pci_sanity_check is confusing. It looks like this:
static int pci_sanity_check(const struct pci_bus_operations *o)
{
u16 class, vendor;
unsigned bus;
int devfn;
struct bus pbus; /* Dummy device */
#define PCI_CLASS_BRIDGE_HOST 0x0600
#define
Hi,
Please check following gpio/multifunc select registers in SB
0:11.0 0xe4 0xe5 0x5b 0x58 0x53 0x95 0x94
I think they should match. Regarding the SIO configuration just one bit is
different - GPIO2 bit 4. Please try to change chipset voltage in BIOS and see
if it changes too.
Rudolf
--
Author: uwe
Date: 2008-01-19 10:40:17 +0100 (Sat, 19 Jan 2008)
New Revision: 3063
Modified:
trunk/util/superiotool/winbond.c
Log:
Small superiotool fix to detect more Winbond W83627EHF chips. The
patch is tested on actual hardware.
As per datasheet the ID should be 0x886? for those chips.
Not
Author: uwe
Date: 2008-01-19 10:40:17 +0100 (Sat, 19 Jan 2008)
New Revision: 3063
Modified:
trunk/util/superiotool/winbond.c
Log:
Small superiotool fix to detect more Winbond W83627EHF chips. The
patch is tested on actual hardware.
As per datasheet the ID should be 0x886? for those chips.
Not
Author: uwe
Date: 2008-01-19 10:43:48 +0100 (Sat, 19 Jan 2008)
New Revision: 3064
Modified:
trunk/util/superiotool/README
Log:
Add Bingxun Shi [EMAIL PROTECTED] to the list of contributors (trivial).
Signed-off-by: Uwe Hermann [EMAIL PROTECTED]
Acked-by: Uwe Hermann [EMAIL PROTECTED]
ron minnich wrote:
I thought that even without VSA, a pci config read of 0:1.0 would give
me something reasonable back. But the devices that are found without
VSA are 0:c.0, 0:d.0, and then 0:f.0 etc.
Without VSA, the only thing you are going to see south of LX are the
real hardware PCI
In the future, I'll add an explicit if you think you see anything that
looks like an error message, STOP IMMEDIATELY to any mails with
subversion commands.
That, or if you see any subversion command, STOP IMMEDIATELY.
:-)
Segher
--
coreboot mailing list
coreboot@coreboot.org
Quoting Corey Osgood [EMAIL PROTECTED]:
[EMAIL PROTECTED] wrote:
So,
With the name change what is LinuxBIOSv3 going to be?
coreboot v1?
coreboot v3?
Thanks - Joe
LinuxBIOS v2 - coreboot v2
LinuxBIOS v3 - coreboot v3
LinuxBIOS v1 - stays the same, for historical and
On Sat, Jan 19, 2008 at 09:09:03AM -0500, Tom Sylla wrote:
Of course, you can access MSRs on those devices before VSA is
loaded.
It would be really awesome to support the bus natively.
//Peter
--
coreboot mailing list
coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot
On 19.01.2008 09:15, ron minnich wrote:
I am wondering for VSA if we should not have a post-ram step where we
find all LAR entries with names like
prestage2/*
and run them. Still not sure of the right approach for VSA. Is VSA so
special that we shouldn't worry about handling it in the
On Sat, Jan 19, 2008 at 10:50:26AM -0500, [EMAIL PROTECTED] wrote:
So people that are working on v3 should still put that in the email
subject line so it doesn't cause confusion, correct?
Just like before, yes. Often it is kind of clear from the
context/content though, v2 and v3 have different
On Jan 19, 2008 7:58 AM, Peter Stuge [EMAIL PROTECTED] wrote:
It would be really awesome to support the bus natively.
I get this request a lot -- just heard the same comment a few days ago.
We could create a method to do this natively, but would need to create
pci bios tables for linux, or
Carl-Daniel Hailfinger wrote:
On 19.01.2008 07:39, ron minnich wrote:
Marc, should we modify the LX build to somehow wget the VSA and copy
it in to LAR? Or should we have a top-level blob directory in v3
that includes the vsa file, and then build it in to LAR?
Please don't store
ron minnich wrote:
pci_sanity_check is confusing. It looks like this:
static int pci_sanity_check(const struct pci_bus_operations *o)
{
u16 class, vendor;
unsigned bus;
int devfn;
struct bus pbus; /* Dummy device */
#define PCI_CLASS_BRIDGE_HOST 0x0600
On 19.01.2008 18:07, Stefan Reinauer wrote:
Carl-Daniel Hailfinger wrote:
On 19.01.2008 07:39, ron minnich wrote:
Marc, should we modify the LX build to somehow wget the VSA and copy
it in to LAR? Or should we have a top-level blob directory in v3
that includes the vsa file, and then build
On Jan 19, 2008 9:48 AM, Carl-Daniel Hailfinger
[EMAIL PROTECTED] wrote:
What exactly does stop us from using stage 2 phase 1 for that purpose?
nothing. I will do that.
I will use the coreboot repo for the blob.
Thanks all, you cleared up my thinking.
ron
--
coreboot mailing list
Carl-Daniel Hailfinger wrote:
*/
- //while (generic_spi_read_status_register()
JEDEC_RDSR_BIT_WIP)
+ while (generic_spi_read_status_register() JEDEC_RDSR_BIT_WIP)
myusec_delay(10);
- //if (i%1024==0) fputc('b',stderr);
+ if (i
On Sat, Jan 19, 2008 at 08:55:44AM -0800, ron minnich wrote:
On Jan 19, 2008 8:18 AM, Carl-Daniel Hailfinger
[EMAIL PROTECTED] wrote:
On 19.01.2008 07:39, ron minnich wrote:
Marc, should we modify the LX build to somehow wget the VSA and copy
it in to LAR? Or should we have a top-level
See patch.
Uwe.
--
http://www.hermann-uwe.de | http://www.holsham-traders.de
http://www.crazy-hacks.org | http://www.unmaintained-free-software.org
Properly cleanup null.o and builtin.o upon 'make clean'.
Signed-off-by: Uwe Hermann [EMAIL PROTECTED]
Index: Makefile
On Sat, Jan 19, 2008 at 08:03:50PM +0100, Uwe Hermann wrote:
Properly cleanup null.o and builtin.o upon 'make clean'.
Signed-off-by: Uwe Hermann [EMAIL PROTECTED]
Acked-by: Peter Stuge [EMAIL PROTECTED]
Index: Makefile
===
Author: uwe
Date: 2008-01-19 22:08:06 +0100 (Sat, 19 Jan 2008)
New Revision: 42
Modified:
trunk/filo-0.5/Makefile
Log:
Properly cleanup null.o and builtin.o upon 'make clean'.
Signed-off-by: Uwe Hermann [EMAIL PROTECTED]
Acked-by: Peter Stuge [EMAIL PROTECTED]
Modified:
Author: uwe
Date: 2008-01-19 22:08:06 +0100 (Sat, 19 Jan 2008)
New Revision: 42
Modified:
trunk/filo-0.5/Makefile
Log:
Properly cleanup null.o and builtin.o upon 'make clean'.
Signed-off-by: Uwe Hermann [EMAIL PROTECTED]
Acked-by: Peter Stuge [EMAIL PROTECTED]
Modified:
On Sat, Jan 19, 2008 at 08:34:36PM +0100, Peter Stuge wrote:
Acked-by: Peter Stuge [EMAIL PROTECTED]
Thanks, r42.
Uwe.
--
http://www.hermann-uwe.de | http://www.holsham-traders.de
http://www.crazy-hacks.org | http://www.unmaintained-free-software.org
--
coreboot mailing list
Quoting Carl-Daniel Hailfinger [EMAIL PROTECTED]:
Hi!
To bring this issue to an end, I resolved all conflicts the patch had
against the current tree and regenerated it without the controversial
id.lds section.
On 09.01.2008 16:13, Marc Karasek wrote:
Attached is the latest.
It uses -ge
On 19.01.2008 19:34, Ronald Hoogenboom wrote:
Carl-Daniel Hailfinger wrote:
*/
-//while (generic_spi_read_status_register()
JEDEC_RDSR_BIT_WIP)
+while (generic_spi_read_status_register() JEDEC_RDSR_BIT_WIP)
myusec_delay(10);
-//if (i%1024==0)
On 18.01.2008 23:10, Ward Vandewege wrote:
On Wed, Jan 16, 2008 at 10:34:29PM -0500, Ward Vandewege wrote:
Winbond W25X16VSSI
Winbond W25X32VSSI
Problem with Winbond is they really only want to sell large
quantities. I haven't even gotten a quote and delivery time
back from my sales rep
Hi Marc!
To commit your patch, I need a signoff from you because you created the
patch. Please see
http://www.coreboot.org/Development_Guidelines#Sign-off_Procedure for
details.
Thanks!
On 19.01.2008 23:15, [EMAIL PROTECTED] wrote:
Quoting Carl-Daniel Hailfinger [EMAIL PROTECTED]:
To
On 19/01/08 08:55 -0800, ron minnich wrote:
On Jan 19, 2008 8:18 AM, Carl-Daniel Hailfinger
[EMAIL PROTECTED] wrote:
On 19.01.2008 07:39, ron minnich wrote:
Marc, should we modify the LX build to somehow wget the VSA and copy
it in to LAR? Or should we have a top-level blob directory in
As this is now committed, can you please post your 'superiotool -d'
output from the board (which one btw?) here for archival purposes?
Ok, I will post an output file tomorrow. The board is an video embeded
system based on intel x86 structure. It is kdm2860(KEDACOM).
Thanks
bxshi
--
coreboot
Author: stepan
Date: 2008-01-20 02:59:43 +0100 (Sun, 20 Jan 2008)
New Revision: 3066
Modified:
trunk/coreboot-v2/targets/amd/serengeti_cheetah_fam10/Config-abuild.lb
Log:
last try i hope. Building with a payload changes the result of the rom
image. Even if the rom image size is not changed, it
On 20.01.2008 02:11, coreboot information wrote:
Change Log:
give it 2k more space for abuild. let's look into this anyways, but get rid of
the impression that the cheetah on fam10 is broken just because we're using a
too new compiler for abuild. (trivial)
Signed-off-by: Stefan Reinauer
Dear coreboot readers!
This is the automated build check service of coreboot.
The developer stepan checked in revision 3066 to
the coreboot source repository and caused the following
changes:
Change Log:
last try i hope. Building with a payload changes the result of the rom
image. Even if the
On Jan 19, 2008 5:37 PM, Jordan Crouse [EMAIL PROTECTED] wrote:
Please don't. coreboot is not about the VSA, its not about VGA blobs
or NIC blobs or Bob's random blob. Its about the core boot code. If
it takes an extra step to build the final rom, well, so be it. Write
a script or use an
33 matches
Mail list logo
