From rminnich at gmail.com  Mon Oct  1 04:36:03 2007
From: rminnich at gmail.com (ron minnich)
Date: Sun, 30 Sep 2007 21:36:03 -0500
Subject: [LinuxBIOS] successfully flashed Asus M2A-VM,
In-Reply-To: <46FF12BC.E588.00ED.0@ravenet.ca>
References: <46FF12BC.E588.00ED.0@ravenet.ca>
Message-ID: <13426df10709301936l69776452q2607898db754fcd7@mail.gmail.com>

On 9/30/07, Rodney Crossman <rodc at ravenet.ca> wrote:

> WARNING: No chipset found. Flash detection will most likely fail.
> SST49LF080A found at physical address: 0xfff00000

It occurs to me that the 'will most likely fail' message is too
pessimistic. Anybody want to reword it :-)

I get that message all the time, followed by the 'OH! I found this flash part!"

Maybe even do this:

Note: flashrom has no support for this chipset.

Then set an internal variable indicating that there was no chipset support.

And then, if and only if no flash part is found, AND the chipset was
not supported:
Warning: no flash part identified, this *may* be due to the fact the
flashrom has no special code for this chipset.

thanks

ron



From corey.osgood at gmail.com  Mon Oct  1 05:03:34 2007
From: corey.osgood at gmail.com (Corey Osgood)
Date: Sun, 30 Sep 2007 23:03:34 -0400
Subject: [LinuxBIOS] EHCI stack to port to FILO?
In-Reply-To: <20070930202924.12388.qmail@stuge.se>
References: <47000258.1020707@gmail.com> <20070930202924.12388.qmail@stuge.se>
Message-ID: <47006386.1060500@gmail.com>

Peter Stuge wrote:
> On Sun, Sep 30, 2007 at 04:08:56PM -0400, Corey Osgood wrote:
>   
>> I'm working from the 2.6 kernel driver at the moment,
>>     
>
> What about the early serial stuff? (Not debug port, but the other.)
>
> Maybe there's some EHCI stuff there?
>   

You mean in the kernel or LB?

>> And can anyone, perhaps with an EPIA or EPIA-M, confirm that UHCI
>> is working in FILO? I've tried disabling the EHCI device, but it
>> still fails on vt8237.
>>     
>
> All EHCI controllers also provide one UHCI or OHCI (I forget if
> there's a choice or if not, which it should be) per physical port in
> order to have backwards compatibility for 1.x-only devices.
>
> So you should find UHCI controller devices when EHCI is enabled. And
> if you disable EHCI, the UHCI/OHCI controllers should be disabled
> too.
>   

Hmm, vt8237r has a separate device for EHCI that can be disabled without
disabling the UHCI controllers. I'm assuming that this essentially makes
them act as regular UHCI controllers.

> Try plugging a low- or full-speed device into the controller.
>   

Just tried it:

boot: uda1:/vmlinuz root=/dev/hda1 console=ttyS0,115200n8
earlyprintk=ttyS0,115200n8 ro            
LinuxLabs USB bootloader
New USB device, setting address 2
New USB device, setting address 2
[...]
New USB device, setting address 2
There is a USB device, but it won't init! This is a bad thing.


I'll try to disable EHCI and then use the 1.1 hard drive adapter, and
see what happens.

-Corey



From stepan at coresystems.de  Mon Oct  1 08:59:02 2007
From: stepan at coresystems.de (Stefan Reinauer)
Date: Mon, 1 Oct 2007 08:59:02 +0200
Subject: [LinuxBIOS] EHCI stack to port to FILO?
In-Reply-To: <47006386.1060500@gmail.com>
References: <47000258.1020707@gmail.com> <20070930202924.12388.qmail@stuge.se>
	<47006386.1060500@gmail.com>
Message-ID: <20071001065902.GA19318@coresystems.de>

* Corey Osgood <corey.osgood at gmail.com> [071001 05:03]:
> > So you should find UHCI controller devices when EHCI is enabled. And
> > if you disable EHCI, the UHCI/OHCI controllers should be disabled
> > too.
> 
> Hmm, vt8237r has a separate device for EHCI that can be disabled without
> disabling the UHCI controllers. I'm assuming that this essentially makes
> them act as regular UHCI controllers.
 
You don't have to disable the EHCI controller device to use the other.
If you don't use the EHCI device, the USB communications will just be
1.1 instead of 2.0

> boot: uda1:/vmlinuz root=/dev/hda1 console=ttyS0,115200n8
> earlyprintk=ttyS0,115200n8 ro            
> LinuxLabs USB bootloader
> New USB device, setting address 2
> New USB device, setting address 2
> [...]
> New USB device, setting address 2
> There is a USB device, but it won't init! This is a bad thing.
 
I think the driver is broken and/or not well tested, unfortunately.

-- 
coresystems GmbH ? Brahmsstr. 16 ? D-79104 Freiburg i. Br.
      Tel.: +49 761 7668825 ? Fax: +49 761 7664613
Email: info at coresystems.de  ? http://www.coresystems.de/
Registergericht: Amtsgericht Freiburg ? HRB 7656
Gesch?ftsf?hrer: Stefan Reinauer ? Ust-IdNr.: DE245674866



From c-d.hailfinger.devel.2006 at gmx.net  Mon Oct  1 12:28:46 2007
From: c-d.hailfinger.devel.2006 at gmx.net (Carl-Daniel Hailfinger)
Date: Mon, 01 Oct 2007 12:28:46 +0200
Subject: [LinuxBIOS] [PATCH] improved SPI flash support (restructured)
In-Reply-To: <20070929135924.GA6264@coresystems.de>
References: <46F78D07.1010608@gmx.net> <20070924231719.GE26022@greenwood>
	<46F85DC7.9040502@gmx.net> <20070927003823.GA708@localdomain>
	<46FB7862.9090008@gmx.net> <20070927143042.GA3788@localdomain>
	<46FD033A.2000108@gmx.net> <20070928145508.GH7553@greenwood>
	<46FD852A.9030400@gmx.net> <46FDB3AD.4070609@gmx.net>
	<20070929135924.GA6264@coresystems.de>
Message-ID: <4700CBDE.4070801@gmx.net>

On 29.09.2007 15:59, Stefan Reinauer wrote:
> * Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006 at gmx.net> [070929 04:08]:
>> +#define ITE_SUPERIO_PORT1	0x2e
>> +#define ITE_SUPERIO_PORT2	0x4e
> 
> This has nothing to do with the IDE. All PC SuperIOs are on 2e or 4e.
> 
>> +int probe_spi(struct flashchip *flash)
>> +{
>> +	unsigned char readarr[3];
> 
> This should be a struct imho
> 
> typedef struct spi_id {
>         unsigned char vendor_id;
>         unsigned short device_id;
> } spi_id_t;

Yes, but the underlying generic SPI function uses an array for commands
and results. Once I add write/erase support, it will become obvious why
I used unsigned char arrays.

> The driver does only probe so far, right?

Yes.

> what about the other SPI commands?

Will be implemented once this patch has been tested.

Carl-Daniel



From stepan at coresystems.de  Mon Oct  1 12:54:55 2007
From: stepan at coresystems.de (Stefan Reinauer)
Date: Mon, 01 Oct 2007 12:54:55 +0200
Subject: [LinuxBIOS] [PATCH] improved SPI flash support (restructured)
In-Reply-To: <4700CBDE.4070801@gmx.net>
References: <46F78D07.1010608@gmx.net> <20070924231719.GE26022@greenwood>
	<46F85DC7.9040502@gmx.net> <20070927003823.GA708@localdomain>
	<46FB7862.9090008@gmx.net> <20070927143042.GA3788@localdomain>
	<46FD033A.2000108@gmx.net> <20070928145508.GH7553@greenwood>
	<46FD852A.9030400@gmx.net> <46FDB3AD.4070609@gmx.net>
	<20070929135924.GA6264@coresystems.de> <4700CBDE.4070801@gmx.net>
Message-ID: <4700D1FF.5030806@coresystems.de>

Carl-Daniel Hailfinger wrote:
>>> +int probe_spi(struct flashchip *flash)
>>> +{
>>> +	unsigned char readarr[3];
>>>       
>> This should be a struct imho
>>
>> typedef struct spi_id {
>>         unsigned char vendor_id;
>>         unsigned short device_id;
>> } spi_id_t;
>>     
>
> Yes, but the underlying generic SPI function uses an array for commands
> and results. Once I add write/erase support, it will become obvious why
> I used unsigned char arrays.
>
>   
Ah, so maybe it should be a union?

>> what about the other SPI commands?
>>     
>
> Will be implemented once this patch has been tested.
>   

Cool. I'll wait.

-- 
coresystems GmbH ? Brahmsstr. 16 ? D-79104 Freiburg i. Br.
      Tel.: +49 761 7668825 ? Fax: +49 761 7664613
Email: info at coresystems.de  ? http://www.coresystems.de/
Registergericht: Amtsgericht Freiburg ? HRB 7656
Gesch?ftsf?hrer: Stefan Reinauer ? Ust-IdNr.: DE245674866




From c-d.hailfinger.devel.2006 at gmx.net  Mon Oct  1 13:01:33 2007
From: c-d.hailfinger.devel.2006 at gmx.net (Carl-Daniel Hailfinger)
Date: Mon, 01 Oct 2007 13:01:33 +0200
Subject: [LinuxBIOS] [PATCH] improved SPI flash support (restructured)
In-Reply-To: <4700D1FF.5030806@coresystems.de>
References: <46F78D07.1010608@gmx.net> <20070924231719.GE26022@greenwood>
	<46F85DC7.9040502@gmx.net> <20070927003823.GA708@localdomain>
	<46FB7862.9090008@gmx.net> <20070927143042.GA3788@localdomain>
	<46FD033A.2000108@gmx.net> <20070928145508.GH7553@greenwood>
	<46FD852A.9030400@gmx.net> <46FDB3AD.4070609@gmx.net>
	<20070929135924.GA6264@coresystems.de>
	<4700CBDE.4070801@gmx.net> <4700D1FF.5030806@coresystems.de>
Message-ID: <4700D38D.8090606@gmx.net>

On 01.10.2007 12:54, Stefan Reinauer wrote:
> Carl-Daniel Hailfinger wrote:
>>>> +int probe_spi(struct flashchip *flash)
>>>> +{
>>>> +	unsigned char readarr[3];
>>>>       
>>> This should be a struct imho
>>>
>>> typedef struct spi_id {
>>>         unsigned char vendor_id;
>>>         unsigned short device_id;
>>> } spi_id_t;
>>>     
>> Yes, but the underlying generic SPI function uses an array for commands
>> and results. Once I add write/erase support, it will become obvious why
>> I used unsigned char arrays.
>>
>>   
> Ah, so maybe it should be a union?

That's an option. I'll consider this once I refine the code.

Carl-Daniel



From ward at gnu.org  Mon Oct  1 14:25:59 2007
From: ward at gnu.org (Ward Vandewege)
Date: Mon, 1 Oct 2007 08:25:59 -0400
Subject: [LinuxBIOS] [PATCH] improved SPI flash support (restructured)
In-Reply-To: <4700CBDE.4070801@gmx.net>
References: <46F85DC7.9040502@gmx.net> <20070927003823.GA708@localdomain>
	<46FB7862.9090008@gmx.net> <20070927143042.GA3788@localdomain>
	<46FD033A.2000108@gmx.net> <20070928145508.GH7553@greenwood>
	<46FD852A.9030400@gmx.net> <46FDB3AD.4070609@gmx.net>
	<20070929135924.GA6264@coresystems.de> <4700CBDE.4070801@gmx.net>
Message-ID: <20071001122559.GA11604@localdomain>

On Mon, Oct 01, 2007 at 12:28:46PM +0200, Carl-Daniel Hailfinger wrote:
> Will be implemented once this patch has been tested.

Ah, yes, sorry, here's the output:

# ./flashrom 
Calibrating delay loop... ok
No LinuxBIOS table found.
Found chipset "NVIDIA MCP55": Enabling flash write... OK.
No EEPROM/flash device found.

# ./flashrom -v
Calibrating delay loop... ok
No LinuxBIOS table found.
Found chipset "NVIDIA MCP55": Enabling flash write... OK.
No EEPROM/flash device found.

# ./flashrom -v -m gigabyte:m57sli
Calibrating delay loop... ok
No LinuxBIOS table found.
Found chipset "NVIDIA MCP55": Enabling flash write... OK.
Found board "GIGABYTE GA-M57SLI": Enabling flash write... Serial flash
segment 0xfffe0000-0xffffffff enabled
Serial flash segment 0x000e0000-0x000fffff enabled
Serial flash segment 0xffee0000-0xffefffff disabled
Serial flash segment 0xfff80000-0xfffeffff enabled
LPC write to serial flash enabled
serial flash pin 29
OK.
No EEPROM/flash device found.

Does that look good?

Thanks,
Ward.

-- 
Ward Vandewege <ward at fsf.org>
Free Software Foundation - Senior System Administrator



From c-d.hailfinger.devel.2006 at gmx.net  Mon Oct  1 14:53:35 2007
From: c-d.hailfinger.devel.2006 at gmx.net (Carl-Daniel Hailfinger)
Date: Mon, 01 Oct 2007 14:53:35 +0200
Subject: [LinuxBIOS] [PATCH] improved SPI flash support (restructured)
In-Reply-To: <20071001122559.GA11604@localdomain>
References: <46F85DC7.9040502@gmx.net> <20070927003823.GA708@localdomain>
	<46FB7862.9090008@gmx.net> <20070927143042.GA3788@localdomain>
	<46FD033A.2000108@gmx.net> <20070928145508.GH7553@greenwood>
	<46FD852A.9030400@gmx.net> <46FDB3AD.4070609@gmx.net>
	<20070929135924.GA6264@coresystems.de>
	<4700CBDE.4070801@gmx.net> <20071001122559.GA11604@localdomain>
Message-ID: <4700EDCF.6020809@gmx.net>

On 01.10.2007 14:25, Ward Vandewege wrote:
> On Mon, Oct 01, 2007 at 12:28:46PM +0200, Carl-Daniel Hailfinger wrote:
>> Will be implemented once this patch has been tested.
> 
> Ah, yes, sorry, here's the output:

Thanks!

> # ./flashrom 
> Calibrating delay loop... ok
> No LinuxBIOS table found.
> Found chipset "NVIDIA MCP55": Enabling flash write... OK.
> No EEPROM/flash device found.
> 
> # ./flashrom -v
> Calibrating delay loop... ok
> No LinuxBIOS table found.
> Found chipset "NVIDIA MCP55": Enabling flash write... OK.
> No EEPROM/flash device found.
> 
> # ./flashrom -v -m gigabyte:m57sli
> Calibrating delay loop... ok
> No LinuxBIOS table found.
> Found chipset "NVIDIA MCP55": Enabling flash write... OK.
> Found board "GIGABYTE GA-M57SLI": Enabling flash write... Serial flash
> segment 0xfffe0000-0xffffffff enabled
> Serial flash segment 0x000e0000-0x000fffff enabled
> Serial flash segment 0xffee0000-0xffefffff disabled
> Serial flash segment 0xfff80000-0xfffeffff enabled
> LPC write to serial flash enabled
> serial flash pin 29
> OK.
> No EEPROM/flash device found.
> 
> Does that look good?

Unfortunately not. Hmm... you used -v (verify) instead of -V (verbose).
And my patch was incomplete.

Can you try "flashrom -V -m gigabyte:m57sli" with the attached patch
(against current svn) and report back?

Thanks,
Carl-Daniel
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: linuxbios_flashrom_ite_spi_restructured3.diff
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20071001/dcb4b56a/attachment.ksh>

From acassis at gmail.com  Mon Oct  1 14:52:31 2007
From: acassis at gmail.com (Alan Carvalho de Assis)
Date: Mon, 1 Oct 2007 09:52:31 -0300
Subject: [LinuxBIOS] GA-M57SLI SPI support
In-Reply-To: <4700E2D9.6000409@gmx.net>
References: <46F696CA.9060501@gmx.net> <46F85DC7.9040502@gmx.net>
	<20070927003823.GA708@localdomain> <46FB7862.9090008@gmx.net>
	<20070927143042.GA3788@localdomain> <46FD033A.2000108@gmx.net>
	<20070928145508.GH7553@greenwood> <46FD852A.9030400@gmx.net>
	<37367b3a0709301303q4e441f7eu11dee5a05ccc3175@mail.gmail.com>
	<4700E2D9.6000409@gmx.net>
Message-ID: <37367b3a0710010552t7c4641ev8f4185b701207b58@mail.gmail.com>

2007/10/1, Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006 at gmx.net>:
>
> On 30.09.2007 22:03, Alan Carvalho de Assis wrote:
> > Hi Carl-Daniel,
> >
> > 2007/9/28, Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006 at gmx.net>:
> > sic
> >> Yes, looking for testers.
> >>
> >
> > Currently I'm off finishing my master degree thesis but I still
> > reading LB posts and I want to know if exist some memory size
> > limitation on LPC-to-SPI?
>
> Yes, but it depends on the translation chip. For the IT8176F, we get
> exactly 1152kBytes if we can trust the datasheet. I prefer not to trust
> it, but so far nodoby has done experiments.
>
So it needs more some experiments.

> > Today we are limited at 2MB BIOS LPC flash but SPI flash can have too
> > many mega bytes. Is possible to use bigger SPI flash using this
> > LPC-to-SPI convertion?
>
> Yes and no. You can still read chips up to 16MBytes by hand, but it is
> CPU-intensive. I might write a driver for that in the future, though.
> Please note that more than 16MBytes can't be addressed with the SPI
> flash protocol because of its limitation to 24bit addresses.
>
Sure. At SST web site the max. flash size I found is 4MBytes (32Mbits).

> If you ever find a SPI flash chip with more than 16MBytes, please tell
> me. I'd like to take a look at its data sheet.
>
I never work with SPI flash. But I think an option is to use 2 chips
and select them using chip selects (it needs some hacks).

> Carl-Daniel
>

Cheers,

Alan

-- 
------------------------------------------------------------
|                     Alan Carvalho de Assis                |
------------------------------------------------------------
--
N?o importa o que os outros ir?o pensar,
A cura para a infelicidade ? a felicidade



From ward at gnu.org  Mon Oct  1 15:00:07 2007
From: ward at gnu.org (Ward Vandewege)
Date: Mon, 1 Oct 2007 09:00:07 -0400
Subject: [LinuxBIOS] [PATCH] improved SPI flash support (restructured)
In-Reply-To: <4700EDCF.6020809@gmx.net>
References: <46FB7862.9090008@gmx.net> <20070927143042.GA3788@localdomain>
	<46FD033A.2000108@gmx.net> <20070928145508.GH7553@greenwood>
	<46FD852A.9030400@gmx.net> <46FDB3AD.4070609@gmx.net>
	<20070929135924.GA6264@coresystems.de>
	<4700CBDE.4070801@gmx.net> <20071001122559.GA11604@localdomain>
	<4700EDCF.6020809@gmx.net>
Message-ID: <20071001130007.GA12406@localdomain>

On Mon, Oct 01, 2007 at 02:53:35PM +0200, Carl-Daniel Hailfinger wrote:
> Unfortunately not. Hmm... you used -v (verify) instead of -V (verbose).

Woops - that's what happens when you try to do stuff before coffee.

> And my patch was incomplete.
> 
> Can you try "flashrom -V -m gigabyte:m57sli" with the attached patch
> (against current svn) and report back?

Yes, this looks a lot better:

# ./flashrom -V -m gigabyte:m57sli
Calibrating delay loop... 283M loops per second. ok
No LinuxBIOS table found.
Found chipset "NVIDIA MCP55": Enabling flash write... OK.
Found board "GIGABYTE GA-M57SLI": Enabling flash write... Serial flash
segment 0xfffe0000-0xffffffff enabled
Serial flash segment 0x000e0000-0x000fffff enabled
Serial flash segment 0xffee0000-0xffefffff disabled
Serial flash segment 0xfff80000-0xfffeffff enabled
LPC write to serial flash enabled
serial flash pin 29
OK.
Probing for Am29F040B, 512 KB
probe_29f040b: id1 0x49, id2 0x4d
Probing for Am29F016D, 2048 KB
probe_29f040b: id1 0xff, id2 0xff
Probing for AE49F2008, 256 KB
probe_jedec: id1 0x83, id2 0x83
Probing for At29C040A, 512 KB
probe_jedec: id1 0x49, id2 0x4d
Probing for At29C020, 256 KB
probe_jedec: id1 0x83, id2 0x83
Probing for Mx29f002, 256 KB
probe_29f002: id1 0x83, id2 0x83
Probing for MX25L4005, 512 KB
RDID returned c2 20 13
probe_spi: id1 0xc2, id2 0x2013
MX25L4005 found at physical address: 0xfff80000
Flash part is MX25L4005 (512 KB)
OK, only ENABLING flash write, but NOT FLASHING.

Thanks,
Ward.

-- 
Ward Vandewege <ward at fsf.org>
Free Software Foundation - Senior System Administrator



From c-d.hailfinger.devel.2006 at gmx.net  Mon Oct  1 15:13:12 2007
From: c-d.hailfinger.devel.2006 at gmx.net (Carl-Daniel Hailfinger)
Date: Mon, 01 Oct 2007 15:13:12 +0200
Subject: [LinuxBIOS] [PATCH] improved SPI flash support (restructured)
In-Reply-To: <20071001130007.GA12406@localdomain>
References: <46FB7862.9090008@gmx.net>
	<20070927143042.GA3788@localdomain>	<46FD033A.2000108@gmx.net>
	<20070928145508.GH7553@greenwood>	<46FD852A.9030400@gmx.net>
	<46FDB3AD.4070609@gmx.net>	<20070929135924.GA6264@coresystems.de>	<4700CBDE.4070801@gmx.net>
	<20071001122559.GA11604@localdomain>	<4700EDCF.6020809@gmx.net>
	<20071001130007.GA12406@localdomain>
Message-ID: <4700F268.2010604@gmx.net>

On 01.10.2007 15:00, Ward Vandewege wrote:
> On Mon, Oct 01, 2007 at 02:53:35PM +0200, Carl-Daniel Hailfinger wrote:
>> Unfortunately not. Hmm... you used -v (verify) instead of -V (verbose).
> 
> Woops - that's what happens when you try to do stuff before coffee.
> 
>> And my patch was incomplete.
>>
>> Can you try "flashrom -V -m gigabyte:m57sli" with the attached patch
>> (against current svn) and report back?
> 
> Yes, this looks a lot better:
> 
> # ./flashrom -V -m gigabyte:m57sli
> Calibrating delay loop... 283M loops per second. ok
> No LinuxBIOS table found.
> Found chipset "NVIDIA MCP55": Enabling flash write... OK.
> Found board "GIGABYTE GA-M57SLI": Enabling flash write... Serial flash
> segment 0xfffe0000-0xffffffff enabled
> Serial flash segment 0x000e0000-0x000fffff enabled
> Serial flash segment 0xffee0000-0xffefffff disabled
> Serial flash segment 0xfff80000-0xfffeffff enabled
> LPC write to serial flash enabled
> serial flash pin 29
> OK.
> Probing for Am29F040B, 512 KB
> probe_29f040b: id1 0x49, id2 0x4d
> Probing for Am29F016D, 2048 KB
> probe_29f040b: id1 0xff, id2 0xff
> Probing for AE49F2008, 256 KB
> probe_jedec: id1 0x83, id2 0x83
> Probing for At29C040A, 512 KB
> probe_jedec: id1 0x49, id2 0x4d
> Probing for At29C020, 256 KB
> probe_jedec: id1 0x83, id2 0x83
> Probing for Mx29f002, 256 KB
> probe_29f002: id1 0x83, id2 0x83
> Probing for MX25L4005, 512 KB
> RDID returned c2 20 13
> probe_spi: id1 0xc2, id2 0x2013
> MX25L4005 found at physical address: 0xfff80000
> Flash part is MX25L4005 (512 KB)
> OK, only ENABLING flash write, but NOT FLASHING.

Great! Can you ack/commit with the following changelog?
------------------------------------------------------------------------

This patch aims to restructure SPI flash support in a more reasonable
way. It introduces a generic SPI host driver for the IT8716F Super I/O
which will enable easy SPI programming without having to care for the
peculiarities of the SPI host.

To activate probing for the IT8716F, you have to use the gigabyte:m57sli
mainboard override. SPI support will then use the gathered SPI host data
to access the SPI flash.

This has been tested sucessfully by Ward Vandewege <ward at gnu.org> on the
GA-M57SLI v2.0, which has a MX25L4005 SPI flash part.

Signed-off-by: Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006 at gmx.net>

------------------------------------------------------------------------

Thanks,
Carl-Daniel



From svn at openbios.org  Mon Oct  1 15:39:03 2007
From: svn at openbios.org (svn at openbios.org)
Date: Mon,  1 Oct 2007 15:39:03 +0200
Subject: [LinuxBIOS] r2815 - trunk/util/superiotool
Message-ID: <mailman.686.1355071170.16123.coreboot@coreboot.org>

Author: uwe
Date: 2007-10-01 15:39:02 +0200 (Mon, 01 Oct 2007)
New Revision: 2815

Modified:
   trunk/util/superiotool/README
   trunk/util/superiotool/superiotool.c
   trunk/util/superiotool/superiotool.h
Log:
De-uglify the --version output (trivial).

Signed-off-by: Uwe Hermann <uwe at hermann-uwe.de>
Acked-by: Uwe Hermann <uwe at hermann-uwe.de>



Modified: trunk/util/superiotool/README
===================================================================
--- trunk/util/superiotool/README	2007-09-28 15:45:43 UTC (rev 2814)
+++ trunk/util/superiotool/README	2007-10-01 13:39:02 UTC (rev 2815)
@@ -37,7 +37,7 @@
  -h | --help            Show a short help text
 
 Per default (no options) superiotool will just probe for a Super I/O
-and print its vendor, name, ID, version, and config port.
+and print its vendor, name, ID, revision, and config port.
 
 Typical usage of superiotool:
 

Modified: trunk/util/superiotool/superiotool.c
===================================================================
--- trunk/util/superiotool/superiotool.c	2007-09-28 15:45:43 UTC (rev 2814)
+++ trunk/util/superiotool/superiotool.c	2007-10-01 13:39:02 UTC (rev 2815)
@@ -172,6 +172,7 @@
 int main(int argc, char *argv[])
 {
 	int i, j, opt, option_index;
+	char tmp[80];
 
 	const static struct option long_options[] = {
 		{"dump",		no_argument, NULL, 'd'},
@@ -195,7 +196,10 @@
 			verbose = 1;
 			break;
 		case 'v':
-			printf("superiotool %s\n", SUPERIOTOOL_VERSION);
+			strncpy((char *)&tmp,
+				(const char *)&SUPERIOTOOL_VERSION[6],
+				strlen(SUPERIOTOOL_VERSION) - 8);
+			printf("superiotool r%s\n", (char *)&tmp);
 			exit(0);
 			break;
 		case 'h':

Modified: trunk/util/superiotool/superiotool.h
===================================================================
--- trunk/util/superiotool/superiotool.h	2007-09-28 15:45:43 UTC (rev 2814)
+++ trunk/util/superiotool/superiotool.h	2007-10-01 13:39:02 UTC (rev 2815)
@@ -29,7 +29,7 @@
 #include <getopt.h>
 #include <sys/io.h>
 
-#define SUPERIOTOOL_VERSION "r$Rev$"
+#define SUPERIOTOOL_VERSION "$Rev$"
 
 #define USAGE "Usage: superiotool [-d] [-D] [-V] [-v] [-h]\n\n\
   -d | --dump            Dump Super I/O registers\n\




From joe at smittys.pointclark.net  Mon Oct  1 15:48:27 2007
From: joe at smittys.pointclark.net (joe at smittys.pointclark.net)
Date: Mon, 01 Oct 2007 09:48:27 -0400
Subject: [LinuxBIOS] Problems with Filo booting - HELP
In-Reply-To: <47000290.6020000@gmail.com>
References: <20070929165103.pcm220bn4s48sow8@smittys.pointclark.net>
	<20070929205527.GA16584@coresystems.de>
	<20070929170245.ata0hgegqowgcwgs@www.smittys.pointclark.net>
	<20070929201342.mifqbujb44ocwks8@smittys.pointclark.net>
	<46FF1CB2.60901@gmail.com>
	<20070930115720.mwni4u7go4wkk8wg@www.smittys.pointclark.net>
	<47000290.6020000@gmail.com>
Message-ID: <20071001094827.loois4qr0g4ckw8o@www.smittys.pointclark.net>

Quoting Corey Osgood <corey.osgood at gmail.com>:

> joe at smittys.pointclark.net wrote:
>> Corey the onboard memory is 128MB. I have to set the video buffer to
>> something or it won't boot past raminit.c. I have it set to 512K.
>> Could this be causing the problem? I will test it with memtest.
>
> In northbridge.c, you are subtracting that 512K from the usable ram? I
> meant to post back that I'd looked it up and you do have 128MB, but
> forgot. But yeah, check with memtest.
>
> -Corey
>
Well I can definatly say there is a memory issue somewhere. memtest  
won't even boot. I don't even know where to go from here :(

Thanks - Joe

---------------------------------------------
Welcome to elfboot, the open sourced starter.
January 2002, Eric Biederman.
Version 1.3

rom_stream: 0xfffd0000 - 0xfffeffff
Found ELF candidate at offset 0
header_offset is 0
Try to load at offset 0x0
malloc Enter, size 32, free_mem_ptr 00018000
malloc 0x00018000
New segment addr 0x10000 size 0x17790 offset 0x1000 filesize 0x17790
(cleaned up) New segment addr 0x10000 size 0x17790 offset 0x1000  
filesize 0x17790
lb: [0x0000000000004000, 0x000000000001c000)
segment: [0x0000000000010000, 0x0000000000027790, 0x0000000000027790)
malloc Enter, size 32, free_mem_ptr 00018020
malloc 0x00018020
    late: [0x000000000001c000, 0x0000000000027790, 0x0000000000027790)
  bounce: [0x0000000007fdc000, 0x0000000007fe8000, 0x0000000007fe8000)
Loading Segment: addr: 0x0000000007fdc000 memsz: 0x000000000000c000  
filesz: 0x000000000000c000
[ 0x0000000007fdc000, 0000000007fe8000, 0x0000000007fe8000) <-  
0000000000001000
Loading Segment: addr: 0x000000000001c000 memsz: 0x000000000000b790  
filesz: 0x000000000000b790
[ 0x000000000001c000, 0000000000027790, 0x0000000000027790) <-  
000000000000d000
Loaded segments
verified segments
closed down stream
Jumping to boot code at 0x10000
entry    = 0x00010000
lb_start = 0x00004000
lb_size  = 0x00018000
adjust   = 0x07fe4000
buffer   = 0x07fd0000
      elf_boot_notes = 0x000139a0
adjusted_boot_notes = 0x07ff79a0
Unexpected Exception: -1 @ ffffffff:ffffffff - Halting
Code: -1 eflags: ffffffff
eax: ffffffff ebx: ffffffff ecx: ffffffff edx: 00018000
edi: ffffffff esi: ffffffff ebp: 0010003c esp: 00100014
--------------------------------------------------------



From stepan at coresystems.de  Mon Oct  1 15:52:22 2007
From: stepan at coresystems.de (Stefan Reinauer)
Date: Mon, 01 Oct 2007 15:52:22 +0200
Subject: [LinuxBIOS] r2815 - trunk/util/superiotool
Message-ID: <4700FB96.6070000@coresystems.de>

svn at openbios.org wrote:
> De-uglify the --version output (trivial).
>   

> -			printf("superiotool %s\n", SUPERIOTOOL_VERSION);
> +			strncpy((char *)&tmp,
> +				(const char *)&SUPERIOTOOL_VERSION[6],
> +				strlen(SUPERIOTOOL_VERSION) - 8);
> +			printf("superiotool r%s\n", (char *)&tmp);
>   

Hm.. is this less uglier? Does it look trivial? ;)

Is there any reason that this doesnt just say

printf ("superiotool r" SUPERIOTOOL_VERSION "\n");

??



-- 
coresystems GmbH ? Brahmsstr. 16 ? D-79104 Freiburg i. Br.
      Tel.: +49 761 7668825 ? Fax: +49 761 7664613
Email: info at coresystems.de  ? http://www.coresystems.de/
Registergericht: Amtsgericht Freiburg ? HRB 7656
Gesch?ftsf?hrer: Stefan Reinauer ? Ust-IdNr.: DE245674866




From svn at openbios.org  Mon Oct  1 16:16:49 2007
From: svn at openbios.org (LinuxBIOS)
Date: Mon, 01 Oct 2007 14:16:49 -0000
Subject: [LinuxBIOS] #55: Support for Intel Virtualization Technology
 (IVT) a.k.a Vanderpool
In-Reply-To: <040.8efcf96c24b65de2fa0952fcdc992926@openbios.org>
References: <040.8efcf96c24b65de2fa0952fcdc992926@openbios.org>
Message-ID: <049.74f285964089ad8a140cdcee870e0858@openbios.org>

#55: Support for Intel Virtualization Technology (IVT) a.k.a Vanderpool
----------------------------+-----------------------------------------------
    Reporter:  uwe          |         Owner:  somebody         
        Type:  enhancement  |        Status:  closed           
    Priority:  major        |     Milestone:  Going mainstream 
   Component:  code         |       Version:                   
  Resolution:  invalid      |      Keywords:                   
Dependencies:               |   Patchstatus:  there is no patch
----------------------------+-----------------------------------------------
Changes (by stepan):

  * status:  new => closed
  * resolution:  => invalid

Comment:

 There is nothing we need to do for this.

 We just should not disable it and set the lock bit. ;-)

-- 
Ticket URL: <http://tracker.linuxbios.org/trac/LinuxBIOS/ticket/55#comment:1>
LinuxBIOS <http://www.linuxbios.org/>

From svn at openbios.org  Mon Oct  1 16:17:23 2007
From: svn at openbios.org (LinuxBIOS)
Date: Mon, 01 Oct 2007 14:17:23 -0000
Subject: [LinuxBIOS] #56: Support for AMD Virtualization (AMD-V) a.k.a
 Pacifica
In-Reply-To: <040.6d41345c7a450869f62e840555738390@openbios.org>
References: <040.6d41345c7a450869f62e840555738390@openbios.org>
Message-ID: <049.69b22bcc36b40814ff10e5ff6f5f12bb@openbios.org>

#56: Support for AMD Virtualization (AMD-V) a.k.a Pacifica
----------------------------+-----------------------------------------------
    Reporter:  uwe          |         Owner:  somebody         
        Type:  enhancement  |        Status:  closed           
    Priority:  major        |     Milestone:  Going mainstream 
   Component:  code         |       Version:                   
  Resolution:  invalid      |      Keywords:                   
Dependencies:               |   Patchstatus:  there is no patch
----------------------------+-----------------------------------------------
Changes (by stepan):

  * status:  new => closed
  * resolution:  => invalid

Comment:

 There is nothing we need to do for this. It works just fine.

-- 
Ticket URL: <http://tracker.linuxbios.org/trac/LinuxBIOS/ticket/56#comment:1>
LinuxBIOS <http://www.linuxbios.org/>

From info at coresystems.de  Mon Oct  1 16:26:15 2007
From: info at coresystems.de (LinuxBIOS information)
Date: Mon, 01 Oct 2007 16:26:15 +0200
Subject: [LinuxBIOS] r2815 build service
Message-ID: <E1IcMDv-0003XM-Fe@khepri.openbios.org>

Dear LinuxBIOS readers!

This is the automated build check service of LinuxBIOS.

The developer "uwe" checked in revision 2815 to
the LinuxBIOS source repository and caused the following 
changes:

Change Log:
De-uglify the --version output (trivial).

Signed-off-by: Uwe Hermann <uwe at hermann-uwe.de>
Acked-by: Uwe Hermann <uwe at hermann-uwe.de>



Build Log:
Compilation of arima:hdama is still broken
See the error log at http://qa.linuxbios.org/log_buildbrd.php?revision=2815&device=hdama&vendor=arima
Compilation of ibm:e325 is still broken
See the error log at http://qa.linuxbios.org/log_buildbrd.php?revision=2815&device=e325&vendor=ibm
Compilation of ibm:e326 is still broken
See the error log at http://qa.linuxbios.org/log_buildbrd.php?revision=2815&device=e326&vendor=ibm
Compilation of iei:juki-511p is still broken
See the error log at http://qa.linuxbios.org/log_buildbrd.php?revision=2815&device=juki-511p&vendor=iei
Compilation of iwill:dk8s2 is still broken
See the error log at http://qa.linuxbios.org/log_buildbrd.php?revision=2815&device=dk8s2&vendor=iwill
Compilation of iwill:dk8x is still broken
See the error log at http://qa.linuxbios.org/log_buildbrd.php?revision=2815&device=dk8x&vendor=iwill
Compilation of newisys:khepri is still broken
See the error log at http://qa.linuxbios.org/log_buildbrd.php?revision=2815&device=khepri&vendor=newisys


If something broke during this checkin please be a pain 
in uwe's neck until the issue is fixed.

If this issue is not fixed within 24h the revision should 
be backed out.

   Best regards,
     LinuxBIOS automatic build system





From joe at smittys.pointclark.net  Mon Oct  1 16:38:41 2007
From: joe at smittys.pointclark.net (joe at smittys.pointclark.net)
Date: Mon, 01 Oct 2007 10:38:41 -0400
Subject: [LinuxBIOS] [v2][PATCH] PCI PERR# and SERR# i82801xx
In-Reply-To: <46FA8C22.5060701@amd.com>
References: <46F9A610.8060306@amd.com>
	<13426df10709251900w3434f2fbp39a1a811b1bf39a6@mail.gmail.com>
	<46FA8C22.5060701@amd.com>
Message-ID: <20071001103841.r4kb4dmtc4skswss@smittys.pointclark.net>

Thee lines in i82801xx_pci.c need to be removed. They cause the  
i82801DB to reset. See this thread for more info:

http://article.gmane.org/gmane.linux.bios/26791

Signed-off-by: Joseph Smith <joe at smittys.pointclark.net>

Thanks - Joe
-------------- next part --------------
A non-text attachment was scrubbed...
Name: i82801xx_pci.patch
Type: text/x-c
Size: 739 bytes
Desc: not available
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20071001/71e2aa28/attachment.bin>

From rminnich at gmail.com  Mon Oct  1 17:13:10 2007
From: rminnich at gmail.com (ron minnich)
Date: Mon, 1 Oct 2007 08:13:10 -0700
Subject: [LinuxBIOS] flashrom erase failed
In-Reply-To: <46FE034A.8020100@mit.edu>
References: <46FE034A.8020100@mit.edu>
Message-ID: <13426df10710010813i59b387d3nad1b929cf10372fe@mail.gmail.com>

On 9/29/07, Lane Brooks <lbrooks at mit.edu> wrote:
> I am trying to flash an SST49LF008A on a board with a Geode CS5536AD
> southbridge using flashrom.  It reads fine, but when I try to write, it
> failed with an ERASE FAILED message.  Any ideas on why?

this usually implies a write disable jumper of some sort -- maybe GPIO
controlled.

thanks

ron



From rminnich at gmail.com  Mon Oct  1 18:50:04 2007
From: rminnich at gmail.com (ron minnich)
Date: Mon, 1 Oct 2007 09:50:04 -0700
Subject: [LinuxBIOS] Problems with Filo booting - HELP
In-Reply-To: <20071001094827.loois4qr0g4ckw8o@www.smittys.pointclark.net>
References: <20070929165103.pcm220bn4s48sow8@smittys.pointclark.net>
	<20070929205527.GA16584@coresystems.de>
	<20070929170245.ata0hgegqowgcwgs@www.smittys.pointclark.net>
	<20070929201342.mifqbujb44ocwks8@smittys.pointclark.net>
	<46FF1CB2.60901@gmail.com>
	<20070930115720.mwni4u7go4wkk8wg@www.smittys.pointclark.net>
	<47000290.6020000@gmail.com>
	<20071001094827.loois4qr0g4ckw8o@www.smittys.pointclark.net>
Message-ID: <13426df10710010950s379f8230y5b4ffec4da605f06@mail.gmail.com>

you might try forcing the size (in code) to 32M or some such in
hardwaremain.c and see if it works then. There's  something odd with
your ram.

ron



From rminnich at gmail.com  Mon Oct  1 18:58:37 2007
From: rminnich at gmail.com (ron minnich)
Date: Mon, 1 Oct 2007 09:58:37 -0700
Subject: [LinuxBIOS] W39V040BPZ or vt8237. Flashing problems.
In-Reply-To: <46FE9285.6000900@comcast.net>
References: <46FD7099.6050801@comcast.net>
	<13426df10709281428h125862daqcbf0bc2c5249281a@mail.gmail.com>
	<46FD783F.4000502@comcast.net>
	<13426df10709281528g385a615cs75a6b2b2ee8124ab@mail.gmail.com>
	<46FD8AF8.9040702@comcast.net>
	<13426df10709281754r3ed1d639qe5a597b9dbe67ac3@mail.gmail.com>
	<46FE9285.6000900@comcast.net>
Message-ID: <13426df10710010958x596c20f6u2a4dde0daa389294@mail.gmail.com>

do you have URL for 8237 docs?

ron



From rminnich at gmail.com  Mon Oct  1 19:01:42 2007
From: rminnich at gmail.com (ron minnich)
Date: Mon, 1 Oct 2007 10:01:42 -0700
Subject: [LinuxBIOS] Enabling APIC 82801xx
In-Reply-To: <20070929084703.fd3vcft204w0so0k@www.smittys.pointclark.net>
References: <20070928024000.oadf9xxpu88og4k8@www.smittys.pointclark.net>
	<20070928030415.gp5qdva4cg844oc8@www.smittys.pointclark.net>
	<20070928114936.d11vuuxb1ssgoskg@smittys.pointclark.net>
	<46FD27F8.80100@amd.com>
	<20070929084703.fd3vcft204w0so0k@www.smittys.pointclark.net>
Message-ID: <13426df10710011001q1778201el6f0fda446a01f9dd@mail.gmail.com>

On 9/29/07, joe at smittys.pointclark.net <joe at smittys.pointclark.net> wrote:

> device pci 2.0 off end # VGA compatible controller: Intel Corporation
> 82830 CGC
>
> enabled it does not allocate the 0x00fec00000 - 0x00fec000ff memory
> range. Is this because the VGA controller prefetches memory first?? Or
> is this just a wacky Intel thing?
>

oh, joy. I have not been following this thread; sorry. So when you
boot with DEBUG_SPEW, do you see what is going on with the allocation?

ron



From rminnich at gmail.com  Mon Oct  1 19:04:41 2007
From: rminnich at gmail.com (ron minnich)
Date: Mon, 1 Oct 2007 10:04:41 -0700
Subject: [LinuxBIOS] Supertek ST-3ET
In-Reply-To: <200709301924.39334.bios@ryven.de>
References: <200709301924.39334.bios@ryven.de>
Message-ID: <13426df10710011004t2714966bvd32d753858e7470c@mail.gmail.com>

On 9/30/07, Markus Boas <bios at ryven.de> wrote:

> rom_stream: 0xfffc0000 - 0xfffcffff
> No header at 0
> ...
> ...
> ...
> No header at 8096
> header_offset is -1
> Can not load ELF

so it can not find any elf image. Your part is 256KB, right? you're
sure it is not 512KiB for example?


> option ROM_SIZE=512*1024
>

oh but it is! The search is starting at fffc0000 and it should start
at fff80000. that's your problem.

But why is the elf loader doing that? I can not recall what would make
it do this. Let me know if you find it, if not, I can try to look.

ron



From peter at stuge.se  Mon Oct  1 19:23:26 2007
From: peter at stuge.se (Peter Stuge)
Date: Mon, 1 Oct 2007 19:23:26 +0200
Subject: [LinuxBIOS] Problems with Filo booting - HELP
In-Reply-To: <13426df10710010950s379f8230y5b4ffec4da605f06@mail.gmail.com>
References: <20070929165103.pcm220bn4s48sow8@smittys.pointclark.net>
	<20070929205527.GA16584@coresystems.de>
	<20070929170245.ata0hgegqowgcwgs@www.smittys.pointclark.net>
	<20070929201342.mifqbujb44ocwks8@smittys.pointclark.net>
	<46FF1CB2.60901@gmail.com>
	<20070930115720.mwni4u7go4wkk8wg@www.smittys.pointclark.net>
	<47000290.6020000@gmail.com>
	<20071001094827.loois4qr0g4ckw8o@www.smittys.pointclark.net>
	<13426df10710010950s379f8230y5b4ffec4da605f06@mail.gmail.com>
Message-ID: <20071001172326.10630.qmail@stuge.se>

On Mon, Oct 01, 2007 at 09:50:04AM -0700, ron minnich wrote:
> you might try forcing the size (in code) to 32M or some such in
> hardwaremain.c and see if it works then.

And/or set very conservative memory timings.


//Peter



From talbotx at comcast.net  Mon Oct  1 19:43:08 2007
From: talbotx at comcast.net (Adam Talbot)
Date: Mon, 01 Oct 2007 10:43:08 -0700
Subject: [LinuxBIOS] W39V040BPZ or vt8237. Flashing problems.
In-Reply-To: <13426df10710010958x596c20f6u2a4dde0daa389294@mail.gmail.com>
References: <46FD7099.6050801@comcast.net>	
	<13426df10709281428h125862daqcbf0bc2c5249281a@mail.gmail.com>	
	<46FD783F.4000502@comcast.net>	
	<13426df10709281528g385a615cs75a6b2b2ee8124ab@mail.gmail.com>	
	<46FD8AF8.9040702@comcast.net>	
	<13426df10709281754r3ed1d639qe5a597b9dbe67ac3@mail.gmail.com>	
	<46FE9285.6000900@comcast.net>
	<13426df10710010958x596c20f6u2a4dde0daa389294@mail.gmail.com>
Message-ID: <470131AC.9020604@comcast.net>

no, sorry
-Adam


ron minnich wrote:
> do you have URL for 8237 docs?
>
> ron
>
>   




From corey.osgood at gmail.com  Mon Oct  1 19:51:21 2007
From: corey.osgood at gmail.com (Corey Osgood)
Date: Mon, 01 Oct 2007 13:51:21 -0400
Subject: [LinuxBIOS] W39V040BPZ or vt8237. Flashing problems.
In-Reply-To: <470131AC.9020604@comcast.net>
References: <46FD7099.6050801@comcast.net>		<13426df10709281428h125862daqcbf0bc2c5249281a@mail.gmail.com>		<46FD783F.4000502@comcast.net>		<13426df10709281528g385a615cs75a6b2b2ee8124ab@mail.gmail.com>		<46FD8AF8.9040702@comcast.net>		<13426df10709281754r3ed1d639qe5a597b9dbe67ac3@mail.gmail.com>		<46FE9285.6000900@comcast.net>	<13426df10710010958x596c20f6u2a4dde0daa389294@mail.gmail.com>
	<470131AC.9020604@comcast.net>
Message-ID: <47013399.7090902@gmail.com>

Adam Talbot wrote:
> no, sorry
> -Adam
>
>
> ron minnich wrote:
>   
>> do you have URL for 8237 docs?
>>
>> ron
>>
>>   
>>     
http://www.via.com.tw/en/downloads/datasheets/chipsets/VT8237R_SouthBridge_Revision2.06_Lead-Free.zip



From rminnich at gmail.com  Mon Oct  1 20:19:46 2007
From: rminnich at gmail.com (ron minnich)
Date: Mon, 1 Oct 2007 11:19:46 -0700
Subject: [LinuxBIOS] filo, qemu, v3
Message-ID: <13426df10710011119j75a6551dg9ff87930258c7567@mail.gmail.com>

I'm having poor luck with the latest v3 release, qemu, and filo. Any
hints here? I have been away for a bit. I'm going to bite the bullet
and try to get geode going, finally.

ron



From corey.osgood at gmail.com  Mon Oct  1 20:26:46 2007
From: corey.osgood at gmail.com (Corey Osgood)
Date: Mon, 01 Oct 2007 14:26:46 -0400
Subject: [LinuxBIOS] [v2][PATCH] PCI PERR# and SERR# i82801xx
In-Reply-To: <20071001103841.r4kb4dmtc4skswss@smittys.pointclark.net>
References: <46F9A610.8060306@amd.com>	<13426df10709251900w3434f2fbp39a1a811b1bf39a6@mail.gmail.com>	<46FA8C22.5060701@amd.com>
	<20071001103841.r4kb4dmtc4skswss@smittys.pointclark.net>
Message-ID: <47013BE6.30808@gmail.com>

joe at smittys.pointclark.net wrote:
> Thee lines in i82801xx_pci.c need to be removed. They cause the
> i82801DB to reset. See this thread for more info:
>
> http://article.gmane.org/gmane.linux.bios/26791
>
> Signed-off-by: Joseph Smith <joe at smittys.pointclark.net>
>
> Thanks - Joe

Acked-by: Corey Osgood <corey.osgood at gmail.com>



From svn at openbios.org  Mon Oct  1 20:32:00 2007
From: svn at openbios.org (svn at openbios.org)
Date: Mon,  1 Oct 2007 20:32:00 +0200
Subject: [LinuxBIOS] r2816 - trunk/LinuxBIOSv2/src/southbridge/intel/i82801xx
Message-ID: <mailman.687.1355071170.16123.coreboot@coreboot.org>

Author: rminnich
Date: 2007-10-01 20:32:00 +0200 (Mon, 01 Oct 2007)
New Revision: 2816

Modified:
   trunk/LinuxBIOSv2/src/southbridge/intel/i82801xx/i82801xx_pci.c
Log:
Thee lines in i82801xx_pci.c need to be removed. They cause the
i82801DB to reset. See this thread for more info:

http://article.gmane.org/gmane.linux.bios/26791

Signed-off-by: Joseph Smith <joe at smittys.pointclark.net>


Acked-by: Corey Osgood <corey.osgood at gmail.com>
Acked-by: Ronald G. Minnich <rminnich at gmail.com>



Modified: trunk/LinuxBIOSv2/src/southbridge/intel/i82801xx/i82801xx_pci.c
===================================================================
--- trunk/LinuxBIOSv2/src/southbridge/intel/i82801xx/i82801xx_pci.c	2007-10-01 13:39:02 UTC (rev 2815)
+++ trunk/LinuxBIOSv2/src/southbridge/intel/i82801xx/i82801xx_pci.c	2007-10-01 18:32:00 UTC (rev 2816)
@@ -34,13 +34,6 @@
 	reg16 |= 0xf900;	/* Clear possible errors */
 	pci_write_config16(dev, 0x06, reg16);
 
-	/* i82801er has this commented out, wonder why? */
-	/* System error enable */
-	reg32 = pci_read_config32(dev, 0x04);
-	reg32 |= (1 << 8);	/* SERR# Enable */
-	reg32 |= (1 << 6);	/* Parity Error Response */
-	pci_write_config32(dev, 0x04, reg32);
-
 	reg16 = pci_read_config16(dev, 0x1e);
 	reg16 |= 0xf800;	/* Clear possible errors */
 	pci_write_config16(dev, 0x1e, reg16);




From rminnich at gmail.com  Mon Oct  1 20:32:16 2007
From: rminnich at gmail.com (ron minnich)
Date: Mon, 1 Oct 2007 11:32:16 -0700
Subject: [LinuxBIOS] [v2][PATCH] PCI PERR# and SERR# i82801xx
In-Reply-To: <47013BE6.30808@gmail.com>
References: <46F9A610.8060306@amd.com>
	<13426df10709251900w3434f2fbp39a1a811b1bf39a6@mail.gmail.com>
	<46FA8C22.5060701@amd.com>
	<20071001103841.r4kb4dmtc4skswss@smittys.pointclark.net>
	<47013BE6.30808@gmail.com>
Message-ID: <13426df10710011132s349f1bf9y443184eed7e49f96@mail.gmail.com>

Committed revision 2816.

ron



From info at coresystems.de  Mon Oct  1 21:18:17 2007
From: info at coresystems.de (LinuxBIOS information)
Date: Mon, 01 Oct 2007 21:18:17 +0200
Subject: [LinuxBIOS] r2816 build service
Message-ID: <E1IcQmX-0002vA-4H@khepri.openbios.org>

Dear LinuxBIOS readers!

This is the automated build check service of LinuxBIOS.

The developer "rminnich" checked in revision 2816 to
the LinuxBIOS source repository and caused the following 
changes:

Change Log:
Thee lines in i82801xx_pci.c need to be removed. They cause the
i82801DB to reset. See this thread for more info:

http://article.gmane.org/gmane.linux.bios/26791

Signed-off-by: Joseph Smith <joe at smittys.pointclark.net>


Acked-by: Corey Osgood <corey.osgood at gmail.com>
Acked-by: Ronald G. Minnich <rminnich at gmail.com>



Build Log:
Compilation of arima:hdama is still broken
See the error log at http://qa.linuxbios.org/log_buildbrd.php?revision=2816&device=hdama&vendor=arima
Compilation of ibm:e325 is still broken
See the error log at http://qa.linuxbios.org/log_buildbrd.php?revision=2816&device=e325&vendor=ibm
Compilation of ibm:e326 is still broken
See the error log at http://qa.linuxbios.org/log_buildbrd.php?revision=2816&device=e326&vendor=ibm
Compilation of iei:juki-511p is still broken
See the error log at http://qa.linuxbios.org/log_buildbrd.php?revision=2816&device=juki-511p&vendor=iei
Compilation of iwill:dk8s2 is still broken
See the error log at http://qa.linuxbios.org/log_buildbrd.php?revision=2816&device=dk8s2&vendor=iwill
Compilation of iwill:dk8x is still broken
See the error log at http://qa.linuxbios.org/log_buildbrd.php?revision=2816&device=dk8x&vendor=iwill
Compilation of newisys:khepri is still broken
See the error log at http://qa.linuxbios.org/log_buildbrd.php?revision=2816&device=khepri&vendor=newisys


If something broke during this checkin please be a pain 
in rminnich's neck until the issue is fixed.

If this issue is not fixed within 24h the revision should 
be backed out.

   Best regards,
     LinuxBIOS automatic build system





From marc.jones at amd.com  Mon Oct  1 22:22:18 2007
From: marc.jones at amd.com (Marc Jones)
Date: Mon, 01 Oct 2007 14:22:18 -0600
Subject: [LinuxBIOS] flashrom erase failed
In-Reply-To: <46FE034A.8020100@mit.edu>
References: <46FE034A.8020100@mit.edu>
Message-ID: <470156FA.1090605@amd.com>



Lane Brooks wrote:
> I am trying to flash an SST49LF008A on a board with a Geode CS5536AD 
> southbridge using flashrom.  It reads fine, but when I try to write, it 
> failed with an ERASE FAILED message.  Any ideas on why?
> 
> Thanks,
> Lane Brooks
> 

Lane,
Geode systems write protect the BIOS via RCONFs (cache settings similar 
to MTRRs). Change MSR 0x1808 top byte to 0x22. Then run flashrom.

 > rdmsr 0x1808
MSR register 0x1808 => 25:ff:fc:02:13:f7:df:00
 > wrmsr 0x1808 22:ff:fc:02:13:f7:df:00
MSR register 0x1808 => 22:ff:fc:02:13:f7:df:00



Marc


-- 
Marc Jones
Senior Firmware Engineer
(970) 226-9684 Office
mailto:Marc.Jones at amd.com
http://www.amd.com/embeddedprocessors





From uwe at hermann-uwe.de  Mon Oct  1 22:43:24 2007
From: uwe at hermann-uwe.de (Uwe Hermann)
Date: Mon, 1 Oct 2007 22:43:24 +0200
Subject: [LinuxBIOS] r2815 - trunk/util/superiotool
In-Reply-To: <4700FB96.6070000@coresystems.de>
References: <4700FB96.6070000@coresystems.de>
Message-ID: <20071001204324.GA9669@greenwood>

On Mon, Oct 01, 2007 at 03:52:22PM +0200, Stefan Reinauer wrote:
> svn at openbios.org wrote:
> > De-uglify the --version output (trivial).
> >   
> 
> > -			printf("superiotool %s\n", SUPERIOTOOL_VERSION);
> > +			strncpy((char *)&tmp,
> > +				(const char *)&SUPERIOTOOL_VERSION[6],
> > +				strlen(SUPERIOTOOL_VERSION) - 8);
> > +			printf("superiotool r%s\n", (char *)&tmp);
> >   
> 
> Hm.. is this less uglier? Does it look trivial? ;)

OK, probably not trivial :) Guilty as charged.

It's less uglier (in the output), though:

Before:
./superiotool -v
superiotool r$Rev: 2814 $

After:
./superiotool -v
superiotool r2815


> Is there any reason that this doesnt just say
> 
> printf ("superiotool r" SUPERIOTOOL_VERSION "\n");

Yes, it won't work unfortunately (I hoped it would, but it doesn't).

$Rev$ will not be replaced by the svn revision (e.g. "2815")
but rather by "$Rev: 2815 $" (which is stupid IMO, but we cannot change
that). It would be nice if there was something like $OnlyRev$ or so
which only prints the actual number, but I don't think there's such an
option.


Uwe.
-- 
http://www.hermann-uwe.de  | http://www.holsham-traders.de
http://www.crazy-hacks.org | http://www.unmaintained-free-software.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20071001/a95f7fa8/attachment.sig>

From uwe at hermann-uwe.de  Mon Oct  1 22:43:35 2007
From: uwe at hermann-uwe.de (Uwe Hermann)
Date: Mon, 1 Oct 2007 22:43:35 +0200
Subject: [LinuxBIOS] [PATCH] fix resource end in K8 amdk8/northbridge.c
In-Reply-To: <46FD9628.9020402@assembler.cz>
References: <46FD9628.9020402@assembler.cz>
Message-ID: <20071001204335.GB9669@greenwood>

On Sat, Sep 29, 2007 at 02:02:48AM +0200, Rudolf Marek wrote:
> Index: src/northbridge/amd/amdk8/northbridge.c
> ===================================================================
> --- src/northbridge/amd/amdk8/northbridge.c	(revision 2776)
> +++ src/northbridge/amd/amdk8/northbridge.c	(working copy)
> @@ -562,7 +562,7 @@
>  	base  |= (resource->base >> 8) & 0xffffff00;
>  	base  |= 3;
>  	limit &= 0x00000048;
> -	limit |= ((resource->base + resource->size) >> 8) & 0xffffff00;
> +	limit |= (resource_end(resource) >> 8) & 0xffffff00;
>  	limit |= (resource->index & 3) << 4;
>  	limit |= (nodeid & 7);
>  	f1_write_config32(reg + 0x4, limit);

What exactly is broken in the current code and how does it show? How can
we test the effect of the fix?


Thanks, Uwe.
-- 
http://www.hermann-uwe.de  | http://www.holsham-traders.de
http://www.crazy-hacks.org | http://www.unmaintained-free-software.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20071001/51075cd2/attachment.sig>

From uwe at hermann-uwe.de  Mon Oct  1 22:49:10 2007
From: uwe at hermann-uwe.de (Uwe Hermann)
Date: Mon, 1 Oct 2007 22:49:10 +0200
Subject: [LinuxBIOS] svn tricks [was:r2814 - trunk/util/superiotool]
In-Reply-To: <20070929172443.16584.qmail@stuge.se>
References: <20070929172443.16584.qmail@stuge.se>
Message-ID: <20071001204910.GC9669@greenwood>

On Sat, Sep 29, 2007 at 07:24:43PM +0200, Peter Stuge wrote:
> > -#define SUPERIOTOOL_VERSION "0.1"
> > +#define SUPERIOTOOL_VERSION "r$Rev$"
> 
> How do I work with this? $Rev$ for superiotool.h won't be increased
> automatically when I make changes to another file.

It will be increased with every commit, no matter which files change.
Contrary to CVS, svn has a global revision number (not per-file
revisions), so it'll be updated whenever you commit something (or
someone else committed something and you do an 'svn up').


> I don't even think $Rev$ will bump when I export the changed rev, so
> this will only show the last rev of the particular file?

Nope. It should show the current revision of your tree.

Say you checkout r400 via 'svn co -r 400 svn://...' then $Rev$
should be replaced with '$Rev: 400 $'.


> I have this issue in my own svn repos. What am I doing wrong?

Hm, dunno, the behaviour you described happens with CVS, but not svn
usually.


Uwe.
-- 
http://www.hermann-uwe.de  | http://www.holsham-traders.de
http://www.crazy-hacks.org | http://www.unmaintained-free-software.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20071001/ae6f54aa/attachment.sig>

From uwe at hermann-uwe.de  Mon Oct  1 22:50:30 2007
From: uwe at hermann-uwe.de (Uwe Hermann)
Date: Mon, 1 Oct 2007 22:50:30 +0200
Subject: [LinuxBIOS] successfully flashed Asus M2A-VM,
In-Reply-To: <46FF12BC.E588.00ED.0@ravenet.ca>
References: <46FF12BC.E588.00ED.0@ravenet.ca>
Message-ID: <20071001205030.GD9669@greenwood>

On Sun, Sep 30, 2007 at 03:06:54AM -0500, Rodney Crossman wrote:
> just an fyi that I successfully flashed the bios on an Asus M2A-VM motherboard which has an amd 690G chipset.  System has been power cycled and all is working.  Thank you all for providing this extremely useful tool.
> 
> # ./flashrom -wv m2a1301.bin
> Calibrating delay loop... ok
> No LinuxBIOS table found.
> WARNING: No chipset found. Flash detection will most likely fail.
> SST49LF080A found at physical address: 0xfff00000
> Flash part is SST49LF080A (1024 KB)
> Flash image seems to be a legacy BIOS. Disabling checks.
> Programming Page: 0255 at address: 0x000ff000
> Verifying flash - VERIFIED

Just to clarify -- you flashed a _different_ image than that which was
on the ROM chip already?


Uwe.
-- 
http://www.hermann-uwe.de  | http://www.holsham-traders.de
http://www.crazy-hacks.org | http://www.unmaintained-free-software.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20071001/e338d69a/attachment.sig>

From uwe at hermann-uwe.de  Mon Oct  1 22:51:21 2007
From: uwe at hermann-uwe.de (Uwe Hermann)
Date: Mon, 1 Oct 2007 22:51:21 +0200
Subject: [LinuxBIOS] Problems with Filo booting - HELP
In-Reply-To: <47000508.7070803@gmail.com>
References: <20070929165103.pcm220bn4s48sow8@smittys.pointclark.net>
	<20070929205527.GA16584@coresystems.de>
	<20070929170245.ata0hgegqowgcwgs@www.smittys.pointclark.net>
	<20070930011155.30724.qmail@stuge.se>
	<20070930115026.ln1v74s668w0ogws@www.smittys.pointclark.net>
	<47000508.7070803@gmail.com>
Message-ID: <20071001205121.GE9669@greenwood>

On Sun, Sep 30, 2007 at 04:20:24PM -0400, Corey Osgood wrote:
> Just build memtest and use the resulting "memtest" (not memtest.bin) as
> your payload. Way simpler then it's supposed to be.

That, and enable serial support in memtest, you'll need/want that to
get the output on the serial console.


Uwe.
-- 
http://www.hermann-uwe.de  | http://www.holsham-traders.de
http://www.crazy-hacks.org | http://www.unmaintained-free-software.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20071001/14bb5abf/attachment.sig>

From joe at smittys.pointclark.net  Mon Oct  1 22:58:58 2007
From: joe at smittys.pointclark.net (joe at smittys.pointclark.net)
Date: Mon, 01 Oct 2007 16:58:58 -0400
Subject: [LinuxBIOS] Problems with Filo booting - HELP
In-Reply-To: <13426df10710010950s379f8230y5b4ffec4da605f06@mail.gmail.com>
References: <20070929165103.pcm220bn4s48sow8@smittys.pointclark.net>
	<20070929205527.GA16584@coresystems.de>
	<20070929170245.ata0hgegqowgcwgs@www.smittys.pointclark.net>
	<20070929201342.mifqbujb44ocwks8@smittys.pointclark.net>
	<46FF1CB2.60901@gmail.com>
	<20070930115720.mwni4u7go4wkk8wg@www.smittys.pointclark.net>
	<47000290.6020000@gmail.com>
	<20071001094827.loois4qr0g4ckw8o@www.smittys.pointclark.net>
	<13426df10710010950s379f8230y5b4ffec4da605f06@mail.gmail.com>
Message-ID: <20071001165858.vlz66uxpusgk0gww@www.smittys.pointclark.net>

Quoting ron minnich <rminnich at gmail.com>:

> you might try forcing the size (in code) to 32M or some such in
> hardwaremain.c and see if it works then. There's  something odd with
> your ram.
>
> ron
>
It won't have anything to do with the fact that:

a. It is onboard 128MB memory
b. It doesn't have a SPD module
c. It is located in the second slot not first.

This is wierd because it passes the ram_check() from auto.c earlier in  
the process just fine.

/* Check RAM. */
ram_check(0, 640 * 1024);

Thanks - Joe



From joe at smittys.pointclark.net  Mon Oct  1 23:53:30 2007
From: joe at smittys.pointclark.net (joe at smittys.pointclark.net)
Date: Mon, 01 Oct 2007 17:53:30 -0400
Subject: [LinuxBIOS] Enabling APIC 82801xx
In-Reply-To: <13426df10710011001q1778201el6f0fda446a01f9dd@mail.gmail.com>
References: <20070928024000.oadf9xxpu88og4k8@www.smittys.pointclark.net>
	<20070928030415.gp5qdva4cg844oc8@www.smittys.pointclark.net>
	<20070928114936.d11vuuxb1ssgoskg@smittys.pointclark.net>
	<46FD27F8.80100@amd.com>
	<20070929084703.fd3vcft204w0so0k@www.smittys.pointclark.net>
	<13426df10710011001q1778201el6f0fda446a01f9dd@mail.gmail.com>
Message-ID: <20071001175330.3of34g8lkpw0wks4@www.smittys.pointclark.net>

Quoting ron minnich <rminnich at gmail.com>:

> On 9/29/07, joe at smittys.pointclark.net <joe at smittys.pointclark.net> wrote:
>
>> device pci 2.0 off end # VGA compatible controller: Intel Corporation
>> 82830 CGC
>>
>> enabled it does not allocate the 0x00fec00000 - 0x00fec000ff memory
>> range. Is this because the VGA controller prefetches memory first?? Or
>> is this just a wacky Intel thing?
>>
>
> oh, joy. I have not been following this thread; sorry. So when you
> boot with DEBUG_SPEW, do you see what is going on with the allocation?
>
> ron
>
I have these set to 9 is that different than DEBUG_SPEW?

## Request this level of debugging output
default  DEFAULT_CONSOLE_LOGLEVEL = 9
## At a maximum only compile in this level of debugging
default  MAXIMUM_CONSOLE_LOGLEVEL = 9



Thanks - Joe



From corey.osgood at gmail.com  Tue Oct  2 00:07:59 2007
From: corey.osgood at gmail.com (Corey Osgood)
Date: Mon, 01 Oct 2007 18:07:59 -0400
Subject: [LinuxBIOS] Enabling APIC 82801xx
In-Reply-To: <20071001175330.3of34g8lkpw0wks4@www.smittys.pointclark.net>
References: <20070928024000.oadf9xxpu88og4k8@www.smittys.pointclark.net>	<20070928030415.gp5qdva4cg844oc8@www.smittys.pointclark.net>	<20070928114936.d11vuuxb1ssgoskg@smittys.pointclark.net>	<46FD27F8.80100@amd.com>	<20070929084703.fd3vcft204w0so0k@www.smittys.pointclark.net>	<13426df10710011001q1778201el6f0fda446a01f9dd@mail.gmail.com>
	<20071001175330.3of34g8lkpw0wks4@www.smittys.pointclark.net>
Message-ID: <47016FBF.3020007@gmail.com>

joe at smittys.pointclark.net wrote:
> Quoting ron minnich <rminnich at gmail.com>:
>
>> On 9/29/07, joe at smittys.pointclark.net <joe at smittys.pointclark.net>
>> wrote:
>>
>>> device pci 2.0 off end # VGA compatible controller: Intel Corporation
>>> 82830 CGC
>>>
>>> enabled it does not allocate the 0x00fec00000 - 0x00fec000ff memory
>>> range. Is this because the VGA controller prefetches memory first?? Or
>>> is this just a wacky Intel thing?
>>>
>>
>> oh, joy. I have not been following this thread; sorry. So when you
>> boot with DEBUG_SPEW, do you see what is going on with the allocation?
>>
>> ron
>>
> I have these set to 9 is that different than DEBUG_SPEW?
>
> ## Request this level of debugging output
> default  DEFAULT_CONSOLE_LOGLEVEL = 9
> ## At a maximum only compile in this level of debugging
> default  MAXIMUM_CONSOLE_LOGLEVEL = 9
>
>
>
> Thanks - Joe
>
9 = DEBUG_SPEW. That info is in a comment in most mainboard Config.lb's.

-Corey



From corey.osgood at gmail.com  Tue Oct  2 00:18:11 2007
From: corey.osgood at gmail.com (Corey Osgood)
Date: Mon, 01 Oct 2007 18:18:11 -0400
Subject: [LinuxBIOS] Problems with Filo booting - HELP
In-Reply-To: <20071001165858.vlz66uxpusgk0gww@www.smittys.pointclark.net>
References: <20070929165103.pcm220bn4s48sow8@smittys.pointclark.net>	<20070929205527.GA16584@coresystems.de>	<20070929170245.ata0hgegqowgcwgs@www.smittys.pointclark.net>	<20070929201342.mifqbujb44ocwks8@smittys.pointclark.net>	<46FF1CB2.60901@gmail.com>	<20070930115720.mwni4u7go4wkk8wg@www.smittys.pointclark.net>	<47000290.6020000@gmail.com>	<20071001094827.loois4qr0g4ckw8o@www.smittys.pointclark.net>	<13426df10710010950s379f8230y5b4ffec4da605f06@mail.gmail.com>
	<20071001165858.vlz66uxpusgk0gww@www.smittys.pointclark.net>
Message-ID: <47017223.6010504@gmail.com>

joe at smittys.pointclark.net wrote:
> Quoting ron minnich <rminnich at gmail.com>:
>
>   
>> you might try forcing the size (in code) to 32M or some such in
>> hardwaremain.c and see if it works then. There's  something odd with
>> your ram.
>>
>> ron
>>
>>     
> It won't have anything to do with the fact that:
>
> a. It is onboard 128MB memory
> b. It doesn't have a SPD module
> c. It is located in the second slot not first.
>   

It shouldn't, no, especially not the first 2.

> This is wierd because it passes the ram_check() from auto.c earlier in  
> the process just fine.
>
> /* Check RAM. */
> ram_check(0, 640 * 1024);
>
> Thanks - Joe

All that's checking is the first 640K. To check the rest of the memory,
use ram_check(1024*1024, 1024*1024*128), starting at 1mb to avoid any
reserved areas. Make sure your ram_resource() calls also avoids those
reserved areas.

-Corey



From bishop.robinson at gmail.com  Tue Oct  2 00:33:20 2007
From: bishop.robinson at gmail.com (Robinson Tryon)
Date: Mon, 1 Oct 2007 18:33:20 -0400
Subject: [LinuxBIOS] Call for help: superiotool
In-Reply-To: <46FBDB3E.4000009@gmx.net>
References: <20070923111315.GC12926@greenwood>
	<a698c16a0709270921l860615dv3ebe8d49e2f4c791@mail.gmail.com>
	<46FBDB3E.4000009@gmx.net>
Message-ID: <a698c16a0710011533n37e5e898l78dac2ef3c2c9ef5@mail.gmail.com>

On 9/27/07, Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006 at gmx.net> wrote:
> On 27.09.2007 18:21, Robinson Tryon wrote:
> >
> > Okay -- I grabbed the code from SVN, compiled it and ran it on a few
> > computers, but I didn't get any useful output (verbose mode was also
> > pretty sparse).  I assume that this means that my Super I/O chips are
> > not supported, correct?
>
> Not supported by superiotool, however if there was any output at all,
> we'd like to know it. That alone would probably help us identify the
> Super I/O, and from there, adding support is rather easy.

What kinds of machines would you like output from?  Any hardware I can
get to run 'superiotool' ?  :-)

What other information should I include?  Motherboard model?  Output from lspci?



From uwe at hermann-uwe.de  Tue Oct  2 00:57:56 2007
From: uwe at hermann-uwe.de (Uwe Hermann)
Date: Tue, 2 Oct 2007 00:57:56 +0200
Subject: [LinuxBIOS] filo, qemu, v3
In-Reply-To: <13426df10710011119j75a6551dg9ff87930258c7567@mail.gmail.com>
References: <13426df10710011119j75a6551dg9ff87930258c7567@mail.gmail.com>
Message-ID: <20071001225756.GF9669@greenwood>

On Mon, Oct 01, 2007 at 11:19:46AM -0700, ron minnich wrote:
> I'm having poor luck with the latest v3 release, qemu, and filo. Any
> hints here? I have been away for a bit. I'm going to bite the bullet
> and try to get geode going, finally.

What's the problem? I just verified that the latest v3 svn revision +
FILO + Linux (in a QEMU disk image) boots fine.


Uwe.
-- 
http://www.hermann-uwe.de  | http://www.holsham-traders.de
http://www.crazy-hacks.org | http://www.unmaintained-free-software.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20071002/02c476ff/attachment.sig>

From joe at smittys.pointclark.net  Tue Oct  2 02:16:17 2007
From: joe at smittys.pointclark.net (joe at smittys.pointclark.net)
Date: Mon, 01 Oct 2007 20:16:17 -0400
Subject: [LinuxBIOS] Enabling APIC 82801xx
In-Reply-To: <47016FBF.3020007@gmail.com>
References: <20070928024000.oadf9xxpu88og4k8@www.smittys.pointclark.net>
	<20070928030415.gp5qdva4cg844oc8@www.smittys.pointclark.net>
	<20070928114936.d11vuuxb1ssgoskg@smittys.pointclark.net>
	<46FD27F8.80100@amd.com>
	<20070929084703.fd3vcft204w0so0k@www.smittys.pointclark.net>
	<13426df10710011001q1778201el6f0fda446a01f9dd@mail.gmail.com>
	<20071001175330.3of34g8lkpw0wks4@www.smittys.pointclark.net>
	<47016FBF.3020007@gmail.com>
Message-ID: <20071001201617.kyfivu1hc0gwgwso@www.smittys.pointclark.net>

Quoting Corey Osgood <corey.osgood at gmail.com>:

> joe at smittys.pointclark.net wrote:
>> Quoting ron minnich <rminnich at gmail.com>:
>>
>>> On 9/29/07, joe at smittys.pointclark.net <joe at smittys.pointclark.net>
>>> wrote:
>>>
>>>> device pci 2.0 off end # VGA compatible controller: Intel Corporation
>>>> 82830 CGC
>>>>
>>>> enabled it does not allocate the 0x00fec00000 - 0x00fec000ff memory
>>>> range. Is this because the VGA controller prefetches memory first?? Or
>>>> is this just a wacky Intel thing?
>>>>
>>>
>>> oh, joy. I have not been following this thread; sorry. So when you
>>> boot with DEBUG_SPEW, do you see what is going on with the allocation?

Here is a copy of my bootlog showing devices alocating memory in this region.


Thanks - Joe
-------------- next part --------------
LinuxBIOS-2.0.0.0Fallback Wed Sep 26 18:28:48 EDT 2007 starting...
Setting initial registers....
Initial registers have been set.
No DIMM found in slot 00
DRB 0x60 has been set to 0x00
DRB1 0x61 has been set to 0x00
Found DIMM in slot 01
DIMM is 0x0080 on side 1
DIMM is 0x0000 on side 2
DRB2 0x62 has been set to 0x04
DRB3 0x63 has been set to 0x04
No DIMM found in slot 00, setting DRA to 0xFF
DRA 0x70 has been set to 0xff
Found DIMM in slot 01, setting DRA...
DRA 0x71 has been set to 0xf1
RAM Enable 1: Apply NOP
    Sending RAM command 0x00000010 to 0x00000000
RAM Enable 2: Precharge all
    Sending RAM command 0x00000020 to 0x00000000
RAM Enable 3: CBR
    Sending RAM command 0x00000060 to 0x00000000
RAM Enable 4: Mode register set
    Sending RAM command 0x00000030 to 0x000001d0
RAM Enable 5: Normal operation
    Sending RAM command 0x20000170 to 0x00000000
Northbridge following SDRAM init:
PCI: 00:00.00
00: 86 80 75 35 06 00 10 00 04 00 00 06 00 00 00 00
10: 08 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
20: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
30: 00 00 00 00 40 00 00 00 00 00 00 00 00 00 00 00
40: 09 00 05 01 00 00 00 00 00 00 00 00 02 28 00 0e
50: 72 a0 20 00 00 00 00 00 00 30 33 33 33 33 33 33
60: 00 00 04 04 00 00 00 00 00 00 00 00 00 00 00 00
70: ff f1 ff ff 00 00 00 00 10 00 00 00 70 01 00 20
80: 00 00 00 00 00 00 00 00 00 d0 20 60 00 00 00 00
90: 02 38 00 00 00 00 00 00 00 00 00 00 00 00 00 00
a0: 02 00 20 00 17 02 00 1f 00 00 00 00 00 00 00 00
b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
c0: 00 54 0e 41 a2 99 01 00 c0 00 00 00 00 00 00 00
d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
e0: 00 00 00 00 00 00 00 00 00 00 00 00 09 c9 9f fc
f0: 11 11 01 00 00 00 0b 05 34 d6 33 cf 22 cf 27 cf
Copying LinuxBIOS to RAM.
Jumping to LinuxBIOS.
LinuxBIOS-2.0.0.0Fallback Wed Sep 26 18:28:48 EDT 2007 booting...
end 6cf8cf61, start 0
32-bit delta 1566
calibrate_tsc 32-bit result is 1566
clocks_per_usec: 1566
Enumerating buses...
scan_static_bus for Root Device
Finding PCI configuration type.
PCI: Using configuration type 1
PCI_DOMAIN: 0000 enabled
PCI_DOMAIN: 0000 scanning...
PCI: pci_scan_bus for bus 00
PCI: 00:00.0 [8086/3575] ops
PCI: 00:00.0 [8086/3575] enabled
PCI: devfn 0x9, bad id 0xffffffff
PCI: devfn 0xa, bad id 0xffffffff
PCI: devfn 0xb, bad id 0xffffffff
PCI: devfn 0xc, bad id 0xffffffff
PCI: devfn 0xd, bad id 0xffffffff
PCI: devfn 0xe, bad id 0xffffffff
PCI: devfn 0xf, bad id 0xffffffff
PCI: 00:02.0 [8086/3577] disabled
PCI: devfn 0x11, bad id 0xffffffff
PCI: devfn 0x12, bad id 0xffffffff
PCI: devfn 0x13, bad id 0xffffffff
PCI: devfn 0x14, bad id 0xffffffff
PCI: devfn 0x15, bad id 0xffffffff
PCI: devfn 0x16, bad id 0xffffffff
PCI: devfn 0x17, bad id 0xffffffff
PCI: devfn 0x18, bad id 0xffffffff
PCI: devfn 0x20, bad id 0xffffffff
PCI: devfn 0x28, bad id 0xffffffff
PCI: devfn 0x30, bad id 0xffffffff
PCI: devfn 0x38, bad id 0xffffffff
PCI: devfn 0x40, bad id 0xffffffff
PCI: devfn 0x48, bad id 0xffffffff
PCI: devfn 0x50, bad id 0xffffffff
PCI: devfn 0x58, bad id 0xffffffff
PCI: devfn 0x60, bad id 0xffffffff
PCI: devfn 0x68, bad id 0xffffffff
PCI: devfn 0x70, bad id 0xffffffff
PCI: devfn 0x78, bad id 0xffffffff
PCI: devfn 0x80, bad id 0xffffffff
PCI: devfn 0x88, bad id 0xffffffff
PCI: devfn 0x90, bad id 0xffffffff
PCI: devfn 0x98, bad id 0xffffffff
PCI: devfn 0xa0, bad id 0xffffffff
PCI: devfn 0xa8, bad id 0xffffffff
PCI: devfn 0xb0, bad id 0xffffffff
PCI: devfn 0xb8, bad id 0xffffffff
PCI: devfn 0xc0, bad id 0xffffffff
PCI: devfn 0xc8, bad id 0xffffffff
PCI: devfn 0xd0, bad id 0xffffffff
PCI: devfn 0xd8, bad id 0xffffffff
PCI: devfn 0xe0, bad id 0xffffffff
PCI: 00:1d.0 [8086/24c2] ops
PCI: 00:1d.0 [8086/24c2] enabled
PCI: 00:1d.1 [8086/24c4] ops
PCI: 00:1d.1 [8086/24c4] enabled
PCI: 00:1d.2 [8086/24c7] ops
PCI: 00:1d.2 [8086/24c7] enabled
PCI: devfn 0xeb, bad id 0xffffffff
PCI: devfn 0xec, bad id 0xffffffff
PCI: devfn 0xed, bad id 0xffffffff
PCI: devfn 0xee, bad id 0xffffffff
PCI: 00:1d.7 [8086/24cd] ops
PCI: 00:1d.7 [8086/24cd] enabled
PCI: 00:1e.0 [8086/244e] bus ops
PCI: 00:1e.0 [8086/244e] enabled
PCI: 00:1f.0 [8086/24c0] bus ops
PCI: 00:1f.0 [8086/24c0] enabled
PCI: 00:1f.1 [8086/24cb] ops
PCI: 00:1f.1 [8086/24cb] enabled
PCI: devfn 0xfa, bad id 0xffffffff
PCI: 00:1f.3 [8086/24c3] enabled
PCI: devfn 0xfc, bad id 0xffffffff
PCI: 00:1f.5 [8086/24c5] ops
PCI: 00:1f.5 [8086/24c5] enabled
PCI: 00:1f.6 [8086/24c6] ops
PCI: 00:1f.6 [8086/24c6] enabled
PCI: devfn 0xff, bad id 0xffffffff
do_pci_scan_bridge for PCI: 00:1e.0
PCI: pci_scan_bus for bus 01
PCI: devfn 0x0, bad id 0xffffffff
PCI: devfn 0x8, bad id 0xffffffff
PCI: devfn 0x10, bad id 0xffffffff
PCI: devfn 0x18, bad id 0xffffffff
PCI: devfn 0x20, bad id 0xffffffff
PCI: devfn 0x28, bad id 0xffffffff
PCI: devfn 0x30, bad id 0xffffffff
PCI: devfn 0x38, bad id 0xffffffff
PCI: devfn 0x40, bad id 0xffffffff
PCI: devfn 0x48, bad id 0xffffffff
PCI: devfn 0x50, bad id 0xffffffff
PCI: devfn 0x58, bad id 0xffffffff
PCI: devfn 0x60, bad id 0xffffffff
PCI: devfn 0x68, bad id 0xffffffff
PCI: devfn 0x70, bad id 0xffffffff
PCI: devfn 0x78, bad id 0xffffffff
PCI: devfn 0x80, bad id 0xffffffff
PCI: devfn 0x88, bad id 0xffffffff
PCI: devfn 0x90, bad id 0xffffffff
PCI: devfn 0x98, bad id 0xffffffff
PCI: devfn 0xa0, bad id 0xffffffff
PCI: devfn 0xa8, bad id 0xffffffff
PCI: devfn 0xb0, bad id 0xffffffff
PCI: devfn 0xb8, bad id 0xffffffff
PCI: devfn 0xc0, bad id 0xffffffff
PCI: devfn 0xc8, bad id 0xffffffff
PCI: devfn 0xd0, bad id 0xffffffff
PCI: devfn 0xd8, bad id 0xffffffff
PCI: devfn 0xe0, bad id 0xffffffff
PCI: devfn 0xe8, bad id 0xffffffff
PCI: devfn 0xf0, bad id 0xffffffff
PCI: devfn 0xf8, bad id 0xffffffff
PCI: pci_scan_bus returning with max=001
do_pci_scan_bridge returns max 1
scan_static_bus for PCI: 00:1f.0
Found SMSC Super I/O (ID=0x60, rev=0x01)
PNP: 002e.0 disabled
PNP: 002e.3 disabled
PNP: 002e.4 enabled
PNP: 002e.5 disabled
PNP: 002e.7 enabled
PNP: 002e.9 disabled
PNP: 002e.a disabled
PNP: 002e.b disabled
scan_static_bus for PCI: 00:1f.0 done
PCI: pci_scan_bus returning with max=001
scan_static_bus for Root Device done
done
Allocating resources...
Reading resources...
Root Device compute_allocate_io: base: 00000400 size: 00000000 align: 0 gran: 0
Root Device read_resources bus 0 link: 0
PCI_DOMAIN: 0000 read_resources bus 0 link: 0
PCI: 00:00.0 register 10(00000008), read-only ignoring it
PCI: 00:1e.0 compute_allocate_io: base: 00000000 size: 00000000 align: 12 gran: 12
PCI: 00:1e.0 read_resources bus 1 link: 0
PCI: 00:1e.0 read_resources bus 1 link: 0 done
PCI: 00:1e.0 compute_allocate_io: base: 00000000 size: 00000000 align: 12 gran: 12 done
PCI: 00:1e.0 compute_allocate_io: base: 0000f000 size: 00000000 align: 12 gran: 12
PCI: 00:1e.0 read_resources bus 1 link: 0
PCI: 00:1e.0 read_resources bus 1 link: 0 done
PCI: 00:1e.0 compute_allocate_io: base: 0000f000 size: 00000000 align: 12 gran: 12 done
PCI: 00:1e.0 1c <- [0x000000f000 - 0x000000efff] bus 01 io
PCI: 00:1e.0 compute_allocate_prefmem: base: 00000000 size: 00000000 align: 20 gran: 20
PCI: 00:1e.0 read_resources bus 1 link: 0
PCI: 00:1e.0 read_resources bus 1 link: 0 done
PCI: 00:1e.0 compute_allocate_prefmem: base: 00000000 size: 00000000 align: 20 gran: 20 done
PCI: 00:1e.0 compute_allocate_prefmem: base: fff00000 size: 00000000 align: 20 gran: 20
PCI: 00:1e.0 read_resources bus 1 link: 0
PCI: 00:1e.0 read_resources bus 1 link: 0 done
PCI: 00:1e.0 compute_allocate_prefmem: base: fff00000 size: 00000000 align: 20 gran: 20 done
PCI: 00:1e.0 24 <- [0x00fff00000 - 0x00ffefffff] bus 01 prefmem
PCI: 00:1e.0 compute_allocate_mem: base: 00000000 size: 00000000 align: 20 gran: 20
PCI: 00:1e.0 read_resources bus 1 link: 0
PCI: 00:1e.0 read_resources bus 1 link: 0 done
PCI: 00:1e.0 compute_allocate_mem: base: 00000000 size: 00000000 align: 20 gran: 20 done
PCI: 00:1e.0 compute_allocate_mem: base: fff00000 size: 00000000 align: 20 gran: 20
PCI: 00:1e.0 read_resources bus 1 link: 0
PCI: 00:1e.0 read_resources bus 1 link: 0 done
PCI: 00:1e.0 compute_allocate_mem: base: fff00000 size: 00000000 align: 20 gran: 20 done
PCI: 00:1e.0 20 <- [0x00fff00000 - 0x00ffefffff] bus 01 mem
PCI: 00:1f.0 read_resources bus 0 link: 0
PCI: 00:1f.0 read_resources bus 0 link: 0 done
PCI_DOMAIN: 0000 read_resources bus 0 link: 0 done
Root Device read_resources bus 0 link: 0 done
PCI: 00:1f.5 10 *  [0x00000400 - 0x000004ff] io
PCI: 00:1f.6 10 *  [0x00000800 - 0x000008ff] io
PCI: 00:1f.6 14 *  [0x00000c00 - 0x00000c7f] io
PCI: 00:1f.5 14 *  [0x00000c80 - 0x00000cbf] io
PCI: 00:1d.0 20 *  [0x00000cc0 - 0x00000cdf] io
PCI: 00:1d.1 20 *  [0x00000ce0 - 0x00000cff] io
PCI: 00:1d.2 20 *  [0x00001000 - 0x0000101f] io
PCI: 00:1f.3 20 *  [0x00001020 - 0x0000103f] io
PCI: 00:1f.1 20 *  [0x00001040 - 0x0000104f] io
PCI: 00:1f.1 10 *  [0x00001050 - 0x00001057] io
PCI: 00:1f.1 18 *  [0x00001060 - 0x00001067] io
PCI: 00:1f.1 14 *  [0x00001070 - 0x00001073] io
PCI: 00:1f.1 1c *  [0x00001080 - 0x00001083] io
Root Device compute_allocate_io: base: 00001084 size: 00000c84 align: 8 gran: 0 done
Root Device compute_allocate_mem: base: 00000000 size: 00000000 align: 0 gran: 0
Root Device read_resources bus 0 link: 0
Root Device read_resources bus 0 link: 0 done
PCI: 00:1d.7 10 *  [0x00000000 - 0x000003ff] mem
PCI: 00:1f.1 24 *  [0x00001000 - 0x000013ff] mem
PCI: 00:1f.5 18 *  [0x00002000 - 0x000021ff] mem
PCI: 00:1f.5 1c *  [0x00003000 - 0x000030ff] mem
Root Device compute_allocate_mem: base: 00003100 size: 00003100 align: 10 gran: 0 done
Done reading resources.
Setting resources...
Root Device compute_allocate_io: base: 00001000 size: 00000c84 align: 8 gran: 0
Root Device read_resources bus 0 link: 0
Root Device read_resources bus 0 link: 0 done
PCI: 00:1f.5 10 *  [0x00001000 - 0x000010ff] io
PCI: 00:1f.6 10 *  [0x00001400 - 0x000014ff] io
PCI: 00:1f.6 14 *  [0x00001800 - 0x0000187f] io
PCI: 00:1f.5 14 *  [0x00001880 - 0x000018bf] io
PCI: 00:1d.0 20 *  [0x000018c0 - 0x000018df] io
PCI: 00:1d.1 20 *  [0x000018e0 - 0x000018ff] io
PCI: 00:1d.2 20 *  [0x00001c00 - 0x00001c1f] io
PCI: 00:1f.3 20 *  [0x00001c20 - 0x00001c3f] io
PCI: 00:1f.1 20 *  [0x00001c40 - 0x00001c4f] io
PCI: 00:1f.1 10 *  [0x00001c50 - 0x00001c57] io
PCI: 00:1f.1 18 *  [0x00001c60 - 0x00001c67] io
PCI: 00:1f.1 14 *  [0x00001c70 - 0x00001c73] io
PCI: 00:1f.1 1c *  [0x00001c80 - 0x00001c83] io
Root Device compute_allocate_io: base: 00001c84 size: 00000c84 align: 8 gran: 0 done
Root Device compute_allocate_mem: base: febfcc00 size: 00003100 align: 10 gran: 0
Root Device read_resources bus 0 link: 0
Root Device read_resources bus 0 link: 0 done
PCI: 00:1d.7 10 *  [0xfebfd000 - 0xfebfd3ff] mem
PCI: 00:1f.1 24 *  [0xfebfe000 - 0xfebfe3ff] mem
PCI: 00:1f.5 18 *  [0xfebff000 - 0xfebff1ff] mem
PCI: 00:1f.5 1c *  [0xfec00000 - 0xfec000ff] mem
Root Device compute_allocate_mem: base: fec00100 size: 00003500 align: 10 gran: 0 done
Root Device assign_resources, bus 0 link: 0
Setting RAM size to 131072
PCI_DOMAIN: 0000 assign_resources, bus 0 link: 0
PCI: 00:1d.0 20 <- [0x00000018c0 - 0x00000018df] io
PCI: 00:1d.1 20 <- [0x00000018e0 - 0x00000018ff] io
PCI: 00:1d.2 20 <- [0x0000001c00 - 0x0000001c1f] io
PCI: 00:1d.7 10 <- [0x00febfd000 - 0x00febfd3ff] mem
PCI: 00:1f.0 assign_resources, bus 0 link: 0
PNP: 002e.4 60 <- [0x00000003f8 - 0x00000003ff] io
PNP: 002e.4 70 <- [0x0000000004 - 0x0000000004] irq
PNP: 002e.7 60 <- [0x0000000060 - 0x0000000060] io
PNP: 002e.7 62 <- [0x0000000064 - 0x0000000064] io
PNP: 002e.7 70 <- [0x0000000001 - 0x0000000001] irq
PNP: 002e.7 72 <- [0x000000000c - 0x000000000c] irq
PCI: 00:1f.0 assign_resources, bus 0 link: 0
PCI: 00:1f.1 10 <- [0x0000001c50 - 0x0000001c57] io
PCI: 00:1f.1 14 <- [0x0000001c70 - 0x0000001c73] io
PCI: 00:1f.1 18 <- [0x0000001c60 - 0x0000001c67] io
PCI: 00:1f.1 1c <- [0x0000001c80 - 0x0000001c83] io
PCI: 00:1f.1 20 <- [0x0000001c40 - 0x0000001c4f] io
PCI: 00:1f.1 24 <- [0x00febfe000 - 0x00febfe3ff] mem
PCI: 00:1f.3 20 <- [0x0000001c20 - 0x0000001c3f] io
PCI: 00:1f.5 10 <- [0x0000001000 - 0x00000010ff] io
PCI: 00:1f.5 14 <- [0x0000001880 - 0x00000018bf] io
PCI: 00:1f.5 18 <- [0x00febff000 - 0x00febff1ff] mem
PCI: 00:1f.5 1c <- [0x00fec00000 - 0x00fec000ff] mem
PCI: 00:1f.6 10 <- [0x0000001400 - 0x00000014ff] io
PCI: 00:1f.6 14 <- [0x0000001800 - 0x000000187f] io
PCI_DOMAIN: 0000 assign_resources, bus 0 link: 0
Root Device assign_resources, bus 0 link: 0
Done setting resources.
Done allocating resources.
Enabling resources...
PCI: 00:00.0 cmd <- 06
PCI: 00:1d.0 cmd <- 01
PCI: 00:1d.1 cmd <- 01
PCI: 00:1d.2 cmd <- 01
PCI: 00:1d.7 subsystem <- 00/00
PCI: 00:1d.7 cmd <- 02
PCI: 00:1e.0 bridge ctrl <- 0003
PCI: 00:1e.0 cmd <- 01
PCI: 00:1f.0 cmd <- 0f
PCI: 00:1f.1 cmd <- 03
PCI: 00:1f.3 subsystem <- 00/00
PCI: 00:1f.3 cmd <- 01
PCI: 00:1f.5 cmd <- 03
PCI: 00:1f.6 cmd <- 01
done.
Initializing devices...
Root Device init
PCI: 00:00.0 init
Northbridge init
PCI: 00:1d.0 init
PCI: 00:1d.1 init
PCI: 00:1d.2 init
PCI: 00:1d.7 init
EHCI: Setting up controller.. done.
PCI: 00:1e.0 init
PCI: 00:1f.0 init
IOAPIC Southbridge enabled 2186
Southbridge APIC ID = 0
APIC Error

From mvanderkolff at gmail.com  Tue Oct  2 02:20:08 2007
From: mvanderkolff at gmail.com (Michael van der Kolff)
Date: Tue, 2 Oct 2007 10:20:08 +1000
Subject: [LinuxBIOS] Gigabyte M61P-S3 board
In-Reply-To: <46FE3D5E.5050606@gmx.net>
References: <8233f01e0709282036g2e36de0bv2c9dca2e42e5f0ae@mail.gmail.com>
	<46FE3D5E.5050606@gmx.net>
Message-ID: <8233f01e0710011720i589d3425ied94a371effb3da@mail.gmail.com>

Hi, sorry for the late response, was on holidays.

I just used r2816 with linuxbios_flashrom_ite_spi_restructured3.diff,
along with the attached patch (which just adds the different it8716 id
used on the GA-M61P-S3 board) and got the following output from
flashrom -V -m gigabyte:m61ps3

Calibrating delay loop... 793M loops per second. ok
No LinuxBIOS table found.
WARNING: No chipset found. Flash detection will most likely fail.
Found board "GIGABYTE GA-M61P-S3": Enabling flash write... Serial
flash segment 0xfffe0000-0xffffffff enabled
Serial flash segment 0x000e0000-0x000fffff enabled
Serial flash segment 0xffee0000-0xffefffff disabled
Serial flash segment 0xfff80000-0xfffeffff enabled
LPC write to serial flash enabled
serial flash pin 29
OK.
Probing for Am29F040B, 512 KB
probe_29f040b: id1 0x49, id2 0x4d
Probing for Am29F016D, 2048 KB
probe_29f040b: id1 0xff, id2 0xff
Probing for AE49F2008, 256 KB
probe_jedec: id1 0xc6, id2 0x9b
Probing for At29C040A, 512 KB
probe_jedec: id1 0x49, id2 0x4d
Probing for At29C020, 256 KB
probe_jedec: id1 0xc6, id2 0x9b
Probing for Mx29f002, 256 KB
probe_29f002: id1 0xc6, id2 0x9b
Probing for MX25L4005, 512 KB
RDID returned c2 20 13
probe_spi: id1 0xc2, id2 0x2013
MX25L4005 found at physical address: 0xfff80000
Flash part is MX25L4005 (512 KB)
OK, only ENABLING flash write, but NOT FLASHING.

and the following output without -m gigabyte:m61ps3
Calibrating delay loop... 794M loops per second. ok
No LinuxBIOS table found.
WARNING: No chipset found. Flash detection will most likely fail.
Probing for Am29F040B, 512 KB
probe_29f040b: id1 0x49, id2 0x4d
Probing for Am29F016D, 2048 KB
probe_29f040b: id1 0xff, id2 0xff
Probing for AE49F2008, 256 KB
probe_jedec: id1 0xc6, id2 0x9b
Probing for At29C040A, 512 KB
probe_jedec: id1 0x49, id2 0x4d
Probing for At29C020, 256 KB
probe_jedec: id1 0xc6, id2 0x9b
Probing for Mx29f002, 256 KB
probe_29f002: id1 0xc6, id2 0x9b
Probing for MX25L4005, 512 KB
Probing for SST29EE020A, 256 KB
probe_jedec: id1 0xc6, id2 0x9b
Probing for SST28SF040A, 512 KB
probe_28sf040: id1 0x49, id2 0x4d
Probing for SST39SF010A, 128 KB
probe_jedec: id1 0xff, id2 0xff
Probing for SST39SF020A, 256 KB
probe_jedec: id1 0xc6, id2 0x9b
Probing for SST39SF040, 512 KB
probe_jedec: id1 0x49, id2 0x4d
Probing for SST39VF020, 256 KB
probe_jedec: id1 0xc6, id2 0x9b
Probing for SST49LF040B, 512 KB
probe_jedec: id1 0x49, id2 0x4d
Probing for SST49LF040, 512 KB
probe_jedec: id1 0x49, id2 0x4d
Probing for SST49LF020A, 256 KB
probe_jedec: id1 0xc6, id2 0x9b
Probing for SST49LF080A, 1024 KB
probe_jedec: id1 0xff, id2 0xff
Probing for SST49LF002A/B, 256 KB
probe_jedec: id1 0xc6, id2 0x9b
Probing for SST49LF003A/B, 384 KB
probe_jedec: id1 0x2e, id2 0x1f
Probing for SST49LF004A/B, 512 KB
probe_jedec: id1 0x49, id2 0x4d
Probing for SST49LF008A, 1024 KB
probe_jedec: id1 0xff, id2 0xff
Probing for SST49LF004C, 512 KB
probe_49lfxxxc: id1 0x49, id2 0x4d
Probing for SST49LF008C, 1024 KB
probe_49lfxxxc: id1 0xff, id2 0xff
Probing for SST49LF016C, 2048 KB
probe_49lfxxxc: id1 0xff, id2 0xff
Probing for SST49LF160C, 2048 KB
probe_49lfxxxc: id1 0xff, id2 0xff
Probing for Pm49FL002, 256 KB
probe_jedec: id1 0xc6, id2 0x9b
Probing for Pm49FL004, 512 KB
probe_jedec: id1 0x49, id2 0x4d
Probing for W29C011, 128 KB
probe_jedec: id1 0xff, id2 0xff
Probing for W29C040P, 512 KB
probe_jedec: id1 0x49, id2 0x4d
Probing for W29C020C, 256 KB
probe_jedec: id1 0xc6, id2 0x9b
Probing for W29EE011, 128 KB
probe_w29ee011: id1 0xff, id2 0xff
Probing for W49F002U, 256 KB
probe_jedec: id1 0xc6, id2 0x9b
Probing for W49V002A, 256 KB
probe_jedec: id1 0xc6, id2 0x9b
Probing for W49V002FA, 256 KB
probe_jedec: id1 0xc6, id2 0x9b
Probing for W39V040FA, 512 KB
probe_jedec: id1 0x49, id2 0x4d
Probing for W39V040A, 512 KB
probe_jedec: id1 0x49, id2 0x4d
Probing for W39V040B, 512 KB
probe_jedec: id1 0x49, id2 0x4d
Probing for W39V080A, 1024 KB
probe_jedec: id1 0xff, id2 0xff
Probing for M29F002B, 256 KB
probe_jedec: id1 0xc6, id2 0x9b
Probing for M50FW040, 512 KB
probe_jedec: id1 0x49, id2 0x4d
Probing for M29W040B, 512 KB
probe_jedec: id1 0x49, id2 0x4d
Probing for M29F002T/NT, 256 KB
probe_jedec: id1 0xc6, id2 0x9b
Probing for M29F400BT, 512 KB
probe_m29f400bt: id1 0x49, id2 0x44
Probing for M50FLW040A, 512 KB
probe_jedec: id1 0x49, id2 0x4d
Probing for M50FLW040B, 512 KB
probe_jedec: id1 0x49, id2 0x4d
Probing for M50FLW080A, 1024 KB
probe_jedec: id1 0xff, id2 0xff
Probing for M50FLW080B, 1024 KB
probe_jedec: id1 0xff, id2 0xff
Probing for M50FW080, 1024 KB
probe_jedec: id1 0xff, id2 0xff
Probing for M50FW016, 2048 KB
probe_jedec: id1 0xff, id2 0xff
Probing for M50LPW116, 2048 KB
probe_jedec: id1 0xff, id2 0xff
Probing for M29W010B, 128 KB
probe_jedec: id1 0xff, id2 0xff
Probing for M29F040B, 512 KB
probe_29f040b: id1 0x49, id2 0x4d
Probing for 82802ab, 512 KB
probe_82802ab: id1 0x49, id2 0x4d
Probing for 82802ac, 1024 KB
probe_82802ab: id1 0xff, id2 0xff
Probing for F49B002UA, 256 KB
probe_jedec: id1 0xc6, id2 0x9b
Probing for LHF00L04, 1024 KB
probe_lhf00l04: id1 0xff, id2 0xff
Probing for S29C51001T, 128 KB
probe_jedec: id1 0xff, id2 0xff
Probing for S29C51002T, 256 KB
probe_jedec: id1 0xc6, id2 0x9b
Probing for S29C51004T, 512 KB
probe_jedec: id1 0x49, id2 0x4d
Probing for S29C31004T, 512 KB
probe_jedec: id1 0x49, id2 0x4d
No EEPROM/flash device found.

Cheers,

Michael
On 9/29/07, Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006 at gmx.net> wrote:
> Hi,
>
> On 29.09.2007 05:36, Michael van der Kolff wrote:
> > Well, I was just inspecting this beautiful little M61P-S3 board, and
> > it has an SPI flash chip on it, in particular, the MX25L4005A.  I
> > don't seem to see anything that would indicate that anything but the
> > IT8716F would be connecting to it.
> >
> > I first tried using the version in Debian (testing):  It didn't detect
> > any flash chip.
> >
> > I then tried using the SVN version: It too didn't detect anything.
>
> Please try current svn with my patch (Subject: [PATCH] improved SPI
> flash support (restructured), date: Sat, 29 Sep 2007 04:08:45) on top of
> it and use your patched board enable for the GA-M57SLI.
>
> > Then I looked through, and found a reference to the M55.  I looked the
>
> GA-M57SLI?
>
> > archives, and found a message from May07:  I figured I would see if I
> > could get lucky telling it to look like an M55.
> >
> > I first got the connection to the IT8716F working, by telling it that
> > the M61 is just like an M55, except with PCI device id 0x03e0.  That
> > seemed to work.
> >
> > However, going from there, it doesn't seem to detect any SPI
> > functionality at all.
>
> Full log please.
>
> > It looks to me like support for each flash chip is needed (given that
> > the spec sheet gives commands to output the manufacturer ID & device
> > ID), but maybe that isn't true.  In any case, the command set is
> > relatively simple.
>
> I know. But the command set for each chip differs slightly, so full
> support is difficult.
>
> > Is the SPI stuff properly supported?  I feel like I'm a little out of
> > my depth on this code...
>
> I started last week to write support for SPI. It is in a really early
> stage and can only ID the chip (and with current svn, it will still say
> that no chip was found even if the ID could be read).
>
> Please run current svn flashrom in verbose mode (-V) and use your
> patched board enable. If possible, repeat this with my patch applied on top.
>
> Regards,
> Carl-Daniel
>



From mvanderkolff at gmail.com  Tue Oct  2 02:21:23 2007
From: mvanderkolff at gmail.com (Michael van der Kolff)
Date: Tue, 2 Oct 2007 10:21:23 +1000
Subject: [LinuxBIOS] Gigabyte M61P-S3 board
In-Reply-To: <8233f01e0710011720i589d3425ied94a371effb3da@mail.gmail.com>
References: <8233f01e0709282036g2e36de0bv2c9dca2e42e5f0ae@mail.gmail.com>
	<46FE3D5E.5050606@gmx.net>
	<8233f01e0710011720i589d3425ied94a371effb3da@mail.gmail.com>
Message-ID: <8233f01e0710011721y3172ca57yfcf828607a9ab0b7@mail.gmail.com>

Uhm, just forgot to attach the additional patch I applied.  Here it comes :)

Cheers,

Michael

On 10/2/07, Michael van der Kolff <mvanderkolff at gmail.com> wrote:
> Hi, sorry for the late response, was on holidays.
>
> I just used r2816 with linuxbios_flashrom_ite_spi_restructured3.diff,
> along with the attached patch (which just adds the different it8716 id
> used on the GA-M61P-S3 board) and got the following output from
> flashrom -V -m gigabyte:m61ps3
>
> Calibrating delay loop... 793M loops per second. ok
> No LinuxBIOS table found.
> WARNING: No chipset found. Flash detection will most likely fail.
> Found board "GIGABYTE GA-M61P-S3": Enabling flash write... Serial
> flash segment 0xfffe0000-0xffffffff enabled
> Serial flash segment 0x000e0000-0x000fffff enabled
> Serial flash segment 0xffee0000-0xffefffff disabled
> Serial flash segment 0xfff80000-0xfffeffff enabled
> LPC write to serial flash enabled
> serial flash pin 29
> OK.
> Probing for Am29F040B, 512 KB
> probe_29f040b: id1 0x49, id2 0x4d
> Probing for Am29F016D, 2048 KB
> probe_29f040b: id1 0xff, id2 0xff
> Probing for AE49F2008, 256 KB
> probe_jedec: id1 0xc6, id2 0x9b
> Probing for At29C040A, 512 KB
> probe_jedec: id1 0x49, id2 0x4d
> Probing for At29C020, 256 KB
> probe_jedec: id1 0xc6, id2 0x9b
> Probing for Mx29f002, 256 KB
> probe_29f002: id1 0xc6, id2 0x9b
> Probing for MX25L4005, 512 KB
> RDID returned c2 20 13
> probe_spi: id1 0xc2, id2 0x2013
> MX25L4005 found at physical address: 0xfff80000
> Flash part is MX25L4005 (512 KB)
> OK, only ENABLING flash write, but NOT FLASHING.
>
> and the following output without -m gigabyte:m61ps3
> Calibrating delay loop... 794M loops per second. ok
> No LinuxBIOS table found.
> WARNING: No chipset found. Flash detection will most likely fail.
> Probing for Am29F040B, 512 KB
> probe_29f040b: id1 0x49, id2 0x4d
> Probing for Am29F016D, 2048 KB
> probe_29f040b: id1 0xff, id2 0xff
> Probing for AE49F2008, 256 KB
> probe_jedec: id1 0xc6, id2 0x9b
> Probing for At29C040A, 512 KB
> probe_jedec: id1 0x49, id2 0x4d
> Probing for At29C020, 256 KB
> probe_jedec: id1 0xc6, id2 0x9b
> Probing for Mx29f002, 256 KB
> probe_29f002: id1 0xc6, id2 0x9b
> Probing for MX25L4005, 512 KB
> Probing for SST29EE020A, 256 KB
> probe_jedec: id1 0xc6, id2 0x9b
> Probing for SST28SF040A, 512 KB
> probe_28sf040: id1 0x49, id2 0x4d
> Probing for SST39SF010A, 128 KB
> probe_jedec: id1 0xff, id2 0xff
> Probing for SST39SF020A, 256 KB
> probe_jedec: id1 0xc6, id2 0x9b
> Probing for SST39SF040, 512 KB
> probe_jedec: id1 0x49, id2 0x4d
> Probing for SST39VF020, 256 KB
> probe_jedec: id1 0xc6, id2 0x9b
> Probing for SST49LF040B, 512 KB
> probe_jedec: id1 0x49, id2 0x4d
> Probing for SST49LF040, 512 KB
> probe_jedec: id1 0x49, id2 0x4d
> Probing for SST49LF020A, 256 KB
> probe_jedec: id1 0xc6, id2 0x9b
> Probing for SST49LF080A, 1024 KB
> probe_jedec: id1 0xff, id2 0xff
> Probing for SST49LF002A/B, 256 KB
> probe_jedec: id1 0xc6, id2 0x9b
> Probing for SST49LF003A/B, 384 KB
> probe_jedec: id1 0x2e, id2 0x1f
> Probing for SST49LF004A/B, 512 KB
> probe_jedec: id1 0x49, id2 0x4d
> Probing for SST49LF008A, 1024 KB
> probe_jedec: id1 0xff, id2 0xff
> Probing for SST49LF004C, 512 KB
> probe_49lfxxxc: id1 0x49, id2 0x4d
> Probing for SST49LF008C, 1024 KB
> probe_49lfxxxc: id1 0xff, id2 0xff
> Probing for SST49LF016C, 2048 KB
> probe_49lfxxxc: id1 0xff, id2 0xff
> Probing for SST49LF160C, 2048 KB
> probe_49lfxxxc: id1 0xff, id2 0xff
> Probing for Pm49FL002, 256 KB
> probe_jedec: id1 0xc6, id2 0x9b
> Probing for Pm49FL004, 512 KB
> probe_jedec: id1 0x49, id2 0x4d
> Probing for W29C011, 128 KB
> probe_jedec: id1 0xff, id2 0xff
> Probing for W29C040P, 512 KB
> probe_jedec: id1 0x49, id2 0x4d
> Probing for W29C020C, 256 KB
> probe_jedec: id1 0xc6, id2 0x9b
> Probing for W29EE011, 128 KB
> probe_w29ee011: id1 0xff, id2 0xff
> Probing for W49F002U, 256 KB
> probe_jedec: id1 0xc6, id2 0x9b
> Probing for W49V002A, 256 KB
> probe_jedec: id1 0xc6, id2 0x9b
> Probing for W49V002FA, 256 KB
> probe_jedec: id1 0xc6, id2 0x9b
> Probing for W39V040FA, 512 KB
> probe_jedec: id1 0x49, id2 0x4d
> Probing for W39V040A, 512 KB
> probe_jedec: id1 0x49, id2 0x4d
> Probing for W39V040B, 512 KB
> probe_jedec: id1 0x49, id2 0x4d
> Probing for W39V080A, 1024 KB
> probe_jedec: id1 0xff, id2 0xff
> Probing for M29F002B, 256 KB
> probe_jedec: id1 0xc6, id2 0x9b
> Probing for M50FW040, 512 KB
> probe_jedec: id1 0x49, id2 0x4d
> Probing for M29W040B, 512 KB
> probe_jedec: id1 0x49, id2 0x4d
> Probing for M29F002T/NT, 256 KB
> probe_jedec: id1 0xc6, id2 0x9b
> Probing for M29F400BT, 512 KB
> probe_m29f400bt: id1 0x49, id2 0x44
> Probing for M50FLW040A, 512 KB
> probe_jedec: id1 0x49, id2 0x4d
> Probing for M50FLW040B, 512 KB
> probe_jedec: id1 0x49, id2 0x4d
> Probing for M50FLW080A, 1024 KB
> probe_jedec: id1 0xff, id2 0xff
> Probing for M50FLW080B, 1024 KB
> probe_jedec: id1 0xff, id2 0xff
> Probing for M50FW080, 1024 KB
> probe_jedec: id1 0xff, id2 0xff
> Probing for M50FW016, 2048 KB
> probe_jedec: id1 0xff, id2 0xff
> Probing for M50LPW116, 2048 KB
> probe_jedec: id1 0xff, id2 0xff
> Probing for M29W010B, 128 KB
> probe_jedec: id1 0xff, id2 0xff
> Probing for M29F040B, 512 KB
> probe_29f040b: id1 0x49, id2 0x4d
> Probing for 82802ab, 512 KB
> probe_82802ab: id1 0x49, id2 0x4d
> Probing for 82802ac, 1024 KB
> probe_82802ab: id1 0xff, id2 0xff
> Probing for F49B002UA, 256 KB
> probe_jedec: id1 0xc6, id2 0x9b
> Probing for LHF00L04, 1024 KB
> probe_lhf00l04: id1 0xff, id2 0xff
> Probing for S29C51001T, 128 KB
> probe_jedec: id1 0xff, id2 0xff
> Probing for S29C51002T, 256 KB
> probe_jedec: id1 0xc6, id2 0x9b
> Probing for S29C51004T, 512 KB
> probe_jedec: id1 0x49, id2 0x4d
> Probing for S29C31004T, 512 KB
> probe_jedec: id1 0x49, id2 0x4d
> No EEPROM/flash device found.
>
> Cheers,
>
> Michael
> On 9/29/07, Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006 at gmx.net> wrote:
> > Hi,
> >
> > On 29.09.2007 05:36, Michael van der Kolff wrote:
> > > Well, I was just inspecting this beautiful little M61P-S3 board, and
> > > it has an SPI flash chip on it, in particular, the MX25L4005A.  I
> > > don't seem to see anything that would indicate that anything but the
> > > IT8716F would be connecting to it.
> > >
> > > I first tried using the version in Debian (testing):  It didn't detect
> > > any flash chip.
> > >
> > > I then tried using the SVN version: It too didn't detect anything.
> >
> > Please try current svn with my patch (Subject: [PATCH] improved SPI
> > flash support (restructured), date: Sat, 29 Sep 2007 04:08:45) on top of
> > it and use your patched board enable for the GA-M57SLI.
> >
> > > Then I looked through, and found a reference to the M55.  I looked the
> >
> > GA-M57SLI?
> >
> > > archives, and found a message from May07:  I figured I would see if I
> > > could get lucky telling it to look like an M55.
> > >
> > > I first got the connection to the IT8716F working, by telling it that
> > > the M61 is just like an M55, except with PCI device id 0x03e0.  That
> > > seemed to work.
> > >
> > > However, going from there, it doesn't seem to detect any SPI
> > > functionality at all.
> >
> > Full log please.
> >
> > > It looks to me like support for each flash chip is needed (given that
> > > the spec sheet gives commands to output the manufacturer ID & device
> > > ID), but maybe that isn't true.  In any case, the command set is
> > > relatively simple.
> >
> > I know. But the command set for each chip differs slightly, so full
> > support is difficult.
> >
> > > Is the SPI stuff properly supported?  I feel like I'm a little out of
> > > my depth on this code...
> >
> > I started last week to write support for SPI. It is in a really early
> > stage and can only ID the chip (and with current svn, it will still say
> > that no chip was found even if the ID could be read).
> >
> > Please run current svn flashrom in verbose mode (-V) and use your
> > patched board enable. If possible, repeat this with my patch applied on top.
> >
> > Regards,
> > Carl-Daniel
> >
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: m61p-s3.diff
Type: application/octet-stream
Size: 682 bytes
Desc: not available
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20071002/41b97e2d/attachment.obj>

From joe at smittys.pointclark.net  Tue Oct  2 02:21:37 2007
From: joe at smittys.pointclark.net (joe at smittys.pointclark.net)
Date: Mon, 01 Oct 2007 20:21:37 -0400
Subject: [LinuxBIOS] Problems with Filo booting - HELP
In-Reply-To: <20071001172326.10630.qmail@stuge.se>
References: <20070929165103.pcm220bn4s48sow8@smittys.pointclark.net>
	<20070929205527.GA16584@coresystems.de>
	<20070929170245.ata0hgegqowgcwgs@www.smittys.pointclark.net>
	<20070929201342.mifqbujb44ocwks8@smittys.pointclark.net>
	<46FF1CB2.60901@gmail.com>
	<20070930115720.mwni4u7go4wkk8wg@www.smittys.pointclark.net>
	<47000290.6020000@gmail.com>
	<20071001094827.loois4qr0g4ckw8o@www.smittys.pointclark.net>
	<13426df10710010950s379f8230y5b4ffec4da605f06@mail.gmail.com>
	<20071001172326.10630.qmail@stuge.se>
Message-ID: <20071001202137.mmhazz8uxa80sgwg@www.smittys.pointclark.net>

Quoting Peter Stuge <peter at stuge.se>:

> On Mon, Oct 01, 2007 at 09:50:04AM -0700, ron minnich wrote:
>> you might try forcing the size (in code) to 32M or some such in
>> hardwaremain.c and see if it works then.
>
> And/or set very conservative memory timings.
>
Not too sure how I can do this. Can you help me?

Thanks - Joe



From rminnich at gmail.com  Tue Oct  2 02:34:07 2007
From: rminnich at gmail.com (ron minnich)
Date: Mon, 1 Oct 2007 17:34:07 -0700
Subject: [LinuxBIOS] Problems with Filo booting - HELP
In-Reply-To: <20071001165858.vlz66uxpusgk0gww@www.smittys.pointclark.net>
References: <20070929165103.pcm220bn4s48sow8@smittys.pointclark.net>
	<20070929205527.GA16584@coresystems.de>
	<20070929170245.ata0hgegqowgcwgs@www.smittys.pointclark.net>
	<20070929201342.mifqbujb44ocwks8@smittys.pointclark.net>
	<46FF1CB2.60901@gmail.com>
	<20070930115720.mwni4u7go4wkk8wg@www.smittys.pointclark.net>
	<47000290.6020000@gmail.com>
	<20071001094827.loois4qr0g4ckw8o@www.smittys.pointclark.net>
	<13426df10710010950s379f8230y5b4ffec4da605f06@mail.gmail.com>
	<20071001165858.vlz66uxpusgk0gww@www.smittys.pointclark.net>
Message-ID: <13426df10710011734p292d050do6950fe8dc4802409@mail.gmail.com>

On 10/1/07, joe at smittys.pointclark.net <joe at smittys.pointclark.net> wrote:

> c. It is located in the second slot not first.

hmm. could this second slot somehow have a different base physical
address? unlikely but this is getting confusing.

ron



From joe at smittys.pointclark.net  Tue Oct  2 03:06:42 2007
From: joe at smittys.pointclark.net (joe at smittys.pointclark.net)
Date: Mon, 01 Oct 2007 21:06:42 -0400
Subject: [LinuxBIOS] Problems with Filo booting - HELP
In-Reply-To: <13426df10710011734p292d050do6950fe8dc4802409@mail.gmail.com>
References: <20070929165103.pcm220bn4s48sow8@smittys.pointclark.net>
	<20070929205527.GA16584@coresystems.de>
	<20070929170245.ata0hgegqowgcwgs@www.smittys.pointclark.net>
	<20070929201342.mifqbujb44ocwks8@smittys.pointclark.net>
	<46FF1CB2.60901@gmail.com>
	<20070930115720.mwni4u7go4wkk8wg@www.smittys.pointclark.net>
	<47000290.6020000@gmail.com>
	<20071001094827.loois4qr0g4ckw8o@www.smittys.pointclark.net>
	<13426df10710010950s379f8230y5b4ffec4da605f06@mail.gmail.com>
	<20071001165858.vlz66uxpusgk0gww@www.smittys.pointclark.net>
	<13426df10710011734p292d050do6950fe8dc4802409@mail.gmail.com>
Message-ID: <20071001210642.2ngf41s54wo0o04s@www.smittys.pointclark.net>

Quoting ron minnich <rminnich at gmail.com>:

> On 10/1/07, joe at smittys.pointclark.net <joe at smittys.pointclark.net> wrote:
>
>> c. It is located in the second slot not first.
>
> hmm. could this second slot somehow have a different base physical
> address? unlikely but this is getting confusing.
>
> ron
>
I don't think so. Your telling me. I am so confused right now I'm  
starting to get a migrane. I can't for the life of me figure out why  
this is choking. Everything seems to be ok right up to the  
jmp_to_elf_entry() function. Then it chokes at the assembly part. Does  
that make sense??


Thanks - Joe



From jordan.crouse at amd.com  Tue Oct  2 03:17:56 2007
From: jordan.crouse at amd.com (Jordan Crouse)
Date: Mon, 1 Oct 2007 19:17:56 -0600
Subject: [LinuxBIOS] Problems with Filo booting - HELP
In-Reply-To: <20071001210642.2ngf41s54wo0o04s@www.smittys.pointclark.net>
References: <20070929170245.ata0hgegqowgcwgs@www.smittys.pointclark.net>
	<20070929201342.mifqbujb44ocwks8@smittys.pointclark.net>
	<46FF1CB2.60901@gmail.com>
	<20070930115720.mwni4u7go4wkk8wg@www.smittys.pointclark.net>
	<47000290.6020000@gmail.com>
	<20071001094827.loois4qr0g4ckw8o@www.smittys.pointclark.net>
	<13426df10710010950s379f8230y5b4ffec4da605f06@mail.gmail.com>
	<20071001165858.vlz66uxpusgk0gww@www.smittys.pointclark.net>
	<13426df10710011734p292d050do6950fe8dc4802409@mail.gmail.com>
	<20071001210642.2ngf41s54wo0o04s@www.smittys.pointclark.net>
Message-ID: <20071002011756.GA23110@cosmic.amd.com>

On 01/10/07 21:06 -0400, joe at smittys.pointclark.net wrote:
> Quoting ron minnich <rminnich at gmail.com>:
> 
> > On 10/1/07, joe at smittys.pointclark.net <joe at smittys.pointclark.net> wrote:
> >
> >> c. It is located in the second slot not first.
> >
> > hmm. could this second slot somehow have a different base physical
> > address? unlikely but this is getting confusing.
> >
> > ron
> >
> I don't think so. Your telling me. I am so confused right now I'm  
> starting to get a migrane. I can't for the life of me figure out why  
> this is choking. Everything seems to be ok right up to the  
> jmp_to_elf_entry() function. Then it chokes at the assembly part. Does  
> that make sense??

Absolutely - if your memory is hosed, this will be the first place that
you'll run afowl of it, especially when it comes to the top of memory.
Because whats happening at this point is that LinuxBIOS is copying some
part of itself to the top of memory to make room for the payload.  If
your memory map is wierd, then this will easily be the first place where
it will be exposed.

Jordan

-- 
Jordan Crouse
Systems Software Development Engineer 
Advanced Micro Devices, Inc.





From uwe at hermann-uwe.de  Tue Oct  2 03:16:59 2007
From: uwe at hermann-uwe.de (Uwe Hermann)
Date: Tue, 2 Oct 2007 03:16:59 +0200
Subject: [LinuxBIOS] linuxbios support for thinkpads?
In-Reply-To: <20070925015420.27557.qmail@stuge.se>
References: <a698c16a0709181249q5a2ddf3dr2f452ad8acb5a493@mail.gmail.com>
	<20070918210622.GF6506@greenwood>
	<a698c16a0709181541v14694292q2c5dd08c3653308c@mail.gmail.com>
	<46F05961.8070803@gmail.com> <20070919200249.11128.qmail@stuge.se>
	<a698c16a0709201518v4cc3c1a3j44f9e461e08f512@mail.gmail.com>
	<20070920230840.30993.qmail@stuge.se>
	<20070921145955.GA11153@greenwood>
	<a698c16a0709240116t433ad588g7afcdc8e9b57e2@mail.gmail.com>
	<20070925015420.27557.qmail@stuge.se>
Message-ID: <20071002011659.GG9669@greenwood>

On Tue, Sep 25, 2007 at 03:54:20AM +0200, Peter Stuge wrote:
> On Mon, Sep 24, 2007 at 04:16:32AM -0400, Robinson Tryon wrote:
> > It's great to hear that AMD is so supportive of this project.
> ..
> > laptop
> 
> This was discussed on IRC shortly after Mark's post. For now, the

Which post? URL?


> graphics hardware simply isn't there to serve this market.
> 
> LB can run the binary VGA BIOS in the emulator for init but for
> operation going through legacy drivers/APIs is not the right way.

Sure, it's not ideal, but as a temporary "hack" until we have something
better -- why not?

Maybe a totally-free-laptop-from-scratch won't happen very soon, but
an existing laptop with supported chipset, superio, EC and socketed ROM
would be a (relatively) easy target to at least support _some_ laptop
at all...

Personally, I would be really happy to see something like this happen.


Uwe.
-- 
http://www.hermann-uwe.de  | http://www.holsham-traders.de
http://www.crazy-hacks.org | http://www.unmaintained-free-software.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20071002/4571712f/attachment.sig>

From jonathansturges at yahoo.com  Tue Oct  2 03:20:16 2007
From: jonathansturges at yahoo.com (Jonathan Sturges)
Date: Mon, 1 Oct 2007 18:20:16 -0700 (PDT)
Subject: [LinuxBIOS] Two more CS5530 IRQ steering questions
Message-ID: <792231.90378.qm@web35903.mail.mud.yahoo.com>



----- Original Message ----
From: Marc Jones <marc.jones at amd.com>
To: Jonathan Sturges <jonathansturges at yahoo.com>
Cc: LinuxBIOS mailing list <linuxbios at linuxbios.org>
Sent: Tuesday, September 25, 2007 12:05:19 PM
Subject: Re: [LinuxBIOS] Two more CS5530 IRQ steering questions



Jonathan Sturges wrote:
>>> Jonathan Sturges wrote:
>>> Two additional questions about CS5530 IRQ steering:
>>> 1)  Comments from Uwe Hermann and Peter Stuge have indicated that it's really better for the kernel to setup the steering registers.  Why is this?  It sounds like the BIOS is a good place to set these.  I assume that a knowledgeable OS could change them if necessary?  At the very least, it does sound like we all agree that it's OK to have LB setup the steering until Linux is fixed.
>>>
>>> 2)  Question about irq_tables.c.  Many of the CS5536 systems have a write_pirq_routing_table() in irq_tables.c that sets the steering registers.  I'd like to be able to set the steering registers in CS5530 systems too, but I'm not a software developer and I need some help.  So in src/mainboard/artecgroup/dbe61/irq_tables.c, you have:
>>> /* Set up chipset IRQ steering. */
>>> pciAddr = 0x80000000 | (CHIPSET_DEV_NUM << 11) | 0x5C;
>>> chipset_irq_map = (PIRQD << 12 | PIRQC << 8 | PIRQB << 4 | PIRQA);
>>> printk_debug("%s(%08X, %04X)\n", __FUNCTION__, pciAddr,
>>>               chipset_irq_map);
>>> outl(pciAddr & ~3, 0xCF8);
>>> outl(chipset_irq_map, 0xCFC);My main question with this block of code is what the two outl() calls are for.  It looks like pciAddr gets the address of the 0x5c steering register, and chipset_irq_map sets the right bits to set all 4 PIRQ lines.  But I'd expect to see the chipset_irq_map written to pciAddr.
>>>
>>> As an alternative, Kenji Noguchi used this code block to set the registers in a CS5530 system he's working on (posted 5-May-2007):
>>> device_t pdev;
>>> //CS5530A
>>> pdev = dev_find_slot(0, (0x12 << 3) + 0);
>>> pci_write_config8(pdev, 0x5c, 0xab);
>>> pci_write_config8(pdev, 0x5d, 0x09);
>>>
>>>
>>> This block makes more sense to me.  Obviously the register values could be set by 
>>> #defines, but it looks simpler to me.
>>>
>>> Bottom line is, before I implement IRQ steering for my CS5530 system, I want to understand what the first code block is doing, and if (or why) it's preferable over the 2nd code block.  Any guidance is appreciated.
>>>
>>> thanks,
>>> Jonathan
>>   
>>
>> outl(pciAddr & ~3, 0xCF8);
>> outl(chipset_irq_map, 0xCFC)
>>
>> is basically the same as
>>
>> pci_write_config8(pdev, 0x5c, 0xab);
>> pci_write_config8(pdev, 0x5d, 0x09);
>>
>>
>> CFC/CF8 is the PCI config space.
> 
> Ahhh... thanks Marc, that was the clarification I needed.
> 
> With that in mind, that block of code should work directly with the CS5530 after defining CHIPSET_DEV_NUM appropriately.  What about '0x80000000', is that a common base address applicable to all CS553x systems?
> 
> thanks,
> Jonathan

DEV_NUM should be a constant for the 5530. It is always hooked up on the 
same IDSEL. The 0x80000000 is standard for all i/o based PCI config 
accesses. It indicates that it is a config access and not just a normal 
PCI i/o access.

Marc



Marc,
I've implemented the CS5536-style IRQ steering register code from above in my CS5530 system.  This is what I'm using:
/* Set up chipset IRQ steering. */
pciAddr = 0x80000000 | (0x12 << 11) | 0x5C;
chipset_irq_map = (PIRQD << 12 | PIRQC << 8 | PIRQB << 4 | PIRQA);
printk_debug("%s(%08X, %04X)\n", __FUNCTION__, pciAddr,
               chipset_irq_map);
outl(pciAddr & ~3, 0xCF8);
outl(chipset_irq_map, 0xCFC);

However, it doesn't seem to have worked entirely.  If it had worked, I assume I should be able to boot a standard Linux kernel and have IRQs worked for the devices in the PIRQ table.  Instead, these devices don't work, unless I boot a kernel with the CS5530 IRQ router patch.
In the LB output, you get this from write_pirq_routing_table():

write_pirq_routing_table(8000905C, 99BA)

...which I think is right.  It doesn't seem like there's much that could be wrong here.  Are the the steering bits reversed maybe?  The high 8 bits are for PIRQD and C, so that would screw things up if they were written to 0x5C, which is the INTB/INTA register.  Is there a reliable way to see the settings of the steering bits from a running system?

thanks,
Jonathan






       
____________________________________________________________________________________
Boardwalk for $500? In 2007? Ha! Play Monopoly Here and Now (it's updated for today's economy) at Yahoo! Games.
http://get.games.yahoo.com/proddesc?gamekey=monopolyherenow  



From kbaski at yahoo.com  Tue Oct  2 03:23:01 2007
From: kbaski at yahoo.com (Baski)
Date: Mon, 1 Oct 2007 18:23:01 -0700 (PDT)
Subject: [LinuxBIOS] LB-v2 version for A8NE-FM
In-Reply-To: <mailman.688.1191284493.4548.linuxbios@linuxbios.org>
Message-ID: <451790.22865.qm@web51607.mail.re2.yahoo.com>

What's a good version of LBv2 to flash on A8NE-FM?
Thx

       
---------------------------------
Pinpoint customers who are looking for what you sell. 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20071001/c11f794a/attachment.html>

From joe at smittys.pointclark.net  Tue Oct  2 04:09:40 2007
From: joe at smittys.pointclark.net (joe at smittys.pointclark.net)
Date: Mon, 01 Oct 2007 22:09:40 -0400
Subject: [LinuxBIOS] Problems with Filo booting - HELP
In-Reply-To: <20071002011756.GA23110@cosmic.amd.com>
References: <20070929170245.ata0hgegqowgcwgs@www.smittys.pointclark.net>
	<20070929201342.mifqbujb44ocwks8@smittys.pointclark.net>
	<46FF1CB2.60901@gmail.com>
	<20070930115720.mwni4u7go4wkk8wg@www.smittys.pointclark.net>
	<47000290.6020000@gmail.com>
	<20071001094827.loois4qr0g4ckw8o@www.smittys.pointclark.net>
	<13426df10710010950s379f8230y5b4ffec4da605f06@mail.gmail.com>
	<20071001165858.vlz66uxpusgk0gww@www.smittys.pointclark.net>
	<13426df10710011734p292d050do6950fe8dc4802409@mail.gmail.com>
	<20071001210642.2ngf41s54wo0o04s@www.smittys.pointclark.net>
	<20071002011756.GA23110@cosmic.amd.com>
Message-ID: <20071001220940.114u4tvvs484woc4@www.smittys.pointclark.net>

Quoting Jordan Crouse <jordan.crouse at amd.com>:

> On 01/10/07 21:06 -0400, joe at smittys.pointclark.net wrote:
>> Quoting ron minnich <rminnich at gmail.com>:
>>
>> > On 10/1/07, joe at smittys.pointclark.net <joe at smittys.pointclark.net> wrote:
>> >
>> >> c. It is located in the second slot not first.
>> >
>> > hmm. could this second slot somehow have a different base physical
>> > address? unlikely but this is getting confusing.
>> >
>> > ron
>> >
>> I don't think so. Your telling me. I am so confused right now I'm
>> starting to get a migrane. I can't for the life of me figure out why
>> this is choking. Everything seems to be ok right up to the
>> jmp_to_elf_entry() function. Then it chokes at the assembly part. Does
>> that make sense??
>
> Absolutely - if your memory is hosed, this will be the first place that
> you'll run afowl of it, especially when it comes to the top of memory.
> Because whats happening at this point is that LinuxBIOS is copying some
> part of itself to the top of memory to make room for the payload.  If
> your memory map is wierd, then this will easily be the first place where
> it will be exposed.
>
> Jordan
>
LinuxBIOS does get copied to TOM? From looking at the code it just  
looks like it just doubles LB's size and then copies it there (bounce  
buffer). If it is getting copied to TOM that explains everything. The  
Internal graphics is supposed to pre-allocate memory from TOM down.  
 From the i82830 datasheet:

--------------------------------------------
These Register Bits control the theft of memory from Main Memory space  
for use as Graphics memory. The memory for TSEG is pre-allocated first  
and then the Graphics memory is pre-allocated. An example of this  
theft mechanism is:

TOM equal 64 MB,
TSEG selected as 512 KB in size,
Graphics memory selected as 1 MB in size
General System RAM available in system = 62.5 MB
General System RAM Range             00000000h to 03E7FFFFh
TSEG Address Range                   03F80000h to 03FFFFFFh
TSEG pre-allocated from              03F80000h to 03FFFFFFh
Graphics memory pre-allocated from   03E80000h to 03F7FFFFh
-----------------------------------------------

I don't have TSEG enabled though. I wonder if I did though, it would  
give LB extra space for it's bounce buffer?? Does this make any sense?

Thanks - Joe



From bishop.robinson at gmail.com  Tue Oct  2 05:31:08 2007
From: bishop.robinson at gmail.com (Robinson Tryon)
Date: Mon, 1 Oct 2007 23:31:08 -0400
Subject: [LinuxBIOS] Call for help: superiotool
In-Reply-To: <46FBDB3E.4000009@gmx.net>
References: <20070923111315.GC12926@greenwood>
	<a698c16a0709270921l860615dv3ebe8d49e2f4c791@mail.gmail.com>
	<46FBDB3E.4000009@gmx.net>
Message-ID: <a698c16a0710012031x5af41d62n1be7e54f0cfb2a5e@mail.gmail.com>

On 9/27/07, Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006 at gmx.net> wrote:
> Not supported by superiotool, however if there was any output at all,
> we'd like to know it. That alone would probably help us identify the
> Super I/O, and from there, adding support is rather easy.

Dell XPS Inspiron PP09L

ubuntu at ubuntu:~$ sudo ./superiotool -v
superiotool 0.1
ubuntu at ubuntu:~$ sudo ./superiotool -V
No Super I/O chip found at 0x002e
No Super I/O chip found at 0x004e
No Super I/O chip found at 0x002e
No Super I/O chip found at 0x004e
Probing 0x002e, failed (0x22), data returns 0x00
Probing 0x002e, failed (0x22), data returns 0x00
No Super I/O chip found at 0x004e
No Super I/O chip found at 0x004e
Probing 0x002e, failed (0x0e), data returns 0x00
Probing 0x002e, failed (0x21), data returns 0x11
No Super I/O chip found at 0x004e
No Super I/O chip found at 0x004e
No Super I/O chip found at 0x03f0
No Super I/O chip found at 0x03f0
No Super I/O chip found at 0x0370
No Super I/O chip found at 0x0370
No Super I/O chip found at 0x002e
No Super I/O chip found at 0x002e
No Super I/O chip found at 0x002e
No Super I/O chip found at 0x002e
No Super I/O chip found at 0x004e
No Super I/O chip found at 0x004e
No Super I/O chip found at 0x004e
No Super I/O chip found at 0x004e
No Super I/O chip found at 0x03f0
No Super I/O chip found at 0x03f0
No Super I/O chip found at 0x03f0
No Super I/O chip found at 0x03f0
No Super I/O chip found at 0x0370
No Super I/O chip found at 0x0370
No Super I/O chip found at 0x0370
No Super I/O chip found at 0x0370
No Super I/O chip found at 0x0250
No Super I/O chip found at 0x0250
No Super I/O chip found at 0x0250
No Super I/O chip found at 0x0250



From bishop.robinson at gmail.com  Tue Oct  2 05:34:05 2007
From: bishop.robinson at gmail.com (Robinson Tryon)
Date: Mon, 1 Oct 2007 23:34:05 -0400
Subject: [LinuxBIOS] Call for help: superiotool
In-Reply-To: <46FBDB3E.4000009@gmx.net>
References: <20070923111315.GC12926@greenwood>
	<a698c16a0709270921l860615dv3ebe8d49e2f4c791@mail.gmail.com>
	<46FBDB3E.4000009@gmx.net>
Message-ID: <a698c16a0710012034i25dec2deq1a07b8eb570f3d97@mail.gmail.com>

On 9/27/07, Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006 at gmx.net> wrote:
> Not supported by superiotool, however if there was any output at all,
> we'd like to know it. That alone would probably help us identify the
> Super I/O, and from there, adding support is rather easy.

System Information
        Manufacturer: Dell Computer Corporation
        Product Name: OptiPlex GX1 400MTbr+

# ./superiotool -v
superiotool r2815?2@
# ./superiotool -V
Probing for ALi Super I/O at 0x3f0... failed
Probing for ALi Super I/O at 0x370... failed
Super I/O found at 0x2e: id = 0xe0
<unknown>
No dump for 0xe0
Probing for NSC Super I/O at 0x4e... failed
Probing 0x2e, failed (0x24), data returns 0x00
Probing for Fintek Super I/O at 0x4e... failed
Probing 0x2e, failed (0x22), data returns 0x70
Probing 0x2e, failed (0x22), data returns 0x70
Probing for ITE Super I/O (init=0x87,0x01,0x55,0x55/0xaa) at 0x4e... failed
Probing for ITE Super I/O (init=0x87,0x87) at 0x4e... failed
Probing 0x2e, failed (0x21), data returns 0x0f
Probing 0x2e, failed (0x0e), data returns 0x00
Probing for SMSC Super I/O at 0x4e... failed
Probing for SMSC Super I/O at 0x4e... failed
Probing for SMSC Super I/O at 0x3f0... failed
Probing for SMSC Super I/O at 0x3f0... failed
Probing for SMSC Super I/O at 0x370... failed
Probing for SMSC Super I/O at 0x370... failed
Probing 0x2e, failed (0x09), data returns 0x00
Probing 0x2e, failed (0x09), data returns 0x00
Probing 0x2e, failed (0x09), data returns 0x00
Probing 0x2e, failed (0x09), data returns 0x00
Probing for Winbond Super I/O (init=0x88) at 0x4e... failed
Probing for Winbond Super I/O (init=0x89) at 0x4e... failed
Probing for Winbond Super I/O (init=0x86,0x86) at 0x4e... failed
Probing for Winbond Super I/O (init=0x87,0x87) at 0x4e... failed
Probing for Winbond Super I/O (init=0x88) at 0x3f0... failed
Probing for Winbond Super I/O (init=0x89) at 0x3f0... failed
Probing for Winbond Super I/O (init=0x86,0x86) at 0x3f0... failed
Probing for Winbond Super I/O (init=0x87,0x87) at 0x3f0... failed
Probing for Winbond Super I/O (init=0x88) at 0x370... failed
Probing for Winbond Super I/O (init=0x89) at 0x370... failed
Probing for Winbond Super I/O (init=0x86,0x86) at 0x370... failed
Probing for Winbond Super I/O (init=0x87,0x87) at 0x370... failed
Probing for Winbond Super I/O (init=0x88) at 0x250... failed
Probing for Winbond Super I/O (init=0x89) at 0x250... failed
Probing for Winbond Super I/O (init=0x86,0x86) at 0x250... failed
Probing for Winbond Super I/O (init=0x87,0x87) at 0x250... failed



From bishop.robinson at gmail.com  Tue Oct  2 05:37:20 2007
From: bishop.robinson at gmail.com (Robinson Tryon)
Date: Mon, 1 Oct 2007 23:37:20 -0400
Subject: [LinuxBIOS] Call for help: superiotool
In-Reply-To: <46FBDB3E.4000009@gmx.net>
References: <20070923111315.GC12926@greenwood>
	<a698c16a0709270921l860615dv3ebe8d49e2f4c791@mail.gmail.com>
	<46FBDB3E.4000009@gmx.net>
Message-ID: <a698c16a0710012037l37bc9d07i6628563002d7e47a@mail.gmail.com>

On 9/27/07, Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006 at gmx.net> wrote:
> Not supported by superiotool, however if there was any output at all,
> we'd like to know it. That alone would probably help us identify the
> Super I/O, and from there, adding support is rather easy.

System Information
        Manufacturer: TOSHIBA
        Product Name: Satellite 1415
        Version: PS141U-1ZCF4V

$ sudo ./superiotool -v
superiotool r2815
$ sudo ./superiotool -V
Probing for ALi Super I/O at 0x3f0... failed
Probing for ALi Super I/O at 0x370... failed
Probing for NSC Super I/O at 0x2e... failed
Probing for NSC Super I/O at 0x4e... failed
Probing for Fintek Super I/O at 0x2e... failed
Probing for Fintek Super I/O at 0x4e... failed
Probing 0x2e, failed (0x22), data returns 0x04
Probing 0x2e, failed (0x22), data returns 0x04
Probing for ITE Super I/O (init=0x87,0x01,0x55,0x55/0xaa) at 0x4e... failed
Probing for ITE Super I/O (init=0x87,0x87) at 0x4e... failed
Probing 0x2e, failed (0x21), data returns 0x00
Probing 0x2e, failed (0x0e), data returns 0x00
Probing for SMSC Super I/O at 0x4e... failed
Probing for SMSC Super I/O at 0x4e... failed
Probing for SMSC Super I/O at 0x3f0... failed
Probing for SMSC Super I/O at 0x3f0... failed
Probing for SMSC Super I/O at 0x370... failed
Probing for SMSC Super I/O at 0x370... failed
Probing for Winbond Super I/O (init=0x88) at 0x2e... failed
Probing for Winbond Super I/O (init=0x89) at 0x2e... failed
Probing for Winbond Super I/O (init=0x86,0x86) at 0x2e... failed
Probing for Winbond Super I/O (init=0x87,0x87) at 0x2e... failed
Probing for Winbond Super I/O (init=0x88) at 0x4e... failed
Probing for Winbond Super I/O (init=0x89) at 0x4e... failed
Probing for Winbond Super I/O (init=0x86,0x86) at 0x4e... failed
Probing for Winbond Super I/O (init=0x87,0x87) at 0x4e... failed
Probing for Winbond Super I/O (init=0x88) at 0x3f0... failed
Probing for Winbond Super I/O (init=0x89) at 0x3f0... failed
Probing for Winbond Super I/O (init=0x86,0x86) at 0x3f0... failed
Probing for Winbond Super I/O (init=0x87,0x87) at 0x3f0... failed
Probing for Winbond Super I/O (init=0x88) at 0x370... failed
Probing for Winbond Super I/O (init=0x89) at 0x370... failed
Probing for Winbond Super I/O (init=0x86,0x86) at 0x370... failed
Probing for Winbond Super I/O (init=0x87,0x87) at 0x370... failed
Probing for Winbond Super I/O (init=0x88) at 0x250... failed
Probing for Winbond Super I/O (init=0x89) at 0x250... failed
Probing for Winbond Super I/O (init=0x86,0x86) at 0x250... failed
Probing for Winbond Super I/O (init=0x87,0x87) at 0x250... failed



From bios at ryven.de  Tue Oct  2 08:22:48 2007
From: bios at ryven.de (Markus)
Date: Tue, 2 Oct 2007 06:22:48 +0000
Subject: [LinuxBIOS] Supertek ST-3ET
In-Reply-To: <13426df10710011004t2714966bvd32d753858e7470c@mail.gmail.com>
References: <200709301924.39334.bios@ryven.de>
	<13426df10710011004t2714966bvd32d753858e7470c@mail.gmail.com>
Message-ID: <20071002062248.165be78d@PXE-Image>

Am Mon, 1 Oct 2007 10:04:41 -0700
schrieb "ron minnich" <rminnich at gmail.com>:

> On 9/30/07, Markus Boas <bios at ryven.de> wrote:
> 
> > rom_stream: 0xfffc0000 - 0xfffcffff
> > No header at 0
> > ...
> > ...
> > ...
> > No header at 8096
> > header_offset is -1
> > Can not load ELF
> 
> so it can not find any elf image. Your part is 256KB, right? you're
> sure it is not 512KiB for example?

The Flash is a Amd Am29F040B, this should be a 512 KB, or I'm wrong.
The orginal Flash ist only a 256 KB, but LB boots so this souldn't
boarder. 
> 
> 
> > option ROM_SIZE=512*1024
> >
> 
> oh but it is! The search is starting at fffc0000 and it should start
> at fff80000. that's your problem.
> 
> But why is the elf loader doing that? I can not recall what would make
> it do this. Let me know if you find it, if not, I can try to look.
> 
> ron
> 

In the config file I change the ROM_Size, but I don't know the right
value for the ROM_IMAGE_SIZE. The 0x10000 build but it was the right
value for the 256 KB flash. A doubel to 0x20000 would not build.

Markus



From corey.osgood at gmail.com  Tue Oct  2 08:22:25 2007
From: corey.osgood at gmail.com (Corey Osgood)
Date: Tue, 02 Oct 2007 02:22:25 -0400
Subject: [LinuxBIOS] Supertek ST-3ET
In-Reply-To: <20071002062248.165be78d@PXE-Image>
References: <200709301924.39334.bios@ryven.de>	<13426df10710011004t2714966bvd32d753858e7470c@mail.gmail.com>
	<20071002062248.165be78d@PXE-Image>
Message-ID: <4701E3A1.80509@gmail.com>

Markus wrote:
> In the config file I change the ROM_Size, but I don't know the right
> value for the ROM_IMAGE_SIZE. The 0x10000 build but it was the right
> value for the 256 KB flash. A doubel to 0x20000 would not build.
>
> Markus
>   

ROM_IMAGE_SIZE is decieving, it's the amount of space to allow LinuxBIOS
(not including the payload) to occupy, for each image (normal/fallback).
It's safe to leave it as 0x10000, or increment as necessary if LB needs
more room, but LB doesn't like to have TOO much room. Whatever space is
left over can be used for a payload or left empty.

-Corey



From bgiraut at gmail.com  Tue Oct  2 12:04:07 2007
From: bgiraut at gmail.com (giraut benoit)
Date: Tue, 2 Oct 2007 12:04:07 +0200
Subject: [LinuxBIOS] LinuxBios on a HP ePC C10 to speed up boot time
Message-ID: <272757430710020304lf39148eld1bc435b7e3d0ce2@mail.gmail.com>

Hello

Is it possible to use linuxbios on a ePC C10 computer ?  it is using
Intel Whitney 82810E that is supported now by linuxbios.

The original bios take horrible long time to boot  (~13 secondes to
get the HP splash screen).
Do you think the linuxbios can speedup the boot time or it is a
hardware problem ?

Thx for your help

benoit



From idwer_v at hotmail.com  Tue Oct  2 15:07:00 2007
From: idwer_v at hotmail.com (Idwer Vollering)
Date: Tue, 2 Oct 2007 13:07:00 +0000
Subject: [LinuxBIOS]  440BX progress / superio w83977tf-aw
Message-ID: <BLU102-W1142FAFAADAABA86DB06C78BAE0@phx.gbl>


http://linuxbios.org/pipermail/linuxbios/2006-November/017262.html

It boots (v2 r2811), but serial outputs says "Can not load ELF Image." which is correct because i didn't yet manage to get filo appended as a payload from targets/asus/p2b/Config.lb.

What options in Config.lb must be set to create enough space to include filo.elf (about 94 KB) using both normal and fallback sections; option ROM_IMAGE_SIZE = (some_substracted_size) * 1024 ?

Also, superio (from r2811) won't recognize the onboard winbond w83977tf-aw.
_________________________________________________________________
De mooiste afbeeldingen van Angelina Jolie vind je met Live Search
http://search.live.com/images/results.aspx?q=angelina%20jolie&FORM=QBIR
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20071002/a8787ada/attachment.html>

From idwer_v at hotmail.com  Tue Oct  2 15:21:23 2007
From: idwer_v at hotmail.com (Idwer Vollering)
Date: Tue, 2 Oct 2007 13:21:23 +0000
Subject: [LinuxBIOS] FW:   440BX progress / superio w83977tf-aw
In-Reply-To: <BLU102-W609EAA2C2EB0A2D789C9CD8BAE0@phx.gbl>
References: <BLU102-W609EAA2C2EB0A2D789C9CD8BAE0@phx.gbl>
Message-ID: <BLU102-W432269A73B18A6665AEB408BAE0@phx.gbl>


Forgot to attach configfiles+minicom-log
From: idwer_v at hotmail.com
To: uwe at hermann-uwe.de
Date: Tue, 2 Oct 2007 13:07:00 +0000
CC: linuxbios at linuxbios.org
Subject: [LinuxBIOS]  440BX progress / superio w83977tf-aw

http://linuxbios.org/pipermail/linuxbios/2006-November/017262.html

It boots (v2 r2811), but serial outputs says 'Can not load ELF Image.' which is correct because i didn't yet manage to get filo appended as a payload from targets/asus/p2b/Config.lb.

What options in Config.lb must be set to create enough space to include filo.elf (about 94 KB) using both normal and fallback sections; option ROM_IMAGE_SIZE = (some_substracted_size) * 1024 ?

Also, superio (from r2811) won't recognize the onboard winbond w83977tf-aw.
Windows Live Mail: Nu 2gb aan opslag - dat zijn maar liefst 1000 foto's - en nog steeds gratis! Windows Live Mail
Publiceer JOUW leven online met Windows Live Spaces: weblog, foto, video en muziek! Het is gratis! Het is gratis!

_________________________________________________________________
Probeer Live.nl 
Probeer Live.nl: zoekmachine van de makers van MSN! 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20071002/d3e038f6/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: minicom.cap-2007_10_01_2145
Type: application/octet-stream
Size: 27561 bytes
Desc: not available
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20071002/d3e038f6/attachment.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: src_mainboard_asus_p2b-Config.lb
Type: application/octet-stream
Size: 3811 bytes
Desc: not available
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20071002/d3e038f6/attachment-0001.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: targets_asus_p2b-Config.lb
Type: application/octet-stream
Size: 520 bytes
Desc: not available
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20071002/d3e038f6/attachment-0002.obj>

From rasmus at wiman.org  Tue Oct  2 15:29:38 2007
From: rasmus at wiman.org (Rasmus Wiman)
Date: Tue, 2 Oct 2007 15:29:38 +0200
Subject: [LinuxBIOS] Call for help: superiotool
In-Reply-To: <20070923111315.GC12926@greenwood>
References: <20070923111315.GC12926@greenwood>
Message-ID: <20071002152938.084fdaef.rasmus@wiman.org>

Uwe Hermann <uwe at hermann-uwe.de> wrote:

>  $ superiotool -d

Here comes a few:
Mainboard: Asus N4L-VM DH (945GM board with socket 479)

Found Winbond W83627EHF/EF/EHG/EG (id=0x88, rev=0x63) at 0x2e
Register dump:
idx 20 21 22 23 24 25 26 27 28 29 2a 2b 2c 2d 2e 2f 
val 88 63 ff 00 44 00 00 ff 50 04 00 00 9a 21 00 ff 
def 88 MM ff 00 MM 00 MM RR 50 04 00 RR 00 21 00 00 
LDN 0x00 (Floppy)
idx 30 60 61 70 74 f0 f1 f2 f4 f5 
val 00 03 f0 06 02 0e 00 ff 00 00 
def 01 03 f0 06 02 8e 00 ff 00 00 
LDN 0x01 (Parallel port)
idx 30 60 61 70 74 f0 
val 00 03 78 00 04 3c 
def 01 03 78 07 04 3f 
LDN 0x02 (COM1)
idx 30 60 61 70 f0 
val 00 03 f8 04 00 
def 01 03 f8 04 00 
LDN 0x03 (COM2)
idx 30 60 61 70 f0 f1 
val 00 02 f8 03 00 00 
def 01 02 f8 03 00 00 
LDN 0x05 (Keyboard)
idx 30 60 61 62 63 70 72 f0 
val 01 00 60 00 64 01 0c 83 
def 01 00 60 00 64 01 0c 83 
LDN 0x06 (Serial flash interface)
idx 30 62 63 
val 00 ff ff 
def 00 00 00 
LDN 0x07 (GPIO 1, GPIO 6, game port, MIDI port)
idx 30 60 61 62 63 70 f0 f1 f2 f3 f4 f5 f6 f7 
val 00 02 01 03 30 00 ff ff ff ff ff ff ff 00 
def 00 02 01 03 30 09 ff 00 00 00 ff 00 00 00 
LDN 0x08 (WDTO#, PLED)
idx 30 f5 f6 f7 
val 00 ff 00 ff 
def 00 00 00 00 
LDN 0x09 (GPIO 2, GPIO 3, GPIO 4, GPIO 5, SUSLED)
idx 30 e0 e1 e2 e3 e4 e5 f0 f1 f2 f3 f4 f5 f6 f7 
val 0f ff 21 00 ff 08 00 ff 0c 00 09 9f ff 00 00 
def 00 ff 00 00 ff 00 00 ff 00 00 00 ff 00 00 00 
LDN 0x0a (ACPI)
idx 30 70 e0 e1 e2 e3 e4 e5 e6 e7 e8 f2 f3 f4 f6 f7 
val 01 00 00 00 ff 00 40 02 0c 10 09 7d 00 00 00 00 
def 00 00 01 00 ff 08 00 RR 00 00 RR 7c 00 00 00 00 
LDN 0x0b (Hardware monitor)
idx 30 60 61 70 f0 f1 
val 01 02 90 00 c1 3f 
def 00 00 00 00 c1 00

Mainboard: MSI K7T266 PRO2 (MS-6380 v2.0)
Found Winbond W83627HF/F/HG/G (id=0x52, rev=0x17) at 0x2e
No dump available for this Super I/O

I also ran superiotool on an Asus L8400 laptop and a HP compaq d530 sff
desktop, but it did not detect any super I/O. Opening up the HP
revealed an SMSC LPC47B387-NC, I feel a bit reluctant to take the
laptop apart.

/Rasmus Wiman

-- 

Geek for hire



From c-d.hailfinger.devel.2006 at gmx.net  Tue Oct  2 16:23:06 2007
From: c-d.hailfinger.devel.2006 at gmx.net (Carl-Daniel Hailfinger)
Date: Tue, 02 Oct 2007 16:23:06 +0200
Subject: [LinuxBIOS] [PATCH] fix resource end in K8 amdk8/northbridge.c
In-Reply-To: <20071001204335.GB9669@greenwood>
References: <46FD9628.9020402@assembler.cz> <20071001204335.GB9669@greenwood>
Message-ID: <4702544A.5080104@gmx.net>

On 01.10.2007 22:43, Uwe Hermann wrote:
> On Sat, Sep 29, 2007 at 02:02:48AM +0200, Rudolf Marek wrote:
>> Index: src/northbridge/amd/amdk8/northbridge.c
>> ===================================================================
>> --- src/northbridge/amd/amdk8/northbridge.c	(revision 2776)
>> +++ src/northbridge/amd/amdk8/northbridge.c	(working copy)
>> @@ -562,7 +562,7 @@
>>  	base  |= (resource->base >> 8) & 0xffffff00;
>>  	base  |= 3;
>>  	limit &= 0x00000048;
>> -	limit |= ((resource->base + resource->size) >> 8) & 0xffffff00;
>> +	limit |= (resource_end(resource) >> 8) & 0xffffff00;
>>  	limit |= (resource->index & 3) << 4;
>>  	limit |= (nodeid & 7);
>>  	f1_write_config32(reg + 0x4, limit);
> 
> What exactly is broken in the current code and how does it show? How can
> we test the effect of the fix?

Resources go backwards (end before start). That should be corrected with
the patch.

I don't have the hardware to verify.

Carl-Daniel



From c-d.hailfinger.devel.2006 at gmx.net  Tue Oct  2 16:33:47 2007
From: c-d.hailfinger.devel.2006 at gmx.net (Carl-Daniel Hailfinger)
Date: Tue, 02 Oct 2007 16:33:47 +0200
Subject: [LinuxBIOS] Call for help: superiotool
In-Reply-To: <a698c16a0710012037l37bc9d07i6628563002d7e47a@mail.gmail.com>
References: <20070923111315.GC12926@greenwood>	
	<a698c16a0709270921l860615dv3ebe8d49e2f4c791@mail.gmail.com>	
	<46FBDB3E.4000009@gmx.net>
	<a698c16a0710012037l37bc9d07i6628563002d7e47a@mail.gmail.com>
Message-ID: <470256CB.9060008@gmx.net>

On 02.10.2007 05:37, Robinson Tryon wrote:
> On 9/27/07, Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006 at gmx.net> wrote:
>> Not supported by superiotool, however if there was any output at all,
>> we'd like to know it. That alone would probably help us identify the
>> Super I/O, and from there, adding support is rather easy.
> 
> System Information
>         Manufacturer: TOSHIBA
>         Product Name: Satellite 1415
>         Version: PS141U-1ZCF4V
> 
> $ sudo ./superiotool -v
> superiotool r2815
> $ sudo ./superiotool -V
> Probing for ALi Super I/O at 0x3f0... failed
> Probing for ALi Super I/O at 0x370... failed
> Probing for NSC Super I/O at 0x2e... failed
> Probing for NSC Super I/O at 0x4e... failed
> Probing for Fintek Super I/O at 0x2e... failed
> Probing for Fintek Super I/O at 0x4e... failed
> Probing 0x2e, failed (0x22), data returns 0x04
> Probing 0x2e, failed (0x22), data returns 0x04
> Probing for ITE Super I/O (init=0x87,0x01,0x55,0x55/0xaa) at 0x4e... failed
> Probing for ITE Super I/O (init=0x87,0x87) at 0x4e... failed
> Probing 0x2e, failed (0x21), data returns 0x00
> Probing 0x2e, failed (0x0e), data returns 0x00
> Probing for SMSC Super I/O at 0x4e... failed
> Probing for SMSC Super I/O at 0x4e... failed
> Probing for SMSC Super I/O at 0x3f0... failed
> Probing for SMSC Super I/O at 0x3f0... failed
> Probing for SMSC Super I/O at 0x370... failed
> Probing for SMSC Super I/O at 0x370... failed
> Probing for Winbond Super I/O (init=0x88) at 0x2e... failed
> Probing for Winbond Super I/O (init=0x89) at 0x2e... failed
> Probing for Winbond Super I/O (init=0x86,0x86) at 0x2e... failed
> Probing for Winbond Super I/O (init=0x87,0x87) at 0x2e... failed
> Probing for Winbond Super I/O (init=0x88) at 0x4e... failed
> Probing for Winbond Super I/O (init=0x89) at 0x4e... failed
> Probing for Winbond Super I/O (init=0x86,0x86) at 0x4e... failed
> Probing for Winbond Super I/O (init=0x87,0x87) at 0x4e... failed
> Probing for Winbond Super I/O (init=0x88) at 0x3f0... failed
> Probing for Winbond Super I/O (init=0x89) at 0x3f0... failed
> Probing for Winbond Super I/O (init=0x86,0x86) at 0x3f0... failed
> Probing for Winbond Super I/O (init=0x87,0x87) at 0x3f0... failed
> Probing for Winbond Super I/O (init=0x88) at 0x370... failed
> Probing for Winbond Super I/O (init=0x89) at 0x370... failed
> Probing for Winbond Super I/O (init=0x86,0x86) at 0x370... failed
> Probing for Winbond Super I/O (init=0x87,0x87) at 0x370... failed
> Probing for Winbond Super I/O (init=0x88) at 0x250... failed
> Probing for Winbond Super I/O (init=0x89) at 0x250... failed
> Probing for Winbond Super I/O (init=0x86,0x86) at 0x250... failed
> Probing for Winbond Super I/O (init=0x87,0x87) at 0x250... failed

Your superiotool version seems broken. Probably one of Uwe's "trivial"
patches.

Carl-Daniel



From c-d.hailfinger.devel.2006 at gmx.net  Tue Oct  2 16:34:36 2007
From: c-d.hailfinger.devel.2006 at gmx.net (Carl-Daniel Hailfinger)
Date: Tue, 02 Oct 2007 16:34:36 +0200
Subject: [LinuxBIOS] Call for help: superiotool
In-Reply-To: <a698c16a0710011533n37e5e898l78dac2ef3c2c9ef5@mail.gmail.com>
References: <20070923111315.GC12926@greenwood>	
	<a698c16a0709270921l860615dv3ebe8d49e2f4c791@mail.gmail.com>	
	<46FBDB3E.4000009@gmx.net>
	<a698c16a0710011533n37e5e898l78dac2ef3c2c9ef5@mail.gmail.com>
Message-ID: <470256FC.40200@gmx.net>

On 02.10.2007 00:33, Robinson Tryon wrote:
> On 9/27/07, Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006 at gmx.net> wrote:
>> On 27.09.2007 18:21, Robinson Tryon wrote:
>>> Okay -- I grabbed the code from SVN, compiled it and ran it on a few
>>> computers, but I didn't get any useful output (verbose mode was also
>>> pretty sparse).  I assume that this means that my Super I/O chips are
>>> not supported, correct?
>> Not supported by superiotool, however if there was any output at all,
>> we'd like to know it. That alone would probably help us identify the
>> Super I/O, and from there, adding support is rather easy.
> 
> What kinds of machines would you like output from?  Any hardware I can
> get to run 'superiotool' ?  :-)

Basically, if the chipset (north-/southbridge) is supported, the first
step in trying to port LB to the mainboard is running superiotool so you
can find out the correct settings for early serial output.

> What other information should I include?  Motherboard model?  Output from lspci?

Motherboard model and if possible the numbers printed on top of the
Super I/O chip.

We can then locate the right data sheet and give it either to you or add
support for the part to superiotool ourselves.

Carl-Daniel



From rminnich at gmail.com  Tue Oct  2 17:31:02 2007
From: rminnich at gmail.com (ron minnich)
Date: Tue, 2 Oct 2007 08:31:02 -0700
Subject: [LinuxBIOS] filo and v3
Message-ID: <13426df10710020831t3ad669e3ua61a00e53f48a696@mail.gmail.com>

here is all I get:
FILO version 0.5 (rminnich at xcpu) Tue Oct  2 08:19:34 PDT 2007
Can't get memory map from firmware. Using hardcoded default.

This is a fresh checkout as of this morning, both v3 and filo. This
did used to work.
GRUB or not grub makes no difference.

DEBUG_ALL=1

ron



From c-d.hailfinger.devel.2006 at gmx.net  Tue Oct  2 17:44:11 2007
From: c-d.hailfinger.devel.2006 at gmx.net (Carl-Daniel Hailfinger)
Date: Tue, 02 Oct 2007 17:44:11 +0200
Subject: [LinuxBIOS] filo and v3
In-Reply-To: <13426df10710020831t3ad669e3ua61a00e53f48a696@mail.gmail.com>
References: <13426df10710020831t3ad669e3ua61a00e53f48a696@mail.gmail.com>
Message-ID: <4702674B.7@gmx.net>

On 02.10.2007 17:31, ron minnich wrote:
> here is all I get:
> FILO version 0.5 (rminnich at xcpu) Tue Oct  2 08:19:34 PDT 2007
> Can't get memory map from firmware. Using hardcoded default.
> 
> This is a fresh checkout as of this morning, both v3 and filo. This
> did used to work.

Can you do a binary search of the last working revision?

Carl-Daniel



From bishop.robinson at gmail.com  Tue Oct  2 17:44:16 2007
From: bishop.robinson at gmail.com (Robinson Tryon)
Date: Tue, 2 Oct 2007 11:44:16 -0400
Subject: [LinuxBIOS] Call for help: superiotool
In-Reply-To: <470256CB.9060008@gmx.net>
References: <20070923111315.GC12926@greenwood>
	<a698c16a0709270921l860615dv3ebe8d49e2f4c791@mail.gmail.com>
	<46FBDB3E.4000009@gmx.net>
	<a698c16a0710012037l37bc9d07i6628563002d7e47a@mail.gmail.com>
	<470256CB.9060008@gmx.net>
Message-ID: <a698c16a0710020844ud12485dhb063f76800170b63@mail.gmail.com>

On 10/2/07, Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006 at gmx.net> wrote:
> On 02.10.2007 05:37, Robinson Tryon wrote:
> > On 9/27/07, Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006 at gmx.net> wrote:
> >> Not supported by superiotool, however if there was any output at all,
> >> we'd like to know it. That alone would probably help us identify the
> >> Super I/O, and from there, adding support is rather easy.
> >
> > System Information
> >         Manufacturer: TOSHIBA
> >         Product Name: Satellite 1415
> >         Version: PS141U-1ZCF4V
> >
> > $ sudo ./superiotool -v
> > superiotool r2815
> > $ sudo ./superiotool -V
> > Probing for ALi Super I/O at 0x3f0... failed
> > Probing for ALi Super I/O at 0x370... failed
> > Probing for NSC Super I/O at 0x2e... failed
> > Probing for NSC Super I/O at 0x4e... failed
> > Probing for Fintek Super I/O at 0x2e... failed
> > Probing for Fintek Super I/O at 0x4e... failed
> > Probing 0x2e, failed (0x22), data returns 0x04
> > Probing 0x2e, failed (0x22), data returns 0x04
> > Probing for ITE Super I/O (init=0x87,0x01,0x55,0x55/0xaa) at 0x4e... failed
> > Probing for ITE Super I/O (init=0x87,0x87) at 0x4e... failed
> > Probing 0x2e, failed (0x21), data returns 0x00
> > Probing 0x2e, failed (0x0e), data returns 0x00
> > Probing for SMSC Super I/O at 0x4e... failed
> > Probing for SMSC Super I/O at 0x4e... failed
> > Probing for SMSC Super I/O at 0x3f0... failed
> > Probing for SMSC Super I/O at 0x3f0... failed
> > Probing for SMSC Super I/O at 0x370... failed
> > Probing for SMSC Super I/O at 0x370... failed
> > Probing for Winbond Super I/O (init=0x88) at 0x2e... failed
> > Probing for Winbond Super I/O (init=0x89) at 0x2e... failed
> > Probing for Winbond Super I/O (init=0x86,0x86) at 0x2e... failed
> > Probing for Winbond Super I/O (init=0x87,0x87) at 0x2e... failed
> > Probing for Winbond Super I/O (init=0x88) at 0x4e... failed
> > Probing for Winbond Super I/O (init=0x89) at 0x4e... failed
> > Probing for Winbond Super I/O (init=0x86,0x86) at 0x4e... failed
> > Probing for Winbond Super I/O (init=0x87,0x87) at 0x4e... failed
> > Probing for Winbond Super I/O (init=0x88) at 0x3f0... failed
> > Probing for Winbond Super I/O (init=0x89) at 0x3f0... failed
> > Probing for Winbond Super I/O (init=0x86,0x86) at 0x3f0... failed
> > Probing for Winbond Super I/O (init=0x87,0x87) at 0x3f0... failed
> > Probing for Winbond Super I/O (init=0x88) at 0x370... failed
> > Probing for Winbond Super I/O (init=0x89) at 0x370... failed
> > Probing for Winbond Super I/O (init=0x86,0x86) at 0x370... failed
> > Probing for Winbond Super I/O (init=0x87,0x87) at 0x370... failed
> > Probing for Winbond Super I/O (init=0x88) at 0x250... failed
> > Probing for Winbond Super I/O (init=0x89) at 0x250... failed
> > Probing for Winbond Super I/O (init=0x86,0x86) at 0x250... failed
> > Probing for Winbond Super I/O (init=0x87,0x87) at 0x250... failed
>
> Your superiotool version seems broken. Probably one of Uwe's "trivial"
> patches.

Hmm... is it possible that the Satellite 1415 doesn't have a Super I/O ?

(could verbose mode please print out the version # ?)



From c-d.hailfinger.devel.2006 at gmx.net  Tue Oct  2 17:50:40 2007
From: c-d.hailfinger.devel.2006 at gmx.net (Carl-Daniel Hailfinger)
Date: Tue, 02 Oct 2007 17:50:40 +0200
Subject: [LinuxBIOS] Call for help: superiotool
In-Reply-To: <a698c16a0710020844ud12485dhb063f76800170b63@mail.gmail.com>
References: <20070923111315.GC12926@greenwood>	<a698c16a0709270921l860615dv3ebe8d49e2f4c791@mail.gmail.com>	<46FBDB3E.4000009@gmx.net>	<a698c16a0710012037l37bc9d07i6628563002d7e47a@mail.gmail.com>	<470256CB.9060008@gmx.net>
	<a698c16a0710020844ud12485dhb063f76800170b63@mail.gmail.com>
Message-ID: <470268D0.9050107@gmx.net>

On 02.10.2007 17:44, Robinson Tryon wrote:
> On 10/2/07, Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006 at gmx.net> wrote:
>> On 02.10.2007 05:37, Robinson Tryon wrote:
>>> On 9/27/07, Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006 at gmx.net> wrote:
>>>> Not supported by superiotool, however if there was any output at all,
>>>> we'd like to know it. That alone would probably help us identify the
>>>> Super I/O, and from there, adding support is rather easy.
>>> System Information
>>>         Manufacturer: TOSHIBA
>>>         Product Name: Satellite 1415
>>>         Version: PS141U-1ZCF4V
>>>
>>> $ sudo ./superiotool -v
>>> superiotool r2815
>>> $ sudo ./superiotool -V
>>> Probing for ALi Super I/O at 0x3f0... failed
>>> Probing for ALi Super I/O at 0x370... failed
>>> Probing for NSC Super I/O at 0x2e... failed
>>> Probing for NSC Super I/O at 0x4e... failed
>>> Probing for Fintek Super I/O at 0x2e... failed
>>> Probing for Fintek Super I/O at 0x4e... failed
>>> Probing 0x2e, failed (0x22), data returns 0x04
>>> Probing 0x2e, failed (0x22), data returns 0x04
>>> Probing for ITE Super I/O (init=0x87,0x01,0x55,0x55/0xaa) at 0x4e... failed
>>> Probing for ITE Super I/O (init=0x87,0x87) at 0x4e... failed
>>> Probing 0x2e, failed (0x21), data returns 0x00
>>> Probing 0x2e, failed (0x0e), data returns 0x00
>>> Probing for SMSC Super I/O at 0x4e... failed
>>> Probing for SMSC Super I/O at 0x4e... failed
>>> Probing for SMSC Super I/O at 0x3f0... failed
>>> Probing for SMSC Super I/O at 0x3f0... failed
>>> Probing for SMSC Super I/O at 0x370... failed
>>> Probing for SMSC Super I/O at 0x370... failed
>>> Probing for Winbond Super I/O (init=0x88) at 0x2e... failed
>>> Probing for Winbond Super I/O (init=0x89) at 0x2e... failed
>>> Probing for Winbond Super I/O (init=0x86,0x86) at 0x2e... failed
>>> Probing for Winbond Super I/O (init=0x87,0x87) at 0x2e... failed
>>> Probing for Winbond Super I/O (init=0x88) at 0x4e... failed
>>> Probing for Winbond Super I/O (init=0x89) at 0x4e... failed
>>> Probing for Winbond Super I/O (init=0x86,0x86) at 0x4e... failed
>>> Probing for Winbond Super I/O (init=0x87,0x87) at 0x4e... failed
>>> Probing for Winbond Super I/O (init=0x88) at 0x3f0... failed
>>> Probing for Winbond Super I/O (init=0x89) at 0x3f0... failed
>>> Probing for Winbond Super I/O (init=0x86,0x86) at 0x3f0... failed
>>> Probing for Winbond Super I/O (init=0x87,0x87) at 0x3f0... failed
>>> Probing for Winbond Super I/O (init=0x88) at 0x370... failed
>>> Probing for Winbond Super I/O (init=0x89) at 0x370... failed
>>> Probing for Winbond Super I/O (init=0x86,0x86) at 0x370... failed
>>> Probing for Winbond Super I/O (init=0x87,0x87) at 0x370... failed
>>> Probing for Winbond Super I/O (init=0x88) at 0x250... failed
>>> Probing for Winbond Super I/O (init=0x89) at 0x250... failed
>>> Probing for Winbond Super I/O (init=0x86,0x86) at 0x250... failed
>>> Probing for Winbond Super I/O (init=0x87,0x87) at 0x250... failed
>> Your superiotool version seems broken. Probably one of Uwe's "trivial"
>> patches.
> 
> Hmm... is it possible that the Satellite 1415 doesn't have a Super I/O ?

Probably the Super I/O is inside the embedded controller and responds to
a special probe sequence.

However, the probing sequence is incomplete (at least when judging it by
its output) and Uwe rewrote the probing sequence, so he can take a look
at it.

> (could verbose mode please print out the version # ?)

Good idea. Care to send a patch?

Carl-Daniel



From svn at openbios.org  Tue Oct  2 17:49:25 2007
From: svn at openbios.org (svn at openbios.org)
Date: Tue,  2 Oct 2007 17:49:25 +0200
Subject: [LinuxBIOS] r2817 - trunk/util/flashrom
Message-ID: <mailman.688.1355071171.16123.coreboot@coreboot.org>

Author: ward
Date: 2007-10-02 17:49:25 +0200 (Tue, 02 Oct 2007)
New Revision: 2817

Modified:
   trunk/util/flashrom/board_enable.c
   trunk/util/flashrom/flash.h
   trunk/util/flashrom/flashchips.c
Log:

This patch aims to restructure SPI flash support in a more reasonable
way. It introduces a generic SPI host driver for the IT8716F Super I/O
which will enable easy SPI programming without having to care for the
peculiarities of the SPI host.

To activate probing for the IT8716F, you have to use the gigabyte:m57sli
mainboard override. SPI support will then use the gathered SPI host data
to access the SPI flash.

This has been tested sucessfully by Ward Vandewege <ward at gnu.org> on the
GA-M57SLI v2.0, which has a MX25L4005 SPI flash part.

Signed-off-by: Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006 at gmx.net>
Acked-by: Ward Vandewege <ward at gnu.org>



Modified: trunk/util/flashrom/board_enable.c
===================================================================
--- trunk/util/flashrom/board_enable.c	2007-10-01 18:32:00 UTC (rev 2816)
+++ trunk/util/flashrom/board_enable.c	2007-10-02 15:49:25 UTC (rev 2817)
@@ -30,6 +30,15 @@
 #include <string.h>
 #include "flash.h"
 
+#define ITE_SUPERIO_PORT1	0x2e
+#define ITE_SUPERIO_PORT2	0x4e
+
+#define JEDEC_RDID	{0x9f}
+#define JEDEC_RDID_OUTSIZE	0x01
+#define JEDEC_RDID_INSIZE	0x03
+
+static uint16_t it8716f_flashport = 0;
+
 /* Generic Super I/O helper functions */
 uint8_t regval(uint16_t port, uint8_t reg)
 {
@@ -51,7 +60,7 @@
 	outb(0x87, port);
 	outb(0x01, port);
 	outb(0x55, port);
-	if (port == 0x2e)
+	if (port == ITE_SUPERIO_PORT1)
 		outb(0x55, port);
 	else
 		outb(0xaa, port);
@@ -96,35 +105,97 @@
 	return flashport;
 }
 
-static void it8716_serial_rdid(uint16_t port)
+/* The IT8716F only supports commands with length 1,2,4,5 bytes including
+   command byte and can not read more than 3 bytes from the device.
+   This function expects writearr[0] to be the first byte sent to the device,
+   whereas the IT8716F splits commands internally into address and non-address
+   commands with the address in inverse wire order. That's why the register
+   ordering in case 4 and 5 may seem strange. */
+static int it8716f_spi_command(uint16_t port, unsigned char writecnt, unsigned char readcnt, const unsigned char *writearr, unsigned char *readarr)
 {
-	uint8_t busy, data0, data1, data2;
+	uint8_t busy, writeenc;
 	do {
 		busy = inb(port) & 0x80;
 	} while (busy);
-	/* RDID */
-	outb(0x9f, port + 1);
-	/* Start IO, 33MHz, 3 input bytes, 0 output bytes*/
-	outb((0x5<<4)|(0x3<<2)|(0x0), port);
+	if (readcnt > 3) {
+		printf("%s called with unsupported readcnt %i\n",
+			__FUNCTION__, readcnt);
+		return 1;
+	}
+	switch (writecnt) {
+	case 1:
+		outb(writearr[0], port + 1);
+		writeenc = 0x0;
+		break;
+	case 2:
+		outb(writearr[0], port + 1);
+		outb(writearr[1], port + 7);
+		writeenc = 0x1;
+		break;
+	case 4:
+		outb(writearr[0], port + 1);
+		outb(writearr[1], port + 4);
+		outb(writearr[2], port + 3);
+		outb(writearr[3], port + 2);
+		writeenc = 0x2;
+		break;
+	case 5:
+		outb(writearr[0], port + 1);
+		outb(writearr[1], port + 4);
+		outb(writearr[2], port + 3);
+		outb(writearr[3], port + 2);
+		outb(writearr[4], port + 7);
+		writeenc = 0x3;
+		break;
+	default:
+		printf("%s called with unsupported writecnt %i\n",
+			__FUNCTION__, writecnt);
+		return 1;
+	}
+	/* Start IO, 33MHz, readcnt input bytes, writecnt output bytes. Note:
+	   We can't use writecnt directly, but have to use a strange encoding */
+	outb((0x5 << 4) | ((readcnt & 0x3) << 2) | (writeenc), port);
 	do {
 		busy = inb(port) & 0x80;
 	} while (busy);
-	data0 = inb(port + 5);
-	data1 = inb(port + 6);
-	data2 = inb(port + 7);
-	printf("RDID returned %02x %02x %02x\n", data0, data1, data2);
-	return;
+	readarr[0] = inb(port + 5);
+	readarr[1] = inb(port + 6);
+	readarr[2] = inb(port + 7);
+	return 0;
 }
 
+static int it8716f_serial_rdid(uint16_t port, unsigned char *readarr)
+{
+	const unsigned char cmd[] = JEDEC_RDID;
+
+	if (it8716f_spi_command(port, JEDEC_RDID_OUTSIZE, JEDEC_RDID_INSIZE, cmd, readarr))
+		return 1;
+	printf("RDID returned %02x %02x %02x\n", readarr[0], readarr[1], readarr[2]);
+	return 0;
+}
+
 static int it87xx_probe_serial_flash(const char *name)
 {
-	uint16_t flashport;
-	flashport = find_ite_serial_flash_port(0x2e);
-	if (flashport)
-		it8716_serial_rdid(flashport);
-	flashport = find_ite_serial_flash_port(0x4e);
-	if (flashport)
-		it8716_serial_rdid(flashport);
+	it8716f_flashport = find_ite_serial_flash_port(ITE_SUPERIO_PORT1);
+	if (!it8716f_flashport)
+		it8716f_flashport = find_ite_serial_flash_port(ITE_SUPERIO_PORT2);
+	return (!it8716f_flashport);
+}
+
+int probe_spi(struct flashchip *flash)
+{
+	unsigned char readarr[3];
+	uint8_t manuf_id;
+	uint16_t model_id;
+	if (it8716f_flashport) {
+		it8716f_serial_rdid(it8716f_flashport, readarr);
+		manuf_id = readarr[0];
+		model_id = (readarr[1] << 8) | readarr[2];
+		printf_debug("%s: id1 0x%x, id2 0x%x\n", __FUNCTION__, manuf_id, model_id);
+		if (manuf_id == flash->manufacture_id && model_id == flash->model_id)
+			return 1;
+	}
+
 	return 0;
 }
 

Modified: trunk/util/flashrom/flash.h
===================================================================
--- trunk/util/flashrom/flash.h	2007-10-01 18:32:00 UTC (rev 2816)
+++ trunk/util/flashrom/flash.h	2007-10-02 15:49:25 UTC (rev 2817)
@@ -55,6 +55,8 @@
 /* Please keep this list sorted alphabetically by manufacturer. The first
  * entry of each section should be the manufacturer ID, followed by the
  * list of devices from that manufacturer (sorted by device IDs).
+ * All LPC/FWH parts (parallel flash) have 8-bit device IDs.
+ * All SPI parts have 16-bit device IDs.
  */
 
 #define AMD_ID			0x01	/* AMD */
@@ -68,8 +70,31 @@
 #define AT_29C040A		0xA4
 #define AT_29C020		0xDA
 
+#define EON_ID			0x1C
+/* EN25 chips are SPI, first byte of device id is memory type,
+   second byte of device id is log(bitsize)-9 */
+#define EN_25B05		0x2010	/* 2^19 kbit or 2^16 kByte */
+#define EN_25B10		0x2011
+#define EN_25B20		0x2012
+#define EN_25B40		0x2013
+#define EN_25B80		0x2014
+#define EN_25B16		0x2015
+#define EN_25B32		0x2016
+
 #define MX_ID			0xC2	/* Macronix (MX) */
 #define MX_29F002		0xB0
+/* MX25L chips are SPI, first byte of device id is memory type,
+   second byte of device id is log(bitsize)-9 */
+#define MX_25L512		0x2010	/* 2^19 kbit or 2^16 kByte */
+#define MX_25L1005		0x2011
+#define MX_25L2005		0x2012
+#define MX_25L4005		0x2013	/* MX25L4005{,A} */
+#define MX_25L8005		0x2014
+#define MX_25L1605		0x2015	/* MX25L1605{,A,D} */
+#define MX_25L3205		0x2016	/* MX25L3205{,A} */
+#define MX_25L6405		0x2017	/* MX25L3205{,D} */
+#define MX_25L1635D		0x2415
+#define MX_25L3235D		0x2416
 
 #define SHARP_ID		0xB0	/* Sharp */
 #define SHARP_LHF00L04		0xCF
@@ -182,6 +207,8 @@
 int linuxbios_init(void);
 extern char *lb_part, *lb_vendor;
 
+int probe_spi(struct flashchip *flash);
+
 /* 82802ab.c */
 int probe_82802ab(struct flashchip *flash);
 int erase_82802ab(struct flashchip *flash);

Modified: trunk/util/flashrom/flashchips.c
===================================================================
--- trunk/util/flashrom/flashchips.c	2007-10-01 18:32:00 UTC (rev 2816)
+++ trunk/util/flashrom/flashchips.c	2007-10-02 15:49:25 UTC (rev 2817)
@@ -38,6 +38,8 @@
 	 probe_jedec,	erase_chip_jedec, write_jedec},
 	{"Mx29f002",	MX_ID,		MX_29F002,	256, 64 * 1024,
 	 probe_29f002,	erase_29f002, 	write_29f002},
+	{"MX25L4005",	MX_ID,		MX_25L4005,	512, 4 * 1024,
+	 probe_spi,	NULL,		NULL},
 	{"SST29EE020A", SST_ID,		SST_29EE020A,	256, 128,
 	 probe_jedec,	erase_chip_jedec, write_jedec},
 	{"SST28SF040A", SST_ID,		SST_28SF040,	512, 256,




From ward at gnu.org  Tue Oct  2 17:50:01 2007
From: ward at gnu.org (Ward Vandewege)
Date: Tue, 2 Oct 2007 11:50:01 -0400
Subject: [LinuxBIOS] [PATCH] improved SPI flash support (restructured)
In-Reply-To: <4700F268.2010604@gmx.net>
References: <46FD033A.2000108@gmx.net> <20070928145508.GH7553@greenwood>
	<46FD852A.9030400@gmx.net> <46FDB3AD.4070609@gmx.net>
	<20070929135924.GA6264@coresystems.de>
	<4700CBDE.4070801@gmx.net> <20071001122559.GA11604@localdomain>
	<4700EDCF.6020809@gmx.net> <20071001130007.GA12406@localdomain>
	<4700F268.2010604@gmx.net>
Message-ID: <20071002155001.GA13052@localdomain>

On Mon, Oct 01, 2007 at 03:13:12PM +0200, Carl-Daniel Hailfinger wrote:
> Great! Can you ack/commit with the following changelog?
> ------------------------------------------------------------------------
> 
> This patch aims to restructure SPI flash support in a more reasonable
> way. It introduces a generic SPI host driver for the IT8716F Super I/O
> which will enable easy SPI programming without having to care for the
> peculiarities of the SPI host.
> 
> To activate probing for the IT8716F, you have to use the gigabyte:m57sli
> mainboard override. SPI support will then use the gathered SPI host data
> to access the SPI flash.
> 
> This has been tested sucessfully by Ward Vandewege <ward at gnu.org> on the
> GA-M57SLI v2.0, which has a MX25L4005 SPI flash part.
> 
> Signed-off-by: Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006 at gmx.net>

Acked-by: Ward Vandewege <ward at gnu.org>

And committed in r2817

Thanks,
Ward.

-- 
Ward Vandewege <ward at fsf.org>
Free Software Foundation - Senior System Administrator



From rminnich at gmail.com  Tue Oct  2 17:51:59 2007
From: rminnich at gmail.com (ron minnich)
Date: Tue, 2 Oct 2007 08:51:59 -0700
Subject: [LinuxBIOS] filo and v3
In-Reply-To: <4702674B.7@gmx.net>
References: <13426df10710020831t3ad669e3ua61a00e53f48a696@mail.gmail.com>
	<4702674B.7@gmx.net>
Message-ID: <13426df10710020851t19c20bb8oc22ed7ccf45e33f9@mail.gmail.com>

This patch fixes the obvious bugs but filo self-relocation still
fails. I need an ack.

ron
-------------- next part --------------
A non-text attachment was scrubbed...
Name: filo.diff
Type: text/x-patch
Size: 1673 bytes
Desc: not available
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20071002/2428ee5d/attachment.diff>

From c-d.hailfinger.devel.2006 at gmx.net  Tue Oct  2 18:02:33 2007
From: c-d.hailfinger.devel.2006 at gmx.net (Carl-Daniel Hailfinger)
Date: Tue, 02 Oct 2007 18:02:33 +0200
Subject: [LinuxBIOS] filo and v3
In-Reply-To: <13426df10710020851t19c20bb8oc22ed7ccf45e33f9@mail.gmail.com>
References: <13426df10710020831t3ad669e3ua61a00e53f48a696@mail.gmail.com>	
	<4702674B.7@gmx.net>
	<13426df10710020851t19c20bb8oc22ed7ccf45e33f9@mail.gmail.com>
Message-ID: <47026B99.4070608@gmx.net>

On 02.10.2007 17:51, ron minnich wrote:
> This patch fixes the obvious bugs but filo self-relocation still
> fails. I need an ack.
> 
> ron
> 
> 
> ------------------------------------------------------------------------
> 
> 1. fix spelling error. 
> 2. paranoid setting of info->memrange to 0
> 3. don't use malloc when it is not possible to use malloc. 
> Signed-off-by: Ronald G. Minnich <rminnich at gmail.com>

Except for the comments below:
Acked-by: Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006 at gmx.net>

> Index: main/linuxbios.c
> ===================================================================
> --- main/linuxbios.c	(revision 35)
> +++ main/linuxbios.c	(working copy)
> @@ -89,7 +89,7 @@
>  		}
>  		if (head->header_bytes != sizeof(*head))
>  			continue;
> -		debug("Found canidate at: %p\n", head);
> +		debug("Found candidate at: %p\n", head);
>  		if (ipchksum((uint16_t *)head, sizeof(*head)) != 0) 
>  			continue;
>  		debug("header checksum o.k.\n");
> @@ -114,6 +114,7 @@
>  	struct lb_header *lb_table;
>  	int found;
>  	debug("Searching for LinuxBIOS tables...\n");
> +	info->memrange = 0;

Use NULL instead?

>  	found = 0;
>  	if (!found) {
>  		found = find_lb_table(phys_to_virt(0x00000), phys_to_virt(0x01000), &lb_table);
> Index: i386/sys_info.c
> ===================================================================
> --- i386/sys_info.c	(revision 35)
> +++ i386/sys_info.c	(working copy)
> @@ -11,6 +11,8 @@
>  {
>      int i;
>      unsigned long long total = 0;
> +    /* this fake memory range covers the case that we can't find any LB structs. */
> +    static struct memrange fakememrange[2];
>  
>      /* Pick up paramters given by bootloader to us */
>      info->boot_type = boot_ctx->eax;
> @@ -30,7 +32,8 @@
>  	printf("Can't get memory map from firmware. "
>  		"Using hardcoded default.\n");
>  	info->n_memranges = 2;
> -	info->memrange = malloc(2 * sizeof(struct memrange));
> +	/* NOTE: DO NOT USE MALLOC HERE */

Can you change the comment to explain why?

> +	info->memrange = fakememrange;
>  	info->memrange[0].base = 0;
>  	info->memrange[0].size = 640*1024;
>  	info->memrange[1].base = 1024*1024;


-- 
http://www.hailfinger.org/



From lbrooks at MIT.EDU  Tue Oct  2 18:20:11 2007
From: lbrooks at MIT.EDU (Lane Brooks)
Date: Tue, 02 Oct 2007 10:20:11 -0600
Subject: [LinuxBIOS] flashrom support for AMD Geode CS5536
Message-ID: <47026FBB.1080809@mit.edu>

Attached is a patch that enables AMD Geode CS5536 chipset support.  I 
have tested it successfully on a MSM800 board from digital logic.  It 
does, however, have a few issues that I would like some feedback on.

In my discussions with Marc Jones, Geode systems write protect the BIOS 
via RCONFs (cache settings similar to MTRRs). Unlocking requires 
changing MSR 0x1808 top byte to 0x22. Reading and writing to the msr, 
however, requires instrucitons rdmsr/wrmsr, which are ring0 privileged 
instructions so only the kernel can do the read/write.  So my patch uses 
the msr kernel module to access these instructions from user space using 
the /dev/cpu/0/msr device.

My questions are:
- I do not think this is portable beyond linux.  Is that an issue?

- My code assumes the msr kernel module is already loaded.  Is there a 
way to force a kernel module to load from the C code?  My code does die 
gracefully with a message reminding them to load the kernel module if 
things fail.

- It seems like there should be a way to revert the msr back after 
flashing is completed to put the bios back in write protect mode.  Is 
there a cleanup mechanism available?  Something like disable_flash...


Thanks,
Lane Brooks
-------------- next part --------------
A non-text attachment was scrubbed...
Name: svn.diff
Type: text/x-patch
Size: 2463 bytes
Desc: not available
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20071002/e603c79d/attachment.diff>

From stepan at coresystems.de  Tue Oct  2 18:27:12 2007
From: stepan at coresystems.de (Stefan Reinauer)
Date: Tue, 2 Oct 2007 18:27:12 +0200
Subject: [LinuxBIOS] flashrom support for AMD Geode CS5536
In-Reply-To: <47026FBB.1080809@mit.edu>
References: <47026FBB.1080809@mit.edu>
Message-ID: <20071002162712.GA29819@coresystems.de>

Dear Lane!

Thank you very much for your patch.

* Lane Brooks <lbrooks at MIT.EDU> [071002 18:20]:
> - It seems like there should be a way to revert the msr back after flashing 
> is completed to put the bios back in write protect mode.  Is there a 
> cleanup mechanism available?  Something like disable_flash...

Unfortunately no. Any patches that generically implement such a
mechanism are welcome though!


> +#define _LARGEFILE64_SOURCE
> +#include <sys/types.h>
> +#include <sys/stat.h>
> +#include <fcntl.h>
> +#include <unistd.h>

> +	unsigned long addr = 0x1808;
> +	lseek64(fd_msr, (off64_t) addr, SEEK_SET);

Why do you use/need large file support for seeking to an offset of
0x1808 ?

Please sign off your patches:
http://linuxbios.org/index.php/Development_Guidelines#How_to_contribute


-- 
coresystems GmbH ? Brahmsstr. 16 ? D-79104 Freiburg i. Br.
      Tel.: +49 761 7668825 ? Fax: +49 761 7664613
Email: info at coresystems.de  ? http://www.coresystems.de/
Registergericht: Amtsgericht Freiburg ? HRB 7656
Gesch?ftsf?hrer: Stefan Reinauer ? Ust-IdNr.: DE245674866



From jordan.crouse at amd.com  Tue Oct  2 18:34:38 2007
From: jordan.crouse at amd.com (Jordan Crouse)
Date: Tue, 2 Oct 2007 10:34:38 -0600
Subject: [LinuxBIOS] flashrom support for AMD Geode CS5536
In-Reply-To: <47026FBB.1080809@mit.edu>
References: <47026FBB.1080809@mit.edu>
Message-ID: <20071002163438.GA16097@cosmic.amd.com>

On 02/10/07 10:20 -0600, Lane Brooks wrote:
> Attached is a patch that enables AMD Geode CS5536 chipset support.  I 
> have tested it successfully on a MSM800 board from digital logic.  It 
> does, however, have a few issues that I would like some feedback on.
> 
> In my discussions with Marc Jones, Geode systems write protect the BIOS 
> via RCONFs (cache settings similar to MTRRs). Unlocking requires 
> changing MSR 0x1808 top byte to 0x22. Reading and writing to the msr, 
> however, requires instrucitons rdmsr/wrmsr, which are ring0 privileged 
> instructions so only the kernel can do the read/write.  So my patch uses 
> the msr kernel module to access these instructions from user space using 
> the /dev/cpu/0/msr device.
> 
> My questions are:
> - I do not think this is portable beyond linux.  Is that an issue?

Right now, no.  Any other *nixish OS will have to solve the MSR problem
for themselves.  If they chose something different, then we'll cross that
bridge when we get to it.

> - My code assumes the msr kernel module is already loaded.  Is there a 
> way to force a kernel module to load from the C code?  My code does die 
> gracefully with a message reminding them to load the kernel module if 
> things fail.

Thats the best we can do, without getting more non-portable. I think.

Jordan





From info at coresystems.de  Tue Oct  2 18:37:16 2007
From: info at coresystems.de (LinuxBIOS information)
Date: Tue, 02 Oct 2007 18:37:16 +0200
Subject: [LinuxBIOS] r2817 build service
Message-ID: <E1IckkG-0005rL-5v@khepri.openbios.org>

Dear LinuxBIOS readers!

This is the automated build check service of LinuxBIOS.

The developer "ward" checked in revision 2817 to
the LinuxBIOS source repository and caused the following 
changes:

Change Log:

This patch aims to restructure SPI flash support in a more reasonable
way. It introduces a generic SPI host driver for the IT8716F Super I/O
which will enable easy SPI programming without having to care for the
peculiarities of the SPI host.

To activate probing for the IT8716F, you have to use the gigabyte:m57sli
mainboard override. SPI support will then use the gathered SPI host data
to access the SPI flash.

This has been tested sucessfully by Ward Vandewege <ward at gnu.org> on the
GA-M57SLI v2.0, which has a MX25L4005 SPI flash part.

Signed-off-by: Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006 at gmx.net>
Acked-by: Ward Vandewege <ward at gnu.org>



Build Log:
Compilation of arima:hdama is still broken
See the error log at http://qa.linuxbios.org/log_buildbrd.php?revision=2817&device=hdama&vendor=arima
Compilation of ibm:e325 is still broken
See the error log at http://qa.linuxbios.org/log_buildbrd.php?revision=2817&device=e325&vendor=ibm
Compilation of ibm:e326 is still broken
See the error log at http://qa.linuxbios.org/log_buildbrd.php?revision=2817&device=e326&vendor=ibm
Compilation of iei:juki-511p is still broken
See the error log at http://qa.linuxbios.org/log_buildbrd.php?revision=2817&device=juki-511p&vendor=iei
Compilation of iwill:dk8s2 is still broken
See the error log at http://qa.linuxbios.org/log_buildbrd.php?revision=2817&device=dk8s2&vendor=iwill
Compilation of iwill:dk8x is still broken
See the error log at http://qa.linuxbios.org/log_buildbrd.php?revision=2817&device=dk8x&vendor=iwill
Compilation of newisys:khepri is still broken
See the error log at http://qa.linuxbios.org/log_buildbrd.php?revision=2817&device=khepri&vendor=newisys


If something broke during this checkin please be a pain 
in ward's neck until the issue is fixed.

If this issue is not fixed within 24h the revision should 
be backed out.

   Best regards,
     LinuxBIOS automatic build system





From rminnich at gmail.com  Tue Oct  2 18:38:05 2007
From: rminnich at gmail.com (ron minnich)
Date: Tue, 2 Oct 2007 09:38:05 -0700
Subject: [LinuxBIOS] flashrom support for AMD Geode CS5536
In-Reply-To: <47026FBB.1080809@mit.edu>
References: <47026FBB.1080809@mit.edu>
Message-ID: <13426df10710020938x276d2c3ewf797f82d035d1bd7@mail.gmail.com>

On 10/2/07, Lane Brooks <lbrooks at mit.edu> wrote:
> Attached is a patch that enables AMD Geode CS5536 chipset support.  I
> have tested it successfully on a MSM800 board from digital logic.  It
> does, however, have a few issues that I would like some feedback on.
>
> In my discussions with Marc Jones, Geode systems write protect the BIOS
> via RCONFs (cache settings similar to MTRRs). Unlocking requires
> changing MSR 0x1808 top byte to 0x22. Reading and writing to the msr,
> however, requires instrucitons rdmsr/wrmsr, which are ring0 privileged
> instructions so only the kernel can do the read/write.  So my patch uses
> the msr kernel module to access these instructions from user space using
> the /dev/cpu/0/msr device.
>
> My questions are:
> - I do not think this is portable beyond linux.  Is that an issue?

it's not, but it is not really an issue at present.
>
> - My code assumes the msr kernel module is already loaded.  Is there a
> way to force a kernel module to load from the C code?  My code does die
> gracefully with a message reminding them to load the kernel module if
> things fail.

it is possible I think to have udev help with this, but I am not sure.
Graceful failure is certainly a good start.

>
> - It seems like there should be a way to revert the msr back after
> flashing is completed to put the bios back in write protect mode.  Is
> there a cleanup mechanism available?  Something like disable_flash...

I thought that was in the structure of flashrom. Now that I look, it
seems like we lost it!
I propose this at the end of flashrom:
board_flash_disable(lb_vendor, lb_part);
chipset_flash_disable(chipset);

but we'll need to change some things to make this all work. We need a
penable struct * to use for the disable; no point in searching each
time we touch a chip. or not?

one comment on your patch: you use /dev/cpu/0/msr. This is great for a
single-cpu machine, and will always be fine on  geode. Lots of times,
people use one piece of flashrom to write another. Imagine some future
hacker, in a year or two, who has copied your code for some SMP
system, not understanding why sometimes flashrom fails (i.e. they set
CPU0 msr but end up running on cpu1). We had this very problem when we
were getting graphics going (and, earlier, SMP going). I suggest a
comment as to why the /dev/cpu/0/msr is always safe on geode, but
future hackers beware on SMP. Or something like that.

That's up to you, however :-)

If you had a signed-off-by line, I would ack and commit for you :-)

ron

ron



From marc.jones at amd.com  Tue Oct  2 18:38:35 2007
From: marc.jones at amd.com (Marc Jones)
Date: Tue, 02 Oct 2007 10:38:35 -0600
Subject: [LinuxBIOS] Two more CS5530 IRQ steering questions
In-Reply-To: <792231.90378.qm@web35903.mail.mud.yahoo.com>
References: <792231.90378.qm@web35903.mail.mud.yahoo.com>
Message-ID: <4702740B.5040803@amd.com>



Jonathan Sturges wrote:
> 
> ----- Original Message ----
> From: Marc Jones <marc.jones at amd.com>
> To: Jonathan Sturges <jonathansturges at yahoo.com>
> Cc: LinuxBIOS mailing list <linuxbios at linuxbios.org>
> Sent: Tuesday, September 25, 2007 12:05:19 PM
> Subject: Re: [LinuxBIOS] Two more CS5530 IRQ steering questions
> 
> 
> 
> Jonathan Sturges wrote:
>>>> Jonathan Sturges wrote:
>>>> Two additional questions about CS5530 IRQ steering:
>>>> 1)  Comments from Uwe Hermann and Peter Stuge have indicated that it's really better for the kernel to setup the steering registers.  Why is this?  It sounds like the BIOS is a good place to set these.  I assume that a knowledgeable OS could change them if necessary?  At the very least, it does sound like we all agree that it's OK to have LB setup the steering until Linux is fixed.
>>>>
>>>> 2)  Question about irq_tables.c.  Many of the CS5536 systems have a write_pirq_routing_table() in irq_tables.c that sets the steering registers.  I'd like to be able to set the steering registers in CS5530 systems too, but I'm not a software developer and I need some help.  So in src/mainboard/artecgroup/dbe61/irq_tables.c, you have:
>>>> /* Set up chipset IRQ steering. */
>>>> pciAddr = 0x80000000 | (CHIPSET_DEV_NUM << 11) | 0x5C;
>>>> chipset_irq_map = (PIRQD << 12 | PIRQC << 8 | PIRQB << 4 | PIRQA);
>>>> printk_debug("%s(%08X, %04X)\n", __FUNCTION__, pciAddr,
>>>>               chipset_irq_map);
>>>> outl(pciAddr & ~3, 0xCF8);
>>>> outl(chipset_irq_map, 0xCFC);My main question with this block of code is what the two outl() calls are for.  It looks like pciAddr gets the address of the 0x5c steering register, and chipset_irq_map sets the right bits to set all 4 PIRQ lines.  But I'd expect to see the chipset_irq_map written to pciAddr.
>>>>
>>>> As an alternative, Kenji Noguchi used this code block to set the registers in a CS5530 system he's working on (posted 5-May-2007):
>>>> device_t pdev;
>>>> //CS5530A
>>>> pdev = dev_find_slot(0, (0x12 << 3) + 0);
>>>> pci_write_config8(pdev, 0x5c, 0xab);
>>>> pci_write_config8(pdev, 0x5d, 0x09);
>>>>
>>>>
>>>> This block makes more sense to me.  Obviously the register values could be set by 
>>>> #defines, but it looks simpler to me.
>>>>
>>>> Bottom line is, before I implement IRQ steering for my CS5530 system, I want to understand what the first code block is doing, and if (or why) it's preferable over the 2nd code block.  Any guidance is appreciated.
>>>>
>>>> thanks,
>>>> Jonathan
>>>   
>>>
>>> outl(pciAddr & ~3, 0xCF8);
>>> outl(chipset_irq_map, 0xCFC)
>>>
>>> is basically the same as
>>>
>>> pci_write_config8(pdev, 0x5c, 0xab);
>>> pci_write_config8(pdev, 0x5d, 0x09);
>>>
>>>
>>> CFC/CF8 is the PCI config space.
>> Ahhh... thanks Marc, that was the clarification I needed.
>>
>> With that in mind, that block of code should work directly with the CS5530 after defining CHIPSET_DEV_NUM appropriately.  What about '0x80000000', is that a common base address applicable to all CS553x systems?
>>
>> thanks,
>> Jonathan
> 
> DEV_NUM should be a constant for the 5530. It is always hooked up on the 
> same IDSEL. The 0x80000000 is standard for all i/o based PCI config 
> accesses. It indicates that it is a config access and not just a normal 
> PCI i/o access.
> 
> Marc
> 
> 
> 
> Marc,
> I've implemented the CS5536-style IRQ steering register code from above in my CS5530 system.  This is what I'm using:
> /* Set up chipset IRQ steering. */
> pciAddr = 0x80000000 | (0x12 << 11) | 0x5C;
> chipset_irq_map = (PIRQD << 12 | PIRQC << 8 | PIRQB << 4 | PIRQA);
> printk_debug("%s(%08X, %04X)\n", __FUNCTION__, pciAddr,
>                chipset_irq_map);
> outl(pciAddr & ~3, 0xCF8);
> outl(chipset_irq_map, 0xCFC);
> 
> However, it doesn't seem to have worked entirely.  If it had worked, I assume I should be able to boot a standard Linux kernel and have IRQs worked for the devices in the PIRQ table.  Instead, these devices don't work, unless I boot a kernel with the CS5530 IRQ router patch.
> In the LB output, you get this from write_pirq_routing_table():
> 
> write_pirq_routing_table(8000905C, 99BA)
> 
> ...which I think is right.  It doesn't seem like there's much that could be wrong here.  Are the the steering bits reversed maybe?  The high 8 bits are for PIRQD and C, so that would screw things up if they were written to 0x5C, which is the INTB/INTA register.  Is there a reliable way to see the settings of the steering bits from a running system?
> 
> thanks,
> Jonathan
> 

Jonathan,

You can use lspci to get that information.
"lspci -xxxv" or "lspci -s 00:12.0 -xxxv" for just device 0x12

Marc


-- 
Marc Jones
Senior Firmware Engineer
(970) 226-9684 Office
mailto:Marc.Jones at amd.com
http://www.amd.com/embeddedprocessors





From jordan.crouse at amd.com  Tue Oct  2 18:36:25 2007
From: jordan.crouse at amd.com (Jordan Crouse)
Date: Tue, 2 Oct 2007 10:36:25 -0600
Subject: [LinuxBIOS] flashrom support for AMD Geode CS5536
In-Reply-To: <20071002162712.GA29819@coresystems.de>
References: <47026FBB.1080809@mit.edu> <20071002162712.GA29819@coresystems.de>
Message-ID: <20071002163625.GB16097@cosmic.amd.com>

On 02/10/07 18:27 +0200, Stefan Reinauer wrote:
> Dear Lane!
> 
> Thank you very much for your patch.
> 
> * Lane Brooks <lbrooks at MIT.EDU> [071002 18:20]:
> > - It seems like there should be a way to revert the msr back after flashing 
> > is completed to put the bios back in write protect mode.  Is there a 
> > cleanup mechanism available?  Something like disable_flash...
> 
> Unfortunately no. Any patches that generically implement such a
> mechanism are welcome though!
> 
> 
> > +#define _LARGEFILE64_SOURCE
> > +#include <sys/types.h>
> > +#include <sys/stat.h>
> > +#include <fcntl.h>
> > +#include <unistd.h>
> 
> > +	unsigned long addr = 0x1808;
> > +	lseek64(fd_msr, (off64_t) addr, SEEK_SET);
> 
> Why do you use/need large file support for seeking to an offset of
> 0x1808 ?

Thats original generic MSR behavior from rdmsr/wrmsr - we need the
large file support to access the high MSRs (0x80000000) and
above.  Its not needed in this case - but is it hurting?

Jordan
-- 
Jordan Crouse
Systems Software Development Engineer 
Advanced Micro Devices, Inc.





From rminnich at gmail.com  Tue Oct  2 18:42:35 2007
From: rminnich at gmail.com (ron minnich)
Date: Tue, 2 Oct 2007 09:42:35 -0700
Subject: [LinuxBIOS] flashrom support for AMD Geode CS5536
In-Reply-To: <20071002163625.GB16097@cosmic.amd.com>
References: <47026FBB.1080809@mit.edu> <20071002162712.GA29819@coresystems.de>
	<20071002163625.GB16097@cosmic.amd.com>
Message-ID: <13426df10710020942x447c62feyabe76d0cbac90a8d@mail.gmail.com>

BTW there is another unsolved issue here. The chip can support FWH or
LPC mode. I don't know how we should be handling that option.

ron



From c-d.hailfinger.devel.2006 at gmx.net  Tue Oct  2 18:44:48 2007
From: c-d.hailfinger.devel.2006 at gmx.net (Carl-Daniel Hailfinger)
Date: Tue, 02 Oct 2007 18:44:48 +0200
Subject: [LinuxBIOS] [PATCH] svn hooks: pre-commit signed-off/acked
	verification
In-Reply-To: <20071002161454.GA21206@coresystems.de>
References: <20071002161454.GA21206@coresystems.de>
Message-ID: <47027580.6070700@gmx.net>

This patch changes the pre-commit hook to check whether more than one
person has signed off/acked a patch. If that is not the case, it will
output a warning, but the commit will not fail.
It is possible to amend this hook to check for triviality of patches
later, but for now the warning is better than nothing.

Signed-off-by: Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006 at gmx.net>

---
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: linuxbios_hooks_check_signoff_ack_sameperson.diff
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20071002/de313b34/attachment.ksh>

From rminnich at gmail.com  Tue Oct  2 18:49:07 2007
From: rminnich at gmail.com (ron minnich)
Date: Tue, 2 Oct 2007 09:49:07 -0700
Subject: [LinuxBIOS] FILO
Message-ID: <13426df10710020949x54749556vfceb5e4792e46a3b@mail.gmail.com>

ok, with the fixes I sent, and latest v3, filo works fine on bochs,
fails on qemu.

hmm :-)

ron



From jordan.crouse at amd.com  Tue Oct  2 18:57:43 2007
From: jordan.crouse at amd.com (Jordan Crouse)
Date: Tue, 2 Oct 2007 10:57:43 -0600
Subject: [LinuxBIOS] flashrom support for AMD Geode CS5536
In-Reply-To: <47026FBB.1080809@mit.edu>
References: <47026FBB.1080809@mit.edu>
Message-ID: <20071002165743.GC16097@cosmic.amd.com>

On 02/10/07 10:20 -0600, Lane Brooks wrote:
> Attached is a patch that enables AMD Geode CS5536 chipset support.  I 
> have tested it successfully on a MSM800 board from digital logic.  It 
> does, however, have a few issues that I would like some feedback on.

NAK for now - its not working on the Norwich.  I am debugging.

Jordan





From stepan at coresystems.de  Tue Oct  2 19:01:26 2007
From: stepan at coresystems.de (Stefan Reinauer)
Date: Tue, 2 Oct 2007 19:01:26 +0200
Subject: [LinuxBIOS] flashrom support for AMD Geode CS5536
In-Reply-To: <13426df10710020938x276d2c3ewf797f82d035d1bd7@mail.gmail.com>
References: <47026FBB.1080809@mit.edu>
	<13426df10710020938x276d2c3ewf797f82d035d1bd7@mail.gmail.com>
Message-ID: <20071002170126.GA27919@coresystems.de>

* ron minnich <rminnich at gmail.com> [071002 18:38]:
> > My questions are:
> > - I do not think this is portable beyond linux.  Is that an issue?
> 
> it's not, but it is not really an issue at present.

Maybe the code should be #ifdef'ed __linux__ with an #else case just
printing a warning a la "Not supported by this OS yet."

> I thought that was in the structure of flashrom. Now that I look, it
> seems like we lost it!

Flashrom never did any such cleanup. I was about to implement it when we
renamed the tool but then I stumbled upon this:

printf("OK, only ENABLING flash write, but NOT FLASHING.\n");

So obviously at some point there was a sense in leaving the system in
such a state. But I want to propose that we drop this behavior and
instead try to always leave the machine in the state we entered it.
Especially when not flashing.

While one might want to mess with an unprotected flash on purpose, for
99% of the cases this is just opening another security issue.
That one % that theoretically might use this as a feature is welcome to
improve the flashrom utility instead of running it for flash
unprotection before running another utility.

> I propose this at the end of flashrom:
> board_flash_disable(lb_vendor, lb_part);
> chipset_flash_disable(chipset);

yepp. Agreed.


> but we'll need to change some things to make this all work. We need a
> penable struct * to use for the disable; no point in searching each
> time we touch a chip. or not?

To achieve this

struct board_pciid_enable *board in board_enable.c:board_flash_enable() 

and

enables[i] in chipset_enable.c:chipset_flash_enable() 

should be globally available.



-- 
coresystems GmbH ? Brahmsstr. 16 ? D-79104 Freiburg i. Br.
      Tel.: +49 761 7668825 ? Fax: +49 761 7664613
Email: info at coresystems.de  ? http://www.coresystems.de/
Registergericht: Amtsgericht Freiburg ? HRB 7656
Gesch?ftsf?hrer: Stefan Reinauer ? Ust-IdNr.: DE245674866



From svn at openbios.org  Tue Oct  2 19:04:57 2007
From: svn at openbios.org (svn at openbios.org)
Date: Tue,  2 Oct 2007 19:04:57 +0200
Subject: [LinuxBIOS] r36 - in trunk/filo-0.5: i386 main
Message-ID: <mailman.689.1355071171.16123.coreboot@coreboot.org>

Author: rminnich
Date: 2007-10-02 19:04:57 +0200 (Tue, 02 Oct 2007)
New Revision: 36

Modified:
   trunk/filo-0.5/i386/sys_info.c
   trunk/filo-0.5/main/linuxbios.c
Log:


1. fix spelling error. 
2. paranoid setting of info->memrange to 0
3. don't use malloc when it is not possible to use malloc. 

Signed-off-by: Ronald G. Minnich <rminnich at gmail.com>
Acked-by: Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006 at gmx.net>


Modified: trunk/filo-0.5/i386/sys_info.c
===================================================================
--- trunk/filo-0.5/i386/sys_info.c	2007-09-23 22:33:38 UTC (rev 35)
+++ trunk/filo-0.5/i386/sys_info.c	2007-10-02 17:04:57 UTC (rev 36)
@@ -11,6 +11,8 @@
 {
     int i;
     unsigned long long total = 0;
+    /* this fake memory range covers the case that we can't find any LB structs. */
+    static struct memrange fakememrange[2];
 
     /* Pick up paramters given by bootloader to us */
     info->boot_type = boot_ctx->eax;
@@ -30,7 +32,12 @@
 	printf("Can't get memory map from firmware. "
 		"Using hardcoded default.\n");
 	info->n_memranges = 2;
-	info->memrange = malloc(2 * sizeof(struct memrange));
+	/* NOTE: DO NOT USE MALLOC HERE *
+	 * malloc structs are not initialized until this information is filled in. 
+         * Use of malloc will create a circular dependency. So use
+         * the static allocated above. 
+         */
+	info->memrange = fakememrange;
 	info->memrange[0].base = 0;
 	info->memrange[0].size = 640*1024;
 	info->memrange[1].base = 1024*1024;

Modified: trunk/filo-0.5/main/linuxbios.c
===================================================================
--- trunk/filo-0.5/main/linuxbios.c	2007-09-23 22:33:38 UTC (rev 35)
+++ trunk/filo-0.5/main/linuxbios.c	2007-10-02 17:04:57 UTC (rev 36)
@@ -89,7 +89,7 @@
 		}
 		if (head->header_bytes != sizeof(*head))
 			continue;
-		debug("Found canidate at: %p\n", head);
+		debug("Found candidate at: %p\n", head);
 		if (ipchksum((uint16_t *)head, sizeof(*head)) != 0) 
 			continue;
 		debug("header checksum o.k.\n");
@@ -114,6 +114,7 @@
 	struct lb_header *lb_table;
 	int found;
 	debug("Searching for LinuxBIOS tables...\n");
+	info->memrange = NULL;
 	found = 0;
 	if (!found) {
 		found = find_lb_table(phys_to_virt(0x00000), phys_to_virt(0x01000), &lb_table);




From rminnich at gmail.com  Tue Oct  2 19:06:11 2007
From: rminnich at gmail.com (ron minnich)
Date: Tue, 2 Oct 2007 10:06:11 -0700
Subject: [LinuxBIOS] filo and v3
In-Reply-To: <47026B99.4070608@gmx.net>
References: <13426df10710020831t3ad669e3ua61a00e53f48a696@mail.gmail.com>
	<4702674B.7@gmx.net>
	<13426df10710020851t19c20bb8oc22ed7ccf45e33f9@mail.gmail.com>
	<47026B99.4070608@gmx.net>
Message-ID: <13426df10710021006m3186ac7mb7554b413ab3f0c8@mail.gmail.com>

On 10/2/07, Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006 at gmx.net> wrote:

> Except for the comments below:
> Acked-by: Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006 at gmx.net>

Committed, with mods per your comments,
Committed revision 36.



From lbrooks at MIT.EDU  Tue Oct  2 19:32:52 2007
From: lbrooks at MIT.EDU (Lane Brooks)
Date: Tue, 02 Oct 2007 11:32:52 -0600
Subject: [LinuxBIOS] flashrom support for AMD Geode CS5536
In-Reply-To: <20071002163625.GB16097@cosmic.amd.com>
References: <47026FBB.1080809@mit.edu> <20071002162712.GA29819@coresystems.de>
	<20071002163625.GB16097@cosmic.amd.com>
Message-ID: <470280C4.4000609@mit.edu>

Jordan Crouse wrote:
> On 02/10/07 18:27 +0200, Stefan Reinauer wrote:
>> Dear Lane!
>>
>> Thank you very much for your patch.
>>
>> * Lane Brooks <lbrooks at MIT.EDU> [071002 18:20]:
>>> - It seems like there should be a way to revert the msr back after flashing 
>>> is completed to put the bios back in write protect mode.  Is there a 
>>> cleanup mechanism available?  Something like disable_flash...
>> Unfortunately no. Any patches that generically implement such a
>> mechanism are welcome though!
>>
>>
>>> +#define _LARGEFILE64_SOURCE
>>> +#include <sys/types.h>
>>> +#include <sys/stat.h>
>>> +#include <fcntl.h>
>>> +#include <unistd.h>
>>> +	unsigned long addr = 0x1808;
>>> +	lseek64(fd_msr, (off64_t) addr, SEEK_SET);
>> Why do you use/need large file support for seeking to an offset of
>> 0x1808 ?
> 
> Thats original generic MSR behavior from rdmsr/wrmsr - we need the
> large file support to access the high MSRs (0x80000000) and
> above.  Its not needed in this case - but is it hurting?
> 
> Jordan


Jordan brings up a point that I forgot to mention previously.  This is 
my first time contributing to an open source project, and I am not 
extremely familiar with protocols in terms of acknowledging code.  I 
based this patch on rdmsr/wrmsr code I found on the OLPC webpage, and it 
seems attributable to Ron Minnich.  Should I acknowledge this fact in 
the code?

Furthermore, I debated whether I should include the generic rdmsr/wrmsr 
functions rather than incorporating them into the flash_enable_cs5526() 
function.  I chose not to include the generic functions because it 
seemed a cleaner approach in the grand scheme of the flashrom code base 
given that non of the other chipset enable functions seem to require 
helper functions.  Any feedback on this point?  Will other chipsets ever 
need to use the MSR to unlock the bios?

Lane



From jordan.crouse at amd.com  Tue Oct  2 19:38:02 2007
From: jordan.crouse at amd.com (Jordan Crouse)
Date: Tue, 2 Oct 2007 11:38:02 -0600
Subject: [LinuxBIOS] flashrom support for AMD Geode CS5536
In-Reply-To: <20071002165743.GC16097@cosmic.amd.com>
References: <47026FBB.1080809@mit.edu> <20071002165743.GC16097@cosmic.amd.com>
Message-ID: <20071002173802.GA27248@cosmic.amd.com>

On 02/10/07 10:57 -0600, Jordan Crouse wrote:
> On 02/10/07 10:20 -0600, Lane Brooks wrote:
> > Attached is a patch that enables AMD Geode CS5536 chipset support.  I 
> > have tested it successfully on a MSM800 board from digital logic.  It 
> > does, however, have a few issues that I would like some feedback on.
> 
> NAK for now - its not working on the Norwich.  I am debugging.

NAK my NAK (making it an ACK).  I put in a larger ROM and confused the
MSR.

Jordan
-- 
Jordan Crouse
Systems Software Development Engineer 
Advanced Micro Devices, Inc.





From jordan.crouse at amd.com  Tue Oct  2 19:40:33 2007
From: jordan.crouse at amd.com (Jordan Crouse)
Date: Tue, 2 Oct 2007 11:40:33 -0600
Subject: [LinuxBIOS] flashrom support for AMD Geode CS5536
In-Reply-To: <470280C4.4000609@mit.edu>
References: <47026FBB.1080809@mit.edu> <20071002162712.GA29819@coresystems.de>
	<20071002163625.GB16097@cosmic.amd.com> <470280C4.4000609@mit.edu>
Message-ID: <20071002174033.GB27248@cosmic.amd.com>

On 02/10/07 11:32 -0600, Lane Brooks wrote:
> Jordan Crouse wrote:
> >On 02/10/07 18:27 +0200, Stefan Reinauer wrote:
> >>Dear Lane!
> >>
> >>Thank you very much for your patch.
> >>
> >>* Lane Brooks <lbrooks at MIT.EDU> [071002 18:20]:
> >>>- It seems like there should be a way to revert the msr back after 
> >>>flashing is completed to put the bios back in write protect mode.  Is 
> >>>there a cleanup mechanism available?  Something like disable_flash...
> >>Unfortunately no. Any patches that generically implement such a
> >>mechanism are welcome though!
> >>
> >>
> >>>+#define _LARGEFILE64_SOURCE
> >>>+#include <sys/types.h>
> >>>+#include <sys/stat.h>
> >>>+#include <fcntl.h>
> >>>+#include <unistd.h>
> >>>+	unsigned long addr = 0x1808;
> >>>+	lseek64(fd_msr, (off64_t) addr, SEEK_SET);
> >>Why do you use/need large file support for seeking to an offset of
> >>0x1808 ?
> >
> >Thats original generic MSR behavior from rdmsr/wrmsr - we need the
> >large file support to access the high MSRs (0x80000000) and
> >above.  Its not needed in this case - but is it hurting?
> >
> >Jordan
> 
> 
> Jordan brings up a point that I forgot to mention previously.  This is 
> my first time contributing to an open source project, and I am not 
> extremely familiar with protocols in terms of acknowledging code.  I 
> based this patch on rdmsr/wrmsr code I found on the OLPC webpage, and it 
> seems attributable to Ron Minnich.  Should I acknowledge this fact in 
> the code?

I can't remember if it was Ron or I that wrote them - maybe a little
of both.  Those were good times.. :)

Anyway - I am of the opinion that this code is of such trival nature that
it borders on the obvious - its neither enlightening nor novel - and as 
such attribution probably isn't called for - unless you really want to.

Jordan
-- 
Jordan Crouse
Systems Software Development Engineer 
Advanced Micro Devices, Inc.





From jordan.crouse at amd.com  Tue Oct  2 19:53:46 2007
From: jordan.crouse at amd.com (Jordan Crouse)
Date: Tue, 2 Oct 2007 11:53:46 -0600
Subject: [LinuxBIOS] [FLASHROM] Fix the help,
 and print a message when nothing happens
Message-ID: <20071002175346.GC27248@cosmic.amd.com>

I have used flashrom just little enough to forget that -w isn't implied,
and wonder why nothing happened.  This fixes the help, and says something
at the end of no operations are specified.  Just a little user-friendliness
from your good friends at LinuxBIOS.

Jordan
-- 
Jordan Crouse
Systems Software Development Engineer 
Advanced Micro Devices, Inc.
-------------- next part --------------
[FLASHROM] Fix the help, and print a message when nothing happens

The help implied that writes happen by default, which they don't.  Fix
the text, and say something when we get to the bottom and nothing happened.

Signed-off-by: Jordan Crouse <jordan.crouse at amd.com>

Index: flashrom/flashrom.c
===================================================================
--- flashrom.orig/flashrom.c	2007-10-02 11:43:38.000000000 -0600
+++ flashrom/flashrom.c	2007-10-02 11:45:51.000000000 -0600
@@ -195,8 +195,7 @@
 	printf("       [-e exclude_end] [-m vendor:part] [-l file.layout] [-i imagename] [file]\n");
 	printf
 	    ("   -r | --read:                    read flash and save into file\n"
-	     "   -w | --write:                   write file into flash (default when\n"
-	     "                                   file is specified)\n"
+	     "   -w | --write:                   write file into flash\n"
 	     "   -v | --verify:                  verify flash against file\n"
 	     "   -E | --erase:                   erase flash device\n"
 	     "   -V | --verbose:                 more verbose output\n"
@@ -456,5 +455,9 @@
 	if (verify_it)
 		ret |= verify_flash(flash, buf);
 
+	if (!(read_it|write_it|verify_it|erase_it)) {
+		printf("No operations were specified.\n");
+	}
+
 	return ret;
 }

From lbrooks at MIT.EDU  Tue Oct  2 20:00:16 2007
From: lbrooks at MIT.EDU (Lane Brooks)
Date: Tue, 02 Oct 2007 12:00:16 -0600
Subject: [LinuxBIOS] flashrom support for AMD Geode CS5536
In-Reply-To: <13426df10710020938x276d2c3ewf797f82d035d1bd7@mail.gmail.com>
References: <47026FBB.1080809@mit.edu>
	<13426df10710020938x276d2c3ewf797f82d035d1bd7@mail.gmail.com>
Message-ID: <47028730.70305@mit.edu>

Here is the patch again with an updated comment regarding SMP and a 
signed-off-by line.

Signed-off-by: Lane Brooks <lbrooks at mit.edu>

ron minnich wrote:
> On 10/2/07, Lane Brooks <lbrooks at mit.edu> wrote:
>> Attached is a patch that enables AMD Geode CS5536 chipset support.  I
>> have tested it successfully on a MSM800 board from digital logic.  It
>> does, however, have a few issues that I would like some feedback on.
>>
>> In my discussions with Marc Jones, Geode systems write protect the BIOS
>> via RCONFs (cache settings similar to MTRRs). Unlocking requires
>> changing MSR 0x1808 top byte to 0x22. Reading and writing to the msr,
>> however, requires instrucitons rdmsr/wrmsr, which are ring0 privileged
>> instructions so only the kernel can do the read/write.  So my patch uses
>> the msr kernel module to access these instructions from user space using
>> the /dev/cpu/0/msr device.
>>
>> My questions are:
>> - I do not think this is portable beyond linux.  Is that an issue?
> 
> it's not, but it is not really an issue at present.
>> - My code assumes the msr kernel module is already loaded.  Is there a
>> way to force a kernel module to load from the C code?  My code does die
>> gracefully with a message reminding them to load the kernel module if
>> things fail.
> 
> it is possible I think to have udev help with this, but I am not sure.
> Graceful failure is certainly a good start.
> 
>> - It seems like there should be a way to revert the msr back after
>> flashing is completed to put the bios back in write protect mode.  Is
>> there a cleanup mechanism available?  Something like disable_flash...
> 
> I thought that was in the structure of flashrom. Now that I look, it
> seems like we lost it!
> I propose this at the end of flashrom:
> board_flash_disable(lb_vendor, lb_part);
> chipset_flash_disable(chipset);
> 
> but we'll need to change some things to make this all work. We need a
> penable struct * to use for the disable; no point in searching each
> time we touch a chip. or not?
> 
> one comment on your patch: you use /dev/cpu/0/msr. This is great for a
> single-cpu machine, and will always be fine on  geode. Lots of times,
> people use one piece of flashrom to write another. Imagine some future
> hacker, in a year or two, who has copied your code for some SMP
> system, not understanding why sometimes flashrom fails (i.e. they set
> CPU0 msr but end up running on cpu1). We had this very problem when we
> were getting graphics going (and, earlier, SMP going). I suggest a
> comment as to why the /dev/cpu/0/msr is always safe on geode, but
> future hackers beware on SMP. Or something like that.
> 
> That's up to you, however :-)
> 
> If you had a signed-off-by line, I would ack and commit for you :-)
> 
> ron
> 
> ron



From ward at gnu.org  Tue Oct  2 20:00:52 2007
From: ward at gnu.org (Ward Vandewege)
Date: Tue, 2 Oct 2007 14:00:52 -0400
Subject: [LinuxBIOS] [FLASHROM] Fix the help,
	and print a message when nothing happens
In-Reply-To: <20071002175346.GC27248@cosmic.amd.com>
References: <20071002175346.GC27248@cosmic.amd.com>
Message-ID: <20071002180052.GA14795@localdomain>

On Tue, Oct 02, 2007 at 11:53:46AM -0600, Jordan Crouse wrote:
> [FLASHROM] Fix the help, and print a message when nothing happens
> 
> The help implied that writes happen by default, which they don't.  Fix
> the text, and say something when we get to the bottom and nothing happened.
> 
> Signed-off-by: Jordan Crouse <jordan.crouse at amd.com>

Acked-by: Ward Vandewege <ward at gnu.org>

Thanks!
Ward.

-- 
Ward Vandewege <ward at fsf.org>
Free Software Foundation - Senior System Administrator



From lbrooks at MIT.EDU  Tue Oct  2 20:03:48 2007
From: lbrooks at MIT.EDU (Lane Brooks)
Date: Tue, 02 Oct 2007 12:03:48 -0600
Subject: [LinuxBIOS] flashrom support for AMD Geode CS5536
In-Reply-To: <47028730.70305@mit.edu>
References: <47026FBB.1080809@mit.edu>	<13426df10710020938x276d2c3ewf797f82d035d1bd7@mail.gmail.com>
	<47028730.70305@mit.edu>
Message-ID: <47028804.4020502@mit.edu>

Here it is again with the patch actually attached.

Lane Brooks wrote:
> Here is the patch again with an updated comment regarding SMP and a 
> signed-off-by line.
> 
> Signed-off-by: Lane Brooks <lbrooks at mit.edu>
> 
> ron minnich wrote:
>> On 10/2/07, Lane Brooks <lbrooks at mit.edu> wrote:
>>> Attached is a patch that enables AMD Geode CS5536 chipset support.  I
>>> have tested it successfully on a MSM800 board from digital logic.  It
>>> does, however, have a few issues that I would like some feedback on.
>>>
>>> In my discussions with Marc Jones, Geode systems write protect the BIOS
>>> via RCONFs (cache settings similar to MTRRs). Unlocking requires
>>> changing MSR 0x1808 top byte to 0x22. Reading and writing to the msr,
>>> however, requires instrucitons rdmsr/wrmsr, which are ring0 privileged
>>> instructions so only the kernel can do the read/write.  So my patch uses
>>> the msr kernel module to access these instructions from user space using
>>> the /dev/cpu/0/msr device.
>>>
>>> My questions are:
>>> - I do not think this is portable beyond linux.  Is that an issue?
>> it's not, but it is not really an issue at present.
>>> - My code assumes the msr kernel module is already loaded.  Is there a
>>> way to force a kernel module to load from the C code?  My code does die
>>> gracefully with a message reminding them to load the kernel module if
>>> things fail.
>> it is possible I think to have udev help with this, but I am not sure.
>> Graceful failure is certainly a good start.
>>
>>> - It seems like there should be a way to revert the msr back after
>>> flashing is completed to put the bios back in write protect mode.  Is
>>> there a cleanup mechanism available?  Something like disable_flash...
>> I thought that was in the structure of flashrom. Now that I look, it
>> seems like we lost it!
>> I propose this at the end of flashrom:
>> board_flash_disable(lb_vendor, lb_part);
>> chipset_flash_disable(chipset);
>>
>> but we'll need to change some things to make this all work. We need a
>> penable struct * to use for the disable; no point in searching each
>> time we touch a chip. or not?
>>
>> one comment on your patch: you use /dev/cpu/0/msr. This is great for a
>> single-cpu machine, and will always be fine on  geode. Lots of times,
>> people use one piece of flashrom to write another. Imagine some future
>> hacker, in a year or two, who has copied your code for some SMP
>> system, not understanding why sometimes flashrom fails (i.e. they set
>> CPU0 msr but end up running on cpu1). We had this very problem when we
>> were getting graphics going (and, earlier, SMP going). I suggest a
>> comment as to why the /dev/cpu/0/msr is always safe on geode, but
>> future hackers beware on SMP. Or something like that.
>>
>> That's up to you, however :-)
>>
>> If you had a signed-off-by line, I would ack and commit for you :-)
>>
>> ron
>>
>> ron
> 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: cs5536.patch
Type: text/x-patch
Size: 2397 bytes
Desc: not available
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20071002/b620f8d8/attachment.patch>

From bishop.robinson at gmail.com  Tue Oct  2 20:34:37 2007
From: bishop.robinson at gmail.com (Robinson Tryon)
Date: Tue, 2 Oct 2007 14:34:37 -0400
Subject: [LinuxBIOS] Call for help: superiotool
In-Reply-To: <470268D0.9050107@gmx.net>
References: <20070923111315.GC12926@greenwood>
	<a698c16a0709270921l860615dv3ebe8d49e2f4c791@mail.gmail.com>
	<46FBDB3E.4000009@gmx.net>
	<a698c16a0710012037l37bc9d07i6628563002d7e47a@mail.gmail.com>
	<470256CB.9060008@gmx.net>
	<a698c16a0710020844ud12485dhb063f76800170b63@mail.gmail.com>
	<470268D0.9050107@gmx.net>
Message-ID: <a698c16a0710021134y55112a45r728d171e7926e94c@mail.gmail.com>

On 10/2/07, Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006 at gmx.net> wrote:
> On 02.10.2007 17:44, Robinson Tryon wrote:
> > Hmm... is it possible that the Satellite 1415 doesn't have a Super I/O ?
>
> Probably the Super I/O is inside the embedded controller and responds to
> a special probe sequence.

Ah, interesting.

>
> However, the probing sequence is incomplete (at least when judging it by
> its output) and Uwe rewrote the probing sequence, so he can take a look
> at it.
>
> > (could verbose mode please print out the version # ?)
>
> Good idea. Care to send a patch?

Sure -- see attachment.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: superiotool.patch
Type: application/octet-stream
Size: 1347 bytes
Desc: not available
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20071002/a7c3ef5e/attachment.obj>

From ward at gnu.org  Tue Oct  2 20:42:37 2007
From: ward at gnu.org (Ward Vandewege)
Date: Tue, 2 Oct 2007 14:42:37 -0400
Subject: [LinuxBIOS] Call for help: superiotool
In-Reply-To: <a698c16a0710021134y55112a45r728d171e7926e94c@mail.gmail.com>
References: <20070923111315.GC12926@greenwood>
	<a698c16a0709270921l860615dv3ebe8d49e2f4c791@mail.gmail.com>
	<46FBDB3E.4000009@gmx.net>
	<a698c16a0710012037l37bc9d07i6628563002d7e47a@mail.gmail.com>
	<470256CB.9060008@gmx.net>
	<a698c16a0710020844ud12485dhb063f76800170b63@mail.gmail.com>
	<470268D0.9050107@gmx.net>
	<a698c16a0710021134y55112a45r728d171e7926e94c@mail.gmail.com>
Message-ID: <20071002184237.GA15345@localdomain>

Hi Robinson,

On Tue, Oct 02, 2007 at 02:34:37PM -0400, Robinson Tryon wrote:
> > > (could verbose mode please print out the version # ?)
> >
> > Good idea. Care to send a patch?
> 
> Sure -- see attachment.

Could you resend with a signed-off-by?

Thanks,
Ward.

-- 
Ward Vandewege <ward at fsf.org>
Free Software Foundation - Senior System Administrator



From rminnich at gmail.com  Tue Oct  2 21:10:50 2007
From: rminnich at gmail.com (ron minnich)
Date: Tue, 2 Oct 2007 12:10:50 -0700
Subject: [LinuxBIOS] flashrom support for AMD Geode CS5536
In-Reply-To: <470280C4.4000609@mit.edu>
References: <47026FBB.1080809@mit.edu> <20071002162712.GA29819@coresystems.de>
	<20071002163625.GB16097@cosmic.amd.com> <470280C4.4000609@mit.edu>
Message-ID: <13426df10710021210h19d2c581yd0576c2ebbedff26@mail.gmail.com>

On 10/2/07, Lane Brooks <lbrooks at mit.edu> wrote:

> Jordan brings up a point that I forgot to mention previously.  This is
> my first time contributing to an open source project, and I am not
> extremely familiar with protocols in terms of acknowledging code.  I
> based this patch on rdmsr/wrmsr code I found on the OLPC webpage, and it
> seems attributable to Ron Minnich.  Should I acknowledge this fact in
> the code?

Ollie Lo wrote that, but it's pretty standard stuff. No need I think
unless Ollie wants it.

ron



From rminnich at gmail.com  Tue Oct  2 21:18:31 2007
From: rminnich at gmail.com (ron minnich)
Date: Tue, 2 Oct 2007 12:18:31 -0700
Subject: [LinuxBIOS] patch: filo
Message-ID: <13426df10710021218o70c53799wf7d8e987524472b0@mail.gmail.com>

A more formal patch; can someone test?

ron
-------------- next part --------------
A non-text attachment was scrubbed...
Name: filo.hdb.diff
Type: text/x-patch
Size: 3576 bytes
Desc: not available
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20071002/6c770cf9/attachment.diff>

From ollie at lanl.gov  Tue Oct  2 21:20:14 2007
From: ollie at lanl.gov (Li-Ta Lo)
Date: Tue, 02 Oct 2007 13:20:14 -0600
Subject: [LinuxBIOS] flashrom support for AMD Geode CS5536
In-Reply-To: <13426df10710021210h19d2c581yd0576c2ebbedff26@mail.gmail.com>
References: <47026FBB.1080809@mit.edu> <20071002162712.GA29819@coresystems.de>
	<20071002163625.GB16097@cosmic.amd.com> <470280C4.4000609@mit.edu>
	<13426df10710021210h19d2c581yd0576c2ebbedff26@mail.gmail.com>
Message-ID: <1191352814.3001.0.camel@exponential.lanl.gov>

On Tue, 2007-10-02 at 12:10 -0700, ron minnich wrote:
> On 10/2/07, Lane Brooks <lbrooks at mit.edu> wrote:
> 
> > Jordan brings up a point that I forgot to mention previously.  This is
> > my first time contributing to an open source project, and I am not
> > extremely familiar with protocols in terms of acknowledging code.  I
> > based this patch on rdmsr/wrmsr code I found on the OLPC webpage, and it
> > seems attributable to Ron Minnich.  Should I acknowledge this fact in
> > the code?
> 
> Ollie Lo wrote that, but it's pretty standard stuff. No need I think
> unless Ollie wants it.
> 

It was nothing. Take it as public domain if I didn't put any license in 
it.

Ollie





From corey.osgood at gmail.com  Tue Oct  2 21:24:48 2007
From: corey.osgood at gmail.com (Corey Osgood)
Date: Tue, 02 Oct 2007 15:24:48 -0400
Subject: [LinuxBIOS] LinuxBios on a HP ePC C10 to speed up boot time
In-Reply-To: <272757430710020304lf39148eld1bc435b7e3d0ce2@mail.gmail.com>
References: <272757430710020304lf39148eld1bc435b7e3d0ce2@mail.gmail.com>
Message-ID: <47029B00.8@gmail.com>

giraut benoit wrote:
> Hello
>
> Is it possible to use linuxbios on a ePC C10 computer ?  it is using
> Intel Whitney 82810E that is supported now by linuxbios.
>
> The original bios take horrible long time to boot  (~13 secondes to
> get the HP splash screen).
> Do you think the linuxbios can speedup the boot time or it is a
> hardware problem ?
>
> Thx for your help
>
> benoit

LinuxBIOS has been ported partially to the 82810 northbridge, but the
work isn't complete. Video isn't working yet, and it currently takes
quite a while to boot. IIRC, the 82810E also has some very minor
differences, I'd have to look at the datasheets again to know for sure.
Once linuxbios is fully ported, it should work great. That's something
I'd like to get back to, but I currently have no time to dedicate to it.

-Corey



From bishop.robinson at gmail.com  Tue Oct  2 21:26:20 2007
From: bishop.robinson at gmail.com (Robinson Tryon)
Date: Tue, 2 Oct 2007 15:26:20 -0400
Subject: [LinuxBIOS] Call for help: superiotool
In-Reply-To: <a698c16a0710021134y55112a45r728d171e7926e94c@mail.gmail.com>
References: <20070923111315.GC12926@greenwood>
	<a698c16a0709270921l860615dv3ebe8d49e2f4c791@mail.gmail.com>
	<46FBDB3E.4000009@gmx.net>
	<a698c16a0710012037l37bc9d07i6628563002d7e47a@mail.gmail.com>
	<470256CB.9060008@gmx.net>
	<a698c16a0710020844ud12485dhb063f76800170b63@mail.gmail.com>
	<470268D0.9050107@gmx.net>
	<a698c16a0710021134y55112a45r728d171e7926e94c@mail.gmail.com>
Message-ID: <a698c16a0710021226t4aa59cdahd99611f032e4bfde@mail.gmail.com>

On 10/2/07, Robinson Tryon <bishop.robinson at gmail.com> wrote:
> > > (could verbose mode please print out the version # ?)
> >
> > Good idea. Care to send a patch?
>
> Sure -- see attachment.
>

Sorry about that. Here's my signed-off by:

Signed-off-by: Robinson P. Tryon <bishop.robinson at gmail.com>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: superiotool.patch
Type: application/octet-stream
Size: 1347 bytes
Desc: not available
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20071002/718700e7/attachment.obj>

From rminnich at gmail.com  Tue Oct  2 21:26:25 2007
From: rminnich at gmail.com (ron minnich)
Date: Tue, 2 Oct 2007 12:26:25 -0700
Subject: [LinuxBIOS] my filo patch
Message-ID: <13426df10710021226i6e4a6c93sb62e3a26a42ff344@mail.gmail.com>

well, I was naive! Turns out filo maintains its own heap, unlike
linuxbios. I will back my erroneous patch out. I'm still not sure
what's wrong here. It's a weird problem, may just be unitialized
memory. But .... filo + v3 + qemu used to work for me.

ron



From svn at openbios.org  Tue Oct  2 21:30:23 2007
From: svn at openbios.org (svn at openbios.org)
Date: Tue,  2 Oct 2007 21:30:23 +0200
Subject: [LinuxBIOS] r37 - trunk/filo-0.5/i386
Message-ID: <mailman.690.1355071171.16123.coreboot@coreboot.org>

Author: rminnich
Date: 2007-10-02 21:30:23 +0200 (Tue, 02 Oct 2007)
New Revision: 37

Modified:
   trunk/filo-0.5/i386/sys_info.c
Log:
Undo erroneous patch. 
Signed-off-by: Ronald G. Minnich <rminnich at gmail.com>
Acked-by: Ronald G. Minnich <rminnich at gmail.com>



Modified: trunk/filo-0.5/i386/sys_info.c
===================================================================
--- trunk/filo-0.5/i386/sys_info.c	2007-10-02 17:04:57 UTC (rev 36)
+++ trunk/filo-0.5/i386/sys_info.c	2007-10-02 19:30:23 UTC (rev 37)
@@ -11,8 +11,6 @@
 {
     int i;
     unsigned long long total = 0;
-    /* this fake memory range covers the case that we can't find any LB structs. */
-    static struct memrange fakememrange[2];
 
     /* Pick up paramters given by bootloader to us */
     info->boot_type = boot_ctx->eax;
@@ -32,12 +30,7 @@
 	printf("Can't get memory map from firmware. "
 		"Using hardcoded default.\n");
 	info->n_memranges = 2;
-	/* NOTE: DO NOT USE MALLOC HERE *
-	 * malloc structs are not initialized until this information is filled in. 
-         * Use of malloc will create a circular dependency. So use
-         * the static allocated above. 
-         */
-	info->memrange = fakememrange;
+	info->memrange = malloc(2 * sizeof(struct memrange));
 	info->memrange[0].base = 0;
 	info->memrange[0].size = 640*1024;
 	info->memrange[1].base = 1024*1024;




From jordan.crouse at amd.com  Tue Oct  2 22:00:34 2007
From: jordan.crouse at amd.com (Jordan Crouse)
Date: Tue, 2 Oct 2007 14:00:34 -0600
Subject: [LinuxBIOS] [BUILDROM] Clean up some files that are no longer
 needed or never used
Message-ID: <20071002200034.GD27248@cosmic.amd.com>

I was going through buildrom today, and found some files that are not useful
to us, so this patch removes them.

-- 
Jordan Crouse
Systems Software Development Engineer 
Advanced Micro Devices, Inc.
-------------- next part --------------
[BUILDROM] Clean up some files that are no longer needed or never used

Remove files that snuck in there by mistake or are no longer needed.

Signed-off-by: Jordan Crouse <jordan.crouse at amd.com>
Index: buildrom-devel/packages/bin/README
===================================================================
--- buildrom-devel.orig/packages/bin/README	2007-10-03 11:47:24.000000000 -0600
+++ /dev/null	1970-01-01 00:00:00.000000000 +0000
@@ -1,4 +0,0 @@
-This directory contains the binary bits that make up various parts of the 
-ROM:
-
-olpc_vsa.64k.bin - VSA code for the ROM.  Stored from 32k to 64k in the ROM.
Index: buildrom-devel/packages/bin/README.md5sums
===================================================================
--- buildrom-devel.orig/packages/bin/README.md5sums	2007-10-03 11:47:24.000000000 -0600
+++ /dev/null	1970-01-01 00:00:00.000000000 +0000
@@ -1 +0,0 @@
-fdf7a6ed9f3d27b901b87e30dce5a14d  olpc_vsa.64k.bin
Index: buildrom-devel/packages/nanox/conf/defconfig
===================================================================
--- buildrom-devel.orig/packages/nanox/conf/defconfig	2007-10-03 11:45:19.000000000 -0600
+++ /dev/null	1970-01-01 00:00:00.000000000 +0000
@@ -1,386 +0,0 @@
-####################################################################
-# Microwindows and Nano-X configuration file
-#
-# This package can be configured to run on Linux (MIPS, ARM, POWERPC or x86)
-# UNIX, ELKS, DJGPP, or RTEMS.
-# On Linux, we've got drivers for Linux 2.x framebuffers, X11, or,
-# svgalib for VGA hardware.
-# In addition, a gpm or direct serial mouse driver can be configured.
-# On ELKS, the bios screen driver and serial mouse driver are always used.
-#
-# Either Microwindows and/or Nano-X can be built.
-# Microwindows and Nano-X have several demos.
-#
-# For MSDOS makes, see mcmwin.mak and mcnanox.mak
-####################################################################
-
-####################################################################
-#
-# build target platform
-#
-# Valid ARCH values are:
-#
-# LINUX-NATIVE
-# LINUX-TCC
-# LINUX-ARM
-# LINUX-MIPS
-# LINUX-POWERPC (BIGENDIAN=Y)
-# LINUX-SPARC (BIGENDIAN=Y)
-# LINUX-SH
-# FREEBSD-X86
-# SOLARIS (BIGENDIAN=Y)
-# TRIMEDIA
-# RTEMS
-# DJGPP
-# ELKS
-#
-# note: ELKS can't build client/server nano-X, nor widget lib
-#
-####################################################################
-ARCH                     = LINUX-NATIVE
-BIGENDIAN                = N
-NATIVETOOLSPREFIX        = 
-ARMTOOLSPREFIX           = arm-linux-
-MIPSTOOLSPREFIX          = mipsel-linux-
-POWERPCTOOLSPREFIX       = powerpc-linux-
-SHTOOLSPREFIX            = sh-linux-gnu
-RTEMSTOOLSPREFIX         = i386-rtemself-
-
-####################################################################
-#
-# Compiling options
-#
-####################################################################
-OPTIMIZE                 = Y
-DEBUG                    = N
-VERBOSE                  = Y
-THREADSAFE               = N
-
-####################################################################
-#
-# Libraries to build: microwin, nano-X, nanowidget, object frameworks
-#
-####################################################################
-MICROWIN                 = N
-NANOX                    = Y
-SHAREDLIBS               = N
-OBJFRAMEWORK             = N
-
-
-####################################################################
-#
-# Demos to build
-#
-####################################################################
-MICROWINDEMO             = N
-NANOXDEMO                = N
-
-####################################################################
-#
-# Applications to build
-#
-####################################################################
-NANOWM                   = N
-
-####################################################################
-#
-# The pixeltype of the native hardware or underlying graphics library.
-# This definition defines the PIXELVAL to be 32, 16 or 8 bits wide.
-# If using Linux framebuffer, set to MWPF_TRUECOLOR0888, and use fbset.
-# It also enables GdArea/GrArea for this particular pixel packing format.
-#
-# define MWPF_PALETTE       /* pixel is packed 8 bits 1, 4 or 8 pal index*/
-# define MWPF_TRUECOLOR8888 /* pixel is packed 32 bits 8/8/8/8 truecolor w/alpha*/
-# define MWPF_TRUECOLOR0888 /* pixel is packed 32 bits 8/8/8 truecolor*/
-# define MWPF_TRUECOLOR888  /* pixel is packed 24 bits 8/8/8 truecolor*/
-# define MWPF_TRUECOLOR565  /* pixel is packed 16 bits 5/6/5 truecolor*/
-# define MWPF_TRUECOLOR555  /* pixel is packed 16 bits 5/5/5 truecolor*/
-# define MWPF_TRUECOLOR332  /* pixel is packed 8 bits 3/3/2 truecolor*/
-#
-####################################################################
-#SCREEN_PIXTYPE           = MWPF_TRUECOLOR0888
-SCREEN_PIXTYPE		  = MWPF_TRUECOLOR565
-
-####################################################################
-#
-# NanoX: Put Y to the following line to link the nano-X application
-# with the server.  This is required for ELKS, if no network is present,
-# or for speed or debugging.  This affects the nano-X server only.
-#
-####################################################################
-LINK_APP_INTO_SERVER     = Y
-
-####################################################################
-# Shared memory support for Nano-X client/server protocol speedup
-####################################################################
-HAVE_SHAREDMEM_SUPPORT   = N
-
-####################################################################
-#
-# File I/O support
-# Supporting either below drags in libc stdio, which may not be wanted
-#
-####################################################################
-HAVE_FILEIO              = Y
-
-####################################################################
-# BMP, GIF reading support
-####################################################################
-HAVE_BMP_SUPPORT         = N
-HAVE_GIF_SUPPORT         = N
-HAVE_PNM_SUPPORT         = Y
-HAVE_XPM_SUPPORT         = N
-
-####################################################################
-# JPEG support through libjpeg, see README.txt in contrib/jpeg
-####################################################################
-HAVE_JPEG_SUPPORT        = N
-INCJPEG                  = .
-LIBJPEG                  = /usr/lib/libjpeg.a
-
-####################################################################
-# PNG support via libpng and libz
-####################################################################
-HAVE_PNG_SUPPORT         = N
-INCPNG                   = .
-LIBPNG                   = /usr/lib/libpng.a
-LIBZ                     = /usr/lib/libz.a
-
-####################################################################
-# TIFF support through libtiff
-####################################################################
-HAVE_TIFF_SUPPORT        = N
-INCTIFF                  = .
-LIBTIFF                  = /usr/lib/libtiff.a
-
-####################################################################
-# native .fnt loadable font support
-####################################################################
-HAVE_FNT_SUPPORT         = N
-HAVE_FNTGZ_SUPPORT       = N
-FNT_FONT_DIR             = "fonts/bdf"
-
-####################################################################
-# T1 adobe type1 font support thru t1lib
-####################################################################
-HAVE_T1LIB_SUPPORT       = N
-INCT1LIB                 = .
-LIBT1LIB                 = /usr/local/lib/libt1.a
-
-####################################################################
-# TrueType font support thru FreeType 1.x
-####################################################################
-HAVE_FREETYPE_SUPPORT    = N
-INCFTLIB                 = /usr/include/freetype1
-LIBFTLIB                 = /usr/lib/libttf.so
-FREETYPE_FONT_DIR        = "fonts/truetype"
-
-####################################################################
-# Support for many kinds of font thru FreeType 2.x
-# Must also set FREETYPE_FONT_DIR in the Freetype 1.x section
-####################################################################
-HAVE_FREETYPE_2_SUPPORT  = N
-INCFT2LIB                = .
-LIBFT2LIB                = /usr/lib/libfreetype.a
-
-####################################################################
-# PCF font support 
-# Selecting HAVE_PCFGZ_SUPPORT will allow you to directly read
-# .pcf.gz files, but it will add libz to the size of the server
-####################################################################
-HAVE_PCF_SUPPORT         = N
-HAVE_PCFGZ_SUPPORT       = N
-PCF_FONT_DIR             = "fonts/pcf"
-
-####################################################################
-# Chinese Han Zi Ku loadable font support
-####################################################################
-HAVE_HZK_SUPPORT         = N
-HZK_FONT_DIR             = "fonts/chinese"
-
-####################################################################
-# Chinese BIG5 compiled in font support (big5font.c)
-####################################################################
-HAVE_BIG5_SUPPORT        = N
-
-####################################################################
-# Chinese GB2312 compiled in font support (gb2312font.c)
-####################################################################
-HAVE_GB2312_SUPPORT      = N
-
-####################################################################
-# Japanese JISX0213 compiled in font support (jisx0213-12x12.c)
-####################################################################
-HAVE_JISX0213_SUPPORT    = N
-
-####################################################################
-# Korean HANGUL font support (jo16x16.c)
-####################################################################
-HAVE_KSC5601_SUPPORT     = N
-
-####################################################################
-# Japanese EUC-JP support using loadable MGL font
-####################################################################
-HAVE_EUCJP_SUPPORT       = N
-EUCJP_FONT_DIR           = "fonts/japanese"
-
-####################################################################
-# Generate screen driver interface only with no fonts or clipping
-####################################################################
-NOFONTSORCLIPPING        = N
-
-####################################################################
-#
-# Window move algorithms for Microwindows
-# Change for tradeoff between cpu speed and looks
-# ERASEMOVE repaints only backgrounds while window dragging, quicker.
-# Otherwise an XOR redraw is used for window moves only after button up,
-# quickest (should set for ELKS)
-# UPDATEREGIONS paints in update clipping region only for better look and feel
-#
-####################################################################
-ERASEMOVE                = Y
-UPDATEREGIONS            = Y
-
-####################################################################
-#
-# Link with Gray Palette (valid only for 4bpp modes)
-#
-####################################################################
-GRAYPALETTE              = N
-
-####################################################################
-#
-# If the platform is running UNIX, Linux or RTEMS...
-#
-####################################################################
-ifneq ($(ARCH), ELKS)
-
-# X Window screen, mouse and kbd drivers
-X11                      = N
-
-ifeq ($(X11), Y)
-# startup screen width, height, (depth for palette mode only)
-SCREEN_WIDTH             = 800
-SCREEN_HEIGHT            = 600
-SCREEN_DEPTH             = 4 
-
-# You may want to turn this on for XFree86 4.x or if your backing store
-# isn't functioning properly
-USE_EXPOSURE		 = Y
-
-else
-
-# framebuffer screen driver (linear and/or vga 4 planes)
-# set VTSWITCH to include virtual terminal switch code
-# set FBREVERSE to reverse bit orders in 1,2,4 bpp
-# set FBVGA=N for all systems without VGA hardware (for MIPS must=N)
-FRAMEBUFFER              = Y
-FBVGA                    = N
-VTSWITCH                 = N
-FBREVERSE                = N
-
-# set HAVETEXTMODE=Y for systems that can switch between text & graphics.
-# On a graphics-only embedded system, such as Osprey and Embedded
-# Planet boards, set HAVETEXTMODE=N
-HAVETEXTMODE             = Y
-
-# svgalib screen driver
-VGALIB                   = N
-
-# direct VGA hardware access screen driver
-HWVGA                    = N
-
-####################################################################
-# Mouse drivers
-# GPMMOUSE	gpm mouse
-# SERMOUSE	serial Microsoft, PC, Logitech, PS/2 mice (/dev/psaux)
-# SUNMOUSE	Sun Workstation mouse (/dev/sunmouse)
-# NOMOUSE	no mouse driver
-#
-# Touchscreen drivers
-# IPAQMOUSE	Compaq iPAQ, Intel Assabet (/dev/h3600_tsraw)
-# ZAURUSMOUSE	Sharp Zaurus (/dev/sharp_ts)
-# TUXMOUSE	TuxScreen (/dev/ucb1x00-ts)
-# ADSMOUSE	Applied Data Systems GC+ (/dev/ts)
-# ADS7846MOUSE	        ADS7846 chip, PSI OMAP Innovator (/dev/innnovator_ts)
-# EPMOUSE	Embedded Planet (/dev/tpanel)
-# VHMOUSE	Vtech Helio (/dev/tpanel)
-# MTMOUSE	MicroTouch serial (/dev/ttyS1)
-# PSIONMOUSE	Psion 5 (/dev/touch_psion)
-# YOPYMOUSE	Yopy (/dev/yopy-ts)
-# HARRIERMOUSE	NEC Harrier (/dev/tpanel)
-####################################################################
-GPMMOUSE                 = N
-SERMOUSE                 = N
-SUNMOUSE                 = N
-NOMOUSE                  = Y
-IPAQMOUSE                = N
-ZAURUSMOUSE              = N
-TUXMOUSE                 = N
-ADSMOUSE                 = N
-ADS7846MOUSE             = N
-EPMOUSE                  = N
-VHMOUSE                  = N
-MTMOUSE                  = N
-PSIONMOUSE               = N
-YOPYMOUSE                = N
-HARRIERMOUSE             = N
-LIRCMOUSE                = N
-
-# keyboard or null kbd driver
-TTYKBD                   = Y
-SCANKBD                  = N
-PIPEKBD                  = N
-IPAQKBD                  = N
-LIRCKBD                  = N
-NOKBD                    = N
-
-endif
-
-# Secondary keyboard drivers.
-# You may have a normal keyboard driver in addition to these
-# drivers, e.g. for both normal keyboard and IR input.
-LIRCKBD2                 = N
-
-####################################################################
-# Screen driver specific configuration
-# SA1100_LCD_LTLEND 4bpp driver with arm SA1100 LCD controller
-# INVERT4BPP 4bpp inverted pixel driver for VTech Helio
-####################################################################
-SA1100_LCD_LTLEND        = N
-INVERT4BPP               = N
-
-####################################################################
-#
-# If the platform is a RTEMS box ....
-#
-####################################################################
-ifeq ($(ARCH), RTEMS)
-
-# Location & BSP information of the RTEMS build
-RTEMS_BUILD              = /tools/build-i386-elf-rtems
-RTEMS_BSP                = pc386
-LINK_APP_INTO_SERVER     = Y
-
-endif
-
-endif
-
-####################################################################
-#
-# If the platform is an ELKS box ...
-#
-####################################################################
-ifeq ($(ARCH), ELKS)
-
-# Higher speed asm driver, c driver of hercules screen driver
-ASMVGADRIVER             = Y
-CVGADRIVER               = N
-HERCDRIVER               = N
-DBGDRIVER                = N
-
-# Mouse support
-SERMOUSE                 = Y
-
-endif

From jordan.crouse at amd.com  Tue Oct  2 22:09:26 2007
From: jordan.crouse at amd.com (Jordan Crouse)
Date: Tue, 2 Oct 2007 14:09:26 -0600
Subject: [LinuxBIOS] [BUILDROM] Remove bitrotten OLPC support
Message-ID: <20071002200926.GE27248@cosmic.amd.com>

Okay, this patch will probably make Ron cry, but in the end, I think
its better for the health of buildrom and the project (the patch, not
Ron crying).

The OLPC code we had in here before was for revision B2 and earlier, 
which will never see the light of day to the public, and only myself,
Ron and Segher have even seen them, let alone used them (and
I'm not even sure if my B2 works).

Even if we were to revive LinuxBIOS for the B3 for the upcoming G1G1
effort, the existing code would be too bitrotten and too old to be of
any use.    The only use we had for it was as a decent example of how
to do LAB, but Ward has upped the stakes with his LAB code that is way
better, and if we have our way, eventually all the LAB code will go away
in favor of something like buildroot.  And finally, the OLPC buildrom
code that last worked for B2 is still active over at dev.laptop.org, so
the code will be accessible if need be.

So, with all that said, I am proposing this patch to remove OLPC support
completely from buildrom, except for OFW, which I will discuss in the next
patch.  Flame on!

Jordan

-- 
Jordan Crouse
Systems Software Development Engineer 
Advanced Micro Devices, Inc.
-------------- next part --------------
[BUILDROM] Remove bitrotten OLPC support

OLPC support is bitrotten, and will never really be useful for the general
public, so eliminate it.

Signed-off-by: Jordan Crouse <jordan.crouse at amd.com>

Index: buildrom-devel/config/payloads/Config.in
===================================================================
--- buildrom-devel.orig/config/payloads/Config.in	2007-10-03 13:22:59.000000000 -0600
+++ buildrom-devel/config/payloads/Config.in	2007-10-03 13:23:14.000000000 -0600
@@ -89,19 +89,6 @@
 	help
 	  Say 'Y' here to include the busybox tools
 
-config BOOTMENU
-	bool "Bootmenu"
-	default y
-	help
-	  Say 'Y' here to include the bootmenu selector
-	
-config OLPCFLASH
-	bool "OLPC flash utility"
-	depends PLATFORM_OLPC
-	default y
-	help
-	  Say 'Y' here to include the OLPC flash utility
-
 endmenu
 
 menu "Memtest86 Configuration"
Index: buildrom-devel/config/payloads/ofw.conf
===================================================================
--- buildrom-devel.orig/config/payloads/ofw.conf	2007-10-03 13:22:59.000000000 -0600
+++ buildrom-devel/config/payloads/ofw.conf	2007-10-03 13:23:14.000000000 -0600
@@ -12,4 +12,4 @@
 # target
 
 PAYLOAD-y=ofw
-HOSTTOOLS-y=crc32sum
+#HOSTTOOLS-y=crc32sum
Index: buildrom-devel/config/platforms/Config.in
===================================================================
--- buildrom-devel.orig/config/platforms/Config.in	2007-10-03 13:22:59.000000000 -0600
+++ buildrom-devel/config/platforms/Config.in	2007-10-03 13:23:14.000000000 -0600
@@ -10,10 +10,6 @@
        bool "AMD Geode LX 'Norwich'"
        select PLATFORM
 
-config PLATFORM_OLPC
-       bool "OLPC Laptop"
-       select PLATFORM
-
 config PLATFORM_DBE61
        bool "Artec Group dbe61"
        select PLATFORM
Index: buildrom-devel/config/platforms/olpc.conf
===================================================================
--- buildrom-devel.orig/config/platforms/olpc.conf	2007-10-03 13:22:59.000000000 -0600
+++ /dev/null	1970-01-01 00:00:00.000000000 +0000
@@ -1,86 +0,0 @@
-# Configuration file for the OLPC platform
-
-# Basic platform configuration
-
-CC=gcc
-STRIP=strip
-AS=as
-
-MACHINE_ARCH=i586
-CFLAGS_platform = -fpic -m32
-ASFLAGS_platform = -32
-
-# Targets
-LINUXBIOS_MK=$(PACKAGE_DIR)/linuxbios/olpc-linuxbios.mk
-KERNEL_MK=$(PACKAGE_DIR)/linuxbios/olpc-kernel.mk
-
-#### Kernel configuration
-
-KERNEL_VERSION=2.6.18-rc4-olpc1
-KERNEL_TAG=1d386c71d46aed41683be5644f397c4fbfbc4d3f
-KERNEL_CONFIG=$(PACKAGE_DIR)/kernel/conf/defconfig-olpc
-
-# The following components are used to create the firmware signature in
-# the ROM.  see README.signature for information about how this is 
-# constructed.
-
-# The firmware model is a 6 byte string that identifies the model
-# This should stay static for the entire CL1 run.
-
-FIRMWARE_MODEL=CL1
-
-# The firmware revision is a 7 byte string that identifies the current
-# version.  The first three bytes of this will be repeated at the end of
-# the string, but that will be pulled out automatically
-# I set this now from a script that calls make
-# I wanted the default to be something non-offical but the boot scripts
-# in the build system look for the Q2A to determine that we are on an
-# OLPC (opposed to QEmu) So I have to have the Q2A. 
-
-FIRMWARE_REVISION = Q2B43
-
-# This is the version number for the embedded controller code pulled
-# in during the LinuxBIOS bulid
-
-EC_VER=B43
-
-# These are LinuxBIOS flags that may be useful
-
-LINUXBIOS_CAS25=y
-LINUXBIOS_ENABLE_FS2=y
-
-# If you uncomment and fill this in then it will override the firmware thats
-# # pulled from dev.laptop.org
-#
-#EC_FIRMWARE_OVERRIDE=PQ2B11T.bin
-
-#### You probably shouldn't change anything under this point
-
-LINUXBIOS_VENDOR=olpc
-LINUXBIOS_BOARD=rev_a
-LINUXBIOS_CONFIG=Config.SPI.lb
-LINUXBIOS_TDIR=rev_a_1M
-LINUXBIOS_ROM_NAME=linuxbios.rom
-
-LINUXBIOS_TAG=f6ec588df29f39a9b3db7fcbde2181d79ff7c5bd
-
-EC_FIRMWARE_URL=http://dev.laptop.org/pub/ec
-
-ifeq ($(PAYLOAD_LAB),y)
-LINUXBIOS_PATCHES += $(PACKAGE_DIR)/linuxbios/dcon-detect.patch
-endif
-
-ifeq ($(LINUXBIOS_CAS25),y)
-LINUXBIOS_PATCHES += $(PACKAGE_DIR)/linuxbios/CL2.5.patch
-LINUXBIOS_CL2_MARKER=_CL2.5
-endif
-
-ifeq ($(LINUXBIOS_ENABLE_FS2),y)
-LINUXBIOS_PATCHES += $(PACKAGE_DIR)/linuxbios/disable_swapsifs.patch
-endif
-
-ifeq ($(EC_FIRMWARE_OVERRIDE),)
-EC_FIRMWARE_REV=ec_v$(EC_VER).img
-else
-EC_FIRMWARE_REV=$(EC_FIRMWARE_OVERRIDE)
-endif
Index: buildrom-devel/config/platforms/platforms.conf
===================================================================
--- buildrom-devel.orig/config/platforms/platforms.conf	2007-10-03 13:22:59.000000000 -0600
+++ buildrom-devel/config/platforms/platforms.conf	2007-10-03 13:23:14.000000000 -0600
@@ -7,7 +7,6 @@
 
 PLATFORM-y=
 PLATFORM-$(CONFIG_PLATFORM_NORWICH) = norwich.conf
-PLATFORM-$(CONFIG_PLATFORM_OLPC) = olpc.conf
 PLATFORM-$(CONFIG_PLATFORM_MSM800SEV) = msm800sev.conf
 PLATFORM-$(CONFIG_PLATFORM_ALIX1C) = alix1c.conf
 PLATFORM-$(CONFIG_PLATFORM_DB800) = db800.conf
Index: buildrom-devel/packages/bootmenu/bootmenu.mk
===================================================================
--- buildrom-devel.orig/packages/bootmenu/bootmenu.mk	2007-10-03 13:22:59.000000000 -0600
+++ /dev/null	1970-01-01 00:00:00.000000000 +0000
@@ -1,52 +0,0 @@
-BOOTMENU_URL=http://dev.laptop.org/~jcrouse/bootmenu
-BOOTMENU_SOURCE=bootmenu-0.3.tar.gz
-BOOTMENU_DIR=$(BUILD_DIR)/bootmenu
-BOOTMENU_SRC_DIR=$(BOOTMENU_DIR)/bootmenu-0.3
-BOOTMENU_STAMP_DIR=$(BOOTMENU_DIR)/stamps
-BOOTMENU_LOG_DIR=$(BOOTMENU_DIR)/logs
-
-ifeq ($(CONFIG_VERBOSE),y)
-BOOTMENU_BUILD_LOG=/dev/stdout
-BOOTMENU_INSTALL_LOG=/dev/stdout
-else
-BOOTMENU_BUILD_LOG=$(BOOTMENU_LOG_DIR)/build.log
-BOOTMENU_INSTALL_LOG=$(BOOTMENU_LOG_DIR)/install.log
-endif
-
-$(SOURCE_DIR)/$(BOOTMENU_SOURCE):
-	@ mkdir -p $(SOURCE_DIR)
-	@ wget -P $(SOURCE_DIR) $(BOOTMENU_URL)/$(BOOTMENU_SOURCE)
-
-$(BOOTMENU_STAMP_DIR)/.unpacked: $(SOURCE_DIR)/$(BOOTMENU_SOURCE)
-	@ echo "Unpacking bootmenu..."
-	@ tar -C $(BOOTMENU_DIR) -zxf $(SOURCE_DIR)/$(BOOTMENU_SOURCE)
-	@ touch $@	
-
-$(BOOTMENU_SRC_DIR)/bootmenu: $(BOOTMENU_STAMP_DIR)/.unpacked
-	@ echo "Building bootmenu..."
-	$(MAKE) LDFLAGS="$(CROSS_CFLAGS) $(LDFLAGS)" -C $(BOOTMENU_SRC_DIR) > $(BOOTMENU_BUILD_LOG) 2>&1
-
-$(INITRD_DIR)/bin/bootmenu: $(BOOTMENU_SRC_DIR)/bootmenu
-	@ install -d $(INITRD_DIR)/bin
-	@ install -m 0755 $(BOOTMENU_SRC_DIR)/bootmenu \
-	$(INITRD_DIR)/bin/bootmenu
-	@ $(STRIPCMD) $(INITRD_DIR)/bin/bootmenu
-	@ install -d $(INITRD_DIR)/images
-	@ install -m 0644 $(BOOTMENU_SRC_DIR)/images/*.ppm $(INITRD_DIR)/images
-
-$(BOOTMENU_STAMP_DIR) $(BOOTMENU_LOG_DIR):
-	@ mkdir -p $@
-
-bootmenu: $(BOOTMENU_STAMP_DIR) $(BOOTMENU_LOG_DIR) $(INITRD_DIR)/bin/bootmenu
-
-bootmenu-clean:
-	@ echo "Cleaning bootmenu..."
-	@ $(MAKE) -C $(BOOTMENU_SRC_DIR) clean > /dev/null 2>&1
-
-bootmenu-distclean:
-	@ rm -rf $(BOOTMENU_DIR)/*
-
-bootmenu-bom:
-	@ echo "Package: bootmenu"
-	@ echo "Source: $(BOOTMENU_URL)/$(BOOTMENU_SOURCE)"
-	@ echo ""
Index: buildrom-devel/packages/crc32sum/crc32sum.mk
===================================================================
--- buildrom-devel.orig/packages/crc32sum/crc32sum.mk	2007-10-03 13:22:59.000000000 -0600
+++ /dev/null	1970-01-01 00:00:00.000000000 +0000
@@ -1,49 +0,0 @@
-CRC32SUM_URL=http://dev.laptop.org/~rsmith
-CRC32SUM_SOURCE=crc32sum_0.1.0.tar.gz
-CRC32SUM_DIR=$(BUILD_DIR)/crc32sum
-CRC32SUM_SRC_DIR=$(CRC32SUM_DIR)/crc32sum_0.1.0
-CRC32SUM_STAMP_DIR=$(CRC32SUM_DIR)/stamps
-CRC32SUM_LOG_DIR=$(CRC32SUM_DIR)/logs
-
-ifeq ($(CONFIG_VERBOSE),y)
-CRC32SUM_BUILD_LOG=/dev/stdout
-CRC32SUM_CONFIG_LOG=/dev/stdout
-else
-CRC32SUM_BUILD_LOG=$(CRC32SUM_LOG_DIR)/build.log
-CRC32SUM_CONFIG_LOG=$(CRC32SUM_LOG_DIR)/config.log
-endif
-
-$(SOURCE_DIR)/$(CRC32SUM_SOURCE):
-	@ mkdir -p $(SOURCE_DIR)
-	@ wget -P $(SOURCE_DIR) $(CRC32SUM_URL)/$(CRC32SUM_SOURCE)
-
-$(CRC32SUM_STAMP_DIR)/.unpacked: $(SOURCE_DIR)/$(CRC32SUM_SOURCE)
-	@ echo "Unpacking crc32sum..."
-	@ tar -C $(CRC32SUM_DIR) -zxf $(SOURCE_DIR)/$(CRC32SUM_SOURCE)
-	@ touch $@	
-
-$(CRC32SUM_SRC_DIR)/crc32sum: $(CRC32SUM_STAMP_DIR)/.unpacked
-	@ echo "Building crc32sum..."
-	@ ( export CC=$(HOST_CC); export CFLAGS=$(HOST_CFLAGS); \
-	  export LDFLAGS=$(HOST_LDFLAGS); unset LIBS; \
-	  $(MAKE) -C $(CRC32SUM_SRC_DIR) all > $(CRC32SUM_BUILD_LOG) 2>&1)
-
-$(STAGING_DIR)/bin/crc32sum: $(CRC32SUM_SRC_DIR)/crc32sum
-	@ install -d $(STAGING_DIR)/bin
-	@ install -m 0755 $< $@
-
-$(CRC32SUM_STAMP_DIR) $(CRC32SUM_LOG_DIR):
-	@ mkdir -p $@
-
-crc32sum: $(CRC32SUM_STAMP_DIR) $(CRC32SUM_LOG_DIR) $(STAGING_DIR)/bin/crc32sum
-
-crc32sum-clean:
-	@ $(MAKE) -C $(CRC32SUM_SRC_DIR) clean > /dev/null 2>&1
-
-crc32sum-distclean:
-	@ rm -rf $(CRC32SUM_DIR)/*
-
-crc32sum-bom:
-	echo "Package: crc32sum"
-	echo "Source: $(CRC32SUM_URL)/$(CRC32SUM_SOURCE)"
-	echo ""
Index: buildrom-devel/packages/fwsig/fwsig.c
===================================================================
--- buildrom-devel.orig/packages/fwsig/fwsig.c	2007-10-03 13:22:59.000000000 -0600
+++ /dev/null	1970-01-01 00:00:00.000000000 +0000
@@ -1,133 +0,0 @@
-#include <stdio.h>
-#include <stdlib.h>
-#include <unistd.h>
-#include <string.h>
-#include <fcntl.h>
-#include <sys/stat.h>
-
-#define FIRMWARE_SIG_OFFSET 0xffc0
-#define FIRMWARE_SIG_SIZE   16
-
-void usage(void) {
-  printf("usage: <file> [sig]\n");
-  printf("- Read or write the firmware signature of the file.\n");
-  printf("- if no signature is provided, then read it from the file.\n");
-  printf("- otherwise, write it into the file.\n");
-}
-
-int openfile(const char *filename, int flags) {
-
-  int fd = open(filename, O_RDONLY);
-  struct stat s;
-
-  if (fd == -1) {
-    printf("Couldn't open %s for reading.\n", filename);    
-    return -1;
-  }
-
-  if (fstat(fd, &s)) {
-    printf("Couldn't stat %s\n", filename);
-    goto error;
-  }
-
-  if (s.st_size < (FIRMWARE_SIG_OFFSET + FIRMWARE_SIG_SIZE)) {
-    printf("Oops - %s is too small for this operation.\n", filename);
-    goto error;
-  }
-  
-  return fd;
-
- error:
-  close(fd);
-  return -1;
-}
-
-int read_sig(const char *filename) {
-
-  int ret;
-  int fd = openfile(filename, O_RDONLY);
-  char sig[FIRMWARE_SIG_SIZE + 1];
-
-  if (fd == -1)
-    return -1;
-
-  ret = lseek(fd, FIRMWARE_SIG_OFFSET, SEEK_SET);
-
-  if (ret == -1) {
-    printf("Couldn't seek to %d in %s\n", FIRMWARE_SIG_OFFSET, filename);
-    goto error;
-  }
-
-  memset(sig, 0, FIRMWARE_SIG_SIZE + 1);
-  ret = read(fd, sig, FIRMWARE_SIG_SIZE);
-
-  if (ret == 0) 
-    printf("%s: \"%16s\"\n", filename, sig);
-  else
-    printf("Error while reading the signature.\n");
-
- error:
-  close(fd);
-  return ret;
-}
-
-int write_sig(const char *filename, const char *sig) {
-
-  int ret;
-  char temp[FIRMWARE_SIG_SIZE + 1];
-  int fd = openfile(filename, O_RDONLY);
-  int i;
-
-  if (fd == -1)
-    return -1;
-
-  ret = lseek(fd, FIRMWARE_SIG_OFFSET, SEEK_SET);
-
-  if (ret == -1) {
-    printf("Couldn't seek to %d in %s\n", FIRMWARE_SIG_OFFSET, filename);
-    goto error;
-  }
-
-  strncpy(temp, sig, FIRMWARE_SIG_SIZE);
-
-  if (strlen(sig) < FIRMWARE_SIG_SIZE) {
-    printf("*** WARNING - the firmware signature is less then %d bytes.\n", FIRMWARE_SIG_SIZE);
-    printf("              It will be padded - this may not have the inteded effect you want.\n");
-
-
-    for(i = strlen(sig); i < FIRMWARE_SIG_SIZE; i++)
-      temp[i] = ' ';
-
-    temp[i] = 0;
-  }
-  else if (strlen(sig) > FIRMWARE_SIG_SIZE) {
-    printf("*** WARNING - the firmware signature is less then %d bytes.\n", FIRMWARE_SIG_SIZE);
-    printf("              It will be truncated - this may not have the inteded effect you want.\n");
-    temp[FIRMWARE_SIG_SIZE] = 0;
-  }
-  
-  ret = write(fd, sig, FIRMWARE_SIG_SIZE);
-
-  if (ret)
-    printf("Error while writing the signature.\n");
-
- error:
-  close(fd);
-  return ret;
-}
-  
-int main(int argc, char **argv) {
-
-  int ret = 1;
-
-  if (argc < 2) 
-    usage();
-  else if (argc == 2) 
-    ret = read_sig(argv[1]);
-  else 
-    ret = write_sig(argv[1], argv[2]);
-  
-  return ret;
-}
-
-  
Index: buildrom-devel/packages/linuxbios/cache.patch
===================================================================
--- buildrom-devel.orig/packages/linuxbios/cache.patch	2007-10-03 13:22:59.000000000 -0600
+++ /dev/null	1970-01-01 00:00:00.000000000 +0000
@@ -1,14 +0,0 @@
-Index: LinuxBIOSv2/src/arch/i386/init/crt0.S.lb
-===================================================================
---- LinuxBIOSv2.orig/src/arch/i386/init/crt0.S.lb	2006-08-28 11:24:58.000000000 -0600
-+++ LinuxBIOSv2/src/arch/i386/init/crt0.S.lb	2006-08-28 15:18:04.000000000 -0600
-@@ -65,6 +65,9 @@
- 
- 	cld				/* clear direction flag */
- 	
-+	/* Invalidate the cache (if they are enabled) */
-+	wbinvd
-+	
- 	/* copy linuxBIOS from it's initial load location to 
- 	 * the location it is compiled to run at.
- 	 * Normally this is copying from FLASH ROM to RAM.
Index: buildrom-devel/packages/linuxbios/dcon-detect.patch
===================================================================
--- buildrom-devel.orig/packages/linuxbios/dcon-detect.patch	2007-10-03 13:22:59.000000000 -0600
+++ /dev/null	1970-01-01 00:00:00.000000000 +0000
@@ -1,80 +0,0 @@
-diff --git a/src/mainboard/olpc/rev_a/mainboard.c b/src/mainboard/olpc/rev_a/mainboard.c
-index d23255b..05abbfa 100755
---- a/src/mainboard/olpc/rev_a/mainboard.c
-+++ b/src/mainboard/olpc/rev_a/mainboard.c
-@@ -6,6 +6,67 @@ #include <device/pci_ops.h>
- #include <arch/io.h>
- #include <pc80/mc146818rtc.h>
- #include "chip.h"
-+#include "../southbridge/amd/cs5536/cs5536_smbus2.h"
-+
-+/* Borrowed from mc146818rtc.c */
-+
-+#define CMOS_READ(addr) ({ \
-+		outb((addr),RTC_PORT(0)); \
-+		inb(RTC_PORT(1)); \
-+		})
-+
-+#define CMOS_WRITE(val, addr) ({ \
-+		outb((addr),RTC_PORT(0)); \
-+		outb((val),RTC_PORT(1)); \
-+		})
-+
-+static void write_bit(unsigned char val) {
-+
-+	unsigned char byte = CMOS_READ(440 / 8);
-+
-+	/* Don't change it if its already set */
-+
-+	if ((byte & 1) == (val & 1))
-+		return;
-+
-+	byte &= ~1;
-+	byte |= val & 1;
-+	CMOS_WRITE(val, 440/8);
-+}
-+
-+static unsigned short _getsmbusbase(void) {
-+	unsigned devfn = PCI_DEVFN(0xf, 0);
-+	device_t dev = dev_find_slot(0x0, devfn);
-+	unsigned long addr = pci_read_config32(dev, PCI_BASE_ADDRESS_0);
-+
-+	return (unsigned short) (addr & ~1);
-+}
-+
-+static void init_dcon(void) {
-+
-+  int ret = 1;
-+  unsigned short rev = 0;
-+  unsigned short iobase = _getsmbusbase();
-+
-+  printk_debug("CHECKING FOR DCON (%x)\n", iobase);
-+
-+  /* Get the IO base for the SMBUS */
-+
-+  rev = do_smbus_read_word(iobase, 0x0D << 1, 0x00);
-+
-+  if (rev & 0xDC00) {
-+	printk_debug("DCON FOUND - REV %x\n", rev);
-+
-+	/* Enable the DCON */
-+	ret = do_smbus_write_word(iobase, 0x0D << 1, 0x01, 0x0069);
-+	if (ret != 0)
-+		printk_debug("DCON ENABLE FAILED\n", ret);
-+  }
-+  else
-+	  printk_debug("DCON NOT FOUND (%x)\n", rev);
-+
-+  write_bit(rev > 0 ? 1 : 0);
-+}
- 
- // indexed access to EC registers
- #define EC_INDEX(n)  (0x380 + (n))
-@@ -98,6 +159,7 @@ #define EC_3700_SIGNATURE  0xa0
-         }
- #endif
- 
-+	init_dcon();
- 	printk_debug("OLPC REVA EXIT %s\n", __FUNCTION__);
- }
- 
Index: buildrom-devel/packages/linuxbios/fix.patch
===================================================================
--- buildrom-devel.orig/packages/linuxbios/fix.patch	2007-10-03 13:22:59.000000000 -0600
+++ /dev/null	1970-01-01 00:00:00.000000000 +0000
@@ -1,56 +0,0 @@
-diff --git a/src/southbridge/amd/cs5536/cs5536.c b/src/southbridge/amd/cs5536/cs5536.c
-index 3e6f96b..6c0c8c0 100755
---- a/src/southbridge/amd/cs5536/cs5536.c
-+++ b/src/southbridge/amd/cs5536/cs5536.c
-@@ -90,6 +90,29 @@ static unsigned char ec_inb(unsigned sho
-     return inb(EC_INDEX(3));
- }
- 
-+#define EC_3920_SIGNATURE  0x09
-+
-+static unsigned char eccmd(unsigned char command) {
-+
-+	unsigned char ret;
-+
-+	if ((ret = inb(0x6c)) & 1)
-+		ret = inb(0x68);
-+
-+	/* Write the command */
-+	outb(command, 0x6C);
-+
-+	/* Wait for the EC response */
-+	while((inb(0x6C) & 3) != 1);
-+
-+	/* get the response */
-+	ret = inb(0x68);
-+
-+	/* Clear the "ownership flag" */
-+	outb(0xFF, 0x6C);
-+	return ret;
-+}
-+
- static void southbridge_init(struct device *dev)
- {
- 	struct southbridge_amd_cs5536_config  *sb = (struct southbridge_amd_cs5536_config *)dev->chip_info;
-@@ -107,13 +130,15 @@ static void southbridge_init(struct devi
- 	setup_i8259(); 
- 
- 	if (sb->lpc_serirq_enable) {
-+		int ret;
- 		msr.lo = sb->lpc_serirq_enable;
--#if 0  // Not Yet
--#define EC_3700_SIGNATURE  0xa0
--                if (ec_inb(0xff00) == EC_3700_SIGNATURE) {
--                    msr.lo |= 0x40;  // Set quiet mode bit
--                }
--#endif
-+
-+		/* Get the HW version */
-+		ret = eccmd(0x09);
-+
-+		if (ret != EC_3920_SIGNATURE)
-+			msr.lo |= 0x40;
-+
- 		msr.hi  = 0;
- 		wrmsr(MDD_LPC_SIRQ, msr);
- 	}
Index: buildrom-devel/packages/linuxbios/linuxbios-olpc.mk
===================================================================
--- buildrom-devel.orig/packages/linuxbios/linuxbios-olpc.mk	2007-10-03 13:22:59.000000000 -0600
+++ /dev/null	1970-01-01 00:00:00.000000000 +0000
@@ -1,64 +0,0 @@
-# This is the OLPC LinuxBIOS target
-
-ifeq ($(CONFIG_PLATFORM),y)
-ifeq ($(LINUXBIOS_TAG),)
-$(error You need to specify a version to pull in your platform config)
-endif
-endif
-
-LINUXBIOS_ROM_FILENAME=olpc-$(FIRMWARE_REVISION)$(LINUXBIOS_CL2_MARKER).rom
-LINUXBIOS_FETCHSH=$(BIN_DIR)/fetchgit.sh
-LINUXBIOS_BASE_DIR=git
-LINUXBIOS_URL=git://dev.laptop.org/projects/linuxbios
-LINUXBIOS_TARBALL=linuxbios-git-$(LINUXBIOS_TAG).tar.gz
-LINUXBIOS_PAYLOAD_TARGET = /tmp/olpcpayload.elf
-LINUXBIOS_VSA=$(PACKAGE_DIR)/bin/olpc_vsa.64k.bin
-
-MANUFACTURER_STRING = `printf "%-6s%-7s%-3s" $(FIRMWARE_MODEL) $(FIRMWARE_REVISION) $(FIRMWARE_REV2)`
-
-ifeq ($(_LINUXBIOS_INC_),)
-include $(PACKAGE_DIR)/linuxbios/linuxbios.inc
-endif
-
-$(SOURCE_DIR)/$(LINUXBIOS_TARBALL): 
-	@ echo "Fetching the LinuxBIOS code..."
-	@ mkdir -p $(SOURCE_DIR)/linuxbios
-	@ $(BIN_DIR)/fetchgit.sh $(LINUXBIOS_URL) $(SOURCE_DIR)/linuxbios \
-	$(LINUXBIOS_TAG) $(SOURCE_DIR)/$(LINUXBIOS_TARBALL) \
-	> $(LINUXBIOS_FETCH_LOG) 2>&1
-
-ifeq ($(EC_FIRMWARE_OVERRIDE),)
-$(LINUXBIOS_STAMP_DIR)/.pull_ecf_$(EC_FIRMWARE_REV):
-	@ echo "Fetching the EC bits..."
-	@ wget -N -P $(LINUXBIOS_BUILD_DIR) $(EC_FIRMWARE_URL)/$(EC_FIRMWARE_REV)
-	@ wget -N -P $(LINUXBIOS_BUILD_DIR) $(EC_FIRMWARE_URL)/MD5SUMS
-	@ if [ "`md5sum $(LINUXBIOS_BUILD_DIR)/$(EC_FIRMWARE_REV) |cut -d' ' -f1`" != "`grep $(EC_FIRMWARE_REV) $(LINUXBIOS_BUILD_DIR)/MD5SUMS | cut -d' ' -f1`" ]; then echo "ERROR! EC firmware hash does not match"; exit 1; fi
-	@ echo "EC Bits fetched and verified"
-	@ touch $@
-else
-$(LINUXBIOS_STAMP_DIR)/.pull_ecf_$(EC_FIRMWARE_REV):
-	@ echo "EC_FIRMWARE_OVERRIDE active so using custom EC bits from $(EC_FIRMWARE_OVERRIDE)"
-	@ cp -f $(PACKAGE_DIR)/bin/$(EC_FIRMWARE_OVERRIDE) $(LINUXBIOS_BUILD_DIR)/$(EC_FIRMWARE_REV)
-	@ touch $@
-endif
-
-
-$(OUTPUT_DIR)/$(OLPC_ROM_FILENAME).nosig: $(LINUXBIOS_OUTPUT) $(LINUXBIOS_STAMP_DIR)/.pull_ecf_$(EC_FIRMWARE_REV)
-	@ echo "Creating FIRMWARE_REVISON = $(FIRMWARE_REVISION) ROM and md5 files"
-	@ cat $(LINUXBIOS_BUILD_DIR)/$(EC_FIRMWARE_REV) $(LINUXBIOS_VSA) \
-	$(LINUXBIOS_BUILD_DIR)/$(LINUXBIOS_OUTPUT) > $@
-
-$(OUTPUT_DIR)/$(LINUXBIOS_ROM_FILENAME): $(OUTPUT_DIR)/$(OLPC_ROM_FILENAME).nosig
-	@ $(BIN_DIR)/setsig.sh $< "$(MANUFACTURER_STRING)" $@ 
-	@ $(STAGING_DIR)/bin/crc32sum -a $@ > $(LINUXBIOS_BUILD_LOG)
-	@ md5sum $@ | cut -d ' ' -f 1 > $(OUTPUT_DIR)/$(LINUXBIOS_ROM_FILENAME).md5
-
-
-olpc-linuxbios: $(OUTPUT_DIR)/$(LINUXBIOS_ROM_FILENAME)
-olpc-linuxbios-clean: generic-linuxbios-clean
-	@ rm -f $(LINUXBIOS_STAMP_DIR)/.pull_ecf_$(EC_FIRMWARE_REV)
-	@ rm -f $(LINUXBIOS_BUILD_DIR)/$(EC_FIRMWARE_REV) \
-        $(LINUXBIOS_BUILD_DIR)/MD5SUMS
-
-olpc-linuxbios-distclean: generic-linuxbios-distclean
-
Index: buildrom-devel/packages/linuxbios/linuxbios.mk
===================================================================
--- buildrom-devel.orig/packages/linuxbios/linuxbios.mk	2007-10-03 13:22:59.000000000 -0600
+++ /dev/null	1970-01-01 00:00:00.000000000 +0000
@@ -1,171 +0,0 @@
-# LinuxBIOS build script
-
-ifeq ($(LINUXBIOS_VENDOR),)
-LINUXBIOS_VENDOR=olpc
-endif
-ifeq ($(LINUXBIOS_BOARD),)
-LINUXBIOS_BOARD=rev_a
-endif
-ifeq ($(LINUXBIOS_CONFIG),)
-LINUXBIOS_CONFIG=Config.SPI.lb
-endif
-ifeq ($(LINUXBIOS_TDIR),)
-LINUXBIOS_TDIR=rev_a_1M
-endif
-ifeq ($(LINUXBIOS_FETCH),)
-LINUXBIOS_FETCH=git
-endif
-
-LINUXBIOS_PATCHES =
-
-ifeq ($(PAYLOAD_LAB),y)
-LINUXBIOS_PATCHES += $(PACKAGE_DIR)/linuxbios/dcon-detect.patch
-endif
-
-ifeq ($(LINUXBIOS_ENABLE_LZMA),y)
-LINUXBIOS_PATCHES += $(PACKAGE_DIR)/linuxbios/lzma-config.patch
-endif
-
-ifeq ($(LINUXBIOS_CAS25),y)
-LINUXBIOS_PATCHES += $(PACKAGE_DIR)/linuxbios/CL2.5.patch
-LINUXBIOS_CL2_MARKER=_CL2.5
-endif
-
-EC_FIRMWARE_URL=http://dev.laptop.org/pub/ec
-
-ifeq ($(EC_FIRMWARE_OVERRIDE),)
-EC_FIRMWARE_REV=ec_v$(EC_VER).img
-else
-EC_FIRMWARE_REV=$(EC_FIRMWARE_OVERRIDE)
-endif
-
-LINUXBIOS_ROM_FILENAME=olpc-$(FIRMWARE_REVISION)$(LINUXBIOS_CL2_MARKER).rom
-
-LINUXBIOS_DIR=$(BUILD_DIR)/linuxbios
-
-LINUXBIOS_TARGET_DIR=$(LINUXBIOS_SRC_DIR)/targets/
-LINUXBIOS_TARGET_NAME=$(LINUXBIOS_VENDOR)/$(LINUXBIOS_BOARD)
-LINUXBIOS_CONFIG_NAME=$(LINUXBIOS_TARGET_NAME)/$(LINUXBIOS_CONFIG)
-LINUXBIOS_BUILD_DIR=$(LINUXBIOS_TARGET_DIR)/$(LINUXBIOS_TARGET_NAME)/$(LINUXBIOS_TDIR)
-
-# Choose the right variables to use based on our fetch method
-
-ifeq ($(LINUXBIOS_FETCH),git)
-LINUXBIOS_FETCHSH=$(BIN_DIR)/fetchgit.sh
-LINUXBIOS_SRC_DIR=$(LINUXBIOS_DIR)/git
-LINUXBIOS_TAG=$(LINUXBIOS_GIT_TAG)
-LINUXBIOS_URL=$(LINUXBIOS_GIT_URL)
-else
-LINUXBIOS_FETCHSH=$(BIN_DIR)/fetchsvn.sh
-LINUXBIOS_SRC_DIR=$(LINUXBIOS_DIR)/svn
-LINUXBIOS_TAG=$(LINUXBIOS_SVN_TAG)
-LINUXBIOS_URL=$(LINUXBIOS_SVN_URL)
-endif
-
-ifeq ($(LINUXBIOS_TAG),)
-$(error LINUXBIOS_TAG was not defined.  Check your Config.mk)
-endif
-
-ifeq ($(LINUXBIOS_URL),)
-$(error LINUXBIOS_URL was not defined.  Check your Config.mk)
-endif
-
-LINUXBIOS_TARBALL=linuxbios-$(LINUXBIOS_FETCH)-$(LINUXBIOS_TAG).tar.gz
-
-LINUXBIOS_STAMP_DIR=$(LINUXBIOS_DIR)/stamps
-LINUXBIOS_LOG_DIR=$(LINUXBIOS_DIR)/logs
-
-ifeq ($(VERBOSE),y)
-LINUXBIOS_FETCH_LOG=/dev/stdout
-LINUXBIOS_CONFIG_LOG=/dev/stdout
-LINUXBIOS_BUILD_LOG=/dev/stdout
-LINUXBIOS_INSTALL_LOG=/dev/stdout
-else
-LINUXBIOS_FETCH_LOG=$(LINUXBIOS_LOG_DIR)/fetch.log
-LINUXBIOS_BUILD_LOG=$(LINUXBIOS_LOG_DIR)/build.log
-LINUXBIOS_CONFIG_LOG=$(LINUXBIOS_LOG_DIR)/config.log
-LINUXBIOS_INSTALL_LOG=$(LINUXBIOS_LOG_DIR)/install.log
-endif
-
-# Build the manufacturer string from the firmware model and revision
-
-FIRMWARE_REV2 = $(shell echo $(FIRMWARE_REVISION) | awk '{print substr($$1,0,3)}')
-MANUFACTURER_STRING = `printf "%-6s%-7s%-3s" $(FIRMWARE_MODEL) $(FIRMWARE_REVISION) $(FIRMWARE_REV2)`
-
-# fix me sooner or later!
-/tmp/olpcpayload.elf: $(PAYLOAD_TARGET)
-	@ cp $< $@
-
-$(SOURCE_DIR)/$(LINUXBIOS_TARBALL): 
-	@ echo "Fetching the LinuxBIOS code..."
-	@ mkdir -p $(SOURCE_DIR)/linuxbios
-	@ $(LINUXBIOS_FETCHSH) $(LINUXBIOS_URL) $(SOURCE_DIR)/linuxbios \
-	$(LINUXBIOS_TAG) $(SOURCE_DIR)/$(LINUXBIOS_TARBALL) \
-	> $(LINUXBIOS_FETCH_LOG) 2>&1
-
-$(LINUXBIOS_STAMP_DIR)/.unpacked: $(SOURCE_DIR)/$(LINUXBIOS_TARBALL)
-	@ echo "Unpacking LinuxBIOS..."
-	@ tar -C $(LINUXBIOS_DIR) -zxf $(SOURCE_DIR)/$(LINUXBIOS_TARBALL)
-	@ touch $@	
-
-$(LINUXBIOS_STAMP_DIR)/.patched: $(LINUXBIOS_STAMP_DIR)/.unpacked
-	@ echo "Patching LinuxBIOS..."
-	@ $(BIN_DIR)/doquilt.sh $(LINUXBIOS_SRC_DIR) $(LINUXBIOS_PATCHES)
-	@ touch $@
-
-$(LINUXBIOS_STAMP_DIR)/.configured: $(LINUXBIOS_STAMP_DIR)/.patched
-	@ echo "Building target config file..."
-	@( cd $(LINUXBIOS_TARGET_DIR); \
-	./buildtarget $(LINUXBIOS_CONFIG_NAME) > $(LINUXBIOS_CONFIG_LOG) 2>&1)
-	@ touch $@
-
-ifeq ($(EC_FIRMWARE_OVERRIDE),)
-$(LINUXBIOS_STAMP_DIR)/.pull_ecf_$(EC_FIRMWARE_REV):
-	@ echo "Fetching the EC bits..."
-	@ wget -N -P $(LINUXBIOS_BUILD_DIR) $(EC_FIRMWARE_URL)/$(EC_FIRMWARE_REV) 
-	@ wget -N -P $(LINUXBIOS_BUILD_DIR) $(EC_FIRMWARE_URL)/MD5SUMS 
-	@ if [ "`md5sum $(LINUXBIOS_BUILD_DIR)/$(EC_FIRMWARE_REV) |cut -d' ' -f1`" != "`grep $(EC_FIRMWARE_REV) $(LINUXBIOS_BUILD_DIR)/MD5SUMS | cut -d' ' -f1`" ]; then echo "ERROR! EC firmware hash does not match"; exit 1; fi
-	@ echo "EC Bits fetched and verified"
-	@ touch $@
-else
-$(LINUXBIOS_STAMP_DIR)/.pull_ecf_$(EC_FIRMWARE_REV):
-	@ echo "EC_FIRMWARE_OVERRIDE active so using custom EC bits from $(EC_FIRMWARE_OVERRIDE)"
-	@ cp -f $(PACKAGE_DIR)/bin/$(EC_FIRMWARE_OVERRIDE) $(LINUXBIOS_BUILD_DIR)/$(EC_FIRMWARE_REV)	
-	@ touch $@
-endif
-
-$(LINUXBIOS_BUILD_DIR)/$(LINUXBIOS_ROM_FILENAME):  $(LINUXBIOS_STAMP_DIR)/.configured /tmp/olpcpayload.elf
-	@ echo "Building linuxbios..."
-	@ make -C $(LINUXBIOS_BUILD_DIR) > $(LINUXBIOS_BUILD_LOG) 2>&1
-
-$(LINUXBIOS_BUILD_DIR)/$(LINUXBIOS_ROM_FILENAME).nosig: $(LINUXBIOS_BUILD_DIR)/$(LINUXBIOS_ROM_FILENAME) $(LINUXBIOS_STAMP_DIR)/.pull_ecf_$(EC_FIRMWARE_REV)
-	@ echo "Creating FIRMWARE_REVISON = $(FIRMWARE_REVISION) ROM and md5 files" 
-	@ cat $(LINUXBIOS_BUILD_DIR)/$(EC_FIRMWARE_REV) $(PACKAGE_DIR)/bin/olpc_vsa.64k.bin $(LINUXBIOS_BUILD_DIR)/linuxbios.rom > $@
-
-$(OUTPUT_DIR)/$(LINUXBIOS_ROM_FILENAME): $(LINUXBIOS_BUILD_DIR)/$(LINUXBIOS_ROM_FILENAME).nosig
-	@ $(BIN_DIR)/setsig.sh $< "$(MANUFACTURER_STRING)" $@ 
-	@ $(STAGING_DIR)/bin/crc32sum -a $@ > $(LINUXBIOS_BUILD_LOG)
-	@ md5sum $@ | cut -d ' ' -f 1 > $(OUTPUT_DIR)/$(LINUXBIOS_ROM_FILENAME).md5
-	
-$(LINUXBIOS_STAMP_DIR) $(LINUXBIOS_LOG_DIR):
-	@ mkdir -p $@
-
-linuxbios: $(LINUXBIOS_STAMP_DIR) $(LINUXBIOS_LOG_DIR) $(OUTPUT_DIR)/$(LINUXBIOS_ROM_FILENAME)
-
-linuxbios-clean:
-	@ echo "Cleaning linuxbios..."
-	@ $(MAKE) -C $(LINUXBIOS_BUILD_DIR) clean > /dev/null 2>&1
-	@ rm -f $(LINUXBIOS_STAMP_DIR)/.pull_ecf_$(EC_FIRMWARE_REV)
-	@ rm -f $(LINUXBIOS_BUILD_DIR)/$(EC_FIRMWARE_REV) \
-	$(LINUXBIOS_BUILD_DIR)/MD5SUMS
-
-linuxbios-distclean:
-	@ rm -rf $(LINUXBIOS_DIR)/*
-
-linuxbios-bom:
-	@ echo "Package: linuxbios"
-	@ echo "Source:  $(LINUXBIOS_URL)"
-	@ echo "Revison: $(LINUXBIOS_TAG)"
-	@ echo "Tarball: `basename $(LINUXBIOS_TARBALL)"
-	@ echo ""
-
Index: buildrom-devel/packages/linuxbios/lzma-config.patch
===================================================================
--- buildrom-devel.orig/packages/linuxbios/lzma-config.patch	2007-10-03 13:22:59.000000000 -0600
+++ /dev/null	1970-01-01 00:00:00.000000000 +0000
@@ -1,15 +0,0 @@
-Index: LinuxBIOSv2/targets/olpc/rev_a/Config.SPI.lb
-===================================================================
---- LinuxBIOSv2.orig/targets/olpc/rev_a/Config.SPI.lb	2006-09-15 11:54:44.000000000 -0600
-+++ LinuxBIOSv2/targets/olpc/rev_a/Config.SPI.lb	2006-09-15 11:55:04.000000000 -0600
-@@ -5,8 +5,8 @@
- 
- # Don't let LinuxBIOS compress the payload
- #option CONFIG_COMPRESSED_ROM_STREAM_NRV2B=0
--#option CONFIG_COMPRESSED_ROM_STREAM_LZMA=1
--#option CONFIG_PRECOMPRESSED_ROM_STREAM=0
-+option CONFIG_COMPRESSED_ROM_STREAM_LZMA=1
-+option CONFIG_PRECOMPRESSED_ROM_STREAM=1
- 
- # leave 64k for vsa and 64k for EC code
- option ROM_SIZE=(1024*1024)-(64*1024)-(64*1024)
Index: buildrom-devel/packages/linuxbios/olpc-linuxbios.mk
===================================================================
--- buildrom-devel.orig/packages/linuxbios/olpc-linuxbios.mk	2007-10-03 13:22:59.000000000 -0600
+++ /dev/null	1970-01-01 00:00:00.000000000 +0000
@@ -1,65 +0,0 @@
-# This is the OLPC LinuxBIOS target
-
-ifeq ($(CONFIG_PLATFORM),y)
-ifeq ($(LINUXBIOS_TAG),)
-$(error You need to specify a version to pull in your platform config)
-endif
-endif
-
-TARGET_ROM=olpc-$(FIRMWARE_REVISION)$(LINUXBIOS_CL2_MARKER).rom
-LINUXBIOS_FETCHSH=$(BIN_DIR)/fetchgit.sh
-LINUXBIOS_BASE_DIR=git
-LINUXBIOS_URL=git://dev.laptop.org/projects/linuxbios
-LINUXBIOS_TARBALL=linuxbios-git-$(LINUXBIOS_TAG).tar.gz
-LINUXBIOS_PAYLOAD_TARGET = /tmp/olpcpayload.elf
-LINUXBIOS_VSA=$(PACKAGE_DIR)/bin/olpc_vsa.64k.bin
-
-MANUFACTURER_STRING = `printf "%-6s%-7s%-3s" $(FIRMWARE_MODEL) $(FIRMWARE_REVISION) $(FIRMWARE_REV2)`
-
-ifeq ($(CONFIG_USE_LZMA),y)
-LINUXBIOS_PATCHES += $(PACKAGE_DIR)/linuxbios/patches/lzma-config.patch
-endif
-
-include $(PACKAGE_DIR)/linuxbios/linuxbios.inc
-
-$(SOURCE_DIR)/$(LINUXBIOS_TARBALL): 
-	@ echo "Fetching the LinuxBIOS code..."
-	@ mkdir -p $(SOURCE_DIR)/linuxbios
-	@ $(BIN_DIR)/fetchgit.sh $(LINUXBIOS_URL) $(SOURCE_DIR)/linuxbios \
-	$(LINUXBIOS_TAG) $(SOURCE_DIR)/$(LINUXBIOS_TARBALL) \
-	> $(LINUXBIOS_FETCH_LOG) 2>&1
-
-ifeq ($(EC_FIRMWARE_OVERRIDE),)
-$(LINUXBIOS_STAMP_DIR)/.pull_ecf_$(EC_FIRMWARE_REV):
-	@ echo "Fetching the EC bits..."
-	@ wget -N -P $(LINUXBIOS_BUILD_DIR) $(EC_FIRMWARE_URL)/$(EC_FIRMWARE_REV)
-	@ wget -N -P $(LINUXBIOS_BUILD_DIR) $(EC_FIRMWARE_URL)/MD5SUMS
-	@ if [ "`md5sum $(LINUXBIOS_BUILD_DIR)/$(EC_FIRMWARE_REV) |cut -d' ' -f1`" != "`grep $(EC_FIRMWARE_REV) $(LINUXBIOS_BUILD_DIR)/MD5SUMS | cut -d' ' -f1`" ]; then echo "ERROR! EC firmware hash does not match"; exit 1; fi
-	@ echo "EC Bits fetched and verified"
-	@ touch $@
-else
-$(LINUXBIOS_STAMP_DIR)/.pull_ecf_$(EC_FIRMWARE_REV):
-	@ echo "EC_FIRMWARE_OVERRIDE active so using custom EC bits from $(EC_FIRMWARE_OVERRIDE)"
-	@ cp -f $(PACKAGE_DIR)/bin/$(EC_FIRMWARE_OVERRIDE) $(LINUXBIOS_BUILD_DIR)/$(EC_FIRMWARE_REV)
-	@ touch $@
-endif
-
-
-$(OUTPUT_DIR)/$(OLPC_ROM_FILENAME).nosig: $(LINUXBIOS_OUTPUT) $(LINUXBIOS_STAMP_DIR)/.pull_ecf_$(EC_FIRMWARE_REV)
-	@ echo "Creating FIRMWARE_REVISON = $(FIRMWARE_REVISION) ROM and md5 files"
-	@ cat $(LINUXBIOS_BUILD_DIR)/$(EC_FIRMWARE_REV) $(LINUXBIOS_VSA) \
-	$(LINUXBIOS_BUILD_DIR)/$(LINUXBIOS_OUTPUT) > $@
-
-$(TARGET_ROM): $(OUTPUT_DIR)/$(OLPC_ROM_FILENAME).nosig
-	@ $(BIN_DIR)/setsig.sh $< "$(MANUFACTURER_STRING)" $@ 
-	@ $(STAGING_DIR)/bin/crc32sum -a $@ > $(LINUXBIOS_BUILD_LOG)
-	@ md5sum $@ | cut -d ' ' -f 1 > $(OUTPUT_DIR)/$(LINUXBIOS_ROM_FILENAME).md5
-
-linuxbios: $(OUTPUT_DIR)/$(TARGET_ROM)
-linuxbios-clean: generic-linuxbios-clean
-	@ rm -f $(LINUXBIOS_STAMP_DIR)/.pull_ecf_$(EC_FIRMWARE_REV)
-	@ rm -f $(LINUXBIOS_BUILD_DIR)/$(EC_FIRMWARE_REV) \
-        $(LINUXBIOS_BUILD_DIR)/MD5SUMS
-
-linuxbios-distclean: generic-linuxbios-distclean
-
Index: buildrom-devel/packages/linuxbios/patches/cache.patch
===================================================================
--- buildrom-devel.orig/packages/linuxbios/patches/cache.patch	2007-10-03 13:22:59.000000000 -0600
+++ /dev/null	1970-01-01 00:00:00.000000000 +0000
@@ -1,14 +0,0 @@
-Index: LinuxBIOSv2/src/arch/i386/init/crt0.S.lb
-===================================================================
---- LinuxBIOSv2.orig/src/arch/i386/init/crt0.S.lb	2006-08-28 11:24:58.000000000 -0600
-+++ LinuxBIOSv2/src/arch/i386/init/crt0.S.lb	2006-08-28 15:18:04.000000000 -0600
-@@ -65,6 +65,9 @@
- 
- 	cld				/* clear direction flag */
- 	
-+	/* Invalidate the cache (if they are enabled) */
-+	wbinvd
-+	
- 	/* copy linuxBIOS from it's initial load location to 
- 	 * the location it is compiled to run at.
- 	 * Normally this is copying from FLASH ROM to RAM.
Index: buildrom-devel/packages/linuxbios/patches/dcon-detect.patch
===================================================================
--- buildrom-devel.orig/packages/linuxbios/patches/dcon-detect.patch	2007-10-03 13:22:59.000000000 -0600
+++ /dev/null	1970-01-01 00:00:00.000000000 +0000
@@ -1,80 +0,0 @@
-diff --git a/src/mainboard/olpc/rev_a/mainboard.c b/src/mainboard/olpc/rev_a/mainboard.c
-index d23255b..05abbfa 100755
---- a/src/mainboard/olpc/rev_a/mainboard.c
-+++ b/src/mainboard/olpc/rev_a/mainboard.c
-@@ -6,6 +6,67 @@ #include <device/pci_ops.h>
- #include <arch/io.h>
- #include <pc80/mc146818rtc.h>
- #include "chip.h"
-+#include "../southbridge/amd/cs5536/cs5536_smbus2.h"
-+
-+/* Borrowed from mc146818rtc.c */
-+
-+#define CMOS_READ(addr) ({ \
-+		outb((addr),RTC_PORT(0)); \
-+		inb(RTC_PORT(1)); \
-+		})
-+
-+#define CMOS_WRITE(val, addr) ({ \
-+		outb((addr),RTC_PORT(0)); \
-+		outb((val),RTC_PORT(1)); \
-+		})
-+
-+static void write_bit(unsigned char val) {
-+
-+	unsigned char byte = CMOS_READ(440 / 8);
-+
-+	/* Don't change it if its already set */
-+
-+	if ((byte & 1) == (val & 1))
-+		return;
-+
-+	byte &= ~1;
-+	byte |= val & 1;
-+	CMOS_WRITE(val, 440/8);
-+}
-+
-+static unsigned short _getsmbusbase(void) {
-+	unsigned devfn = PCI_DEVFN(0xf, 0);
-+	device_t dev = dev_find_slot(0x0, devfn);
-+	unsigned long addr = pci_read_config32(dev, PCI_BASE_ADDRESS_0);
-+
-+	return (unsigned short) (addr & ~1);
-+}
-+
-+static void init_dcon(void) {
-+
-+  int ret = 1;
-+  unsigned short rev = 0;
-+  unsigned short iobase = _getsmbusbase();
-+
-+  printk_debug("CHECKING FOR DCON (%x)\n", iobase);
-+
-+  /* Get the IO base for the SMBUS */
-+
-+  rev = do_smbus_read_word(iobase, 0x0D << 1, 0x00);
-+
-+  if (rev & 0xDC00) {
-+	printk_debug("DCON FOUND - REV %x\n", rev);
-+
-+	/* Enable the DCON */
-+	ret = do_smbus_write_word(iobase, 0x0D << 1, 0x01, 0x0069);
-+	if (ret != 0)
-+		printk_debug("DCON ENABLE FAILED\n", ret);
-+  }
-+  else
-+	  printk_debug("DCON NOT FOUND (%x)\n", rev);
-+
-+  write_bit(rev > 0 ? 1 : 0);
-+}
- 
- // indexed access to EC registers
- #define EC_INDEX(n)  (0x380 + (n))
-@@ -98,6 +159,7 @@ #define EC_3700_SIGNATURE  0xa0
-         }
- #endif
- 
-+	init_dcon();
- 	printk_debug("OLPC REVA EXIT %s\n", __FUNCTION__);
- }
- 
Index: buildrom-devel/packages/linuxbios/patches/disable_swapsifs.patch
===================================================================
--- buildrom-devel.orig/packages/linuxbios/patches/disable_swapsifs.patch	2007-10-03 13:22:59.000000000 -0600
+++ /dev/null	1970-01-01 00:00:00.000000000 +0000
@@ -1,23 +0,0 @@
-Index: LinuxBIOSv2/src/cpu/amd/model_gx2/cpubug.c
-===================================================================
---- LinuxBIOSv2.orig/src/cpu/amd/model_gx2/cpubug.c	2006-08-29 08:44:01.000000000 -0600
-+++ LinuxBIOSv2/src/cpu/amd/model_gx2/cpubug.c	2006-08-29 08:45:21.000000000 -0600
-@@ -176,7 +176,7 @@
- 	wrmsr(0x3003, msr);
- 
- 	/* change this value to zero if you need to disable this BTB SWAPSiF. */
--	if (1) { 
-+	if (0) {
- 
- 		/* Disable enable_actions in DIAGCTL while setting up GLCP */
- 		msr.hi = 0;
-@@ -373,7 +373,8 @@
- 			pcideadlock();
- 			eng1398();
- 			eng2900();
--			bug118339();
-+			/* Disabled because it freaks out FS2 */
-+			//bug118339();
- 			break;
- 		case 0x22:
- 		case 0x30: 
Index: buildrom-devel/packages/linuxbios/patches/fix.patch
===================================================================
--- buildrom-devel.orig/packages/linuxbios/patches/fix.patch	2007-10-03 13:22:59.000000000 -0600
+++ /dev/null	1970-01-01 00:00:00.000000000 +0000
@@ -1,56 +0,0 @@
-diff --git a/src/southbridge/amd/cs5536/cs5536.c b/src/southbridge/amd/cs5536/cs5536.c
-index 3e6f96b..6c0c8c0 100755
---- a/src/southbridge/amd/cs5536/cs5536.c
-+++ b/src/southbridge/amd/cs5536/cs5536.c
-@@ -90,6 +90,29 @@ static unsigned char ec_inb(unsigned sho
-     return inb(EC_INDEX(3));
- }
- 
-+#define EC_3920_SIGNATURE  0x09
-+
-+static unsigned char eccmd(unsigned char command) {
-+
-+	unsigned char ret;
-+
-+	if ((ret = inb(0x6c)) & 1)
-+		ret = inb(0x68);
-+
-+	/* Write the command */
-+	outb(command, 0x6C);
-+
-+	/* Wait for the EC response */
-+	while((inb(0x6C) & 3) != 1);
-+
-+	/* get the response */
-+	ret = inb(0x68);
-+
-+	/* Clear the "ownership flag" */
-+	outb(0xFF, 0x6C);
-+	return ret;
-+}
-+
- static void southbridge_init(struct device *dev)
- {
- 	struct southbridge_amd_cs5536_config  *sb = (struct southbridge_amd_cs5536_config *)dev->chip_info;
-@@ -107,13 +130,15 @@ static void southbridge_init(struct devi
- 	setup_i8259(); 
- 
- 	if (sb->lpc_serirq_enable) {
-+		int ret;
- 		msr.lo = sb->lpc_serirq_enable;
--#if 0  // Not Yet
--#define EC_3700_SIGNATURE  0xa0
--                if (ec_inb(0xff00) == EC_3700_SIGNATURE) {
--                    msr.lo |= 0x40;  // Set quiet mode bit
--                }
--#endif
-+
-+		/* Get the HW version */
-+		ret = eccmd(0x09);
-+
-+		if (ret != EC_3920_SIGNATURE)
-+			msr.lo |= 0x40;
-+
- 		msr.hi  = 0;
- 		wrmsr(MDD_LPC_SIRQ, msr);
- 	}
Index: buildrom-devel/packages/linuxbios/patches/lzma-config.patch
===================================================================
--- buildrom-devel.orig/packages/linuxbios/patches/lzma-config.patch	2007-10-03 13:22:59.000000000 -0600
+++ /dev/null	1970-01-01 00:00:00.000000000 +0000
@@ -1,15 +0,0 @@
-Index: LinuxBIOSv2/targets/olpc/rev_a/Config.SPI.lb
-===================================================================
---- LinuxBIOSv2.orig/targets/olpc/rev_a/Config.SPI.lb	2006-09-15 11:54:44.000000000 -0600
-+++ LinuxBIOSv2/targets/olpc/rev_a/Config.SPI.lb	2006-09-15 11:55:04.000000000 -0600
-@@ -5,8 +5,8 @@
- 
- # Don't let LinuxBIOS compress the payload
- #option CONFIG_COMPRESSED_ROM_STREAM_NRV2B=0
--#option CONFIG_COMPRESSED_ROM_STREAM_LZMA=1
--#option CONFIG_PRECOMPRESSED_ROM_STREAM=0
-+option CONFIG_COMPRESSED_ROM_STREAM_LZMA=1
-+option CONFIG_PRECOMPRESSED_ROM_STREAM=1
- 
- # leave 64k for vsa and 64k for EC code
- option ROM_SIZE=(1024*1024)-(64*1024)-(64*1024)
Index: buildrom-devel/packages/olpcflash/Makefile
===================================================================
--- buildrom-devel.orig/packages/olpcflash/Makefile	2007-10-03 13:22:59.000000000 -0600
+++ /dev/null	1970-01-01 00:00:00.000000000 +0000
@@ -1,9 +0,0 @@
-CC=gcc
-CFLAGS_extra= -Wall
-LDFLAGS_extra=
-
-olpcflash: olpcflash.c
-	$(CC) $(CFLAGS) $(CFLAGS_extra) $(LDFLAGS) $(LDFLAGS_extra) -o $@ olpcflash.c $(LIBS)
-
-clean:
-	rm -f olpcflash
Index: buildrom-devel/packages/olpcflash/olpcflash.c
===================================================================
--- buildrom-devel.orig/packages/olpcflash/olpcflash.c	2007-10-03 13:22:59.000000000 -0600
+++ /dev/null	1970-01-01 00:00:00.000000000 +0000
@@ -1,937 +0,0 @@
-/*
- * olpcflash.c: SPI Flash programming utility for OLPC.
- *
- * Copyright 2000 Silicon Integrated System Corporation
- * Copyright 2004 Tyan Corp
- *		yhlu yhlu at tyan.com add exclude start and end option
- * Copyright 2005-2006 coresystems GmbH 
- *      Stefan Reinauer <stepan at coresystems.de> added rom layout
- *      support, and checking for suitable rom image, various fixes
- *      support for flashing the Technologic Systems 5300.
- * Copyright 2006  Ron Minniich <rminnich at lanl.gov>
- *      Initial support for EnE KB3920 EC and the spansion
- *      25FL008A 8Mibit SPI part on the OLPC
- * Copyright 2006 Richard A. Smith <smithbone at gmail.com> 
- *      Added lots of additional stuff to make writing to spansion part
- *      work correctly with the OLPC EnE EC.
- * 
- *	This program is free software; you can redistribute it and/or modify
- *	it under the terms of the GNU General Public License as published by
- *	the Free Software Foundation; either version 2 of the License, or
- *	(at your option) any later version.
- *
- *	This program is distributed in the hope that it will be useful,
- *	but WITHOUT ANY WARRANTY; without even the implied warranty of
- *	MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
- *	GNU General Public License for more details.
- *
- *	You should have received a copy of the GNU General Public License
- *	along with this program; if not, write to the Free Software
- *	Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.
- *
- */
-
-#include <errno.h>
-#include <fcntl.h>
-#include <sys/mman.h>
-#include <unistd.h>
-#include <stdio.h>
-#include <string.h>
-#include <stdlib.h>
-#include <getopt.h>
-#include <sys/io.h>
-#include <sys/time.h>
-#include <time.h>
-
-#define printf_debug(x...) { if(verbose) printf(x); }
-#define printf_super_debug(x...) { if(verbose > 1) printf(x); }
-
-#define VER_MAJOR   0
-#define VER_MINOR   3
-#define VER_RELEASE 0
-
-#define LINUXBIOS_START		0x10000
-#define PAGE_SIZE			256
-#define EC_CODE_SIZE 		(64*1024)
-#define ROM_SIZE			(1024*1024)
-#define IOBASE_DEFAULT			(0x381)
-
-enum {
-	GPIO5 = 0xfc2a,
-	SPIA0 = 0xfea8, 
-	SPIA1, 
-	SPIA2, 
-	SPIDAT,
-	SPICMD, 
-	SPICFG,
-	SPIDATR
-};
-
-enum {
-	DUMMY,
-	WRITESTATUS = 1,
-	BYTEPROGRAM, 
-	READ,
-	WRITEDISABLE,
-	READSTATUS,	
-	WRITEENABLE,
-	HIGHSPEEDREAD 	= 0xb,
-	SECTORERASESST 	= 0x20, 
-	ENABLEWRITESTATUSSST = 0x50,
-	BLOCKERASESST 	= 0x52,  /* 32k block */
-	CHIPERASESST 	= 0x60,
-	READJDECID 	= 0x9f,
-	AUTOINCPROGSST  = 0xad,
-	CHIPERASEPCM 	= 0xc7, /* also nexflash */
-	SECTORERASEPCM 	= 0xd7,
-	BLOCKERASEPCM 	= 0xd8, /* also nexflash, and spansion, SST (64k) */
-};
-
-enum {
-	SPIBUSY = 2, 
-	SPIFIRMWAREMODE = 1 << 4,
-	SPICMDWE = 8,
-	SPIFLASHREADCE = 1 << 6
-};
-
-enum {
-	WIP = 1 << 0
-};
-
-enum {
-	SPANSION	= 0x01,
-	SST 		= 0xbf,
-	WINBOND 	= 0xef
-};
-
-struct flashchip {
-	int manufacture_id;
-	int model_type;
-	int model_id;
-
-	int total_size;
-	int page_size;
-
-	int (*write_page) (unsigned char *buf, unsigned long addr, unsigned long size);
-
-};
-
-char *chip_to_probe = NULL;
-
-int exclude_start_page, exclude_end_page;
-int force=0, verbose=0; int noop=0;
-
-/* this is the defaut index and data IO base address for
- * EC register access.
- * setup by the EC code.
- */
-
-unsigned short iobase = IOBASE_DEFAULT;
-
-// count to a billion. Time it. If it's < 1 sec, count to 10B, etc.
-unsigned long micro = 1;
-
-
-void myusec_delay(int time)
-{
-	volatile unsigned long i;
-	for (i = 0; i < time * micro; i++);
-}
-
-void myusec_calibrate_delay()
-{
-	int count = 1000;
-	unsigned long timeusec;
-	struct timeval start, end;
-	int ok = 0;
-
-	printf_debug("Setting up microsecond timing loop\n");
-	while (!ok) {
-		gettimeofday(&start, 0);
-		myusec_delay(count);
-		gettimeofday(&end, 0);
-		timeusec = 1000000 * (end.tv_sec - start.tv_sec) +
-		    (end.tv_usec - start.tv_usec);
-		count *= 2;
-		if (timeusec < 1000000 / 4)
-			continue;
-		ok = 1;
-	}
-
-	// compute one microsecond. That will be count / time
-	micro = count / timeusec;
-
-	printf_debug("%ldM loops per second\n", (unsigned long) micro);
-}
-
-
-void setecindex(unsigned short index)
-{
-	unsigned char hi = index>>8;
-	unsigned char lo = index;
-
-	if (noop) return;
-
-	outb(hi, iobase);
-	outb(lo, iobase+1);
-	printf_super_debug("%s: set 0x%x to 0x%x, 0x%x to 0x%x\n", __FUNCTION__, 
-		iobase, hi, iobase+1, lo);
-}
-
-unsigned char getecdata(void)
-{
-	unsigned char data;
-
-	if (noop) return 0;
-
-	data = inb(iobase+2);
-	printf_super_debug("%s: read 0x%x from 0x%x\n", __FUNCTION__, data, iobase+2);
-	return data;
-}
-
-void putecdata(unsigned char data)
-{
-
-	if (noop) return;
-
-	outb(data, iobase+2);
-	printf_super_debug("%s: wrote 0x%x to 0x%x\n", __FUNCTION__, data, iobase+2);
-}
-
-unsigned char readecdata(unsigned short index)
-{
-	setecindex(index);
-	return getecdata();
-}
-
-void writeecdata(unsigned short index, unsigned char data)
-{
-	setecindex(index);
-	putecdata(data);
-}
-
-void setaddr(unsigned long addr){
-	unsigned char data;
-	data = addr;
-	writeecdata(SPIA0, data);
-	data = addr >> 8;
-	writeecdata(SPIA1, data);
-	data = addr >> 16;
-	writeecdata(SPIA2, data);
-}
-
-unsigned char rdata(void)
-{
-	unsigned char data;
-	data = readecdata(SPIDAT);
-	return data;
-}
-
-void wdata(unsigned char data)
-{
-	writeecdata(SPIDAT, data);
-}
-
-unsigned char cmd(void)
-{
-	return readecdata(SPICMD);
-}
-
-void docmd(unsigned char cmd)
-{
-	printf_super_debug("docmd: cmd 0x%x\n", cmd);
-	writeecdata(SPICMD, cmd);
-	printf_super_debug("docmd: cmd 0x%x\n", cmd);
-}
-
-void wait_cmd_sent(void)
-{
-	int trycount = 0;
-	myusec_delay(10);
-
-	if (noop) return;
-
-	while (readecdata(SPICFG) & SPIBUSY){
-		trycount++;
-		myusec_delay(10);
-		if (trycount > 100000){ /* 1 second! */
-			printf("wait_sent: Err: waited for > 1 second\n");
-			trycount = 0;
-		}
-	}
-}	
-
-/* 
- * The EnE code has lots of small delays inbetween
- * many of the actions.  Route all this through 
- * one function so I can play with how long they
- * need to be.
- */
-void short_delay(void)
-{
-	// EnE code did 4 pci reads of the base address
-	// which should be around 800nS
-	// 2 uS should cover it in case I'm wrong
-	myusec_delay(2);
-}
-
-/*
- * Firmware mode allows you raw control over the SPI bus
- * the spansion part is not supported by the EC in 
- * "hardware" mode.
- * in this mode bytes written to the SPICMD register
- * are clocked out the bus.
- * This also asserts SPICS#
- */
-void start_SPI_firmware_mode_access(void)
-{
-	writeecdata(SPICFG,0x18);
-}
-
-void end_SPI_firmware_mode_access(void)
-{
-	writeecdata(SPICFG,0x08);
-}
-
-/*
- * You must do this prior to _every_ command that
- * writes data to the part.  The write enable
- * latch resets after write commands complete.
- */
-void send_write_enable(void) {
-	start_SPI_firmware_mode_access();
-	short_delay();
-	docmd(WRITEENABLE);
-	wait_cmd_sent();
-	end_SPI_firmware_mode_access();
-}
-
-void send_addr(unsigned long addr)
-{
-	unsigned char data;
-
-	data = addr >> 16 & 0xff;
-	docmd(data);
-	wait_cmd_sent();
-
-	data = addr >> 8 & 0xff;
-	docmd(data);
-	wait_cmd_sent();
-
-	data = addr & 0xff;
-	docmd(data);
-}
-
-void enable_flash_cmd(void)
-{
-	writeecdata(SPICFG, SPICMDWE|readecdata(SPICFG));
-}
-
-void enable_flash_write_protect(void)
-{
-	unsigned char val;
-	val = readecdata(GPIO5);
-	val &= ~0x80;
-	writeecdata(GPIO5,val);
-}
-
-void disable_flash_write_protect(void)
-{
-	unsigned char val;
-	val = readecdata(GPIO5);
-	val |= 0x80;
-	writeecdata(GPIO5,val);
-}
-
-/*
- * This appears to be necessary.  If you watch the lines with 
- *	scope you will see that there is constant activity on the SPI
- *	bus to the part.  Trying to write to the port while all that
- * is going on is sure to muck things up.
- * Putting this into reset stops all that 
- * activity.
-
- * Plus Ray Tseng said so.
- * 
- */
-void put_kbc_in_reset(void)
-{
-	unsigned char val;
-	unsigned long timeout = 500000;
-
-	if (noop) return;
-
-	outb(0xd8,0x66);
-	while((inb(0x66) & 0x02) && (timeout>0)) {
-		timeout--;
-	}
-	val = readecdata(0xff14);
-	val |= 0x01;
-	writeecdata(0xff14,val);
-}
-
-void restore_kbc_run_mode(void)
-{
-	unsigned char val;
-
-	val = readecdata(0xff14);
-	val &= ~0x01;
-	writeecdata(0xff14,val);
-}
-
-unsigned char read_status_register(void)
-{
-	unsigned char data=0;
-	start_SPI_firmware_mode_access();
-	short_delay();
-	docmd(READSTATUS);
-	wait_cmd_sent();
-	docmd(DUMMY);
-	wait_cmd_sent();
-	data =  rdata();
-	end_SPI_firmware_mode_access();
-	return data;
-}
-
-// Staus reg writes; erases and programs all need to 
-// check this status bit.
-int wait_write_done(void)
-{
-	int trycount = 0;
-
-	if (noop) return 0;
-
-	while (read_status_register() & WIP){
-		trycount++;
-		myusec_delay(10);
-		// For the spansion part datasheet claims that 
-		// the only thing that takes longer than 500mS is 
-		// bulk erase and we don't ever want to use that
-		// command
-		if (trycount > 100000){ /* 1 second! */
-			printf("wait_write_done: Err: waited for > 1 second\n");
-			trycount = 0;
-			return -1;
-		}
-	}
-
-	return 0;
-}	
-
-int erase_sector(unsigned long addr)
-{
-	send_write_enable();
-	short_delay();
-
-	start_SPI_firmware_mode_access();
-	short_delay();
-
-	docmd(BLOCKERASEPCM);
-	wait_cmd_sent();
-
-	send_addr(addr);
-	wait_cmd_sent();
-
-	end_SPI_firmware_mode_access();
-
-	return wait_write_done();
-}
-
-/*
- Erase from sectors 0x10000 to 0xf0000
-*/
-int erase_linuxbios_area(void) 
-{
-	unsigned long addr;
-
-	for (addr = 0x10000;addr < 0xfffff;addr+=0x10000) {
-		printf("Erasing Sector: 0x%08lx\r\n",addr);
-		erase_sector(addr);
-	}
-	return 0;
-}
-
-int erase_EC_area(void) 
-{
-	unsigned long addr = 0;
-	printf("Erasing Sector: 0x%08lx\r\n",addr);
-	erase_sector(addr);
-	return 0;
-}
-
-int erase_flash(int mode)
-{
-	if (mode == 1) {
-		erase_EC_area();
-	}
-	erase_linuxbios_area();
-	return 0;
-}
-
-
-unsigned char read_flash_byte(unsigned long addr) 
-{
-	unsigned char data;
-
-	setaddr(addr);
-	docmd(READ);
-	wait_cmd_sent();
-	data =  rdata();
-	printf_debug("read 0x%x at 0x%lx\n", data, addr);
-	return data;
-}
-
-int read_flash(unsigned char *buf, unsigned long start, unsigned long size)
-{
-	unsigned long i;
-
-	printf("Reading %ld bytes from %lx\r\n",size,start);
-	for (i = start; i < start+size; i++) {
-		if ((i % 0x10000) == 0) printf("Sector 0x%08lx\r\n", i);
-		*buf = read_flash_byte(i);
-		buf++;
-	}
-	return 0;
-}
-
-int read_jdec_id(struct flashchip *flash)
-{
-	unsigned char data;
-
-	start_SPI_firmware_mode_access();
-	short_delay();
-
-	docmd(READJDECID);
-	wait_cmd_sent();
-	docmd(DUMMY);
-	wait_cmd_sent();
-	data = rdata();
-	flash->manufacture_id = data;
-	docmd(DUMMY);
-	wait_cmd_sent();
-	data = rdata();
-	flash->model_type = data;
-	docmd(DUMMY);
-	wait_cmd_sent();
-	data = rdata();
-	flash->model_id = data;
-
-	end_SPI_firmware_mode_access();
-	
-	return 0;
-}
-
-int write_flash_byte(unsigned long addr, unsigned char data) {
-
-	send_write_enable();
-	short_delay();
-
-	start_SPI_firmware_mode_access();
-	short_delay();
-
-	docmd(BYTEPROGRAM);
-	wait_cmd_sent();
-
-	send_addr(addr);
-	wait_cmd_sent();
-
-	docmd(data);
-	wait_cmd_sent();
-
-	end_SPI_firmware_mode_access();
-
-	wait_write_done();
-/*
-	unsigned char verify;
-	verify =  read_flash_byte(addr);
-	if (verify != data) {
-		printf("addr 0x%x, want 0x%x, got 0x%x\n", 
-				addr, data, verify);
-		return -1;
-	}
-*/
-	return 0;
-}
-
-int write_flash_page(unsigned char *buf, unsigned long addr, unsigned long size)
-{
-	
-	send_write_enable();
-	short_delay();
-
-	start_SPI_firmware_mode_access();
-	short_delay();
-
-	docmd(BYTEPROGRAM);
-	wait_cmd_sent();
-
-	send_addr(addr);
-	wait_cmd_sent();
-
-	while (size > 0) {
-		docmd(*buf);
-		wait_cmd_sent();
-		size--;
-		buf++;
-	}
-
-	end_SPI_firmware_mode_access();
-
-	wait_write_done();
-/*
-	unsigned char verify;
-	verify =  read_flash_byte(addr);
-	if (verify != data) {
-		printf("addr 0x%x, want 0x%x, got 0x%x\n", 
-				addr, data, verify);
-		return -1;
-	}
-*/
-	return 0;
-}
-
-int
-write_flash(unsigned char *buf, unsigned long start, unsigned long size){
-	unsigned long p=0;
-	unsigned long pages=0;
-	unsigned long short_page=0;
-	
-	pages = (size+(PAGE_SIZE-1))/PAGE_SIZE;
-	short_page = size-(pages*PAGE_SIZE);
-
-	printf("Writing %ld bytes starting at address 0x%lx\r\n",size,start);
-
-	for (p=0;p<pages;p++) {
-		if ((start % 0x10000) == 0) printf("Sector 0x%08lx\r\n", start);
-		printf_debug("Page %ld/%ld\r",p+1,pages);
-
-		if (write_flash_page(buf,start,PAGE_SIZE)) {
-			return -1;
-		}
-
-		buf+=PAGE_SIZE;
-		start+=PAGE_SIZE;
-	}
-	printf_debug("\r\n");
-
-	if (short_page) {
-		printf_debug("Short Page of %ld bytes\r\n",short_page);	
-		printf_debug("Address %ld\r\n",start);	
-
-		if (write_flash_page(buf,start,short_page)) {
-			return -1;
-		}
-	}
-
-	return 0;
-}
-
-int verify_flash(unsigned char *buf, unsigned long start, unsigned long size)
-{
-	unsigned long idx;
-	unsigned char r_val;
-
-	printf("Verifying flash\n");
-	
-	if(verbose) printf("address: 0x00000000\b\b\b\b\b\b\b\b\b\b");
-	
-	for (idx = start; idx < start+size; idx++) {
-		if (verbose && ( (idx & 0xfff) == 0xfff ))
-			printf("0x%08lx", idx);
-
-		if ((idx % 0x10000) == 0)
-			printf("Sector 0x%08lx\r\n", idx);
-
-		r_val = read_flash_byte(idx);
-
-		if ( r_val != *buf ) {
-			printf("0x%08lx: ", idx);
-			printf("Expected 0x%02x Got 0x%02x\n",*buf,r_val);
-			printf("Verify FAILED\n");
-			return 1;
-		}
-		buf++;
-
-		if (verbose && ( (idx & 0xfff) == 0xfff ))
-			printf("\b\b\b\b\b\b\b\b\b\b");
-	}
-	if (verbose) 
-		printf("\b\b\b\b\b\b\b\b\b\b ");
-	
-	printf("- VERIFIED         \n");
-	return 0;
-}
-
-
-void usage(const char *name)
-{
-	printf("%s Ver: %d.%d.%d\n",name,VER_MAJOR,VER_MINOR,VER_RELEASE);
-	printf("usage: %s [-rwv] [-V] [file]\n", name);
-	printf("   -r | --read      read flash and save into file\n"
-	       "   -w | --write     write file into flash\n"
-	       "   -v | --verify    verify flash against file\n"
-	       "   -E | --erase     erase LinuxBIOS area (0x10000-0xfffff)\n"
-	       "   -V | --verbose   more verbose output\n"
-               "   -n | --noop Noop mode. Do the motions but no io\n"
-               "   -h | --help This message\n"
-	       "        --no-verify skip the autoverify on write\n"
-	       "   -P | --nobrick: Partial mode. Writes start @ 64Kib\n"	       
-	       "   -I | --id        print out part JDEC ID values\n"
-	       "   -f | --force-id <id>  Force a specific ID\n"
-	       "\n\n");
-	exit(1);
-}
-
-int main(int argc, char *argv[])
-{
-	unsigned long size;
-	unsigned long start_addr=LINUXBIOS_START;
-	FILE *image;
-	int opt;
-	int option_index = 0;
-	int read_it = 0, 
-	    write_it = 0, 
-	    erase_it = 0, 
-	    verify_it = 0,
-	    show_id =0;
-	int auto_verify = 1;
-	int force_id = 0;
-	int brick_mode = 1;
-	int ret = 0;
-	int i=0;
-	int forced_id=0;
-	unsigned char buf[ROM_SIZE];
-	unsigned char* buf_start=NULL;
-
-	struct flashchip flash;
-
-	static struct option long_options[]= {
-		{ "read",		0, 0, 'r' },
-		{ "write",		0, 0, 'w' },
-		{ "erase",		0, 0, 'E' },
-		{ "verify", 		0, 0, 'v' },
-		{ "iobase",		1, 0, 'i' },
-		{ "verbose",		0, 0, 'V' },
-		{ "help", 		0, 0, 'h' },
-		{ "brick",		0, 0, 'B' },
-		{ "nobrick",		0, 0, 'P' },
-		{ "noop",		0, 0, 'n' },
-		{ "no-verify",		0, 0, 'a' },
-		{ "id",			0, 0, 'I' },
-		{ "force-id",		1, 0, 'f' },
-		{ 0, 0, 0, 0 }
-	};
-	
-	char *filename = NULL;
-
-	setbuf(stdout, NULL);
-	while ((opt = getopt_long(argc, argv, "rwvVEnIhPi:f:", long_options,
-					&option_index)) != EOF) {
-		switch (opt) {
-		case 'r':
-			read_it = 1;
-			break;
-		case 'w':
-			write_it = 1;
-			break;
-		case 'v':
-			verify_it = 1;
-			break;
-		case 'V':
-			verbose++;
-			break;
-		case 'E':
-			erase_it = 1;
-			break;
-		case 'i':
-			errno = 0;
-			iobase = (unsigned short) strtol(optarg,0,0);
-			if (errno || (iobase == 0)) {
-				printf("Invalid IO base\n");
-				exit(1);
-			}
-			break;
-		case 'B':
-			brick_mode = 1;
-			break;
-		case 'P':
-			brick_mode = 0;
-			break;
-		case 'n':
-			noop = 1;
-			break;
-		case 'a':
-			auto_verify = 0;
-			break;
-		case 'I':
-			show_id = 1;
-			break;
-
-		case 'f': 
-			force_id = 1;
-			errno = 0;
-			forced_id = (int) strtol(optarg,0,0);
-			if (errno || (forced_id  == 0)) {
-				printf("Invalid Mfg ID\n");
-				exit(1);
-			}
-			break;
-
-		case 'h':
-		default:
-			usage(argv[0]);
-			break;
-		}
-	}
-
-	if (argc > 1) {
-		/* Yes, print them. */
-		int i;
-		printf_debug ("The arguments are:\n");
-		for (i = 1; i < argc; ++i)
-			printf_debug ("%s\n", argv[i]);
-	}
-
-	if (!noop) {
-		if (iopl(3) < 0){
-			perror("iop(3)");
-			exit(1);
-		}
-	}
-
-	if (iobase != IOBASE_DEFAULT) {
-		printf("Useing IO base of 0x%x\n",(unsigned int)iobase);
-	}
-
-	if (read_it && write_it) {
-		printf("-r and -w are mutually exclusive\n");
-		usage(argv[0]);
-	}
-
-	if (optind < argc)
-		filename = argv[optind++];
-
-	if (!erase_it && !write_it && !read_it && !verify_it && !show_id) {
-		printf("No command specified so no operations performed\n");
-		printf("Use -h for details\n");
-		exit(2);
-	}
-
-	printf("Calibrating delay loop... ");
-	myusec_calibrate_delay();
-	printf("ok\n");
-
-	enable_flash_cmd();
-	/* 
-	 * This is required prior to _all_ commands. Otherwise the kbc can steal your data
-	 */
-	put_kbc_in_reset();
-
-	read_jdec_id(&flash);
-
-	if (show_id) {
-		printf("Manufacture ID = 0x%x\n",flash.manufacture_id);
-		printf("Model Type     = 0x%x\n",flash.model_type);
-		printf("Model ID       = 0x%x\n",flash.model_id);
-	}
-
-	if (force_id) {
-		flash.manufacture_id = forced_id;
-	}
-
-	switch (flash.manufacture_id) {
-
-		case SST:
-//			flash.write_page = write_flash_page_sst;
-			printf("SST part found\n");
-		break;
-
-		case WINBOND:
-			flash.write_page = write_flash_page;
-			printf("Windbond part found\n");
-		break;
-		case SPANSION:
-			flash.write_page = write_flash_page;
-			printf("Spansion part found\n");
-		break;
-
-		default:
-			printf("Unable to determine flash type\n");
-			printf("use the -f option to force\n");
-			exit(1);
-	}
-
-	size = ROM_SIZE;
-	start_addr = 0;
-	buf_start = buf;
-
-	for (i=0;i<size;i++) {
-		buf[i] = 0xff;
-	}
-
-	if (brick_mode != 1) {
-		// Normal image
-		// Skip the 1st 64k of the part and the 
-		// file we loaded
-		size -= EC_CODE_SIZE;
-		start_addr = LINUXBIOS_START;
-		buf_start+= EC_CODE_SIZE;
-
-		printf("Partial modei. Skipping first 64Kib\n");
-	}
-	else {
-		printf("Brick mode. Will operate on the first 64Kib\n");
-	}
-
-	if (erase_it) {
-		put_kbc_in_reset();
-		disable_flash_write_protect();
-		erase_flash(brick_mode);
-		enable_flash_write_protect();
-		exit(0);		
-	} else if (read_it) {
-		if ((image = fopen(filename, "w")) == NULL) {
-			perror(filename);
-			exit(1);
-		}
-
-		put_kbc_in_reset();
-
-		// Reading allways read the entire part
-		read_flash(buf,0,ROM_SIZE);
-
-		fwrite(buf, sizeof(char),ROM_SIZE, image);
-		fclose(image);
-		printf("done\n");
-
-	} else {
-		if ((image = fopen(filename, "r")) == NULL) {
-			perror(filename);
-			exit(1);
-		}
-		printf("Loading 0x%x bytes from %s\r\n",ROM_SIZE,filename);
-		fread(buf, sizeof(char), ROM_SIZE, image);
-		fclose(image);
-	}
-
-	if (write_it) {
-		put_kbc_in_reset();
-		disable_flash_write_protect();
-		erase_flash(brick_mode);
-		write_flash(buf_start,start_addr, size);
-		enable_flash_write_protect();
-		if (auto_verify) {
-			ret |= verify_flash(buf_start,start_addr,size);
-		}
-	}
-
-	if (verify_it) {
-		put_kbc_in_reset();
-		ret |= verify_flash(buf_start,start_addr,size);
-	}
-
-	printf("IMPORTANT! The kbc has been left in reset. You keyboard and mouse WILL NOT WORK until you POWER CYCLE.\n");
-	printf("A warm reboot is NOT good enough.\n");
-	return ret;
-}
-
Index: buildrom-devel/packages/olpcflash/olpcflash.mk
===================================================================
--- buildrom-devel.orig/packages/olpcflash/olpcflash.mk	2007-10-03 13:22:59.000000000 -0600
+++ /dev/null	1970-01-01 00:00:00.000000000 +0000
@@ -1,43 +0,0 @@
-OLPCFLASH_DIR=$(BUILD_DIR)/olpcflash
-OLPCFLASH_SRC_DIR=$(OLPCFLASH_DIR)/olpcflash
-OLPCFLASH_STAMP_DIR=$(OLPCFLASH_DIR)/stamps
-OLPCFLASH_LOG_DIR=$(OLPCFLASH_DIR)/logs
-
-ifeq ($(CONFIG_VERBOSE),y)
-OLPCFLASH_BUILD_LOG=/dev/stdout
-OLPCFLASH_INSTALL_LOG=/dev/stdout
-else
-OLPCFLASH_BUILD_LOG=$(OLPCFLASH_LOG_DIR)/build.log
-OLPCFLASH_INSTALL_LOG=$(OLPCFLASH_LOG_DIR)/install.log
-endif
-
-$(OLPCFLASH_SRC_DIR)/olpcflash.c: $(PACKAGE_DIR)/olpcflash/Makefile $(PACKAGE_DIR)/olpcflash/olpcflash.c
-	@ mkdir -p $(OLPCFLASH_SRC_DIR)
-	@ cp $(PACKAGE_DIR)/olpcflash/Makefile $(OLPCFLASH_SRC_DIR)
-	@ cp $(PACKAGE_DIR)/olpcflash/olpcflash.c $(OLPCFLASH_SRC_DIR)
-
-$(OLPCFLASH_SRC_DIR)/olpcflash: $(OLPCFLASH_SRC_DIR)/olpcflash.c
-	@ echo "Building olpcflash..."
-	@ $(MAKE) -C $(OLPCFLASH_SRC_DIR) > $(OLPCFLASH_BUILD_LOG) 2>&1
-
-$(INITRD_DIR)/bin/olpcflash: $(OLPCFLASH_SRC_DIR)/olpcflash
-	@ install -d $(INITRD_DIR)/bin
-	@ install -m 0755 $(OLPCFLASH_SRC_DIR)/olpcflash $@
-	@ $(STRIP) $(INITRD_DIR)/bin/olpcflash
-
-$(OLPCFLASH_STAMP_DIR) $(OLPCFLASH_LOG_DIR):
-	@ mkdir -p $@
-
-olpcflash: $(OLPCFLASH_STAMP_DIR) $(OLPCFLASH_LOG_DIR) $(INITRD_DIR)/bin/olpcflash
-
-olpcflash-clean:
-	@ echo "Cleaning olpcflash..."
-	@ $(MAKE) -C $(OLPCFLASH_SRC_DIR) clean > /dev/null 2>&1
-
-olpcflash-distclean:
-	@ rm -rf $(OLPCFLASH_DIR)/*
-
-olpcflash-bom:
-	@ echo "Package: olpcflash"
-	@ echo "Source: (local) buildrom/packages/olpcflash/olpcflash.c"
-	@ echo ""
Index: buildrom-devel/README
===================================================================
--- buildrom-devel.orig/README	2007-10-03 13:22:59.000000000 -0600
+++ buildrom-devel/README	2007-10-03 13:23:14.000000000 -0600
@@ -48,8 +48,6 @@
   CONFIG_KBL_KEXEC_ONLY - Build only the Kexec part of the KBL
   CONFIG_KBL - Build Marcelo Toscatti's kernel boot loader
   CONFIG_BUSYBOX - Build busybox
-  CONFIG_BOOTMENU - Build the OLPC bootmenu
-  CONFIG_OLPCFLASH - Build the 'olpcflash' utility
 
 memtest:
   CONFIG_MEMTEST_SERIAL - say 'y' here to enable serial output for memtest
Index: buildrom-devel/README.signature
===================================================================
--- buildrom-devel.orig/README.signature	2007-10-03 13:23:19.000000000 -0600
+++ /dev/null	1970-01-01 00:00:00.000000000 +0000
@@ -1,35 +0,0 @@
-Description of the fimrware signature
-
-Pulled from http://dev.laptop.org/ticket/153.
-
-Here's the format:
-
-At offset f.ffc0 in FLASH:
-BW2   Q1A82  Q1A
-------.....  ---
-  |     |     |
-  |     |     |---First 3 characters of revision
-  |     |
-  |     |---Revision
-  |
-  |--- Model
-
-Revision is:
-
-Q - Manufacturer, i.e. Quanta
-1 - board revision number
-A - Major firmware revision
-82- Minor firmware revision
-
-------- Quanta describes their release sequence:
-
-Let me explain our ISO sequence: Qxxxx First x: 1 for A test, 2 for B test, 3 for C test Second x: A~Z: milestone Third x: 1~9: change when test team release to customer, manufacture (outside R&D) Forth x: 1~9: change when sw team release to test team.(inside R&D)
-
-Take EC as example: Q1A11 when sw team release to test team. Test team find some problems, can not relase out Q1A12 when sw team fix the problem and release to test team again Test team test OK, and release out
-
-Next version sw team release will be Q1A21
-
-As I mentioned we will use file name to distinguish the release.
-
-EC release will be PQ1A21.bin (Leading by P) BIOS release will be BQ2A11.bin (leading by B) 
-

From jordan.crouse at amd.com  Tue Oct  2 22:13:17 2007
From: jordan.crouse at amd.com (Jordan Crouse)
Date: Tue, 2 Oct 2007 14:13:17 -0600
Subject: [LinuxBIOS] [BUILDROM]:  Disable OFW
Message-ID: <20071002201317.GF27248@cosmic.amd.com>

Okay, now that everybody has recovered from the last patch, here's the 
last one - disable OFW for the short term in buildrom.  Reason being,
that it only worked for OLPC, and the previous patch removed OLPC.   I
discussed the matter briefly with Stefan and Segher, and they tell me
that there are ongoing efforts to make OFW or a OpenFirmware clone of
some sort usable on a generic x86.  I support that 100%, I think OFW
is a vital payload for this project.  I just don't know enough about
OpenFirmware to get the job done.  So I am submitting a patch to
disable, but not to remove the OFW scripts, so that those who do know
what they are doing can port the code easily.  When everything works,
revert this patch, and we're off to the races.

Jordan

-- 
Jordan Crouse
Systems Software Development Engineer 
Advanced Micro Devices, Inc.
-------------- next part --------------
[BUILDROM]:  Disable OFW

Since OFW in buildrom was only for OLPC, not having OLPC means that OFW
isn't useful right now - hopefully somebody can do do the work to make
OFW or a clone useful for generic x86 platforms.

Signed-off-by: Jordan Crouse <jordan.crouse at amd.com>
Index: buildrom-devel/config/payloads/Config.in
===================================================================
--- buildrom-devel.orig/config/payloads/Config.in	2007-10-03 13:11:57.000000000 -0600
+++ buildrom-devel/config/payloads/Config.in	2007-10-03 13:12:59.000000000 -0600
@@ -31,11 +31,11 @@
 	bool "Linux As Bootloader"
 	select PAYLOAD
 
-config PAYLOAD_OFW
-	depends !PLATFORM_M57SLI
-	depends !PLATFORM_TYAN_S2891
-	bool "OpenFirmware"
-	select PAYLOAD
+#config PAYLOAD_OFW
+#	depends !PLATFORM_M57SLI
+#	depends !PLATFORM_TYAN_S2891
+#	bool "OpenFirmware"
+#	select PAYLOAD
 
 config PAYLOAD_MEMTEST
 	depends !PLATFORM_M57SLI
Index: buildrom-devel/config/payloads/payloads.conf
===================================================================
--- buildrom-devel.orig/config/payloads/payloads.conf	2007-10-03 13:11:57.000000000 -0600
+++ buildrom-devel/config/payloads/payloads.conf	2007-10-03 13:12:59.000000000 -0600
@@ -19,7 +19,7 @@
 PCONF-$(CONFIG_PAYLOAD_LAB) = lab.conf
 PCONF-$(CONFIG_PAYLOAD_ETHERBOOT) = etherboot.conf
 PCONF-$(CONFIG_PAYLOAD_FILO) = filo.conf
-PCONF-$(CONFIG_PAYLOAD_OFW) = ofw.conf
+#PCONF-$(CONFIG_PAYLOAD_OFW) = ofw.conf
 PCONF-$(CONFIG_PAYLOAD_MEMTEST) = memtest.conf
 PCONF-$(CONFIG_PAYLOAD_KERNEL) = kernel.conf
 PCONF-$(CONFIG_PAYLOAD_CUSTOM) = custom.conf

From kevint at lanl.gov  Tue Oct  2 23:26:37 2007
From: kevint at lanl.gov (kevint)
Date: Tue, 2 Oct 2007 15:26:37 -0600
Subject: [LinuxBIOS] hdama compile error
Message-ID: <DEE8917F-067D-4757-8BCE-746526351470@lanl.gov>

Hello,

I am trying to build an hdama target with LinuxBIOSv2 and came across  
this compile error:

[...]
coherent_ht.c:1752.25: coherent_ht.c:1836.41: auto.c:193.47: warning:  
used: %ecx
coherent_ht.c:1752.25: coherent_ht.c:1836.41: auto.c:193.47: warning:  
used: %edx
coherent_ht.c:1752.25: coherent_ht.c:1836.41: auto.c:193.47: warning:  
used: %esi
coherent_ht.c:1752.25: coherent_ht.c:1836.41: auto.c:193.47: warning:  
used: %edi
coherent_ht.c:1752.25: coherent_ht.c:1836.41: auto.c:193.47: warning:  
used: %ebp
coherent_ht.c:1752.25: coherent_ht.c:1836.41: auto.c:193.47: warning:  
used: %esp
coherent_ht.c:1752.25: coherent_ht.c:1836.41: auto.c:193.47: warning:  
used: %edx:%eax
coherent_ht.c:1752.25: coherent_ht.c:1836.41: auto.c:193.47: warning:  
used: %dx:%ax
coherent_ht.c:1752.25: coherent_ht.c:1836.41: auto.c:193.47:
too few registers
make[1]: *** [auto.inc] Error 1
make[1]: Leaving directory `/tmp/LinuxBIOSv2/targets/arima/hdama/ 
hdama/normal'
make: *** [normal/linuxbios.rom] Error 1

I noticed this was mentioned in a 2004 mailing list post by Eric  
Biederman.  The final message, from YhLu, included what appeared to  
be the fix.  I looked at coherent_ht.c and it looks like it was applied.

Also, Arima has a new revision to the hdama board that changes the  
pci layout slightly.  The newest revision is:

(lspci -n)

00:18.0 Class 0600: 1022:1100
00:18.1 Class 0600: 1022:1101
00:18.2 Class 0600: 1022:1102
00:18.3 Class 0600: 1022:1103
00:19.0 Class 0600: 1022:1100
00:19.1 Class 0600: 1022:1101
00:19.2 Class 0600: 1022:1102
00:19.3 Class 0600: 1022:1103
01:01.0 Class 0604: 1022:7450 (rev 12)
01:01.1 Class 0800: 1022:7451 (rev 01)
01:02.0 Class 0604: 1022:7450 (rev 12)
01:02.1 Class 0800: 1022:7451 (rev 01)
01:03.0 Class 0604: 1022:7460 (rev 07)
01:04.0 Class 0601: 1022:7468 (rev 05)
01:04.1 Class 0101: 1022:7469 (rev 03)
01:04.2 Class 0c05: 1022:746a (rev 02)
01:04.3 Class 0680: 1022:746b (rev 05)
01:04.6 Class 0703: 1022:746e (rev 03)
02:03.0 Class 0200: 14e4:1648 (rev 10)
02:03.1 Class 0200: 14e4:1648 (rev 10)
03:01.0 Class 0280: 14c1:8043 (rev 04)
04:00.0 Class 0c03: 1022:7464 (rev 0b)
04:00.1 Class 0c03: 1022:7464 (rev 0b)
04:06.0 Class 0300: 1002:4752 (rev 27)
04:07.0 Class 0180: 1095:3114 (rev 02)

The last line is the SATA controller, which is optional on the new  
board.  The broadcom chips are now on 2:03.0/1 instead of 2:03.0/2:04.0.

The previous board revisions had the following pci layout:

00:18.0 Class 0600: 1022:1100
00:18.1 Class 0600: 1022:1101
00:18.2 Class 0600: 1022:1102
00:18.3 Class 0600: 1022:1103
00:19.0 Class 0600: 1022:1100
00:19.1 Class 0600: 1022:1101
00:19.2 Class 0600: 1022:1102
00:19.3 Class 0600: 1022:1103
01:01.0 Class 0604: 1022:7450 (rev 12)
01:01.1 Class 0800: 1022:7451 (rev 01)
01:02.0 Class 0604: 1022:7450 (rev 12)
01:02.1 Class 0800: 1022:7451 (rev 01)
01:03.0 Class 0604: 1022:7460 (rev 07)
01:04.0 Class 0601: 1022:7468 (rev 05)
01:04.1 Class 0101: 1022:7469 (rev 03)
01:04.2 Class 0c05: 1022:746a (rev 02)
01:04.3 Class 0000: 1022:746b (rev 05)
02:03.0 Class 0200: 14e4:16a6 (rev 02)
02:04.0 Class 0200: 14e4:16a6 (rev 02)
03:01.0 Class 0280: 14c1:8043 (rev 04)
04:00.0 Class 0c03: 1022:7464 (rev 0b)
04:00.1 Class 0c03: 1022:7464 (rev 0b)
04:00.2 Class 0c03: 1022:7463 (rev 02)
04:06.0 Class 0300: 1002:4752 (rev 27)

Will this require a new mainboard target?  I would appreciate any  
help you can provide!

Thanks,

********************************************
Kevin Tegtmeier
HPC-3 Scientific Computing Resources
Los Alamos National Laboratory
email:  kevint at lanl dot gov
********************************************



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20071002/ab4dcd48/attachment.html>

From uwe at hermann-uwe.de  Wed Oct  3 00:17:02 2007
From: uwe at hermann-uwe.de (Uwe Hermann)
Date: Wed, 3 Oct 2007 00:17:02 +0200
Subject: [LinuxBIOS] [PATCH] improved SPI flash support (restructured)
In-Reply-To: <4700EDCF.6020809@gmx.net>
References: <46FB7862.9090008@gmx.net> <20070927143042.GA3788@localdomain>
	<46FD033A.2000108@gmx.net> <20070928145508.GH7553@greenwood>
	<46FD852A.9030400@gmx.net> <46FDB3AD.4070609@gmx.net>
	<20070929135924.GA6264@coresystems.de>
	<4700CBDE.4070801@gmx.net> <20071001122559.GA11604@localdomain>
	<4700EDCF.6020809@gmx.net>
Message-ID: <20071002221701.GD17835@greenwood>

On Mon, Oct 01, 2007 at 02:53:35PM +0200, Carl-Daniel Hailfinger wrote:
> Index: util/flashrom/flash.h
> ===================================================================
> --- util/flashrom/flash.h	(Revision 2814)
> +++ util/flashrom/flash.h	(Arbeitskopie)
> @@ -55,6 +55,8 @@
>  /* Please keep this list sorted alphabetically by manufacturer. The first
>   * entry of each section should be the manufacturer ID, followed by the
>   * list of devices from that manufacturer (sorted by device IDs).
> + * All LPC/FWH parts (parallel flash) have 8-bit device IDs.
> + * All SPI parts have 16-bit device IDs.
>   */
>  
>  #define AMD_ID			0x01	/* AMD */
> @@ -68,8 +70,31 @@
>  #define AT_29C040A		0xA4
>  #define AT_29C020		0xDA
>  
> +#define EON_ID			0x1C
> +/* EN25 chips are SPI, first byte of device id is memory type,
> +   second byte of device id is log(bitsize)-9 */

id -> ID


> +#define EN_25B05		0x2010	/* 2^19 kbit or 2^16 kByte */
> +#define EN_25B10		0x2011
> +#define EN_25B20		0x2012
> +#define EN_25B40		0x2013
> +#define EN_25B80		0x2014
> +#define EN_25B16		0x2015
> +#define EN_25B32		0x2016
> +
>  #define MX_ID			0xC2	/* Macronix (MX) */
>  #define MX_29F002		0xB0
> +/* MX25L chips are SPI, first byte of device id is memory type,
> +   second byte of device id is log(bitsize)-9 */

id -> ID


> +#define MX_25L512		0x2010	/* 2^19 kbit or 2^16 kByte */
> +#define MX_25L1005		0x2011
> +#define MX_25L2005		0x2012
> +#define MX_25L4005		0x2013	/* MX25L4005{,A} */
> +#define MX_25L8005		0x2014
> +#define MX_25L1605		0x2015	/* MX25L1605{,A,D} */
> +#define MX_25L3205		0x2016	/* MX25L3205{,A} */
> +#define MX_25L6405		0x2017	/* MX25L3205{,D} */
> +#define MX_25L1635D		0x2415
> +#define MX_25L3235D		0x2416
>  
>  #define SHARP_ID		0xB0	/* Sharp */
>  #define SHARP_LHF00L04		0xCF
> @@ -182,6 +207,8 @@
>  int linuxbios_init(void);
>  extern char *lb_part, *lb_vendor;
>  
> +int probe_spi(struct flashchip *flash);
> +
>  /* 82802ab.c */
>  int probe_82802ab(struct flashchip *flash);
>  int erase_82802ab(struct flashchip *flash);
> Index: util/flashrom/board_enable.c
> ===================================================================
> --- util/flashrom/board_enable.c	(Revision 2814)
> +++ util/flashrom/board_enable.c	(Arbeitskopie)
> @@ -30,6 +30,15 @@
>  #include <string.h>
>  #include "flash.h"
>  
> +#define ITE_SUPERIO_PORT1	0x2e
> +#define ITE_SUPERIO_PORT2	0x4e
> +
> +#define JEDEC_RDID	{0x9f}
> +#define JEDEC_RDID_OUTSIZE	0x01
> +#define JEDEC_RDID_INSIZE	0x03
> +
> +static uint16_t it8716f_flashport = 0;
> +
>  /* Generic Super I/O helper functions */
>  uint8_t regval(uint16_t port, uint8_t reg)
>  {
> @@ -51,7 +60,7 @@
>  	outb(0x87, port);
>  	outb(0x01, port);
>  	outb(0x55, port);
> -	if (port == 0x2e)
> +	if (port == ITE_SUPERIO_PORT1)
>  		outb(0x55, port);
>  	else
>  		outb(0xaa, port);
> @@ -96,35 +105,97 @@
>  	return flashport;
>  }
>  
> -static void it8716_serial_rdid(uint16_t port)
> +/* The IT8716F only supports commands with length 1,2,4,5 bytes including
> +   command byte and can not read more than 3 bytes from the device.
> +   This function expects writearr[0] to be the first byte sent to the device,
> +   whereas the IT8716F splits commands internally into address and non-address
> +   commands with the address in inverse wire order. That's why the register
> +   ordering in case 4 and 5 may seem strange. */

Please make all multi-line comments look the same as in the rest of the
code:

/* Foo
 * Bar
 */

Or, if we want to use the exact Linux-style:

/*
 * Foo
 * Bar
 */


> +static int it8716f_spi_command(uint16_t port, unsigned char writecnt, unsigned char readcnt, const unsigned char *writearr, unsigned char *readarr)

As per another mail, writecnt/readcnt/writearr/readarr seems to have a
dont-care size, so I think we can make them all 'int' (or 'unsigned int'
if they can't or shouldn't get negative).

I think using the "native" int type is the best solution in general, it
gives the compiler maximum freedom to optimize (not that it would matter
much here).


> Index: util/flashrom/flashchips.c
> ===================================================================
> --- util/flashrom/flashchips.c	(Revision 2814)
> +++ util/flashrom/flashchips.c	(Arbeitskopie)
> @@ -38,6 +38,8 @@
>  	 probe_jedec,	erase_chip_jedec, write_jedec},
>  	{"Mx29f002",	MX_ID,		MX_29F002,	256, 64 * 1024,
>  	 probe_29f002,	erase_29f002, 	write_29f002},
> +	{"MX25L4005",	MX_ID,		MX_25L4005,	512, 4 * 1024,
> +	 probe_spi,	NULL,		NULL},

All the other chips from above are not added?


>  	{"SST29EE020A", SST_ID,		SST_29EE020A,	256, 128,
>  	 probe_jedec,	erase_chip_jedec, write_jedec},
>  	{"SST28SF040A", SST_ID,		SST_28SF040,	512, 256,


With the above fixes:
Acked-by: Uwe Hermann <uwe at hermann-uwe.de>


Uwe.
-- 
http://www.hermann-uwe.de  | http://www.holsham-traders.de
http://www.crazy-hacks.org | http://www.unmaintained-free-software.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20071003/a0e04a46/attachment.sig>

From marc.jones at amd.com  Wed Oct  3 00:28:48 2007
From: marc.jones at amd.com (Marc Jones)
Date: Tue, 02 Oct 2007 16:28:48 -0600
Subject: [LinuxBIOS] hdama compile error
In-Reply-To: <DEE8917F-067D-4757-8BCE-746526351470@lanl.gov>
References: <DEE8917F-067D-4757-8BCE-746526351470@lanl.gov>
Message-ID: <4702C620.2050602@amd.com>



kevint wrote:
> Hello,
> 
> I am trying to build an hdama target with LinuxBIOSv2 and came across 
> this compile error:
> 
> [...]
> coherent_ht.c:1752.25: coherent_ht.c:1836.41: auto.c:193.47: warning: 
> used: %ecx
> coherent_ht.c:1752.25: coherent_ht.c:1836.41: auto.c:193.47: warning: 
> used: %edx
> coherent_ht.c:1752.25: coherent_ht.c:1836.41: auto.c:193.47: warning: 
> used: %esi
> coherent_ht.c:1752.25: coherent_ht.c:1836.41: auto.c:193.47: warning: 
> used: %edi
> coherent_ht.c:1752.25: coherent_ht.c:1836.41: auto.c:193.47: warning: 
> used: %ebp
> coherent_ht.c:1752.25: coherent_ht.c:1836.41: auto.c:193.47: warning: 
> used: %esp
> coherent_ht.c:1752.25: coherent_ht.c:1836.41: auto.c:193.47: warning: 
> used: %edx:%eax
> coherent_ht.c:1752.25: coherent_ht.c:1836.41: auto.c:193.47: warning: 
> used: %dx:%ax
> coherent_ht.c:1752.25: coherent_ht.c:1836.41: auto.c:193.47:
> too few registers
> make[1]: *** [auto.inc] Error 1
> make[1]: Leaving directory 
> `/tmp/LinuxBIOSv2/targets/arima/hdama/hdama/normal'
> make: *** [normal/linuxbios.rom] Error 1
> 
> I noticed this was mentioned in a 2004 mailing list post by Eric 
> Biederman.  The final message, from YhLu, included what appeared to be 
> the fix.  I looked at coherent_ht.c and it looks like it was applied.
> 
> Also, Arima has a new revision to the hdama board that changes the pci 
> layout slightly.  The newest revision is:
> 
> (lspci -n)
> 
> 00:18.0 Class 0600: 1022:1100
> 00:18.1 Class 0600: 1022:1101
> 00:18.2 Class 0600: 1022:1102
> 00:18.3 Class 0600: 1022:1103
> 00:19.0 Class 0600: 1022:1100
> 00:19.1 Class 0600: 1022:1101
> 00:19.2 Class 0600: 1022:1102
> 00:19.3 Class 0600: 1022:1103
> 01:01.0 Class 0604: 1022:7450 (rev 12)
> 01:01.1 Class 0800: 1022:7451 (rev 01)
> 01:02.0 Class 0604: 1022:7450 (rev 12)
> 01:02.1 Class 0800: 1022:7451 (rev 01)
> 01:03.0 Class 0604: 1022:7460 (rev 07)
> 01:04.0 Class 0601: 1022:7468 (rev 05)
> 01:04.1 Class 0101: 1022:7469 (rev 03)
> 01:04.2 Class 0c05: 1022:746a (rev 02)
> 01:04.3 Class 0680: 1022:746b (rev 05)
> 01:04.6 Class 0703: 1022:746e (rev 03)
> 02:03.0 Class 0200: 14e4:1648 (rev 10)
> 02:03.1 Class 0200: 14e4:1648 (rev 10)
> 03:01.0 Class 0280: 14c1:8043 (rev 04)
> 04:00.0 Class 0c03: 1022:7464 (rev 0b)
> 04:00.1 Class 0c03: 1022:7464 (rev 0b)
> 04:06.0 Class 0300: 1002:4752 (rev 27)
> 04:07.0 Class 0180: 1095:3114 (rev 02)
> 
> The last line is the SATA controller, which is optional on the new 
> board.  The broadcom chips are now on 2:03.0/1 instead of 2:03.0/2:04.0.
> 
> The previous board revisions had the following pci layout:
> 
> 00:18.0 Class 0600: 1022:1100
> 00:18.1 Class 0600: 1022:1101
> 00:18.2 Class 0600: 1022:1102
> 00:18.3 Class 0600: 1022:1103
> 00:19.0 Class 0600: 1022:1100
> 00:19.1 Class 0600: 1022:1101
> 00:19.2 Class 0600: 1022:1102
> 00:19.3 Class 0600: 1022:1103
> 01:01.0 Class 0604: 1022:7450 (rev 12)
> 01:01.1 Class 0800: 1022:7451 (rev 01)
> 01:02.0 Class 0604: 1022:7450 (rev 12)
> 01:02.1 Class 0800: 1022:7451 (rev 01)
> 01:03.0 Class 0604: 1022:7460 (rev 07)
> 01:04.0 Class 0601: 1022:7468 (rev 05)
> 01:04.1 Class 0101: 1022:7469 (rev 03)
> 01:04.2 Class 0c05: 1022:746a (rev 02)
> 01:04.3 Class 0000: 1022:746b (rev 05)
> 02:03.0 Class 0200: 14e4:16a6 (rev 02)
> 02:04.0 Class 0200: 14e4:16a6 (rev 02)
> 03:01.0 Class 0280: 14c1:8043 (rev 04)
> 04:00.0 Class 0c03: 1022:7464 (rev 0b)
> 04:00.1 Class 0c03: 1022:7464 (rev 0b)
> 04:00.2 Class 0c03: 1022:7463 (rev 02)
> 04:06.0 Class 0300: 1002:4752 (rev 27)
> 
> Will this require a new mainboard target?  I would appreciate any help 
> you can provide!
> 
> Thanks,
> 
> ********************************************
> Kevin Tegtmeier
> HPC-3 Scientific Computing Resources
> Los Alamos National Laboratory
> email:  kevint at lanl dot gov
> ********************************************
> 
> 
> 

Kevin,

I am no expert, but it looks like this platform is still using ROMCC and 
needs to be ported to CAR.

PCI should just work since it is based off of the device ID and not the 
physical location.


Question to others: Shouldn't the abuild be catching this?

Marc


-- 
Marc Jones
Senior Firmware Engineer
(970) 226-9684 Office
mailto:Marc.Jones at amd.com
http://www.amd.com/embeddedprocessors





From joe at smittys.pointclark.net  Wed Oct  3 00:57:36 2007
From: joe at smittys.pointclark.net (joe at smittys.pointclark.net)
Date: Tue, 02 Oct 2007 18:57:36 -0400
Subject: [LinuxBIOS] System Memory Address Map
Message-ID: <20071002185736.pudb00gs0s4g8gcc@www.smittys.pointclark.net>

Hello,
Is there a function in LinuxBIOS that can dump the System Memory  
Address Map kind of like a kernel does when it first boots?? This  
would greatly help me to see what is going on with my memory alocation  
issue.

Thanks - Joe



From jonathansturges at yahoo.com  Wed Oct  3 01:16:43 2007
From: jonathansturges at yahoo.com (Jonathan Sturges)
Date: Tue, 2 Oct 2007 16:16:43 -0700 (PDT)
Subject: [LinuxBIOS] Two more CS5530 IRQ steering questions
Message-ID: <735999.11669.qm@web35906.mail.mud.yahoo.com>

>Jonathan,
>
>You can use lspci to get that information.
>"lspci -xxxv" or "lspci -s 00:12.0 -xxxv" for just device 0x12
>
>Marc


Marc,
Well the steering bits are actually being set, and it does seem to work!  What threw me off (and I apologize for not testing this more) was the fact that with a normal kernel (2.6.20 plus PCI debugging), you get messages like this at bootup:

IRQ for 0000:00:15.0[A] -> PIRQ 02, mask 0800, excl 0000 -> newirq=11 ... failed
PCI: Guessed IRQ 11 for device 0000:00:15.0
natsemi eth0: NatSemi DP8381[56] at 0xfebf2000 (0000:00:15.0), 00:50:f6:22:91:4e, IRQ 11, port TP.

The "failed" messages concerned me.  However, in reality, the devices work, and you can verify that the interrupts are routed properly via /proc/interrupts.
With the same kernel, but patched to know the CS5530 IRQ router, you don't get the "failed" messages.

So since things work, I'm about ready to claim success.  Are the "failed" messages an acceptable artifact of the kernel not knowing the CS5530 router, or something I should be concerned about?

thanks,
Jonathan






      ____________________________________________________________________________________
Don't let your dream ride pass you by. Make it a reality with Yahoo! Autos.
http://autos.yahoo.com/index.html
 





From svn at openbios.org  Wed Oct  3 01:32:21 2007
From: svn at openbios.org (svn at openbios.org)
Date: Wed,  3 Oct 2007 01:32:21 +0200
Subject: [LinuxBIOS] r2818 - trunk/util/superiotool
Message-ID: <mailman.691.1355071171.16123.coreboot@coreboot.org>

Author: uwe
Date: 2007-10-03 01:32:21 +0200 (Wed, 03 Oct 2007)
New Revision: 2818

Modified:
   trunk/util/superiotool/superiotool.c
Log:
Print superiotool version when run with --verbose.

Signed-off-by: Robinson P. Tryon <bishop.robinson at gmail.com>
Acked-by: Uwe Hermann <uwe at hermann-uwe.de>



Modified: trunk/util/superiotool/superiotool.c
===================================================================
--- trunk/util/superiotool/superiotool.c	2007-10-02 15:49:25 UTC (rev 2817)
+++ trunk/util/superiotool/superiotool.c	2007-10-02 23:32:21 UTC (rev 2818)
@@ -169,10 +169,19 @@
 		       port, inb(port), inb(port + 1));
 }
 
+static void print_version(void)
+{
+	char tmp[80];
+
+	strncpy((char *)&tmp,
+		(const char *)&SUPERIOTOOL_VERSION[6],
+		strlen(SUPERIOTOOL_VERSION) - 8);
+	printf("superiotool r%s\n", (char *)&tmp);
+}
+
 int main(int argc, char *argv[])
 {
 	int i, j, opt, option_index;
-	char tmp[80];
 
 	const static struct option long_options[] = {
 		{"dump",		no_argument, NULL, 'd'},
@@ -193,13 +202,12 @@
 			dump_readable = 1;
 			break;
 		case 'V':
+			/* Print version in --verbose mode. */
+			print_version();
 			verbose = 1;
 			break;
 		case 'v':
-			strncpy((char *)&tmp,
-				(const char *)&SUPERIOTOOL_VERSION[6],
-				strlen(SUPERIOTOOL_VERSION) - 8);
-			printf("superiotool r%s\n", (char *)&tmp);
+			print_version();
 			exit(0);
 			break;
 		case 'h':




From uwe at hermann-uwe.de  Wed Oct  3 01:33:40 2007
From: uwe at hermann-uwe.de (Uwe Hermann)
Date: Wed, 3 Oct 2007 01:33:40 +0200
Subject: [LinuxBIOS] Call for help: superiotool
In-Reply-To: <a698c16a0710021226t4aa59cdahd99611f032e4bfde@mail.gmail.com>
References: <20070923111315.GC12926@greenwood>
	<a698c16a0709270921l860615dv3ebe8d49e2f4c791@mail.gmail.com>
	<46FBDB3E.4000009@gmx.net>
	<a698c16a0710012037l37bc9d07i6628563002d7e47a@mail.gmail.com>
	<470256CB.9060008@gmx.net>
	<a698c16a0710020844ud12485dhb063f76800170b63@mail.gmail.com>
	<470268D0.9050107@gmx.net>
	<a698c16a0710021134y55112a45r728d171e7926e94c@mail.gmail.com>
	<a698c16a0710021226t4aa59cdahd99611f032e4bfde@mail.gmail.com>
Message-ID: <20071002233339.GE17835@greenwood>

On Tue, Oct 02, 2007 at 03:26:20PM -0400, Robinson Tryon wrote:
> Signed-off-by: Robinson P. Tryon <bishop.robinson at gmail.com>

Thanks, committed in r2818 with some minor changes (no need to add the
prototype in superiotool.h as we only use the function in superiotool.c).


Uwe.
-- 
http://www.hermann-uwe.de  | http://www.holsham-traders.de
http://www.crazy-hacks.org | http://www.unmaintained-free-software.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20071003/55c4cbd3/attachment.sig>

From uwe at hermann-uwe.de  Wed Oct  3 01:43:18 2007
From: uwe at hermann-uwe.de (Uwe Hermann)
Date: Wed, 3 Oct 2007 01:43:18 +0200
Subject: [LinuxBIOS] A8N5X port
In-Reply-To: <13426df10709281105l1ba3add9ucf900626e2b5386a@mail.gmail.com>
References: <20070925201112.GA2222@thorin>
	<13426df10709251553m7848a7b5id505cf9c3bd1a478@mail.gmail.com>
	<20070926095052.GA12793@thorin> <20070927171408.GA31172@aragorn>
	<20070927202156.GE24724@thorin>
	<13426df10709271446m24363d2bu8e79d8215a64e073@mail.gmail.com>
	<20070928143846.GF7553@greenwood>
	<13426df10709281105l1ba3add9ucf900626e2b5386a@mail.gmail.com>
Message-ID: <20071002234318.GF17835@greenwood>

On Fri, Sep 28, 2007 at 11:05:29AM -0700, ron minnich wrote:
> OK, these mobos are close enough to each other to share most code. Let
> me throw out a challenge to this group. Make the bios image that runs
> on each board *IDENTICAL*. You can figure out what each board is --
> can you tell by which superio it is or something? -- and then case out
> in runtime.

Sounds possible, yes. And it's a great idea, FWIW. That's for another
patch, though, as it'll need much more work. Could someone please ack
this patch meanwhile (or comment on it)?

Not sure if we want to try runtime-detection in v2, but we should
definately plan for it in v3.

The detection is highly board-specific of course, no generic function
possible. And it has to happen very early (pre-RAM), as we have to
detect a different Super I/O early enough to be able to initialize
it (or at least the serial part).

Super I/O IDs are good and pretty reliable (it seems) _if_ the Super
I/Os (or at least their revisions) differ for each board. Otherwise
you have to find something else that differs (and can be probed pre-RAM).


> Why is this good? Because a vendor can see that with proper design, a
> single bios image can support many mainboards -- even if the hardware
> differs slightly -- thus reducing the cost.
> 
> We've talked about this for years, never done it. Is this the time?

Yep.


Uwe.
-- 
http://www.hermann-uwe.de  | http://www.holsham-traders.de
http://www.crazy-hacks.org | http://www.unmaintained-free-software.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20071003/2de5fb7f/attachment.sig>

From uwe at hermann-uwe.de  Wed Oct  3 01:45:21 2007
From: uwe at hermann-uwe.de (Uwe Hermann)
Date: Wed, 3 Oct 2007 01:45:21 +0200
Subject: [LinuxBIOS] A8N5X port
In-Reply-To: <20070928205145.GC30791@cosmic.amd.com>
References: <20070925201112.GA2222@thorin>
	<13426df10709251553m7848a7b5id505cf9c3bd1a478@mail.gmail.com>
	<20070926095052.GA12793@thorin> <20070927171408.GA31172@aragorn>
	<20070927202156.GE24724@thorin>
	<13426df10709271446m24363d2bu8e79d8215a64e073@mail.gmail.com>
	<20070928143846.GF7553@greenwood>
	<13426df10709281105l1ba3add9ucf900626e2b5386a@mail.gmail.com>
	<20070928205145.GC30791@cosmic.amd.com>
Message-ID: <20071002234521.GG17835@greenwood>

On Fri, Sep 28, 2007 at 02:51:45PM -0600, Jordan Crouse wrote:
> There is a tipping point there though - many people chose LinuxBIOS for
> the very reason that you don't carry around many Ks of code that you don't
> need.

Oh, in this case the differences are so minimal that the amount of
unneeded code is almost zero, I think.


> Even traditional BIOS vendors don't try this.  To me the more 
> important thing is to show that the hardware support is there, and that it
> is a simple build option away.

Sure.

 
> > Why is this good? Because a vendor can see that with proper design, a
> > single bios image can support many mainboards -- even if the hardware
> > differs slightly -- thus reducing the cost.
> 
> I just think you have to be very careful - run time detection is not
> what puts the butts in the seats.

Only as an option, of course. We don't want to do this per default for
all boards. But it's a nice option to have...


Uwe.
-- 
http://www.hermann-uwe.de  | http://www.holsham-traders.de
http://www.crazy-hacks.org | http://www.unmaintained-free-software.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20071003/1e6f1636/attachment.sig>

From alex at rtfs.hu  Wed Oct  3 01:48:38 2007
From: alex at rtfs.hu (Alex Beregszaszi)
Date: Wed, 03 Oct 2007 01:48:38 +0200
Subject: [LinuxBIOS] [PATCH] pci_rom.c checksum extension rom
In-Reply-To: <46FEC872.1000004@gmx.net>
References: <1188904675.17055.2.camel@localhost>
	<20070905022911.GA31013@coresystems.de>
	<1189162475.26302.55.camel@localhost>
	<1189625835.19904.6.camel@localhost> <46FEC872.1000004@gmx.net>
Message-ID: <1191368918.29835.17.camel@localhost>

On Sat, 2007-09-29 at 23:49 +0200, Carl-Daniel Hailfinger wrote:
> On 12.09.2007 21:37, Alex Beregszaszi wrote:
> > Hi,
> > 
> > On Fri, 2007-09-07 at 12:54 +0200, Alex Beregszaszi wrote:
> >> Hi,
> >>
> >> On Wed, 2007-09-05 at 04:29 +0200, Stefan Reinauer wrote:
> >>> * Alex Beregszaszi <alex at rtfs.hu> [070904 13:17]:
> >>>> Hi,
> >>>>
> >>>> the attached patch adds code to checksum the pci extension rom and stop
> >>>> if the stored and calculated checksum differ.
> >>> Is this checksum reliably correct? I am hesitating to add new
> >>> restrictions that might break otherwise working cards.
> >> You are right, attached is a correct method. There is no fixed checksum
> >> byte, instead the whole should sum to zero.
> > 
> > Any comments on this?
> 
> I like it. I'd give you an Ack, but I have no hardware to test with.
> 
> Stefan? Ron?
> 
> Worst case would be that buggy extension ROMs break with a really loud
> warning, so anybody with such ROMs will see it prominently in the logs.
> 
> Alex: Is there an easy way to check extension ROMs in the current
> machine for correct signatures? Maybe standalone utility or such stuff.

There is no utility for that, but you could copy out the memory between
0xc0000 - 0xf00000 from /dev/mem and search for extension headers in it
(see the code in pci_rom.c).

--
Alex





From alex at rtfs.hu  Wed Oct  3 01:50:33 2007
From: alex at rtfs.hu (Alex Beregszaszi)
Date: Wed, 03 Oct 2007 01:50:33 +0200
Subject: [LinuxBIOS] [PATCH] Support other than 0xC000 ROMs in VM86
In-Reply-To: <46FEC977.6040509@gmx.net>
References: <1188925040.17055.40.camel@localhost>
	<20070905014527.GB10233@coresystems.de>
	<1189009010.17055.107.camel@localhost>
	<1189625876.19904.8.camel@localhost> <46FEC977.6040509@gmx.net>
Message-ID: <1191369033.29835.19.camel@localhost>

On Sat, 2007-09-29 at 23:53 +0200, Carl-Daniel Hailfinger wrote:
> On 12.09.2007 21:37, Alex Beregszaszi wrote:
> > Hi,
> > 
> > On Wed, 2007-09-05 at 18:16 +0200, Alex Beregszaszi wrote:
> >> On Wed, 2007-09-05 at 03:45 +0200, Stefan Reinauer wrote:
> >>
> >>>> Also it changes the function to inline assembly and passes the arguments
> >>>> through that.
> >>>>
> >>>> This patch includes the changes from my previous patch "[PATCH] vgabios:
> >>>> use same interface for biosemu.c and vm86.c", but should be committed
> >>>> incrementally.
> >>> Can you please rediff against the current svn and send this patch again?
> >> Sure, attached.
> > 
> > I hope this is not forgotten.
> 
> Has this been committed?

Not yet, and now I have more patches regarding the BIOS emulation code.
Just my last week have been extremely busy and had no time to be active
on Linuxbios.

If you say ack, let me commit this, as I missed my last opportunity to
commit :)

--
Alex





From uwe at hermann-uwe.de  Wed Oct  3 01:54:50 2007
From: uwe at hermann-uwe.de (Uwe Hermann)
Date: Wed, 3 Oct 2007 01:54:50 +0200
Subject: [LinuxBIOS] FW:   440BX progress / superio w83977tf-aw
In-Reply-To: <BLU102-W432269A73B18A6665AEB408BAE0@phx.gbl>
References: <BLU102-W609EAA2C2EB0A2D789C9CD8BAE0@phx.gbl>
	<BLU102-W432269A73B18A6665AEB408BAE0@phx.gbl>
Message-ID: <20071002235450.GH17835@greenwood>

On Tue, Oct 02, 2007 at 01:21:23PM +0000, Idwer Vollering wrote:
> http://linuxbios.org/pipermail/linuxbios/2006-November/017262.html
> 
> It boots (v2 r2811), but serial outputs says 'Can not load ELF Image.' which is correct because i didn't yet manage to get filo appended as a payload from targets/asus/p2b/Config.lb.
> 
> What options in Config.lb must be set to create enough space to include filo.elf (about 94 KB) using both normal and fallback sections; option ROM_IMAGE_SIZE = (some_substracted_size) * 1024 ?

No changes needed in Config.lb, I suggest you simply make filo smaller
for now. Disable all unneeded options (ReiserFS, CDROM support, XFS
support, all debugging, etc). You only need very few of the options.
My filo.elf is 54KB, which is small enough for pretty much all boards.


> Also, superio (from r2811) won't recognize the onboard winbond w83977tf-aw.

It is (partly) recognized, otherwise you wouldn't get any serial output.

The Config.lb stuff below is only executed very late in the boot
process, but the serial console init (which needs the Super I/O) happens
earlier. As you have serial output, that code works ok.


> chip northbridge/intel/i440bx
>         device pci_domain 0 on
>                 device pci 0.0 on end # host bridge
>                 device pci 1.0 on end # pci bridge / agp device/bridge
>                         chip southbridge/intel/i82371eb # southbridge
>                                 device pci 4.0 on end # isa bridge
>                                         chip superio/winbond/w83977tf # superio, winbond w83977tf-aw
>                                                 device pci 4.1 on end # ide interface
>                                                 device pci 4.2 on end # usb controller
>                                                 device pci 4.3 on end # acpi bridge

This looks broken. The PCI devices should not be inside the Super I/O section.
Instead the superio-related stuff should be there. Have a look at some
other boards for examples. The output of 'lspnp -v' (from original BIOS,
and with all hardware attached, e.g. PS/2 keyboard, PS/2 mouse, etc)
should give you some hints (please also post it here).


I'll try to dig out my P2B tomorrow or so and see how far I get, and
maybe post some patch to improve it a bit. Please note that the 440BX
code is still not very generic, it'll probably not work for this board
(only the Tyan S1846 is confirmed to work so far). Fixing this is on
my (huge) TODO list.


Uwe.
-- 
http://www.hermann-uwe.de  | http://www.holsham-traders.de
http://www.crazy-hacks.org | http://www.unmaintained-free-software.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20071003/887358bf/attachment.sig>

From uwe at hermann-uwe.de  Wed Oct  3 01:59:40 2007
From: uwe at hermann-uwe.de (Uwe Hermann)
Date: Wed, 3 Oct 2007 01:59:40 +0200
Subject: [LinuxBIOS] hdama compile error
In-Reply-To: <4702C620.2050602@amd.com>
References: <DEE8917F-067D-4757-8BCE-746526351470@lanl.gov>
	<4702C620.2050602@amd.com>
Message-ID: <20071002235939.GI17835@greenwood>

On Tue, Oct 02, 2007 at 04:28:48PM -0600, Marc Jones wrote:
> I am no expert, but it looks like this platform is still using ROMCC and 
> needs to be ported to CAR.

Yes.

 
> Question to others: Shouldn't the abuild be catching this?

Yes, and it does:

Compilation of arima:hdama is still broken
See the error log at
http://qa.linuxbios.org/log_buildbrd.php?revision=2817&device=hdama&vendor=arima


Long-term solution: someone rewrites the code to use CAR.

Short-term: remove some debugging code until romcc no longer complains
            (trial-and-error) or checkout an older version (I think it
            built fine a while ago).


Uwe.
-- 
http://www.hermann-uwe.de  | http://www.holsham-traders.de
http://www.crazy-hacks.org | http://www.unmaintained-free-software.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20071003/80e1472d/attachment.sig>

From uwe at hermann-uwe.de  Wed Oct  3 02:02:26 2007
From: uwe at hermann-uwe.de (Uwe Hermann)
Date: Wed, 3 Oct 2007 02:02:26 +0200
Subject: [LinuxBIOS] [FLASHROM] Fix the help,
	and print a message when	nothing happens
In-Reply-To: <20071002175346.GC27248@cosmic.amd.com>
References: <20071002175346.GC27248@cosmic.amd.com>
Message-ID: <20071003000225.GJ17835@greenwood>

On Tue, Oct 02, 2007 at 11:53:46AM -0600, Jordan Crouse wrote:
> I have used flashrom just little enough to forget that -w isn't implied,
> and wonder why nothing happened.  This fixes the help, and says something
> at the end of no operations are specified.  Just a little user-friendliness
> from your good friends at LinuxBIOS.

Yep, good patch. I had some people asking me why flashrom doesn't work
and they had the same problem.


> Index: flashrom/flashrom.c
> ===================================================================
> --- flashrom.orig/flashrom.c	2007-10-02 11:43:38.000000000 -0600
> +++ flashrom/flashrom.c	2007-10-02 11:45:51.000000000 -0600
> @@ -195,8 +195,7 @@
>  	printf("       [-e exclude_end] [-m vendor:part] [-l file.layout] [-i imagename] [file]\n");
>  	printf
>  	    ("   -r | --read:                    read flash and save into file\n"
> -	     "   -w | --write:                   write file into flash (default when\n"
> -	     "                                   file is specified)\n"
> +	     "   -w | --write:                   write file into flash\n"
>  	     "   -v | --verify:                  verify flash against file\n"
>  	     "   -E | --erase:                   erase flash device\n"
>  	     "   -V | --verbose:                 more verbose output\n"
> @@ -456,5 +455,9 @@
>  	if (verify_it)
>  		ret |= verify_flash(flash, buf);
>  
> +	if (!(read_it|write_it|verify_it|erase_it)) {
                     ^        ^         ^
      spaces between the entries, as per coding guidelines


> +		printf("No operations were specified.\n");
> +	}
> +
>  	return ret;
>  }

Otherwise:
Acked-by: Uwe Hermann <uwe at hermann-uwe.de>


Uwe.
-- 
http://www.hermann-uwe.de  | http://www.holsham-traders.de
http://www.crazy-hacks.org | http://www.unmaintained-free-software.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20071003/4c6c7f84/attachment.sig>

From uwe at hermann-uwe.de  Wed Oct  3 02:05:39 2007
From: uwe at hermann-uwe.de (Uwe Hermann)
Date: Wed, 3 Oct 2007 02:05:39 +0200
Subject: [LinuxBIOS] LB-v2 version for A8NE-FM
In-Reply-To: <451790.22865.qm@web51607.mail.re2.yahoo.com>
References: <mailman.688.1191284493.4548.linuxbios@linuxbios.org>
	<451790.22865.qm@web51607.mail.re2.yahoo.com>
Message-ID: <20071003000538.GK17835@greenwood>

On Mon, Oct 01, 2007 at 06:23:01PM -0700, Baski wrote:
> What's a good version of LBv2 to flash on A8NE-FM?

No code is committed so far, but you can try my patch from
http://www.linuxbios.org/pipermail/linuxbios/2007-July/023029.html

As usual, make sure you have a means of backup (extra ROM chip with
the original BIOS, for example).


Uwe.
-- 
http://www.hermann-uwe.de  | http://www.holsham-traders.de
http://www.crazy-hacks.org | http://www.unmaintained-free-software.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20071003/981413e4/attachment.sig>

From uwe at hermann-uwe.de  Wed Oct  3 02:10:27 2007
From: uwe at hermann-uwe.de (Uwe Hermann)
Date: Wed, 3 Oct 2007 02:10:27 +0200
Subject: [LinuxBIOS] [BUILDROM] Remove bitrotten OLPC support
In-Reply-To: <20071002200926.GE27248@cosmic.amd.com>
References: <20071002200926.GE27248@cosmic.amd.com>
Message-ID: <20071003001026.GL17835@greenwood>

On Tue, Oct 02, 2007 at 02:09:26PM -0600, Jordan Crouse wrote:
> Okay, this patch will probably make Ron cry, but in the end, I think
> its better for the health of buildrom and the project (the patch, not
> Ron crying).
> 
> The OLPC code we had in here before was for revision B2 and earlier, 
> which will never see the light of day to the public, and only myself,
> Ron and Segher have even seen them, let alone used them (and
> I'm not even sure if my B2 works).
> 
> Even if we were to revive LinuxBIOS for the B3 for the upcoming G1G1
> effort, the existing code would be too bitrotten and too old to be of
> any use.    The only use we had for it was as a decent example of how
> to do LAB, but Ward has upped the stakes with his LAB code that is way
> better, and if we have our way, eventually all the LAB code will go away
> in favor of something like buildroot.  And finally, the OLPC buildrom
> code that last worked for B2 is still active over at dev.laptop.org, so
> the code will be accessible if need be.
> 
> So, with all that said, I am proposing this patch to remove OLPC support
> completely from buildrom, except for OFW, which I will discuss in the next
> patch.  Flame on!

Call it a flame if you want, but:

Acked-by: Uwe Hermann <uwe at hermann-uwe.de>


If somebody needs some of this later (for reference or whatever), it's
still in the repository...

Note: I have not tested the patch, I assume you tested it and it didn't
break random other stuff?


Uwe.
-- 
http://www.hermann-uwe.de  | http://www.holsham-traders.de
http://www.crazy-hacks.org | http://www.unmaintained-free-software.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20071003/e9f915ac/attachment.sig>

From uwe at hermann-uwe.de  Wed Oct  3 02:10:45 2007
From: uwe at hermann-uwe.de (Uwe Hermann)
Date: Wed, 3 Oct 2007 02:10:45 +0200
Subject: [LinuxBIOS] [BUILDROM]:  Disable OFW
In-Reply-To: <20071002201317.GF27248@cosmic.amd.com>
References: <20071002201317.GF27248@cosmic.amd.com>
Message-ID: <20071003001045.GM17835@greenwood>

On Tue, Oct 02, 2007 at 02:13:17PM -0600, Jordan Crouse wrote:
> [BUILDROM]:  Disable OFW
> 
> Since OFW in buildrom was only for OLPC, not having OLPC means that OFW
> isn't useful right now - hopefully somebody can do do the work to make
> OFW or a clone useful for generic x86 platforms.
> 
> Signed-off-by: Jordan Crouse <jordan.crouse at amd.com>

Acked-by: Uwe Hermann <uwe at hermann-uwe.de>


Uwe.
-- 
http://www.hermann-uwe.de  | http://www.holsham-traders.de
http://www.crazy-hacks.org | http://www.unmaintained-free-software.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20071003/89644440/attachment.sig>

From info at coresystems.de  Wed Oct  3 02:20:08 2007
From: info at coresystems.de (LinuxBIOS information)
Date: Wed, 03 Oct 2007 02:20:08 +0200
Subject: [LinuxBIOS] r2818 build service
Message-ID: <E1IcryC-0000Cp-M5@khepri.openbios.org>

Dear LinuxBIOS readers!

This is the automated build check service of LinuxBIOS.

The developer "uwe" checked in revision 2818 to
the LinuxBIOS source repository and caused the following 
changes:

Change Log:
Print superiotool version when run with --verbose.

Signed-off-by: Robinson P. Tryon <bishop.robinson at gmail.com>
Acked-by: Uwe Hermann <uwe at hermann-uwe.de>



Build Log:
Compilation of arima:hdama is still broken
See the error log at http://qa.linuxbios.org/log_buildbrd.php?revision=2818&device=hdama&vendor=arima
Compilation of ibm:e325 is still broken
See the error log at http://qa.linuxbios.org/log_buildbrd.php?revision=2818&device=e325&vendor=ibm
Compilation of ibm:e326 is still broken
See the error log at http://qa.linuxbios.org/log_buildbrd.php?revision=2818&device=e326&vendor=ibm
Compilation of iei:juki-511p is still broken
See the error log at http://qa.linuxbios.org/log_buildbrd.php?revision=2818&device=juki-511p&vendor=iei
Compilation of iwill:dk8s2 is still broken
See the error log at http://qa.linuxbios.org/log_buildbrd.php?revision=2818&device=dk8s2&vendor=iwill
Compilation of iwill:dk8x is still broken
See the error log at http://qa.linuxbios.org/log_buildbrd.php?revision=2818&device=dk8x&vendor=iwill
Compilation of newisys:khepri is still broken
See the error log at http://qa.linuxbios.org/log_buildbrd.php?revision=2818&device=khepri&vendor=newisys


If something broke during this checkin please be a pain 
in uwe's neck until the issue is fixed.

If this issue is not fixed within 24h the revision should 
be backed out.

   Best regards,
     LinuxBIOS automatic build system





From jordan.crouse at amd.com  Wed Oct  3 02:56:22 2007
From: jordan.crouse at amd.com (Jordan Crouse)
Date: Tue, 2 Oct 2007 18:56:22 -0600
Subject: [LinuxBIOS] Remove bitrotten OLPC support
In-Reply-To: <20071003001026.GL17835@greenwood>
References: <20071002200926.GE27248@cosmic.amd.com>
	<20071003001026.GL17835@greenwood>
Message-ID: <20071003005622.GA32474@cosmic.amd.com>

On 03/10/07 02:10 +0200, Uwe Hermann wrote:
> If somebody needs some of this later (for reference or whatever), it's
> still in the repository...
> 
> Note: I have not tested the patch, I assume you tested it and it didn't
> break random other stuff?

Norwich built.  I didn't try to get much more random then that.. :)

Jordan





From peter at stuge.se  Wed Oct  3 03:30:18 2007
From: peter at stuge.se (Peter Stuge)
Date: Wed, 3 Oct 2007 03:30:18 +0200
Subject: [LinuxBIOS] 440BX progress / superio w83977tf-aw
In-Reply-To: <BLU102-W1142FAFAADAABA86DB06C78BAE0@phx.gbl>
References: <BLU102-W1142FAFAADAABA86DB06C78BAE0@phx.gbl>
Message-ID: <20071003013018.29961.qmail@stuge.se>

On Tue, Oct 02, 2007 at 01:07:00PM +0000, Idwer Vollering wrote:
> What options in Config.lb must be set to create enough space to
> include filo.elf (about 94 KB) using both normal and fallback
> sections; option ROM_IMAGE_SIZE = (some_substracted_size) * 1024 ?

How large is your flash chip? 512kb would be good.


//Peter



From uwe at hermann-uwe.de  Wed Oct  3 04:40:31 2007
From: uwe at hermann-uwe.de (Uwe Hermann)
Date: Wed, 3 Oct 2007 04:40:31 +0200
Subject: [LinuxBIOS] Call for help: superiotool
In-Reply-To: <a698c16a0710012034i25dec2deq1a07b8eb570f3d97@mail.gmail.com>
References: <20070923111315.GC12926@greenwood>
	<a698c16a0709270921l860615dv3ebe8d49e2f4c791@mail.gmail.com>
	<46FBDB3E.4000009@gmx.net>
	<a698c16a0710012034i25dec2deq1a07b8eb570f3d97@mail.gmail.com>
Message-ID: <20071003024031.GC6851@greenwood>

On Mon, Oct 01, 2007 at 11:34:05PM -0400, Robinson Tryon wrote:
> System Information
>         Manufacturer: Dell Computer Corporation
>         Product Name: OptiPlex GX1 400MTbr+
> 
> # ./superiotool -v
> superiotool r2815?2@
> # ./superiotool -V
> Probing for ALi Super I/O at 0x3f0... failed
> Probing for ALi Super I/O at 0x370... failed
> Super I/O found at 0x2e: id = 0xe0
> <unknown>
> No dump for 0xe0

This _might_ be the NSC PC87309 chip. No support yet,
but the NSC code needs a rewrite to make it more generic anyway.

Can you look at the mainboard and find out which chip it actually is?


Uwe.
-- 
http://www.hermann-uwe.de  | http://www.holsham-traders.de
http://www.crazy-hacks.org | http://www.unmaintained-free-software.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20071003/00d5d5d5/attachment.sig>

From uwe at hermann-uwe.de  Wed Oct  3 04:42:16 2007
From: uwe at hermann-uwe.de (Uwe Hermann)
Date: Wed, 3 Oct 2007 04:42:16 +0200
Subject: [LinuxBIOS] Call for help: superiotool
In-Reply-To: <470268D0.9050107@gmx.net>
References: <20070923111315.GC12926@greenwood>
	<a698c16a0709270921l860615dv3ebe8d49e2f4c791@mail.gmail.com>
	<46FBDB3E.4000009@gmx.net>
	<a698c16a0710012037l37bc9d07i6628563002d7e47a@mail.gmail.com>
	<470256CB.9060008@gmx.net>
	<a698c16a0710020844ud12485dhb063f76800170b63@mail.gmail.com>
	<470268D0.9050107@gmx.net>
Message-ID: <20071003024216.GD6851@greenwood>

On Tue, Oct 02, 2007 at 05:50:40PM +0200, Carl-Daniel Hailfinger wrote:
> >>> System Information
> >>>         Manufacturer: TOSHIBA
> >>>         Product Name: Satellite 1415
> >>>         Version: PS141U-1ZCF4V
> >>>
> >>> $ sudo ./superiotool -v
> >>> superiotool r2815
> >>> $ sudo ./superiotool -V
> >>> Probing for ALi Super I/O at 0x3f0... failed
> >>> Probing for ALi Super I/O at 0x370... failed
> >>> Probing for NSC Super I/O at 0x2e... failed
> >>> Probing for NSC Super I/O at 0x4e... failed
> >>> Probing for Fintek Super I/O at 0x2e... failed
> >>> Probing for Fintek Super I/O at 0x4e... failed
> >>> Probing 0x2e, failed (0x22), data returns 0x04
> >>> Probing 0x2e, failed (0x22), data returns 0x04
> >>> Probing for ITE Super I/O (init=0x87,0x01,0x55,0x55/0xaa) at 0x4e... failed
> >>> Probing for ITE Super I/O (init=0x87,0x87) at 0x4e... failed
> >>> Probing 0x2e, failed (0x21), data returns 0x00
> >>> Probing 0x2e, failed (0x0e), data returns 0x00
> >>> Probing for SMSC Super I/O at 0x4e... failed
> >>> Probing for SMSC Super I/O at 0x4e... failed
> >>> Probing for SMSC Super I/O at 0x3f0... failed
> >>> Probing for SMSC Super I/O at 0x3f0... failed
> >>> Probing for SMSC Super I/O at 0x370... failed
> >>> Probing for SMSC Super I/O at 0x370... failed
> >>> Probing for Winbond Super I/O (init=0x88) at 0x2e... failed
> >>> Probing for Winbond Super I/O (init=0x89) at 0x2e... failed
> >>> Probing for Winbond Super I/O (init=0x86,0x86) at 0x2e... failed
> >>> Probing for Winbond Super I/O (init=0x87,0x87) at 0x2e... failed
> >>> Probing for Winbond Super I/O (init=0x88) at 0x4e... failed
> >>> Probing for Winbond Super I/O (init=0x89) at 0x4e... failed
> >>> Probing for Winbond Super I/O (init=0x86,0x86) at 0x4e... failed
> >>> Probing for Winbond Super I/O (init=0x87,0x87) at 0x4e... failed
> >>> Probing for Winbond Super I/O (init=0x88) at 0x3f0... failed
> >>> Probing for Winbond Super I/O (init=0x89) at 0x3f0... failed
> >>> Probing for Winbond Super I/O (init=0x86,0x86) at 0x3f0... failed
> >>> Probing for Winbond Super I/O (init=0x87,0x87) at 0x3f0... failed
> >>> Probing for Winbond Super I/O (init=0x88) at 0x370... failed
> >>> Probing for Winbond Super I/O (init=0x89) at 0x370... failed
> >>> Probing for Winbond Super I/O (init=0x86,0x86) at 0x370... failed
> >>> Probing for Winbond Super I/O (init=0x87,0x87) at 0x370... failed
> >>> Probing for Winbond Super I/O (init=0x88) at 0x250... failed
> >>> Probing for Winbond Super I/O (init=0x89) at 0x250... failed
> >>> Probing for Winbond Super I/O (init=0x86,0x86) at 0x250... failed
> >>> Probing for Winbond Super I/O (init=0x87,0x87) at 0x250... failed
> >> Your superiotool version seems broken. Probably one of Uwe's "trivial"
> >> patches.
> > 
> > Hmm... is it possible that the Satellite 1415 doesn't have a Super I/O ?
> 
> Probably the Super I/O is inside the embedded controller and responds to
> a special probe sequence.
> 
> However, the probing sequence is incomplete (at least when judging it by
> its output) and Uwe rewrote the probing sequence, so he can take a look
> at it.

Will do. What do you mean with incomplete?
The --verbose output needs some more fixing to make it more informative, IMO. 


Uwe.
-- 
http://www.hermann-uwe.de  | http://www.holsham-traders.de
http://www.crazy-hacks.org | http://www.unmaintained-free-software.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20071003/2788e3c8/attachment.sig>

From uwe at hermann-uwe.de  Wed Oct  3 05:21:41 2007
From: uwe at hermann-uwe.de (Uwe Hermann)
Date: Wed, 3 Oct 2007 05:21:41 +0200
Subject: [LinuxBIOS] Call for help: superiotool
In-Reply-To: <20070923111315.GC12926@greenwood>
References: <20070923111315.GC12926@greenwood>
	<a698c16a0709280901l1b5b94a3t6007464f669229a7@mail.gmail.com>
Message-ID: <20071003032141.GE6851@greenwood>

[Please always reply to the list]

On Fri, Sep 28, 2007 at 12:01:09PM -0400, Robinson Tryon wrote:
> On 9/23/07, Uwe Hermann <uwe at hermann-uwe.de> wrote:
> >
> >    Supporting new ones is relatively easy, but a bit time-consuming.
> >    You have to grab the datasheet, find out the ID/version of the
> >    Super I/O and add it in the respective file (ite.c for ITE Super I/Os,
> >    for example). For the dump functionality you have to add a (large) table
> >    with all registers and their defaults.
> 
> I went through with the 8726F and saw how the register table in ite.c
> matched up with the datasheet, but I couldn't find the ID/Version
> number mentioned anywhere in the datasheet.  For ITE chips it looks
> like the ID generally matches up with the name of the chip, but I
> figure that it would be best if I could actually look up that
> information in the datasheet -- especially if other chips don't follow
> this convention.

Yes, you should definately look up the ID. Many other chips/vendors use
various different IDs of various sizes and in various locations.


> What's the best way for me to search through a datasheet to find the ID/Version?

There's no general rule, but look for something like "chip id" or "chip
revision" or similar. Usually this information (together with the
required init sequence and ports) is somewhere near the
"Global Configuration Registers" or "PNP configuration" or similar
chapter.


HTH, Uwe.
-- 
http://www.hermann-uwe.de  | http://www.holsham-traders.de
http://www.crazy-hacks.org | http://www.unmaintained-free-software.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20071003/a7ea87ba/attachment.sig>

From yinghailu at gmail.com  Wed Oct  3 06:52:07 2007
From: yinghailu at gmail.com (yhlu)
Date: Tue, 2 Oct 2007 21:52:07 -0700
Subject: [LinuxBIOS] hdama compile error
In-Reply-To: <20071002235939.GI17835@greenwood>
References: <DEE8917F-067D-4757-8BCE-746526351470@lanl.gov>
	<4702C620.2050602@amd.com> <20071002235939.GI17835@greenwood>
Message-ID: <2ea3fae10710022152x3b289e65t2c6bb5b656f0fde7@mail.gmail.com>

can you move new one to incoherent_ht_car.c, and leave the old one to
incoherent_ht.c

or

copy old one to incoherent_ht_romcc.c
some broken MB need to updated...

Kevin,
what is the Opteron rev? is it B3 or Rev E...
You may have problem with B3 and Cache_as_RAM

YH



From my_tsai at sis.com  Wed Oct  3 09:15:30 2007
From: my_tsai at sis.com (Morgan Tsai)
Date: Wed, 3 Oct 2007 15:15:30 +0800
Subject: [LinuxBIOS] [IMPORT] GIGABYTE GA-2761GXDK
Message-ID: <006b01c8058d$38dc52f0$0200a8c0@sis.com.tw>

Copyright (C) 2007 Morgan Tsai <my_tsai at sis.com>
Copyright (C) 2007 Silicon Integrated Systems Corp. (SiS)

Change Log:

Newly support GIGABYTE GA-2761GXDK
CPU type: AMD AM2 socket
Northbridge: SiS 761GX
Southbridge: SiS 966
SuperIO: ITE8716F

The board is still under testing sample. When we finish test without major 
problems, this sample will soon become marketing board.


Signed-off-by: Morgan Tsai <my_tsai at sis.com> 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: LinuxBIOSv2-churchill.tar.bz2
Type: application/octet-stream
Size: 154310 bytes
Desc: not available
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20071003/acb06980/attachment.obj>

From lemenkov at gmail.com  Wed Oct  3 11:59:06 2007
From: lemenkov at gmail.com (Peter Lemenkov)
Date: Wed, 3 Oct 2007 13:59:06 +0400
Subject: [LinuxBIOS] Fwd: [Bug 315351] Review Request: superiotool
Message-ID: <adf480660710030259j65935cb3wfe5a5de6228bbc31@mail.gmail.com>

Hello All!
Just FYI I've just created a review request for adding superiotool
into Fedora distribution and derived distributives.

Still I've got only one request (see quoted text below):

======================================

---------- Forwarded message ----------
From: bugzilla at redhat.com <bugzilla at redhat.com>
Date: 03.10.2007 13:19
Subject: [Bug 315351] Review Request: superiotool - Simple program for
detecting Super I/O on your mainboard
To: lemenkov at gmail.com

[sorry, skipped]

3) SHOULD: If the source package does not include license text(s) as a separate
file from upstream, the packager SHOULD query upstream to include it.

======================================

So I just forwarded it to you - please add LICENSE file into SVN.

-- 
With best regards!



From kevint at lanl.gov  Wed Oct  3 17:26:19 2007
From: kevint at lanl.gov (kevint)
Date: Wed, 3 Oct 2007 09:26:19 -0600
Subject: [LinuxBIOS] hdama compile error
In-Reply-To: <2ea3fae10710022152x3b289e65t2c6bb5b656f0fde7@mail.gmail.com>
References: <DEE8917F-067D-4757-8BCE-746526351470@lanl.gov>
	<4702C620.2050602@amd.com> <20071002235939.GI17835@greenwood>
	<2ea3fae10710022152x3b289e65t2c6bb5b656f0fde7@mail.gmail.com>
Message-ID: <D45EE380-F4A2-4225-8489-F08232A09B53@lanl.gov>

My initial guess is that we have deployed both revisions, and that we  
will need both to work.  I am verifying with our hardware people.

On Oct 2, 2007, at 10:52 PM, yhlu wrote:

>  is it B3 or Rev E

********************************************
Kevin Tegtmeier
HPC-3 Scientific Computing Resources
Los Alamos National Laboratory
email:  kevint at lanl.gov
phone: 505.667.3488
********************************************



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20071003/dbe9a620/attachment.html>

From rminnich at gmail.com  Wed Oct  3 17:50:50 2007
From: rminnich at gmail.com (ron minnich)
Date: Wed, 3 Oct 2007 08:50:50 -0700
Subject: [LinuxBIOS] Remove bitrotten OLPC support
In-Reply-To: <20071003005622.GA32474@cosmic.amd.com>
References: <20071002200926.GE27248@cosmic.amd.com>
	<20071003001026.GL17835@greenwood>
	<20071003005622.GA32474@cosmic.amd.com>
Message-ID: <13426df10710030850q7283b7e4y22e3f1c65ebdd4fd@mail.gmail.com>

totally-acked-by: Ronald G. Minnich <rminnich at gmail.com>

I've been thinking along the same lines. I still think LAB is the way
to go, and I'm very happy to see all the great work Ward has done. I
was going to try to close the loop once my home workshop is done (I
just moved) and try it once again on my old OLPC units.

But the existing OLPC stuff is indeed bit-rotten.

ron



From rminnich at gmail.com  Wed Oct  3 18:16:32 2007
From: rminnich at gmail.com (ron minnich)
Date: Wed, 3 Oct 2007 09:16:32 -0700
Subject: [LinuxBIOS] hdama compile error
In-Reply-To: <DEE8917F-067D-4757-8BCE-746526351470@lanl.gov>
References: <DEE8917F-067D-4757-8BCE-746526351470@lanl.gov>
Message-ID: <13426df10710030916r72359e2ame958f083c52e0967@mail.gmail.com>

I think a new mainboard target for SATA is safer. They may have
rewired IRQs as well.

My first reaction before I saw LANL was "wow, who has hdama any
more?". Then I remembered :-)

ron



From yinghailu at gmail.com  Wed Oct  3 18:26:51 2007
From: yinghailu at gmail.com (yhlu)
Date: Wed, 3 Oct 2007 09:26:51 -0700
Subject: [LinuxBIOS] hdama compile error
In-Reply-To: <13426df10710030916r72359e2ame958f083c52e0967@mail.gmail.com>
References: <DEE8917F-067D-4757-8BCE-746526351470@lanl.gov>
	<13426df10710030916r72359e2ame958f083c52e0967@mail.gmail.com>
Message-ID: <2ea3fae10710030926s55340f1dmc86a3cbbdcf30ddb@mail.gmail.com>

http://www.arima.com.tw/ViewProduct.asp?View=150

that laptop from arima have ck804 chipset...

YH



From russ at ashlandhome.net  Wed Oct  3 18:38:49 2007
From: russ at ashlandhome.net (Russell Whitaker)
Date: Wed, 3 Oct 2007 09:38:49 -0700 (PDT)
Subject: [LinuxBIOS] [IMPORT] GIGABYTE GA-2761GXDK
In-Reply-To: <006b01c8058d$38dc52f0$0200a8c0@sis.com.tw>
References: <006b01c8058d$38dc52f0$0200a8c0@sis.com.tw>
Message-ID: <Pine.LNX.4.64.0710030928160.3653@bigred.russwhit.org>



On Wed, 3 Oct 2007, Morgan Tsai wrote:

> Copyright (C) 2007 Morgan Tsai <my_tsai at sis.com>
> Copyright (C) 2007 Silicon Integrated Systems Corp. (SiS)
>

Also, your email of Sept 21 has same copyright notice.

I believe contributions to the Linuxbios project should be
released under the GPL.

Not trying to start a flame war. Just trying to prevent
problems that might occur later.

   Russ



From marc.jones at amd.com  Wed Oct  3 18:46:04 2007
From: marc.jones at amd.com (Marc Jones)
Date: Wed, 03 Oct 2007 10:46:04 -0600
Subject: [LinuxBIOS] Two more CS5530 IRQ steering questions
In-Reply-To: <735999.11669.qm@web35906.mail.mud.yahoo.com>
References: <735999.11669.qm@web35906.mail.mud.yahoo.com>
Message-ID: <4703C74C.6060603@amd.com>



Jonathan Sturges wrote:
>> Jonathan,
>>
>> You can use lspci to get that information.
>> "lspci -xxxv" or "lspci -s 00:12.0 -xxxv" for just device 0x12
>>
>> Marc
> 
> 
> Marc,
> Well the steering bits are actually being set, and it does seem to work!  What threw me off (and I apologize for not testing this more) was the fact that with a normal kernel (2.6.20 plus PCI debugging), you get messages like this at bootup:
> 
> IRQ for 0000:00:15.0[A] -> PIRQ 02, mask 0800, excl 0000 -> newirq=11 ... failed
> PCI: Guessed IRQ 11 for device 0000:00:15.0
> natsemi eth0: NatSemi DP8381[56] at 0xfebf2000 (0000:00:15.0), 00:50:f6:22:91:4e, IRQ 11, port TP.
> 
> The "failed" messages concerned me.  However, in reality, the devices work, and you can verify that the interrupts are routed properly via /proc/interrupts.
> With the same kernel, but patched to know the CS5530 IRQ router, you don't get the "failed" messages.
> 
> So since things work, I'm about ready to claim success.  Are the "failed" messages an acceptable artifact of the kernel not knowing the CS5530 router, or something I should be concerned about?
> 
> thanks,
> Jonathan


Glad it worked. I don't know enough about the kernel to know if the 
failed message is important. It seems to have a fallback mechanism. I 
also haven't followed the 5530 kernel patch debate. Maybe someone else 
here has the knowledge?

Marc


-- 
Marc Jones
Senior Firmware Engineer
(970) 226-9684 Office
mailto:Marc.Jones at amd.com
http://www.amd.com/embeddedprocessors





From rminnich at gmail.com  Wed Oct  3 19:42:33 2007
From: rminnich at gmail.com (ron minnich)
Date: Wed, 3 Oct 2007 10:42:33 -0700
Subject: [LinuxBIOS] changes to v3 config breaks CONFIG_NOELF?
Message-ID: <13426df10710031042i79e30fd0s471843e1a33683bf@mail.gmail.com>

I am setting NOELF when I run make menuconfig.

But in the config I see:
#
# Payload
#
CONFIG_PAYLOAD_ELF=y
# CONFIG_PAYLOAD_NONE is not set
CONFIG_PAYLOAD_FILE="../filo.elf"


Which is wrong. Anybody know what changed?

ron
p.s. my problem on qemu is that the bss segment is not being zero,
apparently. Still looking.



From rminnich at gmail.com  Wed Oct  3 20:20:35 2007
From: rminnich at gmail.com (ron minnich)
Date: Wed, 3 Oct 2007 11:20:35 -0700
Subject: [LinuxBIOS] patch: fix Kconfig for elf preparsing
Message-ID: <13426df10710031120r21935601t88a2140183fa9d8d@mail.gmail.com>

This repairs the problem I found.

ron
-------------- next part --------------
A non-text attachment was scrubbed...
Name: noelf.diff
Type: text/x-patch
Size: 3356 bytes
Desc: not available
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20071003/4f3568de/attachment.diff>

From rminnich at gmail.com  Wed Oct  3 20:23:45 2007
From: rminnich at gmail.com (ron minnich)
Date: Wed, 3 Oct 2007 11:23:45 -0700
Subject: [LinuxBIOS] patch: fix filo dependency on memory being zero
Message-ID: <13426df10710031123t406504bxdfa9b45e4ad7194b@mail.gmail.com>

This patch makes qemu work again on v3. FILO was depending on bss
being zero, which is not all that safe in embedded. It's better to
zero things you are depending on being zero.

ron



From jtmettala at gmail.com  Wed Oct  3 20:49:26 2007
From: jtmettala at gmail.com (=?UTF-8?Q?Jouni_Mett=C3=A4l=C3=A4?=)
Date: Wed, 3 Oct 2007 21:49:26 +0300
Subject: [LinuxBIOS] MSI MS-6337 (i815 based)
Message-ID: <63e824e50710031149m169e5543t17f2d58695dc3f99@mail.gmail.com>

> Do you have a second computer and a null modem serial cable? If so,
> please hook it up and see what's coming out of the serial port (I hope
> you have the same super io).

I tried with friend laptop. It didn't give anything. Maybe I just can't use
serial cable and minicom :( I hope better debug next time. Superio  is
w83627hf in both mainboards (ms-6178 and ms-6337)

> Did you get it _that_ small? I'm using a 512KB chip, you cannot stick a
> kernel into that. Did you use a bigger chip?

Kernel config (I am no sure if it's the same but it is small) is minimal. It
boots with proprietary bios and it is just for testing. I had no success
with filo either. It is used with ubuntu dapper sources. I'll try to attach
it this week.

00:00.0 Host bridge [0600]: Intel Corporation 82815 815 Chipset Host Bridge
and Memory Controller Hub [8086:1130] (rev 02)
00:02.0 VGA compatible controller [0300]: Intel Corporation 82815 Chipset
Graphics Controller (CGC) [8086:1132] (rev 02)
00:1e.0 PCI bridge [0604]: Intel Corporation 82801 PCI Bridge [8086:244e]
(rev 01)
00:1f.0 ISA bridge [0601]: Intel Corporation 82801BA ISA Bridge (LPC)
[8086:2440] (rev 01)
00:1f.1 IDE interface [0101]: Intel Corporation 82801BA IDE U100 Controller
[8086:244b] (rev 01)
00:1f.2 USB Controller [0c03]: Intel Corporation 82801BA/BAM USB Controller
#1 [8086:2442] (rev 01)
00:1f.3 SMBus [0c05]: Intel Corporation 82801BA/BAM SMBus Controller
[8086:2443] (rev 01)
00:1f.4 USB Controller [0c03]: Intel Corporation 82801BA/BAM USB Controller
#1 [8086:2444] (rev 01)
00:1f.5 Multimedia audio controller [0401]: Intel Corporation 82801BA/BAM
AC'97 Audio Controller [8086:2445] (rev 01)
01:00.0 Multimedia audio controller [0401]: Ensoniq ES1371 [AudioPCI-97]
[1274:1371] (rev 08)
01:02.0 Ethernet controller [0200]: Advanced Micro Devices [AMD] 79c978
[HomePNA] [1022:2001] (rev 52)

Last two are pci cards. Not necessary just now.

lspnp: /proc/bus/pnp not available
might help if I change some settings of proprietary bios.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20071003/5ce33b63/attachment.html>

From svn at openbios.org  Wed Oct  3 20:56:52 2007
From: svn at openbios.org (svn at openbios.org)
Date: Wed,  3 Oct 2007 20:56:52 +0200
Subject: [LinuxBIOS] r2819 - trunk/util/superiotool
Message-ID: <mailman.692.1355071171.16123.coreboot@coreboot.org>

Author: uwe
Date: 2007-10-03 20:56:51 +0200 (Wed, 03 Oct 2007)
New Revision: 2819

Added:
   trunk/util/superiotool/COPYING
Log:
Add a copy of the GPL (trivial).

Signed-off-by: Uwe Hermann <uwe at hermann-uwe.de>
Acked-by: Uwe Hermann <uwe at hermann-uwe.de>



Added: trunk/util/superiotool/COPYING
===================================================================
--- trunk/util/superiotool/COPYING	                        (rev 0)
+++ trunk/util/superiotool/COPYING	2007-10-03 18:56:51 UTC (rev 2819)
@@ -0,0 +1,339 @@
+		    GNU GENERAL PUBLIC LICENSE
+		       Version 2, June 1991
+
+ Copyright (C) 1989, 1991 Free Software Foundation, Inc.,
+ 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA
+ Everyone is permitted to copy and distribute verbatim copies
+ of this license document, but changing it is not allowed.
+
+			    Preamble
+
+  The licenses for most software are designed to take away your
+freedom to share and change it.  By contrast, the GNU General Public
+License is intended to guarantee your freedom to share and change free
+software--to make sure the software is free for all its users.  This
+General Public License applies to most of the Free Software
+Foundation's software and to any other program whose authors commit to
+using it.  (Some other Free Software Foundation software is covered by
+the GNU Lesser General Public License instead.)  You can apply it to
+your programs, too.
+
+  When we speak of free software, we are referring to freedom, not
+price.  Our General Public Licenses are designed to make sure that you
+have the freedom to distribute copies of free software (and charge for
+this service if you wish), that you receive source code or can get it
+if you want it, that you can change the software or use pieces of it
+in new free programs; and that you know you can do these things.
+
+  To protect your rights, we need to make restrictions that forbid
+anyone to deny you these rights or to ask you to surrender the rights.
+These restrictions translate to certain responsibilities for you if you
+distribute copies of the software, or if you modify it.
+
+  For example, if you distribute copies of such a program, whether
+gratis or for a fee, you must give the recipients all the rights that
+you have.  You must make sure that they, too, receive or can get the
+source code.  And you must show them these terms so they know their
+rights.
+
+  We protect your rights with two steps: (1) copyright the software, and
+(2) offer you this license which gives you legal permission to copy,
+distribute and/or modify the software.
+
+  Also, for each author's protection and ours, we want to make certain
+that everyone understands that there is no warranty for this free
+software.  If the software is modified by someone else and passed on, we
+want its recipients to know that what they have is not the original, so
+that any problems introduced by others will not reflect on the original
+authors' reputations.
+
+  Finally, any free program is threatened constantly by software
+patents.  We wish to avoid the danger that redistributors of a free
+program will individually obtain patent licenses, in effect making the
+program proprietary.  To prevent this, we have made it clear that any
+patent must be licensed for everyone's free use or not licensed at all.
+
+  The precise terms and conditions for copying, distribution and
+modification follow.
+
+		    GNU GENERAL PUBLIC LICENSE
+   TERMS AND CONDITIONS FOR COPYING, DISTRIBUTION AND MODIFICATION
+
+  0. This License applies to any program or other work which contains
+a notice placed by the copyright holder saying it may be distributed
+under the terms of this General Public License.  The "Program", below,
+refers to any such program or work, and a "work based on the Program"
+means either the Program or any derivative work under copyright law:
+that is to say, a work containing the Program or a portion of it,
+either verbatim or with modifications and/or translated into another
+language.  (Hereinafter, translation is included without limitation in
+the term "modification".)  Each licensee is addressed as "you".
+
+Activities other than copying, distribution and modification are not
+covered by this License; they are outside its scope.  The act of
+running the Program is not restricted, and the output from the Program
+is covered only if its contents constitute a work based on the
+Program (independent of having been made by running the Program).
+Whether that is true depends on what the Program does.
+
+  1. You may copy and distribute verbatim copies of the Program's
+source code as you receive it, in any medium, provided that you
+conspicuously and appropriately publish on each copy an appropriate
+copyright notice and disclaimer of warranty; keep intact all the
+notices that refer to this License and to the absence of any warranty;
+and give any other recipients of the Program a copy of this License
+along with the Program.
+
+You may charge a fee for the physical act of transferring a copy, and
+you may at your option offer warranty protection in exchange for a fee.
+
+  2. You may modify your copy or copies of the Program or any portion
+of it, thus forming a work based on the Program, and copy and
+distribute such modifications or work under the terms of Section 1
+above, provided that you also meet all of these conditions:
+
+    a) You must cause the modified files to carry prominent notices
+    stating that you changed the files and the date of any change.
+
+    b) You must cause any work that you distribute or publish, that in
+    whole or in part contains or is derived from the Program or any
+    part thereof, to be licensed as a whole at no charge to all third
+    parties under the terms of this License.
+
+    c) If the modified program normally reads commands interactively
+    when run, you must cause it, when started running for such
+    interactive use in the most ordinary way, to print or display an
+    announcement including an appropriate copyright notice and a
+    notice that there is no warranty (or else, saying that you provide
+    a warranty) and that users may redistribute the program under
+    these conditions, and telling the user how to view a copy of this
+    License.  (Exception: if the Program itself is interactive but
+    does not normally print such an announcement, your work based on
+    the Program is not required to print an announcement.)
+
+These requirements apply to the modified work as a whole.  If
+identifiable sections of that work are not derived from the Program,
+and can be reasonably considered independent and separate works in
+themselves, then this License, and its terms, do not apply to those
+sections when you distribute them as separate works.  But when you
+distribute the same sections as part of a whole which is a work based
+on the Program, the distribution of the whole must be on the terms of
+this License, whose permissions for other licensees extend to the
+entire whole, and thus to each and every part regardless of who wrote it.
+
+Thus, it is not the intent of this section to claim rights or contest
+your rights to work written entirely by you; rather, the intent is to
+exercise the right to control the distribution of derivative or
+collective works based on the Program.
+
+In addition, mere aggregation of another work not based on the Program
+with the Program (or with a work based on the Program) on a volume of
+a storage or distribution medium does not bring the other work under
+the scope of this License.
+
+  3. You may copy and distribute the Program (or a work based on it,
+under Section 2) in object code or executable form under the terms of
+Sections 1 and 2 above provided that you also do one of the following:
+
+    a) Accompany it with the complete corresponding machine-readable
+    source code, which must be distributed under the terms of Sections
+    1 and 2 above on a medium customarily used for software interchange; or,
+
+    b) Accompany it with a written offer, valid for at least three
+    years, to give any third party, for a charge no more than your
+    cost of physically performing source distribution, a complete
+    machine-readable copy of the corresponding source code, to be
+    distributed under the terms of Sections 1 and 2 above on a medium
+    customarily used for software interchange; or,
+
+    c) Accompany it with the information you received as to the offer
+    to distribute corresponding source code.  (This alternative is
+    allowed only for noncommercial distribution and only if you
+    received the program in object code or executable form with such
+    an offer, in accord with Subsection b above.)
+
+The source code for a work means the preferred form of the work for
+making modifications to it.  For an executable work, complete source
+code means all the source code for all modules it contains, plus any
+associated interface definition files, plus the scripts used to
+control compilation and installation of the executable.  However, as a
+special exception, the source code distributed need not include
+anything that is normally distributed (in either source or binary
+form) with the major components (compiler, kernel, and so on) of the
+operating system on which the executable runs, unless that component
+itself accompanies the executable.
+
+If distribution of executable or object code is made by offering
+access to copy from a designated place, then offering equivalent
+access to copy the source code from the same place counts as
+distribution of the source code, even though third parties are not
+compelled to copy the source along with the object code.
+
+  4. You may not copy, modify, sublicense, or distribute the Program
+except as expressly provided under this License.  Any attempt
+otherwise to copy, modify, sublicense or distribute the Program is
+void, and will automatically terminate your rights under this License.
+However, parties who have received copies, or rights, from you under
+this License will not have their licenses terminated so long as such
+parties remain in full compliance.
+
+  5. You are not required to accept this License, since you have not
+signed it.  However, nothing else grants you permission to modify or
+distribute the Program or its derivative works.  These actions are
+prohibited by law if you do not accept this License.  Therefore, by
+modifying or distributing the Program (or any work based on the
+Program), you indicate your acceptance of this License to do so, and
+all its terms and conditions for copying, distributing or modifying
+the Program or works based on it.
+
+  6. Each time you redistribute the Program (or any work based on the
+Program), the recipient automatically receives a license from the
+original licensor to copy, distribute or modify the Program subject to
+these terms and conditions.  You may not impose any further
+restrictions on the recipients' exercise of the rights granted herein.
+You are not responsible for enforcing compliance by third parties to
+this License.
+
+  7. If, as a consequence of a court judgment or allegation of patent
+infringement or for any other reason (not limited to patent issues),
+conditions are imposed on you (whether by court order, agreement or
+otherwise) that contradict the conditions of this License, they do not
+excuse you from the conditions of this License.  If you cannot
+distribute so as to satisfy simultaneously your obligations under this
+License and any other pertinent obligations, then as a consequence you
+may not distribute the Program at all.  For example, if a patent
+license would not permit royalty-free redistribution of the Program by
+all those who receive copies directly or indirectly through you, then
+the only way you could satisfy both it and this License would be to
+refrain entirely from distribution of the Program.
+
+If any portion of this section is held invalid or unenforceable under
+any particular circumstance, the balance of the section is intended to
+apply and the section as a whole is intended to apply in other
+circumstances.
+
+It is not the purpose of this section to induce you to infringe any
+patents or other property right claims or to contest validity of any
+such claims; this section has the sole purpose of protecting the
+integrity of the free software distribution system, which is
+implemented by public license practices.  Many people have made
+generous contributions to the wide range of software distributed
+through that system in reliance on consistent application of that
+system; it is up to the author/donor to decide if he or she is willing
+to distribute software through any other system and a licensee cannot
+impose that choice.
+
+This section is intended to make thoroughly clear what is believed to
+be a consequence of the rest of this License.
+
+  8. If the distribution and/or use of the Program is restricted in
+certain countries either by patents or by copyrighted interfaces, the
+original copyright holder who places the Program under this License
+may add an explicit geographical distribution limitation excluding
+those countries, so that distribution is permitted only in or among
+countries not thus excluded.  In such case, this License incorporates
+the limitation as if written in the body of this License.
+
+  9. The Free Software Foundation may publish revised and/or new versions
+of the General Public License from time to time.  Such new versions will
+be similar in spirit to the present version, but may differ in detail to
+address new problems or concerns.
+
+Each version is given a distinguishing version number.  If the Program
+specifies a version number of this License which applies to it and "any
+later version", you have the option of following the terms and conditions
+either of that version or of any later version published by the Free
+Software Foundation.  If the Program does not specify a version number of
+this License, you may choose any version ever published by the Free Software
+Foundation.
+
+  10. If you wish to incorporate parts of the Program into other free
+programs whose distribution conditions are different, write to the author
+to ask for permission.  For software which is copyrighted by the Free
+Software Foundation, write to the Free Software Foundation; we sometimes
+make exceptions for this.  Our decision will be guided by the two goals
+of preserving the free status of all derivatives of our free software and
+of promoting the sharing and reuse of software generally.
+
+			    NO WARRANTY
+
+  11. BECAUSE THE PROGRAM IS LICENSED FREE OF CHARGE, THERE IS NO WARRANTY
+FOR THE PROGRAM, TO THE EXTENT PERMITTED BY APPLICABLE LAW.  EXCEPT WHEN
+OTHERWISE STATED IN WRITING THE COPYRIGHT HOLDERS AND/OR OTHER PARTIES
+PROVIDE THE PROGRAM "AS IS" WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESSED
+OR IMPLIED, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF
+MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE.  THE ENTIRE RISK AS
+TO THE QUALITY AND PERFORMANCE OF THE PROGRAM IS WITH YOU.  SHOULD THE
+PROGRAM PROVE DEFECTIVE, YOU ASSUME THE COST OF ALL NECESSARY SERVICING,
+REPAIR OR CORRECTION.
+
+  12. IN NO EVENT UNLESS REQUIRED BY APPLICABLE LAW OR AGREED TO IN WRITING
+WILL ANY COPYRIGHT HOLDER, OR ANY OTHER PARTY WHO MAY MODIFY AND/OR
+REDISTRIBUTE THE PROGRAM AS PERMITTED ABOVE, BE LIABLE TO YOU FOR DAMAGES,
+INCLUDING ANY GENERAL, SPECIAL, INCIDENTAL OR CONSEQUENTIAL DAMAGES ARISING
+OUT OF THE USE OR INABILITY TO USE THE PROGRAM (INCLUDING BUT NOT LIMITED
+TO LOSS OF DATA OR DATA BEING RENDERED INACCURATE OR LOSSES SUSTAINED BY
+YOU OR THIRD PARTIES OR A FAILURE OF THE PROGRAM TO OPERATE WITH ANY OTHER
+PROGRAMS), EVEN IF SUCH HOLDER OR OTHER PARTY HAS BEEN ADVISED OF THE
+POSSIBILITY OF SUCH DAMAGES.
+
+		     END OF TERMS AND CONDITIONS
+
+	    How to Apply These Terms to Your New Programs
+
+  If you develop a new program, and you want it to be of the greatest
+possible use to the public, the best way to achieve this is to make it
+free software which everyone can redistribute and change under these terms.
+
+  To do so, attach the following notices to the program.  It is safest
+to attach them to the start of each source file to most effectively
+convey the exclusion of warranty; and each file should have at least
+the "copyright" line and a pointer to where the full notice is found.
+
+    <one line to give the program's name and a brief idea of what it does.>
+    Copyright (C) <year>  <name of author>
+
+    This program is free software; you can redistribute it and/or modify
+    it under the terms of the GNU General Public License as published by
+    the Free Software Foundation; either version 2 of the License, or
+    (at your option) any later version.
+
+    This program is distributed in the hope that it will be useful,
+    but WITHOUT ANY WARRANTY; without even the implied warranty of
+    MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+    GNU General Public License for more details.
+
+    You should have received a copy of the GNU General Public License along
+    with this program; if not, write to the Free Software Foundation, Inc.,
+    51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA.
+
+Also add information on how to contact you by electronic and paper mail.
+
+If the program is interactive, make it output a short notice like this
+when it starts in an interactive mode:
+
+    Gnomovision version 69, Copyright (C) year name of author
+    Gnomovision comes with ABSOLUTELY NO WARRANTY; for details type `show w'.
+    This is free software, and you are welcome to redistribute it
+    under certain conditions; type `show c' for details.
+
+The hypothetical commands `show w' and `show c' should show the appropriate
+parts of the General Public License.  Of course, the commands you use may
+be called something other than `show w' and `show c'; they could even be
+mouse-clicks or menu items--whatever suits your program.
+
+You should also get your employer (if you work as a programmer) or your
+school, if any, to sign a "copyright disclaimer" for the program, if
+necessary.  Here is a sample; alter the names:
+
+  Yoyodyne, Inc., hereby disclaims all copyright interest in the program
+  `Gnomovision' (which makes passes at compilers) written by James Hacker.
+
+  <signature of Ty Coon>, 1 April 1989
+  Ty Coon, President of Vice
+
+This General Public License does not permit incorporating your program into
+proprietary programs.  If your program is a subroutine library, you may
+consider it more useful to permit linking proprietary applications with the
+library.  If this is what you want to do, use the GNU Lesser General
+Public License instead of this License.




From uwe at hermann-uwe.de  Wed Oct  3 20:58:00 2007
From: uwe at hermann-uwe.de (Uwe Hermann)
Date: Wed, 3 Oct 2007 20:58:00 +0200
Subject: [LinuxBIOS] Fwd: [Bug 315351] Review Request: superiotool
In-Reply-To: <adf480660710030259j65935cb3wfe5a5de6228bbc31@mail.gmail.com>
References: <adf480660710030259j65935cb3wfe5a5de6228bbc31@mail.gmail.com>
Message-ID: <20071003185800.GA14438@greenwood>

On Wed, Oct 03, 2007 at 01:59:06PM +0400, Peter Lemenkov wrote:
> Hello All!
> Just FYI I've just created a review request for adding superiotool
> into Fedora distribution and derived distributives.

Great, thanks!


> So I just forwarded it to you - please add LICENSE file into SVN.

Done.


Uwe.
-- 
http://www.hermann-uwe.de  | http://www.holsham-traders.de
http://www.crazy-hacks.org | http://www.unmaintained-free-software.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20071003/74d831ec/attachment.sig>

From idwer_v at hotmail.com  Wed Oct  3 21:10:58 2007
From: idwer_v at hotmail.com (Idwer Vollering)
Date: Wed, 3 Oct 2007 19:10:58 +0000
Subject: [LinuxBIOS] 440BX progress / superio w83977tf-aw
In-Reply-To: <20071002235450.GH17835@greenwood>
References: <BLU102-W609EAA2C2EB0A2D789C9CD8BAE0@phx.gbl>
	<BLU102-W432269A73B18A6665AEB408BAE0@phx.gbl>
	<20071002235450.GH17835@greenwood>
Message-ID: <BLU102-W932BF4E27B2864944AC748BAF0@phx.gbl>




> Date: Wed, 3 Oct 2007 01:54:50 +0200
> From: uwe at hermann-uwe.de
> To: idwer_v at hotmail.com
> CC: linuxbios at linuxbios.org
> Subject: Re: FW: [LinuxBIOS]  440BX progress / superio w83977tf-aw
> 
> On Tue, Oct 02, 2007 at 01:21:23PM +0000, Idwer Vollering wrote:
> > http://linuxbios.org/pipermail/linuxbios/2006-November/017262.html
> > 
> > It boots (v2 r2811), but serial outputs says 'Can not load ELF Image.' which is correct because i didn't yet manage to get filo appended as a payload from targets/asus/p2b/Config.lb.
> > 
> > What options in Config.lb must be set to create enough space to include filo.elf (about 94 KB) using both normal and fallback sections; option ROM_IMAGE_SIZE = (some_substracted_size) * 1024 ?
> 
> No changes needed in Config.lb, I suggest you simply make filo smaller
> for now. Disable all unneeded options (ReiserFS, CDROM support, XFS
> support, all debugging, etc). You only need very few of the options.
> My filo.elf is 54KB, which is small enough for pretty much all boards.
> 
> 
> > Also, superio (from r2811) won't recognize the onboard winbond w83977tf-aw.
> 
> It is (partly) recognized, otherwise you wouldn't get any serial output.
> 
> The Config.lb stuff below is only executed very late in the boot
> process, but the serial console init (which needs the Super I/O) happens
> earlier. As you have serial output, that code works ok.
> 
> 
> > chip northbridge/intel/i440bx
> >         device pci_domain 0 on
> >                 device pci 0.0 on end # host bridge
> >                 device pci 1.0 on end # pci bridge / agp device/bridge
> >                         chip southbridge/intel/i82371eb # southbridge
> >                                 device pci 4.0 on end # isa bridge
> >                                         chip superio/winbond/w83977tf # superio, winbond w83977tf-aw
> >                                                 device pci 4.1 on end # ide interface
> >                                                 device pci 4.2 on end # usb controller
> >                                                 device pci 4.3 on end # acpi bridge

according to src/mainboard/tyan/s1846/Config.lb, this should be it:

chip northbridge/intel/i440bx # northbridge
    device pci_domain 0 on
        device pci 0.0 on end # host bridge
        device pci 1.0 on end # agp bridge

        chip southbridge/intel/i82371eb # southbridge
            device pci 4.0 on # isa bridge
                chip superio/winbond/w83977tf # superio, winbond w83977tf-aw
                end
            end

            device pci 4.1 on end # ide interface
            device pci 4.2 on end # usb controller
            device pci 4.3 on end # acpi bridge
            register "ide0_enable" = "1"
            register "ide1_enable" = "1"
        end
    end

    chip cpu/intel/slot_2
    end
end

> 
> This looks broken. The PCI devices should not be inside the Super I/O section.
> Instead the superio-related stuff should be there. Have a look at some
> other boards for examples. The output of 'lspnp -v' (from original BIOS,
> and with all hardware attached, e.g. PS/2 keyboard, PS/2 mouse, etc)
> should give you some hints (please also post it here).

"lspnp: /proc/bus/pnp not available" (asus p2b bios v1012)

The kernel used is compiled with CONFIG_PNPBIOS=y 
> 
> 
> I'll try to dig out my P2B tomorrow or so and see how far I get, and
> maybe post some patch to improve it a bit. Please note that the 440BX
> code is still not very generic, it'll probably not work for this board
> (only the Tyan S1846 is confirmed to work so far). Fixing this is on
> my (huge) TODO list.

Where can i change the (hardcoded i believe) ramspeed/timings ?

> 
> 
> Uwe.
> -- 
> http://www.hermann-uwe.de  | http://www.holsham-traders.de
> http://www.crazy-hacks.org | http://www.unmaintained-free-software.org

_________________________________________________________________
Live.nl: je eigen persoonlijk startpagina met nieuws en feeds die JIJ belangrijk vindt!
http://www.live.com/getstarted.aspx
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20071003/2ba40bf5/attachment.html>

From info at coresystems.de  Wed Oct  3 21:43:07 2007
From: info at coresystems.de (LinuxBIOS information)
Date: Wed, 03 Oct 2007 21:43:07 +0200
Subject: [LinuxBIOS] r2819 build service
Message-ID: <E1IdA7f-0006e5-O6@khepri.openbios.org>

Dear LinuxBIOS readers!

This is the automated build check service of LinuxBIOS.

The developer "uwe" checked in revision 2819 to
the LinuxBIOS source repository and caused the following 
changes:

Change Log:
Add a copy of the GPL (trivial).

Signed-off-by: Uwe Hermann <uwe at hermann-uwe.de>
Acked-by: Uwe Hermann <uwe at hermann-uwe.de>



Build Log:
Compilation of arima:hdama is still broken
See the error log at http://qa.linuxbios.org/log_buildbrd.php?revision=2819&device=hdama&vendor=arima
Compilation of ibm:e325 is still broken
See the error log at http://qa.linuxbios.org/log_buildbrd.php?revision=2819&device=e325&vendor=ibm
Compilation of ibm:e326 is still broken
See the error log at http://qa.linuxbios.org/log_buildbrd.php?revision=2819&device=e326&vendor=ibm
Compilation of iei:juki-511p is still broken
See the error log at http://qa.linuxbios.org/log_buildbrd.php?revision=2819&device=juki-511p&vendor=iei
Compilation of iwill:dk8s2 is still broken
See the error log at http://qa.linuxbios.org/log_buildbrd.php?revision=2819&device=dk8s2&vendor=iwill
Compilation of iwill:dk8x is still broken
See the error log at http://qa.linuxbios.org/log_buildbrd.php?revision=2819&device=dk8x&vendor=iwill
Compilation of newisys:khepri is still broken
See the error log at http://qa.linuxbios.org/log_buildbrd.php?revision=2819&device=khepri&vendor=newisys


If something broke during this checkin please be a pain 
in uwe's neck until the issue is fixed.

If this issue is not fixed within 24h the revision should 
be backed out.

   Best regards,
     LinuxBIOS automatic build system





From kevint at lanl.gov  Wed Oct  3 22:18:00 2007
From: kevint at lanl.gov (kevint)
Date: Wed, 3 Oct 2007 14:18:00 -0600
Subject: [LinuxBIOS] hdama compile error
In-Reply-To: <2ea3fae10710022152x3b289e65t2c6bb5b656f0fde7@mail.gmail.com>
References: <DEE8917F-067D-4757-8BCE-746526351470@lanl.gov>
	<4702C620.2050602@amd.com> <20071002235939.GI17835@greenwood>
	<2ea3fae10710022152x3b289e65t2c6bb5b656f0fde7@mail.gmail.com>
Message-ID: <18D6D92C-FD12-4BB8-9D26-724C1C286D39@lanl.gov>

We have rev C and rev E boards.

Thanks!

On Oct 2, 2007, at 10:52 PM, yhlu wrote:

> can you move new one to incoherent_ht_car.c, and leave the old one to
> incoherent_ht.c
>
> or
>
> copy old one to incoherent_ht_romcc.c
> some broken MB need to updated...
>
> Kevin,
> what is the Opteron rev? is it B3 or Rev E...
> You may have problem with B3 and Cache_as_RAM
>
> YH

********************************************
Kevin Tegtmeier
HPC-3 Scientific Computing Resources
Los Alamos National Laboratory
email:  kevint at lanl.gov
phone: 505.667.3488
********************************************



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20071003/9ee28629/attachment.html>

From rminnich at gmail.com  Wed Oct  3 22:40:44 2007
From: rminnich at gmail.com (ron minnich)
Date: Wed, 3 Oct 2007 13:40:44 -0700
Subject: [LinuxBIOS] patch: fix filo dependency on memory being zero
In-Reply-To: <13426df10710031123t406504bxdfa9b45e4ad7194b@mail.gmail.com>
References: <13426df10710031123t406504bxdfa9b45e4ad7194b@mail.gmail.com>
Message-ID: <13426df10710031340o2469373ape2e7212e485524e7@mail.gmail.com>

Hmm, missing attachment.

ron

On 10/3/07, ron minnich <rminnich at gmail.com> wrote:
> This patch makes qemu work again on v3. FILO was depending on bss
> being zero, which is not all that safe in embedded. It's better to
> zero things you are depending on being zero.
>
> ron
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: filo.zerobss.diff
Type: text/x-patch
Size: 1494 bytes
Desc: not available
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20071003/2d382601/attachment.diff>

From kevint at lanl.gov  Wed Oct  3 23:23:47 2007
From: kevint at lanl.gov (kevint)
Date: Wed, 3 Oct 2007 15:23:47 -0600
Subject: [LinuxBIOS] hdama compile error
In-Reply-To: <18D6D92C-FD12-4BB8-9D26-724C1C286D39@lanl.gov>
References: <DEE8917F-067D-4757-8BCE-746526351470@lanl.gov>
	<4702C620.2050602@amd.com> <20071002235939.GI17835@greenwood>
	<2ea3fae10710022152x3b289e65t2c6bb5b656f0fde7@mail.gmail.com>
	<18D6D92C-FD12-4BB8-9D26-724C1C286D39@lanl.gov>
Message-ID: <AA6DEADB-9F3A-4F64-8882-582154165C60@lanl.gov>

Correction:  Rev C and Rev E Opteron processors.

On Oct 3, 2007, at 2:18 PM, kevint wrote:

> We have rev C and rev E boards.
>
> Thanks!
>
> On Oct 2, 2007, at 10:52 PM, yhlu wrote:
>
>> can you move new one to incoherent_ht_car.c, and leave the old one to
>> incoherent_ht.c
>>
>> or
>>
>> copy old one to incoherent_ht_romcc.c
>> some broken MB need to updated...
>>
>> Kevin,
>> what is the Opteron rev? is it B3 or Rev E...
>> You may have problem with B3 and Cache_as_RAM
>>
>> YH
>
> ********************************************
> Kevin Tegtmeier
> HPC-3 Scientific Computing Resources
> Los Alamos National Laboratory
> email:  kevint at lanl.gov
> phone: 505.667.3488
> ********************************************
>
>
>

********************************************
Kevin Tegtmeier
HPC-3 Scientific Computing Resources
Los Alamos National Laboratory
email:  kevint at lanl.gov
phone: 505.667.3488
********************************************



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20071003/a46b500f/attachment.html>

From rminnich at gmail.com  Wed Oct  3 23:24:17 2007
From: rminnich at gmail.com (ron minnich)
Date: Wed, 3 Oct 2007 14:24:17 -0700
Subject: [LinuxBIOS] I got this just once on digital logic msm800sev
Message-ID: <13426df10710031424p9a06bb7s9899962f97f3215d@mail.gmail.com>

LinuxBIOS-3.0.0 Wed Oct  3 13:53:25 PDT 2007 starting...
Choosing fallback boot.
LAR: Attempting to open 'fallback/initram'.
LAR: Start 0xfff00000 len 0x100000
LAR: search for normal/payload/segment0
LAR: search for normal/payload/segment1
LAR: search for normal/option_table
LAR: search for normal/stage2
LAR: search for normal/initram
LAR: search for bootblock
NO FILE FOUND
LAR: Run file fallback/initram failed: No such file.
Fallback failed. Try normal boot
LAR: Attempting to open 'normal/initram'.
LAR: Start 0xfff00000 len 0x100000
LAR: search for normal/payload/segment0
LAR: search for normal/payload/segment1
LAR: search for normal/option_table
LAR: search for normal/stage2
LAR: search for normal/initram
LAR: CHECK normal/initram @ 0xfff0d770
start 0xfff0d7b0 len 11092 reallen 11092 compression 0 entry
0x00000000 loadaddress 0x0000
where is 0xfff0d7b0

But hey, I did get it *once*. It's not really working right at present.

Note version.

ron



From rminnich at gmail.com  Wed Oct  3 23:30:19 2007
From: rminnich at gmail.com (ron minnich)
Date: Wed, 3 Oct 2007 14:30:19 -0700
Subject: [LinuxBIOS] v3 on msm800sev
Message-ID: <13426df10710031430h6ac26e7fv4f7280369b446091@mail.gmail.com>

actually, it's pretty consistent. Three minute or so wait, then I get
this every time. LinuxBIOS-3.0.0 Wed Oct  3 13:53:25 PDT 2007
starting...
Choosing fallback boot.
LAR: Attempting to open 'fallback/initram'.
LAR: Start 0xfff00000 len 0x100000
LAR: search for normal/payload/segment0
LAR: search for normal/payload/segment1
LAR: search for normal/option_table
LAR: search for normal/stage2
LAR: search for normal/initram
LAR: search for bootblock
NO FILE FOUND
LAR: Run file fallback/initram failed: No such file.
Fallback failed. Try normal boot
LAR: Attempting to open 'normal/initram'.
LAR: Start 0xfff00000 len 0x100000
LAR: search for normal/payload/segment0
LAR: search for normal/payload/segment1
LAR: search for normal/option_table
LAR: search for normal/stage2
LAR: search for normal/initram
LAR: CHECK normal/initram @ 0xfff0d770
start 0xfff0d7b0 len 11092 reallen 11092 compression 0 entry
0x00000000 loadaddress 0x0000
where is 0xfff0d7b0

well, a lot of stuff has to work to get this far. POST is not working
from C -- it's fine from assembly. I don't get the long delay on
serial. It goes bye-bye when it jumps to initram.

But, hey, ... it's working more than it used to.

ron



From yinghailu at gmail.com  Wed Oct  3 23:50:56 2007
From: yinghailu at gmail.com (yhlu)
Date: Wed, 3 Oct 2007 14:50:56 -0700
Subject: [LinuxBIOS] hdama compile error
In-Reply-To: <AA6DEADB-9F3A-4F64-8882-582154165C60@lanl.gov>
References: <DEE8917F-067D-4757-8BCE-746526351470@lanl.gov>
	<4702C620.2050602@amd.com> <20071002235939.GI17835@greenwood>
	<2ea3fae10710022152x3b289e65t2c6bb5b656f0fde7@mail.gmail.com>
	<18D6D92C-FD12-4BB8-9D26-724C1C286D39@lanl.gov>
	<AA6DEADB-9F3A-4F64-8882-582154165C60@lanl.gov>
Message-ID: <2ea3fae10710031450r5973caefna171d799597f9df9@mail.gmail.com>

On 10/3/07, kevint <kevint at lanl.gov> wrote:
> Correction:  Rev C and Rev E Opteron processors.

good, we could translate hadma code to CAR based code, please check
the serengeti_cheetah...

YH



From rminnich at gmail.com  Thu Oct  4 00:34:52 2007
From: rminnich at gmail.com (ron minnich)
Date: Wed, 3 Oct 2007 15:34:52 -0700
Subject: [LinuxBIOS] Two more CS5530 IRQ steering questions
In-Reply-To: <735999.11669.qm@web35906.mail.mud.yahoo.com>
References: <735999.11669.qm@web35906.mail.mud.yahoo.com>
Message-ID: <13426df10710031534n2aee155al8e32cd18c8792ece@mail.gmail.com>

On 10/2/07, Jonathan Sturges <jonathansturges at yahoo.com> wrote:

> So since things work, I'm about ready to claim success.  Are the "failed" messages an acceptable artifact of the kernel not knowing the CS5530 router, or something I should be concerned about?


yes, if it does not know the router it can get pretty mixed up. I
think you're ok.

ron



From myles at pel.cs.byu.edu  Thu Oct  4 00:48:57 2007
From: myles at pel.cs.byu.edu (Myles Watson)
Date: Wed, 3 Oct 2007 16:48:57 -0600
Subject: [LinuxBIOS] FW: ADLO progress
Message-ID: <01ec01c8060f$94ff3b10$4d22040a@chimp>


These are all patches to ADLO/bios/rombios.c

They should be applied in this order:
whitespace.patch
defines.patch
printf.patch
ide_atapi.patch

ide.2.3.5.patch is a patch against the latest bios from Bochs.

The status is that I've eliminated the flakiness.  It boots into the windows
install CD every time, reports my IDE drives correctly, and can install
windows.

It still doesn't boot into Windows once installed.

Any help is appreciated.

Myles

Signed-off-by: Myles Watson <myles at pel.cs.byu.edu>

-------------- next part --------------
A non-text attachment was scrubbed...
Name: whitespace.patch
Type: application/octet-stream
Size: 55033 bytes
Desc: not available
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20071003/68a1bc07/attachment.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: defines.patch
Type: application/octet-stream
Size: 3396 bytes
Desc: not available
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20071003/68a1bc07/attachment-0001.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ide.2.3.5.patch
Type: application/octet-stream
Size: 26038 bytes
Desc: not available
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20071003/68a1bc07/attachment-0002.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ide_atapi.patch
Type: application/octet-stream
Size: 26717 bytes
Desc: not available
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20071003/68a1bc07/attachment-0003.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: printf.patch
Type: application/octet-stream
Size: 1627 bytes
Desc: not available
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20071003/68a1bc07/attachment-0004.obj>

From rminnich at gmail.com  Thu Oct  4 00:54:49 2007
From: rminnich at gmail.com (ron minnich)
Date: Wed, 3 Oct 2007 15:54:49 -0700
Subject: [LinuxBIOS] [IMPORT] GIGABYTE GA-2761GXDK
In-Reply-To: <Pine.LNX.4.64.0710030928160.3653@bigred.russwhit.org>
References: <006b01c8058d$38dc52f0$0200a8c0@sis.com.tw>
	<Pine.LNX.4.64.0710030928160.3653@bigred.russwhit.org>
Message-ID: <13426df10710031554u128792f5w69a67e90415bef12@mail.gmail.com>

On 10/3/07, Russell Whitaker <russ at ashlandhome.net> wrote:
>
>
> On Wed, 3 Oct 2007, Morgan Tsai wrote:
>
> > Copyright (C) 2007 Morgan Tsai <my_tsai at sis.com>
> > Copyright (C) 2007 Silicon Integrated Systems Corp. (SiS)
> >
>
> Also, your email of Sept 21 has same copyright notice.
>
> I believe contributions to the Linuxbios project should be
> released under the GPL.

I went through the code and don't see any issues, since this copyright
is only in the note.

I think Morgan and SiS are doing a fine job here.

But, Morgan, don't you want to get your name and SiS name in the
various files? All the GPL headers are there, but they don't mention
either of you.

I can try to rework this as a patch but it might be better if you do
this instead.

Thanks

ron



From joe at smittys.pointclark.net  Thu Oct  4 01:04:57 2007
From: joe at smittys.pointclark.net (joe at smittys.pointclark.net)
Date: Wed, 03 Oct 2007 19:04:57 -0400
Subject: [LinuxBIOS] Problems with Filo booting - HELP
In-Reply-To: <47017223.6010504@gmail.com>
References: <20070929165103.pcm220bn4s48sow8@smittys.pointclark.net>
	<20070929205527.GA16584@coresystems.de>
	<20070929170245.ata0hgegqowgcwgs@www.smittys.pointclark.net>
	<20070929201342.mifqbujb44ocwks8@smittys.pointclark.net>
	<46FF1CB2.60901@gmail.com>
	<20070930115720.mwni4u7go4wkk8wg@www.smittys.pointclark.net>
	<47000290.6020000@gmail.com>
	<20071001094827.loois4qr0g4ckw8o@www.smittys.pointclark.net>
	<13426df10710010950s379f8230y5b4ffec4da605f06@mail.gmail.com>
	<20071001165858.vlz66uxpusgk0gww@www.smittys.pointclark.net>
	<47017223.6010504@gmail.com>
Message-ID: <20071003190457.a6hta1e4kk8w0wwc@www.smittys.pointclark.net>

Quoting Corey Osgood <corey.osgood at gmail.com>:

> joe at smittys.pointclark.net wrote:
>> Quoting ron minnich <rminnich at gmail.com>:
>>
>>
>>> you might try forcing the size (in code) to 32M or some such in
>>> hardwaremain.c and see if it works then. There's  something odd with
>>> your ram.
>>>
>>> ron
>>>
>>>
>> It won't have anything to do with the fact that:
>>
>> a. It is onboard 128MB memory
>> b. It doesn't have a SPD module
>> c. It is located in the second slot not first.
>>
>
> It shouldn't, no, especially not the first 2.
>
>> This is wierd because it passes the ram_check() from auto.c earlier in
>> the process just fine.
>>
>> /* Check RAM. */
>> ram_check(0, 640 * 1024);
>>
>> Thanks - Joe
>
> All that's checking is the first 640K. To check the rest of the memory,
> use ram_check(1024*1024, 1024*1024*128), starting at 1mb to avoid any
> reserved areas. Make sure your ram_resource() calls also avoids those
> reserved areas.
>
> -Corey
>
Ok, I think I figured out what is going on here. The ram_check from  
0-640K works fine. But ram_check from 1MB-128MB fails. My DRB  
registers are set correctly, and report 128MB of memory. Why? That is  
the golden question of the year. Can anyone help out a thinning hair  
(from pulling out - stress related) guy in desperate need?

Thanks - Joe



From rminnich at gmail.com  Thu Oct  4 01:11:48 2007
From: rminnich at gmail.com (ron minnich)
Date: Wed, 3 Oct 2007 16:11:48 -0700
Subject: [LinuxBIOS] Problems with Filo booting - HELP
In-Reply-To: <20071003190457.a6hta1e4kk8w0wwc@www.smittys.pointclark.net>
References: <20070929165103.pcm220bn4s48sow8@smittys.pointclark.net>
	<20070929201342.mifqbujb44ocwks8@smittys.pointclark.net>
	<46FF1CB2.60901@gmail.com>
	<20070930115720.mwni4u7go4wkk8wg@www.smittys.pointclark.net>
	<47000290.6020000@gmail.com>
	<20071001094827.loois4qr0g4ckw8o@www.smittys.pointclark.net>
	<13426df10710010950s379f8230y5b4ffec4da605f06@mail.gmail.com>
	<20071001165858.vlz66uxpusgk0gww@www.smittys.pointclark.net>
	<47017223.6010504@gmail.com>
	<20071003190457.a6hta1e4kk8w0wwc@www.smittys.pointclark.net>
Message-ID: <13426df10710031611h22224488u6bd4e2840c357454@mail.gmail.com>

How does ram check from 1 mb to 2 (not 128 -- 2) work? You need to
start searching in smaller numbers than 128 mb

ron



From uwe at hermann-uwe.de  Thu Oct  4 02:33:11 2007
From: uwe at hermann-uwe.de (Uwe Hermann)
Date: Thu, 4 Oct 2007 02:33:11 +0200
Subject: [LinuxBIOS] [PATCH] superiotool: Various improvements
Message-ID: <20071004003311.GC14438@greenwood>

This patch changes the --verbose output to make it a lot more useful
and (hopefully) a bit better readable. Also fix up the NSC code to
behave like the rest of superiotool.

Various other changes (see patch) which are sort of interleaved, it
would be overkill (and not useful) to extract them into an extra patch, IMO.

Tested on various computers (both building and runnning).

Example output:

$ ./superiotool -V
superiotool r2815
Probing for ALi Super I/O at 0x3f0...
  Failed. Returned data: id=0xffff, rev=0xff
Probing for ALi Super I/O at 0x370...
  Failed. Returned data: id=0xffff, rev=0xff
Probing for NSC Super I/O at 0x2e...
  Failed. Returned data: port=0xff, port+1=0xff
Probing for NSC Super I/O at 0x4e...
  Failed. Returned data: port=0xff, port+1=0xff
Probing for Fintek Super I/O at 0x2e...
  Failed. Returned data: vid=0xffff, id=0xffff
Probing for Fintek Super I/O at 0x4e...
  Failed. Returned data: vid=0xffff, id=0xffff
Probing for ITE Super I/O (init=0x87,0x01,0x55,0x55/0xaa) at 0x2e...
  Failed. Returned data: id=0x0000, rev=0x0
Probing for ITE Super I/O (init=0x87,0x87) at 0x2e...
  Failed. Returned data: id=0x0000, rev=0x0
Probing for ITE Super I/O (init=0x87,0x01,0x55,0x55/0xaa) at 0x4e...
  Failed. Returned data: id=0xffff, rev=0xf
Probing for ITE Super I/O (init=0x87,0x87) at 0x4e...
  Failed. Returned data: id=0xffff, rev=0xf
Probing for SMSC Super I/O (idregs=0x20/0x21) at 0x2e...
  Failed. Returned data: id=0x00, rev=0x00
Probing for SMSC Super I/O (idregs=0x0d/0x0e) at 0x2e...
  Failed. Returned data: id=0x7a, rev=0x00
Probing for SMSC Super I/O (idregs=0x20/0x21) at 0x4e...
  Failed. Returned data: id=0xff, rev=0xff
Probing for SMSC Super I/O (idregs=0x0d/0x0e) at 0x4e...
  Failed. Returned data: id=0xff, rev=0xff
Probing for SMSC Super I/O (idregs=0x20/0x21) at 0x3f0...
  Failed. Returned data: id=0xff, rev=0xff
Probing for SMSC Super I/O (idregs=0x0d/0x0e) at 0x3f0...
  Failed. Returned data: id=0xff, rev=0xff
Probing for SMSC Super I/O (idregs=0x20/0x21) at 0x370...
  Failed. Returned data: id=0xff, rev=0xff
Probing for SMSC Super I/O (idregs=0x0d/0x0e) at 0x370...
  Failed. Returned data: id=0xff, rev=0xff
Probing for Winbond Super I/O (init=0x88) at 0x2e...
  Failed. Returned data: id/oldid=0xff/0x0f, rev=0xff
Probing for Winbond Super I/O (init=0x89) at 0x2e...
  Failed. Returned data: id/oldid=0xff/0x0f, rev=0xff
Probing for Winbond Super I/O (init=0x86,0x86) at 0x2e...
  Failed. Returned data: id/oldid=0xff/0x0f, rev=0xff
Probing for Winbond Super I/O (init=0x87,0x87) at 0x2e...
  Failed. Returned data: id/oldid=0xff/0x0f, rev=0xff
Probing for Winbond Super I/O (init=0x88) at 0x4e...
  Failed. Returned data: id/oldid=0xff/0x0f, rev=0xff
Probing for Winbond Super I/O (init=0x89) at 0x4e...
  Failed. Returned data: id/oldid=0xff/0x0f, rev=0xff
Probing for Winbond Super I/O (init=0x86,0x86) at 0x4e...
  Failed. Returned data: id/oldid=0xff/0x0f, rev=0xff
Probing for Winbond Super I/O (init=0x87,0x87) at 0x4e...
  Failed. Returned data: id/oldid=0xff/0x0f, rev=0xff
Probing for Winbond Super I/O (init=0x88) at 0x3f0...
  Failed. Returned data: id/oldid=0xff/0x0f, rev=0xff
Probing for Winbond Super I/O (init=0x89) at 0x3f0...
  Failed. Returned data: id/oldid=0xff/0x0f, rev=0xff
Probing for Winbond Super I/O (init=0x86,0x86) at 0x3f0...
  Failed. Returned data: id/oldid=0xff/0x0f, rev=0xff
Probing for Winbond Super I/O (init=0x87,0x87) at 0x3f0...
  Failed. Returned data: id/oldid=0xff/0x0f, rev=0xff
Probing for Winbond Super I/O (init=0x88) at 0x370...
  Failed. Returned data: id/oldid=0xff/0x0f, rev=0xff
Probing for Winbond Super I/O (init=0x89) at 0x370...
  Failed. Returned data: id/oldid=0xff/0x0f, rev=0xff
Probing for Winbond Super I/O (init=0x86,0x86) at 0x370...
  Failed. Returned data: id/oldid=0xff/0x0f, rev=0xff
Probing for Winbond Super I/O (init=0x87,0x87) at 0x370...
  Failed. Returned data: id/oldid=0xff/0x0f, rev=0xff
Probing for Winbond Super I/O (init=0x88) at 0x250...
  Failed. Returned data: id/oldid=0xff/0x0f, rev=0xff
Probing for Winbond Super I/O (init=0x89) at 0x250...
  Failed. Returned data: id/oldid=0xff/0x0f, rev=0xff
Probing for Winbond Super I/O (init=0x86,0x86) at 0x250...
  Failed. Returned data: id/oldid=0xff/0x0f, rev=0xff
Probing for Winbond Super I/O (init=0x87,0x87) at 0x250...
  Failed. Returned data: id/oldid=0xff/0x0f, rev=0xff


Uwe.
-- 
http://www.hermann-uwe.de  | http://www.holsham-traders.de
http://www.crazy-hacks.org | http://www.unmaintained-free-software.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: superiotool_nsc_and_other_fixes.patch
Type: text/x-diff
Size: 9952 bytes
Desc: not available
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20071004/44900d29/attachment.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20071004/44900d29/attachment.sig>

From yinghailu at gmail.com  Thu Oct  4 03:18:13 2007
From: yinghailu at gmail.com (yhlu)
Date: Wed, 3 Oct 2007 18:18:13 -0700
Subject: [LinuxBIOS] [IMPORT] GIGABYTE GA-2761GXDK
In-Reply-To: <13426df10710031554u128792f5w69a67e90415bef12@mail.gmail.com>
References: <006b01c8058d$38dc52f0$0200a8c0@sis.com.tw>
	<Pine.LNX.4.64.0710030928160.3653@bigred.russwhit.org>
	<13426df10710031554u128792f5w69a67e90415bef12@mail.gmail.com>
Message-ID: <2ea3fae10710031818r417b7fb4v3c61898a393c815d@mail.gmail.com>

On 10/3/07, ron minnich <rminnich at gmail.com> wrote:
> On 10/3/07, Russell Whitaker <russ at ashlandhome.net> wrote:
> >
> >
> > On Wed, 3 Oct 2007, Morgan Tsai wrote:
> >
> > > Copyright (C) 2007 Morgan Tsai <my_tsai at sis.com>
> > > Copyright (C) 2007 Silicon Integrated Systems Corp. (SiS)
> > >
> >
> > Also, your email of Sept 21 has same copyright notice.
> >
> > I believe contributions to the Linuxbios project should be
> > released under the GPL.
>
> I went through the code and don't see any issues, since this copyright
> is only in the note.
>
> I think Morgan and SiS are doing a fine job here.
>
> But, Morgan, don't you want to get your name and SiS name in the
> various files? All the GPL headers are there, but they don't mention
> either of you.
>
> I can try to rework this as a patch but it might be better if you do
> this instead.

there is some cleanup need to do:

1. some code is in nb, may need to move to SB
2. some mcp55 etc need to replace...
3. some unneeded files need to be delete...

I think we need to SIS to do the clean at first...

YH



From bishop.robinson at gmail.com  Thu Oct  4 04:10:34 2007
From: bishop.robinson at gmail.com (Robinson Tryon)
Date: Wed, 3 Oct 2007 22:10:34 -0400
Subject: [LinuxBIOS] Call for help: superiotool
In-Reply-To: <20071003024031.GC6851@greenwood>
References: <20070923111315.GC12926@greenwood>
	<a698c16a0709270921l860615dv3ebe8d49e2f4c791@mail.gmail.com>
	<46FBDB3E.4000009@gmx.net>
	<a698c16a0710012034i25dec2deq1a07b8eb570f3d97@mail.gmail.com>
	<20071003024031.GC6851@greenwood>
Message-ID: <a698c16a0710031910t1499df9fic456e4cbe5a510c0@mail.gmail.com>

On 10/2/07, Uwe Hermann <uwe at hermann-uwe.de> wrote:
> On Mon, Oct 01, 2007 at 11:34:05PM -0400, Robinson Tryon wrote:
> > System Information
> >         Manufacturer: Dell Computer Corporation
> >         Product Name: OptiPlex GX1 400MTbr+
> >
> > # ./superiotool -v
> > superiotool r2815?2@
> > # ./superiotool -V
> > Probing for ALi Super I/O at 0x3f0... failed
> > Probing for ALi Super I/O at 0x370... failed
> > Super I/O found at 0x2e: id = 0xe0
> > <unknown>
> > No dump for 0xe0
>
> This _might_ be the NSC PC87309 chip. No support yet,
> but the NSC code needs a rewrite to make it more generic anyway.
>
> Can you look at the mainboard and find out which chip it actually is?

sure -- it'll be a couple days until I can get to it and crack it open, though.



From uwe at hermann-uwe.de  Thu Oct  4 04:22:02 2007
From: uwe at hermann-uwe.de (Uwe Hermann)
Date: Thu, 4 Oct 2007 04:22:02 +0200
Subject: [LinuxBIOS] Call for help: superiotool
In-Reply-To: <20071002152938.084fdaef.rasmus@wiman.org>
References: <20070923111315.GC12926@greenwood>
	<20071002152938.084fdaef.rasmus@wiman.org>
Message-ID: <20071004022202.GA30344@greenwood>

On Tue, Oct 02, 2007 at 03:29:38PM +0200, Rasmus Wiman wrote:
> Here comes a few:
> Mainboard: Asus N4L-VM DH (945GM board with socket 479)
> 
> Found Winbond W83627EHF/EF/EHG/EG (id=0x88, rev=0x63) at 0x2e
> Register dump:
> idx 20 21 22 23 24 25 26 27 28 29 2a 2b 2c 2d 2e 2f 
> val 88 63 ff 00 44 00 00 ff 50 04 00 00 9a 21 00 ff 
> def 88 MM ff 00 MM 00 MM RR 50 04 00 RR 00 21 00 00 
> LDN 0x00 (Floppy)
> idx 30 60 61 70 74 f0 f1 f2 f4 f5 
> val 00 03 f0 06 02 0e 00 ff 00 00 
> def 01 03 f0 06 02 8e 00 ff 00 00 
> LDN 0x01 (Parallel port)
> idx 30 60 61 70 74 f0 
> val 00 03 78 00 04 3c 
> def 01 03 78 07 04 3f 
> LDN 0x02 (COM1)
> idx 30 60 61 70 f0 
> val 00 03 f8 04 00 
> def 01 03 f8 04 00 
> LDN 0x03 (COM2)
> idx 30 60 61 70 f0 f1 
> val 00 02 f8 03 00 00 
> def 01 02 f8 03 00 00 
> LDN 0x05 (Keyboard)
> idx 30 60 61 62 63 70 72 f0 
> val 01 00 60 00 64 01 0c 83 
> def 01 00 60 00 64 01 0c 83 
> LDN 0x06 (Serial flash interface)
> idx 30 62 63 
> val 00 ff ff 
> def 00 00 00 
> LDN 0x07 (GPIO 1, GPIO 6, game port, MIDI port)
> idx 30 60 61 62 63 70 f0 f1 f2 f3 f4 f5 f6 f7 
> val 00 02 01 03 30 00 ff ff ff ff ff ff ff 00 
> def 00 02 01 03 30 09 ff 00 00 00 ff 00 00 00 
> LDN 0x08 (WDTO#, PLED)
> idx 30 f5 f6 f7 
> val 00 ff 00 ff 
> def 00 00 00 00 
> LDN 0x09 (GPIO 2, GPIO 3, GPIO 4, GPIO 5, SUSLED)
> idx 30 e0 e1 e2 e3 e4 e5 f0 f1 f2 f3 f4 f5 f6 f7 
> val 0f ff 21 00 ff 08 00 ff 0c 00 09 9f ff 00 00 
> def 00 ff 00 00 ff 00 00 ff 00 00 00 ff 00 00 00 
> LDN 0x0a (ACPI)
> idx 30 70 e0 e1 e2 e3 e4 e5 e6 e7 e8 f2 f3 f4 f6 f7 
> val 01 00 00 00 ff 00 40 02 0c 10 09 7d 00 00 00 00 
> def 00 00 01 00 ff 08 00 RR 00 00 RR 7c 00 00 00 00 
> LDN 0x0b (Hardware monitor)
> idx 30 60 61 70 f0 f1 
> val 01 02 90 00 c1 3f 
> def 00 00 00 00 c1 00

Thanks, added a link to the wiki.

 
> Mainboard: MSI K7T266 PRO2 (MS-6380 v2.0)
> Found Winbond W83627HF/F/HG/G (id=0x52, rev=0x17) at 0x2e
> No dump available for this Super I/O

If you want to, feel free to grab the datasheet and add dump support.
Nothing complex, just a bit time-consuming...


> I also ran superiotool on an Asus L8400 laptop and a HP compaq d530 sff
> desktop, but it did not detect any super I/O. Opening up the HP
> revealed an SMSC LPC47B387-NC, I feel a bit reluctant to take the
> laptop apart.

Interesting. I can't find a datasheet for the LPC47B387, so dump support
won't happen anytime soon. But it would be nice if you could re-run
'superiotool -V' on that box with my latest patch applied
([PATCH] superiotool: Various improvements). That should tell us the
Super I/O ID, I hope, so we can at least detect the chip.


Uwe.
-- 
http://www.hermann-uwe.de  | http://www.holsham-traders.de
http://www.crazy-hacks.org | http://www.unmaintained-free-software.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20071004/63cc5656/attachment.sig>

From my_tsai at sis.com  Thu Oct  4 04:28:46 2007
From: my_tsai at sis.com (Morgan Tsai)
Date: Thu, 4 Oct 2007 10:28:46 +0800
Subject: [LinuxBIOS] [IMPORT] GIGABYTE GA-2761GXDK
References: <006b01c8058d$38dc52f0$0200a8c0@sis.com.tw>
	<Pine.LNX.4.64.0710030928160.3653@bigred.russwhit.org>
Message-ID: <001d01c8062e$4cdbbab0$0200a8c0@sis.com.tw>

Dear Russ,

Can you help me how to write the correct License declaration?
It's the first time for me to publish our code under the GPL.
Could you show a example here?


Thanks for your help!



Morgan

----- Original Message ----- 
From: "Russell Whitaker" <russ at ashlandhome.net>
To: "Morgan Tsai" <my_tsai at sis.com>
Cc: <linuxbios at linuxbios.org>; "'Dennis Chang /SiS'" <ktchang at sis.com>; 
"Eric Lin" <ericlin at sis.com>
Sent: Thursday, October 04, 2007 12:38 AM
Subject: <Spam>Re: [LinuxBIOS] [IMPORT] GIGABYTE GA-2761GXDK


>
>
> On Wed, 3 Oct 2007, Morgan Tsai wrote:
>
>> Copyright (C) 2007 Morgan Tsai <my_tsai at sis.com>
>> Copyright (C) 2007 Silicon Integrated Systems Corp. (SiS)
>>
>
> Also, your email of Sept 21 has same copyright notice.
>
> I believe contributions to the Linuxbios project should be
> released under the GPL.
>
> Not trying to start a flame war. Just trying to prevent
> problems that might occur later.
>
>   Russ 




From echelon at free.fr  Thu Oct  4 05:32:21 2007
From: echelon at free.fr (echelon at free.fr)
Date: Thu, 04 Oct 2007 05:32:21 +0200
Subject: [LinuxBIOS] badly initialized (?) pci bridge on the M57SLI
	(with irq table and mptable)
In-Reply-To: <1190858035.46fb0d33df9c7@imp.free.fr>
References: <20070917004727.GA7533@localdomain>
	<2ea3fae10709171549i2e318712i9859db93fd305551@mail.gmail.com>
	<1190077673.46ef24e954d99@imp.free.fr>
	<20070919212952.GA16399@localdomain>
	<2ea3fae10709191629w17affbaeh4daf8a0715737ad2@mail.gmail.com>
	<1190278384.46f234f055fc2@imp.free.fr>
	<2ea3fae10709200944o6ebbc89p74ddd188db4826e1@mail.gmail.com>
	<20070924213615.GB26022@greenwood>
	<2ea3fae10709241623l1b579378td2605ddad12be414@mail.gmail.com>
	<1190713007.46f8d6af1483e@imp.free.fr>
	<2ea3fae10709251226x4098fce2o56d61dbec6af9447@mail.gmail.com>
	<1190858035.46fb0d33df9c7@imp.free.fr>
Message-ID: <1191468741.47045ec51281d@imp.free.fr>

I propose:

$(LB)/src/mainboard/gigabyte/m57sli/cache_as_ram_auto.c
138c138
<  RES_PORT_IO_8, SYSCTRL_IO_BASE + 0xc0+38, 0x00, 0x44,/* GPIO39 PCI_GNT3 */ \
---
>  RES_PORT_IO_8, SYSCTRL_IO_BASE + 0xc0+38, 0x00, 0x68,/* GPIO39 PCI_GNT3 */ \

My vga pci card and a pci network card are recognised with this under LinuxBIOS!
I don't understand why this works, but it works..
(I will explain tomorrow how I found this value)

Please can someone validate my change?

Regards,
  Florentin

Quoting echelon at free.fr:

> Hi,
>
> Quoting yhlu <yinghailu at gmail.com>:
>
> > On 9/25/07, echelon at free.fr <echelon at free.fr> wrote:
> > > Hi,
> > > This fix still doesn't work for m57sli v2.0..
> > > As promised, I send a log with :
> > >  - full debugging log in LinuxBIOS;
> >
> > Please only set log_level to 8...
> >
> > >  - Linux boot messages;
> > >  - the result of a "lspci -vvv" command (inclused at the end of the file
> <=
> > the
> > > test was done with the PCI VGA card installed into a PCI slot);
> > lspci -vvxxx
> > lspci -tv
> > are good.
>
> Please find the results of these commands in the attached files (done with a
> updated version of LinuxBIOS - i.e. after your patch was applied)
> I add the result of the command "lspci -xxx" under the award bios for
> reference..
>
> > >  - the result of the command "setpci -s 00:01.0 78.l"
> > ?, you already did that in LinuxBIOS?
>
> Sorry I don't understand the question.. Do you mean that "setpci" was
> executed
> after I updated LB? Yes, it was!..
>
> Florentin
>





From uwe at hermann-uwe.de  Thu Oct  4 04:58:51 2007
From: uwe at hermann-uwe.de (Uwe Hermann)
Date: Thu, 4 Oct 2007 04:58:51 +0200
Subject: [LinuxBIOS] [IMPORT] GIGABYTE GA-2761GXDK
In-Reply-To: <001d01c8062e$4cdbbab0$0200a8c0@sis.com.tw>
References: <006b01c8058d$38dc52f0$0200a8c0@sis.com.tw>
	<Pine.LNX.4.64.0710030928160.3653@bigred.russwhit.org>
	<001d01c8062e$4cdbbab0$0200a8c0@sis.com.tw>
Message-ID: <20071004025851.GA32267@greenwood>

Hi,

first of all -- thanks a lot for your code contribution!
This is really great!


On Thu, Oct 04, 2007 at 10:28:46AM +0800, Morgan Tsai wrote:
> Can you help me how to write the correct License declaration?
> It's the first time for me to publish our code under the GPL.
> Could you show a example here?

For LinuxBIOS we use the same common header everywhere:

http://linuxbios.org/index.php/Development_Guidelines#Common_License_Header

So in your case something like this:


/*
 * This file is part of the LinuxBIOS project.
 *
 * Copyright (C) 2007 Silicon Integrated Systems Corp. (SiS)
 * (Written by Morgan Tsai <my_tsai at sis.com> for SiS)
 *
 * This program is free software; you can redistribute it and/or modify
 * it under the terms of the GNU General Public License as published by
 * the Free Software Foundation; either version 2 of the License, or
 * (at your option) any later version.
 *
 * This program is distributed in the hope that it will be useful,
 * but WITHOUT ANY WARRANTY; without even the implied warranty of
 * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
 * GNU General Public License for more details.
 *
 * You should have received a copy of the GNU General Public License
 * along with this program; if not, write to the Free Software
 * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA  02110-1301 USA
 */

I assume you wrote the code (during working time) for SiS, so I guess
the copyright belongs to SiS, the license is the GPL (version 2 or
later), though. Is this correct?

Every file should have this license header, with all the copyright
owners listed. Files you wrote yourself from scratch (or very trivial
files such as chip.h) are 'Copyright (C) 2007 SiS'.

Code which is heavily based on already existing code should retain the
original copyright owner, but you add SiS as additional copyright owner
if the changes made by SiS are non-trivial. Example:

/*
 * This file is part of the LinuxBIOS project.
 *
 * Copyright (C) 2007 AMD
 * (Written by Yinghai Lu <yinghailu at amd.com> for AMD)
 * Copyright (C) 2007 Silicon Integrated Systems Corp. (SiS)
 * (Written by Morgan Tsai <my_tsai at sis.com> for SiS)
 *
 * This program is free software; you can redistribute it and/or modify
 * it under the terms of the GNU General Public License as published by
 * the Free Software Foundation; either version 2 of the License, or
 * (at your option) any later version.
 *
 * This program is distributed in the hope that it will be useful,
 * but WITHOUT ANY WARRANTY; without even the implied warranty of
 * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
 * GNU General Public License for more details.
 *
 * You should have received a copy of the GNU General Public License
 * along with this program; if not, write to the Free Software
 * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA  02110-1301 USA
 */

Hope that helps...

I'll review the code more thoroughly tomorrow or so and provide some
more suggestions for improvements. I hope we can commit this code
soonish, this is very good news.

Are there any existing mainstream boards which can use this code
already? Stuff you can buy in computer shops, not prototype boards?


Thanks, Uwe.
-- 
http://www.hermann-uwe.de  | http://www.holsham-traders.de
http://www.crazy-hacks.org | http://www.unmaintained-free-software.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20071004/2e404305/attachment.sig>

From yinghailu at gmail.com  Thu Oct  4 05:18:25 2007
From: yinghailu at gmail.com (yhlu)
Date: Wed, 3 Oct 2007 20:18:25 -0700
Subject: [LinuxBIOS] badly initialized (?) pci bridge on the M57SLI
	(with irq table and mptable)
In-Reply-To: <1191468741.47045ec51281d@imp.free.fr>
References: <20070917004727.GA7533@localdomain>
	<2ea3fae10709191629w17affbaeh4daf8a0715737ad2@mail.gmail.com>
	<1190278384.46f234f055fc2@imp.free.fr>
	<2ea3fae10709200944o6ebbc89p74ddd188db4826e1@mail.gmail.com>
	<20070924213615.GB26022@greenwood>
	<2ea3fae10709241623l1b579378td2605ddad12be414@mail.gmail.com>
	<1190713007.46f8d6af1483e@imp.free.fr>
	<2ea3fae10709251226x4098fce2o56d61dbec6af9447@mail.gmail.com>
	<1190858035.46fb0d33df9c7@imp.free.fr>
	<1191468741.47045ec51281d@imp.free.fr>
Message-ID: <2ea3fae10710032018g34790ccfwdca480f561e4cead@mail.gmail.com>

On 10/3/07, echelon at free.fr <echelon at free.fr> wrote:
> I propose:
>
> $(LB)/src/mainboard/gigabyte/m57sli/cache_as_ram_auto.c
> 138c138
> <  RES_PORT_IO_8, SYSCTRL_IO_BASE + 0xc0+38, 0x00, 0x44,/* GPIO39 PCI_GNT3 */ \
> ---
> >  RES_PORT_IO_8, SYSCTRL_IO_BASE + 0xc0+38, 0x00, 0x68,/* GPIO39 PCI_GNT3 */ \
>
> My vga pci card and a pci network card are recognised with this under LinuxBIOS!
> I don't understand why this works, but it works..
> (I will explain tomorrow how I found this value)

wow!

with dumpio?

YH



From russ at ashlandhome.net  Thu Oct  4 05:36:47 2007
From: russ at ashlandhome.net (Russell Whitaker)
Date: Wed, 3 Oct 2007 20:36:47 -0700 (PDT)
Subject: [LinuxBIOS] [IMPORT] GIGABYTE GA-2761GXDK
In-Reply-To: <001d01c8062e$4cdbbab0$0200a8c0@sis.com.tw>
References: <006b01c8058d$38dc52f0$0200a8c0@sis.com.tw>
	<Pine.LNX.4.64.0710030928160.3653@bigred.russwhit.org>
	<001d01c8062e$4cdbbab0$0200a8c0@sis.com.tw>
Message-ID: <Pine.LNX.4.64.0710032029380.2552@bigred.russwhit.org>



On Thu, 4 Oct 2007, Morgan Tsai wrote:

> Dear Russ,
>
> Can you help me how to write the correct License declaration?
> It's the first time for me to publish our code under the GPL.
> Could you show a example here?
>
By now you should have received Uwe's email. He did a better job
of answering your question than I could.

With a quick look found two files without a licence header.
Suspect the files you need to look for all have a 2007 date.

   Russ



From corey.osgood at gmail.com  Thu Oct  4 05:50:36 2007
From: corey.osgood at gmail.com (Corey Osgood)
Date: Wed, 03 Oct 2007 23:50:36 -0400
Subject: [LinuxBIOS] Problems with Filo booting - HELP
In-Reply-To: <20071003190457.a6hta1e4kk8w0wwc@www.smittys.pointclark.net>
References: <20070929165103.pcm220bn4s48sow8@smittys.pointclark.net>	<20070929205527.GA16584@coresystems.de>	<20070929170245.ata0hgegqowgcwgs@www.smittys.pointclark.net>	<20070929201342.mifqbujb44ocwks8@smittys.pointclark.net>	<46FF1CB2.60901@gmail.com>	<20070930115720.mwni4u7go4wkk8wg@www.smittys.pointclark.net>	<47000290.6020000@gmail.com>	<20071001094827.loois4qr0g4ckw8o@www.smittys.pointclark.net>	<13426df10710010950s379f8230y5b4ffec4da605f06@mail.gmail.com>	<20071001165858.vlz66uxpusgk0gww@www.smittys.pointclark.net>	<47017223.6010504@gmail.com>
	<20071003190457.a6hta1e4kk8w0wwc@www.smittys.pointclark.net>
Message-ID: <4704630C.8060803@gmail.com>

joe at smittys.pointclark.net wrote:
> Quoting Corey Osgood <corey.osgood at gmail.com>:
>
>> joe at smittys.pointclark.net wrote:
>>> Quoting ron minnich <rminnich at gmail.com>:
>>>
>>>
>>>> you might try forcing the size (in code) to 32M or some such in
>>>> hardwaremain.c and see if it works then. There's  something odd with
>>>> your ram.
>>>>
>>>> ron
>>>>
>>>>
>>> It won't have anything to do with the fact that:
>>>
>>> a. It is onboard 128MB memory
>>> b. It doesn't have a SPD module
>>> c. It is located in the second slot not first.
>>>
>>
>> It shouldn't, no, especially not the first 2.
>>
>>> This is wierd because it passes the ram_check() from auto.c earlier in
>>> the process just fine.
>>>
>>> /* Check RAM. */
>>> ram_check(0, 640 * 1024);
>>>
>>> Thanks - Joe
>>
>> All that's checking is the first 640K. To check the rest of the memory,
>> use ram_check(1024*1024, 1024*1024*128), starting at 1mb to avoid any
>> reserved areas. Make sure your ram_resource() calls also avoids those
>> reserved areas.
>>
>> -Corey
>>
> Ok, I think I figured out what is going on here. The ram_check from
> 0-640K works fine. But ram_check from 1MB-128MB fails. My DRB
> registers are set correctly, and report 128MB of memory. Why? That is
> the golden question of the year. Can anyone help out a thinning hair
> (from pulling out - stress related) guy in desperate need?
>
> Thanks - Joe
>

Where does it fail? What address(es) does it start to fail at? Does it
return junk (but semi-coherent) values or NULL/zeros? Knowing exactly
where the ram goes from good to bad could help find the start of the
problem.

-Corey



From joe at smittys.pointclark.net  Thu Oct  4 06:26:39 2007
From: joe at smittys.pointclark.net (joe at smittys.pointclark.net)
Date: Thu, 04 Oct 2007 00:26:39 -0400
Subject: [LinuxBIOS] Problems with Filo booting - HELP
In-Reply-To: <4704630C.8060803@gmail.com>
References: <20070929165103.pcm220bn4s48sow8@smittys.pointclark.net>
	<20070929205527.GA16584@coresystems.de>
	<20070929170245.ata0hgegqowgcwgs@www.smittys.pointclark.net>
	<20070929201342.mifqbujb44ocwks8@smittys.pointclark.net>
	<46FF1CB2.60901@gmail.com>
	<20070930115720.mwni4u7go4wkk8wg@www.smittys.pointclark.net>
	<47000290.6020000@gmail.com>
	<20071001094827.loois4qr0g4ckw8o@www.smittys.pointclark.net>
	<13426df10710010950s379f8230y5b4ffec4da605f06@mail.gmail.com>
	<20071001165858.vlz66uxpusgk0gww@www.smittys.pointclark.net>
	<47017223.6010504@gmail.com>
	<20071003190457.a6hta1e4kk8w0wwc@www.smittys.pointclark.net>
	<4704630C.8060803@gmail.com>
Message-ID: <20071004002639.o29oeiku4g84w4g8@www.smittys.pointclark.net>

Quoting Corey Osgood <corey.osgood at gmail.com>:

> joe at smittys.pointclark.net wrote:
>> Quoting Corey Osgood <corey.osgood at gmail.com>:
>>
>>> joe at smittys.pointclark.net wrote:
>>>> Quoting ron minnich <rminnich at gmail.com>:
>>>>
>>>>
>>>>> you might try forcing the size (in code) to 32M or some such in
>>>>> hardwaremain.c and see if it works then. There's  something odd with
>>>>> your ram.
>>>>>
>>>>> ron
>>>>>
>>>>>
>>>> It won't have anything to do with the fact that:
>>>>
>>>> a. It is onboard 128MB memory
>>>> b. It doesn't have a SPD module
>>>> c. It is located in the second slot not first.
>>>>
>>>
>>> It shouldn't, no, especially not the first 2.
>>>
>>>> This is wierd because it passes the ram_check() from auto.c earlier in
>>>> the process just fine.
>>>>
>>>> /* Check RAM. */
>>>> ram_check(0, 640 * 1024);
>>>>
>>>> Thanks - Joe
>>>
>>> All that's checking is the first 640K. To check the rest of the memory,
>>> use ram_check(1024*1024, 1024*1024*128), starting at 1mb to avoid any
>>> reserved areas. Make sure your ram_resource() calls also avoids those
>>> reserved areas.
>>>
>>> -Corey
>>>
>> Ok, I think I figured out what is going on here. The ram_check from
>> 0-640K works fine. But ram_check from 1MB-128MB fails. My DRB
>> registers are set correctly, and report 128MB of memory. Why? That is
>> the golden question of the year. Can anyone help out a thinning hair
>> (from pulling out - stress related) guy in desperate need?
>>
>> Thanks - Joe
>>
>
> Where does it fail? What address(es) does it start to fail at? Does it
> return junk (but semi-coherent) values or NULL/zeros? Knowing exactly
> where the ram goes from good to bad could help find the start of the
> problem.
>
> -Corey
>
Here is my ram_check from 1-128MB. It appears to fill the ram ok. But  
only returns a value of 0xffffffff. Does this mean the ram is WO  
(write only) for some reason? Thanks again for your help.


Thanks - Joe

Testing DRAM : 00100000-08000000
DRAM fill: 00100000-08000000
00100000
00110000
00120000
00130000
00140000
00150000
00160000
00170000
00180000
00190000
001a0000
001b0000
001c0000
001d0000
001e0000
001f0000
00200000
00210000
00220000
00230000
00240000
00250000
00260000
00270000
00280000
00290000
002a0000
002b0000
002c0000
002d0000
002e0000
002f0000
00300000
00310000
00320000
00330000
00340000
00350000
00360000
00370000
00380000
00390000
003a0000
003b0000
003c0000
003d0000
003e0000
003f0000
00400000
00410000
00420000
00430000
00440000
00450000
00460000
00470000
00480000
00490000
004a0000
004b0000
004c0000
004d0000
004e0000
004f0000
00500000
00510000
00520000
00530000
00540000
00550000
00560000
00570000
00580000
00590000
005a0000
005b0000
005c0000
005d0000
005e0000
005f0000
00600000
00610000
00620000
00630000
00640000
00650000
00660000
00670000
00680000
00690000
006a0000
006b0000
006c0000
006d0000
006e0000
006f0000
00700000
00710000
00720000
00730000
00740000
00750000
00760000
00770000
00780000
00790000
007a0000
007b0000
007c0000
007d0000
007e0000
007f0000
00800000
00810000
00820000
00830000
00840000
00850000
00860000
00870000
00880000
00890000
008a0000
008b0000
008c0000
008d0000
008e0000
008f0000
00900000
00910000
00920000
00930000
00940000
00950000
00960000
00970000
00980000
00990000
009a0000
009b0000
009c0000
009d0000
009e0000
009f0000
00a00000
00a10000
00a20000
00a30000
00a40000
00a50000
00a60000
00a70000
00a80000
00a90000
00aa0000
00ab0000
00ac0000
00ad0000
00ae0000
00af0000
00b00000
00b10000
00b20000
00b30000
00b40000
00b50000
00b60000
00b70000
00b80000
00b90000
00ba0000
00bb0000
00bc0000
00bd0000
00be0000
00bf0000
00c00000
00c10000
00c20000
00c30000
00c40000
00c50000
00c60000
00c70000
00c80000
00c90000
00ca0000
00cb0000
00cc0000
00cd0000
00ce0000
00cf0000
00d00000
00d10000
00d20000
00d30000
00d40000
00d50000
00d60000
00d70000
00d80000
00d90000
00da0000
00db0000
00dc0000
00dd0000
00de0000
00df0000
00e00000
00e10000
00e20000
00e30000
00e40000
00e50000
00e60000
00e70000
00e80000
00e90000
00ea0000
00eb0000
00ec0000
00ed0000
00ee0000
00ef0000
00f00000
00f10000
00f20000
00f30000
00f40000
00f50000
00f60000
00f70000
00f80000
00f90000
00fa0000
00fb0000
00fc0000
00fd0000
00fe0000
00ff0000
01000000
01010000
01020000
01030000
01040000
01050000
01060000
01070000
01080000
01090000
010a0000
010b0000
010c0000
010d0000
010e0000
010f0000
01100000
01110000
01120000
01130000
01140000
01150000
01160000
01170000
01180000
01190000
011a0000
011b0000
011c0000
011d0000
011e0000
011f0000
01200000
01210000
01220000
01230000
01240000
01250000
01260000
01270000
01280000
01290000
012a0000
012b0000
012c0000
012d0000
012e0000
012f0000
01300000
01310000
01320000
01330000
01340000
01350000
01360000
01370000
01380000
01390000
013a0000
013b0000
013c0000
013d0000
013e0000
013f0000
01400000
01410000
01420000
01430000
01440000
01450000
01460000
01470000
01480000
01490000
014a0000
014b0000
014c0000
014d0000
014e0000
014f0000
01500000
01510000
01520000
01530000
01540000
01550000
01560000
01570000
01580000
01590000
015a0000
015b0000
015c0000
015d0000
015e0000
015f0000
01600000
01610000
01620000
01630000
01640000
01650000
01660000
01670000
01680000
01690000
016a0000
016b0000
016c0000
016d0000
016e0000
016f0000
01700000
01710000
01720000
01730000
01740000
01750000
01760000
01770000
01780000
01790000
017a0000
017b0000
017c0000
017d0000
017e0000
017f0000
01800000
01810000
01820000
01830000
01840000
01850000
01860000
01870000
01880000
01890000
018a0000
018b0000
018c0000
018d0000
018e0000
018f0000
01900000
01910000
01920000
01930000
01940000
01950000
01960000
01970000
01980000
01990000
019a0000
019b0000
019c0000
019d0000
019e0000
019f0000
01a00000
01a10000
01a20000
01a30000
01a40000
01a50000
01a60000
01a70000
01a80000
01a90000
01aa0000
01ab0000
01ac0000
01ad0000
01ae0000
01af0000
01b00000
01b10000
01b20000
01b30000
01b40000
01b50000
01b60000
01b70000
01b80000
01b90000
01ba0000
01bb0000
01bc0000
01bd0000
01be0000
01bf0000
01c00000
01c10000
01c20000
01c30000
01c40000
01c50000
01c60000
01c70000
01c80000
01c90000
01ca0000
01cb0000
01cc0000
01cd0000
01ce0000
01cf0000
01d00000
01d10000
01d20000
01d30000
01d40000
01d50000
01d60000
01d70000
01d80000
01d90000
01da0000
01db0000
01dc0000
01dd0000
01de0000
01df0000
01e00000
01e10000
01e20000
01e30000
01e40000
01e50000
01e60000
01e70000
01e80000
01e90000
01ea0000
01eb0000
01ec0000
01ed0000
01ee0000
01ef0000
01f00000
01f10000
01f20000
01f30000
01f40000
01f50000
01f60000
01f70000
01f80000
01f90000
01fa0000
01fb0000
01fc0000
01fd0000
01fe0000
01ff0000
02000000
02010000
02020000
02030000
02040000
02050000
02060000
02070000
02080000
02090000
020a0000
020b0000
020c0000
020d0000
020e0000
020f0000
02100000
02110000
02120000
02130000
02140000
02150000
02160000
02170000
02180000
02190000
021a0000
021b0000
021c0000
021d0000
021e0000
021f0000
02200000
02210000
02220000
02230000
02240000
02250000
02260000
02270000
02280000
02290000
022a0000
022b0000
022c0000
022d0000
022e0000
022f0000
02300000
02310000
02320000
02330000
02340000
02350000
02360000
02370000
02380000
02390000
023a0000
023b0000
023c0000
023d0000
023e0000
023f0000
02400000
02410000
02420000
02430000
02440000
02450000
02460000
02470000
02480000
02490000
024a0000
024b0000
024c0000
024d0000
024e0000
024f0000
02500000
02510000
02520000
02530000
02540000
02550000
02560000
02570000
02580000
02590000
025a0000
025b0000
025c0000
025d0000
025e0000
025f0000
02600000
02610000
02620000
02630000
02640000
02650000
02660000
02670000
02680000
02690000
026a0000
026b0000
026c0000
026d0000
026e0000
026f0000
02700000
02710000
02720000
02730000
02740000
02750000
02760000
02770000
02780000
02790000
027a0000
027b0000
027c0000
027d0000
027e0000
027f0000
02800000
02810000
02820000
02830000
02840000
02850000
02860000
02870000
02880000
02890000
028a0000
028b0000
028c0000
028d0000
028e0000
028f0000
02900000
02910000
02920000
02930000
02940000
02950000
02960000
02970000
02980000
02990000
029a0000
029b0000
029c0000
029d0000
029e0000
029f0000
02a00000
02a10000
02a20000
02a30000
02a40000
02a50000
02a60000
02a70000
02a80000
02a90000
02aa0000
02ab0000
02ac0000
02ad0000
02ae0000
02af0000
02b00000
02b10000
02b20000
02b30000
02b40000
02b50000
02b60000
02b70000
02b80000
02b90000
02ba0000
02bb0000
02bc0000
02bd0000
02be0000
02bf0000
02c00000
02c10000
02c20000
02c30000
02c40000
02c50000
02c60000
02c70000
02c80000
02c90000
02ca0000
02cb0000
02cc0000
02cd0000
02ce0000
02cf0000
02d00000
02d10000
02d20000
02d30000
02d40000
02d50000
02d60000
02d70000
02d80000
02d90000
02da0000
02db0000
02dc0000
02dd0000
02de0000
02df0000
02e00000
02e10000
02e20000
02e30000
02e40000
02e50000
02e60000
02e70000
02e80000
02e90000
02ea0000
02eb0000
02ec0000
02ed0000
02ee0000
02ef0000
02f00000
02f10000
02f20000
02f30000
02f40000
02f50000
02f60000
02f70000
02f80000
02f90000
02fa0000
02fb0000
02fc0000
02fd0000
02fe0000
02ff0000
03000000
03010000
03020000
03030000
03040000
03050000
03060000
03070000
03080000
03090000
030a0000
030b0000
030c0000
030d0000
030e0000
030f0000
03100000
03110000
03120000
03130000
03140000
03150000
03160000
03170000
03180000
03190000
031a0000
031b0000
031c0000
031d0000
031e0000
031f0000
03200000
03210000
03220000
03230000
03240000
03250000
03260000
03270000
03280000
03290000
032a0000
032b0000
032c0000
032d0000
032e0000
032f0000
03300000
03310000
03320000
03330000
03340000
03350000
03360000
03370000
03380000
03390000
033a0000
033b0000
033c0000
033d0000
033e0000
033f0000
03400000
03410000
03420000
03430000
03440000
03450000
03460000
03470000
03480000
03490000
034a0000
034b0000
034c0000
034d0000
034e0000
034f0000
03500000
03510000
03520000
03530000
03540000
03550000
03560000
03570000
03580000
03590000
035a0000
035b0000
035c0000
035d0000
035e0000
035f0000
03600000
03610000
03620000
03630000
03640000
03650000
03660000
03670000
03680000
03690000
036a0000
036b0000
036c0000
036d0000
036e0000
036f0000
03700000
03710000
03720000
03730000
03740000
03750000
03760000
03770000
03780000
03790000
037a0000
037b0000
037c0000
037d0000
037e0000
037f0000
03800000
03810000
03820000
03830000
03840000
03850000
03860000
03870000
03880000
03890000
038a0000
038b0000
038c0000
038d0000
038e0000
038f0000
03900000
03910000
03920000
03930000
03940000
03950000
03960000
03970000
03980000
03990000
039a0000
039b0000
039c0000
039d0000
039e0000
039f0000
03a00000
03a10000
03a20000
03a30000
03a40000
03a50000
03a60000
03a70000
03a80000
03a90000
03aa0000
03ab0000
03ac0000
03ad0000
03ae0000
03af0000
03b00000
03b10000
03b20000
03b30000
03b40000
03b50000
03b60000
03b70000
03b80000
03b90000
03ba0000
03bb0000
03bc0000
03bd0000
03be0000
03bf0000
03c00000
03c10000
03c20000
03c30000
03c40000
03c50000
03c60000
03c70000
03c80000
03c90000
03ca0000
03cb0000
03cc0000
03cd0000
03ce0000
03cf0000
03d00000
03d10000
03d20000
03d30000
03d40000
03d50000
03d60000
03d70000
03d80000
03d90000
03da0000
03db0000
03dc0000
03dd0000
03de0000
03df0000
03e00000
03e10000
03e20000
03e30000
03e40000
03e50000
03e60000
03e70000
03e80000
03e90000
03ea0000
03eb0000
03ec0000
03ed0000
03ee0000
03ef0000
03f00000
03f10000
03f20000
03f30000
03f40000
03f50000
03f60000
03f70000
03f80000
03f90000
03fa0000
03fb0000
03fc0000
03fd0000
03fe0000
03ff0000
04000000
04010000
04020000
04030000
04040000
04050000
04060000
04070000
04080000
04090000
040a0000
040b0000
040c0000
040d0000
040e0000
040f0000
04100000
04110000
04120000
04130000
04140000
04150000
04160000
04170000
04180000
04190000
041a0000
041b0000
041c0000
041d0000
041e0000
041f0000
04200000
04210000
04220000
04230000
04240000
04250000
04260000
04270000
04280000
04290000
042a0000
042b0000
042c0000
042d0000
042e0000
042f0000
04300000
04310000
04320000
04330000
04340000
04350000
04360000
04370000
04380000
04390000
043a0000
043b0000
043c0000
043d0000
043e0000
043f0000
04400000
04410000
04420000
04430000
04440000
04450000
04460000
04470000
04480000
04490000
044a0000
044b0000
044c0000
044d0000
044e0000
044f0000
04500000
04510000
04520000
04530000
04540000
04550000
04560000
04570000
04580000
04590000
045a0000
045b0000
045c0000
045d0000
045e0000
045f0000
04600000
04610000
04620000
04630000
04640000
04650000
04660000
04670000
04680000
04690000
046a0000
046b0000
046c0000
046d0000
046e0000
046f0000
04700000
04710000
04720000
04730000
04740000
04750000
04760000
04770000
04780000
04790000
047a0000
047b0000
047c0000
047d0000
047e0000
047f0000
04800000
04810000
04820000
04830000
04840000
04850000
04860000
04870000
04880000
04890000
048a0000
048b0000
048c0000
048d0000
048e0000
048f0000
04900000
04910000
04920000
04930000
04940000
04950000
04960000
04970000
04980000
04990000
049a0000
049b0000
049c0000
049d0000
049e0000
049f0000
04a00000
04a10000
04a20000
04a30000
04a40000
04a50000
04a60000
04a70000
04a80000
04a90000
04aa0000
04ab0000
04ac0000
04ad0000
04ae0000
04af0000
04b00000
04b10000
04b20000
04b30000
04b40000
04b50000
04b60000
04b70000
04b80000
04b90000
04ba0000
04bb0000
04bc0000
04bd0000
04be0000
04bf0000
04c00000
04c10000
04c20000
04c30000
04c40000
04c50000
04c60000
04c70000
04c80000
04c90000
04ca0000
04cb0000
04cc0000
04cd0000
04ce0000
04cf0000
04d00000
04d10000
04d20000
04d30000
04d40000
04d50000
04d60000
04d70000
04d80000
04d90000
04da0000
04db0000
04dc0000
04dd0000
04de0000
04df0000
04e00000
04e10000
04e20000
04e30000
04e40000
04e50000
04e60000
04e70000
04e80000
04e90000
04ea0000
04eb0000
04ec0000
04ed0000
04ee0000
04ef0000
04f00000
04f10000
04f20000
04f30000
04f40000
04f50000
04f60000
04f70000
04f80000
04f90000
04fa0000
04fb0000
04fc0000
04fd0000
04fe0000
04ff0000
05000000
05010000
05020000
05030000
05040000
05050000
05060000
05070000
05080000
05090000
050a0000
050b0000
050c0000
050d0000
050e0000
050f0000
05100000
05110000
05120000
05130000
05140000
05150000
05160000
05170000
05180000
05190000
051a0000
051b0000
051c0000
051d0000
051e0000
051f0000
05200000
05210000
05220000
05230000
05240000
05250000
05260000
05270000
05280000
05290000
052a0000
052b0000
052c0000
052d0000
052e0000
052f0000
05300000
05310000
05320000
05330000
05340000
05350000
05360000
05370000
05380000
05390000
053a0000
053b0000
053c0000
053d0000
053e0000
053f0000
05400000
05410000
05420000
05430000
05440000
05450000
05460000
05470000
05480000
05490000
054a0000
054b0000
054c0000
054d0000
054e0000
054f0000
05500000
05510000
05520000
05530000
05540000
05550000
05560000
05570000
05580000
05590000
055a0000
055b0000
055c0000
055d0000
055e0000
055f0000
05600000
05610000
05620000
05630000
05640000
05650000
05660000
05670000
05680000
05690000
056a0000
056b0000
056c0000
056d0000
056e0000
056f0000
05700000
05710000
05720000
05730000
05740000
05750000
05760000
05770000
05780000
05790000
057a0000
057b0000
057c0000
057d0000
057e0000
057f0000
05800000
05810000
05820000
05830000
05840000
05850000
05860000
05870000
05880000
05890000
058a0000
058b0000
058c0000
058d0000
058e0000
058f0000
05900000
05910000
05920000
05930000
05940000
05950000
05960000
05970000
05980000
05990000
059a0000
059b0000
059c0000
059d0000
059e0000
059f0000
05a00000
05a10000
05a20000
05a30000
05a40000
05a50000
05a60000
05a70000
05a80000
05a90000
05aa0000
05ab0000
05ac0000
05ad0000
05ae0000
05af0000
05b00000
05b10000
05b20000
05b30000
05b40000
05b50000
05b60000
05b70000
05b80000
05b90000
05ba0000
05bb0000
05bc0000
05bd0000
05be0000
05bf0000
05c00000
05c10000
05c20000
05c30000
05c40000
05c50000
05c60000
05c70000
05c80000
05c90000
05ca0000
05cb0000
05cc0000
05cd0000
05ce0000
05cf0000
05d00000
05d10000
05d20000
05d30000
05d40000
05d50000
05d60000
05d70000
05d80000
05d90000
05da0000
05db0000
05dc0000
05dd0000
05de0000
05df0000
05e00000
05e10000
05e20000
05e30000
05e40000
05e50000
05e60000
05e70000
05e80000
05e90000
05ea0000
05eb0000
05ec0000
05ed0000
05ee0000
05ef0000
05f00000
05f10000
05f20000
05f30000
05f40000
05f50000
05f60000
05f70000
05f80000
05f90000
05fa0000
05fb0000
05fc0000
05fd0000
05fe0000
05ff0000
06000000
06010000
06020000
06030000
06040000
06050000
06060000
06070000
06080000
06090000
060a0000
060b0000
060c0000
060d0000
060e0000
060f0000
06100000
06110000
06120000
06130000
06140000
06150000
06160000
06170000
06180000
06190000
061a0000
061b0000
061c0000
061d0000
061e0000
061f0000
06200000
06210000
06220000
06230000
06240000
06250000
06260000
06270000
06280000
06290000
062a0000
062b0000
062c0000
062d0000
062e0000
062f0000
06300000
06310000
06320000
06330000
06340000
06350000
06360000
06370000
06380000
06390000
063a0000
063b0000
063c0000
063d0000
063e0000
063f0000
06400000
06410000
06420000
06430000
06440000
06450000
06460000
06470000
06480000
06490000
064a0000
064b0000
064c0000
064d0000
064e0000
064f0000
06500000
06510000
06520000
06530000
06540000
06550000
06560000
06570000
06580000
06590000
065a0000
065b0000
065c0000
065d0000
065e0000
065f0000
06600000
06610000
06620000
06630000
06640000
06650000
06660000
06670000
06680000
06690000
066a0000
066b0000
066c0000
066d0000
066e0000
066f0000
06700000
06710000
06720000
06730000
06740000
06750000
06760000
06770000
06780000
06790000
067a0000
067b0000
067c0000
067d0000
067e0000
067f0000
06800000
06810000
06820000
06830000
06840000
06850000
06860000
06870000
06880000
06890000
068a0000
068b0000
068c0000
068d0000
068e0000
068f0000
06900000
06910000
06920000
06930000
06940000
06950000
06960000
06970000
06980000
06990000
069a0000
069b0000
069c0000
069d0000
069e0000
069f0000
06a00000
06a10000
06a20000
06a30000
06a40000
06a50000
06a60000
06a70000
06a80000
06a90000
06aa0000
06ab0000
06ac0000
06ad0000
06ae0000
06af0000
06b00000
06b10000
06b20000
06b30000
06b40000
06b50000
06b60000
06b70000
06b80000
06b90000
06ba0000
06bb0000
06bc0000
06bd0000
06be0000
06bf0000
06c00000
06c10000
06c20000
06c30000
06c40000
06c50000
06c60000
06c70000
06c80000
06c90000
06ca0000
06cb0000
06cc0000
06cd0000
06ce0000
06cf0000
06d00000
06d10000
06d20000
06d30000
06d40000
06d50000
06d60000
06d70000
06d80000
06d90000
06da0000
06db0000
06dc0000
06dd0000
06de0000
06df0000
06e00000
06e10000
06e20000
06e30000
06e40000
06e50000
06e60000
06e70000
06e80000
06e90000
06ea0000
06eb0000
06ec0000
06ed0000
06ee0000
06ef0000
06f00000
06f10000
06f20000
06f30000
06f40000
06f50000
06f60000
06f70000
06f80000
06f90000
06fa0000
06fb0000
06fc0000
06fd0000
06fe0000
06ff0000
07000000
07010000
07020000
07030000
07040000
07050000
07060000
07070000
07080000
07090000
070a0000
070b0000
070c0000
070d0000
070e0000
070f0000
07100000
07110000
07120000
07130000
07140000
07150000
07160000
07170000
07180000
07190000
071a0000
071b0000
071c0000
071d0000
071e0000
071f0000
07200000
07210000
07220000
07230000
07240000
07250000
07260000
07270000
07280000
07290000
072a0000
072b0000
072c0000
072d0000
072e0000
072f0000
07300000
07310000
07320000
07330000
07340000
07350000
07360000
07370000
07380000
07390000
073a0000
073b0000
073c0000
073d0000
073e0000
073f0000
07400000
07410000
07420000
07430000
07440000
07450000
07460000
07470000
07480000
07490000
074a0000
074b0000
074c0000
074d0000
074e0000
074f0000
07500000
07510000
07520000
07530000
07540000
07550000
07560000
07570000
07580000
07590000
075a0000
075b0000
075c0000
075d0000
075e0000
075f0000
07600000
07610000
07620000
07630000
07640000
07650000
07660000
07670000
07680000
07690000
076a0000
076b0000
076c0000
076d0000
076e0000
076f0000
07700000
07710000
07720000
07730000
07740000
07750000
07760000
07770000
07780000
07790000
077a0000
077b0000
077c0000
077d0000
077e0000
077f0000
07800000
07810000
07820000
07830000
07840000
07850000
07860000
07870000
07880000
07890000
078a0000
078b0000
078c0000
078d0000
078e0000
078f0000
07900000
07910000
07920000
07930000
07940000
07950000
07960000
07970000
07980000
07990000
079a0000
079b0000
079c0000
079d0000
079e0000
079f0000
07a00000
07a10000
07a20000
07a30000
07a40000
07a50000
07a60000
07a70000
07a80000
07a90000
07aa0000
07ab0000
07ac0000
07ad0000
07ae0000
07af0000
07b00000
07b10000
07b20000
07b30000
07b40000
07b50000
07b60000
07b70000
07b80000
07b90000
07ba0000
07bb0000
07bc0000
07bd0000
07be0000
07bf0000
07c00000
07c10000
07c20000
07c30000
07c40000
07c50000
07c60000
07c70000
07c80000
07c90000
07ca0000
07cb0000
07cc0000
07cd0000
07ce0000
07cf0000
07d00000
07d10000
07d20000
07d30000
07d40000
07d50000
07d60000
07d70000
07d80000
07d90000
07da0000
07db0000
07dc0000
07dd0000
07de0000
07df0000
07e00000
07e10000
07e20000
07e30000
07e40000
07e50000
07e60000
07e70000
07e80000
07e90000
07ea0000
07eb0000
07ec0000
07ed0000
07ee0000
07ef0000
07f00000
07f10000
07f20000
07f30000
07f40000
07f50000
07f60000
07f70000
07f80000
07f90000
07fa0000
07fb0000
07fc0000
07fd0000
07fe0000
07ff0000
08000000
DRAM filled
DRAM verify: 00100000-08000000
00100000
Fail: @0x00100000 Read value=0xffffffff
Fail: @0x00100004 Read value=0xffffffff
Fail: @0x00100008 Read value=0xffffffff
Fail: @0x0010000c Read value=0xffffffff
Fail: @0x00100010 Read value=0xffffffff
Fail: @0x00100014 Read value=0xffffffff
Fail: @0x00100018 Read value=0xffffffff
Fail: @0x0010001c Read value=0xffffffff
Fail: @0x00100020 Read value=0xffffffff
Fail: @0x00100024 Read value=0xffffffff
Fail: @0x00100028 Read value=0xffffffff
Fail: @0x0010002c Read value=0xffffffff
Fail: @0x00100030 Read value=0xffffffff
Fail: @0x00100034 Read value=0xffffffff
Fail: @0x00100038 Read value=0xffffffff
Fail: @0x0010003c Read value=0xffffffff
Fail: @0x00100040 Read value=0xffffffff
Fail: @0x00100044 Read value=0xffffffff
Fail: @0x00100048 Read value=0xffffffff
Fail: @0x0010004c Read value=0xffffffff
Fail: @0x00100050 Read value=0xffffffff
Fail: @0x00100054 Read value=0xffffffff
Fail: @0x00100058 Read value=0xffffffff
Fail: @0x0010005c Read value=0xffffffff
Fail: @0x00100060 Read value=0xffffffff
Fail: @0x00100064 Read value=0xffffffff
Fail: @0x00100068 Read value=0xffffffff
Fail: @0x0010006c Read value=0xffffffff
Fail: @0x00100070 Read value=0xffffffff
Fail: @0x00100074 Read value=0xffffffff
Fail: @0x00100078 Read value=0xffffffff
Fail: @0x0010007c Read value=0xffffffff
Fail: @0x00100080 Read value=0xffffffff
Fail: @0x00100084 Read value=0xffffffff
Fail: @0x00100088 Read value=0xffffffff
Fail: @0x0010008c Read value=0xffffffff
Fail: @0x00100090 Read value=0xffffffff
Fail: @0x00100094 Read value=0xffffffff
Fail: @0x00100098 Read value=0xffffffff
Fail: @0x0010009c Read value=0xffffffff
Fail: @0x001000a0 Read value=0xffffffff
Fail: @0x001000a4 Read value=0xffffffff
Fail: @0x001000a8 Read value=0xffffffff
Fail: @0x001000ac Read value=0xffffffff
Fail: @0x001000b0 Read value=0xffffffff
Fail: @0x001000b4 Read value=0xffffffff
Fail: @0x001000b8 Read value=0xffffffff
Fail: @0x001000bc Read value=0xffffffff
Fail: @0x001000c0 Read value=0xffffffff
Fail: @0x001000c4 Read value=0xffffffff
Fail: @0x001000c8 Read value=0xffffffff
Fail: @0x001000cc Read value=0xffffffff
Fail: @0x001000d0 Read value=0xffffffff
Fail: @0x001000d4 Read value=0xffffffff
Fail: @0x001000d8 Read value=0xffffffff
Fail: @0x001000dc Read value=0xffffffff
Fail: @0x001000e0 Read value=0xffffffff
Fail: @0x001000e4 Read value=0xffffffff
Fail: @0x001000e8 Read value=0xffffffff
Fail: @0x001000ec Read value=0xffffffff
Fail: @0x001000f0 Read value=0xffffffff
Fail: @0x001000f4 Read value=0xffffffff
Fail: @0x001000f8 Read value=0xffffffff
Fail: @0x001000fc Read value=0xffffffff
Fail: @0x00100100 Read value=0xffffffff
Fail: @0x00100104 Read value=0xffffffff
Fail: @0x00100108 Read value=0xffffffff
Fail: @0x0010010c Read value=0xffffffff
Fail: @0x00100110 Read value=0xffffffff
Fail: @0x00100114 Read value=0xffffffff
Fail: @0x00100118 Read value=0xffffffff
Fail: @0x0010011c Read value=0xffffffff
Fail: @0x00100120 Read value=0xffffffff
Fail: @0x00100124 Read value=0xffffffff
Fail: @0x00100128 Read value=0xffffffff
Fail: @0x0010012c Read value=0xffffffff
Fail: @0x00100130 Read value=0xffffffff
Fail: @0x00100134 Read value=0xffffffff
Fail: @0x00100138 Read value=0xffffffff
Fail: @0x0010013c Read value=0xffffffff
Fail: @0x00100140 Read value=0xffffffff
Fail: @0x00100144 Read value=0xffffffff
Fail: @0x00100148 Read value=0xffffffff
Fail: @0x0010014c Read value=0xffffffff
Fail: @0x00100150 Read value=0xffffffff
Fail: @0x00100154 Read value=0xffffffff
Fail: @0x00100158 Read value=0xffffffff
Fail: @0x0010015c Read value=0xffffffff
Fail: @0x00100160 Read value=0xffffffff
Fail: @0x00100164 Read value=0xffffffff
Fail: @0x00100168 Read value=0xffffffff
Fail: @0x0010016c Read value=0xffffffff
Fail: @0x00100170 Read value=0xffffffff
Fail: @0x00100174 Read value=0xffffffff
Fail: @0x00100178 Read value=0xffffffff
Fail: @0x0010017c Read value=0xffffffff
Fail: @0x00100180 Read value=0xffffffff
Fail: @0x00100184 Read value=0xffffffff
Fail: @0x00100188 Read value=0xffffffff
Fail: @0x0010018c Read value=0xffffffff
Fail: @0x00100190 Read value=0xffffffff
Fail: @0x00100194 Read value=0xffffffff
Fail: @0x00100198 Read value=0xffffffff
Fail: @0x0010019c Read value=0xffffffff
Fail: @0x001001a0 Read value=0xffffffff
Fail: @0x001001a4 Read value=0xffffffff
Fail: @0x001001a8 Read value=0xffffffff
Fail: @0x001001ac Read value=0xffffffff
Fail: @0x001001b0 Read value=0xffffffff
Fail: @0x001001b4 Read value=0xffffffff
Fail: @0x001001b8 Read value=0xffffffff
Fail: @0x001001bc Read value=0xffffffff
Fail: @0x001001c0 Read value=0xffffffff
Fail: @0x001001c4 Read value=0xffffffff
Fail: @0x001001c8 Read value=0xffffffff
Fail: @0x001001cc Read value=0xffffffff
Fail: @0x001001d0 Read value=0xffffffff
Fail: @0x001001d4 Read value=0xffffffff
Fail: @0x001001d8 Read value=0xffffffff
Fail: @0x001001dc Read value=0xffffffff
Fail: @0x001001e0 Read value=0xffffffff
Fail: @0x001001e4 Read value=0xffffffff
Fail: @0x001001e8 Read value=0xffffffff
Fail: @0x001001ec Read value=0xffffffff
Fail: @0x001001f0 Read value=0xffffffff
Fail: @0x001001f4 Read value=0xffffffff
Fail: @0x001001f8 Read value=0xffffffff
Fail: @0x001001fc Read value=0xffffffff
Fail: @0x00100200 Read value=0xffffffff
Fail: @0x00100204 Read value=0xffffffff
Fail: @0x00100208 Read value=0xffffffff
Fail: @0x0010020c Read value=0xffffffff
Fail: @0x00100210 Read value=0xffffffff
Fail: @0x00100214 Read value=0xffffffff
Fail: @0x00100218 Read value=0xffffffff
Fail: @0x0010021c Read value=0xffffffff
Fail: @0x00100220 Read value=0xffffffff
Fail: @0x00100224 Read value=0xffffffff
Fail: @0x00100228 Read value=0xffffffff
Fail: @0x0010022c Read value=0xffffffff
Fail: @0x00100230 Read value=0xffffffff
Fail: @0x00100234 Read value=0xffffffff
Fail: @0x00100238 Read value=0xffffffff
Fail: @0x0010023c Read value=0xffffffff
Fail: @0x00100240 Read value=0xffffffff
Fail: @0x00100244 Read value=0xffffffff
Fail: @0x00100248 Read value=0xffffffff
Fail: @0x0010024c Read value=0xffffffff
Fail: @0x00100250 Read value=0xffffffff
Fail: @0x00100254 Read value=0xffffffff
Fail: @0x00100258 Read value=0xffffffff
Fail: @0x0010025c Read value=0xffffffff
Fail: @0x00100260 Read value=0xffffffff
Fail: @0x00100264 Read value=0xffffffff
Fail: @0x00100268 Read value=0xffffffff
Fail: @0x0010026c Read value=0xffffffff
Fail: @0x00100270 Read value=0xffffffff
Fail: @0x00100274 Read value=0xffffffff
Fail: @0x00100278 Read value=0xffffffff
Fail: @0x0010027c Read value=0xffffffff
Fail: @0x00100280 Read value=0xffffffff
Fail: @0x00100284 Read value=0xffffffff
Fail: @0x00100288 Read value=0xffffffff
Fail: @0x0010028c Read value=0xffffffff
Fail: @0x00100290 Read value=0xffffffff
Fail: @0x00100294 Read value=0xffffffff
Fail: @0x00100298 Read value=0xffffffff
Fail: @0x0010029c Read value=0xffffffff
Fail: @0x001002a0 Read value=0xffffffff
Fail: @0x001002a4 Read value=0xffffffff
Fail: @0x001002a8 Read value=0xffffffff
Fail: @0x001002ac Read value=0xffffffff
Fail: @0x001002b0 Read value=0xffffffff
Fail: @0x001002b4 Read value=0xffffffff
Fail: @0x001002b8 Read value=0xffffffff
Fail: @0x001002bc Read value=0xffffffff
Fail: @0x001002c0 Read value=0xffffffff
Fail: @0x001002c4 Read value=0xffffffff
Fail: @0x001002c8 Read value=0xffffffff
Fail: @0x001002cc Read value=0xffffffff
Fail: @0x001002d0 Read value=0xffffffff
Fail: @0x001002d4 Read value=0xffffffff
Fail: @0x001002d8 Read value=0xffffffff
Fail: @0x001002dc Read value=0xffffffff
Fail: @0x001002e0 Read value=0xffffffff
Fail: @0x001002e4 Read value=0xffffffff
Fail: @0x001002e8 Read value=0xffffffff
Fail: @0x001002ec Read value=0xffffffff
Fail: @0x001002f0 Read value=0xffffffff
Fail: @0x001002f4 Read value=0xffffffff
Fail: @0x001002f8 Read value=0xffffffff
Fail: @0x001002fc Read value=0xffffffff
Fail: @0x00100300 Read value=0xffffffff
Fail: @0x00100304 Read value=0xffffffff
Fail: @0x00100308 Read value=0xffffffff
Fail: @0x0010030c Read value=0xffffffff
Fail: @0x00100310 Read value=0xffffffff
Fail: @0x00100314 Read value=0xffffffff
Fail: @0x00100318 Read value=0xffffffff
Fail: @0x0010031c Read value=0xffffffff
Fail: @0x00100320 Read value=0xffffffff
Fail: @0x00100324 Read value=0xffffffff
Fail: @0x00100328 Read value=0xffffffff
Fail: @0x0010032c Read value=0xffffffff
Fail: @0x00100330 Read value=0xffffffff
Fail: @0x00100334 Read value=0xffffffff
Fail: @0x00100338 Read value=0xffffffff
Fail: @0x0010033c Read value=0xffffffff
Fail: @0x00100340 Read value=0xffffffff
Fail: @0x00100344 Read value=0xffffffff
Fail: @0x00100348 Read value=0xffffffff
Fail: @0x0010034c Read value=0xffffffff
Fail: @0x00100350 Read value=0xffffffff
Fail: @0x00100354 Read value=0xffffffff
Fail: @0x00100358 Read value=0xffffffff
Fail: @0x0010035c Read value=0xffffffff
Fail: @0x00100360 Read value=0xffffffff
Fail: @0x00100364 Read value=0xffffffff
Fail: @0x00100368 Read value=0xffffffff
Fail: @0x0010036c Read value=0xffffffff
Fail: @0x00100370 Read value=0xffffffff
Fail: @0x00100374 Read value=0xffffffff
Fail: @0x00100378 Read value=0xffffffff
Fail: @0x0010037c Read value=0xffffffff
Fail: @0x00100380 Read value=0xffffffff
Fail: @0x00100384 Read value=0xffffffff
Fail: @0x00100388 Read value=0xffffffff
Fail: @0x0010038c Read value=0xffffffff
Fail: @0x00100390 Read value=0xffffffff
Fail: @0x00100394 Read value=0xffffffff
Fail: @0x00100398 Read value=0xffffffff
Fail: @0x0010039c Read value=0xffffffff
Fail: @0x001003a0 Read value=0xffffffff
Fail: @0x001003a4 Read value=0xffffffff
Fail: @0x001003a8 Read value=0xffffffff
Fail: @0x001003ac Read value=0xffffffff
Fail: @0x001003b0 Read value=0xffffffff
Fail: @0x001003b4 Read value=0xffffffff
Fail: @0x001003b8 Read value=0xffffffff
Fail: @0x001003bc Read value=0xffffffff
Fail: @0x001003c0 Read value=0xffffffff
Fail: @0x001003c4 Read value=0xffffffff
Fail: @0x001003c8 Read value=0xffffffff
Fail: @0x001003cc Read value=0xffffffff
Fail: @0x001003d0 Read value=0xffffffff
Fail: @0x001003d4 Read value=0xffffffff
Fail: @0x001003d8 Read value=0xffffffff
Fail: @0x001003dc Read value=0xffffffff
Fail: @0x001003e0 Read value=0xffffffff
Fail: @0x001003e4 Read value=0xffffffff
Fail: @0x001003e8 Read value=0xffffffff
Fail: @0x001003ec Read value=0xffffffff
Fail: @0x001003f0 Read value=0xffffffff
Fail: @0x001003f4 Read value=0xffffffff
Fail: @0x001003f8 Read value=0xffffffff
Fail: @0x001003fc Read value=0xffffffff
Fail: @0x00100400 Read value=0xffffffff
Aborting.
00100400
DRAM did _NOT_ verify!



From stepan at coresystems.de  Thu Oct  4 06:44:49 2007
From: stepan at coresystems.de (Stefan Reinauer)
Date: Thu, 4 Oct 2007 06:44:49 +0200
Subject: [LinuxBIOS] Problems with Filo booting - HELP
In-Reply-To: <20071004002639.o29oeiku4g84w4g8@www.smittys.pointclark.net>
References: <46FF1CB2.60901@gmail.com>
	<20070930115720.mwni4u7go4wkk8wg@www.smittys.pointclark.net>
	<47000290.6020000@gmail.com>
	<20071001094827.loois4qr0g4ckw8o@www.smittys.pointclark.net>
	<13426df10710010950s379f8230y5b4ffec4da605f06@mail.gmail.com>
	<20071001165858.vlz66uxpusgk0gww@www.smittys.pointclark.net>
	<47017223.6010504@gmail.com>
	<20071003190457.a6hta1e4kk8w0wwc@www.smittys.pointclark.net>
	<4704630C.8060803@gmail.com>
	<20071004002639.o29oeiku4g84w4g8@www.smittys.pointclark.net>
Message-ID: <20071004044448.GA27127@coresystems.de>

* joe at smittys.pointclark.net <joe at smittys.pointclark.net> [071004 06:26]:

> Here is my ram_check from 1-128MB. It appears to fill the ram ok. But  
> only returns a value of 0xffffffff. Does this mean the ram is WO  
> (write only) for some reason? Thanks again for your help.

Do you have several banks? Do you send your ram init commands to all
these banks, or just the first?



-- 
coresystems GmbH ? Brahmsstr. 16 ? D-79104 Freiburg i. Br.
      Tel.: +49 761 7668825 ? Fax: +49 761 7664613
Email: info at coresystems.de  ? http://www.coresystems.de/
Registergericht: Amtsgericht Freiburg ? HRB 7656
Gesch?ftsf?hrer: Stefan Reinauer ? Ust-IdNr.: DE245674866



From bishop.robinson at gmail.com  Thu Oct  4 07:09:04 2007
From: bishop.robinson at gmail.com (Robinson Tryon)
Date: Thu, 4 Oct 2007 01:09:04 -0400
Subject: [LinuxBIOS] superiotool - IT8705F dump support
Message-ID: <a698c16a0710032209ne8a672kbce87c4f3ca6b6b5@mail.gmail.com>

Here's a patch for the IT8705F.  I followed the structure of the other
ITE chips in the table.  How does it look?

Signed-off-by: Robinson P. Tryon <bishop.robinson at gmail.com>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: it8705f.patch
Type: text/x-patch
Size: 2085 bytes
Desc: not available
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20071004/3e1860ef/attachment.patch>

From stepan at coresystems.de  Thu Oct  4 07:29:33 2007
From: stepan at coresystems.de (Stefan Reinauer)
Date: Thu, 4 Oct 2007 07:29:33 +0200
Subject: [LinuxBIOS] [PATCH] superiotool: Various improvements
In-Reply-To: <20071004003311.GC14438@greenwood>
References: <20071004003311.GC14438@greenwood>
Message-ID: <20071004052932.GA639@coresystems.de>

* Uwe Hermann <uwe at hermann-uwe.de> [071004 02:33]:
>  * Convert the NSC code to the common code structure all other Super I/Os use.
> 
>  * Improve the --verbose output a bit more. Print the "Probing..." text for
>    all Super I/Os and if a Super I/O is not known, show the data we were
>    able to read from the chip (what data this is is very vendor/chip specific).
> 
>  * Thus the common no_superio_found() is dropped, it's not useful.
>    The "read from 0x20" part was wrong for all Super I/Os other than the
>    NSC ones anyway.
> 
>  * Winbond: For the 'olddevid' only use bits 3..0, mask away the others.
> 
>  * SMSC: Print which ID registers we try to read (in --verbose mode).
> 
>  * Minor cosmetic fixes.
>    * Rename PC8374 to PC8374L (as per datasheet).
>    * Rename probe_idregs_simple() to probe_idregs_nsc().
>    * Rename dump_readable_ns8374() to dump_readable_pc8374l().
> 
> Signed-off-by: Uwe Hermann <uwe at hermann-uwe.de>
 
Acked-by: Stefan Reinauer <stepan at coresystems.de>

-- 
coresystems GmbH ? Brahmsstr. 16 ? D-79104 Freiburg i. Br.
      Tel.: +49 761 7668825 ? Fax: +49 761 7664613
Email: info at coresystems.de  ? http://www.coresystems.de/



From svn at openbios.org  Thu Oct  4 07:37:25 2007
From: svn at openbios.org (svn at openbios.org)
Date: Thu,  4 Oct 2007 07:37:25 +0200
Subject: [LinuxBIOS] r503 - in LinuxBIOSv3: . arch/x86
Message-ID: <mailman.693.1355071172.16123.coreboot@coreboot.org>

Author: stepan
Date: 2007-10-04 07:37:24 +0200 (Thu, 04 Oct 2007)
New Revision: 503

Modified:
   LinuxBIOSv3/Kconfig
   LinuxBIOSv3/arch/x86/Makefile
Log:
Fix the config process so that pre-parsing of elf works again. It was broken                                                              
(I think) when the PAYLOAD_NONE change was put in.                                                                                        

Signed-off-by: Ronald G. Minnich <rminnich at gmail.com>   
Acked-by: Stefan Reinauer <stepan at coresystems.de>



Modified: LinuxBIOSv3/Kconfig
===================================================================
--- LinuxBIOSv3/Kconfig	2007-09-26 19:49:38 UTC (rev 502)
+++ LinuxBIOSv3/Kconfig	2007-10-04 05:37:24 UTC (rev 503)
@@ -53,25 +53,6 @@
 	help
 	  Append an extra string to the end of the LinuxBIOS version.
 
-config NOELF
-	bool "Don't use ELF for payloads"
-	depends EXPERT
-	default n
-	help
-	  Until now, LinuxBIOS has used elf for the payload. There are many problems 
-	  this, not least being the inefficiency -- the ELF has to be decompressed to
-	  memory and then the segments have to be copied. Plus, lar can't see the segments 
-	  in the elf -- to see all segments, you have to extract the elf and run readelf on it.
-	  There are problems with collisions of the decompressed ELF location in memory
-	  and the segment locations in memory. 
-	  Finally, validation of the ELF is done at run time, once you have flashed the 
-	  FLASH and rebooted the machine. Boot time is really not the time you want to find 
-	  out your ELF payload is broken. 
-	  With this option, LinuxBIOS will direct lar to break each elf segment into a LAR 
-	  entry. ELF will not be used at all. Note that (for now) LinuxBIOS is backward
-	  compatible -- if you put an ELF payload in, LinuxBIOS can still parse it. We hope
-	  to remove ELF entirely in the future. 
-
 config BEEPS
 	bool "Enable beeps upon certain LinuxBIOS events"
 	depends EXPERT
@@ -113,6 +94,25 @@
         prompt "Payload type"
         default PAYLOAD_NONE
 
+config PAYLOAD_PREPARSE_ELF
+	bool "Pre-parse ELF file and convert ELF segments to LAR entries"
+	depends EXPERT
+	default n
+	help
+	  Until now, LinuxBIOS has used elf for the payload. There are many problems 
+	  this, not least being the inefficiency -- the ELF has to be decompressed to
+	  memory and then the segments have to be copied. Plus, lar can't see the segments 
+	  in the elf -- to see all segments, you have to extract the elf and run readelf on it.
+	  There are problems with collisions of the decompressed ELF location in memory
+	  and the segment locations in memory. 
+	  Finally, validation of the ELF is done at run time, once you have flashed the 
+	  FLASH and rebooted the machine. Boot time is really not the time you want to find 
+	  out your ELF payload is broken. 
+	  With this option, LinuxBIOS will direct lar to break each elf segment into a LAR 
+	  entry. ELF will not be used at all. Note that (for now) LinuxBIOS is backward
+	  compatible -- if you put an ELF payload in, LinuxBIOS can still parse it. We hope
+	  to remove ELF entirely in the future. 
+
 config PAYLOAD_ELF
 	bool "An ELF executable payload file"
 	help
@@ -137,7 +137,7 @@
 
 config PAYLOAD_FILE
 	string "Payload path and filename"
-	depends PAYLOAD_ELF
+	depends PAYLOAD_ELF || PAYLOAD_PREPARSE_ELF
 	default "payload.elf"
 	help
 	  The path and filename of the ELF executable file to use as payload.

Modified: LinuxBIOSv3/arch/x86/Makefile
===================================================================
--- LinuxBIOSv3/arch/x86/Makefile	2007-09-26 19:49:38 UTC (rev 502)
+++ LinuxBIOSv3/arch/x86/Makefile	2007-10-04 05:37:24 UTC (rev 503)
@@ -122,7 +122,7 @@
 endif
 endif
 
-ifeq ($(CONFIG_NOELF), y)
+ifeq ($(CONFIG_PAYLOAD_PREPARSE_ELF), y)
 	PARSEELF = -e
 else
 	PARSEELF = 




From stepan at coresystems.de  Thu Oct  4 07:37:54 2007
From: stepan at coresystems.de (Stefan Reinauer)
Date: Thu, 4 Oct 2007 07:37:54 +0200
Subject: [LinuxBIOS] patch: fix Kconfig for elf preparsing
In-Reply-To: <13426df10710031120r21935601t88a2140183fa9d8d@mail.gmail.com>
References: <13426df10710031120r21935601t88a2140183fa9d8d@mail.gmail.com>
Message-ID: <20071004053754.GA2540@coresystems.de>

* ron minnich <rminnich at gmail.com> [071003 20:20]:
> This repairs the problem I found.
> 
> ron

> Fix the config process so that pre-parsing of elf works again. It was broken
> (I think) when the PAYLOAD_NONE change was put in. 
> Signed-off-by: Ronald G. Minnich <rminnich at gmail.com>

r503

-- 
coresystems GmbH ? Brahmsstr. 16 ? D-79104 Freiburg i. Br.
      Tel.: +49 761 7668825 ? Fax: +49 761 7664613
Email: info at coresystems.de  ? http://www.coresystems.de/
Registergericht: Amtsgericht Freiburg ? HRB 7656
Gesch?ftsf?hrer: Stefan Reinauer ? Ust-IdNr.: DE245674866



From stepan at coresystems.de  Thu Oct  4 07:44:15 2007
From: stepan at coresystems.de (Stefan Reinauer)
Date: Thu, 4 Oct 2007 07:44:15 +0200
Subject: [LinuxBIOS] patch: fix filo dependency on memory being zero
In-Reply-To: <13426df10710031340o2469373ape2e7212e485524e7@mail.gmail.com>
References: <13426df10710031123t406504bxdfa9b45e4ad7194b@mail.gmail.com>
	<13426df10710031340o2469373ape2e7212e485524e7@mail.gmail.com>
Message-ID: <20071004054415.GB2540@coresystems.de>

* ron minnich <rminnich at gmail.com> [071003 22:40]:
> On 10/3/07, ron minnich <rminnich at gmail.com> wrote:
> > This patch makes qemu work again on v3. FILO was depending on bss
> > being zero, which is not all that safe in embedded. It's better to
> > zero things you are depending on being zero.
> >
> > ron
> >

> This patch makes qemu work again on v3. FILO was depending on bss being zero, which is not all that safe in embedded. It's better to zero things you are depending on being zero.
> Signed-off-by: Ronald G. Minnich <rminnich at gmail.com>

Let me guess.. is this with PAYLOAD_PREPARSE_ELF enabled?

What else is different in "embedded" when running LinuxBIOS?

Stefan

-- 
coresystems GmbH ? Brahmsstr. 16 ? D-79104 Freiburg i. Br.
      Tel.: +49 761 7668825 ? Fax: +49 761 7664613
Email: info at coresystems.de  ? http://www.coresystems.de/
Registergericht: Amtsgericht Freiburg ? HRB 7656
Gesch?ftsf?hrer: Stefan Reinauer ? Ust-IdNr.: DE245674866



From stepan at coresystems.de  Thu Oct  4 08:10:03 2007
From: stepan at coresystems.de (Stefan Reinauer)
Date: Thu, 4 Oct 2007 08:10:03 +0200
Subject: [LinuxBIOS] [BUILDROM]:  Disable OFW
In-Reply-To: <20071002201317.GF27248@cosmic.amd.com>
References: <20071002201317.GF27248@cosmic.amd.com>
Message-ID: <20071004061003.GA7211@coresystems.de>

* Jordan Crouse <jordan.crouse at amd.com> [071002 22:13]:
> Okay, now that everybody has recovered from the last patch, here's the 
> last one - disable OFW for the short term in buildrom.  Reason being,
> that it only worked for OLPC, and the previous patch removed OLPC.   I
> discussed the matter briefly with Stefan and Segher, and they tell me
> that there are ongoing efforts to make OFW or a OpenFirmware clone of
> some sort usable on a generic x86.  I support that 100%, I think OFW
> is a vital payload for this project.  I just don't know enough about
> OpenFirmware to get the job done.  So I am submitting a patch to
> disable, but not to remove the OFW scripts, so that those who do know
> what they are doing can port the code easily.  When everything works,
> revert this patch, and we're off to the races.

Please don't! There has been a lot of ongoing effort to make this work
(not with buildrom yet, though), and I think this slimming down is the
wrong direction. If its broken, someone might fix it. If its gone, its
gone.

-- 
coresystems GmbH ? Brahmsstr. 16 ? D-79104 Freiburg i. Br.
      Tel.: +49 761 7668825 ? Fax: +49 761 7664613
Email: info at coresystems.de  ? http://www.coresystems.de/
Registergericht: Amtsgericht Freiburg ? HRB 7656
Gesch?ftsf?hrer: Stefan Reinauer ? Ust-IdNr.: DE245674866



From svn at openbios.org  Thu Oct  4 08:12:32 2007
From: svn at openbios.org (svn at openbios.org)
Date: Thu,  4 Oct 2007 08:12:32 +0200
Subject: [LinuxBIOS] r38 - trunk/filo-0.5/drivers
Message-ID: <mailman.694.1355071172.16123.coreboot@coreboot.org>

Author: stepan
Date: 2007-10-04 08:12:32 +0200 (Thu, 04 Oct 2007)
New Revision: 38

Modified:
   trunk/filo-0.5/drivers/ide.c
Log:
This code is originally from Nikolay Petukhov <nikolaypetukhov at gmail.com> with
one minor change                                           
from me. It enables the option of having only slaves on ide, such as the CF
found on the msm800sev.                                       
                                                                                                                                          
This code has been tested on the msm800sev with one master, master and slave,
and only slave and works. I'd like to see some other tests before we commit.
IDE is touchy.  

Signed-off-by: Ronald G. Minnich <rminnich at gmail.com>
Acked-by: Stefan Reinauer <stepan at coresystems.de>

                                                                  


Modified: trunk/filo-0.5/drivers/ide.c
===================================================================
--- trunk/filo-0.5/drivers/ide.c	2007-10-02 19:30:23 UTC (rev 37)
+++ trunk/filo-0.5/drivers/ide.c	2007-10-04 06:12:32 UTC (rev 38)
@@ -280,8 +280,29 @@
 			inb(IDE_REG_STATUS(ctrl)), inb(IDE_REG_ERROR(ctrl)));
 }
 
+int select_drive(struct controller *ctrl, int drive)
+{
+	int device, status;
+
+	outb(0xa0 | (drive << 4), IDE_REG_DEVICE(ctrl));
+	status = inb(IDE_REG_STATUS(ctrl));
+
+	mdelay(10);
+	
+	device = inb(IDE_REG_DEVICE(ctrl));
+	status = inb(IDE_REG_STATUS(ctrl));
+	
+	if (device == (0xa0 | (drive<<4)))
+		return 1;
+	else
+		return 0;
+}
+
 static int ide_software_reset(struct controller *ctrl)
 {
+	int master_exist = select_drive(ctrl, 0);
+	int slave_exist = select_drive(ctrl, 1);
+
 	/* Wait a little bit in case this is immediately after
 	 * hardware reset.
 	 */
@@ -303,7 +324,10 @@
 		IDE_REG_DEVICE_CONTROL(ctrl));
 	/* If BSY bit is not asserted within 400ns, no device there */
 	if (await_ide(bsy, ctrl, currticks() + IDE_RESET_PULSE) < 0) {
-		return -1;
+		if (slave_exist)
+			printf ("reset failed, but slave maybe exist\n");
+		else
+			return -1;
 	}
 	outb(IDE_CTRL_HD15 | IDE_CTRL_NIEN, IDE_REG_DEVICE_CONTROL(ctrl));
 	mdelay(2);
@@ -863,6 +887,7 @@
 	 * is quite rare.
 	 * 
 	 */
+	debug("init_controller: drive %d\n", drive);
 #if !BSY_SET_DURING_SPINUP
 	if (await_ide(timeout, ctrl, currticks() + IDE_TIMEOUT) < 0) {
 		return -1;
@@ -886,21 +911,44 @@
 	 */
 
 	/* Now initialize the individual drives */
-	info = &harddisk_info[drive];
-	init_drive(info, ctrl, 0, drive, buffer, IDE_CMD_IDENTIFY_DEVICE);
+	int master_drive = drive & ~1;
+	info = &harddisk_info[master_drive];
+
+	/* master */
+	init_drive(info, ctrl, 0, master_drive, buffer, IDE_CMD_IDENTIFY_DEVICE);
+
 	if (!info->drive_exists)
-		init_drive(info, ctrl, 0, drive, buffer,
+		init_drive(info, ctrl, 0, master_drive, buffer,
 				IDE_CMD_IDENTIFY_PACKET_DEVICE);
+
+	debug("MASTER CHECK: master %s\n", 
+			info->drive_exists ? "yes" : "no");
+	/* slave and master */
 	if (info->drive_exists && !info->slave_absent) {
-		drive++;
+		master_drive++;
 		info++;
-		init_drive(info, ctrl, 1, drive, buffer,
+		init_drive(info, ctrl, 1, master_drive, buffer,
 				IDE_CMD_IDENTIFY_DEVICE);
 		if (!info->drive_exists)
-			init_drive(info, ctrl, 1, drive, buffer,
+			init_drive(info, ctrl, 1, master_drive, buffer,
 					IDE_CMD_IDENTIFY_PACKET_DEVICE);
 	}
 
+
+	/* slave */
+	debug("/*slave */ -- drive is %d\n", drive);
+	info = &harddisk_info[drive];
+	if (!info->drive_exists) {
+		debug("NO MASTER -- check slave!\n");
+		init_drive(info, ctrl, 1, drive, buffer, IDE_CMD_IDENTIFY_DEVICE);
+		
+		if (!info->drive_exists)
+			init_drive(info, ctrl, 1, drive, buffer,
+				IDE_CMD_IDENTIFY_PACKET_DEVICE);
+		debug("SLAVE ONLY CHECK: slave %s\n", 
+				info->drive_exists ? "yes" : "no");
+	}
+
 	return 0;
 }
 
@@ -1123,7 +1171,7 @@
 			printf("IDE channel %d not found\n", ctrl_index);
 			return -1;
 		}
-		if (init_controller(ctrl, drive & ~1, ide_buffer) != 0) {
+		if (init_controller(ctrl, drive, ide_buffer) != 0) {
 			printf("No drive detected on IDE channel %d\n",
 					ctrl_index);
 			return -1;




From corey.osgood at gmail.com  Thu Oct  4 08:13:28 2007
From: corey.osgood at gmail.com (Corey Osgood)
Date: Thu, 04 Oct 2007 02:13:28 -0400
Subject: [LinuxBIOS] Problems with Filo booting - HELP
In-Reply-To: <20071004002639.o29oeiku4g84w4g8@www.smittys.pointclark.net>
References: <20070929165103.pcm220bn4s48sow8@smittys.pointclark.net>	<20070929205527.GA16584@coresystems.de>	<20070929170245.ata0hgegqowgcwgs@www.smittys.pointclark.net>	<20070929201342.mifqbujb44ocwks8@smittys.pointclark.net>	<46FF1CB2.60901@gmail.com>	<20070930115720.mwni4u7go4wkk8wg@www.smittys.pointclark.net>	<47000290.6020000@gmail.com>	<20071001094827.loois4qr0g4ckw8o@www.smittys.pointclark.net>	<13426df10710010950s379f8230y5b4ffec4da605f06@mail.gmail.com>	<20071001165858.vlz66uxpusgk0gww@www.smittys.pointclark.net>	<47017223.6010504@gmail.com>	<20071003190457.a6hta1e4kk8w0wwc@www.smittys.pointclark.net>	<4704630C.8060803@gmail.com>
	<20071004002639.o29oeiku4g84w4g8@www.smittys.pointclark.net>
Message-ID: <47048488.5060508@gmail.com>

joe at smittys.pointclark.net wrote:
> Here is my ram_check from 1-128MB. It appears to fill the ram ok. But
> only returns a value of 0xffffffff. Does this mean the ram is WO
> (write only) for some reason? Thanks again for your help.

Okay, this is mostly a shot in the dark, but it's the only thing I can
find that might cause something like this. I'm looking at the AGP size
register (APSIZE, 0xb4) in the datasheet, and the default value is 0x00,
which is 256MB (!!). I also don't see anywhere that AGP has to be
explicitly enabled, it looks like it's enabled by default (yes, I see
AGPCMD, but it says cycles will be ignored, not that the device is
actually disabled and freeing the aperture memory).

Long story short, try setting the AGP aperture to 32MB and moving the
aperture base (APBASE, 0x10-13) to somewhere else, preferably wherever
the stock bios moves it to. Even if it's not the root cause, it'll get
it out of the way for later.

-Corey



From stepan at coresystems.de  Thu Oct  4 08:14:19 2007
From: stepan at coresystems.de (Stefan Reinauer)
Date: Thu, 4 Oct 2007 08:14:19 +0200
Subject: [LinuxBIOS] patch: filo
In-Reply-To: <13426df10710021218o70c53799wf7d8e987524472b0@mail.gmail.com>
References: <13426df10710021218o70c53799wf7d8e987524472b0@mail.gmail.com>
Message-ID: <20071004061419.GB7211@coresystems.de>

* ron minnich <rminnich at gmail.com> [071002 21:18]:
> This code is originally from Nikolay Petukhov <nikolaypetukhov at gmail.com> with one minor change
> from me. It enables the option of having only slaves on ide, such as the CF found on the msm800sev. 
> 
> This code has been tested on the msm800sev with one master, master and slave, and only slave
> and works. I'd like to see some other tests before we commit. IDE is touchy.
> Signed-off-by: Ronald G. Minnich <rminnich at gmail.com>

r38. 

We should also get Peter's speedup patch in. Which is the latest version
of that one?

Also, the direction should be to go towards grub2 as payload and let
filo die.

-- 
coresystems GmbH ? Brahmsstr. 16 ? D-79104 Freiburg i. Br.
      Tel.: +49 761 7668825 ? Fax: +49 761 7664613
Email: info at coresystems.de  ? http://www.coresystems.de/
Registergericht: Amtsgericht Freiburg ? HRB 7656
Gesch?ftsf?hrer: Stefan Reinauer ? Ust-IdNr.: DE245674866



From stepan at coresystems.de  Thu Oct  4 08:15:39 2007
From: stepan at coresystems.de (Stefan Reinauer)
Date: Thu, 4 Oct 2007 08:15:39 +0200
Subject: [LinuxBIOS] [BUILDROM] Clean up some files that are no
	longer	needed or never used
In-Reply-To: <20071002200034.GD27248@cosmic.amd.com>
References: <20071002200034.GD27248@cosmic.amd.com>
Message-ID: <20071004061539.GC7211@coresystems.de>

* Jordan Crouse <jordan.crouse at amd.com> [071002 22:00]:
> [BUILDROM] Clean up some files that are no longer needed or never used
> 
> Remove files that snuck in there by mistake or are no longer needed.
> 
> Signed-off-by: Jordan Crouse <jordan.crouse at amd.com>
Acked-by: Stefan Reinauer <stepan at coresystems.de>


-- 
coresystems GmbH ? Brahmsstr. 16 ? D-79104 Freiburg i. Br.
      Tel.: +49 761 7668825 ? Fax: +49 761 7664613
Email: info at coresystems.de  ? http://www.coresystems.de/
Registergericht: Amtsgericht Freiburg ? HRB 7656
Gesch?ftsf?hrer: Stefan Reinauer ? Ust-IdNr.: DE245674866



From svn at openbios.org  Thu Oct  4 08:26:41 2007
From: svn at openbios.org (svn at openbios.org)
Date: Thu,  4 Oct 2007 08:26:41 +0200
Subject: [LinuxBIOS] r2820 - trunk/util/flashrom
Message-ID: <mailman.695.1355071172.16123.coreboot@coreboot.org>

Author: stepan
Date: 2007-10-04 08:26:41 +0200 (Thu, 04 Oct 2007)
New Revision: 2820

Modified:
   trunk/util/flashrom/flashrom.c
Log:
[FLASHROM] Fix the help, and print a message when nothing happens

The help implied that writes happen by default, which they don't.  Fix
the text, and say something when we dont specify any commands.

Signed-off-by: Jordan Crouse <jordan.crouse at amd.com>    
Acked-by: Stefan Reinauer <stepan at coresystems.de>



Modified: trunk/util/flashrom/flashrom.c
===================================================================
--- trunk/util/flashrom/flashrom.c	2007-10-03 18:56:51 UTC (rev 2819)
+++ trunk/util/flashrom/flashrom.c	2007-10-04 06:26:41 UTC (rev 2820)
@@ -195,8 +195,7 @@
 	printf("       [-e exclude_end] [-m vendor:part] [-l file.layout] [-i imagename] [file]\n");
 	printf
 	    ("   -r | --read:                    read flash and save into file\n"
-	     "   -w | --write:                   write file into flash (default when\n"
-	     "                                   file is specified)\n"
+	     "   -w | --write:                   write file into flash\n"
 	     "   -v | --verify:                  verify flash against file\n"
 	     "   -E | --erase:                   erase flash device\n"
 	     "   -V | --verbose:                 more verbose output\n"
@@ -366,15 +365,22 @@
 
 	if ((flash = probe_flash(flashchips)) == NULL) {
 		printf("No EEPROM/flash device found.\n");
+		// FIXME: flash writes stay enabled!
 		exit(1);
 	}
 
 	printf("Flash part is %s (%d KB)\n", flash->name, flash->total_size);
 
+	if (!(read_it | write_it | verify_it | erase_it)) {
+		printf("No operations were specified.\n");
+		// FIXME: flash writes stay enabled!
+		exit(1);
+	}
+
 	if (!filename && !erase_it) {
-		// FIXME: Do we really want this feature implicitly?
-		printf("OK, only ENABLING flash write, but NOT FLASHING.\n");
-		return 0;
+		printf("Error: No filename specified.\n");
+		// FIXME: flash writes stay enabled!
+		exit(1);
 	}
 
 	size = flash->total_size * 1024;




From juergen127 at kreuzholzen.de  Thu Oct  4 08:27:41 2007
From: juergen127 at kreuzholzen.de (Juergen Beisert)
Date: Thu, 4 Oct 2007 08:27:41 +0200
Subject: [LinuxBIOS] Two more CS5530 IRQ steering questions
In-Reply-To: <4703C74C.6060603@amd.com>
References: <735999.11669.qm@web35906.mail.mud.yahoo.com>
	<4703C74C.6060603@amd.com>
Message-ID: <200710040827.41570.juergen127@kreuzholzen.de>

Marc,

On Wednesday 03 October 2007 18:46, Marc Jones wrote:
> Glad it worked. I don't know enough about the kernel to know if the
> failed message is important. It seems to have a fallback mechanism. I
> also haven't followed the 5530 kernel patch debate. Maybe someone else
> here has the knowledge?

The kernel found the IRQ routing table and now it tries to route this IRQ. As 
it does not know the 5530 IRQ router it would switch to BIOS32 services to do 
so. But there is no BIOS32 service, so it fails. But also it does not touch 
the steering registers. So your solution works.

Juergen



From info at coresystems.de  Thu Oct  4 09:12:58 2007
From: info at coresystems.de (LinuxBIOS information)
Date: Thu, 04 Oct 2007 09:12:58 +0200
Subject: [LinuxBIOS] r2820 build service
Message-ID: <E1IdKtG-0007b9-Mb@khepri.openbios.org>

Dear LinuxBIOS readers!

This is the automated build check service of LinuxBIOS.

The developer "stepan" checked in revision 2820 to
the LinuxBIOS source repository and caused the following 
changes:

Change Log:
[FLASHROM] Fix the help, and print a message when nothing happens

The help implied that writes happen by default, which they don't.  Fix
the text, and say something when we dont specify any commands.

Signed-off-by: Jordan Crouse <jordan.crouse at amd.com>
Acked-by: Stefan Reinauer <stepan at coresystems.de>



Build Log:
Compilation of arima:hdama is still broken
See the error log at http://qa.linuxbios.org/log_buildbrd.php?revision=2820&device=hdama&vendor=arima
Compilation of ibm:e325 is still broken
See the error log at http://qa.linuxbios.org/log_buildbrd.php?revision=2820&device=e325&vendor=ibm
Compilation of ibm:e326 is still broken
See the error log at http://qa.linuxbios.org/log_buildbrd.php?revision=2820&device=e326&vendor=ibm
Compilation of iei:juki-511p is still broken
See the error log at http://qa.linuxbios.org/log_buildbrd.php?revision=2820&device=juki-511p&vendor=iei
Compilation of iwill:dk8s2 is still broken
See the error log at http://qa.linuxbios.org/log_buildbrd.php?revision=2820&device=dk8s2&vendor=iwill
Compilation of iwill:dk8x is still broken
See the error log at http://qa.linuxbios.org/log_buildbrd.php?revision=2820&device=dk8x&vendor=iwill
Compilation of newisys:khepri is still broken
See the error log at http://qa.linuxbios.org/log_buildbrd.php?revision=2820&device=khepri&vendor=newisys


If something broke during this checkin please be a pain 
in stepan's neck until the issue is fixed.

If this issue is not fixed within 24h the revision should 
be backed out.

   Best regards,
     LinuxBIOS automatic build system





From peter at stuge.se  Thu Oct  4 10:04:57 2007
From: peter at stuge.se (Peter Stuge)
Date: Thu, 4 Oct 2007 10:04:57 +0200
Subject: [LinuxBIOS] patch: filo
In-Reply-To: <20071004061419.GB7211@coresystems.de>
References: <13426df10710021218o70c53799wf7d8e987524472b0@mail.gmail.com>
	<20071004061419.GB7211@coresystems.de>
Message-ID: <20071004080457.8656.qmail@stuge.se>

On Thu, Oct 04, 2007 at 08:14:19AM +0200, Stefan Reinauer wrote:
> We should also get Peter's speedup patch in.

Maybe, but note that it does introduce at least one new bugs where
FILO is unable to load more than one file. (Ie when using an initrd
it often fails.)

I thought this was because I broke the simple yet effective caching
system in FILO's block layer, but I looked it over and it did seem
OK. I have not had time to investigate further.

Furthermore I think the patch still hoses FILO in VMware.


> Which is the latest version of that one?

6, but I don't want to sign it off until those two issues are fixed.
If anyone feels like helping out, please do.


//Peter



From ward at gnu.org  Thu Oct  4 15:07:27 2007
From: ward at gnu.org (Ward Vandewege)
Date: Thu, 4 Oct 2007 09:07:27 -0400
Subject: [LinuxBIOS] badly initialized (?) pci bridge on the M57SLI
	(with irq table and mptable)
In-Reply-To: <1191468741.47045ec51281d@imp.free.fr>
References: <20070919212952.GA16399@localdomain>
	<2ea3fae10709191629w17affbaeh4daf8a0715737ad2@mail.gmail.com>
	<1190278384.46f234f055fc2@imp.free.fr>
	<2ea3fae10709200944o6ebbc89p74ddd188db4826e1@mail.gmail.com>
	<20070924213615.GB26022@greenwood>
	<2ea3fae10709241623l1b579378td2605ddad12be414@mail.gmail.com>
	<1190713007.46f8d6af1483e@imp.free.fr>
	<2ea3fae10709251226x4098fce2o56d61dbec6af9447@mail.gmail.com>
	<1190858035.46fb0d33df9c7@imp.free.fr>
	<1191468741.47045ec51281d@imp.free.fr>
Message-ID: <20071004130727.GA8042@localdomain>

On Thu, Oct 04, 2007 at 05:32:21AM +0200, echelon at free.fr wrote:
> I propose:
> 
> $(LB)/src/mainboard/gigabyte/m57sli/cache_as_ram_auto.c
> 138c138
> <  RES_PORT_IO_8, SYSCTRL_IO_BASE + 0xc0+38, 0x00, 0x44,/* GPIO39 PCI_GNT3 */ \
> ---
> >  RES_PORT_IO_8, SYSCTRL_IO_BASE + 0xc0+38, 0x00, 0x68,/* GPIO39 PCI_GNT3 */ \
> 
> My vga pci card and a pci network card are recognised with this under LinuxBIOS!
> I don't understand why this works, but it works..
> (I will explain tomorrow how I found this value)

Owwww, please *do* tell how you figured this one out!

> Please can someone validate my change?

I don't have a V2 yet that has been hardware modded, but perhaps I can try it
on a V1 today, I'll see.

Thanks,
Ward.

-- 
Ward Vandewege <ward at fsf.org>
Free Software Foundation - Senior System Administrator



From rasmus at wiman.org  Thu Oct  4 15:29:44 2007
From: rasmus at wiman.org (Rasmus Wiman)
Date: Thu, 4 Oct 2007 15:29:44 +0200
Subject: [LinuxBIOS] [IMPORT] GIGABYTE GA-2761GXDK
In-Reply-To: <20071004025851.GA32267@greenwood>
References: <006b01c8058d$38dc52f0$0200a8c0@sis.com.tw>
	<Pine.LNX.4.64.0710030928160.3653@bigred.russwhit.org>
	<001d01c8062e$4cdbbab0$0200a8c0@sis.com.tw>
	<20071004025851.GA32267@greenwood>
Message-ID: <20071004152944.c0852d9e.rasmus@wiman.org>

Uwe Hermann <uwe at hermann-uwe.de> wrote:

> Are there any existing mainstream boards which can use this code
> already? Stuff you can buy in computer shops, not prototype boards?

I searched for "761GX" in a few webshops and came across this:
<http://global.shuttle.com/Product/Barebone/SS21T.asp>, a Shuttle
barebone which uses, according to Shuttle, "SiS? 761GX and SiS? 966L?
Chipset". I don't know if the L is significant, but I guess it could be
worth a try.

/Rasmus



From rasmus at wiman.org  Thu Oct  4 16:19:56 2007
From: rasmus at wiman.org (Rasmus Wiman)
Date: Thu, 4 Oct 2007 16:19:56 +0200
Subject: [LinuxBIOS] Call for help: superiotool
In-Reply-To: <20071004022202.GA30344@greenwood>
References: <20070923111315.GC12926@greenwood>
	<20071002152938.084fdaef.rasmus@wiman.org>
	<20071004022202.GA30344@greenwood>
Message-ID: <20071004161956.5da07672.rasmus@wiman.org>

Uwe Hermann <uwe at hermann-uwe.de> wrote:

> Interesting. I can't find a datasheet for the LPC47B387, so dump
> support won't happen anytime soon. But it would be nice if you could
> re-run 'superiotool -V' on that box with my latest patch applied
> ([PATCH] superiotool: Various improvements). That should tell us the
> Super I/O ID, I hope, so we can at least detect the chip.

Ok, here is the result:
./superiotool -V
superiotool r2815
Probing for ALi Super I/O at 0x3f0...
  Failed. Returned data: id=0x0000, rev=0x00
Probing for ALi Super I/O at 0x370...
  Failed. Returned data: id=0xffff, rev=0xff
Probing for NSC Super I/O at 0x2e...
  Failed. Returned data: port=0xff, port+1=0xff
Probing for NSC Super I/O at 0x4e...
  Failed. Returned data: port=0xff, port+1=0xff
Probing for Fintek Super I/O at 0x2e...
  Failed. Returned data: vid=0xffff, id=0xffff
Probing for Fintek Super I/O at 0x4e...
  Failed. Returned data: vid=0xffff, id=0xffff
Probing for ITE Super I/O (init=0x87,0x01,0x55,0x55/0xaa) at 0x2e...
  Failed. Returned data: id=0x6e00, rev=0x9
Probing for ITE Super I/O (init=0x87,0x87) at 0x2e...
  Failed. Returned data: id=0x6e00, rev=0x9
Probing for ITE Super I/O (init=0x87,0x01,0x55,0x55/0xaa) at 0x4e...
  Failed. Returned data: id=0xffff, rev=0xf
Probing for ITE Super I/O (init=0x87,0x87) at 0x4e...
  Failed. Returned data: id=0xffff, rev=0xf
Probing for SMSC Super I/O (idregs=0x20/0x21) at 0x2e...
  Failed. Returned data: id=0x6e, rev=0x00
Probing for SMSC Super I/O (idregs=0x0d/0x0e) at 0x2e...
  Failed. Returned data: id=0x00, rev=0x00
Probing for SMSC Super I/O (idregs=0x20/0x21) at 0x4e...
  Failed. Returned data: id=0xff, rev=0xff
Probing for SMSC Super I/O (idregs=0x0d/0x0e) at 0x4e...
  Failed. Returned data: id=0xff, rev=0xff
Probing for SMSC Super I/O (idregs=0x20/0x21) at 0x3f0...
  Failed. Returned data: id=0x00, rev=0x00
Probing for SMSC Super I/O (idregs=0x0d/0x0e) at 0x3f0...
  Failed. Returned data: id=0x00, rev=0x00
Probing for SMSC Super I/O (idregs=0x20/0x21) at 0x370...
  Failed. Returned data: id=0xff, rev=0xff
Probing for SMSC Super I/O (idregs=0x0d/0x0e) at 0x370...
  Failed. Returned data: id=0xff, rev=0xff
Probing for Winbond Super I/O (init=0x88) at 0x2e...
  Failed. Returned data: id/oldid=0xff/0x0f, rev=0xff
Probing for Winbond Super I/O (init=0x89) at 0x2e...
  Failed. Returned data: id/oldid=0xff/0x0f, rev=0xff
Probing for Winbond Super I/O (init=0x86,0x86) at 0x2e...
  Failed. Returned data: id/oldid=0xff/0x0f, rev=0xff
Probing for Winbond Super I/O (init=0x87,0x87) at 0x2e...
  Failed. Returned data: id/oldid=0xff/0x0f, rev=0xff
Probing for Winbond Super I/O (init=0x88) at 0x4e...
  Failed. Returned data: id/oldid=0xff/0x0f, rev=0xff
Probing for Winbond Super I/O (init=0x89) at 0x4e...
  Failed. Returned data: id/oldid=0xff/0x0f, rev=0xff
Probing for Winbond Super I/O (init=0x86,0x86) at 0x4e...
  Failed. Returned data: id/oldid=0xff/0x0f, rev=0xff
Probing for Winbond Super I/O (init=0x87,0x87) at 0x4e...
  Failed. Returned data: id/oldid=0xff/0x0f, rev=0xff
Probing for Winbond Super I/O (init=0x88) at 0x3f0...
  Failed. Returned data: id/oldid=0x00/0x00, rev=0x00
Probing for Winbond Super I/O (init=0x89) at 0x3f0...
  Failed. Returned data: id/oldid=0x00/0x00, rev=0x00
Probing for Winbond Super I/O (init=0x86,0x86) at 0x3f0...
  Failed. Returned data: id/oldid=0x00/0x00, rev=0x00
Probing for Winbond Super I/O (init=0x87,0x87) at 0x3f0...
  Failed. Returned data: id/oldid=0x00/0x00, rev=0x00
Probing for Winbond Super I/O (init=0x88) at 0x370...
  Failed. Returned data: id/oldid=0xff/0x0f, rev=0xff
Probing for Winbond Super I/O (init=0x89) at 0x370...
  Failed. Returned data: id/oldid=0xff/0x0f, rev=0xff
Probing for Winbond Super I/O (init=0x86,0x86) at 0x370...
  Failed. Returned data: id/oldid=0xff/0x0f, rev=0xff
Probing for Winbond Super I/O (init=0x87,0x87) at 0x370...
  Failed. Returned data: id/oldid=0xff/0x0f, rev=0xff
Probing for Winbond Super I/O (init=0x88) at 0x250...
  Failed. Returned data: id/oldid=0xff/0x0f, rev=0xff
Probing for Winbond Super I/O (init=0x89) at 0x250...
  Failed. Returned data: id/oldid=0xff/0x0f, rev=0xff
Probing for Winbond Super I/O (init=0x86,0x86) at 0x250...
  Failed. Returned data: id/oldid=0xff/0x0f, rev=0xff
Probing for Winbond Super I/O (init=0x87,0x87) at 0x250...
  Failed. Returned data: id/oldid=0xff/0x0f, rev=0xff

By the way, svn said I checked out r2820, but superiotool says r2815. 

/Rasmus



From rminnich at gmail.com  Thu Oct  4 16:44:28 2007
From: rminnich at gmail.com (ron minnich)
Date: Thu, 4 Oct 2007 07:44:28 -0700
Subject: [LinuxBIOS] patch: fix filo dependency on memory being zero
In-Reply-To: <20071004054415.GB2540@coresystems.de>
References: <13426df10710031123t406504bxdfa9b45e4ad7194b@mail.gmail.com>
	<13426df10710031340o2469373ape2e7212e485524e7@mail.gmail.com>
	<20071004054415.GB2540@coresystems.de>
Message-ID: <13426df10710040744k94aaa0ap7c58331c51155993@mail.gmail.com>

On 10/3/07, Stefan Reinauer <stepan at coresystems.de> wrote:

> > This patch makes qemu work again on v3. FILO was depending on bss being zero, which is not all that safe in embedded. It's better to zero things you are depending on being zero.
> > Signed-off-by: Ronald G. Minnich <rminnich at gmail.com>
>
> Let me guess.. is this with PAYLOAD_PREPARSE_ELF enabled?

not at all. It failed with either elf or not elf. The code in FILO
depends on BSS being zero'd. That's not a safe assumption. The fix
turned out to be very, very simple as you can see :-)

>
> What else is different in "embedded" when running LinuxBIOS?

The biggest is that you really can not assume anything about the state
of memory. In fact, it would be desirable to have linuxbios NOT zero
memory, in the event you are recovering from a failure and would like
a memory dump. In the pre-PC days, it was not unusual to scan memory
after reboot when a failure had occurred.

ron



From svn at openbios.org  Thu Oct  4 17:23:39 2007
From: svn at openbios.org (svn at openbios.org)
Date: Thu,  4 Oct 2007 17:23:39 +0200
Subject: [LinuxBIOS] r2821 - trunk/util/superiotool
Message-ID: <mailman.696.1355071172.16123.coreboot@coreboot.org>

Author: uwe
Date: 2007-10-04 17:23:38 +0200 (Thu, 04 Oct 2007)
New Revision: 2821

Modified:
   trunk/util/superiotool/ali.c
   trunk/util/superiotool/fintek.c
   trunk/util/superiotool/ite.c
   trunk/util/superiotool/nsc.c
   trunk/util/superiotool/smsc.c
   trunk/util/superiotool/superiotool.c
   trunk/util/superiotool/superiotool.h
   trunk/util/superiotool/winbond.c
Log:
 * Convert the NSC code to the common code structure all other Super I/Os use.

 * Improve the --verbose output a bit more. Print the "Probing..." text for
   all Super I/Os and if a Super I/O is not known, show the data we were
   able to read from the chip (what data this is is very vendor/chip specific).

 * Thus the common no_superio_found() is dropped, it's not useful.
   The "read from 0x20" part was wrong for all Super I/Os other than the
   NSC ones anyway.

 * Winbond: For the 'olddevid' only use bits 3..0, mask away the others.

 * SMSC: Print which ID registers we try to read (in --verbose mode).

 * Minor cosmetic fixes.
   * Rename PC8374 to PC8374L (as per datasheet).
   * Rename probe_idregs_simple() to probe_idregs_nsc().
   * Rename dump_readable_ns8374() to dump_readable_pc8374l().

Signed-off-by: Uwe Hermann <uwe at hermann-uwe.de>
Acked-by: Stefan Reinauer <stepan at coresystems.de>



Modified: trunk/util/superiotool/ali.c
===================================================================
--- trunk/util/superiotool/ali.c	2007-10-04 06:26:41 UTC (rev 2820)
+++ trunk/util/superiotool/ali.c	2007-10-04 15:23:38 UTC (rev 2821)
@@ -72,6 +72,8 @@
 	uint16_t id;
 	uint8_t rev;
 
+	probing_for("ALi", "", port);
+
 	enter_conf_mode_ali(port);
 
 	id = regval(port, DEVICE_ID_BYTE1_REG) << 8;
@@ -79,7 +81,8 @@
 	rev = regval(port, DEVICE_REV_REG);
 
 	if (superio_unknown(reg_table, id)) {
-		no_superio_found("ALi", "", port);
+		if (verbose)
+			printf(NOTFOUND "id=0x%04x, rev=0x%02x\n", id, rev);
 		exit_conf_mode_ali(port);
 		return;
 	}

Modified: trunk/util/superiotool/fintek.c
===================================================================
--- trunk/util/superiotool/fintek.c	2007-10-04 06:26:41 UTC (rev 2820)
+++ trunk/util/superiotool/fintek.c	2007-10-04 15:23:38 UTC (rev 2821)
@@ -136,6 +136,8 @@
 {
 	uint16_t vid, did;
 
+	probing_for("Fintek", "", port);
+
 	enter_conf_mode_winbond_fintek_ite_8787(port);
 
 	did = regval(port, DEVICE_ID_BYTE1_REG);
@@ -145,12 +147,13 @@
 	vid |= (regval(port, VENDOR_ID_BYTE2_REG) << 8);
 
 	if (vid != FINTEK_VENDOR_ID || superio_unknown(reg_table, did)) {
-		no_superio_found("Fintek", "", port);
+		if (verbose)
+			printf(NOTFOUND "vid=0x%04x, id=0x%04x\n", vid, did);
 		exit_conf_mode_winbond_fintek_ite_8787(port);
 		return;
 	}
 
-	printf("Found Fintek %s (vid=0x%04x, id=0x%04x) at port=0x%x\n",
+	printf("Found Fintek %s (vid=0x%04x, id=0x%04x) at 0x%x\n",
 	       get_superio_name(reg_table, did), vid, did, port);
 
 	dump_superio("Fintek", reg_table, port, did);

Modified: trunk/util/superiotool/ite.c
===================================================================
--- trunk/util/superiotool/ite.c	2007-10-04 06:26:41 UTC (rev 2820)
+++ trunk/util/superiotool/ite.c	2007-10-04 15:23:38 UTC (rev 2821)
@@ -23,6 +23,7 @@
 
 #define CHIP_ID_BYTE1_REG	0x20
 #define CHIP_ID_BYTE2_REG	0x21
+
 #define CHIP_VERSION_REG	0x22
 
 /* Note: IT8726F has ID 0x8726 (datasheet wrongly says 0x8716). */
@@ -265,17 +266,20 @@
 {
 	uint16_t id, chipver;
 
+	probing_for("ITE", init, port);
+
 	id = regval(port, CHIP_ID_BYTE1_REG) << 8;
 	id |= regval(port, CHIP_ID_BYTE2_REG);
 	chipver = regval(port, CHIP_VERSION_REG) & 0x0f; /* Only bits 3..0 */
 
 	if (superio_unknown(reg_table, id)) {
-		no_superio_found("ITE", init, port);
+		if (verbose)
+			printf(NOTFOUND "id=0x%04x, rev=0x%01x\n", id, chipver);
 		exit_conf_mode_ite(port);
 		return;
 	}
 
-	printf("Found ITE %s (id=0x%04x, rev=0x%01x) at port=0x%x\n",
+	printf("Found ITE %s (id=0x%04x, rev=0x%01x) at 0x%x\n",
 	       get_superio_name(reg_table, id), id, chipver, port);
 
 	dump_superio("ITE", reg_table, port, id);

Modified: trunk/util/superiotool/nsc.c
===================================================================
--- trunk/util/superiotool/nsc.c	2007-10-04 06:26:41 UTC (rev 2820)
+++ trunk/util/superiotool/nsc.c	2007-10-04 15:23:38 UTC (rev 2821)
@@ -2,6 +2,7 @@
  * This file is part of the superiotool project.
  *
  * Copyright (C) 2006 Ronald Minnich <rminnich at gmail.com>
+ * Copyright (C) 2007 Uwe Hermann <uwe at hermann-uwe.de>
  *
  * This program is free software; you can redistribute it and/or modify
  * it under the terms of the GNU General Public License as published by
@@ -20,16 +21,23 @@
 
 #include "superiotool.h"
 
-/* Well, they really thought this through, eh? Family is 8 bits! */
-static const char *familyid[] = {
-	[0xf1] = "PC8374 (Winbond/NatSemi)"
+#define CHIP_ID_REG	0x20	/* Super I/O ID (SID) / family */
+#define CHIP_REV_REG	0x27	/* Super I/O revision ID (SRID) */
+
+/* SID[7..0]: chip family. SRID[7..5]: chip ID, SRID[4..0]: chip rev. */
+const static struct superio_registers reg_table[] = {
+	{0xf1, "PC8374L", {
+		{EOT}}},
+	{EOT}
 };
 
-static void dump_readable_ns8374(uint16_t port)
+static void dump_readable_pc8374l(uint16_t port)
 {
 	if (!dump_readable)
 		return;
 
+	printf("Human-readable register dump:\n");
+
 	printf("Enables: 21=%02x, 22=%02x, 23=%02x, 24=%02x, 26=%02x\n",
 	       regval(port, 0x21), regval(port, 0x22), regval(port, 0x23),
 	       regval(port, 0x24), regval(port, 0x26));
@@ -59,34 +67,40 @@
 	     regval(port, 0xf0));
 }
 
-void probe_idregs_simple(uint16_t port)
+void probe_idregs_nsc(uint16_t port)
 {
-	uint16_t id;
+	uint8_t id, rev;
 
-	outb(0x20, port);
-	if (inb(port) != 0x20) {
-		no_superio_found("NSC", "", port);
-		/* TODO: Exit config mode? */
+	probing_for("NSC", "", port);
+
+	outb(CHIP_ID_REG, port);
+	if (inb(port) != CHIP_ID_REG) {
+		if (verbose)
+			printf(NOTFOUND "port=0x%02x, port+1=0x%02x\n",
+			       inb(port), inb(port + 1));
 		return;
 	}
 	id = inb(port + 1);
 
-	printf("Super I/O found at 0x%02x: id = 0x%02x\n", port, id);
-	if (id == 0xff)
+	outb(CHIP_REV_REG, port);
+	if (inb(port) != CHIP_REV_REG) {
+		printf("Warning: Can't get chip revision. Setting to 0xff.\n");
+		rev = 0xff;
+	} else {
+		rev = inb(port + 1);
+	}
+
+	if (superio_unknown(reg_table, id)) {
+		if (verbose)
+			printf(NOTFOUND "sid=0x%02x, srid=0x%02x\n", id, rev);
 		return;
+	}
 
-	if (familyid[id])
-		printf("%s\n", familyid[id]);
-	else
-		printf("<unknown>\n");
+	printf("Found NSC %s (sid=0x%02x, srid=0x%02x) at 0x%x\n",
+	       get_superio_name(reg_table, id), id, rev, port);
 
-	switch (id) {
-	case 0xf1:
-		dump_readable_ns8374(port);
-		break;
-	default:
-		printf("No dump for 0x%02x\n", id);
-		break;
-	}
+	dump_superio("NSC", reg_table, port, id);
+	if (id == 0xf1)
+		dump_readable_pc8374l(port);
 }
 

Modified: trunk/util/superiotool/smsc.c
===================================================================
--- trunk/util/superiotool/smsc.c	2007-10-04 06:26:41 UTC (rev 2820)
+++ trunk/util/superiotool/smsc.c	2007-10-04 15:23:38 UTC (rev 2821)
@@ -133,19 +133,24 @@
 				     uint8_t revreg)
 {
 	uint8_t id, rev;
+	const char *info = (idreg == 0x20) ? "(idregs=0x20/0x21) "
+					   : "(idregs=0x0d/0x0e) ";
 
+	probing_for("SMSC", info, port);
+
 	enter_conf_mode_smsc(port);
 
 	id = regval(port, idreg);
 	rev = regval(port, revreg);
 
 	if (superio_unknown(reg_table, id)) {
-		no_superio_found("SMSC", "", port);
+		if (verbose)
+			printf(NOTFOUND "id=0x%02x, rev=0x%02x\n", id, rev);
 		exit_conf_mode_smsc(port);
 		return;
 	}
 
-	printf("Found %s %s (id=0x%02x, rev=0x%02x) at port=0x%x\n",
+	printf("Found %s %s (id=0x%02x, rev=0x%02x) at 0x%x\n",
 	       (id == 0x77 ? "ASUS" : "SMSC"), get_superio_name(reg_table, id),
 	       id, rev, port);
 

Modified: trunk/util/superiotool/superiotool.c
===================================================================
--- trunk/util/superiotool/superiotool.c	2007-10-04 06:26:41 UTC (rev 2820)
+++ trunk/util/superiotool/superiotool.c	2007-10-04 15:23:38 UTC (rev 2821)
@@ -155,18 +155,14 @@
 		printf("No human-readable dump available for this Super I/O\n");
 }
 
-void no_superio_found(const char *vendor, const char *info, uint16_t port)
+void probing_for(const char *vendor, const char *info, uint16_t port)
 {
 	if (!verbose)
 		return;
 
-	if (inb(port) == 0xff)
-		/* Yes, there's no space between '%s' and 'at'! */
-		printf("Probing for %s Super I/O %sat 0x%x... failed\n",
-		       vendor, info, port);
-	else
-		printf("Probing 0x%x, failed (0x%02x), data returns 0x%02x\n",
-		       port, inb(port), inb(port + 1));
+	/* Yes, there's no space between '%s' and 'at'! */
+	printf("Probing for %s Super I/O %sat 0x%x...\n",
+	       vendor, info, port);
 }
 
 static void print_version(void)

Modified: trunk/util/superiotool/superiotool.h
===================================================================
--- trunk/util/superiotool/superiotool.h	2007-10-04 06:26:41 UTC (rev 2820)
+++ trunk/util/superiotool/superiotool.h	2007-10-04 15:23:38 UTC (rev 2821)
@@ -40,6 +40,8 @@
 Per default (no options) superiotool will just probe for a Super I/O\n\
 and print its vendor, name, ID, revision, and config port.\n"
 
+#define NOTFOUND "  Failed. Returned data: "
+
 #define ARRAY_SIZE(a) (sizeof(a) / sizeof((a)[0]))
 
 #define EOT		-1		/* End Of Table */
@@ -79,7 +81,7 @@
 void dump_superio(const char *name, const struct superio_registers reg_table[],
 		  uint16_t port, uint16_t id);
 void dump_superio_readable(uint16_t port);
-void no_superio_found(const char *vendor, const char *info, uint16_t port);
+void probing_for(const char *vendor, const char *info, uint16_t port);
 
 /* ali.c */
 void probe_idregs_ali(uint16_t port);
@@ -91,7 +93,7 @@
 void probe_idregs_ite(uint16_t port);
 
 /* nsc.c */
-void probe_idregs_simple(uint16_t port);
+void probe_idregs_nsc(uint16_t port);
 
 /* smsc.c */
 void probe_idregs_smsc(uint16_t port);
@@ -105,7 +107,7 @@
 	int ports[MAXNUMPORTS]; /* Signed, as we need EOT. */
 } superio_ports_table[] = {
 	{probe_idregs_ali,	{0x3f0, 0x370, EOT}},
-	{probe_idregs_simple,	{0x2e, 0x4e, EOT}},
+	{probe_idregs_nsc,	{0x2e, 0x4e, EOT}},
 	{probe_idregs_fintek,	{0x2e, 0x4e, EOT}},
 	{probe_idregs_ite,	{0x2e, 0x4e, EOT}},
 	{probe_idregs_smsc,	{0x2e, 0x4e, 0x3f0, 0x370, EOT}},

Modified: trunk/util/superiotool/winbond.c
===================================================================
--- trunk/util/superiotool/winbond.c	2007-10-04 06:26:41 UTC (rev 2820)
+++ trunk/util/superiotool/winbond.c	2007-10-04 15:23:38 UTC (rev 2821)
@@ -184,9 +184,11 @@
 	uint16_t id;
 	uint8_t devid, rev, olddevid;
 
+	probing_for("Winbond", init, port);
+
 	devid = regval(port, DEVICE_ID_REG);
 	rev = regval(port, DEVICE_REV_REG);
-	olddevid = regval(port, DEVICE_ID_REG_OLD);
+	olddevid = regval(port, DEVICE_ID_REG_OLD) & 0x0f;
 
 	if (devid == 0x52)
 		id = devid;				 /* ID only */
@@ -199,7 +201,9 @@
 		id = olddevid & 0x0f;			 /* ID[3..0] */
 
 	if (superio_unknown(reg_table, id)) {
-		no_superio_found("Winbond", init, port);
+		if (verbose)
+			printf(NOTFOUND "id/oldid=0x%02x/0x%02x, rev=0x%02x\n",
+			       devid, olddevid, rev);
 		exit_conf_mode_winbond_fintek_ite_8787(port);
 		return;
 	}




From uwe at hermann-uwe.de  Thu Oct  4 17:25:19 2007
From: uwe at hermann-uwe.de (Uwe Hermann)
Date: Thu, 4 Oct 2007 17:25:19 +0200
Subject: [LinuxBIOS] [PATCH] superiotool: Various improvements
In-Reply-To: <20071004052932.GA639@coresystems.de>
References: <20071004003311.GC14438@greenwood>
	<20071004052932.GA639@coresystems.de>
Message-ID: <20071004152519.GC32267@greenwood>

On Thu, Oct 04, 2007 at 07:29:33AM +0200, Stefan Reinauer wrote:
> * Uwe Hermann <uwe at hermann-uwe.de> [071004 02:33]:
> >  * Convert the NSC code to the common code structure all other Super I/Os use.
> > 
> >  * Improve the --verbose output a bit more. Print the "Probing..." text for
> >    all Super I/Os and if a Super I/O is not known, show the data we were
> >    able to read from the chip (what data this is is very vendor/chip specific).
> > 
> >  * Thus the common no_superio_found() is dropped, it's not useful.
> >    The "read from 0x20" part was wrong for all Super I/Os other than the
> >    NSC ones anyway.
> > 
> >  * Winbond: For the 'olddevid' only use bits 3..0, mask away the others.
> > 
> >  * SMSC: Print which ID registers we try to read (in --verbose mode).
> > 
> >  * Minor cosmetic fixes.
> >    * Rename PC8374 to PC8374L (as per datasheet).
> >    * Rename probe_idregs_simple() to probe_idregs_nsc().
> >    * Rename dump_readable_ns8374() to dump_readable_pc8374l().
> > 
> > Signed-off-by: Uwe Hermann <uwe at hermann-uwe.de>
>  
> Acked-by: Stefan Reinauer <stepan at coresystems.de>

Thanks, r2821.


Uwe.
-- 
http://www.hermann-uwe.de  | http://www.holsham-traders.de
http://www.crazy-hacks.org | http://www.unmaintained-free-software.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20071004/1893db9c/attachment.sig>

From svn at openbios.org  Thu Oct  4 17:44:19 2007
From: svn at openbios.org (svn at openbios.org)
Date: Thu,  4 Oct 2007 17:44:19 +0200
Subject: [LinuxBIOS] r2822 - trunk/util/superiotool
Message-ID: <mailman.697.1355071172.16123.coreboot@coreboot.org>

Author: uwe
Date: 2007-10-04 17:44:19 +0200 (Thu, 04 Oct 2007)
New Revision: 2822

Modified:
   trunk/util/superiotool/ite.c
Log:
Add dump support for the ITE IT8705F/AF.

Signed-off-by: Robinson P. Tryon <bishop.robinson at gmail.com>
Acked-by: Uwe Hermann <uwe at hermann-uwe.de>



Modified: trunk/util/superiotool/ite.c
===================================================================
--- trunk/util/superiotool/ite.c	2007-10-04 15:23:38 UTC (rev 2821)
+++ trunk/util/superiotool/ite.c	2007-10-04 15:44:19 UTC (rev 2822)
@@ -30,7 +30,53 @@
 const static struct superio_registers reg_table[] = {
 	{0x8702, "IT8702F", {
 		{EOT}}},
-	{0x8705, "IT8705F or IT8700F", {
+	{0x8705, "IT8705F/AF or IT8700F", {
+		{NOLDN, NULL,
+			{0x07,0x20,0x21,0x22,0x23,0x24,EOT},
+			{NANA,0x87,0x05,0x00,0x00,NANA,EOT}},
+		{0x0, "Floppy",
+			{0x30,0x60,0x61,0x70,0x74,0xf0,0xf1,EOT},
+			{0x00,0x03,0xf0,0x06,0x02,0x00,0x00,EOT}},
+		{0x1, "COM1",
+			{0x30,0x60,0x61,0x70,0xf0,EOT},
+			{0x00,0x03,0xf8,0x04,0x00,EOT}},
+		{0x2, "COM2",
+			{0x30,0x60,0x61,0x70,0xf0,0xf1,0xf2,0xf3,EOT},
+			{0x00,0x02,0xf8,0x03,0x00,0x50,0x00,0x7f,EOT}},
+		{0x3, "Parallel port",
+			{0x30,0x60,0x61,0x62,0x63,0x64,0x65,0x70,0x74,
+			 0xf0,EOT},
+			{0x00,0x03,0x78,0x07,0x78,0x00,0x80,0x07,0x03,
+			 0x03,EOT}},
+		{0x4, "Environment controller",
+			{0x2b,0x30,0x60,0x61,0x62,0x63,0x70,0xf0,0xf1,0xf2,
+			 0xf3,0xf4,0xf5,0xf6,EOT},
+			{0x00,0x00,0x02,0x90,0x02,0x30,0x09,0x00,0x00,0x00,
+			 0x00,0x00,NANA,NANA,EOT}},
+		{0x5, "GPIO",
+			{0x25,0x26,0x27,0x28,0x29,0x2a,0x2b,0x60,0x61,0x62,
+			 0x63,0x64,0x65,0x70,0x71,0x72,0xb0,0xb1,0xb2,0xb3,
+			 0xb4,0xb5,0xb8,0xb9,0xba,0xbb,0xbc,0xbd,0xc0,0xc1,
+			 0xc2,0xc3,0xc4,0xc5,0xc8,0xc9,0xca,0xcb,0xcc,0xcd,
+			 0xd0,0xd1,0xd2,0xd3,0xd4,0xd5,0xd6,0xd8,0xd9,0xda,
+			 0xf0,0xf1,0xf2,0xf5,0xf6,0xf7,0xf8,0xf9,0xfa,0xfb,
+			 0xfc,0xfd,0xfe,0xff,EOT},
+			{0x00,0x00,0x00,0xff,0xe0,0xff,0x00,0x00,0x00,0x00,
+			 0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,
+			 0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,
+			 0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,
+			 0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,
+			 0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,
+			 0x00,0x00,NANA,0x00,EOT}},
+		{0x6, "Game port",
+			{0x30,0x60,0x61,EOT},
+			{0x00,0x02,0x01,EOT}},
+		{0x7, "Consumer IR",
+			{0x30,0x60,0x61,0x70,0xf0,EOT},
+			{0x00,0x03,0x10,0x0b,0x00,EOT}},
+		{0x8, "MIDI port",
+			{0x30,0x60,0x61,0x70,0xf0,EOT},
+			{0x00,0x03,0x00,0x0a,0x00,EOT}},
 		{EOT}}},
 	{0x8708, "IT8708F", {
 		{NOLDN, NULL,




From uwe at hermann-uwe.de  Thu Oct  4 17:46:21 2007
From: uwe at hermann-uwe.de (Uwe Hermann)
Date: Thu, 4 Oct 2007 17:46:21 +0200
Subject: [LinuxBIOS] superiotool - IT8705F dump support
In-Reply-To: <a698c16a0710032209ne8a672kbce87c4f3ca6b6b5@mail.gmail.com>
References: <a698c16a0710032209ne8a672kbce87c4f3ca6b6b5@mail.gmail.com>
Message-ID: <20071004154621.GD32267@greenwood>

On Thu, Oct 04, 2007 at 01:09:04AM -0400, Robinson Tryon wrote:
> Here's a patch for the IT8705F.  I followed the structure of the other
> ITE chips in the table.  How does it look?

Great, thanks! Committed in r2822 with two minor changes:

 - Use TABs for indentation everywhere.

 - Fixed one typo in the GPIO section (0xf5 was listed twice).

Can you post the dump output for this chip here?


Thanks, Uwe.
-- 
http://www.hermann-uwe.de  | http://www.holsham-traders.de
http://www.crazy-hacks.org | http://www.unmaintained-free-software.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20071004/50e4fe2d/attachment.sig>

From bishop.robinson at gmail.com  Thu Oct  4 18:08:29 2007
From: bishop.robinson at gmail.com (Robinson Tryon)
Date: Thu, 4 Oct 2007 12:08:29 -0400
Subject: [LinuxBIOS] superiotool - IT8705F dump support
In-Reply-To: <20071004154621.GD32267@greenwood>
References: <a698c16a0710032209ne8a672kbce87c4f3ca6b6b5@mail.gmail.com>
	<20071004154621.GD32267@greenwood>
Message-ID: <a698c16a0710040908q212fb566oed5fb9a7badd7b96@mail.gmail.com>

On 10/4/07, Uwe Hermann <uwe at hermann-uwe.de> wrote:
> On Thu, Oct 04, 2007 at 01:09:04AM -0400, Robinson Tryon wrote:
> > Here's a patch for the IT8705F.  I followed the structure of the other
> > ITE chips in the table.  How does it look?
>
> Great, thanks! Committed in r2822 with two minor changes:
>
>  - Use TABs for indentation everywhere.

I noticed that -- I set c-style-mode in emacs to 'linux', but some of
the indentation was still slightly different from what was in ite.c.
Anyone have a suggestion on how I can fix this?

>
>  - Fixed one typo in the GPIO section (0xf5 was listed twice).
>
> Can you post the dump output for this chip here?

Oh I certainly would...if I had a system with that chip... :-)



From info at coresystems.de  Thu Oct  4 18:10:52 2007
From: info at coresystems.de (LinuxBIOS information)
Date: Thu, 04 Oct 2007 18:10:52 +0200
Subject: [LinuxBIOS] r2821 build service
Message-ID: <E1IdTHo-0005c7-FW@khepri.openbios.org>

Dear LinuxBIOS readers!

This is the automated build check service of LinuxBIOS.

The developer "uwe" checked in revision 2821 to
the LinuxBIOS source repository and caused the following 
changes:

Change Log:
 * Convert the NSC code to the common code structure all other Super I/Os use.

 * Improve the --verbose output a bit more. Print the "Probing..." text for
   all Super I/Os and if a Super I/O is not known, show the data we were
   able to read from the chip (what data this is is very vendor/chip specific).

 * Thus the common no_superio_found() is dropped, it's not useful.
   The "read from 0x20" part was wrong for all Super I/Os other than the
   NSC ones anyway.

 * Winbond: For the 'olddevid' only use bits 3..0, mask away the others.

 * SMSC: Print which ID registers we try to read (in --verbose mode).

 * Minor cosmetic fixes.
   * Rename PC8374 to PC8374L (as per datasheet).
   * Rename probe_idregs_simple() to probe_idregs_nsc().
   * Rename dump_readable_ns8374() to dump_readable_pc8374l().

Signed-off-by: Uwe Hermann <uwe at hermann-uwe.de>
Acked-by: Stefan Reinauer <stepan at coresystems.de>



Build Log:
Compilation of arima:hdama is still broken
See the error log at http://qa.linuxbios.org/log_buildbrd.php?revision=2821&device=hdama&vendor=arima
Compilation of ibm:e325 is still broken
See the error log at http://qa.linuxbios.org/log_buildbrd.php?revision=2821&device=e325&vendor=ibm
Compilation of ibm:e326 is still broken
See the error log at http://qa.linuxbios.org/log_buildbrd.php?revision=2821&device=e326&vendor=ibm
Compilation of iei:juki-511p is still broken
See the error log at http://qa.linuxbios.org/log_buildbrd.php?revision=2821&device=juki-511p&vendor=iei
Compilation of iwill:dk8s2 is still broken
See the error log at http://qa.linuxbios.org/log_buildbrd.php?revision=2821&device=dk8s2&vendor=iwill
Compilation of iwill:dk8x is still broken
See the error log at http://qa.linuxbios.org/log_buildbrd.php?revision=2821&device=dk8x&vendor=iwill
Compilation of newisys:khepri is still broken
See the error log at http://qa.linuxbios.org/log_buildbrd.php?revision=2821&device=khepri&vendor=newisys


If something broke during this checkin please be a pain 
in uwe's neck until the issue is fixed.

If this issue is not fixed within 24h the revision should 
be backed out.

   Best regards,
     LinuxBIOS automatic build system





From c-d.hailfinger.devel.2006 at gmx.net  Thu Oct  4 18:17:07 2007
From: c-d.hailfinger.devel.2006 at gmx.net (Carl-Daniel Hailfinger)
Date: Thu, 04 Oct 2007 18:17:07 +0200
Subject: [LinuxBIOS] flashrom support for AMD Geode CS5536
In-Reply-To: <20071002170126.GA27919@coresystems.de>
References: <47026FBB.1080809@mit.edu>	<13426df10710020938x276d2c3ewf797f82d035d1bd7@mail.gmail.com>
	<20071002170126.GA27919@coresystems.de>
Message-ID: <47051203.6090903@gmx.net>

On 02.10.2007 19:01, Stefan Reinauer wrote:
> * ron minnich <rminnich at gmail.com> [071002 18:38]:
>>> My questions are:
>>> - I do not think this is portable beyond linux.  Is that an issue?
>> it's not, but it is not really an issue at present.
> 
> Maybe the code should be #ifdef'ed __linux__ with an #else case just
> printing a warning a la "Not supported by this OS yet."
> 
>> I thought that was in the structure of flashrom. Now that I look, it
>> seems like we lost it!
> 
> Flashrom never did any such cleanup. I was about to implement it when we
> renamed the tool but then I stumbled upon this:
> 
> printf("OK, only ENABLING flash write, but NOT FLASHING.\n");
> 
> So obviously at some point there was a sense in leaving the system in
> such a state. But I want to propose that we drop this behavior and
> instead try to always leave the machine in the state we entered it.
> Especially when not flashing.
> 
> While one might want to mess with an unprotected flash on purpose, for
> 99% of the cases this is just opening another security issue.
> That one % that theoretically might use this as a feature is welcome to
> improve the flashrom utility instead of running it for flash
> unprotection before running another utility.

Agreed.

>> I propose this at the end of flashrom:
>> board_flash_disable(lb_vendor, lb_part);
>> chipset_flash_disable(chipset);
> 
> yepp. Agreed.

Disagree. We still have to store the previous state to be able to revert
to it.

>> but we'll need to change some things to make this all work. We need a
>> penable struct * to use for the disable; no point in searching each
>> time we touch a chip. or not?
> 
> To achieve this
> 
> struct board_pciid_enable *board in board_enable.c:board_flash_enable() 
> 
> and
> 
> enables[i] in chipset_enable.c:chipset_flash_enable() 
> 
> should be globally available.

Different proposal:
If a particular enable function has been run successfully, it should
store a pointer to the corresponding cleanup function and a pointer to
the data which has to be restored.

At least the restore information has to be available somewhere.
Otherwise the exercise is totally pointless since we can't know the
state before the enable function was run.

Carl-Daniel



From svn at openbios.org  Thu Oct  4 18:28:56 2007
From: svn at openbios.org (svn at openbios.org)
Date: Thu,  4 Oct 2007 18:28:56 +0200
Subject: [LinuxBIOS] r2823 - trunk/util/superiotool
Message-ID: <mailman.698.1355071172.16123.coreboot@coreboot.org>

Author: uwe
Date: 2007-10-04 18:28:56 +0200 (Thu, 04 Oct 2007)
New Revision: 2823

Modified:
   trunk/util/superiotool/smsc.c
Log:
Add detection support for the LPC47B387 (trivial).

Signed-off-by: Uwe Hermann <uwe at hermann-uwe.de>
Acked-by: Uwe Hermann <uwe at hermann-uwe.de>



Modified: trunk/util/superiotool/smsc.c
===================================================================
--- trunk/util/superiotool/smsc.c	2007-10-04 15:44:19 UTC (rev 2822)
+++ trunk/util/superiotool/smsc.c	2007-10-04 16:28:56 UTC (rev 2823)
@@ -58,6 +58,11 @@
 		{EOT}}},
 	{0x62, "LPC47S45x", {
 		{EOT}}},
+	{0x6e, "LPC47B387", {
+		/* Found in the HP Compaq Business Desktop d530 Series */
+		/* http://thread.gmane.org/gmane.linux.bios/26648 */
+		/* We cannot find a public datasheet for this Super I/O. */
+		{EOT}}},
 	{0x6f, "LPC47B397", {
 		{EOT}}},
 	{0x77, "A8000", {	/* ASUS A8000, a rebranded DME1737(?) */




From uwe at hermann-uwe.de  Thu Oct  4 18:30:27 2007
From: uwe at hermann-uwe.de (Uwe Hermann)
Date: Thu, 4 Oct 2007 18:30:27 +0200
Subject: [LinuxBIOS] Call for help: superiotool
In-Reply-To: <20071004161956.5da07672.rasmus@wiman.org>
References: <20070923111315.GC12926@greenwood>
	<20071002152938.084fdaef.rasmus@wiman.org>
	<20071004022202.GA30344@greenwood>
	<20071004161956.5da07672.rasmus@wiman.org>
Message-ID: <20071004163027.GE32267@greenwood>

On Thu, Oct 04, 2007 at 04:19:56PM +0200, Rasmus Wiman wrote:
> > Interesting. I can't find a datasheet for the LPC47B387, so dump
> > support won't happen anytime soon. But it would be nice if you could
> > re-run 'superiotool -V' on that box with my latest patch applied
> > ([PATCH] superiotool: Various improvements). That should tell us the
> > Super I/O ID, I hope, so we can at least detect the chip.
> 
> Ok, here is the result:


> Probing for SMSC Super I/O (idregs=0x20/0x21) at 0x2e...
>   Failed. Returned data: id=0x6e, rev=0x00

OK, good. Looks like 0x6e is the ID for the LPC47B387.

Please retry with r2823, just to make sure detection really works
(just run 'superiotool').


> By the way, svn said I checked out r2820, but superiotool says r2815. 

Yes, unfortunately. I think I was wrong, the version-from-svn thing
won't work for us. More on that in another mail.


Uwe.
-- 
http://www.hermann-uwe.de  | http://www.holsham-traders.de
http://www.crazy-hacks.org | http://www.unmaintained-free-software.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20071004/f1c8e8dd/attachment.sig>

From uwe at hermann-uwe.de  Thu Oct  4 18:32:15 2007
From: uwe at hermann-uwe.de (Uwe Hermann)
Date: Thu, 4 Oct 2007 18:32:15 +0200
Subject: [LinuxBIOS] Call for help: superiotool
In-Reply-To: <20071004022202.GA30344@greenwood>
References: <20070923111315.GC12926@greenwood>
	<20071002152938.084fdaef.rasmus@wiman.org>
	<20071004022202.GA30344@greenwood>
Message-ID: <20071004163215.GF32267@greenwood>

On Thu, Oct 04, 2007 at 04:22:02AM +0200, Uwe Hermann wrote:
> > I also ran superiotool on an Asus L8400 laptop and a HP compaq d530 sff
> > desktop, but it did not detect any super I/O. Opening up the HP

Oh, I almost forgot: what does the latest version say on the laptop
when run with --verbose?


Uwe.
-- 
http://www.hermann-uwe.de  | http://www.holsham-traders.de
http://www.crazy-hacks.org | http://www.unmaintained-free-software.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20071004/1d2ef3d2/attachment.sig>

From c-d.hailfinger.devel.2006 at gmx.net  Thu Oct  4 18:37:39 2007
From: c-d.hailfinger.devel.2006 at gmx.net (Carl-Daniel Hailfinger)
Date: Thu, 04 Oct 2007 18:37:39 +0200
Subject: [LinuxBIOS] [IMPORT] GIGABYTE GA-2761GXDK
In-Reply-To: <006b01c8058d$38dc52f0$0200a8c0@sis.com.tw>
References: <006b01c8058d$38dc52f0$0200a8c0@sis.com.tw>
Message-ID: <470516D3.1020305@gmx.net>

Dear Morgan,

This is great!

On 03.10.2007 09:15, Morgan Tsai wrote:
> Copyright (C) 2007 Morgan Tsai <my_tsai at sis.com>
> Copyright (C) 2007 Silicon Integrated Systems Corp. (SiS)
> 
> Change Log:
> 
> Newly support GIGABYTE GA-2761GXDK

This is a DTX board, right? I found an image of it at
http://www.pcgameshardware.de/?menu=browser&article_id=601554&image_id=655235&show=original

> CPU type: AMD AM2 socket
> Northbridge: SiS 761GX
> Southbridge: SiS 966
> SuperIO: ITE8716F

1 PCIe x1 slot
1 PCI slot
6 SATA connectors (1 external)

> The board is still under testing sample. When we finish test without
> major problems, this sample will soon become marketing board.
> 
> 
> Signed-off-by: Morgan Tsai <my_tsai at sis.com>

Thank you very much for this contribution. We will work with you to get
it included in main LinuxBIOS.

Regards,
Carl-Daniel



From c-d.hailfinger.devel.2006 at gmx.net  Thu Oct  4 18:43:40 2007
From: c-d.hailfinger.devel.2006 at gmx.net (Carl-Daniel Hailfinger)
Date: Thu, 04 Oct 2007 18:43:40 +0200
Subject: [LinuxBIOS] Call for help: superiotool
In-Reply-To: <20071003024216.GD6851@greenwood>
References: <20070923111315.GC12926@greenwood>	<a698c16a0709270921l860615dv3ebe8d49e2f4c791@mail.gmail.com>	<46FBDB3E.4000009@gmx.net>	<a698c16a0710012037l37bc9d07i6628563002d7e47a@mail.gmail.com>	<470256CB.9060008@gmx.net>	<a698c16a0710020844ud12485dhb063f76800170b63@mail.gmail.com>	<470268D0.9050107@gmx.net>
	<20071003024216.GD6851@greenwood>
Message-ID: <4705183C.6020804@gmx.net>

On 03.10.2007 04:42, Uwe Hermann wrote:
> On Tue, Oct 02, 2007 at 05:50:40PM +0200, Carl-Daniel Hailfinger wrote:
>>>>> System Information
>>>>>         Manufacturer: TOSHIBA
>>>>>         Product Name: Satellite 1415
>>>>>         Version: PS141U-1ZCF4V
>>>>>
>>>>> $ sudo ./superiotool -v
>>>>> superiotool r2815
>>>>> $ sudo ./superiotool -V
>>>>> Probing for ALi Super I/O at 0x3f0... failed
>>>>> Probing for ALi Super I/O at 0x370... failed
>>>>> Probing for NSC Super I/O at 0x2e... failed
>>>>> Probing for NSC Super I/O at 0x4e... failed
>>>>> Probing for Fintek Super I/O at 0x2e... failed
>>>>> Probing for Fintek Super I/O at 0x4e... failed
>>>>> Probing 0x2e, failed (0x22), data returns 0x04
>>>>> Probing 0x2e, failed (0x22), data returns 0x04
>>>>> Probing for ITE Super I/O (init=0x87,0x01,0x55,0x55/0xaa) at 0x4e... failed
>>>>> Probing for ITE Super I/O (init=0x87,0x87) at 0x4e... failed
>>>>> Probing 0x2e, failed (0x21), data returns 0x00
>>>>> Probing 0x2e, failed (0x0e), data returns 0x00
>>>>> Probing for SMSC Super I/O at 0x4e... failed
>>>>> Probing for SMSC Super I/O at 0x4e... failed
>>>>> Probing for SMSC Super I/O at 0x3f0... failed
>>>>> Probing for SMSC Super I/O at 0x3f0... failed
>>>>> Probing for SMSC Super I/O at 0x370... failed
>>>>> Probing for SMSC Super I/O at 0x370... failed
>>>>> Probing for Winbond Super I/O (init=0x88) at 0x2e... failed
>>>>> Probing for Winbond Super I/O (init=0x89) at 0x2e... failed
>>>>> Probing for Winbond Super I/O (init=0x86,0x86) at 0x2e... failed
>>>>> Probing for Winbond Super I/O (init=0x87,0x87) at 0x2e... failed
>>>>> Probing for Winbond Super I/O (init=0x88) at 0x4e... failed
>>>>> Probing for Winbond Super I/O (init=0x89) at 0x4e... failed
>>>>> Probing for Winbond Super I/O (init=0x86,0x86) at 0x4e... failed
>>>>> Probing for Winbond Super I/O (init=0x87,0x87) at 0x4e... failed
>>>>> Probing for Winbond Super I/O (init=0x88) at 0x3f0... failed
>>>>> Probing for Winbond Super I/O (init=0x89) at 0x3f0... failed
>>>>> Probing for Winbond Super I/O (init=0x86,0x86) at 0x3f0... failed
>>>>> Probing for Winbond Super I/O (init=0x87,0x87) at 0x3f0... failed
>>>>> Probing for Winbond Super I/O (init=0x88) at 0x370... failed
>>>>> Probing for Winbond Super I/O (init=0x89) at 0x370... failed
>>>>> Probing for Winbond Super I/O (init=0x86,0x86) at 0x370... failed
>>>>> Probing for Winbond Super I/O (init=0x87,0x87) at 0x370... failed
>>>>> Probing for Winbond Super I/O (init=0x88) at 0x250... failed
>>>>> Probing for Winbond Super I/O (init=0x89) at 0x250... failed
>>>>> Probing for Winbond Super I/O (init=0x86,0x86) at 0x250... failed
>>>>> Probing for Winbond Super I/O (init=0x87,0x87) at 0x250... failed
>>>> Your superiotool version seems broken. Probably one of Uwe's "trivial"
>>>> patches.
>>> Hmm... is it possible that the Satellite 1415 doesn't have a Super I/O ?
>> Probably the Super I/O is inside the embedded controller and responds to
>> a special probe sequence.
>>
>> However, the probing sequence is incomplete (at least when judging it by
>> its output) and Uwe rewrote the probing sequence, so he can take a look
>> at it.
> 
> Will do. What do you mean with incomplete?
> The --verbose output needs some more fixing to make it more informative, IMO. 

ITE superio probing at 0x2e does not appear in the log above.

Carl-Daniel



From rasmus at wiman.org  Thu Oct  4 18:44:10 2007
From: rasmus at wiman.org (Rasmus Wiman)
Date: Thu, 4 Oct 2007 18:44:10 +0200
Subject: [LinuxBIOS] Call for help: superiotool
In-Reply-To: <20071004163215.GF32267@greenwood>
References: <20070923111315.GC12926@greenwood>
	<20071002152938.084fdaef.rasmus@wiman.org>
	<20071004022202.GA30344@greenwood>
	<20071004163215.GF32267@greenwood>
Message-ID: <20071004184410.8ec008fe.rasmus@wiman.org>

Uwe Hermann <uwe at hermann-uwe.de> skrev:

> On Thu, Oct 04, 2007 at 04:22:02AM +0200, Uwe Hermann wrote:
> > > I also ran superiotool on an Asus L8400 laptop and a HP compaq
> > > d530 sff desktop, but it did not detect any super I/O. Opening up
> > > the HP
> 
> Oh, I almost forgot: what does the latest version say on the laptop
> when run with --verbose?

Horribly little, I'm afraid. Seems like every probe attempt returns the
same.

./superiotool -V
superiotool r2815
Probing for ALi Super I/O at 0x3f0...
  Failed. Returned data: id=0xffff, rev=0xff
Probing for ALi Super I/O at 0x370...
  Failed. Returned data: id=0xffff, rev=0xff
Probing for NSC Super I/O at 0x2e...
  Failed. Returned data: port=0xff, port+1=0xff
Probing for NSC Super I/O at 0x4e...
  Failed. Returned data: port=0xff, port+1=0xff
Probing for Fintek Super I/O at 0x2e...
  Failed. Returned data: vid=0xffff, id=0xffff
Probing for Fintek Super I/O at 0x4e...
  Failed. Returned data: vid=0xffff, id=0xffff
Probing for ITE Super I/O (init=0x87,0x01,0x55,0x55/0xaa) at 0x2e...
  Failed. Returned data: id=0xffff, rev=0xf
Probing for ITE Super I/O (init=0x87,0x87) at 0x2e...
  Failed. Returned data: id=0xffff, rev=0xf
Probing for ITE Super I/O (init=0x87,0x01,0x55,0x55/0xaa) at 0x4e...
  Failed. Returned data: id=0xffff, rev=0xf
Probing for ITE Super I/O (init=0x87,0x87) at 0x4e...
  Failed. Returned data: id=0xffff, rev=0xf
Probing for SMSC Super I/O (idregs=0x20/0x21) at 0x2e...
  Failed. Returned data: id=0xff, rev=0xff
Probing for SMSC Super I/O (idregs=0x0d/0x0e) at 0x2e...
  Failed. Returned data: id=0xff, rev=0xff
Probing for SMSC Super I/O (idregs=0x20/0x21) at 0x4e...
  Failed. Returned data: id=0xff, rev=0xff
Probing for SMSC Super I/O (idregs=0x0d/0x0e) at 0x4e...
  Failed. Returned data: id=0xff, rev=0xff
Probing for SMSC Super I/O (idregs=0x20/0x21) at 0x3f0...
  Failed. Returned data: id=0xff, rev=0xff
Probing for SMSC Super I/O (idregs=0x0d/0x0e) at 0x3f0...
  Failed. Returned data: id=0xff, rev=0xff
Probing for SMSC Super I/O (idregs=0x20/0x21) at 0x370...
  Failed. Returned data: id=0xff, rev=0xff
Probing for SMSC Super I/O (idregs=0x0d/0x0e) at 0x370...
  Failed. Returned data: id=0xff, rev=0xff
Probing for Winbond Super I/O (init=0x88) at 0x2e...
  Failed. Returned data: id/oldid=0xff/0x0f, rev=0xff
Probing for Winbond Super I/O (init=0x89) at 0x2e...
  Failed. Returned data: id/oldid=0xff/0x0f, rev=0xff
Probing for Winbond Super I/O (init=0x86,0x86) at 0x2e...
  Failed. Returned data: id/oldid=0xff/0x0f, rev=0xff
Probing for Winbond Super I/O (init=0x87,0x87) at 0x2e...
  Failed. Returned data: id/oldid=0xff/0x0f, rev=0xff
Probing for Winbond Super I/O (init=0x88) at 0x4e...
  Failed. Returned data: id/oldid=0xff/0x0f, rev=0xff
Probing for Winbond Super I/O (init=0x89) at 0x4e...
  Failed. Returned data: id/oldid=0xff/0x0f, rev=0xff
Probing for Winbond Super I/O (init=0x86,0x86) at 0x4e...
  Failed. Returned data: id/oldid=0xff/0x0f, rev=0xff
Probing for Winbond Super I/O (init=0x87,0x87) at 0x4e...
  Failed. Returned data: id/oldid=0xff/0x0f, rev=0xff
Probing for Winbond Super I/O (init=0x88) at 0x3f0...
  Failed. Returned data: id/oldid=0xff/0x0f, rev=0xff
Probing for Winbond Super I/O (init=0x89) at 0x3f0...
  Failed. Returned data: id/oldid=0xff/0x0f, rev=0xff
Probing for Winbond Super I/O (init=0x86,0x86) at 0x3f0...
  Failed. Returned data: id/oldid=0xff/0x0f, rev=0xff
Probing for Winbond Super I/O (init=0x87,0x87) at 0x3f0...
  Failed. Returned data: id/oldid=0xff/0x0f, rev=0xff
Probing for Winbond Super I/O (init=0x88) at 0x370...
  Failed. Returned data: id/oldid=0xff/0x0f, rev=0xff
Probing for Winbond Super I/O (init=0x89) at 0x370...
  Failed. Returned data: id/oldid=0xff/0x0f, rev=0xff
Probing for Winbond Super I/O (init=0x86,0x86) at 0x370...
  Failed. Returned data: id/oldid=0xff/0x0f, rev=0xff
Probing for Winbond Super I/O (init=0x87,0x87) at 0x370...
  Failed. Returned data: id/oldid=0xff/0x0f, rev=0xff
Probing for Winbond Super I/O (init=0x88) at 0x250...
  Failed. Returned data: id/oldid=0xff/0x0f, rev=0xff
Probing for Winbond Super I/O (init=0x89) at 0x250...
  Failed. Returned data: id/oldid=0xff/0x0f, rev=0xff
Probing for Winbond Super I/O (init=0x86,0x86) at 0x250...
  Failed. Returned data: id/oldid=0xff/0x0f, rev=0xff
Probing for Winbond Super I/O (init=0x87,0x87) at 0x250...
  Failed. Returned data: id/oldid=0xff/0x0f, rev=0xff

/Rasmus



From rasmus at wiman.org  Thu Oct  4 18:50:17 2007
From: rasmus at wiman.org (Rasmus Wiman)
Date: Thu, 4 Oct 2007 18:50:17 +0200
Subject: [LinuxBIOS] Call for help: superiotool
In-Reply-To: <20071004163027.GE32267@greenwood>
References: <20070923111315.GC12926@greenwood>
	<20071002152938.084fdaef.rasmus@wiman.org>
	<20071004022202.GA30344@greenwood>
	<20071004161956.5da07672.rasmus@wiman.org>
	<20071004163027.GE32267@greenwood>
Message-ID: <20071004185017.e1709e94.rasmus@wiman.org>

Uwe Hermann <uwe at hermann-uwe.de> wrote:

> > Probing for SMSC Super I/O (idregs=0x20/0x21) at 0x2e...
> >   Failed. Returned data: id=0x6e, rev=0x00
> 
> OK, good. Looks like 0x6e is the ID for the LPC47B387.
> 
> Please retry with r2823, just to make sure detection really works
> (just run 'superiotool').

It worked!

./superiotool   
Found SMSC LPC47B387 (id=0x6e, rev=0x00) at 0x2e

./superiotool --verbose
superiotool r2815
Probing for ALi Super I/O at 0x3f0...
  Failed. Returned data: id=0x0000, rev=0x00
Probing for ALi Super I/O at 0x370...
  Failed. Returned data: id=0xffff, rev=0xff
Probing for NSC Super I/O at 0x2e...
  Failed. Returned data: port=0xff, port+1=0xff
Probing for NSC Super I/O at 0x4e...
  Failed. Returned data: port=0xff, port+1=0xff
Probing for Fintek Super I/O at 0x2e...
  Failed. Returned data: vid=0xffff, id=0xffff
Probing for Fintek Super I/O at 0x4e...
  Failed. Returned data: vid=0xffff, id=0xffff
Probing for ITE Super I/O (init=0x87,0x01,0x55,0x55/0xaa) at 0x2e...
  Failed. Returned data: id=0x6e00, rev=0x9
Probing for ITE Super I/O (init=0x87,0x87) at 0x2e...
  Failed. Returned data: id=0x6e00, rev=0x9
Probing for ITE Super I/O (init=0x87,0x01,0x55,0x55/0xaa) at 0x4e...
  Failed. Returned data: id=0xffff, rev=0xf
Probing for ITE Super I/O (init=0x87,0x87) at 0x4e...
  Failed. Returned data: id=0xffff, rev=0xf
Probing for SMSC Super I/O (idregs=0x20/0x21) at 0x2e...
Found SMSC LPC47B387 (id=0x6e, rev=0x00) at 0x2e
Probing for SMSC Super I/O (idregs=0x0d/0x0e) at 0x2e...
  Failed. Returned data: id=0x00, rev=0x00
Probing for SMSC Super I/O (idregs=0x20/0x21) at 0x4e...
  Failed. Returned data: id=0xff, rev=0xff
Probing for SMSC Super I/O (idregs=0x0d/0x0e) at 0x4e...
  Failed. Returned data: id=0xff, rev=0xff
Probing for SMSC Super I/O (idregs=0x20/0x21) at 0x3f0...
  Failed. Returned data: id=0x00, rev=0x00
Probing for SMSC Super I/O (idregs=0x0d/0x0e) at 0x3f0...
  Failed. Returned data: id=0x00, rev=0x00
Probing for SMSC Super I/O (idregs=0x20/0x21) at 0x370...
  Failed. Returned data: id=0xff, rev=0xff
Probing for SMSC Super I/O (idregs=0x0d/0x0e) at 0x370...
  Failed. Returned data: id=0xff, rev=0xff
Probing for Winbond Super I/O (init=0x88) at 0x2e...
  Failed. Returned data: id/oldid=0xff/0x0f, rev=0xff
Probing for Winbond Super I/O (init=0x89) at 0x2e...
  Failed. Returned data: id/oldid=0xff/0x0f, rev=0xff
Probing for Winbond Super I/O (init=0x86,0x86) at 0x2e...
  Failed. Returned data: id/oldid=0xff/0x0f, rev=0xff
Probing for Winbond Super I/O (init=0x87,0x87) at 0x2e...
  Failed. Returned data: id/oldid=0xff/0x0f, rev=0xff
Probing for Winbond Super I/O (init=0x88) at 0x4e...
  Failed. Returned data: id/oldid=0xff/0x0f, rev=0xff
Probing for Winbond Super I/O (init=0x89) at 0x4e...
  Failed. Returned data: id/oldid=0xff/0x0f, rev=0xff
Probing for Winbond Super I/O (init=0x86,0x86) at 0x4e...
  Failed. Returned data: id/oldid=0xff/0x0f, rev=0xff
Probing for Winbond Super I/O (init=0x87,0x87) at 0x4e...
  Failed. Returned data: id/oldid=0xff/0x0f, rev=0xff
Probing for Winbond Super I/O (init=0x88) at 0x3f0...
  Failed. Returned data: id/oldid=0x00/0x00, rev=0x00
Probing for Winbond Super I/O (init=0x89) at 0x3f0...
  Failed. Returned data: id/oldid=0x00/0x00, rev=0x00
Probing for Winbond Super I/O (init=0x86,0x86) at 0x3f0...
  Failed. Returned data: id/oldid=0x00/0x00, rev=0x00
Probing for Winbond Super I/O (init=0x87,0x87) at 0x3f0...
  Failed. Returned data: id/oldid=0x00/0x00, rev=0x00
Probing for Winbond Super I/O (init=0x88) at 0x370...
  Failed. Returned data: id/oldid=0xff/0x0f, rev=0xff
Probing for Winbond Super I/O (init=0x89) at 0x370...
  Failed. Returned data: id/oldid=0xff/0x0f, rev=0xff
Probing for Winbond Super I/O (init=0x86,0x86) at 0x370...
  Failed. Returned data: id/oldid=0xff/0x0f, rev=0xff
Probing for Winbond Super I/O (init=0x87,0x87) at 0x370...
  Failed. Returned data: id/oldid=0xff/0x0f, rev=0xff
Probing for Winbond Super I/O (init=0x88) at 0x250...
  Failed. Returned data: id/oldid=0xff/0x0f, rev=0xff
Probing for Winbond Super I/O (init=0x89) at 0x250...
  Failed. Returned data: id/oldid=0xff/0x0f, rev=0xff
Probing for Winbond Super I/O (init=0x86,0x86) at 0x250...
  Failed. Returned data: id/oldid=0xff/0x0f, rev=0xff
Probing for Winbond Super I/O (init=0x87,0x87) at 0x250...
  Failed. Returned data: id/oldid=0xff/0x0f, rev=0xff

/Rasmus



From joe at smittys.pointclark.net  Thu Oct  4 18:59:49 2007
From: joe at smittys.pointclark.net (joe at smittys.pointclark.net)
Date: Thu, 04 Oct 2007 12:59:49 -0400
Subject: [LinuxBIOS] Problems with Filo booting - HELP
In-Reply-To: <47048488.5060508@gmail.com>
References: <20070929165103.pcm220bn4s48sow8@smittys.pointclark.net>
	<20070929205527.GA16584@coresystems.de>
	<20070929170245.ata0hgegqowgcwgs@www.smittys.pointclark.net>
	<20070929201342.mifqbujb44ocwks8@smittys.pointclark.net>
	<46FF1CB2.60901@gmail.com>
	<20070930115720.mwni4u7go4wkk8wg@www.smittys.pointclark.net>
	<47000290.6020000@gmail.com>
	<20071001094827.loois4qr0g4ckw8o@www.smittys.pointclark.net>
	<13426df10710010950s379f8230y5b4ffec4da605f06@mail.gmail.com>
	<20071001165858.vlz66uxpusgk0gww@www.smittys.pointclark.net>
	<47017223.6010504@gmail.com>
	<20071003190457.a6hta1e4kk8w0wwc@www.smittys.pointclark.net>
	<4704630C.8060803@gmail.com>
	<20071004002639.o29oeiku4g84w4g8@www.smittys.pointclark.net>
	<47048488.5060508@gmail.com>
Message-ID: <20071004125949.u3xlwo9bjwgocc48@www.smittys.pointclark.net>

Quoting Corey Osgood <corey.osgood at gmail.com>:

> joe at smittys.pointclark.net wrote:
>> Here is my ram_check from 1-128MB. It appears to fill the ram ok. But
>> only returns a value of 0xffffffff. Does this mean the ram is WO
>> (write only) for some reason? Thanks again for your help.
>
> Okay, this is mostly a shot in the dark, but it's the only thing I can
> find that might cause something like this. I'm looking at the AGP size
> register (APSIZE, 0xb4) in the datasheet, and the default value is 0x00,
> which is 256MB (!!). I also don't see anywhere that AGP has to be
> explicitly enabled, it looks like it's enabled by default (yes, I see
> AGPCMD, but it says cycles will be ignored, not that the device is
> actually disabled and freeing the aperture memory).
>
> Long story short, try setting the AGP aperture to 32MB and moving the
> aperture base (APBASE, 0x10-13) to somewhere else, preferably wherever
> the stock bios moves it to. Even if it's not the root cause, it'll get
> it out of the way for later.
>
> -Corey
>
Those registers also say: "This register is Read Only when either the  
Intel 830M or Intel 830MG internal graphics device is used."

Does that matter? In the original bios these are set to zero.

For IGD the Graphics Memory Aperture Size is set wih bit 0 in GCC1.


Thanks - Joe


Thanks - Joe



From info at coresystems.de  Thu Oct  4 19:01:52 2007
From: info at coresystems.de (LinuxBIOS information)
Date: Thu, 04 Oct 2007 19:01:52 +0200
Subject: [LinuxBIOS] r2822 build service
Message-ID: <E1IdU5A-0003QF-PJ@khepri.openbios.org>

Dear LinuxBIOS readers!

This is the automated build check service of LinuxBIOS.

The developer "uwe" checked in revision 2822 to
the LinuxBIOS source repository and caused the following 
changes:

Change Log:
Add dump support for the ITE IT8705F/AF.

Signed-off-by: Robinson P. Tryon <bishop.robinson at gmail.com>
Acked-by: Uwe Hermann <uwe at hermann-uwe.de>



Build Log:
Compilation of arima:hdama is still broken
See the error log at http://qa.linuxbios.org/log_buildbrd.php?revision=2822&device=hdama&vendor=arima
Compilation of ibm:e325 is still broken
See the error log at http://qa.linuxbios.org/log_buildbrd.php?revision=2822&device=e325&vendor=ibm
Compilation of ibm:e326 is still broken
See the error log at http://qa.linuxbios.org/log_buildbrd.php?revision=2822&device=e326&vendor=ibm
Compilation of iei:juki-511p is still broken
See the error log at http://qa.linuxbios.org/log_buildbrd.php?revision=2822&device=juki-511p&vendor=iei
Compilation of iwill:dk8s2 is still broken
See the error log at http://qa.linuxbios.org/log_buildbrd.php?revision=2822&device=dk8s2&vendor=iwill
Compilation of iwill:dk8x is still broken
See the error log at http://qa.linuxbios.org/log_buildbrd.php?revision=2822&device=dk8x&vendor=iwill
Compilation of newisys:khepri is still broken
See the error log at http://qa.linuxbios.org/log_buildbrd.php?revision=2822&device=khepri&vendor=newisys


If something broke during this checkin please be a pain 
in uwe's neck until the issue is fixed.

If this issue is not fixed within 24h the revision should 
be backed out.

   Best regards,
     LinuxBIOS automatic build system





From joe at smittys.pointclark.net  Thu Oct  4 19:06:27 2007
From: joe at smittys.pointclark.net (joe at smittys.pointclark.net)
Date: Thu, 04 Oct 2007 13:06:27 -0400
Subject: [LinuxBIOS] Problems with Filo booting - HELP
In-Reply-To: <20071004044448.GA27127@coresystems.de>
References: <46FF1CB2.60901@gmail.com>
	<20070930115720.mwni4u7go4wkk8wg@www.smittys.pointclark.net>
	<47000290.6020000@gmail.com>
	<20071001094827.loois4qr0g4ckw8o@www.smittys.pointclark.net>
	<13426df10710010950s379f8230y5b4ffec4da605f06@mail.gmail.com>
	<20071001165858.vlz66uxpusgk0gww@www.smittys.pointclark.net>
	<47017223.6010504@gmail.com>
	<20071003190457.a6hta1e4kk8w0wwc@www.smittys.pointclark.net>
	<4704630C.8060803@gmail.com>
	<20071004002639.o29oeiku4g84w4g8@www.smittys.pointclark.net>
	<20071004044448.GA27127@coresystems.de>
Message-ID: <20071004130627.izaryawis080sckk@www.smittys.pointclark.net>

Quoting Stefan Reinauer <stepan at coresystems.de>:

> * joe at smittys.pointclark.net <joe at smittys.pointclark.net> [071004 06:26]:
>
>> Here is my ram_check from 1-128MB. It appears to fill the ram ok. But
>> only returns a value of 0xffffffff. Does this mean the ram is WO
>> (write only) for some reason? Thanks again for your help.
>
> Do you have several banks? Do you send your ram init commands to all
> these banks, or just the first?
>
>
There is only one bank of onboard memory. I am starting to wonder if  
the memory isn't initializing correctly. But why would only part  
(0-640KB) of the memory initialize and not the rest??


Thanks - Joe



From jtmettala at gmail.com  Thu Oct  4 19:07:09 2007
From: jtmettala at gmail.com (=?UTF-8?Q?Jouni_Mett=C3=A4l=C3=A4?=)
Date: Thu, 4 Oct 2007 20:07:09 +0300
Subject: [LinuxBIOS] MSI MS-6337 (i815 based)
In-Reply-To: <63e824e50710031149m169e5543t17f2d58695dc3f99@mail.gmail.com>
References: <63e824e50710031149m169e5543t17f2d58695dc3f99@mail.gmail.com>
Message-ID: <63e824e50710041007q67558f4jf949e5fe7da13461@mail.gmail.com>

Here is minimal kernel config. I  hope it is right version.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20071004/d93fe2f6/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: config_mini
Type: application/octet-stream
Size: 11637 bytes
Desc: not available
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20071004/d93fe2f6/attachment.obj>

From info at coresystems.de  Thu Oct  4 19:55:23 2007
From: info at coresystems.de (LinuxBIOS information)
Date: Thu, 04 Oct 2007 19:55:23 +0200
Subject: [LinuxBIOS] r2823 build service
Message-ID: <E1IdUux-0008JI-Mr@khepri.openbios.org>

Dear LinuxBIOS readers!

This is the automated build check service of LinuxBIOS.

The developer "uwe" checked in revision 2823 to
the LinuxBIOS source repository and caused the following 
changes:

Change Log:
Add detection support for the LPC47B387 (trivial).

Signed-off-by: Uwe Hermann <uwe at hermann-uwe.de>
Acked-by: Uwe Hermann <uwe at hermann-uwe.de>



Build Log:
Compilation of arima:hdama is still broken
See the error log at http://qa.linuxbios.org/log_buildbrd.php?revision=2823&device=hdama&vendor=arima
Compilation of ibm:e325 is still broken
See the error log at http://qa.linuxbios.org/log_buildbrd.php?revision=2823&device=e325&vendor=ibm
Compilation of ibm:e326 is still broken
See the error log at http://qa.linuxbios.org/log_buildbrd.php?revision=2823&device=e326&vendor=ibm
Compilation of iei:juki-511p is still broken
See the error log at http://qa.linuxbios.org/log_buildbrd.php?revision=2823&device=juki-511p&vendor=iei
Compilation of iwill:dk8s2 is still broken
See the error log at http://qa.linuxbios.org/log_buildbrd.php?revision=2823&device=dk8s2&vendor=iwill
Compilation of iwill:dk8x is still broken
See the error log at http://qa.linuxbios.org/log_buildbrd.php?revision=2823&device=dk8x&vendor=iwill
Compilation of newisys:khepri is still broken
See the error log at http://qa.linuxbios.org/log_buildbrd.php?revision=2823&device=khepri&vendor=newisys


If something broke during this checkin please be a pain 
in uwe's neck until the issue is fixed.

If this issue is not fixed within 24h the revision should 
be backed out.

   Best regards,
     LinuxBIOS automatic build system





From svn at openbios.org  Thu Oct  4 20:34:36 2007
From: svn at openbios.org (svn at openbios.org)
Date: Thu,  4 Oct 2007 20:34:36 +0200
Subject: [LinuxBIOS] r2824 - trunk/util/superiotool
Message-ID: <mailman.699.1355071172.16123.coreboot@coreboot.org>

Author: uwe
Date: 2007-10-04 20:34:36 +0200 (Thu, 04 Oct 2007)
New Revision: 2824

Modified:
   trunk/util/superiotool/winbond.c
Log:
Add some more Winbond chips (trivial).

Add notes which IDs were taken from sensors-detect (as where we lack
datasheets, thus cannot verify them) and which we support but sensors-detect
does not (yet). I'll post patches on the lm-sensors list to sync up
the detected chips between superiotool and sensors-detect.

Signed-off-by: Uwe Hermann <uwe at hermann-uwe.de>
Acked-by: Uwe Hermann <uwe at hermann-uwe.de>



Modified: trunk/util/superiotool/winbond.c
===================================================================
--- trunk/util/superiotool/winbond.c	2007-10-04 16:28:56 UTC (rev 2823)
+++ trunk/util/superiotool/winbond.c	2007-10-04 18:34:36 UTC (rev 2824)
@@ -36,11 +36,12 @@
  * Some other Super I/Os only use bits 3..0 of 0x09 as ID.
  */
 const static struct superio_registers reg_table[] = {
-	{0x527, "W83977CTF", {
+	/* ID and rev[3..0] */
+	{0x527, "W83977CTF", {	/* TODO: Not yet in sensors-detect */
 		{EOT}}},
-	{0x52f, "W83977EF/EG", {
+	{0x52f, "W83977EF/EG", {/* TODO: Not yet in sensors-detect */
 		{EOT}}},
-	{0x595, "W83627SF", {
+	{0x595, "W83627SF", {	/* TODO: Not yet in sensors-detect */
 		{EOT}}},
 	{0x601, "W83697HF/F/HG", { /* No G version? */
 		{NOLDN, NULL,
@@ -90,13 +91,19 @@
 		{EOT}}},
 	{0x610, "W83L517D/D-F", {
 		{EOT}}},
-	{0x681, "W83697UF/UG", {
+	{0x681, "W83697SF/UF/UG", {
 		{EOT}}},
-	{0x708, "W83637HF", {
+	{0x708, "W83637HF/HG", {
 		{EOT}}},
 	{0x828, "W83627THF/THG", { /* We assume rev is bits 3..0 of 0x21. */
 		{EOT}}},
-	{0x886, "W83627EHF/EF/EHG/EG", {
+#if 0
+	{0x85x, "W83687THF", {	/* TODO: sensors-detect: 0x85 */
+		{EOT}}},
+#endif
+	{0xa02, "W83627DHG", {
+		{EOT}}},
+	{0x886, "W83627EHF/EF/EHG/EG", { /* sensors-detect: 0x8853 possible */
 		{NOLDN, NULL,
 			{0x20,0x21,0x22,0x23,0x24,0x25,0x26,0x27,0x28,
 			 0x29,0x2a,0x2b,0x2c,0x2d,0x2e,0x2f,EOT},
@@ -144,16 +151,22 @@
 			{0x30,0x60,0x61,0x70,0xf0,0xf1,EOT},
 			{0x00,0x00,0x00,0x00,0xc1,0x00,EOT}},
 		{EOT}}},
-	{0xa23, "W83627UHG", {
+	{0xa23, "W83627UHG", {/* TODO: Not yet in sensors-detect */
 		{EOT}}},
+
+	/* ID and rev */
 	{0x9771, "W83977F-A/G-A/AF-A/AG-A", {
 		{EOT}}},
 	{0x9773, "W83977TF", {
 		{EOT}}},
 	{0x9774, "W83977ATF", {
 		{EOT}}},
+
+	/* ID only */
 	{0x52, "W83627HF/F/HG/G", {
 		{EOT}}},
+
+	/* ID[3..0] */
 	{0xa, "W83877F", {
 		{EOT}}},
 	{0xc, "W83877TF", {




From bishop.robinson at gmail.com  Thu Oct  4 20:54:04 2007
From: bishop.robinson at gmail.com (Robinson Tryon)
Date: Thu, 4 Oct 2007 14:54:04 -0400
Subject: [LinuxBIOS] superiotool - dump support for IT8661F
Message-ID: <a698c16a0710041154y24ca80acn62ae2e390b55e077@mail.gmail.com>

Signed-off-by: Robinson P. Tryon <bishop.robinson at gmail.com>

Notes:
- Added in the missing tab chars manually (I'm still trying to get
emacs to follow the correct indenting rules).
- Managed to finish up before 1AM, so my proofing should be better
this time... :-)
- What should I do with registers 0x25, 0x26 in the 'Global
Configuration Registers' table?  They both have an LDN of "All-05h",
so should they go with the 0x5 GPIO table or in the GCR table?  (I
took a guess and put them in the former).
-------------- next part --------------
A non-text attachment was scrubbed...
Name: it8661f.patch
Type: text/x-patch
Size: 1555 bytes
Desc: not available
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20071004/44f930cd/attachment.patch>

From info at coresystems.de  Thu Oct  4 21:21:17 2007
From: info at coresystems.de (LinuxBIOS information)
Date: Thu, 04 Oct 2007 21:21:17 +0200
Subject: [LinuxBIOS] r2824 build service
Message-ID: <E1IdWG5-0006FY-51@khepri.openbios.org>

Dear LinuxBIOS readers!

This is the automated build check service of LinuxBIOS.

The developer "uwe" checked in revision 2824 to
the LinuxBIOS source repository and caused the following 
changes:

Change Log:
Add some more Winbond chips (trivial).

Add notes which IDs were taken from sensors-detect (as where we lack
datasheets, thus cannot verify them) and which we support but sensors-detect
does not (yet). I'll post patches on the lm-sensors list to sync up
the detected chips between superiotool and sensors-detect.

Signed-off-by: Uwe Hermann <uwe at hermann-uwe.de>
Acked-by: Uwe Hermann <uwe at hermann-uwe.de>



Build Log:
Compilation of arima:hdama is still broken
See the error log at http://qa.linuxbios.org/log_buildbrd.php?revision=2824&device=hdama&vendor=arima
Compilation of ibm:e325 is still broken
See the error log at http://qa.linuxbios.org/log_buildbrd.php?revision=2824&device=e325&vendor=ibm
Compilation of ibm:e326 is still broken
See the error log at http://qa.linuxbios.org/log_buildbrd.php?revision=2824&device=e326&vendor=ibm
Compilation of iei:juki-511p is still broken
See the error log at http://qa.linuxbios.org/log_buildbrd.php?revision=2824&device=juki-511p&vendor=iei
Compilation of iwill:dk8s2 is still broken
See the error log at http://qa.linuxbios.org/log_buildbrd.php?revision=2824&device=dk8s2&vendor=iwill
Compilation of iwill:dk8x is still broken
See the error log at http://qa.linuxbios.org/log_buildbrd.php?revision=2824&device=dk8x&vendor=iwill
Compilation of newisys:khepri is still broken
See the error log at http://qa.linuxbios.org/log_buildbrd.php?revision=2824&device=khepri&vendor=newisys


If something broke during this checkin please be a pain 
in uwe's neck until the issue is fixed.

If this issue is not fixed within 24h the revision should 
be backed out.

   Best regards,
     LinuxBIOS automatic build system





From ward at gnu.org  Thu Oct  4 22:06:02 2007
From: ward at gnu.org (Ward Vandewege)
Date: Thu, 4 Oct 2007 16:06:02 -0400
Subject: [LinuxBIOS] badly initialized (?) pci bridge on the M57SLI
	(with irq table and mptable)
In-Reply-To: <1191468741.47045ec51281d@imp.free.fr>
References: <20070919212952.GA16399@localdomain>
	<2ea3fae10709191629w17affbaeh4daf8a0715737ad2@mail.gmail.com>
	<1190278384.46f234f055fc2@imp.free.fr>
	<2ea3fae10709200944o6ebbc89p74ddd188db4826e1@mail.gmail.com>
	<20070924213615.GB26022@greenwood>
	<2ea3fae10709241623l1b579378td2605ddad12be414@mail.gmail.com>
	<1190713007.46f8d6af1483e@imp.free.fr>
	<2ea3fae10709251226x4098fce2o56d61dbec6af9447@mail.gmail.com>
	<1190858035.46fb0d33df9c7@imp.free.fr>
	<1191468741.47045ec51281d@imp.free.fr>
Message-ID: <20071004200602.GA12146@localdomain>

Hi Florentin,

On Thu, Oct 04, 2007 at 05:32:21AM +0200, echelon at free.fr wrote:
> I propose:
> 
> $(LB)/src/mainboard/gigabyte/m57sli/cache_as_ram_auto.c
> 138c138
> <  RES_PORT_IO_8, SYSCTRL_IO_BASE + 0xc0+38, 0x00, 0x44,/* GPIO39 PCI_GNT3 */ \
> ---
> >  RES_PORT_IO_8, SYSCTRL_IO_BASE + 0xc0+38, 0x00, 0x68,/* GPIO39 PCI_GNT3 */ \
> 
> My vga pci card and a pci network card are recognised with this under LinuxBIOS!
> I don't understand why this works, but it works..
> (I will explain tomorrow how I found this value)
> 
> Please can someone validate my change?a

I've tried it on a v1.1 m57sli (the plcc version).

Great work! This fixes one of the PCI slots (01:07.0), but not the second
slot (01:08.0, closest to the edge of the board). Can you explain how you got
to this value, so that we can activate the second PCI slot as well?

Thanks!
Ward.

-- 
Ward Vandewege <ward at fsf.org>
Free Software Foundation - Senior System Administrator



From joe at smittys.pointclark.net  Fri Oct  5 04:45:57 2007
From: joe at smittys.pointclark.net (joe at smittys.pointclark.net)
Date: Thu, 04 Oct 2007 22:45:57 -0400
Subject: [LinuxBIOS] Problems with Filo booting - HELP
In-Reply-To: <20071004130627.izaryawis080sckk@www.smittys.pointclark.net>
References: <46FF1CB2.60901@gmail.com>
	<20070930115720.mwni4u7go4wkk8wg@www.smittys.pointclark.net>
	<47000290.6020000@gmail.com>
	<20071001094827.loois4qr0g4ckw8o@www.smittys.pointclark.net>
	<13426df10710010950s379f8230y5b4ffec4da605f06@mail.gmail.com>
	<20071001165858.vlz66uxpusgk0gww@www.smittys.pointclark.net>
	<47017223.6010504@gmail.com>
	<20071003190457.a6hta1e4kk8w0wwc@www.smittys.pointclark.net>
	<4704630C.8060803@gmail.com>
	<20071004002639.o29oeiku4g84w4g8@www.smittys.pointclark.net>
	<20071004044448.GA27127@coresystems.de>
	<20071004130627.izaryawis080sckk@www.smittys.pointclark.net>
Message-ID: <20071004224557.vs2bwhv0g4c4cc0w@www.smittys.pointclark.net>

Quoting joe at smittys.pointclark.net:

> Quoting Stefan Reinauer <stepan at coresystems.de>:
>
>> * joe at smittys.pointclark.net <joe at smittys.pointclark.net> [071004 06:26]:
>>
>>> Here is my ram_check from 1-128MB. It appears to fill the ram ok. But
>>> only returns a value of 0xffffffff. Does this mean the ram is WO
>>> (write only) for some reason? Thanks again for your help.
>>
>> Do you have several banks? Do you send your ram init commands to all
>> these banks, or just the first?
>>
>>
> There is only one bank of onboard memory. I am starting to wonder if
> the memory isn't initializing correctly. But why would only part
> (0-640KB) of the memory initialize and not the rest??
>
>
So I changed around my do_ram_command() in raminit.c a bit and set it  
up so it will send the ram commands to any/all dimms found. I think  
this will work alot better. I will report back after I test it. I have  
attached it if you would like to check it out.


Thanks - Joe
-------------- next part --------------
/*
 * This file is part of the LinuxBIOS project.
 *
 * Copyright (C) 2007 Joseph Smith <joe at smittys.pointclark.net>
 *
 * This program is free software; you can redistribute it and/or modify
 * it under the terms of the GNU General Public License as published by
 * the Free Software Foundation; either version 2 of the License, or
 * (at your option) any later version.
 *
 * This program is distributed in the hope that it will be useful,
 * but WITHOUT ANY WARRANTY; without even the implied warranty of
 * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
 * GNU General Public License for more details.
 *
 * You should have received a copy of the GNU General Public License
 * along with this program; if not, write to the Free Software
 * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA  02110-1301 USA
 *
 */

#include <spd.h>
#include <sdram_mode.h>
#include <delay.h>
#include "i82830.h"

/*-----------------------------------------------------------------------------
Macros and definitions.
-----------------------------------------------------------------------------*/

/* Uncomment this to enable debugging output. */
#define DEBUG_RAM_SETUP 1

/* Debugging macros. */
#if defined(DEBUG_RAM_SETUP)
#define PRINT_DEBUG(x)		print_debug(x)
#define PRINT_DEBUG_HEX8(x)	print_debug_hex8(x)
#define PRINT_DEBUG_HEX16(x)	print_debug_hex16(x)
#define PRINT_DEBUG_HEX32(x)	print_debug_hex32(x)
#define DUMPNORTH()		dump_pci_device(PCI_DEV(0, 0, 0))
#else
#define PRINT_DEBUG(x)
#define PRINT_DEBUG_HEX8(x)
#define PRINT_DEBUG_HEX16(x)
#define PRINT_DEBUG_HEX32(x)
#define DUMPNORTH()
#endif

/* DRC[10:8] - Refresh Mode Select (RMS).
 * 0x0 for Refresh Disabled (Self Refresh)
 * 0x1 for Refresh interval 15.6 us for 133MHz
 * 0x2 for Refresh interval 7.8 us for 133MHz
 * 0x7 /* Refresh interval 128 Clocks. (Fast Refresh Mode)
 */
#define RAM_COMMAND_REFRESH      0x2

/* DRC[6:4] - SDRAM Mode Select (SMS). */
#define RAM_COMMAND_SELF_REFRESH 0x0
#define RAM_COMMAND_NOP		   0x1
#define RAM_COMMAND_PRECHARGE	   0x2
#define RAM_COMMAND_MRS		   0x3
#define RAM_COMMAND_CBR		   0x6
#define RAM_COMMAND_NORMAL	   0x7

/* DRC[29] - Initialization Complete (IC). */
#define RAM_COMMAND_IC           0x1

/*-----------------------------------------------------------------------------
SDRAM configuration functions.
-----------------------------------------------------------------------------*/

/* Send the specified RAM command to all DIMMs. */

static void do_ram_command(const struct mem_controller *ctrl, uint32_t command, uint32_t addr_offset)
{
	uint32_t reg;
	uint32_t dimm_start;
	uint32_t dimm_end;

	/* Configure the RAM command. */
	reg = pci_read_config32(ctrl->d0, DRC);
	/* Clear bits 6-4. */
	reg &= 0xffffff8f;
	reg |= command << 4;
	pci_write_config32(ctrl->d0, DRC, reg);

      /* If RAM_COMMAND_NORMAL set the refresh mode and IC bit. */
	if (command == RAM_COMMAND_NORMAL) {
		reg |= (RAM_COMMAND_REFRESH << 8);
		pci_write_config32(ctrl->d0, DRC, reg);
		udelay(1);
		reg |= (RAM_COMMAND_IC << 29);
		pci_write_config32(ctrl->d0, DRC, reg);
		PRINT_DEBUG("    Sending RAM command 0x");
		PRINT_DEBUG_HEX32(reg);
		PRINT_DEBUG(" to Memory Controller");
		PRINT_DEBUG("\r\n");
      } else {
	/* RAM_COMMAND_NORMAL affects only the memory controller 
	 * and doesn't need to be "sent" to the DIMMs.
	 */
		dimm_start = 0;

		for (i = 0; i < DIMM_SOCKETS; i++) {

			/* DRB is in Ticks of 32MB so we need to get total Bytes
			 * of each DIMM. NOTE: 2^25 == 32MB
			 */
			if (i == 0) {
				dim_end = (pci_read_config8(ctrl->d0, DRB + 1)) << 25;
			} else if (i == 1) {
				dim_end = (pci_read_config8(ctrl->d0, DRB + 3)) << 25;
			}

			if (dimm_end > dimm_start) {
				PRINT_DEBUG("    Sending RAM command 0x");
				PRINT_DEBUG_HEX32(reg);
				PRINT_DEBUG(" to 0x");
				PRINT_DEBUG_HEX32(dimm_start + addr_offset);
				PRINT_DEBUG("\r\n");
				read32(dimm_start + addr_offset);

				/* Set the start of the next DIMM. */
				dimm_start = dimm_end;
			}
		}
	}
}

/*-----------------------------------------------------------------------------
DIMM-independant configuration functions.
-----------------------------------------------------------------------------*/

struct dimm_size {
	unsigned long side1;
	unsigned long side2;
};

static struct dimm_size spd_get_dimm_size(unsigned device)
{
	struct dimm_size sz;
	int i, module_density, dimm_banks;
	sz.side1 = 0;
	module_density = spd_read_byte(device, 31);
	dimm_banks = spd_read_byte(device, 5);

	/* Find the size of side1 */
	/* Find the larger value. The larger value is always side1 */	
	for (i = 512; i >= 0; i >>= 1) {
		if ((module_density & i) == i) {
			sz.side1 = i;
			break;
		}
	}

	/* Set to 0 in case it's single sided */
	sz.side2 = 0;

	/* Test if it's a dual-sided dimm */
	if (dimm_banks > 1) {

		/* Test to see if there's a second value, if so it's asymmetrical */
		if (module_density != i) {

		/* Find the second value, picking up where we left off */
		/* i >>= 1 done initially to make sure we don't get the same value again */
			for (i >>= 1; i >= 0; i >>= 1) {
				if (module_density == (sz.side1 | i)) {
					sz.side2 = i;
					break;
				}
			}

		/* If not, it's symmetrical */
		} else {
		sz.side2 = sz.side1;
		}
	}
	/* SPD byte 31 is the memory size divided by 4 so we
	 * need to muliply by 4 to get the total size.
	 */
	sz.side1 <<= 2;
	sz.side2 <<= 2;
	return sz;
}

static void spd_set_dram_size(const struct mem_controller *ctrl)
{
	int i, value, drb1, drb2;

	for (i = 0; i < DIMM_SOCKETS; i++) {
		struct dimm_size sz;
		unsigned device;
		device = ctrl->channel0[i];
		drb1 = 0;
		drb2 = 0;

		/* First check if a DIMM is actually present. */
		if (spd_read_byte(device, 2) == 0x4) {
			print_debug("Found DIMM in slot ");
			print_debug_hex8(i);
			print_debug("\r\n");

			sz = spd_get_dimm_size(device);

			/* WISHLIST: would be nice to display it as decimal? */
			print_debug("DIMM is 0x");
			print_debug_hex16(sz.side1);
			print_debug(" on side 1\r\n");
			print_debug("DIMM is 0x");
			print_debug_hex16(sz.side2);
			print_debug(" on side 2\r\n");

			/* Test for PC133 (i82830 only supports PC133) */
			/* PC133 SPD9 - cycle time is always 75 */
			if (spd_read_byte(device, 9) != 0x75) {
				print_err("SPD9 DIMM Is Not PC133 Compatable\r\n");
				die("HALT\r\n");
			}
			/* PC133 SPD10 - access time is always 54 */
			if (spd_read_byte(device, 10) != 0x54) {
				print_err("SPD10 DIMM Is Not PC133 Compatable\r\n");
				die("HALT\r\n");
			}

			/* The i82830 can't handle DIMMs smaller than 32MB per
			 * side or larger than 256MB per side. It also can
			 * only support a symmetrical dual-sided dimm.
			 */
			if ((sz.side1 < 32)) {
				print_err("DIMMs smaller than 32MB per side\r\n");
				print_err("are not supported on this board\r\n");
				die("HALT\r\n");
			}

			if ((sz.side2 != 0) && (sz.side2 < 32)) {
				print_err("DIMMs smaller than 32MB per side\r\n");
				print_err("are not supported on this board\r\n");
				die("HALT\r\n");
			}

			if ((sz.side1 > 256) || (sz.side2 > 256)) {
				print_err("DIMMs larger than 256MB per side\r\n");
				print_err("are not supported on this board\r\n");
				die("HALT\r\n");
			}

			if ((sz.side2 != 0) && (sz.side1 != sz.side2)) {
				print_err("This board only supports\r\n");
				print_err("symmetrical dual-sided DIMMs\r\n");
				die("HALT\r\n");
			}

			/* We need to divide size by 32 to set up the
			 * DRB registers.
			*/
			if (sz.side1 > 0) {
				drb1 = sz.side1 >> 5;
			}
			if (sz.side2 > 0) {
				drb2 = sz.side2 >> 5;
			}
		} else {
			PRINT_DEBUG("No DIMM found in slot ");
			PRINT_DEBUG_HEX8(i);
			PRINT_DEBUG("\r\n");

			/* If there's no DIMM in the slot, set value to 0. */
			drb1 = 0;
			drb2 = 0;
		}
      	/* Set the value for DRAM Row Boundary Registers */
		if (i == 0) {
			pci_write_config8(ctrl->d0, DRB, drb1);
			pci_write_config8(ctrl->d0, DRB + 1, drb1 + drb2);
			PRINT_DEBUG("DRB 0x");
			PRINT_DEBUG_HEX8(DRB);
			PRINT_DEBUG(" has been set to 0x");
			PRINT_DEBUG_HEX8(drb1);
			PRINT_DEBUG("\r\n");
			PRINT_DEBUG("DRB1 0x");
			PRINT_DEBUG_HEX8(DRB + 1);
			PRINT_DEBUG(" has been set to 0x");
			PRINT_DEBUG_HEX8(drb1 + drb2);
			PRINT_DEBUG("\r\n");
		} else if (i == 1) {
			value = pci_read_config8(ctrl->d0, DRB + 1);
			pci_write_config8(ctrl->d0, DRB + 2, value + drb1);
			pci_write_config8(ctrl->d0, DRB + 3, value + drb1 + drb2);
			PRINT_DEBUG("DRB2 0x");
			PRINT_DEBUG_HEX8(DRB + 2);
			PRINT_DEBUG(" has been set to 0x");
			PRINT_DEBUG_HEX8(value + drb1);
			PRINT_DEBUG("\r\n");
			PRINT_DEBUG("DRB3 0x");
			PRINT_DEBUG_HEX8(DRB + 3);
			PRINT_DEBUG(" has been set to 0x");
			PRINT_DEBUG_HEX8(value + drb1 + drb2);
			PRINT_DEBUG("\r\n");
		}
	}
}

static void set_dram_row_attributes(const struct mem_controller *ctrl)
{
	int i, dra, col, width, value;

	for (i = 0; i < DIMM_SOCKETS; i++) {
		unsigned device;
		device = ctrl->channel0[i];

		/* First check if a DIMM is actually present. */
		if (spd_read_byte(device, 2) == 0x4) {
			print_debug("Found DIMM in slot ");
			print_debug_hex8(i);
			print_debug(", setting DRA...\r\n");

			dra = 0x00;

			/* columns */
			col = spd_read_byte(device, 4);

			/* data width */
			width = spd_read_byte(device, 6);

			/* calculate page size in bits */
			value = ((1 << col) * width);

			/* convert to Kilobytes */
			dra = ((value / 8) >> 10);

			/* # of banks of DIMM (single or double sided) */
			value = spd_read_byte(device, 5);

			if (value == 1) {
				switch(dra) {
					/* 2KB */
					case 2:
						dra = 0xF0;
						break;
					/* 4KB */
					case 4:
						dra = 0xF1;
						break;
					/* 8KB */
					case 8:
						dra = 0xF2;
						break;
					/* 16KB */
					case 16:
						dra = 0xF3;
						break;
					default:
						print_err("Page size not supported\r\n");
						die("HALT\r\n");
				}
			} else if (value == 2) {
				switch(dra) {
					/* 2KB */
					case 2:
						dra = 0x00;
						break;
					/* 4KB */
					case 4:
						dra = 0x11;
						break;
					/* 8KB */
					case 8:
						dra = 0x22;
						break;
					/* 16KB */
					case 16:
						dra = 0x33;
						break;
					default:
						print_err("Page size not supported\r\n");
						die("HALT\r\n");
				}
			}else {
				print_err("# of banks of DIMM not supported\r\n");
				die("HALT\r\n");
			}

		} else {
			PRINT_DEBUG("No DIMM found in slot ");
			PRINT_DEBUG_HEX8(i);
			PRINT_DEBUG(", setting DRA to 0xFF\r\n");

			/* If there's no DIMM in the slot, set dra value to 0xFF. */
			dra = 0xFF;
		}

		/* Set the value for DRAM Row Attribute Registers */
      	pci_write_config8(ctrl->d0, DRA + i, dra);
		PRINT_DEBUG("DRA 0x");
		PRINT_DEBUG_HEX8(DRA + i);
		PRINT_DEBUG(" has been set to 0x");
		PRINT_DEBUG_HEX8(dra);
		PRINT_DEBUG("\r\n");
	}
}

static void set_dram_timing(const struct mem_controller *ctrl)
{
	/* Set the value for DRAM Timing Register */
	pci_write_config32(ctrl->d0, DRT, 0x00000010);
}

static void set_dram_buffer_strength(const struct mem_controller *ctrl)
{
	/* TODO: This needs to be set according to the DRAM tech
	 * (x8, x16, or x32). Argh, Intel provides no docs on this!
	 * Currently, it needs to be pulled from the output of
	 * lspci -xxx Rx92
	*/

	/* Set the value for System Memory Buffer Strength Control Registers */
	pci_write_config32(ctrl->d0, BUFF_SC, 0xFC9FC909);
}

/*-----------------------------------------------------------------------------
Public interface.
-----------------------------------------------------------------------------*/

static void sdram_set_registers(const struct mem_controller *ctrl)
{
	unsigned value;
	value = 0;

	PRINT_DEBUG("Setting initial registers....\r\n");

      /* Set the value for GMCH Control Register #0 */
      pci_write_config16(ctrl->d0, GCC0, 0xA072);

	/* Set the value for GMCH Control Register #1
	 * Only set bits 6-0, bits 15-7 are reserved.
	 */
	value = pci_read_config16(ctrl->d0, GCC1);
	value |= 0x20;
	pci_write_config16(ctrl->d0, GCC1, value);

	/* Set the value for Fixed DRAM Hole Control Register */
	pci_write_config8(ctrl->d0, FDHC, 0x00);

	/* Set the value for Aperture Base Configuration Register  */
	pci_write_config32(ctrl->d0, APBASE, 0x00000008);

	/* Set the value for Register Range Base Address Register */
	pci_write_config32(ctrl->d0, RRBAR, 0x00000000);

	/* Set the value for Programable Attribute Map Registers
	 * Ideally, this should be R/W for as many ranges as possible.
	 */
	pci_write_config8(ctrl->d0, PAM0, 0x30);
	pci_write_config8(ctrl->d0, PAM1, 0x33);
	pci_write_config8(ctrl->d0, PAM2, 0x33);
	pci_write_config8(ctrl->d0, PAM3, 0x33);
	pci_write_config8(ctrl->d0, PAM4, 0x33);
	pci_write_config8(ctrl->d0, PAM5, 0x33);
	pci_write_config8(ctrl->d0, PAM6, 0x33);

	/* Set the value for DRAM Throttling Control Register */
	pci_write_config32(ctrl->d0, DTC, 0x00000000);

	/* Set the value for System Management RAM Control Register */
	pci_write_config8(ctrl->d0, SMRAM, 0x02);

	/* Set the value for Extended System Management RAM Control Register */
	pci_write_config8(ctrl->d0, ESMRAMC, 0x38);

	PRINT_DEBUG("Initial registers have been set.\r\n");
}

static void sdram_set_spd_registers(const struct mem_controller *ctrl)
{
	spd_set_dram_size(ctrl);

	set_dram_row_attributes(ctrl);

	set_dram_timing(ctrl);

	set_dram_buffer_strength(ctrl);
}

static void sdram_enable(int controllers, const struct mem_controller *ctrl)
{
	int i;

	/* 0. Wait until power/voltages and clocks are stable (200us). */
	udelay(200);

	/* 1. Apply NOP. */
	PRINT_DEBUG("RAM Enable 1: Apply NOP\r\n");
	do_ram_command(ctrl, RAM_COMMAND_NOP, 0);
	udelay(200);

	/* 2. Precharge all. Wait tRP. */
	PRINT_DEBUG("RAM Enable 2: Precharge all\r\n");
	do_ram_command(ctrl, RAM_COMMAND_PRECHARGE, 0);
	udelay(1);

	/* 3. Perform 8 refresh cycles. Wait tRC each time. */
	PRINT_DEBUG("RAM Enable 3: CBR\r\n");
	for (i = 0; i < 8; i++) {
		do_ram_command(ctrl, RAM_COMMAND_CBR, 0);
		udelay(1);
	}

	/* 4. Mode register set. Wait two memory cycles. */
	PRINT_DEBUG("RAM Enable 4: Mode register set\r\n");
	do_ram_command(ctrl, RAM_COMMAND_MRS, 0x1d0);
	udelay(2);

	/* 5. Normal operation (enables refresh) */
	PRINT_DEBUG("RAM Enable 5: Normal operation\r\n");
	do_ram_command(ctrl, RAM_COMMAND_NORMAL, 0);
	udelay(1);

	PRINT_DEBUG("Northbridge following SDRAM init:\r\n");
	DUMPNORTH();
}

From my_tsai at sis.com  Fri Oct  5 05:03:28 2007
From: my_tsai at sis.com (Morgan Tsai)
Date: Fri, 5 Oct 2007 11:03:28 +0800
Subject: [LinuxBIOS] [IMPORT] GIGABYTE GA-2761GXDK
References: <006b01c8058d$38dc52f0$0200a8c0@sis.com.tw>
	<470516D3.1020305@gmx.net>
Message-ID: <006701c806fc$51170ed0$0200a8c0@sis.com.tw>

Dear Carl-Daniel,

You got it, the board in our lab is REV:0.2.
It doesn't have VGA connector on board, so I have to make a "special"
vga external connector cable due to its 12-pin vga con aside PCI slot.
(D-sub VGA connector has 15 pins)

SiS966 southbridge provides 4 SATA connectors, the other two is
provided by SiS187(JMicron clone)


Dear Dennis Chang (SiS),

For Uwe's question, any idea?
>Are there any existing mainstream boards which can use this code
>already? Stuff you can buy in computer shops, not prototype boards?


Morgan

----- Original Message ----- 
From: "Carl-Daniel Hailfinger" <c-d.hailfinger.devel.2006 at gmx.net>
To: "Morgan Tsai" <my_tsai at sis.com>
Cc: <linuxbios at linuxbios.org>; "'Dennis Chang /SiS'" <ktchang at sis.com>;
"Eric Lin" <ericlin at sis.com>
Sent: Friday, October 05, 2007 12:37 AM
Subject: Re: [LinuxBIOS] [IMPORT] GIGABYTE GA-2761GXDK


> Dear Morgan,
>
> This is great!
>
> On 03.10.2007 09:15, Morgan Tsai wrote:
>> Copyright (C) 2007 Morgan Tsai <my_tsai at sis.com>
>> Copyright (C) 2007 Silicon Integrated Systems Corp. (SiS)
>>
>> Change Log:
>>
>> Newly support GIGABYTE GA-2761GXDK
>
> This is a DTX board, right? I found an image of it at
> http://www.pcgameshardware.de/?menu=browser&article_id=601554&image_id=655235&show=original
>
>> CPU type: AMD AM2 socket
>> Northbridge: SiS 761GX
>> Southbridge: SiS 966
>> SuperIO: ITE8716F
>
> 1 PCIe x1 slot
> 1 PCI slot
> 6 SATA connectors (1 external)
>
>> The board is still under testing sample. When we finish test without
>> major problems, this sample will soon become marketing board.
>>
>>
>> Signed-off-by: Morgan Tsai <my_tsai at sis.com>
>
> Thank you very much for this contribution. We will work with you to get
> it included in main LinuxBIOS.
>
> Regards,
> Carl-Daniel




From lemenkov at gmail.com  Fri Oct  5 10:49:31 2007
From: lemenkov at gmail.com (Peter Lemenkov)
Date: Fri, 5 Oct 2007 12:49:31 +0400
Subject: [LinuxBIOS] Flashrom can't detect SST 39SF020A on Gigabyte 7VT880-RZ
Message-ID: <adf480660710050149g1e94dd76ud37704ded446be60@mail.gmail.com>

Hello All!
I've got Gigabyte 7VT880-RZ mainboard. After quick look at the suface
of it I found that it uses SST 39SF020A flash chip. Unfortunately
flashrom won't even read data from flash. Full log here:

http://peter.fedorapeople.org/flashrom.txt

I have no clue what should I do next. Please give an advice.

-- 
With best regards!



From c-d.hailfinger.devel.2006 at gmx.net  Fri Oct  5 12:40:48 2007
From: c-d.hailfinger.devel.2006 at gmx.net (Carl-Daniel Hailfinger)
Date: Fri, 05 Oct 2007 12:40:48 +0200
Subject: [LinuxBIOS] superiotool - dump support for IT8661F
In-Reply-To: <a698c16a0710041154y24ca80acn62ae2e390b55e077@mail.gmail.com>
References: <a698c16a0710041154y24ca80acn62ae2e390b55e077@mail.gmail.com>
Message-ID: <470614B0.7090401@gmx.net>

On 04.10.2007 20:54, Robinson Tryon wrote:
> Signed-off-by: Robinson P. Tryon <bishop.robinson at gmail.com>

Acked-by: Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006 at gmx.net>

> Notes:
> - Added in the missing tab chars manually (I'm still trying to get
> emacs to follow the correct indenting rules).
> - Managed to finish up before 1AM, so my proofing should be better
> this time... :-)
> - What should I do with registers 0x25, 0x26 in the 'Global
> Configuration Registers' table?  They both have an LDN of "All-05h",
> so should they go with the 0x5 GPIO table or in the GCR table?  (I
> took a guess and put them in the former).

You made the right decision.

> ------------------------------------------------------------------------
> 
> Index: ite.c
> ===================================================================
> --- ite.c	(revision 2823)
> +++ ite.c	(working copy)
> @@ -28,6 +28,39 @@
>  
>  /* Note: IT8726F has ID 0x8726 (datasheet wrongly says 0x8716). */
>  const static struct superio_registers reg_table[] = {
> +	{0x8661, "IT8661F", {
> +		{NOLDN, NULL,
> +			{0x00,0x01,0x02,0x03,0x04,0x05,0x06,0x07,0x20,0x21,
> +			 0x22,0x23,0x24,EOT},
> +			{NANA,NANA,NANA,NANA,NANA,NANA,0x00,NANA,0x86,0x61,
> +			 0x00,0x00,0x00,EOT}},
> +		{0x0, "Floppy",
> +			{0x30,0x31,0x60,0x61,0x70,0x71,0x74,0xf0,EOT},
> +			{0x00,0x00,0x03,0xf0,0x06,0x02,0x02,0x00,EOT}},
> +		{0x1, "COM1",
> +			{0x30,0x31,0x60,0x61,0x70,0x71,0xf0,EOT},
> +			{0x00,0x00,0x03,0xf8,0x04,0x02,0x00,EOT}},
> +		{0x2, "COM2",
> +			{0x30,0x31,0x60,0x61,0x70,0x71,0xf0,EOT},
> +			{0x00,0x00,0x02,0xf8,0x03,0x02,0x00,EOT}},
> +		{0x3, "Parallel port",
> +			{0x30,0x31,0x60,0x61,0x62,0x63,0x70,0x71,0x74,0xf0,
> +			 EOT},
> +			{0x00,0x00,0x03,0x78,0x07,0x78,0x07,0x02,0x03,0x03,
> +			 EOT}},
> +		{0x4, "IR",
> +			{0x30,0x31,0x60,0x61,0x62,0x63,0x70,0x71,0x72,0x73,
> +			 0x74,0x75,0xf0,EOT},
> +			{0x00,0x00,0x02,0xe8,0x03,0x00,0x0a,0x02,0x0b,0x02,
> +			 0x01,0x00,0x00,EOT}},
> +		{0x5, "GPIO",
> +			{0x25,0x26,0x60,0x61,0x62,0x63,0x64,0x65,0x66,0x67,
> +			 0x70,0xf0,0xf1,0xf2,0xf3,0xf4,0xf5,0xf6,0xf7,0xf8,
> +			 0xf9,0xfa,0xfb,0xfc,EOT},
> +			{0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,
> +			 0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,
> +			 0x00,0x00,0x00,0x00,EOT}},
> +		{EOT}}},
>  	{0x8702, "IT8702F", {
>  		{EOT}}},
>  	{0x8705, "IT8705F/AF or IT8700F", {
> 


-- 
http://www.hailfinger.org/



From c-d.hailfinger.devel.2006 at gmx.net  Fri Oct  5 12:58:40 2007
From: c-d.hailfinger.devel.2006 at gmx.net (Carl-Daniel Hailfinger)
Date: Fri, 05 Oct 2007 12:58:40 +0200
Subject: [LinuxBIOS] [IMPORT] GIGABYTE GA-2761GXDK
In-Reply-To: <006701c806fc$51170ed0$0200a8c0@sis.com.tw>
References: <006b01c8058d$38dc52f0$0200a8c0@sis.com.tw>	<470516D3.1020305@gmx.net>
	<006701c806fc$51170ed0$0200a8c0@sis.com.tw>
Message-ID: <470618E0.3020803@gmx.net>

Dear Morgan, dear Dennis,

On 05.10.2007 05:03, Morgan Tsai wrote:
> Dear Carl-Daniel,
> 
> You got it, the board in our lab is REV:0.2.
> It doesn't have VGA connector on board, so I have to make a "special"
> vga external connector cable due to its 12-pin vga con aside PCI slot.
> (D-sub VGA connector has 15 pins)
> 
> SiS966 southbridge provides 4 SATA connectors, the other two is
> provided by SiS187(JMicron clone)
> 
> 
> Dear Dennis Chang (SiS),
> 
> For Uwe's question, any idea?
>> Are there any existing mainstream boards which can use this code
>> already? Stuff you can buy in computer shops, not prototype boards?

I found one, but the Southbridge is SiS966L instead of SiS966. Is there
any difference between SiS966L and SiS966?

http://global.shuttle.com/Product/Barebone/SS21T.asp
Socket AM2
SiS 761GX and SiS 966L Chipset
PCI Express x16

Carl-Daniel

> 
> 
> Morgan
> 
> ----- Original Message ----- 
> From: "Carl-Daniel Hailfinger" <c-d.hailfinger.devel.2006 at gmx.net>
> To: "Morgan Tsai" <my_tsai at sis.com>
> Cc: <linuxbios at linuxbios.org>; "'Dennis Chang /SiS'" <ktchang at sis.com>;
> "Eric Lin" <ericlin at sis.com>
> Sent: Friday, October 05, 2007 12:37 AM
> Subject: Re: [LinuxBIOS] [IMPORT] GIGABYTE GA-2761GXDK
> 
> 
>> Dear Morgan,
>>
>> This is great!
>>
>> On 03.10.2007 09:15, Morgan Tsai wrote:
>>> Copyright (C) 2007 Morgan Tsai <my_tsai at sis.com>
>>> Copyright (C) 2007 Silicon Integrated Systems Corp. (SiS)
>>>
>>> Change Log:
>>>
>>> Newly support GIGABYTE GA-2761GXDK
>> This is a DTX board, right? I found an image of it at
>> http://www.pcgameshardware.de/?menu=browser&article_id=601554&image_id=655235&show=original
>>
>>> CPU type: AMD AM2 socket
>>> Northbridge: SiS 761GX
>>> Southbridge: SiS 966
>>> SuperIO: ITE8716F
>> 1 PCIe x1 slot
>> 1 PCI slot
>> 6 SATA connectors (1 external)
>>
>>> The board is still under testing sample. When we finish test without
>>> major problems, this sample will soon become marketing board.
>>>
>>>
>>> Signed-off-by: Morgan Tsai <my_tsai at sis.com>
>> Thank you very much for this contribution. We will work with you to get
>> it included in main LinuxBIOS.
>>
>> Regards,
>> Carl-Daniel
> 
> 


-- 
http://www.hailfinger.org/



From my_tsai at sis.com  Fri Oct  5 13:10:16 2007
From: my_tsai at sis.com (Morgan Tsai)
Date: Fri, 5 Oct 2007 19:10:16 +0800
Subject: [LinuxBIOS] [IMPORT] GIGABYTE GA-2761GXDK
References: <006b01c8058d$38dc52f0$0200a8c0@sis.com.tw>	<470516D3.1020305@gmx.net>
	<006701c806fc$51170ed0$0200a8c0@sis.com.tw>
	<470618E0.3020803@gmx.net>
Message-ID: <000601c80740$50345f10$0200a8c0@sis.com.tw>

Dear Carl-Daniel,

SiS966L has 2 SATA port (1.5G), and only 10/100 Ethernet MAC
SiS966 has 4 SATA port (1.5G), and Gigabit Ethernet MAC

'L' means 'Lite'
Other specifications are identical.


Morgan

----- Original Message ----- 
From: "Carl-Daniel Hailfinger" <c-d.hailfinger.devel.2006 at gmx.net>
To: "Morgan Tsai" <my_tsai at sis.com>
Cc: "'Dennis Chang /SiS'" <ktchang at sis.com>; "Eric Lin" <ericlin at sis.com>; 
<linuxbios at linuxbios.org>
Sent: Friday, October 05, 2007 6:58 PM
Subject: Re: [LinuxBIOS] [IMPORT] GIGABYTE GA-2761GXDK


> Dear Morgan, dear Dennis,
>
> On 05.10.2007 05:03, Morgan Tsai wrote:
>> Dear Carl-Daniel,
>>
>> You got it, the board in our lab is REV:0.2.
>> It doesn't have VGA connector on board, so I have to make a "special"
>> vga external connector cable due to its 12-pin vga con aside PCI slot.
>> (D-sub VGA connector has 15 pins)
>>
>> SiS966 southbridge provides 4 SATA connectors, the other two is
>> provided by SiS187
>>
>>
>> Dear Dennis Chang (SiS),
>>
>> For Uwe's question, any idea?
>>> Are there any existing mainstream boards which can use this code
>>> already? Stuff you can buy in computer shops, not prototype boards?
>
> I found one, but the Southbridge is SiS966L instead of SiS966. Is there
> any difference between SiS966L and SiS966?
>
> http://global.shuttle.com/Product/Barebone/SS21T.asp
> Socket AM2
> SiS 761GX and SiS 966L Chipset
> PCI Express x16
>
> Carl-Daniel
>
>>
>>
>> Morgan
>>
>> ----- Original Message ----- 
>> From: "Carl-Daniel Hailfinger" <c-d.hailfinger.devel.2006 at gmx.net>
>> To: "Morgan Tsai" <my_tsai at sis.com>
>> Cc: <linuxbios at linuxbios.org>; "'Dennis Chang /SiS'" <ktchang at sis.com>;
>> "Eric Lin" <ericlin at sis.com>
>> Sent: Friday, October 05, 2007 12:37 AM
>> Subject: Re: [LinuxBIOS] [IMPORT] GIGABYTE GA-2761GXDK
>>
>>
>>> Dear Morgan,
>>>
>>> This is great!
>>>
>>> On 03.10.2007 09:15, Morgan Tsai wrote:
>>>> Copyright (C) 2007 Morgan Tsai <my_tsai at sis.com>
>>>> Copyright (C) 2007 Silicon Integrated Systems Corp. (SiS)
>>>>
>>>> Change Log:
>>>>
>>>> Newly support GIGABYTE GA-2761GXDK
>>> This is a DTX board, right? I found an image of it at
>>> http://www.pcgameshardware.de/?menu=browser&article_id=601554&image_id=655235&show=original
>>>
>>>> CPU type: AMD AM2 socket
>>>> Northbridge: SiS 761GX
>>>> Southbridge: SiS 966
>>>> SuperIO: ITE8716F
>>> 1 PCIe x1 slot
>>> 1 PCI slot
>>> 6 SATA connectors (1 external)
>>>
>>>> The board is still under testing sample. When we finish test without
>>>> major problems, this sample will soon become marketing board.
>>>>
>>>>
>>>> Signed-off-by: Morgan Tsai <my_tsai at sis.com>
>>> Thank you very much for this contribution. We will work with you to get
>>> it included in main LinuxBIOS.
>>>
>>> Regards,
>>> Carl-Daniel
>>
>>
>
>
> -- 
> http://www.hailfinger.org/ 




From c-d.hailfinger.devel.2006 at gmx.net  Fri Oct  5 13:26:45 2007
From: c-d.hailfinger.devel.2006 at gmx.net (Carl-Daniel Hailfinger)
Date: Fri, 05 Oct 2007 13:26:45 +0200
Subject: [LinuxBIOS] [IMPORT] GIGABYTE GA-2761GXDK
In-Reply-To: <000601c80740$50345f10$0200a8c0@sis.com.tw>
References: <006b01c8058d$38dc52f0$0200a8c0@sis.com.tw>	<470516D3.1020305@gmx.net>	<006701c806fc$51170ed0$0200a8c0@sis.com.tw>	<470618E0.3020803@gmx.net>
	<000601c80740$50345f10$0200a8c0@sis.com.tw>
Message-ID: <47061F75.6040407@gmx.net>

Dear Morgan,

On 05.10.2007 13:10, Morgan Tsai wrote:
> Dear Carl-Daniel,
> 
> SiS966L has 2 SATA port (1.5G), and only 10/100 Ethernet MAC
> SiS966 has 4 SATA port (1.5G), and Gigabit Ethernet MAC

Thanks for the information.

> 'L' means 'Lite'
> Other specifications are identical.

Does that mean your code also works on the SiS966L or do we need some
changes? It would be great to be able to support SiS966 and SiS966L with
the same code.


Carl-Daniel



From rasmus at wiman.org  Fri Oct  5 13:28:53 2007
From: rasmus at wiman.org (Rasmus Wiman)
Date: Fri, 5 Oct 2007 13:28:53 +0200
Subject: [LinuxBIOS] [IMPORT] GIGABYTE GA-2761GXDK
In-Reply-To: <47061F75.6040407@gmx.net>
References: <006b01c8058d$38dc52f0$0200a8c0@sis.com.tw>
	<470516D3.1020305@gmx.net>
	<006701c806fc$51170ed0$0200a8c0@sis.com.tw>
	<470618E0.3020803@gmx.net>
	<000601c80740$50345f10$0200a8c0@sis.com.tw>
	<47061F75.6040407@gmx.net>
Message-ID: <20071005132853.83fe9be0.rasmus@wiman.org>

Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006 at gmx.net> skrev:

> Does that mean your code also works on the SiS966L or do we need some
> changes? It would be great to be able to support SiS966 and SiS966L
> with the same code.

Plus, that Shuttle barebone costs less than many motherboards and just
a little bit more than a M57SLI-S4.

/Rasmus



From c-d.hailfinger.devel.2006 at gmx.net  Fri Oct  5 13:44:10 2007
From: c-d.hailfinger.devel.2006 at gmx.net (Carl-Daniel Hailfinger)
Date: Fri, 05 Oct 2007 13:44:10 +0200
Subject: [LinuxBIOS] Flashrom can't detect SST 39SF020A on Gigabyte
	7VT880-RZ
In-Reply-To: <adf480660710050149g1e94dd76ud37704ded446be60@mail.gmail.com>
References: <adf480660710050149g1e94dd76ud37704ded446be60@mail.gmail.com>
Message-ID: <4706238A.3010107@gmx.net>

On 05.10.2007 10:49, Peter Lemenkov wrote:
> Hello All!
> I've got Gigabyte 7VT880-RZ mainboard. After quick look at the suface
> of it I found that it uses SST 39SF020A flash chip. Unfortunately
> flashrom won't even read data from flash. Full log here:
> 
> http://peter.fedorapeople.org/flashrom.txt
> 
> I have no clue what should I do next. Please give an advice.

The ID should be 0xbf (manuf)/ 0xb6 (device), but nothing like that
appears in the logs. I just verified with the data sheet that the
probing sequence is correct.

> Probing for SST39SF020A, 256 KB
> probe_jedec: id1 0x25, id2 0x41

Since what you got was not what you expected, I believe the board needs
an additional enable sequence.

Regards,
Carl-Daniel



From echelon at free.fr  Fri Oct  5 15:00:15 2007
From: echelon at free.fr (echelon at free.fr)
Date: Fri, 05 Oct 2007 15:00:15 +0200
Subject: [LinuxBIOS] badly initialized (?) pci bridge on the M57SLI
	(with irq table and mptable)
In-Reply-To: <20071004200602.GA12146@localdomain>
References: <20070919212952.GA16399@localdomain>
	<2ea3fae10709191629w17affbaeh4daf8a0715737ad2@mail.gmail.com>
	<1190278384.46f234f055fc2@imp.free.fr>
	<2ea3fae10709200944o6ebbc89p74ddd188db4826e1@mail.gmail.com>
	<20070924213615.GB26022@greenwood>
	<2ea3fae10709241623l1b579378td2605ddad12be414@mail.gmail.com>
	<1190713007.46f8d6af1483e@imp.free.fr>
	<2ea3fae10709251226x4098fce2o56d61dbec6af9447@mail.gmail.com>
	<1190858035.46fb0d33df9c7@imp.free.fr>
	<1191468741.47045ec51281d@imp.free.fr>
	<20071004200602.GA12146@localdomain>
Message-ID: <1191589215.4706355fce344@imp.free.fr>

Hi gentlemens,

 Sorry for answering so late, but Im back after 3 sleepless nights so Im under
continuous coffee perfusion simply to stay awake..
 Firstly to answer to Yinghai, I didn't use dumpio (I don't know what is
this..). I'm mostly a hardware guy (I come from the "embedded world") so my
first reaction was to put an oscilloscope probe on the PCI bus..
 So what have I found out?
  - 1) with the initial LinuxBIOS code, it looks like some control signals of
the PCI bus are not correctly driven when on tries to do configuration requests
under Linux. More specifically, when a 32b read is done on the CONFIG_DATA port
(0cfc) which should trigger a pci configuration register read, one can see that
the signal C/BE[3]# (pin 26 - side B on a PCI slot) doesn't rise at a logical
level of "1" as it should do. Indeed, the PCI bus spec says that the signals
C/BE carry the PCI command code at the beginning of a PCI transaction (p.23 -
chapter 3 "Bus Operation"). This code should be "1010" for a configuration read,
so C/BE[3] should be '1'. In fact it doesn't .. (I have some pics with my
oscilloscope measurement, if someone is interested by them plz let me know..)
  - 2) after analising a little bit the code of the mcp55 southbridge in the LB
source tree (especially the mcp55_early_setup_car.c file), I realised the the
mcp55 southbridge has some kind of "IO multiplexer" unit (like some modern
processors in
the embedded world) which enables the configuration of the mcp55 pins either as
GPIOs, either as "nominal" functions (PCI control signals for example). So, I
asked my self if the GPIO configuration was not fitted for the m57sli board..
  - 3) Btw I figured out that registers of the "IO control unit" of mcp55 can be
mapped into the IO space by writting into the SYSCTRL_REG of the 00:01.1 pci
device integrated into the SB. Indeed by using this value as a base (under
Linux, this register holds the value 0x1400) one can access the GPIO registers
of MCP55 (beginning @ the 0xc0 offset? maybe..) These are 8 bit registers
apparently..
  - 4) After booting with the proprietary Award bios, I dumped this table under
Linux (with a simple custom utility that I wrote for this purpose..). I dumped
256 bytes from 0x1400.
  - 5) I switched (manually.. ;o)) to LinuxBIOS and repeated the operation. I
compared the 2 dump files. I found out that some values do indeed differ, and
one of them corresponds to "GPIO39" as it appears in the "cache_as_ram_auto.c"
file. I changed this value accordingly end rebuild LinuxBIOS.
  - 6) I reflashed and .. voila!..

(Btw I found that "GPIO40" differs as well and should have the value 0x68, but I
didn't dare to do this change yet.. :o))

 Now, after taking a break, I will help with the implementation of the flashrom
support on the m57sli board.. But right now I need to sleep!

Best regards,
 Florentin

Quoting Ward Vandewege <ward at gnu.org>:

> Hi Florentin,
>
> On Thu, Oct 04, 2007 at 05:32:21AM +0200, echelon at free.fr wrote:
> > I propose:
> >
> > $(LB)/src/mainboard/gigabyte/m57sli/cache_as_ram_auto.c
> > 138c138
> > <  RES_PORT_IO_8, SYSCTRL_IO_BASE + 0xc0+38, 0x00, 0x44,/* GPIO39 PCI_GNT3
> */ \
> > ---
> > >  RES_PORT_IO_8, SYSCTRL_IO_BASE + 0xc0+38, 0x00, 0x68,/* GPIO39 PCI_GNT3
> */ \
> >
> > My vga pci card and a pci network card are recognised with this under
> LinuxBIOS!
> > I don't understand why this works, but it works..
> > (I will explain tomorrow how I found this value)
> >
> > Please can someone validate my change?a
>
> I've tried it on a v1.1 m57sli (the plcc version).
>
> Great work! This fixes one of the PCI slots (01:07.0), but not the second
> slot (01:08.0, closest to the edge of the board). Can you explain how you got
> to this value, so that we can activate the second PCI slot as well?
>
> Thanks!
> Ward.
>
> --
> Ward Vandewege <ward at fsf.org>
> Free Software Foundation - Senior System Administrator
>





From niko at ornia.hampshire.edu  Fri Oct  5 09:41:56 2007
From: niko at ornia.hampshire.edu (niko)
Date: Fri, 05 Oct 2007 03:41:56 -0400
Subject: [LinuxBIOS] Tyan Thunder n3600R (S2912) support status?
Message-ID: <4705EAC4.5030302@ornia.hampshire.edu>

Hello there,

I'm in the midst of an upgrade for my server, but I want the entire 
thing to run 100% Free Software, including LinuxBIOS.  The Tyan S2912 
seems to be a perfect match feature/specifications wise for what I am 
searching for.  I need a dual Socket F board with built in SAS and SATA2 
with RAID-5 support on the latter, and ideally two gigabit NICs to 
boot.  This Tyan board largely fits this description more than any other 
board on the LinuxBIOS supported motherboard compatibility list.

The problem is that on the list it is still marked "WIP" with a yellow 
box instead of a green one.  What is the current status of LinuxBIOS 
support for this board?  Will it work at all or maybe partially?  What 
is/isn't working?  I need these certain features on my next motherboard, 
but I also need stability with LinuxBIOS on the board.  Is this too much 
to ask for a dual Socket F board such as this Tyan?

I should also note that I'm not particularly attached to this board.  If 
LinuxBIOS works better with another dual Socket F board, I would love to 
know about it.  I just need the SAS and SATA2, really.

I would sincerely love it if someone could help me understand the 
current state of LinuxBIOS support for this class of motherboards...


..here's hoping the compatibility list is out of date!

Thank you,

?Niko



From rasmus at wiman.org  Fri Oct  5 15:32:43 2007
From: rasmus at wiman.org (Rasmus Wiman)
Date: Fri, 5 Oct 2007 15:32:43 +0200
Subject: [LinuxBIOS] [PATCH] Call for help: superiotool
In-Reply-To: <20071004022202.GA30344@greenwood>
References: <20070923111315.GC12926@greenwood>
	<20071002152938.084fdaef.rasmus@wiman.org>
	<20071004022202.GA30344@greenwood>
Message-ID: <20071005153243.aaa117a3.rasmus@wiman.org>

Uwe Hermann <uwe at hermann-uwe.de> wrote:

> If you want to, feel free to grab the datasheet and add dump support.
> Nothing complex, just a bit time-consuming...

Not so time-consuming for an unemployed guy like me. A few questions,
though. I am not sure how I am supposed to use the constants NANA, RSVD
and MISC, as defined in superiotool.h. I marked the default for global
CR 07 and 21 as NANA, but 07 is logical device number and msd of 21 is
supposedly always 1 and lsd is chip revision id, on my HF it is 7. For
24 the datasheet says "Default 0b1s000s0s", a notation I'm unfamiliar
with, so I set the default to MISC. This is very likely the wrong way
to do it. Also, a few registers are specified as "reserved" or
"Test:Reserver for winbond", but they provide a default, so I entered
that default.

Also, I only grabbed the W83627HF/F datasheet, I think there was a HG/G
sheet available too.

-- 

/Rasmus Wiman

Geek for hire
-------------- next part --------------
A non-text attachment was scrubbed...
Name: w83627HF_F.patch
Type: text/x-patch
Size: 1913 bytes
Desc: not available
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20071005/d590b504/attachment.patch>

From svn at openbios.org  Fri Oct  5 15:47:05 2007
From: svn at openbios.org (svn at openbios.org)
Date: Fri,  5 Oct 2007 15:47:05 +0200
Subject: [LinuxBIOS] r2825 - trunk/util/superiotool
Message-ID: <mailman.700.1355071172.16123.coreboot@coreboot.org>

Author: uwe
Date: 2007-10-05 15:47:04 +0200 (Fri, 05 Oct 2007)
New Revision: 2825

Modified:
   trunk/util/superiotool/ite.c
Log:
Add dump support for the ITE IT8661F. Note that this chip will not yet
be detected, as it needs a non-standard init sequence.

Minor other fix: Drop incorrect 0x2b from LDN 5 of the ITE IT8705F.

Signed-off-by: Robinson P. Tryon <bishop.robinson at gmail.com>
Acked-by: Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006 at gmx.net>
Acked-by: Uwe Hermann <uwe at hermann-uwe.de>



Modified: trunk/util/superiotool/ite.c
===================================================================
--- trunk/util/superiotool/ite.c	2007-10-04 18:34:36 UTC (rev 2824)
+++ trunk/util/superiotool/ite.c	2007-10-05 13:47:04 UTC (rev 2825)
@@ -28,6 +28,40 @@
 
 /* Note: IT8726F has ID 0x8726 (datasheet wrongly says 0x8716). */
 const static struct superio_registers reg_table[] = {
+	{0x8661, "IT8661F", {
+		/* TODO: Needs different init sequence. */
+		{NOLDN, NULL,
+			{0x00,0x01,0x02,0x03,0x04,0x05,0x06,0x07,0x20,0x21,
+			 0x22,0x23,0x24,EOT},
+			{NANA,NANA,NANA,NANA,NANA,NANA,0x00,NANA,0x86,0x61,
+			 0x00,0x00,0x00,EOT}},
+		{0x0, "Floppy",
+			{0x30,0x31,0x60,0x61,0x70,0x71,0x74,0xf0,EOT},
+			{0x00,0x00,0x03,0xf0,0x06,0x02,0x02,0x00,EOT}},
+		{0x1, "COM1",
+			{0x30,0x31,0x60,0x61,0x70,0x71,0xf0,EOT},
+			{0x00,0x00,0x03,0xf8,0x04,0x02,0x00,EOT}},
+		{0x2, "COM2",
+			{0x30,0x31,0x60,0x61,0x70,0x71,0xf0,EOT},
+			{0x00,0x00,0x02,0xf8,0x03,0x02,0x00,EOT}},
+		{0x3, "Parallel port",
+			{0x30,0x31,0x60,0x61,0x62,0x63,0x70,0x71,0x74,
+			 0xf0,EOT},
+			{0x00,0x00,0x03,0x78,0x07,0x78,0x07,0x02,0x03,
+			 0x03,EOT}},
+		{0x4, "IR",
+			{0x30,0x31,0x60,0x61,0x62,0x63,0x70,0x71,0x72,0x73,
+			 0x74,0x75,0xf0,EOT},
+			{0x00,0x00,0x02,0xe8,0x03,0x00,0x0a,0x02,0x0b,0x02,
+			 0x01,0x00,0x00,EOT}},
+		{0x5, "GPIO",
+			{0x25,0x26,0x60,0x61,0x62,0x63,0x64,0x65,0x66,0x67,
+			 0x70,0xf0,0xf1,0xf2,0xf3,0xf4,0xf5,0xf6,0xf7,0xf8,
+			 0xf9,0xfa,0xfb,0xfc,EOT},
+			{0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,
+			 0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,
+			 0x00,0x00,0x00,0x00,EOT}},
+		{EOT}}},
 	{0x8702, "IT8702F", {
 		{EOT}}},
 	{0x8705, "IT8705F/AF or IT8700F", {
@@ -54,20 +88,20 @@
 			{0x00,0x00,0x02,0x90,0x02,0x30,0x09,0x00,0x00,0x00,
 			 0x00,0x00,NANA,NANA,EOT}},
 		{0x5, "GPIO",
-			{0x25,0x26,0x27,0x28,0x29,0x2a,0x2b,0x60,0x61,0x62,
-			 0x63,0x64,0x65,0x70,0x71,0x72,0xb0,0xb1,0xb2,0xb3,
-			 0xb4,0xb5,0xb8,0xb9,0xba,0xbb,0xbc,0xbd,0xc0,0xc1,
-			 0xc2,0xc3,0xc4,0xc5,0xc8,0xc9,0xca,0xcb,0xcc,0xcd,
-			 0xd0,0xd1,0xd2,0xd3,0xd4,0xd5,0xd6,0xd8,0xd9,0xda,
-			 0xf0,0xf1,0xf2,0xf5,0xf6,0xf7,0xf8,0xf9,0xfa,0xfb,
-			 0xfc,0xfd,0xfe,0xff,EOT},
+			{0x25,0x26,0x27,0x28,0x29,0x2a,0x60,0x61,0x62,0x63,
+			 0x64,0x65,0x70,0x71,0x72,0xb0,0xb1,0xb2,0xb3,0xb4,
+			 0xb5,0xb8,0xb9,0xba,0xbb,0xbc,0xbd,0xc0,0xc1,0xc2,
+			 0xc3,0xc4,0xc5,0xc8,0xc9,0xca,0xcb,0xcc,0xcd,0xd0,
+			 0xd1,0xd2,0xd3,0xd4,0xd5,0xd6,0xd8,0xd9,0xda,0xf0,
+			 0xf1,0xf2,0xf5,0xf6,0xf7,0xf8,0xf9,0xfa,0xfb,0xfc,
+			 0xfd,0xfe,0xff,EOT},
 			{0x00,0x00,0x00,0xff,0xe0,0xff,0x00,0x00,0x00,0x00,
 			 0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,
 			 0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,
 			 0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,
 			 0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,
 			 0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,
-			 0x00,0x00,NANA,0x00,EOT}},
+			 0x00,NANA,0x00,EOT}},
 		{0x6, "Game port",
 			{0x30,0x60,0x61,EOT},
 			{0x00,0x02,0x01,EOT}},




From uwe at hermann-uwe.de  Fri Oct  5 15:48:33 2007
From: uwe at hermann-uwe.de (Uwe Hermann)
Date: Fri, 5 Oct 2007 15:48:33 +0200
Subject: [LinuxBIOS] superiotool - dump support for IT8661F
In-Reply-To: <470614B0.7090401@gmx.net>
References: <a698c16a0710041154y24ca80acn62ae2e390b55e077@mail.gmail.com>
	<470614B0.7090401@gmx.net>
Message-ID: <20071005134833.GA5376@greenwood>

On Fri, Oct 05, 2007 at 12:40:48PM +0200, Carl-Daniel Hailfinger wrote:
> On 04.10.2007 20:54, Robinson Tryon wrote:
> > Signed-off-by: Robinson P. Tryon <bishop.robinson at gmail.com>
> 
> Acked-by: Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006 at gmx.net>

Yep, looks good, r2825.

However, this chip will not yet be detected (needs different init
sequence). I'll fix that later if nobody beats me to it.


Uwe.
-- 
http://www.hermann-uwe.de  | http://www.holsham-traders.de
http://www.crazy-hacks.org | http://www.unmaintained-free-software.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20071005/26203303/attachment.sig>

From info at coresystems.de  Fri Oct  5 16:34:23 2007
From: info at coresystems.de (LinuxBIOS information)
Date: Fri, 05 Oct 2007 16:34:23 +0200
Subject: [LinuxBIOS] r2825 build service
Message-ID: <E1IdoFz-0001hl-7G@khepri.openbios.org>

Dear LinuxBIOS readers!

This is the automated build check service of LinuxBIOS.

The developer "uwe" checked in revision 2825 to
the LinuxBIOS source repository and caused the following 
changes:

Change Log:
Add dump support for the ITE IT8661F. Note that this chip will not yet
be detected, as it needs a non-standard init sequence.

Minor other fix: Drop incorrect 0x2b from LDN 5 of the ITE IT8705F.

Signed-off-by: Robinson P. Tryon <bishop.robinson at gmail.com>
Acked-by: Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006 at gmx.net>
Acked-by: Uwe Hermann <uwe at hermann-uwe.de>



Build Log:
Compilation of arima:hdama is still broken
See the error log at http://qa.linuxbios.org/log_buildbrd.php?revision=2825&device=hdama&vendor=arima
Compilation of ibm:e325 is still broken
See the error log at http://qa.linuxbios.org/log_buildbrd.php?revision=2825&device=e325&vendor=ibm
Compilation of ibm:e326 is still broken
See the error log at http://qa.linuxbios.org/log_buildbrd.php?revision=2825&device=e326&vendor=ibm
Compilation of iei:juki-511p is still broken
See the error log at http://qa.linuxbios.org/log_buildbrd.php?revision=2825&device=juki-511p&vendor=iei
Compilation of iwill:dk8s2 is still broken
See the error log at http://qa.linuxbios.org/log_buildbrd.php?revision=2825&device=dk8s2&vendor=iwill
Compilation of iwill:dk8x is still broken
See the error log at http://qa.linuxbios.org/log_buildbrd.php?revision=2825&device=dk8x&vendor=iwill
Compilation of newisys:khepri is still broken
See the error log at http://qa.linuxbios.org/log_buildbrd.php?revision=2825&device=khepri&vendor=newisys


If something broke during this checkin please be a pain 
in uwe's neck until the issue is fixed.

If this issue is not fixed within 24h the revision should 
be backed out.

   Best regards,
     LinuxBIOS automatic build system





From rasmus at wiman.org  Fri Oct  5 16:38:01 2007
From: rasmus at wiman.org (Rasmus Wiman)
Date: Fri, 5 Oct 2007 16:38:01 +0200
Subject: [LinuxBIOS] [PATCH] Call for help: superiotool
In-Reply-To: <20071005153243.aaa117a3.rasmus@wiman.org>
References: <20070923111315.GC12926@greenwood>
	<20071002152938.084fdaef.rasmus@wiman.org>
	<20071004022202.GA30344@greenwood>
	<20071005153243.aaa117a3.rasmus@wiman.org>
Message-ID: <20071005163801.5ef1c1ba.rasmus@wiman.org>

Rasmus Wiman <rasmus at wiman.org> wrote:

> Also, I only grabbed the W83627HF/F datasheet, I think there was a
> HG/G sheet available too.

Rediffed against r2825, my patch was against r2823.

-- 

/Rasmus Wiman

Geek for hire
-------------- next part --------------
A non-text attachment was scrubbed...
Name: w83627HF_F_r2825.patch
Type: text/x-patch
Size: 1879 bytes
Desc: not available
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20071005/89ec1973/attachment.patch>

From myles at pel.cs.byu.edu  Fri Oct  5 17:02:52 2007
From: myles at pel.cs.byu.edu (Myles Watson)
Date: Fri, 5 Oct 2007 09:02:52 -0600
Subject: [LinuxBIOS] Timer frequencies
Message-ID: <000801c80760$cd451290$4c23040a@chimp>

I got Bochs to fail the same way the hardware (my Tyan s2892) fails when I
turned down the timer tick interrupt frequency.  I'm having trouble finding
the place where the timer gets set up.  (Grepping for time,rtc,timer,hz,
etc.)

 

Can someone tell me where I can make the interrupts come at 100 Hz in
LinuxBIOS?

 

Thanks,

Myles

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20071005/8ff28377/attachment.html>

From svn at openbios.org  Fri Oct  5 17:11:39 2007
From: svn at openbios.org (svn at openbios.org)
Date: Fri,  5 Oct 2007 17:11:39 +0200
Subject: [LinuxBIOS] r2826 - trunk/util/superiotool
Message-ID: <mailman.701.1355071172.16123.coreboot@coreboot.org>

Author: uwe
Date: 2007-10-05 17:11:38 +0200 (Fri, 05 Oct 2007)
New Revision: 2826

Modified:
   trunk/util/superiotool/smsc.c
Log:
Add dump support for the SMSC LPC47M10x (trivial).

Signed-off-by: Uwe Hermann <uwe at hermann-uwe.de>
Acked-by: Uwe Hermann <uwe at hermann-uwe.de>



Modified: trunk/util/superiotool/smsc.c
===================================================================
--- trunk/util/superiotool/smsc.c	2007-10-05 13:47:04 UTC (rev 2825)
+++ trunk/util/superiotool/smsc.c	2007-10-05 15:11:38 UTC (rev 2826)
@@ -53,6 +53,39 @@
 	{0x51, "LPC47B27x", {
 		{EOT}}},
 	{0x59, "LPC47M10x", {
+		{NOLDN, NULL,
+			{0x03,0x07,0x20,0x21,0x22,0x23,0x24,0x26,0x27,0x28,
+			 0x2a,0x2b,0x2c,0x2d,0x2e,0x2f,EOT},
+			{RSVD,0x00,0x59,NANA,0x00,0x00,0x44,MISC,MISC,RSVD,
+			 NANA,NANA,NANA,NANA,NANA,NANA,EOT}},
+		{0x0, "Floppy",
+			{0x30,0x60,0x61,0x70,0x74,0xf0,0xf1,0xf2,0xf4,
+			 0xf5,EOT},
+			{0x00,0x03,0xf0,0x06,0x02,0x0e,0x00,0xff,0x00,
+			 0x00,EOT}},
+		{0x3, "Parallel port",
+			{0x30,0x60,0x61,0x70,0x74,0xf0,0xf1,EOT},
+			{0x00,0x00,0x00,0x00,0x04,0x3c,0x00,EOT}},
+		{0x4, "COM1",
+			{0x30,0x60,0x61,0x70,0xf0,EOT},
+			{0x00,0x00,0x00,0x00,0x00,EOT}},
+		{0x5, "COM2",
+			{0x30,0x60,0x61,0x62,0x63,0x70,0x74,0xf0,0xf1,
+			 0xf2,EOT},
+			{NANA,0x00,0x00,RSVD,RSVD,0x00,RSVD,0x00,0x02,
+			 0x03,EOT}},
+		{0x7, "Keyboard",
+			{0x30,0x70,0x72,0xf0,EOT},
+			{0x00,0x00,0x00,0x00,EOT}},
+		{0x9, "Game port",
+			{0x30,0x60,0x61,EOT},
+			{0x00,0x00,0x00,EOT}},
+		{0xa, "Power Management Events (PME)",
+			{0x30,0x60,0x61,0xf0,0xf1,EOT},
+			{0x00,0x00,0x00,NANA,RSVD,EOT}},
+		{0xb, "MPU-401",
+			{0x30,0x60,0x61,0x70,EOT},
+			{0x00,0x03,0x30,0x05,EOT}},
 		{EOT}}},
 	{0x60, "LPC47M15x", {
 		{EOT}}},




From uwe at hermann-uwe.de  Fri Oct  5 17:16:21 2007
From: uwe at hermann-uwe.de (Uwe Hermann)
Date: Fri, 5 Oct 2007 17:16:21 +0200
Subject: [LinuxBIOS] SMSC LPC47M10x
In-Reply-To: <20070923111917.GD12926@greenwood>
References: <20070923111315.GC12926@greenwood>
	<20070923111917.GD12926@greenwood>
Message-ID: <20071005151621.GB5376@greenwood>

This is an IBM NetVista A30p box.

$ superiotool -d
Found SMSC LPC47M10x (id=0x59, rev=0x01) at 0x2e
Register dump:
idx 03 07 20 21 22 23 24 26 27 28 2a 2b 2c 2d 2e 2f
val 00 0b 59 01 39 00 44 2e 00 00 00 00 00 00 00 00
def RR 00 59 NA 00 00 44 MM MM RR NA NA NA NA NA NA
LDN 0x00 (Floppy)
idx 30 60 61 70 74 f0 f1 f2 f4 f5
val 01 03 f0 06 02 0e 00 ff 00 00
def 00 03 f0 06 02 0e 00 ff 00 00
LDN 0x03 (Parallel port)
idx 30 60 61 70 74 f0 f1
val 01 03 78 07 03 ba 00
def 00 00 00 00 04 3c 00
LDN 0x04 (COM1)
idx 30 60 61 70 f0
val 01 03 f8 04 00
def 00 00 00 00 00
LDN 0x05 (COM2)
idx 30 60 61 62 63 70 74 f0 f1 f2
val 01 02 f8 00 00 03 04 00 06 03
def NA 00 00 RR RR 00 RR 00 02 03
LDN 0x07 (Keyboard)
idx 30 70 72 f0
val 01 01 0c 04
def 00 00 00 00
LDN 0x09 (Game port)
idx 30 60 61
val 00 00 00
def 00 00 00
LDN 0x0a (Power Management Events (PME))
idx 30 60 61 f0 f1
val 01 08 00 00 00
def 00 00 00 NA RR
LDN 0x0b (MPU-401)
idx 30 60 61 70
val 00 03 30 05
def 00 03 30 05


Uwe.
-- 
http://www.hermann-uwe.de  | http://www.holsham-traders.de
http://www.crazy-hacks.org | http://www.unmaintained-free-software.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20071005/a48719be/attachment.sig>

From uwe at hermann-uwe.de  Fri Oct  5 17:22:33 2007
From: uwe at hermann-uwe.de (Uwe Hermann)
Date: Fri, 5 Oct 2007 17:22:33 +0200
Subject: [LinuxBIOS] Call for help: superiotool
In-Reply-To: <4705183C.6020804@gmx.net>
References: <20070923111315.GC12926@greenwood>
	<a698c16a0709270921l860615dv3ebe8d49e2f4c791@mail.gmail.com>
	<46FBDB3E.4000009@gmx.net>
	<a698c16a0710012037l37bc9d07i6628563002d7e47a@mail.gmail.com>
	<470256CB.9060008@gmx.net>
	<a698c16a0710020844ud12485dhb063f76800170b63@mail.gmail.com>
	<470268D0.9050107@gmx.net> <20071003024216.GD6851@greenwood>
	<4705183C.6020804@gmx.net>
Message-ID: <20071005152233.GC5376@greenwood>

On Thu, Oct 04, 2007 at 06:43:40PM +0200, Carl-Daniel Hailfinger wrote:
> >>>>> Probing for Fintek Super I/O at 0x2e... failed
> >>>>> Probing for Fintek Super I/O at 0x4e... failed
> >>>>> Probing 0x2e, failed (0x22), data returns 0x04
> >>>>> Probing 0x2e, failed (0x22), data returns 0x04
> >>>>> Probing for ITE Super I/O (init=0x87,0x01,0x55,0x55/0xaa) at 0x4e... failed
> >>>>> Probing for ITE Super I/O (init=0x87,0x87) at 0x4e... failed
> >>>>> Probing 0x2e, failed (0x21), data returns 0x00
> >>>>> Probing 0x2e, failed (0x0e), data returns 0x00
> >>>>> Probing for SMSC Super I/O at 0x4e... failed
> >>>>> Probing for SMSC Super I/O at 0x4e... failed
> >>>>> Probing for SMSC Super I/O at 0x3f0... failed
> >>>>> Probing for SMSC Super I/O at 0x3f0... failed
> >>>>> Probing for SMSC Super I/O at 0x370... failed
> >>>>> Probing for SMSC Super I/O at 0x370... failed

> >> However, the probing sequence is incomplete (at least when judging it by
> >> its output) and Uwe rewrote the probing sequence, so he can take a look
> >> at it.
> > 
> > Will do. What do you mean with incomplete?
> > The --verbose output needs some more fixing to make it more informative, IMO. 
> 
> ITE superio probing at 0x2e does not appear in the log above.

Ah, yes, indeed. I think it _was_ being probed but not correctly shown
in the output. I guess the two 'Probing 0x2e, failed...' lines belong to
the ITE 0x2e probing.

Anyway, the output should be much better in the latest revision. Can you
please repost the --verbose output?


Uwe.
-- 
http://www.hermann-uwe.de  | http://www.holsham-traders.de
http://www.crazy-hacks.org | http://www.unmaintained-free-software.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20071005/2edcd01c/attachment.sig>

From rasmus at wiman.org  Fri Oct  5 17:22:54 2007
From: rasmus at wiman.org (Rasmus Wiman)
Date: Fri, 5 Oct 2007 17:22:54 +0200
Subject: [LinuxBIOS] [PATCH] Call for help: superiotool
In-Reply-To: <20071005163801.5ef1c1ba.rasmus@wiman.org>
References: <20070923111315.GC12926@greenwood>
	<20071002152938.084fdaef.rasmus@wiman.org>
	<20071004022202.GA30344@greenwood>
	<20071005153243.aaa117a3.rasmus@wiman.org>
	<20071005163801.5ef1c1ba.rasmus@wiman.org>
Message-ID: <20071005172254.6b63f88b.rasmus@wiman.org>

Rasmus Wiman <rasmus at wiman.org> wrote:

> Rediffed against r2825, my patch was against r2823.

Oh, I forgot, you might want this too. Mainboard is still the MSI K7T266
PRO2 (MS-6380 v2.0)

su -c './superiotool -d'
Password: 
Found Winbond W83627HF/F/HG/G (id=0x52, rev=0x17) at 0x2e
Register dump:
idx 02 07 20 21 22 23 24 25 26 28 29 2a 2b 2c 2e 2f 
val ff 0b 52 17 ff fe c4 00 00 00 70 7c 10 ff 00 ff 
def 00 NA 52 NA ff 00 MM 00 00 00 00 7c c0 00 00 00 
LDN 0x00 (Floppy)
idx 30 60 61 70 74 f0 f1 f2 f4 f5 
val 01 03 f0 06 02 0e 00 ff 00 00 
def 01 03 f0 06 02 0e 00 ff 00 00 
LDN 0x01 (Parallel port)
idx 30 60 61 70 74 f0 
val 01 03 78 07 03 3a 
def 01 03 78 07 04 3f 
LDN 0x02 (COM1)
idx 30 60 61 70 f0 
val 01 03 f8 04 00 
def 01 03 f8 04 00 
LDN 0x03 (COM2)
idx 30 60 61 70 f0 f1 
val 01 02 f8 03 00 44 
def 01 02 f8 03 00 00 
LDN 0x05 (Keyboard)
idx 30 60 61 62 63 70 72 f0 
val 01 00 60 00 64 01 0c 80 
def 01 00 60 00 64 01 0c 80 
LDN 0x06 (Consumer IR)
idx 30 60 61 70 
val 00 00 00 00 
def 00 00 00 00 
LDN 0x07 (Game port, MIDI port, GPIO 1)
idx 30 60 61 62 63 70 f0 f1 f2 
val 03 02 00 00 00 00 ff 00 00 
def 00 02 01 03 30 09 ff 00 00 
LDN 0x08 (GPIO 2)
idx 30 f0 f1 f2 f3 f5 f6 f6 f7 
val 01 ef 00 10 00 00 00 00 00 
def 00 ff 00 00 00 00 00 00 00 
LDN 0x09 (GPIO 3)
idx 30 f0 f1 f2 f3 
val 01 e3 00 00 00 
def 00 ff 00 00 00 
LDN 0x0a (ACPI)
idx 30 70 e0 e1 e2 e3 e4 e5 e6 e7 f0 f1 f3 f4 f6 f7 f9 fe ff 
val 01 00 00 00 00 00 00 00 00 00 00 af 3c 04 00 00 05 00 00 
def 00 00 00 00 NA NA 00 00 00 00 00 00 00 00 00 00 00 00 00 
LDN 0x0b (Hardware monitor)
idx 30 60 61 70 f0 
val 01 02 90 00 01 
def 00 00 00 00 00

-- 

/Rasmus Wiman

Geek for hire



From uwe at hermann-uwe.de  Fri Oct  5 17:36:23 2007
From: uwe at hermann-uwe.de (Uwe Hermann)
Date: Fri, 5 Oct 2007 17:36:23 +0200
Subject: [LinuxBIOS] [PATCH] Call for help: superiotool
In-Reply-To: <20071005153243.aaa117a3.rasmus@wiman.org>
References: <20070923111315.GC12926@greenwood>
	<20071002152938.084fdaef.rasmus@wiman.org>
	<20071004022202.GA30344@greenwood>
	<20071005153243.aaa117a3.rasmus@wiman.org>
Message-ID: <20071005153623.GD5376@greenwood>

On Fri, Oct 05, 2007 at 03:32:43PM +0200, Rasmus Wiman wrote:
> Uwe Hermann <uwe at hermann-uwe.de> wrote:
> 
> > If you want to, feel free to grab the datasheet and add dump support.
> > Nothing complex, just a bit time-consuming...
> 
> Not so time-consuming for an unemployed guy like me. A few questions,
> though. I am not sure how I am supposed to use the constants NANA, RSVD
> and MISC, as defined in superiotool.h. I marked the default for global

This is up for discussion, more or less. Here's how I handled it until now:

RSVD -- registers marked as reverved in the datasheet

NANA -- do default available / mentioned in the datasheet

MISC -- random other values which cannot be expressed in numbers
        (e.g. "Bits 0 and 1 depend on the state of xyz, rest is 0"; in this
         case the default could be 0x03 or 0x00, we don't know. Thus MISC.)


> CR 07 and 21 as NANA, but 07 is logical device number and msd of 21 is

CR 07 is debatable anyway. There's no real value in listing it at all,
IMO. Maybe we should just drop it from all listings? Comments?

Revision IDs (which can change from chip to chip) should be NANA, at
least that's how I handle them usually.


> supposedly always 1 and lsd is chip revision id, on my HF it is 7. For
> 24 the datasheet says "Default 0b1s000s0s", a notation I'm unfamiliar

Good candidate for MISC, yes.


> with, so I set the default to MISC. This is very likely the wrong way
> to do it. Also, a few registers are specified as "reserved" or
> "Test:Reserver for winbond", but they provide a default, so I entered
> that default.

Hm, neither solution is good for this case, IMO. But we have to choose
one of them. I don't care which. Opinions?


> Also, I only grabbed the W83627HF/F datasheet, I think there was a HG/G
> sheet available too.

Yes. But its unlikely that they're (very) different if they're
documented in the same datasheet. I'll check later.

I was about to commit, but noticed that you forgot to add a
Signed-off-by line, see 
http://linuxbios.org/index.php/Development_Guidelines#Sign-off_Procedure
Please repost with a Signed-off-by.

No need to rediff btw, we can adapt the patch to (smaller) changes
right before committing.


Uwe.
-- 
http://www.hermann-uwe.de  | http://www.holsham-traders.de
http://www.crazy-hacks.org | http://www.unmaintained-free-software.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20071005/67f130ec/attachment.sig>

From info at coresystems.de  Fri Oct  5 17:59:47 2007
From: info at coresystems.de (LinuxBIOS information)
Date: Fri, 05 Oct 2007 17:59:47 +0200
Subject: [LinuxBIOS] r2826 build service
Message-ID: <E1Idpad-0002jT-3S@khepri.openbios.org>

Dear LinuxBIOS readers!

This is the automated build check service of LinuxBIOS.

The developer "uwe" checked in revision 2826 to
the LinuxBIOS source repository and caused the following 
changes:

Change Log:
Add dump support for the SMSC LPC47M10x (trivial).

Signed-off-by: Uwe Hermann <uwe at hermann-uwe.de>
Acked-by: Uwe Hermann <uwe at hermann-uwe.de>



Build Log:
Compilation of arima:hdama is still broken
See the error log at http://qa.linuxbios.org/log_buildbrd.php?revision=2826&device=hdama&vendor=arima
Compilation of ibm:e325 is still broken
See the error log at http://qa.linuxbios.org/log_buildbrd.php?revision=2826&device=e325&vendor=ibm
Compilation of ibm:e326 is still broken
See the error log at http://qa.linuxbios.org/log_buildbrd.php?revision=2826&device=e326&vendor=ibm
Compilation of iei:juki-511p is still broken
See the error log at http://qa.linuxbios.org/log_buildbrd.php?revision=2826&device=juki-511p&vendor=iei
Compilation of iwill:dk8s2 is still broken
See the error log at http://qa.linuxbios.org/log_buildbrd.php?revision=2826&device=dk8s2&vendor=iwill
Compilation of iwill:dk8x is still broken
See the error log at http://qa.linuxbios.org/log_buildbrd.php?revision=2826&device=dk8x&vendor=iwill
Compilation of newisys:khepri is still broken
See the error log at http://qa.linuxbios.org/log_buildbrd.php?revision=2826&device=khepri&vendor=newisys


If something broke during this checkin please be a pain 
in uwe's neck until the issue is fixed.

If this issue is not fixed within 24h the revision should 
be backed out.

   Best regards,
     LinuxBIOS automatic build system





From marc.jones at amd.com  Fri Oct  5 18:10:27 2007
From: marc.jones at amd.com (Marc Jones)
Date: Fri, 05 Oct 2007 10:10:27 -0600
Subject: [LinuxBIOS] Timer frequencies
In-Reply-To: <000801c80760$cd451290$4c23040a@chimp>
References: <000801c80760$cd451290$4c23040a@chimp>
Message-ID: <470661F3.9060100@amd.com>



Myles Watson wrote:
> I got Bochs to fail the same way the hardware (my Tyan s2892) fails when 
> I turned down the timer tick interrupt frequency.  I?m having trouble 
> finding the place where the timer gets set up.  (Grepping for 
> time,rtc,timer,hz, etc.)
> 
>  
> 
> Can someone tell me where I can make the interrupts come at 100 Hz in 
> LinuxBIOS?
> 
>  
> 
> Thanks,
> 
> Myles
> 


I believe that you are looking for calibrate_tsc() in 
cpu\x86\tsc\delay_tsc.c. That only sets up channel2. No reason you 
couldn't make changes in your mainboard but I'm not sure the setting 
will stick. I would expect the linux kernel reprogram the PIT (maybe not 
if it is using ACPI timer or HPET)?

Marc



-- 
Marc Jones
Senior Firmware Engineer
(970) 226-9684 Office
mailto:Marc.Jones at amd.com
http://www.amd.com/embeddedprocessors





From marc.jones at amd.com  Fri Oct  5 18:16:15 2007
From: marc.jones at amd.com (Marc Jones)
Date: Fri, 05 Oct 2007 10:16:15 -0600
Subject: [LinuxBIOS] flashrom support for AMD Geode CS5536
In-Reply-To: <47028804.4020502@mit.edu>
References: <47026FBB.1080809@mit.edu>
	<13426df10710020938x276d2c3ewf797f82d035d1bd7@mail.gmail.com>
	<47028730.70305@mit.edu> <47028804.4020502@mit.edu>
Message-ID: <4706634F.9010609@amd.com>



Lane Brooks wrote:
> Here it is again with the patch actually attached.
> 
> Lane Brooks wrote:
>> Here is the patch again with an updated comment regarding SMP and a 
>> signed-off-by line.
>>
>> Signed-off-by: Lane Brooks <lbrooks at mit.edu>
>>
>> ron minnich wrote:
>>> On 10/2/07, Lane Brooks <lbrooks at mit.edu> wrote:
>>>> Attached is a patch that enables AMD Geode CS5536 chipset support.  I
>>>> have tested it successfully on a MSM800 board from digital logic.  It
>>>> does, however, have a few issues that I would like some feedback on.
>>>>
>>>> In my discussions with Marc Jones, Geode systems write protect the BIOS
>>>> via RCONFs (cache settings similar to MTRRs). Unlocking requires
>>>> changing MSR 0x1808 top byte to 0x22. Reading and writing to the msr,
>>>> however, requires instrucitons rdmsr/wrmsr, which are ring0 privileged
>>>> instructions so only the kernel can do the read/write.  So my patch 
>>>> uses
>>>> the msr kernel module to access these instructions from user space 
>>>> using
>>>> the /dev/cpu/0/msr device.
>>>>
>>>> My questions are:
>>>> - I do not think this is portable beyond linux.  Is that an issue?
>>> it's not, but it is not really an issue at present.
>>>> - My code assumes the msr kernel module is already loaded.  Is there a
>>>> way to force a kernel module to load from the C code?  My code does die
>>>> gracefully with a message reminding them to load the kernel module if
>>>> things fail.
>>> it is possible I think to have udev help with this, but I am not sure.
>>> Graceful failure is certainly a good start.
>>>
>>>> - It seems like there should be a way to revert the msr back after
>>>> flashing is completed to put the bios back in write protect mode.  Is
>>>> there a cleanup mechanism available?  Something like disable_flash...
>>> I thought that was in the structure of flashrom. Now that I look, it
>>> seems like we lost it!
>>> I propose this at the end of flashrom:
>>> board_flash_disable(lb_vendor, lb_part);
>>> chipset_flash_disable(chipset);
>>>
>>> but we'll need to change some things to make this all work. We need a
>>> penable struct * to use for the disable; no point in searching each
>>> time we touch a chip. or not?
>>>
>>> one comment on your patch: you use /dev/cpu/0/msr. This is great for a
>>> single-cpu machine, and will always be fine on  geode. Lots of times,
>>> people use one piece of flashrom to write another. Imagine some future
>>> hacker, in a year or two, who has copied your code for some SMP
>>> system, not understanding why sometimes flashrom fails (i.e. they set
>>> CPU0 msr but end up running on cpu1). We had this very problem when we
>>> were getting graphics going (and, earlier, SMP going). I suggest a
>>> comment as to why the /dev/cpu/0/msr is always safe on geode, but
>>> future hackers beware on SMP. Or something like that.
>>>
>>> That's up to you, however :-)
>>>
>>> If you had a signed-off-by line, I would ack and commit for you :-)
>>>
>>> ron
>>>
>>> ron
>>

Did anyone ack and commit this last version?

Marc



-- 
Marc Jones
Senior Firmware Engineer
(970) 226-9684 Office
mailto:Marc.Jones at amd.com
http://www.amd.com/embeddedprocessors





From myles at pel.cs.byu.edu  Fri Oct  5 18:20:24 2007
From: myles at pel.cs.byu.edu (Myles Watson)
Date: Fri, 5 Oct 2007 10:20:24 -0600
Subject: [LinuxBIOS] Timer frequencies
In-Reply-To: <470661F3.9060100@amd.com>
References: <000801c80760$cd451290$4c23040a@chimp> <470661F3.9060100@amd.com>
Message-ID: <003001c8076b$a27a2c70$4c23040a@chimp>

> Subject: Re: [LinuxBIOS] Timer frequencies
> Myles Watson wrote:
> > I got Bochs to fail the same way the hardware (my Tyan s2892) fails when
> > I turned down the timer tick interrupt frequency.  I'm having trouble
> > finding the place where the timer gets set up.  (Grepping for
> > time,rtc,timer,hz, etc.)
> >
> > Can someone tell me where I can make the interrupts come at 100 Hz in
> > LinuxBIOS?
> >
> > Thanks,
> >
> > Myles
> >
> 
> 
> I believe that you are looking for calibrate_tsc() in
> cpu\x86\tsc\delay_tsc.c. That only sets up channel2. No reason you
> couldn't make changes in your mainboard but I'm not sure the setting
> will stick. I would expect the linux kernel reprogram the PIT (maybe not
> if it is using ACPI timer or HPET)?
> 

I'll check it out.  I'm actually booting Windows with ADLO, so I just need
to make it happy at boot time.

Thanks,
Myles

> Marc
> --
> Marc Jones
> Senior Firmware Engineer
> (970) 226-9684 Office
> mailto:Marc.Jones at amd.com
> http://www.amd.com/embeddedprocessors






From rasmus at wiman.org  Fri Oct  5 19:15:02 2007
From: rasmus at wiman.org (Rasmus Wiman)
Date: Fri, 5 Oct 2007 19:15:02 +0200
Subject: [LinuxBIOS] [PATCH] Call for help: superiotool
In-Reply-To: <20071005153623.GD5376@greenwood>
References: <20070923111315.GC12926@greenwood>
	<20071002152938.084fdaef.rasmus@wiman.org>
	<20071004022202.GA30344@greenwood>
	<20071005153243.aaa117a3.rasmus@wiman.org>
	<20071005153623.GD5376@greenwood>
Message-ID: <20071005191502.7e08a759.rasmus@wiman.org>

Uwe Hermann <uwe at hermann-uwe.de> wrote:

> I was about to commit, but noticed that you forgot to add a
> Signed-off-by line, see 
> http://linuxbios.org/index.php/Development_Guidelines#Sign-off_Procedure
> Please repost with a Signed-off-by.
> 
> No need to rediff btw, we can adapt the patch to (smaller) changes
> right before committing.

Ok, here comes the line. It's my first contribution to a free software
project, so it feels great anyway.

Signed-off-by: Rasmus Wiman <rasmus at wiman.org>

-- 

/Rasmus Wiman

Geek for hire
lp0: on fire
-------------- next part --------------
A non-text attachment was scrubbed...
Name: w83627HF_F_r2825.patch
Type: text/x-patch
Size: 1879 bytes
Desc: not available
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20071005/ea9e1cbb/attachment.patch>

From jordan.crouse at amd.com  Fri Oct  5 19:41:06 2007
From: jordan.crouse at amd.com (Jordan Crouse)
Date: Fri, 5 Oct 2007 11:41:06 -0600
Subject: [LinuxBIOS] flashrom support for AMD Geode CS5536
In-Reply-To: <20071005173559.GD32104@cosmic.amd.com>
References: <47026FBB.1080809@mit.edu>
	<13426df10710020938x276d2c3ewf797f82d035d1bd7@mail.gmail.com>
	<47028730.70305@mit.edu> <47028804.4020502@mit.edu>
	<4706634F.9010609@amd.com> <20071005173559.GD32104@cosmic.amd.com>
Message-ID: <20071005174106.GE32104@cosmic.amd.com>

Sigh - I hit 'r' instead of 'g'.  I blame mutt... :)

On 05/10/07 11:35 -0600, Jordan Crouse wrote:
> On 05/10/07 10:16 -0600, Marc Jones wrote:
> > 
> > 
> > Lane Brooks wrote:
> > > Here it is again with the patch actually attached.
> > > 
> > > Lane Brooks wrote:
> > >> Here is the patch again with an updated comment regarding SMP and a 
> > >> signed-off-by line.
> > >>
> > >> Signed-off-by: Lane Brooks <lbrooks at mit.edu>
> > >>
> > >> ron minnich wrote:
> > >>> On 10/2/07, Lane Brooks <lbrooks at mit.edu> wrote:
> > >>>> Attached is a patch that enables AMD Geode CS5536 chipset support.  I
> > >>>> have tested it successfully on a MSM800 board from digital logic.  It
> > >>>> does, however, have a few issues that I would like some feedback on.
> > >>>>
> > >>>> In my discussions with Marc Jones, Geode systems write protect the BIOS
> > >>>> via RCONFs (cache settings similar to MTRRs). Unlocking requires
> > >>>> changing MSR 0x1808 top byte to 0x22. Reading and writing to the msr,
> > >>>> however, requires instrucitons rdmsr/wrmsr, which are ring0 privileged
> > >>>> instructions so only the kernel can do the read/write.  So my patch 
> > >>>> uses
> > >>>> the msr kernel module to access these instructions from user space 
> > >>>> using
> > >>>> the /dev/cpu/0/msr device.
> > >>>>
> > >>>> My questions are:
> > >>>> - I do not think this is portable beyond linux.  Is that an issue?
> > >>> it's not, but it is not really an issue at present.
> > >>>> - My code assumes the msr kernel module is already loaded.  Is there a
> > >>>> way to force a kernel module to load from the C code?  My code does die
> > >>>> gracefully with a message reminding them to load the kernel module if
> > >>>> things fail.
> > >>> it is possible I think to have udev help with this, but I am not sure.
> > >>> Graceful failure is certainly a good start.
> > >>>
> > >>>> - It seems like there should be a way to revert the msr back after
> > >>>> flashing is completed to put the bios back in write protect mode.  Is
> > >>>> there a cleanup mechanism available?  Something like disable_flash...
> > >>> I thought that was in the structure of flashrom. Now that I look, it
> > >>> seems like we lost it!
> > >>> I propose this at the end of flashrom:
> > >>> board_flash_disable(lb_vendor, lb_part);
> > >>> chipset_flash_disable(chipset);
> > >>>
> > >>> but we'll need to change some things to make this all work. We need a
> > >>> penable struct * to use for the disable; no point in searching each
> > >>> time we touch a chip. or not?
> > >>>
> > >>> one comment on your patch: you use /dev/cpu/0/msr. This is great for a
> > >>> single-cpu machine, and will always be fine on  geode. Lots of times,
> > >>> people use one piece of flashrom to write another. Imagine some future
> > >>> hacker, in a year or two, who has copied your code for some SMP
> > >>> system, not understanding why sometimes flashrom fails (i.e. they set
> > >>> CPU0 msr but end up running on cpu1). We had this very problem when we
> > >>> were getting graphics going (and, earlier, SMP going). I suggest a
> > >>> comment as to why the /dev/cpu/0/msr is always safe on geode, but
> > >>> future hackers beware on SMP. Or something like that.
> > >>>
> > >>> That's up to you, however :-)
> > >>>
> > >>> If you had a signed-off-by line, I would ack and commit for you :-)
> > >>>
> > >>> ron
> > >>>
> > >>> ron
> > >>
> > 
> > Did anyone ack and commit this last version?
> 
> I think ron Acked it, but I'll ack again.
> 
> Acked-by: Jordan Crouse <jordan.crouse at amd.com>
> 
> > Marc
> > 
> > 
> > 
> > -- 
> > Marc Jones
> > Senior Firmware Engineer
> > (970) 226-9684 Office
> > mailto:Marc.Jones at amd.com
> > http://www.amd.com/embeddedprocessors
> > 
> > 
> > 
> > -- 
> > linuxbios mailing list
> > linuxbios at linuxbios.org
> > http://www.linuxbios.org/mailman/listinfo/linuxbios
> > 
> > 
> 
> -- 
> Jordan Crouse
> Systems Software Development Engineer 
> Advanced Micro Devices, Inc.

-- 
Jordan Crouse
Systems Software Development Engineer 
Advanced Micro Devices, Inc.





From uwe at hermann-uwe.de  Fri Oct  5 19:46:28 2007
From: uwe at hermann-uwe.de (Uwe Hermann)
Date: Fri, 5 Oct 2007 19:46:28 +0200
Subject: [LinuxBIOS] [PATCH] superiotool: Make --version actually work
	correctly
Message-ID: <20071005174628.GA9851@greenwood>

When trying to describe this patch the words 'crazy' and 'wacko' come to
mind, but believe it or not, this actually works _and_ it seems to be
the only way to make --version use the svn revision correctly.

The current --version output only changes when superiotool.h is updated,
which is not very useful, of course. This patch fixes it, in that all
changes to *.c or *.h files bump the version number.

Note: You will not be able to easily test this before the commit. You'll
      get a segfault, as the $Rev$ instances will not be replaced until
      _after_ the commit. If you want you can manually change '$Rev$' to
      '$Rev: 2555 $' or so in all files (for testing)...

Uwe.
-- 
http://www.hermann-uwe.de  | http://www.holsham-traders.de
http://www.crazy-hacks.org | http://www.unmaintained-free-software.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: superiotool_svnversion.patch
Type: text/x-diff
Size: 5417 bytes
Desc: not available
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20071005/3bb584c4/attachment.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20071005/3bb584c4/attachment.sig>

From joe at smittys.pointclark.net  Fri Oct  5 19:47:33 2007
From: joe at smittys.pointclark.net (joe at smittys.pointclark.net)
Date: Fri, 05 Oct 2007 13:47:33 -0400
Subject: [LinuxBIOS] JEDEC Memory initialization
In-Reply-To: <20071004224557.vs2bwhv0g4c4cc0w@www.smittys.pointclark.net>
References: <46FF1CB2.60901@gmail.com>
	<20070930115720.mwni4u7go4wkk8wg@www.smittys.pointclark.net>
	<47000290.6020000@gmail.com>
	<20071001094827.loois4qr0g4ckw8o@www.smittys.pointclark.net>
	<13426df10710010950s379f8230y5b4ffec4da605f06@mail.gmail.com>
	<20071001165858.vlz66uxpusgk0gww@www.smittys.pointclark.net>
	<47017223.6010504@gmail.com>
	<20071003190457.a6hta1e4kk8w0wwc@www.smittys.pointclark.net>
	<4704630C.8060803@gmail.com>
	<20071004002639.o29oeiku4g84w4g8@www.smittys.pointclark.net>
	<20071004044448.GA27127@coresystems.de>
	<20071004130627.izaryawis080sckk@www.smittys.pointclark.net>
	<20071004224557.vs2bwhv0g4c4cc0w@www.smittys.pointclark.net>
Message-ID: <20071005134733.lxsm4krnsgsocwss@www.smittys.pointclark.net>

Does anyone know the JEDEC document number that talks about memory  
initialization??

Thanks - Joe



From uwe at hermann-uwe.de  Fri Oct  5 19:50:35 2007
From: uwe at hermann-uwe.de (Uwe Hermann)
Date: Fri, 5 Oct 2007 19:50:35 +0200
Subject: [LinuxBIOS] svn tricks [was:r2814 - trunk/util/superiotool]
In-Reply-To: <20071001204910.GC9669@greenwood>
References: <20070929172443.16584.qmail@stuge.se>
	<20071001204910.GC9669@greenwood>
Message-ID: <20071005175035.GA9912@greenwood>

On Mon, Oct 01, 2007 at 10:49:10PM +0200, Uwe Hermann wrote:
> On Sat, Sep 29, 2007 at 07:24:43PM +0200, Peter Stuge wrote:
> > > -#define SUPERIOTOOL_VERSION "0.1"
> > > +#define SUPERIOTOOL_VERSION "r$Rev$"
> > 
> > How do I work with this? $Rev$ for superiotool.h won't be increased
> > automatically when I make changes to another file.
> 
> It will be increased with every commit, no matter which files change.
> Contrary to CVS, svn has a global revision number (not per-file
> revisions), so it'll be updated whenever you commit something (or
> someone else committed something and you do an 'svn up').

Scrap that, I was wrong.

The svn revision is indeed repository-wide (not per-file), _but_ the
stuff which replaces $Rev$ is actually the last commit for this file
(and not the repository-wide revision as I thought).

There's doesn't seem to be a keyword which is replaced with what we
want, but there's an ugly hack we can use to make it still work in this
case. See my patch in another mail.


Uwe.
-- 
http://www.hermann-uwe.de  | http://www.holsham-traders.de
http://www.crazy-hacks.org | http://www.unmaintained-free-software.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20071005/7cb887df/attachment.sig>

From tsylla at gmail.com  Fri Oct  5 19:59:44 2007
From: tsylla at gmail.com (Tom Sylla)
Date: Fri, 5 Oct 2007 13:59:44 -0400
Subject: [LinuxBIOS] JEDEC Memory initialization
In-Reply-To: <20071005134733.lxsm4krnsgsocwss@www.smittys.pointclark.net>
References: <46FF1CB2.60901@gmail.com>
	<20071001165858.vlz66uxpusgk0gww@www.smittys.pointclark.net>
	<47017223.6010504@gmail.com>
	<20071003190457.a6hta1e4kk8w0wwc@www.smittys.pointclark.net>
	<4704630C.8060803@gmail.com>
	<20071004002639.o29oeiku4g84w4g8@www.smittys.pointclark.net>
	<20071004044448.GA27127@coresystems.de>
	<20071004130627.izaryawis080sckk@www.smittys.pointclark.net>
	<20071004224557.vs2bwhv0g4c4cc0w@www.smittys.pointclark.net>
	<20071005134733.lxsm4krnsgsocwss@www.smittys.pointclark.net>
Message-ID: <57947bf80710051059g16c14392tae439224a3576bc0@mail.gmail.com>

JESD79-2C is for DDR2. I think it was JESD79-D for DDR

On 10/5/07, joe at smittys.pointclark.net <joe at smittys.pointclark.net> wrote:
> Does anyone know the JEDEC document number that talks about memory
> initialization??
>
> Thanks - Joe
>
> --
> linuxbios mailing list
> linuxbios at linuxbios.org
> http://www.linuxbios.org/mailman/listinfo/linuxbios
>



From yinghailu at gmail.com  Fri Oct  5 20:00:02 2007
From: yinghailu at gmail.com (yhlu)
Date: Fri, 5 Oct 2007 11:00:02 -0700
Subject: [LinuxBIOS] badly initialized (?) pci bridge on the M57SLI
	(with irq table and mptable)
In-Reply-To: <1191589215.4706355fce344@imp.free.fr>
References: <20070919212952.GA16399@localdomain>
	<2ea3fae10709200944o6ebbc89p74ddd188db4826e1@mail.gmail.com>
	<20070924213615.GB26022@greenwood>
	<2ea3fae10709241623l1b579378td2605ddad12be414@mail.gmail.com>
	<1190713007.46f8d6af1483e@imp.free.fr>
	<2ea3fae10709251226x4098fce2o56d61dbec6af9447@mail.gmail.com>
	<1190858035.46fb0d33df9c7@imp.free.fr>
	<1191468741.47045ec51281d@imp.free.fr>
	<20071004200602.GA12146@localdomain>
	<1191589215.4706355fce344@imp.free.fr>
Message-ID: <2ea3fae10710051100y68786279rff1019640cb0f8f1@mail.gmail.com>

On 10/5/07, echelon at free.fr <echelon at free.fr> wrote:
> Hi gentlemens,
>
>  Sorry for answering so late, but Im back after 3 sleepless nights so Im under
> continuous coffee perfusion simply to stay awake..
>  Firstly to answer to Yinghai, I didn't use dumpio (I don't know what is
> this..). I'm mostly a hardware guy (I come from the "embedded world") so my
> first reaction was to put an oscilloscope probe on the PCI bus..
>  So what have I found out?
>   - 1) with the initial LinuxBIOS code, it looks like some control signals of
> the PCI bus are not correctly driven when on tries to do configuration requests
> under Linux. More specifically, when a 32b read is done on the CONFIG_DATA port
> (0cfc) which should trigger a pci configuration register read, one can see that
> the signal C/BE[3]# (pin 26 - side B on a PCI slot) doesn't rise at a logical
> level of "1" as it should do. Indeed, the PCI bus spec says that the signals
> C/BE carry the PCI command code at the beginning of a PCI transaction (p.23 -
> chapter 3 "Bus Operation"). This code should be "1010" for a configuration read,
> so C/BE[3] should be '1'. In fact it doesn't .. (I have some pics with my
> oscilloscope measurement, if someone is interested by them plz let me know..)
>   - 2) after analising a little bit the code of the mcp55 southbridge in the LB
> source tree (especially the mcp55_early_setup_car.c file), I realised the the
> mcp55 southbridge has some kind of "IO multiplexer" unit (like some modern
> processors in
> the embedded world) which enables the configuration of the mcp55 pins either as
> GPIOs, either as "nominal" functions (PCI control signals for example). So, I
> asked my self if the GPIO configuration was not fitted for the m57sli board..
>   - 3) Btw I figured out that registers of the "IO control unit" of mcp55 can be
> mapped into the IO space by writting into the SYSCTRL_REG of the 00:01.1 pci
> device integrated into the SB. Indeed by using this value as a base (under
> Linux, this register holds the value 0x1400) one can access the GPIO registers
> of MCP55 (beginning @ the 0xc0 offset? maybe..) These are 8 bit registers
> apparently..

that is what i called dumpio

you need to mcp55 NDA to read gpio info, also some schematic have
table about what gpio should be set. ===> good HW designer put that to
make  BIOS engineer life easier.

YH



From yinghailu at gmail.com  Fri Oct  5 20:04:29 2007
From: yinghailu at gmail.com (yhlu)
Date: Fri, 5 Oct 2007 11:04:29 -0700
Subject: [LinuxBIOS] Tyan Thunder n3600R (S2912) support status?
In-Reply-To: <4705EAC4.5030302@ornia.hampshire.edu>
References: <4705EAC4.5030302@ornia.hampshire.edu>
Message-ID: <2ea3fae10710051104i41d0d010r2462f918c742b501@mail.gmail.com>

On 10/5/07, niko <niko at ornia.hampshire.edu> wrote:
> Hello there,
>
> I'm in the midst of an upgrade for my server, but I want the entire
> thing to run 100% Free Software, including LinuxBIOS.  The Tyan S2912
> seems to be a perfect match feature/specifications wise for what I am
> searching for.  I need a dual Socket F board with built in SAS and SATA2
> with RAID-5 support on the latter, and ideally two gigabit NICs to
> boot.  This Tyan board largely fits this description more than any other
> board on the LinuxBIOS supported motherboard compatibility list.
>
> The problem is that on the list it is still marked "WIP" with a yellow
> box instead of a green one.  What is the current status of LinuxBIOS
> support for this board?  Will it work at all or maybe partially?  What
> is/isn't working?  I need these certain features on my next motherboard,
> but I also need stability with LinuxBIOS on the board.  Is this too much
> to ask for a dual Socket F board such as this Tyan?
>
> I should also note that I'm not particularly attached to this board.  If
> LinuxBIOS works better with another dual Socket F board, I would love to
> know about it.  I just need the SAS and SATA2, really.
>
> I would sincerely love it if someone could help me understand the
> current state of LinuxBIOS support for this class of motherboards...
>
>
> ..here's hoping the compatibility list is out of date!

stefan, can you update that!

anything is missed?

I hope we can find another MB
split power plane ( for quad core support) + MCP55 + IO55 + HTX + SAS controller

before that s2912 is most updated one...

YH



From uwe at hermann-uwe.de  Fri Oct  5 20:47:30 2007
From: uwe at hermann-uwe.de (Uwe Hermann)
Date: Fri, 5 Oct 2007 20:47:30 +0200
Subject: [LinuxBIOS] Tyan Thunder n3600R (S2912) support status?
In-Reply-To: <2ea3fae10710051104i41d0d010r2462f918c742b501@mail.gmail.com>
References: <4705EAC4.5030302@ornia.hampshire.edu>
	<2ea3fae10710051104i41d0d010r2462f918c742b501@mail.gmail.com>
Message-ID: <20071005184730.GB9912@greenwood>

On Fri, Oct 05, 2007 at 11:04:29AM -0700, yhlu wrote:
> > ..here's hoping the compatibility list is out of date!
> 
> stefan, can you update that!
> 
> anything is missed?
> 
> I hope we can find another MB
> split power plane ( for quad core support) + MCP55 + IO55 + HTX + SAS controller
> 
> before that s2912 is most updated one...

Can you please give us a list of which hardware parts you tried on that
board (S2912) and which work or don't work?

Something like the Status table from
http://linuxbios.org/index.php/GIGABYTE_GA-M57SLI-S4_Build_Tutorial#Status

E.g. do the following parts all work and are they all tested?

CPU
RAM
IDE
IDE using CF-to-IDE adapter
SATA
USB
On-board ethernet
On-board audio
PCI add-on cards
PCI Express add-on cards
Floppy
Serial port (COM1)
Serial port (COM2)
Parallel port
PS/2 keyboard
PS/2 mouse
Mainboard sensors/fans
CPU frequency scaling / powersave modes
Flashrom

etc. etc.


Thanks, Uwe.
-- 
http://www.hermann-uwe.de  | http://www.holsham-traders.de
http://www.crazy-hacks.org | http://www.unmaintained-free-software.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20071005/34fd0500/attachment.sig>

From juergen127 at kreuzholzen.de  Fri Oct  5 21:29:54 2007
From: juergen127 at kreuzholzen.de (Juergen Beisert)
Date: Fri, 5 Oct 2007 21:29:54 +0200
Subject: [LinuxBIOS] VGA support for Geode GX1/CS5530
Message-ID: <200710052129.54369.juergen127@kreuzholzen.de>

Hi,

below you will find support for the Geode GX1/CS5530 VGA feature. Its able
to set up one of five screen resolutions (sorry no autodetection at runtime,
resolution is selected at buildtime) and displays a graphic in the right
bottom corner (splash screen).

Patch is against LinuxBIOSv2, revision of today.

Comments are welcome.

Juergen

Index: LinuxBIOSv2/src/southbridge/amd/cs5530/cs5530_vga.c
===================================================================
--- /dev/null
+++ LinuxBIOSv2/src/southbridge/amd/cs5530/cs5530_vga.c
@@ -0,0 +1,458 @@
+/*
+ * Copyright (C) 2007 Juergen Beisert <juergen at kreuzholzen.de>
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; version 2 of the License.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA, 02110-1301 USA
+ *
+ * Purpose:
+ * Activate the VGA feature in a Geode GX1 based system with one of five
+ * possible VESA modes: VGA, SVGA, XGA, 4:3 SXGA and 5:4 SXGA. Also it is
+ * prepared to display a splash screen.
+ */
+#include <arch/io.h>
+#include <device/device.h>
+#include <device/pci.h>
+#include <device/pci_ops.h>
+#include <device/pci_ids.h>
+#include <console/console.h>
+#include <cpu/amd/gx1def.h>
+#include <delay.h>
+
+#if CONFIG_GX1_VIDEO == 1
+/*
+ * Some register descriptions that are no listed in cpu/amd/gx1def.h
+ */
+#define CS5530_DOT_CLK_CONFIG	0x0024
+#define CS5530_DISPLAY_CONFIG	0x0004
+
+#define DC_FB_ST_OFFSET		0x8310	/* framebuffer start offset */
+#define DC_CB_ST_OFFSET		0x8314	/* compression start offset */
+#define DC_CURS_ST_OFFSET	0x8318	/* cursor start offset */
+#define DC_VID_ST_OFFSET	0x8320	/* video start offset */
+#define DC_LINE_DELTA		0x8324	/* fb and cb skip counts */
+#define DC_BUF_SIZE		0x8328	/* fb and cb line size */
+#define DC_H_TIMING_1		0x8330	/* horizontal timing... */
+#define DC_H_TIMING_2		0x8334
+#define DC_H_TIMING_3		0x8338
+#define DC_FP_H_TIMING		0x833C
+#define DC_V_TIMING_1		0x8340	/* vertical timing... */
+#define DC_V_TIMING_2		0x8344
+#define DC_V_TIMING_3		0x8348
+#define DC_FP_V_TIMING		0x834C
+#define DC_TIMING_CFG		0x8308
+#define DC_OUTPUT_CFG		0x830C
+
+/*
+ * what colour depth should be used as default (in bpp)
+ * Note: Currently no other value than 16 is supported
+ */
+#define COLOUR_DEPTH 16
+
+/*
+ * Support for a few basic video modes
+ * Note: all modes only for CRT. The flatpanel feature is
+ * not supported here (due to the lack of hardware to test)
+ */
+struct video_mode {
+	int pixel_clock;		/*<< pixel clock in Hz */
+	unsigned long pll_value;	/*<< pll register value for this clock */
+
+	int visible_pixel;
+	int hsync_start;
+	int hsync_end;
+	int line_length;
+
+	int visible_lines;
+	int vsync_start;
+	int vsync_end;
+	int picture_length;
+
+	int sync_pol;		/*<< 0: low, 1: high, bit 0 hsync, bit 1 vsync */
+};
+
+/*
+ * values for .sync_pol
+ */
+#define HSYNC_HIGH_POL 0
+#define HSYNC_LOW_POL 1
+#define VSYNC_HIGH_POL 0
+#define VSYNC_LOW_POL 2
+
+/* ModeLine "640x480" 31.5 640 664 704 832 480 489 491 520 -hsync -vsync */
+static const struct video_mode mode_640x480 = {
+	/*
+	 * 640x480 @ 72Hz hsync: 37.9kHz
+	 * VESA standard mode for classic 4:3 monitors
+	 */
+	.pixel_clock = 31500000,
+	.pll_value = 0x33915801,
+
+	.visible_pixel = 640,
+	.hsync_start = 664,
+	.hsync_end = 704,	/* 1.27 us sync length */
+	.line_length = 832,	/* 26.39us */
+
+	.visible_lines = 480,
+	.vsync_start = 489,
+	.vsync_end = 491,
+	.picture_length = 520, /* 13.89ms */
+
+	.sync_pol = HSYNC_LOW_POL | VSYNC_LOW_POL
+};
+
+/* ModeLine "800x600" 50.0 800 856 976 1040 600 637 643 666 +hsync +vsync */
+static const struct video_mode mode_800x600 = {
+	/*
+	 * 800x600 @ 72Hz hsync: 48.1kHz
+	 * VESA standard mode for classic 4:3 monitors
+	 */
+	.pixel_clock = 50000000,
+	.pll_value = 0x23088801,
+
+	.visible_pixel = 800,
+	.hsync_start = 856,
+	.hsync_end = 976,
+	.line_length = 1040, /* 20.8us */
+
+	.visible_lines = 600,
+	.vsync_start = 637,
+	.vsync_end = 643,
+	.picture_length = 666, /* 13.89ms */
+
+	.sync_pol = HSYNC_HIGH_POL | VSYNC_HIGH_POL
+};
+
+/* ModeLine "1024x768" 75.0 1024 1048 1184 1328 768 771 777 806 -hsync -vsync */
+static const struct video_mode mode_1024x768 = {
+	/*
+	 * 1024x768 @ 70Hz (VESA) hsync: 56.5kHz
+	 * Standard mode for classic 4:3 monitors
+	 */
+	.pixel_clock = 75000000,
+	.pll_value = 0x37E22801,
+
+	.visible_pixel = 1024,
+	.hsync_start = 1048,
+	.hsync_end = 1184,
+	.line_length = 1328,	/* 17.7us */
+
+	.visible_lines = 768,
+	.vsync_start = 771,
+	.vsync_end = 777,
+	.picture_length = 806,	/* 14.3us */
+
+	.sync_pol = HSYNC_LOW_POL | VSYNC_LOW_POL
+};
+
+/* ModeLine "1280x960" 108.0 1280 1376 1488 1800 960 961 964 1000 +hsync +vsync */
+static const struct video_mode mode_1280x960 = {
+	/*
+	 * 1280x960 @ 60Hz (VESA) hsync: 60.0kHz
+	 * Mode for classic 4:3 monitors
+	 */
+	.pixel_clock = 108000000,
+	.pll_value = 0x2710C805,
+
+	.visible_pixel = 1280,
+	.hsync_start = 1376,
+	.hsync_end = 1488,
+	.line_length = 1800,	/* 16.67us */
+
+	.visible_lines = 960,
+	.vsync_start = 961,
+	.vsync_end = 964,
+	.picture_length = 1000,	/* 16.67ms */
+
+	.sync_pol = HSYNC_HIGH_POL | VSYNC_HIGH_POL
+};
+
+/* ModeLine "1280x1024" 108.0 1280 1328 1440 1688 1024 1025 1028 1066 +hsync +vsync */
+static const struct video_mode mode_1280x1024 = {
+	/*
+	 * 1280x1024 @ 60Hz (VESA) hsync: 64.0kHz
+	 * Mode for modern 5:4 flat screens
+	 */
+	.pixel_clock = 108000000,
+	.pll_value = 0x2710C805,
+
+	.visible_pixel = 1280,
+	.hsync_start = 1328,
+	.hsync_end = 1440,
+	.line_length = 1688,	/* 15.6us */
+
+	.visible_lines = 1024,
+	.vsync_start = 1025,
+	.vsync_end = 1028,
+	.picture_length = 1066,
+
+	.sync_pol = HSYNC_HIGH_POL | VSYNC_HIGH_POL
+};
+
+/*
+ * a few supported common modes
+ */
+static const struct video_mode *modes[] = {
+	&mode_640x480,	/* CONFIG_GX1_VIDEOMODE = 0 */
+	&mode_800x600,	/* CONFIG_GX1_VIDEOMODE = 1 */
+	&mode_1024x768,	/* CONFIG_GX1_VIDEOMODE = 2 */
+	&mode_1280x960,	/* CONFIG_GX1_VIDEOMODE = 3 */
+	&mode_1280x1024	/* CONFIG_GX1_VIDEOMODE = 4 */
+};
+
+/* make a sanity check at buildtime */
+#if CONFIG_GX1_VIDEOMODE > 4
+# error Requested video mode is unknown!
+#endif
+
+/*
+ * Setup the pixel PLL in the companion chip
+ * base: register's base address
+ * pll_val: pll register value to be set
+ */
+static void cs5530_set_clock_frequency(void *io_base,unsigned long pll_val)
+{
+	unsigned long reg;
+
+	/* disable the PLL first, reset and power it down */
+	reg = readl(io_base+CS5530_DOT_CLK_CONFIG) & ~0x20;
+	reg |= 0x80000100;
+	writel(reg, io_base+CS5530_DOT_CLK_CONFIG);
+
+	/* write the new PLL setting */
+	reg |= (pll_val & ~0x80000920);
+	writel(reg, io_base+CS5530_DOT_CLK_CONFIG);
+
+	mdelay(1);	/* wait for control voltage to be 0V */
+
+	/* enable the PLL */
+	reg |= 0x00000800;
+	writel(reg, io_base+CS5530_DOT_CLK_CONFIG);
+
+	/* clear reset */
+	reg &= ~0x80000000;
+	writel(reg, io_base+CS5530_DOT_CLK_CONFIG);
+
+	/* clear bypass */
+	reg &= ~0x00000100;
+	writel(reg, io_base+CS5530_DOT_CLK_CONFIG);
+}
+
+/*
+ * Setup memory layout
+ * gx_base: GX register area
+ * mode: Data about the video mode to setup
+ *
+ * This routine assumes unlocked DC registers. Using compressed buffer
+ * is not supported! (makes more sense later, but not while booting)
+ */
+static void dc_setup_layout(void *gx_base,const struct video_mode *mode)
+{
+	unsigned long base = 0x00000000;
+
+	writel(base, gx_base + DC_FB_ST_OFFSET);
+
+	base += (COLOUR_DEPTH>>3) * mode->visible_pixel * mode->visible_lines;
+
+	writel(base, gx_base + DC_CB_ST_OFFSET);
+	writel(base, gx_base + DC_CURS_ST_OFFSET);
+	writel(base, gx_base + DC_VID_ST_OFFSET);
+	writel(((COLOUR_DEPTH>>3) * mode->visible_pixel) >> 2, gx_base + DC_LINE_DELTA);
+	writel(((COLOUR_DEPTH>>3) * mode->visible_pixel) >> 3, gx_base + DC_BUF_SIZE);
+}
+
+/*
+ * Setup the HSYNC/VSYNC, active video timing
+ * gx_base: GX register area
+ * mode: Data about the video mode to setup
+ *
+ * This routine assumes unlocked DC registers
+ *
+ * |<------------------------- htotal ----------------------------->|
+ * |<------------ hactive -------------->|                          |
+ * |                       hblankstart-->|                          |
+ * |                                                    hblankend-->|
+ * |                                hsyncstart-->|                  |
+ * |                                           hsyncend-->|         |
+ * |#####################################___________________________| RGB data
+ * |______________________________________________---------_________| HSYNC
+ *
+ * |<------------------------- vtotal ----------------------------->|
+ * |<------------ vactive -------------->|                          |
+ * |                       vblankstart-->|                          |
+ * |                                                    vblankend-->|
+ * |                                vsyncstart-->|                  |
+ * |                                           vsyncend-->|         |
+ * |#####################################___________________________| line data
+ * |______________________________________________---------_________| YSYNC
+ */
+static void dc_setup_timing(void *gx_base,const struct video_mode *mode)
+{
+	unsigned long hactive, hblankstart, hsyncstart, hsyncend, hblankend, htotal;
+	unsigned long vactive, vblankstart, vsyncstart, vsyncend, vblankend, vtotal;
+
+	hactive = mode->visible_pixel & 0x7FF;
+	hblankstart = hactive;
+	hsyncstart = mode->hsync_start & 0x7FF;
+	hsyncend =  mode->hsync_end & 0x7FF;
+	hblankend = mode->line_length & 0x7FF;
+	htotal = hblankend;
+
+	vactive = mode->visible_lines & 0x7FF;
+	vblankstart = vactive;
+	vsyncstart = mode->vsync_start & 0x7FF;
+	vsyncend =  mode->vsync_end & 0x7FF;
+	vblankend = mode->picture_length & 0x7FF;
+	vtotal = vblankend;
+
+	/* row description */
+	writel((hactive - 1) | ((htotal - 1) << 16), gx_base + DC_H_TIMING_1);
+	/* horizontal blank description */
+	writel((hblankstart - 1) | ((hblankend - 1) << 16), gx_base + DC_H_TIMING_2);
+	/* horizontal sync description */
+	writel((hsyncstart - 1) | ((hsyncend - 1) << 16), gx_base + DC_H_TIMING_3);
+	writel((hsyncstart - 1) | ((hsyncend - 1) << 16), gx_base + DC_FP_H_TIMING);
+
+	/* line description */
+	writel((vactive - 1) | ((vtotal - 1) << 16), gx_base + DC_V_TIMING_1);
+	/* vertical blank description */
+	writel((vblankstart - 1) | ((vblankend - 1) << 16), gx_base + DC_V_TIMING_2);
+	/* vertical sync description */
+	writel((vsyncstart - 1) | ((vsyncend - 1) << 16), gx_base + DC_V_TIMING_3);
+	writel((vsyncstart - 2) | ((vsyncend - 2) << 16), gx_base + DC_FP_V_TIMING);
+}
+
+/*
+ * Setup required internals to bring the mode up and running
+ * gx_base: GX register area
+ * mode: Data about the video mode to setup
+ */
+static void cs5530_activate_mode(void *gx_base, const struct video_mode *mode)
+{
+	writel(0x00000080, gx_base + DC_GENERAL_CFG);
+	mdelay(1);
+	dc_setup_layout(gx_base,mode);
+	dc_setup_timing(gx_base,mode);
+
+	writel(0x2000C581, gx_base + DC_GENERAL_CFG);
+	writel(0x0000002F, gx_base + DC_TIMING_CFG);
+	writel(0x00003004, gx_base + DC_OUTPUT_CFG);
+}
+
+/*
+ * Activate the current mode to be "visible" outside
+ * gx_base: GX register area
+ * mode: Data about the video mode to setup
+ */
+static void cs5530_activate_video(void *io_base, const struct video_mode *mode)
+{
+	u32 val;
+
+	val = mode->sync_pol;
+	val <<= 8;
+
+	writel(val | 0x0020002F, io_base + CS5530_DISPLAY_CONFIG);
+}
+
+/*
+ * This bitmap file must provide:
+ * int width: pixel count in one line
+ * int height: line count
+ * int colours: ount of used colour
+ * unsigned long colour_map[]: RGB 565 colours to be used
+ * unsigned char bitmap[]: index per pixel into colour_map[], width*height pixels
+ */
+#include "bitmap.c"
+
+/*
+ * show a boot splash screen in the right lower corner of the screen
+ * swidth: screen width in pixel
+ * sheight: screen height in lines
+ * pitch: line pitch in bytes
+ * base: screen base address
+ *
+ * This routine assumes we are using a 16 bit colour depth!
+ */
+static void show_boot_splash_16(u32 swidth,u32 sheight,u32 pitch,void *base)
+{
+	int word_count,i;
+	unsigned short *adr;
+	u32 xstart,ystart,x,y;
+	/*
+	 * fill the screen with the colour of the
+	 * left top pixel in the graphic
+	 */
+	word_count = pitch*sheight;
+	printk_debug("Clear Screen at %p, %d words\n",base,word_count);
+	adr = (unsigned short *) base;
+	for (i=0; i < word_count; i++, adr++)
+		*adr = colour_map[bitmap[0]];
+	printk_debug("Ready\n");
+
+	/*
+	 * paint the splash
+	 */
+	xstart=swidth-width;
+	ystart=sheight-height;
+	printk_debug("Start at %u,%u\n",xstart,ystart);
+	for (y=0;y<height;y++) {
+		adr=(unsigned short*)(base + pitch*(y+ystart)+2*xstart);
+		for (x=0;x<width;x++) {
+			*adr=(unsigned short)colour_map[(int)bitmap[x+y*width]];
+			adr++;
+		}
+	}
+}
+
+/*
+ * management part
+ */
+static void cs5530_vga_init(device_t dev)
+{
+	const struct video_mode *mode;
+	void *io_base, *gx_base;
+
+	io_base = (void*)pci_read_config32(dev,0x10);
+	gx_base = (void*)GX_BASE;
+	mode = modes[CONFIG_GX1_VIDEOMODE];
+
+	printk_debug("Setting up video mode %dx%d with %d Hz clock\n",
+		mode->visible_pixel, mode->visible_lines, mode->pixel_clock);
+
+	cs5530_set_clock_frequency(io_base,mode->pll_value);
+
+	writel(DC_UNLOCK_MAGIC, gx_base + DC_UNLOCK);
+
+	show_boot_splash_16(mode->visible_pixel, mode->visible_lines,
+		mode->visible_pixel*(COLOUR_DEPTH>>3),(void*)(GX_BASE+0x800000));
+
+	cs5530_activate_mode(gx_base,mode);
+
+	cs5530_activate_video(io_base, mode);
+	writel(0x00000000, gx_base + DC_UNLOCK);
+}
+
+static struct device_operations vga_ops = {
+	.read_resources   = pci_dev_read_resources,
+	.set_resources    = pci_dev_set_resources,
+	.enable_resources = pci_dev_enable_resources,
+	.init             = cs5530_vga_init,
+	.enable           = NULL /* not required */
+};
+
+static struct pci_driver vga_pci_driver __pci_driver = {
+	.ops 	= &vga_ops,
+	.vendor = PCI_VENDOR_ID_CYRIX,
+	.device = PCI_DEVICE_ID_CYRIX_5530_VIDEO
+};
+
+#endif /* #if CONFIG_GX1_VIDEO == 1 */
Index: LinuxBIOSv2/src/southbridge/amd/cs5530/Config.lb
===================================================================
--- LinuxBIOSv2.orig/src/southbridge/amd/cs5530/Config.lb
+++ LinuxBIOSv2/src/southbridge/amd/cs5530/Config.lb
@@ -22,3 +22,4 @@ config chip.h
 driver cs5530.o
 driver cs5530_isa.o
 driver cs5530_ide.o
+driver cs5530_vga.o
Index: LinuxBIOSv2/src/config/Options.lb
===================================================================
--- LinuxBIOSv2.orig/src/config/Options.lb
+++ LinuxBIOSv2/src/config/Options.lb
@@ -1016,7 +1016,23 @@ define CONFIG_VIDEO_MB
         comment "Integrated graphics with UMA has dynamic setup"
 end
 
+define CONFIG_GX1_VIDEO
+	default 0
+	export used
+	comment "Build in GX1's graphic support"
+end
 
+define CONFIG_GX1_VIDEOMODE
+	default none
+	export used
+	comment "Define video mode after reset"
+# could be
+# 0 for 640x480
+# 1 for 800x600
+# 2 for 1024x768
+# 3 for 1280x960
+# 4 for 1280x1024
+end
 
 ###############################################
 # Board specific options
Index: LinuxBIOSv2/src/southbridge/amd/cs5530/bitmap.c
===================================================================
--- /dev/null
+++ LinuxBIOSv2/src/southbridge/amd/cs5530/bitmap.c
@@ -0,0 +1,304 @@
+/* do not edit
+This is an image of size 51 x 60 with 234 colours */
+static const int width=51;
+static const int height=60;
+static const int colours=234;
+static const unsigned long colour_map[234] = {
+0x00000000, /* 0 */
+0x00000001, /* 1 */
+0x00000020, /* 2 */
+0x00000021, /* 3 */
+0x00000040, /* 4 */
+0x00000800, /* 5 */
+0x00000821, /* 6 */
+0x00000840, /* 7 */
+0x00000841, /* 8 */
+0x00000861, /* 9 */
+0x00001040, /* 10 */
+0x00001081, /* 11 */
+0x00001082, /* 12 */
+0x00001083, /* 13 */
+0x000010A2, /* 14 */
+0x00001881, /* 15 */
+0x000018C3, /* 16 */
+0x000018E3, /* 17 */
+0x000020A0, /* 18 */
+0x000020E4, /* 19 */
+0x00002103, /* 20 */
+0x00002104, /* 21 */
+0x00002124, /* 22 */
+0x00002921, /* 23 */
+0x00002945, /* 24 */
+0x00002946, /* 25 */
+0x00002965, /* 26 */
+0x00002966, /* 27 */
+0x00003186, /* 28 */
+0x000031A6, /* 29 */
+0x00003942, /* 30 */
+0x00003982, /* 31 */
+0x000039A7, /* 32 */
+0x000039C7, /* 33 */
+0x000039E7, /* 34 */
+0x000039E8, /* 35 */
+0x000041A2, /* 36 */
+0x000041C2, /* 37 */
+0x000041E7, /* 38 */
+0x00004207, /* 39 */
+0x00004208, /* 40 */
+0x00004228, /* 41 */
+0x00004229, /* 42 */
+0x000049E3, /* 43 */
+0x000049E5, /* 44 */
+0x00004A46, /* 45 */
+0x00004A47, /* 46 */
+0x00004A48, /* 47 */
+0x00004A49, /* 48 */
+0x00004A69, /* 49 */
+0x00004A8A, /* 50 */
+0x00005228, /* 51 */
+0x00005247, /* 52 */
+0x00005287, /* 53 */
+0x0000528A, /* 54 */
+0x000052AA, /* 55 */
+0x00005A21, /* 56 */
+0x00005A43, /* 57 */
+0x00005A63, /* 58 */
+0x00005AA9, /* 59 */
+0x00005AAA, /* 60 */
+0x00005ACA, /* 61 */
+0x00005ACB, /* 62 */
+0x00005AEB, /* 63 */
+0x00006222, /* 64 */
+0x00006261, /* 65 */
+0x000062A8, /* 66 */
+0x000062C7, /* 67 */
+0x000062E8, /* 68 */
+0x000062EB, /* 69 */
+0x000062EC, /* 70 */
+0x0000630B, /* 71 */
+0x0000630C, /* 72 */
+0x0000632C, /* 73 */
+0x00006A41, /* 74 */
+0x00006B05, /* 75 */
+0x00006B28, /* 76 */
+0x00006B29, /* 77 */
+0x00006B2D, /* 78 */
+0x00006B4D, /* 79 */
+0x00006B6D, /* 80 */
+0x00006B6E, /* 81 */
+0x00006B8D, /* 82 */
+0x000072A2, /* 83 */
+0x000072E2, /* 84 */
+0x000072E5, /* 85 */
+0x00007306, /* 86 */
+0x00007329, /* 87 */
+0x0000738E, /* 88 */
+0x000073AE, /* 89 */
+0x000073AF, /* 90 */
+0x000073CF, /* 91 */
+0x00007B28, /* 92 */
+0x00007B44, /* 93 */
+0x00007B48, /* 94 */
+0x00007B67, /* 95 */
+0x00007B69, /* 96 */
+0x00007BCE, /* 97 */
+0x00007BCF, /* 98 */
+0x00007BEF, /* 99 */
+0x00008323, /* 100 */
+0x00008345, /* 101 */
+0x000083AA, /* 102 */
+0x00008410, /* 103 */
+0x00008430, /* 104 */
+0x00008B02, /* 105 */
+0x00008B63, /* 106 */
+0x00008B83, /* 107 */
+0x00008B84, /* 108 */
+0x00008BA6, /* 109 */
+0x00008BC7, /* 110 */
+0x00008BEA, /* 111 */
+0x00008BEE, /* 112 */
+0x00008C51, /* 113 */
+0x00008C71, /* 114 */
+0x00009362, /* 115 */
+0x00009363, /* 116 */
+0x00009383, /* 117 */
+0x000093C5, /* 118 */
+0x000093C7, /* 119 */
+0x00009405, /* 120 */
+0x00009492, /* 121 */
+0x00009493, /* 122 */
+0x000094B2, /* 123 */
+0x00009B82, /* 124 */
+0x00009BC3, /* 125 */
+0x00009C2D, /* 126 */
+0x00009CB3, /* 127 */
+0x00009CD3, /* 128 */
+0x00009CF3, /* 129 */
+0x00009CF4, /* 130 */
+0x00009D14, /* 131 */
+0x0000A401, /* 132 */
+0x0000A403, /* 133 */
+0x0000A423, /* 134 */
+0x0000A44C, /* 135 */
+0x0000A489, /* 136 */
+0x0000A4F1, /* 137 */
+0x0000A514, /* 138 */
+0x0000A533, /* 139 */
+0x0000A534, /* 140 */
+0x0000ABE1, /* 141 */
+0x0000AC22, /* 142 */
+0x0000AC24, /* 143 */
+0x0000AC42, /* 144 */
+0x0000AC44, /* 145 */
+0x0000AC48, /* 146 */
+0x0000AC69, /* 147 */
+0x0000AC8A, /* 148 */
+0x0000ACEE, /* 149 */
+0x0000AD0A, /* 150 */
+0x0000AD2E, /* 151 */
+0x0000AD55, /* 152 */
+0x0000AD75, /* 153 */
+0x0000AD76, /* 154 */
+0x0000B423, /* 155 */
+0x0000B441, /* 156 */
+0x0000B444, /* 157 */
+0x0000B464, /* 158 */
+0x0000B484, /* 159 */
+0x0000B4A3, /* 160 */
+0x0000B4C4, /* 161 */
+0x0000B533, /* 162 */
+0x0000B596, /* 163 */
+0x0000B5B6, /* 164 */
+0x0000BC65, /* 165 */
+0x0000BC83, /* 166 */
+0x0000BC84, /* 167 */
+0x0000BCC9, /* 168 */
+0x0000BD03, /* 169 */
+0x0000BD2A, /* 170 */
+0x0000BD54, /* 171 */
+0x0000BD97, /* 172 */
+0x0000BDB5, /* 173 */
+0x0000BDD7, /* 174 */
+0x0000BDD8, /* 175 */
+0x0000BDF7, /* 176 */
+0x0000BE19, /* 177 */
+0x0000C4A2, /* 178 */
+0x0000C4C2, /* 179 */
+0x0000C4C3, /* 180 */
+0x0000C5CE, /* 181 */
+0x0000C5F9, /* 182 */
+0x0000C618, /* 183 */
+0x0000C61A, /* 184 */
+0x0000C638, /* 185 */
+0x0000CCE2, /* 186 */
+0x0000CD03, /* 187 */
+0x0000CD43, /* 188 */
+0x0000CD61, /* 189 */
+0x0000CD88, /* 190 */
+0x0000CE39, /* 191 */
+0x0000CE58, /* 192 */
+0x0000CE59, /* 193 */
+0x0000CE79, /* 194 */
+0x0000CE7A, /* 195 */
+0x0000CE7B, /* 196 */
+0x0000CE9A, /* 197 */
+0x0000D502, /* 198 */
+0x0000D522, /* 199 */
+0x0000D62C, /* 200 */
+0x0000D69A, /* 201 */
+0x0000D69B, /* 202 */
+0x0000D6BA, /* 203 */
+0x0000DD23, /* 204 */
+0x0000DD41, /* 205 */
+0x0000DD81, /* 206 */
+0x0000DDA1, /* 207 */
+0x0000DDA4, /* 208 */
+0x0000DE9C, /* 209 */
+0x0000DEDB, /* 210 */
+0x0000DEFB, /* 211 */
+0x0000DEFD, /* 212 */
+0x0000E5A2, /* 213 */
+0x0000E71C, /* 214 */
+0x0000E73C, /* 215 */
+0x0000EDC1, /* 216 */
+0x0000EF3E, /* 217 */
+0x0000EF5D, /* 218 */
+0x0000EF7D, /* 219 */
+0x0000EF7E, /* 220 */
+0x0000EF7F, /* 221 */
+0x0000F79D, /* 222 */
+0x0000F79E, /* 223 */
+0x0000F7BE, /* 224 */
+0x0000F7BF, /* 225 */
+0x0000F7DE, /* 226 */
+0x0000FFB8, /* 227 */
+0x0000FFBF, /* 228 */
+0x0000FFDD, /* 229 */
+0x0000FFDE, /* 230 */
+0x0000FFDF, /* 231 */
+0x0000FFFB, /* 232 */
+0x0000FFFF, /* 233 */
+};
+
+static const unsigned char bitmap[3060] = {
+0xE9,0xE9,0xE9,0xE9,0xE9,0xE9,0xE9,0xE9,0xE7,0xA4,0xD3,0xE9,0xDF,0xDF,0x8C,0xE7,0xE0,0xDF,0xB0,0xDB,0xE7,0xE0,0xE0,0xC2,0xE7,0xE7,0xE0,0xD3,0xE9,0xE9,0xE0,0xDF,0xDF,0xE7,0xE7,0xD6,0xE9,0xE9,0xE9,0xE9,0xE9,0xE9,0xE9,0xE9,0xE9,0xE9,0xE9,0xE9,0xE9,0xE9,0xE9,
+0xE9,0xE9,0xE9,0xE9,0xE0,0xDB,0xDA,0xDF,0xE9,0x67,0xA3,0xD7,0xDA,0xE9,0x71,0xD7,0xA3,0xE9,0xD6,0xD7,0xD2,0xD6,0xE9,0xC1,0xDF,0x68,0xE9,0xDA,0xE0,0x99,0xAE,0xE9,0xD7,0xB9,0xE9,0xA3,0xDF,0xE0,0xE7,0xE7,0xE7,0xE9,0xE9,0xE9,0xE9,0xE9,0xE9,0xE9,0xE9,0xE9,0xE9,
+0xE9,0xE9,0xE9,0xD6,0x71,0x67,0x63,0x72,0xE9,0x31,0x4F,0x58,0x99,0xD6,0x1D,0x67,0x50,0xB7,0x67,0x36,0x4F,0x99,0xD6,0x28,0x49,0x3F,0xDB,0x71,0x48,0x48,0x80,0xDB,0x37,0x48,0xE9,0x8C,0x58,0x68,0xDA,0xDB,0xDF,0xE0,0xE7,0xE9,0xE9,0xE9,0xE9,0xE9,0xE9,0xE9,0xE9,
+0xE9,0xE9,0xE9,0x79,0x63,0x63,0x58,0x29,0x7B,0x1A,0x28,0x30,0x30,0x63,0x0C,0x50,0x10,0x50,0x28,0x21,0x1D,0x31,0x62,0x11,0x36,0x10,0x68,0x30,0x30,0x16,0x3E,0x68,0x15,0x29,0x8C,0x3E,0x11,0x36,0x4F,0xC2,0xD7,0xDA,0xDF,0xE7,0xE7,0xE9,0xE9,0xE9,0xE9,0xE9,0xE9,
+0xE9,0xE9,0xE7,0x62,0x62,0x63,0x63,0x22,0x37,0x16,0x28,0x36,0x1C,0x28,0x0C,0x49,0x15,0x29,0x16,0x21,0x1D,0x22,0x22,0x0C,0x31,0x11,0x29,0x15,0x21,0x15,0x22,0x22,0x10,0x22,0x48,0x1D,0x08,0x3E,0x29,0x3E,0xB9,0xD2,0xD7,0xDB,0xE0,0xE7,0xE9,0xE9,0xE9,0xE9,0xE9,
+0xE9,0xE9,0xDB,0x62,0x4F,0x4F,0x3F,0x30,0x21,0x15,0x28,0x31,0x22,0x1A,0x0C,0x50,0x18,0x1D,0x0E,0x29,0x1D,0x22,0x16,0x10,0x37,0x1D,0x1D,0x0C,0x28,0x1A,0x29,0x1A,0x18,0x21,0x21,0x16,0x0E,0x3E,0x29,0x30,0x48,0xB0,0xC9,0xD3,0xDB,0xE0,0xE7,0xE9,0xE9,0xE9,0xE9,
+0xE9,0xE9,0xE7,0xA3,0x72,0x21,0x15,0x31,0x36,0x30,0x49,0x36,0x3F,0x29,0x30,0x4F,0x29,0x36,0x21,0x3F,0x28,0x30,0x1A,0x28,0x3E,0x22,0x18,0x16,0x3E,0x1D,0x21,0x11,0x22,0x21,0x10,0x11,0x37,0x11,0x15,0x28,0x48,0x80,0xA4,0xC1,0xD3,0xDA,0xE0,0xE7,0xE9,0xE9,0xE9,
+0xE9,0xD3,0xE9,0xE9,0xE9,0xB7,0x59,0x22,0x58,0x48,0x48,0x48,0x37,0x37,0x3E,0x36,0x36,0x36,0x36,0x37,0x31,0x36,0x36,0x37,0x36,0x30,0x29,0x31,0x36,0x30,0x31,0x31,0x31,0x30,0x30,0x37,0x15,0x15,0xC1,0xE9,0xE9,0x8A,0x59,0x99,0xC1,0xD3,0xDB,0xE0,0xE9,0xE9,0xE9,
+0xE9,0x68,0x50,0x1C,0x16,0x31,0x30,0x1A,0x58,0x49,0x3F,0x3E,0x3E,0x37,0x36,0x37,0x31,0x30,0x30,0x31,0x36,0x30,0x29,0x29,0x29,0x29,0x28,0x28,0x29,0x22,0x28,0x22,0x29,0x29,0x30,0x31,0x15,0x1C,0x59,0x50,0x36,0x36,0x49,0x7B,0xA3,0xC2,0xD6,0xDB,0xE7,0xE9,0xE9,
+0xE9,0xA4,0x50,0x58,0x36,0x29,0x37,0x4F,0x50,0x3F,0x3E,0x31,0x31,0x31,0x36,0x36,0x36,0x31,0x30,0x30,0x29,0x30,0x30,0x29,0x28,0x22,0x28,0x28,0x22,0x28,0x22,0x21,0x22,0x22,0x22,0x36,0x28,0x29,0x1A,0x15,0x0C,0x1A,0x37,0x63,0x80,0xAE,0xC9,0xD7,0xDF,0xE7,0xE9,
+0xE9,0xE7,0xC9,0x80,0x28,0x16,0x15,0x15,0x49,0x37,0x37,0x37,0x30,0x30,0x29,0x30,0x31,0x30,0x29,0x29,0x28,0x36,0x28,0x28,0x48,0x29,0x21,0x22,0x28,0x21,0x21,0x22,0x1D,0x22,0x22,0x30,0x21,0x16,0x1C,0x21,0x31,0x31,0x37,0x4F,0x68,0x8C,0xB7,0xD3,0xDB,0xE7,0xE9,
+0xE9,0xC2,0xE9,0xDA,0xB0,0x4F,0x1D,0x1D,0x4F,0x37,0x31,0x36,0x36,0x30,0x30,0x30,0x31,0x29,0x30,0x28,0x36,0x81,0x50,0x15,0x0C,0x31,0x28,0x21,0x22,0x22,0x22,0x21,0x22,0x21,0x1D,0x28,0x0E,0x11,0x81,0xDF,0xE0,0x80,0x36,0x3E,0x59,0x7B,0xA4,0xC9,0xDA,0xE0,0xE9,
+0xE7,0x72,0x67,0x3E,0x37,0x36,0x16,0x28,0x49,0x37,0x36,0x30,0x30,0x30,0x29,0x30,0x29,0x30,0x22,0x28,0x49,0xB7,0xB9,0x99,0x29,0x0E,0x31,0x28,0x1D,0x21,0x22,0x1D,0x1D,0x22,0x21,0x28,0x11,0x22,0x8C,0x98,0x8A,0x4F,0x30,0x36,0x4F,0x71,0x99,0xC2,0xD7,0xE0,0xE7,
+0xDF,0x80,0x3E,0x18,0x10,0x21,0x31,0x3F,0x48,0x36,0x36,0x30,0x30,0x29,0x30,0x30,0x30,0x29,0x28,0x28,0x50,0xA4,0x8C,0x98,0xA4,0x3E,0x10,0x31,0x22,0x22,0x1D,0x1D,0x22,0x21,0x22,0x22,0x18,0x30,0x10,0x09,0x08,0x0C,0x1D,0x30,0x49,0x68,0x98,0xC1,0xD6,0xDF,0xE7,
+0xE9,0xE7,0xB0,0x50,0x22,0x28,0x22,0x28,0x3E,0x36,0x31,0x30,0x30,0x30,0x29,0x29,0x29,0x28,0x29,0x28,0x4F,0x80,0x48,0x48,0x63,0x98,0x3F,0x16,0x29,0x21,0x1D,0x21,0x21,0x1D,0x21,0x22,0x1D,0x21,0x29,0x31,0x1D,0x1A,0x22,0x30,0x48,0x67,0x8C,0xB9,0xD6,0xDF,0xE7,
+0xDF,0xD3,0xE9,0xD7,0x81,0x31,0x10,0x16,0x3E,0x36,0x31,0x30,0x29,0x30,0x29,0x29,0x28,0x28,0x28,0x28,0x37,0x67,0x48,0x48,0x47,0x50,0x7B,0x36,0x1A,0x30,0x1D,0x1D,0x1D,0x21,0x21,0x21,0x10,0x15,0x63,0xC1,0xC1,0x62,0x31,0x30,0x48,0x67,0x8C,0xB9,0xD6,0xDF,0xE7,
+0xE0,0x8A,0xAE,0x67,0x4F,0x37,0x18,0x22,0x3F,0x36,0x30,0x30,0x29,0x22,0x29,0x29,0x22,0x28,0x28,0x21,0x29,0x61,0x47,0x47,0x48,0x48,0x4F,0x79,0x31,0x22,0x37,0x1D,0x1D,0x1D,0x1C,0x21,0x15,0x36,0xC1,0xD6,0xB7,0x59,0x28,0x30,0x48,0x63,0x8A,0xB9,0xD6,0xDF,0xE7,
+0xD2,0x59,0x36,0x10,0x0C,0x1C,0x15,0x29,0x3F,0x30,0x36,0x30,0x30,0x28,0x22,0x1D,0x28,0x31,0x22,0x21,0x22,0x3E,0x48,0x48,0x48,0x48,0x48,0x50,0x68,0x30,0x30,0x28,0x1D,0x1C,0x21,0x1D,0x11,0x1C,0x0C,0x00,0x02,0x09,0x21,0x30,0x48,0x63,0x8A,0xB9,0xD6,0xDF,0xE7,
+0xE9,0xDB,0x80,0x4F,0x30,0x3E,0x48,0x49,0x36,0x30,0x31,0x30,0x29,0x22,0x2E,0x2D,0x4C,0x6D,0x76,0x94,0x4D,0x31,0x4E,0x48,0x47,0x48,0x48,0x48,0x50,0x62,0x30,0x37,0x1D,0x1D,0x1D,0x1D,0x21,0x29,0x22,0x21,0x1C,0x16,0x21,0x30,0x48,0x63,0x8C,0xB9,0xD6,0xDF,0xE7,
+0xE7,0xE0,0xB9,0x72,0x1D,0x16,0x10,0x16,0x36,0x29,0x29,0x30,0x29,0x44,0xB5,0xC8,0x5D,0x6E,0x9E,0x9D,0x78,0x5F,0x70,0x46,0x47,0x47,0x48,0x3F,0x3F,0x58,0x4F,0x36,0x36,0x1A,0x1A,0x1C,0x15,0x10,0x1D,0x49,0x63,0x37,0x36,0x30,0x48,0x67,0x8C,0xB9,0xD6,0xDF,0xE7,
+0xDA,0xAE,0xE9,0xC2,0x8A,0x3F,0x1A,0x21,0x31,0x29,0x29,0x28,0x29,0x89,0xE5,0xE3,0xAA,0x66,0x38,0x4A,0x41,0x40,0x5C,0x45,0x3E,0x3E,0x3E,0x3E,0x3E,0x3F,0x58,0x48,0x48,0x31,0x18,0x21,0x10,0x21,0xD7,0xE9,0xE7,0x80,0x30,0x30,0x48,0x67,0x8C,0xB9,0xD6,0xDF,0xE7,
+0xD2,0x62,0x62,0x29,0x28,0x28,0x11,0x22,0x36,0x28,0x28,0x28,0x29,0x7E,0xE4,0xE8,0x96,0x3A,0x86,0x8E,0x85,0x75,0x53,0x57,0x3C,0x37,0x37,0x37,0x37,0x37,0x3E,0x4F,0x49,0x4F,0x1C,0x1C,0x16,0x1D,0x31,0x31,0x22,0x1D,0x21,0x30,0x48,0x67,0x8C,0xB9,0xD6,0xDF,0xE7,
+0xDA,0xB0,0x62,0x16,0x10,0x21,0x31,0x48,0x37,0x28,0x28,0x3B,0x6F,0x78,0x95,0x97,0x64,0xA1,0xCF,0xCE,0xC6,0xBB,0x90,0x65,0x3B,0x32,0x36,0x36,0x36,0x31,0x36,0x3F,0x4F,0x4F,0x37,0x1C,0x18,0x22,0x16,0x10,0x0E,0x0C,0x1D,0x30,0x48,0x63,0x8C,0xB9,0xD6,0xDF,0xE7,
+0xE9,0xE0,0x98,0x37,0x1C,0x22,0x22,0x21,0x30,0x31,0x88,0xA5,0xA7,0xB2,0x9F,0x91,0x9F,0xB4,0xC7,0xD0,0x9C,0xA6,0x7C,0x73,0x60,0x30,0x30,0x30,0x30,0x30,0x30,0x30,0x3F,0x58,0x49,0x1C,0x1A,0x1D,0x1D,0x1C,0x21,0x1D,0x22,0x30,0x48,0x63,0x8A,0xB9,0xD6,0xDF,0xE7,
+0xDF,0xD6,0xDA,0x8A,0x49,0x21,0x11,0x18,0x30,0x29,0x35,0x34,0x42,0x2B,0x24,0x1F,0x17,0x25,0x39,0x55,0x54,0x6B,0x69,0x7D,0x5E,0x3C,0x22,0x10,0x1C,0x28,0x28,0x29,0x30,0x3F,0x63,0x3F,0x10,0x10,0x67,0xB9,0xC9,0x72,0x48,0x36,0x3F,0x63,0x8A,0xB9,0xD6,0xDF,0xE7,
+0xD6,0xA4,0xDB,0x98,0x68,0x31,0x1A,0x21,0x30,0x22,0x21,0x22,0x21,0x13,0x7F,0x4E,0x02,0x18,0x98,0xAF,0x19,0x0A,0x12,0x43,0x27,0x30,0x16,0x00,0x0E,0x1D,0x22,0x22,0x28,0x29,0x58,0x67,0x1C,0x1D,0xA3,0xD3,0xB9,0x67,0x29,0x30,0x3F,0x63,0x8A,0xB9,0xD3,0xDF,0xE7,
+0xC1,0x62,0x30,0x0C,0x0E,0x1A,0x15,0x28,0x29,0x22,0x21,0x1C,0x2F,0x2F,0x51,0x9A,0x11,0x52,0x58,0x48,0x7A,0x02,0x05,0x30,0x1C,0x21,0x22,0x02,0x00,0x16,0x1D,0x21,0x21,0x22,0x36,0x72,0x48,0x18,0x02,0x00,0x02,0x08,0x1A,0x29,0x3F,0x63,0x8A,0xB7,0xD3,0xDF,0xE7,
+0xE9,0xE0,0xAE,0x1D,0x1A,0x30,0x49,0x48,0x22,0x21,0x1D,0x21,0x29,0x23,0x33,0x56,0x74,0x77,0x2C,0x18,0x83,0x02,0x03,0x30,0x21,0x1A,0x22,0x09,0x00,0x0E,0x1C,0x1C,0x1D,0x1D,0x21,0x59,0x79,0x29,0x22,0x21,0x1C,0x18,0x21,0x30,0x3F,0x62,0x81,0xB7,0xD3,0xDF,0xE7,
+0xE7,0xDA,0x98,0x3F,0x11,0x15,0x0E,0x16,0x29,0x21,0x1D,0x1D,0x29,0x14,0x93,0xCC,0xB3,0x84,0xA0,0xBE,0x4B,0x02,0x01,0x28,0x1D,0x1D,0x1D,0x18,0x00,0x02,0x18,0x1A,0x1C,0x1A,0x1C,0x29,0x81,0x15,0x30,0x62,0x7B,0x48,0x3E,0x36,0x3F,0x62,0x81,0xB7,0xD3,0xDB,0xE7,
+0xD7,0xC2,0xE9,0xB0,0x71,0x31,0x15,0x1C,0x28,0x21,0x1D,0x1D,0x28,0x1E,0xA6,0xD8,0xBD,0xA9,0xBC,0xC7,0x6A,0x04,0x02,0x20,0x1A,0x1C,0x1C,0x18,0x00,0x00,0x11,0x18,0x18,0x18,0x18,0x1A,0x68,0x1C,0xD2,0xE9,0xE9,0x80,0x36,0x29,0x3E,0x62,0x80,0xB0,0xD2,0xDB,0xE7,
+0xC1,0x79,0x72,0x3F,0x31,0x21,0x0E,0x1D,0x28,0x1C,0x1D,0x1A,0x30,0x0F,0x6C,0xCD,0xD5,0xBA,0x8D,0xA8,0x57,0x0E,0x2A,0x10,0x21,0x1C,0x48,0x02,0x00,0x00,0x0E,0x16,0x16,0x16,0x16,0x18,0x31,0x18,0x18,0x15,0x11,0x10,0x1C,0x29,0x3E,0x59,0x80,0xB0,0xD2,0xDB,0xE7,
+0xDA,0xD2,0x72,0x0E,0x0C,0x1D,0x30,0x37,0x22,0x1C,0x1D,0x1C,0x30,0x06,0xA2,0x92,0x9B,0x8F,0x87,0xBF,0xB1,0x0D,0x1B,0x09,0x1A,0x37,0x1A,0x02,0x00,0x00,0x10,0x18,0x16,0x16,0x16,0x18,0x11,0x21,0x18,0x11,0x11,0x11,0x1D,0x29,0x3E,0x59,0x80,0xB0,0xD2,0xDB,0xE7,
+0xE9,0xE0,0x99,0x37,0x1A,0x22,0x21,0x21,0x22,0x1D,0x1C,0x29,0x1D,0x16,0xAE,0xAC,0xAB,0xAD,0xD1,0xDD,0xD6,0x46,0x02,0x04,0x0B,0x0E,0x00,0x00,0x00,0x00,0x1D,0x1C,0x18,0x18,0x16,0x18,0x10,0x1A,0x1D,0x30,0x30,0x30,0x29,0x29,0x3E,0x59,0x80,0xB0,0xD2,0xDB,0xE7,
+0xDF,0xB9,0x98,0x62,0x22,0x1A,0x0C,0x16,0x22,0x1C,0x21,0x26,0x09,0x5B,0x8B,0xC5,0xCA,0xDC,0xE2,0xC0,0x72,0x7B,0x07,0x07,0x03,0x00,0x00,0x00,0x00,0x0C,0x18,0x1D,0x1C,0x18,0x18,0x18,0x10,0x3F,0xD6,0xE9,0xD3,0x59,0x29,0x29,0x3E,0x59,0x80,0xB0,0xD2,0xDB,0xE7,
+0xCB,0xB0,0xE9,0xAE,0x72,0x30,0x11,0x1D,0x22,0x22,0x11,0x09,0x21,0xCB,0xCB,0xE0,0xE7,0xE9,0xDE,0x99,0x79,0xB7,0x1C,0x03,0x01,0x00,0x00,0x00,0x02,0x1A,0x15,0x15,0x21,0x1C,0x18,0x18,0x0E,0x31,0x67,0x62,0x29,0x1A,0x28,0x29,0x3E,0x62,0x81,0xB0,0xD3,0xDB,0xE7,
+0xB9,0x8A,0x4F,0x11,0x10,0x18,0x0E,0x21,0x29,0x11,0x18,0x10,0x3F,0xCB,0xD2,0xD7,0xDC,0xE9,0xE6,0xC9,0xB6,0xB8,0x5A,0x01,0x00,0x00,0x00,0x00,0x08,0x29,0x29,0x16,0x15,0x1A,0x1A,0x15,0x02,0x0E,0x08,0x00,0x08,0x09,0x1D,0x29,0x3E,0x62,0x81,0xB7,0xD3,0xDB,0xE7,
+0xE9,0xE0,0x98,0x15,0x11,0x1D,0x3E,0x37,0x02,0x0E,0x1C,0x02,0x8A,0xA3,0x71,0xB7,0xE1,0xE9,0xE6,0xDC,0xD9,0xD4,0xC4,0x28,0x02,0x00,0x00,0x09,0x02,0x00,0x00,0x02,0x0C,0x16,0x30,0x21,0x0E,0x21,0x28,0x21,0x1D,0x1A,0x22,0x29,0x3F,0x62,0x81,0xB7,0xD3,0xDF,0xE7,
+0xE9,0xC1,0x67,0x28,0x0E,0x11,0x10,0x16,0x02,0x00,0x08,0x00,0x48,0x8C,0x8C,0xC3,0xDF,0xE0,0xD3,0x7B,0x82,0xCB,0xC9,0x71,0x01,0x00,0x09,0x0C,0x00,0x00,0x00,0x00,0x00,0x00,0x08,0x1C,0x18,0x28,0x98,0xDF,0xC1,0x58,0x3E,0x29,0x3F,0x62,0x81,0xB7,0xD3,0xDF,0xE7,
+0xD6,0xB9,0xD7,0x8C,0x59,0x31,0x10,0x1A,0x0C,0x00,0x00,0x00,0x02,0x18,0x1C,0x21,0x31,0x37,0x31,0x1A,0x1D,0x37,0x3D,0x28,0x03,0x00,0x0C,0x02,0x00,0x02,0x09,0x0E,0x0C,0x10,0x18,0x18,0x15,0x4F,0xC1,0xC9,0x71,0x30,0x21,0x29,0x3F,0x62,0x8A,0xB7,0xD3,0xDF,0xE7,
+0xC2,0x8A,0xAE,0x63,0x49,0x28,0x09,0x1C,0x22,0x16,0x08,0x00,0x00,0x0C,0x18,0x11,0x10,0x10,0x0C,0x09,0x0C,0x0E,0x0E,0x10,0x11,0x15,0x1A,0x22,0x1C,0x1A,0x1D,0x1A,0x11,0x16,0x15,0x16,0x10,0x0C,0x00,0x00,0x00,0x00,0x1A,0x29,0x3F,0x62,0x81,0xB7,0xD3,0xDF,0xE7,
+0xDB,0xDA,0x72,0x08,0x09,0x16,0x22,0x31,0x21,0x18,0x1A,0x16,0x08,0x09,0x15,0x18,0x11,0x16,0x16,0x15,0x11,0x11,0x16,0x16,0x15,0x15,0x11,0x11,0x11,0x15,0x15,0x15,0x11,0x11,0x15,0x18,0x15,0x1C,0x18,0x16,0x1D,0x18,0x21,0x29,0x3E,0x62,0x81,0xB7,0xD3,0xDF,0xE7,
+0xE9,0xDF,0x8A,0x1D,0x15,0x1A,0x1C,0x21,0x22,0x1C,0x16,0x16,0x18,0x18,0x18,0x16,0x16,0x18,0x15,0x15,0x15,0x16,0x16,0x15,0x15,0x15,0x16,0x15,0x11,0x11,0x15,0x11,0x11,0x16,0x16,0x1A,0x16,0x16,0x58,0xC1,0xAE,0x59,0x3E,0x30,0x3E,0x62,0x81,0xB7,0xD3,0xDF,0xE7,
+0xE7,0x98,0x50,0x36,0x16,0x18,0x09,0x18,0x28,0x1D,0x1A,0x16,0x16,0x16,0x16,0x16,0x16,0x16,0x16,0x15,0x16,0x16,0x15,0x16,0x15,0x15,0x11,0x11,0x11,0x15,0x15,0x15,0x11,0x11,0x11,0x1A,0x15,0x31,0xD2,0xCB,0x59,0x29,0x22,0x29,0x3E,0x59,0x80,0xB0,0xD3,0xDB,0xE7,
+0xCB,0xB0,0xDB,0xA4,0x68,0x31,0x10,0x1C,0x28,0x21,0x1C,0x1A,0x16,0x18,0x18,0x1C,0x16,0x18,0x15,0x16,0x18,0x11,0x11,0x15,0x15,0x11,0x11,0x11,0x15,0x11,0x10,0x11,0x15,0x15,0x18,0x1C,0x15,0x18,0x15,0x00,0x02,0x09,0x08,0x21,0x3E,0x59,0x80,0xB0,0xD2,0xDB,0xE7,
+0xC9,0xC1,0x80,0x36,0x21,0x1A,0x10,0x29,0x16,0x11,0x1A,0x0E,0x0C,0x15,0x11,0x1A,0x09,0x0E,0x11,0x16,0x10,0x09,0x0E,0x0E,0x16,0x08,0x09,0x0C,0x11,0x0E,0x08,0x0E,0x0C,0x16,0x08,0x0E,0x18,0x18,0x0C,0x08,0x15,0x16,0x1C,0x28,0x37,0x59,0x80,0xB0,0xD2,0xDB,0xE7,
+0xE9,0xE0,0x81,0x0C,0x09,0x1A,0x29,0x08,0x0E,0x10,0x1C,0x0E,0x0C,0x11,0x16,0x1C,0x02,0x10,0x0E,0x1C,0x10,0x09,0x0E,0x10,0x1A,0x02,0x0E,0x0C,0x18,0x0E,0x09,0x0E,0x10,0x18,0x08,0x10,0x0C,0x18,0x18,0x16,0x10,0x16,0x21,0x29,0x37,0x58,0x7B,0xAE,0xD2,0xDB,0xE7,
+0xE9,0xE0,0x99,0x21,0x1D,0x21,0x1C,0x50,0x72,0x1A,0x1D,0x11,0x71,0x72,0x1A,0x1C,0x16,0x99,0x30,0x1C,0x11,0x59,0x80,0x18,0x1A,0x15,0xA4,0x37,0x18,0x10,0x58,0xAE,0x15,0x18,0x15,0xCB,0x49,0x18,0x11,0x10,0x11,0x16,0x21,0x29,0x3E,0x59,0x80,0xAE,0xD2,0xDB,0xE7,
+0xE9,0xE0,0xA3,0x1A,0x21,0x22,0x21,0xB9,0xCB,0x15,0x22,0x15,0xCB,0xC9,0x11,0x1D,0x22,0xE9,0x50,0x18,0x11,0x98,0xE7,0x10,0x1C,0x15,0xE9,0x68,0x16,0x10,0x71,0xE9,0x16,0x1A,0x10,0xE7,0x67,0x16,0x15,0x15,0x11,0x18,0x22,0x29,0x3E,0x62,0x80,0xB0,0xD2,0xDB,0xE7,
+0xE9,0xE7,0xA3,0x1D,0x1C,0x28,0x30,0xDF,0xCB,0x1D,0x29,0x28,0xE0,0xD2,0x1A,0x22,0x50,0xE9,0x62,0x21,0x21,0xB0,0xE9,0x16,0x1C,0x29,0xE0,0x79,0x1C,0x1C,0x71,0xDB,0x21,0x18,0x21,0xB9,0x79,0x1A,0x15,0x11,0x10,0x18,0x22,0x30,0x48,0x63,0x8A,0xB9,0xD3,0xDF,0xE7,
+0xE9,0xE7,0xD6,0x48,0x1C,0x31,0x18,0x7B,0x59,0x0C,0x16,0x18,0x62,0x50,0x0C,0x16,0x21,0x72,0x28,0x10,0x11,0x48,0x71,0x09,0x10,0x16,0x71,0x36,0x0E,0x0E,0x30,0x50,0x11,0x0E,0x0C,0x49,0x30,0x10,0x0C,0x08,0x10,0x1D,0x28,0x36,0x49,0x68,0x98,0xC2,0xD7,0xDF,0xE7,
+0xE9,0xE9,0xE0,0xDA,0xC9,0xAE,0x7B,0x49,0x28,0x10,0x22,0x22,0x28,0x22,0x15,0x21,0x1D,0x30,0x1C,0x1D,0x1C,0x22,0x22,0x18,0x1D,0x16,0x31,0x21,0x21,0x15,0x29,0x31,0x1D,0x1A,0x1A,0x29,0x1C,0x21,0x21,0x1D,0x22,0x28,0x30,0x3E,0x58,0x79,0xA4,0xCB,0xDA,0xE0,0xE9,
+0xE9,0xE9,0xE7,0xDF,0xD3,0xB9,0x98,0x59,0x36,0x22,0x31,0x3F,0x49,0x1D,0x21,0x28,0x67,0x1D,0x1C,0x22,0x29,0x4F,0x1A,0x1D,0x28,0x58,0x1C,0x1A,0x22,0x29,0x4F,0x1A,0x21,0x28,0x59,0x1C,0x22,0x28,0x28,0x28,0x29,0x31,0x37,0x4F,0x67,0x8A,0xB7,0xD3,0xDB,0xE7,0xE9,
+0xE9,0xE9,0xE7,0xE0,0xD7,0xC9,0xAE,0x81,0x67,0x58,0x48,0x3E,0x37,0x36,0x36,0x36,0x36,0x36,0x31,0x31,0x31,0x31,0x31,0x31,0x31,0x31,0x31,0x31,0x31,0x31,0x31,0x31,0x31,0x31,0x31,0x31,0x31,0x36,0x36,0x36,0x3E,0x48,0x50,0x63,0x7B,0xA3,0xC2,0xD7,0xDF,0xE7,0xE9,
+0xE9,0xE9,0xE9,0xE7,0xDB,0xD3,0xC1,0xA4,0x81,0x72,0x63,0x59,0x50,0x50,0x4F,0x4F,0x4F,0x4F,0x49,0x49,0x49,0x49,0x49,0x49,0x49,0x49,0x49,0x49,0x49,0x49,0x49,0x49,0x49,0x49,0x49,0x49,0x49,0x49,0x4F,0x50,0x58,0x63,0x71,0x80,0x99,0xB9,0xD2,0xDB,0xE0,0xE9,0xE9,
+0xE9,0xE9,0xE9,0xE7,0xE0,0xDA,0xD3,0xC2,0xB0,0x99,0x8A,0x7B,0x79,0x72,0x71,0x71,0x71,0x71,0x68,0x68,0x68,0x68,0x68,0x68,0x68,0x68,0x67,0x67,0x67,0x67,0x67,0x67,0x68,0x68,0x68,0x68,0x68,0x71,0x71,0x72,0x7B,0x8A,0x99,0xAE,0xC1,0xD2,0xDA,0xDF,0xE7,0xE9,0xE9,
+0xE9,0xE9,0xE9,0xE9,0xE7,0xE0,0xDB,0xD6,0xD2,0xC2,0xB7,0xAE,0xA3,0x99,0x99,0x99,0x99,0x98,0x98,0x98,0x98,0x98,0x98,0x98,0x98,0x8C,0x8C,0x8C,0x8C,0x8C,0x8C,0x8C,0x8C,0x98,0x98,0x98,0x98,0x98,0x99,0xA3,0xA4,0xB7,0xC2,0xCB,0xD6,0xDA,0xDF,0xE7,0xE9,0xE9,0xE9,
+0xE9,0xE9,0xE9,0xE9,0xE9,0xE7,0xE0,0xDF,0xDA,0xD7,0xD3,0xCB,0xC9,0xC2,0xC2,0xC2,0xC2,0xC1,0xC1,0xC1,0xC1,0xC1,0xC1,0xC1,0xC1,0xC1,0xB9,0xB9,0xB9,0xB9,0xB9,0xB9,0xC1,0xC1,0xC1,0xC1,0xC1,0xC1,0xC2,0xC2,0xCB,0xD3,0xD7,0xDA,0xDF,0xE0,0xE7,0xE9,0xE9,0xE9,0xE9,
+0xE9,0xE9,0xE9,0xE9,0xE9,0xE9,0xE9,0xE7,0xE0,0xDF,0xDB,0xDA,0xDA,0xD7,0xD7,0xD7,0xD7,0xD6,0xD6,0xD6,0xD6,0xD6,0xD6,0xD6,0xD6,0xD6,0xD6,0xD6,0xD6,0xD6,0xD6,0xD6,0xD6,0xD6,0xD6,0xD6,0xD6,0xD7,0xD7,0xD7,0xDA,0xDB,0xDF,0xE0,0xE7,0xE7,0xE9,0xE9,0xE9,0xE9,0xE9,
+0xE9,0xE9,0xE9,0xE9,0xE9,0xE9,0xE9,0xE9,0xE9,0xE7,0xE7,0xE0,0xE0,0xE0,0xE0,0xE0,0xDF,0xDF,0xDF,0xDF,0xDF,0xDF,0xDF,0xDF,0xDF,0xDF,0xDF,0xDF,0xDF,0xDF,0xDF,0xDF,0xDF,0xDF,0xDF,0xDF,0xDF,0xDF,0xDF,0xE0,0xE0,0xE7,0xE7,0xE9,0xE9,0xE9,0xE9,0xE9,0xE9,0xE9,0xE9,
+0xE9,0xE9,0xE9,0xE9,0xE9,0xE9,0xE9,0xE9,0xE9,0xE9,0xE9,0xE9,0xE9,0xE9,0xE7,0xE7,0xE7,0xE7,0xE7,0xE7,0xE7,0xE7,0xE7,0xE7,0xE7,0xE7,0xE7,0xE7,0xE7,0xE7,0xE7,0xE7,0xE7,0xE7,0xE7,0xE7,0xE7,0xE7,0xE7,0xE9,0xE9,0xE9,0xE9,0xE9,0xE9,0xE9,0xE9,0xE9,0xE9,0xE9,0xE9,
+};



From rminnich at gmail.com  Fri Oct  5 21:56:57 2007
From: rminnich at gmail.com (ron minnich)
Date: Fri, 5 Oct 2007 12:56:57 -0700
Subject: [LinuxBIOS] VGA support for Geode GX1/CS5530
In-Reply-To: <200710052129.54369.juergen127@kreuzholzen.de>
References: <200710052129.54369.juergen127@kreuzholzen.de>
Message-ID: <13426df10710051256l5bcc9ab6i8f19456c64b0450c@mail.gmail.com>

It's great. Give me a signed-off-by line and I will ack and commit.

ron



From yinghailu at gmail.com  Fri Oct  5 22:28:42 2007
From: yinghailu at gmail.com (yhlu)
Date: Fri, 5 Oct 2007 13:28:42 -0700
Subject: [LinuxBIOS] Tyan Thunder n3600R (S2912) support status?
In-Reply-To: <20071005184730.GB9912@greenwood>
References: <4705EAC4.5030302@ornia.hampshire.edu>
	<2ea3fae10710051104i41d0d010r2462f918c742b501@mail.gmail.com>
	<20071005184730.GB9912@greenwood>
Message-ID: <2ea3fae10710051328v17fc5fb7v8b3284670778c017@mail.gmail.com>

On 10/5/07, Uwe Hermann <uwe at hermann-uwe.de> wrote:
> On Fri, Oct 05, 2007 at 11:04:29AM -0700, yhlu wrote:
> > > ..here's hoping the compatibility list is out of date!
> >
> > stefan, can you update that!
> >
> > anything is missed?
> >
> > I hope we can find another MB
> > split power plane ( for quad core support) + MCP55 + IO55 + HTX + SAS controller
> >
> > before that s2912 is most updated one...
>
> Can you please give us a list of which hardware parts you tried on that
> board (S2912) and which work or don't work?
>
> Something like the Status table from
> http://linuxbios.org/index.php/GIGABYTE_GA-M57SLI-S4_Build_Tutorial#Status
>
> E.g. do the following parts all work and are they all tested?
>
> CPU ==>yes
> RAM ===> yes
> IDE ===> yes
> IDE using CF-to-IDE adapter ===>  not tested
> SATA ==> yes
> USB ==> yes
> On-board ethernet ===> yes
> On-board audio ====> N/A
> PCI add-on cards ===> N/A
> PCI Express add-on cards ===> display card
> Floppy ===> why? not tested
> Serial port (COM1) Yes
> Serial port (COM2) ?
> Parallel port ===> why? not tested
> PS/2 keyboard ===> why? not tested
> PS/2 mouse ===> why? not tested
> Mainboard sensors/fans ===> N/A
> CPU frequency scaling / powersave modes ===>no acpi, so no
> Flashrom ==========> not test, i had rom emulator

HTX card: from infipath? works.

YH



From juergen127 at kreuzholzen.de  Fri Oct  5 22:43:37 2007
From: juergen127 at kreuzholzen.de (Juergen Beisert)
Date: Fri, 5 Oct 2007 22:43:37 +0200
Subject: [LinuxBIOS] VGA support for Geode GX1/CS5530
In-Reply-To: <13426df10710051256l5bcc9ab6i8f19456c64b0450c@mail.gmail.com>
References: <200710052129.54369.juergen127@kreuzholzen.de>
	<13426df10710051256l5bcc9ab6i8f19456c64b0450c@mail.gmail.com>
Message-ID: <200710052243.37625.juergen127@kreuzholzen.de>

Hi Ron,

On Friday 05 October 2007 21:56, ron minnich wrote:
> It's great. Give me a signed-off-by line and I will ack and commit.

all right, here it comes:

From: Juergen Beisert <juergen127 at kreuzholzen.de>

This patch will add support for the Geode GX1/CS5530 VGA feature. Its able
to set up one of five screen resolutions (sorry no autodetection at runtime,
resolution is selected at buildtime) and displays a graphic in the right
bottom corner (splash screen).

Patch is against LinuxBIOSv2, revision of 2007-10-05.

Signed-off-by: Juergen Beisert <juergen127 at kreuzholzen.de>

 config/Options.lb                   |   16 +
 southbridge/amd/cs5530/Config.lb    |    1
 southbridge/amd/cs5530/bitmap.c     |  304 +++++++++++++++++++++++
 southbridge/amd/cs5530/cs5530_vga.c |  458 ++++++++++++++++++++++++++++++++++++
 4 files changed, 779 insertions(+)

--- 

Index: LinuxBIOSv2/src/southbridge/amd/cs5530/cs5530_vga.c
===================================================================
--- /dev/null
+++ LinuxBIOSv2/src/southbridge/amd/cs5530/cs5530_vga.c
@@ -0,0 +1,458 @@
+/*
+ * Copyright (C) 2007 Juergen Beisert <juergen at kreuzholzen.de>
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; version 2 of the License.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA, 02110-1301 USA
+ *
+ * Purpose:
+ * Activate the VGA feature in a Geode GX1 based system with one of five
+ * possible VESA modes: VGA, SVGA, XGA, 4:3 SXGA and 5:4 SXGA. Also it is
+ * prepared to display a splash screen.
+ */
+#include <arch/io.h>
+#include <device/device.h>
+#include <device/pci.h>
+#include <device/pci_ops.h>
+#include <device/pci_ids.h>
+#include <console/console.h>
+#include <cpu/amd/gx1def.h>
+#include <delay.h>
+
+#if CONFIG_GX1_VIDEO == 1
+/*
+ * Some register descriptions that are no listed in cpu/amd/gx1def.h
+ */
+#define CS5530_DOT_CLK_CONFIG	0x0024
+#define CS5530_DISPLAY_CONFIG	0x0004
+
+#define DC_FB_ST_OFFSET		0x8310	/* framebuffer start offset */
+#define DC_CB_ST_OFFSET		0x8314	/* compression start offset */
+#define DC_CURS_ST_OFFSET	0x8318	/* cursor start offset */
+#define DC_VID_ST_OFFSET	0x8320	/* video start offset */
+#define DC_LINE_DELTA		0x8324	/* fb and cb skip counts */
+#define DC_BUF_SIZE		0x8328	/* fb and cb line size */
+#define DC_H_TIMING_1		0x8330	/* horizontal timing... */
+#define DC_H_TIMING_2		0x8334
+#define DC_H_TIMING_3		0x8338
+#define DC_FP_H_TIMING		0x833C
+#define DC_V_TIMING_1		0x8340	/* vertical timing... */
+#define DC_V_TIMING_2		0x8344
+#define DC_V_TIMING_3		0x8348
+#define DC_FP_V_TIMING		0x834C
+#define DC_TIMING_CFG		0x8308
+#define DC_OUTPUT_CFG		0x830C
+
+/*
+ * what colour depth should be used as default (in bpp)
+ * Note: Currently no other value than 16 is supported
+ */
+#define COLOUR_DEPTH 16
+
+/*
+ * Support for a few basic video modes
+ * Note: all modes only for CRT. The flatpanel feature is
+ * not supported here (due to the lack of hardware to test)
+ */
+struct video_mode {
+	int pixel_clock;		/*<< pixel clock in Hz */
+	unsigned long pll_value;	/*<< pll register value for this clock */
+
+	int visible_pixel;
+	int hsync_start;
+	int hsync_end;
+	int line_length;
+
+	int visible_lines;
+	int vsync_start;
+	int vsync_end;
+	int picture_length;
+
+	int sync_pol;		/*<< 0: low, 1: high, bit 0 hsync, bit 1 vsync */
+};
+
+/*
+ * values for .sync_pol
+ */
+#define HSYNC_HIGH_POL 0
+#define HSYNC_LOW_POL 1
+#define VSYNC_HIGH_POL 0
+#define VSYNC_LOW_POL 2
+
+/* ModeLine "640x480" 31.5 640 664 704 832 480 489 491 520 -hsync -vsync */
+static const struct video_mode mode_640x480 = {
+	/*
+	 * 640x480 @ 72Hz hsync: 37.9kHz
+	 * VESA standard mode for classic 4:3 monitors
+	 */
+	.pixel_clock = 31500000,
+	.pll_value = 0x33915801,
+
+	.visible_pixel = 640,
+	.hsync_start = 664,
+	.hsync_end = 704,	/* 1.27 us sync length */
+	.line_length = 832,	/* 26.39us */
+
+	.visible_lines = 480,
+	.vsync_start = 489,
+	.vsync_end = 491,
+	.picture_length = 520, /* 13.89ms */
+
+	.sync_pol = HSYNC_LOW_POL | VSYNC_LOW_POL
+};
+
+/* ModeLine "800x600" 50.0 800 856 976 1040 600 637 643 666 +hsync +vsync */
+static const struct video_mode mode_800x600 = {
+	/*
+	 * 800x600 @ 72Hz hsync: 48.1kHz
+	 * VESA standard mode for classic 4:3 monitors
+	 */
+	.pixel_clock = 50000000,
+	.pll_value = 0x23088801,
+
+	.visible_pixel = 800,
+	.hsync_start = 856,
+	.hsync_end = 976,
+	.line_length = 1040, /* 20.8us */
+
+	.visible_lines = 600,
+	.vsync_start = 637,
+	.vsync_end = 643,
+	.picture_length = 666, /* 13.89ms */
+
+	.sync_pol = HSYNC_HIGH_POL | VSYNC_HIGH_POL
+};
+
+/* ModeLine "1024x768" 75.0 1024 1048 1184 1328 768 771 777 806 -hsync -vsync */
+static const struct video_mode mode_1024x768 = {
+	/*
+	 * 1024x768 @ 70Hz (VESA) hsync: 56.5kHz
+	 * Standard mode for classic 4:3 monitors
+	 */
+	.pixel_clock = 75000000,
+	.pll_value = 0x37E22801,
+
+	.visible_pixel = 1024,
+	.hsync_start = 1048,
+	.hsync_end = 1184,
+	.line_length = 1328,	/* 17.7us */
+
+	.visible_lines = 768,
+	.vsync_start = 771,
+	.vsync_end = 777,
+	.picture_length = 806,	/* 14.3us */
+
+	.sync_pol = HSYNC_LOW_POL | VSYNC_LOW_POL
+};
+
+/* ModeLine "1280x960" 108.0 1280 1376 1488 1800 960 961 964 1000 +hsync +vsync */
+static const struct video_mode mode_1280x960 = {
+	/*
+	 * 1280x960 @ 60Hz (VESA) hsync: 60.0kHz
+	 * Mode for classic 4:3 monitors
+	 */
+	.pixel_clock = 108000000,
+	.pll_value = 0x2710C805,
+
+	.visible_pixel = 1280,
+	.hsync_start = 1376,
+	.hsync_end = 1488,
+	.line_length = 1800,	/* 16.67us */
+
+	.visible_lines = 960,
+	.vsync_start = 961,
+	.vsync_end = 964,
+	.picture_length = 1000,	/* 16.67ms */
+
+	.sync_pol = HSYNC_HIGH_POL | VSYNC_HIGH_POL
+};
+
+/* ModeLine "1280x1024" 108.0 1280 1328 1440 1688 1024 1025 1028 1066 +hsync +vsync */
+static const struct video_mode mode_1280x1024 = {
+	/*
+	 * 1280x1024 @ 60Hz (VESA) hsync: 64.0kHz
+	 * Mode for modern 5:4 flat screens
+	 */
+	.pixel_clock = 108000000,
+	.pll_value = 0x2710C805,
+
+	.visible_pixel = 1280,
+	.hsync_start = 1328,
+	.hsync_end = 1440,
+	.line_length = 1688,	/* 15.6us */
+
+	.visible_lines = 1024,
+	.vsync_start = 1025,
+	.vsync_end = 1028,
+	.picture_length = 1066,
+
+	.sync_pol = HSYNC_HIGH_POL | VSYNC_HIGH_POL
+};
+
+/*
+ * a few supported common modes
+ */
+static const struct video_mode *modes[] = {
+	&mode_640x480,	/* CONFIG_GX1_VIDEOMODE = 0 */
+	&mode_800x600,	/* CONFIG_GX1_VIDEOMODE = 1 */
+	&mode_1024x768,	/* CONFIG_GX1_VIDEOMODE = 2 */
+	&mode_1280x960,	/* CONFIG_GX1_VIDEOMODE = 3 */
+	&mode_1280x1024	/* CONFIG_GX1_VIDEOMODE = 4 */
+};
+
+/* make a sanity check at buildtime */
+#if CONFIG_GX1_VIDEOMODE > 4
+# error Requested video mode is unknown!
+#endif
+
+/*
+ * Setup the pixel PLL in the companion chip
+ * base: register's base address
+ * pll_val: pll register value to be set
+ */
+static void cs5530_set_clock_frequency(void *io_base,unsigned long pll_val)
+{
+	unsigned long reg;
+
+	/* disable the PLL first, reset and power it down */
+	reg = readl(io_base+CS5530_DOT_CLK_CONFIG) & ~0x20;
+	reg |= 0x80000100;
+	writel(reg, io_base+CS5530_DOT_CLK_CONFIG);
+
+	/* write the new PLL setting */
+	reg |= (pll_val & ~0x80000920);
+	writel(reg, io_base+CS5530_DOT_CLK_CONFIG);
+
+	mdelay(1);	/* wait for control voltage to be 0V */
+
+	/* enable the PLL */
+	reg |= 0x00000800;
+	writel(reg, io_base+CS5530_DOT_CLK_CONFIG);
+
+	/* clear reset */
+	reg &= ~0x80000000;
+	writel(reg, io_base+CS5530_DOT_CLK_CONFIG);
+
+	/* clear bypass */
+	reg &= ~0x00000100;
+	writel(reg, io_base+CS5530_DOT_CLK_CONFIG);
+}
+
+/*
+ * Setup memory layout
+ * gx_base: GX register area
+ * mode: Data about the video mode to setup
+ *
+ * This routine assumes unlocked DC registers. Using compressed buffer
+ * is not supported! (makes more sense later, but not while booting)
+ */
+static void dc_setup_layout(void *gx_base,const struct video_mode *mode)
+{
+	unsigned long base = 0x00000000;
+
+	writel(base, gx_base + DC_FB_ST_OFFSET);
+
+	base += (COLOUR_DEPTH>>3) * mode->visible_pixel * mode->visible_lines;
+
+	writel(base, gx_base + DC_CB_ST_OFFSET);
+	writel(base, gx_base + DC_CURS_ST_OFFSET);
+	writel(base, gx_base + DC_VID_ST_OFFSET);
+	writel(((COLOUR_DEPTH>>3) * mode->visible_pixel) >> 2, gx_base + DC_LINE_DELTA);
+	writel(((COLOUR_DEPTH>>3) * mode->visible_pixel) >> 3, gx_base + DC_BUF_SIZE);
+}
+
+/*
+ * Setup the HSYNC/VSYNC, active video timing
+ * gx_base: GX register area
+ * mode: Data about the video mode to setup
+ *
+ * This routine assumes unlocked DC registers
+ *
+ * |<------------------------- htotal ----------------------------->|
+ * |<------------ hactive -------------->|                          |
+ * |                       hblankstart-->|                          |
+ * |                                                    hblankend-->|
+ * |                                hsyncstart-->|                  |
+ * |                                           hsyncend-->|         |
+ * |#####################################___________________________| RGB data
+ * |______________________________________________---------_________| HSYNC
+ *
+ * |<------------------------- vtotal ----------------------------->|
+ * |<------------ vactive -------------->|                          |
+ * |                       vblankstart-->|                          |
+ * |                                                    vblankend-->|
+ * |                                vsyncstart-->|                  |
+ * |                                           vsyncend-->|         |
+ * |#####################################___________________________| line data
+ * |______________________________________________---------_________| YSYNC
+ */
+static void dc_setup_timing(void *gx_base,const struct video_mode *mode)
+{
+	unsigned long hactive, hblankstart, hsyncstart, hsyncend, hblankend, htotal;
+	unsigned long vactive, vblankstart, vsyncstart, vsyncend, vblankend, vtotal;
+
+	hactive = mode->visible_pixel & 0x7FF;
+	hblankstart = hactive;
+	hsyncstart = mode->hsync_start & 0x7FF;
+	hsyncend =  mode->hsync_end & 0x7FF;
+	hblankend = mode->line_length & 0x7FF;
+	htotal = hblankend;
+
+	vactive = mode->visible_lines & 0x7FF;
+	vblankstart = vactive;
+	vsyncstart = mode->vsync_start & 0x7FF;
+	vsyncend =  mode->vsync_end & 0x7FF;
+	vblankend = mode->picture_length & 0x7FF;
+	vtotal = vblankend;
+
+	/* row description */
+	writel((hactive - 1) | ((htotal - 1) << 16), gx_base + DC_H_TIMING_1);
+	/* horizontal blank description */
+	writel((hblankstart - 1) | ((hblankend - 1) << 16), gx_base + DC_H_TIMING_2);
+	/* horizontal sync description */
+	writel((hsyncstart - 1) | ((hsyncend - 1) << 16), gx_base + DC_H_TIMING_3);
+	writel((hsyncstart - 1) | ((hsyncend - 1) << 16), gx_base + DC_FP_H_TIMING);
+
+	/* line description */
+	writel((vactive - 1) | ((vtotal - 1) << 16), gx_base + DC_V_TIMING_1);
+	/* vertical blank description */
+	writel((vblankstart - 1) | ((vblankend - 1) << 16), gx_base + DC_V_TIMING_2);
+	/* vertical sync description */
+	writel((vsyncstart - 1) | ((vsyncend - 1) << 16), gx_base + DC_V_TIMING_3);
+	writel((vsyncstart - 2) | ((vsyncend - 2) << 16), gx_base + DC_FP_V_TIMING);
+}
+
+/*
+ * Setup required internals to bring the mode up and running
+ * gx_base: GX register area
+ * mode: Data about the video mode to setup
+ */
+static void cs5530_activate_mode(void *gx_base, const struct video_mode *mode)
+{
+	writel(0x00000080, gx_base + DC_GENERAL_CFG);
+	mdelay(1);
+	dc_setup_layout(gx_base,mode);
+	dc_setup_timing(gx_base,mode);
+
+	writel(0x2000C581, gx_base + DC_GENERAL_CFG);
+	writel(0x0000002F, gx_base + DC_TIMING_CFG);
+	writel(0x00003004, gx_base + DC_OUTPUT_CFG);
+}
+
+/*
+ * Activate the current mode to be "visible" outside
+ * gx_base: GX register area
+ * mode: Data about the video mode to setup
+ */
+static void cs5530_activate_video(void *io_base, const struct video_mode *mode)
+{
+	u32 val;
+
+	val = mode->sync_pol;
+	val <<= 8;
+
+	writel(val | 0x0020002F, io_base + CS5530_DISPLAY_CONFIG);
+}
+
+/*
+ * This bitmap file must provide:
+ * int width: pixel count in one line
+ * int height: line count
+ * int colours: ount of used colour
+ * unsigned long colour_map[]: RGB 565 colours to be used
+ * unsigned char bitmap[]: index per pixel into colour_map[], width*height pixels
+ */
+#include "bitmap.c"
+
+/*
+ * show a boot splash screen in the right lower corner of the screen
+ * swidth: screen width in pixel
+ * sheight: screen height in lines
+ * pitch: line pitch in bytes
+ * base: screen base address
+ *
+ * This routine assumes we are using a 16 bit colour depth!
+ */
+static void show_boot_splash_16(u32 swidth,u32 sheight,u32 pitch,void *base)
+{
+	int word_count,i;
+	unsigned short *adr;
+	u32 xstart,ystart,x,y;
+	/*
+	 * fill the screen with the colour of the
+	 * left top pixel in the graphic
+	 */
+	word_count = pitch*sheight;
+	printk_debug("Clear Screen at %p, %d words\n",base,word_count);
+	adr = (unsigned short *) base;
+	for (i=0; i < word_count; i++, adr++)
+		*adr = colour_map[bitmap[0]];
+	printk_debug("Ready\n");
+
+	/*
+	 * paint the splash
+	 */
+	xstart=swidth-width;
+	ystart=sheight-height;
+	printk_debug("Start at %u,%u\n",xstart,ystart);
+	for (y=0;y<height;y++) {
+		adr=(unsigned short*)(base + pitch*(y+ystart)+2*xstart);
+		for (x=0;x<width;x++) {
+			*adr=(unsigned short)colour_map[(int)bitmap[x+y*width]];
+			adr++;
+		}
+	}
+}
+
+/*
+ * management part
+ */
+static void cs5530_vga_init(device_t dev)
+{
+	const struct video_mode *mode;
+	void *io_base, *gx_base;
+
+	io_base = (void*)pci_read_config32(dev,0x10);
+	gx_base = (void*)GX_BASE;
+	mode = modes[CONFIG_GX1_VIDEOMODE];
+
+	printk_debug("Setting up video mode %dx%d with %d Hz clock\n",
+		mode->visible_pixel, mode->visible_lines, mode->pixel_clock);
+
+	cs5530_set_clock_frequency(io_base,mode->pll_value);
+
+	writel(DC_UNLOCK_MAGIC, gx_base + DC_UNLOCK);
+
+	show_boot_splash_16(mode->visible_pixel, mode->visible_lines,
+		mode->visible_pixel*(COLOUR_DEPTH>>3),(void*)(GX_BASE+0x800000));
+
+	cs5530_activate_mode(gx_base,mode);
+
+	cs5530_activate_video(io_base, mode);
+	writel(0x00000000, gx_base + DC_UNLOCK);
+}
+
+static struct device_operations vga_ops = {
+	.read_resources   = pci_dev_read_resources,
+	.set_resources    = pci_dev_set_resources,
+	.enable_resources = pci_dev_enable_resources,
+	.init             = cs5530_vga_init,
+	.enable           = NULL /* not required */
+};
+
+static struct pci_driver vga_pci_driver __pci_driver = {
+	.ops 	= &vga_ops,
+	.vendor = PCI_VENDOR_ID_CYRIX,
+	.device = PCI_DEVICE_ID_CYRIX_5530_VIDEO
+};
+
+#endif /* #if CONFIG_GX1_VIDEO == 1 */
Index: LinuxBIOSv2/src/southbridge/amd/cs5530/Config.lb
===================================================================
--- LinuxBIOSv2.orig/src/southbridge/amd/cs5530/Config.lb
+++ LinuxBIOSv2/src/southbridge/amd/cs5530/Config.lb
@@ -22,3 +22,4 @@ config chip.h
 driver cs5530.o
 driver cs5530_isa.o
 driver cs5530_ide.o
+driver cs5530_vga.o
Index: LinuxBIOSv2/src/config/Options.lb
===================================================================
--- LinuxBIOSv2.orig/src/config/Options.lb
+++ LinuxBIOSv2/src/config/Options.lb
@@ -1016,7 +1016,23 @@ define CONFIG_VIDEO_MB
         comment "Integrated graphics with UMA has dynamic setup"
 end
 
+define CONFIG_GX1_VIDEO
+	default 0
+	export used
+	comment "Build in GX1's graphic support"
+end
 
+define CONFIG_GX1_VIDEOMODE
+	default none
+	export used
+	comment "Define video mode after reset"
+# could be
+# 0 for 640x480
+# 1 for 800x600
+# 2 for 1024x768
+# 3 for 1280x960
+# 4 for 1280x1024
+end
 
 ###############################################
 # Board specific options
Index: LinuxBIOSv2/src/southbridge/amd/cs5530/bitmap.c
===================================================================
--- /dev/null
+++ LinuxBIOSv2/src/southbridge/amd/cs5530/bitmap.c
@@ -0,0 +1,304 @@
+/* do not edit
+This is an image of size 51 x 60 with 234 colours */
+static const int width=51;
+static const int height=60;
+static const int colours=234;
+static const unsigned long colour_map[234] = {
+0x00000000, /* 0 */
+0x00000001, /* 1 */
+0x00000020, /* 2 */
+0x00000021, /* 3 */
+0x00000040, /* 4 */
+0x00000800, /* 5 */
+0x00000821, /* 6 */
+0x00000840, /* 7 */
+0x00000841, /* 8 */
+0x00000861, /* 9 */
+0x00001040, /* 10 */
+0x00001081, /* 11 */
+0x00001082, /* 12 */
+0x00001083, /* 13 */
+0x000010A2, /* 14 */
+0x00001881, /* 15 */
+0x000018C3, /* 16 */
+0x000018E3, /* 17 */
+0x000020A0, /* 18 */
+0x000020E4, /* 19 */
+0x00002103, /* 20 */
+0x00002104, /* 21 */
+0x00002124, /* 22 */
+0x00002921, /* 23 */
+0x00002945, /* 24 */
+0x00002946, /* 25 */
+0x00002965, /* 26 */
+0x00002966, /* 27 */
+0x00003186, /* 28 */
+0x000031A6, /* 29 */
+0x00003942, /* 30 */
+0x00003982, /* 31 */
+0x000039A7, /* 32 */
+0x000039C7, /* 33 */
+0x000039E7, /* 34 */
+0x000039E8, /* 35 */
+0x000041A2, /* 36 */
+0x000041C2, /* 37 */
+0x000041E7, /* 38 */
+0x00004207, /* 39 */
+0x00004208, /* 40 */
+0x00004228, /* 41 */
+0x00004229, /* 42 */
+0x000049E3, /* 43 */
+0x000049E5, /* 44 */
+0x00004A46, /* 45 */
+0x00004A47, /* 46 */
+0x00004A48, /* 47 */
+0x00004A49, /* 48 */
+0x00004A69, /* 49 */
+0x00004A8A, /* 50 */
+0x00005228, /* 51 */
+0x00005247, /* 52 */
+0x00005287, /* 53 */
+0x0000528A, /* 54 */
+0x000052AA, /* 55 */
+0x00005A21, /* 56 */
+0x00005A43, /* 57 */
+0x00005A63, /* 58 */
+0x00005AA9, /* 59 */
+0x00005AAA, /* 60 */
+0x00005ACA, /* 61 */
+0x00005ACB, /* 62 */
+0x00005AEB, /* 63 */
+0x00006222, /* 64 */
+0x00006261, /* 65 */
+0x000062A8, /* 66 */
+0x000062C7, /* 67 */
+0x000062E8, /* 68 */
+0x000062EB, /* 69 */
+0x000062EC, /* 70 */
+0x0000630B, /* 71 */
+0x0000630C, /* 72 */
+0x0000632C, /* 73 */
+0x00006A41, /* 74 */
+0x00006B05, /* 75 */
+0x00006B28, /* 76 */
+0x00006B29, /* 77 */
+0x00006B2D, /* 78 */
+0x00006B4D, /* 79 */
+0x00006B6D, /* 80 */
+0x00006B6E, /* 81 */
+0x00006B8D, /* 82 */
+0x000072A2, /* 83 */
+0x000072E2, /* 84 */
+0x000072E5, /* 85 */
+0x00007306, /* 86 */
+0x00007329, /* 87 */
+0x0000738E, /* 88 */
+0x000073AE, /* 89 */
+0x000073AF, /* 90 */
+0x000073CF, /* 91 */
+0x00007B28, /* 92 */
+0x00007B44, /* 93 */
+0x00007B48, /* 94 */
+0x00007B67, /* 95 */
+0x00007B69, /* 96 */
+0x00007BCE, /* 97 */
+0x00007BCF, /* 98 */
+0x00007BEF, /* 99 */
+0x00008323, /* 100 */
+0x00008345, /* 101 */
+0x000083AA, /* 102 */
+0x00008410, /* 103 */
+0x00008430, /* 104 */
+0x00008B02, /* 105 */
+0x00008B63, /* 106 */
+0x00008B83, /* 107 */
+0x00008B84, /* 108 */
+0x00008BA6, /* 109 */
+0x00008BC7, /* 110 */
+0x00008BEA, /* 111 */
+0x00008BEE, /* 112 */
+0x00008C51, /* 113 */
+0x00008C71, /* 114 */
+0x00009362, /* 115 */
+0x00009363, /* 116 */
+0x00009383, /* 117 */
+0x000093C5, /* 118 */
+0x000093C7, /* 119 */
+0x00009405, /* 120 */
+0x00009492, /* 121 */
+0x00009493, /* 122 */
+0x000094B2, /* 123 */
+0x00009B82, /* 124 */
+0x00009BC3, /* 125 */
+0x00009C2D, /* 126 */
+0x00009CB3, /* 127 */
+0x00009CD3, /* 128 */
+0x00009CF3, /* 129 */
+0x00009CF4, /* 130 */
+0x00009D14, /* 131 */
+0x0000A401, /* 132 */
+0x0000A403, /* 133 */
+0x0000A423, /* 134 */
+0x0000A44C, /* 135 */
+0x0000A489, /* 136 */
+0x0000A4F1, /* 137 */
+0x0000A514, /* 138 */
+0x0000A533, /* 139 */
+0x0000A534, /* 140 */
+0x0000ABE1, /* 141 */
+0x0000AC22, /* 142 */
+0x0000AC24, /* 143 */
+0x0000AC42, /* 144 */
+0x0000AC44, /* 145 */
+0x0000AC48, /* 146 */
+0x0000AC69, /* 147 */
+0x0000AC8A, /* 148 */
+0x0000ACEE, /* 149 */
+0x0000AD0A, /* 150 */
+0x0000AD2E, /* 151 */
+0x0000AD55, /* 152 */
+0x0000AD75, /* 153 */
+0x0000AD76, /* 154 */
+0x0000B423, /* 155 */
+0x0000B441, /* 156 */
+0x0000B444, /* 157 */
+0x0000B464, /* 158 */
+0x0000B484, /* 159 */
+0x0000B4A3, /* 160 */
+0x0000B4C4, /* 161 */
+0x0000B533, /* 162 */
+0x0000B596, /* 163 */
+0x0000B5B6, /* 164 */
+0x0000BC65, /* 165 */
+0x0000BC83, /* 166 */
+0x0000BC84, /* 167 */
+0x0000BCC9, /* 168 */
+0x0000BD03, /* 169 */
+0x0000BD2A, /* 170 */
+0x0000BD54, /* 171 */
+0x0000BD97, /* 172 */
+0x0000BDB5, /* 173 */
+0x0000BDD7, /* 174 */
+0x0000BDD8, /* 175 */
+0x0000BDF7, /* 176 */
+0x0000BE19, /* 177 */
+0x0000C4A2, /* 178 */
+0x0000C4C2, /* 179 */
+0x0000C4C3, /* 180 */
+0x0000C5CE, /* 181 */
+0x0000C5F9, /* 182 */
+0x0000C618, /* 183 */
+0x0000C61A, /* 184 */
+0x0000C638, /* 185 */
+0x0000CCE2, /* 186 */
+0x0000CD03, /* 187 */
+0x0000CD43, /* 188 */
+0x0000CD61, /* 189 */
+0x0000CD88, /* 190 */
+0x0000CE39, /* 191 */
+0x0000CE58, /* 192 */
+0x0000CE59, /* 193 */
+0x0000CE79, /* 194 */
+0x0000CE7A, /* 195 */
+0x0000CE7B, /* 196 */
+0x0000CE9A, /* 197 */
+0x0000D502, /* 198 */
+0x0000D522, /* 199 */
+0x0000D62C, /* 200 */
+0x0000D69A, /* 201 */
+0x0000D69B, /* 202 */
+0x0000D6BA, /* 203 */
+0x0000DD23, /* 204 */
+0x0000DD41, /* 205 */
+0x0000DD81, /* 206 */
+0x0000DDA1, /* 207 */
+0x0000DDA4, /* 208 */
+0x0000DE9C, /* 209 */
+0x0000DEDB, /* 210 */
+0x0000DEFB, /* 211 */
+0x0000DEFD, /* 212 */
+0x0000E5A2, /* 213 */
+0x0000E71C, /* 214 */
+0x0000E73C, /* 215 */
+0x0000EDC1, /* 216 */
+0x0000EF3E, /* 217 */
+0x0000EF5D, /* 218 */
+0x0000EF7D, /* 219 */
+0x0000EF7E, /* 220 */
+0x0000EF7F, /* 221 */
+0x0000F79D, /* 222 */
+0x0000F79E, /* 223 */
+0x0000F7BE, /* 224 */
+0x0000F7BF, /* 225 */
+0x0000F7DE, /* 226 */
+0x0000FFB8, /* 227 */
+0x0000FFBF, /* 228 */
+0x0000FFDD, /* 229 */
+0x0000FFDE, /* 230 */
+0x0000FFDF, /* 231 */
+0x0000FFFB, /* 232 */
+0x0000FFFF, /* 233 */
+};
+
+static const unsigned char bitmap[3060] = {
+0xE9,0xE9,0xE9,0xE9,0xE9,0xE9,0xE9,0xE9,0xE7,0xA4,0xD3,0xE9,0xDF,0xDF,0x8C,0xE7,0xE0,0xDF,0xB0,0xDB,0xE7,0xE0,0xE0,0xC2,0xE7,0xE7,0xE0,0xD3,0xE9,0xE9,0xE0,0xDF,0xDF,0xE7,0xE7,0xD6,0xE9,0xE9,0xE9,0xE9,0xE9,0xE9,0xE9,0xE9,0xE9,0xE9,0xE9,0xE9,0xE9,0xE9,0xE9,
+0xE9,0xE9,0xE9,0xE9,0xE0,0xDB,0xDA,0xDF,0xE9,0x67,0xA3,0xD7,0xDA,0xE9,0x71,0xD7,0xA3,0xE9,0xD6,0xD7,0xD2,0xD6,0xE9,0xC1,0xDF,0x68,0xE9,0xDA,0xE0,0x99,0xAE,0xE9,0xD7,0xB9,0xE9,0xA3,0xDF,0xE0,0xE7,0xE7,0xE7,0xE9,0xE9,0xE9,0xE9,0xE9,0xE9,0xE9,0xE9,0xE9,0xE9,
+0xE9,0xE9,0xE9,0xD6,0x71,0x67,0x63,0x72,0xE9,0x31,0x4F,0x58,0x99,0xD6,0x1D,0x67,0x50,0xB7,0x67,0x36,0x4F,0x99,0xD6,0x28,0x49,0x3F,0xDB,0x71,0x48,0x48,0x80,0xDB,0x37,0x48,0xE9,0x8C,0x58,0x68,0xDA,0xDB,0xDF,0xE0,0xE7,0xE9,0xE9,0xE9,0xE9,0xE9,0xE9,0xE9,0xE9,
+0xE9,0xE9,0xE9,0x79,0x63,0x63,0x58,0x29,0x7B,0x1A,0x28,0x30,0x30,0x63,0x0C,0x50,0x10,0x50,0x28,0x21,0x1D,0x31,0x62,0x11,0x36,0x10,0x68,0x30,0x30,0x16,0x3E,0x68,0x15,0x29,0x8C,0x3E,0x11,0x36,0x4F,0xC2,0xD7,0xDA,0xDF,0xE7,0xE7,0xE9,0xE9,0xE9,0xE9,0xE9,0xE9,
+0xE9,0xE9,0xE7,0x62,0x62,0x63,0x63,0x22,0x37,0x16,0x28,0x36,0x1C,0x28,0x0C,0x49,0x15,0x29,0x16,0x21,0x1D,0x22,0x22,0x0C,0x31,0x11,0x29,0x15,0x21,0x15,0x22,0x22,0x10,0x22,0x48,0x1D,0x08,0x3E,0x29,0x3E,0xB9,0xD2,0xD7,0xDB,0xE0,0xE7,0xE9,0xE9,0xE9,0xE9,0xE9,
+0xE9,0xE9,0xDB,0x62,0x4F,0x4F,0x3F,0x30,0x21,0x15,0x28,0x31,0x22,0x1A,0x0C,0x50,0x18,0x1D,0x0E,0x29,0x1D,0x22,0x16,0x10,0x37,0x1D,0x1D,0x0C,0x28,0x1A,0x29,0x1A,0x18,0x21,0x21,0x16,0x0E,0x3E,0x29,0x30,0x48,0xB0,0xC9,0xD3,0xDB,0xE0,0xE7,0xE9,0xE9,0xE9,0xE9,
+0xE9,0xE9,0xE7,0xA3,0x72,0x21,0x15,0x31,0x36,0x30,0x49,0x36,0x3F,0x29,0x30,0x4F,0x29,0x36,0x21,0x3F,0x28,0x30,0x1A,0x28,0x3E,0x22,0x18,0x16,0x3E,0x1D,0x21,0x11,0x22,0x21,0x10,0x11,0x37,0x11,0x15,0x28,0x48,0x80,0xA4,0xC1,0xD3,0xDA,0xE0,0xE7,0xE9,0xE9,0xE9,
+0xE9,0xD3,0xE9,0xE9,0xE9,0xB7,0x59,0x22,0x58,0x48,0x48,0x48,0x37,0x37,0x3E,0x36,0x36,0x36,0x36,0x37,0x31,0x36,0x36,0x37,0x36,0x30,0x29,0x31,0x36,0x30,0x31,0x31,0x31,0x30,0x30,0x37,0x15,0x15,0xC1,0xE9,0xE9,0x8A,0x59,0x99,0xC1,0xD3,0xDB,0xE0,0xE9,0xE9,0xE9,
+0xE9,0x68,0x50,0x1C,0x16,0x31,0x30,0x1A,0x58,0x49,0x3F,0x3E,0x3E,0x37,0x36,0x37,0x31,0x30,0x30,0x31,0x36,0x30,0x29,0x29,0x29,0x29,0x28,0x28,0x29,0x22,0x28,0x22,0x29,0x29,0x30,0x31,0x15,0x1C,0x59,0x50,0x36,0x36,0x49,0x7B,0xA3,0xC2,0xD6,0xDB,0xE7,0xE9,0xE9,
+0xE9,0xA4,0x50,0x58,0x36,0x29,0x37,0x4F,0x50,0x3F,0x3E,0x31,0x31,0x31,0x36,0x36,0x36,0x31,0x30,0x30,0x29,0x30,0x30,0x29,0x28,0x22,0x28,0x28,0x22,0x28,0x22,0x21,0x22,0x22,0x22,0x36,0x28,0x29,0x1A,0x15,0x0C,0x1A,0x37,0x63,0x80,0xAE,0xC9,0xD7,0xDF,0xE7,0xE9,
+0xE9,0xE7,0xC9,0x80,0x28,0x16,0x15,0x15,0x49,0x37,0x37,0x37,0x30,0x30,0x29,0x30,0x31,0x30,0x29,0x29,0x28,0x36,0x28,0x28,0x48,0x29,0x21,0x22,0x28,0x21,0x21,0x22,0x1D,0x22,0x22,0x30,0x21,0x16,0x1C,0x21,0x31,0x31,0x37,0x4F,0x68,0x8C,0xB7,0xD3,0xDB,0xE7,0xE9,
+0xE9,0xC2,0xE9,0xDA,0xB0,0x4F,0x1D,0x1D,0x4F,0x37,0x31,0x36,0x36,0x30,0x30,0x30,0x31,0x29,0x30,0x28,0x36,0x81,0x50,0x15,0x0C,0x31,0x28,0x21,0x22,0x22,0x22,0x21,0x22,0x21,0x1D,0x28,0x0E,0x11,0x81,0xDF,0xE0,0x80,0x36,0x3E,0x59,0x7B,0xA4,0xC9,0xDA,0xE0,0xE9,
+0xE7,0x72,0x67,0x3E,0x37,0x36,0x16,0x28,0x49,0x37,0x36,0x30,0x30,0x30,0x29,0x30,0x29,0x30,0x22,0x28,0x49,0xB7,0xB9,0x99,0x29,0x0E,0x31,0x28,0x1D,0x21,0x22,0x1D,0x1D,0x22,0x21,0x28,0x11,0x22,0x8C,0x98,0x8A,0x4F,0x30,0x36,0x4F,0x71,0x99,0xC2,0xD7,0xE0,0xE7,
+0xDF,0x80,0x3E,0x18,0x10,0x21,0x31,0x3F,0x48,0x36,0x36,0x30,0x30,0x29,0x30,0x30,0x30,0x29,0x28,0x28,0x50,0xA4,0x8C,0x98,0xA4,0x3E,0x10,0x31,0x22,0x22,0x1D,0x1D,0x22,0x21,0x22,0x22,0x18,0x30,0x10,0x09,0x08,0x0C,0x1D,0x30,0x49,0x68,0x98,0xC1,0xD6,0xDF,0xE7,
+0xE9,0xE7,0xB0,0x50,0x22,0x28,0x22,0x28,0x3E,0x36,0x31,0x30,0x30,0x30,0x29,0x29,0x29,0x28,0x29,0x28,0x4F,0x80,0x48,0x48,0x63,0x98,0x3F,0x16,0x29,0x21,0x1D,0x21,0x21,0x1D,0x21,0x22,0x1D,0x21,0x29,0x31,0x1D,0x1A,0x22,0x30,0x48,0x67,0x8C,0xB9,0xD6,0xDF,0xE7,
+0xDF,0xD3,0xE9,0xD7,0x81,0x31,0x10,0x16,0x3E,0x36,0x31,0x30,0x29,0x30,0x29,0x29,0x28,0x28,0x28,0x28,0x37,0x67,0x48,0x48,0x47,0x50,0x7B,0x36,0x1A,0x30,0x1D,0x1D,0x1D,0x21,0x21,0x21,0x10,0x15,0x63,0xC1,0xC1,0x62,0x31,0x30,0x48,0x67,0x8C,0xB9,0xD6,0xDF,0xE7,
+0xE0,0x8A,0xAE,0x67,0x4F,0x37,0x18,0x22,0x3F,0x36,0x30,0x30,0x29,0x22,0x29,0x29,0x22,0x28,0x28,0x21,0x29,0x61,0x47,0x47,0x48,0x48,0x4F,0x79,0x31,0x22,0x37,0x1D,0x1D,0x1D,0x1C,0x21,0x15,0x36,0xC1,0xD6,0xB7,0x59,0x28,0x30,0x48,0x63,0x8A,0xB9,0xD6,0xDF,0xE7,
+0xD2,0x59,0x36,0x10,0x0C,0x1C,0x15,0x29,0x3F,0x30,0x36,0x30,0x30,0x28,0x22,0x1D,0x28,0x31,0x22,0x21,0x22,0x3E,0x48,0x48,0x48,0x48,0x48,0x50,0x68,0x30,0x30,0x28,0x1D,0x1C,0x21,0x1D,0x11,0x1C,0x0C,0x00,0x02,0x09,0x21,0x30,0x48,0x63,0x8A,0xB9,0xD6,0xDF,0xE7,
+0xE9,0xDB,0x80,0x4F,0x30,0x3E,0x48,0x49,0x36,0x30,0x31,0x30,0x29,0x22,0x2E,0x2D,0x4C,0x6D,0x76,0x94,0x4D,0x31,0x4E,0x48,0x47,0x48,0x48,0x48,0x50,0x62,0x30,0x37,0x1D,0x1D,0x1D,0x1D,0x21,0x29,0x22,0x21,0x1C,0x16,0x21,0x30,0x48,0x63,0x8C,0xB9,0xD6,0xDF,0xE7,
+0xE7,0xE0,0xB9,0x72,0x1D,0x16,0x10,0x16,0x36,0x29,0x29,0x30,0x29,0x44,0xB5,0xC8,0x5D,0x6E,0x9E,0x9D,0x78,0x5F,0x70,0x46,0x47,0x47,0x48,0x3F,0x3F,0x58,0x4F,0x36,0x36,0x1A,0x1A,0x1C,0x15,0x10,0x1D,0x49,0x63,0x37,0x36,0x30,0x48,0x67,0x8C,0xB9,0xD6,0xDF,0xE7,
+0xDA,0xAE,0xE9,0xC2,0x8A,0x3F,0x1A,0x21,0x31,0x29,0x29,0x28,0x29,0x89,0xE5,0xE3,0xAA,0x66,0x38,0x4A,0x41,0x40,0x5C,0x45,0x3E,0x3E,0x3E,0x3E,0x3E,0x3F,0x58,0x48,0x48,0x31,0x18,0x21,0x10,0x21,0xD7,0xE9,0xE7,0x80,0x30,0x30,0x48,0x67,0x8C,0xB9,0xD6,0xDF,0xE7,
+0xD2,0x62,0x62,0x29,0x28,0x28,0x11,0x22,0x36,0x28,0x28,0x28,0x29,0x7E,0xE4,0xE8,0x96,0x3A,0x86,0x8E,0x85,0x75,0x53,0x57,0x3C,0x37,0x37,0x37,0x37,0x37,0x3E,0x4F,0x49,0x4F,0x1C,0x1C,0x16,0x1D,0x31,0x31,0x22,0x1D,0x21,0x30,0x48,0x67,0x8C,0xB9,0xD6,0xDF,0xE7,
+0xDA,0xB0,0x62,0x16,0x10,0x21,0x31,0x48,0x37,0x28,0x28,0x3B,0x6F,0x78,0x95,0x97,0x64,0xA1,0xCF,0xCE,0xC6,0xBB,0x90,0x65,0x3B,0x32,0x36,0x36,0x36,0x31,0x36,0x3F,0x4F,0x4F,0x37,0x1C,0x18,0x22,0x16,0x10,0x0E,0x0C,0x1D,0x30,0x48,0x63,0x8C,0xB9,0xD6,0xDF,0xE7,
+0xE9,0xE0,0x98,0x37,0x1C,0x22,0x22,0x21,0x30,0x31,0x88,0xA5,0xA7,0xB2,0x9F,0x91,0x9F,0xB4,0xC7,0xD0,0x9C,0xA6,0x7C,0x73,0x60,0x30,0x30,0x30,0x30,0x30,0x30,0x30,0x3F,0x58,0x49,0x1C,0x1A,0x1D,0x1D,0x1C,0x21,0x1D,0x22,0x30,0x48,0x63,0x8A,0xB9,0xD6,0xDF,0xE7,
+0xDF,0xD6,0xDA,0x8A,0x49,0x21,0x11,0x18,0x30,0x29,0x35,0x34,0x42,0x2B,0x24,0x1F,0x17,0x25,0x39,0x55,0x54,0x6B,0x69,0x7D,0x5E,0x3C,0x22,0x10,0x1C,0x28,0x28,0x29,0x30,0x3F,0x63,0x3F,0x10,0x10,0x67,0xB9,0xC9,0x72,0x48,0x36,0x3F,0x63,0x8A,0xB9,0xD6,0xDF,0xE7,
+0xD6,0xA4,0xDB,0x98,0x68,0x31,0x1A,0x21,0x30,0x22,0x21,0x22,0x21,0x13,0x7F,0x4E,0x02,0x18,0x98,0xAF,0x19,0x0A,0x12,0x43,0x27,0x30,0x16,0x00,0x0E,0x1D,0x22,0x22,0x28,0x29,0x58,0x67,0x1C,0x1D,0xA3,0xD3,0xB9,0x67,0x29,0x30,0x3F,0x63,0x8A,0xB9,0xD3,0xDF,0xE7,
+0xC1,0x62,0x30,0x0C,0x0E,0x1A,0x15,0x28,0x29,0x22,0x21,0x1C,0x2F,0x2F,0x51,0x9A,0x11,0x52,0x58,0x48,0x7A,0x02,0x05,0x30,0x1C,0x21,0x22,0x02,0x00,0x16,0x1D,0x21,0x21,0x22,0x36,0x72,0x48,0x18,0x02,0x00,0x02,0x08,0x1A,0x29,0x3F,0x63,0x8A,0xB7,0xD3,0xDF,0xE7,
+0xE9,0xE0,0xAE,0x1D,0x1A,0x30,0x49,0x48,0x22,0x21,0x1D,0x21,0x29,0x23,0x33,0x56,0x74,0x77,0x2C,0x18,0x83,0x02,0x03,0x30,0x21,0x1A,0x22,0x09,0x00,0x0E,0x1C,0x1C,0x1D,0x1D,0x21,0x59,0x79,0x29,0x22,0x21,0x1C,0x18,0x21,0x30,0x3F,0x62,0x81,0xB7,0xD3,0xDF,0xE7,
+0xE7,0xDA,0x98,0x3F,0x11,0x15,0x0E,0x16,0x29,0x21,0x1D,0x1D,0x29,0x14,0x93,0xCC,0xB3,0x84,0xA0,0xBE,0x4B,0x02,0x01,0x28,0x1D,0x1D,0x1D,0x18,0x00,0x02,0x18,0x1A,0x1C,0x1A,0x1C,0x29,0x81,0x15,0x30,0x62,0x7B,0x48,0x3E,0x36,0x3F,0x62,0x81,0xB7,0xD3,0xDB,0xE7,
+0xD7,0xC2,0xE9,0xB0,0x71,0x31,0x15,0x1C,0x28,0x21,0x1D,0x1D,0x28,0x1E,0xA6,0xD8,0xBD,0xA9,0xBC,0xC7,0x6A,0x04,0x02,0x20,0x1A,0x1C,0x1C,0x18,0x00,0x00,0x11,0x18,0x18,0x18,0x18,0x1A,0x68,0x1C,0xD2,0xE9,0xE9,0x80,0x36,0x29,0x3E,0x62,0x80,0xB0,0xD2,0xDB,0xE7,
+0xC1,0x79,0x72,0x3F,0x31,0x21,0x0E,0x1D,0x28,0x1C,0x1D,0x1A,0x30,0x0F,0x6C,0xCD,0xD5,0xBA,0x8D,0xA8,0x57,0x0E,0x2A,0x10,0x21,0x1C,0x48,0x02,0x00,0x00,0x0E,0x16,0x16,0x16,0x16,0x18,0x31,0x18,0x18,0x15,0x11,0x10,0x1C,0x29,0x3E,0x59,0x80,0xB0,0xD2,0xDB,0xE7,
+0xDA,0xD2,0x72,0x0E,0x0C,0x1D,0x30,0x37,0x22,0x1C,0x1D,0x1C,0x30,0x06,0xA2,0x92,0x9B,0x8F,0x87,0xBF,0xB1,0x0D,0x1B,0x09,0x1A,0x37,0x1A,0x02,0x00,0x00,0x10,0x18,0x16,0x16,0x16,0x18,0x11,0x21,0x18,0x11,0x11,0x11,0x1D,0x29,0x3E,0x59,0x80,0xB0,0xD2,0xDB,0xE7,
+0xE9,0xE0,0x99,0x37,0x1A,0x22,0x21,0x21,0x22,0x1D,0x1C,0x29,0x1D,0x16,0xAE,0xAC,0xAB,0xAD,0xD1,0xDD,0xD6,0x46,0x02,0x04,0x0B,0x0E,0x00,0x00,0x00,0x00,0x1D,0x1C,0x18,0x18,0x16,0x18,0x10,0x1A,0x1D,0x30,0x30,0x30,0x29,0x29,0x3E,0x59,0x80,0xB0,0xD2,0xDB,0xE7,
+0xDF,0xB9,0x98,0x62,0x22,0x1A,0x0C,0x16,0x22,0x1C,0x21,0x26,0x09,0x5B,0x8B,0xC5,0xCA,0xDC,0xE2,0xC0,0x72,0x7B,0x07,0x07,0x03,0x00,0x00,0x00,0x00,0x0C,0x18,0x1D,0x1C,0x18,0x18,0x18,0x10,0x3F,0xD6,0xE9,0xD3,0x59,0x29,0x29,0x3E,0x59,0x80,0xB0,0xD2,0xDB,0xE7,
+0xCB,0xB0,0xE9,0xAE,0x72,0x30,0x11,0x1D,0x22,0x22,0x11,0x09,0x21,0xCB,0xCB,0xE0,0xE7,0xE9,0xDE,0x99,0x79,0xB7,0x1C,0x03,0x01,0x00,0x00,0x00,0x02,0x1A,0x15,0x15,0x21,0x1C,0x18,0x18,0x0E,0x31,0x67,0x62,0x29,0x1A,0x28,0x29,0x3E,0x62,0x81,0xB0,0xD3,0xDB,0xE7,
+0xB9,0x8A,0x4F,0x11,0x10,0x18,0x0E,0x21,0x29,0x11,0x18,0x10,0x3F,0xCB,0xD2,0xD7,0xDC,0xE9,0xE6,0xC9,0xB6,0xB8,0x5A,0x01,0x00,0x00,0x00,0x00,0x08,0x29,0x29,0x16,0x15,0x1A,0x1A,0x15,0x02,0x0E,0x08,0x00,0x08,0x09,0x1D,0x29,0x3E,0x62,0x81,0xB7,0xD3,0xDB,0xE7,
+0xE9,0xE0,0x98,0x15,0x11,0x1D,0x3E,0x37,0x02,0x0E,0x1C,0x02,0x8A,0xA3,0x71,0xB7,0xE1,0xE9,0xE6,0xDC,0xD9,0xD4,0xC4,0x28,0x02,0x00,0x00,0x09,0x02,0x00,0x00,0x02,0x0C,0x16,0x30,0x21,0x0E,0x21,0x28,0x21,0x1D,0x1A,0x22,0x29,0x3F,0x62,0x81,0xB7,0xD3,0xDF,0xE7,
+0xE9,0xC1,0x67,0x28,0x0E,0x11,0x10,0x16,0x02,0x00,0x08,0x00,0x48,0x8C,0x8C,0xC3,0xDF,0xE0,0xD3,0x7B,0x82,0xCB,0xC9,0x71,0x01,0x00,0x09,0x0C,0x00,0x00,0x00,0x00,0x00,0x00,0x08,0x1C,0x18,0x28,0x98,0xDF,0xC1,0x58,0x3E,0x29,0x3F,0x62,0x81,0xB7,0xD3,0xDF,0xE7,
+0xD6,0xB9,0xD7,0x8C,0x59,0x31,0x10,0x1A,0x0C,0x00,0x00,0x00,0x02,0x18,0x1C,0x21,0x31,0x37,0x31,0x1A,0x1D,0x37,0x3D,0x28,0x03,0x00,0x0C,0x02,0x00,0x02,0x09,0x0E,0x0C,0x10,0x18,0x18,0x15,0x4F,0xC1,0xC9,0x71,0x30,0x21,0x29,0x3F,0x62,0x8A,0xB7,0xD3,0xDF,0xE7,
+0xC2,0x8A,0xAE,0x63,0x49,0x28,0x09,0x1C,0x22,0x16,0x08,0x00,0x00,0x0C,0x18,0x11,0x10,0x10,0x0C,0x09,0x0C,0x0E,0x0E,0x10,0x11,0x15,0x1A,0x22,0x1C,0x1A,0x1D,0x1A,0x11,0x16,0x15,0x16,0x10,0x0C,0x00,0x00,0x00,0x00,0x1A,0x29,0x3F,0x62,0x81,0xB7,0xD3,0xDF,0xE7,
+0xDB,0xDA,0x72,0x08,0x09,0x16,0x22,0x31,0x21,0x18,0x1A,0x16,0x08,0x09,0x15,0x18,0x11,0x16,0x16,0x15,0x11,0x11,0x16,0x16,0x15,0x15,0x11,0x11,0x11,0x15,0x15,0x15,0x11,0x11,0x15,0x18,0x15,0x1C,0x18,0x16,0x1D,0x18,0x21,0x29,0x3E,0x62,0x81,0xB7,0xD3,0xDF,0xE7,
+0xE9,0xDF,0x8A,0x1D,0x15,0x1A,0x1C,0x21,0x22,0x1C,0x16,0x16,0x18,0x18,0x18,0x16,0x16,0x18,0x15,0x15,0x15,0x16,0x16,0x15,0x15,0x15,0x16,0x15,0x11,0x11,0x15,0x11,0x11,0x16,0x16,0x1A,0x16,0x16,0x58,0xC1,0xAE,0x59,0x3E,0x30,0x3E,0x62,0x81,0xB7,0xD3,0xDF,0xE7,
+0xE7,0x98,0x50,0x36,0x16,0x18,0x09,0x18,0x28,0x1D,0x1A,0x16,0x16,0x16,0x16,0x16,0x16,0x16,0x16,0x15,0x16,0x16,0x15,0x16,0x15,0x15,0x11,0x11,0x11,0x15,0x15,0x15,0x11,0x11,0x11,0x1A,0x15,0x31,0xD2,0xCB,0x59,0x29,0x22,0x29,0x3E,0x59,0x80,0xB0,0xD3,0xDB,0xE7,
+0xCB,0xB0,0xDB,0xA4,0x68,0x31,0x10,0x1C,0x28,0x21,0x1C,0x1A,0x16,0x18,0x18,0x1C,0x16,0x18,0x15,0x16,0x18,0x11,0x11,0x15,0x15,0x11,0x11,0x11,0x15,0x11,0x10,0x11,0x15,0x15,0x18,0x1C,0x15,0x18,0x15,0x00,0x02,0x09,0x08,0x21,0x3E,0x59,0x80,0xB0,0xD2,0xDB,0xE7,
+0xC9,0xC1,0x80,0x36,0x21,0x1A,0x10,0x29,0x16,0x11,0x1A,0x0E,0x0C,0x15,0x11,0x1A,0x09,0x0E,0x11,0x16,0x10,0x09,0x0E,0x0E,0x16,0x08,0x09,0x0C,0x11,0x0E,0x08,0x0E,0x0C,0x16,0x08,0x0E,0x18,0x18,0x0C,0x08,0x15,0x16,0x1C,0x28,0x37,0x59,0x80,0xB0,0xD2,0xDB,0xE7,
+0xE9,0xE0,0x81,0x0C,0x09,0x1A,0x29,0x08,0x0E,0x10,0x1C,0x0E,0x0C,0x11,0x16,0x1C,0x02,0x10,0x0E,0x1C,0x10,0x09,0x0E,0x10,0x1A,0x02,0x0E,0x0C,0x18,0x0E,0x09,0x0E,0x10,0x18,0x08,0x10,0x0C,0x18,0x18,0x16,0x10,0x16,0x21,0x29,0x37,0x58,0x7B,0xAE,0xD2,0xDB,0xE7,
+0xE9,0xE0,0x99,0x21,0x1D,0x21,0x1C,0x50,0x72,0x1A,0x1D,0x11,0x71,0x72,0x1A,0x1C,0x16,0x99,0x30,0x1C,0x11,0x59,0x80,0x18,0x1A,0x15,0xA4,0x37,0x18,0x10,0x58,0xAE,0x15,0x18,0x15,0xCB,0x49,0x18,0x11,0x10,0x11,0x16,0x21,0x29,0x3E,0x59,0x80,0xAE,0xD2,0xDB,0xE7,
+0xE9,0xE0,0xA3,0x1A,0x21,0x22,0x21,0xB9,0xCB,0x15,0x22,0x15,0xCB,0xC9,0x11,0x1D,0x22,0xE9,0x50,0x18,0x11,0x98,0xE7,0x10,0x1C,0x15,0xE9,0x68,0x16,0x10,0x71,0xE9,0x16,0x1A,0x10,0xE7,0x67,0x16,0x15,0x15,0x11,0x18,0x22,0x29,0x3E,0x62,0x80,0xB0,0xD2,0xDB,0xE7,
+0xE9,0xE7,0xA3,0x1D,0x1C,0x28,0x30,0xDF,0xCB,0x1D,0x29,0x28,0xE0,0xD2,0x1A,0x22,0x50,0xE9,0x62,0x21,0x21,0xB0,0xE9,0x16,0x1C,0x29,0xE0,0x79,0x1C,0x1C,0x71,0xDB,0x21,0x18,0x21,0xB9,0x79,0x1A,0x15,0x11,0x10,0x18,0x22,0x30,0x48,0x63,0x8A,0xB9,0xD3,0xDF,0xE7,
+0xE9,0xE7,0xD6,0x48,0x1C,0x31,0x18,0x7B,0x59,0x0C,0x16,0x18,0x62,0x50,0x0C,0x16,0x21,0x72,0x28,0x10,0x11,0x48,0x71,0x09,0x10,0x16,0x71,0x36,0x0E,0x0E,0x30,0x50,0x11,0x0E,0x0C,0x49,0x30,0x10,0x0C,0x08,0x10,0x1D,0x28,0x36,0x49,0x68,0x98,0xC2,0xD7,0xDF,0xE7,
+0xE9,0xE9,0xE0,0xDA,0xC9,0xAE,0x7B,0x49,0x28,0x10,0x22,0x22,0x28,0x22,0x15,0x21,0x1D,0x30,0x1C,0x1D,0x1C,0x22,0x22,0x18,0x1D,0x16,0x31,0x21,0x21,0x15,0x29,0x31,0x1D,0x1A,0x1A,0x29,0x1C,0x21,0x21,0x1D,0x22,0x28,0x30,0x3E,0x58,0x79,0xA4,0xCB,0xDA,0xE0,0xE9,
+0xE9,0xE9,0xE7,0xDF,0xD3,0xB9,0x98,0x59,0x36,0x22,0x31,0x3F,0x49,0x1D,0x21,0x28,0x67,0x1D,0x1C,0x22,0x29,0x4F,0x1A,0x1D,0x28,0x58,0x1C,0x1A,0x22,0x29,0x4F,0x1A,0x21,0x28,0x59,0x1C,0x22,0x28,0x28,0x28,0x29,0x31,0x37,0x4F,0x67,0x8A,0xB7,0xD3,0xDB,0xE7,0xE9,
+0xE9,0xE9,0xE7,0xE0,0xD7,0xC9,0xAE,0x81,0x67,0x58,0x48,0x3E,0x37,0x36,0x36,0x36,0x36,0x36,0x31,0x31,0x31,0x31,0x31,0x31,0x31,0x31,0x31,0x31,0x31,0x31,0x31,0x31,0x31,0x31,0x31,0x31,0x31,0x36,0x36,0x36,0x3E,0x48,0x50,0x63,0x7B,0xA3,0xC2,0xD7,0xDF,0xE7,0xE9,
+0xE9,0xE9,0xE9,0xE7,0xDB,0xD3,0xC1,0xA4,0x81,0x72,0x63,0x59,0x50,0x50,0x4F,0x4F,0x4F,0x4F,0x49,0x49,0x49,0x49,0x49,0x49,0x49,0x49,0x49,0x49,0x49,0x49,0x49,0x49,0x49,0x49,0x49,0x49,0x49,0x49,0x4F,0x50,0x58,0x63,0x71,0x80,0x99,0xB9,0xD2,0xDB,0xE0,0xE9,0xE9,
+0xE9,0xE9,0xE9,0xE7,0xE0,0xDA,0xD3,0xC2,0xB0,0x99,0x8A,0x7B,0x79,0x72,0x71,0x71,0x71,0x71,0x68,0x68,0x68,0x68,0x68,0x68,0x68,0x68,0x67,0x67,0x67,0x67,0x67,0x67,0x68,0x68,0x68,0x68,0x68,0x71,0x71,0x72,0x7B,0x8A,0x99,0xAE,0xC1,0xD2,0xDA,0xDF,0xE7,0xE9,0xE9,
+0xE9,0xE9,0xE9,0xE9,0xE7,0xE0,0xDB,0xD6,0xD2,0xC2,0xB7,0xAE,0xA3,0x99,0x99,0x99,0x99,0x98,0x98,0x98,0x98,0x98,0x98,0x98,0x98,0x8C,0x8C,0x8C,0x8C,0x8C,0x8C,0x8C,0x8C,0x98,0x98,0x98,0x98,0x98,0x99,0xA3,0xA4,0xB7,0xC2,0xCB,0xD6,0xDA,0xDF,0xE7,0xE9,0xE9,0xE9,
+0xE9,0xE9,0xE9,0xE9,0xE9,0xE7,0xE0,0xDF,0xDA,0xD7,0xD3,0xCB,0xC9,0xC2,0xC2,0xC2,0xC2,0xC1,0xC1,0xC1,0xC1,0xC1,0xC1,0xC1,0xC1,0xC1,0xB9,0xB9,0xB9,0xB9,0xB9,0xB9,0xC1,0xC1,0xC1,0xC1,0xC1,0xC1,0xC2,0xC2,0xCB,0xD3,0xD7,0xDA,0xDF,0xE0,0xE7,0xE9,0xE9,0xE9,0xE9,
+0xE9,0xE9,0xE9,0xE9,0xE9,0xE9,0xE9,0xE7,0xE0,0xDF,0xDB,0xDA,0xDA,0xD7,0xD7,0xD7,0xD7,0xD6,0xD6,0xD6,0xD6,0xD6,0xD6,0xD6,0xD6,0xD6,0xD6,0xD6,0xD6,0xD6,0xD6,0xD6,0xD6,0xD6,0xD6,0xD6,0xD6,0xD7,0xD7,0xD7,0xDA,0xDB,0xDF,0xE0,0xE7,0xE7,0xE9,0xE9,0xE9,0xE9,0xE9,
+0xE9,0xE9,0xE9,0xE9,0xE9,0xE9,0xE9,0xE9,0xE9,0xE7,0xE7,0xE0,0xE0,0xE0,0xE0,0xE0,0xDF,0xDF,0xDF,0xDF,0xDF,0xDF,0xDF,0xDF,0xDF,0xDF,0xDF,0xDF,0xDF,0xDF,0xDF,0xDF,0xDF,0xDF,0xDF,0xDF,0xDF,0xDF,0xDF,0xE0,0xE0,0xE7,0xE7,0xE9,0xE9,0xE9,0xE9,0xE9,0xE9,0xE9,0xE9,
+0xE9,0xE9,0xE9,0xE9,0xE9,0xE9,0xE9,0xE9,0xE9,0xE9,0xE9,0xE9,0xE9,0xE9,0xE7,0xE7,0xE7,0xE7,0xE7,0xE7,0xE7,0xE7,0xE7,0xE7,0xE7,0xE7,0xE7,0xE7,0xE7,0xE7,0xE7,0xE7,0xE7,0xE7,0xE7,0xE7,0xE7,0xE7,0xE7,0xE9,0xE9,0xE9,0xE9,0xE9,0xE9,0xE9,0xE9,0xE9,0xE9,0xE9,0xE9,
+};




From svn at openbios.org  Fri Oct  5 23:00:10 2007
From: svn at openbios.org (svn at openbios.org)
Date: Fri,  5 Oct 2007 23:00:10 +0200
Subject: [LinuxBIOS] r2827 - in trunk/LinuxBIOSv2/src: config
	southbridge/amd/cs5530
Message-ID: <mailman.702.1355071173.16123.coreboot@coreboot.org>

Author: rminnich
Date: 2007-10-05 23:00:10 +0200 (Fri, 05 Oct 2007)
New Revision: 2827

Added:
   trunk/LinuxBIOSv2/src/southbridge/amd/cs5530/bitmap.c
   trunk/LinuxBIOSv2/src/southbridge/amd/cs5530/cs5530_vga.c
Modified:
   trunk/LinuxBIOSv2/src/config/Options.lb
   trunk/LinuxBIOSv2/src/southbridge/amd/cs5530/Config.lb
Log:

This patch will add support for the Geode GX1/CS5530 VGA feature. It's able
to set up one of five screen resolutions (sorry no autodetection at runtime,
resolution is selected at buildtime) and displays a graphic in the right
bottom corner (splash screen).

Signed-off-by: Juergen Beisert <juergen127 at kreuzholzen.de>
Acked-by: Ronald G. Minnich <rminnich at gmail.com>
Acked-by: Stefan Reinauer <stepan at coresystems.de>




Modified: trunk/LinuxBIOSv2/src/config/Options.lb
===================================================================
--- trunk/LinuxBIOSv2/src/config/Options.lb	2007-10-05 15:11:38 UTC (rev 2826)
+++ trunk/LinuxBIOSv2/src/config/Options.lb	2007-10-05 21:00:10 UTC (rev 2827)
@@ -1016,7 +1016,23 @@
         comment "Integrated graphics with UMA has dynamic setup"
 end
 
+define CONFIG_GX1_VIDEO
+	default 0
+	export used
+	comment "Build in GX1's graphic support"
+end
 
+define CONFIG_GX1_VIDEOMODE
+	default none
+	export used
+	comment "Define video mode after reset"
+# could be
+# 0 for 640x480
+# 1 for 800x600
+# 2 for 1024x768
+# 3 for 1280x960
+# 4 for 1280x1024
+end
 
 ###############################################
 # Board specific options

Modified: trunk/LinuxBIOSv2/src/southbridge/amd/cs5530/Config.lb
===================================================================
--- trunk/LinuxBIOSv2/src/southbridge/amd/cs5530/Config.lb	2007-10-05 15:11:38 UTC (rev 2826)
+++ trunk/LinuxBIOSv2/src/southbridge/amd/cs5530/Config.lb	2007-10-05 21:00:10 UTC (rev 2827)
@@ -22,3 +22,4 @@
 driver cs5530.o
 driver cs5530_isa.o
 driver cs5530_ide.o
+driver cs5530_vga.o

Added: trunk/LinuxBIOSv2/src/southbridge/amd/cs5530/bitmap.c
===================================================================
--- trunk/LinuxBIOSv2/src/southbridge/amd/cs5530/bitmap.c	                        (rev 0)
+++ trunk/LinuxBIOSv2/src/southbridge/amd/cs5530/bitmap.c	2007-10-05 21:00:10 UTC (rev 2827)
@@ -0,0 +1,304 @@
+/* do not edit
+This is an image of size 51 x 60 with 234 colours */
+static const int width=51;
+static const int height=60;
+static const int colours=234;
+static const unsigned long colour_map[234] = {
+0x00000000, /* 0 */
+0x00000001, /* 1 */
+0x00000020, /* 2 */
+0x00000021, /* 3 */
+0x00000040, /* 4 */
+0x00000800, /* 5 */
+0x00000821, /* 6 */
+0x00000840, /* 7 */
+0x00000841, /* 8 */
+0x00000861, /* 9 */
+0x00001040, /* 10 */
+0x00001081, /* 11 */
+0x00001082, /* 12 */
+0x00001083, /* 13 */
+0x000010A2, /* 14 */
+0x00001881, /* 15 */
+0x000018C3, /* 16 */
+0x000018E3, /* 17 */
+0x000020A0, /* 18 */
+0x000020E4, /* 19 */
+0x00002103, /* 20 */
+0x00002104, /* 21 */
+0x00002124, /* 22 */
+0x00002921, /* 23 */
+0x00002945, /* 24 */
+0x00002946, /* 25 */
+0x00002965, /* 26 */
+0x00002966, /* 27 */
+0x00003186, /* 28 */
+0x000031A6, /* 29 */
+0x00003942, /* 30 */
+0x00003982, /* 31 */
+0x000039A7, /* 32 */
+0x000039C7, /* 33 */
+0x000039E7, /* 34 */
+0x000039E8, /* 35 */
+0x000041A2, /* 36 */
+0x000041C2, /* 37 */
+0x000041E7, /* 38 */
+0x00004207, /* 39 */
+0x00004208, /* 40 */
+0x00004228, /* 41 */
+0x00004229, /* 42 */
+0x000049E3, /* 43 */
+0x000049E5, /* 44 */
+0x00004A46, /* 45 */
+0x00004A47, /* 46 */
+0x00004A48, /* 47 */
+0x00004A49, /* 48 */
+0x00004A69, /* 49 */
+0x00004A8A, /* 50 */
+0x00005228, /* 51 */
+0x00005247, /* 52 */
+0x00005287, /* 53 */
+0x0000528A, /* 54 */
+0x000052AA, /* 55 */
+0x00005A21, /* 56 */
+0x00005A43, /* 57 */
+0x00005A63, /* 58 */
+0x00005AA9, /* 59 */
+0x00005AAA, /* 60 */
+0x00005ACA, /* 61 */
+0x00005ACB, /* 62 */
+0x00005AEB, /* 63 */
+0x00006222, /* 64 */
+0x00006261, /* 65 */
+0x000062A8, /* 66 */
+0x000062C7, /* 67 */
+0x000062E8, /* 68 */
+0x000062EB, /* 69 */
+0x000062EC, /* 70 */
+0x0000630B, /* 71 */
+0x0000630C, /* 72 */
+0x0000632C, /* 73 */
+0x00006A41, /* 74 */
+0x00006B05, /* 75 */
+0x00006B28, /* 76 */
+0x00006B29, /* 77 */
+0x00006B2D, /* 78 */
+0x00006B4D, /* 79 */
+0x00006B6D, /* 80 */
+0x00006B6E, /* 81 */
+0x00006B8D, /* 82 */
+0x000072A2, /* 83 */
+0x000072E2, /* 84 */
+0x000072E5, /* 85 */
+0x00007306, /* 86 */
+0x00007329, /* 87 */
+0x0000738E, /* 88 */
+0x000073AE, /* 89 */
+0x000073AF, /* 90 */
+0x000073CF, /* 91 */
+0x00007B28, /* 92 */
+0x00007B44, /* 93 */
+0x00007B48, /* 94 */
+0x00007B67, /* 95 */
+0x00007B69, /* 96 */
+0x00007BCE, /* 97 */
+0x00007BCF, /* 98 */
+0x00007BEF, /* 99 */
+0x00008323, /* 100 */
+0x00008345, /* 101 */
+0x000083AA, /* 102 */
+0x00008410, /* 103 */
+0x00008430, /* 104 */
+0x00008B02, /* 105 */
+0x00008B63, /* 106 */
+0x00008B83, /* 107 */
+0x00008B84, /* 108 */
+0x00008BA6, /* 109 */
+0x00008BC7, /* 110 */
+0x00008BEA, /* 111 */
+0x00008BEE, /* 112 */
+0x00008C51, /* 113 */
+0x00008C71, /* 114 */
+0x00009362, /* 115 */
+0x00009363, /* 116 */
+0x00009383, /* 117 */
+0x000093C5, /* 118 */
+0x000093C7, /* 119 */
+0x00009405, /* 120 */
+0x00009492, /* 121 */
+0x00009493, /* 122 */
+0x000094B2, /* 123 */
+0x00009B82, /* 124 */
+0x00009BC3, /* 125 */
+0x00009C2D, /* 126 */
+0x00009CB3, /* 127 */
+0x00009CD3, /* 128 */
+0x00009CF3, /* 129 */
+0x00009CF4, /* 130 */
+0x00009D14, /* 131 */
+0x0000A401, /* 132 */
+0x0000A403, /* 133 */
+0x0000A423, /* 134 */
+0x0000A44C, /* 135 */
+0x0000A489, /* 136 */
+0x0000A4F1, /* 137 */
+0x0000A514, /* 138 */
+0x0000A533, /* 139 */
+0x0000A534, /* 140 */
+0x0000ABE1, /* 141 */
+0x0000AC22, /* 142 */
+0x0000AC24, /* 143 */
+0x0000AC42, /* 144 */
+0x0000AC44, /* 145 */
+0x0000AC48, /* 146 */
+0x0000AC69, /* 147 */
+0x0000AC8A, /* 148 */
+0x0000ACEE, /* 149 */
+0x0000AD0A, /* 150 */
+0x0000AD2E, /* 151 */
+0x0000AD55, /* 152 */
+0x0000AD75, /* 153 */
+0x0000AD76, /* 154 */
+0x0000B423, /* 155 */
+0x0000B441, /* 156 */
+0x0000B444, /* 157 */
+0x0000B464, /* 158 */
+0x0000B484, /* 159 */
+0x0000B4A3, /* 160 */
+0x0000B4C4, /* 161 */
+0x0000B533, /* 162 */
+0x0000B596, /* 163 */
+0x0000B5B6, /* 164 */
+0x0000BC65, /* 165 */
+0x0000BC83, /* 166 */
+0x0000BC84, /* 167 */
+0x0000BCC9, /* 168 */
+0x0000BD03, /* 169 */
+0x0000BD2A, /* 170 */
+0x0000BD54, /* 171 */
+0x0000BD97, /* 172 */
+0x0000BDB5, /* 173 */
+0x0000BDD7, /* 174 */
+0x0000BDD8, /* 175 */
+0x0000BDF7, /* 176 */
+0x0000BE19, /* 177 */
+0x0000C4A2, /* 178 */
+0x0000C4C2, /* 179 */
+0x0000C4C3, /* 180 */
+0x0000C5CE, /* 181 */
+0x0000C5F9, /* 182 */
+0x0000C618, /* 183 */
+0x0000C61A, /* 184 */
+0x0000C638, /* 185 */
+0x0000CCE2, /* 186 */
+0x0000CD03, /* 187 */
+0x0000CD43, /* 188 */
+0x0000CD61, /* 189 */
+0x0000CD88, /* 190 */
+0x0000CE39, /* 191 */
+0x0000CE58, /* 192 */
+0x0000CE59, /* 193 */
+0x0000CE79, /* 194 */
+0x0000CE7A, /* 195 */
+0x0000CE7B, /* 196 */
+0x0000CE9A, /* 197 */
+0x0000D502, /* 198 */
+0x0000D522, /* 199 */
+0x0000D62C, /* 200 */
+0x0000D69A, /* 201 */
+0x0000D69B, /* 202 */
+0x0000D6BA, /* 203 */
+0x0000DD23, /* 204 */
+0x0000DD41, /* 205 */
+0x0000DD81, /* 206 */
+0x0000DDA1, /* 207 */
+0x0000DDA4, /* 208 */
+0x0000DE9C, /* 209 */
+0x0000DEDB, /* 210 */
+0x0000DEFB, /* 211 */
+0x0000DEFD, /* 212 */
+0x0000E5A2, /* 213 */
+0x0000E71C, /* 214 */
+0x0000E73C, /* 215 */
+0x0000EDC1, /* 216 */
+0x0000EF3E, /* 217 */
+0x0000EF5D, /* 218 */
+0x0000EF7D, /* 219 */
+0x0000EF7E, /* 220 */
+0x0000EF7F, /* 221 */
+0x0000F79D, /* 222 */
+0x0000F79E, /* 223 */
+0x0000F7BE, /* 224 */
+0x0000F7BF, /* 225 */
+0x0000F7DE, /* 226 */
+0x0000FFB8, /* 227 */
+0x0000FFBF, /* 228 */
+0x0000FFDD, /* 229 */
+0x0000FFDE, /* 230 */
+0x0000FFDF, /* 231 */
+0x0000FFFB, /* 232 */
+0x0000FFFF, /* 233 */
+};
+
+static const unsigned char bitmap[3060] = {
+0xE9,0xE9,0xE9,0xE9,0xE9,0xE9,0xE9,0xE9,0xE7,0xA4,0xD3,0xE9,0xDF,0xDF,0x8C,0xE7,0xE0,0xDF,0xB0,0xDB,0xE7,0xE0,0xE0,0xC2,0xE7,0xE7,0xE0,0xD3,0xE9,0xE9,0xE0,0xDF,0xDF,0xE7,0xE7,0xD6,0xE9,0xE9,0xE9,0xE9,0xE9,0xE9,0xE9,0xE9,0xE9,0xE9,0xE9,0xE9,0xE9,0xE9,0xE9,
+0xE9,0xE9,0xE9,0xE9,0xE0,0xDB,0xDA,0xDF,0xE9,0x67,0xA3,0xD7,0xDA,0xE9,0x71,0xD7,0xA3,0xE9,0xD6,0xD7,0xD2,0xD6,0xE9,0xC1,0xDF,0x68,0xE9,0xDA,0xE0,0x99,0xAE,0xE9,0xD7,0xB9,0xE9,0xA3,0xDF,0xE0,0xE7,0xE7,0xE7,0xE9,0xE9,0xE9,0xE9,0xE9,0xE9,0xE9,0xE9,0xE9,0xE9,
+0xE9,0xE9,0xE9,0xD6,0x71,0x67,0x63,0x72,0xE9,0x31,0x4F,0x58,0x99,0xD6,0x1D,0x67,0x50,0xB7,0x67,0x36,0x4F,0x99,0xD6,0x28,0x49,0x3F,0xDB,0x71,0x48,0x48,0x80,0xDB,0x37,0x48,0xE9,0x8C,0x58,0x68,0xDA,0xDB,0xDF,0xE0,0xE7,0xE9,0xE9,0xE9,0xE9,0xE9,0xE9,0xE9,0xE9,
+0xE9,0xE9,0xE9,0x79,0x63,0x63,0x58,0x29,0x7B,0x1A,0x28,0x30,0x30,0x63,0x0C,0x50,0x10,0x50,0x28,0x21,0x1D,0x31,0x62,0x11,0x36,0x10,0x68,0x30,0x30,0x16,0x3E,0x68,0x15,0x29,0x8C,0x3E,0x11,0x36,0x4F,0xC2,0xD7,0xDA,0xDF,0xE7,0xE7,0xE9,0xE9,0xE9,0xE9,0xE9,0xE9,
+0xE9,0xE9,0xE7,0x62,0x62,0x63,0x63,0x22,0x37,0x16,0x28,0x36,0x1C,0x28,0x0C,0x49,0x15,0x29,0x16,0x21,0x1D,0x22,0x22,0x0C,0x31,0x11,0x29,0x15,0x21,0x15,0x22,0x22,0x10,0x22,0x48,0x1D,0x08,0x3E,0x29,0x3E,0xB9,0xD2,0xD7,0xDB,0xE0,0xE7,0xE9,0xE9,0xE9,0xE9,0xE9,
+0xE9,0xE9,0xDB,0x62,0x4F,0x4F,0x3F,0x30,0x21,0x15,0x28,0x31,0x22,0x1A,0x0C,0x50,0x18,0x1D,0x0E,0x29,0x1D,0x22,0x16,0x10,0x37,0x1D,0x1D,0x0C,0x28,0x1A,0x29,0x1A,0x18,0x21,0x21,0x16,0x0E,0x3E,0x29,0x30,0x48,0xB0,0xC9,0xD3,0xDB,0xE0,0xE7,0xE9,0xE9,0xE9,0xE9,
+0xE9,0xE9,0xE7,0xA3,0x72,0x21,0x15,0x31,0x36,0x30,0x49,0x36,0x3F,0x29,0x30,0x4F,0x29,0x36,0x21,0x3F,0x28,0x30,0x1A,0x28,0x3E,0x22,0x18,0x16,0x3E,0x1D,0x21,0x11,0x22,0x21,0x10,0x11,0x37,0x11,0x15,0x28,0x48,0x80,0xA4,0xC1,0xD3,0xDA,0xE0,0xE7,0xE9,0xE9,0xE9,
+0xE9,0xD3,0xE9,0xE9,0xE9,0xB7,0x59,0x22,0x58,0x48,0x48,0x48,0x37,0x37,0x3E,0x36,0x36,0x36,0x36,0x37,0x31,0x36,0x36,0x37,0x36,0x30,0x29,0x31,0x36,0x30,0x31,0x31,0x31,0x30,0x30,0x37,0x15,0x15,0xC1,0xE9,0xE9,0x8A,0x59,0x99,0xC1,0xD3,0xDB,0xE0,0xE9,0xE9,0xE9,
+0xE9,0x68,0x50,0x1C,0x16,0x31,0x30,0x1A,0x58,0x49,0x3F,0x3E,0x3E,0x37,0x36,0x37,0x31,0x30,0x30,0x31,0x36,0x30,0x29,0x29,0x29,0x29,0x28,0x28,0x29,0x22,0x28,0x22,0x29,0x29,0x30,0x31,0x15,0x1C,0x59,0x50,0x36,0x36,0x49,0x7B,0xA3,0xC2,0xD6,0xDB,0xE7,0xE9,0xE9,
+0xE9,0xA4,0x50,0x58,0x36,0x29,0x37,0x4F,0x50,0x3F,0x3E,0x31,0x31,0x31,0x36,0x36,0x36,0x31,0x30,0x30,0x29,0x30,0x30,0x29,0x28,0x22,0x28,0x28,0x22,0x28,0x22,0x21,0x22,0x22,0x22,0x36,0x28,0x29,0x1A,0x15,0x0C,0x1A,0x37,0x63,0x80,0xAE,0xC9,0xD7,0xDF,0xE7,0xE9,
+0xE9,0xE7,0xC9,0x80,0x28,0x16,0x15,0x15,0x49,0x37,0x37,0x37,0x30,0x30,0x29,0x30,0x31,0x30,0x29,0x29,0x28,0x36,0x28,0x28,0x48,0x29,0x21,0x22,0x28,0x21,0x21,0x22,0x1D,0x22,0x22,0x30,0x21,0x16,0x1C,0x21,0x31,0x31,0x37,0x4F,0x68,0x8C,0xB7,0xD3,0xDB,0xE7,0xE9,
+0xE9,0xC2,0xE9,0xDA,0xB0,0x4F,0x1D,0x1D,0x4F,0x37,0x31,0x36,0x36,0x30,0x30,0x30,0x31,0x29,0x30,0x28,0x36,0x81,0x50,0x15,0x0C,0x31,0x28,0x21,0x22,0x22,0x22,0x21,0x22,0x21,0x1D,0x28,0x0E,0x11,0x81,0xDF,0xE0,0x80,0x36,0x3E,0x59,0x7B,0xA4,0xC9,0xDA,0xE0,0xE9,
+0xE7,0x72,0x67,0x3E,0x37,0x36,0x16,0x28,0x49,0x37,0x36,0x30,0x30,0x30,0x29,0x30,0x29,0x30,0x22,0x28,0x49,0xB7,0xB9,0x99,0x29,0x0E,0x31,0x28,0x1D,0x21,0x22,0x1D,0x1D,0x22,0x21,0x28,0x11,0x22,0x8C,0x98,0x8A,0x4F,0x30,0x36,0x4F,0x71,0x99,0xC2,0xD7,0xE0,0xE7,
+0xDF,0x80,0x3E,0x18,0x10,0x21,0x31,0x3F,0x48,0x36,0x36,0x30,0x30,0x29,0x30,0x30,0x30,0x29,0x28,0x28,0x50,0xA4,0x8C,0x98,0xA4,0x3E,0x10,0x31,0x22,0x22,0x1D,0x1D,0x22,0x21,0x22,0x22,0x18,0x30,0x10,0x09,0x08,0x0C,0x1D,0x30,0x49,0x68,0x98,0xC1,0xD6,0xDF,0xE7,
+0xE9,0xE7,0xB0,0x50,0x22,0x28,0x22,0x28,0x3E,0x36,0x31,0x30,0x30,0x30,0x29,0x29,0x29,0x28,0x29,0x28,0x4F,0x80,0x48,0x48,0x63,0x98,0x3F,0x16,0x29,0x21,0x1D,0x21,0x21,0x1D,0x21,0x22,0x1D,0x21,0x29,0x31,0x1D,0x1A,0x22,0x30,0x48,0x67,0x8C,0xB9,0xD6,0xDF,0xE7,
+0xDF,0xD3,0xE9,0xD7,0x81,0x31,0x10,0x16,0x3E,0x36,0x31,0x30,0x29,0x30,0x29,0x29,0x28,0x28,0x28,0x28,0x37,0x67,0x48,0x48,0x47,0x50,0x7B,0x36,0x1A,0x30,0x1D,0x1D,0x1D,0x21,0x21,0x21,0x10,0x15,0x63,0xC1,0xC1,0x62,0x31,0x30,0x48,0x67,0x8C,0xB9,0xD6,0xDF,0xE7,
+0xE0,0x8A,0xAE,0x67,0x4F,0x37,0x18,0x22,0x3F,0x36,0x30,0x30,0x29,0x22,0x29,0x29,0x22,0x28,0x28,0x21,0x29,0x61,0x47,0x47,0x48,0x48,0x4F,0x79,0x31,0x22,0x37,0x1D,0x1D,0x1D,0x1C,0x21,0x15,0x36,0xC1,0xD6,0xB7,0x59,0x28,0x30,0x48,0x63,0x8A,0xB9,0xD6,0xDF,0xE7,
+0xD2,0x59,0x36,0x10,0x0C,0x1C,0x15,0x29,0x3F,0x30,0x36,0x30,0x30,0x28,0x22,0x1D,0x28,0x31,0x22,0x21,0x22,0x3E,0x48,0x48,0x48,0x48,0x48,0x50,0x68,0x30,0x30,0x28,0x1D,0x1C,0x21,0x1D,0x11,0x1C,0x0C,0x00,0x02,0x09,0x21,0x30,0x48,0x63,0x8A,0xB9,0xD6,0xDF,0xE7,
+0xE9,0xDB,0x80,0x4F,0x30,0x3E,0x48,0x49,0x36,0x30,0x31,0x30,0x29,0x22,0x2E,0x2D,0x4C,0x6D,0x76,0x94,0x4D,0x31,0x4E,0x48,0x47,0x48,0x48,0x48,0x50,0x62,0x30,0x37,0x1D,0x1D,0x1D,0x1D,0x21,0x29,0x22,0x21,0x1C,0x16,0x21,0x30,0x48,0x63,0x8C,0xB9,0xD6,0xDF,0xE7,
+0xE7,0xE0,0xB9,0x72,0x1D,0x16,0x10,0x16,0x36,0x29,0x29,0x30,0x29,0x44,0xB5,0xC8,0x5D,0x6E,0x9E,0x9D,0x78,0x5F,0x70,0x46,0x47,0x47,0x48,0x3F,0x3F,0x58,0x4F,0x36,0x36,0x1A,0x1A,0x1C,0x15,0x10,0x1D,0x49,0x63,0x37,0x36,0x30,0x48,0x67,0x8C,0xB9,0xD6,0xDF,0xE7,
+0xDA,0xAE,0xE9,0xC2,0x8A,0x3F,0x1A,0x21,0x31,0x29,0x29,0x28,0x29,0x89,0xE5,0xE3,0xAA,0x66,0x38,0x4A,0x41,0x40,0x5C,0x45,0x3E,0x3E,0x3E,0x3E,0x3E,0x3F,0x58,0x48,0x48,0x31,0x18,0x21,0x10,0x21,0xD7,0xE9,0xE7,0x80,0x30,0x30,0x48,0x67,0x8C,0xB9,0xD6,0xDF,0xE7,
+0xD2,0x62,0x62,0x29,0x28,0x28,0x11,0x22,0x36,0x28,0x28,0x28,0x29,0x7E,0xE4,0xE8,0x96,0x3A,0x86,0x8E,0x85,0x75,0x53,0x57,0x3C,0x37,0x37,0x37,0x37,0x37,0x3E,0x4F,0x49,0x4F,0x1C,0x1C,0x16,0x1D,0x31,0x31,0x22,0x1D,0x21,0x30,0x48,0x67,0x8C,0xB9,0xD6,0xDF,0xE7,
+0xDA,0xB0,0x62,0x16,0x10,0x21,0x31,0x48,0x37,0x28,0x28,0x3B,0x6F,0x78,0x95,0x97,0x64,0xA1,0xCF,0xCE,0xC6,0xBB,0x90,0x65,0x3B,0x32,0x36,0x36,0x36,0x31,0x36,0x3F,0x4F,0x4F,0x37,0x1C,0x18,0x22,0x16,0x10,0x0E,0x0C,0x1D,0x30,0x48,0x63,0x8C,0xB9,0xD6,0xDF,0xE7,
+0xE9,0xE0,0x98,0x37,0x1C,0x22,0x22,0x21,0x30,0x31,0x88,0xA5,0xA7,0xB2,0x9F,0x91,0x9F,0xB4,0xC7,0xD0,0x9C,0xA6,0x7C,0x73,0x60,0x30,0x30,0x30,0x30,0x30,0x30,0x30,0x3F,0x58,0x49,0x1C,0x1A,0x1D,0x1D,0x1C,0x21,0x1D,0x22,0x30,0x48,0x63,0x8A,0xB9,0xD6,0xDF,0xE7,
+0xDF,0xD6,0xDA,0x8A,0x49,0x21,0x11,0x18,0x30,0x29,0x35,0x34,0x42,0x2B,0x24,0x1F,0x17,0x25,0x39,0x55,0x54,0x6B,0x69,0x7D,0x5E,0x3C,0x22,0x10,0x1C,0x28,0x28,0x29,0x30,0x3F,0x63,0x3F,0x10,0x10,0x67,0xB9,0xC9,0x72,0x48,0x36,0x3F,0x63,0x8A,0xB9,0xD6,0xDF,0xE7,
+0xD6,0xA4,0xDB,0x98,0x68,0x31,0x1A,0x21,0x30,0x22,0x21,0x22,0x21,0x13,0x7F,0x4E,0x02,0x18,0x98,0xAF,0x19,0x0A,0x12,0x43,0x27,0x30,0x16,0x00,0x0E,0x1D,0x22,0x22,0x28,0x29,0x58,0x67,0x1C,0x1D,0xA3,0xD3,0xB9,0x67,0x29,0x30,0x3F,0x63,0x8A,0xB9,0xD3,0xDF,0xE7,
+0xC1,0x62,0x30,0x0C,0x0E,0x1A,0x15,0x28,0x29,0x22,0x21,0x1C,0x2F,0x2F,0x51,0x9A,0x11,0x52,0x58,0x48,0x7A,0x02,0x05,0x30,0x1C,0x21,0x22,0x02,0x00,0x16,0x1D,0x21,0x21,0x22,0x36,0x72,0x48,0x18,0x02,0x00,0x02,0x08,0x1A,0x29,0x3F,0x63,0x8A,0xB7,0xD3,0xDF,0xE7,
+0xE9,0xE0,0xAE,0x1D,0x1A,0x30,0x49,0x48,0x22,0x21,0x1D,0x21,0x29,0x23,0x33,0x56,0x74,0x77,0x2C,0x18,0x83,0x02,0x03,0x30,0x21,0x1A,0x22,0x09,0x00,0x0E,0x1C,0x1C,0x1D,0x1D,0x21,0x59,0x79,0x29,0x22,0x21,0x1C,0x18,0x21,0x30,0x3F,0x62,0x81,0xB7,0xD3,0xDF,0xE7,
+0xE7,0xDA,0x98,0x3F,0x11,0x15,0x0E,0x16,0x29,0x21,0x1D,0x1D,0x29,0x14,0x93,0xCC,0xB3,0x84,0xA0,0xBE,0x4B,0x02,0x01,0x28,0x1D,0x1D,0x1D,0x18,0x00,0x02,0x18,0x1A,0x1C,0x1A,0x1C,0x29,0x81,0x15,0x30,0x62,0x7B,0x48,0x3E,0x36,0x3F,0x62,0x81,0xB7,0xD3,0xDB,0xE7,
+0xD7,0xC2,0xE9,0xB0,0x71,0x31,0x15,0x1C,0x28,0x21,0x1D,0x1D,0x28,0x1E,0xA6,0xD8,0xBD,0xA9,0xBC,0xC7,0x6A,0x04,0x02,0x20,0x1A,0x1C,0x1C,0x18,0x00,0x00,0x11,0x18,0x18,0x18,0x18,0x1A,0x68,0x1C,0xD2,0xE9,0xE9,0x80,0x36,0x29,0x3E,0x62,0x80,0xB0,0xD2,0xDB,0xE7,
+0xC1,0x79,0x72,0x3F,0x31,0x21,0x0E,0x1D,0x28,0x1C,0x1D,0x1A,0x30,0x0F,0x6C,0xCD,0xD5,0xBA,0x8D,0xA8,0x57,0x0E,0x2A,0x10,0x21,0x1C,0x48,0x02,0x00,0x00,0x0E,0x16,0x16,0x16,0x16,0x18,0x31,0x18,0x18,0x15,0x11,0x10,0x1C,0x29,0x3E,0x59,0x80,0xB0,0xD2,0xDB,0xE7,
+0xDA,0xD2,0x72,0x0E,0x0C,0x1D,0x30,0x37,0x22,0x1C,0x1D,0x1C,0x30,0x06,0xA2,0x92,0x9B,0x8F,0x87,0xBF,0xB1,0x0D,0x1B,0x09,0x1A,0x37,0x1A,0x02,0x00,0x00,0x10,0x18,0x16,0x16,0x16,0x18,0x11,0x21,0x18,0x11,0x11,0x11,0x1D,0x29,0x3E,0x59,0x80,0xB0,0xD2,0xDB,0xE7,
+0xE9,0xE0,0x99,0x37,0x1A,0x22,0x21,0x21,0x22,0x1D,0x1C,0x29,0x1D,0x16,0xAE,0xAC,0xAB,0xAD,0xD1,0xDD,0xD6,0x46,0x02,0x04,0x0B,0x0E,0x00,0x00,0x00,0x00,0x1D,0x1C,0x18,0x18,0x16,0x18,0x10,0x1A,0x1D,0x30,0x30,0x30,0x29,0x29,0x3E,0x59,0x80,0xB0,0xD2,0xDB,0xE7,
+0xDF,0xB9,0x98,0x62,0x22,0x1A,0x0C,0x16,0x22,0x1C,0x21,0x26,0x09,0x5B,0x8B,0xC5,0xCA,0xDC,0xE2,0xC0,0x72,0x7B,0x07,0x07,0x03,0x00,0x00,0x00,0x00,0x0C,0x18,0x1D,0x1C,0x18,0x18,0x18,0x10,0x3F,0xD6,0xE9,0xD3,0x59,0x29,0x29,0x3E,0x59,0x80,0xB0,0xD2,0xDB,0xE7,
+0xCB,0xB0,0xE9,0xAE,0x72,0x30,0x11,0x1D,0x22,0x22,0x11,0x09,0x21,0xCB,0xCB,0xE0,0xE7,0xE9,0xDE,0x99,0x79,0xB7,0x1C,0x03,0x01,0x00,0x00,0x00,0x02,0x1A,0x15,0x15,0x21,0x1C,0x18,0x18,0x0E,0x31,0x67,0x62,0x29,0x1A,0x28,0x29,0x3E,0x62,0x81,0xB0,0xD3,0xDB,0xE7,
+0xB9,0x8A,0x4F,0x11,0x10,0x18,0x0E,0x21,0x29,0x11,0x18,0x10,0x3F,0xCB,0xD2,0xD7,0xDC,0xE9,0xE6,0xC9,0xB6,0xB8,0x5A,0x01,0x00,0x00,0x00,0x00,0x08,0x29,0x29,0x16,0x15,0x1A,0x1A,0x15,0x02,0x0E,0x08,0x00,0x08,0x09,0x1D,0x29,0x3E,0x62,0x81,0xB7,0xD3,0xDB,0xE7,
+0xE9,0xE0,0x98,0x15,0x11,0x1D,0x3E,0x37,0x02,0x0E,0x1C,0x02,0x8A,0xA3,0x71,0xB7,0xE1,0xE9,0xE6,0xDC,0xD9,0xD4,0xC4,0x28,0x02,0x00,0x00,0x09,0x02,0x00,0x00,0x02,0x0C,0x16,0x30,0x21,0x0E,0x21,0x28,0x21,0x1D,0x1A,0x22,0x29,0x3F,0x62,0x81,0xB7,0xD3,0xDF,0xE7,
+0xE9,0xC1,0x67,0x28,0x0E,0x11,0x10,0x16,0x02,0x00,0x08,0x00,0x48,0x8C,0x8C,0xC3,0xDF,0xE0,0xD3,0x7B,0x82,0xCB,0xC9,0x71,0x01,0x00,0x09,0x0C,0x00,0x00,0x00,0x00,0x00,0x00,0x08,0x1C,0x18,0x28,0x98,0xDF,0xC1,0x58,0x3E,0x29,0x3F,0x62,0x81,0xB7,0xD3,0xDF,0xE7,
+0xD6,0xB9,0xD7,0x8C,0x59,0x31,0x10,0x1A,0x0C,0x00,0x00,0x00,0x02,0x18,0x1C,0x21,0x31,0x37,0x31,0x1A,0x1D,0x37,0x3D,0x28,0x03,0x00,0x0C,0x02,0x00,0x02,0x09,0x0E,0x0C,0x10,0x18,0x18,0x15,0x4F,0xC1,0xC9,0x71,0x30,0x21,0x29,0x3F,0x62,0x8A,0xB7,0xD3,0xDF,0xE7,
+0xC2,0x8A,0xAE,0x63,0x49,0x28,0x09,0x1C,0x22,0x16,0x08,0x00,0x00,0x0C,0x18,0x11,0x10,0x10,0x0C,0x09,0x0C,0x0E,0x0E,0x10,0x11,0x15,0x1A,0x22,0x1C,0x1A,0x1D,0x1A,0x11,0x16,0x15,0x16,0x10,0x0C,0x00,0x00,0x00,0x00,0x1A,0x29,0x3F,0x62,0x81,0xB7,0xD3,0xDF,0xE7,
+0xDB,0xDA,0x72,0x08,0x09,0x16,0x22,0x31,0x21,0x18,0x1A,0x16,0x08,0x09,0x15,0x18,0x11,0x16,0x16,0x15,0x11,0x11,0x16,0x16,0x15,0x15,0x11,0x11,0x11,0x15,0x15,0x15,0x11,0x11,0x15,0x18,0x15,0x1C,0x18,0x16,0x1D,0x18,0x21,0x29,0x3E,0x62,0x81,0xB7,0xD3,0xDF,0xE7,
+0xE9,0xDF,0x8A,0x1D,0x15,0x1A,0x1C,0x21,0x22,0x1C,0x16,0x16,0x18,0x18,0x18,0x16,0x16,0x18,0x15,0x15,0x15,0x16,0x16,0x15,0x15,0x15,0x16,0x15,0x11,0x11,0x15,0x11,0x11,0x16,0x16,0x1A,0x16,0x16,0x58,0xC1,0xAE,0x59,0x3E,0x30,0x3E,0x62,0x81,0xB7,0xD3,0xDF,0xE7,
+0xE7,0x98,0x50,0x36,0x16,0x18,0x09,0x18,0x28,0x1D,0x1A,0x16,0x16,0x16,0x16,0x16,0x16,0x16,0x16,0x15,0x16,0x16,0x15,0x16,0x15,0x15,0x11,0x11,0x11,0x15,0x15,0x15,0x11,0x11,0x11,0x1A,0x15,0x31,0xD2,0xCB,0x59,0x29,0x22,0x29,0x3E,0x59,0x80,0xB0,0xD3,0xDB,0xE7,
+0xCB,0xB0,0xDB,0xA4,0x68,0x31,0x10,0x1C,0x28,0x21,0x1C,0x1A,0x16,0x18,0x18,0x1C,0x16,0x18,0x15,0x16,0x18,0x11,0x11,0x15,0x15,0x11,0x11,0x11,0x15,0x11,0x10,0x11,0x15,0x15,0x18,0x1C,0x15,0x18,0x15,0x00,0x02,0x09,0x08,0x21,0x3E,0x59,0x80,0xB0,0xD2,0xDB,0xE7,
+0xC9,0xC1,0x80,0x36,0x21,0x1A,0x10,0x29,0x16,0x11,0x1A,0x0E,0x0C,0x15,0x11,0x1A,0x09,0x0E,0x11,0x16,0x10,0x09,0x0E,0x0E,0x16,0x08,0x09,0x0C,0x11,0x0E,0x08,0x0E,0x0C,0x16,0x08,0x0E,0x18,0x18,0x0C,0x08,0x15,0x16,0x1C,0x28,0x37,0x59,0x80,0xB0,0xD2,0xDB,0xE7,
+0xE9,0xE0,0x81,0x0C,0x09,0x1A,0x29,0x08,0x0E,0x10,0x1C,0x0E,0x0C,0x11,0x16,0x1C,0x02,0x10,0x0E,0x1C,0x10,0x09,0x0E,0x10,0x1A,0x02,0x0E,0x0C,0x18,0x0E,0x09,0x0E,0x10,0x18,0x08,0x10,0x0C,0x18,0x18,0x16,0x10,0x16,0x21,0x29,0x37,0x58,0x7B,0xAE,0xD2,0xDB,0xE7,
+0xE9,0xE0,0x99,0x21,0x1D,0x21,0x1C,0x50,0x72,0x1A,0x1D,0x11,0x71,0x72,0x1A,0x1C,0x16,0x99,0x30,0x1C,0x11,0x59,0x80,0x18,0x1A,0x15,0xA4,0x37,0x18,0x10,0x58,0xAE,0x15,0x18,0x15,0xCB,0x49,0x18,0x11,0x10,0x11,0x16,0x21,0x29,0x3E,0x59,0x80,0xAE,0xD2,0xDB,0xE7,
+0xE9,0xE0,0xA3,0x1A,0x21,0x22,0x21,0xB9,0xCB,0x15,0x22,0x15,0xCB,0xC9,0x11,0x1D,0x22,0xE9,0x50,0x18,0x11,0x98,0xE7,0x10,0x1C,0x15,0xE9,0x68,0x16,0x10,0x71,0xE9,0x16,0x1A,0x10,0xE7,0x67,0x16,0x15,0x15,0x11,0x18,0x22,0x29,0x3E,0x62,0x80,0xB0,0xD2,0xDB,0xE7,
+0xE9,0xE7,0xA3,0x1D,0x1C,0x28,0x30,0xDF,0xCB,0x1D,0x29,0x28,0xE0,0xD2,0x1A,0x22,0x50,0xE9,0x62,0x21,0x21,0xB0,0xE9,0x16,0x1C,0x29,0xE0,0x79,0x1C,0x1C,0x71,0xDB,0x21,0x18,0x21,0xB9,0x79,0x1A,0x15,0x11,0x10,0x18,0x22,0x30,0x48,0x63,0x8A,0xB9,0xD3,0xDF,0xE7,
+0xE9,0xE7,0xD6,0x48,0x1C,0x31,0x18,0x7B,0x59,0x0C,0x16,0x18,0x62,0x50,0x0C,0x16,0x21,0x72,0x28,0x10,0x11,0x48,0x71,0x09,0x10,0x16,0x71,0x36,0x0E,0x0E,0x30,0x50,0x11,0x0E,0x0C,0x49,0x30,0x10,0x0C,0x08,0x10,0x1D,0x28,0x36,0x49,0x68,0x98,0xC2,0xD7,0xDF,0xE7,
+0xE9,0xE9,0xE0,0xDA,0xC9,0xAE,0x7B,0x49,0x28,0x10,0x22,0x22,0x28,0x22,0x15,0x21,0x1D,0x30,0x1C,0x1D,0x1C,0x22,0x22,0x18,0x1D,0x16,0x31,0x21,0x21,0x15,0x29,0x31,0x1D,0x1A,0x1A,0x29,0x1C,0x21,0x21,0x1D,0x22,0x28,0x30,0x3E,0x58,0x79,0xA4,0xCB,0xDA,0xE0,0xE9,
+0xE9,0xE9,0xE7,0xDF,0xD3,0xB9,0x98,0x59,0x36,0x22,0x31,0x3F,0x49,0x1D,0x21,0x28,0x67,0x1D,0x1C,0x22,0x29,0x4F,0x1A,0x1D,0x28,0x58,0x1C,0x1A,0x22,0x29,0x4F,0x1A,0x21,0x28,0x59,0x1C,0x22,0x28,0x28,0x28,0x29,0x31,0x37,0x4F,0x67,0x8A,0xB7,0xD3,0xDB,0xE7,0xE9,
+0xE9,0xE9,0xE7,0xE0,0xD7,0xC9,0xAE,0x81,0x67,0x58,0x48,0x3E,0x37,0x36,0x36,0x36,0x36,0x36,0x31,0x31,0x31,0x31,0x31,0x31,0x31,0x31,0x31,0x31,0x31,0x31,0x31,0x31,0x31,0x31,0x31,0x31,0x31,0x36,0x36,0x36,0x3E,0x48,0x50,0x63,0x7B,0xA3,0xC2,0xD7,0xDF,0xE7,0xE9,
+0xE9,0xE9,0xE9,0xE7,0xDB,0xD3,0xC1,0xA4,0x81,0x72,0x63,0x59,0x50,0x50,0x4F,0x4F,0x4F,0x4F,0x49,0x49,0x49,0x49,0x49,0x49,0x49,0x49,0x49,0x49,0x49,0x49,0x49,0x49,0x49,0x49,0x49,0x49,0x49,0x49,0x4F,0x50,0x58,0x63,0x71,0x80,0x99,0xB9,0xD2,0xDB,0xE0,0xE9,0xE9,
+0xE9,0xE9,0xE9,0xE7,0xE0,0xDA,0xD3,0xC2,0xB0,0x99,0x8A,0x7B,0x79,0x72,0x71,0x71,0x71,0x71,0x68,0x68,0x68,0x68,0x68,0x68,0x68,0x68,0x67,0x67,0x67,0x67,0x67,0x67,0x68,0x68,0x68,0x68,0x68,0x71,0x71,0x72,0x7B,0x8A,0x99,0xAE,0xC1,0xD2,0xDA,0xDF,0xE7,0xE9,0xE9,
+0xE9,0xE9,0xE9,0xE9,0xE7,0xE0,0xDB,0xD6,0xD2,0xC2,0xB7,0xAE,0xA3,0x99,0x99,0x99,0x99,0x98,0x98,0x98,0x98,0x98,0x98,0x98,0x98,0x8C,0x8C,0x8C,0x8C,0x8C,0x8C,0x8C,0x8C,0x98,0x98,0x98,0x98,0x98,0x99,0xA3,0xA4,0xB7,0xC2,0xCB,0xD6,0xDA,0xDF,0xE7,0xE9,0xE9,0xE9,
+0xE9,0xE9,0xE9,0xE9,0xE9,0xE7,0xE0,0xDF,0xDA,0xD7,0xD3,0xCB,0xC9,0xC2,0xC2,0xC2,0xC2,0xC1,0xC1,0xC1,0xC1,0xC1,0xC1,0xC1,0xC1,0xC1,0xB9,0xB9,0xB9,0xB9,0xB9,0xB9,0xC1,0xC1,0xC1,0xC1,0xC1,0xC1,0xC2,0xC2,0xCB,0xD3,0xD7,0xDA,0xDF,0xE0,0xE7,0xE9,0xE9,0xE9,0xE9,
+0xE9,0xE9,0xE9,0xE9,0xE9,0xE9,0xE9,0xE7,0xE0,0xDF,0xDB,0xDA,0xDA,0xD7,0xD7,0xD7,0xD7,0xD6,0xD6,0xD6,0xD6,0xD6,0xD6,0xD6,0xD6,0xD6,0xD6,0xD6,0xD6,0xD6,0xD6,0xD6,0xD6,0xD6,0xD6,0xD6,0xD6,0xD7,0xD7,0xD7,0xDA,0xDB,0xDF,0xE0,0xE7,0xE7,0xE9,0xE9,0xE9,0xE9,0xE9,
+0xE9,0xE9,0xE9,0xE9,0xE9,0xE9,0xE9,0xE9,0xE9,0xE7,0xE7,0xE0,0xE0,0xE0,0xE0,0xE0,0xDF,0xDF,0xDF,0xDF,0xDF,0xDF,0xDF,0xDF,0xDF,0xDF,0xDF,0xDF,0xDF,0xDF,0xDF,0xDF,0xDF,0xDF,0xDF,0xDF,0xDF,0xDF,0xDF,0xE0,0xE0,0xE7,0xE7,0xE9,0xE9,0xE9,0xE9,0xE9,0xE9,0xE9,0xE9,
+0xE9,0xE9,0xE9,0xE9,0xE9,0xE9,0xE9,0xE9,0xE9,0xE9,0xE9,0xE9,0xE9,0xE9,0xE7,0xE7,0xE7,0xE7,0xE7,0xE7,0xE7,0xE7,0xE7,0xE7,0xE7,0xE7,0xE7,0xE7,0xE7,0xE7,0xE7,0xE7,0xE7,0xE7,0xE7,0xE7,0xE7,0xE7,0xE7,0xE9,0xE9,0xE9,0xE9,0xE9,0xE9,0xE9,0xE9,0xE9,0xE9,0xE9,0xE9,
+};

Added: trunk/LinuxBIOSv2/src/southbridge/amd/cs5530/cs5530_vga.c
===================================================================
--- trunk/LinuxBIOSv2/src/southbridge/amd/cs5530/cs5530_vga.c	                        (rev 0)
+++ trunk/LinuxBIOSv2/src/southbridge/amd/cs5530/cs5530_vga.c	2007-10-05 21:00:10 UTC (rev 2827)
@@ -0,0 +1,458 @@
+/*
+ * Copyright (C) 2007 Juergen Beisert <juergen at kreuzholzen.de>
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; version 2 of the License.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA, 02110-1301 USA
+ *
+ * Purpose:
+ * Activate the VGA feature in a Geode GX1 based system with one of five
+ * possible VESA modes: VGA, SVGA, XGA, 4:3 SXGA and 5:4 SXGA. Also it is
+ * prepared to display a splash screen.
+ */
+#include <arch/io.h>
+#include <device/device.h>
+#include <device/pci.h>
+#include <device/pci_ops.h>
+#include <device/pci_ids.h>
+#include <console/console.h>
+#include <cpu/amd/gx1def.h>
+#include <delay.h>
+
+#if CONFIG_GX1_VIDEO == 1
+/*
+ * Some register descriptions that are no listed in cpu/amd/gx1def.h
+ */
+#define CS5530_DOT_CLK_CONFIG	0x0024
+#define CS5530_DISPLAY_CONFIG	0x0004
+
+#define DC_FB_ST_OFFSET		0x8310	/* framebuffer start offset */
+#define DC_CB_ST_OFFSET		0x8314	/* compression start offset */
+#define DC_CURS_ST_OFFSET	0x8318	/* cursor start offset */
+#define DC_VID_ST_OFFSET	0x8320	/* video start offset */
+#define DC_LINE_DELTA		0x8324	/* fb and cb skip counts */
+#define DC_BUF_SIZE		0x8328	/* fb and cb line size */
+#define DC_H_TIMING_1		0x8330	/* horizontal timing... */
+#define DC_H_TIMING_2		0x8334
+#define DC_H_TIMING_3		0x8338
+#define DC_FP_H_TIMING		0x833C
+#define DC_V_TIMING_1		0x8340	/* vertical timing... */
+#define DC_V_TIMING_2		0x8344
+#define DC_V_TIMING_3		0x8348
+#define DC_FP_V_TIMING		0x834C
+#define DC_TIMING_CFG		0x8308
+#define DC_OUTPUT_CFG		0x830C
+
+/*
+ * what colour depth should be used as default (in bpp)
+ * Note: Currently no other value than 16 is supported
+ */
+#define COLOUR_DEPTH 16
+
+/*
+ * Support for a few basic video modes
+ * Note: all modes only for CRT. The flatpanel feature is
+ * not supported here (due to the lack of hardware to test)
+ */
+struct video_mode {
+	int pixel_clock;		/*<< pixel clock in Hz */
+	unsigned long pll_value;	/*<< pll register value for this clock */
+
+	int visible_pixel;
+	int hsync_start;
+	int hsync_end;
+	int line_length;
+
+	int visible_lines;
+	int vsync_start;
+	int vsync_end;
+	int picture_length;
+
+	int sync_pol;		/*<< 0: low, 1: high, bit 0 hsync, bit 1 vsync */
+};
+
+/*
+ * values for .sync_pol
+ */
+#define HSYNC_HIGH_POL 0
+#define HSYNC_LOW_POL 1
+#define VSYNC_HIGH_POL 0
+#define VSYNC_LOW_POL 2
+
+/* ModeLine "640x480" 31.5 640 664 704 832 480 489 491 520 -hsync -vsync */
+static const struct video_mode mode_640x480 = {
+	/*
+	 * 640x480 @ 72Hz hsync: 37.9kHz
+	 * VESA standard mode for classic 4:3 monitors
+	 */
+	.pixel_clock = 31500000,
+	.pll_value = 0x33915801,
+
+	.visible_pixel = 640,
+	.hsync_start = 664,
+	.hsync_end = 704,	/* 1.27 us sync length */
+	.line_length = 832,	/* 26.39us */
+
+	.visible_lines = 480,
+	.vsync_start = 489,
+	.vsync_end = 491,
+	.picture_length = 520, /* 13.89ms */
+
+	.sync_pol = HSYNC_LOW_POL | VSYNC_LOW_POL
+};
+
+/* ModeLine "800x600" 50.0 800 856 976 1040 600 637 643 666 +hsync +vsync */
+static const struct video_mode mode_800x600 = {
+	/*
+	 * 800x600 @ 72Hz hsync: 48.1kHz
+	 * VESA standard mode for classic 4:3 monitors
+	 */
+	.pixel_clock = 50000000,
+	.pll_value = 0x23088801,
+
+	.visible_pixel = 800,
+	.hsync_start = 856,
+	.hsync_end = 976,
+	.line_length = 1040, /* 20.8us */
+
+	.visible_lines = 600,
+	.vsync_start = 637,
+	.vsync_end = 643,
+	.picture_length = 666, /* 13.89ms */
+
+	.sync_pol = HSYNC_HIGH_POL | VSYNC_HIGH_POL
+};
+
+/* ModeLine "1024x768" 75.0 1024 1048 1184 1328 768 771 777 806 -hsync -vsync */
+static const struct video_mode mode_1024x768 = {
+	/*
+	 * 1024x768 @ 70Hz (VESA) hsync: 56.5kHz
+	 * Standard mode for classic 4:3 monitors
+	 */
+	.pixel_clock = 75000000,
+	.pll_value = 0x37E22801,
+
+	.visible_pixel = 1024,
+	.hsync_start = 1048,
+	.hsync_end = 1184,
+	.line_length = 1328,	/* 17.7us */
+
+	.visible_lines = 768,
+	.vsync_start = 771,
+	.vsync_end = 777,
+	.picture_length = 806,	/* 14.3us */
+
+	.sync_pol = HSYNC_LOW_POL | VSYNC_LOW_POL
+};
+
+/* ModeLine "1280x960" 108.0 1280 1376 1488 1800 960 961 964 1000 +hsync +vsync */
+static const struct video_mode mode_1280x960 = {
+	/*
+	 * 1280x960 @ 60Hz (VESA) hsync: 60.0kHz
+	 * Mode for classic 4:3 monitors
+	 */
+	.pixel_clock = 108000000,
+	.pll_value = 0x2710C805,
+
+	.visible_pixel = 1280,
+	.hsync_start = 1376,
+	.hsync_end = 1488,
+	.line_length = 1800,	/* 16.67us */
+
+	.visible_lines = 960,
+	.vsync_start = 961,
+	.vsync_end = 964,
+	.picture_length = 1000,	/* 16.67ms */
+
+	.sync_pol = HSYNC_HIGH_POL | VSYNC_HIGH_POL
+};
+
+/* ModeLine "1280x1024" 108.0 1280 1328 1440 1688 1024 1025 1028 1066 +hsync +vsync */
+static const struct video_mode mode_1280x1024 = {
+	/*
+	 * 1280x1024 @ 60Hz (VESA) hsync: 64.0kHz
+	 * Mode for modern 5:4 flat screens
+	 */
+	.pixel_clock = 108000000,
+	.pll_value = 0x2710C805,
+
+	.visible_pixel = 1280,
+	.hsync_start = 1328,
+	.hsync_end = 1440,
+	.line_length = 1688,	/* 15.6us */
+
+	.visible_lines = 1024,
+	.vsync_start = 1025,
+	.vsync_end = 1028,
+	.picture_length = 1066,
+
+	.sync_pol = HSYNC_HIGH_POL | VSYNC_HIGH_POL
+};
+
+/*
+ * a few supported common modes
+ */
+static const struct video_mode *modes[] = {
+	&mode_640x480,	/* CONFIG_GX1_VIDEOMODE = 0 */
+	&mode_800x600,	/* CONFIG_GX1_VIDEOMODE = 1 */
+	&mode_1024x768,	/* CONFIG_GX1_VIDEOMODE = 2 */
+	&mode_1280x960,	/* CONFIG_GX1_VIDEOMODE = 3 */
+	&mode_1280x1024	/* CONFIG_GX1_VIDEOMODE = 4 */
+};
+
+/* make a sanity check at buildtime */
+#if CONFIG_GX1_VIDEOMODE > 4
+# error Requested video mode is unknown!
+#endif
+
+/*
+ * Setup the pixel PLL in the companion chip
+ * base: register's base address
+ * pll_val: pll register value to be set
+ */
+static void cs5530_set_clock_frequency(void *io_base,unsigned long pll_val)
+{
+	unsigned long reg;
+
+	/* disable the PLL first, reset and power it down */
+	reg = readl(io_base+CS5530_DOT_CLK_CONFIG) & ~0x20;
+	reg |= 0x80000100;
+	writel(reg, io_base+CS5530_DOT_CLK_CONFIG);
+
+	/* write the new PLL setting */
+	reg |= (pll_val & ~0x80000920);
+	writel(reg, io_base+CS5530_DOT_CLK_CONFIG);
+
+	mdelay(1);	/* wait for control voltage to be 0V */
+
+	/* enable the PLL */
+	reg |= 0x00000800;
+	writel(reg, io_base+CS5530_DOT_CLK_CONFIG);
+
+	/* clear reset */
+	reg &= ~0x80000000;
+	writel(reg, io_base+CS5530_DOT_CLK_CONFIG);
+
+	/* clear bypass */
+	reg &= ~0x00000100;
+	writel(reg, io_base+CS5530_DOT_CLK_CONFIG);
+}
+
+/*
+ * Setup memory layout
+ * gx_base: GX register area
+ * mode: Data about the video mode to setup
+ *
+ * This routine assumes unlocked DC registers. Using compressed buffer
+ * is not supported! (makes more sense later, but not while booting)
+ */
+static void dc_setup_layout(void *gx_base,const struct video_mode *mode)
+{
+	unsigned long base = 0x00000000;
+
+	writel(base, gx_base + DC_FB_ST_OFFSET);
+
+	base += (COLOUR_DEPTH>>3) * mode->visible_pixel * mode->visible_lines;
+
+	writel(base, gx_base + DC_CB_ST_OFFSET);
+	writel(base, gx_base + DC_CURS_ST_OFFSET);
+	writel(base, gx_base + DC_VID_ST_OFFSET);
+	writel(((COLOUR_DEPTH>>3) * mode->visible_pixel) >> 2, gx_base + DC_LINE_DELTA);
+	writel(((COLOUR_DEPTH>>3) * mode->visible_pixel) >> 3, gx_base + DC_BUF_SIZE);
+}
+
+/*
+ * Setup the HSYNC/VSYNC, active video timing
+ * gx_base: GX register area
+ * mode: Data about the video mode to setup
+ *
+ * This routine assumes unlocked DC registers
+ *
+ * |<------------------------- htotal ----------------------------->|
+ * |<------------ hactive -------------->|                          |
+ * |                       hblankstart-->|                          |
+ * |                                                    hblankend-->|
+ * |                                hsyncstart-->|                  |
+ * |                                           hsyncend-->|         |
+ * |#####################################___________________________| RGB data
+ * |______________________________________________---------_________| HSYNC
+ *
+ * |<------------------------- vtotal ----------------------------->|
+ * |<------------ vactive -------------->|                          |
+ * |                       vblankstart-->|                          |
+ * |                                                    vblankend-->|
+ * |                                vsyncstart-->|                  |
+ * |                                           vsyncend-->|         |
+ * |#####################################___________________________| line data
+ * |______________________________________________---------_________| YSYNC
+ */
+static void dc_setup_timing(void *gx_base,const struct video_mode *mode)
+{
+	unsigned long hactive, hblankstart, hsyncstart, hsyncend, hblankend, htotal;
+	unsigned long vactive, vblankstart, vsyncstart, vsyncend, vblankend, vtotal;
+
+	hactive = mode->visible_pixel & 0x7FF;
+	hblankstart = hactive;
+	hsyncstart = mode->hsync_start & 0x7FF;
+	hsyncend =  mode->hsync_end & 0x7FF;
+	hblankend = mode->line_length & 0x7FF;
+	htotal = hblankend;
+
+	vactive = mode->visible_lines & 0x7FF;
+	vblankstart = vactive;
+	vsyncstart = mode->vsync_start & 0x7FF;
+	vsyncend =  mode->vsync_end & 0x7FF;
+	vblankend = mode->picture_length & 0x7FF;
+	vtotal = vblankend;
+
+	/* row description */
+	writel((hactive - 1) | ((htotal - 1) << 16), gx_base + DC_H_TIMING_1);
+	/* horizontal blank description */
+	writel((hblankstart - 1) | ((hblankend - 1) << 16), gx_base + DC_H_TIMING_2);
+	/* horizontal sync description */
+	writel((hsyncstart - 1) | ((hsyncend - 1) << 16), gx_base + DC_H_TIMING_3);
+	writel((hsyncstart - 1) | ((hsyncend - 1) << 16), gx_base + DC_FP_H_TIMING);
+
+	/* line description */
+	writel((vactive - 1) | ((vtotal - 1) << 16), gx_base + DC_V_TIMING_1);
+	/* vertical blank description */
+	writel((vblankstart - 1) | ((vblankend - 1) << 16), gx_base + DC_V_TIMING_2);
+	/* vertical sync description */
+	writel((vsyncstart - 1) | ((vsyncend - 1) << 16), gx_base + DC_V_TIMING_3);
+	writel((vsyncstart - 2) | ((vsyncend - 2) << 16), gx_base + DC_FP_V_TIMING);
+}
+
+/*
+ * Setup required internals to bring the mode up and running
+ * gx_base: GX register area
+ * mode: Data about the video mode to setup
+ */
+static void cs5530_activate_mode(void *gx_base, const struct video_mode *mode)
+{
+	writel(0x00000080, gx_base + DC_GENERAL_CFG);
+	mdelay(1);
+	dc_setup_layout(gx_base,mode);
+	dc_setup_timing(gx_base,mode);
+
+	writel(0x2000C581, gx_base + DC_GENERAL_CFG);
+	writel(0x0000002F, gx_base + DC_TIMING_CFG);
+	writel(0x00003004, gx_base + DC_OUTPUT_CFG);
+}
+
+/*
+ * Activate the current mode to be "visible" outside
+ * gx_base: GX register area
+ * mode: Data about the video mode to setup
+ */
+static void cs5530_activate_video(void *io_base, const struct video_mode *mode)
+{
+	u32 val;
+
+	val = mode->sync_pol;
+	val <<= 8;
+
+	writel(val | 0x0020002F, io_base + CS5530_DISPLAY_CONFIG);
+}
+
+/*
+ * This bitmap file must provide:
+ * int width: pixel count in one line
+ * int height: line count
+ * int colours: ount of used colour
+ * unsigned long colour_map[]: RGB 565 colours to be used
+ * unsigned char bitmap[]: index per pixel into colour_map[], width*height pixels
+ */
+#include "bitmap.c"
+
+/*
+ * show a boot splash screen in the right lower corner of the screen
+ * swidth: screen width in pixel
+ * sheight: screen height in lines
+ * pitch: line pitch in bytes
+ * base: screen base address
+ *
+ * This routine assumes we are using a 16 bit colour depth!
+ */
+static void show_boot_splash_16(u32 swidth,u32 sheight,u32 pitch,void *base)
+{
+	int word_count,i;
+	unsigned short *adr;
+	u32 xstart,ystart,x,y;
+	/*
+	 * fill the screen with the colour of the
+	 * left top pixel in the graphic
+	 */
+	word_count = pitch*sheight;
+	printk_debug("Clear Screen at %p, %d words\n",base,word_count);
+	adr = (unsigned short *) base;
+	for (i=0; i < word_count; i++, adr++)
+		*adr = colour_map[bitmap[0]];
+	printk_debug("Ready\n");
+
+	/*
+	 * paint the splash
+	 */
+	xstart=swidth-width;
+	ystart=sheight-height;
+	printk_debug("Start at %u,%u\n",xstart,ystart);
+	for (y=0;y<height;y++) {
+		adr=(unsigned short*)(base + pitch*(y+ystart)+2*xstart);
+		for (x=0;x<width;x++) {
+			*adr=(unsigned short)colour_map[(int)bitmap[x+y*width]];
+			adr++;
+		}
+	}
+}
+
+/*
+ * management part
+ */
+static void cs5530_vga_init(device_t dev)
+{
+	const struct video_mode *mode;
+	void *io_base, *gx_base;
+
+	io_base = (void*)pci_read_config32(dev,0x10);
+	gx_base = (void*)GX_BASE;
+	mode = modes[CONFIG_GX1_VIDEOMODE];
+
+	printk_debug("Setting up video mode %dx%d with %d Hz clock\n",
+		mode->visible_pixel, mode->visible_lines, mode->pixel_clock);
+
+	cs5530_set_clock_frequency(io_base,mode->pll_value);
+
+	writel(DC_UNLOCK_MAGIC, gx_base + DC_UNLOCK);
+
+	show_boot_splash_16(mode->visible_pixel, mode->visible_lines,
+		mode->visible_pixel*(COLOUR_DEPTH>>3),(void*)(GX_BASE+0x800000));
+
+	cs5530_activate_mode(gx_base,mode);
+
+	cs5530_activate_video(io_base, mode);
+	writel(0x00000000, gx_base + DC_UNLOCK);
+}
+
+static struct device_operations vga_ops = {
+	.read_resources   = pci_dev_read_resources,
+	.set_resources    = pci_dev_set_resources,
+	.enable_resources = pci_dev_enable_resources,
+	.init             = cs5530_vga_init,
+	.enable           = NULL /* not required */
+};
+
+static struct pci_driver vga_pci_driver __pci_driver = {
+	.ops 	= &vga_ops,
+	.vendor = PCI_VENDOR_ID_CYRIX,
+	.device = PCI_DEVICE_ID_CYRIX_5530_VIDEO
+};
+
+#endif /* #if CONFIG_GX1_VIDEO == 1 */




From rminnich at gmail.com  Fri Oct  5 23:00:52 2007
From: rminnich at gmail.com (ron minnich)
Date: Fri, 5 Oct 2007 14:00:52 -0700
Subject: [LinuxBIOS] VGA support for Geode GX1/CS5530
In-Reply-To: <200710052243.37625.juergen127@kreuzholzen.de>
References: <200710052129.54369.juergen127@kreuzholzen.de>
	<13426df10710051256l5bcc9ab6i8f19456c64b0450c@mail.gmail.com>
	<200710052243.37625.juergen127@kreuzholzen.de>
Message-ID: <13426df10710051400v3a49310i8f3264e694d04b64@mail.gmail.com>

Committed revision 2827.

and thanks!

ron



From uwe at hermann-uwe.de  Fri Oct  5 23:20:54 2007
From: uwe at hermann-uwe.de (Uwe Hermann)
Date: Fri, 5 Oct 2007 23:20:54 +0200
Subject: [LinuxBIOS] Tyan Thunder n3600R (S2912) support status?
In-Reply-To: <2ea3fae10710051328v17fc5fb7v8b3284670778c017@mail.gmail.com>
References: <4705EAC4.5030302@ornia.hampshire.edu>
	<2ea3fae10710051104i41d0d010r2462f918c742b501@mail.gmail.com>
	<20071005184730.GB9912@greenwood>
	<2ea3fae10710051328v17fc5fb7v8b3284670778c017@mail.gmail.com>
Message-ID: <20071005212054.GA7148@greenwood>

On Fri, Oct 05, 2007 at 01:28:42PM -0700, yhlu wrote:
> > CPU ==>yes
> > RAM ===> yes
> > IDE ===> yes
> > IDE using CF-to-IDE adapter ===>  not tested
> > SATA ==> yes
> > USB ==> yes
> > On-board ethernet ===> yes
> > On-board audio ====> N/A
> > PCI add-on cards ===> N/A
> > PCI Express add-on cards ===> display card
> > Floppy ===> why? not tested
> > Serial port (COM1) Yes
> > Serial port (COM2) ?
> > Parallel port ===> why? not tested
> > PS/2 keyboard ===> why? not tested
> > PS/2 mouse ===> why? not tested
> > Mainboard sensors/fans ===> N/A
> > CPU frequency scaling / powersave modes ===>no acpi, so no
> > Flashrom ==========> not test, i had rom emulator
> 
> HTX card: from infipath? works.

Great, thanks!

I created a wiki page for this board here:
http://linuxbios.org/index.php/Tyan_S2912_Build_Tutorial

Please check the information and correct it or add more items as you see fit.


Thanks, Uwe.
-- 
http://www.hermann-uwe.de  | http://www.holsham-traders.de
http://www.crazy-hacks.org | http://www.unmaintained-free-software.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20071005/3c769866/attachment.sig>

From uwe at hermann-uwe.de  Fri Oct  5 23:27:07 2007
From: uwe at hermann-uwe.de (Uwe Hermann)
Date: Fri, 5 Oct 2007 23:27:07 +0200
Subject: [LinuxBIOS] Tyan Thunder n3600R (S2912) support status?
In-Reply-To: <2ea3fae10710051328v17fc5fb7v8b3284670778c017@mail.gmail.com>
References: <4705EAC4.5030302@ornia.hampshire.edu>
	<2ea3fae10710051104i41d0d010r2462f918c742b501@mail.gmail.com>
	<20071005184730.GB9912@greenwood>
	<2ea3fae10710051328v17fc5fb7v8b3284670778c017@mail.gmail.com>
Message-ID: <20071005212707.GB7148@greenwood>

Oh, I almost forgot...

On Fri, Oct 05, 2007 at 01:28:42PM -0700, yhlu wrote:
> > CPU ==>yes
> > RAM ===> yes
> > IDE ===> yes
> > IDE using CF-to-IDE adapter ===>  not tested
> > SATA ==> yes
> > USB ==> yes
> > On-board ethernet ===> yes
> > On-board audio ====> N/A
> > PCI add-on cards ===> N/A
> > PCI Express add-on cards ===> display card
> > Floppy ===> why? not tested

Sure, the typical server admin probably doesn't care about this type of
stuff, but I think in general we want to fully support _all_ the
hardware which is available on the board.

Thus, I think we should have a common Status table in the wiki for _all_
boards and we should explicitly test all available hardware parts in
LinuxBIOS so we have an exact status report as possible for each board.

Our users will surely appreciate it.


> > Serial port (COM1) Yes
> > Serial port (COM2) ?
> > Parallel port ===> why? not tested
> > PS/2 keyboard ===> why? not tested
> > PS/2 mouse ===> why? not tested
> > Mainboard sensors/fans ===> N/A

The spec page says 

- Winbond W83627HF Super IO
- Analog Devices ADT7476 Hardware Monitoring IC

Don't those two provide sensors of various kinds? Did you test any of
them (via lm-sensors probably)?


Uwe.
-- 
http://www.hermann-uwe.de  | http://www.holsham-traders.de
http://www.crazy-hacks.org | http://www.unmaintained-free-software.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20071005/09a61fcd/attachment.sig>

From c-d.hailfinger.devel.2006 at gmx.net  Fri Oct  5 18:11:48 2007
From: c-d.hailfinger.devel.2006 at gmx.net (Carl-Daniel Hailfinger)
Date: Fri, 05 Oct 2007 18:11:48 +0200
Subject: [LinuxBIOS] Gigabyte M61P-S3 board
In-Reply-To: <8233f01e0710011721y3172ca57yfcf828607a9ab0b7@mail.gmail.com>
References: <8233f01e0709282036g2e36de0bv2c9dca2e42e5f0ae@mail.gmail.com>	
	<46FE3D5E.5050606@gmx.net>	
	<8233f01e0710011720i589d3425ied94a371effb3da@mail.gmail.com>
	<8233f01e0710011721y3172ca57yfcf828607a9ab0b7@mail.gmail.com>
Message-ID: <47066244.1010508@gmx.net>

Hi Michael,

On 02.10.2007 02:21, Michael van der Kolff wrote:
> Uhm, just forgot to attach the additional patch I applied.  Here it comes :)
> 
> On 10/2/07, Michael van der Kolff <mvanderkolff at gmail.com> wrote:
>>
>> I just used r2816 with linuxbios_flashrom_ite_spi_restructured3.diff,
>> along with the attached patch (which just adds the different it8716 id
>> used on the GA-M61P-S3 board) and got the following output from
>> flashrom -V -m gigabyte:m61ps3
>>
>> Calibrating delay loop... 793M loops per second. ok
>> No LinuxBIOS table found.
>> WARNING: No chipset found. Flash detection will most likely fail.
>> Found board "GIGABYTE GA-M61P-S3": Enabling flash write... Serial
>> flash segment 0xfffe0000-0xffffffff enabled
>> Serial flash segment 0x000e0000-0x000fffff enabled
>> Serial flash segment 0xffee0000-0xffefffff disabled
>> Serial flash segment 0xfff80000-0xfffeffff enabled
>> LPC write to serial flash enabled
>> serial flash pin 29
>> OK. [...]
>> Probing for MX25L4005, 512 KB
>> RDID returned c2 20 13
>> probe_spi: id1 0xc2, id2 0x2013
>> MX25L4005 found at physical address: 0xfff80000
>> Flash part is MX25L4005 (512 KB)
>> OK, only ENABLING flash write, but NOT FLASHING.

Can you resend the patch with a signed-off-by statement
(http://linuxbios.org/Development_Guidelines#Sign-off_Procedure)
and a changelog entry? My code is now in subversion, so you might want
to rediff your patch and check whether everything still works.

You can then include the following Acked-by in your mail:
Acked-by: Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006 at gmx.net>

Regards,
Carl-Daniel




From c-d.hailfinger.devel.2006 at gmx.net  Fri Oct  5 18:03:48 2007
From: c-d.hailfinger.devel.2006 at gmx.net (Carl-Daniel Hailfinger)
Date: Fri, 05 Oct 2007 18:03:48 +0200
Subject: [LinuxBIOS] FW: ADLO progress
In-Reply-To: <01ec01c8060f$94ff3b10$4d22040a@chimp>
References: <01ec01c8060f$94ff3b10$4d22040a@chimp>
Message-ID: <47066064.9070105@gmx.net>

On 04.10.2007 00:48, Myles Watson wrote:
> These are all patches to ADLO/bios/rombios.c
> 
> They should be applied in this order:
> whitespace.patch
> defines.patch
> printf.patch
> ide_atapi.patch
> 
> ide.2.3.5.patch is a patch against the latest bios from Bochs.
> 
> The status is that I've eliminated the flakiness.  It boots into the windows
> install CD every time, reports my IDE drives correctly, and can install
> windows.

Nice. The preferred way to inclusion (at least as far as I am concerned)
would be like this:
1. Find out the remaining differences between our version of rombios.c
and (a possibly older version of) upstream and if there are any, try to
get them merged upstream (with reasonable changelog, if possible).
2. Prepare patches with detailed changelogs against upstream rombios.c
3. Take feedback from upstream and refine the patches
4. Submit a megapatch to LinuxBIOS which brings the ADLO version of
rombios.c to the state of upstream.

However, I'm still confused why Bochs can install/boot Vista without
problems (at least that's what was reported on their mailing list) and
ADLO seems to need patches.

A couple of comments below:

> +int await_ide();
> +static int await_ide(when_done,base,timeout)
> +  Bit8u when_done;
> +  Bit16u base;
> +  Bit16u timeout;
> +{
> +  Bit32u time=0,last=0;
> +  Bit16u status;
> +  Bit8u result;
> +  status = inb(base + ATA_CB_STAT); // for the times you're supposed to throw one away
> +  for(;;) {
> +    status = inb(base+ATA_CB_STAT);
> +    time++;
> +    if (when_done == BSY)
> +      result = status & ATA_CB_STAT_BSY;
> +    else if (when_done == NOT_BSY)
> +      result = !(status & ATA_CB_STAT_BSY);
> +    else if (when_done == NOT_BSY_DRQ)
> +      result = !(status & ATA_CB_STAT_BSY) && (status & ATA_CB_STAT_DRQ);
> +    else if (when_done == NOT_BSY_NOT_DRQ)
> +      result = !(status & ATA_CB_STAT_BSY) && !(status & ATA_CB_STAT_DRQ);
> +    else if (when_done == NOT_BSY_RDY)
> +      result = !(status & ATA_CB_STAT_BSY) && (status & ATA_CB_STAT_RDY);
> +    else if (when_done == TIMEOUT)
> +      result = 0;

No final else, so result is possibly undefined.

> +
> +    if (result) return 0;
> +    if (time>>16 != last) // mod 2048 each 16 ms

Please explain what the comment has to do with the code.

> +    {
> +      last = time >>16;
> +      BX_DEBUG_ATA("await_ide: (TIMEOUT,BSY,!BSY,!BSY_DRQ,!BSY_!DRQ) %d time= %ld timeout= %d\n",when_done,time>>11, timeout);
> +      print_status(base);
> +    }
> +    if (status & ATA_CB_STAT_ERR)
> +    {
> +      BX_DEBUG_ATA("await_ide: ERROR (TIMEOUT,BSY,!BSY,!BSY_DRQ,!BSY_!DRQ) %d time= %ld timeout= %d\n",when_done,time>>11, timeout);
> +      print_status(base);
> +      return -1;
> +    }
> +    if ((timeout == 0) || ((time>>11) > timeout)) break;
> +  }
> +  BX_INFO("IDE time out\n");
> +  return -1;
> +}
[...]
> @@ -2233,7 +2306,22 @@
>        write_byte(ebda_seg,&EbdaData->ata.devices[device].type,ATA_TYPE_UNKNOWN);
>  
>        // reset the channel
> -      ata_reset(device);
> +        // ATA-4
> +        // 9.3.1-2 Software reset - Device 0 or 1
> +        // 9.3.1 (a), 9.3.2 (a) -- set SRST in DC
> +        outb(iobase2+ATA_CB_DC, ATA_CB_DC_HD15 | ATA_CB_DC_NIEN | ATA_CB_DC_SRST);
> +        udelay(); udelay(); udelay(); udelay(); udelay(); //5 us
> +
> +        // 9.3.1 (c), 9.3.2 (c) -- wait for BSY
> +        await_ide(BSY, iobase1, IDE_TIMEOUT);
> +
> +        // 9.3.1 (f), 9.3.2 (g) -- clear SRST
> +        outb(iobase2+ATA_CB_DC, ATA_CB_DC_HD15 | ATA_CB_DC_NIEN);
> +
> +        // 9.3.1 (l), 9.3.2 (m) -- wait for !BSY
> +        await_ide(NOT_BSY, iobase1, IDE_TIMEOUT);
> +
> +        // 9.3.1 (m), 9.3.2 (n) -- wait for !BSY and DRDY if not ATA_TYPE_ATAPI
>  
>        // check for ATA or ATAPI
>        outb(iobase1+ATA_CB_DH, slave ? ATA_CB_DH_DEV1 : ATA_CB_DH_DEV0);

Any reason to open-code ata_reset()?

There are a few other issues with the patches, but since they did not
have any changelogs, I am not sure what the patches try to achieve.

Regards,
Carl-Daniel




From c-d.hailfinger.devel.2006 at gmx.net  Fri Oct  5 18:14:23 2007
From: c-d.hailfinger.devel.2006 at gmx.net (Carl-Daniel Hailfinger)
Date: Fri, 05 Oct 2007 18:14:23 +0200
Subject: [LinuxBIOS] [RFC] FILO normal/fallback boot patch
In-Reply-To: <46F2DB30.5090809@gmail.com>
References: <46F2DB30.5090809@gmail.com>
Message-ID: <470662DF.1050103@gmx.net>

On 20.09.2007 22:42, Corey Osgood wrote:
> Dunno if anyone's ever wanted/done this before, but the attached patch
> adds a fallback boot option to FILO, so that if the first kernel fails,
> the second one gets booted, if that fails it drops to the usual command
> line. I'm using it on Magden's system to try to boot from USB before
> going to the hard drive, but I imagine it could be used for CD-ROM, etc,
> just as easily. The fallback boot is entirely optional, if not defined
> it's just ignored. Also, this won't break Peter's filo speedup patch,
> except the changes to the default config file (which I'll fix and send
> another patch, if need be). It needs a little more prettying up and some
> comments if it were to get committed, but if people don't want it I
> won't bother.

I like the idea, but I have no coding experience with FILO, so I'm
reluctant to say anything definitive.

Stefan? Ron?

Regards,
Carl-Daniel




From c-d.hailfinger.devel.2006 at gmx.net  Fri Oct  5 18:41:05 2007
From: c-d.hailfinger.devel.2006 at gmx.net (Carl-Daniel Hailfinger)
Date: Fri, 05 Oct 2007 18:41:05 +0200
Subject: [LinuxBIOS] [PATCH] pci_rom.c checksum extension rom
In-Reply-To: <1191368918.29835.17.camel@localhost>
References: <1188904675.17055.2.camel@localhost>	
	<20070905022911.GA31013@coresystems.de>	
	<1189162475.26302.55.camel@localhost>
	<1189625835.19904.6.camel@localhost>	 <46FEC872.1000004@gmx.net>
	<1191368918.29835.17.camel@localhost>
Message-ID: <47066921.1050000@gmx.net>

On 03.10.2007 01:48, Alex Beregszaszi wrote:
> On Sat, 2007-09-29 at 23:49 +0200, Carl-Daniel Hailfinger wrote:
>> On 12.09.2007 21:37, Alex Beregszaszi wrote:
>>> Hi,
>>>
>>> On Fri, 2007-09-07 at 12:54 +0200, Alex Beregszaszi wrote:
>>>> Hi,
>>>>
>>>> On Wed, 2007-09-05 at 04:29 +0200, Stefan Reinauer wrote:
>>>>> * Alex Beregszaszi <alex at rtfs.hu> [070904 13:17]:
>>>>>> Hi,
>>>>>>
>>>>>> the attached patch adds code to checksum the pci extension rom and stop
>>>>>> if the stored and calculated checksum differ.
>>>>> Is this checksum reliably correct? I am hesitating to add new
>>>>> restrictions that might break otherwise working cards.
>>>> You are right, attached is a correct method. There is no fixed checksum
>>>> byte, instead the whole should sum to zero.
>>> Any comments on this?
>> I like it. I'd give you an Ack, but I have no hardware to test with.
>>
>> Stefan? Ron?
>>
>> Worst case would be that buggy extension ROMs break with a really loud
>> warning, so anybody with such ROMs will see it prominently in the logs.
>>
>> Alex: Is there an easy way to check extension ROMs in the current
>> machine for correct signatures? Maybe standalone utility or such stuff.
> 
> There is no utility for that, but you could copy out the memory between
> 0xc0000 - 0xf00000 from /dev/mem and search for extension headers in it
> (see the code in pci_rom.c).

Can you commit with the following changelog?

--------
The attached patch adds code to checksum the pci extension rom and abort
if the stored and calculated checksum differ.

Worst case would be that buggy extension ROMs break with a really loud
warning, so anybody with such ROMs will see it prominently in the logs.

There is no easy way to check extension ROMs in the current machine for
correct signatures, but you could copy out the memory between 0xc0000 -
0xf00000 from /dev/mem and search for extension headers in it (see the
code in pci_rom.c).
--------

Acked-by: Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006 at gmx.net>

Regards,
Carl-Daniel




From c-d.hailfinger.devel.2006 at gmx.net  Fri Oct  5 18:31:20 2007
From: c-d.hailfinger.devel.2006 at gmx.net (Carl-Daniel Hailfinger)
Date: Fri, 05 Oct 2007 18:31:20 +0200
Subject: [LinuxBIOS] [PATCH] Support other than 0xC000 ROMs in VM86
In-Reply-To: <1189009010.17055.107.camel@localhost>
References: <1188925040.17055.40.camel@localhost>	<20070905014527.GB10233@coresystems.de>
	<1189009010.17055.107.camel@localhost>
Message-ID: <470666D8.4050704@gmx.net>

Stefan? I think you wanted to Ack this as well. Alex will then commit.

Alex Beregszaszi wrote:
> If you say ack, let me commit this, as I missed my last opportunity to
> commit :)

> this patch changes the real_mode_switch_call_vga() function to jump to
> the addr given as an argument instead the hardcoded 0xc000.
> 
> Also it changes the function to inline assembly and passes the arguments
> through that.

Can you commit the changes above as separate revisions? First the inline
assembly change, then the variable addr stuff. This makes the changes
easier to follow.

> Signed-off-by: Alex Beregszaszi <alex at rtfs.hu>

Acked-by: Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006 at gmx.net>

Carl-Daniel

> Index: util/x86emu/vm86.c
> ===================================================================
> --- util/x86emu/vm86.c	(revision 494)
> +++ util/x86emu/vm86.c	(working copy)
> @@ -5,6 +5,7 @@
>   *  Copyright (C) 2001 University of California.  LA-CC Number 01-67.
>   *  Copyright (C) 2005 Nick.Barker9 at btinternet.com
>   *  Copyright (C) 2007 coresystems GmbH
> + *  Copyright (C) 2007 Siqon Ltd. (written by Alex Beregszaszi)
>   *
>   *  This program is free software; you can redistribute it and/or modify
>   *  it under the terms of the GNU General Public License as published by
> @@ -98,7 +99,7 @@
>  );
>  
>  /* The address arguments to this function are PHYSICAL ADDRESSES */ 
> -static void real_mode_switch_call_vga(unsigned long devfn)
> +static void real_mode_switch_call_vga(unsigned long devfn, unsigned long addr)
>  {
>  	__asm__ __volatile__ (
>  		/* paranoia -- does ecx get saved? not sure. 
> @@ -106,16 +107,12 @@
>  		 */
>  		"	pushal			\n"
>  		/* save the stack */
> -		"	mov 	%esp, __stack	\n"
> +		"	mov 	%%esp, __stack	\n"
>  		"	jmp 	1f		\n"
>  		"__stack: .long 0		\n"
>  		"1:\n"
> -		/* get devfn into %ecx */
> -		"	movl    %esp, %ebp	\n"
> -		// FIXME: why is this 8? 
> -		"	movl    8(%ebp), %ecx	\n"
>  		/* load 'our' gdt */
> -		"	lgdt	%cs:__mygdtaddr	\n"
> +		"	lgdt	%%cs:__mygdtaddr	\n"
>  
>  		/*  This configures CS properly for real mode. */
>  		"	ljmp	$0x28, $__rms_16bit\n"
> @@ -128,17 +125,17 @@
>  		 * configurations (limits, writability, etc.) once 
>  		 * protected mode is turned off. 
>  		 */
> -		"	mov	$0x30, %ax	\n"
> -		"	mov	%ax, %ds       	\n"
> -		"	mov	%ax, %es       	\n"
> -		"	mov	%ax, %fs       	\n"
> -		"	mov	%ax, %gs       	\n"
> -		"	mov	%ax, %ss       	\n"
> +		"	mov	$0x30, %%ax	\n"
> +		"	mov	%%ax, %%ds       	\n"
> +		"	mov	%%ax, %%es       	\n"
> +		"	mov	%%ax, %%fs       	\n"
> +		"	mov	%%ax, %%gs       	\n"
> +		"	mov	%%ax, %%ss       	\n"
>  
>  		/* Turn off protection (bit 0 in CR0) */
> -		"	movl	%cr0, %eax	\n"
> -		"	andl	$0xFFFFFFFE, %eax \n"
> -		"	movl	%eax, %cr0	\n"
> +		"	movl	%%cr0, %%eax	\n"
> +		"	andl	$0xFFFFFFFE, %%eax \n"
> +		"	movl	%%eax, %%cr0	\n"
>  
>  		/* Now really going into real mode */
>  		"	ljmp	$0,  $__rms_real\n"
> @@ -148,33 +145,49 @@
>  		 * That way we can easily share it between real and
>  		 * protected, since the 16-bit ESP at segment 0 will 
>  		 * work for any case. */
> -		"	mov	$0x0, %ax	\n"
> -		"	mov	%ax, %ss	\n"
> -		"	movl	$0x1000, %eax	\n"
> -		"	movl	%eax, %esp	\n"
> +		"	mov	$0x0, %%ax	\n"
> +		"	mov	%%ax, %%ss	\n"
> +		"	movl	$0x1000, %%eax	\n"
> +		"	movl	%%eax, %%esp	\n"
>  
>  		/* Load our 16 it idt */
> -		"	xor	%ax, %ax	\n"
> -		"	mov	%ax, %ds	\n"
> +		"	xor	%%ax, %%ax	\n"
> +		"	mov	%%ax, %%ds	\n"
>  		"	lidt	__myidt		\n"
>  
>  		/* Dump zeros in the other segment registers */
> -		"	mov	%ax, %es       	\n"
> -		"	mov	%ax, %fs       	\n"
> -		"	mov	%ax, %gs       	\n"
> -		"	mov	$0x40, %ax	\n"
> -		"	mov	%ax, %ds	\n"
> -		"	mov	%cx, %ax	\n"
> +		"	mov	%%ax, %%es       	\n"
> +		"	mov	%%ax, %%fs       	\n"
> +		"	mov	%%ax, %%gs       	\n"
> +		"	mov	$0x40, %%ax	\n"
> +		"	mov	%%ax, %%ds	\n"
> +		"	mov	%%cx, %%ax	\n"
>  
>  		/* run VGA BIOS at 0xc000:0003 */
> -		"	lcall	$0xc000, $0x0003\n"
> +/*		"	lcall	$0xc000, $0x0003   \n"*/
>  
> +		/* calculate addr */
> +		"       mov     %%edx, %%ebx      \n"
> +		"       add     $3, %%ebx        \n"
> +		"       and     $0xffff, %%ebx   \n"
> +		/* calculate segment */
> +		"       and     $0xf0000, %%edx  \n"
> +		"       shr     $4, %%edx        \n"
> +
> +		"       pushw   %%dx             \n"
> +		"       pushw   %%bx             \n"
> +		"       mov     %%esp, %%ebp      \n"
> +		/* idea from bochs bios' rom_scan */
> +		/* call far ss:[bp+0] */
> +		"       .byte 0xff, 0x5e, 0x00   \n"
> +		"       add     $4, %%esp         \n"
> +
>  		/* If we got here, just about done. 
>  		 * Need to get back to protected mode 
>  		 */
> -		"	movl	%cr0, %eax	\n"
> -		"	orl	$0x0000001, %eax\n" /* PE = 1 */
> -		"	movl	%eax, %cr0	\n"
> +		"	movl	%%cr0, %%eax	\n"
> +		"	orl	$0x0000001, %%eax\n" /* PE = 1 */
> +		"	movl	%%eax, %%cr0	\n"
>  
>  		/* Now that we are in protected mode 
>  		 * jump to a 32 bit code segment. 
> @@ -182,21 +195,23 @@
>  		"	data32	ljmp	$0x10, $vgarestart\n"
>  		"vgarestart:\n"
>  		"	.code32\n"
> -		"	movw	$0x18, %ax     	\n"
> -		"	mov	%ax, %ds       	\n"
> -		"	mov	%ax, %es	\n"
> -		"	mov	%ax, %fs	\n"
> -		"	mov	%ax, %gs	\n"
> -		"	mov	%ax, %ss	\n"
> +		"	movw	$0x18, %%ax     	\n"
> +		"	mov	%%ax, %%ds       	\n"
> +		"	mov	%%ax, %%es	\n"
> +		"	mov	%%ax, %%fs	\n"
> +		"	mov	%%ax, %%gs	\n"
> +		"	mov	%%ax, %%ss	\n"
>  
>  		/* restore proper gdt and idt */
> -		"	lgdt	%cs:gdtarg	\n"
> +		"	lgdt	%%cs:gdtarg	\n"
>  		"	lidt	idtarg		\n"
>  
>  		".globl vga_exit		\n"
>  		"vga_exit:			\n"
> -		"	mov	__stack, %esp	\n"
> +		"	mov	__stack, %%esp	\n"
>  		"	popal			\n"
> +		:
> +		: "c" (devfn), "d" (addr)
>  		);
>  }
>  
> @@ -315,8 +330,8 @@
>  	for (i = 0x400; i < 0x500; i++) {
>  		*(unsigned char *) i = 0;
>  	}
> -
> -	real_mode_switch_call_vga((dev->bus->secondary << 8) | dev->path.u.pci.devfn);
> +	
> +	real_mode_switch_call_vga((dev->bus->secondary << 8) | dev->path.u.pci.devfn, addr);
>  }
>  
>  
> 





From info at coresystems.de  Fri Oct  5 23:48:23 2007
From: info at coresystems.de (LinuxBIOS information)
Date: Fri, 05 Oct 2007 23:48:23 +0200
Subject: [LinuxBIOS] r2827 build service
Message-ID: <E1Idv1z-0005Tj-IV@khepri.openbios.org>

Dear LinuxBIOS readers!

This is the automated build check service of LinuxBIOS.

The developer "rminnich" checked in revision 2827 to
the LinuxBIOS source repository and caused the following 
changes:

Change Log:

This patch will add support for the Geode GX1/CS5530 VGA feature. It's able
to set up one of five screen resolutions (sorry no autodetection at runtime,
resolution is selected at buildtime) and displays a graphic in the right
bottom corner (splash screen).

Signed-off-by: Juergen Beisert <juergen127 at kreuzholzen.de>
Acked-by: Ronald G. Minnich <rminnich at gmail.com>
Acked-by: Stefan Reinauer <stepan at coresystems.de>




Build Log:
Compilation of arima:hdama is still broken
See the error log at http://qa.linuxbios.org/log_buildbrd.php?revision=2827&device=hdama&vendor=arima
Compilation of ibm:e325 is still broken
See the error log at http://qa.linuxbios.org/log_buildbrd.php?revision=2827&device=e325&vendor=ibm
Compilation of ibm:e326 is still broken
See the error log at http://qa.linuxbios.org/log_buildbrd.php?revision=2827&device=e326&vendor=ibm
Compilation of iei:juki-511p is still broken
See the error log at http://qa.linuxbios.org/log_buildbrd.php?revision=2827&device=juki-511p&vendor=iei
Compilation of iwill:dk8s2 is still broken
See the error log at http://qa.linuxbios.org/log_buildbrd.php?revision=2827&device=dk8s2&vendor=iwill
Compilation of iwill:dk8x is still broken
See the error log at http://qa.linuxbios.org/log_buildbrd.php?revision=2827&device=dk8x&vendor=iwill
Compilation of newisys:khepri is still broken
See the error log at http://qa.linuxbios.org/log_buildbrd.php?revision=2827&device=khepri&vendor=newisys


If something broke during this checkin please be a pain 
in rminnich's neck until the issue is fixed.

If this issue is not fixed within 24h the revision should 
be backed out.

   Best regards,
     LinuxBIOS automatic build system





From uwe at hermann-uwe.de  Fri Oct  5 23:50:00 2007
From: uwe at hermann-uwe.de (Uwe Hermann)
Date: Fri, 5 Oct 2007 23:50:00 +0200
Subject: [LinuxBIOS] VGA support for Geode GX1/CS5530
In-Reply-To: <200710052243.37625.juergen127@kreuzholzen.de>
References: <200710052129.54369.juergen127@kreuzholzen.de>
	<13426df10710051256l5bcc9ab6i8f19456c64b0450c@mail.gmail.com>
	<200710052243.37625.juergen127@kreuzholzen.de>
Message-ID: <20071005215000.GC7148@greenwood>

On Fri, Oct 05, 2007 at 10:43:37PM +0200, Juergen Beisert wrote:
> This patch will add support for the Geode GX1/CS5530 VGA feature. Its able
> to set up one of five screen resolutions (sorry no autodetection at runtime,
> resolution is selected at buildtime) and displays a graphic in the right
> bottom corner (splash screen).

Nice! So this is in-LinuxBIOS VGA support? I.e. without running any VGA
option ROM blob in an emulator?

I'll give it a try on my CS5530 box in a few days (no access right now).


> +#if CONFIG_GX1_VIDEO == 1
> +/*
> + * Some register descriptions that are no listed in cpu/amd/gx1def.h
> + */

Would it make sense to add them to cpu/amd/gx1def.h?
Probably not as they're not CPU related but VGA related?


> +/*
> + * what colour depth should be used as default (in bpp)
> + * Note: Currently no other value than 16 is supported
> + */
> +#define COLOUR_DEPTH 16

Maybe this should be a user-visible config-option in Confib.lb too?


> +/*
> + * Support for a few basic video modes
> + * Note: all modes only for CRT. The flatpanel feature is
> + * not supported here (due to the lack of hardware to test)
> + */
> +struct video_mode {
> +	int pixel_clock;		/*<< pixel clock in Hz */

What is the '/*<<' supposed to mean?


> +/* ModeLine "640x480" 31.5 640 664 704 832 480 489 491 520 -hsync -vsync */
> +static const struct video_mode mode_640x480 = {
> +	/*
> +	 * 640x480 @ 72Hz hsync: 37.9kHz
> +	 * VESA standard mode for classic 4:3 monitors
> +	 */
> +	.pixel_clock = 31500000,
> +	.pll_value = 0x33915801,
> +
> +	.visible_pixel = 640,
> +	.hsync_start = 664,
> +	.hsync_end = 704,	/* 1.27 us sync length */
> +	.line_length = 832,	/* 26.39us */
> +
> +	.visible_lines = 480,
> +	.vsync_start = 489,
> +	.vsync_end = 491,
> +	.picture_length = 520, /* 13.89ms */
> +
> +	.sync_pol = HSYNC_LOW_POL | VSYNC_LOW_POL

Add a trailing comma here please, it's convenient if stuff is added
later (you can easily forget about the comma).


> +/*
> + * Setup the pixel PLL in the companion chip
> + * base: register's base address
> + * pll_val: pll register value to be set
> + */

Please use Doxygen-style comments (not the same as the kerneldoc
format). In this case:

/**
 * Setup the pixel PLL in the companion chip.
 *
 * @param base Register's base address.
 * @param pll_val PLL register value to be set.
 */


> +static void cs5530_set_clock_frequency(void *io_base,unsigned long pll_val)
                                                        ^
                                           missing space

> +{
> +	unsigned long reg;

u64? u32? Not sure.

Please use the types with explicit width and signedness wherever it
possible and whereever it makes sense (registers etc).


> +/*
> + * Activate the current mode to be "visible" outside
> + * gx_base: GX register area
> + * mode: Data about the video mode to setup
> + */
> +static void cs5530_activate_video(void *io_base, const struct video_mode *mode)
> +{
> +	u32 val;
> +
> +	val = mode->sync_pol;
> +	val <<= 8;

Why not this?

  val = mode->sync_pol << 8;

Or maybe even

  u32 val = mode->sync_pol << 8;


> +	writel(val | 0x0020002F, io_base + CS5530_DISPLAY_CONFIG);
> +}
> +
> +/*
> + * This bitmap file must provide:
> + * int width: pixel count in one line
> + * int height: line count
> + * int colours: ount of used colour
> + * unsigned long colour_map[]: RGB 565 colours to be used
> + * unsigned char bitmap[]: index per pixel into colour_map[], width*height pixels
> + */
> +#include "bitmap.c"

Should be a bit more configurable later (specify filename in Config.lb
or so). In v3 this should probably be handled in Kconfig.


> +/*
> + * show a boot splash screen in the right lower corner of the screen
> + * swidth: screen width in pixel
> + * sheight: screen height in lines
> + * pitch: line pitch in bytes
> + * base: screen base address
> + *
> + * This routine assumes we are using a 16 bit colour depth!
> + */
> +static void show_boot_splash_16(u32 swidth,u32 sheight,u32 pitch,void *base)
> +{
> +	int word_count,i;
> +	unsigned short *adr;
> +	u32 xstart,ystart,x,y;
> +	/*
> +	 * fill the screen with the colour of the
> +	 * left top pixel in the graphic
> +	 */
> +	word_count = pitch*sheight;

A few whitespace issues here and in some other places in the code, please
fix that to comply with the coding guidelines.


> Index: LinuxBIOSv2/src/southbridge/amd/cs5530/bitmap.c
> ===================================================================
> --- /dev/null
> +++ LinuxBIOSv2/src/southbridge/amd/cs5530/bitmap.c
> @@ -0,0 +1,304 @@
> +/* do not edit
> +This is an image of size 51 x 60 with 234 colours */

How was this image generated? What's the source format?

Please also attach a license to it if you created it. If you didn't we
must get permission from the author, I guess (and/or state the license
which applies to it).


I can fix up a few of the cosmetic issues in the repository right away
if you want, or I'll wait for another patch. Please let me know...


Uwe.
-- 
http://www.hermann-uwe.de  | http://www.holsham-traders.de
http://www.crazy-hacks.org | http://www.unmaintained-free-software.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20071005/10eb19a6/attachment.sig>

From c-d.hailfinger.devel.2006 at gmx.net  Fri Oct  5 23:52:27 2007
From: c-d.hailfinger.devel.2006 at gmx.net (Carl-Daniel Hailfinger)
Date: Fri, 05 Oct 2007 23:52:27 +0200
Subject: [LinuxBIOS] [PATCH] Call for help: superiotool
In-Reply-To: <20071005153243.aaa117a3.rasmus@wiman.org>
References: <20070923111315.GC12926@greenwood>	<20071002152938.084fdaef.rasmus@wiman.org>	<20071004022202.GA30344@greenwood>
	<20071005153243.aaa117a3.rasmus@wiman.org>
Message-ID: <4706B21B.4070206@gmx.net>

On 05.10.2007 15:32, Rasmus Wiman wrote:
> [...] the datasheet says "Default 0b1s000s0s", a notation I'm unfamiliar
> with, so I set the default to MISC.

AFAIK that is (at least partially) Verilog syntax.

Regards,
Carl-Daniel



From svn at openbios.org  Fri Oct  5 23:58:04 2007
From: svn at openbios.org (svn at openbios.org)
Date: Fri,  5 Oct 2007 23:58:04 +0200
Subject: [LinuxBIOS] r2828 - trunk/util/superiotool
Message-ID: <mailman.703.1355071173.16123.coreboot@coreboot.org>

Author: uwe
Date: 2007-10-05 23:58:03 +0200 (Fri, 05 Oct 2007)
New Revision: 2828

Modified:
   trunk/util/superiotool/winbond.c
Log:
Add dump support for the Winbond W83627HF/F/HG/G.

Signed-off-by: Rasmus Wiman <rasmus at wiman.org>
Acked-by: Uwe Hermann <uwe at hermann-uwe.de>



Modified: trunk/util/superiotool/winbond.c
===================================================================
--- trunk/util/superiotool/winbond.c	2007-10-05 21:00:10 UTC (rev 2827)
+++ trunk/util/superiotool/winbond.c	2007-10-05 21:58:03 UTC (rev 2828)
@@ -2,6 +2,7 @@
  * This file is part of the superiotool project.
  *
  * Copyright (C) 2007 Uwe Hermann <uwe at hermann-uwe.de>
+ * Copyright (C) 2007 Rasmus Wiman <rasmus at wiman.org>
  *
  * This program is free software; you can redistribute it and/or modify
  * it under the terms of the GNU General Public License as published by
@@ -164,6 +165,48 @@
 
 	/* ID only */
 	{0x52, "W83627HF/F/HG/G", {
+		{NOLDN, NULL,
+			{0x02,0x07,0x20,0x21,0x22,0x23,0x24,0x25,0x26,0x28,
+			 0x29,0x2a,0x2b,0x2c,0x2e,0x2f,EOT},
+			{0x00,NANA,0x52,NANA,0xff,0x00,MISC,0x00,0x00,0x00,
+			 0x00,0x7c,0xc0,0x00,0x00,0x00,EOT}},
+		{0x0, "Floppy",
+			{0x30,0x60,0x61,0x70,0x74,0xf0,0xf1,0xf2,0xf4,
+			 0xf5,EOT},
+			{0x01,0x03,0xf0,0x06,0x02,0x0e,0x00,0xff,0x00,
+			 0x00,EOT}},
+		{0x1, "Parallel port",
+			{0x30,0x60,0x61,0x70,0x74,0xf0,EOT},
+			{0x01,0x03,0x78,0x07,0x04,0x3f,EOT}},
+		{0x2, "COM1",
+			{0x30,0x60,0x61,0x70,0xf0,EOT},
+			{0x01,0x03,0xf8,0x04,0x00,EOT}},
+		{0x3, "COM2",
+			{0x30,0x60,0x61,0x70,0xf0,0xf1,EOT},
+			{0x01,0x02,0xf8,0x03,0x00,0x00,EOT}},
+		{0x5, "Keyboard",
+			{0x30,0x60,0x61,0x62,0x63,0x70,0x72,0xf0,EOT},
+			{0x01,0x00,0x60,0x00,0x64,0x01,0x0c,0x80,EOT}},
+		{0x6, "Consumer IR",
+			{0x30,0x60,0x61,0x70,EOT},
+			{0x00,0x00,0x00,0x00,EOT}},
+		{0x7, "Game port, MIDI port, GPIO 1",
+			{0x30,0x60,0x61,0x62,0x63,0x70,0xf0,0xf1,0xf2,EOT},
+			{0x00,0x02,0x01,0x03,0x30,0x09,0xff,0x00,0x00,EOT}},
+		{0x8, "GPIO 2, Watchdog timer",
+			{0x30,0xf0,0xf1,0xf2,0xf3,0xf5,0xf6,0xf6,0xf7,EOT},
+			{0x00,0xff,0x00,0x00,0x00,0x00,0x00,0x00,0x00,EOT}},
+		{0x9, "GPIO 3",
+			{0x30,0xf0,0xf1,0xf2,0xf3,EOT},
+			{0x00,0xff,0x00,0x00,0x00,EOT}},
+		{0xa, "ACPI",
+			{0x30,0x70,0xe0,0xe1,0xe2,0xe3,0xe4,0xe5,0xe6,0xe7,
+			 0xf0,0xf1,0xf3,0xf4,0xf6,0xf7,0xf9,0xfe,0xff,EOT},
+			{0x00,0x00,0x00,0x00,NANA,NANA,0x00,0x00,0x00,0x00,
+			 0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,EOT}},
+		{0xb, "Hardware monitor",
+			{0x30,0x60,0x61,0x70,0xf0,EOT},
+			{0x00,0x00,0x00,0x00,0x00,EOT}},
 		{EOT}}},
 
 	/* ID[3..0] */




From c-d.hailfinger.devel.2006 at gmx.net  Sat Oct  6 00:00:50 2007
From: c-d.hailfinger.devel.2006 at gmx.net (Carl-Daniel Hailfinger)
Date: Sat, 06 Oct 2007 00:00:50 +0200
Subject: [LinuxBIOS] [PATCH] superiotool: Make --version actually work
 correctly
In-Reply-To: <20071005174628.GA9851@greenwood>
References: <20071005174628.GA9851@greenwood>
Message-ID: <4706B412.7080408@gmx.net>

On 05.10.2007 19:46, Uwe Hermann wrote:
> As the svn keyword $Rev$ is not replaced with the global repository ID
> but rather with the ID of the last commit which changed the
> respective file (where $Rev$ is located), the current --version output
> is incorrect.
> 
> This patch fixes the output by keeping a $Rev$ instance in every file
> (which can be different for every file) and then calculating the
> biggest revision (which is our superiotool version) at runtime when
> superiotool is invoked with --version.
> 
> This only takes *.c and *.h files into account, changes to the README
> and other non-code files will no be reflected in the version number.
> But this is actually a good thing in this case, we don't want to bump
> the version number upon README changes anyway.
> 
> Signed-off-by: Uwe Hermann <uwe at hermann-uwe.de>

Nack. Can we switch back to a more sensible versioning scheme (like 0.1
etc.) or at least ask some svn experts whether there is an easier and
cleaner way to include a revision number?
BTW, the $Rev$ output format is ugly beyond words.

Carl-Daniel



From uwe at hermann-uwe.de  Fri Oct  5 23:59:21 2007
From: uwe at hermann-uwe.de (Uwe Hermann)
Date: Fri, 5 Oct 2007 23:59:21 +0200
Subject: [LinuxBIOS] [PATCH] Call for help: superiotool
In-Reply-To: <20071005191502.7e08a759.rasmus@wiman.org>
References: <20070923111315.GC12926@greenwood>
	<20071002152938.084fdaef.rasmus@wiman.org>
	<20071004022202.GA30344@greenwood>
	<20071005153243.aaa117a3.rasmus@wiman.org>
	<20071005153623.GD5376@greenwood>
	<20071005191502.7e08a759.rasmus@wiman.org>
Message-ID: <20071005215921.GD7148@greenwood>

On Fri, Oct 05, 2007 at 07:15:02PM +0200, Rasmus Wiman wrote:
> Signed-off-by: Rasmus Wiman <rasmus at wiman.org>

Thanks, committed in r2828 with some very small cosmetic changes.
I also added you to the Copyright owner list at the top of the file.


Uwe.
-- 
http://www.hermann-uwe.de  | http://www.holsham-traders.de
http://www.crazy-hacks.org | http://www.unmaintained-free-software.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20071005/19de2b76/attachment.sig>

From uwe at hermann-uwe.de  Sat Oct  6 00:08:43 2007
From: uwe at hermann-uwe.de (Uwe Hermann)
Date: Sat, 6 Oct 2007 00:08:43 +0200
Subject: [LinuxBIOS] MSI MS-6337 (i815 based)
In-Reply-To: <63e824e50710031149m169e5543t17f2d58695dc3f99@mail.gmail.com>
References: <63e824e50710031149m169e5543t17f2d58695dc3f99@mail.gmail.com>
Message-ID: <20071005220843.GE7148@greenwood>

On Wed, Oct 03, 2007 at 09:49:26PM +0300, Jouni Mett?l? wrote:
> > Do you have a second computer and a null modem serial cable? If so,
> > please hook it up and see what's coming out of the serial port (I hope
> > you have the same super io).
> 
> I tried with friend laptop. It didn't give anything. Maybe I just can't use
> serial cable and minicom :( I hope better debug next time. Superio  is
> w83627hf in both mainboards (ms-6178 and ms-6337)

OK, on the MS-6178 I can say for sure that serial output works in LinuxBIOS.

Quick minicom tutorial:

$ minicom -s
  -> Serial port setup
  -> Press A and enter your COM device (ttyS0 or ttyS1 or ttyUSB0 or so)
  -> Press E and choose "115200 8N1" (default)
  -> Disable Hardware and Software Flow Control (via F and G)
  -> Press enter to leave the menu
  -> Save setup as..
  ->   Enter "lb"
  -> Exit from minicom

So, from now on you can use this config like this:

$ minicom -o lb


> > Did you get it _that_ small? I'm using a 512KB chip, you cannot stick a
> > kernel into that. Did you use a bigger chip?
> 
> Kernel config (I am no sure if it's the same but it is small) is minimal. It
> boots with proprietary bios and it is just for testing. I had no success
> with filo either. It is used with ubuntu dapper sources. I'll try to attach
> it this week.
> 
> 00:00.0 Host bridge [0600]: Intel Corporation 82815 815 Chipset Host Bridge
> and Memory Controller Hub [8086:1130] (rev 02)
> 00:02.0 VGA compatible controller [0300]: Intel Corporation 82815 Chipset
> Graphics Controller (CGC) [8086:1132] (rev 02)
> 00:1e.0 PCI bridge [0604]: Intel Corporation 82801 PCI Bridge [8086:244e]
> (rev 01)
> 00:1f.0 ISA bridge [0601]: Intel Corporation 82801BA ISA Bridge (LPC)
> [8086:2440] (rev 01)
> 00:1f.1 IDE interface [0101]: Intel Corporation 82801BA IDE U100 Controller
> [8086:244b] (rev 01)
> 00:1f.2 USB Controller [0c03]: Intel Corporation 82801BA/BAM USB Controller
> #1 [8086:2442] (rev 01)
> 00:1f.3 SMBus [0c05]: Intel Corporation 82801BA/BAM SMBus Controller
> [8086:2443] (rev 01)
> 00:1f.4 USB Controller [0c03]: Intel Corporation 82801BA/BAM USB Controller
> #1 [8086:2444] (rev 01)
> 00:1f.5 Multimedia audio controller [0401]: Intel Corporation 82801BA/BAM
> AC'97 Audio Controller [8086:2445] (rev 01)
> 01:00.0 Multimedia audio controller [0401]: Ensoniq ES1371 [AudioPCI-97]
> [1274:1371] (rev 08)
> 01:02.0 Ethernet controller [0200]: Advanced Micro Devices [AMD] 79c978
> [HomePNA] [1022:2001] (rev 52)

So this is the ms-6337, I guess? It's an i815 chipset which is similar,
but not quite the same as i810. Some more work is probably needed for that.


> lspnp: /proc/bus/pnp not available

Strange. Maybe you have to enable some "PnP" option in the BIOS for
lspnp to work?


Uwe.
-- 
http://www.hermann-uwe.de  | http://www.holsham-traders.de
http://www.crazy-hacks.org | http://www.unmaintained-free-software.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20071006/185c0aa8/attachment.sig>

From bishop.robinson at gmail.com  Sat Oct  6 00:10:36 2007
From: bishop.robinson at gmail.com (Robinson Tryon)
Date: Fri, 5 Oct 2007 18:10:36 -0400
Subject: [LinuxBIOS] [PATCH] Call for help: superiotool
In-Reply-To: <20071005215921.GD7148@greenwood>
References: <20070923111315.GC12926@greenwood>
	<20071002152938.084fdaef.rasmus@wiman.org>
	<20071004022202.GA30344@greenwood>
	<20071005153243.aaa117a3.rasmus@wiman.org>
	<20071005153623.GD5376@greenwood>
	<20071005191502.7e08a759.rasmus@wiman.org>
	<20071005215921.GD7148@greenwood>
Message-ID: <a698c16a0710051510q4cacd55apa07f1e037e4d02eb@mail.gmail.com>

On 10/5/07, Uwe Hermann <uwe at hermann-uwe.de> wrote:
> On Fri, Oct 05, 2007 at 07:15:02PM +0200, Rasmus Wiman wrote:
> > Signed-off-by: Rasmus Wiman <rasmus at wiman.org>
>
> Thanks, committed in r2828 with some very small cosmetic changes.
> I also added you to the Copyright owner list at the top of the file.

Should I be adding myself to the copyright owner list at the top of
the files when I add dump support for chips?  I assumed that copying
the tables from the datasheets wouldn't be "creative" enough for me to
assert a copyright on the commit...



From mvanderkolff at gmail.com  Sat Oct  6 00:21:52 2007
From: mvanderkolff at gmail.com (Michael van der Kolff)
Date: Sat, 6 Oct 2007 08:21:52 +1000
Subject: [LinuxBIOS] Gigabyte M61P-S3 board
In-Reply-To: <8233f01e0710011721y3172ca57yfcf828607a9ab0b7@mail.gmail.com>
References: <8233f01e0709282036g2e36de0bv2c9dca2e42e5f0ae@mail.gmail.com>
	<46FE3D5E.5050606@gmx.net>
	<8233f01e0710011720i589d3425ied94a371effb3da@mail.gmail.com>
	<8233f01e0710011721y3172ca57yfcf828607a9ab0b7@mail.gmail.com>
Message-ID: <8233f01e0710051521m66d6781ex809222c9e6bdad69@mail.gmail.com>

Signed-off-by: Michael van der Kolff <mvanderkolff at gmail.com>

On 10/2/07, Michael van der Kolff <mvanderkolff at gmail.com> wrote:
> Uhm, just forgot to attach the additional patch I applied.  Here it comes :)
>
> Cheers,
>
> Michael
>
> On 10/2/07, Michael van der Kolff <mvanderkolff at gmail.com> wrote:
> > Hi, sorry for the late response, was on holidays.
> >
> > I just used r2816 with linuxbios_flashrom_ite_spi_restructured3.diff,
> > along with the attached patch (which just adds the different it8716 id
> > used on the GA-M61P-S3 board) and got the following output from
> > flashrom -V -m gigabyte:m61ps3
> >
> > Calibrating delay loop... 793M loops per second. ok
> > No LinuxBIOS table found.
> > WARNING: No chipset found. Flash detection will most likely fail.
> > Found board "GIGABYTE GA-M61P-S3": Enabling flash write... Serial
> > flash segment 0xfffe0000-0xffffffff enabled
> > Serial flash segment 0x000e0000-0x000fffff enabled
> > Serial flash segment 0xffee0000-0xffefffff disabled
> > Serial flash segment 0xfff80000-0xfffeffff enabled
> > LPC write to serial flash enabled
> > serial flash pin 29
> > OK.
> > Probing for Am29F040B, 512 KB
> > probe_29f040b: id1 0x49, id2 0x4d
> > Probing for Am29F016D, 2048 KB
> > probe_29f040b: id1 0xff, id2 0xff
> > Probing for AE49F2008, 256 KB
> > probe_jedec: id1 0xc6, id2 0x9b
> > Probing for At29C040A, 512 KB
> > probe_jedec: id1 0x49, id2 0x4d
> > Probing for At29C020, 256 KB
> > probe_jedec: id1 0xc6, id2 0x9b
> > Probing for Mx29f002, 256 KB
> > probe_29f002: id1 0xc6, id2 0x9b
> > Probing for MX25L4005, 512 KB
> > RDID returned c2 20 13
> > probe_spi: id1 0xc2, id2 0x2013
> > MX25L4005 found at physical address: 0xfff80000
> > Flash part is MX25L4005 (512 KB)
> > OK, only ENABLING flash write, but NOT FLASHING.
> >
> > and the following output without -m gigabyte:m61ps3
> > Calibrating delay loop... 794M loops per second. ok
> > No LinuxBIOS table found.
> > WARNING: No chipset found. Flash detection will most likely fail.
> > Probing for Am29F040B, 512 KB
> > probe_29f040b: id1 0x49, id2 0x4d
> > Probing for Am29F016D, 2048 KB
> > probe_29f040b: id1 0xff, id2 0xff
> > Probing for AE49F2008, 256 KB
> > probe_jedec: id1 0xc6, id2 0x9b
> > Probing for At29C040A, 512 KB
> > probe_jedec: id1 0x49, id2 0x4d
> > Probing for At29C020, 256 KB
> > probe_jedec: id1 0xc6, id2 0x9b
> > Probing for Mx29f002, 256 KB
> > probe_29f002: id1 0xc6, id2 0x9b
> > Probing for MX25L4005, 512 KB
> > Probing for SST29EE020A, 256 KB
> > probe_jedec: id1 0xc6, id2 0x9b
> > Probing for SST28SF040A, 512 KB
> > probe_28sf040: id1 0x49, id2 0x4d
> > Probing for SST39SF010A, 128 KB
> > probe_jedec: id1 0xff, id2 0xff
> > Probing for SST39SF020A, 256 KB
> > probe_jedec: id1 0xc6, id2 0x9b
> > Probing for SST39SF040, 512 KB
> > probe_jedec: id1 0x49, id2 0x4d
> > Probing for SST39VF020, 256 KB
> > probe_jedec: id1 0xc6, id2 0x9b
> > Probing for SST49LF040B, 512 KB
> > probe_jedec: id1 0x49, id2 0x4d
> > Probing for SST49LF040, 512 KB
> > probe_jedec: id1 0x49, id2 0x4d
> > Probing for SST49LF020A, 256 KB
> > probe_jedec: id1 0xc6, id2 0x9b
> > Probing for SST49LF080A, 1024 KB
> > probe_jedec: id1 0xff, id2 0xff
> > Probing for SST49LF002A/B, 256 KB
> > probe_jedec: id1 0xc6, id2 0x9b
> > Probing for SST49LF003A/B, 384 KB
> > probe_jedec: id1 0x2e, id2 0x1f
> > Probing for SST49LF004A/B, 512 KB
> > probe_jedec: id1 0x49, id2 0x4d
> > Probing for SST49LF008A, 1024 KB
> > probe_jedec: id1 0xff, id2 0xff
> > Probing for SST49LF004C, 512 KB
> > probe_49lfxxxc: id1 0x49, id2 0x4d
> > Probing for SST49LF008C, 1024 KB
> > probe_49lfxxxc: id1 0xff, id2 0xff
> > Probing for SST49LF016C, 2048 KB
> > probe_49lfxxxc: id1 0xff, id2 0xff
> > Probing for SST49LF160C, 2048 KB
> > probe_49lfxxxc: id1 0xff, id2 0xff
> > Probing for Pm49FL002, 256 KB
> > probe_jedec: id1 0xc6, id2 0x9b
> > Probing for Pm49FL004, 512 KB
> > probe_jedec: id1 0x49, id2 0x4d
> > Probing for W29C011, 128 KB
> > probe_jedec: id1 0xff, id2 0xff
> > Probing for W29C040P, 512 KB
> > probe_jedec: id1 0x49, id2 0x4d
> > Probing for W29C020C, 256 KB
> > probe_jedec: id1 0xc6, id2 0x9b
> > Probing for W29EE011, 128 KB
> > probe_w29ee011: id1 0xff, id2 0xff
> > Probing for W49F002U, 256 KB
> > probe_jedec: id1 0xc6, id2 0x9b
> > Probing for W49V002A, 256 KB
> > probe_jedec: id1 0xc6, id2 0x9b
> > Probing for W49V002FA, 256 KB
> > probe_jedec: id1 0xc6, id2 0x9b
> > Probing for W39V040FA, 512 KB
> > probe_jedec: id1 0x49, id2 0x4d
> > Probing for W39V040A, 512 KB
> > probe_jedec: id1 0x49, id2 0x4d
> > Probing for W39V040B, 512 KB
> > probe_jedec: id1 0x49, id2 0x4d
> > Probing for W39V080A, 1024 KB
> > probe_jedec: id1 0xff, id2 0xff
> > Probing for M29F002B, 256 KB
> > probe_jedec: id1 0xc6, id2 0x9b
> > Probing for M50FW040, 512 KB
> > probe_jedec: id1 0x49, id2 0x4d
> > Probing for M29W040B, 512 KB
> > probe_jedec: id1 0x49, id2 0x4d
> > Probing for M29F002T/NT, 256 KB
> > probe_jedec: id1 0xc6, id2 0x9b
> > Probing for M29F400BT, 512 KB
> > probe_m29f400bt: id1 0x49, id2 0x44
> > Probing for M50FLW040A, 512 KB
> > probe_jedec: id1 0x49, id2 0x4d
> > Probing for M50FLW040B, 512 KB
> > probe_jedec: id1 0x49, id2 0x4d
> > Probing for M50FLW080A, 1024 KB
> > probe_jedec: id1 0xff, id2 0xff
> > Probing for M50FLW080B, 1024 KB
> > probe_jedec: id1 0xff, id2 0xff
> > Probing for M50FW080, 1024 KB
> > probe_jedec: id1 0xff, id2 0xff
> > Probing for M50FW016, 2048 KB
> > probe_jedec: id1 0xff, id2 0xff
> > Probing for M50LPW116, 2048 KB
> > probe_jedec: id1 0xff, id2 0xff
> > Probing for M29W010B, 128 KB
> > probe_jedec: id1 0xff, id2 0xff
> > Probing for M29F040B, 512 KB
> > probe_29f040b: id1 0x49, id2 0x4d
> > Probing for 82802ab, 512 KB
> > probe_82802ab: id1 0x49, id2 0x4d
> > Probing for 82802ac, 1024 KB
> > probe_82802ab: id1 0xff, id2 0xff
> > Probing for F49B002UA, 256 KB
> > probe_jedec: id1 0xc6, id2 0x9b
> > Probing for LHF00L04, 1024 KB
> > probe_lhf00l04: id1 0xff, id2 0xff
> > Probing for S29C51001T, 128 KB
> > probe_jedec: id1 0xff, id2 0xff
> > Probing for S29C51002T, 256 KB
> > probe_jedec: id1 0xc6, id2 0x9b
> > Probing for S29C51004T, 512 KB
> > probe_jedec: id1 0x49, id2 0x4d
> > Probing for S29C31004T, 512 KB
> > probe_jedec: id1 0x49, id2 0x4d
> > No EEPROM/flash device found.
> >
> > Cheers,
> >
> > Michael
> > On 9/29/07, Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006 at gmx.net> wrote:
> > > Hi,
> > >
> > > On 29.09.2007 05:36, Michael van der Kolff wrote:
> > > > Well, I was just inspecting this beautiful little M61P-S3 board, and
> > > > it has an SPI flash chip on it, in particular, the MX25L4005A.  I
> > > > don't seem to see anything that would indicate that anything but the
> > > > IT8716F would be connecting to it.
> > > >
> > > > I first tried using the version in Debian (testing):  It didn't detect
> > > > any flash chip.
> > > >
> > > > I then tried using the SVN version: It too didn't detect anything.
> > >
> > > Please try current svn with my patch (Subject: [PATCH] improved SPI
> > > flash support (restructured), date: Sat, 29 Sep 2007 04:08:45) on top of
> > > it and use your patched board enable for the GA-M57SLI.
> > >
> > > > Then I looked through, and found a reference to the M55.  I looked the
> > >
> > > GA-M57SLI?
> > >
> > > > archives, and found a message from May07:  I figured I would see if I
> > > > could get lucky telling it to look like an M55.
> > > >
> > > > I first got the connection to the IT8716F working, by telling it that
> > > > the M61 is just like an M55, except with PCI device id 0x03e0.  That
> > > > seemed to work.
> > > >
> > > > However, going from there, it doesn't seem to detect any SPI
> > > > functionality at all.
> > >
> > > Full log please.
> > >
> > > > It looks to me like support for each flash chip is needed (given that
> > > > the spec sheet gives commands to output the manufacturer ID & device
> > > > ID), but maybe that isn't true.  In any case, the command set is
> > > > relatively simple.
> > >
> > > I know. But the command set for each chip differs slightly, so full
> > > support is difficult.
> > >
> > > > Is the SPI stuff properly supported?  I feel like I'm a little out of
> > > > my depth on this code...
> > >
> > > I started last week to write support for SPI. It is in a really early
> > > stage and can only ID the chip (and with current svn, it will still say
> > > that no chip was found even if the ID could be read).
> > >
> > > Please run current svn flashrom in verbose mode (-V) and use your
> > > patched board enable. If possible, repeat this with my patch applied on top.
> > >
> > > Regards,
> > > Carl-Daniel
> > >
> >
>
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: m61p-s3.diff
Type: application/octet-stream
Size: 682 bytes
Desc: not available
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20071006/843cdc26/attachment.obj>

From tsylla at gmail.com  Sat Oct  6 00:27:03 2007
From: tsylla at gmail.com (Tom Sylla)
Date: Fri, 5 Oct 2007 18:27:03 -0400
Subject: [LinuxBIOS] emulator PIT setup
Message-ID: <57947bf80710051527s2e7dcd86nce7d2ad10f10fbb6@mail.gmail.com>

Many moons ago I had a problem with an XGI VGA option ROM in the emulator:

http://www.linuxbios.org/pipermail/linuxbios/2006-December/017568.html

I poked at it again this week, and found that my PIT was not set up on
my platform, so port 61 was not ticking, and the delay routines in the
option ROM were getting stuck.

It looks like the emulator attempts to set up something in the PIT:
http://tracker.linuxbios.org/trac/LinuxBIOS/browser/trunk/LinuxBIOSv2/src/devices/emulator/biosemu.c#L301

but that is timer 0, which is for the timer tick, not the refresh
timer (port 61).

To fix my problem, I just added LX's PIT counter 1 init I/Os:

http://tracker.linuxbios.org/trac/LinuxBIOS/browser/trunk/LinuxBIOSv2/src/cpu/amd/model_lx/syspreinit.c#L32

before the Counter 0 code, and the XGI ROM then loaded ok.

My first question is about the current PIT code in the emulator. What
is it trying to do? Is it supposed to be turning on counter 1, and
just broken? Or is it really meant to be enabling the timer tick?

The next question is where would be a good place for the Counter 1
init? It seems like it should be done generically in LB for any SB
with a PIT.



From uwe at hermann-uwe.de  Sat Oct  6 00:30:06 2007
From: uwe at hermann-uwe.de (Uwe Hermann)
Date: Sat, 6 Oct 2007 00:30:06 +0200
Subject: [LinuxBIOS] [PATCH] superiotool: Make --version actually
	work	correctly
In-Reply-To: <4706B412.7080408@gmx.net>
References: <20071005174628.GA9851@greenwood> <4706B412.7080408@gmx.net>
Message-ID: <20071005223006.GF7148@greenwood>

On Sat, Oct 06, 2007 at 12:00:50AM +0200, Carl-Daniel Hailfinger wrote:
> On 05.10.2007 19:46, Uwe Hermann wrote:
> > As the svn keyword $Rev$ is not replaced with the global repository ID
> > but rather with the ID of the last commit which changed the
> > respective file (where $Rev$ is located), the current --version output
> > is incorrect.
> > 
> > This patch fixes the output by keeping a $Rev$ instance in every file
> > (which can be different for every file) and then calculating the
> > biggest revision (which is our superiotool version) at runtime when
> > superiotool is invoked with --version.
> > 
> > This only takes *.c and *.h files into account, changes to the README
> > and other non-code files will no be reflected in the version number.
> > But this is actually a good thing in this case, we don't want to bump
> > the version number upon README changes anyway.
> > 
> > Signed-off-by: Uwe Hermann <uwe at hermann-uwe.de>
> 
> Nack. Can we switch back to a more sensible versioning scheme (like 0.1

That's not more sensible, IMO. We want a versioning which is
automated (svn rev), so that we don't have to change it manually
upon every commit (we'll surely forget that many times).

And I'm also pretty sure we want a per-commit version-number-update
as superiotool is a moving target and we don't do (tarball) releases.
We want to know exactly which svn revision a user was running for a
specific superiotool dump output.


> etc.) or at least ask some svn experts whether there is an easier and
> cleaner way to include a revision number?

Yeah, that would surely be great. Do you know any method or whom to ask?
I browsed the svn code and manuals but didn't find anything better
than $Rev$.


> BTW, the $Rev$ output format is ugly beyond words.

Full ack.

That's why it has to be mangled quite a bit before usage. However, the
final output looks ok IMO:

$ ./superiotool -v
superiotool r2821


Uwe.
-- 
http://www.hermann-uwe.de  | http://www.holsham-traders.de
http://www.crazy-hacks.org | http://www.unmaintained-free-software.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20071006/b684ecb0/attachment.sig>

From jordan.crouse at amd.com  Sat Oct  6 00:28:07 2007
From: jordan.crouse at amd.com (Jordan Crouse)
Date: Fri, 5 Oct 2007 16:28:07 -0600
Subject: [LinuxBIOS] Initram+XIP
Message-ID: <20071005222807.GF32104@cosmic.amd.com>

(This is a long e-mail.  I apologize, but I feel this is important to
cover).

This week I've been working with LinuxBIOSv3 to try to get over the XIP
initram problem.  For those that tuning in late, here's the recap:

There are some symbols that we use that we want to define once, and 
use in different segments (such as printk). This is very easy to do
for segments that are loaded and run at a particular location in memory,
by passing in the symbol list from stage0 to LD through the -R command
line option, from which LD figures the right relative offsets.

The problem is, this is only easy if you know where your code is 
executing, and pass the appropriate fu into LD.  For most systems,
we need to run at least the initram segment in place on the ROM which
are not always located at a known location - there can be multiple
initram blocks, and LAR can put them anywhere it wishes.  Needless to
say, this breaks things badly when we try to call functions in the bootblock
with a relative offset that walks into the weeds.

So my quest this week was to try to find a list of solutions that we
can consider as a group. The only criteria I had for a solution is that
it needed to maintain the independence of the individual segments (i.e. -
I couldn't just cheat and link the bootblock and initram together).  Any
other legitimate solution was on the table, though obviously, the more
simple and obvious the better. Here's what I came up with:

-----------------------------------------
Solution 1 - fixed locations

the -R trick to LD works for the XIP modules too, assuming that you link it
at the right address where it will execute in the ROM. The very simplest way
to do this would be to define fixed locations for the initram(s) and feed
those in to to LD (through a platform configuration).  This would be 
remotely similar to v2.

PROS: Easy
CONS: Completely breaks the LAR model, wastes ROM space, and really breaks
the whole v3 concept.

Solution 2 - relink the image

Like above, we use -R to pass in the symbols from stage0.

we link the image at an arbitrary address (say, 0x0), and
build it into the LAR.   We can then ask LAR where it put the segment,
and then relink the segment at that address, and replace it in the LAR.
There may be other things we can do with LAR to make this easier - perhaps
just pass in the sizes of the segments to LAR and have it return the offsets
without actually constructing an archive, perhaps?

PROS: Fits in the v3 model 
CONS: Complex, and relies on some scripts to do the right thing with LAR.
Also, its confusing to relink twice.

Solution 3 - postlinker

Again, we use -R to pass in the symbols from stage0 and link the segment
to 0x0.   But instead of re-linking when we learn the address, we run
a special utility that will read the relocation tables in the ELF and
update the addresses in the ELF.  This should be somewhat more lightweight
then re-linking.  The same problems with LAR still exist here -
the key is finding out the address we need to link to.

PROS:  Fits into the v3 model, less complex then relinking
CONS:  Finding the address from LAR will be a challenge.  Plus its another
custom utility to maintain.

Solution 3.5 - postlinker + symbol table

One CON for all of these is that each solution requires us to have the 
stage0.o ELF file laying around.  To me, that sort of defeats the purpose
of independence.  So the 4th option is similar to the 3rd (and suffers from
the same problems), but instead of using -R to pass the symbols to LD
during the link stage, we leave the shared symbols undefined.   Then,
we grab a list of shared symbols from stage0.o (which could easily be 
a "published" list, and feed that into the custom script from above, which
could fill in the undefined shared symbols.

PROS: One could build an initram completely separate from 
stage0 (which is the goal).  
CONS: An extra stage of abstraction to get the symbol table.  It would be
difficult to ensure that the symbol table matches the current bootblock.
Finding the address from the LAR remains a challenge. Custom utility.
-----------------------------------------

I vote for #3 and possibly #4.  I've spent some time writing the very
custom app described above, and I used it with a little manual
trickery to make the Geode boot through the initram stage (I'll send it 
out in a separate e-mail).  Figuring out the right address from LAR
will be the tricky part - for that i really don't have a good idea (I
build the lar with the un-modified initram, listed the lar, figured out the
address, ran my tool, and re-lared the new initram.  I don't recommend
that method - too much possibility for failure).

So, why am I telling you this?  Because I think the time is ripe for a
discussion - we know what needs to be done code wise, and we have a list
of options at our disposal, but the most important thing we need is
consensus.  I don't want this to be some crazy scheme cooked up late at
night and snuck into the code base when nobody is looking.

Thoughts?
Jordan

--
Jordan Crouse
Systems Software Development Engineer 
Advanced Micro Devices, Inc.





From rasmus at wiman.org  Sat Oct  6 00:32:52 2007
From: rasmus at wiman.org (Rasmus Wiman)
Date: Sat, 6 Oct 2007 00:32:52 +0200
Subject: [LinuxBIOS] Tyan Thunder n3600R (S2912) support status?
In-Reply-To: <20071005212707.GB7148@greenwood>
References: <4705EAC4.5030302@ornia.hampshire.edu>
	<2ea3fae10710051104i41d0d010r2462f918c742b501@mail.gmail.com>
	<20071005184730.GB9912@greenwood>
	<2ea3fae10710051328v17fc5fb7v8b3284670778c017@mail.gmail.com>
	<20071005212707.GB7148@greenwood>
Message-ID: <20071006003252.9bc2ea49.rasmus@wiman.org>

Uwe Hermann <uwe at hermann-uwe.de> skrev:

> The spec page says 
> 
> - Winbond W83627HF Super IO
> - Analog Devices ADT7476 Hardware Monitoring IC
> 
> Don't those two provide sensors of various kinds? Did you test any of
> them (via lm-sensors probably)?

Yes, it should. That's the difference between W83627F and HF, the HF
has sensors, the F doesn't, according to the data sheet.

-- 

/Rasmus Wiman
Geek for hire
lp0: on fire



From ward at gnu.org  Sat Oct  6 00:37:30 2007
From: ward at gnu.org (Ward Vandewege)
Date: Fri, 5 Oct 2007 18:37:30 -0400
Subject: [LinuxBIOS] [PATCH] superiotool: Make --version actually work
	correctly
In-Reply-To: <20071005223006.GF7148@greenwood>
References: <20071005174628.GA9851@greenwood> <4706B412.7080408@gmx.net>
	<20071005223006.GF7148@greenwood>
Message-ID: <20071005223730.GA23669@localdomain>

On Sat, Oct 06, 2007 at 12:30:06AM +0200, Uwe Hermann wrote:
> > etc.) or at least ask some svn experts whether there is an easier and
> > cleaner way to include a revision number?
> 
> Yeah, that would surely be great. Do you know any method or whom to ask?
> I browsed the svn code and manuals but didn't find anything better
> than $Rev$.

Can't we do this with a commit hook that would update the version number
(which is in 1 place only) automatically to the SVN revision number?

Thanks,
Ward.

-- 
Ward Vandewege <ward at fsf.org>
Free Software Foundation - Senior System Administrator



From ward at gnu.org  Sat Oct  6 00:40:06 2007
From: ward at gnu.org (Ward Vandewege)
Date: Fri, 5 Oct 2007 18:40:06 -0400
Subject: [LinuxBIOS] Tyan Thunder n3600R (S2912) support status?
In-Reply-To: <20071006003252.9bc2ea49.rasmus@wiman.org>
References: <4705EAC4.5030302@ornia.hampshire.edu>
	<2ea3fae10710051104i41d0d010r2462f918c742b501@mail.gmail.com>
	<20071005184730.GB9912@greenwood>
	<2ea3fae10710051328v17fc5fb7v8b3284670778c017@mail.gmail.com>
	<20071005212707.GB7148@greenwood>
	<20071006003252.9bc2ea49.rasmus@wiman.org>
Message-ID: <20071005224006.GB23669@localdomain>

On Sat, Oct 06, 2007 at 12:32:52AM +0200, Rasmus Wiman wrote:
> Uwe Hermann <uwe at hermann-uwe.de> skrev:
> 
> > The spec page says 
> > 
> > - Winbond W83627HF Super IO
> > - Analog Devices ADT7476 Hardware Monitoring IC
> > 
> > Don't those two provide sensors of various kinds? Did you test any of
> > them (via lm-sensors probably)?
> 
> Yes, it should. That's the difference between W83627F and HF, the HF
> has sensors, the F doesn't, according to the data sheet.

If it's anything like the other Tyan boards I've played with, some of the
sensors/fans will be hooked up to the SuperIO, and the bulk will be hooked up
to the ADT7476.

I think I added some code to the s2881 tree that sanitizes fan speed control
(as in, puts it under automatic hardware control). IIRC, the other Tyan
boards don't have that yet.

Thanks,
Ward.

-- 
Ward Vandewege <ward at fsf.org>
Free Software Foundation - Senior System Administrator



From jordan.crouse at amd.com  Sat Oct  6 00:42:48 2007
From: jordan.crouse at amd.com (Jordan Crouse)
Date: Fri, 5 Oct 2007 16:42:48 -0600
Subject: [LinuxBIOS] lbrelocs - LinuxBIOSv3 re-linking tool
Message-ID: <20071005224248.GG32104@cosmic.amd.com>

Okay - based on my previous e-mail, attached is the custom tool that I
wrote to change the relative addresses of the initram binary so that it
can be placed at an arbitrary place in the ROM and still work.

To start with, we ask LD to emit the relocation info for the segment into
the ELF.  The relocation tables list everywhere in the binary where a 
symbol reference is made.  Using that information, we can easily walk
the table and adjust each all the relative offsets so that they will
work from a base address specified on the command line.

This tool just changes the code - a more complete solution would probably
rewrite the entire ELF file so the offset was correct - I think thats
as easy as re-writing the sh_addr for the sections, but I don't know for
sure.  I had to take a crash course in how relocs worked (thanks a million
to  Eric Biderman for arch/i386/boot/compressed/relocs.c in the Linux kernel
- it taught me much, and I borrowed some of the functions for this utility
too).

So, I put this out there as food for thought, and end with some instructions
on how to see it in action (I used the amd/norwich/ mainboard):

Modify the $(LD) command in mainboards/amd/norwich/Makefile to this:

$(Q)$(LD) -R$(obj)/stage0.o --emit-relocs -Ttext 0x0 $(INITRAM_OBJ)
--entry=main -o $(obj)/linuxbios.initram.o

This moves the text to 0x0 (makes the math easier for me to verify), and
emit the relocation tables.

Build the LinuxBIOS image.

Compile the tool, and run it:
lbrelocs -b <base address> linuxbios.initram.o

This command will adjust all the references in the code to the base address.
It will overwrite linuxbios.initram.o, so I recommend saving it off first
if you are going to play around.  Because we're not changing the actual
offsets of the sections, the disassembly will get confused, but you can
still do the math yourself to verify that the calls are correct.

If you are brave and have a geode, you can figure out the right address
to adjust the segment too, copy it to a binary, and rebuild it into a LAR
and see it boot.  

I'm rambling, so I'm going to leave you here.  Comments especially welcome,
if I can do something smarter or better, I'm very interested to hear about
it.  

Jordan

-- 
Jordan Crouse
Systems Software Development Engineer 
Advanced Micro Devices, Inc.
-------------- next part --------------
/* LinuxBIOS post-link fixup script for segments  
 * Copyright (C) 2007, Advanced Micro Devices, Inc.
 *
 * Techniques for reading the ELF file was borrowed from
 * arch/i386/boot/compressed/relocs.c
 * Mainly by Eric Biderman, but also others too.

 This program is free software; you can redistribute it and/or modify
 it under the terms of the GNU General Public License as published by
 the Free Software Foundation; either version 2 of the License, or
 (at your option) any later version.
 
 This program is distributed in the hope that it will be useful,
 but WITHOUT ANY WARRANTY; without even the implied warranty of
 MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
 GNU General Public License for more details.
 
 You should have received a copy of the GNU General Public License
 along with this program; if not, write to the Free Software
 Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA  02111-1307  USA
*/

/* What is happening here? 
 *
 * LinuxBIOSv3 functionality is divided into a series of independent segments,
 * each of which serves a different purpose and are linked independently of
 * each other.  LinuxBIOS also has a number of common symbols that are to 
 * be shared by each segment (such as printk).  The code for these will live
 * in the bootblock (at a known location), but need to be resolved for each
 * block.  This is easily done with the -R command line option for GNU ld.
 *
 * This is not a problem for segments that are compiled to run in memory,
 * since they will be loaded to whatever memory address they were linked for,
 * and all the relative function calls just work.
 *
 * This *is* a problem for segments that need to be executed in place from
 * the ROM (for the segments that run before memory is initialized).  These
 * ROMs are not located at a set location, they may be located anywhere on
 * the ROM (at the option of the LAR tool). 
 *
 * This utility takes an XIP module and adjusts it to run at a specified
 * location.  Thus the final location of the code need not be known at link
 * time.
 *
 * How does this work?  
 *
 * When the ELF is linked, we ask it to emit a series of tables known as
 * relocation tables, which point at all the locations in the the code
 * where we refer to symbols (like calls to functions).  Based on these
 * relocation tables, we can adjust each relative symbol reference to 
 * match the new execution address.
 */

#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <unistd.h>
#include <sys/stat.h>
#include <fcntl.h>
#include <stdarg.h>
#include <sys/mman.h>
#include <elf.h>
#include <ctype.h>

/* We shouldn't see ELF headers with more then 64 sections -
the most I've seen to date is 12 */

#define MAXSHDRS 64
#define ARRAY_SIZE(x) (sizeof(x) / sizeof((x)[0]))

/* We use this structure to carry around the information for a given
   ELF file, including the mmap variables.  This is a little overkill
   when we read a single ELF file, but it gives us the flexiblity
   to read multiple ELF files if we need to 
*/

struct elffile {
	int fd;
	unsigned char *ptr;
	int size;

	Elf32_Ehdr *header;
	Elf32_Shdr *sects[MAXSHDRS];
	Elf32_Rel  *relocs[MAXSHDRS];
	Elf32_Sym  *symtab[MAXSHDRS];
	char *strtab[MAXSHDRS];
};

/* A verbose flag to increase the blather from printfs() */
static int verbose;

/* Borrowed from relocs.c - I liked the idea - print an error message
 and exit with an error.
*/

static void die(char *fmt, ...)
{
	va_list ap;
	va_start(ap, fmt);
	vfprintf(stderr, fmt, ap);
	va_end(ap);
	exit(1);
}

/* Borrowed from relocs.c - return name of a section */

static const char *secname(struct elffile *file, unsigned int index)
{
	const char *stab;
	const char *name = "<noname>";

	/* Get the string table for the section headers */
	stab = file->strtab[file->header->e_shstrndx];

	/* If the index matches a real section in the ELF file,
	   then use sh_name to index into the string table above.
	   table.  Otherwise, its a standard section type, and we
	   a standard name
	*/

	if (index < file->header->e_shnum)
		name = stab + file->sects[index]->sh_name;
	else if (index == SHN_ABS)
		name = "ABSOLUTE";
	else if (index == SHN_COMMON)
		name = "COMMON";
	return name;
}
		
/* Borrowed from relocs.c - return name of a symbol */
       
static const char *getname(struct elffile *file, const char *strtab,
			   Elf32_Sym *sym)
{
	const char *name = "<noname>";

	/* If st_name is non zero, then it is an index into the string table
	   passed into the function.  If st_name is not set, then we need to
	   look up the section name instead 
	*/

	if (sym->st_name)
		name = strtab + sym->st_name;
	else
		name = secname(file, file->sects[sym->st_shndx]->sh_name);

	return name;
}

/* Parse the ELF header */

static void getheader(struct elffile *file) 
{	
	file->header = (Elf32_Ehdr *) file->ptr;
	
	if (memcmp(file->header->e_ident, ELFMAG, 4)) 
		die("File is not an ELF\n");

	if (file->header->e_ident[EI_CLASS] != ELFCLASS32)
		die("Not a 32 bit executable\n"); 
	       		
	if (file->header->e_ident[EI_DATA] != ELFDATA2LSB)
		die("Not a LSB ELF executable\n"); 
	
	if (file->header->e_ident[EI_VERSION] != EV_CURRENT)
		die("Unknown ELF version\n"); 

	/* We assume that we are on a LSB system for simplicity now,
	   but this is a stupid assumption and should be fixed 
	*/
}

/* Get the list of sections, and the individual tables from the ELF */

static void getsections(struct elffile *file)
{
	int i;
	int count = file->header->e_shnum;	
	int offset = file->header->e_shoff;

	if (count > MAXSHDRS) 
		die("Too many headers\n");
	
	/* We assume that we are on a LSB system for simplicity now,
	   but this is a stupid assumption and should be fixed 
	*/

	for(i = 0; i < count; i++) {
		file->sects[i] = (Elf32_Shdr *) (file->ptr + offset);
		offset += sizeof(Elf32_Shdr);

		/* We need to individually index the string tables,
		   the symbol tables, and the star of the show, the
		   relocation tables - so when we encounter
		   those, we set up the array pointers accordingly.
		   The mmap()ed file makes this very easy.
		*/

		switch(file->sects[i]->sh_type) {
		case SHT_STRTAB:
			file->strtab[i] = (char *)
				(file->ptr + file->sects[i]->sh_offset);
			break;

		case SHT_SYMTAB:
			file->symtab[i] = (Elf32_Sym *)
				(file->ptr + file->sects[i]->sh_offset);
			break;

		case SHT_REL:
			file->relocs[i] = (Elf32_Rel *)
				(file->ptr + file->sects[i]->sh_offset);
			break;
		}
	}
}
		
/* These are the most important function - this is where we walk
   the reloc tables, and fixup the symbol references.  By the
   time this function ends, the incoming binary should be completely
   ready to go
*/

static void fixupsection(struct elffile *file, int base, int index) 
{	
	int i;
	
	int section = file->sects[index]->sh_link;		
	Elf32_Sym *table = file->symtab[section];

	/* Get the base address of the symbol table */

	unsigned int symbase = file->sects[file->sects[index]->sh_info]->sh_addr;

	/* Get the file offset of the section */
	unsigned int foffset = file->sects[file->sects[index]->sh_info]->sh_offset;

	Elf32_Rel *rel = file->relocs[index];

	/* Walk the relocation table */
	
	for(i = 0; i < file->sects[index]->sh_size / sizeof(*rel); i++) {
		
		/* This is the relative offset of the reloc */
		unsigned int roffset = rel[i].r_offset - symbase;
		
		/* This is the actual location in the file where the reference is */
		unsigned int *fpos = (unsigned int *) (file->ptr + foffset + roffset);
		
		if (ELF32_R_TYPE(rel[i].r_info) == R_386_32) {
			/* For absolute values, we just update the value in place */
			*fpos = (*fpos - symbase) + base;
		}
		else if (ELF32_R_TYPE(rel[i].r_info) == R_386_PC32) {

			unsigned int offset;

			/* Get the actual symbol this entry indexes to */
			Elf32_Sym *sym = &table[ELF32_R_SYM(rel[i].r_info)];

			/* we only worry about the absolute values ("external functions") 
			   everything else should have the right offsets already */

			if (sym->st_shndx != SHN_ABS)
				continue;
					       			
			/* calculate the new relative offset of the symbol */
			offset = sym->st_value - (base + roffset);

			/* Update the value in the file */
			*fpos = 0xfffffffc + offset;
		}
	}
}

static void fixuprelocs(struct elffile *file, int base)
{
	int index;
	
	/* Go through the entire list of sections */

	for(index = 0; index < file->header->e_shnum; index++) {

		/* We only care about the relocation tables */

		if (file->sects[index]->sh_type != SHT_REL)
			continue;
		
		fixupsection(file, base, index);
	}
}

/* Borrowed from reloc.c - pretty print the relocation type */

static const char *reltype(unsigned type)
{
        static const char *type_name[] = {
#define REL_TYPE(X) [X] = #X
                REL_TYPE(R_386_NONE),
                REL_TYPE(R_386_32),
                REL_TYPE(R_386_PC32),
                REL_TYPE(R_386_GOT32),
                REL_TYPE(R_386_PLT32),
                REL_TYPE(R_386_COPY),
                REL_TYPE(R_386_GLOB_DAT),
                REL_TYPE(R_386_JMP_SLOT),
                REL_TYPE(R_386_RELATIVE),
                REL_TYPE(R_386_GOTOFF),
                REL_TYPE(R_386_GOTPC),
#undef REL_TYPE
	};
        const char *name = "UNKNOWN";

        if (type < ARRAY_SIZE(type_name)) {
                name = type_name[type];
        }
        return name;
}

/* This function shows the list of relocations - not useful in normal usage, but its good
   for debugging issues
*/

static void showrelocs(struct elffile *file) {

	int i, j;

	for(i = 0; i < file->header->e_shnum; i++) {
		
		char *sh_strtab;
		Elf32_Sym *sh_symtab;
		unsigned int sec_symtab;
		
		/* We only care about the relocation tables */

		if (file->sects[i]->sh_type != SHT_REL)
			continue;

		/* Get the symbol table index */

		sec_symtab = file->sects[i]->sh_link;

		if (!(file->sects[file->sects[i]->sh_info]->sh_flags & SHF_ALLOC))
			continue;

		/* Get the symbol table and string table */

		sh_symtab = file->symtab[sec_symtab];
		sh_strtab = file->strtab[file->sects[sec_symtab]->sh_link];

		for(j = 0; j < file->sects[i]->sh_size / sizeof(file->relocs[0][0]); j++) {

			Elf32_Rel *rel;
			Elf32_Sym *sym;
			const char *name;

			rel = &file->relocs[i][j];
			sym = &sh_symtab[ELF32_R_SYM(rel->r_info)];
			
			/* Get the name of the symbol */

			name = getname(file, sh_strtab, sym);

			/* Show it */

			printf("%d: %08x %08x %10s %08x %s\n",
			       sym->st_shndx,
			       rel->r_offset,
			       rel->r_info,
			       reltype(ELF32_R_TYPE(rel->r_info)),
			       sym->st_value,
			       name);
		}
	}	
}
	
/* This function opens an elf file, mmaps it, and parses the structures */

static int openelf(const char *filename, struct elffile *file)
{
	struct stat s;

	/* Open the file */

	file->fd = open(filename, O_RDWR);

	/* Get the size */

	if (fstat(file->fd, &s)) {
		fprintf(stderr, "Couldn't stat %s: %m\n", filename);
		close(file->fd);
		return -1;
	}
	
	file->size = s.st_size;

	/* Map the file */

	file->ptr = mmap(0, s.st_size, PROT_READ | PROT_WRITE, MAP_SHARED, file->fd, 0);

	if (file->ptr == MAP_FAILED) {
		fprintf(stderr, "Unable to map the file: %m\n");
		close(file->fd);
		return -1;
	}

	/* Parse the ELF bits */
	getheader(file);
	getsections(file);

	return 0;
}

/* This function closes the ELF file (writing back any changes) */

static void closeelf(struct elffile *file)
{
	if (file->fd > 0) {
		munmap(file->ptr, file->size);
		close(file->fd);
	}

	file->fd = 0;
}

struct elffile relocs;
			
int main(int argc, char **argv) 
{
	int frelocs = 0;
	unsigned int base = 0;

	/* Options:
	   -S - specify the symbols table to use when fixing up the relocations 
	   -v - be verbose
	   -r - Show the relocation tables in the image - for debugging
	   -b - Specify the base address for the initram (as a hex value)
	*/

	while(1) {
		signed char ch = getopt(argc, argv, "S:vrlb:");
		if (ch == -1) 
			break;

		switch(ch) {
		case 'b':
			base = strtoul(optarg, 0, 0);
		case 'v':
			verbose = 1;
			break;

		case 'r':
			frelocs=1;
			break;
		}
	} 

	
	if (optind >= argc) {
		printf("Error - you must specify an object file to fixup\n");
		return -1;
	}
	
	if (openelf(argv[optind], &relocs))
		return -1;

	else if (frelocs)
		showrelocs(&relocs);
	else {
		if (verbose)
			printf("Fixing up the object file %s (using base %x)\n", argv[optind], base);

		fixuprelocs(&relocs, base);
	}

	closeelf(&relocs);

	return 0;
}

From info at coresystems.de  Sat Oct  6 00:46:03 2007
From: info at coresystems.de (LinuxBIOS information)
Date: Sat, 06 Oct 2007 00:46:03 +0200
Subject: [LinuxBIOS] r2828 build service
Message-ID: <E1Idvvn-0004td-TQ@khepri.openbios.org>

Dear LinuxBIOS readers!

This is the automated build check service of LinuxBIOS.

The developer "uwe" checked in revision 2828 to
the LinuxBIOS source repository and caused the following 
changes:

Change Log:
Add dump support for the Winbond W83627HF/F/HG/G.

Signed-off-by: Rasmus Wiman <rasmus at wiman.org>
Acked-by: Uwe Hermann <uwe at hermann-uwe.de>



Build Log:
Compilation of arima:hdama is still broken
See the error log at http://qa.linuxbios.org/log_buildbrd.php?revision=2828&device=hdama&vendor=arima
Compilation of ibm:e325 is still broken
See the error log at http://qa.linuxbios.org/log_buildbrd.php?revision=2828&device=e325&vendor=ibm
Compilation of ibm:e326 is still broken
See the error log at http://qa.linuxbios.org/log_buildbrd.php?revision=2828&device=e326&vendor=ibm
Compilation of iei:juki-511p is still broken
See the error log at http://qa.linuxbios.org/log_buildbrd.php?revision=2828&device=juki-511p&vendor=iei
Compilation of iwill:dk8s2 is still broken
See the error log at http://qa.linuxbios.org/log_buildbrd.php?revision=2828&device=dk8s2&vendor=iwill
Compilation of iwill:dk8x is still broken
See the error log at http://qa.linuxbios.org/log_buildbrd.php?revision=2828&device=dk8x&vendor=iwill
Compilation of newisys:khepri is still broken
See the error log at http://qa.linuxbios.org/log_buildbrd.php?revision=2828&device=khepri&vendor=newisys


If something broke during this checkin please be a pain 
in uwe's neck until the issue is fixed.

If this issue is not fixed within 24h the revision should 
be backed out.

   Best regards,
     LinuxBIOS automatic build system





From jordan.crouse at amd.com  Sat Oct  6 00:56:47 2007
From: jordan.crouse at amd.com (Jordan Crouse)
Date: Fri, 5 Oct 2007 16:56:47 -0600
Subject: [LinuxBIOS] lbrelocs - LinuxBIOSv3 re-linking tool
In-Reply-To: <20071005224248.GG32104@cosmic.amd.com>
References: <20071005224248.GG32104@cosmic.amd.com>
Message-ID: <20071005225647.GH32104@cosmic.amd.com>

On 05/10/07 16:42 -0600, Jordan Crouse wrote:
> Okay - based on my previous e-mail, attached is the custom tool that I
> wrote to change the relative addresses of the initram binary so that it
> can be placed at an arbitrary place in the ROM and still work.
> 
> To start with, we ask LD to emit the relocation info for the segment into
> the ELF.  The relocation tables list everywhere in the binary where a 
> symbol reference is made.  Using that information, we can easily walk
> the table and adjust each all the relative offsets so that they will
> work from a base address specified on the command line.
> 
> This tool just changes the code - a more complete solution would probably
> rewrite the entire ELF file so the offset was correct - I think thats
> as easy as re-writing the sh_addr for the sections, but I don't know for
> sure.  I had to take a crash course in how relocs worked (thanks a million
> to  Eric Biderman for arch/i386/boot/compressed/relocs.c in the Linux kernel
> - it taught me much, and I borrowed some of the functions for this utility
> too).

<SNIP>

> I'm rambling, so I'm going to leave you here.  Comments especially welcome,
> if I can do something smarter or better, I'm very interested to hear about
> it.  

It occurs to me after all this that objcopy can do the same thing, and
probably better.  So we might be able to get away with no custom
applications, unless we want to do the symbol table thing that we discussed
before, and then this script would be useful for that (and I have a version
of it that reads a custom symbol table).  So much of this was probably for
naught, but i learned a ton.

Jordan

-- 
Jordan Crouse
Systems Software Development Engineer 
Advanced Micro Devices, Inc.





From rminnich at gmail.com  Sat Oct  6 02:27:47 2007
From: rminnich at gmail.com (ron minnich)
Date: Fri, 5 Oct 2007 17:27:47 -0700
Subject: [LinuxBIOS] lbrelocs - LinuxBIOSv3 re-linking tool
In-Reply-To: <20071005225647.GH32104@cosmic.amd.com>
References: <20071005224248.GG32104@cosmic.amd.com>
	<20071005225647.GH32104@cosmic.amd.com>
Message-ID: <13426df10710051727l28ec570v50b19d33556853ec@mail.gmail.com>

if you want true independence, why not make the stage0 symbol table a
lar file? You could compress it. Then, later, you can make a new
initram and will be able to link it with the stage0 that you are not
going to change.

I like 3+4 too, and what you are doing looks like we're moving the
right direction.

ron



From peter at stuge.se  Sat Oct  6 07:27:34 2007
From: peter at stuge.se (Peter Stuge)
Date: Sat, 6 Oct 2007 07:27:34 +0200
Subject: [LinuxBIOS] flashrom support for AMD Geode CS5536
In-Reply-To: <20071005174106.GE32104@cosmic.amd.com>
References: <47026FBB.1080809@mit.edu>
	<13426df10710020938x276d2c3ewf797f82d035d1bd7@mail.gmail.com>
	<47028730.70305@mit.edu> <47028804.4020502@mit.edu>
	<4706634F.9010609@amd.com> <20071005173559.GD32104@cosmic.amd.com>
	<20071005174106.GE32104@cosmic.amd.com>
Message-ID: <20071006052734.11231.qmail@stuge.se>

On Fri, Oct 05, 2007 at 11:41:06AM -0600, Jordan Crouse wrote:
> Sigh - I hit 'r' instead of 'g'.  I blame mutt... :)

Add

subscribe linuxbios at linuxbios.org

to .muttrc, then you can use list-reply (L in the default config
IIRC) to always send back to the list, and only the list.

It's very nice.


//Peter



From stepan at coresystems.de  Sat Oct  6 07:52:38 2007
From: stepan at coresystems.de (Stefan Reinauer)
Date: Sat, 6 Oct 2007 07:52:38 +0200
Subject: [LinuxBIOS] Initram+XIP
In-Reply-To: <20071005222807.GF32104@cosmic.amd.com>
References: <20071005222807.GF32104@cosmic.amd.com>
Message-ID: <20071006055238.GA9752@coresystems.de>

* Jordan Crouse <jordan.crouse at amd.com> [071006 00:28]:
> This week I've been working with LinuxBIOSv3 to try to get over the XIP
> initram problem.  For those that tuning in late, here's the recap:
> 
> There are some symbols that we use that we want to define once, and 
> use in different segments (such as printk). This is very easy to do
> for segments that are loaded and run at a particular location in memory,
> by passing in the symbol list from stage0 to LD through the -R command
> line option, from which LD figures the right relative offsets.
> 
> The problem is, this is only easy if you know where your code is 
> executing, and pass the appropriate fu into LD.  For most systems,
> we need to run at least the initram segment in place on the ROM which
> are not always located at a known location - there can be multiple
> initram blocks, and LAR can put them anywhere it wishes.  Needless to
> say, this breaks things badly when we try to call functions in the bootblock
> with a relative offset that walks into the weeds.

I tried playing with the same thing and I came up with the following
hack (attachment) .. The big issue is it doesnt work like that yet. The
idea is to take the decision of the jump address from the
compiler+linker because we already know it.

Can something like this work a all?



-- 
coresystems GmbH ? Brahmsstr. 16 ? D-79104 Freiburg i. Br.
      Tel.: +49 761 7668825 ? Fax: +49 761 7664613
Email: info at coresystems.de  ? http://www.coresystems.de/
Registergericht: Amtsgericht Freiburg ? HRB 7656
Gesch?ftsf?hrer: Stefan Reinauer ? Ust-IdNr.: DE245674866
-------------- next part --------------
A non-text attachment was scrubbed...
Name: reloc.diff
Type: text/x-patch
Size: 2510 bytes
Desc: not available
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20071006/f86067ba/attachment.diff>

From juergen127 at kreuzholzen.de  Sat Oct  6 12:21:08 2007
From: juergen127 at kreuzholzen.de (Juergen Beisert)
Date: Sat, 6 Oct 2007 12:21:08 +0200
Subject: [LinuxBIOS] VGA support for Geode GX1/CS5530
In-Reply-To: <20071005215000.GC7148@greenwood>
References: <200710052129.54369.juergen127@kreuzholzen.de>
	<200710052243.37625.juergen127@kreuzholzen.de>
	<20071005215000.GC7148@greenwood>
Message-ID: <200710061221.09248.juergen127@kreuzholzen.de>

Hi Uwe,

On Friday 05 October 2007 23:50, Uwe Hermann wrote:
> On Fri, Oct 05, 2007 at 10:43:37PM +0200, Juergen Beisert wrote:
> > This patch will add support for the Geode GX1/CS5530 VGA feature. Its
> > able to set up one of five screen resolutions (sorry no autodetection at
> > runtime, resolution is selected at buildtime) and displays a graphic in
> > the right bottom corner (splash screen).
>
> Nice! So this is in-LinuxBIOS VGA support? I.e. without running any VGA
> option ROM blob in an emulator?

This "driver" really knows the hardware, so it does not need any help from any 
kind of SMM.

> I'll give it a try on my CS5530 box in a few days (no access right now).

Visit my BCOM WINNET100 Tutorial, scroll to the buttom of this document and 
download the Board Support Package. Extract it, you will need some patches to 
use the VGA console feature within Linux. Also for the Linux kernel you will 
need a specific console driver for the GX1, as the generic driver expects 
some help from the SMM. See patches/linux-2.6.22/generic for the whole patch 
stack, apply it to a fresh 2.6.22 kernel and build it with the 
igel316-kernelconfig.target as its .config. Also if you like to run X on it, 
you will need a special driver. You can find it in the BSP in the  
local_src/xf86-video-geode_gx1 directory.

> > +#if CONFIG_GX1_VIDEO == 1
> > +/*
> > + * Some register descriptions that are no listed in cpu/amd/gx1def.h
> > + */
>
> Would it make sense to add them to cpu/amd/gx1def.h?
> Probably not as they're not CPU related but VGA related?

To be discussed. As this CPU and the chipset is one silicon (Note: only VGA 
interface support is in the companion chip, but the graphic feature is part 
of the Geode device!) you can put both defines together.

> > +/*
> > + * what colour depth should be used as default (in bpp)
> > + * Note: Currently no other value than 16 is supported
> > + */
> > +#define COLOUR_DEPTH 16
>
> Maybe this should be a user-visible config-option in Confib.lb too?

Makes no sense yet, as my routines do not support the 8 bit CLUT mode. And the 
Geode hardware only supports 16 and 8 bit mode. Nothing else.

> > +/*
> > + * Support for a few basic video modes
> > + * Note: all modes only for CRT. The flatpanel feature is
> > + * not supported here (due to the lack of hardware to test)
> > + */
> > +struct video_mode {
> > +	int pixel_clock;		/*<< pixel clock in Hz */
>
> What is the '/*<<' supposed to mean?

Doxygen style. I like it, but I was not sure if it will be accepted in LBv2. 
But it seems I forgot it to remove...

> > +/* ModeLine "640x480" 31.5 640 664 704 832 480 489 491 520 -hsync -vsync
> > */ +static const struct video_mode mode_640x480 = {
> > +	/*
> > +	 * 640x480 @ 72Hz hsync: 37.9kHz
> > +	 * VESA standard mode for classic 4:3 monitors
> > +	 */
> > +	.pixel_clock = 31500000,
> > +	.pll_value = 0x33915801,
> > +
> > +	.visible_pixel = 640,
> > +	.hsync_start = 664,
> > +	.hsync_end = 704,	/* 1.27 us sync length */
> > +	.line_length = 832,	/* 26.39us */
> > +
> > +	.visible_lines = 480,
> > +	.vsync_start = 489,
> > +	.vsync_end = 491,
> > +	.picture_length = 520, /* 13.89ms */
> > +
> > +	.sync_pol = HSYNC_LOW_POL | VSYNC_LOW_POL
>
> Add a trailing comma here please, it's convenient if stuff is added
> later (you can easily forget about the comma).

IMHO: I hate this leading comma. But all right, I will add it for you.

> > +/*
> > + * Setup the pixel PLL in the companion chip
> > + * base: register's base address
> > + * pll_val: pll register value to be set
> > + */
>
> Please use Doxygen-style comments (not the same as the kerneldoc
> format). In this case:

I'm up for it!

> /**
>  * Setup the pixel PLL in the companion chip.
>  *
>  * @param base Register's base address.
>  * @param pll_val PLL register value to be set.
>  */
>
> > +static void cs5530_set_clock_frequency(void *io_base,unsigned long
> > pll_val)
>
>                                                         ^
>                                            missing space

Ohhh, the spaces, always the spaces...

> > +{
> > +	unsigned long reg;
>
> u64? u32? Not sure.
>
> Please use the types with explicit width and signedness wherever it
> possible and whereever it makes sense (registers etc).

Hmm, all right. 

> > +/*
> > + * Activate the current mode to be "visible" outside
> > + * gx_base: GX register area
> > + * mode: Data about the video mode to setup
> > + */
> > +static void cs5530_activate_video(void *io_base, const struct video_mode
> > *mode) +{
> > +	u32 val;
> > +
> > +	val = mode->sync_pol;
> > +	val <<= 8;
>
> Why not this?
>
>   val = mode->sync_pol << 8;
>
> Or maybe even
>
>   u32 val = mode->sync_pol << 8;

Hmmm, mode->sync_pol is an signed int. So shift operations are a bad idea?

> > +	writel(val | 0x0020002F, io_base + CS5530_DISPLAY_CONFIG);
> > +}
> > +
> > +/*
> > + * This bitmap file must provide:
> > + * int width: pixel count in one line
> > + * int height: line count
> > + * int colours: ount of used colour
> > + * unsigned long colour_map[]: RGB 565 colours to be used
> > + * unsigned char bitmap[]: index per pixel into colour_map[],
> > width*height pixels + */
> > +#include "bitmap.c"
>
> Should be a bit more configurable later (specify filename in Config.lb
> or so). In v3 this should probably be handled in Kconfig.

Yeees. This bitmap is a gimmick only. I was sure everyone would reject it on 
this list.

> > +/*
> > + * show a boot splash screen in the right lower corner of the screen
> > + * swidth: screen width in pixel
> > + * sheight: screen height in lines
> > + * pitch: line pitch in bytes
> > + * base: screen base address
> > + *
> > + * This routine assumes we are using a 16 bit colour depth!
> > + */
> > +static void show_boot_splash_16(u32 swidth,u32 sheight,u32 pitch,void
> > *base) +{
> > +	int word_count,i;
> > +	unsigned short *adr;
> > +	u32 xstart,ystart,x,y;
> > +	/*
> > +	 * fill the screen with the colour of the
> > +	 * left top pixel in the graphic
> > +	 */
> > +	word_count = pitch*sheight;
>
> A few whitespace issues here and in some other places in the code, please
> fix that to comply with the coding guidelines.

Ack.

> > Index: LinuxBIOSv2/src/southbridge/amd/cs5530/bitmap.c
> > ===================================================================
> > --- /dev/null
> > +++ LinuxBIOSv2/src/southbridge/amd/cs5530/bitmap.c
> > @@ -0,0 +1,304 @@
> > +/* do not edit
> > +This is an image of size 51 x 60 with 234 colours */
>
> How was this image generated? What's the source format?
>
> Please also attach a license to it if you created it. If you didn't we
> must get permission from the author, I guess (and/or state the license
> which applies to it).

Gimmick only. This graphic file is autogenerated with a small program that 
converts xpm into C code. This one shows one of the icons from the linuxbios 
website (one of the chips with the penguin in it). So I have no clue what 
kind of license this file should have.
The small converter tool is part of my BSP. Refer in local_src/xpm_converter 
for the source.

> I can fix up a few of the cosmetic issues in the repository right away
> if you want, or I'll wait for another patch. Please let me know...

I will resend the patch.

Juergen



From bishop.robinson at gmail.com  Sat Oct  6 15:41:44 2007
From: bishop.robinson at gmail.com (Robinson Tryon)
Date: Sat, 6 Oct 2007 09:41:44 -0400
Subject: [LinuxBIOS] [PATCH] superiotool: Make --version actually work
	correctly
In-Reply-To: <20071005223730.GA23669@localdomain>
References: <20071005174628.GA9851@greenwood> <4706B412.7080408@gmx.net>
	<20071005223006.GF7148@greenwood> <20071005223730.GA23669@localdomain>
Message-ID: <a698c16a0710060641t3d70604fj6f3268ed600f07ef@mail.gmail.com>

On 10/5/07, Ward Vandewege <ward at gnu.org> wrote:
> On Sat, Oct 06, 2007 at 12:30:06AM +0200, Uwe Hermann wrote:
> > > etc.) or at least ask some svn experts whether there is an easier and
> > > cleaner way to include a revision number?
> >
> > Yeah, that would surely be great. Do you know any method or whom to ask?
> > I browsed the svn code and manuals but didn't find anything better
> > than $Rev$.
>
> Can't we do this with a commit hook that would update the version number
> (which is in 1 place only) automatically to the SVN revision number?

I was going to suggest that the buildscript pull the current revision
# out of SVN, but the idea of a commit hook sounds like it could be
cleaner.  Would the hook apply whenever any file is committed to the
repository, or just to files in the superiotool directory?



From okajima at digitalinfra.co.jp  Sat Oct  6 15:44:59 2007
From: okajima at digitalinfra.co.jp (Jun OKAJIMA)
Date: Sat, 06 Oct 2007 22:44:59 +0900
Subject: [LinuxBIOS] MACH BOOT
Message-ID: <200710061344.AA02657@bbb-jz5c7z9hn9y.digitalinfra.co.jp>


Maybe you already know this?

MACH BOOT is a very fast CD booting Linux.
It boots Linux desktop in less than 10 sec from CD.

Check it out please.
http://www.machboot.com/

Then, why I mail here?

The current issue for making boot faster is, not a Linux issue
but BIOS issue. Linux can boot less than 10 sec, but BIOS
uses more than 20 sec!.

ANY HELP?. Of course, using Linux BIOS is one choice.


           --- Okajima, Jun. Tokyo, Japan.


http://www.machboot.com/
http://www.digitalinfra.co.jp/
http://distrowatch.com/weekly.php?issue=20070917





From acassis at gmail.com  Sat Oct  6 16:31:47 2007
From: acassis at gmail.com (Alan Carvalho de Assis)
Date: Sat, 6 Oct 2007 11:31:47 -0300
Subject: [LinuxBIOS] MACH BOOT
In-Reply-To: <200710061344.AA02657@bbb-jz5c7z9hn9y.digitalinfra.co.jp>
References: <200710061344.AA02657@bbb-jz5c7z9hn9y.digitalinfra.co.jp>
Message-ID: <37367b3a0710060731r2e284b46m794e5ac3d7bc0ef0@mail.gmail.com>

Hi Jun,

2007/10/6, Jun OKAJIMA <okajima at digitalinfra.co.jp>:
>
> Maybe you already know this?
>
> MACH BOOT is a very fast CD booting Linux.
> It boots Linux desktop in less than 10 sec from CD.
>
> Check it out please.
> http://www.machboot.com/
>
It is fantastic, very good results.

> Then, why I mail here?
>
> The current issue for making boot faster is, not a Linux issue
> but BIOS issue. Linux can boot less than 10 sec, but BIOS
> uses more than 20 sec!.
>
> ANY HELP?. Of course, using Linux BIOS is one choice.
>

I think using LinuxBIOS is the best choice. Using LinuxBIOS and Linux
with graphical aplications (kdrive and matchbox) built in inside BIOS
Flash I got < 10s startup (with no optimizations). You just need get a
supported board
(http://www.linuxbios.org/index.php/Supported_Motherboards) and make a
try.

>
>            --- Okajima, Jun. Tokyo, Japan.
>
>
> http://www.machboot.com/
> http://www.digitalinfra.co.jp/
> http://distrowatch.com/weekly.php?issue=20070917
>

Cheers,

Alan



From stepan at coresystems.de  Sat Oct  6 16:33:30 2007
From: stepan at coresystems.de (Stefan Reinauer)
Date: Sat, 06 Oct 2007 07:33:30 -0700
Subject: [LinuxBIOS] [PATCH] superiotool: Make --version actually work
 correctly
In-Reply-To: <a698c16a0710060641t3d70604fj6f3268ed600f07ef@mail.gmail.com>
References: <20071005174628.GA9851@greenwood>
	<4706B412.7080408@gmx.net>	<20071005223006.GF7148@greenwood>
	<20071005223730.GA23669@localdomain>
	<a698c16a0710060641t3d70604fj6f3268ed600f07ef@mail.gmail.com>
Message-ID: <47079CBA.8040305@coresystems.de>

Robinson Tryon wrote:
> On 10/5/07, Ward Vandewege <ward at gnu.org> wrote:
>   
>> On Sat, Oct 06, 2007 at 12:30:06AM +0200, Uwe Hermann wrote:
>>     
>>>> etc.) or at least ask some svn experts whether there is an easier and
>>>> cleaner way to include a revision number?
>>>>         
>>> Yeah, that would surely be great. Do you know any method or whom to ask?
>>> I browsed the svn code and manuals but didn't find anything better
>>> than $Rev$.
>>>       
>> Can't we do this with a commit hook that would update the version number
>> (which is in 1 place only) automatically to the SVN revision number?
>>     
>
> I was going to suggest that the buildscript pull the current revision
> # out of SVN, but the idea of a commit hook sounds like it could be
> cleaner.  Would the hook apply whenever any file is committed to the
> repository, or just to files in the superiotool directory?
>
>   
Ideally only commits to the superiotool directory should count, since
its a seperate utility.

but we might want the same thing for linuxbios, too, and add that number
to EXTRA_VERSION or so
then we know which repository revision people work on when reporting
problems.

-- 
coresystems GmbH ? Brahmsstr. 16 ? D-79104 Freiburg i. Br.
      Tel.: +49 761 7668825 ? Fax: +49 761 7664613
Email: info at coresystems.de  ? http://www.coresystems.de/
Registergericht: Amtsgericht Freiburg ? HRB 7656
Gesch?ftsf?hrer: Stefan Reinauer ? Ust-IdNr.: DE245674866




From jordan at chalmers.se  Sat Oct  6 16:36:30 2007
From: jordan at chalmers.se (Ulf Jordan)
Date: Sat, 6 Oct 2007 16:36:30 +0200 (CEST)
Subject: [LinuxBIOS] [PATCH] superiotool: Make --version actually work
 correctly
In-Reply-To: <a698c16a0710060641t3d70604fj6f3268ed600f07ef@mail.gmail.com>
References: <20071005174628.GA9851@greenwood> <4706B412.7080408@gmx.net>
	<20071005223006.GF7148@greenwood> <20071005223730.GA23669@localdomain>
	<a698c16a0710060641t3d70604fj6f3268ed600f07ef@mail.gmail.com>
Message-ID: <Pine.LNX.4.63.0710061613240.2573@elfpc10.elmagn.chalmers.se>

On Sat, 6 Oct 2007, Robinson Tryon wrote:

> On 10/5/07, Ward Vandewege <ward at gnu.org> wrote:
>> On Sat, Oct 06, 2007 at 12:30:06AM +0200, Uwe Hermann wrote:
>>>> etc.) or at least ask some svn experts whether there is an easier and
>>>> cleaner way to include a revision number?
>>>
>>> Yeah, that would surely be great. Do you know any method or whom to ask?
>>> I browsed the svn code and manuals but didn't find anything better
>>> than $Rev$.
>>
>> Can't we do this with a commit hook that would update the version number
>> (which is in 1 place only) automatically to the SVN revision number?
>
> I was going to suggest that the buildscript pull the current revision
> # out of SVN, but the idea of a commit hook sounds like it could be
> cleaner.  Would the hook apply whenever any file is committed to the
> repository, or just to files in the superiotool directory?

NACK. svn commit hooks should not change the contents of the commit, at 
least not according to the svn book (client side caching problems might 
occur).

I've attached a patch that during build time extracts the svn revision 
from $Rev$ comments in each source file, and keeps the extracted value up 
to date using make.

Direct application of the patch might give one failure on superiotool.h 
(it has the expanded $Rev$ in your working directory), and compilation 
failure on superiotool.c, since the new $Rev$'s haven't yet been expanded 
(these two issues should not appear when receiving the patch through 'svn 
update'). For testing I expanded the $Rev$ by hand to the corresponding 
svn revisions, and then it worked like a charme:

$ make
sed -ne 's/.*Rev: \([0-9]*\) .*/\1/p' ali.c fintek.c ite.c nsc.c smsc.c 
superiotool.c winbond.c superiotool.h \
         | sort -n \
         | tail -1 \
         | sed 's/.*/#define SUPERIOTOOL_VERSION "&"/' >version.h
gcc -O2 -Wall -Werror -Wstrict-prototypes -Wundef -Wstrict-aliasing 
-Werror-implicit-function-declaration -ansi   -c -o superiotool.o 
superiotool.c
gcc -O2 -Wall -Werror -Wstrict-prototypes -Wundef -Wstrict-aliasing 
-Werror-implicit-function-declaration -ansi   -c -o ali.o ali.c
gcc -O2 -Wall -Werror -Wstrict-prototypes -Wundef -Wstrict-aliasing 
-Werror-implicit-function-declaration -ansi   -c -o fintek.o fintek.c
gcc -O2 -Wall -Werror -Wstrict-prototypes -Wundef -Wstrict-aliasing 
-Werror-implicit-function-declaration -ansi   -c -o ite.o ite.c
gcc -O2 -Wall -Werror -Wstrict-prototypes -Wundef -Wstrict-aliasing 
-Werror-implicit-function-declaration -ansi   -c -o nsc.o nsc.c
gcc -O2 -Wall -Werror -Wstrict-prototypes -Wundef -Wstrict-aliasing 
-Werror-implicit-function-declaration -ansi   -c -o smsc.o smsc.c
gcc -O2 -Wall -Werror -Wstrict-prototypes -Wundef -Wstrict-aliasing 
-Werror-implicit-function-declaration -ansi   -c -o winbond.o winbond.c
gcc -O2 -Wall -Werror -Wstrict-prototypes -Wundef -Wstrict-aliasing 
-Werror-implicit-function-declaration -ansi -o superiotool superiotool.o 
ali.o fintek.o ite.o nsc.o smsc.o winbond.o
$ ./superiotool --version
superiotool r2828


/ulf
-------------- next part --------------
Extract superiotool version number from the svn revision numbers of the
*.c and superiotool.h files.

Signed-off-by: Ulf Jordan <jordan at chalmers.se>

Index: fintek.c
===================================================================
--- fintek.c	(revision 2828)
+++ fintek.c	(arbetskopia)
@@ -19,6 +19,13 @@
  * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA  02110-1301 USA
  */
 
+/*
+ * Each superiotool source file should have a revision comment for
+ * version tracking. The largest revision is extracted by the build
+ * system into version.h
+ * $Rev$
+ */
+
 #include "superiotool.h"
 
 #define DEVICE_ID_BYTE1_REG	0x20
Index: winbond.c
===================================================================
--- winbond.c	(revision 2828)
+++ winbond.c	(arbetskopia)
@@ -19,6 +19,13 @@
  * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA  02110-1301 USA
  */
 
+/*
+ * Each superiotool source file should have a revision comment for
+ * version tracking. The largest revision is extracted by the build
+ * system into version.h
+ * $Rev$
+ */
+
 #include "superiotool.h"
 
 #define DEVICE_ID_REG_OLD	0x09
Index: ite.c
===================================================================
--- ite.c	(revision 2828)
+++ ite.c	(arbetskopia)
@@ -19,6 +19,13 @@
  * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA  02110-1301 USA
  */
 
+/*
+ * Each superiotool source file should have a revision comment for
+ * version tracking. The largest revision is extracted by the build
+ * system into version.h
+ * $Rev$
+ */
+
 #include "superiotool.h"
 
 #define CHIP_ID_BYTE1_REG	0x20
Index: nsc.c
===================================================================
--- nsc.c	(revision 2828)
+++ nsc.c	(arbetskopia)
@@ -19,6 +19,13 @@
  * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA  02110-1301 USA
  */
 
+/*
+ * Each superiotool source file should have a revision comment for
+ * version tracking. The largest revision is extracted by the build
+ * system into version.h
+ * $Rev$
+ */
+
 #include "superiotool.h"
 
 #define CHIP_ID_REG	0x20	/* Super I/O ID (SID) / family */
Index: superiotool.c
===================================================================
--- superiotool.c	(revision 2828)
+++ superiotool.c	(arbetskopia)
@@ -20,6 +20,13 @@
  * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA  02110-1301 USA
  */
 
+/*
+ * Each superiotool source file should have a revision comment for
+ * version tracking. The largest revision is extracted by the build
+ * system into version.h
+ * $Rev$
+ */
+
 #include "superiotool.h"
 
 /* Command line options. */
@@ -167,12 +174,7 @@
 
 static void print_version(void)
 {
-	char tmp[80];
-
-	strncpy((char *)&tmp,
-		(const char *)&SUPERIOTOOL_VERSION[6],
-		strlen(SUPERIOTOOL_VERSION) - 8);
-	printf("superiotool r%s\n", (char *)&tmp);
+	printf("superiotool r" SUPERIOTOOL_VERSION "\n");
 }
 
 int main(int argc, char *argv[])
Index: ali.c
===================================================================
--- ali.c	(revision 2828)
+++ ali.c	(arbetskopia)
@@ -18,6 +18,13 @@
  * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA  02110-1301 USA
  */
 
+/*
+ * Each superiotool source file should have a revision comment for
+ * version tracking. The largest revision is extracted by the build
+ * system into version.h
+ * $Rev$
+ */
+
 #include "superiotool.h"
 
 #define DEVICE_ID_BYTE1_REG	0x20
Index: smsc.c
===================================================================
--- smsc.c	(revision 2828)
+++ smsc.c	(arbetskopia)
@@ -18,6 +18,13 @@
  * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA  02110-1301 USA
  */
 
+/*
+ * Each superiotool source file should have a revision comment for
+ * version tracking. The largest revision is extracted by the build
+ * system into version.h
+ * $Rev$
+ */
+
 #include "superiotool.h"
 
 #define DEVICE_ID_REG_OLD	0x0d
Index: superiotool.h
===================================================================
--- superiotool.h	(revision 2828)
+++ superiotool.h	(arbetskopia)
@@ -29,7 +29,13 @@
 #include <getopt.h>
 #include <sys/io.h>
 
-#define SUPERIOTOOL_VERSION "$Rev$"
+/*
+ * Each superiotool source file should have a revision comment for
+ * version tracking. The largest revision is extracted by the build
+ * system into version.h
+ * $Rev$
+ */
+#include "version.h"
 
 #define USAGE "Usage: superiotool [-d] [-D] [-V] [-v] [-h]\n\n\
   -d | --dump            Dump Super I/O registers\n\
Index: Makefile
===================================================================
--- Makefile	(revision 2828)
+++ Makefile	(arbetskopia)
@@ -32,6 +32,14 @@
 
 all: $(PROGRAM)
 
+superiotool.o: version.h
+
+version.h: *.c superiotool.h
+	sed -ne 's/.*Rev: \([0-9]*\) .*/\1/p' $^ \
+	| sort -n \
+	| tail -1 \
+	| sed 's/.*/#define SUPERIOTOOL_VERSION "&"/' >$@
+
 $(PROGRAM): $(OBJS) superiotool.h
 	$(CC) $(CFLAGS) -o $(PROGRAM) $(OBJS)
 
@@ -39,7 +47,7 @@
 	$(INSTALL) $(PROGRAM) $(PREFIX)/bin
 
 clean:
-	rm -f $(PROGRAM) *.o
+	rm -f $(PROGRAM) *.o version.h
 
 .PHONY: all install clean
 

From joe at smittys.pointclark.net  Sat Oct  6 16:39:00 2007
From: joe at smittys.pointclark.net (joe at smittys.pointclark.net)
Date: Sat, 06 Oct 2007 10:39:00 -0400
Subject: [LinuxBIOS] Problems with Filo booting - HELP
In-Reply-To: <20071004125949.u3xlwo9bjwgocc48@www.smittys.pointclark.net>
References: <20070929165103.pcm220bn4s48sow8@smittys.pointclark.net>
	<20070929205527.GA16584@coresystems.de>
	<20070929170245.ata0hgegqowgcwgs@www.smittys.pointclark.net>
	<20070929201342.mifqbujb44ocwks8@smittys.pointclark.net>
	<46FF1CB2.60901@gmail.com>
	<20070930115720.mwni4u7go4wkk8wg@www.smittys.pointclark.net>
	<47000290.6020000@gmail.com>
	<20071001094827.loois4qr0g4ckw8o@www.smittys.pointclark.net>
	<13426df10710010950s379f8230y5b4ffec4da605f06@mail.gmail.com>
	<20071001165858.vlz66uxpusgk0gww@www.smittys.pointclark.net>
	<47017223.6010504@gmail.com>
	<20071003190457.a6hta1e4kk8w0wwc@www.smittys.pointclark.net>
	<4704630C.8060803@gmail.com>
	<20071004002639.o29oeiku4g84w4g8@www.smittys.pointclark.net>
	<47048488.5060508@gmail.com>
	<20071004125949.u3xlwo9bjwgocc48@www.smittys.pointclark.net>
Message-ID: <20071006103900.9ogqdjwn4088ow4s@www.smittys.pointclark.net>


>> Okay, this is mostly a shot in the dark, but it's the only thing I can
>> find that might cause something like this. I'm looking at the AGP size
>> register (APSIZE, 0xb4) in the datasheet, and the default value is 0x00,
>> which is 256MB (!!). I also don't see anywhere that AGP has to be
>> explicitly enabled, it looks like it's enabled by default (yes, I see
>> AGPCMD, but it says cycles will be ignored, not that the device is
>> actually disabled and freeing the aperture memory).
>>
>> Long story short, try setting the AGP aperture to 32MB and moving the
>> aperture base (APBASE, 0x10-13) to somewhere else, preferably wherever
>> the stock bios moves it to. Even if it's not the root cause, it'll get
>> it out of the way for later.
>>
>> -Corey
>>
Corey, After scatching my head for days (hair thinning even more) I  
think you may be onto something. I have tried changing the values in  
APBASE before with no luck and I think this is why:

1. APSIZE Bits[5:3] need to be set first to 111 too allow APBASE  
Bits[27:25] to become R/W.

2. Now we can set APBASE Bits[27:25] to 111 for 32MB Aperture.

3. I noticed this in my bootlogs:

    PCI: 00:00.0 register 10(00000008), read-only ignoring it

    Which is the APBASE register. I think LB is tring to configure an  
address range for it but not able to because the address range is set  
to read only.

4. Set register GCC0 Bit 9 to 1. This enables access to the Aperture  
allowing LB to configure an address range.

I wish there was a way to just disable the Aperture all togethor for  
now but the i82830 is not designed to run in headless mode (no  
graphics). I will try this out and report back.

Thanks - Joe



From jordan.crouse at amd.com  Sat Oct  6 16:53:15 2007
From: jordan.crouse at amd.com (Jordan Crouse)
Date: Sat, 6 Oct 2007 08:53:15 -0600
Subject: [LinuxBIOS] lbrelocs - LinuxBIOSv3 re-linking tool
In-Reply-To: <13426df10710051727l28ec570v50b19d33556853ec@mail.gmail.com>
References: <20071005224248.GG32104@cosmic.amd.com>
	<20071005225647.GH32104@cosmic.amd.com>
	<13426df10710051727l28ec570v50b19d33556853ec@mail.gmail.com>
Message-ID: <20071006145315.GD9631@cosmic.amd.com>

On 05/10/07 17:27 -0700, ron minnich wrote:
> if you want true independence, why not make the stage0 symbol table a
> lar file? You could compress it. Then, later, you can make a new
> initram and will be able to link it with the stage0 that you are not
> going to change.

I had thought about originally saying that all this should go directly
into LAR, but there's one problem with that - we feed LAR the binary
for the LinuxBIOS segments, not the ELF.  So we would have to teach
LAR how to either do the binary copy too, or teach it how to call
objcopy.  I'm not sure if thats the sort of complexity that LAR needs
to learn.  We could put the ELF itself into the ROM (LinuxBIOS could
easily figure out how to call into it by parsing the headers), but thats
extra bits that we can't afford.

Jordan

-- 
Jordan Crouse
Systems Software Development Engineer 
Advanced Micro Devices, Inc.





From bishop.robinson at gmail.com  Sat Oct  6 17:42:15 2007
From: bishop.robinson at gmail.com (Robinson Tryon)
Date: Sat, 6 Oct 2007 11:42:15 -0400
Subject: [LinuxBIOS] [PATCH] superiotool: Make --version actually work
	correctly
In-Reply-To: <Pine.LNX.4.63.0710061613240.2573@elfpc10.elmagn.chalmers.se>
References: <20071005174628.GA9851@greenwood> <4706B412.7080408@gmx.net>
	<20071005223006.GF7148@greenwood> <20071005223730.GA23669@localdomain>
	<a698c16a0710060641t3d70604fj6f3268ed600f07ef@mail.gmail.com>
	<Pine.LNX.4.63.0710061613240.2573@elfpc10.elmagn.chalmers.se>
Message-ID: <a698c16a0710060842r84a87e1h1610dae77fddf2ed@mail.gmail.com>

On 10/6/07, Ulf Jordan <jordan at chalmers.se> wrote:
> On Sat, 6 Oct 2007, Robinson Tryon wrote:
>
> > On 10/5/07, Ward Vandewege <ward at gnu.org> wrote:
> >> On Sat, Oct 06, 2007 at 12:30:06AM +0200, Uwe Hermann wrote:
> >>>> etc.) or at least ask some svn experts whether there is an easier and
> >>>> cleaner way to include a revision number?
> >>>
> >>> Yeah, that would surely be great. Do you know any method or whom to ask?
> >>> I browsed the svn code and manuals but didn't find anything better
> >>> than $Rev$.
> >>
> >> Can't we do this with a commit hook that would update the version number
> >> (which is in 1 place only) automatically to the SVN revision number?
> >
> > I was going to suggest that the buildscript pull the current revision
> > # out of SVN, but the idea of a commit hook sounds like it could be
> > cleaner.  Would the hook apply whenever any file is committed to the
> > repository, or just to files in the superiotool directory?
>
> NACK. svn commit hooks should not change the contents of the commit, at
> least not according to the svn book (client side caching problems might
> occur).
>
> I've attached a patch that during build time extracts the svn revision
> from $Rev$ comments in each source file, and keeps the extracted value up
> to date using make.
>
> Direct application of the patch might give one failure on superiotool.h
> (it has the expanded $Rev$ in your working directory), and compilation
> failure on superiotool.c, since the new $Rev$'s haven't yet been expanded
> (these two issues should not appear when receiving the patch through 'svn
> update'). For testing I expanded the $Rev$ by hand to the corresponding
> svn revisions, and then it worked like a charme:

What about pulling the version directly out of SVN at build time?  Like this:

svn info | sed -n 's/.*Revision: \([0-9]*\)/\1/ p'

As long as the Makefile lives at the top level of the project, this
value should always reflect the latest commit in the current checkout.



From jordan at chalmers.se  Sat Oct  6 17:56:07 2007
From: jordan at chalmers.se (Ulf Jordan)
Date: Sat, 6 Oct 2007 17:56:07 +0200 (CEST)
Subject: [LinuxBIOS] [PATCH] superiotool: Make --version actually work
 correctly
In-Reply-To: <a698c16a0710060842r84a87e1h1610dae77fddf2ed@mail.gmail.com>
References: <20071005174628.GA9851@greenwood> <4706B412.7080408@gmx.net>
	<20071005223006.GF7148@greenwood> <20071005223730.GA23669@localdomain>
	<a698c16a0710060641t3d70604fj6f3268ed600f07ef@mail.gmail.com>
	<Pine.LNX.4.63.0710061613240.2573@elfpc10.elmagn.chalmers.se>
	<a698c16a0710060842r84a87e1h1610dae77fddf2ed@mail.gmail.com>
Message-ID: <Pine.LNX.4.63.0710061745550.3565@elfpc10.elmagn.chalmers.se>

On Sat, 6 Oct 2007, Robinson Tryon wrote:

> What about pulling the version directly out of SVN at build time?  Like this:
>
> svn info | sed -n 's/.*Revision: \([0-9]*\)/\1/ p'
>
> As long as the Makefile lives at the top level of the project, this
> value should always reflect the latest commit in the current checkout.

That looks like a good solution.

I read a bit in the svn book, and they recommend using svnversion for 
getting a "global" revision number for a set of files. However, that tool 
seems to have a bit more varying output, reflecting local changes and 
mixed revsion numbers etc.

/ulf



From bishop.robinson at gmail.com  Sat Oct  6 18:00:31 2007
From: bishop.robinson at gmail.com (Robinson Tryon)
Date: Sat, 6 Oct 2007 12:00:31 -0400
Subject: [LinuxBIOS] superiotool - dump support for fdc37b72x
Message-ID: <a698c16a0710060900t73032585j7716f046ad05ba42@mail.gmail.com>

Signed-off-by: Robinson P. Tryon <bishop.robinson at gmail.com>

I did my best to interpret the data sheet properly.  I wasn't sure if
the TEST registers were important or not, so I left them in.  I'm
still not sure about whether I should put a copyright notice in the
file, so feel free to keep or kill that line as appropriate.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: fdc37b72x.patch
Type: application/octet-stream
Size: 2005 bytes
Desc: not available
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20071006/fe6c73a3/attachment.obj>

From jonathansturges at yahoo.com  Sat Oct  6 18:04:01 2007
From: jonathansturges at yahoo.com (Jonathan Sturges)
Date: Sat, 6 Oct 2007 09:04:01 -0700 (PDT)
Subject: [LinuxBIOS] Normal vs. fallback images and CMOS
Message-ID: <447943.33531.qm@web35902.mail.mud.yahoo.com>

Question.  If an embedded board has no battery backup, it should have no (usable) CMOS.  Therefore, is a "Normal" image required on such a system?  My understanding is that CMOS settings are required to force the Fallback image to boot, except in cases of an missing or corrupt Normal image.
I'm thinking I can pack in a bigger LB payload, if there's only need for one image.  Are there any considerations I'm missing?

Thanks,
Jonathan




       
____________________________________________________________________________________
Boardwalk for $500? In 2007? Ha! Play Monopoly Here and Now (it's updated for today's economy) at Yahoo! Games.
http://get.games.yahoo.com/proddesc?gamekey=monopolyherenow  



From jordan at chalmers.se  Sat Oct  6 18:24:35 2007
From: jordan at chalmers.se (Ulf Jordan)
Date: Sat, 6 Oct 2007 18:24:35 +0200 (CEST)
Subject: [LinuxBIOS] [PATCH] superiotool: Make --version actually work
 correctly
In-Reply-To: <Pine.LNX.4.63.0710061745550.3565@elfpc10.elmagn.chalmers.se>
References: <20071005174628.GA9851@greenwood> <4706B412.7080408@gmx.net>
	<20071005223006.GF7148@greenwood> <20071005223730.GA23669@localdomain>
	<a698c16a0710060641t3d70604fj6f3268ed600f07ef@mail.gmail.com>
	<Pine.LNX.4.63.0710061613240.2573@elfpc10.elmagn.chalmers.se>
	<a698c16a0710060842r84a87e1h1610dae77fddf2ed@mail.gmail.com>
	<Pine.LNX.4.63.0710061745550.3565@elfpc10.elmagn.chalmers.se>
Message-ID: <Pine.LNX.4.63.0710061817310.3565@elfpc10.elmagn.chalmers.se>

On Sat, 6 Oct 2007, Ulf Jordan wrote:

> On Sat, 6 Oct 2007, Robinson Tryon wrote:
>
>> What about pulling the version directly out of SVN at build time?  Like this:
>>
>> svn info | sed -n 's/.*Revision: \([0-9]*\)/\1/ p'
>>
>> As long as the Makefile lives at the top level of the project, this
>> value should always reflect the latest commit in the current checkout.
>
> That looks like a good solution.

Attached is the much shorter patch using Robinson's suggestion to get
the svn revision number as the superiotool version number.

/ulf
-------------- next part --------------
Set the superiotool version number from svn.

Signed-off-by: Ulf Jordan <jordan at chalmers.se>

Index: superiotool.c
===================================================================
--- superiotool.c	(revision 2828)
+++ superiotool.c	(working copy)
@@ -167,12 +167,7 @@
 
 static void print_version(void)
 {
-	char tmp[80];
-
-	strncpy((char *)&tmp,
-		(const char *)&SUPERIOTOOL_VERSION[6],
-		strlen(SUPERIOTOOL_VERSION) - 8);
-	printf("superiotool r%s\n", (char *)&tmp);
+	printf("superiotool r" SUPERIOTOOL_VERSION "\n");
 }
 
 int main(int argc, char *argv[])
Index: superiotool.h
===================================================================
--- superiotool.h	(revision 2828)
+++ superiotool.h	(working copy)
@@ -29,7 +29,7 @@
 #include <getopt.h>
 #include <sys/io.h>
 
-#define SUPERIOTOOL_VERSION "$Rev$"
+#include "version.h"
 
 #define USAGE "Usage: superiotool [-d] [-D] [-V] [-v] [-h]\n\n\
   -d | --dump            Dump Super I/O registers\n\
Index: Makefile
===================================================================
--- Makefile	(revision 2828)
+++ Makefile	(working copy)
@@ -32,6 +32,13 @@
 
 all: $(PROGRAM)
 
+superiotool.o: version.h
+
+version.h: *.c superiotool.h
+	svn info \
+	| sed -n 's/.*Revision: \([0-9]*\)/\1/ p' \
+	| sed 's/.*/#define SUPERIOTOOL_VERSION "&"/' >$@
+
 $(PROGRAM): $(OBJS) superiotool.h
 	$(CC) $(CFLAGS) -o $(PROGRAM) $(OBJS)
 
@@ -39,7 +46,7 @@
 	$(INSTALL) $(PROGRAM) $(PREFIX)/bin
 
 clean:
-	rm -f $(PROGRAM) *.o
+	rm -f $(PROGRAM) *.o version.h
 
 .PHONY: all install clean
 

From bishop.robinson at gmail.com  Sat Oct  6 18:32:56 2007
From: bishop.robinson at gmail.com (Robinson Tryon)
Date: Sat, 6 Oct 2007 12:32:56 -0400
Subject: [LinuxBIOS] [PATCH] superiotool: Make --version actually work
	correctly
In-Reply-To: <Pine.LNX.4.63.0710061817310.3565@elfpc10.elmagn.chalmers.se>
References: <20071005174628.GA9851@greenwood> <4706B412.7080408@gmx.net>
	<20071005223006.GF7148@greenwood> <20071005223730.GA23669@localdomain>
	<a698c16a0710060641t3d70604fj6f3268ed600f07ef@mail.gmail.com>
	<Pine.LNX.4.63.0710061613240.2573@elfpc10.elmagn.chalmers.se>
	<a698c16a0710060842r84a87e1h1610dae77fddf2ed@mail.gmail.com>
	<Pine.LNX.4.63.0710061745550.3565@elfpc10.elmagn.chalmers.se>
	<Pine.LNX.4.63.0710061817310.3565@elfpc10.elmagn.chalmers.se>
Message-ID: <a698c16a0710060932t1232b0b9lea744e21baf9f7a0@mail.gmail.com>

On 10/6/07, Ulf Jordan <jordan at chalmers.se> wrote:
> On Sat, 6 Oct 2007, Ulf Jordan wrote:
>
> > On Sat, 6 Oct 2007, Robinson Tryon wrote:
> >
> >> What about pulling the version directly out of SVN at build time?  Like this:
> >>
> >> svn info | sed -n 's/.*Revision: \([0-9]*\)/\1/ p'
> >>
> >> As long as the Makefile lives at the top level of the project, this
> >> value should always reflect the latest commit in the current checkout.
> >
> > That looks like a good solution.
>
> Attached is the much shorter patch using Robinson's suggestion to get
> the svn revision number as the superiotool version number.

Looks good.



From uwe at hermann-uwe.de  Sat Oct  6 18:50:31 2007
From: uwe at hermann-uwe.de (Uwe Hermann)
Date: Sat, 6 Oct 2007 18:50:31 +0200
Subject: [LinuxBIOS] [PATCH] Call for help: superiotool
In-Reply-To: <a698c16a0710051510q4cacd55apa07f1e037e4d02eb@mail.gmail.com>
References: <20070923111315.GC12926@greenwood>
	<20071002152938.084fdaef.rasmus@wiman.org>
	<20071004022202.GA30344@greenwood>
	<20071005153243.aaa117a3.rasmus@wiman.org>
	<20071005153623.GD5376@greenwood>
	<20071005191502.7e08a759.rasmus@wiman.org>
	<20071005215921.GD7148@greenwood>
	<a698c16a0710051510q4cacd55apa07f1e037e4d02eb@mail.gmail.com>
Message-ID: <20071006165031.GA6227@greenwood>

On Fri, Oct 05, 2007 at 06:10:36PM -0400, Robinson Tryon wrote:
> On 10/5/07, Uwe Hermann <uwe at hermann-uwe.de> wrote:
> > On Fri, Oct 05, 2007 at 07:15:02PM +0200, Rasmus Wiman wrote:
> > > Signed-off-by: Rasmus Wiman <rasmus at wiman.org>
> >
> > Thanks, committed in r2828 with some very small cosmetic changes.
> > I also added you to the Copyright owner list at the top of the file.
> 
> Should I be adding myself to the copyright owner list at the top of
> the files when I add dump support for chips?  I assumed that copying
> the tables from the datasheets wouldn't be "creative" enough for me to
> assert a copyright on the commit...

Hm, I think you're right. I acted a bit too fast by adding you to the
Copyright header, sorry. However, we should still give proper credit to
all contributors, so maybe we add a THANKS or AUTHORS file (or a section
in the README file)?

Opinions?


Uwe.
-- 
http://www.hermann-uwe.de  | http://www.holsham-traders.de
http://www.crazy-hacks.org | http://www.unmaintained-free-software.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20071006/ec24a352/attachment.sig>

From bishop.robinson at gmail.com  Sat Oct  6 18:50:52 2007
From: bishop.robinson at gmail.com (Robinson Tryon)
Date: Sat, 6 Oct 2007 12:50:52 -0400
Subject: [LinuxBIOS] superiotool - dump support for fdc37b72x
In-Reply-To: <a698c16a0710060900t73032585j7716f046ad05ba42@mail.gmail.com>
References: <a698c16a0710060900t73032585j7716f046ad05ba42@mail.gmail.com>
Message-ID: <a698c16a0710060950y72193613l8c9482eace0d3b63@mail.gmail.com>

Comparing the specs for the FDC37B78x and the FDC37B72x you can see
that there's a whole lot of duplication in the dump table.  At first
glance, the global config (apart from the chip ID), the floppy,
parallel port, and serial ports have exactly the same register layout
for both chip families.

Is there some way that we can factor out these common data?



From joe at smittys.pointclark.net  Sat Oct  6 19:11:07 2007
From: joe at smittys.pointclark.net (joe at smittys.pointclark.net)
Date: Sat, 06 Oct 2007 13:11:07 -0400
Subject: [LinuxBIOS] Problems with Filo booting - HELP
In-Reply-To: <47048488.5060508@gmail.com>
References: <20070929165103.pcm220bn4s48sow8@smittys.pointclark.net>
	<20070929205527.GA16584@coresystems.de>
	<20070929170245.ata0hgegqowgcwgs@www.smittys.pointclark.net>
	<20070929201342.mifqbujb44ocwks8@smittys.pointclark.net>
	<46FF1CB2.60901@gmail.com>
	<20070930115720.mwni4u7go4wkk8wg@www.smittys.pointclark.net>
	<47000290.6020000@gmail.com>
	<20071001094827.loois4qr0g4ckw8o@www.smittys.pointclark.net>
	<13426df10710010950s379f8230y5b4ffec4da605f06@mail.gmail.com>
	<20071001165858.vlz66uxpusgk0gww@www.smittys.pointclark.net>
	<47017223.6010504@gmail.com>
	<20071003190457.a6hta1e4kk8w0wwc@www.smittys.pointclark.net>
	<4704630C.8060803@gmail.com>
	<20071004002639.o29oeiku4g84w4g8@www.smittys.pointclark.net>
	<47048488.5060508@gmail.com>
Message-ID: <20071006131107.fvu75g25cks48scs@www.smittys.pointclark.net>

> Long story short, try setting the AGP aperture to 32MB and moving the
> aperture base (APBASE, 0x10-13) to somewhere else, preferably wherever
> the stock bios moves it to. Even if it's not the root cause, it'll get
> it out of the way for later.
>
> -Corey
>
It looks like the original bios alocates the memory region 0xf0000000  
- 0xf7ffffff for the Aperture how would I force LinuxBIOS to do this??
Thanks - Joe




From bishop.robinson at gmail.com  Sat Oct  6 19:16:14 2007
From: bishop.robinson at gmail.com (Robinson Tryon)
Date: Sat, 6 Oct 2007 13:16:14 -0400
Subject: [LinuxBIOS] superiotool - dump support for fdc37b78x
Message-ID: <a698c16a0710061016y3d29ab99u790e946ab6dbdc68@mail.gmail.com>

Signed-off-by: Robinson P. Tryon <bishop.robinson at gmail.com>

(This patch builds on the b272x patch)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: fdc37b78x.patch
Type: application/octet-stream
Size: 3558 bytes
Desc: not available
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20071006/a3e50851/attachment.obj>

From stepan at coresystems.de  Sat Oct  6 19:18:27 2007
From: stepan at coresystems.de (Stefan Reinauer)
Date: Sat, 6 Oct 2007 19:18:27 +0200
Subject: [LinuxBIOS] Normal vs. fallback images and CMOS
In-Reply-To: <447943.33531.qm@web35902.mail.mud.yahoo.com>
References: <447943.33531.qm@web35902.mail.mud.yahoo.com>
Message-ID: <20071006171827.GA14760@coresystems.de>

* Jonathan Sturges <jonathansturges at yahoo.com> [071006 18:04]:
> Question.  If an embedded board has no battery backup, it should have
> no (usable) CMOS.  Therefore, is a "Normal" image required on such a
> system?  My understanding is that CMOS settings are required to force
> the Fallback image to boot, except in cases of an missing or corrupt
> Normal image.

It's rather the other way around. CMOS allows the Normal image to be
booted. So without CMOS you always boot the Fallback image. Which is
good, because Fallback uses the hardcoded default values for all
otherwise CMOS drives variables.

So just drop the Normal image.

Stefan

-- 
coresystems GmbH ? Brahmsstr. 16 ? D-79104 Freiburg i. Br.
      Tel.: +49 761 7668825 ? Fax: +49 761 7664613
Email: info at coresystems.de  ? http://www.coresystems.de/
Registergericht: Amtsgericht Freiburg ? HRB 7656
Gesch?ftsf?hrer: Stefan Reinauer ? Ust-IdNr.: DE245674866



From stepan at coresystems.de  Sat Oct  6 19:27:08 2007
From: stepan at coresystems.de (Stefan Reinauer)
Date: Sat, 6 Oct 2007 19:27:08 +0200
Subject: [LinuxBIOS] [PATCH] superiotool: Make --version actually
	work	correctly
In-Reply-To: <a698c16a0710060842r84a87e1h1610dae77fddf2ed@mail.gmail.com>
References: <20071005174628.GA9851@greenwood> <4706B412.7080408@gmx.net>
	<20071005223006.GF7148@greenwood>
	<20071005223730.GA23669@localdomain>
	<a698c16a0710060641t3d70604fj6f3268ed600f07ef@mail.gmail.com>
	<Pine.LNX.4.63.0710061613240.2573@elfpc10.elmagn.chalmers.se>
	<a698c16a0710060842r84a87e1h1610dae77fddf2ed@mail.gmail.com>
Message-ID: <20071006172706.GB14760@coresystems.de>

* Robinson Tryon <bishop.robinson at gmail.com> [071006 17:42]:
> What about pulling the version directly out of SVN at build time?  Like this:
> 
> svn info | sed -n 's/.*Revision: \([0-9]*\)/\1/ p'
> 
> As long as the Makefile lives at the top level of the project, this
> value should always reflect the latest commit in the current checkout.

unless you svn up certain subdirectories..

-- 
coresystems GmbH ? Brahmsstr. 16 ? D-79104 Freiburg i. Br.
      Tel.: +49 761 7668825 ? Fax: +49 761 7664613
Email: info at coresystems.de  ? http://www.coresystems.de/
Registergericht: Amtsgericht Freiburg ? HRB 7656
Gesch?ftsf?hrer: Stefan Reinauer ? Ust-IdNr.: DE245674866



From corey.osgood at gmail.com  Sat Oct  6 19:42:26 2007
From: corey.osgood at gmail.com (Corey Osgood)
Date: Sat, 06 Oct 2007 13:42:26 -0400
Subject: [LinuxBIOS] [PATCH] superiotool: Make --version actually	work
 correctly
In-Reply-To: <20071005223006.GF7148@greenwood>
References: <20071005174628.GA9851@greenwood> <4706B412.7080408@gmx.net>
	<20071005223006.GF7148@greenwood>
Message-ID: <4707C902.40400@gmail.com>

Uwe Hermann wrote:
> On Sat, Oct 06, 2007 at 12:00:50AM +0200, Carl-Daniel Hailfinger wrote:
>   
>> BTW, the $Rev$ output format is ugly beyond words.
>>     
>
> Full ack.
>
> That's why it has to be mangled quite a bit before usage. However, the
> final output looks ok IMO:
>
> $ ./superiotool -v
> superiotool r2821
>
>
> Uwe.
>   


Not here it doesn't:

amp at hp:~/linuxbios/lb_clean/LinuxBIOSv2/util/superiotool$ ./superiotool -v
superiotool r2821?z??
amp at hp:~/linuxbios/lb_clean/LinuxBIOSv2/util/superiotool$ ./superiotool -v
superiotool r2821????
amp at hp:~/linuxbios/lb_clean/LinuxBIOSv2/util/superiotool$ ./superiotool -v
superiotool r2821??
amp at hp:~/linuxbios/lb_clean/LinuxBIOSv2/util/superiotool$ ./superiotool -v
superiotool r2821????
amp at hp:~/linuxbios/lb_clean/LinuxBIOSv2/util/superiotool$ ./superiotool -v
superiotool r2821?*??
amp at hp:~/linuxbios/lb_clean/LinuxBIOSv2/util/superiotool$ ./superiotool -v
superiotool r2821?
amp at hp:~/linuxbios/lb_clean/LinuxBIOSv2/util/superiotool$ ./superiotool -v
superiotool r2821?:??

I agree with Carl-Daniel, that we should probably switch to a non-svn
based versioning scheme. For now, it avoids the headache of "how do we
do it". It also means that down the road if we don't touch superiotool
for 6 months, the version hasn't been bumped 300 times by LinuxBIOSv2
commits, without ever touching the tool. Which means that if this ever
starts making it into packages, maintainers don't have the headache of
trying to figure out if there actually is an updated version or not.
Just my 2 cents.

-Corey



From bishop.robinson at gmail.com  Sat Oct  6 19:45:24 2007
From: bishop.robinson at gmail.com (Robinson Tryon)
Date: Sat, 6 Oct 2007 13:45:24 -0400
Subject: [LinuxBIOS] [PATCH] superiotool: Make --version actually work
	correctly
In-Reply-To: <20071006172706.GB14760@coresystems.de>
References: <20071005174628.GA9851@greenwood> <4706B412.7080408@gmx.net>
	<20071005223006.GF7148@greenwood> <20071005223730.GA23669@localdomain>
	<a698c16a0710060641t3d70604fj6f3268ed600f07ef@mail.gmail.com>
	<Pine.LNX.4.63.0710061613240.2573@elfpc10.elmagn.chalmers.se>
	<a698c16a0710060842r84a87e1h1610dae77fddf2ed@mail.gmail.com>
	<20071006172706.GB14760@coresystems.de>
Message-ID: <a698c16a0710061045j574cb988nf33ac6a5795f51e2@mail.gmail.com>

On 10/6/07, Stefan Reinauer <stepan at coresystems.de> wrote:
> * Robinson Tryon <bishop.robinson at gmail.com> [071006 17:42]:
> > What about pulling the version directly out of SVN at build time?  Like this:
> >
> > svn info | sed -n 's/.*Revision: \([0-9]*\)/\1/ p'
> >
> > As long as the Makefile lives at the top level of the project, this
> > value should always reflect the latest commit in the current checkout.
>
> unless you svn up certain subdirectories..

I believe that my statement is still correct: the revision in the
binary will reflect the latest commit present in the current checkout.
 Of course, if that commit included files in a subdirectory as well as
at the top level, then you could have the problem of only pulling-down
half of a commit!

The only way I could see this causing a problem would be if someone
tried to build a binary without doing a top-level update.... but that
is pure folly, eh?



From corey.osgood at gmail.com  Sat Oct  6 19:53:22 2007
From: corey.osgood at gmail.com (Corey Osgood)
Date: Sat, 06 Oct 2007 13:53:22 -0400
Subject: [LinuxBIOS] [PATCH] superiotool: Make --version actually	work
 correctly
In-Reply-To: <4707C902.40400@gmail.com>
References: <20071005174628.GA9851@greenwood> <4706B412.7080408@gmx.net>
	<20071005223006.GF7148@greenwood> <4707C902.40400@gmail.com>
Message-ID: <4707CB92.6070305@gmail.com>

Corey Osgood wrote:
> Uwe Hermann wrote:
>   
>> On Sat, Oct 06, 2007 at 12:00:50AM +0200, Carl-Daniel Hailfinger wrote:
>>   
>>     
>>> BTW, the $Rev$ output format is ugly beyond words.
>>>     
>>>       
>> Full ack.
>>
>> That's why it has to be mangled quite a bit before usage. However, the
>> final output looks ok IMO:
>>
>> $ ./superiotool -v
>> superiotool r2821
>>
>>
>> Uwe.
>>   
>>     
>
>
> Not here it doesn't:
>
> amp at hp:~/linuxbios/lb_clean/LinuxBIOSv2/util/superiotool$ ./superiotool -v
> superiotool r2821?z??
> amp at hp:~/linuxbios/lb_clean/LinuxBIOSv2/util/superiotool$ ./superiotool -v
> superiotool r2821????
> amp at hp:~/linuxbios/lb_clean/LinuxBIOSv2/util/superiotool$ ./superiotool -v
> superiotool r2821??
> amp at hp:~/linuxbios/lb_clean/LinuxBIOSv2/util/superiotool$ ./superiotool -v
> superiotool r2821????
> amp at hp:~/linuxbios/lb_clean/LinuxBIOSv2/util/superiotool$ ./superiotool -v
> superiotool r2821?*??
> amp at hp:~/linuxbios/lb_clean/LinuxBIOSv2/util/superiotool$ ./superiotool -v
> superiotool r2821?
> amp at hp:~/linuxbios/lb_clean/LinuxBIOSv2/util/superiotool$ ./superiotool -v
> superiotool r2821?:??

Also just noticed it doesn't work:

amp at hp:~/linuxbios/lb_clean/LinuxBIOSv2/util/superiotool$ ./superiotool -v
superiotool r2821?:
amp at hp:~/linuxbios/lb_clean/LinuxBIOSv2/util/superiotool$ svn info
Path: .
URL: svn://linuxbios.org/repos/trunk/util/superiotool
Repository Root: svn://linuxbios.org/repos
Repository UUID: 2b7e53f0-3cfb-0310-b3e9-8179ed1497e1
Revision: 2828
Node Kind: directory
Schedule: normal
Last Changed Author: uwe
Last Changed Rev: 2828
Last Changed Date: 2007-10-05 17:58:03 -0400 (Fri, 05 Oct 2007)

-Corey



From bishop.robinson at gmail.com  Sat Oct  6 19:56:49 2007
From: bishop.robinson at gmail.com (Robinson Tryon)
Date: Sat, 6 Oct 2007 13:56:49 -0400
Subject: [LinuxBIOS] [PATCH] superiotool: Make --version actually work
	correctly
In-Reply-To: <4707C902.40400@gmail.com>
References: <20071005174628.GA9851@greenwood> <4706B412.7080408@gmx.net>
	<20071005223006.GF7148@greenwood> <4707C902.40400@gmail.com>
Message-ID: <a698c16a0710061056p7407d700v4835fae0a4775793@mail.gmail.com>

On 10/6/07, Corey Osgood <corey.osgood at gmail.com> wrote:
>
> I agree with Carl-Daniel, that we should probably switch to a non-svn
> based versioning scheme. For now, it avoids the headache of "how do we
> do it". It also means that down the road if we don't touch superiotool
> for 6 months, the version hasn't been bumped 300 times by LinuxBIOSv2
> commits, without ever touching the tool. Which means that if this ever
> starts making it into packages, maintainers don't have the headache of
> trying to figure out if there actually is an updated version or not.
> Just my 2 cents.

The patch that Ulf and I made should bump the revision number if (and
only if) one of the files in the superiotool/ directory changes.

I agree that using the SVN rev as the version # seems a little
non-standard, but when people mail in dumps to the list, it's really
nice to know exactly which version of the code was in the binary that
made that dump.  What if the version # were something more standard
and we just printed out the SVN rev alongside it?  Something like:

  superiotool v0.2 -- built from svn r255687 on Sat Oct  6 13:56:31 EDT 2007



From rminnich at gmail.com  Sat Oct  6 20:00:13 2007
From: rminnich at gmail.com (ron minnich)
Date: Sat, 6 Oct 2007 11:00:13 -0700
Subject: [LinuxBIOS] VGA support for Geode GX1/CS5530
In-Reply-To: <200710061221.09248.juergen127@kreuzholzen.de>
References: <200710052129.54369.juergen127@kreuzholzen.de>
	<200710052243.37625.juergen127@kreuzholzen.de>
	<20071005215000.GC7148@greenwood>
	<200710061221.09248.juergen127@kreuzholzen.de>
Message-ID: <13426df10710061100o471944d7r9db29d60f9e5a63f@mail.gmail.com>

On 10/6/07, Juergen Beisert <juergen127 at kreuzholzen.de> wrote:

> I will resend the patch.

send a patch to the repo, I committed your patch too soon it seems :-)

I guess I got excited about vga!

ron



From jordan at chalmers.se  Sat Oct  6 20:09:34 2007
From: jordan at chalmers.se (Ulf Jordan)
Date: Sat, 6 Oct 2007 20:09:34 +0200 (CEST)
Subject: [LinuxBIOS] [PATCH] superiotool: Make --version actually work
 correctly
In-Reply-To: <20071006172706.GB14760@coresystems.de>
References: <20071005174628.GA9851@greenwood> <4706B412.7080408@gmx.net>
	<20071005223006.GF7148@greenwood> <20071005223730.GA23669@localdomain>
	<a698c16a0710060641t3d70604fj6f3268ed600f07ef@mail.gmail.com>
	<Pine.LNX.4.63.0710061613240.2573@elfpc10.elmagn.chalmers.se>
	<a698c16a0710060842r84a87e1h1610dae77fddf2ed@mail.gmail.com>
	<20071006172706.GB14760@coresystems.de>
Message-ID: <Pine.LNX.4.63.0710061947140.13569@elfpc10.elmagn.chalmers.se>

On Sat, 6 Oct 2007, Stefan Reinauer wrote:

> * Robinson Tryon <bishop.robinson at gmail.com> [071006 17:42]:
>> What about pulling the version directly out of SVN at build time?  Like this:
>>
>> svn info | sed -n 's/.*Revision: \([0-9]*\)/\1/ p'
>>
>> As long as the Makefile lives at the top level of the project, this
>> value should always reflect the latest commit in the current checkout.
>
> unless you svn up certain subdirectories..

Also svn:externals gives problems, even "svn info -R" wont go down into 
them.

There are also a few other problems:

svn info is internationalized, so for sed to work reliably LANG=C is 
needed.

.*Revision: will read out the revision from the latest svn up.

Last Changed Rev: will read out the latest comitted change, which is more 
what we desire.

svnversion -c might be better, but it doesn't recurse, and has an 
interesting output format in the general case (but sed will fix it!)


To summarize some pros & cons:

1. $Rev$-based in files (at run time or build time):

+ granular control of which files' revisions are considered

+ clearly calculates version number only from desired files

+ does not depend on svn during build

- more complex, need to remember which files to tag with $Rev$-based code


2. svn build time based

+ easy to code both in source and makefiles

- need to be careful about which svn revision numbers are actually used to 
determine the "global" version number (latest svn up or comitted)

- recursion down into subdirectories and svn:externals needs to be 
carefully considered

- makes the build environment dependent on svn and svn meta data, which 
may cause concern in external automated build environments (like OS 
distributors)


/ulf



From lemenkov at gmail.com  Sat Oct  6 20:33:07 2007
From: lemenkov at gmail.com (Peter Lemenkov)
Date: Sat, 6 Oct 2007 22:33:07 +0400
Subject: [LinuxBIOS] System requirements for LinuxBIOS
Message-ID: <adf480660710061133u38206889u98ab9cb3212cf8b0@mail.gmail.com>

Hello All!
I can't find minimal system requirements for running LinuxBIOS.
Especially I interested in minimal size of flashrom because I've got
one mainboard with AT29C010A - 1 Megabit 128K x 8 5-volt Only CMOS
Flash Memory. Is it enough for placing LinuxBIOS there?

Maybe there are some other limitations?
-- 
With best regards!



From svn at openbios.org  Sat Oct  6 21:06:52 2007
From: svn at openbios.org (svn at openbios.org)
Date: Sat,  6 Oct 2007 21:06:52 +0200
Subject: [LinuxBIOS] r39 - trunk/filo-0.5/main
Message-ID: <mailman.704.1355071174.16123.coreboot@coreboot.org>

Author: stepan
Date: 2007-10-06 21:06:52 +0200 (Sat, 06 Oct 2007)
New Revision: 39

Modified:
   trunk/filo-0.5/main/malloc.c
Log:
This patch makes qemu work again on v3. FILO was depending on bss being zero, which is not all that safe in embedded. It's better to zero things you are depending on being zero.

Signed-off-by: Ronald G. Minnich <rminnich at gmail.com>
Acked-by: Stefan Reinauer <stepan at coresystems.de>



Modified: trunk/filo-0.5/main/malloc.c
===================================================================
--- trunk/filo-0.5/main/malloc.c	2007-10-04 06:12:32 UTC (rev 38)
+++ trunk/filo-0.5/main/malloc.c	2007-10-06 19:06:52 UTC (rev 39)
@@ -43,8 +43,10 @@
 static unsigned long total_free, total_alloc;
 static unsigned int count_free, count_alloc;
 
+/* FILO should not count on bss being zero. That's dangerous */
 static void malloc_init(void)
 {
+    memset(&_heap, 0, heap_end - heap_start);
     head = (struct block_header *) ALIGN(heap_start);
     head->prev_size = INUSE;
     head->size = ((heap_end & ~(ALIGNMENT-1)) - ALIGN(heap_start))
@@ -70,9 +72,11 @@
 {
     struct block_header *p, *new_space;
     unsigned long required, largest, remainder;
-
-    if (!head)
+    static int firsttime = 1;
+    if (firsttime) {
 	malloc_init();
+	firsttime = 0;
+    }
 
 #ifdef DEBUG
     malloc_check();




From stepan at coresystems.de  Sat Oct  6 21:13:14 2007
From: stepan at coresystems.de (Stefan Reinauer)
Date: Sat, 06 Oct 2007 12:13:14 -0700
Subject: [LinuxBIOS] :  Disable OFW
In-Reply-To: <20071004145256.GB8721@cosmic.amd.com>
References: <20071002201317.GF27248@cosmic.amd.com>
	<20071004061003.GA7211@coresystems.de>
	<20071004145256.GB8721@cosmic.amd.com>
Message-ID: <4707DE4A.4060701@coresystems.de>

Jordan Crouse wrote:
> On 04/10/07 08:10 +0200, Stefan Reinauer wrote:
>   
>> * Jordan Crouse <jordan.crouse at amd.com> [071002 22:13]:
>>     
>>> Okay, now that everybody has recovered from the last patch, here's the 
>>> last one - disable OFW for the short term in buildrom.  Reason being,
>>> that it only worked for OLPC, and the previous patch removed OLPC.   I
>>> discussed the matter briefly with Stefan and Segher, and they tell me
>>> that there are ongoing efforts to make OFW or a OpenFirmware clone of
>>> some sort usable on a generic x86.  I support that 100%, I think OFW
>>> is a vital payload for this project.  I just don't know enough about
>>> OpenFirmware to get the job done.  So I am submitting a patch to
>>> disable, but not to remove the OFW scripts, so that those who do know
>>> what they are doing can port the code easily.  When everything works,
>>> revert this patch, and we're off to the races.
>>>       
>>     
ok

Acked-by: Stefan Reinauer <stepan at coresystems.de>


-- 
coresystems GmbH ? Brahmsstr. 16 ? D-79104 Freiburg i. Br.
      Tel.: +49 761 7668825 ? Fax: +49 761 7664613
Email: info at coresystems.de  ? http://www.coresystems.de/
Registergericht: Amtsgericht Freiburg ? HRB 7656
Gesch?ftsf?hrer: Stefan Reinauer ? Ust-IdNr.: DE245674866




From juergen127 at kreuzholzen.de  Sat Oct  6 21:59:46 2007
From: juergen127 at kreuzholzen.de (Juergen Beisert)
Date: Sat, 6 Oct 2007 21:59:46 +0200
Subject: [LinuxBIOS] VGA support for Geode GX1/CS5530, 2nd try
In-Reply-To: <20071005215000.GC7148@greenwood>
References: <200710052129.54369.juergen127@kreuzholzen.de>
	<200710052243.37625.juergen127@kreuzholzen.de>
	<20071005215000.GC7148@greenwood>
Message-ID: <200710062159.47434.juergen127@kreuzholzen.de>

On Friday 05 October 2007 23:50, Uwe Hermann wrote:
> I can fix up a few of the cosmetic issues in the repository right away
> if you want, or I'll wait for another patch. Please let me know...

From: Juergen Beisert <juergen127 at kreuzholzen.de>

This patch will fix some issues with spaces in the code and Doxygen style
documentation. I hope I found all missed spaces...
Painting the splash graphic is now ifdef'ed as Uwe mentioned.

Patch is against LinuxBIOSv2, revision of 2007-10-06.

Signed-off-by: Juergen Beisert <juergen127 at kreuzholzen.de>

 config/Options.lb                   |    6
 southbridge/amd/cs5530/cs5530_vga.c |  227 ++++++++++++++++++++----------------
 2 files changed, 137 insertions(+), 96 deletions(-)

--- 

Index: LinuxBIOSv2/src/config/Options.lb
===================================================================
--- LinuxBIOSv2.orig/src/config/Options.lb
+++ LinuxBIOSv2/src/config/Options.lb
@@ -1016,6 +1016,12 @@ define CONFIG_VIDEO_MB
         comment "Integrated graphics with UMA has dynamic setup"
 end
 
+define CONFIG_SPLASH_GRAPHIC
+	default 0
+	export used
+	comment "Paint a splash screen"
+end
+
 define CONFIG_GX1_VIDEO
 	default 0
 	export used
Index: LinuxBIOSv2/src/southbridge/amd/cs5530/cs5530_vga.c
===================================================================
--- LinuxBIOSv2.orig/src/southbridge/amd/cs5530/cs5530_vga.c
+++ LinuxBIOSv2/src/southbridge/amd/cs5530/cs5530_vga.c
@@ -13,11 +13,22 @@
  * You should have received a copy of the GNU General Public License
  * along with this program; if not, write to the Free Software
  * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA, 02110-1301 USA
+ */
+
+/**
+ * @brief Activate the VGA feature in a Geode GX1 based system with one
+ * of five possible VESA modes: VGA, SVGA, XGA, 4:3 SXGA and 5:4 SXGA.
+ * Also it is prepared to display a splash screen.
  *
- * Purpose:
- * Activate the VGA feature in a Geode GX1 based system with one of five
- * possible VESA modes: VGA, SVGA, XGA, 4:3 SXGA and 5:4 SXGA. Also it is
- * prepared to display a splash screen.
+ * In a Geode GX1 environment the companion CS5530 is the VGA
+ * interface only. It contains a PLL for pixel clock generation,
+ * DACs to generate the analogue RGB signals, drivers for HSYNC
+ * and VSYNC and drivers for a digital flatpanel.
+ * The graphic feature itself (framebuffer, acceleration unit)
+ * is not part of this device. It is part of the CPU device.
+ * But both depend on each other, we cannot divide them into
+ * different drivers. So this driver is not only a CS5530 driver,
+ * it is also a Geode GX1 chipset graphic driver.
  */
 #include <arch/io.h>
 #include <device/device.h>
@@ -52,13 +63,13 @@
 #define DC_TIMING_CFG		0x8308
 #define DC_OUTPUT_CFG		0x830C
 
-/*
+/**
  * what colour depth should be used as default (in bpp)
  * Note: Currently no other value than 16 is supported
  */
 #define COLOUR_DEPTH 16
 
-/*
+/**
  * Support for a few basic video modes
  * Note: all modes only for CRT. The flatpanel feature is
  * not supported here (due to the lack of hardware to test)
@@ -67,33 +78,34 @@ struct video_mode {
 	int pixel_clock;		/*<< pixel clock in Hz */
 	unsigned long pll_value;	/*<< pll register value for this clock */
 
-	int visible_pixel;
-	int hsync_start;
-	int hsync_end;
-	int line_length;
-
-	int visible_lines;
-	int vsync_start;
-	int vsync_end;
-	int picture_length;
+	int visible_pixel;		/*<< visible pixels in one line */
+	int hsync_start;		/*<< start of hsync behind visible pixels */
+	int hsync_end;			/*<< end of hsync behind its start */
+	int line_length;		/*<< whole line length */
+
+	int visible_lines;		/*<< visible lines on screen */
+	int vsync_start;		/*<< vsync start behind last visible line */
+	int vsync_end;			/*<< end of vsync behind its start */
+	int picture_length;		/*<< whole screen length */
 
 	int sync_pol;		/*<< 0: low, 1: high, bit 0 hsync, bit 1 vsync */
 };
 
 /*
- * values for .sync_pol
+ * values for .sync_pol in struct video_mode
  */
 #define HSYNC_HIGH_POL 0
 #define HSYNC_LOW_POL 1
 #define VSYNC_HIGH_POL 0
 #define VSYNC_LOW_POL 2
 
-/* ModeLine "640x480" 31.5 640 664 704 832 480 489 491 520 -hsync -vsync */
+/**
+ * 640x480 @ 72Hz hsync: 37.9kHz
+ * VESA standard mode for classic 4:3 monitors
+ * Copied from X11:
+ * ModeLine "640x480" 31.5 640 664 704 832 480 489 491 520 -hsync -vsync
+ */
 static const struct video_mode mode_640x480 = {
-	/*
-	 * 640x480 @ 72Hz hsync: 37.9kHz
-	 * VESA standard mode for classic 4:3 monitors
-	 */
 	.pixel_clock = 31500000,
 	.pll_value = 0x33915801,
 
@@ -107,15 +119,16 @@ static const struct video_mode mode_640x
 	.vsync_end = 491,
 	.picture_length = 520, /* 13.89ms */
 
-	.sync_pol = HSYNC_LOW_POL | VSYNC_LOW_POL
+	.sync_pol = HSYNC_LOW_POL | VSYNC_LOW_POL,
 };
 
-/* ModeLine "800x600" 50.0 800 856 976 1040 600 637 643 666 +hsync +vsync */
+/**
+ * 800x600 @ 72Hz hsync: 48.1kHz
+ * VESA standard mode for classic 4:3 monitors
+ * Copied from X11:
+ * ModeLine "800x600" 50.0 800 856 976 1040 600 637 643 666 +hsync +vsync
+ */
 static const struct video_mode mode_800x600 = {
-	/*
-	 * 800x600 @ 72Hz hsync: 48.1kHz
-	 * VESA standard mode for classic 4:3 monitors
-	 */
 	.pixel_clock = 50000000,
 	.pll_value = 0x23088801,
 
@@ -129,15 +142,16 @@ static const struct video_mode mode_800x
 	.vsync_end = 643,
 	.picture_length = 666, /* 13.89ms */
 
-	.sync_pol = HSYNC_HIGH_POL | VSYNC_HIGH_POL
+	.sync_pol = HSYNC_HIGH_POL | VSYNC_HIGH_POL,
 };
 
-/* ModeLine "1024x768" 75.0 1024 1048 1184 1328 768 771 777 806 -hsync -vsync */
+/**
+ * 1024x768 @ 70Hz (VESA) hsync: 56.5kHz
+ * Standard mode for classic 4:3 monitors
+ * Copied from X11:
+ * ModeLine "1024x768" 75.0 1024 1048 1184 1328 768 771 777 806 -hsync -vsync
+ */
 static const struct video_mode mode_1024x768 = {
-	/*
-	 * 1024x768 @ 70Hz (VESA) hsync: 56.5kHz
-	 * Standard mode for classic 4:3 monitors
-	 */
 	.pixel_clock = 75000000,
 	.pll_value = 0x37E22801,
 
@@ -151,15 +165,16 @@ static const struct video_mode mode_1024
 	.vsync_end = 777,
 	.picture_length = 806,	/* 14.3us */
 
-	.sync_pol = HSYNC_LOW_POL | VSYNC_LOW_POL
+	.sync_pol = HSYNC_LOW_POL | VSYNC_LOW_POL,
 };
 
-/* ModeLine "1280x960" 108.0 1280 1376 1488 1800 960 961 964 1000 +hsync +vsync */
+/**
+ * 1280x960 @ 60Hz (VESA) hsync: 60.0kHz
+ * Mode for classic 4:3 monitors
+ * Copied from X11:
+ * ModeLine "1280x960" 108.0 1280 1376 1488 1800 960 961 964 1000 +hsync +vsync
+ */
 static const struct video_mode mode_1280x960 = {
-	/*
-	 * 1280x960 @ 60Hz (VESA) hsync: 60.0kHz
-	 * Mode for classic 4:3 monitors
-	 */
 	.pixel_clock = 108000000,
 	.pll_value = 0x2710C805,
 
@@ -173,15 +188,16 @@ static const struct video_mode mode_1280
 	.vsync_end = 964,
 	.picture_length = 1000,	/* 16.67ms */
 
-	.sync_pol = HSYNC_HIGH_POL | VSYNC_HIGH_POL
+	.sync_pol = HSYNC_HIGH_POL | VSYNC_HIGH_POL,
 };
 
-/* ModeLine "1280x1024" 108.0 1280 1328 1440 1688 1024 1025 1028 1066 +hsync +vsync */
+/**
+ * 1280x1024 @ 60Hz (VESA) hsync: 64.0kHz
+ * Mode for modern 5:4 flat screens
+ * Copied from X11:
+ * ModeLine "1280x1024" 108.0 1280 1328 1440 1688 1024 1025 1028 1066 +hsync +vsync
+ */
 static const struct video_mode mode_1280x1024 = {
-	/*
-	 * 1280x1024 @ 60Hz (VESA) hsync: 64.0kHz
-	 * Mode for modern 5:4 flat screens
-	 */
 	.pixel_clock = 108000000,
 	.pll_value = 0x2710C805,
 
@@ -195,11 +211,11 @@ static const struct video_mode mode_1280
 	.vsync_end = 1028,
 	.picture_length = 1066,
 
-	.sync_pol = HSYNC_HIGH_POL | VSYNC_HIGH_POL
+	.sync_pol = HSYNC_HIGH_POL | VSYNC_HIGH_POL,
 };
 
-/*
- * a few supported common modes
+/**
+ * List of supported common modes
  */
 static const struct video_mode *modes[] = {
 	&mode_640x480,	/* CONFIG_GX1_VIDEOMODE = 0 */
@@ -214,12 +230,14 @@ static const struct video_mode *modes[] 
 # error Requested video mode is unknown!
 #endif
 
-/*
+/**
  * Setup the pixel PLL in the companion chip
- * base: register's base address
- * pll_val: pll register value to be set
+ * @param[in] base register's base address
+ * @param[in] pll_val pll register value to be set
+ *
+ * The PLL to program here is located in the CS5530
  */
-static void cs5530_set_clock_frequency(void *io_base,unsigned long pll_val)
+static void cs5530_set_clock_frequency(void *io_base, unsigned long pll_val)
 {
 	unsigned long reg;
 
@@ -247,17 +265,26 @@ static void cs5530_set_clock_frequency(v
 	writel(reg, io_base+CS5530_DOT_CLK_CONFIG);
 }
 
-/*
+/**
  * Setup memory layout
- * gx_base: GX register area
- * mode: Data about the video mode to setup
+ * @param[in] gx_base GX register area
+ * @param[in] mode Data about the video mode to setup
  *
- * This routine assumes unlocked DC registers. Using compressed buffer
- * is not supported! (makes more sense later, but not while booting)
+ * Memory layout must be setup in Geode GX1's chipset.
+ * Note: This routine assumes unlocked DC registers.
+ * Note: Using compressed buffer is not supported yet!
+ * (makes more sense later, but not while booting)
+ *
+ * At this point a check is missed if the requested video
+ * mode is possible with the provided video memory.
+ * Check if symbol CONFIG_VIDEO_MB is at least:
+ * - 1 (=1MiB) for VGA and SVGA
+ * - 2 (=2MiB) for XGA
+ * - 4 (=4MiB) for SXGA
  */
-static void dc_setup_layout(void *gx_base,const struct video_mode *mode)
+static void dc_setup_layout(void *gx_base, const struct video_mode *mode)
 {
-	unsigned long base = 0x00000000;
+	u32 base = 0x00000000;
 
 	writel(base, gx_base + DC_FB_ST_OFFSET);
 
@@ -270,12 +297,13 @@ static void dc_setup_layout(void *gx_bas
 	writel(((COLOUR_DEPTH>>3) * mode->visible_pixel) >> 3, gx_base + DC_BUF_SIZE);
 }
 
-/*
+/**
  * Setup the HSYNC/VSYNC, active video timing
- * gx_base: GX register area
- * mode: Data about the video mode to setup
+ * @param[in] gx_base GX register area
+ * @param[in] mode Data about the video mode to setup
  *
- * This routine assumes unlocked DC registers
+ * Sync signal generation is done in Geode GX1's chipset.
+ * Note: This routine assumes unlocked DC registers
  *
  * |<------------------------- htotal ----------------------------->|
  * |<------------ hactive -------------->|                          |
@@ -295,10 +323,10 @@ static void dc_setup_layout(void *gx_bas
  * |#####################################___________________________| line data
  * |______________________________________________---------_________| YSYNC
  */
-static void dc_setup_timing(void *gx_base,const struct video_mode *mode)
+static void dc_setup_timing(void *gx_base, const struct video_mode *mode)
 {
-	unsigned long hactive, hblankstart, hsyncstart, hsyncend, hblankend, htotal;
-	unsigned long vactive, vblankstart, vsyncstart, vsyncend, vblankend, vtotal;
+	u32 hactive, hblankstart, hsyncstart, hsyncend, hblankend, htotal;
+	u32 vactive, vblankstart, vsyncstart, vsyncend, vblankend, vtotal;
 
 	hactive = mode->visible_pixel & 0x7FF;
 	hblankstart = hactive;
@@ -331,10 +359,13 @@ static void dc_setup_timing(void *gx_bas
 	writel((vsyncstart - 2) | ((vsyncend - 2) << 16), gx_base + DC_FP_V_TIMING);
 }
 
-/*
+/**
  * Setup required internals to bring the mode up and running
- * gx_base: GX register area
- * mode: Data about the video mode to setup
+ * @param[in] gx_base GX register area
+ * @param[in] mode Data about the video mode to setup
+ *
+ * Must be setup in Geode GX1's chipset.
+ * Note: This routine assumes unlocked DC registers.
  */
 static void cs5530_activate_mode(void *gx_base, const struct video_mode *mode)
 {
@@ -348,21 +379,24 @@ static void cs5530_activate_mode(void *g
 	writel(0x00003004, gx_base + DC_OUTPUT_CFG);
 }
 
-/*
+/**
  * Activate the current mode to be "visible" outside
- * gx_base: GX register area
- * mode: Data about the video mode to setup
+ * @param[in] gx_base GX register area
+ * @param[in] mode Data about the video mode to setup
+ *
+ * As we now activate the interface this must be done
+ * in the CS5530
  */
 static void cs5530_activate_video(void *io_base, const struct video_mode *mode)
 {
 	u32 val;
 
-	val = mode->sync_pol;
-	val <<= 8;
-
+	val = (u32)mode->sync_pol << 8;
 	writel(val | 0x0020002F, io_base + CS5530_DISPLAY_CONFIG);
 }
 
+#if CONFIG_SPLASH_GRAPHIC == 1
+
 /*
  * This bitmap file must provide:
  * int width: pixel count in one line
@@ -382,7 +416,7 @@ static void cs5530_activate_video(void *
  *
  * This routine assumes we are using a 16 bit colour depth!
  */
-static void show_boot_splash_16(u32 swidth,u32 sheight,u32 pitch,void *base)
+static void show_boot_splash_16(u32 swidth, u32 sheight, u32 pitch,void *base)
 {
 	int word_count,i;
 	unsigned short *adr;
@@ -391,51 +425,52 @@ static void show_boot_splash_16(u32 swid
 	 * fill the screen with the colour of the
 	 * left top pixel in the graphic
 	 */
-	word_count = pitch*sheight;
-	printk_debug("Clear Screen at %p, %d words\n",base,word_count);
-	adr = (unsigned short *) base;
-	for (i=0; i < word_count; i++, adr++)
+	word_count = pitch * sheight;
+	adr = (unsigned short*)base;
+	for (i = 0; i < word_count; i++, adr++)
 		*adr = colour_map[bitmap[0]];
-	printk_debug("Ready\n");
 
 	/*
 	 * paint the splash
 	 */
-	xstart=swidth-width;
-	ystart=sheight-height;
-	printk_debug("Start at %u,%u\n",xstart,ystart);
-	for (y=0;y<height;y++) {
-		adr=(unsigned short*)(base + pitch*(y+ystart)+2*xstart);
-		for (x=0;x<width;x++) {
-			*adr=(unsigned short)colour_map[(int)bitmap[x+y*width]];
+	xstart = swidth-width;
+	ystart = sheight-height;
+	for (y = 0; y < height; y++) {
+		adr=(unsigned short*)(base + pitch*(y+ystart) + 2 * xstart);
+		for (x = 0; x < width; x++) {
+			*adr=(unsigned short)colour_map[(int)bitmap[x + y * width]];
 			adr++;
 		}
 	}
 }
+#else
+# define show_boot_splash_16(w, x, y , z)
+#endif
 
-/*
- * management part
+/**
+ * LinuxBIOS management part
+ * @param[in] dev Info about the PCI device to initialise
  */
 static void cs5530_vga_init(device_t dev)
 {
 	const struct video_mode *mode;
 	void *io_base, *gx_base;
 
-	io_base = (void*)pci_read_config32(dev,0x10);
+	io_base = (void*)pci_read_config32(dev, 0x10);
 	gx_base = (void*)GX_BASE;
 	mode = modes[CONFIG_GX1_VIDEOMODE];
 
 	printk_debug("Setting up video mode %dx%d with %d Hz clock\n",
 		mode->visible_pixel, mode->visible_lines, mode->pixel_clock);
 
-	cs5530_set_clock_frequency(io_base,mode->pll_value);
+	cs5530_set_clock_frequency(io_base, mode->pll_value);
 
 	writel(DC_UNLOCK_MAGIC, gx_base + DC_UNLOCK);
 
 	show_boot_splash_16(mode->visible_pixel, mode->visible_lines,
-		mode->visible_pixel*(COLOUR_DEPTH>>3),(void*)(GX_BASE+0x800000));
+		mode->visible_pixel * (COLOUR_DEPTH>>3), (void*)(GX_BASE + 0x800000));
 
-	cs5530_activate_mode(gx_base,mode);
+	cs5530_activate_mode(gx_base, mode);
 
 	cs5530_activate_video(io_base, mode);
 	writel(0x00000000, gx_base + DC_UNLOCK);
@@ -446,13 +481,13 @@ static struct device_operations vga_ops 
 	.set_resources    = pci_dev_set_resources,
 	.enable_resources = pci_dev_enable_resources,
 	.init             = cs5530_vga_init,
-	.enable           = NULL /* not required */
+	.enable           = NULL, /* not required */
 };
 
 static struct pci_driver vga_pci_driver __pci_driver = {
 	.ops 	= &vga_ops,
 	.vendor = PCI_VENDOR_ID_CYRIX,
-	.device = PCI_DEVICE_ID_CYRIX_5530_VIDEO
+	.device = PCI_DEVICE_ID_CYRIX_5530_VIDEO,
 };
 
 #endif /* #if CONFIG_GX1_VIDEO == 1 */



From juergen127 at kreuzholzen.de  Sat Oct  6 22:12:37 2007
From: juergen127 at kreuzholzen.de (Juergen Beisert)
Date: Sat, 6 Oct 2007 22:12:37 +0200
Subject: [LinuxBIOS] [PATCH] Make GX1 video memory size configurable
Message-ID: <200710062212.37786.juergen127@kreuzholzen.de>

From: Juergen Beisert <juergen127 at kreuzholzen.de>

This patch makes the reserved video memory on Geode GX1 based systems
configurable. This makes sense on systems with small memories when the VGA
feature is not used (CONFIG_VIDEO_MB = 0 in this case).
On Geode GX1 based systems the following amount of memory should be reserved
when VGA support is enabled:
 - 1MiB for VGA and SVGA resolutions
 - 2MiB for XGA resolution
 - 4MiB for SXGA resolution

Patch is against LinuxBIOSv2, revision of 2007-10-06.

Signed-off-by: Juergen Beisert <juergen127 at kreuzholzen.de>

 northbridge.c |    4 +---
 1 file changed, 1 insertion(+), 3 deletions(-)

--- 

Index: LinuxBIOSv2/src/northbridge/amd/gx1/northbridge.c
===================================================================
--- LinuxBIOSv2.orig/src/northbridge/amd/gx1/northbridge.c
+++ LinuxBIOSv2/src/northbridge/amd/gx1/northbridge.c
@@ -125,8 +125,6 @@ static uint32_t find_pci_tolm(struct bus
 	return tolm;
 }
 
-#define FRAMEBUFFERK 4096
-
 static void pci_domain_set_resources(device_t dev)
 {
 	device_t mc_dev;
@@ -153,7 +151,7 @@ static void pci_domain_set_resources(dev
 		tomk = ramreg << 10;
 
 		/* Sort out the framebuffer size */
-		tomk -= FRAMEBUFFERK;
+		tomk -= CONFIG_VIDEO_MB * 1024;
 		*bcdramtop = ((tomk << 10) - 1);
 		*mcgbaseadd = (tomk >> 9);
 



From bishop.robinson at gmail.com  Sat Oct  6 22:27:33 2007
From: bishop.robinson at gmail.com (Robinson Tryon)
Date: Sat, 6 Oct 2007 16:27:33 -0400
Subject: [LinuxBIOS] superiotool - dump support for fdc37c672
Message-ID: <a698c16a0710061327h259aac4fyad1297f0929b24d8@mail.gmail.com>

Signed-off-by: Robinson P. Tryon <bishop.robinson at gmail.com>

I also looked at the FDC37M707, which appears to have a chip id of
0x42, but in the table there is already  {0x42, "FDC37B80x" ...}.  Are
these the same chip, or?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: fdc37c672.patch
Type: application/octet-stream
Size: 1379 bytes
Desc: not available
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20071006/ef405901/attachment.obj>

From kbaski at yahoo.com  Sat Oct  6 22:37:59 2007
From: kbaski at yahoo.com (Baski)
Date: Sat, 6 Oct 2007 13:37:59 -0700 (PDT)
Subject: [LinuxBIOS] Tyan s2881+opteron +ubuntu+LBv2 => no GUI
In-Reply-To: <mailman.812.1191681399.4548.linuxbios@linuxbios.org>
Message-ID: <33077.18923.qm@web51602.mail.re2.yahoo.com>

I got the latest version of LB2 as of today and followed the s2881 Built tutorial.
I extracted the VGA bios from latest AMI bios (v208)  using cbrom under  Win-XP. 

Ubuntu boots into Text mode, but fails trying to launch the GUI.
I'm pasting linuxbios log, dmesg dump and lpsci here.  Thanks in advance.
 
LB log:
LinuxBIOS-2.0.0_s2881_Fallback Sat Oct  6 13:41:10 CDT 2007 starting...
01 nodes initialized.
core0 started: 
started ap apicid:  01
SBLink=02
NC node|link=02
ht reset -


LinuxBIOS-2.0.0_s2881_Fallback Sat Oct  6 13:41:10 CDT 2007 starting...
01 nodes initialized.
core0 started: 
started ap apicid:  01
SBLink=02
NC node|link=02
Ram1.00
Ram2.00
Ram3
Initializing memory:  done
Ram4
v_esp=000cfdac
testx = 5a5a5a5a
Copying data from cache to RAM -- switching to use RAM as stack... Done
testx = 5a5a5a5a
Disabling cache as ram now 
Clearing initial memory region: Done
Copying LinuxBIOS to RAM.
src=fffe0000
dst=00004000
linxbios_ram.nrv2b length = 0000dd0c
linxbios_ram.bin   length = 000252d0
Jumping to LinuxBIOS.
LinuxBIOS-2.0.0_s2881_Fallback Sat Oct  6 13:41:10 CDT 2007 booting...
Enumerating buses...
APIC_CLUSTER: 0 enabled
PCI_DOMAIN: 0000 enabled
  PCI: 00:18.3 siblings=1
CPU: APIC: 00 enabled
CPU: APIC: 01 enabled
PCI: pci_scan_bus for bus 00
PCI: 00:18.0 [1022/1100] enabled
PCI: 00:18.1 [1022/1101] enabled
PCI: 00:18.2 [1022/1102] enabled
PCI: 00:18.3 [1022/1103] enabled
PCI: 01:00.0 [1022/7450] enabled
PCI: 01:0a.0 [1022/7450] enabled next_unitid: 000c
PCI: 01:00.0 [1022/7460] enabled
PCI: 01:0c.0 [1022/7460] enabled next_unitid: 0010
 unitid: 000c --> 0006
PCI: pci_scan_bus for bus 01
PCI: 01:06.0 [1022/7460] enabled
PCI: 01:07.0 [1022/7468] enabled
PCI: 01:07.1 [1022/7469] enabled
PCI: 01:07.2 [1022/746a] enabled
PCI: 01:07.3 [1022/746b] enabled
PCI: 01:0a.0 [1022/7450] enabled
PCI: 01:0a.1 [1022/7451] enabled
PCI: 01:0b.0 [1022/7450] enabled
PCI: 01:0b.1 [1022/7451] enabled
PCI: pci_scan_bus for bus 02
PCI: 02:00.0 [1022/7464] enabled
PCI: 02:00.1 [1022/7464] enabled
Disabling static device: PCI: 02:05.0
PCI: 02:06.0 [1002/4752] enabled
PCI: pci_scan_bus returning with max=002
PNP: 002e.0 enabled
PNP: 002e.1 disabled
PNP: 002e.2 enabled
PNP: 002e.3 disabled
PNP: 002e.5 enabled
PNP: 002e.6 disabled
PNP: 002e.7 disabled
PNP: 002e.8 disabled
PNP: 002e.9 disabled
PNP: 002e.a disabled
PNP: 002e.b enabled
smbus: PCI: 01:07.3[0]->I2C: 01:50 enabled
smbus: PCI: 01:07.3[0]->I2C: 01:51 enabled
smbus: PCI: 01:07.3[0]->I2C: 01:52 enabled
smbus: PCI: 01:07.3[0]->I2C: 01:53 enabled
smbus: PCI: 01:07.3[0]->I2C: 01:54 enabled
smbus: PCI: 01:07.3[0]->I2C: 01:55 enabled
smbus: PCI: 01:07.3[0]->I2C: 01:56 enabled
smbus: PCI: 01:07.3[0]->I2C: 01:57 enabled
smbus: PCI: 01:07.3[0]->I2C: 01:2d enabled
smbus: PCI: 01:07.3[0]->I2C: 01:2a enabled
smbus: PCI: 01:07.3[0]->I2C: 01:49 enabled
smbus: PCI: 01:07.3[0]->I2C: 01:4a enabled
PCI: pci_scan_bus for bus 03
PCI: 03:09.0 [14e4/1648] enabled
PCI: 03:09.1 [14e4/1648] enabled
Disabling static device: PCI: 03:0a.0
Disabling static device: PCI: 03:0a.1
PCI: pci_scan_bus returning with max=003
PCI: 03: 100MHz PCI-X
PCI: pci_scan_bus for bus 04
PCI: pci_scan_bus returning with max=004
PCI: 04: 133MHz PCI-X
PCI: pci_scan_bus returning with max=004
PCI: pci_scan_bus returning with max=004
scan_root_bus ok
done
Allocating resources...
Reading resources...
PCI: 01:06.0 24 <- [0x00fff00000 - 0x00ffefffff] bus 02 prefmem
PCI: 01:0a.0 1c <- [0x00fffff000 - 0x00ffffefff] bus 03 io
PCI: 01:0a.0 24 <- [0xfffffffffff00000 - 0xffffffffffefffff] bus 03 prefmem
Done reading resources.
Allocating VGA resource PCI: 02:06.0
Setting PCI_BRIDGE_CTL_VGA for bridge PCI: 01:06.0
Setting PCI_BRIDGE_CTL_VGA for bridge PCI: 00:18.0
Setting PCI_BRIDGE_CTL_VGA for bridge PCI_DOMAIN: 0000
Setting PCI_BRIDGE_CTL_VGA for bridge Root Device
Setting resources...
VGA: PCI: 00:18.0 (aka node 0) link 2 has VGA device
PCI: 00:18.0 1ba <- [0x00fd300000 - 0x00fd2fffff] prefmem <node 0 link 2>
PCI: 00:18.0 1c2 <- [0x0000001000 - 0x0000002fff] io <node 0 link 2>
PCI: 00:18.0 1b2 <- [0x00fc000000 - 0x00fd2fffff] mem <node 0 link 2>
PCI: 01:06.0 1c <- [0x0000001000 - 0x0000001fff] bus 02 io
PCI: 01:06.0 20 <- [0x00fc000000 - 0x00fd0fffff] bus 02 mem
PCI: 02:00.0 10 <- [0x00fd000000 - 0x00fd000fff] mem
PCI: 02:00.1 10 <- [0x00fd001000 - 0x00fd001fff] mem
PCI: 02:06.0 10 <- [0x00fc000000 - 0x00fcffffff] mem
PCI: 02:06.0 14 <- [0x0000001000 - 0x00000010ff] io
PCI: 02:06.0 18 <- [0x00fd002000 - 0x00fd002fff] mem
PCI: 02:06.0 30 <- [0x00fff80000 - 0x00fff9ffff] romem
PNP: 002e.0 60 <- [0x00000003f0 - 0x00000003f7] io
PNP: 002e.0 70 <- [0x0000000006 - 0x0000000006] irq
PNP: 002e.0 74 <- [0x0000000002 - 0x0000000002] drq
PNP: 002e.2 60 <- [0x00000003f8 - 0x00000003ff] io
PNP: 002e.2 70 <- [0x0000000004 - 0x0000000004] irq
PNP: 002e.5 60 <- [0x0000000060 - 0x0000000060] io
PNP: 002e.5 62 <- [0x0000000064 - 0x0000000064] io
PNP: 002e.5 70 <- [0x0000000001 - 0x0000000001] irq
PNP: 002e.5 72 <- [0x000000000c - 0x000000000c] irq
PNP: 002e.b 60 <- [0x0000000290 - 0x0000000297] io
PNP: 002e.b 70 <- [0x0000000005 - 0x0000000005] irq
PCI: 01:07.1 20 <- [0x0000002420 - 0x000000242f] io
PCI: 01:07.2 10 <- [0x0000002400 - 0x000000241f] io
PCI: 01:07.3 58 <- [0x0000002000 - 0x00000020ff] io
PCI: 01:0a.0 20 <- [0x00fd100000 - 0x00fd1fffff] bus 03 mem
PCI: 03:09.0 10 <- [0x00fd100000 - 0x00fd10ffff] mem64
PCI: 03:09.0 18 <- [0x00fd110000 - 0x00fd11ffff] mem64
PCI: 03:09.1 10 <- [0x00fd120000 - 0x00fd12ffff] mem64
PCI: 03:09.1 18 <- [0x00fd130000 - 0x00fd13ffff] mem64
PCI: 01:0a.1 10 <- [0x00fd200000 - 0x00fd200fff] mem64
PCI: 01:0b.1 10 <- [0x00fd201000 - 0x00fd201fff] mem64
PCI: 00:18.3 94 <- [0x00f8000000 - 0x00fbffffff] mem <gart>
Done setting resources.
Done allocating resources.
Enabling resources...
PCI: 00:18.0 cmd <- 00
PCI: 01:06.0 bridge ctrl <- 000b
PCI: 01:06.0 cmd <- 07
PCI: 02:00.0 subsystem <- 10f1/2881
PCI: 02:00.0 cmd <- 02
PCI: 02:00.1 subsystem <- 10f1/2881
PCI: 02:00.1 cmd <- 02
PCI: 02:06.0 subsystem <- 10f1/2881
PCI: 02:06.0 cmd <- 83
PCI: 01:07.0 subsystem <- 10f1/2881
PCI: 01:07.0 cmd <- 0f
w83627hf hwm smbus enabled
PCI: 01:07.1 subsystem <- 10f1/2881
PCI: 01:07.1 cmd <- 01
PCI: 01:07.2 subsystem <- 10f1/2881
PCI: 01:07.2 cmd <- 01
PCI: 01:07.3 subsystem <- 10f1/2881
PCI: 01:07.3 cmd <- 01
PCI: 01:0a.0 bridge ctrl <- 0003
PCI: 01:0a.0 cmd <- 06
PCI: 03:09.0 subsystem <- 10f1/2881
PCI: 03:09.0 cmd <- 02
PCI: 03:09.1 subsystem <- 10f1/2881
PCI: 03:09.1 cmd <- 02
PCI: 01:0a.1 subsystem <- 10f1/2881
PCI: 01:0a.1 cmd <- 06
PCI: 01:0b.1 subsystem <- 10f1/2881
PCI: 01:0b.1 cmd <- 06
PCI: 00:18.1 subsystem <- 10f1/2881
PCI: 00:18.1 cmd <- 00
PCI: 00:18.2 subsystem <- 10f1/2881
PCI: 00:18.2 cmd <- 00
PCI: 00:18.3 cmd <- 00
done.
Initializing devices...
Root Device init
APIC_CLUSTER: 0 init
Initializing CPU #0
CPU: vendor AMD device 20f12
CPU: family 0f, model 21, stepping 02
Enabling cache

Setting fixed MTRRs(0-88) type: UC
Setting fixed MTRRs(0-16) Type: WB, RdMEM, WrMEM
Setting fixed MTRRs(24-88) Type: WB, RdMEM, WrMEM
DONE fixed MTRRs
Setting variable MTRR 0, base:    0MB, range: 1024MB, type WB
DONE variable MTRRs
Clear out the extra MTRR's

MTRR check
Fixed MTRRs   : Enabled
Variable MTRRs: Enabled

microcode: equivalent processor rev id  = 0x0210, patch id = 0x00000000
microcode: patch id that want to apply= 0x0000004d
microcode: updated to patch id = 0x0000004d  success
CPU model Dual Core AMD Opteron(tm) Processor 275
Setting up local apic... apic_id: 0x00 done.
Clearing memory 2048K - 1048576K: --------------- done
CPU #0 Initialized
Initializing CPU #1
Waiting for 1 CPUS to stop
CPU: vendor AMD device 20f12
CPU: family 0f, model 21, stepping 02
Enabling cache

Setting fixed MTRRs(0-88) type: UC
Setting fixed MTRRs(0-16) Type: WB, RdMEM, WrMEM
Setting fixed MTRRs(24-88) Type: WB, RdMEM, WrMEM
DONE fixed MTRRs
Setting variable MTRR 0, base:    0MB, range: 1024MB, type WB
DONE variable MTRRs
Clear out the extra MTRR's

MTRR check
Fixed MTRRs   : Enabled
Variable MTRRs: Enabled

microcode: equivalent processor rev id  = 0x0210, patch id = 0x00000000
microcode: patch id that want to apply= 0x0000004d
microcode: updated to patch id = 0x0000004d  success
CPU model Dual Core AMD Opteron(tm) Processor 275
Setting up local apic... apic_id: 0x01 done.
CPU #1 Initialized
All AP CPUs stopped
PCI: 00:18.0 init
PCI: 01:0a.0 init
PCI: 03:09.0 init
PCI: 03:09.1 init
PCI: 01:06.0 init
PCI: 02:06.0 init
rom address for PCI: 02:06.0 = fff80000
copying VGA ROM Image from 0xfff80000 to 0xc0000, 0x9000 bytes
entering emulator
halt_sys: file /home/baski/LinuxBIOSv2/src/devices/emulator/x86emu/ops.c, line 4
387
PCI: 01:07.0 init
amd8111: ioapic bsp_apicid = 00
RTC Init
RTC: Checksum invalid zeroing cmos
Invalid CMOS LB checksum
enabling HPET @0xfed00000
PNP: 002e.0 init
PNP: 002e.2 init
PNP: 002e.5 init
PNP: 002e.b init
PCI: 01:07.1 init
IDE1 IDE0 PCI: 01:07.3 init
set power on after power fail
smbus: PCI: 01:07.3[0]->I2C: 01:2d init
ADM1027: monitoring enabled
PCI: 00:18.1 init
PCI: 00:18.2 init
PCI: 00:18.3 init
NB: Function 3 Misc Control.. done.
PNP: 0000.0 init
SMBus controller found
ADT7463 found
ADT7463 properly initializedDevices initialized
Writing IRQ routing tables to 0xf0000...done.
Wrote the mp table end at: 00000020 - 000001cc
Moving GDT to 0x500...ok
Adjust low_table_end from 0x00000530 to 0x00001000 
Adjust rom_table_end from 0x000f0400 to 0x00100000 
Wrote linuxbios table at: 00000530 - 00000dcc  checksum ad64

Welcome to elfboot, the open sourced starter.
January 2002, Eric Biederman.
Version 1.3

rom_stream: 0xfffc0000 - 0xfffdffff
Found ELF candidate at offset 0
header_offset is 0
Try to load at offset 0x0
New segment addr 0x100000 size 0x3d6c0 offset 0xc0 filesize 0x136c8
(cleaned up) New segment addr 0x100000 size 0x3d6c0 offset 0xc0 filesize 0x136c8
New segment addr 0x13d6c0 size 0x48 offset 0x137a0 filesize 0x48
(cleaned up) New segment addr 0x13d6c0 size 0x48 offset 0x137a0 filesize 0x48
Dropping non PT_LOAD segment
Dropping non PT_LOAD segment
Loading Segment: addr: 0x0000000000100000 memsz: 0x000000000003d6c0 filesz: 0x00
000000000136c8
Clearing Segment: addr: 0x00000000001136c8 memsz: 0x0000000000029ff8
Loading Segment: addr: 0x000000000013d6c0 memsz: 0x0000000000000048 filesz: 0x00
00000000000048
Jumping to boot code at 0x10e81c
FILO version 0.5 (root at Bharathi) Sat Oct  6 04:42:05 CDT 2007
collect_linuxbios_info: Searching for LinuxBIOS tables...
find_lb_table: Found candidate at: 00000530
find_lb_table: header checksum o.k.
find_lb_table: table checksum o.k.
find_lb_table: record count o.k.
collect_linuxbios_info: Found LinuxBIOS table at: 00000530
convert_memmap: 0x00000000000000 0x00000000001000 16
convert_memmap: 0x00000000001000 0x0000000009f000 1
convert_memmap: 0x000000000c0000 0x00000000030000 1
convert_memmap: 0x000000000f0000 0x00000000010000 16
convert_memmap: 0x00000000100000 0x0000003ff00000 1
Press <Enter> for default menu.lst (hda1:/boot/grub/menu.lst), or <Esc> for prom

menu: hda1:/boot/grub/menu.lst
hda: LBA 20GB: ST320413A                               
Mounted ext2fs
Found Linux version 2.6.20-16-generic (root at terranova) #2 SMP Sun Sep 23 19:50:3
9 UTC 2007 (protocol 0x205) (loadflags 0x1) bzImage.
init_linux_params: Setting up paramters at 0x90000
set_memory_size: 0000000000001000 - 00000000000a0000
set_memory_size: 00000000000c0000 - 00000000000f0000
set_memory_size: 0000000000100000 - 0000000040000000
set_memory_size: ramtop=0x40000000
set_memory_size: ext_mem_k=64512, alt_mem_k=1047552
parse_command_line: original command line: "root=UUID=5b3a4606-2585-402e-87be-4b
314cc7edd0 ro console=tty0 console=ttyS0,115200 quiet splash initrd=/boot/initrd
.img-2.6.20-16-generic"
parse_command_line: kernel command line at 0x91000
parse_command_line: initrd=/boot/initrd.img-2.6.20-16-generic
parse_command_line: kernel command line (96 bytes): "root=UUID=5b3a4606-2585-402
e-87be-4b314cc7edd0 ro console=tty0 console=ttyS0,115200 quiet splash"
load_linux_kernel: offset=0x1e00 addr=0x100000 size=0x1a8bac
Loading kernel... ok
load_initrd: start=0x1f961000 end=0x1ffffead
Loading initrd... ok
start_linux: eip=0x100000
Jumping to entry point...
[    0.000000] ACPI: Unable to locate RSDP
[    0.173372] PCI: Unable to handle 64-bit address space for bridge 0000:01:0a.
0
Loading, please wait...
usplash: libusplash.c:260: switch_console: Assertion `(saved_vt >= 0) && (saved_
vt < 10)' failed.
kinit: name_to_dev_t(/dev/disk/by-uuid/de4789bd-6c3e-4035-8587-c3d7d86e9c49) = h
da5(3,5)
kinit: trying to resume from /dev/disk/by-uuid/de4789bd-6c3e-4035-8587-c3d7d86e9
c49
kinit: No resume image, doing normal boot...
 * Reading files needed to boot...        [ OK ]
 * Setting preliminary keymap...        [ OK ]
 * Preparing restricted drivers...        [ OK ]
 * Starting basic networking...        [ OK ]
 * Starting kernel event manager...        [ OK ]
 * Loading hardware drivers...        
[   24.152000] shpchp: shpc_init: cannot reserve MMIO region
[   24.156000] shpchp: shpc_init: cannot reserve MMIO region
[   24.160000] shpchp: shpc_init: cannot reserve MMIO region
[ OK ]
 * Loading kernel modules...        
 * Loading manual drivers...        [ OK ]
 * Activating swap...        [ OK ]
 * Checking root file system...        
fsck 1.40-WIP (14-Nov-2006)
/dev/hda1: clean, 139655/2338336 files, 735473/4672899 blocks
[ OK ]
 * Checking file systems...        
fsck 1.40-WIP (14-Nov-2006)
[ OK ]
 * Mounting local filesystems...        [ OK ]
 * Activating swapfile swap...        [ OK ]
 * Configuring network interfaces...        [ OK ]
 * Starting system log daemon...        [ OK ]
 * Doing Wacom setup...        
cat: */id: No such file or directory
[ OK ]
 * Starting kernel log...        [ OK ]
 * Starting system message bus dbus        [ OK ]
 * Starting Hardware abstraction layer hald        [ OK ]
 * Starting DHCP D-Bus daemon dhcdbd        [ OK ]
 * Starting network connection manager NetworkManager        [ OK ]
 * Starting Avahi mDNS/DNS-SD Daemon: avahi-daemon        [ OK ]
 * Starting network events dispatcher NetworkManagerDispatcher        [ OK ]
 * Starting System Tools Backends system-tools-backends        [ OK ]
 * Starting GNOME Display Manager...        [ OK ]
 * Starting Common Unix Printing System: cupsd        [ OK ]
 * Starting HP Linux Printing and Imaging System        [ OK ]
 * Starting powernowd...         
/etc/rc2.d/S20powernowd: 156: cannot create /sys/devices/system/cpu/cpu0//cpufre
q/scaling_governor: Directory nonexistent
 * CPU frequency scaling not supported
[ OK ]
 * Starting Bluetooth services        [ OK ]
 * Starting anac(h)ronistic cron anacron        [ OK ]
 * Starting deferred execution scheduler atd        [ OK ]
 * Starting periodic command scheduler crond        [ OK ]
 * Enabling additional executable binary formats binfmt-support        [ OK ]
 * Checking battery state...        [ OK ]
 * Running local boot scripts (/etc/rc.local)        [ OK ]

dmseg:
======
[    0.000000] Linux version 2.6.20-16-generic (root at terranova) (gcc version 4.1.2 (Ubuntu 4.1.2-0ubuntu4)) #2 SMP Sun Sep 23 19:50:39 UTC 2007 (Ubuntu 2.6.20-16.32-generic)
[    0.000000] BIOS-provided physical RAM map:
[    0.000000] sanitize start
[    0.000000] sanitize end
[    0.000000] copy_e820_map() start: 0000000000001000 size: 000000000009f000 end: 00000000000a0000 type: 1
[    0.000000] copy_e820_map() type is E820_RAM
[    0.000000] copy_e820_map() start: 00000000000c0000 size: 0000000000030000 end: 00000000000f0000 type: 1
[    0.000000] copy_e820_map() type is E820_RAM
[    0.000000] copy_e820_map() lies in range...
[    0.000000] copy_e820_map() end <= 0x100000ULL
[    0.000000] copy_e820_map() start: 0000000000100000 size: 000000003ff00000 end: 0000000040000000 type: 1
[    0.000000] copy_e820_map() type is E820_RAM
[    0.000000]  BIOS-e820: 0000000000001000 - 00000000000a0000 (usable)
[    0.000000]  BIOS-e820: 0000000000100000 - 0000000040000000 (usable)
[    0.000000] 128MB HIGHMEM available.
[    0.000000] 896MB LOWMEM available.
[    0.000000] found SMP MP-table at 00000010
[    0.000000] Entering add_active_range(0, 0, 262144) 0 entries of 256 used
[    0.000000] Zone PFN ranges:
[    0.000000]   DMA             0 ->     4096
[    0.000000]   Normal       4096 ->   229376
[    0.000000]   HighMem    229376 ->   262144
[    0.000000] early_node_map[1] active PFN ranges
[    0.000000]     0:        0 ->   262144
[    0.000000] On node 0 totalpages: 262144
[    0.000000]   DMA zone: 32 pages used for memmap
[    0.000000]   DMA zone: 0 pages reserved
[    0.000000]   DMA zone: 4064 pages, LIFO batch:0
[    0.000000]   Normal zone: 1760 pages used for memmap
[    0.000000]   Normal zone: 223520 pages, LIFO batch:31
[    0.000000]   HighMem zone: 256 pages used for memmap
[    0.000000]   HighMem zone: 32512 pages, LIFO batch:7
[    0.000000] DMI not present or invalid.
[    0.000000] ACPI: Unable to locate RSDP
[    0.000000] Intel MultiProcessor Specification v1.4
[    0.000000]     Virtual Wire compatibility mode.
[    0.000000] OEM ID: TYAN     Product ID: S2881        APIC at: 0xFEE00000
[    0.000000] Processor #0 15:1 APIC version 16
[    0.000000] Processor #1 15:1 APIC version 16
[    0.000000] I/O APIC #2 Version 17 at 0xFEC00000.
[    0.000000] I/O APIC #3 Version 17 at 0xFD200000.
[    0.000000] I/O APIC #4 Version 17 at 0xFD201000.
[    0.000000] Enabling APIC mode:  Flat.  Using 3 I/O APICs
[    0.000000] Processors: 2
[    0.000000] Allocating PCI resources starting at 50000000 (gap: 40000000:c0000000)
[    0.000000] Detected 2191.253 MHz processor.
[   76.672598] Built 1 zonelists.  Total pages: 260096
[   76.672601] Kernel command line: root=UUID=5b3a4606-2585-402e-87be-4b314cc7edd0 ro console=tty0 console=ttyS0,115200 quiet splash
[   76.672724] mapped APIC to ffffd000 (fee00000)
[   76.672726] mapped IOAPIC to ffffc000 (fec00000)
[   76.672728] mapped IOAPIC to ffffb000 (fd200000)
[   76.672730] mapped IOAPIC to ffffa000 (fd201000)
[   76.672732] Enabling fast FPU save and restore... done.
[   76.672734] Enabling unmasked SIMD FPU exception support... done.
[   76.672742] Initializing CPU#0
[   76.672806] PID hash table entries: 4096 (order: 12, 16384 bytes)
[   76.675390] Console: colour VGA+ 80x25
[   76.679884] Dentry cache hash table entries: 131072 (order: 7, 524288 bytes)
[   76.680249] Inode-cache hash table entries: 65536 (order: 6, 262144 bytes)
[   76.697022] Memory: 1028524k/1048576k available (1993k kernel code, 19496k reserved, 900k data, 328k init, 131072k highmem)
[   76.697031] virtual kernel memory layout:
[   76.697032]     fixmap  : 0xfff4e000 - 0xfffff000   ( 708 kB)
[   76.697033]     pkmap   : 0xff800000 - 0xffc00000   (4096 kB)
[   76.697034]     vmalloc : 0xf8800000 - 0xff7fe000   ( 111 MB)
[   76.697035]     lowmem  : 0xc0000000 - 0xf8000000   ( 896 MB)
[   76.697036]       .init : 0xc03d9000 - 0xc042b000   ( 328 kB)
[   76.697037]       .data : 0xc02f2429 - 0xc03d36d4   ( 900 kB)
[   76.697038]       .text : 0xc0100000 - 0xc02f2429   (1993 kB)
[   76.697041] Checking if this processor honours the WP bit even in supervisor mode... Ok.
[   76.776739] Calibrating delay using timer specific routine.. 4386.55 BogoMIPS (lpj=8773117)
[   76.776774] Security Framework v1.0.0 initialized
[   76.776779] SELinux:  Disabled at boot.
[   76.776792] Mount-cache hash table entries: 512
[   76.776908] CPU: After generic identify, caps: 178bfbff e3d3fbff 00000000 00000000 00000001 00000000 00000003
[   76.776916] CPU: L1 I Cache: 64K (64 bytes/line), D cache 64K (64 bytes/line)
[   76.776918] CPU: L2 Cache: 1024K (64 bytes/line)
[   76.776920] CPU 0(2) -> Core 0
[   76.776922] CPU: After all inits, caps: 178bfbff e3d3fbff 00000000 00000410 00000001 00000000 00000003
[   76.776932] Compat vDSO mapped to ffffe000.
[   76.776935] Remapping vsyscall page to ffffe000
[   76.776944] Checking 'hlt' instruction... OK.
[   76.792851] SMP alternatives: switching to UP code
[   76.793231] Early unpacking initramfs... done
[   77.047725] CPU0: AMD Dual Core AMD Opteron(tm) Processor 275 stepping 02
[   77.047744] SMP alternatives: switching to SMP code
[   77.047840] Booting processor 1/1 eip 3000
[   77.058051] Initializing CPU#1
[   77.136478] Calibrating delay using timer specific routine.. 4382.41 BogoMIPS (lpj=8764835)
[   77.136484] CPU: After generic identify, caps: 178bfbff e3d3fbff 00000000 00000000 00000001 00000000 00000003
[   77.136490] CPU: L1 I Cache: 64K (64 bytes/line), D cache 64K (64 bytes/line)
[   77.136492] CPU: L2 Cache: 1024K (64 bytes/line)
[   77.136494] CPU 1(2) -> Core 1
[   77.136495] CPU: After all inits, caps: 178bfbff e3d3fbff 00000000 00000410 00000001 00000000 00000003
[   77.136686] CPU1: AMD Dual Core AMD Opteron(tm) Processor 275 stepping 02
[   77.136700] Total of 2 processors activated (8768.97 BogoMIPS).
[   77.136923] ENABLING IO-APIC IRQs
[   77.137192] ..TIMER: vector=0x31 apic1=0 pin1=2 apic2=0 pin2=0
[   77.284380] checking TSC synchronization across 2 CPUs: passed.
[    0.003997] Brought up 2 CPUs
[    0.171190] migration_cost=524
[    0.171415] Booting paravirtualized kernel on bare hardware
[    0.171502] Time: 18:46:21  Date: 09/06/107
[    0.171528] NET: Registered protocol family 16
[    0.171597] EISA bus registered
[    0.172005] PCI: Using configuration type 1
[    0.172007] Setting up standard PCI resources
[    0.172475] ACPI: Interpreter disabled.
[    0.172477] Linux Plug and Play Support v0.97 (c) Adam Belay
[    0.172483] pnp: PnP ACPI: disabled
[    0.172484] PnPBIOS: Scanning system for PnP BIOS support...
[    0.172493] PnPBIOS: PnP BIOS support was not detected.
[    0.172524] PCI: Probing PCI hardware
[    0.172526] PCI: Probing PCI hardware (bus 00)
[    0.173220] Boot video device is 0000:02:06.0
[    0.173372] PCI: Unable to handle 64-bit address space for bridge 0000:01:0a.0
[    0.181144] PCI: Discovered primary peer bus 01 [IRQ]
[    0.181149] PCI: Using IRQ router default [1022/7468] at 0000:01:07.0
[    0.181159] PCI->APIC IRQ transform: 0000:01:07.2[D] -> IRQ 19
[    0.181166] PCI->APIC IRQ transform: 0000:02:00.0[D] -> IRQ 19
[    0.181169] PCI->APIC IRQ transform: 0000:02:00.1[D] -> IRQ 19
[    0.181172] PCI->APIC IRQ transform: 0000:02:06.0[A] -> IRQ 18
[    0.181175] PCI->APIC IRQ transform: 0000:03:09.0[A] -> IRQ 24
[    0.181178] PCI->APIC IRQ transform: 0000:03:09.1[B] -> IRQ 25
[    0.181224] NET: Registered protocol family 8
[    0.181225] NET: Registered protocol family 20
[    0.181445] PCI: Bridge: 0000:01:06.0
[    0.181448]   IO window: 1000-1fff
[    0.181452]   MEM window: fc000000-fd0fffff
[    0.181456]   PREFETCH window: 50000000-500fffff
[    0.181461] PCI: Bridge: 0000:01:0a.0
[    0.181462]   IO window: disabled.
[    0.181465]   MEM window: fd100000-fd1fffff
[    0.181468]   PREFETCH window: 50100000-501fffff
[    0.181470] PCI: Bridge: 0000:01:0b.0
[    0.181472]   IO window: disabled.
[    0.181474]   MEM window: disabled.
[    0.181476]   PREFETCH window: disabled.
[    0.181522] NET: Registered protocol family 2
[    0.215878] IP route cache hash table entries: 32768 (order: 5, 131072 bytes)
[    0.215998] TCP established hash table entries: 131072 (order: 8, 1048576 bytes)
[    0.216815] TCP bind hash table entries: 65536 (order: 7, 524288 bytes)
[    0.217213] TCP: Hash tables configured (established 131072 bind 65536)
[    0.217215] TCP reno registered
[    0.231932] checking if image is initramfs... it is
[    0.734631] Freeing initrd memory: 6779k freed
[    1.244000] audit: initializing netlink socket (disabled)
[    1.244000] audit(1191696382.428:1): initialized
[    1.244000] highmem bounce pool size: 64 pages
[    1.244000] VFS: Disk quotas dquot_6.5.1
[    1.244000] Dquot-cache hash table entries: 1024 (order 0, 4096 bytes)
[    1.244000] io scheduler noop registered
[    1.244000] io scheduler anticipatory registered
[    1.244000] io scheduler deadline registered
[    1.244000] io scheduler cfq registered (default)
[    1.244000] PCI: MSI quirk detected. PCI_BUS_FLAGS_NO_MSI set for 0000:01:0a.0 subordinate bus.
[    1.244000] PCI: MSI quirk detected. PCI_BUS_FLAGS_NO_MSI set for 0000:01:0b.0 subordinate bus.
[    1.248000] isapnp: Scanning for PnP cards...
[    1.600000] isapnp: No Plug & Play device found
[    1.620000] Real Time Clock Driver v1.12ac
[    1.620000] Serial: 8250/16550 driver $Revision: 1.90 $ 4 ports, IRQ sharing enabled
[    1.620000] serial8250: ttyS0 at I/O 0x3f8 (irq = 4) is a 16550A
[    1.620000] mice: PS/2 mouse device common for all mice
[    1.620000] RAMDISK driver initialized: 16 RAM disks of 65536K size 1024 blocksize
[    1.620000] input: Macintosh mouse button emulation as /class/input/input0
[    1.620000] Uniform Multi-Platform E-IDE driver Revision: 7.00alpha2
[    1.620000] ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx
[    1.620000] PNP: No PS/2 controller found. Probing ports directly.
[    1.624000] serio: i8042 KBD port at 0x60,0x64 irq 1
[    1.624000] serio: i8042 AUX port at 0x60,0x64 irq 12
[    1.624000] EISA: Probing bus 0 at eisa.0
[    1.624000] Cannot allocate resource for EISA slot 1
[    1.624000] Cannot allocate resource for EISA slot 2
[    1.624000] EISA: Detected 0 cards.
[    1.624000] TCP cubic registered
[    1.624000] NET: Registered protocol family 1
[    1.624000] Starting balanced_irq
[    1.624000] Using IPI No-Shortcut mode
[    1.624000]   Magic number: 11:619:796
[    1.624000]   hash matches device ptyr4
[    1.624000] Freeing unused kernel memory: 328k freed
[    1.640000] input: AT Translated Set 2 keyboard as /class/input/input1
[    2.836000] Capability LSM initialized
[    2.896000] thermal: Unknown symbol acpi_processor_set_thermal_limit
[    3.236000] SCSI subsystem initialized
[    3.240000] libata version 2.20 loaded.
[    3.252000] AMD8111: IDE controller at PCI slot 0000:01:07.1
[    3.252000] AMD8111: chipset revision 3
[    3.252000] AMD8111: not 100% native mode: will probe irqs later
[    3.252000] AMD8111: 0000:01:07.1 (rev 03) UDMA133 controller
[    3.252000]     ide0: BM-DMA at 0x2420-0x2427, BIOS settings: hda:pio, hdb:pio
[    3.252000]     ide1: BM-DMA at 0x2428-0x242f, BIOS settings: hdc:pio, hdd:pio
[    3.252000] Probing IDE interface ide0...
[    3.296000] usbcore: registered new interface driver usbfs
[    3.296000] usbcore: registered new interface driver hub
[    3.296000] usbcore: registered new device driver usb
[    3.296000] ohci_hcd: 2006 August 04 USB 1.1 'Open' Host Controller (OHCI) Driver
[    3.548000] hda: ST320413A, ATA DISK drive
[    4.224000] ide0 at 0x1f0-0x1f7,0x3f6 on irq 14
[    4.224000] Probing IDE interface ide1...
[    4.792000] ohci_hcd 0000:02:00.0: OHCI Host Controller
[    4.796000] ohci_hcd 0000:02:00.0: new USB bus registered, assigned bus number 1
[    4.796000] ohci_hcd 0000:02:00.0: irq 19, io mem 0xfd000000
[    4.856000] usb usb1: configuration #1 chosen from 1 choice
[    4.856000] hub 1-0:1.0: USB hub found
[    4.856000] hub 1-0:1.0: 3 ports detected
[    4.960000] ohci_hcd 0000:02:00.1: OHCI Host Controller
[    4.960000] ohci_hcd 0000:02:00.1: new USB bus registered, assigned bus number 2
[    4.960000] ohci_hcd 0000:02:00.1: irq 19, io mem 0xfd001000
[    5.020000] usb usb2: configuration #1 chosen from 1 choice
[    5.020000] hub 2-0:1.0: USB hub found
[    5.020000] hub 2-0:1.0: 3 ports detected
[    5.128000] tg3.c:v3.72.1 (January 8, 2007)
[    5.160000] eth0: Tigon3 [partno(BCM95704A7) rev 2003 PHY(5704)] (PCIX:100MHz:64-bit) 10/100/1000Base-T Ethernet 00:e0:81:2f:6d:8c
[    5.160000] eth0: RXcsums[1] LinkChgREG[0] MIirq[0] ASF[0] Split[0] WireSpeed[1] TSOcap[1] 
[    5.160000] eth0: dma_rwctrl[769f4000] dma_mask[64-bit]
[    5.192000] eth1: Tigon3 [partno(BCM95704A7) rev 2003 PHY(5704)] (PCIX:100MHz:64-bit) 10/100/1000Base-T Ethernet 00:e0:81:2f:6d:8d
[    5.192000] eth1: RXcsums[1] LinkChgREG[0] MIirq[0] ASF[0] Split[0] WireSpeed[1] TSOcap[1] 
[    5.192000] eth1: dma_rwctrl[769f4000] dma_mask[64-bit]
[    5.196000] hda: max request size: 128KiB
[    5.200000] hda: 39102336 sectors (20020 MB) w/512KiB Cache, CHS=38792/16/63, UDMA(100)
[    5.200000] hda: cache flushes not supported
[    5.200000]  hda:<6>usb 1-2: new full speed USB device using ohci_hcd and address 2
[    5.492000] usb 1-2: configuration #1 chosen from 1 choice
[    5.708000] hda: dma_intr: status=0x51 { DriveReady SeekComplete Error }
[    5.708000] hda: dma_intr: error=0x84 { DriveStatusError BadCRC }
[    5.708000] ide: failed opcode was: unknown
[    5.804000] usb 1-3: new low speed USB device using ohci_hcd and address 3
[    6.020000] usb 1-3: configuration #1 chosen from 1 choice
[    6.024000] usbcore: registered new interface driver libusual
[    6.028000] Initializing USB Mass Storage driver...
[    6.028000] scsi0 : SCSI emulation for USB Mass Storage devices
[    6.028000] usb-storage: device found at 2
[    6.028000] usb-storage: waiting for device to settle before scanning
[    6.028000] usbcore: registered new interface driver usb-storage
[    6.028000] USB Mass Storage support registered.
[    6.032000] usbcore: registered new interface driver hiddev
[    6.040000] input: HID 1241:1111 as /class/input/input2
[    6.040000] input: USB HID v1.00 Mouse [HID 1241:1111] on usb-0000:02:00.0-3
[    6.040000] usbcore: registered new interface driver usbhid
[    6.040000] drivers/usb/input/hid-core.c: v2.6:USB HID core driver
[    6.212000] hda: dma_intr: status=0x51 { DriveReady SeekComplete Error }
[    6.212000] hda: dma_intr: error=0x84 { DriveStatusError BadCRC }
[    6.212000] ide: failed opcode was: unknown
[    6.660000] hda: dma_intr: status=0x51 { DriveReady SeekComplete Error }
[    6.660000] hda: dma_intr: error=0x84 { DriveStatusError BadCRC }
[    6.660000] ide: failed opcode was: unknown
[    7.152000] hda: dma_intr: status=0x51 { DriveReady SeekComplete Error }
[    7.152000] hda: dma_intr: error=0x84 { DriveStatusError BadCRC }
[    7.152000] ide: failed opcode was: unknown
[    7.200000] ide0: reset: success
[    7.220000]  hda1 hda2 < hda5 >
[    7.564000] Attempting manual resume
[    7.564000] swsusp: Resume From Partition 3:5
[    7.564000] PM: Checking swsusp image.
[    7.600000] PM: Resume from disk failed.
[    7.664000] kjournald starting.  Commit interval 5 seconds
[    7.664000] EXT3-fs: mounted filesystem with ordered data mode.
[    8.252000] hda: dma_intr: status=0x51 { DriveReady SeekComplete Error }
[    8.252000] hda: dma_intr: error=0x84 { DriveStatusError BadCRC }
[    8.252000] ide: failed opcode was: unknown
[    8.724000] hda: dma_intr: status=0x51 { DriveReady SeekComplete Error }
[    8.724000] hda: dma_intr: error=0x84 { DriveStatusError BadCRC }
[    8.724000] ide: failed opcode was: unknown
[    9.176000] hda: dma_intr: status=0x51 { DriveReady SeekComplete Error }
[    9.176000] hda: dma_intr: error=0x84 { DriveStatusError BadCRC }
[    9.176000] ide: failed opcode was: unknown
[    9.664000] hda: dma_intr: status=0x51 { DriveReady SeekComplete Error }
[    9.664000] hda: dma_intr: error=0x84 { DriveStatusError BadCRC }
[    9.664000] ide: failed opcode was: unknown
[    9.712000] ide0: reset: success
[   11.028000] usb-storage: device scan complete
[   11.060000] scsi 0:0:0:0: Direct-Access     NEC      USB UF000x       1.50 PQ: 0 ANSI: 0 CCS
[   20.620000] hda: dma_intr: status=0x51 { DriveReady SeekComplete Error }
[   20.620000] hda: dma_intr: error=0x84 { DriveStatusError BadCRC }
[   20.620000] ide: failed opcode was: unknown
[   23.132000] PM: Writing back config space on device 0000:03:09.1 at offset b (was 164814e4, writing 164414e4)
[   23.132000] PM: Writing back config space on device 0000:03:09.1 at offset 3 (was 804000, writing 804010)
[   23.132000] PM: Writing back config space on device 0000:03:09.1 at offset 2 (was 2000000, writing 2000003)
[   23.132000] PM: Writing back config space on device 0000:03:09.1 at offset 1 (was 2b00000, writing 2b00006)
[   23.252000] PM: Writing back config space on device 0000:03:09.0 at offset b (was 164814e4, writing 164414e4)
[   23.252000] PM: Writing back config space on device 0000:03:09.0 at offset 3 (was 804000, writing 804010)
[   23.252000] PM: Writing back config space on device 0000:03:09.0 at offset 2 (was 2000000, writing 2000003)
[   23.252000] PM: Writing back config space on device 0000:03:09.0 at offset 1 (was 2b00000, writing 2b00006)
[   24.020000] AMD768 RNG detected
[   24.136000] pci_hotplug: PCI Hot Plug PCI Core version: 0.5
[   24.148000] shpchp: Unknown symbol acpi_run_oshp
[   24.148000] shpchp: Unknown symbol pci_hp_change_slot_info
[   24.148000] shpchp: Unknown symbol pci_hp_register
[   24.148000] shpchp: Unknown symbol pci_hp_deregister
[   24.148000] shpchp: Unknown symbol acpi_get_hp_params_from_firmware
[   24.152000] shpchp: Unknown symbol acpi_run_oshp
[   24.152000] shpchp: Unknown symbol pci_hp_change_slot_info
[   24.152000] shpchp: Unknown symbol pci_hp_register
[   24.152000] shpchp: Unknown symbol pci_hp_deregister
[   24.152000] shpchp: Unknown symbol acpi_get_hp_params_from_firmware
[   24.152000] shpchp: HPC vendor_id 1022 device_id 7460 ss_vid 0 ss_did 0
[   24.152000] shpchp: shpc_init: cannot reserve MMIO region
[   24.156000] shpchp: HPC vendor_id 1022 device_id 7450 ss_vid 0 ss_did 0
[   24.156000] shpchp: shpc_init: cannot reserve MMIO region
[   24.160000] shpchp: HPC vendor_id 1022 device_id 7450 ss_vid 0 ss_did 0
[   24.160000] shpchp: shpc_init: cannot reserve MMIO region
[   24.164000] shpchp: Standard Hot Plug PCI Controller Driver version: 0.4
[   24.444000] NET: Registered protocol family 17
[   24.908000] sd 0:0:0:0: Attached scsi removable disk sda
[   24.920000] sd 0:0:0:0: Attached scsi generic sg0 type 0
[   25.056000] fuse init (API version 7.8)
[   25.116000] lp: driver loaded but no devices found
[   25.144000] Adding 859436k swap on /dev/disk/by-uuid/de4789bd-6c3e-4035-8587-c3d7d86e9c49.  Priority:-1 extents:1 across:859436k
[   25.280000] EXT3 FS on hda1, internal journal
[   29.492000] powernow_k8: Unknown symbol acpi_processor_notify_smm
[   29.492000] powernow_k8: Unknown symbol acpi_processor_unregister_performance
[   29.492000] powernow_k8: Unknown symbol acpi_processor_register_performance
[   29.536000] acpi_cpufreq: Unknown symbol acpi_processor_notify_smm
[   29.536000] acpi_cpufreq: Unknown symbol acpi_processor_unregister_performance
[   29.536000] acpi_cpufreq: Unknown symbol acpi_processor_preregister_performance
[   29.536000] acpi_cpufreq: Unknown symbol acpi_processor_register_performance
[   32.792000] ppdev: user-space parallel port driver
[   33.580000] apm: BIOS not found.
[   33.736000] Bluetooth: Core ver 2.11
[   33.736000] NET: Registered protocol family 31
[   33.736000] Bluetooth: HCI device and connection manager initialized
[   33.736000] Bluetooth: HCI socket layer initialized
[   33.772000] Bluetooth: L2CAP ver 2.8
[   33.772000] Bluetooth: L2CAP socket layer initialized
[   33.828000] Bluetooth: RFCOMM socket layer initialized
[   33.828000] Bluetooth: RFCOMM TTY layer initialized
[   33.828000] Bluetooth: RFCOMM ver 1.8
[   66.780000] NET: Registered protocol family 10
[   66.780000] lo: Disabled Privacy Extensions
[   66.780000] ADDRCONF(NETDEV_UP): eth0: link is not ready
[   66.780000] ADDRCONF(NETDEV_UP): eth1: link is not ready

lspci
====
00:18.0 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] HyperTransport Technology Configuration
00:18.1 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] Address Map
00:18.2 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] DRAM Controller
00:18.3 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] Miscellaneous Control
01:06.0 PCI bridge: Advanced Micro Devices [AMD] AMD-8111 PCI (rev 07)
01:07.0 ISA bridge: Advanced Micro Devices [AMD] AMD-8111 LPC (rev 05)
01:07.1 IDE interface: Advanced Micro Devices [AMD] AMD-8111 IDE (rev 03)
01:07.2 SMBus: Advanced Micro Devices [AMD] AMD-8111 SMBus 2.0 (rev 02)
01:07.3 Bridge: Advanced Micro Devices [AMD] AMD-8111 ACPI (rev 05)
01:0a.0 PCI bridge: Advanced Micro Devices [AMD] AMD-8131 PCI-X Bridge (rev 12)
01:0a.1 PIC: Advanced Micro Devices [AMD] AMD-8131 PCI-X IOAPIC (rev 01)
01:0b.0 PCI bridge: Advanced Micro Devices [AMD] AMD-8131 PCI-X Bridge (rev 12)
01:0b.1 PIC: Advanced Micro Devices [AMD] AMD-8131 PCI-X IOAPIC (rev 01)
02:00.0 USB Controller: Advanced Micro Devices [AMD] AMD-8111 USB (rev 0b)
02:00.1 USB Controller: Advanced Micro Devices [AMD] AMD-8111 USB (rev 0b)
02:06.0 VGA compatible controller: ATI Technologies Inc Rage XL (rev 27)
03:09.0 Ethernet controller: Broadcom Corporation NetXtreme BCM5704 Gigabit Ethernet (rev 03)
03:09.1 Ethernet controller: Broadcom Corporation NetXtreme BCM5704 Gigabit Ethernet (rev 03)


       
---------------------------------
Be a better Globetrotter. Get better travel answers from someone who knows.
Yahoo! Answers - Check it out.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20071006/cd265c64/attachment.html>

From bishop.robinson at gmail.com  Sat Oct  6 22:56:29 2007
From: bishop.robinson at gmail.com (Robinson Tryon)
Date: Sat, 6 Oct 2007 16:56:29 -0400
Subject: [LinuxBIOS] superiotool - dump support for LPC47B27X
Message-ID: <a698c16a0710061356s78de5406t340f302e42dc7a29@mail.gmail.com>

Signed-off-by: Robinson P.Tryon <bishop.robinson at gmail.com>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: lpc47b27x.patch
Type: text/x-diff
Size: 1279 bytes
Desc: not available
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20071006/d2ac709f/attachment.bin>

From lemenkov at gmail.com  Sat Oct  6 22:59:14 2007
From: lemenkov at gmail.com (Peter Lemenkov)
Date: Sun, 7 Oct 2007 00:59:14 +0400
Subject: [LinuxBIOS] Adding support for At29C010A
Message-ID: <adf480660710061359j5bacd5cale42985db1e2a5a6e@mail.gmail.com>

Hello All!
After a quick look through the specs for At29C020 and At29C040A I
realized that all these chips looks identical. The only difference is
page size - 128 bytes at At29C010A and 256 bytes at 020 and 040
models.

So am I right then suggests that for enabling At20C010A chip I need
only add few lines -

         {"At29C010A",    ATMEL_ID,       AT_29C010A,     128, 128,
         probe_jedec,   erase_chip_jedec, write_jedec},

into flashchips.h and only one #define into flash.c?
I don't exactly understand how to find device ID - looks like I need a
small advice :)

-- 
With best regards!



From lemenkov at gmail.com  Sat Oct  6 23:01:44 2007
From: lemenkov at gmail.com (Peter Lemenkov)
Date: Sun, 7 Oct 2007 01:01:44 +0400
Subject: [LinuxBIOS] Adding support for At29C010A
In-Reply-To: <adf480660710061359j5bacd5cale42985db1e2a5a6e@mail.gmail.com>
References: <adf480660710061359j5bacd5cale42985db1e2a5a6e@mail.gmail.com>
Message-ID: <adf480660710061401r27757b08v41c221a8ad4fb98e@mail.gmail.com>

2007/10/7, Peter Lemenkov <lemenkov at gmail.com>:
> Hello All!
> After a quick look through the specs for At29C020 and At29C040A I
> realized that all these chips looks identical. The only difference is
> page size - 128 bytes at At29C010A and 256 bytes at 020 and 040
> models.
>
> So am I right then suggests that for enabling At20C010A chip I need
> only add few lines -
>
>          {"At29C010A",    ATMEL_ID,       AT_29C010A,     128, 128,
>          probe_jedec,   erase_chip_jedec, write_jedec},
>
> into flashchips.h and only one #define into flash.c?
> I don't exactly understand how to find device ID - looks like I need a
> small advice :)

Small note - I speak aboun flashrom.
-- 
With best regards!



From ward at gnu.org  Sat Oct  6 23:13:13 2007
From: ward at gnu.org (Ward Vandewege)
Date: Sat, 6 Oct 2007 17:13:13 -0400
Subject: [LinuxBIOS] Tyan s2881+opteron +ubuntu+LBv2 => no GUI
In-Reply-To: <33077.18923.qm@web51602.mail.re2.yahoo.com>
References: <mailman.812.1191681399.4548.linuxbios@linuxbios.org>
	<33077.18923.qm@web51602.mail.re2.yahoo.com>
Message-ID: <20071006211313.GA31129@localdomain>

On Sat, Oct 06, 2007 at 01:37:59PM -0700, Baski wrote:
> I got the latest version of LB2 as of today and followed the s2881 Built
> tutorial.
> I extracted the VGA bios from latest AMI bios (v208)  using cbrom under 
> Win-XP.
> 
> Ubuntu boots into Text mode, but fails trying to launch the GUI.

Can you describe more in detail what happens? Error messages? What happens 
when you try running startx from the command line? What's in the X log file?

Thanks,
Ward.

-- 
Ward Vandewege <ward at fsf.org>
Free Software Foundation - Senior System Administrator



From joe at smittys.pointclark.net  Sat Oct  6 23:45:08 2007
From: joe at smittys.pointclark.net (joe at smittys.pointclark.net)
Date: Sat, 06 Oct 2007 17:45:08 -0400
Subject: [LinuxBIOS] Problems with Filo booting - HELP
In-Reply-To: <20071006103900.9ogqdjwn4088ow4s@www.smittys.pointclark.net>
References: <20070929165103.pcm220bn4s48sow8@smittys.pointclark.net>
	<20070929205527.GA16584@coresystems.de>
	<20070929170245.ata0hgegqowgcwgs@www.smittys.pointclark.net>
	<20070929201342.mifqbujb44ocwks8@smittys.pointclark.net>
	<46FF1CB2.60901@gmail.com>
	<20070930115720.mwni4u7go4wkk8wg@www.smittys.pointclark.net>
	<47000290.6020000@gmail.com>
	<20071001094827.loois4qr0g4ckw8o@www.smittys.pointclark.net>
	<13426df10710010950s379f8230y5b4ffec4da605f06@mail.gmail.com>
	<20071001165858.vlz66uxpusgk0gww@www.smittys.pointclark.net>
	<47017223.6010504@gmail.com>
	<20071003190457.a6hta1e4kk8w0wwc@www.smittys.pointclark.net>
	<4704630C.8060803@gmail.com>
	<20071004002639.o29oeiku4g84w4g8@www.smittys.pointclark.net>
	<47048488.5060508@gmail.com>
	<20071004125949.u3xlwo9bjwgocc48@www.smittys.pointclark.net>
	<20071006103900.9ogqdjwn4088ow4s@www.smittys.pointclark.net>
Message-ID: <20071006174508.owh2ehwr8cgckws8@smittys.pointclark.net>


> Corey, After scatching my head for days (hair thinning even more) I
> think you may be onto something. I have tried changing the values in
> APBASE before with no luck and I think this is why:
>
> 1. APSIZE Bits[5:3] need to be set first to 111 too allow APBASE
> Bits[27:25] to become R/W.
This register sets ok
>
> 2. Now we can set APBASE Bits[27:25] to 111 for 32MB Aperture.
Nope not able to write to this register. Why??
>
> 3. I noticed this in my bootlogs:
>
> ? ? ?PCI: 00:00.0 register 10(00000008), read-only ignoring it
>
> ? ? ?Which is the APBASE register. I think LB is tring to configure an
> address range for it but not able to because the address range is set
> to read only.
Boot log still says this:-(
>
> 4. Set register GCC0 Bit 9 to 1. This enables access to the Aperture
> allowing LB to configure an address range.
Not able to set this bit eithor.
>
> I wish there was a way to just disable the Aperture all togethor for
> now but the i82830 is not designed to run in headless mode (no
> graphics). I will try this out and report back.
>
I don't know where to go from here..

Thanks - Joe

Northbridge following SDRAM init:
PCI: 00:00.00
00: 86 80 75 35 06 00 10 00 04 00 00 06 00 00 00 00
10: 08 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
20: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
30: 00 00 00 00 40 00 00 00 00 00 00 00 00 00 00 00
40: 09 00 05 01 00 00 00 00 00 00 00 00 02 28 00 0e
50: 72 A0 20 00 00 00 00 00 00 30 33 33 33 33 33 33
60: 00 00 04 04 00 00 00 00 00 00 00 00 00 00 00 00
70: ff f1 ff ff 00 00 00 00 10 00 00 00 70 02 00 20
80: 00 00 00 00 00 00 00 00 00 d0 00 40 00 00 00 00
90: 02 38 00 00 00 00 00 00 00 00 00 00 00 00 00 00
a0: 02 00 20 00 17 02 00 1f 00 00 00 00 00 00 00 00
b0: 00 00 00 00 38 00 00 00 00 00 00 00 00 00 00 00
c0: 00 54 0e 41 a2 99 01 00 c0 00 00 00 00 00 00 00
d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
e0: 00 00 00 00 00 00 00 00 00 00 00 00 09 c9 9f fc
f0: 11 11 01 00 00 00 0b 05 34 d6 30 cf 22 cf 23 cf
Testing DRAM : 00100000-00200000
DRAM fill: 00100000-00200000
00100000
00110000
00120000
00130000
00140000
00150000
00160000
00170000
00180000
00190000
001a0000
001b0000
001c0000
001d0000
001e0000
001f0000
00200000
DRAM filled
DRAM verify: 00100000-00200000
00100000
Fail: @0x00100000 Read value=0xffffffff
..................
Fail: @0x00100400 Read value=0xffffffff
Aborting.

00100400
DRAM did _NOT_ verify!
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20071006/70b004a6/attachment.html>

From uwe at hermann-uwe.de  Sun Oct  7 00:05:05 2007
From: uwe at hermann-uwe.de (Uwe Hermann)
Date: Sun, 7 Oct 2007 00:05:05 +0200
Subject: [LinuxBIOS] superiotool - dump support for fdc37b72x
In-Reply-To: <a698c16a0710060950y72193613l8c9482eace0d3b63@mail.gmail.com>
References: <a698c16a0710060900t73032585j7716f046ad05ba42@mail.gmail.com>
	<a698c16a0710060950y72193613l8c9482eace0d3b63@mail.gmail.com>
Message-ID: <20071006220505.GB6227@greenwood>

On Sat, Oct 06, 2007 at 12:50:52PM -0400, Robinson Tryon wrote:
> Comparing the specs for the FDC37B78x and the FDC37B72x you can see
> that there's a whole lot of duplication in the dump table.  At first
> glance, the global config (apart from the chip ID), the floppy,
> parallel port, and serial ports have exactly the same register layout
> for both chip families.
> 
> Is there some way that we can factor out these common data?

No, I don't think that's practicable.

While refactoring code is a good thing in general, this is just a bunch
of numbers and I don't see a way to sensibly factor this out.


Uwe.
-- 
http://www.hermann-uwe.de  | http://www.holsham-traders.de
http://www.crazy-hacks.org | http://www.unmaintained-free-software.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20071007/54fbb35a/attachment.sig>

From uwe at hermann-uwe.de  Sun Oct  7 00:27:20 2007
From: uwe at hermann-uwe.de (Uwe Hermann)
Date: Sun, 7 Oct 2007 00:27:20 +0200
Subject: [LinuxBIOS] [PATCH] superiotool: Make --version actually
	work	correctly
In-Reply-To: <4707CB92.6070305@gmail.com>
References: <20071005174628.GA9851@greenwood> <4706B412.7080408@gmx.net>
	<20071005223006.GF7148@greenwood> <4707C902.40400@gmail.com>
	<4707CB92.6070305@gmail.com>
Message-ID: <20071006222720.GC6227@greenwood>

On Sat, Oct 06, 2007 at 01:53:22PM -0400, Corey Osgood wrote:
> >>> BTW, the $Rev$ output format is ugly beyond words.
> >>>     
> >>>       
> >> Full ack.
> >>
> >> That's why it has to be mangled quite a bit before usage. However, the
> >> final output looks ok IMO:
> >>
> >> $ ./superiotool -v
> >> superiotool r2821


> > Not here it doesn't:
> >
> > amp at hp:~/linuxbios/lb_clean/LinuxBIOSv2/util/superiotool$ ./superiotool -v
> > superiotool r2821?z??
> > amp at hp:~/linuxbios/lb_clean/LinuxBIOSv2/util/superiotool$ ./superiotool -v
> > superiotool r2821????
> > amp at hp:~/linuxbios/lb_clean/LinuxBIOSv2/util/superiotool$ ./superiotool -v
> > superiotool r2821??
> > amp at hp:~/linuxbios/lb_clean/LinuxBIOSv2/util/superiotool$ ./superiotool -v
> > superiotool r2821????
> > amp at hp:~/linuxbios/lb_clean/LinuxBIOSv2/util/superiotool$ ./superiotool -v
> > superiotool r2821?*??
> > amp at hp:~/linuxbios/lb_clean/LinuxBIOSv2/util/superiotool$ ./superiotool -v
> > superiotool r2821?
> > amp at hp:~/linuxbios/lb_clean/LinuxBIOSv2/util/superiotool$ ./superiotool -v
> > superiotool r2821?:??

Hm, is that random junk at the end of the version? In that case there's
a bug somewhere in my code. Should be fixable, though.


> Also just noticed it doesn't work:
> 
> amp at hp:~/linuxbios/lb_clean/LinuxBIOSv2/util/superiotool$ ./superiotool -v
> superiotool r2821?:
> amp at hp:~/linuxbios/lb_clean/LinuxBIOSv2/util/superiotool$ svn info
> Path: .
> URL: svn://linuxbios.org/repos/trunk/util/superiotool
> Repository Root: svn://linuxbios.org/repos
> Repository UUID: 2b7e53f0-3cfb-0310-b3e9-8179ed1497e1
> Revision: 2828
> Node Kind: directory
> Schedule: normal
> Last Changed Author: uwe
> Last Changed Rev: 2828
> Last Changed Date: 2007-10-05 17:58:03 -0400 (Fri, 05 Oct 2007)

That's expected, it won't work until you commit (and do

  $ svn ps svn:keywords "Author Date Id Rev URL" *.[ch]

before committing). That's contained in the patch, but the svn
properties are not applied when you simply use 'patch' to apply
the patch...


Uwe.
-- 
http://www.hermann-uwe.de  | http://www.holsham-traders.de
http://www.crazy-hacks.org | http://www.unmaintained-free-software.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20071007/a5d5c02a/attachment.sig>

From david.hendricks at gmail.com  Sun Oct  7 04:09:40 2007
From: david.hendricks at gmail.com (David Hendricks)
Date: Sat, 6 Oct 2007 19:09:40 -0700
Subject: [LinuxBIOS] superiotool patch for W83627THF/THG
Message-ID: <a2496e180710061909x5d9c5acbna9ad7404be9c2218@mail.gmail.com>

Hello everyone,
    Ron, Stefan and I were kicking the shit and came up with this small
patch for superiotool. Adds support for a Winbond device where there was
once only a stub. Enjoy!

Signed-off-by: David Hendricks <david.hendricks at gmail.com>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20071006/7a58bf63/attachment.html>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: superiotool.diff
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20071006/7a58bf63/attachment.ksh>

From david.hendricks at gmail.com  Sun Oct  7 04:15:13 2007
From: david.hendricks at gmail.com (David Hendricks)
Date: Sat, 6 Oct 2007 19:15:13 -0700
Subject: [LinuxBIOS] [PATCH] Flashrom -- Add W83627THF and K8N-Neo3 support
Message-ID: <a2496e180710061915j145f13d0p36d2b02092ff4ae9@mail.gmail.com>

Hello again everyone,
    Another patch we hacked up today to get flashrom working on the MSI
K8N-Neo3 board. Let us know what you think!

Signed-off-by: David Hendricks <david.hendricks at gmail.com>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20071006/2e3d8296/attachment.html>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: flashrom.diff
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20071006/2e3d8296/attachment.ksh>

From bishop.robinson at gmail.com  Sun Oct  7 04:26:16 2007
From: bishop.robinson at gmail.com (Robinson Tryon)
Date: Sat, 6 Oct 2007 22:26:16 -0400
Subject: [LinuxBIOS] superiotool - dump support for LPC47M112
Message-ID: <a698c16a0710061926j630a66f7maadc57d891047eb1@mail.gmail.com>

Signed-off-by: Robinson P. Tryon <bishop.robinson at gmail.com>

This chip shares the same id as the LPC47M10x line, and from
comparison, appears to have the same set of registers.

In general, can I assume that two chips with the same id number will
have the exact same register layout?

Also, what are "Ultra I/Os", and should superiotool support dumps from 'em?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: lpc47m112.patch
Type: text/x-diff
Size: 376 bytes
Desc: not available
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20071006/1921fbe2/attachment.bin>

From bishop.robinson at gmail.com  Sun Oct  7 04:46:44 2007
From: bishop.robinson at gmail.com (Robinson Tryon)
Date: Sat, 6 Oct 2007 22:46:44 -0400
Subject: [LinuxBIOS] Call for help: superiotool
In-Reply-To: <20070923111315.GC12926@greenwood>
References: <20070923111315.GC12926@greenwood>
Message-ID: <a698c16a0710061946h1dc1eb90g4535a740d9b082e3@mail.gmail.com>

Question about registers:

In the datasheet for the FDC37M81x, registers 0x62,0x63 of COM2 have
values marked for their hard reset (0x00,0x00).  In the 'Configuration
Register' column, there is a note that these two registers are
'Reserved'.

So, in this type of case should I mark the two registers with their
given value, 0x00, or should I use RSVD?

What if the registers were marked with a dash (-) ?  Usually I would
mark that as NANA, but if it's marked as reserved I assume I should
use RSVD instead.

Oh -- and what about the chip rev?  Usually there's no given value
(because it would change with each chip), so I would mark it MISC, but
I believe I saw that other people had marked the chip rev register as
NANA.  Which is preferable, and why?


Thanks!
--Robinson



From stepan at coresystems.de  Sun Oct  7 04:52:35 2007
From: stepan at coresystems.de (Stefan Reinauer)
Date: Sun, 7 Oct 2007 04:52:35 +0200
Subject: [LinuxBIOS] initram / xip issue
Message-ID: <20071007025235.GA13102@coresystems.de>

Ok, here's my latest patch that makes initram callbacks to stage0 work
in v3. It's not all that pretty, but it is the least ugly thing I could
find.

Stefan

-- 
coresystems GmbH ? Brahmsstr. 16 ? D-79104 Freiburg i. Br.
      Tel.: +49 761 7668825 ? Fax: +49 761 7664613
Email: info at coresystems.de  ? http://www.coresystems.de/
Registergericht: Amtsgericht Freiburg ? HRB 7656
Gesch?ftsf?hrer: Stefan Reinauer ? Ust-IdNr.: DE245674866
-------------- next part --------------
A non-text attachment was scrubbed...
Name: solve-XIP-issue.diff
Type: text/x-patch
Size: 7423 bytes
Desc: not available
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20071007/acf3ce6e/attachment.diff>

From corey.osgood at gmail.com  Sun Oct  7 05:01:29 2007
From: corey.osgood at gmail.com (Corey Osgood)
Date: Sat, 06 Oct 2007 23:01:29 -0400
Subject: [LinuxBIOS] [PATCH] superiotool: Make --version actually work
 correctly
In-Reply-To: <20071006222720.GC6227@greenwood>
References: <20071005174628.GA9851@greenwood> <4706B412.7080408@gmx.net>
	<20071005223006.GF7148@greenwood> <4707C902.40400@gmail.com>
	<4707CB92.6070305@gmail.com> <20071006222720.GC6227@greenwood>
Message-ID: <47084C09.2080906@gmail.com>

Uwe Hermann wrote
> That's expected, it won't work until you commit (and do
>
>   $ svn ps svn:keywords "Author Date Id Rev URL" *.[ch]
>
> before committing). That's contained in the patch, but the svn
> properties are not applied when you simply use 'patch' to apply
> the patch...
>
>
> Uwe.
>   

Oops, my bad. I thought the patch had already been applied to the tree.
Excuse my ignorance, sorry.

On another note, can we print something when superiotool is run without
any parameters and fails to find any Super IO?

-Corey



From bishop.robinson at gmail.com  Sun Oct  7 06:05:16 2007
From: bishop.robinson at gmail.com (Robinson Tryon)
Date: Sun, 7 Oct 2007 00:05:16 -0400
Subject: [LinuxBIOS] superiotool - dump support for FDC37M81x
Message-ID: <a698c16a0710062105h5bff055btc2fcb4d505a37a49@mail.gmail.com>

Signed-off-by: Robinson P. Tryon <bishop.robinson at gmail.com>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: fdc37m81x.patch
Type: text/x-diff
Size: 1275 bytes
Desc: not available
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20071007/809ee83d/attachment.bin>

From okajima at digitalinfra.co.jp  Sun Oct  7 06:08:06 2007
From: okajima at digitalinfra.co.jp (Jun OKAJIMA)
Date: Sun, 07 Oct 2007 13:08:06 +0900
Subject: [LinuxBIOS] MACH BOOT
In-Reply-To: <37367b3a0710060731r2e284b46m794e5ac3d7bc0ef0@mail.gmail.com>
References: <37367b3a0710060731r2e284b46m794e5ac3d7bc0ef0@mail.gmail.com>
Message-ID: <200710070408.AA02658@bbb-jz5c7z9hn9y.digitalinfra.co.jp>

>
>2007/10/6, Jun OKAJIMA <okajima at digitalinfra.co.jp>:
>>
>> Maybe you already know this?
>>
>> MACH BOOT is a very fast CD booting Linux.
>> It boots Linux desktop in less than 10 sec from CD.
>>
>> Check it out please.
>> http://www.machboot.com/
>>
>It is fantastic, very good results.
>
>> Then, why I mail here?
>>
>> The current issue for making boot faster is, not a Linux issue
>> but BIOS issue. Linux can boot less than 10 sec, but BIOS
>> uses more than 20 sec!.
>>
>> ANY HELP?. Of course, using Linux BIOS is one choice.
>>
>
>I think using LinuxBIOS is the best choice. Using LinuxBIOS and Linux
>with graphical aplications (kdrive and matchbox) built in inside BIOS
>Flash I got < 10s startup (with no optimizations). You just need get a
>supported board
>(http://www.linuxbios.org/index.php/Supported_Motherboards) and make a
>try.
>
>

I checked the video. It looks great. Good work.
But, your way limits functionality. You can use only Tiny/X and busybox and...
If you use Firefox, using CD-ROM is necessary, right?

So, combining your way and my way would be a right choice.

And, the problem is not only BIOS, but a firm ware of CD-ROM also.
In some drives, to recognize a medium and start reading requies more than 10 sec.
I mean, to start reading uses more time than booting Linux itself.
To solve this, probably so-called "LinuxFirmware" would be necessary...

I need ATAPI commands like these.
SET_MEDIA( media_type="CD-R", media_format="SINGLE_SESSION" )
START_SPIN( speed="MAX", wait=0)
If you can send these commands in the early stage of BIOS booting,
it gets more faster to start reading a medium.

        --- Okajima, Jun. Tokyo, Japan.
            http://www.machboot.com/








From kbaski at yahoo.com  Sun Oct  7 07:10:13 2007
From: kbaski at yahoo.com (Baski)
Date: Sat, 6 Oct 2007 22:10:13 -0700 (PDT)
Subject: [LinuxBIOS] Tyan s2881+opteron +ubuntu+LBv2 => no GUI
In-Reply-To: <mailman.824.1191722990.4548.linuxbios@linuxbios.org>
Message-ID: <844518.43384.qm@web51601.mail.re2.yahoo.com>

4. Re: Tyan s2881+opteron +ubuntu+LBv2 => no GUI (Ward Vandewege)
On Sat, Oct 06, 2007 at 01:37:59PM -0700, Baski wrote:
> I got the latest version of LB2 as of today and followed the s2881 Built
> tutorial.
> I extracted the VGA bios from latest AMI bios (v208)  using cbrom under 
> Win-XP.
> 
> Ubuntu boots into Text mode, but fails trying to launch the GUI.

Can you describe more in detail what happens? Error messages? What happens 
when you try running startx from the command line? What's in the X log file?

Thanks,
Ward.

Hi,
1st thing.  My system always executes Fallback image
"LinuxBIOS-2.0.0_s2881_Fallback Sat Oct  6 13:41:10 CDT 2007 booting..."

Ubuntu seems to start gnome.  I'm not getting the gnome desktop.  I see that gnome-session is already running, but can't run any graphic apps.  It says "NO DEVICE" .  
I tried to run 'startx' from the shell and again I got "No Devices detected".  Here is the log of X failure.
===

X Window System Version 7.2.0
Release Date: 22 January 2007
X Protocol Version 11, Revision 0, Release 7.2
Build Operating System: Linux Ubuntu
Current Operating System: Linux Bharathi 2.6.20-16-generic #2 SMP Sun Sep 23 19:50:39 UTC 2007 i686
Build Date: 04 April 2007
    Before reporting problems, check http://wiki.x.org
    to make sure that you have the latest version.
Module Loader present
Markers: (--) probed, (**) from config file, (==) default setting,
    (++) from command line, (!!) notice, (II) informational,
    (WW) warning, (EE) error, (NI) not implemented, (??) unknown.
(==) Log file: "/var/log/Xorg.0.log", Time: Sat Oct  6 22:24:49 2007
(==) Using config file: "/etc/X11/xorg.conf"
(==) ServerLayout "Default Layout"
(**) |-->Screen "Default Screen" (0)
(**) |   |-->Monitor "DELL M782"
(**) |   |-->Device "ATI Technologies Inc Rage XL"
(**) |-->Input Device "Generic Keyboard"
(**) |-->Input Device "Configured Mouse"
(**) |-->Input Device "stylus"
(**) |-->Input Device "cursor"
(**) |-->Input Device "eraser"
(WW) The directory "/usr/share/fonts/X11/cyrillic" does not exist.
    Entry deleted from font path.
....
    X.Org Font Renderer : 0.5
(--) using VT number 7

(II) PCI: End of PCI scan
(II) Host-to-PCI bridge:
(II) Bus 0: bridge is at (0:24:0), (0,0,4), BCTRL: 0x0008 (VGA_EN is set)
(II) Bus 0 I/O range:
(II) Loading /usr/lib/xorg/modules//libi2c.so
(II) Module i2c: vendor="X.Org Foundation"
    compiled for 7.2.0, module version = 1.2.0
    ABI class: X.Org Video Driver, version 1.1
(II) LoadModule: "ddc"
(II) Loading /usr/lib/xorg/modules//libddc.so
(II) Module ddc: vendor="X.Org Foundation"
    compiled for 7.2.0, module version = 1.0.0
    ABI class: X.Org Video Driver, version 1.1
(II) LoadModule: "dri"
(II) Loading /usr/lib/xorg/modules/extensions//libdri.so
(II) Module dri: vendor="X.Org Foundation"
    compiled for 7.2.0, module version = 1.0.0
    ABI class: X.Org Server Extension, version 0.3
(II) Loading extension XFree86-DRI
(II) LoadModule: "extmod"
(II) Loading /usr/lib/xorg/modules/extensions//libextmod.so
(II) Module extmod: vendor="X.Org Foundation"
    compiled for 7.2.0, module version = 1.0.0
    Module class: X.Org Server Extension
    ABI class: X.Org Server Extension, version 0.3
(II) Loading extension SHAPE
(II) Loading extension MIT-SUNDRY-NONSTANDARD
(II) Loading extension BIG-REQUESTS
(II) Loading extension SYNC
(II) Loading extension MIT-SCREEN-SAVER
(II) Loading extension XC-MISC
(II) Loading extension XFree86-VidModeExtension
(II) Loading extension XFree86-Misc
(II) Loading extension XFree86-DGA
(II) Loading extension DPMS
(II) Loading extension TOG-CUP
(II) Loading extension Extended-Visual-Information
(II) Loading extension XVideo
(II) Loading extension XVideo-MotionCompensation
(II) Loading extension X-Resource
(II) LoadModule: "freetype"
(II) Loading /usr/lib/xorg/modules//fonts/libfreetype.so
(II) Module freetype: vendor="X.Org Foundation & the After X-TT Project"
    compiled for 7.2.0, module version = 2.1.0
    Module class: X.Org Font Renderer
    ABI class: X.Org Font Renderer, version 0.5
(II) Loading font FreeType
(II) LoadModule: "glx"
(II) Loading /usr/lib/xorg/modules/extensions//libglx.so
(II) Module glx: vendor="X.Org Foundation"
    compiled for 7.2.0, module version = 1.0.0
    ABI class: X.Org Server Extension, version 0.3
(==) AIGLX enabled
(II) Loading extension GLX
(II) LoadModule: "int10"
(II) Loading /usr/lib/xorg/modules//libint10.so
(II) Module int10: vendor="X.Org Foundation"
    compiled for 7.2.0, module version = 1.0.0
    ABI class: X.Org Video Driver, version 1.1
(II) LoadModule: "vbe"
(II) Loading /usr/lib/xorg/modules//libvbe.so
(II) Module vbe: vendor="X.Org Foundation"
    compiled for 7.2.0, module version = 1.1.0
    ABI class: X.Org Video Driver, version 1.1
(II) LoadModule: "ati"
(II) Loading /usr/lib/xorg/modules/drivers//ati_drv.so
(II) Module ati: vendor="X.Org Foundation"
    compiled for 7.2.0, module version = 6.6.3
    Module class: X.Org Video Driver
    ABI class: X.Org Video Driver, version 1.1
(II) LoadModule: "kbd"
(II) Loading /usr/lib/xorg/modules/input//kbd_drv.so
(II) Module kbd: vendor="X.Org Foundation"
    compiled for 7.2.0, module version = 1.1.0
    Module class: X.Org XInput Driver
    ABI class: X.Org XInput driver, version 0.7
(II) LoadModule: "mouse"
(II) Loading /usr/lib/xorg/modules/input//mouse_drv.so
(II) Module mouse: vendor="X.Org Foundation"
    compiled for 7.2.0, module version = 1.1.1
    Module class: X.Org XInput Driver
    ABI class: X.Org XInput driver, version 0.7
(II) LoadModule: "wacom"
(II) Loading /usr/lib/xorg/modules/input//wacom_drv.so
(II) Module wacom: vendor="X.Org Foundation"
    compiled for 4.3.99.902, module version = 1.0.0
    Module class: X.Org XInput Driver
    ABI class: X.Org XInput driver, version 0.7
(II) R128: Driver for ATI Rage 128 chipsets:

(II) Primary Device is: PCI 02:06:0
(II) ATI:  Candidate "Device" section "ATI Technologies Inc Rage XL".
(II) ATI:  Shared PCI/AGP Mach64 in slot 2:6:0 detected.
(EE) No devices detected.

Fatal server error:
no screens found
=====

       
---------------------------------
Boardwalk for $500? In 2007? Ha! 
Play Monopoly Here and Now (it's updated for today's economy) at Yahoo! Games.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20071006/06d59089/attachment.html>

From jordan at chalmers.se  Sun Oct  7 11:09:24 2007
From: jordan at chalmers.se (Ulf Jordan)
Date: Sun, 7 Oct 2007 11:09:24 +0200 (CEST)
Subject: [LinuxBIOS] [PATCH] superiotool: Make --version actually work
 correctly
In-Reply-To: <Pine.LNX.4.63.0710061947140.13569@elfpc10.elmagn.chalmers.se>
References: <20071005174628.GA9851@greenwood> <4706B412.7080408@gmx.net>
	<20071005223006.GF7148@greenwood> <20071005223730.GA23669@localdomain>
	<a698c16a0710060641t3d70604fj6f3268ed600f07ef@mail.gmail.com>
	<Pine.LNX.4.63.0710061613240.2573@elfpc10.elmagn.chalmers.se>
	<a698c16a0710060842r84a87e1h1610dae77fddf2ed@mail.gmail.com>
	<20071006172706.GB14760@coresystems.de>
	<Pine.LNX.4.63.0710061947140.13569@elfpc10.elmagn.chalmers.se>
Message-ID: <Pine.LNX.4.63.0710071011140.17155@elfpc10.elmagn.chalmers.se>

On Sat, 6 Oct 2007, Ulf Jordan wrote:

> svnversion -c might be better, but it doesn't recurse, and has an
> interesting output format in the general case (but sed will fix it!)

The issue of how to derive version numbers from svn revision information 
is indeed non-trivial, as shown by our discussion here and on other lists 
like the Subversion users' list.

To obtain a global revision number from a working copy there is a very 
good example in the svn FAQ (it's the only one in a red box, so I guess 
it's really frequently asked):

http://subversion.tigris.org/faq.html#version-value-in-source

However, I believe we don't want the superiotool version to increase just 
because there are other commits in the v2 tree, so the example needs 
adapting by adding -c to svnversion.


Attached is a patch that:

* derives the superiotool version number from the latest committed change 
to superiotool files (NOT the latest svn up of the superiotool directory)

* strips away extra information from svnversion, to arrive at a single 
version number like 2828 instead of 2814:2828M ("this build is made up of 
files with latest modification in rev 2814 to 2828 plus local 
modifications").

* does not recurse down into subdirectories or svn:externals (there are no 
such things in superiotool for the moment)

* does all the work in determining the version number at build time

* depends on GNU make features (although it could be rewritten more 
portably using a version.h file instead, like my previous patch)


This approach could easily be combined with a traditional version number 
from a #define in superiotool.h, as Robinson pointed out.

Corey: if you apply this patch to current svn superiotool, does the 
trailing garbage go away?


/ulf
-------------- next part --------------
Set the superiotool version number from svn at build time.

Signed-off-by: Ulf Jordan <jordan at chalmers.se>

Index: superiotool.c
===================================================================
--- superiotool.c	(revision 2828)
+++ superiotool.c	(working copy)
@@ -167,12 +167,7 @@
 
 static void print_version(void)
 {
-	char tmp[80];
-
-	strncpy((char *)&tmp,
-		(const char *)&SUPERIOTOOL_VERSION[6],
-		strlen(SUPERIOTOOL_VERSION) - 8);
-	printf("superiotool r%s\n", (char *)&tmp);
+	printf("superiotool r%s\n", SUPERIOTOOL_VERSION);
 }
 
 int main(int argc, char *argv[])
Index: superiotool.h
===================================================================
--- superiotool.h	(revision 2828)
+++ superiotool.h	(working copy)
@@ -29,8 +29,6 @@
 #include <getopt.h>
 #include <sys/io.h>
 
-#define SUPERIOTOOL_VERSION "$Rev$"
-
 #define USAGE "Usage: superiotool [-d] [-D] [-V] [-v] [-h]\n\n\
   -d | --dump            Dump Super I/O registers\n\
   -D | --dump-readable   Dump Super I/O registers in human-readable format\n\
Index: Makefile
===================================================================
--- Makefile	(revision 2828)
+++ Makefile	(working copy)
@@ -24,14 +24,19 @@
 INSTALL = /usr/bin/install
 PREFIX  = /usr/local
 
+SVNDEF := -D'SUPERIOTOOL_VERSION="$(shell svnversion -cn . \
+          | sed -e "s/.*://" -e "s/\([0-9]*\).*/\1/")"'
+
 # TODO: -pedantic
 CFLAGS = -O2 -Wall -Werror -Wstrict-prototypes -Wundef -Wstrict-aliasing \
-         -Werror-implicit-function-declaration -ansi
+         -Werror-implicit-function-declaration -ansi $(SVNDEF)
 
 OBJS = superiotool.o ali.o fintek.o ite.o nsc.o smsc.o winbond.o
 
 all: $(PROGRAM)
 
+superiotool.o: *.c superiotool.h
+
 $(PROGRAM): $(OBJS) superiotool.h
 	$(CC) $(CFLAGS) -o $(PROGRAM) $(OBJS)
 

From peter at stuge.se  Sun Oct  7 12:25:35 2007
From: peter at stuge.se (Peter Stuge)
Date: Sun, 7 Oct 2007 12:25:35 +0200
Subject: [LinuxBIOS] superiotool - dump support for fdc37b78x
In-Reply-To: <a698c16a0710061016y3d29ab99u790e946ab6dbdc68@mail.gmail.com>
References: <a698c16a0710061016y3d29ab99u790e946ab6dbdc68@mail.gmail.com>
Message-ID: <20071007102535.4670.qmail@stuge.se>

On Sat, Oct 06, 2007 at 01:16:14PM -0400, Robinson Tryon wrote:
> Signed-off-by: Robinson P. Tryon <bishop.robinson at gmail.com>
> 
> (This patch builds on the b272x patch)

There was a very long line in it, otherwise looks fine.


//Peter



From peter at stuge.se  Sun Oct  7 12:35:30 2007
From: peter at stuge.se (Peter Stuge)
Date: Sun, 7 Oct 2007 12:35:30 +0200
Subject: [LinuxBIOS] System requirements for LinuxBIOS
In-Reply-To: <adf480660710061133u38206889u98ab9cb3212cf8b0@mail.gmail.com>
References: <adf480660710061133u38206889u98ab9cb3212cf8b0@mail.gmail.com>
Message-ID: <20071007103530.6212.qmail@stuge.se>

On Sat, Oct 06, 2007 at 10:33:07PM +0400, Peter Lemenkov wrote:
> I can't find minimal system requirements for running LinuxBIOS.

For v3 it's a CPU that can use cache as RAM. CAR is getting popular
in v2 as well for boards with complex RAM init code.


> Especially I interested in minimal size of flashrom because I've
> got one mainboard with AT29C010A - 1 Megabit 128K x 8 5-volt Only
> CMOS Flash Memory. Is it enough for placing LinuxBIOS there?

That mostly depends on the payload you want to use. The LB part of
the flash image is rarely more than 32kb.


//Peter



From peter at stuge.se  Sun Oct  7 12:42:47 2007
From: peter at stuge.se (Peter Stuge)
Date: Sun, 7 Oct 2007 12:42:47 +0200
Subject: [LinuxBIOS] VGA support for Geode GX1/CS5530, 2nd try
In-Reply-To: <200710062159.47434.juergen127@kreuzholzen.de>
References: <200710052129.54369.juergen127@kreuzholzen.de>
	<200710052243.37625.juergen127@kreuzholzen.de>
	<20071005215000.GC7148@greenwood>
	<200710062159.47434.juergen127@kreuzholzen.de>
Message-ID: <20071007104247.8009.qmail@stuge.se>

On Sat, Oct 06, 2007 at 09:59:46PM +0200, Juergen Beisert wrote:
> Patch is against LinuxBIOSv2, revision of 2007-10-06.
> 
> Signed-off-by: Juergen Beisert <juergen127 at kreuzholzen.de>

Acked-by: Peter Stuge <peter at stuge.se>



From peter at stuge.se  Sun Oct  7 12:43:51 2007
From: peter at stuge.se (Peter Stuge)
Date: Sun, 7 Oct 2007 12:43:51 +0200
Subject: [LinuxBIOS] [PATCH] Make GX1 video memory size configurable
In-Reply-To: <200710062212.37786.juergen127@kreuzholzen.de>
References: <200710062212.37786.juergen127@kreuzholzen.de>
Message-ID: <20071007104351.8373.qmail@stuge.se>

On Sat, Oct 06, 2007 at 10:12:37PM +0200, Juergen Beisert wrote:
> -		tomk -= FRAMEBUFFERK;
> +		tomk -= CONFIG_VIDEO_MB * 1024;

Does this option already exist? If so:

Acked-by: Peter Stuge <peter at stuge.se>



From peter at stuge.se  Sun Oct  7 12:46:05 2007
From: peter at stuge.se (Peter Stuge)
Date: Sun, 7 Oct 2007 12:46:05 +0200
Subject: [LinuxBIOS] superiotool - dump support for LPC47B27X
In-Reply-To: <a698c16a0710061356s78de5406t340f302e42dc7a29@mail.gmail.com>
References: <a698c16a0710061356s78de5406t340f302e42dc7a29@mail.gmail.com>
Message-ID: <20071007104605.8880.qmail@stuge.se>

On Sat, Oct 06, 2007 at 04:56:29PM -0400, Robinson Tryon wrote:
> Signed-off-by: Robinson P.Tryon <bishop.robinson at gmail.com>

Looks good, but haven't tested.

Acked-by: Peter Stuge <peter at stuge.se>



From peter at stuge.se  Sun Oct  7 12:48:05 2007
From: peter at stuge.se (Peter Stuge)
Date: Sun, 7 Oct 2007 12:48:05 +0200
Subject: [LinuxBIOS] Adding support for At29C010A
In-Reply-To: <adf480660710061359j5bacd5cale42985db1e2a5a6e@mail.gmail.com>
References: <adf480660710061359j5bacd5cale42985db1e2a5a6e@mail.gmail.com>
Message-ID: <20071007104805.9212.qmail@stuge.se>

On Sun, Oct 07, 2007 at 12:59:14AM +0400, Peter Lemenkov wrote:
> After a quick look through the specs for At29C020 and At29C040A I
> realized that all these chips looks identical. The only difference
> is page size - 128 bytes at At29C010A and 256 bytes at 020 and 040
> models.

Yes, that's pretty common for chips from the same family.


> So am I right then suggests that for enabling At20C010A chip I need
> only add few lines -
> 
>          {"At29C010A",    ATMEL_ID,       AT_29C010A,     128, 128,
>          probe_jedec,   erase_chip_jedec, write_jedec},
> 
> into flashchips.h and only one #define into flash.c?

Yup.


> I don't exactly understand how to find device ID - looks like I
> need a small advice :)

It should be mentioned in the chip data sheet. Look near the
programming algorithm. Programming requires enabling a special
command mode with some sequence of writes. Usually you can read the
ID bytes instead of starting to program after that sequence.


//Peter



From peter at stuge.se  Sun Oct  7 12:54:56 2007
From: peter at stuge.se (Peter Stuge)
Date: Sun, 7 Oct 2007 12:54:56 +0200
Subject: [LinuxBIOS] superiotool - dump support for fdc37b72x
In-Reply-To: <20071006220505.GB6227@greenwood>
References: <a698c16a0710060900t73032585j7716f046ad05ba42@mail.gmail.com>
	<a698c16a0710060950y72193613l8c9482eace0d3b63@mail.gmail.com>
	<20071006220505.GB6227@greenwood>
Message-ID: <20071007105456.10526.qmail@stuge.se>

On Sun, Oct 07, 2007 at 12:05:05AM +0200, Uwe Hermann wrote:
> > Is there some way that we can factor out these common data?
> 
> No, I don't think that's practicable.

Depends on how much values would be duplicate I think.


> While refactoring code is a good thing in general, this is just a
> bunch of numbers and I don't see a way to sensibly factor this out.

Easy, just split the current table into LDN data common for more than
one chip, and LDN data specific to each chip, then add code to create
the current table from that.


//Peter



From peter at stuge.se  Sun Oct  7 13:01:15 2007
From: peter at stuge.se (Peter Stuge)
Date: Sun, 7 Oct 2007 13:01:15 +0200
Subject: [LinuxBIOS] superiotool patch for W83627THF/THG
In-Reply-To: <a2496e180710061909x5d9c5acbna9ad7404be9c2218@mail.gmail.com>
References: <a2496e180710061909x5d9c5acbna9ad7404be9c2218@mail.gmail.com>
Message-ID: <20071007110115.11603.qmail@stuge.se>

On Sat, Oct 06, 2007 at 07:09:40PM -0700, David Hendricks wrote:
> Hello everyone,
>     Ron, Stefan and I were kicking the shit and came up with this small
> patch for superiotool. Adds support for a Winbond device where there was
> once only a stub. Enjoy!
> 
> Signed-off-by: David Hendricks <david.hendricks at gmail.com>

Acked-by: Peter Stuge <peter at stuge.se>



From peter at stuge.se  Sun Oct  7 13:02:10 2007
From: peter at stuge.se (Peter Stuge)
Date: Sun, 7 Oct 2007 13:02:10 +0200
Subject: [LinuxBIOS] superiotool - dump support for LPC47M112
In-Reply-To: <a698c16a0710061926j630a66f7maadc57d891047eb1@mail.gmail.com>
References: <a698c16a0710061926j630a66f7maadc57d891047eb1@mail.gmail.com>
Message-ID: <20071007110210.11774.qmail@stuge.se>

On Sat, Oct 06, 2007 at 10:26:16PM -0400, Robinson Tryon wrote:
> Signed-off-by: Robinson P. Tryon <bishop.robinson at gmail.com>

Acked-by: Peter Stuge <peter at stuge.se>

> In general, can I assume that two chips with the same id number
> will have the exact same register layout?

No, I don't think that is safe.


> Also, what are "Ultra I/Os", and should superiotool support dumps
> from 'em?

Sorry, no idea.


//Peter



From peter at stuge.se  Sun Oct  7 13:02:59 2007
From: peter at stuge.se (Peter Stuge)
Date: Sun, 7 Oct 2007 13:02:59 +0200
Subject: [LinuxBIOS] [PATCH] Call for help: superiotool
In-Reply-To: <20071006165031.GA6227@greenwood>
References: <20070923111315.GC12926@greenwood>
	<20071002152938.084fdaef.rasmus@wiman.org>
	<20071004022202.GA30344@greenwood>
	<20071005153243.aaa117a3.rasmus@wiman.org>
	<20071005153623.GD5376@greenwood>
	<20071005191502.7e08a759.rasmus@wiman.org>
	<20071005215921.GD7148@greenwood>
	<a698c16a0710051510q4cacd55apa07f1e037e4d02eb@mail.gmail.com>
	<20071006165031.GA6227@greenwood>
Message-ID: <20071007110259.11839.qmail@stuge.se>

On Sat, Oct 06, 2007 at 06:50:31PM +0200, Uwe Hermann wrote:
> However, we should still give proper credit to all contributors, so
> maybe we add a THANKS or AUTHORS file (or a section in the README
> file)?
> 
> Opinions?

AUTHORS is good, section in README is fine too.


//Peter



From peter at stuge.se  Sun Oct  7 13:04:32 2007
From: peter at stuge.se (Peter Stuge)
Date: Sun, 7 Oct 2007 13:04:32 +0200
Subject: [LinuxBIOS] superiotool - dump support for FDC37M81x
In-Reply-To: <a698c16a0710062105h5bff055btc2fcb4d505a37a49@mail.gmail.com>
References: <a698c16a0710062105h5bff055btc2fcb4d505a37a49@mail.gmail.com>
Message-ID: <20071007110432.12182.qmail@stuge.se>

On Sun, Oct 07, 2007 at 12:05:16AM -0400, Robinson Tryon wrote:
> Signed-off-by: Robinson P. Tryon <bishop.robinson at gmail.com>

Acked-by: Peter Stuge <peter at stuge.se>



From peter at stuge.se  Sun Oct  7 13:07:48 2007
From: peter at stuge.se (Peter Stuge)
Date: Sun, 7 Oct 2007 13:07:48 +0200
Subject: [LinuxBIOS] MACH BOOT
In-Reply-To: <200710070408.AA02658@bbb-jz5c7z9hn9y.digitalinfra.co.jp>
References: <37367b3a0710060731r2e284b46m794e5ac3d7bc0ef0@mail.gmail.com>
	<200710070408.AA02658@bbb-jz5c7z9hn9y.digitalinfra.co.jp>
Message-ID: <20071007110748.12682.qmail@stuge.se>

On Sun, Oct 07, 2007 at 01:08:06PM +0900, Jun OKAJIMA wrote:
> I need ATAPI commands like these.
> SET_MEDIA( media_type="CD-R", media_format="SINGLE_SESSION" )
> START_SPIN( speed="MAX", wait=0)
> If you can send these commands in the early stage of BIOS booting,
> it gets more faster to start reading a medium.

That could certainly be added (configurable) both to FILO and GRUB2.


//Peter



From lemenkov at gmail.com  Sun Oct  7 13:22:24 2007
From: lemenkov at gmail.com (Peter Lemenkov)
Date: Sun, 7 Oct 2007 15:22:24 +0400
Subject: [LinuxBIOS] Flashrom: support for At29C010A added.
Message-ID: <adf480660710070422t8c12c8dv2494b148e6c85d18@mail.gmail.com>

Hello All!
Very simple patch - easy to review. Unfortunately I still not tested
it on real hardware (due to lack of AT-power supply).

-- 
With best regards!
-------------- next part --------------
A non-text attachment was scrubbed...
Name: flashrom-at29c010a-enabled.diff
Type: application/octet-stream
Size: 851 bytes
Desc: not available
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20071007/23f38f9f/attachment.obj>

From juergen127 at kreuzholzen.de  Sun Oct  7 14:28:49 2007
From: juergen127 at kreuzholzen.de (Juergen Beisert)
Date: Sun, 7 Oct 2007 14:28:49 +0200
Subject: [LinuxBIOS] [PATCH] Make GX1 video memory size configurable
In-Reply-To: <20071007104351.8373.qmail@stuge.se>
References: <200710062212.37786.juergen127@kreuzholzen.de>
	<20071007104351.8373.qmail@stuge.se>
Message-ID: <200710071428.49765.juergen127@kreuzholzen.de>

On Sunday 07 October 2007 12:43, Peter Stuge wrote:
> On Sat, Oct 06, 2007 at 10:12:37PM +0200, Juergen Beisert wrote:
> > -		tomk -= FRAMEBUFFERK;
> > +		tomk -= CONFIG_VIDEO_MB * 1024;
>
> Does this option already exist? If so:

take a look into src/config/Options.lb, line 1013:

[...]
define CONFIG_VIDEO_MB
        default none
        export used
        comment "Integrated graphics with UMA has dynamic setup"
end
[...]

Or is this option to be used in a different way?

Juergen



From lemenkov at gmail.com  Sun Oct  7 14:52:43 2007
From: lemenkov at gmail.com (Peter Lemenkov)
Date: Sun, 7 Oct 2007 16:52:43 +0400
Subject: [LinuxBIOS] FYI Asus ships mainboard with Linux,
	Firefox & Skype sitting in flashrom :)
Message-ID: <adf480660710070552pe9e5ba8h2c134f2d50526498@mail.gmail.com>

Hello All!
Maybe somebody didn't see it yet?

http://www.phoronix.com/scan.php?page=article&item=869

They'd better use LinuxBIOS :)

-- 
With best regards!



From acassis at gmail.com  Sun Oct  7 15:17:01 2007
From: acassis at gmail.com (Alan Carvalho de Assis)
Date: Sun, 7 Oct 2007 10:17:01 -0300
Subject: [LinuxBIOS] MACH BOOT
In-Reply-To: <200710070408.AA02658@bbb-jz5c7z9hn9y.digitalinfra.co.jp>
References: <37367b3a0710060731r2e284b46m794e5ac3d7bc0ef0@mail.gmail.com>
	<200710070408.AA02658@bbb-jz5c7z9hn9y.digitalinfra.co.jp>
Message-ID: <37367b3a0710070617v857e74dx829ac3add0621e81@mail.gmail.com>

Hi Jun,

2007/10/7, Jun OKAJIMA <okajima at digitalinfra.co.jp>:
> I checked the video. It looks great. Good work.
> But, your way limits functionality. You can use only Tiny/X and busybox and...
> If you use Firefox, using CD-ROM is necessary, right?
>

Yes, this is a good approach. You can place the Linux kernel on the
BIOS and rootfs can still on the CDROM. I don't make tests but I think
read from BIOS Flash (LPC = ~16.7 MB/s) is more faster than read from
48X CDROM (48 x 150KB/s = ~ 7MB/s)

> So, combining your way and my way would be a right choice.
>

Yes, once we don't have BIOS flash more than 2MB then this combining
is the right choice.

> And, the problem is not only BIOS, but a firm ware of CD-ROM also.
> In some drives, to recognize a medium and start reading requies more than 10 sec.
> I mean, to start reading uses more time than booting Linux itself.
> To solve this, probably so-called "LinuxFirmware" would be necessary...
>
> I need ATAPI commands like these.
> SET_MEDIA( media_type="CD-R", media_format="SINGLE_SESSION" )
> START_SPIN( speed="MAX", wait=0)
> If you can send these commands in the early stage of BIOS booting,
> it gets more faster to start reading a medium.
>

Hmm, so this is the trick to get Linux booting in 10s :-)
You will get best results using LinuxBIOS.

>         --- Okajima, Jun. Tokyo, Japan.
>             http://www.machboot.com/
>

Cheers,

Alan



From jordan.crouse at amd.com  Sun Oct  7 15:39:31 2007
From: jordan.crouse at amd.com (Jordan Crouse)
Date: Sun, 7 Oct 2007 07:39:31 -0600
Subject: [LinuxBIOS] initram / xip issue
In-Reply-To: <20071007025235.GA13102@coresystems.de>
References: <20071007025235.GA13102@coresystems.de>
Message-ID: <20071007133931.GA13803@cosmic.amd.com>

On 07/10/07 04:52 +0200, Stefan Reinauer wrote:
> Ok, here's my latest patch that makes initram callbacks to stage0 work
> in v3. It's not all that pretty, but it is the least ugly thing I could
> find.
> 
> Stefan
> 
> -- 
> coresystems GmbH ? Brahmsstr. 16 ? D-79104 Freiburg i. Br.
>       Tel.: +49 761 7668825 ? Fax: +49 761 7664613
> Email: info at coresystems.de  ? http://www.coresystems.de/
> Registergericht: Amtsgericht Freiburg ? HRB 7656
> Gesch?ftsf?hrer: Stefan Reinauer ? Ust-IdNr.: DE245674866

> This patch against LinuxBIOSv3 enables calls from initram (freely located XIP
> code) to stage0 (fixed location code) by forcing gcc to create an absolute call
> instruction to stage0. 
> 
> Signed-off-by: Stefan Reinauer <stepan at coresystems.de>
> 
> Index: include/console.h
> ===================================================================
> --- include/console.h	(revision 503)
> +++ include/console.h	(working copy)
> @@ -46,7 +46,13 @@
>  };
>  
>  // 
> +#ifndef XIP

I really don't like the idea of singling out XIP segements.  I vote we
changed this to SHARED, and do this for all segments, regardless of where
they live.  The code impact should be minimal.

>  int printk(int msg_level, const char *fmt, ...) 
>  	__attribute__((format (printf, 2, 3)));
> +#else
> +int stage0printk(int msg_level, const char *fmt, ...) 
> +	__attribute__((format (printf, 2, 3)));
> +int (*printk)(int msg_level, const char *fmt, ...) = stage0printk;
> +#endif

There has got to be a way that we can turn this into a general
purpose macro to make it easy for developers to mark new functions
as shared without understanding whats happening above

> Index: arch/x86/ldscript.ld
> ===================================================================
> --- arch/x86/ldscript.ld	(revision 503)
> +++ arch/x86/ldscript.ld	(working copy)
> @@ -33,10 +33,13 @@
>  	.stage0_1 . : {
>  		_stage0_1 = .;
>  		*(.text);
> +		*(.text.*)
> +		*(.rodata)
> +		*(.rodata.*)
> +		*(.got)
> +		*(.got.*)

How much size does the GOT add?

Jordan
-- 
Jordan Crouse
Systems Software Development Engineer 
Advanced Micro Devices, Inc.





From uwe at hermann-uwe.de  Sun Oct  7 16:17:38 2007
From: uwe at hermann-uwe.de (Uwe Hermann)
Date: Sun, 7 Oct 2007 16:17:38 +0200
Subject: [LinuxBIOS] Tyan s2881+opteron +ubuntu+LBv2 => no GUI
In-Reply-To: <844518.43384.qm@web51601.mail.re2.yahoo.com>
References: <mailman.824.1191722990.4548.linuxbios@linuxbios.org>
	<844518.43384.qm@web51601.mail.re2.yahoo.com>
Message-ID: <20071007141738.GA12533@greenwood>

On Sat, Oct 06, 2007 at 10:10:13PM -0700, Baski wrote:
> 1st thing.  My system always executes Fallback image
> "LinuxBIOS-2.0.0_s2881_Fallback Sat Oct  6 13:41:10 CDT 2007 booting..."

That's ok and expected.

 
> Fatal server error:
> no screens found

Can you please post the full LinuxBIOS and Linux boot log? Also and
lspci -nnv and the contents of you xorg.conf.


Uwe.
-- 
http://www.hermann-uwe.de  | http://www.holsham-traders.de
http://www.crazy-hacks.org | http://www.unmaintained-free-software.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20071007/8bce62be/attachment.sig>

From uwe at hermann-uwe.de  Sun Oct  7 16:20:09 2007
From: uwe at hermann-uwe.de (Uwe Hermann)
Date: Sun, 7 Oct 2007 16:20:09 +0200
Subject: [LinuxBIOS] Flashrom: support for At29C010A added.
In-Reply-To: <adf480660710070422t8c12c8dv2494b148e6c85d18@mail.gmail.com>
References: <adf480660710070422t8c12c8dv2494b148e6c85d18@mail.gmail.com>
Message-ID: <20071007142009.GB12533@greenwood>

On Sun, Oct 07, 2007 at 03:22:24PM +0400, Peter Lemenkov wrote:
> Very simple patch - easy to review. Unfortunately I still not tested
> it on real hardware (due to lack of AT-power supply).

Looks good, but please report with a Signed-off-by, see
http://linuxbios.org/index.php/Development_Guidelines#Sign-off_Procedure

Can you test this soonish on hardware or can someone else on the list
test it?


Thanks, Uwe.
-- 
http://www.hermann-uwe.de  | http://www.holsham-traders.de
http://www.crazy-hacks.org | http://www.unmaintained-free-software.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20071007/151281e0/attachment.sig>

From lemenkov at gmail.com  Sun Oct  7 16:26:33 2007
From: lemenkov at gmail.com (Peter Lemenkov)
Date: Sun, 7 Oct 2007 18:26:33 +0400
Subject: [LinuxBIOS]  Flashrom: support for At29C010A added.
In-Reply-To: <adf480660710070725m631d08e9lace5b79f35d2779a@mail.gmail.com>
References: <adf480660710070422t8c12c8dv2494b148e6c85d18@mail.gmail.com>
	<20071007142009.GB12533@greenwood>
	<adf480660710070725m631d08e9lace5b79f35d2779a@mail.gmail.com>
Message-ID: <adf480660710070726g4ade1645g7074b90a74ea0e05@mail.gmail.com>

2007/10/7, Uwe Hermann <uwe at hermann-uwe.de>:
> On Sun, Oct 07, 2007 at 03:22:24PM +0400, Peter Lemenkov wrote:
> > Very simple patch - easy to review. Unfortunately I still not tested
> > it on real hardware (due to lack of AT-power supply).
>
> Looks good, but please report with a Signed-off-by, see
> http://linuxbios.org/index.php/Development_Guidelines#Sign-off_Procedure

OK. I applied my patch again with a signature below:

Signed-off-by: Peter Lemenkov <lemenkov at gmail.com>

> Can you test this soonish on hardware or can someone else on the list
> test it?

I'll be able to test in a week or two - I need to find AT power supply
for my board. If someone could test it would be preferable.

> Thanks, Uwe.

--
With best regards!
-------------- next part --------------
A non-text attachment was scrubbed...
Name: flashrom-at29c010a-enabled.diff
Type: application/octet-stream
Size: 851 bytes
Desc: not available
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20071007/556b9af5/attachment.obj>

From svn at openbios.org  Sun Oct  7 16:33:13 2007
From: svn at openbios.org (svn at openbios.org)
Date: Sun,  7 Oct 2007 16:33:13 +0200
Subject: [LinuxBIOS] r2829 - trunk/util/superiotool
Message-ID: <mailman.705.1355071174.16123.coreboot@coreboot.org>

Author: uwe
Date: 2007-10-07 16:33:13 +0200 (Sun, 07 Oct 2007)
New Revision: 2829

Modified:
   trunk/util/superiotool/smsc.c
Log:
Dump support for the SMSC FDC37M81x.

Signed-off-by: Robinson P. Tryon <bishop.robinson at gmail.com>
Acked-by: Peter Stuge <peter at stuge.se>
Acked-by: Uwe Hermann <uwe at hermann-uwe.de>



Modified: trunk/util/superiotool/smsc.c
===================================================================
--- trunk/util/superiotool/smsc.c	2007-10-05 21:58:03 UTC (rev 2828)
+++ trunk/util/superiotool/smsc.c	2007-10-07 14:33:13 UTC (rev 2829)
@@ -47,6 +47,36 @@
 	{0x4c, "FDC37B72x", {
 		{EOT}}},
 	{0x4d, "FDC37M81x", {
+		{NOLDN, NULL,
+			{0x03,0x07,0x20,0x21,0x22,0x23,0x24,0x26,0x27,0x2b,
+			 0x2c,0x2d,0x2e,0x2f,EOT},
+			{0x03,0x00,0x4d,NANA,0x00,0x00,0x04,MISC,MISC,NANA,
+			 NANA,NANA,NANA,NANA,EOT}},
+		{0x0, "Floppy",
+			{0x30,0x60,0x61,0x70,0x74,0xf0,0xf1,0xf2,0xf4,
+			 0xf5,EOT},
+			{0x00,0x03,0xf0,0x06,0x02,0x0e,0x00,0xff,0x00,
+			 0x00,EOT}},
+		{0x3, "Parallel port",
+			{0x30,0x60,0x61,0x70,0x74,0xf0,0xf1,EOT},
+			{0x00,0x00,0x00,0x00,0x04,0x3c,0x00,EOT}},
+		{0x4, "COM1",
+			{0x30,0x60,0x61,0x70,0xf0,EOT},
+			{0x00,0x00,0x00,0x00,0x00,EOT}},
+		{0x5, "COM2",
+			{0x30,0x60,0x61,0x62,0x63,0x70,0xf0,0xf1,0xf2,EOT},
+			{0x00,0x00,0x00,RSVD,RSVD,0x00,0x00,0x02,0x03,EOT}},
+		{0x7, "Keyboard",
+			{0x30,0x70,0x72,0xf0,EOT},
+			{0x00,0x00,0x00,0x00,EOT}},
+		{0x8, "Aux I/O",
+			/* Only 0xf6 existing (and reserved) or 0xf6..0xfb? */
+			{0x30,0xb4,0xb5,0xb6,0xb7,0xc0,0xc1,0xc2,0xc3,0xc4,
+			 0xc5,0xc6,0xc7,0xc8,0xf1,0xf2,0xf3,0xf4,0xf6,0xf7,
+			 0xf8,0xf9,0xfa,0xfb,EOT},
+			{0x00,NANA,NANA,NANA,NANA,0x02,0x01,NANA,NANA,NANA,
+			 NANA,NANA,NANA,NANA,0x00,0x00,0x00,0x00,RSVD,RSVD,
+			 RSVD,RSVD,RSVD,RSVD,EOT}},
 		{EOT}}},
 	{0x47, "FDC37M60x", {
 		{EOT}}},




From uwe at hermann-uwe.de  Sun Oct  7 16:38:45 2007
From: uwe at hermann-uwe.de (Uwe Hermann)
Date: Sun, 7 Oct 2007 16:38:45 +0200
Subject: [LinuxBIOS] superiotool - dump support for FDC37M81x
In-Reply-To: <20071007110432.12182.qmail@stuge.se>
References: <a698c16a0710062105h5bff055btc2fcb4d505a37a49@mail.gmail.com>
	<20071007110432.12182.qmail@stuge.se>
Message-ID: <20071007143845.GC12533@greenwood>

On Sun, Oct 07, 2007 at 01:04:32PM +0200, Peter Stuge wrote:
> On Sun, Oct 07, 2007 at 12:05:16AM -0400, Robinson Tryon wrote:
> > Signed-off-by: Robinson P. Tryon <bishop.robinson at gmail.com>
> 
> Acked-by: Peter Stuge <peter at stuge.se>

r2829.

Minor changes:

 - Changed reserved registers to RSVD (even if the datasheet lists defaults)

 - Page 138 of the datasheet says '0xF6 : FB' (reserved). I read that as
   "there are registers 0xf6, 0xf7, ... up to 0xfb which are all reserved".
   (not only one register, 0xf6, which is reserved).


Uwe.
-- 
http://www.hermann-uwe.de  | http://www.holsham-traders.de
http://www.crazy-hacks.org | http://www.unmaintained-free-software.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20071007/b6f8277f/attachment.sig>

From bari at onelabs.com  Sun Oct  7 16:50:20 2007
From: bari at onelabs.com (bari)
Date: Sun, 07 Oct 2007 09:50:20 -0500
Subject: [LinuxBIOS] ASUS MB with Embedded Linux
Message-ID: <4708F22C.5020301@onelabs.com>

Slashdot has an article about how ASUSTek has introduced the P5E3 Deluxe 
motherboard, which in addition to using Intel's new X38 Chipset.
http://linux.slashdot.org/article.pl?sid=07/10/07/0614246

The ASUS website spec only mentions ASUS CrashFree BIOS 3 as the BIOS.
http://www.asus.com/products.aspx?l1=3&l2=11&l3=572&l4=0&model=1872&modelmenu=1

What BIOS is this?

Surf the Internet in 5-second-boot time without entering Windows.
With a fast bootup speed of only 5 seconds, the ASUS Express Gate offers 
an optional Linux OS bootup that allows you to enjoy instant access to 
commonly used functions like accessing the Internet, VoIP, and Web 
emailing without entering the OS.

-Bari



From svn at openbios.org  Sun Oct  7 17:04:17 2007
From: svn at openbios.org (svn at openbios.org)
Date: Sun,  7 Oct 2007 17:04:17 +0200
Subject: [LinuxBIOS] r2830 - trunk/util/superiotool
Message-ID: <mailman.706.1355071174.16123.coreboot@coreboot.org>

Author: uwe
Date: 2007-10-07 17:04:17 +0200 (Sun, 07 Oct 2007)
New Revision: 2830

Modified:
   trunk/util/superiotool/smsc.c
Log:
Dump support for the SMSC FDC37B78x.

Signed-off-by: Robinson P. Tryon <bishop.robinson at gmail.com>
Acked-by: Uwe Hermann <uwe at hermann-uwe.de>



Modified: trunk/util/superiotool/smsc.c
===================================================================
--- trunk/util/superiotool/smsc.c	2007-10-07 14:33:13 UTC (rev 2829)
+++ trunk/util/superiotool/smsc.c	2007-10-07 15:04:17 UTC (rev 2830)
@@ -43,6 +43,47 @@
 	{0x42, "FDC37B80x", {
 		{EOT}}},
 	{0x44, "FDC37B78x", {
+		{NOLDN, NULL,
+			{0x03,0x07,0x20,0x21,0x22,0x23,0x24,0x26,0x27,0x28,
+			 0x2b,0x2c,0x2d,0x2e,0x2f,EOT},
+			{0x03,NANA,0x44,0x00,0x00,0x00,0x04,MISC,MISC,0x00,
+			 NANA,NANA,NANA,NANA,NANA,EOT}},
+		{0x0, "Floppy",
+			{0x30,0x60,0x61,0x70,0x74,0xf0,0xf1,0xf2,0xf4,0xf5,
+			 EOT},
+			{0x00,0x03,0xf0,0x06,0x02,0x0e,0x00,0xff,0x00,0x00,
+			 EOT}},
+		{0x3, "Parallel port",
+			{0x30,0x60,0x61,0x70,0x74,0xf0,0xf1,EOT},
+			{0x00,0x00,0x00,0x00,0x04,0x3c,0x00,EOT}},
+		{0x4, "COM1",
+			{0x30,0x60,0x61,0x70,0xf0,EOT},
+			{0x00,0x00,0x00,0x00,0x00,EOT}},
+		{0x5, "COM2",
+			{0x30,0x60,0x61,0x62,0x63,0x70,0x74,0xf0,0xf1,0xf2,
+			 EOT},
+			{NANA,0x00,0x00,0x00,0x00,0x00,0x04,0x00,0x02,0x03,
+			 EOT}},
+		{0x6, "Real-time clock (RTC)",
+			{0x30,0x62,0x63,0x70,0xf0,EOT},
+			{0x00,0x00,0x70,0x00,0x00,EOT}},
+		{0x7, "Keyboard",
+			{0x30,0x70,0x72,0xf0,EOT},
+			{0x00,0x00,0x00,0x00,EOT}},
+		{0x8, "Aux I/O",
+			{0x30,0xb0,0xb1,0xb2,0xb3,0xb8,0xc0,0xc1,0xc2,0xc3,
+			 0xc4,0xc5,0xc6,0xc8,0xca,0xcb,0xcc,0xd0,0xd1,0xd2,
+			 0xd3,0xd4,0xd5,0xd6,0xd7,0xe0,0xe1,0xe2,0xe3,0xe4,
+			 0xe5,0xe6,0xe7,0xef,0xf0,0xf1,0xf2,0xf3,0xf4,0xf6,
+			 0xf9,0xfa,EOT},
+			{0x00,NANA,NANA,NANA,NANA,NANA,NANA,0x01,NANA,NANA,
+			 NANA,0x00,NANA,NANA,NANA,NANA,NANA,NANA,NANA,NANA,
+			 NANA,NANA,NANA,NANA,NANA,NANA,NANA,NANA,NANA,NANA,
+			 NANA,NANA,NANA,NANA,NANA,0x00,0x00,0x00,0x00,NANA,
+			 NANA,NANA,EOT}},
+		{0xa, "ACPI",
+			{0x30,0x60,0x61,0x70,0xf0,EOT},
+			{0x00,0x00,0x00,NANA,NANA,EOT}},
 		{EOT}}},
 	{0x4c, "FDC37B72x", {
 		{EOT}}},




From uwe at hermann-uwe.de  Sun Oct  7 17:04:58 2007
From: uwe at hermann-uwe.de (Uwe Hermann)
Date: Sun, 7 Oct 2007 17:04:58 +0200
Subject: [LinuxBIOS] superiotool - dump support for fdc37b78x
In-Reply-To: <a698c16a0710061016y3d29ab99u790e946ab6dbdc68@mail.gmail.com>
References: <a698c16a0710061016y3d29ab99u790e946ab6dbdc68@mail.gmail.com>
Message-ID: <20071007150458.GD12533@greenwood>

On Sat, Oct 06, 2007 at 01:16:14PM -0400, Robinson Tryon wrote:
> Signed-off-by: Robinson P. Tryon <bishop.robinson at gmail.com>
> 
> (This patch builds on the b272x patch)

Thanks, r2830 (only comitted the FDC37B78x part here).


Uwe.
-- 
http://www.hermann-uwe.de  | http://www.holsham-traders.de
http://www.crazy-hacks.org | http://www.unmaintained-free-software.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20071007/eaadbacb/attachment.sig>

From svn at openbios.org  Sun Oct  7 17:12:12 2007
From: svn at openbios.org (svn at openbios.org)
Date: Sun,  7 Oct 2007 17:12:12 +0200
Subject: [LinuxBIOS] r2831 - trunk/util/superiotool
Message-ID: <mailman.707.1355071175.16123.coreboot@coreboot.org>

Author: uwe
Date: 2007-10-07 17:12:12 +0200 (Sun, 07 Oct 2007)
New Revision: 2831

Modified:
   trunk/util/superiotool/smsc.c
Log:
Dump support for the SMSC FDC37B72x.

Signed-off-by: Robinson P. Tryon <bishop.robinson at gmail.com>
Acked-by: Uwe Hermann <uwe at hermann-uwe.de>



Modified: trunk/util/superiotool/smsc.c
===================================================================
--- trunk/util/superiotool/smsc.c	2007-10-07 15:04:17 UTC (rev 2830)
+++ trunk/util/superiotool/smsc.c	2007-10-07 15:12:12 UTC (rev 2831)
@@ -86,6 +86,42 @@
 			{0x00,0x00,0x00,NANA,NANA,EOT}},
 		{EOT}}},
 	{0x4c, "FDC37B72x", {
+		{NOLDN, NULL,
+			{0x03,0x07,0x20,0x21,0x22,0x23,0x24,0x26,0x27,0x28,
+			 0x2b,0x2c,0x2d,0x2e,0x2f,EOT},
+			{0x03,NANA,0x4c,0x00,0x00,0x00,0x04,MISC,MISC,0x00,
+			 NANA,NANA,NANA,NANA,NANA,EOT}},
+		{0x0, "Floppy",
+			{0x30,0x60,0x61,0x70,0x74,0xf0,0xf1,0xf2,0xf4,0xf5,
+			 EOT},
+			{0x00,0x03,0xf0,0x06,0x02,0x0e,0x00,0xff,0x00,0x00,
+			 EOT}},
+		{0x3, "Parallel port",
+			{0x30,0x60,0x61,0x70,0x74,0xf0,0xf1,EOT},
+			{0x00,0x00,0x00,0x00,0x04,0x3c,0x00,EOT}},
+		{0x4, "COM1",
+			{0x30,0x60,0x61,0x70,0xf0,EOT},
+			{0x00,0x00,0x00,0x00,0x00,EOT}},
+		{0x5, "COM2",
+			{0x30,0x60,0x61,0x70,0xf0,0xf1,0xf2,EOT},
+			{NANA,0x00,0x00,0x00,0x00,0x02,0x03,EOT}},
+		{0x7, "Keyboard",
+			{0x30,0x70,0x72,0xf0,EOT},
+			{0x00,0x00,0x00,0x00,EOT}},
+		{0x8, "Aux I/O",
+			{0x30,0xb0,0xb1,0xb2,0xb3,0xb8,0xc0,0xc1,0xc2,0xc3,
+			 0xc4,0xc5,0xc6,0xc8,0xca,0xcb,0xcc,0xd0,0xd1,0xd2,
+			 0xd3,0xd4,0xd5,0xd6,0xd7,0xe0,0xe1,0xe2,0xe3,0xe4,
+			 0xe5,0xe6,0xe7,0xef,0xf0,0xf1,0xf2,0xf3,0xf4,0xf6,
+			 0xf9,0xfa,EOT},
+			{0x00,NANA,NANA,NANA,NANA,NANA,0x00,0x01,NANA,NANA,
+			 NANA,0x00,NANA,NANA,NANA,NANA,NANA,NANA,NANA,NANA,
+			 NANA,NANA,NANA,NANA,NANA,NANA,NANA,NANA,NANA,NANA,
+			 NANA,NANA,NANA,NANA,NANA,0x00,0x00,0x00,MISC,NANA,
+			 NANA,NANA,EOT}},
+		{0xa, "ACPI",
+			{0x30,0x60,0x61,0x70,0xf0,EOT},
+			{0x00,0x00,0x00,NANA,NANA,EOT}},
 		{EOT}}},
 	{0x4d, "FDC37M81x", {
 		{NOLDN, NULL,




From uwe at hermann-uwe.de  Sun Oct  7 17:12:38 2007
From: uwe at hermann-uwe.de (Uwe Hermann)
Date: Sun, 7 Oct 2007 17:12:38 +0200
Subject: [LinuxBIOS] superiotool - dump support for fdc37b72x
In-Reply-To: <a698c16a0710060900t73032585j7716f046ad05ba42@mail.gmail.com>
References: <a698c16a0710060900t73032585j7716f046ad05ba42@mail.gmail.com>
Message-ID: <20071007151238.GE12533@greenwood>

On Sat, Oct 06, 2007 at 12:00:31PM -0400, Robinson Tryon wrote:
> Signed-off-by: Robinson P. Tryon <bishop.robinson at gmail.com>

Thanks, r2831.


Uwe.
-- 
http://www.hermann-uwe.de  | http://www.holsham-traders.de
http://www.crazy-hacks.org | http://www.unmaintained-free-software.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20071007/e9d971d0/attachment.sig>

From info at coresystems.de  Sun Oct  7 17:20:47 2007
From: info at coresystems.de (LinuxBIOS information)
Date: Sun, 07 Oct 2007 17:20:47 +0200
Subject: [LinuxBIOS] r2829 build service
Message-ID: <E1IeXvz-0000Xv-Li@khepri.openbios.org>

Dear LinuxBIOS readers!

This is the automated build check service of LinuxBIOS.

The developer "uwe" checked in revision 2829 to
the LinuxBIOS source repository and caused the following 
changes:

Change Log:
Dump support for the SMSC FDC37M81x.

Signed-off-by: Robinson P. Tryon <bishop.robinson at gmail.com>
Acked-by: Peter Stuge <peter at stuge.se>
Acked-by: Uwe Hermann <uwe at hermann-uwe.de>



Build Log:
Compilation of arima:hdama is still broken
See the error log at http://qa.linuxbios.org/log_buildbrd.php?revision=2829&device=hdama&vendor=arima
Compilation of ibm:e325 is still broken
See the error log at http://qa.linuxbios.org/log_buildbrd.php?revision=2829&device=e325&vendor=ibm
Compilation of ibm:e326 is still broken
See the error log at http://qa.linuxbios.org/log_buildbrd.php?revision=2829&device=e326&vendor=ibm
Compilation of iei:juki-511p is still broken
See the error log at http://qa.linuxbios.org/log_buildbrd.php?revision=2829&device=juki-511p&vendor=iei
Compilation of iwill:dk8s2 is still broken
See the error log at http://qa.linuxbios.org/log_buildbrd.php?revision=2829&device=dk8s2&vendor=iwill
Compilation of iwill:dk8x is still broken
See the error log at http://qa.linuxbios.org/log_buildbrd.php?revision=2829&device=dk8x&vendor=iwill
Compilation of newisys:khepri is still broken
See the error log at http://qa.linuxbios.org/log_buildbrd.php?revision=2829&device=khepri&vendor=newisys


If something broke during this checkin please be a pain 
in uwe's neck until the issue is fixed.

If this issue is not fixed within 24h the revision should 
be backed out.

   Best regards,
     LinuxBIOS automatic build system





From svn at openbios.org  Sun Oct  7 17:26:40 2007
From: svn at openbios.org (svn at openbios.org)
Date: Sun,  7 Oct 2007 17:26:40 +0200
Subject: [LinuxBIOS] r2832 - trunk/util/superiotool
Message-ID: <mailman.708.1355071175.16123.coreboot@coreboot.org>

Author: uwe
Date: 2007-10-07 17:26:40 +0200 (Sun, 07 Oct 2007)
New Revision: 2832

Added:
   trunk/util/superiotool/superiotool.8
Modified:
   trunk/util/superiotool/Makefile
Log:
Add a manpage for superiotool (trivial).

Signed-off-by: Uwe Hermann <uwe at hermann-uwe.de>
Acked-by: Uwe Hermann <uwe at hermann-uwe.de>



Modified: trunk/util/superiotool/Makefile
===================================================================
--- trunk/util/superiotool/Makefile	2007-10-07 15:12:12 UTC (rev 2831)
+++ trunk/util/superiotool/Makefile	2007-10-07 15:26:40 UTC (rev 2832)
@@ -37,6 +37,8 @@
 
 install: $(PROGRAM)
 	$(INSTALL) $(PROGRAM) $(PREFIX)/bin
+	mkdir -p $(PREFIX)/share/man/man8
+	$(INSTALL) $(PROGRAM).8 $(PREFIX)/share/man/man8
 
 clean:
 	rm -f $(PROGRAM) *.o

Added: trunk/util/superiotool/superiotool.8
===================================================================
--- trunk/util/superiotool/superiotool.8	                        (rev 0)
+++ trunk/util/superiotool/superiotool.8	2007-10-07 15:26:40 UTC (rev 2832)
@@ -0,0 +1,58 @@
+.TH SUPERIOTOOL 8 "October 7, 2007"
+.SH NAME
+superiotool \- Super I/O detection tool
+.SH SYNOPSIS
+.B superiotool \fR[\fB\-dDVvh\fR] 
+.SH DESCRIPTION
+.B superiotool
+is a GPL'd user-space utility which can
+.PP
+ * detect which Super I/O chip is soldered onto your mainboard,
+.PP
+ * at which configuration port it's located (usually 0x2e or 0x4e), and
+.PP
+ * dump all register contents of the Super I/O chip, together with the
+   default values as per datasheet (to make comparing the values easy).
+.PP
+It is mainly used for LinuxBIOS development purposes (see linuxbios.org
+for details on LinuxBIOS), but it may also be useful for other things.
+.SH OPTIONS
+If no command line option is specified,
+.B superiotool
+merely tries to detect the Super I/O chip.
+You must use either the
+.BR "\-d" " or the " "\-D"
+option to dump the Super I/O register contents.
+.TP
+.B "\-d, \-\-dump"
+Dump Super I/O registers (if the Super I/O chip is detected and
+.B superiotool
+supports the
+.B "\-\-dump"
+option for this chip).
+.TP
+.B "\-D, \-\-dump-readable"
+Dump Super I/O registers in human-readable format (if the Super I/O chip
+is detected and
+.B superiotool
+supports the
+.B "\-\-dump-readable"
+option for this chip).
+.TP
+.B "\-V, \-\-verbose"
+Enable verbose mode. This option can be used together with the
+.BR "\-d" " or " "\-D" " option".
+.TP
+.B "\-v, \-\-version"
+Show version information and exit.
+.TP
+.B "\-h, \-\-help"
+Show a help text and exit.
+.SH BUGS
+Please report any bugs at http://tracker.linuxbios.org/trac/LinuxBIOS/
+or on the LinuxBIOS mailing list (http://linuxbios.org/Mailinglist).
+.SH LICENCE
+.B superiotool
+is covered by the GNU General Public License (GPL), version 2 or later.
+.SH SEE ALSO
+.BR sensors-detect (8)




From uwe at hermann-uwe.de  Sun Oct  7 17:39:51 2007
From: uwe at hermann-uwe.de (Uwe Hermann)
Date: Sun, 7 Oct 2007 17:39:51 +0200
Subject: [LinuxBIOS] superiotool - dump support for LPC47M112
In-Reply-To: <20071007110210.11774.qmail@stuge.se>
References: <a698c16a0710061926j630a66f7maadc57d891047eb1@mail.gmail.com>
	<20071007110210.11774.qmail@stuge.se>
Message-ID: <20071007153951.GG12533@greenwood>

Hi,

while the patch is correct I won't apply it for now. I have a much
bigger patch in the works which does what your patch does, and adds
a lots more other (duplicate) IDs for chips with different name...


On Sun, Oct 07, 2007 at 01:02:10PM +0200, Peter Stuge wrote:
> > In general, can I assume that two chips with the same id number
> > will have the exact same register layout?
> 
> No, I don't think that is safe.

True.

There are several chips with different names and same IDs.
 
 
> > Also, what are "Ultra I/Os", and should superiotool support dumps
> > from 'em?
> 
> Sorry, no idea.

Can you name an example? I think that's just another name for Super I/O,
so yes, I think we should support them.


Uwe.
-- 
http://www.hermann-uwe.de  | http://www.holsham-traders.de
http://www.crazy-hacks.org | http://www.unmaintained-free-software.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20071007/e19f272b/attachment.sig>

From idwer_v at hotmail.com  Sun Oct  7 17:50:03 2007
From: idwer_v at hotmail.com (Idwer Vollering)
Date: Sun, 7 Oct 2007 15:50:03 +0000
Subject: [LinuxBIOS] Flashrom: support for At29C010A added.
In-Reply-To: <20071007142009.GB12533@greenwood>
References: <adf480660710070422t8c12c8dv2494b148e6c85d18@mail.gmail.com>
	<20071007142009.GB12533@greenwood>
Message-ID: <BLU102-W490CDC4ABE7C94EFDBDEE28BAB0@phx.gbl>




> Date: Sun, 7 Oct 2007 16:20:09 +0200
> From: uwe at hermann-uwe.de
> To: lemenkov at gmail.com
> CC: linuxbios at linuxbios.org
> Subject: Re: [LinuxBIOS] Flashrom: support for At29C010A added.
> 
> On Sun, Oct 07, 2007 at 03:22:24PM +0400, Peter Lemenkov wrote:
> > Very simple patch - easy to review. Unfortunately I still not tested
> > it on real hardware (due to lack of AT-power supply).
> 
> Looks good, but please report with a Signed-off-by, see
> http://linuxbios.org/index.php/Development_Guidelines#Sign-off_Procedure
> 
> Can you test this soonish on hardware or can someone else on the list
> test it?
> 
> 
> Thanks, Uwe.
> -- 
> http://www.hermann-uwe.de  | http://www.holsham-traders.de
> http://www.crazy-hacks.org | http://www.unmaintained-free-software.org

Reading the content of at29c010a works (at29c010a-128BK.bios), reflashing doesn't.. maybe it is self-protected ?

$ sudo ./flashrom -V -v -w at29c010a-128KB.bios
(..)
Probing for At29C010A, 128 KB
probe_jedec: id1 0x1f, id2 0xd5
AT29C010A found at physical address: 0xfffe0000
Flash part is At29C010A (128 KB)
Flash image seems to be a legacy BIOS. Disabling checks.
Programming Page: 1023 at address: 0x0001ff80
Verifying flash address: 0x00000000 - FAILED

Maybe it needs to be erased first:
$ sudo ./flashrom -V -v -w at29c010a-128KB.bios

(..)

Probing for At29C010A, 128 KB

probe_jedec: id1 0x1f, id2 0xd5

AT29C010A found at physical address: 0xfffe0000

Flash part is At29C010A (128 KB)
Erasing flash chip

Flash after erase:

$ sudo ./flashrom -V -v -w at29c010a-128KB.bios

(..)

Probing for At29C010A, 128 KB

probe_jedec: id1 0x1f, id2 0xd5

AT29C010A found at physical address: 0xfffe0000

Flash part is At29C010A (128 KB)

Flash image seems to be a legacy BIOS. Disabling checks.

Programming Page: 1023 at address: 0x0001ff80

Verifying flash address: 0x00000000 - FAILED
_________________________________________________________________
De mooiste afbeeldingen van Angelina Jolie vind je met Live Search
http://search.live.com/images/results.aspx?q=angelina%20jolie&FORM=QBIR
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20071007/cd769a68/attachment.html>

From info at coresystems.de  Sun Oct  7 18:10:22 2007
From: info at coresystems.de (LinuxBIOS information)
Date: Sun, 07 Oct 2007 18:10:22 +0200
Subject: [LinuxBIOS] r2830 build service
Message-ID: <E1IeYhy-0005vC-Dm@khepri.openbios.org>

Dear LinuxBIOS readers!

This is the automated build check service of LinuxBIOS.

The developer "uwe" checked in revision 2830 to
the LinuxBIOS source repository and caused the following 
changes:

Change Log:
Dump support for the SMSC FDC37B78x.

Signed-off-by: Robinson P. Tryon <bishop.robinson at gmail.com>
Acked-by: Uwe Hermann <uwe at hermann-uwe.de>



Build Log:
Compilation of arima:hdama is still broken
See the error log at http://qa.linuxbios.org/log_buildbrd.php?revision=2830&device=hdama&vendor=arima
Compilation of ibm:e325 is still broken
See the error log at http://qa.linuxbios.org/log_buildbrd.php?revision=2830&device=e325&vendor=ibm
Compilation of ibm:e326 is still broken
See the error log at http://qa.linuxbios.org/log_buildbrd.php?revision=2830&device=e326&vendor=ibm
Compilation of iei:juki-511p is still broken
See the error log at http://qa.linuxbios.org/log_buildbrd.php?revision=2830&device=juki-511p&vendor=iei
Compilation of iwill:dk8s2 is still broken
See the error log at http://qa.linuxbios.org/log_buildbrd.php?revision=2830&device=dk8s2&vendor=iwill
Compilation of iwill:dk8x is still broken
See the error log at http://qa.linuxbios.org/log_buildbrd.php?revision=2830&device=dk8x&vendor=iwill
Compilation of newisys:khepri is still broken
See the error log at http://qa.linuxbios.org/log_buildbrd.php?revision=2830&device=khepri&vendor=newisys


If something broke during this checkin please be a pain 
in uwe's neck until the issue is fixed.

If this issue is not fixed within 24h the revision should 
be backed out.

   Best regards,
     LinuxBIOS automatic build system





From rminnich at gmail.com  Sun Oct  7 18:38:12 2007
From: rminnich at gmail.com (ron minnich)
Date: Sun, 7 Oct 2007 09:38:12 -0700
Subject: [LinuxBIOS] ASUS MB with Embedded Linux
In-Reply-To: <4708F22C.5020301@onelabs.com>
References: <4708F22C.5020301@onelabs.com>
Message-ID: <13426df10710070938m798bd2aficfc34c09bf5faa33@mail.gmail.com>

It's interesting as it is an Intel chipset.

Folks have known how to make Linux into an EFI-replacement for several
years. I have heard  that Linux can easily replace EFI, and is loaded
after PEI. PEI has most of the really secret sauce anyway. I wonder if
this is what asus is doing?

I guess there is demand for this, I bet there could be way more demand
for Linux in FLASH than for EFI, if more people knew that companies
can put Linux in FLASH in place of EFI.

Open source continues to push proprietary, closed solutions out of its way.

ron



From rminnich at gmail.com  Sun Oct  7 19:13:38 2007
From: rminnich at gmail.com (ron minnich)
Date: Sun, 7 Oct 2007 10:13:38 -0700
Subject: [LinuxBIOS] FYI Asus ships mainboard with Linux,
	Firefox & Skype sitting in flashrom :)
In-Reply-To: <adf480660710070552pe9e5ba8h2c134f2d50526498@mail.gmail.com>
References: <adf480660710070552pe9e5ba8h2c134f2d50526498@mail.gmail.com>
Message-ID: <13426df10710071013n674be7f8g2983cbc1d7220e6b@mail.gmail.com>

On 10/7/07, Peter Lemenkov <lemenkov at gmail.com> wrote:
> Hello All!
> Maybe somebody didn't see it yet?
>
> http://www.phoronix.com/scan.php?page=article&item=869
>
> They'd better use LinuxBIOS :)

I wonder if Intel let them. It's an intel chipset.

ron



From info at coresystems.de  Sun Oct  7 19:19:43 2007
From: info at coresystems.de (LinuxBIOS information)
Date: Sun, 07 Oct 2007 19:19:43 +0200
Subject: [LinuxBIOS] r2831 build service
Message-ID: <E1IeZn5-0006As-Tf@khepri.openbios.org>

Dear LinuxBIOS readers!

This is the automated build check service of LinuxBIOS.

The developer "uwe" checked in revision 2831 to
the LinuxBIOS source repository and caused the following 
changes:

Change Log:
Dump support for the SMSC FDC37B72x.

Signed-off-by: Robinson P. Tryon <bishop.robinson at gmail.com>
Acked-by: Uwe Hermann <uwe at hermann-uwe.de>



Build Log:
Compilation of arima:hdama is still broken
See the error log at http://qa.linuxbios.org/log_buildbrd.php?revision=2831&device=hdama&vendor=arima
Compilation of ibm:e325 is still broken
See the error log at http://qa.linuxbios.org/log_buildbrd.php?revision=2831&device=e325&vendor=ibm
Compilation of ibm:e326 is still broken
See the error log at http://qa.linuxbios.org/log_buildbrd.php?revision=2831&device=e326&vendor=ibm
Compilation of iei:juki-511p is still broken
See the error log at http://qa.linuxbios.org/log_buildbrd.php?revision=2831&device=juki-511p&vendor=iei
Compilation of iwill:dk8s2 is still broken
See the error log at http://qa.linuxbios.org/log_buildbrd.php?revision=2831&device=dk8s2&vendor=iwill
Compilation of iwill:dk8x is still broken
See the error log at http://qa.linuxbios.org/log_buildbrd.php?revision=2831&device=dk8x&vendor=iwill
Compilation of newisys:khepri is still broken
See the error log at http://qa.linuxbios.org/log_buildbrd.php?revision=2831&device=khepri&vendor=newisys


If something broke during this checkin please be a pain 
in uwe's neck until the issue is fixed.

If this issue is not fixed within 24h the revision should 
be backed out.

   Best regards,
     LinuxBIOS automatic build system





From bari at onelabs.com  Sun Oct  7 19:46:07 2007
From: bari at onelabs.com (bari)
Date: Sun, 07 Oct 2007 12:46:07 -0500
Subject: [LinuxBIOS] ASUS MB with Embedded Linux
In-Reply-To: <13426df10710070938m798bd2aficfc34c09bf5faa33@mail.gmail.com>
References: <4708F22C.5020301@onelabs.com>
	<13426df10710070938m798bd2aficfc34c09bf5faa33@mail.gmail.com>
Message-ID: <47091B5F.2090000@onelabs.com>

At $360 USD ea. I thought maybe M$ got into the BIOS business.



From info at coresystems.de  Sun Oct  7 20:13:55 2007
From: info at coresystems.de (LinuxBIOS information)
Date: Sun, 07 Oct 2007 20:13:55 +0200
Subject: [LinuxBIOS] r2832 build service
Message-ID: <E1IeadX-0003Hh-Db@khepri.openbios.org>

Dear LinuxBIOS readers!

This is the automated build check service of LinuxBIOS.

The developer "uwe" checked in revision 2832 to
the LinuxBIOS source repository and caused the following 
changes:

Change Log:
Add a manpage for superiotool (trivial).

Signed-off-by: Uwe Hermann <uwe at hermann-uwe.de>
Acked-by: Uwe Hermann <uwe at hermann-uwe.de>



Build Log:
Compilation of arima:hdama is still broken
See the error log at http://qa.linuxbios.org/log_buildbrd.php?revision=2832&device=hdama&vendor=arima
Compilation of ibm:e325 is still broken
See the error log at http://qa.linuxbios.org/log_buildbrd.php?revision=2832&device=e325&vendor=ibm
Compilation of ibm:e326 is still broken
See the error log at http://qa.linuxbios.org/log_buildbrd.php?revision=2832&device=e326&vendor=ibm
Compilation of iei:juki-511p is still broken
See the error log at http://qa.linuxbios.org/log_buildbrd.php?revision=2832&device=juki-511p&vendor=iei
Compilation of iwill:dk8s2 is still broken
See the error log at http://qa.linuxbios.org/log_buildbrd.php?revision=2832&device=dk8s2&vendor=iwill
Compilation of iwill:dk8x is still broken
See the error log at http://qa.linuxbios.org/log_buildbrd.php?revision=2832&device=dk8x&vendor=iwill
Compilation of newisys:khepri is still broken
See the error log at http://qa.linuxbios.org/log_buildbrd.php?revision=2832&device=khepri&vendor=newisys


If something broke during this checkin please be a pain 
in uwe's neck until the issue is fixed.

If this issue is not fixed within 24h the revision should 
be backed out.

   Best regards,
     LinuxBIOS automatic build system





From svn at openbios.org  Sun Oct  7 21:04:26 2007
From: svn at openbios.org (svn at openbios.org)
Date: Sun,  7 Oct 2007 21:04:26 +0200
Subject: [LinuxBIOS] r2833 - trunk/util/superiotool
Message-ID: <mailman.709.1355071175.16123.coreboot@coreboot.org>

Author: uwe
Date: 2007-10-07 21:04:26 +0200 (Sun, 07 Oct 2007)
New Revision: 2833

Modified:
   trunk/util/superiotool/winbond.c
Log:
Add dump support for the Winbond W83627THF/THG.

Signed-off-by: David Hendricks <david.hendricks at gmail.com>
Acked-by: Peter Stuge <peter at stuge.se>
Acked-by: Uwe Hermann <uwe at hermann-uwe.de>



Modified: trunk/util/superiotool/winbond.c
===================================================================
--- trunk/util/superiotool/winbond.c	2007-10-07 15:26:40 UTC (rev 2832)
+++ trunk/util/superiotool/winbond.c	2007-10-07 19:04:26 UTC (rev 2833)
@@ -97,6 +97,49 @@
 	{0x708, "W83637HF/HG", {
 		{EOT}}},
 	{0x828, "W83627THF/THG", { /* We assume rev is bits 3..0 of 0x21. */
+		{NOLDN, NULL,
+			{0x20,0x21,0x22,0x23,0x24,0x25,0x26,0x28,0x29,0x2a,
+			 0x2b,0x2c,0x2d,0x2e,0x2f,EOT},
+			{0x82,NANA,0xff,0x00,MISC,0x00,MISC,0x00,0x00,0x00,
+			 MISC,MISC,MISC,0x00,0x00,EOT}},
+		/* Some register defaults depend on the value of PNPCSV. */
+		{0x0, "Floppy",
+			{0x30,0x60,0x61,0x70,0x74,0xf0,0xf1,0xf2,0xf4,
+			 0xf5,EOT},
+			{0x01,0x03,0xf0,0x06,0x02,0x0e,0x00,0xff,0x00,
+			 0x00,EOT}},
+		{0x1, "Parallel port",
+			{0x30,0x60,0x61,0x70,0x74,0xf0,EOT},
+			{0x01,0x03,0x78,0x07,0x04,0x3f,EOT}},
+		{0x2, "COM1",
+			{0x30,0x60,0x61,0x70,0xf0,EOT},
+			{0x01,0x03,0xf8,0x04,0x00,EOT}},
+		{0x3, "COM2",
+			{0x30,0x60,0x61,0x70,0xf0,0xf1,EOT},
+			{0x01,0x02,0xf8,0x03,0x00,0x00,EOT}},
+		{0x5, "Keyboard",
+			{0x30,0x60,0x61,0x62,0x63,0x70,0x72,0xf0,EOT},
+			{0x01,0x00,0x60,0x00,0x64,0x01,0x0c,0x80,EOT}},
+		{0x7, "GPIO 1, GPIO 5, game port, MIDI port",
+			{0x30,0x60,0x61,0x62,0x63,0x70,0xf0,0xf1,0xf2,0xf3,
+			 0xf4,0xf5,EOT},
+			{0x00,0x02,0x01,0x03,0x30,0x09,0xff,0x00,0x00,0xff,
+			 0x00,0x00,EOT}},
+		{0x8, "GPIO 2",
+			{0x30,0xf0,0xf1,0xf2,0xf3,0xf4,0xf5,0xf6,0xf7,EOT},
+			{0x00,0xff,0x00,0x00,0x00,RSVD,0x00,0x00,0x00,EOT}},
+		{0x9, "GPIO 3, GPIO 4",
+			{0x30,0xf0,0xf1,0xf2,0xf3,0xf4,0xf5,0xf6,EOT},
+			{0x00,0xff,0x00,0x00,0x00,0xff,0x00,0x00,EOT}},
+		{0xa, "ACPI",
+			/* Note: Datasheet says 0xe2 can't be read/written. */
+			{0x30,0x70,0xe0,0xe1,0xe2,0xe3,0xe4,0xe5,0xe6,0xe7,
+			 0xf0,0xf1,0xf3,0xf4,0xf6,0xf7,0xf9,0xfe,0xff,EOT},
+			{0x00,0x00,0x00,0x00,MISC,MISC,0x00,0x00,0x00,0x00,
+			 0x00,0x00,0x00,0x00,0x00,0x00,0x00,RSVD,RSVD,EOT}},
+		{0xb, "Hardware monitor",
+			{0x30,0x60,0x61,0x70,EOT},
+			{0x00,0x00,0x00,0x00,EOT}},
 		{EOT}}},
 #if 0
 	{0x85x, "W83687THF", {	/* TODO: sensors-detect: 0x85 */




From svn at openbios.org  Sun Oct  7 21:10:24 2007
From: svn at openbios.org (svn at openbios.org)
Date: Sun,  7 Oct 2007 21:10:24 +0200
Subject: [LinuxBIOS] r2834 - trunk/util/superiotool
Message-ID: <mailman.710.1355071175.16123.coreboot@coreboot.org>

Author: uwe
Date: 2007-10-07 21:10:24 +0200 (Sun, 07 Oct 2007)
New Revision: 2834

Modified:
   trunk/util/superiotool/README
Log:
Add a list of contributors to the README (trivial). Also, a small hint
about where to send additional register dumps.

Signed-off-by: Uwe Hermann <uwe at hermann-uwe.de>
Acked-by: Uwe Hermann <uwe at hermann-uwe.de>



Modified: trunk/util/superiotool/README
===================================================================
--- trunk/util/superiotool/README	2007-10-07 19:04:26 UTC (rev 2833)
+++ trunk/util/superiotool/README	2007-10-07 19:10:24 UTC (rev 2834)
@@ -59,7 +59,12 @@
 
 Please see http://linuxbios.org/Superiotool#Supported_devices.
 
+There's also a collection of sample register dumps from various Super I/O
+chips on that page. Please send further register dumps (either from a
+proprietary BIOS and/or from LinuxBIOS) to the LinuxBIOS mailing list
+(http://linuxbios.org/Mailinglist).
 
+
 Website and Mailing List
 ------------------------
 
@@ -79,3 +84,16 @@
 It is licensed under the terms of the GNU General Public License (GPL),
 either version 2 of the License, or (at your option) any later version.
 
+
+Contributors
+------------
+
+Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006 at gmx.net>
+David Hendricks <david.hendricks at gmail.com>
+Rasmus Wiman <rasmus at wiman.org>
+Robinson P. Tryon <bishop.robinson at gmail.com>
+Ronald Minnich <rminnich at gmail.com>
+Stefan Reinauer <stepan at coresystems.de>
+Uwe Hermann <uwe at hermann-uwe.de>
+Ward Vandewege <ward at gnu.org>
+




From uwe at hermann-uwe.de  Sun Oct  7 21:15:26 2007
From: uwe at hermann-uwe.de (Uwe Hermann)
Date: Sun, 7 Oct 2007 21:15:26 +0200
Subject: [LinuxBIOS] superiotool patch for W83627THF/THG
In-Reply-To: <20071007110115.11603.qmail@stuge.se>
References: <a2496e180710061909x5d9c5acbna9ad7404be9c2218@mail.gmail.com>
	<20071007110115.11603.qmail@stuge.se>
Message-ID: <20071007191526.GH12533@greenwood>

On Sun, Oct 07, 2007 at 01:01:15PM +0200, Peter Stuge wrote:
> On Sat, Oct 06, 2007 at 07:09:40PM -0700, David Hendricks wrote:
> > Hello everyone,
> >     Ron, Stefan and I were kicking the shit and came up with this small
> > patch for superiotool. Adds support for a Winbond device where there was
> > once only a stub. Enjoy!
> > 
> > Signed-off-by: David Hendricks <david.hendricks at gmail.com>
> 
> Acked-by: Peter Stuge <peter at stuge.se>

Thanks, r2833. I fixed some values in the table, though. Maybe just
simple typos, but just to make sure -- we're really talking about the
W83627THF/THG chips? And you used the defaults as per datasheet
(not the output from a certain _physical_ chip you tried it on)?

Anyway, do you happen to also have a box with this Super I/O? If so,
please send the dump output from the latest svn revision.


Thanks, Uwe.
-- 
http://www.hermann-uwe.de  | http://www.holsham-traders.de
http://www.crazy-hacks.org | http://www.unmaintained-free-software.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20071007/c988f667/attachment.sig>

From gavin at trollgod.org.uk  Sun Oct  7 21:35:03 2007
From: gavin at trollgod.org.uk (Gavin Kinsey)
Date: Sun, 7 Oct 2007 20:35:03 +0100
Subject: [LinuxBIOS] Superiotool dump for Epox 8RDA3+
Message-ID: <200710072035.03610.gavin@trollgod.org.uk>

Just noticed that superiotool now supports my board, don't know whether 
someone has already posted a dump for this chip but another can't hurt 
if they have so...

Mainboard: Epox 8RDA3+
nVidia nForce 2 chipset

$ sudo ./superiotool -d
Found Winbond W83627HF/F/HG/G (id=0x52, rev=0x17) at 0x2e
Register dump:
idx 02 07 20 21 22 23 24 25 26 28 29 2a 2b 2c 2e 2f
val ff 0b 52 17 ff fe 80 00 00 00 00 7c c0 ff 00 ff
def 00 NA 52 NA ff 00 MM 00 00 00 00 7c c0 00 00 00
LDN 0x00 (Floppy)
idx 30 60 61 70 74 f0 f1 f2 f4 f5
val 01 03 f0 06 02 0e 00 ff 00 00
def 01 03 f0 06 02 0e 00 ff 00 00
LDN 0x01 (Parallel port)
idx 30 60 61 70 74 f0
val 01 03 78 07 04 3c
def 01 03 78 07 04 3f
LDN 0x02 (COM1)
idx 30 60 61 70 f0
val 01 03 f8 04 00
def 01 03 f8 04 00
LDN 0x03 (COM2)
idx 30 60 61 70 f0 f1
val 01 02 f8 03 00 00
def 01 02 f8 03 00 00
LDN 0x05 (Keyboard)
idx 30 60 61 62 63 70 72 f0
val 01 00 60 00 64 01 00 80
def 01 00 60 00 64 01 0c 80
LDN 0x06 (Consumer IR)
idx 30 60 61 70
val 00 00 00 00
def 00 00 00 00
LDN 0x07 (Game port, MIDI port, GPIO 1)
idx 30 60 61 62 63 70 f0 f1 f2
val 07 02 01 03 30 0a ff 00 00
def 00 02 01 03 30 09 ff 00 00
LDN 0x08 (GPIO 2, Watchdog timer)
idx 30 f0 f1 f2 f3 f5 f6 f6 f7
val 01 ff 07 01 00 00 00 00 00
def 00 ff 00 00 00 00 00 00 00
LDN 0x09 (GPIO 3)
idx 30 f0 f1 f2 f3
val 01 ff 00 00 40
def 00 ff 00 00 00
LDN 0x0a (ACPI)
idx 30 70 e0 e1 e2 e3 e4 e5 e6 e7 f0 f1 f3 f4 f6 f7 f9 fe ff
val 00 00 40 03 14 00 00 00 00 00 00 af 37 04 00 00 00 00 00
def 00 00 00 00 NA NA 00 00 00 00 00 00 00 00 00 00 00 00 00
LDN 0x0b (Hardware monitor)
idx 30 60 61 70 f0
val 01 02 90 00 00
def 00 00 00 00 00



From info at coresystems.de  Sun Oct  7 21:51:37 2007
From: info at coresystems.de (LinuxBIOS information)
Date: Sun, 07 Oct 2007 21:51:37 +0200
Subject: [LinuxBIOS] r2833 build service
Message-ID: <E1IecA5-0002yb-K8@khepri.openbios.org>

Dear LinuxBIOS readers!

This is the automated build check service of LinuxBIOS.

The developer "uwe" checked in revision 2833 to
the LinuxBIOS source repository and caused the following 
changes:

Change Log:
Add dump support for the Winbond W83627THF/THG.

Signed-off-by: David Hendricks <david.hendricks at gmail.com>
Acked-by: Peter Stuge <peter at stuge.se>
Acked-by: Uwe Hermann <uwe at hermann-uwe.de>



Build Log:
Compilation of arima:hdama is still broken
See the error log at http://qa.linuxbios.org/log_buildbrd.php?revision=2833&device=hdama&vendor=arima
Compilation of ibm:e325 is still broken
See the error log at http://qa.linuxbios.org/log_buildbrd.php?revision=2833&device=e325&vendor=ibm
Compilation of ibm:e326 is still broken
See the error log at http://qa.linuxbios.org/log_buildbrd.php?revision=2833&device=e326&vendor=ibm
Compilation of iei:juki-511p is still broken
See the error log at http://qa.linuxbios.org/log_buildbrd.php?revision=2833&device=juki-511p&vendor=iei
Compilation of iwill:dk8s2 is still broken
See the error log at http://qa.linuxbios.org/log_buildbrd.php?revision=2833&device=dk8s2&vendor=iwill
Compilation of iwill:dk8x is still broken
See the error log at http://qa.linuxbios.org/log_buildbrd.php?revision=2833&device=dk8x&vendor=iwill
Compilation of newisys:khepri is still broken
See the error log at http://qa.linuxbios.org/log_buildbrd.php?revision=2833&device=khepri&vendor=newisys


If something broke during this checkin please be a pain 
in uwe's neck until the issue is fixed.

If this issue is not fixed within 24h the revision should 
be backed out.

   Best regards,
     LinuxBIOS automatic build system





From uwe at hermann-uwe.de  Sun Oct  7 21:52:06 2007
From: uwe at hermann-uwe.de (Uwe Hermann)
Date: Sun, 7 Oct 2007 21:52:06 +0200
Subject: [LinuxBIOS] Flashrom: support for At29C010A added.
In-Reply-To: <BLU102-W490CDC4ABE7C94EFDBDEE28BAB0@phx.gbl>
References: <adf480660710070422t8c12c8dv2494b148e6c85d18@mail.gmail.com>
	<20071007142009.GB12533@greenwood>
	<BLU102-W490CDC4ABE7C94EFDBDEE28BAB0@phx.gbl>
Message-ID: <20071007195206.GI12533@greenwood>

On Sun, Oct 07, 2007 at 03:50:03PM +0000, Idwer Vollering wrote:
> Reading the content of at29c010a works (at29c010a-128BK.bios), reflashing doesn't.. maybe it is self-protected ?

Can you read/write other recognized chips on the same mainboard? If no,
then it's quite likely to be a mainboard/chipset issue.


> $ sudo ./flashrom -V -v -w at29c010a-128KB.bios
> (..)
> Probing for At29C010A, 128 KB
> probe_jedec: id1 0x1f, id2 0xd5
> AT29C010A found at physical address: 0xfffe0000

This looks good I think, the chip is recognized,
so I guess we can commit.


Uwe.
-- 
http://www.hermann-uwe.de  | http://www.holsham-traders.de
http://www.crazy-hacks.org | http://www.unmaintained-free-software.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20071007/e91b36d9/attachment.sig>

From svn at openbios.org  Sun Oct  7 22:01:23 2007
From: svn at openbios.org (svn at openbios.org)
Date: Sun,  7 Oct 2007 22:01:23 +0200
Subject: [LinuxBIOS] r2835 - trunk/util/superiotool
Message-ID: <mailman.711.1355071175.16123.coreboot@coreboot.org>

Author: uwe
Date: 2007-10-07 22:01:23 +0200 (Sun, 07 Oct 2007)
New Revision: 2835

Modified:
   trunk/util/superiotool/ali.c
   trunk/util/superiotool/fintek.c
   trunk/util/superiotool/ite.c
   trunk/util/superiotool/nsc.c
   trunk/util/superiotool/smsc.c
   trunk/util/superiotool/superiotool.c
   trunk/util/superiotool/superiotool.h
   trunk/util/superiotool/winbond.c
Log:
Print a short message if no Super I/O chip could be detected (trivial).

Signed-off-by: Uwe Hermann <uwe at hermann-uwe.de>
Acked-by: Uwe Hermann <uwe at hermann-uwe.de>



Modified: trunk/util/superiotool/ali.c
===================================================================
--- trunk/util/superiotool/ali.c	2007-10-07 19:10:24 UTC (rev 2834)
+++ trunk/util/superiotool/ali.c	2007-10-07 20:01:23 UTC (rev 2835)
@@ -89,6 +89,7 @@
 
 	printf("Found ALi %s (id=0x%04x, rev=0x%02x) at 0x%x\n",
 	       get_superio_name(reg_table, id), id, rev, port);
+	chip_found = 1;
 
 	dump_superio("ALi", reg_table, port, id);
 	dump_superio_readable(port); /* TODO */

Modified: trunk/util/superiotool/fintek.c
===================================================================
--- trunk/util/superiotool/fintek.c	2007-10-07 19:10:24 UTC (rev 2834)
+++ trunk/util/superiotool/fintek.c	2007-10-07 20:01:23 UTC (rev 2835)
@@ -155,6 +155,7 @@
 
 	printf("Found Fintek %s (vid=0x%04x, id=0x%04x) at 0x%x\n",
 	       get_superio_name(reg_table, did), vid, did, port);
+	chip_found = 1;
 
 	dump_superio("Fintek", reg_table, port, did);
 	dump_readable_fintek(port, did);

Modified: trunk/util/superiotool/ite.c
===================================================================
--- trunk/util/superiotool/ite.c	2007-10-07 19:10:24 UTC (rev 2834)
+++ trunk/util/superiotool/ite.c	2007-10-07 20:01:23 UTC (rev 2835)
@@ -361,6 +361,7 @@
 
 	printf("Found ITE %s (id=0x%04x, rev=0x%01x) at 0x%x\n",
 	       get_superio_name(reg_table, id), id, chipver, port);
+	chip_found = 1;
 
 	dump_superio("ITE", reg_table, port, id);
 	dump_superio_readable(port); /* TODO */

Modified: trunk/util/superiotool/nsc.c
===================================================================
--- trunk/util/superiotool/nsc.c	2007-10-07 19:10:24 UTC (rev 2834)
+++ trunk/util/superiotool/nsc.c	2007-10-07 20:01:23 UTC (rev 2835)
@@ -98,6 +98,7 @@
 
 	printf("Found NSC %s (sid=0x%02x, srid=0x%02x) at 0x%x\n",
 	       get_superio_name(reg_table, id), id, rev, port);
+	chip_found = 1;
 
 	dump_superio("NSC", reg_table, port, id);
 	if (id == 0xf1)

Modified: trunk/util/superiotool/smsc.c
===================================================================
--- trunk/util/superiotool/smsc.c	2007-10-07 19:10:24 UTC (rev 2834)
+++ trunk/util/superiotool/smsc.c	2007-10-07 20:01:23 UTC (rev 2835)
@@ -298,6 +298,7 @@
 	printf("Found %s %s (id=0x%02x, rev=0x%02x) at 0x%x\n",
 	       (id == 0x77 ? "ASUS" : "SMSC"), get_superio_name(reg_table, id),
 	       id, rev, port);
+	chip_found = 1;
 
 	dump_superio((id == 0x77 ? "ASUS" : "SMSC"), reg_table, port, id);
 	dump_superio_readable(port); /* TODO */

Modified: trunk/util/superiotool/superiotool.c
===================================================================
--- trunk/util/superiotool/superiotool.c	2007-10-07 19:10:24 UTC (rev 2834)
+++ trunk/util/superiotool/superiotool.c	2007-10-07 20:01:23 UTC (rev 2835)
@@ -25,6 +25,9 @@
 /* Command line options. */
 int dump = 0, dump_readable = 0, verbose = 0;
 
+/* Global flag which indicates whether a chip was detected at all. */
+int chip_found = 0;
+
 uint8_t regval(uint16_t port, uint8_t reg)
 {
 	outb(reg, port);
@@ -229,5 +232,8 @@
 				superio_ports_table[i].ports[j]);
 	}
 
+	if (!chip_found)
+		printf("No Super I/O found\n");
+
 	return 0;
 }

Modified: trunk/util/superiotool/superiotool.h
===================================================================
--- trunk/util/superiotool/superiotool.h	2007-10-07 19:10:24 UTC (rev 2834)
+++ trunk/util/superiotool/superiotool.h	2007-10-07 20:01:23 UTC (rev 2835)
@@ -59,6 +59,8 @@
 /* Command line parameters. */
 extern int dump, dump_readable, verbose;
 
+extern int chip_found;
+
 struct superio_registers {
 	int32_t superio_id;		/* Signed, as we need EOT. */
 	const char name[MAXNAMELEN];	/* Super I/O name */

Modified: trunk/util/superiotool/winbond.c
===================================================================
--- trunk/util/superiotool/winbond.c	2007-10-07 19:10:24 UTC (rev 2834)
+++ trunk/util/superiotool/winbond.c	2007-10-07 20:01:23 UTC (rev 2835)
@@ -313,6 +313,7 @@
 	else
 		printf("Found Winbond %s (id=0x%02x, rev=0x%02x) at 0x%x\n",
 		       get_superio_name(reg_table, id), devid, rev, port);
+	chip_found = 1;
 
 	/* TODO: Special notes in dump output for the MISC entries. */
 	dump_superio("Winbond", reg_table, port, id);




From uwe at hermann-uwe.de  Sun Oct  7 22:02:15 2007
From: uwe at hermann-uwe.de (Uwe Hermann)
Date: Sun, 7 Oct 2007 22:02:15 +0200
Subject: [LinuxBIOS] Superiotool dump for Epox 8RDA3+
In-Reply-To: <200710072035.03610.gavin@trollgod.org.uk>
References: <200710072035.03610.gavin@trollgod.org.uk>
Message-ID: <20071007200215.GJ12533@greenwood>

On Sun, Oct 07, 2007 at 08:35:03PM +0100, Gavin Kinsey wrote:
> Just noticed that superiotool now supports my board, don't know whether 
> someone has already posted a dump for this chip but another can't hurt 
> if they have so...

Yep, thanks. Added link to the wiki.


Uwe.
-- 
http://www.hermann-uwe.de  | http://www.holsham-traders.de
http://www.crazy-hacks.org | http://www.unmaintained-free-software.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20071007/2b6757a2/attachment.sig>

From idwer_v at hotmail.com  Sun Oct  7 22:02:43 2007
From: idwer_v at hotmail.com (Idwer Vollering)
Date: Sun, 7 Oct 2007 20:02:43 +0000
Subject: [LinuxBIOS] Flashrom: support for At29C010A added.
In-Reply-To: <20071007195206.GI12533@greenwood>
References: <adf480660710070422t8c12c8dv2494b148e6c85d18@mail.gmail.com>
	<20071007142009.GB12533@greenwood>
	<BLU102-W490CDC4ABE7C94EFDBDEE28BAB0@phx.gbl> 
	<20071007195206.GI12533@greenwood>
Message-ID: <BLU102-W2385718A87EA40290FFE08BAB0@phx.gbl>




> Date: Sun, 7 Oct 2007 21:52:06 +0200
> From: uwe at hermann-uwe.de
> To: idwer_v at hotmail.com
> CC: lemenkov at gmail.com; linuxbios at linuxbios.org
> Subject: Re: [LinuxBIOS] Flashrom: support for At29C010A added.
> 
> On Sun, Oct 07, 2007 at 03:50:03PM +0000, Idwer Vollering wrote:
> > Reading the content of at29c010a works (at29c010a-128BK.bios), reflashing doesn't.. maybe it is self-protected ?
> 
> Can you read/write other recognized chips on the same mainboard? If no,
> then it's quite likely to be a mainboard/chipset issue.

Yes, however i don't have a different mainboard with a non-82801 chipset (440bx / asus p2b is the mainboard i tried flashing the at29c010 on) that has a dip-socket and a supported chipset..

> 
> 
> > $ sudo ./flashrom -V -v -w at29c010a-128KB.bios
> > (..)
> > Probing for At29C010A, 128 KB
> > probe_jedec: id1 0x1f, id2 0xd5
> > AT29C010A found at physical address: 0xfffe0000
> 
> This looks good I think, the chip is recognized,
> so I guess we can commit.
> 
> 
> Uwe.
> -- 
> http://www.hermann-uwe.de  | http://www.holsham-traders.de
> http://www.crazy-hacks.org | http://www.unmaintained-free-software.org

_________________________________________________________________
Nooit meer offline met Windows Live Messenger op je mobiele telefoon
http://www.getlivemobile.nl/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20071007/a950c095/attachment.html>

From uwe at hermann-uwe.de  Sun Oct  7 22:03:26 2007
From: uwe at hermann-uwe.de (Uwe Hermann)
Date: Sun, 7 Oct 2007 22:03:26 +0200
Subject: [LinuxBIOS] [PATCH] superiotool: Make --version actually
	work	correctly
In-Reply-To: <47084C09.2080906@gmail.com>
References: <20071005174628.GA9851@greenwood> <4706B412.7080408@gmx.net>
	<20071005223006.GF7148@greenwood> <4707C902.40400@gmail.com>
	<4707CB92.6070305@gmail.com> <20071006222720.GC6227@greenwood>
	<47084C09.2080906@gmail.com>
Message-ID: <20071007200326.GK12533@greenwood>

On Sat, Oct 06, 2007 at 11:01:29PM -0400, Corey Osgood wrote:
> On another note, can we print something when superiotool is run without
> any parameters and fails to find any Super IO?

Good point, yes. Fixed in r2835.


Uwe.
-- 
http://www.hermann-uwe.de  | http://www.holsham-traders.de
http://www.crazy-hacks.org | http://www.unmaintained-free-software.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20071007/c13ab360/attachment.sig>

From idwer_v at hotmail.com  Sun Oct  7 22:09:55 2007
From: idwer_v at hotmail.com (Idwer Vollering)
Date: Sun, 7 Oct 2007 20:09:55 +0000
Subject: [LinuxBIOS] Superiotool dump for (Soltek mainboard with 82801 /
 i865 / w83627thf/thg)
Message-ID: <BLU102-W345101C146BE8D239FFE218BAB0@phx.gbl>


Probing for Winbond Super I/O (init=0x87,0x87) at 0x2e...
Found Winbond W83627THF/THG (id=0x82, rev=0x83) at 0x2e
Register dump:
idx 20 21 22 23 24 25 26 28 29 2a 2b 2c 2d 2e 2f 
val 82 83 ff fe 42 00 00 00 00 00 00 00 00 00 ff 
def 82 NA ff 00 MM 00 MM 00 00 00 MM MM MM 00 00 
LDN 0x00 (Floppy)
idx 30 60 61 70 74 f0 f1 f2 f4 f5 
val 01 03 f0 06 02 0e 00 ff 00 00 
def 01 03 f0 06 02 0e 00 ff 00 00 
LDN 0x01 (Parallel port)
idx 30 60 61 70 74 f0 
val 00 00 00 00 04 3c 
def 01 03 78 07 04 3f 
LDN 0x02 (COM1)
idx 30 60 61 70 f0 
val 01 03 f8 04 00 
def 01 03 f8 04 00 
LDN 0x03 (COM2)
idx 30 60 61 70 f0 f1 
val 01 02 f8 03 00 04 
def 01 02 f8 03 00 00 
LDN 0x05 (Keyboard)
idx 30 60 61 62 63 70 72 f0 
val 01 00 60 00 64 01 0c 42 
def 01 00 60 00 64 01 0c 80 
LDN 0x07 (GPIO 1, GPIO 5, game port, MIDI port)
idx 30 60 61 62 63 70 f0 f1 f2 f3 f4 f5 
val 00 02 01 03 30 09 ff ff ff ff ff ff 
def 00 02 01 03 30 09 ff 00 00 ff 00 00 
LDN 0x08 (GPIO 2)
idx 30 f0 f1 f2 f3 f4 f5 f6 f7 
val 00 ff ff ff 00 ff 40 00 00 
def 00 ff 00 00 00 RR 00 00 00 
LDN 0x09 (GPIO 3, GPIO 4)
idx 30 f0 f1 f2 f3 f4 f5 f6 
val 00 ff ff ff 00 ff ff ff 
def 00 ff 00 00 00 ff 00 00 
LDN 0x0a (ACPI)
idx 30 70 e0 e1 e2 e3 e4 e5 e6 e7 f0 f1 f3 f4 f6 f7 f9 fe ff 
val 00 00 00 00 00 6f 10 00 00 00 00 8f 37 00 00 00 00 00 00 
def 00 00 00 00 MM MM 00 00 00 00 00 00 00 00 00 00 00 RR RR 
LDN 0x0b (Hardware monitor)
idx 30 60 61 70 
val 01 02 90 00 
def 00 00 00 00 
No human-readable dump available for this Super I/O


_________________________________________________________________
Probeer Live.nl 
Probeer Live.nl: zoekmachine van de makers van MSN! 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20071007/c8b74f3e/attachment.html>

From info at coresystems.de  Sun Oct  7 22:47:46 2007
From: info at coresystems.de (LinuxBIOS information)
Date: Sun, 07 Oct 2007 22:47:46 +0200
Subject: [LinuxBIOS] r2834 build service
Message-ID: <E1Ied2Q-0001LG-FF@khepri.openbios.org>

Dear LinuxBIOS readers!

This is the automated build check service of LinuxBIOS.

The developer "uwe" checked in revision 2834 to
the LinuxBIOS source repository and caused the following 
changes:

Change Log:
Add a list of contributors to the README (trivial). Also, a small hint
about where to send additional register dumps.

Signed-off-by: Uwe Hermann <uwe at hermann-uwe.de>
Acked-by: Uwe Hermann <uwe at hermann-uwe.de>



Build Log:
Compilation of arima:hdama is still broken
See the error log at http://qa.linuxbios.org/log_buildbrd.php?revision=2834&device=hdama&vendor=arima
Compilation of ibm:e325 is still broken
See the error log at http://qa.linuxbios.org/log_buildbrd.php?revision=2834&device=e325&vendor=ibm
Compilation of ibm:e326 is still broken
See the error log at http://qa.linuxbios.org/log_buildbrd.php?revision=2834&device=e326&vendor=ibm
Compilation of iei:juki-511p is still broken
See the error log at http://qa.linuxbios.org/log_buildbrd.php?revision=2834&device=juki-511p&vendor=iei
Compilation of iwill:dk8s2 is still broken
See the error log at http://qa.linuxbios.org/log_buildbrd.php?revision=2834&device=dk8s2&vendor=iwill
Compilation of iwill:dk8x is still broken
See the error log at http://qa.linuxbios.org/log_buildbrd.php?revision=2834&device=dk8x&vendor=iwill
Compilation of newisys:khepri is still broken
See the error log at http://qa.linuxbios.org/log_buildbrd.php?revision=2834&device=khepri&vendor=newisys


If something broke during this checkin please be a pain 
in uwe's neck until the issue is fixed.

If this issue is not fixed within