From libv at skynet.be  Sun Jun  1 11:10:40 2008
From: libv at skynet.be (Luc Verhaegen)
Date: Sun, 1 Jun 2008 11:10:40 +0200
Subject: [coreboot] [flashrom] support for delta mp2-bx-x motherboard
	(tested)
In-Reply-To: <483E7022.9090903@icyb.net.ua>
References: <482B4BDC.4070308@icyb.net.ua> <482BA0AD.8070108@gmx.net>
	<482BF916.2050601@icyb.net.ua>
	<482C0F52.6030604@coresystems.de> <482D4557.60301@icyb.net.ua>
	<482E173D.20306@gmx.net> <483E7022.9090903@icyb.net.ua>
Message-ID: <20080601091040.GA19728@skynet.be>

On Thu, May 29, 2008 at 11:58:10AM +0300, Andriy Gapon wrote:

> This board can not be uniquely identified by PCI devices, all of them
> are part of 440BX/PIIX4E chipset.

>  	 "artecgroup", "dbe62", "Artec Group DBE62", board_artecgroup_dbe6x},
>   	{0x8086, 0x27b8, 0x0000, 0x0000, 0x0000, 0x0000, 0x0000, 0x0000,
>   	 "kontron", "986lcd-m", "Kontron 986LCD-M", board_kontron_986lcd_m},
> +	{0x8086, 0x7113, 0x0000, 0x0000, 0x0000, 0x0000, 0x0000, 0x0000,
> +	 "delta", "mp2-bx-x", "Delta MP2-BX-X", board_mp2_bx_x},
>  	{0, 0, 0, 0, 0, 0, 0, 0, NULL, NULL}	/* Keep this */
>  };
>  

I see a lot of 0's in the pci-id list, same for the kontron board.

Surely at least one other set of main device ids can be put in there. 
Due to the lack of subsystem ids this will not give you unique 
identification, but this will provide an additional safeguard.

For the recent kontron board, though, nothing less than a full set seems 
acceptable. Unless kontron, as an embedded vendor, couldn't be bothered 
with card ids as usual.

Luc Verhaegen.
SUSE/Novell X Driver Developer.



From c-d.hailfinger.devel.2006 at gmx.net  Sun Jun  1 16:14:59 2008
From: c-d.hailfinger.devel.2006 at gmx.net (Carl-Daniel Hailfinger)
Date: Sun, 01 Jun 2008 16:14:59 +0200
Subject: [coreboot] [flashrom] flashrom problem: will not flash on
 compaq/deskpro Deskpro EN SFF P600. "ERASE FAILED @237568,
 val 60!" My box is doomed to be bricked :-(
In-Reply-To: <4841D018.2050701@openhardware.de>
References: <4841D018.2050701@openhardware.de>
Message-ID: <4842AEE3.30101@gmx.net>

Hi all,

[Ludwig: can you please subscribe to the coreboot list? We can continue
working on your problem there.]

IIRC Uwe has been working with the mainboard mentioned below. Could you
please take a look?

Regards,
Carl-Daniel

On 01.06.2008 00:24, Ludwig Jaffe wrote:
> Hi Having the Deskpro EN SFF P600. abused as poor mans webservers,
> I was anoyed by the compaq-bios requiring a kbd to boot. even in
> "server-mode"
> Now having build a rom, I am little bit frustrated on programming the
> flash.
> Because if one has a programmer one has to de-solder the flash,
> because there is *no*
> socket. If one desolders one can also use a bigger flash, not having
> to fiddle around with filo-features
> just to get it fit (usb has to stay out)
>
> Now my machine is doomed to be bricked as soon as power fails :-(((
> Would be nice if you can resolve the problem.
>
> Here is the program output:
>
>
> ./flashrom  -w coreboot.rom
> Calibrating delay loop... OK.
> No coreboot table found.
> Found chipset "Intel PIIX4/4E/4M", enabling flash write... OK.
> Found chip "ST M29F002T/NT" (256 KB) at physical address 0xfffc0000.
> ===
> This flash part has status UNTESTED for operations: PROBE READ ERASE
> WRITE
> Please email a report to flashrom at coreboot.org if any of the above
> operations
> work correctly for you with this flash part. Please include the full
> output
> from the program, including chipset found. Thank you for your help!
> ===
> Note: If the following flash access fails, you might need to specify
> -m <vendor>:<mainboard>.
> ERASE FAILED @237568, val 60!
>
>
>
>
> -- 
> ./flashrom -V -w coreboot.rom >flash.txt
>
> Calibrating delay loop... 165M loops per second. OK.
> No coreboot table found.
> Found chipset "Intel PIIX4/4E/4M", enabling flash write... OK.
> Probing for AMD Am29F016D, 2048 KB: probe_29f040b: id1 0xff, id2 0xff
> Probing for AMD Am29F040B, 512 KB: probe_29f040b: id1 0x20, id2 0xb0
> Probing for AMD Am29LV040B, 512 KB: probe_29f040b: id1 0x20, id2 0xb0
> Probing for ASD AE49F2008, 256 KB: probe_jedec: id1 0x20, id2 0xb0
> Probing for Atmel AT29C020, 256 KB: probe_jedec: id1 0x20, id2 0xb0
> Probing for Atmel AT29C040A, 512 KB: probe_jedec: id1 0x20, id2 0xb0
> Probing for Atmel AT49F002(N), 256 KB: probe_jedec: id1 0x20, id2 0xb0
> Probing for Atmel AT49F002(N)T, 256 KB: probe_jedec: id1 0x20, id2 0xb0
> Probing for Atmel AT25DF321, 4096 KB: spi_command called, but no SPI
> chipset detected
> Probing for Amic Technology A25L40P, 512 KB: spi_command called, but
> no SPI chipset detected
> Probing for EMST F49B002UA, 256 KB: probe_jedec: id1 0x20, id2 0xb0
> Probing for EON EN29F002(A)(N)B, 256 KB: probe_jedec: id1 0x20, id2 0xb0
> Probing for EON EN29F002(A)(N)T, 256 KB: probe_jedec: id1 0x20, id2 0xb0
> Probing for Fujitsu MBM29F400TC, 512 KB: probe_m29f400bt: id1 0xff,
> id2 0xff
> Probing for Intel 82802AB, 512 KB: probe_82802ab: id1 0xff, id2 0xff
> Probing for Intel 82802AC, 1024 KB: probe_82802ab: id1 0xff, id2 0xff
> Probing for Macronix MX25L4005, 512 KB: spi_command called, but no SPI
> chipset detected
> Probing for Macronix MX25L8005, 1024 KB: spi_command called, but no
> SPI chipset detected
> Probing for Macronix MX25L1605, 2048 KB: spi_command called, but no
> SPI chipset detected
> Probing for Macronix MX25L3205, 4096 KB: spi_command called, but no
> SPI chipset detected
> Probing for Macronix MX29F002, 256 KB: probe_29f002: id1 0x20, id2 0xb0
> Probing for PMC Pm25LV010, 128 KB: spi_command called, but no SPI
> chipset detected
> Probing for PMC Pm25LV016B, 2048 KB: spi_command called, but no SPI
> chipset detected
> Probing for PMC Pm25LV020, 256 KB: spi_command called, but no SPI
> chipset detected
> Probing for PMC Pm25LV040, 512 KB: spi_command called, but no SPI
> chipset detected
> Probing for PMC Pm25LV080B, 1024 KB: spi_command called, but no SPI
> chipset detected
> Probing for PMC Pm25LV512, 64 KB: spi_command called, but no SPI
> chipset detected
> Probing for PMC Pm49FL002, 256 KB: probe_jedec: id1 0x20, id2 0xb0
> Probing for PMC Pm49FL004, 512 KB: probe_jedec: id1 0x20, id2 0xb0
> Probing for Sharp LHF00L04, 1024 KB: probe_lhf00l04: id1 0xff, id2 0xff
> Probing for Spansion S25FL016A, 2048 KB: spi_command called, but no
> SPI chipset detected
> Probing for SST SST25VF016B, 2048 KB: spi_command called, but no SPI
> chipset detected
> Probing for SST SST25VF040B, 512 KB: spi_command called, but no SPI
> chipset detected
> Probing for SST SST28SF040A, 512 KB: probe_28sf040: id1 0xff, id2 0xff
> Probing for SST SST29EE010, 128 KB: probe_jedec: id1 0x20, id2 0xb0
> Probing for SST SST29LE010, 128 KB: probe_jedec: id1 0x20, id2 0xb0
> Probing for SST SST29EE020A, 256 KB: probe_jedec: id1 0x20, id2 0xb0
> Probing for SST SST29LE020, 256 KB: probe_jedec: id1 0x20, id2 0xb0
> Probing for SST SST39SF010A, 128 KB: probe_jedec: id1 0x20, id2 0xb0
> Probing for SST SST39SF020A, 256 KB: probe_jedec: id1 0x20, id2 0xb0
> Probing for SST SST39SF040, 512 KB: probe_jedec: id1 0x20, id2 0xb0
> Probing for SST SST39VF512, 64 KB: probe_jedec: id1 0x20, id2 0xb0
> Probing for SST SST39VF010, 128 KB: probe_jedec: id1 0x20, id2 0xb0
> Probing for SST SST39VF020, 256 KB: probe_jedec: id1 0x20, id2 0xb0
> Probing for SST SST39VF040, 512 KB: probe_jedec: id1 0x20, id2 0xb0
> Probing for SST SST49LF002A/B, 256 KB: probe_jedec: id1 0x20, id2 0xb0
> Probing for SST SST49LF003A/B, 384 KB: probe_jedec: id1 0x20, id2 0xb0
> Probing for SST SST49LF004A/B, 512 KB: probe_jedec: id1 0x20, id2 0xb0
> Probing for SST SST49LF004C, 512 KB: probe_49lfxxxc: id1 0xff, id2 0xff
> Probing for SST SST49LF008A, 1024 KB: probe_jedec: id1 0x20, id2 0xb0
> Probing for SST SST49LF008C, 1024 KB: probe_49lfxxxc: id1 0xff, id2 0xff
> Probing for SST SST49LF016C, 2048 KB: probe_49lfxxxc: id1 0xff, id2 0xff
> Probing for SST SST49LF020A, 256 KB: probe_jedec: id1 0x20, id2 0xb0
> Probing for SST SST49LF040, 512 KB: probe_jedec: id1 0x20, id2 0xb0
> Probing for SST SST49LF040B, 512 KB: probe_jedec: id1 0x20, id2 0xb0
> Probing for SST SST49LF080A, 1024 KB: probe_jedec: id1 0x20, id2 0xb0
> Probing for SST SST49LF160C, 2048 KB: probe_49lfxxxc: id1 0xff, id2 0xff
> Probing for ST M25P05-A, 64 KB: spi_command called, but no SPI chipset
> detected
> Probing for ST M25P10-A, 128 KB: spi_command called, but no SPI
> chipset detected
> Probing for ST M25P20, 256 KB: spi_command called, but no SPI chipset
> detected
> Probing for ST M25P40, 512 KB: spi_command called, but no SPI chipset
> detected
> Probing for ST M25P40-old, 512 KB: spi_command called, but no SPI
> chipset detected
> Probing for ST M25P80, 1024 KB: spi_command called, but no SPI chipset
> detected
> Probing for ST M25P16, 2048 KB: spi_command called, but no SPI chipset
> detected
> Probing for ST M25P32, 4096 KB: spi_command called, but no SPI chipset
> detected
> Probing for ST M25P64, 8192 KB: spi_command called, but no SPI chipset
> detected
> Probing for ST M25P128, 16384 KB: spi_command called, but no SPI
> chipset detected
> Probing for ST M29F002B, 256 KB: probe_jedec: id1 0x20, id2 0xb0
> Probing for ST M29F002T/NT, 256 KB: probe_jedec: id1 0x20, id2 0xb0
> Found chip "ST M29F002T/NT" (256 KB) at physical address 0xfffc0000.
> Probing for ST M29F040B, 512 KB: probe_29f040b: id1 0x20, id2 0xb0
> Probing for ST M29F400BT, 512 KB: probe_m29f400bt: id1 0xff, id2 0xff
> Probing for ST M29W010B, 128 KB: probe_jedec: id1 0x20, id2 0xb0
> Probing for ST M29W040B, 512 KB: probe_jedec: id1 0x20, id2 0xb0
> Probing for ST M50FLW040A, 512 KB: probe_stm50flw0x0x: id1 0x20, id2 0xb0
> Probing for ST M50FLW040B, 512 KB: probe_stm50flw0x0x: id1 0x20, id2 0xb0
> Probing for ST M50FLW080A, 1024 KB: probe_stm50flw0x0x: id1 0x20, id2
> 0xb0
> Probing for ST M50FLW080B, 1024 KB: probe_stm50flw0x0x: id1 0x20, id2
> 0xb0
> Probing for ST M50FW016, 2048 KB: probe_82802ab: id1 0xff, id2 0xff
> Probing for ST M50FW040, 512 KB: probe_82802ab: id1 0xff, id2 0xff
> Probing for ST M50FW080, 1024 KB: probe_82802ab: id1 0xff, id2 0xff
> Probing for ST M50LPW116, 2048 KB: probe_jedec: id1 0xff, id2 0xff,
> id1 parity violation
> Probing for SyncMOS S29C31004T, 512 KB: probe_jedec: id1 0x20, id2 0xb0
> Probing for SyncMOS S29C51001T, 128 KB: probe_jedec: id1 0x20, id2 0xb0
> Probing for SyncMOS S29C51002T, 256 KB: probe_jedec: id1 0x20, id2 0xb0
> Probing for SyncMOS S29C51004T, 512 KB: probe_jedec: id1 0x20, id2 0xb0
> Probing for Winbond W25x10, 128 KB: spi_command called, but no SPI
> chipset detected
> Probing for Winbond W25x20, 256 KB: spi_command called, but no SPI
> chipset detected
> Probing for Winbond W25x40, 512 KB: spi_command called, but no SPI
> chipset detected
> Probing for Winbond W25x80, 1024 KB: spi_command called, but no SPI
> chipset detected
> Probing for Winbond W29C011, 128 KB: probe_jedec: id1 0x20, id2 0xb0
> Probing for Winbond W29C020C, 256 KB: probe_jedec: id1 0x20, id2 0xb0
> Probing for Winbond W29C040P, 512 KB: probe_jedec: id1 0x20, id2 0xb0
> Probing for Winbond W29EE011, 128 KB: probe_w29ee011: id1 0xff, id2 0xff
> Probing for Winbond W39V040A, 512 KB: probe_jedec: id1 0x20, id2 0xb0
> Probing for Winbond W39V040B, 512 KB: probe_jedec: id1 0x20, id2 0xb0
> Probing for Winbond W39V040FA, 512 KB: probe_jedec: id1 0x20, id2 0xb0
> Probing for Winbond W39V080A, 1024 KB: probe_jedec: id1 0x20, id2 0xb0
> Probing for Winbond W49F002U, 256 KB: probe_jedec: id1 0x20, id2 0xb0
> Probing for Winbond W49V002A, 256 KB: probe_jedec: id1 0x20, id2 0xb0
> Probing for Winbond W49V002FA, 256 KB: probe_jedec: id1 0x20, id2 0xb0
> Probing for Winbond W39V080FA, 1024 KB: probe_winbond_fwhub: vid 0x20,
> did 0xb0
> Probing for Winbond W39V080FA (dual mode), 512 KB:
> probe_winbond_fwhub: vid 0x20, did 0xb0
> Probing for EON unknown EON SPI chip, 0 KB: spi_command called, but no
> SPI chipset detected
> Probing for Macronix unknown Macronix SPI chip, 0 KB: spi_command
> called, but no SPI chipset detected
> Probing for PMC unknown PMC SPI chip, 0 KB: spi_command called, but no
> SPI chipset detected
> Probing for SST unknown SST SPI chip, 0 KB: spi_command called, but no
> SPI chipset detected
> Probing for ST unknown ST SPI chip, 0 KB: spi_command called, but no
> SPI chipset detected
> ===
> This flash part has status UNTESTED for operations: PROBE READ ERASE
> WRITE
> Please email a report to flashrom at coreboot.org if any of the above
> operations
> work correctly for you with this flash part. Please include the full
> output
> from the program, including chipset found. Thank you for your help!
> ===
> coreboot last image size (not ROM size) is 131072 bytes.
> Manufacturer: Compaq
> Mainboard ID: Deskpro EN SFF P600
> Note: If the following flash access fails, you might need to specify
> -m <vendor>:<mainboard>.
> ERASE FAILED @237568, val 60!
>
> -
> Why should I give the vendor and board if it was detected correctly?
>
>
> Thanks for your help
>
> LuJa
>
>


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




From luja at openhardware.de  Sun Jun  1 17:06:41 2008
From: luja at openhardware.de (Ludwig Jaffe)
Date: Sun, 01 Jun 2008 17:06:41 +0200
Subject: [coreboot] [Fwd: Re: [flashrom] flashrom problem: will not flash on
 compaq/deskpro Deskpro EN SFF P600. "ERASE FAILED @237568,
 val 60!" My box is doomed to be bricked :-(]
Message-ID: <4842BB01.2090405@openhardware.de>


-------------- next part --------------
An embedded message was scrubbed...
From: Ludwig Jaffe <luja at openhardware.de>
Subject: Re: [flashrom] flashrom problem: will not flash on compaq/deskpro Deskpro EN SFF P600. "ERASE FAILED @237568, val 60!" My box is doomed to be bricked :-(
Date: Sun, 01 Jun 2008 16:59:56 +0200
Size: 31936
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20080601/db664054/attachment.eml>

From tiagomnm at gmail.com  Sun Jun  1 17:09:07 2008
From: tiagomnm at gmail.com (Tiago Marques)
Date: Sun, 1 Jun 2008 16:09:07 +0100
Subject: [coreboot] flashrom verify fails, CK804, MCP55
In-Reply-To: <47AC6B27.6040708@gmx.net>
References: <b1335fe90801270721i49a29a58v6ee03b9d5a9037f0@mail.gmail.com>
	<20080127160652.GA21535@coresystems.de>
	<b1335fe90801271006h35de2c71vc3bc6ab13ab39a02@mail.gmail.com>
	<b1335fe90801271006m63b7e884h2440d1d1bb5aa614@mail.gmail.com>
	<20080127181124.GA23002@localdomain>
	<b1335fe90801271119h5af39e2el388df1785d21e015@mail.gmail.com>
	<20080127194808.GA23518@localdomain>
	<b1335fe90801271233p149cccc9k3a60f165ab01fe0c@mail.gmail.com>
	<b1335fe90801290959r6f65c208na74badb4dac9aa@mail.gmail.com>
	<47AC6B27.6040708@gmx.net>
Message-ID: <b1335fe90806010809r3eadbf71lb17ab1126906cc7d@mail.gmail.com>

Finally had some time to test this.
The erase command does nothing, I was still able to download the full
BIOS and boot the machine. This using the latest flashrom revision.
First step is to make it erase? Where should I start?

Best regards


On 2/8/08, Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006 at gmx.net> wrote:
> On 29.01.2008 18:59, Tiago Marques wrote:
>  > Any ideas? From where should I start?
>  >
>
>
> Try to erase a chip with "flashrom -E" (just erase, no write, no verify)
>  and then read back the contents with "flashrom -r". Look at the
>  resulting file with xxd or hexdump and check if it is all 0xff.
>  I suspect that it will not be all 0xff when erased in the problematic
>  boards, but it will be all 0xff when erased in the K8T890 board.
>
>  Regards,
>  Carl-Daniel
>
>
>  --
>  http://www.hailfinger.org/
>
>



From luja at openhardware.de  Sun Jun  1 17:19:10 2008
From: luja at openhardware.de (Ludwig Jaffe)
Date: Sun, 01 Jun 2008 17:19:10 +0200
Subject: [coreboot] flashrom patch for little improvement with st 29F002BT
Message-ID: <4842BDEE.2000706@openhardware.de>

Hello,
while fixing the dangerous situation for my boxes I made little 
improvements to
flashrom.
It is still impossible to flash ST 29F002BT because unprotecting does 
not work for now.
But read/write/probe does.


Greetings

LuJa

-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: flashrom.patch
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20080601/c8254841/attachment.ksh>

From c-d.hailfinger.devel.2006 at gmx.net  Sun Jun  1 17:45:00 2008
From: c-d.hailfinger.devel.2006 at gmx.net (Carl-Daniel Hailfinger)
Date: Sun, 01 Jun 2008 17:45:00 +0200
Subject: [coreboot] LinuxTag 2008 Status
In-Reply-To: <1212091343.7391.49.camel@mattotaupa.wohnung.familie-menzel.net>
References: <e0232121f7eded9ae0d225494504aff1@imap.1and1.com>
	<1212091343.7391.49.camel@mattotaupa.wohnung.familie-menzel.net>
Message-ID: <4842C3FC.8050508@gmx.net>

Hi all,

On 29.05.2008 22:02, Paul Menzel wrote:
> Am Donnerstag, den 29.05.2008, 13:39 -0400 schrieb Joseph Smith:
>   
>> How is LinuxTag 2008 going Peter, Paul, and Carl-Daniel?
>>     
>
> Pierre, who offered his help with the booth and is considered a spammer
> by trac, is also presenting coreboot.
>   

We were a team of four for most of the time. Thanks again to Paul and
Pierre for helping us out, they were a pleasure to work with! There was
some sort of "collateral damage", though: I believe Paul and Pierre now
know a lot more about coreboot. ;-)



>> Are you getting alot of people excited about coreboot?
>>     
>
> So I will try to give a quick summary of the first two days. I was there
> about 70 % of it.
>
> - Peter is talking a lot to people. As evidence he is gravelly.
> Especially after the workshop/talk he gave today.
>   

His voice recovered. Sort of.


> I would guess that we talk to about 4?6 people in an hour. But since we
> are talking to them about 10 minutes the booth is busy most of the time
> and it would be rather crowded if more people are there.

To be honest, we could have talked to more people if we had been given
more than 2 m^2 booth space with the space available for presentation in
front being 1 m wide.


> There knowledge on coreboot varies. Even more because
> of the name change early this year.

I had multiple companies/public sector institutions tell me to not
bother telling them about coreboot because "we are already investigating
LinuxBIOS". When I pointed out the recent name change, they invariably
asked why we didn't advertise the old name on our flyers/posters as
well. I then pointed out the difficulties we had with "Linux" and "BIOS"
in the name and they understood that. Still, I'd like to keep the old
name around for some time to come, at least on posters (smaller font etc.).


> Some people have already seen the project last year and have quiet some
> knowledge about the hardware. Then I need the help from Peter.
>   

To be honest, Paul is a very fast learner and answered even difficult
questions about hardware support and architecture and he covered the
booth alone for extended periods of time.


> 2. Another guy was thinking about a NAS-Device with a Celeron processor.
> But he will come back some other time, because Peter or Carl-Daniel were
> busy with the workshop then.
>   

That actually sort of worked out. This person will join the list and
inquire further.


> - Although the booth is small and there is not enough room that more
> than four people have room around the booth, I believe that a lot of
> people are passing by, because their are just two bare boards sitting on
> the table and the monitor is displaying a ncurses-menu. The poster has
> also only coreboot on it. So we do not have a real eye-catcher. Maybe we
> should hack a screensaver payload which just displays ?Want to boot
> faster??, ?Free your BIOS?? and so on in big ASCII on the monitor or
> write it on the poster.
>   

We need to capitalize further on our instant boot ability. It was the
feature that impressed people the most. It was also a much-praised
feature in the radio interview I did on Friday. The interviewer said
that living directly below the roof in summer was only bearable if one
could turn the computers off to reduce heating and get instant boot on
demand.


> When they see the demonstration, they are a little bit more excited. And
> some even want to take a deeper look at it.
>   

Indeed.


> There are also not so many business guys running around?especially no
> mainboard vendors. So I guess the main objective is, to make coreboot
> more known to the world and probably attract some potential developers.
>   

To be honest, a quite sizable percentage of people stopping by our booth
were developers exhibiting with other projects, so I'd say we got some
opinion leaders interested.


> If you have some more marketing ideas or objectives, please tell me/us.
>
> - Each of Peter (English) and Carl-Daniel (German) gave a talk/workshop
> on flashrom today. I listened to the one of Carl-Daniel and there were
> about 15 people.
>   

Yes, the turnout was way lower than expected, probably due to the fact
that even we as speakers were having difficulties finding the room. The
only advertisements for the workshops I could find were directly in
front of the rooms where the workshops happened, and these rooms were on
floors where nothing else happened.

Advice for anybody considering a speaking/tutorial engagement at next
year's LinuxTag: Submit a talk+paper and don't bother with workshops.


> - Carl-Daniel arrived today. But it looks like he left his alix1c board
> in the cardboard in the workshop room and it was not there anymore when
> we came back. Hopefully we will find it or the one who took it brings it
> to the lost-and-found office, because that was the only presentation
> board, when Peter is leaving tomorrow. And Carl-Daniel is going to have
> a workshop with this board on Saturday.
>   

The board was recovered on Saturday evening. Someone had picked it up
and threw it over the walls of the locked back room of our booth. Thanks
to that anonymous kind finder.

And Peter's flight was overbooked, so he had to stay in Berlin. That way
we could handle the coreboot workshop together. Thanks, Peter!
By the way, the coreboot workshop had even less attendance (~8 persons)
than the flashrom workshop, but at least one person brought a board,
although that board was unsupported (alix.2c2). The great thing is that
we got coreboot to run mostly fine, just some interrupts seemed to be
screwed. Still, that person is going to join the list and probably work
on finishing the port.


Regards,
Carl-Daniel



From luja at openhardware.de  Sun Jun  1 17:50:04 2008
From: luja at openhardware.de (Ludwig Jaffe)
Date: Sun, 01 Jun 2008 17:50:04 +0200
Subject: [coreboot] Unprotecting 29F002BT
Message-ID: <4842C52C.7050607@openhardware.de>

Hi,

looking for the unprotect-algorithm I found the AN1122 from ST.
The figure 4 shows a way to do this, but, how do we put VID=12V to Pin#1?
Does anybody know how this is done or if we should use the 
programmer-mode/way instaed of insystem/mode/way?

Thanks for your comments.

Attached the application-note, and the datasheet of st29F002B series.


Greetings

LuJa


-------------- next part --------------
A non-text attachment was scrubbed...
Name: 29f002.pdf
Type: application/pdf
Size: 214417 bytes
Desc: not available
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20080601/3860a0ed/attachment.pdf>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: an1121.pdf
Type: application/pdf
Size: 98941 bytes
Desc: not available
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20080601/3860a0ed/attachment-0001.pdf>

From c-d.hailfinger.devel.2006 at gmx.net  Sun Jun  1 17:48:16 2008
From: c-d.hailfinger.devel.2006 at gmx.net (Carl-Daniel Hailfinger)
Date: Sun, 01 Jun 2008 17:48:16 +0200
Subject: [coreboot] LinuxTag 2008 Status
In-Reply-To: <20080530204441.GA14200@cosmic.amd.com>
References: <e0232121f7eded9ae0d225494504aff1@imap.1and1.com>	<1212091343.7391.49.camel@mattotaupa.wohnung.familie-menzel.net>	<13426df10805291458i3990273aleb91978bb3911730@mail.gmail.com>
	<20080530204441.GA14200@cosmic.amd.com>
Message-ID: <4842C4C0.8060303@gmx.net>

On 30.05.2008 22:44, Jordan Crouse wrote:
> On 29/05/08 14:58 -0700, ron minnich wrote:
>   
>> Wow, wonderful job to all at LInuxTag! Thanks to you all!
>>
>> I just ran the bayou demo and it is really impressive. I wonder if
>> there is anything else like it? It's really neat.
>>     
>
> Thanks.  There is still much to be done, but I think this is a pretty
> good start.. :) To that end, let me solicit the help of the community to
> think about the next step. 
>
> As a group we have identified two main behaviors for the chooser:
>
>  * An interactive menu
>  * Chaining (running one payload after another in the fashion of a 
>  traditional BIOS)
>   

Absolutely.

> But when you look closer, the number of possible modes explodes.  As an
> example:
>
>  - You may want to add a timeout to the menu, so that if somebody doesn't
>  press the hotkey, a default payload is chosen.
>   

Reasonable.

>  - When chaining, some payloads will be opt in (press F1 for setup), some
>  will be opt out (press F2 to skip), and others will always run
>   

Reasonable as well.

>  - Uwe expressed a desire to select a chain from the menu
>   

No offense, but IMHO that is a bit overboard.

> Everything is further complicated by the fact that we can add a new payload
> to the LAR at any time, which makes it very difficult to specific the
> configuration at bayou compile time.
>   

Maybe just store a default configuration at compile time and retrieve
settings from NVRAM or from a continuously-changing zone in flash?

> So, this is a very long and complex way of saying that we need a simple
> yet clever way to configure bayou that takes into account all of the
> above.  Any ideas?
>   

See above.

Regards,
Carl-Daniel



From qchwu at 163.com  Mon Jun  2 11:34:10 2008
From: qchwu at 163.com (qchwu)
Date: Mon, 2 Jun 2008 17:34:10 +0800 (CST)
Subject: [coreboot] buildrom
Message-ID: <4843BE92.0001D1.00883@bj163app6.163.com>

I build a rom for ADM DB800. One error appear as following:

[root at localhost buildrom-devel]# make
Unpacking mkelfimage...
Patching mkelfimage...
Applying patch mkelfImage-2.7-x86_64.patch
Applying patch mkelfimage-autoconf.patch
Now at patch mkelfimage-autoconf.patch
Building mkelfImage...
Building unifdef (host)...
Building lzma...
Unpacking kernel (2.6.20.2)...
Patching kernel...
Building kernel...
Installing kernel headers...
Building the ELF payload...
Compressing the ELF payload with lzma...
******************
Payload takes 1508825 Bytes (1473 KBytes) in ROM:
******************
Unpacking coreboot (coreboot-svn-3335.tar.gz)...
Patching coreboot...
Building target...
/bin/sh: line 0: cd: /bios/buildrom/buildrom-devel/work/coreboot/svn/targets/: ?????????
make: *** [/bios/buildrom/buildrom-devel/work/coreboot/stamps/.configured-db800] ?? 127
[root at localhost buildrom-devel]# 

How can i clear this error?

My gcc'version is 4.2.2.
kernel'version is 2.6.18
make'version is 3.81

thanks!
chenghu


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

From luja at openhardware.de  Sun Jun  1 16:59:56 2008
From: luja at openhardware.de (Ludwig Jaffe)
Date: Sun, 01 Jun 2008 16:59:56 +0200
Subject: [coreboot] [flashrom] flashrom problem: will not flash on
 compaq/deskpro Deskpro EN SFF P600. "ERASE FAILED @237568,
 val 60!" My box is doomed to be bricked :-(
In-Reply-To: <4842AEE3.30101@gmx.net>
References: <4841D018.2050701@openhardware.de> <4842AEE3.30101@gmx.net>
Message-ID: <4842B96C.4030308@openhardware.de>

Hi all,

i fiddled around with the flashrom util, and I managed to rewrite the 
original compaq-bios, which I saved before.
I modified the flashrom-utily to enable writing the flashrom. The 
29F002BT works with 29f002-funktions and *not* with jedec....
The only problem that remains, is that it is not possible to unprotect 
the 20f002bt (ST). with the flashrom utily. So I can not upgrade the flash!
I will go and code some improvement to that.

A suggestion regarding architecture:


struct flashchip flashchips[] = {
        
/**********************************************************************************************************************************************************************************************************************/
        /* Vendor       Chip                    Vendor ID       Chip 
ID                 TODO    TODO            Test status     Probe 
function          Erase function                  Write 
function          Read function */
        
/**********************************************************************************************************************************************************************************************************************/
        {"AMD",         "Am29F016D",            AMD_ID,         
AM_29F016D,             2048,   64 * 1024,      TEST_UNTESTED,  
probe_29f040b,          erase_29f040b,                  write_29f040b},
        {"AMD",         "Am29F040B",            AMD_ID,         
AM_29F040B,             512,    64 * 1024,      TEST_OK_PREW,   
probe_29f040b,          erase_29f040b,                  write_29f040b},
        {"AMD",         "Am29LV040B",           AMD_ID,         
AM_29LV040B,            512,    64 * 1024,      TEST_UNTESTED,  
probe_29f040b,          erase_29f040b,                  write_29f040b},
        {"ASD",         "AE49F2008",            ASD_ID,         
ASD_AE49F2008,          256,    128,            TEST_UNTESTED,  
probe_jedec,            erase_chip_jedec,               write_jedec},
        {"Atmel",       "AT29C020",             ATMEL_ID,       
AT_29C020,              256,    256,            TEST_UNTESTED,  
probe_jedec,            erase_chip_jedec,               write_jedec},
        {"Atmel",       "AT29C040A",            ATMEL_ID,       
AT_29C040A,             512,    256,            TEST_UNTESTED,  
probe_jedec,            erase_chip_jedec,               write_jedec},
        {"Atmel",       "AT49F002(N)",          ATMEL_ID,       
AT_49F002N,             256,    256,            TEST_UNTESTED,  
probe_jedec,            erase_chip_jedec,               write_jedec},
        {"Atmel",       "AT49F002(N)T",         ATMEL_ID,       
AT_49F002NT,            256,    256,            TEST_UNTESTED,  
probe_jedec,            erase_chip_jedec,               write_jedec},
        {"Atmel",       "AT25DF321",            ATMEL_ID,       
AT_25DF321,             4096,   256,            TEST_OK_PREW,   
probe_spi_rdid,         spi_chip_erase_c7,      spi_chip_write, 
spi_chip_read},
        {"Amic Technology","A25L40P",           AMIC_ID,        
AMIC_A25L40P,           512,    256,            TEST_UNTESTED,  
probe_spi_rdid,         spi_chip_erase_c7,      spi_chip_write, 
spi_chip_read},
        {"EMST",        "F49B002UA",            EMST_ID,        
EMST_F49B002UA,         256,    4096,           TEST_UNTESTED,  
probe_jedec,            erase_chip_jedec,               write_49f002},
        {"EON",         "EN29F002(A)(N)B",      EON_ID,         
EN_29F002B,             256,    256,            TEST_UNTESTED,  
probe_jedec,            erase_chip_jedec,               write_jedec},
        {"EON",         "EN29F002(A)(N)T",      EON_ID,         
EN_29F002T,             256,    256,            TEST_UNTESTED,  
probe_jedec,            erase_chip_jedec,               write_jedec},


        {"ST",          "M29F002BB/BNB",        ST_ID,          
ST_M29F002BB,           256,    64 * 1024,      TEST_UNTESTED,  
probe_29f002,           erase_29f002,                   write_29f002},
        {"ST",          "M29F002BT/BNT",        ST_ID,          
ST_M29F002BT,           256,    64 * 1024,      
TEST_OK_PR|TEST_BAD_ERASE,      probe_29f002,           
erase_29f002,                   write_29f002},

We should add a function-pointer for protect and unprotect, because this 
is sometimes special. e.g. 29f002bt (st).
We should provide an extra funktion to protect/unprotect the bios to the 
user, so that reweiting the eeprom will be
read() -> save old
unprotect()
test_if_unprotected()
 if not die
erase()
 test_if_empty()
 if not, try to rewrite saved_old!
 else die.
write
verify


So the methods protect/unprotect have to be seperate and not be hidden 
in erase or write functions.
And they should be accessible via the punction-pointer-table.



My patch contains my little modifications and da doxygen file to ease 
understanding the code.

Please help me to improve the architecture of flashrom.

Greetings


LuJa






Carl-Daniel Hailfinger schrieb:
> Hi all,
>
> [Ludwig: can you please subscribe to the coreboot list? We can continue
> working on your problem there.]
>
> IIRC Uwe has been working with the mainboard mentioned below. Could you
> please take a look?
>
> Regards,
> Carl-Daniel
>
> On 01.06.2008 00:24, Ludwig Jaffe wrote:
>   
>> Hi Having the Deskpro EN SFF P600. abused as poor mans webservers,
>> I was anoyed by the compaq-bios requiring a kbd to boot. even in
>> "server-mode"
>> Now having build a rom, I am little bit frustrated on programming the
>> flash.
>> Because if one has a programmer one has to de-solder the flash,
>> because there is *no*
>> socket. If one desolders one can also use a bigger flash, not having
>> to fiddle around with filo-features
>> just to get it fit (usb has to stay out)
>>
>> Now my machine is doomed to be bricked as soon as power fails :-(((
>> Would be nice if you can resolve the problem.
>>
>> Here is the program output:
>>
>>
>> ./flashrom  -w coreboot.rom
>> Calibrating delay loop... OK.
>> No coreboot table found.
>> Found chipset "Intel PIIX4/4E/4M", enabling flash write... OK.
>> Found chip "ST M29F002T/NT" (256 KB) at physical address 0xfffc0000.
>> ===
>> This flash part has status UNTESTED for operations: PROBE READ ERASE
>> WRITE
>> Please email a report to flashrom at coreboot.org if any of the above
>> operations
>> work correctly for you with this flash part. Please include the full
>> output
>> from the program, including chipset found. Thank you for your help!
>> ===
>> Note: If the following flash access fails, you might need to specify
>> -m <vendor>:<mainboard>.
>> ERASE FAILED @237568, val 60!
>>
>>
>>
>>
>> -- 
>> ./flashrom -V -w coreboot.rom >flash.txt
>>
>> Calibrating delay loop... 165M loops per second. OK.
>> No coreboot table found.
>> Found chipset "Intel PIIX4/4E/4M", enabling flash write... OK.
>> Probing for AMD Am29F016D, 2048 KB: probe_29f040b: id1 0xff, id2 0xff
>> Probing for AMD Am29F040B, 512 KB: probe_29f040b: id1 0x20, id2 0xb0
>> Probing for AMD Am29LV040B, 512 KB: probe_29f040b: id1 0x20, id2 0xb0
>> Probing for ASD AE49F2008, 256 KB: probe_jedec: id1 0x20, id2 0xb0
>> Probing for Atmel AT29C020, 256 KB: probe_jedec: id1 0x20, id2 0xb0
>> Probing for Atmel AT29C040A, 512 KB: probe_jedec: id1 0x20, id2 0xb0
>> Probing for Atmel AT49F002(N), 256 KB: probe_jedec: id1 0x20, id2 0xb0
>> Probing for Atmel AT49F002(N)T, 256 KB: probe_jedec: id1 0x20, id2 0xb0
>> Probing for Atmel AT25DF321, 4096 KB: spi_command called, but no SPI
>> chipset detected
>> Probing for Amic Technology A25L40P, 512 KB: spi_command called, but
>> no SPI chipset detected
>> Probing for EMST F49B002UA, 256 KB: probe_jedec: id1 0x20, id2 0xb0
>> Probing for EON EN29F002(A)(N)B, 256 KB: probe_jedec: id1 0x20, id2 0xb0
>> Probing for EON EN29F002(A)(N)T, 256 KB: probe_jedec: id1 0x20, id2 0xb0
>> Probing for Fujitsu MBM29F400TC, 512 KB: probe_m29f400bt: id1 0xff,
>> id2 0xff
>> Probing for Intel 82802AB, 512 KB: probe_82802ab: id1 0xff, id2 0xff
>> Probing for Intel 82802AC, 1024 KB: probe_82802ab: id1 0xff, id2 0xff
>> Probing for Macronix MX25L4005, 512 KB: spi_command called, but no SPI
>> chipset detected
>> Probing for Macronix MX25L8005, 1024 KB: spi_command called, but no
>> SPI chipset detected
>> Probing for Macronix MX25L1605, 2048 KB: spi_command called, but no
>> SPI chipset detected
>> Probing for Macronix MX25L3205, 4096 KB: spi_command called, but no
>> SPI chipset detected
>> Probing for Macronix MX29F002, 256 KB: probe_29f002: id1 0x20, id2 0xb0
>> Probing for PMC Pm25LV010, 128 KB: spi_command called, but no SPI
>> chipset detected
>> Probing for PMC Pm25LV016B, 2048 KB: spi_command called, but no SPI
>> chipset detected
>> Probing for PMC Pm25LV020, 256 KB: spi_command called, but no SPI
>> chipset detected
>> Probing for PMC Pm25LV040, 512 KB: spi_command called, but no SPI
>> chipset detected
>> Probing for PMC Pm25LV080B, 1024 KB: spi_command called, but no SPI
>> chipset detected
>> Probing for PMC Pm25LV512, 64 KB: spi_command called, but no SPI
>> chipset detected
>> Probing for PMC Pm49FL002, 256 KB: probe_jedec: id1 0x20, id2 0xb0
>> Probing for PMC Pm49FL004, 512 KB: probe_jedec: id1 0x20, id2 0xb0
>> Probing for Sharp LHF00L04, 1024 KB: probe_lhf00l04: id1 0xff, id2 0xff
>> Probing for Spansion S25FL016A, 2048 KB: spi_command called, but no
>> SPI chipset detected
>> Probing for SST SST25VF016B, 2048 KB: spi_command called, but no SPI
>> chipset detected
>> Probing for SST SST25VF040B, 512 KB: spi_command called, but no SPI
>> chipset detected
>> Probing for SST SST28SF040A, 512 KB: probe_28sf040: id1 0xff, id2 0xff
>> Probing for SST SST29EE010, 128 KB: probe_jedec: id1 0x20, id2 0xb0
>> Probing for SST SST29LE010, 128 KB: probe_jedec: id1 0x20, id2 0xb0
>> Probing for SST SST29EE020A, 256 KB: probe_jedec: id1 0x20, id2 0xb0
>> Probing for SST SST29LE020, 256 KB: probe_jedec: id1 0x20, id2 0xb0
>> Probing for SST SST39SF010A, 128 KB: probe_jedec: id1 0x20, id2 0xb0
>> Probing for SST SST39SF020A, 256 KB: probe_jedec: id1 0x20, id2 0xb0
>> Probing for SST SST39SF040, 512 KB: probe_jedec: id1 0x20, id2 0xb0
>> Probing for SST SST39VF512, 64 KB: probe_jedec: id1 0x20, id2 0xb0
>> Probing for SST SST39VF010, 128 KB: probe_jedec: id1 0x20, id2 0xb0
>> Probing for SST SST39VF020, 256 KB: probe_jedec: id1 0x20, id2 0xb0
>> Probing for SST SST39VF040, 512 KB: probe_jedec: id1 0x20, id2 0xb0
>> Probing for SST SST49LF002A/B, 256 KB: probe_jedec: id1 0x20, id2 0xb0
>> Probing for SST SST49LF003A/B, 384 KB: probe_jedec: id1 0x20, id2 0xb0
>> Probing for SST SST49LF004A/B, 512 KB: probe_jedec: id1 0x20, id2 0xb0
>> Probing for SST SST49LF004C, 512 KB: probe_49lfxxxc: id1 0xff, id2 0xff
>> Probing for SST SST49LF008A, 1024 KB: probe_jedec: id1 0x20, id2 0xb0
>> Probing for SST SST49LF008C, 1024 KB: probe_49lfxxxc: id1 0xff, id2 0xff
>> Probing for SST SST49LF016C, 2048 KB: probe_49lfxxxc: id1 0xff, id2 0xff
>> Probing for SST SST49LF020A, 256 KB: probe_jedec: id1 0x20, id2 0xb0
>> Probing for SST SST49LF040, 512 KB: probe_jedec: id1 0x20, id2 0xb0
>> Probing for SST SST49LF040B, 512 KB: probe_jedec: id1 0x20, id2 0xb0
>> Probing for SST SST49LF080A, 1024 KB: probe_jedec: id1 0x20, id2 0xb0
>> Probing for SST SST49LF160C, 2048 KB: probe_49lfxxxc: id1 0xff, id2 0xff
>> Probing for ST M25P05-A, 64 KB: spi_command called, but no SPI chipset
>> detected
>> Probing for ST M25P10-A, 128 KB: spi_command called, but no SPI
>> chipset detected
>> Probing for ST M25P20, 256 KB: spi_command called, but no SPI chipset
>> detected
>> Probing for ST M25P40, 512 KB: spi_command called, but no SPI chipset
>> detected
>> Probing for ST M25P40-old, 512 KB: spi_command called, but no SPI
>> chipset detected
>> Probing for ST M25P80, 1024 KB: spi_command called, but no SPI chipset
>> detected
>> Probing for ST M25P16, 2048 KB: spi_command called, but no SPI chipset
>> detected
>> Probing for ST M25P32, 4096 KB: spi_command called, but no SPI chipset
>> detected
>> Probing for ST M25P64, 8192 KB: spi_command called, but no SPI chipset
>> detected
>> Probing for ST M25P128, 16384 KB: spi_command called, but no SPI
>> chipset detected
>> Probing for ST M29F002B, 256 KB: probe_jedec: id1 0x20, id2 0xb0
>> Probing for ST M29F002T/NT, 256 KB: probe_jedec: id1 0x20, id2 0xb0
>> Found chip "ST M29F002T/NT" (256 KB) at physical address 0xfffc0000.
>> Probing for ST M29F040B, 512 KB: probe_29f040b: id1 0x20, id2 0xb0
>> Probing for ST M29F400BT, 512 KB: probe_m29f400bt: id1 0xff, id2 0xff
>> Probing for ST M29W010B, 128 KB: probe_jedec: id1 0x20, id2 0xb0
>> Probing for ST M29W040B, 512 KB: probe_jedec: id1 0x20, id2 0xb0
>> Probing for ST M50FLW040A, 512 KB: probe_stm50flw0x0x: id1 0x20, id2 0xb0
>> Probing for ST M50FLW040B, 512 KB: probe_stm50flw0x0x: id1 0x20, id2 0xb0
>> Probing for ST M50FLW080A, 1024 KB: probe_stm50flw0x0x: id1 0x20, id2
>> 0xb0
>> Probing for ST M50FLW080B, 1024 KB: probe_stm50flw0x0x: id1 0x20, id2
>> 0xb0
>> Probing for ST M50FW016, 2048 KB: probe_82802ab: id1 0xff, id2 0xff
>> Probing for ST M50FW040, 512 KB: probe_82802ab: id1 0xff, id2 0xff
>> Probing for ST M50FW080, 1024 KB: probe_82802ab: id1 0xff, id2 0xff
>> Probing for ST M50LPW116, 2048 KB: probe_jedec: id1 0xff, id2 0xff,
>> id1 parity violation
>> Probing for SyncMOS S29C31004T, 512 KB: probe_jedec: id1 0x20, id2 0xb0
>> Probing for SyncMOS S29C51001T, 128 KB: probe_jedec: id1 0x20, id2 0xb0
>> Probing for SyncMOS S29C51002T, 256 KB: probe_jedec: id1 0x20, id2 0xb0
>> Probing for SyncMOS S29C51004T, 512 KB: probe_jedec: id1 0x20, id2 0xb0
>> Probing for Winbond W25x10, 128 KB: spi_command called, but no SPI
>> chipset detected
>> Probing for Winbond W25x20, 256 KB: spi_command called, but no SPI
>> chipset detected
>> Probing for Winbond W25x40, 512 KB: spi_command called, but no SPI
>> chipset detected
>> Probing for Winbond W25x80, 1024 KB: spi_command called, but no SPI
>> chipset detected
>> Probing for Winbond W29C011, 128 KB: probe_jedec: id1 0x20, id2 0xb0
>> Probing for Winbond W29C020C, 256 KB: probe_jedec: id1 0x20, id2 0xb0
>> Probing for Winbond W29C040P, 512 KB: probe_jedec: id1 0x20, id2 0xb0
>> Probing for Winbond W29EE011, 128 KB: probe_w29ee011: id1 0xff, id2 0xff
>> Probing for Winbond W39V040A, 512 KB: probe_jedec: id1 0x20, id2 0xb0
>> Probing for Winbond W39V040B, 512 KB: probe_jedec: id1 0x20, id2 0xb0
>> Probing for Winbond W39V040FA, 512 KB: probe_jedec: id1 0x20, id2 0xb0
>> Probing for Winbond W39V080A, 1024 KB: probe_jedec: id1 0x20, id2 0xb0
>> Probing for Winbond W49F002U, 256 KB: probe_jedec: id1 0x20, id2 0xb0
>> Probing for Winbond W49V002A, 256 KB: probe_jedec: id1 0x20, id2 0xb0
>> Probing for Winbond W49V002FA, 256 KB: probe_jedec: id1 0x20, id2 0xb0
>> Probing for Winbond W39V080FA, 1024 KB: probe_winbond_fwhub: vid 0x20,
>> did 0xb0
>> Probing for Winbond W39V080FA (dual mode), 512 KB:
>> probe_winbond_fwhub: vid 0x20, did 0xb0
>> Probing for EON unknown EON SPI chip, 0 KB: spi_command called, but no
>> SPI chipset detected
>> Probing for Macronix unknown Macronix SPI chip, 0 KB: spi_command
>> called, but no SPI chipset detected
>> Probing for PMC unknown PMC SPI chip, 0 KB: spi_command called, but no
>> SPI chipset detected
>> Probing for SST unknown SST SPI chip, 0 KB: spi_command called, but no
>> SPI chipset detected
>> Probing for ST unknown ST SPI chip, 0 KB: spi_command called, but no
>> SPI chipset detected
>> ===
>> This flash part has status UNTESTED for operations: PROBE READ ERASE
>> WRITE
>> Please email a report to flashrom at coreboot.org if any of the above
>> operations
>> work correctly for you with this flash part. Please include the full
>> output
>> from the program, including chipset found. Thank you for your help!
>> ===
>> coreboot last image size (not ROM size) is 131072 bytes.
>> Manufacturer: Compaq
>> Mainboard ID: Deskpro EN SFF P600
>> Note: If the following flash access fails, you might need to specify
>> -m <vendor>:<mainboard>.
>> ERASE FAILED @237568, val 60!
>>
>> -
>> Why should I give the vendor and board if it was detected correctly?
>>
>>
>> Thanks for your help
>>
>> LuJa
>>
>>
>>     
>
>
>   

-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: flashrom.patch
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20080601/b1d64660/attachment.ksh>

From todthgie at hotmail.com  Mon Jun  2 12:54:26 2008
From: todthgie at hotmail.com (a a)
Date: Mon, 2 Jun 2008 10:54:26 +0000
Subject: [coreboot] [flashrom] flashrom problem: will not flash on
 compaq/deskpro Deskpro EN SFF P600. "E
Message-ID: <BAY132-W29FE5DA9F81C3309F331E9C7BB0@phx.gbl>


Hi all,

Ludwig Jaffe wrote:
> Hi all,
> 
> i fiddled around with the flashrom util, and I managed to rewrite the 
> original compaq-bios, which I saved before.
> I modified the flashrom-utily to enable writing the flashrom. The 
> 29F002BT works with 29f002-funktions and *not* with jedec....
> The only problem that remains, is that it is not possible to unprotect 
> the 20f002bt (ST). with the flashrom utily. So I can not upgrade the flash!
> I will go and code some improvement to that.
> 

i worked with Uwe to create the support for the Compaq deskpro EN SFF 
600N i have here

i needed 3 hardware mods:
- socket for the flash chip (with loads of luck you can skip this but 
please let me test the current tree before you flash coreboot into your 
unit)
- set SW1 to ON to disable the write protection on the'normal' (non 
bootblock ) part of the bios (if you dont do this the ASIC will disable 
ANY writes even probes to the flash iirc
-if you have the original chip onboard: short (not installed) jumper P34 
that is next to the flashpart (shorting this will temp. unlock the 
bootblock and allow (un)programming of the lockbits note that you should 
first protected the whole chip before unproetcting.

i also needed a couple of software hacks that are not yet in the tree:
-disable some parts of the southbrigde (KBC ectect) so the superio can 
handle them
-stuff some values to the ASIC so networking works (otherwise eth0 will 
not show on the pci bus)
-i had some trouble with onboard audio but i dont remember the details now
-i dont have onboard vga working yet  and was planning on maybe using / 
writing free support for it so i dont need a vga bios


i dont have time today/tomorrow to look at it in more detail .. will do 
that later this week ...

greetings,
todthgie




> A suggestion regarding architecture:
> 

> We should add a function-pointer for protect and unprotect, because this 
> is sometimes special. e.g. 29f002bt (st).
> We should provide an extra funktion to protect/unprotect the bios to the 
> user, so that reweiting the eeprom will be
> read() -> save old
> unprotect()
> test_if_unprotected()
> if not die
> erase()
> test_if_empty()
> if not, try to rewrite saved_old!
> else die.
> write
> verify
> 
> 
> So the methods protect/unprotect have to be seperate and not be hidden 
> in erase or write functions.
> And they should be accessible via the punction-pointer-table.
> 
> 
> 
> My patch contains my little modifications and da doxygen file to ease 
> understanding the code.
> 
> Please help me to improve the architecture of flashrom.
> 
> Greetings
> 
> 
> LuJa
> 
> 
> 
> 


_________________________________________________________________
Express yourself instantly with MSN Messenger! Download today it's FREE!
http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20080602/1923d46e/attachment.html>

From todthgie at hotmail.com  Mon Jun  2 13:12:40 2008
From: todthgie at hotmail.com (a a)
Date: Mon, 2 Jun 2008 11:12:40 +0000
Subject: [coreboot] [flashrom] flashrom problem: will not flash on
 compaq/deskpro Deskpro EN SFF P600. "E
Message-ID: <BAY132-W34F759968A0442BF9404EFC7BB0@phx.gbl>


ps.

also note that the board will not take> 256KByte chips because pin 1
(#reset on the 29F002BT  A18 for>256KByte parts) of the plcc it wired 
to P34 (other end of P34 is wired to 12V) and it might even destroy 
other chips if P34 is placed !!

hotflashing on this board is very hard because the powersupply is over 
the rom socket i made myself a extension cable from some compatible 
14Pin molex minifit-jr connectors to allow access to the chip while the 
powersupply is nect to the box

i think we should give flashrom a couple of special commands ..
LOCK and UNLOCK (i used some letters but forgot them)
to unlock this kind of chip locks

the original bios has a recovery option btw ... keek esc pressed 
powering up it will 'talk' to you over the keyboard leds / pc speaker
ahd should be able to restore the bios from a diskette iirc


a a wrote:
> Hi all,
> 
> Ludwig Jaffe wrote:
> > Hi all,
> >
> > i fiddled around with the flashrom util, and I managed to rewrite the
> > original compaq-bios, which I saved before.
> > I modified the flashrom-utily to enable writing the flashrom. The
> > 29F002BT works with 29f002-funktions and *not* with jedec....
> > The only problem that remains, is that it is not possible to unprotect
> > the 20f002bt (ST). with the flashrom utily. So I can not upgrade the 
> flash!
> > I will go and code some improvement to that.
> >
> 
> i worked with Uwe to create the support for the Compaq deskpro EN SFF
> 600N i have here
> 
> i needed 3 hardware mods:
> - socket for the flash chip (with loads of luck you can skip this but
> please let me test the current tree before you flash coreboot into your
> unit)
> - set SW1 to ON to disable the write protection on the'normal' (non
> bootblock ) part of the bios (if you dont do this the ASIC will disable
> ANY writes even probes to the flash iirc
> -if you have the original chip onboard: short (not installed) jumper P34
> that is next to the flashpart (shorting this will temp. unlock the
> bootblock and allow (un)programming of the lockbits note that you should
> first protected the whole chip before unproetcting.
> 
> i also needed a couple of software hacks that are not yet in the tree:
> -disable some parts of the southbrigde (KBC ectect) so the superio can
> handle them
> -stuff some values to the ASIC so networking works (otherwise eth0 will
> not show on the pci bus)
> -i had some trouble with onboard audio but i dont remember the details now
> -i dont have onboard vga working yet and was planning on maybe using /
> writing free support for it so i dont need a vga bios
> 
> 
> i dont have time today/tomorrow to look at it in more detail .. will do
> that later this week ...
> 
> greetings,
> todthgie
> 
> 
> 
> 
> > A suggestion regarding architecture:
> >
> 
> > We should add a function-pointer for protect and unprotect, because this
> > is sometimes special. e.g. 29f002bt (st).
> > We should provide an extra funktion to protect/unprotect the bios to the
> > user, so that reweiting the eeprom will be
> > read() -> save old
> > unprotect()
> > test_if_unprotected()
> > if not die
> > erase()
> > test_if_empty()
> > if not, try to rewrite saved_old!
> > else die.
> > write
> > verify
> >
> >
> > So the methods protect/unprotect have to be seperate and not be hidden
> > in erase or write functions.
> > And they should be accessible via the punction-pointer-table.
> >
> >
> >
> > My patch contains my little modifications and da doxygen file to ease
> > understanding the code.
> >
> > Please help me to improve the architecture of flashrom.
> >
> > Greetings
> >
> >
> > LuJa
> >
> >
> >
> >
> 
> 
> ------------------------------------------------------------------------
> Express yourself instantly with MSN Messenger! MSN Messenger 
> 
> 



_________________________________________________________________
Express yourself instantly with MSN Messenger! Download today it's FREE!
http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20080602/0512b708/attachment.html>

From ward at gnu.org  Mon Jun  2 13:18:25 2008
From: ward at gnu.org (Ward Vandewege)
Date: Mon, 2 Jun 2008 07:18:25 -0400
Subject: [coreboot] buildrom
In-Reply-To: <4843BE92.0001D1.00883@bj163app6.163.com>
References: <4843BE92.0001D1.00883@bj163app6.163.com>
Message-ID: <20080602111825.GA27706@localdomain>

On Mon, Jun 02, 2008 at 05:34:10PM +0800, qchwu wrote:
>    I build a rom for ADM DB800. One error appear as following:
> 
>    [root at localhost buildrom-devel]# make
>    Unpacking mkelfimage...
>    Patching mkelfimage...
>    Applying patch mkelfImage-2.7-x86_64.patch
>    Applying patch mkelfimage-autoconf.patch
>    Now at patch mkelfimage-autoconf.patch
>    Building mkelfImage...
>    Building unifdef (host)...
>    Building lzma...
>    Unpacking kernel (2.6.20.2)...
>    Patching kernel...
>    Building kernel...
>    Installing kernel headers...
>    Building the ELF payload...
>    Compressing the ELF payload with lzma...
>    ******************
>    Payload takes 1508825 Bytes (1473 KBytes) in ROM:
>    ******************
>    Unpacking coreboot (coreboot-svn-3335.tar.gz)...
>    Patching coreboot...
>    Building target...
>    /bin/sh: line 0: cd:
>    /bios/buildrom/buildrom-devel/work/coreboot/svn/targets/: A>>OD-A:C,,o:IA:
>    1/4th>>oA:?A 1/4
>    make: ***
>    [/bios/buildrom/buildrom-devel/work/coreboot/stamps/.configured-db800]
>    'iIo 127
>    [root at localhost buildrom-devel]#

Hmm, that error message seems to be encoded in a non-ASCII character set? Can
you explain/translate the error?

Thanks,
Ward.

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



From luja at openhardware.de  Mon Jun  2 13:27:14 2008
From: luja at openhardware.de (Ludwig Jaffe)
Date: Mon, 02 Jun 2008 13:27:14 +0200
Subject: [coreboot] [flashrom] flashrom problem: will not flash on
 compaq/deskpro Deskpro EN SFF P600
Message-ID: <4843D912.6000501@openhardware.de>

Hi!

thank you for your info.
Could you document your steps a little bit?
Ok, I thought about closing the jumper P34.

The AppNote of st says one only has to rise pin1 (reset) to vid=12V to 
temporarily
unprotect the flash. -> but 12V can cause harm to other devices, and I 
do not know the circuitry of the board.
So this feature seems to be jumper P34. I will try.

Fortunately I managed to rewrite the old bios in the unporotected 
sectors (the protected sectors were not modified by
erase and write). So reboot should be safe.

Attached you find my coreboot.bin together with the filo config. (The 
Flash is damn small, one wants to have more space. Which upgrades are
supported? If I solder a socket I easily could upgrade to a bigger flash)


Is my coreboot kosher? does it boot?


Many thanks


LuJa
-------------- next part --------------
A non-text attachment was scrubbed...
Name: coreboot.rom
Type: application/octet-stream
Size: 262144 bytes
Desc: not available
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20080602/793d00f8/attachment.obj>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: fstab
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20080602/793d00f8/attachment.ksh>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: Config
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20080602/793d00f8/attachment-0001.ksh>

From luja at openhardware.de  Mon Jun  2 13:41:19 2008
From: luja at openhardware.de (Ludwig Jaffe)
Date: Mon, 02 Jun 2008 13:41:19 +0200
Subject: [coreboot] [Fwd: Re: [flashrom] flashrom problem: will not flash on
 compaq/deskpro Deskpro EN SFF P600. "E]
Message-ID: <4843DC5F.4070001@openhardware.de>

a a schrieb:
> ps.
>
> also note that the board will not take> 256KByte chips because pin 1
> (#reset on the 29F002BT A18 for>256KByte parts) of the plcc it wired
> to P34 (other end of P34 is wired to 12V) and it might even destroy
> other chips if P34 is placed !!
Uh! Thats evil.

>
> hotflashing on this board is very hard because the powersupply is over
> the rom socket i made myself a extension cable from some compatible
> 14Pin molex minifit-jr connectors to allow access to the chip while the
> powersupply is nect to the box
where do I get the connectors? Do you have a Digi-key / other distri 
order#?
>
> i think we should give flashrom a couple of special commands ..
> LOCK and UNLOCK (i used some letters but forgot them)
> to unlock this kind of chip locks
flashrom:
Yes, It would be nice to rewrite flashrom accordingly because others 
(openbios.org) also
like to use it. Lets make it a pretty cool tool also for upgrading 
normal pc-bios from remote with linux.
I like the function-pointer arcutecture very much. So we could enhance 
it by adding a function-pointer
for unprotect(*bios) and protect(*bios).
Then an *universal* algorithm will call according to the commandline-params
read(*bios) for backup, unprotect(), is_unprotected(), erase(), 
is_empty() [if not, try to write backup. verify()], write(), verify().

The function-pointers for write() read() and the like point to the 
implementation dependend on the detected flash.
Also function calls within the write or erase have to use the 
function-fointers, so that by servicing the function-pointer table and the
specialized routines, fine granular support for any flash can be writen.
So the ST-Way of unprotecting can be used for all st devices of the 
family. So we save code and become very flexible.
The Problem with the actual code is that some routines simply write some 
data out to issue jedec-erase instaed of calling the erase-method pointed
to by the function-pointer erase().

So flashrom has to be rewritten accordingly (not so much effort) and 
tested by people having the flash-roms in their machines.


>
> the original bios has a recovery option btw ... keek esc pressed
> powering up it will 'talk' to you over the keyboard leds / pc speaker
> ahd should be able to restore the bios from a diskette iirc

Thanks for the tip.

Have you ever thought of reverse-engineering the bios-flaser of compaq 
using a debugger (does the effort make sense?)

Do you have a service-manual? there are some more not assembled 
connectors. E.G.  P115 between Super-IO and ATI-Graphics
whicht seems to be interessting (maybe gpios of super io or I2C/SMBUS)...


Thanks for your tips.


LuJa
>
>
> a a wrote:
> > Hi all,
> >
> > Ludwig Jaffe wrote:
> > > Hi all,
> > >
> > > i fiddled around with the flashrom util, and I managed to rewrite the
> > > original compaq-bios, which I saved before.
> > > I modified the flashrom-utily to enable writing the flashrom. The
> > > 29F002BT works with 29f002-funktions and *not* with jedec....
> > > The only problem that remains, is that it is not possible to 
> unprotect
> > > the 20f002bt (ST). with the flashrom utily. So I can not upgrade the
> > flash!
> > > I will go and code some improvement to that.
> > >
> >
> > i worked with Uwe to create the support for the Compaq deskpro EN SFF
> > 600N i have here
> >
> > i needed 3 hardware mods:
> > - socket for the flash chip (with loads of luck you can skip this but
> > please let me test the current tree before you flash coreboot into your
> > unit)
> > - set SW1 to ON to disable the write protection on the'normal' (non
> > bootblock ) part of the bios (if you dont do this the ASIC will disable
> > ANY writes even probes to the flash iirc
> > -if you have the original chip onboard: short (not installed) jumper 
> P34
> > that is next to the flashpart (shorting this will temp. unlock the
> > bootblock and allow (un)programming of the lockbits note that you 
> should
> > first protected the whole chip before unproetcting.
> >
> > i also needed a couple of software hacks that are not yet in the tree:
> > -disable some parts of the southbrigde (KBC ectect) so the superio can
> > handle them
> > -stuff some values to the ASIC so networking works (otherwise eth0 will
> > not show on the pci bus)
> > -i had some trouble with onboard audio but i dont remember the 
> details now
> > -i dont have onboard vga working yet and was planning on maybe using /
> > writing free support for it so i dont need a vga bios
> >
> >
> > i dont have time today/tomorrow to look at it in more detail .. will do
> > that later this week ...
> >
> > greetings,
> > todthgie
> >
> >
> >
> >
> > > A suggestion regarding architecture:
> > >
> >
> > > We should add a function-pointer for protect and unprotect, 
> because this
> > > is sometimes special. e.g. 29f002bt (st).
> > > We should provide an extra funktion to protect/unprotect the bios 
> to the
> > > user, so that reweiting the eeprom will be
> > > read() -> save old
> > > unprotect()
> > > test_if_unprotected()
> > > if not die
> > > erase()
> > > test_if_empty()
> > > if not, try to rewrite saved_old!
> > > else die.
> > > write
> > > verify
> > >
> > >
> > > So the methods protect/unprotect have to be seperate and not be 
> hidden
> > > in erase or write functions.
> > > And they should be accessible via the punction-pointer-table.
> > >
> > >
> > >
> > > My patch contains my little modifications and da doxygen file to ease
> > > understanding the code.
> > >
> > > Please help me to improve the architecture of flashrom.
> > >
> > > Greetings
> > >
> > >
> > > LuJa
> > >
> > >
> > >
> > >
> >
> >
> > 
> ------------------------------------------------------------------------
> > Express yourself instantly with MSN Messenger! MSN Messenger
> >
> >
>
>
>
> ------------------------------------------------------------------------
> Express yourself instantly with MSN Messenger! MSN Messenger 
> <http://clk.atdmt.com/AVE/go/onm00200471ave/direct/01/>

-------------- next part --------------
An embedded message was scrubbed...
From: Ludwig Jaffe <luja at openhardware.de>
Subject: Re: [coreboot] [flashrom] flashrom problem: will not flash on compaq/deskpro Deskpro EN SFF P600. "E
Date: Mon, 02 Jun 2008 13:40:19 +0200
Size: 6652
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20080602/6a666fd0/attachment.eml>

From todthgie at hotmail.com  Mon Jun  2 14:31:18 2008
From: todthgie at hotmail.com (a a)
Date: Mon, 2 Jun 2008 12:31:18 +0000
Subject: [coreboot] [flashrom] flashrom problem: will not flash on
 compaq/deskpro Deskpro EN SFF P600. "E
Message-ID: <BAY132-W33A5FD4D0F330B9B9E5430C7BB0@phx.gbl>


Ludwig Jaffe wrote:
> a a schrieb:
>> ps.
>>
>> also note that the board will not take> 256KByte chips because pin 1
>> (#reset on the 29F002BT A18 for>256KByte parts) of the plcc it wired
>> to P34 (other end of P34 is wired to 12V) and it might even destroy
>> other chips if P34 is placed !!
> Uh! Thats evil.
> 
>>
>> hotflashing on this board is very hard because the powersupply is over
>> the rom socket i made myself a extension cable from some compatible
>> 14Pin molex minifit-jr connectors to allow access to the chip while the
>> powersupply is nect to the box
> where do I get the connectors? Do you have a Digi-key / other distri 
> order#?

housing for male pins 14 way (to put on the psu):
molex 0039012141 (or harder to find 0039012146)
male pin to insert into this housing:
molex 5558 (or high current 44478) (there are many variations in plating 
and packaging)

housing for female pins 14 way (to put on the mobo):
molex 0039012140  or harder to find 0039012145)
female pin to insert into this housing:
molex 5556 (or high current 44476) (there are many variations in plating 
and packaging)

maybe you can order some samples from molex ?

where are you from btw? (im from the Netherlands)

>>
>> i think we should give flashrom a couple of special commands ..
>> LOCK and UNLOCK (i used some letters but forgot them)
>> to unlock this kind of chip locks
> flashrom:
> Yes, It would be nice to rewrite flashrom accordingly because others 
> (openbios.org) also
> like to use it. Lets make it a pretty cool tool also for upgrading 
> normal pc-bios from remote with linux.
> I like the function-pointer arcutecture very much. So we could enhance 
> it by adding a function-pointer
> for unprotect(*bios) and protect(*bios).
> Then an *universal* algorithm will call according to the commandline-params
> read(*bios) for backup, unprotect(), is_unprotected(), erase(), 
> is_empty() [if not, try to write backup. verify()], write(), verify().
> 
> The function-pointers for write() read() and the like point to the 
> implementation dependend on the detected flash.
> Also function calls within the write or erase have to use the 
> function-fointers, so that by servicing the function-pointer table and the
> specialized routines, fine granular support for any flash can be writen.
> So the ST-Way of unprotecting can be used for all st devices of the 
> family. So we save code and become very flexible.
> The Problem with the actual code is that some routines simply write some 
> data out to issue jedec-erase instaed of calling the erase-method pointed
> to by the function-pointer erase().
> 
> So flashrom has to be rewritten accordingly (not so much effort) and 
> tested by people having the flash-roms in their machines.
> 
> 
>>
>> the original bios has a recovery option btw ... keek esc pressed
>> powering up it will 'talk' to you over the keyboard leds / pc speaker
>> ahd should be able to restore the bios from a diskette iirc
> 
> Thanks for the tip.
> 
> Have you ever thought of reverse-engineering the bios-flaser of compaq 
> using a debugger (does the effort make sense?)

i did just that but it seams the switch will overrule software/ASIC.
iirc the password is stored (encripted?) in cmos.
im dont remember if the asic remembers it on its own or that the bios 
loads it at boot ...
but i dont have the details in my head atm and no time to look it up

> Do you have a service-manual? there are some more not assembled 
> connectors. E.G.  P115 between Super-IO and ATI-Graphics
> whicht seems to be interessting (maybe gpios of super io or I2C/SMBUS)...

i think i saw somewhere that P115 is SCSI but im not shure..
i am shure that that are loads of missing resistor 'bank' parts around 
that...
P108 seams to be gameport(maybe also midi)

service manual i have is pdf_27556.pdf
i got it from
http://www.manualshark.org/manualshark/files/28/pdf_27556.pdf
see also
http://www.manualshark.org/p/hewlett-packard-28/hewlett-packard-compaq-deskpro-en-desktop-pc-series-26913/


> 
> Thanks for your tips.
> 
> 
> LuJa
>>
>>
>> a a wrote:
>>> Hi all,
>>>
>>> Ludwig Jaffe wrote:
>>>> Hi all,
>>>>
>>>> i fiddled around with the flashrom util, and I managed to rewrite the
>>>> original compaq-bios, which I saved before.
>>>> I modified the flashrom-utily to enable writing the flashrom. The
>>>> 29F002BT works with 29f002-funktions and *not* with jedec....
>>>> The only problem that remains, is that it is not possible to 
>> unprotect
>>>> the 20f002bt (ST). with the flashrom utily. So I can not upgrade the
>>> flash!
>>>> I will go and code some improvement to that.
>>>>
>>>
>>> i worked with Uwe to create the support for the Compaq deskpro EN SFF
>>> 600N i have here
>>>
>>> i needed 3 hardware mods:
>>> - socket for the flash chip (with loads of luck you can skip this but
>>> please let me test the current tree before you flash coreboot into your
>>> unit)
>>> - set SW1 to ON to disable the write protection on the'normal' (non
>>> bootblock ) part of the bios (if you dont do this the ASIC will disable
>>> ANY writes even probes to the flash iirc
>>> -if you have the original chip onboard: short (not installed) jumper 
>> P34
>>> that is next to the flashpart (shorting this will temp. unlock the
>>> bootblock and allow (un)programming of the lockbits note that you 
>> should
>>> first protected the whole chip before unproetcting.
>>>
>>> i also needed a couple of software hacks that are not yet in the tree:
>>> -disable some parts of the southbrigde (KBC ectect) so the superio can
>>> handle them
>>> -stuff some values to the ASIC so networking works (otherwise eth0 will
>>> not show on the pci bus)
>>> -i had some trouble with onboard audio but i dont remember the 
>> details now
>>> -i dont have onboard vga working yet and was planning on maybe using /
>>> writing free support for it so i dont need a vga bios
>>>
>>>
>>> i dont have time today/tomorrow to look at it in more detail .. will do
>>> that later this week ...
>>>
>>> greetings,
>>> todthgie
>>>
>>>
>>>
>>>
>>>> A suggestion regarding architecture:
>>>>
>>>
>>>> We should add a function-pointer for protect and unprotect, 
>> because this
>>>> is sometimes special. e.g. 29f002bt (st).
>>>> We should provide an extra funktion to protect/unprotect the bios 
>> to the
>>>> user, so that reweiting the eeprom will be
>>>> read() -> save old
>>>> unprotect()
>>>> test_if_unprotected()
>>>> if not die
>>>> erase()
>>>> test_if_empty()
>>>> if not, try to rewrite saved_old!
>>>> else die.
>>>> write
>>>> verify
>>>>
>>>>
>>>> So the methods protect/unprotect have to be seperate and not be 
>> hidden
>>>> in erase or write functions.
>>>> And they should be accessible via the punction-pointer-table.
>>>>
>>>>
>>>>
>>>> My patch contains my little modifications and da doxygen file to ease
>>>> understanding the code.
>>>>
>>>> Please help me to improve the architecture of flashrom.
>>>>
>>>> Greetings
>>>>
>>>>
>>>> LuJa
>>>>
>>>>
>>>>
>>>>
>>>
>>>
>>> 
>> ------------------------------------------------------------------------
>>> Express yourself instantly with MSN Messenger! MSN Messenger
>>>
>>>
>>
>>
>>
>> ------------------------------------------------------------------------
>> Express yourself instantly with MSN Messenger! MSN Messenger 
>> 
> 
> 
> 



_________________________________________________________________
Express yourself instantly with MSN Messenger! Download today it's FREE!
http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20080602/055a96e6/attachment.html>

From todthgie at hotmail.com  Mon Jun  2 14:36:22 2008
From: todthgie at hotmail.com (a a)
Date: Mon, 2 Jun 2008 12:36:22 +0000
Subject: [coreboot] Unprotecting 29F002BT
Message-ID: <BAY132-W43DB93FFD0AB4EDA3BC00DC7BB0@phx.gbl>


Ludwig Jaffe wrote:
> Hi,
> 
> looking for the unprotect-algorithm I found the AN1122 from ST.
> The figure 4 shows a way to do this, but, how do we put VID=12V to Pin#1?
> Does anybody know how this is done or if we should use the 
> programmer-mode/way instaed of insystem/mode/way?
> 
> Thanks for your comments.
> 
> Attached the application-note, and the datasheet of st29F002B series.
> 
> 
> Greetings
> 
> LuJa
> 
> 
from the other tread i assume you are talking about the
compaq deskpro en sff 600n motherboard which has a jumper (P34 but not 
mounted only pads) to connect pin1 to 12Vdc


_________________________________________________________________
Express yourself instantly with MSN Messenger! Download today it's FREE!
http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20080602/296a5ecb/attachment.html>

From luja at openhardware.de  Mon Jun  2 14:45:05 2008
From: luja at openhardware.de (Ludwig Jaffe)
Date: Mon, 02 Jun 2008 14:45:05 +0200
Subject: [coreboot] [flashrom] flashrom problem: will not flash on
 compaq/deskpro Deskpro EN SFF P600.
In-Reply-To: <BAY132-W33A5FD4D0F330B9B9E5430C7BB0@phx.gbl>
References: <BAY132-W33A5FD4D0F330B9B9E5430C7BB0@phx.gbl>
Message-ID: <4843EB51.2010805@openhardware.de>

Hi,

Thanks for the molex-numbers. I will check spoerle if they sell some.
I am from munich/germany.
My Compaq is the 600mhz p3-version with BX-Chipset.  and an P34 jumper 
which is not populated.
I will solder in a cable with a switch, so I can protect/unprotect the 
flash.

Greetings

LuJa



a a schrieb:
> Ludwig Jaffe wrote:
> > a a schrieb:
> >> ps.
> >>
> >> also note that the board will not take> 256KByte chips because pin 1
> >> (#reset on the 29F002BT A18 for>256KByte parts) of the plcc it wired
> >> to P34 (other end of P34 is wired to 12V) and it might even destroy
> >> other chips if P34 is placed !!
> > Uh! Thats evil.
> >
> >>
> >> hotflashing on this board is very hard because the powersupply is over
> >> the rom socket i made myself a extension cable from some compatible
> >> 14Pin molex minifit-jr connectors to allow access to the chip while the
> >> powersupply is nect to the box
> > where do I get the connectors? Do you have a Digi-key / other distri
> > order#?
>
> housing for male pins 14 way (to put on the psu):
> molex 0039012141 (or harder to find 0039012146)
> male pin to insert into this housing:
> molex 5558 (or high current 44478) (there are many variations in plating
> and packaging)
>
> housing for female pins 14 way (to put on the mobo):
> molex 0039012140 or harder to find 0039012145)
> female pin to insert into this housing:
> molex 5556 (or high current 44476) (there are many variations in plating
> and packaging)
>
> maybe you can order some samples from molex ?
>
> where are you from btw? (im from the Netherlands)
>
> >>
> >> i think we should give flashrom a couple of special commands ..
> >> LOCK and UNLOCK (i used some letters but forgot them)
> >> to unlock this kind of chip locks
> > flashrom:
> > Yes, It would be nice to rewrite flashrom accordingly because others
> > (openbios.org) also
> > like to use it. Lets make it a pretty cool tool also for upgrading
> > normal pc-bios from remote with linux.
> > I like the function-pointer arcutecture very much. So we could enhance
> > it by adding a function-pointer
> > for unprotect(*bios) and protect(*bios).
> > Then an *universal* algorithm will call according to the 
> commandline-params
> > read(*bios) for backup, unprotect(), is_unprotected(), erase(),
> > is_empty() [if not, try to write backup. verify()], write(), verify().
> >
> > The function-pointers for write() read() and the like point to the
> > implementation dependend on the detected flash.
> > Also function calls within the write or erase have to use the
> > function-fointers, so that by servicing the function-pointer table 
> and the
> > specialized routines, fine granular support for any flash can be writen.
> > So the ST-Way of unprotecting can be used for all st devices of the
> > family. So we save code and become very flexible.
> > The Problem with the actual code is that some routines simply write 
> some
> > data out to issue jedec-erase instaed of calling the erase-method 
> pointed
> > to by the function-pointer erase().
> >
> > So flashrom has to be rewritten accordingly (not so much effort) and
> > tested by people having the flash-roms in their machines.
> >
> >
> >>
> >> the original bios has a recovery option btw ... keek esc pressed
> >> powering up it will 'talk' to you over the keyboard leds / pc speaker
> >> ahd should be able to restore the bios from a diskette iirc
> >
> > Thanks for the tip.
> >
> > Have you ever thought of reverse-engineering the bios-flaser of compaq
> > using a debugger (does the effort make sense?)
>
> i did just that but it seams the switch will overrule software/ASIC.
> iirc the password is stored (encripted?) in cmos.
> im dont remember if the asic remembers it on its own or that the bios
> loads it at boot ...
> but i dont have the details in my head atm and no time to look it up
>
> > Do you have a service-manual? there are some more not assembled
> > connectors. E.G. P115 between Super-IO and ATI-Graphics
> > whicht seems to be interessting (maybe gpios of super io or 
> I2C/SMBUS)...
>
> i think i saw somewhere that P115 is SCSI but im not shure..
> i am shure that that are loads of missing resistor 'bank' parts around
> that...
> P108 seams to be gameport(maybe also midi)
>
> service manual i have is pdf_27556.pdf
> i got it from
> http://www.manualshark.org/manualshark/files/28/pdf_27556.pdf
> see also
> http://www.manualshark.org/p/hewlett-packard-28/hewlett-packard-compaq-deskpro-en-desktop-pc-series-26913/
>
>
> >
> > Thanks for your tips.
> >
> >
> > LuJa
> >>
> >>
> >> a a wrote:
> >>> Hi all,
> >>>
> >>> Ludwig Jaffe wrote:
> >>>> Hi all,
> >>>>
> >>>> i fiddled around with the flashrom util, and I managed to rewrite the
> >>>> original compaq-bios, which I saved before.
> >>>> I modified the flashrom-utily to enable writing the flashrom. The
> >>>> 29F002BT works with 29f002-funktions and *not* with jedec....
> >>>> The only problem that remains, is that it is not possible to
> >> unprotect
> >>>> the 20f002bt (ST). with the flashrom utily. So I can not upgrade the
> >>> flash!
> >>>> I will go and code some improvement to that.
> >>>>
> >>>
> >>> i worked with Uwe to create the support for the Compaq deskpro EN SFF
> >>> 600N i have here
> >>>
> >>> i needed 3 hardware mods:
> >>> - socket for the flash chip (with loads of luck you can skip this but
> >>> please let me test the current tree before you flash coreboot into 
> your
> >>> unit)
> >>> - set SW1 to ON to disable the write protection on the'normal' (non
> >>> bootblock ) part of the bios (if you dont do this the ASIC will 
> disable
> >>> ANY writes even probes to the flash iirc
> >>> -if you have the original chip onboard: short (not installed) jumper
> >> P34
> >>> that is next to the flashpart (shorting this will temp. unlock the
> >>> bootblock and allow (un)programming of the lockbits note that you
> >> should
> >>> first protected the whole chip before unproetcting.
> >>>
> >>> i also needed a couple of software hacks that are not yet in the tree:
> >>> -disable some parts of the southbrigde (KBC ectect) so the superio can
> >>> handle them
> >>> -stuff some values to the ASIC so networking works (otherwise eth0 
> will
> >>> not show on the pci bus)
> >>> -i had some trouble with onboard audio but i dont remember the
> >> details now
> >>> -i dont have onboard vga working yet and was planning on maybe using /
> >>> writing free support for it so i dont need a vga bios
> >>>
> >>>
> >>> i dont have time today/tomorrow to look at it in more detail .. 
> will do
> >>> that later this week ...
> >>>
> >>> greetings,
> >>> todthgie
> >>>
> >>>
> >>>
> >>>
> >>>> A suggestion regarding architecture:
> >>>>
> >>>
> >>>> We should add a function-pointer for protect and unprotect,
> >> because this
> >>>> is sometimes special. e.g. 29f002bt (st).
> >>>> We should provide an extra funktion to protect/unprotect the bios
> >> to the
> >>>> user, so that reweiting the eeprom will be
> >>>> read() -> save old
> >>>> unprotect()
> >>>> test_if_unprotected()
> >>>> if not die
> >>>> erase()
> >>>> test_if_empty()
> >>>> if not, try to rewrite saved_old!
> >>>> else die.
> >>>> write
> >>>> verify
> >>>>
> >>>>
> >>>> So the methods protect/unprotect have to be seperate and not be
> >> hidden
> >>>> in erase or write functions.
> >>>> And they should be accessible via the punction-pointer-table.
> >>>>
> >>>>
> >>>>
> >>>> My patch contains my little modifications and da doxygen file to ease
> >>>> understanding the code.
> >>>>
> >>>> Please help me to improve the architecture of flashrom.
> >>>>
> >>>> Greetings
> >>>>
> >>>>
> >>>> LuJa
> >>>>
> >>>>
> >>>>
> >>>>
> >>>
> >>>
> >>>
> >> 
> ------------------------------------------------------------------------
> >>> Express yourself instantly with MSN Messenger! MSN Messenger
> >>>
> >>>
> >>
> >>
> >>
> >> 
> ------------------------------------------------------------------------
> >> Express yourself instantly with MSN Messenger! MSN Messenger
> >>
> >
> >
> >
>
>
>
> ------------------------------------------------------------------------
> Express yourself instantly with MSN Messenger! MSN Messenger 
> <http://clk.atdmt.com/AVE/go/onm00200471ave/direct/01/>




From joe at settoplinux.org  Mon Jun  2 17:11:19 2008
From: joe at settoplinux.org (Joseph Smith)
Date: Mon, 02 Jun 2008 11:11:19 -0400
Subject: [coreboot] =?utf-8?q?DRAM_Row_Attributes_i82830_Help=3F?=
Message-ID: <95ee7e27715670f9af4126719f84515e@imap.1and1.com>


Hello,
I am having a problem with my set_dram_row_attributes() function in
raminit.c and need some help. The function seems to calculate ok but when
it comes to the switches, it is only working with one so-dimm not two. Is
this because there are two switches with the same name? How can I fix it?
Here is the output with some extra debugging and the function:

Found DIMM in slot 00, setting DRA...
Test - columns 0x0a
Test - data width 0x40
Test - page size 0x00010000
Test - KB 0x08
Test - banks 0x02
DRA 0x70 has been set to 0x08 <---- THIS SHOULD BE 0X22 - SEE SWITCH BELOW
Found DIMM in slot 01, setting DRA...
Test - columns 0x09
Test - data width 0x40
Test - page size 0x00008000
Test - KB 0x04
Test - banks 0x01
DRA 0x71 has been set to 0xf1


----------------------------------
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) {
				case 2: /* 2KB */
					dra = 0xF0;
					break;
				case 4: /* 4KB */
					dra = 0xF1;
					break;
				case 8: /* 8KB */
					dra = 0xF2;
					break;
				case 16: /* 16KB */
					dra = 0xF3;
					break;
				default:
					print_err("Page size not supported\r\n");
					die("HALT\r\n");
				}
			} else if (value == 2) {
				switch (dra) {
				case 2: /* 2KB */
					dra = 0x00;
					break;
				case 4: /* 4KB */
					dra = 0x11;
					break;
				case 8: /* 8KB */
					dra = 0x22;
					break;
				case 16: /* 16KB */
					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");
	}
}


I am stumped, please help.
-- 
Thanks,
Joseph Smith
Set-Top-Linux
www.settoplinux.org




From mylesgw at gmail.com  Mon Jun  2 17:26:44 2008
From: mylesgw at gmail.com (Myles Watson)
Date: Mon, 2 Jun 2008 09:26:44 -0600
Subject: [coreboot] buildrom
In-Reply-To: <4843BE92.0001D1.00883@bj163app6.163.com>
References: <4843BE92.0001D1.00883@bj163app6.163.com>
Message-ID: <2831fecf0806020826y59bfcd89y966e55d1dd2b09f0@mail.gmail.com>

2008/6/2 qchwu <qchwu at 163.com>:
> I build a rom for ADM DB800. One error appear as following:
>
> [root at localhost buildrom-devel]# make
> Unpacking mkelfimage...
> Patching mkelfimage...
> Applying patch mkelfImage-2.7-x86_64.patch
> Applying patch mkelfimage-autoconf.patch
> Now at patch mkelfimage-autoconf.patch
> Building mkelfImage...
> Building unifdef (host)...
> Building lzma...
> Unpacking kernel (2.6.20.2)...
> Patching kernel...
> Building kernel...
> Installing kernel headers...
> Building the ELF payload...
> Compressing the ELF payload with lzma...
> ******************
> Payload takes 1508825 Bytes (1473 KBytes) in ROM:
> ******************
> Unpacking coreboot (coreboot-svn-3335.tar.gz)...
> Patching coreboot...
> Building target...
> /bin/sh: line 0: cd:
> /bios/buildrom/buildrom-devel/work/coreboot/svn/targets/: ?????????
> make: ***
> [/bios/buildrom/buildrom-devel/work/coreboot/stamps/.configured-db800] ??
> 127

When I try to build a compressed payload for DB800, I get an error
because it can't find Config-lab.lb.  Here are the steps you should
take:

1. Create a Config-lab.lb in work/coreboot/svn/targets/amd/db800/
which sets ROM_SIZE correctly for the chip you have.
2. Make sure you build a payload that fits in the chip ( Your lab
payload above needs at least a 2MB (16 Mbit) chip.
3. Try it again.

Thanks,
Myles

> [root at localhost buildrom-devel]#
>
> How can i clear this error?
>
> My gcc'version is 4.2.2.
> kernel'version is 2.6.18
> make'version is 3.81
>
> thanks!
> chenghu
>
>
>
>
> ________________________________
> ??????????
> --
> coreboot mailing list
> coreboot at coreboot.org
> http://www.coreboot.org/mailman/listinfo/coreboot
>

From mylesgw at gmail.com  Mon Jun  2 17:29:00 2008
From: mylesgw at gmail.com (Myles Watson)
Date: Mon, 2 Jun 2008 09:29:00 -0600
Subject: [coreboot] Coreinfo and geode conflict in buildrom
Message-ID: <2831fecf0806020829y76b46b10k9da5d424e56af1fd@mail.gmail.com>

I couldn't build a coreinfo payload for the db800 because they both
try to set DEPENDS-y.  Is there a strong ordering (which should set it
and which should add to the list), or should we make a new DEPENDS-y
for the platform?

Thanks,
Myles



From jordan.crouse at amd.com  Mon Jun  2 17:36:57 2008
From: jordan.crouse at amd.com (Jordan Crouse)
Date: Mon, 2 Jun 2008 09:36:57 -0600
Subject: [coreboot] Coreinfo and geode conflict in buildrom
In-Reply-To: <2831fecf0806020829y76b46b10k9da5d424e56af1fd@mail.gmail.com>
References: <2831fecf0806020829y76b46b10k9da5d424e56af1fd@mail.gmail.com>
Message-ID: <20080602153657.GB27238@cosmic.amd.com>

On 02/06/08 09:29 -0600, Myles Watson wrote:
> I couldn't build a coreinfo payload for the db800 because they both
> try to set DEPENDS-y.  Is there a strong ordering (which should set it
> and which should add to the list), or should we make a new DEPENDS-y
> for the platform?

Hmmm - they should both use a +=.  DEPENDS-y should be empty by default,
but if we don't want to depend on make doing the right thing, we can
do a DEPENDS-y= before we start including files.

There shouldn't be any strong ordering in the DEPENDS-y code in general,
if there is, thats a bug.

Jordan

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




From svn at coreboot.org  Mon Jun  2 18:14:55 2008
From: svn at coreboot.org (svn at coreboot.org)
Date: Mon,  2 Jun 2008 18:14:55 +0200
Subject: [coreboot] r200 - buildrom-devel/config/payloads
Message-ID: <mailman.1616.1355071329.16123.coreboot@coreboot.org>

Author: myles
Date: 2008-06-02 18:14:55 +0200 (Mon, 02 Jun 2008)
New Revision: 200

Modified:
   buildrom-devel/config/payloads/libpayload-dep.conf
Log:
This is a trivial patch that corrects the libpayload dependency handling in
buildrom.
 
Signed-off-by: Myles Watson <mylesgw at gmail.com>
Acked-by: Myles Watson <mylesgw at gmail.com>



Modified: buildrom-devel/config/payloads/libpayload-dep.conf
===================================================================
--- buildrom-devel/config/payloads/libpayload-dep.conf	2008-05-29 14:38:03 UTC (rev 199)
+++ buildrom-devel/config/payloads/libpayload-dep.conf	2008-06-02 16:14:55 UTC (rev 200)
@@ -3,4 +3,4 @@
 include $(CONFIG_DIR)/payloads/generic.conf
 
 # Add libpayload as a dependency
-DEPENDS-y=libpayload
+DEPENDS-y+=libpayload




From mylesgw at gmail.com  Mon Jun  2 18:16:55 2008
From: mylesgw at gmail.com (Myles Watson)
Date: Mon, 2 Jun 2008 10:16:55 -0600
Subject: [coreboot] Coreinfo and geode conflict in buildrom
In-Reply-To: <20080602153657.GB27238@cosmic.amd.com>
References: <2831fecf0806020829y76b46b10k9da5d424e56af1fd@mail.gmail.com>
	<20080602153657.GB27238@cosmic.amd.com>
Message-ID: <009401c8c4cc$13c21c80$1a02a8c0@chimp>



> -----Original Message-----
> From: Jordan Crouse [mailto:jordan.crouse at amd.com]
> Sent: Monday, June 02, 2008 9:37 AM
> To: Myles Watson
> Cc: coreboot at coreboot.or...
> Subject: Re: Coreinfo and geode conflict in buildrom
> 
> On 02/06/08 09:29 -0600, Myles Watson wrote:
> > I couldn't build a coreinfo payload for the db800 because they both
> > try to set DEPENDS-y.  Is there a strong ordering (which should set it
> > and which should add to the list), or should we make a new DEPENDS-y
> > for the platform?
> 
> Hmmm - they should both use a +=.  

Fixed in Rev 200.

> DEPENDS-y should be empty by default,
> but if we don't want to depend on make doing the right thing, we can
> do a DEPENDS-y= before we start including files.

We do that in Makefile.

> 
> There shouldn't be any strong ordering in the DEPENDS-y code in general,
> if there is, thats a bug.

Thanks,
Myles





From urjaman at gmail.com  Mon Jun  2 19:18:47 2008
From: urjaman at gmail.com (Urja Rannikko)
Date: Mon, 2 Jun 2008 20:18:47 +0300
Subject: [coreboot] Adding support for an old motherboard to coreboot?
Message-ID: <460f92b70806021018h2a1cbfaat3e9f780936bdde82@mail.gmail.com>

Hi list,

I have an old Acer/IBM V58XA motherboard that was idling useless here.
I have been looking at coreboot for a while and thought that adding
support for my hardware would be a nice challenge for me. I think that
i could learn a lot by making this mb supported, although it's
usefulness in general is questionable (P233, 64M SDRAM).

I actually found the chipset datasheets (Acer/ALi M1531B and M1533)
here http://www.rom.by/doki.htm .

I have a PCI POST card, the MB has an 256k AT29C020 flash ROM. It's
supported by uniflash.
I have a serial "null modem" cable to use for getting debug output.
One problem is that i don't have a bios savior / backup flash chip for
it. I think that i would salvage from somewhere/purchase an additional
flashrom and backup the current bios to it (hotswapping, i have done
it before) and test coreboot using the current flash chip.

It has only an fdd,keyb,vga,mem,cpu,power attached now so struggled to
find an 1.44M linux that would have lspci and stopped there.

Here's pretty much all the spec i know of the MB:
- CPU: Pentium 233 MMX
- RAM: 2*  32MB SDRAM's
- "Memory, Cache and Buffer Controller": ALi M1531 B1
- Southbridge: ALi M1533 A1
- VGA: Integrated ATI RageII+DVD with 2M of memory
- SuperIO: SMsC FDC37C935APM (just found a datasheet for this)

One note is that it seems to be that both the M1533 and the superio
chip have an IDE controller capability and keyboard interface. This
seems odd. I really don't know which chip's IDE this MB uses. (The
M1533 is physically nearer to the ide connectors...)

It has the following connectors available:
- external:
- 2 usb
- 1 rs232
- 1 parallel
- audio conns, game/midiport, vga, ps2 kb&mouse
- internal:
- 3 pci, 4 isa
- 2 ide/ata channels
- fdd connector

Then, here go my questions to the list.
- Should i develop using coreboot v2 or v3?
- Could somebody list me the basic steps of adding a new motherboard
to coreboot(v2 or v3)?
- ------- '' --------- Estimate of the amount of code that needs to be written?
- I took a brief look at the datasheets and it seems that the
motherboard supports SMM (system management mode) and thus has SMRAM
(2 SRAM chips found near cpu) (another one near the M1531). Could this
ram be used the same way as Cache-As-RAM is used on newer
motherboards?

-- 
Urja Rannikko



From jordan.crouse at amd.com  Tue Jun  3 01:48:05 2008
From: jordan.crouse at amd.com (Jordan Crouse)
Date: Mon, 2 Jun 2008 17:48:05 -0600
Subject: [coreboot] LinuxTag 2008 Status
In-Reply-To: <00a601c8c2a8$df85a0b0$0023040a@chimp>
References: <20080530204441.GA14200@cosmic.amd.com>
	<00a601c8c2a8$df85a0b0$0023040a@chimp>
Message-ID: <20080602234805.GB30270@cosmic.amd.com>

On 30/05/08 16:59 -0600, Myles Watson wrote:
> 
> > But when you look closer, the number of possible modes explodes.  As an
> > example:
> > 
> >  - You may want to add a timeout to the menu, so that if somebody doesn't
> >  press the hotkey, a default payload is chosen.
> >  - When chaining, some payloads will be opt in (press F1 for setup), some
> >  will be opt out (press F2 to skip), and others will always run
> >  - Uwe expressed a desire to select a chain from the menu
> > 
> > Everything is further complicated by the fact that we can add a new
> > payload
> > to the LAR at any time, which makes it very difficult to specific the
> > configuration at bayou compile time.
> 
> How about the name of the lar entry for the payload (since we can store the
> user-friendly name in the notes.)  The default payload is the one named
> "payload" or "normal" or "default".  Then any number of payloads with their
> attributes can be added, but the default still works.

I like this, but allow me to play devil's advocate for a second.  There
might be a few flies in the ointment.  The dynamic nature of LAR forces
us to consider complex scenarios that otherwise wouldn't be a factor.
What if you want to change the default payload?  If the name isn't shorter
then payloads/default, then there will be much shifting of bytes, which
is dangerous on the ROM (or rather, no less dangerous then writing
a new ROM).

The other thing that concerns me is that the person building the LAR needs
to make the conscious decision to name one of the payloads payload/default.
Sure we could make the LAR binary handle the magic, but that would 
be just another flag in a cast of thousands.  We already experience
a bit of this pain already.  In lieu of a magic number in the LAR header
or in the SELF header, bayou currently checks for the name prefix 'payload/'
and assumes that is a payload.  I have already forgotten to append
'payload/' several times (until I got the Makefile to do it for me).
I believe that this will cause problems down the road - not everybody
will be using buildrom.

All that said, I think that this is the best suggestion so far - it is
easy to implement, and at least gets us further down the path.

Jordan

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




From jordan.crouse at amd.com  Tue Jun  3 01:51:39 2008
From: jordan.crouse at amd.com (Jordan Crouse)
Date: Mon, 2 Jun 2008 17:51:39 -0600
Subject: [coreboot] LinuxTag 2008 Status
In-Reply-To: <4842C4C0.8060303@gmx.net>
References: <e0232121f7eded9ae0d225494504aff1@imap.1and1.com>
	<1212091343.7391.49.camel@mattotaupa.wohnung.familie-menzel.net>
	<13426df10805291458i3990273aleb91978bb3911730@mail.gmail.com>
	<20080530204441.GA14200@cosmic.amd.com> <4842C4C0.8060303@gmx.net>
Message-ID: <20080602235139.GC30270@cosmic.amd.com>

On 01/06/08 17:48 +0200, Carl-Daniel Hailfinger wrote:
> >  - Uwe expressed a desire to select a chain from the menu
> >   
> 
> No offense, but IMHO that is a bit overboard.

Not as overboard as it might sound though - say for example that we make
a payload specifically to populate the legacy tables.  A boot menu could
offer the choice between Windows and Linux, and if you chose the Windows
path it would run the legacy table payload followed by the windows loader,
while the Linux path would just run grub2 (or FILO).  Its not a crazy idea,
and its the sort of thing we need to be prepared for.

> > Everything is further complicated by the fact that we can add a new payload
> > to the LAR at any time, which makes it very difficult to specific the
> > configuration at bayou compile time.
> >   
> 
> Maybe just store a default configuration at compile time and retrieve
> settings from NVRAM or from a continuously-changing zone in flash?

Sure, but lets get more technical - how is this going to work?  Who is
going to write the configuration?  How would one change the configuration
(probably at the same time they are adding something to the LAR?).  Should
we have a simple text file on the ROM?  XML?  Something else?
Many questions, few answers.

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




From joe at settoplinux.org  Tue Jun  3 02:09:27 2008
From: joe at settoplinux.org (Joseph Smith)
Date: Mon, 2 Jun 2008 20:09:27 -0400
Subject: [coreboot] LinuxTag 2008 Status
In-Reply-To: <20080602235139.GC30270@cosmic.amd.com>
References: <e0232121f7eded9ae0d225494504aff1@imap.1and1.com><1212091343.7391.49.camel@mattotaupa.wohnung.familie-menzel.net><13426df10805291458i3990273aleb91978bb3911730@mail.gmail.com><20080530204441.GA14200@cosmic.amd.com>
	<4842C4C0.8060303@gmx.net> <20080602235139.GC30270@cosmic.amd.com>
Message-ID: <510ED59CFC3040A18AF52027AE9999FA@smitty2m>

> > >  - Uwe expressed a desire to select a chain from the menu
> > >
> >
> > No offense, but IMHO that is a bit overboard.
> 
> Not as overboard as it might sound though - say for example that we make
> a payload specifically to populate the legacy tables.  A boot menu could
> offer the choice between Windows and Linux, and if you chose the Windows
> path it would run the legacy table payload followed by the windows loader,
> while the Linux path would just run grub2 (or FILO).  Its not a crazy
> idea,
> and its the sort of thing we need to be prepared for.
> 
I really like this idea :-)

Thanks,
Joseph Smith
Set-Top-Linux
www.settoplinux.org




From qchwu at 163.com  Tue Jun  3 02:09:35 2008
From: qchwu at 163.com (qchwu)
Date: Tue, 3 Jun 2008 08:09:35 +0800 (CST)
Subject: [coreboot] buildrom
Message-ID: <48448BBF.000039.17899@bj163app5.163.com>

I build a rom for ADM DB800. One error appear as following:

[root at localhost buildrom-devel]# make
Unpacking mkelfimage...
Patching mkelfimage...
Applying patch mkelfImage-2.7-x86_64.patch
Applying patch mkelfimage-autoconf.patch
Now at patch mkelfimage-autoconf.patch
Building mkelfImage...
Building unifdef (host)...
Building lzma...
Unpacking kernel (2.6.20.2)...
Patching kernel...
Building kernel...
Installing kernel headers...
Building the ELF payload...
Compressing the ELF payload with lzma...
******************
Payload takes 1508825 Bytes (1473 KBytes) in ROM:
******************
Unpacking coreboot (coreboot-svn-3335.tar.gz)...
Patching coreboot...
Building target...
/bin/sh: line 0: cd: /bios/buildrom/buildrom-devel/work/coreboot/svn/targets/: ????????? (the file or folder is not found.)
make: *** [/bios/buildrom/buildrom-devel/work/coreboot/stamps/.configured-db800] ?? 127 (error 127)
[root at localhost buildrom-devel]# 

How can i clear this error?

My gcc'version is 4.2.2.
kernel'version is 2.6.18
make'version is 3.81

thanks!
chenghu
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20080603/ef573910/attachment.html>

From Daniel.Shufelt at EProPortland.com  Tue Jun  3 02:13:23 2008
From: Daniel.Shufelt at EProPortland.com (Daniel Shufelt)
Date: Mon, 2 Jun 2008 17:13:23 -0700
Subject: [coreboot] EFI / Tiano Engineer Needed
Message-ID: <E47948D9A39EF0488B832ED828048C6D04DB2F20@tsgsrv01.nwhq.thestollergroup.com>

Hi Everyone!

 

It's not my intention to detract from the purpose of this list rest
assured I'll only submit this inquiry once.  If you have an interest
please contact me directly off the list.

 

I have a client located near Portland Oregon (not Intel) who is looking
to bring on a Senior EFI developer who has experience leveraging the
Tiano framework.  I would be happy to provide a job description and
company information to any interested parties.  This is a great
opportunity with a reputable company offering great salary, benefits
etc.

 

Sorry if this is not the proper forum however, seasoned firmware
engineers are few and far between and those with experience with the
Tiano framework seem to be even sparser.

 

Thank you all for your patients and understanding.  I do apologize if
anyone found this inquiry irritating; I won't make this a habit.

 

 

Best regards,

 

Dan Shufelt

Information Technology Recruiter

Express Employment Professionals

*Professional & Executive Search*

7401 SW Washo Ct, Suite 200

Tualatin, Oregon 97062

* 503.612.2072 - Direct

* 503.720.5262 - Mobile

7 503.352.1764 - FAX

* daniel.shufelt at eproportland.com
<mailto:daniel.shufelt at eproportland.com> 

*      http://www.epsportland.com <http://www.epsportland.com/> 

http://www.linkedin.com/in/dshufelt
<http://www.linkedin.com/in/dshufeltp> 

 

"Here for you 24/7!"

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

From svn at coreboot.org  Tue Jun  3 02:22:01 2008
From: svn at coreboot.org (svn at coreboot.org)
Date: Tue,  3 Jun 2008 02:22:01 +0200
Subject: [coreboot] r3360 - trunk/util/flashrom
Message-ID: <mailman.1617.1355071329.16123.coreboot@coreboot.org>

Author: stuge
Date: 2008-06-03 02:22:00 +0200 (Tue, 03 Jun 2008)
New Revision: 3360

Modified:
   trunk/util/flashrom/flashchips.c
Log:
Ward writes:

SST SST49LF160C is confirmed to work for PROBE READ ERASE WRITE, at least on
2 MCP55-based boards (gigabyte m57sli v1 and supermicro h8dmr).

On the m57sli board, it only works > 512K when booted into coreboot; the
proprietary bios seems to do something weird where it locks rom access down
to the first 512K of the chip.

Signed-off-by: Peter Stuge <peter at stuge.se>
Acked-by: Peter Stuge <peter at stuge.se>


Modified: trunk/util/flashrom/flashchips.c
===================================================================
--- trunk/util/flashrom/flashchips.c	2008-05-28 08:40:23 UTC (rev 3359)
+++ trunk/util/flashrom/flashchips.c	2008-06-03 00:22:00 UTC (rev 3360)
@@ -95,7 +95,7 @@
 	{"SST",		"SST49LF040",		SST_ID,		SST_49LF040,		512,	4096,		TEST_UNTESTED,	probe_jedec,		erase_49lf040,			write_49lf040},
 	{"SST",		"SST49LF040B",		SST_ID,		SST_49LF040B,		512,	64 * 1024,	TEST_UNTESTED,	probe_sst_fwhub,	erase_sst_fwhub,		write_sst_fwhub},
 	{"SST",		"SST49LF080A",		SST_ID,		SST_49LF080A,		1024,	4096,		TEST_OK_PREW,	probe_jedec,		erase_49lf040,			write_49lf040},
-	{"SST",		"SST49LF160C",		SST_ID,		SST_49LF160C,		2048,	4 * 1024,	TEST_UNTESTED,	probe_49lfxxxc,		erase_49lfxxxc,			write_49lfxxxc},
+	{"SST",		"SST49LF160C",		SST_ID,		SST_49LF160C,		2048,	4 * 1024,	TEST_OK_PREW,	probe_49lfxxxc,		erase_49lfxxxc,			write_49lfxxxc},
 	{"ST",		"M25P05-A",		ST_ID,		ST_M25P05A,		64,	256,		TEST_UNTESTED,	probe_spi_rdid,		spi_chip_erase_c7,	spi_chip_write, spi_chip_read},
 	{"ST",		"M25P10-A",		ST_ID,		ST_M25P10A,		128,	256,		TEST_UNTESTED,	probe_spi_rdid,		spi_chip_erase_c7,	spi_chip_write, spi_chip_read},
 	{"ST",		"M25P20",		ST_ID,		ST_M25P20,		256,	256,		TEST_UNTESTED,	probe_spi_rdid,		spi_chip_erase_c7,	spi_chip_write, spi_chip_read},




From info at coresystems.de  Tue Jun  3 03:07:36 2008
From: info at coresystems.de (coreboot information)
Date: Tue, 03 Jun 2008 03:07:36 +0200
Subject: [coreboot] r3360 build service
Message-ID: <E1K3Kzw-0001AA-O3@khepri.openbios.org>

Dear coreboot readers!

This is the automated build check service of coreboot.

The developer "stuge" checked in revision 3360 to
the coreboot source repository and caused the following 
changes:

Change Log:
Ward writes:

SST SST49LF160C is confirmed to work for PROBE READ ERASE WRITE, at least on
2 MCP55-based boards (gigabyte m57sli v1 and supermicro h8dmr).

On the m57sli board, it only works > 512K when booted into coreboot; the
proprietary bios seems to do something weird where it locks rom access down
to the first 512K of the chip.

Signed-off-by: Peter Stuge <peter at stuge.se>
Acked-by: Peter Stuge <peter at stuge.se>


Build Log:
Compilation of via:epia-cn is still broken
See the error log at http://qa.coreboot.org/log_buildbrd.php?revision=3360&device=epia-cn&vendor=via


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

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

   Best regards,
     coreboot automatic build system





From joe at settoplinux.org  Tue Jun  3 03:34:45 2008
From: joe at settoplinux.org (Joseph Smith)
Date: Mon, 02 Jun 2008 21:34:45 -0400
Subject: [coreboot] memtest x86 64-bit issues
Message-ID: <4cbe64c0bc7c649fe7e755d05192485a@imap.1and1.com>


Hello,
I can't seem to build memtest on my 64-bit version of FC8. Can someone just
send me a 32-bit memtest elf file?

Here is the error:
[joe at localhost memtest86-3.4]$ make
as   -o head.o head.s
head.S: Assembler messages:
head.S:44: Error: 8-byte relocation cannot be applied to 4-byte field
head.S:53: Error: 8-byte relocation cannot be applied to 4-byte field
head.S:56: Error: 8-byte relocation cannot be applied to 4-byte field
head.S:57: Error: 8-byte relocation cannot be applied to 4-byte field
head.S:58: Error: 8-byte relocation cannot be applied to 4-byte field
head.S:59: Error: 8-byte relocation cannot be applied to 4-byte field
head.S:73: Error: 8-byte relocation cannot be applied to 4-byte field
head.S:76: Error: 8-byte relocation cannot be applied to 4-byte field
head.S:77: Error: 8-byte relocation cannot be applied to 4-byte field
head.S:83: Error: 8-byte relocation cannot be applied to 4-byte field
head.S:89: Error: 8-byte relocation cannot be applied to 4-byte field
head.S:98: Error: 8-byte relocation cannot be applied to 4-byte field
head.S:105: Error: 8-byte relocation cannot be applied to 4-byte field
head.S:107: Error: 8-byte relocation cannot be applied to 4-byte field
head.S:115: Error: 8-byte relocation cannot be applied to 4-byte field
head.S:123: Error: 8-byte relocation cannot be applied to 4-byte field
head.S:131: Error: 8-byte relocation cannot be applied to 4-byte field
head.S:139: Error: 8-byte relocation cannot be applied to 4-byte field
head.S:147: Error: 8-byte relocation cannot be applied to 4-byte field
head.S:155: Error: 8-byte relocation cannot be applied to 4-byte field
head.S:163: Error: 8-byte relocation cannot be applied to 4-byte field
head.S:171: Error: 8-byte relocation cannot be applied to 4-byte field
head.S:179: Error: 8-byte relocation cannot be applied to 4-byte field
head.S:187: Error: 8-byte relocation cannot be applied to 4-byte field
head.S:195: Error: 8-byte relocation cannot be applied to 4-byte field
head.S:203: Error: 8-byte relocation cannot be applied to 4-byte field
head.S:211: Error: 8-byte relocation cannot be applied to 4-byte field
head.S:219: Error: 8-byte relocation cannot be applied to 4-byte field
head.S:227: Error: 8-byte relocation cannot be applied to 4-byte field
head.S:235: Error: 8-byte relocation cannot be applied to 4-byte field
head.S:243: Error: 8-byte relocation cannot be applied to 4-byte field
head.S:251: Error: 8-byte relocation cannot be applied to 4-byte field
head.S:259: Error: 8-byte relocation cannot be applied to 4-byte field
head.S:268: Error: 8-byte relocation cannot be applied to 4-byte field
head.S:269: Error: 8-byte relocation cannot be applied to 4-byte field
head.S:270: Error: 8-byte relocation cannot be applied to 4-byte field
head.S:274: Error: 8-byte relocation cannot be applied to 4-byte field
head.S:446: Error: 8-byte relocation cannot be applied to 4-byte field
head.S:692: Error: 8-byte relocation cannot be applied to 4-byte field
head.S:697: Error: 8-byte relocation cannot be applied to 4-byte field
head.S:700: Error: 8-byte relocation cannot be applied to 4-byte field
head.S:701: Error: 8-byte relocation cannot be applied to 4-byte field
head.S:716: Error: 8-byte relocation cannot be applied to 4-byte field
head.S:717: Error: 8-byte relocation cannot be applied to 4-byte field
head.S:718: Error: 8-byte relocation cannot be applied to 4-byte field
head.S:719: Error: 8-byte relocation cannot be applied to 4-byte field
head.S:720: Error: 8-byte relocation cannot be applied to 4-byte field
head.S:721: Error: 8-byte relocation cannot be applied to 4-byte field
head.S:722: Error: 8-byte relocation cannot be applied to 4-byte field
head.S:723: Error: 8-byte relocation cannot be applied to 4-byte field
head.S:726: Error: 8-byte relocation cannot be applied to 4-byte field
head.S:727: Error: 8-byte relocation cannot be applied to 4-byte field
head.S:729: Error: 8-byte relocation cannot be applied to 4-byte field
head.S:742: Error: 8-byte relocation cannot be applied to 4-byte field
head.S:744: Error: 8-byte relocation cannot be applied to 4-byte field
head.S:945: Error: 8-byte relocation cannot be applied to 4-byte field
make: *** [head.o] Error 1
[joe at localhost memtest86-3.4]$     

-- 
Thanks,
Joseph Smith
Set-Top-Linux
www.settoplinux.org




From corey.osgood at gmail.com  Tue Jun  3 04:02:41 2008
From: corey.osgood at gmail.com (Corey Osgood)
Date: Mon, 2 Jun 2008 22:02:41 -0400
Subject: [coreboot] memtest x86 64-bit issues
In-Reply-To: <4cbe64c0bc7c649fe7e755d05192485a@imap.1and1.com>
References: <4cbe64c0bc7c649fe7e755d05192485a@imap.1and1.com>
Message-ID: <dd3c80060806021902l6d5f091fm59aa03387853e417@mail.gmail.com>

On Mon, Jun 2, 2008 at 9:34 PM, Joseph Smith <joe at settoplinux.org> wrote:
You want precomp.bin from the source/binary package on memtest86.com

-Corey

>
> Hello,
> I can't seem to build memtest on my 64-bit version of FC8. Can someone just
> send me a 32-bit memtest elf file?
>
> Here is the error:
> [joe at localhost memtest86-3.4]$ make
> as   -o head.o head.s
> head.S: Assembler messages:
> head.S:44: Error: 8-byte relocation cannot be applied to 4-byte field
> head.S:53: Error: 8-byte relocation cannot be applied to 4-byte field
> head.S:56: Error: 8-byte relocation cannot be applied to 4-byte field
> head.S:57: Error: 8-byte relocation cannot be applied to 4-byte field
> head.S:58: Error: 8-byte relocation cannot be applied to 4-byte field
> head.S:59: Error: 8-byte relocation cannot be applied to 4-byte field
> head.S:73: Error: 8-byte relocation cannot be applied to 4-byte field
> head.S:76: Error: 8-byte relocation cannot be applied to 4-byte field
> head.S:77: Error: 8-byte relocation cannot be applied to 4-byte field
> head.S:83: Error: 8-byte relocation cannot be applied to 4-byte field
> head.S:89: Error: 8-byte relocation cannot be applied to 4-byte field
> head.S:98: Error: 8-byte relocation cannot be applied to 4-byte field
> head.S:105: Error: 8-byte relocation cannot be applied to 4-byte field
> head.S:107: Error: 8-byte relocation cannot be applied to 4-byte field
> head.S:115: Error: 8-byte relocation cannot be applied to 4-byte field
> head.S:123: Error: 8-byte relocation cannot be applied to 4-byte field
> head.S:131: Error: 8-byte relocation cannot be applied to 4-byte field
> head.S:139: Error: 8-byte relocation cannot be applied to 4-byte field
> head.S:147: Error: 8-byte relocation cannot be applied to 4-byte field
> head.S:155: Error: 8-byte relocation cannot be applied to 4-byte field
> head.S:163: Error: 8-byte relocation cannot be applied to 4-byte field
> head.S:171: Error: 8-byte relocation cannot be applied to 4-byte field
> head.S:179: Error: 8-byte relocation cannot be applied to 4-byte field
> head.S:187: Error: 8-byte relocation cannot be applied to 4-byte field
> head.S:195: Error: 8-byte relocation cannot be applied to 4-byte field
> head.S:203: Error: 8-byte relocation cannot be applied to 4-byte field
> head.S:211: Error: 8-byte relocation cannot be applied to 4-byte field
> head.S:219: Error: 8-byte relocation cannot be applied to 4-byte field
> head.S:227: Error: 8-byte relocation cannot be applied to 4-byte field
> head.S:235: Error: 8-byte relocation cannot be applied to 4-byte field
> head.S:243: Error: 8-byte relocation cannot be applied to 4-byte field
> head.S:251: Error: 8-byte relocation cannot be applied to 4-byte field
> head.S:259: Error: 8-byte relocation cannot be applied to 4-byte field
> head.S:268: Error: 8-byte relocation cannot be applied to 4-byte field
> head.S:269: Error: 8-byte relocation cannot be applied to 4-byte field
> head.S:270: Error: 8-byte relocation cannot be applied to 4-byte field
> head.S:274: Error: 8-byte relocation cannot be applied to 4-byte field
> head.S:446: Error: 8-byte relocation cannot be applied to 4-byte field
> head.S:692: Error: 8-byte relocation cannot be applied to 4-byte field
> head.S:697: Error: 8-byte relocation cannot be applied to 4-byte field
> head.S:700: Error: 8-byte relocation cannot be applied to 4-byte field
> head.S:701: Error: 8-byte relocation cannot be applied to 4-byte field
> head.S:716: Error: 8-byte relocation cannot be applied to 4-byte field
> head.S:717: Error: 8-byte relocation cannot be applied to 4-byte field
> head.S:718: Error: 8-byte relocation cannot be applied to 4-byte field
> head.S:719: Error: 8-byte relocation cannot be applied to 4-byte field
> head.S:720: Error: 8-byte relocation cannot be applied to 4-byte field
> head.S:721: Error: 8-byte relocation cannot be applied to 4-byte field
> head.S:722: Error: 8-byte relocation cannot be applied to 4-byte field
> head.S:723: Error: 8-byte relocation cannot be applied to 4-byte field
> head.S:726: Error: 8-byte relocation cannot be applied to 4-byte field
> head.S:727: Error: 8-byte relocation cannot be applied to 4-byte field
> head.S:729: Error: 8-byte relocation cannot be applied to 4-byte field
> head.S:742: Error: 8-byte relocation cannot be applied to 4-byte field
> head.S:744: Error: 8-byte relocation cannot be applied to 4-byte field
> head.S:945: Error: 8-byte relocation cannot be applied to 4-byte field
> make: *** [head.o] Error 1
> [joe at localhost memtest86-3.4]$
>
> --
> Thanks,
> Joseph Smith
> Set-Top-Linux
> www.settoplinux.org
>
>
> --
> coreboot mailing list
> coreboot at coreboot.org
> http://www.coreboot.org/mailman/listinfo/coreboot
>



From joe at settoplinux.org  Tue Jun  3 04:15:28 2008
From: joe at settoplinux.org (Joseph Smith)
Date: Mon, 02 Jun 2008 22:15:28 -0400
Subject: [coreboot] memtest x86 64-bit issues
In-Reply-To: <dd3c80060806021902l6d5f091fm59aa03387853e417@mail.gmail.com>
References: <4cbe64c0bc7c649fe7e755d05192485a@imap.1and1.com>
	<dd3c80060806021902l6d5f091fm59aa03387853e417@mail.gmail.com>
Message-ID: <6528b0f9fd94040b1ce6d2ba735e3d96@imap.1and1.com>




On Mon, 2 Jun 2008 22:02:41 -0400, "Corey Osgood" <corey.osgood at gmail.com>
wrote:
> On Mon, Jun 2, 2008 at 9:34 PM, Joseph Smith <joe at settoplinux.org> wrote:
> You want precomp.bin from the source/binary package on memtest86.com
> 
> -Corey

That's the elf file for a coreboot payload?
> 
>>
>> Hello,
>> I can't seem to build memtest on my 64-bit version of FC8. Can someone
> just
>> send me a 32-bit memtest elf file?
>>
>> Here is the error:
>> [joe at localhost memtest86-3.4]$ make
>> as   -o head.o head.s
>> head.S: Assembler messages:
>> head.S:44: Error: 8-byte relocation cannot be applied to 4-byte field
>> head.S:53: Error: 8-byte relocation cannot be applied to 4-byte field
>> head.S:56: Error: 8-byte relocation cannot be applied to 4-byte field
>> head.S:57: Error: 8-byte relocation cannot be applied to 4-byte field
>> head.S:58: Error: 8-byte relocation cannot be applied to 4-byte field
>> head.S:59: Error: 8-byte relocation cannot be applied to 4-byte field
>> head.S:73: Error: 8-byte relocation cannot be applied to 4-byte field
>> head.S:76: Error: 8-byte relocation cannot be applied to 4-byte field
>> head.S:77: Error: 8-byte relocation cannot be applied to 4-byte field
>> head.S:83: Error: 8-byte relocation cannot be applied to 4-byte field
>> head.S:89: Error: 8-byte relocation cannot be applied to 4-byte field
>> head.S:98: Error: 8-byte relocation cannot be applied to 4-byte field
>> head.S:105: Error: 8-byte relocation cannot be applied to 4-byte field
>> head.S:107: Error: 8-byte relocation cannot be applied to 4-byte field
>> head.S:115: Error: 8-byte relocation cannot be applied to 4-byte field
>> head.S:123: Error: 8-byte relocation cannot be applied to 4-byte field
>> head.S:131: Error: 8-byte relocation cannot be applied to 4-byte field
>> head.S:139: Error: 8-byte relocation cannot be applied to 4-byte field
>> head.S:147: Error: 8-byte relocation cannot be applied to 4-byte field
>> head.S:155: Error: 8-byte relocation cannot be applied to 4-byte field
>> head.S:163: Error: 8-byte relocation cannot be applied to 4-byte field
>> head.S:171: Error: 8-byte relocation cannot be applied to 4-byte field
>> head.S:179: Error: 8-byte relocation cannot be applied to 4-byte field
>> head.S:187: Error: 8-byte relocation cannot be applied to 4-byte field
>> head.S:195: Error: 8-byte relocation cannot be applied to 4-byte field
>> head.S:203: Error: 8-byte relocation cannot be applied to 4-byte field
>> head.S:211: Error: 8-byte relocation cannot be applied to 4-byte field
>> head.S:219: Error: 8-byte relocation cannot be applied to 4-byte field
>> head.S:227: Error: 8-byte relocation cannot be applied to 4-byte field
>> head.S:235: Error: 8-byte relocation cannot be applied to 4-byte field
>> head.S:243: Error: 8-byte relocation cannot be applied to 4-byte field
>> head.S:251: Error: 8-byte relocation cannot be applied to 4-byte field
>> head.S:259: Error: 8-byte relocation cannot be applied to 4-byte field
>> head.S:268: Error: 8-byte relocation cannot be applied to 4-byte field
>> head.S:269: Error: 8-byte relocation cannot be applied to 4-byte field
>> head.S:270: Error: 8-byte relocation cannot be applied to 4-byte field
>> head.S:274: Error: 8-byte relocation cannot be applied to 4-byte field
>> head.S:446: Error: 8-byte relocation cannot be applied to 4-byte field
>> head.S:692: Error: 8-byte relocation cannot be applied to 4-byte field
>> head.S:697: Error: 8-byte relocation cannot be applied to 4-byte field
>> head.S:700: Error: 8-byte relocation cannot be applied to 4-byte field
>> head.S:701: Error: 8-byte relocation cannot be applied to 4-byte field
>> head.S:716: Error: 8-byte relocation cannot be applied to 4-byte field
>> head.S:717: Error: 8-byte relocation cannot be applied to 4-byte field
>> head.S:718: Error: 8-byte relocation cannot be applied to 4-byte field
>> head.S:719: Error: 8-byte relocation cannot be applied to 4-byte field
>> head.S:720: Error: 8-byte relocation cannot be applied to 4-byte field
>> head.S:721: Error: 8-byte relocation cannot be applied to 4-byte field
>> head.S:722: Error: 8-byte relocation cannot be applied to 4-byte field
>> head.S:723: Error: 8-byte relocation cannot be applied to 4-byte field
>> head.S:726: Error: 8-byte relocation cannot be applied to 4-byte field
>> head.S:727: Error: 8-byte relocation cannot be applied to 4-byte field
>> head.S:729: Error: 8-byte relocation cannot be applied to 4-byte field
>> head.S:742: Error: 8-byte relocation cannot be applied to 4-byte field
>> head.S:744: Error: 8-byte relocation cannot be applied to 4-byte field
>> head.S:945: Error: 8-byte relocation cannot be applied to 4-byte field
>> make: *** [head.o] Error 1
>> [joe at localhost memtest86-3.4]$
>>
>> --
>> Thanks,
>> Joseph Smith
>> Set-Top-Linux
>> www.settoplinux.org
>>
>>
>> --
>> coreboot mailing list
>> coreboot at coreboot.org
>> http://www.coreboot.org/mailman/listinfo/coreboot
>>
> 
> --
> coreboot mailing list
> coreboot at coreboot.org
> http://www.coreboot.org/mailman/listinfo/coreboot
-- 
Thanks,
Joseph Smith
Set-Top-Linux
www.settoplinux.org




From joe at settoplinux.org  Tue Jun  3 05:41:11 2008
From: joe at settoplinux.org (Joseph Smith)
Date: Mon, 02 Jun 2008 23:41:11 -0400
Subject: [coreboot] ram init help on the i82830
In-Reply-To: <dd3c80060805282246n200d7eb9j3ea094a7fbbc8519@mail.gmail.com>
References: <bd5a919d8f8c9f3b1843712f5dc06e7d@imap.1and1.com>
	<dd3c80060805272040n58bd85f3x95bfc2cc0928f308@mail.gmail.com>
	<dd3c80060805272104u9efe708h892f6d1f98fa1a1c@mail.gmail.com>
	<2b006022ef73ffcb29f9a499ec98605f@imap.1and1.com>
	<d9895cb58ebc619bc751b8882077b2af@imap.1and1.com>
	<dd3c80060805282246n200d7eb9j3ea094a7fbbc8519@mail.gmail.com>
Message-ID: <d570aa83b51576676c357b9ee62740ca@imap.1and1.com>


> 
>>        /* See if there are 2 sticks. */
>>        if((drb1 != 0) && (drb3 != 0)) {
> 
> Should be:
> 
> if((drb1 != 0) && (drb3 != drb1))
> 
In theory this would not work. If you have a so-dimm in slot0 drb3 would ==
drb1. The register would look something like this:

04 04 04 04

for a 128MB single sidded so-dimm in the first slot.

-- 
Thanks,
Joseph Smith
Set-Top-Linux
www.settoplinux.org




From joe at settoplinux.org  Tue Jun  3 05:45:22 2008
From: joe at settoplinux.org (Joseph Smith)
Date: Mon, 02 Jun 2008 23:45:22 -0400
Subject: [coreboot] ram init help on the i82830
In-Reply-To: <d570aa83b51576676c357b9ee62740ca@imap.1and1.com>
References: <bd5a919d8f8c9f3b1843712f5dc06e7d@imap.1and1.com>
	<dd3c80060805272040n58bd85f3x95bfc2cc0928f308@mail.gmail.com>
	<dd3c80060805272104u9efe708h892f6d1f98fa1a1c@mail.gmail.com>
	<2b006022ef73ffcb29f9a499ec98605f@imap.1and1.com>
	<d9895cb58ebc619bc751b8882077b2af@imap.1and1.com>
	<dd3c80060805282246n200d7eb9j3ea094a7fbbc8519@mail.gmail.com>
	<d570aa83b51576676c357b9ee62740ca@imap.1and1.com>
Message-ID: <de5fd7225ea3f050b203bb4e8ec69944@imap.1and1.com>




On Mon, 02 Jun 2008 23:41:11 -0400, Joseph Smith <joe at settoplinux.org>
wrote:
> 
>>
>>>        /* See if there are 2 sticks. */
>>>        if((drb1 != 0) && (drb3 != 0)) {
>>
>> Should be:
>>
>> if((drb1 != 0) && (drb3 != drb1))
>>
> In theory this would not work. If you have a so-dimm in slot0 drb3 would
> ==
> drb1. The register would look something like this:
> 
> 04 04 04 04
> 
> for a 128MB single sidded so-dimm in the first slot.
> 
Actually, this should work:

if((drb1 != 0) && (drb3 > drb1)) {

This way if drb1 is not zero, you know you have a so-dimm in slot0.
And if drb3 is greater than drb1, you know you have a so-dimm in slot1.

-- 
Thanks,
Joseph Smith
Set-Top-Linux
www.settoplinux.org




From corey.osgood at gmail.com  Tue Jun  3 07:07:52 2008
From: corey.osgood at gmail.com (Corey Osgood)
Date: Tue, 3 Jun 2008 01:07:52 -0400
Subject: [coreboot] memtest x86 64-bit issues
In-Reply-To: <6528b0f9fd94040b1ce6d2ba735e3d96@imap.1and1.com>
References: <4cbe64c0bc7c649fe7e755d05192485a@imap.1and1.com>
	<dd3c80060806021902l6d5f091fm59aa03387853e417@mail.gmail.com>
	<6528b0f9fd94040b1ce6d2ba735e3d96@imap.1and1.com>
Message-ID: <dd3c80060806022207u3c575ecfw63f564e220061612@mail.gmail.com>

*Fail*

No, it's not, sorry. If noone else steps in, I'm stuck in Vista on my
laptop for now, NetworkManager's broken in my Ubuntu install, but I'll
set up putty and build it on my fileserver Thursday. Sorry, but I
won't be home for more then a few minutes between now and then.

-Corey

On Mon, Jun 2, 2008 at 10:15 PM, Joseph Smith <joe at settoplinux.org> wrote:
>
>
>
> On Mon, 2 Jun 2008 22:02:41 -0400, "Corey Osgood" <corey.osgood at gmail.com>
> wrote:
>> On Mon, Jun 2, 2008 at 9:34 PM, Joseph Smith <joe at settoplinux.org> wrote:
>> You want precomp.bin from the source/binary package on memtest86.com
>>
>> -Corey
>
> That's the elf file for a coreboot payload?
>>
>>>
>>> Hello,
>>> I can't seem to build memtest on my 64-bit version of FC8. Can someone
>> just
>>> send me a 32-bit memtest elf file?
>>>
>>> Here is the error:
>>> [joe at localhost memtest86-3.4]$ make
>>> as   -o head.o head.s
>>> head.S: Assembler messages:
>>> head.S:44: Error: 8-byte relocation cannot be applied to 4-byte field
>>> head.S:53: Error: 8-byte relocation cannot be applied to 4-byte field
>>> head.S:56: Error: 8-byte relocation cannot be applied to 4-byte field
>>> head.S:57: Error: 8-byte relocation cannot be applied to 4-byte field
>>> head.S:58: Error: 8-byte relocation cannot be applied to 4-byte field
>>> head.S:59: Error: 8-byte relocation cannot be applied to 4-byte field
>>> head.S:73: Error: 8-byte relocation cannot be applied to 4-byte field
>>> head.S:76: Error: 8-byte relocation cannot be applied to 4-byte field
>>> head.S:77: Error: 8-byte relocation cannot be applied to 4-byte field
>>> head.S:83: Error: 8-byte relocation cannot be applied to 4-byte field
>>> head.S:89: Error: 8-byte relocation cannot be applied to 4-byte field
>>> head.S:98: Error: 8-byte relocation cannot be applied to 4-byte field
>>> head.S:105: Error: 8-byte relocation cannot be applied to 4-byte field
>>> head.S:107: Error: 8-byte relocation cannot be applied to 4-byte field
>>> head.S:115: Error: 8-byte relocation cannot be applied to 4-byte field
>>> head.S:123: Error: 8-byte relocation cannot be applied to 4-byte field
>>> head.S:131: Error: 8-byte relocation cannot be applied to 4-byte field
>>> head.S:139: Error: 8-byte relocation cannot be applied to 4-byte field
>>> head.S:147: Error: 8-byte relocation cannot be applied to 4-byte field
>>> head.S:155: Error: 8-byte relocation cannot be applied to 4-byte field
>>> head.S:163: Error: 8-byte relocation cannot be applied to 4-byte field
>>> head.S:171: Error: 8-byte relocation cannot be applied to 4-byte field
>>> head.S:179: Error: 8-byte relocation cannot be applied to 4-byte field
>>> head.S:187: Error: 8-byte relocation cannot be applied to 4-byte field
>>> head.S:195: Error: 8-byte relocation cannot be applied to 4-byte field
>>> head.S:203: Error: 8-byte relocation cannot be applied to 4-byte field
>>> head.S:211: Error: 8-byte relocation cannot be applied to 4-byte field
>>> head.S:219: Error: 8-byte relocation cannot be applied to 4-byte field
>>> head.S:227: Error: 8-byte relocation cannot be applied to 4-byte field
>>> head.S:235: Error: 8-byte relocation cannot be applied to 4-byte field
>>> head.S:243: Error: 8-byte relocation cannot be applied to 4-byte field
>>> head.S:251: Error: 8-byte relocation cannot be applied to 4-byte field
>>> head.S:259: Error: 8-byte relocation cannot be applied to 4-byte field
>>> head.S:268: Error: 8-byte relocation cannot be applied to 4-byte field
>>> head.S:269: Error: 8-byte relocation cannot be applied to 4-byte field
>>> head.S:270: Error: 8-byte relocation cannot be applied to 4-byte field
>>> head.S:274: Error: 8-byte relocation cannot be applied to 4-byte field
>>> head.S:446: Error: 8-byte relocation cannot be applied to 4-byte field
>>> head.S:692: Error: 8-byte relocation cannot be applied to 4-byte field
>>> head.S:697: Error: 8-byte relocation cannot be applied to 4-byte field
>>> head.S:700: Error: 8-byte relocation cannot be applied to 4-byte field
>>> head.S:701: Error: 8-byte relocation cannot be applied to 4-byte field
>>> head.S:716: Error: 8-byte relocation cannot be applied to 4-byte field
>>> head.S:717: Error: 8-byte relocation cannot be applied to 4-byte field
>>> head.S:718: Error: 8-byte relocation cannot be applied to 4-byte field
>>> head.S:719: Error: 8-byte relocation cannot be applied to 4-byte field
>>> head.S:720: Error: 8-byte relocation cannot be applied to 4-byte field
>>> head.S:721: Error: 8-byte relocation cannot be applied to 4-byte field
>>> head.S:722: Error: 8-byte relocation cannot be applied to 4-byte field
>>> head.S:723: Error: 8-byte relocation cannot be applied to 4-byte field
>>> head.S:726: Error: 8-byte relocation cannot be applied to 4-byte field
>>> head.S:727: Error: 8-byte relocation cannot be applied to 4-byte field
>>> head.S:729: Error: 8-byte relocation cannot be applied to 4-byte field
>>> head.S:742: Error: 8-byte relocation cannot be applied to 4-byte field
>>> head.S:744: Error: 8-byte relocation cannot be applied to 4-byte field
>>> head.S:945: Error: 8-byte relocation cannot be applied to 4-byte field
>>> make: *** [head.o] Error 1
>>> [joe at localhost memtest86-3.4]$
>>>
>>> --
>>> Thanks,
>>> Joseph Smith
>>> Set-Top-Linux
>>> www.settoplinux.org
>>>
>>>
>>> --
>>> coreboot mailing list
>>> coreboot at coreboot.org
>>> http://www.coreboot.org/mailman/listinfo/coreboot
>>>
>>
>> --
>> coreboot mailing list
>> coreboot at coreboot.org
>> http://www.coreboot.org/mailman/listinfo/coreboot
> --
> Thanks,
> Joseph Smith
> Set-Top-Linux
> www.settoplinux.org
>
>



From rminnich at gmail.com  Tue Jun  3 07:51:15 2008
From: rminnich at gmail.com (ron minnich)
Date: Mon, 2 Jun 2008 22:51:15 -0700
Subject: [coreboot] patch: clean up cx5536 power handling,
	get power working on usb port 3 on dbe62
Message-ID: <13426df10806022251s7fa8ff0et60f26885261b3c1f@mail.gmail.com>

attached

who knows why I can't get port 4 to go ....

mystery so far.

ron
-------------- next part --------------
A non-text attachment was scrubbed...
Name: dbe62usb.diff
Type: text/x-diff
Size: 3786 bytes
Desc: not available
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20080602/34758dc6/attachment.bin>

From c-d.hailfinger.devel.2006 at gmx.net  Tue Jun  3 12:35:40 2008
From: c-d.hailfinger.devel.2006 at gmx.net (Carl-Daniel Hailfinger)
Date: Tue, 03 Jun 2008 12:35:40 +0200
Subject: [coreboot] patch: clean up cx5536 power handling,
 get power working on usb port 3 on dbe62
In-Reply-To: <13426df10806022251s7fa8ff0et60f26885261b3c1f@mail.gmail.com>
References: <13426df10806022251s7fa8ff0et60f26885261b3c1f@mail.gmail.com>
Message-ID: <48451E7C.2010708@gmx.net>

On 03.06.2008 07:51, ron minnich wrote:
> attached
>
> who knows why I can't get port 4 to go ....
>
> mystery so far.
>
> ron
>   
> This patch gets usb port 3 on dbe62 working and sets up a dts-based way to map USB 
> EHCI power control registers to power enables pins 1 and 2. 
>   

Nice work! Do you plan to add that sort of info to your geode/cs5536
info dumper?

> Why doesn't port 4 work? Who knows. That's a problem for another day. 
>
> Signed-off-by: Ronald G. Minnich <rminnich at gmail.com>
>   

Acked-by: Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006 at gmx.net>
with one minor cosmetic change (see below).

> Index: southbridge/amd/cs5536/cs5536.c
> ===================================================================
> --- southbridge/amd/cs5536/cs5536.c	(revision 687)
> +++ southbridge/amd/cs5536/cs5536.c	(working copy)
> @@ -454,8 +454,34 @@
>  			*(bar + UOCMUX) |= PMUX_HOST;
>  
>  		/* Overcurrent configuration */
> +		printk(BIOS_DEBUG, "UOCCAP is %x\n", *(bar + UOCCAP));
>  		if (sb->enable_USBP4_overcurrent)
>  			*(bar + UOCCAP) |= sb->enable_USBP4_overcurrent;
> +		/* power control. This is bit USB_PWR_EN2 in the UUCO.
> +		 * From Jordan: The kernel never sees a header for
> +		 * this device.  It used to provide a OS visible
> +		 * device, but that was defeatured.  There are still
> +		 * some registers in the block that are useful for the
> +		 * firmware to setup, but nothing that a kernel level
> +		 * driver would need to consume.
> +		 *
> +		 * That said, VSA _does_ provide the header under
> +		 * device ID PCI_DEVICE_ID_AMD_CS5536_OTG, but it is
> +		 * hidden when 0xDEADBEEF is written to config space
> +		 * register 0x7C
> +		 * (southbridge/amd/cs5536/cs5536.c:492).
> +		 *
> +		 * If you need to write the port power settings you
> +		 * can find the resource in the PCI config space and
> +		 * write to it as usual, just make sure that you do it
> +		 * before the block gets DEADBEEFed.
> +		 */
> +		if (sb->pph) {
> +			*(bar + UOCCAP) &= ~0xff;
> +			*(bar + UOCCAP) |= sb->pph;
> +		}
> +		printk(BIOS_DEBUG, "UOCCAP is %x\n", *(bar + UOCCAP));
> +
>  	}
>  
>  	/* PBz#6466: If the UOC(OTG) device, port 4, is configured as a
> Index: southbridge/amd/cs5536/dts
> ===================================================================
> --- southbridge/amd/cs5536/dts	(revision 687)
> +++ southbridge/amd/cs5536/dts	(working copy)
> @@ -37,8 +37,31 @@
>  	enable_ide_nand_flash = "0";
>  
>  	/* Enable USB Port 4 (0:host 1:device). */
> +	/* This means that the board or whatever would be a "gadget", i.e. 
>   

Please merge these two comment blocks (remove termination from the first
one, remove beginning from the second one).

> +	 * you connect it to a computer and it looks like a storage or camera
> +	 * or printer. 
> +	 */
>  	enable_USBP4_device = "0";
>  
> +	/* This is a tad confusing, but it's hard to make it easy. 
> +	 * These are the PPH bits (port power handling) in the 
> +	 * USB Option Capability register. They are 4 2-bit fields
> +	 * that correspond to the four ports. This chip has two PWR ENABLE
> +	 * pins, and what you can do is, for each of the four fields, 
> +	 * map which port controls which pin. It is common to map 
> +	 * ports 1&2 to PWR_EN_1, and ports 3&4 to PWR_EN_2.
> +	 * The two bit fields are as follows:
> +	 * 00 -- no power ever
> +	 * 01 -- power control in EHCI will turn on both. 
> +	 * 10 -- power control will turn on EN1
> +	 * 11 -- power control will turn on EN2
> +	 * This is all very wiring dependent, and there is a default value,
> +	 * so we let this default to 0, which to the driver means "do nothing", 
> +	 * but if the mainboard sets it, then it will be set into the UOCCAP.
> +	 * for reference, DBE62 seems to want xx111010 -- xx because we 
> +	 * can get port 3 to work, but not port 4.
> +	 */
> +	pph = "0";
>  	/* 0:off, xxxx:overcurrent setting, e.g. 0x3FEA.
>  	 * See CS5536 - Data Book (pages 380-381).
>  	 */
> Index: mainboard/artecgroup/dbe62/dts
> ===================================================================
> --- mainboard/artecgroup/dbe62/dts	(revision 687)
> +++ mainboard/artecgroup/dbe62/dts	(working copy)
> @@ -52,6 +52,8 @@
>  			com2_address = "0x3f8";
>  			/* Set com2 IRQ to be what is usually COM1 */
>  			com2_irq = "4";
> +			/* USB Port Power Handling setting. */
> +			pph = "0xf5";
>  		};
>  		pci at 15,2 {
>  			/config/("southbridge/amd/cs5536/ide");

Regards,
Carl-Daniel



From joe at settoplinux.org  Tue Jun  3 13:52:55 2008
From: joe at settoplinux.org (Joseph Smith)
Date: Tue, 3 Jun 2008 07:52:55 -0400
Subject: [coreboot] ram init help on the i82830
In-Reply-To: <de5fd7225ea3f050b203bb4e8ec69944@imap.1and1.com>
References: <bd5a919d8f8c9f3b1843712f5dc06e7d@imap.1and1.com><dd3c80060805272040n58bd85f3x95bfc2cc0928f308@mail.gmail.com><dd3c80060805272104u9efe708h892f6d1f98fa1a1c@mail.gmail.com><2b006022ef73ffcb29f9a499ec98605f@imap.1and1.com><d9895cb58ebc619bc751b8882077b2af@imap.1and1.com><dd3c80060805282246n200d7eb9j3ea094a7fbbc8519@mail.gmail.com><d570aa83b51576676c357b9ee62740ca@imap.1and1.com>
	<de5fd7225ea3f050b203bb4e8ec69944@imap.1and1.com>
Message-ID: <A4E79ED7CDA94E91A6B7B622DC3C2667@smitty2m>


Well, I got everything working now :-)
But I am still getting a crazy kernel crash :-(

Checking 'hlt' instruction... OK.
SMP alternatives: switching to UP code
Freeing SMP alternatives: 14k freed
BUG: unable to handle kernel paging request at virtual address 7c142450
 printing eip:
c047d698
*pde = 00000000
Oops: 0000 [#1]
SMP 
Modules linked in:
CPU:    0
EIP:    0060:[<c047d698>]    Not tainted VLI
EFLAGS: 00010006   (2.6.23.15-80.fc7 #1)
EIP is at kmem_cache_alloc+0x36/0x99
eax: 00000000   ebx: 00000000   ecx: c043af87   edx: 7c142444
esi: dfd36000   edi: 00000286   ebp: 000000d0   esp: c0738ef0
ds: 007b   es: 007b   fs: 00d8  gs: 0000  ss: 0068
Process swapper (pid: 0, ti=c0738000 task=c06f5340 task.ti=c0738000)
Stack: c042dea8 00000000 00000000 00800b00 00800b00 c0738f80 c043af87
00000206 
       00000046 c042dea8 00000000 00000046 c0738fc8 00000000 00800b00
00800b00 
       c0738f80 c042c969 00000000 00000046 00cf9000 fffb6c73 00000000
c100e798 
Call Trace:
 [<c042dea8>] vprintk+0x2a5/0x2e0
 [<c043af87>] alloc_pid+0x16/0x243
 [<c042dea8>] vprintk+0x2a5/0x2e0
 [<c042c969>] do_fork+0x12/0x17e
 [<c073d3e0>] kernel_init+0x0/0x360
 [<c0403358>] kernel_thread+0x8e/0x96
 [<c073d3e0>] kernel_init+0x0/0x360
 [<c0405db4>] kernel_thread_helper+0x0/0x10
 [<c061b775>] rest_init+0x11/0x4a
 [<c073da6c>] start_kernel+0x32c/0x334
 [<c073d177>] unknown_bootoption+0x0/0x195
 =======================
Code: 8b 4c 24 18 9c 58 90 8d b4 26 00 00 00 00 89 c7 fa 90 8d b4 26 00 00
00 00 90 64 a1 08 c0 77 c0 8b 94 86 90 00 00 00 85 d2 74 06 <83> 7a 0c 00 75
17 89 54 24 04 89 f0 89 ea 89 0c 24 83 c9 ff e8 
EIP: [<c047d698>] kmem_cache_alloc+0x36/0x99 SS:ESP 0068:c0738ef0
Kernel panic - not syncing: Attempted to kill the idle task!


Thanks,
Joseph Smith
Set-Top-Linux
www.settoplinux.org




From uwe.schwarz at saxnet.de  Tue Jun  3 15:56:56 2008
From: uwe.schwarz at saxnet.de (Uwe Schwarz)
Date: Tue, 3 Jun 2008 15:56:56 +0200
Subject: [coreboot] Problem with PLL
Message-ID: <1F1F933B-FB37-44F6-AA77-AD8B4EF60BA6@saxnet.de>

Hi,

I'm trying to boot coreboot v2 on a AMD db800 (Geode LX) Board. Around  
30% of my boots it keeps freezing right after "Configuring PLL" during  
pll_reset.

Is there anything I could try to figure out why it's doing that?

// Uwe



From patrick at georgi-clan.de  Tue Jun  3 16:26:46 2008
From: patrick at georgi-clan.de (Patrick Georgi)
Date: Tue, 03 Jun 2008 16:26:46 +0200
Subject: [coreboot] [PATCH][v3] add consoles to v3 lbtable
Message-ID: <484554A6.1030201@georgi-clan.de>

Hi,

when doing the patch for cbv2 to add console information, I promised to 
provide a compatible facility for v3, too.
Sorry it took so long, but here it is.

It currently uses the pci rom init config variable to decide if to add a 
vgatext console, because that's the best we have in v3.
Better ideas are welcome.


Regards,
Patrick Georgi
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: patch-20080603-1-consoles-in-cbv3-lbtable
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20080603/ca372b9a/attachment.ksh>

From patrick at georgi-clan.de  Tue Jun  3 16:30:42 2008
From: patrick at georgi-clan.de (Patrick Georgi)
Date: Tue, 03 Jun 2008 16:30:42 +0200
Subject: [coreboot] [PATCH][v3] Argument order in compiler options
Message-ID: <48455592.3010203@georgi-clan.de>

Hi,

For building coreboot v3 on cygwin, these changes (among others that I 
still clean up) are needed.
Otherwise, it doesn't find the symbols in the libraries (ld arguments 
are parsed right-to-left).

Regards,
Patrick Georgi
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: patch-20080603-2-linker-arguments-order
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20080603/15f1b14d/attachment.ksh>

From jordan.crouse at amd.com  Tue Jun  3 16:44:40 2008
From: jordan.crouse at amd.com (Jordan Crouse)
Date: Tue, 3 Jun 2008 08:44:40 -0600
Subject: [coreboot] patch: clean up cx5536 power handling,
	get power working on	usb port 3 on dbe62
In-Reply-To: <13426df10806022251s7fa8ff0et60f26885261b3c1f@mail.gmail.com>
References: <13426df10806022251s7fa8ff0et60f26885261b3c1f@mail.gmail.com>
Message-ID: <20080603144440.GC505@cosmic.amd.com>

On 02/06/08 22:51 -0700, ron minnich wrote:
> attached
> 
> who knows why I can't get port 4 to go ....
> 
> mystery so far.
> 
> ron

> This patch gets usb port 3 on dbe62 working and sets up a dts-based way to map USB 
> EHCI power control registers to power enables pins 1 and 2. 
> 
> Why doesn't port 4 work? Who knows. That's a problem for another day. 

Are you sure that the enable_USBP4_device = "0" code is working?
The port defaults to being off - you have to specifically enable it
to either be a host or a device.

> Signed-off-by: Ronald G. Minnich <rminnich at gmail.com>
> 
> Index: southbridge/amd/cs5536/cs5536.c
> ===================================================================
> --- southbridge/amd/cs5536/cs5536.c	(revision 687)
> +++ southbridge/amd/cs5536/cs5536.c	(working copy)
> @@ -454,8 +454,34 @@
>  			*(bar + UOCMUX) |= PMUX_HOST;
>  
>  		/* Overcurrent configuration */
> +		printk(BIOS_DEBUG, "UOCCAP is %x\n", *(bar + UOCCAP));
>  		if (sb->enable_USBP4_overcurrent)
>  			*(bar + UOCCAP) |= sb->enable_USBP4_overcurrent;
> +		/* power control. This is bit USB_PWR_EN2 in the UUCO.
> +		 * From Jordan: The kernel never sees a header for
> +		 * this device.  It used to provide a OS visible
> +		 * device, but that was defeatured.  There are still
> +		 * some registers in the block that are useful for the
> +		 * firmware to setup, but nothing that a kernel level
> +		 * driver would need to consume.
> +		 *
> +		 * That said, VSA _does_ provide the header under
> +		 * device ID PCI_DEVICE_ID_AMD_CS5536_OTG, but it is
> +		 * hidden when 0xDEADBEEF is written to config space
> +		 * register 0x7C
> +		 * (southbridge/amd/cs5536/cs5536.c:492).
> +		 *
> +		 * If you need to write the port power settings you
> +		 * can find the resource in the PCI config space and
> +		 * write to it as usual, just make sure that you do it
> +		 * before the block gets DEADBEEFed.
> +		 */

Please get rid of this - you don't need 20 lines of comment to explain
three lines of code.

> +		if (sb->pph) {
> +			*(bar + UOCCAP) &= ~0xff;
> +			*(bar + UOCCAP) |= sb->pph;
> +		}
> +		printk(BIOS_DEBUG, "UOCCAP is %x\n", *(bar + UOCCAP));
> +
>  	}
>  
>  	/* PBz#6466: If the UOC(OTG) device, port 4, is configured as a
> Index: southbridge/amd/cs5536/dts
> ===================================================================
> --- southbridge/amd/cs5536/dts	(revision 687)
> +++ southbridge/amd/cs5536/dts	(working copy)
> @@ -37,8 +37,31 @@
>  	enable_ide_nand_flash = "0";
>  
>  	/* Enable USB Port 4 (0:host 1:device). */
> +	/* This means that the board or whatever would be a "gadget", i.e. 
> +	 * you connect it to a computer and it looks like a storage or camera
> +	 * or printer. 
> +	 */
>  	enable_USBP4_device = "0";
>  
> +	/* This is a tad confusing, but it's hard to make it easy. 
> +	 * These are the PPH bits (port power handling) in the 
> +	 * USB Option Capability register. They are 4 2-bit fields
> +	 * that correspond to the four ports. This chip has two PWR ENABLE
> +	 * pins, and what you can do is, for each of the four fields, 
> +	 * map which port controls which pin. It is common to map 
> +	 * ports 1&2 to PWR_EN_1, and ports 3&4 to PWR_EN_2.
> +	 * The two bit fields are as follows:
> +	 * 00 -- no power ever
> +	 * 01 -- power control in EHCI will turn on both. 
> +	 * 10 -- power control will turn on EN1
> +	 * 11 -- power control will turn on EN2
> +	 * This is all very wiring dependent, and there is a default value,
> +	 * so we let this default to 0, which to the driver means "do nothing", 
> +	 * but if the mainboard sets it, then it will be set into the UOCCAP.
> +	 * for reference, DBE62 seems to want xx111010 -- xx because we 
> +	 * can get port 3 to work, but not port 4.
> +	 */
> +	pph = "0";
>  	/* 0:off, xxxx:overcurrent setting, e.g. 0x3FEA.
>  	 * See CS5536 - Data Book (pages 380-381).
>  	 */
> Index: mainboard/artecgroup/dbe62/dts
> ===================================================================
> --- mainboard/artecgroup/dbe62/dts	(revision 687)
> +++ mainboard/artecgroup/dbe62/dts	(working copy)
> @@ -52,6 +52,8 @@
>  			com2_address = "0x3f8";
>  			/* Set com2 IRQ to be what is usually COM1 */
>  			com2_irq = "4";
> +			/* USB Port Power Handling setting. */
> +			pph = "0xf5";
>  		};
>  		pci at 15,2 {
>  			/config/("southbridge/amd/cs5536/ide");

> -- 
> coreboot mailing list
> coreboot at coreboot.org
> http://www.coreboot.org/mailman/listinfo/coreboot

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




From rminnich at gmail.com  Tue Jun  3 16:54:51 2008
From: rminnich at gmail.com (ron minnich)
Date: Tue, 3 Jun 2008 07:54:51 -0700
Subject: [coreboot] patch: clean up cx5536 power handling,
	get power working on usb port 3 on dbe62
In-Reply-To: <20080603144440.GC505@cosmic.amd.com>
References: <13426df10806022251s7fa8ff0et60f26885261b3c1f@mail.gmail.com>
	<20080603144440.GC505@cosmic.amd.com>
Message-ID: <13426df10806030754h6161dbd3u92884946983c5bda@mail.gmail.com>

On Tue, Jun 3, 2008 at 7:44 AM, Jordan Crouse <jordan.crouse at amd.com> wrote:

>> +             /* power control. This is bit USB_PWR_EN2 in the UUCO.
>> +              * From Jordan: The kernel never sees a header for
>> +              * this device.  It used to provide a OS visible
>> +              * device, but that was defeatured.  There are still
>> +              * some registers in the block that are useful for the
>> +              * firmware to setup, but nothing that a kernel level
>> +              * driver would need to consume.
>> +              *
>> +              * That said, VSA _does_ provide the header under
>> +              * device ID PCI_DEVICE_ID_AMD_CS5536_OTG, but it is
>> +              * hidden when 0xDEADBEEF is written to config space
>> +              * register 0x7C
>> +              * (southbridge/amd/cs5536/cs5536.c:492).
>> +              *
>> +              * If you need to write the port power settings you
>> +              * can find the resource in the PCI config space and
>> +              * write to it as usual, just make sure that you do it
>> +              * before the block gets DEADBEEFed.
>> +              */
>
> Please get rid of this - you don't need 20 lines of comment to explain
> three lines of code.
>

I want that comment somewhere. This stuff is obvious to knowledgeable
amd guys but not as obvious to those of us out here.

thanks

ron



From jordan.crouse at amd.com  Tue Jun  3 17:02:45 2008
From: jordan.crouse at amd.com (Jordan Crouse)
Date: Tue, 3 Jun 2008 09:02:45 -0600
Subject: [coreboot] patch: clean up cx5536 power handling,
	get power working on	usb port 3 on dbe62
In-Reply-To: <13426df10806030754h6161dbd3u92884946983c5bda@mail.gmail.com>
References: <13426df10806022251s7fa8ff0et60f26885261b3c1f@mail.gmail.com>
	<20080603144440.GC505@cosmic.amd.com>
	<13426df10806030754h6161dbd3u92884946983c5bda@mail.gmail.com>
Message-ID: <20080603150245.GE505@cosmic.amd.com>

On 03/06/08 07:54 -0700, ron minnich wrote:
> On Tue, Jun 3, 2008 at 7:44 AM, Jordan Crouse <jordan.crouse at amd.com> wrote:
> 
> >> +             /* power control. This is bit USB_PWR_EN2 in the UUCO.
> >> +              * From Jordan: The kernel never sees a header for
> >> +              * this device.  It used to provide a OS visible
> >> +              * device, but that was defeatured.  There are still
> >> +              * some registers in the block that are useful for the
> >> +              * firmware to setup, but nothing that a kernel level
> >> +              * driver would need to consume.
> >> +              *
> >> +              * That said, VSA _does_ provide the header under
> >> +              * device ID PCI_DEVICE_ID_AMD_CS5536_OTG, but it is
> >> +              * hidden when 0xDEADBEEF is written to config space
> >> +              * register 0x7C
> >> +              * (southbridge/amd/cs5536/cs5536.c:492).
> >> +              *
> >> +              * If you need to write the port power settings you
> >> +              * can find the resource in the PCI config space and
> >> +              * write to it as usual, just make sure that you do it
> >> +              * before the block gets DEADBEEFed.
> >> +              */
> >
> > Please get rid of this - you don't need 20 lines of comment to explain
> > three lines of code.
> >
> 
> I want that comment somewhere. This stuff is obvious to knowledgeable
> amd guys but not as obvious to those of us out here.

I would agree, if any of the comment actually explained what you are
doing here.  If there needs to be documentation about how DEADBEEF works,
then so be it, but this comment is out of place and, IMHO not very well
written.

Jordan

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




From rminnich at gmail.com  Tue Jun  3 17:02:20 2008
From: rminnich at gmail.com (ron minnich)
Date: Tue, 3 Jun 2008 08:02:20 -0700
Subject: [coreboot] patch: clean up cx5536 power handling,
	get power working on usb port 3 on dbe62
In-Reply-To: <20080603150245.GE505@cosmic.amd.com>
References: <13426df10806022251s7fa8ff0et60f26885261b3c1f@mail.gmail.com>
	<20080603144440.GC505@cosmic.amd.com>
	<13426df10806030754h6161dbd3u92884946983c5bda@mail.gmail.com>
	<20080603150245.GE505@cosmic.amd.com>
Message-ID: <13426df10806030802i55912ce6ib4aef8975a438126@mail.gmail.com>

try this.

ron
-------------- next part --------------
A non-text attachment was scrubbed...
Name: dbe62usb.diff
Type: text/x-diff
Size: 3923 bytes
Desc: not available
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20080603/78ebe261/attachment.bin>

From jordan.crouse at amd.com  Tue Jun  3 17:06:11 2008
From: jordan.crouse at amd.com (Jordan Crouse)
Date: Tue, 3 Jun 2008 09:06:11 -0600
Subject: [coreboot] patch: clean up cx5536 power handling,
	get power working on	usb port 3 on dbe62
In-Reply-To: <13426df10806030802i55912ce6ib4aef8975a438126@mail.gmail.com>
References: <13426df10806022251s7fa8ff0et60f26885261b3c1f@mail.gmail.com>
	<20080603144440.GC505@cosmic.amd.com>
	<13426df10806030754h6161dbd3u92884946983c5bda@mail.gmail.com>
	<20080603150245.GE505@cosmic.amd.com>
	<13426df10806030802i55912ce6ib4aef8975a438126@mail.gmail.com>
Message-ID: <20080603150611.GF505@cosmic.amd.com>

Better.  Thanks.

On 03/06/08 08:02 -0700, ron minnich wrote:
> try this.
> 
> ron

> This patch gets usb port 3 on dbe62 working and sets up a dts-based way to map USB 
> EHCI power control registers to power enables pins 1 and 2. 
> 
> Why doesn't port 4 work? Who knows. That's a problem for another day. 
> 
> Signed-off-by: Ronald G. Minnich <rminnich at gmail.com>
> Index: southbridge/amd/cs5536/cs5536.c
> ===================================================================
> --- southbridge/amd/cs5536/cs5536.c	(revision 687)
> +++ southbridge/amd/cs5536/cs5536.c	(working copy)
> @@ -454,8 +454,16 @@
>  			*(bar + UOCMUX) |= PMUX_HOST;
>  
>  		/* Overcurrent configuration */
> +		printk(BIOS_DEBUG, "UOCCAP is %x\n", *(bar + UOCCAP));
>  		if (sb->enable_USBP4_overcurrent)
>  			*(bar + UOCCAP) |= sb->enable_USBP4_overcurrent;
> +		/* power control. see comment in the dts for these bits */
> +		if (sb->pph) {
> +			*(bar + UOCCAP) &= ~0xff;
> +			*(bar + UOCCAP) |= sb->pph;
> +		}
> +		printk(BIOS_DEBUG, "UOCCAP is %x\n", *(bar + UOCCAP));
> +
>  	}
>  
>  	/* PBz#6466: If the UOC(OTG) device, port 4, is configured as a
> @@ -481,7 +489,17 @@
>  		}
>  	}
>  
> -	/* Disable virtual PCI UDC and OTG headers. */
> +	/* Disable virtual PCI UDC and OTG headers.  The kernel never
> +	 * sees a header for this device.  It used to provide an OS
> +	 * visible device, but that was defeatured.  There are still
> +	 * some registers in the block that are useful for the firmware
> +	 * to setup, but nothing that a kernel level driver would need
> +	 * to consume.
> +	 *
> +	 * As you can see above, VSA does provide the header under
> +	 * device ID PCI_DEVICE_ID_AMD_CS5536_OTG, but it is hidden
> +	 * when 0xDEADBEEF is written to config space register 0x7C.
> +	 */
>  	dev = dev_find_pci_device(PCI_VENDOR_ID_AMD,
>  			      PCI_DEVICE_ID_AMD_CS5536_UDC, 0);
>  	if (dev)
> Index: southbridge/amd/cs5536/dts
> ===================================================================
> --- southbridge/amd/cs5536/dts	(revision 687)
> +++ southbridge/amd/cs5536/dts	(working copy)
> @@ -36,9 +36,34 @@
>  	/* 0:IDE 1:FLASH, if you are using NAND flash instead of IDE drive. */
>  	enable_ide_nand_flash = "0";
>  
> -	/* Enable USB Port 4 (0:host 1:device). */
> +	/* Enable USB Port 4 (0:host 1:device). 
> +	 * This means that the board or whatever would be a "gadget", i.e. 
> +	 * you connect it to a computer and it looks like a storage or camera
> +	 * or printer. 
> +	 */
>  	enable_USBP4_device = "0";
>  
> +	/* This is a tad confusing, but it's hard to make it easy. 
> +	 * These are the PPH bits (port power handling) in the 
> +	 * USB Option Capability register. They are 4 2-bit fields
> +	 * that correspond to the four ports. This chip has two PWR ENABLE
> +	 * pins, and what you can do is, for each of the four fields, 
> +	 * map which port controls which pin. It is common to map 
> +	 * ports 1&2 to PWR_EN_1, and ports 3&4 to PWR_EN_2.
> +	 * The two bit fields are as follows:
> +	 * 00 -- no power ever
> +	 * 01 -- power control in EHCI will turn on both. 
> +	 * 10 -- power control will turn on EN1
> +	 * 11 -- power control will turn on EN2
> +	 * This is all very wiring dependent, 
> +	 * and there is a default hardware value (0xea),
> +	 * meaning port 4 is EN2 and the rest are EN1. 
> +	 * So we let this default to 0, which to the driver means "do nothing", 
> +	 * but if the mainboard sets it, then it will be set into the UOCCAP.
> +	 * for reference, DBE62 seems to want xx111010 -- xx because we 
> +	 * can get port 3 to work, but not port 4.
> +	 */
> +	pph = "0";
>  	/* 0:off, xxxx:overcurrent setting, e.g. 0x3FEA.
>  	 * See CS5536 - Data Book (pages 380-381).
>  	 */
> Index: mainboard/artecgroup/dbe62/dts
> ===================================================================
> --- mainboard/artecgroup/dbe62/dts	(revision 687)
> +++ mainboard/artecgroup/dbe62/dts	(working copy)
> @@ -52,6 +52,8 @@
>  			com2_address = "0x3f8";
>  			/* Set com2 IRQ to be what is usually COM1 */
>  			com2_irq = "4";
> +			/* USB Port Power Handling setting. */
> +			pph = "0xf5";
>  		};
>  		pci at 15,2 {
>  			/config/("southbridge/amd/cs5536/ide");


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




From svn at coreboot.org  Tue Jun  3 17:22:17 2008
From: svn at coreboot.org (svn at coreboot.org)
Date: Tue,  3 Jun 2008 17:22:17 +0200
Subject: [coreboot] r688 - in coreboot-v3: mainboard/artecgroup/dbe62
	southbridge/amd/cs5536
Message-ID: <mailman.1618.1355071330.16123.coreboot@coreboot.org>

Author: rminnich
Date: 2008-06-03 17:22:16 +0200 (Tue, 03 Jun 2008)
New Revision: 688

Modified:
   coreboot-v3/mainboard/artecgroup/dbe62/dts
   coreboot-v3/southbridge/amd/cs5536/cs5536.c
   coreboot-v3/southbridge/amd/cs5536/dts
Log:
This patch gets usb port 3 on dbe62 working and sets up a dts-based way to map 
USB EHCI power control registers to power enables pins 1 and 2. 

Why doesn't port 4 work? Who knows. That's a problem for another day. 

Signed-off-by: Ronald G. Minnich <rminnich at gmail.com>


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


Modified: coreboot-v3/mainboard/artecgroup/dbe62/dts
===================================================================
--- coreboot-v3/mainboard/artecgroup/dbe62/dts	2008-05-28 01:00:36 UTC (rev 687)
+++ coreboot-v3/mainboard/artecgroup/dbe62/dts	2008-06-03 15:22:16 UTC (rev 688)
@@ -52,6 +52,8 @@
 			com2_address = "0x3f8";
 			/* Set com2 IRQ to be what is usually COM1 */
 			com2_irq = "4";
+			/* USB Port Power Handling setting. */
+			pph = "0xf5";
 		};
 		pci at 15,2 {
 			/config/("southbridge/amd/cs5536/ide");

Modified: coreboot-v3/southbridge/amd/cs5536/cs5536.c
===================================================================
--- coreboot-v3/southbridge/amd/cs5536/cs5536.c	2008-05-28 01:00:36 UTC (rev 687)
+++ coreboot-v3/southbridge/amd/cs5536/cs5536.c	2008-06-03 15:22:16 UTC (rev 688)
@@ -454,8 +454,16 @@
 			*(bar + UOCMUX) |= PMUX_HOST;
 
 		/* Overcurrent configuration */
+		printk(BIOS_DEBUG, "UOCCAP is %x\n", *(bar + UOCCAP));
 		if (sb->enable_USBP4_overcurrent)
 			*(bar + UOCCAP) |= sb->enable_USBP4_overcurrent;
+		/* power control. see comment in the dts for these bits */
+		if (sb->pph) {
+			*(bar + UOCCAP) &= ~0xff;
+			*(bar + UOCCAP) |= sb->pph;
+		}
+		printk(BIOS_DEBUG, "UOCCAP is %x\n", *(bar + UOCCAP));
+
 	}
 
 	/* PBz#6466: If the UOC(OTG) device, port 4, is configured as a
@@ -481,7 +489,17 @@
 		}
 	}
 
-	/* Disable virtual PCI UDC and OTG headers. */
+	/* Disable virtual PCI UDC and OTG headers.  The kernel never
+	 * sees a header for this device.  It used to provide an OS
+	 * visible device, but that was defeatured.  There are still
+	 * some registers in the block that are useful for the firmware
+	 * to setup, but nothing that a kernel level driver would need
+	 * to consume.
+	 *
+	 * As you can see above, VSA does provide the header under
+	 * device ID PCI_DEVICE_ID_AMD_CS5536_OTG, but it is hidden
+	 * when 0xDEADBEEF is written to config space register 0x7C.
+	 */
 	dev = dev_find_pci_device(PCI_VENDOR_ID_AMD,
 			      PCI_DEVICE_ID_AMD_CS5536_UDC, 0);
 	if (dev)

Modified: coreboot-v3/southbridge/amd/cs5536/dts
===================================================================
--- coreboot-v3/southbridge/amd/cs5536/dts	2008-05-28 01:00:36 UTC (rev 687)
+++ coreboot-v3/southbridge/amd/cs5536/dts	2008-06-03 15:22:16 UTC (rev 688)
@@ -36,9 +36,34 @@
 	/* 0:IDE 1:FLASH, if you are using NAND flash instead of IDE drive. */
 	enable_ide_nand_flash = "0";
 
-	/* Enable USB Port 4 (0:host 1:device). */
+	/* Enable USB Port 4 (0:host 1:device). 
+	 * This means that the board or whatever would be a "gadget", i.e. 
+	 * you connect it to a computer and it looks like a storage or camera
+	 * or printer. 
+	 */
 	enable_USBP4_device = "0";
 
+	/* This is a tad confusing, but it's hard to make it easy. 
+	 * These are the PPH bits (port power handling) in the 
+	 * USB Option Capability register. They are 4 2-bit fields
+	 * that correspond to the four ports. This chip has two PWR ENABLE
+	 * pins, and what you can do is, for each of the four fields, 
+	 * map which port controls which pin. It is common to map 
+	 * ports 1&2 to PWR_EN_1, and ports 3&4 to PWR_EN_2.
+	 * The two bit fields are as follows:
+	 * 00 -- no power ever
+	 * 01 -- power control in EHCI will turn on both. 
+	 * 10 -- power control will turn on EN1
+	 * 11 -- power control will turn on EN2
+	 * This is all very wiring dependent, 
+	 * and there is a default hardware value (0xea),
+	 * meaning port 4 is EN2 and the rest are EN1. 
+	 * So we let this default to 0, which to the driver means "do nothing", 
+	 * but if the mainboard sets it, then it will be set into the UOCCAP.
+	 * for reference, DBE62 seems to want xx111010 -- xx because we 
+	 * can get port 3 to work, but not port 4.
+	 */
+	pph = "0";
 	/* 0:off, xxxx:overcurrent setting, e.g. 0x3FEA.
 	 * See CS5536 - Data Book (pages 380-381).
 	 */




From rminnich at gmail.com  Tue Jun  3 17:22:52 2008
From: rminnich at gmail.com (ron minnich)
Date: Tue, 3 Jun 2008 08:22:52 -0700
Subject: [coreboot] patch: clean up cx5536 power handling,
	get power working on usb port 3 on dbe62
In-Reply-To: <20080603150611.GF505@cosmic.amd.com>
References: <13426df10806022251s7fa8ff0et60f26885261b3c1f@mail.gmail.com>
	<20080603144440.GC505@cosmic.amd.com>
	<13426df10806030754h6161dbd3u92884946983c5bda@mail.gmail.com>
	<20080603150245.GE505@cosmic.amd.com>
	<13426df10806030802i55912ce6ib4aef8975a438126@mail.gmail.com>
	<20080603150611.GF505@cosmic.amd.com>
Message-ID: <13426df10806030822s33ef291dw77e7da25ef29b881@mail.gmail.com>

Committed revision 688.



From mylesgw at gmail.com  Tue Jun  3 17:56:26 2008
From: mylesgw at gmail.com (Myles Watson)
Date: Tue, 3 Jun 2008 09:56:26 -0600
Subject: [coreboot] memtest x86 64-bit issues
In-Reply-To: <4cbe64c0bc7c649fe7e755d05192485a@imap.1and1.com>
References: <4cbe64c0bc7c649fe7e755d05192485a@imap.1and1.com>
Message-ID: <002a01c8c592$61b61880$0023040a@chimp>


> -----Original Message-----
> From: coreboot-bounces at coreboot.org [mailto:coreboot-bounces at coreboot.org]
> On Behalf Of Joseph Smith
> Sent: Monday, June 02, 2008 7:35 PM
> To: coreboot at coreboot.org
> Subject: [coreboot] memtest x86 64-bit issues
> 
> 
> Hello,
> I can't seem to build memtest on my 64-bit version of FC8. Can someone
> just
> send me a 32-bit memtest elf file?

Joe,

Have you tried using buildrom?  It builds memtest fine for me on a 64-bit FC
machine.

If there's some reason you don't want to use buildrom, you could still look
at how it sets up the build.

Thanks,
Myles






From mylesgw at gmail.com  Tue Jun  3 18:00:11 2008
From: mylesgw at gmail.com (Myles Watson)
Date: Tue, 3 Jun 2008 10:00:11 -0600
Subject: [coreboot] Newbie questions
In-Reply-To: <F8090380-722E-4E5A-8C6D-F5B890B40385@atomic-x.co.uk>
References: <F8090380-722E-4E5A-8C6D-F5B890B40385@atomic-x.co.uk>
Message-ID: <002b01c8c592$e7ccb9b0$0023040a@chimp>



> -----Original Message-----
> From: coreboot-bounces at coreboot.org [mailto:coreboot-bounces at coreboot.org]
> On Behalf Of Richard Green
> Sent: Saturday, May 31, 2008 1:42 PM
> To: coreboot at coreboot.org
> Subject: [coreboot] Newbie questions
> 
> Hi,
> 
> I'm looking to build a headless system, mainly for messing around with
> Linux which I'd like to access remotely and via a serial console
> without the need for a keyboard and monitor. Unfortunately I don't
> really have the budget to buy a server motherboard and the kind of
> processor that goes with it (I already have a core 2 duo, so just plan
> to get a suitable motherboard for that), and so wont be able to run it
> headless and get a serial console from boot. I do realise that Linux
> can provide a serial console from grub, but I'd like to be able to
> reinstall and do everything without a monitor in the house.
> 
> My question is; If I got a supported motherboard and installed
> coreboot upon it, would I be able to configure it so that all output
> from power-on was redirected to a serial port on the motherboard, and
> all configuration could be completed using this method so that I could
> boot and install operating systems from CD, etc using just the serial
> console? Would it be completely supported by Linux or would there be
> any noticeable difference to, say using a standard motherboard with a
> standard BIOS?

Rich,

You can configure Coreboot to send all of its output to the serial port.
The rest of the functionality that you want depends on other software.  For
example, if you're using an installation CD for Fedora, it would have to
send all of its output to the serial port for this to work.  The Coreboot
part is easy, though.

Thanks,
Myles





From Marc.Jones at amd.com  Tue Jun  3 18:39:16 2008
From: Marc.Jones at amd.com (Marc Jones)
Date: Tue, 3 Jun 2008 10:39:16 -0600
Subject: [coreboot] Problem with PLL
In-Reply-To: <1F1F933B-FB37-44F6-AA77-AD8B4EF60BA6@saxnet.de>
References: <1F1F933B-FB37-44F6-AA77-AD8B4EF60BA6@saxnet.de>
Message-ID: <484573B4.9050607@amd.com>

Uwe Schwarz wrote:
> Hi,
> 
> I'm trying to boot coreboot v2 on a AMD db800 (Geode LX) Board. Around  
> 30% of my boots it keeps freezing right after "Configuring PLL" during  
> pll_reset.
> 
> Is there anything I could try to figure out why it's doing that?
> 
> // Uwe
> 

Uwe,
Failing sometimes may mean that there is a hardware problem but here are 
some things you can check.

What is the port80 code when it fails?

Can you narrow down the line that fails, northbridge\amd\lx\pll_reset.c?

If it fails in the reset you can try making the pll lock time longer but 
I doubt that it will help.
msrGlcpSysRstpll.lo |= (0xFF << RSTPPL_LOWER_HOLD_COUNT_SHIFT);

You can check the GLCP_SYS_RSTPLL value that is being set.

Marc


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




From segher at kernel.crashing.org  Tue Jun  3 19:50:20 2008
From: segher at kernel.crashing.org (Segher Boessenkool)
Date: Tue, 3 Jun 2008 19:50:20 +0200
Subject: [coreboot] [PATCH][v3] Argument order in compiler options
In-Reply-To: <48455592.3010203@georgi-clan.de>
References: <48455592.3010203@georgi-clan.de>
Message-ID: <d195a5ac565bc3746bd78e1f1bbb0db1@kernel.crashing.org>

> For building coreboot v3 on cygwin, these changes (among others that I 
> still clean up) are needed.
> Otherwise, it doesn't find the symbols in the libraries (ld arguments 
> are parsed right-to-left).

No they're not.  Object files are linked left to right; object files
in archives are only included if any of their symbols are required.
Because of that, in general, libraries should be last on the command
line.

Patch looks good though.


Segher




From mylesgw at gmail.com  Tue Jun  3 21:03:22 2008
From: mylesgw at gmail.com (Myles Watson)
Date: Tue, 3 Jun 2008 13:03:22 -0600
Subject: [coreboot] LinuxTag 2008 Status
In-Reply-To: <20080602234805.GB30270@cosmic.amd.com>
References: <20080530204441.GA14200@cosmic.amd.com>
	<00a601c8c2a8$df85a0b0$0023040a@chimp>
	<20080602234805.GB30270@cosmic.amd.com>
Message-ID: <003701c8c5ac$7f8bbc10$0023040a@chimp>



> -----Original Message-----
> From: Jordan Crouse [mailto:jordan.crouse at amd.com]
> Sent: Monday, June 02, 2008 5:48 PM
> To: Myles Watson
> Cc: 'ron minnich'; coreboot at coreboot.org
> Subject: Re: LinuxTag 2008 Status
> 
> On 30/05/08 16:59 -0600, Myles Watson wrote:
> >
> > > But when you look closer, the number of possible modes explodes.  As
> an
> > > example:
> > >
> > >  - You may want to add a timeout to the menu, so that if somebody
> doesn't
> > >  press the hotkey, a default payload is chosen.
> > >  - When chaining, some payloads will be opt in (press F1 for setup),
> some
> > >  will be opt out (press F2 to skip), and others will always run
> > >  - Uwe expressed a desire to select a chain from the menu
> > >
> > > Everything is further complicated by the fact that we can add a new
> > > payload
> > > to the LAR at any time, which makes it very difficult to specific the
> > > configuration at bayou compile time.
> >
> > How about the name of the lar entry for the payload (since we can store
> the
> > user-friendly name in the notes.)  The default payload is the one named
> > "payload" or "normal" or "default".  Then any number of payloads with
> their
> > attributes can be added, but the default still works.
> 
> I like this, but allow me to play devil's advocate for a second.  There
> might be a few flies in the ointment.  The dynamic nature of LAR forces
> us to consider complex scenarios that otherwise wouldn't be a factor.
> What if you want to change the default payload?  If the name isn't shorter
> then payloads/default, then there will be much shifting of bytes, which
> is dangerous on the ROM (or rather, no less dangerous then writing
> a new ROM).

Right now we don't do partial writes, do we?  If we did, this isn't
dangerous as long as we rewrite the entire lar entry, is it?

> The other thing that concerns me is that the person building the LAR needs
> to make the conscious decision to name one of the payloads
> payload/default.

No matter what we choose to do, the user will have to make a conscious
decision about which payload is default.  If there isn't a default it will
still work, and they'll be more careful next time they build the ROM. :)

> Sure we could make the LAR binary handle the magic, but that would
> be just another flag in a cast of thousands.  We already experience
> a bit of this pain already.  In lieu of a magic number in the LAR header
> or in the SELF header, bayou currently checks for the name prefix
> 'payload/'
> and assumes that is a payload.  I have already forgotten to append
> 'payload/' several times (until I got the Makefile to do it for me).
> I believe that this will cause problems down the road - not everybody
> will be using buildrom.

You're right, we still have considerable evangelism to do.

> All that said, I think that this is the best suggestion so far - it is
> easy to implement, and at least gets us further down the path.

I'm looking forward to seeing the next incarnation.

Thanks,
Myles





From joe at settoplinux.org  Tue Jun  3 21:30:06 2008
From: joe at settoplinux.org (Joseph Smith)
Date: Tue, 03 Jun 2008 15:30:06 -0400
Subject: [coreboot] memtest x86 64-bit issues
In-Reply-To: <002a01c8c592$61b61880$0023040a@chimp>
References: <4cbe64c0bc7c649fe7e755d05192485a@imap.1and1.com>
	<002a01c8c592$61b61880$0023040a@chimp>
Message-ID: <e08b5bd8d0f42b26043e2b19c8858090@imap.1and1.com>




On Tue, 3 Jun 2008 09:56:26 -0600, "Myles Watson" <mylesgw at gmail.com>
wrote:
> 
> Have you tried using buildrom?  It builds memtest fine for me on a 64-bit
> FC
> machine.
>
How do you do this?
> 
> If there's some reason you don't want to use buildrom, you could still
> look
> at how it sets up the build.
> 
The makefile has the CC -m32 option to build it as 32-bit but this
obviously is not working?

-- 
Thanks,
Joseph Smith
Set-Top-Linux
www.settoplinux.org




From mylesgw at gmail.com  Tue Jun  3 21:36:03 2008
From: mylesgw at gmail.com (Myles Watson)
Date: Tue, 3 Jun 2008 13:36:03 -0600
Subject: [coreboot] memtest x86 64-bit issues
In-Reply-To: <e08b5bd8d0f42b26043e2b19c8858090@imap.1and1.com>
References: <4cbe64c0bc7c649fe7e755d05192485a@imap.1and1.com>
	<002a01c8c592$61b61880$0023040a@chimp>
	<e08b5bd8d0f42b26043e2b19c8858090@imap.1and1.com>
Message-ID: <004001c8c5b1$101209c0$0023040a@chimp>



> On Tue, 3 Jun 2008 09:56:26 -0600, "Myles Watson" <mylesgw at gmail.com>
> wrote:
> >
> > Have you tried using buildrom?  It builds memtest fine for me on a 64-
> bit
> > FC
> > machine.
> >
> How do you do this?

1. I check out buildrom:

svn co svn://coreboot.org/buildrom

2. cd buildrom/buildrom-devel

3. Configure it 

make configure

Select your platform and payload (memtest86)

4. Exit config
5. Type make

There will be an elf file called memtest86-payload.elf (or something like
that) in the buildrom/buildrom-devel/deploy directory

I hope that was what you were asking.

Thanks,
Myles





From bari at onelabs.com  Tue Jun  3 21:53:43 2008
From: bari at onelabs.com (bari)
Date: Tue, 03 Jun 2008 14:53:43 -0500
Subject: [coreboot] Epia-CN USB Does Not init Properly with LAB
Message-ID: <4845A147.3030307@onelabs.com>

The epia-cn works fine with FILO, except for the lack of VGA console. X 
however works fine. When you drop out of X the screen is left with 
vertical bars until X restarts. The PS2 keyboard is still responsive 
when out of X.

The epia-cn does not init the usb controler properly with LAB. Does 
anyone have any idea what the kernel in LAB may be getting wrong?

Serial debug output with LAB:
http://pastebin.com/m3320b15f

The kernel is built with buildrom along with kexec and the initrd.
Linux version 2.6.22.2BuildROML-A-BV1.0

Coreboot is used to build coreboot and the config.lb uses the elf.lzma 
from buildrom as a payload.

# cat interrupts
           CPU0       
  0:     173636    XT-PIC-XT        timer
  2:          0    XT-PIC-XT        cascade
  4:         65    XT-PIC-XT        serial
  9:          0    XT-PIC-XT        acpi
 10:     100000    XT-PIC-XT        uhci_hcd:usb3, uhci_hcd:usb4
 11:     100000    XT-PIC-XT        uhci_hcd:usb1, uhci_hcd:usb2
 14:          1    XT-PIC-XT        ide0
 15:          1    XT-PIC-XT        ide1
NMI:          0 
LOC:          0 
ERR:          0
MIS:          0

# cat ioports
0000-001f : dma1
0020-0021 : pic1
0040-0043 : timer0
0050-0053 : timer1
0060-006f : keyboard
0080-008f : dma page reg
00a0-00a1 : pic2
00c0-00df : dma2
00f0-00ff : fpu
0170-0177 : 0000:00:0f.0
  0170-0177 : ide1
01f0-01f7 : 0000:00:0f.0
  01f0-01f7 : ide0
0376-0376 : 0000:00:0f.0
  0376-0376 : ide1
03f6-03f6 : 0000:00:0f.0
  03f6-03f6 : ide0
03f8-03ff : serial
0400-047f : pnp 00:02
  0400-0403 : ACPI PM1a_EVT_BLK
  0404-0405 : ACPI PM1a_CNT_BLK
  0408-040b : ACPI PM_TMR
  0410-0415 : ACPI CPU throttle
  0420-0423 : ACPI GPE0_BLK
0500-050f : pnp 00:02
  0500-0507 : vt596_smbus
0cf8-0cff : PCI conf1
1000-10ff : 0000:00:11.5
1400-14ff : 0000:00:12.0
  1400-14ff : via-rhine
1800-181f : 0000:00:10.0
  1800-181f : uhci_hcd
1820-183f : 0000:00:10.1
  1820-183f : uhci_hcd
1840-185f : 0000:00:10.2
  1840-185f : uhci_hcd
1860-187f : 0000:00:10.3
  1860-187f : uhci_hcd
1880-188f : 0000:00:0f.0
  1880-1887 : ide0
  1888-188f : ide1
d000-dfff : PCI Bus #01

# cat devices
Character devices:
  1 mem
  2 pty
  3 ttyp
  4 /dev/vc/0
  4 tty
  4 ttyS
  5 /dev/tty
  5 /dev/console
  5 /dev/ptmx
  7 vcs
 10 misc
 13 input
128 ptm
136 pts
180 usb
189 usb_device
254 usb_endpoint

Block devices:
  1 ramdisk
  3 ide0
  7 loop
  8 sd
 22 ide1
 65 sd
 66 sd
 67 sd
 68 sd
 69 sd
 70 sd
 71 sd
128 sd
129 sd
130 sd
131 sd
132 sd
133 sd
134 sd
135 sd

# cat mounts
rootfs / rootfs rw 0 0
proc /proc proc rw 0 0
usbfs /proc/bus/usb usbfs rw 0 0

# cat meminfo
MemTotal:       907084 kB
MemFree:        902840 kB
Buffers:             0 kB
Cached:            484 kB
SwapCached:          0 kB
Active:            352 kB
Inactive:          256 kB
SwapTotal:           0 kB
SwapFree:            0 kB
Dirty:               0 kB
Writeback:           0 kB
AnonPages:         144 kB
Mapped:            172 kB
Slab:                0 kB
SReclaimable:        0 kB
SUnreclaim:          0 kB
PageTables:         36 kB
NFS_Unstable:        0 kB
Bounce:              0 kB
CommitLimit:    453540 kB
Committed_AS:      412 kB
VmallocTotal:   122576 kB
VmallocUsed:         0 kB
VmallocChunk:   122576 kB

# cat stat
cpu  1 0 106 75454 0 210 28 0
cpu0 1 0 106 75454 0 210 28 0
intr 389895 189491 0 0 0 402 0 0 0 0 0 100000 100000 0 0 1 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
ctxt 6514
btime 1212515072
processes 859
procs_running 2
procs_blocked 0

# cat version
Linux version 2.6.22.2BuildROML-A-BV1.0 (ly at ly-d) (gcc version 4.1.3 20070929 (prerelease) (Ubuntu 4.1.2-16ubuntu2)) #8 PREEMPT Tue Jun 3 12:18:28 CDT 2008


-Bari





From jordan.crouse at amd.com  Tue Jun  3 22:22:23 2008
From: jordan.crouse at amd.com (Jordan Crouse)
Date: Tue, 3 Jun 2008 14:22:23 -0600
Subject: [coreboot] LinuxTag 2008 Status
In-Reply-To: <003701c8c5ac$7f8bbc10$0023040a@chimp>
References: <20080530204441.GA14200@cosmic.amd.com>
	<00a601c8c2a8$df85a0b0$0023040a@chimp>
	<20080602234805.GB30270@cosmic.amd.com>
	<003701c8c5ac$7f8bbc10$0023040a@chimp>
Message-ID: <20080603202223.GE2398@cosmic.amd.com>

On 03/06/08 13:03 -0600, Myles Watson wrote:
> 
> 
> > -----Original Message-----
> > From: Jordan Crouse [mailto:jordan.crouse at amd.com]
> > Sent: Monday, June 02, 2008 5:48 PM
> > To: Myles Watson
> > Cc: 'ron minnich'; coreboot at coreboot.org
> > Subject: Re: LinuxTag 2008 Status
> > 
> > On 30/05/08 16:59 -0600, Myles Watson wrote:
> > >
> > > > But when you look closer, the number of possible modes explodes.  As
> > an
> > > > example:
> > > >
> > > >  - You may want to add a timeout to the menu, so that if somebody
> > doesn't
> > > >  press the hotkey, a default payload is chosen.
> > > >  - When chaining, some payloads will be opt in (press F1 for setup),
> > some
> > > >  will be opt out (press F2 to skip), and others will always run
> > > >  - Uwe expressed a desire to select a chain from the menu
> > > >
> > > > Everything is further complicated by the fact that we can add a new
> > > > payload
> > > > to the LAR at any time, which makes it very difficult to specific the
> > > > configuration at bayou compile time.
> > >
> > > How about the name of the lar entry for the payload (since we can store
> > the
> > > user-friendly name in the notes.)  The default payload is the one named
> > > "payload" or "normal" or "default".  Then any number of payloads with
> > their
> > > attributes can be added, but the default still works.
> > 
> > I like this, but allow me to play devil's advocate for a second.  There
> > might be a few flies in the ointment.  The dynamic nature of LAR forces
> > us to consider complex scenarios that otherwise wouldn't be a factor.
> > What if you want to change the default payload?  If the name isn't shorter
> > then payloads/default, then there will be much shifting of bytes, which
> > is dangerous on the ROM (or rather, no less dangerous then writing
> > a new ROM).
> 
> Right now we don't do partial writes, do we?  If we did, this isn't
> dangerous as long as we rewrite the entire lar entry, is it?

You are right, we don't do partial writes right now, but it is the
800 pound gorilla in the room.  Everything about the design of LAR
is based around the concept of partial writes, so we really can't 
ignore it.

One of our problems is that we have made partial writes a high
priority, but we haven't clearly defined how they are going to work.
Adding new code to an existing ROM isn't a difficult concept, but when
it comes to changing or replacing blobs, it gets very vague, and IMHO
very scary.  None of our current v3 platforms support fallback, so just
one blown sector is death, even if LAR can detect it and print 
a "gee, we're sorry but the ROM is corrupted message".  I am having 
trouble being convinced that this is any safer then writing a full ROM,
but thats off-topic for this message.

The point is that we have to always be aware that the LAR could change
from boot to boot. If we need to support a dynamic LAR, then we need
to keep the bayou related complexity to a minimum, or at least as low
as the circumstances will allow.

> > The other thing that concerns me is that the person building the LAR needs
> > to make the conscious decision to name one of the payloads
> > payload/default.
> 
> No matter what we choose to do, the user will have to make a conscious
> decision about which payload is default.  If there isn't a default it will
> still work, and they'll be more careful next time they build the ROM. :)

Indeed.  But I think my main concern is that on one hand we treat 
payloads like any other LAR blob, but on the other hand we put
restrictions on the name and make it the developers burden to get it
right.

> > Sure we could make the LAR binary handle the magic, but that would
> > be just another flag in a cast of thousands.  We already experience
> > a bit of this pain already.  In lieu of a magic number in the LAR header
> > or in the SELF header, bayou currently checks for the name prefix
> > 'payload/'
> > and assumes that is a payload.  I have already forgotten to append
> > 'payload/' several times (until I got the Makefile to do it for me).
> > I believe that this will cause problems down the road - not everybody
> > will be using buildrom.
> 
> You're right, we still have considerable evangelism to do.

I like your moxie! :)

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




From joe at settoplinux.org  Tue Jun  3 22:55:24 2008
From: joe at settoplinux.org (Joseph Smith)
Date: Tue, 03 Jun 2008 16:55:24 -0400
Subject: [coreboot] memtest x86 64-bit issues
In-Reply-To: <004001c8c5b1$101209c0$0023040a@chimp>
References: <4cbe64c0bc7c649fe7e755d05192485a@imap.1and1.com>
	<002a01c8c592$61b61880$0023040a@chimp>
	<e08b5bd8d0f42b26043e2b19c8858090@imap.1and1.com>
	<004001c8c5b1$101209c0$0023040a@chimp>
Message-ID: <2a3c8717ba35f38a07a391111923f490@imap.1and1.com>




On Tue, 3 Jun 2008 13:36:03 -0600, "Myles Watson" <mylesgw at gmail.com>
wrote:
> 
> 
>> On Tue, 3 Jun 2008 09:56:26 -0600, "Myles Watson" <mylesgw at gmail.com>
>> wrote:
>> >
>> > Have you tried using buildrom?  It builds memtest fine for me on a 64-
>> bit
>> > FC
>> > machine.
>> >
>> How do you do this?
> 
> 1. I check out buildrom:
> 
> svn co svn://coreboot.org/buildrom
> 
> 2. cd buildrom/buildrom-devel
> 
> 3. Configure it
> 
> make configure
> 
> Select your platform and payload (memtest86)
> 
> 4. Exit config
> 5. Type make
> 
> There will be an elf file called memtest86-payload.elf (or something like
> that) in the buildrom/buildrom-devel/deploy directory
> 
> I hope that was what you were asking.
> 
Yes
Thanks Myles, I have to admit I haven't messed around with buildrom too
much.
-- 
Thanks,
Joseph Smith
Set-Top-Linux
www.settoplinux.org




From joe at settoplinux.org  Wed Jun  4 04:59:41 2008
From: joe at settoplinux.org (Joseph Smith)
Date: Tue, 03 Jun 2008 22:59:41 -0400
Subject: [coreboot] ram init help on the i82830
In-Reply-To: <A4E79ED7CDA94E91A6B7B622DC3C2667@smitty2m>
References: <bd5a919d8f8c9f3b1843712f5dc06e7d@imap.1and1.com><dd3c80060805272040n58bd85f3x95bfc2cc0928f308@mail.gmail.com><dd3c80060805272104u9efe708h892f6d1f98fa1a1c@mail.gmail.com><2b006022ef73ffcb29f9a499ec98605f@imap.1and1.com><d9895cb58ebc619bc751b8882077b2af@imap.1and1.com><dd3c80060805282246n200d7eb9j3ea094a7fbbc8519@mail.gmail.com><d570aa83b51576676c357b9ee62740ca@imap.1and1.com>
	<de5fd7225ea3f050b203bb4e8ec69944@imap.1and1.com>
	<A4E79ED7CDA94E91A6B7B622DC3C2667@smitty2m>
Message-ID: <a93e55d75703dacc4135e58c015b9f69@imap.1and1.com>


Good News!!!
I think I got it working :-)
I am running memtest86 right now and if all goes well I build it again with
filo and test it. 

First I tried with initializing each dimm socket. I booted to memtest and
it kept erroring out at 256mb. Because this is a double sidded 512MB
so-dimm, I figured out that each side of each dimm needs to be initialized.
So I came up with this:


	for (i = 0; i < MAX_DIMM_SIDES; i++) {
		dimm_end = pci_read_config8(ctrl->d0, DRB + i);
		if (dimm_end > dimm_start) {
			PRINT_DEBUG("    Sending RAM command 0x");
			PRINT_DEBUG_HEX32(reg32);
			PRINT_DEBUG(" to 0x");
			PRINT_DEBUG_HEX32((dimm_start * 32 * 1024 * 1024) + addr_offset);
			PRINT_DEBUG("\r\n");
			read32((dimm_start * 32 * 1024 * 1024) + addr_offset);
		}
		/* Set the start of the next DIMM. */
		dimm_start = dimm_end;
	}

It seems to work good so far, hopefully I will be submitting a patch soon.
Output from bootlog:

coreboot-2.0.0_IP1000 Tue Jun  3 21:56:32 EDT 2008 starting...
Setting initial registers....
Initial registers have been set.
Found DIMM in slot 00
DIMM is 0x0100 on side 1
DIMM is 0x0100 on side 2
DRB 0x60 has been set to 0x08
DRB1 0x61 has been set to 0x10
Found DIMM in slot 01
DIMM is 0x0040 on side 1
DIMM is 0x0000 on side 2
DRB2 0x62 has been set to 0x12
DRB3 0x63 has been set to 0x12
Found DIMM in slot 00, setting DRA...
DRA 0x70 has been set to 0x22
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
    Sending RAM command 0x00000010 to 0x10000000
    Sending RAM command 0x00000010 to 0x20000000
RAM Enable 2: Precharge all
    Sending RAM command 0x00000020 to 0x00000000
    Sending RAM command 0x00000020 to 0x10000000
    Sending RAM command 0x00000020 to 0x20000000
RAM Enable 3: CBR
    Sending RAM command 0x00000060 to 0x00000000
    Sending RAM command 0x00000060 to 0x10000000
    Sending RAM command 0x00000060 to 0x20000000
    Sending RAM command 0x00000060 to 0x00000000
    Sending RAM command 0x00000060 to 0x10000000
    Sending RAM command 0x00000060 to 0x20000000
    Sending RAM command 0x00000060 to 0x00000000
    Sending RAM command 0x00000060 to 0x10000000
    Sending RAM command 0x00000060 to 0x20000000
    Sending RAM command 0x00000060 to 0x00000000
    Sending RAM command 0x00000060 to 0x10000000
    Sending RAM command 0x00000060 to 0x20000000
    Sending RAM command 0x00000060 to 0x00000000
    Sending RAM command 0x00000060 to 0x10000000
    Sending RAM command 0x00000060 to 0x20000000
    Sending RAM command 0x00000060 to 0x00000000
    Sending RAM command 0x00000060 to 0x10000000
    Sending RAM command 0x00000060 to 0x20000000
    Sending RAM command 0x00000060 to 0x00000000
    Sending RAM command 0x00000060 to 0x10000000
    Sending RAM command 0x00000060 to 0x20000000
    Sending RAM command 0x00000060 to 0x00000000
    Sending RAM command 0x00000060 to 0x10000000
    Sending RAM command 0x00000060 to 0x20000000
RAM Enable 4: Mode register set
    Sending RAM command 0x00000030 to 0x000001d0
    Sending RAM command 0x00000030 to 0x100001d0
    Sending RAM command 0x00000030 to 0x200001d0
RAM Enable 5: Normal operation
    Sending RAM command 0x00000070 to 0x00000000
    Sending RAM command 0x00000070 to 0x10000000
    Sending RAM command 0x00000070 to 0x20000000
RAM Enable 6: Enable Refresh and IC

-- 
Thanks,
Joseph Smith
Set-Top-Linux
www.settoplinux.org




From qchwu at 163.com  Wed Jun  4 05:28:32 2008
From: qchwu at 163.com (qchwu)
Date: Wed, 4 Jun 2008 11:28:32 +0800 (CST)
Subject: [coreboot] buildrom
Message-ID: <48460BE0.000024.00983@bj163app5.163.com>

The "buildrom" is downloaded with SVN. When i build the ROM for AMD DB800 with FILO as payload,two error appear.
1./bios/buildrom/buildrom-devel/work/coreboot/svn/targets/: the file or folder is not found.

2.[/bios/buildrom/buildrom-devel/work/coreboot/stamps/.configured-db800] error 127.

After the make,i check the folder "/bios/buildrom/buildrom-devel/work/coreboot/svn/",the "targets"floder is not existing.The "SVN" folder and it's sub-folder are build by make,and can be cleaned by "make distclean".why the "targets"folder is not created by the make process?

When i check the "/bios/buildrom/buildrom-devel/work/coreboot/stamps",the ".configured-db800 " is not existing. here is the file?

How can i clear the errors?


Thanks!
chenghu
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20080604/2cdf507a/attachment.html>

From rminnich at gmail.com  Wed Jun  4 05:52:21 2008
From: rminnich at gmail.com (ron minnich)
Date: Tue, 3 Jun 2008 20:52:21 -0700
Subject: [coreboot] Xorg.conf for LX
Message-ID: <13426df10806032052x3ecd79c0j2504f6e30cb2c328@mail.gmail.com>

I've got this lovely LX framebuffer but am a little unclear on how to
set up my X11 config.

any hints welcome. I know that newer Xorg just sorta "gets it right"
but my ubuntu appears not to be that new.

ron



From rminnich at gmail.com  Wed Jun  4 06:28:09 2008
From: rminnich at gmail.com (ron minnich)
Date: Tue, 3 Jun 2008 21:28:09 -0700
Subject: [coreboot] patch: fix USB ports on DBE62,
	and other cs5536-based platforms
Message-ID: <13426df10806032128r67b6439aw81f5578c48dcd579@mail.gmail.com>

This change adds some debug prints, and a comment warning to dts on cs5536.

Most importantly it fixes a simple programming error which made it so most of
the sets on the USB were not doing anything. The bug is also in V2.

With this fix, the DBE62 USB ports all work!

If someone clones the fix to V2, it will also fix V2. Or, we can just convince
you to move forward to V3 :-)

Signed-off-by: Ronald G. Minnich <rminnich at gmail.com>

Also, please note, my remaining issue is to fix X11 on DBE62, then I
believe we are done. Has someone tested audio however?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: cs5536.fix
Type: application/octet-stream
Size: 2154 bytes
Desc: not available
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20080603/a4f08ee5/attachment.obj>

From joe at settoplinux.org  Wed Jun  4 07:04:56 2008
From: joe at settoplinux.org (Joseph Smith)
Date: Wed, 4 Jun 2008 01:04:56 -0400
Subject: [coreboot] Xorg.conf for LX
In-Reply-To: <13426df10806032052x3ecd79c0j2504f6e30cb2c328@mail.gmail.com>
References: <13426df10806032052x3ecd79c0j2504f6e30cb2c328@mail.gmail.com>
Message-ID: <DA56227956AA4384B304695C99E87189@smitty2m>



> -----Original Message-----
> From: coreboot-bounces at coreboot.org [mailto:coreboot-bounces at coreboot.org]
> On Behalf Of ron minnich
> Sent: Tuesday, June 03, 2008 11:52 PM
> To: Coreboot
> Subject: [coreboot] Xorg.conf for LX
> 
> I've got this lovely LX framebuffer but am a little unclear on how to
> set up my X11 config.
> 
> any hints welcome. I know that newer Xorg just sorta "gets it right"
> but my ubuntu appears not to be that new.
> 
Did you try:

# Xorg -configure

Thanks,
Joseph Smith
Set-Top-Linux
www.settoplinux.org




From rminnich at gmail.com  Wed Jun  4 07:44:17 2008
From: rminnich at gmail.com (ron minnich)
Date: Tue, 3 Jun 2008 22:44:17 -0700
Subject: [coreboot] Xorg.conf for LX
In-Reply-To: <DA56227956AA4384B304695C99E87189@smitty2m>
References: <13426df10806032052x3ecd79c0j2504f6e30cb2c328@mail.gmail.com>
	<DA56227956AA4384B304695C99E87189@smitty2m>
Message-ID: <13426df10806032244h65c28c31yb5ff9eeb6adc9f28@mail.gmail.com>

On Tue, Jun 3, 2008 at 10:04 PM, Joseph Smith <joe at settoplinux.org> wrote:

> # Xorg -configure
>


long story but I did not.

Here is what I have for now.

Section "Files"
EndSection

Section "InputDevice"
        Identifier      "Generic Keyboard"
        Driver          "kbd"
        Option          "CoreKeyboard"
        Option          "XkbRules"      "xorg"
        Option          "XkbModel"      "pc105"
        Option          "XkbLayout"     "us"
EndSection

# This section allows use of a supplementary USB mouse at any time:
Section "InputDevice"
        Identifier      "USB Mouse"
        Driver          "mouse"
        Option          "SendCoreEvents"        "true"
        #Option         "Device"                "/dev/input/mouse2"
        Option          "Device"                "/dev/mice"
        Option          "Protocol"              "ImPS/2"
        Option          "Emulate3Buttons"       "false"
        Option          "ZAxisMapping"          "4 5"
EndSection

Section "Device"
        Identifier "Geode"
        Driver "amd"
        Option "HWcursor"
EndSection
Section "Monitor"
        Identifier      "Generic Monitor"
        Option          "DPMS"
        HorizSync       28-64
        VertRefresh     43-60
EndSection

Section "Screen"
        Identifier      "Default Screen"
        Device          "Geode"
        Monitor         "Generic Monitor"
        DefaultDepth    24
        SubSection "Display"
                Modes           "1280x1024" "1024x768"
        EndSubSection
EndSection

Section "ServerLayout"
        Identifier      "Default Layout"
        Screen          "Default Screen"
        InputDevice     "Generic Keyboard"
        InputDevice     "USB Mouse"

EndSection

Anyway, X is up, but at some point I get this  ...http://pastebin.com/m800b21a

ron



From r.marek at assembler.cz  Wed Jun  4 08:43:19 2008
From: r.marek at assembler.cz (Rudolf Marek)
Date: Wed, 04 Jun 2008 08:43:19 +0200
Subject: [coreboot] Epia-CN USB Does Not init Properly with LAB
In-Reply-To: <4845A147.3030307@onelabs.com>
References: <4845A147.3030307@onelabs.com>
Message-ID: <48463987.5030804@assembler.cz>

Hi,

Interrupts are wrong. I think because PIRQ/INTA/INTB... routing registers may 
not be set correctly. (regs 0x50 something in SB) Why is LAPIC disabled? The 
VT8237R code always expects APIC to be working, and it enables APIC mode.

Please check with orginal BIOS in what mode SB operates or get  the lapic 
working if it has some.

Thanks,
Rudolf



From uwe.schwarz at saxnet.de  Wed Jun  4 13:30:52 2008
From: uwe.schwarz at saxnet.de (Uwe Schwarz)
Date: Wed, 4 Jun 2008 13:30:52 +0200
Subject: [coreboot] Problem with PLL
In-Reply-To: <484573B4.9050607@amd.com>
References: <1F1F933B-FB37-44F6-AA77-AD8B4EF60BA6@saxnet.de>
	<484573B4.9050607@amd.com>
Message-ID: <8425A3CD-AD3E-400F-B9B4-2C48BFE7AC3A@saxnet.de>

Hi Marc,

> Can you narrow down the line that fails, northbridge\amd\lx 
> \pll_reset.c?

It failed at this line:
wrmsr(GLCP_SYS_RSTPLL, msrGlcpSysRstpll);

> If it fails in the reset you can try making the pll lock time longer  
> but
> I doubt that it will help.
> msrGlcpSysRstpll.lo |= (0xFF << RSTPPL_LOWER_HOLD_COUNT_SHIFT);

and that did the trick. It does boot now, thanks for helping.

// Uwe
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3934 bytes
Desc: not available
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20080604/74764e33/attachment.p7s>

From c-d.hailfinger.devel.2006 at gmx.net  Wed Jun  4 14:14:49 2008
From: c-d.hailfinger.devel.2006 at gmx.net (Carl-Daniel Hailfinger)
Date: Wed, 04 Jun 2008 14:14:49 +0200
Subject: [coreboot] ram init help on the i82830
In-Reply-To: <a93e55d75703dacc4135e58c015b9f69@imap.1and1.com>
References: <bd5a919d8f8c9f3b1843712f5dc06e7d@imap.1and1.com><dd3c80060805272040n58bd85f3x95bfc2cc0928f308@mail.gmail.com><dd3c80060805272104u9efe708h892f6d1f98fa1a1c@mail.gmail.com><2b006022ef73ffcb29f9a499ec98605f@imap.1and1.com><d9895cb58ebc619bc751b8882077b2af@imap.1and1.com><dd3c80060805282246n200d7eb9j3ea094a7fbbc8519@mail.gmail.com><d570aa83b51576676c357b9ee62740ca@imap.1and1.com>	<de5fd7225ea3f050b203bb4e8ec69944@imap.1and1.com>	<A4E79ED7CDA94E91A6B7B622DC3C2667@smitty2m>
	<a93e55d75703dacc4135e58c015b9f69@imap.1and1.com>
Message-ID: <48468739.4010207@gmx.net>

On 04.06.2008 04:59, Joseph Smith wrote:
> Good News!!!
> I think I got it working :-)
>   

Great!

> I am running memtest86 right now and if all goes well I build it again with
> filo and test it. 
>
> First I tried with initializing each dimm socket. I booted to memtest and
> it kept erroring out at 256mb. Because this is a double sidded 512MB
> so-dimm, I figured out that each side of each dimm needs to be initialized.
> So I came up with this:
>
>
> 	for (i = 0; i < MAX_DIMM_SIDES; i++) {
> 		dimm_end = pci_read_config8(ctrl->d0, DRB + i);
> 		if (dimm_end > dimm_start) {
> 			PRINT_DEBUG("    Sending RAM command 0x");
> 			PRINT_DEBUG_HEX32(reg32);
> 			PRINT_DEBUG(" to 0x");
> 			PRINT_DEBUG_HEX32((dimm_start * 32 * 1024 * 1024) + addr_offset);
> 			PRINT_DEBUG("\r\n");
> 			read32((dimm_start * 32 * 1024 * 1024) + addr_offset);
> 		}
> 		/* Set the start of the next DIMM. */
> 		dimm_start = dimm_end;
> 	}
>
> It seems to work good so far, hopefully I will be submitting a patch soon.
>   

Please submit a patch now, regardless of how ugly/polluted/unclean it
is. We had too many losses of great patches in the past because
computers died and an early not-ready patch is better than nothing.

Regards,
Carl-Daniel



From c-d.hailfinger.devel.2006 at gmx.net  Wed Jun  4 14:24:23 2008
From: c-d.hailfinger.devel.2006 at gmx.net (Carl-Daniel Hailfinger)
Date: Wed, 04 Jun 2008 14:24:23 +0200
Subject: [coreboot] patch: fix USB ports on DBE62,
 and other cs5536-based platforms
In-Reply-To: <13426df10806032128r67b6439aw81f5578c48dcd579@mail.gmail.com>
References: <13426df10806032128r67b6439aw81f5578c48dcd579@mail.gmail.com>
Message-ID: <48468977.8020904@gmx.net>

On 04.06.2008 06:28, ron minnich wrote:
> This change adds some debug prints, and a comment warning to dts on cs5536.
>
> Most importantly it fixes a simple programming error which made it so most of
> the sets on the USB were not doing anything. The bug is also in V2.
>
> With this fix, the DBE62 USB ports all work!
>
> If someone clones the fix to V2, it will also fix V2. Or, we can just convince
> you to move forward to V3 :-)
>
> Signed-off-by: Ronald G. Minnich <rminnich at gmail.com>
>   

If you fix the problems outlined below, this is
Acked-by: Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006 at gmx.net>

> Also, please note, my remaining issue is to fix X11 on DBE62, then I
> believe we are done. Has someone tested audio however?
>   

> Index: southbridge/amd/cs5536/cs5536.c
> ===================================================================
> --- southbridge/amd/cs5536/cs5536.c	(revision 688)
> +++ southbridge/amd/cs5536/cs5536.c	(working copy)
> @@ -395,18 +395,19 @@
>  	}
>  }
>  
> -#define HCCPARAMS		0x08
> -#define IPREG04			0xA0
> +/* the /sizeof(unsigned long) is to convert byte offsets into u32 offsets */
>   

sizeof(unsigned long) is u64 for 64bit architectures. I suggest either
sizeof(u32) or sizeof(int).

> +#define HCCPARAMS		(0x08/sizeof(unsigned long))
> +#define IPREG04			(0xA0/sizeof(unsigned long))
>   

same here. The indentation looks strange as well.

>  #define USB_HCCPW_SET		(1 << 1)
>  #define UOCCAP			0x00
>  #define APU_SET			(1 << 15)
> -#define UOCMUX			0x04
> +#define UOCMUX			(0x04/sizeof(unsigned long))
>   

same here
>  #define PMUX_HOST		0x02
>  #define PMUX_DEVICE		0x03
>  #define PUEN_SET		(1 << 2)
> -#define UDCDEVCTL		0x404
> +#define UDCDEVCTL		(0x404/sizeof(unsigned long))
>   

same here

>  #define UDC_SD_SET		(1 << 10)
> -#define UOCCTL			0x0C
> +#define UOCCTL			(0x0C/sizeof(unsigned long))
>   

same here.

>  #define PADEN_SET		(1 << 7)
>  
>  /**
> @@ -445,6 +446,8 @@
>  	if (dev) {
>  		bar = (u32 *) pci_read_config32(dev, PCI_BASE_ADDRESS_0);
>  
> +		printk(BIOS_DEBUG, "UOCMUX is %x\n", *(bar + UOCMUX));
> +
>  		*(bar + UOCMUX) &= PUEN_SET;
>  
>  		/* Host or Device? */
> @@ -463,6 +466,7 @@
>  			*(bar + UOCCAP) |= sb->pph;
>  		}
>  		printk(BIOS_DEBUG, "UOCCAP is %x\n", *(bar + UOCCAP));
> +		printk(BIOS_DEBUG, "UOCMUX is %x\n", *(bar + UOCMUX));
>  
>  	}
>  
> @@ -489,6 +493,8 @@
>  		}
>  	}
>  
> +	printk(BIOS_DEBUG, "UOCCTL is %x\n", *(bar + UOCCTL));
> +
>  	/* Disable virtual PCI UDC and OTG headers.  The kernel never
>  	 * sees a header for this device.  It used to provide an OS
>  	 * visible device, but that was defeatured.  There are still
> Index: southbridge/amd/cs5536/dts
> ===================================================================
> --- southbridge/amd/cs5536/dts	(revision 688)
> +++ southbridge/amd/cs5536/dts	(working copy)
> @@ -66,6 +66,10 @@
>  	pph = "0";
>  	/* 0:off, xxxx:overcurrent setting, e.g. 0x3FEA.
>  	 * See CS5536 - Data Book (pages 380-381).
> +	 * And don't just set this to "1". You have to set it 
> +	 * to values that make sense for the register. Do not set this
> +	 * for your mainboard unless you have made sure of the register
> +	 * settings!
>  	 */
>  	enable_USBP4_overcurrent = "0";
>  
>   

Regards,
Carl-Daniel

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




From c-d.hailfinger.devel.2006 at gmx.net  Wed Jun  4 14:29:42 2008
From: c-d.hailfinger.devel.2006 at gmx.net (Carl-Daniel Hailfinger)
Date: Wed, 04 Jun 2008 14:29:42 +0200
Subject: [coreboot] [PATCH] [RFC] v3: CS5536 cleanup
In-Reply-To: <13426df10805071751p7adb40c8s759875e09ccee15@mail.gmail.com>
References: <48205A47.5060403@gmx.net> <4822458B.4030506@gmx.net>
	<13426df10805071751p7adb40c8s759875e09ccee15@mail.gmail.com>
Message-ID: <48468AB6.5060605@gmx.net>

Hi Ron,

I assume this slipped through the cracks. Had we committed this earlier,
you would have been able to scratch part of the additional code comments
in r688.

Regards,
Carl-Daniel

On 08.05.2008 02:51, ron minnich wrote:
> On 08.05.2008 02:12, Carl-Daniel Hailfinger wrote:
>> Hi Ron,
>>
>> can you review this?
>>
>> - Clean up Geode companion chip CS5536 code.
>> - Improve VPCI hiding debug message and add doxygen comments.
>> - Eliminate a few redundant dev_find_pci_device() calls.
>>
>> This should be an equivalence transformation.
>>
>> Build tested on norwich, db800, alix.1c, alix.2c3, dbe62.
>> No new breakage on dbe61.
>>
>> Signed-off-by: Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006 at gmx.net>
> will test tonight or tomorrow night. Am on short trip.
>
> ron
>   


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




From peter at stuge.se  Wed Jun  4 14:52:32 2008
From: peter at stuge.se (Peter Stuge)
Date: Wed, 4 Jun 2008 14:52:32 +0200
Subject: [coreboot] patch: fix USB ports on DBE62,
	and other cs5536-based platforms
In-Reply-To: <48468977.8020904@gmx.net>
References: <13426df10806032128r67b6439aw81f5578c48dcd579@mail.gmail.com>
	<48468977.8020904@gmx.net>
Message-ID: <20080604125232.2035.qmail@stuge.se>

On Wed, Jun 04, 2008 at 02:24:23PM +0200, Carl-Daniel Hailfinger wrote:
> > +++ southbridge/amd/cs5536/cs5536.c	(working copy)
> > @@ -395,18 +395,19 @@
> >  	}
> >  }
> >  
> > -#define HCCPARAMS		0x08
> > -#define IPREG04			0xA0
> > +/* the /sizeof(unsigned long) is to convert byte offsets into u32 offsets */
> >   
> 
> sizeof(unsigned long) is u64 for 64bit architectures.

Note which file this is in. I doubt the 5536 will be used on a 64 bit
CPU anytime soon.


> I suggest either sizeof(u32) or sizeof(int).

Though I consider this only cosmetic, I agree that u32 is nicer.
Also since it is mentioned in the comment.


> The indentation looks strange as well.

Maybe because patch is being viewed and there are some odd tabs or
other spacing in the original file.

I found that applying the patch is the only way to reliably detect
whitespace problems.


Ron, if you feel like it, make those unsigned longs u32s, if not,
still:

Acked-by: Peter Stuge <peter at stuge.se>



From svn at coreboot.org  Wed Jun  4 16:36:35 2008
From: svn at coreboot.org (svn at coreboot.org)
Date: Wed,  4 Jun 2008 16:36:35 +0200
Subject: [coreboot] r689 - coreboot-v3/southbridge/amd/cs5536
Message-ID: <mailman.1619.1355071330.16123.coreboot@coreboot.org>

Author: rminnich
Date: 2008-06-04 16:36:35 +0200 (Wed, 04 Jun 2008)
New Revision: 689

Modified:
   coreboot-v3/southbridge/amd/cs5536/cs5536.c
   coreboot-v3/southbridge/amd/cs5536/dts
Log:
This change adds some debug prints, and a comment warning to dts on cs5536.

Most importantly it fixes a simple programming error which made it so most of
the sets on the USB were not doing anything. The bug is also in V2.

With this fix, the DBE62 USB ports all work!

If someone clones the fix to V2, it will also fix V2. Or, we can just convince
you to move forward to V3 :-)

Signed-off-by: Ronald G. Minnich <rminnich at gmail.com>

Acked-by: Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006 at gmx.net>
Acked-by: Peter Stuge <peter at stuge.se>


Modified: coreboot-v3/southbridge/amd/cs5536/cs5536.c
===================================================================
--- coreboot-v3/southbridge/amd/cs5536/cs5536.c	2008-06-03 15:22:16 UTC (rev 688)
+++ coreboot-v3/southbridge/amd/cs5536/cs5536.c	2008-06-04 14:36:35 UTC (rev 689)
@@ -395,18 +395,19 @@
 	}
 }
 
-#define HCCPARAMS		0x08
-#define IPREG04			0xA0
+/* the /sizeof(u32) is to convert byte offsets into u32 offsets */
+#define HCCPARAMS		(0x08/sizeof(u32))
+#define IPREG04			(0xA0/sizeof(u32))
 #define USB_HCCPW_SET		(1 << 1)
 #define UOCCAP			0x00
 #define APU_SET			(1 << 15)
-#define UOCMUX			0x04
+#define UOCMUX			(0x04/sizeof(u32))
 #define PMUX_HOST		0x02
 #define PMUX_DEVICE		0x03
 #define PUEN_SET		(1 << 2)
-#define UDCDEVCTL		0x404
+#define UDCDEVCTL		(0x404/sizeof(u32))
 #define UDC_SD_SET		(1 << 10)
-#define UOCCTL			0x0C
+#define UOCCTL			(0x0C/sizeof(u32))
 #define PADEN_SET		(1 << 7)
 
 /**
@@ -445,6 +446,8 @@
 	if (dev) {
 		bar = (u32 *) pci_read_config32(dev, PCI_BASE_ADDRESS_0);
 
+		printk(BIOS_DEBUG, "UOCMUX is %x\n", *(bar + UOCMUX));
+
 		*(bar + UOCMUX) &= PUEN_SET;
 
 		/* Host or Device? */
@@ -463,6 +466,7 @@
 			*(bar + UOCCAP) |= sb->pph;
 		}
 		printk(BIOS_DEBUG, "UOCCAP is %x\n", *(bar + UOCCAP));
+		printk(BIOS_DEBUG, "UOCMUX is %x\n", *(bar + UOCMUX));
 
 	}
 
@@ -489,6 +493,8 @@
 		}
 	}
 
+	printk(BIOS_DEBUG, "UOCCTL is %x\n", *(bar + UOCCTL));
+
 	/* Disable virtual PCI UDC and OTG headers.  The kernel never
 	 * sees a header for this device.  It used to provide an OS
 	 * visible device, but that was defeatured.  There are still

Modified: coreboot-v3/southbridge/amd/cs5536/dts
===================================================================
--- coreboot-v3/southbridge/amd/cs5536/dts	2008-06-03 15:22:16 UTC (rev 688)
+++ coreboot-v3/southbridge/amd/cs5536/dts	2008-06-04 14:36:35 UTC (rev 689)
@@ -66,6 +66,10 @@
 	pph = "0";
 	/* 0:off, xxxx:overcurrent setting, e.g. 0x3FEA.
 	 * See CS5536 - Data Book (pages 380-381).
+	 * And don't just set this to "1". You have to set it 
+	 * to values that make sense for the register. Do not set this
+	 * for your mainboard unless you have made sure of the register
+	 * settings!
 	 */
 	enable_USBP4_overcurrent = "0";
 




From mylesgw at gmail.com  Wed Jun  4 16:39:16 2008
From: mylesgw at gmail.com (Myles Watson)
Date: Wed, 4 Jun 2008 08:39:16 -0600
Subject: [coreboot] LinuxTag 2008 Status
In-Reply-To: <20080603202223.GE2398@cosmic.amd.com>
References: <20080530204441.GA14200@cosmic.amd.com>
	<00a601c8c2a8$df85a0b0$0023040a@chimp>
	<20080602234805.GB30270@cosmic.amd.com>
	<003701c8c5ac$7f8bbc10$0023040a@chimp>
	<20080603202223.GE2398@cosmic.amd.com>
Message-ID: <008a01c8c650$c53d6e80$0023040a@chimp>



> >
> > Right now we don't do partial writes, do we?  If we did, this isn't
> > dangerous as long as we rewrite the entire lar entry, is it?
> 
> You are right, we don't do partial writes right now, but it is the
> 800 pound gorilla in the room.  Everything about the design of LAR
> is based around the concept of partial writes, so we really can't
> ignore it.
> 
> One of our problems is that we have made partial writes a high
> priority, but we haven't clearly defined how they are going to work.
> Adding new code to an existing ROM isn't a difficult concept, but when
> it comes to changing or replacing blobs, it gets very vague, and IMHO
> very scary.  None of our current v3 platforms support fallback, so just
> one blown sector is death, even if LAR can detect it and print
> a "gee, we're sorry but the ROM is corrupted message".  I am having
> trouble being convinced that this is any safer then writing a full ROM,
> but thats off-topic for this message.
> 
> The point is that we have to always be aware that the LAR could change
> from boot to boot. If we need to support a dynamic LAR, then we need
> to keep the bayou related complexity to a minimum, or at least as low
> as the circumstances will allow.

It seems like supporting partial writes means knowing the details that right
now only flashrom knows.  Maybe we should bite off a smaller chunk and make
flashrom support partial writes.  In other words we create a valid LAR
updated however the user wanted, make sure they know if they're changing the
bootblock or something else that's critical, and then let flashrom only
write the portions that have changed.  That way we keep the details where
they belong.

Thanks,
Myles




From c-d.hailfinger.devel.2006 at gmx.net  Wed Jun  4 16:42:31 2008
From: c-d.hailfinger.devel.2006 at gmx.net (Carl-Daniel Hailfinger)
Date: Wed, 04 Jun 2008 16:42:31 +0200
Subject: [coreboot] coreboot & OpenSolaris
In-Reply-To: <4846a530.zV9BNs/vyQfoixoi%Joerg.Schilling@fokus.fraunhofer.de>
References: <4842baec.IC0jKb8m/ClpVPE6%Joerg.Schilling@fokus.fraunhofer.de>
	<48454223.3050807@gmx.net>
	<484666d2.wU64hZRSUftqvDuP%Joerg.Schilling@fokus.fraunhofer.de>
	<48469361.10604@gmx.net>
	<48469553.C+kU/ElswhZQACK5%Joerg.Schilling@fokus.fraunhofer.de>
	<48469716.7090500@gmx.net>
	<4846a530.zV9BNs/vyQfoixoi%Joerg.Schilling@fokus.fraunhofer.de>
Message-ID: <4846A9D7.3000605@gmx.net>

Hi,

[please CC J?rg on replies, I don't know whether he is already
subscribed to the list.]
J?rg Schilling and I have been working to get flashrom to compile again
under Solaris. The credit belongs to J?rg.

The patch below is a first hack to get everything running and not
completely ready for merging. Adding platform-specific #include
statements to each file is suboptimal, I'd prefer to have them all in
flash.h. Once we have a mergeable patch, I'd like to get a review from
the person who created Solaris support in the first place.

Besides that, we may want to disable compilation explicitly for any
untested arch. Especially the problem that there is no agreed-upon order
of out[bwl] arguments is a disaster waiting to happen if someone tests a
new Linux-incompatible platform.

Regards,
Carl-Daniel

On 04.06.2008 16:22, Joerg Schilling wrote:
> Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006 at gmx.net> wrote:
>
>   
>> Hast Du evtl. einen unfertigen Patch, den ich durchs Review jagen kann?
>> Es w?re klasse, wenn wir das vor dem Release 1.0 mergen k?nnen.
>>     
>
> hier ist erstmal mein aktueller Stand:
>
> --- Makefile.orig	Di Jun  3 16:53:49 2008
> +++ Makefile	Mi Jun  4 16:21:23 2008
> @@ -15,6 +15,8 @@
>  OS_ARCH	= $(shell uname)
>  ifeq ($(OS_ARCH), SunOS)
>  LDFLAGS = -lpci -lz
> +CFLAGS += -I.
> +LDFLAGS += -L/tmp/pciutils-2.2.10/lib/
>  else
>  LDFLAGS = -lpci -lz
>  STRIP_ARGS = -s
> @@ -52,7 +54,7 @@
>  	rm -f $(PROGRAM) .dependencies
>  	
>  dep:
> -	@$(CC) -MM *.c > .dependencies
> +	$(CC) -M $(CFLAGS) $(OBJS:%.o=%.c) > .dependencies
>  
>  pciutils:
>  	@echo; echo -n "Checking for pciutils and zlib... "
> @@ -60,7 +62,7 @@
>  		   echo "struct pci_access *pacc;";	   \
>  		   echo "int main(int argc, char **argv)"; \
>  		   echo "{ pacc = pci_alloc(); return 0; }"; ) > .test.c )
> -	@$(CC) $(CFLAGS) .test.c -o .test $(LDFLAGS) &>/dev/null &&	\
> +	@$(CC) $(CFLAGS) .test.c -o .test $(LDFLAGS) >/dev/null 2>&1 &&	\
>  		echo "found." || ( echo "not found."; echo;		\
>  		echo "Please install pciutils-devel and zlib-devel.";	\
>  		echo "See README for more information."; echo;		\
> Index: flash.h
> ===================================================================
> --- flash.h	(revision 3360)
> +++ flash.h	(working copy)
> @@ -41,6 +41,14 @@
>    #define INW(x) __extension__ ({ u_int tmp = (x); inw(tmp); })
>    #define INL(x) __extension__ ({ u_int tmp = (x); inl(tmp); })
>  #else
> +#ifdef	__sun
> +  #define OUTB(x, y) outb(y, x)
> +  #define OUTW(x, y) outw(y, x)
> +  #define OUTL(x, y) outl(y, x)
> +  #define INB  inb
> +  #define INW  inw
> +  #define INL  inl
> +#else
>    #define OUTB outb
>    #define OUTW outw
>    #define OUTL outl
> @@ -48,6 +56,7 @@
>    #define INW  inw
>    #define INL  inl
>  #endif
> +#endif
>  
>  #define ARRAY_SIZE(a) (sizeof(a) / sizeof((a)[0]))
>  
> @@ -357,7 +366,7 @@
>  
>  /* udelay.c */
>  void myusec_delay(int time);
> -void myusec_calibrate_delay();
> +void myusec_calibrate_delay(void);
>  
>  /* PCI handling for board/chipset_enable */
>  struct pci_access *pacc;
> @@ -406,12 +415,12 @@
>  int probe_spi_rdid(struct flashchip *flash);
>  int probe_spi_res(struct flashchip *flash);
>  int spi_command(unsigned int writecnt, unsigned int readcnt, const unsigned char *writearr, unsigned char *readarr);
> -void spi_write_enable();
> -void spi_write_disable();
> +void spi_write_enable(void);
> +void spi_write_disable(void);
>  int spi_chip_erase_c7(struct flashchip *flash);
>  int spi_chip_write(struct flashchip *flash, uint8_t *buf);
>  int spi_chip_read(struct flashchip *flash, uint8_t *buf);
> -uint8_t spi_read_status_register();
> +uint8_t spi_read_status_register(void);
>  void spi_disable_blockprotect(void);
>  void spi_byte_program(int address, uint8_t byte);
>  void spi_page_program(int block, uint8_t *buf, uint8_t *bios);
> @@ -450,6 +459,8 @@
>  			     volatile uint8_t *dst);
>  int probe_jedec(struct flashchip *flash);
>  int erase_chip_jedec(struct flashchip *flash);
> +int write_page_write_jedec(volatile uint8_t *bios, uint8_t *src,
> +			   volatile uint8_t *dst, int page_size);
>  int write_jedec(struct flashchip *flash, uint8_t *buf);
>  int erase_sector_jedec(volatile uint8_t *bios, unsigned int page);
>  int erase_block_jedec(volatile uint8_t *bios, unsigned int page);
> Index: it87spi.c
> ===================================================================
> --- it87spi.c	(revision 3360)
> +++ it87spi.c	(working copy)
> @@ -26,6 +26,10 @@
>  #include <pci/pci.h>
>  #include <stdint.h>
>  #include <string.h>
> +/* for outb(),... */
> +#if defined (__sun) && (defined(__i386) || defined(__amd64))
> +#include <asm/sunddi.h>	/* XXX nonportable gcc/_KERNEL only, may disappear */
> +#endif
>  #include "flash.h"
>  #include "spi.h"
>  
> Index: chipset_enable.c
> ===================================================================
> --- chipset_enable.c	(revision 3360)
> +++ chipset_enable.c	(working copy)
> @@ -33,6 +33,10 @@
>  #include <sys/mman.h>
>  #include <fcntl.h>
>  #include <unistd.h>
> +/* for outb(),... */
> +#if defined (__sun) && (defined(__i386) || defined(__amd64))
> +#include <asm/sunddi.h>	/* XXX nonportable gcc/_KERNEL only, may disappear */
> +#endif
>  #include "flash.h"
>  
>  static int enable_flash_ali_m1533(struct pci_dev *dev, const char *name)
> Index: flashrom.c
> ===================================================================
> --- flashrom.c	(revision 3360)
> +++ flashrom.c	(working copy)
> @@ -33,10 +33,9 @@
>  #include <pci/pci.h>
>  /* for iopl */
>  #if defined (__sun) && (defined(__i386) || defined(__amd64))
> -#include <strings.h>
>  #include <sys/sysi86.h>
>  #include <sys/psw.h>
> -#include <asm/sunddi.h>
> +#include <asm/sunddi.h>	/* XXX nonportable gcc/_KERNEL only, may disappear */
>  #endif
>  #include "flash.h"
>  
> Index: board_enable.c
> ===================================================================
> --- board_enable.c	(revision 3360)
> +++ board_enable.c	(working copy)
> @@ -29,6 +29,10 @@
>  #include <stdint.h>
>  #include <string.h>
>  #include <fcntl.h>
> +/* for outb(),... */
> +#if defined (__sun) && (defined(__i386) || defined(__amd64))
> +#include <asm/sunddi.h>	/* XXX nonportable gcc/_KERNEL only, may disappear */
> +#endif
>  #include "flash.h"
>  
>  /*
> J?rg
>
>   


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




From rminnich at gmail.com  Wed Jun  4 16:43:00 2008
From: rminnich at gmail.com (ron minnich)
Date: Wed, 4 Jun 2008 07:43:00 -0700
Subject: [coreboot] patch: fix USB ports on DBE62,
	and other cs5536-based platforms
In-Reply-To: <20080604125232.2035.qmail@stuge.se>
References: <13426df10806032128r67b6439aw81f5578c48dcd579@mail.gmail.com>
	<48468977.8020904@gmx.net> <20080604125232.2035.qmail@stuge.se>
Message-ID: <13426df10806040743s45c75354xbbea0faec78c4b19@mail.gmail.com>

Committed revision 689.

A little meta-note here. I am seeing, more frequently now than 20
years ago, this kind of style in drivers and bios code:

base = (u32 *)pci_read_config_long(whatever);
*(base + xyz) =

Somehow, in all the usage of pragmas, attributes, segment names, and
all the other gadgets that have been added to C in the last while,
we've completely lost track of one of the most important reasons to
use C in systems programming!

What's the right way to work on memory-mapped registers? Well, in this case:

struct usb_otg{
  u32 uoc;
  u32 uocmux;
  u32 _1; /* A Plan 9 trick, and  if it's good enough for the guys who
designed C,
                       it's good enough for me (this is a reserved register) */
  u32 uocctl;
};

and so on. So, just a note: don't forget about structs as templates
for memory mapped registers. That capability has been there and been
used since, oh, 1973 or so :-)

thanks

ron



From rminnich at gmail.com  Wed Jun  4 16:53:36 2008
From: rminnich at gmail.com (ron minnich)
Date: Wed, 4 Jun 2008 07:53:36 -0700
Subject: [coreboot] [PATCH] [RFC] v3: CS5536 cleanup
In-Reply-To: <48468AB6.5060605@gmx.net>
References: <48205A47.5060403@gmx.net> <4822458B.4030506@gmx.net>
	<13426df10805071751p7adb40c8s759875e09ccee15@mail.gmail.com>
	<48468AB6.5060605@gmx.net>
Message-ID: <13426df10806040753y17eeb1f1q73319c0c82e00fc2@mail.gmail.com>

So, I went to apply and test this patch, but I guess, on reflection,
I'm pretty uncomfortable with it. Why? Because of this:

+	hide_vpci(0x800079C4);

This is even worse than putting stuff like this in the code
        dev = dev_find_pci_device(PCI_VENDOR_ID_AMD,
                              PCI_DEVICE_ID_AMD_CS5536_UDC, 0);
        if (dev)
                pci_write_config32(dev, 0x7C, 0xDEADBEEF);

because at least the latter form doesn't hard code pcidevfn.

I think you are right. hide_vpci should take a dev pointer. So let's
try to rework with that change to hide_vpci and we can then bring this
patch in.

hide_vpci then becomes pretty simple in fact ...

thanks

ron



From jordan.crouse at amd.com  Wed Jun  4 17:12:45 2008
From: jordan.crouse at amd.com (Jordan Crouse)
Date: Wed, 4 Jun 2008 09:12:45 -0600
Subject: [coreboot] buildrom
In-Reply-To: <48460BE0.000024.00983@bj163app5.163.com>
References: <48460BE0.000024.00983@bj163app5.163.com>
Message-ID: <20080604151245.GB8983@cosmic.amd.com>

On 04/06/08 11:28 +0800, qchwu wrote:
> The "buildrom" is downloaded with SVN. When i build the ROM for AMD DB800 with FILO as payload,two error appear.
> 1./bios/buildrom/buildrom-devel/work/coreboot/svn/targets/: the file or folder is not found.

This means your SVN fetch failed.  Please check to make sure you are not
behind a filewall or other such issue.

We should detect this and exit gracefully.  The correct place for this is
probably in the SVN fetcher.

Jordan

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




From jordan.crouse at amd.com  Wed Jun  4 17:15:58 2008
From: jordan.crouse at amd.com (Jordan Crouse)
Date: Wed, 4 Jun 2008 09:15:58 -0600
Subject: [coreboot] Xorg.conf for LX
In-Reply-To: <13426df10806032244h65c28c31yb5ff9eeb6adc9f28@mail.gmail.com>
References: <13426df10806032052x3ecd79c0j2504f6e30cb2c328@mail.gmail.com>
	<DA56227956AA4384B304695C99E87189@smitty2m>
	<13426df10806032244h65c28c31yb5ff9eeb6adc9f28@mail.gmail.com>
Message-ID: <20080604151558.GD8983@cosmic.amd.com>

On 03/06/08 22:44 -0700, ron minnich wrote:
> On Tue, Jun 3, 2008 at 10:04 PM, Joseph Smith <joe at settoplinux.org> wrote:
> 
> > # Xorg -configure
> >
> 
> 
> long story but I did not.
> 
> Here is what I have for now.
> 
> Section "Files"
> EndSection
> 
> Section "InputDevice"
>         Identifier      "Generic Keyboard"
>         Driver          "kbd"
>         Option          "CoreKeyboard"
>         Option          "XkbRules"      "xorg"
>         Option          "XkbModel"      "pc105"
>         Option          "XkbLayout"     "us"
> EndSection
> 
> # This section allows use of a supplementary USB mouse at any time:
> Section "InputDevice"
>         Identifier      "USB Mouse"
>         Driver          "mouse"
>         Option          "SendCoreEvents"        "true"
>         #Option         "Device"                "/dev/input/mouse2"
>         Option          "Device"                "/dev/mice"
>         Option          "Protocol"              "ImPS/2"
>         Option          "Emulate3Buttons"       "false"
>         Option          "ZAxisMapping"          "4 5"
> EndSection
> 
> Section "Device"
>         Identifier "Geode"
>         Driver "amd"
>         Option "HWcursor"
> EndSection
> Section "Monitor"
>         Identifier      "Generic Monitor"
>         Option          "DPMS"
>         HorizSync       28-64
>         VertRefresh     43-60
> EndSection
> 
> Section "Screen"
>         Identifier      "Default Screen"
>         Device          "Geode"
>         Monitor         "Generic Monitor"
>         DefaultDepth    24
>         SubSection "Display"
>                 Modes           "1280x1024" "1024x768"
>         EndSubSection
> EndSection
> 
> Section "ServerLayout"
>         Identifier      "Default Layout"
>         Screen          "Default Screen"
>         InputDevice     "Generic Keyboard"
>         InputDevice     "USB Mouse"
> 
> EndSection
> 
> Anyway, X is up, but at some point I get this  ...http://pastebin.com/m800b21a

Um - thats bad.  Why are you running aptitude, and what exactly is aptitude
doing?  That looks like memory issues to me.

Jordan

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




From jordan.crouse at amd.com  Wed Jun  4 17:15:01 2008
From: jordan.crouse at amd.com (Jordan Crouse)
Date: Wed, 4 Jun 2008 09:15:01 -0600
Subject: [coreboot] Xorg.conf for LX
In-Reply-To: <13426df10806032052x3ecd79c0j2504f6e30cb2c328@mail.gmail.com>
References: <13426df10806032052x3ecd79c0j2504f6e30cb2c328@mail.gmail.com>
Message-ID: <20080604151501.GC8983@cosmic.amd.com>

On 03/06/08 20:52 -0700, ron minnich wrote:
> I've got this lovely LX framebuffer but am a little unclear on how to
> set up my X11 config.
> 
> any hints welcome. I know that newer Xorg just sorta "gets it right"
> but my ubuntu appears not to be that new.

In fact, current Ubuntu does an awesome job of getting it wrong.
Martin-Eric is working hard trying to resolve that.

Run Xorg -configure from the command line, it will make you a valid
xorg.conf you can use.

Jordan

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




From Marc.Jones at amd.com  Wed Jun  4 18:46:57 2008
From: Marc.Jones at amd.com (Marc Jones)
Date: Wed, 4 Jun 2008 10:46:57 -0600
Subject: [coreboot] patch: fix USB ports on DBE62,
 and other cs5536-based platforms
In-Reply-To: <13426df10806032128r67b6439aw81f5578c48dcd579@mail.gmail.com>
References: <13426df10806032128r67b6439aw81f5578c48dcd579@mail.gmail.com>
Message-ID: <4846C701.2000406@amd.com>

ron minnich wrote:
> This change adds some debug prints, and a comment warning to dts on cs5536.
> 
> Most importantly it fixes a simple programming error which made it so most of
> the sets on the USB were not doing anything. The bug is also in V2.
> 


> /* the /sizeof(u32) is to convert byte offsets into u32 offsets */
> #define HCCPARAMS		(0x08/sizeof(u32))



I don't understand this change. This is standard MMIO. The memory mapped 
registers are defined 0h, 04h, 08h, 0Ah...

You could
*(bar + 08h) |= 1 << 9;
or
*(bar + 09h) |= 1 << 1;

Can you please explain?

Marc


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




From c-d.hailfinger.devel.2006 at gmx.net  Wed Jun  4 18:50:05 2008
From: c-d.hailfinger.devel.2006 at gmx.net (Carl-Daniel Hailfinger)
Date: Wed, 04 Jun 2008 18:50:05 +0200
Subject: [coreboot] [PATCH] [RFC] v3: CS5536 cleanup
In-Reply-To: <13426df10806040753y17eeb1f1q73319c0c82e00fc2@mail.gmail.com>
References: <48205A47.5060403@gmx.net>
	<4822458B.4030506@gmx.net>	<13426df10805071751p7adb40c8s759875e09ccee15@mail.gmail.com>	<48468AB6.5060605@gmx.net>
	<13426df10806040753y17eeb1f1q73319c0c82e00fc2@mail.gmail.com>
Message-ID: <4846C7BD.5050601@gmx.net>

On 04.06.2008 16:53, ron minnich wrote:
> So, I went to apply and test this patch, but I guess, on reflection,
> I'm pretty uncomfortable with it. Why? Because of this:
>
> +	hide_vpci(0x800079C4);
>
> This is even worse than putting stuff like this in the code
>         dev = dev_find_pci_device(PCI_VENDOR_ID_AMD,
>                               PCI_DEVICE_ID_AMD_CS5536_UDC, 0);
>         if (dev)
>                 pci_write_config32(dev, 0x7C, 0xDEADBEEF);
>
> because at least the latter form doesn't hard code pcidevfn.
>
> I think you are right. hide_vpci should take a dev pointer. So let's
> try to rework with that change to hide_vpci and we can then bring this
> patch in.
>
> hide_vpci then becomes pretty simple in fact ...
>   

Please note that my patch does only change those occurences where

pci_write_config32(dev, 0x7C, 0xDEADBEEF);

was unusable. The rest of the changes is just better commenting,
avoidance of variable reuse and so on.

My original patch had the pci_write_config32 -> hide_vpci transformation
(bad), the updated patch (dated 08.05.2008 02:12) didn't, that way I can
send a followup patch which introduces hide_vpci_dev and cleans up the
rest once you ack this one.

Regards,
Carl-Daniel



From rminnich at gmail.com  Wed Jun  4 19:04:14 2008
From: rminnich at gmail.com (ron minnich)
Date: Wed, 4 Jun 2008 10:04:14 -0700
Subject: [coreboot] patch: fix USB ports on DBE62,
	and other cs5536-based platforms
In-Reply-To: <4846C701.2000406@amd.com>
References: <13426df10806032128r67b6439aw81f5578c48dcd579@mail.gmail.com>
	<4846C701.2000406@amd.com>
Message-ID: <13426df10806041004g4e4eed26s7ad1fdc24162b52a@mail.gmail.com>

On Wed, Jun 4, 2008 at 9:46 AM, Marc Jones <Marc.Jones at amd.com> wrote:
> ron minnich wrote:
>> This change adds some debug prints, and a comment warning to dts on cs5536.
>>
>> Most importantly it fixes a simple programming error which made it so most of
>> the sets on the USB were not doing anything. The bug is also in V2.
>>
>
>
>> /* the /sizeof(u32) is to convert byte offsets into u32 offsets */
>> #define HCCPARAMS             (0x08/sizeof(u32))
>
>
>
> I don't understand this change. This is standard MMIO. The memory mapped
> registers are defined 0h, 04h, 08h, 0Ah...
>
> You could
> *(bar + 08h) |= 1 << 9;
> or
> *(bar + 09h) |= 1 << 1;
>


This is an old C gotcha. Offsets are scaled by the pointer size. bar
is a u32 *. So you see this:
*(bar + HCCPARAMS)

And it's easy to think that it is this:
*(bar + 0xc)

but actually, because bar is a u32 *, it will actually dereference this:
*(bar + 0xc*4) i.e. the sizeof a u32 ...

It has to work this way, because when you do bar++, it increments bar
by 4, not 1.

This is one of the reasons why, for mmio, we ought to be using structs.

thanks

ron



From stepan at coresystems.de  Wed Jun  4 19:32:56 2008
From: stepan at coresystems.de (Stefan Reinauer)
Date: Wed, 04 Jun 2008 19:32:56 +0200
Subject: [coreboot] patch: fix USB ports on DBE62,
 and other cs5536-based platforms
In-Reply-To: <4846C701.2000406@amd.com>
References: <13426df10806032128r67b6439aw81f5578c48dcd579@mail.gmail.com>
	<4846C701.2000406@amd.com>
Message-ID: <4846D1C8.6090603@coresystems.de>

Marc Jones wrote:
> ron minnich wrote:
>   
>> This change adds some debug prints, and a comment warning to dts on cs5536.
>>
>> Most importantly it fixes a simple programming error which made it so most of
>> the sets on the USB were not doing anything. The bug is also in V2.
>>
>>     
>
>
>   
>> /* the /sizeof(u32) is to convert byte offsets into u32 offsets */
>> #define HCCPARAMS		(0x08/sizeof(u32))
>>     
>
>
>
> I don't understand this change. This is standard MMIO. The memory mapped 
> registers are defined 0h, 04h, 08h, 0Ah...
>
> You could
> *(bar + 08h) |= 1 << 9;
> or
> *(bar + 09h) |= 1 << 1;
>   

Yes, this looks much saner...

on i945 i am using a couple of defines for accessing MMIO registers (in
this case the MCHBAR registers)

#define MCHBAR8(x) *((volatile u8 *)(DEFAULT_MCHBAR + x))
#define MCHBAR16(x) *((volatile u16 *)(DEFAULT_MCHBAR + x))
#define MCHBAR32(x) *((volatile u32 *)(DEFAULT_MCHBAR + x))

so you can write

MCHBAR8(DCC) |= (1<<1);

for maximum readablility


> Can you please explain?
>   



-- 
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 --------------
An HTML attachment was scrubbed...
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20080604/96c904d8/attachment.html>

From rminnich at gmail.com  Wed Jun  4 19:37:13 2008
From: rminnich at gmail.com (ron minnich)
Date: Wed, 4 Jun 2008 10:37:13 -0700
Subject: [coreboot] patch: fix USB ports on DBE62,
	and other cs5536-based platforms
In-Reply-To: <4846D1C8.6090603@coresystems.de>
References: <13426df10806032128r67b6439aw81f5578c48dcd579@mail.gmail.com>
	<4846C701.2000406@amd.com> <4846D1C8.6090603@coresystems.de>
Message-ID: <13426df10806041037m57c3356cu2472fcc1f28d84cf@mail.gmail.com>

On Wed, Jun 4, 2008 at 10:32 AM, Stefan Reinauer <stepan at coresystems.de> wrote:

> #define MCHBAR8(x) *((volatile u8 *)(DEFAULT_MCHBAR + x))
> #define MCHBAR16(x) *((volatile u16 *)(DEFAULT_MCHBAR + x))
> #define MCHBAR32(x) *((volatile u32 *)(DEFAULT_MCHBAR + x))
>
> so you can write
>
> MCHBAR8(DCC) |= (1<<1);
>
> for maximum readablility
>

yes but as I mentioned .... one of the very earliest uses of struct,
from the guy who designed C, was to avoid this kind of construct.
Register structures accessed via mmio? set up a struct.

thanks

ron



From Marc.Jones at amd.com  Wed Jun  4 19:41:52 2008
From: Marc.Jones at amd.com (Marc Jones)
Date: Wed, 4 Jun 2008 11:41:52 -0600
Subject: [coreboot] patch: fix USB ports on DBE62,
 and other cs5536-based platforms
In-Reply-To: <13426df10806041004g4e4eed26s7ad1fdc24162b52a@mail.gmail.com>
References: <13426df10806032128r67b6439aw81f5578c48dcd579@mail.gmail.com>	
	<4846C701.2000406@amd.com>
	<13426df10806041004g4e4eed26s7ad1fdc24162b52a@mail.gmail.com>
Message-ID: <4846D3E0.9060506@amd.com>

ron minnich wrote:
> On Wed, Jun 4, 2008 at 9:46 AM, Marc Jones <Marc.Jones at amd.com> wrote:
>> ron minnich wrote:
>>> This change adds some debug prints, and a comment warning to dts on cs5536.
>>>
>>> Most importantly it fixes a simple programming error which made it so most of
>>> the sets on the USB were not doing anything. The bug is also in V2.
>>>
>>
>>> /* the /sizeof(u32) is to convert byte offsets into u32 offsets */
>>> #define HCCPARAMS             (0x08/sizeof(u32))
>>
>>
>> I don't understand this change. This is standard MMIO. The memory mapped
>> registers are defined 0h, 04h, 08h, 0Ah...
>>
>> You could
>> *(bar + 08h) |= 1 << 9;
>> or
>> *(bar + 09h) |= 1 << 1;
>>
> 
> 
> This is an old C gotcha. Offsets are scaled by the pointer size. bar
> is a u32 *. So you see this:
> *(bar + HCCPARAMS)
> 
> And it's easy to think that it is this:
> *(bar + 0xc)
> 
> but actually, because bar is a u32 *, it will actually dereference this:
> *(bar + 0xc*4) i.e. the sizeof a u32 ...
> 
> It has to work this way, because when you do bar++, it increments bar
> by 4, not 1.
> 
> This is one of the reasons why, for mmio, we ought to be using structs.
> 
> thanks
> 
> ron
> 

Doh! I see. It should be a byte pointer and then use the readl() abd 
writel() etc from io.h. I'll post a patch for v2 in a few minutes.

A struct for the entire device seems overkill for a couple of registers.
Marc

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




From stepan at coresystems.de  Wed Jun  4 20:10:59 2008
From: stepan at coresystems.de (Stefan Reinauer)
Date: Wed, 04 Jun 2008 20:10:59 +0200
Subject: [coreboot] patch: fix USB ports on DBE62,
 and other cs5536-based platforms
In-Reply-To: <13426df10806041037m57c3356cu2472fcc1f28d84cf@mail.gmail.com>
References: <13426df10806032128r67b6439aw81f5578c48dcd579@mail.gmail.com>	<4846C701.2000406@amd.com>
	<4846D1C8.6090603@coresystems.de>
	<13426df10806041037m57c3356cu2472fcc1f28d84cf@mail.gmail.com>
Message-ID: <4846DAB3.3080007@coresystems.de>

ron minnich wrote:
> On Wed, Jun 4, 2008 at 10:32 AM, Stefan Reinauer <stepan at coresystems.de> wrote:
>
>   
>> #define MCHBAR8(x) *((volatile u8 *)(DEFAULT_MCHBAR + x))
>> #define MCHBAR16(x) *((volatile u16 *)(DEFAULT_MCHBAR + x))
>> #define MCHBAR32(x) *((volatile u32 *)(DEFAULT_MCHBAR + x))
>>
>> so you can write
>>
>> MCHBAR8(DCC) |= (1<<1);
>>
>> for maximum readablility
>>
>>     
>
> yes but as I mentioned .... one of the very earliest uses of struct,
> from the guy who designed C, was to avoid this kind of construct.
> Register structures accessed via mmio? set up a struct.
>   
The one disadvantage of structs for this kind of thing is that you have
no way to cleanly describe offsets except through padding bytes.
So you end up recalculating offsets of registers and numbers of bytes of
reserved1 - reserved100 arrays within your struct, one for every hole.
And when you add a register, you do the work again, and it's error
prone, a single byte off, and all your registers are wrong.

I'm not against using structs, in fact maybe we should just do it, but
they're not the optimal solution either. The guy who invented struct was
not a firmware developer.


-- 
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 rminnich at gmail.com  Wed Jun  4 20:11:12 2008
From: rminnich at gmail.com (ron minnich)
Date: Wed, 4 Jun 2008 11:11:12 -0700
Subject: [coreboot] patch: fix USB ports on DBE62,
	and other cs5536-based platforms
In-Reply-To: <4846D3E0.9060506@amd.com>
References: <13426df10806032128r67b6439aw81f5578c48dcd579@mail.gmail.com>
	<4846C701.2000406@amd.com>
	<13426df10806041004g4e4eed26s7ad1fdc24162b52a@mail.gmail.com>
	<4846D3E0.9060506@amd.com>
Message-ID: <13426df10806041111p453ddbcfnd479b628386681e5@mail.gmail.com>

On Wed, Jun 4, 2008 at 10:41 AM, Marc Jones <Marc.Jones at amd.com> wrote:
>
> A struct for the entire device seems overkill for a couple of registers.
>

What can I say? In the early Unix days, and even now, it's how we've done it :-)

but anyway ... I'm not that worried about it. It's more interesting to
me that a once-common technique is no longer used that much.

thanks!

ron



From rminnich at gmail.com  Wed Jun  4 20:12:16 2008
From: rminnich at gmail.com (ron minnich)
Date: Wed, 4 Jun 2008 11:12:16 -0700
Subject: [coreboot] patch: fix USB ports on DBE62,
	and other cs5536-based platforms
In-Reply-To: <4846DAB3.3080007@coresystems.de>
References: <13426df10806032128r67b6439aw81f5578c48dcd579@mail.gmail.com>
	<4846C701.2000406@amd.com> <4846D1C8.6090603@coresystems.de>
	<13426df10806041037m57c3356cu2472fcc1f28d84cf@mail.gmail.com>
	<4846DAB3.3080007@coresystems.de>
Message-ID: <13426df10806041112t19ed94b6sab9b99924dcac3c2@mail.gmail.com>

On Wed, Jun 4, 2008 at 11:10 AM, Stefan Reinauer <stepan at coresystems.de> wrote:

> I'm not against using structs, in fact maybe we should just do it, but
> they're not the optimal solution either. The guy who invented struct was
> not a firmware developer.
>

you gotta trust me on this, but, back then, writing an OS was not that
much different. In fact Unix V6 and coreboot are just about the same
size ...

ron



From stepan at coresystems.de  Wed Jun  4 20:30:38 2008
From: stepan at coresystems.de (Stefan Reinauer)
Date: Wed, 04 Jun 2008 20:30:38 +0200
Subject: [coreboot] patch: fix USB ports on DBE62,
 and other cs5536-based platforms
In-Reply-To: <13426df10806041112t19ed94b6sab9b99924dcac3c2@mail.gmail.com>
References: <13426df10806032128r67b6439aw81f5578c48dcd579@mail.gmail.com>	<4846C701.2000406@amd.com>
	<4846D1C8.6090603@coresystems.de>	<13426df10806041037m57c3356cu2472fcc1f28d84cf@mail.gmail.com>	<4846DAB3.3080007@coresystems.de>
	<13426df10806041112t19ed94b6sab9b99924dcac3c2@mail.gmail.com>
Message-ID: <4846DF4E.2040906@coresystems.de>

ron minnich wrote:
> On Wed, Jun 4, 2008 at 11:10 AM, Stefan Reinauer <stepan at coresystems.de> wrote:
>   
>> I'm not against using structs, in fact maybe we should just do it, but
>> they're not the optimal solution either. The guy who invented struct was
>> not a firmware developer
>
> you gotta trust me on this, but, back then, writing an OS was not that
> much different. In fact Unix V6 and coreboot are just about the same
> size ...
>   
So are you saying we should make this part of our coding guidelines?

I believe we really have not used this anywhere in v2 so far. Maybe we
should start doing this for v3?

How do we handle tables like the resource setup in the K8 code? It's
mostly int arrays of

{
   offset, andvalue, orvalue,
   offset, andvalue, orvalue,
   offset, andvalue, orvalue,
}

This kind of partial filling would have to be done in code completely

mystruct.member1 &= andvalue1;
mystruct.member1 |= orvalue1;
...

Or is there a better way?


-- 
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 --------------
An HTML attachment was scrubbed...
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20080604/c6d8cdac/attachment.html>

From Marc.Jones at amd.com  Wed Jun  4 21:21:46 2008
From: Marc.Jones at amd.com (Marc Jones)
Date: Wed, 4 Jun 2008 13:21:46 -0600
Subject: [coreboot] [patch][v2] cs5536 usb port4 configuration
Message-ID: <4846EB4A.3040602@amd.com>

This patch uses byte pointer and the MMIO read and write functions.

Marc

-- 
Marc Jones
Senior Firmware Engineer
(970) 226-9684 Office
mailto:Marc.Jones at amd.com
http://www.amd.com/embeddedprocessors
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: usb.patch
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20080604/71a698b0/attachment.ksh>

From jordan.crouse at amd.com  Wed Jun  4 21:31:27 2008
From: jordan.crouse at amd.com (Jordan Crouse)
Date: Wed, 4 Jun 2008 13:31:27 -0600
Subject: [coreboot] patch: fix USB ports on DBE62,
	and other cs5536-based platforms
In-Reply-To: <4846DF4E.2040906@coresystems.de>
References: <13426df10806032128r67b6439aw81f5578c48dcd579@mail.gmail.com>
	<4846C701.2000406@amd.com> <4846D1C8.6090603@coresystems.de>
	<13426df10806041037m57c3356cu2472fcc1f28d84cf@mail.gmail.com>
	<4846DAB3.3080007@coresystems.de>
	<13426df10806041112t19ed94b6sab9b99924dcac3c2@mail.gmail.com>
	<4846DF4E.2040906@coresystems.de>
Message-ID: <20080604193127.GA13534@cosmic.amd.com>

On 04/06/08 20:30 +0200, Stefan Reinauer wrote:
> ron minnich wrote:
> > On Wed, Jun 4, 2008 at 11:10 AM, Stefan Reinauer <stepan at coresystems.de> wrote:
> >   
> >> I'm not against using structs, in fact maybe we should just do it, but
> >> they're not the optimal solution either. The guy who invented struct was
> >> not a firmware developer
> >
> > you gotta trust me on this, but, back then, writing an OS was not that
> > much different. In fact Unix V6 and coreboot are just about the same
> > size ...
> >   
> So are you saying we should make this part of our coding guidelines?

NAK, NAK, NAK, NAK.

Sometimes, there are good reasons for practices to fall out of 
use.  Using a struct for mmio is not in common usage today for a
variety of reasons (see Linux kernel, Xorg, various RTOSen both
closed and opened).

That said, we shouldn't pick our guidelines based on tradition or what
Linus happens to be doing today, we should pick them based on common sense
and what works for our project.

Common sense dictates to me that it is far easier to keep a datasheet
synced with a list of #defines then a structure.  Verifying that you
have the right offsets by counting member sizes in the structure is
a recipe for disaster.  Not all MMIO spaces are sequential - sometimes the
register offsets are bunched together on 0x100 or 0x1000 boundaries -
take the Geode LX display filter for example - the regular display
registers are from offsets 0x00 - 0x120, but the panel control registers
start at 0x400. There is no clean way to map that in a structure without
causing some WTF sirens to go off.

Let us allow everybody to use what they want and try not to legislate
ourselves too badly.  And for the love of crumbcake, please start using
void * (or failing that u8 *) for MMIO pointers!  :)

Jordan

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




From rminnich at gmail.com  Wed Jun  4 21:50:48 2008
From: rminnich at gmail.com (ron minnich)
Date: Wed, 4 Jun 2008 12:50:48 -0700
Subject: [coreboot] patch: fix USB ports on DBE62,
	and other cs5536-based platforms
In-Reply-To: <20080604193127.GA13534@cosmic.amd.com>
References: <13426df10806032128r67b6439aw81f5578c48dcd579@mail.gmail.com>
	<4846C701.2000406@amd.com> <4846D1C8.6090603@coresystems.de>
	<13426df10806041037m57c3356cu2472fcc1f28d84cf@mail.gmail.com>
	<4846DAB3.3080007@coresystems.de>
	<13426df10806041112t19ed94b6sab9b99924dcac3c2@mail.gmail.com>
	<4846DF4E.2040906@coresystems.de>
	<20080604193127.GA13534@cosmic.amd.com>
Message-ID: <13426df10806041250p51c7360eqcd90b988aa02eba6@mail.gmail.com>

On Wed, Jun 4, 2008 at 12:31 PM, Jordan Crouse <jordan.crouse at amd.com> wrote:
> On 04/06/08 20:30 +0200, Stefan Reinauer wrote:

>> So are you saying we should make this part of our coding guidelines?
>
> NAK, NAK, NAK, NAK.
>

yes, Jordan is right on this point. It's not common practice any more,
and nobody has been using it, no need to make it a guideline.

ron



From ward at gnu.org  Thu Jun  5 00:07:44 2008
From: ward at gnu.org (Ward Vandewege)
Date: Wed, 4 Jun 2008 18:07:44 -0400
Subject: [coreboot] Fix M57SLI interrupts, again
In-Reply-To: <200805252342.09803.duwe@lst.de>
References: <200805252342.09803.duwe@lst.de>
Message-ID: <20080604220744.GA31413@localdomain>

Hi Torsten,

On Sun, May 25, 2008 at 11:42:09PM +0200, Torsten Duwe wrote:
> Please test, especially on v2.x
> 
> With current code, the primary PCIe slot is no longer bus#6, but 7.

I'm not sure I follow. On a v1 board:

coreboot v3360: primary PCIe slot:

  0000:07:00.0 VGA compatible controller: nVidia Corporation: Unknown device
0392 (rev a1)

coreboot v3360: secondary PCIe slot:

  0000:02:00.0 VGA compatible controller: nVidia Corporation: Unknown device
0392 (rev a1)

proprietary bios (F5): primary PCIe slot:

  0000:02:00.0 VGA compatible controller: nVidia Corporation: Unknown device
0392 (rev a1)

proprietary bios (F5): secondary PCIe slot:

  0000:02:00.0 VGA compatible controller: nVidia Corporation: Unknown device
0392 (rev a1)

That's right, the same bus id. In fact, the only difference in lcpsi when
switching the vga card to the other PCIe slot under the proprietary bios is:

  -0000:00:0f.0 PCI bridge: nVidia Corporation: Unknown device 0377 (rev a2)
  +0000:00:0a.0 PCI bridge: nVidia Corporation: Unknown device 0376 (rev a2)

> This patch makes the graphics card, 

Do you mean it fixes the proprietary Nvidia driver's IRQ problem? With the
free nvida driver both PCIe slots work for me. I have not tested the
proprietary driver.

> as well as both PCI slots' INT A,
> work again, at least on my V1.0 board.

That's the other thing I'm not entirely sure of; both PCI slots seem to work
for me with stock 3306. I've plugged network cards in both and they seem to
be happy.

Can you elaborate a bit more on the problems you are seeing?

Thanks,
Ward.

> Signed-off-by: Torsten Duwe <duwe at lst.de>
> 
> --- CVS/coreboot-v2/src/mainboard/gigabyte/m57sli/mptable.c	2008-01-27 23:45:00.000000000 +0100
> +++ tmp/coreboot-v2/src/mainboard/gigabyte/m57sli/mptable.c	2008-05-19 10:49:05.000000000 +0200
> @@ -3,6 +3,7 @@
>   *
>   * Copyright (C) 2007 AMD
>   * Written by Yinghai Lu <yinghailu at amd.com> for AMD.
> + * Copyright (C) 2007,2008 Torsten Duwe
>   *
>   * 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
> @@ -140,7 +141,7 @@
>  	for(j=7; j>=2; j--) {
>  		if(!bus_mcp55[j]) continue;
>  	        for(i=0;i<4;i++) { /* map all functions */
> -        	        PCI_INT(j,0,i, 16+(1+j+i)%4);
> +        	        PCI_INT(j,0,i, 16+(j+i)%4);
>          	}
>  	}
>  

> -- 
> coreboot mailing list
> coreboot at coreboot.org
> http://www.coreboot.org/mailman/listinfo/coreboot
> 
> !DSPAM:4839dd4526894879134247!

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



From ward at gnu.org  Thu Jun  5 00:21:19 2008
From: ward at gnu.org (Ward Vandewege)
Date: Wed, 4 Jun 2008 18:21:19 -0400
Subject: [coreboot] Fix M57SLI interrupts, again
In-Reply-To: <20080604220744.GA31413@localdomain>
References: <200805252342.09803.duwe@lst.de>
	<20080604220744.GA31413@localdomain>
Message-ID: <20080604222119.GA17945@localdomain>

On Wed, Jun 04, 2008 at 06:07:44PM -0400, Ward Vandewege wrote:
> > as well as both PCI slots' INT A,
> > work again, at least on my V1.0 board.
> 
> That's the other thing I'm not entirely sure of; both PCI slots seem to work
> for me with stock 3306. I've plugged network cards in both and they seem to
> be happy.

To follow up on this, both with and without your fix I can make a nic on the
edge pci slot do this:

[  336.340000] Uhhuh. NMI received for unknown reason a1 on CPU 0.
[  336.340000] Uhhuh. NMI received for unknown reason 00 on CPU 1.
[  336.340000] Do you have a strange power saving mode enabled?
[  336.340000] Dazed and confused, but trying to continue
[  336.340000] You have some hardware problem, likely on the PCI bus.
[  336.340000] Dazed and confused, but trying to continue

That's by simply making it print a bunch of text over ssh.

Hrm. I guess things are not quite ok yet.

Thanks,
Ward.

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



From rminnich at gmail.com  Thu Jun  5 02:19:44 2008
From: rminnich at gmail.com (ron minnich)
Date: Wed, 4 Jun 2008 17:19:44 -0700
Subject: [coreboot] [patch][v2] cs5536 usb port4 configuration
In-Reply-To: <4846EB4A.3040602@amd.com>
References: <4846EB4A.3040602@amd.com>
Message-ID: <13426df10806041719s550fc46er37ec243832d7d6e3@mail.gmail.com>

neat.

Do you want to do that for v3? I like it.

:-)

ron



From luja at openhardware.de  Thu Jun  5 11:21:03 2008
From: luja at openhardware.de (Ludwig Jaffe)
Date: Thu, 05 Jun 2008 11:21:03 +0200
Subject: [coreboot] Unprotecting 29F002BT
In-Reply-To: <BAY132-W36254405BF33DC9D8E9CDFC7BB0@phx.gbl>
References: <BAY132-W36254405BF33DC9D8E9CDFC7BB0@phx.gbl>
Message-ID: <4847AFFF.2060807@openhardware.de>

a a schrieb:
> Ludwig Jaffe wrote:
> > Hi
> >
> > yes, I will check the jumper to unprotect the flash.
> > Accourding to an1122 this should be the "temporary unprotect"
> > by rising pin1 to 12V=VID.
> > The block-unprotect algorithm (protect all blocks, then unprotect all)
> > should be added to flashrom aswell so we can permanently unprotect the
> > flash.
>
> jep done that .. but i think you did also ?

No, not yet. That is work to do.
Soldering-in the jumper is not the big deal btw.

>
>
> > Greetings
> >
> > LuJa
> >
> >
> >
> > a a schrieb:
> >> Ludwig Jaffe wrote:
> >>> Hi,
> >>>
> >>> looking for the unprotect-algorithm I found the AN1122 from ST.
> >>> The figure 4 shows a way to do this, but, how do we put VID=12V to
> >> Pin#1?
> >>> Does anybody know how this is done or if we should use the
> >>> programmer-mode/way instaed of insystem/mode/way?
> >>>
> >>> Thanks for your comments.
> >>>
> >>> Attached the application-note, and the datasheet of st29F002B series.
> >>>
> >>>
> >>> Greetings
> >>>
> >>> LuJa
> >>>
> >>>
> >> from the other tread i assume you are talking about the
> >> compaq deskpro en sff 600n motherboard which has a jumper (P34 but not
> >> mounted only pads) to connect pin1 to 12Vdc
> >>
> >>
> >> 
> ------------------------------------------------------------------------
> >> Express yourself instantly with MSN Messenger! MSN Messenger
> >>
> >
> >
> >
>
>
>
> ------------------------------------------------------------------------
> Express yourself instantly with MSN Messenger! MSN Messenger 
> <http://clk.atdmt.com/AVE/go/onm00200471ave/direct/01/>




From svn at coreboot.org  Thu Jun  5 16:54:13 2008
From: svn at coreboot.org (svn at coreboot.org)
Date: Thu,  5 Jun 2008 16:54:13 +0200
Subject: [coreboot] r201 - buildrom-devel/config/payloads
Message-ID: <mailman.1620.1355071330.16123.coreboot@coreboot.org>

Author: jcrouse
Date: 2008-06-05 16:54:13 +0200 (Thu, 05 Jun 2008)
New Revision: 201

Modified:
   buildrom-devel/config/payloads/Config.in
Log:
DIsable LZMA on Geode for coreboot-v2 since we don't have a Config-lab.lb
that is appropriate for Geode platforms.  Trivial.

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



Modified: buildrom-devel/config/payloads/Config.in
===================================================================
--- buildrom-devel/config/payloads/Config.in	2008-06-02 16:14:55 UTC (rev 200)
+++ buildrom-devel/config/payloads/Config.in	2008-06-05 14:54:13 UTC (rev 201)
@@ -5,6 +5,7 @@
 
 config USE_LZMA
 	bool "Enable LZMA compression"
+	depends COREBOOT_V3 || (COREBOOT_V2 && !PLATFORM_GEODE)
 	default y
 	help
 	  Precompress the payload with LZMA when using coreboot v2. This changes




From joe at settoplinux.org  Thu Jun  5 17:44:17 2008
From: joe at settoplinux.org (Joseph Smith)
Date: Thu, 05 Jun 2008 11:44:17 -0400
Subject: [coreboot] ram init help on the i82830
In-Reply-To: <48468739.4010207@gmx.net>
References: <bd5a919d8f8c9f3b1843712f5dc06e7d@imap.1and1.com><dd3c80060805272040n58bd85f3x95bfc2cc0928f308@mail.gmail.com><dd3c80060805272104u9efe708h892f6d1f98fa1a1c@mail.gmail.com><2b006022ef73ffcb29f9a499ec98605f@imap.1and1.com><d9895cb58ebc619bc751b8882077b2af@imap.1and1.com><dd3c80060805282246n200d7eb9j3ea094a7fbbc8519@mail.gmail.com><d570aa83b51576676c357b9ee62740ca@imap.1and1.com>	<de5fd7225ea3f050b203bb4e8ec69944@imap.1and1.com>	<A4E79ED7CDA94E91A6B7B622DC3C2667@smitty2m>
	<a93e55d75703dacc4135e58c015b9f69@imap.1and1.com>
	<48468739.4010207@gmx.net>
Message-ID: <6beaecf9bd96719afae342509c175c2f@imap.1and1.com>




On Wed, 04 Jun 2008 14:14:49 +0200, Carl-Daniel Hailfinger
<c-d.hailfinger.devel.2006 at gmx.net> wrote:
> On 04.06.2008 04:59, Joseph Smith wrote:
>> Good News!!!
>> I think I got it working :-)
>>
> 
> Great!
> 
>> I am running memtest86 right now and if all goes well I build it again
> with
>> filo and test it.
>>
>> First I tried with initializing each dimm socket. I booted to memtest
> and
>> it kept erroring out at 256mb. Because this is a double sidded 512MB
>> so-dimm, I figured out that each side of each dimm needs to be
> initialized.
>> So I came up with this:
>>
>>
>> 	for (i = 0; i < MAX_DIMM_SIDES; i++) {
>> 		dimm_end = pci_read_config8(ctrl->d0, DRB + i);
>> 		if (dimm_end > dimm_start) {
>> 			PRINT_DEBUG("    Sending RAM command 0x");
>> 			PRINT_DEBUG_HEX32(reg32);
>> 			PRINT_DEBUG(" to 0x");
>> 			PRINT_DEBUG_HEX32((dimm_start * 32 * 1024 * 1024) + addr_offset);
>> 			PRINT_DEBUG("\r\n");
>> 			read32((dimm_start * 32 * 1024 * 1024) + addr_offset);
>> 		}
>> 		/* Set the start of the next DIMM. */
>> 		dimm_start = dimm_end;
>> 	}
>>
>> It seems to work good so far, hopefully I will be submitting a patch
> soon.
>>
> 
> Please submit a patch now, regardless of how ugly/polluted/unclean it
> is. We had too many losses of great patches in the past because
> computers died and an early not-ready patch is better than nothing.
> 
Oh, don't worry all be submitting a patch. I just want to make sure I have
my bases covered first.
I hope You don't think the code above is in any way
"ugly/polluted/unclean". I think it is a very clean, fast, and great way to
acomplish memory initialization.

-- 
Thanks,
Joseph Smith
Set-Top-Linux
www.settoplinux.org




From mylesgw at gmail.com  Thu Jun  5 19:09:14 2008
From: mylesgw at gmail.com (Myles Watson)
Date: Thu, 5 Jun 2008 11:09:14 -0600
Subject: [coreboot] r201 - buildrom-devel/config/payloads
In-Reply-To: <4847fe34.0aec660a.2b0e.40d4SMTPIN_ADDED@mx.google.com>
References: <4847fe34.0aec660a.2b0e.40d4SMTPIN_ADDED@mx.google.com>
Message-ID: <00cd01c8c72e$e23fe380$0023040a@chimp>



> Author: jcrouse
> Date: 2008-06-05 16:54:13 +0200 (Thu, 05 Jun 2008)
> New Revision: 201
> 
> Modified:
>    buildrom-devel/config/payloads/Config.in
> Log:
> DIsable LZMA on Geode for coreboot-v2 since we don't have a Config-lab.lb
> that is appropriate for Geode platforms.  Trivial.

Why not add the Config-lab.lb instead?  I realize that it maybe should be
Config-lzma.lb, but it seems like Geode users might want compression too.

Thanks,
Myles





From wharms at bfs.de  Thu Jun  5 19:12:04 2008
From: wharms at bfs.de (walter harms)
Date: Thu, 05 Jun 2008 19:12:04 +0200
Subject: [coreboot] flashrom and list of computers
Message-ID: <48481E64.3000903@bfs.de>

hi list,
after the nice flashrom demonstration on linuxtag in berlin.
i have compiled flashrom and tested on several computer in the company.
(simply using ./flashrom)

Is there anyone interested in collecting these data ?
Motherboard (Manufacturer) + flashrom result ?

re,
 wh




From nathanael at gnat.ca  Thu Jun  5 19:44:15 2008
From: nathanael at gnat.ca (Nathanael D. Noblet)
Date: Thu, 05 Jun 2008 11:44:15 -0600
Subject: [coreboot] Acer Opens Up...
Message-ID: <484825EF.1050600@gnat.ca>

Just came across this...
http://www.itnews.com.au/News/77636,acer-bets-big-on-linux.aspx

I'm wondering if they are using or know of coreboot?? Perhaps an 
opportunity to get in with a vendor, if they haven't already contacted 
you guys...


-- 
Nathanael d. Noblet
Gnat Solutions, Inc
T: 403.875.4613



From bari at onelabs.com  Thu Jun  5 20:39:36 2008
From: bari at onelabs.com (bari)
Date: Thu, 05 Jun 2008 13:39:36 -0500
Subject: [coreboot] flashrom and list of computers
In-Reply-To: <48481E64.3000903@bfs.de>
References: <48481E64.3000903@bfs.de>
Message-ID: <484832E8.6030002@onelabs.com>

walter harms wrote:
> hi list,
> after the nice flashrom demonstration on linuxtag in berlin.
> i have compiled flashrom and tested on several computer in the company.
> (simply using ./flashrom)
>
> Is there anyone interested in collecting these data ?
> Motherboard (Manufacturer) + flashrom result ?
>
>   
Yes, post it here if you have the model numbers as well (with lspci 
would be even better).

-Bari



From c-d.hailfinger.devel.2006 at gmx.net  Thu Jun  5 21:00:01 2008
From: c-d.hailfinger.devel.2006 at gmx.net (Carl-Daniel Hailfinger)
Date: Thu, 05 Jun 2008 21:00:01 +0200
Subject: [coreboot] ram init help on the i82830
In-Reply-To: <6beaecf9bd96719afae342509c175c2f@imap.1and1.com>
References: <bd5a919d8f8c9f3b1843712f5dc06e7d@imap.1and1.com><dd3c80060805272040n58bd85f3x95bfc2cc0928f308@mail.gmail.com><dd3c80060805272104u9efe708h892f6d1f98fa1a1c@mail.gmail.com><2b006022ef73ffcb29f9a499ec98605f@imap.1and1.com><d9895cb58ebc619bc751b8882077b2af@imap.1and1.com><dd3c80060805282246n200d7eb9j3ea094a7fbbc8519@mail.gmail.com><d570aa83b51576676c357b9ee62740ca@imap.1and1.com>	<de5fd7225ea3f050b203bb4e8ec69944@imap.1and1.com>	<A4E79ED7CDA94E91A6B7B622DC3C2667@smitty2m>
	<a93e55d75703dacc4135e58c015b9f69@imap.1and1.com>
	<48468739.4010207@gmx.net>
	<6beaecf9bd96719afae342509c175c2f@imap.1and1.com>
Message-ID: <484837B1.8020800@gmx.net>

On 05.06.2008 17:44, Joseph Smith wrote:
>
> On Wed, 04 Jun 2008 14:14:49 +0200, Carl-Daniel Hailfinger
> <c-d.hailfinger.devel.2006 at gmx.net> wrote:
>   
>> Please submit a patch now, regardless of how ugly/polluted/unclean it
>> is. We had too many losses of great patches in the past because
>> computers died and an early not-ready patch is better than nothing.
>>
>>     
> Oh, don't worry all be submitting a patch. I just want to make sure I have
> my bases covered first.
> I hope You don't think the code above is in any way
> "ugly/polluted/unclean". I think it is a very clean, fast, and great way to
> acomplish memory initialization.
>   

Sure, the code looks nice. I wanted to say something along the lines of
"if you have any leftover unrelated changes in the tree, don't worry
about them and submit the state of your tree anyway". I wish to
apologize if my statement caused any irritation. As a non-native speaker
I occassionally miss subtle meanings in a sentence.


Regards,
Carl-Daniel



From joe at settoplinux.org  Thu Jun  5 21:16:51 2008
From: joe at settoplinux.org (Joseph Smith)
Date: Thu, 05 Jun 2008 15:16:51 -0400
Subject: [coreboot] ram init help on the i82830
In-Reply-To: <484837B1.8020800@gmx.net>
References: <bd5a919d8f8c9f3b1843712f5dc06e7d@imap.1and1.com><dd3c80060805272040n58bd85f3x95bfc2cc0928f308@mail.gmail.com><dd3c80060805272104u9efe708h892f6d1f98fa1a1c@mail.gmail.com><2b006022ef73ffcb29f9a499ec98605f@imap.1and1.com><d9895cb58ebc619bc751b8882077b2af@imap.1and1.com><dd3c80060805282246n200d7eb9j3ea094a7fbbc8519@mail.gmail.com><d570aa83b51576676c357b9ee62740ca@imap.1and1.com>	<de5fd7225ea3f050b203bb4e8ec69944@imap.1and1.com>	<A4E79ED7CDA94E91A6B7B622DC3C2667@smitty2m>
	<a93e55d75703dacc4135e58c015b9f69@imap.1and1.com>
	<48468739.4010207@gmx.net>
	<6beaecf9bd96719afae342509c175c2f@imap.1and1.com>
	<484837B1.8020800@gmx.net>
Message-ID: <b602ba0ca8dc5b2dea8ba5fb21d8be56@imap.1and1.com>




On Thu, 05 Jun 2008 21:00:01 +0200, Carl-Daniel Hailfinger
<c-d.hailfinger.devel.2006 at gmx.net> wrote:
> On 05.06.2008 17:44, Joseph Smith wrote:
>>
>> On Wed, 04 Jun 2008 14:14:49 +0200, Carl-Daniel Hailfinger
>> <c-d.hailfinger.devel.2006 at gmx.net> wrote:
>>
>>> Please submit a patch now, regardless of how ugly/polluted/unclean it
>>> is. We had too many losses of great patches in the past because
>>> computers died and an early not-ready patch is better than nothing.
>>>
>>>
>> Oh, don't worry all be submitting a patch. I just want to make sure I
> have
>> my bases covered first.
>> I hope You don't think the code above is in any way
>> "ugly/polluted/unclean". I think it is a very clean, fast, and great way
> to
>> acomplish memory initialization.
>>
> 
> Sure, the code looks nice. I wanted to say something along the lines of
> "if you have any leftover unrelated changes in the tree, don't worry
> about them and submit the state of your tree anyway". I wish to
> apologize if my statement caused any irritation. As a non-native speaker
> I occassionally miss subtle meanings in a sentence.
> 

No worries, Carl-Daniel. I know what you meant. I just want to be sure this
is going to work first. I have been very busy with other life things the
past few days, that is why I have not submitted it yet. This should be a
great advance though, it will allow mutiple dimm (dual and single sided)
support for many of the intel northbridges, including the i810, and
possibly the 440bx(which it is not currently working for).

-- 
Thanks,
Joseph Smith
Set-Top-Linux
www.settoplinux.org




From c-d.hailfinger.devel.2006 at gmx.net  Thu Jun  5 21:22:24 2008
From: c-d.hailfinger.devel.2006 at gmx.net (Carl-Daniel Hailfinger)
Date: Thu, 05 Jun 2008 21:22:24 +0200
Subject: [coreboot] Acer Opens Up...
In-Reply-To: <484825EF.1050600@gnat.ca>
References: <484825EF.1050600@gnat.ca>
Message-ID: <48483CF0.6010404@gmx.net>

On 05.06.2008 19:44, Nathanael D. Noblet wrote:
> Just came across this...
> http://www.itnews.com.au/News/77636,acer-bets-big-on-linux.aspx
>
> I'm wondering if they are using or know of coreboot?? Perhaps an 
> opportunity to get in with a vendor, if they haven't already contacted 
> you guys...
>   

I haven't yet heard from them, maybe someone else knows more.

If anybody has contacts inside Acer, please speak up. I have a
comprehensive list of what we can offer any cooperative vendor and would
like to make sure they don't miss that opportunity.

Regards,
Carl-Daniel



From tiagomnm at gmail.com  Thu Jun  5 21:59:25 2008
From: tiagomnm at gmail.com (Tiago Marques)
Date: Thu, 5 Jun 2008 20:59:25 +0100
Subject: [coreboot] flashrom verify fails, CK804, MCP55
In-Reply-To: <b1335fe90806010809r3eadbf71lb17ab1126906cc7d@mail.gmail.com>
References: <b1335fe90801270721i49a29a58v6ee03b9d5a9037f0@mail.gmail.com>
	<b1335fe90801271006h35de2c71vc3bc6ab13ab39a02@mail.gmail.com>
	<b1335fe90801271006m63b7e884h2440d1d1bb5aa614@mail.gmail.com>
	<20080127181124.GA23002@localdomain>
	<b1335fe90801271119h5af39e2el388df1785d21e015@mail.gmail.com>
	<20080127194808.GA23518@localdomain>
	<b1335fe90801271233p149cccc9k3a60f165ab01fe0c@mail.gmail.com>
	<b1335fe90801290959r6f65c208na74badb4dac9aa@mail.gmail.com>
	<47AC6B27.6040708@gmx.net>
	<b1335fe90806010809r3eadbf71lb17ab1126906cc7d@mail.gmail.com>
Message-ID: <b1335fe90806051259g7bf14951ybcca4985761a836b@mail.gmail.com>

help?


On 6/1/08, Tiago Marques <tiagomnm at gmail.com> wrote:
> Finally had some time to test this.
>  The erase command does nothing, I was still able to download the full
>  BIOS and boot the machine. This using the latest flashrom revision.
>  First step is to make it erase? Where should I start?
>
>  Best regards
>
>
>
>  On 2/8/08, Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006 at gmx.net> wrote:
>  > On 29.01.2008 18:59, Tiago Marques wrote:
>  >  > Any ideas? From where should I start?
>  >  >
>  >
>  >
>  > Try to erase a chip with "flashrom -E" (just erase, no write, no verify)
>  >  and then read back the contents with "flashrom -r". Look at the
>  >  resulting file with xxd or hexdump and check if it is all 0xff.
>  >  I suspect that it will not be all 0xff when erased in the problematic
>  >  boards, but it will be all 0xff when erased in the K8T890 board.
>  >
>  >  Regards,
>  >  Carl-Daniel
>  >
>  >
>  >  --
>  >  http://www.hailfinger.org/
>  >
>  >
>



From c-d.hailfinger.devel.2006 at gmx.net  Thu Jun  5 22:18:21 2008
From: c-d.hailfinger.devel.2006 at gmx.net (Carl-Daniel Hailfinger)
Date: Thu, 05 Jun 2008 22:18:21 +0200
Subject: [coreboot] flashrom verify fails, CK804, MCP55
In-Reply-To: <b1335fe90806051259g7bf14951ybcca4985761a836b@mail.gmail.com>
References: <b1335fe90801270721i49a29a58v6ee03b9d5a9037f0@mail.gmail.com>	<b1335fe90801271006h35de2c71vc3bc6ab13ab39a02@mail.gmail.com>	<b1335fe90801271006m63b7e884h2440d1d1bb5aa614@mail.gmail.com>	<20080127181124.GA23002@localdomain>	<b1335fe90801271119h5af39e2el388df1785d21e015@mail.gmail.com>	<20080127194808.GA23518@localdomain>	<b1335fe90801271233p149cccc9k3a60f165ab01fe0c@mail.gmail.com>	<b1335fe90801290959r6f65c208na74badb4dac9aa@mail.gmail.com>	<47AC6B27.6040708@gmx.net>	<b1335fe90806010809r3eadbf71lb17ab1126906cc7d@mail.gmail.com>
	<b1335fe90806051259g7bf14951ybcca4985761a836b@mail.gmail.com>
Message-ID: <48484A0D.8040706@gmx.net>

On 05.06.2008 21:59, Tiago Marques wrote:
> help?
>
>
> On 6/1/08, Tiago Marques <tiagomnm at gmail.com> wrote:
>   
>> Finally had some time to test this.
>>  The erase command does nothing, I was still able to download the full
>>  BIOS and boot the machine. This using the latest flashrom revision.
>>  First step is to make it erase? Where should I start?
>>     

Sorry, I will be unavailable for the rest of the month due to diploma
thesis work. I hope you can find somebody else on this list to help you.


Regards,
Carl-Daniel



From c-d.hailfinger.devel.2006 at gmx.net  Thu Jun  5 22:31:36 2008
From: c-d.hailfinger.devel.2006 at gmx.net (Carl-Daniel Hailfinger)
Date: Thu, 05 Jun 2008 22:31:36 +0200
Subject: [coreboot] Fwd: Re: Open Firmware
Message-ID: <48484D28.9010705@gmx.net>

Hi all,

I felt compelled to respond to the post by Werner Almesberger on
openmoko-kernel, but forgot to CC it here, so you get it as forwarded mail.

Regards,
Carl-Daniel

-------- Original Message --------
Subject: 	Re: Open Firmware
Date: 	Thu, 05 Jun 2008 22:16:37 +0200
From: 	Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006 at gmx.net>
To: 	openmoko-kernel at lists.openmoko.org
References: 	7780e76c0805231833x58ac3655j34e2eb1ee9bdbe40 at mail.gmail.com



Hi all,

sorry for appearing out of nowhere. I have been following Openmoko for
quite some time and I'm very pleasantly surprised by what has been
achieved in such short time.

Werner Almesberger wrote:
> I wonder what troubles OLPC ran into with LinuxBIOS. I can understand
> the slow boot time issues, but it should be easy enough to add a
> fastpath for this.

As someone who participated in early porting of LinuxBIOS (now coreboot)
to the OLPC platform, I feel I'm qualified to answer this.
Basically, in the beginning there was a choice between a proprietary
BIOS and LinuxBIOS+Linux in the ROM. Since LinuxBIOS-Linux worked so
well, that solution was chosen. However, size constraints of the ROM
eventually led to the conclusion that something smaller than a full
Linux kernel in the ROM was desirable. At that point, OpenFirmware
became open source and it was subsequently used in combination with
LinuxBIOS in the ROM. After some time, Mitch Bradley (OpenFirmware
creator and expert) was (iirc) hired by OLPC to work on the firmware
full time. Since he's an OpenFirmware expert and was not too familiar
with the LinuxBIOS code, he eventually decided to move early hardware
init into OpenFirmware and remove LinuxBIOS.
The slow boot time was only partially (~10%) caused by LinuxBIOS version
2 and that issue has been fixed in coreboot v3. I have seen rather slow
AMD Geode machines run through coreboot v3 initialization in 500 ms
(including RAM setup, PCI setup etc.), so 500 ms after poweron you get
to pass execution to a Linux kernel. Depending on your hardware, faster
startup is possible.


At the beginning of this year, LinuxBIOS was renamed to coreboot because
we're neither a BIOS nor do we have Linux dependencies. However, we
optionally support a Linux kernel (and a traditional BIOS emulation if
anyone wants that) as a so-called payload, the thing that's executed
directly after the lowlevel hardware init has been performed.

We (the coreboot team) are very interested in validating our brand new
coreboot version 3 design on multiple architectures. It works well on
x86 (AMD GeodeLX is tested right now) and you can bundle it with a Linux
kernel in ROM easily. We call that scenario LAB (Linux As Bootloader)
and some people use it heavily. Since coreboot supports LZMA compressed
payloads natively, having a complete Linux kernel in ROM is not a big
size challenge anymore.

If anybody wants to port coreboot to the FreeRunner or any other
platform, we'd be happy to help. A first look at the code is probably
easiest if you pick the coreboot v3 qemu(x86) target and work from there.

More info about coreboot is available at http://www.coreboot.org/ .
The mailing list is http://www.coreboot.org/mailman/listinfo/coreboot
IRC (may be a bit slow to respond) http://www.coreboot.org/IRC

If you have any questions, want a short demo, pointers to "cool
features" lists or a generic introduction, feel free to ask either me
personally or all developers via our mailing list.

Regards,
Carl-Daniel



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




From Ken.Fuchs at bench.com  Fri Jun  6 00:37:10 2008
From: Ken.Fuchs at bench.com (Ken.Fuchs at bench.com)
Date: Thu, 5 Jun 2008 17:37:10 -0500
Subject: [coreboot] [RFC] Porting coreboot to Intel Atom (Silverthorne) &
	SCH US15W (Poulsbo) chipset
Message-ID: <AA28F077645B324881335614E4F7C428034DBE@win-ex01.bench.com>

Thanks to everyone suggesting AMD processor
alternatives (Geode LX) a while back.  However,
we have decided to stay with Intel Atom (due to
its much faster clock speed as well low power
requirements).

Which version of coreboot (v2 or v3) would be
better to port to Intel Atom?  We want a fast
boot up to both Linux and at least one Microsoft
OS (maybe CE).  Based on Carl-Daniel Hailfinger's
recent post regarding "Open Firmware", v3 would
probably be much faster than v2.

I helped do an (Opteron) nVidia nForce4 LinuxBIOS
port a few years ago, but I don't think it will be
much help in porting coreboot to the Intel Atom.
Which coreboot chipset might be the best starting
point for a port to Intel Atom?

Any other opinions about firmware development
on the Atom would be welcome ...

It seems like an American Arium ECM-XDP3 with
SourcePoint would be well worth the price for
a large porting effort such as this.  (It will
provide both assembly and C level JTAG debugging.)
Is there a cheaper JTAG debugger that might be
viable on Atom/Poulsbo?

The firmware will be stored on a SPI NOR flash
via LPC and an embedded controller rather than
FWH.

I have two major concerns about this port:

1) I may not have enough time/resources to complete
   it.  So I may end up optimizing a commercial UEFI
   solution.

2) I'm not sure I will be able to contribute my
   source code changes back to the coreboot project
   due to NDA restrictions/ambiguities.

Sincerely,

Ken Fuchs



From marc.jones at amd.com  Fri Jun  6 01:32:12 2008
From: marc.jones at amd.com (Marc Jones)
Date: Thu, 5 Jun 2008 17:32:12 -0600
Subject: [coreboot] [patch][v2] cs5536 usb port4 configuration - new v3
 patch
In-Reply-To: <13426df10806041719s550fc46er37ec243832d7d6e3@mail.gmail.com>
References: <4846EB4A.3040602@amd.com>
	<13426df10806041719s550fc46er37ec243832d7d6e3@mail.gmail.com>
Message-ID: <4848777C.5030607@amd.com>

ron minnich wrote:
> neat.
>
> Do you want to do that for v3? I like it.
>
> :-)
>
> ron
>
>   

As you wish. :)
Builds but not tested on a platform. Can you try it on the dbe62?

Thanks,
Marc




-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: usb.patch
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20080605/ac0c4c39/attachment.ksh>

From c-d.hailfinger.devel.2006 at gmx.net  Fri Jun  6 02:26:47 2008
From: c-d.hailfinger.devel.2006 at gmx.net (Carl-Daniel Hailfinger)
Date: Fri, 06 Jun 2008 02:26:47 +0200
Subject: [coreboot] [patch][v2] cs5536 usb port4 configuration - new v3
 patch
In-Reply-To: <4848777C.5030607@amd.com>
References: <4846EB4A.3040602@amd.com>	<13426df10806041719s550fc46er37ec243832d7d6e3@mail.gmail.com>
	<4848777C.5030607@amd.com>
Message-ID: <48488447.8040004@gmx.net>

On 06.06.2008 01:32, Marc Jones wrote:
> ron minnich wrote:
>> neat.
>>
>> Do you want to do that for v3? I like it.
>>
>> :-)
>>
>> ron
>>
>>   
>
> As you wish. :)
> Builds but not tested on a platform. Can you try it on the dbe62?

Dumb question: Does this break strict aliasing in any way?

Regards,
Carl-Daniel



From c-d.hailfinger.devel.2006 at gmx.net  Fri Jun  6 03:49:11 2008
From: c-d.hailfinger.devel.2006 at gmx.net (Carl-Daniel Hailfinger)
Date: Fri, 06 Jun 2008 03:49:11 +0200
Subject: [coreboot] [RFC] Porting coreboot to Intel Atom (Silverthorne)
 &	SCH US15W (Poulsbo) chipset
In-Reply-To: <AA28F077645B324881335614E4F7C428034DBE@win-ex01.bench.com>
References: <AA28F077645B324881335614E4F7C428034DBE@win-ex01.bench.com>
Message-ID: <48489797.3090606@gmx.net>

On 06.06.2008 00:37, Ken.Fuchs at bench.com wrote:
> Thanks to everyone suggesting AMD processor
> alternatives (Geode LX) a while back.  However,
> we have decided to stay with Intel Atom (due to
> its much faster clock speed as well low power
> requirements).
>   

Sure.

> Which version of coreboot (v2 or v3) would be
> better to port to Intel Atom?  We want a fast
> boot up to both Linux and at least one Microsoft
> OS (maybe CE).  Based on Carl-Daniel Hailfinger's
> recent post regarding "Open Firmware", v3 would
> probably be much faster than v2.
>   

IIRC you are trying to use coreboot for commercial purposes, so the
needed development time is probably more important than 200 milliseconds
more or less during boot. Luckily, v3 offers vastly easier development,
probably reducing time-to-market significantly, while facilitating
debugging and improving boot speed at the same time.
Unless there's lots of code in v2 which you can leverage for Atom
porting, may I strongly suggest you try v3?

> I helped do an (Opteron) nVidia nForce4 LinuxBIOS
> port a few years ago, but I don't think it will be
> much help in porting coreboot to the Intel Atom.
> Which coreboot chipset might be the best starting
> point for a port to Intel Atom?
>   

IMO the most important thing would be getting CAR up and running. AFAICS
neither v2 nor v3 have CAR code which has been tested with Atom. Stefan
Reinauer has been working on recent Intel chipsets, so he would know
best, though I'm not sure how related Atom and other processors are. The
SCH US15W looks similar to the ICH6, but I could be totally wrong here.

> Any other opinions about firmware development
> on the Atom would be welcome ...
>   

> The firmware will be stored on a SPI NOR flash
> via LPC and an embedded controller rather than
> FWH.
>   

The embedded controller will be a challenge on its own unless you can
leverage existing (commercial?) code for it.

> I have two major concerns about this port:
>
> 1) I may not have enough time/resources to complete
>    it.  So I may end up optimizing a commercial UEFI
>    solution.
>   

IIRC UEFI can be stacked on top of coreboot, but I'm not sure about the
current state of that project. It should be possible to leave the
lowlevel hardware init to coreboot and pass control to an UEFI
implementation afterwards.

> 2) I'm not sure I will be able to contribute my
>    source code changes back to the coreboot project
>    due to NDA restrictions/ambiguities.
>   

I'm afraid that's pretty much a showstopper. Please try to work out the
details of these restrictions. There are some NDAs which don't have a
problem with publishing code after review, some others are OK with
publishing code as long as it doesn't have any comments mentioning the
docs, ...
Writing code for which the legal status is unclear is usually a lost
effort, especially if you're under time pressure. Having partial code is
better for the project than no code, so if you decide to tackle this,
please check what could be done from public docs and submit these parts
in any case.

Regards,
Carl-Daniel



From segher at kernel.crashing.org  Fri Jun  6 03:11:47 2008
From: segher at kernel.crashing.org (Segher Boessenkool)
Date: Fri, 6 Jun 2008 03:11:47 +0200
Subject: [coreboot] [patch][v2] cs5536 usb port4 configuration - new v3
	patch
In-Reply-To: <48488447.8040004@gmx.net>
References: <4846EB4A.3040602@amd.com>	<13426df10806041719s550fc46er37ec243832d7d6e3@mail.gmail.com>
	<4848777C.5030607@amd.com> <48488447.8040004@gmx.net>
Message-ID: <1f4f14e8f7b7bcb7b3c62ec6530f782a@kernel.crashing.org>

> Dumb question: Does this break strict aliasing in any way?

Show the code?  I'll do you an analysis.


Segher




From jakllsch at kollasch.net  Fri Jun  6 04:44:09 2008
From: jakllsch at kollasch.net (Jonathan A. Kollasch)
Date: Fri, 6 Jun 2008 02:44:09 +0000
Subject: [coreboot] Coreboot, BSD, Makefiles and trac
In-Reply-To: <483E7BEA.7000702@defora.org>
References: <483E7BEA.7000702@defora.org>
Message-ID: <20080606024408.GT4265@tazenda.kollasch.net>

On Thu, May 29, 2008 at 11:48:26AM +0200, Pierre Pronchery wrote:
> 			Hello,
> 
> I'm trying to use the ticket system in trac, but keep being rejected as
> a spammer: "500 Internal Server Error (Submission rejected as potential
> spam)"
> 
> Anyway, what I wanted to report is that Coreboot requires changes to
> compile on BSD (in my case NetBSD). What I wanted to get committed so

Ooooh, spiffy.  I guess this means I have a bit more motivation then.
More on this later.

> far is quite trivial actually: recursive "make" calls should be changed
> to "$(MAKE)", as GNU make (or "gmake") is apparently necessary to build.

Yeah, for coreboot itself there are just a few lines that need patching
to build on NetBSD/i386

> The attached patch is for ADLO, but the generic build system would need
> to be fixed as well.

I haven't pushed very hard for getting this fixed, as I figured
I was one of those for-just-one-user cases.  That and it's easy
enough to patch.

Anyway,
I have a boot(8)-based payload that I've been working on occasionally,
It's in an ugly-ish, somewhat hard-coded, but none-the-less working
state.  Also, it's an easy-ish route to loading NetBSD/amd64's ELF64
kernels.

	Jonathan Kollasch
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 194 bytes
Desc: not available
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20080606/0902b136/attachment.sig>

From rminnich at gmail.com  Fri Jun  6 06:42:30 2008
From: rminnich at gmail.com (ron minnich)
Date: Thu, 5 Jun 2008 21:42:30 -0700
Subject: [coreboot] Fwd: Re: Open Firmware
In-Reply-To: <48484D28.9010705@gmx.net>
References: <48484D28.9010705@gmx.net>
Message-ID: <13426df10806052142v4ff7a69es501b8ac0d17f7ab1@mail.gmail.com>

did you mean 500 milliseconds or 500 microseconds when you said 500
ms? Just curious.

ron



From wharms at bfs.de  Fri Jun  6 09:10:20 2008
From: wharms at bfs.de (walter harms)
Date: Fri, 06 Jun 2008 09:10:20 +0200
Subject: [coreboot] flashrom and list of computers
In-Reply-To: <484832E8.6030002@onelabs.com>
References: <48481E64.3000903@bfs.de> <484832E8.6030002@onelabs.com>
Message-ID: <4848E2DC.3000801@bfs.de>



bari wrote:
> walter harms wrote:
>> hi list,
>> after the nice flashrom demonstration on linuxtag in berlin.
>> i have compiled flashrom and tested on several computer in the company.
>> (simply using ./flashrom)
>>
>> Is there anyone interested in collecting these data ?
>> Motherboard (Manufacturer) + flashrom result ?
>>
>>   
> Yes, post it here if you have the model numbers as well (with lspci
> would be even better).
> 

my idea was to use dmidecode that i can get informations like that:

Handle 0x0100
        DMI type 1, 25 bytes.
        System Information
                Manufacturer: Dell Inc.
                Product Name: OptiPlex GX280
                Version: Not Specified

Handle 0x0200
        DMI type 2, 8 bytes.
        Base Board Information
                Manufacturer: Dell Inc.
                Product Name: 0C7195
                Version:

(Version is not filled, serial numbers removed)

re,
 wh



From formol76 at hotmail.com  Fri Jun  6 10:24:56 2008
From: formol76 at hotmail.com (m-a daneau)
Date: Fri, 6 Jun 2008 08:24:56 +0000
Subject: [coreboot] openbios on tyan s2895
Message-ID: <BAY142-W532C5FBC5952A63713E442DBB70@phx.gbl>


hi, 

surprisingly, my mother board is fully supported by openbios.

i'm now searching a way to install ubuntu and xp on a raid1 with sata.  do you think that an openbios could help in some way?

thank you
m-a

_________________________________________________________________

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

From c-d.hailfinger.devel.2006 at gmx.net  Fri Jun  6 11:34:52 2008
From: c-d.hailfinger.devel.2006 at gmx.net (Carl-Daniel Hailfinger)
Date: Fri, 06 Jun 2008 11:34:52 +0200
Subject: [coreboot] Fwd: Re: Open Firmware
In-Reply-To: <13426df10806052142v4ff7a69es501b8ac0d17f7ab1@mail.gmail.com>
References: <48484D28.9010705@gmx.net>
	<13426df10806052142v4ff7a69es501b8ac0d17f7ab1@mail.gmail.com>
Message-ID: <484904BC.4080606@gmx.net>

On 06.06.2008 06:42, ron minnich wrote:
> did you mean 500 milliseconds or 500 microseconds when you said 500
> ms? Just curious.
>   

500 ms meant milliseconds. us would have been microseconds. I'm also
pretty sure we can improve on that.


Regards,
Carl-Daniel



From c-d.hailfinger.devel.2006 at gmx.net  Fri Jun  6 12:05:46 2008
From: c-d.hailfinger.devel.2006 at gmx.net (Carl-Daniel Hailfinger)
Date: Fri, 06 Jun 2008 12:05:46 +0200
Subject: [coreboot] coreboot & OpenSolaris
In-Reply-To: <4846A9D7.3000605@gmx.net>
References: <4842baec.IC0jKb8m/ClpVPE6%Joerg.Schilling@fokus.fraunhofer.de>	<48454223.3050807@gmx.net>	<484666d2.wU64hZRSUftqvDuP%Joerg.Schilling@fokus.fraunhofer.de>	<48469361.10604@gmx.net>	<48469553.C+kU/ElswhZQACK5%Joerg.Schilling@fokus.fraunhofer.de>	<48469716.7090500@gmx.net>	<4846a530.zV9BNs/vyQfoixoi%Joerg.Schilling@fokus.fraunhofer.de>
	<4846A9D7.3000605@gmx.net>
Message-ID: <48490BFA.8080905@gmx.net>

Hi Joerg,

after the review I have some comments on the patch you sent. The
comments are inline in the patch, it would be great if you could resend
with the mentioned changes and also add a "Signed-off-by:" statement to
your submission. See
http://www.coreboot.org/Development_Guidelines#Sign-off_Procedure for
details.

Thanks.

On 04.06.2008 16:42, Carl-Daniel Hailfinger wrote:
> Hi,
>
> [please CC J?rg on replies, I don't know whether he is already
> subscribed to the list.]
> J?rg Schilling and I have been working to get flashrom to compile again
> under Solaris. The credit belongs to J?rg.
>
> The patch below is a first hack to get everything running and not
> completely ready for merging. Adding platform-specific #include
> statements to each file is suboptimal, I'd prefer to have them all in
> flash.h. Once we have a mergeable patch, I'd like to get a review from
> the person who created Solaris support in the first place.
>
> Besides that, we may want to disable compilation explicitly for any
> untested arch. Especially the problem that there is no agreed-upon order
> of out[bwl] arguments is a disaster waiting to happen if someone tests a
> new Linux-incompatible platform.
>
> Regards,
> Carl-Daniel
>
> On 04.06.2008 16:22, Joerg Schilling wrote:
>   
>> Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006 at gmx.net> wrote:
>>
>>   
>>     
>>> Hast Du evtl. einen unfertigen Patch, den ich durchs Review jagen kann?
>>> Es w?re klasse, wenn wir das vor dem Release 1.0 mergen k?nnen.
>>>     
>>>       
>> hier ist erstmal mein aktueller Stand:
>>
>> --- Makefile.orig	Di Jun  3 16:53:49 2008
>> +++ Makefile	Mi Jun  4 16:21:23 2008
>> @@ -15,6 +15,8 @@
>>  OS_ARCH	= $(shell uname)
>>  ifeq ($(OS_ARCH), SunOS)
>>  LDFLAGS = -lpci -lz
>> +CFLAGS += -I.
>> +LDFLAGS += -L/tmp/pciutils-2.2.10/lib/
>>  else
>>  LDFLAGS = -lpci -lz
>>  STRIP_ARGS = -s
>>     

Please skip the hunk for now since it is specific to your installation.
We can still merge something similar later.

>> @@ -52,7 +54,7 @@
>>  	rm -f $(PROGRAM) .dependencies
>>  	
>>  dep:
>> -	@$(CC) -MM *.c > .dependencies
>> +	$(CC) -M $(CFLAGS) $(OBJS:%.o=%.c) > .dependencies
>>  
>>  pciutils:
>>  	@echo; echo -n "Checking for pciutils and zlib... "
>>     

I have trouble parsing the reason for the hunk above. AFAICS this is a
change for better debugging only.

>> @@ -60,7 +62,7 @@
>>  		   echo "struct pci_access *pacc;";	   \
>>  		   echo "int main(int argc, char **argv)"; \
>>  		   echo "{ pacc = pci_alloc(); return 0; }"; ) > .test.c )
>> -	@$(CC) $(CFLAGS) .test.c -o .test $(LDFLAGS) &>/dev/null &&	\
>> +	@$(CC) $(CFLAGS) .test.c -o .test $(LDFLAGS) >/dev/null 2>&1 &&	\
>>  		echo "found." || ( echo "not found."; echo;		\
>>  		echo "Please install pciutils-devel and zlib-devel.";	\
>>  		echo "See README for more information."; echo;		\
>> Index: flash.h
>> ===================================================================
>> --- flash.h	(revision 3360)
>> +++ flash.h	(working copy)
>> @@ -41,6 +41,14 @@
>>    #define INW(x) __extension__ ({ u_int tmp = (x); inw(tmp); })
>>    #define INL(x) __extension__ ({ u_int tmp = (x); inl(tmp); })
>>  #else
>> +#ifdef	__sun
>> +  #define OUTB(x, y) outb(y, x)
>> +  #define OUTW(x, y) outw(y, x)
>> +  #define OUTL(x, y) outl(y, x)
>> +  #define INB  inb
>> +  #define INW  inw
>> +  #define INL  inl
>> +#else
>>    #define OUTB outb
>>    #define OUTW outw
>>    #define OUTL outl
>> @@ -48,6 +56,7 @@
>>    #define INW  inw
>>    #define INL  inl
>>  #endif
>> +#endif
>>  
>>  #define ARRAY_SIZE(a) (sizeof(a) / sizeof((a)[0]))
>>  
>>     

I'm contemplating whether we should use #elif here. It would surely make
the code more readable.

>> @@ -357,7 +366,7 @@
>>  
>>  /* udelay.c */
>>  void myusec_delay(int time);
>> -void myusec_calibrate_delay();
>> +void myusec_calibrate_delay(void);
>>  
>>  /* PCI handling for board/chipset_enable */
>>  struct pci_access *pacc;
>> @@ -406,12 +415,12 @@
>>  int probe_spi_rdid(struct flashchip *flash);
>>  int probe_spi_res(struct flashchip *flash);
>>  int spi_command(unsigned int writecnt, unsigned int readcnt, const unsigned char *writearr, unsigned char *readarr);
>> -void spi_write_enable();
>> -void spi_write_disable();
>> +void spi_write_enable(void);
>> +void spi_write_disable(void);
>>  int spi_chip_erase_c7(struct flashchip *flash);
>>  int spi_chip_write(struct flashchip *flash, uint8_t *buf);
>>  int spi_chip_read(struct flashchip *flash, uint8_t *buf);
>> -uint8_t spi_read_status_register();
>> +uint8_t spi_read_status_register(void);
>>  void spi_disable_blockprotect(void);
>>  void spi_byte_program(int address, uint8_t byte);
>>  void spi_page_program(int block, uint8_t *buf, uint8_t *bios);
>> @@ -450,6 +459,8 @@
>>  			     volatile uint8_t *dst);
>>  int probe_jedec(struct flashchip *flash);
>>  int erase_chip_jedec(struct flashchip *flash);
>> +int write_page_write_jedec(volatile uint8_t *bios, uint8_t *src,
>> +			   volatile uint8_t *dst, int page_size);
>>  int write_jedec(struct flashchip *flash, uint8_t *buf);
>>  int erase_sector_jedec(volatile uint8_t *bios, unsigned int page);
>>  int erase_block_jedec(volatile uint8_t *bios, unsigned int page);
>>     

Any reason for that write_page_write_jedec prototype?

>> Index: it87spi.c
>> ===================================================================
>> --- it87spi.c	(revision 3360)
>> +++ it87spi.c	(working copy)
>> @@ -26,6 +26,10 @@
>>  #include <pci/pci.h>
>>  #include <stdint.h>
>>  #include <string.h>
>> +/* for outb(),... */
>> +#if defined (__sun) && (defined(__i386) || defined(__amd64))
>> +#include <asm/sunddi.h>	/* XXX nonportable gcc/_KERNEL only, may disappear */
>> +#endif
>>  #include "flash.h"
>>  #include "spi.h"
>>  
>>     

Could you add the #include to flash.h instead?

>> Index: chipset_enable.c
>> ===================================================================
>> --- chipset_enable.c	(revision 3360)
>> +++ chipset_enable.c	(working copy)
>> @@ -33,6 +33,10 @@
>>  #include <sys/mman.h>
>>  #include <fcntl.h>
>>  #include <unistd.h>
>> +/* for outb(),... */
>> +#if defined (__sun) && (defined(__i386) || defined(__amd64))
>> +#include <asm/sunddi.h>	/* XXX nonportable gcc/_KERNEL only, may disappear */
>> +#endif
>>  #include "flash.h"
>>  
>>  static int enable_flash_ali_m1533(struct pci_dev *dev, const char *name)
>>     

Same here.

>> Index: flashrom.c
>> ===================================================================
>> --- flashrom.c	(revision 3360)
>> +++ flashrom.c	(working copy)
>> @@ -33,10 +33,9 @@
>>  #include <pci/pci.h>
>>  /* for iopl */
>>  #if defined (__sun) && (defined(__i386) || defined(__amd64))
>> -#include <strings.h>
>>  #include <sys/sysi86.h>
>>  #include <sys/psw.h>
>> -#include <asm/sunddi.h>
>> +#include <asm/sunddi.h>	/* XXX nonportable gcc/_KERNEL only, may disappear */
>>  #endif
>>  #include "flash.h"
>>  
>>     

Same here.

>> Index: board_enable.c
>> ===================================================================
>> --- board_enable.c	(revision 3360)
>> +++ board_enable.c	(working copy)
>> @@ -29,6 +29,10 @@
>>  #include <stdint.h>
>>  #include <string.h>
>>  #include <fcntl.h>
>> +/* for outb(),... */
>> +#if defined (__sun) && (defined(__i386) || defined(__amd64))
>> +#include <asm/sunddi.h>	/* XXX nonportable gcc/_KERNEL only, may disappear */
>> +#endif
>>  #include "flash.h"
>>  
>>  /*
>>     

And here.

Regards,
Carl-Daniel



From luja at openhardware.de  Fri Jun  6 15:08:53 2008
From: luja at openhardware.de (Ludwig Jaffe)
Date: Fri, 06 Jun 2008 15:08:53 +0200
Subject: [coreboot] flashrom and list of computers
In-Reply-To: <4848E2DC.3000801@bfs.de>
References: <48481E64.3000903@bfs.de> <484832E8.6030002@onelabs.com>
	<4848E2DC.3000801@bfs.de>
Message-ID: <484936E5.20208@openhardware.de>

Hi together!

Lets rewrite / improve flashrom!

I would like to see an universal function-pointer approach for the 
flash-dev handling, as I stated before in this mailing list.

For detection of flash the flash-identification according to the 
manufacturers can be used, so all functionpointers for the
detect-routines can be tried.

To detect the mainboard I would additionally suggest looking for strings 
in the bios (if original-bios is used). For Coreboot, I would suggest to
have a short text with manufacturer, board model, chipset, cpu so string 
search can find something.
Not to fall over all garbage the string search has to be filtered with 
known names as compaq, hp, ibm, asus, phoenix, award, and the like.

Using DMI is better for newer boards having DMI.

So one can build different strategies for identifiing the mainboard. And 
use a functionpointer approach to do special tasks for the boards
e.g. switching the bios to flash (some boards have a 2 bios-sockets)
e.g. unprotecting the boot-block.  (e.g. my compaq SFF PC needs P34 
soldered in and closed.) So an appropriate text has to be printed, if the
board can not automagically disable write-protection etc.
e.g. do other fancy stuff like unlocking the case.


Who is in charge for flashboot?
We should organize and manage the change-requests for that little piece 
of soft.


Kind Regards


LuJa



walter harms schrieb:
> bari wrote:
>   
>> walter harms wrote:
>>     
>>> hi list,
>>> after the nice flashrom demonstration on linuxtag in berlin.
>>> i have compiled flashrom and tested on several computer in the company.
>>> (simply using ./flashrom)
>>>
>>> Is there anyone interested in collecting these data ?
>>> Motherboard (Manufacturer) + flashrom result ?
>>>
>>>   
>>>       
>> Yes, post it here if you have the model numbers as well (with lspci
>> would be even better).
>>
>>     
>
> my idea was to use dmidecode that i can get informations like that:
>
> Handle 0x0100
>         DMI type 1, 25 bytes.
>         System Information
>                 Manufacturer: Dell Inc.
>                 Product Name: OptiPlex GX280
>                 Version: Not Specified
>
> Handle 0x0200
>         DMI type 2, 8 bytes.
>         Base Board Information
>                 Manufacturer: Dell Inc.
>                 Product Name: 0C7195
>                 Version:
>
> (Version is not filled, serial numbers removed)
>
> re,
>  wh
>
>   




From c-d.hailfinger.devel.2006 at gmx.net  Fri Jun  6 15:41:02 2008
From: c-d.hailfinger.devel.2006 at gmx.net (Carl-Daniel Hailfinger)
Date: Fri, 06 Jun 2008 15:41:02 +0200
Subject: [coreboot] flashrom and list of computers
In-Reply-To: <484936E5.20208@openhardware.de>
References: <48481E64.3000903@bfs.de>
	<484832E8.6030002@onelabs.com>	<4848E2DC.3000801@bfs.de>
	<484936E5.20208@openhardware.de>
Message-ID: <48493E6E.9040608@gmx.net>

On 06.06.2008 15:08, Ludwig Jaffe wrote:
> Lets rewrite / improve flashrom!
>   

A rewrite is unneccessary. Improvements are welcome.

> I would like to see an universal function-pointer approach for the 
> flash-dev handling, as I stated before in this mailing list.
>   

We already have that.

> For detection of flash the flash-identification according to the 
> manufacturers can be used, so all functionpointers for the
> detect-routines can be tried.
>   

We already do that.

> To detect the mainboard I would additionally suggest looking for strings 
> in the bios (if original-bios is used).

Sorry, that will not work reliably. We have some known false positives
and some known false negatives.

> For Coreboot, I would suggest to
> have a short text with manufacturer, board model, chipset, cpu so string 
> search can find something.
>   

We already have strings with board manufacturer+model. Chipset and CPU
strings do not make sense.

> Not to fall over all garbage the string search has to be filtered with 
> known names as compaq, hp, ibm, asus, phoenix, award, and the like.
>
> Using DMI is better for newer boards having DMI.
>   

Sorry, that will not work reliably. We have some known false positives
and some known false negatives.

> So one can build different strategies for identifiing the mainboard. And 
> use a functionpointer approach to do special tasks for the boards
> e.g. switching the bios to flash (some boards have a 2 bios-sockets)
>   

We already do that.

> e.g. unprotecting the boot-block.  (e.g. my compaq SFF PC needs P34 
> soldered in and closed.) So an appropriate text has to be printed, if the
> board can not automagically disable write-protection etc.
> e.g. do other fancy stuff like unlocking the case.
>   

We already can do that if anyone commits a text message.

> Who is in charge for flashboot?
>   

Do you mean flashrom? If so, your patches can be reviewed by the list.

> We should organize and manage the change-requests for that little piece 
> of soft.
>   

Please post patches. We can discuss them.


Regards,
Carl-Daniel



From c-d.hailfinger.devel.2006 at gmx.net  Fri Jun  6 15:48:52 2008
From: c-d.hailfinger.devel.2006 at gmx.net (Carl-Daniel Hailfinger)
Date: Fri, 06 Jun 2008 15:48:52 +0200
Subject: [coreboot] flashrom and list of computers
In-Reply-To: <4848E2DC.3000801@bfs.de>
References: <48481E64.3000903@bfs.de> <484832E8.6030002@onelabs.com>
	<4848E2DC.3000801@bfs.de>
Message-ID: <48494044.4020402@gmx.net>

Hi Walter,

On 06.06.2008 09:10, walter harms wrote:
> bari wrote:
>   
>> walter harms wrote:
>>     
>>> hi list,
>>> after the nice flashrom demonstration on linuxtag in berlin.
>>> i have compiled flashrom and tested on several computer in the company.
>>> (simply using ./flashrom)
>>>       

Great.

>>> Is there anyone interested in collecting these data ?
>>> Motherboard (Manufacturer) + flashrom result ?
>>>   
>>>       
>> Yes, post it here if you have the model numbers as well (with lspci
>> would be even better).
>>     
>
> my idea was to use dmidecode that i can get informations like that:
>
> Handle 0x0100
>         DMI type 1, 25 bytes.
>         System Information
>                 Manufacturer: Dell Inc.
>                 Product Name: OptiPlex GX280
>                 Version: Not Specified
>
> Handle 0x0200
>         DMI type 2, 8 bytes.
>         Base Board Information
>                 Manufacturer: Dell Inc.
>                 Product Name: 0C7195
>                 Version:
>
> (Version is not filled, serial numbers removed)
>   

Sometimes dmidecode also has information on BIOS size. Having that info
as well would be nice.
lspci -nnv (not a typo, I really want -nnv) would help a lot to estimate
testing coverage.

If there are machines where flashrom does not find a flash chip, please
run flashrom -V.


Regards,
Carl-Daniel



From wharms at bfs.de  Fri Jun  6 16:43:22 2008
From: wharms at bfs.de (walter harms)
Date: Fri, 06 Jun 2008 16:43:22 +0200
Subject: [coreboot] flashrom and list of computers
In-Reply-To: <48493E6E.9040608@gmx.net>
References: <48481E64.3000903@bfs.de>
	<484832E8.6030002@onelabs.com>	<4848E2DC.3000801@bfs.de>
	<484936E5.20208@openhardware.de> <48493E6E.9040608@gmx.net>
Message-ID: <48494D0A.5090404@bfs.de>

it is nice to see that so many people like the idea ... :)

back to basics. my suggestion was to have a list and perhaps a utility
that allows coreboot/flashrom to collect chip data from various box
in the hope to seek out easy targets and give the developers a new incentive.

I do not thing that the myriad PC boards need that much support. A very interessting
target could the std. desktop PC deployed by companies (DELL,HP, etc ..)
That would open a whole new area: a desktop PC that boots linux instandly.

Since journey starts with the first step and coreboot simply need a database about
deployed systems and there chipsets. To get many users as possible to submit data
a *simple* script is need that collect the informations and sends it directly to coreboot.org.

Next question: who will write that script ?

re
 wh



Carl-Daniel Hailfinger wrote:
> On 06.06.2008 15:08, Ludwig Jaffe wrote:
>> Lets rewrite / improve flashrom!
>>   
> 
> A rewrite is unneccessary. Improvements are welcome.
> 
>> I would like to see an universal function-pointer approach for the 
>> flash-dev handling, as I stated before in this mailing list.
>>   
> 
> We already have that.
> 
>> For detection of flash the flash-identification according to the 
>> manufacturers can be used, so all functionpointers for the
>> detect-routines can be tried.
>>   
> 
> We already do that.
> 
>> To detect the mainboard I would additionally suggest looking for strings 
>> in the bios (if original-bios is used).
> 
> Sorry, that will not work reliably. We have some known false positives
> and some known false negatives.
> 
>> For Coreboot, I would suggest to
>> have a short text with manufacturer, board model, chipset, cpu so string 
>> search can find something.
>>   
> 
> We already have strings with board manufacturer+model. Chipset and CPU
> strings do not make sense.
> 
>> Not to fall over all garbage the string search has to be filtered with 
>> known names as compaq, hp, ibm, asus, phoenix, award, and the like.
>>
>> Using DMI is better for newer boards having DMI.
>>   
> 
> Sorry, that will not work reliably. We have some known false positives
> and some known false negatives.
> 
>> So one can build different strategies for identifiing the mainboard. And 
>> use a functionpointer approach to do special tasks for the boards
>> e.g. switching the bios to flash (some boards have a 2 bios-sockets)
>>   
> 
> We already do that.
> 
>> e.g. unprotecting the boot-block.  (e.g. my compaq SFF PC needs P34 
>> soldered in and closed.) So an appropriate text has to be printed, if the
>> board can not automagically disable write-protection etc.
>> e.g. do other fancy stuff like unlocking the case.
>>   
> 
> We already can do that if anyone commits a text message.
> 
>> Who is in charge for flashboot?
>>   
> 
> Do you mean flashrom? If so, your patches can be reviewed by the list.
> 
>> We should organize and manage the change-requests for that little piece 
>> of soft.
>>   
> 
> Please post patches. We can discuss them.
> 
> 
> Regards,
> Carl-Daniel
> 
> 



From c-d.hailfinger.devel.2006 at gmx.net  Fri Jun  6 16:57:59 2008
From: c-d.hailfinger.devel.2006 at gmx.net (Carl-Daniel Hailfinger)
Date: Fri, 06 Jun 2008 16:57:59 +0200
Subject: [coreboot] flashrom and list of computers
In-Reply-To: <48494D0A.5090404@bfs.de>
References: <48481E64.3000903@bfs.de>
	<484832E8.6030002@onelabs.com>	<4848E2DC.3000801@bfs.de>
	<484936E5.20208@openhardware.de> <48493E6E.9040608@gmx.net>
	<48494D0A.5090404@bfs.de>
Message-ID: <48495077.30102@gmx.net>

On 06.06.2008 16:43, walter harms wrote:
> it is nice to see that so many people like the idea ... :)
>
> back to basics. my suggestion was to have a list and perhaps a utility
> that allows coreboot/flashrom to collect chip data from various box
> in the hope to seek out easy targets and give the developers a new incentive.
>   

We have two different problems:
- Not enough developers for coreboot. Having more system data in a
database will not help at all. We need more developers to complete
existing targets or create new ones.
- Not enough system data for flashrom. That's why we tell people to test
flashrom and report success/failure.


> I do not thing that the myriad PC boards need that much support. A very interessting
> target could the std. desktop PC deployed by companies (DELL,HP, etc ..)
> That would open a whole new area: a desktop PC that boots linux instandly.
>
> Since journey starts with the first step and coreboot simply need a database about
> deployed systems and there chipsets. To get many users as possible to submit data
> a *simple* script is need that collect the informations and sends it directly to coreboot.org.
>
> Next question: who will write that script ?
>   

I wrote such a script a few months ago and sent it to the list.

The best thing someone new to coreboot/flashrom can do easily is testing
flashrom everywhere. After that, the next step is to find a machine
supported by coreboot and install coreboot there. Entering real coreboot
development is difficult and comes later.

Regards,
Carl-Daniel



From wharms at bfs.de  Fri Jun  6 17:07:36 2008
From: wharms at bfs.de (walter harms)
Date: Fri, 06 Jun 2008 17:07:36 +0200
Subject: [coreboot] flashrom and list of computers
In-Reply-To: <48495077.30102@gmx.net>
References: <48481E64.3000903@bfs.de>
	<484832E8.6030002@onelabs.com>	<4848E2DC.3000801@bfs.de>
	<484936E5.20208@openhardware.de> <48493E6E.9040608@gmx.net>
	<48494D0A.5090404@bfs.de> <48495077.30102@gmx.net>
Message-ID: <484952B8.2040408@bfs.de>



Carl-Daniel Hailfinger wrote:

> 
>> I do not thing that the myriad PC boards need that much support. A very interessting
>> target could the std. desktop PC deployed by companies (DELL,HP, etc ..)
>> That would open a whole new area: a desktop PC that boots linux instandly.
>>
>> Since journey starts with the first step and coreboot simply need a database about
>> deployed systems and there chipsets. To get many users as possible to submit data
>> a *simple* script is need that collect the informations and sends it directly to coreboot.org.
>>
>> Next question: who will write that script ?
>>   
> 
> I wrote such a script a few months ago and sent it to the list.
> 

it should be available on coreboot.org/download or front page clearly visible !
it will clearly not help getting more people into
coreboot development but if you can add a chip that is used in 1000 desktops you
will certainly draw more attention than doing the same effort and reaching 10.
If it works than you can find that chip.
Even when you will never use the data collected by the script, so what ? it will waste only
a few more bytes on the coreboot.org server.

re,
 wh




From c-d.hailfinger.devel.2006 at gmx.net  Fri Jun  6 17:13:15 2008
From: c-d.hailfinger.devel.2006 at gmx.net (Carl-Daniel Hailfinger)
Date: Fri, 06 Jun 2008 17:13:15 +0200
Subject: [coreboot] flashrom and list of computers
In-Reply-To: <48494FF8.50309@bfs.de>
References: <48481E64.3000903@bfs.de> <484832E8.6030002@onelabs.com>
	<4848E2DC.3000801@bfs.de> <48494044.4020402@gmx.net>
	<48494FF8.50309@bfs.de>
Message-ID: <4849540B.6000708@gmx.net>

Hi,

does anybody have an idea what to do if ICH6 BIOS Lock is enabled and
BIOS Write is disabled? Removing the lock bit seems to fail according to
flashrom.

On 06.06.2008 16:55, walter harms wrote:
> Carl-Daniel Hailfinger wrote:
>   
>> On 06.06.2008 09:10, walter harms wrote:
>>     
>>> my idea was to use dmidecode that i can get informations like that:
>>>
>>> Handle 0x0100
>>>         DMI type 1, 25 bytes.
>>>         System Information
>>>                 Manufacturer: Dell Inc.
>>>                 Product Name: OptiPlex GX280
>>>                 Version: Not Specified
>>>
>>>   
>>>       
>> Sometimes dmidecode also has information on BIOS size. Having that info
>> as well would be nice.
>>     
>
> Handle 0x0000
>         DMI type 0, 20 bytes.
>         BIOS Information
>                 Vendor: Dell Inc.
>                 ROM Size: 512 kB
>
>   
>> If there are machines where flashrom does not find a flash chip, please
>> run flashrom -V.
>>
>>     
> attached
>   

Thanks.

Found chipset "Intel ICH6/ICH6R", enabling flash write...
BIOS Lock Enable: enabled, BIOS Write Enable: disabled, BIOS_CNTL is 0x2
tried to set 0xdc to 0x3 on Intel ICH6/ICH6R failed (WARNING ONLY)
FAILED!

Dell has locked the BIOS against writing. We try to unlock it, but we fail.

Does the BIOS have any settings like "BIOS/Flash write protection" or
something similar?

> note: please understand that i have no intention to run ./flashrom -w before i am totaly
> sure that i can revert that.
>   

OK. Good decision.

Regards,
Carl-Daniel



From bari at onelabs.com  Fri Jun  6 18:42:27 2008
From: bari at onelabs.com (bari)
Date: Fri, 06 Jun 2008 11:42:27 -0500
Subject: [coreboot] VIA Northbridge K8T890 and SiS Northbridge: SiS 761GX
Message-ID: <484968F3.2050302@onelabs.com>

Anyone know why the VIA Northbridge K8T890 in the SVN in the southbridge 
directory?

Why didn't the SiS 761GX make it into the SVN at all?

-Bari



From Marc.Jones at amd.com  Fri Jun  6 18:56:07 2008
From: Marc.Jones at amd.com (Marc Jones)
Date: Fri, 6 Jun 2008 10:56:07 -0600
Subject: [coreboot] VIA Northbridge K8T890 and SiS Northbridge: SiS 761GX
In-Reply-To: <484968F3.2050302@onelabs.com>
References: <484968F3.2050302@onelabs.com>
Message-ID: <48496C27.5070509@amd.com>

bari wrote:
> Anyone know why the VIA Northbridge K8T890 in the SVN in the southbridge 
> directory?
> 

Because it isn't really a northbridge. In an Intel system the 
northbridge contains the memory controller. So MC init code is in the 
northbridge directory. On AMD processors, the northbridge is integrated 
on in the CPU so you see CPU directories under the northbridge 
directory. The southbridge directory is used for chipsets like the 
K8T890 Hyptertransport tunnel with a PCIe bridge. Other examples of this 
are the AMD 8111/8131 and Broadcom 5780/5785.

Maybe we should consider renaming the directories to be more clear.
northbridge -> memorycontroller
southbridge -> chipsets


> Why didn't the SiS 761GX make it into the SVN at all?

No idea, can you bump that patch thread?

Marc

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




From c-d.hailfinger.devel.2006 at gmx.net  Fri Jun  6 19:38:18 2008
From: c-d.hailfinger.devel.2006 at gmx.net (Carl-Daniel Hailfinger)
Date: Fri, 06 Jun 2008 19:38:18 +0200
Subject: [coreboot] VIA Northbridge K8T890 and SiS Northbridge: SiS 761GX
In-Reply-To: <48496C27.5070509@amd.com>
References: <484968F3.2050302@onelabs.com> <48496C27.5070509@amd.com>
Message-ID: <4849760A.30505@gmx.net>

On 06.06.2008 18:56, Marc Jones wrote:
> bari wrote:
>   
>> Why didn't the SiS 761GX make it into the SVN at all?
>>     
>
> No idea, can you bump that patch thread?
>   

That's very strange, I thought I had seen a commit message for it.

Regards,
Carl-Daniel



From bari at onelabs.com  Fri Jun  6 20:21:10 2008
From: bari at onelabs.com (bari)
Date: Fri, 06 Jun 2008 13:21:10 -0500
Subject: [coreboot] VIA Northbridge K8T890 and SiS Northbridge: SiS 761GX
In-Reply-To: <48496C27.5070509@amd.com>
References: <484968F3.2050302@onelabs.com> <48496C27.5070509@amd.com>
Message-ID: <48498016.9080306@onelabs.com>

Marc Jones wrote:
>
> Maybe we should consider renaming the directories to be more clear.
> northbridge -> memorycontroller
> southbridge -> chipsets
And for more fun and confusion, single chip "chipsets" with integrated 
north-south bridges.

Such as the vx800 or cx700 that may make it to the public SVN one day

http://www.via.com.tw/en/products/chipsets/v-series/vx800/index.jsp

http://www.via.com.tw/en/products/chipsets/c-series/cx700m/index.jsp

-Bari



From luja at openhardware.de  Fri Jun  6 20:35:05 2008
From: luja at openhardware.de (Ludwig Jaffe)
Date: Fri, 06 Jun 2008 20:35:05 +0200
Subject: [coreboot] flashrom and list of computers
In-Reply-To: <48493E6E.9040608@gmx.net>
References: <48481E64.3000903@bfs.de>	<484832E8.6030002@onelabs.com>	<4848E2DC.3000801@bfs.de>	<484936E5.20208@openhardware.de>
	<48493E6E.9040608@gmx.net>
Message-ID: <48498359.3090502@openhardware.de>

Hi all!
> On 06.06.2008 15:08, Ludwig Jaffe wrote:
>   
>> Lets rewrite / improve flashrom!
>>   
>>     
>
> A rewrite is unneccessary. Improvements are welcome.
>   
Yes, but there are some issues that are not straight enough.
For example: write and erase  try themselves to unlock the flash.
This should be handled by a generic unlock() which is function-pointered 
for the device in charge.
Also with the method lock()
>   
>> I would like to see an universal function-pointer approach for the 
>> flash-dev handling, as I stated before in this mailing list.
>>   
>>     
>
> We already have that.
>
>   
>> For detection of flash the flash-identification according to the 
>> manufacturers can be used, so all functionpointers for the
>> detect-routines can be tried.
>>   
>>     
>
> We already do that.
>
>   
>> To detect the mainboard I would additionally suggest looking for strings 
>> in the bios (if original-bios is used).
>>     
>
> Sorry, that will not work reliably. We have some known false positives
> and some known false negatives.
>   
Ok, but if we have known positives, we can use it for them. If no known 
positive, we at least write "Could be" asus p2b.
Like tcp-fingerprinting with nmap -O, the users report a fingerprint and 
nmap -O knows cisco PIX or what the hell...

>   
>> For Coreboot, I would suggest to
>> have a short text with manufacturer, board model, chipset, cpu so string 
>> search can find something.
>>   
>>     
>
> We already have strings with board manufacturer+model. Chipset and CPU
> strings do not make sense.
>   
OK, If you think so.
>   
>> Not to fall over all garbage the string search has to be filtered with 
>> known names as compaq, hp, ibm, asus, phoenix, award, and the like.
>>
>> Using DMI is better for newer boards having DMI.
>>   
>>     
>
> Sorry, that will not work reliably. We have some known false positives
> and some known false negatives.
>
>   
As written above:
we can prompt "could be" + "Report if you know better".
>> So one can build different strategies for identifiing the mainboard. And 
>> use a functionpointer approach to do special tasks for the boards
>> e.g. switching the bios to flash (some boards have a 2 bios-sockets)
>>   
>>     
>
> We already do that.
>   
this should also be function-pointered :-)
>   
>> e.g. unprotecting the boot-block.  (e.g. my compaq SFF PC needs P34 
>> soldered in and closed.) So an appropriate text has to be printed, if the
>> board can not automagically disable write-protection etc.
>> e.g. do other fancy stuff like unlocking the case.
>>   
>>     
>
> We already can do that if anyone commits a text message.
>   
OK, I will do so.
How to check-out/check in stuff for flashrom? I would like to have a 
devel-account.
>   
>> Who is in charge for flashboot?
>>   
>>     
>
> Do you mean flashrom? If so, your patches can be reviewed by the list.
>
>   
Yes, beeing stupid I f*cked it up :-)
>> We should organize and manage the change-requests for that little piece 
>> of soft.
>>   
>>     
>
> Please post patches. We can discuss them.
>   
I posted a little bit some days ago for ST29F002 BNT/BT in my Compaq SFF 
PC 600MHZ. BX-Chipset
>
> Regards,
> Carl-Daniel
>
>   
Cheeres


Ludwig



From peter at stuge.se  Fri Jun  6 20:35:38 2008
From: peter at stuge.se (Peter Stuge)
Date: Fri, 6 Jun 2008 20:35:38 +0200
Subject: [coreboot] [patch][v2] cs5536 usb port4 configuration
In-Reply-To: <4846EB4A.3040602@amd.com>
References: <4846EB4A.3040602@amd.com>
Message-ID: <20080606183538.2796.qmail@stuge.se>

On Wed, Jun 04, 2008 at 01:21:46PM -0600, Marc Jones wrote:
> This patch uses byte pointer and the MMIO read and write functions.

Nice.


> +		writel(readl(bar + IPREG04) | USB_HCCPW_SET, bar + IPREG04);

..though I still prefer set and clear functions or macros over this.


//Peter



From coreboot at jens.kuehnel.org  Fri Jun  6 20:50:50 2008
From: coreboot at jens.kuehnel.org (Jens Kuehnel)
Date: Fri, 06 Jun 2008 20:50:50 +0200
Subject: [coreboot] Newbee patch for A49LF040A (Alix2c2) please have a look.
Message-ID: <4849870A.20908@jens.kuehnel.org>

Hi coreboot list,

I visited the coreboot/flashrom talk during linuxtag, and was really 
impressed how "easy" it is can help/to hack. My target is to let 
coreboot run on my alix2c2 (the one with only 2 network cards).
The advantage for me is, its similar to an existing target (not too 
hard), but far enough to learn something.

My first problem it that flashrom does not support my flashchip.
But I hope I can fix this. :-) Patch attached.

But before I break my flash. Is it possible to destroy the chip, by 
using the wrong method?

The chip is a AMIC A49LF040A. It look like a SST 49LF040 replacement, I 
found the IDs @ http://www.amictechnology.com/pdf/A49LF040A.pdf.

I have a "LPC.1A", which means I can recover from bad flashes. But I 
don't like to solder SMD.

Can someone with more experience look over it, before I test it? Thanks 
a lot!

Greetings from Frankfurt/M (Germany)

CU
Jens



diff -u flashrom/flashchips.c flashrom-jk/flashchips.c
--- flashrom/flashchips.c       2008-06-05 18:06:52.000000000 +0200
+++ flashrom-jk/flashchips.c    2008-06-06 20:31:53.000000000 +0200
@@ -44,6 +44,7 @@
         {"Atmel",       "AT49F002(N)",          ATMEL_ID, 
AT_49F002N,             256,    256,            TEST_UNTESTED, 
probe_jedec,            erase_chip_jedec,  write_jedec},
         {"Atmel",       "AT49F002(N)T",         ATMEL_ID, 
AT_49F002NT,            256,    256,            TEST_UNTESTED, 
probe_jedec,            erase_chip_jedec,  write_jedec},
         {"Atmel",       "AT25DF321",            ATMEL_ID, 
AT_25DF321,             4096,   256,            TEST_OK_PREW, 
probe_spi_rdid,         spi_chip_erase_c7, spi_chip_write,  spi_chip_read},
+       {"Amic Technology","A49LF040A",         AMIC_ID, 
AMIC_A49LF040A,         512,    4096,           TEST_UNTESTED, 
probe_jedec,            erase_49lf040,                  write_49lf040},
         {"Amic Technology","A25L40P",           AMIC_ID, 
AMIC_A25L40P,           512,    256,            TEST_UNTESTED, 
probe_spi_rdid,         spi_chip_erase_c7, spi_chip_write, spi_chip_read},
         {"EMST",        "F49B002UA",            EMST_ID, 
EMST_F49B002UA,         256,    4096,           TEST_UNTESTED, 
probe_jedec,            erase_chip_jedec,  write_49f002},
         {"EON",         "EN29F002(A)(N)B",      EON_ID, 
EN_29F002B,             256,    256,            TEST_UNTESTED, 
probe_jedec,            erase_chip_jedec,  write_jedec},
diff -u flashrom/flash.h flashrom-jk/flash.h
--- flashrom/flash.h    2008-06-05 18:06:52.000000000 +0200
+++ flashrom-jk/flash.h 2008-06-06 20:32:19.000000000 +0200
@@ -119,6 +119,7 @@
  #define AMIC_ID                        0x7F37  /* AMIC */
  #define AMIC_ID_NOPREFIX       0x37    /* AMIC */
  #define AMIC_A25L40P           0x2013
+#define AMIC_A49LF040A         0x379D

  #define ASD_ID                 0x25    /* ASD, not listed in JEP106W */
  #define ASD_AE49F2008          0x52



From stepan at coresystems.de  Fri Jun  6 21:08:39 2008
From: stepan at coresystems.de (Stefan Reinauer)
Date: Fri, 06 Jun 2008 21:08:39 +0200
Subject: [coreboot] flashrom and list of computers
In-Reply-To: <4849540B.6000708@gmx.net>
References: <48481E64.3000903@bfs.de>
	<484832E8.6030002@onelabs.com>	<4848E2DC.3000801@bfs.de>
	<48494044.4020402@gmx.net>	<48494FF8.50309@bfs.de>
	<4849540B.6000708@gmx.net>
Message-ID: <48498B37.7030801@coresystems.de>

Carl-Daniel Hailfinger wrote:
> Hi,
>
> does anybody have an idea what to do if ICH6 BIOS Lock is enabled and
> BIOS Write is disabled? Removing the lock bit seems to fail according to
> flashrom.
Yes, put a magic signature somewhere, go to S3 and wake up again.

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 peter at stuge.se  Fri Jun  6 21:10:49 2008
From: peter at stuge.se (Peter Stuge)
Date: Fri, 6 Jun 2008 21:10:49 +0200
Subject: [coreboot] superiotool: add dump support for Winbond (NSC)
	PC87427
In-Reply-To: <57947bf80805290746l1ec07954o90af1cb18ec3877a@mail.gmail.com>
References: <57947bf80805290746l1ec07954o90af1cb18ec3877a@mail.gmail.com>
Message-ID: <20080606191049.32661.qmail@stuge.se>

On Thu, May 29, 2008 at 10:46:33AM -0400, Tom Sylla wrote:
> Add dump support for Winbond (NSC) PC87427. Dumps available from real hardware.
> 
> Signed-off-by: Tom Sylla <tsylla at gmail.com>

Acked-by: Peter Stuge <peter at stuge.se>


> Index: nsc.c
> ===================================================================
> --- nsc.c	(revision 3358)
> +++ nsc.c	(working copy)
> @@ -408,6 +408,65 @@
>  		{EOT}}},
>  	{0xf2, "PC87427", {
>  		/* SRID[7..5] is marked as "not applicable for the PC87427". */
> +		{NOLDN, NULL,
> +			{0x10,0x12,0x13,0x1d,0x20,0x21,0x22,0x23,0x24,0x25,
> +			 0x26,0x27,0x28,0x29,0x2a,0x2b,0x2c,0x2d,0x2e,0x2f,
> +			 EOT},
> +			{0x00,0x00,0x00,0x00,0xf2,0x11,0xa0,MISC,MISC,MISC,
> +			 0x02,NANA,0x00,MISC,0x00,0x00,MISC,MISC,RSVD,RSVD,
> +			 EOT}},
> +		{0x0, "Floppy",
> +			{0x30,0x60,0x61,0x70,0x71,0x74,0x75,0xf0,0xf1,EOT},
> +			{0x00,0x03,0xf2,0x06,0x03,0x02,0x04,0x24,0x00,EOT}},
> +		{0x2, "COM2",
> +			{0x30,0x60,0x61,0x70,0x71,0x74,0x75,0xf0,EOT},
> +			{0x00,0x02,0xf8,0x03,0x03,0x04,0x04,0x02,EOT}},
> +		{0x3, "COM1",
> +			{0x30,0x60,0x61,0x70,0x71,0x74,0x75,0xf0,EOT},
> +			{0x00,0x03,0xf8,0x04,0x03,0x04,0x04,0x02,EOT}},
> +		{0x4, "System wake-up control (SWC)",
> +			{0x30,0x60,0x61,0x62,0x63,0x64,0x65,0x66,0x67,0x70,
> +			 0x71,0x74,0x75,EOT},
> +			{0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,
> +			 0x03,0x04,0x04,EOT}},
> +		{0x5, "Mouse",
> +			{0x30,0x70,0x71,0x74,0x75,EOT},
> +			{0x00,0x0c,0x02,0x04,0x04,EOT}},
> +		{0x6, "Keyboard",
> +			{0x30,0x60,0x61,0x62,0x63,0x70,0x71,0x74,0x75,0xf0,
> +			 EOT},
> +			{0x00,0x00,0x60,0x00,0x64,0x01,0x02,0x04,0x04,0x40,
> +			 EOT}},
> +		{0x7, "GPIO",
> +			{0x30,0x50,0x60,0x61,0x70,0x71,0x74,0x75,0xf0,0xf1,
> +			 0xf2,0xf3,0xf4,0xf5,0xf6,0xf7,0xf8,EOT},
> +			{0x00,0x00,0x00,0x00,0x00,0x03,0x04,0x04,0x00,MISC,
> +			 0x01,0x00,0x00,0x00,0x00,0x00,0x00,EOT}},
> +		{0x9, "Fan Monitor and Control (FMC)",
> +			{0x30,0x50,0x60,0x61,0x70,0x71,0x74,0x75,0xf0,0xf1,
> +			 EOT},
> +			{0x00,0x00,0x00,0x00,0x00,0x03,0x04,0x04,0x19,0x06,
> +			 EOT}},
> +		{0xa, "Watchdog timer (WDT)",
> +			{0x30,0x50,0x60,0x61,0x70,0x71,0x74,0x75,0xf0,EOT},
> +			{0x00,0x00,0x00,0x00,0x00,0x03,0x04,0x04,0x00,EOT}},
> +		{0xf, "X-Bus",
> +			{0x30,0x60,0x61,0x70,0x71,0x74,0x75,0xf0,0xf1,0xf2,
> +			 0xf3,0xf4,0xf5,0xf6,0xf7,0xf8,0xf9,0xfa,0xfb,0xfc,
> +			 0xfd,0xfe,0xff,EOT},
> +			{0x00,0x00,0x00,0x00,0x00,0x04,0x04,0x00,0x00,0x00,
> +			 0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,
> +			 0x00,0x80,0x10,EOT}},
> +		{0x10, "Real-time clock (RTC)",
> +			{0x30,0x60,0x61,0x62,0x63,0x70,0x71,0x74,0x75,0xf0,
> +			 0xf1,0xf2,0xf3,0xf6,0xf7,EOT},
> +			{0x00,0x00,0x70,0x00,0x72,0x08,0x00,0x04,0x04,0x00,
> +			 0x00,0x00,0x00,MISC,0x00,EOT}},
> +		{0x14, "Health Monitoring and Control (HMC)",
> +			{0x30,0x50,0x60,0x61,0x62,0x63,0x70,0x71,0x74,0x75,
> +			 0xf0,EOT},
> +			{0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x03,0x04,0x04,
> +			 0x05,EOT}},
>  		{EOT}}},
>  	{0xf3, "PC87373", {
>  		{EOT}}},
> Index: superiotool.h
> ===================================================================
> --- superiotool.h	(revision 3358)
> +++ superiotool.h	(working copy)
> @@ -51,7 +51,7 @@
>  #define NANA		-3		/* Not Available */
>  #define RSVD		-4		/* Reserved */
>  #define MISC		-5		/* Needs special comment in output */
> -#define MAXLDN		0x10		/* Biggest LDN */
> +#define MAXLDN		0x14		/* Biggest LDN */
>  #define LDNSIZE		(MAXLDN + 3)	/* Biggest LDN + 0 + NOLDN + EOT */
>  #define MAXNUMIDX	170		/* Maximum number of indexes */
>  #define IDXSIZE 	(MAXNUMIDX + 1)



From c-d.hailfinger.devel.2006 at gmx.net  Fri Jun  6 21:28:15 2008
From: c-d.hailfinger.devel.2006 at gmx.net (Carl-Daniel Hailfinger)
Date: Fri, 06 Jun 2008 21:28:15 +0200
Subject: [coreboot] Newbee patch for A49LF040A (Alix2c2) please have a
 look.
In-Reply-To: <4849870A.20908@jens.kuehnel.org>
References: <4849870A.20908@jens.kuehnel.org>
Message-ID: <48498FCF.8020404@gmx.net>

Hi Jens,

On 06.06.2008 20:50, Jens Kuehnel wrote:
> Hi coreboot list,
>
> I visited the coreboot/flashrom talk during linuxtag, and was really 
>   

I remember... you were the one who brought hardware to the workshop.

> impressed how "easy" it is can help/to hack. My target is to let 
> coreboot run on my alix2c2 (the one with only 2 network cards).
> The advantage for me is, its similar to an existing target (not too 
> hard), but far enough to learn something.
>   

That's great.

> My first problem it that flashrom does not support my flashchip.
> But I hope I can fix this. :-) Patch attached.
>   

Thanks for the patch. Unfortunately it seems your mailer wrapped the
patch. Thunderbird users either
- have to attach the patch or
- select HTML composition, then choose "Preformat", then paste the patch
and then send it and confirm converting the mail to plain text.

> But before I break my flash. Is it possible to destroy the chip, by 
> using the wrong method?
>   

In theory, this should not happen. In practice, old or extremely cheap
flash chips can have sticky bits after a few erase cycles. I think the
risk for your board is almost zero.

> The chip is a AMIC A49LF040A. It look like a SST 49LF040 replacement, I 
> found the IDs @ http://www.amictechnology.com/pdf/A49LF040A.pdf.
>
> I have a "LPC.1A", which means I can recover from bad flashes. But I 
> don't like to solder SMD.
>
> Can someone with more experience look over it, before I test it? Thanks 
> a lot!
>   

I'd like to do that, but the patch was so mangled that I had problems
reading it. It looks like you put vendor and device ID together in
AMIC_A49LF040A. The vendor ID you want is probably AMIC_ID_NOPREFIX.

> Greetings from Frankfurt/M (Germany)
>   

Greetings from Tuebingen (same country)

Regards,
Carl-Daniel



From c-d.hailfinger.devel.2006 at gmx.net  Fri Jun  6 21:36:47 2008
From: c-d.hailfinger.devel.2006 at gmx.net (Carl-Daniel Hailfinger)
Date: Fri, 06 Jun 2008 21:36:47 +0200
Subject: [coreboot] flashrom and list of computers
In-Reply-To: <48498B37.7030801@coresystems.de>
References: <48481E64.3000903@bfs.de>
	<484832E8.6030002@onelabs.com>	<4848E2DC.3000801@bfs.de>
	<48494044.4020402@gmx.net>	<48494FF8.50309@bfs.de>
	<4849540B.6000708@gmx.net> <48498B37.7030801@coresystems.de>
Message-ID: <484991CF.9000108@gmx.net>

On 06.06.2008 21:08, Stefan Reinauer wrote:
> Carl-Daniel Hailfinger wrote:
>   
>> Hi,
>>
>> does anybody have an idea what to do if ICH6 BIOS Lock is enabled and
>> BIOS Write is disabled? Removing the lock bit seems to fail according to
>> flashrom.
>>     
> Yes, put a magic signature somewhere, go to S3 and wake up again.
>   

Thanks. I'm not sure this applies to Dell machines as well, though,
because they use an in-BIOS flash updater which looks for a complete
BIOS image at a few predefined memory locations after every soft reboot.


Regards,
Carl-Daniel



From c-d.hailfinger.devel.2006 at gmx.net  Fri Jun  6 21:42:35 2008
From: c-d.hailfinger.devel.2006 at gmx.net (Carl-Daniel Hailfinger)
Date: Fri, 06 Jun 2008 21:42:35 +0200
Subject: [coreboot] flashrom and list of computers
In-Reply-To: <48498359.3090502@openhardware.de>
References: <48481E64.3000903@bfs.de>	<484832E8.6030002@onelabs.com>	<4848E2DC.3000801@bfs.de>	<484936E5.20208@openhardware.de>
	<48493E6E.9040608@gmx.net> <48498359.3090502@openhardware.de>
Message-ID: <4849932B.9090201@gmx.net>

On 06.06.2008 20:35, Ludwig Jaffe wrote:
> Hi all!
>> On 06.06.2008 15:08, Ludwig Jaffe wrote:
>>  
>>> Lets rewrite / improve flashrom!
>>>       
>>
>> A rewrite is unneccessary. Improvements are welcome.
>>   
> Yes, but there are some issues that are not straight enough.
> For example: write and erase  try themselves to unlock the flash.
> This should be handled by a generic unlock() which is
> function-pointered for the device in charge.

Agreed.

> Also with the method lock()

I think one function for lock/unlock is enough. It can take
"lock/unlock" as parameter.
 
>>> To detect the mainboard I would additionally suggest looking for
>>> strings in the bios (if original-bios is used).
>>>     
>>
>> Sorry, that will not work reliably. We have some known false positives
>> and some known false negatives.
>>   
> Ok, but if we have known positives, we can use it for them. If no
> known positive, we at least write "Could be" asus p2b.
> Like tcp-fingerprinting with nmap -O, the users report a fingerprint
> and nmap -O knows cisco PIX or what the hell...

PCI subsystem IDs are more reliable than random strings from memory. We
already use those in board_enable.
 
>>> For Coreboot, I would suggest to
>>> have a short text with manufacturer, board model, chipset, cpu so
>>> string search can find something.
>>>       
>>
>> We already have strings with board manufacturer+model. Chipset and CPU
>> strings do not make sense.
>>   
> OK, If you think so.

Chipset can be found by lspci, the CPU by /proc/cpuinfo. A coreboot
image can support multiple CPUs.
 
>>> Not to fall over all garbage the string search has to be filtered
>>> with known names as compaq, hp, ibm, asus, phoenix, award, and the
>>> like.
>>>
>>> Using DMI is better for newer boards having DMI.
>>>       
>>
>> Sorry, that will not work reliably. We have some known false positives
>> and some known false negatives.
>>
>>   
> As written above:
> we can prompt "could be" + "Report if you know better".

That does not help because we still have to write routines for every
special mainboard and then we can easily use PCI subsystem IDs.

>>> So one can build different strategies for identifiing the mainboard.
>>> And use a functionpointer approach to do special tasks for the boards
>>> e.g. switching the bios to flash (some boards have a 2 bios-sockets)
>>>       
>>
>> We already do that.
>>   
> this should also be function-pointered :-)

It is.
 
>>> e.g. unprotecting the boot-block.  (e.g. my compaq SFF PC needs P34
>>> soldered in and closed.) So an appropriate text has to be printed,
>>> if the
>>> board can not automagically disable write-protection etc.
>>> e.g. do other fancy stuff like unlocking the case.
>>>       
>>
>> We already can do that if anyone commits a text message.
>>   
> OK, I will do so.
> How to check-out/check in stuff for flashrom? I would like to have a
> devel-account.

Usually someone first sends a few patches, one of the longtime
developers commits them, and after some time the new person gets svn
commit access.

svn repo is at svn://coreboot.org/repos/trunk/util/flashrom

>>> We should organize and manage the change-requests for that little
>>> piece of soft.
>>>       
>>
>> Please post patches. We can discuss them.
>>   
> I posted a little bit some days ago for ST29F002 BNT/BT in my Compaq
> SFF PC 600MHZ. BX-Chipset

Yes, that patch is still under review AFAICS.

Regards,
Carl-Daniel



From ward at gnu.org  Fri Jun  6 21:48:40 2008
From: ward at gnu.org (Ward Vandewege)
Date: Fri, 6 Jun 2008 15:48:40 -0400
Subject: [coreboot] flashrom and list of computers
In-Reply-To: <4849932B.9090201@gmx.net>
References: <48481E64.3000903@bfs.de> <484832E8.6030002@onelabs.com>
	<4848E2DC.3000801@bfs.de> <484936E5.20208@openhardware.de>
	<48493E6E.9040608@gmx.net> <48498359.3090502@openhardware.de>
	<4849932B.9090201@gmx.net>
Message-ID: <20080606194840.GA22965@localdomain>

On Fri, Jun 06, 2008 at 09:42:35PM +0200, Carl-Daniel Hailfinger wrote:
> That does not help because we still have to write routines for every
> special mainboard and then we can easily use PCI subsystem IDs.

Sadly, not always. Look at the various geode boards out there, for instance -
a lot of them look very alike or even identical if you only look at PCI
subsystem IDs, but are in fact made by different vendors and/or different
models of the same vendor. Ask the artecgroup guys for their experience with
that :/

Thanks,
Ward.

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



From peter at stuge.se  Fri Jun  6 22:13:49 2008
From: peter at stuge.se (Peter Stuge)
Date: Fri, 6 Jun 2008 22:13:49 +0200
Subject: [coreboot] [PATCH][v3] Argument order in compiler options
In-Reply-To: <48455592.3010203@georgi-clan.de>
References: <48455592.3010203@georgi-clan.de>
Message-ID: <20080606201349.22552.qmail@stuge.se>

On Tue, Jun 03, 2008 at 04:30:42PM +0200, Patrick Georgi wrote:
> Signed-Off-By: Patrick Georgi <patrick at georgi-clan.de>

With the below question answered, this is:

Acked-by: Peter Stuge <peter at stuge.se>



> Index: util/kconfig/lxdialog/Makefile
> ===================================================================
> --- util/kconfig/lxdialog/Makefile	(revision 687)
> +++ util/kconfig/lxdialog/Makefile	(working copy)
> @@ -24,8 +24,8 @@
>  
>  $(obj)/util/kconfig/lxdialog/lxdialog: $(obj)/dochecklxdialog $(patsubst %,$(obj)/util/kconfig/lxdialog/%,$(lxdialog-objs))
>  	$(Q)printf "  HOSTCC  $(subst $(shell pwd)/,,$(@))\n"
> -	$(Q)$(HOSTCC) $(HOST_LOADLIBES) \
> -		$(patsubst %,$(obj)/util/kconfig/lxdialog/%,$(lxdialog-objs)) -o $@
> +	$(Q)$(HOSTCC) \
> +		$(patsubst %,$(obj)/util/kconfig/lxdialog/%,$(lxdialog-objs)) -o $@ $(HOST_LOADLIBES)

HOST_LOADLIB*E*S

Is that last E a typo?


> 
>  $(obj)/util/kconfig/lxdialog/%.o: $(src)/util/kconfig/lxdialog/%.c
>  	$(Q)mkdir -p $(obj)/util/kconfig/lxdialog/
> Index: util/kconfig/Makefile
> ===================================================================
> --- util/kconfig/Makefile	(revision 687)
> +++ util/kconfig/Makefile	(working copy)
> @@ -102,11 +102,11 @@
>  
>  $(obj)/util/kconfig/mconf: $(patsubst %,$(obj)/util/kconfig/%,$(mconf-objects))
>  	$(Q)printf "  HOSTCC  $(subst $(shell pwd)/,,$(@))\n"
> -	$(Q)$(HOSTCC) $(CURSESLIBS) $(INTLLIBS) -o $@ $^
> +	$(Q)$(HOSTCC) -o $@ $^ $(CURSESLIBS) $(INTLLIBS)
>  
>  $(obj)/util/kconfig/conf: $(patsubst %,$(obj)/util/kconfig/%,$(conf-objects))
>  	$(Q)printf "  HOSTCC  $(subst $(shell pwd)/,,$(@))\n"
> -	$(Q)$(HOSTCC) $(CURSESLIBS) -o $@ $^
> +	$(Q)$(HOSTCC) -o $@ $^ $(CURSESLIBS)
>  
>  $(obj)/util/kconfig/qconf: $(patsubst %,$(obj)/util/kconfig/%,$(qconf-objects))
>  	$(Q)printf "  HOSTCXX $(subst $(shell pwd)/,,$(@))\n"



From Marc.Jones at amd.com  Fri Jun  6 22:27:24 2008
From: Marc.Jones at amd.com (Marc Jones)
Date: Fri, 6 Jun 2008 14:27:24 -0600
Subject: [coreboot] [patch][v2] cs5536 usb port4 configuration - new v3
 patch
In-Reply-To: <48488447.8040004@gmx.net>
References: <4846EB4A.3040602@amd.com>	<13426df10806041719s550fc46er37ec243832d7d6e3@mail.gmail.com>
	<4848777C.5030607@amd.com> <48488447.8040004@gmx.net>
Message-ID: <48499DAC.2000609@amd.com>

Carl-Daniel Hailfinger wrote:

> Dumb question: Does this break strict aliasing in any way?

I don't think so. There are not two pointers (of different types) that 
refer to the same location in the scope.

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 Jun  6 22:28:31 2008
From: Marc.Jones at amd.com (Marc Jones)
Date: Fri, 6 Jun 2008 14:28:31 -0600
Subject: [coreboot] [patch][v2] cs5536 usb port4 configuration - new v3
 patch
In-Reply-To: <1f4f14e8f7b7bcb7b3c62ec6530f782a@kernel.crashing.org>
References: <4846EB4A.3040602@amd.com>	<13426df10806041719s550fc46er37ec243832d7d6e3@mail.gmail.com>
	<4848777C.5030607@amd.com> <48488447.8040004@gmx.net>
	<1f4f14e8f7b7bcb7b3c62ec6530f782a@kernel.crashing.org>
Message-ID: <48499DEF.6020800@amd.com>

Segher Boessenkool wrote:
>> Dumb question: Does this break strict aliasing in any way?
> 
> Show the code?  I'll do you an analysis.
> 
> 
> Segher
> 
> 

Here is the patch.

Marc


-- 
Marc Jones
Senior Firmware Engineer
(970) 226-9684 Office
mailto:Marc.Jones at amd.com
http://www.amd.com/embeddedprocessors
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: usb.patch
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20080606/3fe926ca/attachment.ksh>

From peter at stuge.se  Fri Jun  6 22:30:54 2008
From: peter at stuge.se (Peter Stuge)
Date: Fri, 6 Jun 2008 22:30:54 +0200
Subject: [coreboot] Problem with PLL
In-Reply-To: <8425A3CD-AD3E-400F-B9B4-2C48BFE7AC3A@saxnet.de>
References: <1F1F933B-FB37-44F6-AA77-AD8B4EF60BA6@saxnet.de>
	<484573B4.9050607@amd.com>
	<8425A3CD-AD3E-400F-B9B4-2C48BFE7AC3A@saxnet.de>
Message-ID: <20080606203054.4865.qmail@stuge.se>

On Wed, Jun 04, 2008 at 01:30:52PM +0200, Uwe Schwarz wrote:
> >If it fails in the reset you can try making the pll lock time
> >longer but I doubt that it will help.
> >msrGlcpSysRstpll.lo |= (0xFF << RSTPPL_LOWER_HOLD_COUNT_SHIFT);
> 
> and that did the trick.

What is this indicative of?

Some clock quality parameter?


//Peter



From svn at coreboot.org  Fri Jun  6 22:47:42 2008
From: svn at coreboot.org (svn at coreboot.org)
Date: Fri,  6 Jun 2008 22:47:42 +0200
Subject: [coreboot] r690 - in coreboot-v3/util/kconfig: . lxdialog
Message-ID: <mailman.1621.1355071330.16123.coreboot@coreboot.org>

Author: oxygene
Date: 2008-06-06 22:47:42 +0200 (Fri, 06 Jun 2008)
New Revision: 690

Modified:
   coreboot-v3/util/kconfig/Makefile
   coreboot-v3/util/kconfig/lxdialog/Makefile
Log:
Order libraries last on the command line when
building kconfig and lxdialog, so that their
content is used to resolve unknown symbols even
when they are static libraries.

Also fix HOST_LOADLIBS typo.

Signed-Off-By: Patrick Georgi <patrick at georgi-clan.de>
Acked-by: Peter Stuge <peter at stuge.se>



Modified: coreboot-v3/util/kconfig/Makefile
===================================================================
--- coreboot-v3/util/kconfig/Makefile	2008-06-04 14:36:35 UTC (rev 689)
+++ coreboot-v3/util/kconfig/Makefile	2008-06-06 20:47:42 UTC (rev 690)
@@ -102,11 +102,11 @@
 
 $(obj)/util/kconfig/mconf: $(patsubst %,$(obj)/util/kconfig/%,$(mconf-objects))
 	$(Q)printf "  HOSTCC  $(subst $(shell pwd)/,,$(@))\n"
-	$(Q)$(HOSTCC) $(CURSESLIBS) $(INTLLIBS) -o $@ $^
+	$(Q)$(HOSTCC) -o $@ $^ $(CURSESLIBS) $(INTLLIBS)
 
 $(obj)/util/kconfig/conf: $(patsubst %,$(obj)/util/kconfig/%,$(conf-objects))
 	$(Q)printf "  HOSTCC  $(subst $(shell pwd)/,,$(@))\n"
-	$(Q)$(HOSTCC) $(CURSESLIBS) -o $@ $^
+	$(Q)$(HOSTCC) -o $@ $^ $(CURSESLIBS)
 
 $(obj)/util/kconfig/qconf: $(patsubst %,$(obj)/util/kconfig/%,$(qconf-objects))
 	$(Q)printf "  HOSTCXX $(subst $(shell pwd)/,,$(@))\n"

Modified: coreboot-v3/util/kconfig/lxdialog/Makefile
===================================================================
--- coreboot-v3/util/kconfig/lxdialog/Makefile	2008-06-04 14:36:35 UTC (rev 689)
+++ coreboot-v3/util/kconfig/lxdialog/Makefile	2008-06-06 20:47:42 UTC (rev 690)
@@ -8,14 +8,14 @@
 # Use recursively expanded variables so we do not call gcc unless
 # we really need to do so. (Do not call gcc as part of make mrproper)
 HOST_EXTRACFLAGS = $(shell $(CONFIG_SHELL) $(check-lxdialog) -ccflags)
-HOST_LOADLIBES   = $(shell $(CONFIG_SHELL) $(check-lxdialog) -ldflags $(HOSTCC))
+HOST_LOADLIBS   = $(shell $(CONFIG_SHELL) $(check-lxdialog) -ldflags $(HOSTCC))
  
 HOST_EXTRACFLAGS += -DLOCALE 
 
 .PHONY: dochecklxdialog
 $(obj)/dochecklxdialog:
 	$(Q)printf "  CHECK   $(subst $(shell pwd)/,,$(@))\n"
-	$(Q)$(CONFIG_SHELL) $(check-lxdialog) -check $(HOSTCC) $(HOST_LOADLIBES)
+	$(Q)$(CONFIG_SHELL) $(check-lxdialog) -check $(HOSTCC) $(HOST_LOADLIBS)
 
 always		:= lxdialog dochecklxdialog
 
@@ -24,8 +24,8 @@
 
 $(obj)/util/kconfig/lxdialog/lxdialog: $(obj)/dochecklxdialog $(patsubst %,$(obj)/util/kconfig/lxdialog/%,$(lxdialog-objs))
 	$(Q)printf "  HOSTCC  $(subst $(shell pwd)/,,$(@))\n"
-	$(Q)$(HOSTCC) $(HOST_LOADLIBES) \
-		$(patsubst %,$(obj)/util/kconfig/lxdialog/%,$(lxdialog-objs)) -o $@
+	$(Q)$(HOSTCC) \
+		$(patsubst %,$(obj)/util/kconfig/lxdialog/%,$(lxdialog-objs)) -o $@ $(HOST_LOADLIBS)
 
 $(obj)/util/kconfig/lxdialog/%.o: $(src)/util/kconfig/lxdialog/%.c
 	$(Q)mkdir -p $(obj)/util/kconfig/lxdialog/




From patrick at georgi-clan.de  Fri Jun  6 22:48:32 2008
From: patrick at georgi-clan.de (Patrick Georgi)
Date: Fri, 06 Jun 2008 22:48:32 +0200
Subject: [coreboot] [PATCH][v3] Argument order in compiler options
In-Reply-To: <20080606201349.22552.qmail@stuge.se>
References: <48455592.3010203@georgi-clan.de>
	<20080606201349.22552.qmail@stuge.se>
Message-ID: <4849A2A0.3020601@georgi-clan.de>

Peter Stuge schrieb:
> With the below question answered, this is:
>
> Acked-by: Peter Stuge <peter at stuge.se>
>   
Thanks, r690.
> HOST_LOADLIB*E*S
>
> Is that last E a typo?
>   
I think so (and see nothing that indicates otherwise) - I opted for the 
minimal patch, but I suppose fixing it (if only to avoid this question 
the next time a change affects that variable) is more sensible.


Thanks,
Patrick



From patrick at georgi-clan.de  Fri Jun  6 23:01:06 2008
From: patrick at georgi-clan.de (Patrick Georgi)
Date: Fri, 06 Jun 2008 23:01:06 +0200
Subject: [coreboot] [PATCH][v3] read actual memory size in qemu-i386
Message-ID: <4849A592.2040501@georgi-clan.de>

Hi,

the attached patch makes the i440bx emulation read the cmos registers of 
the bochs/qemu emulation that carry RAM size information instead of 
assuming 128MB.

Regards,
Patrick
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: patch-20080605-1-dynamic-memsize-in-qemu
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20080606/64f5e4d9/attachment.ksh>

From peter at stuge.se  Fri Jun  6 23:08:21 2008
From: peter at stuge.se (Peter Stuge)
Date: Fri, 6 Jun 2008 23:08:21 +0200
Subject: [coreboot] [PATCH][v3] read actual memory size in qemu-i386
In-Reply-To: <4849A592.2040501@georgi-clan.de>
References: <4849A592.2040501@georgi-clan.de>
Message-ID: <20080606210821.3641.qmail@stuge.se>

On Fri, Jun 06, 2008 at 11:01:06PM +0200, Patrick Georgi wrote:
> Index: northbridge/intel/i440bxemulation/domain
> ===================================================================
> --- northbridge/intel/i440bxemulation/domain	(revision 689)
> +++ northbridge/intel/i440bxemulation/domain	(working copy)
> @@ -19,6 +19,5 @@
>   */
>  
>  {
> -	ramsize = "128";

Is this parameter now used anywhere else?


>  	device_operations = "i440bx_domain";
>  };
> Index: northbridge/intel/i440bxemulation/i440bx.c
> ===================================================================
> --- northbridge/intel/i440bxemulation/i440bx.c	(revision 689)
> +++ northbridge/intel/i440bxemulation/i440bx.c	(working copy)
> @@ -37,25 +37,40 @@
>   * such modified SOFTWARE should be clearly marked, so as not to confuse
>   * it with the version available from LANL.
>   */
> + /* dynamic qemu ram size detection
> +    Copyright 2008 Patrick Georgi <patrick at georgi-clan.de>
> +    Licensed under the terms of the GNU General Public License v2 or later
> + */

Maybe nicer to have the same style on all comments?


>  #include <types.h>
>  #include <console.h>
>  #include <device/device.h>
>  #include <device/pci.h>
>  #include <string.h>
> +#include <io.h>
>  #include "i440bx.h"
>  #include "statictree.h"
>  
>  /* Here are the ops for 440BX as a PCI domain. */
>  
> +static int inb_cmos(int port)
> +{
> +	outb(port, 0x70);
> +	return inb(0x71);
> +}
> +

Is this available somewhere else? Should it be?


>  static void pci_domain_set_resources(struct device *dev)
>  {
>  	struct device *mc_dev;
>  	u32 tolmk;		/* Top of low mem, Kbytes. */
>  	int idx;
> -	struct northbridge_intel_i440bxemulation_domain_config *device_configuration =
> -	    dev->device_configuration;
> -	tolmk = device_configuration->ramsize * 1024;
> +	/* read large mem memory descriptor
> +	   for <16 MB read the more detailed small mem descriptor
> +	   all values in kbytes */
> +	tolmk = ((inb_cmos(0x35)<<8) |inb_cmos(0x34)) * 64;
> +	if (tolmk <= 16 * 1024) {
> +		tolmk = (inb_cmos(0x31)<<8) |inb_cmos(0x30);
> +	}

I like this.


//Peter



From patrick at georgi-clan.de  Fri Jun  6 23:30:42 2008
From: patrick at georgi-clan.de (Patrick Georgi)
Date: Fri, 06 Jun 2008 23:30:42 +0200
Subject: [coreboot] [PATCH][v3] read actual memory size in qemu-i386
In-Reply-To: <20080606210821.3641.qmail@stuge.se>
References: <4849A592.2040501@georgi-clan.de>
	<20080606210821.3641.qmail@stuge.se>
Message-ID: <4849AC82.5040305@georgi-clan.de>

Peter Stuge schrieb:
> On Fri, Jun 06, 2008 at 11:01:06PM +0200, Patrick Georgi wrote:
>   
>> -	ramsize = "128";
>>     
> Is this parameter now used anywhere else?
>   
The only other reference for "ramsize" I find is doc/design/newboot.lyx, 
which was wrong on this already (I don't see any way to change that 
value via kconfig). Unfortunately I don't have lyx, and I fear that 
mangling that file into compliance by hand will only break it. How to go 
on there?
>
> Maybe nicer to have the same style on all comments?
>   
Sorry, you're right. I added myself to the top header (which I didn't 
see before). I'll post a new patch when the other open issues are resolved.
>> +static int inb_cmos(int port)
>> +{
>> +	outb(port, 0x70);
>> +	return inb(0x71);
>> +}
>> +
>>     
> Is this available somewhere else? Should it be?
>   
It seems to be an official interface that bochs/qemu adopted for their 
purpose (nvramtool uses these ports, too), but I can't see any other use 
in cbv3 except nvramtool, which is userland.
It could (together with a write operation) be provided for future use. 
It might even be combined with nvramtool (but that's a different layer: 
boot code vs. userland, so I don't feel good with that).

In my opinion, moving them (two functions, read/write) as static 
functions to a header would be the best option. It's only drawn in when 
necessary, it's probably inlined anyway, and if they get used more 
regularily, we can still consider moving them to a separate source file 
in lib/. I'd look if that header could be used both for boot code and 
userland code, but not if that involves too many hacks.


Thanks for the review,
Patrick



From stepan at coresystems.de  Sat Jun  7 00:24:58 2008
From: stepan at coresystems.de (Stefan Reinauer)
Date: Sat, 07 Jun 2008 00:24:58 +0200
Subject: [coreboot] flashrom and list of computers
In-Reply-To: <484991CF.9000108@gmx.net>
References: <48481E64.3000903@bfs.de>
	<484832E8.6030002@onelabs.com>	<4848E2DC.3000801@bfs.de>
	<48494044.4020402@gmx.net>	<48494FF8.50309@bfs.de>
	<4849540B.6000708@gmx.net> <48498B37.7030801@coresystems.de>
	<484991CF.9000108@gmx.net>
Message-ID: <4849B93A.1080809@coresystems.de>

Carl-Daniel Hailfinger wrote:
> On 06.06.2008 21:08, Stefan Reinauer wrote:
>   
>> Carl-Daniel Hailfinger wrote:
>>   
>>     
>>> Hi,
>>>
>>> does anybody have an idea what to do if ICH6 BIOS Lock is enabled and
>>> BIOS Write is disabled? Removing the lock bit seems to fail according to
>>> flashrom.
>>>     
>>>       
>> Yes, put a magic signature somewhere, go to S3 and wake up again.
>>   
>>     
>
> Thanks. I'm not sure this applies to Dell machines as well, though,
> because they use an in-BIOS flash updater which looks for a complete
> BIOS image at a few predefined memory locations after every soft reboot.
>   
The method is probably very similar, flashing is locked down by SMM
while in OS context. Not much you can do
(well, check whether the SMM handler is locked, too, and replace it, for
example)

-- 
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 --------------
An HTML attachment was scrubbed...
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20080607/23be494b/attachment.html>

From coreboot at jens.kuehnel.org  Sat Jun  7 00:39:22 2008
From: coreboot at jens.kuehnel.org (Jens Kuehnel)
Date: Sat, 07 Jun 2008 00:39:22 +0200
Subject: [coreboot] Newbee patch for A49LF040A (Alix2c2) please have a
 look.
In-Reply-To: <48498FCF.8020404@gmx.net>
References: <4849870A.20908@jens.kuehnel.org> <48498FCF.8020404@gmx.net>
Message-ID: <4849BC9A.20808@jens.kuehnel.org>

Carl-Daniel Hailfinger schrieb:
Hi,

> I remember... you were the one who brought hardware to the workshop.
Yep, thats me. :-)

>> My first problem it that flashrom does not support my flashchip.
>> But I hope I can fix this. :-) Patch attached.
>>   
> 
> Thanks for the patch. Unfortunately it seems your mailer wrapped the
> patch. Thunderbird users either
> - have to attach the patch or
Done


> In theory, this should not happen. In practice, old or extremely cheap
> flash chips can have sticky bits after a few erase cycles. I think the
> risk for your board is almost zero.
I thought so, but want to be sure.


> I'd like to do that, but the patch was so mangled that I had problems
> reading it. It looks like you put vendor and device ID together in
> AMIC_A49LF040A. The vendor ID you want is probably AMIC_ID_NOPREFIX.
OK, I changed that.

>> Greetings from Frankfurt/M (Germany)
> Greetings from Tuebingen (same country)

CU
Jens
-------------- next part --------------
A non-text attachment was scrubbed...
Name: A49LF040A.diff
Type: text/x-patch
Size: 1592 bytes
Desc: not available
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20080607/b9befd95/attachment.diff>

From c-d.hailfinger.devel.2006 at gmx.net  Sat Jun  7 01:55:50 2008
From: c-d.hailfinger.devel.2006 at gmx.net (Carl-Daniel Hailfinger)
Date: Sat, 07 Jun 2008 01:55:50 +0200
Subject: [coreboot] Newbee patch for A49LF040A (Alix2c2) please have a
 look.
In-Reply-To: <4849BC9A.20808@jens.kuehnel.org>
References: <4849870A.20908@jens.kuehnel.org> <48498FCF.8020404@gmx.net>
	<4849BC9A.20808@jens.kuehnel.org>
Message-ID: <4849CE86.60403@gmx.net>

Hi Jens,

On 07.06.2008 00:39, Jens Kuehnel wrote:
> Carl-Daniel Hailfinger schrieb:
>
>
>> I'd like to do that, but the patch was so mangled that I had problems
>> reading it. It looks like you put vendor and device ID together in
>> AMIC_A49LF040A. The vendor ID you want is probably AMIC_ID_NOPREFIX.
> OK, I changed that.

Looks really good.

The only remaining question is whether the erase and write functions
should be the generic JEDEC functions instead. I haven't tested that and
unfortunately I did not have time to read the spec yet.

Simply running "flashrom" with the patch should tell you whether the
chip detection works and it is absolutely harmless. We can postpone
testing erase and write until you have confirmed chip detection.

Also, could you please add a Signed-off-by statement to your patch?
Otherwise we can't commit it. See
http://www.coreboot.org/Development_Guidelines#Sign-off_Procedure for
details.

Regards,
Carl-Daniel



From rminnich at gmail.com  Sat Jun  7 03:27:37 2008
From: rminnich at gmail.com (ron minnich)
Date: Fri, 6 Jun 2008 18:27:37 -0700
Subject: [coreboot] [patch][v2] cs5536 usb port4 configuration - new v3
	patch
In-Reply-To: <48499DEF.6020800@amd.com>
References: <4846EB4A.3040602@amd.com>
	<13426df10806041719s550fc46er37ec243832d7d6e3@mail.gmail.com>
	<4848777C.5030607@amd.com> <48488447.8040004@gmx.net>
	<1f4f14e8f7b7bcb7b3c62ec6530f782a@kernel.crashing.org>
	<48499DEF.6020800@amd.com>
Message-ID: <13426df10806061827n79b7df6esd03018caa0200eb9@mail.gmail.com>

I'll try this as soon as I get home from travel.

maybe another week.

ron



From ward at gnu.org  Sat Jun  7 05:17:50 2008
From: ward at gnu.org (Ward Vandewege)
Date: Fri, 6 Jun 2008 23:17:50 -0400
Subject: [coreboot] Newbee patch for A49LF040A (Alix2c2) please have
	a	look.
In-Reply-To: <4849CE86.60403@gmx.net>
References: <4849870A.20908@jens.kuehnel.org> <48498FCF.8020404@gmx.net>
	<4849BC9A.20808@jens.kuehnel.org> <4849CE86.60403@gmx.net>
Message-ID: <20080607031750.GA17479@localdomain>

On Sat, Jun 07, 2008 at 01:55:50AM +0200, Carl-Daniel Hailfinger wrote:
> Hi Jens,
> 
> On 07.06.2008 00:39, Jens Kuehnel wrote:
> > Carl-Daniel Hailfinger schrieb:
> >
> >
> >> I'd like to do that, but the patch was so mangled that I had problems
> >> reading it. It looks like you put vendor and device ID together in
> >> AMIC_A49LF040A. The vendor ID you want is probably AMIC_ID_NOPREFIX.
> > OK, I changed that.
> 
> Looks really good.
> 
> The only remaining question is whether the erase and write functions
> should be the generic JEDEC functions instead. I haven't tested that and
> unfortunately I did not have time to read the spec yet.
> 
> Simply running "flashrom" with the patch should tell you whether the
> chip detection works and it is absolutely harmless. We can postpone
> testing erase and write until you have confirmed chip detection.

I'm testing on an ALIX.2c3, which has the same rom chip:

# ./flashrom 
Calibrating delay loop... OK.
No coreboot table found.
Found chipset "AMD CS5536", enabling flash write... OK.
Found chip "Amic Technology A49LF040A" (512 KB) at physical address
0xfff80000.
===
This flash part has status UNTESTED for operations: PROBE READ ERASE WRITE
Please email a report to flashrom at coreboot.org if any of the above operations
work correctly for you with this flash part. Please include the full output
from the program, including chipset found. Thank you for your help!
===
No operations were specified.

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

So that's good. But running it again flashrom no longer sees the chip!

# ./flashrom -v -r test.rom
Calibrating delay loop... OK.
No coreboot table found.
Found chipset "AMD CS5536", enabling flash write... OK.
No EEPROM/flash device found.

# ./flashrom 
Calibrating delay loop... OK.
No coreboot table found.
Found chipset "AMD CS5536", enabling flash write... OK.
No EEPROM/flash device found.

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

After a cold reboot, I can run flashrom again, and the image it reads out
looks like it could be correct:

# ./flashrom -v -r test.rom
Calibrating delay loop... OK.
No coreboot table found.
Found chipset "AMD CS5536", enabling flash write... OK.
Found chip "Amic Technology A49LF040A" (512 KB) at physical address
0xfff80000.
===
This flash part has status UNTESTED for operations: PROBE READ ERASE WRITE
Please email a report to flashrom at coreboot.org if any of the above operations
work correctly for you with this flash part. Please include the full output
from the program, including chipset found. Thank you for your help!
===
Reading Flash...done
Verifying flash... VERIFIED.          
littleredbox:/usr/src/flashrom3# v test.rom 
-rw-r--r-- 1 root src 524288 2008-06-06 23:15 test.rom

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

And then, no more:

# ./flashrom -v -r test2.rom
Calibrating delay loop... OK.
No coreboot table found.
Found chipset "AMD CS5536", enabling flash write... OK.
No EEPROM/flash device found.

Thanks,
Ward.

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



From c-d.hailfinger.devel.2006 at gmx.net  Sat Jun  7 05:37:05 2008
From: c-d.hailfinger.devel.2006 at gmx.net (Carl-Daniel Hailfinger)
Date: Sat, 07 Jun 2008 05:37:05 +0200
Subject: [coreboot] Newbee patch for A49LF040A (Alix2c2) please have a
 look.
In-Reply-To: <20080607031750.GA17479@localdomain>
References: <4849870A.20908@jens.kuehnel.org> <48498FCF.8020404@gmx.net>
	<4849BC9A.20808@jens.kuehnel.org> <4849CE86.60403@gmx.net>
	<20080607031750.GA17479@localdomain>
Message-ID: <484A0261.6010302@gmx.net>

On 07.06.2008 05:17, Ward Vandewege wrote:
> On Sat, Jun 07, 2008 at 01:55:50AM +0200, Carl-Daniel Hailfinger wrote:
>   
>> Hi Jens,
>>
>> On 07.06.2008 00:39, Jens Kuehnel wrote:
>>     
>>> Carl-Daniel Hailfinger schrieb:
>>>
>>>
>>>       
>>>> I'd like to do that, but the patch was so mangled that I had problems
>>>> reading it. It looks like you put vendor and device ID together in
>>>> AMIC_A49LF040A. The vendor ID you want is probably AMIC_ID_NOPREFIX.
>>>>         
>>> OK, I changed that.
>>>       
>> Looks really good.
>>
>> The only remaining question is whether the erase and write functions
>> should be the generic JEDEC functions instead. I haven't tested that and
>> unfortunately I did not have time to read the spec yet.
>>
>> Simply running "flashrom" with the patch should tell you whether the
>> chip detection works and it is absolutely harmless. We can postpone
>> testing erase and write until you have confirmed chip detection.
>>     
>
> I'm testing on an ALIX.2c3, which has the same rom chip:
>
> # ./flashrom 
> Calibrating delay loop... OK.
> No coreboot table found.
> Found chipset "AMD CS5536", enabling flash write... OK.
> Found chip "Amic Technology A49LF040A" (512 KB) at physical address
> 0xfff80000.
> ===
> This flash part has status UNTESTED for operations: PROBE READ ERASE WRITE
> Please email a report to flashrom at coreboot.org if any of the above operations
> work correctly for you with this flash part. Please include the full output
> from the program, including chipset found. Thank you for your help!
> ===
> No operations were specified.
>
> -----------------------------------------------------------------------------
>
> So that's good. But running it again flashrom no longer sees the chip!
>
> # ./flashrom -v -r test.rom
> Calibrating delay loop... OK.
> No coreboot table found.
> Found chipset "AMD CS5536", enabling flash write... OK.
> No EEPROM/flash device found.
>
> # ./flashrom 
> Calibrating delay loop... OK.
> No coreboot table found.
> Found chipset "AMD CS5536", enabling flash write... OK.
> No EEPROM/flash device found.
>
> -----------------------------------------------------------------------------
>
> After a cold reboot, I can run flashrom again, and the image it reads out
> looks like it could be correct:
>
> # ./flashrom -v -r test.rom
> Calibrating delay loop... OK.
> No coreboot table found.
> Found chipset "AMD CS5536", enabling flash write... OK.
> Found chip "Amic Technology A49LF040A" (512 KB) at physical address
> 0xfff80000.
> ===
> This flash part has status UNTESTED for operations: PROBE READ ERASE WRITE
> Please email a report to flashrom at coreboot.org if any of the above operations
> work correctly for you with this flash part. Please include the full output
> from the program, including chipset found. Thank you for your help!
> ===
> Reading Flash...done
> Verifying flash... VERIFIED.          
> littleredbox:/usr/src/flashrom3# v test.rom 
> -rw-r--r-- 1 root src 524288 2008-06-06 23:15 test.rom
>
> -----------------------------------------------------------------------------
>
> And then, no more:
>
> # ./flashrom -v -r test2.rom
> Calibrating delay loop... OK.
> No coreboot table found.
> Found chipset "AMD CS5536", enabling flash write... OK.
> No EEPROM/flash device found.
>   

I suspect one of the other probe functions is killing communication with
the chip. If that's not the case, maybe we don't leave ID mode correctly.

Can you try repeated
flashrom -c A49LF040A
(I forgot the exact chipname specification) after a cold boot?

Regards,
Carl-Daniel



From ward at gnu.org  Sat Jun  7 05:47:14 2008
From: ward at gnu.org (Ward Vandewege)
Date: Fri, 6 Jun 2008 23:47:14 -0400
Subject: [coreboot] Newbee patch for A49LF040A (Alix2c2) please have
	a	look.
In-Reply-To: <484A0261.6010302@gmx.net>
References: <4849870A.20908@jens.kuehnel.org> <48498FCF.8020404@gmx.net>
	<4849BC9A.20808@jens.kuehnel.org> <4849CE86.60403@gmx.net>
	<20080607031750.GA17479@localdomain> <484A0261.6010302@gmx.net>
Message-ID: <20080607034714.GA19574@localdomain>

On Sat, Jun 07, 2008 at 05:37:05AM +0200, Carl-Daniel Hailfinger wrote:
> I suspect one of the other probe functions is killing communication with
> the chip. If that's not the case, maybe we don't leave ID mode correctly.
> 
> Can you try repeated
> flashrom -c A49LF040A
> (I forgot the exact chipname specification) after a cold boot?

Yeah, that works:

littleredbox:/usr/src/flashrom3# ./flashrom -c A49LF040A
Calibrating delay loop... OK.
No coreboot table found.
Found chipset "AMD CS5536", enabling flash write... OK.
Found chip "Amic Technology A49LF040A" (512 KB) at physical address
0xfff80000.
===
This flash part has status UNTESTED for operations: PROBE READ ERASE WRITE
Please email a report to flashrom at coreboot.org if any of the above operations
work correctly for you with this flash part. Please include the full output
from the program, including chipset found. Thank you for your help!
===
No operations were specified.
littleredbox:/usr/src/flashrom3# ./flashrom -c A49LF040A
Calibrating delay loop... OK.
No coreboot table found.
Found chipset "AMD CS5536", enabling flash write... OK.
Found chip "Amic Technology A49LF040A" (512 KB) at physical address
0xfff80000.
===
This flash part has status UNTESTED for operations: PROBE READ ERASE WRITE
Please email a report to flashrom at coreboot.org if any of the above operations
work correctly for you with this flash part. Please include the full output
from the program, including chipset found. Thank you for your help!
===
No operations were specified.
littleredbox:/usr/src/flashrom3# ./flashrom -c A49LF040A
Calibrating delay loop... OK.
No coreboot table found.
Found chipset "AMD CS5536", enabling flash write... OK.
Found chip "Amic Technology A49LF040A" (512 KB) at physical address
0xfff80000.
===
This flash part has status UNTESTED for operations: PROBE READ ERASE WRITE
Please email a report to flashrom at coreboot.org if any of the above operations
work correctly for you with this flash part. Please include the full output
from the program, including chipset found. Thank you for your help!
===
No operations were specified.
littleredbox:/usr/src/flashrom3# ./flashrom -c A49LF040A
Calibrating delay loop... OK.
No coreboot table found.
Found chipset "AMD CS5536", enabling flash write... OK.
Found chip "Amic Technology A49LF040A" (512 KB) at physical address
0xfff80000.
===
This flash part has status UNTESTED for operations: PROBE READ ERASE WRITE
Please email a report to flashrom at coreboot.org if any of the above operations
work correctly for you with this flash part. Please include the full output
from the program, including chipset found. Thank you for your help!
===
No operations were specified.
littleredbox:/usr/src/flashrom3# ./flashrom -c A49LF040A -r test.rom
Calibrating delay loop... OK.
No coreboot table found.
Found chipset "AMD CS5536", enabling flash write... OK.
Found chip "Amic Technology A49LF040A" (512 KB) at physical address
0xfff80000.
===
This flash part has status UNTESTED for operations: PROBE READ ERASE WRITE
Please email a report to flashrom at coreboot.org if any of the above operations
work correctly for you with this flash part. Please include the full output
from the program, including chipset found. Thank you for your help!
===
Reading Flash...done
littleredbox:/usr/src/flashrom3# ./flashrom -c A49LF040A -r test2.rom
Calibrating delay loop... OK.
No coreboot table found.
Found chipset "AMD CS5536", enabling flash write... OK.
Found chip "Amic Technology A49LF040A" (512 KB) at physical address
0xfff80000.
===
This flash part has status UNTESTED for operations: PROBE READ ERASE WRITE
Please email a report to flashrom at coreboot.org if any of the above operations
work correctly for you with this flash part. Please include the full output
from the program, including chipset found. Thank you for your help!
===
Reading Flash...done
littleredbox:/usr/src/flashrom3# ./flashrom -c A49LF040A -r test2.rom -V
Calibrating delay loop... 108M loops per second. OK.
No coreboot table found.
Found chipset "AMD CS5536", enabling flash write... OK.
Probing for Amic Technology A49LF040A, 512 KB: probe_jedec: id1 0x37, id2
0x9d
Found chip "Amic Technology A49LF040A" (512 KB) at physical address
0xfff80000.
===
This flash part has status UNTESTED for operations: PROBE READ ERASE WRITE
Please email a report to flashrom at coreboot.org if any of the above operations
work correctly for you with this flash part. Please include the full output
from the program, including chipset found. Thank you for your help!
===
Reading Flash...done
littleredbox:/usr/src/flashrom3# ./flashrom -c A49LF040A -r test2.rom -v
Calibrating delay loop... OK.
No coreboot table found.
Found chipset "AMD CS5536", enabling flash write... OK.
Found chip "Amic Technology A49LF040A" (512 KB) at physical address
0xfff80000.
===
This flash part has status UNTESTED for operations: PROBE READ ERASE WRITE
Please email a report to flashrom at coreboot.org if any of the above operations
work correctly for you with this flash part. Please include the full output
from the program, including chipset found. Thank you for your help!
===
Reading Flash...done
Verifying flash... VERIFIED.          


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



From coreboot at jens.kuehnel.org  Sat Jun  7 06:57:05 2008
From: coreboot at jens.kuehnel.org (Jens Kuehnel)
Date: Sat, 07 Jun 2008 06:57:05 +0200
Subject: [coreboot] [PATCH] Newbee patch for A49LF040A (Alix2c2) please
 have a look.
In-Reply-To: <4849CE86.60403@gmx.net>
References: <4849870A.20908@jens.kuehnel.org>
	<48498FCF.8020404@gmx.net>	<4849BC9A.20808@jens.kuehnel.org>
	<4849CE86.60403@gmx.net>
Message-ID: <484A1521.101@jens.kuehnel.org>

Carl-Daniel Hailfinger schrieb:
> Hi Jens,

Here the patch, I will play around with generic JEDEC and detection 
tomorrow.

CU
Jens
---

Signed-Off-By: Jens Kuehnel <coreboot at jens.kuehnel.org>

-------------- next part --------------
A non-text attachment was scrubbed...
Name: A49LF040A.patch
Type: text/x-patch
Size: 1539 bytes
Desc: not available
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20080607/d2d63ec9/attachment.patch>

From avg at icyb.net.ua  Sat Jun  7 11:58:31 2008
From: avg at icyb.net.ua (Andriy Gapon)
Date: Sat, 07 Jun 2008 12:58:31 +0300
Subject: [coreboot] [flashrom] layout.c: couple of nitpicks
Message-ID: <484A5BC7.5040509@icyb.net.ua>


It seems that in show_id() type of 'walk' variable should of fixed size 
(i.e. uint32_t) for x86_64 portability.

Also, it looks suspicious that two legacy bios checks (nvidia and 
general) are exactly the same:
if ((*walk) == 0 || ((*walk) & 0x3ff) != 0) {
         /* We might have an Nvidia chipset bios
...
}

if ((*walk) == 0 || ((*walk) & 0x3ff) != 0) {
         printf("Flash image seems to be a legacy BIOS. Disabling 
checks.\n");
...
-- 
Andriy Gapon



From svn at coreboot.org  Sat Jun  7 13:36:30 2008
From: svn at coreboot.org (svn at coreboot.org)
Date: Sat,  7 Jun 2008 13:36:30 +0200
Subject: [coreboot] r3361 - trunk/util/superiotool
Message-ID: <mailman.1622.1355071331.16123.coreboot@coreboot.org>

Author: stuge
Date: 2008-06-07 13:36:30 +0200 (Sat, 07 Jun 2008)
New Revision: 3361

Modified:
   trunk/util/superiotool/nsc.c
   trunk/util/superiotool/superiotool.h
Log:
Add dump support for Winbond (NSC) PC87427. Dumps available from real hardware.

Signed-off-by: Tom Sylla <tsylla at gmail.com>
Acked-by: Peter Stuge <peter at stuge.se>


Modified: trunk/util/superiotool/nsc.c
===================================================================
--- trunk/util/superiotool/nsc.c	2008-06-03 00:22:00 UTC (rev 3360)
+++ trunk/util/superiotool/nsc.c	2008-06-07 11:36:30 UTC (rev 3361)
@@ -408,6 +408,65 @@
 		{EOT}}},
 	{0xf2, "PC87427", {
 		/* SRID[7..5] is marked as "not applicable for the PC87427". */
+		{NOLDN, NULL,
+			{0x10,0x12,0x13,0x1d,0x20,0x21,0x22,0x23,0x24,0x25,
+			 0x26,0x27,0x28,0x29,0x2a,0x2b,0x2c,0x2d,0x2e,0x2f,
+			 EOT},
+			{0x00,0x00,0x00,0x00,0xf2,0x11,0xa0,MISC,MISC,MISC,
+			 0x02,NANA,0x00,MISC,0x00,0x00,MISC,MISC,RSVD,RSVD,
+			 EOT}},
+		{0x0, "Floppy",
+			{0x30,0x60,0x61,0x70,0x71,0x74,0x75,0xf0,0xf1,EOT},
+			{0x00,0x03,0xf2,0x06,0x03,0x02,0x04,0x24,0x00,EOT}},
+		{0x2, "COM2",
+			{0x30,0x60,0x61,0x70,0x71,0x74,0x75,0xf0,EOT},
+			{0x00,0x02,0xf8,0x03,0x03,0x04,0x04,0x02,EOT}},
+		{0x3, "COM1",
+			{0x30,0x60,0x61,0x70,0x71,0x74,0x75,0xf0,EOT},
+			{0x00,0x03,0xf8,0x04,0x03,0x04,0x04,0x02,EOT}},
+		{0x4, "System wake-up control (SWC)",
+			{0x30,0x60,0x61,0x62,0x63,0x64,0x65,0x66,0x67,0x70,
+			 0x71,0x74,0x75,EOT},
+			{0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,
+			 0x03,0x04,0x04,EOT}},
+		{0x5, "Mouse",
+			{0x30,0x70,0x71,0x74,0x75,EOT},
+			{0x00,0x0c,0x02,0x04,0x04,EOT}},
+		{0x6, "Keyboard",
+			{0x30,0x60,0x61,0x62,0x63,0x70,0x71,0x74,0x75,0xf0,
+			 EOT},
+			{0x00,0x00,0x60,0x00,0x64,0x01,0x02,0x04,0x04,0x40,
+			 EOT}},
+		{0x7, "GPIO",
+			{0x30,0x50,0x60,0x61,0x70,0x71,0x74,0x75,0xf0,0xf1,
+			 0xf2,0xf3,0xf4,0xf5,0xf6,0xf7,0xf8,EOT},
+			{0x00,0x00,0x00,0x00,0x00,0x03,0x04,0x04,0x00,MISC,
+			 0x01,0x00,0x00,0x00,0x00,0x00,0x00,EOT}},
+		{0x9, "Fan Monitor and Control (FMC)",
+			{0x30,0x50,0x60,0x61,0x70,0x71,0x74,0x75,0xf0,0xf1,
+			 EOT},
+			{0x00,0x00,0x00,0x00,0x00,0x03,0x04,0x04,0x19,0x06,
+			 EOT}},
+		{0xa, "Watchdog timer (WDT)",
+			{0x30,0x50,0x60,0x61,0x70,0x71,0x74,0x75,0xf0,EOT},
+			{0x00,0x00,0x00,0x00,0x00,0x03,0x04,0x04,0x00,EOT}},
+		{0xf, "X-Bus",
+			{0x30,0x60,0x61,0x70,0x71,0x74,0x75,0xf0,0xf1,0xf2,
+			 0xf3,0xf4,0xf5,0xf6,0xf7,0xf8,0xf9,0xfa,0xfb,0xfc,
+			 0xfd,0xfe,0xff,EOT},
+			{0x00,0x00,0x00,0x00,0x00,0x04,0x04,0x00,0x00,0x00,
+			 0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,
+			 0x00,0x80,0x10,EOT}},
+		{0x10, "Real-time clock (RTC)",
+			{0x30,0x60,0x61,0x62,0x63,0x70,0x71,0x74,0x75,0xf0,
+			 0xf1,0xf2,0xf3,0xf6,0xf7,EOT},
+			{0x00,0x00,0x70,0x00,0x72,0x08,0x00,0x04,0x04,0x00,
+			 0x00,0x00,0x00,MISC,0x00,EOT}},
+		{0x14, "Health Monitoring and Control (HMC)",
+			{0x30,0x50,0x60,0x61,0x62,0x63,0x70,0x71,0x74,0x75,
+			 0xf0,EOT},
+			{0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x03,0x04,0x04,
+			 0x05,EOT}},
 		{EOT}}},
 	{0xf3, "PC87373", {
 		{EOT}}},

Modified: trunk/util/superiotool/superiotool.h
===================================================================
--- trunk/util/superiotool/superiotool.h	2008-06-03 00:22:00 UTC (rev 3360)
+++ trunk/util/superiotool/superiotool.h	2008-06-07 11:36:30 UTC (rev 3361)
@@ -51,7 +51,7 @@
 #define NANA		-3		/* Not Available */
 #define RSVD		-4		/* Reserved */
 #define MISC		-5		/* Needs special comment in output */
-#define MAXLDN		0x10		/* Biggest LDN */
+#define MAXLDN		0x14		/* Biggest LDN */
 #define LDNSIZE		(MAXLDN + 3)	/* Biggest LDN + 0 + NOLDN + EOT */
 #define MAXNUMIDX	170		/* Maximum number of indexes */
 #define IDXSIZE 	(MAXNUMIDX + 1)




From peter at stuge.se  Sat Jun  7 13:36:55 2008
From: peter at stuge.se (Peter Stuge)
Date: Sat, 7 Jun 2008 13:36:55 +0200
Subject: [coreboot] superiotool: add dump support for Winbond (NSC)
	PC87427
In-Reply-To: <20080606191049.32661.qmail@stuge.se>
References: <57947bf80805290746l1ec07954o90af1cb18ec3877a@mail.gmail.com>
	<20080606191049.32661.qmail@stuge.se>
Message-ID: <20080607113655.19386.qmail@stuge.se>

On Fri, Jun 06, 2008 at 09:10:49PM +0200, Peter Stuge wrote:
> On Thu, May 29, 2008 at 10:46:33AM -0400, Tom Sylla wrote:
> > Add dump support for Winbond (NSC) PC87427. Dumps available from real hardware.
> > 
> > Signed-off-by: Tom Sylla <tsylla at gmail.com>
> 
> Acked-by: Peter Stuge <peter at stuge.se>

r3361



From c-d.hailfinger.devel.2006 at gmx.net  Sat Jun  7 13:40:39 2008
From: c-d.hailfinger.devel.2006 at gmx.net (Carl-Daniel Hailfinger)
Date: Sat, 07 Jun 2008 13:40:39 +0200
Subject: [coreboot] Newbee patch for A49LF040A (Alix2c2) please have	a
 look.
In-Reply-To: <20080607034714.GA19574@localdomain>
References: <4849870A.20908@jens.kuehnel.org>
	<48498FCF.8020404@gmx.net>	<4849BC9A.20808@jens.kuehnel.org>
	<4849CE86.60403@gmx.net>	<20080607031750.GA17479@localdomain>
	<484A0261.6010302@gmx.net> <20080607034714.GA19574@localdomain>
Message-ID: <484A73B7.4030609@gmx.net>

On 07.06.2008 05:47, Ward Vandewege wrote:
> On Sat, Jun 07, 2008 at 05:37:05AM +0200, Carl-Daniel Hailfinger wrote:
>   
>> I suspect one of the other probe functions is killing communication with
>> the chip. If that's not the case, maybe we don't leave ID mode correctly.
>>
>> Can you try repeated
>> flashrom -c A49LF040A
>> (I forgot the exact chipname specification) after a cold boot?
>>     
>
> Yeah, that works:
>
> littleredbox:/usr/src/flashrom3# ./flashrom -c A49LF040A
> [...]
> Found chip "Amic Technology A49LF040A" (512 KB) at physical address
> 0xfff80000.
> [...]
> No operations were specified.
> littleredbox:/usr/src/flashrom3# ./flashrom -c A49LF040A
> [...]
> Found chip "Amic Technology A49LF040A" (512 KB) at physical address
> 0xfff80000.
> [...]
> No operations were specified.
> littleredbox:/usr/src/flashrom3# ./flashrom -c A49LF040A
> [...]
> Found chip "Amic Technology A49LF040A" (512 KB) at physical address
> 0xfff80000.
> [...]
> No operations were specified.
>   

Ouch. So one of the other probe functions kills communication. Can one
of you try disabling other chip definitions in flashchips.c with #if 0
to narrow this problem down?

Regards,
Carl-Daniel



From info at coresystems.de  Sat Jun  7 14:11:31 2008
From: info at coresystems.de (coreboot information)
Date: Sat, 07 Jun 2008 14:11:31 +0200
Subject: [coreboot] r3361 build service
Message-ID: <E1K4xGd-0008Bk-HH@khepri.openbios.org>

Dear coreboot readers!

This is the automated build check service of coreboot.

The developer "stuge" checked in revision 3361 to
the coreboot source repository and caused the following 
changes:

Change Log:
Add dump support for Winbond (NSC) PC87427. Dumps available from real hardware.

Signed-off-by: Tom Sylla <tsylla at gmail.com>
Acked-by: Peter Stuge <peter at stuge.se>


Build Log:
Compilation of via:epia-cn is still broken
See the error log at http://qa.coreboot.org/log_buildbrd.php?revision=3361&device=epia-cn&vendor=via


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

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

   Best regards,
     coreboot automatic build system





From svn at coreboot.org  Sat Jun  7 14:35:11 2008
From: svn at coreboot.org (svn at coreboot.org)
Date: Sat,  7 Jun 2008 14:35:11 +0200
Subject: [coreboot] r3362 - trunk/coreboot-v2/targets/via/epia-cn
Message-ID: <mailman.1623.1355071331.16123.coreboot@coreboot.org>

Author: stepan
Date: 2008-06-07 14:35:11 +0200 (Sat, 07 Jun 2008)
New Revision: 3362

Added:
   trunk/coreboot-v2/targets/via/epia-cn/Config-abuild.lb
Log:
fix via epia cn abuild.

Signed-off-by: Stefan Reinauer <stepan at coresystems.de>
Acked-by: Stefan Reinauer <stepan at coresystems.de>


Added: trunk/coreboot-v2/targets/via/epia-cn/Config-abuild.lb
===================================================================
--- trunk/coreboot-v2/targets/via/epia-cn/Config-abuild.lb	                        (rev 0)
+++ trunk/coreboot-v2/targets/via/epia-cn/Config-abuild.lb	2008-06-07 12:35:11 UTC (rev 3362)
@@ -0,0 +1,20 @@
+# This will make a target directory of ./VENDOR_MAINBOARD
+
+target VENDOR_MAINBOARD
+mainboard VENDOR/MAINBOARD
+
+option CC="CROSSCC"
+option CROSS_COMPILE="CROSS_PREFIX"
+option HOSTCC="CROSS_HOSTCC"
+
+__COMPRESSION__
+
+option ROM_SIZE=512*1024
+
+romimage "fallback" 
+	option USE_FALLBACK_IMAGE=1
+	option ROM_IMAGE_SIZE=0x20000
+	option COREBOOT_EXTRA_VERSION=".0-fallback"
+	payload __PAYLOAD__
+end
+buildrom ./coreboot.rom ROM_SIZE "fallback"




From ward at gnu.org  Sat Jun  7 15:00:52 2008
From: ward at gnu.org (Ward Vandewege)
Date: Sat, 7 Jun 2008 09:00:52 -0400
Subject: [coreboot] Newbee patch for A49LF040A (Alix2c2) please have
	a	look.
In-Reply-To: <484A73B7.4030609@gmx.net>
References: <4849870A.20908@jens.kuehnel.org> <48498FCF.8020404@gmx.net>
	<4849BC9A.20808@jens.kuehnel.org> <4849CE86.60403@gmx.net>
	<20080607031750.GA17479@localdomain> <484A0261.6010302@gmx.net>
	<20080607034714.GA19574@localdomain> <484A73B7.4030609@gmx.net>
Message-ID: <20080607130052.GA22883@localdomain>

On Sat, Jun 07, 2008 at 01:40:39PM +0200, Carl-Daniel Hailfinger wrote:
> Ouch. So one of the other probe functions kills communication. Can one
> of you try disabling other chip definitions in flashchips.c with #if 0
> to narrow this problem down?

This is the culprit:

  {"Winbond", "W29EE011",   WINBOND_ID, W_29C011,   128,  128,
TEST_OK_PREW, probe_w29ee011,   erase_chip_jedec,   write_jedec},

Thanks,
Ward.

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



From jens at localhost.kuehnel.org  Sat Jun  7 14:38:06 2008
From: jens at localhost.kuehnel.org (jens at localhost.kuehnel.org)
Date: Sat, 7 Jun 2008 14:38:06 +0200 (CEST)
Subject: [coreboot] Newbee patch for A49LF040A (Alix2c2) please have	a
 look.
In-Reply-To: <484A73B7.4030609@gmx.net>
References: <4849870A.20908@jens.kuehnel.org> <48498FCF.8020404@gmx.net>
	<4849BC9A.20808@jens.kuehnel.org> <4849CE86.60403@gmx.net>
	<20080607031750.GA17479@localdomain> <484A0261.6010302@gmx.net>
	<20080607034714.GA19574@localdomain> <484A73B7.4030609@gmx.net>
Message-ID: <19292.212.21.161.89.1212842286.squirrel@www.kuehnel.org>

> On 07.06.2008 05:47, Ward Vandewege wrote:
>> On Sat, Jun 07, 2008 at 05:37:05AM +0200, Carl-Daniel Hailfinger wrote:
> Ouch. So one of the other probe functions kills communication. Can one
> of you try disabling other chip definitions in flashchips.c with #if 0
> to narrow this problem down?

I did a small shell script.
flashrom -c "W29EE011"
is the problem!

CU
Jens




From info at coresystems.de  Sat Jun  7 15:10:04 2008
From: info at coresystems.de (coreboot information)
Date: Sat, 07 Jun 2008 15:10:04 +0200
Subject: [coreboot] r3362 build service
Message-ID: <E1K4yBI-0003sy-9u@khepri.openbios.org>

Dear coreboot readers!

This is the automated build check service of coreboot.

The developer "stepan" checked in revision 3362 to
the coreboot source repository and caused the following 
changes:

Change Log:
fix via epia cn abuild.

Signed-off-by: Stefan Reinauer <stepan at coresystems.de>
Acked-by: Stefan Reinauer <stepan at coresystems.de>


Build Log:
Compilation of via:epia-cn has been fixed


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,
     coreboot automatic build system





From stepan at coresystems.de  Sat Jun  7 15:40:35 2008
From: stepan at coresystems.de (Stefan Reinauer)
Date: Sat, 07 Jun 2008 15:40:35 +0200
Subject: [coreboot] Newbee patch for A49LF040A (Alix2c2) please have	a
 look.
In-Reply-To: <20080607130052.GA22883@localdomain>
References: <4849870A.20908@jens.kuehnel.org>
	<48498FCF.8020404@gmx.net>	<4849BC9A.20808@jens.kuehnel.org>
	<4849CE86.60403@gmx.net>	<20080607031750.GA17479@localdomain>
	<484A0261.6010302@gmx.net>	<20080607034714.GA19574@localdomain>
	<484A73B7.4030609@gmx.net> <20080607130052.GA22883@localdomain>
Message-ID: <484A8FD3.7040201@coresystems.de>

Ward Vandewege wrote:
> On Sat, Jun 07, 2008 at 01:40:39PM +0200, Carl-Daniel Hailfinger wrote:
>   
>> Ouch. So one of the other probe functions kills communication. Can one
>> of you try disabling other chip definitions in flashchips.c with #if 0
>> to narrow this problem down?
>>     
>
> This is the culprit:
>
>   {"Winbond", "W29EE011",   WINBOND_ID, W_29C011,   128,  128,
> TEST_OK_PREW, probe_w29ee011,   erase_chip_jedec,   write_jedec},
>   

Is it enough to change the order of the lines?

-- 
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 ward at gnu.org  Sat Jun  7 15:45:23 2008
From: ward at gnu.org (Ward Vandewege)
Date: Sat, 7 Jun 2008 09:45:23 -0400
Subject: [coreboot] Newbee patch for A49LF040A (Alix2c2) please have
	a	look.
In-Reply-To: <484A8FD3.7040201@coresystems.de>
References: <4849870A.20908@jens.kuehnel.org> <48498FCF.8020404@gmx.net>
	<4849BC9A.20808@jens.kuehnel.org> <4849CE86.60403@gmx.net>
	<20080607031750.GA17479@localdomain> <484A0261.6010302@gmx.net>
	<20080607034714.GA19574@localdomain> <484A73B7.4030609@gmx.net>
	<20080607130052.GA22883@localdomain>
	<484A8FD3.7040201@coresystems.de>
Message-ID: <20080607134523.GA27554@localdomain>

On Sat, Jun 07, 2008 at 03:40:35PM +0200, Stefan Reinauer wrote:
> Ward Vandewege wrote:
> > On Sat, Jun 07, 2008 at 01:40:39PM +0200, Carl-Daniel Hailfinger wrote:
> >   
> >> Ouch. So one of the other probe functions kills communication. Can one
> >> of you try disabling other chip definitions in flashchips.c with #if 0
> >> to narrow this problem down?
> >>     
> >
> > This is the culprit:
> >
> >   {"Winbond", "W29EE011",   WINBOND_ID, W_29C011,   128,  128,
> > TEST_OK_PREW, probe_w29ee011,   erase_chip_jedec,   write_jedec},
> >   
> 
> Is it enough to change the order of the lines?

No; the probe for W29EE011 is done after the probe for A49LF040A.

Thanks,
Ward.

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



From stepan at coresystems.de  Sat Jun  7 16:07:29 2008
From: stepan at coresystems.de (Stefan Reinauer)
Date: Sat, 07 Jun 2008 16:07:29 +0200
Subject: [coreboot] Newbee patch for A49LF040A (Alix2c2) please have a
 look.
In-Reply-To: <20080607134523.GA27554@localdomain>
References: <4849870A.20908@jens.kuehnel.org> <48498FCF.8020404@gmx.net>
	<4849BC9A.20808@jens.kuehnel.org> <4849CE86.60403@gmx.net>
	<20080607031750.GA17479@localdomain> <484A0261.6010302@gmx.net>
	<20080607034714.GA19574@localdomain> <484A73B7.4030609@gmx.net>
	<20080607130052.GA22883@localdomain>
	<484A8FD3.7040201@coresystems.de>
	<20080607134523.GA27554@localdomain>
Message-ID: <484A9621.1020407@coresystems.de>

Ward Vandewege wrote:
> On Sat, Jun 07, 2008 at 03:40:35PM +0200, Stefan Reinauer wrote:
>   
>> Ward Vandewege wrote:
>>     
>>> On Sat, Jun 07, 2008 at 01:40:39PM +0200, Carl-Daniel Hailfinger wrote:
>>>   
>>>       
>>>> Ouch. So one of the other probe functions kills communication. Can one
>>>> of you try disabling other chip definitions in flashchips.c with #if 0
>>>> to narrow this problem down?
>>>>     
>>>>         
>>> This is the culprit:
>>>
>>>   {"Winbond", "W29EE011",   WINBOND_ID, W_29C011,   128,  128,
>>> TEST_OK_PREW, probe_w29ee011,   erase_chip_jedec,   write_jedec},
>>>   
>>>       
>> Is it enough to change the order of the lines?
>>     
>
> No; the probe for W29EE011 is done after the probe for A49LF040A.
>
> Thanks,
> Ward.
>
>   

Ah, this is broken... flashrom should not continue when it found a chip
in a given memory area already.

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 --------------
An HTML attachment was scrubbed...
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20080607/a418ca1b/attachment.html>

From c-d.hailfinger.devel.2006 at gmx.net  Sat Jun  7 16:21:08 2008
From: c-d.hailfinger.devel.2006 at gmx.net (Carl-Daniel Hailfinger)
Date: Sat, 07 Jun 2008 16:21:08 +0200
Subject: [coreboot] Newbee patch for A49LF040A (Alix2c2) please have a
 look.
In-Reply-To: <484A9621.1020407@coresystems.de>
References: <4849870A.20908@jens.kuehnel.org> <48498FCF.8020404@gmx.net>
	<4849BC9A.20808@jens.kuehnel.org> <4849CE86.60403@gmx.net>
	<20080607031750.GA17479@localdomain> <484A0261.6010302@gmx.net>
	<20080607034714.GA19574@localdomain> <484A73B7.4030609@gmx.net>
	<20080607130052.GA22883@localdomain>
	<484A8FD3.7040201@coresystems.de>
	<20080607134523.GA27554@localdomain>
	<484A9621.1020407@coresystems.de>
Message-ID: <484A9954.3090301@gmx.net>

On 07.06.2008 16:07, Stefan Reinauer wrote:
> Ward Vandewege wrote:
>   
>> On Sat, Jun 07, 2008 at 03:40:35PM +0200, Stefan Reinauer wrote:
>>   
>>     
>>> Ward Vandewege wrote:
>>>     
>>>       
>>>> On Sat, Jun 07, 2008 at 01:40:39PM +0200, Carl-Daniel Hailfinger wrote:
>>>>   
>>>>       
>>>>         
>>>>> Ouch. So one of the other probe functions kills communication. Can one
>>>>> of you try disabling other chip definitions in flashchips.c with #if 0
>>>>> to narrow this problem down?
>>>>>     
>>>>>         
>>>>>           
>>>> This is the culprit:
>>>>
>>>>   {"Winbond", "W29EE011",   WINBOND_ID, W_29C011,   128,  128,
>>>> TEST_OK_PREW, probe_w29ee011,   erase_chip_jedec,   write_jedec},
>>>>   
>>>>       
>>>>         
>>> Is it enough to change the order of the lines?
>>>     
>>>       
>> No; the probe for W29EE011 is done after the probe for A49LF040A.
>>
>> Thanks,
>> Ward.
>>
>>   
>>     
>
> Ah, this is broken... flashrom should not continue when it found a chip
> in a given memory area already.
>   

Besides that, we probe twice for W_29C011. Once we probe with the normal
JEDEC function, the second time we use the special probe function. Maybe
we can figure out why.


Regards,
Carl-Daniel



From peter at stuge.se  Sat Jun  7 16:29:13 2008
From: peter at stuge.se (Peter Stuge)
Date: Sat, 7 Jun 2008 16:29:13 +0200
Subject: [coreboot] Newbee patch for A49LF040A (Alix2c2) please have a
	look.
In-Reply-To: <484A9621.1020407@coresystems.de>
References: <4849BC9A.20808@jens.kuehnel.org> <4849CE86.60403@gmx.net>
	<20080607031750.GA17479@localdomain> <484A0261.6010302@gmx.net>
	<20080607034714.GA19574@localdomain> <484A73B7.4030609@gmx.net>
	<20080607130052.GA22883@localdomain>
	<484A8FD3.7040201@coresystems.de>
	<20080607134523.GA27554@localdomain>
	<484A9621.1020407@coresystems.de>
Message-ID: <20080607142913.25791.qmail@stuge.se>

On Sat, Jun 07, 2008 at 04:07:29PM +0200, Stefan Reinauer wrote:
> Ah, this is broken... flashrom should not continue when it found a
> chip in a given memory area already.

flashrom supports boards with more than one flash chip.

But perhaps we need to teach flashrom more about how chips can be
connected. On boards with two chips, they can obviously not be on
the same LPC bus for example. There would be a collision on the bus.

Ward and me investigated. The W29EE011 probe command is quite similar
to the A49LF040A block erase command, but the last byte differs.
A49LF040A seems to enter an undefined state when it receives such an
unknown command. Sleeping the maximum A49LF040A timeout before
sending the jedec ID exit command did not help.

It seems to me that the Amic chip is behaving badly.

Action plan?

1. Penalize W29EE011 by never probing it without -c W29EE011

This sucks because the W29EE011 chip isn't the one misbehaving here.
On the other hand, it does have a nasty product ID sequence.


2. Make order in flashchips.c important, and stop probing after an
   A49LF040A is found since we know no boards with Amic+other chip.

This sucks because it is SO not obvious that the order of entries in
the table should matter. It also sucks because we would introduce an
exception in the flashrom code flow.


3. Teach flashrom that the only way to have multiple flash chips is
   to have them on different busses. LPC and ISA would have to be
   considered the same, which I think is OK.

This sucks for the same reasons as #2 above. The order of entries in
flashchips.c becomes important here as well.


Personally I think #1 is the lesser of these evils, mainly because
that solution is tinker safe, generic, and W29EE011 is not so common
today. It is not a great solution though, so please share your input
and any ideas.


//Peter



From c-d.hailfinger.devel.2006 at gmx.net  Sat Jun  7 18:14:17 2008
From: c-d.hailfinger.devel.2006 at gmx.net (Carl-Daniel Hailfinger)
Date: Sat, 07 Jun 2008 18:14:17 +0200
Subject: [coreboot] Newbee patch for A49LF040A (Alix2c2) please have a
 look.
In-Reply-To: <20080607142913.25791.qmail@stuge.se>
References: <4849BC9A.20808@jens.kuehnel.org>
	<4849CE86.60403@gmx.net>	<20080607031750.GA17479@localdomain>
	<484A0261.6010302@gmx.net>	<20080607034714.GA19574@localdomain>
	<484A73B7.4030609@gmx.net>	<20080607130052.GA22883@localdomain>	<484A8FD3.7040201@coresystems.de>	<20080607134523.GA27554@localdomain>	<484A9621.1020407@coresystems.de>
	<20080607142913.25791.qmail@stuge.se>
Message-ID: <484AB3D9.2000604@gmx.net>

On 07.06.2008 16:29, Peter Stuge wrote:
> On Sat, Jun 07, 2008 at 04:07:29PM +0200, Stefan Reinauer wrote:
>   
>> Ah, this is broken... flashrom should not continue when it found a
>> chip in a given memory area already.
>>     
>
> flashrom supports boards with more than one flash chip.
>
> But perhaps we need to teach flashrom more about how chips can be
> connected. On boards with two chips, they can obviously not be on
> the same LPC bus for example. There would be a collision on the bus.
>   

Well, you can have multiple different/identical LPC chips on the same
bus as long as they are strapped to different memory locations (chip
numbers). flashrom ignores that right now.

> Ward and me investigated. The W29EE011 probe command is quite similar
> to the A49LF040A block erase command, but the last byte differs.
> A49LF040A seems to enter an undefined state when it receives such an
> unknown command. Sleeping the maximum A49LF040A timeout before
> sending the jedec ID exit command did not help.
>   

Does anyone have the ability to test whether the standard JEDEC probe
would work for the W29EE011?

> It seems to me that the Amic chip is behaving badly.
>
> Action plan?
>
> 1. Penalize W29EE011 by never probing it without -c W29EE011
>
> This sucks because the W29EE011 chip isn't the one misbehaving here.
> On the other hand, it does have a nasty product ID sequence.
>
>
> 2. Make order in flashchips.c important, and stop probing after an
>    A49LF040A is found since we know no boards with Amic+other chip.
>
> This sucks because it is SO not obvious that the order of entries in
> the table should matter. It also sucks because we would introduce an
> exception in the flashrom code flow.
>   

Table order did matter until the "multiple flash chip support" patch was
merged. Having an exception for the Amic chip sounds bad, though.

> 3. Teach flashrom that the only way to have multiple flash chips is
>    to have them on different busses. LPC and ISA would have to be
>    considered the same, which I think is OK.
>
> This sucks for the same reasons as #2 above. The order of entries in
> flashchips.c becomes important here as well.
>   

That's the only correct way to do it.

> Personally I think #1 is the lesser of these evils, mainly because
> that solution is tinker safe, generic, and W29EE011 is not so common
> today. It is not a great solution though, so please share your input
> and any ideas.
>   

I'd say retest whether the W29EE011 can work with standard JEDEC
commands, then decide on further actions.

Regards,
Carl-Daniel



From stepan at coresystems.de  Sat Jun  7 18:37:25 2008
From: stepan at coresystems.de (Stefan Reinauer)
Date: Sat, 07 Jun 2008 18:37:25 +0200
Subject: [coreboot] Newbee patch for A49LF040A (Alix2c2) please have a
 look.
In-Reply-To: <484AB3D9.2000604@gmx.net>
References: <4849BC9A.20808@jens.kuehnel.org>	<4849CE86.60403@gmx.net>	<20080607031750.GA17479@localdomain>	<484A0261.6010302@gmx.net>	<20080607034714.GA19574@localdomain>	<484A73B7.4030609@gmx.net>	<20080607130052.GA22883@localdomain>	<484A8FD3.7040201@coresystems.de>	<20080607134523.GA27554@localdomain>	<484A9621.1020407@coresystems.de>	<20080607142913.25791.qmail@stuge.se>
	<484AB3D9.2000604@gmx.net>
Message-ID: <484AB945.9030401@coresystems.de>

Carl-Daniel Hailfinger wrote:
> On 07.06.2008 16:29, Peter Stuge wrote:
>   
>> On Sat, Jun 07, 2008 at 04:07:29PM +0200, Stefan Reinauer wrote:
>>   
>>     
>>> Ah, this is broken... flashrom should not continue when it found a
>>> chip in a given memory area already.
>>>     
>>>       
>> flashrom supports boards with more than one flash chip.
>>
>> But perhaps we need to teach flashrom more about how chips can be
>> connected. On boards with two chips, they can obviously not be on
>> the same LPC bus for example. There would be a collision on the bus.  
>> 3. Teach flashrom that the only way to have multiple flash chips is
>>    to have them on different busses. LPC and ISA would have to be
>>    considered the same, which I think is OK.
>>
>> This sucks for the same reasons as #2 above. The order of entries in
>> flashchips.c becomes important here as well.
>>   
>>     
>
> That's the only correct way to do it.
>
>   
It does not have to be different busses. There can be 4 flash chips in a
row on the same bus, but not sharing the same physical address space.

-- 
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  Sat Jun  7 19:02:00 2008
From: c-d.hailfinger.devel.2006 at gmx.net (Carl-Daniel Hailfinger)
Date: Sat, 07 Jun 2008 19:02:00 +0200
Subject: [coreboot] Newbee patch for A49LF040A (Alix2c2) please have a
 look.
In-Reply-To: <484AB945.9030401@coresystems.de>
References: <4849BC9A.20808@jens.kuehnel.org>	<4849CE86.60403@gmx.net>	<20080607031750.GA17479@localdomain>	<484A0261.6010302@gmx.net>	<20080607034714.GA19574@localdomain>	<484A73B7.4030609@gmx.net>	<20080607130052.GA22883@localdomain>	<484A8FD3.7040201@coresystems.de>	<20080607134523.GA27554@localdomain>	<484A9621.1020407@coresystems.de>	<20080607142913.25791.qmail@stuge.se>
	<484AB3D9.2000604@gmx.net> <484AB945.9030401@coresystems.de>
Message-ID: <484ABF08.20902@gmx.net>

On 07.06.2008 18:37, Stefan Reinauer wrote:
> Carl-Daniel Hailfinger wrote:
>   
>> On 07.06.2008 16:29, Peter Stuge wrote:
>>   
>>     
>>> On Sat, Jun 07, 2008 at 04:07:29PM +0200, Stefan Reinauer wrote:
>>>   
>>>     
>>>       
>>>> Ah, this is broken... flashrom should not continue when it found a
>>>> chip in a given memory area already.
>>>>
>>>>         

>> Well, you can have multiple different/identical LPC chips on the same
>> bus as long as they are strapped to different memory locations (chip
>> numbers). flashrom ignores that right now.
>>     

>>> flashrom supports boards with more than one flash chip.
>>>
>>> But perhaps we need to teach flashrom more about how chips can be
>>> connected. On boards with two chips, they can obviously not be on
>>> the same LPC bus for example. There would be a collision on the bus.  
>>> 3. Teach flashrom that the only way to have multiple flash chips is
>>>    to have them on different busses. LPC and ISA would have to be
>>>    considered the same, which I think is OK.
>>>
>>> This sucks for the same reasons as #2 above. The order of entries in
>>> flashchips.c becomes important here as well.
>>>
>>>
>>>       
>> That's the only correct way to do it.
>>
>>
>>     
> It does not have to be different busses. There can be 4 flash chips in a
> row on the same bus, but not sharing the same physical address space.
>   

Yes, I wrote that in my mail as well. The "only correct way" statement
was a bit strong, it was intended to request probing for one chip per
bus+addresspace only.

Regards,
Carl-Daniel
-- 

http://www.hailfinger.org/




From coreboot at jens.kuehnel.org  Sun Jun  8 00:15:49 2008
From: coreboot at jens.kuehnel.org (Jens Kuehnel)
Date: Sun, 08 Jun 2008 00:15:49 +0200
Subject: [coreboot] [PATCH] Newbee patch for A49LF040A (Alix2c2) please
 have a look.
In-Reply-To: <484A1521.101@jens.kuehnel.org>
References: <4849870A.20908@jens.kuehnel.org>	<48498FCF.8020404@gmx.net>	<4849BC9A.20808@jens.kuehnel.org>	<4849CE86.60403@gmx.net>
	<484A1521.101@jens.kuehnel.org>
Message-ID: <484B0895.60100@jens.kuehnel.org>

Hi,
I tried to erase the flash tonight. But without result, both 
erase_49lf040 and erase_chip_jedec.

But after a erase_49fl040 the chip does not reacts anymore,until a reboot.

I will compare the Specs of SST49LF040 and the AMIC and will try again 
tomorrow.

Good night from Germany.

CU
Jens



From techie at whiterocker.com  Sun Jun  8 06:23:07 2008
From: techie at whiterocker.com (Chris Kilgour)
Date: Sat, 07 Jun 2008 21:23:07 -0700
Subject: [coreboot] Some Notes On Building gPXE for Coreboot
Message-ID: <484B5EAB.5070608@whiterocker.com>

http://www.whiterocker.com/gpxe/

FYI - At this point I don't plan to submit any patches to gPXE as my 
approach is rather hackish and still experimental.

Any comments/suggestions welcome.

Chris.



From peter at stuge.se  Sun Jun  8 06:32:58 2008
From: peter at stuge.se (Peter Stuge)
Date: Sun, 8 Jun 2008 06:32:58 +0200
Subject: [coreboot] Some Notes On Building gPXE for Coreboot
In-Reply-To: <484B5EAB.5070608@whiterocker.com>
References: <484B5EAB.5070608@whiterocker.com>
Message-ID: <20080608043258.8095.qmail@stuge.se>

On Sat, Jun 07, 2008 at 09:23:07PM -0700, Chris Kilgour wrote:
> http://www.whiterocker.com/gpxe/
> 
> FYI - At this point I don't plan to submit any patches to gPXE as
> my approach is rather hackish and still experimental.
> 
> Any comments/suggestions welcome.

Great work!

How do you think that a "proper" port of gPXE to coreboot differs
from your approach?


//Peter



From bari at onelabs.com  Sun Jun  8 06:40:03 2008
From: bari at onelabs.com (bari)
Date: Sat, 07 Jun 2008 23:40:03 -0500
Subject: [coreboot] Some Notes On Building gPXE for Coreboot
In-Reply-To: <484B5EAB.5070608@whiterocker.com>
References: <484B5EAB.5070608@whiterocker.com>
Message-ID: <484B62A3.4070408@onelabs.com>

May we add this into the coreboot wiki?

-Bari

Chris Kilgour wrote:
> http://www.whiterocker.com/gpxe/
>
> FYI - At this point I don't plan to submit any patches to gPXE as my 
> approach is rather hackish and still experimental.
>
> Any comments/suggestions welcome.
>
> Chris.
>
>   




From techie at whiterocker.com  Sun Jun  8 06:55:14 2008
From: techie at whiterocker.com (Chris Kilgour)
Date: Sat, 07 Jun 2008 21:55:14 -0700
Subject: [coreboot] Some Notes On Building gPXE for Coreboot
In-Reply-To: <20080608043258.8095.qmail@stuge.se>
References: <484B5EAB.5070608@whiterocker.com>
	<20080608043258.8095.qmail@stuge.se>
Message-ID: <484B6632.3050501@whiterocker.com>

Peter Stuge wrote:
> On Sat, Jun 07, 2008 at 09:23:07PM -0700, Chris Kilgour wrote:
>   
>> FYI - At this point I don't plan to submit any patches to gPXE as
>> my approach is rather hackish and still experimental.
>>
>>     
> How do you think that a "proper" port of gPXE to coreboot differs
> from your approach?
>   
Off-hand I would say:

1.  The gPXE elfprefix is currently busted, it would be preferred to fix 
that so gPXE might build a well-formed ELF on its own.  At first I tried 
to fix it but gave up because of #2 below.
2. The "gPXE way" of producing final images is all about feeding a 
universal linker script, and I couldn't find a way of modifying it 
(trimming 16-bit code, getting the elfprefix right) to produce what I 
wanted without massive surgery that would affect a ton of regression 
cases.  So I went the "treat gPXE as a library" route instead.
3. I'm not sure if all the 16-bit gPXE stuff really needs to be omitted 
or if it can/should be left in the ELF.  I didn't want it, but others might.


I also don't have the bandwidth to deal with getting a patch morphed 
into shape that the gPXE maintainers would accept, but I welcome anyone 
with such inclinations to take the baton.


Chris.



From techie at whiterocker.com  Sun Jun  8 07:02:25 2008
From: techie at whiterocker.com (Chris Kilgour)
Date: Sat, 07 Jun 2008 22:02:25 -0700
Subject: [coreboot] Some Notes On Building gPXE for Coreboot
In-Reply-To: <484B62A3.4070408@onelabs.com>
References: <484B5EAB.5070608@whiterocker.com> <484B62A3.4070408@onelabs.com>
Message-ID: <484B67E1.1030203@whiterocker.com>

bari wrote:
> May we add this into the coreboot wiki?
>
I was going to do that originally.  But I wondered if putting it on the 
coreboot Wiki before any success reports would give it some 
as-yet-undeserved credence.

That said, if anyone would like to adapt my instructions to the coreboot 
Wiki, please feel free to do so.

Chris.



From c-d.hailfinger.devel.2006 at gmx.net  Sun Jun  8 13:41:33 2008
From: c-d.hailfinger.devel.2006 at gmx.net (Carl-Daniel Hailfinger)
Date: Sun, 08 Jun 2008 13:41:33 +0200
Subject: [coreboot] Offline notice
Message-ID: <484BC56D.9030903@gmx.net>

Hi all,

I regret to tell you that I'll probably be offline (and very slow to
respond to mail) until June 30th due to university sucking up every hour
of my days and nights.
If you all continue working on coreboot like you did before (I don't
doubt that), I'll come back and will be surprised by lots of great news. :-)

Have fun and good luck!
Regards,
Carl-Daniel



From lyos.gemininorezel at gmail.com  Sun Jun  8 20:59:03 2008
From: lyos.gemininorezel at gmail.com (Lyos Norezel)
Date: Sun, 8 Jun 2008 14:59:03 -0400
Subject: [coreboot] BIOS Chip AMIC A29040BL Documentation
In-Reply-To: <45a5b7cc0806081153l64cbc6bbmef55297255e8c26b@mail.gmail.com>
References: <45a5b7cc0806081153l64cbc6bbmef55297255e8c26b@mail.gmail.com>
Message-ID: <45a5b7cc0806081159y1947e6bfo5e998ab8e535d720@mail.gmail.com>

Greetings.
     My Motherboard has a BIOS chip label AMIC A29040BL. Flashrom does not,
yet, support this chip. The chipset of this motherboard is supported
however. The documentation for this BIOS chip can be found here:
http://www.amictechnology.com/pdf/A29040B.pdf .
Any way this chip could be added to flashrom?

Lyos Gemini Norezel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20080608/30136313/attachment.html>

From bari at onelabs.com  Mon Jun  9 00:16:17 2008
From: bari at onelabs.com (bari)
Date: Sun, 08 Jun 2008 17:16:17 -0500
Subject: [coreboot] V2 Orders of Initialization of Devices
Message-ID: <484C5A31.9000301@onelabs.com>

Does the order of the devices in /src/maniboard/../../Config.lb actually 
effect the order in which the devices are initialized in coreboot?

If not, what is the preferred method if one device or register needs to 
be set before others?

-Bari



From khorben at defora.org  Mon Jun  9 00:50:55 2008
From: khorben at defora.org (Pierre Pronchery)
Date: Mon, 09 Jun 2008 00:50:55 +0200
Subject: [coreboot] Makefile generation patch for non-native GNU make
Message-ID: <484C624F.8070605@defora.org>

Changes Makefile generation so that recursive "make" calls read
"$(MAKE)" instead, as GNU make (or "gmake") is currently necessary to build.

Signed-off-by: Pierre Pronchery <khorben at defora.org>
---
HTH,
-- 
khorben
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: coreboot.patch
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20080609/e070ed74/attachment.ksh>

From svn at coreboot.org  Mon Jun  9 01:05:24 2008
From: svn at coreboot.org (svn at coreboot.org)
Date: Mon,  9 Jun 2008 01:05:24 +0200
Subject: [coreboot] r3363 - in trunk/coreboot-v2/util: ADLO newconfig
Message-ID: <mailman.1624.1355071331.16123.coreboot@coreboot.org>

Author: stepan
Date: 2008-06-09 01:05:24 +0200 (Mon, 09 Jun 2008)
New Revision: 3363

Modified:
   trunk/coreboot-v2/util/ADLO/Makefile
   trunk/coreboot-v2/util/newconfig/config.g
Log:
Changes Makefile generation so that recursive "make" calls read
"$(MAKE)" instead, as GNU make (or "gmake") is currently necessary to build.

Signed-off-by: Pierre Pronchery <khorben at defora.org>
Acked-by: Stefan Reinauer <stepan at coresystems.de>



Modified: trunk/coreboot-v2/util/ADLO/Makefile
===================================================================
--- trunk/coreboot-v2/util/ADLO/Makefile	2008-06-07 12:35:11 UTC (rev 3362)
+++ trunk/coreboot-v2/util/ADLO/Makefile	2008-06-08 23:05:24 UTC (rev 3363)
@@ -40,7 +40,7 @@
 #-------------------------------------------------
 
 bios:
-	( cd ${BOCHS_B} ; make )
+	( cd ${BOCHS_B} ; $(MAKE) )
 	sync
 
 #-------------------------------------------------
@@ -101,7 +101,7 @@
 
 clean:
 	rm -rf *.o ${PAYLOAD}
-	(cd ${BOCHS_B} ; make clean ) 
+	(cd ${BOCHS_B} ; $(MAKE) clean ) 
 
 distclean: clean
 	rm -rf ${BOCHS_C}

Modified: trunk/coreboot-v2/util/newconfig/config.g
===================================================================
--- trunk/coreboot-v2/util/newconfig/config.g	2008-06-07 12:35:11 UTC (rev 3362)
+++ trunk/coreboot-v2/util/newconfig/config.g	2008-06-08 23:05:24 UTC (rev 3363)
@@ -2158,7 +2158,7 @@
 	for i, o in romimages.items():
 		file.write("%s/coreboot.rom:\n" % o.getname())
 		file.write("\tif (cd %s; \\\n" % o.getname())
-		file.write("\t\tmake coreboot.rom)\\\n")
+		file.write("\t\t$(MAKE) coreboot.rom)\\\n")
 		file.write("\tthen true; else exit 1; fi;\n\n")
 	file.write("clean: ")
 	for i in romimages.keys():
@@ -2166,7 +2166,7 @@
 	file.write("\n\n")
 	for i, o in romimages.items():
 		file.write("%s-clean:\n" % o.getname())
-		file.write("\t(cd %s; make clean)\n\n" % o.getname())
+		file.write("\t(cd %s; $(MAKE) clean)\n\n" % o.getname())
 
 	for i in buildroms:
 		file.write("%s:" % i.name)




From stepan at coresystems.de  Mon Jun  9 01:06:14 2008
From: stepan at coresystems.de (Stefan Reinauer)
Date: Mon, 09 Jun 2008 01:06:14 +0200
Subject: [coreboot] Makefile generation patch for non-native GNU make
In-Reply-To: <484C624F.8070605@defora.org>
References: <484C624F.8070605@defora.org>
Message-ID: <484C65E6.3080000@coresystems.de>

Pierre Pronchery wrote:
> Changes Makefile generation so that recursive "make" calls read
> "$(MAKE)" instead, as GNU make (or "gmake") is currently necessary to build.
>
> Signed-off-by: Pierre Pronchery <khorben at defora.org>
> ---
> HTH,
>   
Thanks,

Committed as revision 3363.


-- 
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 --------------
An HTML attachment was scrubbed...
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20080609/2436a50e/attachment.html>

From joe at settoplinux.org  Mon Jun  9 04:29:35 2008
From: joe at settoplinux.org (Joseph Smith)
Date: Sun, 8 Jun 2008 22:29:35 -0400
Subject: [coreboot] V2 Orders of Initialization of Devices
In-Reply-To: <484C5A31.9000301@onelabs.com>
References: <484C5A31.9000301@onelabs.com>
Message-ID: <F1E6FD377C74478F9477AF448422C2B6@smitty2m>



> -----Original Message-----
> From: coreboot-bounces at coreboot.org [mailto:coreboot-bounces at coreboot.org]
> On Behalf Of bari
> Sent: Sunday, June 08, 2008 6:16 PM
> To: coreboot at coreboot.org
> Subject: [coreboot] V2 Orders of Initialization of Devices
> 
> Does the order of the devices in /src/maniboard/../../Config.lb actually
> effect the order in which the devices are initialized in coreboot?
> 
> If not, what is the preferred method if one device or register needs to
> be set before others?
> 

If you need to initialize a device early you can always do it in auto.c, but
it depends which device it is.....
For example, if it is a PCI device, you will need to initialize the PCI
bridge first, and then you can initialize the PCI device.

Thanks,
Joseph Smith
Set-Top-Linux
www.settoplinux.org




From kevin at koconnor.net  Mon Jun  9 05:37:40 2008
From: kevin at koconnor.net (Kevin O'Connor)
Date: Sun, 8 Jun 2008 23:37:40 -0400
Subject: [coreboot] latest legacybios update
Message-ID: <20080609033740.GA1161@morn.localdomain>

Hi,

I've made some recent progress with "legacybios".  The code will now
locate and parse the coreboot table.  This means that "legacybios"
will now have the correct ram size and will properly populate the e820
map with the info.  I've confirmed that my epia-m continues to boot
into linux with the recent changes.

I've also fixed a few bugs - slave ide drives are now working for me
and apm no longer crashes the linux kernel.

For those that are interested, the code is in git - see:

http://git.linuxtogo.org/

My next step is going to be getting bios tables (pir, acpi) working so
that the legacybios payload doesn't overwrite them.  I plan on
hacking coreboot-v2 so that it deploys the tables to the top of ram
instead of 0xf0000.  I then plan on having legacybios locate the
tables (by looking at the coreboot table) and then copy the subset of
tables that must reside in the 0xf0000 segment.

For those that remember the discussion at:

http://www.coreboot.org/pipermail/coreboot/2008-May/034688.html

I'm basically advocating option (c).

Finally, I've successfully booted windows xp and windows vista under
qemu (without using coreboot).  Once I get the standard bios tables
working, I'll see if I can get them running too.

-Kevin



From bari at onelabs.com  Mon Jun  9 05:52:26 2008
From: bari at onelabs.com (bari)
Date: Sun, 08 Jun 2008 22:52:26 -0500
Subject: [coreboot] V2 Orders of Initialization of Devices
In-Reply-To: <F1E6FD377C74478F9477AF448422C2B6@smitty2m>
References: <484C5A31.9000301@onelabs.com>
	<F1E6FD377C74478F9477AF448422C2B6@smitty2m>
Message-ID: <484CA8FA.3060606@onelabs.com>

Joseph Smith wrote:
>>
>> Does the order of the devices in /src/maniboard/../../Config.lb actually
>> effect the order in which the devices are initialized in coreboot?
>>
>> If not, what is the preferred method if one device or register needs to
>> be set before others?
>>
>>     
>
> If you need to initialize a device early you can always do it in auto.c, but
> it depends which device it is.....
> For example, if it is a PCI device, you will need to initialize the PCI
> bridge first, and then you can initialize the PCI device.
>
>
>   
Yes, but if you don't use auto.c does the order in Config.lb have an 
effect on the order in which registers are written to or read from?

-Bari




From kevin at koconnor.net  Mon Jun  9 05:59:34 2008
From: kevin at koconnor.net (Kevin O'Connor)
Date: Sun, 8 Jun 2008 23:59:34 -0400
Subject: [coreboot] latest legacybios update
In-Reply-To: <20080609033740.GA1161@morn.localdomain>
References: <20080609033740.GA1161@morn.localdomain>
Message-ID: <20080609035934.GA1323@morn.localdomain>

On Sun, Jun 08, 2008 at 11:37:40PM -0400, Kevin O'Connor wrote:
> I've made some recent progress with "legacybios".

One more update - the freedos v1.0 live cd boots and runs on my
epia-m.  I've also confirmed regular PS2 style keyboard and mouse are
working.

-Kevin



From joe at settoplinux.org  Mon Jun  9 14:03:39 2008
From: joe at settoplinux.org (Joseph Smith)
Date: Mon, 9 Jun 2008 08:03:39 -0400
Subject: [coreboot] latest legacybios update
In-Reply-To: <20080609033740.GA1161@morn.localdomain>
References: <20080609033740.GA1161@morn.localdomain>
Message-ID: <0A5742B41ED74EA685BE57599E25A43F@smitty2m>



> -----Original Message-----
> From: coreboot-bounces at coreboot.org [mailto:coreboot-bounces at coreboot.org]
> On Behalf Of Kevin O'Connor
> Sent: Sunday, June 08, 2008 11:38 PM
> To: coreboot at coreboot.org
> Subject: [coreboot] latest legacybios update
> 
> Hi,
> 
> I've made some recent progress with "legacybios".  The code will now
> locate and parse the coreboot table.  This means that "legacybios"
> will now have the correct ram size and will properly populate the e820
> map with the info.  I've confirmed that my epia-m continues to boot
> into linux with the recent changes.
> 
> I've also fixed a few bugs - slave ide drives are now working for me
> and apm no longer crashes the linux kernel.
> 
> For those that are interested, the code is in git - see:
> 
> http://git.linuxtogo.org/
> 
> My next step is going to be getting bios tables (pir, acpi) working so
> that the legacybios payload doesn't overwrite them.  I plan on
> hacking coreboot-v2 so that it deploys the tables to the top of ram
> instead of 0xf0000.  I then plan on having legacybios locate the
> tables (by looking at the coreboot table) and then copy the subset of
> tables that must reside in the 0xf0000 segment.
> 
> For those that remember the discussion at:
> 
> http://www.coreboot.org/pipermail/coreboot/2008-May/034688.html
> 
> I'm basically advocating option (c).
> 
> Finally, I've successfully booted windows xp and windows vista under
> qemu (without using coreboot).  Once I get the standard bios tables
> working, I'll see if I can get them running too.
> 
Great work Kevin :-)

Thanks,
Joseph Smith
Set-Top-Linux
www.settoplinux.org




From joe at settoplinux.org  Mon Jun  9 14:06:30 2008
From: joe at settoplinux.org (Joseph Smith)
Date: Mon, 9 Jun 2008 08:06:30 -0400
Subject: [coreboot] V2 Orders of Initialization of Devices
In-Reply-To: <484CA8FA.3060606@onelabs.com>
References: <484C5A31.9000301@onelabs.com><F1E6FD377C74478F9477AF448422C2B6@smitty2m>
	<484CA8FA.3060606@onelabs.com>
Message-ID: <5414A7336B20468E9AD8DCB96F299958@smitty2m>




> -----Original Message-----
> From: coreboot-bounces at coreboot.org [mailto:coreboot-bounces at coreboot.org]
> On Behalf Of bari
> Sent: Sunday, June 08, 2008 11:52 PM
> To: joe at settoplinux.org
> Cc: coreboot at coreboot.org
> Subject: Re: [coreboot] V2 Orders of Initialization of Devices
> 
> Joseph Smith wrote:
> >>
> >> Does the order of the devices in /src/maniboard/../../Config.lb
> actually
> >> effect the order in which the devices are initialized in coreboot?
> >>
> >> If not, what is the preferred method if one device or register needs to
> >> be set before others?
> >>
> >>
> >
> > If you need to initialize a device early you can always do it in auto.c,
> but
> > it depends which device it is.....
> > For example, if it is a PCI device, you will need to initialize the PCI
> > bridge first, and then you can initialize the PCI device.
> >
> >
> >
> Yes, but if you don't use auto.c does the order in Config.lb have an
> effect on the order in which registers are written to or read from?
> 

Hmm, only one way to find out. Move some stuff around Config.lb, and compare
the bootlog with past bootlogs. I'd be curious to find out the results.

Thanks,
Joseph Smith
Set-Top-Linux
www.settoplinux.org




From joe at settoplinux.org  Mon Jun  9 14:10:55 2008
From: joe at settoplinux.org (Joseph Smith)
Date: Mon, 9 Jun 2008 08:10:55 -0400
Subject: [coreboot] Memory clock cycles -> microseconds (us)
In-Reply-To: <5414A7336B20468E9AD8DCB96F299958@smitty2m>
References: <484C5A31.9000301@onelabs.com><F1E6FD377C74478F9477AF448422C2B6@smitty2m><484CA8FA.3060606@onelabs.com>
	<5414A7336B20468E9AD8DCB96F299958@smitty2m>
Message-ID: <6066E9236D084E45A769DB5CBD67BFE6@smitty2m>

Hello,
Does anyone know the mathematical formula for converting memory clock cycles
into microseconds (us)??


Thanks,
Joseph Smith
Set-Top-Linux
www.settoplinux.org




From jordan.crouse at amd.com  Mon Jun  9 17:10:29 2008
From: jordan.crouse at amd.com (Jordan Crouse)
Date: Mon, 9 Jun 2008 09:10:29 -0600
Subject: [coreboot] Some Notes On Building gPXE for Coreboot
In-Reply-To: <484B5EAB.5070608@whiterocker.com>
References: <484B5EAB.5070608@whiterocker.com>
Message-ID: <20080609151029.GD21123@cosmic.amd.com>

On 07/06/08 21:23 -0700, Chris Kilgour wrote:
> http://www.whiterocker.com/gpxe/
> 
> FYI - At this point I don't plan to submit any patches to gPXE as my 
> approach is rather hackish and still experimental.

I really like this patch:
http://www.whiterocker.com/gpxe/libpayload-lplconsole.patch

We should investigate ways to build this into the generic build to
work around other payloads that might have similar issues.

Jordan

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




From mylesgw at gmail.com  Mon Jun  9 17:53:02 2008
From: mylesgw at gmail.com (Myles Watson)
Date: Mon, 9 Jun 2008 09:53:02 -0600
Subject: [coreboot] Memory clock cycles -> microseconds (us)
In-Reply-To: <6066E9236D084E45A769DB5CBD67BFE6@smitty2m>
References: <484C5A31.9000301@onelabs.com><F1E6FD377C74478F9477AF448422C2B6@smitty2m><484CA8FA.3060606@onelabs.com><5414A7336B20468E9AD8DCB96F299958@smitty2m>
	<6066E9236D084E45A769DB5CBD67BFE6@smitty2m>
Message-ID: <016901c8ca48$e6f19ff0$0023040a@chimp>

> Hello,
> Does anyone know the mathematical formula for converting memory clock
> cycles
> into microseconds (us)??

1 MHz means 1 million clock cycles per second, so 1 clock cycle per
microsecond.

166 MHz -> 166 clock cycles per microsecond.

Thanks,
Myles





From Ken.Fuchs at bench.com  Mon Jun  9 18:25:53 2008
From: Ken.Fuchs at bench.com (Ken.Fuchs at bench.com)
Date: Mon, 9 Jun 2008 11:25:53 -0500
Subject: [coreboot] filo-0.5 compilation issues
Message-ID: <AA28F077645B324881335614E4F7C428034DC5@win-ex01.bench.com>

I can't use svn protocol, because my firewall permits only the
standard ports for ftp, http and https, etc.  So, I accessed
the filo-0.5 URI:

http://openbios.org/viewvc/trunk/filo-0.5/?root=FILO

Next, I clicked the "Download GNU tarball" link with URI:

http://openbios.org/viewvc/trunk/filo-0.5.tar.gz?root=FILO&view=tar

The file downloaded is trunk.tar.gz which extracts fine:

$ tar xvzf trunk.tar.gz

Target directory is trunk/filo-0.5 as expected.

Compilation issues:

Make is run once to create the default Config file and
define the include/arch symlink.  A second make invocation
should build the file.elf target, but fatal compilation
errors prevent this.

I'm using gcc v4.1.2 and make v3.81 (Knoppix 5.1.1).  Is my
toolchain too old?

Here is a log of the two make invocations mentioned above.
The Config is not changed from the default generated, but
will need to be changed to generate the desired target.

------

The errors that occur using the default Config
generated from i386/defconfig without making any changes
to Config or the filo-0.5 source files:

$ make
rm -f include/arch
ln -s ../i386/include include/arch
test -f Config && mv Config Config.bak || true
cat defconfig i386/defconfig >>Config
*** Default Config file is created ***
*** Now you examine this file and edit it as you like ***
$ make
Makefile:64: warning: overriding commands for target `clean'
makerules:46: warning: ignoring old commands for target `clean'
echo '#define PROGRAM_NAME "FILO"' > main/version.h
echo '#define PROGRAM_VERSION "0.5.5 (fuchsk at Knoppix) Mon Jun  9
12:42:45 EDT 2008"' >> main/version.h
make -C main
make[1]: Entering directory `/mnt/s2u1/atom/cb/trunk/filo-0.5/main'
/bin/echo -e '/* GENERATED FILE, DO NOT EDIT */\n' >../config.h
sed -e 's/#.*//' -e '/=/!d' -e
's/\([^[:space:]]*\)[[:space:]]*=[[:space:]]*\(.*\).*/#define \1 \2/' -e
's/^#define \([^ ]*\) 0$/#undef \1/' ../Config >>../config.h
gcc -m32 -Wall -Os -fomit-frame-pointer -fno-common -ffreestanding
-fno-strict-aliasing -Wno-unused  -nostdinc -imacros ../config.h
-I../include -I/usr/lib/gcc/i486-linux-gnu/4.1.2/include -MD -c filo.c
-o filo.o
gcc -m32 -Wall -Os -fomit-frame-pointer -fno-common -ffreestanding
-fno-strict-aliasing -Wno-unused  -nostdinc -imacros ../config.h
-I../include -I/usr/lib/gcc/i486-linux-gnu/4.1.2/include -MD -c
linuxbios.c -o linuxbios.o
gcc -m32 -Wall -Os -fomit-frame-pointer -fno-common -ffreestanding
-fno-strict-aliasing -Wno-unused  -nostdinc -imacros ../config.h
-I../include -I/usr/lib/gcc/i486-linux-gnu/4.1.2/include -MD -c malloc.c
-o malloc.o
malloc.c: In function 'allot2':
malloc.c:206: warning: assignment makes integer from pointer without a
cast
gcc -m32 -Wall -Os -fomit-frame-pointer -fno-common -ffreestanding
-fno-strict-aliasing -Wno-unused  -nostdinc -imacros ../config.h
-I../include -I/usr/lib/gcc/i486-linux-gnu/4.1.2/include -MD -c printf.c
-o printf.o
printf.c: In function 'vtxprintf':
printf.c:197: error: 'se' undeclared (first use in this function)
printf.c:197: error: (Each undeclared identifier is reported only once
printf.c:197: error: for each function it appears in.)
printf.c:197: error: 'value' undeclared (first use in this function)
printf.c:198: error: 'cp' undeclared (first use in this function)
printf.c:199: warning: no return statement in function returning
non-void
printf.c: At top level:
printf.c:200: error: expected identifier or '(' before 'if'
printf.c:202: error: expected identifier or '(' before 'return'
printf.c:203: error: expected identifier or '(' before '}' token
printf.c:206: error: redefinition of 'simple_strtoll'
printf.c:60: error: previous definition of 'simple_strtoll' was here
printf.c: In function 'simple_strtoll':
printf.c:209: error: expected ')' before 'flags'
printf.c:214: error: too few arguments to function 'simple_strtoull'
printf.c:214: error: expected ';' before '}' token
printf.c: At top level:
printf.c:217: warning: data definition has no type or storage class
printf.c:217: warning: type defaults to 'int' in declaration of
'field_width'
printf.c:218: error: expected identifier or '(' before 'if'
printf.c:220: error: expected identifier or '(' before 'else'
printf.c:231: warning: data definition has no type or storage class
printf.c:231: warning: type defaults to 'int' in declaration of
'precision'
printf.c:232: error: expected identifier or '(' before 'if'
printf.c:246: warning: data definition has no type or storage class
printf.c:246: warning: type defaults to 'int' in declaration of
'qualifier'
printf.c:247: error: expected identifier or '(' before 'if'
printf.c:253: warning: data definition has no type or storage class
printf.c:253: warning: type defaults to 'int' in declaration of 'base'
printf.c:255: error: expected identifier or '(' before 'switch'
printf.c:331: error: expected identifier or '(' before 'if'
printf.c:333: error: expected identifier or '(' before 'else'
printf.c:335: error: expected identifier or '(' before 'else'
printf.c:339: error: expected identifier or '(' before 'else'
printf.c:341: error: expected identifier or '(' before 'else'
printf.c:343: error: expected '=', ',', ';', 'asm' or '__attribute__'
before '+=' token
printf.c:344: error: expected identifier or '(' before '}' token
printf.c:345: error: expected identifier or '(' before 'return'
printf.c:346: error: expected identifier or '(' before '}' token
make[1]: *** [printf.o] Error 1
make[1]: Leaving directory `/mnt/s2u1/atom/cb/trunk/filo-0.5/main'
make: *** [main/builtin.o] Error 2

Thanks,

Ken Fuchs



From peter at stuge.se  Mon Jun  9 19:03:46 2008
From: peter at stuge.se (Peter Stuge)
Date: Mon, 9 Jun 2008 19:03:46 +0200
Subject: [coreboot] coreboot BIOSisms
In-Reply-To: <20080609033740.GA1161@morn.localdomain>
References: <20080609033740.GA1161@morn.localdomain>
Message-ID: <20080609170346.357.qmail@stuge.se>

On Sun, Jun 08, 2008 at 11:37:40PM -0400, Kevin O'Connor wrote:
> I plan on hacking coreboot-v2 so that it deploys the tables to the
> top of ram instead of 0xf0000.  I then plan on having legacybios
> locate the tables (by looking at the coreboot table) and then copy
> the subset of tables that must reside in the 0xf0000 segment.
> 
> For those that remember the discussion at:
> 
> http://www.coreboot.org/pipermail/coreboot/2008-May/034688.html
> 
> I'm basically advocating option (c).

I still don't want coreboot to know about BIOS tables at all.

Alas, it already does, there is both PIR and ACPI.


Do we really want these BIOS tables to be created by coreboot?

If yes, why shouldn't LegacyBIOS simply be included in coreboot?

If no, how can we fix that?


I would much prefer if any and all table generation could be handled
by LegacyBIOS or maybe another, separate, payload. I think it is
important to isolate coreboot from BIOSisms, so that new, modern,
payloads don't start using BIOS tables created by coreboot because
that's what the other kids did, or because it was the only way the
information was accessible. I'd like to move away from that scenario.

Is it really the best we can do? :\


//Peter



From joe at settoplinux.org  Mon Jun  9 19:06:08 2008
From: joe at settoplinux.org (Joseph Smith)
Date: Mon, 09 Jun 2008 13:06:08 -0400
Subject: [coreboot] Memory clock cycles -> microseconds (us)
In-Reply-To: <016901c8ca48$e6f19ff0$0023040a@chimp>
References: <484C5A31.9000301@onelabs.com><F1E6FD377C74478F9477AF448422C2B6@smitty2m><484CA8FA.3060606@onelabs.com><5414A7336B20468E9AD8DCB96F299958@smitty2m>
	<6066E9236D084E45A769DB5CBD67BFE6@smitty2m>
	<016901c8ca48$e6f19ff0$0023040a@chimp>
Message-ID: <d1aebbcb3bb5f0a4c94f1994172d56f7@imap.1and1.com>




On Mon, 9 Jun 2008 09:53:02 -0600, "Myles Watson" <mylesgw at gmail.com>
wrote:
>> Hello,
>> Does anyone know the mathematical formula for converting memory clock
>> cycles
>> into microseconds (us)??
> 
> 1 MHz means 1 million clock cycles per second, so 1 clock cycle per
> microsecond.
> 
> 166 MHz -> 166 clock cycles per microsecond.
> 
Thanks Myles:-)
I didn't realize it was that easy.
So, for example if a memory initialization datasheet says you should delay
for 3 clocks than that means 3us, correct?

-- 
Thanks,
Joseph Smith
Set-Top-Linux
www.settoplinux.org




From peter at stuge.se  Mon Jun  9 19:14:32 2008
From: peter at stuge.se (Peter Stuge)
Date: Mon, 9 Jun 2008 19:14:32 +0200
Subject: [coreboot] Memory clock cycles -> microseconds (us)
In-Reply-To: <d1aebbcb3bb5f0a4c94f1994172d56f7@imap.1and1.com>
References: <6066E9236D084E45A769DB5CBD67BFE6@smitty2m>
	<016901c8ca48$e6f19ff0$0023040a@chimp>
	<d1aebbcb3bb5f0a4c94f1994172d56f7@imap.1and1.com>
Message-ID: <20080609171432.10656.qmail@stuge.se>

On Mon, Jun 09, 2008 at 01:06:08PM -0400, Joseph Smith wrote:
> >> Does anyone know the mathematical formula for converting memory
> >> clock cycles into microseconds (us)??
> > 
> > 1 MHz means 1 million clock cycles per second, so 1 clock cycle
> > per microsecond.
> > 
> > 166 MHz -> 166 clock cycles per microsecond.
> 
> Thanks Myles:-)
> I didn't realize it was that easy.
> So, for example if a memory initialization datasheet says you
> should delay for 3 clocks than that means 3us, correct?

Only if the memory clock is 1MHz, but if it's 166MHz then delay for
3/166 microseconds = 18 nanoseconds


The formula is: t=1/f

If f=1000000, each cycle is 1/1000000 seconds, or 1 microsecond.
If f=166000000, each cycle is 1/166000000 seconds, or 1/166 us = 6 ns


//Peter



From stepan at coresystems.de  Mon Jun  9 19:20:30 2008
From: stepan at coresystems.de (Stefan Reinauer)
Date: Mon, 09 Jun 2008 19:20:30 +0200
Subject: [coreboot] coreboot BIOSisms
In-Reply-To: <20080609170346.357.qmail@stuge.se>
References: <20080609033740.GA1161@morn.localdomain>
	<20080609170346.357.qmail@stuge.se>
Message-ID: <484D665E.3090308@coresystems.de>

Peter Stuge wrote:
>
> Do we really want these BIOS tables to be created by coreboot?
>
> If yes, why shouldn't LegacyBIOS simply be included in coreboot?
>   

I definitely think it should. We have half a legacybios in there for VGA
init anyways.
Obviously as an option. Or, rather, as a dependency when you choose the
option "option rom based VGA init" or the option "int13 bootloader".

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 joe at settoplinux.org  Mon Jun  9 19:23:21 2008
From: joe at settoplinux.org (Joseph Smith)
Date: Mon, 09 Jun 2008 13:23:21 -0400
Subject: [coreboot] coreboot BIOSisms
In-Reply-To: <484D665E.3090308@coresystems.de>
References: <20080609033740.GA1161@morn.localdomain>
	<20080609170346.357.qmail@stuge.se>
	<484D665E.3090308@coresystems.de>
Message-ID: <c498d8c6ff2b02a017e3fbb0b17bfe67@imap.1and1.com>




On Mon, 09 Jun 2008 19:20:30 +0200, Stefan Reinauer <stepan at coresystems.de>
wrote:
> Peter Stuge wrote:
>>
>> Do we really want these BIOS tables to be created by coreboot?
>>
>> If yes, why shouldn't LegacyBIOS simply be included in coreboot?
>>   
> 
> I definitely think it should. We have half a legacybios in there for VGA
> init anyways.
> Obviously as an option. Or, rather, as a dependency when you choose the
> option "option rom based VGA init" or the option "int13 bootloader".
> 
I like your take on this Stefan. Why not just make it an option in
coreboot?

-- 
Thanks,
Joseph Smith
Set-Top-Linux
www.settoplinux.org




From Marc.Jones at amd.com  Mon Jun  9 19:23:51 2008
From: Marc.Jones at amd.com (Marc Jones)
Date: Mon, 09 Jun 2008 11:23:51 -0600
Subject: [coreboot] coreboot BIOSisms
In-Reply-To: <20080609170346.357.qmail@stuge.se>
References: <20080609033740.GA1161@morn.localdomain>
	<20080609170346.357.qmail@stuge.se>
Message-ID: <484D6727.1000304@amd.com>

Peter Stuge wrote:

> I still don't want coreboot to know about BIOS tables at all.
> 
> Alas, it already does, there is both PIR and ACPI.


Because they are required by Linux.


> Do we really want these BIOS tables to be created by coreboot?

probably.

> If yes, why shouldn't LegacyBIOS simply be included in coreboot?

maybe but legacybios has a lot of things coreboot (for Linux) doesn't 
need. They are required for other OS.

> If no, how can we fix that?
> 
> 
> I would much prefer if any and all table generation could be handled
> by LegacyBIOS or maybe another, separate, payload. 

Then that payload has to have the knowledge of every cpu, chipset, and 
motherboard configuration to extract the information. That is difficult 
which is why the OS leaves it up the the BIOS. It make sense that the 
tables are generated and used by the configuration code.

Marc

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




From peter at stuge.se  Mon Jun  9 19:31:40 2008
From: peter at stuge.se (Peter Stuge)
Date: Mon, 9 Jun 2008 19:31:40 +0200
Subject: [coreboot] coreboot BIOSisms
In-Reply-To: <c498d8c6ff2b02a017e3fbb0b17bfe67@imap.1and1.com>
References: <20080609033740.GA1161@morn.localdomain>
	<20080609170346.357.qmail@stuge.se>
	<484D665E.3090308@coresystems.de>
	<c498d8c6ff2b02a017e3fbb0b17bfe67@imap.1and1.com>
Message-ID: <20080609173140.26398.qmail@stuge.se>

On Mon, Jun 09, 2008 at 01:23:21PM -0400, Joseph Smith wrote:
> >> If yes, why shouldn't LegacyBIOS simply be included in coreboot?
> > 
> > I definitely think it should. We have half a legacybios in there
> > for VGA init anyways.
> > Obviously as an option. Or, rather, as a dependency when you choose
> > the option "option rom based VGA init" or the option "int13
> > bootloader".
> 
> I like your take on this Stefan. Why not just make it an option in
> coreboot?

Tricky because it drastically changes coreboot's demarcation point.

I also like Stefan's thinking to use LegacyBIOS rather than the
built-in half-baked stuff for VGA init, and int 13.

That's just one rather simple BIOSism though, the callbacks during
coreboot runtime. Whether they should remain for the payload is
another matter, as are the tables.


//Peter



From joe at settoplinux.org  Mon Jun  9 19:36:29 2008
From: joe at settoplinux.org (Joseph Smith)
Date: Mon, 09 Jun 2008 13:36:29 -0400
Subject: [coreboot] Memory clock cycles -> microseconds (us)
In-Reply-To: <20080609171432.10656.qmail@stuge.se>
References: <6066E9236D084E45A769DB5CBD67BFE6@smitty2m>
	<016901c8ca48$e6f19ff0$0023040a@chimp>
	<d1aebbcb3bb5f0a4c94f1994172d56f7@imap.1and1.com>
	<20080609171432.10656.qmail@stuge.se>
Message-ID: <5f2490688d69840150eff2bf6cae68ea@imap.1and1.com>




On Mon, 9 Jun 2008 19:14:32 +0200, Peter Stuge <peter at stuge.se> wrote:
> On Mon, Jun 09, 2008 at 01:06:08PM -0400, Joseph Smith wrote:
>> >> Does anyone know the mathematical formula for converting memory
>> >> clock cycles into microseconds (us)??
>> >
>> > 1 MHz means 1 million clock cycles per second, so 1 clock cycle
>> > per microsecond.
>> >
>> > 166 MHz -> 166 clock cycles per microsecond.
>>
>> Thanks Myles:-)
>> I didn't realize it was that easy.
>> So, for example if a memory initialization datasheet says you
>> should delay for 3 clocks than that means 3us, correct?
> 
> Only if the memory clock is 1MHz, but if it's 166MHz then delay for
> 3/166 microseconds = 18 nanoseconds
> 
> 
> The formula is: t=1/f
> 
> If f=1000000, each cycle is 1/1000000 seconds, or 1 microsecond.
> If f=166000000, each cycle is 1/166000000 seconds, or 1/166 us = 6 ns
> 
> 
Ok, let me get this straight. So in my case the memory is PC133 which is
133 MHz. So each clock cycle is 1/133 us? And, to delay for 3 clocks would
be 3/133 us = 22 ns?

-- 
Thanks,
Joseph Smith
Set-Top-Linux
www.settoplinux.org




From peter at stuge.se  Mon Jun  9 19:39:50 2008
From: peter at stuge.se (Peter Stuge)
Date: Mon, 9 Jun 2008 19:39:50 +0200
Subject: [coreboot] coreboot BIOSisms
In-Reply-To: <484D6727.1000304@amd.com>
References: <20080609033740.GA1161@morn.localdomain>
	<20080609170346.357.qmail@stuge.se> <484D6727.1000304@amd.com>
Message-ID: <20080609173950.1634.qmail@stuge.se>

On Mon, Jun 09, 2008 at 11:23:51AM -0600, Marc Jones wrote:
> > I still don't want coreboot to know about BIOS tables at all.
> > 
> > Alas, it already does, there is both PIR and ACPI.
> 
> Because they are required by Linux.

Wasn't that supposed to change though? Does anyone know what happened
with the x86 device tree?


> > Do we really want these BIOS tables to be created by coreboot?
> 
> probably.
> 
> > If yes, why shouldn't LegacyBIOS simply be included in coreboot?
> 
> maybe but legacybios has a lot of things coreboot (for Linux) doesn't
> need. They are required for other OS.

Yep, but it is so nice to optimize them away when running Linux.


> > I would much prefer if any and all table generation could be
> > handled by LegacyBIOS or maybe another, separate, payload. 
> 
> Then that payload has to have the knowledge of every cpu, chipset,
> and motherboard configuration to extract the information. That is
> difficult which is why the OS leaves it up the the BIOS. It make
> sense that the tables are generated and used by the configuration
> code.

We already have some if not all of this information in coreboot.
I think the ideal would be to allow payloads to use all that
information in a handy way, rather than only through BIOS tables.

Seems this is our hot potato.


//Peter



From peter at stuge.se  Mon Jun  9 19:47:24 2008
From: peter at stuge.se (Peter Stuge)
Date: Mon, 9 Jun 2008 19:47:24 +0200
Subject: [coreboot] Memory clock cycles -> microseconds (us)
In-Reply-To: <5f2490688d69840150eff2bf6cae68ea@imap.1and1.com>
References: <6066E9236D084E45A769DB5CBD67BFE6@smitty2m>
	<016901c8ca48$e6f19ff0$0023040a@chimp>
	<d1aebbcb3bb5f0a4c94f1994172d56f7@imap.1and1.com>
	<20080609171432.10656.qmail@stuge.se>
	<5f2490688d69840150eff2bf6cae68ea@imap.1and1.com>
Message-ID: <20080609174724.8458.qmail@stuge.se>

On Mon, Jun 09, 2008 at 01:36:29PM -0400, Joseph Smith wrote:
> >> >> Does anyone know the mathematical formula for converting memory
> >> >> clock cycles into microseconds (us)??
> >> >
> >> > 1 MHz means 1 million clock cycles per second, so 1 clock cycle
> >> > per microsecond.
> >> >
> >> > 166 MHz -> 166 clock cycles per microsecond.
> > 
> > The formula is: t=1/f
> > 
> > If f=1000000, each cycle is 1/1000000 seconds, or 1 microsecond.
> > If f=166000000, each cycle is 1/166000000 seconds, or 1/166 us = 6 ns
> 
> Ok, let me get this straight. So in my case the memory is PC133
> which is 133 MHz. So each clock cycle is 1/133 us? And, to delay for
> 3 clocks would be 3/133 us = 22 ns?

Yes sir, that's correct!


//Peter



From joe at settoplinux.org  Mon Jun  9 21:15:46 2008
From: joe at settoplinux.org (Joseph Smith)
Date: Mon, 09 Jun 2008 15:15:46 -0400
Subject: [coreboot] Memory clock cycles -> microseconds (us)
In-Reply-To: <20080609174724.8458.qmail@stuge.se>
References: <6066E9236D084E45A769DB5CBD67BFE6@smitty2m>
	<016901c8ca48$e6f19ff0$0023040a@chimp>
	<d1aebbcb3bb5f0a4c94f1994172d56f7@imap.1and1.com>
	<20080609171432.10656.qmail@stuge.se>
	<5f2490688d69840150eff2bf6cae68ea@imap.1and1.com>
	<20080609174724.8458.qmail@stuge.se>
Message-ID: <68b4773d604c80b4c26e160df2bf6bb1@imap.1and1.com>




On Mon, 9 Jun 2008 19:47:24 +0200, Peter Stuge <peter at stuge.se> wrote:
> On Mon, Jun 09, 2008 at 01:36:29PM -0400, Joseph Smith wrote:
>> >> >> Does anyone know the mathematical formula for converting memory
>> >> >> clock cycles into microseconds (us)??
>> >> >
>> >> > 1 MHz means 1 million clock cycles per second, so 1 clock cycle
>> >> > per microsecond.
>> >> >
>> >> > 166 MHz -> 166 clock cycles per microsecond.
>> >
>> > The formula is: t=1/f
>> >
>> > If f=1000000, each cycle is 1/1000000 seconds, or 1 microsecond.
>> > If f=166000000, each cycle is 1/166000000 seconds, or 1/166 us = 6 ns
>>
>> Ok, let me get this straight. So in my case the memory is PC133
>> which is 133 MHz. So each clock cycle is 1/133 us? And, to delay for
>> 3 clocks would be 3/133 us = 22 ns?
> 
> Yes sir, that's correct!
> 
> 
Ok then, that brings me to my next question. In alot of our raminit.c's we
use udelay() between the memory initialization steps. We could probably cut
the memory initialization time in half buy using nanoseconds instead or
microseconds.

How hard would it be to add a nanoseconds delay to delay.h?

-- 
Thanks,
Joseph Smith
Set-Top-Linux
www.settoplinux.org




From r.marek at assembler.cz  Mon Jun  9 21:50:30 2008
From: r.marek at assembler.cz (Rudolf Marek)
Date: Mon, 09 Jun 2008 21:50:30 +0200
Subject: [coreboot] memory init on ASUS M2V-MX  SE
Message-ID: <484D8986.2020107@assembler.cz>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hello all,

I'm trying to get the Asus M2V-MX SE working (K8T890/VT8237S) it has AM2 socket.
CPU is semperon model 127 fam f

Currently there is some problem with memory, I have attached the log.
I have no clue what might be wrong. The module is 512MB 533MHz single DDR2 with
CAS4. The FIDVID changing and fidvid setup is disabled, reset of HT is disabled.

It seems to fall down the drain on very same place.

Any clue? Maybe I have some options wrong? What should I check please?

I checked I2C reading and they are correct (I verified with EEPROM dump)

I dont understand why:
...
Setting variable MTRR 02, base: 0000MB, range: 0200MB, type WB
...

The range is only to 200MB ???

export MEM_TRAIN_SEQ:=0

I have no other DDR2 module to check.

Thanks,
Rudolf



-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFITYmF3J9wPJqZRNURAj/iAJ9wmNn9okVbF9Wn+xHNlTpfSBPrIQCfXqxG
e8VpRhnd12QDnPFxg4jRSWk=
=Sioj
-----END PGP SIGNATURE-----
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: m.txt
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20080609/fd4dd3b3/attachment.txt>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: m.txt.sig
Type: application/octet-stream
Size: 65 bytes
Desc: not available
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20080609/fd4dd3b3/attachment.obj>

From joe at settoplinux.org  Mon Jun  9 23:39:58 2008
From: joe at settoplinux.org (Joseph Smith)
Date: Mon, 09 Jun 2008 17:39:58 -0400
Subject: [coreboot] coreboot BIOSisms
In-Reply-To: <20080609173950.1634.qmail@stuge.se>
References: <20080609033740.GA1161@morn.localdomain>
	<20080609170346.357.qmail@stuge.se> <484D6727.1000304@amd.com>
	<20080609173950.1634.qmail@stuge.se>
Message-ID: <4bb72ded530ea9b586021f19cea6914e@imap.1and1.com>




On Mon, 9 Jun 2008 19:39:50 +0200, Peter Stuge <peter at stuge.se> wrote:
> On Mon, Jun 09, 2008 at 11:23:51AM -0600, Marc Jones wrote:
>> > I still don't want coreboot to know about BIOS tables at all.
>> >
>> > Alas, it already does, there is both PIR and ACPI.
>>
>> Because they are required by Linux.
> 
> Wasn't that supposed to change though? Does anyone know what happened
> with the x86 device tree?
> 
> 
>> > Do we really want these BIOS tables to be created by coreboot?
>>
>> probably.
>>
>> > If yes, why shouldn't LegacyBIOS simply be included in coreboot?
>>
>> maybe but legacybios has a lot of things coreboot (for Linux) doesn't
>> need. They are required for other OS.
> 
> Yep, but it is so nice to optimize them away when running Linux.

Thus making it a coreboot option for other OS's
> 
> 
>> > I would much prefer if any and all table generation could be
>> > handled by LegacyBIOS or maybe another, separate, payload.
>>
>> Then that payload has to have the knowledge of every cpu, chipset,
>> and motherboard configuration to extract the information. That is
>> difficult which is why the OS leaves it up the the BIOS. It make
>> sense that the tables are generated and used by the configuration
>> code.
> 
> We already have some if not all of this information in coreboot.
> I think the ideal would be to allow payloads to use all that
> information in a handy way, rather than only through BIOS tables.
> 
Why not just have it so legacybios just reads this info from coreboot and
creates the desired tables?

-- 
Thanks,
Joseph Smith
Set-Top-Linux
www.settoplinux.org




From peter at stuge.se  Mon Jun  9 23:40:51 2008
From: peter at stuge.se (Peter Stuge)
Date: Mon, 9 Jun 2008 23:40:51 +0200
Subject: [coreboot] memory init on ASUS M2V-MX  SE
In-Reply-To: <484D8986.2020107@assembler.cz>
References: <484D8986.2020107@assembler.cz>
Message-ID: <20080609214051.32334.qmail@stuge.se>

On Mon, Jun 09, 2008 at 09:50:30PM +0200, Rudolf Marek wrote:
> I dont understand why:
> ...
> Setting variable MTRR 02, base: 0000MB, range: 0200MB, type WB
> ...
> 
> The range is only to 200MB ???

I believe this is hex, so 512MB decimal.


> I have no other DDR2 module to check.

Could you test the same DIMM with coreboot on another K8 board?


//Peter



From peter at stuge.se  Mon Jun  9 23:43:10 2008
From: peter at stuge.se (Peter Stuge)
Date: Mon, 9 Jun 2008 23:43:10 +0200
Subject: [coreboot] Memory clock cycles -> microseconds (us)
In-Reply-To: <68b4773d604c80b4c26e160df2bf6bb1@imap.1and1.com>
References: <6066E9236D084E45A769DB5CBD67BFE6@smitty2m>
	<016901c8ca48$e6f19ff0$0023040a@chimp>
	<d1aebbcb3bb5f0a4c94f1994172d56f7@imap.1and1.com>
	<20080609171432.10656.qmail@stuge.se>
	<5f2490688d69840150eff2bf6cae68ea@imap.1and1.com>
	<20080609174724.8458.qmail@stuge.se>
	<68b4773d604c80b4c26e160df2bf6bb1@imap.1and1.com>
Message-ID: <20080609214310.1826.qmail@stuge.se>

On Mon, Jun 09, 2008 at 03:15:46PM -0400, Joseph Smith wrote:
> How hard would it be to add a nanoseconds delay to delay.h?

It would probably have to be a busy wait with compensation for
the current CPU frequency.


//Peter



From peter at stuge.se  Mon Jun  9 23:43:53 2008
From: peter at stuge.se (Peter Stuge)
Date: Mon, 9 Jun 2008 23:43:53 +0200
Subject: [coreboot] coreboot BIOSisms
In-Reply-To: <4bb72ded530ea9b586021f19cea6914e@imap.1and1.com>
References: <20080609033740.GA1161@morn.localdomain>
	<20080609170346.357.qmail@stuge.se> <484D6727.1000304@amd.com>
	<20080609173950.1634.qmail@stuge.se>
	<4bb72ded530ea9b586021f19cea6914e@imap.1and1.com>
Message-ID: <20080609214353.2290.qmail@stuge.se>

On Mon, Jun 09, 2008 at 05:39:58PM -0400, Joseph Smith wrote:
> >> > I would much prefer if any and all table generation could be
> >> > handled by LegacyBIOS or maybe another, separate, payload.
> >>
> >> Then that payload has to have the knowledge of every cpu, chipset,
> >> and motherboard configuration to extract the information. That is
> >> difficult which is why the OS leaves it up the the BIOS. It make
> >> sense that the tables are generated and used by the configuration
> >> code.
> > 
> > We already have some if not all of this information in coreboot.
> > I think the ideal would be to allow payloads to use all that
> > information in a handy way, rather than only through BIOS tables.
> 
> Why not just have it so legacybios just reads this info from
> coreboot and creates the desired tables?

Yes, that is exactly how I would like it to work.


//Peter



From joe at settoplinux.org  Mon Jun  9 23:48:11 2008
From: joe at settoplinux.org (Joseph Smith)
Date: Mon, 09 Jun 2008 17:48:11 -0400
Subject: [coreboot] Memory clock cycles -> microseconds (us)
In-Reply-To: <20080609214310.1826.qmail@stuge.se>
References: <6066E9236D084E45A769DB5CBD67BFE6@smitty2m>
	<016901c8ca48$e6f19ff0$0023040a@chimp>
	<d1aebbcb3bb5f0a4c94f1994172d56f7@imap.1and1.com>
	<20080609171432.10656.qmail@stuge.se>
	<5f2490688d69840150eff2bf6cae68ea@imap.1and1.com>
	<20080609174724.8458.qmail@stuge.se>
	<68b4773d604c80b4c26e160df2bf6bb1@imap.1and1.com>
	<20080609214310.1826.qmail@stuge.se>
Message-ID: <78c0c1e0f7cda9cea72482492aae9cd7@imap.1and1.com>




On Mon, 9 Jun 2008 23:43:10 +0200, Peter Stuge <peter at stuge.se> wrote:
> On Mon, Jun 09, 2008 at 03:15:46PM -0400, Joseph Smith wrote:
>> How hard would it be to add a nanoseconds delay to delay.h?
> 
> It would probably have to be a busy wait with compensation for
> the current CPU frequency.
> 
> 
I'm not sure what you mean, Peter?

-- 
Thanks,
Joseph Smith
Set-Top-Linux
www.settoplinux.org




From peter at stuge.se  Tue Jun 10 00:02:55 2008
From: peter at stuge.se (Peter Stuge)
Date: Tue, 10 Jun 2008 00:02:55 +0200
Subject: [coreboot] Memory clock cycles -> microseconds (us)
In-Reply-To: <78c0c1e0f7cda9cea72482492aae9cd7@imap.1and1.com>
References: <6066E9236D084E45A769DB5CBD67BFE6@smitty2m>
	<016901c8ca48$e6f19ff0$0023040a@chimp>
	<d1aebbcb3bb5f0a4c94f1994172d56f7@imap.1and1.com>
	<20080609171432.10656.qmail@stuge.se>
	<5f2490688d69840150eff2bf6cae68ea@imap.1and1.com>
	<20080609174724.8458.qmail@stuge.se>
	<68b4773d604c80b4c26e160df2bf6bb1@imap.1and1.com>
	<20080609214310.1826.qmail@stuge.se>
	<78c0c1e0f7cda9cea72482492aae9cd7@imap.1and1.com>
Message-ID: <20080609220255.16780.qmail@stuge.se>

On Mon, Jun 09, 2008 at 05:48:11PM -0400, Joseph Smith wrote:
> On Mon, 9 Jun 2008 23:43:10 +0200, Peter Stuge <peter at stuge.se> wrote:
> > On Mon, Jun 09, 2008 at 03:15:46PM -0400, Joseph Smith wrote:
> >> How hard would it be to add a nanoseconds delay to delay.h?
> > 
> > It would probably have to be a busy wait with compensation for
> > the current CPU frequency.
> 
> I'm not sure what you mean, Peter?

Busy wait is a loop of some number of NOP instructions, as opposed to
relying on some CPU peripheral such as a timer to signal elapsed
time. The number of NOP instructions has to be calculated from the
current CPU frequency.


//Peter



From r.marek at assembler.cz  Tue Jun 10 00:20:22 2008
From: r.marek at assembler.cz (Rudolf Marek)
Date: Tue, 10 Jun 2008 00:20:22 +0200
Subject: [coreboot] coreboot BIOSisms
In-Reply-To: <20080609214353.2290.qmail@stuge.se>
References: <20080609033740.GA1161@morn.localdomain>	<20080609170346.357.qmail@stuge.se>
	<484D6727.1000304@amd.com>	<20080609173950.1634.qmail@stuge.se>	<4bb72ded530ea9b586021f19cea6914e@imap.1and1.com>
	<20080609214353.2290.qmail@stuge.se>
Message-ID: <484DACA6.6010103@assembler.cz>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

> Yes, that is exactly how I would like it to work.

Sorry I think this is not possible due to ACPI bloatness. It would require ASL
compiler RUNTIME. And as Marc already wrote, the legacybios would need to know
lot a lot of details about each board. I would suggest to leave it as it is and
let the coreboot create the tables. If you dont like them, you can always
ignore/delete them (or not create if you are creating some OS which can do that)

Rudolf
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFITaym3J9wPJqZRNURAgUjAKCLJwUvhB9Xpy0KsIpcM9t1p25OIgCeOK+i
bQrrJ6ufd8eLQLSgmEdhXx8=
=bL2M
-----END PGP SIGNATURE-----



From r.marek at assembler.cz  Tue Jun 10 00:21:15 2008
From: r.marek at assembler.cz (Rudolf Marek)
Date: Tue, 10 Jun 2008 00:21:15 +0200
Subject: [coreboot] memory init on ASUS M2V-MX  SE
In-Reply-To: <20080609214051.32334.qmail@stuge.se>
References: <484D8986.2020107@assembler.cz>
	<20080609214051.32334.qmail@stuge.se>
Message-ID: <484DACDB.8080304@assembler.cz>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Peter Stuge wrote:
> On Mon, Jun 09, 2008 at 09:50:30PM +0200, Rudolf Marek wrote:
>> I dont understand why:
>> ...
>> Setting variable MTRR 02, base: 0000MB, range: 0200MB, type WB
>> ...
>>
>> The range is only to 200MB ???
> 
> I believe this is hex, so 512MB decimal.

Aha good catch.

> 
> 
>> I have no other DDR2 module to check.
> 
> Could you test the same DIMM with coreboot on another K8 board?

Hmm I dont have any other DDR2 board. I have only DDR board here. Maybe it is
some other problem, still dont know.

Rudolf
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFITazb3J9wPJqZRNURAutwAKC3s1+rQdcwm5g9lgu1Pw6fyazKwgCbBxV2
klAFOFKxC9MJWw3hM8pXJNw=
=5LEG
-----END PGP SIGNATURE-----



From r.marek at assembler.cz  Tue Jun 10 00:53:01 2008
From: r.marek at assembler.cz (Rudolf Marek)
Date: Tue, 10 Jun 2008 00:53:01 +0200
Subject: [coreboot] memory init on ASUS M2V-MX  SE
In-Reply-To: <484DACDB.8080304@assembler.cz>
References: <484D8986.2020107@assembler.cz>	<20080609214051.32334.qmail@stuge.se>
	<484DACDB.8080304@assembler.cz>
Message-ID: <484DB44D.9040903@assembler.cz>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi all,

Hum it seems that there is some watchdog somewhere, it resets the board even in
while (1) {} loop. It seems to take 4 seconds. The IT8712 seems to have one.
Will investigate further.

Rudolf
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFITbRN3J9wPJqZRNURAqztAKCeEv4RPNRvvd9Y4kV5Gd61zxAd1QCeKhh2
BFGbTCEJq4SzuAiLDPJ1amg=
=J5bn
-----END PGP SIGNATURE-----



From Marc.Jones at amd.com  Tue Jun 10 00:54:43 2008
From: Marc.Jones at amd.com (Marc Jones)
Date: Mon, 9 Jun 2008 16:54:43 -0600
Subject: [coreboot] memory init on ASUS M2V-MX  SE
In-Reply-To: <484D8986.2020107@assembler.cz>
References: <484D8986.2020107@assembler.cz>
Message-ID: <484DB4B3.50805@amd.com>

Rudolf Marek wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Hello all,
> 
> I'm trying to get the Asus M2V-MX SE working (K8T890/VT8237S) it has AM2 socket.
> CPU is semperon model 127 fam f

> I have no clue what might be wrong. The module is 512MB 533MHz single DDR2 with
> CAS4. 
> 
It is detecting the memory as 266MHz. Check why it doesn't do 533Mhz. 
Some kind of clock problem? Is the CPU clock ok?

> It seems to fall down the drain on very same place.
> 
Strange, I assume that the legacy bios works?

Marc


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




From peter at stuge.se  Tue Jun 10 01:29:52 2008
From: peter at stuge.se (Peter Stuge)
Date: Tue, 10 Jun 2008 01:29:52 +0200
Subject: [coreboot] memory init on ASUS M2V-MX  SE
In-Reply-To: <484DB44D.9040903@assembler.cz>
References: <484D8986.2020107@assembler.cz>
	<20080609214051.32334.qmail@stuge.se>
	<484DACDB.8080304@assembler.cz> <484DB44D.9040903@assembler.cz>
Message-ID: <20080609232952.20401.qmail@stuge.se>

On Tue, Jun 10, 2008 at 12:53:01AM +0200, Rudolf Marek wrote:
> Hum it seems that there is some watchdog somewhere, it resets the
> board even in while (1) {} loop. It seems to take 4 seconds. The
> IT8712 seems to have one. Will investigate further.

4 seconds reminds me of the hardware power switch timeout.


//Peter



From Marc.Jones at amd.com  Tue Jun 10 00:56:23 2008
From: Marc.Jones at amd.com (Marc Jones)
Date: Mon, 09 Jun 2008 16:56:23 -0600
Subject: [coreboot] memory init on ASUS M2V-MX  SE
In-Reply-To: <484DB44D.9040903@assembler.cz>
References: <484D8986.2020107@assembler.cz>	<20080609214051.32334.qmail@stuge.se>	<484DACDB.8080304@assembler.cz>
	<484DB44D.9040903@assembler.cz>
Message-ID: <484DB517.7060109@amd.com>

Rudolf Marek wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Hi all,
> 
> Hum it seems that there is some watchdog somewhere, it resets the board even in
> while (1) {} loop. It seems to take 4 seconds. The IT8712 seems to have one.
> Will investigate further.
> 

Ah, I was going to say that but expected it to be through memory init 
within 4seconds. Look for a power button debounce 4seconds could come 
from an ACPI style power button or a true watchdog.

Marc



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




From joe at settoplinux.org  Tue Jun 10 03:26:09 2008
From: joe at settoplinux.org (Joseph Smith)
Date: Mon, 9 Jun 2008 21:26:09 -0400
Subject: [coreboot] coreboot BIOSisms
In-Reply-To: <484DACA6.6010103@assembler.cz>
References: <20080609033740.GA1161@morn.localdomain>	<20080609170346.357.qmail@stuge.se><484D6727.1000304@amd.com>	<20080609173950.1634.qmail@stuge.se>	<4bb72ded530ea9b586021f19cea6914e@imap.1and1.com><20080609214353.2290.qmail@stuge.se>
	<484DACA6.6010103@assembler.cz>
Message-ID: <BBE6D4BA788C4B83B9B4C48E3FE09E7D@smitty2m>



> -----Original Message-----
> From: coreboot-bounces at coreboot.org [mailto:coreboot-bounces at coreboot.org]
> On Behalf Of Rudolf Marek
> Sent: Monday, June 09, 2008 6:20 PM
> To: coreboot at coreboot.org
> Subject: Re: [coreboot] coreboot BIOSisms
> 
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> > Yes, that is exactly how I would like it to work.
> 
> Sorry I think this is not possible due to ACPI bloatness. It would require
> ASL
> compiler RUNTIME. And as Marc already wrote, the legacybios would need to
> know
> lot a lot of details about each board. I would suggest to leave it as it
> is and
> let the coreboot create the tables. If you dont like them, you can always
> ignore/delete them (or not create if you are creating some OS which can do
> that)
> 
Couldn't we just add a little mini program in between the two that is just
responsible for reporting all of the necessary data from coreboot to
legacybios?

Thanks,
Joseph Smith
Set-Top-Linux
www.settoplinux.org




From joe at settoplinux.org  Tue Jun 10 03:37:45 2008
From: joe at settoplinux.org (Joseph Smith)
Date: Mon, 9 Jun 2008 21:37:45 -0400
Subject: [coreboot] Memory clock cycles -> microseconds (us)
In-Reply-To: <20080609220255.16780.qmail@stuge.se>
References: <6066E9236D084E45A769DB5CBD67BFE6@smitty2m><016901c8ca48$e6f19ff0$0023040a@chimp><d1aebbcb3bb5f0a4c94f1994172d56f7@imap.1and1.com><20080609171432.10656.qmail@stuge.se><5f2490688d69840150eff2bf6cae68ea@imap.1and1.com><20080609174724.8458.qmail@stuge.se><68b4773d604c80b4c26e160df2bf6bb1@imap.1and1.com><20080609214310.1826.qmail@stuge.se><78c0c1e0f7cda9cea72482492aae9cd7@imap.1and1.com>
	<20080609220255.16780.qmail@stuge.se>
Message-ID: <8F203E1E145D40DD969C76CDC34B5771@smitty2m>




> -----Original Message-----
> From: coreboot-bounces at coreboot.org [mailto:coreboot-bounces at coreboot.org]
> On Behalf Of Peter Stuge
> Sent: Monday, June 09, 2008 6:03 PM
> To: coreboot at coreboot.org
> Subject: Re: [coreboot] Memory clock cycles -> microseconds (us)
> 
> On Mon, Jun 09, 2008 at 05:48:11PM -0400, Joseph Smith wrote:
> > On Mon, 9 Jun 2008 23:43:10 +0200, Peter Stuge <peter at stuge.se> wrote:
> > > On Mon, Jun 09, 2008 at 03:15:46PM -0400, Joseph Smith wrote:
> > >> How hard would it be to add a nanoseconds delay to delay.h?
> > >
> > > It would probably have to be a busy wait with compensation for
> > > the current CPU frequency.
> >
> > I'm not sure what you mean, Peter?
> 
> Busy wait is a loop of some number of NOP instructions, as opposed to
> relying on some CPU peripheral such as a timer to signal elapsed
> time. The number of NOP instructions has to be calculated from the
> current CPU frequency.
> 
> 
That seems more complicated than it needs to be. Here is what I am thinking:
JEDEC specifies what the wait/delay is supposed to be between memory
initialization steps. They specify/measure these in memory clock cycles.
Currently we just guess, and round up in microseconds (us) (I guess it is
better to wait too long than not enough). But, even if we wait 1/2 a
microsecond or more than needed on each step, That's 3 or 4 microseconds
longer than needed. See where I am going with this?

Thanks,
Joseph Smith
Set-Top-Linux
www.settoplinux.org




From rminnich at gmail.com  Tue Jun 10 03:54:45 2008
From: rminnich at gmail.com (ron minnich)
Date: Mon, 9 Jun 2008 18:54:45 -0700
Subject: [coreboot] filo-0.5 compilation issues
In-Reply-To: <AA28F077645B324881335614E4F7C428034DC5@win-ex01.bench.com>
References: <AA28F077645B324881335614E4F7C428034DC5@win-ex01.bench.com>
Message-ID: <13426df10806091854n135f0e1au533ac9211b722dc7@mail.gmail.com>

gcc -m32 -Wall -Os -fomit-frame-pointer -fno-common -ffreestanding
-fno-strict-aliasing -Wno-unused  -nostdinc -imacros ../config.h
-I../include -I/usr/lib/gcc/i486-linux-gnu/4.1.2/include -MD -c printf.c
-o printf.o

What does this with -E show? This is really weird.

ron



From kevin at koconnor.net  Tue Jun 10 04:18:35 2008
From: kevin at koconnor.net (Kevin O'Connor)
Date: Mon, 9 Jun 2008 22:18:35 -0400
Subject: [coreboot] coreboot BIOSisms
In-Reply-To: <20080609170346.357.qmail@stuge.se>
References: <20080609033740.GA1161@morn.localdomain>
	<20080609170346.357.qmail@stuge.se>
Message-ID: <20080610021835.GA5498@morn.localdomain>

On Mon, Jun 09, 2008 at 07:03:46PM +0200, Peter Stuge wrote:
> On Sun, Jun 08, 2008 at 11:37:40PM -0400, Kevin O'Connor wrote:
> > http://www.coreboot.org/pipermail/coreboot/2008-May/034688.html
> > 
> > I'm basically advocating option (c).
> 
> Do we really want these BIOS tables to be created by coreboot?
> 
> If yes, why shouldn't LegacyBIOS simply be included in coreboot?
> 
> If no, how can we fix that?

Hi Peter,

I'm torn on this question myself.  I can see both sides of the issue.

I do think there are some high-level requirements:

* These tables (PIR, mptable, acpi, smbios) need to be generated one
  way or another.  All the major OSs in use today need them - a
  machine that can not run all the major OSs is at a distinct
  disadvantage in the market place.

* It is a bad idea to force legacybios (or any payload) to be board
  specific.  Doing so would require vendors to commit code to multiple
  repos.  It would fragment the development efforts and lead to
  confusion.

* Most of the info in the tables can not be reasonably auto-detected
  by the payload.  Thus, one way or another, the info needs to be
  passed into them.

* It makes no sense to have coreboot export info in a coreboot
  specific format if that info is used purely by the payload to export
  it in a different format.  For example, consider the smbios "system
  enclosure" table - neither coreboot nor legacybios have any need to
  know how many power cords are attached to the machine.  Making a
  coreboot "num power cords" field just so legacybios can translate
  that to the smbios field is a waste.  (There are plenty of these
  information fields - take a look at the acpi and smbios specs.)

Given the above, I see two possibilities.

The first involves having coreboot build the standard tables.  As was
discussed, this exposes coreboot to some ugliness.

The second would involve passing a few key pieces of info to the
payload and then have the payload build the tables with just the bare
minimum amount of data.  This is what bochs/qemu do today, and it
seems to work reasonably well.  Most of the fields seem pointless
anyway - for example, I can't imagine why an app would care how many
power cords the machine had - and if it did care, I can't imagine it
would trust the bios.

Unfortunately, one big issue with option two is that there is no good
way to pass these ad-hoc values to the payload today.  Some of the
larger blobs (eg, the AML code) could be put into a lar segment.
However, v2 doesn't support LAR.  Many of the smaller fields (eg, num
cpus, uuid, apic address) are too ad-hoc and numerous to pass via
coreboot tables. (And again, why define a new coreboot table if we can
reuse an already defined acpi/mptable table?)

I'm open to ideas.

-Kevin



From peter at stuge.se  Tue Jun 10 05:37:46 2008
From: peter at stuge.se (Peter Stuge)
Date: Tue, 10 Jun 2008 05:37:46 +0200
Subject: [coreboot] Memory clock cycles -> microseconds (us)
In-Reply-To: <8F203E1E145D40DD969C76CDC34B5771@smitty2m>
References: <20080609220255.16780.qmail@stuge.se>
	<8F203E1E145D40DD969C76CDC34B5771@smitty2m>
Message-ID: <20080610033746.23405.qmail@stuge.se>

On Mon, Jun 09, 2008 at 09:37:45PM -0400, Joseph Smith wrote:
> See where I am going with this?

Sorry, not at all.

Of course it would be nice to not spend more time than neccessary
on waits during RAM init.

But nanosecond precision is more difficult than microsecond
precision, and unless there are on the order of 1000 or 10000 delays
where we wait microseconds instead of nanoseconds I don't think it is
a worthwhile optimization.


//Peter



From tsylla at gmail.com  Tue Jun 10 07:02:45 2008
From: tsylla at gmail.com (Tom Sylla)
Date: Tue, 10 Jun 2008 01:02:45 -0400
Subject: [coreboot] Memory clock cycles -> microseconds (us)
In-Reply-To: <8F203E1E145D40DD969C76CDC34B5771@smitty2m>
References: <6066E9236D084E45A769DB5CBD67BFE6@smitty2m><016901c8ca48$e6f19ff0$0023040a@chimp><d1aebbcb3bb5f0a4c94f1994172d56f7@imap.1and1.com><20080609171432.10656.qmail@stuge.se><5f2490688d69840150eff2bf6cae68ea@imap.1and1.com><20080609174724.8458.qmail@stuge.se><68b4773d604c80b4c26e160df2bf6bb1@imap.1and1.com><20080609214310.1826.qmail@stuge.se><78c0c1e0f7cda9cea72482492aae9cd7@imap.1and1.com>	<20080609220255.16780.qmail@stuge.se>
	<8F203E1E145D40DD969C76CDC34B5771@smitty2m>
Message-ID: <484E0AF5.9040908@gmail.com>

>> Busy wait is a loop of some number of NOP instructions, as opposed to
>> relying on some CPU peripheral such as a timer to signal elapsed
>> time. The number of NOP instructions has to be calculated from the
>> current CPU frequency.
>>
>>
> That seems more complicated than it needs to be. Here is what I am thinking:
> JEDEC specifies what the wait/delay is supposed to be between memory
> initialization steps. They specify/measure these in memory clock cycles.
> Currently we just guess, and round up in microseconds (us) (I guess it is
> better to wait too long than not enough). But, even if we wait 1/2 a
> microsecond or more than needed on each step, That's 3 or 4 microseconds
> longer than needed. See where I am going with this?

It really can't be less complicated, but a lot of the work is already 
done. Take a look at delay_tsc.c, which uses the tsc for delays (which 
is a little bit nicer than counting NOPs) It does the tsc calibration 
vs. the PIT (or even vs. port 80s) to get the CPU frequency. delay_tsc 
has udelay now, but could reasonably easily have ndelay too. Precision 
in the 10s of ns should be possible.

Peter's point is that it probably does not matter too much. Even if you 
rounded up 5 individual delays to 1 usec each, that is only 5us. You can 
reclaim a lot of it, but it may be more work than it is worth.





From wharms at bfs.de  Tue Jun 10 09:54:37 2008
From: wharms at bfs.de (walter harms)
Date: Tue, 10 Jun 2008 09:54:37 +0200
Subject: [coreboot] flashrom and list of computers
In-Reply-To: <48495077.30102@gmx.net>
References: <48481E64.3000903@bfs.de>
	<484832E8.6030002@onelabs.com>	<4848E2DC.3000801@bfs.de>
	<484936E5.20208@openhardware.de> <48493E6E.9040608@gmx.net>
	<48494D0A.5090404@bfs.de> <48495077.30102@gmx.net>
Message-ID: <484E333D.2060204@bfs.de>



>> Next question: who will write that script ?
>>   
> 
> I wrote such a script a few months ago and sent it to the list.


can you send me that script ?

re,
 wh



From joe at settoplinux.org  Tue Jun 10 12:37:18 2008
From: joe at settoplinux.org (Joseph Smith)
Date: Tue, 10 Jun 2008 06:37:18 -0400
Subject: [coreboot] Memory clock cycles -> microseconds (us)
In-Reply-To: <20080610033746.23405.qmail@stuge.se>
References: <20080609220255.16780.qmail@stuge.se>
	<8F203E1E145D40DD969C76CDC34B5771@smitty2m>
	<20080610033746.23405.qmail@stuge.se>
Message-ID: <72c9a4c642c745eed4df462723256832@imap.1and1.com>




On Tue, 10 Jun 2008 05:37:46 +0200, Peter Stuge <peter at stuge.se> wrote:
> On Mon, Jun 09, 2008 at 09:37:45PM -0400, Joseph Smith wrote:
>> See where I am going with this?
> 
> Sorry, not at all.
> 
> Of course it would be nice to not spend more time than neccessary
> on waits during RAM init.
> 
> But nanosecond precision is more difficult than microsecond
> precision, and unless there are on the order of 1000 or 10000 delays
> where we wait microseconds instead of nanoseconds I don't think it is
> a worthwhile optimization.
> 
> 
> Peter's point is that it probably does not matter too much. Even if you
> rounded up 5 individual delays to 1 usec each, that is only 5us. You can
> reclaim a lot of it, but it may be more work than it is worth.

Ok, nevermind then. I just thought it would be something to speed up the
boot process even more.

-- 
Thanks,
Joseph Smith
Set-Top-Linux
www.settoplinux.org




From darmawan.salihun at gmail.com  Tue Jun 10 12:38:59 2008
From: darmawan.salihun at gmail.com (Darmawan Salihun)
Date: Tue, 10 Jun 2008 17:38:59 +0700
Subject: [coreboot] flashrom and list of computers
In-Reply-To: <48498B37.7030801@coresystems.de>
References: <48481E64.3000903@bfs.de> <484832E8.6030002@onelabs.com>
	<4848E2DC.3000801@bfs.de> <48494044.4020402@gmx.net>
	<48494FF8.50309@bfs.de> <4849540B.6000708@gmx.net>
	<48498B37.7030801@coresystems.de>
Message-ID: <46893e740806100338u6a6f4be1m3f3d2c7c34bd5150@mail.gmail.com>

On Sat, Jun 7, 2008 at 2:08 AM, Stefan Reinauer <stepan at coresystems.de> wrote:
> Carl-Daniel Hailfinger wrote:
>> Hi,
>>
>> does anybody have an idea what to do if ICH6 BIOS Lock is enabled and
>> BIOS Write is disabled? Removing the lock bit seems to fail according to
>> flashrom.
> Yes, put a magic signature somewhere, go to S3 and wake up again.

I read about this method somewhere in Phoenix BIOS Windows flash utility
 documentation a few years ago. But, not sure yet whether it's reliable enough.

Have you test it? or is it already integrated in current flashrom?

>
> 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
>
>
> --
> coreboot mailing list
> coreboot at coreboot.org
> http://www.coreboot.org/mailman/listinfo/coreboot



-- 
Regards,

Darmawan Salihun
--------------------------------------------------------------------
-= Human knowledge belongs to the world =-



From joe at settoplinux.org  Tue Jun 10 14:46:07 2008
From: joe at settoplinux.org (Joseph Smith)
Date: Tue, 10 Jun 2008 08:46:07 -0400
Subject: [coreboot] coreboot BIOSisms
In-Reply-To: <20080610021835.GA5498@morn.localdomain>
References: <20080609033740.GA1161@morn.localdomain>
	<20080609170346.357.qmail@stuge.se>
	<20080610021835.GA5498@morn.localdomain>
Message-ID: <8a5e5d330d5bb633f537e6dd718f8ef7@imap.1and1.com>


> Given the above, I see two possibilities.
> 
> The first involves having coreboot build the standard tables.

Like I said why not just have a mini program between the two that handles
this operation. It could be added to coreboot or legacybios as an option
module. The mini program would read the coreboot tables and what ever else
it needed and then set these tables up in a format that coresponds with
legacybios, and finally passes the tables to legacybios. Does it have to be
more complicated than that?

-- 
Thanks,
Joseph Smith
Set-Top-Linux
www.settoplinux.org




From stepan at coresystems.de  Tue Jun 10 16:28:54 2008
From: stepan at coresystems.de (Stefan Reinauer)
Date: Tue, 10 Jun 2008 16:28:54 +0200
Subject: [coreboot] coreboot BIOSisms
In-Reply-To: <8a5e5d330d5bb633f537e6dd718f8ef7@imap.1and1.com>
References: <20080609033740.GA1161@morn.localdomain>	<20080609170346.357.qmail@stuge.se>	<20080610021835.GA5498@morn.localdomain>
	<8a5e5d330d5bb633f537e6dd718f8ef7@imap.1and1.com>
Message-ID: <484E8FA6.4010307@coresystems.de>

Joseph Smith wrote:
>> Given the above, I see two possibilities.
>>
>> The first involves having coreboot build the standard tables.
>>     
>
> Like I said why not just have a mini program between the two that handles
> this operation. It could be added to coreboot or legacybios as an option
> module. The mini program would read the coreboot tables and what ever else
> it needed and then set these tables up in a format that coresponds with
> legacybios, and finally passes the tables to legacybios. Does it have to be
> more complicated than that?
>   

Why not have one or the other do it, thus saving another instance with
knowledge around?


-- 
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 r.marek at assembler.cz  Tue Jun 10 17:33:29 2008
From: r.marek at assembler.cz (Rudolf Marek)
Date: Tue, 10 Jun 2008 17:33:29 +0200
Subject: [coreboot] coreboot BIOSisms
In-Reply-To: <8a5e5d330d5bb633f537e6dd718f8ef7@imap.1and1.com>
References: <20080609033740.GA1161@morn.localdomain>	<20080609170346.357.qmail@stuge.se>	<20080610021835.GA5498@morn.localdomain>
	<8a5e5d330d5bb633f537e6dd718f8ef7@imap.1and1.com>
Message-ID: <484E9EC9.9090408@assembler.cz>


> Like I said why not just have a mini program between the two that handles
> this operation. It could be added to coreboot or legacybios as an option
> module. The mini program would read the coreboot tables and what ever else
> it needed and then set these tables up in a format that coresponds with
> legacybios, and finally passes the tables to legacybios. Does it have to be
> more complicated than that?
>   
Yes if ACPI is involved. Please do try to get ACPI support working for 
your board. Or look at least on DSDT table
from the "normal" BIOS. The whole thing with ACPI is not matter of 
simple tables. ACPI needs to know
a LOT about the BOARD, CHIPSET, CPU. You cant have that in separate 
payload. It is not matter to re-invent all the tables.
ACPI contains its own bytecode, what are you suggesting is building in a 
runtime compiler for the the tables, not
telling about the source code for the tables ;)

This is the reason why I really want to have this in coreboot. If you 
dont like it do not compile it in.

Rudolf





From joe at settoplinux.org  Tue Jun 10 18:40:21 2008
From: joe at settoplinux.org (Joseph Smith)
Date: Tue, 10 Jun 2008 12:40:21 -0400
Subject: [coreboot] coreboot BIOSisms
In-Reply-To: <484E8FA6.4010307@coresystems.de>
References: <20080609033740.GA1161@morn.localdomain>	<20080609170346.357.qmail@stuge.se>	<20080610021835.GA5498@morn.localdomain>
	<8a5e5d330d5bb633f537e6dd718f8ef7@imap.1and1.com>
	<484E8FA6.4010307@coresystems.de>
Message-ID: <555a0abe612587b0720552dbf1a9256c@imap.1and1.com>




On Tue, 10 Jun 2008 16:28:54 +0200, Stefan Reinauer <stepan at coresystems.de>
wrote:
> Joseph Smith wrote:
>>> Given the above, I see two possibilities.
>>>
>>> The first involves having coreboot build the standard tables.
>>>
>>
>> Like I said why not just have a mini program between the two that
> handles
>> this operation. It could be added to coreboot or legacybios as an option
>> module. The mini program would read the coreboot tables and what ever
> else
>> it needed and then set these tables up in a format that coresponds with
>> legacybios, and finally passes the tables to legacybios. Does it have to
> be
>> more complicated than that?
>>
> 
> Why not have one or the other do it, thus saving another instance with
> knowledge around?
> 
Yup one or the other...

-- 
Thanks,
Joseph Smith
Set-Top-Linux
www.settoplinux.org




From wtogami at redhat.com  Tue Jun 10 18:47:38 2008
From: wtogami at redhat.com (Warren Togami)
Date: Tue, 10 Jun 2008 12:47:38 -0400
Subject: [coreboot] [patch] mkelfimage intelligent placement of ramdisk
Message-ID: <484EB02A.5080305@redhat.com>

The attached patch by Peter Jones <pjones at redhat.com> implements 
intelligent placement of the ramdisk in memory during boot of an ELF 
image created by mkelfimage.

mkelfimage prior to this patch defaults to a hardcoded 1MB which doesn't 
quite work in all circumstances.  The kernel as it is decompressed can 
overwrite part of the ramdisk.  Peter says that pretty much all other 
boot loaders already do this intelligent detection instead of native 
hard coding.

This patch allows a wrapped Fedora i586 kernel to boot on both KVM and 
Artec Group's Thincan DBE61C (coreboot).  It probably needs more testing 
in other circumstances.

Thanks,
Warren Togami
wtogami at redhat.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: mkelfImage-2.7-ramdisk_base.patch
Type: text/x-patch
Size: 2598 bytes
Desc: not available
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20080610/e5a1af93/attachment.patch>

From marekpenther at aol.com  Tue Jun 10 18:49:22 2008
From: marekpenther at aol.com (Marek Artur Penther)
Date: Tue, 10 Jun 2008 18:49:22 +0200
Subject: [coreboot] AMD751, AMD756, AMD761, AMD762, AMD766, AMD768,
	VIA VT82C686(A/B), VIA VT8231, VIA VT8235
Message-ID: <200806101849.22441.marekpenther@aol.com>

I still looking for support for this devices:
Northbidges:
AMD751, AMD761, AMD762
Southbridges:
AMD756, AMD766, AMD768, VIA VT82C686(A/B), VIA VT8231, VIA VT8235
I have some Motherboards with AMD751 and AMD761 Northbridges, and I looking 
for Motherboard with AMD762+AMD766 or AMD762+AMD768. AMD762 is Northbridge 
with support for SMP, so coreboot should also support SMP for this platform. 
Is there man who can write support for these devices? I can not, because I 
just started with programming, so I can not write so complicated code. I 
still waiting for this and this do not came, so I wrote, because I think 
maybe no one will write it, because there are to less Motherboards with these 
devices.



From peter at stuge.se  Tue Jun 10 19:16:41 2008
From: peter at stuge.se (Peter Stuge)
Date: Tue, 10 Jun 2008 19:16:41 +0200
Subject: [coreboot] [patch] mkelfimage intelligent placement of ramdisk
In-Reply-To: <484EB02A.5080305@redhat.com>
References: <484EB02A.5080305@redhat.com>
Message-ID: <20080610171641.13215.qmail@stuge.se>

On Tue, Jun 10, 2008 at 12:47:38PM -0400, Warren Togami wrote:
> The attached patch by Peter Jones <pjones at redhat.com> implements 
> intelligent placement of the ramdisk in memory during boot of an
> ELF image created by mkelfimage.

I appreciate this patch!

But can you (or Peter) please describe the algorithm in english?

I don't like a commit message that claims code to be intelligent.. :p


> This patch allows a wrapped Fedora i586 kernel to boot on both KVM
> and Artec Group's Thincan DBE61C (coreboot).  It probably needs
> more testing in other circumstances.

Thanks again for the patch. See below for some comments.


> diff -up mkelfImage-2.7/linux-i386/convert_params.c.ramdisk_base mkelfImage-2.7/linux-i386/convert_params.c
> --- mkelfImage-2.7/linux-i386/convert_params.c.ramdisk_base	2006-03-27 18:44:59.000000000 -0500
> +++ mkelfImage-2.7/linux-i386/convert_params.c	2008-05-21 12:55:44.000000000 -0400
> @@ -1301,6 +1301,44 @@ static void query_firmware_values(struct
>  	
>  }
>  
> +static void relocate_ramdisk(struct param_info *info)
> +{
> +	struct e820entry *e820_map;
> +	struct e820entry *highest = 0;
> +	unsigned long load_addr;
> +	int i;
> +
> +	e820_map = info->real_mode->e820_map;
> +#if 0
> +	printf("initrd_start = 0x%lx\n", info->real_mode->initrd_start);
> +	printf("real_mode->e820_map_nr: %d\n", info->real_mode->e820_map_nr);
> +#endif

I think these debugging messages should either be hooked to some
verbose option or simply removed.


> +	for (i = 0; i < info->real_mode->e820_map_nr; i++) {
> +		if (e820_map[i].type != E820_RAM)
> +			continue;
> +#if 0
> +		printf("addr: 0x%lx len: %x\n", e820_map[i].addr, e820_map[i].size);
> +#endif

..as should this.


> +		if (highest && e820_map[i].addr < highest->addr)
> +			continue;
> +		if (e820_map[i].size < info->real_mode->initrd_size)
> +			continue;

Find the highest free RAM block in the e820 map which is big enough to
hold the initrd..


> +		if (e820_map[i].addr + info->real_mode->initrd_size >= 0x38000000)
> +			continue;

..what is this 3.5MB limit about? Also might this condition be
sensitive to an overflow error?


> +		highest = &e820_map[i];
> +	}
> +
> +	if (highest == 0)
> +		return;
> +
> +	load_addr = highest->addr + highest->size;
> +	load_addr -= info->real_mode->initrd_size;
> +	load_addr &= ~0xfffUL;

Load the initrd to the top of this RAM block on a 4k boundary.


> +
> +	memcpy((void *)load_addr, (void *)info->real_mode->initrd_start, info->real_mode->initrd_size);
> +	printf("relocating ramdisk to 0x%lx\n", load_addr);
> +	info->real_mode->initrd_start = load_addr;
> +}
>  /*
>   * Debug
>   * =============================================================================
> @@ -1533,6 +1571,10 @@ void *convert_params(unsigned type, void
>  	query_firmware_class(&info);
>  	query_firmware_values(&info);
>  	query_bootloader_values(&info);
> +	if (info.real_mode->initrd_size) {
> +		/* Make sure the initrd is in a relatively safe place. */
> +		relocate_ramdisk(&info);
> +	}
>  
>  	/* Do the hardware setup that linux might forget... */
>  	hardware_setup(&info);
> diff -up mkelfImage-2.7/linux-i386/mkelf-linux-i386.c.ramdisk_base mkelfImage-2.7/linux-i386/mkelf-linux-i386.c
> --- mkelfImage-2.7/linux-i386/mkelf-linux-i386.c.ramdisk_base	2006-03-17 09:08:22.000000000 -0500
> +++ mkelfImage-2.7/linux-i386/mkelf-linux-i386.c	2008-05-21 10:47:42.000000000 -0400
> @@ -352,6 +352,9 @@ int linux_i386_mkelf(int argc, char **ar
>  	 */
>  	params->initrd_start = params->initrd_size = 0;
>  	if (ramdisk_size) {
> +		while (ramdisk_base <= kernel_size)
> +			ramdisk_base <<= 1;
> +

Does this start with 1MB, then try 2MB, 4MB and so on?


>  		phdr[index].p_paddr  = ramdisk_base;
>  		phdr[index].p_vaddr  = ramdisk_base;
>  		phdr[index].p_filesz = ramdisk_size;


Please keep in mind to also include Signed-off-by: lines from all who
have touched the patch. Please see
http://www.coreboot.org/Development_Guidelines#Sign-off_Procedure

Thanks again for your contribution!


//Peter



From joe at settoplinux.org  Tue Jun 10 19:20:32 2008
From: joe at settoplinux.org (Joseph Smith)
Date: Tue, 10 Jun 2008 13:20:32 -0400
Subject: [coreboot] coreboot BIOSisms
In-Reply-To: <484E9EC9.9090408@assembler.cz>
References: <20080609033740.GA1161@morn.localdomain>	<20080609170346.357.qmail@stuge.se>	<20080610021835.GA5498@morn.localdomain>
	<8a5e5d330d5bb633f537e6dd718f8ef7@imap.1and1.com>
	<484E9EC9.9090408@assembler.cz>
Message-ID: <e0d27d385414bccfb46f4522fea8694c@imap.1and1.com>




On Tue, 10 Jun 2008 17:33:29 +0200, Rudolf Marek <r.marek at assembler.cz>
wrote:
> 
>> Like I said why not just have a mini program between the two that
> handles
>> this operation. It could be added to coreboot or legacybios as an option
>> module. The mini program would read the coreboot tables and what ever
> else
>> it needed and then set these tables up in a format that coresponds with
>> legacybios, and finally passes the tables to legacybios. Does it have to
> be
>> more complicated than that?
>>
> Yes if ACPI is involved. Please do try to get ACPI support working for
> your board. Or look at least on DSDT table
> from the "normal" BIOS. The whole thing with ACPI is not matter of
> simple tables. ACPI needs to know
> a LOT about the BOARD, CHIPSET, CPU. You cant have that in separate
> payload. It is not matter to re-invent all the tables.
> ACPI contains its own bytecode, what are you suggesting is building in a
> runtime compiler for the the tables, not
> telling about the source code for the tables ;)
>
Correct me if I am wrong, currently we don't create the ACPI tables. We
just use a hex version from the original bios correct? Why not just pass
this along to legacybios and covert it if needed?
> 
> This is the reason why I really want to have this in coreboot. If you
> dont like it do not compile it in.
> 
That's why I think we should just make it an option module.


-- 
Thanks,
Joseph Smith
Set-Top-Linux
www.settoplinux.org




From joe at settoplinux.org  Tue Jun 10 19:22:12 2008
From: joe at settoplinux.org (Joseph Smith)
Date: Tue, 10 Jun 2008 13:22:12 -0400
Subject: [coreboot] [patch] mkelfimage intelligent placement of ramdisk
In-Reply-To: <484EB02A.5080305@redhat.com>
References: <484EB02A.5080305@redhat.com>
Message-ID: <110db31c21b1e26e224cea0f30345b9b@imap.1and1.com>




On Tue, 10 Jun 2008 12:47:38 -0400, Warren Togami <wtogami at redhat.com>
wrote:
> The attached patch by Peter Jones <pjones at redhat.com> implements
> intelligent placement of the ramdisk in memory during boot of an ELF
> image created by mkelfimage.
> 
> mkelfimage prior to this patch defaults to a hardcoded 1MB which doesn't
> quite work in all circumstances.  The kernel as it is decompressed can
> overwrite part of the ramdisk.  Peter says that pretty much all other
> boot loaders already do this intelligent detection instead of native
> hard coding.
> 
> This patch allows a wrapped Fedora i586 kernel to boot on both KVM and
> Artec Group's Thincan DBE61C (coreboot).  It probably needs more testing
> in other circumstances.
> 
Cool. Good work!
-- 
Thanks,
Joseph Smith
Set-Top-Linux
www.settoplinux.org




From wtogami at redhat.com  Tue Jun 10 21:49:06 2008
From: wtogami at redhat.com (Warren Togami)
Date: Tue, 10 Jun 2008 15:49:06 -0400
Subject: [coreboot] [patch] mkelfimage intelligent placement of ramdisk
In-Reply-To: <20080610171641.13215.qmail@stuge.se>
References: <484EB02A.5080305@redhat.com> <20080610171641.13215.qmail@stuge.se>
Message-ID: <484EDAB2.1060701@redhat.com>

Peter Stuge wrote:
> On Tue, Jun 10, 2008 at 12:47:38PM -0400, Warren Togami wrote:
>> The attached patch by Peter Jones <pjones at redhat.com> implements 
>> intelligent placement of the ramdisk in memory during boot of an
>> ELF image created by mkelfimage.
> 
> I appreciate this patch!
> 
> But can you (or Peter) please describe the algorithm in english?
> 
> I don't like a commit message that claims code to be intelligent.. :p

I personally don't understand the algorithm beyond your interpretation.

Peter explained only a few bits below.  Lots of this algorithm is simply 
how other bootloaders have worked for years.  This was just a simple way 
to implement something known to work.

In any case it is certainly better than the previous hard coded value.

I hope others test this patch so we can be certain it doesn't break 
anyone where it previously worked.  It shouldn't.

> 
>> diff -up mkelfImage-2.7/linux-i386/convert_params.c.ramdisk_base mkelfImage-2.7/linux-i386/convert_params.c
>> --- mkelfImage-2.7/linux-i386/convert_params.c.ramdisk_base	2006-03-27 18:44:59.000000000 -0500
>> +++ mkelfImage-2.7/linux-i386/convert_params.c	2008-05-21 12:55:44.000000000 -0400
>> @@ -1301,6 +1301,44 @@ static void query_firmware_values(struct
>>  	
>>  }
>>  
>> +static void relocate_ramdisk(struct param_info *info)
>> +{
>> +	struct e820entry *e820_map;
>> +	struct e820entry *highest = 0;
>> +	unsigned long load_addr;
>> +	int i;
>> +
>> +	e820_map = info->real_mode->e820_map;
>> +#if 0
>> +	printf("initrd_start = 0x%lx\n", info->real_mode->initrd_start);
>> +	printf("real_mode->e820_map_nr: %d\n", info->real_mode->e820_map_nr);
>> +#endif
> 
> I think these debugging messages should either be hooked to some
> verbose option or simply removed.

For merging with upstream I would just remove these blocks unless you 
already have an established way of building with runtime debug messages. 
  Just go ahead and change it as you see fit for merging.

>> +		if (e820_map[i].addr + info->real_mode->initrd_size >= 0x38000000)
>> +			continue;
> 
> ..what is this 3.5MB limit about? Also might this condition be
> sensitive to an overflow error?
> 

Peter isn't sure why 3.5MB specifically.  He said it is known to work 
for many years in other boot loaders.  There may have been a historic 
reason for this particular value but he doesn't know.

>> diff -up mkelfImage-2.7/linux-i386/mkelf-linux-i386.c.ramdisk_base mkelfImage-2.7/linux-i386/mkelf-linux-i386.c
>> --- mkelfImage-2.7/linux-i386/mkelf-linux-i386.c.ramdisk_base	2006-03-17 09:08:22.000000000 -0500
>> +++ mkelfImage-2.7/linux-i386/mkelf-linux-i386.c	2008-05-21 10:47:42.000000000 -0400
>> @@ -352,6 +352,9 @@ int linux_i386_mkelf(int argc, char **ar
>>  	 */
>>  	params->initrd_start = params->initrd_size = 0;
>>  	if (ramdisk_size) {
>> +		while (ramdisk_base <= kernel_size)
>> +			ramdisk_base <<= 1;
>> +
> 
> Does this start with 1MB, then try 2MB, 4MB and so on?

According to Peter there this is only a simple way that avoids alignment 
earlier.  While not expressly necessary (you could add), this requires 
less code, and more importantly, it is known to work.

> 
> 
>>  		phdr[index].p_paddr  = ramdisk_base;
>>  		phdr[index].p_vaddr  = ramdisk_base;
>>  		phdr[index].p_filesz = ramdisk_size;
> 
> 
> Please keep in mind to also include Signed-off-by: lines from all who
> have touched the patch. Please see
> http://www.coreboot.org/Development_Guidelines#Sign-off_Procedure
> 

OK, he agreed.  Attached is the same patch with his signing off (but not 
me since I didn't change it.)

Warren Togami
wtogami at redhat.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: mkelfImage-2.7-ramdisk_base.patch
Type: text/x-patch
Size: 2646 bytes
Desc: not available
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20080610/8be6ac4e/attachment.patch>

From paulepanter at users.sourceforge.net  Tue Jun 10 22:09:20 2008
From: paulepanter at users.sourceforge.net (Paul Menzel)
Date: Tue, 10 Jun 2008 22:09:20 +0200
Subject: [coreboot] flashrom and list of computers
In-Reply-To: <484E333D.2060204@bfs.de>
References: <48481E64.3000903@bfs.de> <484832E8.6030002@onelabs.com>
	<4848E2DC.3000801@bfs.de> <484936E5.20208@openhardware.de>
	<48493E6E.9040608@gmx.net> <48494D0A.5090404@bfs.de>
	<48495077.30102@gmx.net>  <484E333D.2060204@bfs.de>
Message-ID: <1213128560.3847.4.camel@mattotaupa.wohnung.familie-menzel.net>

Dear Walter,


Am Dienstag, den 10.06.2008, 09:54 +0200 schrieb walter harms:
> 
> >> Next question: who will write that script ?
> >>   
> > 
> > I wrote such a script a few months ago and sent it to the list.
> 
> 
> can you send me that script ?

I am not sure, but maybe this [1] and [2] is the script, Carl-Daniel was
talking about. (The thread is broken, so in [2] is the recent version, I
think.)


Thanks,

Paul


[1] http://www.coreboot.org/pipermail/coreboot/2008-February/031507.html
[2] http://www.coreboot.org/pipermail/coreboot/2008-March/031654.html
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: Dies ist ein digital signierter Nachrichtenteil
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20080610/275c348f/attachment.sig>

From mylesgw at gmail.com  Tue Jun 10 22:36:48 2008
From: mylesgw at gmail.com (Myles Watson)
Date: Tue, 10 Jun 2008 14:36:48 -0600
Subject: [coreboot] [patch] mkelfimage intelligent placement of ramdisk
In-Reply-To: <484EDAB2.1060701@redhat.com>
References: <484EB02A.5080305@redhat.com> <20080610171641.13215.qmail@stuge.se>
	<484EDAB2.1060701@redhat.com>
Message-ID: <002901c8cb39$b5aae770$0023040a@chimp>


> I hope others test this patch so we can be certain it doesn't break
> anyone where it previously worked.  It shouldn't.

I was hoping it would fix qemu's problem with a LAB kernel, but it doesn't
change the behavior.

> >> +		if (e820_map[i].addr + info->real_mode->initrd_size >=
> 0x38000000)
> >> +			continue;
> >
> > ..what is this 3.5MB limit about? Also might this condition be
> > sensitive to an overflow error?
> >
> 
> Peter isn't sure why 3.5MB specifically.  He said it is known to work
> for many years in other boot loaders.  There may have been a historic
> reason for this particular value but he doesn't know.

I read that value as 896MB, for what it's worth.

Thanks,
Myles






From wtogami at redhat.com  Tue Jun 10 22:45:01 2008
From: wtogami at redhat.com (Warren Togami)
Date: Tue, 10 Jun 2008 16:45:01 -0400
Subject: [coreboot] [patch] mkelfimage intelligent placement of ramdisk
In-Reply-To: <002901c8cb39$b5aae770$0023040a@chimp>
References: <484EB02A.5080305@redhat.com>
	<20080610171641.13215.qmail@stuge.se>	<484EDAB2.1060701@redhat.com>
	<002901c8cb39$b5aae770$0023040a@chimp>
Message-ID: <484EE7CD.6030303@redhat.com>

Myles Watson wrote:
>> I hope others test this patch so we can be certain it doesn't break
>> anyone where it previously worked.  It shouldn't.
> 
> I was hoping it would fix qemu's problem with a LAB kernel, but it doesn't
> change the behavior.

I have no idea what a LAB kernel is, but if your qemu is using the qemu 
standard BIOS (not coreboot) you could try wraplinux instead of mkelfimage.

http://www.kernel.org/pub/linux/utils/boot/wraplinux/
http://git.etherboot.org/?p=wraplinux.git;a=summary

Warren Togami
wtogami at redhat.com



From mylesgw at gmail.com  Tue Jun 10 22:55:42 2008
From: mylesgw at gmail.com (Myles Watson)
Date: Tue, 10 Jun 2008 14:55:42 -0600
Subject: [coreboot] [patch] mkelfimage intelligent placement of ramdisk
In-Reply-To: <484EE7CD.6030303@redhat.com>
References: <484EB02A.5080305@redhat.com><20080610171641.13215.qmail@stuge.se>	<484EDAB2.1060701@redhat.com><002901c8cb39$b5aae770$0023040a@chimp>
	<484EE7CD.6030303@redhat.com>
Message-ID: <002a01c8cb3c$595702d0$0023040a@chimp>


> > I was hoping it would fix qemu's problem with a LAB kernel, but it
> doesn't
> > change the behavior.
> 
> I have no idea what a LAB kernel is, but if your qemu is using the qemu
> standard BIOS (not coreboot) you could try wraplinux instead of
> mkelfimage.

Thanks for the pointer.  I'm curious why it wouldn't work with coreboot,
since it produces an ELF or NBI file.

Thanks,
Myles

> http://www.kernel.org/pub/linux/utils/boot/wraplinux/
> http://git.etherboot.org/?p=wraplinux.git;a=summary
> 
> Warren Togami
> wtogami at redhat.com
> 
> --
> coreboot mailing list
> coreboot at coreboot.org
> http://www.coreboot.org/mailman/listinfo/coreboot




From hoogenboom30 at zonnet.nl  Tue Jun 10 23:31:12 2008
From: hoogenboom30 at zonnet.nl (Ronald Hoogenboom)
Date: Tue, 10 Jun 2008 23:31:12 +0200
Subject: [coreboot] m57sli FAN control
In-Reply-To: <20080610183457.GA32451@localdomain>
References: <20080610183457.GA32451@localdomain>
Message-ID: <484EF2A0.7060507@zonnet.nl>

This patch enables automatic fan control on the gigabyte M57sli-s4 
motherboard using the environmental controller of the IT8716 superio.
All fan outputs are controlled by the cpu temperature sensor for safety.

Signed-off-by: Ronald Hoogenboom <hoogenboom30 at zonnet.nl>


-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: fanctl.patch
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20080610/f8da5932/attachment.ksh>

From yannis.lg at gmail.com  Tue Jun 10 23:44:20 2008
From: yannis.lg at gmail.com (yannis le gal)
Date: Tue, 10 Jun 2008 23:44:20 +0200
Subject: [coreboot] Laptop with PN800 chipset
In-Reply-To: <53d14c280803120044y1a08864k6c8811610233c0d8@mail.gmail.com>
References: <53d14c280803110746n16bf9b4m6156a022840bfdf3@mail.gmail.com>
	<007901c88398$23688860$6401a8c0@who8>
	<53d14c280803120044y1a08864k6c8811610233c0d8@mail.gmail.com>
Message-ID: <53d14c280806101444m20be20b9kb924ea46f35da725@mail.gmail.com>

Hi , is there something new with PN800 chipset ?




On Wed, Mar 12, 2008 at 08:44:41AM +0100, yannis le gal wrote:
>* I found a technical documentation on the web :*
Ok. That probably wasn't meant to end up on the web though.


>* it talks about all chips used*
Yes. I think this laptop is a fairly good laptop candidate for
coreboot if someone wants to have a go and is comfortable with
reverse engineering microcontroller assembly code.


>* > laptops are not yet a viable target, except for one, because they*>* > use special chips to control special features that are found only*>* > on a laptop designed system, and normally these are not at all*>* > documented.*
Here the special chip is the Winbond W83L950D keyboard controller.
Actually this has started happening on desktop mainboards too. Me and
Uwe did some exploring of a board which had an SMSC superio with an
integrated microcontroller. When that board powered up the system CPU
was held in reset and only the microcontroller in the superio was
running, from system flash. There was a special sequence required to
release the system CPU from reset. Anyway, back to this system:

The W83L950D has an 8051 microcontroller and 40kb of flash memory
which contains the 8051 program. The chip also has a whole bunch
of other features and 72(!) GPIO pins. The data sheet can be found
on datasheetarchive.com.

The 8051 can be both good and bad, completely depending on how it's
software is written. Good if the 8051 handles all it's tasks
independently from the rest of the system. Bad if some software in
the system needs to interact with it. In any event the 8051 software
is most likely not documented anywhere, and certainly not somewhere
public.

It is evident that the W83L950D 8051 code is responsible for quite a
few things, including:

* Fan control
* Keyboard and touchpad
* Special keys (Fn, power, lid, etc)
* Battery charging control and voltage monitoring
* Battery communication
* Power management
* Power good signalling to southbridge and hard drive
* Backlight level control
* Speaker beep simulation
* System wakeup (alarm)
* CPU temperature monitoring

Best case, all of these are completely autonomous.
Worst case, coreboot needs to help the 8051 do all of these things.

To do that the 40kb 8051 assembly program would need to be reverse
engineered. For comparison it took a year or so to reverse engineer
the 256kb firmware in the Xbox 360 DVD.

I think reality is somewhere in between the two extremes.


And then there's the PN800 which isn't supported. But at least there
are some developers involved in the project who already have contact
with VIA and are able to request information under NDA. If I've
understood correctly actually receiving the information will take at
least a few months however.

The rest of the system seems to be supported, probably well enough to
get some results once PN800 and the W83L950D firmware are
investigated and handled.

One person with appropriate background but no detailed knowledge of
these particular chips, say six-eight months of work.


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

From r.marek at assembler.cz  Tue Jun 10 23:50:14 2008
From: r.marek at assembler.cz (Rudolf Marek)
Date: Tue, 10 Jun 2008 23:50:14 +0200
Subject: [coreboot] coreboot BIOSisms
In-Reply-To: <e0d27d385414bccfb46f4522fea8694c@imap.1and1.com>
References: <20080609033740.GA1161@morn.localdomain>	<20080609170346.357.qmail@stuge.se>	<20080610021835.GA5498@morn.localdomain>
	<8a5e5d330d5bb633f537e6dd718f8ef7@imap.1and1.com>
	<484E9EC9.9090408@assembler.cz>
	<e0d27d385414bccfb46f4522fea8694c@imap.1and1.com>
Message-ID: <484EF716.1030606@assembler.cz>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi,

> Correct me if I am wrong, currently we don't create the ACPI tables. We
> just use a hex version from the original bios correct? Why not just pass
> this along to legacybios and covert it if needed?

Well nope. I'm using my own tables, compiled from source code. Please note that
some ACPI tables are not static, but are created for specific CPU just plugged in.

>> This is the reason why I really want to have this in coreboot. If you
>> dont like it do not compile it in.
>>
> That's why I think we should just make it an option module.

Oke that would work for me.

Rudolf
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFITvcW3J9wPJqZRNURAqf6AKDGir0TFdpggmFdoBxHkpp7l4hFDwCeKRoZ
Xnk9IBD3p3sBytUmktBhA2M=
=hivF
-----END PGP SIGNATURE-----



From wtogami at redhat.com  Tue Jun 10 23:58:58 2008
From: wtogami at redhat.com (Warren Togami)
Date: Tue, 10 Jun 2008 17:58:58 -0400
Subject: [coreboot] [patch] mkelfimage intelligent placement of ramdisk
In-Reply-To: <002a01c8cb3c$595702d0$0023040a@chimp>
References: <484EB02A.5080305@redhat.com><20080610171641.13215.qmail@stuge.se>	<484EDAB2.1060701@redhat.com><002901c8cb39$b5aae770$0023040a@chimp>
	<484EE7CD.6030303@redhat.com>
	<002a01c8cb3c$595702d0$0023040a@chimp>
Message-ID: <484EF922.7020502@redhat.com>

Myles Watson wrote:
>>> I was hoping it would fix qemu's problem with a LAB kernel, but it
>> doesn't
>>> change the behavior.
>> I have no idea what a LAB kernel is, but if your qemu is using the qemu
>> standard BIOS (not coreboot) you could try wraplinux instead of
>> mkelfimage.
> 
> Thanks for the pointer.  I'm curious why it wouldn't work with coreboot,
> since it produces an ELF or NBI file.
> 

https://fedorahosted.org/k12linux/wiki/Notes/Coreboot
I wrote some notes here.  H Peter Anvin (of kernel fame) wrote wraplinux 
from scratch because mknbi has such terrible code and has been dead for 
so long.  He was unaware of the existence of mkelfimage at the time.

He said wraplinux relies upon "int 15h, AX=2401h (unless A20 is enabled) 
and int 15h, AX=E820h (for probing memory)".  He indicated that he 
really dislikes the design of coreboot and will likely never support it.

wraplinux worked for me with qemu's standard BIOS + Etherboot like used 
in kvm.

Warren Togami
wtogami at redhat.com



From kevin at koconnor.net  Wed Jun 11 01:02:26 2008
From: kevin at koconnor.net (Kevin O'Connor)
Date: Tue, 10 Jun 2008 19:02:26 -0400
Subject: [coreboot] coreboot BIOSisms
In-Reply-To: <8a5e5d330d5bb633f537e6dd718f8ef7@imap.1and1.com>
References: <20080609033740.GA1161@morn.localdomain>
	<20080609170346.357.qmail@stuge.se>
	<20080610021835.GA5498@morn.localdomain>
	<8a5e5d330d5bb633f537e6dd718f8ef7@imap.1and1.com>
Message-ID: <20080610230226.GA10608@morn.localdomain>

Hi Joseph,

On Tue, Jun 10, 2008 at 08:46:07AM -0400, Joseph Smith wrote:
> > Given the above, I see two possibilities.
> > 
> > The first involves having coreboot build the standard tables.
> 
> Like I said why not just have a mini program between the two that handles
> this operation.

Where does this "mini program" get the data?  It will face the same
issues I outlined in my previous email.

>It could be added to coreboot or legacybios as an option
> module. The mini program would read the coreboot tables and what ever else
> it needed and then set these tables up in a format that coresponds with
> legacybios, and finally passes the tables to legacybios.

The coreboot table today does not provide sufficient information to
build the acpi/pir/mptable/smbios tables.

We could extend the coreboot table - but what's the point of defining
our own intermediate format.  For example, if the end consumer wants
an smbios table, why translate from "coreboot->coreboot
table->legacybios->smbios table" when we can just go from
"coreboot->smbios table"?

>Does it have to be more complicated than that?

Adding an additional program in between seems to make things more
complicated.

Thanks,
-Kevin



From joe at settoplinux.org  Wed Jun 11 02:55:09 2008
From: joe at settoplinux.org (Joseph Smith)
Date: Tue, 10 Jun 2008 20:55:09 -0400
Subject: [coreboot] coreboot BIOSisms
In-Reply-To: <20080610230226.GA10608@morn.localdomain>
References: <20080609033740.GA1161@morn.localdomain><20080609170346.357.qmail@stuge.se><20080610021835.GA5498@morn.localdomain><8a5e5d330d5bb633f537e6dd718f8ef7@imap.1and1.com>
	<20080610230226.GA10608@morn.localdomain>
Message-ID: <8F1B914B7F76463F93B73DF877E0D45B@smitty2m>



> -----Original Message-----
> From: coreboot-bounces at coreboot.org [mailto:coreboot-bounces at coreboot.org]
> On Behalf Of Kevin O'Connor
> Sent: Tuesday, June 10, 2008 7:02 PM
> To: Joseph Smith
> Cc: coreboot at coreboot.org
> Subject: Re: [coreboot] coreboot BIOSisms
> 
> Hi Joseph,
> 
> On Tue, Jun 10, 2008 at 08:46:07AM -0400, Joseph Smith wrote:
> > > Given the above, I see two possibilities.
> > >
> > > The first involves having coreboot build the standard tables.
> >
> > Like I said why not just have a mini program between the two that
> handles
> > this operation.
> 
> Where does this "mini program" get the data?  It will face the same
> issues I outlined in my previous email.
> 
> >It could be added to coreboot or legacybios as an option
> > module. The mini program would read the coreboot tables and what ever
> else
> > it needed and then set these tables up in a format that coresponds with
> > legacybios, and finally passes the tables to legacybios.
> 
> The coreboot table today does not provide sufficient information to
> build the acpi/pir/mptable/smbios tables.
> 
> We could extend the coreboot table - but what's the point of defining
> our own intermediate format.  For example, if the end consumer wants
> an smbios table, why translate from "coreboot->coreboot
> table->legacybios->smbios table" when we can just go from
> "coreboot->smbios table"?
> 
> >Does it have to be more complicated than that?
> 
> Adding an additional program in between seems to make things more
> complicated.
> 
Just trying to help with the brain storming process. I am not in any way
trying to make things more complicated. I just think It is going to take a
lot of work, changing the coreboot core code. And very careful at that not
to break the core code from using other payloads. That's why I am suggesting
an option module.

Thanks,
Joseph Smith
Set-Top-Linux
www.settoplinux.org




From peter at stuge.se  Wed Jun 11 03:53:27 2008
From: peter at stuge.se (Peter Stuge)
Date: Wed, 11 Jun 2008 03:53:27 +0200
Subject: [coreboot] flashrom: BioStar P4M80-M4 patch
Message-ID: <20080611015327.28797.qmail@stuge.se>

Patch attached.


//Peter
-------------- next part --------------
A non-text attachment was scrubbed...
Name: fr.p4m80m4_board.patch
Type: text/x-diff
Size: 1566 bytes
Desc: not available
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20080611/3855afe1/attachment.bin>

From peter at stuge.se  Wed Jun 11 03:54:08 2008
From: peter at stuge.se (Peter Stuge)
Date: Wed, 11 Jun 2008 03:54:08 +0200
Subject: [coreboot] flashrom: Amic A29040B support
In-Reply-To: <45a5b7cc0806081159y1947e6bfo5e998ab8e535d720@mail.gmail.com>
References: <45a5b7cc0806081153l64cbc6bbmef55297255e8c26b@mail.gmail.com>
	<45a5b7cc0806081159y1947e6bfo5e998ab8e535d720@mail.gmail.com>
Message-ID: <20080611015408.29361.qmail@stuge.se>

On Sun, Jun 08, 2008 at 02:59:03PM -0400, Lyos Norezel wrote:
> Any way this chip could be added to flashrom?

Patch attached.


//Peter
-------------- next part --------------
A non-text attachment was scrubbed...
Name: fr.a29040b.patch
Type: text/x-diff
Size: 1651 bytes
Desc: not available
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20080611/c18b6c5b/attachment.bin>

From lyos.gemininorezel at gmail.com  Wed Jun 11 04:13:10 2008
From: lyos.gemininorezel at gmail.com (Lyos Gemini Norezel)
Date: Tue, 10 Jun 2008 22:13:10 -0400
Subject: [coreboot] flashrom: BioStar P4M80-M4 patch
In-Reply-To: <20080611015327.28797.qmail@stuge.se>
References: <20080611015327.28797.qmail@stuge.se>
Message-ID: <484F34B6.7050808@gmail.com>

Acked-by: Lyos Gemini Norezel <Lyos.GeminiNorezel at gmail.com>

Lyos Gemini Norezel

Peter Stuge wrote:
> Patch attached.
>
>
> //Peter
>   

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

From lyos.gemininorezel at gmail.com  Wed Jun 11 04:13:38 2008
From: lyos.gemininorezel at gmail.com (Lyos Gemini Norezel)
Date: Tue, 10 Jun 2008 22:13:38 -0400
Subject: [coreboot] flashrom: Amic A29040B support
In-Reply-To: <20080611015408.29361.qmail@stuge.se>
References: <45a5b7cc0806081153l64cbc6bbmef55297255e8c26b@mail.gmail.com>	<45a5b7cc0806081159y1947e6bfo5e998ab8e535d720@mail.gmail.com>
	<20080611015408.29361.qmail@stuge.se>
Message-ID: <484F34D2.1010308@gmail.com>

Acked-by: Lyos Gemini Norezel <Lyos.GeminiNorezel at gmail.com>

Lyos Gemini Norezel

Peter Stuge wrote:
> On Sun, Jun 08, 2008 at 02:59:03PM -0400, Lyos Norezel wrote:
>   
>> Any way this chip could be added to flashrom?
>>     
>
> Patch attached.
>
>
> //Peter
>   

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

From peter at stuge.se  Wed Jun 11 04:17:49 2008
From: peter at stuge.se (Peter Stuge)
Date: Wed, 11 Jun 2008 04:17:49 +0200
Subject: [coreboot] coreboot BIOSisms
In-Reply-To: <20080610230226.GA10608@morn.localdomain>
References: <20080609033740.GA1161@morn.localdomain>
	<20080609170346.357.qmail@stuge.se>
	<20080610021835.GA5498@morn.localdomain>
	<8a5e5d330d5bb633f537e6dd718f8ef7@imap.1and1.com>
	<20080610230226.GA10608@morn.localdomain>
Message-ID: <20080611021749.13762.qmail@stuge.se>

On Tue, Jun 10, 2008 at 07:02:26PM -0400, Kevin O'Connor wrote:
> For example, if the end consumer wants an smbios table,

This is exactly my point:

End consumer is oblivious to these data structures, and rightly so.
End consumer only wants $kernel to run and be featureful.

$kernel wants BIOSisms to run and be featureful.

We have to provide BIOSisms for $kernels for now.


But we have a unique opportunity to revise these data structures now!

By creating a good intermediate format, we will eventually be able to
replace many if not all BIOSisms with something better documented,
maybe even something simpler and certainly something nicer.


> why translate from "coreboot->coreboot table->legacybios->smbios
> table" when we can just go from "coreboot->smbios table"?

Staying true to the design that coreboot is not a BIOS, but something
better.


> Adding an additional program in between seems to make things more
> complicated.

Short term, yes - slightly more complicated but much better structured.
Long term the additional program dies.


//Peter



From svn at coreboot.org  Wed Jun 11 04:22:42 2008
From: svn at coreboot.org (svn at coreboot.org)
Date: Wed, 11 Jun 2008 04:22:42 +0200
Subject: [coreboot] r3364 - trunk/util/flashrom
Message-ID: <mailman.1625.1355071332.16123.coreboot@coreboot.org>

Author: stuge
Date: 2008-06-11 04:22:42 +0200 (Wed, 11 Jun 2008)
New Revision: 3364

Modified:
   trunk/util/flashrom/board_enable.c
Log:
flashrom: Board enable and autodetection for BioStar P4M80-M4.

Thanks to Reinder for clean room reverse engineering and data sheet diving!

This board is autodetected because there are some good BioStar subsystem IDs.
Matching uses onboard VT6420 SATA RAID with subsystem BioStar 3206 and
onboard UniChrome Pro IGP graphics with subsystem BioStar 1202.

Signed-off-by: Peter Stuge <peter at stuge.se>
Acked-by: Lyos Gemini Norezel <lyos.gemininorezel at gmail.com>


Modified: trunk/util/flashrom/board_enable.c
===================================================================
--- trunk/util/flashrom/board_enable.c	2008-06-08 23:05:24 UTC (rev 3363)
+++ trunk/util/flashrom/board_enable.c	2008-06-11 02:22:42 UTC (rev 3364)
@@ -515,6 +515,32 @@
 }
 
 /**
+ * Suited for:
+ *   - BioStar P4M80-M4: Intel P4 + VIA P4M800 + VT8237
+ */
+static int board_biostar_p4m80_m4(const char *name)
+{
+	/* enter IT87xx conf mode */
+	OUTB(0x87, 0x2e);
+	OUTB(0x01, 0x2e);
+	OUTB(0x55, 0x2e);
+	OUTB(0x55, 0x2e);
+
+	/* select right flash chip */
+	wbsio_mask(0x2e, 0x22, 0x80, 0x80);
+
+	/* bit 3: flash chip write enable
+	 * bit 7: map flash chip at 1MB-128K (why though? ignoring this.)
+	 */
+	wbsio_mask(0x2e, 0x24, 0x04, 0x04);
+
+	/* exit IT87xx conf mode */
+	wbsio_write(0x2, 0x2e, 0x2);
+
+	return 0;
+}
+
+/**
  * We use 2 sets of IDs here, you're free to choose which is which. This
  * is to provide a very high degree of certainty when matching a board on
  * the basis of subsystem/card IDs. As not every vendor handles
@@ -584,6 +610,8 @@
 	 "artecgroup", "dbe62", "Artec Group DBE62", board_artecgroup_dbe6x},
  	{0x8086, 0x27b8, 0x0000, 0x0000, 0x0000, 0x0000, 0x0000, 0x0000,
  	 "kontron", "986lcd-m", "Kontron 986LCD-M", board_kontron_986lcd_m},
+ 	{0x1106, 0x3149, 0x1565, 0x3206, 0x1106, 0x3344, 0x1565, 0x1202,
+ 	 NULL, NULL, "BioStar P4M80-M4", board_biostar_p4m80_m4},
 	{0, 0, 0, 0, 0, 0, 0, 0, NULL, NULL}	/* Keep this */
 };
 




From peter at stuge.se  Wed Jun 11 04:23:10 2008
From: peter at stuge.se (Peter Stuge)
Date: Wed, 11 Jun 2008 04:23:10 +0200
Subject: [coreboot] flashrom: BioStar P4M80-M4 patch
In-Reply-To: <484F34B6.7050808@gmail.com>
References: <20080611015327.28797.qmail@stuge.se> <484F34B6.7050808@gmail.com>
Message-ID: <20080611022310.18114.qmail@stuge.se>

On Tue, Jun 10, 2008 at 10:13:10PM -0400, Lyos Gemini Norezel wrote:
> Acked-by: Lyos Gemini Norezel <Lyos.GeminiNorezel at gmail.com>

Thanks! r3364



From svn at coreboot.org  Wed Jun 11 04:24:16 2008
From: svn at coreboot.org (svn at coreboot.org)
Date: Wed, 11 Jun 2008 04:24:16 +0200
Subject: [coreboot] r3365 - trunk/util/flashrom
Message-ID: <mailman.1626.1355071332.16123.coreboot@coreboot.org>

Author: stuge
Date: 2008-06-11 04:24:15 +0200 (Wed, 11 Jun 2008)
New Revision: 3365

Modified:
   trunk/util/flashrom/flash.h
   trunk/util/flashrom/flashchips.c
Log:
flashrom: Add support for Amic Technology A29040B flash chip.

PROBE READ tested by Lyos Gemini Norezel on BioStar P4M80-M4.

Signed-off-by: Peter Stuge <peter at stuge.se>
Acked-by: Lyos Gemini Norezel <lyos.gemininorezel at gmail.com>


Modified: trunk/util/flashrom/flash.h
===================================================================
--- trunk/util/flashrom/flash.h	2008-06-11 02:22:42 UTC (rev 3364)
+++ trunk/util/flashrom/flash.h	2008-06-11 02:24:15 UTC (rev 3365)
@@ -119,6 +119,7 @@
 #define AMIC_ID			0x7F37	/* AMIC */
 #define AMIC_ID_NOPREFIX	0x37	/* AMIC */
 #define AMIC_A25L40P		0x2013
+#define AMIC_A29040B		0x86
 
 #define ASD_ID			0x25	/* ASD, not listed in JEP106W */
 #define ASD_AE49F2008		0x52

Modified: trunk/util/flashrom/flashchips.c
===================================================================
--- trunk/util/flashrom/flashchips.c	2008-06-11 02:22:42 UTC (rev 3364)
+++ trunk/util/flashrom/flashchips.c	2008-06-11 02:24:15 UTC (rev 3365)
@@ -45,6 +45,7 @@
 	{"Atmel",	"AT49F002(N)T",		ATMEL_ID,	AT_49F002NT,		256,	256,		TEST_UNTESTED,	probe_jedec,		erase_chip_jedec,		write_jedec},
 	{"Atmel",       "AT25DF321",		ATMEL_ID,	AT_25DF321,		4096,	256,		TEST_OK_PREW,	probe_spi_rdid,		spi_chip_erase_c7,	spi_chip_write,	spi_chip_read},
 	{"Amic Technology","A25L40P",		AMIC_ID,	AMIC_A25L40P,		512,	256,		TEST_UNTESTED,	probe_spi_rdid,		spi_chip_erase_c7,	spi_chip_write, spi_chip_read},
+	{"Amic Technology","A29040B",		AMIC_ID_NOPREFIX, AMIC_A29040B,		512,	64 * 1024,	TEST_OK_PR,	probe_29f040b,		erase_29f040b,			write_29f040b},
 	{"EMST",	"F49B002UA",		EMST_ID,	EMST_F49B002UA,		256,	4096,		TEST_UNTESTED,	probe_jedec,		erase_chip_jedec,		write_49f002},
 	{"EON",		"EN29F002(A)(N)B",	EON_ID,		EN_29F002B,		256,	256,		TEST_UNTESTED,	probe_jedec,		erase_chip_jedec,		write_jedec},
 	{"EON",		"EN29F002(A)(N)T",	EON_ID,		EN_29F002T,		256,	256,		TEST_UNTESTED,	probe_jedec,		erase_chip_jedec,		write_jedec},




From peter at stuge.se  Wed Jun 11 04:24:44 2008
From: peter at stuge.se (Peter Stuge)
Date: Wed, 11 Jun 2008 04:24:44 +0200
Subject: [coreboot] flashrom: Amic A29040B support
In-Reply-To: <484F34D2.1010308@gmail.com>
References: <45a5b7cc0806081153l64cbc6bbmef55297255e8c26b@mail.gmail.com>
	<45a5b7cc0806081159y1947e6bfo5e998ab8e535d720@mail.gmail.com>
	<20080611015408.29361.qmail@stuge.se> <484F34D2.1010308@gmail.com>
Message-ID: <20080611022444.19401.qmail@stuge.se>

On Tue, Jun 10, 2008 at 10:13:38PM -0400, Lyos Gemini Norezel wrote:
> Acked-by: Lyos Gemini Norezel <Lyos.GeminiNorezel at gmail.com>

Thanks for testing! r3365



From peter at stuge.se  Wed Jun 11 05:07:36 2008
From: peter at stuge.se (Peter Stuge)
Date: Wed, 11 Jun 2008 05:07:36 +0200
Subject: [coreboot] [patch] mkelfimage intelligent placement of ramdisk
In-Reply-To: <484EF922.7020502@redhat.com>
References: <484EE7CD.6030303@redhat.com>
	<002a01c8cb3c$595702d0$0023040a@chimp>
	<484EF922.7020502@redhat.com>
Message-ID: <20080611030736.20175.qmail@stuge.se>

On Tue, Jun 10, 2008 at 05:58:58PM -0400, Warren Togami wrote:
> H Peter Anvin (of kernel fame) wrote wraplinux from scratch because
> mknbi has such terrible code and has been dead for so long.

Sweet!


> He said wraplinux relies upon "int 15h, AX=2401h (unless A20 is
> enabled) and int 15h, AX=E820h (for probing memory)".  He indicated
> that he really dislikes the design of coreboot and will likely
> never support it.

I would very much appreciate if you could expand on this.

In general I think more communication involving coreboot and kernel
developers is a good thing because the projects can be quite closely
connected.


//Peter



From kevin at koconnor.net  Wed Jun 11 06:22:32 2008
From: kevin at koconnor.net (Kevin O'Connor)
Date: Wed, 11 Jun 2008 00:22:32 -0400
Subject: [coreboot] coreboot BIOSisms
In-Reply-To: <20080611021749.13762.qmail@stuge.se>
References: <20080609033740.GA1161@morn.localdomain>
	<20080609170346.357.qmail@stuge.se>
	<20080610021835.GA5498@morn.localdomain>
	<8a5e5d330d5bb633f537e6dd718f8ef7@imap.1and1.com>
	<20080610230226.GA10608@morn.localdomain>
	<20080611021749.13762.qmail@stuge.se>
Message-ID: <20080611042232.GA11420@morn.localdomain>

Hi Peter!

On Wed, Jun 11, 2008 at 04:17:49AM +0200, Peter Stuge wrote:
> By creating a good intermediate format, we will eventually be able to
> replace many if not all BIOSisms with something better documented,
> maybe even something simpler and certainly something nicer.

This is why I'm "torn" on the issue.  I can see the value in a good
intermediate format - one that would allow coreboot to easily export a
wide variety of static and dynamic data.

Unfortunately, I don't believe there is a good intermediate format
available today.  LAR looks nice, but it only seems useful for large
blobs and it isn't supported by v2.  The coreboot table is effectively
the same technology as the binary ACPI/pir/mptable/smbios tables.  I
don't see a compelling advantage to defining new coreboot tables over
using existing standard tables.

> > why translate from "coreboot->coreboot table->legacybios->smbios
> > table" when we can just go from "coreboot->smbios table"?
> 
> Staying true to the design that coreboot is not a BIOS, but something
> better.

I'm not really sure what that means.  Coreboot doing something
different from a "BIOS" does not inherently mean that coreboot is
better.  So, if there is an intermediate format with compelling
features - then I'm all for it.  But, if a new intermediate format is
just different or only slightly better - then I'd recommend using the
existing standards.

> > Adding an additional program in between seems to make things more
> > complicated.
> 
> Short term, yes - slightly more complicated but much better structured.
> Long term the additional program dies.

I agree 100% that if acpi/pir/mptable/smbios table generation is added
to coreboot that it should be optional.

Thanks,
-Kevin



From corebootbmw2 at lsmod.de  Wed Jun 11 08:44:37 2008
From: corebootbmw2 at lsmod.de (Bernhard M. Wiedemann)
Date: Wed, 11 Jun 2008 08:44:37 +0200
Subject: [coreboot] coreboot on QEMU
Message-ID: <20080611064437.GA13396@uml12d.zq1.de>

Hello,

I have recently tried out the coreboot-v2 trunk with a self-built FILO-0.5 payload and precompiled coreboot-v3+FILO from http://www.coreboot.org/QEMU (bios.bin dating 2008-05-01) using an unpatched qemu-0.9.0 and 0.9.1 from OpenSUSE-10.3. 
The rootfs contained a Debian/Etch that I had lying around.

I encountered some Problems:
a) virtual NIC (ne2k_pci) did not work. It said, it didnt know about IRQ routing for PCI pin A and assigned IRQ 0. pci=biosirq or pci=noapic did not help either.

b) the virtual machine did not power down after "halt"

I verified that both worked by booting Knoppix on the same qemu version without -L (so with standard qemu BIOS)


call was:
qemu -net nic,vlan=0 -net tap,vlan=0,ifname=tap0,script=/etc/qemu-ifup -hda disk.img -L ~ -nographic

Boot Log is at
http://www.lsmod.de/~bernhard/qemu-coreboot-v3.txt

What for is the qemu-linuxbios/qemu-isa-bios-ram.patch ?
Any other suggestions? 

Ciao
Bernhard M.



From peter at stuge.se  Wed Jun 11 10:03:37 2008
From: peter at stuge.se (Peter Stuge)
Date: Wed, 11 Jun 2008 10:03:37 +0200
Subject: [coreboot] coreboot BIOSisms
In-Reply-To: <20080611042232.GA11420@morn.localdomain>
References: <20080609033740.GA1161@morn.localdomain>
	<20080609170346.357.qmail@stuge.se>
	<20080610021835.GA5498@morn.localdomain>
	<8a5e5d330d5bb633f537e6dd718f8ef7@imap.1and1.com>
	<20080610230226.GA10608@morn.localdomain>
	<20080611021749.13762.qmail@stuge.se>
	<20080611042232.GA11420@morn.localdomain>
Message-ID: <20080611080337.28002.qmail@stuge.se>

On Wed, Jun 11, 2008 at 12:22:32AM -0400, Kevin O'Connor wrote:
> On Wed, Jun 11, 2008 at 04:17:49AM +0200, Peter Stuge wrote:
> > By creating a good intermediate format, we will eventually be able to
> > replace many if not all BIOSisms with something better documented,
> > maybe even something simpler and certainly something nicer.
> 
> This is why I'm "torn" on the issue.  I can see the value in a good
> intermediate format - one that would allow coreboot to easily
> export a wide variety of static and dynamic data.
> 
> Unfortunately, I don't believe there is a good intermediate format
> available today.

That's right. It doesn't exist yet.


> LAR looks nice, but it only seems useful for large blobs and it
> isn't supported by v2.

And LAR has been heavily optimized for flash, so is probably not the
best candidate.


> The coreboot table is effectively the same technology as the binary
> ACPI/pir/mptable/smbios tables.  I don't see a compelling advantage
> to defining new coreboot tables over using existing standard
> tables.

For one thing, there would be a single table instead of many.


> > Staying true to the design that coreboot is not a BIOS, but
> > something better.
> 
> I'm not really sure what that means.  Coreboot doing something
> different from a "BIOS" does not inherently mean that coreboot is
> better.

I think it does, just because "BIOS" is so old and implies many other
things. I consider doing even almost the same thing but with a new
name and more together to be a big improvement.
(Basically what coreboot is all about.)


> So, if there is an intermediate format with compelling features -
> then I'm all for it.

Would you be interested in helping with development of that format,
or do you only wish to use it when it becomes available?


> But, if a new intermediate format is just different or only
> slightly better - then I'd recommend using the existing standards.

The container format can't be very different - it will still be one
data structure in RAM.

But could the contents be improved upon?

Of course, as mere producers we don't care too much, it would be
interesting to discuss also with the consumers.

One consumer opinion is "why change what works" which is
understandable, but is it really the only one?


//Peter



From r&d2 at dave-tech.it  Wed Jun 11 11:34:35 2008
From: r&d2 at dave-tech.it (llandre)
Date: Wed, 11 Jun 2008 11:34:35 +0200
Subject: [coreboot] Firmware hub flash addressing [off-topic]
Message-ID: <484F9C2B.8030003@dave-tech.it>

Sorry for posting a message that is a little bit off-topic.

I'm working with a SST 8 Mbit Firmware Hub SST49LF008A flash connected 
to Geode LX LPC bus.
I need to understand where flash registers are mapped in case the flash 
ID is set to 1 (this flash is not the boot flash that has ID=0).
The datasheet just says about identification registers (same thing 
applies for other registers too):

JEDEC ID Registers
The JEDEC ID registers for the boot device appear at
FFBC0000H and FFBC0001H in the 4 GByte system
memory map, and will appear ***elsewhere*** if the device is not
the boot device.


Anybody can tell me what does "elsewhere" stand for in this sentence?



TIA,
llandre

DAVE Electronics System House - R&D Department
web:   http://www.dave.eu
email: r&d2 at dave-tech.it



From hpa at zytor.com  Wed Jun 11 07:27:19 2008
From: hpa at zytor.com (H. Peter Anvin)
Date: Tue, 10 Jun 2008 22:27:19 -0700
Subject: [coreboot] [patch] mkelfimage intelligent placement of ramdisk
In-Reply-To: <20080611030736.20175.qmail@stuge.se>
References: <484EE7CD.6030303@redhat.com>
	<002a01c8cb3c$595702d0$0023040a@chimp>
	<484EF922.7020502@redhat.com> <20080611030736.20175.qmail@stuge.se>
Message-ID: <484F6237.1080608@zytor.com>

Peter Stuge wrote:
> On Tue, Jun 10, 2008 at 05:58:58PM -0400, Warren Togami wrote:
>> H Peter Anvin (of kernel fame) wrote wraplinux from scratch because
>> mknbi has such terrible code and has been dead for so long.
> 
> Sweet!
> 
>> He said wraplinux relies upon "int 15h, AX=2401h (unless A20 is
>> enabled) and int 15h, AX=E820h (for probing memory)".  He indicated
>> that he really dislikes the design of coreboot and will likely
>> never support it.
> 
> I would very much appreciate if you could expand on this.
> 
> In general I think more communication involving coreboot and kernel
> developers is a good thing because the projects can be quite closely
> connected.

Yes, and therein lies the problem.  They shouldn't have to be.

APIs exist to decouple modules.  Use them.  I understand there is 
finally some serious work going on in that vein in the coreboot 
community; this makes sense.

The "no API" model is idiotic.

	-hpa



From peter at stuge.se  Wed Jun 11 12:37:01 2008
From: peter at stuge.se (Peter Stuge)
Date: Wed, 11 Jun 2008 12:37:01 +0200
Subject: [coreboot] [patch] mkelfimage intelligent placement of ramdisk
In-Reply-To: <484F6237.1080608@zytor.com>
References: <484EE7CD.6030303@redhat.com>
	<002a01c8cb3c$595702d0$0023040a@chimp>
	<484EF922.7020502@redhat.com> <20080611030736.20175.qmail@stuge.se>
	<484F6237.1080608@zytor.com>
Message-ID: <20080611103701.9675.qmail@stuge.se>

On Tue, Jun 10, 2008 at 10:27:19PM -0700, H. Peter Anvin wrote:
> APIs exist to decouple modules.  Use them.  I understand there is
> finally some serious work going on in that vein in the coreboot
> community; this makes sense.
> 
> The "no API" model is idiotic.

You don't feel it is possible/desirable to have all hardware code
in the operating system so that boot code can be oneshot?

(of course the boot code still has to hand over state information)

What would the ideal abstraction be then?


//Peter



From jordan.crouse at amd.com  Wed Jun 11 17:32:49 2008
From: jordan.crouse at amd.com (Jordan Crouse)
Date: Wed, 11 Jun 2008 09:32:49 -0600
Subject: [coreboot] mkelfimage intelligent placement of ramdisk
In-Reply-To: <20080611103701.9675.qmail@stuge.se>
References: <484EE7CD.6030303@redhat.com>
	<002a01c8cb3c$595702d0$0023040a@chimp>
	<484EF922.7020502@redhat.com> <20080611030736.20175.qmail@stuge.se>
	<484F6237.1080608@zytor.com> <20080611103701.9675.qmail@stuge.se>
Message-ID: <20080611153249.GB25014@cosmic.amd.com>

On 11/06/08 12:37 +0200, Peter Stuge wrote:
> On Tue, Jun 10, 2008 at 10:27:19PM -0700, H. Peter Anvin wrote:
> > APIs exist to decouple modules.  Use them.  I understand there is
> > finally some serious work going on in that vein in the coreboot
> > community; this makes sense.
> > 
> > The "no API" model is idiotic.
> 
> You don't feel it is possible/desirable to have all hardware code
> in the operating system so that boot code can be oneshot?
> 
> (of course the boot code still has to hand over state information)
> 
> What would the ideal abstraction be then?

Interestingly enough, this thread is intertwining with the "coreboot
BIOSisms" threat, and Peter has gotten his wish.. "Of course, as mere
producers we don't care too much, it would be interesting to discuss
also with the consumers".  Well, here is the owner of the init code 
for the only operating system we can boot.  I think he qualifies as
an interested party.

I don't presume to speak for hpa, but I do think I feel his concern.
His areas of interest aren't so very much different then ours.  With
syslinux and the kernel init code, his main goal is to take a decidedly
complex architecture and beat it into sanity.  And for the most part,
it will just work on any given x86 architecture - hpa isn't running around
trying Linux on every new platform that is coming out - he trusts that
the BIOS will give him the information that he needs.

Now, you can argue that that the API is old and archaic and stupid.
Those are legitimate arguments, but they aren't interesting for the guy
who doesn't want to have to worry about changing his code every time a 
BIOS software developer thinks he has something clever. 

This is a problem we are already struggling with.  Why doesn't gPXE work
out of the box?  Why wouldn't libpayload + coreinfo work on non coreboot
BIOSen (by all accounts it should).  The first answer is because we need
to add coreboot specific code to gPXE, and the second answer is that
we have _only_ coreboot specific code in libpayload.  These are probably
not optimal solutions.

Now, I don't know how hpa feels about the traditional BIOS API - perhaps he
too would be open to a new way of doing things.  But even if he is, there are
lots of API consumers right behind him (ACPI, mptable, etc, etc) that would
need convincing as well.  Its a long road to travel, and we may never
reach the end successfully.  I think what Kevin is doing is exactly the
right course of action - we need to play well with others, sooner rather
then later and then slowly bring them along with us.   That is the only
way we can be successful.  Storming in and saying "we are clever, support
us or die!" is not a great way to win over the world.

I'll leave you with a thought - the first guy who stood up and said
"Hey lets overthrow the king" got his head cut off.  It takes
consensus to make permanent change.

Jordan

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




From Ken.Fuchs at bench.com  Wed Jun 11 18:23:09 2008
From: Ken.Fuchs at bench.com (Ken.Fuchs at bench.com)
Date: Wed, 11 Jun 2008 11:23:09 -0500
Subject: [coreboot] filo-0.5 compilation issues
In-Reply-To: <13426df10806091854n135f0e1au533ac9211b722dc7@mail.gmail.com>
Message-ID: <AA28F077645B324881335614E4F7C4284A4909@win-ex01.bench.com>

ron minnich wrote: 
 
> gcc -m32 -Wall -Os -fomit-frame-pointer -fno-common -ffreestanding
> -fno-strict-aliasing -Wno-unused  -nostdinc -imacros ../config.h
> -I../include -I/usr/lib/gcc/i486-linux-gnu/4.1.2/include -MD 
> -c printf.c
> -o printf.o
> 
> What does this with -E show? This is really weird.

With -E, the compilation produces (without warnings or errors)
the following preprocessor output appended below my sig.

Thanks,

Ken Fuchs

------

# 1 "printf.c"
# 1 "<built-in>"
# 1 "<command line>"
# 1 "./../config.h" 1
# 1 "<command line>" 2
# 1 "printf.c"
# 16 "printf.c"
# 1 "/usr/lib/gcc/i486-linux-gnu/4.1.2/include/stdarg.h" 1
# 43 "/usr/lib/gcc/i486-linux-gnu/4.1.2/include/stdarg.h"
typedef __builtin_va_list __gnuc_va_list;
# 105 "/usr/lib/gcc/i486-linux-gnu/4.1.2/include/stdarg.h"
typedef __gnuc_va_list va_list;
# 17 "printf.c" 2
# 1 "../include/lib.h" 1



# 1 "/usr/lib/gcc/i486-linux-gnu/4.1.2/include/stddef.h" 1
# 152 "/usr/lib/gcc/i486-linux-gnu/4.1.2/include/stddef.h"
typedef int ptrdiff_t;
# 214 "/usr/lib/gcc/i486-linux-gnu/4.1.2/include/stddef.h"
typedef unsigned int size_t;
# 326 "/usr/lib/gcc/i486-linux-gnu/4.1.2/include/stddef.h"
typedef int wchar_t;
# 5 "../include/lib.h" 2
# 1 "../include/arch/stdint.h" 1



typedef unsigned char uint8_t;
typedef unsigned short uint16_t;
typedef unsigned int uint32_t;
typedef unsigned long long uint64_t;




typedef signed char int8_t;
typedef signed short int16_t;
typedef signed int int32_t;
typedef signed long long int64_t;
# 6 "../include/lib.h" 2


void vga_init(void);
void vga_putchar(unsigned int c);



int kbd_havekey(void);
int kbd_havechar(void);
int kbd_getchar(void);



void serial_init(void);
void serial_putchar(unsigned char c);
int serial_havechar(void);
int serial_getchar(void);


void console_init(void);
int putchar(int c);
int puts(const char *s);
int printf(const char *fmt, ...) __attribute__ ((format (printf, 1,
2)));
int havekey(void);
int havechar(void);
int getchar(void);
int getline(char *buf, int max);

extern int last_putchar;

void *malloc(size_t size);
void free(void *ptr);
void *calloc(size_t nmemb, size_t size);
void *realloc(void *ptr, size_t size);
void malloc_check(void);
void malloc_diag(void);
void *allot2(size_t size, unsigned int alignment);
void forget2(void *ptr);


size_t strnlen(const char *src, size_t max);
size_t strlen(const char *src);
int strcmp(const char *s1, const char *s2);
int memcmp(const void *s1, const void *s2, size_t n);
void *memcpy(void *dest, const void *src, size_t n);
void *memset(void *s, int c, size_t n);
void *memmove(void *dest, const void *src, size_t n);
int isspace(int c);
int isdigit(int c);
int tolower(int c);
char *strdup(const char *s);
char *strchr(const char *s, int c);
char *strncpy(char *to, const char *from, int count);
char * strcpy (char *dest, const char *src);
char * strstr (const char *s1, const char *s2);
int strncat (char *s1, const char *s2, int n);
int sprintf(char * buf, const char *fmt, ...);

unsigned long long simple_strtoull(const char *cp,char **endp,unsigned
int base);
unsigned long long strtoull_with_suffix(const char *cp,char
**endp,unsigned int base);

unsigned int get_le32(const unsigned char *);
unsigned int get_le16(const unsigned char *);
void hexdump(const void *p, unsigned int len);

long long simple_strtoll(const char *cp,char **endp,unsigned int base);

void halt(void) __attribute__((noreturn));





struct sys_info;
int elf_load(struct sys_info *, const char *filename, const char
*cmdline);


int linux_load(struct sys_info *, const char *filename, const char
*cmdline);
# 18 "printf.c" 2
# 26 "printf.c"
static inline unsigned char __toupper(unsigned char c)
{
        if (((c) >= 'a' && (c) <= 'z'))
                c -= 'a'-'A';
        return c;
}


unsigned long long simple_strtoull(const char *cp,char **endp,unsigned
int base)
{
 unsigned long long result = 0,value;

 if (!base) {
  base = 10;
  if (*cp == '0') {
   base = 8;
   cp++;
   if ((*cp == 'x') && (((cp[1]) >= '0' && (cp[1]) <= '9') || ((cp[1])
>= 'a' && (cp[1]) <= 'f') || ((cp[1]) >= 'A' && (cp[1]) <= 'F'))) {
    cp++;
    base = 16;
   }
  }
 }
 while ((((*cp) >= '0' && (*cp) <= '9') || ((*cp) >= 'a' && (*cp) <=
'f') || ((*cp) >= 'A' && (*cp) <= 'F')) && (value = ((*cp) >= '0' &&
(*cp) <= '9') ? *cp-'0' : (((*cp) >= 'a' && (*cp) <= 'z')
     ? __toupper(*cp) : *cp)-'A'+10) < base) {
  result = result*base + value;
  cp++;
 }
 if (endp)
  *endp = (char *)cp;
 return result;
}

long long simple_strtoll(const char *cp,char **endp,unsigned int base)
{
 if(*cp=='-')
  return -simple_strtoull(cp+1,endp,base);
 return simple_strtoull(cp,endp,base);
}

unsigned long long strtoull_with_suffix(const char *cp,char
**endp,unsigned int base)
{
 unsigned long long result;

 if (!endp) {
     printf("%s must be called with endp\n", __FUNCTION__);
     return 0;
 }
 result = simple_strtoull(cp, endp, base);
 switch (__toupper(**endp)) {
 case 'K':
  result <<= 10;
  ++*endp;
  break;
 case 'M':
  result <<= 20;
  ++*endp;
  break;
 case 'G':
  result <<= 30;
  ++*endp;
  break;
 }
 return result;
}


static int skip_atoi(const char **s)
{
 int i=0;

 while (((**s) >= '0' && (**s) <= '9'))
  i = i*10 + *((*s)++) - '0';
 return i;
}
# 116 "printf.c"
static int number(int (*tx_byte)(int byte), long long num, int base, int
size, int precision
 ,int type)
{
 char c,sign,tmp[66];
 const char *digits="0123456789abcdefghijklmnopqrstuvwxyz";
 int i;
 int count = 0;

 if (type & 64)
  digits = "0123456789ABCDEFGHIJKLMNOPQRSTUVWXYZ";
 if (type & 16)
  type &= ~1;
 if (base < 2 || base > 36)
  return 0;
 c = (type & 1) ? '0' : ' ';
 sign = 0;
 if (type & 2) {
  if (num < 0) {
   sign = '-';
   num = -num;
   size--;
  } else if (type & 4) {
   sign = '+';
   size--;
  } else if (type & 8) {
   sign = ' ';
   size--;
  }
 }
 if (type & 32) {
  if (base == 16)
   size -= 2;
  else if (base == 8)
   size--;
 }
 i = 0;
 if (num == 0)
  tmp[i++]='0';
 else while (num != 0)
  tmp[i++] = digits[({ int __res; __res = ((unsigned long long) num) %
(unsigned) base; num = ((unsigned long long) num) / (unsigned) base;
__res; })];
 if (i > precision)
  precision = i;
 size -= precision;
 if (!(type&(1 +16)))
  while(size-->0)
   tx_byte(' '), count++;
 if (sign)
  tx_byte(sign), count++;
 if (type & 32) {
  if (base==8)
   tx_byte('0'), count++;
  else if (base==16) {
   tx_byte('0'), count++;
   tx_byte(digits[33]), count++;
  }
 }
 if (!(type & 16))
  while (size-- > 0)
   tx_byte(c), count++;
 while (i < precision--)
  tx_byte('0'), count++;
 while (i-- > 0)
  tx_byte(tmp[i]), count++;
 while (size-- > 0)
  tx_byte(' '), count++;
 return count;
}


int vtxprintf(int (*tx_byte)(int byte), const char *fmt, va_list args)
{
 int len;
 unsigned long long num;
 int i, base;
 const char *s;

 int flags;

 int field_width;
 int precision;

 int qualifier; se + value;
  cp++;
 }
 if (endp)
  *endp = (char *)cp;
 return result;
}

long long simple_strtoll(const char *cp,char **endp,unsigned int base)
{
 if(*cp=='-')
  return -simple_strtoull(cp+1,endp,base);
 return simple_strtoull(cp,endp flags |= 16; goto repeat;
    case '+': flags |= 4; goto repeat;
    case ' ': flags |= 8; goto repeat;
    case '#': flags |= 32; goto repeat;
    case '0': flags |= 1; goto repeat;
    }


  field_width = -1;
  if (((*fmt) >= '0' && (*fmt) <= '9'))
   field_width = skip_atoi(&fmt);
  else if (*fmt == '*') {
   ++fmt;

   field_width = __builtin_va_arg(args,int);
   if (field_width < 0) {
    field_width = -field_width;
    flags |= 16;
   }
  }


  precision = -1;
  if (*fmt == '.') {
   ++fmt;
   if (((*fmt) >= '0' && (*fmt) <= '9'))
    precision = skip_atoi(&fmt);
   else if (*fmt == '*') {
    ++fmt;

    precision = __builtin_va_arg(args,int);
   }
   if (precision < 0)
    precision = 0;
  }


  qualifier = -1;
  if (*fmt == 'h' || *fmt == 'l' || *fmt == 'L') {
   qualifier = *fmt;
   ++fmt;
  }


  base = 10;

  switch (*fmt) {
  case 'c':
   if (!(flags & 16))
    while (--field_width > 0)
     tx_byte(' '), count++;
   tx_byte((unsigned char) __builtin_va_arg(args,int)), count++;
   while (--field_width > 0)
    tx_byte(' '), count++;
   continue;

  case 's':
   s = __builtin_va_arg(args,char *);
   if (!s)
    s = "<NULL>";

   len = strnlen(s, precision);

   if (!(flags & 16))
    while (len < field_width--)
     tx_byte(' '), count++;
   for (i = 0; i < len; ++i)
    tx_byte(*s++), count++;
   while (len < field_width--)
    tx_byte(' '), count++;
   continue;

  case 'p':
   if (field_width == -1) {
    field_width = 2*sizeof(void *);
    flags |= 1;
   }
   count += number(tx_byte,
    (unsigned long) __builtin_va_arg(args,void *), 16,
    field_width, precision, flags);
   continue;


  case 'n':
   if (qualifier == 'l') {
    long * ip = __builtin_va_arg(args,long *);
    *ip = count;
   } else {
    int * ip = __builtin_va_arg(args,int *);
    *ip = count;
   }
   continue;

  case '%':
   tx_byte('%'), count++;
   continue;


  case 'o':
   base = 8;
   break;

  case 'X':
   flags |= 64;
  case 'x':
   base = 16;
   break;

  case 'd':
  case 'i':
   flags |= 2;
  case 'u':
   break;

  default:
   tx_byte('%'), count++;
   if (*fmt)
    tx_byte(*fmt), count++;
   else
    --fmt;
   continue;
  }
  if (qualifier == 'L')
   num = __builtin_va_arg(args,unsigned long long);
  else if (qualifier == 'l')
   num = __builtin_va_arg(args,unsigned long);
  else if (qualifier == 'h') {
   num = (unsigned short) __builtin_va_arg(args,int);
   if (flags & 2)
    num = (short) num;
  } else if (flags & 2)
   num = __builtin_va_arg(args,int);
  else
   num = __builtin_va_arg(args,unsigned int);
  count += number(tx_byte, num, base, field_width, precision, flags);
 }
 return count;
}



static char *str_buf;
static int str_tx_byte(int byte)
{
 *str_buf = byte;
 str_buf++;
 return byte;
}

int vsprintf(char * buf, const char *fmt, va_list args)
{
 int i;
 str_buf = buf;
 i = vtxprintf(str_tx_byte, fmt, args);


 *str_buf = '\0';
 return i;
}

int sprintf(char * buf, const char *fmt, ...)
{
 va_list args;
 int i;

 __builtin_va_start(args,fmt);
 i=vsprintf(buf,fmt,args);
 __builtin_va_end(args);
 return i;
}

int printf(const char *fmt, ...)
{
 va_list args;
 int i;

 __builtin_va_start(args,fmt);
 i = vtxprintf(putchar, fmt, args);
 __builtin_va_end(args);
 return i;
}
 



From hpa at zytor.com  Wed Jun 11 18:55:32 2008
From: hpa at zytor.com (H. Peter Anvin)
Date: Wed, 11 Jun 2008 09:55:32 -0700
Subject: [coreboot] mkelfimage intelligent placement of ramdisk
In-Reply-To: <20080611153249.GB25014@cosmic.amd.com>
References: <484EE7CD.6030303@redhat.com>
	<002a01c8cb3c$595702d0$0023040a@chimp>
	<484EF922.7020502@redhat.com> <20080611030736.20175.qmail@stuge.se>
	<484F6237.1080608@zytor.com> <20080611103701.9675.qmail@stuge.se>
	<20080611153249.GB25014@cosmic.amd.com>
Message-ID: <48500384.2030005@zytor.com>

Jordan Crouse wrote:
> On 11/06/08 12:37 +0200, Peter Stuge wrote:
>> On Tue, Jun 10, 2008 at 10:27:19PM -0700, H. Peter Anvin wrote:
>>> APIs exist to decouple modules.  Use them.  I understand there is
>>> finally some serious work going on in that vein in the coreboot
>>> community; this makes sense.
>>>
>>> The "no API" model is idiotic.
>> You don't feel it is possible/desirable to have all hardware code
>> in the operating system so that boot code can be oneshot?
>>
>> (of course the boot code still has to hand over state information)
>>
>> What would the ideal abstraction be then?
> 
> Interestingly enough, this thread is intertwining with the "coreboot
> BIOSisms" threat, and Peter has gotten his wish.. "Of course, as mere
> producers we don't care too much, it would be interesting to discuss
> also with the consumers".  Well, here is the owner of the init code 
> for the only operating system we can boot.  I think he qualifies as
> an interested party.
> 
> I don't presume to speak for hpa, but I do think I feel his concern.
> His areas of interest aren't so very much different then ours.  With
> syslinux and the kernel init code, his main goal is to take a decidedly
> complex architecture and beat it into sanity.  And for the most part,
> it will just work on any given x86 architecture - hpa isn't running around
> trying Linux on every new platform that is coming out - he trusts that
> the BIOS will give him the information that he needs.
> 
> Now, you can argue that that the API is old and archaic and stupid.
> Those are legitimate arguments, but they aren't interesting for the guy
> who doesn't want to have to worry about changing his code every time a 
> BIOS software developer thinks he has something clever. 
> 
> This is a problem we are already struggling with.  Why doesn't gPXE work
> out of the box?  Why wouldn't libpayload + coreinfo work on non coreboot
> BIOSen (by all accounts it should).  The first answer is because we need
> to add coreboot specific code to gPXE, and the second answer is that
> we have _only_ coreboot specific code in libpayload.  These are probably
> not optimal solutions.
> 
> Now, I don't know how hpa feels about the traditional BIOS API - perhaps he
> too would be open to a new way of doing things.  But even if he is, there are
> lots of API consumers right behind him (ACPI, mptable, etc, etc) that would
> need convincing as well.  Its a long road to travel, and we may never
> reach the end successfully.  I think what Kevin is doing is exactly the
> right course of action - we need to play well with others, sooner rather
> then later and then slowly bring them along with us.   That is the only
> way we can be successful.  Storming in and saying "we are clever, support
> us or die!" is not a great way to win over the world.
> 
> I'll leave you with a thought - the first guy who stood up and said
> "Hey lets overthrow the king" got his head cut off.  It takes
> consensus to make permanent change.
> 

Thank you for saying this way more eloquently than I would have (I have 
gotten a bit hoarse over the years from yelling the same message too 
many times.)  Your description above summarizes the issues really quite 
nicely.

As far as the BIOS API is concerned, it is archaic, it's ugly, it is 
ubiquitous, and it works.  The latter two means that no matter what 
happens, I have to support the BIOS API.  Anything coreboot does 
differently means more work (or that I'll simply say "forget about that 
stupid thing"), *especially* since there is a cost to multiple solutions 
for anything.  As you point out, once you abandon the BIOS model you 
have a lot of things behind it that need changing, and largely for no 
good reason.

The fact that legacy BIOS runs in 16-bit mode is almost an advantage, 
because it has kept it from mushrooming too far out of control.  It's a 
pretty small API and relatively well-behaved, believe it or not. 
Furthermore, it is quite limited, which has prevented people from 
abusing it too badly -- for one thing, noone expects legacy BIOS to be fast.

I would absolutely love for Coreboot to get involved as a full-fledged 
player on the proper BIOS stage, first of all because it would give a 
full-featured open source firmware solution, and second of all because 
it might give some leverage when it comes to driving that platform; 
Intel used to sort of take that role until they got obsessed with EFI.

As far as implementation is concerned - there is no law that says that 
the legacy BIOS needs to be written in 16-bit code.  One could even trap 
to SMM on a BIOS interrupt and implement the actual service routines in 
that mode.

	-hpa



From hpa at zytor.com  Wed Jun 11 18:58:58 2008
From: hpa at zytor.com (H. Peter Anvin)
Date: Wed, 11 Jun 2008 09:58:58 -0700
Subject: [coreboot] [patch] mkelfimage intelligent placement of ramdisk
In-Reply-To: <20080611030736.20175.qmail@stuge.se>
References: <484EE7CD.6030303@redhat.com>
	<002a01c8cb3c$595702d0$0023040a@chimp>
	<484EF922.7020502@redhat.com> <20080611030736.20175.qmail@stuge.se>
Message-ID: <48500452.6090906@zytor.com>

Peter Stuge wrote:
> 
>> He said wraplinux relies upon "int 15h, AX=2401h (unless A20 is
>> enabled) and int 15h, AX=E820h (for probing memory)".  He indicated
>> that he really dislikes the design of coreboot and will likely
>> never support it.
> 
> I would very much appreciate if you could expand on this.
> 

I should point out something here:

wraplinux uses a subset of the BIOS calls used by the Linux setup code 
itself.  If you can boot a Linux kernel from the standard 16-bit entry 
point, wraplinux should work out of the box.

	-hpa



From Ken.Fuchs at bench.com  Wed Jun 11 21:15:04 2008
From: Ken.Fuchs at bench.com (Ken.Fuchs at bench.com)
Date: Wed, 11 Jun 2008 14:15:04 -0500
Subject: [coreboot] How to build coreboot for AMD/Opteron nVnida/CK804 CRB
Message-ID: <AA28F077645B324881335614E4F7C4284A490B@win-ex01.bench.com>

There doesn't seem to be a target defined for this board
in the current source for coreboot.

I tried:

$ cd ./targets
$ ./buildtarget nvidia/ck804
No target config file found
Tried both nvidia/ck804 and nvidia/ck804/Config.lb
$

Where are the target files for the Opteron/CK804 CRB?

--- Chipset Reference Boards ---

It is very important that coreboot contains the targets
of all chipset reference boards, since mainboard designers
often use them as the basis of their own designs.  Thus
coreboot ports from these chipset reference boards to the
mainboards based on them would seem to be the easiest way
to do these board-level ports.  The only exception might
be a mainboard family whose various members may be closer
in design that the chipset reference board.

Sincerely,

Ken Fuchs



From joe at settoplinux.org  Wed Jun 11 22:26:26 2008
From: joe at settoplinux.org (Joseph Smith)
Date: Wed, 11 Jun 2008 16:26:26 -0400
Subject: [coreboot] How to build coreboot for AMD/Opteron nVnida/CK804
	CRB
In-Reply-To: <AA28F077645B324881335614E4F7C4284A490B@win-ex01.bench.com>
References: <AA28F077645B324881335614E4F7C4284A490B@win-ex01.bench.com>
Message-ID: <1A15C993AE2B4A0D853E8E08C4821DF9@smitty2m>



> -----Original Message-----
> From: coreboot-bounces at coreboot.org [mailto:coreboot-bounces at coreboot.org]
> On Behalf Of Ken.Fuchs at bench.com
> Sent: Wednesday, June 11, 2008 3:15 PM
> To: coreboot at coreboot.org
> Subject: [coreboot] How to build coreboot for AMD/Opteron nVnida/CK804 CRB
> 
> There doesn't seem to be a target defined for this board
> in the current source for coreboot.
> 
> I tried:
> 
> $ cd ./targets
> $ ./buildtarget nvidia/ck804
> No target config file found
> Tried both nvidia/ck804 and nvidia/ck804/Config.lb
> $
> 
> Where are the target files for the Opteron/CK804 CRB?
> 
> --- Chipset Reference Boards ---
> 
> It is very important that coreboot contains the targets
> of all chipset reference boards, since mainboard designers
> often use them as the basis of their own designs.  Thus
> coreboot ports from these chipset reference boards to the
> mainboards based on them would seem to be the easiest way
> to do these board-level ports.  The only exception might
> be a mainboard family whose various members may be closer
> in design that the chipset reference board.
> 

Sorry I don't think that board is supported by coreboot. I know in the past
it is very hard to get nvidia chips supported due to lack of datasheets,
public information, etc.

Here is the list of boards that are supported:
http://www.coreboot.org/Supported_Motherboards



Thanks,
Joseph Smith
Set-Top-Linux
www.settoplinux.org




From Ken.Fuchs at bench.com  Wed Jun 11 23:54:23 2008
From: Ken.Fuchs at bench.com (Ken.Fuchs at bench.com)
Date: Wed, 11 Jun 2008 16:54:23 -0500
Subject: [coreboot] How to build coreboot for AMD/Opteron nVnida/CK804
	CRB
In-Reply-To: <1A15C993AE2B4A0D853E8E08C4821DF9@smitty2m>
Message-ID: <AA28F077645B324881335614E4F7C4284A490C@win-ex01.bench.com>

> Ken Fuchs wrote:

> > There doesn't seem to be a target defined for this board
> > in the current source for coreboot.
> > 
> > I tried:
> > 
> > $ cd ./targets
> > $ ./buildtarget nvidia/ck804
> > No target config file found
> > Tried both nvidia/ck804 and nvidia/ck804/Config.lb
> > $
> > 
> > Where are the target files for the Opteron/CK804 CRB?
> > 
> > --- Chipset Reference Boards ---
> > 
> > It is very important that coreboot contains the targets
> > of all chipset reference boards, since mainboard designers
> > often use them as the basis of their own designs.  Thus
> > coreboot ports from these chipset reference boards to the
> > mainboards based on them would seem to be the easiest way
> > to do these board-level ports.  The only exception might
> > be a mainboard family whose various members may be closer
> > in design that the chipset reference board.

Joseph Smith wrote:
 
> Sorry I don't think that board is supported by coreboot. I 
> know in the past
> it is very hard to get nvidia chips supported due to lack of 
> datasheets,
> public information, etc.

The nVidia CK804 CRB is supported by coreboot
(or at least it should be supported).  I have
three year old source code based on LinuxBIOS
that supports this board.  Our code was never
submitted, because another CK804 port of
LinuxBIOS was completed and submitted before
ours.

Three years ago, I didn't have any trouble
getting technical information for the nVidia
CK804 chipset.  An NDA was required.  nVidia
was very easy to work with, especially while
reviewing our source code.  We were provided
with good support by nVidia.

--- CK804 code in official LinuxBIOS source code ---

The nVidia CK804 chipset is definitely supported
by coreboot.  See ./src/southbridge/nvidia/ck804/.
What happened to the mainboard and target files
of the nVidia CK804 CRB board?  Did someone remove
them from the coreboot repository?

I also have a snapshot of the official LinuxBIOS
code right after the other CK804 port was officially
submitted (three years ago).  It contains
./src/mainboard/nvidia/nf4crb, so the CK804
mainboard files were in the official tree.  However,
I see no evidence that the target files were in that
snapshot, but I assumed that they were added later.

Sincerely,

Ken Fuchs



From joe at settoplinux.org  Thu Jun 12 04:02:08 2008
From: joe at settoplinux.org (Joseph Smith)
Date: Wed, 11 Jun 2008 22:02:08 -0400
Subject: [coreboot] How to build coreboot for AMD/Opteron nVnida/CK804CRB
In-Reply-To: <AA28F077645B324881335614E4F7C4284A490C@win-ex01.bench.com>
References: <1A15C993AE2B4A0D853E8E08C4821DF9@smitty2m>
	<AA28F077645B324881335614E4F7C4284A490C@win-ex01.bench.com>
Message-ID: <A8CFE8C0B1A6490DA3F49AD9F7F4B8D8@smitty2m>


> -----Original Message-----
> From: coreboot-bounces at coreboot.org [mailto:coreboot-bounces at coreboot.org]
> On Behalf Of Ken.Fuchs at bench.com
> Sent: Wednesday, June 11, 2008 5:54 PM
> To: coreboot at coreboot.org
> Cc: joe at settoplinux.org
> Subject: Re: [coreboot] How to build coreboot for AMD/Opteron
> nVnida/CK804CRB
> 
> > Ken Fuchs wrote:
> 
> > > There doesn't seem to be a target defined for this board
> > > in the current source for coreboot.
> > >
> > > I tried:
> > >
> > > $ cd ./targets
> > > $ ./buildtarget nvidia/ck804
> > > No target config file found
> > > Tried both nvidia/ck804 and nvidia/ck804/Config.lb
> > > $
> > >
> > > Where are the target files for the Opteron/CK804 CRB?
> > >
> > > --- Chipset Reference Boards ---
> > >
> > > It is very important that coreboot contains the targets
> > > of all chipset reference boards, since mainboard designers
> > > often use them as the basis of their own designs.  Thus
> > > coreboot ports from these chipset reference boards to the
> > > mainboards based on them would seem to be the easiest way
> > > to do these board-level ports.  The only exception might
> > > be a mainboard family whose various members may be closer
> > > in design that the chipset reference board.
> 
> Joseph Smith wrote:
> 
> > Sorry I don't think that board is supported by coreboot. I
> > know in the past
> > it is very hard to get nvidia chips supported due to lack of
> > datasheets,
> > public information, etc.
> 
> The nVidia CK804 CRB is supported by coreboot
> (or at least it should be supported).  I have
> three year old source code based on LinuxBIOS
> that supports this board.  Our code was never
> submitted, because another CK804 port of
> LinuxBIOS was completed and submitted before
> ours.
> 
> Three years ago, I didn't have any trouble
> getting technical information for the nVidia
> CK804 chipset.  An NDA was required.  nVidia
> was very easy to work with, especially while
> reviewing our source code.  We were provided
> with good support by nVidia.
> 
> --- CK804 code in official LinuxBIOS source code ---
> 
> The nVidia CK804 chipset is definitely supported
> by coreboot.  See ./src/southbridge/nvidia/ck804/.
> What happened to the mainboard and target files
> of the nVidia CK804 CRB board?  Did someone remove
> them from the coreboot repository?
> 
> I also have a snapshot of the official LinuxBIOS
> code right after the other CK804 port was officially
> submitted (three years ago).  It contains
> ./src/mainboard/nvidia/nf4crb, so the CK804
> mainboard files were in the official tree.  However,
> I see no evidence that the target files were in that
> snapshot, but I assumed that they were added later.
> 
Hmm, that is strange. That was before my time. I have only been involved
with coreboot for about 1 1/2 years. What was the revision that it was
committed to the svn? Maybe you could research a few revisions after that to
see when it got dropped? Maybe search the mailing list archives to see if
there are any discussions on why it got dropped?


Thanks,
Joseph Smith
Set-Top-Linux
www.settoplinux.org




From joe at settoplinux.org  Thu Jun 12 04:16:45 2008
From: joe at settoplinux.org (Joseph Smith)
Date: Wed, 11 Jun 2008 22:16:45 -0400
Subject: [coreboot] How to build coreboot for AMD/Opteron nVnida/CK804CRB
In-Reply-To: <AA28F077645B324881335614E4F7C4284A490C@win-ex01.bench.com>
References: <1A15C993AE2B4A0D853E8E08C4821DF9@smitty2m>
	<AA28F077645B324881335614E4F7C4284A490C@win-ex01.bench.com>
Message-ID: <87CC90ABB7F84CB8B449058B03A723E9@smitty2m>



> The nVidia CK804 chipset is definitely supported
> by coreboot.  See ./src/southbridge/nvidia/ck804/.

Your right, it looks like there are several Tyan boards that use the nVidia
CK804.

Thanks,
Joseph Smith
Set-Top-Linux
www.settoplinux.org




From njdube at gmail.com  Thu Jun 12 08:34:18 2008
From: njdube at gmail.com (Nathaniel Dube)
Date: Thu, 12 Jun 2008 01:34:18 -0500
Subject: [coreboot] (no subject)
Message-ID: <200806120134.27473.njdube@gmail.com>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

First off, I'm by no means a engineer.  This message is going out to real 
engineers that might have interest in bringing the idea I'm about to share 
with you to reality.  This idea came to me after some light reading about 
rootkits on wikipedia and playing around with the program "rkhunter".  

Malware designers are writing code that can infect a system via rootkits.  
I've even read about the possibility of malware that can infect ROM chips on 
mother boards as well as ROM chips on PCI cards.  Meaning, anything that is 
rewritable isn't safe from malware.  Then it dawned on me that most of these 
security issues could be minimized at the hardware level at preboot, meaning 
before the operating system loads.

My brother brought his laptop to me complaning the internet wont work and that 
it's slow as a whale turd.  When I looked at it I found it swarming with 
viruses.  I asked him what happened to the firewall and antivirus that In 
installed for him and he said he turned them off because the firewall was 
messing with his internet and he didn't know how to turn it off with out also 
turning off the antivirus.  I think it was Eset Internet Security.  I use 
Linux on my system so I don't touch Windows software all that often.  I've 
come to the conclusion that it doesn't matter what software you put on there 
or what you do, stupid users (and most users are stupid) will fsck up there 
system.

That's when I decided that mother boards need to be dramatically redesigned 
from the ground up with a proactive role in security.  Now here's where I 
will start with my wonderful idea that will save the world.  You will either 
see that world with me or you wont.

I'm sure most of you are aware of the history of the BIOS and the ROM's 
they're on.  Back in the day they really where ROM in every sense of the term 
that they where READ only.  They where embed on the board so you would need a 
solder iron to remove them.  Then they came out with the removable kind with 
sockets that you can replace with a new chip.  Then comes the kind you can 
flash with software but are embedded.  I'm sorry but impeded un-removeable ROM 
chips are completely asinine.  Now on to my idea.

Instead of one ROM chip for the BIOS there should be 3 and use "coreboot" as 
the BIOS.  All 3 will utilize sockets to be removeable for easy replacement.  
The first chip will have the purpose as a backup of the default BIOS and the 
chip will be read only.  The second chip will house a copy of the primary 
BIOS which will be rewritable and allow for updates.  The third chip I will 
call the ESP (Emergency Security Protocols) ROM which may or may not be read 
only, I haven't decided yet.  The third chip will have the open source 
programs rkhunter, clamav and perhaps other programs that might be useful for 
a preboot.

In the event the other two are corrupted for what ever reason you need only 
flip a jumper, turn on the computer and the backup BIOS takes control and 
allows you to wipe the other two chips and restore a rewritable copy of the 
BIOS to chip 2 and the ESP BIOS to chip 3.  The backup BIOS will also have 
the Linux program "wipe" so in the unlikeliness a rootkit takes control of 
chips 2 and 3 chip 1 will wipe it out and start from scratch.

This board will also have integrated wifi as well as lan making it easy to get 
a internet connection.  The goal being to be able to update the signatures of 
rkhunter and clamav as well as update both firmware by direct download before 
the OS even loads.  This entire process will have a liberal use of checksums 
to make sure at no time is any malware being installed during the preboot 
process.

I'm still trying to work out the finer details in my head.  So my idea may 
make sense or it may not.  Ultimately what I'm trying to do is build a mother 
board with BIOS backup/security redundancy.  The 3 chips act as a triad that 
protect one another.  The board should be designed so it tries to load the 
second chip with the rewritable BIOS and use the third chip to do a quick 
self scan for rootkits.  If for some reason the first BIOS wont load it will 
fall back on the backup BIOS restoring the primary.  Perhaps some one can 
share a better way of implimenting my idea.  The goal is to make it damn near 
impossible for malware to alter or change the BIOS or load at preboot.  These 
security meause could also be used to protect rewritable ROM on other 
hardware.

Please share your thoughts.  I would really like to see a board like this see 
the light of reality.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.4-svn0 (GNU/Linux)

iD8DBQFIUMNzvsn/sQCIOqQRAqG+AJ9t1W14EgBRJQrOmvdpaNK5edMeNACggq+G
ij2koHbQDzhTVXpv+AQbEHE=
=V7L3
-----END PGP SIGNATURE-----



From njdube at gmail.com  Thu Jun 12 08:37:43 2008
From: njdube at gmail.com (Nathaniel Dube)
Date: Thu, 12 Jun 2008 01:37:43 -0500
Subject: [coreboot] (no subject)
In-Reply-To: <200806120134.27473.njdube@gmail.com>
References: <200806120134.27473.njdube@gmail.com>
Message-ID: <200806120137.44268.njdube@gmail.com>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

I just realized I forgot a subject.  Sorry about that, please disregard this 
email.  I'll do a new one, past and copy the write a subject.  Again, sorry.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.4-svn0 (GNU/Linux)

iD8DBQFIUMQ4vsn/sQCIOqQRApaUAJ0QkUiQ15k24Yy0XrwjWsDIJwc9aQCfVw7R
lyyO8vq8lWoWVP490+tKC8o=
=JPOz
-----END PGP SIGNATURE-----



From njdube at gmail.com  Thu Jun 12 08:42:30 2008
From: njdube at gmail.com (Nathaniel Dube)
Date: Thu, 12 Jun 2008 01:42:30 -0500
Subject: [coreboot] 3 Chip Open BIOS + ESP: Backup/Secure BIOS with
	Redundancy
Message-ID: <200806120142.30389.njdube@gmail.com>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

First off, I'm by no means a engineer.  This message is going out to real 
engineers that might have interest in bringing the idea I'm about to share 
with you to reality.  This idea came to me after some light reading about 
rootkits on wikipedia and playing around with the program "rkhunter".  

Malware designers are writing code that can infect a system via rootkits.  
I've even read about the possibility of malware that can infect ROM chips on 
mother boards as well as ROM chips on PCI cards.  Meaning, anything that is 
rewritable isn't safe from malware.  Then it dawned on me that most of these 
security issues could be minimized at the hardware level at preboot, meaning 
before the operating system loads.

My brother brought his laptop to me complaning the internet wont work and that 
it's slow as a whale turd.  When I looked at it I found it swarming with 
viruses.  I asked him what happened to the firewall and antivirus that In 
installed for him and he said he turned them off because the firewall was 
messing with his internet and he didn't know how to turn it off with out also 
turning off the antivirus.  I think it was Eset Internet Security.  I use 
Linux on my system so I don't touch Windows software all that often.  I've 
come to the conclusion that it doesn't matter what software you put on there 
or what you do, stupid users (and most users are stupid) will fsck up there 
system.

That's when I decided that mother boards need to be dramatically redesigned 
from the ground up with a proactive role in security.  Now here's where I 
will start with my wonderful idea that will save the world.  You will either 
see that world with me or you wont.

I'm sure most of you are aware of the history of the BIOS and the ROM's 
they're on.  Back in the day they really where ROM in every sense of the term 
that they where READ only.  They where embed on the board so you would need a 
solder iron to remove them.  Then they came out with the removable kind with 
sockets that you can replace with a new chip.  Then comes the kind you can 
flash with software but are embedded.  I'm sorry but impeded un-removeable ROM 
chips are completely asinine.  Now on to my idea.

Instead of one ROM chip for the BIOS there should be 3 and use "coreboot" as 
the BIOS.  All 3 will utilize sockets to be removeable for easy replacement.  
The first chip will have the purpose as a backup of the default BIOS and the 
chip will be read only.  The second chip will house a copy of the primary 
BIOS which will be rewritable and allow for updates.  The third chip I will 
call the ESP (Emergency Security Protocols) ROM which may or may not be read 
only, I haven't decided yet.  The third chip will have the open source 
programs rkhunter, clamav and perhaps other programs that might be useful for 
a preboot.

In the event the other two are corrupted for what ever reason you need only 
flip a jumper, turn on the computer and the backup BIOS takes control and 
allows you to wipe the other two chips and restore a rewritable copy of the 
BIOS to chip 2 and the ESP BIOS to chip 3.  The backup BIOS will also have 
the Linux program "wipe" so in the unlikeliness a rootkit takes control of 
chips 2 and 3 chip 1 will wipe it out and start from scratch.

This board will also have integrated wifi as well as lan making it easy to get 
a internet connection.  The goal being to be able to update the signatures of 
rkhunter and clamav as well as update both firmware by direct download before 
the OS even loads.  This entire process will have a liberal use of checksums 
to make sure at no time is any malware being installed during the preboot 
process.

I'm still trying to work out the finer details in my head.  So my idea may 
make sense or it may not.  Ultimately what I'm trying to do is build a mother 
board with BIOS backup/security redundancy.  The 3 chips act as a triad that 
protect one another.  The board should be designed so it tries to load the 
second chip with the rewritable BIOS and use the third chip to do a quick 
self scan for rootkits.  If for some reason the first BIOS wont load it will 
fall back on the backup BIOS restoring the primary.  Perhaps some one can 
share a better way of implimenting my idea.  The goal is to make it damn near 
impossible for malware to alter or change the BIOS or load at preboot.  These 
security meause could also be used to protect rewritable ROM on other 
hardware.

Please share your thoughts.  I would really like to see a board like this see 
the light of reality.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.4-svn0 (GNU/Linux)

iD8DBQFIUMVWvsn/sQCIOqQRAnqwAJ9lYdjiBqnaVArQvHZIcIIaD8A0gQCfSKn1
YYOUf33mToJpZ7N/HI6Q7jY=
=VeHI
-----END PGP SIGNATURE-----



From corey.osgood at gmail.com  Thu Jun 12 09:46:19 2008
From: corey.osgood at gmail.com (Corey Osgood)
Date: Thu, 12 Jun 2008 03:46:19 -0400
Subject: [coreboot] 3 Chip Open BIOS + ESP: Backup/Secure BIOS with
	Redundancy
In-Reply-To: <200806120142.30389.njdube@gmail.com>
References: <200806120142.30389.njdube@gmail.com>
Message-ID: <dd3c80060806120046n6779be09od58cfdca59bd8a75@mail.gmail.com>

I'd just like to point out some flaws in your proposal:

1. If Chip 1 is read only, and something happens, chips 2 and 3 are
restored to whatever version they were originally, leaving chips 2 and
3 open to the same vulnerability, should it not be eradicated from the
hard drive or fixed by an update.
2. Without some sort of extremely efficient compression algorithm,
Chip 1 would have to be as large as Chip 2 + 3. I'm guessing it would
probably end up being 4 chips, all the same size.
3. How is Chip 3 to determine what network to connect to? Can you
really fit a networking stack, dhcp client, and secure ftp client into
1 or 2MB or less? How much time would be added to the boot time for
Chip 3 to identify a network, connect to it, get an IP, and then check
the versioning and potentially download an update and apply it?
4. What happens if the download server is compromised? Or if the
download location is forced to move? Do you really like the idea of
writing down 75 character web addresses so you can type them in to a
BIOS (or rather, payload) configuration menu, to change an update
path? What happens if Chip 3 needs to get restored?
5. How does this protect against malicious/infected PCI roms?
6. Do you honestly believe your brother's type of ignorance can be
fixed by a more secure BIOS? Seriously, the type of people who have
those kinds of problems, viruses and malware running amuck, would
never realize their BIOS had a problem, wouldn't open their case to
realize there's a switch on the board, and probably wouldn't even read
the manual to find out it was there or what it did. Proper antivirus
software, malware protection, and a decent firewall, combined with
reflashing the BIOS every once in a while, can give exactly the same
result. I know several people who had me work on their computers, back
when windows 98 and ME were the current versions, they were having
horrible problems with their computers running slow, this file or that
was missing/damaged, etc. Come to find out, in at least half a dozen
cases, they were canceling scandisk every time the computer started.
Let it run, and in every case, problem solved. What happens when your
rootkit detection program realizes the BIOS is messed up, and asks the
user to get down on their hands and knees, dig the computer out of the
desk they so lovingly hid it in, open the case, flip a switch, get it
all back together so they can restart it, wait 5 minutes, and repeat?

I'm not an engineer either, yet, working on my degree, I'm just trying
to give you some things to consider. You should also consider that
vendors don't like spending any more money then they absolutely have
to, so adding 2 or 3 redundant chips is not cool. Also, most current
hardware only supports one flash chip, or else 2 flash chips but on 2
different interfaces (SPI and LPC, for example).

-Corey

On Thu, Jun 12, 2008 at 2:42 AM, Nathaniel Dube <njdube at gmail.com> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> First off, I'm by no means a engineer.  This message is going out to real
> engineers that might have interest in bringing the idea I'm about to share
> with you to reality.  This idea came to me after some light reading about
> rootkits on wikipedia and playing around with the program "rkhunter".
>
> Malware designers are writing code that can infect a system via rootkits.
> I've even read about the possibility of malware that can infect ROM chips on
> mother boards as well as ROM chips on PCI cards.  Meaning, anything that is
> rewritable isn't safe from malware.  Then it dawned on me that most of these
> security issues could be minimized at the hardware level at preboot, meaning
> before the operating system loads.
>
> My brother brought his laptop to me complaning the internet wont work and that
> it's slow as a whale turd.  When I looked at it I found it swarming with
> viruses.  I asked him what happened to the firewall and antivirus that In
> installed for him and he said he turned them off because the firewall was
> messing with his internet and he didn't know how to turn it off with out also
> turning off the antivirus.  I think it was Eset Internet Security.  I use
> Linux on my system so I don't touch Windows software all that often.  I've
> come to the conclusion that it doesn't matter what software you put on there
> or what you do, stupid users (and most users are stupid) will fsck up there
> system.
>
> That's when I decided that mother boards need to be dramatically redesigned
> from the ground up with a proactive role in security.  Now here's where I
> will start with my wonderful idea that will save the world.  You will either
> see that world with me or you wont.
>
> I'm sure most of you are aware of the history of the BIOS and the ROM's
> they're on.  Back in the day they really where ROM in every sense of the term
> that they where READ only.  They where embed on the board so you would need a
> solder iron to remove them.  Then they came out with the removable kind with
> sockets that you can replace with a new chip.  Then comes the kind you can
> flash with software but are embedded.  I'm sorry but impeded un-removeable ROM
> chips are completely asinine.  Now on to my idea.
>
> Instead of one ROM chip for the BIOS there should be 3 and use "coreboot" as
> the BIOS.  All 3 will utilize sockets to be removeable for easy replacement.
> The first chip will have the purpose as a backup of the default BIOS and the
> chip will be read only.  The second chip will house a copy of the primary
> BIOS which will be rewritable and allow for updates.  The third chip I will
> call the ESP (Emergency Security Protocols) ROM which may or may not be read
> only, I haven't decided yet.  The third chip will have the open source
> programs rkhunter, clamav and perhaps other programs that might be useful for
> a preboot.
>
> In the event the other two are corrupted for what ever reason you need only
> flip a jumper, turn on the computer and the backup BIOS takes control and
> allows you to wipe the other two chips and restore a rewritable copy of the
> BIOS to chip 2 and the ESP BIOS to chip 3.  The backup BIOS will also have
> the Linux program "wipe" so in the unlikeliness a rootkit takes control of
> chips 2 and 3 chip 1 will wipe it out and start from scratch.
>
> This board will also have integrated wifi as well as lan making it easy to get
> a internet connection.  The goal being to be able to update the signatures of
> rkhunter and clamav as well as update both firmware by direct download before
> the OS even loads.  This entire process will have a liberal use of checksums
> to make sure at no time is any malware being installed during the preboot
> process.
>
> I'm still trying to work out the finer details in my head.  So my idea may
> make sense or it may not.  Ultimately what I'm trying to do is build a mother
> board with BIOS backup/security redundancy.  The 3 chips act as a triad that
> protect one another.  The board should be designed so it tries to load the
> second chip with the rewritable BIOS and use the third chip to do a quick
> self scan for rootkits.  If for some reason the first BIOS wont load it will
> fall back on the backup BIOS restoring the primary.  Perhaps some one can
> share a better way of implimenting my idea.  The goal is to make it damn near
> impossible for malware to alter or change the BIOS or load at preboot.  These
> security meause could also be used to protect rewritable ROM on other
> hardware.
>
> Please share your thoughts.  I would really like to see a board like this see
> the light of reality.
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v2.0.4-svn0 (GNU/Linux)
>
> iD8DBQFIUMVWvsn/sQCIOqQRAnqwAJ9lYdjiBqnaVArQvHZIcIIaD8A0gQCfSKn1
> YYOUf33mToJpZ7N/HI6Q7jY=
> =VeHI
> -----END PGP SIGNATURE-----
>
> --
> coreboot mailing list
> coreboot at coreboot.org
> http://www.coreboot.org/mailman/listinfo/coreboot
>



From njdube at gmail.com  Thu Jun 12 12:43:46 2008
From: njdube at gmail.com (Nathaniel Dube)
Date: Thu, 12 Jun 2008 05:43:46 -0500
Subject: [coreboot] 3 Chip Open BIOS + ESP: Backup/Secure BIOS with
	Redundancy
In-Reply-To: <dd3c80060806120046n6779be09od58cfdca59bd8a75@mail.gmail.com>
References: <200806120142.30389.njdube@gmail.com>
	<dd3c80060806120046n6779be09od58cfdca59bd8a75@mail.gmail.com>
Message-ID: <200806120543.54295.njdube@gmail.com>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Thursday 12 June 2008 02:46:19 am you wrote:
> 1. If Chip 1 is read only, and something happens, chips 2 and 3 are
> restored to whatever version they were originally, leaving chips 2 and
> 3 open to the same vulnerability, should it not be eradicated from the
> hard drive or fixed by an update.

Having the read only Backup-BIOS wipe the writable BIOS is simply a last case 
scenario.  It's a last line of defense incase your primary BIOS becomes 
foobar.  Keep in mind you would also have a software antivirus and firewall 
running on your operating system.  So if the malware happens to get through 
that it would then have to deal with the hardware rootkit protection in the 
mother board.  When ever you boot, the BIOS would use a checksum to check it 
self for modifications.  I could be wrong but I believe there are similar 
security protocols in SELinux and similar technologies to detect if the Linux 
kernel has been screwed with.

> 2. Without some sort of extremely efficient compression algorithm,
> Chip 1 would have to be as large as Chip 2 + 3. I'm guessing it would
> probably end up being 4 chips, all the same size.

I suppose I could make it little more simple and just have 2 chips.  One would 
be a backup and one for primary use.  I have a little flash drive in my 
pocket right now, it's 8 GB.  I'm sure we can design a sufficiently big 
enough chip to store the necessary software.

> 3. How is Chip 3 to determine what network to connect to? Can you
> really fit a networking stack, dhcp client, and secure ftp client into
> 1 or 2MB or less? How much time would be added to the boot time for
> Chip 3 to identify a network, connect to it, get an IP, and then check
> the versioning and potentially download an update and apply it?

Sure, why not.  If you want 100% guarantee, then don't ever use the internet.  
If we can figure out how to buy stuff offline with strong enough encryption 
with a big enough margin of safety, I'm sure we can figure out something on 
how to download updates.

> 4. What happens if the download server is compromised? Or if the
> download location is forced to move? Do you really like the idea of
> writing down 75 character web addresses so you can type them in to a
> BIOS (or rather, payload) configuration menu, to change an update
> path? What happens if Chip 3 needs to get restored?

I really don't see that happening.  I don't remember ever having any issues 
with download patches for openSUSE.  Now that I mention it, the people at 
Novell have their main update domain bounce you to random mirrors.  So when 
you download updates, you're not allways getting them from the same system.  
Just incase one goes down it'll bounce you to a different mirror.  Which 
means you don't have to waste time changing URLs for your updates.  Also, the 
RPM packages are signed with GPG keys from the people who manage the 
repositories you're downloading from.  It's to help protect you incase the 
servers are compromised. ;-)

> 5. How does this protect against malicious/infected PCI roms?

It would be possible in theory that when you install new hardware that have 
writable ROMs (video card maybe I'm not sure there are any that are writable) 
that your mother board makes a checksum of that ROM's firmware.  So on a next 
reboot your mother board does a quick check to see if there where any changes 
and alert you if there is.  Now if we could make this board really clever we 
could give it enough room to make backups as well as checksums of all the 
firmware off all your hardware.  Then if something is changed it could either 
ask you if you want to restore from backup or incase of stupid users have it 
set to do it automatically.

> 6. Do you honestly believe your brother's type of ignorance can be
> fixed by a more secure BIOS?

There is no simple fix for stupidity but to go for a car metaphore for a 
moment.  You have locks and keys for your house and car.  Sure, if some 
people wanted to bad enough they can just break the window hot wire your car 
and drive off or pick the lock on your house and steal your TV.  Then you can 
install a car alarm and a GPS for the cops and install a security system in 
your house.  It's a cat and mouse game.  Persistant people will find ways 
around almost any locked door.  But that's no excuse not to lock your door.  
While security may not keep every one out, it'll keep more people out then if 
you use nothing at all. ;-)

> Seriously, the type of people who have 
> those kinds of problems, viruses and malware running amuck, would
> never realize their BIOS had a problem, wouldn't open their case to
> realize there's a switch on the board, and probably wouldn't even read
> the manual to find out it was there or what it did.

Instead of a jumper I suppose you can design it to be automatic in the 
instance the writable BIOS failed a cheksum.  The system would then reboot it 
self, restore from backups after wiping the infected BIOS, download updates 
for rkhunter and clamav.  Then the BIOS would force clamav to scan the system 
for infection.  Most of this can be done automatically in a clever way in the 
same way scandisk runs on windows if you shut it down wrong.  Something 
similar hapens on Linux.

Now I'm not suggesting a really long boot process every time you turn on the 
system.  On every boot it would only check the BIOS for modification and 
maybe the MBR then continue on it's marry way.  All this it meant to do is 
help protect against rootkits.  This could also help serve as a protection 
measure against failed BIOS flashes to update the BIOS.  Which has happened 
to me before.  I ordered a board for my dad and noticed the BIOS was out of 
date.  I followed the directions to the letter.  Downloaded the updates from 
the companies site attempted to flash the system.  Everything appeared to 
work.  But when I rebooted the damn thing all I got was a black screen.

Now if mother boards had been built with a second read only chip as a backup 
to restore from I wouldn't have waisted days sending it back in the mail 
telling them it was DOA so I can get another one.

> Proper antivirus software, malware protection, and a decent firewall, 
combined with reflashing the BIOS every once in a while, can give exactly the 
same result.

This might work for people like you and me but this wont work for the average 
person.

> I know several people who had me work on their computers, back 
> when windows 98 and ME were the current versions, they were having
> horrible problems with their computers running slow, this file or that
> was missing/damaged, etc. Come to find out, in at least half a dozen
> cases, they were canceling scandisk every time the computer started.

I find most people do that with everything that seems to be a boundary between 
them and what they really feal like doing on the computer. If it comes to 
taking maybe 10 seconds to read a security alert from their antivirus or 
firewall or spending that 10 seconds on myspace they'll choose myspace every 
time and just click what every to make the window go away.  Which is what my 
brother did with his firewall and ended up blocking all traffic.  He couldn't 
figure out what magical beast broke his internet so he managed to uninstall 
the firwall all together which took the antivirus with it.  Which is how he 
ended up infected with more viruses then a Nigerian hooker.  I had to tell 
him to stop using limewire and if he insisted on downloading stuff to learn 
how to use bittorrent.

> Let it run, and in every case, problem solved. What happens when your
> rootkit detection program realizes the BIOS is messed up, and asks the
> user to get down on their hands and knees, dig the computer out of the
> desk they so lovingly hid it in, open the case, flip a switch, get it
> all back together so they can restart it, wait 5 minutes, and repeat?

As I said above, a more clever system will do it all automatically.  If you 
shut down most operating systems improperly they're smart enough to run 
software to scan the file system for damage on the next reboot.  Perhaps my 
idea is overly complicated, but the point I was trying to make still stands.  
This is the 21st century, mother boards need to be taking a more active role 
in protecting them selves from the crap that's out there.  Because stupid 
users isn't going to do it for them.

> I'm not an engineer either, yet, working on my degree, I'm just trying
> to give you some things to consider. You should also consider that
> vendors don't like spending any more money then they absolutely have
> to, so adding 2 or 3 redundant chips is not cool. Also, most current
> hardware only supports one flash chip, or else 2 flash chips but on 2
> different interfaces (SPI and LPC, for example).

Hardware manufactories need to get off their lazy a$$es and start innovating.  
Oh well, there's always the technological singularity to look forward to.  
Then machines can fix them selves and not rely on stupid users.  Some times I 
wish the Matrix was reality.  A lot of people out there deserve to be turned 
into batteries. ;-)
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.4-svn0 (GNU/Linux)

iD8DBQFIUP3qvsn/sQCIOqQRAsrDAJ0c3Ls2SWFLW+OgHqxjJuGzcmv0cgCcD7uZ
GFi/3lCpnVf7ig4Z1RVWd+I=
=UBPq
-----END PGP SIGNATURE-----



From borsburn at codonics.com  Thu Jun 12 18:22:36 2008
From: borsburn at codonics.com (Bret Orsburn)
Date: Thu, 12 Jun 2008 12:22:36 -0400
Subject: [coreboot] Where to begin?
Message-ID: <48514D4C.7090304@codonics.com>

Corebooters:

Which version of coreboot, and which target, would you start with if you 
wanted to support this board:

http://www.bcmcom.com/bcm_product_mx965gme.htm

with a Celeron M processor.

Thanks.

----

    Bret Orsburn





From joe at settoplinux.org  Thu Jun 12 18:43:12 2008
From: joe at settoplinux.org (Joseph Smith)
Date: Thu, 12 Jun 2008 12:43:12 -0400
Subject: [coreboot] =?utf-8?q?Where_to_begin=3F?=
In-Reply-To: <48514D4C.7090304@codonics.com>
References: <48514D4C.7090304@codonics.com>
Message-ID: <11601fcf0e07a50f5e3a3229b5f022bb@imap.1and1.com>




On Thu, 12 Jun 2008 12:22:36 -0400, Bret Orsburn <borsburn at codonics.com>
wrote:
> Corebooters:
> 
> Which version of coreboot, and which target, would you start with if you
> wanted to support this board:
> 
> http://www.bcmcom.com/bcm_product_mx965gme.htm
> 
> with a Celeron M processor.
> 
If you want to work on this board to get it supported by coreboot I would
start with the mtarvon board with the i3100 northbridge and the i82801xx
southbridge. You also need to figure out what the superIO is and if that is
supported.

Wow, 16Mb SPI flash, I don't think you'll run out of room with that one.

Thanks,
Joseph Smith
Set-Top-Linux
www.settoplinux.org




From yinghailu at gmail.com  Thu Jun 12 20:34:35 2008
From: yinghailu at gmail.com (yhlu)
Date: Thu, 12 Jun 2008 11:34:35 -0700
Subject: [coreboot] How to build coreboot for AMD/Opteron nVnida/CK804
	CRB
In-Reply-To: <AA28F077645B324881335614E4F7C4284A490C@win-ex01.bench.com>
References: <1A15C993AE2B4A0D853E8E08C4821DF9@smitty2m>
	<AA28F077645B324881335614E4F7C4284A490C@win-ex01.bench.com>
Message-ID: <2ea3fae10806121134x5c6f1990s7861b80cb84f05db@mail.gmail.com>

On Wed, Jun 11, 2008 at 2:54 PM,  <Ken.Fuchs at bench.com> wrote:
>> Ken Fuchs wrote:
>
>> > There doesn't seem to be a target defined for this board
>> > in the current source for coreboot.
>> >
>> > I tried:
>> >
>> > $ cd ./targets
>> > $ ./buildtarget nvidia/ck804
>> > No target config file found
>> > Tried both nvidia/ck804 and nvidia/ck804/Config.lb
>> > $
>> >
>> > Where are the target files for the Opteron/CK804 CRB?
>> >
>> > --- Chipset Reference Boards ---
>> >
>> > It is very important that coreboot contains the targets
>> > of all chipset reference boards, since mainboard designers
>> > often use them as the basis of their own designs.  Thus
>> > coreboot ports from these chipset reference boards to the
>> > mainboards based on them would seem to be the easiest way
>> > to do these board-level ports.  The only exception might
>> > be a mainboard family whose various members may be closer
>> > in design that the chipset reference board.
>
> Joseph Smith wrote:
>
>> Sorry I don't think that board is supported by coreboot. I
>> know in the past
>> it is very hard to get nvidia chips supported due to lack of
>> datasheets,
>> public information, etc.
>
> The nVidia CK804 CRB is supported by coreboot
> (or at least it should be supported).  I have
> three year old source code based on LinuxBIOS
> that supports this board.  Our code was never
> submitted, because another CK804 port of
> LinuxBIOS was completed and submitted before
> ours.
>
> Three years ago, I didn't have any trouble
> getting technical information for the nVidia
> CK804 chipset.  An NDA was required.  nVidia
> was very easy to work with, especially while
> reviewing our source code.  We were provided
> with good support by nVidia.
>
> --- CK804 code in official LinuxBIOS source code ---
>
> The nVidia CK804 chipset is definitely supported
> by coreboot.  See ./src/southbridge/nvidia/ck804/.
> What happened to the mainboard and target files
> of the nVidia CK804 CRB board?  Did someone remove
> them from the coreboot repository?
>
> I also have a snapshot of the official LinuxBIOS
> code right after the other CK804 port was officially
> submitted (three years ago).  It contains
> ./src/mainboard/nvidia/nf4crb, so the CK804
> mainboard files were in the official tree.  However,
> I see no evidence that the target files were in that
> snapshot, but I assumed that they were added later.
>

i have src/mainboard/nvidia/crb in my local disk.

don't know why it is not made to public.

that should be something like s2895 but doesn't have 8131...

YH



From peter at stuge.se  Fri Jun 13 01:46:21 2008
From: peter at stuge.se (Peter Stuge)
Date: Fri, 13 Jun 2008 01:46:21 +0200
Subject: [coreboot] flashrom: Board enable for GIGABYTE GA-7VT600
Message-ID: <20080612234621.12778.qmail@stuge.se>

See patch.


//Peter
-------------- next part --------------
A non-text attachment was scrubbed...
Name: fr.ga7vt600.patch
Type: text/x-diff
Size: 956 bytes
Desc: not available
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20080613/541506d4/attachment.bin>

From lyos.gemininorezel at gmail.com  Fri Jun 13 01:48:32 2008
From: lyos.gemininorezel at gmail.com (Lyos Gemini Norezel)
Date: Thu, 12 Jun 2008 19:48:32 -0400
Subject: [coreboot] flashrom: Board enable for GIGABYTE GA-7VT600
In-Reply-To: <20080612234621.12778.qmail@stuge.se>
References: <20080612234621.12778.qmail@stuge.se>
Message-ID: <4851B5D0.7080209@gmail.com>

Acked-by: Lyos Gemini Norezel <Lyos.GeminiNorezel at gmail.com>

Lyos Gemini Norezel


Peter Stuge wrote:
> See patch.
>
>
> //Peter
>   




From peter at stuge.se  Fri Jun 13 02:20:01 2008
From: peter at stuge.se (Peter Stuge)
Date: Fri, 13 Jun 2008 02:20:01 +0200
Subject: [coreboot] flashrom: Board enable for GIGABYTE GA-7VT600
In-Reply-To: <4851B5D0.7080209@gmail.com>
References: <20080612234621.12778.qmail@stuge.se> <4851B5D0.7080209@gmail.com>
Message-ID: <20080613002001.7146.qmail@stuge.se>

On Thu, Jun 12, 2008 at 07:48:32PM -0400, Lyos Gemini Norezel wrote:
> Acked-by: Lyos Gemini Norezel <Lyos.GeminiNorezel at gmail.com>

Thanks! But here's an updated patch with a second PCI id. :)


//Peter
-------------- next part --------------
A non-text attachment was scrubbed...
Name: fr.ga7vt600.patch
Type: text/x-diff
Size: 1019 bytes
Desc: not available
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20080613/4ac5bda7/attachment.bin>

From lyos.gemininorezel at gmail.com  Fri Jun 13 02:41:40 2008
From: lyos.gemininorezel at gmail.com (Lyos Gemini Norezel)
Date: Thu, 12 Jun 2008 20:41:40 -0400
Subject: [coreboot] flashrom: Board enable for GIGABYTE GA-7VT600
In-Reply-To: <20080613002001.7146.qmail@stuge.se>
References: <20080612234621.12778.qmail@stuge.se> <4851B5D0.7080209@gmail.com>
	<20080613002001.7146.qmail@stuge.se>
Message-ID: <4851C244.40004@gmail.com>

Peter Stuge wrote:
> On Thu, Jun 12, 2008 at 07:48:32PM -0400, Lyos Gemini Norezel wrote:
>   
>> Acked-by: Lyos Gemini Norezel <Lyos.GeminiNorezel at gmail.com>
>>     
>
> Thanks! But here's an updated patch with a second PCI id. :)
>
>
> //Peter
>   

Acked-by: Lyos Gemini Norezel <Lyos.GeminiNorezel at gmail.com>

Lyos Gemini Norezel

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

From svn at coreboot.org  Fri Jun 13 03:39:46 2008
From: svn at coreboot.org (svn at coreboot.org)
Date: Fri, 13 Jun 2008 03:39:46 +0200
Subject: [coreboot] r3366 - trunk/util/flashrom
Message-ID: <mailman.1627.1355071332.16123.coreboot@coreboot.org>

Author: stuge
Date: 2008-06-13 03:39:45 +0200 (Fri, 13 Jun 2008)
New Revision: 3366

Modified:
   trunk/util/flashrom/board_enable.c
Log:
flashrom: Board enable and autodetection for GIGABYTE GA-7VT600

Uses the VT8237 ISA bridge with mainboard subsystem ID and Realtek 8139 with
mainboard subsystem ID for board detection.

Signed-off-by: Peter Stuge <peter at stuge.se>
Acked-by: Lyos Gemini Norezel <lyos.gemininorezel at gmail.com>


Modified: trunk/util/flashrom/board_enable.c
===================================================================
--- trunk/util/flashrom/board_enable.c	2008-06-11 02:24:15 UTC (rev 3365)
+++ trunk/util/flashrom/board_enable.c	2008-06-13 01:39:45 UTC (rev 3366)
@@ -517,6 +517,7 @@
 /**
  * Suited for:
  *   - BioStar P4M80-M4: Intel P4 + VIA P4M800 + VT8237
+ *   - GIGABYTE GA-7VT600: AMD K7 + VIA KT600 + VT8237
  */
 static int board_biostar_p4m80_m4(const char *name)
 {
@@ -612,6 +613,8 @@
  	 "kontron", "986lcd-m", "Kontron 986LCD-M", board_kontron_986lcd_m},
  	{0x1106, 0x3149, 0x1565, 0x3206, 0x1106, 0x3344, 0x1565, 0x1202,
  	 NULL, NULL, "BioStar P4M80-M4", board_biostar_p4m80_m4},
+ 	{0x1106, 0x3227, 0x1458, 0x5001, 0x10ec, 0x8139, 0x1458, 0xe000,
+ 	 NULL, NULL, "GIGABYTE GA-7VT600", board_biostar_p4m80_m4},
 	{0, 0, 0, 0, 0, 0, 0, 0, NULL, NULL}	/* Keep this */
 };
 




From peter at stuge.se  Fri Jun 13 03:40:17 2008
From: peter at stuge.se (Peter Stuge)
Date: Fri, 13 Jun 2008 03:40:17 +0200
Subject: [coreboot] flashrom: Board enable for GIGABYTE GA-7VT600
In-Reply-To: <4851C244.40004@gmail.com>
References: <20080612234621.12778.qmail@stuge.se> <4851B5D0.7080209@gmail.com>
	<20080613002001.7146.qmail@stuge.se> <4851C244.40004@gmail.com>
Message-ID: <20080613014017.6823.qmail@stuge.se>

On Thu, Jun 12, 2008 at 08:41:40PM -0400, Lyos Gemini Norezel wrote:
> >Thanks! But here's an updated patch with a second PCI id. :)
> 
> Acked-by: Lyos Gemini Norezel <Lyos.GeminiNorezel at gmail.com>

Thanks! r3366



From Ken.Fuchs at bench.com  Fri Jun 13 19:41:11 2008
From: Ken.Fuchs at bench.com (Ken.Fuchs at bench.com)
Date: Fri, 13 Jun 2008 12:41:11 -0500
Subject: [coreboot] How to build coreboot for AMD/Opteron nVnida/CK804
	CRB
In-Reply-To: <2ea3fae10806121134x5c6f1990s7861b80cb84f05db@mail.gmail.com>
Message-ID: <AA28F077645B324881335614E4F7C4284A4917@win-ex01.bench.com>

> On Wed, Jun 11, 2008 at 2:54 PM, Ken.Fuchs wrote:

> >> Ken Fuchs wrote:
> >
> >> > There doesn't seem to be a target defined for this board
> >> > (nVidia CK804 CRB) in the current source for coreboot.
> >> >
> >> > I tried:
> >> >
> >> > $ cd ./targets
> >> > $ ./buildtarget nvidia/ck804
> >> > No target config file found
> >> > Tried both nvidia/ck804 and nvidia/ck804/Config.lb
> >> > $

> > --- CK804 code in official LinuxBIOS source code ---
> >
> > The nVidia CK804 chipset is definitely supported
> > by coreboot.  See ./src/southbridge/nvidia/ck804/.
> > What happened to the mainboard and target files
> > of the nVidia CK804 CRB board?  Did someone remove
> > them from the coreboot repository?
> >
> > I also have a snapshot of the official LinuxBIOS
> > code right after the other CK804 port was officially
> > submitted (three years ago).  It contains
> > ./src/mainboard/nvidia/nf4crb, so the CK804
> > mainboard files were in the official tree.  However,
> > I see no evidence that the target files were in that
> > snapshot, but I assumed that they were added later.

yhlu wrote:

> i have src/mainboard/nvidia/crb in my local disk.
> 
> don't know why it is not made to public.
> 
> that should be something like s2895 but doesn't have 8131...

YH, did you do your first CK804 port to the nVidia reference board?

You should have the nVidia CK804 CRB target files too, right?

Can you please commit all the missing files needed for the
nVidia CK804 CRB (reference board)?

After that, I can test coreboot on my nVidia CK804 CRB boards.

Thanks,

Ken Fuchs



From bari at onelabs.com  Fri Jun 13 19:53:28 2008
From: bari at onelabs.com (bari)
Date: Fri, 13 Jun 2008 12:53:28 -0500
Subject: [coreboot] How to build coreboot for AMD/Opteron nVnida/CK804
 CRB
In-Reply-To: <AA28F077645B324881335614E4F7C4284A4917@win-ex01.bench.com>
References: <AA28F077645B324881335614E4F7C4284A4917@win-ex01.bench.com>
Message-ID: <4852B418.7030903@onelabs.com>

Ken.Fuchs at bench.com wrote:
> YH, did you do your first CK804 port to the nVidia reference board?
>
> You should have the nVidia CK804 CRB target files too, right?
>
> Can you please commit all the missing files needed for the
> nVidia CK804 CRB (reference board)?
>
> After that, I can test coreboot on my nVidia CK804 CRB boards.
>
>   
If anyone posts them, I or someone will ack them so we can submit them.

-Bari




From cdfrey at foursquare.net  Sat Jun 14 01:12:39 2008
From: cdfrey at foursquare.net (Chris Frey)
Date: Fri, 13 Jun 2008 19:12:39 -0400
Subject: [coreboot] Athlon 64 X2, coreboot, and ECC memory
Message-ID: <20080613231239.GA16990@foursquare.net>

Hi,

I'm looking through specs and lists of supported motherboards and mailing
list posts, and I see some conflicting reports about the Athlon 64 X2
and its ECC support.

As this processor apparently has ECC support in it, does it matter what
motherboard is used?

Does anyone have coreboot + Athlon 64 X2 + ECC working?

- Chris




From won.derick at yahoo.com  Sat Jun 14 15:00:05 2008
From: won.derick at yahoo.com (Won De Erick)
Date: Sat, 14 Jun 2008 06:00:05 -0700 (PDT)
Subject: [coreboot] [oc] 3 Chip Open BIOS + ESP: Backup/Secure BIOS with
	Redundancy
Message-ID: <628158.49510.qm@web45801.mail.sp1.yahoo.com>

http://www.gigabyte.com.tw/FileList/NewTech/2006_motherboard_newtech/how_does_quad_bios_work_dq6.htm



----- Original Message ----
From: Nathaniel Dube <njdube at gmail.com>
To: coreboot at coreboot.org; cores at opencores.org
Sent: Thursday, June 12, 2008 2:42:30 PM
Subject: [oc] 3 Chip Open BIOS + ESP:  Backup/Secure BIOS with Redundancy

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

First off, I'm by no means a engineer.  This message is going out to real 
engineers that might have interest in bringing the idea I'm about to share 
with you to reality.  This idea came to me after some light reading about 
rootkits on wikipedia and playing around with the program "rkhunter".  

Malware designers are writing code that can infect a system via rootkits.  
I've even read about the possibility of malware that can infect ROM chips on 
mother boards as well as ROM chips on PCI cards.  Meaning, anything that is 
rewritable isn't safe from malware.  Then it dawned on me that most of these 
security issues could be minimized at the hardware level at preboot, meaning 
before the operating system loads.

My brother brought his laptop to me complaning the internet wont work and that 
it's slow as a whale turd.  When I looked at it I found it swarming with 
viruses.  I asked him what happened to the firewall and antivirus that In 
installed for him and he said he turned them off because the firewall was 
messing with his internet and he didn't know how to turn it off with out also 
turning off the antivirus.  I think it was Eset Internet Security.  I use 
Linux on my system so I don't touch Windows software all that often.  I've 
come to the conclusion that it doesn't matter what software you put on there 
or what you do, stupid users (and most users are stupid) will fsck up there 
system.

That's when I decided that mother boards need to be dramatically redesigned 
from the ground up with a proactive role in security.  Now here's where I 
will start with my wonderful idea that will save the world.  You will either 
see that world with me or you wont.

I'm sure most of you are aware of the history of the BIOS and the ROM's 
they're on.  Back in the day they really where ROM in every sense of the term 
that they where READ only.  They where embed on the board so you would need a 
solder iron to remove them.  Then they came out with the removable kind with 
sockets that you can replace with a new chip.  Then comes the kind you can 
flash with software but are embedded.  I'm sorry but impeded un-removeable ROM 
chips are completely asinine.  Now on to my idea.

Instead of one ROM chip for the BIOS there should be 3 and use "coreboot" as 
the BIOS.  All 3 will utilize sockets to be removeable for easy replacement.  
The first chip will have the purpose as a backup of the default BIOS and the 
chip will be read only.  The second chip will house a copy of the primary 
BIOS which will be rewritable and allow for updates.  The third chip I will 
call the ESP (Emergency Security Protocols) ROM which may or may not be read 
only, I haven't decided yet.  The third chip will have the open source 
programs rkhunter, clamav and perhaps other programs that might be useful for 
a preboot.

In the event the other two are corrupted for what ever reason you need only 
flip a jumper, turn on the computer and the backup BIOS takes control and 
allows you to wipe the other two chips and restore a rewritable copy of the 
BIOS to chip 2 and the ESP BIOS to chip 3.  The backup BIOS will also have 
the Linux program "wipe" so in the unlikeliness a rootkit takes control of 
chips 2 and 3 chip 1 will wipe it out and start from scratch.

This board will also have integrated wifi as well as lan making it easy to get 
a internet connection.  The goal being to be able to update the signatures of 
rkhunter and clamav as well as update both firmware by direct download before 
the OS even loads.  This entire process will have a liberal use of checksums 
to make sure at no time is any malware being installed during the preboot 
process.

I'm still trying to work out the finer details in my head.  So my idea may 
make sense or it may not.  Ultimately what I'm trying to do is build a mother 
board with BIOS backup/security redundancy.  The 3 chips act as a triad that 
protect one another.  The board should be designed so it tries to load the 
second chip with the rewritable BIOS and use the third chip to do a quick 
self scan for rootkits.  If for some reason the first BIOS wont load it will 
fall back on the backup BIOS restoring the primary.  Perhaps some one can 
share a better way of implimenting my idea.  The goal is to make it damn near 
impossible for malware to alter or change the BIOS or load at preboot.  These 
security meause could also be used to protect rewritable ROM on other 
hardware.

Please share your thoughts.  I would really like to see a board like this see 
the light of reality.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.4-svn0 (GNU/Linux)

iD8DBQFIUMVWvsn/sQCIOqQRAnqwAJ9lYdjiBqnaVArQvHZIcIIaD8A0gQCfSKn1
YYOUf33mToJpZ7N/HI6Q7jY=
=VeHI
-----END PGP SIGNATURE-----
_______________________________________________
http://www.opencores.org/mailman/listinfo/cores


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

From peter at stuge.se  Sat Jun 14 18:13:31 2008
From: peter at stuge.se (Peter Stuge)
Date: Sat, 14 Jun 2008 18:13:31 +0200
Subject: [coreboot] [oc] 3 Chip Open BIOS + ESP: Backup/Secure BIOS with
	Redundancy
In-Reply-To: <628158.49510.qm@web45801.mail.sp1.yahoo.com>
References: <628158.49510.qm@web45801.mail.sp1.yahoo.com>
Message-ID: <20080614161331.2045.qmail@stuge.se>

On Sat, Jun 14, 2008 at 06:00:05AM -0700, Won De Erick wrote:
> http://www.gigabyte.com.tw/FileList/NewTech/2006_motherboard_newtech/how_does_quad_bios_work_dq6.htm

Yeah. Situation 1 is GIGABYTE's patented hardware failover.

Situation 2-3 are variations on the same.


//Peter



From peter at stuge.se  Sat Jun 14 19:23:07 2008
From: peter at stuge.se (Peter Stuge)
Date: Sat, 14 Jun 2008 19:23:07 +0200
Subject: [coreboot] flashrom image identification problem/coreboot signature
	RFC
Message-ID: <20080614172307.27445.qmail@stuge.se>

On Fri, Jun 13, 2008 at 02:30:31PM -0700, Victor Zele wrote:
> bash-3.00# ./flashrom -vw sa6k14.rom
..
> coreboot last image size (not ROM size) is -1791885312 bytes.
> Segmentation fault

Victor used the factory flashing utility to update his factory BIOS,
then he read back the sa6k14.rom file using flashrom.

When trying to write sa6k14.rom, flashrom mistakes it for a coreboot
image and crashes because it is in fact not a coreboot image, and
where coreboot stores hints for flashrom, sa6k14.rom has data which
is garbage to flashrom.

The problem lies in layout.c:show_id() which does this to identify a
factory BIOS:

--8<--
        walk = (unsigned int *)(bios + size - 0x10);
        walk--;

        if ((*walk) == 0 || ((*walk) & 0x3ff) != 0) {
                /* We might have an Nvidia chipset bios 
                 * which stores the id information at a 
                 * different location.
                 */
                walk = (unsigned int *)(bios + size - 0x80);
                walk--;
        }

        if ((*walk) == 0 || ((*walk) & 0x3ff) != 0) {
                printf("Flash image seems to be a legacy BIOS.
                mainboard_vendor = def_name;
                mainboard_part = def_name;  
                return 0;
        }
-->8--

Seems that the 4 last bytes before the reset vector are checked, and
that flashrom considers the image to be coreboot when bits 9-0 are 0
and one or more of bits 31-10 are 1.

This heuristic is no longer good enough. Any ideas for a nice and
simple coreboot signature?


//Peter



From stepan at coresystems.de  Sat Jun 14 21:25:43 2008
From: stepan at coresystems.de (Stefan Reinauer)
Date: Sat, 14 Jun 2008 21:25:43 +0200
Subject: [coreboot] flashrom image identification problem/coreboot
 signature RFC
In-Reply-To: <20080614172307.27445.qmail@stuge.se>
References: <20080614172307.27445.qmail@stuge.se>
Message-ID: <48541B37.5080703@coresystems.de>

Peter Stuge wrote:
>
> Seems that the 4 last bytes before the reset vector are checked, and
> that flashrom considers the image to be coreboot when bits 9-0 are 0
> and one or more of bits 31-10 are 1.
>
> This heuristic is no longer good enough. Any ideas for a nice and
> simple coreboot signature?
>
>   

Yes. A LAR file with that information in the image.

-- 
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 peter at stuge.se  Sat Jun 14 21:34:01 2008
From: peter at stuge.se (Peter Stuge)
Date: Sat, 14 Jun 2008 21:34:01 +0200
Subject: [coreboot] flashrom image identification problem/coreboot
	signature RFC
In-Reply-To: <48541B37.5080703@coresystems.de>
References: <20080614172307.27445.qmail@stuge.se>
	<48541B37.5080703@coresystems.de>
Message-ID: <20080614193401.5871.qmail@stuge.se>

On Sat, Jun 14, 2008 at 09:25:43PM +0200, Stefan Reinauer wrote:
> > This heuristic is no longer good enough. Any ideas for a nice and
> > simple coreboot signature?
> 
> Yes. A LAR file with that information in the image.

Ah of course - yes for v3 that's perfect.

What about v2?


//Peter



From ward at gnu.org  Sat Jun 14 21:37:51 2008
From: ward at gnu.org (Ward Vandewege)
Date: Sat, 14 Jun 2008 15:37:51 -0400
Subject: [coreboot] m57sli FAN control
In-Reply-To: <484EF2A0.7060507@zonnet.nl>
References: <20080610183457.GA32451@localdomain> <484EF2A0.7060507@zonnet.nl>
Message-ID: <20080614193751.GA1295@localdomain>

Hi Ronald,

On Tue, Jun 10, 2008 at 11:31:12PM +0200, Ronald Hoogenboom wrote:
> This patch enables automatic fan control on the gigabyte M57sli-s4  
> motherboard using the environmental controller of the IT8716 superio.
> All fan outputs are controlled by the cpu temperature sensor for safety.

I've made a few small modifications:

* put fan2 and 3 under hardware control ('smart' mode)
* updated for the current SVN tree

Thanks,
Ward.

-- 
Ward Vandewege <ward at fsf.org>
Free Software Foundation - Senior System Administrator
-------------- next part --------------
A non-text attachment was scrubbed...
Name: fanctl-m57sli-final.patch
Type: text/x-diff
Size: 3075 bytes
Desc: not available
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20080614/44a39b43/attachment.bin>

From stepan at coresystems.de  Sat Jun 14 21:53:08 2008
From: stepan at coresystems.de (Stefan Reinauer)
Date: Sat, 14 Jun 2008 21:53:08 +0200
Subject: [coreboot] flashrom image identification
 problem/coreboot	signature RFC
In-Reply-To: <20080614193401.5871.qmail@stuge.se>
References: <20080614172307.27445.qmail@stuge.se>	<48541B37.5080703@coresystems.de>
	<20080614193401.5871.qmail@stuge.se>
Message-ID: <485421A4.6080306@coresystems.de>

Peter Stuge wrote:
> On Sat, Jun 14, 2008 at 09:25:43PM +0200, Stefan Reinauer wrote:
>   
>>> This heuristic is no longer good enough. Any ideas for a nice and
>>> simple coreboot signature?
>>>       
>> Yes. A LAR file with that information in the image.
>>     
>
> Ah of course - yes for v3 that's perfect.
>
> What about v2?
>
>   
I suggest using the same mechanism, wrapping the information in a lar
header, making it a single file lar. The lar format can handle this, and
we don't have to worry for different versions.

-- 
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 peter at stuge.se  Sun Jun 15 04:53:14 2008
From: peter at stuge.se (Peter Stuge)
Date: Sun, 15 Jun 2008 04:53:14 +0200
Subject: [coreboot] flashrom patch: Force read unknown flash chips
Message-ID: <20080615025314.30721.qmail@stuge.se>

Patch attached.


//Peter
-------------- next part --------------
A non-text attachment was scrubbed...
Name: fr.fr.patch
Type: text/x-diff
Size: 5202 bytes
Desc: not available
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20080615/e12f194a/attachment.bin>

From paulepanter at users.sourceforge.net  Sun Jun 15 09:25:08 2008
From: paulepanter at users.sourceforge.net (Paul Menzel)
Date: Sun, 15 Jun 2008 09:25:08 +0200
Subject: [coreboot] flashrom patch: Force read unknown flash chips
In-Reply-To: <20080615025314.30721.qmail@stuge.se>
References: <20080615025314.30721.qmail@stuge.se>
Message-ID: <1213514708.5519.4.camel@mattotaupa.wohnung.familie-menzel.net>

Dear Peter,


as always I can just comment on the messages. I hope someone else will
ack this patch, since Carl-Daniel is idle for a while.


Am Sonntag, den 15.06.2008, 04:53 +0200 schrieb Peter Stuge:
> @@ -427,6 +428,44 @@
>                 exit(1);
>         } else if (!flashes[0]) {
>                 printf("No EEPROM/flash device found.\n");
> +               if (!force || !chip_to_probe) {
> +                       printf("If you know which flash chip you have and if this version of flashrom\n");
> +                       printf("supports a similar flash chip, you can try a force read. Run:\n");

Here you say ?force read?.

> +                       printf("flashrom -f -r -c similar_supported_flash_chip filename\n");
> +                       printf("\n");
> +                       printf("Note: flashrom can never write when the flash chip isn't found automatically.\n");
> +               }
> +               if (force && read_it && chip_to_probe) {
> +                       printf("Detected forced read (-f -r -c options) - forcing chip probe success.\n");

Here you say ?forced read?.

> +                       flashes[0] = probe_flash(flashchips, 1);
> +                       if (!flashes[0]) {
> +                               printf("flashrom does not support the flash chip '%s'.\n", chip_to_probe);
> +                               printf("Run flashrom -L to print a list of the supported hardware in this version.\n");

Native speakers, is the article ?the? correct here?


Thanks,

Paul
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: Dies ist ein digital signierter Nachrichtenteil
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20080615/1adb72a6/attachment.sig>

From peter at stuge.se  Sun Jun 15 14:38:47 2008
From: peter at stuge.se (Peter Stuge)
Date: Sun, 15 Jun 2008 14:38:47 +0200
Subject: [coreboot] flashrom patch: Force read unknown flash chips
In-Reply-To: <1213514708.5519.4.camel@mattotaupa.wohnung.familie-menzel.net>
References: <20080615025314.30721.qmail@stuge.se>
	<1213514708.5519.4.camel@mattotaupa.wohnung.familie-menzel.net>
Message-ID: <20080615123847.16951.qmail@stuge.se>

Hi Paul,

On Sun, Jun 15, 2008 at 09:25:08AM +0200, Paul Menzel wrote:
> as always I can just comment on the messages.

You can test too. :) But more eyes on messages is very good! I
appreciate your review.


> I hope someone else will ack this patch, since Carl-Daniel is idle
> for a while.

Everyone who can review and/or test is invited to do so.


This patch can be tested also on systems where flashrom is already
able to successfully detect the flash chip, by specifying -f -r -c
and specifying a different flash chip than what is really there in
the system as parameter to -c.

For example, on my laptop flashrom finds an SST chip:

# ./flashrom 
Calibrating delay loop... OK.
No coreboot table found.
Found chipset "Intel ICH3-M", enabling flash write... OK.
Found chip "SST SST49LF008A" (1024 KB) at physical address
0xfff00000.
===
This flash part has status UNTESTED for operations: ERASE WRITE
Please email a report to flashrom at coreboot.org if any of the above operations
work correctly for you with this flash part. Please include the full output
from the program, including chipset found. Thank you for your help!
===
No operations were specified.


But I can still test the patch by forcing (e.g.) a Winbond chip:

# ./flashrom -f -r -c W39V080A out.bin
Calibrating delay loop... OK.
No coreboot table found.
Found chipset "Intel ICH3-M", enabling flash write... OK.
No EEPROM/flash device found.
Force read (-f -r -c) requested, forcing chip probe success:
Found chip "Winbond W39V080A" (1024 KB) at physical address 0xfff00000.
Force reading flash...done

# xxd out.bin|head
0000000: 55aa 74e8 5528 cb28 2803 0000 0000 0000  U.t.U(.((.......
0000010: 0000 0000 0000 2000 4000 6000 a803 3001  ...... . at .`...0.
0000020: 554e 4449 16c4 0000 0102 6a0e 0008 b094  UNDI......j.....
0000030: e021 5043 4952 0000 0000 0000 0000 0000  .!PCIR..........
0000040: 5043 4952 8680 2912 0000 1800 0002 0000  PCIR..).........
0000050: 7400 0102 0080 0000 0000 0000 0000 ff00  t...............
0000060: 2450 6e50 0102 0000 00c9 0000 0000 9b00  $PnP............
0000070: bc00 0200 00e4 0000 0000 b80d 0000 0000  ................
0000080: 0d0a 436f 7079 7269 6768 7420 2843 2920  ..Copyright (C) 
0000090: 3139 3937 2d32 3030 322c 2049 6e74 656c  1997-2002, Intel


> > +                       printf("If you know which flash chip you have and if this version of flashrom\n");
> > +                       printf("supports a similar flash chip, you can try a force read. Run:\n");
> 
> Here you say ???force read???.

> > +               if (force && read_it && chip_to_probe) {
> > +                       printf("Detected forced read (-f -r -c options) - forcing chip probe success.\n");
> 
> Here you say ???forced read???.

Thanks for pointing out this inconsistency. I've updated the messages
a bit but will hold off sending a new patch a little to see if there
are some more comments.


> > +                       flashes[0] = probe_flash(flashchips, 1);
> > +                       if (!flashes[0]) {
> > +                               printf("flashrom does not support the flash chip '%s'.\n", chip_to_probe);
> > +                               printf("Run flashrom -L to print a list of the supported hardware in this version.\n");
> 
> Native speakers, is the article ???the??? correct here?

This message could indeed use some improvement. I changed the wording
to improve grammar and clarify, and besides, flashrom doesn't print
on paper, it just displays the list. :)


//Peter



From beckam2 at fel.cvut.cz  Sun Jun 15 14:52:43 2008
From: beckam2 at fel.cvut.cz (Marek Becka)
Date: Sun, 15 Jun 2008 14:52:43 +0200
Subject: [coreboot] work on intel 440GX
Message-ID: <4855109B.3000503@fel.cvut.cz>

Hi all,

I have one older motherboard with Intel 440 GX chipset. During this 
summer I would like to try to port coreboot on it. I like idea of this 
project and I would like to support it and learn something new.  There 
is already work on 440 BX chipset, so I can establish on it. 
Documentation from Intel is also available. The only problem should be 
Ali M5132 Super I/O. I haven't found anything about this chip. It is 
real problem?



From yuen at klacno.sk  Sun Jun 15 14:56:58 2008
From: yuen at klacno.sk (Marek Becka)
Date: Sun, 15 Jun 2008 14:56:58 +0200
Subject: [coreboot] work on intel 440gx
Message-ID: <4855119A.4030806@klacno.sk>

Hi all,

I have one older motherboard with Intel 440 GX chipset. During this 
summer I would like to try to port coreboot on it. I like idea of this 
project and I would like to support it and learn something new.  There 
is already work on 440 BX chipset, so I can establish on it. 
Documentation from Intel is also available. The only problem should be 
Ali M5132 Super I/O. I haven't found anything about this chip. It is 
real problem?



From svn at coreboot.org  Sun Jun 15 17:00:03 2008
From: svn at coreboot.org (coreboot tracker)
Date: Sun, 15 Jun 2008 17:00:03 +0200
Subject: [coreboot] Trac reminder: list of new ticket(s)
Message-ID: <E1K7ti7-0000Wt-4j@khepri.openbios.org>

An HTML attachment was scrubbed...
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20080615/dd123b42/attachment.html>

From svn at coreboot.org  Sun Jun 15 23:49:58 2008
From: svn at coreboot.org (coreboot)
Date: Sun, 15 Jun 2008 21:49:58 -0000
Subject: [coreboot] #14: Rename "stream" to "payload"
In-Reply-To: <039.ae1eaa54b37c97f4af2b032691a9a73d@coreboot.org>
References: <039.ae1eaa54b37c97f4af2b032691a9a73d@coreboot.org>
Message-ID: <048.e6f1f1baaa0c485598284ed2eab5b905@coreboot.org>

#14: Rename "stream" to "payload"
----------------------------+-----------------------------------------------
    Reporter:  uwe          |         Owner:  somebody                
        Type:  enhancement  |        Status:  closed                  
    Priority:  major        |     Milestone:  Cosmetic fixes          
   Component:  coreboot     |       Version:  v2                      
  Resolution:  fixed        |      Keywords:                          
Dependencies:  #22          |   Patchstatus:  patch has been committed
----------------------------+-----------------------------------------------
Changes (by eswierk):

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

-- 
Ticket URL: <http://tracker.coreboot.org/trac/coreboot/ticket/14#comment:11>
coreboot <http://www.coreboot.org/>

From joe at settoplinux.org  Mon Jun 16 14:04:10 2008
From: joe at settoplinux.org (Joseph Smith)
Date: Mon, 16 Jun 2008 08:04:10 -0400
Subject: [coreboot] work on intel 440GX
In-Reply-To: <4855109B.3000503@fel.cvut.cz>
References: <4855109B.3000503@fel.cvut.cz>
Message-ID: <5f29c75c176d20b1498cf2845893fe50@imap.1and1.com>




On Sun, 15 Jun 2008 14:52:43 +0200, Marek Becka <beckam2 at fel.cvut.cz>
wrote:
> Hi all,
> 
> I have one older motherboard with Intel 440 GX chipset. During this
> summer I would like to try to port coreboot on it. I like idea of this
> project and I would like to support it and learn something new.  There
> is already work on 440 BX chipset, so I can establish on it.
> Documentation from Intel is also available. The only problem should be
> Ali M5132 Super I/O. I haven't found anything about this chip. It is
> real problem?
> 
Hello Marek,
I think it is great you want to port coreboot to the 440GX. Go for it!
As far as the SuperIO, are you able to get ahold of a datasheet for it?
If so, you can do some reading and then find one that matches it pretty
close and use that for your starting code.
Hope that helps.

-- 
Thanks,
Joseph Smith
Set-Top-Linux
www.settoplinux.org




From marekr2 at fel.cvut.cz  Mon Jun 16 14:29:51 2008
From: marekr2 at fel.cvut.cz (Rudolf Marek)
Date: Mon, 16 Jun 2008 14:29:51 +0200
Subject: [coreboot] work on intel 440GX
In-Reply-To: <5f29c75c176d20b1498cf2845893fe50@imap.1and1.com>
References: <4855109B.3000503@fel.cvut.cz>
	<5f29c75c176d20b1498cf2845893fe50@imap.1and1.com>
Message-ID: <48565CBF.608@fel.cvut.cz>

Hi,

You will need the SuperIO datasheet

http://www.m6117d.com/doc/m5113.pdf

Maybe this one will be similar enough?

Rudolf



From marc.jones at amd.com  Mon Jun 16 17:34:22 2008
From: marc.jones at amd.com (Marc Jones)
Date: Mon, 16 Jun 2008 09:34:22 -0600
Subject: [coreboot] Athlon 64 X2, coreboot, and ECC memory
In-Reply-To: <20080613231239.GA16990@foursquare.net>
References: <20080613231239.GA16990@foursquare.net>
Message-ID: <485687FE.7040903@amd.com>

Hi Chris,

Athlon 64 X2 in a AM2 socket supports ECC.

The motherboard also has to support ECC but I think most (all) of them do.

Marc

Chris Frey wrote:
> Hi,
>
> I'm looking through specs and lists of supported motherboards and mailing
> list posts, and I see some conflicting reports about the Athlon 64 X2
> and its ECC support.
>
> As this processor apparently has ECC support in it, does it matter what
> motherboard is used?
>
> Does anyone have coreboot + Athlon 64 X2 + ECC working?
>
> - Chris
>
>
>   





From c-d.hailfinger.devel.2006 at gmx.net  Mon Jun 16 18:57:00 2008
From: c-d.hailfinger.devel.2006 at gmx.net (Carl-Daniel Hailfinger)
Date: Mon, 16 Jun 2008 18:57:00 +0200
Subject: [coreboot] flashrom image identification
 problem/coreboot	signature RFC
In-Reply-To: <485421A4.6080306@coresystems.de>
References: <20080614172307.27445.qmail@stuge.se>	<48541B37.5080703@coresystems.de>	<20080614193401.5871.qmail@stuge.se>
	<485421A4.6080306@coresystems.de>
Message-ID: <48569B5C.4030804@gmx.net>

On 14.06.2008 21:53, Stefan Reinauer wrote:
> Peter Stuge wrote:
>   
>> On Sat, Jun 14, 2008 at 09:25:43PM +0200, Stefan Reinauer wrote:
>>   
>>     
>>>> This heuristic is no longer good enough. Any ideas for a nice and
>>>> simple coreboot signature?
>>>>       
>>>>         
>>> Yes. A LAR file with that information in the image.
>>>     
>>>       
>> Ah of course - yes for v3 that's perfect.
>>
>> What about v2?
>>
>>   
>>     
> I suggest using the same mechanism, wrapping the information in a lar
> header, making it a single file lar. The lar format can handle this, and
> we don't have to worry for different versions.
>   

How about a generic bootblock/VPD signature instead? Having a short
signature in the top 256 bytes or so will allow recognition of complete
and incomplete (only partly mapped) coreboot images easily.

Proposal for signature formats:

4 bytes:
"CB20" for v2.0 and "CB30" for v3.0

8 bytes (option 1):
"CB203300" for v2.0, rev 3300

8 bytes (option 2):
"coreboot"

16 bytes:
"coreboot20r3300 " for v2.0, r3300 (note the space at the end for
5-digit svn revisions)

Regards,
Carl-Daniel



From stepan at coresystems.de  Mon Jun 16 19:02:17 2008
From: stepan at coresystems.de (Stefan Reinauer)
Date: Mon, 16 Jun 2008 19:02:17 +0200
Subject: [coreboot] flashrom image identification
 problem/coreboot	signature RFC
In-Reply-To: <48569B5C.4030804@gmx.net>
References: <20080614172307.27445.qmail@stuge.se>	<48541B37.5080703@coresystems.de>	<20080614193401.5871.qmail@stuge.se>	<485421A4.6080306@coresystems.de>
	<48569B5C.4030804@gmx.net>
Message-ID: <48569C99.2040300@coresystems.de>

Carl-Daniel Hailfinger wrote:
> On 14.06.2008 21:53, Stefan Reinauer wrote:
>> I suggest using the same mechanism, wrapping the information in a lar
>> header, making it a single file lar. The lar format can handle this, and
>> we don't have to worry for different versions.
>>   
>>     
>
> How about a generic bootblock/VPD signature instead? Having a short
> signature in the top 256 bytes or so will allow recognition of complete
> and incomplete (only partly mapped) coreboot images easily.
>
> Proposal for signature formats:
>
> 4 bytes:
> "CB20" for v2.0 and "CB30" for v3.0
>
> 8 bytes (option 1):
> "CB203300" for v2.0, rev 3300
>
> 8 bytes (option 2):
> "coreboot"
>
> 16 bytes:
> "coreboot20r3300 " for v2.0, r3300 (note the space at the end for
> 5-digit svn revisions)
>   

Top 256 bytes will not always work. The current trouble is due to the
fact that we have some mainboards that need the information in a
different place than others.

Other than that, we might indeed put the coreboot version into the
firmware signature, too, if there's a reason to do so. Is there?

I miss the actual information in your suggestion, namely the mainboard
vendor and type.

Since we already have LAR, using that format instead of yet another
signature rule makes a lot of sense in my opinion.

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 c-d.hailfinger.devel.2006 at gmx.net  Mon Jun 16 19:39:15 2008
From: c-d.hailfinger.devel.2006 at gmx.net (Carl-Daniel Hailfinger)
Date: Mon, 16 Jun 2008 19:39:15 +0200
Subject: [coreboot] flashrom image identification
 problem/coreboot	signature RFC
In-Reply-To: <48569C99.2040300@coresystems.de>
References: <20080614172307.27445.qmail@stuge.se>	<48541B37.5080703@coresystems.de>	<20080614193401.5871.qmail@stuge.se>	<485421A4.6080306@coresystems.de>
	<48569B5C.4030804@gmx.net> <48569C99.2040300@coresystems.de>
Message-ID: <4856A543.2040103@gmx.net>

On 16.06.2008 19:02, Stefan Reinauer wrote:
> Carl-Daniel Hailfinger wrote:
>   
>> On 14.06.2008 21:53, Stefan Reinauer wrote:
>>     
>>> I suggest using the same mechanism, wrapping the information in a lar
>>> header, making it a single file lar. The lar format can handle this, and
>>> we don't have to worry for different versions.
>>>   
>>>     
>>>       
>> How about a generic bootblock/VPD signature instead? Having a short
>> signature in the top 256 bytes or so will allow recognition of complete
>> and incomplete (only partly mapped) coreboot images easily.
>>
>> Proposal for signature formats:
>>
>> 4 bytes:
>> "CB20" for v2.0 and "CB30" for v3.0
>>
>> 8 bytes (option 1):
>> "CB203300" for v2.0, rev 3300
>>
>> 8 bytes (option 2):
>> "coreboot"
>>
>> 16 bytes:
>> "coreboot20r3300 " for v2.0, r3300 (note the space at the end for
>> 5-digit svn revisions)
>>   
>>     
>
> Top 256 bytes will not always work. The current trouble is due to the
> fact that we have some mainboards that need the information in a
> different place than others.
>   

Anything in the top 4k would be OK for me, unless there are specific
reasons this is impossible with some boards. I'd appreciate a pointer
about the "different place" thing.

> Other than that, we might indeed put the coreboot version into the
> firmware signature, too, if there's a reason to do so. Is there?
>   

Not sure about svn revision, but differentiating between v2 and v3 would
help. For one, we could keep a pseudo-LAR out of v2.

> I miss the actual information in your suggestion, namely the mainboard
> vendor and type.
>   

Placing vendor and type somewhere else is possible, as long as flashrom
knows that it should look there.

> Since we already have LAR, using that format instead of yet another
> signature rule makes a lot of sense in my opinion.
>   

For v3, yes mostly.
For v2, someone would have to add a invalid LAR pseudoheader to the
final linked image. Definitely not something I'd like to try (my linker
script skills are not good enough nor do I consider this to be a
particularly compelling idea).


Regards,
Carl-Daniel



From stepan at coresystems.de  Mon Jun 16 19:53:08 2008
From: stepan at coresystems.de (Stefan Reinauer)
Date: Mon, 16 Jun 2008 19:53:08 +0200
Subject: [coreboot] flashrom image identification
 problem/coreboot	signature RFC
In-Reply-To: <4856A543.2040103@gmx.net>
References: <20080614172307.27445.qmail@stuge.se>	<48541B37.5080703@coresystems.de>	<20080614193401.5871.qmail@stuge.se>	<485421A4.6080306@coresystems.de>
	<48569B5C.4030804@gmx.net> <48569C99.2040300@coresystems.de>
	<4856A543.2040103@gmx.net>
Message-ID: <4856A884.7030201@coresystems.de>

Carl-Daniel Hailfinger wrote:

>> Top 256 bytes will not always work. The current trouble is due to the
>> fact that we have some mainboards that need the information in a
>> different place than others.
>>   
>>     
>
> Anything in the top 4k would be OK for me, unless there are specific
> reasons this is impossible with some boards. I'd appreciate a pointer
> about the "different place" thing.
>   

Why would you want to artificially limit this at all. A lar entry can be
anywhere in the binary and it will still work. Now imagine how flexible
that would be ;-)

>> Other than that, we might indeed put the coreboot version into the
>> firmware signature, too, if there's a reason to do so. Is there?
>>     
>
> Not sure about svn revision, but differentiating between v2 and v3 would
> help. For one, we could keep a pseudo-LAR out of v2.
>   
What's the benefit of using "CB20" as a magic rather than "LARCHIVE"?
Exactly: None.
There are disadvantages to having to maintain two different ways of
doing things though. Especially given that v2 is going to be obsoleted
some time.
>> I miss the actual information in your suggestion, namely the mainboard
>> vendor and type.
>>   
>>     
>
> Placing vendor and type somewhere else is possible, as long as flashrom
> knows that it should look there.
>   
Sure. And this is what the whole discussion is about. Maybe you missed
the point in the first place?

>> Since we already have LAR, using that format instead of yet another
>> signature rule makes a lot of sense in my opinion.
>>   
>>     
>
> For v3, yes mostly.
> For v2, someone would have to add a invalid LAR pseudoheader to the
> final linked image. 
No invalid header needed. No pseudo header anyways. Just pack a plain
normal valid header there.

> Definitely not something I'd like to try (my linker
> script skills are not good enough nor do I consider this to be a
> particularly compelling idea).
>   
Placing a few bytes at an arbitrary 16byte aligned address within the
image is quite simple.




-- 
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 Jun 16 20:21:09 2008
From: c-d.hailfinger.devel.2006 at gmx.net (Carl-Daniel Hailfinger)
Date: Mon, 16 Jun 2008 20:21:09 +0200
Subject: [coreboot] flashrom image identification
 problem/coreboot	signature RFC
In-Reply-To: <4856A884.7030201@coresystems.de>
References: <20080614172307.27445.qmail@stuge.se>	<48541B37.5080703@coresystems.de>	<20080614193401.5871.qmail@stuge.se>	<485421A4.6080306@coresystems.de>
	<48569B5C.4030804@gmx.net> <48569C99.2040300@coresystems.de>
	<4856A543.2040103@gmx.net> <4856A884.7030201@coresystems.de>
Message-ID: <4856AF15.10005@gmx.net>

On 16.06.2008 19:53, Stefan Reinauer wrote:
> Carl-Daniel Hailfinger wrote:
>
>   
>>> Top 256 bytes will not always work. The current trouble is due to the
>>> fact that we have some mainboards that need the information in a
>>> different place than others.
>>>   
>>>     
>>>       
>> Anything in the top 4k would be OK for me, unless there are specific
>> reasons this is impossible with some boards. I'd appreciate a pointer
>> about the "different place" thing.
>>   
>>     
>
> Why would you want to artificially limit this at all. A lar entry can be
> anywhere in the binary and it will still work. Now imagine how flexible
> that would be ;-)
>   

And unpacking the lar will possible result in garbage if the header is
"somewhere".

>>> Other than that, we might indeed put the coreboot version into the
>>> firmware signature, too, if there's a reason to do so. Is there?
>>>     
>>>       
>> Not sure about svn revision, but differentiating between v2 and v3 would
>> help. For one, we could keep a pseudo-LAR out of v2.
>>   
>>     
> What's the benefit of using "CB20" as a magic rather than "LARCHIVE"?
> Exactly: None.
> There are disadvantages to having to maintain two different ways of
> doing things though. Especially given that v2 is going to be obsoleted
> some time.
>   
>>> I miss the actual information in your suggestion, namely the mainboard
>>> vendor and type.
>>>   
>>>     
>>>       
>> Placing vendor and type somewhere else is possible, as long as flashrom
>> knows that it should look there.
>>   
>>     
> Sure. And this is what the whole discussion is about. Maybe you missed
> the point in the first place?
>   

The point was to make sure flashrom does not segfault anymore on real
world images. Feel free to fix that in any way you want.

>>> Since we already have LAR, using that format instead of yet another
>>> signature rule makes a lot of sense in my opinion.
>>>   
>>>     
>>>       
>> For v3, yes mostly.
>> For v2, someone would have to add a invalid LAR pseudoheader to the
>> final linked image. 
>>     
> No invalid header needed. No pseudo header anyways. Just pack a plain
> normal valid header there.
>   

And unpacking the plain normal valid header will result in what?

>> Definitely not something I'd like to try (my linker
>> script skills are not good enough nor do I consider this to be a
>> particularly compelling idea).
>>   
>>     
> Placing a few bytes at an arbitrary 16byte aligned address within the
> image is quite simple.
>   

Great. As long as you fix the flashrom segfault (which needs a flashrom
code change and was the reason the thread got started) you can change
the v2 image any way you want.
You could even postpone the signature decision and improve the coreboot
detection heuristic in flashrom by checking the read values for sanity
(a negative image size is not sane).

Regards,
Carl-Daniel

P.S. Back to university work...



From stepan at coresystems.de  Mon Jun 16 20:32:22 2008
From: stepan at coresystems.de (Stefan Reinauer)
Date: Mon, 16 Jun 2008 20:32:22 +0200
Subject: [coreboot] flashrom image identification
 problem/coreboot	signature RFC
In-Reply-To: <4856AF15.10005@gmx.net>
References: <20080614172307.27445.qmail@stuge.se>	<48541B37.5080703@coresystems.de>	<20080614193401.5871.qmail@stuge.se>	<485421A4.6080306@coresystems.de>
	<48569B5C.4030804@gmx.net> <48569C99.2040300@coresystems.de>
	<4856A543.2040103@gmx.net> <4856A884.7030201@coresystems.de>
	<4856AF15.10005@gmx.net>
Message-ID: <4856B1B6.8000305@coresystems.de>

Carl-Daniel Hailfinger wrote:

> And unpacking the lar will possible result in garbage if the header is
> "somewhere".
>   

Unpacking it? We're talking about searching a signature. Nobody will
ever unpack a v2 image with a single lar entry.

Besides, the utility should be able to cope with it. At least per
design. Even if it doesn't make sense.

> And unpacking the plain normal valid header will result in what?
>   
A file containing your mainboard vendor and type, I suppose?






-- 
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 r&d2 at dave-tech.it  Tue Jun 17 16:30:32 2008
From: r&d2 at dave-tech.it (llandre)
Date: Tue, 17 Jun 2008 16:30:32 +0200
Subject: [coreboot] Firmware hub flash addressing [off-topic]
In-Reply-To: <484F9C2B.8030003@dave-tech.it>
References: <484F9C2B.8030003@dave-tech.it>
Message-ID: <4857CA88.8080701@dave-tech.it>

> Sorry for posting a message that is a little bit off-topic.
> 
> I'm working with a SST 8 Mbit Firmware Hub SST49LF008A flash connected 
> to Geode LX LPC bus.
> I need to understand where flash registers are mapped in case the flash 
> ID is set to 1 (this flash is not the boot flash that has ID=0).
> The datasheet just says about identification registers (same thing 
> applies for other registers too):
> 
> JEDEC ID Registers
> The JEDEC ID registers for the boot device appear at
> FFBC0000H and FFBC0001H in the 4 GByte system
> memory map, and will appear ***elsewhere*** if the device is not
> the boot device.
> 
> 
> Anybody can tell me what does "elsewhere" stand for in this sentence?
Some news ...
If I understand correctly, "elsewhere" is not defined by LPC/FirmwareHub 
standard but it depends on LPC controller (that's why it is not 
specified in flash datasheet). On GeodeLX/CS5536, when reading location 
at 0xFFBC0000, CS5536 generates a Firmware Hub Memory Read cycle with 
IDSEL=0 (I verified this with a logic analyzer connected to LPC bus). I 
tried to access different locations but I was not able to make CS5536 to 
generate read cycles with IDSEL different from 0. So I don't understand 
how the physical addresses are related to the IDSEL that is sent on the 
LPC bus by CS5536. Anybody can help?



-- 
llandre

DAVE Electronics System House - R&D Department
web:   http://www.dave.eu
email: r&d2 at dave-tech.it



From svn at coreboot.org  Tue Jun 17 17:30:00 2008
From: svn at coreboot.org (svn at coreboot.org)
Date: Tue, 17 Jun 2008 17:30:00 +0200
Subject: [coreboot] r202 - buildrom-devel/packages/qemu
Message-ID: <mailman.1628.1355071333.16123.coreboot@coreboot.org>

Author: ward
Date: 2008-06-17 17:29:59 +0200 (Tue, 17 Jun 2008)
New Revision: 202

Modified:
   buildrom-devel/packages/qemu/qemu.mk
Log:

The download URL for QEMU has changed.

This is a trivial patch.

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



Modified: buildrom-devel/packages/qemu/qemu.mk
===================================================================
--- buildrom-devel/packages/qemu/qemu.mk	2008-06-05 14:54:13 UTC (rev 201)
+++ buildrom-devel/packages/qemu/qemu.mk	2008-06-17 15:29:59 UTC (rev 202)
@@ -1,4 +1,4 @@
-QEMU_URL=http://fabrice.bellard.free.fr/qemu/
+QEMU_URL=http://bellard.org/qemu/
 QEMU_SOURCE=qemu-0.9.0.tar.gz
 QEMU_DIR=$(BUILD_DIR)/qemu
 QEMU_SRC_DIR=$(QEMU_DIR)/qemu-0.9.0




From rminnich at gmail.com  Tue Jun 17 17:56:29 2008
From: rminnich at gmail.com (ron minnich)
Date: Tue, 17 Jun 2008 08:56:29 -0700
Subject: [coreboot] dbe62 status
Message-ID: <13426df10806170856j7b1b369fp95db2137d8349633@mail.gmail.com>

X11 still gets very bad errors. I think the memory is not quite right:
BUG: unable to handle kernel paging request at fd1c858b
IP: [<d08e1430>] :nfs:nfs_readpage+0x15/0x211
*pde = 00000000
Oops: 0000 [#2]
Modules linked in: nfs lockd sunrpc via_velocity 9p 9pnet

Pid: 1219, comm: python Tainted: G      D  (2.6.25.7-faro #1)
EIP: 0060:[<d08e1430>] EFLAGS: 00010246 CPU: 0
EIP is at nfs_readpage+0x15/0x211 [nfs]
EAX: fd1c858b EBX: ce10bf40 ECX: d08f49a0 EDX: c1026980
ESI: ce380470 EDI: c1026980 EBP: ce38ff28 ESP: ce38feb8
 DS: 007b ES: 007b FS: 0000 GS: 0033 SS: 0068
Process python (pid: 1219, ti=ce38e000 task=ce836550 task.ti=ce38e000)
Stack: fffffffe 05f08f17 0000000d d0908194 ce5a9f14 00000002 c1026980 ce380470
       ce10bf40 ce38ff28 c012f271 ce380470 ce5a9f14 ce10bf84 ce5a9e78 00000000
       00000004 ce38ff44 c014bb95 d0908194 ce380470 ce836550 ce1f5060 c013659d
Call Trace:
 [<c012f271>] filemap_fault+0x288/0x2e0
 [<c014bb95>] do_path_lookup+0xf3/0x10c
 [<c013659d>] __do_fault+0x4e/0x2d2
 [<c0137738>] handle_mm_fault+0x1fc/0x439
 [<c010d152>] do_page_fault+0x1f9/0x513
 [<c010cf59>] do_page_fault+0x0/0x513
 [<c02925da>] error_code+0x6a/0x70
 =======================
Code: 75 04 0f ba 2b 03 89 f0 5b 5e 5f 5d e9 7b f9 ff ff 5b 5e 5f 5d
c3 55 57 89 d7 56 53 89 c3 83 ec 18 8b 42 10 f6 05 2c 45 89 d0 08 <8b>
28 74 16 ff 72
EIP: [<d08e1430>] nfs_readpage+0x15/0x211 [nfs] SS:ESP 0068:ce38feb8
---[ end trace a6f30bfb7037e608 ]---
Eeek! page_mapcount(page) went negative! (-2050490369)
  page pfn = 134e
  page->flags = fffffdb4
BUG: unable to handle kernel paging request at fffffe9c
IP: [<c013b8ad>] page_remove_rmap+0x62/0xf6
*pde = 00001067 *pte = 00000000
Oops: 0000 [#3]

Ouch.

OK, so, dbe62 owners, let's try to work out memory.

ron



From Marc.Jones at amd.com  Tue Jun 17 17:59:28 2008
From: Marc.Jones at amd.com (Marc Jones)
Date: Tue, 17 Jun 2008 09:59:28 -0600
Subject: [coreboot] dbe62 status
In-Reply-To: <13426df10806170856j7b1b369fp95db2137d8349633@mail.gmail.com>
References: <13426df10806170856j7b1b369fp95db2137d8349633@mail.gmail.com>
Message-ID: <4857DF60.1080006@amd.com>

ron minnich wrote:
> X11 still gets very bad errors. I think the memory is not quite right:

Ron,

Have you run an exhaustive memtest86?

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  Tue Jun 17 18:13:53 2008
From: rminnich at gmail.com (ron minnich)
Date: Tue, 17 Jun 2008 09:13:53 -0700
Subject: [coreboot] dbe62 status
In-Reply-To: <4857DF60.1080006@amd.com>
References: <13426df10806170856j7b1b369fp95db2137d8349633@mail.gmail.com>
	<4857DF60.1080006@amd.com>
Message-ID: <13426df10806170913v787219d3gd8ad9b17cbb67ac1@mail.gmail.com>

I just discovered I can  no longer build a working memtest. I asked
buildrom to do it but it no longer even starts:
Stage2 code done.
LAR: Attempting to open 'normal/payload/segment0'.
LAR: Attempting to open 'normal/payload/segment1'.
LAR: load_file: No such file 'normal/payload/segment1'
========== mainboard_pre_payload: done =========================================

 Entry point address:               0x10000
  Start of program headers:          52 (bytes into file)
  Start of section headers:          117012 (bytes into file)
  Flags:                             0x0
  Size of this header:               52 (bytes)
  Size of program headers:           32 (bytes)
  Number of program headers:         1
  Size of section headers:           40 (bytes)
  Number of section headers:         3
  Section header string table index: 2

Section Headers:
  [Nr] Name              Type            Addr     Off    Size   ES Flg Lk Inf Al
  [ 0]                   NULL            00000000 000000 000000 00      0   0  0
  [ 1] .data             PROGBITS        00010000 001000 01b900 00  WA  0   0  1
  [ 2] .shstrtab         STRTAB          00000000 01c900 000011 00      0   0  1
Key to Flags:
  W (write), A (alloc), X (execute), M (merge), S (strings)
  I (info), L (link order), G (group), x (unknown)
  O (extra OS processing required) o (OS specific), p (processor specific)

There are no section groups in this file.

Program Headers:
  Type           Offset   VirtAddr   PhysAddr   FileSiz MemSiz  Flg Align
  LOAD           0x001000 0x00010000 0x00010000 0x1b900 0x1b900 RW  0x1000

arg. I used to be able to run it.

ron



From svn at coreboot.org  Tue Jun 17 18:38:56 2008
From: svn at coreboot.org (svn at coreboot.org)
Date: Tue, 17 Jun 2008 18:38:56 +0200
Subject: [coreboot] r203 - buildrom-devel/config/platforms
Message-ID: <mailman.1629.1355071333.16123.coreboot@coreboot.org>

Author: ward
Date: 2008-06-17 18:38:56 +0200 (Tue, 17 Jun 2008)
New Revision: 203

Modified:
   buildrom-devel/config/platforms/qemu.conf
Log:

Fix LAB builds for qemu - we were not using the right kernel version.

This is a trivial patch.

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



Modified: buildrom-devel/config/platforms/qemu.conf
===================================================================
--- buildrom-devel/config/platforms/qemu.conf	2008-06-17 15:29:59 UTC (rev 202)
+++ buildrom-devel/config/platforms/qemu.conf	2008-06-17 16:38:56 UTC (rev 203)
@@ -7,8 +7,8 @@
 
 # kernel configuration (for LAB)
 
-KERNEL_VERSION=2.6.20
-KERNEL_CONFIG=$(PACKAGE_DIR)/kernel/conf/defconfig-qemu-2.6.20
+KERNEL_VERSION=2.6.22.2
+KERNEL_CONFIG=$(PACKAGE_DIR)/kernel/conf/defconfig-qemu
 UCLIBC_VER=0.9.29
 
 # Etherboot configuration




From Marc.Jones at amd.com  Tue Jun 17 19:38:58 2008
From: Marc.Jones at amd.com (Marc Jones)
Date: Tue, 17 Jun 2008 11:38:58 -0600
Subject: [coreboot] Firmware hub flash addressing [off-topic]
In-Reply-To: <4857CA88.8080701@dave-tech.it>
References: <484F9C2B.8030003@dave-tech.it> <4857CA88.8080701@dave-tech.it>
Message-ID: <4857F6B2.3070904@amd.com>

llandre wrote:
>> Sorry for posting a message that is a little bit off-topic.
>>
>> I'm working with a SST 8 Mbit Firmware Hub SST49LF008A flash connected 
>> to Geode LX LPC bus.
>> I need to understand where flash registers are mapped in case the flash 
>> ID is set to 1 (this flash is not the boot flash that has ID=0).
>> The datasheet just says about identification registers (same thing 
>> applies for other registers too):
>>
>> JEDEC ID Registers
>> The JEDEC ID registers for the boot device appear at
>> FFBC0000H and FFBC0001H in the 4 GByte system
>> memory map, and will appear ***elsewhere*** if the device is not
>> the boot device.
>>
>>
>> Anybody can tell me what does "elsewhere" stand for in this sentence?
> Some news ...
> If I understand correctly, "elsewhere" is not defined by LPC/FirmwareHub 
> standard but it depends on LPC controller (that's why it is not 
> specified in flash datasheet). On GeodeLX/CS5536, when reading location 
> at 0xFFBC0000, CS5536 generates a Firmware Hub Memory Read cycle with 
> IDSEL=0 (I verified this with a logic analyzer connected to LPC bus). I 
> tried to access different locations but I was not able to make CS5536 to 
> generate read cycles with IDSEL different from 0. So I don't understand 
> how the physical addresses are related to the IDSEL that is sent on the 
> LPC bus by CS5536. Anybody can help?

llandre,

Sorry, the 5536 only sets IDSEL = 0 for FWH.  But, I think you can 
design in multiple LPC ROMs.

The LPC ROMs should have ID pins that map them to different regions, 
i.e. there's an internal compare for the inverted values to certain 
address bits.  So it seems you should be able to map multiple devices in 
the address space this way.

See page 10 -
http://www.sst.com/downloads/datasheet/S71213.pdf

Marc



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




From nick.innes at blueyonder.co.uk  Tue Jun 17 21:11:40 2008
From: nick.innes at blueyonder.co.uk (Nick Innes)
Date: Tue, 17 Jun 2008 20:11:40 +0100
Subject: [coreboot] Thin Client Compaq Evo T20
In-Reply-To: <1211560413.14762.38.camel@MyDesktop.blueyonder.co.uk>
References: <482885C1.4020305@tidepool.ca> <20080513011725.GA2124@greenwood>
	<48366B1B.8030200@tidepool.ca>  <20080523091927.5cd0747d@Tansmeta>
	<1211560413.14762.38.camel@MyDesktop.blueyonder.co.uk>
Message-ID: <1213729900.3371.18.camel@MyDesktop.blueyonder.co.uk>

Hi,

I've been making reasonable progress on getting one of my T30s to boot.
I can reliably get the thing to etherboot a 2.6.24 kernel I compiled and
an ugly bodged up RAM disk I've created.

I've got what I think is a working irq_tables.c file for the mainboard,
however when the kernel boots it says 'PCI: Guessed IRQ x for device
0000:00:y.0', where x is the IRQ in my irq_tables.c and y is the devfn
(device? slot?) in the file, just before each device gets used for the
first time.
After a little prodding checkpir gave me what I assume to be a valid
checksum, which seems to have made no difference. Is the kernel very
good at guessing, or are these the symptom of a bad checksum in the
table, or an incorrect kernel config?

I'm also a little stumped on the initialisation of the cardbus slot - it
all looks good, but one of the GPIO lines on the super-IO is connected
to the /shutdown line on the power controller, so no power seems to get
through. It can detect insertions and removals of cards and correctly
identify whether the inserted card is PCMCIA or Cardbus.
Is it reasonable that the cardbus controller can see the type of card if
the card is unpowered? I think the EPIA-MII is a very different animal,
but would be thrilled to be wrong and benefit from someone's experiences
with it!

Nick





From peter at stuge.se  Tue Jun 17 22:20:21 2008
From: peter at stuge.se (Peter Stuge)
Date: Tue, 17 Jun 2008 22:20:21 +0200
Subject: [coreboot] Thin Client Compaq Evo T20
In-Reply-To: <1213729900.3371.18.camel@MyDesktop.blueyonder.co.uk>
References: <482885C1.4020305@tidepool.ca> <20080513011725.GA2124@greenwood>
	<48366B1B.8030200@tidepool.ca> <20080523091927.5cd0747d@Tansmeta>
	<1211560413.14762.38.camel@MyDesktop.blueyonder.co.uk>
	<1213729900.3371.18.camel@MyDesktop.blueyonder.co.uk>
Message-ID: <20080617202021.14679.qmail@stuge.se>

On Tue, Jun 17, 2008 at 08:11:40PM +0100, Nick Innes wrote:
> I'm also a little stumped on the initialisation of the cardbus slot
..
> I think the EPIA-MII is a very different animal, but would be
> thrilled to be wrong and benefit from someone's experiences with it!

EPIA-MII has a Ricoh RL5c456 controller which is really buggy. Linux
PCMCIA people have documented a unfixable (IIRC) problem with slot
power.

Which controller is in the T30?


//Peter



From peter at stuge.se  Tue Jun 17 22:21:31 2008
From: peter at stuge.se (Peter Stuge)
Date: Tue, 17 Jun 2008 22:21:31 +0200
Subject: [coreboot] Thin Client Compaq Evo T20
In-Reply-To: <20080617202021.14679.qmail@stuge.se>
References: <482885C1.4020305@tidepool.ca> <20080513011725.GA2124@greenwood>
	<48366B1B.8030200@tidepool.ca> <20080523091927.5cd0747d@Tansmeta>
	<1211560413.14762.38.camel@MyDesktop.blueyonder.co.uk>
	<1213729900.3371.18.camel@MyDesktop.blueyonder.co.uk>
	<20080617202021.14679.qmail@stuge.se>
Message-ID: <20080617202131.15419.qmail@stuge.se>

On Tue, Jun 17, 2008 at 10:20:21PM +0200, Peter Stuge wrote:
> On Tue, Jun 17, 2008 at 08:11:40PM +0100, Nick Innes wrote:
> > I'm also a little stumped on the initialisation of the cardbus slot
> ..
> > I think the EPIA-MII is a very different animal, but would be
> > thrilled to be wrong and benefit from someone's experiences with it!
> 
> EPIA-MII has a Ricoh RL5c456 controller which is really buggy. Linux
> PCMCIA people have documented a unfixable (IIRC) problem with slot
> power.
> 
> Which controller is in the T30?

Never mind, just read your old post. No idea about the TI controller.

Can you look into that shutdown GPIO?


//Peter



From nick.innes at blueyonder.co.uk  Tue Jun 17 22:55:15 2008
From: nick.innes at blueyonder.co.uk (Nick Innes)
Date: Tue, 17 Jun 2008 21:55:15 +0100
Subject: [coreboot] Thin Client Compaq Evo T20
In-Reply-To: <20080617202131.15419.qmail@stuge.se>
References: <482885C1.4020305@tidepool.ca> <20080513011725.GA2124@greenwood>
	<48366B1B.8030200@tidepool.ca> <20080523091927.5cd0747d@Tansmeta>
	<1211560413.14762.38.camel@MyDesktop.blueyonder.co.uk>
	<1213729900.3371.18.camel@MyDesktop.blueyonder.co.uk>
	<20080617202021.14679.qmail@stuge.se>
	<20080617202131.15419.qmail@stuge.se>
Message-ID: <1213736115.7274.13.camel@MyDesktop.blueyonder.co.uk>

Hi Peter,

I'll have a play - I've looked at the TI datasheets for both parts, and
concluded that they don't give a sensible idea of when the signal should
be asserted and when not. It reads as though other signals control the
power to the card and this is an optional power switch, which I suspect
may be used by the original BIOS/CE.Net firmware to enable/disable the
slot for security reasons (I cannot find mention of this in the manual,
but cannot think of any other reason).

Is there any way in coreboot v2 to run something mainboard specific just
before starting the payload? I ask because on the T20 I have no output
but a bicolour LED connected to the southbridge, and it'd be good to
know when execution was about to be passed to the payload and that we'd
found RAM etc OK - I tried post ram initialisation in auto.c, however
this all happens before coreboot is copied to RAM and executed.

Nick

On Tue, 2008-06-17 at 22:21 +0200, Peter Stuge wrote:
> On Tue, Jun 17, 2008 at 10:20:21PM +0200, Peter Stuge wrote:
> > On Tue, Jun 17, 2008 at 08:11:40PM +0100, Nick Innes wrote:
> > > I'm also a little stumped on the initialisation of the cardbus slot
> > ..
> > > I think the EPIA-MII is a very different animal, but would be
> > > thrilled to be wrong and benefit from someone's experiences with it!
> > 
> > EPIA-MII has a Ricoh RL5c456 controller which is really buggy. Linux
> > PCMCIA people have documented a unfixable (IIRC) problem with slot
> > power.
> > 
> > Which controller is in the T30?
> 
> Never mind, just read your old post. No idea about the TI controller.
> 
> Can you look into that shutdown GPIO?
> 
> 
> //Peter
> 





From stepan at coresystems.de  Wed Jun 18 01:04:49 2008
From: stepan at coresystems.de (Stefan Reinauer)
Date: Wed, 18 Jun 2008 01:04:49 +0200
Subject: [coreboot] GSoC project(SCSI boot)__status report
In-Reply-To: <20080616223806.GA5103@morn.localdomain>
References: <92cbc4c70806020926i41b757c0ga661a3549c840be5@mail.gmail.com>
	<48513ADE.4050000@coresystems.de>
	<92cbc4c70806151947h524d5885sb4a4abba0a61ba8a@mail.gmail.com>
	<48567C4B.6050302@coresystems.de>
	<20080616223806.GA5103@morn.localdomain>
Message-ID: <48584311.4060308@coresystems.de>

Kevin O'Connor wrote:
> On Mon, Jun 16, 2008 Stefan Reinauer wrote:
>   
>> Zhang Rui is working for Google Summer of Code on booting off
>> SCSI using option roms with coreboot; He will be cleaning up the legacy
>> bios infrastructure parts in coreboot and make sure LegacyBIOS can
>> easily be used. It would be great if you could help him in case we are
>> in need of someone who knows Legacy BIOS really well!
>>     
>
> Sure.  I'd prefer to cc a mailing list though - it increases overall
> awareness.  Either coreboot or bochs lists would be fine.
>   
Ok, let's CC coreboot.org on this one.

>>>> The code in util/x86emu/ should then be modified to
>>>> * look for that file in the "lar"
>>>> * copy it to 0xf0000
>>>> * use it instead of the current handlers
>>>>     
>>>>         
>>> I have a question, what is the exact address of each handler function
>>> in the legacybios of Qemu/Bochs? Does the legacybios bin begin with
>>> the int0 call so the address of intXX call can be calculated from the
>>> beginning of legacybios bin?
>>>       
>
> Look for the ".org" strings in rombios.c of bochs bios.  Or, with
> LegacyBIOS, look for all the "entry_xxx" functions in
> src/romlayout.S.  See:
>
> http://git.linuxtogo.org/?p=kevin/legacybios.git;a=blob;f=src/romlayout.S;h=c8522612ab996533e6480dfe8ccc73e6af0f7c0d;hb=f54c150090ff38a73ef64a5d20fdfa0d9c403972#l363
>
> These define the entry points of the bios.  You definitely do _not_
> want to use the fixed addresses.  The one exception is f000:fff0 -
> which is the standard 16bit entry point for the "post" code of the
> bios.
>   
Ok, this is good.

>> Here's the first question to Kevin: How can we install the LegacyBIOS
>> interrupt handlers in order to call a single option rom and return back
>> to coreboot scope?
>>     
>
> I'm slightly confused by your use of "legacy bios" and "LegacyBIOS".
>   
:-) sorry, i will try to be more clear ..

> The latest code I've written (I'll call in LegacyBIOS) produces an elf
> file with a 32bit entry point.  It works as a standard payload with
> coreboot.
>   
How will this work? Is there a piece of 32bit code that will copy the
rest of LegacyBIOS to 0xf0000?

Is there a way to produce a "bios.bin" image that can be copied to
0xe0000 or 0xf0000 and still has all the coreboot stuff in it?

> In the general case, to use the 16bit handlers you need to run the
> code contained in the "post" section.  See:
>
> http://git.linuxtogo.org/?p=kevin/legacybios.git;a=blob;f=src/post.c;h=766e8984e765634a99989fbbd5cec74c914586a2;hb=f54c150090ff38a73ef64a5d20fdfa0d9c403972#l207
>
> This code initializes the BDA and EBDA memory areas - including the
> idt table.  However, the last part of "post" will attempt to boot the
> system (by calling int19).  If you want to "post" without booting,
> you'd need to extend LegacyBIOS to return to coreboot somehow.
>   
Ok. what would be the best way to do this? create a well known entry
point, similar to the reset vector?

> Is there a particular reason you'd want to return to coreboot?
>   
Yes: Currently VGA initialization in coreboot is done with a mix of
[vm86|x86emu] and half a intXX callback layer good enough to cope with
most graphics cards.

To make this really good, we'd need to heavily extend that intXX
callback code in coreboot. Which means it has to grow and grow and it
will eventually become a reduced version of LegacyBIOS. That is bad. If
we know LegacyBIOS does a pretty good job and it is reasonably small
(even qemu's current bios.bin is under 30k with , I would really prefer
using it for that task instead of yet another half-baked solution.

But when LegacyBIOS is supposed to replace the current intXX layer, it
has to return after doing its initialization, possibly it has to do
everything in _start() up and including the call to post().

The current option rom handling in post() may not be sufficient to
initialize all option roms in a system, as the current coreboot v3 code
is able to load an option rom for a given device from the "lar" archive,
copy it to the option rom area and execute it from there. This way we
can easily support an arbitrary number of onboard devices with option
roms. But when jumping into LegacyBIOS, not all option roms may be
visible in the address space at the same time.

I guess what I am suggesting is to split the bootmenu + OS loader
(int19) part from the init part.

This way we can still provide the option rom initialization via
LegacyBIOS' intXX callbacks but do not force the user to also use its
int19 boot code, but can instead jump into another payload - for example
UEFI or GRUB2 in flash.

>>>> What we have to find out is: Do we have to preserve much at all? Maybe
>>>> it is enough to install legacybios to 0xf0000 and let it live there,
>>>> then the payloads could just use intXX calls, as they can with a
>>>> non-free bios installed. But maybe it is not that trivial.
>>>>         
>
> As above, some of the interrupt handlers may run okay without "post"
> running.  However, several of them want to access the Bios Data Area
> (BDA) and Extended Bios Data Area (EBDA).  Basically, these are the
> working storage areas of the bios.  The "post" code is what
> initializes these memory areas.
>
> [...]
>   
Ok, I think this is much clearer now.
>>> Could we preserve 0xf0000 for the legacybios? If we can put coreboot
>>> table and ACPI tables and something else in the low 1M of RAM, it will
>>> be a good job. How much space will these tables take? I mean coreboot
>>> table and ACPI tables.
>>>       
>
> What I'm currently doing is having coreboot build the tables somewhere
> high in memory, and then having LegacyBIOS move the tables that need
> to be in 0xf0000 down to that area.
>   
Do you have a list of tables that need to live at 0xf0000? I know at
least a lot of ACPI can live pretty high up.
coreboot table currently resides at 0x530 or 0x500 but it is not very
well placed there.

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 --------------
An HTML attachment was scrubbed...
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20080618/6b939aa0/attachment.html>

From rminnich at gmail.com  Wed Jun 18 03:09:51 2008
From: rminnich at gmail.com (ron minnich)
Date: Tue, 17 Jun 2008 18:09:51 -0700
Subject: [coreboot] patch: supermicro h8qm8
Message-ID: <13426df10806171809if8ba56cyc8d365b4eb2d8cdd@mail.gmail.com>

coreboot for this board. I'd like to get this in so some folks who
need to see it can see it. This is assembled from other boards so far.
Once I start real changes I'll modify copyright as needed.

thanks

ron
-------------- next part --------------
A non-text attachment was scrubbed...
Name: h8qm8.diff
Type: text/x-patch
Size: 148982 bytes
Desc: not available
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20080617/1951dd50/attachment.diff>

From ward at gnu.org  Wed Jun 18 03:16:39 2008
From: ward at gnu.org (Ward Vandewege)
Date: Tue, 17 Jun 2008 21:16:39 -0400
Subject: [coreboot] patch: supermicro h8qm8
In-Reply-To: <13426df10806171809if8ba56cyc8d365b4eb2d8cdd@mail.gmail.com>
References: <13426df10806171809if8ba56cyc8d365b4eb2d8cdd@mail.gmail.com>
Message-ID: <20080618011639.GA4515@localdomain>

Hi Ron,

On Tue, Jun 17, 2008 at 06:09:51PM -0700, ron minnich wrote:
> This is for the supermicro h8qm8. I am on a short fuse here (trying to fix a problem) 
> and want to get this initial pass in, esp. for amd to see. 
> 
> The parts are put together from serengeti_cheetah_fam10 and m57sli (which has mcp55). 
> 
> I will add copyright when it starts to make sense. 
> 
> Also, this is from code already in the code tree. I don't think we need too long a discussion 
> of formatting ;-)
> 
> Status: almost compiles: 
> /usr/bin/ld: warning: dot moved backwards before `.id'
> /usr/bin/ld: warning: dot moved backwards before `.id'
> /usr/bin/ld: warning: dot moved backwards before `.id'
> crt0.o: In function `finalize_node_setup':
> crt0.S:(.rom.text+0x47a3): undefined reference to `get_sbdn'
> crt0.o: In function `real_main':
> crt0.S:(.rom.text+0xc16a): undefined reference to `soft_reset'
> collect2: ld returned 1 exit status
> 
> There's a bit more work left but I like having this on the svn server, not on my laptop. 
> 
> Signed-off-by: Ronald G. Minnich <rminnich at gmail.com>

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

if you do not commit this spurious hunk:

> Index: targets/gigabyte/ga_2761gxdk/Config.lb
> ===================================================================
> --- targets/gigabyte/ga_2761gxdk/Config.lb	(revision 3366)
> +++ targets/gigabyte/ga_2761gxdk/Config.lb	(working copy)
> @@ -32,8 +32,13 @@
>          option ROM_IMAGE_SIZE=0x20000
>          option XIP_ROM_SIZE=0x40000
>          option COREBOOT_EXTRA_VERSION="$(shell cat ../../VERSION)_Normal"
> +<<<<<<< .mine
> +#        payload ../../../../payloads/filo_uda1.elf
> +	payload /tmp/filo.elf
> +=======
>  #	payload ../../../../payloads/filo_uda1.elf
>  	payload ../payload.elf
> +>>>>>>> .r3127
>  end
>  
>  romimage "fallback"
> @@ -42,8 +47,13 @@
>          option ROM_IMAGE_SIZE=0x20000
>          option XIP_ROM_SIZE=0x40000
>          option COREBOOT_EXTRA_VERSION="$(shell cat ../../VERSION)_Fallback"
> +<<<<<<< .mine
> +#        payload ../../../../payloads/filo_uda1.elf
> +	payload /tmp/filo.elf
> +=======
>  #	payload ../../../../payloads/filo_uda1.elf
>  	payload ../payload.elf
> +>>>>>>> .r3127
>  end
>  
>  romimage "failover"


Thanks,
Ward.

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



From joe at settoplinux.org  Wed Jun 18 03:25:59 2008
From: joe at settoplinux.org (Joseph Smith)
Date: Tue, 17 Jun 2008 21:25:59 -0400
Subject: [coreboot]
	=?utf-8?q?GSoC_project=28SCSI_boot=29=5F=5Fstatus_repo?=
	=?utf-8?q?rt?=
In-Reply-To: <48584311.4060308@coresystems.de>
References: <92cbc4c70806020926i41b757c0ga661a3549c840be5@mail.gmail.com>
	<48513ADE.4050000@coresystems.de>
	<92cbc4c70806151947h524d5885sb4a4abba0a61ba8a@mail.gmail.com>
	<48567C4B.6050302@coresystems.de>
	<20080616223806.GA5103@morn.localdomain>
	<48584311.4060308@coresystems.de>
Message-ID: <5291a56333627468cb118eda911dc2af@imap.1and1.com>




On Wed, 18 Jun 2008 01:04:49 +0200, Stefan Reinauer <stepan at coresystems.de>
wrote:
> Kevin O'Connor wrote:
>> On Mon, Jun 16, 2008 Stefan Reinauer wrote:
>>
>>> Zhang Rui is working for Google Summer of Code on booting off
>>> SCSI using option roms with coreboot; He will be cleaning up the legacy
>>> bios infrastructure parts in coreboot and make sure LegacyBIOS can
>>> easily be used. It would be great if you could help him in case we are
>>> in need of someone who knows Legacy BIOS really well!
>>>
That's sweet, great work:-)
>
>
> To make this really good, we'd need to heavily extend that intXX
> callback code in coreboot. Which means it has to grow and grow and it
> will eventually become a reduced version of LegacyBIOS. That is bad. If
> we know LegacyBIOS does a pretty good job and it is reasonably small
> (even qemu's current bios.bin is under 30k with , I would really prefer
> using it for that task instead of yet another half-baked solution.
>
I think we all came to an agreement that the only "real" way to do this is
integrate legacybios (or parts) into coreboot (as an option of course).
> 
> But when LegacyBIOS is supposed to replace the current intXX layer, it
> has to return after doing its initialization, possibly it has to do
> everything in _start() up and including the call to post().
> 
> The current option rom handling in post() may not be sufficient to
> initialize all option roms in a system, as the current coreboot v3 code
> is able to load an option rom for a given device from the "lar" archive,
> copy it to the option rom area and execute it from there. This way we
> can easily support an arbitrary number of onboard devices with option
> roms. But when jumping into LegacyBIOS, not all option roms may be
> visible in the address space at the same time.
> 
> I guess what I am suggesting is to split the bootmenu + OS loader
> (int19) part from the init part.
> 
> This way we can still provide the option rom initialization via
> LegacyBIOS' intXX callbacks but do not force the user to also use its
> int19 boot code, but can instead jump into another payload - for example
> UEFI or GRUB2 in flash.
> 
How would one go about this? You lost me here?

(off topic)
Speaking of INT19 I found this neat little article on INT19 and the master
boot record. Maybe it helps in some way?

-- 
Thanks,
Joseph Smith
Set-Top-Linux
www.settoplinux.org




From joe at settoplinux.org  Wed Jun 18 03:29:02 2008
From: joe at settoplinux.org (Joseph Smith)
Date: Tue, 17 Jun 2008 21:29:02 -0400
Subject: [coreboot]
	=?utf-8?q?GSoC_project=28SCSI_boot=29=5F=5Fstatus_repo?=
	=?utf-8?q?rt?=
In-Reply-To: <5291a56333627468cb118eda911dc2af@imap.1and1.com>
References: <92cbc4c70806020926i41b757c0ga661a3549c840be5@mail.gmail.com>
	<48513ADE.4050000@coresystems.de>
	<92cbc4c70806151947h524d5885sb4a4abba0a61ba8a@mail.gmail.com>
	<48567C4B.6050302@coresystems.de>
	<20080616223806.GA5103@morn.localdomain>
	<48584311.4060308@coresystems.de>
	<5291a56333627468cb118eda911dc2af@imap.1and1.com>
Message-ID: <1df8670e42ee09ed5e5cd07c96f21040@imap.1and1.com>




On Tue, 17 Jun 2008 21:25:59 -0400, Joseph Smith <joe at settoplinux.org>
wrote:
> 
> 
> 
> On Wed, 18 Jun 2008 01:04:49 +0200, Stefan Reinauer
> <stepan at coresystems.de>
> wrote:
>> Kevin O'Connor wrote:
>>> On Mon, Jun 16, 2008 Stefan Reinauer wrote:
>>>
>>>> Zhang Rui is working for Google Summer of Code on booting off
>>>> SCSI using option roms with coreboot; He will be cleaning up the
> legacy
>>>> bios infrastructure parts in coreboot and make sure LegacyBIOS can
>>>> easily be used. It would be great if you could help him in case we are
>>>> in need of someone who knows Legacy BIOS really well!
>>>>
> That's sweet, great work:-)
>>
>>
>> To make this really good, we'd need to heavily extend that intXX
>> callback code in coreboot. Which means it has to grow and grow and it
>> will eventually become a reduced version of LegacyBIOS. That is bad. If
>> we know LegacyBIOS does a pretty good job and it is reasonably small
>> (even qemu's current bios.bin is under 30k with , I would really prefer
>> using it for that task instead of yet another half-baked solution.
>>
> I think we all came to an agreement that the only "real" way to do this
is
> integrate legacybios (or parts) into coreboot (as an option of course).
>>
>> But when LegacyBIOS is supposed to replace the current intXX layer, it
>> has to return after doing its initialization, possibly it has to do
>> everything in _start() up and including the call to post().
>>
>> The current option rom handling in post() may not be sufficient to
>> initialize all option roms in a system, as the current coreboot v3 code
>> is able to load an option rom for a given device from the "lar" archive,
>> copy it to the option rom area and execute it from there. This way we
>> can easily support an arbitrary number of onboard devices with option
>> roms. But when jumping into LegacyBIOS, not all option roms may be
>> visible in the address space at the same time.
>>
>> I guess what I am suggesting is to split the bootmenu + OS loader
>> (int19) part from the init part.
>>
>> This way we can still provide the option rom initialization via
>> LegacyBIOS' intXX callbacks but do not force the user to also use its
>> int19 boot code, but can instead jump into another payload - for example
>> UEFI or GRUB2 in flash.
>>
> How would one go about this? You lost me here?
> 
> (off topic)
> Speaking of INT19 I found this neat little article on INT19 and the
master
> boot record. Maybe it helps in some way?
> 
Oops here it is:
http://www.dewassoc.com/kbase/hard_drives/master_boot_record.htm

-- 
Thanks,
Joseph Smith
Set-Top-Linux
www.settoplinux.org




From ward at gnu.org  Wed Jun 18 03:44:37 2008
From: ward at gnu.org (Ward Vandewege)
Date: Tue, 17 Jun 2008 21:44:37 -0400
Subject: [coreboot] flashrom patch: Force read unknown flash chips
In-Reply-To: <20080615025314.30721.qmail@stuge.se>
References: <20080615025314.30721.qmail@stuge.se>
Message-ID: <20080618014437.GA6461@localdomain>

On Sun, Jun 15, 2008 at 04:53:14AM +0200, Peter Stuge wrote:
> flashrom: Force read unknown flash chips
> 
> When flash chip detection fails, it is still useful and possible to read the
> flash chip contents. If no flash chip is found in normal probes and the
> -f -r -c CHIPNAME options are given, a successful probe for the specified
> chip is forced, and flashrom reads the flash chip using either the read
> function for the specified chip, or if there is none, a simple memcpy().
> 
> The patch also moves the global variable int force in flashrom.c into main()
> and passes it as a parameter to layout.c:show_id(), which is the only other
> function that uses the variable. This is needed to avoid confusion with the
> new parameter int force which is added to flashrom.c:probe_flash() to force
> a probe success.
> 
> Signed-off-by: Peter Stuge <peter at stuge.se>

Tested on alix.2c3, works there.

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

with the changes proposed by Paul in this thread.

Thanks,
Ward.

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



From kevin at koconnor.net  Wed Jun 18 04:05:15 2008
From: kevin at koconnor.net (Kevin O'Connor)
Date: Tue, 17 Jun 2008 22:05:15 -0400
Subject: [coreboot] GSoC project(SCSI boot)__status report
In-Reply-To: <48584311.4060308@coresystems.de>
References: <92cbc4c70806020926i41b757c0ga661a3549c840be5@mail.gmail.com>
	<48513ADE.4050000@coresystems.de>
	<92cbc4c70806151947h524d5885sb4a4abba0a61ba8a@mail.gmail.com>
	<48567C4B.6050302@coresystems.de>
	<20080616223806.GA5103@morn.localdomain>
	<48584311.4060308@coresystems.de>
Message-ID: <20080618020515.GA28422@morn.localdomain>

On Wed, Jun 18, 2008 at 01:04:49AM +0200, Stefan Reinauer wrote:
> Kevin O'Connor wrote:
> > The latest code I've written (I'll call in LegacyBIOS) produces an elf
> > file with a 32bit entry point.  It works as a standard payload with
> > coreboot.
> >   
> How will this work? Is there a piece of 32bit code that will copy the
> rest of LegacyBIOS to 0xf0000?

The LegacyBIOS elf file expects to be loaded into the 0xf0000 area:

$ objdump -x out/bios.bin.elf
[...]
start address 0x000f66a0

Program Header:
    LOAD off    0x00001000 vaddr 0x000f0000 paddr 0x000f0000 align 2**12
         filesz 0x00010000 memsz 0x00010000 flags rw-

Currently all of the 16bit and 32bit code fits in the 64K segment at
0xf0000.  Just load the elf into that area and jump to it.

> Is there a way to produce a "bios.bin" image that can be copied to
> 0xe0000 or 0xf0000 and still has all the coreboot stuff in it?

The elf file (bios.bin.elf) is just a wrapper around a 64K blob
(bios.bin) with a specified entry point.  So, if one wants the blob
and not the elf then the file bios.bin can be used.

> > This code initializes the BDA and EBDA memory areas - including the
> > idt table.  However, the last part of "post" will attempt to boot the
> > system (by calling int19).  If you want to "post" without booting,
> > you'd need to extend LegacyBIOS to return to coreboot somehow.
> >   
> Ok. what would be the best way to do this? create a well known entry
> point, similar to the reset vector?

I wouldn't want to hardcode an address, but we can certainly create a
returnable coreboot entry point and have the build process export the
address somehow.  Effectively, the build process today is exporting
the current 32bit entry point by building an elf around bios.bin and
setting the elf "start address".

To return to coreboot, however, one also needs to restore the stack,
idt, and gdt..

> > Is there a particular reason you'd want to return to coreboot?
[...]
> The current option rom handling in post() may not be sufficient to
> initialize all option roms in a system, as the current coreboot v3 code
> is able to load an option rom for a given device from the "lar" archive,
> copy it to the option rom area and execute it from there. This way we
> can easily support an arbitrary number of onboard devices with option
> roms.

So, why not have coreboot load all the option roms from the lar into
ram and then launch LegacyBIOS?

>But when jumping into LegacyBIOS, not all option roms may be
> visible in the address space at the same time.

This is surprising.  If all the option roms don't fit, how would a
normal BIOS boot the system?  If one were to swap out an option rom,
how could one be sure the option rom didn't "hook" a 16bit int
handler?

> I guess what I am suggesting is to split the bootmenu + OS loader
> (int19) part from the init part.

I have no issue with doing this - it's trivial to implement multiple
entry points.  One need only implement a "__start2" type function that
called a subset of the init code.

I do think it is conceptually simpler if coreboot did its thing and
then launched LegacyBIOS as a payload.  Then LegacyBIOS could do its
thing and then launch the OS.

> This way we can still provide the option rom initialization via
> LegacyBIOS' intXX callbacks but do not force the user to also use its
> int19 boot code, but can instead jump into another payload - for example
> UEFI or GRUB2 in flash.

I think it would be cool to teach LegacyBIOS how to read the lar.
That way one could boot floppy, cdrom, hard drive, or lar payload.
Something like LegacyBIOS+Bayou.

I'm not tied to anything though - whatever works.

> > What I'm currently doing is having coreboot build the tables somewhere
> > high in memory, and then having LegacyBIOS move the tables that need
> > to be in 0xf0000 down to that area.
> >   
> Do you have a list of tables that need to live at 0xf0000? I know at
> least a lot of ACPI can live pretty high up.
> coreboot table currently resides at 0x530 or 0x500 but it is not very
> well placed there.

I know of only PIR (generally 32-160 bytes), ACPI RSDP (20-36 bytes),
SMBIOS Structure Table Entry Point (31 bytes), and mptable Floating
Pointer Structure (16 bytes).  (Note that SMBIOS is just a newer
definition of DMI - DMI's equivalent entry point is 15 bytes.)

It's straight forward to relocate these tables.  I changed coreboot-v2
code in write_tables() (arch/i386/boot/tables.c) to use a high memory
location instead of 0xf0000.  Coreboot-v2 automatically exported the
new location in the coreboot table.  I then had LegacyBIOS scan those
memory areas marked as CB_MEM_TABLE for the standard bios table
signatures.  See:

http://git.linuxtogo.org/?p=kevin/legacybios.git;a=blob;f=src/coreboot.c;h=635c2f683d699ff3a3f318bc5a4bb95538d95345;hb=f54c150090ff38a73ef64a5d20fdfa0d9c403972#l13

-Kevin



From svn at coreboot.org  Wed Jun 18 04:08:40 2008
From: svn at coreboot.org (svn at coreboot.org)
Date: Wed, 18 Jun 2008 04:08:40 +0200
Subject: [coreboot] r3367 - trunk/util/flashrom
Message-ID: <mailman.1630.1355071333.16123.coreboot@coreboot.org>

Author: stuge
Date: 2008-06-18 04:08:40 +0200 (Wed, 18 Jun 2008)
New Revision: 3367

Modified:
   trunk/util/flashrom/flash.h
   trunk/util/flashrom/flashrom.c
   trunk/util/flashrom/layout.c
Log:
flashrom: Force read unknown flash chips

When flash chip detection fails, it is still useful and possible to read the
flash chip contents. If no flash chip is found in normal probes and the
-f -r -c CHIPNAME options are given, a successful probe for the specified
chip is forced, and then flashrom reads the flash chip using either the read
function for the specified chip, or if there is none, a simple memcpy().

The patch also moves the global variable int force in flashrom.c into main()
and passes it as a parameter to layout.c:show_id(), which was the only other
function that used the variable. This is needed to avoid confusion with the
new parameter int force which is added to flashrom.c:probe_flash() and used
to force probe success for the chip named in char *chip_to_probe.

Signed-off-by: Peter Stuge <peter at stuge.se>
Acked-by: Ward Vandewege <ward at gnu.org>


Modified: trunk/util/flashrom/flash.h
===================================================================
--- trunk/util/flashrom/flash.h	2008-06-13 01:39:45 UTC (rev 3366)
+++ trunk/util/flashrom/flash.h	2008-06-18 02:08:40 UTC (rev 3367)
@@ -394,7 +394,7 @@
 int map_flash_registers(struct flashchip *flash);
 
 /* layout.c */
-int show_id(uint8_t *bios, int size);
+int show_id(uint8_t *bios, int size, int force);
 int read_romlayout(char *name);
 int find_romentry(char *name);
 int handle_romentries(uint8_t *buffer, uint8_t *content);

Modified: trunk/util/flashrom/flashrom.c
===================================================================
--- trunk/util/flashrom/flashrom.c	2008-06-13 01:39:45 UTC (rev 3366)
+++ trunk/util/flashrom/flashrom.c	2008-06-18 02:08:40 UTC (rev 3367)
@@ -43,7 +43,7 @@
 char *chip_to_probe = NULL;
 struct pci_access *pacc;	/* For board and chipset_enable */
 int exclude_start_page, exclude_end_page;
-int force = 0, verbose = 0;
+int verbose = 0;
 int fd_mem;
 
 struct pci_dev *pci_dev_find(uint16_t vendor, uint16_t device)
@@ -99,7 +99,7 @@
 	return 0;
 }
 
-struct flashchip *probe_flash(struct flashchip *flash)
+struct flashchip *probe_flash(struct flashchip *flash, int force)
 {
 	volatile uint8_t *bios;
 	unsigned long flash_baseaddr, size;
@@ -111,7 +111,7 @@
 		}
 		printf_debug("Probing for %s %s, %d KB: ",
 			     flash->vendor, flash->name, flash->total_size);
-		if (!flash->probe) {
+		if (!flash->probe && !force) {
 			printf_debug("failed! flashrom has no probe function for this flash chip.\n");
 			flash++;
 			continue;
@@ -150,7 +150,7 @@
 		}
 		flash->virtual_memory = bios;
 
-		if (flash->probe(flash) == 1) {
+		if (force || flash->probe(flash) == 1) {
 			printf("Found chip \"%s %s\" (%d KB) at physical address 0x%lx.\n",
 			       flash->vendor, flash->name, flash->total_size,
 			       flash_baseaddr);
@@ -251,6 +251,7 @@
 	struct flashchip *flash, *flashes[3];
 	int opt;
 	int option_index = 0;
+	int force = 0;
 	int read_it = 0, write_it = 0, erase_it = 0, verify_it = 0;
 	int ret = 0, i;
 #ifdef __FreeBSD__
@@ -413,7 +414,7 @@
 	board_flash_enable(lb_vendor, lb_part);
 
 	for (i = 0; i < ARRAY_SIZE(flashes); i++) {
-		flashes[i] = probe_flash(i ? flashes[i - 1] + 1 : flashchips);
+		flashes[i] = probe_flash(i ? flashes[i - 1] + 1 : flashchips, 0);
 		if (!flashes[i])
 			for (i++; i < ARRAY_SIZE(flashes); i++)
 				flashes[i] = NULL;
@@ -427,6 +428,44 @@
 		exit(1);
 	} else if (!flashes[0]) {
 		printf("No EEPROM/flash device found.\n");
+		if (!force || !chip_to_probe) {
+			printf("If you know which flash chip you have, and if this version of flashrom\n");
+			printf("supports a similar flash chip, you can try to force read your chip. Run:\n");
+			printf("flashrom -f -r -c similar_supported_flash_chip filename\n");
+			printf("\n");
+			printf("Note: flashrom can never write when the flash chip isn't found automatically.\n");
+		}
+		if (force && read_it && chip_to_probe) {
+			printf("Force read (-f -r -c) requested, forcing chip probe success:\n");
+			flashes[0] = probe_flash(flashchips, 1);
+			if (!flashes[0]) {
+				printf("flashrom does not support a flash chip named '%s'.\n", chip_to_probe);
+				printf("Run flashrom -L to view the hardware supported in this flashrom version.\n");
+				exit(1);
+			}
+			size = flashes[0]->total_size * 1024;
+			buf = (uint8_t *) calloc(size, sizeof(char));
+
+			if ((image = fopen(filename, "w")) == NULL) {
+				perror(filename);
+				exit(1);
+			}
+			printf("Force reading flash...");
+			if (!flashes[0]->read)
+				memcpy(buf, (const char *)flashes[0]->virtual_memory, size);
+			else
+				flashes[0]->read(flashes[0], buf);
+
+			if (exclude_end_position - exclude_start_position > 0)
+				memset(buf + exclude_start_position, 0,
+				       exclude_end_position - exclude_start_position);
+
+			fwrite(buf, sizeof(char), size, image);
+			fclose(image);
+			printf("done\n");
+			free(buf);
+			exit(0);
+		}
 		// FIXME: flash writes stay enabled!
 		exit(1);
 	}
@@ -522,7 +561,7 @@
 		}
 
 		fread(buf, sizeof(char), size, image);
-		show_id(buf, size);
+		show_id(buf, size, force);
 		fclose(image);
 	}
 

Modified: trunk/util/flashrom/layout.c
===================================================================
--- trunk/util/flashrom/layout.c	2008-06-13 01:39:45 UTC (rev 3366)
+++ trunk/util/flashrom/layout.c	2008-06-18 02:08:40 UTC (rev 3367)
@@ -28,8 +28,6 @@
 char *mainboard_part = NULL;
 int romimages = 0;
 
-extern int force;
-
 #define MAX_ROMLAYOUT	16
 
 typedef struct {
@@ -43,7 +41,7 @@
 
 static char *def_name = "DEFAULT";
 
-int show_id(uint8_t *bios, int size)
+int show_id(uint8_t *bios, int size, int force)
 {
 	unsigned int *walk;
 




From ward at gnu.org  Wed Jun 18 04:08:58 2008
From: ward at gnu.org (Ward Vandewege)
Date: Tue, 17 Jun 2008 22:08:58 -0400
Subject: [coreboot] Newbee patch for A49LF040A (Alix2c2) please have
	a	look.
In-Reply-To: <20080607142913.25791.qmail@stuge.se>
References: <4849CE86.60403@gmx.net> <20080607031750.GA17479@localdomain>
	<484A0261.6010302@gmx.net> <20080607034714.GA19574@localdomain>
	<484A73B7.4030609@gmx.net> <20080607130052.GA22883@localdomain>
	<484A8FD3.7040201@coresystems.de>
	<20080607134523.GA27554@localdomain>
	<484A9621.1020407@coresystems.de>
	<20080607142913.25791.qmail@stuge.se>
Message-ID: <20080618020858.GB6461@localdomain>

On Sat, Jun 07, 2008 at 04:29:13PM +0200, Peter Stuge wrote:
> On Sat, Jun 07, 2008 at 04:07:29PM +0200, Stefan Reinauer wrote:
> > Ah, this is broken... flashrom should not continue when it found a
> > chip in a given memory area already.
> 
> flashrom supports boards with more than one flash chip.
> 
> But perhaps we need to teach flashrom more about how chips can be
> connected. On boards with two chips, they can obviously not be on
> the same LPC bus for example. There would be a collision on the bus.
> 
> Ward and me investigated. The W29EE011 probe command is quite similar
> to the A49LF040A block erase command, but the last byte differs.
> A49LF040A seems to enter an undefined state when it receives such an
> unknown command. Sleeping the maximum A49LF040A timeout before
> sending the jedec ID exit command did not help.
> 
> It seems to me that the Amic chip is behaving badly.
> 
> Action plan?
> 
> 1. Penalize W29EE011 by never probing it without -c W29EE011
> 
> This sucks because the W29EE011 chip isn't the one misbehaving here.
> On the other hand, it does have a nasty product ID sequence.

Please find a patch attached that does just that.

Thanks,
Ward.

-- 
Ward Vandewege <ward at fsf.org>
Free Software Foundation - Senior System Administrator
-------------- next part --------------
A non-text attachment was scrubbed...
Name: flashrom-disable-probing-W29EE011.patch
Type: text/x-diff
Size: 847 bytes
Desc: not available
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20080617/9f401d83/attachment.bin>

From peter at stuge.se  Wed Jun 18 04:09:37 2008
From: peter at stuge.se (Peter Stuge)
Date: Wed, 18 Jun 2008 04:09:37 +0200
Subject: [coreboot] flashrom patch: Force read unknown flash chips
In-Reply-To: <20080618014437.GA6461@localdomain>
References: <20080615025314.30721.qmail@stuge.se>
	<20080618014437.GA6461@localdomain>
Message-ID: <20080618020937.2064.qmail@stuge.se>

On Tue, Jun 17, 2008 at 09:44:37PM -0400, Ward Vandewege wrote:
> > Signed-off-by: Peter Stuge <peter at stuge.se>
> 
> Tested on alix.2c3, works there.
> 
> Acked-by: Ward Vandewege <ward at gnu.org>
> with the changes proposed by Paul in this thread.

Thanks! r3367


//Peter



From ward at gnu.org  Wed Jun 18 04:25:15 2008
From: ward at gnu.org (Ward Vandewege)
Date: Tue, 17 Jun 2008 22:25:15 -0400
Subject: [coreboot] Newbee patch for A49LF040A (Alix2c2) please have
	a	look.
In-Reply-To: <20080618020858.GB6461@localdomain>
References: <20080607031750.GA17479@localdomain> <484A0261.6010302@gmx.net>
	<20080607034714.GA19574@localdomain> <484A73B7.4030609@gmx.net>
	<20080607130052.GA22883@localdomain>
	<484A8FD3.7040201@coresystems.de>
	<20080607134523.GA27554@localdomain>
	<484A9621.1020407@coresystems.de>
	<20080607142913.25791.qmail@stuge.se>
	<20080618020858.GB6461@localdomain>
Message-ID: <20080618022515.GA9157@localdomain>

On Tue, Jun 17, 2008 at 10:08:58PM -0400, Ward Vandewege wrote:
> On Sat, Jun 07, 2008 at 04:29:13PM +0200, Peter Stuge wrote:
> > On Sat, Jun 07, 2008 at 04:07:29PM +0200, Stefan Reinauer wrote:
> > > Ah, this is broken... flashrom should not continue when it found a
> > > chip in a given memory area already.
> > 
> > flashrom supports boards with more than one flash chip.
> > 
> > But perhaps we need to teach flashrom more about how chips can be
> > connected. On boards with two chips, they can obviously not be on
> > the same LPC bus for example. There would be a collision on the bus.
> > 
> > Ward and me investigated. The W29EE011 probe command is quite similar
> > to the A49LF040A block erase command, but the last byte differs.
> > A49LF040A seems to enter an undefined state when it receives such an
> > unknown command. Sleeping the maximum A49LF040A timeout before
> > sending the jedec ID exit command did not help.
> > 
> > It seems to me that the Amic chip is behaving badly.
> > 
> > Action plan?
> > 
> > 1. Penalize W29EE011 by never probing it without -c W29EE011
> > 
> > This sucks because the W29EE011 chip isn't the one misbehaving here.
> > On the other hand, it does have a nasty product ID sequence.
> 
> Please find a patch attached that does just that.

And now for a revised copy that does not disable -c W29EE011 as well (thanks
Peter!).

Thanks,
Ward.

-- 
Ward Vandewege <ward at fsf.org>
Free Software Foundation - Senior System Administrator
-------------- next part --------------
A non-text attachment was scrubbed...
Name: flashrom-disable-probing-W29EE011.b.patch
Type: text/x-diff
Size: 1044 bytes
Desc: not available
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20080617/691c1c73/attachment.bin>

From kevin at koconnor.net  Wed Jun 18 04:58:00 2008
From: kevin at koconnor.net (Kevin O'Connor)
Date: Tue, 17 Jun 2008 22:58:00 -0400
Subject: [coreboot] GSoC project(SCSI boot)__status report
In-Reply-To: <5291a56333627468cb118eda911dc2af@imap.1and1.com>
References: <92cbc4c70806020926i41b757c0ga661a3549c840be5@mail.gmail.com>
	<48513ADE.4050000@coresystems.de>
	<92cbc4c70806151947h524d5885sb4a4abba0a61ba8a@mail.gmail.com>
	<48567C4B.6050302@coresystems.de>
	<20080616223806.GA5103@morn.localdomain>
	<48584311.4060308@coresystems.de>
	<5291a56333627468cb118eda911dc2af@imap.1and1.com>
Message-ID: <20080618025800.GA28799@morn.localdomain>

On Tue, Jun 17, 2008 at 09:25:59PM -0400, Joseph Smith wrote:
> On Wed, 18 Jun 2008 01:04:49 +0200, Stefan Reinauer <stepan at coresystems.de>
> wrote:
> > To make this really good, we'd need to heavily extend that intXX
> > callback code in coreboot. Which means it has to grow and grow and it
> > will eventually become a reduced version of LegacyBIOS. That is bad. If
> > we know LegacyBIOS does a pretty good job and it is reasonably small
> > (even qemu's current bios.bin is under 30k with , I would really prefer
> > using it for that task instead of yet another half-baked solution.
> >
> I think we all came to an agreement that the only "real" way to do this is
> integrate legacybios (or parts) into coreboot (as an option of course).

I recommend caution here.

I think it is important that LegacyBIOS support kvm, qemu, and bochs.
Having the code support those environments will help increase the
overall user base, which will help ensure the core code supports many
different OSes and is thoroughly tested.  So, I don't think we want to
make LegacyBIOS coreboot specific.

I also don't think it would be a good idea to fork the code or copy
large parts of it into multiple repositories.

So, I'm all for aligning coreboot and LegacyBIOS - it is after all the
reason I started LegacyBIOS - but I think we need to come up with a
boundary between the two.  In my opinion, coreboot should (optionally)
call out to LegacyBIOS and the two should work towards the same goal.
But I don't think they should be tightly integrated at the source code
level.

-Kevin



From kevin at koconnor.net  Wed Jun 18 05:26:11 2008
From: kevin at koconnor.net (Kevin O'Connor)
Date: Tue, 17 Jun 2008 23:26:11 -0400
Subject: [coreboot] GSoC project(SCSI boot)__status report
In-Reply-To: <92cbc4c70806171953m11ab463cxd73a1382f9ceeda7@mail.gmail.com>
References: <92cbc4c70806020926i41b757c0ga661a3549c840be5@mail.gmail.com>
	<48513ADE.4050000@coresystems.de>
	<92cbc4c70806151947h524d5885sb4a4abba0a61ba8a@mail.gmail.com>
	<48567C4B.6050302@coresystems.de>
	<20080616223806.GA5103@morn.localdomain>
	<48584311.4060308@coresystems.de>
	<20080618020515.GA28422@morn.localdomain>
	<92cbc4c70806171953m11ab463cxd73a1382f9ceeda7@mail.gmail.com>
Message-ID: <20080618032611.GA28903@morn.localdomain>

Hi Zhang,

I don't think your mails are making it to the coreboot list.

On Wed, Jun 18, 2008 at 10:53:39AM +0800, ?? wrote:
> 2008/6/18 Kevin O'Connor <kevin at koconnor.net>:
> > The elf file (bios.bin.elf) is just a wrapper around a 64K blob
> > (bios.bin) with a specified entry point.  So, if one wants the blob
> > and not the elf then the file bios.bin can be used.
> 
> "bios.bin" is also produced after building of LegacyBIOS?

Yes.

> So we can just copy the "bios.bin" to 0xf0000?

Yes.

> and then how can we call the post() function?

Well, that will require some work.  :-)  Take a look at how the build
exports the assembler stub "post32" (in post.c) - which calls _start()
(also in post.c).

-Kevin



From peter at stuge.se  Wed Jun 18 06:28:26 2008
From: peter at stuge.se (Peter Stuge)
Date: Wed, 18 Jun 2008 06:28:26 +0200
Subject: [coreboot] flashrom: Add support for AMIC Technology A49LF040A and
	do not probe W29EE011 anymore
In-Reply-To: <20080618022515.GA9157@localdomain>
References: <484A0261.6010302@gmx.net> <20080607034714.GA19574@localdomain>
	<484A73B7.4030609@gmx.net> <20080607130052.GA22883@localdomain>
	<484A8FD3.7040201@coresystems.de>
	<20080607134523.GA27554@localdomain>
	<484A9621.1020407@coresystems.de>
	<20080607142913.25791.qmail@stuge.se>
	<20080618020858.GB6461@localdomain>
	<20080618022515.GA9157@localdomain>
Message-ID: <20080618042826.16077.qmail@stuge.se>

On Tue, Jun 17, 2008 at 10:25:15PM -0400, Ward Vandewege wrote:
> This patch disables default probing for the Winbond W29EE011, because
> its (unusual) probe sequence puts the AMIC A49LF040A in a funky state.

Ok! I put together these patches and also found that the Pm49FL
functions work for this chip.


//Peter
-------------- next part --------------
A non-text attachment was scrubbed...
Name: fr.a49lf040.patch
Type: text/x-diff
Size: 3298 bytes
Desc: not available
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20080618/47c7e91a/attachment.bin>

From rminnich at gmail.com  Wed Jun 18 07:13:02 2008
From: rminnich at gmail.com (ron minnich)
Date: Tue, 17 Jun 2008 22:13:02 -0700
Subject: [coreboot] memtest
Message-ID: <13426df10806172213h1d52fcaaje550c58b8a444845@mail.gmail.com>

OK, bulit memtest 3.3 from scratch and it's running.

interesting problem. The memtest built by buildrom won't boot on
dbe62, the 3.3. version I built is fine and loads via etherboot just
fine.

Anyway, it gets a depressingly large # of errors. We are definitely
not doing something right :-)

For anyone who wants eboot for dbe62, my .config for linuxbios, a
working memtest for all this, my scripts to build images, etc ... let
me know.

thanks

ron



From read.liu at gmail.com  Wed Jun 18 11:05:28 2008
From: read.liu at gmail.com (zhanyi liu)
Date: Wed, 18 Jun 2008 17:05:28 +0800
Subject: [coreboot] The project to support UEFI payload is on the way
Message-ID: <10b008310806180205l306009f5g82afcc1196ccba78@mail.gmail.com>

Hi, all

I am Joey Liu, a new member of coreboot project.
Many thanks to stefan and ron, I am very glad to join in the coreboot big
family.

My recent job is aim  to let coreboot support UEFI(Unified Extensible
Firmware Interface) payload.
TianoCore, UEFI implementation from Intel corp., will be adopted.
This is excellent project, I will try hard to finish.
I am just starting it.
if who is interested in it or has some wonderful idea, don't hesitate to
tell me what you think.
All of it will help me a lot. ^__^


Joey Liu
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20080618/98e69cfc/attachment.html>

From zrfail at gmail.com  Wed Jun 18 04:25:22 2008
From: zrfail at gmail.com (=?GB2312?B?tsCw3A==?=)
Date: Wed, 18 Jun 2008 10:25:22 +0800
Subject: [coreboot] GSoC project(SCSI boot)__status report
In-Reply-To: <48584311.4060308@coresystems.de>
References: <92cbc4c70806020926i41b757c0ga661a3549c840be5@mail.gmail.com>
	<48513ADE.4050000@coresystems.de>
	<92cbc4c70806151947h524d5885sb4a4abba0a61ba8a@mail.gmail.com>
	<48567C4B.6050302@coresystems.de>
	<20080616223806.GA5103@morn.localdomain>
	<48584311.4060308@coresystems.de>
Message-ID: <92cbc4c70806171925g67a9751avfe5b949b07b09660@mail.gmail.com>

2008/6/18 Stefan Reinauer <stepan at coresystems.de>:


> The latest code I've written (I'll call in LegacyBIOS) produces an elf
> file with a 32bit entry point.  It works as a standard payload with
> coreboot.

It seems that the LegacyBIOS is a elf file after building.

So I think there may be two way:
1. Integrate LegacyBIOS (or parts) into coreboot.
2. Let LegacyBIOS be a payload of coreboot and let LegacyBIOS to run
other payload. (This needs us to init the option rom and install a
special handler in LegacyBIOS)


>
> Is there a particular reason you'd want to return to coreboot?
>
>
> Yes: Currently VGA initialization in coreboot is done with a mix of
> [vm86|x86emu] and half a intXX callback layer good enough to cope with most
> graphics cards.
>
> To make this really good, we'd need to heavily extend that intXX callback
> code in coreboot. Which means it has to grow and grow and it will eventually
> become a reduced version of LegacyBIOS. That is bad. If we know LegacyBIOS
> does a pretty good job and it is reasonably small (even qemu's current
> bios.bin is under 30k with , I would really prefer using it for that task
> instead of yet another half-baked solution.
>
> But when LegacyBIOS is supposed to replace the current intXX layer, it has
> to return after doing its initialization, possibly it has to do everything
> in _start() up and including the call to post().
>
> The current option rom handling in post() may not be sufficient to
> initialize all option roms in a system, as the current coreboot v3 code is
> able to load an option rom for a given device from the "lar" archive, copy
> it to the option rom area and execute it from there. This way we can easily
> support an arbitrary number of onboard devices with option roms. But when
> jumping into LegacyBIOS, not all option roms may be visible in the address
> space at the same time.
>
> I guess what I am suggesting is to split the bootmenu + OS loader (int19)
> part from the init part.
>
> This way we can still provide the option rom initialization via LegacyBIOS'
> intXX callbacks but do not force the user to also use its int19 boot code,
> but can instead jump into another payload - for example UEFI or GRUB2 in
> flash.


So, we should choose the first way:
1. Integrate LegacyBIOS (or parts) into coreboot.



> What we have to find out is: Do we have to preserve much at all? Maybe
> it is enough to install legacybios to 0xf0000 and let it live there,
> then the payloads could just use intXX calls, as they can with a
> non-free bios installed. But maybe it is not that trivial.
>
>
> As above, some of the interrupt handlers may run okay without "post"
> running.  However, several of them want to access the Bios Data Area
> (BDA) and Extended Bios Data Area (EBDA).  Basically, these are the
> working storage areas of the bios.  The "post" code is what
> initializes these memory areas.


here is my thought:
1. First we should take the codes from the elf of LegacyBIOS and copy
it to some memory like 0xf0000. Maybe we should analyze the elf format
of LegacyBIOS?
2. Then we should extend the post() method to init the memory and do
_not_ booting after post().
3. Call the modified post() method.
4. initialization of the controller and having the controller option rom
bios install a "handler" (int13).  This the job for SCSI booting.  And
then other tasks.

is it OK?


Zhang Rui



From zrfail at gmail.com  Wed Jun 18 04:53:39 2008
From: zrfail at gmail.com (=?GB2312?B?tsCw3A==?=)
Date: Wed, 18 Jun 2008 10:53:39 +0800
Subject: [coreboot] GSoC project(SCSI boot)__status report
In-Reply-To: <20080618020515.GA28422@morn.localdomain>
References: <92cbc4c70806020926i41b757c0ga661a3549c840be5@mail.gmail.com>
	<48513ADE.4050000@coresystems.de>
	<92cbc4c70806151947h524d5885sb4a4abba0a61ba8a@mail.gmail.com>
	<48567C4B.6050302@coresystems.de>
	<20080616223806.GA5103@morn.localdomain>
	<48584311.4060308@coresystems.de>
	<20080618020515.GA28422@morn.localdomain>
Message-ID: <92cbc4c70806171953m11ab463cxd73a1382f9ceeda7@mail.gmail.com>

2008/6/18 Kevin O'Connor <kevin at koconnor.net>:
> Currently all of the 16bit and 32bit code fits in the 64K segment at
> 0xf0000.  Just load the elf into that area and jump to it.
>
>> Is there a way to produce a "bios.bin" image that can be copied to
>> 0xe0000 or 0xf0000 and still has all the coreboot stuff in it?
>
> The elf file (bios.bin.elf) is just a wrapper around a 64K blob
> (bios.bin) with a specified entry point.  So, if one wants the blob
> and not the elf then the file bios.bin can be used.
>

"bios.bin" is also produced after building of LegacyBIOS?
So we can just copy the "bios.bin" to 0xf0000?
and then how can we call the post() function?


>> > Is there a particular reason you'd want to return to coreboot?
> [...]
>> The current option rom handling in post() may not be sufficient to
>> initialize all option roms in a system, as the current coreboot v3 code
>> is able to load an option rom for a given device from the "lar" archive,
>> copy it to the option rom area and execute it from there. This way we
>> can easily support an arbitrary number of onboard devices with option
>> roms.
>
> So, why not have coreboot load all the option roms from the lar into
> ram and then launch LegacyBIOS?

This is another choise?



>>But when jumping into LegacyBIOS, not all option roms may be
>> visible in the address space at the same time.
>
> This is surprising.  If all the option roms don't fit, how would a
> normal BIOS boot the system?  If one were to swap out an option rom,
> how could one be sure the option rom didn't "hook" a 16bit int
> handler?
>
>> I guess what I am suggesting is to split the bootmenu + OS loader
>> (int19) part from the init part.
>
> I have no issue with doing this - it's trivial to implement multiple
> entry points.  One need only implement a "__start2" type function that
> called a subset of the init code.
>
> I do think it is conceptually simpler if coreboot did its thing and
> then launched LegacyBIOS as a payload.  Then LegacyBIOS could do its
> thing and then launch the OS.
>
>> This way we can still provide the option rom initialization via
>> LegacyBIOS' intXX callbacks but do not force the user to also use its
>> int19 boot code, but can instead jump into another payload - for example
>> UEFI or GRUB2 in flash.
>
> I think it would be cool to teach LegacyBIOS how to read the lar.
> That way one could boot floppy, cdrom, hard drive, or lar payload.
> Something like LegacyBIOS+Bayou.
>
> I'm not tied to anything though - whatever works.
>

There is two method:
1. use LegacyBIOS code in coreboot.
2. coreboot --> LegacyBIOS --> other payload(OS or "bootloader")

Which one to choose?
question:
1. use LegacyBIOS code in coreboot.
we should figure out how to use LegacyBIOS code within coreboot.

2. coreboot --> LegacyBIOS --> other payload(OS or "bootloader")
we should find a way to pass more information from coreboot to
LegacyBIOS, such as the option rom in lar.
Will the adding one more layer between coreboot and other payload cost
more time in the booting process?
Or maybe the it cost almost equally that one more layer and the
copying of code in LegacyBIOS to 0xf0000?

I think both way will work in the end and both need time to solve some problem.
So we should have a decision as early as possible and give more time
to the thinking of how to solve the problem of the decision.

Any more suggestions?


Zhang Rui



From zrfail at gmail.com  Wed Jun 18 12:14:43 2008
From: zrfail at gmail.com (=?GB2312?B?tsCw3A==?=)
Date: Wed, 18 Jun 2008 18:14:43 +0800
Subject: [coreboot] The project to support UEFI payload is on the way
In-Reply-To: <10b008310806180205l306009f5g82afcc1196ccba78@mail.gmail.com>
References: <10b008310806180205l306009f5g82afcc1196ccba78@mail.gmail.com>
Message-ID: <92cbc4c70806180314p729a5a9cmd4b6288b08ae7f19@mail.gmail.com>

Welcome.

Zhang Rui

2008/6/18, zhanyi liu <read.liu at gmail.com>:
> Hi, all
>
> I am Joey Liu, a new member of coreboot project.
> Many thanks to stefan and ron, I am very glad to join in the coreboot big
> family.
>
> My recent job is aim  to let coreboot support UEFI(Unified Extensible
> Firmware Interface) payload.
> TianoCore, UEFI implementation from Intel corp., will be adopted.
> This is excellent project, I will try hard to finish.
> I am just starting it.
> if who is interested in it or has some wonderful idea, don't hesitate to
> tell me what you think.
> All of it will help me a lot. ^__^
>
>
> Joey Liu
>
> --
> coreboot mailing list
> coreboot at coreboot.org
> http://www.coreboot.org/mailman/listinfo/coreboot
>



From r&d2 at dave-tech.it  Wed Jun 18 12:29:04 2008
From: r&d2 at dave-tech.it (llandre)
Date: Wed, 18 Jun 2008 12:29:04 +0200
Subject: [coreboot] Firmware hub flash addressing [off-topic]
In-Reply-To: <4857F6B2.3070904@amd.com>
References: <484F9C2B.8030003@dave-tech.it> <4857CA88.8080701@dave-tech.it>
	<4857F6B2.3070904@amd.com>
Message-ID: <4858E370.5050405@dave-tech.it>

Marc,

thanks for your help.

> Sorry, the 5536 only sets IDSEL = 0 for FWH.  
I see. Unfortunately this is not explained in databook.

> But, I think you can 
> design in multiple LPC ROMs.
> 
> The LPC ROMs should have ID pins that map them to different regions, 
> i.e. there's an internal compare for the inverted values to certain 
> address bits.  So it seems you should be able to map multiple devices in 
> the address space this way.
> 
> See page 10 -
> http://www.sst.com/downloads/datasheet/S71213.pdf
Fine. I think we'll replace FWH with LPC flash in order to support 
multiple ROMs on LPC bus.


Regards,
llandre

DAVE Electronics System House - R&D Department
web:   http://www.dave.eu
email: r&d2 at dave-tech.it



From c-d.hailfinger.devel.2006 at gmx.net  Wed Jun 18 13:56:33 2008
From: c-d.hailfinger.devel.2006 at gmx.net (Carl-Daniel Hailfinger)
Date: Wed, 18 Jun 2008 13:56:33 +0200
Subject: [coreboot] flashrom: Add support for AMIC Technology A49LF040A
 and	do not probe W29EE011 anymore
In-Reply-To: <20080618042826.16077.qmail@stuge.se>
References: <484A0261.6010302@gmx.net>
	<20080607034714.GA19574@localdomain>	<484A73B7.4030609@gmx.net>
	<20080607130052.GA22883@localdomain>	<484A8FD3.7040201@coresystems.de>	<20080607134523.GA27554@localdomain>	<484A9621.1020407@coresystems.de>	<20080607142913.25791.qmail@stuge.se>	<20080618020858.GB6461@localdomain>	<20080618022515.GA9157@localdomain>
	<20080618042826.16077.qmail@stuge.se>
Message-ID: <4858F7F1.6070708@gmx.net>

On 18.06.2008 06:28, Peter Stuge wrote:
> On Tue, Jun 17, 2008 at 10:25:15PM -0400, Ward Vandewege wrote:
>   
>> This patch disables default probing for the Winbond W29EE011, because
>> its (unusual) probe sequence puts the AMIC A49LF040A in a funky state.
>>     
>
> Ok! I put together these patches and also found that the Pm49FL
> functions work for this chip.
>   

I'd still like to know:
- whether the W29EE011 non-standard probing could be replaced by JEDEC
probing
- whether we can write 0xFF to the chip after probing, triggering a
reset for most chips.


Regards,
Carl-Daniel



From joe at settoplinux.org  Wed Jun 18 14:35:36 2008
From: joe at settoplinux.org (Joseph Smith)
Date: Wed, 18 Jun 2008 08:35:36 -0400
Subject: [coreboot] The project to support UEFI payload is on the way
In-Reply-To: <92cbc4c70806180314p729a5a9cmd4b6288b08ae7f19@mail.gmail.com>
References: <10b008310806180205l306009f5g82afcc1196ccba78@mail.gmail.com>
	<92cbc4c70806180314p729a5a9cmd4b6288b08ae7f19@mail.gmail.com>
Message-ID: <7462f4029eb94c7300cd73020d95d076@imap.1and1.com>




On Wed, 18 Jun 2008 18:14:43 +0800, "??" <zrfail at gmail.com> wrote:
> Welcome.
> 
> Zhang Rui
> 
> 2008/6/18, zhanyi liu <read.liu at gmail.com>:
>> Hi, all
>>
>> I am Joey Liu, a new member of coreboot project.
>> Many thanks to stefan and ron, I am very glad to join in the coreboot
> big
>> family.
>>
>> My recent job is aim  to let coreboot support UEFI(Unified Extensible
>> Firmware Interface) payload.
>> TianoCore, UEFI implementation from Intel corp., will be adopted.
>> This is excellent project, I will try hard to finish.
>> I am just starting it.
>> if who is interested in it or has some wonderful idea, don't hesitate to
>> tell me what you think.
>> All of it will help me a lot. ^__^
>>
>>
Yes, welcome Joey Liu, if you have any questions or need help, do not
hesitate to ask.
I am excited about this:-)

-- 
Thanks,
Joseph Smith
Set-Top-Linux
www.settoplinux.org




From ward at gnu.org  Wed Jun 18 14:42:32 2008
From: ward at gnu.org (Ward Vandewege)
Date: Wed, 18 Jun 2008 08:42:32 -0400
Subject: [coreboot] flashrom: Add support for AMIC Technology
	A49LF040A	and do not probe W29EE011 anymore
In-Reply-To: <20080618042826.16077.qmail@stuge.se>
References: <20080607034714.GA19574@localdomain> <484A73B7.4030609@gmx.net>
	<20080607130052.GA22883@localdomain>
	<484A8FD3.7040201@coresystems.de>
	<20080607134523.GA27554@localdomain>
	<484A9621.1020407@coresystems.de>
	<20080607142913.25791.qmail@stuge.se>
	<20080618020858.GB6461@localdomain>
	<20080618022515.GA9157@localdomain>
	<20080618042826.16077.qmail@stuge.se>
Message-ID: <20080618124232.GA17315@localdomain>

On Wed, Jun 18, 2008 at 06:28:26AM +0200, Peter Stuge wrote:
> On Tue, Jun 17, 2008 at 10:25:15PM -0400, Ward Vandewege wrote:
> > This patch disables default probing for the Winbond W29EE011, because
> > its (unusual) probe sequence puts the AMIC A49LF040A in a funky state.
> 
> Ok! I put together these patches and also found that the Pm49FL
> functions work for this chip.
> 
> 
> //Peter
> 
> 
> !DSPAM:4858af3c32361804284693!

> flashrom: Add support for AMIC Technology A49LF040A and do not probe W29EE011 anymore
> 
> Jens sent the first patch that added A49LF040A to flash.h and flashchips.c
> using _jedec and _49lf040 functions.
> 
> An issue was found with probe_w29ee011() for the Winbond W29EE011, which
> caused the A49LF040A to no longer respond to any commands.
> 
> Ward made a patch to disable probing by default for the W29EE011 following
> some discussion. Using -c W29EE011 will make flashrom probe for the chip.
> 
> Peter did some more datasheet diving and found that the Pm49FL00x functions
> suited this chip quite well because of the block locking registers in
> A49LF040A, and finally tested PROBE READ ERASE WRITE to work on ALIX.3c3.
> 
> Signed-off-by: Jens Kuehnel <coreboot at jens.kuehnel.org>
> Signed-off-by: Ward Vandewege <ward at gnu.org>
> Signed-off-by: Peter Stuge <peter at stuge.se>

Excellent - confirmed to work on alix.2c3.

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

Thanks,
Ward.

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



From joe at settoplinux.org  Wed Jun 18 14:53:12 2008
From: joe at settoplinux.org (Joseph Smith)
Date: Wed, 18 Jun 2008 08:53:12 -0400
Subject: [coreboot]
	=?utf-8?q?GSoC_project=28SCSI_boot=29=5F=5Fstatus_repo?=
	=?utf-8?q?rt?=
In-Reply-To: <20080618025800.GA28799@morn.localdomain>
References: <92cbc4c70806020926i41b757c0ga661a3549c840be5@mail.gmail.com>
	<48513ADE.4050000@coresystems.de>
	<92cbc4c70806151947h524d5885sb4a4abba0a61ba8a@mail.gmail.com>
	<48567C4B.6050302@coresystems.de>
	<20080616223806.GA5103@morn.localdomain>
	<48584311.4060308@coresystems.de>
	<5291a56333627468cb118eda911dc2af@imap.1and1.com>
	<20080618025800.GA28799@morn.localdomain>
Message-ID: <a7df9ffb104f47b43005b4b3d234abbc@imap.1and1.com>




On Tue, 17 Jun 2008 22:58:00 -0400, Kevin O'Connor <kevin at koconnor.net>
wrote:
> On Tue, Jun 17, 2008 at 09:25:59PM -0400, Joseph Smith wrote:
>> On Wed, 18 Jun 2008 01:04:49 +0200, Stefan Reinauer
> <stepan at coresystems.de>
>> wrote:
>> > To make this really good, we'd need to heavily extend that intXX
>> > callback code in coreboot. Which means it has to grow and grow and it
>> > will eventually become a reduced version of LegacyBIOS. That is bad.
> If
>> > we know LegacyBIOS does a pretty good job and it is reasonably small
>> > (even qemu's current bios.bin is under 30k with , I would really
> prefer
>> > using it for that task instead of yet another half-baked solution.
>> >
>> I think we all came to an agreement that the only "real" way to do this
> is
>> integrate legacybios (or parts) into coreboot (as an option of course).
> 
> I recommend caution here.
> 
> I think it is important that LegacyBIOS support kvm, qemu, and bochs.
> Having the code support those environments will help increase the
> overall user base, which will help ensure the core code supports many
> different OSes and is thoroughly tested.  So, I don't think we want to
> make LegacyBIOS coreboot specific.
> 
> I also don't think it would be a good idea to fork the code or copy
> large parts of it into multiple repositories.
> 
> So, I'm all for aligning coreboot and LegacyBIOS - it is after all the
> reason I started LegacyBIOS - but I think we need to come up with a
> boundary between the two.  In my opinion, coreboot should (optionally)
> call out to LegacyBIOS and the two should work towards the same goal.
> But I don't think they should be tightly integrated at the source code
> level.
> 
Hmm. Then how are we going to go about this? What do you suggest Kevin?
Could we set up coreboot to call LegacyBIOS at a certain point, execute it,
and then jump back to coreboot? Kind of like vm86/x86emu does for VGA? If
so at what point in the coreboot process do we want this to happen?

-- 
Thanks,
Joseph Smith
Set-Top-Linux
www.settoplinux.org




From cristi.magherusan at net.utcluj.ro  Wed Jun 18 15:25:22 2008
From: cristi.magherusan at net.utcluj.ro (Cristi Magherusan)
Date: Wed, 18 Jun 2008 16:25:22 +0300
Subject: [coreboot] GSoC AVATT project
In-Reply-To: <4858FC14.9020502@coresystems.de>
References: <1212664625.1327.5.camel@dragonbeastie.localdomain>
	<13426df10806121032v74fa8e88wa0c86d9b0bee79d1@mail.gmail.com>
	<4858FC14.9020502@coresystems.de>
Message-ID: <1213795522.14138.46.camel@localhost>

Hello,

On Wed, 2008-06-18 at 14:14 +0200, Stefan Reinauer wrote:
> ron minnich wrote:
> > are you ready to go? We are supposed to have started.
> any news?

These days I just finished my graduation stuff, so that now I can start
working full time on my GSoC project.

This is what I have in mind, for anyone who may be interested about this
topic and cannot read my GSoC application's discussions:

My project (AVATT) involves creating a small KVM-aware Linux payload,
integrating in the initrd the tools needed to create and run virtual
machines, straight on top of the BIOS.

The first part is about making everything as small as possible, aiming
it to fit in under 1 MB, but as smaller it gets, as better. 

The Linux kernel minimization part is quite trivial, there are those
tiny patches which can easily make it a few hundreds of kilobites, and
some careful drivers selection.

Still some work needs to be done on the minimization of the KVM tools.
Their dependencies on high-level userspace stuff like SDL must be
eliminated, and they must be statically linked with some small libc. I'm
thinking about uclibc, but any other ideas are welcome.

Then, I was thinking about making some small GNU screen-like tool that
would allow the user to quiclky create (wizard?), attach and switch
between virtual mahines. This would be great for console-only OS-es, but
i guess that more serious ones should be able to use real tty's, if
needed, just like X is doing for its display. 
Xen's tools, dtach and GNU screen may be considered as reference for
this kind of tool.
Ideally, the system should allow multiplexing any other devices, like
sound, USB, etc, but this must be further investigated.

I already have a testbed installation that uses qemu to emulate a amd64
box. Latest qemu supports virtualization itself, and I already succeeded
to run double emulation with it, as a proof of concept. 
The performance is awful, but it works. Anyway, the final part will need
a powerful amd64 machine that should be used for testing the real stuff.

If you have any suggestions and questions to ask, feel free to do it.

Best regards,
Cristi

-- 
Cristi Magherusan,
Universitatea Tehnica din Cluj - Napoca
Centrul de Comunicatii "Pusztai Kalman"
Tel. 0264/401247  http://cc.utcluj.ro
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20080618/2a8fb6eb/attachment.sig>

From peter at stuge.se  Wed Jun 18 15:35:15 2008
From: peter at stuge.se (Peter Stuge)
Date: Wed, 18 Jun 2008 15:35:15 +0200
Subject: [coreboot] flashrom: Add support for AMIC Technology A49LF040A
	and	do not probe W29EE011 anymore
In-Reply-To: <4858F7F1.6070708@gmx.net>
References: <484A73B7.4030609@gmx.net> <20080607130052.GA22883@localdomain>
	<484A8FD3.7040201@coresystems.de>
	<20080607134523.GA27554@localdomain>
	<484A9621.1020407@coresystems.de>
	<20080607142913.25791.qmail@stuge.se>
	<20080618020858.GB6461@localdomain>
	<20080618022515.GA9157@localdomain>
	<20080618042826.16077.qmail@stuge.se> <4858F7F1.6070708@gmx.net>
Message-ID: <20080618133515.3360.qmail@stuge.se>

On Wed, Jun 18, 2008 at 01:56:33PM +0200, Carl-Daniel Hailfinger wrote:
> I'd still like to know:
> - whether the W29EE011 non-standard probing could be replaced by
> JEDEC probing

I don't believe we will be able to test this anytime soon because the
chip is quite old.


> - whether we can write 0xFF to the chip after probing, triggering a
> reset for most chips.

We did try writing the product ID exit command, and unfortunately it
did not help.

Note that the chip still responds fine to LPC reads, data is
returned, but any write commands are ignored. The way I read the data
sheet this indicates that the chip is in an undocumented state.

Please do feel free to investigate this further, but personally I
doubt we'll ever find out what AMIC's state machine is up to. :\


//Peter



From svn at coreboot.org  Wed Jun 18 15:36:35 2008
From: svn at coreboot.org (svn at coreboot.org)
Date: Wed, 18 Jun 2008 15:36:35 +0200
Subject: [coreboot] r3368 - trunk/util/flashrom
Message-ID: <mailman.1631.1355071333.16123.coreboot@coreboot.org>

Author: stuge
Date: 2008-06-18 15:36:34 +0200 (Wed, 18 Jun 2008)
New Revision: 3368

Modified:
   trunk/util/flashrom/flash.h
   trunk/util/flashrom/flashchips.c
   trunk/util/flashrom/w29ee011.c
Log:
flashrom: Add support for AMIC Technology A49LF040A and do not probe W29EE011 anymore

Jens sent the first patch that added A49LF040A to flash.h and flashchips.c
using _jedec and _49lf040 functions.

An issue was found with probe_w29ee011() for the Winbond W29EE011, which
caused the A49LF040A to no longer respond to any commands.

Ward made a patch to disable probing by default for the W29EE011 following
some discussion. Using -c W29EE011 will make flashrom probe for the chip.

Peter did some more datasheet diving and found that the Pm49FL00x functions
suited this chip quite well because of the block locking registers in
A49LF040A, and finally tested PROBE READ ERASE WRITE to work on ALIX.3c3.

Ward confirmed that this works on alix.2c3 too.

Signed-off-by: Jens Kuehnel <coreboot at jens.kuehnel.org>
Signed-off-by: Ward Vandewege <ward at gnu.org>
Signed-off-by: Peter Stuge <peter at stuge.se>
Acked-by: Ward Vandewege <ward at gnu.org>


Modified: trunk/util/flashrom/flash.h
===================================================================
--- trunk/util/flashrom/flash.h	2008-06-18 02:08:40 UTC (rev 3367)
+++ trunk/util/flashrom/flash.h	2008-06-18 13:36:34 UTC (rev 3368)
@@ -120,6 +120,7 @@
 #define AMIC_ID_NOPREFIX	0x37	/* AMIC */
 #define AMIC_A25L40P		0x2013
 #define AMIC_A29040B		0x86
+#define AMIC_A49LF040A		0x9d
 
 #define ASD_ID			0x25	/* ASD, not listed in JEP106W */
 #define ASD_AE49F2008		0x52

Modified: trunk/util/flashrom/flashchips.c
===================================================================
--- trunk/util/flashrom/flashchips.c	2008-06-18 02:08:40 UTC (rev 3367)
+++ trunk/util/flashrom/flashchips.c	2008-06-18 13:36:34 UTC (rev 3368)
@@ -45,6 +45,7 @@
 	{"Atmel",	"AT49F002(N)T",		ATMEL_ID,	AT_49F002NT,		256,	256,		TEST_UNTESTED,	probe_jedec,		erase_chip_jedec,		write_jedec},
 	{"Atmel",       "AT25DF321",		ATMEL_ID,	AT_25DF321,		4096,	256,		TEST_OK_PREW,	probe_spi_rdid,		spi_chip_erase_c7,	spi_chip_write,	spi_chip_read},
 	{"Amic Technology","A25L40P",		AMIC_ID,	AMIC_A25L40P,		512,	256,		TEST_UNTESTED,	probe_spi_rdid,		spi_chip_erase_c7,	spi_chip_write, spi_chip_read},
+	{"AMIC Technology","A49LF040A",		AMIC_ID_NOPREFIX, AMIC_A49LF040A,	512,	64 * 1024,	TEST_OK_PREW,	probe_49fl00x,		erase_49fl00x,			write_49fl00x},
 	{"Amic Technology","A29040B",		AMIC_ID_NOPREFIX, AMIC_A29040B,		512,	64 * 1024,	TEST_OK_PR,	probe_29f040b,		erase_29f040b,			write_29f040b},
 	{"EMST",	"F49B002UA",		EMST_ID,	EMST_F49B002UA,		256,	4096,		TEST_UNTESTED,	probe_jedec,		erase_chip_jedec,		write_49f002},
 	{"EON",		"EN29F002(A)(N)B",	EON_ID,		EN_29F002B,		256,	256,		TEST_UNTESTED,	probe_jedec,		erase_chip_jedec,		write_jedec},

Modified: trunk/util/flashrom/w29ee011.c
===================================================================
--- trunk/util/flashrom/w29ee011.c	2008-06-18 02:08:40 UTC (rev 3367)
+++ trunk/util/flashrom/w29ee011.c	2008-06-18 13:36:34 UTC (rev 3368)
@@ -18,13 +18,24 @@
  * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA  02110-1301 USA
  */
 
+#include <string.h>
 #include "flash.h"
 
 int probe_w29ee011(struct flashchip *flash)
 {
 	volatile uint8_t *bios = flash->virtual_memory;
 	uint8_t id1, id2;
+	extern char *chip_to_probe;
 
+	if (!chip_to_probe || strcmp(chip_to_probe,"W29EE011")) {
+		printf_debug("\n===\n");
+		printf_debug("  Probing disabled for Winbond W29EE011 because the probing sequence puts the\n");
+		printf_debug("  AMIC A49LF040A in a funky state.\n");
+		printf_debug("  Use 'flashrom -c W29EE011' if you have a board with this chip.");
+		printf_debug("\n===\n");
+		return 0;
+	}
+
 	/* Issue JEDEC Product ID Entry command */
 	*(volatile uint8_t *)(bios + 0x5555) = 0xAA;
 	myusec_delay(10);




From peter at stuge.se  Wed Jun 18 15:37:06 2008
From: peter at stuge.se (Peter Stuge)
Date: Wed, 18 Jun 2008 15:37:06 +0200
Subject: [coreboot] flashrom: Add support for AMIC Technology
	A49LF040A	and do not probe W29EE011 anymore
In-Reply-To: <20080618124232.GA17315@localdomain>
References: <484A73B7.4030609@gmx.net> <20080607130052.GA22883@localdomain>
	<484A8FD3.7040201@coresystems.de>
	<20080607134523.GA27554@localdomain>
	<484A9621.1020407@coresystems.de>
	<20080607142913.25791.qmail@stuge.se>
	<20080618020858.GB6461@localdomain>
	<20080618022515.GA9157@localdomain>
	<20080618042826.16077.qmail@stuge.se>
	<20080618124232.GA17315@localdomain>
Message-ID: <20080618133706.5276.qmail@stuge.se>

On Wed, Jun 18, 2008 at 08:42:32AM -0400, Ward Vandewege wrote:
> Excellent - confirmed to work on alix.2c3.
> 
> Acked-by: Ward Vandewege <ward at gnu.org>

Thanks! r3368


//Peter



From c-d.hailfinger.devel.2006 at gmx.net  Wed Jun 18 16:15:07 2008
From: c-d.hailfinger.devel.2006 at gmx.net (Carl-Daniel Hailfinger)
Date: Wed, 18 Jun 2008 16:15:07 +0200
Subject: [coreboot] flashrom: Add support for AMIC Technology A49LF040A
 and	do not probe W29EE011 anymore
In-Reply-To: <20080618133515.3360.qmail@stuge.se>
References: <484A73B7.4030609@gmx.net>
	<20080607130052.GA22883@localdomain>	<484A8FD3.7040201@coresystems.de>	<20080607134523.GA27554@localdomain>	<484A9621.1020407@coresystems.de>	<20080607142913.25791.qmail@stuge.se>	<20080618020858.GB6461@localdomain>	<20080618022515.GA9157@localdomain>	<20080618042826.16077.qmail@stuge.se>
	<4858F7F1.6070708@gmx.net> <20080618133515.3360.qmail@stuge.se>
Message-ID: <4859186B.9040608@gmx.net>

On 18.06.2008 15:35, Peter Stuge wrote:
> On Wed, Jun 18, 2008 at 01:56:33PM +0200, Carl-Daniel Hailfinger wrote:
>   
>> I'd still like to know:
>> - whether the W29EE011 non-standard probing could be replaced by
>> JEDEC probing
>>     
>
> I don't believe we will be able to test this anytime soon because the
> chip is quite old.
>   

And it is listed as TEST_OK_PREW in flashchips.c, so we have some tester
somewhere (Uwe). By the way, since we don't probe for that chip anymore,
we have to change the chip to TEST_OK_REW|TEST_BAD_PROBE.

>> - whether we can write 0xFF to the chip after probing, triggering a
>> reset for most chips.
>>     
>
> We did try writing the product ID exit command, and unfortunately it
> did not help.
>   

Yes, that's why I suggested 0xFF.

> Note that the chip still responds fine to LPC reads, data is
> returned, but any write commands are ignored. The way I read the data
> sheet this indicates that the chip is in an undocumented state.
>
> Please do feel free to investigate this further, but personally I
> doubt we'll ever find out what AMIC's state machine is up to. :\
>   

Unfortunately I don't have the necessary hardware.

Regards,
Carl-Daniel



From Marc.Jones at amd.com  Wed Jun 18 17:28:07 2008
From: Marc.Jones at amd.com (Marc Jones)
Date: Wed, 18 Jun 2008 09:28:07 -0600
Subject: [coreboot] GSoC project(SCSI boot)__status report
In-Reply-To: <a7df9ffb104f47b43005b4b3d234abbc@imap.1and1.com>
References: <92cbc4c70806020926i41b757c0ga661a3549c840be5@mail.gmail.com>	<48513ADE.4050000@coresystems.de>	<92cbc4c70806151947h524d5885sb4a4abba0a61ba8a@mail.gmail.com>	<48567C4B.6050302@coresystems.de>	<20080616223806.GA5103@morn.localdomain>	<48584311.4060308@coresystems.de>	<5291a56333627468cb118eda911dc2af@imap.1and1.com>	<20080618025800.GA28799@morn.localdomain>
	<a7df9ffb104f47b43005b4b3d234abbc@imap.1and1.com>
Message-ID: <48592987.9050708@amd.com>

Joseph Smith wrote:

> Hmm. Then how are we going to go about this? What do you suggest Kevin?
> Could we set up coreboot to call LegacyBIOS at a certain point, execute it,
> and then jump back to coreboot? Kind of like vm86/x86emu does for VGA? If
> so at what point in the coreboot process do we want this to happen?
> 

I think that it will have to do that if you want to run the VGA ROM (and 
other ROMs) as part of the normal PCI initialization. The interrupt 
code will need to be in place at that time.

Marc



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




From joe at settoplinux.org  Wed Jun 18 17:57:48 2008
From: joe at settoplinux.org (Joseph Smith)
Date: Wed, 18 Jun 2008 11:57:48 -0400
Subject: [coreboot] coreboot table and i82801xx GPIO conflicts
Message-ID: <a8b858ca6c2c6a79f2bf62192c60ff1b@imap.1and1.com>


Hello,
I was just reading Stefan's API wiki page and something dawned on me. For
the i82801xx, the LPC GPIO Base address is set to 0x500. According to
Stefan's API wiki page the coreboot table is also at 0x500. The output from
the kernel indicates a conflict at 0x500? Could this be causing a
conflict???

Kernel:
PCI quirk: region 0400-047f claimed by ICH4 ACPI/GPIO/TCO
PCI quirk: region 0500-053f claimed by ICH4 GPIO

-- 
Thanks,
Joseph Smith
Set-Top-Linux
www.settoplinux.org




From r.marek at assembler.cz  Wed Jun 18 18:12:48 2008
From: r.marek at assembler.cz (Rudolf Marek)
Date: Wed, 18 Jun 2008 18:12:48 +0200
Subject: [coreboot] coreboot table and i82801xx GPIO conflicts
In-Reply-To: <a8b858ca6c2c6a79f2bf62192c60ff1b@imap.1and1.com>
References: <a8b858ca6c2c6a79f2bf62192c60ff1b@imap.1and1.com>
Message-ID: <48593400.4050800@assembler.cz>

Hi,

You are mixing up memory and IO ports memory. IO ports have their own address 
space accessible with inb/outb.

Rudolf



From joe at settoplinux.org  Wed Jun 18 18:33:32 2008
From: joe at settoplinux.org (Joseph Smith)
Date: Wed, 18 Jun 2008 12:33:32 -0400
Subject: [coreboot] coreboot table and i82801xx GPIO conflicts
In-Reply-To: <48593400.4050800@assembler.cz>
References: <a8b858ca6c2c6a79f2bf62192c60ff1b@imap.1and1.com>
	<48593400.4050800@assembler.cz>
Message-ID: <8288ea21dc6c1d2e93a9b95f7842fbf6@imap.1and1.com>




On Wed, 18 Jun 2008 18:12:48 +0200, Rudolf Marek <r.marek at assembler.cz>
wrote:
> Hi,
> 
> You are mixing up memory and IO ports memory. IO ports have their own
> address
> space accessible with inb/outb.
> 
Ah, duh, your right. But what could be causing this then?

Kernel:
PCI quirk: region 0400-047f claimed by ICH4 ACPI/GPIO/TCO
PCI quirk: region 0500-053f claimed by ICH4 GPIO

-- 
Thanks,
Joseph Smith
Set-Top-Linux
www.settoplinux.org




From rminnich at gmail.com  Wed Jun 18 18:40:31 2008
From: rminnich at gmail.com (ron minnich)
Date: Wed, 18 Jun 2008 09:40:31 -0700
Subject: [coreboot] The project to support UEFI payload is on the way
In-Reply-To: <10b008310806180205l306009f5g82afcc1196ccba78@mail.gmail.com>
References: <10b008310806180205l306009f5g82afcc1196ccba78@mail.gmail.com>
Message-ID: <13426df10806180940x27c313e2h2aadd84e00f4701c@mail.gmail.com>

Welcome, I think we all very happy to have you invovled in coreboot. I
think the project is quite exciting.

thanks

ron



From rminnich at gmail.com  Wed Jun 18 18:55:40 2008
From: rminnich at gmail.com (ron minnich)
Date: Wed, 18 Jun 2008 09:55:40 -0700
Subject: [coreboot] GSoC AVATT project
In-Reply-To: <1213795522.14138.46.camel@localhost>
References: <1212664625.1327.5.camel@dragonbeastie.localdomain>
	<13426df10806121032v74fa8e88wa0c86d9b0bee79d1@mail.gmail.com>
	<4858FC14.9020502@coresystems.de>
	<1213795522.14138.46.camel@localhost>
Message-ID: <13426df10806180955t141fe6d3x2198ced26605c8db@mail.gmail.com>

Let's keep it very simple to start. The main goal is to provide kvm
support from coreboot immediately, and allow users to start up VMs
from a shell prompt at boot. I think if you get this going, people
will add a lot of good work.

It's essential that we get this working on real hardware in the long
term, even more important than the nice GUI at first; what have we
chosen as a target?

Also, it is very important that at certain "breakpoints" on the way,
we make sure others can replicate your work. This type of testing
allows catches important problems. So a "recipe" at these breakpoint
stops that others can use to duplicate your setup would be a great
idea.

Thanks, this is a wonderful project and we are very happy to have you
working on it.

ron



From cristi.magherusan at net.utcluj.ro  Wed Jun 18 19:35:04 2008
From: cristi.magherusan at net.utcluj.ro (Cristi Magherusan)
Date: Wed, 18 Jun 2008 20:35:04 +0300
Subject: [coreboot] GSoC AVATT project
In-Reply-To: <13426df10806180955t141fe6d3x2198ced26605c8db@mail.gmail.com>
References: <1212664625.1327.5.camel@dragonbeastie.localdomain>
	<13426df10806121032v74fa8e88wa0c86d9b0bee79d1@mail.gmail.com>
	<4858FC14.9020502@coresystems.de> <1213795522.14138.46.camel@localhost>
	<13426df10806180955t141fe6d3x2198ced26605c8db@mail.gmail.com>
Message-ID: <1213810504.14138.73.camel@localhost>

On Wed, 2008-06-18 at 09:55 -0700, ron minnich wrote:
> Let's keep it very simple to start. The main goal is to provide kvm
> support from coreboot immediately, and allow users to start up VMs
> from a shell prompt at boot. I think if you get this going, people
> will add a lot of good work.
> 
Okay, That's how I've thought too, those ideas were on the long run, but
first I must solve the basic problem of running a KVM Linux payload.

> It's essential that we get this working on real hardware in the long
> term, even more important than the nice GUI at first; what have we
> chosen as a target?

?Anything AMD64-based that can run KVM-qemu over coreboot2 should do.
Please someone who owns this kind of boards with coreboot2 test the KVM
support and write in the wiki if it works, and I'll buy the one that is
best supported by coreboot.

Anyway, for this stage that I'm in qemu is the perfect tool. The real
box will only be needed a bit later. 

Qemu can easily run a dually emulated Linux kernel (vm inside vm), and
that's everything I need for now.? A simple kernel should work just
fine. My original test involved a guest VM with a full desktop runing
inside it, that's why it was that slow.

> Also, it is very important that at certain "breakpoints" on the way,
> we make sure others can replicate your work. This type of testing
> allows catches important problems. So a "recipe" at these breakpoint
> stops that others can use to duplicate your setup would be a great
> idea.
Okay, I'm going to make a wiki page where I'll document whatever I'm doing, 
so please someone make me a wiki account. I'd like to have the username 
"alien", if possible ;) (that's my IRC nickname too)

> Thanks, this is a wonderful project and we are very happy to have you
> working on it.
I also think the same, this project has a huge coolness factor and I'm
very glad that I was chosen to make it happen, but even more to get
involved in coreboot.

Cristi

-- 
Cristi Magherusan,
Universitatea Tehnica din Cluj - Napoca
Centrul de Comunicatii "Pusztai Kalman"
Tel. 0264/401247  http://cc.utcluj.ro




From davilla at 4pi.com  Wed Jun 18 19:53:59 2008
From: davilla at 4pi.com (Scott D. Davilla)
Date: Wed, 18 Jun 2008 13:53:59 -0400
Subject: [coreboot] AppleTV development
Message-ID: <p0623091bc47ef48c58be@[192.168.2.55]>

Hello all,

	I'm the author of atv-bootloader which enabled booting of 
standard un-patched Linux kernels on AppleTV hardware.

For background, the AppleTV uses a pure EFI bios which uses boot.efi 
to boot a OSX darwin kernel. The EFI firmware does cert checking 
which prevents the use of rEFIt as a bootloader so a fake darwin 
kernel (mach_kernel) was created to act as a secondary bootloader.

I've extended this secondary bootloader (my work is atv-bootloader) 
to remove the nasty kernel patches by translating the EFI memory map 
into an E820 memory map and relocating ACPI and SMBIOS table pointers 
to where Linux can find them. In addition, since video is presented 
as a linear console frame buffer, I setup Linux boot params for a 
vesafb.

A custom Linux kernel/initramfs is embedded into the secondary 
bootloader. This kernel/initramsfs then finds and loads the real 
kernel using kexec. The reason for the initial kernel is USB 2.0 
support. It was easier to do it this way than add all the required 
bits to support USB 2.0.

This all works pretty well and the nvidia binary driver see and 
correctly uses the nvidia 7300 chipset for 720p/1080i XvMC hardware 
decode. So for about $230, the AppleTV is about the least expensive 
hardware platform for handling 720p/1080i mpeg2 video content.

One of the current issues is that since the AppleTV is pure EFI, that 
means no PC-bios and vbios is not in the typical locations so video 
resolution changes can only be handled by the nvidia binary driver 
under X11.

I've recently found where vbios is located and have been able to copy 
it to 0xC0000 and run the standard "nv" X11 driver. When running "nv" 
I can even POST it using testbios.

The plan is to have the secondary bootloader relocate vbios and POST 
it in prep for Linux. This involves patching in software/hardware 
interrupt handlers (remember no PC-bios). Since I'm not a 
pc-bios/vbios expert this is where the fun starts.

The other thought is to go all the way and do a PC-bios layer 
complete with vbios handling.

ADLO seems interesting. The secondary bootloader is running in 
protected mode so it could load the ADLO payload and launch it.

Coreboot and it's associated projects is the closest development 
effort that involved pc-bios/vbios work so I'd like to get some 
comments or suggestions.

Thanks
Scott




From peter at stuge.se  Wed Jun 18 20:17:37 2008
From: peter at stuge.se (Peter Stuge)
Date: Wed, 18 Jun 2008 20:17:37 +0200
Subject: [coreboot] coreboot table and i82801xx GPIO conflicts
In-Reply-To: <8288ea21dc6c1d2e93a9b95f7842fbf6@imap.1and1.com>
References: <a8b858ca6c2c6a79f2bf62192c60ff1b@imap.1and1.com>
	<48593400.4050800@assembler.cz>
	<8288ea21dc6c1d2e93a9b95f7842fbf6@imap.1and1.com>
Message-ID: <20080618181737.25759.qmail@stuge.se>

On Wed, Jun 18, 2008 at 12:33:32PM -0400, Joseph Smith wrote:
> Ah, duh, your right. But what could be causing this then?
> 
> Kernel:
> PCI quirk: region 0400-047f claimed by ICH4 ACPI/GPIO/TCO
> PCI quirk: region 0500-053f claimed by ICH4 GPIO

Can't say without more kernel message context.


//Peter



From Ken.Fuchs at bench.com  Wed Jun 18 20:55:39 2008
From: Ken.Fuchs at bench.com (Ken.Fuchs at bench.com)
Date: Wed, 18 Jun 2008 13:55:39 -0500
Subject: [coreboot] The project to support UEFI payload is on the way
In-Reply-To: <AA28F077645B324881335614E4F7C4284A492A@win-ex01.bench.com>
Message-ID: <AA28F077645B324881335614E4F7C4284A492B@win-ex01.bench.com>

> My recent job is aim  to let coreboot support UEFI(Unified 
> Extensible Firmware Interface) payload.

Welcome to coreboot!

> TianoCore, UEFI implementation from Intel corp., will be adopted.

Would you consider using code from previous attempts at open source
UEFI such as

http://www.gnu.org/software/gnufi/

Sincerely,

Ken Fuchs



From Ken.Fuchs at bench.com  Wed Jun 18 22:45:01 2008
From: Ken.Fuchs at bench.com (Ken.Fuchs at bench.com)
Date: Wed, 18 Jun 2008 15:45:01 -0500
Subject: [coreboot] [RFC] coreboot and embedded controllers,
	for example OLPC and its OpenEC code
Message-ID: <AA28F077645B324881335614E4F7C4284A492D@win-ex01.bench.com>

Embedded controllers are being put on mainboards to
add functionality that the chipset and other support
chips can't easily provide.  The most common application
is keyboard handling on laptops.  Another example is
the embedded controllers added to servers for various
management features.  Embedded controllers seem to be
showing up now for many Intel PC board designs for
such things as power management and LPC to SPI
interfacing to support SPI NOR flash booting of the
BIOS/firmware.

I'm looking for an open source micro-controller project
that could be adapted to for use on PC embedded controllers
as described above.

What happened with the OLPC's OpenEC code?  Was that
ever completed?  Did the name change to something else?
Is it currently being developed?

Is there a viable alternative to OpenEC for embedded
controller code?  Will it work with coreboot or
appropriate payloads?

Any comments regarding coreboot and embedded controllers?

Sincerely,

Ken Fuchs



From jordan.crouse at amd.com  Thu Jun 19 00:13:03 2008
From: jordan.crouse at amd.com (Jordan Crouse)
Date: Wed, 18 Jun 2008 16:13:03 -0600
Subject: [coreboot] coreboot and embedded controllers,
	for example OLPC and its	OpenEC code
In-Reply-To: <AA28F077645B324881335614E4F7C4284A492D@win-ex01.bench.com>
References: <AA28F077645B324881335614E4F7C4284A492D@win-ex01.bench.com>
Message-ID: <20080618221302.GD5767@cosmic.amd.com>

On 18/06/08 15:45 -0500, Ken.Fuchs at bench.com wrote:
> What happened with the OLPC's OpenEC code?  Was that
> ever completed?  Did the name change to something else?
> Is it currently being developed?

I'm not sure what the current status is, you may want to
ask on devel at laptop.org.  As is often the case with
projects like these, there is no shortage of people
eager to begin reverse engineering closed source 
firmware but few of them stick around when they discover
the complexity of the task at hand.

In short, embedded controller code is dark magic.  You need
detailed schematics of your board, a clear indication of the
API that the BIOS requires, a JTAG debugger and a lot of time.
If you think that coreboot is too platform specfic, then you 
haven't seen anything yet.

Aas far as coreboot is concerned, we just don't have access to
information for any EC enabled platform that we might otherwise
support.  The only platform we would come even close to being
in the ballpark of supporting would be the OLPC, but even then
we are missing the schematics and the hardware bits needed to
flash the ROM.

What we need is a freely available EC chip that we can easily
hack on without complex or expensive hardware.  Then the task will
be to come up with a reasonable operating system to provide timers
and provide a general platform for development.  Once you get to
that point, then I think there is a real chance that an OpenEC 
solution could win.  Until then, its going to be black hole that
makes everybody cringe.

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




From r.marek at assembler.cz  Thu Jun 19 00:42:22 2008
From: r.marek at assembler.cz (Rudolf Marek)
Date: Thu, 19 Jun 2008 00:42:22 +0200
Subject: [coreboot] coreboot table and i82801xx GPIO conflicts
In-Reply-To: <20080618181737.25759.qmail@stuge.se>
References: <a8b858ca6c2c6a79f2bf62192c60ff1b@imap.1and1.com>	<48593400.4050800@assembler.cz>	<8288ea21dc6c1d2e93a9b95f7842fbf6@imap.1and1.com>
	<20080618181737.25759.qmail@stuge.se>
Message-ID: <48598F4E.8000608@assembler.cz>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Peter Stuge wrote:
> On Wed, Jun 18, 2008 at 12:33:32PM -0400, Joseph Smith wrote:
>> Ah, duh, your right. But what could be causing this then?
>>
>> Kernel:
>> PCI quirk: region 0400-047f claimed by ICH4 ACPI/GPIO/TCO
>> PCI quirk: region 0500-053f claimed by ICH4 GPIO
> 
> Can't say without more kernel message context.

Well that the PNP subsytem needs to be aware on non-std bars which claim this
IO. Imagine if PCI IO allocator in linux will for some non-assigned resource
assign same region as above. Well this wont happen because PCI io usually starts
at 1000 but in general it might be above 1000 too. I think this was the reason
for this quirk. - The ACPI pnp might claim this region too and in fact ACPI
should do that. Even more specially this quirk is here mostly when ACPI fails to
do so and the IO is above 1000 ;)

You may ignore this as "mostly harmless".  No really it is harmless for you.

Thanks,
Rudolf
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFIWY9O3J9wPJqZRNURAqiZAJ9FHan7sztUCbnH0HPBabm8DF86IgCfYpzf
qXGUZBwRg9gV/x+1raU0GgU=
=VpT6
-----END PGP SIGNATURE-----



From frieder.ferlemann at web.de  Thu Jun 19 01:22:47 2008
From: frieder.ferlemann at web.de (Frieder Ferlemann)
Date: Thu, 19 Jun 2008 01:22:47 +0200
Subject: [coreboot] coreboot and embedded controllers,
 for example OLPC and its	OpenEC code
In-Reply-To: <20080618221302.GD5767@cosmic.amd.com>
References: <AA28F077645B324881335614E4F7C4284A492D@win-ex01.bench.com>
	<20080618221302.GD5767@cosmic.amd.com>
Message-ID: <485998C7.9050108@web.de>

Hi,

Jordan Crouse schrieb:
 > On 18/06/08 15:45 -0500, Ken.Fuchs at bench.com wrote:
 >> What happened with the OLPC's OpenEC code?  Was that
 >> ever completed?  Did the name change to something else?
 >> Is it currently being developed?
 >
 > I'm not sure what the current status is, you may want to
 > ask on devel at laptop.org.  As is often the case with

there is currently no active development done on OpenEC I'm afraid.

I jumped in to provide a framework which would allow for a GPL'ed
firmware for the Embedded controler in the XO of the
One-Laptop-per-Child project.

But it turned out I was the only one contributing code.
And having no access to up to date schematics and only a very
terse data sheet of the controller (and still nobody joining)
I felt I could not complete within the time-scale that
would matter for the OLPC project.

So for now OpenEC is not being worked on. But I think the project
(while in its early stages) is now adequately positioned as a
starting point for an Embedded Controler firmware.

Current status is best seen at:
http://wiki.laptop.org/go/OpenEC

 > projects like these, there is no shortage of people
 > eager to begin reverse engineering closed source firmware but few of them stick around when they discover
 > the complexity of the task at hand.

I knew before, just speculated on others joining:)

 > In short, embedded controller code is dark magic.  You need
 > detailed schematics of your board, a clear indication of the
 > API that the BIOS requires, a JTAG debugger and a lot of time.
 > If you think that coreboot is too platform specfic, then you haven't seen anything yet.
 >
 > Aas far as coreboot is concerned, we just don't have access to
 > information for any EC enabled platform that we might otherwise
 > support.  The only platform we would come even close to being
 > in the ballpark of supporting would be the OLPC, but even then
 > we are missing the schematics and the hardware bits needed to
 > flash the ROM.

OLPC is slightly better, there is a publically available
(but outdated (and only one page out of many)) schematic:
   http://dev.laptop.org/attachment/ticket/477/SCHEMATIC1%20_%2012%20--%20EC%20KB3700.pdf

And flashing should not be a problem. At least for early XOs
this only requires rather straightforward hardware:
   http://wiki.laptop.org/go/Image:Serial_adapter.jpg

 > What we need is a freely available EC chip that we can easily
 > hack on without complex or expensive hardware.  Then the task will
 > be to come up with a reasonable operating system to provide timers
 > and provide a general platform for development.  Once you get to
 > that point, then I think there is a real chance that an OpenEC solution could win.  Until then, its going to be black hole that
 > makes everybody cringe.

Yep, let's see what happens. OpenEC is GPL'ed so it is there
to stay and it is waiting for a slightly better chance than
OLPC turned out to be.

And OpenEC was written with portability in mind. While it
specifically targets an ENE KB3700 (with its 8051 based core)
the source is also compileable with gcc.

Greetings,
Frieder




From jordan.crouse at amd.com  Thu Jun 19 01:30:05 2008
From: jordan.crouse at amd.com (Jordan Crouse)
Date: Wed, 18 Jun 2008 17:30:05 -0600
Subject: [coreboot] Fw: Re:  coreboot and embedded controllers,
	?for example	OLPC and its?OpenEC code
Message-ID: <20080618233005.GA6726@cosmic.amd.com>

This was sent to just me, but I think there is information here
that would be interesting to the group.

----- Forwarded message from Frieder Ferlemann <frieder.ferlemann at web.de> -----

From: Frieder Ferlemann <frieder.ferlemann at web.de>
Date: Thu, 19 Jun 2008 01:17:17 +0200
To: Jordan Crouse <jordan.crouse at amd.com>
Subject: Re: [coreboot] coreboot and embedded controllers, for example OLPC
	and its OpenEC code

Hi,

Jordan Crouse schrieb:
> On 18/06/08 15:45 -0500, Ken.Fuchs at bench.com wrote:
>> What happened with the OLPC's OpenEC code?  Was that
>> ever completed?  Did the name change to something else?
>> Is it currently being developed?
>
> I'm not sure what the current status is, you may want to
> ask on devel at laptop.org.  As is often the case with

there is currently no active development done on OpenEC I'm afraid.

I jumped in to provide a framework which would allow for a GPL'ed
firmware for the Embedded controler in the XO of the
One-Laptop-per-Child project.

But it turned out I was the only one contributing code.
And having no access to up to date schematics and only a very
terse data sheet of the controller (and still nobody joining)
I felt I could not complete within the time-scale that
would matter for the OLPC project.

So for now OpenEC is not being worked on. But I think the project
(while in its early stages) is now adequately positioned as a
starting point for an Embedded Controler firmware.

Current status is best seen at:
http://wiki.laptop.org/go/OpenEC

> projects like these, there is no shortage of people
> eager to begin reverse engineering closed source firmware but few of 
> them stick around when they discover
> the complexity of the task at hand.

I knew before, just speculated on others joining:)

> In short, embedded controller code is dark magic.  You need
> detailed schematics of your board, a clear indication of the
> API that the BIOS requires, a JTAG debugger and a lot of time.
> If you think that coreboot is too platform specfic, then you haven't 
> seen anything yet.
>
> Aas far as coreboot is concerned, we just don't have access to
> information for any EC enabled platform that we might otherwise
> support.  The only platform we would come even close to being
> in the ballpark of supporting would be the OLPC, but even then
> we are missing the schematics and the hardware bits needed to
> flash the ROM.

OLPC is slightly better, there is a publically available
(but outdated (and only one page out of many)) schematic:
  http://dev.laptop.org/attachment/ticket/477/SCHEMATIC1%20_%2012%20--%20EC%20KB3700.pdf

And flashing should not be a problem. At least for early XOs
this only requires rather straightforward hardware:
  http://wiki.laptop.org/go/Image:Serial_adapter.jpg

> What we need is a freely available EC chip that we can easily
> hack on without complex or expensive hardware.  Then the task will
> be to come up with a reasonable operating system to provide timers
> and provide a general platform for development.  Once you get to
> that point, then I think there is a real chance that an OpenEC solution 
> could win.  Until then, its going to be black hole that
> makes everybody cringe.

Yep, let's see what happens. OpenEC is GPL'ed so it is there
to stay and it is waiting for a slightly better chance than
OLPC turned out to be.

And OpenEC was written with portability in mind. While it
specifically targets an ENE KB3700 (with its 8051 based core)
the source is also compileable with gcc.

Greetings,
Frieder


----- End forwarded message -----

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




From bari at onelabs.com  Thu Jun 19 02:21:28 2008
From: bari at onelabs.com (bari)
Date: Wed, 18 Jun 2008 19:21:28 -0500
Subject: [coreboot] Patch to extend ROM decode range to 1MB for vt8237r
Message-ID: <4859A688.7070606@onelabs.com>

This patch extends the VIA vt8237r southbridge decode range for the ROM 
to 1MB.

Rudolf had use this for a board specific patch in the past. We also already do this for all vt8237r in flashrom.

Signed-off-by: Bari Ari <bari at onelabs.com>


-Bari
-------------- next part --------------
A non-text attachment was scrubbed...
Name: vt8237r.patch
Type: text/x-patch
Size: 557 bytes
Desc: not available
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20080618/fd422409/attachment.patch>

From bari at onelabs.com  Thu Jun 19 02:55:10 2008
From: bari at onelabs.com (bari)
Date: Wed, 18 Jun 2008 19:55:10 -0500
Subject: [coreboot] Buildrom breaks with 2.6.25.4 or 2.6.24.7 kernel source
Message-ID: <4859AE6E.7090000@onelabs.com>

I tried building LAB for the Tyan s-2891 using buildrom and 2.6.25.4 
kernel source.

debug output:

/home/ly/buildrom/buildrom-devel/work/busybox/busybox-1.1.3/libbb/procps.c:15:22: 
error: asm/page.h: No such file or directory
make[2]: *** 
[/home/ly/buildrom/buildrom-devel/work/busybox/busybox-1.1.3/libbb/procps.o] 
Error 1
make[1]: *** [all] Error 2


The kernel was built just fine. It just breaks during the build of busybox.

Also breaks with 2.6.24.7 kernel, 2.6.22.2 or 2.6.22.5 kernel is fine.

Any ideas why?

-Bari





From read.liu at gmail.com  Thu Jun 19 03:06:51 2008
From: read.liu at gmail.com (Joey Liu)
Date: Thu, 19 Jun 2008 09:06:51 +0800
Subject: [coreboot] The project to support UEFI payload is on the way
In-Reply-To: <AA28F077645B324881335614E4F7C4284A492B@win-ex01.bench.com>
References: <AA28F077645B324881335614E4F7C4284A492A@win-ex01.bench.com>
	<AA28F077645B324881335614E4F7C4284A492B@win-ex01.bench.com>
Message-ID: <10b008310806181806u467d1c9kd00186ce3e8a5c56@mail.gmail.com>

hi, Ken

Selecting TianoCore for the project is because I have some experience in it.
And I think GNUFI will be considered later. ^_^

2008/6/19 <Ken.Fuchs at bench.com>:

> > My recent job is aim  to let coreboot support UEFI(Unified
> > Extensible Firmware Interface) payload.
>
> Welcome to coreboot!
>
> > TianoCore, UEFI implementation from Intel corp., will be adopted.
>
> Would you consider using code from previous attempts at open source
> UEFI such as
>
> http://www.gnu.org/software/gnufi/
>
> Sincerely,
>
> Ken Fuchs
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20080619/a4f8eae3/attachment.html>

From zrfail at gmail.com  Thu Jun 19 03:38:03 2008
From: zrfail at gmail.com (Zhang Rui)
Date: Thu, 19 Jun 2008 09:38:03 +0800
Subject: [coreboot] GSoC project(SCSI boot)__status report
In-Reply-To: <48592987.9050708@amd.com>
References: <92cbc4c70806020926i41b757c0ga661a3549c840be5@mail.gmail.com>
	<48513ADE.4050000@coresystems.de>
	<92cbc4c70806151947h524d5885sb4a4abba0a61ba8a@mail.gmail.com>
	<48567C4B.6050302@coresystems.de>
	<20080616223806.GA5103@morn.localdomain>
	<48584311.4060308@coresystems.de>
	<5291a56333627468cb118eda911dc2af@imap.1and1.com>
	<20080618025800.GA28799@morn.localdomain>
	<a7df9ffb104f47b43005b4b3d234abbc@imap.1and1.com>
	<48592987.9050708@amd.com>
Message-ID: <92cbc4c70806181838x66d6e45dl6f287441838de26b@mail.gmail.com>

What I am going to do is:
1. copy LegacyBIOS codes to 0xf0000,
2. call a modifid post() in LegacyBIOS to initialize the memory and
return to coreboot.
3. initialize the SCSI controller and install a handler.

Is that OK?

2008/6/18 Marc Jones <Marc.Jones at amd.com>:
> Joseph Smith wrote:
>
>> Hmm. Then how are we going to go about this? What do you suggest Kevin?
>> Could we set up coreboot to call LegacyBIOS at a certain point, execute it,
>> and then jump back to coreboot? Kind of like vm86/x86emu does for VGA? If
>> so at what point in the coreboot process do we want this to happen?
>>
>
> I think that it will have to do that if you want to run the VGA ROM (and
> other ROMs) as part of the normal PCI initialization. The interrupt
> code will need to be in place at that time.
>
> Marc
>
>
>
> --
> Marc Jones
> Senior Firmware Engineer
> (970) 226-9684 Office
> mailto:Marc.Jones at amd.com
> http://www.amd.com/embeddedprocessors
>
>
> --
> coreboot mailing list
> coreboot at coreboot.org
> http://www.coreboot.org/mailman/listinfo/coreboot
>



From peter at stuge.se  Thu Jun 19 04:14:52 2008
From: peter at stuge.se (Peter Stuge)
Date: Thu, 19 Jun 2008 04:14:52 +0200
Subject: [coreboot] coreboot and embedded controllers,
	for example OLPC and its	OpenEC code
In-Reply-To: <485998C7.9050108@web.de>
References: <AA28F077645B324881335614E4F7C4284A492D@win-ex01.bench.com>
	<20080618221302.GD5767@cosmic.amd.com> <485998C7.9050108@web.de>
Message-ID: <20080619021452.30958.qmail@stuge.se>

Just a little tidbit..

On Thu, Jun 19, 2008 at 01:22:47AM +0200, Frieder Ferlemann wrote:
> Yep, let's see what happens. OpenEC is GPL'ed so it is there
> to stay and it is waiting for a slightly better chance than
> OLPC turned out to be.

Me and Uwe ran into a desktop board with this SMSC superio..


> And OpenEC was written with portability in mind. While it
> specifically targets an ENE KB3700 (with its 8051 based core)
> the source is also compileable with gcc.

The superio included an 8051. The 8051 did not have it's own program
memory, it's program was stored in the BIOS flash.

When the board powered up, only the 8051 was running. It needed
software to do some stuff, and only then could it negotiate release
of the main CPU reset.

We found some PDF files and it did seem within our reach to get the
8051 to at least power up the CPU, but it was the heart of the
superio, so I believe most superio functions would be unavailable
until there was more 8051 code.

Not so much fun.


//Peter



From joe at settoplinux.org  Thu Jun 19 04:22:15 2008
From: joe at settoplinux.org (Joseph Smith)
Date: Wed, 18 Jun 2008 22:22:15 -0400
Subject: [coreboot] GSoC project(SCSI boot)__status report
In-Reply-To: <92cbc4c70806181838x66d6e45dl6f287441838de26b@mail.gmail.com>
References: <92cbc4c70806020926i41b757c0ga661a3549c840be5@mail.gmail.com>
	<48513ADE.4050000@coresystems.de>
	<92cbc4c70806151947h524d5885sb4a4abba0a61ba8a@mail.gmail.com>
	<48567C4B.6050302@coresystems.de>
	<20080616223806.GA5103@morn.localdomain>
	<48584311.4060308@coresystems.de>
	<5291a56333627468cb118eda911dc2af@imap.1and1.com>
	<20080618025800.GA28799@morn.localdomain>
	<a7df9ffb104f47b43005b4b3d234abbc@imap.1and1.com>
	<48592987.9050708@amd.com>
	<92cbc4c70806181838x66d6e45dl6f287441838de26b@mail.gmail.com>
Message-ID: <6F651D11120C4323B9E0DC329F4D0734@smitty2m>



> -----Original Message-----
> From: Zhang Rui [mailto:zrfail at gmail.com]
> Sent: Wednesday, June 18, 2008 9:38 PM
> To: Marc Jones
> Cc: Joseph Smith; Stefan Reinauer; Kevin O'Connor; Coreboot
> Subject: Re: [coreboot] GSoC project(SCSI boot)__status report
> 
> What I am going to do is:
> 1. copy LegacyBIOS codes to 0xf0000,
> 2. call a modifid post() in LegacyBIOS to initialize the memory and
> return to coreboot.
> 3. initialize the SCSI controller and install a handler.
> 
> Is that OK?

Well,
Sorry to say, to me that does not make very much sense.
First of all, at the point where you "1. copy LegacyBIOS codes to 0xf0000"
the memory should already be initialized by coreboot correct?? This is one
of the first things coreboot does is initialize the memory. So, the second
part of number 2. ("initialize the memory") may not be necessary if the
memory is already initialized by coreboot.

Here is what I would suggest, I don't know if it is the right direction, but
I think it logically makes sense:

1. Start the coreboot initialization process as normal
2. When coreboot gets to the memory allocation part; have it reserve a
certain amount(Size of LegacyBIOS??) at 0xf0000 (if option LegacyBIOS is
selected).
3. (if option LegacyBIOS is selected) copy LegacyBIOS codes to 0xf0000.
4. (if option LegacyBIOS is selected) Jump to LegacyBIOS and setup any
tables, INT's, etc.
5. Return to coreboot and continue as normal.
6. in the payload part initialize the SCSI controller and install a handler
and call LegacyBIOS INT19.

Does this make any sense, or am I way off course???


Thanks,
Joseph Smith
Set-Top-Linux
www.settoplinux.org




From kevin at koconnor.net  Thu Jun 19 04:30:45 2008
From: kevin at koconnor.net (Kevin O'Connor)
Date: Wed, 18 Jun 2008 22:30:45 -0400
Subject: [coreboot] coreboot BIOSisms
In-Reply-To: <20080611080337.28002.qmail@stuge.se>
References: <20080609033740.GA1161@morn.localdomain>
	<20080609170346.357.qmail@stuge.se>
	<20080610021835.GA5498@morn.localdomain>
	<8a5e5d330d5bb633f537e6dd718f8ef7@imap.1and1.com>
	<20080610230226.GA10608@morn.localdomain>
	<20080611021749.13762.qmail@stuge.se>
	<20080611042232.GA11420@morn.localdomain>
	<20080611080337.28002.qmail@stuge.se>
Message-ID: <20080619023045.GA2109@morn.localdomain>

Hi Peter,

On Wed, Jun 11, 2008 at 10:03:37AM +0200, Peter Stuge wrote:
> On Wed, Jun 11, 2008 at 12:22:32AM -0400, Kevin O'Connor wrote:
> > So, if there is an intermediate format with compelling features -
> > then I'm all for it.
> 
> Would you be interested in helping with development of that format,
> or do you only wish to use it when it becomes available?

I'm not interested in writing code for an intermediate format at this
time.  I'm full of opinions, but I'm not sure that will move us
forward.

In general, I think the simpler the intermediate format the better.
For example, I think an area of memory with a simple list of ascii
"key=value\n" pairs would work fine.

-Kevin



From peter at stuge.se  Thu Jun 19 04:32:17 2008
From: peter at stuge.se (Peter Stuge)
Date: Thu, 19 Jun 2008 04:32:17 +0200
Subject: [coreboot] Patch to extend ROM decode range to 1MB for vt8237r
In-Reply-To: <4859A688.7070606@onelabs.com>
References: <4859A688.7070606@onelabs.com>
Message-ID: <20080619023217.11593.qmail@stuge.se>

On Wed, Jun 18, 2008 at 07:21:28PM -0500, bari wrote:
> This patch extends the VIA vt8237r southbridge decode range for the ROM 
> to 1MB.
> 
> Rudolf had use this for a board specific patch in the past. We also already 
> do this for all vt8237r in flashrom.
> 
> Signed-off-by: Bari Ari <bari at onelabs.com>

If the TODO is actually still a TODO, please keep the comment.

Acked-by: Peter Stuge <peter at stuge.se>


> Index: southbridge/via/vt8237r/vt8237r.c
> ===================================================================
> --- southbridge/via/vt8237r/vt8237r.c	(revision 3368)
> +++ southbridge/via/vt8237r/vt8237r.c	(working copy)
> @@ -78,7 +78,8 @@
>  	pci_write_config8(dev, 0x50, sb->fn_ctrl_lo);
>  	pci_write_config8(dev, 0x51, sb->fn_ctrl_hi);
>  
> -	/* TODO: If SATA is disabled, move IDE to fn0 to conform PCI specs. */
> +	/* Extend ROM decode to 1MB FFC00000 - FFFFFFFF */
> +	pci_write_config8(dev, 0x41, 0x7f);
>  }
>  
>  struct chip_operations southbridge_via_vt8237r_ops = {



From joe at settoplinux.org  Thu Jun 19 04:36:18 2008
From: joe at settoplinux.org (Joseph Smith)
Date: Wed, 18 Jun 2008 22:36:18 -0400
Subject: [coreboot] coreboot table and i82801xx GPIO conflicts
In-Reply-To: <48598F4E.8000608@assembler.cz>
References: <a8b858ca6c2c6a79f2bf62192c60ff1b@imap.1and1.com>	<48593400.4050800@assembler.cz>	<8288ea21dc6c1d2e93a9b95f7842fbf6@imap.1and1.com><20080618181737.25759.qmail@stuge.se>
	<48598F4E.8000608@assembler.cz>
Message-ID: <BDEB04C304AA4ECAA745C4580DACC68A@smitty2m>




> -----Original Message-----
> From: coreboot-bounces at coreboot.org [mailto:coreboot-bounces at coreboot.org]
> On Behalf Of Rudolf Marek
> Sent: Wednesday, June 18, 2008 6:42 PM
> To: Coreboot
> Subject: Re: [coreboot] coreboot table and i82801xx GPIO conflicts
> 
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Peter Stuge wrote:
> > On Wed, Jun 18, 2008 at 12:33:32PM -0400, Joseph Smith wrote:
> >> Ah, duh, your right. But what could be causing this then?
> >>
> >> Kernel:
> >> PCI quirk: region 0400-047f claimed by ICH4 ACPI/GPIO/TCO
> >> PCI quirk: region 0500-053f claimed by ICH4 GPIO
> >
> > Can't say without more kernel message context.
> 
> Well that the PNP subsytem needs to be aware on non-std bars which claim
> this
> IO. Imagine if PCI IO allocator in linux will for some non-assigned
> resource
> assign same region as above. Well this wont happen because PCI io usually
> starts
> at 1000 but in general it might be above 1000 too. I think this was the
> reason
> for this quirk. - The ACPI pnp might claim this region too and in fact
> ACPI
> should do that. Even more specially this quirk is here mostly when ACPI
> fails to
> do so and the IO is above 1000 ;)
> 
> You may ignore this as "mostly harmless".  No really it is harmless for
> you.
> 
Thanks Rudolf that makes sense. That would explain it because I also get
this message from coreboot " Disabling local apic...done." (Although I have
no idea why coreboot disables it?). And this from the kernel:

Local APIC disabled by BIOS -- you can enable it with "lapic"

You can check out the boot log here to see what I mean:
http://www.coreboot.org/pipermail/coreboot/2008-March/032221.html

Thanks,
Joseph Smith
Set-Top-Linux
www.settoplinux.org




From bari at onelabs.com  Thu Jun 19 06:14:32 2008
From: bari at onelabs.com (bari)
Date: Wed, 18 Jun 2008 23:14:32 -0500
Subject: [coreboot] Patch to extend ROM decode range to 1MB for vt8237r
In-Reply-To: <20080619023217.11593.qmail@stuge.se>
References: <4859A688.7070606@onelabs.com>
	<20080619023217.11593.qmail@stuge.se>
Message-ID: <4859DD28.9080809@onelabs.com>

Peter Stuge wrote:
> On Wed, Jun 18, 2008 at 07:21:28PM -0500, bari wrote:
>   
>> This patch extends the VIA vt8237r southbridge decode range for the ROM 
>> to 1MB.
>>
>> Rudolf had use this for a board specific patch in the past. We also already 
>> do this for all vt8237r in flashrom.
>>
>> Signed-off-by: Bari Ari <bari at onelabs.com>
>>     
>
> If the TODO is actually still a TODO, please keep the comment.
>
> Acked-by: Peter Stuge <peter at stuge.se>
>
>
>   
>> Index: southbridge/via/vt8237r/vt8237r.c
>> ===================================================================
>> --- southbridge/via/vt8237r/vt8237r.c	(revision 3368)
>> +++ southbridge/via/vt8237r/vt8237r.c	(working copy)
>> @@ -78,7 +78,8 @@
>>  	pci_write_config8(dev, 0x50, sb->fn_ctrl_lo);
>>  	pci_write_config8(dev, 0x51, sb->fn_ctrl_hi);
>>  
>> -	/* TODO: If SATA is disabled, move IDE to fn0 to conform PCI specs. */
>> +	/* Extend ROM decode to 1MB FFC00000 - FFFFFFFF */
>> +	pci_write_config8(dev, 0x41, 0x7f);
>>  }
>>  
>>  struct chip_operations southbridge_via_vt8237r_ops = {
>>     
>
>   
It doesn't matter to me, the SATA comment was there since the thought 
was SATA was broken on vt8237r. If someone wishes to disable the SATA 
then I'd imagine they would handle it in a board specific manner.

Here's another patch with the comment left in.

This patch extends the VIA vt8237r southbridge decode range for the ROM 
to 1MB.

Rudolf had use this for a board specific patch in the past. We also already 
do this for the vt8237r in flashrom.

Signed-off-by: Bari Ari <bari at onelabs.com>




-------------- next part --------------
A non-text attachment was scrubbed...
Name: vt8237r-s.patch
Type: text/x-patch
Size: 556 bytes
Desc: not available
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20080618/3ddad855/attachment.patch>

From frieder.ferlemann at web.de  Thu Jun 19 08:40:32 2008
From: frieder.ferlemann at web.de (Frieder Ferlemann)
Date: Thu, 19 Jun 2008 08:40:32 +0200
Subject: [coreboot] coreboot and embedded controllers,
 for example OLPC and its	OpenEC code
In-Reply-To: <20080619021452.30958.qmail@stuge.se>
References: <AA28F077645B324881335614E4F7C4284A492D@win-ex01.bench.com>	<20080618221302.GD5767@cosmic.amd.com>
	<485998C7.9050108@web.de> <20080619021452.30958.qmail@stuge.se>
Message-ID: <4859FF60.6030803@web.de>

Hi Peter,

Peter Stuge schrieb:
> Just a little tidbit..
> 
> On Thu, Jun 19, 2008 at 01:22:47AM +0200, Frieder Ferlemann wrote:
>> Yep, let's see what happens. OpenEC is GPL'ed so it is there
>> to stay and it is waiting for a slightly better chance than
>> OLPC turned out to be.
> 
> Me and Uwe ran into a desktop board with this SMSC superio..
> 
> 
>> And OpenEC was written with portability in mind. While it
>> specifically targets an ENE KB3700 (with its 8051 based core)
>> the source is also compileable with gcc.
> 
> The superio included an 8051. The 8051 did not have it's own program
> memory, it's program was stored in the BIOS flash.
> 
> When the board powered up, only the 8051 was running. It needed
> software to do some stuff, and only then could it negotiate release
> of the main CPU reset.

This seems close to the EC on the XO.

> We found some PDF files and it did seem within our reach to get the
> 8051 to at least power up the CPU, but it was the heart of the
> superio, so I believe most superio functions would be unavailable
> until there was more 8051 code.

On the XO both the host CPU (Geode) and the EC could access special
function registers (those which were mapped into xdata space on the EC).
(Access to these registers was later switched off for the host CPU due
to security implications)

Out of curiosity, which SMSC superio was it?

Greetings,
Frieder



From zrfail at gmail.com  Thu Jun 19 10:00:04 2008
From: zrfail at gmail.com (Zhang Rui)
Date: Thu, 19 Jun 2008 16:00:04 +0800
Subject: [coreboot] Black window when running qemu with
	coreboot+LegacyBIOS
In-Reply-To: <20080619014748.GA1344@morn.localdomain>
References: <92cbc4c70806181829x67547e58pf4df99b2a72d241b@mail.gmail.com>
	<20080619014748.GA1344@morn.localdomain>
Message-ID: <92cbc4c70806190100u47e07626mf433ebcb54197b8@mail.gmail.com>

Hi Kevin,


2008/6/19 Kevin O'Connor <kevin at koconnor.net>:
> Please 'cc the coreboot mailing list too.
OK.


> On Thu, Jun 19, 2008 at 09:29:29AM +0800, Zhang Rui wrote:
>> Hello,
>>
>> I build the latest code of LegacyBIOS and get bios.bin.elf.  Then use
>> it as payload of coreboot. Then I put bios.bin produced by coreboot
>> and Vgabios-cirrus in one directory.
>> And then run "qemu -L <directory of Vgabios-cirrus and bios.bin> -hda
>> /dev/zero -serial stdio".   But I get a black window of qemu with no
>> output and cannot close. There are lots of messages in the command
>> console.
>>
>> Is that OK or is there any problem?
>
> You've done well to get this far.  You have an issue with coreboot:
>
>> the message in the console:
>>
>> coreboot-3.0.674 Thu Jun 19 08:39:43 CST 2008 starting...
> [...]
>> LAR: Attempting to open 'normal/payload/segment0'.
>> LAR: Start 0xfffc0000 len 0x40000
>> LAR: seen member normal/option_table
>> LAR: seen member normal/initram/segment0
>> LAR: seen member normal/stage2/segment0
>> LAR: seen member normal/stage2/segment1
>> LAR: seen member normal/stage2/segment2
>> LAR: seen member normal/payload/segment0
>> LAR: CHECK normal/payload/segment0 @ 0xfffc43c0
>> start 0xfffc4410 len 20789 reallen 65652 compression 1 entry
>> 0x000f66e0 loadaddress 0x08048000
>> LAR: Compression algorithm #1 (lzma) used
>> Decoding error = 1
>
> The above is not right.
>
> To compare, I get:
>
> LAR: Attempting to open 'normal/payload/segment0'.
> LAR: Start 0xfffc0000 len 0x40000
> LAR: seen member normal/option_table
> LAR: seen member normal/initram/segment0
> LAR: seen member normal/stage2/segment0
> LAR: seen member normal/stage2/segment1
> LAR: seen member normal/stage2/segment2
> LAR: seen member normal/payload/segment0
> LAR: CHECK normal/payload/segment0 @ 0xfffc3e30
> start 0xfffc3e80 len 21037 reallen 65536 compression 1 entry 0x000f66a0 loadaddress 0x000f0000
> LAR: Compression algorithm #1 (lzma) used
>
> You have an incorrect reallen and loadaddress.  You can use "objdump
> -x bios.bin.elf" to confirm that the elf file is correct.  I get:
>
> $ objdump -x out/bios.bin.elf
>
> out/bios.bin.elf:     file format elf32-i386
> out/bios.bin.elf
> architecture: i386, flags 0x00000112:
> EXEC_P, HAS_SYMS, D_PAGED
> start address 0x000f66a0
>
> Program Header:
>    LOAD off    0x00001000 vaddr 0x000f0000 paddr 0x000f0000 align 2**12
>         filesz 0x00010000 memsz 0x00010000 flags rw-
>
> Sections:
> Idx Name          Size      VMA       LMA       File off  Algn
>  0 .data         00010000  000f0000  000f0000  00001000  2**0
>                  CONTENTS, ALLOC, LOAD, DATA
> SYMBOL TABLE:
> 000f0000 l    d  .data  00000000 .data
> 00010000 g       *ABS*  00000000 _binary_out_bios_bin_size
> 00100000 g       *ABS*  00000000 __bss_start
> 00100000 g       .data  00000000 _binary_out_bios_bin_end
> 00100000 g       *ABS*  00000000 _edata
> 00100000 g       *ABS*  00000000 _end
> 000f0000 g       .data  00000000 _binary_out_bios_bin_start
>
>
> -Kevin
>


You are right.  There is something wrong with my elf file. The address
and size is not correct.
Here is the message about my bios.bin.elf:

legacybios/out> objdump -x bios.bin.elf
bios.bin.elf:     file format elf32-i386
bios.bin.elf
architecture: i386, flags 0x00000112:
EXEC_P, HAS_SYMS, D_PAGED
start address 0x000f66e0

Program Header:
    LOAD off    0x00000000 vaddr 0x08048000 paddr 0x08048000 align 2**12
         filesz 0x00010074 memsz 0x00010074 flags rw-

Sections:
Idx Name          Size      VMA       LMA       File off  Algn
  0 .data         00010000  08048074  08048074  00000074  2**0
                  CONTENTS, ALLOC, LOAD, DATA
SYMBOL TABLE:
08048074 l    d  .data  00000000 .data
00000000 l    d  *ABS*  00000000 .shstrtab
00000000 l    d  *ABS*  00000000 .symtab
00000000 l    d  *ABS*  00000000 .strtab
00010000 g       *ABS*  00000000 _binary_out_bios_bin_size
08058074 g       *ABS*  00000000 __bss_start
08058074 g       .data  00000000 _binary_out_bios_bin_end
08058074 g       *ABS*  00000000 _edata
08058074 g       *ABS*  00000000 _end
08048074 g       .data  00000000 _binary_out_bios_bin_start


What could be wrong in my building process? I build LegacyBIOS again
with the config.h setting in http://www.coreboot.org/LegacyBIOS and
the result is the same.

Here is the building message:
[...]legacybios> make AVOIDCOMBINE=1
mkdir out
  Compiling whole program out/blob.16.s
In file included from out/blob.16.s.tmp.c:7:
out/../src/kbd.c: In function 'process_key':
out/../src/kbd.c:658: warning: dereferencing type-punned pointer will
break strict-aliasing rules
out/../src/kbd.c:659: warning: dereferencing type-punned pointer will
break strict-aliasing rules
out/../src/kbd.c:661: warning: dereferencing type-punned pointer will
break strict-aliasing rules
out/../src/kbd.c:662: warning: dereferencing type-punned pointer will
break strict-aliasing rules
out/../src/kbd.c:667: warning: dereferencing type-punned pointer will
break strict-aliasing rules
out/../src/kbd.c:673: warning: dereferencing type-punned pointer will
break strict-aliasing rules
out/../src/kbd.c:674: warning: dereferencing type-punned pointer will
break strict-aliasing rules
out/../src/kbd.c:676: warning: dereferencing type-punned pointer will
break strict-aliasing rules
out/../src/kbd.c:677: warning: dereferencing type-punned pointer will
break strict-aliasing rules
out/../src/kbd.c:682: warning: dereferencing type-punned pointer will
break strict-aliasing rules
out/../src/kbd.c:683: warning: dereferencing type-punned pointer will
break strict-aliasing rules
out/../src/kbd.c:685: warning: dereferencing type-punned pointer will
break strict-aliasing rules
out/../src/kbd.c:686: warning: dereferencing type-punned pointer will
break strict-aliasing rules
In file included from out/blob.16.s.tmp.c:12:
out/../src/disk.c: In function 'extended_access':
out/../src/disk.c:135: warning: dereferencing type-punned pointer will
break strict-aliasing rules
out/../src/disk.c:136: warning: dereferencing type-punned pointer will
break strict-aliasing rules
out/../src/disk.c:138: warning: dereferencing type-punned pointer will
break strict-aliasing rules
out/../src/disk.c:150: warning: dereferencing type-punned pointer will
break strict-aliasing rules
out/../src/disk.c: In function 'disk_1348':
out/../src/disk.c:358: warning: dereferencing type-punned pointer will
break strict-aliasing rules
out/../src/disk.c:375: warning: dereferencing type-punned pointer will
break strict-aliasing rules
out/../src/disk.c:378: warning: dereferencing type-punned pointer will
break strict-aliasing rules
out/../src/disk.c:381: warning: dereferencing type-punned pointer will
break strict-aliasing rules
out/../src/disk.c:390: warning: dereferencing type-punned pointer will
break strict-aliasing rules
out/../src/disk.c:396: warning: dereferencing type-punned pointer will
break strict-aliasing rules
out/../src/disk.c:405: warning: dereferencing type-punned pointer will
break strict-aliasing rules
out/../src/disk.c:407: warning: dereferencing type-punned pointer will
break strict-aliasing rules
out/../src/disk.c:408: warning: dereferencing type-punned pointer will
break strict-aliasing rules
out/../src/disk.c:462: warning: dereferencing type-punned pointer will
break strict-aliasing rules
out/../src/disk.c:463: warning: dereferencing type-punned pointer will
break strict-aliasing rules
out/../src/disk.c:466: warning: dereferencing type-punned pointer will
break strict-aliasing rules
In file included from out/blob.16.s.tmp.c:13:
out/../src/cdrom.c: At top level:
out/../src/disk.h:111: warning: 'cdrom_read_emu' declared inline after
being called
out/../src/disk.h:111: warning: previous declaration of
'cdrom_read_emu' was here
out/../src/cdrom.c: In function 'cdemu_134b':
out/../src/cdrom.c:282: warning: dereferencing type-punned pointer
will break strict-aliasing rules
out/../src/cdrom.c:283: warning: dereferencing type-punned pointer
will break strict-aliasing rules
out/../src/cdrom.c:284: warning: dereferencing type-punned pointer
will break strict-aliasing rules
out/../src/cdrom.c:285: warning: dereferencing type-punned pointer
will break strict-aliasing rules
  Generating assembler for src/font.c
  Moving data sections to text in out/font.16.s
  Generating assembler for src/cbt.c
  Moving data sections to text in out/cbt.16.s
  Generating assembler for src/floppy_dbt.c
  Moving data sections to text in out/floppy_dbt.16.s
  Generating 16bit layout of out/romlayout16.o
  Precompiling src/rombios16.lds.S
  Linking out/rom16.o
  Extracting binary out/rom16.bin
  Generating symbol offset header out/rom16.offset.auto.h
  Compiling whole program out/romlayout32.o
  Precompiling src/rombios32.lds.S
  Linking out/rom32.o
  Extracting binary out/rom32.bin
  Generating symbol offset header out/rom32.offset.auto.h
  Building out/bios.bin
Writing output rom out/bios.bin
 16bit C-code size: 26336
 32bit C-code size: 11044
 Total C-code size: 37380



From zrfail at gmail.com  Thu Jun 19 10:24:10 2008
From: zrfail at gmail.com (Zhang Rui)
Date: Thu, 19 Jun 2008 16:24:10 +0800
Subject: [coreboot] GSoC project(SCSI boot)__status report
In-Reply-To: <6F651D11120C4323B9E0DC329F4D0734@smitty2m>
References: <92cbc4c70806020926i41b757c0ga661a3549c840be5@mail.gmail.com>
	<48567C4B.6050302@coresystems.de>
	<20080616223806.GA5103@morn.localdomain>
	<48584311.4060308@coresystems.de>
	<5291a56333627468cb118eda911dc2af@imap.1and1.com>
	<20080618025800.GA28799@morn.localdomain>
	<a7df9ffb104f47b43005b4b3d234abbc@imap.1and1.com>
	<48592987.9050708@amd.com>
	<92cbc4c70806181838x66d6e45dl6f287441838de26b@mail.gmail.com>
	<6F651D11120C4323B9E0DC329F4D0734@smitty2m>
Message-ID: <92cbc4c70806190124v4422a1e4kd0302de3dd1df79@mail.gmail.com>

2008/6/19 Joseph Smith <joe at settoplinux.org>:
>
>[...]
>
> Well,
> Sorry to say, to me that does not make very much sense.
> First of all, at the point where you "1. copy LegacyBIOS codes to 0xf0000"
> the memory should already be initialized by coreboot correct?? This is one
> of the first things coreboot does is initialize the memory. So, the second
> part of number 2. ("initialize the memory") may not be necessary if the
> memory is already initialized by coreboot.

Sorry for being unclear. According to Kevin, some LegacyBIOS interrupt
handlers need the Bios Data Area (BDA) and Extended Bios Data Area
(EBDA) setted by the post() function in LegacyBIOS.  So my meaning of
2. ("initialize the memory") is use modified post() to set up these
areas.
Here is some piece of Kevin's email, and I forword the full text at
the end of this email.
>> >> What we have to find out is: Do we have to preserve much at all? Maybe
>> >> it is enough to install legacybios to 0xf0000 and let it live there,
>> >> then the payloads could just use intXX calls, as they can with an
>> >> AMI/Phoenix/Award bios installed. But maybe it is not that trivial.
>
> As above, some of the interrupt handlers may run okay without "post"
> running.  However, several of them want to access the Bios Data Area
> (BDA) and Extended Bios Data Area (EBDA).  Basically, these are the
> working storage areas of the bios.  The "post" code is what
> initializes these memory areas.


> Here is what I would suggest, I don't know if it is the right direction, but
> I think it logically makes sense:
>
> 1. Start the coreboot initialization process as normal
> 2. When coreboot gets to the memory allocation part; have it reserve a
> certain amount(Size of LegacyBIOS??) at 0xf0000 (if option LegacyBIOS is
> selected).
this should be taken to consideration.

> 3. (if option LegacyBIOS is selected) copy LegacyBIOS codes to 0xf0000.
> 4. (if option LegacyBIOS is selected) Jump to LegacyBIOS and setup any
> tables, INT's, etc.
According to Kevin's email, this will be done by calling post() in
LegacyBIOS. But post() will do the booting at the end, so we should
modify it to return to coreboot.

> 5. Return to coreboot and continue as normal.
> 6. in the payload part initialize the SCSI controller and install a handler
> and call LegacyBIOS INT19.
>
> Does this make any sense, or am I way off course???

Thanks to Joseph. You give a more detailed roadmap and I will try to
go on this direction.

And any questions?

Zhang Rui







Here is Kevin's email.

2008/6/17 Kevin O'Connor <kevin at koconnor.net>:
> On Mon, Jun 16, 2008 at 04:44:27PM +0200, Stefan Reinauer wrote:
>> Kevin: Zhang Rui is working for Google Summer of Code on booting off
>> SCSI using option roms with coreboot; He will be cleaning up the legacy
>> bios infrastructure parts in coreboot and make sure LegacyBIOS can
>> easily be used. It would be great if you could help him in case we are
>> in need of someone who knows Legacy BIOS really well!
>
> Sure.  I'd prefer to cc a mailing list though - it increases overall
> awareness.  Either coreboot or bochs lists would be fine.
>
>> >> The code in util/x86emu/ should then be modified to
>> >> * look for that file in the "lar"
>> >> * copy it to 0xf0000
>> >> * use it instead of the current handlers
>> >>
>> >
>> > I have a question, what is the exact address of each handler function
>> > in the legacybios of Qemu/Bochs? Does the legacybios bin begin with
>> > the int0 call so the address of intXX call can be calculated from the
>> > beginning of legacybios bin?
>
> Look for the ".org" strings in rombios.c of bochs bios.  Or, with
> LegacyBIOS, look for all the "entry_xxx" functions in
> src/romlayout.S.  See:
>
> http://git.linuxtogo.org/?p=kevin/legacybios.git;a=blob;f=src/romlayout.S;h=c8522612ab996533e6480dfe8ccc73e6af0f7c0d;hb=f54c150090ff38a73ef64a5d20fdfa0d9c403972#l363
>
> These define the entry points of the bios.  You definitely do _not_
> want to use the fixed addresses.  The one exception is f000:fff0 -
> which is the standard 16bit entry point for the "post" code of the
> bios.
>
>> Here's the first question to Kevin: How can we install the LegacyBIOS
>> interrupt handlers in order to call a single option rom and return back
>> to coreboot scope?
>
> I'm slightly confused by your use of "legacy bios" and "LegacyBIOS".
> The latest code I've written (I'll call in LegacyBIOS) produces an elf
> file with a 32bit entry point.  It works as a standard payload with
> coreboot.
>
> In the general case, to use the 16bit handlers you need to run the
> code contained in the "post" section.  See:
>
> http://git.linuxtogo.org/?p=kevin/legacybios.git;a=blob;f=src/post.c;h=766e8984e765634a99989fbbd5cec74c914586a2;hb=f54c150090ff38a73ef64a5d20fdfa0d9c403972#l207
>
> This code initializes the BDA and EBDA memory areas - including the
> idt table.  However, the last part of "post" will attempt to boot the
> system (by calling int19).  If you want to "post" without booting,
> you'd need to extend LegacyBIOS to return to coreboot somehow.
>
> Is there a particular reason you'd want to return to coreboot?
>
>>Is there some entry point in LegacyBIOS for doing this?
>
> To run "post" in LegacyBIOS, you should jump to the 32bit elf entry
> point.  See:
>
> http://git.linuxtogo.org/?p=kevin/legacybios.git;a=blob;f=src/post.c;h=766e8984e765634a99989fbbd5cec74c914586a2;hb=f54c150090ff38a73ef64a5d20fdfa0d9c403972#l324
>
> If you really wanted to, you could jump to f000:fff0 in 16bit mode,
> but all that will do with LegacyBIOS is cause it to jump back to 32bit
> mode and then call the same code as above.
>
>>Or should we use the hard coded addresses of the handlers? Is
>> there a hard coded address for every int handler? Or is there a better
>> way for doing this?
>
> No, no, and yes.  You really don't want to use the fixed addresses.
> You really want to rely on LegacyBIOS (or bochs bios) to do its job.
>
> [...]
>> >> What we have to find out is: Do we have to preserve much at all? Maybe
>> >> it is enough to install legacybios to 0xf0000 and let it live there,
>> >> then the payloads could just use intXX calls, as they can with an
>> >> AMI/Phoenix/Award bios installed. But maybe it is not that trivial.
>
> As above, some of the interrupt handlers may run okay without "post"
> running.  However, several of them want to access the Bios Data Area
> (BDA) and Extended Bios Data Area (EBDA).  Basically, these are the
> working storage areas of the bios.  The "post" code is what
> initializes these memory areas.
>
> [...]
>> > Could we preserve 0xf0000 for the legacybios? If we can put coreboot
>> > table and ACPI tables and something else in the low 1M of RAM, it will
>> > be a good job. How much space will these tables take? I mean coreboot
>> > table and ACPI tables.
>
> What I'm currently doing is having coreboot build the tables somewhere
> high in memory, and then having LegacyBIOS move the tables that need
> to be in 0xf0000 down to that area.
>
> Regards,
> -Kevin
>



From peter at stuge.se  Thu Jun 19 13:43:01 2008
From: peter at stuge.se (Peter Stuge)
Date: Thu, 19 Jun 2008 13:43:01 +0200
Subject: [coreboot] Patch to extend ROM decode range to 1MB for vt8237r
In-Reply-To: <4859DD28.9080809@onelabs.com>
References: <4859A688.7070606@onelabs.com>
	<20080619023217.11593.qmail@stuge.se>
	<4859DD28.9080809@onelabs.com>
Message-ID: <20080619114301.4259.qmail@stuge.se>

On Wed, Jun 18, 2008 at 11:14:32PM -0500, bari wrote:
> This patch extends the VIA vt8237r southbridge decode range for the ROM 
> to 1MB.
> 
> Rudolf had use this for a board specific patch in the past. We also already 
> do this for the vt8237r in flashrom.
> 
> Signed-off-by: Bari Ari <bari at onelabs.com>

Acked-by: Peter Stuge <peter at stuge.se>

> Index: southbridge/via/vt8237r/vt8237r.c
> ===================================================================
> --- southbridge/via/vt8237r/vt8237r.c	(revision 3368)
> +++ southbridge/via/vt8237r/vt8237r.c	(working copy)
> @@ -78,7 +78,8 @@
>  	pci_write_config8(dev, 0x50, sb->fn_ctrl_lo);
>  	pci_write_config8(dev, 0x51, sb->fn_ctrl_hi);
>  
> 	/* TODO: If SATA is disabled, move IDE to fn0 to conform PCI specs. */
> +	/* Extend ROM decode to 1MB FFC00000 - FFFFFFFF */
> +	pci_write_config8(dev, 0x41, 0x7f);
>  }
>  
>  struct chip_operations southbridge_via_vt8237r_ops = {



From kevin at koconnor.net  Thu Jun 19 14:39:29 2008
From: kevin at koconnor.net (Kevin O'Connor)
Date: Thu, 19 Jun 2008 08:39:29 -0400
Subject: [coreboot] Black window when running qemu
	with	coreboot+LegacyBIOS
In-Reply-To: <92cbc4c70806190100u47e07626mf433ebcb54197b8@mail.gmail.com>
References: <92cbc4c70806181829x67547e58pf4df99b2a72d241b@mail.gmail.com>
	<20080619014748.GA1344@morn.localdomain>
	<92cbc4c70806190100u47e07626mf433ebcb54197b8@mail.gmail.com>
Message-ID: <20080619123929.GA7437@morn.localdomain>

On Thu, Jun 19, 2008 at 04:00:04PM +0800, Zhang Rui wrote:
> 2008/6/19 Kevin O'Connor <kevin at koconnor.net>:
> > $ objdump -x out/bios.bin.elf
> >
> > out/bios.bin.elf:     file format elf32-i386
> > out/bios.bin.elf
> > architecture: i386, flags 0x00000112:
> > EXEC_P, HAS_SYMS, D_PAGED
> > start address 0x000f66a0
> >
> > Program Header:
> >    LOAD off    0x00001000 vaddr 0x000f0000 paddr 0x000f0000 align 2**12
> >         filesz 0x00010000 memsz 0x00010000 flags rw-
> >
> > Sections:
> > Idx Name          Size      VMA       LMA       File off  Algn
> >  0 .data         00010000  000f0000  000f0000  00001000  2**0
> >                  CONTENTS, ALLOC, LOAD, DATA
> > SYMBOL TABLE:
> > 000f0000 l    d  .data  00000000 .data
> > 00010000 g       *ABS*  00000000 _binary_out_bios_bin_size
> > 00100000 g       *ABS*  00000000 __bss_start
> > 00100000 g       .data  00000000 _binary_out_bios_bin_end
> > 00100000 g       *ABS*  00000000 _edata
> > 00100000 g       *ABS*  00000000 _end
> > 000f0000 g       .data  00000000 _binary_out_bios_bin_start
> >
> legacybios/out> objdump -x bios.bin.elf
> bios.bin.elf:     file format elf32-i386
> bios.bin.elf
> architecture: i386, flags 0x00000112:
> EXEC_P, HAS_SYMS, D_PAGED
> start address 0x000f66e0
> 
> Program Header:
>     LOAD off    0x00000000 vaddr 0x08048000 paddr 0x08048000 align 2**12
>          filesz 0x00010074 memsz 0x00010074 flags rw-
> 
> Sections:
> Idx Name          Size      VMA       LMA       File off  Algn
>   0 .data         00010000  08048074  08048074  00000074  2**0
>                   CONTENTS, ALLOC, LOAD, DATA
> SYMBOL TABLE:
> 08048074 l    d  .data  00000000 .data
> 00000000 l    d  *ABS*  00000000 .shstrtab
> 00000000 l    d  *ABS*  00000000 .symtab
> 00000000 l    d  *ABS*  00000000 .strtab
> 00010000 g       *ABS*  00000000 _binary_out_bios_bin_size
> 08058074 g       *ABS*  00000000 __bss_start
> 08058074 g       .data  00000000 _binary_out_bios_bin_end
> 08058074 g       *ABS*  00000000 _edata
> 08058074 g       *ABS*  00000000 _end
> 08048074 g       .data  00000000 _binary_out_bios_bin_start
> 

Looks like a difference between our versions of 'ld'.  The build
effectively does:

ld -melf_i386 -e 0xf66e0 -Ttext 0xf0000 -b binary bios.bin -o bios.bin.elf

I'm not sure why it builds a different elf on your machine.  Can you
try modifying tools/buildrom.py so that it uses "-Tdata" instead of
"-Ttext"?

Myles, maybe this was the same problem you were seeing?

-Kevin



From jordan.crouse at amd.com  Thu Jun 19 16:20:35 2008
From: jordan.crouse at amd.com (Jordan Crouse)
Date: Thu, 19 Jun 2008 08:20:35 -0600
Subject: [coreboot] Buildrom breaks with 2.6.25.4 or 2.6.24.7 kernel
	source
In-Reply-To: <4859AE6E.7090000@onelabs.com>
References: <4859AE6E.7090000@onelabs.com>
Message-ID: <20080619142035.GA3787@cosmic.amd.com>

On 18/06/08 19:55 -0500, bari wrote:
> I tried building LAB for the Tyan s-2891 using buildrom and 2.6.25.4 
> kernel source.
> 
> debug output:
> 
> /home/ly/buildrom/buildrom-devel/work/busybox/busybox-1.1.3/libbb/procps.c:15:22: 
> error: asm/page.h: No such file or directory
> make[2]: *** 
> [/home/ly/buildrom/buildrom-devel/work/busybox/busybox-1.1.3/libbb/procps.o] 
> Error 1
> make[1]: *** [all] Error 2
> 
> 
> The kernel was built just fine. It just breaks during the build of busybox.
> 
> Also breaks with 2.6.24.7 kernel, 2.6.22.2 or 2.6.22.5 kernel is fine.
> 
> Any ideas why?

Did any of the asm/ header files get copied in the unifdef stage?  If
not, then I'm betting it is because of the i386->x86 switch that happened
post 2.6.22.

Jordan

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




From joe at settoplinux.org  Thu Jun 19 18:35:09 2008
From: joe at settoplinux.org (Joseph Smith)
Date: Thu, 19 Jun 2008 12:35:09 -0400
Subject: [coreboot]
	=?utf-8?q?GSoC_project=28SCSI_boot=29=5F=5Fstatus_repo?=
	=?utf-8?q?rt?=
In-Reply-To: <92cbc4c70806190124v4422a1e4kd0302de3dd1df79@mail.gmail.com>
References: <92cbc4c70806020926i41b757c0ga661a3549c840be5@mail.gmail.com>
	<48567C4B.6050302@coresystems.de>
	<20080616223806.GA5103@morn.localdomain>
	<48584311.4060308@coresystems.de>
	<5291a56333627468cb118eda911dc2af@imap.1and1.com>
	<20080618025800.GA28799@morn.localdomain>
	<a7df9ffb104f47b43005b4b3d234abbc@imap.1and1.com>
	<48592987.9050708@amd.com>
	<92cbc4c70806181838x66d6e45dl6f287441838de26b@mail.gmail.com>
	<6F651D11120C4323B9E0DC329F4D0734@smitty2m>
	<92cbc4c70806190124v4422a1e4kd0302de3dd1df79@mail.gmail.com>
Message-ID: <96ea9e59082d34e62343c21f5cb32fed@imap.1and1.com>




On Thu, 19 Jun 2008 16:24:10 +0800, "Zhang Rui" <zrfail at gmail.com> wrote:
> 2008/6/19 Joseph Smith <joe at settoplinux.org>:
>>
>>[...]
>>
>> Well,
>> Sorry to say, to me that does not make very much sense.
>> First of all, at the point where you "1. copy LegacyBIOS codes to
> 0xf0000"
>> the memory should already be initialized by coreboot correct?? This is
> one
>> of the first things coreboot does is initialize the memory. So, the
> second
>> part of number 2. ("initialize the memory") may not be necessary if the
>> memory is already initialized by coreboot.
> 
> Sorry for being unclear. According to Kevin, some LegacyBIOS interrupt
> handlers need the Bios Data Area (BDA) and Extended Bios Data Area
> (EBDA) setted by the post() function in LegacyBIOS.  So my meaning of
> 2. ("initialize the memory") is use modified post() to set up these
> areas.
> Here is some piece of Kevin's email, and I forword the full text at
> the end of this email.
>>> >> What we have to find out is: Do we have to preserve much at all?
> Maybe
>>> >> it is enough to install legacybios to 0xf0000 and let it live there,
>>> >> then the payloads could just use intXX calls, as they can with an
>>> >> AMI/Phoenix/Award bios installed. But maybe it is not that trivial.
>>
>> As above, some of the interrupt handlers may run okay without "post"
>> running.  However, several of them want to access the Bios Data Area
>> (BDA) and Extended Bios Data Area (EBDA).  Basically, these are the
>> working storage areas of the bios.  The "post" code is what
>> initializes these memory areas.
> 
> 
>> Here is what I would suggest, I don't know if it is the right direction,
> but
>> I think it logically makes sense:
>>
>> 1. Start the coreboot initialization process as normal
>> 2. When coreboot gets to the memory allocation part; have it reserve a
>> certain amount(Size of LegacyBIOS??) at 0xf0000 (if option LegacyBIOS is
>> selected).
> this should be taken to consideration.
> 
>> 3. (if option LegacyBIOS is selected) copy LegacyBIOS codes to 0xf0000.
>> 4. (if option LegacyBIOS is selected) Jump to LegacyBIOS and setup any
>> tables, INT's, etc.
> According to Kevin's email, this will be done by calling post() in
> LegacyBIOS. But post() will do the booting at the end, so we should
> modify it to return to coreboot.
> 
>> 5. Return to coreboot and continue as normal.
>> 6. in the payload part initialize the SCSI controller and install a
> handler
>> and call LegacyBIOS INT19.
>>
>> Does this make any sense, or am I way off course???
> 
> Thanks to Joseph. You give a more detailed roadmap and I will try to
> go on this direction.
> 
> And any questions?
> 
I don't think so, I am excited to try it out once you are finished.
Although I am using IDE instead of SCSI.
Sorry if I sound like a broken record, the main thing to remember is we
need to make all the LegacyBIOS code that is getting injected into the
coreboot base code optional, hence the "if option LegacyBIOS is selected".
There are alot of people sensative about this, and we need to keep coreboot
flexible and make everyone happy, right?

-- 
Thanks,
Joseph Smith
Set-Top-Linux
www.settoplinux.org




From Ken.Fuchs at bench.com  Thu Jun 19 22:23:44 2008
From: Ken.Fuchs at bench.com (Ken.Fuchs at bench.com)
Date: Thu, 19 Jun 2008 15:23:44 -0500
Subject: [coreboot] coreboot and embedded controllers,
	for example OLPC and its	OpenEC code
In-Reply-To: <20080619021452.30958.qmail@stuge.se>
Message-ID: <AA28F077645B324881335614E4F7C4284A4932@win-ex01.bench.com>

Peter Stuge wrote:

> Just a little tidbit..
> 
> On Thu, Jun 19, 2008 at 01:22:47AM +0200, Frieder Ferlemann wrote:
>
> > Yep, let's see what happens. OpenEC is GPL'ed so it is there
> > to stay and it is waiting for a slightly better chance than
> > OLPC turned out to be.
> 
> Me and Uwe ran into a desktop board with this SMSC superio..
> 
> > And OpenEC was written with portability in mind. While it
> > specifically targets an ENE KB3700 (with its 8051 based core)
> > the source is also compileable with gcc.
> 
> The superio included an 8051. The 8051 did not have it's own program
> memory, it's program was stored in the BIOS flash.
> 
> When the board powered up, only the 8051 was running. It needed
> software to do some stuff, and only then could it negotiate release
> of the main CPU reset.
> 
> We found some PDF files and it did seem within our reach to get the
> 8051 to at least power up the CPU, but it was the heart of the
> superio, so I believe most superio functions would be unavailable
> until there was more 8051 code.

Can you provide more details?  Such as exactly which SMSC SuperIO?
What was the embedded controller used for?  Just perform basic
SuperIO functions or something more?  Which desktop board?
Which processor and chipset?

coreboot needs to have a solution/framework/interface for dealing
with embedded controllers.  The trend seems to be that mainboards
will have more of these as time goes by.  For existing boards,
coreboot may be able to load the existing embedded controller
code, but for new designs with coreboot firmware, the embedded
controller code will have to written from scratch and obviously
will require a toolchain and debugging tools.

Here's a few resources that may be useful for working with EC
(especially 8051/MCS 51):

http://sdcc.sourceforge.net/

http://www.8052.com/tutorial.phtml

http://www.noicedebugger.com/

http://mazsola.iit.uni-miskolc.hu/~drdani/embedded/s51/

http://en.wikipedia.org/wiki/Intel_8051

Sincerely,

Ken Fuchs



From jordan.crouse at amd.com  Thu Jun 19 22:43:52 2008
From: jordan.crouse at amd.com (Jordan Crouse)
Date: Thu, 19 Jun 2008 14:43:52 -0600
Subject: [coreboot] coreboot and embedded controllers,
	for example OLPC and its	OpenEC code
In-Reply-To: <AA28F077645B324881335614E4F7C4284A4932@win-ex01.bench.com>
References: <20080619021452.30958.qmail@stuge.se>
	<AA28F077645B324881335614E4F7C4284A4932@win-ex01.bench.com>
Message-ID: <20080619204352.GB28880@cosmic.amd.com>

On 19/06/08 15:23 -0500, Ken.Fuchs at bench.com wrote:
> coreboot needs to have a solution/framework/interface for dealing
> with embedded controllers.  The trend seems to be that mainboards
> will have more of these as time goes by.  For existing boards,
> coreboot may be able to load the existing embedded controller
> code, but for new designs with coreboot firmware, the embedded
> controller code will have to written from scratch and obviously
> will require a toolchain and debugging tools.

When done right, the embedded controller will be transparent to
coreboot.  If you need a solution / framework / interface
for dealing with custom embedded controller code, then the
openEC project isn't doing a very good job.

Jordan




From bari at onelabs.com  Thu Jun 19 22:55:53 2008
From: bari at onelabs.com (bari)
Date: Thu, 19 Jun 2008 15:55:53 -0500
Subject: [coreboot] coreboot and embedded controllers,
 for example OLPC and its	OpenEC code
In-Reply-To: <20080619204352.GB28880@cosmic.amd.com>
References: <20080619021452.30958.qmail@stuge.se>	<AA28F077645B324881335614E4F7C4284A4932@win-ex01.bench.com>
	<20080619204352.GB28880@cosmic.amd.com>
Message-ID: <485AC7D9.6040001@onelabs.com>

Jordan Crouse wrote:
> On 19/06/08 15:23 -0500, Ken.Fuchs at bench.com wrote:
>   
>> coreboot needs to have a solution/framework/interface for dealing
>> with embedded controllers.  The trend seems to be that mainboards
>> will have more of these as time goes by.  For existing boards,
>> coreboot may be able to load the existing embedded controller
>> code, but for new designs with coreboot firmware, the embedded
>> controller code will have to written from scratch and obviously
>> will require a toolchain and debugging tools.
>>     
>
> When done right, the embedded controller will be transparent to
> coreboot.  If you need a solution / framework / interface
> for dealing with custom embedded controller code, then the
> openEC project isn't doing a very good job.
>   
Exactly!

What is the ultimate dream here? To develop replacement open firmware 
for existing embedded controllers
that have been used for years mainly in laptops and servers?

To develop open firmware for embedded controllers that oem's and odm's 
will use in new designs in the future?

I understand why someone that enjoys tinkering with laptops and servers 
might like this. I'm not sure that the odm's and oem's will be 
interested in an open solution unless it is very stable and very well 
supported.

-Bari




From jordan.crouse at amd.com  Thu Jun 19 23:04:06 2008
From: jordan.crouse at amd.com (Jordan Crouse)
Date: Thu, 19 Jun 2008 15:04:06 -0600
Subject: [coreboot] coreboot and embedded controllers,
	for example OLPC and its	OpenEC code
In-Reply-To: <485AC7D9.6040001@onelabs.com>
References: <20080619021452.30958.qmail@stuge.se>
	<AA28F077645B324881335614E4F7C4284A4932@win-ex01.bench.com>
	<20080619204352.GB28880@cosmic.amd.com>
	<485AC7D9.6040001@onelabs.com>
Message-ID: <20080619210406.GC28880@cosmic.amd.com>

On 19/06/08 15:55 -0500, bari wrote:
> Jordan Crouse wrote:
> > On 19/06/08 15:23 -0500, Ken.Fuchs at bench.com wrote:
> >   
> >> coreboot needs to have a solution/framework/interface for dealing
> >> with embedded controllers.  The trend seems to be that mainboards
> >> will have more of these as time goes by.  For existing boards,
> >> coreboot may be able to load the existing embedded controller
> >> code, but for new designs with coreboot firmware, the embedded
> >> controller code will have to written from scratch and obviously
> >> will require a toolchain and debugging tools.
> >>     
> >
> > When done right, the embedded controller will be transparent to
> > coreboot.  If you need a solution / framework / interface
> > for dealing with custom embedded controller code, then the
> > openEC project isn't doing a very good job.
> >   
> Exactly!
> 
> What is the ultimate dream here? To develop replacement open firmware 
> for existing embedded controllers
> that have been used for years mainly in laptops and servers?
> 
> To develop open firmware for embedded controllers that oem's and odm's 
> will use in new designs in the future?
> 
> I understand why someone that enjoys tinkering with laptops and servers 
> might like this. I'm not sure that the odm's and oem's will be 
> interested in an open solution unless it is very stable and very well 
> supported.

If you do s/embedded controller/BIOS/ in the paragraphs, the argument
remains exactly the same. Lets face it, coreboot and an embedded
controller project are birds of a feather.  What I'm saying is that
in an ideal world, they can both exist without being aware of each other.

Jordan

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




From peter at stuge.se  Thu Jun 19 23:07:39 2008
From: peter at stuge.se (Peter Stuge)
Date: Thu, 19 Jun 2008 23:07:39 +0200
Subject: [coreboot] coreboot and embedded controllers,
	for example OLPC and its	OpenEC code
In-Reply-To: <485AC7D9.6040001@onelabs.com>
References: <20080619021452.30958.qmail@stuge.se>
	<AA28F077645B324881335614E4F7C4284A4932@win-ex01.bench.com>
	<20080619204352.GB28880@cosmic.amd.com>
	<485AC7D9.6040001@onelabs.com>
Message-ID: <20080619210739.7942.qmail@stuge.se>

On Thu, Jun 19, 2008 at 03:55:53PM -0500, bari wrote:
> Jordan Crouse wrote:
> > When done right, the embedded controller will be transparent to
> > coreboot.

How common is that in your experience?


> What is the ultimate dream here? To develop replacement open
> firmware for existing embedded controllers that have been used for
> years mainly in laptops and servers?

Yeah, in some cases..


> To develop open firmware for embedded controllers that oem's and
> odm's will use in new designs in the future?
> 
> I understand why someone that enjoys tinkering with laptops and
> servers might like this. I'm not sure that the odm's and oem's will
> be interested in an open solution unless it is very stable and very
> well supported.

Well there's still the binary blob problem.

If the EC has it's own firmware then coreboot just needs to know how
to cooperate with it, but for ones where EC firmware is stored in the
BIOS flash - there's a bit of a problem with coreboot..

Granted, those ECs don't seem to be so popular. (yet?)


Sorry - I don't remember which board or SMSC controller it was.
Hopefully Uwe will see this thread and fill in.


//Peter



From jordan.crouse at amd.com  Thu Jun 19 23:17:53 2008
From: jordan.crouse at amd.com (Jordan Crouse)
Date: Thu, 19 Jun 2008 15:17:53 -0600
Subject: [coreboot] coreboot and embedded controllers,
	for example OLPC and its	OpenEC code
In-Reply-To: <20080619210739.7942.qmail@stuge.se>
References: <20080619021452.30958.qmail@stuge.se>
	<AA28F077645B324881335614E4F7C4284A4932@win-ex01.bench.com>
	<20080619204352.GB28880@cosmic.amd.com>
	<485AC7D9.6040001@onelabs.com> <20080619210739.7942.qmail@stuge.se>
Message-ID: <20080619211753.GD28880@cosmic.amd.com>

On 19/06/08 23:07 +0200, Peter Stuge wrote:
> On Thu, Jun 19, 2008 at 03:55:53PM -0500, bari wrote:
> > Jordan Crouse wrote:
> > > When done right, the embedded controller will be transparent to
> > > coreboot.
> 
> How common is that in your experience?

Very common.  But I have to qualify my answer - when I say transparent, 
I don't mean that there might not be special registers implemented
by the embedded controller for that particular platform.

What I mean by "transparent" is that it shouldn't matter to coreboot
if the embedded controller is running OpenEC or a proprietary version.
It should look and feel the same.

> > To develop open firmware for embedded controllers that oem's and
> > odm's will use in new designs in the future?
> > 
> > I understand why someone that enjoys tinkering with laptops and
> > servers might like this. I'm not sure that the odm's and oem's will
> > be interested in an open solution unless it is very stable and very
> > well supported.
> 
> Well there's still the binary blob problem.
> 
> If the EC has it's own firmware then coreboot just needs to know how
> to cooperate with it, but for ones where EC firmware is stored in the
> BIOS flash - there's a bit of a problem with coreboot..

Let us be careful with definitions.  None of these things are problems
with the coreboot code itself, but rather with the management of the
ROM in general.  And yes, we have problems with figuring out ROM
partitioning and management, but we are working on those.

> Granted, those ECs don't seem to be so popular. (yet?)

They will be, sooner then you think. 

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




From bari at onelabs.com  Thu Jun 19 23:36:20 2008
From: bari at onelabs.com (bari)
Date: Thu, 19 Jun 2008 16:36:20 -0500
Subject: [coreboot] Patch to extend ROM decode range to 1MB for vt8237r
Message-ID: <485AD154.3010703@onelabs.com>

This patch extends the VIA vt8237r southbridge decode range for the ROM 
to 1MB.

Signed-off-by: Bari Ari <bari at onelabs.com>

Acked-by: Peter Stuge <peter at stuge.se>

-------------- next part --------------
A non-text attachment was scrubbed...
Name: vt8237r-s.patch
Type: text/x-patch
Size: 521 bytes
Desc: not available
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20080619/d2f4c217/attachment.patch>

From jordan.crouse at amd.com  Fri Jun 20 00:16:03 2008
From: jordan.crouse at amd.com (Jordan Crouse)
Date: Thu, 19 Jun 2008 16:16:03 -0600
Subject: [coreboot] libpayload:  Support curses for serial
Message-ID: <20080619221603.GF28880@cosmic.amd.com>

Support curses over serial.  Tested with coreinfo over qemu, looks good.
I'm not sure what will happen when we actually get in front of a real
terminal emulator, but thats part of the fun.

Jordan
-- 
Jordan Crouse
Systems Software Development Engineer 
Advanced Micro Devices, Inc.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: term.patch
Type: text/x-diff
Size: 5773 bytes
Desc: not available
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20080619/54f4e48d/attachment.bin>

From rminnich at gmail.com  Fri Jun 20 00:21:45 2008
From: rminnich at gmail.com (ron minnich)
Date: Thu, 19 Jun 2008 15:21:45 -0700
Subject: [coreboot] libpayload: Support curses for serial
In-Reply-To: <20080619221603.GF28880@cosmic.amd.com>
References: <20080619221603.GF28880@cosmic.amd.com>
Message-ID: <13426df10806191521u46f1742cr24d10a030ece90db@mail.gmail.com>

On Thu, Jun 19, 2008 at 3:16 PM, Jordan Crouse <jordan.crouse at amd.com> wrote:
> Support curses over serial.  Tested with coreinfo over qemu, looks good.
> I'm not sure what will happen when we actually get in front of a real
> terminal emulator, but thats part of the fun.
>
> Jordan

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



From jordan.crouse at amd.com  Fri Jun 20 00:49:13 2008
From: jordan.crouse at amd.com (Jordan Crouse)
Date: Thu, 19 Jun 2008 16:49:13 -0600
Subject: [coreboot] Bayou v0.3
Message-ID: <20080619224913.GG28880@cosmic.amd.com>

Greetings.  I am very happy to present to you the next version of the
proof-of-concept for Bayou, the Coreboot payload chooser. A good amount
of this version was re-written to support everybody's favorite feature:
chaining! :)

Let me get the usual URLS out the way.  Source and QEMU demo:

http://www.coreboot.org/~jcrouse/bayou_0.3.tar.gz
http://www.coreboot.org/~jcrouse/bayou-demo-20080619.rom

The default chain runs a password checker and then coreinfo.  If you 
press escape before the timeout, you can run coreinfo directly from
the menu, or run the default chain.  If you exit from coreinfo in
the chain, you will go back to the menu automatically.

The "system password" is 'coreboot'.  My apologies to Uwe - I know he
has a better password payload, but he is busy right now, and I needed
to hack something together really quickly.  oh, and make sure you check
it all out in serial too.. :)

This is using the configuration scheme that I wrote up on the Bayou
wiki page:

http://www.coreboot.org/Bayou

The bayou_payload_table format allows us to support chains, menu items,
and menu items that turn into chains; basically the whole shooting match.

The downside is that this makes building the LAR somewhat more complex.
To help with that, I wrote a new utility I call pbuilder that uses an 
XML file to define the payloads to be included and writes the LAR 
and automatically inserts the payloads it needs.  I chose XML because
it fit well with the nested nature of the configuration table.
Time will tell if it will work well with buildrom or not.  I'll be
documenting all of this on the wiki in the coming days.

So there you go.  Comments welcome.  Our next step after this is to
start resolving the various SELF related feuds and start getting this
code checked in.

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




From peter at stuge.se  Fri Jun 20 01:11:18 2008
From: peter at stuge.se (Peter Stuge)
Date: Fri, 20 Jun 2008 01:11:18 +0200
Subject: [coreboot] Bayou v0.3
In-Reply-To: <20080619224913.GG28880@cosmic.amd.com>
References: <20080619224913.GG28880@cosmic.amd.com>
Message-ID: <20080619231118.28324.qmail@stuge.se>

On Thu, Jun 19, 2008 at 04:49:13PM -0600, Jordan Crouse wrote:
> Greetings.  I am very happy to present to you the next version of the
> proof-of-concept for Bayou, the Coreboot payload chooser.

Sweet! :)

I have not yet tested it, but I encountered an issue in the 0.2
blar Makefile that I never sent a patch for. It remains in pbuilder
so here's the patch!

Oh - and please run make clean before packaging the next tarball so
that x86_64 lzma/*.o aren't included - they don't work here. :)

I think bayou is so neat! Thanks a lot for your efforts!


//Peter
-------------- next part --------------
A non-text attachment was scrubbed...
Name: bayou_0.3_payload-builder_Makefile_dependencyfix.patch
Type: text/x-diff
Size: 1103 bytes
Desc: not available
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20080620/58ab3a65/attachment.bin>

From svn at coreboot.org  Fri Jun 20 02:01:14 2008
From: svn at coreboot.org (svn at coreboot.org)
Date: Fri, 20 Jun 2008 02:01:14 +0200
Subject: [coreboot] r3369 - trunk/coreboot-v2/src/southbridge/via/vt8237r
Message-ID: <mailman.1632.1355071333.16123.coreboot@coreboot.org>

Author: stuge
Date: 2008-06-20 02:01:14 +0200 (Fri, 20 Jun 2008)
New Revision: 3369

Modified:
   trunk/coreboot-v2/src/southbridge/via/vt8237r/vt8237r.c
Log:
Extend the VIA vt8237r southbridge decode range for the ROM to 1MB.

Signed-off-by: Bari Ari <bari at onelabs.com>
Acked-by: Peter Stuge <peter at stuge.se>


Modified: trunk/coreboot-v2/src/southbridge/via/vt8237r/vt8237r.c
===================================================================
--- trunk/coreboot-v2/src/southbridge/via/vt8237r/vt8237r.c	2008-06-18 13:36:34 UTC (rev 3368)
+++ trunk/coreboot-v2/src/southbridge/via/vt8237r/vt8237r.c	2008-06-20 00:01:14 UTC (rev 3369)
@@ -79,6 +79,8 @@
 	pci_write_config8(dev, 0x51, sb->fn_ctrl_hi);
 
 	/* TODO: If SATA is disabled, move IDE to fn0 to conform PCI specs. */
+	/* Extend ROM decode to 1MB FFC00000 - FFFFFFFF */
+	pci_write_config8(dev, 0x41, 0x7f);
 }
 
 struct chip_operations southbridge_via_vt8237r_ops = {




From svn at coreboot.org  Fri Jun 20 02:01:42 2008
From: svn at coreboot.org (svn at coreboot.org)
Date: Fri, 20 Jun 2008 02:01:42 +0200
Subject: [coreboot] r3370 - in trunk/payloads/libpayload: curses drivers
	include
Message-ID: <mailman.1633.1355071333.16123.coreboot@coreboot.org>

Author: jcrouse
Date: 2008-06-20 02:01:42 +0200 (Fri, 20 Jun 2008)
New Revision: 3370

Modified:
   trunk/payloads/libpayload/curses/keyboard.c
   trunk/payloads/libpayload/curses/tinycurses.c
   trunk/payloads/libpayload/drivers/serial.c
   trunk/payloads/libpayload/include/libpayload.h
Log:
libpayload:  Support curses for serial

Support the curses interface over serial by supporting a minimal vt100
terminal.

Signed-off-by: Jordan Crouse <jordan.crouse at amd.com>
Acked-by: Ronald G. Minnich <rminnich at gmail.com>


Modified: trunk/payloads/libpayload/curses/keyboard.c
===================================================================
--- trunk/payloads/libpayload/curses/keyboard.c	2008-06-20 00:01:14 UTC (rev 3369)
+++ trunk/payloads/libpayload/curses/keyboard.c	2008-06-20 00:01:42 UTC (rev 3370)
@@ -43,11 +43,89 @@
 
 /* ============== Serial ==================== */
 
-/* FIXME:  Cook the serial correctly */
+/* We treat serial like a vt100 terminal.  For now we
+   do the cooking in here, but we should probably eventually
+   pass it to dedicated vt100 code */
 
+static int getkeyseq(char *buffer, int len)
+{
+	int i;
+
+	for(i = 0; i < 75; i++) {
+		if (serial_havechar())
+			break;
+		mdelay(1);
+	}
+
+	if (i == 75)
+		return len;
+
+	buffer[len++] = serial_getchar();
+	return getkeyseq(buffer, len);
+}
+
+static struct {
+	char *seq;
+	int key;
+} escape_codes[] = {
+	{ "[A", KEY_UP },
+	{ "[B", KEY_DOWN },
+	{ "[C", KEY_RIGHT },
+	{ "[D", KEY_LEFT },
+	{ "OP", KEY_F(1) },
+	{ "OQ", KEY_F(2) },
+	{ "OR", KEY_F(3) },
+	{ "OS", KEY_F(4) },
+	{ "[15~", KEY_F(5) },
+	{ "[17~", KEY_F(6) },
+	{ "[18~", KEY_F(7) },
+	{ "[19~", KEY_F(8) },
+	{ "[20~", KEY_F(9) },
+	{ "[21~", KEY_F(10) },
+	{ "[24~", KEY_F(12) },
+	{ NULL },
+};
+
+static int handle_escape(void)
+{
+	char buffer[5];
+	int len = getkeyseq(buffer, 0);
+	int i, t;
+
+	if (len == 0)
+		return 27;
+
+	for(i = 0; escape_codes[i].seq != NULL; i++) {
+		char *p = escape_codes[i].seq;
+
+		for(t = 0; t < len; t++) {
+			if (!*p || *p != buffer[t])
+				break;
+			p++;
+		}
+
+		if (t == len)
+			return escape_codes[i].key;
+	}
+
+	return 0;
+}
+
 static int cook_serial(unsigned char ch)
 {
-	return (int) ch;
+	switch(ch) {
+	case 8:
+		return KEY_BACKSPACE;
+
+	case 13:
+		return KEY_ENTER;
+
+	case 27:
+		return handle_escape();
+
+	default:
+		return ch;
+	}
 }
 
 /* ================ Keyboard ================ */

Modified: trunk/payloads/libpayload/curses/tinycurses.c
===================================================================
--- trunk/payloads/libpayload/curses/tinycurses.c	2008-06-20 00:01:14 UTC (rev 3369)
+++ trunk/payloads/libpayload/curses/tinycurses.c	2008-06-20 00:01:42 UTC (rev 3370)
@@ -218,6 +218,10 @@
 	// newterm(name, stdout, stdin);
 	// def_prog_mode();
 
+	if (curses_flags & F_ENABLE_SERIAL) {
+		serial_clear();
+	}
+
 	if (curses_flags & F_ENABLE_CONSOLE) {
 		/* Clear the screen and kill the cursor */
 
@@ -586,20 +590,48 @@
 	win->_flags |= _HASMOVED;
 	return OK;
 }
+
 int wnoutrefresh(WINDOW *win)
 {
 	// FIXME.
+	int serial_is_bold = 0;
+
 	int x, y;
 
+	serial_end_bold();
+
 	for (y = 0; y <= win->_maxy; y++) {
+
+		/* Position the serial cursor */
+
+		if (curses_flags & F_ENABLE_SERIAL)
+			serial_set_cursor(win->_begy + y, win->_begx);
+
 		for (x = 0; x <= win->_maxx; x++) {
-			if (curses_flags & F_ENABLE_SERIAL)
+			attr_t attr = win->_line[y].text[x].attr;
+
+			unsigned int c =
+				((int)color_pairs[PAIR_NUMBER(attr)]) << 8;
+
+			if (curses_flags & F_ENABLE_SERIAL) {
+
+				if (attr & A_BOLD) {
+					if (!serial_is_bold) {
+						serial_start_bold();
+						serial_is_bold = 1;
+					}
+				}
+				else {
+					if (serial_is_bold) {
+						serial_end_bold();
+						serial_is_bold = 0;
+					}
+				}
+
 				serial_putchar(win->_line[y].text[x].chars[0]);
+			}
 
 			if (curses_flags & F_ENABLE_CONSOLE) {
-				attr_t attr = win->_line[y].text[x].attr;
-				unsigned int c =
-				  ((int)color_pairs[PAIR_NUMBER(attr)]) << 8;
 
 				/* Handle some of the attributes. */
 				if (attr & A_BOLD)

Modified: trunk/payloads/libpayload/drivers/serial.c
===================================================================
--- trunk/payloads/libpayload/drivers/serial.c	2008-06-20 00:01:14 UTC (rev 3369)
+++ trunk/payloads/libpayload/drivers/serial.c	2008-06-20 00:01:42 UTC (rev 3370)
@@ -35,6 +35,25 @@
 #define DIVISOR (115200 / CONFIG_SERIAL_BAUD_RATE)
 #endif
 
+/* This is a hack - we convert the drawing characters to ASCII */
+
+static unsigned char translate_special_chars(unsigned char c)
+{
+	switch(c) {
+	case 196:
+		return '-';
+	case 179:
+		return '|';
+	case 218:
+	case 191:
+	case 192:
+	case 217:
+		return '+';
+	default:
+		return ' ';
+	}
+}
+
 void serial_init(void)
 {
 #ifdef CONFIG_SERIAL_SET_SPEED
@@ -61,6 +80,9 @@
 
 void serial_putchar(unsigned char c)
 {
+	if (c > 127)
+		c = translate_special_chars(c);
+
 	while ((inb(IOBASE + 0x05) & 0x20) == 0) ;
 	outb(c, IOBASE);
 }
@@ -75,3 +97,38 @@
 	while (!serial_havechar()) ;
 	return (int)inb(IOBASE);
 }
+
+/*  These are thinly veiled vt100 functions used by curses */
+
+#define VT100_CLEAR       "\e[H\e[J"
+#define VT100_SBOLD       "\e[7m"
+#define VT100_EBOLD       "\e[m"
+#define VT100_CURSOR_ADDR "\e[%d;%dH"
+
+static void serial_putcmd(char *str)
+{
+	while(*str)
+		serial_putchar(*(str++));
+}
+
+void serial_clear(void)
+{
+	serial_putcmd(VT100_CLEAR);
+}
+
+void serial_start_bold(void)
+{
+	serial_putcmd(VT100_SBOLD);
+}
+
+void serial_end_bold(void)
+{
+	serial_putcmd(VT100_EBOLD);
+}
+
+void serial_set_cursor(int y, int x)
+{
+	char buffer[32];
+	snprintf(buffer, sizeof(buffer), VT100_CURSOR_ADDR, y, x);
+	serial_putcmd(buffer);
+}

Modified: trunk/payloads/libpayload/include/libpayload.h
===================================================================
--- trunk/payloads/libpayload/include/libpayload.h	2008-06-20 00:01:14 UTC (rev 3369)
+++ trunk/payloads/libpayload/include/libpayload.h	2008-06-20 00:01:42 UTC (rev 3370)
@@ -107,6 +107,11 @@
 int serial_havechar(void);
 int serial_getchar(void);
 
+void serial_clear(void);
+void serial_start_bold(void);
+void serial_end_bold(void);
+void serial_set_cursor(int y, int x);
+
 /* drivers/speaker.c */
 void speaker_enable(u16 freq);
 void speaker_disable(void);




From peter at stuge.se  Fri Jun 20 02:02:50 2008
From: peter at stuge.se (Peter Stuge)
Date: Fri, 20 Jun 2008 02:02:50 +0200
Subject: [coreboot] Patch to extend ROM decode range to 1MB for vt8237r
In-Reply-To: <485AD154.3010703@onelabs.com>
References: <485AD154.3010703@onelabs.com>
Message-ID: <20080620000250.30573.qmail@stuge.se>

On Thu, Jun 19, 2008 at 04:36:20PM -0500, bari wrote:
> This patch extends the VIA vt8237r southbridge decode range for the ROM 
> to 1MB.
> 
> Signed-off-by: Bari Ari <bari at onelabs.com>
> Acked-by: Peter Stuge <peter at stuge.se>

r3369



From svn at coreboot.org  Fri Jun 20 02:02:52 2008
From: svn at coreboot.org (svn at coreboot.org)
Date: Fri, 20 Jun 2008 02:02:52 +0200
Subject: [coreboot] r3371 - trunk/payloads/coreinfo
Message-ID: <mailman.1634.1355071333.16123.coreboot@coreboot.org>

Author: jcrouse
Date: 2008-06-20 02:02:52 +0200 (Fri, 20 Jun 2008)
New Revision: 3371

Modified:
   trunk/payloads/coreinfo/coreinfo.c
Log:
coreinfo:  Enable serial support

Remove the lines preventing serial + curses thanks to r3370. Trivial.

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



Modified: trunk/payloads/coreinfo/coreinfo.c
===================================================================
--- trunk/payloads/coreinfo/coreinfo.c	2008-06-20 00:01:42 UTC (rev 3370)
+++ trunk/payloads/coreinfo/coreinfo.c	2008-06-20 00:02:52 UTC (rev 3371)
@@ -269,9 +269,6 @@
 {
 	int i, j;
 
-	curses_enable_serial(0);
-	curses_enable_vga(1);
-
 	initscr();
 
 	init_pair(1, COLOR_WHITE, COLOR_GREEN);




From jordan.crouse at amd.com  Fri Jun 20 02:03:48 2008
From: jordan.crouse at amd.com (Jordan Crouse)
Date: Thu, 19 Jun 2008 18:03:48 -0600
Subject: [coreboot] libpayload: Support curses for serial
In-Reply-To: <13426df10806191521u46f1742cr24d10a030ece90db@mail.gmail.com>
References: <20080619221603.GF28880@cosmic.amd.com>
	<13426df10806191521u46f1742cr24d10a030ece90db@mail.gmail.com>
Message-ID: <20080620000348.GH28880@cosmic.amd.com>

On 19/06/08 15:21 -0700, ron minnich wrote:
> On Thu, Jun 19, 2008 at 3:16 PM, Jordan Crouse <jordan.crouse at amd.com> wrote:
> > Support curses over serial.  Tested with coreinfo over qemu, looks good.
> > I'm not sure what will happen when we actually get in front of a real
> > terminal emulator, but thats part of the fun.
> >
> > Jordan
> 
> Acked-by: Ronald G. Minnich<rminnich at gmail.com>

r3370.  Thanks.  And r3371 is the trivial patch to coreinfo to enable
serial there.

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




From ward at gnu.org  Fri Jun 20 02:24:23 2008
From: ward at gnu.org (Ward Vandewege)
Date: Thu, 19 Jun 2008 20:24:23 -0400
Subject: [coreboot] Bayou v0.3
In-Reply-To: <20080619224913.GG28880@cosmic.amd.com>
References: <20080619224913.GG28880@cosmic.amd.com>
Message-ID: <20080620002423.GA419@localdomain>

On Thu, Jun 19, 2008 at 04:49:13PM -0600, Jordan Crouse wrote:
> Greetings.  I am very happy to present to you the next version of the
> proof-of-concept for Bayou, the Coreboot payload chooser. A good amount
> of this version was re-written to support everybody's favorite feature:
> chaining! :)
> 
> Let me get the usual URLS out the way.  Source and QEMU demo:
> 
> http://www.coreboot.org/~jcrouse/bayou_0.3.tar.gz
> http://www.coreboot.org/~jcrouse/bayou-demo-20080619.rom
> 
> The default chain runs a password checker and then coreinfo.  If you 
> press escape before the timeout, you can run coreinfo directly from
> the menu, or run the default chain.  If you exit from coreinfo in
> the chain, you will go back to the menu automatically.
> 
> The "system password" is 'coreboot'.  My apologies to Uwe - I know he
> has a better password payload, but he is busy right now, and I needed
> to hack something together really quickly.  oh, and make sure you check
> it all out in serial too.. :)

Nice!! I tried the qemu serial, works fine. Backspace does not though?

Thanks,
Ward.

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



From svn at coreboot.org  Fri Jun 20 04:58:42 2008
From: svn at coreboot.org (svn at coreboot.org)
Date: Fri, 20 Jun 2008 04:58:42 +0200
Subject: [coreboot] r3372 - trunk/util/flashrom
Message-ID: <mailman.1635.1355071333.16123.coreboot@coreboot.org>

Author: stuge
Date: 2008-06-20 04:58:42 +0200 (Fri, 20 Jun 2008)
New Revision: 3372

Modified:
   trunk/util/flashrom/flashrom.c
Log:
flashrom: Show expected and read byte on verify failure. Trivial.

Signed-off-by: Peter Stuge <peter at stuge.se>
Acked-by: Peter Stuge <peter at stuge.se>


Modified: trunk/util/flashrom/flashrom.c
===================================================================
--- trunk/util/flashrom/flashrom.c	2008-06-20 00:02:52 UTC (rev 3371)
+++ trunk/util/flashrom/flashrom.c	2008-06-20 02:58:42 UTC (rev 3372)
@@ -187,7 +187,8 @@
 			if (verbose) {
 				printf("0x%08x ", idx);
 			}
-			printf("FAILED!\n");
+			printf("FAILED!  Expected=0x%02x, Read=0x%02x\n",
+				*(buf + idx), *(buf2 + idx));
 			return 1;
 		}
 




From zrfail at gmail.com  Fri Jun 20 05:01:14 2008
From: zrfail at gmail.com (Zhang Rui)
Date: Fri, 20 Jun 2008 11:01:14 +0800
Subject: [coreboot] Black window when running qemu with
	coreboot+LegacyBIOS
In-Reply-To: <20080619123929.GA7437@morn.localdomain>
References: <92cbc4c70806181829x67547e58pf4df99b2a72d241b@mail.gmail.com>
	<20080619014748.GA1344@morn.localdomain>
	<92cbc4c70806190100u47e07626mf433ebcb54197b8@mail.gmail.com>
	<20080619123929.GA7437@morn.localdomain>
Message-ID: <92cbc4c70806192001p1c4ccbfx5952683362efbd15@mail.gmail.com>

2008/6/19 Kevin O'Connor <kevin at koconnor.net>:
> Looks like a difference between our versions of 'ld'.  The build
> effectively does:
>
> ld -melf_i386 -e 0xf66e0 -Ttext 0xf0000 -b binary bios.bin -o bios.bin.elf

my ld version information:
[...]legacybios> ld --version
GNU ld version 2.16.91.0.5 20051219 (SUSE Linux)


> I'm not sure why it builds a different elf on your machine.  Can you
> try modifying tools/buildrom.py so that it uses "-Tdata" instead of
> "-Ttext"?
>
I get the right elf file after I executed:
        ld -melf_i386 -e 0xf66e0 -Tdata 0xf0000 -b binary bios.bin -o
bios.bin.elf

here is the elf information:
out/bios.bin.elf:     file format elf32-i386
out/bios.bin.elf
architecture: i386, flags 0x00000112:
EXEC_P, HAS_SYMS, D_PAGED
start address 0x000f66e0

Program Header:
    LOAD off    0x00001000 vaddr 0x000f0000 paddr 0x000f0000 align 2**12
         filesz 0x00010000 memsz 0x00010000 flags rw-

Sections:
Idx Name          Size      VMA       LMA       File off  Algn
  0 .data         00010000  000f0000  000f0000  00001000  2**0
                  CONTENTS, ALLOC, LOAD, DATA
SYMBOL TABLE:
000f0000 l    d  .data  00000000 .data
00000000 l    d  *ABS*  00000000 .shstrtab
00000000 l    d  *ABS*  00000000 .symtab
00000000 l    d  *ABS*  00000000 .strtab
00010000 g       *ABS*  00000000 _binary_out_bios_bin_size
00100000 g       *ABS*  00000000 __bss_start
00100000 g       .data  00000000 _binary_out_bios_bin_end
00100000 g       *ABS*  00000000 _edata
00100000 g       *ABS*  00000000 _end
000f0000 g       .data  00000000 _binary_out_bios_bin_start



And then I build it as payload of coreboot and then run qemu with coreboot.
I get the following messages in the console:

[...]
Stage2 code done.
LAR: Attempting to open 'normal/payload/segment0'.
LAR: Start 0xfffc0000 len 0x40000
LAR: seen member normal/option_table
LAR: seen member normal/initram/segment0
LAR: seen member normal/stage2/segment0
LAR: seen member normal/stage2/segment1
LAR: seen member normal/stage2/segment2
LAR: seen member normal/payload/segment0
LAR: CHECK normal/payload/segment0 @ 0xfffc43c0
start 0xfffc4410 len 20752 reallen 65536 compression 1 entry
0x000f66e0 loadaddress 0x000f0000
LAR: Compression algorithm #1 (lzma) used
LAR: Attempting to open 'normal/payload/segment1'.
LAR: Start 0xfffc0000 len 0x40000
LAR: seen member normal/option_table
LAR: seen member normal/initram/segment0
LAR: seen member normal/stage2/segment0
LAR: seen member normal/stage2/segment1
LAR: seen member normal/stage2/segment2
LAR: seen member normal/payload/segment0
LAR: seen member bootblock
LAR: File not found!
LAR: load_file: No such file 'normal/payload/segment1'
LAR: load_file_segments: All loaded, entry 0x000f66e0
Start bios
bios_table_addr: 0x000ff0a5 end=0x000ff841
ram_size=0x08000000
Scan for VGA option rom
Benter handle_10: a=00000e42 b=00000000 c=00000000 d=00000000
si=00000000 di=00000000
  ds=00000000 es=00000000 ip=0000e818 cs=0000f000 f=00000002 r=0000fca0
Ienter handle_10: a=00000e49 b=00000000 c=00000000 d=00000000
si=00000000 di=00000000
  ds=00000000 es=00000000 ip=0000e818 cs=0000f000 f=00000002 r=0000fca0
Oenter handle_10: a=00000e4f b=00000000 c=00000000 d=00000000
si=00000000 di=00000000
  ds=00000000 es=00000000 ip=0000e818 cs=0000f000 f=00000002 r=0000fca0
Senter handle_10: a=00000e53 b=00000000 c=00000000 d=00000000
si=00000000 di=00000000
  ds=00000000 es=00000000 ip=0000e818 cs=0000f000 f=00000002 r=0000fca0
 enter handle_10: a=00000e20 b=00000000 c=00000000 d=00000000
si=00000000 di=00000000

[...]

enter handle_10: a=00000e0d b=00000000 c=00000000 d=00000000
si=00000000 di=00000000
  ds=00000000 es=00000000 ip=0000e818 cs=0000f000 f=00000002 r=0000f664
enter handle_10: a=00000e0a b=00000000 c=00000000 d=00000000
si=00000000 di=00000000
  ds=00000000 es=00000000 ip=0000e818 cs=0000f000 f=00000002 r=0000f674
enter handle_18: NULL
No bootable device.

Is that OK?
Thanks for help. ^_^

Zhang Rui



From zrfail at gmail.com  Fri Jun 20 05:21:50 2008
From: zrfail at gmail.com (Zhang Rui)
Date: Fri, 20 Jun 2008 11:21:50 +0800
Subject: [coreboot] GSoC project(SCSI boot)__status report
In-Reply-To: <96ea9e59082d34e62343c21f5cb32fed@imap.1and1.com>
References: <92cbc4c70806020926i41b757c0ga661a3549c840be5@mail.gmail.com>
	<48584311.4060308@coresystems.de>
	<5291a56333627468cb118eda911dc2af@imap.1and1.com>
	<20080618025800.GA28799@morn.localdomain>
	<a7df9ffb104f47b43005b4b3d234abbc@imap.1and1.com>
	<48592987.9050708@amd.com>
	<92cbc4c70806181838x66d6e45dl6f287441838de26b@mail.gmail.com>
	<6F651D11120C4323B9E0DC329F4D0734@smitty2m>
	<92cbc4c70806190124v4422a1e4kd0302de3dd1df79@mail.gmail.com>
	<96ea9e59082d34e62343c21f5cb32fed@imap.1and1.com>
Message-ID: <92cbc4c70806192021g180ff350m3097e90f189cd53e@mail.gmail.com>

2008/6/20 Joseph Smith <joe at settoplinux.org>:
> I don't think so, I am excited to try it out once you are finished.
> Although I am using IDE instead of SCSI.
> Sorry if I sound like a broken record, the main thing to remember is we
> need to make all the LegacyBIOS code that is getting injected into the
> coreboot base code optional, hence the "if option LegacyBIOS is selected".
> There are alot of people sensative about this, and we need to keep coreboot
> flexible and make everyone happy, right?
>
OK, I will keep "making LegacyBIOS code optional" in my mind.
May be a choice in the menuconfig is suitable?
I will implement this option after I finished the SCSI booting functionality.
Is this OK?

And another question, LegacyBIOS is not in the coreboot base code now
and where should we put it? Maybe in the util/LegacyBIOS?



From dpchrist at holgerdanske.com  Fri Jun 20 06:58:46 2008
From: dpchrist at holgerdanske.com (David Christensen)
Date: Thu, 19 Jun 2008 21:58:46 -0700
Subject: [coreboot] What are the best motherboards/systems out there for
	open-source software?
Message-ID: <BF50B61B20664C3496BE33D55D1C7002@a64x23800p>

coreboot:

I am researching parts to build a new open-source desktop system, and came
across coreboot tonight.


I have heard of open-source projects to implement x86 BIOS, but have always
wondered how they fared given the fact that most motherboard vendors and chip
vendors consider their products confidential intellectual property and won't
provide technical documentation necessary for software development without an
contract (NDA, etc.).


Are there any modern x86 motherboards and/or systems currently available for
which technical documents are available for the motherboard and everything on
it?


Are matters better or worse for alternate architectures?


David




From svn at coreboot.org  Fri Jun 20 19:32:10 2008
From: svn at coreboot.org (svn at coreboot.org)
Date: Fri, 20 Jun 2008 19:32:10 +0200
Subject: [coreboot] r204 - buildrom-devel/packages/coreinfo
Message-ID: <mailman.1636.1355071333.16123.coreboot@coreboot.org>

Author: jcrouse
Date: 2008-06-20 19:32:10 +0200 (Fri, 20 Jun 2008)
New Revision: 204

Modified:
   buildrom-devel/packages/coreinfo/coreinfo.mk
Log:
Bump coreinfo to the latest version to get curses + serial support.
Trivial.

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


Modified: buildrom-devel/packages/coreinfo/coreinfo.mk
===================================================================
--- buildrom-devel/packages/coreinfo/coreinfo.mk	2008-06-17 16:38:56 UTC (rev 203)
+++ buildrom-devel/packages/coreinfo/coreinfo.mk	2008-06-20 17:32:10 UTC (rev 204)
@@ -1,5 +1,5 @@
 COREINFO_URL=svn://coreboot.org/repos/trunk/payloads/coreinfo
-COREINFO_TAG=3289
+COREINFO_TAG=3372
 
 COREINFO_DIR=$(BUILD_DIR)/coreinfo
 COREINFO_SRC_DIR=$(COREINFO_DIR)/svn




From svn at coreboot.org  Fri Jun 20 22:49:00 2008
From: svn at coreboot.org (svn at coreboot.org)
Date: Fri, 20 Jun 2008 22:49:00 +0200
Subject: [coreboot] r205 - buildrom-devel/packages/memtest
Message-ID: <mailman.1637.1355071333.16123.coreboot@coreboot.org>

Author: jcrouse
Date: 2008-06-20 22:49:00 +0200 (Fri, 20 Jun 2008)
New Revision: 205

Modified:
   buildrom-devel/packages/memtest/memtest.mk
Log:
memtest-3.4 breaks badly on coreboot - we don't know why.  Revert back
to last known working version (3.3).  Trivial yet critical. :)

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


Modified: buildrom-devel/packages/memtest/memtest.mk
===================================================================
--- buildrom-devel/packages/memtest/memtest.mk	2008-06-20 17:32:10 UTC (rev 204)
+++ buildrom-devel/packages/memtest/memtest.mk	2008-06-20 20:49:00 UTC (rev 205)
@@ -1,7 +1,7 @@
 MEMTEST_URL=http://www.memtest86.com/
-MEMTEST_SOURCE=memtest86-3.4.tar.gz
+MEMTEST_SOURCE=memtest86-3.3.tar.gz
 MEMTEST_DIR=$(BUILD_DIR)/memtest
-MEMTEST_SRC_DIR=$(MEMTEST_DIR)/memtest86-3.4
+MEMTEST_SRC_DIR=$(MEMTEST_DIR)/memtest86-3.3
 MEMTEST_STAMP_DIR=$(MEMTEST_DIR)/stamps
 MEMTEST_LOG_DIR=$(MEMTEST_DIR)/logs
 




From Ken.Fuchs at bench.com  Fri Jun 20 19:28:03 2008
From: Ken.Fuchs at bench.com (Ken.Fuchs at bench.com)
Date: Fri, 20 Jun 2008 12:28:03 -0500
Subject: [coreboot] What are the best motherboards/systems out there
	foropen-source software?
In-Reply-To: <BF50B61B20664C3496BE33D55D1C7002@a64x23800p>
Message-ID: <AA28F077645B324881335614E4F7C4284A4935@win-ex01.bench.com>

David Christensen wrote:

> coreboot:
> 
> I am researching parts to build a new open-source desktop 
> system, and came across coreboot tonight.
> 
> I have heard of open-source projects to implement x86 BIOS, 
> but have always wondered how they fared given the fact
> that most motherboard vendors and chip vendors consider
> their products confidential intellectual property and won't
> provide technical documentation necessary for software 
> development without an contract (NDA, etc.).

Just to be clear, NDA is short for Non-Disclosure Agreement.
There is no standard NDA; even the same company will have
a different NDA for a different purpose.  An NDA will often
list exactly what will be shared and protected, but often
companies will want this list to be very general so that
almost anything shared that was not previously shared by
legal means will be protected by the terms of the NDA.

Some companies will provide enough information about their
boards, processors, chipsets, ancillary chips and embedded
controllers with or without an NDA.  With an NDA in place,
they will often want to review code based on an open source
project (i.e. coreboot), before allowing it to be publicly
released.  There may be a few companies that are resistant
to any open source BIOS and may not agree to an NDA for
that purpose, but I know of no such case yet.  Companies
will tend to do what is best for their bottom line; we just
need to convince them that an Open BIOS/firmware like
coreboot will help them improve their bottom line.

When a company is resistant to releasing technical information
even with an NDA or the prospect of getting approval to release
source created via NDA protected information is doubtful, there
is the option of reverse engineering the technical information
via JTAG debuggers, logical analyzers and similar tools.
Of course this is only an option for those that do not sign
any relevant NDA.  Also, care must be taken to ensure that the
reverse engineering activities do not violate any applicable
laws.

> Are there any modern x86 motherboards and/or systems 
> currently available for which technical documents are
> available for the motherboard and everything on it?

I'm not aware of any x86 main boards with complete technical
information that are available without signing an NDA.  Some
that may come close would be on the coreboot main board list,
but some of these may have been developed under NDA, which
means the only public technical information available may be
the approved & released chipset-specific, coreboot source code
itself:

http://www.coreboot.org/Supported_Motherboards

Perhaps, someone else is aware of such a board with complete
publicly available technical information, including full
schematics and BOM?

> Are matters better or worse for alternate architectures?

The situation for non-x86 processors is much better.  U-Boot
seems to support almost any non-x86 based board that exists.
If a board is not supported, its architecture often is supported
and thus a port U-Boot to it is usually quite easy to do.

In my opinion, U-Boot's non-x86 firmware market share is so high
that embedded board designers ignore U-Boot at the own peril.
This is especially true of architectures that MS Windows CE does
_not_ support.  (CE supports only x86, MIPS, ARM and SuperH where
ARM is the only one that is really significant; CE's bootloader
Eboot is really a joke compared to the power of U-Boot in any
case.)

http://www.denx.de/wiki/UBoot

Sincerely,

Ken Fuchs



From rminnich at gmail.com  Fri Jun 20 17:04:20 2008
From: rminnich at gmail.com (ron minnich)
Date: Fri, 20 Jun 2008 09:04:20 -0600
Subject: [coreboot] libpayload: Support curses for serial
In-Reply-To: <20080620000348.GH28880@cosmic.amd.com>
References: <20080619221603.GF28880@cosmic.amd.com>
	<13426df10806191521u46f1742cr24d10a030ece90db@mail.gmail.com>
	<20080620000348.GH28880@cosmic.amd.com>
Message-ID: <13426df10806200804u4cbc7c21od59b683cbba625@mail.gmail.com>

screenshots!

we need bayou screenshots on wiki!

bayou is the wonder of the age, IMHO. I'm serious. I don't see
anything like it anywhere. Imagine, an intuitive payload chooser in
the bios. Just look what the mac puts you through in contrast.

ron



From peter at stuge.se  Fri Jun 20 15:04:26 2008
From: peter at stuge.se (Peter Stuge)
Date: Fri, 20 Jun 2008 15:04:26 +0200
Subject: [coreboot] What are the best motherboards/systems out there for
	open-source software?
In-Reply-To: <BF50B61B20664C3496BE33D55D1C7002@a64x23800p>
References: <BF50B61B20664C3496BE33D55D1C7002@a64x23800p>
Message-ID: <20080620130426.3056.qmail@stuge.se>

Hello David,

On Thu, Jun 19, 2008 at 09:58:46PM -0700, David Christensen wrote:
> Are there any modern x86 motherboards and/or systems currently
> available for which technical documents are available for the
> motherboard and everything on it?

My favorite is the GIGABYTE GA-M57SLI-S4 with AM2 socket. It is
supported in coreboot and it's also possible to put an extra flash
chip on the board to be able to experiment with coreboot without
fear of bricking the board.

My company sells such modified boards, but unfortunately I am not
able to sell directly to consumers in Denmark (but businesses is
OK) because of EU environmental regulations. :\ I don't have
resources to register in every member state's producer registry.


//Peter



From jordan.crouse at amd.com  Fri Jun 20 17:06:25 2008
From: jordan.crouse at amd.com (Jordan Crouse)
Date: Fri, 20 Jun 2008 09:06:25 -0600
Subject: [coreboot] Bayou v0.3
In-Reply-To: <20080620002423.GA419@localdomain>
References: <20080619224913.GG28880@cosmic.amd.com>
	<20080620002423.GA419@localdomain>
Message-ID: <20080620150625.GA28462@cosmic.amd.com>

On 19/06/08 20:24 -0400, Ward Vandewege wrote:
> On Thu, Jun 19, 2008 at 04:49:13PM -0600, Jordan Crouse wrote:
> > Greetings.  I am very happy to present to you the next version of the
> > proof-of-concept for Bayou, the Coreboot payload chooser. A good amount
> > of this version was re-written to support everybody's favorite feature:
> > chaining! :)
> > 
> > Let me get the usual URLS out the way.  Source and QEMU demo:
> > 
> > http://www.coreboot.org/~jcrouse/bayou_0.3.tar.gz
> > http://www.coreboot.org/~jcrouse/bayou-demo-20080619.rom
> > 
> > The default chain runs a password checker and then coreinfo.  If you 
> > press escape before the timeout, you can run coreinfo directly from
> > the menu, or run the default chain.  If you exit from coreinfo in
> > the chain, you will go back to the menu automatically.
> > 
> > The "system password" is 'coreboot'.  My apologies to Uwe - I know he
> > has a better password payload, but he is busy right now, and I needed
> > to hack something together really quickly.  oh, and make sure you check
> > it all out in serial too.. :)
> 
> Nice!! I tried the qemu serial, works fine. Backspace does not though?

Yeah, I saw that literally seconds after checking it in.  I'll look at it
today.

Jordan

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




From Ken.Fuchs at bench.com  Sat Jun 21 00:11:21 2008
From: Ken.Fuchs at bench.com (Ken.Fuchs at bench.com)
Date: Fri, 20 Jun 2008 17:11:21 -0500
Subject: [coreboot] coreboot and U-Boot: a comparison
Message-ID: <AA28F077645B324881335614E4F7C4284A4937@win-ex01.bench.com>

Having worked in a non-trivial way with both LinuxBIOS code and
U-Boot code, I can make a fair comparison of coreboot and U-Boot.

I wish coreboot was as dominant in the x86 market as U-Boot is
in the non-x86 market.  There appear to be several reasons:

1) Technical information flows very freely in the non-x86 market.
2) U-Boot has official stable releases and coreboot doesn't.
3) Das U-Boot had a very early name change from PPCBoot when it
   added non-PPC processor support.  LinuxBIOS had a recent name
   change to coreboot, but that was a huge mistake.  More people
   know about LinuxBIOS that disappeared than know about coreboot.
4) In the non-x86 market, the processor often includes all I/O
   controllers needed by the application.  Often a designer just
   needs to pick the processor variant that contains all the
   I/O controllers he needs.  No chipsets and often no external
   I/O controllers are required for the design.
5) No IBVs (Independent BIOS Vendors = AMI, Phoenix, Insyde,
   General Software, etc.) that dominate (monopolize) the market
   with proprietary firmware/BIOS "solutions".
6) Much of the U-Boot code, especially its device drivers come
   from the corresponding device drivers in the Linux kernel.
7) There seems to be more active development on U-Boot than on
   coreboot based on the activity of their respective mailing
   lists.
8) U-Boot now has architecture specific git repositories for
   active development available via http protocol that passes
   through most firewalls transparently.  coreboot has a
   single SVN repository that seems to be accessible only
   via the svn protocol which requires that the svn port
   be open on the firewall which is often impossible to get
   approved, since it is a "non-standard" port.

Whether or not you agree with all of these reasons, something
can be done about all of them to varying degrees, ranging from
nothing to completely fixing it.

Sincerely,

Ken Fuchs




From Ken.Fuchs at bench.com  Fri Jun 20 23:40:15 2008
From: Ken.Fuchs at bench.com (Ken.Fuchs at bench.com)
Date: Fri, 20 Jun 2008 16:40:15 -0500
Subject: [coreboot] coreboot and embedded controllers;
	for example OLPC and its OpenEC code
In-Reply-To: <20080619211753.GD28880@cosmic.amd.com>
Message-ID: <AA28F077645B324881335614E4F7C4284A4936@win-ex01.bench.com>

To simplify the discussion, let's restrict EC to those
used in laptops.  Here is a description of the embedded
controller paragraph in the OLPC from the URI
http://wiki.laptop.org/go/Power_Management.

Assuming the specific processor and embedded controller
could be replaced by others, this is the definition of
an embedded controller that coreboot must deal with to be
taken seriously in the laptop or mobile computing markets:

>  Embedded controller
>
> The embedded controller, an ENE KB3700: Image:KB3700-ds-01.pdf,
> is used to charge the battery, emulate various legacy devices
> (e.g. PS/2), add more GPIO pins (since the Geode does not have
> enough pins, some signals have to be routed through the EC),
> boot the system (the SPI flash used to store the firmware is a
> serial ROM attached to the EC), wake up the system under
> various circumstances, and other miscellaneous functions.  The
> EC specification contains detailed information about the
> commands and protocol used to communicate with the EC. A number
> of buttons (game pad and buttons, etc.), are interfaced to the
> EC, and also generate scan codes as though they were keyboard
> keys, to simplify the programming interface. SCI events are
> also generated at times to inform the CPU of events, so that
> the XO-1 can avoid polling interfaces that would otherwise
> require periodic wake ups.
>
> See also OpenEC

Note that such an EC will be running prior to the processor.
As stated above it monitors several devices, processor and
board signals and activates some in response.  It may also
have about a hundred processor initiated commands that it
executes (http://wiki.laptop.org/go/Ec_specification).

------

> > > Jordan Crouse wrote:
> > > > When done right, the embedded controller will be transparent to
> > > > coreboot.
> > 
> > How common is that in your experience?

Jordan Crouse wrote:
 
> Very common.  But I have to qualify my answer - when I say 
> transparent, 
> I don't mean that there might not be special registers implemented
> by the embedded controller for that particular platform.
> 
> What I mean by "transparent" is that it shouldn't matter to coreboot
> if the embedded controller is running OpenEC or a proprietary version.
> It should look and feel the same.

It might be possible that coreboot can avoid accessing the EC
in the case that nothing needs to be initialized after a power
on/reset event until the payload is loaded.  However, coreboot's
payload at a very minimum must be able to handle the EC and the
EC's devices.

When the power button is pressed, the EC will turn on the
appropriate power planes, wait for while, release the processor
from reset.  Next, the EC will wait for an LPC read, access its
SPI NOR flash for the required data and place the data on the
LPC bus and repeat.  coreboot may need to communicate with the
EC to initialize devices it controls.  When the firmware boot
completes, it may be necessary to command the EC to go into
a run mode.  Note that we may have to deal with poorly
designed/implemented proprietary EC code, so some unnecessary
handshaking between the processor and the EC may be required.

> > On Thu, Jun 19, 2008 at 03:55:53PM -0500, bari wrote:
> > >
> > > To develop open firmware for embedded controllers that oem's and
> > > odm's will use in new designs in the future?
> > > 
> > > I understand why someone that enjoys tinkering with laptops and
> > > servers might like this. I'm not sure that the odm's and 
> > > oem's will
> > > be interested in an open solution unless it is very 
> > > stable and very
> > > well supported.

I agree that the EC code must be extremely stable, since it
must handle many critical laptop devices like SPI NOR flash,
power management (sleep/standby/resume), battery charging/status,
and maybe thermal management, in addition to the non-critical
PS/2 and keyboard devices.

For laptops, ODMs like Quanta are exactly the companies that
must be convinced that open source EC code is better than IBV
written EC code.

Why is open source EC code important for coreboot?  Well, for
all mainboards with an embedded controller, coreboot with an
appropriate payload(s) would not constitute a complete open
source BIOS/firmware when the EC still contains proprietary
code.

> On 19/06/08 23:07 +0200, Peter Stuge wrote:
> > 
> > Well there's still the binary blob problem.
> > 
> > If the EC has it's own firmware then coreboot just needs to know how
> > to cooperate with it, but for ones where EC firmware is 
> stored in the
> > BIOS flash - there's a bit of a problem with coreboot..
> 
> Let us be careful with definitions.  None of these things are problems
> with the coreboot code itself, but rather with the management of the
> ROM in general.  And yes, we have problems with figuring out ROM
> partitioning and management, but we are working on those.

I'm not sure it is that clear cut.  If a mainboard contains
an EC (open source or proprietary), coreboot may have to
handle it similar to any other ancillary chip (such as a
SuperIO) that is required to boot.  It could be something
that can be delayed and handled later by a payload, but the
EC may not necessarily be ignored by coreboot without at
least some lost of functionality.

------

OpenFirmware & OLPC:

I heard that LinuxBIOS was replaced by Firmworks' OpenFirmware
due to the resume being too slow.  Here's an interesting
interview with Firmworks' Mitch Bradley that is primarily
about the OLPC and firmware, but doesn't say much about the
EC code, expect that it was proprietary and the source of
many problems that were far more difficult simply because
the EC source code was closed.

http://howsoftwareisbuilt.com/2008/03/27/interview-with-mitch-bradley-fi
rmware-olpc/

I highly recommend this interview, especially starting with
the first question regarding OLPC through the end.

Sincerely,

Ken Fuchs



From Ken.Fuchs at bench.com  Sat Jun 21 00:30:44 2008
From: Ken.Fuchs at bench.com (Ken.Fuchs at bench.com)
Date: Fri, 20 Jun 2008 17:30:44 -0500
Subject: [coreboot] [RFC] coreboot Live CD
Message-ID: <AA28F077645B324881335614E4F7C4284A4939@win-ex01.bench.com>

The main problem with LinuxBIOS/coreboot is the lack
of stable releases.

When coreboot gets a stable release or at least a
stable snapshot, it would be nice to add the source
code to a Live CD with the proper toolchain.

Another problem with LinuxBIOS and now with coreboot
is all the mainboards I tried to build or the even
the payloads would never compile without some serious
errors.  Hopefully, a validated coreboot Live CD
would solve this problem and increase exposure of
coreboot at the same time.

Sincerely,

Ken Fuchs



From joe at settoplinux.org  Fri Jun 20 22:06:55 2008
From: joe at settoplinux.org (Joseph Smith)
Date: Fri, 20 Jun 2008 16:06:55 -0400
Subject: [coreboot] test
Message-ID: <ab5efb84f7e54259d6318bd9e95bfe2f@imap.1and1.com>



-- 
Thanks,
Joseph Smith
Set-Top-Linux
www.settoplinux.org




From rminnich at gmail.com  Sat Jun 21 00:49:38 2008
From: rminnich at gmail.com (ron minnich)
Date: Fri, 20 Jun 2008 16:49:38 -0600
Subject: [coreboot] coreboot and U-Boot: a comparison
In-Reply-To: <AA28F077645B324881335614E4F7C4284A4937@win-ex01.bench.com>
References: <AA28F077645B324881335614E4F7C4284A4937@win-ex01.bench.com>
Message-ID: <13426df10806201549r252d0fcfm15592a6152517c0b@mail.gmail.com>

On Fri, Jun 20, 2008 at 4:11 PM,  <Ken.Fuchs at bench.com> wrote:
> Having worked in a non-trivial way with both LinuxBIOS code and
> U-Boot code, I can make a fair comparison of coreboot and U-Boot.
>
> I wish coreboot was as dominant in the x86 market as U-Boot is
> in the non-x86 market.  There appear to be several reasons:
>
> 1) Technical information flows very freely in the non-x86 market.

A really big problem for us, and getting *worse* in some cases.

Also, I've been through all the platforms U-boot supports (admittedly,
a while ago). They are *easy*
to write to compared to the stuff we deal with. That's been a factor
in our ability to ship stable releases.

A big problem is the hostilty that one big x86 mover and shaker has
shown to this project over the last 6 years. It's made life hard, what
with the continuous FUD.

> 2) U-Boot has official stable releases and coreboot doesn't.

What can this even mean? I've looked at the code too and used it. I
don't know if I believe that
for a given stable release, every single platform in the release works
perfectly. We've gone with stable
release per platform, via saying "this svn rev for this platform".
Anything else has proven very hard.

> 3) Das U-Boot had a very early name change from PPCBoot when it
>   added non-PPC processor support.  LinuxBIOS had a recent name
>   change to coreboot, but that was a huge mistake.  More people
>   know about LinuxBIOS that disappeared than know about coreboot.

Let's not talk about the name please. There has been too much on this
already. The change was done, it's over, let's move on. Trust me, I'm
well aware of the brand equity we lost with the name change. It will
take years to get it back. But we had a lot of insistence from many
quarters.

> 4) In the non-x86 market, the processor often includes all I/O
>   controllers needed by the application.  Often a designer just
>   needs to pick the processor variant that contains all the
>   I/O controllers he needs.  No chipsets and often no external
>   I/O controllers are required for the design.

Like I said, the non-x86 market is really a good deal easier than ours.

> 6) Much of the U-Boot code, especially its device drivers come
>   from the corresponding device drivers in the Linux kernel.

There's no need for "drivers" in LB, that's the whole point. This is
actually a negative IMHO for
U-boot -- way more software bits than we have.

> 7) There seems to be more active development on U-Boot than on
>   coreboot based on the activity of their respective mailing
>   lists.

Almost certainly true. U-boot is good stuff, and is a de-facto
standard in the ARM and PPC world. They've
done a great job. Why that one company wants UEFI for ARM is totally
baffling. They've got u-boot; why wreck such a a good thing? That has
to be a Pointy-Haired Boss decision.

> 8) U-Boot now has architecture specific git repositories for
>   active development available via http protocol that passes
>   through most firewalls transparently.  coreboot has a
>   single SVN repository that seems to be accessible only
>   via the svn protocol which requires that the svn port
>   be open on the firewall which is often impossible to get
>   approved, since it is a "non-standard" port.

ah, git. Love it or hate it. I know people who have used it and now
stopped. We had a truly terrible experience with LB and arch years
ago, and the SCM question is a sensitive one. I have had people tell
me "move to git" and others tell me "please please DON'T EVER MOVE TO
GIT".

that's a tough one.

ron



From rminnich at gmail.com  Sat Jun 21 00:50:24 2008
From: rminnich at gmail.com (ron minnich)
Date: Fri, 20 Jun 2008 16:50:24 -0600
Subject: [coreboot] [RFC] coreboot Live CD
In-Reply-To: <AA28F077645B324881335614E4F7C4284A4939@win-ex01.bench.com>
References: <AA28F077645B324881335614E4F7C4284A4939@win-ex01.bench.com>
Message-ID: <13426df10806201550r49073f37x2c70d6157db17d56@mail.gmail.com>

On Fri, Jun 20, 2008 at 4:30 PM,  <Ken.Fuchs at bench.com> wrote:
>
> Another problem with LinuxBIOS and now with coreboot
> is all the mainboards I tried to build or the even
> the payloads would never compile without some serious
> errors.  Hopefully, a validated coreboot Live CD
> would solve this problem and increase exposure of
> coreboot at the same time.

Ken, no offense intended, but this is a vacuous comment absent logs of
failed builds. But we'd love to see them.

thanks

ron



From jordan.crouse at amd.com  Sat Jun 21 00:53:25 2008
From: jordan.crouse at amd.com (Jordan Crouse)
Date: Fri, 20 Jun 2008 16:53:25 -0600
Subject: [coreboot] libpayload: Support curses for serial
In-Reply-To: <13426df10806200804u4cbc7c21od59b683cbba625@mail.gmail.com>
References: <20080619221603.GF28880@cosmic.amd.com>
	<13426df10806191521u46f1742cr24d10a030ece90db@mail.gmail.com>
	<20080620000348.GH28880@cosmic.amd.com>
	<13426df10806200804u4cbc7c21od59b683cbba625@mail.gmail.com>
Message-ID: <20080620225325.GA8459@cosmic.amd.com>

On 20/06/08 09:04 -0600, ron minnich wrote:
> screenshots!
> 
> we need bayou screenshots on wiki!

Done:
http://www.coreboot.org/Bayou

Jordan

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




From kevin at koconnor.net  Fri Jun 20 14:56:46 2008
From: kevin at koconnor.net (Kevin O'Connor)
Date: Fri, 20 Jun 2008 08:56:46 -0400
Subject: [coreboot] Black window when running qemu
	with	coreboot+LegacyBIOS
In-Reply-To: <92cbc4c70806192001p1c4ccbfx5952683362efbd15@mail.gmail.com>
References: <92cbc4c70806181829x67547e58pf4df99b2a72d241b@mail.gmail.com>
	<20080619014748.GA1344@morn.localdomain>
	<92cbc4c70806190100u47e07626mf433ebcb54197b8@mail.gmail.com>
	<20080619123929.GA7437@morn.localdomain>
	<92cbc4c70806192001p1c4ccbfx5952683362efbd15@mail.gmail.com>
Message-ID: <20080620125646.GA19607@morn.localdomain>

On Fri, Jun 20, 2008 at 11:01:14AM +0800, Zhang Rui wrote:
> 2008/6/19 Kevin O'Connor <kevin at koconnor.net>:
> I get the right elf file after I executed:
>         ld -melf_i386 -e 0xf66e0 -Tdata 0xf0000 -b binary bios.bin -o
> bios.bin.elf

Okay, thanks.  I've checked this change into latest git.

> And then I build it as payload of coreboot and then run qemu with coreboot.
> I get the following messages in the console:
> 
> [...]
> enter handle_10: a=00000e0a b=00000000 c=00000000 d=00000000
> si=00000000 di=00000000
>   ds=00000000 es=00000000 ip=0000e818 cs=0000f000 f=00000002 r=0000f674
> enter handle_18: NULL
> No bootable device.
> 
> Is that OK?

You have succesfully launched LegacyBIOS.  However, the vga rom was
not found.  Make sure you're running with the latest vgabios.  Also,
you probably haven't specified a floppy, hard drive, or cdrom to boot
from.

-Kevin



From jordan.crouse at amd.com  Sat Jun 21 01:11:28 2008
From: jordan.crouse at amd.com (Jordan Crouse)
Date: Fri, 20 Jun 2008 17:11:28 -0600
Subject: [coreboot] Black window when running qemu with
	coreboot+LegacyBIOS
In-Reply-To: <20080620125646.GA19607@morn.localdomain>
References: <92cbc4c70806181829x67547e58pf4df99b2a72d241b@mail.gmail.com>
	<20080619014748.GA1344@morn.localdomain>
	<92cbc4c70806190100u47e07626mf433ebcb54197b8@mail.gmail.com>
	<20080619123929.GA7437@morn.localdomain>
	<92cbc4c70806192001p1c4ccbfx5952683362efbd15@mail.gmail.com>
	<20080620125646.GA19607@morn.localdomain>
Message-ID: <20080620231128.GA8661@cosmic.amd.com>

On 20/06/08 08:56 -0400, Kevin O'Connor wrote:
> On Fri, Jun 20, 2008 at 11:01:14AM +0800, Zhang Rui wrote:
> > 2008/6/19 Kevin O'Connor <kevin at koconnor.net>:
> > I get the right elf file after I executed:
> >         ld -melf_i386 -e 0xf66e0 -Tdata 0xf0000 -b binary bios.bin -o
> > bios.bin.elf
> 
> Okay, thanks.  I've checked this change into latest git.
> 
> > And then I build it as payload of coreboot and then run qemu with coreboot.
> > I get the following messages in the console:
> > 
> > [...]
> > enter handle_10: a=00000e0a b=00000000 c=00000000 d=00000000
> > si=00000000 di=00000000
> >   ds=00000000 es=00000000 ip=0000e818 cs=0000f000 f=00000002 r=0000f674
> > enter handle_18: NULL
> > No bootable device.
> > 
> > Is that OK?
> 
> You have succesfully launched LegacyBIOS.  However, the vga rom was
> not found.  Make sure you're running with the latest vgabios.  Also,
> you probably haven't specified a floppy, hard drive, or cdrom to boot
> from.

We should discuss what needs to be done to bring this goodness to buildrom.

Jordan

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




From joe at settoplinux.org  Sat Jun 21 01:45:47 2008
From: joe at settoplinux.org (Joseph Smith)
Date: Fri, 20 Jun 2008 19:45:47 -0400
Subject: [coreboot] libpayload: Support curses for serial
In-Reply-To: <20080620225325.GA8459@cosmic.amd.com>
References: <20080619221603.GF28880@cosmic.amd.com>
	<13426df10806191521u46f1742cr24d10a030ece90db@mail.gmail.com>
	<20080620000348.GH28880@cosmic.amd.com>
	<13426df10806200804u4cbc7c21od59b683cbba625@mail.gmail.com>
	<20080620225325.GA8459@cosmic.amd.com>
Message-ID: <2a105b58558b8554785bfee1c6af9dc3@imap.1and1.com>




On Fri, 20 Jun 2008 16:53:25 -0600, Jordan Crouse <jordan.crouse at amd.com>
wrote:
> On 20/06/08 09:04 -0600, ron minnich wrote:
>> screenshots!
>>
>> we need bayou screenshots on wiki!
> 
> Done:
> http://www.coreboot.org/Bayou
> 
> Jordan
> 
SWEET!! That looks great Jordan, keep up the great work:-)
-- 
Thanks,
Joseph Smith
Set-Top-Linux
www.settoplinux.org




From joe at settoplinux.org  Sat Jun 21 02:02:59 2008
From: joe at settoplinux.org (Joseph Smith)
Date: Fri, 20 Jun 2008 20:02:59 -0400
Subject: [coreboot]
	=?utf-8?q?GSoC_project=28SCSI_boot=29=5F=5Fstatus_repo?=
	=?utf-8?q?rt?=
In-Reply-To: <92cbc4c70806192021g180ff350m3097e90f189cd53e@mail.gmail.com>
References: <92cbc4c70806020926i41b757c0ga661a3549c840be5@mail.gmail.com>
	<48584311.4060308@coresystems.de>
	<5291a56333627468cb118eda911dc2af@imap.1and1.com>
	<20080618025800.GA28799@morn.localdomain>
	<a7df9ffb104f47b43005b4b3d234abbc@imap.1and1.com>
	<48592987.9050708@amd.com>
	<92cbc4c70806181838x66d6e45dl6f287441838de26b@mail.gmail.com>
	<6F651D11120C4323B9E0DC329F4D0734@smitty2m>
	<92cbc4c70806190124v4422a1e4kd0302de3dd1df79@mail.gmail.com>
	<96ea9e59082d34e62343c21f5cb32fed@imap.1and1.com>
	<92cbc4c70806192021g180ff350m3097e90f189cd53e@mail.gmail.com>
Message-ID: <270ad02a8e614fd766c6ad175c568751@imap.1and1.com>




On Fri, 20 Jun 2008 11:21:50 +0800, "Zhang Rui" <zrfail at gmail.com> wrote:
> 2008/6/20 Joseph Smith <joe at settoplinux.org>:
>> I don't think so, I am excited to try it out once you are finished.
>> Although I am using IDE instead of SCSI.
>> Sorry if I sound like a broken record, the main thing to remember is we
>> need to make all the LegacyBIOS code that is getting injected into the
>> coreboot base code optional, hence the "if option LegacyBIOS is
> selected".
>> There are alot of people sensative about this, and we need to keep
> coreboot
>> flexible and make everyone happy, right?
>>
> OK, I will keep "making LegacyBIOS code optional" in my mind.
> May be a choice in the menuconfig is suitable?
> I will implement this option after I finished the SCSI booting
> functionality.
> Is this OK?
Sure
> 

For v3 you could probably just use the menuconfig. I haven't played around
with v3 yet, so someone else would probably be better to answer that.

For v2 use a global option in Option.lb, something like:

uses USE_LEGACYBIOS
##
## Build code for LegacyBIOS support
## 0 = disabled, 1 = enabled
##
default USE_LEGACYBIOS = 1

and then before and after your code use a preprocessing directive:

#if USE_LEGACYBIOS

Insert LegacyBIOS code here

#endif

> And another question, LegacyBIOS is not in the coreboot base code now
> and where should we put it? Maybe in the util/LegacyBIOS?
> 
This would be a good question for Kevin

Hope that helps:-)

-- 
Thanks,
Joseph Smith
Set-Top-Linux
www.settoplinux.org




From joe at settoplinux.org  Sat Jun 21 02:05:04 2008
From: joe at settoplinux.org (Joseph Smith)
Date: Fri, 20 Jun 2008 20:05:04 -0400
Subject: [coreboot] Thomson IP1000's for sale
Message-ID: <63045b3c64572a76890e61d5b3ae1ee6@imap.1and1.com>


Hello,

In case anyone wanted to play with coreboot and the Thomson IP1000, and
possibly help me with some development, there are a few for sale on eBay
fairly cheap. Just an FYI in case your interested:

http://search.ebay.com/search/search.dll?from=R40&_trksid=m37&satitle=TELUS+TV+

-- 
Thanks,
Joseph Smith
Set-Top-Linux
www.settoplinux.org




From tiagomnm at gmail.com  Sat Jun 21 02:09:11 2008
From: tiagomnm at gmail.com (Tiago Marques)
Date: Sat, 21 Jun 2008 01:09:11 +0100
Subject: [coreboot] flashrom verify fails, CK804, MCP55
In-Reply-To: <48484A0D.8040706@gmx.net>
References: <b1335fe90801270721i49a29a58v6ee03b9d5a9037f0@mail.gmail.com>
	<20080127181124.GA23002@localdomain>
	<b1335fe90801271119h5af39e2el388df1785d21e015@mail.gmail.com>
	<20080127194808.GA23518@localdomain>
	<b1335fe90801271233p149cccc9k3a60f165ab01fe0c@mail.gmail.com>
	<b1335fe90801290959r6f65c208na74badb4dac9aa@mail.gmail.com>
	<47AC6B27.6040708@gmx.net>
	<b1335fe90806010809r3eadbf71lb17ab1126906cc7d@mail.gmail.com>
	<b1335fe90806051259g7bf14951ybcca4985761a836b@mail.gmail.com>
	<48484A0D.8040706@gmx.net>
Message-ID: <b1335fe90806201709i2483e5fofb14360e96930577@mail.gmail.com>

Help!
Can't someone give me some pointers?
Tks,
            Tiago Marques



On 6/5/08, Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006 at gmx.net> wrote:
> On 05.06.2008 21:59, Tiago Marques wrote:
>  > help?
>  >
>  >
>  > On 6/1/08, Tiago Marques <tiagomnm at gmail.com> wrote:
>  >
>  >> Finally had some time to test this.
>  >>  The erase command does nothing, I was still able to download the full
>  >>  BIOS and boot the machine. This using the latest flashrom revision.
>  >>  First step is to make it erase? Where should I start?
>  >>
>
>
> Sorry, I will be unavailable for the rest of the month due to diploma
>  thesis work. I hope you can find somebody else on this list to help you.
>
>
>  Regards,
>
> Carl-Daniel
>



From joe at settoplinux.org  Sat Jun 21 02:10:39 2008
From: joe at settoplinux.org (Joseph Smith)
Date: Fri, 20 Jun 2008 20:10:39 -0400
Subject: [coreboot] [RFC] coreboot Live CD
In-Reply-To: <13426df10806201550r49073f37x2c70d6157db17d56@mail.gmail.com>
References: <AA28F077645B324881335614E4F7C4284A4939@win-ex01.bench.com>
	<13426df10806201550r49073f37x2c70d6157db17d56@mail.gmail.com>
Message-ID: <fd2e0825beb43017e20697a034680c7d@imap.1and1.com>




On Fri, 20 Jun 2008 16:50:24 -0600, "ron minnich" <rminnich at gmail.com>
wrote:
> On Fri, Jun 20, 2008 at 4:30 PM,  <Ken.Fuchs at bench.com> wrote:
>>
>> Another problem with LinuxBIOS and now with coreboot
>> is all the mainboards I tried to build or the even
>> the payloads would never compile without some serious
>> errors.  Hopefully, a validated coreboot Live CD
>> would solve this problem and increase exposure of
>> coreboot at the same time.

Sorry I can't relate here my boards build just fine.....

-- 
Thanks,
Joseph Smith
Set-Top-Linux
www.settoplinux.org




From svn at coreboot.org  Sat Jun 21 02:19:52 2008
From: svn at coreboot.org (svn at coreboot.org)
Date: Sat, 21 Jun 2008 02:19:52 +0200
Subject: [coreboot] r3373 - trunk/util/flashrom
Message-ID: <mailman.1638.1355071334.16123.coreboot@coreboot.org>

Author: stuge
Date: 2008-06-21 02:19:52 +0200 (Sat, 21 Jun 2008)
New Revision: 3373

Modified:
   trunk/util/flashrom/jedec.c
Log:
flashrom: Increase delay in probe_jedec() to 2ms to reliably detect AT29C020

Run time is increased a few 100ms but this is needed for reliability.
I consider this trivial.

Signed-off-by: Peter Stuge <peter at stuge.se>
Acked-by: Peter Stuge <peter at stuge.se>


Modified: trunk/util/flashrom/jedec.c
===================================================================
--- trunk/util/flashrom/jedec.c	2008-06-20 02:58:42 UTC (rev 3372)
+++ trunk/util/flashrom/jedec.c	2008-06-21 00:19:52 UTC (rev 3373)
@@ -103,7 +103,7 @@
 	 * needs 10 ms according to the data sheet, but it has been tested
 	 * to work reliably with 20 us. Allow a factor of 2 safety margin.
 	 */
-	myusec_delay(40);
+	myusec_delay(2000);
 
 	/* Read product ID */
 	id1 = *(volatile uint8_t *)bios;




From svn at coreboot.org  Sat Jun 21 02:21:23 2008
From: svn at coreboot.org (svn at coreboot.org)
Date: Sat, 21 Jun 2008 02:21:23 +0200
Subject: [coreboot] r3374 - trunk/util/flashrom
Message-ID: <mailman.1639.1355071334.16123.coreboot@coreboot.org>

Author: stuge
Date: 2008-06-21 02:21:22 +0200 (Sat, 21 Jun 2008)
New Revision: 3374

Modified:
   trunk/util/flashrom/flashchips.c
Log:
flashrom: Update test status for Atmel AT29C020 and SST29EE010

Thanks to Urja Rannikko for reporting test results with these flash chips.

Signed-off-by: Peter Stuge <peter at stuge.se>
Acked-by: Peter Stuge <peter at stuge.se>


Modified: trunk/util/flashrom/flashchips.c
===================================================================
--- trunk/util/flashrom/flashchips.c	2008-06-21 00:19:52 UTC (rev 3373)
+++ trunk/util/flashrom/flashchips.c	2008-06-21 00:21:22 UTC (rev 3374)
@@ -39,7 +39,7 @@
 	{"AMD",		"Am29F040B",		AMD_ID,		AM_29F040B,		512,	64 * 1024,	TEST_OK_PREW,	probe_29f040b,		erase_29f040b,			write_29f040b},
 	{"AMD",		"Am29LV040B",		AMD_ID,		AM_29LV040B,		512,	64 * 1024,	TEST_UNTESTED,	probe_29f040b,		erase_29f040b,			write_29f040b},
 	{"ASD",		"AE49F2008",		ASD_ID,		ASD_AE49F2008,		256,	128,		TEST_UNTESTED,	probe_jedec,		erase_chip_jedec,		write_jedec},
-	{"Atmel",	"AT29C020",		ATMEL_ID,	AT_29C020,		256,	256,		TEST_UNTESTED,	probe_jedec,		erase_chip_jedec,		write_jedec},
+	{"Atmel",	"AT29C020",		ATMEL_ID,	AT_29C020,		256,	256,		TEST_OK_PREW,	probe_jedec,		erase_chip_jedec,		write_jedec},
 	{"Atmel",	"AT29C040A",		ATMEL_ID,	AT_29C040A,		512,	256,		TEST_UNTESTED,	probe_jedec,		erase_chip_jedec,		write_jedec},
 	{"Atmel",	"AT49F002(N)",		ATMEL_ID,	AT_49F002N,		256,	256,		TEST_UNTESTED,	probe_jedec,		erase_chip_jedec,		write_jedec},
 	{"Atmel",	"AT49F002(N)T",		ATMEL_ID,	AT_49F002NT,		256,	256,		TEST_UNTESTED,	probe_jedec,		erase_chip_jedec,		write_jedec},
@@ -74,7 +74,7 @@
 	{"SST",		"SST25VF016B",		SST_ID,		SST_25VF016B,		2048,	256,		TEST_UNTESTED,	probe_spi_rdid,		spi_chip_erase_c7,	spi_chip_write,	spi_chip_read},
 	{"SST",		"SST25VF040B",		SST_ID,		SST_25VF040B,		512,	256,		TEST_UNTESTED,	probe_spi_rdid,		spi_chip_erase_c7,	spi_chip_write,	spi_chip_read},
 	{"SST",		"SST28SF040A",		SST_ID,		SST_28SF040,		512,	256,		TEST_UNTESTED,	probe_28sf040,		erase_28sf040,			write_28sf040},
-	{"SST",		"SST29EE010",		SST_ID,		SST_29EE010,		128,	128,		TEST_UNTESTED,	probe_jedec,		erase_chip_jedec,		write_jedec},
+	{"SST",		"SST29EE010",		SST_ID,		SST_29EE010,		128,	128,		TEST_OK_PREW,	probe_jedec,		erase_chip_jedec,		write_jedec},
 	{"SST",		"SST29LE010",		SST_ID,		SST_29LE010,		128,	128,		TEST_UNTESTED,	probe_jedec,		erase_chip_jedec, 		write_jedec},
 	{"SST",		"SST29EE020A",		SST_ID,		SST_29EE020A,		256,	128,		TEST_UNTESTED,	probe_jedec,		erase_chip_jedec,		write_jedec},
 	{"SST",		"SST29LE020",		SST_ID,		SST_29LE020,		256,	128,		TEST_UNTESTED,	probe_jedec,		erase_chip_jedec,		write_jedec},




From peter at stuge.se  Sat Jun 21 02:46:01 2008
From: peter at stuge.se (Peter Stuge)
Date: Sat, 21 Jun 2008 02:46:01 +0200
Subject: [coreboot] flashrom verify fails, CK804, MCP55
In-Reply-To: <b1335fe90806010809r3eadbf71lb17ab1126906cc7d@mail.gmail.com>
References: <20080127160652.GA21535@coresystems.de>
	<b1335fe90801271006h35de2c71vc3bc6ab13ab39a02@mail.gmail.com>
	<b1335fe90801271006m63b7e884h2440d1d1bb5aa614@mail.gmail.com>
	<20080127181124.GA23002@localdomain>
	<b1335fe90801271119h5af39e2el388df1785d21e015@mail.gmail.com>
	<20080127194808.GA23518@localdomain>
	<b1335fe90801271233p149cccc9k3a60f165ab01fe0c@mail.gmail.com>
	<b1335fe90801290959r6f65c208na74badb4dac9aa@mail.gmail.com>
	<47AC6B27.6040708@gmx.net>
	<b1335fe90806010809r3eadbf71lb17ab1126906cc7d@mail.gmail.com>
Message-ID: <20080621004601.29261.qmail@stuge.se>

Dear Tiago,

On Sun, Jun 01, 2008 at 04:09:07PM +0100, Tiago Marques wrote:
> Finally had some time to test this.
> The erase command does nothing, I was still able to download the
> full BIOS and boot the machine. This using the latest flashrom
> revision. First step is to make it erase? Where should I start?

If this is the case with both Winbond and PMC flash chips it seems
like the write disable signals to the chip were set, but in that
case it would not have been possible for flashrom to PROBE
successfully. Hm.

I am interested in debugging this. Would it be possible for you to
join our IRC channel sometime for a more effective session?

irc.freenode.net #coreboot

If not, we can do email too. :)


//Peter



From c-d.hailfinger.devel.2006 at gmx.net  Sat Jun 21 02:52:10 2008
From: c-d.hailfinger.devel.2006 at gmx.net (Carl-Daniel Hailfinger)
Date: Sat, 21 Jun 2008 02:52:10 +0200
Subject: [coreboot] r3373 - trunk/util/flashrom
In-Reply-To: <20080621002024.15816gmx1@mx099.gmx.net>
References: <20080621002024.15816gmx1@mx099.gmx.net>
Message-ID: <485C50BA.1000607@gmx.net>

On 21.06.2008 02:19, svn at coreboot.org wrote:
> Author: stuge
> Date: 2008-06-21 02:19:52 +0200 (Sat, 21 Jun 2008)
> New Revision: 3373
>
> Modified:
>    trunk/util/flashrom/jedec.c
> Log:
> flashrom: Increase delay in probe_jedec() to 2ms to reliably detect AT29C020
>
> Run time is increased a few 100ms but this is needed for reliability.
> I consider this trivial.
>   

Please fix the comment above your change to match the new reality. Thanks.

> Signed-off-by: Peter Stuge <peter at stuge.se>
> Acked-by: Peter Stuge <peter at stuge.se>
>
>
> Modified: trunk/util/flashrom/jedec.c
> ===================================================================
> --- trunk/util/flashrom/jedec.c	2008-06-20 02:58:42 UTC (rev 3372)
> +++ trunk/util/flashrom/jedec.c	2008-06-21 00:19:52 UTC (rev 3373)
> @@ -103,7 +103,7 @@
>  	 * needs 10 ms according to the data sheet, but it has been tested
>  	 * to work reliably with 20 us. Allow a factor of 2 safety margin.
>  	 */
> -	myusec_delay(40);
> +	myusec_delay(2000);
>  
>  	/* Read product ID */
>  	id1 = *(volatile uint8_t *)bios;
>
>
>   
Regards,
Carl-Daniel

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




From svn at coreboot.org  Sat Jun 21 03:02:21 2008
From: svn at coreboot.org (svn at coreboot.org)
Date: Sat, 21 Jun 2008 03:02:21 +0200
Subject: [coreboot] r3375 - trunk/util/flashrom
Message-ID: <mailman.1640.1355071334.16123.coreboot@coreboot.org>

Author: stuge
Date: 2008-06-21 03:02:20 +0200 (Sat, 21 Jun 2008)
New Revision: 3375

Modified:
   trunk/util/flashrom/jedec.c
Log:
flashrom: Update comment to match delay change in probe_jedec() r3373

Signed-off-by: Peter Stuge <peter at stuge.se>
Acked-by: Peter Stuge <peter at stuge.se>


Modified: trunk/util/flashrom/jedec.c
===================================================================
--- trunk/util/flashrom/jedec.c	2008-06-21 00:21:22 UTC (rev 3374)
+++ trunk/util/flashrom/jedec.c	2008-06-21 01:02:20 UTC (rev 3375)
@@ -101,7 +101,7 @@
 	*(volatile uint8_t *)(bios + 0x5555) = 0x90;
 	/* Older chips may need up to 100 us to respond. The ATMEL 29C020
 	 * needs 10 ms according to the data sheet, but it has been tested
-	 * to work reliably with 20 us. Allow a factor of 2 safety margin.
+	 * to work reliably with 2 ms.
 	 */
 	myusec_delay(2000);
 




From peter at stuge.se  Sat Jun 21 03:03:04 2008
From: peter at stuge.se (Peter Stuge)
Date: Sat, 21 Jun 2008 03:03:04 +0200
Subject: [coreboot] r3373 - trunk/util/flashrom
In-Reply-To: <485C50BA.1000607@gmx.net>
References: <20080621002024.15816gmx1@mx099.gmx.net> <485C50BA.1000607@gmx.net>
Message-ID: <20080621010304.10059.qmail@stuge.se>

On Sat, Jun 21, 2008 at 02:52:10AM +0200, Carl-Daniel Hailfinger wrote:
> Please fix the comment above your change to match the new reality.

Yeah, good idea. r3375


//Peter



From joe at settoplinux.org  Fri Jun 20 13:59:39 2008
From: joe at settoplinux.org (Joseph Smith)
Date: Fri, 20 Jun 2008 07:59:39 -0400
Subject: [coreboot] GSoC project(SCSI boot)__status report
In-Reply-To: <92cbc4c70806192021g180ff350m3097e90f189cd53e@mail.gmail.com>
References: <92cbc4c70806020926i41b757c0ga661a3549c840be5@mail.gmail.com><48584311.4060308@coresystems.de><5291a56333627468cb118eda911dc2af@imap.1and1.com><20080618025800.GA28799@morn.localdomain><a7df9ffb104f47b43005b4b3d234abbc@imap.1and1.com><48592987.9050708@amd.com><92cbc4c70806181838x66d6e45dl6f287441838de26b@mail.gmail.com><6F651D11120C4323B9E0DC329F4D0734@smitty2m><92cbc4c70806190124v4422a1e4kd0302de3dd1df79@mail.gmail.com><96ea9e59082d34e62343c21f5cb32fed@imap.1and1.com>
	<92cbc4c70806192021g180ff350m3097e90f189cd53e@mail.gmail.com>
Message-ID: <3E892B14825F442E813402C0F2E6169E@smitty2m>

> -----Original Message-----
> From: coreboot-bounces+joe=settoplinux.org at coreboot.org [mailto:coreboot-
> bounces+joe=settoplinux.org at coreboot.org] On Behalf Of Zhang Rui
> Sent: Thursday, June 19, 2008 11:22 PM
> To: Joseph Smith
> Cc: Stefan Reinauer; Kevin O'Connor; Marc Jones; Coreboot
> Subject: Re: [coreboot] GSoC project(SCSI boot)__status report
> 
> 2008/6/20 Joseph Smith <joe at settoplinux.org>:
> > I don't think so, I am excited to try it out once you are finished.
> > Although I am using IDE instead of SCSI.
> > Sorry if I sound like a broken record, the main thing to remember is we
> > need to make all the LegacyBIOS code that is getting injected into the
> > coreboot base code optional, hence the "if option LegacyBIOS is
> selected".
> > There are alot of people sensative about this, and we need to keep
> coreboot
> > flexible and make everyone happy, right?
> >
> OK, I will keep "making LegacyBIOS code optional" in my mind.
> May be a choice in the menuconfig is suitable?
> I will implement this option after I finished the SCSI booting
> functionality.
> Is this OK?
> 
> And another question, LegacyBIOS is not in the coreboot base code now
> and where should we put it? Maybe in the util/LegacyBIOS?
> 
For v3 you could probably just use the menuconfig. I haven't played around
with v3 yet, so someone else would probably be better to answer that.

For v2 use a global option in Option.lb, something like:

uses USE_LEGACYBIOS
##
## Build code for LegacyBIOS support
## 0 = disabled, 1 = enabled
##
default USE_LEGACYBIOS = 1

and then before and after your code use a preprocessing directive:

#if USE_LEGACYBIOS

Insert LegacyBIOS code here

#endif


Hope that helps:-)

Thanks,
Joseph Smith
Set-Top-Linux
www.settoplinux.org




From joe at settoplinux.org  Fri Jun 20 14:09:07 2008
From: joe at settoplinux.org (joe at settoplinux.org)
Date: Fri, 20 Jun 2008 08:09:07 -0400
Subject: [coreboot] Thomson IP1000's for sale
Message-ID: <E52EB85BBF0C4B688B9815457F342CD5@smitty2m>

Hello,

In case anyone wanted to play with coreboot and the Thomson IP1000, and
possibly help me with some development, there are a few for sale on eBay
fairly cheap. Just an FYI in case your interested:

 

http://search.ebay.com/search/search.dll?from=R40&_trksid=m37&satitle=TELUS+
TV+

 

Thanks - Joe

 

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

From joe at settoplinux.org  Sat Jun 21 04:03:18 2008
From: joe at settoplinux.org (Joseph Smith)
Date: Fri, 20 Jun 2008 22:03:18 -0400
Subject: [coreboot] -v2[PATCH] i82830 multiple so-dimm support
Message-ID: <237225d341fe652bb43f5c1e89bc42d5@imap.1and1.com>

This patch allows support for booting multiple so-dimms, single or double
sided.

Signed-off-by: Joseph Smith <joe at settoplinux.org>

-- 
Thanks,
Joseph Smith
Set-Top-Linux
www.settoplinux.org
-------------- next part --------------
Index: src/northbridge/intel/i82830/raminit.c
===================================================================
--- src/northbridge/intel/i82830/raminit.c	(revision 3375)
+++ src/northbridge/intel/i82830/raminit.c	(working copy)
@@ -53,7 +53,7 @@
  * 0x2 for Refresh interval 7.8 us for 133MHz
  * 0x7 /* Refresh interval 128 Clocks. (Fast Refresh Mode)
  */
-#define RAM_COMMAND_REFRESH		0x2
+#define RAM_COMMAND_REFRESH		0x1
 
 /* DRC[6:4] - SDRAM Mode Select (SMS). */
 #define RAM_COMMAND_SELF_REFRESH	0x0
@@ -76,7 +76,7 @@
 			   uint32_t addr_offset)
 {
 	int i;
-	uint8_t reg8, reg8_2 = 0;
+	uint8_t dimm_start, dimm_end;
 	uint32_t reg32;
 
 	/* Configure the RAM command. */
@@ -84,28 +84,27 @@
 	/* Clear bits 29, 10-8, 6-4. */
 	reg32 &= 0xdffff88f;
 	reg32 |= command << 4;
-	/* If RAM_COMMAND_NORMAL set the refresh mode and IC bit. */
-	if (command == RAM_COMMAND_NORMAL)
-		reg32 |= ((RAM_COMMAND_REFRESH << 8) | (RAM_COMMAND_IC << 29));
 	pci_write_config32(ctrl->d0, DRC, reg32);
 
-	/* RAM_COMMAND_NORMAL affects only the memory controller and
-	   doesn't need to be "sent" to the DIMMs. */
-	/* if (command == RAM_COMMAND_NORMAL) return; */
+	/* Send the ram command to each row of memory.
+	 * (DIMM_SOCKETS * 2) is the maximum number of rows possible.
+	 * Note: Each DRB defines the upper boundary address of 
+	 * each SDRAM row in 32-MB granularity.
+	 */
+	dimm_start = 0;
 
-	PRINT_DEBUG("    Sending RAM command 0x");
-	PRINT_DEBUG_HEX32(reg32);
-	PRINT_DEBUG(" to 0x");
-	PRINT_DEBUG_HEX32(0 + addr_offset);
-	PRINT_DEBUG("\r\n");
-
-	/* NOTE: Dual-sided ready. */
-	read32(0 + addr_offset);
-	for (i = 0; i < 4; i++) {
-		reg8 = pci_read_config8(ctrl->d0, DRB + i);
-		if (reg8 != reg8_2)
-			read32(reg8 * 32 * 1024 * 1024);
-		reg8_2 = reg8;
+	for (i = 0; i < (DIMM_SOCKETS * 2); i++) {
+		dimm_end = pci_read_config8(ctrl->d0, DRB + i);
+		if (dimm_end > dimm_start) {
+			PRINT_DEBUG("    Sending RAM command 0x");
+			PRINT_DEBUG_HEX32(reg32);
+			PRINT_DEBUG(" to 0x");
+			PRINT_DEBUG_HEX32((dimm_start * 32 * 1024 * 1024) + addr_offset);
+			PRINT_DEBUG("\r\n");
+			read32((dimm_start * 32 * 1024 * 1024) + addr_offset);
+		}
+		/* Set the start of the next DIMM. */
+		dimm_start = dimm_end;
 	}
 }
 
@@ -316,38 +315,28 @@
 			value = spd_read_byte(device, 5);
 
 			if (value == 1) {
-				switch (dra) {
-				case 2: /* 2KB */
-					dra = 0xF0;
-					break;
-				case 4: /* 4KB */
-					dra = 0xF1;
-					break;
-				case 8: /* 8KB */
-					dra = 0xF2;
-					break;
-				case 16: /* 16KB */
-					dra = 0xF3;
-					break;
-				default:
+				if (dra == 2) {
+					dra = 0xF0; /* 2KB */
+				} else if (dra == 4) {
+					dra = 0xF1; /* 4KB */
+				} else if (dra == 8) {
+					dra = 0xF2; /* 8KB */
+				} else if (dra == 16) {
+					dra = 0xF3; /* 16KB */
+				} else {
 					print_err("Page size not supported\r\n");
 					die("HALT\r\n");
 				}
 			} else if (value == 2) {
-				switch (dra) {
-				case 2: /* 2KB */
-					dra = 0x00;
-					break;
-				case 4: /* 4KB */
-					dra = 0x11;
-					break;
-				case 8: /* 8KB */
-					dra = 0x22;
-					break;
-				case 16: /* 16KB */
-					dra = 0x33;
-					break;
-				default:
+				if (dra == 2) {
+					dra = 0x00; /* 2KB */
+				} else if (dra == 4) {
+					dra = 0x11; /* 4KB */
+				} else if (dra == 8) {
+					dra = 0x22; /* 8KB */
+				} else if (dra == 16) {
+					dra = 0x33; /* 16KB */
+				} else {
 					print_err("Page size not supported\r\n");
 					die("HALT\r\n");
 				}
@@ -471,6 +460,7 @@
 static void sdram_enable(int controllers, const struct mem_controller *ctrl)
 {
 	int i;
+	uint32_t reg32;
 
 	/* 0. Wait until power/voltages and clocks are stable (200us). */
 	udelay(200);
@@ -503,6 +493,12 @@
 	do_ram_command(ctrl, RAM_COMMAND_NORMAL, 0);
 	udelay(1);
 
+	/* 6. Enable refresh and Set initialization complete. */
+	PRINT_DEBUG("RAM Enable 6: Enable Refresh and IC\r\n");
+	reg32 = pci_read_config32(ctrl->d0, DRC);
+	reg32 |= ((RAM_COMMAND_REFRESH << 8) | (RAM_COMMAND_IC << 29));
+	pci_write_config32(ctrl->d0, DRC, reg32);
+
 	PRINT_DEBUG("Northbridge following SDRAM init:\r\n");
 	DUMPNORTH();
 }

From peter at stuge.se  Sat Jun 21 04:41:28 2008
From: peter at stuge.se (Peter Stuge)
Date: Sat, 21 Jun 2008 04:41:28 +0200
Subject: [coreboot] filo: Skip native ATA controllers in
	find_ide_controller_compat()
Message-ID: <20080621024128.19965.qmail@stuge.se>

Patch not signed off since I haven't tested this at all.

I would appreciate test results from using this patch on boards which
have both SATA controller(s) and one or more PATA controllers in
compatibility (AKA legacy) mode.

Previously it was not possible to boot from a drive on a PATA
controller in compat mode when there were PCI devices in native
mode (SATA always are) on lower devfn numbers. Native mode devices
were basically still assumed to use the legacy IO ports in the code
looking up IO ports for compat devices.

Please set DEBUG_IDE=1 in Config and send output to me or the list.

Thanks!


//Peter
-------------- next part --------------
A non-text attachment was scrubbed...
Name: filo.skipnativeata.patch
Type: text/x-diff
Size: 2597 bytes
Desc: not available
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20080621/e092c31f/attachment.bin>

From peter at stuge.se  Sat Jun 21 04:45:22 2008
From: peter at stuge.se (Peter Stuge)
Date: Sat, 21 Jun 2008 04:45:22 +0200
Subject: [coreboot] filo: Skip native ATA controllers in
	find_ide_controller_compat()
In-Reply-To: <20080621024128.19965.qmail@stuge.se>
References: <20080621024128.19965.qmail@stuge.se>
Message-ID: <20080621024522.23166.qmail@stuge.se>

On Sat, Jun 21, 2008 at 04:41:28AM +0200, Peter Stuge wrote:
> Patch not signed off since I haven't tested this at all.

Found a bug in the debug() calls. Fixed in the attached version.


//Peter
-------------- next part --------------
A non-text attachment was scrubbed...
Name: filo.skipnativeata.2.patch
Type: text/x-diff
Size: 2617 bytes
Desc: not available
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20080621/f3f5a789/attachment.bin>

From svn at coreboot.org  Sat Jun 21 06:23:11 2008
From: svn at coreboot.org (svn at coreboot.org)
Date: Sat, 21 Jun 2008 06:23:11 +0200
Subject: [coreboot] r3376 - trunk/util/flashrom
Message-ID: <mailman.1641.1355071334.16123.coreboot@coreboot.org>

Author: stuge
Date: 2008-06-21 06:23:10 +0200 (Sat, 21 Jun 2008)
New Revision: 3376

Modified:
   trunk/util/flashrom/flashchips.c
Log:
flashrom: Uppercase AMIC since that's what they write in datasheets.

Signed-off-by: Peter Stuge <peter at stuge.se>
Acked-by: Peter Stuge <peter at stuge.se>


Modified: trunk/util/flashrom/flashchips.c
===================================================================
--- trunk/util/flashrom/flashchips.c	2008-06-21 01:02:20 UTC (rev 3375)
+++ trunk/util/flashrom/flashchips.c	2008-06-21 04:23:10 UTC (rev 3376)
@@ -44,9 +44,9 @@
 	{"Atmel",	"AT49F002(N)",		ATMEL_ID,	AT_49F002N,		256,	256,		TEST_UNTESTED,	probe_jedec,		erase_chip_jedec,		write_jedec},
 	{"Atmel",	"AT49F002(N)T",		ATMEL_ID,	AT_49F002NT,		256,	256,		TEST_UNTESTED,	probe_jedec,		erase_chip_jedec,		write_jedec},
 	{"Atmel",       "AT25DF321",		ATMEL_ID,	AT_25DF321,		4096,	256,		TEST_OK_PREW,	probe_spi_rdid,		spi_chip_erase_c7,	spi_chip_write,	spi_chip_read},
-	{"Amic Technology","A25L40P",		AMIC_ID,	AMIC_A25L40P,		512,	256,		TEST_UNTESTED,	probe_spi_rdid,		spi_chip_erase_c7,	spi_chip_write, spi_chip_read},
+	{"AMIC Technology","A25L40P",		AMIC_ID,	AMIC_A25L40P,		512,	256,		TEST_UNTESTED,	probe_spi_rdid,		spi_chip_erase_c7,	spi_chip_write, spi_chip_read},
 	{"AMIC Technology","A49LF040A",		AMIC_ID_NOPREFIX, AMIC_A49LF040A,	512,	64 * 1024,	TEST_OK_PREW,	probe_49fl00x,		erase_49fl00x,			write_49fl00x},
-	{"Amic Technology","A29040B",		AMIC_ID_NOPREFIX, AMIC_A29040B,		512,	64 * 1024,	TEST_OK_PR,	probe_29f040b,		erase_29f040b,			write_29f040b},
+	{"AMIC Technology","A29040B",		AMIC_ID_NOPREFIX, AMIC_A29040B,		512,	64 * 1024,	TEST_OK_PR,	probe_29f040b,		erase_29f040b,			write_29f040b},
 	{"EMST",	"F49B002UA",		EMST_ID,	EMST_F49B002UA,		256,	4096,		TEST_UNTESTED,	probe_jedec,		erase_chip_jedec,		write_49f002},
 	{"EON",		"EN29F002(A)(N)B",	EON_ID,		EN_29F002B,		256,	256,		TEST_UNTESTED,	probe_jedec,		erase_chip_jedec,		write_jedec},
 	{"EON",		"EN29F002(A)(N)T",	EON_ID,		EN_29F002T,		256,	256,		TEST_UNTESTED,	probe_jedec,		erase_chip_jedec,		write_jedec},




From svn at coreboot.org  Sat Jun 21 06:39:18 2008
From: svn at coreboot.org (svn at coreboot.org)
Date: Sat, 21 Jun 2008 06:39:18 +0200
Subject: [coreboot] r3377 - trunk/util/flashrom
Message-ID: <mailman.1642.1355071334.16123.coreboot@coreboot.org>

Author: stuge
Date: 2008-06-21 06:39:17 +0200 (Sat, 21 Jun 2008)
New Revision: 3377

Modified:
   trunk/util/flashrom/Makefile
Log:
flashrom: Fix OBJS in Makefile to compile stm50flw0x0x.c like the others

Signed-off-by: Peter Stuge <peter at stuge.se>
Acked-by: Peter Stuge <peter at stuge.se>


Modified: trunk/util/flashrom/Makefile
===================================================================
--- trunk/util/flashrom/Makefile	2008-06-21 04:23:10 UTC (rev 3376)
+++ trunk/util/flashrom/Makefile	2008-06-21 04:39:17 UTC (rev 3377)
@@ -24,7 +24,7 @@
 LDFLAGS += -L/usr/local/lib
 endif
 
-OBJS = chipset_enable.o board_enable.o udelay.o jedec.o stm50flw0x0x.c \
+OBJS = chipset_enable.o board_enable.o udelay.o jedec.o stm50flw0x0x.o \
 	sst28sf040.o am29f040b.o mx29f002.o sst39sf020.o m29f400bt.o \
 	w49f002u.o 82802ab.o msys_doc.o pm49fl00x.o sst49lf040.o \
 	sst49lfxxxc.o sst_fwhub.o layout.o cbtable.o flashchips.o \




From bari at onelabs.com  Sat Jun 21 06:55:54 2008
From: bari at onelabs.com (bari)
Date: Fri, 20 Jun 2008 23:55:54 -0500
Subject: [coreboot] filo: Skip native ATA controllers
	in	find_ide_controller_compat()
In-Reply-To: <20080621024522.23166.qmail@stuge.se>
References: <20080621024128.19965.qmail@stuge.se>
	<20080621024522.23166.qmail@stuge.se>
Message-ID: <485C89DA.1090303@onelabs.com>

Peter Stuge wrote:
> On Sat, Jun 21, 2008 at 04:41:28AM +0200, Peter Stuge wrote:
>   
>> Patch not signed off since I haven't tested this at all.
>>     
>
> Found a bug in the debug() calls. Fixed in the attached version.
>
>
> //Peter
>   
It works!

Pre-Acked Bari Ari <bari at onelabs.com>



From peter at stuge.se  Sat Jun 21 07:10:45 2008
From: peter at stuge.se (Peter Stuge)
Date: Sat, 21 Jun 2008 07:10:45 +0200
Subject: [coreboot] flashrom: Slight restructure of SPI probe_ functions
Message-ID: <20080621051045.32488.qmail@stuge.se>

Patch attached.


//Peter
-------------- next part --------------
A non-text attachment was scrubbed...
Name: fr.spiprobe_restructure.patch
Type: text/x-diff
Size: 3759 bytes
Desc: not available
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20080621/f2679f87/attachment.bin>

From peter at stuge.se  Sat Jun 21 08:06:50 2008
From: peter at stuge.se (Peter Stuge)
Date: Sat, 21 Jun 2008 08:06:50 +0200
Subject: [coreboot] filo: Skip native ATA controllers in
	find_ide_controller_compat()
In-Reply-To: <485C89DA.1090303@onelabs.com>
References: <20080621024128.19965.qmail@stuge.se>
	<20080621024522.23166.qmail@stuge.se>
	<485C89DA.1090303@onelabs.com>
Message-ID: <20080621060650.11428.qmail@stuge.se>

On Fri, Jun 20, 2008 at 11:55:54PM -0500, bari wrote:
> Peter Stuge wrote:
> > Found a bug in the debug() calls. Fixed in the attached version.
> 
> It works!

Great! I'm looking forward to more test results. Here's a properly
signed-off patch with some small debug message fixes and better
explanation.

Anyone else who has a board with a SATA PCI device before the
PATA/IDE device, please test booting from PATA using this patch.

It would also be interesting to boot this patch on a board with only
PATA/IDE devices - ie. no SATA or native mode PATA.


//Peter
-------------- next part --------------
A non-text attachment was scrubbed...
Name: filo.skipnativeata.3.patch
Type: text/x-diff
Size: 3346 bytes
Desc: not available
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20080621/ff5fb1f5/attachment.bin>

From joe at settoplinux.org  Sat Jun 21 16:32:33 2008
From: joe at settoplinux.org (Joseph Smith)
Date: Sat, 21 Jun 2008 10:32:33 -0400
Subject: [coreboot] -v2[PATCH] i82830 multiple so-dimm support ACK??
In-Reply-To: <237225d341fe652bb43f5c1e89bc42d5@imap.1and1.com>
References: <237225d341fe652bb43f5c1e89bc42d5@imap.1and1.com>
Message-ID: <977AAF39A7BD4BF08CE3A41A6FDD1163@smitty2m>



> -----Original Message-----
> From: coreboot-bounces+joe=settoplinux.org at coreboot.org [mailto:coreboot-
> bounces+joe=settoplinux.org at coreboot.org] On Behalf Of Joseph Smith
> Sent: Friday, June 20, 2008 10:03 PM
> To: coreboot
> Subject: [coreboot] -v2[PATCH] i82830 multiple so-dimm support
> 
> This patch allows support for booting multiple so-dimms, single or double
> sided.
> 
> Signed-off-by: Joseph Smith <joe at settoplinux.org>
> 

Looking for an Acker, Anyone?

Thanks,
Joseph Smith
Set-Top-Linux
www.settoplinux.org




From tiagomnm at gmail.com  Sat Jun 21 17:50:12 2008
From: tiagomnm at gmail.com (Tiago Marques)
Date: Sat, 21 Jun 2008 16:50:12 +0100
Subject: [coreboot] flashrom verify fails, CK804, MCP55
In-Reply-To: <20080621004601.29261.qmail@stuge.se>
References: <20080127160652.GA21535@coresystems.de>
	<b1335fe90801271006m63b7e884h2440d1d1bb5aa614@mail.gmail.com>
	<20080127181124.GA23002@localdomain>
	<b1335fe90801271119h5af39e2el388df1785d21e015@mail.gmail.com>
	<20080127194808.GA23518@localdomain>
	<b1335fe90801271233p149cccc9k3a60f165ab01fe0c@mail.gmail.com>
	<b1335fe90801290959r6f65c208na74badb4dac9aa@mail.gmail.com>
	<47AC6B27.6040708@gmx.net>
	<b1335fe90806010809r3eadbf71lb17ab1126906cc7d@mail.gmail.com>
	<20080621004601.29261.qmail@stuge.se>
Message-ID: <b1335fe90806210850n32344c2fy4ed15e9ad1e2bc0e@mail.gmail.com>

I would rather do it by e-mail, for now.
What information would you need?
Best regards


On 6/21/08, Peter Stuge <peter at stuge.se> wrote:
> Dear Tiago,
>
>
>  On Sun, Jun 01, 2008 at 04:09:07PM +0100, Tiago Marques wrote:
>  > Finally had some time to test this.
>  > The erase command does nothing, I was still able to download the
>  > full BIOS and boot the machine. This using the latest flashrom
>  > revision. First step is to make it erase? Where should I start?
>
>
> If this is the case with both Winbond and PMC flash chips it seems
>  like the write disable signals to the chip were set, but in that
>  case it would not have been possible for flashrom to PROBE
>  successfully. Hm.
>
>  I am interested in debugging this. Would it be possible for you to
>  join our IRC channel sometime for a more effective session?
>
>  irc.freenode.net #coreboot
>
>  If not, we can do email too. :)
>
>
>  //Peter
>
>
>  --
>  coreboot mailing list
>  coreboot at coreboot.org
>  http://www.coreboot.org/mailman/listinfo/coreboot
>



From niels_ole at salscheider-online.de  Sat Jun 21 17:52:08 2008
From: niels_ole at salscheider-online.de (Niels Ole Salscheider)
Date: Sat, 21 Jun 2008 17:52:08 +0200
Subject: [coreboot] Recent AMD chipsets
Message-ID: <200806211752.09108.niels_ole@salscheider-online.de>

Hello,

are there any plans to port coreboot to a recent AMD chipset like 780G / 
SB700? I would like to see coreboot running on the ASUS M3A-H/HDMI.

I am not very experienced in low-level programming but I am willing to learn 
and to spend some time to port coreboot to that chipset.
How far is the progress of coreboot v3? Is it a good idea to use that version 
or is it better to use coreboot v2 and port it to v3 as soon as it is stable?

The flash chip on the ASUS M3A-H/HDMI is a SPI chip like the one that can be 
found on the GIGABYTE GA-M57SLI-S4. There is a second unused position, too.
Are there any limitations on the chips that can be used or can I use any of 
the supported spi chips (like the MX25L3205)?

Kind regards

Ole



From patrick at georgi-clan.de  Sat Jun 21 21:14:24 2008
From: patrick at georgi-clan.de (Patrick Georgi)
Date: Sat, 21 Jun 2008 21:14:24 +0200
Subject: [coreboot] coreboot and U-Boot: a comparison
In-Reply-To: <13426df10806201549r252d0fcfm15592a6152517c0b@mail.gmail.com>
References: <AA28F077645B324881335614E4F7C4284A4937@win-ex01.bench.com>
	<13426df10806201549r252d0fcfm15592a6152517c0b@mail.gmail.com>
Message-ID: <485D5310.8030802@georgi-clan.de>

ron minnich schrieb:
>> 8) U-Boot now has architecture specific git repositories for
>>   active development available via http protocol that passes
>>   through most firewalls transparently.  coreboot has a
>>   single SVN repository that seems to be accessible only
>>   via the svn protocol which requires that the svn port
>>   be open on the firewall which is often impossible to get
>>   approved, since it is a "non-standard" port.
>>     
>
> ah, git. Love it or hate it. I know people who have used it and now
> stopped. We had a truly terrible experience with LB and arch years
> ago, and the SCM question is a sensitive one. I have had people tell
> me "move to git" and others tell me "please please DON'T EVER MOVE TO
> GIT".
>   
I think, the main request here is to have the repo available over a 
"standard port" (yay, it's PHBs and BOFHs ruining the party again).

We already provide the cbv2 repo over https (as documented on 
http://www.coreboot.org/Download_coreboot ), and it should be easy to 
provide the other repos as well. It should be easy to map them into the 
http namespace on coreboot.org, if that's truly necessary.


Regards,
Patrick



From bari at onelabs.com  Sat Jun 21 21:24:16 2008
From: bari at onelabs.com (bari)
Date: Sat, 21 Jun 2008 14:24:16 -0500
Subject: [coreboot] filo: Skip native ATA controllers
	in	find_ide_controller_compat()
In-Reply-To: <20080621060650.11428.qmail@stuge.se>
References: <20080621024128.19965.qmail@stuge.se>	<20080621024522.23166.qmail@stuge.se>	<485C89DA.1090303@onelabs.com>
	<20080621060650.11428.qmail@stuge.se>
Message-ID: <485D5560.20802@onelabs.com>

Peter Stuge wrote:
> On Fri, Jun 20, 2008 at 11:55:54PM -0500, bari wrote:
>   
>> Peter Stuge wrote:
>>     
>>> Found a bug in the debug() calls. Fixed in the attached version.
>>>       
>> It works!
>>     
>
> Great! I'm looking forward to more test results. Here's a properly
> signed-off patch with some small debug message fixes and better
> explanation.
>
> Anyone else who has a board with a SATA PCI device before the
> PATA/IDE device, please test booting from PATA using this patch.
>
> It would also be interesting to boot this patch on a board with only
> PATA/IDE devices - ie. no SATA or native mode PATA.
>
>
> //Peter
>   
Seems to be fine on any combination with the vt8237r.

Post-acked or is it acked-again?

Acked: Bari Ari <bari at onelabs.com>



From hansolofalcon at worldnet.att.net  Sat Jun 21 21:49:51 2008
From: hansolofalcon at worldnet.att.net (Gregg C Levine)
Date: Sat, 21 Jun 2008 15:49:51 -0400
Subject: [coreboot] Updating Mailman
Message-ID: <000001c8d3d7$fb1fbe10$6401a8c0@who8>

Hello!
Ron, Stefan, everyone:
I am currently subscribed via the address in my signature. And as it happens
my Google Mail address. I chose to do that so I could work on different
aspects of Coreboot, and post the appropriate contents of build logs and
other necessary text files to the list so as to properly describe any
errors.

However every time a message arrives I need to check it to see if it was for
my signature address or my Google Mail one, and that's done by reading the
headers.

The version of Mailman being used by GNU itself for its lists actually
displays the subscribed address as part of its displayed items in the To:
and From: blocks. Can this be done for the version used on this list?

Incidentally this happens every time my mail program collapses and retrieves
everything from both locations.
--
Gregg C Levine hansolofalcon at worldnet.att.net
"The Force will be with you always." Obi-Wan Kenobi
? 






From kevin at koconnor.net  Sun Jun 22 02:17:10 2008
From: kevin at koconnor.net (Kevin O'Connor)
Date: Sat, 21 Jun 2008 20:17:10 -0400
Subject: [coreboot] filo: Skip native ATA controllers
	in	find_ide_controller_compat()
In-Reply-To: <20080621060650.11428.qmail@stuge.se>
References: <20080621024128.19965.qmail@stuge.se>
	<20080621024522.23166.qmail@stuge.se>
	<485C89DA.1090303@onelabs.com>
	<20080621060650.11428.qmail@stuge.se>
Message-ID: <20080622001710.GA4308@morn.localdomain>

On Sat, Jun 21, 2008 at 08:06:50AM +0200, Peter Stuge wrote:
> On Fri, Jun 20, 2008 at 11:55:54PM -0500, bari wrote:
> > Peter Stuge wrote:
> > > Found a bug in the debug() calls. Fixed in the attached version.
> > 
> > It works!
> 
> Great! I'm looking forward to more test results. Here's a properly
> signed-off patch with some small debug message fixes and better
> explanation.
> 
> Anyone else who has a board with a SATA PCI device before the
> PATA/IDE device, please test booting from PATA using this patch.
> 
> It would also be interesting to boot this patch on a board with only
> PATA/IDE devices - ie. no SATA or native mode PATA.

I can confirm that my epia-m continues to boot with a patched filo.
The epia-m has only PATA, and it is in compatibility mode.

-Kevin



From svn at coreboot.org  Sun Jun 22 03:53:33 2008
From: svn at coreboot.org (svn at coreboot.org)
Date: Sun, 22 Jun 2008 03:53:33 +0200
Subject: [coreboot] r49 - in trunk/filo-0.5: drivers include main
Message-ID: <mailman.1643.1355071334.16123.coreboot@coreboot.org>

Author: stuge
Date: 2008-06-22 03:53:33 +0200 (Sun, 22 Jun 2008)
New Revision: 49

Modified:
   trunk/filo-0.5/drivers/ide.c
   trunk/filo-0.5/include/pci.h
   trunk/filo-0.5/main/pci.c
Log:
FILO: find_ide_controller_compat(): Skip over PCI devices in native mode

find_ide_controller_compat() would assume that all controllers were using
legacy ports, even SATA and IDE controllers in native PCI mode.

On a system with these PCI ids:
pci_init: 00:0f.0 1106:3149 0101 8f /* SATA native with 2 channels */
pci_init: 00:0f.1 1106:0571 0101 8a /* PATA legacy with 2 channels */

The SATA device has io resources above 0x1000.
The PATA device is without proper io resources, but is configured to listen
on the first and second legacy IDE ports 0x1f0 and 0x170.

find_ide_controller_compat() would incorrectly assume that the SATA device
used ports 0x1f0 and 0x170, and that the PATA device used 0x1e8 and 0x168.

This teaches find_ide_controller_compat() to skip devices in native mode.

Tested to not change anything on PATA-only boards and tested to allow
SATA+PATA boards to correctly boot from PATA drives.

Signed-off-by: Peter Stuge <peter at stuge.se>
Acked-by: Bari Ari <bari at onelabs.com>


Modified: trunk/filo-0.5/drivers/ide.c
===================================================================
--- trunk/filo-0.5/drivers/ide.c	2008-05-03 15:03:45 UTC (rev 48)
+++ trunk/filo-0.5/drivers/ide.c	2008-06-22 01:53:33 UTC (rev 49)
@@ -1078,8 +1078,13 @@
 
 static int find_ide_controller_compat(struct controller *ctrl, int index)
 {
+#ifdef SUPPORT_PCI
+	int skip, i, pci_index = index / 2;
+	struct pci_dev *dev;
+#else
 	if (index >= IDE_MAX_CONTROLLERS)
 		return -1;
+#endif
 #ifdef PCMCIA_CF
 	if (index == 2) {
 		ctrl->cmd_base = 0x1e0;
@@ -1087,6 +1092,31 @@
 		return 0;
 	}
 #endif
+#ifdef SUPPORT_PCI
+	/* skip any SATA and PATA PCI controllers in native mode */
+	for (skip = i = 0; i < pci_index && index; i++) {
+		/* look for i:th ata (IDE/other storage really) device */
+		dev = pci_find_ata_device(-1, -1, -1, i);
+		if (!dev)
+			break;
+		/* only IDE can be in compat mode so skip all others */
+		if (0x0101 != dev->devclass) {
+			/* other storage (SATA) always has two channels */
+			skip += 2;
+			continue;
+		}
+		/* primary in native mode? then skip it. */
+		if (1 == (dev->prog_if & 1))
+			skip++;
+		/* secondary in native mode? then skip it. */
+		if (index && 4 == (dev->prog_if & 4))
+			skip++;
+	}
+	index = skip <= index ? index - skip : 0;
+	debug("skipping %d native PCI controllers, new index=%d\n", skip, index);
+	if (index >= IDE_MAX_CONTROLLERS)
+		return -1;
+#endif
 	ctrl->cmd_base  = ide_base[index];
 	ctrl->ctrl_base = ide_base[index] + IDE_REG_EXTENDED_OFFSET;
 	return 0;

Modified: trunk/filo-0.5/include/pci.h
===================================================================
--- trunk/filo-0.5/include/pci.h	2008-05-03 15:03:45 UTC (rev 48)
+++ trunk/filo-0.5/include/pci.h	2008-06-22 01:53:33 UTC (rev 49)
@@ -32,5 +32,6 @@
 
 void pci_init(void);
 struct pci_dev *pci_find_device(int vendor, int device, int devclass, int prog_if, int index);
+struct pci_dev *pci_find_ata_device(int vendor, int device, int prog_if, int index);
 
 #endif /* PCI_H */

Modified: trunk/filo-0.5/main/pci.c
===================================================================
--- trunk/filo-0.5/main/pci.c	2008-05-03 15:03:45 UTC (rev 48)
+++ trunk/filo-0.5/main/pci.c	2008-06-22 01:53:33 UTC (rev 49)
@@ -107,3 +107,20 @@
     }
     return NULL;
 }
+
+struct pci_dev *pci_find_ata_device(int vendor, int device, int prog_if, int index)
+{
+    struct pci_dev *dev;
+
+    for (dev = dev_list; dev < dev_list + n_devs; dev++) {
+	if (vendor < 0 || vendor==dev->vendor)
+	    if (device < 0 || device==dev->device)
+		if (0x0180 == dev->devclass || 0x0101 == dev->devclass)
+		    if (prog_if < 0 || prog_if==dev->prog_if) {
+			if (index == 0)
+			    return dev;
+			index--;
+		    }
+    }
+    return NULL;
+}




From corey.osgood at gmail.com  Sun Jun 22 03:54:34 2008
From: corey.osgood at gmail.com (Corey Osgood)
Date: Sat, 21 Jun 2008 21:54:34 -0400
Subject: [coreboot] filo: Skip native ATA controllers in
	find_ide_controller_compat()
In-Reply-To: <20080622001710.GA4308@morn.localdomain>
References: <20080621024128.19965.qmail@stuge.se>
	<20080621024522.23166.qmail@stuge.se> <485C89DA.1090303@onelabs.com>
	<20080621060650.11428.qmail@stuge.se>
	<20080622001710.GA4308@morn.localdomain>
Message-ID: <dd3c80060806211854i565c4a67xf398124d571de537@mail.gmail.com>

Anyone want to try with an IDE controller in native mode? I know
vt8237r can handle it, shouldn't this make it so FILO can figure it
out?

-Corey

On Sat, Jun 21, 2008 at 8:17 PM, Kevin O'Connor <kevin at koconnor.net> wrote:
> On Sat, Jun 21, 2008 at 08:06:50AM +0200, Peter Stuge wrote:
>> On Fri, Jun 20, 2008 at 11:55:54PM -0500, bari wrote:
>> > Peter Stuge wrote:
>> > > Found a bug in the debug() calls. Fixed in the attached version.
>> >
>> > It works!
>>
>> Great! I'm looking forward to more test results. Here's a properly
>> signed-off patch with some small debug message fixes and better
>> explanation.
>>
>> Anyone else who has a board with a SATA PCI device before the
>> PATA/IDE device, please test booting from PATA using this patch.
>>
>> It would also be interesting to boot this patch on a board with only
>> PATA/IDE devices - ie. no SATA or native mode PATA.
>
> I can confirm that my epia-m continues to boot with a patched filo.
> The epia-m has only PATA, and it is in compatibility mode.
>
> -Kevin
>
> --
> coreboot mailing list
> coreboot at coreboot.org
> http://www.coreboot.org/mailman/listinfo/coreboot
>



From peter at stuge.se  Sun Jun 22 03:55:01 2008
From: peter at stuge.se (Peter Stuge)
Date: Sun, 22 Jun 2008 03:55:01 +0200
Subject: [coreboot] filo: Skip native ATA controllers
	in	find_ide_controller_compat()
In-Reply-To: <20080622001710.GA4308@morn.localdomain>
	<485D5560.20802@onelabs.com>
References: <20080621024128.19965.qmail@stuge.se>
	<20080621024522.23166.qmail@stuge.se>
	<485C89DA.1090303@onelabs.com>
	<20080621060650.11428.qmail@stuge.se>
	<20080622001710.GA4308@morn.localdomain>
	<20080621024128.19965.qmail@stuge.se>
	<20080621024522.23166.qmail@stuge.se>
	<485C89DA.1090303@onelabs.com>
	<20080621060650.11428.qmail@stuge.se> <485D5560.20802@onelabs.com>
Message-ID: <20080622015501.19071.qmail@stuge.se>

On Sat, Jun 21, 2008 at 02:24:16PM -0500, bari wrote:
> Seems to be fine on any combination with the vt8237r.
> 
> Post-acked or is it acked-again?
> 
> Acked: Bari Ari <bari at onelabs.com>

On Sat, Jun 21, 2008 at 08:17:10PM -0400, Kevin O'Connor wrote:
> I can confirm that my epia-m continues to boot with a patched filo.
> The epia-m has only PATA, and it is in compatibility mode.

Thanks for testing this! I confirmed correct functionality also on
ALIX 3c3.

FILO r49


//Peter



From peter at stuge.se  Sun Jun 22 03:56:40 2008
From: peter at stuge.se (Peter Stuge)
Date: Sun, 22 Jun 2008 03:56:40 +0200
Subject: [coreboot] filo: Skip native ATA controllers in
	find_ide_controller_compat()
In-Reply-To: <dd3c80060806211854i565c4a67xf398124d571de537@mail.gmail.com>
References: <20080621024128.19965.qmail@stuge.se>
	<20080621024522.23166.qmail@stuge.se>
	<485C89DA.1090303@onelabs.com>
	<20080621060650.11428.qmail@stuge.se>
	<20080622001710.GA4308@morn.localdomain>
	<dd3c80060806211854i565c4a67xf398124d571de537@mail.gmail.com>
Message-ID: <20080622015640.20315.qmail@stuge.se>

On Sat, Jun 21, 2008 at 09:54:34PM -0400, Corey Osgood wrote:
> Anyone want to try with an IDE controller in native mode? I know
> vt8237r can handle it, shouldn't this make it so FILO can figure it
> out?

Please do test more if you can! I committed this just a second ago
but would love to see test reports from more complex setups.

If the IDE controller is in native mode, please try booting from more
than just the first drive, to exercise the new code.


//Peter



From svn at coreboot.org  Sun Jun 22 04:00:39 2008
From: svn at coreboot.org (svn at coreboot.org)
Date: Sun, 22 Jun 2008 04:00:39 +0200
Subject: [coreboot] r3378 - trunk/util/flashrom
Message-ID: <mailman.1644.1355071334.16123.coreboot@coreboot.org>

Author: stuge
Date: 2008-06-22 04:00:39 +0200 (Sun, 22 Jun 2008)
New Revision: 3378

Modified:
   trunk/util/flashrom/Makefile
Log:
flashrom: Some Makefile cleaning

Signed-off-by: Peter Stuge <peter at stuge.se>
Acked-by: Peter Stuge <peter at stuge.se>


Modified: trunk/util/flashrom/Makefile
===================================================================
--- trunk/util/flashrom/Makefile	2008-06-21 04:39:17 UTC (rev 3377)
+++ trunk/util/flashrom/Makefile	2008-06-22 02:00:39 UTC (rev 3378)
@@ -46,11 +46,11 @@
 	$(CC) -c $(CFLAGS) $(SVNDEF) $(CPPFLAGS) $< -o $@
 
 clean:
-	rm -f *.o *~
+	rm -f $(PROGRAM) *.o *~
 
 distclean: clean
-	rm -f $(PROGRAM) .dependencies
-	
+	rm -f .dependencies
+
 dep:
 	@$(CC) -MM *.c > .dependencies
 
@@ -68,11 +68,10 @@
 	@rm -f .test.c .test
 
 install: $(PROGRAM)
-	$(INSTALL) flashrom $(PREFIX)/sbin
+	$(INSTALL) $(PROGRAM) $(PREFIX)/sbin
 	mkdir -p $(PREFIX)/share/man/man8
 	$(INSTALL) $(PROGRAM).8 $(PREFIX)/share/man/man8
 
 .PHONY: all clean distclean dep pciutils
 
 -include .dependencies
-




From corey.osgood at gmail.com  Sun Jun 22 04:01:39 2008
From: corey.osgood at gmail.com (Corey Osgood)
Date: Sat, 21 Jun 2008 22:01:39 -0400
Subject: [coreboot] filo: Skip native ATA controllers in
	find_ide_controller_compat()
In-Reply-To: <20080622015640.20315.qmail@stuge.se>
References: <20080621024128.19965.qmail@stuge.se>
	<20080621024522.23166.qmail@stuge.se> <485C89DA.1090303@onelabs.com>
	<20080621060650.11428.qmail@stuge.se>
	<20080622001710.GA4308@morn.localdomain>
	<dd3c80060806211854i565c4a67xf398124d571de537@mail.gmail.com>
	<20080622015640.20315.qmail@stuge.se>
Message-ID: <dd3c80060806211901x5ac1041fx75f8012d38ed73c8@mail.gmail.com>

bari will probably beat me to it ;) I've still got my cn700/vt8237r
board all set up on the test station, I just haven't had time to even
think about touching it in, well, a long time. Lately my attention's
been turned to race cars :D But as soon as those are up, running, and
out of the garage, I've got a few things pending for cn700.

-Corey

On Sat, Jun 21, 2008 at 9:56 PM, Peter Stuge <peter at stuge.se> wrote:
> On Sat, Jun 21, 2008 at 09:54:34PM -0400, Corey Osgood wrote:
>> Anyone want to try with an IDE controller in native mode? I know
>> vt8237r can handle it, shouldn't this make it so FILO can figure it
>> out?
>
> Please do test more if you can! I committed this just a second ago
> but would love to see test reports from more complex setups.
>
> If the IDE controller is in native mode, please try booting from more
> than just the first drive, to exercise the new code.
>
>
> //Peter
>
> --
> coreboot mailing list
> coreboot at coreboot.org
> http://www.coreboot.org/mailman/listinfo/coreboot
>



From svn at coreboot.org  Sun Jun 22 04:04:49 2008
From: svn at coreboot.org (svn at coreboot.org)
Date: Sun, 22 Jun 2008 04:04:49 +0200
Subject: [coreboot] r3379 - trunk/util/flashrom
Message-ID: <mailman.1645.1355071334.16123.coreboot@coreboot.org>

Author: stuge
Date: 2008-06-22 04:04:49 +0200 (Sun, 22 Jun 2008)
New Revision: 3379

Modified:
   trunk/util/flashrom/flashchips.c
Log:
flashrom: Update test status to TEST_OK_PREW for ST M50FLW080A and SST49LF008A

Many thanks to Julio Cesar Costa for the test report!

Signed-off-by: Peter Stuge <peter at stuge.se>
Acked-by: Peter Stuge <peter at stuge.se>


Modified: trunk/util/flashrom/flashchips.c
===================================================================
--- trunk/util/flashrom/flashchips.c	2008-06-22 02:00:39 UTC (rev 3378)
+++ trunk/util/flashrom/flashchips.c	2008-06-22 02:04:49 UTC (rev 3379)
@@ -90,7 +90,7 @@
 	{"SST",		"SST49LF003A/B",	SST_ID,		SST_49LF003A,		384,	64 * 1024,	TEST_UNTESTED,	probe_sst_fwhub,	erase_sst_fwhub,		write_sst_fwhub},
 	{"SST",		"SST49LF004A/B",	SST_ID,		SST_49LF004A,		512,	64 * 1024,	TEST_OK_PREW,	probe_sst_fwhub,	erase_sst_fwhub,		write_sst_fwhub},
 	{"SST",		"SST49LF004C",		SST_ID,		SST_49LF004C,		512,	4 * 1024,	TEST_UNTESTED,	probe_49lfxxxc,		erase_49lfxxxc,			write_49lfxxxc},
-	{"SST",		"SST49LF008A",		SST_ID,		SST_49LF008A,		1024,	64 * 1024,	TEST_OK_PR,	probe_sst_fwhub,	erase_sst_fwhub,		write_sst_fwhub},
+	{"SST",		"SST49LF008A",		SST_ID,		SST_49LF008A,		1024,	64 * 1024,	TEST_OK_PREW,	probe_sst_fwhub,	erase_sst_fwhub,		write_sst_fwhub},
 	{"SST",		"SST49LF008C",		SST_ID,		SST_49LF008C,		1024,	4 * 1024,	TEST_UNTESTED,	probe_49lfxxxc,		erase_49lfxxxc,			write_49lfxxxc},
 	{"SST",		"SST49LF016C",		SST_ID,		SST_49LF016C,		2048,	4 * 1024,	TEST_UNTESTED,	probe_49lfxxxc,		erase_49lfxxxc,			write_49lfxxxc},
 	{"SST",		"SST49LF020A",		SST_ID,		SST_49LF020A,		256,	16 * 1024,	TEST_UNTESTED,	probe_jedec,		erase_49lf040,			write_49lf040},
@@ -116,7 +116,7 @@
 	{"ST",		"M29W040B",		ST_ID,		ST_M29W040B,		512,	64 * 1024,	TEST_UNTESTED,	probe_jedec,		erase_chip_jedec,		write_jedec},
 	{"ST",		"M50FLW040A",		ST_ID,		ST_M50FLW040A,		512,	64 * 1024,	TEST_UNTESTED,	probe_stm50flw0x0x,	erase_stm50flw0x0x,		write_stm50flw0x0x},
 	{"ST",		"M50FLW040B",		ST_ID,		ST_M50FLW040B,		512,	64 * 1024,	TEST_UNTESTED,	probe_stm50flw0x0x,	erase_stm50flw0x0x,		write_stm50flw0x0x},
-	{"ST",		"M50FLW080A",		ST_ID,		ST_M50FLW080A,		1024,	64 * 1024,	TEST_UNTESTED,	probe_stm50flw0x0x,	erase_stm50flw0x0x,		write_stm50flw0x0x},
+	{"ST",		"M50FLW080A",		ST_ID,		ST_M50FLW080A,		1024,	64 * 1024,	TEST_OK_PREW,	probe_stm50flw0x0x,	erase_stm50flw0x0x,		write_stm50flw0x0x},
 	{"ST",		"M50FLW080B",		ST_ID,		ST_M50FLW080B,		1024,	64 * 1024,	TEST_UNTESTED,	probe_stm50flw0x0x,	erase_stm50flw0x0x,		write_stm50flw0x0x},
 	{"ST",		"M50FW016",		ST_ID,		ST_M50FW016,		2048,	64 * 1024,	TEST_UNTESTED,	probe_82802ab,		erase_82802ab,			write_82802ab},
 	{"ST",		"M50FW040",		ST_ID,		ST_M50FW040,		512,	64 * 1024,	TEST_UNTESTED,	probe_82802ab,		erase_82802ab,			write_82802ab},




From peter at stuge.se  Sun Jun 22 04:12:53 2008
From: peter at stuge.se (Peter Stuge)
Date: Sun, 22 Jun 2008 04:12:53 +0200
Subject: [coreboot] -v2[PATCH] i82830 multiple so-dimm support
In-Reply-To: <237225d341fe652bb43f5c1e89bc42d5@imap.1and1.com>
References: <237225d341fe652bb43f5c1e89bc42d5@imap.1and1.com>
Message-ID: <20080622021253.650.qmail@stuge.se>

On Fri, Jun 20, 2008 at 10:03:18PM -0400, Joseph Smith wrote:
> This patch allows support for booting multiple so-dimms, single or double
> sided.
> 
> Signed-off-by: Joseph Smith <joe at settoplinux.org>

Acked-by: Peter Stuge <peter at stuge.se>


> Index: src/northbridge/intel/i82830/raminit.c
> ===================================================================
> --- src/northbridge/intel/i82830/raminit.c	(revision 3375)
> +++ src/northbridge/intel/i82830/raminit.c	(working copy)
> @@ -53,7 +53,7 @@
>   * 0x2 for Refresh interval 7.8 us for 133MHz
>   * 0x7 /* Refresh interval 128 Clocks. (Fast Refresh Mode)
>   */
> -#define RAM_COMMAND_REFRESH		0x2
> +#define RAM_COMMAND_REFRESH		0x1
>  
>  /* DRC[6:4] - SDRAM Mode Select (SMS). */
>  #define RAM_COMMAND_SELF_REFRESH	0x0
> @@ -76,7 +76,7 @@
>  			   uint32_t addr_offset)
>  {
>  	int i;
> -	uint8_t reg8, reg8_2 = 0;
> +	uint8_t dimm_start, dimm_end;
>  	uint32_t reg32;
>  
>  	/* Configure the RAM command. */
> @@ -84,28 +84,27 @@
>  	/* Clear bits 29, 10-8, 6-4. */
>  	reg32 &= 0xdffff88f;
>  	reg32 |= command << 4;
> -	/* If RAM_COMMAND_NORMAL set the refresh mode and IC bit. */
> -	if (command == RAM_COMMAND_NORMAL)
> -		reg32 |= ((RAM_COMMAND_REFRESH << 8) | (RAM_COMMAND_IC << 29));
>  	pci_write_config32(ctrl->d0, DRC, reg32);
>  
> -	/* RAM_COMMAND_NORMAL affects only the memory controller and
> -	   doesn't need to be "sent" to the DIMMs. */
> -	/* if (command == RAM_COMMAND_NORMAL) return; */
> +	/* Send the ram command to each row of memory.
> +	 * (DIMM_SOCKETS * 2) is the maximum number of rows possible.
> +	 * Note: Each DRB defines the upper boundary address of 
> +	 * each SDRAM row in 32-MB granularity.
> +	 */
> +	dimm_start = 0;
>  
> -	PRINT_DEBUG("    Sending RAM command 0x");
> -	PRINT_DEBUG_HEX32(reg32);
> -	PRINT_DEBUG(" to 0x");
> -	PRINT_DEBUG_HEX32(0 + addr_offset);
> -	PRINT_DEBUG("\r\n");
> -
> -	/* NOTE: Dual-sided ready. */
> -	read32(0 + addr_offset);
> -	for (i = 0; i < 4; i++) {
> -		reg8 = pci_read_config8(ctrl->d0, DRB + i);
> -		if (reg8 != reg8_2)
> -			read32(reg8 * 32 * 1024 * 1024);
> -		reg8_2 = reg8;
> +	for (i = 0; i < (DIMM_SOCKETS * 2); i++) {
> +		dimm_end = pci_read_config8(ctrl->d0, DRB + i);
> +		if (dimm_end > dimm_start) {
> +			PRINT_DEBUG("    Sending RAM command 0x");
> +			PRINT_DEBUG_HEX32(reg32);
> +			PRINT_DEBUG(" to 0x");
> +			PRINT_DEBUG_HEX32((dimm_start * 32 * 1024 * 1024) + addr_offset);
> +			PRINT_DEBUG("\r\n");
> +			read32((dimm_start * 32 * 1024 * 1024) + addr_offset);
> +		}
> +		/* Set the start of the next DIMM. */
> +		dimm_start = dimm_end;
>  	}
>  }
>  
> @@ -316,38 +315,28 @@
>  			value = spd_read_byte(device, 5);
>  
>  			if (value == 1) {
> -				switch (dra) {
> -				case 2: /* 2KB */
> -					dra = 0xF0;
> -					break;
> -				case 4: /* 4KB */
> -					dra = 0xF1;
> -					break;
> -				case 8: /* 8KB */
> -					dra = 0xF2;
> -					break;
> -				case 16: /* 16KB */
> -					dra = 0xF3;
> -					break;
> -				default:
> +				if (dra == 2) {
> +					dra = 0xF0; /* 2KB */
> +				} else if (dra == 4) {
> +					dra = 0xF1; /* 4KB */
> +				} else if (dra == 8) {
> +					dra = 0xF2; /* 8KB */
> +				} else if (dra == 16) {
> +					dra = 0xF3; /* 16KB */
> +				} else {
>  					print_err("Page size not supported\r\n");
>  					die("HALT\r\n");
>  				}
>  			} else if (value == 2) {
> -				switch (dra) {
> -				case 2: /* 2KB */
> -					dra = 0x00;
> -					break;
> -				case 4: /* 4KB */
> -					dra = 0x11;
> -					break;
> -				case 8: /* 8KB */
> -					dra = 0x22;
> -					break;
> -				case 16: /* 16KB */
> -					dra = 0x33;
> -					break;
> -				default:
> +				if (dra == 2) {
> +					dra = 0x00; /* 2KB */
> +				} else if (dra == 4) {
> +					dra = 0x11; /* 4KB */
> +				} else if (dra == 8) {
> +					dra = 0x22; /* 8KB */
> +				} else if (dra == 16) {
> +					dra = 0x33; /* 16KB */
> +				} else {
>  					print_err("Page size not supported\r\n");
>  					die("HALT\r\n");
>  				}
> @@ -471,6 +460,7 @@
>  static void sdram_enable(int controllers, const struct mem_controller *ctrl)
>  {
>  	int i;
> +	uint32_t reg32;
>  
>  	/* 0. Wait until power/voltages and clocks are stable (200us). */
>  	udelay(200);
> @@ -503,6 +493,12 @@
>  	do_ram_command(ctrl, RAM_COMMAND_NORMAL, 0);
>  	udelay(1);
>  
> +	/* 6. Enable refresh and Set initialization complete. */
> +	PRINT_DEBUG("RAM Enable 6: Enable Refresh and IC\r\n");
> +	reg32 = pci_read_config32(ctrl->d0, DRC);
> +	reg32 |= ((RAM_COMMAND_REFRESH << 8) | (RAM_COMMAND_IC << 29));
> +	pci_write_config32(ctrl->d0, DRC, reg32);
> +
>  	PRINT_DEBUG("Northbridge following SDRAM init:\r\n");
>  	DUMPNORTH();
>  }



From peter at stuge.se  Sun Jun 22 04:55:05 2008
From: peter at stuge.se (Peter Stuge)
Date: Sun, 22 Jun 2008 04:55:05 +0200
Subject: [coreboot] flashrom: Remove dead M-Systems Disk on Chip code
Message-ID: <20080622025505.903.qmail@stuge.se>

Patch attached.


//Peter
-------------- next part --------------
A non-text attachment was scrubbed...
Name: fr.nodoc.patch
Type: text/x-diff
Size: 16616 bytes
Desc: not available
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20080622/6ddaca3b/attachment.bin>

From peter at stuge.se  Sun Jun 22 05:18:08 2008
From: peter at stuge.se (Peter Stuge)
Date: Sun, 22 Jun 2008 05:18:08 +0200
Subject: [coreboot] Technologic TS-5300
Message-ID: <20080622031808.18419.qmail@stuge.se>

Who remembers details about this guy?

flashrom hardcodes the flash chip address to 0x9400000 with -DTS5300
instead of the regular 4G-flash chip size.

There's a comment suggesting that it should be possible to autodetect
when flashrom is running on TS-5300, but there is no mention of how.

The Technologic TS-5300 is an AMD Elan 520 PC/104 design which seems
to still sell at $259 on
http://www.embeddedarm.com/products/board-detail.php?product=TS-5300

I want to get rid of the #define. Probe it or lose it!


//Peter



From joe at settoplinux.org  Sun Jun 22 06:19:06 2008
From: joe at settoplinux.org (Joseph Smith)
Date: Sun, 22 Jun 2008 00:19:06 -0400
Subject: [coreboot] RCA RM4100 vs Thomson IP1000
In-Reply-To: <F0FDF5932163483FAAF630FA1657F713@smitty2m>
References: <2c84967da1d0d1e8c9fac1e39bef2515@imap.1and1.com><dd3c80060805142131t7d08106bn6010e4040356bdbe@mail.gmail.com><056898452376c1ea0f81c202ac9f0954@imap.1and1.com><BAFBC4FF5DC944F49CC1505078AFF1E9@smitty2m><72a20e45689ced9a884ee99232622d99@imap.1and1.com><13426df10805171019t56ef9edaif5262a084e85645d@mail.gmail.com><364604bad4291bd401bb5debd24af8df@imap.1and1.com><13426df10805172033la629618r469964fc33ec1db0@mail.gmail.com><D4D826E0DCF5402ABB19365EF6CF4676@smitty2m>
	<13426df10805180843q38151242x3b419efb6d621e49@mail.gmail.com>
	<F0FDF5932163483FAAF630FA1657F713@smitty2m>
Message-ID: <3d5436518e612c64d21f0955f0242917@imap.1and1.com>




On Sun, 18 May 2008 13:27:06 -0400, "Joseph Smith" <joe at settoplinux.org>
wrote:
> 
> 
> 
>> -----Original Message-----
>> From: coreboot-bounces at coreboot.org
> [mailto:coreboot-bounces at coreboot.org]
>> On Behalf Of ron minnich
>> Sent: Sunday, May 18, 2008 11:43 AM
>> To: joe at settoplinux.org
>> Cc: Corey Osgood; coreboot at coreboot.org
>> Subject: Re: [coreboot] RCA RM4100 vs Thomson IP1000
>>
>> On Sun, May 18, 2008 at 5:36 AM, Joseph Smith <joe at settoplinux.org>
> wrote:
>>
>> > Could I just put a PCI card in it, coreboot it up, run getpir and see
> if
>> the
>> > card is detected???
>> >
>> no, this won't work.
>>
>> Sorry, I forgot the getpir problem.
>>
>> I forget: is flash pluggable? If so:
>> boot LB
>> boot linux
>> put old flash in
>> run getpir
>>
Sorry it took so long to get back on this, it didn't work, they were both
the same. I think getpir gets the irq table from memory.

-- 
Thanks,
Joseph Smith
Set-Top-Linux
www.settoplinux.org




From svn at coreboot.org  Sun Jun 22 06:22:46 2008
From: svn at coreboot.org (svn at coreboot.org)
Date: Sun, 22 Jun 2008 06:22:46 +0200
Subject: [coreboot] r3380 - trunk/coreboot-v2/src/northbridge/intel/i82830
Message-ID: <mailman.1646.1355071334.16123.coreboot@coreboot.org>

Author: linux_junkie
Date: 2008-06-22 06:22:46 +0200 (Sun, 22 Jun 2008)
New Revision: 3380

Modified:
   trunk/coreboot-v2/src/northbridge/intel/i82830/raminit.c
Log:
This patch allows support for multiple so-dimms, single or double sided.

Signed-off-by: Joseph Smith <joe at settoplinux.org>
Acked-by: Peter Stuge <peter at stuge.se>

Modified: trunk/coreboot-v2/src/northbridge/intel/i82830/raminit.c
===================================================================
--- trunk/coreboot-v2/src/northbridge/intel/i82830/raminit.c	2008-06-22 02:04:49 UTC (rev 3379)
+++ trunk/coreboot-v2/src/northbridge/intel/i82830/raminit.c	2008-06-22 04:22:46 UTC (rev 3380)
@@ -53,7 +53,7 @@
  * 0x2 for Refresh interval 7.8 us for 133MHz
  * 0x7 /* Refresh interval 128 Clocks. (Fast Refresh Mode)
  */
-#define RAM_COMMAND_REFRESH		0x2
+#define RAM_COMMAND_REFRESH		0x1
 
 /* DRC[6:4] - SDRAM Mode Select (SMS). */
 #define RAM_COMMAND_SELF_REFRESH	0x0
@@ -76,7 +76,7 @@
 			   uint32_t addr_offset)
 {
 	int i;
-	uint8_t reg8, reg8_2 = 0;
+	uint8_t dimm_start, dimm_end;
 	uint32_t reg32;
 
 	/* Configure the RAM command. */
@@ -84,28 +84,27 @@
 	/* Clear bits 29, 10-8, 6-4. */
 	reg32 &= 0xdffff88f;
 	reg32 |= command << 4;
-	/* If RAM_COMMAND_NORMAL set the refresh mode and IC bit. */
-	if (command == RAM_COMMAND_NORMAL)
-		reg32 |= ((RAM_COMMAND_REFRESH << 8) | (RAM_COMMAND_IC << 29));
 	pci_write_config32(ctrl->d0, DRC, reg32);
 
-	/* RAM_COMMAND_NORMAL affects only the memory controller and
-	   doesn't need to be "sent" to the DIMMs. */
-	/* if (command == RAM_COMMAND_NORMAL) return; */
+	/* Send the ram command to each row of memory.
+	 * (DIMM_SOCKETS * 2) is the maximum number of rows possible.
+	 * Note: Each DRB defines the upper boundary address of 
+	 * each SDRAM row in 32-MB granularity.
+	 */
+	dimm_start = 0;
 
-	PRINT_DEBUG("    Sending RAM command 0x");
-	PRINT_DEBUG_HEX32(reg32);
-	PRINT_DEBUG(" to 0x");
-	PRINT_DEBUG_HEX32(0 + addr_offset);
-	PRINT_DEBUG("\r\n");
-
-	/* NOTE: Dual-sided ready. */
-	read32(0 + addr_offset);
-	for (i = 0; i < 4; i++) {
-		reg8 = pci_read_config8(ctrl->d0, DRB + i);
-		if (reg8 != reg8_2)
-			read32(reg8 * 32 * 1024 * 1024);
-		reg8_2 = reg8;
+	for (i = 0; i < (DIMM_SOCKETS * 2); i++) {
+		dimm_end = pci_read_config8(ctrl->d0, DRB + i);
+		if (dimm_end > dimm_start) {
+			PRINT_DEBUG("    Sending RAM command 0x");
+			PRINT_DEBUG_HEX32(reg32);
+			PRINT_DEBUG(" to 0x");
+			PRINT_DEBUG_HEX32((dimm_start * 32 * 1024 * 1024) + addr_offset);
+			PRINT_DEBUG("\r\n");
+			read32((dimm_start * 32 * 1024 * 1024) + addr_offset);
+		}
+		/* Set the start of the next DIMM. */
+		dimm_start = dimm_end;
 	}
 }
 
@@ -316,38 +315,28 @@
 			value = spd_read_byte(device, 5);
 
 			if (value == 1) {
-				switch (dra) {
-				case 2: /* 2KB */
-					dra = 0xF0;
-					break;
-				case 4: /* 4KB */
-					dra = 0xF1;
-					break;
-				case 8: /* 8KB */
-					dra = 0xF2;
-					break;
-				case 16: /* 16KB */
-					dra = 0xF3;
-					break;
-				default:
+				if (dra == 2) {
+					dra = 0xF0; /* 2KB */
+				} else if (dra == 4) {
+					dra = 0xF1; /* 4KB */
+				} else if (dra == 8) {
+					dra = 0xF2; /* 8KB */
+				} else if (dra == 16) {
+					dra = 0xF3; /* 16KB */
+				} else {
 					print_err("Page size not supported\r\n");
 					die("HALT\r\n");
 				}
 			} else if (value == 2) {
-				switch (dra) {
-				case 2: /* 2KB */
-					dra = 0x00;
-					break;
-				case 4: /* 4KB */
-					dra = 0x11;
-					break;
-				case 8: /* 8KB */
-					dra = 0x22;
-					break;
-				case 16: /* 16KB */
-					dra = 0x33;
-					break;
-				default:
+				if (dra == 2) {
+					dra = 0x00; /* 2KB */
+				} else if (dra == 4) {
+					dra = 0x11; /* 4KB */
+				} else if (dra == 8) {
+					dra = 0x22; /* 8KB */
+				} else if (dra == 16) {
+					dra = 0x33; /* 16KB */
+				} else {
 					print_err("Page size not supported\r\n");
 					die("HALT\r\n");
 				}
@@ -471,6 +460,7 @@
 static void sdram_enable(int controllers, const struct mem_controller *ctrl)
 {
 	int i;
+	uint32_t reg32;
 
 	/* 0. Wait until power/voltages and clocks are stable (200us). */
 	udelay(200);
@@ -503,6 +493,12 @@
 	do_ram_command(ctrl, RAM_COMMAND_NORMAL, 0);
 	udelay(1);
 
+	/* 6. Enable refresh and Set initialization complete. */
+	PRINT_DEBUG("RAM Enable 6: Enable Refresh and IC\r\n");
+	reg32 = pci_read_config32(ctrl->d0, DRC);
+	reg32 |= ((RAM_COMMAND_REFRESH << 8) | (RAM_COMMAND_IC << 29));
+	pci_write_config32(ctrl->d0, DRC, reg32);
+
 	PRINT_DEBUG("Northbridge following SDRAM init:\r\n");
 	DUMPNORTH();
 }




From joe at settoplinux.org  Sun Jun 22 06:24:39 2008
From: joe at settoplinux.org (Joseph Smith)
Date: Sun, 22 Jun 2008 00:24:39 -0400
Subject: [coreboot] -v2[PATCH] i82830 multiple so-dimm support
In-Reply-To: <20080622021253.650.qmail@stuge.se>
References: <237225d341fe652bb43f5c1e89bc42d5@imap.1and1.com>
	<20080622021253.650.qmail@stuge.se>
Message-ID: <fe811be7df91a197d649f8d6637db03b@imap.1and1.com>




On Sun, 22 Jun 2008 04:12:53 +0200, Peter Stuge <peter at stuge.se> wrote:
> On Fri, Jun 20, 2008 at 10:03:18PM -0400, Joseph Smith wrote:
>> This patch allows support for booting multiple so-dimms, single or
> double
>> sided.
>>
>> Signed-off-by: Joseph Smith <joe at settoplinux.org>
> 
> Acked-by: Peter Stuge <peter at stuge.se>
> 
Thanks Peter.

r3380

-- 
Thanks,
Joseph Smith
Set-Top-Linux
www.settoplinux.org




From peter at stuge.se  Sun Jun 22 07:24:45 2008
From: peter at stuge.se (Peter Stuge)
Date: Sun, 22 Jun 2008 07:24:45 +0200
Subject: [coreboot] GA-M57SLI-S4 rev 2.0 dual flash chip modification recipe
Message-ID: <20080622052445.14908.qmail@stuge.se>

The board can be modified in two ways. One is simpler and less
reliable, the other is more complex but much more robust.

Materials needed:
1x SO-8 SPI flash chip, ideally 200mil but 150mil can work too
   Spansion S25FL016A is easy to get. Macronix has the 32Mbit MX25L3205.
2x 0402 100k chip resistors
1x SPTD (Single Pole Dual Throw) switch and three wires

For the better modification, you also need:
2x 0402 4k7 chip resistors (1k is OK too, 10k does not work!)
2x 0603 100k chip resistors
2x SOT-23 BC847C transistors


See http://stuge.se/m57sli/m57sli_soic_detail_labels.jpg for reference.

Common steps always needed:
1. U9: Populate flash chip
2. R509: Remove
3. R89,R130: Populate 0402 100k resistors

Simple:
NOTE: Keep wires to the switch short! Only a few centimeters/one inch.
4. Solder center contact on switch to Q4-3 or Q5-3. Either is OK.
5. Solder one side contact on switch to Q4-1.
6. Solder other side contact on switch to Q5-1.
7. DONE!

Better:
NOTE: Switch wires can be rather long. Several meters has been tested.
4. R90,R91: Populate 0402 4k7 resistors
5. R86,R389: Populate 0603 100k resistors
6. Q4,Q5: Populate SOT-23 BC847C transistors
7. Solder center contact on switch to VCC, e.g. at BC54-2.
8. Solder one side contact on switch to R86-2.
9. Solder other side contact on switch to R389-2.
10. DONE!


I am happy to sell boards pre-modified with the better modification.
Unfortunately I cannot offer these boards to consumers in all EU
member states because of EU environmental regulations, but many are
OK.

//Peter



From freevanx at gmail.com  Sun Jun 22 07:34:20 2008
From: freevanx at gmail.com (freevanx)
Date: Sun, 22 Jun 2008 13:34:20 +0800
Subject: [coreboot] Recent AMD chipsets
In-Reply-To: <200806211752.09108.niels_ole@salscheider-online.de>
References: <200806211752.09108.niels_ole@salscheider-online.de>
Message-ID: <fe8256d20806212234i1d469a44gdae3fa3eb961290b@mail.gmail.com>

Hi All,

I  have such question too. I have some borad using Intel 5000 MCH and ESB2
southbridge, I have check coreboot supported chipset list, I have not see
any version of coreboot support this board. I'd like to try  let coreboot
run at this board.

I can't decide which version of coreboot to use, And I'm a newcomer, I don't
know what's the major difference between V2 and V3.

Best Regards.

Qin.


On 6/21/08, Niels Ole Salscheider <niels_ole at salscheider-online.de> wrote:
>
> Hello,
>
> are there any plans to port coreboot to a recent AMD chipset like 780G /
> SB700? I would like to see coreboot running on the ASUS M3A-H/HDMI.
>
> I am not very experienced in low-level programming but I am willing to
> learn
> and to spend some time to port coreboot to that chipset.
> How far is the progress of coreboot v3? Is it a good idea to use that
> version
> or is it better to use coreboot v2 and port it to v3 as soon as it is
> stable?
>
> The flash chip on the ASUS M3A-H/HDMI is a SPI chip like the one that can
> be
> found on the GIGABYTE GA-M57SLI-S4. There is a second unused position, too.
> Are there any limitations on the chips that can be used or can I use any of
> the supported spi chips (like the MX25L3205)?
>
> Kind regards
>
> Ole
>
> --
> coreboot mailing list
> coreboot at coreboot.org
> http://www.coreboot.org/mailman/listinfo/coreboot
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20080622/46c69096/attachment.html>

From bari at onelabs.com  Sun Jun 22 08:29:28 2008
From: bari at onelabs.com (bari)
Date: Sun, 22 Jun 2008 01:29:28 -0500
Subject: [coreboot] Recent AMD chipsets
In-Reply-To: <200806211752.09108.niels_ole@salscheider-online.de>
References: <200806211752.09108.niels_ole@salscheider-online.de>
Message-ID: <485DF148.1020409@onelabs.com>

Niels Ole Salscheider wrote:
> Hello,
>
> are there any plans to port coreboot to a recent AMD chipset like 780G / 
> SB700? I would like to see coreboot running on the ASUS M3A-H/HDMI.
>
>   
The AMD 690/600 is in the works.
> I am not very experienced in low-level programming but I am willing to learn 
> and to spend some time to port coreboot to that chipset.
> How far is the progress of coreboot v3? Is it a good idea to use that version 
> or is it better to use coreboot v2 and port it to v3 as soon as it is stable?
>   
Start with V2, then it can be moved into V3.
> The flash chip on the ASUS M3A-H/HDMI is a SPI chip like the one that can be 
> found on the GIGABYTE GA-M57SLI-S4. There is a second unused position, too.
> Are there any limitations on the chips that can be used or can I use any of 
> the supported spi chips (like the MX25L3205)?
>
>   
Depends on the southbridge as far as how large the spi device may be.

-Bari




From ronald at zonnet.nl  Sun Jun 22 12:05:30 2008
From: ronald at zonnet.nl (Ronald Hoogenboom)
Date: Sun, 22 Jun 2008 12:05:30 +0200
Subject: [coreboot] m57sli FAN control
In-Reply-To: <20080614193751.GA1295@localdomain>
References: <20080610183457.GA32451@localdomain> <484EF2A0.7060507@zonnet.nl>
	<20080614193751.GA1295@localdomain>
Message-ID: <1214129130.2718.5.camel@amd-x2.grundel>

Hi Ward,

I finally got round to test the 'final' patch and it looks fine on my V2
board. What's the deal now? Do I do a signed-off-by and you do an ack?
Or is my previous signed-off sufficient.

Ronald.

On Sat, 2008-06-14 at 15:37 -0400, Ward Vandewege wrote:
> Hi Ronald,
> 
> On Tue, Jun 10, 2008 at 11:31:12PM +0200, Ronald Hoogenboom wrote:
> > This patch enables automatic fan control on the gigabyte M57sli-s4  
> > motherboard using the environmental controller of the IT8716 superio.
> > All fan outputs are controlled by the cpu temperature sensor for safety.
> 
> I've made a few small modifications:
> 
> * put fan2 and 3 under hardware control ('smart' mode)
> * updated for the current SVN tree
> 
> Thanks,
> Ward.
> 




From stepan at coresystems.de  Sun Jun 22 12:24:25 2008
From: stepan at coresystems.de (Stefan Reinauer)
Date: Sun, 22 Jun 2008 12:24:25 +0200
Subject: [coreboot] flashrom: Remove dead M-Systems Disk on Chip code
In-Reply-To: <20080622025505.903.qmail@stuge.se>
References: <20080622025505.903.qmail@stuge.se>
Message-ID: <485E2859.6050506@coresystems.de>

Peter Stuge wrote:
> Patch attached.
>
>
> //Peter
>   
> flashrom: Remove dead M-Systems Disk on Chip code
>
> DOC support has been disabled by default for many years. The write function
> does nothing but print text. It has a call to write_page_md2802() commented
> out, but that function does not exist. This is dead code with ugly #ifdefs.
>
> Updates README to reflect that there was a time when there was code, but it
> didn't work. Removes M-Systems #defines and also includes svn rm msys_doc.*
>
> Signed-off-by: Peter Stuge <peter at stuge.se>

Absolutely NACK.

The reason the code is not compiled in per default is that the probing
takes forever. Still, no reason to drop support.

I don't think we should drop features because we don't like a few ifdefs.

-- 
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  Sun Jun 22 12:27:27 2008
From: stepan at coresystems.de (Stefan Reinauer)
Date: Sun, 22 Jun 2008 12:27:27 +0200
Subject: [coreboot] Technologic TS-5300
In-Reply-To: <20080622031808.18419.qmail@stuge.se>
References: <20080622031808.18419.qmail@stuge.se>
Message-ID: <485E290F.4030708@coresystems.de>

Peter Stuge wrote:
> Who remembers details about this guy?
>
> flashrom hardcodes the flash chip address to 0x9400000 with -DTS5300
> instead of the regular 4G-flash chip size.
>
> There's a comment suggesting that it should be possible to autodetect
> when flashrom is running on TS-5300, but there is no mention of how.
>
> The Technologic TS-5300 is an AMD Elan 520 PC/104 design which seems
> to still sell at $259 on
> http://www.embeddedarm.com/products/board-detail.php?product=TS-5300
>
> I want to get rid of the #define. Probe it or lose it!
>
>   
I say NACK to dropping this code.

Please don't get the code drop frenzy! There are enough other open
working lots.

There's a register in the SC520 which lets you map the ROM to a certain
address. On the TS5300 it was strapped to 0x9400000, other SC520 systems
may be configured differently. But basically all have their flash at
non-standard positions afaik.

If you want to write code to do the probing, I'll gladly ACK it. I can't
test anymore - the TS5300 stayed back at the linuxtag in 07. No idea
what happened to it.

-- 
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  Sun Jun 22 12:30:03 2008
From: stepan at coresystems.de (Stefan Reinauer)
Date: Sun, 22 Jun 2008 12:30:03 +0200
Subject: [coreboot] r3378 - trunk/util/flashrom
Message-ID: <485E29AB.60001@coresystems.de>

svn at coreboot.org wrote:
> Author: stuge
> Date: 2008-06-22 04:00:39 +0200 (Sun, 22 Jun 2008)
> New Revision: 3378
>
> Modified:
>    trunk/util/flashrom/Makefile
> Log:
> flashrom: Some Makefile cleaning
>
> Signed-off-by: Peter Stuge <peter at stuge.se>
> Acked-by: Peter Stuge <peter at stuge.se>
>
>
> Modified: trunk/util/flashrom/Makefile
> ===================================================================
> --- trunk/util/flashrom/Makefile	2008-06-21 04:39:17 UTC (rev 3377)
> +++ trunk/util/flashrom/Makefile	2008-06-22 02:00:39 UTC (rev 3378)
> @@ -46,11 +46,11 @@
>  	$(CC) -c $(CFLAGS) $(SVNDEF) $(CPPFLAGS) $< -o $@
>  
>  clean:
> -	rm -f *.o *~
> +	rm -f $(PROGRAM) *.o *~
>  
>  distclean: clean
> -	rm -f $(PROGRAM) .dependencies
> -	
> +	rm -f .dependencies
> +
>   
Sorry, I don't like this ... it's not cleaning up but changing the
behavior.


-- 
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 niels_ole at salscheider-online.de  Sun Jun 22 12:47:19 2008
From: niels_ole at salscheider-online.de (Niels Ole Salscheider)
Date: Sun, 22 Jun 2008 12:47:19 +0200
Subject: [coreboot] Recent AMD chipsets
In-Reply-To: <485DF148.1020409@onelabs.com>
References: <200806211752.09108.niels_ole@salscheider-online.de>
	<485DF148.1020409@onelabs.com>
Message-ID: <200806221247.19829.niels_ole@salscheider-online.de>

Hello,

> > are there any plans to port coreboot to a recent AMD chipset like 780G /
> > SB700? I would like to see coreboot running on the ASUS M3A-H/HDMI.
>
> The AMD 690/600 is in the works.

That sounds great and I think that it won't be to difficult to move to AMD 
780G / SB700, will it?
Nevertheless, I cannot find any code for AMD 690 / SB600 in SVN - is it 
already there?

I think that we need further information concerning irq routing (I think I 
have to ask ASUS for it) as well as the southbridge (like the addresses 
passed to pci_write_config32, right? I have to ask AMD for that).
Do I need further information?

> > I am not very experienced in low-level programming but I am willing to
> > learn and to spend some time to port coreboot to that chipset.
> > How far is the progress of coreboot v3? Is it a good idea to use that
> > version or is it better to use coreboot v2 and port it to v3 as soon as
> > it is stable?
>
> Start with V2, then it can be moved into V3.

What is the difference between v2 and v3 / will it be difficult to move it?

> > The flash chip on the ASUS M3A-H/HDMI is a SPI chip like the one that can
> > be found on the GIGABYTE GA-M57SLI-S4. There is a second unused position,
> > too. Are there any limitations on the chips that can be used or can I use
> > any of the supported spi chips (like the MX25L3205)?
>
> Depends on the southbridge as far as how large the spi device may be.

The chip found on my mainboard is a MX25L8005 with 8MBit. Where can I buy a 
MX25L8005 or a larger chip (in Germay)? I have found 8MBit and 16Mbit spi 
chips on http://www.bios-fix.de (13,54? + 2,21?) but I cannot find the 
MX25L3205.

Kind regards

Ole



From ward at gnu.org  Sun Jun 22 14:33:36 2008
From: ward at gnu.org (Ward Vandewege)
Date: Sun, 22 Jun 2008 08:33:36 -0400
Subject: [coreboot] m57sli FAN control
In-Reply-To: <1214129130.2718.5.camel@amd-x2.grundel>
References: <20080610183457.GA32451@localdomain> <484EF2A0.7060507@zonnet.nl>
	<20080614193751.GA1295@localdomain>
	<1214129130.2718.5.camel@amd-x2.grundel>
Message-ID: <20080622123336.GA13126@localdomain>

Hi Ronald,

On Sun, Jun 22, 2008 at 12:05:30PM +0200, Ronald Hoogenboom wrote:
> I finally got round to test the 'final' patch and it looks fine on my V2
> board. What's the deal now? Do I do a signed-off-by and you do an ack?
> Or is my previous signed-off sufficient.

I think in this case you can probably do both a signed-off-by and an
acked-by, and I'll do the same, since we both worked on the patch and both
tested it.

Then I'll be very glad to commit it :)

Thanks!
Ward.

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



From peter at stuge.se  Sun Jun 22 16:22:34 2008
From: peter at stuge.se (Peter Stuge)
Date: Sun, 22 Jun 2008 16:22:34 +0200
Subject: [coreboot] flashrom: Remove dead M-Systems Disk on Chip code
In-Reply-To: <485E2859.6050506@coresystems.de>
References: <20080622025505.903.qmail@stuge.se>
	<485E2859.6050506@coresystems.de>
Message-ID: <20080622142234.32122.qmail@stuge.se>

On Sun, Jun 22, 2008 at 12:24:25PM +0200, Stefan Reinauer wrote:
> > The write function does nothing but print text. It has a call to
> > write_page_md2802() commented out, but that function does not
> > exist. This is dead code with ugly #ifdefs.
> 
> Absolutely NACK.

Please reconsider my patch.


> The reason the code is not compiled in per default is that the
> probing takes forever. Still, no reason to drop support.
> 
> I don't think we should drop features because we don't like a few
> ifdefs.

That is not the most important reason. Please look at the code. Probe
may actually work, but read, erase and write simply can not:


int read_md2802(struct flashchip *flash, uint8_t *buf)
{
        return 0;
}

int erase_md2802(struct flashchip *flash)
{
        volatile uint8_t *bios = flash->virtual_memory;

        return 1;

        *(volatile uint8_t *)(bios + 0x5555) = 0xAA;
        *(volatile uint8_t *)(bios + 0x2AAA) = 0x55;  
        *(volatile uint8_t *)(bios + 0x5555) = 0x80;

        *(volatile uint8_t *)(bios + 0x5555) = 0xAA;
        *(volatile uint8_t *)(bios + 0x2AAA) = 0x55;
        *(volatile uint8_t *)(bios + 0x5555) = 0x10;
}

int write_md2802(struct flashchip *flash, uint8_t *buf)
{
        int i;
        int total_size = flash->total_size * 1024;
        int page_size = flash->page_size;
        volatile uint8_t *bios = flash->virtual_memory;

        return (1);

Immediate return. But even if it had not been there:


        erase_md2802(flash);
        if (*bios != (uint8_t) 0xff) {
                printf("ERASE FAILED!\n");
                return -1;
        }
        printf("Programming page: ");
        for (i = 0; i < total_size / page_size; i++) {
                printf("%04d at address: 0x%08x", i, i * page_size);
                //write_page_md2802(bios, buf + i * page_size, bios + i * page_size, page_size);

This call is commented out because write_page_md2802() does not exist.


                printf("\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b");
        }
        printf("\n");
        //protect_md2802(bios);

        return 0;
}


The simple fact is that this flash driver is not complete. If a patch
had been sent to the list that added a driver like this today it
would have been NAKed by a screaming horde of people. :)

I don't know how to justify keeping this code around.


//Peter



From ronald at zonnet.nl  Sun Jun 22 16:26:21 2008
From: ronald at zonnet.nl (Ronald Hoogenboom)
Date: Sun, 22 Jun 2008 16:26:21 +0200
Subject: [coreboot] [patch] m57sli FAN control
In-Reply-To: <20080622123336.GA13126@localdomain>
References: <20080610183457.GA32451@localdomain> <484EF2A0.7060507@zonnet.nl>
	<20080614193751.GA1295@localdomain>
	<1214129130.2718.5.camel@amd-x2.grundel>
	<20080622123336.GA13126@localdomain>
Message-ID: <1214144781.2718.35.camel@amd-x2.grundel>

Finally automatic fan control for the gigabyte m57sli-s4 mainboard.

Signed-off-by: Ronald Hoogenboom <hoogenboom30 at zonnet.nl>
Acked-by: Ronald Hoogenboom <hoogenboom30 at zonnet.nl>


-------------- next part --------------
A non-text attachment was scrubbed...
Name: fanctl-m57sli-final.patch
Type: text/x-patch
Size: 3075 bytes
Desc: not available
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20080622/03ddf7aa/attachment.patch>

From svn at coreboot.org  Sun Jun 22 16:33:17 2008
From: svn at coreboot.org (svn at coreboot.org)
Date: Sun, 22 Jun 2008 16:33:17 +0200
Subject: [coreboot] r3381 - in trunk/coreboot-v2/src:
	mainboard/gigabyte/m57sli superio/ite/it8716f
Message-ID: <mailman.1647.1355071334.16123.coreboot@coreboot.org>

Author: ward
Date: 2008-06-22 16:33:17 +0200 (Sun, 22 Jun 2008)
New Revision: 3381

Modified:
   trunk/coreboot-v2/src/mainboard/gigabyte/m57sli/fanctl.c
   trunk/coreboot-v2/src/superio/ite/it8716f/superio.c
Log:

Enable hardware fan control for m57sli.

Tested on v1 and v2 of the board.

Signed-off-by: Ronald Hoogenboom <hoogenboom30 at zonnet.nl>
Signed-off-by: Ward Vandewege <ward at gnu.org>
Acked-by: Ronald Hoogenboom <hoogenboom30 at zonnet.nl>



Modified: trunk/coreboot-v2/src/mainboard/gigabyte/m57sli/fanctl.c
===================================================================
--- trunk/coreboot-v2/src/mainboard/gigabyte/m57sli/fanctl.c	2008-06-22 04:22:46 UTC (rev 3380)
+++ trunk/coreboot-v2/src/mainboard/gigabyte/m57sli/fanctl.c	2008-06-22 14:33:17 UTC (rev 3381)
@@ -9,16 +9,30 @@
 static const struct {
 	uint8_t index, value;
 } sequence[]= {
+	/* Make sure we can monitor, and enable SMI# interrupt output */
+	{ 0x00, 0x13},
+	/* Disable fan interrupt status bits for SMI# */
+	{ 0x04, 0x37},
+	/* Disable VIN interrupt status bits for SMI# */
+	{ 0x05, 0xff},
+	/* Disable fan interrupt status bits for IRQ */
+	{ 0x07, 0x37},
+	/* Disable VIN interrupt status bits for IRQ */
+	{ 0x08, 0xff},
+	/* Disable external sensor interrupt */
+	{ 0x09, 0x87},
+	/* Enable 16 bit counter divisors */
+	{ 0x0c, 0x07},
 	/* Set FAN_CTL control register (0x14) polarity to high, and
 	   activate fans 1, 2 and 3. */
-	{ 0x14, 0x87},
+	{ 0x14, 0xd7},
 	/* set the correct sensor types 1,2 thermistor; 3 diode */
 	{ 0x51, 0x1c},
-	/* set the 'zero' voltage for diode type sensor */
+	/* set the 'zero' voltage for diode type sensor 3 */
 	{ 0x5c, 0x80},
 //	{ 0x56, 0xe5},
 //	{ 0x57, 0xe5},
-	{ 0x59, 0xe5},
+	{ 0x59, 0xec},
 	{ 0x5c, 0x00},
 	/* fan1 (controlled by temp3) control parameters */
 	/* fan off limit */
@@ -33,14 +47,24 @@
 	{ 0x64, 0x90},
 	/* direct-down and interval */
 	{ 0x65, 0x03},
+	/* temperature limit of fan stop for fan3 (automatic) */
+	{ 0x70, 0xff},
+	/* temperature limit of fan start for fan3 (automatic) */
+	{ 0x71, 0x14},
+	/* Set PWM start & slope for fan3 */
+	{ 0x73, 0x20},
+	/* Initialize PWM automatic mode slope values for fan3 */
+	{ 0x74, 0x90},
+	/* set smartguardian temperature interval for fan3 */
+	{ 0x75, 0x03},
 	/* fan1 auto controlled by temp3 */
 	{ 0x15, 0x82},
-	/* fan2 soft controlled, max speed */
-	{ 0x16, 0x7f},
-	/* fan3 soft controlled, 75% speed */
-	{ 0x17, 0x60},
+	/* fan2 auto controlled by temp3 */
+	{ 0x16, 0x82},
+	/* fan3 auto controlled by temp3 */
+	{ 0x17, 0x82},
 	/* all fans enable, fan1 ctl smart */
-	{ 0x13, 0x71}
+	{ 0x13, 0x77}
 };
 
 #define ARRAYSIZE(x) sizeof x/sizeof *x

Modified: trunk/coreboot-v2/src/superio/ite/it8716f/superio.c
===================================================================
--- trunk/coreboot-v2/src/superio/ite/it8716f/superio.c	2008-06-22 04:22:46 UTC (rev 3380)
+++ trunk/coreboot-v2/src/superio/ite/it8716f/superio.c	2008-06-22 14:33:17 UTC (rev 3381)
@@ -50,6 +50,9 @@
 	pnp_write_config(dev, 0x02, 0x02);
 }
 
+#ifdef HAVE_FANCTL
+extern void init_ec(uint16_t base);
+#else
 static void pnp_write_index(uint16_t port_base, uint8_t reg, uint8_t value)
 {
 	outb(reg, port_base);
@@ -62,9 +65,6 @@
 	return inb(port_base + 1);
 }
 
-/* #ifdef HAVE_FANCTL
-extern void init_ec(uint16_t base);
-#else */
 static void init_ec(uint16_t base)
 {
 	uint8_t value;
@@ -80,7 +80,7 @@
 	printk_debug("FAN_CTL: reg = 0x%04x, writing value = 0x%02x\r\n",
 		     base + 0x14, value | 0x87);
 }
-//#endif
+#endif
 
 static void it8716f_init(device_t dev)
 {




From ward at gnu.org  Sun Jun 22 16:34:25 2008
From: ward at gnu.org (Ward Vandewege)
Date: Sun, 22 Jun 2008 10:34:25 -0400
Subject: [coreboot] [patch] m57sli FAN control
In-Reply-To: <1214144781.2718.35.camel@amd-x2.grundel>
References: <20080610183457.GA32451@localdomain> <484EF2A0.7060507@zonnet.nl>
	<20080614193751.GA1295@localdomain>
	<1214129130.2718.5.camel@amd-x2.grundel>
	<20080622123336.GA13126@localdomain>
	<1214144781.2718.35.camel@amd-x2.grundel>
Message-ID: <20080622143425.GB26763@localdomain>

On Sun, Jun 22, 2008 at 04:26:21PM +0200, Ronald Hoogenboom wrote:
> Finally automatic fan control for the gigabyte m57sli-s4 mainboard.
> 
> Signed-off-by: Ronald Hoogenboom <hoogenboom30 at zonnet.nl>
> Acked-by: Ronald Hoogenboom <hoogenboom30 at zonnet.nl>

r3381

Thanks,
Ward.

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



From svn at coreboot.org  Sun Jun 22 16:36:04 2008
From: svn at coreboot.org (svn at coreboot.org)
Date: Sun, 22 Jun 2008 16:36:04 +0200
Subject: [coreboot] r206 - buildrom-devel/config/platforms
Message-ID: <mailman.1648.1355071334.16123.coreboot@coreboot.org>

Author: ward
Date: 2008-06-22 16:36:04 +0200 (Sun, 22 Jun 2008)
New Revision: 206

Modified:
   buildrom-devel/config/platforms/m57sli.conf
Log:

Bump up m57sli revision to take advantage of new fan control code.

This is a trivial patch.

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



Modified: buildrom-devel/config/platforms/m57sli.conf
===================================================================
--- buildrom-devel/config/platforms/m57sli.conf	2008-06-20 20:49:00 UTC (rev 205)
+++ buildrom-devel/config/platforms/m57sli.conf	2008-06-22 14:36:04 UTC (rev 206)
@@ -30,7 +30,7 @@
 COREBOOT_VENDOR=gigabyte
 COREBOOT_BOARD=m57sli
 CBV2_TDIR=m57sli
-CBV2_TAG=3118
+CBV2_TAG=3381
 
 # FILO configuration
 




From c-d.hailfinger.devel.2006 at gmx.net  Sun Jun 22 16:40:03 2008
From: c-d.hailfinger.devel.2006 at gmx.net (Carl-Daniel Hailfinger)
Date: Sun, 22 Jun 2008 16:40:03 +0200
Subject: [coreboot] flashrom: Remove dead M-Systems Disk on Chip code
In-Reply-To: <485E2859.6050506@coresystems.de>
References: <20080622025505.903.qmail@stuge.se>
	<485E2859.6050506@coresystems.de>
Message-ID: <485E6443.6000900@gmx.net>

On 22.06.2008 12:24, Stefan Reinauer wrote:
> Peter Stuge wrote:
>   
>> Patch attached.
>>
>>
>> //Peter
>>   
>> flashrom: Remove dead M-Systems Disk on Chip code
>>
>> DOC support has been disabled by default for many years. The write function
>> does nothing but print text. It has a call to write_page_md2802() commented
>> out, but that function does not exist. This is dead code with ugly #ifdefs.
>>
>> Updates README to reflect that there was a time when there was code, but it
>> didn't work. Removes M-Systems #defines and also includes svn rm msys_doc.*
>>
>> Signed-off-by: Peter Stuge <peter at stuge.se>
>>     
>
> Absolutely NACK.
>
> The reason the code is not compiled in per default is that the probing
> takes forever. Still, no reason to drop support.
>   

No, the flashrom DoC code in subversion never worked. The write
functions were commented out already at the time flashrom was checked in
into the v2 tree at the end of the year 2003. The code in flashrom has
been useless since forever. By the way, I checked the DoC code in
another repository (v1 flash_and_burn), and that code also never worked.

> I don't think we should drop features because we don't like a few ifdefs.
>   

Agreed. Dropping code that _never_ worked is very reasonable, though.

Regards,
Carl-Daniel

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




From peter at stuge.se  Sun Jun 22 17:13:54 2008
From: peter at stuge.se (Peter Stuge)
Date: Sun, 22 Jun 2008 17:13:54 +0200
Subject: [coreboot] flashrom SC520 support
In-Reply-To: <485E290F.4030708@coresystems.de>
References: <20080622031808.18419.qmail@stuge.se>
	<485E290F.4030708@coresystems.de>
Message-ID: <20080622151354.8960.qmail@stuge.se>

On Sun, Jun 22, 2008 at 12:27:27PM +0200, Stefan Reinauer wrote:
> > Who remembers details about this guy?
> >
> > flashrom hardcodes the flash chip address to 0x9400000 with
> > -DTS5300 instead of the regular 4G-flash chip size.
..
> > I want to get rid of the #define. Probe it or lose it!
> 
> I say NACK to dropping this code.
> 
> Please don't get the code drop frenzy! There are enough other open
> working lots.

Just a little cleaning up.


> On the TS5300 it was strapped to 0x9400000, other SC520 systems
> may be configured differently. But basically all have their flash
> at non-standard positions afaik.

Hm? You say strapped, to me that means controlled by board
design/jumpers. Is the address always set by hardware, and
then that address is readable in the PAR registers?


> If you want to write code to do the probing, I'll gladly ACK it.

I won't write that until it can be tested by someone before commit.


> I can't test anymore - the TS5300 stayed back at the linuxtag in
> 07. No idea what happened to it.

Maybe Carsten still has it?

Does anyone else have access to a SC520 system?

I hope you agree that it is not so useful to spend time on adding
support for a 7+ year old board, which noone can test on, that has
already been compiled out of the utility by default since forever.


//Peter



From peter at stuge.se  Sun Jun 22 17:20:38 2008
From: peter at stuge.se (Peter Stuge)
Date: Sun, 22 Jun 2008 17:20:38 +0200
Subject: [coreboot] r3378 - trunk/util/flashrom
In-Reply-To: <485E29AB.60001@coresystems.de>
References: <485E29AB.60001@coresystems.de>
Message-ID: <20080622152038.14735.qmail@stuge.se>

On Sun, Jun 22, 2008 at 12:30:03PM +0200, Stefan Reinauer wrote:
> >  clean:
> > -	rm -f *.o *~
> > +	rm -f $(PROGRAM) *.o *~
> >  
> >  distclean: clean
> > -	rm -f $(PROGRAM) .dependencies
> > -	
> > +	rm -f .dependencies
> > +
> 
> Sorry, I don't like this ...

Don't like the self-ack or the actual change?


> it's not cleaning up but changing the behavior.

I agree this is a change in build system behavior and for that reason
it might not have been so nice to self-ack. However, it harmonizes
flashrom with pretty much every other tool I have built. It's not
very common for "make clean" to leave the binary around, thus I think
the change (making flashrom's build system more intuitive) is trivial
enough to self-ack.

As always I am very open to discussion!


//Peter



From svn at coreboot.org  Sun Jun 22 19:06:41 2008
From: svn at coreboot.org (svn at coreboot.org)
Date: Sun, 22 Jun 2008 19:06:41 +0200
Subject: [coreboot] r3382 - trunk/util/flashrom
Message-ID: <mailman.1649.1355071334.16123.coreboot@coreboot.org>

Author: stepan
Date: 2008-06-22 19:06:41 +0200 (Sun, 22 Jun 2008)
New Revision: 3382

Removed:
   trunk/util/flashrom/msys_doc.c
   trunk/util/flashrom/msys_doc.h
Modified:
   trunk/util/flashrom/Makefile
   trunk/util/flashrom/README
   trunk/util/flashrom/flash.h
   trunk/util/flashrom/flashchips.c
Log:
flashrom: Remove dead M-Systems Disk on Chip code

DOC support has been disabled by default for many years. The write function
does nothing but print text. It has a call to write_page_md2802() commented
out, but that function does not exist. This is dead code with ugly #ifdefs.

Updates README to reflect that there was a time when there was code, but it
didn't work. Removes M-Systems #defines and also includes svn rm msys_doc.*

Signed-off-by: Peter Stuge <peter at stuge.se>
Acked-by: Stefan Reinauer <stepan at coresystems.de>



Modified: trunk/util/flashrom/Makefile
===================================================================
--- trunk/util/flashrom/Makefile	2008-06-22 14:33:17 UTC (rev 3381)
+++ trunk/util/flashrom/Makefile	2008-06-22 17:06:41 UTC (rev 3382)
@@ -11,7 +11,7 @@
 INSTALL = /usr/bin/install
 PREFIX  = /usr/local
 #CFLAGS  = -O2 -g -Wall -Werror
-CFLAGS  = -Os -Wall -Werror -DDISABLE_DOC # -DTS5300
+CFLAGS  = -Os -Wall -Werror # -DTS5300
 OS_ARCH	= $(shell uname)
 ifeq ($(OS_ARCH), SunOS)
 LDFLAGS = -lpci -lz
@@ -26,7 +26,7 @@
 
 OBJS = chipset_enable.o board_enable.o udelay.o jedec.o stm50flw0x0x.o \
 	sst28sf040.o am29f040b.o mx29f002.o sst39sf020.o m29f400bt.o \
-	w49f002u.o 82802ab.o msys_doc.o pm49fl00x.o sst49lf040.o \
+	w49f002u.o 82802ab.o pm49fl00x.o sst49lf040.o \
 	sst49lfxxxc.o sst_fwhub.o layout.o cbtable.o flashchips.o \
 	flashrom.o w39v080fa.o sharplhf00l04.o w29ee011.o spi.o it87spi.o \
 	ichspi.o

Modified: trunk/util/flashrom/README
===================================================================
--- trunk/util/flashrom/README	2008-06-22 14:33:17 UTC (rev 3381)
+++ trunk/util/flashrom/README	2008-06-22 17:06:41 UTC (rev 3382)
@@ -98,8 +98,10 @@
 Disk on Chip support
 --------------------
 
-Disk on Chip support is currently disabled since it is considered unstable.
-Change CFLAGS in the Makefile to enable it: Remove -DDISABLE_DOC from CFLAGS.
+Disk on Chip support was removed from flashrom in r3380. It had already
+been disabled by default in flashrom for several years because the code
+was considered unstable and incomplete. The products intended to work
+have been End-Of-Lifed by the manufacturer for a long time.
 
 
 Supported Flash Chips
@@ -113,7 +115,6 @@
 EMST F49B002UA
 Intel 82802AB (Firmware Hub) 
 Intel 82802AC (Firmware Hub) 
-M-Systems MD-2802 (unsupported, disabled by default)
 MX MX-29F002
 PMC PMC-49FL002
 PMC PMC-49FL004

Modified: trunk/util/flashrom/flash.h
===================================================================
--- trunk/util/flashrom/flash.h	2008-06-22 14:33:17 UTC (rev 3381)
+++ trunk/util/flashrom/flash.h	2008-06-22 17:06:41 UTC (rev 3382)
@@ -192,11 +192,6 @@
 
 #define ISSI_ID			0xD5	/* ISSI Integrated Silicon Solutions */
 
-#define MSYSTEMS_ID		0x156F	/* M-Systems, not listed in JEP106W */
-#define MSYSTEMS_MD2200		0xDB
-#define MSYSTEMS_MD2800		0x30	/* hmm -- both 0x30 */
-#define MSYSTEMS_MD2802		0x30	/* hmm -- both 0x30 */
-
 /*
  * MX25 chips are SPI, first byte of device ID is memory type,
  * second byte of device ID is log(bitsize)-9.

Modified: trunk/util/flashrom/flashchips.c
===================================================================
--- trunk/util/flashrom/flashchips.c	2008-06-22 14:33:17 UTC (rev 3381)
+++ trunk/util/flashrom/flashchips.c	2008-06-22 17:06:41 UTC (rev 3382)
@@ -21,9 +21,6 @@
  */
 
 #include "flash.h"
-#ifndef DISABLE_DOC
-#include "msys_doc.h"
-#endif
 
 /**
  * List of supported flash ROM chips.
@@ -58,9 +55,6 @@
 	{"Macronix",	"MX25L1605",		MX_ID,		MX_25L1605,		2048,	256,		TEST_UNTESTED,	probe_spi_rdid,		spi_chip_erase_c7,	spi_chip_write,	spi_chip_read},
 	{"Macronix",	"MX25L3205",		MX_ID,		MX_25L3205,		4096,	256,		TEST_OK_PREW,	probe_spi_rdid,		spi_chip_erase_c7,	spi_chip_write,	spi_chip_read},
 	{"Macronix",	"MX29F002",		MX_ID,		MX_29F002,		256,	64 * 1024,	TEST_UNTESTED,	probe_29f002,		erase_29f002,			write_29f002},
-#ifndef DISABLE_DOC
-	{"M-Systems",	"MD-2802",		MSYSTEMS_ID,	MSYSTEMS_MD2802,	8,	8 * 1024,	TEST_UNTESTED,	probe_md2802,		erase_md2802,			write_md2802,		read_md2802},
-#endif
 	{"PMC",		"Pm25LV010",		PMC_ID,		PMC_25LV010,		128,	256,		TEST_UNTESTED,	probe_spi_rdid,		spi_chip_erase_c7,	spi_chip_write,	spi_chip_read},
 	{"PMC",		"Pm25LV016B",		PMC_ID,		PMC_25LV016B,		2048,	256,		TEST_UNTESTED,	probe_spi_rdid,		spi_chip_erase_c7,	spi_chip_write,	spi_chip_read},
 	{"PMC",		"Pm25LV020",		PMC_ID,		PMC_25LV020,		256,	256,		TEST_UNTESTED,	probe_spi_rdid,		spi_chip_erase_c7,	spi_chip_write,	spi_chip_read},

Deleted: trunk/util/flashrom/msys_doc.c
===================================================================
--- trunk/util/flashrom/msys_doc.c	2008-06-22 14:33:17 UTC (rev 3381)
+++ trunk/util/flashrom/msys_doc.c	2008-06-22 17:06:41 UTC (rev 3382)
@@ -1,250 +0,0 @@
-/*
- * This file is part of the flashrom project.
- *
- * Copyright (C) 2003 Niki W. Waibel <niki.waibel at gmx.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 <stdio.h>
-#include <unistd.h>
-#include "flash.h"
-#include "msys_doc.h"
-
-static int doc_wait(volatile uint8_t *bios, int timeout);
-static uint8_t doc_read_chipid(volatile uint8_t *bios);
-static uint8_t doc_read_docstatus(volatile uint8_t *bios);
-static uint8_t doc_read_cdsncontrol(volatile uint8_t *bios);
-static void doc_write_cdsncontrol(volatile uint8_t *bios, uint8_t data);
-
-int probe_md2802(struct flashchip *flash)
-{
-	volatile uint8_t *bios = flash->virtual_memory;
-	uint8_t chipid;
-#ifndef MSYSTEMS_DOC_NO_55AA_CHECKING
-	uint8_t id_0x55, id_0xAA;
-#endif				/* !MSYSTEMS_DOC_NO_55AA_CHECKING */
-	int i, toggle_a, toggle_b;
-
-	printf_debug("%s:\n", __FUNCTION__);
-	printf_debug("%s: *******************************\n", __FUNCTION__);
-	printf_debug("%s: * THIS IS A PRE ALPHA VERSION *\n", __FUNCTION__);
-	printf_debug("%s: * IN THE DEVELOPEMENT *********\n", __FUNCTION__);
-	printf_debug("%s: * PROCESS RIGHT NOW. **********\n", __FUNCTION__);
-	printf_debug("%s: *******************************\n", __FUNCTION__);
-	printf_debug("%s: * IF YOU ARE NOT A DEVELOPER **\n", __FUNCTION__);
-	printf_debug("%s: * THEN DO NOT TRY TO READ OR **\n", __FUNCTION__);
-	printf_debug("%s: * WRITE TO THIS DEVICE ********\n", __FUNCTION__);
-	printf_debug("%s: *******************************\n", __FUNCTION__);
-	printf_debug("%s:\n", __FUNCTION__);
-
-	printf_debug("%s: switching off reset mode ...\n", __FUNCTION__);
-	doc_write(0x85, bios, DOCControl);
-	doc_write(0x85, bios, DOCControl);
-	doc_read_4nop(bios);
-	if (doc_wait(bios, 5000))
-		return (-1);
-	printf("%s: switching off reset mode ... done\n", __FUNCTION__);
-	printf("%s:\n", __FUNCTION__);
-
-	printf("%s: switching off write protection ...\n", __FUNCTION__);
-	doc_write_cdsncontrol(bios, doc_read_cdsncontrol(bios) & (~0x08));
-	printf("%s: switching off write protection ... done\n", __FUNCTION__);
-	printf("%s:\n", __FUNCTION__);
-
-	chipid = doc_read_chipid(bios);
-#ifndef MSYSTEMS_DOC_NO_55AA_CHECKING
-	id_0x55 = doc_read(bios, IPL_0x0000);
-	id_0xAA = doc_read(bios, IPL_0x0001);
-#endif				/* !MSYSTEMS_DOC_NO_55AA_CHECKING */
-	printf("%s: IPL_0x0000: 0x%02x\n", __FUNCTION__, id_0x55);
-	printf("%s: IPL_0x0001: 0x%02x\n", __FUNCTION__, id_0xAA);
-	printf("%s: IPL_0x0002: 0x%02x\n", __FUNCTION__,
-	       doc_read(bios, IPL_0x0002));
-	printf("%s: IPL_0x0003: 0x%02x\n", __FUNCTION__,
-	       doc_read(bios, IPL_0x0003));
-	printf("%s:\n", __FUNCTION__);
-	printf("%s: ChipID: 0x%02x\n", __FUNCTION__, chipid);
-	printf("%s: DOCStatus: 0x%02x\n", __FUNCTION__,
-	       doc_read_docstatus(bios));
-	printf("%s: FloorSelect: 0x%02x\n", __FUNCTION__,
-	       doc_read(bios, FloorSelect));
-	printf("%s: CDSNControl: 0x%02x\n", __FUNCTION__,
-	       doc_read_cdsncontrol(bios));
-	printf("%s: CDSNDeviceSelect: 0x%02x\n", __FUNCTION__,
-	       doc_read(bios, CDSNDeviceSelect));
-	printf("%s: ECCConfiguration: 0x%02x\n", __FUNCTION__,
-	       doc_read(bios, ECCConfiguration));
-	printf("%s: CDSNSlowIO: 0x%02x\n", __FUNCTION__,
-	       doc_read(bios, CDSNSlowIO));
-	printf("%s: ECCSyndrome0: 0x%02x\n", __FUNCTION__,
-	       doc_read(bios, ECCSyndrome0));
-	printf("%s: ECCSyndrome1: 0x%02x\n", __FUNCTION__,
-	       doc_read(bios, ECCSyndrome1));
-	printf("%s: ECCSyndrome2: 0x%02x\n", __FUNCTION__,
-	       doc_read(bios, ECCSyndrome2));
-	printf("%s: ECCSyndrome3: 0x%02x\n", __FUNCTION__,
-	       doc_read(bios, ECCSyndrome3));
-	printf("%s: ECCSyndrome4: 0x%02x\n", __FUNCTION__,
-	       doc_read(bios, ECCSyndrome4));
-	printf("%s: ECCSyndrome5: 0x%02x\n", __FUNCTION__,
-	       doc_read(bios, ECCSyndrome5));
-	printf("%s: AliasResolution: 0x%02x\n", __FUNCTION__,
-	       doc_read(bios, AliasResolution));
-	printf("%s: ConfigurationInput: 0x%02x\n", __FUNCTION__,
-	       doc_read(bios, ConfigurationInput));
-	printf("%s: ReadPipelineInitialization: 0x%02x\n", __FUNCTION__,
-	       doc_read(bios, ReadPipelineInitialization));
-	printf("%s: LastDataRead: 0x%02x\n", __FUNCTION__,
-	       doc_read(bios, LastDataRead));
-	printf("%s:\n", __FUNCTION__);
-
-	printf("%s: checking ECCConfiguration toggle bit\n", __FUNCTION__);
-	printf("%s:", __FUNCTION__);
-	toggle_a = toggle_b = 0;
-	for (i = 0; i < 10; i++) {
-		uint8_t toggle = doc_toggle(bios);
-
-		printf(" 0x%02x", toggle);
-
-		if (i % 2)
-			toggle_a += toggle;
-		else
-			toggle_b += toggle;
-	}			/* for(i=0; i<10; i++) */
-	printf("\n%s: toggle result: %d/%d\n", __FUNCTION__, toggle_a,
-	       toggle_b);
-
-	if (chipid == flash->model_id && ((toggle_a == 5 && toggle_b == 0)
-					  || (toggle_a == 0 && toggle_b == 5))
-#ifndef MSYSTEMS_DOC_NO_55AA_CHECKING
-	    && id_0x55 == 0x55 && id_0xAA == 0xaa
-#endif				/* !MSYSTEMS_DOC_NO_55AA_CHECKING */
-	    ) {
-		return 1;
-	}
-
-	return 0;
-}
-
-int read_md2802(struct flashchip *flash, uint8_t *buf)
-{
-	return 0;
-}
-
-int erase_md2802(struct flashchip *flash)
-{
-	volatile uint8_t *bios = flash->virtual_memory;
-
-	return 1;
-
-	*(volatile uint8_t *)(bios + 0x5555) = 0xAA;
-	*(volatile uint8_t *)(bios + 0x2AAA) = 0x55;
-	*(volatile uint8_t *)(bios + 0x5555) = 0x80;
-
-	*(volatile uint8_t *)(bios + 0x5555) = 0xAA;
-	*(volatile uint8_t *)(bios + 0x2AAA) = 0x55;
-	*(volatile uint8_t *)(bios + 0x5555) = 0x10;
-}
-
-int write_md2802(struct flashchip *flash, uint8_t *buf)
-{
-	int i;
-	int total_size = flash->total_size * 1024;
-	int page_size = flash->page_size;
-	volatile uint8_t *bios = flash->virtual_memory;
-
-	return (1);
-	erase_md2802(flash);
-	if (*bios != (uint8_t) 0xff) {
-		printf("ERASE FAILED!\n");
-		return -1;
-	}
-	printf("Programming page: ");
-	for (i = 0; i < total_size / page_size; i++) {
-		printf("%04d at address: 0x%08x", i, i * page_size);
-		//write_page_md2802(bios, buf + i * page_size, bios + i * page_size, page_size);
-		printf
-		    ("\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b");
-	}
-	printf("\n");
-	//protect_md2802(bios);
-
-	return 0;
-}				/* int write_md2802(struct flashchip *flash, uint8_t *buf) */
-
-/*
-	wait timeout msec for doc to become ready
-	return:
-		0: ready
-		-1: timeout expired
-*/
-
-static int doc_wait(volatile uint8_t *bios, int timeout)
-{
-	int i = 20;
-
-	doc_read_4nop(bios);
-
-	while (_doc_busy(bios) && (i != 0)) {
-		usleep(timeout * 1000 / 20);
-		i--;
-	}
-
-	doc_read_2nop(bios);
-
-	if (_doc_busy(bios)) {
-		doc_read_2nop(bios);
-		return (-1);
-	}
-
-	return 0;
-}
-
-static uint8_t doc_read_docstatus(volatile uint8_t *bios)
-{
-	doc_read(bios, CDSNSlowIO);
-	doc_read_2nop(bios);
-
-	return (doc_read(bios, _DOCStatus));
-}
-
-static uint8_t doc_read_chipid(volatile uint8_t *bios)
-{
-	doc_read(bios, CDSNSlowIO);
-	doc_read_2nop(bios);
-
-	return (doc_read(bios, _ChipID));
-}
-
-static uint8_t doc_read_cdsncontrol(volatile uint8_t *bios)
-{
-	uint8_t value;
-
-	/* the delays might be necessary when reading the busy bit,
-	   but because a read to this reg reads the busy bit
-	   anyway we better do this delays... */
-	doc_read_4nop(bios);
-	value = doc_read(bios, _CDSNControl);
-	doc_read_2nop(bios);
-
-	return value;
-}
-
-static void doc_write_cdsncontrol(volatile uint8_t *bios, uint8_t data)
-{
-	doc_write(data, bios, _CDSNControl);
-	doc_read_4nop(bios);
-}

Deleted: trunk/util/flashrom/msys_doc.h
===================================================================
--- trunk/util/flashrom/msys_doc.h	2008-06-22 14:33:17 UTC (rev 3381)
+++ trunk/util/flashrom/msys_doc.h	2008-06-22 17:06:41 UTC (rev 3382)
@@ -1,99 +0,0 @@
-/*
- * This file is part of the flashrom project.
- *
- * Copyright (C) 2003 Niki W. Waibel <niki.waibel at gmx.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
- */
-
-#ifndef __MSYS_DOC_H__
-#define __MSYS_DOC_H__ 1
-
-/* idea from include/linux/mtd/doc2000.h */
-/* registers with __ should not be read/written directly */
-#define MSYSTEMS_DOC_R__ChipID                    0x1000
-#define MSYSTEMS_DOC_R__DOCStatus                 0x1001
-#define MSYSTEMS_DOC_W_DOCControl                 0x1002
-#define MSYSTEMS_DOC_R_FloorSelect                0x1003
-#define MSYSTEMS_DOC_W_FloorSelect                0x1003
-#define MSYSTEMS_DOC_R__CDSNControl               0x1004
-#define MSYSTEMS_DOC_W__CDSNControl               0x1004
-#define MSYSTEMS_DOC_R_CDSNDeviceSelect           0x1005
-#define MSYSTEMS_DOC_W_CDSNDeviceSelect           0x1005
-#define MSYSTEMS_DOC_R_ECCConfiguration           0x1006
-#define MSYSTEMS_DOC_W_ECCConfiguration           0x1006
-#define MSYSTEMS_DOC_R_CDSNSlowIO                 0x100d
-#define MSYSTEMS_DOC_W_CDSNSlowIO                 0x100d
-#define MSYSTEMS_DOC_R_ECCSyndrome0               0x1010
-#define MSYSTEMS_DOC_R_ECCSyndrome1               0x1011
-#define MSYSTEMS_DOC_R_ECCSyndrome2               0x1012
-#define MSYSTEMS_DOC_R_ECCSyndrome3               0x1013
-#define MSYSTEMS_DOC_R_ECCSyndrome4               0x1014
-#define MSYSTEMS_DOC_R_ECCSyndrome5               0x1015
-#define MSYSTEMS_DOC_R_AliasResolution            0x101b
-#define MSYSTEMS_DOC_W_AliasResolution            0x101b
-#define MSYSTEMS_DOC_R_ConfigurationInput         0x101c
-#define MSYSTEMS_DOC_W_ConfigurationInput         0x101c
-#define MSYSTEMS_DOC_R_ReadPipelineInitialization 0x101d
-#define MSYSTEMS_DOC_W_WritePipelineTermination   0x101e
-#define MSYSTEMS_DOC_R_LastDataRead               0x101f
-#define MSYSTEMS_DOC_W_LastDataRead               0x101f
-#define MSYSTEMS_DOC_R_NOP                        0x1020
-#define MSYSTEMS_DOC_W_NOP                        0x1020
-
-#define MSYSTEMS_DOC_R_IPL_0x0000                 0x0000
-#define MSYSTEMS_DOC_R_IPL_0x0001                 0x0001
-#define MSYSTEMS_DOC_R_IPL_0x0002                 0x0002
-#define MSYSTEMS_DOC_R_IPL_0x0003                 0x0003
-
-#define MSYSTEMS_DOC_R_CDSNIO_BASE                0x0800
-#define MSYSTEMS_DOC_W_CDSNIO_BASE                0x0800
-
-#define doc_read(base,reg) \
-	(*(volatile uint8_t *)(base + MSYSTEMS_DOC_R_##reg))
-
-#define doc_read_nop(base) \
-	doc_read(base, NOP)
-
-#define doc_read_2nop(base) \
-	{ doc_read_nop(base); doc_read_nop(base); }
-
-#define doc_read_4nop(base) \
-	{ doc_read_2nop(base); doc_read_2nop(base); }
-
-#define doc_write(data,base,reg) \
-	(*(volatile uint8_t *)(base + MSYSTEMS_DOC_W_##reg)) = data
-
-#define doc_write_nop(base) \
-	doc_write(0, base, NOP)
-
-#define doc_write_2nop(base) \
-	{ doc_write_nop(base); doc_write_nop(base); }
-
-#define doc_write_4nop(base) \
-	{ doc_write_2nop(base); doc_write_2nop(base); }
-
-#define _doc_busy(base)   /* 0: ready; -1: busy */ \
-	( ((doc_read(base, _CDSNControl) & 0x80) >> 7) - 1)
-
-#define doc_toggle(base)   /* 0, 1, 0, 1, 0, 1, ... if a doc is present */ \
-	( (doc_read(base, ECCConfiguration) & 0x04) >> 2 )
-
-int probe_md2802(struct flashchip *flash);
-int read_md2802(struct flashchip *flash, uint8_t *buf);
-int erase_md2802(struct flashchip *flash);
-int write_md2802(struct flashchip *flash, uint8_t *buf);
-
-#endif				/* !__MSYS_DOC_H__ */




From stepan at coresystems.de  Sun Jun 22 19:14:32 2008
From: stepan at coresystems.de (Stefan Reinauer)
Date: Sun, 22 Jun 2008 19:14:32 +0200
Subject: [coreboot] r3378 - trunk/util/flashrom
In-Reply-To: <20080622152038.14735.qmail@stuge.se>
References: <485E29AB.60001@coresystems.de>
	<20080622152038.14735.qmail@stuge.se>
Message-ID: <485E8878.8050902@coresystems.de>

Peter Stuge wrote:
>> Sorry, I don't like this ...
>>     
>
> Don't like the self-ack or the actual change?
>   
yes.

>> it's not cleaning up but changing the behavior.
>>     
>
> I agree this is a change in build system behavior and for that reason
> it might not have been so nice to self-ack. However, it harmonizes
> flashrom with pretty much every other tool I have built. It's not
> very common for "make clean" to leave the binary around, thus I think
> the change (making flashrom's build system more intuitive) is trivial
> enough to self-ack.
>
> As always I am very open to discussion!
>   
I don't think this gets better by extending the discussion. It's far
easier to fix the few scripts this breaks than to start another lengthy
discussion.

We might want to consider dropping distclean completely, by the same
reasons you brought for your current behavior.

I checked the other makefiles around and most of them indeed clean the
binary in make clean, not make distclean.

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 svn at coreboot.org  Sun Jun 22 19:15:03 2008
From: svn at coreboot.org (svn at coreboot.org)
Date: Sun, 22 Jun 2008 19:15:03 +0200
Subject: [coreboot] r3383 - trunk/util/inteltool
Message-ID: <mailman.1650.1355071334.16123.coreboot@coreboot.org>

Author: stepan
Date: 2008-06-22 19:15:03 +0200 (Sun, 22 Jun 2008)
New Revision: 3383

Modified:
   trunk/util/inteltool/Makefile
Log:
as per Peter's suggestion. clean binary in make clean
Signed-off-by: Stefan Reinauer <stepan at coresystems.de>
Acked-by: Stefan Reinauer <stepan at coresystems.de>



Modified: trunk/util/inteltool/Makefile
===================================================================
--- trunk/util/inteltool/Makefile	2008-06-22 17:06:41 UTC (rev 3382)
+++ trunk/util/inteltool/Makefile	2008-06-22 17:15:03 UTC (rev 3383)
@@ -35,10 +35,10 @@
 	$(CC) -o $(PROGRAM) $(OBJS) $(LDFLAGS)
 
 clean:
-	rm -f *.o *~
+	rm -f $(PROGRAM) *.o *~
 
 distclean: clean
-	rm -f $(PROGRAM) .dependencies
+	rm -f .dependencies
 
 dep:
 	@$(CC) -MM *.c > .dependencies




From stepan at coresystems.de  Sun Jun 22 19:20:22 2008
From: stepan at coresystems.de (Stefan Reinauer)
Date: Sun, 22 Jun 2008 19:20:22 +0200
Subject: [coreboot] flashrom SC520 support
In-Reply-To: <20080622151354.8960.qmail@stuge.se>
References: <20080622031808.18419.qmail@stuge.se>	<485E290F.4030708@coresystems.de>
	<20080622151354.8960.qmail@stuge.se>
Message-ID: <485E89D6.7080404@coresystems.de>

Peter Stuge wrote:
>> On the TS5300 it was strapped to 0x9400000, other SC520 systems
>> may be configured differently. But basically all have their flash
>> at non-standard positions afaik.
>>     
>
> Hm? You say strapped, to me that means controlled by board
> design/jumpers. Is the address always set by hardware, and
> then that address is readable in the PAR registers?
>   
I hint you to the SC520 manuals on AMDs web page.

> Does anyone else have access to a SC520 system?
>
> I hope you agree that it is not so useful to spend time on adding
> support for a 7+ year old board, which noone can test on, that has
> already been compiled out of the utility by default since forever.
>   
Absolutely my point. This is why the current state is possibly the best
it can get in this regard.

We won't drop coreboot support for sc520 either, just because the
default case (ie. compiling a K8 or LX target) does not include that
code (.. since many years)

That code worked fine when I last tested it last year, so there's
absolutely no reason to remove it.

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 svn at coreboot.org  Sun Jun 22 19:54:05 2008
From: svn at coreboot.org (svn at coreboot.org)
Date: Sun, 22 Jun 2008 19:54:05 +0200
Subject: [coreboot] r3384 - trunk/util/flashrom
Message-ID: <mailman.1651.1355071334.16123.coreboot@coreboot.org>

Author: stuge
Date: 2008-06-22 19:54:03 +0200 (Sun, 22 Jun 2008)
New Revision: 3384

Modified:
   trunk/util/flashrom/README
Log:
flashrom: A few changes were committed before the DoC remove, update README.

Signed-off-by: Peter Stuge <peter at stuge.se>
Acked-by: Peter Stuge <peter at stuge.se>


Modified: trunk/util/flashrom/README
===================================================================
--- trunk/util/flashrom/README	2008-06-22 17:15:03 UTC (rev 3383)
+++ trunk/util/flashrom/README	2008-06-22 17:54:03 UTC (rev 3384)
@@ -98,7 +98,7 @@
 Disk on Chip support
 --------------------
 
-Disk on Chip support was removed from flashrom in r3380. It had already
+Disk on Chip support was removed from flashrom in r3382. It had already
 been disabled by default in flashrom for several years because the code
 was considered unstable and incomplete. The products intended to work
 have been End-Of-Lifed by the manufacturer for a long time.




From peter at stuge.se  Sun Jun 22 19:54:55 2008
From: peter at stuge.se (Peter Stuge)
Date: Sun, 22 Jun 2008 19:54:55 +0200
Subject: [coreboot] r3382 - trunk/util/flashrom
Message-ID: <20080622175455.13920.qmail@stuge.se>

On Sun, Jun 22, 2008 at 07:06:41PM +0200, svn at coreboot.org wrote:
> Author: stepan
> Log:
> flashrom: Remove dead M-Systems Disk on Chip code

Awesome! Thanks a lot for reviewing!


//Peter



From peter at stuge.se  Sun Jun 22 20:18:44 2008
From: peter at stuge.se (Peter Stuge)
Date: Sun, 22 Jun 2008 20:18:44 +0200
Subject: [coreboot] flashrom SC520 support
In-Reply-To: <485E89D6.7080404@coresystems.de>
References: <20080622031808.18419.qmail@stuge.se>
	<485E290F.4030708@coresystems.de>
	<20080622151354.8960.qmail@stuge.se>
	<485E89D6.7080404@coresystems.de>
Message-ID: <20080622181844.1602.qmail@stuge.se>

On Sun, Jun 22, 2008 at 07:20:22PM +0200, Stefan Reinauer wrote:
> > Hm? You say strapped, to me that means controlled by board
> > design/jumpers. Is the address always set by hardware, and
> > then that address is readable in the PAR registers?
> 
> I hint you to the SC520 manuals on AMDs web page.

Yeah, already had a look at some of them, nothing in the register
doc, but I didn't yet check the users's guide even though it is
supposed to detail BOOTCS# stuff.


> > I hope you agree that it is not so useful to spend time on adding
> > support for a 7+ year old board, which noone can test on, that has
> > already been compiled out of the utility by default since forever.
> 
> Absolutely my point. This is why the current state is possibly the
> best it can get in this regard.
..
> That code worked fine when I last tested it last year, so there's
> absolutely no reason to remove it.

Fair enough!

If someone has a board with the SC520 and can help test, please speak
up so we can have a generic board enable. (Carsten, still tuned in?
Do you remember if you saw Stefan's board? I don't remember seeing it
when we packed but it was a while ago. :\ )


//Peter



From svn at coreboot.org  Sun Jun 22 20:50:26 2008
From: svn at coreboot.org (svn at coreboot.org)
Date: Sun, 22 Jun 2008 20:50:26 +0200
Subject: [coreboot] r3385 - trunk/util/flashrom
Message-ID: <mailman.1652.1355071334.16123.coreboot@coreboot.org>

Author: uwe
Date: 2008-06-22 20:50:25 +0200 (Sun, 22 Jun 2008)
New Revision: 3385

Modified:
   trunk/util/flashrom/README
   trunk/util/flashrom/flashrom.8
Log:
Some flashrom documentation fixes, and removal of duplicated info (trivial).

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



Modified: trunk/util/flashrom/README
===================================================================
--- trunk/util/flashrom/README	2008-06-22 17:54:03 UTC (rev 3384)
+++ trunk/util/flashrom/README	2008-06-22 18:50:25 UTC (rev 3385)
@@ -11,11 +11,10 @@
 Build Requirements
 ------------------
 
-To build the flashrom utility you need to have the following packages
-installed on your Linux system:
+To build the flashrom utility you need to install the following packages:
 
 * pciutils
-* pciutils-devel / pciutils-dev
+* pciutils-devel / pciutils-dev / libpci-dev
 * zlib-devel / zlib1g-dev
 
 
@@ -49,22 +48,13 @@
 (parse DMI as well in future?). If no coreboot table could be read
 or if you want to override these values, you can specify -m, e.g.:
 
-  flashrom -w --mainboard AGAMI:ARUMA agami_aruma.rom
+ $ flashrom -w --mainboard AGAMI:ARUMA agami_aruma.rom
 
-The following boards require the specification of the board name, if
-no coreboot table is found:
+See the 'Supported mainboards' section in the output of 'flashrom -L' for
+a list of boards which require the specification of the board name, if no
+coreboot table is found.
 
-* IWILL DK8-HTX: use -m iwill:dk8_htx
-* Agami Aruma: use -m AGAMI:ARUMA
-* ASUS P5A: use -m asus:p5a
-* IBM x3455: use -m ibm:x3455
-* EPoX EP-BX3: use -m epox:ep-bx3
-* GIGABYTE GA-M57SLI-S4 v2.0: use -m gigabyte:m57sli
-* GIGABYTE GA-M61P-S3: use -m gigabyte:m61p
-* MSI K8N Neo3: use -m msi:k8n-neo3
-* Acorp 6A815EPD: use -m acorp:6a815epd
 
-
 ROM Layout Support
 ------------------
 
@@ -104,90 +94,11 @@
 have been End-Of-Lifed by the manufacturer for a long time.
 
 
-Supported Flash Chips
----------------------
+Supported Flash Chips / Chipsets / Mainboards
+---------------------------------------------
 
-AMD AM-29F040B
-AMD AM-29F016D
-ASD AE49F2008
-Atmel AT-29C040A
-Atmel AT-29C020
-EMST F49B002UA
-Intel 82802AB (Firmware Hub) 
-Intel 82802AC (Firmware Hub) 
-MX MX-29F002
-PMC PMC-49FL002
-PMC PMC-49FL004
-Sharp LHF-00L04
-Spansion S25FL016A
-SST SST-29EE020A
-SST SST-28SF040A
-SST SST-39SF010A
-SST SST-39SF020A
-SST SST-39SF040
-SST SST-39VF020
-SST SST-49LF040B
-SST SST-49LF040
-SST SST-49LF020A
-SST SST-49LF080A
-SST SST-49LF160C
-SST SST-49LF002A/B
-SST SST-49LF003A/B
-SST SST-49LF004A/B
-SST SST-49LF008A
-SST SST-49LF004C
-SST SST-49LF008C
-SST SST-49LF016C
-ST ST-M50FLW040A
-ST ST-M50FLW040B
-ST ST-M50FLW080A
-ST ST-M50FLW080B
-ST ST-M50FW040
-ST ST-M50FW080
-ST ST-M50FW016
-ST ST-M50LPW116
-ST ST-M29F002B
-ST ST-M29F002T
-ST ST-M29F002NT
-ST ST-M29F400BT
-ST ST-M29F040B
-ST ST-M29W010B
-ST ST-M29W040B
-SyncMOS S29C51001T/B
-SyncMOS S29C51002T/B
-SyncMOS S29C51004T/B
-SyncMOS S29C31004T
-Winbond W29C011
-Winbond W29C020C
-Winbond W29C040P
-Winbond W29EE011
-Winbond W49F002U
-Winbond W49V002A
-Winbond W49V002FA
-Winbond W39V040FA
-Winbond W39V040A
-Winbond W39V040B
-Winbond W39V080A
+Please check the output of 'flashrom -L' for the list of supported
+flash chips, chipsets/southbridges, and mainboards.
 
+See also http://coreboot.org/Flashrom for more details.
 
-Supported Southbridges
-----------------------
-
-AMD CS5530/CS5530A
-AMD Geode SC1100
-AMD AMD-8111
-ATI SB400
-Broadcom HT-1000
-Intel ICH0-ICH8 (all variations)
-Intel PIIX4/PIIX4E/PIIX4M
-NVIDIA CK804
-NVIDIA MCP51
-NVIDIA MCP55
-SiS 630
-SiS 5595
-VIA CX700
-VIA VT8231
-VIA VT8235
-VIA VT8237
-VIA VT82C686
-

Modified: trunk/util/flashrom/flashrom.8
===================================================================
--- trunk/util/flashrom/flashrom.8	2008-06-22 17:54:03 UTC (rev 3384)
+++ trunk/util/flashrom/flashrom.8	2008-06-22 18:50:25 UTC (rev 3385)
@@ -1,4 +1,4 @@
-.TH FLASHROM 8 "January 18, 2008"
+.TH FLASHROM 8 "June 22, 2008"
 .SH NAME
 flashrom \- a universal BIOS/ROM/flash programming utility
 .SH SYNOPSIS
@@ -43,8 +43,8 @@
 .B "\-m, \-\-mainboard" <[vendor:]part>
 Override mainboard settings. This option is needed for some mainboards,
 see the
-.B flashrom
-README for a list. The vendor is not required when the board name is unique.
+.B "flashrom \-\-list\-supported"
+output for a list. The vendor is not required when the board name is unique.
 .TP
 .B "\-f, \-\-force"
 Force write without checking whether the ROM image file is really meant




From joe at settoplinux.org  Sun Jun 22 21:22:39 2008
From: joe at settoplinux.org (Joseph Smith)
Date: Sun, 22 Jun 2008 15:22:39 -0400
Subject: [coreboot] =?utf-8?q?Does_LegacyBIOS_support_USB=3F?=
Message-ID: <67d992061ec27d6ec5f5ac9dbb2e3aa7@imap.1and1.com>


Hello,
This may be a question for Kevin, but does LegacyBIOS support booting from
USB drives? And/or legacy keyboard functionality?

-- 
Thanks,
Joseph Smith
Set-Top-Linux
www.settoplinux.org




From joe at settoplinux.org  Sun Jun 22 21:27:03 2008
From: joe at settoplinux.org (Joseph Smith)
Date: Sun, 22 Jun 2008 15:27:03 -0400
Subject: [coreboot] #88: Add UHCI/OHCI/EHCI support to GRUB2
In-Reply-To: <13352155.129011208359327646.JavaMail.servlet@perfora>
References: <13352155.129011208359327646.JavaMail.servlet@perfora>
Message-ID: <597b21367c1ea31c1e46263f68ff12cd@imap.1and1.com>


> #88: Add UHCI/OHCI/EHCI support to GRUB2
>
----------------------------+-----------------------------------------------
>     Reporter:  uwe          |         Owner:  oxygene
>         Type:  enhancement  |        Status:  new
>     Priority:  critical     |     Milestone:  Port GRUB2 to coreboot
>    Component:  filo         |       Version:
>   Resolution:               |      Keywords:
> Dependencies:               |   Patchstatus:  there is no patch
>
----------------------------+-----------------------------------------------
> Changes (by stepan):
> 
>   * owner:  => oxygene
> 
> --
> Ticket URL:
> <http://tracker.coreboot.org/trac/coreboot/ticket/88#comment:2>
> coreboot <http://www.coreboot.org/>
> 
> 
How is it going with this Patrick? Do you have a status update? I am still
eagerly waiting :-|

-- 
Thanks,
Joseph Smith
Set-Top-Linux
www.settoplinux.org




From joe at settoplinux.org  Mon Jun 23 01:55:00 2008
From: joe at settoplinux.org (Joseph Smith)
Date: Sun, 22 Jun 2008 19:55:00 -0400
Subject: [coreboot] inteltool is sweet
Message-ID: <54cc9a7996443329d2d97d41e565204e@imap.1and1.com>

Hello,
I finally had a chance to try out inteltool, and it works great! Great job
Stefan! Attached is the output from the Thomson IP1000. Maybe if I get some
free time I will add i82830 northbridge support to it.
-- 
Thanks,
Joseph Smith
Set-Top-Linux
www.settoplinux.org
-------------- next part --------------
Intel Northbridge: 8086:3575 (unknown)
Intel Southbridge: 8086:24c0 (ICH4)

============= GPIOS =============

GPIOBASE = 0x0500 (IO)

gpiobase+0x0000: 0x1a003180 (GPIO_USE_SEL)
gpiobase+0x0004: 0x0200ffff (GP_IO_SEL)
gpiobase+0x0008: 0x00000000 (RESERVED)
gpiobase+0x000c: 0x1bbf0000 (GP_LVL)
gpiobase+0x0010: 0x00000000 (RESERVED)
gpiobase+0x0014: 0x00000000 (GPO_TTL)
gpiobase+0x0018: 0x00040000 (GPO_BLINK)
gpiobase+0x001c: 0x00000000 (RESERVED)
gpiobase+0x0020: 0x00000000 (RESERVED)
gpiobase+0x0024: 0x00000000 (RESERVED)
gpiobase+0x0028: 0x00000000 (RESERVED)
gpiobase+0x002c: 0x00000000 (GPI_INV)
gpiobase+0x0030: 0x00000fff (GPIO_USE_SEL2)
gpiobase+0x0034: 0x00000000 (GP_IO_SEL2)
gpiobase+0x0038: 0x00000fff (GP_LVL2)
gpiobase+0x003c: 0x00000000 (RESERVED)



============= RCBA ==============

This southbridge does not have RCBA.



============= PMBASE ============

Error: Dumping PMBASE on this southbridge is not (yet) supported.



============= MCHBAR ============

Error: Dumping MCHBAR on this northbridge is not (yet) supported.



============= EPBAR =============

Error: Dumping EPBAR on this northbridge is not (yet) supported.



============= DMIBAR ============

Error: Dumping DMIBAR on this northbridge is not (yet) supported.


========= PCIEXBAR ========

Error: Dumping PCIEXBAR on this northbridge is not (yet) supported.



===================== SHARED MSRs (All Cores) =====================
 MSR 0x00000017 = 0x94910000:0x00000000 (IA32_PLATFORM_ID)
 MSR 0x0000002A = 0x00000000:0xC6440000 (EBL_CR_POWERON)
 (*) MSR 0x000000CD = 0xFFFFFFFF:0xFFFFFFFF (FSB_CLOCK_STS)
 (*) MSR 0x000000CE = 0xFFFFFFFF:0xFFFFFFFF (FSB_CLOCK_VCC)
 (*) MSR 0x000000E2 = 0xFFFFFFFF:0xFFFFFFFF (CLOCK_CST_CONFIG_CONTROL)
 (*) MSR 0x000000E3 = 0xFFFFFFFF:0xFFFFFFFF (PMG_IO_BASE_ADDR)
 (*) MSR 0x000000E4 = 0xFFFFFFFF:0xFFFFFFFF (PMG_IO_CAPTURE_ADDR)
 (*) MSR 0x000000EE = 0xFFFFFFFF:0xFFFFFFFF (EXT_CONFIG)
 MSR 0x0000011E = 0x00000000:0x007447E1 (BBL_CR_CTL3)
 (*) MSR 0x00000194 = 0xFFFFFFFF:0xFFFFFFFF (CLOCK_FLEX_MAX)
 (*) MSR 0x00000198 = 0xFFFFFFFF:0xFFFFFFFF (IA32_PERF_STATUS)
 (*) MSR 0x000001A0 = 0xFFFFFFFF:0xFFFFFFFF (IA32_MISC_ENABLES)
 (*) MSR 0x000001AA = 0xFFFFFFFF:0xFFFFFFFF (PIC_SENS_CFG)
 MSR 0x00000400 = 0x00000000:0xC6440000 (IA32_MC0_CTL)
 MSR 0x00000401 = 0x10000000:0x00000000 (IA32_MC0_STATUS)
 MSR 0x00000402 = 0x00000000:0x00000000 (IA32_MC0_ADDR)
 MSR 0x0000040C = 0x00000000:0x00000001 (IA32_MC4_CTL)
 MSR 0x0000040D = 0x00000000:0x00000000 (IA32_MC4_STATUS)
 (*) MSR 0x0000040E = 0xFFFFFFFF:0xFFFFFFFF (IA32_MC4_ADDR)

====================== UNIQUE MSRs  (core 0) ======================
 MSR 0x00000010 = 0x00000293:0xADC16B0A (IA32_TIME_STAMP_COUNTER)
 MSR 0x0000001B = 0x00000000:0xFEE00100 (IA32_APIC_BASE)
 (*) MSR 0x0000003A = 0xFFFFFFFF:0xFFFFFFFF (IA32_FEATURE_CONTROL)
 (*) MSR 0x0000003F = 0xFFFFFFFF:0xFFFFFFFF (IA32_TEMPERATURE_OFFSET)
 MSR 0x0000008B = 0x00000001:0x00000000 (IA32_BIOS_SIGN_ID)
 (*) MSR 0x000000E7 = 0xFFFFFFFF:0xFFFFFFFF (IA32_MPERF)
 (*) MSR 0x000000E8 = 0xFFFFFFFF:0xFFFFFFFF (IA32_APERF)
 MSR 0x000000FE = 0x00000000:0x00000508 (IA32_MTRRCAP)
 MSR 0x0000015F = 0x00000000:0x002400E0 (DTS_CAL_CTRL)
 MSR 0x00000179 = 0x00000000:0x00000005 (IA32_MCG_CAP)
 MSR 0x0000017A = 0x00000000:0x00000000 (IA32_MCG_STATUS)
 (*) MSR 0x00000199 = 0xFFFFFFFF:0xFFFFFFFF (IA32_PERF_CONTROL)
 (*) MSR 0x0000019A = 0xFFFFFFFF:0xFFFFFFFF (IA32_CLOCK_MODULATION)
 (*) MSR 0x0000019B = 0xFFFFFFFF:0xFFFFFFFF (IA32_THERM_INTERRUPT)
 (*) MSR 0x0000019C = 0xFFFFFFFF:0xFFFFFFFF (IA32_THERM_STATUS)
 (*) MSR 0x0000019D = 0xFFFFFFFF:0xFFFFFFFF (GV_THERM)
 MSR 0x000001D9 = 0x00000000:0x00000001 (IA32_DEBUGCTL)
 MSR 0x00000200 = 0x00000000:0x00000006 (IA32_MTRR_PHYSBASE0)
 MSR 0x00000201 = 0x0000000F:0xE0000800 (IA32_MTRR_PHYSMASK0)
 MSR 0x00000202 = 0x00000000:0x20000006 (IA32_MTRR_PHYSBASE1)
 MSR 0x00000203 = 0x0000000F:0xFE000800 (IA32_MTRR_PHYSMASK1)
 MSR 0x00000204 = 0x00000000:0x22000006 (IA32_MTRR_PHYSBASE2)
 MSR 0x00000205 = 0x0000000F:0xFF000800 (IA32_MTRR_PHYSMASK2)
 MSR 0x00000206 = 0x00000000:0x23000006 (IA32_MTRR_PHYSBASE3)
 MSR 0x00000207 = 0x0000000F:0xFF800800 (IA32_MTRR_PHYSMASK3)
 MSR 0x00000208 = 0x00000000:0xF0000001 (IA32_MTRR_PHYSBASE4)
 MSR 0x00000209 = 0x0000000F:0xF8000800 (IA32_MTRR_PHYSMASK4)
 MSR 0x0000020A = 0x00000000:0x00000000 (IA32_MTRR_PHYSBASE5)
 MSR 0x0000020B = 0x00000000:0x00000000 (IA32_MTRR_PHYSMASK5)
 MSR 0x0000020C = 0x00000000:0x00000000 (IA32_MTRR_PHYSBASE6)
 MSR 0x0000020D = 0x00000000:0x00000000 (IA32_MTRR_PHYSMASK6)
 MSR 0x0000020E = 0x00000000:0x00000000 (IA32_MTRR_PHYSBASE7)
 MSR 0x0000020F = 0x00000000:0x00000000 (IA32_MTRR_PHYSMASK7)
 MSR 0x00000250 = 0x06060606:0x06060606 (IA32_MTRR_FIX64K_00000)
 MSR 0x00000258 = 0x06060606:0x06060606 (IA32_MTRR_FIX16K_80000)
 MSR 0x00000259 = 0x00000000:0x00000000 (IA32_MTRR_FIX16K_A0000)
 MSR 0x00000268 = 0x00000000:0x00000000 (IA32_MTRR_FIX4K_C0000)
 MSR 0x00000269 = 0x00000000:0x00000000 (IA32_MTRR_FIX4K_C8000)
 MSR 0x0000026A = 0x00000000:0x00000000 (IA32_MTRR_FIX4K_D0000)
 MSR 0x0000026B = 0x00000000:0x00000000 (IA32_MTRR_FIX4K_D8000)
 MSR 0x0000026C = 0x00000000:0x00000000 (IA32_MTRR_FIX4K_E0000)
 MSR 0x0000026D = 0x00000000:0x00000000 (IA32_MTRR_FIX4K_E8000)
 MSR 0x0000026E = 0x00000000:0x00000000 (IA32_MTRR_FIX4K_F0000)
 MSR 0x0000026F = 0x00000000:0x00000000 (IA32_MTRR_FIX4K_F8000)
 MSR 0x000002FF = 0x00000000:0x00000C00 (IA32_MTRR_DEF_TYPE)

(*) Some MSRs could not be read. The marked values are unreliable.



From kevin at koconnor.net  Mon Jun 23 04:05:53 2008
From: kevin at koconnor.net (Kevin O'Connor)
Date: Sun, 22 Jun 2008 22:05:53 -0400
Subject: [coreboot] Does LegacyBIOS support USB?
In-Reply-To: <67d992061ec27d6ec5f5ac9dbb2e3aa7@imap.1and1.com>
References: <67d992061ec27d6ec5f5ac9dbb2e3aa7@imap.1and1.com>
Message-ID: <20080623020553.GA13543@morn.localdomain>

Hi,

On Sun, Jun 22, 2008 at 03:22:39PM -0400, Joseph Smith wrote:
> This may be a question for Kevin, but does LegacyBIOS support booting from
> USB drives? And/or legacy keyboard functionality?

No, it does not currently support USB.  However, it is a long term
goal of mine to support it.

-Kevin



From joe at settoplinux.org  Mon Jun 23 04:22:50 2008
From: joe at settoplinux.org (Joseph Smith)
Date: Sun, 22 Jun 2008 22:22:50 -0400
Subject: [coreboot] =?utf-8?q?Does_LegacyBIOS_support_USB=3F?=
In-Reply-To: <20080623020553.GA13543@morn.localdomain>
References: <67d992061ec27d6ec5f5ac9dbb2e3aa7@imap.1and1.com>
	<20080623020553.GA13543@morn.localdomain>
Message-ID: <5e6195f93c46f102e48dacd5b8675479@imap.1and1.com>




On Sun, 22 Jun 2008 22:05:53 -0400, Kevin O'Connor <kevin at koconnor.net>
wrote:
> Hi,
> 
> On Sun, Jun 22, 2008 at 03:22:39PM -0400, Joseph Smith wrote:
>> This may be a question for Kevin, but does LegacyBIOS support booting
> from
>> USB drives? And/or legacy keyboard functionality?
> 
> No, it does not currently support USB.  However, it is a long term
> goal of mine to support it.
> 
Oh ok.

-- 
Thanks,
Joseph Smith
Set-Top-Linux
www.settoplinux.org




From rminnich at gmail.com  Mon Jun 23 08:04:21 2008
From: rminnich at gmail.com (ron minnich)
Date: Sun, 22 Jun 2008 23:04:21 -0700
Subject: [coreboot] coreboot and U-Boot: a comparison
In-Reply-To: <485D5310.8030802@georgi-clan.de>
References: <AA28F077645B324881335614E4F7C4284A4937@win-ex01.bench.com>
	<13426df10806201549r252d0fcfm15592a6152517c0b@mail.gmail.com>
	<485D5310.8030802@georgi-clan.de>
Message-ID: <13426df10806222304h7207ac3dla2c8719eb5569453@mail.gmail.com>

On Sat, Jun 21, 2008 at 12:14 PM, Patrick Georgi <patrick at georgi-clan.de> wrote:

> We already provide the cbv2 repo over https (as documented on
> http://www.coreboot.org/Download_coreboot ), and it should be easy to
> provide the other repos as well. It should be easy to map them into the http
> namespace on coreboot.org, if that's truly necessary.
>

yes you and Ken are right and we should set this up. I just don't know how :-)

thanks

ron



From rminnich at gmail.com  Mon Jun 23 08:07:30 2008
From: rminnich at gmail.com (ron minnich)
Date: Sun, 22 Jun 2008 23:07:30 -0700
Subject: [coreboot] Technologic TS-5300
In-Reply-To: <485E290F.4030708@coresystems.de>
References: <20080622031808.18419.qmail@stuge.se>
	<485E290F.4030708@coresystems.de>
Message-ID: <13426df10806222307l37c6c86i2b58ab202598db57@mail.gmail.com>

you can't put more than 64k flash up in high memory on the ts5300 --
it's an sc520 limitation -- they drop 64k of hardware registers right
in the middle of what is supposed to be (by standard) BIOS ROM address
space. If you want to delete this code, be aware that you may be
removing sc520 flashing support completely. Absent a test, I recommend
you NOT delete it.

I think that for this type of change, you must be very very careful to
ensure it works before a commit. sc520 has very strange limitations. A
neat chip but I don't ever want to work with it again ...

ron



From tiagomnm at gmail.com  Mon Jun 23 14:56:52 2008
From: tiagomnm at gmail.com (Tiago Marques)
Date: Mon, 23 Jun 2008 13:56:52 +0100
Subject: [coreboot] What are the best motherboards/systems out there
	foropen-source software?
In-Reply-To: <AA28F077645B324881335614E4F7C4284A4935@win-ex01.bench.com>
References: <BF50B61B20664C3496BE33D55D1C7002@a64x23800p>
	<AA28F077645B324881335614E4F7C4284A4935@win-ex01.bench.com>
Message-ID: <b1335fe90806230556t384eb592vc448ec6734fc872@mail.gmail.com>

I've seen my fair share of open-source adoption, or not. As such,
seeing the recent developments with open-source drivers in the Intel
camp, I can say they are pretty happy with the result, everyone is.

Has it already been attempted to contact chipset manufacturers to
release information without NDA, much like what AMD has already done
with graphics cards?
I say this because, if they realize that by allowing open-source
replacements for the BIOS would allow for new industry players to have
a lower cost of entry to the motherboard manufacturing. This, I see,
would drive chipset sales up, which is good for them IMHO. Emerging
markets like Chine, which will start doing it anyway, would benefit,
like the manufacturer would also.
This is something I think Coreboot should be attempting to "lobby", so
NDAs could become a thing of the past.

Anyone has any idea of how much are the costs for using Pheonix or AMI's BIOS?

Best regards,
                                Tiago Marques



On 6/20/08, Ken.Fuchs at bench.com <Ken.Fuchs at bench.com> wrote:
> David Christensen wrote:
>
>  > coreboot:
>  >
>  > I am researching parts to build a new open-source desktop
>  > system, and came across coreboot tonight.
>  >
>  > I have heard of open-source projects to implement x86 BIOS,
>  > but have always wondered how they fared given the fact
>  > that most motherboard vendors and chip vendors consider
>  > their products confidential intellectual property and won't
>  > provide technical documentation necessary for software
>  > development without an contract (NDA, etc.).
>
>
> Just to be clear, NDA is short for Non-Disclosure Agreement.
>  There is no standard NDA; even the same company will have
>  a different NDA for a different purpose.  An NDA will often
>  list exactly what will be shared and protected, but often
>  companies will want this list to be very general so that
>  almost anything shared that was not previously shared by
>  legal means will be protected by the terms of the NDA.
>
>  Some companies will provide enough information about their
>  boards, processors, chipsets, ancillary chips and embedded
>  controllers with or without an NDA.  With an NDA in place,
>  they will often want to review code based on an open source
>  project (i.e. coreboot), before allowing it to be publicly
>  released.  There may be a few companies that are resistant
>  to any open source BIOS and may not agree to an NDA for
>  that purpose, but I know of no such case yet.  Companies
>  will tend to do what is best for their bottom line; we just
>  need to convince them that an Open BIOS/firmware like
>  coreboot will help them improve their bottom line.
>
>  When a company is resistant to releasing technical information
>  even with an NDA or the prospect of getting approval to release
>  source created via NDA protected information is doubtful, there
>  is the option of reverse engineering the technical information
>  via JTAG debuggers, logical analyzers and similar tools.
>  Of course this is only an option for those that do not sign
>  any relevant NDA.  Also, care must be taken to ensure that the
>  reverse engineering activities do not violate any applicable
>  laws.
>
>
>  > Are there any modern x86 motherboards and/or systems
>  > currently available for which technical documents are
>  > available for the motherboard and everything on it?
>
>
> I'm not aware of any x86 main boards with complete technical
>  information that are available without signing an NDA.  Some
>  that may come close would be on the coreboot main board list,
>  but some of these may have been developed under NDA, which
>  means the only public technical information available may be
>  the approved & released chipset-specific, coreboot source code
>  itself:
>
>  http://www.coreboot?.org/Supported_Motherboards
>
>  Perh?aps, someone else is aware of such a board with complete
>  publicly available technical information, including full
>  schematics and BOM?
>
>
>  > Are matters better or worse for alternate architectures?
>
>
> The situation for non-x86 processors is much better.  U-Boot
>  seems to support almost any non-x86 based board that exists.
>  If a board is not supported, its architecture often is supported
>  and thus a port U-Boot to it is usually quite easy to do.
>
>  In my opinion, U-Boot's non-x86 firmware market share is so high
>  that embedded board designers ignore U-Boot at the own peril.
>  This is especially true of architectures that MS Windows CE does
>  _not_ support.  (CE supports only x86, MIPS, ARM and SuperH where
>  ARM is the only one that is really significant; CE's bootloader
>  Eboot is really a joke compared to the power of U-Boot in any
>  case.)
>
>  http://www.denx.de/wi?ki/UBoot
>
>  Sincerely,
>
>  Ken Fuchs
>
>
>  --
>  coreboot mailing list
>  coreboot at coreboot.org
>  http:?//www.coreboot.org/mailman/list?info/coreboot
>

From cristi.magherusan at net.utcluj.ro  Mon Jun 23 16:58:03 2008
From: cristi.magherusan at net.utcluj.ro (Cristi Magherusan)
Date: Mon, 23 Jun 2008 17:58:03 +0300
Subject: [coreboot] What are the best motherboards/systems out
	there	foropen-source software?
In-Reply-To: <b1335fe90806230556t384eb592vc448ec6734fc872@mail.gmail.com>
References: <BF50B61B20664C3496BE33D55D1C7002@a64x23800p>
	<AA28F077645B324881335614E4F7C4284A4935@win-ex01.bench.com>
	<b1335fe90806230556t384eb592vc448ec6734fc872@mail.gmail.com>
Message-ID: <1214233083.6688.20.camel@localhost>

On Mon, 2008-06-23 at 13:56 +0100, Tiago Marques wrote:
> I've seen my fair share of open-source adoption, or not. As such,
> seeing the recent developments with open-source drivers in the Intel
> camp, I can say they are pretty happy with the result, everyone is.

>From my experience, Intel only cares about the big OEM companies. 
When they do give something to the community they usually give 
poorly-written sourcecode that only they can further maintain instead 
of proper documentation. The best example are the the ipw3945/iwlwifi 
drivers for their wireless adapters.
http://kerneltrap.org/node/6650
?http://www.openbsd.org/papers/brhard2007

> Has it already been attempted to contact chipset manufacturers to
> release information without NDA, much like what AMD has already done
> with graphics cards?

Yes it was, and they always give evasive answers about Intelectual
Property and external regulations that they must follow in order to
assure the robustness or security of their products. Pure bull$%!#.

> I say this because, if they realize that by allowing open-source
> replacements for the BIOS would allow for new industry players to have
> a lower cost of entry to the motherboard manufacturing. This, I see,
> would drive chipset sales up, which is good for them IMHO. Emerging
> markets like Chine, which will start doing it anyway, would benefit,
> like the manufacturer would also.

AMD and VIA are doing this, among others to reduce costs. Intel is just
too big for this small starting players.

> This is something I think Coreboot should be attempting to "lobby", so
> NDAs could become a thing of the past.
> 
> Anyone has any idea of how much are the costs for using Pheonix or AMI's BIOS?

A few dollars per unit, i guess. I think their strong point is that they
offer support for them and make them work on new board models.

Cristi

-- 
Cristi Magherusan,
Universitatea Tehnica din Cluj - Napoca
Centrul de Comunicatii "Pusztai Kalman"
Tel. 0264/401247  http://cc.utcluj.ro




From jordan.crouse at amd.com  Mon Jun 23 17:16:00 2008
From: jordan.crouse at amd.com (Jordan Crouse)
Date: Mon, 23 Jun 2008 09:16:00 -0600
Subject: [coreboot] filo: Skip native ATA controllers
	in	find_ide_controller_compat()
In-Reply-To: <20080622015501.19071.qmail@stuge.se>
References: <20080621024522.23166.qmail@stuge.se>
	<485C89DA.1090303@onelabs.com>
	<20080621060650.11428.qmail@stuge.se>
	<20080622001710.GA4308@morn.localdomain>
	<20080621024128.19965.qmail@stuge.se>
	<20080621024522.23166.qmail@stuge.se>
	<485C89DA.1090303@onelabs.com>
	<20080621060650.11428.qmail@stuge.se> <485D5560.20802@onelabs.com>
	<20080622015501.19071.qmail@stuge.se>
Message-ID: <20080623151600.GA11345@cosmic.amd.com>

On 22/06/08 03:55 +0200, Peter Stuge wrote:
> On Sat, Jun 21, 2008 at 02:24:16PM -0500, bari wrote:
> > Seems to be fine on any combination with the vt8237r.
> > 
> > Post-acked or is it acked-again?
> > 
> > Acked: Bari Ari <bari at onelabs.com>
> 
> On Sat, Jun 21, 2008 at 08:17:10PM -0400, Kevin O'Connor wrote:
> > I can confirm that my epia-m continues to boot with a patched filo.
> > The epia-m has only PATA, and it is in compatibility mode.
> 
> Thanks for testing this! I confirmed correct functionality also on
> ALIX 3c3.
> 
> FILO r49

Is it still too early to bump buildrom to the new revision?

Jordan

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




From peter at stuge.se  Mon Jun 23 17:18:57 2008
From: peter at stuge.se (Peter Stuge)
Date: Mon, 23 Jun 2008 17:18:57 +0200
Subject: [coreboot] filo: Skip native ATA controllers
	in	find_ide_controller_compat()
In-Reply-To: <20080623151600.GA11345@cosmic.amd.com>
References: <485C89DA.1090303@onelabs.com>
	<20080621060650.11428.qmail@stuge.se>
	<20080622001710.GA4308@morn.localdomain>
	<20080621024128.19965.qmail@stuge.se>
	<20080621024522.23166.qmail@stuge.se>
	<485C89DA.1090303@onelabs.com>
	<20080621060650.11428.qmail@stuge.se> <485D5560.20802@onelabs.com>
	<20080622015501.19071.qmail@stuge.se>
	<20080623151600.GA11345@cosmic.amd.com>
Message-ID: <20080623151857.21410.qmail@stuge.se>

On Mon, Jun 23, 2008 at 09:16:00AM -0600, Jordan Crouse wrote:
> > Thanks for testing this! I confirmed correct functionality also on
> > ALIX 3c3.
> > 
> > FILO r49
> 
> Is it still too early to bump buildrom to the new revision?

Go ahead. If there's a problem we can fix it.

The patch is only relevant with SATA PCI devices before PATA PCI
devices when one wants to boot from PATA.


//Peter



From bari at onelabs.com  Mon Jun 23 17:21:16 2008
From: bari at onelabs.com (bari)
Date: Mon, 23 Jun 2008 10:21:16 -0500
Subject: [coreboot] filo: Skip native ATA
	controllers	in	find_ide_controller_compat()
In-Reply-To: <20080623151600.GA11345@cosmic.amd.com>
References: <20080621024522.23166.qmail@stuge.se>	<485C89DA.1090303@onelabs.com>	<20080621060650.11428.qmail@stuge.se>	<20080622001710.GA4308@morn.localdomain>	<20080621024128.19965.qmail@stuge.se>	<20080621024522.23166.qmail@stuge.se>	<485C89DA.1090303@onelabs.com>	<20080621060650.11428.qmail@stuge.se>
	<485D5560.20802@onelabs.com>	<20080622015501.19071.qmail@stuge.se>
	<20080623151600.GA11345@cosmic.amd.com>
Message-ID: <485FBF6C.6090401@onelabs.com>

Jordan Crouse wrote:
> On 22/06/08 03:55 +0200, Peter Stuge wrote:
>   
>> On Sat, Jun 21, 2008 at 02:24:16PM -0500, bari wrote:
>>     
>>> Seems to be fine on any combination with the vt8237r.
>>>
>>> Post-acked or is it acked-again?
>>>
>>> Acked: Bari Ari <bari at onelabs.com>
>>>       
>> On Sat, Jun 21, 2008 at 08:17:10PM -0400, Kevin O'Connor wrote:
>>     
>>> I can confirm that my epia-m continues to boot with a patched filo.
>>> The epia-m has only PATA, and it is in compatibility mode.
>>>       
>> Thanks for testing this! I confirmed correct functionality also on
>> ALIX 3c3.
>>
>> FILO r49
>>     
>
> Is it still too early to bump buildrom to the new revision?
>
> Jordan
>
>   
Fine by me, it hasn't given me any problems yet with any combination of 
drives and their boot orders. Buildrom needs some updating.

-Bari



From svn at coreboot.org  Mon Jun 23 17:28:22 2008
From: svn at coreboot.org (svn at coreboot.org)
Date: Mon, 23 Jun 2008 17:28:22 +0200
Subject: [coreboot] r207 - in buildrom-devel/packages/filo: . patches
Message-ID: <mailman.1653.1355071334.16123.coreboot@coreboot.org>

Author: jcrouse
Date: 2008-06-23 17:28:22 +0200 (Mon, 23 Jun 2008)
New Revision: 207

Modified:
   buildrom-devel/packages/filo/filo.mk
   buildrom-devel/packages/filo/patches/make.patch
Log:
buildrom:  move FILO to r49

New patch to filo does a better job of groking sata drivers, moving
to new revision (trivial).

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


Modified: buildrom-devel/packages/filo/filo.mk
===================================================================
--- buildrom-devel/packages/filo/filo.mk	2008-06-22 14:36:04 UTC (rev 206)
+++ buildrom-devel/packages/filo/filo.mk	2008-06-23 15:28:22 UTC (rev 207)
@@ -1,5 +1,5 @@
 FILO_URL=svn://coreboot.org/filo/trunk/filo-0.5
-FILO_TAG=44
+FILO_TAG=49
 
 FILO_DIR=$(BUILD_DIR)/filo
 FILO_SRC_DIR=$(FILO_DIR)/svn

Modified: buildrom-devel/packages/filo/patches/make.patch
===================================================================
--- buildrom-devel/packages/filo/patches/make.patch	2008-06-22 14:36:04 UTC (rev 206)
+++ buildrom-devel/packages/filo/patches/make.patch	2008-06-23 15:28:22 UTC (rev 207)
@@ -1,14 +1,14 @@
 Index: svn/makerules
 ===================================================================
---- svn.orig/makerules	2007-05-01 02:15:06.000000000 -0600
-+++ svn/makerules	2007-05-01 02:15:45.000000000 -0600
+--- svn.orig/makerules	2008-06-23 09:25:38.000000000 -0600
++++ svn/makerules	2008-06-23 09:26:54.000000000 -0600
 @@ -6,7 +6,7 @@
  GCCINCDIR = $(shell $(CC) -print-search-dirs | head -n 1 | cut -d' ' -f2)include
  CPPFLAGS = -nostdinc -imacros $(TOPDIR)/config.h -I$(TOPDIR)/include -I$(GCCINCDIR) -MD
  # grub part needs no-strict-aliasing!
 -CFLAGS = -Wall -Os -fomit-frame-pointer -fno-common -ffreestanding \
 +CFLAGS_extra = -Wall -Os -fomit-frame-pointer -fno-common -ffreestanding \
- 	 -fno-strict-aliasing -Wno-pointer-sign -Wno-unused 
+ 	 -fno-strict-aliasing -Wno-unused 
  
  ASFLAGS = -D__ASSEMBLY__
 @@ -30,10 +30,10 @@




From jordan.crouse at amd.com  Mon Jun 23 17:29:30 2008
From: jordan.crouse at amd.com (Jordan Crouse)
Date: Mon, 23 Jun 2008 09:29:30 -0600
Subject: [coreboot] filo: Skip native ATA controllers
	in	find_ide_controller_compat()
In-Reply-To: <20080623151857.21410.qmail@stuge.se>
References: <20080621060650.11428.qmail@stuge.se>
	<20080622001710.GA4308@morn.localdomain>
	<20080621024128.19965.qmail@stuge.se>
	<20080621024522.23166.qmail@stuge.se>
	<485C89DA.1090303@onelabs.com>
	<20080621060650.11428.qmail@stuge.se> <485D5560.20802@onelabs.com>
	<20080622015501.19071.qmail@stuge.se>
	<20080623151600.GA11345@cosmic.amd.com>
	<20080623151857.21410.qmail@stuge.se>
Message-ID: <20080623152930.GC11345@cosmic.amd.com>

On 23/06/08 17:18 +0200, Peter Stuge wrote:
> On Mon, Jun 23, 2008 at 09:16:00AM -0600, Jordan Crouse wrote:
> > > Thanks for testing this! I confirmed correct functionality also on
> > > ALIX 3c3.
> > > 
> > > FILO r49
> > 
> > Is it still too early to bump buildrom to the new revision?
> 
> Go ahead. If there's a problem we can fix it.
> 
> The patch is only relevant with SATA PCI devices before PATA PCI
> devices when one wants to boot from PATA.

Which is pretty much every motherboard made after 2006.. :)

r207 to buildrom.  Good luck.

Jordan

> 
> //Peter
> 
> -- 
> coreboot mailing list
> coreboot at coreboot.org
> http://www.coreboot.org/mailman/listinfo/coreboot
> 

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




From peter at stuge.se  Mon Jun 23 17:32:27 2008
From: peter at stuge.se (Peter Stuge)
Date: Mon, 23 Jun 2008 17:32:27 +0200
Subject: [coreboot] filo: Skip native ATA controllers
	in	find_ide_controller_compat()
In-Reply-To: <20080623152930.GC11345@cosmic.amd.com>
References: <20080622001710.GA4308@morn.localdomain>
	<20080621024128.19965.qmail@stuge.se>
	<20080621024522.23166.qmail@stuge.se>
	<485C89DA.1090303@onelabs.com>
	<20080621060650.11428.qmail@stuge.se> <485D5560.20802@onelabs.com>
	<20080622015501.19071.qmail@stuge.se>
	<20080623151600.GA11345@cosmic.amd.com>
	<20080623151857.21410.qmail@stuge.se>
	<20080623152930.GC11345@cosmic.amd.com>
Message-ID: <20080623153227.800.qmail@stuge.se>

On Mon, Jun 23, 2008 at 09:29:30AM -0600, Jordan Crouse wrote:
> > The patch is only relevant with SATA PCI devices before PATA PCI
> > devices when one wants to boot from PATA.
> 
> Which is pretty much every motherboard made after 2006.. :)

m57sli has PATA first, but anyway I guess not too many are booting
from PATA these days.


> r207 to buildrom.  Good luck.

\o/


//Peter



From mylesgw at gmail.com  Mon Jun 23 18:14:41 2008
From: mylesgw at gmail.com (Myles Watson)
Date: Mon, 23 Jun 2008 10:14:41 -0600
Subject: [coreboot] Black window when running qemu with
	coreboot+LegacyBIOS
In-Reply-To: <20080620231128.GA8661@cosmic.amd.com>
References: <92cbc4c70806181829x67547e58pf4df99b2a72d241b@mail.gmail.com>
	<20080619014748.GA1344@morn.localdomain>
	<92cbc4c70806190100u47e07626mf433ebcb54197b8@mail.gmail.com>
	<20080619123929.GA7437@morn.localdomain>
	<92cbc4c70806192001p1c4ccbfx5952683362efbd15@mail.gmail.com>
	<20080620125646.GA19607@morn.localdomain>
	<20080620231128.GA8661@cosmic.amd.com>
Message-ID: <006301c8d54c$3f307430$0023040a@chimp>

> > You have succesfully launched LegacyBIOS.  However, the vga rom was
> > not found.  Make sure you're running with the latest vgabios.  Also,
> > you probably haven't specified a floppy, hard drive, or cdrom to boot
> > from.
> 
> We should discuss what needs to be done to bring this goodness to
> buildrom.

I submitted a patch a while ago.  After Uwe's suggestions, the only response
I got was from Peter saying that Kevin should decide on the name before we
committed it.

Thanks,
Myles




From jordan.crouse at amd.com  Mon Jun 23 18:19:53 2008
From: jordan.crouse at amd.com (Jordan Crouse)
Date: Mon, 23 Jun 2008 10:19:53 -0600
Subject: [coreboot] Black window when running qemu with
	coreboot+LegacyBIOS
In-Reply-To: <006301c8d54c$3f307430$0023040a@chimp>
References: <92cbc4c70806181829x67547e58pf4df99b2a72d241b@mail.gmail.com>
	<20080619014748.GA1344@morn.localdomain>
	<92cbc4c70806190100u47e07626mf433ebcb54197b8@mail.gmail.com>
	<20080619123929.GA7437@morn.localdomain>
	<92cbc4c70806192001p1c4ccbfx5952683362efbd15@mail.gmail.com>
	<20080620125646.GA19607@morn.localdomain>
	<20080620231128.GA8661@cosmic.amd.com>
	<006301c8d54c$3f307430$0023040a@chimp>
Message-ID: <20080623161953.GE11345@cosmic.amd.com>

On 23/06/08 10:14 -0600, Myles Watson wrote:
> > > You have succesfully launched LegacyBIOS.  However, the vga rom was
> > > not found.  Make sure you're running with the latest vgabios.  Also,
> > > you probably haven't specified a floppy, hard drive, or cdrom to boot
> > > from.
> > 
> > We should discuss what needs to be done to bring this goodness to
> > buildrom.
> 
> I submitted a patch a while ago.  After Uwe's suggestions, the only response
> I got was from Peter saying that Kevin should decide on the name before we
> committed it.

Ugh - where was I?  Please send it again - We can fight the name battle
later.

Jordan

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




From stepan at coresystems.de  Mon Jun 23 18:26:45 2008
From: stepan at coresystems.de (Stefan Reinauer)
Date: Mon, 23 Jun 2008 18:26:45 +0200
Subject: [coreboot] Black window when running qemu with
	coreboot+LegacyBIOS
In-Reply-To: <20080623161953.GE11345@cosmic.amd.com>
References: <92cbc4c70806181829x67547e58pf4df99b2a72d241b@mail.gmail.com>
	<20080619014748.GA1344@morn.localdomain>
	<92cbc4c70806190100u47e07626mf433ebcb54197b8@mail.gmail.com>
	<20080619123929.GA7437@morn.localdomain>
	<92cbc4c70806192001p1c4ccbfx5952683362efbd15@mail.gmail.com>
	<20080620125646.GA19607@morn.localdomain>
	<20080620231128.GA8661@cosmic.amd.com>
	<006301c8d54c$3f307430$0023040a@chimp>
	<20080623161953.GE11345@cosmic.amd.com>
Message-ID: <485FCEC5.6020202@coresystems.de>

Jordan Crouse wrote:
> On 23/06/08 10:14 -0600, Myles Watson wrote:
>   
>>>> You have succesfully launched LegacyBIOS.  However, the vga rom was
>>>> not found.  Make sure you're running with the latest vgabios.  Also,
>>>> you probably haven't specified a floppy, hard drive, or cdrom to boot
>>>> from.
>>>>         
>>> We should discuss what needs to be done to bring this goodness to
>>> buildrom.
>>>       
>> I submitted a patch a while ago.  After Uwe's suggestions, the only response
>> I got was from Peter saying that Kevin should decide on the name before we
>> committed it.
>>     
>
> Ugh - where was I?  Please send it again - We can fight the name battle
> later.
>   
Please, before we get this into buildrom, let's get it straight first. 
Zhang Rui is working on integration of LegacyBIOS for all purposes, not 
just int19 booting. It will replace a lot of code in current coreboot. 
We should consider keeping it in util/ in the v3 tree.

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: signature.asc
Type: application/pgp-signature
Size: 249 bytes
Desc: OpenPGP digital signature
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20080623/caf4ca2f/attachment.sig>

From jordan.crouse at amd.com  Mon Jun 23 18:32:30 2008
From: jordan.crouse at amd.com (Jordan Crouse)
Date: Mon, 23 Jun 2008 10:32:30 -0600
Subject: [coreboot] Black window when running qemu with
	coreboot+LegacyBIOS
In-Reply-To: <485FCEC5.6020202@coresystems.de>
References: <92cbc4c70806181829x67547e58pf4df99b2a72d241b@mail.gmail.com>
	<20080619014748.GA1344@morn.localdomain>
	<92cbc4c70806190100u47e07626mf433ebcb54197b8@mail.gmail.com>
	<20080619123929.GA7437@morn.localdomain>
	<92cbc4c70806192001p1c4ccbfx5952683362efbd15@mail.gmail.com>
	<20080620125646.GA19607@morn.localdomain>
	<20080620231128.GA8661@cosmic.amd.com>
	<006301c8d54c$3f307430$0023040a@chimp>
	<20080623161953.GE11345@cosmic.amd.com>
	<485FCEC5.6020202@coresystems.de>
Message-ID: <20080623163230.GF11345@cosmic.amd.com>

On 23/06/08 18:26 +0200, Stefan Reinauer wrote:
> Jordan Crouse wrote:
> > On 23/06/08 10:14 -0600, Myles Watson wrote:
> >   
> >>>> You have succesfully launched LegacyBIOS.  However, the vga rom was
> >>>> not found.  Make sure you're running with the latest vgabios.  Also,
> >>>> you probably haven't specified a floppy, hard drive, or cdrom to boot
> >>>> from.
> >>>>         
> >>> We should discuss what needs to be done to bring this goodness to
> >>> buildrom.
> >>>       
> >> I submitted a patch a while ago.  After Uwe's suggestions, the only response
> >> I got was from Peter saying that Kevin should decide on the name before we
> >> committed it.
> >>     
> >
> > Ugh - where was I?  Please send it again - We can fight the name battle
> > later.
> >   
> Please, before we get this into buildrom, let's get it straight first. 
> Zhang Rui is working on integration of LegacyBIOS for all purposes, not 
> just int19 booting. It will replace a lot of code in current coreboot. 
> We should consider keeping it in util/ in the v3 tree.

I'm not sure what that has to do with the price of tea in China.  Does
it build seperately from coreboot or not?  If it does, then it belongs in
buildrom.  We can always change what it is named or where it lives later.

Jordan

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




From Ken.Fuchs at bench.com  Mon Jun 23 18:36:34 2008
From: Ken.Fuchs at bench.com (Ken.Fuchs at bench.com)
Date: Mon, 23 Jun 2008 11:36:34 -0500
Subject: [coreboot] [RFC] coreboot Live CD
In-Reply-To: <13426df10806201550r49073f37x2c70d6157db17d56@mail.gmail.com>
Message-ID: <AA28F077645B324881335614E4F7C4284A493C@win-ex01.bench.com>

> On Fri, Jun 20, 2008 at 4:30 PM,  <Ken.Fuchs at bench.com> wrote:
> >
> > Another problem with LinuxBIOS and now with coreboot
> > is all the mainboards I tried to build or the even
> > the payloads would never compile without some serious
> > errors.  Hopefully, a validated coreboot Live CD
> > would solve this problem and increase exposure of
> > coreboot at the same time.
> 
> Ken, no offense intended, but this is a vacuous comment absent logs of
> failed builds. But we'd love to see them.

I sent a log of filo-0.5 compilation issues nearly two weeks
ago as detailed in the following three URIs:

http://www.coreboot.org/pipermail/coreboot/2008-June/035647.html
http://www.coreboot.org/pipermail/coreboot/2008-June/035674.html
http://www.coreboot.org/pipermail/coreboot/2008-June/035718.html

Thanks for responding to my filo-0.5 compilation issues as detailed
in the first URI above, but no one responded to my log in the final
URI above.

------

I haven't previously reported my latest coreboot build issue.
Here it is:

$ cd ./targets
$ ./buildtarget tyan/s2885
build_dir=tyan/s2885/s2885
No coreboot config script found. Rebuilding it..
  File "/mnt/s2u1/atom/cb/coreboot-v2-3360/util/newconfig/yapps2.py",
line 418
    gen.write(indent, "elsf update(self, gen):
                                             ^
SyntaxError: EOL while scanning single-quoted string
python: can't open file 'tyan/s2885/s2885/config.py': [Errno 2] No such
file or directory
./buildtarget: line 78: tyan/s2885/s2885/*/Makefile.settings: No such
file or directory
./buildtarget: line 79: tyan/s2885/s2885/*/Makefile.settings: No such
file or directory
$ 

I'm using snapshot coreboot-v2-3360.

Sincerely,

Ken Fuchs



From stepan at coresystems.de  Mon Jun 23 18:41:29 2008
From: stepan at coresystems.de (Stefan Reinauer)
Date: Mon, 23 Jun 2008 18:41:29 +0200
Subject: [coreboot] Black window when running qemu with
	coreboot+LegacyBIOS
In-Reply-To: <20080623163230.GF11345@cosmic.amd.com>
References: <92cbc4c70806181829x67547e58pf4df99b2a72d241b@mail.gmail.com>
	<20080619014748.GA1344@morn.localdomain>
	<92cbc4c70806190100u47e07626mf433ebcb54197b8@mail.gmail.com>
	<20080619123929.GA7437@morn.localdomain>
	<92cbc4c70806192001p1c4ccbfx5952683362efbd15@mail.gmail.com>
	<20080620125646.GA19607@morn.localdomain>
	<20080620231128.GA8661@cosmic.amd.com>
	<006301c8d54c$3f307430$0023040a@chimp>
	<20080623161953.GE11345@cosmic.amd.com>
	<485FCEC5.6020202@coresystems.de>
	<20080623163230.GF11345@cosmic.amd.com>
Message-ID: <485FD239.6030500@coresystems.de>

Jordan Crouse wrote:
>
> I'm not sure what that has to do with the price of tea in China.  Does
> it build seperately from coreboot or not?  
Not anymore after GSoC is done.

Thanks,

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: signature.asc
Type: application/pgp-signature
Size: 249 bytes
Desc: OpenPGP digital signature
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20080623/1ef886d3/attachment.sig>

From stepan at coresystems.de  Mon Jun 23 18:47:46 2008
From: stepan at coresystems.de (Stefan Reinauer)
Date: Mon, 23 Jun 2008 18:47:46 +0200
Subject: [coreboot] [RFC] coreboot Live CD
In-Reply-To: <AA28F077645B324881335614E4F7C4284A493C@win-ex01.bench.com>
References: <AA28F077645B324881335614E4F7C4284A493C@win-ex01.bench.com>
Message-ID: <485FD3B2.30407@coresystems.de>

Ken.Fuchs at bench.com wrote:
>> On Fri, Jun 20, 2008 at 4:30 PM,  <Ken.Fuchs at bench.com> wrote:
>>     
>>> Another problem with LinuxBIOS and now with coreboot
>>> is all the mainboards I tried to build or the even
>>> the payloads would never compile without some serious
>>> errors.  Hopefully, a validated coreboot Live CD
>>> would solve this problem and increase exposure of
>>> coreboot at the same time.
>>>       
>> Ken, no offense intended, but this is a vacuous comment absent logs of
>> failed builds. But we'd love to see them.
>>     
>
> I sent a log of filo-0.5 compilation issues nearly two weeks
> ago as detailed in the following three URIs:
>
> http://www.coreboot.org/pipermail/coreboot/2008-June/035647.html
> http://www.coreboot.org/pipermail/coreboot/2008-June/035674.html
> http://www.coreboot.org/pipermail/coreboot/2008-June/035718.html
>
> Thanks for responding to my filo-0.5 compilation issues as detailed
> in the first URI above, but no one responded to my log in the final
> URI above.
>   

Can you post line 197 of printf.c ? It seems your source code is corrupt 
or something.

> ------
>
> I haven't previously reported my latest coreboot build issue.
> Here it is:
>
> $ cd ./targets
> $ ./buildtarget tyan/s2885
> build_dir=tyan/s2885/s2885
> No coreboot config script found. Rebuilding it..
>   File "/mnt/s2u1/atom/cb/coreboot-v2-3360/util/newconfig/yapps2.py",
> line 418
>     gen.write(indent, "elsf update(self, gen):
>                                              ^
>   
Same issue here:

The line in my source code is:
        gen.write(indent, "else: ")

Your source code is seriously corrupted. How did you download it?


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: signature.asc
Type: application/pgp-signature
Size: 249 bytes
Desc: OpenPGP digital signature
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20080623/40f50780/attachment.sig>

From jordan.crouse at amd.com  Mon Jun 23 18:46:58 2008
From: jordan.crouse at amd.com (Jordan Crouse)
Date: Mon, 23 Jun 2008 10:46:58 -0600
Subject: [coreboot] Black window when running qemu with
	coreboot+LegacyBIOS
In-Reply-To: <485FD239.6030500@coresystems.de>
References: <92cbc4c70806190100u47e07626mf433ebcb54197b8@mail.gmail.com>
	<20080619123929.GA7437@morn.localdomain>
	<92cbc4c70806192001p1c4ccbfx5952683362efbd15@mail.gmail.com>
	<20080620125646.GA19607@morn.localdomain>
	<20080620231128.GA8661@cosmic.amd.com>
	<006301c8d54c$3f307430$0023040a@chimp>
	<20080623161953.GE11345@cosmic.amd.com>
	<485FCEC5.6020202@coresystems.de>
	<20080623163230.GF11345@cosmic.amd.com>
	<485FD239.6030500@coresystems.de>
Message-ID: <20080623164658.GG11345@cosmic.amd.com>

On 23/06/08 18:41 +0200, Stefan Reinauer wrote:
> Jordan Crouse wrote:
> >
> > I'm not sure what that has to do with the price of tea in China.  Does
> > it build seperately from coreboot or not?  
> Not anymore after GSoC is done.

I'm just trying to get as many people exposed to it as possible.  But if 
there is an advantage to waiting a few weeks, then I'm fine with that.

Jordan

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




From rminnich at gmail.com  Mon Jun 23 18:49:24 2008
From: rminnich at gmail.com (ron minnich)
Date: Mon, 23 Jun 2008 09:49:24 -0700
Subject: [coreboot] [RFC] coreboot Live CD
In-Reply-To: <AA28F077645B324881335614E4F7C4284A493C@win-ex01.bench.com>
References: <13426df10806201550r49073f37x2c70d6157db17d56@mail.gmail.com>
	<AA28F077645B324881335614E4F7C4284A493C@win-ex01.bench.com>
Message-ID: <13426df10806230949l22bbcf8br7872ba79711d7e1c@mail.gmail.com>

On Mon, Jun 23, 2008 at 9:36 AM,  <Ken.Fuchs at bench.com> wrote:
>
> I sent a log of filo-0.5 compilation issues nearly two weeks
> ago as detailed in the following three URIs:
>
> http://www.coreboot.org/pipermail/coreboot/2008-June/035647.html
> http://www.coreboot.org/pipermail/coreboot/2008-June/035674.html
> http://www.coreboot.org/pipermail/coreboot/2008-June/035718.html
>
> Thanks for responding to my filo-0.5 compilation issues as detailed
> in the first URI above, but no one responded to my log in the final
> URI above.

you can't avoid the need to do a little sleuthing of your own. Let's
look at the file:

int vtxprintf(int (*tx_byte)(int byte), const char *fmt, va_list args)
{
 int len;
 unsigned long long num;
 int i, base;
 const char *s;

 int flags;

 int field_width;
 int precision;

 int qualifier; se + value;
  cp++;
 }

What's happened here? the original is this:
int vtxprintf(int (*tx_byte)(int byte), const char *fmt, va_list args)
{
        int len;
        unsigned long long num;
        int i, base;
        const char *s;

        int flags;              /* flags to number() */

        int field_width;        /* width of output field */
        int precision;          /* min. # of digits for integers; max
                                   number of chars for from string */
        int qualifier;
(starts at line 185)

What's th 'se + value' stuff?

That's this:
se + value;
                cp++;
        }
        if (endp)
                *endp = (char *)cp;
        return result;
}

starts at line 55.

Then:


> $ cd ./targets
> $ ./buildtarget tyan/s2885
> build_dir=tyan/s2885/s2885
> No coreboot config script found. Rebuilding it..
>  File "/mnt/s2u1/atom/cb/coreboot-v2-3360/util/newconfig/yapps2.py",
> line 418
>    gen.write(indent, "elsf update(self, gen):

This part: gen.write(indent, "els
is line 418.

This part: update(self, gen):

is line 448.

You've got some serious file system or disk corruption.

ron



From mylesgw at gmail.com  Mon Jun 23 18:50:21 2008
From: mylesgw at gmail.com (Myles Watson)
Date: Mon, 23 Jun 2008 10:50:21 -0600
Subject: [coreboot] Black window when running qemu with
	coreboot+LegacyBIOS
In-Reply-To: <485FD239.6030500@coresystems.de>
References: <92cbc4c70806181829x67547e58pf4df99b2a72d241b@mail.gmail.com>
	<20080619014748.GA1344@morn.localdomain>
	<92cbc4c70806190100u47e07626mf433ebcb54197b8@mail.gmail.com>
	<20080619123929.GA7437@morn.localdomain>
	<92cbc4c70806192001p1c4ccbfx5952683362efbd15@mail.gmail.com>
	<20080620125646.GA19607@morn.localdomain>
	<20080620231128.GA8661@cosmic.amd.com>
	<006301c8d54c$3f307430$0023040a@chimp>
	<20080623161953.GE11345@cosmic.amd.com>
	<485FCEC5.6020202@coresystems.de>
	<20080623163230.GF11345@cosmic.amd.com>
	<485FD239.6030500@coresystems.de>
Message-ID: <007c01c8d551$3a139bd0$0023040a@chimp>

> From: Stefan Reinauer [mailto:stepan at coresystems.de]
> Jordan Crouse wrote:
> >
> > I'm not sure what that has to do with the price of tea in China.  Does
> > it build seperately from coreboot or not?
> Not anymore after GSoC is done.

I'm interested in more than one line here.  Why would LegacyBIOS be more
tightly integrated than any other payload?  What parts will be tightly
integrated?

Thanks,
Myles





From bari at onelabs.com  Mon Jun 23 18:50:34 2008
From: bari at onelabs.com (bari)
Date: Mon, 23 Jun 2008 11:50:34 -0500
Subject: [coreboot] [RFC] Coreboot Ports in Progress
Message-ID: <485FD45A.3090701@onelabs.com>

Is there anyway we can try keep track of what everyone may be doing as 
far as ports of coreboot to new boards or chipsets as well as utils?

I understand that sometimes projects are under contract and need to be 
kept quiet until after it's completed and released. But for others, it 
is not a problem to at least announce on the mail list what they may be 
up to, or if the project has stalled.

Case in point, the C7 + CN700 (epia-cn) port had several efforts going 
on in parallel with everyone going through the shared pain and 
duplicated issues.

My hope is to further the spirit of cooperation we already have and 
expedite the development of coreboot ports and utils in the future.

-Bari



From rminnich at gmail.com  Mon Jun 23 19:02:59 2008
From: rminnich at gmail.com (ron minnich)
Date: Mon, 23 Jun 2008 11:02:59 -0600
Subject: [coreboot] [RFC] Coreboot Ports in Progress
In-Reply-To: <485FD45A.3090701@onelabs.com>
References: <485FD45A.3090701@onelabs.com>
Message-ID: <13426df10806231002r759f5e53y421f91cdbe55906@mail.gmail.com>

On Mon, Jun 23, 2008 at 10:50 AM, bari <bari at onelabs.com> wrote:
> Is there anyway we can try keep track of what everyone may be doing as
> far as ports of coreboot to new boards or chipsets as well as utils?
>
> I understand that sometimes projects are under contract and need to be
> kept quiet until after it's completed and released. But for others, it
> is not a problem to at least announce on the mail list what they may be
> up to, or if the project has stalled.
>
> Case in point, the C7 + CN700 (epia-cn) port had several efforts going
> on in parallel with everyone going through the shared pain and
> duplicated issues.


great idea. sounds like another web page to me?

ron



From r.marek at assembler.cz  Mon Jun 23 19:16:00 2008
From: r.marek at assembler.cz (Rudolf Marek)
Date: Mon, 23 Jun 2008 19:16:00 +0200
Subject: [coreboot] [RFC] Coreboot Ports in Progress
In-Reply-To: <13426df10806231002r759f5e53y421f91cdbe55906@mail.gmail.com>
References: <485FD45A.3090701@onelabs.com>
	<13426df10806231002r759f5e53y421f91cdbe55906@mail.gmail.com>
Message-ID: <485FDA50.6050104@assembler.cz>

I'm doing:

K8M890/VT8237S

I have following datasheets under NDA:

VT8237R NDA
VT8237S NDA
VT8237A NDA
K8T890CE NDA
K8T890CF NDA
K8M890 NDA

Rudolf



From tiagomnm at gmail.com  Mon Jun 23 19:30:53 2008
From: tiagomnm at gmail.com (Tiago Marques)
Date: Mon, 23 Jun 2008 18:30:53 +0100
Subject: [coreboot] What are the best motherboards/systems out there
	foropen-source software?
In-Reply-To: <b1335fe90806231030w51e0a734oa5c380df6ad671dc@mail.gmail.com>
References: <BF50B61B20664C3496BE33D55D1C7002@a64x23800p>
	<AA28F077645B324881335614E4F7C4284A4935@win-ex01.bench.com>
	<b1335fe90806230556t384eb592vc448ec6734fc872@mail.gmail.com>
	<1214233083.6688.20.camel@localhost>
	<b1335fe90806231030w51e0a734oa5c380df6ad671dc@mail.gmail.com>
Message-ID: <b1335fe90806231030l2f062026r26e12a5923faf143@mail.gmail.com>

Ok, I get your point, but the Iwlwifi is quite open IMHO. I don't
really trust Intel, as they may pull the documentation for future
products but take a look at this:

http://www.phoronix.com/scan.php?page=article&item=984&num=1
http://www.phoronix.com/scan.php?page=article&item=850&num=1

They seem quite happy, well, at least the graphics division.

I think it would be profitable to talk to companies like
http://www.jwele.com/ which are emerging players in the market, to
whom coreboot might interest. I can try to do this, but it isn't
usually easy to get the right contacts.

Best regards,
                              Tiago Marques



On Mon, Jun 23, 2008 at 3:58 PM, Cristi Magherusan
<cristi.magherusan at net.utcluj.ro> wrote:
> On Mon, 2008-06-23 at 13:56 +0100, Tiago Marques wrote:
>> I've seen my fair share of open-source adoption, or not. As such,
>> seeing the recent developments with open-source drivers in the Intel
>> camp, I can say they are pretty happy with the result, everyone is.
>
> >From my experience, Intel only cares about the big OEM companies.
> When they do give something to the community they usually give
> poorly-written sourcecode that only they can further maintain instead
> of proper documentation. The best example are the the ipw3945/iwlwifi
> drivers for their wireless adapters.
> http://kerneltrap.org/node/6650
> ?http://www.openbsd.org/papers/brhard2007
>
>> Has it already been attempted to contact chipset manufacturers to
>> release information without NDA, much like what AMD has already done
>> with graphics cards?
>
> Yes it was, and they always give evasive answers about Intelectual
> Property and external regulations that they must follow in order to
> assure the robustness or security of their products. Pure bull$%!#.
>
>> I say this because, if they realize that by allowing open-source
>> replacements for the BIOS would allow for new industry players to have
>> a lower cost of entry to the motherboard manufacturing. This, I see,
>> would drive chipset sales up, which is good for them IMHO. Emerging
>> markets like Chine, which will start doing it anyway, would benefit,
>> like the manufacturer would also.
>
> AMD and VIA are doing this, among others to reduce costs. Intel is just
> too big for this small starting players.
>
>> This is something I think Coreboot should be attempting to "lobby", so
>> NDAs could become a thing of the past.
>>
>> Anyone has any idea of how much are the costs for using Pheonix or AMI's BIOS?
>
> A few dollars per unit, i guess. I think their strong point is that they
> offer support for them and make them work on new board models.
>
> Cristi
>
> --
> Cristi Magherusan,
> Universitatea Tehnica din Cluj - Napoca
> Centrul de Comunicatii "Pusztai Kalman"
> Tel. 0264/401247  http://cc.utcluj.ro
>
>

From Ken.Fuchs at bench.com  Mon Jun 23 20:19:06 2008
From: Ken.Fuchs at bench.com (Ken.Fuchs at bench.com)
Date: Mon, 23 Jun 2008 13:19:06 -0500
Subject: [coreboot] [Comm. BIOS costs] What are the best
	motherboards/systems out there for open-source software?
In-Reply-To: <1214233083.6688.20.camel@localhost>
Message-ID: <AA28F077645B324881335614E4F7C4284A493F@win-ex01.bench.com>

> On Mon, 2008-06-23 at 13:56 +0100, Tiago Marques wrote:

> > Anyone has any idea of how much are the costs for using 
> > Pheonix or AMI's BIOS?

Cristi Magherusan wrote:

> A few dollars per unit, i guess. I think their strong point 
> is that they
> offer support for them and make them work on new board models.

The royalty per unit varies widely based on unit volume.
For lower volumes, the royalty per unit can be about $10
or even more per unit.

However, the biggest external cost is the source code
licensing fee.  A full UEFI based source code license
will cost up to $50,000 via a IBV (according to public
UEFI documents as I recall).  An IBV in this context
would include AMI, Phoenix, Insyde and General Software.
(A legacy BIOS is comparable in price and usually faster
as well, a sad comment on UEFI.)  If your board contains
an embedded controller that laptops/mobile devices often
require, the $50,000 figure may not cover the embedded
controller's source code, so you can expect to pay a
significant percentage more to include the embedded
controller source code.  There may even be an additional
per unit royalty for the embedded controller source code.

So now you have a rough idea of the external costs that
can be saved on mainboards that are already supported by
coreboot and associated payloads.  BTW, OpenEC is the
only open source embedded controller I'm aware of and it
partially supports a least a particular version of the
OLPC as of the end of 2007 when development on it ceased.
So, if you need embedded controller code, your lowest cost
alternative will probably still be closed source as
provided by an IBV or other third party that specializes
in embedded controller code.

Sincerely,

Ken Fuchs



From c-d.hailfinger.devel.2006 at gmx.net  Mon Jun 23 20:29:03 2008
From: c-d.hailfinger.devel.2006 at gmx.net (Carl-Daniel Hailfinger)
Date: Mon, 23 Jun 2008 20:29:03 +0200
Subject: [coreboot] filo: Skip native ATA
	controllers	in	find_ide_controller_compat()
In-Reply-To: <20080622015501.19071.qmail@stuge.se>
References: <20080621024128.19965.qmail@stuge.se>	<20080621024522.23166.qmail@stuge.se>	<485C89DA.1090303@onelabs.com>	<20080621060650.11428.qmail@stuge.se>	<20080622001710.GA4308@morn.localdomain>	<20080621024128.19965.qmail@stuge.se>	<20080621024522.23166.qmail@stuge.se>	<485C89DA.1090303@onelabs.com>	<20080621060650.11428.qmail@stuge.se>
	<485D5560.20802@onelabs.com> <20080622015501.19071.qmail@stuge.se>
Message-ID: <485FEB6F.6080407@gmx.net>

On 22.06.2008 03:55, Peter Stuge wrote:
> Thanks for testing this! I confirmed correct functionality also on
> ALIX 3c3.
>   

2c3 or 3c3?

Regards,
Carl-Daniel

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




From peter at stuge.se  Mon Jun 23 22:42:29 2008
From: peter at stuge.se (Peter Stuge)
Date: Mon, 23 Jun 2008 22:42:29 +0200
Subject: [coreboot] filo: Skip native ATA
	controllers	in	find_ide_controller_compat()
In-Reply-To: <485FEB6F.6080407@gmx.net>
References: <485C89DA.1090303@onelabs.com>
	<20080621060650.11428.qmail@stuge.se>
	<20080622001710.GA4308@morn.localdomain>
	<20080621024128.19965.qmail@stuge.se>
	<20080621024522.23166.qmail@stuge.se>
	<485C89DA.1090303@onelabs.com>
	<20080621060650.11428.qmail@stuge.se> <485D5560.20802@onelabs.com>
	<20080622015501.19071.qmail@stuge.se> <485FEB6F.6080407@gmx.net>
Message-ID: <20080623204229.3337.qmail@stuge.se>

On Mon, Jun 23, 2008 at 08:29:03PM +0200, Carl-Daniel Hailfinger wrote:
> On 22.06.2008 03:55, Peter Stuge wrote:
> > Thanks for testing this! I confirmed correct functionality also on
> > ALIX 3c3.
> 
> 2c3 or 3c3?

3c3, I don't have a 2c3. I think that's Ward's board.


//Peter



From c-d.hailfinger.devel.2006 at gmx.net  Mon Jun 23 23:54:22 2008
From: c-d.hailfinger.devel.2006 at gmx.net (Carl-Daniel Hailfinger)
Date: Mon, 23 Jun 2008 23:54:22 +0200
Subject: [coreboot] filo: Skip native
	ATA	controllers	in	find_ide_controller_compat()
In-Reply-To: <20080623204229.3337.qmail@stuge.se>
References: <485C89DA.1090303@onelabs.com>	<20080621060650.11428.qmail@stuge.se>	<20080622001710.GA4308@morn.localdomain>	<20080621024128.19965.qmail@stuge.se>	<20080621024522.23166.qmail@stuge.se>	<485C89DA.1090303@onelabs.com>	<20080621060650.11428.qmail@stuge.se>
	<485D5560.20802@onelabs.com>	<20080622015501.19071.qmail@stuge.se>
	<485FEB6F.6080407@gmx.net> <20080623204229.3337.qmail@stuge.se>
Message-ID: <48601B8E.1080802@gmx.net>

On 23.06.2008 22:42, Peter Stuge wrote:
> On Mon, Jun 23, 2008 at 08:29:03PM +0200, Carl-Daniel Hailfinger wrote:
>   
>> On 22.06.2008 03:55, Peter Stuge wrote:
>>     
>>> Thanks for testing this! I confirmed correct functionality also on
>>> ALIX 3c3.
>>>       
>> 2c3 or 3c3?
>>     
>
> 3c3, I don't have a 2c3. I think that's Ward's board.
>   

Great! So we support another one of the alix boards and nobody except
knew about it... Could you please add a notice to the wiki and/or v3
Kconfig?


Regards,
Carl-Daniel



From Ken.Fuchs at bench.com  Tue Jun 24 00:23:51 2008
From: Ken.Fuchs at bench.com (Ken.Fuchs at bench.com)
Date: Mon, 23 Jun 2008 17:23:51 -0500
Subject: [coreboot] [RFC] coreboot Live CD
In-Reply-To: <485FD3B2.30407@coresystems.de>
Message-ID: <AA28F077645B324881335614E4F7C4284A4941@win-ex01.bench.com>

> Ken.Fuchs at bench.com wrote:
> >> On Fri, Jun 20, 2008 at 4:30 PM,  <Ken.Fuchs at bench.com> wrote:
> >>     
> >>> Another problem with LinuxBIOS and now with coreboot
> >>> is all the mainboards I tried to build or the even
> >>> the payloads would never compile without some serious
> >>> errors.  Hopefully, a validated coreboot Live CD
> >>> would solve this problem and increase exposure of
> >>> coreboot at the same time.
> >>>       
> >> Ken, no offense intended, but this is a vacuous comment 
> >> absent logs of
> >> failed builds. But we'd love to see them.
> >>     
> >
> > I sent a log of filo-0.5 compilation issues nearly two weeks
> > ago as detailed in the following three URIs:
> >
> > http://www.coreboot.org/pipermail/coreboot/2008-June/035647.html
> > http://www.coreboot.org/pipermail/coreboot/2008-June/035674.html
> > http://www.coreboot.org/pipermail/coreboot/2008-June/035718.html
> >
> > Thanks for responding to my filo-0.5 compilation issues as detailed
> > in the first URI above, but no one responded to my log in the final
> > URI above.

Stefan Reinauer wrote:

> Can you post line 197 of printf.c ? It seems your source code 
> is corrupt 
> or something.

My NFS server and NFS client do not appear to be working.
It did not occur to me that NFS could be the problem,
since have used this server reliably for 2-3 years.

When I put the filo-0.5 source code on a Linux ramdisk,
it cleanly built filo.
 
> > ------
> >
> > I haven't previously reported my latest coreboot build issue.
> > Here it is:
> >
> > $ cd ./targets
> > $ ./buildtarget tyan/s2885
> > build_dir=tyan/s2885/s2885
> > No coreboot config script found. Rebuilding it..
> >   File 
> > "/mnt/s2u1/atom/cb/coreboot-v2-3360/util/newconfig/yapps2.py",
> > line 418
> >     gen.write(indent, "elsf update(self, gen):
> >                                              ^
>  
> Same issue here:
> 
> The line in my source code is:
>         gen.write(indent, "else: ")

I copied the coreboot-v2-3385 source code to a USB
pen drive and it now builds cleanly.

> Your source code is seriously corrupted. How did you download it?

I downloaded it via Firefox and maybe the FlashGot plug-in
and associated wxDownloadFast download manager.  However,
it doesn't appear to have been corrupted by the download
itself.

As mentioned above, it appears to be a problem with my
"previously" reliable GNU/Linux (PPC Gentoo based) NFS
server or the NFS client of my most recent machine.
I manually started portmap on it, so perhaps that may
be related to may corruption problems.

Thanks to everyone who responded to this RFC, including:

ron minnich
Joseph Smith
Stefan Reinauer

I still think that a coreboot Live CD (maybe a Knoppix
remastering) would be a good way to promote coreboot
adoption.

Maybe coreboot on a DSL sized business card mini-CD?  Now
that would be an impressive card to give out at shows!

Sincerely,

Ken Fuchs



From peter at stuge.se  Tue Jun 24 00:24:00 2008
From: peter at stuge.se (Peter Stuge)
Date: Tue, 24 Jun 2008 00:24:00 +0200
Subject: [coreboot] filo: Skip native
	ATA	controllers	in	find_ide_controller_compat()
In-Reply-To: <48601B8E.1080802@gmx.net>
References: <20080622001710.GA4308@morn.localdomain>
	<20080621024128.19965.qmail@stuge.se>
	<20080621024522.23166.qmail@stuge.se>
	<485C89DA.1090303@onelabs.com>
	<20080621060650.11428.qmail@stuge.se> <485D5560.20802@onelabs.com>
	<20080622015501.19071.qmail@stuge.se>
	<485FEB6F.6080407@gmx.net> <20080623204229.3337.qmail@stuge.se>
	<48601B8E.1080802@gmx.net>
Message-ID: <20080623222400.21037.qmail@stuge.se>

On Mon, Jun 23, 2008 at 11:54:22PM +0200, Carl-Daniel Hailfinger wrote:
> >>> Thanks for testing this! I confirmed correct functionality also
> >>> on ALIX 3c3.
> >>
> >> 2c3 or 3c3?
> >
> > 3c3, I don't have a 2c3. I think that's Ward's board.
> 
> Great! So we support another one of the alix boards and nobody
> except knew about it... Could you please add a notice to the wiki
> and/or v3 Kconfig?

Not so fast. I was refering to the FILO patch. :)

coreboot did boot the board, but interrupts seem not OK yet.

I'll look into that though. :)


//Peter



From kevin at koconnor.net  Tue Jun 24 00:33:49 2008
From: kevin at koconnor.net (Kevin O'Connor)
Date: Mon, 23 Jun 2008 18:33:49 -0400
Subject: [coreboot] Black window when running qemu
	with	coreboot+LegacyBIOS
In-Reply-To: <485FCEC5.6020202@coresystems.de>
References: <92cbc4c70806181829x67547e58pf4df99b2a72d241b@mail.gmail.com>
	<20080619014748.GA1344@morn.localdomain>
	<92cbc4c70806190100u47e07626mf433ebcb54197b8@mail.gmail.com>
	<20080619123929.GA7437@morn.localdomain>
	<92cbc4c70806192001p1c4ccbfx5952683362efbd15@mail.gmail.com>
	<20080620125646.GA19607@morn.localdomain>
	<20080620231128.GA8661@cosmic.amd.com>
	<006301c8d54c$3f307430$0023040a@chimp>
	<20080623161953.GE11345@cosmic.amd.com>
	<485FCEC5.6020202@coresystems.de>
Message-ID: <20080623223349.GA16946@morn.localdomain>

Hi,

On Mon, Jun 23, 2008 at 06:26:45PM +0200, Stefan Reinauer wrote:
> Please, before we get this into buildrom, let's get it straight first.  
> Zhang Rui is working on integration of LegacyBIOS for all purposes, not  
> just int19 booting. It will replace a lot of code in current coreboot.  
> We should consider keeping it in util/ in the v3 tree.

I think it is a bad idea to copy the LegacyBIOS code into another
repo.  I believe there should be one main repository that qemu, bochs,
kvm, etc. can all use.  See also:

http://www.coreboot.org/pipermail/coreboot/2008-June/035788.html

-Kevin



From mylesgw at gmail.com  Tue Jun 24 00:51:31 2008
From: mylesgw at gmail.com (Myles Watson)
Date: Mon, 23 Jun 2008 16:51:31 -0600
Subject: [coreboot] Black window when running qemu with
	coreboot+LegacyBIOS
In-Reply-To: <20080623223349.GA16946@morn.localdomain>
References: <92cbc4c70806181829x67547e58pf4df99b2a72d241b@mail.gmail.com>
	<92cbc4c70806190100u47e07626mf433ebcb54197b8@mail.gmail.com>
	<20080619123929.GA7437@morn.localdomain>
	<92cbc4c70806192001p1c4ccbfx5952683362efbd15@mail.gmail.com>
	<20080620125646.GA19607@morn.localdomain>
	<20080620231128.GA8661@cosmic.amd.com>
	<006301c8d54c$3f307430$0023040a@chimp>
	<20080623161953.GE11345@cosmic.amd.com>
	<485FCEC5.6020202@coresystems.de>
	<20080623223349.GA16946@morn.localdomain>
Message-ID: <2831fecf0806231551v2840f96dl4d817dcc2b07c4d9@mail.gmail.com>

On Mon, Jun 23, 2008 at 4:33 PM, Kevin O'Connor <kevin at koconnor.net> wrote:
> Hi,
>
> On Mon, Jun 23, 2008 at 06:26:45PM +0200, Stefan Reinauer wrote:
>> Please, before we get this into buildrom, let's get it straight first.
>> Zhang Rui is working on integration of LegacyBIOS for all purposes, not
>> just int19 booting. It will replace a lot of code in current coreboot.
>> We should consider keeping it in util/ in the v3 tree.
>
> I think it is a bad idea to copy the LegacyBIOS code into another
> repo.  I believe there should be one main repository that qemu, bochs,
> kvm, etc. can all use.

I agree.  The more people we can serve with the same code base, the
more stable it will be.

Thanks,
Myles



From mylesgw at gmail.com  Tue Jun 24 00:53:46 2008
From: mylesgw at gmail.com (Myles Watson)
Date: Mon, 23 Jun 2008 16:53:46 -0600
Subject: [coreboot] Add legacybios to buildrom
Message-ID: <2831fecf0806231553l3980d985kcb09dfba0e7954c0@mail.gmail.com>

This is the same patch I posted earlier which adds legacybios to
buildrom.  It has some options hardcoded in hardcode.diff because it
seems like the easiest way to keep the configuration in one place.

Signed-off-by: Myles Watson <mylesgw at gmail.com>

Thanks,
Myles
-------------- next part --------------
A non-text attachment was scrubbed...
Name: add_legacybios.diff
Type: text/x-patch
Size: 5484 bytes
Desc: not available
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20080623/a7829b20/attachment.diff>

From Ken.Fuchs at bench.com  Tue Jun 24 01:27:21 2008
From: Ken.Fuchs at bench.com (Ken.Fuchs at bench.com)
Date: Mon, 23 Jun 2008 18:27:21 -0500
Subject: [coreboot] coreboot and U-Boot: a comparison
In-Reply-To: <485D5310.8030802@georgi-clan.de>
Message-ID: <AA28F077645B324881335614E4F7C4284A4942@win-ex01.bench.com>

> > Ken Fuchs wrote:

> >> 8) U-Boot now has architecture specific git repositories for
> >>   active development available via http protocol that passes
> >>   through most firewalls transparently.  coreboot has a
> >>   single SVN repository that seems to be accessible only
> >>   via the svn protocol which requires that the svn port
> >>   be open on the firewall which is often impossible to get
> >>   approved, since it is a "non-standard" port.

> ron minnich schrieb:

> > ah, git. Love it or hate it. I know people who have used it and now
> > stopped. We had a truly terrible experience with LB and arch years
> > ago, and the SCM question is a sensitive one. I have had people tell
> > me "move to git" and others tell me "please please DON'T 
> > EVER MOVE TO
> > GIT".

Patrick Georgi wrote:
   
> I think, the main request here is to have the repo available over a 
> "standard port" (yay, it's PHBs and BOFHs ruining the party again).
> 
> We already provide the cbv2 repo over https (as documented on 
> http://www.coreboot.org/Download_coreboot ), and it should be easy to 
> provide the other repos as well. It should be easy to map 
> them into the 
> http namespace on coreboot.org, if that's truly necessary.

Yes, all source available from the Subversion repository via
http/https is what I'm mainly looking for.  Read only
access would allow update of a developer's current tree.

I actually advocated Subversion when arch was chosen a few
years ago.  Subversion is a good SCM, but a lot of open source
projects have moved to git.  However, if Subversion is adequate,
I see no pressing reason to switch to git.  There are some
nice tools to track source code at a high level via git though.

Sincerely,

Ken Fuchs



From ward at gnu.org  Tue Jun 24 03:20:10 2008
From: ward at gnu.org (Ward Vandewege)
Date: Mon, 23 Jun 2008 21:20:10 -0400
Subject: [coreboot] flashrom: Slight restructure of SPI probe_ functions
In-Reply-To: <20080621051045.32488.qmail@stuge.se>
References: <20080621051045.32488.qmail@stuge.se>
Message-ID: <20080624012010.GA8241@localdomain>

On Sat, Jun 21, 2008 at 07:10:45AM +0200, Peter Stuge wrote:
> Patch attached.
> 
> 
> //Peter
> 
> 
> !DSPAM:485c8dbe118861804284693!

> flashrom: Slight restructure of SPI probe_ functions
> 
> Preparation for a probe optimization patch to come. This patch does not change
> functionality. spi_probe_rdid was tested to still work on my M57SLI rev 2.
> 
> The idea is to have error checks return error immediately when something
> fails, rather than having code inside an if block testing for success.
> This means: Less indentation, more clear what the code checks for.
> 
> Signed-off-by: Peter Stuge <peter at stuge.se>

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

Thanks,
Ward.

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



From svn at coreboot.org  Tue Jun 24 03:22:03 2008
From: svn at coreboot.org (svn at coreboot.org)
Date: Tue, 24 Jun 2008 03:22:03 +0200
Subject: [coreboot] r3386 - trunk/util/flashrom
Message-ID: <mailman.1654.1355071335.16123.coreboot@coreboot.org>

Author: stuge
Date: 2008-06-24 03:22:03 +0200 (Tue, 24 Jun 2008)
New Revision: 3386

Modified:
   trunk/util/flashrom/spi.c
Log:
flashrom: Slight restructure of SPI probe_ functions

Preparation for a probe optim