From c-d.hailfinger.devel.2006 at gmx.net  Sat Mar  1 00:53:33 2008
From: c-d.hailfinger.devel.2006 at gmx.net (Carl-Daniel Hailfinger)
Date: Sat, 01 Mar 2008 00:53:33 +0100
Subject: [coreboot] [PATCH] v3: convert fake SPD to struct spd_entry
In-Reply-To: <20080229211638.GA23974@coresystems.de>
References: <47C4601C.5020809@gmx.net> <20080229204700.GB8306@coresystems.de>
	<47C87353.3090807@gmx.net> <20080229211638.GA23974@coresystems.de>
Message-ID: <47C89AFD.2000408@gmx.net>

On 29.02.2008 22:16, Stefan Reinauer wrote:
> * Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006 at gmx.net> [080229 22:04]:
>   
>>>  85% of 128 bytes? Therefore this is O(n) now instead of O(1) in ROM
>>> accesses. Are you sure?
>>>   
>>>       
>> Well, since we need the fake SPD in initram, we can't compress it and 
>> really lose that space in ROM. That's why I decided to accept higher lookup 
>> cost to achieve space savings. However, if anybody can show that the 
>> increased code complexity costs us more ROM space than what we save by 
>> converting the data structure from a direct access array to an iterated 
>> list, I'm all for changing it back.
>>     
>
>
> Oh I had assumed you had already analyzed the code space savings before
> claiming your method saves 85% by running in a loop instead of once.
>   

Sorry, I forgot that. Statistics for gcc 4.2.1, alix1c initram:

                   |  old  | new
spd_read_byte size |   107 |  109
total size         | 10000 | 9989


If the SPD array had been populated correctly in the old version 
(including checksum bytes), the savings would have been more 
substantial. Oh well.

Regards,
Carl-Daniel

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




From c-d.hailfinger.devel.2006 at gmx.net  Sat Mar  1 00:55:20 2008
From: c-d.hailfinger.devel.2006 at gmx.net (Carl-Daniel Hailfinger)
Date: Sat, 01 Mar 2008 00:55:20 +0100
Subject: [coreboot] Image format is unsupported while building QEMU
In-Reply-To: <20080229212303.GA26191@coresystems.de>
References: <fa70bcc0802290457s6221d527o19757027ef566315@mail.gmail.com>
	<20080229212303.GA26191@coresystems.de>
Message-ID: <47C89B68.9020805@gmx.net>

On 29.02.2008 22:23, Stefan Reinauer wrote:
> * malatesh kamatad <malateshkamat at gmail.com> [080229 13:57]:
>   
>> coreboot-2.0.0-GRUB2 Fri Feb 22 15:42:36 IST 2008 starting...
>>     
>
> ..
>
>   
>> rom_stream: 0xfffc0000 - 0xfffeffff
>> Found ELF candidate at offset 0
>> Unsupported image format
>>     
>  
> As of now, I suggest to use coreboot v3 if you want to use
> mainstream grub.
>   

You created an unpartitioned hard disk image. That is probably not 
supported.

Regards,
Carl-Daniel

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




From c-d.hailfinger.devel.2006 at gmx.net  Sat Mar  1 01:13:55 2008
From: c-d.hailfinger.devel.2006 at gmx.net (Carl-Daniel Hailfinger)
Date: Sat, 01 Mar 2008 01:13:55 +0100
Subject: [coreboot] flashrom issues??
In-Reply-To: <20080229192145.GA15773@coresystems.de>
References: <20080216134533.6awmn90xcsww80c4@www.smittys.pointclark.net>
	<20080219112943.6w24vj5rc0okkc4s@www.smittys.pointclark.net>
	<20080219163507.GA21962@coresystems.de>
	<20080229123601.4dnjxissn40c4gw8@www.smittys.pointclark.net>
	<20080229190715.GA10976@coresystems.de> <47C8593F.1030607@gmx.net>
	<20080229192145.GA15773@coresystems.de>
Message-ID: <47C89FC3.3000207@gmx.net>

On 29.02.2008 20:21, Stefan Reinauer wrote:
> * Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006 at gmx.net> [080229 20:13]:
>   
>>>>> Yes, it means the actual flash write mechanism is protected, though the
>>>>> ID command gets through. I had the same thing on another ICH4M board.
>>>>> Might be SMM protection, some GPIO or some other mapping/locking
>>>>> mechanism.

"Might be SMM...", so this is not certain.

>>>> Do you remember what you did to fix this on the ICH4-M?
>>>>     
>>>>         
>>> The issue remained unfixed, I used a Galep5 to burn the flash chips.
>>>   
>>>       
>> In theory, this should be debuggable with DOS ports of the ICH GPIO dumper 
>> and superiotool.
>>     
>
> SMM based bios lock down? How so? It does not seem to be a GPIO issue in
> case. 
>   

If the lockdown is indeed SMM based, we can find out with superiotool 
and the GPIO dumper (they will show no changes in GPIO configuration). 
Then again, if you can ID the chip, it means you can write to it and the 
only thing missing is setting the TBL# and WP# pins of the flash chip 
high. Both pins are probably connected to some GPIOs, so unless SMM 
protects access to the GPIO settings, flashing should be possible.
If the problem appears under coreboot as well, we can rule out SMM 
protection, but not SMM flash enabling.

Regards,
Carl-Daniel

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




From c-d.hailfinger.devel.2006 at gmx.net  Sat Mar  1 02:58:56 2008
From: c-d.hailfinger.devel.2006 at gmx.net (Carl-Daniel Hailfinger)
Date: Sat, 01 Mar 2008 02:58:56 +0100
Subject: [coreboot] patch: dbe62
In-Reply-To: <13426df10802290852h109ab986o89a83f689a14148b@mail.gmail.com>
References: <13426df10802281441v109c6edai8e448131a0539c93@mail.gmail.com>	<20080229010002.9912.qmail@stuge.se>	<13426df10802281853q27757ab3mac567ab8c574412@mail.gmail.com>	<20080229134132.2184.qmail@stuge.se>
	<13426df10802290852h109ab986o89a83f689a14148b@mail.gmail.com>
Message-ID: <47C8B860.5030700@gmx.net>

On 29.02.2008 17:52, ron minnich wrote:
> On Fri, Feb 29, 2008 at 5:41 AM, Peter Stuge <peter at stuge.se> wrote:
>
>   
>>  > >  > +void mainboard_pre_payload(void)
>>  > >  > +{
>>  > >  > +     geode_pre_payload();
>>  > >  > +     banner(BIOS_DEBUG, "mainboard_pre_payload: done");
>>  > >  > +}
>>  > >
>>  > >  Why do we need this mainboard code when it is only calling a
>>  > >  function that can be determined using the dts?
>>  >
>>  > Show me how. I don't know.
>>
>>  arch/x86/stage1.c currently calls mainboard_pre_payload() - for
>>  Geode LX the call has nothing to do with the mainboard and
>>  everything to do with the north.
>>
>>  geode_pre_payload() is defined in geodelx/geodelxinit.c, so one easy
>>  way is to rename it to northbridge_amd_geodelx_pre_payload() and
>>  generate the call from data in the dts.
>>
>>  Another way would be to add it to struct device_operations. I like
>>  that better actually.
>>     
>
>
> Yep, but here you've hit a limitation in the design which we never
> thought of. Device stuff is in stage 2. But this mainboard_early stuff
> is in main (btw, we're going to need to rename arch/x86/stage1.c again
> -- since it calls stage2 and stage2 returns to it, it's not really a
> stage1 at all. I believe the name change was my mistake).
>   

Perhaps call it "launcher" stage? On the other hand, it is part of the 
bootblock (so either stage0 or stage1) and it is after CAR has been 
switched on (so definitely stage1). I vote to keep the name until we 
figure out something better.

> The device tree is in stage 2. It goes away at the end of stage2 since
> we didn't see a need for it. The data that it creates is gone at that
> point.
>
> OK, it gets worse. You REALLY don't want to do this call until just
> about the last second, after payload is up and ready to go, since it
> disables ROM caching. That's a long time after stage 2. You can't do
> this call in stage2.
>
> There are several options here but most of them are not that great.
> 1. add phase7 to stage 2 in device tree and return dynamic device tree
> from stage 2 to caller.
> stage2 phase 7 is now called AFTER payload is loaded and BEFORE
> payload is jumped to. This breaks our nice stage design but that's
> life. Big problem -- where does device tree go in memory and what do
> we do if it interferes with payload location?
> 2. what we have now -- it works.
>   

What we have now is OK, but there is room for improvement.

> 3. name a pre-payload in the dts, have dtc build the
> mainboard_pre_payload function for us, call stays as it is now.
> 4. Linker sets -- Oh, yuck, a lot of work went into v3 to AVOID linker sets.
>   

5. Maybe the name of mainboard_pre_payload() is unfortunate and we 
should have pre_payload() which calls cpu_pre_payload(), 
chipset_pre_payload() and mainboard_pre_payload() in a row. That way, we 
don't have to put any GeodeLX ROM cache disabling below mainboard() and 
keep that stuff local to the southbridge code.


>>  > >  > +unsigned long write_pirq_routing_table(unsigned long addr)
>>  > >
>>  > >  What an abomination. hint hint ;)
>>  > >
>>  > >  Can this code really not live in northbridge/ ?
>>  >
>>  > no, it's a south function, with mainboard-dependent bits. I'm happy
>>  > to see a way to make it generic, I just don't know how yet.
>>
>>  Is the _code_ really mainboard dependent? I would think it's device
>>  dependent, and the board only changes input values. Am I off?
>>     
>
> Sure, but it's almost always a southbridge thing. But you need to
> rewrite the code quite a bit to move it to the south directory, and
> I'm not sure it's worth it in the end -- having it in mainboard allows
> you to deal with mainboard bugs and problems very easily.
>   

Peter's idea was probably to separate code from data and I think there 
is some potential in that idea. write_pirq_routing_table() is identical 
for alix1c and dbe62 and could in theory really live in the south 
directory. AFAICS this wouldn't even require any changes in the function.

Regards,
Carl-Daniel

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




From rminnich at gmail.com  Sat Mar  1 03:03:37 2008
From: rminnich at gmail.com (ron minnich)
Date: Fri, 29 Feb 2008 18:03:37 -0800
Subject: [coreboot] patch: dbe62
In-Reply-To: <47C8B860.5030700@gmx.net>
References: <13426df10802281441v109c6edai8e448131a0539c93@mail.gmail.com>
	<20080229010002.9912.qmail@stuge.se>
	<13426df10802281853q27757ab3mac567ab8c574412@mail.gmail.com>
	<20080229134132.2184.qmail@stuge.se>
	<13426df10802290852h109ab986o89a83f689a14148b@mail.gmail.com>
	<47C8B860.5030700@gmx.net>
Message-ID: <13426df10802291803y2b042304pfa78ce2e2900dfa1@mail.gmail.com>

On Fri, Feb 29, 2008 at 5:58 PM, Carl-Daniel Hailfinger
<c-d.hailfinger.devel.2006 at gmx.net> wrote:

>  Peter's idea was probably to separate code from data and I think there
>  is some potential in that idea. write_pirq_routing_table() is identical
>  for alix1c and dbe62 and could in theory really live in the south
>  directory. AFAICS this wouldn't even require any changes in the function.

it's a great idea. I just don't yet know how to do it.

ron



From rminnich at gmail.com  Sat Mar  1 03:06:14 2008
From: rminnich at gmail.com (ron minnich)
Date: Fri, 29 Feb 2008 18:06:14 -0800
Subject: [coreboot] patch: dbe62
In-Reply-To: <47C8B860.5030700@gmx.net>
References: <13426df10802281441v109c6edai8e448131a0539c93@mail.gmail.com>
	<20080229010002.9912.qmail@stuge.se>
	<13426df10802281853q27757ab3mac567ab8c574412@mail.gmail.com>
	<20080229134132.2184.qmail@stuge.se>
	<13426df10802290852h109ab986o89a83f689a14148b@mail.gmail.com>
	<47C8B860.5030700@gmx.net>
Message-ID: <13426df10802291806g62eb8de0s9db1479630eb98fd@mail.gmail.com>

On Fri, Feb 29, 2008 at 5:58 PM, Carl-Daniel Hailfinger
<c-d.hailfinger.devel.2006 at gmx.net> wrote:

>  5. Maybe the name of mainboard_pre_payload() is unfortunate and we
>  should have pre_payload() which calls cpu_pre_payload(),
>  chipset_pre_payload() and mainboard_pre_payload() in a row. That way, we
>  don't have to put any GeodeLX ROM cache disabling below mainboard() and
>  keep that stuff local to the southbridge code.
>

My concern here is we're going to walk our way back to the v1 style
functions that end up mostly empty (e.g. mainboard_pre_payload(){}) on
most targets. Mainboard_pre_payload is a hack but I have no good ideas
on workarounds. Let's think this out some more. We'll get it.

The chipsets are always changing our ideas on how to set up the software :-)

ron



From c-d.hailfinger.devel.2006 at gmx.net  Sat Mar  1 03:33:07 2008
From: c-d.hailfinger.devel.2006 at gmx.net (Carl-Daniel Hailfinger)
Date: Sat, 01 Mar 2008 03:33:07 +0100
Subject: [coreboot] patch: dbe62
In-Reply-To: <13426df10802291806g62eb8de0s9db1479630eb98fd@mail.gmail.com>
References: <13426df10802281441v109c6edai8e448131a0539c93@mail.gmail.com>	
	<20080229010002.9912.qmail@stuge.se>	
	<13426df10802281853q27757ab3mac567ab8c574412@mail.gmail.com>	
	<20080229134132.2184.qmail@stuge.se>	
	<13426df10802290852h109ab986o89a83f689a14148b@mail.gmail.com>	
	<47C8B860.5030700@gmx.net>
	<13426df10802291806g62eb8de0s9db1479630eb98fd@mail.gmail.com>
Message-ID: <47C8C063.9000306@gmx.net>

On 01.03.2008 03:06, ron minnich wrote:
> On Fri, Feb 29, 2008 at 5:58 PM, Carl-Daniel Hailfinger wrote:
>   
>>  5. Maybe the name of mainboard_pre_payload() is unfortunate and we
>>  should have pre_payload() which calls cpu_pre_payload(),
>>  chipset_pre_payload() and mainboard_pre_payload() in a row. That way, we
>>  don't have to put any GeodeLX ROM cache disabling below mainboard() and
>>  keep that stuff local to the southbridge code
>
> My concern here is we're going to walk our way back to the v1 style
> functions that end up mostly empty (e.g. mainboard_pre_payload(){}) on
> most targets. Mainboard_pre_payload is a hack but I have no good ideas
> on workarounds. Let's think this out some more. We'll get it.
>   

Actually, these empty functions should be zero cost in the binary with 
gcc, but they clutter the source code. Hmm. I'd like something like 
"overridable functions" similar to weak functions, but where gcc is able 
to strip out the call if no non-empty function exists.

> The chipsets are always changing our ideas on how to set up the software :-)
>   

Indeed.

Regards,
Carl-Daniel

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




From peter at stuge.se  Sat Mar  1 03:51:19 2008
From: peter at stuge.se (Peter Stuge)
Date: Sat, 1 Mar 2008 03:51:19 +0100
Subject: [coreboot] Geode GX / CS5535 / PIC
In-Reply-To: <20080229161131.GA30432@greenwood>
References: <47C73861.3010802@gmx.de> <20080229004346.5836.qmail@stuge.se>
	<47C79B71.8050103@gmx.de> <47C79D4B.8020702@gmx.de>
	<20080229142247.GA18182@greenwood> <47C828A2.2070102@gmx.de>
	<20080229161131.GA30432@greenwood>
Message-ID: <20080301025119.13631.qmail@stuge.se>

On Fri, Feb 29, 2008 at 05:11:31PM +0100, Uwe Hermann wrote:
> > Here's the board itself:
> > http://www.nottoxic.com/wapcc/dectop/wiki/lib/exe/fetch.php?cache=cache&media=hardware:dectop:dectoplb.jpg
> 
> The BIOS chip is soldered.

It looks like J11 may also have the LPC bus signals. If the boot
flash selector ball is also on J11 you could use Artec's dongle or
just another LPC flash chip to work on coreboot rather than having to
desolder the existing chip.


//Peter



From peter at stuge.se  Sat Mar  1 03:54:34 2008
From: peter at stuge.se (Peter Stuge)
Date: Sat, 1 Mar 2008 03:54:34 +0100
Subject: [coreboot] Fwd:  Unable to power up db800 with coreboot
In-Reply-To: <b61da340802290947g6c3f4408xac6778ff7bcc1bcb@mail.gmail.com>
References: <b61da340802261708u14ac90b0n64290f39a03331ba@mail.gmail.com>
	<47C4B8CE.8070508@amd.com>
	<b61da340802261718u18160207m9dd02f1f69ec895d@mail.gmail.com>
	<47C5AFBB.9050406@amd.com>
	<b61da340802271625sff25d22sa230c606c905b319@mail.gmail.com>
	<47C600B7.4050001@amd.com>
	<b61da340802271632o4a9843c3t42a70dc8f362e2a2@mail.gmail.com>
	<b61da340802281840u2ac2e393xe14ff0fc59cbb4c0@mail.gmail.com>
	<47C82FF3.1040803@amd.com>
	<b61da340802290947g6c3f4408xac6778ff7bcc1bcb@mail.gmail.com>
Message-ID: <20080301025434.15484.qmail@stuge.se>

On Fri, Feb 29, 2008 at 09:47:16AM -0800, Phani Babu Giddi wrote:
> MENULST_FILE = "hda1:/grub/menu.lst"
> 
> AUTOBOOT_FILE = "hda1:/vmlinuz initrd hda1:/initrd root=/dev/hda3
>   vga=0x317 console=tty0 console=ttyS0,115200"

As far as I know these two are mutually exclusive. If using the grub
compatibility stuff in FILO then AUTOBOOT_FILE will never be used.

I don't like grub and thus always stick to only using AUTOBOOT_FILE.

In your case the line looks fine if the kernel is stored in
/boot/vmlinuz, if it's /vmlinuz then change to hda3 instead of hda1
in the first argument.

Oh, and make sure you build FILO with reiserfs support if the kernel
is on your root partition.


//Peter



From phanig at gmail.com  Sat Mar  1 04:04:26 2008
From: phanig at gmail.com (Phani Babu Giddi)
Date: Fri, 29 Feb 2008 19:04:26 -0800
Subject: [coreboot] Fwd: Unable to power up db800 with coreboot
In-Reply-To: <20080301025434.15484.qmail@stuge.se>
References: <b61da340802261708u14ac90b0n64290f39a03331ba@mail.gmail.com>
	<b61da340802261718u18160207m9dd02f1f69ec895d@mail.gmail.com>
	<47C5AFBB.9050406@amd.com>
	<b61da340802271625sff25d22sa230c606c905b319@mail.gmail.com>
	<47C600B7.4050001@amd.com>
	<b61da340802271632o4a9843c3t42a70dc8f362e2a2@mail.gmail.com>
	<b61da340802281840u2ac2e393xe14ff0fc59cbb4c0@mail.gmail.com>
	<47C82FF3.1040803@amd.com>
	<b61da340802290947g6c3f4408xac6778ff7bcc1bcb@mail.gmail.com>
	<20080301025434.15484.qmail@stuge.se>
Message-ID: <b61da340802291904n4cd28d7axf84bafc0adf5fa85@mail.gmail.com>

Hi Peter,

Yes I have turned on resierfs and ext2 too because /boot is and ext2
partition. From your description it looks like the AUTOBOOT options are good
but not sure why it reports of Unsupported image format. Let me first get
rid of GRUB. Do yout know if FILO works for all versions of GRUB boot
loaders or there are some specific boot loaders that it supports.

Regards,
Phani

On Fri, Feb 29, 2008 at 6:54 PM, Peter Stuge <peter at stuge.se> wrote:

> On Fri, Feb 29, 2008 at 09:47:16AM -0800, Phani Babu Giddi wrote:
> > MENULST_FILE = "hda1:/grub/menu.lst"
> >
> > AUTOBOOT_FILE = "hda1:/vmlinuz initrd hda1:/initrd root=/dev/hda3
> >   vga=0x317 console=tty0 console=ttyS0,115200"
>
> As far as I know these two are mutually exclusive. If using the grub
> compatibility stuff in FILO then AUTOBOOT_FILE will never be used.
>
> I don't like grub and thus always stick to only using AUTOBOOT_FILE.
>
> In your case the line looks fine if the kernel is stored in
> /boot/vmlinuz, if it's /vmlinuz then change to hda3 instead of hda1
> in the first argument.
>
> Oh, and make sure you build FILO with reiserfs support if the kernel
> is on your root partition.
>
>
> //Peter
>
> --
> 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/20080229/b0027cbf/attachment.html>

From corey.osgood at gmail.com  Sat Mar  1 07:40:45 2008
From: corey.osgood at gmail.com (Corey Osgood)
Date: Sat, 1 Mar 2008 01:40:45 -0500
Subject: [coreboot] GENFADT and GENDSDT
In-Reply-To: <47C859CC.9080504@gmx.net>
References: <1201558563.3453.25.camel@urbez.site> <47A9B241.7050004@gmx.net>
	<47C5F637.1020006@gmx.net> <1204185304.8207.5.camel@Mobulus>
	<47C6A072.3080101@gmx.net> <47C6ECCC.2090803@gmx.net>
	<20080228202208.GC24000@greenwood> <47C71C45.3040808@gmx.net>
	<dd3c80060802282123h4510ebc4u1deb705ed377138e@mail.gmail.com>
	<47C859CC.9080504@gmx.net>
Message-ID: <dd3c80060802292240l2e2e2c60j5505bb679e12ddc1@mail.gmail.com>

On Fri, Feb 29, 2008 at 2:15 PM, Carl-Daniel Hailfinger <
c-d.hailfinger.devel.2006 at gmx.net> wrote:

> Please note that iasl can't perform any of the functions of
> gendsdt


dumping the dsdt to a file, then iasl -d and iasl -tc will produce the same
thing, but with some sort of optimizations. Disabling the optimizations,
with -oa should produce exactly the same output as gendsdt, except for
whitespace, the copyright header, and some dsdt header info (compiler, etc).
You're entirely correct about genfadt vs iasl though, and now you've got me
thinking that two utiliities is a better idea.

On Fri, Feb 29, 2008 at 2:56 PM, Uwe Hermann <uwe at hermann-uwe.de> wrote:

> On Fri, Feb 29, 2008 at 08:15:24PM +0100, Carl-Daniel Hailfinger wrote:
> > Can we at least agree on the name of the directory where the tool(s)
> > should live? Should we call it gen_acpi or genacpi? I'd say you decide
>
> genacpi sounds good.
>
>
> Uwe.
>

Ack. Here's a sign-off to make it with:

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

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

From sync.jma at gmail.com  Sat Mar  1 08:59:13 2008
From: sync.jma at gmail.com (Jun Ma)
Date: Sat, 1 Mar 2008 15:59:13 +0800
Subject: [coreboot] Probe missing on W49F002U
Message-ID: <dcf6addc0802292359q47871439i7d9bf80bb85474cd@mail.gmail.com>

Hi, all.
 I downloaded flashrom from
http://www.openbios.org/viewvc/trunk/util/flashrom.tar.gz?view=tar,
also it was built correctly,  when I scp it to an SIS530/SIS5595 board
with debian-4.0r2, it just can't recognize my Winbond W49G002U EEPROM,
here comes the verbose log:


Sis530:~# ./flashrom -c W49F002U
Calibrating delay loop... OK.
No coreboot table found.
Found chipset "SIS5595", enabling flash write... OK.
No EEPROM/flash device found.
Sis530:~# ./flashrom -R
flashrom r
Sis530:~# ./flashrom --version
flashrom r
Sis530:~# ./flashrom -V -r
Calibrating delay loop... 59M loops per second. OK.
No coreboot table found.
Found chipset "SIS5595", enabling flash write... OK.
Probing for Am29F040B, 512 KB
probe_29f040b: id1 0xff, id2 0xff
Probing for Am29LV040B, 512 KB
probe_29f040b: id1 0xff, id2 0xff
Probing for Am29F016D, 2048 KB
probe_29f040b: id1 0xff, id2 0xff
Probing for AE49F2008, 256 KB
probe_jedec: id1 0xff, id2 0xff
Probing for At29C040A, 512 KB
probe_jedec: id1 0xff, id2 0xff
Probing for At29C020, 256 KB
probe_jedec: id1 0xff, id2 0xff
Probing for At49F002(N), 256 KB
probe_jedec: id1 0xff, id2 0xff
Probing for At49F002(N)T, 256 KB
probe_jedec: id1 0xff, id2 0xff
Probing for EN29F002(A)(N)T, 256 KB
probe_jedec: id1 0xff, id2 0xff
Probing for EN29F002(A)(N)B, 256 KB
probe_jedec: id1 0xff, id2 0xff
Probing for MBM29F400TC, 512 KB
probe_m29f400bt: id1 0xff, id2 0xff
Probing for MX29F002, 256 KB
probe_29f002: id1 0xff, id2 0xff
Probing for MX25L4005, 512 KB
generic_spi_command called, but no SPI chipset detected
Probing for MX25L8005, 1024 KB
generic_spi_command called, but no SPI chipset detected
Probing for MX25L3205, 4096 KB
generic_spi_command called, but no SPI chipset detected
Probing for S25FL016A, 2048 KB
generic_spi_command called, but no SPI chipset detected
Probing for SST25VF040B, 512 KB
generic_spi_command called, but no SPI chipset detected
Probing for SST25VF016B, 2048 KB
generic_spi_command called, but no SPI chipset detected
Probing for SST29EE020A, 256 KB
probe_jedec: id1 0xff, id2 0xff
Probing for SST28SF040A, 512 KB
probe_28sf040: id1 0xff, id2 0xff
Probing for SST39SF010A, 128 KB
probe_jedec: id1 0xff, id2 0xff
Probing for SST39SF020A, 256 KB
probe_jedec: id1 0xff, id2 0xff
Probing for SST39SF040, 512 KB
probe_jedec: id1 0xff, id2 0xff
Probing for SST39VF020, 256 KB
probe_jedec: id1 0xff, id2 0xff
Probing for SST49LF040B, 512 KB
probe_jedec: id1 0xff, id2 0xff
Probing for SST49LF040, 512 KB
probe_jedec: id1 0xff, id2 0xff
Probing for SST49LF020A, 256 KB
probe_jedec: id1 0xff, id2 0xff
Probing for SST49LF080A, 1024 KB
probe_jedec: id1 0xff, id2 0xff
Probing for SST49LF002A/B, 256 KB
probe_jedec: id1 0xff, id2 0xff
Probing for SST49LF003A/B, 384 KB
probe_jedec: id1 0xff, id2 0xff
Probing for SST49LF004A/B, 512 KB
probe_jedec: id1 0xff, id2 0xff
Probing for SST49LF008A, 1024 KB
probe_jedec: id1 0xff, id2 0xff
Probing for SST49LF004C, 512 KB
probe_49lfxxxc: id1 0xff, id2 0xff
Probing for SST49LF008C, 1024 KB
probe_49lfxxxc: id1 0xff, id2 0xff
Probing for SST49LF016C, 2048 KB
probe_49lfxxxc: id1 0xff, id2 0xff
Probing for SST49LF160C, 2048 KB
probe_49lfxxxc: id1 0xff, id2 0xff
Probing for Pm49FL002, 256 KB
probe_jedec: id1 0xff, id2 0xff
Probing for Pm49FL004, 512 KB
probe_jedec: id1 0xff, id2 0xff
Probing for Pm25LV512, 64 KB
generic_spi_command called, but no SPI chipset detected
Probing for Pm25LV010, 128 KB
generic_spi_command called, but no SPI chipset detected
Probing for Pm25LV020, 256 KB
generic_spi_command called, but no SPI chipset detected
Probing for Pm25LV040, 512 KB
generic_spi_command called, but no SPI chipset detected
Probing for Pm25LV080B, 1024 KB
generic_spi_command called, but no SPI chipset detected
Probing for Pm25LV016B, 2048 KB
generic_spi_command called, but no SPI chipset detected
Probing for W29C011, 128 KB
probe_jedec: id1 0xff, id2 0xff
Probing for W29C040P, 512 KB
probe_jedec: id1 0xff, id2 0xff
Probing for W29C020C, 256 KB
probe_jedec: id1 0xff, id2 0xff
Probing for W29EE011, 128 KB
probe_w29ee011: id1 0xff, id2 0xff
Probing for W49F002U, 256 KB
probe_jedec: id1 0xff, id2 0xff
Probing for W49V002A, 256 KB
probe_jedec: id1 0xff, id2 0xff
Probing for W49V002FA, 256 KB
probe_jedec: id1 0xff, id2 0xff
Probing for W39V040FA, 512 KB
probe_jedec: id1 0xff, id2 0xff
Probing for W39V040A, 512 KB
probe_jedec: id1 0xff, id2 0xff
Probing for W39V040B, 512 KB
probe_jedec: id1 0xff, id2 0xff
Probing for W39V080A, 1024 KB
probe_jedec: id1 0xff, id2 0xff
Probing for W25x10, 128 KB
generic_spi_command called, but no SPI chipset detected
Probing for W25x20, 256 KB
generic_spi_command called, but no SPI chipset detected
Probing for W25x40, 512 KB
generic_spi_command called, but no SPI chipset detected
Probing for W25x80, 1024 KB
generic_spi_command called, but no SPI chipset detected
Probing for M29F002B, 256 KB
probe_jedec: id1 0xff, id2 0xff
Probing for M50FW040, 512 KB
probe_jedec: id1 0xff, id2 0xff
Probing for M29W040B, 512 KB
probe_jedec: id1 0xff, id2 0xff
Probing for M29F002T/NT, 256 KB
probe_jedec: id1 0xff, id2 0xff
Probing for M29F400BT, 512 KB
probe_m29f400bt: id1 0xff, id2 0xff
Probing for M50FLW040A, 512 KB
probe_jedec: id1 0xff, id2 0xff
Probing for M50FLW040B, 512 KB
probe_jedec: id1 0xff, id2 0xff
Probing for M50FLW080A, 1024 KB
probe_jedec: id1 0xff, id2 0xff
Probing for M50FLW080B, 1024 KB
probe_jedec: id1 0xff, id2 0xff
Probing for M50FW080, 1024 KB
probe_jedec: id1 0xff, id2 0xff
Probing for M50FW016, 2048 KB
probe_jedec: id1 0xff, id2 0xff
Probing for M50LPW116, 2048 KB
probe_jedec: id1 0xff, id2 0xff
Probing for M29W010B, 128 KB
probe_jedec: id1 0xff, id2 0xff
Probing for M29F040B, 512 KB
probe_29f040b: id1 0xff, id2 0xff
Probing for M25P05-A, 64 KB
generic_spi_command called, but no SPI chipset detected
Probing for M25P10-A, 128 KB
generic_spi_command called, but no SPI chipset detected
Probing for M25P20, 256 KB
generic_spi_command called, but no SPI chipset detected
Probing for M25P40, 512 KB
generic_spi_command called, but no SPI chipset detected
Probing for M25P80, 1024 KB
generic_spi_command called, but no SPI chipset detected
Probing for M25P16, 2048 KB
generic_spi_command called, but no SPI chipset detected
Probing for M25P32, 4096 KB
generic_spi_command called, but no SPI chipset detected
Probing for M25P64, 8192 KB
generic_spi_command called, but no SPI chipset detected
Probing for M25P128, 16384 KB
generic_spi_command called, but no SPI chipset detected
Probing for 82802ab, 512 KB
probe_82802ab: id1 0xff, id2 0xff
Probing for 82802ac, 1024 KB
probe_82802ab: id1 0xff, id2 0xff
Probing for F49B002UA, 256 KB
probe_jedec: id1 0xff, id2 0xff
Probing for LHF00L04, 1024 KB
probe_lhf00l04: id1 0xff, id2 0xff
Probing for S29C51001T, 128 KB
probe_jedec: id1 0xff, id2 0xff
Probing for S29C51002T, 256 KB
probe_jedec: id1 0xff, id2 0xff
Probing for S29C51004T, 512 KB
probe_jedec: id1 0xff, id2 0xff
Probing for S29C31004T, 512 KB
probe_jedec: id1 0xff, id2 0xff
Probing for EON unknown SPI chip, 0 KB
WARNING: size: 0 -> 4096 (page size)
generic_spi_command called, but no SPI chipset detected
Probing for MX unknown SPI chip, 0 KB
WARNING: size: 0 -> 4096 (page size)
generic_spi_command called, but no SPI chipset detected
Probing for PMC unknown SPI chip, 0 KB
WARNING: size: 0 -> 4096 (page size)
generic_spi_command called, but no SPI chipset detected
Probing for SST unknown SPI chip, 0 KB
WARNING: size: 0 -> 4096 (page size)
generic_spi_command called, but no SPI chipset detected
Probing for ST unknown SPI chip, 0 KB
WARNING: size: 0 -> 4096 (page size)
generic_spi_command called, but no SPI chipset detected
No EEPROM/flash device found.
Sis530:~#


After quick reading of your source code, I saw this probing function:
int probe_jedec(struct flashchip *flash)
{
      volatile uint8_t *bios = flash->virtual_memory;
      uint8_t id1, id2;
      uint32_t largeid1, largeid2;

      /* Issue JEDEC Product ID Entry command */
      *(volatile uint8_t *)(bios + 0x5555) = 0xAA;
      myusec_delay(10);
      *(volatile uint8_t *)(bios + 0x2AAA) = 0x55;
      myusec_delay(10);
      *(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.
       */
      myusec_delay(40);

      /* Read product ID */
      id1 = *(volatile uint8_t *)bios;
      id2 = *(volatile uint8_t *)(bios + 0x01);
      largeid1 = id1;
      largeid2 = id2;

      /* Check if it is a continuation ID, this should be a while loop. */
      if (id1 == 0x7F) {
              largeid1 <<= 8;
              id1 = *(volatile uint8_t *)(bios + 0x100);
              largeid1 |= id1;
      }
      if (id2 == 0x7F) {
              largeid2 <<= 8;
              id2 = *(volatile uint8_t *)(bios + 0x101);
              largeid2 |= id2;
      }

      /* Issue JEDEC Product ID Exit command */
      *(volatile uint8_t *)(bios + 0x5555) = 0xAA;
      myusec_delay(10);
      *(volatile uint8_t *)(bios + 0x2AAA) = 0x55;
      myusec_delay(10);
      *(volatile uint8_t *)(bios + 0x5555) = 0xF0;
      myusec_delay(40);

      printf_debug("%s: id1 0x%x, id2 0x%x\n", __FUNCTION__,
largeid1, largeid2);
      if (largeid1 == flash->manufacture_id && largeid2 == flash->model_id)
              return 1;

      return 0;
}

Seems flashrom routing got 0xff, 0xff on largeid1, largeid2.
Has anybody tested this routing on SIS530?
Thanks.

-- 
FIXME if it is wrong.



From joe at smittys.pointclark.net  Sat Mar  1 14:04:54 2008
From: joe at smittys.pointclark.net (joe at smittys.pointclark.net)
Date: Sat, 01 Mar 2008 08:04:54 -0500
Subject: [coreboot] flashrom issues??
In-Reply-To: <47C89FC3.3000207@gmx.net>
References: <20080216134533.6awmn90xcsww80c4@www.smittys.pointclark.net>
	<20080219112943.6w24vj5rc0okkc4s@www.smittys.pointclark.net>
	<20080219163507.GA21962@coresystems.de>
	<20080229123601.4dnjxissn40c4gw8@www.smittys.pointclark.net>
	<20080229190715.GA10976@coresystems.de> <47C8593F.1030607@gmx.net>
	<20080229192145.GA15773@coresystems.de> <47C89FC3.3000207@gmx.net>
Message-ID: <20080301080454.x1rgbpahwwks4k8c@www.smittys.pointclark.net>

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

> On 29.02.2008 20:21, Stefan Reinauer wrote:
>> * Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006 at gmx.net> [080229 20:13]:
>>
>>>>>> Yes, it means the actual flash write mechanism is protected, though the
>>>>>> ID command gets through. I had the same thing on another ICH4M board.
>>>>>> Might be SMM protection, some GPIO or some other mapping/locking
>>>>>> mechanism.
>
> "Might be SMM...", so this is not certain.
>
>>>>> Do you remember what you did to fix this on the ICH4-M?
>>>>>
>>>> The issue remained unfixed, I used a Galep5 to burn the flash chips.
>>>>
>>> In theory, this should be debuggable with DOS ports of the ICH   
>>> GPIO dumper and superiotool.
>>>
>>
>> SMM based bios lock down? How so? It does not seem to be a GPIO issue in
>> case.
>
> If the lockdown is indeed SMM based, we can find out with superiotool
> and the GPIO dumper (they will show no changes in GPIO configuration).
> Then again, if you can ID the chip, it means you can write to it and
> the only thing missing is setting the TBL# and WP# pins of the flash
> chip high. Both pins are probably connected to some GPIOs, so unless
> SMM protects access to the GPIO settings, flashing should be possible.
> If the problem appears under coreboot as well, we can rule out SMM
> protection, but not SMM flash enabling.
>
To check this with superiotool I have to be able to dump the "Runtime  
Registers", this is where the GPIO's are (See the SMSC lpc47m192  
datasheet for more info). Currently superiotool does not dump these  
registers so modifications will be required.

Little confused about SMM? In the nothbridge datasheet it talks about  
SMM (System Management Space), I do not have any of these registers  
set, just defaults. In the southbridge datasheet it talks about SMM  
(special mask mode), I do not have any of these registers set eithor,  
just defaults. Are these related, or two different things? Do I need  
to set these registers up?


Thanks - Joe



From joe at smittys.pointclark.net  Sat Mar  1 16:12:13 2008
From: joe at smittys.pointclark.net (joe at smittys.pointclark.net)
Date: Sat, 01 Mar 2008 10:12:13 -0500
Subject: [coreboot] IDE cable select question
In-Reply-To: <20080222155354.vwphwy7zk04gs4sw@www.smittys.pointclark.net>
References: <20080222111554.ffirg0lfb40ookg8@www.smittys.pointclark.net>
	<13426df10802220858x6601ce57yc2246e579c8ce426@mail.gmail.com>
	<20080222121511.8i2h9rkyyokwwkws@www.smittys.pointclark.net>
	<13426df10802220958v39aa13e0v928d5c231e18da1f@mail.gmail.com>
	<20080222131325.hfnef0552coocokw@www.smittys.pointclark.net>
	<20080222150303.4dlfqz83s40w4cg0@www.smittys.pointclark.net>
	<47BF2F5C.5070109@gmx.net>
	<20080222155354.vwphwy7zk04gs4sw@www.smittys.pointclark.net>
Message-ID: <20080301101213.rsxwai4asg84s4s8@www.smittys.pointclark.net>

Well,
Much to my suprise it looks like pin 34 of the IDE connetor does not  
assert a signal if the cable is 40 pin and does assert a signal if the  
cable is 80 pin. This is a standard for all motherboards that support  
ATA66/ATA100. Now I just have to figure out where this signal is  
asserted too (maybe a GPIO -> in). Once I figure that out this will be  
easy. I can just tell coreboot to: read ide cable signal, set ide  
cable select register bit to 1.


Thanks - Joe



From c-d.hailfinger.devel.2006 at gmx.net  Sat Mar  1 16:16:30 2008
From: c-d.hailfinger.devel.2006 at gmx.net (Carl-Daniel Hailfinger)
Date: Sat, 01 Mar 2008 16:16:30 +0100
Subject: [coreboot] patch: dbe62
In-Reply-To: <13426df10802291803y2b042304pfa78ce2e2900dfa1@mail.gmail.com>
References: <13426df10802281441v109c6edai8e448131a0539c93@mail.gmail.com>	<20080229010002.9912.qmail@stuge.se>	<13426df10802281853q27757ab3mac567ab8c574412@mail.gmail.com>	<20080229134132.2184.qmail@stuge.se>	<13426df10802290852h109ab986o89a83f689a14148b@mail.gmail.com>	<47C8B860.5030700@gmx.net>
	<13426df10802291803y2b042304pfa78ce2e2900dfa1@mail.gmail.com>
Message-ID: <47C9734E.1010807@gmx.net>

On 01.03.2008 03:03, ron minnich wrote:
> On Fri, Feb 29, 2008 at 5:58 PM, Carl-Daniel Hailfinger
> <c-d.hailfinger.devel.2006 at gmx.net> wrote:
>
>   
>>  Peter's idea was probably to separate code from data and I think there
>>  is some potential in that idea. write_pirq_routing_table() is identical
>>  for alix1c and dbe62 and could in theory really live in the south
>>  directory. AFAICS this wouldn't even require any changes in the function.
>>     
>
> it's a great idea. I just don't yet know how to do it.
>   

Ron: The patch is also attached to reduce your gmail pain.

Factor out write_pirq_routing_table() for all GeodeLX targets.
Compile tested on norwich, alix1c and dbe62. msm800sev is not affected 
and dbe61 is broken anyway.

svn is unable to create a valid patch for what I did, so I'll have to 
commit this myself. To reproduce, perform the following commands, then 
apply the patch:

svn mv mainboard/amd/norwich/irq_tables.c mainboard/amd/norwich/irq_tables.h
svn mv mainboard/pcengines/alix1c/irq_tables.c mainboard/pcengines/alix1c/irq_tables.h
svn mv mainboard/artecgroup/dbe61/irq_tables.c mainboard/artecgroup/dbe61/irq_tables.h
svn mv mainboard/artecgroup/dbe62/irq_tables.c mainboard/artecgroup/dbe62/irq_tables.h

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


Index: LinuxBIOSv3-pirq/southbridge/amd/cs5536/irq_tables.c
===================================================================
--- LinuxBIOSv3-pirq/southbridge/amd/cs5536/irq_tables.c	(Revision 0)
+++ LinuxBIOSv3-pirq/southbridge/amd/cs5536/irq_tables.c	(Revision 0)
@@ -0,0 +1,77 @@
+/*
+* This file is part of the coreboot project.
+*
+* Copyright (C) 2007 Advanced Micro Devices, Inc.
+*
+* This program is free software; you can redistribute it and/or modify
+* it under the terms of the GNU General Public License version 2 as
+* published by the Free Software Foundation.
+*
+* 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 <types.h>
+#include <lib.h>
+#include <console.h>
+#include <device/device.h>
+#include <device/pci.h>
+#include <string.h>
+#include <msr.h>
+#include <io.h>
+#include <pirq_routing.h>
+#include <amd_geodelx.h>
+#include <irq_tables.h>
+#include "cs5536.h"
+
+unsigned long write_pirq_routing_table(unsigned long addr)
+{
+	int i, j, k, num_entries;
+	unsigned char pirq[4];
+	u16 chipset_irq_map;
+	u32 pciAddr, pirtable_end;
+	struct irq_routing_table *pirq_tbl;
+
+	pirtable_end = copy_pirq_routing_table(addr);
+
+	/* Set up chipset IRQ steering. */
+	pciAddr = 0x80000000 | (CHIPSET_DEV_NUM << 11) | 0x5C;
+	chipset_irq_map = (PIRQD << 12 | PIRQC << 8 | PIRQB << 4 | PIRQA);
+	printk(BIOS_DEBUG, "%s(%08X, %04X)\n", __FUNCTION__, pciAddr,
+		     chipset_irq_map);
+	outl(pciAddr & ~3, 0xCF8);
+	outl(chipset_irq_map, 0xCFC);
+
+	pirq_tbl = (struct irq_routing_table *) (addr);
+	num_entries = (pirq_tbl->size - 32) / 16;
+
+	/* Set PCI IRQs. */
+	for (i = 0; i < num_entries; i++) {
+		printk(BIOS_DEBUG, "PIR Entry %d Dev/Fn: %X Slot: %d\n", i,
+			     pirq_tbl->slots[i].devfn, pirq_tbl->slots[i].slot);
+		for (j = 0; j < 4; j++) {
+			printk(BIOS_DEBUG, "INT: %c bitmap: %x ", 'A' + j,
+				     pirq_tbl->slots[i].irq[j].bitmap);
+			/* Finds lsb in bitmap to IRQ#. */
+			for (k = 0; 
+			     (!((pirq_tbl->slots[i].irq[j].bitmap >> k) & 1)) 
+				     && (pirq_tbl->slots[i].irq[j].bitmap != 0);
+			     k++);
+			pirq[j] = k;
+			printk(BIOS_DEBUG, "PIRQ: %d\n", k);
+		}
+
+		/* Bus, device, slots IRQs for {A,B,C,D}. */
+		pci_assign_irqs(pirq_tbl->slots[i].bus,
+				pirq_tbl->slots[i].devfn >> 3, pirq);
+	}
+
+	/* Put the PIR table in memory and checksum. */
+	return pirtable_end;
+}
Index: LinuxBIOSv3-pirq/southbridge/amd/cs5536/Makefile
===================================================================
--- LinuxBIOSv3-pirq/southbridge/amd/cs5536/Makefile	(Revision 626)
+++ LinuxBIOSv3-pirq/southbridge/amd/cs5536/Makefile	(Arbeitskopie)
@@ -23,6 +23,10 @@
 
 STAGE2_CHIPSET_OBJ += $(obj)/southbridge/amd/cs5536/cs5536.o
 
+ifeq ($(CONFIG_PIRQ_TABLE),y)
+STAGE2_CHIPSET_OBJ += $(obj)/southbridge/amd/cs5536/irq_tables.o 
+endif
+
 STAGE0_CHIPSET_OBJ += $(obj)/southbridge/amd/cs5536/stage1.o
 
 endif
Index: LinuxBIOSv3-pirq/mainboard/amd/norwich/irq_tables.h
===================================================================
--- LinuxBIOSv3-pirq/mainboard/amd/norwich/irq_tables.h	(Revision 626)
+++ LinuxBIOSv3-pirq/mainboard/amd/norwich/irq_tables.h	(Arbeitskopie)
@@ -93,49 +93,3 @@
 	 {0x00, (0x0C << 3) | 0x0, {{L_PIRQA, M_PIRQA}, {L_PIRQB, M_PIRQB}, {L_PIRQC, M_PIRQC}, {L_PIRQD, M_PIRQD}}, 0x4, 0x0},	/* slot4 */
 	 }
 };
-
-unsigned long write_pirq_routing_table(unsigned long addr)
-{
-	int i, j, k, num_entries;
-	unsigned char pirq[4];
-	u16 chipset_irq_map;
-	u32 pciAddr, pirtable_end;
-	struct irq_routing_table *pirq_tbl;
-
-	pirtable_end = copy_pirq_routing_table(addr);
-
-	/* Set up chipset IRQ steering. */
-	pciAddr = 0x80000000 | (CHIPSET_DEV_NUM << 11) | 0x5C;
-	chipset_irq_map = (PIRQD << 12 | PIRQC << 8 | PIRQB << 4 | PIRQA);
-	printk(BIOS_DEBUG, "%s(%08X, %04X)\n", __FUNCTION__, pciAddr,
-		     chipset_irq_map);
-	outl(pciAddr & ~3, 0xCF8);
-	outl(chipset_irq_map, 0xCFC);
-
-	pirq_tbl = (struct irq_routing_table *) (addr);
-	num_entries = (pirq_tbl->size - 32) / 16;
-
-	/* Set PCI IRQs. */
-	for (i = 0; i < num_entries; i++) {
-		printk(BIOS_DEBUG, "PIR Entry %d Dev/Fn: %X Slot: %d\n", i,
-			     pirq_tbl->slots[i].devfn, pirq_tbl->slots[i].slot);
-		for (j = 0; j < 4; j++) {
-			printk(BIOS_DEBUG, "INT: %c bitmap: %x ", 'A' + j,
-				     pirq_tbl->slots[i].irq[j].bitmap);
-			/* Finds lsb in bitmap to IRQ#. */
-			for (k = 0;
-			     (!((pirq_tbl->slots[i].irq[j].bitmap >> k) & 1))
-				     && (pirq_tbl->slots[i].irq[j].bitmap != 0);
-			     k++);
-			pirq[j] = k;
-			printk(BIOS_DEBUG, "PIRQ: %d\n", k);
-		}
-
-		/* Bus, device, slots IRQs for {A,B,C,D}. */
-		pci_assign_irqs(pirq_tbl->slots[i].bus,
-				pirq_tbl->slots[i].devfn >> 3, pirq);
-	}
-
-	/* Put the PIR table in memory and checksum. */
-	return pirtable_end;
-}
Index: LinuxBIOSv3-pirq/mainboard/amd/norwich/Makefile
===================================================================
--- LinuxBIOSv3-pirq/mainboard/amd/norwich/Makefile	(Revision 626)
+++ LinuxBIOSv3-pirq/mainboard/amd/norwich/Makefile	(Arbeitskopie)
@@ -26,7 +26,7 @@
 		$(src)/southbridge/amd/cs5536/smbus_initram.c \
 		$(src)/arch/x86/geodelx/geodelx.c
 
-STAGE2_MAINBOARD_OBJ = irq_tables.o
+STAGE2_MAINBOARD_OBJ = 
 
 $(obj)/coreboot.vpd:
 	$(Q)printf "  BUILD   DUMMY VPD\n"
Index: LinuxBIOSv3-pirq/mainboard/artecgroup/dbe62/irq_tables.h
===================================================================
--- LinuxBIOSv3-pirq/mainboard/artecgroup/dbe62/irq_tables.h	(Revision 626)
+++ LinuxBIOSv3-pirq/mainboard/artecgroup/dbe62/irq_tables.h	(Arbeitskopie)
@@ -68,49 +68,3 @@
 	 {0x00, (0x0D << 3) | 0x0, {{L_PIRQC, M_PIRQC}, {0x00, 0x00}, {0x00, 0x00}, {0x00, 0x00}}, 0x0, 0x0},	/* ethernet */
 	}
 };
-
-unsigned long write_pirq_routing_table(unsigned long addr)
-{
-	int i, j, k, num_entries;
-	unsigned char pirq[4];
-	u16 chipset_irq_map;
-	u32 pciAddr, pirtable_end;
-	struct irq_routing_table *pirq_tbl;
-
-	pirtable_end = copy_pirq_routing_table(addr);
-
-	/* Set up chipset IRQ steering. */
-	pciAddr = 0x80000000 | (CHIPSET_DEV_NUM << 11) | 0x5C;
-	chipset_irq_map = (PIRQD << 12 | PIRQC << 8 | PIRQB << 4 | PIRQA);
-	printk(BIOS_DEBUG, "%s(%08X, %04X)\n", __FUNCTION__, pciAddr,
-		     chipset_irq_map);
-	outl(pciAddr & ~3, 0xCF8);
-	outl(chipset_irq_map, 0xCFC);
-
-	pirq_tbl = (struct irq_routing_table *) (addr);
-	num_entries = (pirq_tbl->size - 32) / 16;
-
-	/* Set PCI IRQs. */
-	for (i = 0; i < num_entries; i++) {
-		printk(BIOS_DEBUG, "PIR Entry %d Dev/Fn: %X Slot: %d\n", i,
-			     pirq_tbl->slots[i].devfn, pirq_tbl->slots[i].slot);
-		for (j = 0; j < 4; j++) {
-			printk(BIOS_DEBUG, "INT: %c bitmap: %x ", 'A' + j,
-				     pirq_tbl->slots[i].irq[j].bitmap);
-			/* Finds lsb in bitmap to IRQ#. */
-			for (k = 0; 
-			     (!((pirq_tbl->slots[i].irq[j].bitmap >> k) & 1)) 
-				     && (pirq_tbl->slots[i].irq[j].bitmap != 0);
-			     k++);
-			pirq[j] = k;
-			printk(BIOS_DEBUG, "PIRQ: %d\n", k);
-		}
-
-		/* Bus, device, slots IRQs for {A,B,C,D}. */
-		pci_assign_irqs(pirq_tbl->slots[i].bus,
-				pirq_tbl->slots[i].devfn >> 3, pirq);
-	}
-
-	/* Put the PIR table in memory and checksum. */
-	return pirtable_end;
-}
Index: LinuxBIOSv3-pirq/mainboard/artecgroup/dbe62/Makefile
===================================================================
--- LinuxBIOSv3-pirq/mainboard/artecgroup/dbe62/Makefile	(Revision 626)
+++ LinuxBIOSv3-pirq/mainboard/artecgroup/dbe62/Makefile	(Arbeitskopie)
@@ -25,7 +25,7 @@
 		$(src)/northbridge/amd/geodelx/raminit.c \
 		$(src)/arch/x86/geodelx/geodelx.c
 
-STAGE2_MAINBOARD_OBJ = irq_tables.o 
+STAGE2_MAINBOARD_OBJ = 
 
 $(obj)/coreboot.vpd:
 	$(Q)printf "  BUILD   DUMMY VPD\n"
Index: LinuxBIOSv3-pirq/mainboard/pcengines/alix1c/irq_tables.h
===================================================================
--- LinuxBIOSv3-pirq/mainboard/pcengines/alix1c/irq_tables.h	(Revision 626)
+++ LinuxBIOSv3-pirq/mainboard/pcengines/alix1c/irq_tables.h	(Arbeitskopie)
@@ -17,20 +17,9 @@
 * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA  02110-1301 USA
 */
 
-#include <types.h>
-#include <lib.h>
-#include <console.h>
-#include <device/device.h>
-#include <device/pci.h>
-#include <string.h>
-#include <msr.h>
-#include <io.h>
 #include <pirq_routing.h>
-#include <amd_geodelx.h>
-#include "../../../southbridge/amd/cs5536/cs5536.h"
 
 
-
 /* Platform IRQs */
 #define PIRQA 11
 #define PIRQB 10
@@ -112,49 +101,3 @@
 		{0x00, (0x0F << 3) | 0x0, {{L_PIRQA, M_PIRQA}, {L_PIRQB, M_PIRQB}, {L_PIRQC, M_PIRQC}, {L_PIRQD, M_PIRQD}}, 0x0, 0x0},
 	}
 };
-
-unsigned long write_pirq_routing_table(unsigned long addr)
-{
-	int i, j, k, num_entries;
-	unsigned char pirq[4];
-	u16 chipset_irq_map;
-	u32 pciAddr, pirtable_end;
-	struct irq_routing_table *pirq_tbl;
-
-	pirtable_end = copy_pirq_routing_table(addr);
-
-	/* Set up chipset IRQ steering. */
-	pciAddr = 0x80000000 | (CHIPSET_DEV_NUM << 11) | 0x5C;
-	chipset_irq_map = (PIRQD << 12 | PIRQC << 8 | PIRQB << 4 | PIRQA);
-	printk(BIOS_DEBUG, "%s(%08X, %04X)\n", __FUNCTION__, pciAddr,
-		     chipset_irq_map);
-	outl(pciAddr & ~3, 0xCF8);
-	outl(chipset_irq_map, 0xCFC);
-
-	pirq_tbl = (struct irq_routing_table *) (addr);
-	num_entries = (pirq_tbl->size - 32) / 16;
-
-	/* Set PCI IRQs. */
-	for (i = 0; i < num_entries; i++) {
-		printk(BIOS_DEBUG, "PIR Entry %d Dev/Fn: %X Slot: %d\n", i,
-			     pirq_tbl->slots[i].devfn, pirq_tbl->slots[i].slot);
-		for (j = 0; j < 4; j++) {
-			printk(BIOS_DEBUG, "INT: %c bitmap: %x ", 'A' + j,
-				     pirq_tbl->slots[i].irq[j].bitmap);
-			/* Finds lsb in bitmap to IRQ#. */
-			for (k = 0; 
-			     (!((pirq_tbl->slots[i].irq[j].bitmap >> k) & 1)) 
-				     && (pirq_tbl->slots[i].irq[j].bitmap != 0);
-			     k++);
-			pirq[j] = k;
-			printk(BIOS_DEBUG, "PIRQ: %d\n", k);
-		}
-
-		/* Bus, device, slots IRQs for {A,B,C,D}. */
-		pci_assign_irqs(pirq_tbl->slots[i].bus,
-				pirq_tbl->slots[i].devfn >> 3, pirq);
-	}
-
-	/* Put the PIR table in memory and checksum. */
-	return pirtable_end;
-}
Index: LinuxBIOSv3-pirq/mainboard/pcengines/alix1c/Makefile
===================================================================
--- LinuxBIOSv3-pirq/mainboard/pcengines/alix1c/Makefile	(Revision 626)
+++ LinuxBIOSv3-pirq/mainboard/pcengines/alix1c/Makefile	(Arbeitskopie)
@@ -25,7 +25,7 @@
 		$(src)/northbridge/amd/geodelx/raminit.c \
 		$(src)/arch/x86/geodelx/geodelx.c
 
-STAGE2_MAINBOARD_OBJ = irq_tables.o 
+STAGE2_MAINBOARD_OBJ = 
 
 $(obj)/coreboot.vpd:
 	$(Q)printf "  BUILD   DUMMY VPD\n"
Index: LinuxBIOSv3-pirq/Makefile
===================================================================
--- LinuxBIOSv3-pirq/Makefile	(Revision 626)
+++ LinuxBIOSv3-pirq/Makefile	(Arbeitskopie)
@@ -85,6 +85,7 @@
 COREBOOTINCLUDE    :=   -I$(src) -Iinclude \
 			-I$(src)/include \
 			-I$(src)/include/arch/$(ARCH)/ \
+			-I$(src)/mainboard/$(MAINBOARDDIR)/ \
 			-include $(obj)/config.h \
 			-include $(obj)/build.h
 



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

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

From peter at stuge.se  Sat Mar  1 16:27:21 2008
From: peter at stuge.se (Peter Stuge)
Date: Sat, 1 Mar 2008 16:27:21 +0100
Subject: [coreboot] patch: dbe62
In-Reply-To: <47C9734E.1010807@gmx.net>
References: <13426df10802281441v109c6edai8e448131a0539c93@mail.gmail.com>
	<20080229010002.9912.qmail@stuge.se>
	<13426df10802281853q27757ab3mac567ab8c574412@mail.gmail.com>
	<20080229134132.2184.qmail@stuge.se>
	<13426df10802290852h109ab986o89a83f689a14148b@mail.gmail.com>
	<47C8B860.5030700@gmx.net>
	<13426df10802291803y2b042304pfa78ce2e2900dfa1@mail.gmail.com>
	<47C9734E.1010807@gmx.net>
Message-ID: <20080301152721.25943.qmail@stuge.se>

You got it with code vs. data, Carl-Daniel. This is a nice good step
towards what I meant! :)

I'll try to think a bit about how to express interrupt routing, but
there is no point in a different syntax if it isn't more flexible.
I think this will crystallize for k8.


On Sat, Mar 01, 2008 at 04:16:30PM +0100, Carl-Daniel Hailfinger wrote:
> Ron: The patch is also attached to reduce your gmail pain.
> 
> Factor out write_pirq_routing_table() for all GeodeLX targets.
> Compile tested on norwich, alix1c and dbe62. msm800sev is not affected 
> and dbe61 is broken anyway.
> 
> svn is unable to create a valid patch for what I did, so I'll have to 
> commit this myself. To reproduce, perform the following commands, then 
> apply the patch:
> 
> svn mv mainboard/amd/norwich/irq_tables.c mainboard/amd/norwich/irq_tables.h
> svn mv mainboard/pcengines/alix1c/irq_tables.c 
> mainboard/pcengines/alix1c/irq_tables.h
> svn mv mainboard/artecgroup/dbe61/irq_tables.c 
> mainboard/artecgroup/dbe61/irq_tables.h
> svn mv mainboard/artecgroup/dbe62/irq_tables.c 
> mainboard/artecgroup/dbe62/irq_tables.h
> 
> Signed-off-by: Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006 at gmx.net>

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

(but let's have some more comments)


> Index: LinuxBIOSv3-pirq/southbridge/amd/cs5536/irq_tables.c
> ===================================================================
> --- LinuxBIOSv3-pirq/southbridge/amd/cs5536/irq_tables.c	(Revision 0)
> +++ LinuxBIOSv3-pirq/southbridge/amd/cs5536/irq_tables.c	(Revision 0)
> @@ -0,0 +1,77 @@
> +/*
> +* This file is part of the coreboot project.
> +*
> +* Copyright (C) 2007 Advanced Micro Devices, Inc.
> +*
> +* This program is free software; you can redistribute it and/or modify
> +* it under the terms of the GNU General Public License version 2 as
> +* published by the Free Software Foundation.
> +*
> +* 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 <types.h>
> +#include <lib.h>
> +#include <console.h>
> +#include <device/device.h>
> +#include <device/pci.h>
> +#include <string.h>
> +#include <msr.h>
> +#include <io.h>
> +#include <pirq_routing.h>
> +#include <amd_geodelx.h>
> +#include <irq_tables.h>
> +#include "cs5536.h"
> +
> +unsigned long write_pirq_routing_table(unsigned long addr)
> +{
> +	int i, j, k, num_entries;
> +	unsigned char pirq[4];
> +	u16 chipset_irq_map;
> +	u32 pciAddr, pirtable_end;
> +	struct irq_routing_table *pirq_tbl;
> +
> +	pirtable_end = copy_pirq_routing_table(addr);
> +
> +	/* Set up chipset IRQ steering. */
> +	pciAddr = 0x80000000 | (CHIPSET_DEV_NUM << 11) | 0x5C;
> +	chipset_irq_map = (PIRQD << 12 | PIRQC << 8 | PIRQB << 4 | PIRQA);
> +	printk(BIOS_DEBUG, "%s(%08X, %04X)\n", __FUNCTION__, pciAddr,
> +		     chipset_irq_map);
> +	outl(pciAddr & ~3, 0xCF8);
> +	outl(chipset_irq_map, 0xCFC);
> +
> +	pirq_tbl = (struct irq_routing_table *) (addr);
> +	num_entries = (pirq_tbl->size - 32) / 16;
> +
> +	/* Set PCI IRQs. */
> +	for (i = 0; i < num_entries; i++) {
> +		printk(BIOS_DEBUG, "PIR Entry %d Dev/Fn: %X Slot: %d\n", i,
> +			     pirq_tbl->slots[i].devfn, 
> pirq_tbl->slots[i].slot);
> +		for (j = 0; j < 4; j++) {
> +			printk(BIOS_DEBUG, "INT: %c bitmap: %x ", 'A' + j,
> +				     pirq_tbl->slots[i].irq[j].bitmap);
> +			/* Finds lsb in bitmap to IRQ#. */
> +			for (k = 0; 
> +			     (!((pirq_tbl->slots[i].irq[j].bitmap >> k) & 
> 1)) +				     && (pirq_tbl->slots[i].irq[j].bitmap != 
> 0);
> +			     k++);
> +			pirq[j] = k;
> +			printk(BIOS_DEBUG, "PIRQ: %d\n", k);
> +		}
> +
> +		/* Bus, device, slots IRQs for {A,B,C,D}. */
> +		pci_assign_irqs(pirq_tbl->slots[i].bus,
> +				pirq_tbl->slots[i].devfn >> 3, pirq);
> +	}
> +
> +	/* Put the PIR table in memory and checksum. */
> +	return pirtable_end;
> +}
> Index: LinuxBIOSv3-pirq/southbridge/amd/cs5536/Makefile
> ===================================================================
> --- LinuxBIOSv3-pirq/southbridge/amd/cs5536/Makefile	(Revision 626)
> +++ LinuxBIOSv3-pirq/southbridge/amd/cs5536/Makefile	(Arbeitskopie)
> @@ -23,6 +23,10 @@
> 
> STAGE2_CHIPSET_OBJ += $(obj)/southbridge/amd/cs5536/cs5536.o
> 
> +ifeq ($(CONFIG_PIRQ_TABLE),y)
> +STAGE2_CHIPSET_OBJ += $(obj)/southbridge/amd/cs5536/irq_tables.o 
> +endif
> +
> STAGE0_CHIPSET_OBJ += $(obj)/southbridge/amd/cs5536/stage1.o
> 
> endif
> Index: LinuxBIOSv3-pirq/mainboard/amd/norwich/irq_tables.h
> ===================================================================
> --- LinuxBIOSv3-pirq/mainboard/amd/norwich/irq_tables.h	(Revision 
> 626)
> +++ LinuxBIOSv3-pirq/mainboard/amd/norwich/irq_tables.h (Arbeitskopie)
> @@ -93,49 +93,3 @@
> 	 {0x00, (0x0C << 3) | 0x0, {{L_PIRQA, M_PIRQA}, {L_PIRQB, M_PIRQB}, 
> 	 {L_PIRQC, M_PIRQC}, {L_PIRQD, M_PIRQD}}, 0x4, 0x0},	/* slot4 */
> 	 }
> };
> -
> -unsigned long write_pirq_routing_table(unsigned long addr)
> -{
> -	int i, j, k, num_entries;
> -	unsigned char pirq[4];
> -	u16 chipset_irq_map;
> -	u32 pciAddr, pirtable_end;
> -	struct irq_routing_table *pirq_tbl;
> -
> -	pirtable_end = copy_pirq_routing_table(addr);
> -
> -	/* Set up chipset IRQ steering. */
> -	pciAddr = 0x80000000 | (CHIPSET_DEV_NUM << 11) | 0x5C;
> -	chipset_irq_map = (PIRQD << 12 | PIRQC << 8 | PIRQB << 4 | PIRQA);
> -	printk(BIOS_DEBUG, "%s(%08X, %04X)\n", __FUNCTION__, pciAddr,
> -		     chipset_irq_map);
> -	outl(pciAddr & ~3, 0xCF8);
> -	outl(chipset_irq_map, 0xCFC);
> -
> -	pirq_tbl = (struct irq_routing_table *) (addr);
> -	num_entries = (pirq_tbl->size - 32) / 16;
> -
> -	/* Set PCI IRQs. */
> -	for (i = 0; i < num_entries; i++) {
> -		printk(BIOS_DEBUG, "PIR Entry %d Dev/Fn: %X Slot: %d\n", i,
> -			     pirq_tbl->slots[i].devfn, 
> pirq_tbl->slots[i].slot);
> -		for (j = 0; j < 4; j++) {
> -			printk(BIOS_DEBUG, "INT: %c bitmap: %x ", 'A' + j,
> -				     pirq_tbl->slots[i].irq[j].bitmap);
> -			/* Finds lsb in bitmap to IRQ#. */
> -			for (k = 0;
> -			     (!((pirq_tbl->slots[i].irq[j].bitmap >> k) & 1))
> -				     && (pirq_tbl->slots[i].irq[j].bitmap != 
> 0);
> -			     k++);
> -			pirq[j] = k;
> -			printk(BIOS_DEBUG, "PIRQ: %d\n", k);
> -		}
> -
> -		/* Bus, device, slots IRQs for {A,B,C,D}. */
> -		pci_assign_irqs(pirq_tbl->slots[i].bus,
> -				pirq_tbl->slots[i].devfn >> 3, pirq);
> -	}
> -
> -	/* Put the PIR table in memory and checksum. */
> -	return pirtable_end;
> -}
> Index: LinuxBIOSv3-pirq/mainboard/amd/norwich/Makefile
> ===================================================================
> --- LinuxBIOSv3-pirq/mainboard/amd/norwich/Makefile	(Revision 626)
> +++ LinuxBIOSv3-pirq/mainboard/amd/norwich/Makefile	(Arbeitskopie)
> @@ -26,7 +26,7 @@
> 		$(src)/southbridge/amd/cs5536/smbus_initram.c \
> 		$(src)/arch/x86/geodelx/geodelx.c
> 
> -STAGE2_MAINBOARD_OBJ = irq_tables.o
> +STAGE2_MAINBOARD_OBJ = 
> 
> $(obj)/coreboot.vpd:
> 	$(Q)printf "  BUILD   DUMMY VPD\n"
> Index: LinuxBIOSv3-pirq/mainboard/artecgroup/dbe62/irq_tables.h
> ===================================================================
> --- LinuxBIOSv3-pirq/mainboard/artecgroup/dbe62/irq_tables.h	(Revision 
> 626)
> +++ LinuxBIOSv3-pirq/mainboard/artecgroup/dbe62/irq_tables.h (Arbeitskopie)
> @@ -68,49 +68,3 @@
> 	 {0x00, (0x0D << 3) | 0x0, {{L_PIRQC, M_PIRQC}, {0x00, 0x00}, {0x00, 
> 	 0x00}, {0x00, 0x00}}, 0x0, 0x0},	/* ethernet */
> 	}
> };
> -
> -unsigned long write_pirq_routing_table(unsigned long addr)
> -{
> -	int i, j, k, num_entries;
> -	unsigned char pirq[4];
> -	u16 chipset_irq_map;
> -	u32 pciAddr, pirtable_end;
> -	struct irq_routing_table *pirq_tbl;
> -
> -	pirtable_end = copy_pirq_routing_table(addr);
> -
> -	/* Set up chipset IRQ steering. */
> -	pciAddr = 0x80000000 | (CHIPSET_DEV_NUM << 11) | 0x5C;
> -	chipset_irq_map = (PIRQD << 12 | PIRQC << 8 | PIRQB << 4 | PIRQA);
> -	printk(BIOS_DEBUG, "%s(%08X, %04X)\n", __FUNCTION__, pciAddr,
> -		     chipset_irq_map);
> -	outl(pciAddr & ~3, 0xCF8);
> -	outl(chipset_irq_map, 0xCFC);
> -
> -	pirq_tbl = (struct irq_routing_table *) (addr);
> -	num_entries = (pirq_tbl->size - 32) / 16;
> -
> -	/* Set PCI IRQs. */
> -	for (i = 0; i < num_entries; i++) {
> -		printk(BIOS_DEBUG, "PIR Entry %d Dev/Fn: %X Slot: %d\n", i,
> -			     pirq_tbl->slots[i].devfn, 
> pirq_tbl->slots[i].slot);
> -		for (j = 0; j < 4; j++) {
> -			printk(BIOS_DEBUG, "INT: %c bitmap: %x ", 'A' + j,
> -				     pirq_tbl->slots[i].irq[j].bitmap);
> -			/* Finds lsb in bitmap to IRQ#. */
> -			for (k = 0; 
> -			     (!((pirq_tbl->slots[i].irq[j].bitmap >> k) & 
> 1)) -				     && (pirq_tbl->slots[i].irq[j].bitmap != 
> 0);
> -			     k++);
> -			pirq[j] = k;
> -			printk(BIOS_DEBUG, "PIRQ: %d\n", k);
> -		}
> -
> -		/* Bus, device, slots IRQs for {A,B,C,D}. */
> -		pci_assign_irqs(pirq_tbl->slots[i].bus,
> -				pirq_tbl->slots[i].devfn >> 3, pirq);
> -	}
> -
> -	/* Put the PIR table in memory and checksum. */
> -	return pirtable_end;
> -}
> Index: LinuxBIOSv3-pirq/mainboard/artecgroup/dbe62/Makefile
> ===================================================================
> --- LinuxBIOSv3-pirq/mainboard/artecgroup/dbe62/Makefile	(Revision 
> 626)
> +++ LinuxBIOSv3-pirq/mainboard/artecgroup/dbe62/Makefile (Arbeitskopie)
> @@ -25,7 +25,7 @@
> 		$(src)/northbridge/amd/geodelx/raminit.c \
> 		$(src)/arch/x86/geodelx/geodelx.c
> 
> -STAGE2_MAINBOARD_OBJ = irq_tables.o 
> +STAGE2_MAINBOARD_OBJ = 
> 
> $(obj)/coreboot.vpd:
> 	$(Q)printf "  BUILD   DUMMY VPD\n"
> Index: LinuxBIOSv3-pirq/mainboard/pcengines/alix1c/irq_tables.h
> ===================================================================
> --- LinuxBIOSv3-pirq/mainboard/pcengines/alix1c/irq_tables.h	(Revision 
> 626)
> +++ LinuxBIOSv3-pirq/mainboard/pcengines/alix1c/irq_tables.h (Arbeitskopie)
> @@ -17,20 +17,9 @@
> * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA  02110-1301 USA
> */
> 
> -#include <types.h>
> -#include <lib.h>
> -#include <console.h>
> -#include <device/device.h>
> -#include <device/pci.h>
> -#include <string.h>
> -#include <msr.h>
> -#include <io.h>
> #include <pirq_routing.h>
> -#include <amd_geodelx.h>
> -#include "../../../southbridge/amd/cs5536/cs5536.h"
> 
> 
> -
> /* Platform IRQs */
> #define PIRQA 11
> #define PIRQB 10
> @@ -112,49 +101,3 @@
> 		{0x00, (0x0F << 3) | 0x0, {{L_PIRQA, M_PIRQA}, {L_PIRQB, 
> 		M_PIRQB}, {L_PIRQC, M_PIRQC}, {L_PIRQD, M_PIRQD}}, 0x0, 0x0},
> 	}
> };
> -
> -unsigned long write_pirq_routing_table(unsigned long addr)
> -{
> -	int i, j, k, num_entries;
> -	unsigned char pirq[4];
> -	u16 chipset_irq_map;
> -	u32 pciAddr, pirtable_end;
> -	struct irq_routing_table *pirq_tbl;
> -
> -	pirtable_end = copy_pirq_routing_table(addr);
> -
> -	/* Set up chipset IRQ steering. */
> -	pciAddr = 0x80000000 | (CHIPSET_DEV_NUM << 11) | 0x5C;
> -	chipset_irq_map = (PIRQD << 12 | PIRQC << 8 | PIRQB << 4 | PIRQA);
> -	printk(BIOS_DEBUG, "%s(%08X, %04X)\n", __FUNCTION__, pciAddr,
> -		     chipset_irq_map);
> -	outl(pciAddr & ~3, 0xCF8);
> -	outl(chipset_irq_map, 0xCFC);
> -
> -	pirq_tbl = (struct irq_routing_table *) (addr);
> -	num_entries = (pirq_tbl->size - 32) / 16;
> -
> -	/* Set PCI IRQs. */
> -	for (i = 0; i < num_entries; i++) {
> -		printk(BIOS_DEBUG, "PIR Entry %d Dev/Fn: %X Slot: %d\n", i,
> -			     pirq_tbl->slots[i].devfn, 
> pirq_tbl->slots[i].slot);
> -		for (j = 0; j < 4; j++) {
> -			printk(BIOS_DEBUG, "INT: %c bitmap: %x ", 'A' + j,
> -				     pirq_tbl->slots[i].irq[j].bitmap);
> -			/* Finds lsb in bitmap to IRQ#. */
> -			for (k = 0; 
> -			     (!((pirq_tbl->slots[i].irq[j].bitmap >> k) & 
> 1)) -				     && (pirq_tbl->slots[i].irq[j].bitmap != 
> 0);
> -			     k++);
> -			pirq[j] = k;
> -			printk(BIOS_DEBUG, "PIRQ: %d\n", k);
> -		}
> -
> -		/* Bus, device, slots IRQs for {A,B,C,D}. */
> -		pci_assign_irqs(pirq_tbl->slots[i].bus,
> -				pirq_tbl->slots[i].devfn >> 3, pirq);
> -	}
> -
> -	/* Put the PIR table in memory and checksum. */
> -	return pirtable_end;
> -}
> Index: LinuxBIOSv3-pirq/mainboard/pcengines/alix1c/Makefile
> ===================================================================
> --- LinuxBIOSv3-pirq/mainboard/pcengines/alix1c/Makefile	(Revision 
> 626)
> +++ LinuxBIOSv3-pirq/mainboard/pcengines/alix1c/Makefile (Arbeitskopie)
> @@ -25,7 +25,7 @@
> 		$(src)/northbridge/amd/geodelx/raminit.c \
> 		$(src)/arch/x86/geodelx/geodelx.c
> 
> -STAGE2_MAINBOARD_OBJ = irq_tables.o 
> +STAGE2_MAINBOARD_OBJ = 
> 
> $(obj)/coreboot.vpd:
> 	$(Q)printf "  BUILD   DUMMY VPD\n"
> Index: LinuxBIOSv3-pirq/Makefile
> ===================================================================
> --- LinuxBIOSv3-pirq/Makefile	(Revision 626)
> +++ LinuxBIOSv3-pirq/Makefile	(Arbeitskopie)
> @@ -85,6 +85,7 @@
> COREBOOTINCLUDE    :=   -I$(src) -Iinclude \
> 			-I$(src)/include \
> 			-I$(src)/include/arch/$(ARCH)/ \
> +			-I$(src)/mainboard/$(MAINBOARDDIR)/ \
> 			-include $(obj)/config.h \
> 			-include $(obj)/build.h
> 
> 
> 
> 
> -- 
> http://www.hailfinger.org/
> 

> Index: LinuxBIOSv3-pirq/southbridge/amd/cs5536/irq_tables.c
> ===================================================================
> --- LinuxBIOSv3-pirq/southbridge/amd/cs5536/irq_tables.c	(Revision 0)
> +++ LinuxBIOSv3-pirq/southbridge/amd/cs5536/irq_tables.c	(Revision 0)
> @@ -0,0 +1,77 @@
> +/*
> +* This file is part of the coreboot project.
> +*
> +* Copyright (C) 2007 Advanced Micro Devices, Inc.
> +*
> +* This program is free software; you can redistribute it and/or modify
> +* it under the terms of the GNU General Public License version 2 as
> +* published by the Free Software Foundation.
> +*
> +* 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 <types.h>
> +#include <lib.h>
> +#include <console.h>
> +#include <device/device.h>
> +#include <device/pci.h>
> +#include <string.h>
> +#include <msr.h>
> +#include <io.h>
> +#include <pirq_routing.h>
> +#include <amd_geodelx.h>
> +#include <irq_tables.h>
> +#include "cs5536.h"
> +
> +unsigned long write_pirq_routing_table(unsigned long addr)
> +{
> +	int i, j, k, num_entries;
> +	unsigned char pirq[4];
> +	u16 chipset_irq_map;
> +	u32 pciAddr, pirtable_end;
> +	struct irq_routing_table *pirq_tbl;
> +
> +	pirtable_end = copy_pirq_routing_table(addr);
> +
> +	/* Set up chipset IRQ steering. */
> +	pciAddr = 0x80000000 | (CHIPSET_DEV_NUM << 11) | 0x5C;
> +	chipset_irq_map = (PIRQD << 12 | PIRQC << 8 | PIRQB << 4 | PIRQA);
> +	printk(BIOS_DEBUG, "%s(%08X, %04X)\n", __FUNCTION__, pciAddr,
> +		     chipset_irq_map);
> +	outl(pciAddr & ~3, 0xCF8);
> +	outl(chipset_irq_map, 0xCFC);
> +
> +	pirq_tbl = (struct irq_routing_table *) (addr);
> +	num_entries = (pirq_tbl->size - 32) / 16;
> +
> +	/* Set PCI IRQs. */
> +	for (i = 0; i < num_entries; i++) {
> +		printk(BIOS_DEBUG, "PIR Entry %d Dev/Fn: %X Slot: %d\n", i,
> +			     pirq_tbl->slots[i].devfn, pirq_tbl->slots[i].slot);
> +		for (j = 0; j < 4; j++) {
> +			printk(BIOS_DEBUG, "INT: %c bitmap: %x ", 'A' + j,
> +				     pirq_tbl->slots[i].irq[j].bitmap);
> +			/* Finds lsb in bitmap to IRQ#. */
> +			for (k = 0; 
> +			     (!((pirq_tbl->slots[i].irq[j].bitmap >> k) & 1)) 
> +				     && (pirq_tbl->slots[i].irq[j].bitmap != 0);
> +			     k++);
> +			pirq[j] = k;
> +			printk(BIOS_DEBUG, "PIRQ: %d\n", k);
> +		}
> +
> +		/* Bus, device, slots IRQs for {A,B,C,D}. */
> +		pci_assign_irqs(pirq_tbl->slots[i].bus,
> +				pirq_tbl->slots[i].devfn >> 3, pirq);
> +	}
> +
> +	/* Put the PIR table in memory and checksum. */
> +	return pirtable_end;
> +}
> Index: LinuxBIOSv3-pirq/southbridge/amd/cs5536/Makefile
> ===================================================================
> --- LinuxBIOSv3-pirq/southbridge/amd/cs5536/Makefile	(Revision 626)
> +++ LinuxBIOSv3-pirq/southbridge/amd/cs5536/Makefile	(Arbeitskopie)
> @@ -23,6 +23,10 @@
>  
>  STAGE2_CHIPSET_OBJ += $(obj)/southbridge/amd/cs5536/cs5536.o
>  
> +ifeq ($(CONFIG_PIRQ_TABLE),y)
> +STAGE2_CHIPSET_OBJ += $(obj)/southbridge/amd/cs5536/irq_tables.o 
> +endif
> +
>  STAGE0_CHIPSET_OBJ += $(obj)/southbridge/amd/cs5536/stage1.o
>  
>  endif
> Index: LinuxBIOSv3-pirq/mainboard/amd/norwich/irq_tables.h
> ===================================================================
> --- LinuxBIOSv3-pirq/mainboard/amd/norwich/irq_tables.h	(Revision 626)
> +++ LinuxBIOSv3-pirq/mainboard/amd/norwich/irq_tables.h	(Arbeitskopie)
> @@ -93,49 +93,3 @@
>  	 {0x00, (0x0C << 3) | 0x0, {{L_PIRQA, M_PIRQA}, {L_PIRQB, M_PIRQB}, {L_PIRQC, M_PIRQC}, {L_PIRQD, M_PIRQD}}, 0x4, 0x0},	/* slot4 */
>  	 }
>  };
> -
> -unsigned long write_pirq_routing_table(unsigned long addr)
> -{
> -	int i, j, k, num_entries;
> -	unsigned char pirq[4];
> -	u16 chipset_irq_map;
> -	u32 pciAddr, pirtable_end;
> -	struct irq_routing_table *pirq_tbl;
> -
> -	pirtable_end = copy_pirq_routing_table(addr);
> -
> -	/* Set up chipset IRQ steering. */
> -	pciAddr = 0x80000000 | (CHIPSET_DEV_NUM << 11) | 0x5C;
> -	chipset_irq_map = (PIRQD << 12 | PIRQC << 8 | PIRQB << 4 | PIRQA);
> -	printk(BIOS_DEBUG, "%s(%08X, %04X)\n", __FUNCTION__, pciAddr,
> -		     chipset_irq_map);
> -	outl(pciAddr & ~3, 0xCF8);
> -	outl(chipset_irq_map, 0xCFC);
> -
> -	pirq_tbl = (struct irq_routing_table *) (addr);
> -	num_entries = (pirq_tbl->size - 32) / 16;
> -
> -	/* Set PCI IRQs. */
> -	for (i = 0; i < num_entries; i++) {
> -		printk(BIOS_DEBUG, "PIR Entry %d Dev/Fn: %X Slot: %d\n", i,
> -			     pirq_tbl->slots[i].devfn, pirq_tbl->slots[i].slot);
> -		for (j = 0; j < 4; j++) {
> -			printk(BIOS_DEBUG, "INT: %c bitmap: %x ", 'A' + j,
> -				     pirq_tbl->slots[i].irq[j].bitmap);
> -			/* Finds lsb in bitmap to IRQ#. */
> -			for (k = 0;
> -			     (!((pirq_tbl->slots[i].irq[j].bitmap >> k) & 1))
> -				     && (pirq_tbl->slots[i].irq[j].bitmap != 0);
> -			     k++);
> -			pirq[j] = k;
> -			printk(BIOS_DEBUG, "PIRQ: %d\n", k);
> -		}
> -
> -		/* Bus, device, slots IRQs for {A,B,C,D}. */
> -		pci_assign_irqs(pirq_tbl->slots[i].bus,
> -				pirq_tbl->slots[i].devfn >> 3, pirq);
> -	}
> -
> -	/* Put the PIR table in memory and checksum. */
> -	return pirtable_end;
> -}
> Index: LinuxBIOSv3-pirq/mainboard/amd/norwich/Makefile
> ===================================================================
> --- LinuxBIOSv3-pirq/mainboard/amd/norwich/Makefile	(Revision 626)
> +++ LinuxBIOSv3-pirq/mainboard/amd/norwich/Makefile	(Arbeitskopie)
> @@ -26,7 +26,7 @@
>  		$(src)/southbridge/amd/cs5536/smbus_initram.c \
>  		$(src)/arch/x86/geodelx/geodelx.c
>  
> -STAGE2_MAINBOARD_OBJ = irq_tables.o
> +STAGE2_MAINBOARD_OBJ = 
>  
>  $(obj)/coreboot.vpd:
>  	$(Q)printf "  BUILD   DUMMY VPD\n"
> Index: LinuxBIOSv3-pirq/mainboard/artecgroup/dbe62/irq_tables.h
> ===================================================================
> --- LinuxBIOSv3-pirq/mainboard/artecgroup/dbe62/irq_tables.h	(Revision 626)
> +++ LinuxBIOSv3-pirq/mainboard/artecgroup/dbe62/irq_tables.h	(Arbeitskopie)
> @@ -68,49 +68,3 @@
>  	 {0x00, (0x0D << 3) | 0x0, {{L_PIRQC, M_PIRQC}, {0x00, 0x00}, {0x00, 0x00}, {0x00, 0x00}}, 0x0, 0x0},	/* ethernet */
>  	}
>  };
> -
> -unsigned long write_pirq_routing_table(unsigned long addr)
> -{
> -	int i, j, k, num_entries;
> -	unsigned char pirq[4];
> -	u16 chipset_irq_map;
> -	u32 pciAddr, pirtable_end;
> -	struct irq_routing_table *pirq_tbl;
> -
> -	pirtable_end = copy_pirq_routing_table(addr);
> -
> -	/* Set up chipset IRQ steering. */
> -	pciAddr = 0x80000000 | (CHIPSET_DEV_NUM << 11) | 0x5C;
> -	chipset_irq_map = (PIRQD << 12 | PIRQC << 8 | PIRQB << 4 | PIRQA);
> -	printk(BIOS_DEBUG, "%s(%08X, %04X)\n", __FUNCTION__, pciAddr,
> -		     chipset_irq_map);
> -	outl(pciAddr & ~3, 0xCF8);
> -	outl(chipset_irq_map, 0xCFC);
> -
> -	pirq_tbl = (struct irq_routing_table *) (addr);
> -	num_entries = (pirq_tbl->size - 32) / 16;
> -
> -	/* Set PCI IRQs. */
> -	for (i = 0; i < num_entries; i++) {
> -		printk(BIOS_DEBUG, "PIR Entry %d Dev/Fn: %X Slot: %d\n", i,
> -			     pirq_tbl->slots[i].devfn, pirq_tbl->slots[i].slot);
> -		for (j = 0; j < 4; j++) {
> -			printk(BIOS_DEBUG, "INT: %c bitmap: %x ", 'A' + j,
> -				     pirq_tbl->slots[i].irq[j].bitmap);
> -			/* Finds lsb in bitmap to IRQ#. */
> -			for (k = 0; 
> -			     (!((pirq_tbl->slots[i].irq[j].bitmap >> k) & 1)) 
> -				     && (pirq_tbl->slots[i].irq[j].bitmap != 0);
> -			     k++);
> -			pirq[j] = k;
> -			printk(BIOS_DEBUG, "PIRQ: %d\n", k);
> -		}
> -
> -		/* Bus, device, slots IRQs for {A,B,C,D}. */
> -		pci_assign_irqs(pirq_tbl->slots[i].bus,
> -				pirq_tbl->slots[i].devfn >> 3, pirq);
> -	}
> -
> -	/* Put the PIR table in memory and checksum. */
> -	return pirtable_end;
> -}
> Index: LinuxBIOSv3-pirq/mainboard/artecgroup/dbe62/Makefile
> ===================================================================
> --- LinuxBIOSv3-pirq/mainboard/artecgroup/dbe62/Makefile	(Revision 626)
> +++ LinuxBIOSv3-pirq/mainboard/artecgroup/dbe62/Makefile	(Arbeitskopie)
> @@ -25,7 +25,7 @@
>  		$(src)/northbridge/amd/geodelx/raminit.c \
>  		$(src)/arch/x86/geodelx/geodelx.c
>  
> -STAGE2_MAINBOARD_OBJ = irq_tables.o 
> +STAGE2_MAINBOARD_OBJ = 
>  
>  $(obj)/coreboot.vpd:
>  	$(Q)printf "  BUILD   DUMMY VPD\n"
> Index: LinuxBIOSv3-pirq/mainboard/pcengines/alix1c/irq_tables.h
> ===================================================================
> --- LinuxBIOSv3-pirq/mainboard/pcengines/alix1c/irq_tables.h	(Revision 626)
> +++ LinuxBIOSv3-pirq/mainboard/pcengines/alix1c/irq_tables.h	(Arbeitskopie)
> @@ -17,20 +17,9 @@
>  * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA  02110-1301 USA
>  */
>  
> -#include <types.h>
> -#include <lib.h>
> -#include <console.h>
> -#include <device/device.h>
> -#include <device/pci.h>
> -#include <string.h>
> -#include <msr.h>
> -#include <io.h>
>  #include <pirq_routing.h>
> -#include <amd_geodelx.h>
> -#include "../../../southbridge/amd/cs5536/cs5536.h"
>  
>  
> -
>  /* Platform IRQs */
>  #define PIRQA 11
>  #define PIRQB 10
> @@ -112,49 +101,3 @@
>  		{0x00, (0x0F << 3) | 0x0, {{L_PIRQA, M_PIRQA}, {L_PIRQB, M_PIRQB}, {L_PIRQC, M_PIRQC}, {L_PIRQD, M_PIRQD}}, 0x0, 0x0},
>  	}
>  };
> -
> -unsigned long write_pirq_routing_table(unsigned long addr)
> -{
> -	int i, j, k, num_entries;
> -	unsigned char pirq[4];
> -	u16 chipset_irq_map;
> -	u32 pciAddr, pirtable_end;
> -	struct irq_routing_table *pirq_tbl;
> -
> -	pirtable_end = copy_pirq_routing_table(addr);
> -
> -	/* Set up chipset IRQ steering. */
> -	pciAddr = 0x80000000 | (CHIPSET_DEV_NUM << 11) | 0x5C;
> -	chipset_irq_map = (PIRQD << 12 | PIRQC << 8 | PIRQB << 4 | PIRQA);
> -	printk(BIOS_DEBUG, "%s(%08X, %04X)\n", __FUNCTION__, pciAddr,
> -		     chipset_irq_map);
> -	outl(pciAddr & ~3, 0xCF8);
> -	outl(chipset_irq_map, 0xCFC);
> -
> -	pirq_tbl = (struct irq_routing_table *) (addr);
> -	num_entries = (pirq_tbl->size - 32) / 16;
> -
> -	/* Set PCI IRQs. */
> -	for (i = 0; i < num_entries; i++) {
> -		printk(BIOS_DEBUG, "PIR Entry %d Dev/Fn: %X Slot: %d\n", i,
> -			     pirq_tbl->slots[i].devfn, pirq_tbl->slots[i].slot);
> -		for (j = 0; j < 4; j++) {
> -			printk(BIOS_DEBUG, "INT: %c bitmap: %x ", 'A' + j,
> -				     pirq_tbl->slots[i].irq[j].bitmap);
> -			/* Finds lsb in bitmap to IRQ#. */
> -			for (k = 0; 
> -			     (!((pirq_tbl->slots[i].irq[j].bitmap >> k) & 1)) 
> -				     && (pirq_tbl->slots[i].irq[j].bitmap != 0);
> -			     k++);
> -			pirq[j] = k;
> -			printk(BIOS_DEBUG, "PIRQ: %d\n", k);
> -		}
> -
> -		/* Bus, device, slots IRQs for {A,B,C,D}. */
> -		pci_assign_irqs(pirq_tbl->slots[i].bus,
> -				pirq_tbl->slots[i].devfn >> 3, pirq);
> -	}
> -
> -	/* Put the PIR table in memory and checksum. */
> -	return pirtable_end;
> -}
> Index: LinuxBIOSv3-pirq/mainboard/pcengines/alix1c/Makefile
> ===================================================================
> --- LinuxBIOSv3-pirq/mainboard/pcengines/alix1c/Makefile	(Revision 626)
> +++ LinuxBIOSv3-pirq/mainboard/pcengines/alix1c/Makefile	(Arbeitskopie)
> @@ -25,7 +25,7 @@
>  		$(src)/northbridge/amd/geodelx/raminit.c \
>  		$(src)/arch/x86/geodelx/geodelx.c
>  
> -STAGE2_MAINBOARD_OBJ = irq_tables.o 
> +STAGE2_MAINBOARD_OBJ = 
>  
>  $(obj)/coreboot.vpd:
>  	$(Q)printf "  BUILD   DUMMY VPD\n"
> Index: LinuxBIOSv3-pirq/Makefile
> ===================================================================
> --- LinuxBIOSv3-pirq/Makefile	(Revision 626)
> +++ LinuxBIOSv3-pirq/Makefile	(Arbeitskopie)
> @@ -85,6 +85,7 @@
>  COREBOOTINCLUDE    :=   -I$(src) -Iinclude \
>  			-I$(src)/include \
>  			-I$(src)/include/arch/$(ARCH)/ \
> +			-I$(src)/mainboard/$(MAINBOARDDIR)/ \
>  			-include $(obj)/config.h \
>  			-include $(obj)/build.h
>  



From svn at coreboot.org  Sat Mar  1 16:33:04 2008
From: svn at coreboot.org (svn at coreboot.org)
Date: Sat,  1 Mar 2008 16:33:04 +0100
Subject: [coreboot] r3120 - trunk/util
Message-ID: <mailman.1237.1355071270.16123.coreboot@coreboot.org>

Author: hailfinger
Date: 2008-03-01 16:33:03 +0100 (Sat, 01 Mar 2008)
New Revision: 3120

Added:
   trunk/util/genacpi/
Log:
Create a genacpi directory below util/ which will hold all acpi related
code/data generation utilities.

Signed-off-by: Corey Osgood <corey.osgood at gmail.com>
Acked-by: Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006 at gmx.net>





From c-d.hailfinger.devel.2006 at gmx.net  Sat Mar  1 16:33:29 2008
From: c-d.hailfinger.devel.2006 at gmx.net (Carl-Daniel Hailfinger)
Date: Sat, 01 Mar 2008 16:33:29 +0100
Subject: [coreboot] GENFADT and GENDSDT
In-Reply-To: <dd3c80060802292240l2e2e2c60j5505bb679e12ddc1@mail.gmail.com>
References: <1201558563.3453.25.camel@urbez.site> <47A9B241.7050004@gmx.net>	
	<47C5F637.1020006@gmx.net> <1204185304.8207.5.camel@Mobulus>	
	<47C6A072.3080101@gmx.net> <47C6ECCC.2090803@gmx.net>	
	<20080228202208.GC24000@greenwood> <47C71C45.3040808@gmx.net>	
	<dd3c80060802282123h4510ebc4u1deb705ed377138e@mail.gmail.com>	
	<47C859CC.9080504@gmx.net>
	<dd3c80060802292240l2e2e2c60j5505bb679e12ddc1@mail.gmail.com>
Message-ID: <47C97749.2070209@gmx.net>

On 01.03.2008 07:40, Corey Osgood wrote:
> On Fri, Feb 29, 2008 at 2:15 PM, Carl-Daniel Hailfinger <
> c-d.hailfinger.devel.2006 at gmx.net> wrote:
>
>   
>> Please note that iasl can't perform any of the functions of
>> gendsdt
>>     
>
>
> dumping the dsdt to a file, then iasl -d and iasl -tc will produce the same
> thing, but with some sort of optimizations. Disabling the optimizations,
> with -oa should produce exactly the same output as gendsdt, except for
> whitespace, the copyright header, and some dsdt header info (compiler, etc).
>   

Sorry, my bad, I didn't know that. Then I vote to drop gendsdt and 
require use of iasl (plus a sed script/whatever to modify the headers) 
instead. We need iasl anyway for the stuff Rudolf is working on.

> You're entirely correct about genfadt vs iasl though, and now you've got me
> thinking that two utiliities is a better idea.
>   

At last! I admit I was really stubborn, though you were nice enough to 
correct me where I was wrong. Thanks!

> On Fri, Feb 29, 2008 at 2:56 PM, Uwe Hermann <uwe at hermann-uwe.de> wrote:
>   
>> On Fri, Feb 29, 2008 at 08:15:24PM +0100, Carl-Daniel Hailfinger wrote:
>>     
>>> Can we at least agree on the name of the directory where the tool(s)
>>> should live? Should we call it gen_acpi or genacpi? I'd say you decide
>>>       
>> genacpi sounds good.
>>     
>
> Ack. Here's a sign-off to make it with:
>
> Signed-off-by: Corey Osgood <corey.osgood at gmail.com>
>   

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

and committed in r3120.

Regards,
Carl-Daniel

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




From c-d.hailfinger.devel.2006 at gmx.net  Sat Mar  1 16:40:36 2008
From: c-d.hailfinger.devel.2006 at gmx.net (Carl-Daniel Hailfinger)
Date: Sat, 01 Mar 2008 16:40:36 +0100
Subject: [coreboot] flashrom issues??
In-Reply-To: <20080301080454.x1rgbpahwwks4k8c@www.smittys.pointclark.net>
References: <20080216134533.6awmn90xcsww80c4@www.smittys.pointclark.net>	<20080219112943.6w24vj5rc0okkc4s@www.smittys.pointclark.net>	<20080219163507.GA21962@coresystems.de>	<20080229123601.4dnjxissn40c4gw8@www.smittys.pointclark.net>	<20080229190715.GA10976@coresystems.de>
	<47C8593F.1030607@gmx.net>	<20080229192145.GA15773@coresystems.de>
	<47C89FC3.3000207@gmx.net>
	<20080301080454.x1rgbpahwwks4k8c@www.smittys.pointclark.net>
Message-ID: <47C978F4.4030904@gmx.net>

On 01.03.2008 14:04, joe at smittys.pointclark.net wrote:
> Quoting Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006 at gmx.net>:
>
>> On 29.02.2008 20:21, Stefan Reinauer wrote:
>>> * Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006 at gmx.net> [080229 
>>> 20:13]:
>>>
>>>>>>> Yes, it means the actual flash write mechanism is protected, 
>>>>>>> though the
>>>>>>> ID command gets through. I had the same thing on another ICH4M 
>>>>>>> board.
>>>>>>> Might be SMM protection, some GPIO or some other mapping/locking
>>>>>>> mechanism.
>>
>> "Might be SMM...", so this is not certain.
>>
>>>>>> Do you remember what you did to fix this on the ICH4-M?
>>>>>>
>>>>> The issue remained unfixed, I used a Galep5 to burn the flash chips.
>>>>>
>>>> In theory, this should be debuggable with DOS ports of the ICH  
>>>> GPIO dumper and superiotool.
>>>>
>>>
>>> SMM based bios lock down? How so? It does not seem to be a GPIO 
>>> issue in
>>> case.
>>
>> If the lockdown is indeed SMM based, we can find out with superiotool
>> and the GPIO dumper (they will show no changes in GPIO configuration).
>> Then again, if you can ID the chip, it means you can write to it and
>> the only thing missing is setting the TBL# and WP# pins of the flash
>> chip high. Both pins are probably connected to some GPIOs, so unless
>> SMM protects access to the GPIO settings, flashing should be possible.
>> If the problem appears under coreboot as well, we can rule out SMM
>> protection, but not SMM flash enabling.
>>
> To check this with superiotool I have to be able to dump the "Runtime 
> Registers", this is where the GPIO's are (See the SMSC lpc47m192 
> datasheet for more info). Currently superiotool does not dump these 
> registers so modifications will be required.

I was relying on the new extended superiotool dumping functionality. 
That doesn't exist yet for your superio, so I should have written 
"...can find out with superiotool (once that has GPIO dumping support 
for your superio) and...". Thanks for correcting me.

> Little confused about SMM? In the nothbridge datasheet it talks about 
> SMM (System Management Space), I do not have any of these registers 
> set, just defaults.

I only know SMM as "System Management Mode" and I hope very much we do 
not have to mess with SMM code arbitrating access to any superio/chipset 
GPIOs.

> In the southbridge datasheet it talks about SMM (special mask mode), I 
> do not have any of these registers set eithor, just defaults. Are 
> these related, or two different things? Do I need to set these 
> registers up?

I had no idea about this meaning of SMM, so I can't answer here.

Regards,
Carl-Daniel

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




From peter at stuge.se  Sat Mar  1 16:50:01 2008
From: peter at stuge.se (Peter Stuge)
Date: Sat, 1 Mar 2008 16:50:01 +0100
Subject: [coreboot] flashrom issues??
In-Reply-To: <20080301080454.x1rgbpahwwks4k8c@www.smittys.pointclark.net>
References: <20080216134533.6awmn90xcsww80c4@www.smittys.pointclark.net>
	<20080219112943.6w24vj5rc0okkc4s@www.smittys.pointclark.net>
	<20080219163507.GA21962@coresystems.de>
	<20080229123601.4dnjxissn40c4gw8@www.smittys.pointclark.net>
	<20080229190715.GA10976@coresystems.de> <47C8593F.1030607@gmx.net>
	<20080229192145.GA15773@coresystems.de> <47C89FC3.3000207@gmx.net>
	<20080301080454.x1rgbpahwwks4k8c@www.smittys.pointclark.net>
Message-ID: <20080301155002.1984.qmail@stuge.se>

On Sat, Mar 01, 2008 at 08:04:54AM -0500, joe at smittys.pointclark.net wrote:
> Little confused about SMM? In the nothbridge datasheet it talks
> about SMM (System Management Space), I do not have any of these
> registers set, just defaults. In the southbridge datasheet it talks
> about SMM (special mask mode), I do not have any of these registers
> set eithor, just defaults. Are these related, or two different
> things? Do I need to set these registers up?

They are different things.

SMM when talking about flashing refers to System Management Mode
which is a special task context supported by mobile-only x86 since
mobile 386SL and later also non-mobile x86.

http://en.wikipedia.org/wiki/System_Management_Mode

SMM is entered by triggering an SMI (System Management Interrupt)
which can be done either by electrical signal to a dedicated pin on
the CPU, or by software traps that are defined when initializing SMM.

Software traps can be set on IO and memory access.

This is the technology used by VSA to emulate legacy hardware on
Geodes.

When it comes to flashing, accessing the flash chip as usual causes a
software trap and the code in SMM (put in place by the factory BIOS
during boot) will determine whether to allow this particular access
to continue onto real hardware or just fail and return 0xff.

There have been some stories on the list about what the SMM code does
to make it's decision, checksums in reserved memory area and whatnot.


//Peter



From peter at stuge.se  Sat Mar  1 16:51:19 2008
From: peter at stuge.se (Peter Stuge)
Date: Sat, 1 Mar 2008 16:51:19 +0100
Subject: [coreboot] flashrom issues??
In-Reply-To: <20080301080454.x1rgbpahwwks4k8c@www.smittys.pointclark.net>
References: <20080216134533.6awmn90xcsww80c4@www.smittys.pointclark.net>
	<20080219112943.6w24vj5rc0okkc4s@www.smittys.pointclark.net>
	<20080219163507.GA21962@coresystems.de>
	<20080229123601.4dnjxissn40c4gw8@www.smittys.pointclark.net>
	<20080229190715.GA10976@coresystems.de> <47C8593F.1030607@gmx.net>
	<20080229192145.GA15773@coresystems.de> <47C89FC3.3000207@gmx.net>
	<20080301080454.x1rgbpahwwks4k8c@www.smittys.pointclark.net>
Message-ID: <20080301155120.2608.qmail@stuge.se>

On Sat, Mar 01, 2008 at 08:04:54AM -0500, joe at smittys.pointclark.net wrote:
> Do I need to set these registers up?

Sorry, I didn't answer this.

No, you don't have to set up SMM when using coreboot.

But coreboot needs to know what tricks the factory BIOS is hiding in
it's SMM code, if any.


//Peter



From c-d.hailfinger.devel.2006 at gmx.net  Sat Mar  1 16:56:15 2008
From: c-d.hailfinger.devel.2006 at gmx.net (Carl-Daniel Hailfinger)
Date: Sat, 01 Mar 2008 16:56:15 +0100
Subject: [coreboot] flashrom issues??
In-Reply-To: <20080301155002.1984.qmail@stuge.se>
References: <20080216134533.6awmn90xcsww80c4@www.smittys.pointclark.net>	<20080219112943.6w24vj5rc0okkc4s@www.smittys.pointclark.net>	<20080219163507.GA21962@coresystems.de>	<20080229123601.4dnjxissn40c4gw8@www.smittys.pointclark.net>	<20080229190715.GA10976@coresystems.de>
	<47C8593F.1030607@gmx.net>	<20080229192145.GA15773@coresystems.de>
	<47C89FC3.3000207@gmx.net>	<20080301080454.x1rgbpahwwks4k8c@www.smittys.pointclark.net>
	<20080301155002.1984.qmail@stuge.se>
Message-ID: <47C97C9F.1010607@gmx.net>

On 01.03.2008 16:50, Peter Stuge wrote:
> On Sat, Mar 01, 2008 at 08:04:54AM -0500, joe at smittys.pointclark.net wrote:
>   
>> Little confused about SMM? In the nothbridge datasheet it talks
>> about SMM (System Management Space), I do not have any of these
>> registers set, just defaults. In the southbridge datasheet it talks
>> about SMM (special mask mode), I do not have any of these registers
>> set eithor, just defaults. Are these related, or two different
>> things? Do I need to set these registers up?
>>     
>
> They are different things.
>
> SMM when talking about flashing refers to System Management Mode
> which is a special task context supported by mobile-only x86 since
> mobile 386SL and later also non-mobile x86.
>
> http://en.wikipedia.org/wiki/System_Management_Mode
>
> SMM is entered by triggering an SMI (System Management Interrupt)
> which can be done either by electrical signal to a dedicated pin on
> the CPU, or by software traps that are defined when initializing SMM.
>
> Software traps can be set on IO and memory access.
>
> This is the technology used by VSA to emulate legacy hardware on
> Geodes.
>
> When it comes to flashing, accessing the flash chip as usual causes a
> software trap and the code in SMM (put in place by the factory BIOS
> during boot) will determine whether to allow this particular access
> to continue onto real hardware or just fail and return 0xff.
>
> There have been some stories on the list about what the SMM code does
> to make it's decision, checksums in reserved memory area and whatnot.
>   

That's why I want to know if this also happens under coreboot. If so, we 
can rule out that sort of SMM because coreboot does not use SMM yet.

Regards,
Carl-Daniel

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




From info at coresystems.de  Sat Mar  1 17:29:50 2008
From: info at coresystems.de (coreboot information)
Date: Sat, 01 Mar 2008 17:29:50 +0100
Subject: [coreboot] r3120 build service
Message-ID: <E1JVUas-0006Df-21@khepri.openbios.org>

Dear coreboot readers!

This is the automated build check service of coreboot.

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

Change Log:
Create a genacpi directory below util/ which will hold all acpi related
code/data generation utilities.

Signed-off-by: Corey Osgood <corey.osgood at gmail.com>
Acked-by: Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006 at gmx.net>


Build Log:
Compilation of amd:serengeti_cheetah_fam10 is still broken
See the error log at http://qa.coreboot.org/log_buildbrd.php?revision=3120&device=serengeti_cheetah_fam10&vendor=amd


If something broke during this checkin please be a pain 
in hailfinger'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 rminnich at gmail.com  Sat Mar  1 17:39:13 2008
From: rminnich at gmail.com (ron minnich)
Date: Sat, 1 Mar 2008 08:39:13 -0800
Subject: [coreboot] Probe missing on W49F002U
In-Reply-To: <dcf6addc0802292359q47871439i7d9bf80bb85474cd@mail.gmail.com>
References: <dcf6addc0802292359q47871439i7d9bf80bb85474cd@mail.gmail.com>
Message-ID: <13426df10803010839i2254601ag75df6e764eaf3544@mail.gmail.com>

There is almost certainly an additional write control line on this
board, and you will have to find it.

It's not too hard to do, let us know if you would like to try.

ron



From rminnich at gmail.com  Sat Mar  1 18:08:25 2008
From: rminnich at gmail.com (ron minnich)
Date: Sat, 1 Mar 2008 09:08:25 -0800
Subject: [coreboot] patch: dbe62
In-Reply-To: <20080301152721.25943.qmail@stuge.se>
References: <13426df10802281441v109c6edai8e448131a0539c93@mail.gmail.com>
	<20080229010002.9912.qmail@stuge.se>
	<13426df10802281853q27757ab3mac567ab8c574412@mail.gmail.com>
	<20080229134132.2184.qmail@stuge.se>
	<13426df10802290852h109ab986o89a83f689a14148b@mail.gmail.com>
	<47C8B860.5030700@gmx.net>
	<13426df10802291803y2b042304pfa78ce2e2900dfa1@mail.gmail.com>
	<47C9734E.1010807@gmx.net> <20080301152721.25943.qmail@stuge.se>
Message-ID: <13426df10803010908s6a866eb0jcdaf90135d6579b6@mail.gmail.com>

It looks great but don't commit until I or someone else tests on hardware.

thanks

ron



From joe at smittys.pointclark.net  Sat Mar  1 18:34:04 2008
From: joe at smittys.pointclark.net (joe at smittys.pointclark.net)
Date: Sat, 01 Mar 2008 12:34:04 -0500
Subject: [coreboot] flashrom issues??
In-Reply-To: <47C978F4.4030904@gmx.net>
References: <20080216134533.6awmn90xcsww80c4@www.smittys.pointclark.net>
	<20080219112943.6w24vj5rc0okkc4s@www.smittys.pointclark.net>
	<20080219163507.GA21962@coresystems.de>
	<20080229123601.4dnjxissn40c4gw8@www.smittys.pointclark.net>
	<20080229190715.GA10976@coresystems.de> <47C8593F.1030607@gmx.net>
	<20080229192145.GA15773@coresystems.de> <47C89FC3.3000207@gmx.net>
	<20080301080454.x1rgbpahwwks4k8c@www.smittys.pointclark.net>
	<47C978F4.4030904@gmx.net>
Message-ID: <20080301123404.lsocj753k88k08k4@www.smittys.pointclark.net>

>> To check this with superiotool I have to be able to dump the   
>> "Runtime Registers", this is where the GPIO's are (See the SMSC   
>> lpc47m192 datasheet for more info). Currently superiotool does not   
>> dump these registers so modifications will be required.
>
> I was relying on the new extended superiotool dumping functionality.
> That doesn't exist yet for your superio, so I should have written
> "...can find out with superiotool (once that has GPIO dumping support
> for your superio) and...". Thanks for correcting me.
>
I am working on this right now.....

Thanks - Joe



From joe at smittys.pointclark.net  Sat Mar  1 18:38:06 2008
From: joe at smittys.pointclark.net (joe at smittys.pointclark.net)
Date: Sat, 01 Mar 2008 12:38:06 -0500
Subject: [coreboot] IDE cable select question
In-Reply-To: <20080301101213.rsxwai4asg84s4s8@www.smittys.pointclark.net>
References: <20080222111554.ffirg0lfb40ookg8@www.smittys.pointclark.net>
	<13426df10802220858x6601ce57yc2246e579c8ce426@mail.gmail.com>
	<20080222121511.8i2h9rkyyokwwkws@www.smittys.pointclark.net>
	<13426df10802220958v39aa13e0v928d5c231e18da1f@mail.gmail.com>
	<20080222131325.hfnef0552coocokw@www.smittys.pointclark.net>
	<20080222150303.4dlfqz83s40w4cg0@www.smittys.pointclark.net>
	<47BF2F5C.5070109@gmx.net>
	<20080222155354.vwphwy7zk04gs4sw@www.smittys.pointclark.net>
	<20080301101213.rsxwai4asg84s4s8@www.smittys.pointclark.net>
Message-ID: <20080301123806.lozv181mow8o8koc@www.smittys.pointclark.net>

> Well,
> Much to my suprise it looks like pin 34 of the IDE connetor does not
> assert a signal if the cable is 40
**Correction** conductors
> and does assert a signal if the
> cable is 80
**Correction** conductors
> . This is a standard for all motherboards that support
> ATA66/ATA100. Now I just have to figure out where this signal is
> asserted too (maybe a GPIO -> in). Once I figure that out this will be
> easy. I can just tell coreboot to: read ide cable signal, set ide
> cable select register bit to 1.



Thanks - Joe



From svn at coreboot.org  Sat Mar  1 19:49:39 2008
From: svn at coreboot.org (svn at coreboot.org)
Date: Sat,  1 Mar 2008 19:49:39 +0100
Subject: [coreboot] r3121 - trunk/util/superiotool
Message-ID: <mailman.1238.1355071270.16123.coreboot@coreboot.org>

Author: uwe
Date: 2008-03-01 19:49:39 +0100 (Sat, 01 Mar 2008)
New Revision: 3121

Modified:
   trunk/util/superiotool/README
   trunk/util/superiotool/ite.c
   trunk/util/superiotool/superiotool.8
   trunk/util/superiotool/superiotool.c
   trunk/util/superiotool/superiotool.h
Log:
Small coding style fixes and documentation updates (trivial).

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



Modified: trunk/util/superiotool/README
===================================================================
--- trunk/util/superiotool/README	2008-03-01 15:33:03 UTC (rev 3120)
+++ trunk/util/superiotool/README	2008-03-01 18:49:39 UTC (rev 3121)
@@ -30,10 +30,10 @@
 Usage
 -----
 
- $ superiotool [-d] [-l] [-V] [-v] [-h]
+ $ superiotool [-d] [-e] [-l] [-V] [-v] [-h]
 
  -d | --dump            Dump Super I/O register contents
- -e | --extra-dump      Dump Secondary registers too (like EC registers etc.)
+ -e | --extra-dump      Dump secondary registers too (e.g. EC registers)
  -l | --list-supported  Show the list of supported Super I/O chips
  -V | --verbose         Verbose mode
  -v | --version         Show the superiotool version

Modified: trunk/util/superiotool/ite.c
===================================================================
--- trunk/util/superiotool/ite.c	2008-03-01 15:33:03 UTC (rev 3120)
+++ trunk/util/superiotool/ite.c	2008-03-01 18:49:39 UTC (rev 3121)
@@ -379,7 +379,7 @@
 
 static void probe_idregs_ite_helper(const char *init, uint16_t port)
 {
-	uint16_t id, chipver;
+	uint16_t id, chipver, ecport;
 
 	probing_for("ITE", init, port);
 
@@ -400,13 +400,16 @@
 	dump_superio("ITE", reg_table, port, id);
 
 	if (extra_dump) {
-		uint16_t ecport;
-		regwrite(port, 0x07, 0x04); /*EC LDN*/
+		regwrite(port, 0x07, 0x04); /* Select LDN 4 (EC). */
+
+		/* Get EC base address (stored in LDN 4, index 0x60/0x61). */
 		ecport = regval(port, 0x60) << 8;
 		ecport |= regval(port, 0x61);
+
+		/* EC address register = EC base address + 5. */
 		ecport += 5;
 
-		printf("Environment Controller (0x%04x)\n",ecport);
+		printf("Environment controller (0x%04x)\n", ecport);
 		dump_superio("ITE-EC", ec_table, ecport, id);
 	}
 }

Modified: trunk/util/superiotool/superiotool.8
===================================================================
--- trunk/util/superiotool/superiotool.8	2008-03-01 15:33:03 UTC (rev 3120)
+++ trunk/util/superiotool/superiotool.8	2008-03-01 18:49:39 UTC (rev 3121)
@@ -77,8 +77,8 @@
 Dump extra secondary register contents too, if available. Only in combination
 with the
 .B --dump
-option. This option will, for instance, dump the Environmental Controller
-configuration registers for the ITE IT8716f chip. The format is similar to
+option. This option will, for instance, dump the environmental controller (EC)
+configuration registers for the ITE IT8716F chip. The format is similar to
 the output of the
 .B --dump
 option.

Modified: trunk/util/superiotool/superiotool.c
===================================================================
--- trunk/util/superiotool/superiotool.c	2008-03-01 15:33:03 UTC (rev 3120)
+++ trunk/util/superiotool/superiotool.c	2008-03-01 18:49:39 UTC (rev 3121)
@@ -158,8 +158,7 @@
 		return;
 
 	/* Yes, there's no space between '%s' and 'at'! */
-	printf("Probing for %s Super I/O %sat 0x%x...\n",
-	       vendor, info, port);
+	printf("Probing for %s Super I/O %sat 0x%x...\n", vendor, info, port);
 }
 
 /** Print a list of all supported chips from the given vendor. */

Modified: trunk/util/superiotool/superiotool.h
===================================================================
--- trunk/util/superiotool/superiotool.h	2008-03-01 15:33:03 UTC (rev 3120)
+++ trunk/util/superiotool/superiotool.h	2008-03-01 18:49:39 UTC (rev 3121)
@@ -30,9 +30,9 @@
 #include <getopt.h>
 #include <sys/io.h>
 
-#define USAGE "Usage: superiotool [-d] [-l] [-V] [-v] [-h]\n\n\
+#define USAGE "Usage: superiotool [-d] [-e] [-l] [-V] [-v] [-h]\n\n\
   -d | --dump            Dump Super I/O register contents\n\
-  -e | --extra-dump      Dump Secondary registers too (like EC registers etc.)\n\
+  -e | --extra-dump      Dump secondary registers too (e.g. EC registers)\n\
   -l | --list-supported  Show the list of supported Super I/O chips\n\
   -V | --verbose         Verbose mode\n\
   -v | --version         Show the superiotool version\n\




From c-d.hailfinger.devel.2006 at gmx.net  Sat Mar  1 19:52:19 2008
From: c-d.hailfinger.devel.2006 at gmx.net (Carl-Daniel Hailfinger)
Date: Sat, 01 Mar 2008 19:52:19 +0100
Subject: [coreboot] v3: missing dependencies
Message-ID: <47C9A5E3.3090304@gmx.net>

I finally found out why building one target, running menuconfig to 
change the target and recompiling fails unless you make clean in between:
statictree.c and statictree.h are missing dependencies on .config or its 
derivatives. Ouch. That's not totally bad for statictree.c because it 
sits next to the dts, but for statictree.h.
So if you configure for qemu, compile, reconfigure for alix1c, compile 
again, make thinks statictree.h is not stale because it is newer than 
the alix1c dts. Boom.

Two possible fixes:
- move statictree.h to the mainboard dir next to statictree.c.
- have statictree.h depend on .config or derivatives.

I like the first option a lot better.

Opinions?

Regards,
Carl-Daniel

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




From svn at coreboot.org  Sat Mar  1 20:06:33 2008
From: svn at coreboot.org (svn at coreboot.org)
Date: Sat,  1 Mar 2008 20:06:33 +0100
Subject: [coreboot] r3122 - trunk/util/lxbios
Message-ID: <mailman.1239.1355071270.16123.coreboot@coreboot.org>

Author: uwe
Date: 2008-03-01 20:06:32 +0100 (Sat, 01 Mar 2008)
New Revision: 3122

Modified:
   trunk/util/lxbios/DISCLAIMER
   trunk/util/lxbios/Makefile
   trunk/util/lxbios/README
   trunk/util/lxbios/cmos_lowlevel.c
   trunk/util/lxbios/cmos_lowlevel.h
   trunk/util/lxbios/cmos_ops.c
   trunk/util/lxbios/cmos_ops.h
   trunk/util/lxbios/common.c
   trunk/util/lxbios/common.h
   trunk/util/lxbios/input_file.c
   trunk/util/lxbios/input_file.h
   trunk/util/lxbios/layout.c
   trunk/util/lxbios/layout.h
   trunk/util/lxbios/layout_file.c
   trunk/util/lxbios/layout_file.h
   trunk/util/lxbios/lbtable.c
   trunk/util/lxbios/lbtable.h
   trunk/util/lxbios/lxbios.1
   trunk/util/lxbios/lxbios.c
   trunk/util/lxbios/lxbios.spec
   trunk/util/lxbios/opts.c
   trunk/util/lxbios/opts.h
   trunk/util/lxbios/reg_expr.c
   trunk/util/lxbios/reg_expr.h
Log:
Rename lxbios to nvramtool.

This is step 1 in a three-step commit:

 1. Apply patch, commit.

 2. Rename some files:
    $ svn mv lxbios.c nvramtool.c
    $ svn mv lxbios.1 nvramtool.c
    $ svn mv lxbios.spec nvramtool.spec
    $ svn ci

 3. Rename lxbios directory:
    $ svn mv lxbios/ nvramtool/
    $ svn ci

Signed-off-by: Uwe Hermann <uwe at hermann-uwe.de>
Acked-by: Stefan Reinauer <stepan at coresystems.de>



Modified: trunk/util/lxbios/DISCLAIMER
===================================================================
--- trunk/util/lxbios/DISCLAIMER	2008-03-01 18:49:39 UTC (rev 3121)
+++ trunk/util/lxbios/DISCLAIMER	2008-03-01 19:06:32 UTC (rev 3122)
@@ -8,9 +8,9 @@
 UCRL-CODE-2003-012
 All rights reserved.
 
-This file is part of lxbios, a utility for reading/writing coreboot
+This file is part of nvramtool, a utility for reading/writing coreboot
 parameters and displaying information from the coreboot table.
-For details, see http://coreboot.org/Lxbios.
+For details, see http://coreboot.org/nvramtool.
 
 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

Modified: trunk/util/lxbios/Makefile
===================================================================
--- trunk/util/lxbios/Makefile	2008-03-01 18:49:39 UTC (rev 3121)
+++ trunk/util/lxbios/Makefile	2008-03-01 19:06:32 UTC (rev 3122)
@@ -1,28 +1,28 @@
 # $Id$
 
-PROJECT = lxbios
+PROJECT = nvramtool
 CC = gcc
 CFLAGS = -O2 -W -Wall
 LDFLAGS =
 OBJS = common.o compute_ip_checksum.o hexdump.o cmos_lowlevel.o \
        reg_expr.o layout.o layout_file.o lbtable.o cmos_ops.o input_file.o \
-       opts.o lxbios.o
+       opts.o nvramtool.o
 HEADERS = common.h ip_checksum.h coreboot_tables.h hexdump.h \
           cmos_lowlevel.h reg_expr.h layout.h layout_file.h lbtable.h \
           cmos_ops.h input_file.h opts.h
 
-all: lxbios man
+all: nvramtool man
 
-lxbios: $(OBJS)
+nvramtool: $(OBJS)
 	$(CC) $(LDFLAGS) -o $@ $(OBJS)
 
-man: lxbios.1.gz
+man: nvramtool.1.gz
 
 $(OBJS): $(HEADERS)
 
-lxbios.1.gz: lxbios.1
-	gzip -c --best lxbios.1 > lxbios.1.gz
+nvramtool.1.gz: nvramtool.1
+	gzip -c --best nvramtool.1 > nvramtool.1.gz
 
 clean:
-	rm -f *.o lxbios lxbios.1.gz
+	rm -f *.o nvramtool nvramtool.1.gz
 

Modified: trunk/util/lxbios/README
===================================================================
--- trunk/util/lxbios/README	2008-03-01 18:49:39 UTC (rev 3121)
+++ trunk/util/lxbios/README	2008-03-01 19:06:32 UTC (rev 3122)
@@ -2,7 +2,7 @@
 
 Summary of Operation
 --------------------
-lxbios is a utility for reading/writing coreboot parameters and
+nvramtool is a utility for reading/writing coreboot parameters and
 displaying information from the coreboot table.  It is intended for x86-based
 systems (both 32-bit and 64-bit) that use coreboot.
 

Modified: trunk/util/lxbios/cmos_lowlevel.c
===================================================================
--- trunk/util/lxbios/cmos_lowlevel.c	2008-03-01 18:49:39 UTC (rev 3121)
+++ trunk/util/lxbios/cmos_lowlevel.c	2008-03-01 19:06:32 UTC (rev 3122)
@@ -8,9 +8,9 @@
  *  UCRL-CODE-2003-012
  *  All rights reserved.
  *
- *  This file is part of lxbios, a utility for reading/writing coreboot
+ *  This file is part of nvramtool, a utility for reading/writing coreboot
  *  parameters and displaying information from the coreboot table.
- *  For details, see http://coreboot.org/Lxbios.
+ *  For details, see http://coreboot.org/nvramtool.
  *
  *  Please also read the file DISCLAIMER which is included in this software
  *  distribution.

Modified: trunk/util/lxbios/cmos_lowlevel.h
===================================================================
--- trunk/util/lxbios/cmos_lowlevel.h	2008-03-01 18:49:39 UTC (rev 3121)
+++ trunk/util/lxbios/cmos_lowlevel.h	2008-03-01 19:06:32 UTC (rev 3122)
@@ -8,9 +8,9 @@
  *  UCRL-CODE-2003-012
  *  All rights reserved.
  *
- *  This file is part of lxbios, a utility for reading/writing coreboot
+ *  This file is part of nvramtool, a utility for reading/writing coreboot
  *  parameters and displaying information from the coreboot table.
- *  For details, see http://coreboot.org/Lxbios.
+ *  For details, see http://coreboot.org/nvramtool.
  *
  *  Please also read the file DISCLAIMER which is included in this software
  *  distribution.
@@ -29,8 +29,8 @@
  *  59 Temple Place, Suite 330, Boston, MA 02111-1307 USA.
 \*****************************************************************************/
 
-#ifndef LXBIOS_CMOS_LOWLEVEL_H
-#define LXBIOS_CMOS_LOWLEVEL_H
+#ifndef NVRAMTOOL_CMOS_LOWLEVEL_H
+#define NVRAMTOOL_CMOS_LOWLEVEL_H
 
 #include "common.h"
 
@@ -59,4 +59,4 @@
 static inline int verify_cmos_byte_index (unsigned index)
  { return (index < CMOS_RTC_AREA_SIZE) || (index >= CMOS_SIZE); }
 
-#endif  /* LXBIOS_CMOS_LOWLEVEL_H */
+#endif  /* NVRAMTOOL_CMOS_LOWLEVEL_H */

Modified: trunk/util/lxbios/cmos_ops.c
===================================================================
--- trunk/util/lxbios/cmos_ops.c	2008-03-01 18:49:39 UTC (rev 3121)
+++ trunk/util/lxbios/cmos_ops.c	2008-03-01 19:06:32 UTC (rev 3122)
@@ -8,9 +8,9 @@
  *  UCRL-CODE-2003-012
  *  All rights reserved.
  *
- *  This file is part of lxbios, a utility for reading/writing coreboot
+ *  This file is part of nvramtool, a utility for reading/writing coreboot
  *  parameters and displaying information from the coreboot table.
- *  For details, see http://coreboot.org/Lxbios.
+ *  For details, see http://coreboot.org/nvramtool.
  *
  *  Please also read the file DISCLAIMER which is included in this software
  *  distribution.

Modified: trunk/util/lxbios/cmos_ops.h
===================================================================
--- trunk/util/lxbios/cmos_ops.h	2008-03-01 18:49:39 UTC (rev 3121)
+++ trunk/util/lxbios/cmos_ops.h	2008-03-01 19:06:32 UTC (rev 3122)
@@ -8,9 +8,9 @@
  *  UCRL-CODE-2003-012
  *  All rights reserved.
  *
- *  This file is part of lxbios, a utility for reading/writing coreboot
+ *  This file is part of nvramtool, a utility for reading/writing coreboot
  *  parameters and displaying information from the coreboot table.
- *  For details, see http://coreboot.org/Lxbios.
+ *  For details, see http://coreboot.org/nvramtool.
  *
  *  Please also read the file DISCLAIMER which is included in this software
  *  distribution.
@@ -29,8 +29,8 @@
  *  59 Temple Place, Suite 330, Boston, MA 02111-1307 USA.
 \*****************************************************************************/
 
-#ifndef LXBIOS_CMOS_OPS_H
-#define LXBIOS_CMOS_OPS_H
+#ifndef CMOS_OPS_H
+#define CMOS_OPS_H
 
 #include "common.h"
 #include "layout.h"
@@ -50,4 +50,4 @@
 uint16_t cmos_checksum_compute (void);
 void cmos_checksum_verify (void);
 
-#endif  /* LXBIOS_CMOS_OPS_H */
+#endif  /* CMOS_OPS_H */

Modified: trunk/util/lxbios/common.c
===================================================================
--- trunk/util/lxbios/common.c	2008-03-01 18:49:39 UTC (rev 3121)
+++ trunk/util/lxbios/common.c	2008-03-01 19:06:32 UTC (rev 3122)
@@ -8,9 +8,9 @@
  *  UCRL-CODE-2003-012
  *  All rights reserved.
  *
- *  This file is part of lxbios, a utility for reading/writing coreboot
+ *  This file is part of nvramtool, a utility for reading/writing coreboot
  *  parameters and displaying information from the coreboot table.
- *  For details, see http://coreboot.org/Lxbios.
+ *  For details, see http://coreboot.org/nvramtool.
  *
  *  Please also read the file DISCLAIMER which is included in this software
  *  distribution.
@@ -32,7 +32,7 @@
 #include "common.h"
 
 /* basename of this program, as reported by argv[0] */
-const char prog_name[] = "lxbios";
+const char prog_name[] = "nvramtool";
 
 /* version of this program */
 const char prog_version[] = "2.0.1";

Modified: trunk/util/lxbios/common.h
===================================================================
--- trunk/util/lxbios/common.h	2008-03-01 18:49:39 UTC (rev 3121)
+++ trunk/util/lxbios/common.h	2008-03-01 19:06:32 UTC (rev 3122)
@@ -8,9 +8,9 @@
  *  UCRL-CODE-2003-012
  *  All rights reserved.
  *
- *  This file is part of lxbios, a utility for reading/writing coreboot
+ *  This file is part of nvramtool, a utility for reading/writing coreboot
  *  parameters and displaying information from the coreboot table.
- *  For details, see http://coreboot.org/Lxbios.
+ *  For details, see http://coreboot.org/nvramtool.
  *
  *  Please also read the file DISCLAIMER which is included in this software
  *  distribution.
@@ -29,8 +29,8 @@
  *  59 Temple Place, Suite 330, Boston, MA 02111-1307 USA.
 \*****************************************************************************/
 
-#ifndef LXBIOS_COMMON_H
-#define LXBIOS_COMMON_H
+#ifndef COMMON_H
+#define COMMON_H
 
 #include <sys/types.h>
 #include <sys/stat.h>
@@ -69,4 +69,4 @@
 void out_of_memory (void);
 void usage (FILE *outfile);
 
-#endif  /* LXBIOS_COMMON_H */
+#endif  /* COMMON_H */

Modified: trunk/util/lxbios/input_file.c
===================================================================
--- trunk/util/lxbios/input_file.c	2008-03-01 18:49:39 UTC (rev 3121)
+++ trunk/util/lxbios/input_file.c	2008-03-01 19:06:32 UTC (rev 3122)
@@ -8,9 +8,9 @@
  *  UCRL-CODE-2003-012
  *  All rights reserved.
  *
- *  This file is part of lxbios, a utility for reading/writing coreboot
+ *  This file is part of nvramtool, a utility for reading/writing coreboot
  *  parameters and displaying information from the coreboot table.
- *  For details, see http://coreboot.org/Lxbios.
+ *  For details, see http://coreboot.org/nvramtool.
  *
  *  Please also read the file DISCLAIMER which is included in this software
  *  distribution.

Modified: trunk/util/lxbios/input_file.h
===================================================================
--- trunk/util/lxbios/input_file.h	2008-03-01 18:49:39 UTC (rev 3121)
+++ trunk/util/lxbios/input_file.h	2008-03-01 19:06:32 UTC (rev 3122)
@@ -8,9 +8,9 @@
  *  UCRL-CODE-2003-012
  *  All rights reserved.
  *
- *  This file is part of lxbios, a utility for reading/writing coreboot
+ *  This file is part of nvramtool, a utility for reading/writing coreboot
  *  parameters and displaying information from the coreboot table.
- *  For details, see http://coreboot.org/Lxbios.
+ *  For details, see http://coreboot.org/nvramtool.
  *
  *  Please also read the file DISCLAIMER which is included in this software
  *  distribution.
@@ -29,8 +29,8 @@
  *  59 Temple Place, Suite 330, Boston, MA 02111-1307 USA.
 \*****************************************************************************/
 
-#ifndef LXBIOS_INPUT_FILE_H
-#define LXBIOS_INPUT_FILE_H
+#ifndef INPUT_FILE_H
+#define INPUT_FILE_H
 
 #include "common.h"
 
@@ -53,4 +53,4 @@
 
 extern const char assignment_regex[];
 
-#endif  /* LXBIOS_INPUT_FILE_H */
+#endif  /* INPUT_FILE_H */

Modified: trunk/util/lxbios/layout.c
===================================================================
--- trunk/util/lxbios/layout.c	2008-03-01 18:49:39 UTC (rev 3121)
+++ trunk/util/lxbios/layout.c	2008-03-01 19:06:32 UTC (rev 3122)
@@ -8,9 +8,9 @@
  *  UCRL-CODE-2003-012
  *  All rights reserved.
  *
- *  This file is part of lxbios, a utility for reading/writing coreboot
+ *  This file is part of nvramtool, a utility for reading/writing coreboot
  *  parameters and displaying information from the coreboot table.
- *  For details, see http://coreboot.org/Lxbios.
+ *  For details, see http://coreboot.org/nvramtool.
  *
  *  Please also read the file DISCLAIMER which is included in this software
  *  distribution.

Modified: trunk/util/lxbios/layout.h
===================================================================
--- trunk/util/lxbios/layout.h	2008-03-01 18:49:39 UTC (rev 3121)
+++ trunk/util/lxbios/layout.h	2008-03-01 19:06:32 UTC (rev 3122)
@@ -8,9 +8,9 @@
  *  UCRL-CODE-2003-012
  *  All rights reserved.
  *
- *  This file is part of lxbios, a utility for reading/writing coreboot
+ *  This file is part of nvramtool, a utility for reading/writing coreboot
  *  parameters and displaying information from the coreboot table.
- *  For details, see http://coreboot.org/Lxbios.
+ *  For details, see http://coreboot.org/nvramtool.
  *
  *  Please also read the file DISCLAIMER which is included in this software
  *  distribution.
@@ -29,8 +29,8 @@
  *  59 Temple Place, Suite 330, Boston, MA 02111-1307 USA.
 \*****************************************************************************/
 
-#ifndef LXBIOS_LAYOUT_H
-#define LXBIOS_LAYOUT_H
+#ifndef LAYOUT_H
+#define LAYOUT_H
 
 #include "common.h"
 #include "coreboot_tables.h"
@@ -111,4 +111,4 @@
 int checksum_layout_to_bytes (cmos_checksum_layout_t *layout);
 void checksum_layout_to_bits (cmos_checksum_layout_t *layout);
 
-#endif  /* LXBIOS_LAYOUT_H */
+#endif  /* LAYOUT_H */

Modified: trunk/util/lxbios/layout_file.c
===================================================================
--- trunk/util/lxbios/layout_file.c	2008-03-01 18:49:39 UTC (rev 3121)
+++ trunk/util/lxbios/layout_file.c	2008-03-01 19:06:32 UTC (rev 3122)
@@ -8,9 +8,9 @@
  *  UCRL-CODE-2003-012
  *  All rights reserved.
  *
- *  This file is part of lxbios, a utility for reading/writing coreboot
+ *  This file is part of nvramtool, a utility for reading/writing coreboot
  *  parameters and displaying information from the coreboot table.
- *  For details, see http://coreboot.org/Lxbios.
+ *  For details, see http://coreboot.org/nvramtool.
  *
  *  Please also read the file DISCLAIMER which is included in this software
  *  distribution.

Modified: trunk/util/lxbios/layout_file.h
===================================================================
--- trunk/util/lxbios/layout_file.h	2008-03-01 18:49:39 UTC (rev 3121)
+++ trunk/util/lxbios/layout_file.h	2008-03-01 19:06:32 UTC (rev 3122)
@@ -8,9 +8,9 @@
  *  UCRL-CODE-2003-012
  *  All rights reserved.
  *
- *  This file is part of lxbios, a utility for reading/writing coreboot
+ *  This file is part of nvramtool, a utility for reading/writing coreboot
  *  parameters and displaying information from the coreboot table.
- *  For details, see http://coreboot.org/Lxbios.
+ *  For details, see http://coreboot.org/nvramtool.
  *
  *  Please also read the file DISCLAIMER which is included in this software
  *  distribution.
@@ -29,8 +29,8 @@
  *  59 Temple Place, Suite 330, Boston, MA 02111-1307 USA.
 \*****************************************************************************/
 
-#ifndef LXBIOS_LAYOUT_FILE_H
-#define LXBIOS_LAYOUT_FILE_H
+#ifndef LAYOUT_FILE_H
+#define LAYOUT_FILE_H
 
 #include "common.h"
 #include "coreboot_tables.h"
@@ -39,4 +39,4 @@
 void get_layout_from_file (void);
 void write_cmos_layout (FILE *f);
 
-#endif  /* LXBIOS_LAYOUT_FILE_H */
+#endif  /* LAYOUT_FILE_H */

Modified: trunk/util/lxbios/lbtable.c
===================================================================
--- trunk/util/lxbios/lbtable.c	2008-03-01 18:49:39 UTC (rev 3121)
+++ trunk/util/lxbios/lbtable.c	2008-03-01 19:06:32 UTC (rev 3122)
@@ -9,9 +9,9 @@
  *  UCRL-CODE-2003-012
  *  All rights reserved.
  *
- *  This file is part of lxbios, a utility for reading/writing coreboot
+ *  This file is part of nvramtool, a utility for reading/writing coreboot
  *  parameters and displaying information from the coreboot table.
- *  For details, see http://coreboot.org/Lxbios.
+ *  For details, see http://coreboot.org/nvramtool.
  *
  *  Please also read the file DISCLAIMER which is included in this software
  *  distribution.

Modified: trunk/util/lxbios/lbtable.h
===================================================================
--- trunk/util/lxbios/lbtable.h	2008-03-01 18:49:39 UTC (rev 3121)
+++ trunk/util/lxbios/lbtable.h	2008-03-01 19:06:32 UTC (rev 3122)
@@ -8,9 +8,9 @@
  *  UCRL-CODE-2003-012
  *  All rights reserved.
  *
- *  This file is part of lxbios, a utility for reading/writing coreboot
+ *  This file is part of nvramtool, a utility for reading/writing coreboot
  *  parameters and displaying information from the coreboot table.
- *  For details, see http://coreboot.org/Lxbios.
+ *  For details, see http://coreboot.org/nvramtool.
  *
  *  Please also read the file DISCLAIMER which is included in this software
  *  distribution.
@@ -29,8 +29,8 @@
  *  59 Temple Place, Suite 330, Boston, MA 02111-1307 USA.
 \*****************************************************************************/
 
-#ifndef LXBIOS_LBTABLE_H
-#define LXBIOS_LBTABLE_H
+#ifndef LBTABLE_H
+#define LBTABLE_H
 
 #include "common.h"
 
@@ -40,4 +40,4 @@
 void list_lbtable_choices (void);
 void list_lbtable_item (const char item[]);
 
-#endif  /* LXBIOS_LBTABLE_H */
+#endif  /* LBTABLE_H */

Modified: trunk/util/lxbios/lxbios.1
===================================================================
--- trunk/util/lxbios/lxbios.1	2008-03-01 18:49:39 UTC (rev 3121)
+++ trunk/util/lxbios/lxbios.1	2008-03-01 19:06:32 UTC (rev 3122)
@@ -1,5 +1,5 @@
 .\"***************************************************************************\
-.\" lxbios.1
+.\" nvramtool.1
 .\" $Id$
 .\"***************************************************************************
 .\"  Copyright (C) 2002, 2003 The Regents of the University of California.
@@ -8,9 +8,9 @@
 .\"  UCRL-CODE-2003-012
 .\"  All rights reserved.
 .\"
-.\"  This file is part of lxbios, a utility for reading/writing coreboot
+.\"  This file is part of nvramtool, a utility for reading/writing coreboot
 .\"  parameters and displaying information from the coreboot table.
-.\"  For details, see http://coreboot.org/Lxbios.
+.\"  For details, see http://coreboot.org/nvramtool.
 .\"
 .\"  Please also read the file DISCLAIMER which is included in this software
 .\"  distribution.
@@ -28,43 +28,43 @@
 .\"  with this program; if not, write to the Free Software Foundation, Inc.,
 .\"  59 Temple Place, Suite 330, Boston, MA 02111-1307 USA.
 .\"***************************************************************************/
-.TH LXBIOS 1 "January 2008" Linux
+.TH NVRAMTOOL 1 "January 2008" Linux
 .SH NAME
-lxbios \- read/write coreboot-related information
+nvramtool \- read/write coreboot-related information
 .SH SYNOPSIS
-.B "lxbios [OPTS] [-n] -r NAME"
+.B "nvramtool [OPTS] [-n] -r NAME"
 .br
-.B "lxbios [OPTS] -e NAME"
+.B "nvramtool [OPTS] -e NAME"
 .br
-.B "lxbios [OPTS] -a"
+.B "nvramtool [OPTS] -a"
 .br
-.B "lxbios [OPTS] -w NAME=VALUE"
+.B "nvramtool [OPTS] -w NAME=VALUE"
 .br
-.B "lxbios [OPTS] -p INPUT_FILE"
+.B "nvramtool [OPTS] -p INPUT_FILE"
 .br
-.B "lxbios [OPTS] -i"
+.B "nvramtool [OPTS] -i"
 .br
-.B "lxbios [OPTS] -c [VALUE]"
+.B "nvramtool [OPTS] -c [VALUE]"
 .br
-.B "lxbios [OPTS] -l [ARG]"
+.B "nvramtool [OPTS] -l [ARG]"
 .br
-.B "lxbios [OPTS] -d"
+.B "nvramtool [OPTS] -d"
 .br
-.B "lxbios [OPTS] -Y"
+.B "nvramtool [OPTS] -Y"
 .br
-.B "lxbios [OPTS] -b OUTPUT_FILE"
+.B "nvramtool [OPTS] -b OUTPUT_FILE"
 .br
-.B "lxbios [OPTS] -B INPUT_FILE"
+.B "nvramtool [OPTS] -B INPUT_FILE"
 .br
-.B "lxbios [OPTS] -x"
+.B "nvramtool [OPTS] -x"
 .br
-.B "lxbios [OPTS] -X DUMPFILE"
+.B "nvramtool [OPTS] -X DUMPFILE"
 .br
-.B "lxbios [OPTS] -v"
+.B "nvramtool [OPTS] -v"
 .br
-.B "lxbios [OPTS] -h"
+.B "nvramtool [OPTS] -h"
 .SH DESCRIPTION
-.B "lxbios"
+.B "nvramtool"
 is a utility for reading/writing coreboot parameters and displaying
 information from the coreboot table.
 
@@ -180,11 +180,11 @@
 
 The
 .B "'-y LAYOUT_FILE'"
-option tells lxbios to obtain CMOS layout information from the contents of
+option tells nvramtool to obtain CMOS layout information from the contents of
 .B "LAYOUT_FILE."
 Likewise, the
 .B "'-t'"
-option tells lxbios to obtain CMOS layout information from the CMOS option
+option tells nvramtool to obtain CMOS layout information from the CMOS option
 table (contained within the coreboot table).  If neither option is
 specified, the CMOS option table is used by default.
 .B "LAYOUT_FILE"

Modified: trunk/util/lxbios/lxbios.c
===================================================================
--- trunk/util/lxbios/lxbios.c	2008-03-01 18:49:39 UTC (rev 3121)
+++ trunk/util/lxbios/lxbios.c	2008-03-01 19:06:32 UTC (rev 3122)
@@ -1,5 +1,5 @@
 /*****************************************************************************\
- * lxbios.c
+ * nvramtool.c
  * $Id$
  *****************************************************************************
  *  Copyright (C) 2002-2005 The Regents of the University of California.
@@ -8,9 +8,9 @@
  *  UCRL-CODE-2003-012
  *  All rights reserved.
  *
- *  This file is part of lxbios, a utility for reading/writing coreboot
+ *  This file is part of nvramtool, a utility for reading/writing coreboot
  *  parameters and displaying information from the coreboot table.
- *  For details, see http://coreboot.org/Lxbios.
+ *  For details, see http://coreboot.org/nvramtool.
  *
  *  Please also read the file DISCLAIMER which is included in this software
  *  distribution.
@@ -96,18 +96,18 @@
 int main (int argc, char *argv[])
  { cmos_layout_get_fn_t fn;
 
-   parse_lxbios_args(argc, argv);
+   parse_nvramtool_args(argc, argv);
 
-   if (lxbios_op_modifiers[LXBIOS_MOD_USE_CMOS_LAYOUT_FILE].found)
+   if (nvramtool_op_modifiers[NVRAMTOOL_MOD_USE_CMOS_LAYOUT_FILE].found)
     { set_layout_filename(
-            lxbios_op_modifiers[LXBIOS_MOD_USE_CMOS_LAYOUT_FILE].param);
+            nvramtool_op_modifiers[NVRAMTOOL_MOD_USE_CMOS_LAYOUT_FILE].param);
       fn = get_layout_from_file;
     }
    else
       fn = get_layout_from_cmos_table;
 
    register_cmos_layout_get_fn(fn);
-   op_fns[lxbios_op.op]();
+   op_fns[nvramtool_op.op]();
    return 0;
  }
 
@@ -140,11 +140,11 @@
  * Else show all possible values for ARG.
  ****************************************************************************/
 static void op_lbtable_show_info (void)
- { if (lxbios_op.param == NULL)
+ { if (nvramtool_op.param == NULL)
       list_lbtable_choices();
    else
     { get_lbtable();
-      list_lbtable_item(lxbios_op.param);
+      list_lbtable_item(nvramtool_op.param);
     }
  }
 
@@ -169,7 +169,7 @@
  ****************************************************************************/
 static void op_show_param_values (void)
  { get_cmos_layout();
-   list_param_enums(lxbios_op.param);
+   list_param_enums(nvramtool_op.param);
  }
 
 /****************************************************************************
@@ -184,8 +184,8 @@
  { int result;
 
    get_cmos_layout();
-   result = list_one_param(lxbios_op.param,
-                  !lxbios_op_modifiers[LXBIOS_MOD_SHOW_VALUE_ONLY].found);
+   result = list_one_param(nvramtool_op.param,
+                  !nvramtool_op_modifiers[NVRAMTOOL_MOD_SHOW_VALUE_ONLY].found);
    cmos_checksum_verify();
 
    if (result)
@@ -225,7 +225,7 @@
    /* Separate 'NAME=VALUE' syntax into two strings representing NAME and
     * VALUE.
     */
-   parse_assignment(lxbios_op.param, &name, &value);
+   parse_assignment(nvramtool_op.param, &name, &value);
 
    set_one_param(name, value);
  }
@@ -252,9 +252,9 @@
 static void op_cmos_set_params_file (void)
  { FILE *f;
 
-   if ((f = fopen(lxbios_op.param, "r")) == NULL)
+   if ((f = fopen(nvramtool_op.param, "r")) == NULL)
     { fprintf(stderr, "%s: Can not open file %s for reading: %s\n",
-              prog_name, lxbios_op.param, strerror(errno));
+              prog_name, nvramtool_op.param, strerror(errno));
       exit(1);
     }
 
@@ -276,14 +276,14 @@
 
    get_cmos_layout();
 
-   if (lxbios_op.param == NULL)
+   if (nvramtool_op.param == NULL)
     { set_iopl(3);
       checksum = cmos_checksum_read();
       set_iopl(0);
       printf("0x%x\n", checksum);
     }
    else
-    { checksum = convert_checksum_value(lxbios_op.param);
+    { checksum = convert_checksum_value(nvramtool_op.param);
       set_iopl(3);
       cmos_checksum_write(checksum);
       set_iopl(0);
@@ -313,9 +313,9 @@
  { unsigned char data[CMOS_SIZE];
    FILE *f;
 
-   if ((f = fopen(lxbios_op.param, "w")) == NULL)
+   if ((f = fopen(nvramtool_op.param, "w")) == NULL)
     { fprintf(stderr, "%s: Can not open file %s for writing: %s\n",
-              prog_name, lxbios_op.param, strerror(errno));
+              prog_name, nvramtool_op.param, strerror(errno));
       exit(1);
     }
 
@@ -325,7 +325,7 @@
 
    if (fwrite(data, 1, CMOS_SIZE, f) != CMOS_SIZE)
     { fprintf(stderr, "%s: Error writing CMOS data to file %s: %s\n",
-              prog_name, lxbios_op.param, strerror(errno));
+              prog_name, nvramtool_op.param, strerror(errno));
       exit(1);
     }
 
@@ -344,16 +344,16 @@
    size_t nr_bytes;
    FILE *f;
 
-   if ((f = fopen(lxbios_op.param, "r")) == NULL)
+   if ((f = fopen(nvramtool_op.param, "r")) == NULL)
     { fprintf(stderr, "%s: Can not open file %s for reading: %s\n",
-              prog_name, lxbios_op.param, strerror(errno));
+              prog_name, nvramtool_op.param, strerror(errno));
       exit(1);
     }
 
    if ((nr_bytes = fread(data, 1, CMOS_SIZE, f)) != CMOS_SIZE)
     { fprintf(stderr, "%s: Error: Only able to read %d bytes of CMOS data "
               "from file %s.  CMOS data is unchanged.\n", prog_name,
-              (int) nr_bytes, lxbios_op.param);
+              (int) nr_bytes, nvramtool_op.param);
       exit(1);
     }
 
@@ -392,9 +392,9 @@
    size_t nr_bytes;
    FILE *f;
 
-   if ((f = fopen(lxbios_op.param, "r")) == NULL)
+   if ((f = fopen(nvramtool_op.param, "r")) == NULL)
     { fprintf(stderr, "%s: Can not open file %s for reading: %s\n",
-              prog_name, lxbios_op.param, strerror(errno));
+              prog_name, nvramtool_op.param, strerror(errno));
       exit(1);
     }
 

Modified: trunk/util/lxbios/lxbios.spec
===================================================================
--- trunk/util/lxbios/lxbios.spec	2008-03-01 18:49:39 UTC (rev 3121)
+++ trunk/util/lxbios/lxbios.spec	2008-03-01 19:06:32 UTC (rev 3122)
@@ -2,21 +2,21 @@
 # $Id$
 ##
 
-Name:    lxbios
+Name:    nvramtool
 Version: 2.0.1
 Release: 0
 
 Summary: coreboot utility program
 Group:   System Environment/Base
 License: GPL
-Provides: lxbios
+Provides: nvramtool
 
 BuildRoot: %{_tmppath}/%{name}-%{version}
 
 Source0: %{name}-%{version}.tgz
 
 %description
-lxbios is a utility for reading/writing coreboot parameters and displaying
+nvramtool is a utility for reading/writing coreboot parameters and displaying
 information from the coreboot table.
 
 At boot time, coreboot places a table (known as the coreboot table) in low
@@ -36,8 +36,8 @@
 rm -rf "$RPM_BUILD_ROOT"
 mkdir -p "$RPM_BUILD_ROOT/usr/bin"
 mkdir -p "$RPM_BUILD_ROOT/usr/man/man1"
-cp lxbios "$RPM_BUILD_ROOT/usr/bin"
-cp lxbios.1.gz $RPM_BUILD_ROOT/usr/man/man1
+cp nvramtool "$RPM_BUILD_ROOT/usr/bin"
+cp nvramtool.1.gz $RPM_BUILD_ROOT/usr/man/man1
 
 %clean
 rm -rf "$RPM_BUILD_ROOT"
@@ -46,5 +46,5 @@
 %defattr(-,root,root,0755)
 %doc ChangeLog README
 %doc README
-/usr/bin/lxbios
-/usr/man/man1/lxbios.1.gz
+/usr/bin/nvramtool
+/usr/man/man1/nvramtool.1.gz

Modified: trunk/util/lxbios/opts.c
===================================================================
--- trunk/util/lxbios/opts.c	2008-03-01 18:49:39 UTC (rev 3121)
+++ trunk/util/lxbios/opts.c	2008-03-01 19:06:32 UTC (rev 3122)
@@ -8,9 +8,9 @@
  *  UCRL-CODE-2003-012
  *  All rights reserved.
  *
- *  This file is part of lxbios, a utility for reading/writing coreboot
+ *  This file is part of nvramtool, a utility for reading/writing coreboot
  *  parameters and displaying information from the coreboot table.
- *  For details, see http://coreboot.org/Lxbios.
+ *  For details, see http://coreboot.org/nvramtool.
  *
  *  Please also read the file DISCLAIMER which is included in this software
  *  distribution.
@@ -32,30 +32,30 @@
 #include "common.h"
 #include "opts.h"
 
-lxbios_op_info_t lxbios_op;
+nvramtool_op_info_t nvramtool_op;
 
-lxbios_op_modifier_info_t lxbios_op_modifiers[LXBIOS_NUM_OP_MODIFIERS];
+nvramtool_op_modifier_info_t nvramtool_op_modifiers[NVRAMTOOL_NUM_OP_MODIFIERS];
 
 static char * handle_optional_arg (int argc, char *argv[]);
-static void register_op (int *op_found, lxbios_op_t op, char op_param[]);
-static void register_op_modifier (lxbios_op_modifier_t mod, char mod_param[]);
+static void register_op (int *op_found, nvramtool_op_t op, char op_param[]);
+static void register_op_modifier (nvramtool_op_modifier_t mod, char mod_param[]);
 static void resolve_op_modifiers (void);
 static void sanity_check_args (void);
 
 static const char getopt_string[] = "-ab:B:c::de:hil::np:r:tvw:xX:y:Y";
 
 /****************************************************************************
- * parse_lxbios_args
+ * parse_nvramtool_args
  *
  * Parse command line arguments.
  ****************************************************************************/
-void parse_lxbios_args (int argc, char *argv[])
- { lxbios_op_modifier_info_t *mod_info;
+void parse_nvramtool_args (int argc, char *argv[])
+ { nvramtool_op_modifier_info_t *mod_info;
    int i, op_found;
    char c;
 
-   for (i = 0, mod_info = lxbios_op_modifiers;
-        i < LXBIOS_NUM_OP_MODIFIERS;
+   for (i = 0, mod_info = nvramtool_op_modifiers;
+        i < NVRAMTOOL_NUM_OP_MODIFIERS;
         i++, mod_info++)
     { mod_info->found = FALSE;
       mod_info->found_seq = 0;
@@ -68,63 +68,63 @@
    do
     { switch (c = getopt(argc, argv, getopt_string))
        { case 'a':
-            register_op(&op_found, LXBIOS_OP_CMOS_SHOW_ALL_PARAMS, NULL);
+            register_op(&op_found, NVRAMTOOL_OP_CMOS_SHOW_ALL_PARAMS, NULL);
             break;
          case 'b':
-            register_op(&op_found, LXBIOS_OP_WRITE_CMOS_DUMP, optarg);
+            register_op(&op_found, NVRAMTOOL_OP_WRITE_CMOS_DUMP, optarg);
             break;
          case 'B':
-            register_op(&op_found, LXBIOS_OP_READ_CMOS_DUMP, optarg);
+            register_op(&op_found, NVRAMTOOL_OP_READ_CMOS_DUMP, optarg);
             break;
          case 'c':
-            register_op(&op_found, LXBIOS_OP_CMOS_CHECKSUM,
+            register_op(&op_found, NVRAMTOOL_OP_CMOS_CHECKSUM,
                         handle_optional_arg(argc, argv));
             break;
          case 'd':
-            register_op(&op_found, LXBIOS_OP_LBTABLE_DUMP, NULL);
+            register_op(&op_found, NVRAMTOOL_OP_LBTABLE_DUMP, NULL);
             break;
          case 'e':
-            register_op(&op_found, LXBIOS_OP_SHOW_PARAM_VALUES, optarg);
+            register_op(&op_found, NVRAMTOOL_OP_SHOW_PARAM_VALUES, optarg);
             break;
          case 'h':
-            register_op(&op_found, LXBIOS_OP_SHOW_USAGE, NULL);
+            register_op(&op_found, NVRAMTOOL_OP_SHOW_USAGE, NULL);
             break;
          case 'i':
-            register_op(&op_found, LXBIOS_OP_CMOS_SET_PARAMS_STDIN, NULL);
+            register_op(&op_found, NVRAMTOOL_OP_CMOS_SET_PARAMS_STDIN, NULL);
             break;
          case 'l':
-            register_op(&op_found, LXBIOS_OP_LBTABLE_SHOW_INFO,
+            register_op(&op_found, NVRAMTOOL_OP_LBTABLE_SHOW_INFO,
                         handle_optional_arg(argc, argv));
             break;
          case 'n':
-            register_op_modifier(LXBIOS_MOD_SHOW_VALUE_ONLY, NULL);
+            register_op_modifier(NVRAMTOOL_MOD_SHOW_VALUE_ONLY, NULL);
             break;
          case 'p':
-            register_op(&op_found, LXBIOS_OP_CMOS_SET_PARAMS_FILE, optarg);
+            register_op(&op_found, NVRAMTOOL_OP_CMOS_SET_PARAMS_FILE, optarg);
             break;
          case 'r':
-            register_op(&op_found, LXBIOS_OP_CMOS_SHOW_ONE_PARAM, optarg);
+            register_op(&op_found, NVRAMTOOL_OP_CMOS_SHOW_ONE_PARAM, optarg);
             break;
          case 't':
-            register_op_modifier(LXBIOS_MOD_USE_CMOS_OPT_TABLE, NULL);
+            register_op_modifier(NVRAMTOOL_MOD_USE_CMOS_OPT_TABLE, NULL);
             break;
          case 'v':
-            register_op(&op_found, LXBIOS_OP_SHOW_VERSION, NULL);
+            register_op(&op_found, NVRAMTOOL_OP_SHOW_VERSION, NULL);
             break;
          case 'w':
-            register_op(&op_found, LXBIOS_OP_CMOS_SET_ONE_PARAM, optarg);
+            register_op(&op_found, NVRAMTOOL_OP_CMOS_SET_ONE_PARAM, optarg);
             break;
          case 'x':
-            register_op(&op_found, LXBIOS_OP_SHOW_CMOS_HEX_DUMP, NULL);
+            register_op(&op_found, NVRAMTOOL_OP_SHOW_CMOS_HEX_DUMP, NULL);
             break;
          case 'X':
-            register_op(&op_found, LXBIOS_OP_SHOW_CMOS_DUMPFILE, optarg);
+            register_op(&op_found, NVRAMTOOL_OP_SHOW_CMOS_DUMPFILE, optarg);
             break;
          case 'y':
-            register_op_modifier(LXBIOS_MOD_USE_CMOS_LAYOUT_FILE, optarg);
+            register_op_modifier(NVRAMTOOL_MOD_USE_CMOS_LAYOUT_FILE, optarg);
             break;
          case 'Y':
-            register_op(&op_found, LXBIOS_OP_SHOW_LAYOUT, NULL);
+            register_op(&op_found, NVRAMTOOL_OP_SHOW_LAYOUT, NULL);
             break;
          case -1:  /* no more command line args */
             break;
@@ -178,13 +178,13 @@
  *
  * Store the user's selection of which operation this program should perform.
  ****************************************************************************/
-static void register_op (int *op_found, lxbios_op_t op, char op_param[])
- { if (*op_found && (op != lxbios_op.op))
+static void register_op (int *op_found, nvramtool_op_t op, char op_param[])
+ { if (*op_found && (op != nvramtool_op.op))
       usage(stderr);
 
    *op_found = TRUE;
-   lxbios_op.op = op;
-   lxbios_op.param = op_param;
+   nvramtool_op.op = op;
+   nvramtool_op.param = op_param;
  }
 
 /****************************************************************************
@@ -193,11 +193,11 @@
  * Store information regarding an optional argument specified in addition to
  * the user's selection of which operation this program should perform.
  ****************************************************************************/
-static void register_op_modifier (lxbios_op_modifier_t mod, char mod_param[])
+static void register_op_modifier (nvramtool_op_modifier_t mod, char mod_param[])
  { static int found_seq = 0;
-   lxbios_op_modifier_info_t *mod_info;
+   nvramtool_op_modifier_info_t *mod_info;
 
-   mod_info = &lxbios_op_modifiers[mod];
+   mod_info = &nvramtool_op_modifiers[mod];
    mod_info->found = TRUE;
    mod_info->found_seq = ++found_seq;
    mod_info->param = mod_param;
@@ -210,13 +210,13 @@
  * the last specified argument overrides previous conflicting arguments.
  ****************************************************************************/
 static void resolve_op_modifiers (void)
- { if (lxbios_op_modifiers[LXBIOS_MOD_USE_CMOS_LAYOUT_FILE].found &&
-       lxbios_op_modifiers[LXBIOS_MOD_USE_CMOS_OPT_TABLE].found)
-    { if (lxbios_op_modifiers[LXBIOS_MOD_USE_CMOS_LAYOUT_FILE].found_seq >
-          lxbios_op_modifiers[LXBIOS_MOD_USE_CMOS_OPT_TABLE].found_seq)
-         lxbios_op_modifiers[LXBIOS_MOD_USE_CMOS_OPT_TABLE].found = FALSE;
+ { if (nvramtool_op_modifiers[NVRAMTOOL_MOD_USE_CMOS_LAYOUT_FILE].found &&
+       nvramtool_op_modifiers[NVRAMTOOL_MOD_USE_CMOS_OPT_TABLE].found)
+    { if (nvramtool_op_modifiers[NVRAMTOOL_MOD_USE_CMOS_LAYOUT_FILE].found_seq >
+          nvramtool_op_modifiers[NVRAMTOOL_MOD_USE_CMOS_OPT_TABLE].found_seq)
+         nvramtool_op_modifiers[NVRAMTOOL_MOD_USE_CMOS_OPT_TABLE].found = FALSE;
       else
-         lxbios_op_modifiers[LXBIOS_MOD_USE_CMOS_LAYOUT_FILE].found = FALSE;
+         nvramtool_op_modifiers[NVRAMTOOL_MOD_USE_CMOS_LAYOUT_FILE].found = FALSE;
     }
  }
 
@@ -226,7 +226,7 @@
  * Perform sanity checking on command line arguments.
  ****************************************************************************/
 static void sanity_check_args (void)
- { if ((lxbios_op_modifiers[LXBIOS_MOD_SHOW_VALUE_ONLY].found) &&
-       (lxbios_op.op != LXBIOS_OP_CMOS_SHOW_ONE_PARAM))
+ { if ((nvramtool_op_modifiers[NVRAMTOOL_MOD_SHOW_VALUE_ONLY].found) &&
+       (nvramtool_op.op != NVRAMTOOL_OP_CMOS_SHOW_ONE_PARAM))
       usage(stderr);
  }

Modified: trunk/util/lxbios/opts.h
===================================================================
--- trunk/util/lxbios/opts.h	2008-03-01 18:49:39 UTC (rev 3121)
+++ trunk/util/lxbios/opts.h	2008-03-01 19:06:32 UTC (rev 3122)
@@ -8,9 +8,9 @@
  *  UCRL-CODE-2003-012
  *  All rights reserved.
  *
- *  This file is part of lxbios, a utility for reading/writing coreboot
+ *  This file is part of nvramtool, a utility for reading/writing coreboot
  *  parameters and displaying information from the coreboot table.
- *  For details, see http://coreboot.org/Lxbios.
+ *  For details, see http://coreboot.org/nvramtool.
  *
  *  Please also read the file DISCLAIMER which is included in this software
  *  distribution.
@@ -29,56 +29,56 @@
  *  59 Temple Place, Suite 330, Boston, MA 02111-1307 USA.
 \*****************************************************************************/
 
-#ifndef LXBIOS_OPTS_H
-#define LXBIOS_OPTS_H
+#ifndef OPTS_H
+#define OPTS_H
 
 #include "common.h"
 
 typedef enum
- { LXBIOS_OP_SHOW_VERSION = 0,
-   LXBIOS_OP_SHOW_USAGE,
-   LXBIOS_OP_LBTABLE_SHOW_INFO,
-   LXBIOS_OP_LBTABLE_DUMP,
-   LXBIOS_OP_SHOW_PARAM_VALUES,
-   LXBIOS_OP_CMOS_SHOW_ONE_PARAM,
-   LXBIOS_OP_CMOS_SHOW_ALL_PARAMS,
-   LXBIOS_OP_CMOS_SET_ONE_PARAM,
-   LXBIOS_OP_CMOS_SET_PARAMS_STDIN,
-   LXBIOS_OP_CMOS_SET_PARAMS_FILE,
-   LXBIOS_OP_CMOS_CHECKSUM,
-   LXBIOS_OP_SHOW_LAYOUT,
-   LXBIOS_OP_WRITE_CMOS_DUMP,
-   LXBIOS_OP_READ_CMOS_DUMP,
-   LXBIOS_OP_SHOW_CMOS_HEX_DUMP,
-   LXBIOS_OP_SHOW_CMOS_DUMPFILE
+ { NVRAMTOOL_OP_SHOW_VERSION = 0,
+   NVRAMTOOL_OP_SHOW_USAGE,
+   NVRAMTOOL_OP_LBTABLE_SHOW_INFO,
+   NVRAMTOOL_OP_LBTABLE_DUMP,
+   NVRAMTOOL_OP_SHOW_PARAM_VALUES,
+   NVRAMTOOL_OP_CMOS_SHOW_ONE_PARAM,
+   NVRAMTOOL_OP_CMOS_SHOW_ALL_PARAMS,
+   NVRAMTOOL_OP_CMOS_SET_ONE_PARAM,
+   NVRAMTOOL_OP_CMOS_SET_PARAMS_STDIN,
+   NVRAMTOOL_OP_CMOS_SET_PARAMS_FILE,
+   NVRAMTOOL_OP_CMOS_CHECKSUM,
+   NVRAMTOOL_OP_SHOW_LAYOUT,
+   NVRAMTOOL_OP_WRITE_CMOS_DUMP,
+   NVRAMTOOL_OP_READ_CMOS_DUMP,
+   NVRAMTOOL_OP_SHOW_CMOS_HEX_DUMP,
+   NVRAMTOOL_OP_SHOW_CMOS_DUMPFILE
  }
-lxbios_op_t;
+nvramtool_op_t;
 
 typedef struct
- { lxbios_op_t op;
+ { nvramtool_op_t op;
    char *param;
  }
-lxbios_op_info_t;
+nvramtool_op_info_t;
 
 typedef enum
- { LXBIOS_MOD_SHOW_VALUE_ONLY = 0,
-   LXBIOS_MOD_USE_CMOS_LAYOUT_FILE,
-   LXBIOS_MOD_USE_CMOS_OPT_TABLE,
-   LXBIOS_NUM_OP_MODIFIERS  /* must always be last */
+ { NVRAMTOOL_MOD_SHOW_VALUE_ONLY = 0,
+   NVRAMTOOL_MOD_USE_CMOS_LAYOUT_FILE,
+   NVRAMTOOL_MOD_USE_CMOS_OPT_TABLE,
+   NVRAMTOOL_NUM_OP_MODIFIERS  /* must always be last */
  }
-lxbios_op_modifier_t;
+nvramtool_op_modifier_t;
 
 typedef struct
  { int found;
    int found_seq;
    char *param;
  }
-lxbios_op_modifier_info_t;
+nvramtool_op_modifier_info_t;
 
-extern lxbios_op_info_t lxbios_op;
+extern nvramtool_op_info_t nvramtool_op;
 
-extern lxbios_op_modifier_info_t lxbios_op_modifiers[];
+extern nvramtool_op_modifier_info_t nvramtool_op_modifiers[];
 
-void parse_lxbios_args (int argc, char *argv[]);
+void parse_nvramtool_args (int argc, char *argv[]);
 
-#endif  /* LXBIOS_OPTS_H */
+#endif  /* OPTS_H */

Modified: trunk/util/lxbios/reg_expr.c
===================================================================
--- trunk/util/lxbios/reg_expr.c	2008-03-01 18:49:39 UTC (rev 3121)
+++ trunk/util/lxbios/reg_expr.c	2008-03-01 19:06:32 UTC (rev 3122)
@@ -8,9 +8,9 @@
  *  UCRL-CODE-2003-012
  *  All rights reserved.
  *
- *  This file is part of lxbios, a utility for reading/writing coreboot
+ *  This file is part of nvramtool, a utility for reading/writing coreboot
  *  parameters and displaying information from the coreboot table.
- *  For details, see http://coreboot.org/Lxbios.
+ *  For details, see http://coreboot.org/nvramtool.
  *
  *  Please also read the file DISCLAIMER which is included in this software
  *  distribution.

Modified: trunk/util/lxbios/reg_expr.h
===================================================================
--- trunk/util/lxbios/reg_expr.h	2008-03-01 18:49:39 UTC (rev 3121)
+++ trunk/util/lxbios/reg_expr.h	2008-03-01 19:06:32 UTC (rev 3122)
@@ -8,9 +8,9 @@
  *  UCRL-CODE-2003-012
  *  All rights reserved.
  *
- *  This file is part of lxbios, a utility for reading/writing coreboot
+ *  This file is part of nvramtool, a utility for reading/writing coreboot
  *  parameters and displaying information from the coreboot table.
- *  For details, see http://coreboot.org/Lxbios.
+ *  For details, see http://coreboot.org/nvramtool.
  *
  *  Please also read the file DISCLAIMER which is included in this software
  *  distribution.
@@ -29,8 +29,8 @@
  *  59 Temple Place, Suite 330, Boston, MA 02111-1307 USA.
 \*****************************************************************************/
 
-#ifndef LXBIOS_REG_EXPR_H
-#define LXBIOS_REG_EXPR_H
+#ifndef REG_EXPR_H
+#define REG_EXPR_H
 
 #include <regex.h>
 #include "common.h"
@@ -39,4 +39,4 @@
                         /* const char *expr1, regex_t *reg1, */ ...);
 void free_reg_exprs (int num_exprs, /* regex_t *reg1, */ ...);
 
-#endif  /* LXBIOS_REG_EXPR_H */
+#endif  /* REG_EXPR_H */




From svn at coreboot.org  Sat Mar  1 20:07:47 2008
From: svn at coreboot.org (svn at coreboot.org)
Date: Sat,  1 Mar 2008 20:07:47 +0100
Subject: [coreboot] r3123 - trunk/util/lxbios
Message-ID: <mailman.1240.1355071270.16123.coreboot@coreboot.org>

Author: uwe
Date: 2008-03-01 20:07:46 +0100 (Sat, 01 Mar 2008)
New Revision: 3123

Added:
   trunk/util/lxbios/nvramtool.1
   trunk/util/lxbios/nvramtool.c
   trunk/util/lxbios/nvramtool.spec
Removed:
   trunk/util/lxbios/lxbios.1
   trunk/util/lxbios/lxbios.c
   trunk/util/lxbios/lxbios.spec
Log:
Rename lxbios to nvramtool, step 2 (rename files).

Signed-off-by: Uwe Hermann <uwe at hermann-uwe.de>
Acked-by: Stefan Reinauer <stepan at coresystems.de>



Deleted: trunk/util/lxbios/lxbios.1
===================================================================
--- trunk/util/lxbios/lxbios.1	2008-03-01 19:06:32 UTC (rev 3122)
+++ trunk/util/lxbios/lxbios.1	2008-03-01 19:07:46 UTC (rev 3123)
@@ -1,255 +0,0 @@
-.\"***************************************************************************\
-.\" nvramtool.1
-.\" $Id$
-.\"***************************************************************************
-.\"  Copyright (C) 2002, 2003 The Regents of the University of California.
-.\"  Produced at the Lawrence Livermore National Laboratory.
-.\"  Written by David S. Peterson <dsp at llnl.gov> <dave_peterson at pobox.com>.
-.\"  UCRL-CODE-2003-012
-.\"  All rights reserved.
-.\"
-.\"  This file is part of nvramtool, a utility for reading/writing coreboot
-.\"  parameters and displaying information from the coreboot table.
-.\"  For details, see http://coreboot.org/nvramtool.
-.\"
-.\"  Please also read the file DISCLAIMER which is included in this software
-.\"  distribution.
-.\"
-.\"  This program is free software; you can redistribute it and/or modify it
-.\"  under the terms of the GNU General Public License (as published by the
-.\"  Free Software Foundation) version 2, dated June 1991.
-.\"
-.\"  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 terms and
-.\"  conditions of the GNU General Public License for more details.
-.\"
-.\"  You should have received a copy of the GNU General Public License along
-.\"  with this program; if not, write to the Free Software Foundation, Inc.,
-.\"  59 Temple Place, Suite 330, Boston, MA 02111-1307 USA.
-.\"***************************************************************************/
-.TH NVRAMTOOL 1 "January 2008" Linux
-.SH NAME
-nvramtool \- read/write coreboot-related information
-.SH SYNOPSIS
-.B "nvramtool [OPTS] [-n] -r NAME"
-.br
-.B "nvramtool [OPTS] -e NAME"
-.br
-.B "nvramtool [OPTS] -a"
-.br
-.B "nvramtool [OPTS] -w NAME=VALUE"
-.br
-.B "nvramtool [OPTS] -p INPUT_FILE"
-.br
-.B "nvramtool [OPTS] -i"
-.br
-.B "nvramtool [OPTS] -c [VALUE]"
-.br
-.B "nvramtool [OPTS] -l [ARG]"
-.br
-.B "nvramtool [OPTS] -d"
-.br
-.B "nvramtool [OPTS] -Y"
-.br
-.B "nvramtool [OPTS] -b OUTPUT_FILE"
-.br
-.B "nvramtool [OPTS] -B INPUT_FILE"
-.br
-.B "nvramtool [OPTS] -x"
-.br
-.B "nvramtool [OPTS] -X DUMPFILE"
-.br
-.B "nvramtool [OPTS] -v"
-.br
-.B "nvramtool [OPTS] -h"
-.SH DESCRIPTION
-.B "nvramtool"
-is a utility for reading/writing coreboot parameters and displaying
-information from the coreboot table.
-
-The coreboot table resides in low physical memory.  It is created at boot
-time by coreboot, and contains various system information such as the type
-of mainboard in use.  It specifies locations in the CMOS (nonvolatile RAM)
-where the coreboot parameters are stored.
-
-This program is intended for (x86-based) systems that use coreboot.  For
-information about coreboot, see
-.br
-http://www.coreboot.org/.
-.SH PARAMETERS
-.TP
-.B "[-n] -r NAME"
-Show the value of the coreboot parameter given by
-.B "NAME."
-If
-.B "-n"
-is specified, show only the value.  Otherwise show both parameter name and
-value.
-.TP
-.B "-e NAME"
-Show all possible values for parameter given by
-.B "NAME."
-.TP
-.B "-a"
-Show the names and values for all coreboot parameters.
-.TP
-.B "-w NAME=VALUE"
-Assign
-.B "VALUE"
-to coreboot parameter given by
-.B "NAME."
-.TP
-.B "-p INPUT_FILE"
-Assign values to coreboot parameters according to the contents of
-.B "INPUT_FILE."
-The format of this file is described below.
-.TP
-.B "-i"
-This is similar to the
-.B "-p"
-option, except that the contents of the input file are taken from standard
-input.
-.TP
-.B "-c [VALUE]"
-If
-.B "VALUE"
-is present then set the CMOS checksum for the coreboot parameters to
-.B "VALUE." 
-Otherwise, show the checksum value.
-.TP
-.B "-l [ARG]"
-If
-.B "ARG"
-is present then show information from the coreboot table as specified by
-.B "ARG."
-Otherwise show all possible values for
-.B "ARG."
-.TP
-.B "-d"
-Do a low-level dump of the coreboot table.
-.TP
-.B "-Y"
-Write CMOS layout information to standard output.  If redirected to a file,
-the layout information may be used as input for the
-.B "'-y LAYOUT_FILE'"
-option (see below).
-.TP
-.B "-b OUTPUT_FILE"
-Write the contents of CMOS memory to the binary file
-.B "OUTPUT_FILE."
-The first 14 bytes of
-.B "OUTPUT_FILE"
-do not contain actual CMOS data, and are always written as zeros.  This is
-because the first 14 bytes of the CMOS area do not contain CMOS memory.  These
-bytes are involved with the functioning of the real time clock.
-.TP
-.B "-B INPUT_FILE"
-Read binary data from
-.B "INPUT_FILE"
-and write the data to CMOS memory.  The first 14 bytes of
-.B "INPUT_FILE"
-are skipped and data is written to CMOS starting at the 15th byte of the CMOS
-area.  This is because the first 14 bytes of the CMOS area do not contain CMOS
-memory.  These bytes are involved with the functioning of the real time clock.
-.TP
-.B "-x"
-Show a hex dump of all CMOS data.  The first 14 bytes of the dump do not
-contain actual CMOS data, and are always shown as zeros.  This is because the
-first 14 bytes of the CMOS area do not contain CMOS memory.  These bytes are
-involved with the functioning of the real time clock.
-.TP
-.B "-X DUMPFILE"
-Read binary data from
-.B "DUMPFILE"
-(presumably a CMOS dumpfile created using the
-.B "-b OUTPUT_FILE"
-option) and show a hex dump of the data.
-.TP
-.B "-v"
-Show version information for this program.
-.TP
-.B "-h"
-Show a help message for this program.
-.SH "OPTIONS"
-In all cases above,
-.B "[OPTS]"
-evaluates to the following:
-
-.B "    [-y LAYOUT_FILE | -t]"
-
-The
-.B "'-y LAYOUT_FILE'"
-option tells nvramtool to obtain CMOS layout information from the contents of
-.B "LAYOUT_FILE."
-Likewise, the
-.B "'-t'"
-option tells nvramtool to obtain CMOS layout information from the CMOS option
-table (contained within the coreboot table).  If neither option is
-specified, the CMOS option table is used by default.
-.B "LAYOUT_FILE"
-follows the format of the
-.B "cmos.layout"
-files provided by coreboot.
-
-If the coreboot installed on your system was built without specifying
-.B "HAVE_OPTION_TABLE,"
-then the coreboot table will not contain a CMOS option table.  In this case,
-the
-.B "'-y LAYOUT_FILE'"
-option must be used.
-
-These two options are silently ignored when used in combination with other
-options (such as
-.B "-h,"
-for instance) for which they are not applicable.
-.SH FILE FORMAT
-For the
-.B "-p"
-option,
-.B "INPUT_FILE"
-must consist of a sequence of lines such that each line is either a blank
-line, a comment, or an assignment.  A blank line consists only of zero or
-more whitespace characters (spaces and tabs).  A comment is constructed as
-follows:
-
-.B "    [ws]#[text]"
-
-Here,
-.B "[ws]"
-indicates optional whitespace characters and
-.B "[text]"
-indicates optional text.  Blank lines and comments are both ignored.  An
-assignment is constructed as follows:
-
-.B "    [ws]NAME[ws]=[ws]VALUE[ws]"
-
-Here,
-.B "NAME"
-is the name of a coreboot parameter and
-.B "VALUE"
-is the value that will be assigned to
-.B "NAME."
-.B "VALUE"
-is allowed to contain whitespace characters, but it must begin and end with
-nonwhitespace characters.  Note that each comment must appear on a line by
-itself.  If you attempt to add a comment to the end of an assignment, then the
-comment will be interpreted as part of
-.B "VALUE."
-It is useful to observe that the output produced by both the
-.B "-a"
-and the
-.B "'[-n] NAME'"
-options (without
-.B "-n"
-specified) adheres to this file format.
-.SH BUGS
-This program does not implement any type of synchronization to ensure that
-different processes don't stomp on each other when trying to access the
-nonvolatile RAM simultaneously.  Therefore, corruption of the BIOS parameter
-values may occur if multiple instances of this program are executed
-concurrently.
-.SH AUTHORS
-David S. Peterson <dsp at llnl.gov> <dave_peterson at pobox.com>
-.br
-Stefan Reinauer <stepan at openbios.org>

Deleted: trunk/util/lxbios/lxbios.c
===================================================================
--- trunk/util/lxbios/lxbios.c	2008-03-01 19:06:32 UTC (rev 3122)
+++ trunk/util/lxbios/lxbios.c	2008-03-01 19:07:46 UTC (rev 3123)
@@ -1,754 +0,0 @@
-/*****************************************************************************\
- * nvramtool.c
- * $Id$
- *****************************************************************************
- *  Copyright (C) 2002-2005 The Regents of the University of California.
- *  Produced at the Lawrence Livermore National Laboratory.
- *  Written by Dave Peterson <dsp at llnl.gov> <dave_peterson at pobox.com>.
- *  UCRL-CODE-2003-012
- *  All rights reserved.
- *
- *  This file is part of nvramtool, a utility for reading/writing coreboot
- *  parameters and displaying information from the coreboot table.
- *  For details, see http://coreboot.org/nvramtool.
- *
- *  Please also read the file DISCLAIMER which is included in this software
- *  distribution.
- *
- *  This program is free software; you can redistribute it and/or modify it
- *  under the terms of the GNU General Public License (as published by the
- *  Free Software Foundation) version 2, dated June 1991.
- *
- *  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 terms and
- *  conditions of the GNU General Public License for more details.
- *
- *  You should have received a copy of the GNU General Public License along
- *  with this program; if not, write to the Free Software Foundation, Inc.,
- *  59 Temple Place, Suite 330, Boston, MA 02111-1307 USA.
-\*****************************************************************************/
-
-#include "common.h"
-#include "opts.h"
-#include "lbtable.h"
-#include "layout.h"
-#include "layout_file.h"
-#include "input_file.h"
-#include "cmos_ops.h"
-#include "cmos_lowlevel.h"
-#include "reg_expr.h"
-#include "hexdump.h"
-
-typedef void (*op_fn_t) (void);
-
-static void op_show_version (void);
-static void op_show_usage (void);
-static void op_lbtable_show_info (void);
-static void op_lbtable_dump (void);
-static void op_show_param_values (void);
-static void op_cmos_show_one_param (void);
-static void op_cmos_show_all_params (void);
-static void op_cmos_set_one_param (void);
-static void op_cmos_set_params_stdin (void);
-static void op_cmos_set_params_file (void);
-static void op_cmos_checksum (void);
-static void op_show_layout (void);
-static void op_write_cmos_dump (void);
-static void op_read_cmos_dump (void);
-static void op_show_cmos_hex_dump (void);
-static void op_show_cmos_dumpfile (void);
-static int list_one_param (const char name[], int show_name);
-static int list_all_params (void);
-static void list_param_enums (const char name[]);
-static void set_one_param (const char name[], const char value[]);
-static void set_params (FILE *f);
-static void parse_assignment (char arg[], const char **name,
-                              const char **value);
-static int list_cmos_entry (const cmos_entry_t *e, int show_name);
-static uint16_t convert_checksum_value (const char value[]);
-
-static const op_fn_t op_fns[] =
- { op_show_version,
-   op_show_usage,
-   op_lbtable_show_info,
-   op_lbtable_dump,
-   op_show_param_values,
-   op_cmos_show_one_param,
-   op_cmos_show_all_params,
-   op_cmos_set_one_param,
-   op_cmos_set_params_stdin,
-   op_cmos_set_params_file,
-   op_cmos_checksum,
-   op_show_layout,
-   op_write_cmos_dump,
-   op_read_cmos_dump,
-   op_show_cmos_hex_dump,
-   op_show_cmos_dumpfile
- };
-
-static const hexdump_format_t cmos_dump_format =
- { 16, 2, "", " | ", " ", " | ", '.', NULL };
-
-/****************************************************************************
- * main
- ****************************************************************************/
-int main (int argc, char *argv[])
- { cmos_layout_get_fn_t fn;
-
-   parse_nvramtool_args(argc, argv);
-
-   if (nvramtool_op_modifiers[NVRAMTOOL_MOD_USE_CMOS_LAYOUT_FILE].found)
-    { set_layout_filename(
-            nvramtool_op_modifiers[NVRAMTOOL_MOD_USE_CMOS_LAYOUT_FILE].param);
-      fn = get_layout_from_file;
-    }
-   else
-      fn = get_layout_from_cmos_table;
-
-   register_cmos_layout_get_fn(fn);
-   op_fns[nvramtool_op.op]();
-   return 0;
- }
-
-/****************************************************************************
- * op_show_version
- *
- * -v
- *
- * Show version information for this program.
- ****************************************************************************/
-static void op_show_version (void)
- { printf("This is %s version %s.\n", prog_name, prog_version); }
-
-/****************************************************************************
- * op_show_usage
- *
- * -h
- *
- * Show a usage message for this program.
- ****************************************************************************/
-static void op_show_usage (void)
- { usage(stdout); }
-
-/****************************************************************************
- * op_lbtable_show_info
- *
- * -l [ARG]
- *
- * If ARG is present, show coreboot table information specified by ARG.
- * Else show all possible values for ARG.
- ****************************************************************************/
-static void op_lbtable_show_info (void)
- { if (nvramtool_op.param == NULL)
-      list_lbtable_choices();
-   else
-    { get_lbtable();
-      list_lbtable_item(nvramtool_op.param);
-    }
- }
-
-/****************************************************************************
- * op_lbtable_dump
- *
- * -d
- *
- * Do low-level dump of coreboot table.
- ****************************************************************************/
-static void op_lbtable_dump (void)
- { get_lbtable();
-   dump_lbtable();
- }
-
-/****************************************************************************
- * op_show_param_values
- *
- * -e NAME option
- *
- * Show all possible values for parameter NAME.
- ****************************************************************************/
-static void op_show_param_values (void)
- { get_cmos_layout();
-   list_param_enums(nvramtool_op.param);
- }
-
-/****************************************************************************
- * op_cmos_show_one_param
- *
- * [-n] -r NAME
- *
- * Show parameter NAME.  If -n is specified, show value only.  Else show name
- * and value.
- ****************************************************************************/
-static void op_cmos_show_one_param (void)
- { int result;
-
-   get_cmos_layout();
-   result = list_one_param(nvramtool_op.param,
-                  !nvramtool_op_modifiers[NVRAMTOOL_MOD_SHOW_VALUE_ONLY].found);
-   cmos_checksum_verify();
-
-   if (result)
-      exit(1);
- }
-
-/****************************************************************************
- * op_cmos_show_all_params
- *
- * -a
- *
- * Show names and values for all parameters.
- ****************************************************************************/
-static void op_cmos_show_all_params (void)
- { int result;
-
-   get_cmos_layout();
-   result = list_all_params();
-   cmos_checksum_verify();
-
-   if (result)
-      exit(1);
- }
-
-/****************************************************************************
- * op_cmos_set_one_param
- *
- * -w NAME=VALUE
- *
- * Set parameter NAME to VALUE.
- ****************************************************************************/
-static void op_cmos_set_one_param (void)
- { const char *name, *value;
-
-   get_cmos_layout();
-
-   /* Separate 'NAME=VALUE' syntax into two strings representing NAME and
-    * VALUE.
-    */
-   parse_assignment(nvramtool_op.param, &name, &value);
-
-   set_one_param(name, value);
- }
-
-/****************************************************************************
- * op_cmos_set_params_stdin
- *
- * -i
- *
- * Set parameters according to standard input.
- ****************************************************************************/
-static void op_cmos_set_params_stdin (void)
- { get_cmos_layout();
-   set_params(stdin);
- }
-
-/****************************************************************************
- * op_cmos_set_params_file
- *
- * -p INPUT_FILE
- *
- * Set parameters according to INPUT_FILE.
- ****************************************************************************/
-static void op_cmos_set_params_file (void)
- { FILE *f;
-
-   if ((f = fopen(nvramtool_op.param, "r")) == NULL)
-    { fprintf(stderr, "%s: Can not open file %s for reading: %s\n",
-              prog_name, nvramtool_op.param, strerror(errno));
-      exit(1);
-    }
-
-   get_cmos_layout();
-   set_params(f);
-   fclose(f);
- }
-
-/****************************************************************************
- * op_cmos_checksum
- *
- * -c [VALUE]
- *
- * If VALUE is present, set coreboot CMOS checksum to VALUE.  Else show
- * checksum value.
- ****************************************************************************/
-static void op_cmos_checksum (void)
- { uint16_t checksum;
-
-   get_cmos_layout();
-
-   if (nvramtool_op.param == NULL)
-    { set_iopl(3);
-      checksum = cmos_checksum_read();
-      set_iopl(0);
-      printf("0x%x\n", checksum);
-    }
-   else
-    { checksum = convert_checksum_value(nvramtool_op.param);
-      set_iopl(3);
-      cmos_checksum_write(checksum);
-      set_iopl(0);
-    }
- }
-
-/****************************************************************************
- * op_show_layout
- *
- * -Y
- *
- * Write CMOS layout information to standard output.
- ****************************************************************************/
-static void op_show_layout (void)
- { get_cmos_layout();
-   write_cmos_layout(stdout);
- }
-
-/****************************************************************************
- * op_write_cmos_dump
- *
- * -b OUTPUT_FILE
- *
- * Write the contents of CMOS memory to a binary file.
- ****************************************************************************/
-static void op_write_cmos_dump (void)
- { unsigned char data[CMOS_SIZE];
-   FILE *f;
-
-   if ((f = fopen(nvramtool_op.param, "w")) == NULL)
-    { fprintf(stderr, "%s: Can not open file %s for writing: %s\n",
-              prog_name, nvramtool_op.param, strerror(errno));
-      exit(1);
-    }
-
-   set_iopl(3);
-   cmos_read_all(data);
-   set_iopl(0);
-
-   if (fwrite(data, 1, CMOS_SIZE, f) != CMOS_SIZE)
-    { fprintf(stderr, "%s: Error writing CMOS data to file %s: %s\n",
-              prog_name, nvramtool_op.param, strerror(errno));
-      exit(1);
-    }
-
-   fclose(f);
- }
-
-/****************************************************************************
- * op_read_cmos_dump
- *
- * -B INPUT_FILE
- *
- * Read binary data from a file and write the data to CMOS memory.
- ****************************************************************************/
-static void op_read_cmos_dump (void)
- { unsigned char data[CMOS_SIZE];
-   size_t nr_bytes;
-   FILE *f;
-
-   if ((f = fopen(nvramtool_op.param, "r")) == NULL)
-    { fprintf(stderr, "%s: Can not open file %s for reading: %s\n",
-              prog_name, nvramtool_op.param, strerror(errno));
-      exit(1);
-    }
-
-   if ((nr_bytes = fread(data, 1, CMOS_SIZE, f)) != CMOS_SIZE)
-    { fprintf(stderr, "%s: Error: Only able to read %d bytes of CMOS data "
-              "from file %s.  CMOS data is unchanged.\n", prog_name,
-              (int) nr_bytes, nvramtool_op.param);
-      exit(1);
-    }
-
-   fclose(f);
-   set_iopl(3);
-   cmos_write_all(data);
-   set_iopl(0);
- }
-
-/****************************************************************************
- * op_show_cmos_hex_dump
- *
- * -x
- *
- * Write a hex dump of CMOS memory to standard output.
- ****************************************************************************/
-static void op_show_cmos_hex_dump (void)
- { unsigned char data[CMOS_SIZE];
-
-   set_iopl(3);
-   cmos_read_all(data);
-   set_iopl(0);
-   hexdump(data, CMOS_SIZE, 0, stdout, &cmos_dump_format);
- }
-
-/****************************************************************************
- * op_show_cmos_dumpfile
- *
- * -X DUMP_FILE
- *
- * Read binary data from a file (presumably a CMOS dump file) and display a
- * hex dump of the CMOS data from the file.
- ****************************************************************************/
-static void op_show_cmos_dumpfile (void)
- { unsigned char data[CMOS_SIZE];
-   size_t nr_bytes;
-   FILE *f;
-
-   if ((f = fopen(nvramtool_op.param, "r")) == NULL)
-    { fprintf(stderr, "%s: Can not open file %s for reading: %s\n",
-              prog_name, nvramtool_op.param, strerror(errno));
-      exit(1);
-    }
-
-   nr_bytes = fread(data, 1, CMOS_SIZE, f);
-   fclose(f);
-   hexdump(data, nr_bytes, 0, stdout, &cmos_dump_format);
- }
-
-/****************************************************************************
- * list_one_param
- *
- * Attempt to list one CMOS parameter given by 'name'.  'show_name' is a
- * boolean value indicating whether the parameter name should be displayed
- * along with its value.  Return 1 if error was encountered.  Else return OK.
- ****************************************************************************/
-static int list_one_param (const char name[], int show_name)
- { const cmos_entry_t *e;
-
-   if (is_checksum_name(name) || ((e = find_cmos_entry(name)) == NULL))
-    { fprintf(stderr, "%s: CMOS parameter %s not found.\n", prog_name, name);
-      exit(1);
-    }
-
-   if (e->config == CMOS_ENTRY_RESERVED)
-    { fprintf(stderr, "%s: Parameter %s is reserved.\n", prog_name, name);
-      exit(1);
-    }
-
-   return (list_cmos_entry(e, show_name) != 0);
- }
-
-/****************************************************************************
- * list_all_params
- *
- * Attempt to list all CMOS parameters.  Return 1 if error was encountered.
- * Else return OK.
- ****************************************************************************/
-static int list_all_params (void)
- { const cmos_entry_t *e;
-   int result;
-
-   result = OK;
-
-   for (e = first_cmos_entry(); e != NULL; e = next_cmos_entry(e))
-    { if ((e->config == CMOS_ENTRY_RESERVED) || is_checksum_name(e->name))
-         continue;
-
-      if (list_cmos_entry(e, TRUE))
-         result = 1;
-    }
-
-   return result;
- }
-
-/****************************************************************************
- * list_param_enums
- *
- * List all possible values for CMOS parameter given by 'name'.
- ****************************************************************************/
-static void list_param_enums (const char name[])
- { const cmos_entry_t *e;
-   const cmos_enum_t *p;
-
-   if (is_checksum_name(name) || (e = find_cmos_entry(name)) == NULL)
-    { fprintf(stderr, "%s: CMOS parameter %s not found.\n", prog_name, name);
-      exit(1);
-    }
-
-   switch (e->config)
-    { case CMOS_ENTRY_ENUM:
-         for (p = first_cmos_enum_id(e->config_id);
-              p != NULL;
-              p = next_cmos_enum_id(p))
-            printf("%s\n", p->text);
-
-         break;
-
-      case CMOS_ENTRY_HEX:
-         printf("Parameter %s requires a %u-bit unsigned integer.\n", name,
-                e->length);
-         break;
-
-      case CMOS_ENTRY_RESERVED:
-         printf("Parameter %s is reserved.\n", name);
-         break;
-
-      default:
-         BUG();
-    }
- }
-
-/****************************************************************************
- * set_one_param
- *
- * Set the CMOS parameter given by 'name' to 'value'.  The 'name' parameter
- * is case-sensitive.  If we are setting an enum parameter, then 'value' is
- * interpreted as a case-sensitive string that must match the option name
- * exactly.  If we are setting a 'hex' parameter, then 'value' is treated as
- * a string representation of an unsigned integer that may be specified in
- * decimal, hex, or octal.
- ****************************************************************************/
-static void set_one_param (const char name[], const char value[])
- { const cmos_entry_t *e;
-   unsigned long long n;
-
-   if (is_checksum_name(name) || (e = find_cmos_entry(name)) == NULL)
-    { fprintf(stderr, "%s: CMOS parameter %s not found.", prog_name, name);
-      exit(1);
-    }
-
-   switch (prepare_cmos_write(e, value, &n))
-    { case OK:
-         break;
-
-      case CMOS_OP_BAD_ENUM_VALUE:
-         fprintf(stderr, "%s: Bad value for parameter %s.", prog_name, name);
-         goto fail;
-
-      case CMOS_OP_NEGATIVE_INT:
-         fprintf(stderr,
-                 "%s: This program does not support assignment of negative "
-                 "numbers to coreboot parameters.", prog_name);
-         goto fail;
-
-      case CMOS_OP_INVALID_INT:
-         fprintf(stderr, "%s: %s is not a valid integer.", prog_name, value);
-         goto fail;
-
-      case CMOS_OP_RESERVED:
-         fprintf(stderr,
-                 "%s: Can not modify reserved coreboot parameter %s.",
-                 prog_name, name);
-         goto fail;
-
-      case CMOS_OP_VALUE_TOO_WIDE:
-         fprintf(stderr,
-                 "%s: Can not write value %s to CMOS parameter %s that is "
-                 "only %d bits wide.", prog_name, value, name, e->length);
-         goto fail;
-
-      case CMOS_OP_NO_MATCHING_ENUM:
-         fprintf(stderr,
-                 "%s: coreboot parameter %s has no matching enums.",
-                 prog_name, name);
-         goto fail;
-
-      case CMOS_AREA_OUT_OF_RANGE:
-         fprintf(stderr,
-                 "%s: The CMOS area specified by the layout info for "
-                 "coreboot parameter %s is out of range.", prog_name, name);
-         goto fail;
-
-      case CMOS_AREA_OVERLAPS_RTC:
-         fprintf(stderr,
-                 "%s: The CMOS area specified by the layout info for "
-                 "coreboot parameter %s overlaps the realtime clock area.",
-                 prog_name, name);
-         goto fail;
-
-      case CMOS_AREA_TOO_WIDE:
-         fprintf(stderr,
-                 "%s: The CMOS area specified by the layout info for "
-                 "coreboot parameter %s is too wide.",
-                 prog_name, name);
-         goto fail;
-
-      default:
-         fprintf(stderr,
-                 "%s: Unknown error encountered while attempting to modify "
-                 "coreboot parameter %s.", prog_name, name);
-         goto fail;
-    }
-
-   /* write the value to nonvolatile RAM */
-   set_iopl(3);
-   cmos_write(e->bit, e->length, n);
-   cmos_checksum_write(cmos_checksum_compute());
-   set_iopl(0);
-   return;
-
-fail:
-   fprintf(stderr, "  CMOS write not performed.\n");
-   exit(1);
- }
-
-/****************************************************************************
- * set_params
- *
- * Set coreboot parameters according to the contents of file 'f'.
- ****************************************************************************/
-static void set_params (FILE *f)
- { /* First process the input file.  Then perform writes only if there were
-    * no problems processing the input.  Either all values will be written
-    * successfully or no values will be written.
-    */
-   do_cmos_writes(process_input_file(f));
- }
-
-/****************************************************************************
- * parse_assignment
- *
- * Parse the string 'arg' (which supposedly represents an assignment) into a
- * NAME and a VALUE.  If 'arg' does not conform to the proper assignment
- * syntax, exit with a usage message.  Otherwise, on return, 'arg' is broken
- * into substrings representing NAME and VALUE, and *name and *value are set
- * to point to these two substrings.
- ****************************************************************************/
-static void parse_assignment (char arg[], const char **name,
-                              const char **value)
- { static const size_t N_MATCHES = 4;
-   regmatch_t match[N_MATCHES];
-   regex_t assignment;
-
-   compile_reg_exprs(REG_EXTENDED | REG_NEWLINE, 1, assignment_regex,
-                     &assignment);
-
-   /* Does 'arg' conform to proper assignment syntax?  If not, exit with a
-    * usage message.
-    */
-   if (regexec(&assignment, arg, N_MATCHES, match, 0))
-      usage(stderr);
-
-   /* Ok, we found a valid assignment.  Break it into two strings
-    * representing NAME and VALUE.
-    */
-   arg[match[1].rm_eo] = '\0';
-   arg[match[2].rm_eo] = '\0';
-   *name = &arg[match[1].rm_so];
-   *value = &arg[match[2].rm_so];
-
-   free_reg_exprs(1, &assignment);
- }
-
-/****************************************************************************
- * list_cmos_entry
- *
- * Attempt to list the CMOS entry represented by 'e'.  'show_name' is a
- * boolean value indicating whether the parameter name should be displayed
- * along with its value.  On success, return OK.  On error, print an error
- * message and return 1.
- ****************************************************************************/
-static int list_cmos_entry (const cmos_entry_t *e, int show_name)
- { const cmos_enum_t *p;
-   unsigned long long value;
-
-   /* sanity check CMOS entry */
-   switch (prepare_cmos_read(e))
-    { case OK:
-         break;
-
-      case CMOS_OP_RESERVED:
-         BUG();
-
-      case CMOS_AREA_OUT_OF_RANGE:
-         fprintf(stderr, "%s: Can not read coreboot parameter %s because "
-                 "layout info specifies out of range CMOS area.\n", prog_name,
-                 e->name);
-         return 1;
-
-      case CMOS_AREA_OVERLAPS_RTC:
-         fprintf(stderr, "%s: Can not read coreboot parameter %s because "
-                 "layout info specifies CMOS area that overlaps realtime "
-                 "clock area.\n", prog_name, e->name);
-         return 1;
-
-      case CMOS_AREA_TOO_WIDE:
-         fprintf(stderr, "%s: Can not read coreboot parameter %s because "
-                 "layout info specifies CMOS area that is too wide.\n",
-                 prog_name, e->name);
-         return 1;
-
-      default:
-         fprintf(stderr, "%s: Unknown error encountered while attempting to "
-                 "read coreboot parameter %s\n", prog_name, e->name);
-         return 1;
-    }
-
-   /* read the value from CMOS */
-   set_iopl(3);
-   value = cmos_read(e->bit, e->length);
-   set_iopl(0);
-
-   /* display the value */
-   switch (e->config)
-    { case CMOS_ENTRY_ENUM:
-         if ((p = find_cmos_enum(e->config_id, value)) == NULL)
-          { if (show_name)
-               printf("# Bad value -> %s = 0x%llx\n", e->name, value);
-            else
-               printf("Bad value -> 0x%llx\n", value);
-          }
-         else
-          { if (show_name)
-               printf("%s = %s\n", e->name, p->text);
-            else
-               printf("%s\n", p->text);
-          }
-
-         break;
-
-      case CMOS_ENTRY_HEX:
-         if (show_name)
-            printf("%s = 0x%llx\n", e->name, value);
-         else
-            printf("0x%llx\n", value);
-
-         break;
-
-      case CMOS_ENTRY_RESERVED:
-      default:
-         BUG();
-    }
-
-   return OK;
- }
-
-/****************************************************************************
- * convert_checksum_value
- *
- * 'value' is the string representation of a checksum value that the user
- * wishes to set using the -c option.  Convert the string to a 16-bit
- * unsigned integer and return the result.  Exit with an error message if
- * 'value' is invalid.
- ****************************************************************************/
-static uint16_t convert_checksum_value (const char value[])
- { unsigned long n;
-   const char *p;
-   uint16_t result;
-   int negative;
-
-   for (p = value; isspace(*p); p++);
-
-   negative = (*p == '-');
-   n = strtoul(value, (char **) &p, 0);
-
-   if (*p)
-    { fprintf(stderr, "%s: Checksum value %s is not a valid integer.\n",
-              prog_name, value);
-      exit(1);
-    }
-
-   if (negative)
-    { fprintf(stderr,
-              "%s: Checksum must be an unsigned integer.\n", prog_name);
-      exit(1);
-    }
-
-   result = (uint16_t) n;
-
-   if (result != n)
-    { fprintf(stderr,
-              "%s: Checksum value must fit within 16 bits.\n", prog_name);
-      exit(1);
-    }
-
-   return result;
- }

Deleted: trunk/util/lxbios/lxbios.spec
===================================================================
--- trunk/util/lxbios/lxbios.spec	2008-03-01 19:06:32 UTC (rev 3122)
+++ trunk/util/lxbios/lxbios.spec	2008-03-01 19:07:46 UTC (rev 3123)
@@ -1,50 +0,0 @@
-##
-# $Id$
-##
-
-Name:    nvramtool
-Version: 2.0.1
-Release: 0
-
-Summary: coreboot utility program
-Group:   System Environment/Base
-License: GPL
-Provides: nvramtool
-
-BuildRoot: %{_tmppath}/%{name}-%{version}
-
-Source0: %{name}-%{version}.tgz
-
-%description
-nvramtool is a utility for reading/writing coreboot parameters and displaying
-information from the coreboot table.
-
-At boot time, coreboot places a table (known as the coreboot table) in low
-physical memory.  The contents of this table are preserved even after
-coreboot transfers control to the kernel and the kernel initializes itself.
-The coreboot table contains various system information such as the type of
-mainboard in use.  It also specifies locations in the CMOS (nonvolatile RAM)
-where the coreboot parameters are stored.
-
-%prep
-%setup -n %{name}-%{version}
-
-%build
-make
-
-%install
-rm -rf "$RPM_BUILD_ROOT"
-mkdir -p "$RPM_BUILD_ROOT/usr/bin"
-mkdir -p "$RPM_BUILD_ROOT/usr/man/man1"
-cp nvramtool "$RPM_BUILD_ROOT/usr/bin"
-cp nvramtool.1.gz $RPM_BUILD_ROOT/usr/man/man1
-
-%clean
-rm -rf "$RPM_BUILD_ROOT"
-
-%files
-%defattr(-,root,root,0755)
-%doc ChangeLog README
-%doc README
-/usr/bin/nvramtool
-/usr/man/man1/nvramtool.1.gz

Copied: trunk/util/lxbios/nvramtool.1 (from rev 3122, trunk/util/lxbios/lxbios.1)
===================================================================
--- trunk/util/lxbios/nvramtool.1	                        (rev 0)
+++ trunk/util/lxbios/nvramtool.1	2008-03-01 19:07:46 UTC (rev 3123)
@@ -0,0 +1,255 @@
+.\"***************************************************************************\
+.\" nvramtool.1
+.\" $Id$
+.\"***************************************************************************
+.\"  Copyright (C) 2002, 2003 The Regents of the University of California.
+.\"  Produced at the Lawrence Livermore National Laboratory.
+.\"  Written by David S. Peterson <dsp at llnl.gov> <dave_peterson at pobox.com>.
+.\"  UCRL-CODE-2003-012
+.\"  All rights reserved.
+.\"
+.\"  This file is part of nvramtool, a utility for reading/writing coreboot
+.\"  parameters and displaying information from the coreboot table.
+.\"  For details, see http://coreboot.org/nvramtool.
+.\"
+.\"  Please also read the file DISCLAIMER which is included in this software
+.\"  distribution.
+.\"
+.\"  This program is free software; you can redistribute it and/or modify it
+.\"  under the terms of the GNU General Public License (as published by the
+.\"  Free Software Foundation) version 2, dated June 1991.
+.\"
+.\"  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 terms and
+.\"  conditions of the GNU General Public License for more details.
+.\"
+.\"  You should have received a copy of the GNU General Public License along
+.\"  with this program; if not, write to the Free Software Foundation, Inc.,
+.\"  59 Temple Place, Suite 330, Boston, MA 02111-1307 USA.
+.\"***************************************************************************/
+.TH NVRAMTOOL 1 "January 2008" Linux
+.SH NAME
+nvramtool \- read/write coreboot-related information
+.SH SYNOPSIS
+.B "nvramtool [OPTS] [-n] -r NAME"
+.br
+.B "nvramtool [OPTS] -e NAME"
+.br
+.B "nvramtool [OPTS] -a"
+.br
+.B "nvramtool [OPTS] -w NAME=VALUE"
+.br
+.B "nvramtool [OPTS] -p INPUT_FILE"
+.br
+.B "nvramtool [OPTS] -i"
+.br
+.B "nvramtool [OPTS] -c [VALUE]"
+.br
+.B "nvramtool [OPTS] -l [ARG]"
+.br
+.B "nvramtool [OPTS] -d"
+.br
+.B "nvramtool [OPTS] -Y"
+.br
+.B "nvramtool [OPTS] -b OUTPUT_FILE"
+.br
+.B "nvramtool [OPTS] -B INPUT_FILE"
+.br
+.B "nvramtool [OPTS] -x"
+.br
+.B "nvramtool [OPTS] -X DUMPFILE"
+.br
+.B "nvramtool [OPTS] -v"
+.br
+.B "nvramtool [OPTS] -h"
+.SH DESCRIPTION
+.B "nvramtool"
+is a utility for reading/writing coreboot parameters and displaying
+information from the coreboot table.
+
+The coreboot table resides in low physical memory.  It is created at boot
+time by coreboot, and contains various system information such as the type
+of mainboard in use.  It specifies locations in the CMOS (nonvolatile RAM)
+where the coreboot parameters are stored.
+
+This program is intended for (x86-based) systems that use coreboot.  For
+information about coreboot, see
+.br
+http://www.coreboot.org/.
+.SH PARAMETERS
+.TP
+.B "[-n] -r NAME"
+Show the value of the coreboot parameter given by
+.B "NAME."
+If
+.B "-n"
+is specified, show only the value.  Otherwise show both parameter name and
+value.
+.TP
+.B "-e NAME"
+Show all possible values for parameter given by
+.B "NAME."
+.TP
+.B "-a"
+Show the names and values for all coreboot parameters.
+.TP
+.B "-w NAME=VALUE"
+Assign
+.B "VALUE"
+to coreboot parameter given by
+.B "NAME."
+.TP
+.B "-p INPUT_FILE"
+Assign values to coreboot parameters according to the contents of
+.B "INPUT_FILE."
+The format of this file is described below.
+.TP
+.B "-i"
+This is similar to the
+.B "-p"
+option, except that the contents of the input file are taken from standard
+input.
+.TP
+.B "-c [VALUE]"
+If
+.B "VALUE"
+is present then set the CMOS checksum for the coreboot parameters to
+.B "VALUE." 
+Otherwise, show the checksum value.
+.TP
+.B "-l [ARG]"
+If
+.B "ARG"
+is present then show information from the coreboot table as specified by
+.B "ARG."
+Otherwise show all possible values for
+.B "ARG."
+.TP
+.B "-d"
+Do a low-level dump of the coreboot table.
+.TP
+.B "-Y"
+Write CMOS layout information to standard output.  If redirected to a file,
+the layout information may be used as input for the
+.B "'-y LAYOUT_FILE'"
+option (see below).
+.TP
+.B "-b OUTPUT_FILE"
+Write the contents of CMOS memory to the binary file
+.B "OUTPUT_FILE."
+The first 14 bytes of
+.B "OUTPUT_FILE"
+do not contain actual CMOS data, and are always written as zeros.  This is
+because the first 14 bytes of the CMOS area do not contain CMOS memory.  These
+bytes are involved with the functioning of the real time clock.
+.TP
+.B "-B INPUT_FILE"
+Read binary data from
+.B "INPUT_FILE"
+and write the data to CMOS memory.  The first 14 bytes of
+.B "INPUT_FILE"
+are skipped and data is written to CMOS starting at the 15th byte of the CMOS
+area.  This is because the first 14 bytes of the CMOS area do not contain CMOS
+memory.  These bytes are involved with the functioning of the real time clock.
+.TP
+.B "-x"
+Show a hex dump of all CMOS data.  The first 14 bytes of the dump do not
+contain actual CMOS data, and are always shown as zeros.  This is because the
+first 14 bytes of the CMOS area do not contain CMOS memory.  These bytes are
+involved with the functioning of the real time clock.
+.TP
+.B "-X DUMPFILE"
+Read binary data from
+.B "DUMPFILE"
+(presumably a CMOS dumpfile created using the
+.B "-b OUTPUT_FILE"
+option) and show a hex dump of the data.
+.TP
+.B "-v"
+Show version information for this program.
+.TP
+.B "-h"
+Show a help message for this program.
+.SH "OPTIONS"
+In all cases above,
+.B "[OPTS]"
+evaluates to the following:
+
+.B "    [-y LAYOUT_FILE | -t]"
+
+The
+.B "'-y LAYOUT_FILE'"
+option tells nvramtool to obtain CMOS layout information from the contents of
+.B "LAYOUT_FILE."
+Likewise, the
+.B "'-t'"
+option tells nvramtool to obtain CMOS layout information from the CMOS option
+table (contained within the coreboot table).  If neither option is
+specified, the CMOS option table is used by default.
+.B "LAYOUT_FILE"
+follows the format of the
+.B "cmos.layout"
+files provided by coreboot.
+
+If the coreboot installed on your system was built without specifying
+.B "HAVE_OPTION_TABLE,"
+then the coreboot table will not contain a CMOS option table.  In this case,
+the
+.B "'-y LAYOUT_FILE'"
+option must be used.
+
+These two options are silently ignored when used in combination with other
+options (such as
+.B "-h,"
+for instance) for which they are not applicable.
+.SH FILE FORMAT
+For the
+.B "-p"
+option,
+.B "INPUT_FILE"
+must consist of a sequence of lines such that each line is either a blank
+line, a comment, or an assignment.  A blank line consists only of zero or
+more whitespace characters (spaces and tabs).  A comment is constructed as
+follows:
+
+.B "    [ws]#[text]"
+
+Here,
+.B "[ws]"
+indicates optional whitespace characters and
+.B "[text]"
+indicates optional text.  Blank lines and comments are both ignored.  An
+assignment is constructed as follows:
+
+.B "    [ws]NAME[ws]=[ws]VALUE[ws]"
+
+Here,
+.B "NAME"
+is the name of a coreboot parameter and
+.B "VALUE"
+is the value that will be assigned to
+.B "NAME."
+.B "VALUE"
+is allowed to contain whitespace characters, but it must begin and end with
+nonwhitespace characters.  Note that each comment must appear on a line by
+itself.  If you attempt to add a comment to the end of an assignment, then the
+comment will be interpreted as part of
+.B "VALUE."
+It is useful to observe that the output produced by both the
+.B "-a"
+and the
+.B "'[-n] NAME'"
+options (without
+.B "-n"
+specified) adheres to this file format.
+.SH BUGS
+This program does not implement any type of synchronization to ensure that
+different processes don't stomp on each other when trying to access the
+nonvolatile RAM simultaneously.  Therefore, corruption of the BIOS parameter
+values may occur if multiple instances of this program are executed
+concurrently.
+.SH AUTHORS
+David S. Peterson <dsp at llnl.gov> <dave_peterson at pobox.com>
+.br
+Stefan Reinauer <stepan at openbios.org>

Copied: trunk/util/lxbios/nvramtool.c (from rev 3122, trunk/util/lxbios/lxbios.c)
===================================================================
--- trunk/util/lxbios/nvramtool.c	                        (rev 0)
+++ trunk/util/lxbios/nvramtool.c	2008-03-01 19:07:46 UTC (rev 3123)
@@ -0,0 +1,754 @@
+/*****************************************************************************\
+ * nvramtool.c
+ * $Id$
+ *****************************************************************************
+ *  Copyright (C) 2002-2005 The Regents of the University of California.
+ *  Produced at the Lawrence Livermore National Laboratory.
+ *  Written by Dave Peterson <dsp at llnl.gov> <dave_peterson at pobox.com>.
+ *  UCRL-CODE-2003-012
+ *  All rights reserved.
+ *
+ *  This file is part of nvramtool, a utility for reading/writing coreboot
+ *  parameters and displaying information from the coreboot table.
+ *  For details, see http://coreboot.org/nvramtool.
+ *
+ *  Please also read the file DISCLAIMER which is included in this software
+ *  distribution.
+ *
+ *  This program is free software; you can redistribute it and/or modify it
+ *  under the terms of the GNU General Public License (as published by the
+ *  Free Software Foundation) version 2, dated June 1991.
+ *
+ *  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 terms and
+ *  conditions of the GNU General Public License for more details.
+ *
+ *  You should have received a copy of the GNU General Public License along
+ *  with this program; if not, write to the Free Software Foundation, Inc.,
+ *  59 Temple Place, Suite 330, Boston, MA 02111-1307 USA.
+\*****************************************************************************/
+
+#include "common.h"
+#include "opts.h"
+#include "lbtable.h"
+#include "layout.h"
+#include "layout_file.h"
+#include "input_file.h"
+#include "cmos_ops.h"
+#include "cmos_lowlevel.h"
+#include "reg_expr.h"
+#include "hexdump.h"
+
+typedef void (*op_fn_t) (void);
+
+static void op_show_version (void);
+static void op_show_usage (void);
+static void op_lbtable_show_info (void);
+static void op_lbtable_dump (void);
+static void op_show_param_values (void);
+static void op_cmos_show_one_param (void);
+static void op_cmos_show_all_params (void);
+static void op_cmos_set_one_param (void);
+static void op_cmos_set_params_stdin (void);
+static void op_cmos_set_params_file (void);
+static void op_cmos_checksum (void);
+static void op_show_layout (void);
+static void op_write_cmos_dump (void);
+static void op_read_cmos_dump (void);
+static void op_show_cmos_hex_dump (void);
+static void op_show_cmos_dumpfile (void);
+static int list_one_param (const char name[], int show_name);
+static int list_all_params (void);
+static void list_param_enums (const char name[]);
+static void set_one_param (const char name[], const char value[]);
+static void set_params (FILE *f);
+static void parse_assignment (char arg[], const char **name,
+                              const char **value);
+static int list_cmos_entry (const cmos_entry_t *e, int show_name);
+static uint16_t convert_checksum_value (const char value[]);
+
+static const op_fn_t op_fns[] =
+ { op_show_version,
+   op_show_usage,
+   op_lbtable_show_info,
+   op_lbtable_dump,
+   op_show_param_values,
+   op_cmos_show_one_param,
+   op_cmos_show_all_params,
+   op_cmos_set_one_param,
+   op_cmos_set_params_stdin,
+   op_cmos_set_params_file,
+   op_cmos_checksum,
+   op_show_layout,
+   op_write_cmos_dump,
+   op_read_cmos_dump,
+   op_show_cmos_hex_dump,
+   op_show_cmos_dumpfile
+ };
+
+static const hexdump_format_t cmos_dump_format =
+ { 16, 2, "", " | ", " ", " | ", '.', NULL };
+
+/****************************************************************************
+ * main
+ ****************************************************************************/
+int main (int argc, char *argv[])
+ { cmos_layout_get_fn_t fn;
+
+   parse_nvramtool_args(argc, argv);
+
+   if (nvramtool_op_modifiers[NVRAMTOOL_MOD_USE_CMOS_LAYOUT_FILE].found)
+    { set_layout_filename(
+            nvramtool_op_modifiers[NVRAMTOOL_MOD_USE_CMOS_LAYOUT_FILE].param);
+      fn = get_layout_from_file;
+    }
+   else
+      fn = get_layout_from_cmos_table;
+
+   register_cmos_layout_get_fn(fn);
+   op_fns[nvramtool_op.op]();
+   return 0;
+ }
+
+/****************************************************************************
+ * op_show_version
+ *
+ * -v
+ *
+ * Show version information for this program.
+ ****************************************************************************/
+static void op_show_version (void)
+ { printf("This is %s version %s.\n", prog_name, prog_version); }
+
+/****************************************************************************
+ * op_show_usage
+ *
+ * -h
+ *
+ * Show a usage message for this program.
+ ****************************************************************************/
+static void op_show_usage (void)
+ { usage(stdout); }
+
+/****************************************************************************
+ * op_lbtable_show_info
+ *
+ * -l [ARG]
+ *
+ * If ARG is present, show coreboot table information specified by ARG.
+ * Else show all possible values for ARG.
+ ****************************************************************************/
+static void op_lbtable_show_info (void)
+ { if (nvramtool_op.param == NULL)
+      list_lbtable_choices();
+   else
+    { get_lbtable();
+      list_lbtable_item(nvramtool_op.param);
+    }
+ }
+
+/****************************************************************************
+ * op_lbtable_dump
+ *
+ * -d
+ *
+ * Do low-level dump of coreboot table.
+ ****************************************************************************/
+static void op_lbtable_dump (void)
+ { get_lbtable();
+   dump_lbtable();
+ }
+
+/****************************************************************************
+ * op_show_param_values
+ *
+ * -e NAME option
+ *
+ * Show all possible values for parameter NAME.
+ ****************************************************************************/
+static void op_show_param_values (void)
+ { get_cmos_layout();
+   list_param_enums(nvramtool_op.param);
+ }
+
+/****************************************************************************
+ * op_cmos_show_one_param
+ *
+ * [-n] -r NAME
+ *
+ * Show parameter NAME.  If -n is specified, show value only.  Else show name
+ * and value.
+ ****************************************************************************/
+static void op_cmos_show_one_param (void)
+ { int result;
+
+   get_cmos_layout();
+   result = list_one_param(nvramtool_op.param,
+                  !nvramtool_op_modifiers[NVRAMTOOL_MOD_SHOW_VALUE_ONLY].found);
+   cmos_checksum_verify();
+
+   if (result)
+      exit(1);
+ }
+
+/****************************************************************************
+ * op_cmos_show_all_params
+ *
+ * -a
+ *
+ * Show names and values for all parameters.
+ ****************************************************************************/
+static void op_cmos_show_all_params (void)
+ { int result;
+
+   get_cmos_layout();
+   result = list_all_params();
+   cmos_checksum_verify();
+
+   if (result)
+      exit(1);
+ }
+
+/****************************************************************************
+ * op_cmos_set_one_param
+ *
+ * -w NAME=VALUE
+ *
+ * Set parameter NAME to VALUE.
+ ****************************************************************************/
+static void op_cmos_set_one_param (void)
+ { const char *name, *value;
+
+   get_cmos_layout();
+
+   /* Separate 'NAME=VALUE' syntax into two strings representing NAME and
+    * VALUE.
+    */
+   parse_assignment(nvramtool_op.param, &name, &value);
+
+   set_one_param(name, value);
+ }
+
+/****************************************************************************
+ * op_cmos_set_params_stdin
+ *
+ * -i
+ *
+ * Set parameters according to standard input.
+ ****************************************************************************/
+static void op_cmos_set_params_stdin (void)
+ { get_cmos_layout();
+   set_params(stdin);
+ }
+
+/****************************************************************************
+ * op_cmos_set_params_file
+ *
+ * -p INPUT_FILE
+ *
+ * Set parameters according to INPUT_FILE.
+ ****************************************************************************/
+static void op_cmos_set_params_file (void)
+ { FILE *f;
+
+   if ((f = fopen(nvramtool_op.param, "r")) == NULL)
+    { fprintf(stderr, "%s: Can not open file %s for reading: %s\n",
+              prog_name, nvramtool_op.param, strerror(errno));
+      exit(1);
+    }
+
+   get_cmos_layout();
+   set_params(f);
+   fclose(f);
+ }
+
+/****************************************************************************
+ * op_cmos_checksum
+ *
+ * -c [VALUE]
+ *
+ * If VALUE is present, set coreboot CMOS checksum to VALUE.  Else show
+ * checksum value.
+ ****************************************************************************/
+static void op_cmos_checksum (void)
+ { uint16_t checksum;
+
+   get_cmos_layout();
+
+   if (nvramtool_op.param == NULL)
+    { set_iopl(3);
+      checksum = cmos_checksum_read();
+      set_iopl(0);
+      printf("0x%x\n", checksum);
+    }
+   else
+    { checksum = convert_checksum_value(nvramtool_op.param);
+      set_iopl(3);
+      cmos_checksum_write(checksum);
+      set_iopl(0);
+    }
+ }
+
+/****************************************************************************
+ * op_show_layout
+ *
+ * -Y
+ *
+ * Write CMOS layout information to standard output.
+ ****************************************************************************/
+static void op_show_layout (void)
+ { get_cmos_layout();
+   write_cmos_layout(stdout);
+ }
+
+/****************************************************************************
+ * op_write_cmos_dump
+ *
+ * -b OUTPUT_FILE
+ *
+ * Write the contents of CMOS memory to a binary file.
+ ****************************************************************************/
+static void op_write_cmos_dump (void)
+ { unsigned char data[CMOS_SIZE];
+   FILE *f;
+
+   if ((f = fopen(nvramtool_op.param, "w")) == NULL)
+    { fprintf(stderr, "%s: Can not open file %s for writing: %s\n",
+              prog_name, nvramtool_op.param, strerror(errno));
+      exit(1);
+    }
+
+   set_iopl(3);
+   cmos_read_all(data);
+   set_iopl(0);
+
+   if (fwrite(data, 1, CMOS_SIZE, f) != CMOS_SIZE)
+    { fprintf(stderr, "%s: Error writing CMOS data to file %s: %s\n",
+              prog_name, nvramtool_op.param, strerror(errno));
+      exit(1);
+    }
+
+   fclose(f);
+ }
+
+/****************************************************************************
+ * op_read_cmos_dump
+ *
+ * -B INPUT_FILE
+ *
+ * Read binary data from a file and write the data to CMOS memory.
+ ****************************************************************************/
+static void op_read_cmos_dump (void)
+ { unsigned char data[CMOS_SIZE];
+   size_t nr_bytes;
+   FILE *f;
+
+   if ((f = fopen(nvramtool_op.param, "r")) == NULL)
+    { fprintf(stderr, "%s: Can not open file %s for reading: %s\n",
+              prog_name, nvramtool_op.param, strerror(errno));
+      exit(1);
+    }
+
+   if ((nr_bytes = fread(data, 1, CMOS_SIZE, f)) != CMOS_SIZE)
+    { fprintf(stderr, "%s: Error: Only able to read %d bytes of CMOS data "
+              "from file %s.  CMOS data is unchanged.\n", prog_name,
+              (int) nr_bytes, nvramtool_op.param);
+      exit(1);
+    }
+
+   fclose(f);
+   set_iopl(3);
+   cmos_write_all(data);
+   set_iopl(0);
+ }
+
+/****************************************************************************
+ * op_show_cmos_hex_dump
+ *
+ * -x
+ *
+ * Write a hex dump of CMOS memory to standard output.
+ ****************************************************************************/
+static void op_show_cmos_hex_dump (void)
+ { unsigned char data[CMOS_SIZE];
+
+   set_iopl(3);
+   cmos_read_all(data);
+   set_iopl(0);
+   hexdump(data, CMOS_SIZE, 0, stdout, &cmos_dump_format);
+ }
+
+/****************************************************************************
+ * op_show_cmos_dumpfile
+ *
+ * -X DUMP_FILE
+ *
+ * Read binary data from a file (presumably a CMOS dump file) and display a
+ * hex dump of the CMOS data from the file.
+ ****************************************************************************/
+static void op_show_cmos_dumpfile (void)
+ { unsigned char data[CMOS_SIZE];
+   size_t nr_bytes;
+   FILE *f;
+
+   if ((f = fopen(nvramtool_op.param, "r")) == NULL)
+    { fprintf(stderr, "%s: Can not open file %s for reading: %s\n",
+              prog_name, nvramtool_op.param, strerror(errno));
+      exit(1);
+    }
+
+   nr_bytes = fread(data, 1, CMOS_SIZE, f);
+   fclose(f);
+   hexdump(data, nr_bytes, 0, stdout, &cmos_dump_format);
+ }
+
+/****************************************************************************
+ * list_one_param
+ *
+ * Attempt to list one CMOS parameter given by 'name'.  'show_name' is a
+ * boolean value indicating whether the parameter name should be displayed
+ * along with its value.  Return 1 if error was encountered.  Else return OK.
+ ****************************************************************************/
+static int list_one_param (const char name[], int show_name)
+ { const cmos_entry_t *e;
+
+   if (is_checksum_name(name) || ((e = find_cmos_entry(name)) == NULL))
+    { fprintf(stderr, "%s: CMOS parameter %s not found.\n", prog_name, name);
+      exit(1);
+    }
+
+   if (e->config == CMOS_ENTRY_RESERVED)
+    { fprintf(stderr, "%s: Parameter %s is reserved.\n", prog_name, name);
+      exit(1);
+    }
+
+   return (list_cmos_entry(e, show_name) != 0);
+ }
+
+/****************************************************************************
+ * list_all_params
+ *
+ * Attempt to list all CMOS parameters.  Return 1 if error was encountered.
+ * Else return OK.
+ ****************************************************************************/
+static int list_all_params (void)
+ { const cmos_entry_t *e;
+   int result;
+
+   result = OK;
+
+   for (e = first_cmos_entry(); e != NULL; e = next_cmos_entry(e))
+    { if ((e->config == CMOS_ENTRY_RESERVED) || is_checksum_name(e->name))
+         continue;
+
+      if (list_cmos_entry(e, TRUE))
+         result = 1;
+    }
+
+   return result;
+ }
+
+/****************************************************************************
+ * list_param_enums
+ *
+ * List all possible values for CMOS parameter given by 'name'.
+ ****************************************************************************/
+static void list_param_enums (const char name[])
+ { const cmos_entry_t *e;
+   const cmos_enum_t *p;
+
+   if (is_checksum_name(name) || (e = find_cmos_entry(name)) == NULL)
+    { fprintf(stderr, "%s: CMOS parameter %s not found.\n", prog_name, name);
+      exit(1);
+    }
+
+   switch (e->config)
+    { case CMOS_ENTRY_ENUM:
+         for (p = first_cmos_enum_id(e->config_id);
+              p != NULL;
+              p = next_cmos_enum_id(p))
+            printf("%s\n", p->text);
+
+         break;
+
+      case CMOS_ENTRY_HEX:
+         printf("Parameter %s requires a %u-bit unsigned integer.\n", name,
+                e->length);
+         break;
+
+      case CMOS_ENTRY_RESERVED:
+         printf("Parameter %s is reserved.\n", name);
+         break;
+
+      default:
+         BUG();
+    }
+ }
+
+/****************************************************************************
+ * set_one_param
+ *
+ * Set the CMOS parameter given by 'name' to 'value'.  The 'name' parameter
+ * is case-sensitive.  If we are setting an enum parameter, then 'value' is
+ * interpreted as a case-sensitive string that must match the option name
+ * exactly.  If we are setting a 'hex' parameter, then 'value' is treated as
+ * a string representation of an unsigned integer that may be specified in
+ * decimal, hex, or octal.
+ ****************************************************************************/
+static void set_one_param (const char name[], const char value[])
+ { const cmos_entry_t *e;
+   unsigned long long n;
+
+   if (is_checksum_name(name) || (e = find_cmos_entry(name)) == NULL)
+    { fprintf(stderr, "%s: CMOS parameter %s not found.", prog_name, name);
+      exit(1);
+    }
+
+   switch (prepare_cmos_write(e, value, &n))
+    { case OK:
+         break;
+
+      case CMOS_OP_BAD_ENUM_VALUE:
+         fprintf(stderr, "%s: Bad value for parameter %s.", prog_name, name);
+         goto fail;
+
+      case CMOS_OP_NEGATIVE_INT:
+         fprintf(stderr,
+                 "%s: This program does not support assignment of negative "
+                 "numbers to coreboot parameters.", prog_name);
+         goto fail;
+
+      case CMOS_OP_INVALID_INT:
+         fprintf(stderr, "%s: %s is not a valid integer.", prog_name, value);
+         goto fail;
+
+      case CMOS_OP_RESERVED:
+         fprintf(stderr,
+                 "%s: Can not modify reserved coreboot parameter %s.",
+                 prog_name, name);
+         goto fail;
+
+      case CMOS_OP_VALUE_TOO_WIDE:
+         fprintf(stderr,
+                 "%s: Can not write value %s to CMOS parameter %s that is "
+                 "only %d bits wide.", prog_name, value, name, e->length);
+         goto fail;
+
+      case CMOS_OP_NO_MATCHING_ENUM:
+         fprintf(stderr,
+                 "%s: coreboot parameter %s has no matching enums.",
+                 prog_name, name);
+         goto fail;
+
+      case CMOS_AREA_OUT_OF_RANGE:
+         fprintf(stderr,
+                 "%s: The CMOS area specified by the layout info for "
+                 "coreboot parameter %s is out of range.", prog_name, name);
+         goto fail;
+
+      case CMOS_AREA_OVERLAPS_RTC:
+         fprintf(stderr,
+                 "%s: The CMOS area specified by the layout info for "
+                 "coreboot parameter %s overlaps the realtime clock area.",
+                 prog_name, name);
+         goto fail;
+
+      case CMOS_AREA_TOO_WIDE:
+         fprintf(stderr,
+                 "%s: The CMOS area specified by the layout info for "
+                 "coreboot parameter %s is too wide.",
+                 prog_name, name);
+         goto fail;
+
+      default:
+         fprintf(stderr,
+                 "%s: Unknown error encountered while attempting to modify "
+                 "coreboot parameter %s.", prog_name, name);
+         goto fail;
+    }
+
+   /* write the value to nonvolatile RAM */
+   set_iopl(3);
+   cmos_write(e->bit, e->length, n);
+   cmos_checksum_write(cmos_checksum_compute());
+   set_iopl(0);
+   return;
+
+fail:
+   fprintf(stderr, "  CMOS write not performed.\n");
+   exit(1);
+ }
+
+/****************************************************************************
+ * set_params
+ *
+ * Set coreboot parameters according to the contents of file 'f'.
+ ****************************************************************************/
+static void set_params (FILE *f)
+ { /* First process the input file.  Then perform writes only if there were
+    * no problems processing the input.  Either all values will be written
+    * successfully or no values will be written.
+    */
+   do_cmos_writes(process_input_file(f));
+ }
+
+/****************************************************************************
+ * parse_assignment
+ *
+ * Parse the string 'arg' (which supposedly represents an assignment) into a
+ * NAME and a VALUE.  If 'arg' does not conform to the proper assignment
+ * syntax, exit with a usage message.  Otherwise, on return, 'arg' is broken
+ * into substrings representing NAME and VALUE, and *name and *value are set
+ * to point to these two substrings.
+ ****************************************************************************/
+static void parse_assignment (char arg[], const char **name,
+                              const char **value)
+ { static const size_t N_MATCHES = 4;
+   regmatch_t match[N_MATCHES];
+   regex_t assignment;
+
+   compile_reg_exprs(REG_EXTENDED | REG_NEWLINE, 1, assignment_regex,
+                     &assignment);
+
+   /* Does 'arg' conform to proper assignment syntax?  If not, exit with a
+    * usage message.
+    */
+   if (regexec(&assignment, arg, N_MATCHES, match, 0))
+      usage(stderr);
+
+   /* Ok, we found a valid assignment.  Break it into two strings
+    * representing NAME and VALUE.
+    */
+   arg[match[1].rm_eo] = '\0';
+   arg[match[2].rm_eo] = '\0';
+   *name = &arg[match[1].rm_so];
+   *value = &arg[match[2].rm_so];
+
+   free_reg_exprs(1, &assignment);
+ }
+
+/****************************************************************************
+ * list_cmos_entry
+ *
+ * Attempt to list the CMOS entry represented by 'e'.  'show_name' is a
+ * boolean value indicating whether the parameter name should be displayed
+ * along with its value.  On success, return OK.  On error, print an error
+ * message and return 1.
+ ****************************************************************************/
+static int list_cmos_entry (const cmos_entry_t *e, int show_name)
+ { const cmos_enum_t *p;
+   unsigned long long value;
+
+   /* sanity check CMOS entry */
+   switch (prepare_cmos_read(e))
+    { case OK:
+         break;
+
+      case CMOS_OP_RESERVED:
+         BUG();
+
+      case CMOS_AREA_OUT_OF_RANGE:
+         fprintf(stderr, "%s: Can not read coreboot parameter %s because "
+                 "layout info specifies out of range CMOS area.\n", prog_name,
+                 e->name);
+         return 1;
+
+      case CMOS_AREA_OVERLAPS_RTC:
+         fprintf(stderr, "%s: Can not read coreboot parameter %s because "
+                 "layout info specifies CMOS area that overlaps realtime "
+                 "clock area.\n", prog_name, e->name);
+         return 1;
+
+      case CMOS_AREA_TOO_WIDE:
+         fprintf(stderr, "%s: Can not read coreboot parameter %s because "
+                 "layout info specifies CMOS area that is too wide.\n",
+                 prog_name, e->name);
+         return 1;
+
+      default:
+         fprintf(stderr, "%s: Unknown error encountered while attempting to "
+                 "read coreboot parameter %s\n", prog_name, e->name);
+         return 1;
+    }
+
+   /* read the value from CMOS */
+   set_iopl(3);
+   value = cmos_read(e->bit, e->length);
+   set_iopl(0);
+
+   /* display the value */
+   switch (e->config)
+    { case CMOS_ENTRY_ENUM:
+         if ((p = find_cmos_enum(e->config_id, value)) == NULL)
+          { if (show_name)
+               printf("# Bad value -> %s = 0x%llx\n", e->name, value);
+            else
+               printf("Bad value -> 0x%llx\n", value);
+          }
+         else
+          { if (show_name)
+               printf("%s = %s\n", e->name, p->text);
+            else
+               printf("%s\n", p->text);
+          }
+
+         break;
+
+      case CMOS_ENTRY_HEX:
+         if (show_name)
+            printf("%s = 0x%llx\n", e->name, value);
+         else
+            printf("0x%llx\n", value);
+
+         break;
+
+      case CMOS_ENTRY_RESERVED:
+      default:
+         BUG();
+    }
+
+   return OK;
+ }
+
+/****************************************************************************
+ * convert_checksum_value
+ *
+ * 'value' is the string representation of a checksum value that the user
+ * wishes to set using the -c option.  Convert the string to a 16-bit
+ * unsigned integer and return the result.  Exit with an error message if
+ * 'value' is invalid.
+ ****************************************************************************/
+static uint16_t convert_checksum_value (const char value[])
+ { unsigned long n;
+   const char *p;
+   uint16_t result;
+   int negative;
+
+   for (p = value; isspace(*p); p++);
+
+   negative = (*p == '-');
+   n = strtoul(value, (char **) &p, 0);
+
+   if (*p)
+    { fprintf(stderr, "%s: Checksum value %s is not a valid integer.\n",
+              prog_name, value);
+      exit(1);
+    }
+
+   if (negative)
+    { fprintf(stderr,
+              "%s: Checksum must be an unsigned integer.\n", prog_name);
+      exit(1);
+    }
+
+   result = (uint16_t) n;
+
+   if (result != n)
+    { fprintf(stderr,
+              "%s: Checksum value must fit within 16 bits.\n", prog_name);
+      exit(1);
+    }
+
+   return result;
+ }

Copied: trunk/util/lxbios/nvramtool.spec (from rev 3122, trunk/util/lxbios/lxbios.spec)
===================================================================
--- trunk/util/lxbios/nvramtool.spec	                        (rev 0)
+++ trunk/util/lxbios/nvramtool.spec	2008-03-01 19:07:46 UTC (rev 3123)
@@ -0,0 +1,50 @@
+##
+# $Id$
+##
+
+Name:    nvramtool
+Version: 2.0.1
+Release: 0
+
+Summary: coreboot utility program
+Group:   System Environment/Base
+License: GPL
+Provides: nvramtool
+
+BuildRoot: %{_tmppath}/%{name}-%{version}
+
+Source0: %{name}-%{version}.tgz
+
+%description
+nvramtool is a utility for reading/writing coreboot parameters and displaying
+information from the coreboot table.
+
+At boot time, coreboot places a table (known as the coreboot table) in low
+physical memory.  The contents of this table are preserved even after
+coreboot transfers control to the kernel and the kernel initializes itself.
+The coreboot table contains various system information such as the type of
+mainboard in use.  It also specifies locations in the CMOS (nonvolatile RAM)
+where the coreboot parameters are stored.
+
+%prep
+%setup -n %{name}-%{version}
+
+%build
+make
+
+%install
+rm -rf "$RPM_BUILD_ROOT"
+mkdir -p "$RPM_BUILD_ROOT/usr/bin"
+mkdir -p "$RPM_BUILD_ROOT/usr/man/man1"
+cp nvramtool "$RPM_BUILD_ROOT/usr/bin"
+cp nvramtool.1.gz $RPM_BUILD_ROOT/usr/man/man1
+
+%clean
+rm -rf "$RPM_BUILD_ROOT"
+
+%files
+%defattr(-,root,root,0755)
+%doc ChangeLog README
+%doc README
+/usr/bin/nvramtool
+/usr/man/man1/nvramtool.1.gz




From svn at coreboot.org  Sat Mar  1 20:09:02 2008
From: svn at coreboot.org (svn at coreboot.org)
Date: Sat,  1 Mar 2008 20:09:02 +0100
Subject: [coreboot] r3124 - trunk/util
Message-ID: <mailman.1241.1355071270.16123.coreboot@coreboot.org>

Author: uwe
Date: 2008-03-01 20:09:01 +0100 (Sat, 01 Mar 2008)
New Revision: 3124

Added:
   trunk/util/nvramtool/
Removed:
   trunk/util/lxbios/
Log:
Rename lxbios to nvramtool, step 3 (rename directory).

Signed-off-by: Uwe Hermann <uwe at hermann-uwe.de>
Acked-by: Stefan Reinauer <stepan at coresystems.de>






From svn at coreboot.org  Sat Mar  1 20:12:19 2008
From: svn at coreboot.org (svn at coreboot.org)
Date: Sat,  1 Mar 2008 20:12:19 +0100
Subject: [coreboot] r627 - coreboot-v3/util
Message-ID: <mailman.1242.1355071270.16123.coreboot@coreboot.org>

Author: uwe
Date: 2008-03-01 20:12:19 +0100 (Sat, 01 Mar 2008)
New Revision: 627

Modified:
   coreboot-v3/util/
Log:
Adapt v3 svn:externals to lxbios -> nvramtool rename.

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




Property changes on: coreboot-v3/util
___________________________________________________________________
Modified: svn:externals
   - flashrom svn://linuxbios.org/repos/trunk/util/flashrom
lxbios svn://linuxbios.org/repos/trunk/util/lxbios
superiotool svn://linuxbios.org/repos/trunk/util/superiotool

   + flashrom svn://linuxbios.org/repos/trunk/util/flashrom
nvramtool svn://linuxbios.org/repos/trunk/util/nvramtool
superiotool svn://linuxbios.org/repos/trunk/util/superiotool





From svn at coreboot.org  Sat Mar  1 20:13:51 2008
From: svn at coreboot.org (svn at coreboot.org)
Date: Sat,  1 Mar 2008 20:13:51 +0100
Subject: [coreboot] r3125 - trunk/coreboot-v2/util
Message-ID: <mailman.1243.1355071270.16123.coreboot@coreboot.org>

Author: uwe
Date: 2008-03-01 20:13:50 +0100 (Sat, 01 Mar 2008)
New Revision: 3125

Modified:
   trunk/coreboot-v2/util/
Log:
Adapt v2 svn:externals for lxbios -> nvramtool rename.

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




Property changes on: trunk/coreboot-v2/util
___________________________________________________________________
Modified: svn:externals
   - flashrom svn://coreboot.org/repos/trunk/util/flashrom
lxbios svn://coreboot.org/repos/trunk/util/lxbios
superiotool svn://coreboot.org/repos/trunk/util/superiotool
getpir svn://coreboot.org/repos/trunk/util/getpir
mptable svn://coreboot.org/repos/trunk/util/mptable

   + flashrom svn://coreboot.org/repos/trunk/util/flashrom
nvramtool svn://coreboot.org/repos/trunk/util/nvramtool
superiotool svn://coreboot.org/repos/trunk/util/superiotool
getpir svn://coreboot.org/repos/trunk/util/getpir
mptable svn://coreboot.org/repos/trunk/util/mptable





From uwe at hermann-uwe.de  Sat Mar  1 20:17:23 2008
From: uwe at hermann-uwe.de (Uwe Hermann)
Date: Sat, 1 Mar 2008 20:17:23 +0100
Subject: [coreboot] [PATCH] Rename lxbios to nvramtool
In-Reply-To: <20080126214023.GB20664@coresystems.de>
References: <20080125153659.GA22420@greenwood>
	<20080126214023.GB20664@coresystems.de>
Message-ID: <20080301191723.GA25090@greenwood>

On Sat, Jan 26, 2008 at 10:40:23PM +0100, Stefan Reinauer wrote:
> I agree with CDH that we need to be careful with what we rename, but
> this is the one thing that directly exposes all of coreboot to the user.
> And some of the payloads, too. So even before lxbios was a
> not-so-fitting name. Let's do it.
> 
> Acked-by: Stefan Reinauer <stepan at coresystems.de>

Thanks, r3122 et al.


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



From c-d.hailfinger.devel.2006 at gmx.net  Sat Mar  1 20:26:12 2008
From: c-d.hailfinger.devel.2006 at gmx.net (Carl-Daniel Hailfinger)
Date: Sat, 01 Mar 2008 20:26:12 +0100
Subject: [coreboot] [PATCH] v3: convert stage2 and initram makefile rules
 from object to source files
Message-ID: <47C9ADD4.2070009@gmx.net>

Convert stage2 and initram makefile rules from object to source files. 
This creates a clearer distinction between source files in the source 
tree we want to have compiled and indirectly created object/source files 
in the object tree.

It also will make enable us to move to whole-program 
optimization/compilation which should yield substantial size savings.
Then again, we may be able to do that without the makefile conversion as 
well.

This is a RFC, not to be applied immediately.

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

Index: LinuxBIOSv3-makefilerewrite/southbridge/amd/cs5536/Makefile
===================================================================
--- LinuxBIOSv3-makefilerewrite/southbridge/amd/cs5536/Makefile	(Revision 626)
+++ LinuxBIOSv3-makefilerewrite/southbridge/amd/cs5536/Makefile	(Arbeitskopie)
@@ -21,7 +21,7 @@
 
 ifeq ($(CONFIG_SOUTHBRIDGE_AMD_CS5536),y)
 
-STAGE2_CHIPSET_OBJ += $(obj)/southbridge/amd/cs5536/cs5536.o
+STAGE2_CHIPSET_SRC += $(src)/southbridge/amd/cs5536/cs5536.c
 
 STAGE0_CHIPSET_OBJ += $(obj)/southbridge/amd/cs5536/stage1.o
 
Index: LinuxBIOSv3-makefilerewrite/southbridge/intel/i82371eb/Makefile
===================================================================
--- LinuxBIOSv3-makefilerewrite/southbridge/intel/i82371eb/Makefile	(Revision 626)
+++ LinuxBIOSv3-makefilerewrite/southbridge/intel/i82371eb/Makefile	(Arbeitskopie)
@@ -20,6 +20,6 @@
 
 ifeq ($(CONFIG_SOUTHBRIDGE_INTEL_I82371EB),y)
 
-STAGE2_CHIPSET_OBJ += $(obj)/southbridge/intel/i82371eb/i82371eb.o
+STAGE2_CHIPSET_SRC += $(src)/southbridge/intel/i82371eb/i82371eb.c
 
 endif
Index: LinuxBIOSv3-makefilerewrite/superio/winbond/w83627hf/Makefile
===================================================================
--- LinuxBIOSv3-makefilerewrite/superio/winbond/w83627hf/Makefile	(Revision 626)
+++ LinuxBIOSv3-makefilerewrite/superio/winbond/w83627hf/Makefile	(Arbeitskopie)
@@ -25,6 +25,6 @@
 STAGE0_CHIPSET_OBJ += $(obj)/device/pnp_raw.o
 
 # Always add to variables, as there could be more than one Super I/O.
-STAGE2_CHIPSET_OBJ += $(obj)/superio/winbond/w83627hf/superio.o
+STAGE2_CHIPSET_SRC += $(src)/superio/winbond/w83627hf/superio.c
 
 endif
Index: LinuxBIOSv3-makefilerewrite/superio/fintek/f71805f/Makefile
===================================================================
--- LinuxBIOSv3-makefilerewrite/superio/fintek/f71805f/Makefile	(Revision 626)
+++ LinuxBIOSv3-makefilerewrite/superio/fintek/f71805f/Makefile	(Arbeitskopie)
@@ -24,6 +24,6 @@
 STAGE0_CHIPSET_OBJ += $(obj)/device/pnp_raw.o
 
 # Always add to variables, as there could be more than one Super I/O.
-STAGE2_CHIPSET_OBJ += $(obj)/superio/fintek/f71805f/superio.o
+STAGE2_CHIPSET_SRC += $(src)/superio/fintek/f71805f/superio.c
 
 endif
Index: LinuxBIOSv3-makefilerewrite/mainboard/adl/msm800sev/Makefile
===================================================================
--- LinuxBIOSv3-makefilerewrite/mainboard/adl/msm800sev/Makefile	(Revision 626)
+++ LinuxBIOSv3-makefilerewrite/mainboard/adl/msm800sev/Makefile	(Arbeitskopie)
@@ -21,12 +21,12 @@
 
 STAGE0_MAINBOARD_OBJ := $(obj)/mainboard/$(MAINBOARDDIR)/stage1.o
 
-INITRAM_OBJ =   $(src)/mainboard/$(MAINBOARDDIR)/initram.c \
+INITRAM_SRC =   $(src)/mainboard/$(MAINBOARDDIR)/initram.c \
 		$(src)/northbridge/amd/geodelx/raminit.c \
 		$(src)/southbridge/amd/cs5536/smbus_initram.c \
 		$(src)/arch/x86/geodelx/geodelx.c
 
-STAGE2_MAINBOARD_OBJ =
+STAGE2_MAINBOARD_SRC =
 
 $(obj)/coreboot.vpd:
 	$(Q)printf "  BUILD   DUMMY VPD\n"
Index: LinuxBIOSv3-makefilerewrite/mainboard/amd/norwich/Makefile
===================================================================
--- LinuxBIOSv3-makefilerewrite/mainboard/amd/norwich/Makefile	(Revision 626)
+++ LinuxBIOSv3-makefilerewrite/mainboard/amd/norwich/Makefile	(Arbeitskopie)
@@ -21,12 +21,12 @@
 
 STAGE0_MAINBOARD_OBJ := $(obj)/mainboard/$(MAINBOARDDIR)/stage1.o
 
-INITRAM_OBJ =   $(src)/mainboard/$(MAINBOARDDIR)/initram.c \
+INITRAM_SRC =   $(src)/mainboard/$(MAINBOARDDIR)/initram.c \
 		$(src)/northbridge/amd/geodelx/raminit.c \
 		$(src)/southbridge/amd/cs5536/smbus_initram.c \
 		$(src)/arch/x86/geodelx/geodelx.c
 
-STAGE2_MAINBOARD_OBJ = irq_tables.o
+STAGE2_MAINBOARD_SRC = irq_tables.c
 
 $(obj)/coreboot.vpd:
 	$(Q)printf "  BUILD   DUMMY VPD\n"
Index: LinuxBIOSv3-makefilerewrite/mainboard/artecgroup/dbe61/Makefile
===================================================================
--- LinuxBIOSv3-makefilerewrite/mainboard/artecgroup/dbe61/Makefile	(Revision 626)
+++ LinuxBIOSv3-makefilerewrite/mainboard/artecgroup/dbe61/Makefile	(Arbeitskopie)
@@ -21,11 +21,11 @@
 
 STAGE0_MAINBOARD_OBJ := $(obj)/mainboard/$(MAINBOARDDIR)/stage1.o
 
-INITRAM_OBJ =   $(src)/mainboard/$(MAINBOARDDIR)/initram.c \
+INITRAM_SRC =   $(src)/mainboard/$(MAINBOARDDIR)/initram.c \
 		$(src)/northbridge/amd/geodelx/raminit.c \
 		$(src)/arch/x86/geodelx/geodelx.c
 
-STAGE2_MAINBOARD_OBJ = 
+STAGE2_MAINBOARD_SRC = 
 
 $(obj)/coreboot.vpd:
 	$(Q)printf "  BUILD   DUMMY VPD\n"
Index: LinuxBIOSv3-makefilerewrite/mainboard/artecgroup/dbe62/Makefile
===================================================================
--- LinuxBIOSv3-makefilerewrite/mainboard/artecgroup/dbe62/Makefile	(Revision 626)
+++ LinuxBIOSv3-makefilerewrite/mainboard/artecgroup/dbe62/Makefile	(Arbeitskopie)
@@ -21,11 +21,11 @@
 
 STAGE0_MAINBOARD_OBJ := $(obj)/mainboard/$(MAINBOARDDIR)/stage1.o
 
-INITRAM_OBJ =   $(src)/mainboard/$(MAINBOARDDIR)/initram.c \
+INITRAM_SRC =   $(src)/mainboard/$(MAINBOARDDIR)/initram.c \
 		$(src)/northbridge/amd/geodelx/raminit.c \
 		$(src)/arch/x86/geodelx/geodelx.c
 
-STAGE2_MAINBOARD_OBJ = irq_tables.o 
+STAGE2_MAINBOARD_SRC = irq_tables.c 
 
 $(obj)/coreboot.vpd:
 	$(Q)printf "  BUILD   DUMMY VPD\n"
Index: LinuxBIOSv3-makefilerewrite/mainboard/pcengines/alix1c/Makefile
===================================================================
--- LinuxBIOSv3-makefilerewrite/mainboard/pcengines/alix1c/Makefile	(Revision 626)
+++ LinuxBIOSv3-makefilerewrite/mainboard/pcengines/alix1c/Makefile	(Arbeitskopie)
@@ -21,11 +21,11 @@
 
 STAGE0_MAINBOARD_OBJ := $(obj)/mainboard/$(MAINBOARDDIR)/stage1.o
 
-INITRAM_OBJ =   $(src)/mainboard/$(MAINBOARDDIR)/initram.c \
+INITRAM_SRC =   $(src)/mainboard/$(MAINBOARDDIR)/initram.c \
 		$(src)/northbridge/amd/geodelx/raminit.c \
 		$(src)/arch/x86/geodelx/geodelx.c
 
-STAGE2_MAINBOARD_OBJ = irq_tables.o 
+STAGE2_MAINBOARD_SRC = irq_tables.c 
 
 $(obj)/coreboot.vpd:
 	$(Q)printf "  BUILD   DUMMY VPD\n"
Index: LinuxBIOSv3-makefilerewrite/mainboard/emulation/qemu-x86/Makefile
===================================================================
--- LinuxBIOSv3-makefilerewrite/mainboard/emulation/qemu-x86/Makefile	(Revision 626)
+++ LinuxBIOSv3-makefilerewrite/mainboard/emulation/qemu-x86/Makefile	(Arbeitskopie)
@@ -28,10 +28,10 @@
 # directory and is built from what was auto.c in v2.
 #
 
-INITRAM_OBJ = $(src)/mainboard/$(MAINBOARDDIR)/initram.c \
+INITRAM_SRC = $(src)/mainboard/$(MAINBOARDDIR)/initram.c \
 		$(src)/mainboard/$(MAINBOARDDIR)/initram_printktest.c
 
-STAGE2_MAINBOARD_OBJ = vga.o
+STAGE2_MAINBOARD_SRC = vga.c
 
 #
 # VPD or SIP ROM or... how does NVIDIA call it?
Index: LinuxBIOSv3-makefilerewrite/device/Makefile
===================================================================
--- LinuxBIOSv3-makefilerewrite/device/Makefile	(Revision 626)
+++ LinuxBIOSv3-makefilerewrite/device/Makefile	(Arbeitskopie)
@@ -24,6 +24,6 @@
 	$(Q)printf "  CC      $(subst $(shell pwd)/,,$(@))\n"
 	$(Q)$(CC) $(INITCFLAGS) -c $< -o $@
 
-STAGE2_DEVICE_OBJ = device.o device_util.o root_device.o \
-		    pci_device.o pci_ops.o pci_rom.o pnp_device.o pnp_raw.o
+STAGE2_DEVICE_SRC = device.c device_util.c root_device.c \
+		    pci_device.c pci_ops.c pci_rom.c pnp_device.c pnp_raw.c
 
Index: LinuxBIOSv3-makefilerewrite/northbridge/amd/geodelx/Makefile
===================================================================
--- LinuxBIOSv3-makefilerewrite/northbridge/amd/geodelx/Makefile	(Revision 626)
+++ LinuxBIOSv3-makefilerewrite/northbridge/amd/geodelx/Makefile	(Arbeitskopie)
@@ -21,9 +21,9 @@
 
 ifeq ($(CONFIG_NORTHBRIDGE_AMD_GEODELX),y)
 
-STAGE2_CHIPSET_OBJ += $(obj)/northbridge/amd/geodelx/geodelx.o \
-		      $(obj)/northbridge/amd/geodelx/vsmsetup.o \
-		      $(obj)/util/x86emu/vm86_gdt.o \
-		      $(obj)/northbridge/amd/geodelx/grphinit.o
+STAGE2_CHIPSET_SRC += $(src)/northbridge/amd/geodelx/geodelx.c \
+		      $(src)/northbridge/amd/geodelx/vsmsetup.c \
+		      $(src)/util/x86emu/vm86_gdt.c \
+		      $(src)/northbridge/amd/geodelx/grphinit.c
 
 endif
Index: LinuxBIOSv3-makefilerewrite/northbridge/intel/i440bxemulation/Makefile
===================================================================
--- LinuxBIOSv3-makefilerewrite/northbridge/intel/i440bxemulation/Makefile	(Revision 626)
+++ LinuxBIOSv3-makefilerewrite/northbridge/intel/i440bxemulation/Makefile	(Arbeitskopie)
@@ -21,6 +21,6 @@
 
 ifeq ($(CONFIG_NORTHBRIDGE_INTEL_I440BXEMULATION),y)
 
-STAGE2_CHIPSET_OBJ += $(obj)/northbridge/intel/i440bxemulation/i440bx.o
+STAGE2_CHIPSET_SRC += $(src)/northbridge/intel/i440bxemulation/i440bx.c
 
 endif
Index: LinuxBIOSv3-makefilerewrite/arch/x86/Makefile
===================================================================
--- LinuxBIOSv3-makefilerewrite/arch/x86/Makefile	(Revision 626)
+++ LinuxBIOSv3-makefilerewrite/arch/x86/Makefile	(Arbeitskopie)
@@ -179,27 +179,32 @@
 # TODO: This should be compressed with the default compressor.
 #
 
-STAGE2_LIB_OBJ       = stage2.o clog2.o mem.o tables.o delay.o \
-		       compute_ip_checksum.o string.o
+STAGE2_LIB_SRC       = stage2.c clog2.c mem.c tables.c delay.c \
+		       compute_ip_checksum.c string.c
 
-STAGE2_ARCH_X86_OBJ  = archtables.o coreboot_table.o udelay_io.o
-STAGE2_ARCH_X86_OBJ += pci_ops_auto.o pci_ops_conf1.o pci_ops_conf2.o
-STAGE2_ARCH_X86_OBJ += keyboard.o i8259.o isa-dma.o
+STAGE2_ARCH_X86_SRC  = archtables.c coreboot_table.c udelay_io.c
+STAGE2_ARCH_X86_SRC += pci_ops_auto.c pci_ops_conf1.c pci_ops_conf2.c
+STAGE2_ARCH_X86_SRC += keyboard.c i8259.c isa-dma.c
 
 ifeq ($(CONFIG_PIRQ_TABLE),y)
-STAGE2_ARCH_X86_OBJ += pirq_routing.o
+STAGE2_ARCH_X86_SRC += pirq_routing.c
 endif
 
 STAGE2_DYNAMIC_OBJ   = statictree.o
 
-STAGE2_OBJ := $(patsubst %,$(obj)/lib/%,$(STAGE2_LIB_OBJ)) \
-	      $(patsubst %,$(obj)/arch/x86/%,$(STAGE2_ARCH_X86_OBJ)) \
-	      $(patsubst %,$(obj)/device/%,$(STAGE2_DEVICE_OBJ)) \
-	      $(patsubst %,$(obj)/mainboard/$(MAINBOARDDIR)/%,$(STAGE2_MAINBOARD_OBJ)) \
-	      $(patsubst %,$(obj)/mainboard/$(MAINBOARDDIR)/%,$(STAGE2_DYNAMIC_OBJ))
+STAGE2_SRC := $(patsubst %,$(src)/lib/%,$(STAGE2_LIB_SRC)) \
+	      $(patsubst %,$(src)/arch/x86/%,$(STAGE2_ARCH_X86_SRC)) \
+	      $(patsubst %,$(src)/device/%,$(STAGE2_DEVICE_SRC)) \
+	      $(patsubst %,$(src)/mainboard/$(MAINBOARDDIR)/%,$(STAGE2_MAINBOARD_SRC))
 
-STAGE2_OBJ += $(STAGE2_CHIPSET_OBJ)
+STAGE2_SRC += $(STAGE2_CHIPSET_SRC)
 
+STAGE2_OBJ := $(patsubst $(src)/%.c,$(obj)/%.o,$(STAGE2_SRC))
+
+# This one is special, but only due to slightly incorrect rules and dependencies.
+# Don't change the dependencies for now.
+STAGE2_OBJ += $(patsubst %,$(obj)/mainboard/$(MAINBOARDDIR)/%,$(STAGE2_DYNAMIC_OBJ))
+
 ifeq ($(CONFIG_PCI_OPTION_ROM_RUN),y)
 ifeq ($(CONFIG_PCI_OPTION_ROM_RUN_X86EMU),y)
 # x86emu wants libgcc
@@ -215,7 +220,7 @@
 
 STAGE2_OBJ_NEEDED = $(filter-out $(STAGE0_OBJ), $(STAGE2_OBJ))
 
-$(obj)/coreboot.stage2 $(obj)/coreboot.stage2.map: $(obj)/stage0.o $(STAGE2_OBJ_NEEDED)
+$(obj)/coreboot.stage2 $(obj)/coreboot.stage2.map: $(obj)/stage0.o $(STAGE2_OBJ_NEEDED) $(STAGE2_SRC)
 	$(Q)# leave a .o with full symbols in it for debugging.
 	$(Q)printf "  LD      $(subst $(shell pwd)/,,$(@))\n"
 	$(Q)$(LD) -R $(obj)/stage0.o -Ttext 0x2000 --entry=stage2 \
@@ -249,9 +254,9 @@
 	$(Q)printf "  AS      $(subst $(shell pwd)/,,$(@))\n"
 	$(Q)$(AS) $(obj)/arch/x86/stage0_asm.s -o $@
 
-$(obj)/coreboot.initram $(obj)/coreboot.initram.map: $(obj)/stage0.init $(obj)/stage0-prefixed.o $(INITRAM_OBJ)
+$(obj)/coreboot.initram $(obj)/coreboot.initram.map: $(obj)/stage0.init $(obj)/stage0-prefixed.o $(INITRAM_SRC)
 	$(Q)printf "  CC      $(subst $(shell pwd)/,,$(@)) (XIP)\n"
-	$(Q)$(CC) $(INITCFLAGS) -D_SHARED -fPIE -c -combine $(INITRAM_OBJ) -o $(obj)/coreboot.initram_partiallylinked.o
+	$(Q)$(CC) $(INITCFLAGS) -D_SHARED -fPIE -c -combine $(INITRAM_SRC) -o $(obj)/coreboot.initram_partiallylinked.o
 	$(Q)# initram links against stage0
 	$(Q)printf "  LD      $(subst $(shell pwd)/,,$(@))\n"
 	$(Q)$(LD) -Ttext 0 --entry main -N -R $(obj)/stage0-prefixed.o \


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




From c-d.hailfinger.devel.2006 at gmx.net  Sat Mar  1 20:36:49 2008
From: c-d.hailfinger.devel.2006 at gmx.net (Carl-Daniel Hailfinger)
Date: Sat, 01 Mar 2008 20:36:49 +0100
Subject: [coreboot] [PATCH] Rename lxbios to nvramtool
In-Reply-To: <20080301191723.GA25090@greenwood>
References: <20080125153659.GA22420@greenwood>	<20080126214023.GB20664@coresystems.de>
	<20080301191723.GA25090@greenwood>
Message-ID: <47C9B051.6060104@gmx.net>

On 01.03.2008 20:17, Uwe Hermann wrote:
> On Sat, Jan 26, 2008 at 10:40:23PM +0100, Stefan Reinauer wrote:
>   
>> I agree with CDH that we need to be careful with what we rename, but
>> this is the one thing that directly exposes all of coreboot to the user.
>> And some of the payloads, too. So even before lxbios was a
>> not-so-fitting name. Let's do it.
>>
>> Acked-by: Stefan Reinauer <stepan at coresystems.de>
>>     
>
> Thanks, r3122 et al.
>   

And it breaks when going back with "svn up" for any revision up to 626 
in v3.
Q.E.D.

compiler at p35:/sources/tmptrees/corebootv3-tmp3> svn up

Fetching external item into 'util/flashrom'
External at revision 3125.


Fetching external item into 'util/nvramtool'
External at revision 3125.


Fetching external item into 'util/superiotool'
External at revision 3125.

At revision 627.
compiler at p35:/sources/tmptrees/corebootv3-tmp3> svn up -r 626
 U   util

Fetching external item into 'util/flashrom'
Updated external to revision 3125.


Fetching external item into 'util/superiotool'
Updated external to revision 3125.


Fetching external item into 'util/lxbios'
svn: URL 'svn://linuxbios.org/repos/trunk/util/lxbios' doesn't exist



Regards,
Carl-Daniel

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




From corey.osgood at gmail.com  Sat Mar  1 21:00:38 2008
From: corey.osgood at gmail.com (Corey Osgood)
Date: Sat, 1 Mar 2008 15:00:38 -0500
Subject: [coreboot] [PATCH] Rename lxbios to nvramtool
In-Reply-To: <47C9B051.6060104@gmx.net>
References: <20080125153659.GA22420@greenwood>
	<20080126214023.GB20664@coresystems.de>
	<20080301191723.GA25090@greenwood> <47C9B051.6060104@gmx.net>
Message-ID: <dd3c80060803011200u7ea53a82l631309fedc12a3a2@mail.gmail.com>

On Sat, Mar 1, 2008 at 2:36 PM, Carl-Daniel Hailfinger <
c-d.hailfinger.devel.2006 at gmx.net> wrote:

> On 01.03.2008 20:17, Uwe Hermann wrote:
> > On Sat, Jan 26, 2008 at 10:40:23PM +0100, Stefan Reinauer wrote:
> >
> >> I agree with CDH that we need to be careful with what we rename, but
> >> this is the one thing that directly exposes all of coreboot to the
> user.
> >> And some of the payloads, too. So even before lxbios was a
> >> not-so-fitting name. Let's do it.
> >>
> >> Acked-by: Stefan Reinauer <stepan at coresystems.de>
> >>
> >
> > Thanks, r3122 et al.
> >
>
> And it breaks when going back with "svn up" for any revision up to 626
> in v3.


does svn up --ignore-externals work?

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

From info at coresystems.de  Sat Mar  1 21:01:37 2008
From: info at coresystems.de (coreboot information)
Date: Sat, 01 Mar 2008 21:01:37 +0100
Subject: [coreboot] r3121 build service
Message-ID: <E1JVXtp-0001Jd-UI@khepri.openbios.org>

Dear coreboot readers!

This is the automated build check service of coreboot.

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

Change Log:
Small coding style fixes and documentation updates (trivial).

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



Build Log:
Compilation of amd:serengeti_cheetah_fam10 is still broken
See the error log at http://qa.coreboot.org/log_buildbrd.php?revision=3121&device=serengeti_cheetah_fam10&vendor=amd


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

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

   Best regards,
     coreboot automatic build system





From corey.osgood at gmail.com  Sat Mar  1 21:18:34 2008
From: corey.osgood at gmail.com (Corey Osgood)
Date: Sat, 1 Mar 2008 15:18:34 -0500
Subject: [coreboot] GENFADT and GENDSDT
In-Reply-To: <47C97749.2070209@gmx.net>
References: <1201558563.3453.25.camel@urbez.site>
	<1204185304.8207.5.camel@Mobulus> <47C6A072.3080101@gmx.net>
	<47C6ECCC.2090803@gmx.net> <20080228202208.GC24000@greenwood>
	<47C71C45.3040808@gmx.net>
	<dd3c80060802282123h4510ebc4u1deb705ed377138e@mail.gmail.com>
	<47C859CC.9080504@gmx.net>
	<dd3c80060802292240l2e2e2c60j5505bb679e12ddc1@mail.gmail.com>
	<47C97749.2070209@gmx.net>
Message-ID: <dd3c80060803011218r1fcca587qa382f5edfcac9b5e@mail.gmail.com>

On Sat, Mar 1, 2008 at 10:33 AM, Carl-Daniel Hailfinger <
c-d.hailfinger.devel.2006 at gmx.net> wrote:

> On 01.03.2008 07:40, Corey Osgood wrote:
> > On Fri, Feb 29, 2008 at 2:15 PM, Carl-Daniel Hailfinger <
> > c-d.hailfinger.devel.2006 at gmx.net> wrote:
> >
> >
> >> Please note that iasl can't perform any of the functions of
> >> gendsdt
> >>
> >
> >
> > dumping the dsdt to a file, then iasl -d and iasl -tc will produce the
> same
> > thing, but with some sort of optimizations. Disabling the optimizations,
> > with -oa should produce exactly the same output as gendsdt, except for
> > whitespace, the copyright header, and some dsdt header info (compiler,
> etc).
> >
>
> Sorry, my bad, I didn't know that. Then I vote to drop gendsdt and
> require use of iasl (plus a sed script/whatever to modify the headers)
> instead. We need iasl anyway for the stuff Rudolf is working on.


I'll second that. If you want to make it happen, I'll ack it. I'd do it
myself, but I'm trying to get the cn700 back on track.

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

From c-d.hailfinger.devel.2006 at gmx.net  Sat Mar  1 21:39:21 2008
From: c-d.hailfinger.devel.2006 at gmx.net (Carl-Daniel Hailfinger)
Date: Sat, 01 Mar 2008 21:39:21 +0100
Subject: [coreboot] [PATCH] Rename lxbios to nvramtool
In-Reply-To: <dd3c80060803011200u7ea53a82l631309fedc12a3a2@mail.gmail.com>
References: <20080125153659.GA22420@greenwood>	
	<20080126214023.GB20664@coresystems.de>	
	<20080301191723.GA25090@greenwood> <47C9B051.6060104@gmx.net>
	<dd3c80060803011200u7ea53a82l631309fedc12a3a2@mail.gmail.com>
Message-ID: <47C9BEF9.5090701@gmx.net>

On 01.03.2008 21:00, Corey Osgood wrote:
> On Sat, Mar 1, 2008 at 2:36 PM, Carl-Daniel Hailfinger <
> c-d.hailfinger.devel.2006 at gmx.net> wrote:
>
>   
>> On 01.03.2008 20:17, Uwe Hermann wrote:
>>     
>>> On Sat, Jan 26, 2008 at 10:40:23PM +0100, Stefan Reinauer wrote:
>>>
>>>       
>>>> I agree with CDH that we need to be careful with what we rename, but
>>>> this is the one thing that directly exposes all of coreboot to the
>>>>         
>> user.
>>     
>>>> And some of the payloads, too. So even before lxbios was a
>>>> not-so-fitting name. Let's do it.
>>>>
>>>> Acked-by: Stefan Reinauer <stepan at coresystems.de>
>>>>
>>>>         
>>> Thanks, r3122 et al.
>>>
>>>       
>> And it breaks when going back with "svn up" for any revision up to 626
>> in v3.
>>     
>
> does svn up --ignore-externals work?
>   

Yes, it does. Thanks. Care to write something up in the wiki?

Regards,
Carl-Daniel

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




From info at coresystems.de  Sat Mar  1 22:07:36 2008
From: info at coresystems.de (coreboot information)
Date: Sat, 01 Mar 2008 22:07:36 +0100
Subject: [coreboot] r3122 build service
Message-ID: <E1JVYvg-0005XP-7E@khepri.openbios.org>

Dear coreboot readers!

This is the automated build check service of coreboot.

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

Change Log:
Rename lxbios to nvramtool.

This is step 1 in a three-step commit:

 1. Apply patch, commit.

 2. Rename some files:
    $ svn mv lxbios.c nvramtool.c
    $ svn mv lxbios.1 nvramtool.c
    $ svn mv lxbios.spec nvramtool.spec
    $ svn ci

 3. Rename lxbios directory:
    $ svn mv lxbios/ nvramtool/
    $ svn ci

Signed-off-by: Uwe Hermann <uwe at hermann-uwe.de>
Acked-by: Stefan Reinauer <stepan at coresystems.de>



Build Log:
Compilation of amd:serengeti_cheetah_fam10 is still broken
See the error log at http://qa.coreboot.org/log_buildbrd.php?revision=3122&device=serengeti_cheetah_fam10&vendor=amd


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

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

   Best regards,
     coreboot automatic build system





From svn at coreboot.org  Sat Mar  1 22:33:51 2008
From: svn at coreboot.org (svn at coreboot.org)
Date: Sat,  1 Mar 2008 22:33:51 +0100
Subject: [coreboot] r628 - in coreboot-v3: . mainboard/amd/norwich
	mainboard/artecgroup/dbe61 mainboard/artecgroup/dbe62
	mainboard/pcengines/alix1c southbridge/amd/cs5536
Message-ID: <mailman.1244.1355071270.16123.coreboot@coreboot.org>

Author: rminnich
Date: 2008-03-01 22:33:51 +0100 (Sat, 01 Mar 2008)
New Revision: 628

Added:
   coreboot-v3/mainboard/amd/norwich/irq_tables.h
   coreboot-v3/mainboard/artecgroup/dbe61/irq_tables.h
   coreboot-v3/mainboard/artecgroup/dbe62/irq_tables.h
   coreboot-v3/mainboard/pcengines/alix1c/irq_tables.h
Removed:
   coreboot-v3/mainboard/amd/norwich/irq_tables.c
   coreboot-v3/mainboard/artecgroup/dbe61/irq_tables.c
   coreboot-v3/mainboard/artecgroup/dbe62/irq_tables.c
   coreboot-v3/mainboard/pcengines/alix1c/irq_tables.c
Modified:
   coreboot-v3/Makefile
   coreboot-v3/mainboard/amd/norwich/Makefile
   coreboot-v3/mainboard/artecgroup/dbe62/Makefile
   coreboot-v3/mainboard/pcengines/alix1c/Makefile
   coreboot-v3/southbridge/amd/cs5536/Makefile
Log:
Factor out write_pirq_routing_table() for all GeodeLX targets.
Compile tested on norwich, alix1c and dbe62. msm800sev is not affected
and dbe61 is broken anyway.

svn is unable to create a valid patch for what I did, so I'll have to
commit this myself. To reproduce, perform the following commands, then
apply the patch:

svn mv mainboard/amd/norwich/irq_tables.c mainboard/amd/norwich/irq_tables.h
svn mv mainboard/pcengines/alix1c/irq_tables.c mainboard/pcengines/alix1c/irq_tables.h
svn mv mainboard/artecgroup/dbe61/irq_tables.c mainboard/artecgroup/dbe61/irq_tables.h
svn mv mainboard/artecgroup/dbe62/irq_tables.c mainboard/artecgroup/dbe62/irq_tables.h

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

tested on alix1c. Boots, USB, graphics, and ethernet all work.

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

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



Modified: coreboot-v3/Makefile
===================================================================
--- coreboot-v3/Makefile	2008-03-01 19:12:19 UTC (rev 627)
+++ coreboot-v3/Makefile	2008-03-01 21:33:51 UTC (rev 628)
@@ -85,6 +85,7 @@
 COREBOOTINCLUDE    :=   -I$(src) -Iinclude \
 			-I$(src)/include \
 			-I$(src)/include/arch/$(ARCH)/ \
+			-I$(src)/mainboard/$(MAINBOARDDIR)/ \
 			-include $(obj)/config.h \
 			-include $(obj)/build.h
 

Modified: coreboot-v3/mainboard/amd/norwich/Makefile
===================================================================
--- coreboot-v3/mainboard/amd/norwich/Makefile	2008-03-01 19:12:19 UTC (rev 627)
+++ coreboot-v3/mainboard/amd/norwich/Makefile	2008-03-01 21:33:51 UTC (rev 628)
@@ -26,7 +26,7 @@
 		$(src)/southbridge/amd/cs5536/smbus_initram.c \
 		$(src)/arch/x86/geodelx/geodelx.c
 
-STAGE2_MAINBOARD_OBJ = irq_tables.o
+STAGE2_MAINBOARD_OBJ = 
 
 $(obj)/coreboot.vpd:
 	$(Q)printf "  BUILD   DUMMY VPD\n"

Deleted: coreboot-v3/mainboard/amd/norwich/irq_tables.c
===================================================================
--- coreboot-v3/mainboard/amd/norwich/irq_tables.c	2008-03-01 19:12:19 UTC (rev 627)
+++ coreboot-v3/mainboard/amd/norwich/irq_tables.c	2008-03-01 21:33:51 UTC (rev 628)
@@ -1,141 +0,0 @@
-/*
-* This file is part of the coreboot project.
-*
-* Copyright (C) 2007 Advanced Micro Devices, Inc.
-*
-* This program is free software; you can redistribute it and/or modify
-* it under the terms of the GNU General Public License version 2 as
-* published by the Free Software Foundation.
-*
-* 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 <types.h>
-#include <lib.h>
-#include <console.h>
-#include <device/device.h>
-#include <device/pci.h>
-#include <string.h>
-#include <msr.h>
-#include <io.h>
-#include <pirq_routing.h>
-#include <amd_geodelx.h>
-#include "../../../southbridge/amd/cs5536/cs5536.h"
-
-/* Number of slots and devices in the PIR table */
-#define SLOT_COUNT 6
-
-/* Platform IRQs */
-#define PIRQA 11
-#define PIRQB 10
-#define PIRQC 11
-#define PIRQD 10
-
-/* Map */
-#define M_PIRQA (1 << PIRQA)	/* Bitmap of supported IRQs */
-#define M_PIRQB (1 << PIRQB)	/* Bitmap of supported IRQs */
-#define M_PIRQC (1 << PIRQC)	/* Bitmap of supported IRQs */
-#define M_PIRQD (1 << PIRQD)	/* Bitmap of supported IRQs */
-
-/* Link */
-#define L_PIRQA 1		/* Means Slot INTx# Connects To Chipset INTA# */
-#define L_PIRQB 2		/* Means Slot INTx# Connects To Chipset INTB# */
-#define L_PIRQC 3		/* Means Slot INTx# Connects To Chipset INTC# */
-#define L_PIRQD 4		/* Means Slot INTx# Connects To Chipset INTD# */
-
-/*
- * Norwich interrupt wiring.
- *
- * Devices are:
- *
- * 00:01.0 Host bridge: Advanced Micro Devices [AMD] CS5536 [Geode companion] Host Bridge (rev 31)
- * 00:01.1 Graphics device:  Advanced Micro Devices [AMD] Geode LX Graphics
- * 00:01.2 Entertainment encryption device: Advanced Micro Devices [AMD] Geode LX AES Security Block
- * 00:0b.0 slot3
- * 00:0c.0 slot4
- * 00:0d.0 slot1
- * 00:0e.0 slot2
- * 00:0f.0 ISA bridge: Advanced Micro Devices [AMD] CS5536 [Geode companion] ISA (rev 03)
- * 00:0f.2 IDE interface: Advanced Micro Devices [AMD] CS5536 [Geode companion] IDE (rev 01)
- * 00:0f.3 Multimedia audio controller: Advanced Micro Devices [AMD] CS5536 [Geode companion] Audio (rev 01)
- * 00:0f.4 USB Controller: Advanced Micro Devices [AMD] CS5536 [Geode companion] OHC (rev 02)
- * 00:0f.5 USB Controller: Advanced Micro Devices [AMD] CS5536 [Geode companion] EHC (rev 02)
- *
- */
-
-const struct irq_routing_table intel_irq_routing_table = {
-	PIRQ_SIGNATURE,
-	PIRQ_VERSION,
-	32 + 16 * SLOT_COUNT,	/* Max. number of devices on the bus */
-	0x00,			/* Where the interrupt router lies (bus) */
-	(0x0F << 3) | 0x0,      /* Where the interrupt router lies (dev) */
-	0x00,			/* IRQs devoted exclusively to PCI usage */
-	0x100B,			/* Vendor */
-	0x002B,			/* Device */
-	0,			/* Crap (miniport) */
-	{0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0},	/* u8 rfu[11] */
-	0x00,			/* Checksum */
-	{
-	 /* If you change the number of entries, change the IRQ_SLOT_COUNT above! */
-	 /* bus, dev|fn,           {link, bitmap},      {link, bitmap},     {link, bitmap},     {link, bitmap},     slot, rfu */
-	 {0x00, (0x01 << 3) | 0x0, {{L_PIRQA, M_PIRQA}, {0x00, 0x00}, {0x00, 0x00}, {0x00, 0x00}}, 0x0, 0x0},	/* cpu */
-	 {0x00, (0x0F << 3) | 0x0, {{L_PIRQA, M_PIRQA}, {L_PIRQB, M_PIRQB}, {L_PIRQC, M_PIRQC}, {L_PIRQD, M_PIRQD}}, 0x0, 0x0},	/* chipset */
-	 {0x00, (0x0D << 3) | 0x0, {{L_PIRQB, M_PIRQB}, {L_PIRQC, M_PIRQC}, {L_PIRQD, M_PIRQD}, {L_PIRQA, M_PIRQA}}, 0x1, 0x0},	/* slot1 */
-	 {0x00, (0x0E << 3) | 0x0, {{L_PIRQC, M_PIRQC}, {L_PIRQD, M_PIRQD}, {L_PIRQA, M_PIRQA}, {L_PIRQB, M_PIRQB}}, 0x2, 0x0},	/* slot2 */
-	 {0x00, (0x0B << 3) | 0x0, {{L_PIRQD, M_PIRQD}, {L_PIRQA, M_PIRQA}, {L_PIRQB, M_PIRQB}, {L_PIRQC, M_PIRQC}}, 0x3, 0x0},	/* slot3 */
-	 {0x00, (0x0C << 3) | 0x0, {{L_PIRQA, M_PIRQA}, {L_PIRQB, M_PIRQB}, {L_PIRQC, M_PIRQC}, {L_PIRQD, M_PIRQD}}, 0x4, 0x0},	/* slot4 */
-	 }
-};
-
-unsigned long write_pirq_routing_table(unsigned long addr)
-{
-	int i, j, k, num_entries;
-	unsigned char pirq[4];
-	u16 chipset_irq_map;
-	u32 pciAddr, pirtable_end;
-	struct irq_routing_table *pirq_tbl;
-
-	pirtable_end = copy_pirq_routing_table(addr);
-
-	/* Set up chipset IRQ steering. */
-	pciAddr = 0x80000000 | (CHIPSET_DEV_NUM << 11) | 0x5C;
-	chipset_irq_map = (PIRQD << 12 | PIRQC << 8 | PIRQB << 4 | PIRQA);
-	printk(BIOS_DEBUG, "%s(%08X, %04X)\n", __FUNCTION__, pciAddr,
-		     chipset_irq_map);
-	outl(pciAddr & ~3, 0xCF8);
-	outl(chipset_irq_map, 0xCFC);
-
-	pirq_tbl = (struct irq_routing_table *) (addr);
-	num_entries = (pirq_tbl->size - 32) / 16;
-
-	/* Set PCI IRQs. */
-	for (i = 0; i < num_entries; i++) {
-		printk(BIOS_DEBUG, "PIR Entry %d Dev/Fn: %X Slot: %d\n", i,
-			     pirq_tbl->slots[i].devfn, pirq_tbl->slots[i].slot);
-		for (j = 0; j < 4; j++) {
-			printk(BIOS_DEBUG, "INT: %c bitmap: %x ", 'A' + j,
-				     pirq_tbl->slots[i].irq[j].bitmap);
-			/* Finds lsb in bitmap to IRQ#. */
-			for (k = 0;
-			     (!((pirq_tbl->slots[i].irq[j].bitmap >> k) & 1))
-				     && (pirq_tbl->slots[i].irq[j].bitmap != 0);
-			     k++);
-			pirq[j] = k;
-			printk(BIOS_DEBUG, "PIRQ: %d\n", k);
-		}
-
-		/* Bus, device, slots IRQs for {A,B,C,D}. */
-		pci_assign_irqs(pirq_tbl->slots[i].bus,
-				pirq_tbl->slots[i].devfn >> 3, pirq);
-	}
-
-	/* Put the PIR table in memory and checksum. */
-	return pirtable_end;
-}

Copied: coreboot-v3/mainboard/amd/norwich/irq_tables.h (from rev 627, coreboot-v3/mainboard/amd/norwich/irq_tables.c)
===================================================================
--- coreboot-v3/mainboard/amd/norwich/irq_tables.h	                        (rev 0)
+++ coreboot-v3/mainboard/amd/norwich/irq_tables.h	2008-03-01 21:33:51 UTC (rev 628)
@@ -0,0 +1,95 @@
+/*
+* This file is part of the coreboot project.
+*
+* Copyright (C) 2007 Advanced Micro Devices, Inc.
+*
+* This program is free software; you can redistribute it and/or modify
+* it under the terms of the GNU General Public License version 2 as
+* published by the Free Software Foundation.
+*
+* 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 <types.h>
+#include <lib.h>
+#include <console.h>
+#include <device/device.h>
+#include <device/pci.h>
+#include <string.h>
+#include <msr.h>
+#include <io.h>
+#include <pirq_routing.h>
+#include <amd_geodelx.h>
+#include "../../../southbridge/amd/cs5536/cs5536.h"
+
+/* Number of slots and devices in the PIR table */
+#define SLOT_COUNT 6
+
+/* Platform IRQs */
+#define PIRQA 11
+#define PIRQB 10
+#define PIRQC 11
+#define PIRQD 10
+
+/* Map */
+#define M_PIRQA (1 << PIRQA)	/* Bitmap of supported IRQs */
+#define M_PIRQB (1 << PIRQB)	/* Bitmap of supported IRQs */
+#define M_PIRQC (1 << PIRQC)	/* Bitmap of supported IRQs */
+#define M_PIRQD (1 << PIRQD)	/* Bitmap of supported IRQs */
+
+/* Link */
+#define L_PIRQA 1		/* Means Slot INTx# Connects To Chipset INTA# */
+#define L_PIRQB 2		/* Means Slot INTx# Connects To Chipset INTB# */
+#define L_PIRQC 3		/* Means Slot INTx# Connects To Chipset INTC# */
+#define L_PIRQD 4		/* Means Slot INTx# Connects To Chipset INTD# */
+
+/*
+ * Norwich interrupt wiring.
+ *
+ * Devices are:
+ *
+ * 00:01.0 Host bridge: Advanced Micro Devices [AMD] CS5536 [Geode companion] Host Bridge (rev 31)
+ * 00:01.1 Graphics device:  Advanced Micro Devices [AMD] Geode LX Graphics
+ * 00:01.2 Entertainment encryption device: Advanced Micro Devices [AMD] Geode LX AES Security Block
+ * 00:0b.0 slot3
+ * 00:0c.0 slot4
+ * 00:0d.0 slot1
+ * 00:0e.0 slot2
+ * 00:0f.0 ISA bridge: Advanced Micro Devices [AMD] CS5536 [Geode companion] ISA (rev 03)
+ * 00:0f.2 IDE interface: Advanced Micro Devices [AMD] CS5536 [Geode companion] IDE (rev 01)
+ * 00:0f.3 Multimedia audio controller: Advanced Micro Devices [AMD] CS5536 [Geode companion] Audio (rev 01)
+ * 00:0f.4 USB Controller: Advanced Micro Devices [AMD] CS5536 [Geode companion] OHC (rev 02)
+ * 00:0f.5 USB Controller: Advanced Micro Devices [AMD] CS5536 [Geode companion] EHC (rev 02)
+ *
+ */
+
+const struct irq_routing_table intel_irq_routing_table = {
+	PIRQ_SIGNATURE,
+	PIRQ_VERSION,
+	32 + 16 * SLOT_COUNT,	/* Max. number of devices on the bus */
+	0x00,			/* Where the interrupt router lies (bus) */
+	(0x0F << 3) | 0x0,      /* Where the interrupt router lies (dev) */
+	0x00,			/* IRQs devoted exclusively to PCI usage */
+	0x100B,			/* Vendor */
+	0x002B,			/* Device */
+	0,			/* Crap (miniport) */
+	{0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0},	/* u8 rfu[11] */
+	0x00,			/* Checksum */
+	{
+	 /* If you change the number of entries, change the IRQ_SLOT_COUNT above! */
+	 /* bus, dev|fn,           {link, bitmap},      {link, bitmap},     {link, bitmap},     {link, bitmap},     slot, rfu */
+	 {0x00, (0x01 << 3) | 0x0, {{L_PIRQA, M_PIRQA}, {0x00, 0x00}, {0x00, 0x00}, {0x00, 0x00}}, 0x0, 0x0},	/* cpu */
+	 {0x00, (0x0F << 3) | 0x0, {{L_PIRQA, M_PIRQA}, {L_PIRQB, M_PIRQB}, {L_PIRQC, M_PIRQC}, {L_PIRQD, M_PIRQD}}, 0x0, 0x0},	/* chipset */
+	 {0x00, (0x0D << 3) | 0x0, {{L_PIRQB, M_PIRQB}, {L_PIRQC, M_PIRQC}, {L_PIRQD, M_PIRQD}, {L_PIRQA, M_PIRQA}}, 0x1, 0x0},	/* slot1 */
+	 {0x00, (0x0E << 3) | 0x0, {{L_PIRQC, M_PIRQC}, {L_PIRQD, M_PIRQD}, {L_PIRQA, M_PIRQA}, {L_PIRQB, M_PIRQB}}, 0x2, 0x0},	/* slot2 */
+	 {0x00, (0x0B << 3) | 0x0, {{L_PIRQD, M_PIRQD}, {L_PIRQA, M_PIRQA}, {L_PIRQB, M_PIRQB}, {L_PIRQC, M_PIRQC}}, 0x3, 0x0},	/* slot3 */
+	 {0x00, (0x0C << 3) | 0x0, {{L_PIRQA, M_PIRQA}, {L_PIRQB, M_PIRQB}, {L_PIRQC, M_PIRQC}, {L_PIRQD, M_PIRQD}}, 0x4, 0x0},	/* slot4 */
+	 }
+};

Deleted: coreboot-v3/mainboard/artecgroup/dbe61/irq_tables.c
===================================================================
--- coreboot-v3/mainboard/artecgroup/dbe61/irq_tables.c	2008-03-01 19:12:19 UTC (rev 627)
+++ coreboot-v3/mainboard/artecgroup/dbe61/irq_tables.c	2008-03-01 21:33:51 UTC (rev 628)
@@ -1,60 +0,0 @@
-/* This file was generated by getpir.c, do not modify! 
-   (but if you do, please run checkpir on it to verify)
- * Contains the IRQ Routing Table dumped directly from your memory, which BIOS sets up
- *
- * Documentation at : http://www.microsoft.com/hwdev/busbios/PCIIRQ.HTM
-*/
-
-#include <arch/pirq_routing.h>
-
-#define ID_SLOT_PCI_NET		1			// ThinCan ethernet
-#define ID_SLOT_PCI_RSVD1	2           // reserved entry 1
-#define ID_SLOT_PCI_RSVD3	3           // reserved entry 2
-#define ID_SLOT_PCI_RSVD2	4			// reserved entry 3
-#define ID_EMBED_PCI		0xff		// onboard PCI device
-
-// CS5535 PCI INT[A-D] Interrupt Routing lines.
-#define NO_CONNECT			0			// not used
-#define CS_PCI_INTA			1			// PCI INTA
-#define CS_PCI_INTB			2			// PCI INTB
-#define CS_PCI_INTC			3			// PCI INTC
-#define CS_PCI_INTD			4			// PCI INTD
-
-// IRQ bitmap reference line	FEDCBA9876543210
-//								0000110000100000b
-#define PCI_IRQ					0xc20	// PCI allowed IRQs here
-
-const struct irq_routing_table intel_irq_routing_table = 
-{
-	PIRQ_SIGNATURE,  /* u32 signature */
-	PIRQ_VERSION,    /* u16 version   */
-	32+16*6,		/* there can be total 2 devices on the bus */
-	0x00,		 /* Where the interrupt router lies (bus) */
-	(0x12<<3)|0x0,   /* Where the interrupt router lies (dev) */
-	0x0800,			/* IRQs devoted exclusively to PCI usage */
-	0x1022,			/* Vendor */
-	0x208f,			/* Device */
-	0x00000000,		/* Crap (miniport) */
-	{ 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0 }, /* u8 rfu[11] */
-	0xdf,         /*  u8 checksum , this hase to set to some value that would give 0 after the sum of all bytes for this structure (including checksum) */
-	{
-		/* bus,     dev|fn,   {link, bitmap}, {link, bitmap}, {link, bitmap}, {link, bitmap},  slot, rfu */
-		// Geode GX3 Host Bridge and VGA Graphics
-		{0, 0x01<<3, {{CS_PCI_INTA, PCI_IRQ}, {NO_CONNECT, PCI_IRQ}, {NO_CONNECT, PCI_IRQ}, {NO_CONNECT, PCI_IRQ}}, ID_EMBED_PCI, 0x0},
-		// Realtek RTL8100/8139 Network Controller
-		{0, 0x0d<<3, {{CS_PCI_INTB, PCI_IRQ}, {CS_PCI_INTC, PCI_IRQ}, {CS_PCI_INTD, PCI_IRQ}, {CS_PCI_INTA, PCI_IRQ}}, ID_SLOT_PCI_NET, 0x0},
-		// Reserved for future extensions
-		{0, 0x0c<<3, {{CS_PCI_INTA, PCI_IRQ}, {CS_PCI_INTB, PCI_IRQ}, {CS_PCI_INTC, PCI_IRQ}, {CS_PCI_INTD, PCI_IRQ}}, ID_SLOT_PCI_RSVD1, 0x0},
-		// Geode CS5535/CS5536 IO Companion: USB controllers, IDE, Audio.
-		{0, 0x0f<<3, {{CS_PCI_INTA, PCI_IRQ}, {CS_PCI_INTB, PCI_IRQ}, {CS_PCI_INTC, PCI_IRQ}, {CS_PCI_INTD, PCI_IRQ}}, ID_EMBED_PCI, 0x0},
-		// Reserved for future extensions
-		{0, 0x0e<<3, {{CS_PCI_INTC, PCI_IRQ}, {CS_PCI_INTD, PCI_IRQ}, {CS_PCI_INTA, PCI_IRQ}, {CS_PCI_INTB, PCI_IRQ}}, ID_SLOT_PCI_RSVD2, 0x0},
-		// Reserved for future extensions
-		{0, 0x0b<<3, {{CS_PCI_INTD, PCI_IRQ}, {CS_PCI_INTA, PCI_IRQ}, {CS_PCI_INTB, PCI_IRQ}, {CS_PCI_INTC, PCI_IRQ}}, ID_SLOT_PCI_RSVD3, 0x0}
-	}
-};
-
-unsigned long write_pirq_routing_table(unsigned long addr)
-{
-        return copy_pirq_routing_table(addr);
-}

Copied: coreboot-v3/mainboard/artecgroup/dbe61/irq_tables.h (from rev 627, coreboot-v3/mainboard/artecgroup/dbe61/irq_tables.c)
===================================================================
--- coreboot-v3/mainboard/artecgroup/dbe61/irq_tables.h	                        (rev 0)
+++ coreboot-v3/mainboard/artecgroup/dbe61/irq_tables.h	2008-03-01 21:33:51 UTC (rev 628)
@@ -0,0 +1,60 @@
+/* This file was generated by getpir.c, do not modify! 
+   (but if you do, please run checkpir on it to verify)
+ * Contains the IRQ Routing Table dumped directly from your memory, which BIOS sets up
+ *
+ * Documentation at : http://www.microsoft.com/hwdev/busbios/PCIIRQ.HTM
+*/
+
+#include <arch/pirq_routing.h>
+
+#define ID_SLOT_PCI_NET		1			// ThinCan ethernet
+#define ID_SLOT_PCI_RSVD1	2           // reserved entry 1
+#define ID_SLOT_PCI_RSVD3	3           // reserved entry 2
+#define ID_SLOT_PCI_RSVD2	4			// reserved entry 3
+#define ID_EMBED_PCI		0xff		// onboard PCI device
+
+// CS5535 PCI INT[A-D] Interrupt Routing lines.
+#define NO_CONNECT			0			// not used
+#define CS_PCI_INTA			1			// PCI INTA
+#define CS_PCI_INTB			2			// PCI INTB
+#define CS_PCI_INTC			3			// PCI INTC
+#define CS_PCI_INTD			4			// PCI INTD
+
+// IRQ bitmap reference line	FEDCBA9876543210
+//								0000110000100000b
+#define PCI_IRQ					0xc20	// PCI allowed IRQs here
+
+const struct irq_routing_table intel_irq_routing_table = 
+{
+	PIRQ_SIGNATURE,  /* u32 signature */
+	PIRQ_VERSION,    /* u16 version   */
+	32+16*6,		/* there can be total 2 devices on the bus */
+	0x00,		 /* Where the interrupt router lies (bus) */
+	(0x12<<3)|0x0,   /* Where the interrupt router lies (dev) */
+	0x0800,			/* IRQs devoted exclusively to PCI usage */
+	0x1022,			/* Vendor */
+	0x208f,			/* Device */
+	0x00000000,		/* Crap (miniport) */
+	{ 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0 }, /* u8 rfu[11] */
+	0xdf,         /*  u8 checksum , this hase to set to some value that would give 0 after the sum of all bytes for this structure (including checksum) */
+	{
+		/* bus,     dev|fn,   {link, bitmap}, {link, bitmap}, {link, bitmap}, {link, bitmap},  slot, rfu */
+		// Geode GX3 Host Bridge and VGA Graphics
+		{0, 0x01<<3, {{CS_PCI_INTA, PCI_IRQ}, {NO_CONNECT, PCI_IRQ}, {NO_CONNECT, PCI_IRQ}, {NO_CONNECT, PCI_IRQ}}, ID_EMBED_PCI, 0x0},
+		// Realtek RTL8100/8139 Network Controller
+		{0, 0x0d<<3, {{CS_PCI_INTB, PCI_IRQ}, {CS_PCI_INTC, PCI_IRQ}, {CS_PCI_INTD, PCI_IRQ}, {CS_PCI_INTA, PCI_IRQ}}, ID_SLOT_PCI_NET, 0x0},
+		// Reserved for future extensions
+		{0, 0x0c<<3, {{CS_PCI_INTA, PCI_IRQ}, {CS_PCI_INTB, PCI_IRQ}, {CS_PCI_INTC, PCI_IRQ}, {CS_PCI_INTD, PCI_IRQ}}, ID_SLOT_PCI_RSVD1, 0x0},
+		// Geode CS5535/CS5536 IO Companion: USB controllers, IDE, Audio.
+		{0, 0x0f<<3, {{CS_PCI_INTA, PCI_IRQ}, {CS_PCI_INTB, PCI_IRQ}, {CS_PCI_INTC, PCI_IRQ}, {CS_PCI_INTD, PCI_IRQ}}, ID_EMBED_PCI, 0x0},
+		// Reserved for future extensions
+		{0, 0x0e<<3, {{CS_PCI_INTC, PCI_IRQ}, {CS_PCI_INTD, PCI_IRQ}, {CS_PCI_INTA, PCI_IRQ}, {CS_PCI_INTB, PCI_IRQ}}, ID_SLOT_PCI_RSVD2, 0x0},
+		// Reserved for future extensions
+		{0, 0x0b<<3, {{CS_PCI_INTD, PCI_IRQ}, {CS_PCI_INTA, PCI_IRQ}, {CS_PCI_INTB, PCI_IRQ}, {CS_PCI_INTC, PCI_IRQ}}, ID_SLOT_PCI_RSVD3, 0x0}
+	}
+};
+
+unsigned long write_pirq_routing_table(unsigned long addr)
+{
+        return copy_pirq_routing_table(addr);
+}

Modified: coreboot-v3/mainboard/artecgroup/dbe62/Makefile
===================================================================
--- coreboot-v3/mainboard/artecgroup/dbe62/Makefile	2008-03-01 19:12:19 UTC (rev 627)
+++ coreboot-v3/mainboard/artecgroup/dbe62/Makefile	2008-03-01 21:33:51 UTC (rev 628)
@@ -25,7 +25,7 @@
 		$(src)/northbridge/amd/geodelx/raminit.c \
 		$(src)/arch/x86/geodelx/geodelx.c
 
-STAGE2_MAINBOARD_OBJ = irq_tables.o 
+STAGE2_MAINBOARD_OBJ = 
 
 $(obj)/coreboot.vpd:
 	$(Q)printf "  BUILD   DUMMY VPD\n"

Deleted: coreboot-v3/mainboard/artecgroup/dbe62/irq_tables.c
===================================================================
--- coreboot-v3/mainboard/artecgroup/dbe62/irq_tables.c	2008-03-01 19:12:19 UTC (rev 627)
+++ coreboot-v3/mainboard/artecgroup/dbe62/irq_tables.c	2008-03-01 21:33:51 UTC (rev 628)
@@ -1,116 +0,0 @@
-/*
-* This file is part of the coreboot project.
-*
-* Copyright (C) 2007 Advanced Micro Devices, Inc.
-*
-* This program is free software; you can redistribute it and/or modify
-* it under the terms of the GNU General Public License version 2 as
-* published by the Free Software Foundation.
-*
-* 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 <types.h>
-#include <lib.h>
-#include <console.h>
-#include <device/device.h>
-#include <device/pci.h>
-#include <string.h>
-#include <msr.h>
-#include <io.h>
-#include <pirq_routing.h>
-#include <amd_geodelx.h>
-#include "../../../southbridge/amd/cs5536/cs5536.h"
-
-
-
-/* Platform IRQs */
-#define PIRQA 10
-#define PIRQB 11
-#define PIRQC 10
-#define PIRQD 11
-
-/* Map */
-#define M_PIRQA (1 << PIRQA)	/* Bitmap of supported IRQs */
-#define M_PIRQB (1 << PIRQB)	/* Bitmap of supported IRQs */
-#define M_PIRQC (1 << PIRQC)	/* Bitmap of supported IRQs */
-#define M_PIRQD (1 << PIRQD)	/* Bitmap of supported IRQs */
-
-/* Link */
-#define L_PIRQA 1		/* Means Slot INTx# Connects To Chipset INTA# */
-#define L_PIRQB 2		/* Means Slot INTx# Connects To Chipset INTB# */
-#define L_PIRQC 3		/* Means Slot INTx# Connects To Chipset INTC# */
-#define L_PIRQD 4		/* Means Slot INTx# Connects To Chipset INTD# */
-
-const struct irq_routing_table intel_irq_routing_table = {
-	PIRQ_SIGNATURE,
-	PIRQ_VERSION,
-	32 + 16 * 5,		/* Max. number of devices on the bus */
-	0x00,			/* Where the interrupt router lies (bus) */
-	(0x0F << 3) | 0x0,      /* Where the interrupt router lies (dev) */
-	0x00,			/* IRQs devoted exclusively to PCI usage */
-	0x100B,			/* Vendor */
-	0x002B,			/* Device */
-	0,			/* Crap (miniport) */
-	{0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0},	/* u8 rfu[11] */
-	0x00,			/* Checksum */
-	{
-	 /* bus, dev|fn,           {link, bitmap},      {link, bitmap},     {link, bitmap},     {link, bitmap},     slot, rfu */
-	 {0x00, (0x01 << 3) | 0x0, {{L_PIRQA, M_PIRQA}, {0x00, 0x00}, {0x00, 0x00}, {0x00, 0x00}}, 0x0, 0x0},	/* cpu */
-	 {0x00, (0x0F << 3) | 0x0, {{L_PIRQA, M_PIRQA}, {L_PIRQB, M_PIRQB}, {L_PIRQC, M_PIRQC}, {L_PIRQD, M_PIRQD}}, 0x0, 0x0},	/* chipset */
-	 {0x00, (0x0D << 3) | 0x0, {{L_PIRQC, M_PIRQC}, {0x00, 0x00}, {0x00, 0x00}, {0x00, 0x00}}, 0x0, 0x0},	/* ethernet */
-	}
-};
-
-unsigned long write_pirq_routing_table(unsigned long addr)
-{
-	int i, j, k, num_entries;
-	unsigned char pirq[4];
-	u16 chipset_irq_map;
-	u32 pciAddr, pirtable_end;
-	struct irq_routing_table *pirq_tbl;
-
-	pirtable_end = copy_pirq_routing_table(addr);
-
-	/* Set up chipset IRQ steering. */
-	pciAddr = 0x80000000 | (CHIPSET_DEV_NUM << 11) | 0x5C;
-	chipset_irq_map = (PIRQD << 12 | PIRQC << 8 | PIRQB << 4 | PIRQA);
-	printk(BIOS_DEBUG, "%s(%08X, %04X)\n", __FUNCTION__, pciAddr,
-		     chipset_irq_map);
-	outl(pciAddr & ~3, 0xCF8);
-	outl(chipset_irq_map, 0xCFC);
-
-	pirq_tbl = (struct irq_routing_table *) (addr);
-	num_entries = (pirq_tbl->size - 32) / 16;
-
-	/* Set PCI IRQs. */
-	for (i = 0; i < num_entries; i++) {
-		printk(BIOS_DEBUG, "PIR Entry %d Dev/Fn: %X Slot: %d\n", i,
-			     pirq_tbl->slots[i].devfn, pirq_tbl->slots[i].slot);
-		for (j = 0; j < 4; j++) {
-			printk(BIOS_DEBUG, "INT: %c bitmap: %x ", 'A' + j,
-				     pirq_tbl->slots[i].irq[j].bitmap);
-			/* Finds lsb in bitmap to IRQ#. */
-			for (k = 0; 
-			     (!((pirq_tbl->slots[i].irq[j].bitmap >> k) & 1)) 
-				     && (pirq_tbl->slots[i].irq[j].bitmap != 0);
-			     k++);
-			pirq[j] = k;
-			printk(BIOS_DEBUG, "PIRQ: %d\n", k);
-		}
-
-		/* Bus, device, slots IRQs for {A,B,C,D}. */
-		pci_assign_irqs(pirq_tbl->slots[i].bus,
-				pirq_tbl->slots[i].devfn >> 3, pirq);
-	}
-
-	/* Put the PIR table in memory and checksum. */
-	return pirtable_end;
-}

Copied: coreboot-v3/mainboard/artecgroup/dbe62/irq_tables.h (from rev 627, coreboot-v3/mainboard/artecgroup/dbe62/irq_tables.c)
===================================================================
--- coreboot-v3/mainboard/artecgroup/dbe62/irq_tables.h	                        (rev 0)
+++ coreboot-v3/mainboard/artecgroup/dbe62/irq_tables.h	2008-03-01 21:33:51 UTC (rev 628)
@@ -0,0 +1,70 @@
+/*
+* This file is part of the coreboot project.
+*
+* Copyright (C) 2007 Advanced Micro Devices, Inc.
+*
+* This program is free software; you can redistribute it and/or modify
+* it under the terms of the GNU General Public License version 2 as
+* published by the Free Software Foundation.
+*
+* 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 <types.h>
+#include <lib.h>
+#include <console.h>
+#include <device/device.h>
+#include <device/pci.h>
+#include <string.h>
+#include <msr.h>
+#include <io.h>
+#include <pirq_routing.h>
+#include <amd_geodelx.h>
+#include "../../../southbridge/amd/cs5536/cs5536.h"
+
+
+
+/* Platform IRQs */
+#define PIRQA 10
+#define PIRQB 11
+#define PIRQC 10
+#define PIRQD 11
+
+/* Map */
+#define M_PIRQA (1 << PIRQA)	/* Bitmap of supported IRQs */
+#define M_PIRQB (1 << PIRQB)	/* Bitmap of supported IRQs */
+#define M_PIRQC (1 << PIRQC)	/* Bitmap of supported IRQs */
+#define M_PIRQD (1 << PIRQD)	/* Bitmap of supported IRQs */
+
+/* Link */
+#define L_PIRQA 1		/* Means Slot INTx# Connects To Chipset INTA# */
+#define L_PIRQB 2		/* Means Slot INTx# Connects To Chipset INTB# */
+#define L_PIRQC 3		/* Means Slot INTx# Connects To Chipset INTC# */
+#define L_PIRQD 4		/* Means Slot INTx# Connects To Chipset INTD# */
+
+const struct irq_routing_table intel_irq_routing_table = {
+	PIRQ_SIGNATURE,
+	PIRQ_VERSION,
+	32 + 16 * 5,		/* Max. number of devices on the bus */
+	0x00,			/* Where the interrupt router lies (bus) */
+	(0x0F << 3) | 0x0,      /* Where the interrupt router lies (dev) */
+	0x00,			/* IRQs devoted exclusively to PCI usage */
+	0x100B,			/* Vendor */
+	0x002B,			/* Device */
+	0,			/* Crap (miniport) */
+	{0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0},	/* u8 rfu[11] */
+	0x00,			/* Checksum */
+	{
+	 /* bus, dev|fn,           {link, bitmap},      {link, bitmap},     {link, bitmap},     {link, bitmap},     slot, rfu */
+	 {0x00, (0x01 << 3) | 0x0, {{L_PIRQA, M_PIRQA}, {0x00, 0x00}, {0x00, 0x00}, {0x00, 0x00}}, 0x0, 0x0},	/* cpu */
+	 {0x00, (0x0F << 3) | 0x0, {{L_PIRQA, M_PIRQA}, {L_PIRQB, M_PIRQB}, {L_PIRQC, M_PIRQC}, {L_PIRQD, M_PIRQD}}, 0x0, 0x0},	/* chipset */
+	 {0x00, (0x0D << 3) | 0x0, {{L_PIRQC, M_PIRQC}, {0x00, 0x00}, {0x00, 0x00}, {0x00, 0x00}}, 0x0, 0x0},	/* ethernet */
+	}
+};

Modified: coreboot-v3/mainboard/pcengines/alix1c/Makefile
===================================================================
--- coreboot-v3/mainboard/pcengines/alix1c/Makefile	2008-03-01 19:12:19 UTC (rev 627)
+++ coreboot-v3/mainboard/pcengines/alix1c/Makefile	2008-03-01 21:33:51 UTC (rev 628)
@@ -25,7 +25,7 @@
 		$(src)/northbridge/amd/geodelx/raminit.c \
 		$(src)/arch/x86/geodelx/geodelx.c
 
-STAGE2_MAINBOARD_OBJ = irq_tables.o 
+STAGE2_MAINBOARD_OBJ = 
 
 $(obj)/coreboot.vpd:
 	$(Q)printf "  BUILD   DUMMY VPD\n"

Deleted: coreboot-v3/mainboard/pcengines/alix1c/irq_tables.c
===================================================================
--- coreboot-v3/mainboard/pcengines/alix1c/irq_tables.c	2008-03-01 19:12:19 UTC (rev 627)
+++ coreboot-v3/mainboard/pcengines/alix1c/irq_tables.c	2008-03-01 21:33:51 UTC (rev 628)
@@ -1,160 +0,0 @@
-/*
-* This file is part of the coreboot project.
-*
-* Copyright (C) 2007 Advanced Micro Devices, Inc.
-*
-* This program is free software; you can redistribute it and/or modify
-* it under the terms of the GNU General Public License version 2 as
-* published by the Free Software Foundation.
-*
-* 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 <types.h>
-#include <lib.h>
-#include <console.h>
-#include <device/device.h>
-#include <device/pci.h>
-#include <string.h>
-#include <msr.h>
-#include <io.h>
-#include <pirq_routing.h>
-#include <amd_geodelx.h>
-#include "../../../southbridge/amd/cs5536/cs5536.h"
-
-
-
-/* Platform IRQs */
-#define PIRQA 11
-#define PIRQB 10
-#define PIRQC 11
-#define PIRQD 9
-
-/* Map */
-#define M_PIRQA (1 << PIRQA)	/* Bitmap of supported IRQs */
-#define M_PIRQB (1 << PIRQB)	/* Bitmap of supported IRQs */
-#define M_PIRQC (1 << PIRQC)	/* Bitmap of supported IRQs */
-#define M_PIRQD (1 << PIRQD)	/* Bitmap of supported IRQs */
-
-/* Link */
-#define L_PIRQA 1		/* Means Slot INTx# Connects To Chipset INTA# */
-#define L_PIRQB 2		/* Means Slot INTx# Connects To Chipset INTB# */
-#define L_PIRQC 3		/* Means Slot INTx# Connects To Chipset INTC# */
-#define L_PIRQD 4		/* Means Slot INTx# Connects To Chipset INTD# */
-
-/*
- * ALIX1.C interrupt wiring.
- *
- * Devices are:
- *
- * 00:01.0 Host bridge: Advanced Micro Devices [AMD] CS5536 [Geode companion] Host Bridge (rev 31)
- * 00:01.2 Entertainment encryption device: Advanced Micro Devices [AMD] Geode LX AES Security Block
- * 00:0d.0 Ethernet controller: VIA Technologies, Inc. VT6105M [Rhine-III] (rev 96)
- * 00:0e.0 Network controller: Intersil Corporation Prism 2.5 Wavelan chipset (rev 01)
- * 00:0f.0 ISA bridge: Advanced Micro Devices [AMD] CS5536 [Geode companion] ISA (rev 03)
- * 00:0f.2 IDE interface: Advanced Micro Devices [AMD] CS5536 [Geode companion] IDE (rev 01)
- * 00:0f.3 Multimedia audio controller: Advanced Micro Devices [AMD] CS5536 [Geode companion] Audio (rev 01)
- * 00:0f.4 USB Controller: Advanced Micro Devices [AMD] CS5536 [Geode companion] OHC (rev 02)
- * 00:0f.5 USB Controller: Advanced Micro Devices [AMD] CS5536 [Geode companion] EHC (rev 02)
- *
- * The only devices that interrupt are:
- *
- * What         Device  IRQ     PIN     PIN WIRED TO
- * -------------------------------------------------
- * AES          00:01.2 0a      01      A       A
- * 3VPCI        00:0c.0 0a      01      A       A
- * eth0 	00:0d.0 0b      01      A       B
- * mpci 	00:0e.0 0a      01      A       A
- * usb          00:0f.3 0b      02      B       B
- * usb          00:0f.4 0b      04      D       D
- * usb          00:0f.5 0b      04      D       D
- *
- * The only swizzled interrupt is eth0, where INTA is wired to interrupt controller line B.
- */
-
-const struct irq_routing_table intel_irq_routing_table = {
-	PIRQ_SIGNATURE,
-	PIRQ_VERSION,
-	32 + 16 * 5,		/* Max. number of devices on the bus */
-	0x00,			/* Where the interrupt router lies (bus) */
-	(0x0F << 3) | 0x0,      /* Where the interrupt router lies (dev) */
-	0x00,			/* IRQs devoted exclusively to PCI usage */
-	0x100B,			/* Vendor */
-	0x002B,			/* Device */
-	0,			/* Crap (miniport) */
-	{0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0},	/* u8 rfu[11] */
-	0x00,			/* Checksum */
-	{
-		/* If you change the number of entries, change IRQ_SLOT_COUNT above! */
-
-		/* bus, dev|fn,           {link, bitmap},      {link, bitmap},     {link, bitmap},     {link, bitmap},     slot, rfu */
-
-		/* CPU */
-		{0x00, (0x01 << 3) | 0x0, {{L_PIRQA, M_PIRQA}, {0x00, 0x00}, {0x00, 0x00}, {0x00, 0x00}}, 0x0, 0x0},
-
-		/* PCI (slot 1) */
-		{0x00, (0x0C << 3) | 0x0, {{L_PIRQC, M_PIRQC}, {L_PIRQD, M_PIRQD}, {L_PIRQA, M_PIRQA}, {L_PIRQB, M_PIRQB}}, 0x4, 0x0},
-
-		/* On-board ethernet */
-		{0x00, (0x0D << 3) | 0x0, {{L_PIRQB, M_PIRQB}, {0x00, 0x00}, {0x00, 0x00}, {0x00, 0x00}}, 0x0, 0x0},
-
-		/* Mini PCI (slot 2) */
-		{0x00, (0x0E << 3) | 0x0, {{L_PIRQA, M_PIRQA}, {L_PIRQB, M_PIRQB}, {L_PIRQC, M_PIRQC}, {L_PIRQD, M_PIRQD}}, 0x1, 0x0},
-
-		/* Chipset slots -- f.3 wires to B, and f.4 and f.5 wires to D. */
-		{0x00, (0x0F << 3) | 0x0, {{L_PIRQA, M_PIRQA}, {L_PIRQB, M_PIRQB}, {L_PIRQC, M_PIRQC}, {L_PIRQD, M_PIRQD}}, 0x0, 0x0},
-	}
-};
-
-unsigned long write_pirq_routing_table(unsigned long addr)
-{
-	int i, j, k, num_entries;
-	unsigned char pirq[4];
-	u16 chipset_irq_map;
-	u32 pciAddr, pirtable_end;
-	struct irq_routing_table *pirq_tbl;
-
-	pirtable_end = copy_pirq_routing_table(addr);
-
-	/* Set up chipset IRQ steering. */
-	pciAddr = 0x80000000 | (CHIPSET_DEV_NUM << 11) | 0x5C;
-	chipset_irq_map = (PIRQD << 12 | PIRQC << 8 | PIRQB << 4 | PIRQA);
-	printk(BIOS_DEBUG, "%s(%08X, %04X)\n", __FUNCTION__, pciAddr,
-		     chipset_irq_map);
-	outl(pciAddr & ~3, 0xCF8);
-	outl(chipset_irq_map, 0xCFC);
-
-	pirq_tbl = (struct irq_routing_table *) (addr);
-	num_entries = (pirq_tbl->size - 32) / 16;
-
-	/* Set PCI IRQs. */
-	for (i = 0; i < num_entries; i++) {
-		printk(BIOS_DEBUG, "PIR Entry %d Dev/Fn: %X Slot: %d\n", i,
-			     pirq_tbl->slots[i].devfn, pirq_tbl->slots[i].slot);
-		for (j = 0; j < 4; j++) {
-			printk(BIOS_DEBUG, "INT: %c bitmap: %x ", 'A' + j,
-				     pirq_tbl->slots[i].irq[j].bitmap);
-			/* Finds lsb in bitmap to IRQ#. */
-			for (k = 0; 
-			     (!((pirq_tbl->slots[i].irq[j].bitmap >> k) & 1)) 
-				     && (pirq_tbl->slots[i].irq[j].bitmap != 0);
-			     k++);
-			pirq[j] = k;
-			printk(BIOS_DEBUG, "PIRQ: %d\n", k);
-		}
-
-		/* Bus, device, slots IRQs for {A,B,C,D}. */
-		pci_assign_irqs(pirq_tbl->slots[i].bus,
-				pirq_tbl->slots[i].devfn >> 3, pirq);
-	}
-
-	/* Put the PIR table in memory and checksum. */
-	return pirtable_end;
-}

Copied: coreboot-v3/mainboard/pcengines/alix1c/irq_tables.h (from rev 627, coreboot-v3/mainboard/pcengines/alix1c/irq_tables.c)
===================================================================
--- coreboot-v3/mainboard/pcengines/alix1c/irq_tables.h	                        (rev 0)
+++ coreboot-v3/mainboard/pcengines/alix1c/irq_tables.h	2008-03-01 21:33:51 UTC (rev 628)
@@ -0,0 +1,103 @@
+/*
+* This file is part of the coreboot project.
+*
+* Copyright (C) 2007 Advanced Micro Devices, Inc.
+*
+* This program is free software; you can redistribute it and/or modify
+* it under the terms of the GNU General Public License version 2 as
+* published by the Free Software Foundation.
+*
+* 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 <pirq_routing.h>
+
+
+/* Platform IRQs */
+#define PIRQA 11
+#define PIRQB 10
+#define PIRQC 11
+#define PIRQD 9
+
+/* Map */
+#define M_PIRQA (1 << PIRQA)	/* Bitmap of supported IRQs */
+#define M_PIRQB (1 << PIRQB)	/* Bitmap of supported IRQs */
+#define M_PIRQC (1 << PIRQC)	/* Bitmap of supported IRQs */
+#define M_PIRQD (1 << PIRQD)	/* Bitmap of supported IRQs */
+
+/* Link */
+#define L_PIRQA 1		/* Means Slot INTx# Connects To Chipset INTA# */
+#define L_PIRQB 2		/* Means Slot INTx# Connects To Chipset INTB# */
+#define L_PIRQC 3		/* Means Slot INTx# Connects To Chipset INTC# */
+#define L_PIRQD 4		/* Means Slot INTx# Connects To Chipset INTD# */
+
+/*
+ * ALIX1.C interrupt wiring.
+ *
+ * Devices are:
+ *
+ * 00:01.0 Host bridge: Advanced Micro Devices [AMD] CS5536 [Geode companion] Host Bridge (rev 31)
+ * 00:01.2 Entertainment encryption device: Advanced Micro Devices [AMD] Geode LX AES Security Block
+ * 00:0d.0 Ethernet controller: VIA Technologies, Inc. VT6105M [Rhine-III] (rev 96)
+ * 00:0e.0 Network controller: Intersil Corporation Prism 2.5 Wavelan chipset (rev 01)
+ * 00:0f.0 ISA bridge: Advanced Micro Devices [AMD] CS5536 [Geode companion] ISA (rev 03)
+ * 00:0f.2 IDE interface: Advanced Micro Devices [AMD] CS5536 [Geode companion] IDE (rev 01)
+ * 00:0f.3 Multimedia audio controller: Advanced Micro Devices [AMD] CS5536 [Geode companion] Audio (rev 01)
+ * 00:0f.4 USB Controller: Advanced Micro Devices [AMD] CS5536 [Geode companion] OHC (rev 02)
+ * 00:0f.5 USB Controller: Advanced Micro Devices [AMD] CS5536 [Geode companion] EHC (rev 02)
+ *
+ * The only devices that interrupt are:
+ *
+ * What         Device  IRQ     PIN     PIN WIRED TO
+ * -------------------------------------------------
+ * AES          00:01.2 0a      01      A       A
+ * 3VPCI        00:0c.0 0a      01      A       A
+ * eth0 	00:0d.0 0b      01      A       B
+ * mpci 	00:0e.0 0a      01      A       A
+ * usb          00:0f.3 0b      02      B       B
+ * usb          00:0f.4 0b      04      D       D
+ * usb          00:0f.5 0b      04      D       D
+ *
+ * The only swizzled interrupt is eth0, where INTA is wired to interrupt controller line B.
+ */
+
+const struct irq_routing_table intel_irq_routing_table = {
+	PIRQ_SIGNATURE,
+	PIRQ_VERSION,
+	32 + 16 * 5,		/* Max. number of devices on the bus */
+	0x00,			/* Where the interrupt router lies (bus) */
+	(0x0F << 3) | 0x0,      /* Where the interrupt router lies (dev) */
+	0x00,			/* IRQs devoted exclusively to PCI usage */
+	0x100B,			/* Vendor */
+	0x002B,			/* Device */
+	0,			/* Crap (miniport) */
+	{0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0},	/* u8 rfu[11] */
+	0x00,			/* Checksum */
+	{
+		/* If you change the number of entries, change IRQ_SLOT_COUNT above! */
+
+		/* bus, dev|fn,           {link, bitmap},      {link, bitmap},     {link, bitmap},     {link, bitmap},     slot, rfu */
+
+		/* CPU */
+		{0x00, (0x01 << 3) | 0x0, {{L_PIRQA, M_PIRQA}, {0x00, 0x00}, {0x00, 0x00}, {0x00, 0x00}}, 0x0, 0x0},
+
+		/* PCI (slot 1) */
+		{0x00, (0x0C << 3) | 0x0, {{L_PIRQC, M_PIRQC}, {L_PIRQD, M_PIRQD}, {L_PIRQA, M_PIRQA}, {L_PIRQB, M_PIRQB}}, 0x4, 0x0},
+
+		/* On-board ethernet */
+		{0x00, (0x0D << 3) | 0x0, {{L_PIRQB, M_PIRQB}, {0x00, 0x00}, {0x00, 0x00}, {0x00, 0x00}}, 0x0, 0x0},
+
+		/* Mini PCI (slot 2) */
+		{0x00, (0x0E << 3) | 0x0, {{L_PIRQA, M_PIRQA}, {L_PIRQB, M_PIRQB}, {L_PIRQC, M_PIRQC}, {L_PIRQD, M_PIRQD}}, 0x1, 0x0},
+
+		/* Chipset slots -- f.3 wires to B, and f.4 and f.5 wires to D. */
+		{0x00, (0x0F << 3) | 0x0, {{L_PIRQA, M_PIRQA}, {L_PIRQB, M_PIRQB}, {L_PIRQC, M_PIRQC}, {L_PIRQD, M_PIRQD}}, 0x0, 0x0},
+	}
+};

Modified: coreboot-v3/southbridge/amd/cs5536/Makefile
===================================================================
--- coreboot-v3/southbridge/amd/cs5536/Makefile	2008-03-01 19:12:19 UTC (rev 627)
+++ coreboot-v3/southbridge/amd/cs5536/Makefile	2008-03-01 21:33:51 UTC (rev 628)
@@ -23,6 +23,10 @@
 
 STAGE2_CHIPSET_OBJ += $(obj)/southbridge/amd/cs5536/cs5536.o
 
+ifeq ($(CONFIG_PIRQ_TABLE),y)
+STAGE2_CHIPSET_OBJ += $(obj)/southbridge/amd/cs5536/irq_tables.o 
+endif
+
 STAGE0_CHIPSET_OBJ += $(obj)/southbridge/amd/cs5536/stage1.o
 
 endif




From rminnich at gmail.com  Sat Mar  1 22:34:35 2008
From: rminnich at gmail.com (ron minnich)
Date: Sat, 1 Mar 2008 13:34:35 -0800
Subject: [coreboot] patch: dbe62
In-Reply-To: <13426df10803010908s6a866eb0jcdaf90135d6579b6@mail.gmail.com>
References: <13426df10802281441v109c6edai8e448131a0539c93@mail.gmail.com>
	<20080229010002.9912.qmail@stuge.se>
	<13426df10802281853q27757ab3mac567ab8c574412@mail.gmail.com>
	<20080229134132.2184.qmail@stuge.se>
	<13426df10802290852h109ab986o89a83f689a14148b@mail.gmail.com>
	<47C8B860.5030700@gmx.net>
	<13426df10802291803y2b042304pfa78ce2e2900dfa1@mail.gmail.com>
	<47C9734E.1010807@gmx.net> <20080301152721.25943.qmail@stuge.se>
	<13426df10803010908s6a866eb0jcdaf90135d6579b6@mail.gmail.com>
Message-ID: <13426df10803011334o20ec721lfde0b3d18aee9c20@mail.gmail.com>

Tested on alix1c. Ethernet, USB, graphics, serial all work.

Committed revision 628.



From svn at coreboot.org  Sat Mar  1 23:09:01 2008
From: svn at coreboot.org (svn at coreboot.org)
Date: Sat,  1 Mar 2008 23:09:01 +0100
Subject: [coreboot] r629 - coreboot-v3/southbridge/amd/cs5536
Message-ID: <mailman.1245.1355071270.16123.coreboot@coreboot.org>

Author: hailfinger
Date: 2008-03-01 23:09:00 +0100 (Sat, 01 Mar 2008)
New Revision: 629

Added:
   coreboot-v3/southbridge/amd/cs5536/irq_tables.c
Log:
Add file forgotten in r628. Same changelog follows:

Factor out write_pirq_routing_table() for all GeodeLX targets.
Compile tested on norwich, alix1c and dbe62. msm800sev is not affected
and dbe61 is broken anyway.

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

tested on alix1c. Boots, USB, graphics, and ethernet all work.

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

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


Added: coreboot-v3/southbridge/amd/cs5536/irq_tables.c
===================================================================
--- coreboot-v3/southbridge/amd/cs5536/irq_tables.c	                        (rev 0)
+++ coreboot-v3/southbridge/amd/cs5536/irq_tables.c	2008-03-01 22:09:00 UTC (rev 629)
@@ -0,0 +1,77 @@
+/*
+* This file is part of the coreboot project.
+*
+* Copyright (C) 2007 Advanced Micro Devices, Inc.
+*
+* This program is free software; you can redistribute it and/or modify
+* it under the terms of the GNU General Public License version 2 as
+* published by the Free Software Foundation.
+*
+* 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 <types.h>
+#include <lib.h>
+#include <console.h>
+#include <device/device.h>
+#include <device/pci.h>
+#include <string.h>
+#include <msr.h>
+#include <io.h>
+#include <pirq_routing.h>
+#include <amd_geodelx.h>
+#include <irq_tables.h>
+#include "cs5536.h"
+
+unsigned long write_pirq_routing_table(unsigned long addr)
+{
+	int i, j, k, num_entries;
+	unsigned char pirq[4];
+	u16 chipset_irq_map;
+	u32 pciAddr, pirtable_end;
+	struct irq_routing_table *pirq_tbl;
+
+	pirtable_end = copy_pirq_routing_table(addr);
+
+	/* Set up chipset IRQ steering. */
+	pciAddr = 0x80000000 | (CHIPSET_DEV_NUM << 11) | 0x5C;
+	chipset_irq_map = (PIRQD << 12 | PIRQC << 8 | PIRQB << 4 | PIRQA);
+	printk(BIOS_DEBUG, "%s(%08X, %04X)\n", __FUNCTION__, pciAddr,
+		     chipset_irq_map);
+	outl(pciAddr & ~3, 0xCF8);
+	outl(chipset_irq_map, 0xCFC);
+
+	pirq_tbl = (struct irq_routing_table *) (addr);
+	num_entries = (pirq_tbl->size - 32) / 16;
+
+	/* Set PCI IRQs. */
+	for (i = 0; i < num_entries; i++) {
+		printk(BIOS_DEBUG, "PIR Entry %d Dev/Fn: %X Slot: %d\n", i,
+			     pirq_tbl->slots[i].devfn, pirq_tbl->slots[i].slot);
+		for (j = 0; j < 4; j++) {
+			printk(BIOS_DEBUG, "INT: %c bitmap: %x ", 'A' + j,
+				     pirq_tbl->slots[i].irq[j].bitmap);
+			/* Finds lsb in bitmap to IRQ#. */
+			for (k = 0; 
+			     (!((pirq_tbl->slots[i].irq[j].bitmap >> k) & 1)) 
+				     && (pirq_tbl->slots[i].irq[j].bitmap != 0);
+			     k++);
+			pirq[j] = k;
+			printk(BIOS_DEBUG, "PIRQ: %d\n", k);
+		}
+
+		/* Bus, device, slots IRQs for {A,B,C,D}. */
+		pci_assign_irqs(pirq_tbl->slots[i].bus,
+				pirq_tbl->slots[i].devfn >> 3, pirq);
+	}
+
+	/* Put the PIR table in memory and checksum. */
+	return pirtable_end;
+}




From c-d.hailfinger.devel.2006 at gmx.net  Sat Mar  1 23:08:53 2008
From: c-d.hailfinger.devel.2006 at gmx.net (Carl-Daniel Hailfinger)
Date: Sat, 01 Mar 2008 23:08:53 +0100
Subject: [coreboot] patch: dbe62
In-Reply-To: <13426df10803011334o20ec721lfde0b3d18aee9c20@mail.gmail.com>
References: <13426df10802281441v109c6edai8e448131a0539c93@mail.gmail.com>	<20080229010002.9912.qmail@stuge.se>	<13426df10802281853q27757ab3mac567ab8c574412@mail.gmail.com>	<20080229134132.2184.qmail@stuge.se>	<13426df10802290852h109ab986o89a83f689a14148b@mail.gmail.com>	<47C8B860.5030700@gmx.net>	<13426df10802291803y2b042304pfa78ce2e2900dfa1@mail.gmail.com>	<47C9734E.1010807@gmx.net>
	<20080301152721.25943.qmail@stuge.se>	<13426df10803010908s6a866eb0jcdaf90135d6579b6@mail.gmail.com>
	<13426df10803011334o20ec721lfde0b3d18aee9c20@mail.gmail.com>
Message-ID: <47C9D3F5.9010506@gmx.net>

On 01.03.2008 22:34, ron minnich wrote:
> Tested on alix1c. Ethernet, USB, graphics, serial all work.
>
> Committed revision 628.
>   

Thanks. And fixed in revision 629. (There was a reason why I wrote that 
I have to commit it myself...)

Regards,
Carl-Daniel

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




From info at coresystems.de  Sat Mar  1 23:15:21 2008
From: info at coresystems.de (coreboot information)
Date: Sat, 01 Mar 2008 23:15:21 +0100
Subject: [coreboot] r3123 build service
Message-ID: <E1JVZzF-0000Br-GN@khepri.openbios.org>

Dear coreboot readers!

This is the automated build check service of coreboot.

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

Change Log:
Rename lxbios to nvramtool, step 2 (rename files).

Signed-off-by: Uwe Hermann <uwe at hermann-uwe.de>
Acked-by: Stefan Reinauer <stepan at coresystems.de>



Build Log:
Compilation of amd:serengeti_cheetah_fam10 is still broken
See the error log at http://qa.coreboot.org/log_buildbrd.php?revision=3123&device=serengeti_cheetah_fam10&vendor=amd


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

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

   Best regards,
     coreboot automatic build system





From info at coresystems.de  Sun Mar  2 00:11:32 2008
From: info at coresystems.de (coreboot information)
Date: Sun, 02 Mar 2008 00:11:32 +0100
Subject: [coreboot] r3124 build service
Message-ID: <E1JVarc-0001eg-Tx@khepri.openbios.org>

Dear coreboot readers!

This is the automated build check service of coreboot.

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

Change Log:
Rename lxbios to nvramtool, step 3 (rename directory).

Signed-off-by: Uwe Hermann <uwe at hermann-uwe.de>
Acked-by: Stefan Reinauer <stepan at coresystems.de>



Build Log:
Compilation of amd:serengeti_cheetah_fam10 is still broken
See the error log at http://qa.coreboot.org/log_buildbrd.php?revision=3124&device=serengeti_cheetah_fam10&vendor=amd


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

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

   Best regards,
     coreboot automatic build system





From c-d.hailfinger.devel.2006 at gmx.net  Sun Mar  2 00:19:21 2008
From: c-d.hailfinger.devel.2006 at gmx.net (Carl-Daniel Hailfinger)
Date: Sun, 02 Mar 2008 00:19:21 +0100
Subject: [coreboot] v3: missing dependencies
In-Reply-To: <47C9A5E3.3090304@gmx.net>
References: <47C9A5E3.3090304@gmx.net>
Message-ID: <47C9E479.2000201@gmx.net>

On 01.03.2008 19:52, Carl-Daniel Hailfinger wrote:
> I finally found out why building one target, running menuconfig to 
> change the target and recompiling fails unless you make clean in between:
> statictree.c and statictree.h are missing dependencies on .config or its 
> derivatives. Ouch. That's not totally bad for statictree.c because it 
> sits next to the dts, but for statictree.h.
> So if you configure for qemu, compile, reconfigure for alix1c, compile 
> again, make thinks statictree.h is not stale because it is newer than 
> the alix1c dts. Boom.
>
> Two possible fixes:
> - move statictree.h to the mainboard dir next to statictree.c.
> - have statictree.h depend on .config or derivatives.
>
> I like the first option a lot better.
>   

Actually, we may need both.

There is another related dependency bug in our makefiles: Copying a 
.config in place is not sufficient to run make. It still needs "make 
oldconfig" or any other "make *config".

> Opinions?
>   

Regards,

Carl-Daniel

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




From rminnich at gmail.com  Sun Mar  2 00:30:50 2008
From: rminnich at gmail.com (ron minnich)
Date: Sat, 1 Mar 2008 15:30:50 -0800
Subject: [coreboot] v3: missing dependencies
In-Reply-To: <47C9A5E3.3090304@gmx.net>
References: <47C9A5E3.3090304@gmx.net>
Message-ID: <13426df10803011530n4b26c877y75c997770904aa3a@mail.gmail.com>

On Sat, Mar 1, 2008 at 10:52 AM, Carl-Daniel Hailfinger
<c-d.hailfinger.devel.2006 at gmx.net> wrote:

>  - move statictree.h to the mainboard dir next to statictree.c.

Yes. It makes no sense where it is now.

ron



From info at coresystems.de  Sun Mar  2 01:05:00 2008
From: info at coresystems.de (coreboot information)
Date: Sun, 02 Mar 2008 01:05:00 +0100
Subject: [coreboot] r3125 build service
Message-ID: <E1JVbhM-0002k6-MB@khepri.openbios.org>

Dear coreboot readers!

This is the automated build check service of coreboot.

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

Change Log:
Adapt v2 svn:externals for lxbios -> nvramtool rename.

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



Build Log:
Compilation of amd:serengeti_cheetah_fam10 is still broken
See the error log at http://qa.coreboot.org/log_buildbrd.php?revision=3125&device=serengeti_cheetah_fam10&vendor=amd


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

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

   Best regards,
     coreboot automatic build system





From jonathanrrogers at gmail.com  Sun Mar  2 09:18:26 2008
From: jonathanrrogers at gmail.com (Jonathan Rogers)
Date: Sun, 02 Mar 2008 03:18:26 -0500
Subject: [coreboot] VGA and Asus a8v-e_se
Message-ID: <47CA62D2.3040702@gmail.com>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

I have successfully built coreboot-v2-3119 with a FILO payload and
booted my Asus a8v-e_se mainboard with the resulting image. However, VGA
is not initialized and I can only interact with it via serial console.
The video card is a PNY Nvidia 7900GS PCIe card.

I can boot Linux from my SATA disk normally except a few devices aren't
working, most notably the video card. Neither Linux nor the proprietary
Nvidia driver see any VGA devices. When I reflash the legacy Award BIOS
I copied from the BIOS before installing the coreboot image, everything
returns to normal and the VGA card works.

I tried to follow the wiki page http://www.coreboot.org/VGA_support, so
I opened src/mainboard/asus/a8v-e_se/Options.lb. However, that file
contains the following lines instead of ones starting with "option" as
in the wiki:

#VGA
default CONFIG_CONSOLE_VGA=1
default CONFIG_PCI_ROM_RUN=1

So, I'm not sure what that means. Has the configuration method changed?
Do the default lines enable those features? During boot, I see many
initialization messages on the serial console from coreboot, but nothing
about VGA or PCI_ROM_RUN. The wiki page
http://www.coreboot.org/ASUS_A8V-E_SE_Build_Tutorial doesn't have much
in the way of instructions, but it does say that PCIe video cards work.
Any pointers would be appreciated.

Jonathan Rogers
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFHymLSMs6f82yVS5wRAhh3AJ9LBivG+U+ZINyMs2xVYb+5b5/WQgCgq/ch
TAZzvfZzrAW7cqPfNGcw1nc=
=Kki+
-----END PGP SIGNATURE-----



From r.marek at assembler.cz  Sun Mar  2 09:34:35 2008
From: r.marek at assembler.cz (Rudolf Marek)
Date: Sun, 02 Mar 2008 09:34:35 +0100
Subject: [coreboot] VGA and Asus a8v-e_se
In-Reply-To: <47CA62D2.3040702@gmail.com>
References: <47CA62D2.3040702@gmail.com>
Message-ID: <47CA669B.9090202@assembler.cz>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi,

I have same motherboard and I did the port to this motherboard/chipset. Can you
give me

lspci -vvvxxx

Ran in the proprietary BIOS as well as all messages from the serial console as
attachments? I have an PCIe ATI card and it does work great. What other devices
are not working?

Can you give me also a cat /proc/acpi/dsdt > /tmp/dsdt.bin file?

Thanks
Rudolf


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFHymaa3J9wPJqZRNURAog6AJoDhsbz7yLk24R6z82J0mWips5MtQCgzcy4
6G/dDcgk3TysF5IDoNl3dGk=
=3Riz
-----END PGP SIGNATURE-----



From corey.osgood at gmail.com  Sun Mar  2 09:35:51 2008
From: corey.osgood at gmail.com (Corey Osgood)
Date: Sun, 2 Mar 2008 03:35:51 -0500
Subject: [coreboot] VGA and Asus a8v-e_se
In-Reply-To: <47CA62D2.3040702@gmail.com>
References: <47CA62D2.3040702@gmail.com>
Message-ID: <dd3c80060803020035w7e1273a1of2fa7bfbe438dad7@mail.gmail.com>

On Sun, Mar 2, 2008 at 3:18 AM, Jonathan Rogers <jonathanrrogers at gmail.com>
wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> I have successfully built coreboot-v2-3119 with a FILO payload and
> booted my Asus a8v-e_se mainboard with the resulting image. However, VGA
> is not initialized and I can only interact with it via serial console.
> The video card is a PNY Nvidia 7900GS PCIe card.
>
> I can boot Linux from my SATA disk normally except a few devices aren't
> working, most notably the video card. Neither Linux nor the proprietary
> Nvidia driver see any VGA devices. When I reflash the legacy Award BIOS
> I copied from the BIOS before installing the coreboot image, everything
> returns to normal and the VGA card works.
>
> I tried to follow the wiki page http://www.coreboot.org/VGA_support, so
> I opened src/mainboard/asus/a8v-e_se/Options.lb. However, that file
> contains the following lines instead of ones starting with "option" as
> in the wiki:
>
> #VGA
> default CONFIG_CONSOLE_VGA=1
> default CONFIG_PCI_ROM_RUN=1
>
> So, I'm not sure what that means. Has the configuration method changed?
> Do the default lines enable those features? During boot, I see many
> initialization messages on the serial console from coreboot, but nothing
> about VGA or PCI_ROM_RUN. The wiki page
> http://www.coreboot.org/ASUS_A8V-E_SE_Build_Tutorial doesn't have much
> in the way of instructions, but it does say that PCIe video cards work.
> Any pointers would be appreciated.
>
> Jonathan Rogers
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.6 (GNU/Linux)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
>
> iD8DBQFHymLSMs6f82yVS5wRAhh3AJ9LBivG+U+ZINyMs2xVYb+5b5/WQgCgq/ch
> TAZzvfZzrAW7cqPfNGcw1nc=
> =Kki+
> -----END PGP SIGNATURE-----


Can you try reverting to revision 3118 (svn up -r3118)? r3119 made a change
to how we detect VGA card presence, which *should* have corrected a very old
bug, but might not have. Please send bootlogs (up to elfboot) from both
revisions if anything changes, if not just one.

Thanks,
Corey
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20080302/9fdbaa4e/attachment.html>

From jonathanrrogers at gmail.com  Sun Mar  2 09:53:31 2008
From: jonathanrrogers at gmail.com (Jonathan Rogers)
Date: Sun, 02 Mar 2008 03:53:31 -0500
Subject: [coreboot] VGA and Asus a8v-e_se
In-Reply-To: <47CA669B.9090202@assembler.cz>
References: <47CA62D2.3040702@gmail.com> <47CA669B.9090202@assembler.cz>
Message-ID: <47CA6B0B.6080804@gmail.com>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Rudolf Marek wrote:
> Hi,
> 
> I have same motherboard and I did the port to this motherboard/chipset. Can you
> give me
> 
> lspci -vvvxxx
> 
> Ran in the proprietary BIOS as well as all messages from the serial console as
> attachments? I have an PCIe ATI card and it does work great. What other devices
> are not working?

The frequency scaling driver powernow_k8 does not seem to work after
booting with coreboot. I'm very new to coreboot, but it seemed to me
that this was related to DSDT, which I haven't done anything about yet.

> 
> Can you give me also a cat /proc/acpi/dsdt > /tmp/dsdt.bin file?

Do I need to somehow use that DSDT from the Award BIOS when I boot using
coreboot to get things like frequency scaling working?

I'll send the console messages in the next message.

Jonathan Rogers
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFHymqMMs6f82yVS5wRApyCAJ0cXV2J/xV25XM8In0/wAc60kFf/wCff4Zq
j1T5FgLrnhBaSsiKoblTB7o=
=jG4b
-----END PGP SIGNATURE-----
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: a8v-e_se.lspci
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20080302/1d62e48b/attachment.ksh>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: dsdt.bin
Type: application/octet-stream
Size: 30055 bytes
Desc: not available
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20080302/1d62e48b/attachment.bin>

From jonathanrrogers at gmail.com  Sun Mar  2 10:05:24 2008
From: jonathanrrogers at gmail.com (Jonathan Rogers)
Date: Sun, 02 Mar 2008 04:05:24 -0500
Subject: [coreboot] VGA and Asus a8v-e_se
In-Reply-To: <47CA669B.9090202@assembler.cz>
References: <47CA62D2.3040702@gmail.com> <47CA669B.9090202@assembler.cz>
Message-ID: <47CA6DD4.5010109@gmail.com>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Rudolf Marek wrote:
> Ran in the proprietary BIOS as well as all messages from the serial console as
> attachments? I have an PCIe ATI card and it does work great. What other devices
> are not working?

Here is the boot log of 3119 up to elfboot.

Jonathan Rogers
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFHym3TMs6f82yVS5wRAriuAKCuL1iw7KQy2NMwj+B1Ca+mMyCW8wCfaCFl
RhY49BaFuAcspoS7bZW2D0U=
=J62+
-----END PGP SIGNATURE-----
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: coreboot-v2-3119.log
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20080302/9b851dcd/attachment.ksh>

From jonathanrrogers at gmail.com  Sun Mar  2 10:22:17 2008
From: jonathanrrogers at gmail.com (Jonathan Rogers)
Date: Sun, 02 Mar 2008 04:22:17 -0500
Subject: [coreboot] VGA and Asus a8v-e_se
In-Reply-To: <dd3c80060803020035w7e1273a1of2fa7bfbe438dad7@mail.gmail.com>
References: <47CA62D2.3040702@gmail.com>
	<dd3c80060803020035w7e1273a1of2fa7bfbe438dad7@mail.gmail.com>
Message-ID: <47CA71C9.10205@gmail.com>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Corey Osgood wrote:
> On Sun, Mar 2, 2008 at 3:18 AM, Jonathan Rogers <jonathanrrogers at gmail.com>
> wrote:
> 
> I have successfully built coreboot-v2-3119 with a FILO payload and
> booted my Asus a8v-e_se mainboard with the resulting image. However, VGA
> is not initialized and I can only interact with it via serial console.
> The video card is a PNY Nvidia 7900GS PCIe card.
> 
> I can boot Linux from my SATA disk normally except a few devices aren't
> working, most notably the video card. Neither Linux nor the proprietary
> Nvidia driver see any VGA devices. When I reflash the legacy Award BIOS
> I copied from the BIOS before installing the coreboot image, everything
> returns to normal and the VGA card works.
> 
> I tried to follow the wiki page http://www.coreboot.org/VGA_support, so
> I opened src/mainboard/asus/a8v-e_se/Options.lb. However, that file
> contains the following lines instead of ones starting with "option" as
> in the wiki:
> 
> #VGA
> default CONFIG_CONSOLE_VGA=1
> default CONFIG_PCI_ROM_RUN=1
> 
> So, I'm not sure what that means. Has the configuration method changed?
> Do the default lines enable those features? During boot, I see many
> initialization messages on the serial console from coreboot, but nothing
> about VGA or PCI_ROM_RUN. The wiki page
> http://www.coreboot.org/ASUS_A8V-E_SE_Build_Tutorial doesn't have much
> in the way of instructions, but it does say that PCIe video cards work.
> Any pointers would be appreciated.
> 
> Jonathan Rogers

> Can you try reverting to revision 3118 (svn up -r3118)? r3119 made a change
> to how we detect VGA card presence, which *should* have corrected a very old
> bug, but might not have. Please send bootlogs (up to elfboot) from both
> revisions if anything changes, if not just one.

Here's the log from 3118. BTW, I used snapshot tarballs for both.

Jonathan Rogers
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFHynHIMs6f82yVS5wRAgWAAKCdZDMojxcoufwfdZgA4A9hmrTprwCfU7RL
iDkvmXlptfvqdhb2o6B1D3I=
=nF9l
-----END PGP SIGNATURE-----
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: coreboot-v2-3118.log
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20080302/4e902eb3/attachment.ksh>

From traut at gmx.de  Sun Mar  2 12:13:14 2008
From: traut at gmx.de (Martin Trautmann)
Date: Sun, 02 Mar 2008 12:13:14 +0100
Subject: [coreboot] Geode GX / CS5535 / PIC
In-Reply-To: <20080301025119.13631.qmail@stuge.se>
References: <47C73861.3010802@gmx.de>
	<20080229004346.5836.qmail@stuge.se>	<47C79B71.8050103@gmx.de>
	<47C79D4B.8020702@gmx.de>	<20080229142247.GA18182@greenwood>
	<47C828A2.2070102@gmx.de>	<20080229161131.GA30432@greenwood>
	<20080301025119.13631.qmail@stuge.se>
Message-ID: <47CA8BCA.6050302@gmx.de>

Peter Stuge wrote:
> On Fri, Feb 29, 2008 at 05:11:31PM +0100, Uwe Hermann wrote:
>>> Here's the board itself:
>>> http://www.nottoxic.com/wapcc/dectop/wiki/lib/exe/fetch.php?cache=cache&media=hardware:dectop:dectoplb.jpg
>> The BIOS chip is soldered.
> 
> It looks like J11 may also have the LPC bus signals. 

Could be.

I assumed LVDS on 
http://www.nottoxic.com/wapcc/dectop/wiki/doku.php?id=hardware:dectop:erweiterungen#lvds_connector 
- I'll have to check e.g. the voltage levels on pins 8/18 (5 or 3.3V) 
and 19/20 (12 V). Is there a typical default pinout for LPC?

http://www.artecgroup.com/downloads/task,doc_download/gid,5/Itemid,33/ 
could use anything.

I've seen other applications which used 20 pin connectors for GPIO purposes


 > If the boot
> flash selector ball is also on J11 you could use Artec's dongle or
> just another LPC flash chip to work on coreboot rather than having to
> desolder the existing chip.

I know that the BIOS can be programmed easily onboard since there's a 
Windows software around to reprogram it.

Is there any kind of de-assembler within coreboot that would help to 
find out what the current BIOS versions do?

Thanks,
Martin



From stepan at coresystems.de  Sun Mar  2 13:12:55 2008
From: stepan at coresystems.de (Stefan Reinauer)
Date: Sun, 2 Mar 2008 13:12:55 +0100
Subject: [coreboot] [RFC] port bochs-bios to gcc
In-Reply-To: <20080225140332.GA27071@double.lan>
References: <20080222034440.GA3852@double.lan>
	<fdaac4d50802250241t213df01fv6454dd784109be36@mail.gmail.com>
	<20080225140332.GA27071@double.lan>
Message-ID: <20080302121255.GA19286@coresystems.de>

* Kevin O'Connor <kevin at koconnor.net> [080225 15:03]:
> I'll take a look at this later tonight (along with your other
> questions).
> 
> I have been placing my most recent work at:
> 
> http://linuxtogo.org/~kevin/legacybios/
> 
> Indeed, I just pushed a 0.1.2 tar file.  I agree this needs to be
> moved to source control - I just need to find a home.
 
We'd be glad to host the project on coreboot.org, if you wish.

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 smittys.pointclark.net  Sun Mar  2 18:03:43 2008
From: joe at smittys.pointclark.net (joe at smittys.pointclark.net)
Date: Sun, 02 Mar 2008 12:03:43 -0500
Subject: [coreboot] flashrom issues??
In-Reply-To: <20080301123404.lsocj753k88k08k4@www.smittys.pointclark.net>
References: <20080216134533.6awmn90xcsww80c4@www.smittys.pointclark.net>
	<20080219112943.6w24vj5rc0okkc4s@www.smittys.pointclark.net>
	<20080219163507.GA21962@coresystems.de>
	<20080229123601.4dnjxissn40c4gw8@www.smittys.pointclark.net>
	<20080229190715.GA10976@coresystems.de> <47C8593F.1030607@gmx.net>
	<20080229192145.GA15773@coresystems.de> <47C89FC3.3000207@gmx.net>
	<20080301080454.x1rgbpahwwks4k8c@www.smittys.pointclark.net>
	<47C978F4.4030904@gmx.net>
	<20080301123404.lsocj753k88k08k4@www.smittys.pointclark.net>
Message-ID: <20080302120343.ce1rrwrgo4ggw4gc@www.smittys.pointclark.net>

Quoting joe at smittys.pointclark.net:

>>> To check this with superiotool I have to be able to dump the
>>> "Runtime Registers", this is where the GPIO's are (See the SMSC
>>> lpc47m192 datasheet for more info). Currently superiotool does not
>>> dump these registers so modifications will be required.
>>
>> I was relying on the new extended superiotool dumping functionality.
>> That doesn't exist yet for your superio, so I should have written
>> "...can find out with superiotool (once that has GPIO dumping support
>> for your superio) and...". Thanks for correcting me.
>>
> I am working on this right now.....
>
hmm, I think I did everthing right but my dumps are coming back with  
all zero's, not the default values. Would someone mind taking a look  
to see what I am doing wrong in the attached smsc.c

I need to fix the format, but here is the output:

[root at localhost superiotool]# superiotool -de
superiotool r3121
Found SMSC LPC47M15x/192/997 (id=0x60, rev=0x01) at 0x2e
Register dump:
idx 03 07 20 21 22 23 24 26  27 28 2a 2b 2c 2d 2e 2f
val 00 0a 60 01 10 00 44 2e  00 00 00 00 00 00 00 00
def RR 00 60 NA 00 00 44 MM  MM RR NA NA NA NA NA NA
LDN 0x00 (Floppy)
idx 30 60 61 70 74 f0 f1 f2  f4 f5
val 00 03 f0 06 02 0e 00 ff  00 00
def 00 03 f0 06 02 0e 00 ff  00 00
LDN 0x03 (Parallel port)
idx 30 60 61 70 74 f0 f1
val 00 03 78 07 04 3c 00
def 00 00 00 00 04 3c 00
LDN 0x04 (COM1)
idx 30 60 61 70 f0
val 01 03 f8 04 00
def 00 00 00 00 00
LDN 0x05 (COM2 / IR)
idx 30 60 61 70 f0 f1 f2
val 00 00 00 00 00 02 03
def NA 00 00 00 00 02 03
LDN 0x07 (Keyboard)
idx 30 70 72 f0
val 01 01 0c 00
def 00 00 00 00
LDN 0x09 (Game port)
idx 30 60 61
val 00 00 00
def 00 00 00
LDN 0x0a (Power Management Events (PME))
idx 30 60 61 f0
val 01 0a 00 00
def 00 00 00 NA
LDN 0x0b (MPU-401)
idx 30 60 61 70
val 00 03 30 05
def 00 03 30 05
PME I/O Base Address (0x0a00)
Register dump:
idx 00 02 04 05 06 07 08 0a  0b 0c 0d 0e 10 11 12 13  14 16 17 18 19  
1a 1c 1e  1f 20 21 22 23 24 25 26  27 28 29 2a 2b 2c 2d 2f
val 00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  00 00 00 00 00  
00 00 00  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00
def 00 00 00 00 00 00 00 00  00 00 00 00 02 00 00 00  00 00 00 00 00  
00 00 03  NA NA NA 00 01 01 01 01  01 01 01 01 01 01 01 01
Register dump:
idx 30 31 32 33 34 35 36 37  38 39 3a 3b 3c 3d 3e 3f  40 41 42 43 44  
45 46 47  48 4b 4c 4d 4e 4f 50 56  57 58 59 5a 5b 5c 5d 5e  5f
val 00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  00 00 00 00 00  
00 00 00  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  00
def 01 01 01 01 01 01 01 05  04 01 01 01 01 01 01 01  01 01 00 01 01  
01 01 01  01 00 00 00 00 00 00 00  00 50 00 00 00 00 00 00  00



Thanks - Joe
-------------- next part --------------
/*
 * This file is part of the superiotool project.
 *
 * Copyright (C) 2007 Uwe Hermann <uwe at hermann-uwe.de>
 *
 * This program is free software; you can redistribute it and/or modify
 * it under the terms of the GNU General Public License as published by
 * 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 "superiotool.h"

#define DEVICE_ID_REG_OLD	0x0d
#define DEVICE_REV_REG_OLD	0x0e

#define DEVICE_ID_REG   	0x20
#define DEVICE_REV_REG  	0x21

static const struct superio_registers reg_table[] = {
	/* The following Super I/Os use the 0x20/0x21 ID registers. */
	{0x03, "FDC37C93xFR", {
		/* FIXME: There's another 0x03 but found on port 0x0d/0x0e! */
		{EOT}}},
	{0x0a, "FDC37N971", {
		{EOT}}},
	{0x0b, "FDC37N972", {
		{EOT}}},
	{0x0e, "LPC47N252", {	/* From sensors-detect */
		{EOT}}},
	{0x14, "LPC47M172", {
		{EOT}}},
	{0x30, "FDC37C93xAPM", {
		{EOT}}},
	{0x40, "FDC37C67x", {	/* E.g. FDC37C672. Chiprev: 0x01 */
		{NOLDN, NULL,
			{0x03,0x20,0x21,0x22,0x23,0x24,0x26,0x27,0x2b,0x2c,
			 0x2d,0x2e,0x2f,EOT},
			{0x03,0x40,NANA,0x00,0x00,0x04,MISC,MISC,NANA,NANA,
			 NANA,NANA,NANA,EOT}},
		{0x0, "Floppy",
			{0x30,0x60,0x61,0x70,0x74,0xf0,0xf1,0xf2,0xf4,0xf5,
			 EOT},
			{0x00,0x03,0xf0,0x06,0x02,0x0e,0x00,0xff,0x00,0x00,
			 EOT}},
		{0x3, "Parallel port",
			{0x30,0x60,0x61,0x70,0x74,0xf0,0xf1,EOT},
			{0x00,0x00,0x00,0x00,0x04,0x3c,0x00,EOT}},
		{0x4, "COM1",
			{0x30,0x60,0x61,0x70,0xf0,EOT},
			{0x00,0x00,0x00,0x00,0x00,EOT}},
		{0x5, "COM2",
			{0x30,0x60,0x61,0x62,0x63,0x70,0x74,0xf0,0xf1,0xf2,
			 EOT},
			{0x00,0x00,0x00,0x00,0x00,0x00,0x04,0x00,0x02,0x03,
			 EOT}},
		{0x7, "Keyboard",
			{0x30,0x70,0x72,0xf0,EOT},
			{0x00,0x00,0x00,0x00,EOT}},
		{0x8, "Aux I/O",
			{0x30,0xb4,0xb5,0xb6,0xb7,0xc0,0xc1,0xc2,0xc3,0xc4,
			 0xf1,0xf2,0xf3,0xf4,0xf6,0xf7,0xf8,0xf9,0xfa,0xfb,
			 EOT},
			{0x00,NANA,NANA,NANA,NANA,0x06,0x03,NANA,NANA,NANA,
			 0x00,0x00,0x00,MISC,RSVD,RSVD,RSVD,RSVD,RSVD,RSVD,
			 EOT}},
		{EOT}}},
	{0x42, "FDC37B80x/FDC37M707", {
		{EOT}}},
	{0x09, "FDC37N958FR", {	/* Found in e.g. Dell Latitude CPi A366XT. */
		{NOLDN, NULL,
			{0x03,0x07,0x20,0x21,0x22,0x23,0x24,0x26,0x27,0x28,
			 0x2b,0x2c,0x2d,0x2e,0x2f,EOT},
			{0x03,NANA,0x44,0x00,0x00,0x00,0x04,MISC,MISC,0x00,
			 NANA,NANA,NANA,NANA,NANA,EOT}},
		{0x0, "Floppy",
			{0x30,0x60,0x61,0x70,0x74,0xf0,0xf1,0xf2,0xf4,0xf5,
			 EOT},
			{0x00,0x03,0xf0,0x06,0x02,0x0e,0x00,0xff,0x00,0x00,
			 EOT}},
		{0x3, "Parallel port",
			{0x30,0x60,0x61,0x70,0x74,0xf0,0xf1,EOT},
			{0x00,0x00,0x00,0x00,0x04,0x3c,0x00,EOT}},
		{0x4, "COM1",
			{0x30,0x60,0x61,0x70,0xf0,EOT},
			{0x00,0x00,0x00,0x00,0x00,EOT}},
		{0x5, "COM2",
			{0x30,0x60,0x61,0x62,0x63,0x70,0x74,0xf0,0xf1,0xf2,
			 EOT},
			{NANA,0x00,0x00,0x00,0x00,0x00,0x04,0x00,0x02,0x03,
			 EOT}},
		{0x6, "Real-time clock (RTC)",
			{0x30,0x62,0x63,0x70,0xf0,EOT},
			{0x00,0x00,0x70,0x00,0x00,EOT}},
		{0x7, "Keyboard",
			{0x30,0x70,0x72,0xf0,EOT},
			{0x00,0x00,0x00,0x00,EOT}},
		{0x8, "Aux I/O",
			{0x30,0xb0,0xb1,0xb2,0xb3,0xb8,0xc0,0xc1,0xc2,0xc3,
			 0xc4,0xc5,0xc6,0xc8,0xca,0xcb,0xcc,0xd0,0xd1,0xd2,
			 0xd3,0xd4,0xd5,0xd6,0xd7,0xe0,0xe1,0xe2,0xe3,0xe4,
			 0xe5,0xe6,0xe7,0xef,0xf0,0xf1,0xf2,0xf3,0xf4,0xf6,
			 0xf9,0xfa,EOT},
			{0x00,NANA,NANA,NANA,NANA,NANA,NANA,0x01,NANA,NANA,
			 NANA,0x00,NANA,NANA,NANA,NANA,NANA,NANA,NANA,NANA,
			 NANA,NANA,NANA,NANA,NANA,NANA,NANA,NANA,NANA,NANA,
			 NANA,NANA,NANA,NANA,NANA,0x00,0x00,0x00,0x00,NANA,
			 NANA,NANA,EOT}},
		{0xa, "ACPI",
			{0x30,0x60,0x61,0x70,0xf0,EOT},
			{0x00,0x00,0x00,NANA,NANA,EOT}},
		{EOT}}},
	{0x43, "FDC37B77x", {
		{EOT}}},
	{0x44, "FDC37B78x", {
		{NOLDN, NULL,
			{0x03,0x07,0x20,0x21,0x22,0x23,0x24,0x26,0x27,0x28,
			 0x2b,0x2c,0x2d,0x2e,0x2f,EOT},
			{0x03,NANA,0x44,0x00,0x00,0x00,0x04,MISC,MISC,0x00,
			 NANA,NANA,NANA,NANA,NANA,EOT}},
		{0x0, "Floppy",
			{0x30,0x60,0x61,0x70,0x74,0xf0,0xf1,0xf2,0xf4,0xf5,
			 EOT},
			{0x00,0x03,0xf0,0x06,0x02,0x0e,0x00,0xff,0x00,0x00,
			 EOT}},
		{0x3, "Parallel port",
			{0x30,0x60,0x61,0x70,0x74,0xf0,0xf1,EOT},
			{0x00,0x00,0x00,0x00,0x04,0x3c,0x00,EOT}},
		{0x4, "COM1",
			{0x30,0x60,0x61,0x70,0xf0,EOT},
			{0x00,0x00,0x00,0x00,0x00,EOT}},
		{0x5, "COM2",
			{0x30,0x60,0x61,0x62,0x63,0x70,0x74,0xf0,0xf1,0xf2,
			 EOT},
			{NANA,0x00,0x00,0x00,0x00,0x00,0x04,0x00,0x02,0x03,
			 EOT}},
		{0x6, "Real-time clock (RTC)",
			{0x30,0x62,0x63,0x70,0xf0,EOT},
			{0x00,0x00,0x70,0x00,0x00,EOT}},
		{0x7, "Keyboard",
			{0x30,0x70,0x72,0xf0,EOT},
			{0x00,0x00,0x00,0x00,EOT}},
		{0x8, "Aux I/O",
			{0x30,0xb0,0xb1,0xb2,0xb3,0xb8,0xc0,0xc1,0xc2,0xc3,
			 0xc4,0xc5,0xc6,0xc8,0xca,0xcb,0xcc,0xd0,0xd1,0xd2,
			 0xd3,0xd4,0xd5,0xd6,0xd7,0xe0,0xe1,0xe2,0xe3,0xe4,
			 0xe5,0xe6,0xe7,0xef,0xf0,0xf1,0xf2,0xf3,0xf4,0xf6,
			 0xf9,0xfa,EOT},
			{0x00,NANA,NANA,NANA,NANA,NANA,NANA,0x01,NANA,NANA,
			 NANA,0x00,NANA,NANA,NANA,NANA,NANA,NANA,NANA,NANA,
			 NANA,NANA,NANA,NANA,NANA,NANA,NANA,NANA,NANA,NANA,
			 NANA,NANA,NANA,NANA,NANA,0x00,0x00,0x00,0x00,NANA,
			 NANA,NANA,EOT}},
		{0xa, "ACPI",
			{0x30,0x60,0x61,0x70,0xf0,EOT},
			{0x00,0x00,0x00,NANA,NANA,EOT}},
		{EOT}}},
	{0x47, "FDC37M60x", {	/* TODO: Not yet in sensors-detect */
		{EOT}}},
	{0x4c, "FDC37B72x", {
		{NOLDN, NULL,
			{0x03,0x07,0x20,0x21,0x22,0x23,0x24,0x26,0x27,0x28,
			 0x2b,0x2c,0x2d,0x2e,0x2f,EOT},
			{0x03,NANA,0x4c,0x00,0x00,0x00,0x04,MISC,MISC,0x00,
			 NANA,NANA,NANA,NANA,NANA,EOT}},
		{0x0, "Floppy",
			{0x30,0x60,0x61,0x70,0x74,0xf0,0xf1,0xf2,0xf4,0xf5,
			 EOT},
			{0x00,0x03,0xf0,0x06,0x02,0x0e,0x00,0xff,0x00,0x00,
			 EOT}},
		{0x3, "Parallel port",
			{0x30,0x60,0x61,0x70,0x74,0xf0,0xf1,EOT},
			{0x00,0x00,0x00,0x00,0x04,0x3c,0x00,EOT}},
		{0x4, "COM1",
			{0x30,0x60,0x61,0x70,0xf0,EOT},
			{0x00,0x00,0x00,0x00,0x00,EOT}},
		{0x5, "COM2",
			{0x30,0x60,0x61,0x70,0xf0,0xf1,0xf2,EOT},
			{NANA,0x00,0x00,0x00,0x00,0x02,0x03,EOT}},
		{0x7, "Keyboard",
			{0x30,0x70,0x72,0xf0,EOT},
			{0x00,0x00,0x00,0x00,EOT}},
		{0x8, "Aux I/O",
			{0x30,0xb0,0xb1,0xb2,0xb3,0xb8,0xc0,0xc1,0xc2,0xc3,
			 0xc4,0xc5,0xc6,0xc8,0xca,0xcb,0xcc,0xd0,0xd1,0xd2,
			 0xd3,0xd4,0xd5,0xd6,0xd7,0xe0,0xe1,0xe2,0xe3,0xe4,
			 0xe5,0xe6,0xe7,0xef,0xf0,0xf1,0xf2,0xf3,0xf4,0xf6,
			 0xf9,0xfa,EOT},
			{0x00,NANA,NANA,NANA,NANA,NANA,0x00,0x01,NANA,NANA,
			 NANA,0x00,NANA,NANA,NANA,NANA,NANA,NANA,NANA,NANA,
			 NANA,NANA,NANA,NANA,NANA,NANA,NANA,NANA,NANA,NANA,
			 NANA,NANA,NANA,NANA,NANA,0x00,0x00,0x00,MISC,NANA,
			 NANA,NANA,EOT}},
		{0xa, "ACPI",
			{0x30,0x60,0x61,0x70,0xf0,EOT},
			{0x00,0x00,0x00,NANA,NANA,EOT}},
		{EOT}}},
	{0x4d, "FDC37M81x", {
		{NOLDN, NULL,
			{0x03,0x07,0x20,0x21,0x22,0x23,0x24,0x26,0x27,0x2b,
			 0x2c,0x2d,0x2e,0x2f,EOT},
			{0x03,0x00,0x4d,NANA,0x00,0x00,0x04,MISC,MISC,NANA,
			 NANA,NANA,NANA,NANA,EOT}},
		{0x0, "Floppy",
			{0x30,0x60,0x61,0x70,0x74,0xf0,0xf1,0xf2,0xf4,
			 0xf5,EOT},
			{0x00,0x03,0xf0,0x06,0x02,0x0e,0x00,0xff,0x00,
			 0x00,EOT}},
		{0x3, "Parallel port",
			{0x30,0x60,0x61,0x70,0x74,0xf0,0xf1,EOT},
			{0x00,0x00,0x00,0x00,0x04,0x3c,0x00,EOT}},
		{0x4, "COM1",
			{0x30,0x60,0x61,0x70,0xf0,EOT},
			{0x00,0x00,0x00,0x00,0x00,EOT}},
		{0x5, "COM2",
			{0x30,0x60,0x61,0x62,0x63,0x70,0xf0,0xf1,0xf2,EOT},
			{0x00,0x00,0x00,RSVD,RSVD,0x00,0x00,0x02,0x03,EOT}},
		{0x7, "Keyboard",
			{0x30,0x70,0x72,0xf0,EOT},
			{0x00,0x00,0x00,0x00,EOT}},
		{0x8, "Aux I/O",
			/* Only 0xf6 existing (and reserved) or 0xf6..0xfb? */
			{0x30,0xb4,0xb5,0xb6,0xb7,0xc0,0xc1,0xc2,0xc3,0xc4,
			 0xc5,0xc6,0xc7,0xc8,0xf1,0xf2,0xf3,0xf4,0xf6,0xf7,
			 0xf8,0xf9,0xfa,0xfb,EOT},
			{0x00,NANA,NANA,NANA,NANA,0x02,0x01,NANA,NANA,NANA,
			 NANA,NANA,NANA,NANA,0x00,0x00,0x00,0x00,RSVD,RSVD,
			 RSVD,RSVD,RSVD,RSVD,EOT}},
		{EOT}}},
	{0x51, "LPC47B27x", {
		{NOLDN, NULL,
			{0x03,0x20,0x21,0x22,0x23,0x24,0x26,0x27,0x28,
			 0x2a,0x2b,0x2c,0x2d,0x2e,0x2f,EOT},
			{RSVD,0x51,NANA,0x00,0x00,0x04,MISC,MISC,RSVD,
			 NANA,NANA,NANA,NANA,NANA,NANA,EOT}},
		{0x0, "Floppy",
			{0x30,0x60,0x61,0x70,0x74,0xf0,0xf1,0xf2,0xf4,0xf5,
			 EOT},
			{0x00,0x03,0xf0,0x06,0x02,0x0e,0x00,0xff,0x00,0x00,
			 EOT}},
		{0x3, "Parallel port",
			{0x30,0x60,0x61,0x70,0x74,0xf0,0xf1,EOT},
			{0x00,0x00,0x00,0x00,0x04,0x3c,0x00,EOT}},
		{0x4, "COM1",
			{0x30,0x60,0x61,0x70,0xf0,EOT},
			{0x00,0x00,0x00,0x00,0x00,EOT}},
		{0x5, "COM2",
			{0x30,0x60,0x61,0x62,0x63,0x70,0x74,0xf0,0xf1,0xf2,
			 EOT},
			{NANA,0x00,0x00,0x00,0x00,0x00,0x04,0x00,0x02,0x03,
			 EOT}},
		{0x7, "Keyboard",
			{0x30,0x70,0x72,0xf0,EOT},
			{0x00,0x00,0x00,0x00,EOT}},
		{0x9, "Game port",
			{0x30,0x60,0x61,EOT},
			{0x00,0x00,0x00,EOT}},
		{0xa, "Power-management events (PME)",
			{0x30,0x60,0x61,0xf0,0xf1,EOT},
			{0x00,0x00,0x00,NANA,NANA,EOT}},
		{0xb, "MIDI port (MPU-401)",
			{0x30,0x60,0x61,0x70,EOT},
			{0x00,0x03,0x30,0x05,EOT}},
		{EOT}}},
	{0x52, "LPC47B37x", {
		{EOT}}},
	{0x54, "LPC47U33x", {
		{EOT}}},
	{0x56, "LPC47B34x", {
		{EOT}}},
	{0x57, "LPC47S42x", {
		{EOT}}},
	{0x59, "LPC47M10x/112/13x", {
		{NOLDN, NULL,
			{0x03,0x07,0x20,0x21,0x22,0x23,0x24,0x26,0x27,0x28,
			 0x2a,0x2b,0x2c,0x2d,0x2e,0x2f,EOT},
			{RSVD,0x00,0x59,NANA,0x00,0x00,0x44,MISC,MISC,RSVD,
			 NANA,NANA,NANA,NANA,NANA,NANA,EOT}},
		{0x0, "Floppy",
			{0x30,0x60,0x61,0x70,0x74,0xf0,0xf1,0xf2,0xf4,
			 0xf5,EOT},
			{0x00,0x03,0xf0,0x06,0x02,0x0e,0x00,0xff,0x00,
			 0x00,EOT}},
		{0x3, "Parallel port",
			{0x30,0x60,0x61,0x70,0x74,0xf0,0xf1,EOT},
			{0x00,0x00,0x00,0x00,0x04,0x3c,0x00,EOT}},
		{0x4, "COM1",
			{0x30,0x60,0x61,0x70,0xf0,EOT},
			{0x00,0x00,0x00,0x00,0x00,EOT}},
		{0x5, "COM2",
			{0x30,0x60,0x61,0x62,0x63,0x70,0x74,0xf0,0xf1,
			 0xf2,EOT},
			{NANA,0x00,0x00,RSVD,RSVD,0x00,RSVD,0x00,0x02,
			 0x03,EOT}},
		{0x7, "Keyboard",
			{0x30,0x70,0x72,0xf0,EOT},
			{0x00,0x00,0x00,0x00,EOT}},
		{0x9, "Game port",
			{0x30,0x60,0x61,EOT},
			{0x00,0x00,0x00,EOT}},
		{0xa, "Power Management Events (PME)",
			{0x30,0x60,0x61,0xf0,0xf1,EOT},
			{0x00,0x00,0x00,NANA,RSVD,EOT}},
		{0xb, "MPU-401",
			{0x30,0x60,0x61,0x70,EOT},
			{0x00,0x03,0x30,0x05,EOT}},
		{EOT}}},
	{0x5d, "LPC47B357", {	/* From sensors-detect (no datasheet) */
		{EOT}}},
	{0x5f, "LPC47M14x", {
		{EOT}}},
	{0x60, "LPC47M15x/192/997", {
		{NOLDN, NULL,
			{0x03,0x07,0x20,0x21,0x22,0x23,0x24,0x26,0x27,0x28,
			 0x2a,0x2b,0x2c,0x2d,0x2e,0x2f,EOT},
			{RSVD,0x00,0x60,NANA,0x00,0x00,0x44,MISC,MISC,RSVD,
			 NANA,NANA,NANA,NANA,NANA,NANA,EOT}},
		{0x0, "Floppy",
			{0x30,0x60,0x61,0x70,0x74,0xf0,0xf1,0xf2,0xf4,0xf5,
			 EOT},
			{0x00,0x03,0xf0,0x06,0x02,0x0e,0x00,0xff,0x00,0x00,
			 EOT}},
		{0x3, "Parallel port",
			{0x30,0x60,0x61,0x70,0x74,0xf0,0xf1,EOT},
			{0x00,0x00,0x00,0x00,0x04,0x3c,0x00,EOT}},
		{0x4, "COM1",
			{0x30,0x60,0x61,0x70,0xf0,EOT},
			{0x00,0x00,0x00,0x00,0x00,EOT}},
		{0x5, "COM2 / IR",
			{0x30,0x60,0x61,0x70,0xf0,0xf1,0xf2,EOT},
			{NANA,0x00,0x00,0x00,0x00,0x02,0x03,EOT}},
		{0x7, "Keyboard",
			{0x30,0x70,0x72,0xf0,EOT},
			{0x00,0x00,0x00,0x00,EOT}},
		{0x9, "Game port",
			{0x30,0x60,0x61,EOT},
			{0x00,0x00,0x00,EOT}},
		{0xa, "Power Management Events (PME)",
			{0x30,0x60,0x61,0xf0,EOT},
			{0x00,0x00,0x00,NANA,EOT}},
		{0xb, "MPU-401",
			{0x30,0x60,0x61,0x70,EOT},
			{0x00,0x03,0x30,0x05,EOT}},
		{EOT}}},
	{0x62, "LPC47S45x", {
		{EOT}}},
	{0x6b, "LPC47M292", {	/* From sensors-detect */
		{EOT}}},
	{0x6e, "LPC47B387", {	/* TODO: Not yet in sensors-detect */
		/* Found in the HP Compaq Business Desktop d530 Series */
		/* http://article.gmane.org/gmane.linux.bios/27192 */
		/* We cannot find a public datasheet for this Super I/O. */
		{EOT}}},
	{0x6f, "LPC47B397", {
		{EOT}}},
	{0x74, "LPC47M182", {
		{EOT}}},
	{0x76, "LPC47M584", {	/* From sensors-detect (no datasheet) */
		{EOT}}},
	{0x77, "A8000", {	/* ASUS A8000, a rebranded DME1737(?) */
		{NOLDN, NULL,
			{0x03,0x07,0x20,0x21,0x22,0x23,0x24,0x26,0x27,0x28,
			 0x2a,0x2b,0x2c,0x2d,0x2e,0x2f,EOT},
			{RSVD,0x00,0x77,NANA,0x00,RSVD,0x44,MISC,MISC,RSVD,
			 NANA,NANA,NANA,NANA,NANA,NANA,EOT}},
		{0x0, "Floppy",
			{0x30,0x60,0x61,0x70,0x74,0xf0,0xf1,0xf2,0xf4,
			 0xf5,EOT},
			{0x00,0x03,0xf0,0x06,0x02,0x0e,0x00,0xff,0x00,
			 0x00,EOT}},
		{0x3, "Parallel port",
			{0x30,0x60,0x61,0x70,0x74,0xf0,0xf1,EOT},
			{0x00,0x00,0x00,0x00,0x04,0x3c,0x00,EOT}},
		{0x4, "COM1",
			{0x30,0x60,0x61,0x70,0xf0,EOT},
			{0x00,0x00,0x00,0x00,0x00,EOT}},
		{0x5, "COM2",
			{0x30,0x60,0x61,0x70,0xf0,0xf1,0xf2,EOT},
			{0x00,0x00,0x00,0x00,0x00,0x02,0x03,EOT}},
		{0x7, "Keyboard",
			{0x30,0x70,0x72,0xf0,EOT},
			{0x00,0x00,0x00,0x00,EOT}},
		{0xa, "Runtime registers",
			{0x30,0x60,0x61,0x62,0x63,0xf0,0xf1,0xf2,EOT},
			{0x00,0x00,0x00,0x00,0x00,NANA,RSVD,0x04,EOT}},
		{EOT}}},
	{0x78, "DME1737", {
		{NOLDN, NULL,
			{0x03,0x07,0x20,0x21,0x22,0x23,0x24,0x26,0x27,0x28,
			 0x2a,0x2b,0x2c,0x2d,0x2e,0x2f,EOT},
			{RSVD,0x00,0x77,NANA,0x00,RSVD,0x44,MISC,MISC,RSVD,
			 NANA,NANA,NANA,NANA,NANA,NANA,EOT}},
		{0x0, "Floppy",
			{0x30,0x60,0x61,0x70,0x74,0xf0,0xf1,0xf2,0xf4,
			 0xf5,EOT},
			{0x00,0x03,0xf0,0x06,0x02,0x0e,0x00,0xff,0x00,
			 0x00,EOT}},
		{0x3, "Parallel port",
			{0x30,0x60,0x61,0x70,0x74,0xf0,0xf1,EOT},
			{0x00,0x00,0x00,0x00,0x04,0x3c,0x00,EOT}},
		{0x4, "COM1",
			{0x30,0x60,0x61,0x70,0xf0,EOT},
			{0x00,0x00,0x00,0x00,0x00,EOT}},
		{0x5, "COM2",
			{0x30,0x60,0x61,0x70,0xf0,0xf1,0xf2,EOT},
			{0x00,0x00,0x00,0x00,0x00,0x02,0x03,EOT}},
		{0x7, "Keyboard",
			{0x30,0x70,0x72,0xf0,EOT},
			{0x00,0x00,0x00,0x00,EOT}},
		{0xa, "Runtime registers",
			{0x30,0x60,0x61,0x62,0x63,0xf0,0xf1,0xf2,EOT},
			{0x00,0x00,0x00,0x00,0x00,NANA,RSVD,0x04,EOT}},
		{EOT}}},
	{0x79, "SCH5504", {	/* From sensors-detect (no datasheet) */
		{EOT}}},
#if 0
	{0x7a, "Unknown", {	/* Found in Toshiba Satellite A80-117. */
		{EOT}}},
#endif
	{0x7c, "SCH3112", {
		{EOT}}},
	{0x7d, "SCH3114", {
		{EOT}}},
	{0x7f, "SCH3116", {
		{EOT}}},
	{0x81, "SCH5307", {
		{EOT}}},
	{0x85, "SCH5317", {	/* From sensors-detect */
		{EOT}}},
	{0x90, "SCH4307", {	/* From sensors-detect */
		{EOT}}},

	/* The following Super I/Os use the 0x0d/0x0e ID registers. */
	{0x03, "FDC37C669", {
		/* Init: 0x55, 0x55. Exit: 0xaa. Ports: 0x3f0/0x370. */
		/* Chiprev: 0x02. */
		/* FIXME: There's another 0x03 but found on port 0x20/0x21! */
		{EOT}}},
	{0x04, "FDC37C669FR", {	/* TODO: Not yet in sensors-detect. */
		/* Init: 0x55, 0x55. Exit: 0xaa. Ports: 0x3f0/0x370. */
		{EOT}}},
	{0x13, "LPC47N237", {
		/* Init: 0x55. Exit: 0xaa. Ports: 0x2e/0x4e. */
		{EOT}}},
	{0x28, "FDC37N769", {
		/* Init: 0x55. Exit: 0xaa. Ports: 0x3f0/0x370. */
		{NOLDN, NULL,
			{0x00,0x01,0x02,0x03,0x04,0x05,0x06,0x07,0x08,0x09,
			 0x0a,0x0b,0x0c,0x0d,0x0e,0x0f,0x10,0x11,0x12,0x13,
			 0x14,0x15,0x16,0x17,0x18,0x19,0x1a,0x1b,0x1c,0x1d,
			 0x1e,0x1f,0x20,0x21,0x22,0x23,0x24,0x25,0x26,0x27,
			 0x28,0x29,0x2a,0x2b,0x2c,0x2d,0x2e,0x2f,EOT},
			{0x28,0x9c,0x88,0x70,0x00,0x00,0xff,0x00,0x00,0x00,
			 0x00,0x00,0x02,0x28,NANA,0x00,0x00,0x80,RSVD,RSVD,
			 NANA,NANA,NANA,0x03,RSVD,RSVD,RSVD,RSVD,RSVD,RSVD,
			 0x80,0x00,0x3c,RSVD,RSVD,0x00,0x00,0x00,0x00,0x00,
			 0x00,0x00,RSVD,0x00,0x00,0x03,0x00,0x00,EOT}},
		{EOT}}},
	{0x29, "FDC37N3869/FDC37N869", {
		/* Init: 0x55. Exit: 0xaa. Ports: 0x3f0/0x370. */
		{EOT}}},
	{0x5a, "LPC47N227", {
		/* Init: 0x55. Exit: 0xaa. Ports: 0x2e/0x4e. */
		{NOLDN, NULL,
			{0x00,0x01,0x02,0x03,0x04,0x05,0x06,0x07,0x08,0x09,
			 0x0a,0x0b,0x0c,0x0d,0x0e,0x0f,0x10,0x11,0x12,0x13,
			 0x14,0x15,0x16,0x17,0x18,0x19,0x1a,0x1b,0x1c,0x1d,
			 0x1e,0x1f,0x20,0x21,0x22,0x23,0x24,0x25,0x26,0x27,
			 0x28,0x29,0x2a,0x2b,0x2c,0x2d,0x2e,0x2f,0x30,0x31,
			 0x32,0x33,0x34,0x35,0x36,0x37,0x38,0x39,EOT},
			{0x28,0x9c,0x08,0x70,0x00,0x00,0xff,0x00,RSVD,0x00,
			 0x00,0x00,0x02,0x5a,NANA,0x00,0x00,0x80,MISC,0x00,
			 NANA,NANA,NANA,0x03,RSVD,RSVD,RSVD,RSVD,RSVD,RSVD,
			 RSVD,0x00,0x3c,0x00,0x00,0x00,0x00,0x00,0x00,0x00,
			 0x00,0x80,0x00,0x00,0x00,0x03,0x00,0x00,0x00,0x00,
			 0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x80,EOT}},
		{EOT}}},
	{0x65, "FDC37C665GT/IR", {
		/* Init: 0x55, 0x55. Exit: 0xaa. Port: 0x3f0. */
		/* Chiprev: 0x02 = FDC37C665GT, 0x82 = FDC37C665IR */
		{EOT}}},
	{0x66, "FDC37C666GT", {
		/* Init: 0x55, 0x55. Exit: 0xaa. Port: 0x3f0. Chiprev: 0x02. */
		{EOT}}},
	{EOT}
};

static const struct superio_registers rr_table[] = {
	{0x60, "LPC47M15x/192/997", {
		{NOLDN, NULL,
			{0x00,0x02,0x04,0x05,0x06,0x07,0x08,0x0a,0x0b,0x0c,
			 0x0d,0x0e,0x10,0x11,0x12,0x13,0x14,0x16,0x17,0x18,
			 0x19,0x1a,0x1c,0x1e,0x1f,0x20,0x21,0x22,0x23,0x24,
			 0x25,0x26,0x27,0x28,0x29,0x2a,0x2b,0x2c,0x2d,0x2f,
			 EOT},
			{0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,
			 0x00,0x00,0x02,0x00,0x00,0x00,0x00,0x00,0x00,0x00,
			 0x00,0x00,0x00,0x03,NANA,NANA,NANA,0x00,0x01,0x01,
			 0x01,0x01,0x01,0x01,0x01,0x01,0x01,0x01,0x01,0x01,
			 EOT}},
		{NOLDN, NULL,
			{0x30,0x31,0x32,0x33,0x34,0x35,0x36,0x37,0x38,0x39,
			 0x3a,0x3b,0x3c,0x3d,0x3e,0x3f,0x40,0x41,0x42,0x43,
			 0x44,0x45,0x46,0x47,0x48,0x4b,0x4c,0x4d,0x4e,0x4f,
			 0x50,0x56,0x57,0x58,0x59,0x5a,0x5b,0x5c,0x5d,0x5e,
			 0x5f,EOT},
			{0x01,0x01,0x01,0x01,0x01,0x01,0x01,0x05,0x04,0x01,
			 0x01,0x01,0x01,0x01,0x01,0x01,0x01,0x01,0x00,0x01,
			 0x01,0x01,0x01,0x01,0x01,0x00,0x00,0x00,0x00,0x00,
			 0x00,0x00,0x00,0x50,0x00,0x00,0x00,0x00,0x00,0x00,
			 0x00,EOT}},
		{EOT}}},
	{EOT}
};

static void enter_conf_mode_smsc(uint16_t port)
{
	/* Some of the SMSC Super I/Os have an 0x55,0x55 init, some only
	 * require one 0x55. We do 0x55,0x55 for all of them at the moment,
	 * in the assumption that the extra 0x55 won't hurt the other
	 * Super I/Os. This is verified to be true on (at least) the FDC37N769.
	 */
	outb(0x55, port);
	outb(0x55, port);
}

static void exit_conf_mode_smsc(uint16_t port)
{
	outb(0xaa, port);
}

static void probe_idregs_smsc_helper(uint16_t port, uint8_t idreg,
				     uint8_t revreg)
{
	uint8_t id, rev;
	const char *info = (idreg == 0x20) ? "(idregs=0x20/0x21) "
					   : "(idregs=0x0d/0x0e) ";

	probing_for("SMSC", info, port);

	enter_conf_mode_smsc(port);

	id = regval(port, idreg);
	rev = regval(port, revreg);

	if (superio_unknown(reg_table, id)) {
		if (verbose)
			printf(NOTFOUND "id=0x%02x, rev=0x%02x\n", id, rev);
		exit_conf_mode_smsc(port);
		return;
	}

	printf("Found %s %s (id=0x%02x, rev=0x%02x) at 0x%x\n",
	       (id == 0x77 ? "ASUS" : "SMSC"), get_superio_name(reg_table, id),
	       id, rev, port);
	chip_found = 1;

	dump_superio((id == 0x77 ? "ASUS" : "SMSC"), reg_table, port, id);

	/* Dump Runtime Registers on LPC47M15x/192/997 */
	if (extra_dump) {
		uint16_t rrport;
		regwrite(port, 0x07, 0xa); /* Select LDN A (PME). */

		/* Get i/o base address (stored in LDN A, index 0x60/0x61). */
		rrport = regval(port, 0x60) << 8;
		rrport |= regval(port, 0x61);

		printf("PME I/O Base Address (0x%04x)\n",rrport);
		dump_superio("RUNTIME REGISTERS", rr_table, rrport, id);
	}

	exit_conf_mode_smsc(port);
}

void probe_idregs_smsc(uint16_t port)
{
	probe_idregs_smsc_helper(port, DEVICE_ID_REG, DEVICE_REV_REG);
	probe_idregs_smsc_helper(port, DEVICE_ID_REG_OLD, DEVICE_REV_REG_OLD);
}

void print_smsc_chips(void)
{
	print_vendor_chips("SMSC", reg_table);
}

From r.marek at assembler.cz  Sun Mar  2 18:22:55 2008
From: r.marek at assembler.cz (Rudolf Marek)
Date: Sun, 02 Mar 2008 18:22:55 +0100
Subject: [coreboot] VGA and Asus a8v-e_se
In-Reply-To: <47CA6B0B.6080804@gmail.com>
References: <47CA62D2.3040702@gmail.com> <47CA669B.9090202@assembler.cz>
	<47CA6B0B.6080804@gmail.com>
Message-ID: <47CAE26F.8050102@assembler.cz>


> Rudolf Marek wrote:
>> Hi,
>>
>> I have same motherboard and I did the port to this motherboard/chipset. Can you
>> give me
>>
>> lspci -vvvxxx

you sent me output of lspci -x and I need all xxx ;)

Even this would be ok:
lspci -xxx

> The frequency scaling driver powernow_k8 does not seem to work after
> booting with coreboot. I'm very new to coreboot, but it seemed to me
> that this was related to DSDT, which I haven't done anything about yet.

Well I'm working on some tool to teach coreboot how to create the PSS objects.
If you want to get frequency scaling working.

1) acpidump -t SSDT -b >ssdt.bin
2) iasl -d ssdt.bin
3) send it here ;) you should see some PSS PCT objects. I will tell how to put 
this into the dsdt.asl in src/mainboard/asus....

> Do I need to somehow use that DSDT from the Award BIOS when I boot using
> coreboot to get things like frequency scaling working?

Yep check above.

> 
> I'll send the console messages in the next message.
> 

Ok, I think for some reason the PCIe card does not get to work. I have ATI card 
and it does work.

Hopefully can tell more once I have the lspci dumps from original BIOS.

Rudolf



From r.marek at assembler.cz  Sun Mar  2 18:47:29 2008
From: r.marek at assembler.cz (Rudolf Marek)
Date: Sun, 02 Mar 2008 18:47:29 +0100
Subject: [coreboot] VGA and Asus a8v-e_se
In-Reply-To: <47CA6B0B.6080804@gmail.com>
References: <47CA62D2.3040702@gmail.com> <47CA669B.9090202@assembler.cz>
	<47CA6B0B.6080804@gmail.com>
Message-ID: <47CAE831.9070402@assembler.cz>

Hi,

You need to run the lspci -xxx as root.
(and also the acpidump)
Rudolf



From r.marek at assembler.cz  Sun Mar  2 22:34:37 2008
From: r.marek at assembler.cz (Rudolf Marek)
Date: Sun, 02 Mar 2008 22:34:37 +0100
Subject: [coreboot] VGA and Asus a8v-e_se
In-Reply-To: <47CB1616.6070105@gmail.com>
References: <47CA62D2.3040702@gmail.com> <47CA669B.9090202@assembler.cz>
	<47CA6B0B.6080804@gmail.com> <47CAE831.9070402@assembler.cz>
	<47CB1616.6070105@gmail.com>
Message-ID: <47CB1D6D.9090904@assembler.cz>

Hi,

To fix the powernow add following after following line into dsdt.asl

Processor (\_PR.CPU1, 0x01, 0x000000, 0x00) {}

    Scope (\_PR.CPU0)
     {
         Name (_PCT, Package (0x02)
         {
             ResourceTemplate ()
             {
                 Register (FFixedHW,
                     0x00,               // Bit Width
                     0x00,               // Bit Offset
                     0x0000000000000000, // Address
                     ,)
             },

             ResourceTemplate ()
             {
                 Register (FFixedHW,
                     0x00,               // Bit Width
                     0x00,               // Bit Offset
                     0x0000000000000000, // Address
                     ,)
             }
         })
         Name (_PSS, Package (0x04)
         {
             Package (0x06)
             {
                 0x00000898,
                 0x00014D34,
                 0x00000064,
                 0x00000009,
                 0xE020298E,
                 0x0000018E
             },

             Package (0x06)
             {
                 0x000007D0,
                 0x00014438,
                 0x00000064,
                 0x00000009,
                 0xE0202A0C,
                 0x0000020C
             },

             Package (0x06)
             {
                 0x00000708,
                 0x00011300,
                 0x00000064,
                 0x00000009,
                 0xE0202A8A,
                 0x0000028A
             },

             Package (0x06)
             {
                 0x000003E8,
                 0x00008D04,
                 0x00000064,
                 0x00000009,
                 0xE0202C82,
                 0x00000482
             }
         })
         Name (_PPC, 0x00)
     }

Then just recompile Coreboot. I'm using the powernowd and it does work.


If possible could you send me the lspci -xxx when the coreboot is running too? 
You may also try /LinuxBIOSv2/src/southbridge/via/k8t890/k8t890_pcie.c to edit 
the init function:
static void peg_init(struct device *dev)

I think you can put return at the beginning of the function. There is a chance 
that it will work without anything else. I think problem is in card reset.

I have in plan to cleanup the PCIe init a bit but frankly I dont know if the 
reset is needed and even not sure about the link retrain.

Thanks,
Rudolf



From jonathanrrogers at gmail.com  Sun Mar  2 23:04:25 2008
From: jonathanrrogers at gmail.com (Jonathan Rogers)
Date: Sun, 02 Mar 2008 17:04:25 -0500
Subject: [coreboot] VGA and Asus a8v-e_se
In-Reply-To: <47CAE26F.8050102@assembler.cz>
References: <47CA62D2.3040702@gmail.com> <47CA669B.9090202@assembler.cz>
	<47CA6B0B.6080804@gmail.com> <47CAE26F.8050102@assembler.cz>
Message-ID: <47CB2469.7090306@gmail.com>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Rudolf Marek wrote:
> Ok, I think for some reason the PCIe card does not get to work. I have
> ATI card and it does work.

Yes, that does seem to be the case. I've tried two Nvidia PCIe cards (a
7900GS and a 6600GT) with both 3118 and 3119 and none of those
combinations works. However, an ancient 32-bit Cirrus Logic VGA card
works with both versions of coreboot. Unfortunately, I don't have an ATI
or other type of PCIe card to try right now.

Jonathan Rogers
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFHyyRpMs6f82yVS5wRAgb2AJ4rYmxgEMHLFDIUCG4L7uk2hxKxtgCgvCgH
7xAcAF7wXwTQmy8VqEJakXQ=
=mN2E
-----END PGP SIGNATURE-----



From kevin at koconnor.net  Sun Mar  2 23:50:37 2008
From: kevin at koconnor.net (Kevin O'Connor)
Date: Sun, 2 Mar 2008 17:50:37 -0500
Subject: [coreboot] [RFC] port bochs-bios to gcc
In-Reply-To: <20080302121255.GA19286@coresystems.de>
References: <20080222034440.GA3852@double.lan>
	<fdaac4d50802250241t213df01fv6454dd784109be36@mail.gmail.com>
	<20080225140332.GA27071@double.lan>
	<20080302121255.GA19286@coresystems.de>
Message-ID: <20080302225037.GA31394@double.lan>

On Sun, Mar 02, 2008 at 01:12:55PM +0100, Stefan Reinauer wrote:
> > Indeed, I just pushed a 0.1.2 tar file.  I agree this needs to be
> > moved to source control - I just need to find a home.
>  
> We'd be glad to host the project on coreboot.org, if you wish.
> 
> Stefan

Hi Stefan,

I've got a temporary location using git at http://git.linuxtogo.org/
After I've finished porting the code, I'll look for a permanent home.
Thanks for the offer - it sounds like a good idea.

-Kevin

P.S. things are moving along.  I've ported disk access and can boot
Linux under qemu.



From sync.jma at gmail.com  Mon Mar  3 02:36:33 2008
From: sync.jma at gmail.com (Jun Ma)
Date: Mon, 3 Mar 2008 09:36:33 +0800
Subject: [coreboot] Probe missing on W49F002U
In-Reply-To: <13426df10803010839i2254601ag75df6e764eaf3544@mail.gmail.com>
References: <dcf6addc0802292359q47871439i7d9bf80bb85474cd@mail.gmail.com>
	<13426df10803010839i2254601ag75df6e764eaf3544@mail.gmail.com>
Message-ID: <dcf6addc0803021736s4d0b9458u7d80bf49d01676b2@mail.gmail.com>

On Sun, Mar 2, 2008 at 12:39 AM, ron minnich <rminnich at gmail.com> wrote:
> There is almost certainly an additional write control line on this
> board, and you will have to find it.
>
> It's not too hard to do, let us know if you would like to try.
>
> ron
>

Sorry for my delay.
I have a PCCHIP SIS530 board right in my hand, and datasheets for
SIS530/SIS5595/W49F002U.
but I haven't got any SCH or PCB files for this board,  maybe I should
read the W49F002U DS first?

when you talked about "an additional write control line on this
board", do you mean it was not the problem caused by the BIOS chip?
All SIS530/SIS5595 boards have the same problem?  Would
'amiflash at Win32' or other flash routings have the same problem?

PS: the original BIOS chip for this board is ASD AE29F2008-12, It also
can't be readed by flashrom(and the model was not listed in flashrom
README file).

Can you guide me in a better direction? I will try my best on this test.
Thanks.



From peter at stuge.se  Mon Mar  3 02:58:24 2008
From: peter at stuge.se (Peter Stuge)
Date: Mon, 3 Mar 2008 02:58:24 +0100
Subject: [coreboot] Probe missing on W49F002U
In-Reply-To: <dcf6addc0803021736s4d0b9458u7d80bf49d01676b2@mail.gmail.com>
References: <dcf6addc0802292359q47871439i7d9bf80bb85474cd@mail.gmail.com>
	<13426df10803010839i2254601ag75df6e764eaf3544@mail.gmail.com>
	<dcf6addc0803021736s4d0b9458u7d80bf49d01676b2@mail.gmail.com>
Message-ID: <20080303015824.20707.qmail@stuge.se>

On Mon, Mar 03, 2008 at 09:36:33AM +0800, Jun Ma wrote:
> > There is almost certainly an additional write control line on
> > this board, and you will have to find it.
> >
> > It's not too hard to do, let us know if you would like to try.
> 
> I have a PCCHIP SIS530 board right in my hand, and datasheets for
> SIS530/SIS5595/W49F002U.

Great! This is helpful.


> but I haven't got any SCH or PCB files for this board,  maybe I
> should read the W49F002U DS first?

Yes, that is a good start. Then probably the southbridge (5595?) to
find out about GPIO pins.


> when you talked about "an additional write control line on this
> board", do you mean it was not the problem caused by the BIOS chip?

Correct. Board vendors frequently connect a GPIO signal to the flash
chip write protect input, in order to protect the flash chip from
unintended writes.


> All SIS530/SIS5595 boards have the same problem?

Each board vendor can use different GPIO signals, and some may choose
to not use any GPIO but disable write protect by connecting it
directly to logic 0 or 1, so that there is no "protection."


> Would 'amiflash at Win32' or other flash routings have the same
> problem?

amiflash knows how to control this write protection, other flash
routines may or may not. uniflash for example can call flash
operations in the existing BIOS which know how to control the
protection.


> PS: the original BIOS chip for this board is ASD AE29F2008-12, It
> also can't be readed by flashrom(and the model was not listed in
> flashrom README file).

Ok, if it is not very different from the other supported flash chips
it should not be very difficult to add.


> Can you guide me in a better direction? I will try my best on this
> test.

In order to find out about the GPIO you can either:
* Use a multimeter to check if any GPIO pin on the southbridge is
  connected to the flash chip write protect
* Save all GPIO registers from booting with factory BIOS
  Compare with GPIO registers from booting with coreboot
  Set one GPIO register bit at a time and test if flashrom can
  identify the flash chip automatically. (That requires write to work
  correctly.)


Best regards

//Peter



From rminnich at gmail.com  Mon Mar  3 06:12:58 2008
From: rminnich at gmail.com (ron minnich)
Date: Sun, 2 Mar 2008 21:12:58 -0800
Subject: [coreboot] Probe missing on W49F002U
In-Reply-To: <20080303015824.20707.qmail@stuge.se>
References: <dcf6addc0802292359q47871439i7d9bf80bb85474cd@mail.gmail.com>
	<13426df10803010839i2254601ag75df6e764eaf3544@mail.gmail.com>
	<dcf6addc0803021736s4d0b9458u7d80bf49d01676b2@mail.gmail.com>
	<20080303015824.20707.qmail@stuge.se>
Message-ID: <13426df10803022112g6eb64c1fp9081c6f0e7a24a@mail.gmail.com>

when we worked out a board recently it was really easy.

David, Stefan and I did it.

What we did:

Use superiotoo to dump the superio. Look at GPIOs. Notice that one,
and only one,
GPIO was even enabled. And it was enabled as output.

So we looked at the output value, inverted it, and flashrom worked fine.

This was a few minutes of debugging. It took longer to modify
superiotool to know about this particular superio than it took to
figure out how to write enable flash :-)

You'll just need to dump the states of the GPIOs on the SiS part, see
which ones
are enabled, see which are enabled as outputs, and for a first try, just
invert them all ... you can work out which one is controlling it bit by bit.


ron



From yinghailu at gmail.com  Mon Mar  3 06:39:52 2008
From: yinghailu at gmail.com (yhlu)
Date: Sun, 2 Mar 2008 21:39:52 -0800
Subject: [coreboot] Hiding a PCI device
In-Reply-To: <334282.71431.qm@web51608.mail.re2.yahoo.com>
References: <mailman.752.1204156090.27277.coreboot@coreboot.org>
	<334282.71431.qm@web51608.mail.re2.yahoo.com>
Message-ID: <2ea3fae10803022139n60f0c7cfm8435f16774e31865@mail.gmail.com>

On Thu, Feb 28, 2008 at 8:18 AM, Baski <kbaski at yahoo.com> wrote:
> Hello,
> Is there a way in LB to hide a PCI device from the OS?  I want to prevent
> linux from loading the device driver automatically for a particular PCI
> device. (Similar to a device behind a bridge).  I don't want to do any
> tweaks in linux.

add smi handler to trap pci conf access. the ioport cf8 or the mmconf

YH



From sync.jma at gmail.com  Mon Mar  3 07:10:20 2008
From: sync.jma at gmail.com (Jun Ma)
Date: Mon, 3 Mar 2008 14:10:20 +0800
Subject: [coreboot] Probe missing on W49F002U
In-Reply-To: <20080303015824.20707.qmail@stuge.se>
References: <dcf6addc0802292359q47871439i7d9bf80bb85474cd@mail.gmail.com>
	<13426df10803010839i2254601ag75df6e764eaf3544@mail.gmail.com>
	<dcf6addc0803021736s4d0b9458u7d80bf49d01676b2@mail.gmail.com>
	<20080303015824.20707.qmail@stuge.se>
Message-ID: <dcf6addc0803022210y59fafe8cpcfba348b5bd3c489@mail.gmail.com>

> > but I haven't got any SCH or PCB files for this board,  maybe I
> > should read the W49F002U DS first?
>
> Yes, that is a good start. Then probably the southbridge (5595?) to
> find out about GPIO pins.
>
>
> > when you talked about "an additional write control line on this
> > board", do you mean it was not the problem caused by the BIOS chip?
>
> Correct. Board vendors frequently connect a GPIO signal to the flash
> chip write protect input, in order to protect the flash chip from
> unintended writes.
>
[MJ]  for my poor board SIS5595/W49F002U, there seems no WP#
function, you can get DS from:
http://www.winbond-usa.com/products/winbond_products/pdfs/Memory/w49f002u.pdf

Here are some discription about programming & hardware data protection
on W49F002U :

Program Operation
The W49F002U is programmed on a byte-by-byte basis. Program operation
can only change logical
data "1" to logical data "0". The erase operation (changed entire data
in two main memory blocks and
two parameter blocks and/or boot block from "0" to "1") is needed
before programming.
The program operation is initiated by a 4-byte command code sequence
(see Command Codes for
Byte Programming). The device will internally enter the program
operation immediately after the byteprogram
command is entered. The internal program timer will automatically
time-out (50 mS max. -
TBP). Once completed, the device returns to normal read mode. Data
polling and/or Toggle Bits can
be used to detect end of program cycle.

Hardware Data Protection
The integrity of the data stored in the W49F002U is also hardware
protected in the following ways:
(1) Noise/Glitch Protection: A WE pulse of less than 15 nS in duration
will not initiate a write cycle.
(2) VDD Power Up/Down Detection: The programming operation is
inhibited when VDD is less than
2.5V typical.
(3) Write Inhibit Mode: Forcing OE low, CE high, or WE high will
inhibit the write operation. This
prevents inadvertent writes during power-up or power-down periods.
(4) VDD power-on delay: When VDD has reached its sense level, the
device will automatically time-out
5 mS before any write (erase/program) operation.

>
> > All SIS530/SIS5595 boards have the same problem?
>
> Each board vendor can use different GPIO signals, and some may choose
> to not use any GPIO but disable write protect by connecting it
> directly to logic 0 or 1, so that there is no "protection."
>
[MJ] Understood, Thanks.

>
> > Would 'amiflash at Win32' or other flash routings have the same
> > problem?
>
> amiflash knows how to control this write protection, other flash
> routines may or may not. uniflash for example can call flash
> operations in the existing BIOS which know how to control the
> protection.
>
[MJ]  Thanks, I am a new guy in x86/BIOS field. I choose flashrom
because it is based on linux, while uniflash seems only have a win32
release.

>
> > PS: the original BIOS chip for this board is ASD AE29F2008-12, It
> > also can't be readed by flashrom(and the model was not listed in
> > flashrom README file).
>
> Ok, if it is not very different from the other supported flash chips
> it should not be very difficult to add.
>
[MJ] because I have no more BIOS EEPROM chips in hand, I just tested
W49F002U, after programming by a BIOS programmer, it also works on my
board, :)

>
> > Can you guide me in a better direction? I will try my best on this
> > test.
>
> In order to find out about the GPIO you can either:
> * Use a multimeter to check if any GPIO pin on the southbridge is
>  connected to the flash chip write protect
> * Save all GPIO registers from booting with factory BIOS
>  Compare with GPIO registers from booting with coreboot
>  Set one GPIO register bit at a time and test if flashrom can
>  identify the flash chip automatically. (That requires write to work
>  correctly.)
>
[MJ] I suppose that there has no WP# pin on W49F002U, so there should
not have any GPIO pin connected between South bridge and BIOS.

Thank you for your excellecent help.

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



-- 
FIXME if it is wrong.



From sync.jma at gmail.com  Mon Mar  3 07:17:25 2008
From: sync.jma at gmail.com (Jun Ma)
Date: Mon, 3 Mar 2008 14:17:25 +0800
Subject: [coreboot] Probe missing on W49F002U
In-Reply-To: <13426df10803022112g6eb64c1fp9081c6f0e7a24a@mail.gmail.com>
References: <dcf6addc0802292359q47871439i7d9bf80bb85474cd@mail.gmail.com>
	<13426df10803010839i2254601ag75df6e764eaf3544@mail.gmail.com>
	<dcf6addc0803021736s4d0b9458u7d80bf49d01676b2@mail.gmail.com>
	<20080303015824.20707.qmail@stuge.se>
	<13426df10803022112g6eb64c1fp9081c6f0e7a24a@mail.gmail.com>
Message-ID: <dcf6addc0803022217v6b658a8co5110e85f69d75586@mail.gmail.com>

> What we did:
>
> Use superiotoo to dump the superio. Look at GPIOs. Notice that one,
> and only one,
> GPIO was even enabled. And it was enabled as output.
>
> So we looked at the output value, inverted it, and flashrom worked fine.
>
> This was a few minutes of debugging. It took longer to modify
> superiotool to know about this particular superio than it took to
> figure out how to write enable flash :-)
>
> You'll just need to dump the states of the GPIOs on the SiS part, see
> which ones
> are enabled, see which are enabled as outputs, and for a first try, just
> invert them all ... you can work out which one is controlling it bit by bit.
>

For my poor board with Super I/O chip ITE IT8770F, the superiotool outputs:

Sis530:~/superiotool#
Sis530:~/superiotool# ./superiotool -V
superiotool r
Probing for ALi Super I/O at 0x3f0...
  Failed. Returned data: id=0xffff, rev=0xff
Probing for ALi Super I/O at 0x370...
  Failed. Returned data: id=0xffff, rev=0xff
Probing for Fintek Super I/O at 0x2e...
  Failed. Returned data: vid=0xffff, id=0xffff
Probing for Fintek Super I/O at 0x4e...
  Failed. Returned data: vid=0xffff, id=0xffff
Probing for ITE Super I/O (init=0x87,0x01,0x55,0x55/0xaa) at 0x2e...
  Failed. Returned data: id=0xffff, rev=0xf
Probing for ITE Super I/O (init=0x87,0x87) at 0x2e...
  Failed. Returned data: id=0xffff, rev=0xf
Probing for ITE Super I/O (init=0x87,0x01,0x55,0x55/0xaa) at 0x4e...
  Failed. Returned data: id=0xffff, rev=0xf
Probing for ITE Super I/O (init=0x87,0x87) at 0x4e...
  Failed. Returned data: id=0xffff, rev=0xf
Probing for NSC Super I/O at 0x2e...
  Failed. Returned data: port=0xff, port+1=0xff
Probing for NSC Super I/O at 0x4e...
  Failed. Returned data: port=0xff, port+1=0xff
Probing for SMSC Super I/O (idregs=0x20/0x21) at 0x2e...
  Failed. Returned data: id=0xff, rev=0xff
Probing for SMSC Super I/O (idregs=0x0d/0x0e) at 0x2e...
  Failed. Returned data: id=0xff, rev=0xff
Probing for SMSC Super I/O (idregs=0x20/0x21) at 0x4e...
  Failed. Returned data: id=0xff, rev=0xff
Probing for SMSC Super I/O (idregs=0x0d/0x0e) at 0x4e...
  Failed. Returned data: id=0xff, rev=0xff
Probing for SMSC Super I/O (idregs=0x20/0x21) at 0x162e...
  Failed. Returned data: id=0xff, rev=0xff
Probing for SMSC Super I/O (idregs=0x0d/0x0e) at 0x162e...
  Failed. Returned data: id=0xff, rev=0xff
Probing for SMSC Super I/O (idregs=0x20/0x21) at 0x164e...
  Failed. Returned data: id=0xff, rev=0xff
Probing for SMSC Super I/O (idregs=0x0d/0x0e) at 0x164e...
  Failed. Returned data: id=0xff, rev=0xff
Probing for SMSC Super I/O (idregs=0x20/0x21) at 0x3f0...
  Failed. Returned data: id=0xff, rev=0xff
Probing for SMSC Super I/O (idregs=0x0d/0x0e) at 0x3f0...
  Failed. Returned data: id=0xff, rev=0xff
Probing for SMSC Super I/O (idregs=0x20/0x21) at 0x370...
  Failed. Returned data: id=0xff, rev=0xff
Probing for SMSC Super I/O (idregs=0x0d/0x0e) at 0x370...
  Failed. Returned data: id=0xff, rev=0xff
Probing for Winbond Super I/O (init=0x88) at 0x2e...
  Failed. Returned data: id/oldid=0xff/0x0f, rev=0xff
Probing for Winbond Super I/O (init=0x89) at 0x2e...
  Failed. Returned data: id/oldid=0xff/0x0f, rev=0xff
Probing for Winbond Super I/O (init=0x86,0x86) at 0x2e...
  Failed. Returned data: id/oldid=0xff/0x0f, rev=0xff
Probing for Winbond Super I/O (init=0x87,0x87) at 0x2e...
  Failed. Returned data: id/oldid=0xff/0x0f, rev=0xff
Probing for Winbond Super I/O (init=0x88) at 0x4e...
  Failed. Returned data: id/oldid=0xff/0x0f, rev=0xff
Probing for Winbond Super I/O (init=0x89) at 0x4e...
  Failed. Returned data: id/oldid=0xff/0x0f, rev=0xff
Probing for Winbond Super I/O (init=0x86,0x86) at 0x4e...
  Failed. Returned data: id/oldid=0xff/0x0f, rev=0xff
Probing for Winbond Super I/O (init=0x87,0x87) at 0x4e...
  Failed. Returned data: id/oldid=0xff/0x0f, rev=0xff
Probing for Winbond Super I/O (init=0x88) at 0x3f0...
  Failed. Returned data: id/oldid=0xff/0x0f, rev=0xff
Probing for Winbond Super I/O (init=0x89) at 0x3f0...
  Failed. Returned data: id/oldid=0xff/0x0f, rev=0xff
Probing for Winbond Super I/O (init=0x86,0x86) at 0x3f0...
  Failed. Returned data: id/oldid=0xff/0x0f, rev=0xff
Probing for Winbond Super I/O (init=0x87,0x87) at 0x3f0...
  Failed. Returned data: id/oldid=0xff/0x0f, rev=0xff
Probing for Winbond Super I/O (init=0x88) at 0x370...
  Failed. Returned data: id/oldid=0xff/0x0f, rev=0xff
Probing for Winbond Super I/O (init=0x89) at 0x370...
  Failed. Returned data: id/oldid=0xff/0x0f, rev=0xff
Probing for Winbond Super I/O (init=0x86,0x86) at 0x370...
  Failed. Returned data: id/oldid=0xff/0x0f, rev=0xff
Probing for Winbond Super I/O (init=0x87,0x87) at 0x370...
  Failed. Returned data: id/oldid=0xff/0x0f, rev=0xff
Probing for Winbond Super I/O (init=0x88) at 0x250...
  Failed. Returned data: id/oldid=0xff/0x0f, rev=0xff
Probing for Winbond Super I/O (init=0x89) at 0x250...
  Failed. Returned data: id/oldid=0xff/0x0f, rev=0xff
Probing for Winbond Super I/O (init=0x86,0x86) at 0x250...
  Failed. Returned data: id/oldid=0xff/0x0f, rev=0xff
Probing for Winbond Super I/O (init=0x87,0x87) at 0x250...
  Failed. Returned data: id/oldid=0xff/0x0f, rev=0xff
No Super I/O found
Sis530:~/superiotool#


I saw some comments here:
/**
 * IT871[01]F and IT8708F use 0x87, 0x87
 * IT8761F uses 0x87, 0x61, 0x55, 0x55/0xaa
 * IT86xxF series uses different ports
 * IT8661F uses 0x86, 0x61, 0x55/0xaa, 0x55/0xaa and 32 more writes
 * IT8673F uses 0x86, 0x80, 0x55/0xaa, 0x55/0xaa and 32 more writes
 */
static void enter_conf_mode_ite(uint16_t port)
{
	outb(0x87, port);
	outb(0x01, port);
	outb(0x55, port);
	if (port == 0x2e)
		outb(0x55, port);
	else
		outb(0xaa, port);
}

Not support IT8770F(I guessed)?
also I haven't found any DS about IT8770F on internet, seems I am blind now..



From Libo.Feng at amd.com  Mon Mar  3 11:04:01 2008
From: Libo.Feng at amd.com (Feng, Libo)
Date: Mon, 3 Mar 2008 18:04:01 +0800
Subject: [coreboot] Two questions about 690/600
Message-ID: <DD1CC71B621B004FA76856E5129D6B1701367507@sbjgexmb1.amd.com>


Hi, all, Marc and Yinghai,

We are adapting LB for AMD Herring board based on Turion 64x2 and 690/600. Now we have two questions, could you give us some guide?

1. How to enable the VGA controller on 690? LB has detected the controller, from the previous experience, we seem to need a VBIOS to initialize the controller. But the controller is integrated into the 690, can we handle it just like an onboard controller and put VBIOS at 0xfff80000 and run VBIOS in the function of dev_initialize?

2. 600 is attached to 690 via A-Link, from my understanding, 600 should be on another PCI bus, but from the LB trace, it seems 600 is still on PCI bus 0. Why? The 690 Datasheet says NB/SB Link P2P bridge is hidden by default, is this the reason? 

Thanks.

Best Regards

??? Feng Libo @ AMD  Ext: 20906
Mobile Phone: 13683249071
Office Phone: 0086-010-62801406

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

From joop_boonen at web.de  Mon Mar  3 11:43:14 2008
From: joop_boonen at web.de (Joop Boonen)
Date: Mon, 3 Mar 2008 11:43:14 +0100 (CET)
Subject: [coreboot] LinuxBios on Tyan Tiger S2460 760MP/AMD766
Message-ID: <64220.194.237.142.11.1204540994.squirrel@www.boonen.name>

All,

I've bought a SATAII controller (SIL3124-2) But it doesn't seem to work in
combination with the bios (1.05) on my Tyan main board (Isn't recognised
in the boot process).

Therefore I'm thinking of putting LinuxBios on the main board.

has anyone succeeded in putting LinuxBios on this main board?

Regards,

Joop Boonen.




From peter at stuge.se  Mon Mar  3 12:55:12 2008
From: peter at stuge.se (Peter Stuge)
Date: Mon, 3 Mar 2008 12:55:12 +0100
Subject: [coreboot] Two questions about 690/600
In-Reply-To: <DD1CC71B621B004FA76856E5129D6B1701367507@sbjgexmb1.amd.com>
References: <DD1CC71B621B004FA76856E5129D6B1701367507@sbjgexmb1.amd.com>
Message-ID: <20080303115512.9930.qmail@stuge.se>

Hi,

On Mon, Mar 03, 2008 at 06:04:01PM +0800, Feng, Libo wrote:
> We are adapting LB for AMD Herring board based on Turion 64x2 and
> 690/600.

Good news! :)


> 1. How to enable the VGA controller on 690? LB has detected the
> controller, from the previous experience, we seem to need a VBIOS
> to initialize the controller. But the controller is integrated into
> the 690, can we handle it just like an onboard controller and put
> VBIOS at 0xfff80000 and run VBIOS in the function of dev_initialize?

Yes, including a copy of the VGA BIOS into coreboot is one way to
make it work. Note that for this to be really useful AMD would need
to allow distribution of the VGA BIOS for the 690 - which may or may
not be possible. (Not possible for Geode for example.)

Another way is to write native graphics drivers for coreboot, Linux
framebuffer and X.org. This is how the Geode works, except there is
no coreboot driver so the graphics controller is not initialized at
boot until the Linux kernel framebuffer driver has started.

Personally I prefer this over including a VGA BIOS, but unless
someone also writes a coreboot graphics driver there will be the
drawback of having no graphics at all during the potentially
sensitive step of starting the payload. (If the payload doesn't
work as intendend, many users will require graphics to proceed.)


> 2. 600 is attached to 690 via A-Link, from my understanding, 600
> should be on another PCI bus, but from the LB trace, it seems 600
> is still on PCI bus 0. Why? The 690 Datasheet says NB/SB Link P2P
> bridge is hidden by default, is this the reason? 

I don't know anything about the 690/600 interconnect so I can only
guess here - but you are correct that devices behind a hidden bridge
will appear on the same bus as the bridge.


//Peter



From c-d.hailfinger.devel.2006 at gmx.net  Mon Mar  3 14:26:31 2008
From: c-d.hailfinger.devel.2006 at gmx.net (Carl-Daniel Hailfinger)
Date: Mon, 03 Mar 2008 14:26:31 +0100
Subject: [coreboot] Probe missing on W49F002U
In-Reply-To: <dcf6addc0803022210y59fafe8cpcfba348b5bd3c489@mail.gmail.com>
References: <dcf6addc0802292359q47871439i7d9bf80bb85474cd@mail.gmail.com>	<13426df10803010839i2254601ag75df6e764eaf3544@mail.gmail.com>	<dcf6addc0803021736s4d0b9458u7d80bf49d01676b2@mail.gmail.com>	<20080303015824.20707.qmail@stuge.se>
	<dcf6addc0803022210y59fafe8cpcfba348b5bd3c489@mail.gmail.com>
Message-ID: <47CBFC87.8090005@gmx.net>

On 03.03.2008 07:10, Jun Ma wrote:
> [MJ]  for my poor board SIS5595/W49F002U, there seems no WP#
> function, you can get DS from:
> http://www.winbond-usa.com/products/winbond_products/pdfs/Memory/w49f002u.pdf
>   

There is a write protection function in the W49F002U: #WE, but the 
signal is inverted.


>>> Can you guide me in a better direction? I will try my best on this
>>> test.
>>>       
>> In order to find out about the GPIO you can either:
>> * Use a multimeter to check if any GPIO pin on the southbridge is
>>  connected to the flash chip write protect
>> * Save all GPIO registers from booting with factory BIOS
>>  Compare with GPIO registers from booting with coreboot
>>  Set one GPIO register bit at a time and test if flashrom can
>>  identify the flash chip automatically. (That requires write to work
>>  correctly.)
>>
>>     
> [MJ] I suppose that there has no WP# pin on W49F002U, so there should
> not have any GPIO pin connected between South bridge and BIOS.
>   

See above.

Regards,
Carl-Daniel
-- 
http://www.hailfinger.org/




From c-d.hailfinger.devel.2006 at gmx.net  Mon Mar  3 14:47:13 2008
From: c-d.hailfinger.devel.2006 at gmx.net (Carl-Daniel Hailfinger)
Date: Mon, 03 Mar 2008 14:47:13 +0100
Subject: [coreboot] Probe missing on W49F002U
In-Reply-To: <dcf6addc0803022217v6b658a8co5110e85f69d75586@mail.gmail.com>
References: <dcf6addc0802292359q47871439i7d9bf80bb85474cd@mail.gmail.com>	<13426df10803010839i2254601ag75df6e764eaf3544@mail.gmail.com>	<dcf6addc0803021736s4d0b9458u7d80bf49d01676b2@mail.gmail.com>	<20080303015824.20707.qmail@stuge.se>	<13426df10803022112g6eb64c1fp9081c6f0e7a24a@mail.gmail.com>
	<dcf6addc0803022217v6b658a8co5110e85f69d75586@mail.gmail.com>
Message-ID: <47CC0161.4000706@gmx.net>

On 03.03.2008 07:17, Jun Ma wrote:
>> What we did:
>>
>> Use superiotoo to dump the superio. Look at GPIOs. Notice that one,
>> and only one,
>> GPIO was even enabled. And it was enabled as output.
>>
>> So we looked at the output value, inverted it, and flashrom worked fine.
>>
>> This was a few minutes of debugging. It took longer to modify
>> superiotool to know about this particular superio than it took to
>> figure out how to write enable flash :-)
>>
>> You'll just need to dump the states of the GPIOs on the SiS part, see
>> which ones
>> are enabled, see which are enabled as outputs, and for a first try, just
>> invert them all ... you can work out which one is controlling it bit by bit.
>>
>>     
>
> For my poor board with Super I/O chip ITE IT8770F, the superiotool outputs:
>
> Sis530:~/superiotool#
> Sis530:~/superiotool# ./superiotool -V
> superiotool r
> Probing for ALi Super I/O at 0x3f0...
>   Failed. Returned data: id=0xffff, rev=0xff
> Probing for ALi Super I/O at 0x370...
>   Failed. Returned data: id=0xffff, rev=0xff
> Probing for Fintek Super I/O at 0x2e...
>   Failed. Returned data: vid=0xffff, id=0xffff
> Probing for Fintek Super I/O at 0x4e...
>   Failed. Returned data: vid=0xffff, id=0xffff
> Probing for ITE Super I/O (init=0x87,0x01,0x55,0x55/0xaa) at 0x2e...
>   Failed. Returned data: id=0xffff, rev=0xf
> Probing for ITE Super I/O (init=0x87,0x87) at 0x2e...
>   Failed. Returned data: id=0xffff, rev=0xf
> Probing for ITE Super I/O (init=0x87,0x01,0x55,0x55/0xaa) at 0x4e...
>   Failed. Returned data: id=0xffff, rev=0xf
> Probing for ITE Super I/O (init=0x87,0x87) at 0x4e...
>   Failed. Returned data: id=0xffff, rev=0xf
> Probing for NSC Super I/O at 0x2e...
>   Failed. Returned data: port=0xff, port+1=0xff
> Probing for NSC Super I/O at 0x4e...
>   Failed. Returned data: port=0xff, port+1=0xff
> Probing for SMSC Super I/O (idregs=0x20/0x21) at 0x2e...
>   Failed. Returned data: id=0xff, rev=0xff
> Probing for SMSC Super I/O (idregs=0x0d/0x0e) at 0x2e...
>   Failed. Returned data: id=0xff, rev=0xff
> Probing for SMSC Super I/O (idregs=0x20/0x21) at 0x4e...
>   Failed. Returned data: id=0xff, rev=0xff
> Probing for SMSC Super I/O (idregs=0x0d/0x0e) at 0x4e...
>   Failed. Returned data: id=0xff, rev=0xff
> Probing for SMSC Super I/O (idregs=0x20/0x21) at 0x162e...
>   Failed. Returned data: id=0xff, rev=0xff
> Probing for SMSC Super I/O (idregs=0x0d/0x0e) at 0x162e...
>   Failed. Returned data: id=0xff, rev=0xff
> Probing for SMSC Super I/O (idregs=0x20/0x21) at 0x164e...
>   Failed. Returned data: id=0xff, rev=0xff
> Probing for SMSC Super I/O (idregs=0x0d/0x0e) at 0x164e...
>   Failed. Returned data: id=0xff, rev=0xff
> Probing for SMSC Super I/O (idregs=0x20/0x21) at 0x3f0...
>   Failed. Returned data: id=0xff, rev=0xff
> Probing for SMSC Super I/O (idregs=0x0d/0x0e) at 0x3f0...
>   Failed. Returned data: id=0xff, rev=0xff
> Probing for SMSC Super I/O (idregs=0x20/0x21) at 0x370...
>   Failed. Returned data: id=0xff, rev=0xff
> Probing for SMSC Super I/O (idregs=0x0d/0x0e) at 0x370...
>   Failed. Returned data: id=0xff, rev=0xff
> Probing for Winbond Super I/O (init=0x88) at 0x2e...
>   Failed. Returned data: id/oldid=0xff/0x0f, rev=0xff
> Probing for Winbond Super I/O (init=0x89) at 0x2e...
>   Failed. Returned data: id/oldid=0xff/0x0f, rev=0xff
> Probing for Winbond Super I/O (init=0x86,0x86) at 0x2e...
>   Failed. Returned data: id/oldid=0xff/0x0f, rev=0xff
> Probing for Winbond Super I/O (init=0x87,0x87) at 0x2e...
>   Failed. Returned data: id/oldid=0xff/0x0f, rev=0xff
> Probing for Winbond Super I/O (init=0x88) at 0x4e...
>   Failed. Returned data: id/oldid=0xff/0x0f, rev=0xff
> Probing for Winbond Super I/O (init=0x89) at 0x4e...
>   Failed. Returned data: id/oldid=0xff/0x0f, rev=0xff
> Probing for Winbond Super I/O (init=0x86,0x86) at 0x4e...
>   Failed. Returned data: id/oldid=0xff/0x0f, rev=0xff
> Probing for Winbond Super I/O (init=0x87,0x87) at 0x4e...
>   Failed. Returned data: id/oldid=0xff/0x0f, rev=0xff
> Probing for Winbond Super I/O (init=0x88) at 0x3f0...
>   Failed. Returned data: id/oldid=0xff/0x0f, rev=0xff
> Probing for Winbond Super I/O (init=0x89) at 0x3f0...
>   Failed. Returned data: id/oldid=0xff/0x0f, rev=0xff
> Probing for Winbond Super I/O (init=0x86,0x86) at 0x3f0...
>   Failed. Returned data: id/oldid=0xff/0x0f, rev=0xff
> Probing for Winbond Super I/O (init=0x87,0x87) at 0x3f0...
>   Failed. Returned data: id/oldid=0xff/0x0f, rev=0xff
> Probing for Winbond Super I/O (init=0x88) at 0x370...
>   Failed. Returned data: id/oldid=0xff/0x0f, rev=0xff
> Probing for Winbond Super I/O (init=0x89) at 0x370...
>   Failed. Returned data: id/oldid=0xff/0x0f, rev=0xff
> Probing for Winbond Super I/O (init=0x86,0x86) at 0x370...
>   Failed. Returned data: id/oldid=0xff/0x0f, rev=0xff
> Probing for Winbond Super I/O (init=0x87,0x87) at 0x370...
>   Failed. Returned data: id/oldid=0xff/0x0f, rev=0xff
> Probing for Winbond Super I/O (init=0x88) at 0x250...
>   Failed. Returned data: id/oldid=0xff/0x0f, rev=0xff
> Probing for Winbond Super I/O (init=0x89) at 0x250...
>   Failed. Returned data: id/oldid=0xff/0x0f, rev=0xff
> Probing for Winbond Super I/O (init=0x86,0x86) at 0x250...
>   Failed. Returned data: id/oldid=0xff/0x0f, rev=0xff
> Probing for Winbond Super I/O (init=0x87,0x87) at 0x250...
>   Failed. Returned data: id/oldid=0xff/0x0f, rev=0xff
> No Super I/O found
> Sis530:~/superiotool#
>
>
> I saw some comments here:
> /**
>  * IT871[01]F and IT8708F use 0x87, 0x87
>  * IT8761F uses 0x87, 0x61, 0x55, 0x55/0xaa
>  * IT86xxF series uses different ports
>  * IT8661F uses 0x86, 0x61, 0x55/0xaa, 0x55/0xaa and 32 more writes
>  * IT8673F uses 0x86, 0x80, 0x55/0xaa, 0x55/0xaa and 32 more writes
>  */
> static void enter_conf_mode_ite(uint16_t port)
> {
> 	outb(0x87, port);
> 	outb(0x01, port);
> 	outb(0x55, port);
> 	if (port == 0x2e)
> 		outb(0x55, port);
> 	else
> 		outb(0xaa, port);
> }
>
> Not support IT8770F(I guessed)?
> also I haven't found any DS about IT8770F on internet, seems I am blind now..
>   
Look for IT8661F. Someone wrote the IT8770F and the IT8761F are identical. But it is not easy to add support for it.

Regards,
Carl-Daniel

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




From klaus123 at ibnoetzold.de  Mon Mar  3 15:20:56 2008
From: klaus123 at ibnoetzold.de (Klaus Stammermann)
Date: Mon, 3 Mar 2008 15:20:56 +0100
Subject: [coreboot] Problems with VIA EPIA-ME6000
Message-ID: <200803031520.56570.klaus123@ibnoetzold.de>

Hi there

I have some trouble to use coreboot on my VIA EPIA-ME6000 so I hope someone 
could give me some hints. 

With epia-m and filo I can build a bios without vga. This runs till jumping to 
kernel. This breaks up with an error:
Loading kernel... ok
"Jumping to entry point...
0

coreboot-2.0.0.0-Fallback Mo 18. Feb 16:59:57 CET 2008 starting..."

I tried with a PCI-VGA-card, "option CONFIG_CONSOLE_VGA = 1" and "option 
CONFIG_PCI_ROM_RUN=1".  This breaks up with this error:

"INSTALL REAL-MODE IDT
DO THE VGA BIOS
found VGA: vid=102b, did=519
rom base, size: fffc0000
write_protect_vgabios
bus/devfn = 0xa0
Unexpected Exception: 13 @ 10:00013808 - Halting
Code: 0 eflags: 00010002
eax: 00000011 ebx: 000247d4 ecx: 00023f8c edx: 00024a70
edi: 0001a4b0 esi: 00024a70 ebp: 00023f54 esp: 00023f54"

And using VGA-support with onboard device I get this message:
"DO THE VGA BIOS
found VGA: vid=1106, did=3122
rom base, size: fffc0000
BAD SIGNATURE 0x7f 0x45
Unexpected Exception: 13 @ 10:000130fe - Halting
Code: 0 eflags: 00010006
eax: 00000000 ebx: 000247d4 ecx: 80010030 edx: 00000cfc
edi: 0001a4b0 esi: 000247d4 ebp: 00023f8c esp: 00023f6c"

What do I have to do to boot with a VGA-card? Are there any options which have 
to be set?

Else, using onboard vga device I got the vga-bios by PERL-script 
(www.coreboot.org/VGA_support). Is it right this vga bios has to be insert in 
front of coreboot image? Should it be 64k big or just as big as it is in 
original? And on which adresses the parts of vga-bios, normal and fallback 
(with there payload) have to be set?

Does anyone use this board with coreboot too? Could some show a Config-file 
for this so I may see my mistakes?



From bgiraut at gmail.com  Mon Mar  3 16:15:59 2008
From: bgiraut at gmail.com (giraut benoit)
Date: Mon, 3 Mar 2008 16:15:59 +0100
Subject: [coreboot] LinuxBios for E-pc C10
Message-ID: <272757430803030715v957eae6r26a3107d0c222cca@mail.gmail.com>

Hello

Is there any chance to get my E-PC C10 board booting a linux bios ? The
Northbridge Intel 82810 and the  Southbridge Intel* * 82801 are supported
now. How can I process to test this board ?

I had read few months ago that someone try to port the linuxbios to this
board but i can't remember who ?

Thx benoit
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20080303/387a25ef/attachment.html>

From paulepanter at users.sourceforge.net  Mon Mar  3 16:19:51 2008
From: paulepanter at users.sourceforge.net (Paul Menzel)
Date: Mon, 03 Mar 2008 16:19:51 +0100
Subject: [coreboot] coreboot system analyzer
In-Reply-To: <47C6C360.1050302@gmx.net>
References: <47C6C360.1050302@gmx.net>
Message-ID: <1204557591.3704.14.camel@mattotaupa.home.familie-menzel.de>

Hi,


Am Donnerstag, den 28.02.2008, 15:21 +0100 schrieb Carl-Daniel
Hailfinger:
> This is a ready-made script which gathers all information about a system 
> we could want to evaluate whether porting is possible and/or easy.
> 
> The idea behind it is to get loads of people to run the script and help 
> us analyze coverage of flashrom and superiotool, together with board 
> distribution among willing testers.
> In the future, this could include the ICH GPIO dumper, the K8 resource 
> dumper, the MCP55 configuration dumper and a few other utilities.
> 
> Signed-off-by: Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006 at gmx.net>

Great idea.

> acpidump >acpidump.txt

The problem is, that it is not certain, that acpidump is installed on
the system (It is not on mine). So maybe we should test for the
existence. I do not know of a better way to check, whether a program is
in the path.

if [ -f /usr/bin/acpidump ]
  then
    acpidump > acpidump.txt
  else
    echo "Please install acpidump of the pmtools package."
    echo "Debian-based: sudo aptitude install acpidump ."
fi

or
  else
    wget http://ftp.kernel.org/pub/linux/kernel/people/lenb/acpi/utils/pmtools-20071116.tar.bz2
    tar xjvf pmtools-20071116.tar.bz2
    cd pmtools-20071116/acpidump/
    make
    ./acpidump > acpidump.txt
fi


An other thing is, whether the script should use sudo and compile the
programs with the right of the normal user.


Regards,

Paul




From rminnich at gmail.com  Mon Mar  3 16:47:16 2008
From: rminnich at gmail.com (ron minnich)
Date: Mon, 3 Mar 2008 07:47:16 -0800
Subject: [coreboot] LinuxBios for E-pc C10
In-Reply-To: <272757430803030715v957eae6r26a3107d0c222cca@mail.gmail.com>
References: <272757430803030715v957eae6r26a3107d0c222cca@mail.gmail.com>
Message-ID: <13426df10803030747g6075245du30f33a4203a0e58c@mail.gmail.com>

let's start with an lspci , lspci -v -v -v , lspci -n

ron



From svn at coreboot.org  Mon Mar  3 17:14:16 2008
From: svn at coreboot.org (svn at coreboot.org)
Date: Mon,  3 Mar 2008 17:14:16 +0100
Subject: [coreboot] r630 - coreboot-v3/util
Message-ID: <mailman.1246.1355071271.16123.coreboot@coreboot.org>

Author: uwe
Date: 2008-03-03 17:14:15 +0100 (Mon, 03 Mar 2008)
New Revision: 630

Modified:
   coreboot-v3/util/
Log:
Missing linuxbios.org -> coreboot.org rename in v3 svn:externals (trivial).

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




Property changes on: coreboot-v3/util
___________________________________________________________________
Modified: svn:externals
   - flashrom svn://linuxbios.org/repos/trunk/util/flashrom
nvramtool svn://linuxbios.org/repos/trunk/util/nvramtool
superiotool svn://linuxbios.org/repos/trunk/util/superiotool

   + flashrom svn://coreboot.org/repos/trunk/util/flashrom
nvramtool svn://coreboot.org/repos/trunk/util/nvramtool
superiotool svn://coreboot.org/repos/trunk/util/superiotool





From c-d.hailfinger.devel.2006 at gmx.net  Mon Mar  3 17:50:22 2008
From: c-d.hailfinger.devel.2006 at gmx.net (Carl-Daniel Hailfinger)
Date: Mon, 03 Mar 2008 17:50:22 +0100
Subject: [coreboot] Two questions about 690/600
In-Reply-To: <DD1CC71B621B004FA76856E5129D6B1701367507@sbjgexmb1.amd.com>
References: <DD1CC71B621B004FA76856E5129D6B1701367507@sbjgexmb1.amd.com>
Message-ID: <47CC2C4E.5060004@gmx.net>

Hi,

On 03.03.2008 11:04, Feng, Libo wrote:
> We are adapting LB for AMD Herring board based on Turion 64x2 and 690/600.

Great!

> Now we have two questions, could you give us some guide?
>
> 1. How to enable the VGA controller on 690? LB has detected the controller, from the previous experience, we seem to need a VBIOS to initialize the controller. But the controller is integrated into the 690, can we handle it just like an onboard controller and put VBIOS at 0xfff80000 and run VBIOS in the function of dev_initialize?
>   

VGA initialization has changed in latest svn. Which svn revision are you 
using?
You may want to skip VGA initialization for now. It is easier to get the 
rest working first.

> 2. 600 is attached to 690 via A-Link,

A-Link or A-Link Xpress? If it is the latter, it is a PCI-Express link.

>  from my understanding, 600 should be on another PCI bus, but from the LB trace, it seems 600 is still on PCI bus 0. Why? The 690 Datasheet says NB/SB Link P2P bridge is hidden by default, is this the reason?
>   

If you post a boot log and/or a patch against latest svn, we can 
probably help.

Regards,
Carl-Daniel

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




From c-d.hailfinger.devel.2006 at gmx.net  Mon Mar  3 18:23:21 2008
From: c-d.hailfinger.devel.2006 at gmx.net (Carl-Daniel Hailfinger)
Date: Mon, 03 Mar 2008 18:23:21 +0100
Subject: [coreboot] coreboot system analyzer
In-Reply-To: <1204557591.3704.14.camel@mattotaupa.home.familie-menzel.de>
References: <47C6C360.1050302@gmx.net>
	<1204557591.3704.14.camel@mattotaupa.home.familie-menzel.de>
Message-ID: <47CC3409.4000001@gmx.net>

On 03.03.2008 16:19, Paul Menzel wrote:
> Hi,
>
> Am Donnerstag, den 28.02.2008, 15:21 +0100 schrieb Carl-Daniel
> Hailfinger:
>   
>> This is a ready-made script which gathers all information about a system 
>> we could want to evaluate whether porting is possible and/or easy.
>>
>> The idea behind it is to get loads of people to run the script and help 
>> us analyze coverage of flashrom and superiotool, together with board 
>> distribution among willing testers.
>> In the future, this could include the ICH GPIO dumper, the K8 resource 
>> dumper, the MCP55 configuration dumper and a few other utilities.
>>
>> Signed-off-by: Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006 at gmx.net>
>>     
>
> Great idea.
>   

Thanks.


>> acpidump >acpidump.txt
>>     
>
> The problem is, that it is not certain, that acpidump is installed on
> the system (It is not on mine). So maybe we should test for the
> existence. I do not know of a better way to check, whether a program is
> in the path.
> [...]
>   

I adapted your code somewhat, but it is not finished. Thanks for the code.

> An other thing is, whether the script should use sudo and compile the
> programs with the right of the normal user.
>   

Indeed. I'd even say we could split the script in two scripts, one 
privileged and one unprivileged.

New version attached.

Regards,
Carl-Daniel

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

-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: coreboot_analyze
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20080303/d797964c/attachment.ksh>

From phanig at gmail.com  Mon Mar  3 19:38:45 2008
From: phanig at gmail.com (Phani Babu Giddi)
Date: Mon, 3 Mar 2008 10:38:45 -0800
Subject: [coreboot] Video ROM and VSA for Geode LX
Message-ID: <b61da340803031038se7413c9n136947b29b2ad4b0@mail.gmail.com>

Hi,

I am having trouble getting AMD's DB800 board to boot Linux with FILO. I am
using buildrom to build the image.

Now for debugging purposses I want to get Video ROM in coreboot image. Has
anybody tried patching Video ROM to coreboot image for Geode LX, if so which
part of the BIOS image does this fit in. Is it after VSA or before that ? I
think I have to reduce ROM_SIZE by the size of VSA and Video ROM.


Is there any other way I can debug coreboot/filo ? Can all the post codes
and other stuff be seen on serial console ?

Regards,
Phani
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20080303/8d7b1cc4/attachment.html>

From phanig at gmail.com  Mon Mar  3 20:15:21 2008
From: phanig at gmail.com (Phani Babu Giddi)
Date: Mon, 3 Mar 2008 11:15:21 -0800
Subject: [coreboot] Video ROM and VSA for Geode LX
In-Reply-To: <b61da340803031038se7413c9n136947b29b2ad4b0@mail.gmail.com>
References: <b61da340803031038se7413c9n136947b29b2ad4b0@mail.gmail.com>
Message-ID: <b61da340803031115m71f35fd7gb103f5e19b7d3dce@mail.gmail.com>

I check Options.lb for db800 board and looks like serial console debugging
is turned on, but I still dont see any messages on my serial console.

# To Enable the Serial Console
default CONFIG_CONSOLE_SERIAL8250=1
default TTYS0_BAUD=115200
# Select the serial console base port
default TTYS0_BASE=0x3f8
## Request this level of debugging output
default  DEFAULT_CONSOLE_LOGLEVEL=8
## At a maximum only compile in this level of debugging
default  MAXIMUM_CONSOLE_LOGLEVEL=8

-Phani
On Mon, Mar 3, 2008 at 10:38 AM, Phani Babu Giddi <phanig at gmail.com> wrote:

> Hi,
>
> I am having trouble getting AMD's DB800 board to boot Linux with FILO. I
> am using buildrom to build the image.
>
> Now for debugging purposses I want to get Video ROM in coreboot image. Has
> anybody tried patching Video ROM to coreboot image for Geode LX, if so which
> part of the BIOS image does this fit in. Is it after VSA or before that ? I
> think I have to reduce ROM_SIZE by the size of VSA and Video ROM.
>
>
> Is there any other way I can debug coreboot/filo ? Can all the post codes
> and other stuff be seen on serial console ?
>
> Regards,
> Phani
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20080303/13b9003c/attachment.html>

From marc.jones at amd.com  Mon Mar  3 21:12:06 2008
From: marc.jones at amd.com (Marc Jones)
Date: Mon, 03 Mar 2008 13:12:06 -0700
Subject: [coreboot] Video ROM and VSA for Geode LX
In-Reply-To: <b61da340803031115m71f35fd7gb103f5e19b7d3dce@mail.gmail.com>
References: <b61da340803031038se7413c9n136947b29b2ad4b0@mail.gmail.com>
	<b61da340803031115m71f35fd7gb103f5e19b7d3dce@mail.gmail.com>
Message-ID: <47CC5B96.4080304@amd.com>

Phani,

It should just work. Have you tested a serial console with the normal 
BIOS in Linux?

Marc


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




From phanig at gmail.com  Mon Mar  3 21:17:32 2008
From: phanig at gmail.com (Phani Babu Giddi)
Date: Mon, 3 Mar 2008 12:17:32 -0800
Subject: [coreboot] Video ROM and VSA for Geode LX
In-Reply-To: <47CC5B96.4080304@amd.com>
References: <b61da340803031038se7413c9n136947b29b2ad4b0@mail.gmail.com>
	<b61da340803031115m71f35fd7gb103f5e19b7d3dce@mail.gmail.com>
	<47CC5B96.4080304@amd.com>
Message-ID: <b61da340803031217v2c3ea71dx9d53d0e7755e25f8@mail.gmail.com>

Marc,

Yes I have tested and I can see the messages. Do I need to check how the
serial port on DB800 board has been routed. Looks like the Config ROM
expects it to be on 3f8 and take out from the Winbond Super IO. If the board
has picked up the serial port either from the sourth bridge of else if its
using some other port then that could be the reason for this.

How about the Video ROM image does it go after VSA or before that ?

Regards,
Phani

On Mon, Mar 3, 2008 at 12:12 PM, Marc Jones <marc.jones at amd.com> wrote:

> Phani,
>
> It should just work. Have you tested a serial console with the normal
> BIOS in Linux?
>
> Marc
>
>
> --
> Marc Jones
> Senior Firmware Engineer
> (970) 226-9684 Office
> mailto:Marc.Jones at amd.com
> http://www.amd.com/embeddedprocessors
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20080303/31726d89/attachment.html>

From stepan at coresystems.de  Mon Mar  3 21:33:22 2008
From: stepan at coresystems.de (Stefan Reinauer)
Date: Mon, 3 Mar 2008 21:33:22 +0100
Subject: [coreboot] Problems with VIA EPIA-ME6000
In-Reply-To: <200803031520.56570.klaus123@ibnoetzold.de>
References: <200803031520.56570.klaus123@ibnoetzold.de>
Message-ID: <20080303203322.GA7335@coresystems.de>

* Klaus Stammermann <klaus123 at ibnoetzold.de> [080303 15:20]:
> Hi there
> 
> I have some trouble to use coreboot on my VIA EPIA-ME6000 so I hope someone 
> could give me some hints. 
> 
> With epia-m and filo I can build a bios without vga. This runs till jumping to 
> kernel. This breaks up with an error:
> Loading kernel... ok
> "Jumping to entry point...
> 0
 
Was the kernel built with serial console support? Was console=ttyS0,...
specified as a command line option to the kernel?

> And using VGA-support with onboard device I get this message:
> "DO THE VGA BIOS
> found VGA: vid=1106, did=3122
> rom base, size: fffc0000
> BAD SIGNATURE 0x7f 0x45
> Unexpected Exception: 13 @ 10:000130fe - Halting
> Code: 0 eflags: 00010006
> eax: 00000000 ebx: 000247d4 ecx: 80010030 edx: 00000cfc
> edi: 0001a4b0 esi: 000247d4 ebp: 00023f8c esp: 00023f6c"
> 
> What do I have to do to boot with a VGA-card? Are there any options which have 
> to be set?

I think you need a special version of the vga option rom. 
Have you used the one from the optionroms repo?
http://www.coreboot.org/viewvc/trunk/optionroms/?root=optionroms 

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 marc.jones at amd.com  Mon Mar  3 21:37:25 2008
From: marc.jones at amd.com (Marc Jones)
Date: Mon, 03 Mar 2008 13:37:25 -0700
Subject: [coreboot] Video ROM and VSA for Geode LX
In-Reply-To: <b61da340803031217v2c3ea71dx9d53d0e7755e25f8@mail.gmail.com>
References: <b61da340803031038se7413c9n136947b29b2ad4b0@mail.gmail.com>	<b61da340803031115m71f35fd7gb103f5e19b7d3dce@mail.gmail.com>	<47CC5B96.4080304@amd.com>
	<b61da340803031217v2c3ea71dx9d53d0e7755e25f8@mail.gmail.com>
Message-ID: <47CC6185.9060304@amd.com>

Phani,

The DB800 coreboot configures the Winbond SIO. There have been some 
reported problems with the SIO buffers getting messed up. I don't recall 
the exact symptom but try completely powering off the system by 
unplugging or power off the ATX power supply and press the power button 
to get rid of any on-board capacitance. If this is your problem there 
should be reword instructions from Logic or on the AMD embedded 
developer site.


The video ROM would need to go before the VSA in the ROM image. VSA is 
expected to be on the end. See do_vsmbios().


Marc


Phani Babu Giddi wrote:
> Marc,
>  
> Yes I have tested and I can see the messages. Do I need to check how the 
> serial port on DB800 board has been routed. Looks like the Config ROM 
> expects it to be on 3f8 and take out from the Winbond Super IO. If the 
> board has picked up the serial port either from the sourth bridge of 
> else if its using some other port then that could be the reason for this.
>  
> How about the Video ROM image does it go after VSA or before that ?
>  
> Regards,
> Phani
> 
> On Mon, Mar 3, 2008 at 12:12 PM, Marc Jones <marc.jones at amd.com 
> <mailto:marc.jones at amd.com>> wrote:
> 
>     Phani,
> 
>     It should just work. Have you tested a serial console with the normal
>     BIOS in Linux?
> 
>     Marc
> 
> 
>     --
>     Marc Jones
>     Senior Firmware Engineer
>     (970) 226-9684 Office
>     mailto:Marc.Jones at amd.com <mailto:Marc.Jones at amd.com>
>     http://www.amd.com/embeddedprocessors
> 
> 

-- 
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  Mon Mar  3 22:06:37 2008
From: marc.jones at amd.com (Marc Jones)
Date: Mon, 03 Mar 2008 14:06:37 -0700
Subject: [coreboot] patch: dbe62
In-Reply-To: <47C9D3F5.9010506@gmx.net>
References: <13426df10802281441v109c6edai8e448131a0539c93@mail.gmail.com>	<20080229010002.9912.qmail@stuge.se>	<13426df10802281853q27757ab3mac567ab8c574412@mail.gmail.com>	<20080229134132.2184.qmail@stuge.se>	<13426df10802290852h109ab986o89a83f689a14148b@mail.gmail.com>	<47C8B860.5030700@gmx.net>	<13426df10802291803y2b042304pfa78ce2e2900dfa1@mail.gmail.com>	<47C9734E.1010807@gmx.net>	<20080301152721.25943.qmail@stuge.se>	<13426df10803010908s6a866eb0jcdaf90135d6579b6@mail.gmail.com>	<13426df10803011334o20ec721lfde0b3d18aee9c20@mail.gmail.com>
	<47C9D3F5.9010506@gmx.net>
Message-ID: <47CC685D.60809@amd.com>

Carl-Daniel,

Just tried the new irq table code on Norwich. Everything seems to be 
working. Thanks for making these changes. This is much cleaner.

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  Mon Mar  3 22:50:24 2008
From: c-d.hailfinger.devel.2006 at gmx.net (Carl-Daniel Hailfinger)
Date: Mon, 03 Mar 2008 22:50:24 +0100
Subject: [coreboot] [LinuxBIOS] W39V040BPZ or vt8237. Flashing problems.
In-Reply-To: <46FE9285.6000900@comcast.net>
References: <46FD7099.6050801@comcast.net>		<13426df10709281428h125862daqcbf0bc2c5249281a@mail.gmail.com>		<46FD783F.4000502@comcast.net>		<13426df10709281528g385a615cs75a6b2b2ee8124ab@mail.gmail.com>		<46FD8AF8.9040702@comcast.net>	<13426df10709281754r3ed1d639qe5a597b9dbe67ac3@mail.gmail.com>
	<46FE9285.6000900@comcast.net>
Message-ID: <47CC72A0.5050707@gmx.net>

Hi Adam,

did you figure out the reason of the bad interaction between vt8237 and 
W39V040BPZ?

On 29.09.2007 19:59, Adam Talbot wrote:
> Some more information to follow.  If possible, I would like to try to
> fix this.  So, if any one has a few good places to look, and some good
> places in the code to add debug statements, that would be great.  I am
> not all that familiar with flashrom, yet. What other BIOS chips are on
> the CN700+VT8237 boards, I would like a different chip, just to prove it
> is not the chip(s).
> -Adam Talbot
>
> v21g flashrom # ./flashrom -r backup.bin
> Calibrating delay loop... ok
> No LinuxBIOS table found.
> Found chipset "VT8237": Enabling flash write... OK.
> W39V040B found at physical address: 0xfff80000
> Flash part is W39V040B (512 KB)
> Reading Flash...done
>   

Flash chip is found, reading out works fine.

> v21g flashrom # time ./flashrom -wV backup.bin
> Calibrating delay loop... 496M loops per second. ok
> No LinuxBIOS table found.
> Found chipset "VT8237": Enabling flash write... OK.
> [...]
> Probing for W39V040B, 512 KB
> probe_jedec: id1 0xda, id2 0x54
> W39V040B found at physical address: 0xfff80000
> Flash part is W39V040B (512 KB)
> Flash image seems to be a legacy BIOS. Disabling checks.
>   

Chip found again, is being erased before the writing starts.

> Programming Page: 0000 at address: 0x00000000
>   

It hangs here.

> ### Ctrl-C ###
> real    1134m28.975s
> user    1134m49.425s
> sys     0m0.277s
>
>
> v21g flashrom # ./flashrom               
> Calibrating delay loop... ok
> No LinuxBIOS table found.
> Found chipset "VT8237": Enabling flash write... OK.
> No EEPROM/flash device found.
>   

I'm seeing exactly the same symptoms with a W39V040BPZ on my MCP51 
Asrock K8NF4G-SATA2 board. Strange fact: If I hot-unplug the flash chip 
and hot-replug it, it is recognized again. Reading it shows the erase 
was successful, but once I try to program even one byte, communication 
with the flash chip fails completely and I have to unplug and replug to 
fix that.

Regards,
Carl-Daniel

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




From ward at gnu.org  Mon Mar  3 22:51:50 2008
From: ward at gnu.org (Ward Vandewege)
Date: Mon, 3 Mar 2008 16:51:50 -0500
Subject: [coreboot] m57sli FAN control
In-Reply-To: <1204230442.3710.5.camel@amd-x2.grundel>
References: <1202596404.2721.46.camel@amd-x2.grundel>
	<1203293543.2857.13.camel@amd-x2.grundel>
	<1203365892.2790.18.camel@amd-x2.grundel>
	<20080218202916.GA32656@localdomain>
	<1203720727.2659.21.camel@amd-x2.grundel>
	<1203891496.2735.6.camel@amd-x2.grundel>
	<20080225193753.GA8625@localdomain>
	<1204153993.2716.22.camel@amd-x2.grundel>
	<20080227233827.GA3982@localdomain>
	<1204230442.3710.5.camel@amd-x2.grundel>
Message-ID: <20080303215150.GA19063@localdomain>

All right, please find a revised patch attached that does not stop the CPU
fan.

Turns out that the original patch malfunctioned on both v1.1 and v2 of the
board if the it87 driver was not loaded. That driver fixed the settings,
which added to my confusion. It also explains why it seemed to work for me at
first, but then did not when rebooting (I was booting a different filesystem
that did not load the it87 module on startup).

Anyway, I'd be grateful for some testing of the attached. It does the right
thing on v1.1 and v2 of the board based on my testing. It does not set the
diode zero adjust temperature right yet for v2 of the board (it should be 0xfe
instead of 0xec). That could be done by adding a detection for the revision
of the IT8716F chip (v2 seems to have rev3, v1.1 has rev0), but I don't have
time to add that right now. It's not that important I think - but if someone
wants to contribute that change, please feel free. There are a few other
registers that should be slightly different between v1.1 and v2 but nothing
very crucial it seems.

Thanks,
Ward.

-- 
Ward Vandewege <ward at fsf.org>
Free Software Foundation - Senior System Administrator
-------------- next part --------------
A non-text attachment was scrubbed...
Name: fanctl.patch
Type: text/x-diff
Size: 3888 bytes
Desc: not available
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20080303/7d8bc3b8/attachment.bin>

From c-d.hailfinger.devel.2006 at gmx.net  Mon Mar  3 22:57:28 2008
From: c-d.hailfinger.devel.2006 at gmx.net (Carl-Daniel Hailfinger)
Date: Mon, 03 Mar 2008 22:57:28 +0100
Subject: [coreboot] patch: dbe62
In-Reply-To: <47CC685D.60809@amd.com>
References: <13426df10802281441v109c6edai8e448131a0539c93@mail.gmail.com>	<20080229010002.9912.qmail@stuge.se>	<13426df10802281853q27757ab3mac567ab8c574412@mail.gmail.com>	<20080229134132.2184.qmail@stuge.se>	<13426df10802290852h109ab986o89a83f689a14148b@mail.gmail.com>	<47C8B860.5030700@gmx.net>	<13426df10802291803y2b042304pfa78ce2e2900dfa1@mail.gmail.com>	<47C9734E.1010807@gmx.net>	<20080301152721.25943.qmail@stuge.se>	<13426df10803010908s6a866eb0jcdaf90135d6579b6@mail.gmail.com>	<13426df10803011334o20ec721lfde0b3d18aee9c20@mail.gmail.com>
	<47C9D3F5.9010506@gmx.net> <47CC685D.60809@amd.com>
Message-ID: <47CC7448.10306@gmx.net>

Marc,

thanks for testing! Does that mean the Norwich works without any 
problems and we can change the v3 status of Norwich to OK here: 
http://www.coreboot.org/Supported_Motherboards

Regards,
Carl-Daniel

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




From marc.jones at amd.com  Mon Mar  3 23:17:40 2008
From: marc.jones at amd.com (Marc Jones)
Date: Mon, 03 Mar 2008 15:17:40 -0700
Subject: [coreboot] patch: dbe62
In-Reply-To: <47CC7448.10306@gmx.net>
References: <13426df10802281441v109c6edai8e448131a0539c93@mail.gmail.com>	<20080229010002.9912.qmail@stuge.se>	<13426df10802281853q27757ab3mac567ab8c574412@mail.gmail.com>	<20080229134132.2184.qmail@stuge.se>	<13426df10802290852h109ab986o89a83f689a14148b@mail.gmail.com>	<47C8B860.5030700@gmx.net>	<13426df10802291803y2b042304pfa78ce2e2900dfa1@mail.gmail.com>	<47C9734E.1010807@gmx.net>	<20080301152721.25943.qmail@stuge.se>	<13426df10803010908s6a866eb0jcdaf90135d6579b6@mail.gmail.com>	<13426df10803011334o20ec721lfde0b3d18aee9c20@mail.gmail.com>	<47C9D3F5.9010506@gmx.net>
	<47CC685D.60809@amd.com> <47CC7448.10306@gmx.net>
Message-ID: <47CC7904.4040208@amd.com>

Carl-Daniel,

Yes, Norwich works fine. I don't know of any issues. Go ahead and change 
the status in the wiki.

Marc


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




From corey.osgood at gmail.com  Tue Mar  4 00:42:05 2008
From: corey.osgood at gmail.com (Corey Osgood)
Date: Mon, 03 Mar 2008 18:42:05 -0500
Subject: [coreboot] [LinuxBIOS] W39V040BPZ or vt8237. Flashing problems.
In-Reply-To: <47CC72A0.5050707@gmx.net>
References: <46FD7099.6050801@comcast.net>
	<13426df10709281428h125862daqcbf0bc2c5249281a@mail.gmail.com>
	<46FD783F.4000502@comcast.net>
	<13426df10709281528g385a615cs75a6b2b2ee8124ab@mail.gmail.com>
	<46FD8AF8.9040702@comcast.net>
	<13426df10709281754r3ed1d639qe5a597b9dbe67ac3@mail.gmail.com>
	<46FE9285.6000900@comcast.net>  <47CC72A0.5050707@gmx.net>
Message-ID: <1204587725.6247.4.camel@Mobulus>

On Mon, 2008-03-03 at 22:50 +0100, Carl-Daniel Hailfinger wrote:
> Hi Adam,
> 
> did you figure out the reason of the bad interaction between vt8237 and 
> W39V040BPZ?
> 
> On 29.09.2007 19:59, Adam Talbot wrote:
> > Some more information to follow.  If possible, I would like to try to
> > fix this.  So, if any one has a few good places to look, and some good
> > places in the code to add debug statements, that would be great.  I am
> > not all that familiar with flashrom, yet. What other BIOS chips are on
> > the CN700+VT8237 boards, I would like a different chip, just to prove it
> > is not the chip(s).
> > -Adam Talbot
> >
> > v21g flashrom # ./flashrom -r backup.bin
> > Calibrating delay loop... ok
> > No LinuxBIOS table found.
> > Found chipset "VT8237": Enabling flash write... OK.
> > W39V040B found at physical address: 0xfff80000
> > Flash part is W39V040B (512 KB)
> > Reading Flash...done
> >   
> 
> Flash chip is found, reading out works fine.
> 
> > v21g flashrom # time ./flashrom -wV backup.bin
> > Calibrating delay loop... 496M loops per second. ok
> > No LinuxBIOS table found.
> > Found chipset "VT8237": Enabling flash write... OK.
> > [...]
> > Probing for W39V040B, 512 KB
> > probe_jedec: id1 0xda, id2 0x54
> > W39V040B found at physical address: 0xfff80000
> > Flash part is W39V040B (512 KB)
> > Flash image seems to be a legacy BIOS. Disabling checks.
> >   
> 
> Chip found again, is being erased before the writing starts.
> 
> > Programming Page: 0000 at address: 0x00000000
> >   
> 
> It hangs here.
> 
> > ### Ctrl-C ###
> > real    1134m28.975s
> > user    1134m49.425s
> > sys     0m0.277s
> >
> >
> > v21g flashrom # ./flashrom               
> > Calibrating delay loop... ok
> > No LinuxBIOS table found.
> > Found chipset "VT8237": Enabling flash write... OK.
> > No EEPROM/flash device found.
> >   
> 
> I'm seeing exactly the same symptoms with a W39V040BPZ on my MCP51 
> Asrock K8NF4G-SATA2 board. Strange fact: If I hot-unplug the flash chip 
> and hot-replug it, it is recognized again. Reading it shows the erase 
> was successful, but once I try to program even one byte, communication 
> with the flash chip fails completely and I have to unplug and replug to 
> fix that.

I'm seeing exactly the same thing with the cn700+vt8237r on Jetway
J7F2W, same flash chip, except that where it hangs seems random. I had
assumed the flash chips were write protected in some way that I didn't
care to work around, since they're the factory BIOS. Removing the chip
then reinserting it allows flashrom to detect it again, and writing
actually works and verifys, extremely slowly, perhaps 1 out of 100
times. PMC PM49FL004 works perfectly fine on the same board.

-Corey




From peter at stuge.se  Tue Mar  4 01:03:11 2008
From: peter at stuge.se (Peter Stuge)
Date: Tue, 4 Mar 2008 01:03:11 +0100
Subject: [coreboot] coreboot system analyzer
In-Reply-To: <47CC3409.4000001@gmx.net>
References: <47C6C360.1050302@gmx.net>
	<1204557591.3704.14.camel@mattotaupa.home.familie-menzel.de>
	<47CC3409.4000001@gmx.net>
Message-ID: <20080304000312.21122.qmail@stuge.se>

On Mon, Mar 03, 2008 at 06:23:21PM +0100, Carl-Daniel Hailfinger wrote:
> test -z "$ACPIDUMP" && for a in /usr/bin /bin /usr/local/bin /usr/sbin /sbin /usr/local/sbin; do
> 	test -f $a/acpidump && IASL="$a/acpidump"
> done
> test -z "$ACPIDUMP" && { echo acpidump not found.; exit 1; }

ACPIDUMP vs IASL ?


> DMIDECODE=`which dmidecode 2>/dev/null`
> test -z "$DMIDECODE" && for a in /usr/bin /bin /usr/local/bin /usr/sbin /sbin /usr/local/sbin; do
> 	test -f $a/dmidecode && IASL="$a/dmidecode"
> done
> test -z "$DMIDECODE" && { echo dmidecode not found.; exit 1; }

DMIDECODE vs IASL ?


> dumps at coreboot.org

Does this exist? Who reads it?


//Peter



From peter at stuge.se  Tue Mar  4 01:15:06 2008
From: peter at stuge.se (Peter Stuge)
Date: Tue, 4 Mar 2008 01:15:06 +0100
Subject: [coreboot] [LinuxBIOS] W39V040BPZ or vt8237. Flashing problems.
In-Reply-To: <1204587725.6247.4.camel@Mobulus>
References: <46FD7099.6050801@comcast.net>
	<13426df10709281428h125862daqcbf0bc2c5249281a@mail.gmail.com>
	<46FD783F.4000502@comcast.net>
	<13426df10709281528g385a615cs75a6b2b2ee8124ab@mail.gmail.com>
	<46FD8AF8.9040702@comcast.net>
	<13426df10709281754r3ed1d639qe5a597b9dbe67ac3@mail.gmail.com>
	<46FE9285.6000900@comcast.net> <47CC72A0.5050707@gmx.net>
	<1204587725.6247.4.camel@Mobulus>
Message-ID: <20080304001506.23800.qmail@stuge.se>

On Mon, Mar 03, 2008 at 06:42:05PM -0500, Corey Osgood wrote:
> > If I hot-unplug the flash chip and hot-replug it, it is recognized
> > again. Reading it shows the erase was successful, but once I try
> > to program even one byte, communication with the flash chip fails
> > completely and I have to unplug and replug to fix that.
> 
> I'm seeing exactly the same thing with the cn700+vt8237r on Jetway
> J7F2W, same flash chip, except that where it hangs seems random.

I take this to mean that 8237 and the W39V040BPZ aren't really
compatible.

I would investigate if the timing for the two is compatible on paper.
Also, maybe the 8237 has some speed setting like the ITE.


//Peter



From c-d.hailfinger.devel.2006 at gmx.net  Tue Mar  4 03:00:57 2008
From: c-d.hailfinger.devel.2006 at gmx.net (Carl-Daniel Hailfinger)
Date: Tue, 04 Mar 2008 03:00:57 +0100
Subject: [coreboot] patch: dbe62
In-Reply-To: <47CC7904.4040208@amd.com>
References: <13426df10802281441v109c6edai8e448131a0539c93@mail.gmail.com>	<20080229010002.9912.qmail@stuge.se>	<13426df10802281853q27757ab3mac567ab8c574412@mail.gmail.com>	<20080229134132.2184.qmail@stuge.se>	<13426df10802290852h109ab986o89a83f689a14148b@mail.gmail.com>	<47C8B860.5030700@gmx.net>	<13426df10802291803y2b042304pfa78ce2e2900dfa1@mail.gmail.com>	<47C9734E.1010807@gmx.net>	<20080301152721.25943.qmail@stuge.se>	<13426df10803010908s6a866eb0jcdaf90135d6579b6@mail.gmail.com>	<13426df10803011334o20ec721lfde0b3d18aee9c20@mail.gmail.com>	<47C9D3F5.9010506@gmx.net>	<47CC685D.60809@amd.com>
	<47CC7448.10306@gmx.net> <47CC7904.4040208@amd.com>
Message-ID: <47CCAD59.8080801@gmx.net>

Marc,

thanks for verifying. Norwich v3 status in the wiki has been changed to 
"OK".

Are you working on a db800 port for v3? If not, I'd like to give it a 
first try.

Regards,
Carl-Daniel

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




From c-d.hailfinger.devel.2006 at gmx.net  Tue Mar  4 04:16:01 2008
From: c-d.hailfinger.devel.2006 at gmx.net (Carl-Daniel Hailfinger)
Date: Tue, 04 Mar 2008 04:16:01 +0100
Subject: [coreboot] [PATCH] v3: AMD DB800 support
Message-ID: <47CCBEF1.4040208@gmx.net>

This is another milestone in my quest to obsolete v2.

[Patch looks strange due to a svn bug. Please let me commit, my tree 
will give us proper svn blame history and actually commit correctly.]

Compile tested.
Untested on hardware, but it should work.
Marc, can you please test on real hardware?

AMD DB800 support, ported from v2.

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

--- /dev/null	2007-09-21 23:50:58.000000000 +0200
+++ LinuxBIOSv3-db800/mainboard/amd/db800/Kconfig	2008-03-04 03:07:01.000000000 +0100
@@ -0,0 +1,44 @@
+##
+## This file is part of the coreboot project.
+##
+## Copyright (C) 2007 coresystems GmbH
+## (Written by Stefan Reinauer <stepan at coresystems.de> for coresystems GmbH)
+##
+## 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
+##
+
+config MAINBOARD_NAME
+	string
+	default amd/db800
+	depends BOARD_AMD_DB800
+	help
+	  This is the default mainboard name.
+
+config MAINBOARD_PCI_SUBSYSTEM_VENDOR_ID
+	hex
+	# TODO: Fix PCI ID.
+	default 0x1022
+	depends BOARD_AMD_DB800
+	help
+	  Mainboard specific PCI subsystem vendor ID.
+
+config MAINBOARD_PCI_SUBSYSTEM_DEVICE_ID
+	hex
+	# TODO: Fix PCI ID.
+	default 0x2323
+	depends BOARD_AMD_DB800
+	help
+	  Mainboard specific PCI subsystem device ID.
+
--- /dev/null	2007-09-21 23:50:58.000000000 +0200
+++ LinuxBIOSv3-db800/mainboard/amd/db800/initram.c	2008-03-04 04:02:32.000000000 +0100
@@ -0,0 +1,106 @@
+/*
+ * This file is part of the coreboot project.
+ *
+ * Copyright (C) 2007 Advanced Micro Devices, Inc.
+ *
+ * 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
+ */
+
+#define _MAINOBJECT
+
+#include <types.h>
+#include <lib.h>
+#include <console.h>
+#include <device/device.h>
+#include <device/pci.h>
+#include <string.h>
+#include <msr.h>
+#include <io.h>
+#include <amd_geodelx.h>
+#include <northbridge/amd/geodelx/raminit.h>
+
+/* #include <device/smbus.h>
+ * TODO: figure out how smbus functions should be done. See smbus_ops.c
+ */
+extern int smbus_read_byte(u16 device, u8 address);
+
+#define MANUALCONF 0		/* Do automatic strapped PLL config */
+#define PLLMSRHI 0x00001490	/* manual settings for the PLL */
+#define PLLMSRLO 0x02000030
+#define DIMM0 ((u8) 0xA0)
+#define DIMM1 ((u8) 0xA2)
+
+u8 spd_read_byte(u16 device, u8 address)
+{
+	u8 spdbyte;
+
+	printk(BIOS_DEBUG, "spd_read_byte dev %04x\n", device);
+
+	spdbyte = smbus_read_byte(device, address);
+
+	printk(BIOS_DEBUG, " addr %02x returns %02x\n", address, spdbyte);
+
+	return spdbyte;
+}
+
+/**
+  * Placeholder in case we ever need it. Since this file is a
+  * template for other motherboards, we want this here and we want the
+  * call in the right place.
+  */
+
+static void mb_gpio_init(void)
+{
+	/* Early mainboard specific GPIO setup */
+}
+
+/**
+  * main for initram for the AMD DB800 development platform.
+  * It might seem that you could somehow do these functions in, e.g., the cpu
+  * code, but the order of operations and what those operations are is VERY
+  * strongly mainboard dependent. It's best to leave it in the mainboard code.
+  */
+int main(void)
+{
+	printk(BIOS_DEBUG, "Hi there from initram (stage1) main!\n");
+	post_code(POST_START_OF_MAIN);
+
+	system_preinit();
+	printk(BIOS_DEBUG, "done preinit\n");
+
+	mb_gpio_init();
+	printk(BIOS_DEBUG, "done gpio init\n");
+
+	pll_reset(MANUALCONF, PLLMSRHI, PLLMSRLO);
+	printk(BIOS_DEBUG, "done pll reset\n");
+
+	cpu_reg_init(0, DIMM0, DIMM1);
+	printk(BIOS_DEBUG, "done cpu reg init\n");
+
+	sdram_set_registers();
+	printk(BIOS_DEBUG, "done sdram set registers\n");
+
+	sdram_set_spd_registers(DIMM0, DIMM1);
+	printk(BIOS_DEBUG, "done sdram set spd registers\n");
+
+	sdram_enable(DIMM0, DIMM1);
+	printk(BIOS_DEBUG, "done sdram enable\n");
+
+	/* Check low memory */
+	/*ram_check(0x00000000, 640*1024); */
+
+	printk(BIOS_DEBUG, "stage1 returns\n");
+	return 0;
+}
--- /dev/null	2007-09-21 23:50:58.000000000 +0200
+++ LinuxBIOSv3-db800/mainboard/amd/db800/stage1.c	2008-03-04 03:05:09.000000000 +0100
@@ -0,0 +1,57 @@
+/*
+ * This file is part of the coreboot project.
+ *
+ * Copyright (C) 2007 Advanced Micro Devices, Inc.
+ *
+ * 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 <types.h>
+#include <lib.h>
+#include <console.h>
+#include <device/device.h>
+#include <device/pci.h>
+#include <string.h>
+#include <msr.h>
+#include <io.h>
+#include <amd_geodelx.h>
+#include <southbridge/amd/cs5536/cs5536.h>
+#include <superio/winbond/w83627hf/w83627hf.h>
+
+#define SERIAL_DEV W83627HF_SP1
+#define SERIAL_IOBASE 0x3f8
+
+void hardware_stage1(void)
+{
+	void w83627hf_enable_serial(u8 dev, u8 serial, u16 iobase);
+	post_code(POST_START_OF_MAIN);
+	geodelx_msr_init();
+
+	cs5536_stage1();
+
+	/* NOTE: must do this AFTER the early_setup!
+	 * it is counting on some early MSR setup
+	 * for cs5536.
+	 */
+	cs5536_disable_internal_uart();
+	w83627hf_enable_serial(0x2e, SERIAL_DEV, SERIAL_IOBASE);
+
+}
+
+void mainboard_pre_payload(void)
+{
+	geode_pre_payload();
+	banner(BIOS_DEBUG, "mainboard_pre_payload: done");
+}
--- /dev/null	2007-09-21 23:50:58.000000000 +0200
+++ LinuxBIOSv3-db800/mainboard/amd/db800/dts	2008-03-04 04:01:49.000000000 +0100
@@ -0,0 +1,55 @@
+/*
+ * This file is part of the coreboot project.
+ *
+ * Copyright (C) 2007 Ronald G. Minnich <rminnich at gmail.com>
+ *
+ * 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
+ */
+
+/{
+	mainboard-vendor = "AMD";
+	mainboard-name = "DB800";
+	cpus { };
+	apic at 0 {
+		/config/("northbridge/amd/geodelx/apic");
+	};
+	domain at 0 {
+		/config/("northbridge/amd/geodelx/domain");
+		/* Video RAM has to be in 2MB chunks. */
+		geode_video_mb = "8";
+		pci at 1,0 {
+			/config/("northbridge/amd/geodelx/pci");
+		};
+		pci at 15,0 {
+			/config/("southbridge/amd/cs5536/dts");
+			enable_ide = "1";
+			/* Interrupt enables for LPC bus.
+			 *  Each bit is an IRQ 0-15. */
+			lpc_serirq_enable = "0x000010da";
+			/* LPC IRQ polarity. Each bit is an IRQ 0-15. */
+			lpc_serirq_polarity = "0x0000EF25";
+			/* 0:continuous 1:quiet */
+			lpc_serirq_mode = "1";
+			/* GPIO(0-0x20) for INT D:C:B:A, 0xFF=none. 
+			 * See virtual PIC spec. */
+			enable_gpio_int_route = "0x0D0C0700";
+			enable_USBP4_device = "1";
+		};
+		ioport at 46 {
+			/config/("superio/winbond/w83627hf/dts");
+			com1enable = "1";
+		};
+	};
+};
--- /dev/null	2007-09-21 23:50:58.000000000 +0200
+++ LinuxBIOSv3-db800/mainboard/amd/db800/irq_tables.h	2008-03-04 04:02:08.000000000 +0100
@@ -0,0 +1,81 @@
+/*
+* This file is part of the coreboot project.
+*
+* Copyright (C) 2007 Advanced Micro Devices, Inc.
+*
+* This program is free software; you can redistribute it and/or modify
+* it under the terms of the GNU General Public License version 2 as
+* published by the Free Software Foundation.
+*
+* 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 <pirq_routing.h>
+
+/* Number of slots and devices in the PIR table */
+#define SLOT_COUNT 4
+
+/* Platform IRQs */
+#define PIRQA 10
+#define PIRQB 11
+#define PIRQC 10
+#define PIRQD 11
+
+/* Map */
+#define M_PIRQA (1 << PIRQA)	/* Bitmap of supported IRQs */
+#define M_PIRQB (1 << PIRQB)	/* Bitmap of supported IRQs */
+#define M_PIRQC (1 << PIRQC)	/* Bitmap of supported IRQs */
+#define M_PIRQD (1 << PIRQD)	/* Bitmap of supported IRQs */
+
+/* Link */
+#define L_PIRQA 1		/* Means Slot INTx# Connects To Chipset INTA# */
+#define L_PIRQB 2		/* Means Slot INTx# Connects To Chipset INTB# */
+#define L_PIRQC 3		/* Means Slot INTx# Connects To Chipset INTC# */
+#define L_PIRQD 4		/* Means Slot INTx# Connects To Chipset INTD# */
+
+/*
+ * AMD DB800 interrupt wiring.
+ *
+ * Devices are:
+ *
+ * FIXME
+ *
+ */
+
+const struct irq_routing_table intel_irq_routing_table = {
+	PIRQ_SIGNATURE,
+	PIRQ_VERSION,
+	32 + 16 * SLOT_COUNT,	/* Max. number of devices on the bus */
+	0x00,			/* Where the interrupt router lies (bus) */
+	(0x0F << 3) | 0x0,      /* Where the interrupt router lies (dev) */
+	0x00,			/* IRQs devoted exclusively to PCI usage */
+	0x100B,			/* Vendor */
+	0x002B,			/* Device */
+	0,			/* Crap (miniport) */
+	{0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0},	/* u8 rfu[11] */
+	0x00,			/* Checksum */
+	{
+		/* If you change the number of entries, change IRQ_SLOT_COUNT above! */
+
+		/* bus, dev|fn,           {link, bitmap},      {link, bitmap},     {link, bitmap},     {link, bitmap},     slot, rfu */
+
+		/* CPU */
+		{0x00, (0x01 << 3) | 0x0, {{L_PIRQA, M_PIRQA}, {0x00, 0x00}, {0x00, 0x00}, {0x00, 0x00}}, 0x0, 0x0},
+
+		/* Chipset slots -- f.3 wires to B, and f.4 and f.5 wires to D. */
+		{0x00, (0x0F << 3) | 0x0, {{L_PIRQA, M_PIRQA}, {L_PIRQB, M_PIRQB}, {L_PIRQC, M_PIRQC}, {L_PIRQD, M_PIRQD}}, 0x0, 0x0},
+
+		/* On-board ethernet */
+		{0x00, (0x0D << 3) | 0x0, {{L_PIRQB, M_PIRQB}, {0x00, 0x00}, {0x00, 0x00}, {0x00, 0x00}}, 0x0, 0x0},
+
+		/* PCI (slot 1) */
+		{0x00, (0x0E << 3) | 0x0, {{L_PIRQC, M_PIRQC}, {L_PIRQD, M_PIRQD}, {L_PIRQA, M_PIRQA}, {L_PIRQB, M_PIRQB}}, 0x1, 0x0},
+	}
+};
--- /dev/null	2007-09-21 23:50:58.000000000 +0200
+++ LinuxBIOSv3-db800/mainboard/amd/db800/cmos.layout	2008-03-04 03:08:52.000000000 +0100
@@ -0,0 +1,74 @@
+entries
+
+#start-bit length  config config-ID    name
+#0            8       r       0        seconds
+#8            8       r       0        alarm_seconds
+#16           8       r       0        minutes
+#24           8       r       0        alarm_minutes
+#32           8       r       0        hours
+#40           8       r       0        alarm_hours
+#48           8       r       0        day_of_week
+#56           8       r       0        day_of_month
+#64           8       r       0        month
+#72           8       r       0        year
+#80           4       r       0        rate_select
+#84           3       r       0        REF_Clock
+#87           1       r       0        UIP
+#88           1       r       0        auto_switch_DST
+#89           1       r       0        24_hour_mode
+#90           1       r       0        binary_values_enable
+#91           1       r       0        square-wave_out_enable
+#92           1       r       0        update_finished_enable
+#93           1       r       0        alarm_interrupt_enable
+#94           1       r       0        periodic_interrupt_enable
+#95           1       r       0        disable_clock_updates
+#96         288       r       0        temporary_filler
+0          384       r       0        reserved_memory
+384          1       e       4        boot_option
+385          1       e       4        last_boot
+386          1       e       1        ECC_memory
+388          4       r       0        reboot_bits
+392          3       e       5        baud_rate
+400          1       e       1        power_on_after_fail
+412          4       e       6        debug_level
+416          4       e       7        boot_first
+420          4       e       7        boot_second
+424          4       e       7        boot_third
+428          4       h       0        boot_index
+432	     8       h       0        boot_countdown
+1008         16      h       0        check_sum
+
+enumerations
+
+#ID value   text
+1     0     Disable
+1     1     Enable
+2     0     Enable
+2     1     Disable
+4     0     Fallback
+4     1     Normal
+5     0     115200
+5     1     57600
+5     2     38400
+5     3     19200
+5     4     9600
+5     5     4800
+5     6     2400
+5     7     1200
+6     6     Notice
+6     7     Info
+6     8     Debug
+6     9     Spew
+7     0     Network
+7     1     HDD
+7     2     Floppy
+7     8     Fallback_Network
+7     9     Fallback_HDD
+7     10    Fallback_Floppy
+#7     3     ROM
+
+checksums
+
+checksum 392 1007 1008
+
+
--- /dev/null	2007-09-21 23:50:58.000000000 +0200
+++ LinuxBIOSv3-db800/mainboard/amd/db800/Makefile	2008-03-04 03:18:53.000000000 +0100
@@ -0,0 +1,34 @@
+##
+## This file is part of the coreboot project.
+##
+## Copyright (C) 2006-2007 coresystems GmbH
+## (Written by Stefan Reinauer <stepan at coresystems.de> for coresystems GmbH)
+##
+## 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
+##
+
+STAGE0_MAINBOARD_OBJ := $(obj)/mainboard/$(MAINBOARDDIR)/stage1.o
+
+INITRAM_OBJ =   $(src)/mainboard/$(MAINBOARDDIR)/initram.c \
+		$(src)/northbridge/amd/geodelx/raminit.c \
+		$(src)/southbridge/amd/cs5536/smbus_initram.c \
+		$(src)/arch/x86/geodelx/geodelx.c
+
+STAGE2_MAINBOARD_OBJ = 
+
+$(obj)/coreboot.vpd:
+	$(Q)printf "  BUILD   DUMMY VPD\n"
+	$(Q)dd if=/dev/zero of=$(obj)/coreboot.vpd bs=256 count=1 $(SILENT)
+
Index: LinuxBIOSv3-db800/mainboard/amd/Kconfig
===================================================================
--- LinuxBIOSv3-db800/mainboard/amd/Kconfig	(Revision 630)
+++ LinuxBIOSv3-db800/mainboard/amd/Kconfig	(Arbeitskopie)
@@ -23,6 +23,18 @@
 	prompt "Mainboard model"
 	depends on VENDOR_AMD
 
+config BOARD_AMD_DB800
+	bool "DB800"
+	select ARCH_X86
+	select CPU_AMD_GEODELX
+	select OPTION_TABLE
+	select NORTHBRIDGE_AMD_GEODELX
+	select SOUTHBRIDGE_AMD_CS5536
+	select SUPERIO_WINBOND_W83627HF
+	select PIRQ_TABLE
+	help
+	  AMD DB800 Geode LX development board.
+
 config BOARD_AMD_NORWICH
 	bool "Norwich"
 	select ARCH_X86
@@ -36,5 +48,6 @@
 
 endchoice
 
+source "mainboard/amd/db800/Kconfig"
 source "mainboard/amd/norwich/Kconfig"
 
Index: LinuxBIOSv3-db800/mainboard/amd/norwich/irq_tables.h
===================================================================
--- LinuxBIOSv3-db800/mainboard/amd/norwich/irq_tables.h	(Revision 630)
+++ LinuxBIOSv3-db800/mainboard/amd/norwich/irq_tables.h	(Arbeitskopie)
@@ -17,17 +17,7 @@
 * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA  02110-1301 USA
 */
 
-#include <types.h>
-#include <lib.h>
-#include <console.h>
-#include <device/device.h>
-#include <device/pci.h>
-#include <string.h>
-#include <msr.h>
-#include <io.h>
 #include <pirq_routing.h>
-#include <amd_geodelx.h>
-#include "../../../southbridge/amd/cs5536/cs5536.h"
 
 /* Number of slots and devices in the PIR table */
 #define SLOT_COUNT 6
@@ -83,13 +73,19 @@
 	{0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0},	/* u8 rfu[11] */
 	0x00,			/* Checksum */
 	{
-	 /* If you change the number of entries, change the IRQ_SLOT_COUNT above! */
-	 /* bus, dev|fn,           {link, bitmap},      {link, bitmap},     {link, bitmap},     {link, bitmap},     slot, rfu */
-	 {0x00, (0x01 << 3) | 0x0, {{L_PIRQA, M_PIRQA}, {0x00, 0x00}, {0x00, 0x00}, {0x00, 0x00}}, 0x0, 0x0},	/* cpu */
-	 {0x00, (0x0F << 3) | 0x0, {{L_PIRQA, M_PIRQA}, {L_PIRQB, M_PIRQB}, {L_PIRQC, M_PIRQC}, {L_PIRQD, M_PIRQD}}, 0x0, 0x0},	/* chipset */
-	 {0x00, (0x0D << 3) | 0x0, {{L_PIRQB, M_PIRQB}, {L_PIRQC, M_PIRQC}, {L_PIRQD, M_PIRQD}, {L_PIRQA, M_PIRQA}}, 0x1, 0x0},	/* slot1 */
-	 {0x00, (0x0E << 3) | 0x0, {{L_PIRQC, M_PIRQC}, {L_PIRQD, M_PIRQD}, {L_PIRQA, M_PIRQA}, {L_PIRQB, M_PIRQB}}, 0x2, 0x0},	/* slot2 */
-	 {0x00, (0x0B << 3) | 0x0, {{L_PIRQD, M_PIRQD}, {L_PIRQA, M_PIRQA}, {L_PIRQB, M_PIRQB}, {L_PIRQC, M_PIRQC}}, 0x3, 0x0},	/* slot3 */
-	 {0x00, (0x0C << 3) | 0x0, {{L_PIRQA, M_PIRQA}, {L_PIRQB, M_PIRQB}, {L_PIRQC, M_PIRQC}, {L_PIRQD, M_PIRQD}}, 0x4, 0x0},	/* slot4 */
+		/* If you change the number of entries, change IRQ_SLOT_COUNT above! */
+		/* bus, dev|fn,           {link, bitmap},      {link, bitmap},     {link, bitmap},     {link, bitmap},     slot, rfu */
+		/* CPU */
+		{0x00, (0x01 << 3) | 0x0, {{L_PIRQA, M_PIRQA}, {0x00, 0x00}, {0x00, 0x00}, {0x00, 0x00}}, 0x0, 0x0},
+		/* chipset */
+		{0x00, (0x0F << 3) | 0x0, {{L_PIRQA, M_PIRQA}, {L_PIRQB, M_PIRQB}, {L_PIRQC, M_PIRQC}, {L_PIRQD, M_PIRQD}}, 0x0, 0x0},
+		/* slot1 */
+		{0x00, (0x0D << 3) | 0x0, {{L_PIRQB, M_PIRQB}, {L_PIRQC, M_PIRQC}, {L_PIRQD, M_PIRQD}, {L_PIRQA, M_PIRQA}}, 0x1, 0x0},
+		/* slot2 */
+		{0x00, (0x0E << 3) | 0x0, {{L_PIRQC, M_PIRQC}, {L_PIRQD, M_PIRQD}, {L_PIRQA, M_PIRQA}, {L_PIRQB, M_PIRQB}}, 0x2, 0x0},
+		/* slot3 */
+		{0x00, (0x0B << 3) | 0x0, {{L_PIRQD, M_PIRQD}, {L_PIRQA, M_PIRQA}, {L_PIRQB, M_PIRQB}, {L_PIRQC, M_PIRQC}}, 0x3, 0x0},
+		/* slot4 */
+		{0x00, (0x0C << 3) | 0x0, {{L_PIRQA, M_PIRQA}, {L_PIRQB, M_PIRQB}, {L_PIRQC, M_PIRQC}, {L_PIRQD, M_PIRQD}}, 0x4, 0x0},
 	 }
 };
Index: LinuxBIOSv3-db800/mainboard/amd/db800/Kconfig
===================================================================
--- LinuxBIOSv3-db800/mainboard/amd/db800/Kconfig	(Revision 0)
+++ LinuxBIOSv3-db800/mainboard/amd/db800/Kconfig	(Arbeitskopie)
@@ -21,8 +21,8 @@
 
 config MAINBOARD_NAME
 	string
-	default amd/norwich
-	depends BOARD_AMD_NORWICH
+	default amd/db800
+	depends BOARD_AMD_DB800
 	help
 	  This is the default mainboard name.
 
@@ -30,7 +30,7 @@
 	hex
 	# TODO: Fix PCI ID.
 	default 0x1022
-	depends BOARD_AMD_NORWICH
+	depends BOARD_AMD_DB800
 	help
 	  Mainboard specific PCI subsystem vendor ID.
 
@@ -38,7 +38,7 @@
 	hex
 	# TODO: Fix PCI ID.
 	default 0x2323
-	depends BOARD_AMD_NORWICH
+	depends BOARD_AMD_DB800
 	help
 	  Mainboard specific PCI subsystem device ID.
 
Index: LinuxBIOSv3-db800/mainboard/amd/db800/initram.c
===================================================================
--- LinuxBIOSv3-db800/mainboard/amd/db800/initram.c	(Revision 0)
+++ LinuxBIOSv3-db800/mainboard/amd/db800/initram.c	(Arbeitskopie)
@@ -67,7 +67,7 @@
 }
 
 /**
-  * main for initram for the AMD Norwich development platform.
+  * main for initram for the AMD DB800 development platform.
   * It might seem that you could somehow do these functions in, e.g., the cpu
   * code, but the order of operations and what those operations are is VERY
   * strongly mainboard dependent. It's best to leave it in the mainboard code.
Index: LinuxBIOSv3-db800/mainboard/amd/db800/dts
===================================================================
--- LinuxBIOSv3-db800/mainboard/amd/db800/dts	(Revision 0)
+++ LinuxBIOSv3-db800/mainboard/amd/db800/dts	(Arbeitskopie)
@@ -19,8 +19,8 @@
  */
 
 /{
-	mainboard-vendor = "PC Engines";
-	mainboard-name = "ALIX1.C";
+	mainboard-vendor = "AMD";
+	mainboard-name = "DB800";
 	cpus { };
 	apic at 0 {
 		/config/("northbridge/amd/geodelx/apic");
@@ -45,6 +45,7 @@
 			/* GPIO(0-0x20) for INT D:C:B:A, 0xFF=none. 
 			 * See virtual PIC spec. */
 			enable_gpio_int_route = "0x0D0C0700";
+			enable_USBP4_device = "1";
 		};
 		ioport at 46 {
 			/config/("superio/winbond/w83627hf/dts");
Index: LinuxBIOSv3-db800/mainboard/amd/db800/irq_tables.h
===================================================================
--- LinuxBIOSv3-db800/mainboard/amd/db800/irq_tables.h	(Revision 0)
+++ LinuxBIOSv3-db800/mainboard/amd/db800/irq_tables.h	(Arbeitskopie)
@@ -19,12 +19,14 @@
 
 #include <pirq_routing.h>
 
+/* Number of slots and devices in the PIR table */
+#define SLOT_COUNT 4
 
 /* Platform IRQs */
-#define PIRQA 11
-#define PIRQB 10
-#define PIRQC 11
-#define PIRQD 9
+#define PIRQA 10
+#define PIRQB 11
+#define PIRQC 10
+#define PIRQD 11
 
 /* Map */
 #define M_PIRQA (1 << PIRQA)	/* Bitmap of supported IRQs */
@@ -39,39 +41,18 @@
 #define L_PIRQD 4		/* Means Slot INTx# Connects To Chipset INTD# */
 
 /*
- * ALIX1.C interrupt wiring.
+ * AMD DB800 interrupt wiring.
  *
  * Devices are:
  *
- * 00:01.0 Host bridge: Advanced Micro Devices [AMD] CS5536 [Geode companion] Host Bridge (rev 31)
- * 00:01.2 Entertainment encryption device: Advanced Micro Devices [AMD] Geode LX AES Security Block
- * 00:0d.0 Ethernet controller: VIA Technologies, Inc. VT6105M [Rhine-III] (rev 96)
- * 00:0e.0 Network controller: Intersil Corporation Prism 2.5 Wavelan chipset (rev 01)
- * 00:0f.0 ISA bridge: Advanced Micro Devices [AMD] CS5536 [Geode companion] ISA (rev 03)
- * 00:0f.2 IDE interface: Advanced Micro Devices [AMD] CS5536 [Geode companion] IDE (rev 01)
- * 00:0f.3 Multimedia audio controller: Advanced Micro Devices [AMD] CS5536 [Geode companion] Audio (rev 01)
- * 00:0f.4 USB Controller: Advanced Micro Devices [AMD] CS5536 [Geode companion] OHC (rev 02)
- * 00:0f.5 USB Controller: Advanced Micro Devices [AMD] CS5536 [Geode companion] EHC (rev 02)
+ * FIXME
  *
- * The only devices that interrupt are:
- *
- * What         Device  IRQ     PIN     PIN WIRED TO
- * -------------------------------------------------
- * AES          00:01.2 0a      01      A       A
- * 3VPCI        00:0c.0 0a      01      A       A
- * eth0 	00:0d.0 0b      01      A       B
- * mpci 	00:0e.0 0a      01      A       A
- * usb          00:0f.3 0b      02      B       B
- * usb          00:0f.4 0b      04      D       D
- * usb          00:0f.5 0b      04      D       D
- *
- * The only swizzled interrupt is eth0, where INTA is wired to interrupt controller line B.
  */
 
 const struct irq_routing_table intel_irq_routing_table = {
 	PIRQ_SIGNATURE,
 	PIRQ_VERSION,
-	32 + 16 * 5,		/* Max. number of devices on the bus */
+	32 + 16 * SLOT_COUNT,	/* Max. number of devices on the bus */
 	0x00,			/* Where the interrupt router lies (bus) */
 	(0x0F << 3) | 0x0,      /* Where the interrupt router lies (dev) */
 	0x00,			/* IRQs devoted exclusively to PCI usage */
@@ -88,16 +69,13 @@
 		/* CPU */
 		{0x00, (0x01 << 3) | 0x0, {{L_PIRQA, M_PIRQA}, {0x00, 0x00}, {0x00, 0x00}, {0x00, 0x00}}, 0x0, 0x0},
 
-		/* PCI (slot 1) */
-		{0x00, (0x0C << 3) | 0x0, {{L_PIRQC, M_PIRQC}, {L_PIRQD, M_PIRQD}, {L_PIRQA, M_PIRQA}, {L_PIRQB, M_PIRQB}}, 0x4, 0x0},
+		/* Chipset slots -- f.3 wires to B, and f.4 and f.5 wires to D. */
+		{0x00, (0x0F << 3) | 0x0, {{L_PIRQA, M_PIRQA}, {L_PIRQB, M_PIRQB}, {L_PIRQC, M_PIRQC}, {L_PIRQD, M_PIRQD}}, 0x0, 0x0},
 
 		/* On-board ethernet */
 		{0x00, (0x0D << 3) | 0x0, {{L_PIRQB, M_PIRQB}, {0x00, 0x00}, {0x00, 0x00}, {0x00, 0x00}}, 0x0, 0x0},
 
-		/* Mini PCI (slot 2) */
-		{0x00, (0x0E << 3) | 0x0, {{L_PIRQA, M_PIRQA}, {L_PIRQB, M_PIRQB}, {L_PIRQC, M_PIRQC}, {L_PIRQD, M_PIRQD}}, 0x1, 0x0},
-
-		/* Chipset slots -- f.3 wires to B, and f.4 and f.5 wires to D. */
-		{0x00, (0x0F << 3) | 0x0, {{L_PIRQA, M_PIRQA}, {L_PIRQB, M_PIRQB}, {L_PIRQC, M_PIRQC}, {L_PIRQD, M_PIRQD}}, 0x0, 0x0},
+		/* PCI (slot 1) */
+		{0x00, (0x0E << 3) | 0x0, {{L_PIRQC, M_PIRQC}, {L_PIRQD, M_PIRQD}, {L_PIRQA, M_PIRQA}, {L_PIRQB, M_PIRQB}}, 0x1, 0x0},
 	}
 };
Index: LinuxBIOSv3-db800/mainboard/pcengines/alix1c/irq_tables.h
===================================================================
--- LinuxBIOSv3-db800/mainboard/pcengines/alix1c/irq_tables.h	(Revision 630)
+++ LinuxBIOSv3-db800/mainboard/pcengines/alix1c/irq_tables.h	(Arbeitskopie)
@@ -19,6 +19,8 @@
 
 #include <pirq_routing.h>
 
+/* Number of slots and devices in the PIR table */
+#define SLOT_COUNT 5
 
 /* Platform IRQs */
 #define PIRQA 11
@@ -71,7 +73,7 @@
 const struct irq_routing_table intel_irq_routing_table = {
 	PIRQ_SIGNATURE,
 	PIRQ_VERSION,
-	32 + 16 * 5,		/* Max. number of devices on the bus */
+	32 + 16 * SLOT_COUNT,	/* Max. number of devices on the bus */
 	0x00,			/* Where the interrupt router lies (bus) */
 	(0x0F << 3) | 0x0,      /* Where the interrupt router lies (dev) */
 	0x00,			/* IRQs devoted exclusively to PCI usage */


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




From c-d.hailfinger.devel.2006 at gmx.net  Tue Mar  4 04:53:47 2008
From: c-d.hailfinger.devel.2006 at gmx.net (Carl-Daniel Hailfinger)
Date: Tue, 04 Mar 2008 04:53:47 +0100
Subject: [coreboot] [LinuxBIOS] W39V040BPZ or vt8237. Flashing problems.
In-Reply-To: <20080304001506.23800.qmail@stuge.se>
References: <46FD7099.6050801@comcast.net>	<13426df10709281428h125862daqcbf0bc2c5249281a@mail.gmail.com>	<46FD783F.4000502@comcast.net>	<13426df10709281528g385a615cs75a6b2b2ee8124ab@mail.gmail.com>	<46FD8AF8.9040702@comcast.net>	<13426df10709281754r3ed1d639qe5a597b9dbe67ac3@mail.gmail.com>	<46FE9285.6000900@comcast.net>
	<47CC72A0.5050707@gmx.net>	<1204587725.6247.4.camel@Mobulus>
	<20080304001506.23800.qmail@stuge.se>
Message-ID: <47CCC7CB.3010602@gmx.net>

Hi Yinghai,

I am seeing problems with Winbond W39V040B and MCP51. It seems these 
problems are probably related to LPC timing. Did you check the MCP51 
datasheets for LPC timing and flashing when you were at AMD?

On 04.03.2008 01:15, Peter Stuge wrote:
> On Mon, Mar 03, 2008 at 06:42:05PM -0500, Corey Osgood wrote:
>   
>>> If I hot-unplug the flash chip and hot-replug it, it is recognized
>>> again. Reading it shows the erase was successful, but once I try
>>> to program even one byte, communication with the flash chip fails
>>> completely and I have to unplug and replug to fix that.
>>>       
>> I'm seeing exactly the same thing with the cn700+vt8237r on Jetway
>> J7F2W, same flash chip, except that where it hangs seems random.
>>     
>
> I take this to mean that 8237 and the W39V040BPZ aren't really
> compatible.
>
> I would investigate if the timing for the two is compatible on paper.
> Also, maybe the 8237 has some speed setting like the ITE.
>   

The interesting thing is that the chip is the factory installed chip and 
flashing it should (not yet tested) work fine with the vendor flash tool.

Regards,
Carl-Daniel

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




From c-d.hailfinger.devel.2006 at gmx.net  Tue Mar  4 04:56:48 2008
From: c-d.hailfinger.devel.2006 at gmx.net (Carl-Daniel Hailfinger)
Date: Tue, 04 Mar 2008 04:56:48 +0100
Subject: [coreboot] [LinuxBIOS] W39V040BPZ or vt8237. Flashing problems.
In-Reply-To: <47CCC7CB.3010602@gmx.net>
References: <46FD7099.6050801@comcast.net>	<13426df10709281428h125862daqcbf0bc2c5249281a@mail.gmail.com>	<46FD783F.4000502@comcast.net>	<13426df10709281528g385a615cs75a6b2b2ee8124ab@mail.gmail.com>	<46FD8AF8.9040702@comcast.net>	<13426df10709281754r3ed1d639qe5a597b9dbe67ac3@mail.gmail.com>	<46FE9285.6000900@comcast.net>	<47CC72A0.5050707@gmx.net>	<1204587725.6247.4.camel@Mobulus>	<20080304001506.23800.qmail@stuge.se>
	<47CCC7CB.3010602@gmx.net>
Message-ID: <47CCC880.5080406@gmx.net>

On 04.03.2008 04:53, Carl-Daniel Hailfinger wrote:
> On 04.03.2008 01:15, Peter Stuge wrote:
>   
>> On Mon, Mar 03, 2008 at 06:42:05PM -0500, Corey Osgood wrote:
>>   
>>     
>>>> If I hot-unplug the flash chip and hot-replug it, it is recognized
>>>> again. Reading it shows the erase was successful, but once I try
>>>> to program even one byte, communication with the flash chip fails
>>>> completely and I have to unplug and replug to fix that.
>>>>       
>>>>         
>>> I'm seeing exactly the same thing with the cn700+vt8237r on Jetway
>>> J7F2W, same flash chip, except that where it hangs seems random.
>>>     
>>>       
>> I take this to mean that 8237 and the W39V040BPZ aren't really
>> compatible.
>>
>> I would investigate if the timing for the two is compatible on paper.
>> Also, maybe the 8237 has some speed setting like the ITE.  
>>     
>
> The interesting thing is that the chip is the factory installed chip and 
> flashing it should (not yet tested) work fine with the vendor flash tool.
>   

Yes, the 8237 has some LPC timing settings which could help here. See 
the data shett for details.

Regards,
Carl-Daniel

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




From jonathanrrogers at gmail.com  Tue Mar  4 05:06:53 2008
From: jonathanrrogers at gmail.com (Jonathan Rogers)
Date: Mon, 03 Mar 2008 23:06:53 -0500
Subject: [coreboot] VGA and Asus a8v-e_se
In-Reply-To: <47CB1D6D.9090904@assembler.cz>
References: <47CA62D2.3040702@gmail.com> <47CA669B.9090202@assembler.cz>
	<47CA6B0B.6080804@gmail.com> <47CAE831.9070402@assembler.cz>
	<47CB1616.6070105@gmail.com> <47CB1D6D.9090904@assembler.cz>
Message-ID: <47CCCADD.7060908@gmail.com>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Rudolf Marek wrote:
> Hi,
> 
> To fix the powernow add following after following line into dsdt.asl
> 
> Processor (\_PR.CPU1, 0x01, 0x000000, 0x00) {}
> 
>    Scope (\_PR.CPU0)
>     {
>         Name (_PCT, Package (0x02)
>         {
>             ResourceTemplate ()
>             {
>                 Register (FFixedHW,
>                     0x00,               // Bit Width
>                     0x00,               // Bit Offset
>                     0x0000000000000000, // Address
>                     ,)
>             },
> 
>             ResourceTemplate ()
>             {
>                 Register (FFixedHW,
>                     0x00,               // Bit Width
>                     0x00,               // Bit Offset
>                     0x0000000000000000, // Address
>                     ,)
>             }
>         })
>         Name (_PSS, Package (0x04)
>         {
>             Package (0x06)
>             {
>                 0x00000898,
>                 0x00014D34,
>                 0x00000064,
>                 0x00000009,
>                 0xE020298E,
>                 0x0000018E
>             },
> 
>             Package (0x06)
>             {
>                 0x000007D0,
>                 0x00014438,
>                 0x00000064,
>                 0x00000009,
>                 0xE0202A0C,
>                 0x0000020C
>             },
> 
>             Package (0x06)
>             {
>                 0x00000708,
>                 0x00011300,
>                 0x00000064,
>                 0x00000009,
>                 0xE0202A8A,
>                 0x0000028A
>             },
> 
>             Package (0x06)
>             {
>                 0x000003E8,
>                 0x00008D04,
>                 0x00000064,
>                 0x00000009,
>                 0xE0202C82,
>                 0x00000482
>             }
>         })
>         Name (_PPC, 0x00)
>     }
> 
> Then just recompile Coreboot. I'm using the powernowd and it does work.
> 
> 
> If possible could you send me the lspci -xxx when the coreboot is
> running too? You may also try
> /LinuxBIOSv2/src/southbridge/via/k8t890/k8t890_pcie.c to edit the init
> function:
> static void peg_init(struct device *dev)
> 
> I think you can put return at the beginning of the function. There is a
> chance that it will work without anything else. I think problem is in
> card reset.
> 
> I have in plan to cleanup the PCIe init a bit but frankly I dont know if
> the reset is needed and even not sure about the link retrain.

Your instructions about both Powernow! and VGA BIOS were right on. I now
have my Ubuntu system running with both video and frequency scaling
after booting from coreboot. I have attached the output from "sudo lspci
- -vvvxxx" after making the above changes and booting coreboot.

All of the regular PCI devices seem to be on bus 00, while the onboard
PCIe network interface is on bus 05. The PCIe x16 card is on bus 02.
Before I bypassed the peg_init function, all of the PCI devices except
the Nvidia PCIe x16 video card seemed to work. When I ran lspci, it made
no mention of any device on bus 02 or any vga or nvidia device; it did
however see the network interface on bus 05. I neglected to save that
output, but I can un-bypass peg_init and save the lspci output if it
will be helpful.

BTW, how are flash chip sizes detected? All of the images I've generated
using coreboot or saved using flashrom on this board are 512KiB, but the
manual indicates that it has 4MiB of flash. Is the manual lying? I'm
curious because I'm wondering if it's possible to use a Linux payload
with this board, but I realize that Filo or etherboot is probably
sufficient as far as minimizing boot time. Thank you very much for your
insight and tolerance of my limited knowledge.

Jonathan Rogers
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFHzMrdMs6f82yVS5wRAlJuAKDfO80g65SlNXMnW5yYx4UEI7fTHwCgjRft
4LpXmmZ1i3WrK9CP9tz3q18=
=SNFi
-----END PGP SIGNATURE-----
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: a8v-e_se.lspci_root_coreboot
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20080303/a71cc57d/attachment.ksh>

From jonathanrrogers at gmail.com  Tue Mar  4 05:48:54 2008
From: jonathanrrogers at gmail.com (Jonathan Rogers)
Date: Mon, 03 Mar 2008 23:48:54 -0500
Subject: [coreboot] VGA and Asus a8v-e_se
In-Reply-To: <47CB1D6D.9090904@assembler.cz>
References: <47CA62D2.3040702@gmail.com> <47CA669B.9090202@assembler.cz>
	<47CA6B0B.6080804@gmail.com> <47CAE831.9070402@assembler.cz>
	<47CB1616.6070105@gmail.com> <47CB1D6D.9090904@assembler.cz>
Message-ID: <47CCD4B6.30002@gmail.com>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Rudolf Marek wrote:
> If possible could you send me the lspci -xxx when the coreboot is
> running too? 

I have attached the output of "sudo lspci -vvvxxx" after booting
coreboot with the normal peg_init when the Nvidia PCIe x16 VGA card
wasn't working.

One thing that doesn't work currently is a soft reboot. When I reboot in
Linux I get the following on the serial console, then it the machine
just sits there. I then have to hit the reset button or cycle the power.

- ------------------------------------------------------------------
 * Will now restart
[  451.336818] Restarting system.


coreboot-2.0.0.0Fallback Mon Mar  3 20:19:29 EST 2008 starting...
now booting... fallback


coreboot-2.0.0.0Normal Mon Mar  3 20:19:00 EST 2008 starting...
now booting... real_main



INIT detected from  ---- {APICID = 00 NODEID = 00 COREID = 00} ---

Issuing SOFT_RESET...


coreboot-2.0.0.0Fallback Mon Mar  3 20:19:29 EST 2008 starting...
now booting... fallback


coreboot-2.0.0.0Normal Mon Mar  3 20:19:00 EST 2008 starting...
now booting... real_main
core0 started:
now booting... Core0 started
started ap apicid:
SBLink=00
NC node|link=00
- ------------------------------------------------------------------

Thanks

Jonathan Rogers
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFHzNS1Ms6f82yVS5wRAoTMAJ9YmHVTUZN7BG6rFa9TJriJYZdB2ACgqvMz
uyWn0UhZg6Cv6GZTb7d7s14=
=3TWO
-----END PGP SIGNATURE-----
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: lspci_asus_a8v-e_se_novga.log
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20080303/f515148e/attachment.ksh>

From patrick at georgi-clan.de  Tue Mar  4 08:16:08 2008
From: patrick at georgi-clan.de (Patrick Georgi)
Date: Tue, 04 Mar 2008 08:16:08 +0100
Subject: [coreboot] VGA and Asus a8v-e_se
In-Reply-To: <47CCCADD.7060908@gmail.com>
References: <47CA62D2.3040702@gmail.com> <47CA669B.9090202@assembler.cz>
	<47CA6B0B.6080804@gmail.com> <47CAE831.9070402@assembler.cz>
	<47CB1616.6070105@gmail.com> <47CB1D6D.9090904@assembler.cz>
	<47CCCADD.7060908@gmail.com>
Message-ID: <1204614968.5962.1.camel@tetris>

Am Montag, den 03.03.2008, 23:06 -0500 schrieb Jonathan Rogers:
> BTW, how are flash chip sizes detected? All of the images I've
> generated
> using coreboot or saved using flashrom on this board are 512KiB, but the
> manual indicates that it has 4MiB of flash. Is the manual lying? I'm
I guess that's 512 kilobytes vs. 4 megabits?
Memory chip sizes are usually specified in bits.


Patrick Georgi




From klaus123 at ibnoetzold.de  Tue Mar  4 08:31:23 2008
From: klaus123 at ibnoetzold.de (Klaus Stammermann)
Date: Tue, 4 Mar 2008 08:31:23 +0100
Subject: [coreboot] Problems with VIA EPIA-ME6000
In-Reply-To: <20080303203322.GA7335@coresystems.de>
References: <200803031520.56570.klaus123@ibnoetzold.de>
	<20080303203322.GA7335@coresystems.de>
Message-ID: <200803040831.23138.klaus123@ibnoetzold.de>

Am Montag, 3. M?rz 2008 21:33 schrieben Sie:
> * Klaus Stammermann <klaus123 at ibnoetzold.de> [080303 15:20]:
> > Hi there
> >
> > I have some trouble to use coreboot on my VIA EPIA-ME6000 so I hope
> > someone could give me some hints.
> >
> > With epia-m and filo I can build a bios without vga. This runs till
> > jumping to kernel. This breaks up with an error:
> > Loading kernel... ok
> > "Jumping to entry point...
> > 0
>
> Was the kernel built with serial console support? Was console=ttyS0,...
> specified as a command line option to the kernel?
>

Yes, I use following startup parameters:
"hda1:/boot/vmlinuz root=/dev/hda1 console=tty0 console=ttyS0,115200"

> > And using VGA-support with onboard device I get this message:
> > "DO THE VGA BIOS
> > found VGA: vid=1106, did=3122
> > rom base, size: fffc0000
> > BAD SIGNATURE 0x7f 0x45
> > Unexpected Exception: 13 @ 10:000130fe - Halting
> > Code: 0 eflags: 00010006
> > eax: 00000000 ebx: 000247d4 ecx: 80010030 edx: 00000cfc
> > edi: 0001a4b0 esi: 000247d4 ebp: 00023f8c esp: 00023f6c"
> >
> > What do I have to do to boot with a VGA-card? Are there any options which
> > have to be set?
>
> I think you need a special version of the vga option rom.
> Have you used the one from the optionroms repo?
> http://www.coreboot.org/viewvc/trunk/optionroms/?root=optionroms
>
> Stefan
I did not use that optionroms. But how can I use this optionrom? Where do I 
have to put it in my image?

Klaus



From jonathanrrogers at gmail.com  Tue Mar  4 10:24:25 2008
From: jonathanrrogers at gmail.com (Jonathan Rogers)
Date: Tue, 04 Mar 2008 04:24:25 -0500
Subject: [coreboot] VGA and Asus a8v-e_se
In-Reply-To: <1204614968.5962.1.camel@tetris>
References: <47CA62D2.3040702@gmail.com> <47CA669B.9090202@assembler.cz>	
	<47CA6B0B.6080804@gmail.com> <47CAE831.9070402@assembler.cz>	
	<47CB1616.6070105@gmail.com> <47CB1D6D.9090904@assembler.cz>	
	<47CCCADD.7060908@gmail.com> <1204614968.5962.1.camel@tetris>
Message-ID: <47CD1549.4090504@gmail.com>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Patrick Georgi wrote:
> Am Montag, den 03.03.2008, 23:06 -0500 schrieb Jonathan Rogers:
>> BTW, how are flash chip sizes detected? All of the images I've
>> generated
>> using coreboot or saved using flashrom on this board are 512KiB, but the
>> manual indicates that it has 4MiB of flash. Is the manual lying? I'm
> I guess that's 512 kilobytes vs. 4 megabits?
> Memory chip sizes are usually specified in bits.

This is the exact text from the user manual PDF:

BIOS features 4 MB Flash ROM, Award BIOS, PnP, DMI2.0, WfM2.0,
                SM BIOS 2.3

So, does that mean 4 megabits? If so, that's even less than 512KiB
(524288 byte) images I've been writing, which are actually about 4.19
megabits.

Jonathan Rogers
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFHzRVJMs6f82yVS5wRAq2pAKDeJj8tq7np6AF3e2TyYr2nH+E8cgCgnkZ0
K1ADvvxtwcU3Lgv8En4JaFA=
=p2HO
-----END PGP SIGNATURE-----



From r.marek at assembler.cz  Tue Mar  4 11:00:15 2008
From: r.marek at assembler.cz (Rudolf Marek)
Date: Tue, 04 Mar 2008 11:00:15 +0100
Subject: [coreboot] VGA and Asus a8v-e_se
In-Reply-To: <47CD1549.4090504@gmail.com>
References: <47CA62D2.3040702@gmail.com>
	<47CA669B.9090202@assembler.cz>		<47CA6B0B.6080804@gmail.com>
	<47CAE831.9070402@assembler.cz>		<47CB1616.6070105@gmail.com>
	<47CB1D6D.9090904@assembler.cz>		<47CCCADD.7060908@gmail.com>
	<1204614968.5962.1.camel@tetris> <47CD1549.4090504@gmail.com>
Message-ID: <47CD1DAF.9080904@assembler.cz>

Hi,

The flash is only 512KB I bought 1MB part. I will tell in evening which 
and what needs to be done to get it work.
I need to work now.
Rudolf



From Libo.Feng at amd.com  Tue Mar  4 11:08:02 2008
From: Libo.Feng at amd.com (Feng, Libo)
Date: Tue, 4 Mar 2008 18:08:02 +0800
Subject: [coreboot] PIC, APIC, XAPIC and XIOAPIC
Message-ID: <DD1CC71B621B004FA76856E5129D6B170136788C@sbjgexmb1.amd.com>


Hi, all,

I am a little confused by PIC, APIC, XAPIC and XIOAPIC.

In LB stage, only PIC mode is applied, isn't it? However, I remember some people of LB community told me there was no ISR except the debug ISR during LB. So does this mean it totally unnecessary to setup PIC via C00h/C001h IO port in LB?

APIC is setup only after OS runs and gets the interrupt routing from MPTable or ACPI table, is it correct? Then, what difference between APIC and XAPIC? Some documents say APIC has MMIO space registers at FEC00000h while XAPIC has PCI configuration space registers. But some documents seems to refer the same controller by APIC and XAPIC.

And XAPIC and XIOAPIC are the same things, aren?t they?

Please help me out, I am completely confused by these terms.


Best Regards

??? Feng Libo @ AMD  Ext: 20906
Mobile Phone: 13683249071
Office Phone: 0086-010-62801406

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

From c-d.hailfinger.devel.2006 at gmx.net  Tue Mar  4 12:04:56 2008
From: c-d.hailfinger.devel.2006 at gmx.net (Carl-Daniel Hailfinger)
Date: Tue, 04 Mar 2008 12:04:56 +0100
Subject: [coreboot] VGA and Asus a8v-e_se
In-Reply-To: <47CD1549.4090504@gmail.com>
References: <47CA62D2.3040702@gmail.com>
	<47CA669B.9090202@assembler.cz>		<47CA6B0B.6080804@gmail.com>
	<47CAE831.9070402@assembler.cz>		<47CB1616.6070105@gmail.com>
	<47CB1D6D.9090904@assembler.cz>		<47CCCADD.7060908@gmail.com>
	<1204614968.5962.1.camel@tetris> <47CD1549.4090504@gmail.com>
Message-ID: <47CD2CD8.1020409@gmx.net>

On 04.03.2008 10:24, Jonathan Rogers wrote:
> Patrick Georgi wrote:
> > Am Montag, den 03.03.2008, 23:06 -0500 schrieb Jonathan Rogers:
> >> BTW, how are flash chip sizes detected? All of the images I've
> >> generated
> >> using coreboot or saved using flashrom on this board are 512KiB, 
> but the
> >> manual indicates that it has 4MiB of flash. Is the manual lying? I'm
> > I guess that's 512 kilobytes vs. 4 megabits?
> > Memory chip sizes are usually specified in bits.
>
> This is the exact text from the user manual PDF:
>
> BIOS features 4 MB Flash ROM, Award BIOS, PnP, DMI2.0, WfM2.0,
>                 SM BIOS 2.3
>
> So, does that mean 4 megabits? If so, that's even less than 512KiB
> (524288 byte) images I've been writing, which are actually about 4.19
> megabits.

Think binary megabits. In that case, 4 megabits (which BIOS flash and 
mainboard vendors strangely write as "MB") is exactly 512 kiBytes.

Regards,
Carl-Daniel
-- 
http://www.hailfinger.org/




From uwe at hermann-uwe.de  Tue Mar  4 12:50:54 2008
From: uwe at hermann-uwe.de (Uwe Hermann)
Date: Tue, 4 Mar 2008 12:50:54 +0100
Subject: [coreboot] Problems with VIA EPIA-ME6000
In-Reply-To: <200803040831.23138.klaus123@ibnoetzold.de>
References: <200803031520.56570.klaus123@ibnoetzold.de>
	<20080303203322.GA7335@coresystems.de>
	<200803040831.23138.klaus123@ibnoetzold.de>
Message-ID: <20080304115054.GA17625@greenwood>

On Tue, Mar 04, 2008 at 08:31:23AM +0100, Klaus Stammermann wrote:
> Am Montag, 3. M?rz 2008 21:33 schrieben Sie:
> > * Klaus Stammermann <klaus123 at ibnoetzold.de> [080303 15:20]:
> > > Hi there
> > >
> > > I have some trouble to use coreboot on my VIA EPIA-ME6000 so I hope
> > > someone could give me some hints.
> > >
> > > With epia-m and filo I can build a bios without vga. This runs till
> > > jumping to kernel. This breaks up with an error:
> > > Loading kernel... ok
> > > "Jumping to entry point...
> > > 0
> >
> > Was the kernel built with serial console support? Was console=ttyS0,...
> > specified as a command line option to the kernel?
> >
> 
> Yes, I use following startup parameters:
> "hda1:/boot/vmlinuz root=/dev/hda1 console=tty0 console=ttyS0,115200"

And you also use 'USE_GRUB = 0'? Otherwise FILO will try to read your
menu.lst file from GRUB and ignore the above line.


> I did not use that optionroms. But how can I use this optionrom? Where do I 
> have to put it in my image?

I think at the beginning (but someone please correct me if I'm wrong), i.e.

cat vga.rom coreboot.com > coreboot_full.rom

But you need to tweak the config files too in order to make the
coreboot.rom smaller (so there's place for vga.rom).


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



From klaus123 at ibnoetzold.de  Tue Mar  4 13:15:06 2008
From: klaus123 at ibnoetzold.de (Klaus Stammermann)
Date: Tue, 4 Mar 2008 13:15:06 +0100
Subject: [coreboot] Problems with VIA EPIA-ME6000
In-Reply-To: <20080304115054.GA17625@greenwood>
References: <200803031520.56570.klaus123@ibnoetzold.de>
	<200803040831.23138.klaus123@ibnoetzold.de>
	<20080304115054.GA17625@greenwood>
Message-ID: <200803041315.06358.klaus123@ibnoetzold.de>

Am Dienstag, 4. M?rz 2008 12:50 schrieben Sie:
> On Tue, Mar 04, 2008 at 08:31:23AM +0100, Klaus Stammermann wrote:
> > Am Montag, 3. M?rz 2008 21:33 schrieben Sie:
> > > * Klaus Stammermann <klaus123 at ibnoetzold.de> [080303 15:20]:
> > > > Hi there
> > > >
> > > > I have some trouble to use coreboot on my VIA EPIA-ME6000 so I hope
> > > > someone could give me some hints.
> > > >
> > > > With epia-m and filo I can build a bios without vga. This runs till
> > > > jumping to kernel. This breaks up with an error:
> > > > Loading kernel... ok
> > > > "Jumping to entry point...
> > > > 0
> > >
> > > Was the kernel built with serial console support? Was console=ttyS0,...
> > > specified as a command line option to the kernel?
> >
> > Yes, I use following startup parameters:
> > "hda1:/boot/vmlinuz root=/dev/hda1 console=tty0 console=ttyS0,115200"
>
> And you also use 'USE_GRUB = 0'? Otherwise FILO will try to read your
> menu.lst file from GRUB and ignore the above line.
>

In file Config on filo 0.4.2 I can't find such an option. But I use
LINUX_LOADER = 1
which should activate filo as loader for standard Linux kernel image. 

> > I did not use that optionroms. But how can I use this optionrom? Where do
> > I have to put it in my image?
>
> I think at the beginning (but someone please correct me if I'm wrong), i.e.
>
> cat vga.rom coreboot.com > coreboot_full.rom
>

I think so too but I don't know exactly. So I will try this.

> But you need to tweak the config files too in order to make the
> coreboot.rom smaller (so there's place for vga.rom).
>
>
> Uwe.

Klaus



From jonathanrrogers at gmail.com  Tue Mar  4 13:20:06 2008
From: jonathanrrogers at gmail.com (Jonathan Rogers)
Date: Tue, 04 Mar 2008 07:20:06 -0500
Subject: [coreboot] VGA and Asus a8v-e_se
In-Reply-To: <47CD1DAF.9080904@assembler.cz>
References: <47CA62D2.3040702@gmail.com>
	<47CA669B.9090202@assembler.cz>		<47CA6B0B.6080804@gmail.com>
	<47CAE831.9070402@assembler.cz>		<47CB1616.6070105@gmail.com>
	<47CB1D6D.9090904@assembler.cz>		<47CCCADD.7060908@gmail.com>
	<1204614968.5962.1.camel@tetris> <47CD1549.4090504@gmail.com>
	<47CD1DAF.9080904@assembler.cz>
Message-ID: <47CD3E76.6010203@gmail.com>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Rudolf Marek wrote:
> The flash is only 512KB I bought 1MB part. I will tell in evening which
> and what needs to be done to get it work.
> I need to work now.

Yeah, I was just curious about the apparent discrepancy; it's not a
priority for to me to fit more in there. I now realize that as
Carl-Daniel pointed out, when the manual says 4MB, it means the same as
512KiB. Thanks for the help.

Jonathan Rogers
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFHzT52Ms6f82yVS5wRAhkhAJ4yIP+hIW1vSXb4E3UrQ6LNSiMl8gCgo1+d
p7NI4GU2YuOm6Ec0IzZRXvo=
=zamI
-----END PGP SIGNATURE-----



From joe at smittys.pointclark.net  Tue Mar  4 14:36:25 2008
From: joe at smittys.pointclark.net (joe at smittys.pointclark.net)
Date: Tue, 04 Mar 2008 08:36:25 -0500
Subject: [coreboot] flashrom issues??
In-Reply-To: <20080302120343.ce1rrwrgo4ggw4gc@www.smittys.pointclark.net>
References: <20080216134533.6awmn90xcsww80c4@www.smittys.pointclark.net>
	<20080219112943.6w24vj5rc0okkc4s@www.smittys.pointclark.net>
	<20080219163507.GA21962@coresystems.de>
	<20080229123601.4dnjxissn40c4gw8@www.smittys.pointclark.net>
	<20080229190715.GA10976@coresystems.de> <47C8593F.1030607@gmx.net>
	<20080229192145.GA15773@coresystems.de> <47C89FC3.3000207@gmx.net>
	<20080301080454.x1rgbpahwwks4k8c@www.smittys.pointclark.net>
	<47C978F4.4030904@gmx.net>
	<20080301123404.lsocj753k88k08k4@www.smittys.pointclark.net>
	<20080302120343.ce1rrwrgo4ggw4gc@www.smittys.pointclark.net>
Message-ID: <20080304083625.2za5fcgp2oso448k@www.smittys.pointclark.net>

Quoting joe at smittys.pointclark.net:

> Quoting joe at smittys.pointclark.net:
>
>>>> To check this with superiotool I have to be able to dump the
>>>> "Runtime Registers", this is where the GPIO's are (See the SMSC
>>>> lpc47m192 datasheet for more info). Currently superiotool does not
>>>> dump these registers so modifications will be required.
>>>
>>> I was relying on the new extended superiotool dumping functionality.
>>> That doesn't exist yet for your superio, so I should have written
>>> "...can find out with superiotool (once that has GPIO dumping support
>>> for your superio) and...". Thanks for correcting me.
>>>
Well,
I wasn't able to get a dump of the "Runtime Registers" with  
superiotool working, but I was able to get a dump of it with the old  
dd method, there are alot of differences........maybe one of these  
GPIO settings is causing my flashrom issue??? It is hard to say  
without schmatics, but I could always try one register at a time until  
it works???

Thanks - Joe

rm4100
00 00 00 00 dc 00 14 0f e7 00 00 00 00 00 00 00
02 00 14 0f ce 00 00 00 00 00 00 00 00 00 03 02
81 00 00 01 01 01 01 01 01 01 01 01 01 01 00 01
01 01 01 05 05 00 00 00 04 01 01 01 01 86 01 05
05 05 04 05 04 05 04 01 01 00 00 00 04 d0 00 07
00 00 00 00 00 00 00 00 50 ff ff 00 00 00 00 00

coreboot
00 00 00 00 d8 00 14 0f 67 00 00 00 00 00 00 00
02 00 14 0f c6 00 00 00 00 00 00 00 00 00 03 02
81 00 00 01 01 01 01 01 01 01 01 01 01 01 00 02
01 01 01 01 01 00 00 05 04 01 01 01 01 01 01 01
01 01 00 01 01 01 01 01 01 00 00 00 04 d0 04 23
00 00 00 00 00 00 00 00 50 ff ff 00 00 00 00 00



From klaus123 at ibnoetzold.de  Tue Mar  4 14:42:19 2008
From: klaus123 at ibnoetzold.de (Klaus Stammermann)
Date: Tue, 4 Mar 2008 14:42:19 +0100
Subject: [coreboot] Problems with VIA EPIA-ME6000
In-Reply-To: <20080304115054.GA17625@greenwood>
References: <200803031520.56570.klaus123@ibnoetzold.de>
	<200803040831.23138.klaus123@ibnoetzold.de>
	<20080304115054.GA17625@greenwood>
Message-ID: <200803041442.19732.klaus123@ibnoetzold.de>

Am Dienstag, 4. M?rz 2008 12:50 schrieb Uwe Hermann:
> On Tue, Mar 04, 2008 at 08:31:23AM +0100, Klaus Stammermann wrote:
> > Am Montag, 3. M?rz 2008 21:33 schrieben Sie:
> > > * Klaus Stammermann <klaus123 at ibnoetzold.de> [080303 15:20]:
> > > > Hi there
> > > >
> > > > I have some trouble to use coreboot on my VIA EPIA-ME6000 so I hope
> > > > someone could give me some hints.
> > > >
> > > > With epia-m and filo I can build a bios without vga. This runs till
> > > > jumping to kernel. This breaks up with an error:
> > > > Loading kernel... ok
> > > > "Jumping to entry point...
> > > > 0
> > >
> > > Was the kernel built with serial console support? Was console=ttyS0,...
> > > specified as a command line option to the kernel?
> >
> > Yes, I use following startup parameters:
> > "hda1:/boot/vmlinuz root=/dev/hda1 console=tty0 console=ttyS0,115200"
>
> And you also use 'USE_GRUB = 0'? Otherwise FILO will try to read your
> menu.lst file from GRUB and ignore the above line.
>
> > I did not use that optionroms. But how can I use this optionrom? Where do
> > I have to put it in my image?
>
> I think at the beginning (but someone please correct me if I'm wrong), i.e.
>
> cat vga.rom coreboot.com > coreboot_full.rom
>
> But you need to tweak the config files too in order to make the
> coreboot.rom smaller (so there's place for vga.rom).
>

I get some problem at making coreboot.rom smaller. Normal and fallback get 
128kb before. I tried two different possibilities to get space for it, but 
both failed.

I need 57344b. But taking 57344/2 out of both raises error "XIP_ROM_BASE is 
not multiple of XIP_ROM_SIZE". And reducing one of them about 57344b make 
breaks because of overleaping sections.

Is there any overview how to use all these option in Config.lb? I think I 
don't understand the structur of all these options and their results.

Klaus



From klaus123 at ibnoetzold.de  Tue Mar  4 15:14:19 2008
From: klaus123 at ibnoetzold.de (Klaus Stammermann)
Date: Tue, 4 Mar 2008 15:14:19 +0100
Subject: [coreboot] make problem
Message-ID: <200803041514.19070.klaus123@ibnoetzold.de>

Hi there

On my EPIA-ME6000 I try to get some free space to insert VGA BIOS. But I get 
often this error message:
"XIP_ROM_BASE is not a multiple of XIP_ROM_SIZE".

Could anyone explain what this means? What do I have looking for to get some 
free space in my image?

An overview of all possible options and their description would be very nice. 
Is there something like that available?

Greetings
Klaus



From c-d.hailfinger.devel.2006 at gmx.net  Tue Mar  4 15:37:55 2008
From: c-d.hailfinger.devel.2006 at gmx.net (Carl-Daniel Hailfinger)
Date: Tue, 04 Mar 2008 15:37:55 +0100
Subject: [coreboot] flashrom issues??
In-Reply-To: <20080304083625.2za5fcgp2oso448k@www.smittys.pointclark.net>
References: <20080216134533.6awmn90xcsww80c4@www.smittys.pointclark.net>	<20080219112943.6w24vj5rc0okkc4s@www.smittys.pointclark.net>	<20080219163507.GA21962@coresystems.de>	<20080229123601.4dnjxissn40c4gw8@www.smittys.pointclark.net>	<20080229190715.GA10976@coresystems.de>
	<47C8593F.1030607@gmx.net>	<20080229192145.GA15773@coresystems.de>
	<47C89FC3.3000207@gmx.net>	<20080301080454.x1rgbpahwwks4k8c@www.smittys.pointclark.net>	<47C978F4.4030904@gmx.net>	<20080301123404.lsocj753k88k08k4@www.smittys.pointclark.net>	<20080302120343.ce1rrwrgo4ggw4gc@www.smittys.pointclark.net>
	<20080304083625.2za5fcgp2oso448k@www.smittys.pointclark.net>
Message-ID: <47CD5EC3.5000304@gmx.net>

On 04.03.2008 14:36, joe at smittys.pointclark.net wrote:
> Quoting joe at smittys.pointclark.net:
>
>   
>> Quoting joe at smittys.pointclark.net:
>>
>>     
>>>>> To check this with superiotool I have to be able to dump the
>>>>> "Runtime Registers", this is where the GPIO's are (See the SMSC
>>>>> lpc47m192 datasheet for more info). Currently superiotool does not
>>>>> dump these registers so modifications will be required.
>>>>>           
>>>> I was relying on the new extended superiotool dumping functionality.
>>>> That doesn't exist yet for your superio, so I should have written
>>>> "...can find out with superiotool (once that has GPIO dumping support
>>>> for your superio) and...". Thanks for correcting me.
>>>>
>>>>         
> Well,
> I wasn't able to get a dump of the "Runtime Registers" with  
> superiotool working, but I was able to get a dump of it with the old  
> dd method,

dd method? Can you please tell me the exact command for that? I think 
the extra register dumping for ITE is totally incompatible with the one 
for SMSC which would explain your problems.

> there are alot of differences........maybe one of these  
> GPIO settings is causing my flashrom issue??? It is hard to say  
> without schmatics, but I could always try one register at a time until  
> it works???
>   

Yes. Or set all of them to the factory BIOS values at once and try 
again. Sometimes dependencies between various registers make it 
dangerous to change only a part of the values.

> Thanks - Joe
>
> rm4100
> 00 00 00 00 dc 00 14 0f e7 00 00 00 00 00 00 00
> 02 00 14 0f ce 00 00 00 00 00 00 00 00 00 03 02
> 81 00 00 01 01 01 01 01 01 01 01 01 01 01 00 01
> 01 01 01 05 05 00 00 00 04 01 01 01 01 86 01 05
> 05 05 04 05 04 05 04 01 01 00 00 00 04 d0 00 07
> 00 00 00 00 00 00 00 00 50 ff ff 00 00 00 00 00
>
> coreboot
> 00 00 00 00 d8 00 14 0f 67 00 00 00 00 00 00 00
> 02 00 14 0f c6 00 00 00 00 00 00 00 00 00 03 02
> 81 00 00 01 01 01 01 01 01 01 01 01 01 01 00 02
> 01 01 01 01 01 00 00 05 04 01 01 01 01 01 01 01
> 01 01 00 01 01 01 01 01 01 00 00 00 04 d0 04 23
> 00 00 00 00 00 00 00 00 50 ff ff 00 00 00 00 00
>   

Nice output.

Regards,
Carl-Daniel


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




From rminnich at gmail.com  Tue Mar  4 15:49:44 2008
From: rminnich at gmail.com (ron minnich)
Date: Tue, 4 Mar 2008 06:49:44 -0800
Subject: [coreboot] Problems with VIA EPIA-ME6000
In-Reply-To: <20080303203322.GA7335@coresystems.de>
References: <200803031520.56570.klaus123@ibnoetzold.de>
	<20080303203322.GA7335@coresystems.de>
Message-ID: <13426df10803040649s7603f85k88fc299106152a4d@mail.gmail.com>

don't forget earlyprintk

console=ttyS0,115200 earlyprintk=ttyS0,115200[,keep]

ron



From rminnich at gmail.com  Tue Mar  4 15:54:47 2008
From: rminnich at gmail.com (ron minnich)
Date: Tue, 4 Mar 2008 06:54:47 -0800
Subject: [coreboot] VGA and Asus a8v-e_se
In-Reply-To: <47CA62D2.3040702@gmail.com>
References: <47CA62D2.3040702@gmail.com>
Message-ID: <13426df10803040654t507ed1fax6eba869150fc41cd@mail.gmail.com>

On Sun, Mar 2, 2008 at 12:18 AM, Jonathan Rogers
<jonathanrrogers at gmail.com> wrote:

>  I tried to follow the wiki page http://www.coreboot.org/VGA_support, so
>  I opened src/mainboard/asus/a8v-e_se/Options.lb. However, that file
>  contains the following lines instead of ones starting with "option" as
>  in the wiki:
>
>  #VGA
>  default CONFIG_CONSOLE_VGA=1
>  default CONFIG_PCI_ROM_RUN=1

yes, this wiki page is really wrong, I just realized.

We should not be telling people to mess with those files, unless they
are going to commit those changes
to the svn. People should only ever need to change files in the
targets/ directory. If they need to change some
other config files, then we have a bug or we need to make an improvement.

Can whoever wrote that page get in touch with me so we can try to fix it up?

thanks

ron



From rminnich at gmail.com  Tue Mar  4 16:00:43 2008
From: rminnich at gmail.com (ron minnich)
Date: Tue, 4 Mar 2008 07:00:43 -0800
Subject: [coreboot] PIC, APIC, XAPIC and XIOAPIC
In-Reply-To: <DD1CC71B621B004FA76856E5129D6B170136788C@sbjgexmb1.amd.com>
References: <DD1CC71B621B004FA76856E5129D6B170136788C@sbjgexmb1.amd.com>
Message-ID: <13426df10803040700k778faf01v9cc787c09bbad666@mail.gmail.com>

On Tue, Mar 4, 2008 at 2:08 AM, Feng, Libo <Libo.Feng at amd.com> wrote:

> In LB stage, only PIC mode is applied, isn't it? However, I remember some
> people of LB community told me there was no ISR except the debug ISR during
> LB. So does this mean it totally unnecessary to setup PIC via C00h/C001h IO
> port in LB?

PIC is set up in many mainboards so it is ready for the kernel. This
is because so many $PIR tables are wrong.

PIC is not needed for ISR, but coreboot only does ISR for the case of
running PCI (or VGA) ROMs anyway.

>
> APIC is setup only after OS runs and gets the interrupt routing from MPTable
> or ACPI table, is it correct? Then, what difference between APIC and XAPIC?
> Some documents say APIC has MMIO space registers at FEC00000h while XAPIC
> has PCI configuration space registers. But some documents seems to refer the
> same controller by APIC and XAPIC.

APIC is set up by kernel.

ron



From uwe at hermann-uwe.de  Tue Mar  4 16:23:23 2008
From: uwe at hermann-uwe.de (Uwe Hermann)
Date: Tue, 4 Mar 2008 16:23:23 +0100
Subject: [coreboot] Problems with VIA EPIA-ME6000
In-Reply-To: <200803041442.19732.klaus123@ibnoetzold.de>
References: <200803031520.56570.klaus123@ibnoetzold.de>
	<200803040831.23138.klaus123@ibnoetzold.de>
	<20080304115054.GA17625@greenwood>
	<200803041442.19732.klaus123@ibnoetzold.de>
Message-ID: <20080304152323.GA1533@greenwood>

On Tue, Mar 04, 2008 at 02:42:19PM +0100, Klaus Stammermann wrote:
> > I think at the beginning (but someone please correct me if I'm wrong), i.e.
> >
> > cat vga.rom coreboot.com > coreboot_full.rom
> >
> > But you need to tweak the config files too in order to make the
> > coreboot.rom smaller (so there's place for vga.rom).
> >
> 
> I get some problem at making coreboot.rom smaller. Normal and fallback get 
> 128kb before. I tried two different possibilities to get space for it, but 
> both failed.

This stuff is highly confusing in coreboot, sorry. Please post your
current patch against svn (all changes you made to any files).

Also, where did you get your VGA ROM from? Using which tools (awardeco,
amideco, phnxdeco, other)? How big is it exactly?

I hope we can post a patch for you which should build a working
coreboot.rom where you can prepend the VGA BIOS with enough information.


> I need 57344b. But taking 57344/2 out of both raises error "XIP_ROM_BASE is 
> not multiple of XIP_ROM_SIZE". And reducing one of them about 57344b make 

Don't mess with XIP_ROM_SIZE, that's not what you want.


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



From uwe at hermann-uwe.de  Tue Mar  4 16:27:21 2008
From: uwe at hermann-uwe.de (Uwe Hermann)
Date: Tue, 4 Mar 2008 16:27:21 +0100
Subject: [coreboot] make problem
In-Reply-To: <200803041514.19070.klaus123@ibnoetzold.de>
References: <200803041514.19070.klaus123@ibnoetzold.de>
Message-ID: <20080304152721.GB1533@greenwood>

On Tue, Mar 04, 2008 at 03:14:19PM +0100, Klaus Stammermann wrote:
> Hi there
> 
> On my EPIA-ME6000 I try to get some free space to insert VGA BIOS. But I get 
> often this error message:
> "XIP_ROM_BASE is not a multiple of XIP_ROM_SIZE".
> 
> Could anyone explain what this means? What do I have looking for to get some 
> free space in my image?
> 
> An overview of all possible options and their description would be very nice. 
> Is there something like that available?

http://www.coreboot.org/Coreboot_Options

documentation/LinuxBIOS-AMD64.tex has some more info, too. But all this
stuff is really confusing and non-trivial, see my other mail. Please
post the requested info, maybe we can provide you with a patch.


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



From rminnich at gmail.com  Tue Mar  4 16:34:51 2008
From: rminnich at gmail.com (ron minnich)
Date: Tue, 4 Mar 2008 07:34:51 -0800
Subject: [coreboot] Problems with VIA EPIA-ME6000
In-Reply-To: <20080304152323.GA1533@greenwood>
References: <200803031520.56570.klaus123@ibnoetzold.de>
	<200803040831.23138.klaus123@ibnoetzold.de>
	<20080304115054.GA17625@greenwood>
	<200803041442.19732.klaus123@ibnoetzold.de>
	<20080304152323.GA1533@greenwood>
Message-ID: <13426df10803040734r20956064t4be62081bcdf3166@mail.gmail.com>

On Tue, Mar 4, 2008 at 7:23 AM, Uwe Hermann <uwe at hermann-uwe.de> wrote:

>  Don't mess with XIP_ROM_SIZE, that's not what you want.

yes.

Marc has I believe posted a nice map of the various ROM control
parameters and how they work.

I'm sorry it is so messy, we only learned a good way to do this in v3 :-(

Also, don't forget, for changing ROM sizes you should only ever adjust
config files in the target directory.

ron



From uwe at hermann-uwe.de  Tue Mar  4 16:49:24 2008
From: uwe at hermann-uwe.de (Uwe Hermann)
Date: Tue, 4 Mar 2008 16:49:24 +0100
Subject: [coreboot] [PATCH] flashrom: Drop rom.layout
Message-ID: <20080304154924.GA3598@greenwood>

See patch.


Uwe.
-- 
http://www.hermann-uwe.de  | http://www.holsham-traders.de
http://www.crazy-hacks.org | http://www.unmaintained-free-software.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: flashrom_drop_rom_layout.patch
Type: text/x-diff
Size: 456 bytes
Desc: not available
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20080304/581136c6/attachment.bin>

From uwe at hermann-uwe.de  Tue Mar  4 16:54:11 2008
From: uwe at hermann-uwe.de (Uwe Hermann)
Date: Tue, 4 Mar 2008 16:54:11 +0100
Subject: [coreboot] [PATCH] flashrom: Add missing license to layout.c
Message-ID: <20080304155411.GB3598@greenwood>

See patch.


Uwe.
-- 
http://www.hermann-uwe.de  | http://www.holsham-traders.de
http://www.crazy-hacks.org | http://www.unmaintained-free-software.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: flashrom_layout_license.patch
Type: text/x-diff
Size: 1085 bytes
Desc: not available
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20080304/0f22a74e/attachment.bin>

From stepan at coresystems.de  Tue Mar  4 17:04:27 2008
From: stepan at coresystems.de (Stefan Reinauer)
Date: Tue, 4 Mar 2008 17:04:27 +0100
Subject: [coreboot] [PATCH] flashrom: Add missing license to layout.c
In-Reply-To: <20080304155411.GB3598@greenwood>
References: <20080304155411.GB3598@greenwood>
Message-ID: <20080304160427.GA4513@coresystems.de>

Acked-by: Stefan Reinauer <stepan at coresystems.de>

* Uwe Hermann <uwe at hermann-uwe.de> [080304 16:54]:
> 
> Uwe.
> -- 
> http://www.hermann-uwe.de  | http://www.holsham-traders.de
> http://www.crazy-hacks.org | http://www.unmaintained-free-software.org

> Index: layout.c
> ===================================================================
> --- layout.c	(Revision 3125)
> +++ layout.c	(Arbeitskopie)
> @@ -1,3 +1,23 @@
> +/*
> + * This file is part of the flashrom project.
> + *
> + * Copyright (C) 2005-2008 coresystems GmbH
> + * (Written by Stefan Reinauer <stepan at coresystems.de> for coresystems GmbH)
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License as published by
> + * the Free Software Foundation; version 2 of the License.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> + * GNU General Public License for more details.
> + *
> + * You should have received a copy of the GNU General Public License
> + * along with this program; if not, write to the Free Software
> + * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA  02110-1301 USA
> + */
> +
>  #include <stdio.h>
>  #include <stdlib.h>
>  #include <string.h>

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

-- 
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 mylesgw at gmail.com  Tue Mar  4 17:08:08 2008
From: mylesgw at gmail.com (Myles Watson)
Date: Tue, 4 Mar 2008 09:08:08 -0700
Subject: [coreboot] make problem
In-Reply-To: <200803041514.19070.klaus123@ibnoetzold.de>
References: <200803041514.19070.klaus123@ibnoetzold.de>
Message-ID: <00c301c87e11$f0b22650$b522040a@chimp>



> -----Original Message-----
> From: coreboot-bounces at coreboot.org [mailto:coreboot-bounces at coreboot.org]
> On Behalf Of Klaus Stammermann
> Sent: Tuesday, March 04, 2008 7:14 AM
> To: coreboot at coreboot.org
> Subject: [coreboot] make problem
> 
> Hi there
> 
> On my EPIA-ME6000 I try to get some free space to insert VGA BIOS. But I
> get
> often this error message:
> "XIP_ROM_BASE is not a multiple of XIP_ROM_SIZE".
> 
> Could anyone explain what this means? What do I have looking for to get
> some
> free space in my image?
> 
> An overview of all possible options and their description would be very
> nice.
> Is there something like that available?

This is helpful for me.  Marc Jones put it together.

http://www.coreboot.org/Anatomy_of_a_Failover_coreboot_v2_Image

Myles

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




From klaus123 at ibnoetzold.de  Tue Mar  4 17:10:40 2008
From: klaus123 at ibnoetzold.de (Klaus Stammermann)
Date: Tue, 4 Mar 2008 17:10:40 +0100
Subject: [coreboot] Problems with VIA EPIA-ME6000
In-Reply-To: <20080304152323.GA1533@greenwood>
References: <200803031520.56570.klaus123@ibnoetzold.de>
	<200803041442.19732.klaus123@ibnoetzold.de>
	<20080304152323.GA1533@greenwood>
Message-ID: <200803041710.41023.klaus123@ibnoetzold.de>

Am Dienstag, 4. M?rz 2008 16:23 schrieben Sie:
> On Tue, Mar 04, 2008 at 02:42:19PM +0100, Klaus Stammermann wrote:
> > > I think at the beginning (but someone please correct me if I'm wrong),
> > > i.e.
> > >
> > > cat vga.rom coreboot.com > coreboot_full.rom
> > >
> > > But you need to tweak the config files too in order to make the
> > > coreboot.rom smaller (so there's place for vga.rom).
> >
> > I get some problem at making coreboot.rom smaller. Normal and fallback
> > get 128kb before. I tried two different possibilities to get space for
> > it, but both failed.
>
> This stuff is highly confusing in coreboot, sorry. Please post your
> current patch against svn (all changes you made to any files).
>
Here the diff:
-----------------------------------------------------------------------------------------------------------------------------------
Index: src/mainboard/via/epia-m/Options.lb
===================================================================
--- src/mainboard/via/epia-m/Options.lb	(Revision 3086)
+++ src/mainboard/via/epia-m/Options.lb	(Arbeitskopie)
@@ -51,8 +51,8 @@
 ###
 ### Build options
 ###
-default CONFIG_PCI_ROM_RUN=0
-default CONFIG_CONSOLE_VGA=0
+default CONFIG_PCI_ROM_RUN=1
+default CONFIG_CONSOLE_VGA=1
 
 ##
 ## Build code for the fallback boot
Index: targets/via/epia-m/Config.lb
===================================================================
--- targets/via/epia-m/Config.lb	(Revision 3086)
+++ targets/via/epia-m/Config.lb	(Arbeitskopie)
@@ -7,21 +7,21 @@
 option  DEFAULT_CONSOLE_LOGLEVEL=8
 option  CONFIG_CONSOLE_SERIAL8250=1
 
-option ROM_SIZE=256*1024
+option ROM_SIZE=(256*1024)-(64*1024)
 
 
 option HAVE_OPTION_TABLE=1
 option CONFIG_ROM_PAYLOAD=1
 option HAVE_FALLBACK_BOOT=1
 #option CONFIG_COMPRESSED_PAYLOAD_NRV2B=1
-option CONFIG_COMPRESSED_PAYLOAD_NRV2B=0
+#option CONFIG_COMPRESSED_PAYLOAD_NRV2B=0
 
 
 ###
 ### Compute the location and size of where this firmware image
 ### (coreboot plus bootloader) will live in the boot rom chip.
 ###
-option FALLBACK_SIZE=131072
+option FALLBACK_SIZE=(96*1024)
 
 ## Coreboot C code runs at this location in RAM
 option _RAMBASE=0x00004000
@@ -31,18 +31,22 @@
 #
 romimage "normal"
 	option USE_FALLBACK_IMAGE=0
-#option ROM_IMAGE_SIZE=128*1024
-	option ROM_IMAGE_SIZE=64*1024
+#	option ROM_IMAGE_SIZE=(128*1024)-27312
+	option ROM_IMAGE_SIZE=(96*1024)-27312
+#	option ROM_IMAGE_SIZE=0xc000
+#	option ROM_SECTION_OFFSET=0x10000
+#	option ROM_SECTION_SIZE=0x18000
 	option COREBOOT_EXTRA_VERSION=".0-Normal"
-	payload $(HOME)/svn/payload.elf
+	payload $(HOME)/Entwicklung/LinuxBIOS/VIA-BIOS/filo.small.elf
 end
 
 romimage "fallback" 
 	option USE_FALLBACK_IMAGE=1
-	#option ROM_IMAGE_SIZE=128*1024
-	option ROM_IMAGE_SIZE=60*1024
+#	option ROM_IMAGE_SIZE=(128*1024)-27312
+	option ROM_IMAGE_SIZE=(96*1024)-27312
+#	option ROM_IMAGE_SIZE=0xc000
 	option COREBOOT_EXTRA_VERSION=".0-Fallback"
-	payload $(HOME)/svn/payload.elf
+	payload $(HOME)/Entwicklung/LinuxBIOS/VIA-BIOS/filo.small.elf
 end
 
 buildrom ./coreboot.rom ROM_SIZE "normal" "fallback"
-----------------------------------------------------------------------------------------------------------------------------------
In an earlier version I changed Config.lb in src dir to get VGA BIOS. But now 
it isn't included. If it is important, I could post it later.

> Also, where did you get your VGA ROM from? Using which tools (awardeco,
> amideco, phnxdeco, other)? How big is it exactly?
>
On http://www.coreboot.org/VGA_support at bottom there is a perl script. Using 
this I got my VGABIOS. This is 60416 bytes big (optionsrom is 57344 bytes 
which I used at last).

filo.small.elf is 27312 bytes big. So don't wonder what number this is.

> I hope we can post a patch for you which should build a working
> coreboot.rom where you can prepend the VGA BIOS with enough information.
>
That would be very nice and I hope we could solve this problems. 
Sorry but till next monday I can't get more information from my development 
system. I will look at this mailinglist and maybe some easy information I 
could give out of my mind.

> > I need 57344b. But taking 57344/2 out of both raises error "XIP_ROM_BASE
> > is not multiple of XIP_ROM_SIZE". And reducing one of them about 57344b
> > make
>
> Don't mess with XIP_ROM_SIZE, that's not what you want.
OK, that sounds very good :-)

Thank you for your help. 

Klaus



From uwe at hermann-uwe.de  Tue Mar  4 17:28:12 2008
From: uwe at hermann-uwe.de (Uwe Hermann)
Date: Tue, 4 Mar 2008 17:28:12 +0100
Subject: [coreboot] Problems with VIA EPIA-ME6000
In-Reply-To: <200803041710.41023.klaus123@ibnoetzold.de>
References: <200803031520.56570.klaus123@ibnoetzold.de>
	<200803041442.19732.klaus123@ibnoetzold.de>
	<20080304152323.GA1533@greenwood>
	<200803041710.41023.klaus123@ibnoetzold.de>
Message-ID: <20080304162812.GB5787@greenwood>

On Tue, Mar 04, 2008 at 05:10:40PM +0100, Klaus Stammermann wrote:
> Here the diff:
> -----------------------------------------------------------------------------------------------------------------------------------
> Index: src/mainboard/via/epia-m/Options.lb
> ===================================================================
> --- src/mainboard/via/epia-m/Options.lb	(Revision 3086)
> +++ src/mainboard/via/epia-m/Options.lb	(Arbeitskopie)
> @@ -51,8 +51,8 @@
>  ###
>  ### Build options
>  ###
> -default CONFIG_PCI_ROM_RUN=0
> -default CONFIG_CONSOLE_VGA=0
> +default CONFIG_PCI_ROM_RUN=1
> +default CONFIG_CONSOLE_VGA=1

Looks ok.

  
>  ##
>  ## Build code for the fallback boot
> Index: targets/via/epia-m/Config.lb
> ===================================================================
> --- targets/via/epia-m/Config.lb	(Revision 3086)
> +++ targets/via/epia-m/Config.lb	(Arbeitskopie)
> @@ -7,21 +7,21 @@
>  option  DEFAULT_CONSOLE_LOGLEVEL=8
>  option  CONFIG_CONSOLE_SERIAL8250=1
>  
> -option ROM_SIZE=256*1024
> +option ROM_SIZE=(256*1024)-(64*1024)

OK, assuming you have a 256KB ROM chip and your VGA BIOS is 64KB.

  
>  option HAVE_OPTION_TABLE=1
>  option CONFIG_ROM_PAYLOAD=1
>  option HAVE_FALLBACK_BOOT=1
>  #option CONFIG_COMPRESSED_PAYLOAD_NRV2B=1
> -option CONFIG_COMPRESSED_PAYLOAD_NRV2B=0
> +#option CONFIG_COMPRESSED_PAYLOAD_NRV2B=0

Why?


>  ### Compute the location and size of where this firmware image
>  ### (coreboot plus bootloader) will live in the boot rom chip.
>  ###
> -option FALLBACK_SIZE=131072
> +option FALLBACK_SIZE=(96*1024)

Not sure about this. I'd rather not change it unless really necessary
(it isn't in this case, I think).


>  ## Coreboot C code runs at this location in RAM
>  option _RAMBASE=0x00004000
> @@ -31,18 +31,22 @@
>  #
>  romimage "normal"
>  	option USE_FALLBACK_IMAGE=0
> -#option ROM_IMAGE_SIZE=128*1024
> -	option ROM_IMAGE_SIZE=64*1024
> +#	option ROM_IMAGE_SIZE=(128*1024)-27312
> +	option ROM_IMAGE_SIZE=(96*1024)-27312

This is wrong.

ROM_IMAGE_SIZE is the maximum size the coreboot code can use (without
payload, without VGA ROM, etc).

Something like 64*1024 is usually ok.


> +#	option ROM_IMAGE_SIZE=0xc000
> +#	option ROM_SECTION_OFFSET=0x10000
> +#	option ROM_SECTION_SIZE=0x18000
>  	option COREBOOT_EXTRA_VERSION=".0-Normal"
> -	payload $(HOME)/svn/payload.elf
> +	payload $(HOME)/Entwicklung/LinuxBIOS/VIA-BIOS/filo.small.elf

Never used $(HOME) here, but I assume it works? If not, try
/tmp/filo.elf and copy your payload there.


>  end
>  
>  romimage "fallback" 
>  	option USE_FALLBACK_IMAGE=1
> -	#option ROM_IMAGE_SIZE=128*1024
> -	option ROM_IMAGE_SIZE=60*1024
> +#	option ROM_IMAGE_SIZE=(128*1024)-27312
> +	option ROM_IMAGE_SIZE=(96*1024)-27312

Also wrong, see above.


> +#	option ROM_IMAGE_SIZE=0xc000
>  	option COREBOOT_EXTRA_VERSION=".0-Fallback"
> -	payload $(HOME)/svn/payload.elf
> +	payload $(HOME)/Entwicklung/LinuxBIOS/VIA-BIOS/filo.small.elf
>  end
>  
>  buildrom ./coreboot.rom ROM_SIZE "normal" "fallback"
> -----------------------------------------------------------------------------------------------------------------------------------


> In an earlier version I changed Config.lb in src dir to get VGA BIOS. But now 
> it isn't included. If it is important, I could post it later.

Plese post it.

But the above patch comes from an 'svn diff' at the top-level directory,
correct? I.e. all your current changes are in there?


> > Also, where did you get your VGA ROM from? Using which tools (awardeco,
> > amideco, phnxdeco, other)? How big is it exactly?
> >
> On http://www.coreboot.org/VGA_support at bottom there is a perl script. Using 
> this I got my VGABIOS. This is 60416 bytes big 

OK. Which vendor BIOS does the board have? Can you use
awardeco/amideco/phnxdeco to get the VGA BIOS and compare it with the
one from the script? Just to be sure that worked fine...


> (optionsrom is 57344 bytes which I used at last).

Huh, what's that? Where from?


> filo.small.elf is 27312 bytes big. So don't wonder what number this is.

Are you sure this is ok? The smallest usable FILO I've used so far is
ca. 57 KB. Your 27 KB FILO looks _very_ small.

Also, please use the latest version from

 % svn co svn://coreboot.org/filo/trunk/filo-0.5

Type 'make' (that will generate a Config file), then edit Config, then
type make again.


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



From svn at coreboot.org  Tue Mar  4 17:29:54 2008
From: svn at coreboot.org (svn at coreboot.org)
Date: Tue,  4 Mar 2008 17:29:54 +0100
Subject: [coreboot] r3126 - trunk/util/flashrom
Message-ID: <mailman.1247.1355071274.16123.coreboot@coreboot.org>

Author: uwe
Date: 2008-03-04 17:29:54 +0100 (Tue, 04 Mar 2008)
New Revision: 3126

Modified:
   trunk/util/flashrom/layout.c
Log:
Add missing license header to layout.c. The file was written by
Stefan Reinauer for coresystems GmbH in 2005, as confirmed on IRC.

Signed-off-by: Uwe Hermann <uwe at hermann-uwe.de>
Acked-by: Stefan Reinauer <stepan at coresystems.de>



Modified: trunk/util/flashrom/layout.c
===================================================================
--- trunk/util/flashrom/layout.c	2008-03-01 19:13:50 UTC (rev 3125)
+++ trunk/util/flashrom/layout.c	2008-03-04 16:29:54 UTC (rev 3126)
@@ -1,3 +1,23 @@
+/*
+ * This file is part of the flashrom project.
+ *
+ * Copyright (C) 2005-2008 coresystems GmbH
+ * (Written by Stefan Reinauer <stepan at coresystems.de> for coresystems GmbH)
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; version 2 of the License.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA  02110-1301 USA
+ */
+
 #include <stdio.h>
 #include <stdlib.h>
 #include <string.h>




From uwe at hermann-uwe.de  Tue Mar  4 17:31:08 2008
From: uwe at hermann-uwe.de (Uwe Hermann)
Date: Tue, 4 Mar 2008 17:31:08 +0100
Subject: [coreboot] [PATCH] flashrom: Add missing license to layout.c
In-Reply-To: <20080304160427.GA4513@coresystems.de>
References: <20080304155411.GB3598@greenwood>
	<20080304160427.GA4513@coresystems.de>
Message-ID: <20080304163108.GC5787@greenwood>

Oops, attached old file without description and Signed-off-by, sorry.

Here it is:
Signed-off-by: Uwe Hermann <uwe at hermann-uwe.de>


On Tue, Mar 04, 2008 at 05:04:27PM +0100, Stefan Reinauer wrote:
> Acked-by: Stefan Reinauer <stepan at coresystems.de>

Thanks, r3126.


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



From marc.jones at amd.com  Tue Mar  4 17:43:15 2008
From: marc.jones at amd.com (Marc Jones)
Date: Tue, 04 Mar 2008 09:43:15 -0700
Subject: [coreboot] patch: dbe62
In-Reply-To: <47CCAD59.8080801@gmx.net>
References: <13426df10802281441v109c6edai8e448131a0539c93@mail.gmail.com>	<20080229010002.9912.qmail@stuge.se>	<13426df10802281853q27757ab3mac567ab8c574412@mail.gmail.com>	<20080229134132.2184.qmail@stuge.se>	<13426df10802290852h109ab986o89a83f689a14148b@mail.gmail.com>	<47C8B860.5030700@gmx.net>	<13426df10802291803y2b042304pfa78ce2e2900dfa1@mail.gmail.com>	<47C9734E.1010807@gmx.net>	<20080301152721.25943.qmail@stuge.se>	<13426df10803010908s6a866eb0jcdaf90135d6579b6@mail.gmail.com>	<13426df10803011334o20ec721lfde0b3d18aee9c20@mail.gmail.com>	<47C9D3F5.9010506@gmx.net>	<47CC685D.60809@amd.com>	<47CC7448.10306@gmx.net>
	<47CC7904.4040208@amd.com> <47CCAD59.8080801@gmx.net>
Message-ID: <47CD7C23.7050106@amd.com>

Carl-Daniel,

That was my plan but some family10 stuff has come up. I think it would 
be great if you want to do that port. Looking farther in the mail-list, 
I see that you have a patch. I will test it this morning.


Marc

Carl-Daniel Hailfinger wrote:
> Marc,
> 
> thanks for verifying. Norwich v3 status in the wiki has been changed to 
> "OK".
> 
> Are you working on a db800 port for v3? If not, I'd like to give it a 
> first try.
> 
> Regards,
> Carl-Daniel
> 

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




From svn at coreboot.org  Tue Mar  4 18:21:04 2008
From: svn at coreboot.org (svn at coreboot.org)
Date: Tue,  4 Mar 2008 18:21:04 +0100
Subject: [coreboot] r3127 - trunk/util/superiotool
Message-ID: <mailman.1248.1355071274.16123.coreboot@coreboot.org>

Author: uwe
Date: 2008-03-04 18:21:04 +0100 (Tue, 04 Mar 2008)
New Revision: 3127

Modified:
   trunk/util/superiotool/README
Log:
Drop some duplicate documentation from the README. The manpage and
'superiotool --help' already provide the same information (trivial).

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



Modified: trunk/util/superiotool/README
===================================================================
--- trunk/util/superiotool/README	2008-03-04 16:29:54 UTC (rev 3126)
+++ trunk/util/superiotool/README	2008-03-04 17:21:04 UTC (rev 3127)
@@ -30,15 +30,8 @@
 Usage
 -----
 
- $ superiotool [-d] [-e] [-l] [-V] [-v] [-h]
+Please read the superiotool(1) manpage or type 'superiotool --help'.
 
- -d | --dump            Dump Super I/O register contents
- -e | --extra-dump      Dump secondary registers too (e.g. EC registers)
- -l | --list-supported  Show the list of supported Super I/O chips
- -V | --verbose         Verbose mode
- -v | --version         Show the superiotool version
- -h | --help            Show a short help text
-
 Per default (no options) superiotool will just probe for a Super I/O
 and print its vendor, name, ID, revision, and config port.
 




From uwe at hermann-uwe.de  Tue Mar  4 18:39:28 2008
From: uwe at hermann-uwe.de (Uwe Hermann)
Date: Tue, 4 Mar 2008 18:39:28 +0100
Subject: [coreboot] [PATCH] superiotool: Various fixes
Message-ID: <20080304173928.GA11615@greenwood>

See patch.


Uwe.
-- 
http://www.hermann-uwe.de  | http://www.holsham-traders.de
http://www.crazy-hacks.org | http://www.unmaintained-free-software.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: superiotool_fixes.patch
Type: text/x-diff
Size: 3099 bytes
Desc: not available
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20080304/71aa7b21/attachment.bin>

From marc.jones at amd.com  Tue Mar  4 18:46:35 2008
From: marc.jones at amd.com (Marc Jones)
Date: Tue, 04 Mar 2008 10:46:35 -0700
Subject: [coreboot] [PATCH] v3: AMD DB800 support
In-Reply-To: <47CCBEF1.4040208@gmx.net>
References: <47CCBEF1.4040208@gmx.net>
Message-ID: <47CD8AFB.5020603@amd.com>



Carl-Daniel Hailfinger wrote:
> This is another milestone in my quest to obsolete v2.
> 
> [Patch looks strange due to a svn bug. Please let me commit, my tree 
> will give us proper svn blame history and actually commit correctly.]
> 
As you noted, reading the patch is weird. I don't understand, are you 
trying to keep file history from the original files or something? I 
would still expect the diff to have all new files. There is a second 
patch of the file that doesn't make sense. For example: 
LinuxBIOSv3-db800/mainboard/amd/db800/irq_tables.h.

I couldn't get it to apply cleanly. Maybe my mail reader munged it. Can 
you check it applies and resend?

Also, there are some other cleanups that should probably be in a 
seperate patch.
LinuxBIOSv3-db800/mainboard/amd/norwich/irq_tables.h
LinuxBIOSv3-db800/mainboard/pcengines/alix1c/irq_tables.h

Marc


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




From joe at smittys.pointclark.net  Tue Mar  4 19:00:55 2008
From: joe at smittys.pointclark.net (joe at smittys.pointclark.net)
Date: Tue, 04 Mar 2008 13:00:55 -0500
Subject: [coreboot] flashrom issues??
In-Reply-To: <47CD5EC3.5000304@gmx.net>
References: <20080216134533.6awmn90xcsww80c4@www.smittys.pointclark.net>
	<20080219112943.6w24vj5rc0okkc4s@www.smittys.pointclark.net>
	<20080219163507.GA21962@coresystems.de>
	<20080229123601.4dnjxissn40c4gw8@www.smittys.pointclark.net>
	<20080229190715.GA10976@coresystems.de> <47C8593F.1030607@gmx.net>
	<20080229192145.GA15773@coresystems.de> <47C89FC3.3000207@gmx.net>
	<20080301080454.x1rgbpahwwks4k8c@www.smittys.pointclark.net>
	<47C978F4.4030904@gmx.net>
	<20080301123404.lsocj753k88k08k4@www.smittys.pointclark.net>
	<20080302120343.ce1rrwrgo4ggw4gc@www.smittys.pointclark.net>
	<20080304083625.2za5fcgp2oso448k@www.smittys.pointclark.net>
	<47CD5EC3.5000304@gmx.net>
Message-ID: <20080304130055.pyz552okgk8wco8w@www.smittys.pointclark.net>

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

> On 04.03.2008 14:36, joe at smittys.pointclark.net wrote:
>> Quoting joe at smittys.pointclark.net:
>>
>>
>>> Quoting joe at smittys.pointclark.net:
>>>
>>>
>>>>>> To check this with superiotool I have to be able to dump the
>>>>>> "Runtime Registers", this is where the GPIO's are (See the SMSC
>>>>>> lpc47m192 datasheet for more info). Currently superiotool does not
>>>>>> dump these registers so modifications will be required.
>>>>>>
>>>>> I was relying on the new extended superiotool dumping functionality.
>>>>> That doesn't exist yet for your superio, so I should have written
>>>>> "...can find out with superiotool (once that has GPIO dumping support
>>>>> for your superio) and...". Thanks for correcting me.
>>>>>
>>>>>
>> Well,
>> I wasn't able to get a dump of the "Runtime Registers" with    
>> superiotool working, but I was able to get a dump of it with the   
>> old  dd method,
>
> dd method? Can you please tell me the exact command for that? I think
> the extra register dumping for ITE is totally incompatible with the one
> for SMSC which would explain your problems.
>
rm4100
[root at localhost proc]# dd if=/dev/port bs=1 skip=$[0x0800] count=128 | xxd
256+0 records in
256+0 records out
256 bytes (256 B) copied, 0.00171602 s, 149 kB/s
0000000: 0000 0000 dc00 140f e700 0000 0000 0000  ................
0000010: 0200 140f ce00 0000 0000 0000 0000 0302  ................
0000020: 8100 0001 0101 0101 0101 0101 0101 0001  ................
0000030: 0101 0105 0500 0000 0401 0101 0186 0105  ................
0000040: 0505 0405 0405 0401 0100 0000 04d0 0007  ................
0000050: 0000 0000 0000 0000 50ff ff00 0000 0000  ........P.......
0000060: 0000 0000 0000 0000 0000 0000 0000 0000  ................
0000070: 0000 0000 0000 0000 0000 0000 0000 0000  ................

coreboot
[root at localhost ~]# dd if=/dev/port bs=1 skip=$[0x0a00] count=128 | xxd
256+0 records in
256+0 records out
256 bytes (256 B) copied, 0.00217287 s, 118 kB/s
0000000: 0000 0000 d800 140f 6700 0000 0000 0000  ........g.......
0000010: 0200 140f c600 0000 0000 0000 0000 0302  ................
0000020: 8100 0001 0101 0101 0101 0101 0101 0002  ................
0000030: 0101 0101 0100 0005 0401 0101 0101 0101  ................
0000040: 0101 0001 0101 0101 0100 0000 04d0 0423  ...............#
0000050: 0000 0000 0000 0000 50ff ff00 0000 0000  ........P.......
0000060: 0000 0000 0000 0000 0000 0000 0000 0000  ................
0000070: 0000 0000 0000 0000 0000 0000 0000 0000  ................
>
>> there are alot of differences........maybe one of these  GPIO   
>> settings is causing my flashrom issue??? It is hard to say  without  
>>  schmatics, but I could always try one register at a time until  it  
>>  works???
>>
>
> Yes. Or set all of them to the factory BIOS values at once and try
> again. Sometimes dependencies between various registers make it
> dangerous to change only a part of the values.
>
Which is a little weird, because in coreboot all the values aren't at  
their defaults, maybe hardwired?
>
>>
>> rm4100
>> 00 00 00 00 dc 00 14 0f e7 00 00 00 00 00 00 00
>> 02 00 14 0f ce 00 00 00 00 00 00 00 00 00 03 02
>> 81 00 00 01 01 01 01 01 01 01 01 01 01 01 00 01
>> 01 01 01 05 05 00 00 00 04 01 01 01 01 86 01 05
>> 05 05 04 05 04 05 04 01 01 00 00 00 04 d0 00 07
>> 00 00 00 00 00 00 00 00 50 ff ff 00 00 00 00 00
>>
>> coreboot
>> 00 00 00 00 d8 00 14 0f 67 00 00 00 00 00 00 00
>> 02 00 14 0f c6 00 00 00 00 00 00 00 00 00 03 02
>> 81 00 00 01 01 01 01 01 01 01 01 01 01 01 00 02
>> 01 01 01 01 01 00 00 05 04 01 01 01 01 01 01 01
>> 01 01 00 01 01 01 01 01 01 00 00 00 04 d0 04 23
>> 00 00 00 00 00 00 00 00 50 ff ff 00 00 00 00 00
>>
>
> Nice output.
>
The output is not that nice I had to doctor it up a little bit.

Thanks - Joe



From tsylla at gmail.com  Tue Mar  4 19:56:45 2008
From: tsylla at gmail.com (Tom Sylla)
Date: Tue, 4 Mar 2008 13:56:45 -0500
Subject: [coreboot] flashrom issues??
In-Reply-To: <20080304130055.pyz552okgk8wco8w@www.smittys.pointclark.net>
References: <20080216134533.6awmn90xcsww80c4@www.smittys.pointclark.net>
	<20080229192145.GA15773@coresystems.de> <47C89FC3.3000207@gmx.net>
	<20080301080454.x1rgbpahwwks4k8c@www.smittys.pointclark.net>
	<47C978F4.4030904@gmx.net>
	<20080301123404.lsocj753k88k08k4@www.smittys.pointclark.net>
	<20080302120343.ce1rrwrgo4ggw4gc@www.smittys.pointclark.net>
	<20080304083625.2za5fcgp2oso448k@www.smittys.pointclark.net>
	<47CD5EC3.5000304@gmx.net>
	<20080304130055.pyz552okgk8wco8w@www.smittys.pointclark.net>
Message-ID: <57947bf80803041056j53fef6dyaab3cc5589854d92@mail.gmail.com>

On Tue, Mar 4, 2008 at 1:00 PM,  <joe at smittys.pointclark.net> wrote:
>  rm4100
>  [root at localhost proc]# dd if=/dev/port bs=1 skip=$[0x0800] count=128 | xxd
>  256+0 records in
>  256+0 records out
>  256 bytes (256 B) copied, 0.00171602 s, 149 kB/s
>  0000000: 0000 0000 dc00 140f e700 0000 0000 0000  ................
<SNIP>
>  >> rm4100
>  >> 00 00 00 00 dc 00 14 0f e7 00 00 00 00 00 00 00
<SNIP>
>  The output is not that nice I had to doctor it up a little bit.


I use hexdump instead, no doctoring required:

[xxx at xxx xxx]# dd if=/dev/port bs=1 skip=$[0x0800] count=128 | hexdump -C
00000000  00 00 00 00 18 00 00 c0  00 00 00 00 00 00 00 00  |................|
00000010  02 00 80 80 00 00 00 80  00 00 20 00 00 00 02 00  |.......... .....|
00000020  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
00000030  00 04 00 01 00 00 06 00  00 84 84 84 84 84 01 00  |................|
00000040  01 84 05 05 05 04 05 04  05 04 00 91 40 01 28 57  |............ at .(W|
00000050  47 60 00 00 00 00 00 9f  5c 6c 00 06 00 00 a4 00  |G`......\l......|
00000060  01 00 61 01 60 00 00 00  60 7f 04 00 00 00 00 00  |..a.`...`.......|
00000070  0e 01 00 04 00 01 18 00  00 00 00 00 20 52 6c 6b  |............ Rlk|
00000080

You can get quite fancy with hexdump's '-e' option, displaying in
dwords, tab formatting, etc.
The '-C' option gets the output formatted easily.



From c-d.hailfinger.devel.2006 at gmx.net  Tue Mar  4 21:01:03 2008
From: c-d.hailfinger.devel.2006 at gmx.net (Carl-Daniel Hailfinger)
Date: Tue, 04 Mar 2008 21:01:03 +0100
Subject: [coreboot] [PATCH] v3: AMD DB800 support
In-Reply-To: <47CD8AFB.5020603@amd.com>
References: <47CCBEF1.4040208@gmx.net> <47CD8AFB.5020603@amd.com>
Message-ID: <47CDAA7F.8010804@gmx.net>

On 04.03.2008 18:46, Marc Jones wrote:
>
>
> Carl-Daniel Hailfinger wrote:
>> This is another milestone in my quest to obsolete v2.
>>
>> [Patch looks strange due to a svn bug. Please let me commit, my tree 
>> will give us proper svn blame history and actually commit correctly.]
>>
> As you noted, reading the patch is weird. I don't understand, are you 
> trying to keep file history from the original files or something?

Yes.

> I would still expect the diff to have all new files.

The new files (with svn cp) didn't appear at all. They were hand-diffed 
by me.

> There is a second patch of the file that doesn't make sense. For 
> example: LinuxBIOSv3-db800/mainboard/amd/db800/irq_tables.h.

And that was an artifact of my process.

> I couldn't get it to apply cleanly. Maybe my mail reader munged it. 
> Can you check it applies and resend?

New patch, completely hand-generated, apply checked and compile checked.

> Also, there are some other cleanups that should probably be in a 
> seperate patch.
> LinuxBIOSv3-db800/mainboard/amd/norwich/irq_tables.h
> LinuxBIOSv3-db800/mainboard/pcengines/alix1c/irq_tables.h

Thanks, killed.

Regards,
Carl-Daniel

AMD DB800 support, ported from v2.

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


--- /dev/null	2007-09-21 23:50:58.000000000 +0200
+++ LinuxBIOSv3-db800/mainboard/amd/db800/Kconfig	2008-03-04 03:07:01.000000000 +0100
@@ -0,0 +1,44 @@
+##
+## This file is part of the coreboot project.
+##
+## Copyright (C) 2007 coresystems GmbH
+## (Written by Stefan Reinauer <stepan at coresystems.de> for coresystems GmbH)
+##
+## 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
+##
+
+config MAINBOARD_NAME
+	string
+	default amd/db800
+	depends BOARD_AMD_DB800
+	help
+	  This is the default mainboard name.
+
+config MAINBOARD_PCI_SUBSYSTEM_VENDOR_ID
+	hex
+	# TODO: Fix PCI ID.
+	default 0x1022
+	depends BOARD_AMD_DB800
+	help
+	  Mainboard specific PCI subsystem vendor ID.
+
+config MAINBOARD_PCI_SUBSYSTEM_DEVICE_ID
+	hex
+	# TODO: Fix PCI ID.
+	default 0x2323
+	depends BOARD_AMD_DB800
+	help
+	  Mainboard specific PCI subsystem device ID.
+
--- /dev/null	2007-09-21 23:50:58.000000000 +0200
+++ LinuxBIOSv3-db800/mainboard/amd/db800/initram.c	2008-03-04 04:02:32.000000000 +0100
@@ -0,0 +1,106 @@
+/*
+ * This file is part of the coreboot project.
+ *
+ * Copyright (C) 2007 Advanced Micro Devices, Inc.
+ *
+ * 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
+ */
+
+#define _MAINOBJECT
+
+#include <types.h>
+#include <lib.h>
+#include <console.h>
+#include <device/device.h>
+#include <device/pci.h>
+#include <string.h>
+#include <msr.h>
+#include <io.h>
+#include <amd_geodelx.h>
+#include <northbridge/amd/geodelx/raminit.h>
+
+/* #include <device/smbus.h>
+ * TODO: figure out how smbus functions should be done. See smbus_ops.c
+ */
+extern int smbus_read_byte(u16 device, u8 address);
+
+#define MANUALCONF 0		/* Do automatic strapped PLL config */
+#define PLLMSRHI 0x00001490	/* manual settings for the PLL */
+#define PLLMSRLO 0x02000030
+#define DIMM0 ((u8) 0xA0)
+#define DIMM1 ((u8) 0xA2)
+
+u8 spd_read_byte(u16 device, u8 address)
+{
+	u8 spdbyte;
+
+	printk(BIOS_DEBUG, "spd_read_byte dev %04x\n", device);
+
+	spdbyte = smbus_read_byte(device, address);
+
+	printk(BIOS_DEBUG, " addr %02x returns %02x\n", address, spdbyte);
+
+	return spdbyte;
+}
+
+/**
+  * Placeholder in case we ever need it. Since this file is a
+  * template for other motherboards, we want this here and we want the
+  * call in the right place.
+  */
+
+static void mb_gpio_init(void)
+{
+	/* Early mainboard specific GPIO setup */
+}
+
+/**
+  * main for initram for the AMD DB800 development platform.
+  * It might seem that you could somehow do these functions in, e.g., the cpu
+  * code, but the order of operations and what those operations are is VERY
+  * strongly mainboard dependent. It's best to leave it in the mainboard code.
+  */
+int main(void)
+{
+	printk(BIOS_DEBUG, "Hi there from initram (stage1) main!\n");
+	post_code(POST_START_OF_MAIN);
+
+	system_preinit();
+	printk(BIOS_DEBUG, "done preinit\n");
+
+	mb_gpio_init();
+	printk(BIOS_DEBUG, "done gpio init\n");
+
+	pll_reset(MANUALCONF, PLLMSRHI, PLLMSRLO);
+	printk(BIOS_DEBUG, "done pll reset\n");
+
+	cpu_reg_init(0, DIMM0, DIMM1);
+	printk(BIOS_DEBUG, "done cpu reg init\n");
+
+	sdram_set_registers();
+	printk(BIOS_DEBUG, "done sdram set registers\n");
+
+	sdram_set_spd_registers(DIMM0, DIMM1);
+	printk(BIOS_DEBUG, "done sdram set spd registers\n");
+
+	sdram_enable(DIMM0, DIMM1);
+	printk(BIOS_DEBUG, "done sdram enable\n");
+
+	/* Check low memory */
+	/*ram_check(0x00000000, 640*1024); */
+
+	printk(BIOS_DEBUG, "stage1 returns\n");
+	return 0;
+}
--- /dev/null	2007-09-21 23:50:58.000000000 +0200
+++ LinuxBIOSv3-db800/mainboard/amd/db800/stage1.c	2008-03-04 03:05:09.000000000 +0100
@@ -0,0 +1,57 @@
+/*
+ * This file is part of the coreboot project.
+ *
+ * Copyright (C) 2007 Advanced Micro Devices, Inc.
+ *
+ * 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 <types.h>
+#include <lib.h>
+#include <console.h>
+#include <device/device.h>
+#include <device/pci.h>
+#include <string.h>
+#include <msr.h>
+#include <io.h>
+#include <amd_geodelx.h>
+#include <southbridge/amd/cs5536/cs5536.h>
+#include <superio/winbond/w83627hf/w83627hf.h>
+
+#define SERIAL_DEV W83627HF_SP1
+#define SERIAL_IOBASE 0x3f8
+
+void hardware_stage1(void)
+{
+	void w83627hf_enable_serial(u8 dev, u8 serial, u16 iobase);
+	post_code(POST_START_OF_MAIN);
+	geodelx_msr_init();
+
+	cs5536_stage1();
+
+	/* NOTE: must do this AFTER the early_setup!
+	 * it is counting on some early MSR setup
+	 * for cs5536.
+	 */
+	cs5536_disable_internal_uart();
+	w83627hf_enable_serial(0x2e, SERIAL_DEV, SERIAL_IOBASE);
+
+}
+
+void mainboard_pre_payload(void)
+{
+	geode_pre_payload();
+	banner(BIOS_DEBUG, "mainboard_pre_payload: done");
+}
--- /dev/null	2007-09-21 23:50:58.000000000 +0200
+++ LinuxBIOSv3-db800/mainboard/amd/db800/dts	2008-03-04 04:01:49.000000000 +0100
@@ -0,0 +1,55 @@
+/*
+ * This file is part of the coreboot project.
+ *
+ * Copyright (C) 2007 Ronald G. Minnich <rminnich at gmail.com>
+ *
+ * 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
+ */
+
+/{
+	mainboard-vendor = "AMD";
+	mainboard-name = "DB800";
+	cpus { };
+	apic at 0 {
+		/config/("northbridge/amd/geodelx/apic");
+	};
+	domain at 0 {
+		/config/("northbridge/amd/geodelx/domain");
+		/* Video RAM has to be in 2MB chunks. */
+		geode_video_mb = "8";
+		pci at 1,0 {
+			/config/("northbridge/amd/geodelx/pci");
+		};
+		pci at 15,0 {
+			/config/("southbridge/amd/cs5536/dts");
+			enable_ide = "1";
+			/* Interrupt enables for LPC bus.
+			 *  Each bit is an IRQ 0-15. */
+			lpc_serirq_enable = "0x000010da";
+			/* LPC IRQ polarity. Each bit is an IRQ 0-15. */
+			lpc_serirq_polarity = "0x0000EF25";
+			/* 0:continuous 1:quiet */
+			lpc_serirq_mode = "1";
+			/* GPIO(0-0x20) for INT D:C:B:A, 0xFF=none. 
+			 * See virtual PIC spec. */
+			enable_gpio_int_route = "0x0D0C0700";
+			enable_USBP4_device = "1";
+		};
+		ioport at 46 {
+			/config/("superio/winbond/w83627hf/dts");
+			com1enable = "1";
+		};
+	};
+};
--- /dev/null	2007-09-21 23:50:58.000000000 +0200
+++ LinuxBIOSv3-db800/mainboard/amd/db800/irq_tables.h	2008-03-04 04:02:08.000000000 +0100
@@ -0,0 +1,81 @@
+/*
+* This file is part of the coreboot project.
+*
+* Copyright (C) 2007 Advanced Micro Devices, Inc.
+*
+* This program is free software; you can redistribute it and/or modify
+* it under the terms of the GNU General Public License version 2 as
+* published by the Free Software Foundation.
+*
+* 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 <pirq_routing.h>
+
+/* Number of slots and devices in the PIR table */
+#define SLOT_COUNT 4
+
+/* Platform IRQs */
+#define PIRQA 10
+#define PIRQB 11
+#define PIRQC 10
+#define PIRQD 11
+
+/* Map */
+#define M_PIRQA (1 << PIRQA)	/* Bitmap of supported IRQs */
+#define M_PIRQB (1 << PIRQB)	/* Bitmap of supported IRQs */
+#define M_PIRQC (1 << PIRQC)	/* Bitmap of supported IRQs */
+#define M_PIRQD (1 << PIRQD)	/* Bitmap of supported IRQs */
+
+/* Link */
+#define L_PIRQA 1		/* Means Slot INTx# Connects To Chipset INTA# */
+#define L_PIRQB 2		/* Means Slot INTx# Connects To Chipset INTB# */
+#define L_PIRQC 3		/* Means Slot INTx# Connects To Chipset INTC# */
+#define L_PIRQD 4		/* Means Slot INTx# Connects To Chipset INTD# */
+
+/*
+ * AMD DB800 interrupt wiring.
+ *
+ * Devices are:
+ *
+ * FIXME
+ *
+ */
+
+const struct irq_routing_table intel_irq_routing_table = {
+	PIRQ_SIGNATURE,
+	PIRQ_VERSION,
+	32 + 16 * SLOT_COUNT,	/* Max. number of devices on the bus */
+	0x00,			/* Where the interrupt router lies (bus) */
+	(0x0F << 3) | 0x0,      /* Where the interrupt router lies (dev) */
+	0x00,			/* IRQs devoted exclusively to PCI usage */
+	0x100B,			/* Vendor */
+	0x002B,			/* Device */
+	0,			/* Crap (miniport) */
+	{0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0},	/* u8 rfu[11] */
+	0x00,			/* Checksum */
+	{
+		/* If you change the number of entries, change IRQ_SLOT_COUNT above! */
+
+		/* bus, dev|fn,           {link, bitmap},      {link, bitmap},     {link, bitmap},     {link, bitmap},     slot, rfu */
+
+		/* CPU */
+		{0x00, (0x01 << 3) | 0x0, {{L_PIRQA, M_PIRQA}, {0x00, 0x00}, {0x00, 0x00}, {0x00, 0x00}}, 0x0, 0x0},
+
+		/* Chipset slots -- f.3 wires to B, and f.4 and f.5 wires to D. */
+		{0x00, (0x0F << 3) | 0x0, {{L_PIRQA, M_PIRQA}, {L_PIRQB, M_PIRQB}, {L_PIRQC, M_PIRQC}, {L_PIRQD, M_PIRQD}}, 0x0, 0x0},
+
+		/* On-board ethernet */
+		{0x00, (0x0D << 3) | 0x0, {{L_PIRQB, M_PIRQB}, {0x00, 0x00}, {0x00, 0x00}, {0x00, 0x00}}, 0x0, 0x0},
+
+		/* PCI (slot 1) */
+		{0x00, (0x0E << 3) | 0x0, {{L_PIRQC, M_PIRQC}, {L_PIRQD, M_PIRQD}, {L_PIRQA, M_PIRQA}, {L_PIRQB, M_PIRQB}}, 0x1, 0x0},
+	}
+};
--- /dev/null	2007-09-21 23:50:58.000000000 +0200
+++ LinuxBIOSv3-db800/mainboard/amd/db800/cmos.layout	2008-03-04 03:08:52.000000000 +0100
@@ -0,0 +1,74 @@
+entries
+
+#start-bit length  config config-ID    name
+#0            8       r       0        seconds
+#8            8       r       0        alarm_seconds
+#16           8       r       0        minutes
+#24           8       r       0        alarm_minutes
+#32           8       r       0        hours
+#40           8       r       0        alarm_hours
+#48           8       r       0        day_of_week
+#56           8       r       0        day_of_month
+#64           8       r       0        month
+#72           8       r       0        year
+#80           4       r       0        rate_select
+#84           3       r       0        REF_Clock
+#87           1       r       0        UIP
+#88           1       r       0        auto_switch_DST
+#89           1       r       0        24_hour_mode
+#90           1       r       0        binary_values_enable
+#91           1       r       0        square-wave_out_enable
+#92           1       r       0        update_finished_enable
+#93           1       r       0        alarm_interrupt_enable
+#94           1       r       0        periodic_interrupt_enable
+#95           1       r       0        disable_clock_updates
+#96         288       r       0        temporary_filler
+0          384       r       0        reserved_memory
+384          1       e       4        boot_option
+385          1       e       4        last_boot
+386          1       e       1        ECC_memory
+388          4       r       0        reboot_bits
+392          3       e       5        baud_rate
+400          1       e       1        power_on_after_fail
+412          4       e       6        debug_level
+416          4       e       7        boot_first
+420          4       e       7        boot_second
+424          4       e       7        boot_third
+428          4       h       0        boot_index
+432	     8       h       0        boot_countdown
+1008         16      h       0        check_sum
+
+enumerations
+
+#ID value   text
+1     0     Disable
+1     1     Enable
+2     0     Enable
+2     1     Disable
+4     0     Fallback
+4     1     Normal
+5     0     115200
+5     1     57600
+5     2     38400
+5     3     19200
+5     4     9600
+5     5     4800
+5     6     2400
+5     7     1200
+6     6     Notice
+6     7     Info
+6     8     Debug
+6     9     Spew
+7     0     Network
+7     1     HDD
+7     2     Floppy
+7     8     Fallback_Network
+7     9     Fallback_HDD
+7     10    Fallback_Floppy
+#7     3     ROM
+
+checksums
+
+checksum 392 1007 1008
+
+
--- /dev/null	2007-09-21 23:50:58.000000000 +0200
+++ LinuxBIOSv3-db800/mainboard/amd/db800/Makefile	2008-03-04 03:18:53.000000000 +0100
@@ -0,0 +1,34 @@
+##
+## This file is part of the coreboot project.
+##
+## Copyright (C) 2006-2007 coresystems GmbH
+## (Written by Stefan Reinauer <stepan at coresystems.de> for coresystems GmbH)
+##
+## 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
+##
+
+STAGE0_MAINBOARD_OBJ := $(obj)/mainboard/$(MAINBOARDDIR)/stage1.o
+
+INITRAM_OBJ =   $(src)/mainboard/$(MAINBOARDDIR)/initram.c \
+		$(src)/northbridge/amd/geodelx/raminit.c \
+		$(src)/southbridge/amd/cs5536/smbus_initram.c \
+		$(src)/arch/x86/geodelx/geodelx.c
+
+STAGE2_MAINBOARD_OBJ = 
+
+$(obj)/coreboot.vpd:
+	$(Q)printf "  BUILD   DUMMY VPD\n"
+	$(Q)dd if=/dev/zero of=$(obj)/coreboot.vpd bs=256 count=1 $(SILENT)
+
Index: LinuxBIOSv3-db800/mainboard/amd/Kconfig
===================================================================
--- LinuxBIOSv3-db800/mainboard/amd/Kconfig	(Revision 630)
+++ LinuxBIOSv3-db800/mainboard/amd/Kconfig	(Arbeitskopie)
@@ -23,6 +23,18 @@
 	prompt "Mainboard model"
 	depends on VENDOR_AMD
 
+config BOARD_AMD_DB800
+	bool "DB800"
+	select ARCH_X86
+	select CPU_AMD_GEODELX
+	select OPTION_TABLE
+	select NORTHBRIDGE_AMD_GEODELX
+	select SOUTHBRIDGE_AMD_CS5536
+	select SUPERIO_WINBOND_W83627HF
+	select PIRQ_TABLE
+	help
+	  AMD DB800 Geode LX development board.
+
 config BOARD_AMD_NORWICH
 	bool "Norwich"
 	select ARCH_X86
@@ -36,5 +48,6 @@
 
 endchoice
 
+source "mainboard/amd/db800/Kconfig"
 source "mainboard/amd/norwich/Kconfig"
 


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




From segher at kernel.crashing.org  Tue Mar  4 21:10:19 2008
From: segher at kernel.crashing.org (Segher Boessenkool)
Date: Tue, 4 Mar 2008 21:10:19 +0100
Subject: [coreboot] PIC, APIC, XAPIC and XIOAPIC
In-Reply-To: <DD1CC71B621B004FA76856E5129D6B170136788C@sbjgexmb1.amd.com>
References: <DD1CC71B621B004FA76856E5129D6B170136788C@sbjgexmb1.amd.com>
Message-ID: <42db59db8844bc0b9f5fa18d50283083@kernel.crashing.org>

> In LB stage, only PIC mode is applied, isn't it? However, I remember 
> some people of LB community told me there was no ISR except the debug 
> ISR during LB. So does this mean it totally unnecessary to setup PIC 
> via C00h/C001h IO port in LB?

You need to set up the legacy PIC really early, since it doesn't 
initialise
itself to any sane settings at bootup.


Segher




From phanig at gmail.com  Tue Mar  4 22:07:14 2008
From: phanig at gmail.com (Phani Babu Giddi)
Date: Tue, 4 Mar 2008 13:07:14 -0800
Subject: [coreboot] 3.3V PCI Post Card
Message-ID: <b61da340803041307u26eafda3tfc5d903b3ac5a390@mail.gmail.com>

Hello All,

Is anybody aware of a 3.3V PCI Post Card. I happen to purchase a PCI Post
Card from ElstonSystems and looks like it operates on 5V. Unfortunately the
Geode DB800 board that I have doesnt provide 5V.

Regards,
Phani
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20080304/fd9d6349/attachment.html>

From marc.jones at amd.com  Tue Mar  4 22:09:56 2008
From: marc.jones at amd.com (Marc Jones)
Date: Tue, 04 Mar 2008 14:09:56 -0700
Subject: [coreboot] [PATCH] v3: AMD DB800 support
In-Reply-To: <47CDAA7F.8010804@gmx.net>
References: <47CCBEF1.4040208@gmx.net> <47CD8AFB.5020603@amd.com>
	<47CDAA7F.8010804@gmx.net>
Message-ID: <47CDBAA4.6090007@amd.com>



> 
> New patch, completely hand-generated, apply checked and compile checked.
> 

I still had some issues getting the patch to apply. It could be my 
Thunderbird mail reader but you should check. Attaching the file would 
avoid a mail reader issue.


Problem in the dts

> +            lpc_serirq_mode = "1";
> +            /* GPIO(0-0x20) for INT D:C:B:A, 0xFF=none. +             * 
> See virtual PIC spec. */

...

Problem in the Makefile
> +STAGE2_MAINBOARD_OBJ = +


patch didn't like this like either. I had to put a space before config 
to get it to work.
> config BOARD_AMD_NORWICH
>     bool "Norwich"
>     select ARCH_X86


It wouldn't boot all the way into Linux. It seems like there is a IRQ 
routing since that is where the image stopped. I attached db800 and 
norwich console output.

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: db800.txt
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20080304/abf1ff8c/attachment.txt>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: norwich.txt
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20080304/abf1ff8c/attachment-0001.txt>

From joe at smittys.pointclark.net  Tue Mar  4 22:17:04 2008
From: joe at smittys.pointclark.net (joe at smittys.pointclark.net)
Date: Tue, 04 Mar 2008 16:17:04 -0500
Subject: [coreboot] flashrom issues??
In-Reply-To: <57947bf80803041056j53fef6dyaab3cc5589854d92@mail.gmail.com>
References: <20080216134533.6awmn90xcsww80c4@www.smittys.pointclark.net>
	<20080229192145.GA15773@coresystems.de> <47C89FC3.3000207@gmx.net>
	<20080301080454.x1rgbpahwwks4k8c@www.smittys.pointclark.net>
	<47C978F4.4030904@gmx.net>
	<20080301123404.lsocj753k88k08k4@www.smittys.pointclark.net>
	<20080302120343.ce1rrwrgo4ggw4gc@www.smittys.pointclark.net>
	<20080304083625.2za5fcgp2oso448k@www.smittys.pointclark.net>
	<47CD5EC3.5000304@gmx.net>
	<20080304130055.pyz552okgk8wco8w@www.smittys.pointclark.net>
	<57947bf80803041056j53fef6dyaab3cc5589854d92@mail.gmail.com>
Message-ID: <20080304161704.aiion635cs0skcwk@www.smittys.pointclark.net>

Quoting Tom Sylla <tsylla at gmail.com>:

> On Tue, Mar 4, 2008 at 1:00 PM,  <joe at smittys.pointclark.net> wrote:
>>  rm4100
>>  [root at localhost proc]# dd if=/dev/port bs=1 skip=$[0x0800] count=128 | xxd
>>  256+0 records in
>>  256+0 records out
>>  256 bytes (256 B) copied, 0.00171602 s, 149 kB/s
>>  0000000: 0000 0000 dc00 140f e700 0000 0000 0000  ................
> <SNIP>
>>  >> rm4100
>>  >> 00 00 00 00 dc 00 14 0f e7 00 00 00 00 00 00 00
> <SNIP>
>>  The output is not that nice I had to doctor it up a little bit.
>
>
> I use hexdump instead, no doctoring required:
>
> [xxx at xxx xxx]# dd if=/dev/port bs=1 skip=$[0x0800] count=128 | hexdump -C
> 00000000  00 00 00 00 18 00 00 c0  00 00 00 00 00 00 00 00    
> |................|
> 00000010  02 00 80 80 00 00 00 80  00 00 20 00 00 00 02 00    
> |.......... .....|
> 00000020  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00    
> |................|
> 00000030  00 04 00 01 00 00 06 00  00 84 84 84 84 84 01 00    
> |................|
> 00000040  01 84 05 05 05 04 05 04  05 04 00 91 40 01 28 57    
> |............ at .(W|
> 00000050  47 60 00 00 00 00 00 9f  5c 6c 00 06 00 00 a4 00    
> |G`......\l......|
> 00000060  01 00 61 01 60 00 00 00  60 7f 04 00 00 00 00 00    
> |..a.`...`.......|
> 00000070  0e 01 00 04 00 01 18 00  00 00 00 00 20 52 6c 6b    
> |............ Rlk|
> 00000080
>
> You can get quite fancy with hexdump's '-e' option, displaying in
> dwords, tab formatting, etc.
> The '-C' option gets the output formatted easily.
>

Cool, thanks for the tip Tom:-)

Thanks - Joe



From r.marek at assembler.cz  Tue Mar  4 23:11:13 2008
From: r.marek at assembler.cz (Rudolf Marek)
Date: Tue, 04 Mar 2008 23:11:13 +0100
Subject: [coreboot] VGA and Asus a8v-e_se
In-Reply-To: <47CCCADD.7060908@gmail.com>
References: <47CA62D2.3040702@gmail.com>
	<47CA669B.9090202@assembler.cz>	<47CA6B0B.6080804@gmail.com>
	<47CAE831.9070402@assembler.cz>	<47CB1616.6070105@gmail.com>
	<47CB1D6D.9090904@assembler.cz> <47CCCADD.7060908@gmail.com>
Message-ID: <47CDC901.1040307@assembler.cz>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

> Your instructions about both Powernow! and VGA BIOS were right on. I now
> have my Ubuntu system running with both video and frequency scaling
> after booting from coreboot. I have attached the output from "sudo lspci
> -vvvxxx" after making the above changes and booting coreboot.

Good. Please can you bit play with the peg_init?

I think you can ommit:

       /* Disable scrambling bit 6 to 1. */
        pci_write_config8(dev, 0xc0, 0x43);

and this part:

        /* Retrain link. */
        reg = pci_read_config8(dev, 0x50);
        pci_write_config8(dev, 0x50, reg | 0x20);

        reg = pci_read_config8(dev, 0x3e);
        reg |= 0x40;            /* Bus reset. */
        pci_write_config8(dev, 0x3e, reg);

        reg = pci_read_config8(dev, 0x3e);
        reg &= ~0x40;           /* Clear reset. */
        pci_write_config8(dev, 0x3e, reg);

Will it work afterwards?

Or you may try to change:
 pci_write_config8(dev, 0xe1, 0xb);

to:

 pci_write_config8(dev, 0xe1, 0x4);

I have usually like 1 hour of free time every day (during late evening) so I
can't test too much but I can help like this.

Thanks,
Rudolf





> 
> All of the regular PCI devices seem to be on bus 00, while the onboard
> PCIe network interface is on bus 05. The PCIe x16 card is on bus 02.
> Before I bypassed the peg_init function, all of the PCI devices except
> the Nvidia PCIe x16 video card seemed to work. When I ran lspci, it made
> no mention of any device on bus 02 or any vga or nvidia device; it did
> however see the network interface on bus 05. I neglected to save that
> output, but I can un-bypass peg_init and save the lspci output if it
> will be helpful.
> 
> BTW, how are flash chip sizes detected? All of the images I've generated
> using coreboot or saved using flashrom on this board are 512KiB, but the
> manual indicates that it has 4MiB of flash. Is the manual lying? I'm
> curious because I'm wondering if it's possible to use a Linux payload
> with this board, but I realize that Filo or etherboot is probably
> sufficient as far as minimizing boot time. Thank you very much for your
> insight and tolerance of my limited knowledge.
> 
> Jonathan Rogers
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFHzckB3J9wPJqZRNURAimOAKDViCGcN4fSUATdU8CiqQhAIVOR0QCcCIqF
7+4IqpMUwYM5N3/i7JKg+Lg=
=MTzk
-----END PGP SIGNATURE-----



From c-d.hailfinger.devel.2006 at gmx.net  Tue Mar  4 23:12:05 2008
From: c-d.hailfinger.devel.2006 at gmx.net (Carl-Daniel Hailfinger)
Date: Tue, 04 Mar 2008 23:12:05 +0100
Subject: [coreboot] [PATCH] v3: AMD DB800 support
In-Reply-To: <47CDBAA4.6090007@amd.com>
References: <47CCBEF1.4040208@gmx.net> <47CD8AFB.5020603@amd.com>
	<47CDAA7F.8010804@gmx.net> <47CDBAA4.6090007@amd.com>
Message-ID: <47CDC935.1060206@gmx.net>

On 04.03.2008 22:09, Marc Jones wrote:
>> New patch, completely hand-generated, apply checked and compile checked.
>
> I still had some issues getting the patch to apply. It could be my 
> Thunderbird mail reader but you should check. Attaching the file would 
> avoid a mail reader issue.

Patch attached. I use Seamonkey and the patch applied just fine after 
the roundtrip. Sorry for the inconvenience.


> It wouldn't boot all the way into Linux. It seems like there is a IRQ 
> routing since that is where the image stopped. I attached db800 and 
> norwich console output.

Thanks. The IRQ routing was copied straight from v2 so there should be 
no difference in theory.

There are a few things I don't like about the boot log:
> Done pll_reset
> done pll reset
> SMBus WAIT ERROR 13
> SMBus READ ERROR: smbus_send_slave_address; device a2SMBus WAIT ERROR 13
>   

All those SMBus error messages. Need to investigate.

> Done cpubug fixes
> done cpu reg init
> done sdram set registers
> SMBus WAIT ERROR 13
> SMBus READ ERROR: smbus_send_slave_address; device a2SMBus WAIT ERROR 13
> SMBus WAIT ERROR 13
> SMBus READ ERROR: smbus_send_slave_address; device a2SMBus WAIT ERROR 13
> ========== Check present =======================================================
> ========== MODBANKS ============================================================
> ========== FIELDBANKS ==========================================================
> ========== SPDNUMROWS ==========================================================
> ========== SPDBANKDENSITY ======================================================
> ========== BEFORT CTZ ==========================================================
> ========== TEST DIMM SIZE>8 ====================================================
> ========== PAGESIZE ============================================================
> ========== MAXCOLADDR ==========================================================
> ========== RDMSR CF07 ==========================================================
> ========== WRMSR CF07 ==========================================================
> ========== ALL DONE ============================================================
> ========== Check present =======================================================
> SMBus WAIT ERROR 13
> SMBus READ ERROR: smbus_send_slave_address; device a2SMBus WAIT ERROR 13
> SMBus WAIT ERROR 13
> SMBus READ ERROR: smbus_send_slave_address; device a2SMBus WAIT ERROR 13
> SMBus WAIT ERROR 13
> SMBus READ ERROR: smbus_send_slave_address; device a2SMBus WAIT ERROR 13
> SMBus WAIT ERROR 13
> SMBus READ ERROR: smbus_send_slave_address; device a2SMBus WAIT ERROR 13
> SMBus WAIT ERROR 13
> SMBus READ ERROR: smbus_send_slave_address; device a2SMBus WAIT ERROR 13
> SMBus WAIT ERROR 13
> SMBus READ ERROR: smbus_send_slave_address; device a2SMBus WAIT ERROR 13
> SMBus WAIT ERROR 13
> SMBus READ ERROR: smbus_send_slave_address; device a2SMBus WAIT ERROR 13
> SMBus WAIT ERROR 13
> SMBus READ ERROR: smbus_send_slave_address; device a2SMBus WAIT ERROR 13
> SMBus WAIT ERROR 13
> SMBus READ ERROR: smbus_send_slave_address; device a2SMBus WAIT ERROR 13
> done sdram set spd registers
> DRAM controller init done.
> RAM DLL lock
> done sdram enable
> stage1 returns
> run_file returns with 0
> Done RAM init code
>   
[...]
> PCI: scan devfn 0x0 to 0xff
> PCI: devfn 0x0
> pci_scan_get_dev: list is 0x00087eb4, *list is 0x0000b4c0
> pci_scan_get_dev: check dev pci_1_0 
> pci_scan_get_dev: check dev pci_1_0 it has devfn 0x08
> pci_scan_get_dev: check dev pci_15_0 
> pci_scan_get_dev: check dev pci_15_0 it has devfn 0x78
> pci_scan_get_dev: check dev ioport_46 
> pci_scan_get_dev: child ioport_46(IOPORT: 2e) not a pci device: it's type 11
> PCI: pci_scan_bus pci_scan_get_dev returns dev None (no dev in tree yet)
> PCI: devfn 0x0, bad id 0xffffffff
> PCI: pci_scan_bus pci_probe_dev returns dev 0x00000000("
?3
9?Gw?g?7?????E?A?
$@FP%\{??l????7B?f??1?
 ??"
> 0{?j????w?{?
?.??4?xH`\)
> PCI: devfn 0x8
>   

And the above points to memory corruption or reading uninitialized 
memory. That's a bug.

> PCI: devfn 0xb, bad id 0xffffffff
> PCI: pci_scan_bus pci_probe_dev returns dev 0x00000000("
?3
9?Gw?g?7?????E?A?
$@FP%\{??l????7B?f??1?
 ??"
> 0{?j????w?{?
?.??4?xH`\)
> PCI: devfn 0xc
>   

Same here. And countless repetitions.

> Phase 4: Reading resources...
> Root Device compute_allocate_io: base: 00000400 size: 00000000 align: 0 gran: 0
> read_resources: root(Root Device) read_resources bus 0 link: 0
> read_resources: root(Root Device) dtsname cpus have_resources 0 enabled 1
> cpus: Unknown device path type: 0
> read_resources: cpus() missing phase4_read_resources
> read_resources: root(Root Device) dtsname apic_0 have_resources 0 enabled 1
> read_resources: root(Root Device) dtsname domain_0 have_resources 0 enabled 1
> read_resources: domain_0(PCI_DOMAIN: 0000) read_resources bus 0 link: 0
> read_resources: domain_0(PCI_DOMAIN: 0000) dtsname pci_1_0 have_resources 0 enabled 1
> read_resources: "
?3
9?Gw?g?7?????E?A?
$@FP%\{??l????7B?f??1?
 ??"
> 0{?j????w?{?
?.??4?xH`\(<null>) read_resources bus 0 link: 0
> read_resources: "
?3
9?Gw?g?7?????E?A?
$@FP%\{??l????7B?f??1?
 ??"
> 0{?j????w?{?
?.??4?xH`\(<null>) read_resources bus 0 link: 0 done
> read_resources: domain_0(PCI_DOMAIN: 0000) dtsname dynamic PCI: 00:01.1 have_resources 0 enabled 1
> read_resources: domain_0(PCI_DOMAIN: 0000) dtsname dynamic PCI: 00:01.2 have_resources 0 enabled 1
>   

Similar bug.

> Copying IRQ routing tables to 0x983040x...done.
> Verifing copy of IRQ routing tables at 0x983040x...done
> Checking IRQ routing table consistency...
> check_pirq_routing_table() - irq_routing_table located at: 0x0x000f0000
> /home/marcj/svn/coreboot-v3/arch/x86/pirq_routing.c:    62:check_pirq_routing_table() - checksum is: 0x00 but should be: 0x26
> done.
>   

Ouch. And I claim the table was a straight copy of the v2 db800 table...

Thanks a lot for testing! Could you maybe test v2 db800 as well to check 
IRQ routing tables consistency there?

Fixes for some of the bugs above will come in a separate patch.

Regards,
Carl-Daniel

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

-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: linuxbios3_amd_db800_2.diff
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20080304/7b4adacc/attachment.ksh>

From r.marek at assembler.cz  Tue Mar  4 23:14:26 2008
From: r.marek at assembler.cz (Rudolf Marek)
Date: Tue, 04 Mar 2008 23:14:26 +0100
Subject: [coreboot] VGA and Asus a8v-e_se
In-Reply-To: <47CD1DAF.9080904@assembler.cz>
References: <47CA62D2.3040702@gmail.com>	<47CA669B.9090202@assembler.cz>		<47CA6B0B.6080804@gmail.com>	<47CAE831.9070402@assembler.cz>		<47CB1616.6070105@gmail.com>	<47CB1D6D.9090904@assembler.cz>		<47CCCADD.7060908@gmail.com>	<1204614968.5962.1.camel@tetris>
	<47CD1549.4090504@gmail.com> <47CD1DAF.9080904@assembler.cz>
Message-ID: <47CDC9C2.5090706@assembler.cz>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi,

I bought SST49LF080A (1MB) on http://bios-repair.co.uk for 5.74GBP incl shipping
to CZ. It does work, but minor modification to SB needs to be done. I will post
a patch some day...

Rudolf
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFHzcnC3J9wPJqZRNURAqPJAKCEFg1vvxxsGXBQ3I+eMSgc+VxAMwCePdtq
q6LcR6S5XxHdj2HerDA9mQY=
=K1/g
-----END PGP SIGNATURE-----



From r.marek at assembler.cz  Tue Mar  4 23:14:26 2008
From: r.marek at assembler.cz (Rudolf Marek)
Date: Tue, 04 Mar 2008 23:14:26 +0100
Subject: [coreboot] VGA and Asus a8v-e_se
In-Reply-To: <47CD1DAF.9080904@assembler.cz>
References: <47CA62D2.3040702@gmail.com>	<47CA669B.9090202@assembler.cz>		<47CA6B0B.6080804@gmail.com>	<47CAE831.9070402@assembler.cz>		<47CB1616.6070105@gmail.com>	<47CB1D6D.9090904@assembler.cz>		<47CCCADD.7060908@gmail.com>	<1204614968.5962.1.camel@tetris>
	<47CD1549.4090504@gmail.com> <47CD1DAF.9080904@assembler.cz>
Message-ID: <47CDC9C2.5090706@assembler.cz>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi,

I bought SST49LF080A (1MB) on http://bios-repair.co.uk for 5.74GBP incl shipping
to CZ. It does work, but minor modification to SB needs to be done. I will post
a patch some day...

Rudolf
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFHzcnC3J9wPJqZRNURAqPJAKCEFg1vvxxsGXBQ3I+eMSgc+VxAMwCePdtq
q6LcR6S5XxHdj2HerDA9mQY=
=K1/g
-----END PGP SIGNATURE-----



From marc.jones at amd.com  Tue Mar  4 23:16:20 2008
From: marc.jones at amd.com (Marc Jones)
Date: Tue, 04 Mar 2008 15:16:20 -0700
Subject: [coreboot] [PATCH] v3: AMD DB800 support
In-Reply-To: <47CDC935.1060206@gmx.net>
References: <47CCBEF1.4040208@gmx.net> <47CD8AFB.5020603@amd.com>
	<47CDAA7F.8010804@gmx.net> <47CDBAA4.6090007@amd.com>
	<47CDC935.1060206@gmx.net>
Message-ID: <47CDCA34.3060401@amd.com>



Carl-Daniel Hailfinger wrote:
> On 04.03.2008 22:09, Marc Jones wrote:
> There are a few things I don't like about the boot log:
>> Done pll_reset
>> done pll reset
>> SMBus WAIT ERROR 13
>> SMBus READ ERROR: smbus_send_slave_address; device a2SMBus WAIT ERROR 13
>>   
> 
> All those SMBus error messages. Need to investigate.

It just means that there isn't a dimm there.
Marc

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




From r.marek at assembler.cz  Tue Mar  4 23:20:33 2008
From: r.marek at assembler.cz (Rudolf Marek)
Date: Tue, 04 Mar 2008 23:20:33 +0100
Subject: [coreboot] VGA and Asus a8v-e_se
In-Reply-To: <47CCD4B6.30002@gmail.com>
References: <47CA62D2.3040702@gmail.com>
	<47CA669B.9090202@assembler.cz>	<47CA6B0B.6080804@gmail.com>
	<47CAE831.9070402@assembler.cz>	<47CB1616.6070105@gmail.com>
	<47CB1D6D.9090904@assembler.cz> <47CCD4B6.30002@gmail.com>
Message-ID: <47CDCB31.2040509@assembler.cz>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

> coreboot-2.0.0.0Normal Mon Mar  3 20:19:00 EST 2008 starting...
> now booting... real_main
> core0 started:
> now booting... Core0 started
> started ap apicid:
> SBLink=00
> NC node|link=00

Hmm yes it happened to me too but only very few times. Maybe you can put some
debug messages bellow the cache_as_ram_auto.c:

ht_setup_chains_x(sysinfo);     // it will init sblnk and sbbusn, nodes, sbdn

function, I think it might freeze in k8t890_early_setup_car.

Thanks,
Rudolf
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFHzcsw3J9wPJqZRNURAtCjAKDHSvyE6iCZIBDcH9zVTXfk+x9A0gCdFiSw
pAHIuX/4uQ5TaN3+8BwJXbs=
=EWmV
-----END PGP SIGNATURE-----



From c-d.hailfinger.devel.2006 at gmx.net  Tue Mar  4 23:27:38 2008
From: c-d.hailfinger.devel.2006 at gmx.net (Carl-Daniel Hailfinger)
Date: Tue, 04 Mar 2008 23:27:38 +0100
Subject: [coreboot] [PATCH] v3: Fix one NULL pointer dereference,
 add code to debug another one.
Message-ID: <47CDCCDA.1000509@gmx.net>

Fix one NULL pointer dereference, add code to debug another one.

Don't commit yet, I'd rather apply a fix for the NULL pointer
than just debugging it.

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


Index: device/device.c
===================================================================
--- device/device.c	(Revision 630)
+++ device/device.c	(Arbeitskopie)
@@ -277,8 +277,9 @@
 {
 	struct device *curdev;
 
-	printk(BIOS_SPEW, "%s: %s(%s) read_resources bus %d link: %d\n",
-	       __func__, bus->dev->dtsname, dev_path(bus->dev),
+	printk(BIOS_SPEW, "%s: bus->dev %p, bus->dev->dtsname %p, %s(%s) read_resources bus %d link: %d\n",
+	       __func__, bus->dev, bus->dev->dtsname,
+	       bus->dev->dtsname, dev_path(bus->dev),
 	       bus->secondary, bus->link);
 
 	/* Walk through all devices and find which resources they need. */
Index: device/pci_device.c
===================================================================
--- device/pci_device.c	(Revision 630)
+++ device/pci_device.c	(Arbeitskopie)
@@ -1101,7 +1101,7 @@
 		dev = pci_probe_dev(dev, bus, devfn);
 		printk(BIOS_SPEW,
 		       "PCI: pci_scan_bus pci_probe_dev returns dev %p(%s)\n",
-		       dev, dev->dtsname);
+		       dev, dev ? dev->dtsname : "None (not found)");
 
 		/* If this is not a multi function device, or the device is
 		 * not present don't waste time probing another function. 


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




From c-d.hailfinger.devel.2006 at gmx.net  Tue Mar  4 23:30:08 2008
From: c-d.hailfinger.devel.2006 at gmx.net (Carl-Daniel Hailfinger)
Date: Tue, 04 Mar 2008 23:30:08 +0100
Subject: [coreboot] [PATCH] v3: AMD DB800 support
In-Reply-To: <47CDCA34.3060401@amd.com>
References: <47CCBEF1.4040208@gmx.net>
	<47CD8AFB.5020603@amd.com>	<47CDAA7F.8010804@gmx.net>
	<47CDBAA4.6090007@amd.com>	<47CDC935.1060206@gmx.net>
	<47CDCA34.3060401@amd.com>
Message-ID: <47CDCD70.5040204@gmx.net>

On 04.03.2008 23:16, Marc Jones wrote:
> Carl-Daniel Hailfinger wrote:
>   
>> On 04.03.2008 22:09, Marc Jones wrote:
>> There are a few things I don't like about the boot log:
>>     
>>> Done pll_reset
>>> done pll reset
>>> SMBus WAIT ERROR 13
>>> SMBus READ ERROR: smbus_send_slave_address; device a2SMBus WAIT ERROR 13
>>>   
>>>       
>> All those SMBus error messages. Need to investigate.
>>     
>
> It just means that there isn't a dimm there.
>   

Thanks for clearing this up. That means we have to work on the error 
messages. They are irritating and confusing. And they appear too often.

Regards,
Carl-Daniel

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




From jordan.crouse at amd.com  Tue Mar  4 23:45:35 2008
From: jordan.crouse at amd.com (Jordan Crouse)
Date: Tue, 4 Mar 2008 15:45:35 -0700
Subject: [coreboot] libplayload and coreinfo
Message-ID: <20080304224535.GJ11357@cosmic.amd.com>

Greetings.  I've been talking about it for a while, and I've gotten
a few people excited, so I figured it was time to actually release
something useful.

I believe that there is a lot of power in coreboot for AMD customers,
especially in the embedded market which my team supports.  Part of
that power is in the low cost and high visibility of the open source
code, but also in the flexibility of the payload model.  Now, for a very
low cost a customer can get not only the hardware initialization, but 
also an blank page where they can add their own special, be it a fully
fledged payload, or just an intermediary before loading an operating
system.

This is where libpayload comes in - it abstracts away the icky bits
of payload initialization, and gives the user a semblance of a normal
C library that they can use to develop a payload without having to
worry about re-implementing malloc() and printf() and all the other
usual friends.

I am happy to release the first proof of concept for libpayload:

http://coreboot.org/~jcrouse/libpayload_0.1.tar.gz

This is a conglomeration of code from three projects - the 
payload initialization code from FILO, superb curses code from
our good friend Uwe Hermann, and various libc and driver bits
from coreboot-v3.  I combined them together into a library,
mixed kconfig into the mix and baked at 300F for 2 hours.  This is
proof of concept code for the most part, and I wouldn't go off
and put this in your airplane autopilot quite yet, but its a good
start.

And to celebrate the good start, how about something practical to
go with it?  Here is something I call coreinfo:

http://coreboot.org/~jcrouse/coreinfo_0.1.tar.gz

Coreinfo is a curses based payload that outputs lots of information
about the CPU and system.  Or rather, it will - for now it just 
shows the cpuid of the processor, and has a rather slick PCI device
browser.  The most important thing is that it shows that libpayload
can be used for a relatively complex payload without really breathing
hard.  Here's a screenshot:

http://coreboot.org/~jcrouse/coreinfo_screenshot.png

So, please, enjoy.  Flame me as needed, and once everybody has
digested this for a bit, we'll meet back and discuss what the
next step is.  Obviously, I think more libc functions are needed,
filesystem support is useful, and maybe even graphics are in our future.

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




From dsedrich at violin-memory.com  Tue Mar  4 23:38:38 2008
From: dsedrich at violin-memory.com (David Edrich)
Date: Tue, 4 Mar 2008 16:38:38 -0600
Subject: [coreboot] qemu error message: "Unrecognized partitioning scheme"
Message-ID: <031701c87e48$7e531ba0$7af952e0$@com>

Can anyone tell me why when following the coreboot wiki procedure for using qemu I would get the error message:

"Unrecognized partitioning scheme"

 

 

The last few lines are below:

So.FILO does seem to be able to read something from this disk image, from the output. If relevant, the OS I was using was knoppix.

 

 

Also I'd like to know if there an easy way to exit qemu. I keep having to run kill -9 <task number>

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

 

Jumping to boot code at 0x10e77c

FILO version 0.5 (dsedrich at nwell) Mon Feb 25 20:06:44 EST 2008

menu: hda3:/boot/filo/menu.lst

IDE time out

reset failed, but slave maybe exist

hda: LBA48 2147MB: QEMU HARDDISK

Unrecognized partitioning scheme

 

 

 

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

Here is everything that was outputted:

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

Welcome to elfboot, the open sourced starter.

[dsedrich at nwell:~] $ qemu -L ~ -hda /home/tmp/disk.img -nographic

Could not configure '/dev/rtc' to have a 1024 Hz timer. This is not a fatal

error, but for better emulation accuracy either use a 2.6 host Linux kernel or

type 'echo 1024 > /proc/sys/dev/rtc/max-user-freq' as root.

 

 

coreboot-2.0.0-GRUB2 Tue Feb 26 13:31:40 EST 2008 starting...

Copying coreboot to RAM.

(qemu) Jumping to coreboot.

coreboot-2.0.0-GRUB2 Tue Feb 26 13:31:40 EST 2008 booting...

Enumerating buses...

Finding PCI configuration type.

PCI: Using configuration type 1

PCI_DOMAIN: 0000 enabled

PCI: pci_scan_bus for bus 00

PCI: 00:00.0 [8086/1237] enabled

PCI: 00:01.0 [8086/7000] enabled

PCI: 00:01.1 [8086/7010] enabled

PCI: 00:01.3 [8086/7113] enabled

PCI: 00:02.0 [1013/00b8] enabled

PCI: 00:03.0 [10ec/8029] enabled

PCI: pci_scan_bus returning with max=000

done

Allocating resources...

Reading resources...

Done reading resources.

Setting resources...

I would set ram size to 0x20000 Kbytes

PCI: 00:01.1 20 <- [0x0000001400 - 0x000000140f] size 0x00000010 gran 0x04 io

PCI: 00:02.0 10 <- [0x00fc000000 - 0x00fdffffff] size 0x02000000 gran 0x19 prefmem

PCI: 00:02.0 14 <- [0x00fe000000 - 0x00fe000fff] size 0x00001000 gran 0x0c mem

PCI: 00:03.0 10 <- [0x0000001000 - 0x00000010ff] size 0x00000100 gran 0x08 io

Done setting resources.

Done allocating resources.

Enabling resources...

PCI: 00:00.0 subsystem <- 00/00

PCI: 00:00.0 cmd <- 00

PCI: 00:01.0 subsystem <- 00/00

PCI: 00:01.0 cmd <- 07

PCI: 00:01.1 cmd <- 01

PCI: 00:01.3 cmd <- 00

PCI: 00:02.0 cmd <- 03

PCI: 00:03.0 cmd <- 01

done.

Initializing devices...

Root Device init

PCI: 00:00.0 init

PCI: 00:01.0 init

PCI: 00:01.1 init

PCI: 00:01.3 init

PCI: 00:02.0 init

INSTALL REAL-MODE IDT

DO THE VGA BIOS

found VGA: vid=1013, did=b8

rom base, size: c0000

BAD SIGNATURE 0x0 0x0

biosint: INT# 0x10

biosint: eax 0x2 ebx 0x0 ecx 0x80000001 edx 0x0

biosint: ebp 0x11fac esp 0xffa edi 0x0 esi 0x12538

biosint:  ip 0x806e   cs 0x0  flags 0x46

BIOSINT: Unsupport int #0x10

PCI: 00:03.0 init

Devices initialized

Copying IRQ routing tables to 0xf0000...done.

Verifing copy of IRQ routing tables at 0xf0000...done

Checking IRQ routing table consistency...

check_pirq_routing_table() - irq_routing_table located at: 0x000f0000

done.

Moving GDT to 0x500...ok

Adjust low_table_end from 0x00000530 to 0x00001000

Adjust rom_table_end from 0x000f0400 to 0x00100000

Wrote coreboot table at: 00000530 - 00000bc4  checksum eb9d

 

Welcome to elfboot, the open sourced starter.

January 2002, Eric Biederman.

Version 1.3

 

rom_stream: 0xfffc0000 - 0xfffeffff

Found ELF candidate at offset 0

header_offset is 0

Try to load at offset 0x0

New segment addr 0x100000 size 0x3cfe0 offset 0xc0 filesize 0x12fc8

(cleaned up) New segment addr 0x100000 size 0x3cfe0 offset 0xc0 filesize 0x12fc8

New segment addr 0x13cfe0 size 0x48 offset 0x130a0 filesize 0x48

(cleaned up) New segment addr 0x13cfe0 size 0x48 offset 0x130a0 filesize 0x48

Dropping non PT_LOAD segment

Dropping non PT_LOAD segment

Loading Segment: addr: 0x0000000000100000 memsz: 0x000000000003cfe0 filesz: 0x0000000000012fc8

Clearing Segment: addr: 0x0000000000112fc8 memsz: 0x000000000002a018

Loading Segment: addr: 0x000000000013cfe0 memsz: 0x0000000000000048 filesz: 0x0000000000000048

Jumping to boot code at 0x10e77c

FILO version 0.5 (dsedrich at nwell) Mon Feb 25 20:06:44 EST 2008

menu: hda3:/boot/filo/menu.lst

IDE time out

reset failed, but slave maybe exist

hda: LBA48 2147MB: QEMU HARDDISK

Unrecognized partitioning scheme

 

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

From rminnich at gmail.com  Tue Mar  4 23:38:31 2008
From: rminnich at gmail.com (ron minnich)
Date: Tue, 4 Mar 2008 14:38:31 -0800
Subject: [coreboot] [PATCH] v3: AMD DB800 support
In-Reply-To: <47CDCD70.5040204@gmx.net>
References: <47CCBEF1.4040208@gmx.net> <47CD8AFB.5020603@amd.com>
	<47CDAA7F.8010804@gmx.net> <47CDBAA4.6090007@amd.com>
	<47CDC935.1060206@gmx.net> <47CDCA34.3060401@amd.com>
	<47CDCD70.5040204@gmx.net>
Message-ID: <13426df10803041438v18389cc6n1a485bfe05939a8e@mail.gmail.com>

On Tue, Mar 4, 2008 at 2:30 PM, Carl-Daniel Hailfinger
<c-d.hailfinger.devel.2006 at gmx.net> wrote:

>  Thanks for clearing this up. That means we have to work on the error
>  messages. They are irritating and confusing. And they appear too often.

I agree. Somehow we need to balance need for lots of diags in SPEW
with diags that are actually useful ...

ron



From marc.jones at amd.com  Tue Mar  4 23:35:52 2008
From: marc.jones at amd.com (Marc Jones)
Date: Tue, 04 Mar 2008 15:35:52 -0700
Subject: [coreboot] [PATCH] v3: AMD DB800 support
In-Reply-To: <47CDCD70.5040204@gmx.net>
References: <47CCBEF1.4040208@gmx.net>
	<47CD8AFB.5020603@amd.com>	<47CDAA7F.8010804@gmx.net>
	<47CDBAA4.6090007@amd.com>	<47CDC935.1060206@gmx.net>
	<47CDCA34.3060401@amd.com> <47CDCD70.5040204@gmx.net>
Message-ID: <47CDCEC8.20400@amd.com>



Carl-Daniel Hailfinger wrote:
> On 04.03.2008 23:16, Marc Jones wrote:
>> Carl-Daniel Hailfinger wrote:
>>  
>>> On 04.03.2008 22:09, Marc Jones wrote:
>>> There are a few things I don't like about the boot log:
>>>    
>>>> Done pll_reset
>>>> done pll reset
>>>> SMBus WAIT ERROR 13
>>>> SMBus READ ERROR: smbus_send_slave_address; device a2SMBus WAIT 
>>>> ERROR 13
>>>>         
>>> All those SMBus error messages. Need to investigate.
>>>     
>>
>> It just means that there isn't a dimm there.
>>   
> 
> Thanks for clearing this up. That means we have to work on the error 
> messages. They are irritating and confusing. And they appear too often.
> 
> Regards,
> Carl-Daniel
> 

They are turned up to level 8 (irritating and confusing). You wouldn't 
see that at level 4.....

Yes, that could be done better. My only excuse is that it was ported 
from stackless asm which couldn't track dimm presence.

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 Mar  4 23:39:39 2008
From: rminnich at gmail.com (ron minnich)
Date: Tue, 4 Mar 2008 14:39:39 -0800
Subject: [coreboot] libplayload and coreinfo
In-Reply-To: <20080304224535.GJ11357@cosmic.amd.com>
References: <20080304224535.GJ11357@cosmic.amd.com>
Message-ID: <13426df10803041439y73e65588g2305973dbb2be3c9@mail.gmail.com>

That is really cool :-)

ron



From mylesgw at gmail.com  Tue Mar  4 23:44:53 2008
From: mylesgw at gmail.com (Myles Watson)
Date: Tue, 4 Mar 2008 15:44:53 -0700
Subject: [coreboot] qemu error message: "Unrecognized partitioning
	scheme"
In-Reply-To: <031701c87e48$7e531ba0$7af952e0$@com>
References: <031701c87e48$7e531ba0$7af952e0$@com>
Message-ID: <2831fecf0803041444l2b168027tcafb1ba417eb9e7f@mail.gmail.com>

> Also I'd like to know if there an easy way to exit qemu. I keep having to
> run kill -9 <task number>
>

I'll answer the easier one :)

Switch to the terminal in which you started qemu and use Ctrl+C.

Myles



From jordan.crouse at amd.com  Tue Mar  4 23:52:40 2008
From: jordan.crouse at amd.com (Jordan Crouse)
Date: Tue, 4 Mar 2008 15:52:40 -0700
Subject: [coreboot] libplayload and coreinfo
In-Reply-To: <13426df10803041439y73e65588g2305973dbb2be3c9@mail.gmail.com>
References: <20080304224535.GJ11357@cosmic.amd.com>
	<13426df10803041439y73e65588g2305973dbb2be3c9@mail.gmail.com>
Message-ID: <20080304225240.GA23501@cosmic.amd.com>

On 04/03/08 14:39 -0800, ron minnich wrote:
> That is really cool :-)

I would like to point out that all the eye-candy is really thanks to Uwe
and his awesome tinycurses implmentation, without which none of this
would have been possible.  printf() is good and all, but I prefer 
pretty colors.

Thanks, Uwe!

> ron
> 
> -- 
> 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 ronald at zonnet.nl  Wed Mar  5 00:01:27 2008
From: ronald at zonnet.nl (Ronald Hoogenboom)
Date: Wed, 05 Mar 2008 00:01:27 +0100
Subject: [coreboot] m57sli FAN control
In-Reply-To: <20080303215150.GA19063@localdomain>
References: <1202596404.2721.46.camel@amd-x2.grundel>
	<1203293543.2857.13.camel@amd-x2.grundel>
	<1203365892.2790.18.camel@amd-x2.grundel>
	<20080218202916.GA32656@localdomain>
	<1203720727.2659.21.camel@amd-x2.grundel>
	<1203891496.2735.6.camel@amd-x2.grundel>
	<20080225193753.GA8625@localdomain>
	<1204153993.2716.22.camel@amd-x2.grundel>
	<20080227233827.GA3982@localdomain>
	<1204230442.3710.5.camel@amd-x2.grundel>
	<20080303215150.GA19063@localdomain>
Message-ID: <1204671687.2675.26.camel@amd-x2.grundel>

Hi Ward,

Strange, but here it worked...

It seems that your board(s) use (also?) FAN3. Mine uses only FAN1.
Indeed the original bios also turned on auto control of FAN3 (by the
same sensor), but since my CPU fan isn't connected to that one, I didn't
include it (bit selfish, I agree). The 0-degree threshold for the
diode-type sensors is set to 0xe5 by my bios (I don't know where you get
the 0xfe from...), but the reading is a bit off compared to the K8-temp,
so maybe the 0xec might be better (not much difference anyway). This is
only necessary sensor 2 (idx 0x59), as that is the only diode sensor.
The value 0x60 for index 0x5c is not correct according to the datasheet
(unused bits should be 0, not 1), but indeed my bios also sets 0x60.
Again the settings for index 0x70..0x75 are for FAN3, which I don't use
(the selfish principle). You also set the FAN2 control to be controlled
by temp3, but you don't set the parameters 0x68..0x6d. Should set 0x16
to some value 0~127. I think for the 0x14 index the value 0x87 was a
mistake from my side, 0xd7 uses a more sensible PWM frequency (obviously
my fan didn't care...).
The voltage limit settings 0x31..0x3f have nothing to do with FAN
control, should be left out. Shouldn't index 0x13 be set to 0x75 for
both FAN1 and FAN3 smartguardian mode?

I'll give it a try asap (probably after the weekend).

I think gigabyte provides different bios for V1 and V2 boards, shouldn't
we do the same? (by means of an option, like setting HAVE_FANCTL to 1
for v1 and to 2 for v2)

Ronald.

On Mon, 2008-03-03 at 16:51 -0500, Ward Vandewege wrote:
> All right, please find a revised patch attached that does not stop the CPU
> fan.
> 
> Turns out that the original patch malfunctioned on both v1.1 and v2 of the
> board if the it87 driver was not loaded. That driver fixed the settings,
> which added to my confusion. It also explains why it seemed to work for me at
> first, but then did not when rebooting (I was booting a different filesystem
> that did not load the it87 module on startup).
> 
> Anyway, I'd be grateful for some testing of the attached. It does the right
> thing on v1.1 and v2 of the board based on my testing. It does not set the
> diode zero adjust temperature right yet for v2 of the board (it should be 0xfe
> instead of 0xec). That could be done by adding a detection for the revision
> of the IT8716F chip (v2 seems to have rev3, v1.1 has rev0), but I don't have
> time to add that right now. It's not that important I think - but if someone
> wants to contribute that change, please feel free. There are a few other
> registers that should be slightly different between v1.1 and v2 but nothing
> very crucial it seems.
> 

> Thanks,
> Ward.
> 




From rminnich at gmail.com  Wed Mar  5 00:02:00 2008
From: rminnich at gmail.com (ron minnich)
Date: Tue, 4 Mar 2008 15:02:00 -0800
Subject: [coreboot] qemu error message: "Unrecognized partitioning
	scheme"
In-Reply-To: <031701c87e48$7e531ba0$7af952e0$@com>
References: <031701c87e48$7e531ba0$7af952e0$@com>
Message-ID: <13426df10803041502v37b079a7ob131b1e68f797ee8@mail.gmail.com>

are you sure the file you are using is partitioned?

losetup /dev/loop0 /home/tmp/disk.img
sfdisk -l /dev/loop0

If it is not partitioned you can boot it raw:
hda:/boot/filo/menu.lst

Note I left the '3' out

ron



From mylesgw at gmail.com  Wed Mar  5 00:44:00 2008
From: mylesgw at gmail.com (Myles Watson)
Date: Tue, 4 Mar 2008 16:44:00 -0700
Subject: [coreboot] A lar patch with some cleanup and adding greedy name
	matching
In-Reply-To: <2831fecf0802291214v5bd251f0q969805178da37ad@mail.gmail.com>
References: <2831fecf0802291214v5bd251f0q969805178da37ad@mail.gmail.com>
Message-ID: <010201c87e51$9f7a6af0$b522040a@chimp>


Ping.

> -----Original Message-----
> From: Myles Watson [mailto:mylesgw at gmail.com]
> Sent: Friday, February 29, 2008 1:14 PM
> To: Coreboot
> Subject: A lar patch with some cleanup and adding greedy name matching
> 
> This patch fixes lar options parsing, a seg fault with long path names,
> and
> makes use of functions that were already defined.  It also adds greedy
> name
> matching for listing and extracting archives, which allows recursive
> descent
> into the lar directory structure.
> 
> An example is:
> 
> lar -l normal/payload
>   normal/payload/segment0 (172032 bytes, zeroes compressed to 1 bytes
> @0x4330);loadaddress 0x0x112e60 entry 0x0x10e5fc
>   normal/payload/segment1 (77384 bytes, lzma compressed to 42674 bytes
> @0x4390);loadaddress 0x0x100000 entry 0x0x10e5fc
>   normal/payload/segment2 (72 bytes, lzma compressed to 47 bytes
> @0xeaa0);loadaddress 0x0x13ce60 entry 0x0x10e5fc
> Total size = 42962B 41KB (0xa7d2)
> 
> instead of
> 
> No matching lar entries found.
> 
> Myles
> 
> file-by-file changes:
> 
> util/lar/lar.c:
> 	add more options to the usage message
> 	use get_larsize() instead of using larsize
> 	rearrange errors from parsing args to be more correct
> 
> util/lar/stream.c:
> 	change elfname size to MAX_PATHLEN instead of 64
> 	make file_in_list greedy with filename matches
> 	change total_size calculation to include file names
> 	change lar_add_entry to use header_len function instead of
> reinventing
> 
> Signed-off-by: Myles Watson <mylesgw at gmail.com>




From peter at stuge.se  Wed Mar  5 00:23:48 2008
From: peter at stuge.se (Peter Stuge)
Date: Wed, 5 Mar 2008 00:23:48 +0100
Subject: [coreboot] [PATCH] flashrom: Drop rom.layout
In-Reply-To: <20080304154924.GA3598@greenwood>
References: <20080304154924.GA3598@greenwood>
Message-ID: <20080304232348.7893.qmail@stuge.se>

On Tue, Mar 04, 2008 at 04:49:24PM +0100, Uwe Hermann wrote:
> useless rom.layout

Dunno. Maybe someone uses it.

I think it will be superseded by lar support in flashrom, but until
that's ready this may actually be useful.


//Peter



From peter at stuge.se  Wed Mar  5 00:46:38 2008
From: peter at stuge.se (Peter Stuge)
Date: Wed, 5 Mar 2008 00:46:38 +0100
Subject: [coreboot] libplayload and coreinfo
In-Reply-To: <20080304225240.GA23501@cosmic.amd.com>
	<20080304224535.GJ11357@cosmic.amd.com>
References: <20080304224535.GJ11357@cosmic.amd.com>
	<13426df10803041439y73e65588g2305973dbb2be3c9@mail.gmail.com>
	<20080304225240.GA23501@cosmic.amd.com>
	<20080304224535.GJ11357@cosmic.amd.com>
Message-ID: <20080304234638.16971.qmail@stuge.se>

On Tue, Mar 04, 2008 at 03:45:35PM -0700, Jordan Crouse wrote:
> http://coreboot.org/~jcrouse/coreinfo_screenshot.png

On Tue, Mar 04, 2008 at 03:52:40PM -0700, Jordan Crouse wrote:
> I would like to point out that all the eye-candy is really thanks
> to Uwe and his awesome tinycurses implmentation

Vielen Dank and Thank You!

This made my day which was otherwise not so good.

It is beautiful!


//Peter



From peter at stuge.se  Wed Mar  5 00:51:40 2008
From: peter at stuge.se (Peter Stuge)
Date: Wed, 5 Mar 2008 00:51:40 +0100
Subject: [coreboot] m57sli FAN control
In-Reply-To: <1204671687.2675.26.camel@amd-x2.grundel>
References: <1203365892.2790.18.camel@amd-x2.grundel>
	<20080218202916.GA32656@localdomain>
	<1203720727.2659.21.camel@amd-x2.grundel>
	<1203891496.2735.6.camel@amd-x2.grundel>
	<20080225193753.GA8625@localdomain>
	<1204153993.2716.22.camel@amd-x2.grundel>
	<20080227233827.GA3982@localdomain>
	<1204230442.3710.5.camel@amd-x2.grundel>
	<20080303215150.GA19063@localdomain>
	<1204671687.2675.26.camel@amd-x2.grundel>
Message-ID: <20080304235141.18203.qmail@stuge.se>

On Wed, Mar 05, 2008 at 12:01:27AM +0100, Ronald Hoogenboom wrote:
> I think gigabyte provides different bios for V1 and V2 boards,
> shouldn't we do the same?

This is something I have thought about on and off.

If there are hardware differences on the board revisions that we are
unable to reliably determine in software I think they should be
separate ports..


> (by means of an option, like setting HAVE_FANCTL to 1 for v1 and to
> 2 for v2)

..rather than having options.

This also fits better with how v3 works, where I think it would be
more intuitive to have several board revs at the same level in the
Kconfig menus rather than having a submenu for boards where multiple
revisions are supported.


//Peter


//Peter



From rminnich at gmail.com  Wed Mar  5 02:27:21 2008
From: rminnich at gmail.com (ron minnich)
Date: Tue, 4 Mar 2008 17:27:21 -0800
Subject: [coreboot] A lar patch with some cleanup and adding greedy name
	matching
In-Reply-To: <010201c87e51$9f7a6af0$b522040a@chimp>
References: <2831fecf0802291214v5bd251f0q969805178da37ad@mail.gmail.com>
	<010201c87e51$9f7a6af0$b522040a@chimp>
Message-ID: <13426df10803041727g7df7c7eegbacdac802c6970d0@mail.gmail.com>

On Tue, Mar 4, 2008 at 3:44 PM, Myles Watson <mylesgw at gmail.com> wrote:
>
>  Ping.
>

I just did a test build with this and tested under qemu and it works
fine. I don't see how it could cause alix1c troubles so I'm acking it.

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



From c-d.hailfinger.devel.2006 at gmx.net  Wed Mar  5 02:35:57 2008
From: c-d.hailfinger.devel.2006 at gmx.net (Carl-Daniel Hailfinger)
Date: Wed, 05 Mar 2008 02:35:57 +0100
Subject: [coreboot] [PATCH] v3: AMD DB800 support
In-Reply-To: <47CDBAA4.6090007@amd.com>
References: <47CCBEF1.4040208@gmx.net> <47CD8AFB.5020603@amd.com>
	<47CDAA7F.8010804@gmx.net> <47CDBAA4.6090007@amd.com>
Message-ID: <47CDF8FD.3000105@gmx.net>

On 04.03.2008 22:09, Marc Jones wrote:
> It wouldn't boot all the way into Linux. It seems like there is a IRQ 
> routing since that is where the image stopped. I attached db800 and 
> norwich console output.

Thanks for the output. I don't like a few parts of the db800 output 
which are not there on norwich:

> PCI: Done for loop
> ioport_46
> ========== PCI: Left over static devices.
>  =====================================

It complains about left over devices, but the only leftover device is 
not a PCI device as far as the logs seem to tell. Could be a bug, could 
be that the db800 and norwich have different sets of PCI devices showing 
up...
Hm. Need to find out why dev_find_device on db800 is called 3 times for 
1022:2097 and 2 times for 1022:2096, all of them in phase 6. On Norwich, 
dev_find_device is called 2 times for 1022:2097 and once for 1022:2096.

db800.txt:dev_find_device: find PCI: 1022:2090
db800.txt:dev_find_device: find PCI: 1022:2090
db800.txt:dev_find_device: find PCI: 1022:2095
db800.txt:dev_find_device: find PCI: 1022:2097
db800.txt:dev_find_device: find PCI: 1022:2096
db800.txt:dev_find_device: find PCI: 1022:2097
db800.txt:dev_find_device: find PCI: 1022:2096
db800.txt:dev_find_device: find PCI: 1022:2097
norwich.txt:dev_find_device: find PCI: 1022:2090
norwich.txt:dev_find_device: find PCI: 1022:2090
norwich.txt:dev_find_device: find PCI: 1022:2095
norwich.txt:dev_find_device: find PCI: 1022:2097
norwich.txt:dev_find_device: find PCI: 1022:2096
norwich.txt:dev_find_device: find PCI: 1022:2097

More analysis later.

Regards,
Carl-Daniel

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




From c-d.hailfinger.devel.2006 at gmx.net  Wed Mar  5 02:43:42 2008
From: c-d.hailfinger.devel.2006 at gmx.net (Carl-Daniel Hailfinger)
Date: Wed, 05 Mar 2008 02:43:42 +0100
Subject: [coreboot] [PATCH] v3: PIRQ table cosmetics
Message-ID: <47CDFACE.4040006@gmx.net>

PIRQ table cosmetics/cleanup.

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


Index: LinuxBIOSv3-db800/mainboard/amd/norwich/irq_tables.h
===================================================================
--- LinuxBIOSv3-db800/mainboard/amd/norwich/irq_tables.h	(Revision 630)
+++ LinuxBIOSv3-db800/mainboard/amd/norwich/irq_tables.h	(Arbeitskopie)
@@ -17,17 +17,7 @@
 * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA  02110-1301 USA
 */
 
-#include <types.h>
-#include <lib.h>
-#include <console.h>
-#include <device/device.h>
-#include <device/pci.h>
-#include <string.h>
-#include <msr.h>
-#include <io.h>
 #include <pirq_routing.h>
-#include <amd_geodelx.h>
-#include "../../../southbridge/amd/cs5536/cs5536.h"
 
 /* Number of slots and devices in the PIR table */
 #define SLOT_COUNT 6
@@ -83,13 +73,19 @@
 	{0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0},	/* u8 rfu[11] */
 	0x00,			/* Checksum */
 	{
-	 /* If you change the number of entries, change the IRQ_SLOT_COUNT above! */
-	 /* bus, dev|fn,           {link, bitmap},      {link, bitmap},     {link, bitmap},     {link, bitmap},     slot, rfu */
-	 {0x00, (0x01 << 3) | 0x0, {{L_PIRQA, M_PIRQA}, {0x00, 0x00}, {0x00, 0x00}, {0x00, 0x00}}, 0x0, 0x0},	/* cpu */
-	 {0x00, (0x0F << 3) | 0x0, {{L_PIRQA, M_PIRQA}, {L_PIRQB, M_PIRQB}, {L_PIRQC, M_PIRQC}, {L_PIRQD, M_PIRQD}}, 0x0, 0x0},	/* chipset */
-	 {0x00, (0x0D << 3) | 0x0, {{L_PIRQB, M_PIRQB}, {L_PIRQC, M_PIRQC}, {L_PIRQD, M_PIRQD}, {L_PIRQA, M_PIRQA}}, 0x1, 0x0},	/* slot1 */
-	 {0x00, (0x0E << 3) | 0x0, {{L_PIRQC, M_PIRQC}, {L_PIRQD, M_PIRQD}, {L_PIRQA, M_PIRQA}, {L_PIRQB, M_PIRQB}}, 0x2, 0x0},	/* slot2 */
-	 {0x00, (0x0B << 3) | 0x0, {{L_PIRQD, M_PIRQD}, {L_PIRQA, M_PIRQA}, {L_PIRQB, M_PIRQB}, {L_PIRQC, M_PIRQC}}, 0x3, 0x0},	/* slot3 */
-	 {0x00, (0x0C << 3) | 0x0, {{L_PIRQA, M_PIRQA}, {L_PIRQB, M_PIRQB}, {L_PIRQC, M_PIRQC}, {L_PIRQD, M_PIRQD}}, 0x4, 0x0},	/* slot4 */
+		/* If you change the number of entries, change IRQ_SLOT_COUNT above! */
+		/* bus, dev|fn,           {link, bitmap},      {link, bitmap},     {link, bitmap},     {link, bitmap},     slot, rfu */
+		/* CPU */
+		{0x00, (0x01 << 3) | 0x0, {{L_PIRQA, M_PIRQA}, {0x00, 0x00}, {0x00, 0x00}, {0x00, 0x00}}, 0x0, 0x0},
+		/* chipset */
+		{0x00, (0x0F << 3) | 0x0, {{L_PIRQA, M_PIRQA}, {L_PIRQB, M_PIRQB}, {L_PIRQC, M_PIRQC}, {L_PIRQD, M_PIRQD}}, 0x0, 0x0},
+		/* slot1 */
+		{0x00, (0x0D << 3) | 0x0, {{L_PIRQB, M_PIRQB}, {L_PIRQC, M_PIRQC}, {L_PIRQD, M_PIRQD}, {L_PIRQA, M_PIRQA}}, 0x1, 0x0},
+		/* slot2 */
+		{0x00, (0x0E << 3) | 0x0, {{L_PIRQC, M_PIRQC}, {L_PIRQD, M_PIRQD}, {L_PIRQA, M_PIRQA}, {L_PIRQB, M_PIRQB}}, 0x2, 0x0},
+		/* slot3 */
+		{0x00, (0x0B << 3) | 0x0, {{L_PIRQD, M_PIRQD}, {L_PIRQA, M_PIRQA}, {L_PIRQB, M_PIRQB}, {L_PIRQC, M_PIRQC}}, 0x3, 0x0},
+		/* slot4 */
+		{0x00, (0x0C << 3) | 0x0, {{L_PIRQA, M_PIRQA}, {L_PIRQB, M_PIRQB}, {L_PIRQC, M_PIRQC}, {L_PIRQD, M_PIRQD}}, 0x4, 0x0},
 	 }
 };
Index: LinuxBIOSv3-db800/mainboard/artecgroup/dbe62/irq_tables.h
===================================================================
--- LinuxBIOSv3-db800/mainboard/artecgroup/dbe62/irq_tables.h	(Revision 630)
+++ LinuxBIOSv3-db800/mainboard/artecgroup/dbe62/irq_tables.h	(Arbeitskopie)
@@ -17,20 +17,12 @@
 * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA  02110-1301 USA
 */
 
-#include <types.h>
-#include <lib.h>
-#include <console.h>
-#include <device/device.h>
-#include <device/pci.h>
-#include <string.h>
-#include <msr.h>
-#include <io.h>
 #include <pirq_routing.h>
-#include <amd_geodelx.h>
-#include "../../../southbridge/amd/cs5536/cs5536.h"
 
+/* Number of slots and devices in the PIR table */
+#warning SLOT_COUNT does not match PIR table contents
+#define SLOT_COUNT 5
 
-
 /* Platform IRQs */
 #define PIRQA 10
 #define PIRQB 11
@@ -52,7 +44,7 @@
 const struct irq_routing_table intel_irq_routing_table = {
 	PIRQ_SIGNATURE,
 	PIRQ_VERSION,
-	32 + 16 * 5,		/* Max. number of devices on the bus */
+	32 + 16 * SLOT_COUNT,	/* Max. number of devices on the bus */
 	0x00,			/* Where the interrupt router lies (bus) */
 	(0x0F << 3) | 0x0,      /* Where the interrupt router lies (dev) */
 	0x00,			/* IRQs devoted exclusively to PCI usage */
@@ -62,9 +54,12 @@
 	{0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0},	/* u8 rfu[11] */
 	0x00,			/* Checksum */
 	{
-	 /* bus, dev|fn,           {link, bitmap},      {link, bitmap},     {link, bitmap},     {link, bitmap},     slot, rfu */
-	 {0x00, (0x01 << 3) | 0x0, {{L_PIRQA, M_PIRQA}, {0x00, 0x00}, {0x00, 0x00}, {0x00, 0x00}}, 0x0, 0x0},	/* cpu */
-	 {0x00, (0x0F << 3) | 0x0, {{L_PIRQA, M_PIRQA}, {L_PIRQB, M_PIRQB}, {L_PIRQC, M_PIRQC}, {L_PIRQD, M_PIRQD}}, 0x0, 0x0},	/* chipset */
-	 {0x00, (0x0D << 3) | 0x0, {{L_PIRQC, M_PIRQC}, {0x00, 0x00}, {0x00, 0x00}, {0x00, 0x00}}, 0x0, 0x0},	/* ethernet */
+		/* bus, dev|fn,           {link, bitmap},      {link, bitmap},     {link, bitmap},     {link, bitmap},     slot, rfu */
+		/* CPU */
+		{0x00, (0x01 << 3) | 0x0, {{L_PIRQA, M_PIRQA}, {0x00, 0x00}, {0x00, 0x00}, {0x00, 0x00}}, 0x0, 0x0},
+		/* chipset */
+		{0x00, (0x0F << 3) | 0x0, {{L_PIRQA, M_PIRQA}, {L_PIRQB, M_PIRQB}, {L_PIRQC, M_PIRQC}, {L_PIRQD, M_PIRQD}}, 0x0, 0x0},
+		/* ethernet */
+		{0x00, (0x0D << 3) | 0x0, {{L_PIRQC, M_PIRQC}, {0x00, 0x00}, {0x00, 0x00}, {0x00, 0x00}}, 0x0, 0x0},
 	}
 };
Index: LinuxBIOSv3-db800/mainboard/pcengines/alix1c/irq_tables.h
===================================================================
--- LinuxBIOSv3-db800/mainboard/pcengines/alix1c/irq_tables.h	(Revision 630)
+++ LinuxBIOSv3-db800/mainboard/pcengines/alix1c/irq_tables.h	(Arbeitskopie)
@@ -19,6 +19,8 @@
 
 #include <pirq_routing.h>
 
+/* Number of slots and devices in the PIR table */
+#define SLOT_COUNT 5
 
 /* Platform IRQs */
 #define PIRQA 11
@@ -71,7 +73,7 @@
 const struct irq_routing_table intel_irq_routing_table = {
 	PIRQ_SIGNATURE,
 	PIRQ_VERSION,
-	32 + 16 * 5,		/* Max. number of devices on the bus */
+	32 + 16 * SLOT_COUNT,	/* Max. number of devices on the bus */
 	0x00,			/* Where the interrupt router lies (bus) */
 	(0x0F << 3) | 0x0,      /* Where the interrupt router lies (dev) */
 	0x00,			/* IRQs devoted exclusively to PCI usage */


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




From c-d.hailfinger.devel.2006 at gmx.net  Wed Mar  5 03:03:46 2008
From: c-d.hailfinger.devel.2006 at gmx.net (Carl-Daniel Hailfinger)
Date: Wed, 05 Mar 2008 03:03:46 +0100
Subject: [coreboot] [PATCH] v3: Fix two NULL pointer dereferences in device
	code
In-Reply-To: <47CDCCDA.1000509@gmx.net>
References: <47CDCCDA.1000509@gmx.net>
Message-ID: <47CDFF82.5020602@gmx.net>

Ron? You can probably tell if bus->dev==NULL in read_resources(bus)
is an error or if we need to handle it cleanly.

Fix two NULL pointer dereferences in device code.
Add a nasty warning if one of the cases triggers because that should
not happen. We should fix the cases where the warning triggers.

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

Index: LinuxBIOSv3-db800-forexport/device/device.c
===================================================================
--- LinuxBIOSv3-db800-forexport/device/device.c	(Revision 630)
+++ LinuxBIOSv3-db800-forexport/device/device.c	(Arbeitskopie)
@@ -278,8 +278,13 @@
 	struct device *curdev;
 
 	printk(BIOS_SPEW, "%s: %s(%s) read_resources bus %d link: %d\n",
-	       __func__, bus->dev->dtsname, dev_path(bus->dev),
+	       __func__,
+	       (bus->dev ? bus->dev->dtsname : "No dtsname for NULL device"),
+	       (bus->dev ? dev_path(bus->dev) : "No path for NULL device"),
 	       bus->secondary, bus->link);
+	if (!bus->dev)
+		printk(BIOS_WARNING, "%s: ERROR: bus->dev is NULL!\n",
+		       __func__);
 
 	/* Walk through all devices and find which resources they need. */
 	for (curdev = bus->children; curdev; curdev = curdev->sibling) {
Index: LinuxBIOSv3-db800-forexport/device/pci_device.c
===================================================================
--- LinuxBIOSv3-db800-forexport/device/pci_device.c	(Revision 630)
+++ LinuxBIOSv3-db800-forexport/device/pci_device.c	(Arbeitskopie)
@@ -1101,7 +1101,7 @@
 		dev = pci_probe_dev(dev, bus, devfn);
 		printk(BIOS_SPEW,
 		       "PCI: pci_scan_bus pci_probe_dev returns dev %p(%s)\n",
-		       dev, dev->dtsname);
+		       dev, dev ? dev->dtsname : "None (not found)");
 
 		/* If this is not a multi function device, or the device is
 		 * not present don't waste time probing another function. 


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




From rminnich at gmail.com  Wed Mar  5 03:54:10 2008
From: rminnich at gmail.com (ron minnich)
Date: Tue, 4 Mar 2008 18:54:10 -0800
Subject: [coreboot] [PATCH] v3: Fix two NULL pointer dereferences in
	device code
In-Reply-To: <47CDFF82.5020602@gmx.net>
References: <47CDCCDA.1000509@gmx.net> <47CDFF82.5020602@gmx.net>
Message-ID: <13426df10803041854p12ec2f34tabf95237ba2ee905@mail.gmail.com>

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



This was on db800 right? I need to get a failure case.



From rminnich at gmail.com  Wed Mar  5 03:56:42 2008
From: rminnich at gmail.com (ron minnich)
Date: Tue, 4 Mar 2008 18:56:42 -0800
Subject: [coreboot] [PATCH] v3: AMD DB800 support
In-Reply-To: <47CDF8FD.3000105@gmx.net>
References: <47CCBEF1.4040208@gmx.net> <47CD8AFB.5020603@amd.com>
	<47CDAA7F.8010804@gmx.net> <47CDBAA4.6090007@amd.com>
	<47CDF8FD.3000105@gmx.net>
Message-ID: <13426df10803041856u73228065k24071067d2a701a9@mail.gmail.com>

On Tue, Mar 4, 2008 at 5:35 PM, Carl-Daniel Hailfinger
<c-d.hailfinger.devel.2006 at gmx.net> wrote:

>
>  It complains about left over devices, but the only leftover device is
>  not a PCI device as far as the logs seem to tell. Could be a bug, could
>  be that the db800 and norwich have different sets of PCI devices showing
>  up...

It is a factor of the pci-centric nature of the old v2 device tree.

Needs cleanup.

>  Hm. Need to find out why dev_find_device on db800 is called 3 times for
>  1022:2097 and 2 times for 1022:2096, all of them in phase 6. On Norwich,
>  dev_find_device is called 2 times for 1022:2097 and once for 1022:2096.
>
>  db800.txt:dev_find_device: find PCI: 1022:2090
>  db800.txt:dev_find_device: find PCI: 1022:2090
>  db800.txt:dev_find_device: find PCI: 1022:2095
>  db800.txt:dev_find_device: find PCI: 1022:2097
>  db800.txt:dev_find_device: find PCI: 1022:2096
>  db800.txt:dev_find_device: find PCI: 1022:2097
>  db800.txt:dev_find_device: find PCI: 1022:2096
>  db800.txt:dev_find_device: find PCI: 1022:2097
>  norwich.txt:dev_find_device: find PCI: 1022:2090
>  norwich.txt:dev_find_device: find PCI: 1022:2090
>  norwich.txt:dev_find_device: find PCI: 1022:2095
>  norwich.txt:dev_find_device: find PCI: 1022:2097
>  norwich.txt:dev_find_device: find PCI: 1022:2096
>  norwich.txt:dev_find_device: find PCI: 1022:2097
>
>  More analysis later.


it's an nxm algorithm. I am pretty sure those multilple prints of same
device are the devices in the tree it is trying to match against, not
the device it is called with.

ron



From Libo.Feng at amd.com  Wed Mar  5 05:12:46 2008
From: Libo.Feng at amd.com (Feng, Libo)
Date: Wed, 5 Mar 2008 12:12:46 +0800
Subject: [coreboot] PIC, APIC, XAPIC and XIOAPIC
In-Reply-To: <42db59db8844bc0b9f5fa18d50283083@kernel.crashing.org>
References: <DD1CC71B621B004FA76856E5129D6B170136788C@sbjgexmb1.amd.com>
	<42db59db8844bc0b9f5fa18d50283083@kernel.crashing.org>
Message-ID: <DD1CC71B621B004FA76856E5129D6B1701367AE8@sbjgexmb1.amd.com>

 
Hi, all,


I check the FILO code, all devices work under polling mode. So I think at the very beginning of initialization, OS probably needs the legacy PIC enabled before APIC mode enabled. 


Best Regards

??? Feng Libo @ AMD  Ext: 20906
Mobile Phone: 13683249071
Office Phone: 0086-010-62801406

-----Original Message-----
From: Segher Boessenkool [mailto:segher at kernel.crashing.org] 
Sent: Wednesday, March 05, 2008 4:10 AM
To: Feng, Libo
Cc: coreboot at coreboot.org
Subject: Re: [coreboot] PIC, APIC, XAPIC and XIOAPIC

> In LB stage, only PIC mode is applied, isn't it? However, I remember 
> some people of LB community told me there was no ISR except the debug 
> ISR during LB. So does this mean it totally unnecessary to setup PIC 
> via C00h/C001h IO port in LB?

You need to set up the legacy PIC really early, since it doesn't initialise itself to any sane settings at bootup.


Segher






From joe at smittys.pointclark.net  Wed Mar  5 05:37:13 2008
From: joe at smittys.pointclark.net (joe at smittys.pointclark.net)
Date: Tue, 04 Mar 2008 23:37:13 -0500
Subject: [coreboot] v2[PATCH]RCA RM4100 i82830 support
In-Reply-To: <dd3c80060802282108t434afff0pdf1aecdddf811d1e@mail.gmail.com>
References: <20080225122041.1b4k68468gkwcoow@www.smittys.pointclark.net>
	<20080226020328.6758.qmail@stuge.se>
	<20080225212049.kok3vfgiswk04ss8@www.smittys.pointclark.net>
	<1203995881.6248.56.camel@Mobulus>
	<20080226161958.hs8k5z3aos0ckgoc@www.smittys.pointclark.net>
	<1204063995.6248.65.camel@Mobulus>
	<20080226200223.phifyjor0g0gc0kk@www.smittys.pointclark.net>
	<20080226213345.mux04iosrkgoosks@www.smittys.pointclark.net>
	<1204090436.6695.9.camel@Mobulus>
	<20080227071619.3kvzfiyu8ksksoco@www.smittys.pointclark.net>
	<dd3c80060802282108t434afff0pdf1aecdddf811d1e@mail.gmail.com>
Message-ID: <20080304233713.9ebennthfks4wg48@www.smittys.pointclark.net>

I hate to say it Corey, but this just sends it into an infinite loop.  
Does it make a difference that the onboard memory is located in slot2  
and slot1 is empty? Here is what I have:

Thanks - Joe

static void do_ram_command(const struct mem_controller *ctrl, uint32_t  
command, uint32_t addr_offset)
{
	int i;
	uint8_t reg8;
	uint32_t reg32;

	/* Configure the RAM command. */
	reg32 = pci_read_config32(ctrl->d0, DRC);
	/* 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; */

	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 < ARRAY_SIZE(ctrl->channel0); i++) {
		reg8 = pci_read_config8(ctrl->d0, DRB + i);
		read32(((reg8 * 32) * 1024) * 1024);
	}
}



From rminnich at gmail.com  Wed Mar  5 06:08:15 2008
From: rminnich at gmail.com (ron minnich)
Date: Tue, 4 Mar 2008 21:08:15 -0800
Subject: [coreboot] some thoughts on dts vs. Kconfig vs. makefiles vs. C
	code
In-Reply-To: <20080229153508.GA14418@cosmic.amd.com>
References: <13426df10802281040n4afcdce1p1af052b71ce556f1@mail.gmail.com>
	<20080229153508.GA14418@cosmic.amd.com>
Message-ID: <13426df10803042108v25cc43ccm2d92ebc2e4b1ff8b@mail.gmail.com>

On Fri, Feb 29, 2008 at 7:35 AM, Jordan Crouse <jordan.crouse at amd.com> wrote:

>  Excellent.  I feel compelled to chime in on behalf of buildrom.  The
>  fewer files that we need to copy and/or modify from buildrom to
>  coreboot-v3 to get what we need, the happier we will be.   If we find
>  ourselves constantly changing values in the dts or in Makefiles, then
>  that should be a really good clue that perhaps the value belongs in
>  Kconfig instead.  I don't think anybody likes how we're doing configuration
>  now - I look forward to being able to copy a single .config file in
>  place, or, at the worst, being able to construct a single .config file
>  with the changes we need.

What would you change? Do you mean that the settings in the mainboard
dts should be in a .config file?

If we do that, we're going to need to make parsing the dts part of the
make menuconfig process. Or did I miss the point?

ron



From rminnich at gmail.com  Wed Mar  5 06:51:05 2008
From: rminnich at gmail.com (ron minnich)
Date: Tue, 4 Mar 2008 21:51:05 -0800
Subject: [coreboot] patch: set dbe62 to have com2 on com1 address
Message-ID: <13426df10803042151y6f1f1e3fn4c179c264669f044@mail.gmail.com>

I still have no LPC dongle, but I am getting closer. I really liked
this as it shows off the power of our new
config system, the dts. There is a whole function in v2 to make com2
operate at the com1 address. For v3, we just set
a value in the mainboard dts and we're done (in theory ; I can't tell
if this works). DBE62 is getting through a lot of POST
btw but hangs at 13.

I just realized this exampel also shows that you do NOT want all dts
values to be visible in Kconfig.
It would make no sense to change these
values on the dbe62.

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

Index: mainboard/artecgroup/dbe62/dts
===================================================================
--- mainboard/artecgroup/dbe62/dts      (revision 630)
+++ mainboard/artecgroup/dbe62/dts      (working copy)
@@ -43,6 +43,10 @@
                        /* GPIO(0-0x20) for INT D:C:B:A, 0xFF=none.
                         * See virtual PIC spec. */
                        enable_gpio_int_route = "0x0D0C0700";
+                       /* we use com2 since that is on the dongle */
+                       com2_enable = "1";
+                       /* Set com2 address to be COM1 */
+                       com2_address = "0x3f8";
                };
        };
 };



From rminnich at gmail.com  Wed Mar  5 07:23:53 2008
From: rminnich at gmail.com (ron minnich)
Date: Tue, 4 Mar 2008 22:23:53 -0800
Subject: [coreboot] first output: dbe62 and v3
Message-ID: <13426df10803042223j425b7e39jf071ca211d7106bd@mail.gmail.com>

attached. It dies and I'm sure it is bad ram settings, but it's a start.

One thing I plan to change pretty soon: power button control can move
from stage1 to stage2, and power button control will be managed in dts
(another dts setting we would NOT want visible in Kconfig; you could
render a board totally unbootable and unrepairable with the wrong
setting. Kconfig should be for settings that are safe to change).

There are other things in stage1 for the lx that we should try to move
to stage 2:
        cs5536_setup_extmsr();
        cs5536_setup_cis_mode();

        msr = rdmsr(GLCP_SYS_RSTPLL);
        if (msr.lo & (0x3f << 26)) {
                /* PLL is already set and we are reboot from PLL reset. */
                return;
        }

        cs5536_setup_idsel();
        cs5536_usb_swapsif();
        cs5536_setup_iobase();
        cs5536_setup_smbus_gpio();
        /* cs5536_enable_smbus(); -- Leave this out for now. */
//      cs5536_setup_power_button();


how much of this do we want managed in stage1? How much is unchanging,
board to board? How much MUST be there? Really, a lot is going on;
what can we leave to stage 2. Power button for sure; what else?

And how do we parameterize this? Just pass in a set of booleans for
those things we wish to control (e.g. smbus).

At this rate, carl-daniel, we may soon have another board for your list.

thanks

ron
p.s. thanks to artecgroup for such great product design and support.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: dbe62
Type: application/octet-stream
Size: 8460 bytes
Desc: not available
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20080304/a3c84e19/attachment.obj>

From corey.osgood at gmail.com  Wed Mar  5 07:30:40 2008
From: corey.osgood at gmail.com (Corey Osgood)
Date: Wed, 5 Mar 2008 01:30:40 -0500
Subject: [coreboot] v2[PATCH]RCA RM4100 i82830 support
In-Reply-To: <20080304233713.9ebennthfks4wg48@www.smittys.pointclark.net>
References: <20080225122041.1b4k68468gkwcoow@www.smittys.pointclark.net>
	<1203995881.6248.56.camel@Mobulus>
	<20080226161958.hs8k5z3aos0ckgoc@www.smittys.pointclark.net>
	<1204063995.6248.65.camel@Mobulus>
	<20080226200223.phifyjor0g0gc0kk@www.smittys.pointclark.net>
	<20080226213345.mux04iosrkgoosks@www.smittys.pointclark.net>
	<1204090436.6695.9.camel@Mobulus>
	<20080227071619.3kvzfiyu8ksksoco@www.smittys.pointclark.net>
	<dd3c80060802282108t434afff0pdf1aecdddf811d1e@mail.gmail.com>
	<20080304233713.9ebennthfks4wg48@www.smittys.pointclark.net>
Message-ID: <dd3c80060803042230y56ba10dcif065d722350dbc36@mail.gmail.com>

On Tue, Mar 4, 2008 at 11:37 PM, <joe at smittys.pointclark.net> wrote:

> I hate to say it Corey, but this just sends it into an infinite loop.
> Does it make a difference that the onboard memory is located in slot2
> and slot1 is empty? Here is what I have:
>
> Thanks - Joe


Try this instead, IIRC there are 4 DRBs. If it fails to build with too few
registers, I think you can nuke the extra variable and just do multiple
reads to the same location, or else reuse reg32 in place of reg8_2. I'm not
really sure why the previous version failed, it looks sound to me. It might
be interesting to put in some debugging output, to see what's going wrong.

static void do_ram_command(const struct mem_controller *ctrl, uint32_t
command, uint32_t addr_offset)
{
       int i;
       uint8_t reg8, reg8_2 = 0;
       uint32_t reg32;

       /* Configure the RAM command. */
       reg32 = pci_read_config32(ctrl->d0, DRC);
       /* 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; */

       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); //extra
parentheses aren't necessary
               reg8_2 = reg8;
       }
}
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20080305/aca43022/attachment.html>

From r.marek at assembler.cz  Wed Mar  5 09:10:54 2008
From: r.marek at assembler.cz (Rudolf Marek)
Date: Wed, 05 Mar 2008 09:10:54 +0100
Subject: [coreboot] PIC, APIC, XAPIC and XIOAPIC
In-Reply-To: <DD1CC71B621B004FA76856E5129D6B1701367AE8@sbjgexmb1.amd.com>
References: <DD1CC71B621B004FA76856E5129D6B170136788C@sbjgexmb1.amd.com>	<42db59db8844bc0b9f5fa18d50283083@kernel.crashing.org>
	<DD1CC71B621B004FA76856E5129D6B1701367AE8@sbjgexmb1.amd.com>
Message-ID: <47CE558E.9030704@assembler.cz>

Hello,

You need to put at least SB IOAPICs in virtualwire mode. Thats what BIOS should 
do. CHeck the Multiprocessor Specs 1.4 for details. (or VIA 8237 code in 
southbridge/)

http://www.intel.com/design/intarch/MANUALS/242016.htm

Rudolf



From Libo.Feng at amd.com  Wed Mar  5 09:25:11 2008
From: Libo.Feng at amd.com (Feng, Libo)
Date: Wed, 5 Mar 2008 16:25:11 +0800
Subject: [coreboot] PIC, APIC, XAPIC and XIOAPIC
In-Reply-To: <47CE558E.9030704@assembler.cz>
References: <DD1CC71B621B004FA76856E5129D6B170136788C@sbjgexmb1.amd.com>	<42db59db8844bc0b9f5fa18d50283083@kernel.crashing.org>
	<DD1CC71B621B004FA76856E5129D6B1701367AE8@sbjgexmb1.amd.com>
	<47CE558E.9030704@assembler.cz>
Message-ID: <DD1CC71B621B004FA76856E5129D6B1701367C4D@sbjgexmb1.amd.com>

 
Yes. I think that after power on, IOAPIC works on PIC mode or virtual wire mode by default. But no device use interrupts in both coreboot and FILO, keyboard, vga, serial port all polling. I check the mptable.c, some people set the IOAPIC in PIC mode via c00h/c01h, now that no device uses it, why they set it? Maybe at the very beginning of OS, PIC mode is applied before IOAPIC is enabled. My understanding is correct or not? Thank you.


Best Regards

??? Feng Libo @ AMD  Ext: 20906
Mobile Phone: 13683249071
Office Phone: 0086-010-62801406

-----Original Message-----
From: Rudolf Marek [mailto:r.marek at assembler.cz] 
Sent: Wednesday, March 05, 2008 4:11 PM
To: Feng, Libo
Cc: coreboot at coreboot.org
Subject: Re: [coreboot] PIC, APIC, XAPIC and XIOAPIC

Hello,

You need to put at least SB IOAPICs in virtualwire mode. Thats what BIOS should do. CHeck the Multiprocessor Specs 1.4 for details. (or VIA 8237 code in
southbridge/)

http://www.intel.com/design/intarch/MANUALS/242016.htm

Rudolf





From r.marek at assembler.cz  Wed Mar  5 09:28:38 2008
From: r.marek at assembler.cz (Rudolf Marek)
Date: Wed, 05 Mar 2008 09:28:38 +0100
Subject: [coreboot] PIC, APIC, XAPIC and XIOAPIC
In-Reply-To: <DD1CC71B621B004FA76856E5129D6B1701367C4D@sbjgexmb1.amd.com>
References: <DD1CC71B621B004FA76856E5129D6B170136788C@sbjgexmb1.amd.com>	<42db59db8844bc0b9f5fa18d50283083@kernel.crashing.org>
	<DD1CC71B621B004FA76856E5129D6B1701367AE8@sbjgexmb1.amd.com>
	<47CE558E.9030704@assembler.cz>
	<DD1CC71B621B004FA76856E5129D6B1701367C4D@sbjgexmb1.amd.com>
Message-ID: <47CE59B6.3060601@assembler.cz>

Feng, Libo wrote:
> 
> Yes. I think that after power on, IOAPIC works on PIC mode or virtual wire
> mode by default. But no device use interrupts in both coreboot and FILO,
> keyboard, vga, serial port all polling. I check the mptable.c, some people
> set the IOAPIC in PIC mode via c00h/c01h, now that no device uses it, why
> they set it? Maybe at the very beginning of OS, PIC mode is applied before
> IOAPIC is enabled. My understanding is correct or not? Thank you.

Yes its true, there is short period of time where PIC is used. So it is later 
switched to APIC.

Thanks,
Rudolf



From jonathanrrogers at gmail.com  Wed Mar  5 10:08:05 2008
From: jonathanrrogers at gmail.com (Jonathan Rogers)
Date: Wed, 05 Mar 2008 04:08:05 -0500
Subject: [coreboot] VGA and Asus a8v-e_se
In-Reply-To: <47CDC901.1040307@assembler.cz>
References: <47CA62D2.3040702@gmail.com>
	<47CA669B.9090202@assembler.cz>	<47CA6B0B.6080804@gmail.com>
	<47CAE831.9070402@assembler.cz>	<47CB1616.6070105@gmail.com>
	<47CB1D6D.9090904@assembler.cz> <47CCCADD.7060908@gmail.com>
	<47CDC901.1040307@assembler.cz>
Message-ID: <47CE62F5.8010706@gmail.com>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Rudolf Marek wrote:
>> Your instructions about both Powernow! and VGA BIOS were right on. I now
>> have my Ubuntu system running with both video and frequency scaling
>> after booting from coreboot. I have attached the output from "sudo lspci
>> -vvvxxx" after making the above changes and booting coreboot.
> 
> Good. Please can you bit play with the peg_init?
> 
> I think you can ommit:
> 
>        /* Disable scrambling bit 6 to 1. */
>         pci_write_config8(dev, 0xc0, 0x43);
> 
> and this part:
> 
>         /* Retrain link. */
>         reg = pci_read_config8(dev, 0x50);
>         pci_write_config8(dev, 0x50, reg | 0x20);
> 
>         reg = pci_read_config8(dev, 0x3e);
>         reg |= 0x40;            /* Bus reset. */
>         pci_write_config8(dev, 0x3e, reg);
> 
>         reg = pci_read_config8(dev, 0x3e);
>         reg &= ~0x40;           /* Clear reset. */
>         pci_write_config8(dev, 0x3e, reg);
> 
> Will it work afterwards?

I made these changes and VGA initialization works!

One thing that I didn't notice the first few times I booted with
coreboot is that the CPU fan speed control that Asus calls Q-fan doesn't
seem to be working. When I boot using the legacy Asus BIOS, the CPU fan
audibly slows down a few seconds after starting. Whenever the CPU is
idle, the sensors command shows the CPU fan at about 1800 RPM. However,
 after booting coreboot, the fan stays at full blast. The sensors
command shows that the CPU fan is running at about 2500 RPM continuously.

I see that the Wiki page
<URL:http://www.coreboot.org/ASUS_A8V-E_SE_Build_Tutorial> says that
Sensors / fan control is "OK", but I'm not sure if that means that the
motherboard's fan speed controller should be working or not. I also
tried to set up fan speed control using the LM-sensors package. Here's
the output from "sudo pwmconfig":

- ----------------------------------------------------------------------
This program will search your sensors for pulse width modulation (pwm)
controls, and test each one to see if it controls a fan on
your motherboard. Note that many motherboards do not have pwm
circuitry installed, even if your sensor chip supports pwm.

We will attempt to briefly stop each fan using the pwm controls.
The program will attempt to restore each fan to full speed
after testing. However, it is ** very important ** that you
physically verify that the fans have been to full speed
after the program has completed.

Found the following devices:
   hwmon0/device is k8temp
   hwmon1/device is w83627ehf

Found the following PWM controls:
   hwmon1/device/pwm1
hwmon1/device/pwm1 stuck to 0
Failed to set hwmon1/device/pwm1 to full speed
Something's wrong, check your fans!
- ----------------------------------------------------------------------

Thank you very much for your time and help, especially in light of your
busy schedule. I hope my experiments can help you and others who want to
run coreboot on this board.

Jonathan Rogers
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFHzmL0Ms6f82yVS5wRAmiXAJ0fvSHrlRr4XIGXjUhWejngkYG9CQCeL7GB
OJzGAEaB3z+Aez3Vh1z/6bI=
=/flJ
-----END PGP SIGNATURE-----



From klaus123 at ibnoetzold.de  Wed Mar  5 10:16:51 2008
From: klaus123 at ibnoetzold.de (Klaus Stammermann)
Date: Wed, 5 Mar 2008 10:16:51 +0100 (CET)
Subject: [coreboot] make problem
In-Reply-To: <00c301c87e11$f0b22650$b522040a@chimp>
References: <200803041514.19070.klaus123@ibnoetzold.de>
	<00c301c87e11$f0b22650$b522040a@chimp>
Message-ID: <1968.213.61.222.30.1204708611.squirrel@www.ibnoetzold.de>

>> -----Original Message-----
>> From: coreboot-bounces at coreboot.org
>> [mailto:coreboot-bounces at coreboot.org]
>> On Behalf Of Klaus Stammermann
>> Sent: Tuesday, March 04, 2008 7:14 AM
>> To: coreboot at coreboot.org
>> Subject: [coreboot] make problem
>>
>> Hi there
>>
>> On my EPIA-ME6000 I try to get some free space to insert VGA BIOS. But I
>> get
>> often this error message:
>> "XIP_ROM_BASE is not a multiple of XIP_ROM_SIZE".
>>
>> Could anyone explain what this means? What do I have looking for to get
>> some
>> free space in my image?
>>
>> An overview of all possible options and their description would be very
>> nice.
>> Is there something like that available?
>
> This is helpful for me.  Marc Jones put it together.
>
> http://www.coreboot.org/Anatomy_of_a_Failover_coreboot_v2_Image
>
> Myles
Thank you. That overview could help.

Klaus





From r.marek at assembler.cz  Wed Mar  5 10:27:34 2008
From: r.marek at assembler.cz (Rudolf Marek)
Date: Wed, 05 Mar 2008 10:27:34 +0100
Subject: [coreboot] VGA and Asus a8v-e_se
In-Reply-To: <47CE62F5.8010706@gmail.com>
References: <47CA62D2.3040702@gmail.com>
	<47CA669B.9090202@assembler.cz>	<47CA6B0B.6080804@gmail.com>
	<47CAE831.9070402@assembler.cz>	<47CB1616.6070105@gmail.com>
	<47CB1D6D.9090904@assembler.cz> <47CCCADD.7060908@gmail.com>
	<47CDC901.1040307@assembler.cz> <47CE62F5.8010706@gmail.com>
Message-ID: <47CE6786.1000404@assembler.cz>

Hi,

> I made these changes and VGA initialization works!

OK I will try maybe today evening with my ATI card. I think we can leave it like 
that.

> One thing that I didn't notice the first few times I booted with
> coreboot is that the CPU fan speed control that Asus calls Q-fan doesn't
> seem to be working. When I boot using the legacy Asus BIOS, the CPU fan
> audibly slows down a few seconds after starting. Whenever the CPU is
> idle, the sensors command shows the CPU fan at about 1800 RPM. However,
>  after booting coreboot, the fan stays at full blast. The sensors
> command shows that the CPU fan is running at about 2500 RPM continuously.

Yes I know, maybe we should create some TODO plan on wiki page:

A8V-E SE Specific todo:

1) initialize fans to "thermal cruise mode"
2) reset somtimes does not work
3) LDT bus is set to 1000MHz and not checked for Semprons or other settings
4) Extend the flash decode so 1MB chips can be used

My global todo:

5) genpowenow - generatate automatically the APCI objects for powernow
6) S3 support
7) Dummy SMM routine
8) v3 port?

> Thank you very much for your time and help, especially in light of your
> busy schedule. I hope my experiments can help you and others who want to
> run coreboot on this board.

yes I'm glad that someone pick up this board - maybe you can jump in and try to 
program something too ;) I would suggest to start with 1, 3 or 4.

For the silent fan, you can use /sys/class/hwmon/... interfacce. Check the
http://git.kernel.org/?p=linux/kernel/git/stable/linux-2.6.24.y.git;a=blob;f=Documentation/hwmon/w83627ehf;h=ccc2bcb610686aaf44a0d38c5f67db44e8985e82;hb=HEAD

Not all detailed parameters can be programmed by the driver, but all important 
yes. So you can use "echo " command to programm it. I think pwm2 is the CPU FAN 
header.

Here is a datasheet for a chip.
http://www.winbond.com/hq/enu/ProductAndSales/ProductLines/ComputerLogicIC/SuperIO/LPCSuperIOforDesktopAndServer/W83627EHG.htm

Thanks,

Rudolf



From klaus123 at ibnoetzold.de  Wed Mar  5 10:33:34 2008
From: klaus123 at ibnoetzold.de (Klaus Stammermann)
Date: Wed, 5 Mar 2008 10:33:34 +0100 (CET)
Subject: [coreboot] Problems with VIA EPIA-ME6000
In-Reply-To: <20080304162812.GB5787@greenwood>
References: <200803031520.56570.klaus123@ibnoetzold.de>
	<200803041442.19732.klaus123@ibnoetzold.de>
	<20080304152323.GA1533@greenwood>
	<200803041710.41023.klaus123@ibnoetzold.de>
	<20080304162812.GB5787@greenwood>
Message-ID: <3176.213.61.222.30.1204709614.squirrel@www.ibnoetzold.de>

> On Tue, Mar 04, 2008 at 05:10:40PM +0100, Klaus Stammermann wrote:
>> Here the diff:
>> -----------------------------------------------------------------------------------------------------------------------------------
>> Index: src/mainboard/via/epia-m/Options.lb
>> ===================================================================
>> --- src/mainboard/via/epia-m/Options.lb	(Revision 3086)
>> +++ src/mainboard/via/epia-m/Options.lb	(Arbeitskopie)
>> @@ -51,8 +51,8 @@
>>  ###
>>  ### Build options
>>  ###
>> -default CONFIG_PCI_ROM_RUN=0
>> -default CONFIG_CONSOLE_VGA=0
>> +default CONFIG_PCI_ROM_RUN=1
>> +default CONFIG_CONSOLE_VGA=1
>
> Looks ok.
>
>>  ##
>>  ## Build code for the fallback boot
>> Index: targets/via/epia-m/Config.lb
>> ===================================================================
>> --- targets/via/epia-m/Config.lb	(Revision 3086)
>> +++ targets/via/epia-m/Config.lb	(Arbeitskopie)
>> @@ -7,21 +7,21 @@
>>  option  DEFAULT_CONSOLE_LOGLEVEL=8
>>  option  CONFIG_CONSOLE_SERIAL8250=1
>>
>> -option ROM_SIZE=256*1024
>> +option ROM_SIZE=(256*1024)-(64*1024)
>
> OK, assuming you have a 256KB ROM chip and your VGA BIOS is 64KB.
>

I have 256KB ROM and I got some VGA BIOS. One of them is exactly 64KB but
that one out of script is smaller (see below).

>>  option HAVE_OPTION_TABLE=1
>>  option CONFIG_ROM_PAYLOAD=1
>>  option HAVE_FALLBACK_BOOT=1
>>  #option CONFIG_COMPRESSED_PAYLOAD_NRV2B=1
>> -option CONFIG_COMPRESSED_PAYLOAD_NRV2B=0
>> +#option CONFIG_COMPRESSED_PAYLOAD_NRV2B=0
>
> Why?
>
>
>>  ### Compute the location and size of where this firmware image
>>  ### (coreboot plus bootloader) will live in the boot rom chip.
>>  ###
>> -option FALLBACK_SIZE=131072
>> +option FALLBACK_SIZE=(96*1024)
>
> Not sure about this. I'd rather not change it unless really necessary
> (it isn't in this case, I think).
>
>
>>  ## Coreboot C code runs at this location in RAM
>>  option _RAMBASE=0x00004000
>> @@ -31,18 +31,22 @@
>>  #
>>  romimage "normal"
>>  	option USE_FALLBACK_IMAGE=0
>> -#option ROM_IMAGE_SIZE=128*1024
>> -	option ROM_IMAGE_SIZE=64*1024
>> +#	option ROM_IMAGE_SIZE=(128*1024)-27312
>> +	option ROM_IMAGE_SIZE=(96*1024)-27312
>
> This is wrong.
>
> ROM_IMAGE_SIZE is the maximum size the coreboot code can use (without
> payload, without VGA ROM, etc).
>
> Something like 64*1024 is usually ok.
>
>

OK, I will look at that. I got these options out of Config.vga.filo.

>> +#	option ROM_IMAGE_SIZE=0xc000
>> +#	option ROM_SECTION_OFFSET=0x10000
>> +#	option ROM_SECTION_SIZE=0x18000
>>  	option COREBOOT_EXTRA_VERSION=".0-Normal"
>> -	payload $(HOME)/svn/payload.elf
>> +	payload $(HOME)/Entwicklung/LinuxBIOS/VIA-BIOS/filo.small.elf
>
> Never used $(HOME) here, but I assume it works? If not, try
> /tmp/filo.elf and copy your payload there.
>
>

I don't think I got problems with this but I can try an absolute path.

>>  end
>>
>>  romimage "fallback"
>>  	option USE_FALLBACK_IMAGE=1
>> -	#option ROM_IMAGE_SIZE=128*1024
>> -	option ROM_IMAGE_SIZE=60*1024
>> +#	option ROM_IMAGE_SIZE=(128*1024)-27312
>> +	option ROM_IMAGE_SIZE=(96*1024)-27312
>
> Also wrong, see above.
>
>
>> +#	option ROM_IMAGE_SIZE=0xc000
>>  	option COREBOOT_EXTRA_VERSION=".0-Fallback"
>> -	payload $(HOME)/svn/payload.elf
>> +	payload $(HOME)/Entwicklung/LinuxBIOS/VIA-BIOS/filo.small.elf
>>  end
>>
>>  buildrom ./coreboot.rom ROM_SIZE "normal" "fallback"
>> -----------------------------------------------------------------------------------------------------------------------------------
>
>
>> In an earlier version I changed Config.lb in src dir to get VGA BIOS.
>> But now
>> it isn't included. If it is important, I could post it later.
>
> Plese post it.

On monday I'll send it to mailinglist.

>
> But the above patch comes from an 'svn diff' at the top-level directory,
> correct? I.e. all your current changes are in there?
>

Yes, these are actual all changes on top-level dir of corebott sandbox.

>> > Also, where did you get your VGA ROM from? Using which tools
>> (awardeco,
>> > amideco, phnxdeco, other)? How big is it exactly?
>> >
>> On http://www.coreboot.org/VGA_support at bottom there is a perl script.
>> Using
>> this I got my VGABIOS. This is 60416 bytes big
>
> OK. Which vendor BIOS does the board have? Can you use
> awardeco/amideco/phnxdeco to get the VGA BIOS and compare it with the
> one from the script? Just to be sure that worked fine...
>

I'll try this on monday. I don't know, what vendor BIOS was in ROM. I used
the original BIOS got from VIA.

>> (optionsrom is 57344 bytes which I used at last).
>
> Huh, what's that? Where from?
>

Look at post of Stefan Reinauer
(http://www.coreboot.org/pipermail/coreboot/2008-March/031664.html)

>> filo.small.elf is 27312 bytes big. So don't wonder what number this is.
>
> Are you sure this is ok? The smallest usable FILO I've used so far is
> ca. 57 KB. Your 27 KB FILO looks _very_ small.
>
> Also, please use the latest version from
>
>  % svn co svn://coreboot.org/filo/trunk/filo-0.5
>
> Type 'make' (that will generate a Config file), then edit Config, then
> type make again.
>
>
> Uwe.
> --
> http://www.hermann-uwe.de  | http://www.holsham-traders.de
> http://www.crazy-hacks.org | http://www.unmaintained-free-software.org
>

I'm not sure if payload is ok. But at first I used a bigger one and the
errors where same. So I removed all I think I'll not need. How can I test
payload?

But if your smallest payload is 57KB and I will use normal and fallback
and a VGA BIOS I get space problems. About 64KB for VGA and 2 payloads
about 57KB are 178KB. Is 78KB for normal and fallback not too small?

I will update my filo and look at that config. Maybe there is some special
on my config (e.g. I only need ext2, so all other are deactivated).

Klaus



From svn at coreboot.org  Wed Mar  5 13:57:11 2008
From: svn at coreboot.org (svn at coreboot.org)
Date: Wed,  5 Mar 2008 13:57:11 +0100
Subject: [coreboot] r631 - coreboot-v3/device
Message-ID: <mailman.1249.1355071274.16123.coreboot@coreboot.org>

Author: hailfinger
Date: 2008-03-05 13:57:10 +0100 (Wed, 05 Mar 2008)
New Revision: 631

Modified:
   coreboot-v3/device/device.c
   coreboot-v3/device/pci_device.c
Log:
Fix two NULL pointer dereferences in device code.
Add a nasty warning if one of the cases triggers because that should
not happen. We should fix the cases where the warning triggers.

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


Modified: coreboot-v3/device/device.c
===================================================================
--- coreboot-v3/device/device.c	2008-03-03 16:14:15 UTC (rev 630)
+++ coreboot-v3/device/device.c	2008-03-05 12:57:10 UTC (rev 631)
@@ -278,8 +278,13 @@
 	struct device *curdev;
 
 	printk(BIOS_SPEW, "%s: %s(%s) read_resources bus %d link: %d\n",
-	       __func__, bus->dev->dtsname, dev_path(bus->dev),
+	       __func__,
+	       (bus->dev ? bus->dev->dtsname : "No dtsname for NULL device"),
+	       (bus->dev ? dev_path(bus->dev) : "No path for NULL device"),
 	       bus->secondary, bus->link);
+	if (!bus->dev)
+		printk(BIOS_WARNING, "%s: ERROR: bus->dev is NULL!\n",
+		       __func__);
 
 	/* Walk through all devices and find which resources they need. */
 	for (curdev = bus->children; curdev; curdev = curdev->sibling) {

Modified: coreboot-v3/device/pci_device.c
===================================================================
--- coreboot-v3/device/pci_device.c	2008-03-03 16:14:15 UTC (rev 630)
+++ coreboot-v3/device/pci_device.c	2008-03-05 12:57:10 UTC (rev 631)
@@ -1101,7 +1101,7 @@
 		dev = pci_probe_dev(dev, bus, devfn);
 		printk(BIOS_SPEW,
 		       "PCI: pci_scan_bus pci_probe_dev returns dev %p(%s)\n",
-		       dev, dev->dtsname);
+		       dev, dev ? dev->dtsname : "None (not found)");
 
 		/* If this is not a multi function device, or the device is
 		 * not present don't waste time probing another function. 




From c-d.hailfinger.devel.2006 at gmx.net  Wed Mar  5 13:56:21 2008
From: c-d.hailfinger.devel.2006 at gmx.net (Carl-Daniel Hailfinger)
Date: Wed, 05 Mar 2008 13:56:21 +0100
Subject: [coreboot] [PATCH] v3: Fix two NULL pointer dereferences in
	device code
In-Reply-To: <13426df10803041854p12ec2f34tabf95237ba2ee905@mail.gmail.com>
References: <47CDCCDA.1000509@gmx.net> <47CDFF82.5020602@gmx.net>
	<13426df10803041854p12ec2f34tabf95237ba2ee905@mail.gmail.com>
Message-ID: <47CE9875.6090007@gmx.net>

On 05.03.2008 03:54, ron minnich wrote:
> Acked-by: Ronald G. Minnich <rminnich at gmail.com>
>   

Thanks, committed in r631.

> This was on db800 right? I need to get a failure case.
>   

db800, norwich, probably any AMD board triggered the NULL dereference in 
device/device.c. There is still one NULL dereference left in 
device/device.c and I need you to answer my question to fix it 
completely. Then again, you probably asked for a way to reproduce to see 
this. With the patch applied, look for "ERROR: bus->dev is NULL" in the 
logs and notice if that appears, there is garbage in the log later on.

>> Ron? You can probably tell if bus->dev==NULL in read_resources(bus)
>> is an error or if we need to handle it cleanly.
>>     

All boards (including qemu) triggered the NULL pointer in 
device/pci_device.c. Look for "None (not found)" in the logs with the 
patch applied. You'll see it 33 times in the qemu boot log.

Regards,
Carl-Daniel

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




From c-d.hailfinger.devel.2006 at gmx.net  Wed Mar  5 14:04:30 2008
From: c-d.hailfinger.devel.2006 at gmx.net (Carl-Daniel Hailfinger)
Date: Wed, 05 Mar 2008 14:04:30 +0100
Subject: [coreboot] [PATCH] v3: AMD DB800 support
In-Reply-To: <13426df10803041856u73228065k24071067d2a701a9@mail.gmail.com>
References: <47CCBEF1.4040208@gmx.net> <47CD8AFB.5020603@amd.com>	
	<47CDAA7F.8010804@gmx.net> <47CDBAA4.6090007@amd.com>	
	<47CDF8FD.3000105@gmx.net>
	<13426df10803041856u73228065k24071067d2a701a9@mail.gmail.com>
Message-ID: <47CE9A5E.5040309@gmx.net>

On 05.03.2008 03:56, ron minnich wrote:
> On Tue, Mar 4, 2008 at 5:35 PM, Carl-Daniel Hailfinger wrote:
>   
>>  It complains about left over devices, but the only leftover device is
>>  not a PCI device as far as the logs seem to tell. Could be a bug, could
>>  be that the db800 and norwich have different sets of PCI devices showing
>>  up...
>>     
>
> It is a factor of the pci-centric nature of the old v2 device tree.
>
> Needs cleanup.
>   

Can you do that? I'm not totally familiar with the code there.

>>  Hm. Need to find out why dev_find_device on db800 is called 3 times for
>>  1022:2097 and 2 times for 1022:2096, all of them in phase 6. On Norwich,
>>  dev_find_device is called 2 times for 1022:2097 and once for 1022:2096.
>>
>>  db800.txt:dev_find_device: find PCI: 1022:2090
>>  db800.txt:dev_find_device: find PCI: 1022:2090
>>  db800.txt:dev_find_device: find PCI: 1022:2095
>>  db800.txt:dev_find_device: find PCI: 1022:2097
>>  db800.txt:dev_find_device: find PCI: 1022:2096
>>  db800.txt:dev_find_device: find PCI: 1022:2097
>>  db800.txt:dev_find_device: find PCI: 1022:2096
>>  db800.txt:dev_find_device: find PCI: 1022:2097
>>  norwich.txt:dev_find_device: find PCI: 1022:2090
>>  norwich.txt:dev_find_device: find PCI: 1022:2090
>>  norwich.txt:dev_find_device: find PCI: 1022:2095
>>  norwich.txt:dev_find_device: find PCI: 1022:2097
>>  norwich.txt:dev_find_device: find PCI: 1022:2096
>>  norwich.txt:dev_find_device: find PCI: 1022:2097
>>
>>  More analysis later.
>>     
>
>
> it's an nxm algorithm. I am pretty sure those multilple prints of same
> device are the devices in the tree it is trying to match against, not
> the device it is called with.
>   

No, unfortunately this is the device it is called with/looking for. 
Seems to be a bug.

Regards,
Carl-Daniel

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




From c-d.hailfinger.devel.2006 at gmx.net  Wed Mar  5 14:22:57 2008
From: c-d.hailfinger.devel.2006 at gmx.net (Carl-Daniel Hailfinger)
Date: Wed, 05 Mar 2008 14:22:57 +0100
Subject: [coreboot] patch: set dbe62 to have com2 on com1 address
In-Reply-To: <13426df10803042151y6f1f1e3fn4c179c264669f044@mail.gmail.com>
References: <13426df10803042151y6f1f1e3fn4c179c264669f044@mail.gmail.com>
Message-ID: <47CE9EB1.2010704@gmx.net>

On 05.03.2008 06:51, ron minnich wrote:
> I still have no LPC dongle, but I am getting closer. I really liked
> this as it shows off the power of our new
> config system, the dts. There is a whole function in v2 to make com2
> operate at the com1 address. For v3, we just set
> a value in the mainboard dts and we're done (in theory ; I can't tell
> if this works). DBE62 is getting through a lot of POST
> btw but hangs at 13.
>
> I just realized this exampel also shows that you do NOT want all dts
> values to be visible in Kconfig.
> It would make no sense to change these
> values on the dbe62.
>
> Signed-off-by: Ronald G. Minnich <rminnich at gmail.com>
>   

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


> Index: mainboard/artecgroup/dbe62/dts
> ===================================================================
> --- mainboard/artecgroup/dbe62/dts      (revision 630)
> +++ mainboard/artecgroup/dbe62/dts      (working copy)
> @@ -43,6 +43,10 @@
>                         /* GPIO(0-0x20) for INT D:C:B:A, 0xFF=none.
>                          * See virtual PIC spec. */
>                         enable_gpio_int_route = "0x0D0C0700";
> +                       /* we use com2 since that is on the dongle */
>   

Uppercase the W in "we"?

> +                       com2_enable = "1";
> +                       /* Set com2 address to be COM1 */
> +                       com2_address = "0x3f8";
>                 };
>         };
>  };
>   

If you look at the dbe61 dts, you can see the same settings except that 
dbe61 additionally sets com2_irq = "4".

Regards,
Carl-Daniel

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




From c-d.hailfinger.devel.2006 at gmx.net  Wed Mar  5 14:38:54 2008
From: c-d.hailfinger.devel.2006 at gmx.net (Carl-Daniel Hailfinger)
Date: Wed, 05 Mar 2008 14:38:54 +0100
Subject: [coreboot] [PATCH] more fake SPD debugging
In-Reply-To: <13426df10803042223j425b7e39jf071ca211d7106bd@mail.gmail.com>
References: <13426df10803042223j425b7e39jf071ca211d7106bd@mail.gmail.com>
Message-ID: <47CEA26E.7090500@gmx.net>

On 05.03.2008 07:23, ron minnich wrote:
> attached. It dies and I'm sure it is bad ram settings, but it's a start.
>   

Yes. Try the following patch.

Add debugging to fake SPD read functions. We want to know when we try to 
read from a nonexisting member of the fake SPD.

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

Index: LinuxBIOSv3-spd_debug/mainboard/artecgroup/dbe61/initram.c
===================================================================
--- LinuxBIOSv3-spd_debug/mainboard/artecgroup/dbe61/initram.c	(Revision 631)
+++ LinuxBIOSv3-spd_debug/mainboard/artecgroup/dbe61/initram.c	(Arbeitskopie)
@@ -97,7 +97,7 @@
 	/* returns 0xFF on any failures */
 	u8 ret = 0xff;
 
-	printk(BIOS_DEBUG, "spd_read_byte dev %04x\n", device);
+	printk(BIOS_DEBUG, "spd_read_byte dev %04x", device);
 	if (device == DIMM0) {
 		for (i = 0; i < ARRAY_SIZE(spd_table); i++) {
 			if (spd_table[i].address == address) {
@@ -105,6 +105,9 @@
 			}
 		}
 	}
+	if (i == ARRAY_SIZE(spd_table))
+		printk(BIOS_DEBUG, " addr %02x does not exist in SPD table",
+			address);
 
 	printk(BIOS_DEBUG, " addr %02x returns %02x\n", address, ret);
 	return ret;
Index: LinuxBIOSv3-spd_debug/mainboard/artecgroup/dbe62/initram.c
===================================================================
--- LinuxBIOSv3-spd_debug/mainboard/artecgroup/dbe62/initram.c	(Revision 631)
+++ LinuxBIOSv3-spd_debug/mainboard/artecgroup/dbe62/initram.c	(Arbeitskopie)
@@ -87,7 +87,7 @@
 	/* returns 0xFF on any failures */
 	u8 ret = 0xff;
 
-	printk(BIOS_DEBUG, "spd_read_byte dev %04x\n", device);
+	printk(BIOS_DEBUG, "spd_read_byte dev %04x", device);
 	if (device == DIMM0) {
 		for (i = 0; i < ARRAY_SIZE(spd_table); i++) {
 			if (spd_table[i].address == address) {
@@ -95,6 +95,9 @@
 			}
 		}
 	}
+	if (i == ARRAY_SIZE(spd_table))
+		printk(BIOS_DEBUG, " addr %02x does not exist in SPD table",
+			address);
 
 	printk(BIOS_DEBUG, " addr %02x returns %02x\n", address, ret);
 	return ret;
Index: LinuxBIOSv3-spd_debug/mainboard/pcengines/alix1c/initram.c
===================================================================
--- LinuxBIOSv3-spd_debug/mainboard/pcengines/alix1c/initram.c	(Revision 631)
+++ LinuxBIOSv3-spd_debug/mainboard/pcengines/alix1c/initram.c	(Arbeitskopie)
@@ -97,7 +97,7 @@
 	/* returns 0xFF on any failures */
 	u8 ret = 0xff;
 
-	printk(BIOS_DEBUG, "spd_read_byte dev %04x\n", device);
+	printk(BIOS_DEBUG, "spd_read_byte dev %04x", device);
 	if (device == DIMM0) {
 		for (i = 0; i < ARRAY_SIZE(spd_table); i++) {
 			if (spd_table[i].address == address) {
@@ -105,6 +105,9 @@
 			}
 		}
 	}
+	if (i == ARRAY_SIZE(spd_table))
+		printk(BIOS_DEBUG, " addr %02x does not exist in SPD table",
+			address);
 
 	printk(BIOS_DEBUG, " addr %02x returns %02x\n", address, ret);
 	return ret;


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




From c-d.hailfinger.devel.2006 at gmx.net  Wed Mar  5 14:49:12 2008
From: c-d.hailfinger.devel.2006 at gmx.net (Carl-Daniel Hailfinger)
Date: Wed, 05 Mar 2008 14:49:12 +0100
Subject: [coreboot] first output: dbe62 and v3
In-Reply-To: <13426df10803042223j425b7e39jf071ca211d7106bd@mail.gmail.com>
References: <13426df10803042223j425b7e39jf071ca211d7106bd@mail.gmail.com>
Message-ID: <47CEA4D8.8080405@gmx.net>

On 05.03.2008 07:23, ron minnich wrote:
> One thing I plan to change pretty soon: power button control can move
> from stage1 to stage2,

That depends on your goals. We once discussed how to fail over to a 
initram/stage2/payload downloaded via serial. That can take a lot of 
time. I seem to remember that some power button control on some Geode 
boards has to be done in the first 4 seconds after poweron. That timing 
constraint will bite us when downloading over serial. Of course, if I'm 
wrong (or we can perform failsafe powerbutton control in stage 1), 
discard my objection.

>  and power button control will be managed in dts
> (another dts setting we would NOT want visible in Kconfig; you could
> render a board totally unbootable and unrepairable with the wrong
> setting. Kconfig should be for settings that are safe to change).
>   

We currently abuse Kconfig for settings which should be available 
before/outside stage2, iow when the device tree is not available. 
Depending on our design stategy, we may want to generate a subset of the 
device tree as #defines suitable for inclusion outside stage2.

> There are other things in stage1 for the lx that we should try to move
> to stage 2:
>         cs5536_setup_extmsr();
>         cs5536_setup_cis_mode();
>
>         msr = rdmsr(GLCP_SYS_RSTPLL);
>         if (msr.lo & (0x3f << 26)) {
>                 /* PLL is already set and we are reboot from PLL reset. */
>                 return;
>         }
>
>         cs5536_setup_idsel();
>         cs5536_usb_swapsif();
>         cs5536_setup_iobase();
>         cs5536_setup_smbus_gpio();
>         /* cs5536_enable_smbus(); -- Leave this out for now. */
> //      cs5536_setup_power_button();
>
>
> how much of this do we want managed in stage1? How much is unchanging,
> board to board? How much MUST be there? Really, a lot is going on;
> what can we leave to stage 2. Power button for sure; what else?
>   

I'd say anything which is neither time-critical (in the sense of time 
after poweron) nor essential for emergency initram+stage2 downloads over 
serial/usbdebug nor a ROM access/execution speedup can move to stage2 
phase 1.

> And how do we parameterize this? Just pass in a set of booleans for
> those things we wish to control (e.g. smbus).
>   

See my device tree subset generation idea above.

> At this rate, carl-daniel, we may soon have another board for your list.
>   

Nice.

Regards,
Carl-Daniel

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




From c-d.hailfinger.devel.2006 at gmx.net  Wed Mar  5 14:52:47 2008
From: c-d.hailfinger.devel.2006 at gmx.net (Carl-Daniel Hailfinger)
Date: Wed, 05 Mar 2008 14:52:47 +0100
Subject: [coreboot] some thoughts on dts vs. Kconfig vs. makefiles vs.
 C	code
In-Reply-To: <13426df10803042108v25cc43ccm2d92ebc2e4b1ff8b@mail.gmail.com>
References: <13426df10802281040n4afcdce1p1af052b71ce556f1@mail.gmail.com>	<20080229153508.GA14418@cosmic.amd.com>
	<13426df10803042108v25cc43ccm2d92ebc2e4b1ff8b@mail.gmail.com>
Message-ID: <47CEA5AF.5080400@gmx.net>

On 05.03.2008 06:08, ron minnich wrote:
> On Fri, Feb 29, 2008 at 7:35 AM, Jordan Crouse <jordan.crouse at amd.com> wrote:
>
>   
>>  Excellent.  I feel compelled to chime in on behalf of buildrom.  The
>>  fewer files that we need to copy and/or modify from buildrom to
>>  coreboot-v3 to get what we need, the happier we will be.   If we find
>>  ourselves constantly changing values in the dts or in Makefiles, then
>>  that should be a really good clue that perhaps the value belongs in
>>  Kconfig instead.  I don't think anybody likes how we're doing configuration
>>  now - I look forward to being able to copy a single .config file in
>>  place, or, at the worst, being able to construct a single .config file
>>  with the changes we need.
>>     
>
> What would you change? Do you mean that the settings in the mainboard
> dts should be in a .config file?
>
> If we do that, we're going to need to make parsing the dts part of the
> make menuconfig process. Or did I miss the point?
>   

I think the dts already has override capabilities, so buildrom should be 
able to just supply another mainboard-level dts which only contains the 
settings you want to override in the mainboard dts.

Regards,
Carl-Daniel

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




From uwe at hermann-uwe.de  Wed Mar  5 15:13:56 2008
From: uwe at hermann-uwe.de (Uwe Hermann)
Date: Wed, 5 Mar 2008 15:13:56 +0100
Subject: [coreboot] Problems with VIA EPIA-ME6000
In-Reply-To: <2558.99.141.181.120.1204682698.squirrel@webmail1.hrnoc.net>
References: <200803031520.56570.klaus123@ibnoetzold.de>
	<200803041442.19732.klaus123@ibnoetzold.de>
	<20080304152323.GA1533@greenwood>
	<200803041710.41023.klaus123@ibnoetzold.de>
	<20080304162812.GB5787@greenwood>
	<2558.99.141.181.120.1204682698.squirrel@webmail1.hrnoc.net>
Message-ID: <20080305141356.GA18951@greenwood>

[Forwarding to list]

On Tue, Mar 04, 2008 at 09:04:58PM -0500, mercury at wirebros.com wrote:
> As we talk about images, do we need both of them (normal and fallback)?

No, fallback-only will also work. Normal-only does _not_ work.


> I managed to build working coreboot using fallback image only, no VGA bios.

Yep.


> The problem is that from power-up to first console log it takes roughly
> 10seconds. I never managed to build coreboot with both images (normal,
> fallback). Platform: EPIA MII-1.2GHz, 512MB ram.

Hm, should work, at least it does for many other boards. What was the
problem?


> Please also see my comment in patch below;
> 
> 
> 
> > On Tue, Mar 04, 2008 at 05:10:40PM +0100, Klaus Stammermann wrote:
> >> Here the diff:
> >> -----------------------------------------------------------------------------------------------------------------------------------
> >> Index: src/mainboard/via/epia-m/Options.lb
> >> ===================================================================
> >> --- src/mainboard/via/epia-m/Options.lb	(Revision 3086)
> >> +++ src/mainboard/via/epia-m/Options.lb	(Arbeitskopie)
> >> @@ -51,8 +51,8 @@
> >>  ###
> >>  ### Build options
> >>  ###
> >> -default CONFIG_PCI_ROM_RUN=0
> >> -default CONFIG_CONSOLE_VGA=0
> >> +default CONFIG_PCI_ROM_RUN=1
> >> +default CONFIG_CONSOLE_VGA=1
> >
> > Looks ok.
> >
> >
> >>  ##
> >>  ## Build code for the fallback boot
> >> Index: targets/via/epia-m/Config.lb
> >> ===================================================================
> >> --- targets/via/epia-m/Config.lb	(Revision 3086)
> >> +++ targets/via/epia-m/Config.lb	(Arbeitskopie)
> >> @@ -7,21 +7,21 @@
> >>  option  DEFAULT_CONSOLE_LOGLEVEL=8
> >>  option  CONFIG_CONSOLE_SERIAL8250=1
> >>
> >> -option ROM_SIZE=256*1024
> >> +option ROM_SIZE=(256*1024)-(64*1024)
> >
> > OK, assuming you have a 256KB ROM chip and your VGA BIOS is 64KB.
> 
> if it's less than 64k, do we pad it or adjust ROM_SIZE to be exactly
> 256k-vgabios?

You set ROM_SIZE to '(256*1024)-12345' if the VGA blob is exactly 12345
bytes, for example. No extra manual padding or such. But you prepend
the 12345 bytes big VGA blob to coreboot.rom later (to make it exactly
256KB big).


> >>  option HAVE_OPTION_TABLE=1
> >>  option CONFIG_ROM_PAYLOAD=1
> >>  option HAVE_FALLBACK_BOOT=1
> >>  #option CONFIG_COMPRESSED_PAYLOAD_NRV2B=1
> >> -option CONFIG_COMPRESSED_PAYLOAD_NRV2B=0
> >> +#option CONFIG_COMPRESSED_PAYLOAD_NRV2B=0
> >
> > Why?
> >
> >
> >>  ### Compute the location and size of where this firmware image
> >>  ### (coreboot plus bootloader) will live in the boot rom chip.
> >>  ###
> >> -option FALLBACK_SIZE=131072
> >> +option FALLBACK_SIZE=(96*1024)
> >
> what this parameter is for?
> where is it used?

Size of the fallback image.


> > Not sure about this. I'd rather not change it unless really necessary
> > (it isn't in this case, I think).
> >
> >
> >>  ## Coreboot C code runs at this location in RAM
> >>  option _RAMBASE=0x00004000
> >> @@ -31,18 +31,22 @@
> >>  #
> >>  romimage "normal"
> >>  	option USE_FALLBACK_IMAGE=0
> >> -#option ROM_IMAGE_SIZE=128*1024
> >> -	option ROM_IMAGE_SIZE=64*1024
> >> +#	option ROM_IMAGE_SIZE=(128*1024)-27312
> >> +	option ROM_IMAGE_SIZE=(96*1024)-27312
> >
> > This is wrong.
> >
> > ROM_IMAGE_SIZE is the maximum size the coreboot code can use (without
> > payload, without VGA ROM, etc).
> >
> > Something like 64*1024 is usually ok.
> We can use ROM_SECTION_SIZE to specify size of "normal" image, but we need
> to offset it using ROM_SECTION_OFFSET=vgabiossize so I believe you need to
> use these 2 variables.

Hm, I wouldn't do that. I don't think ROM_SECTION_SIZE is meant to be
modified, it's for internal use only.

For prepending VGA images, using a correct ROM_SIZE should be enough,
e.g. 'option ROM_SIZE=(256*1024)-(64*1024)' for a 64KB VGA image. If
that's not enough it's probably a bug in the build system/configuration.


> >
> >
> >> +#	option ROM_IMAGE_SIZE=0xc000
> >> +#	option ROM_SECTION_OFFSET=0x10000
> >> +#	option ROM_SECTION_SIZE=0x18000
> >>  	option COREBOOT_EXTRA_VERSION=".0-Normal"
> >> -	payload $(HOME)/svn/payload.elf
> >> +	payload $(HOME)/Entwicklung/LinuxBIOS/VIA-BIOS/filo.small.elf
> >
> > Never used $(HOME) here, but I assume it works? If not, try
> > /tmp/filo.elf and copy your payload there.
> >
> >
> >>  end
> >>
> >>  romimage "fallback"
> >>  	option USE_FALLBACK_IMAGE=1
> >> -	#option ROM_IMAGE_SIZE=128*1024
> >> -	option ROM_IMAGE_SIZE=60*1024
> >> +#	option ROM_IMAGE_SIZE=(128*1024)-27312
> >> +	option ROM_IMAGE_SIZE=(96*1024)-27312
> >
> > Also wrong, see above.
> Should this section be offset by 128k?

No, don't think so, will be done internally, you don't have to
manually fix it.


> or buildrom will take care of it?

Yes, but I think you mean 'targets/buildtarget'?


> 
> >
> >
> >> +#	option ROM_IMAGE_SIZE=0xc000
> >>  	option COREBOOT_EXTRA_VERSION=".0-Fallback"
> >> -	payload $(HOME)/svn/payload.elf
> >> +	payload $(HOME)/Entwicklung/LinuxBIOS/VIA-BIOS/filo.small.elf
> >>  end
> >>
> >>  buildrom ./coreboot.rom ROM_SIZE "normal" "fallback"
> >> -----------------------------------------------------------------------------------------------------------------------------------
> >
> >
> >> In an earlier version I changed Config.lb in src dir to get VGA BIOS.
> >> But now
> >> it isn't included. If it is important, I could post it later.
> >
> > Plese post it.
> >
> > But the above patch comes from an 'svn diff' at the top-level directory,
> > correct? I.e. all your current changes are in there?
> >
> >
> >> > Also, where did you get your VGA ROM from? Using which tools
> >> (awardeco,
> >> > amideco, phnxdeco, other)? How big is it exactly?
> >> >
> >> On http://www.coreboot.org/VGA_support at bottom there is a perl script.
> >> Using
> >> this I got my VGABIOS. This is 60416 bytes big
> >
> > OK. Which vendor BIOS does the board have? Can you use
> > awardeco/amideco/phnxdeco to get the VGA BIOS and compare it with the
> > one from the script? Just to be sure that worked fine...
> >
> >
> >> (optionsrom is 57344 bytes which I used at last).
> >
> > Huh, what's that? Where from?
> >
> >
> >> filo.small.elf is 27312 bytes big. So don't wonder what number this is.
> >
> > Are you sure this is ok? The smallest usable FILO I've used so far is
> > ca. 57 KB. Your 27 KB FILO looks _very_ small.
> >
> > Also, please use the latest version from
> >
> >  % svn co svn://coreboot.org/filo/trunk/filo-0.5
> >
> > Type 'make' (that will generate a Config file), then edit Config, then
> > type make again.


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



From c-d.hailfinger.devel.2006 at gmx.net  Wed Mar  5 15:15:33 2008
From: c-d.hailfinger.devel.2006 at gmx.net (Carl-Daniel Hailfinger)
Date: Wed, 05 Mar 2008 15:15:33 +0100
Subject: [coreboot] some thoughts on dts vs. Kconfig vs. makefiles vs.
 C	code
In-Reply-To: <20080229003941.4677.qmail@stuge.se>
References: <13426df10802281040n4afcdce1p1af052b71ce556f1@mail.gmail.com>
	<20080229003941.4677.qmail@stuge.se>
Message-ID: <47CEAB05.3010907@gmx.net>

On 29.02.2008 01:39, Peter Stuge wrote:
> Ron, awesome writeup! Thanks for putting it together so well!
>   

Indeed, thanks!


> On Thu, Feb 28, 2008 at 10:40:41AM -0800, ron minnich wrote:
>   
>> In general, control variables that are not intended to be changed,
>> and which can cause undetectable problems, should remain in C code.
>>     
>
> Disagree. Or - well - variables controlling _what_ exactly?
>   

If they are constant for all code, simply use one #define or declare the 
stuff as const for better type checking.


>> I am inclined to include Cache As Ram (CAR) settings here. CAR is
>> very tricky. It's easy to get it slightly wrong, and not know it. I
>> think CAR settings should, once they are right, remain hidden and
>> hard to adjust.
>>
>> DRAM timing that is fixed belongs here too.
>>     
>
> Code should be used for runtime logic. I have a huge issue of
> principle with code being used as data storage when there exists
> another good method intended specifically for the purpose.
> [...]
> Another is a compiler/linker that generates code which doesn't use a
> data segment for storage, but the code segment. Static initialized
> data is compiled into move instructions that copy data from code at
> runtime.
>   

Move instructions shouldn't happen if the data is declared const.


>> dts should be used for control variables that are per-mainboard.
>>     
>
> Yes! I equate this with specifics of the hardware design. What is
> connected where and in cases where it matters also how it is
> connected. For example how interrupts are routed to PCI slots, if
> those four muxed signals on the sobridge are used for COM2 or SATA
> on this board, and the timing compensation constant that is needed
> for the particular series resistance to RAM on this board. (for MCs
> that have such settings.)
>   

What about per-mainboard settings which are totally uninteresting to 
stage2 and payload?


>> The dts variables are currently usually static for a given
>> mainboard, since they reflect the hardware of the mainboard.
>>     
>
> Yep.
>
>   
>> The device tree compiler compiles dts down to C code for use by the
>> image. Currently this code is initialized structures and a .h file
>> with type definitions.
>>     
>
> I agree 100% with you on the dts, but I think your reasoning around
> the C code goes against it. :\
>
>   
>> Kconfig should rarely, if ever, be used to set device options that
>> belong in the dts; or, set very low level build options such as
>> DRAM timing.
>>     
>
> It may be tempting to add (invisble) data into Kconfig. This is
> presumably because it is simple to create dependencies and easy
> to access in code.
>
> That would be a testament to dts not being easy enough to deal with.
>   

We already have invisible data in Kconfig because we need to access that 
data when the device tree is not yet available. CARBASE is an example of 
that. It is constant for a given subarch, but also used by the generic 
printk code (and that code is not subarch-specific).

I wrote this in another thread:

We currently abuse Kconfig for settings which should be available 
before/outside stage2, iow when the device tree is not available. 
Depending on our design stategy, we may want to generate a subset of the 
device tree as #defines suitable for inclusion outside stage2.


Regards,
Carl-Daniel

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




From svn at coreboot.org  Wed Mar  5 15:51:35 2008
From: svn at coreboot.org (svn at coreboot.org)
Date: Wed,  5 Mar 2008 15:51:35 +0100
Subject: [coreboot] r632 - coreboot-v3/util/lar
Message-ID: <mailman.1250.1355071275.16123.coreboot@coreboot.org>

Author: myles
Date: 2008-03-05 15:51:35 +0100 (Wed, 05 Mar 2008)
New Revision: 632

Modified:
   coreboot-v3/util/lar/lar.c
   coreboot-v3/util/lar/stream.c
Log:
This patch fixes lar options parsing, a seg fault with long path names, and
makes use of functions that were already defined.  It also adds greedy name
matching for listing and extracting archives, which allows recursive descent
into the lar directory structure.

changes file-by-file:

util/lar/lar.c:
	add more options to the usage message
	use get_larsize() instead of using larsize
	rearrange errors from parsing args to be more correct

util/lar/stream.c:
	change elfname size to MAX_PATHLEN instead of 64
	make file_in_list greedy with filename matches
	change total_size calculation to include file names
	change lar_add_entry to use header_len function instead of reinventing

Signed-off-by: Myles Watson <mylesgw at gmail.com>
Acked-by: Ronald G. Minnich <rminnich at gmail.com>



Modified: coreboot-v3/util/lar/lar.c
===================================================================
--- coreboot-v3/util/lar/lar.c	2008-03-05 12:57:10 UTC (rev 631)
+++ coreboot-v3/util/lar/lar.c	2008-03-05 14:51:35 UTC (rev 632)
@@ -44,8 +44,9 @@
 
 static void usage(char *name)
 {
-	printf("\nLAR - the Lightweight Archiver " VERSION "\n" COPYRIGHT "\n\n"
-	       "Usage: %s [-ecxal] archive.lar [[[file1] file2] ...]\n\n", name);
+	printf("\nLAR - the Lightweight Archiver " VERSION "\n" COPYRIGHT "\n\n");
+	printf("Usage: %s [-ecxal] archive.lar [-b NAME] [-s SIZE[M|k]]\n",name);
+	printf("\t[[[file1] file2] ...]\n\n");
 	printf("Examples:\n");
 	printf("  lar -c -s 32k -b bootblock myrom.lar foo nocompress:bar\n");
 	printf("  lar -a myrom.lar foo blob:baz\n");
@@ -121,7 +122,7 @@
 
 int create_lar(const char *archivename, struct file *files)
 {
-	struct lar *lar = lar_new_archive(archivename, larsize);
+	struct lar *lar = lar_new_archive(archivename, get_larsize());
 
 	if (lar == NULL) {
 		fprintf(stderr, "Unable to create %s as a LAR archive.\n",
@@ -343,24 +344,21 @@
 	}
 
 	/* size only makes sense when creating a lar */
-	if (larmode != CREATE && larsize) {
+	if (larmode != CREATE && get_larsize()) {
 		printf("Warning: size parameter ignored since "
 		       "not creating an archive.\n");
 	}
 
-	if (bootblock) {
+	if (larmode == CREATE && !get_larsize()) {
+		printf("When creating a LAR archive, "
+			"you must specify an archive size.\n");
+		exit(1);
+	}
 
-		/* adding a bootblock only makes sense when creating a lar */
-		if (larmode != CREATE) {
-			printf("Warning: bootblock parameter ignored since "
-			       "not creating an archive.\n");
-		}
-
-		/* adding a bootblock only makes sense when creating a lar */
-		if (!larsize) {
-			printf("When creating a LAR archive, you must specify an archive size.\n");
-			exit(1);
-		}
+	/* adding a bootblock only makes sense when creating a lar */
+	if (bootblock && larmode != CREATE) {
+		printf("Warning: bootblock parameter ignored since "
+		       "not creating an archive.\n");
 	}
 
 	if (optind < argc) {

Modified: coreboot-v3/util/lar/stream.c
===================================================================
--- coreboot-v3/util/lar/stream.c	2008-03-05 12:57:10 UTC (rev 631)
+++ coreboot-v3/util/lar/stream.c	2008-03-05 14:51:35 UTC (rev 632)
@@ -82,7 +82,7 @@
 	int size;
 	int segment = 0;
 	char *header;
-	char ename[64];
+	char ename[MAX_PATHLEN];
 	int headers;
 	char *temp;
 	enum compalgo thisalgo;
@@ -529,7 +529,7 @@
 		return 1;
 
 	for(p = files ; p; p = p->next) {
-		if (!strcmp(p->name, filename))
+		if (!strncmp(p->name, filename, strlen(p->name)))
 			return 1;
 	}
 
@@ -560,17 +560,17 @@
 			break;
 
 		filename = (char *) (ptr + sizeof(struct lar_header));
-		total_size += sizeof(struct lar_header);
 
 		if (file_in_list(files, filename)) {
 			printf("  %s ", filename);
+			total_size += ntohl(header->offset);
+			total_size += ntohl(header->len);
 
 			if (ntohl(header->compression) == ALGO_NONE) {
 				printf("(%d bytes @0x%lx);",
 				       ntohl(header->len),
 				       (unsigned long)(ptr - lar->map) +
 				       ntohl(header->offset));
-				total_size += ntohl(header->len);
 			} else {
 				printf("(%d bytes, %s compressed to %d bytes "
 				       "@0x%lx);",
@@ -579,7 +579,6 @@
 				       ntohl(header->len),
 				       (unsigned long)(ptr - lar->map) +
 				       ntohl(header->offset));
-				total_size += ntohl(header->len);
 			}
 			printf("loadaddress 0x%#x entry 0x%#x\n", 
 					ntohl(header->loadaddress), 
@@ -603,8 +602,11 @@
 	}
 
 	/* Print the total size */
-	printf ("Total size = %d bytes (0x%x)\n", total_size, total_size);
-	
+	if (total_size >0)
+		printf("Total size = %dB %dKB (0x%x)\n", 
+			total_size, total_size/1024, total_size);
+	else
+		printf("No matching lar entries found.\n");
 }
 
 /**
@@ -797,9 +799,10 @@
  * Given a name, return the size of the header for that name.  
  * 
  * @param name header name
+ * @param new_pathlen pointer to the (possibly truncated) pathlen
  * @return  header size
  */
-int hlen(char *pathname)
+int header_len(char *pathname, int *new_pathlen)
 {
 	int pathlen;
 	int len;
@@ -808,6 +811,8 @@
 		MAX_PATHLEN : strlen(pathname) + 1;
 	len = sizeof(struct lar_header) + pathlen;
 	len = (len + 15) & 0xFFFFFFF0;
+	if (new_pathlen!=NULL)
+		*new_pathlen = pathlen;
 
 	return len;
 }
@@ -827,7 +832,7 @@
 	offset = lar_empty_offset(lar);
 
 	/* Figure out how big our header will be */
-	size = get_bootblock_offset(lar->size) - offset - hlen(name) - 1;
+	size = get_bootblock_offset(lar->size) - offset - header_len(name,NULL) - 1;
 
 	return size;
 }
@@ -878,12 +883,8 @@
 	/* Find the beginning of the available space in the LAR */
 	offset = lar_empty_offset(lar);
 
-	pathlen = strlen(pathname) + 1 > MAX_PATHLEN ? 
-		MAX_PATHLEN : strlen(pathname) + 1;
-
 	/* Figure out how big our header will be */
-	hlen = sizeof(struct lar_header) + pathlen;
-	hlen = (hlen + 15) & 0xFFFFFFF0;
+	hlen = header_len(pathname, &pathlen);
 
 	if (offset + hlen + complen >= get_bootblock_offset(lar->size)) {
 		err("Not enough room in the LAR to add the file.\n");




From c-d.hailfinger.devel.2006 at gmx.net  Wed Mar  5 15:51:26 2008
From: c-d.hailfinger.devel.2006 at gmx.net (Carl-Daniel Hailfinger)
Date: Wed, 05 Mar 2008 15:51:26 +0100
Subject: [coreboot] some thoughts on dts vs. Kconfig vs. makefiles vs. C
 code
In-Reply-To: <13426df10802281040n4afcdce1p1af052b71ce556f1@mail.gmail.com>
References: <13426df10802281040n4afcdce1p1af052b71ce556f1@mail.gmail.com>
Message-ID: <47CEB36E.4010004@gmx.net>

On 28.02.2008 19:40, ron minnich wrote:
> I have no idea if this helps. But there's been discussion of "DRAM
> settings in DTS" and "where does CARBASE go" and so on, so I think we
> need to try to document some rules. Here is a first cut.
>
> [...]
> Kconfig
>
> Kconfig has two uses. First, Kconfig is used to select a mainboard and
> set build options for the mainboard, e.g. whether compression is used or
> not. Kconfig can also set runtime parameters, such as baud rate for the
> console. Kconfig should rarely, if ever, be used to set device options
> that belong in the dts;

There is a problem with that approach. I disagree that baud rate for the 
console is different from the address of the serial port when you 
consider their scope. So it does not make sense to have one in Kconfig 
and one in the dts. Sure, the baud rate is going to be changed more 
often, but the amount of change a variable is going to see during 
configuration is not a consideration of the dts/Kconfig placing decision 
yet.

The address of the serial port is the poster child for how complicated 
the interaction between Kconfig and code and dts is:
mainboard/pcengines/alix1c/stage1.c:#define SERIAL_IOBASE 0x3f8
superio/winbond/w83627hf/dts: com1io = "0x3f8";
We need the #define in stage1 code because we have to access to the 
device tree yet. However, we also store the value in the dts. We also 
could place this in Kconfig (I'm against that) and control this centrally.

How about a way to mark a dts property "must be available as #define in 
stage1"?

Regards,
Carl-Daniel

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




From mylesgw at gmail.com  Wed Mar  5 15:52:58 2008
From: mylesgw at gmail.com (Myles Watson)
Date: Wed, 5 Mar 2008 07:52:58 -0700
Subject: [coreboot] A lar patch with some cleanup and adding greedy name
	matching
In-Reply-To: <13426df10803041727g7df7c7eegbacdac802c6970d0@mail.gmail.com>
References: <2831fecf0802291214v5bd251f0q969805178da37ad@mail.gmail.com>
	<010201c87e51$9f7a6af0$b522040a@chimp>
	<13426df10803041727g7df7c7eegbacdac802c6970d0@mail.gmail.com>
Message-ID: <2831fecf0803050652v6181d5e1s9bfa40cedc52fa7a@mail.gmail.com>

On Tue, Mar 4, 2008 at 6:27 PM, ron minnich <rminnich at gmail.com> wrote:
> On Tue, Mar 4, 2008 at 3:44 PM, Myles Watson <mylesgw at gmail.com> wrote:
>  >
>  >  Ping.
>  >
>
>  I just did a test build with this and tested under qemu and it works
>  fine. I don't see how it could cause alix1c troubles so I'm acking it.
>
>  Acked-by: Ronald G. Minnich <rminnich at gmail.com>
>

Rev 632.

Thanks,
Myles



From c-d.hailfinger.devel.2006 at gmx.net  Wed Mar  5 16:04:21 2008
From: c-d.hailfinger.devel.2006 at gmx.net (Carl-Daniel Hailfinger)
Date: Wed, 05 Mar 2008 16:04:21 +0100
Subject: [coreboot] [PATCH] v3: move statictree.h to
	build/mainboard/$vendor/$board/
In-Reply-To: <13426df10802210807m770a24dauc162c5cf1a74139b@mail.gmail.com>
References: <47BD8269.1010909@gmx.net>
	<13426df10802210807m770a24dauc162c5cf1a74139b@mail.gmail.com>
Message-ID: <47CEB675.1030103@gmx.net>

On 21.02.2008 17:07, ron minnich wrote:
> On thing I know for sure: statictree.h is in the wrong place. it is in
> build, and needs to be in build/mainboard/abcd/xyz
>   
Move statictree.h to build/mainboard/$vendor/$board/.

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

Index: LinuxBIOSv3-makefiledependencies/Rules.make
===================================================================
--- LinuxBIOSv3-makefiledependencies/Rules.make	(Revision 631)
+++ LinuxBIOSv3-makefiledependencies/Rules.make	(Arbeitskopie)
@@ -23,7 +23,7 @@
 # Miscellaneous mainboard specific build targets!
 #
 
-$(obj)/mainboard/$(MAINBOARDDIR)/statictree.o: $(obj)/mainboard/$(MAINBOARDDIR)/statictree.c $(obj)/statictree.h
+$(obj)/mainboard/$(MAINBOARDDIR)/statictree.o: $(obj)/mainboard/$(MAINBOARDDIR)/statictree.c $(obj)/mainboard/$(MAINBOARDDIR)/statictree.h
 	$(Q)printf "  CC      $(subst $(shell pwd)/,,$(@))\n"
 	$(Q)$(CC) $(INITCFLAGS) $(COREBOOTINCLUDE) -c -o $@ $<
 
@@ -31,7 +31,7 @@
 	$(Q)printf "  DTC     $(subst $(shell pwd)/,,$(@))\n"
 	$(Q)$(obj)/util/dtc/dtc -O lb mainboard/$(MAINBOARDDIR)/dts > $@
 
-$(obj)/statictree.h: $(src)/mainboard/$(MAINBOARDDIR)/dts $(obj)/util/dtc/dtc
+$(obj)/mainboard/$(MAINBOARDDIR)/statictree.h: $(src)/mainboard/$(MAINBOARDDIR)/dts $(obj)/util/dtc/dtc
 	$(Q)printf "  DTC     $(subst $(shell pwd)/,,$(@))\n"
 	$(Q)$(obj)/util/dtc/dtc -O lbh mainboard/$(MAINBOARDDIR)/dts > $@
 
@@ -55,7 +55,7 @@
 # Miscellaneous superio specific build targets!
 #
 
-$(obj)/superio/%.o: $(src)/superio/%.c $(obj)/statictree.h
+$(obj)/superio/%.o: $(src)/superio/%.c $(obj)/mainboard/$(MAINBOARDDIR)/statictree.h
 	$(Q)mkdir -p $(dir $@)
 	$(Q)printf "  CC      $(subst $(shell pwd)/,,$(@))\n"
 	$(Q)$(CC) $(INITCFLAGS) -c $< -o $@
@@ -64,7 +64,7 @@
 # Miscellaneous northbridge specific build targets!
 #
 
-$(obj)/northbridge/%.o: $(src)/northbridge/%.c $(obj)/statictree.h
+$(obj)/northbridge/%.o: $(src)/northbridge/%.c $(obj)/mainboard/$(MAINBOARDDIR)/statictree.h
 	$(Q)mkdir -p $(dir $@)
 	$(Q)printf "  CC      $(subst $(shell pwd)/,,$(@))\n"
 	$(Q)$(CC) $(INITCFLAGS) -c $< -o $@
@@ -73,7 +73,7 @@
 # Miscellaneous southbridge specific build targets!
 #
 
-$(obj)/southbridge/%.o: $(src)/southbridge/%.c $(obj)/statictree.h
+$(obj)/southbridge/%.o: $(src)/southbridge/%.c $(obj)/mainboard/$(MAINBOARDDIR)/statictree.h
 	$(Q)mkdir -p $(dir $@)
 	$(Q)printf "  CC      $(subst $(shell pwd)/,,$(@))\n"
 	$(Q)$(CC) $(INITCFLAGS) -c $< -o $@
Index: LinuxBIOSv3-makefiledependencies/northbridge/intel/i440bxemulation/i440bx.c
===================================================================
--- LinuxBIOSv3-makefiledependencies/northbridge/intel/i440bxemulation/i440bx.c	(Revision 631)
+++ LinuxBIOSv3-makefiledependencies/northbridge/intel/i440bxemulation/i440bx.c	(Arbeitskopie)
@@ -44,7 +44,7 @@
 #include <device/pci.h>
 #include <string.h>
 #include "i440bx.h"
-#include "statictree.h"
+#include <statictree.h>
 
 /* Here are the ops for 440BX as a PCI domain. */
 
Index: LinuxBIOSv3-makefiledependencies/Makefile
===================================================================
--- LinuxBIOSv3-makefiledependencies/Makefile	(Revision 631)
+++ LinuxBIOSv3-makefiledependencies/Makefile	(Arbeitskopie)
@@ -86,6 +86,7 @@
 			-I$(src)/include \
 			-I$(src)/include/arch/$(ARCH)/ \
 			-I$(src)/mainboard/$(MAINBOARDDIR)/ \
+			-I$(obj)/mainboard/$(MAINBOARDDIR)/ \
 			-include $(obj)/config.h \
 			-include $(obj)/build.h
 


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




From rminnich at gmail.com  Wed Mar  5 16:49:57 2008
From: rminnich at gmail.com (ron minnich)
Date: Wed, 5 Mar 2008 07:49:57 -0800
Subject: [coreboot] [PATCH] v3: move statictree.h to
	build/mainboard/$vendor/$board/
In-Reply-To: <47CEB675.1030103@gmx.net>
References: <47BD8269.1010909@gmx.net>
	<13426df10802210807m770a24dauc162c5cf1a74139b@mail.gmail.com>
	<47CEB675.1030103@gmx.net>
Message-ID: <13426df10803050749l3a7c3c38p678fbbf98de1783f@mail.gmail.com>

So, the real test here: can I build all the different targets without
removing any other targets first?

thanks

ron



From rminnich at gmail.com  Wed Mar  5 16:53:50 2008
From: rminnich at gmail.com (ron minnich)
Date: Wed, 5 Mar 2008 07:53:50 -0800
Subject: [coreboot] some thoughts on dts vs. Kconfig vs. makefiles vs. C
	code
In-Reply-To: <47CEB36E.4010004@gmx.net>
References: <13426df10802281040n4afcdce1p1af052b71ce556f1@mail.gmail.com>
	<47CEB36E.4010004@gmx.net>
Message-ID: <13426df10803050753h52f8030fjfeee5b678ff8b4e6@mail.gmail.com>

On Wed, Mar 5, 2008 at 6:51 AM, Carl-Daniel Hailfinger
<c-d.hailfinger.devel.2006 at gmx.net> wrote:

>  How about a way to mark a dts property "must be available as #define in
>  stage1"?

not sure. statictree.c in stage 1? Then we bring in all that mechanism.

Think think ... not sure

ron



From rminnich at gmail.com  Wed Mar  5 16:53:50 2008
From: rminnich at gmail.com (ron minnich)
Date: Wed, 5 Mar 2008 07:53:50 -0800
Subject: [coreboot] some thoughts on dts vs. Kconfig vs. makefiles vs. C
	code
In-Reply-To: <47CEB36E.4010004@gmx.net>
References: <13426df10802281040n4afcdce1p1af052b71ce556f1@mail.gmail.com>
	<47CEB36E.4010004@gmx.net>
Message-ID: <13426df10803050753h52f8030fjfeee5b678ff8b4e6@mail.gmail.com>

On Wed, Mar 5, 2008 at 6:51 AM, Carl-Daniel Hailfinger
<c-d.hailfinger.devel.2006 at gmx.net> wrote:

>  How about a way to mark a dts property "must be available as #define in
>  stage1"?

not sure. statictree.c in stage 1? Then we bring in all that mechanism.

Think think ... not sure

ron



From rminnich at gmail.com  Wed Mar  5 16:58:03 2008
From: rminnich at gmail.com (ron minnich)
Date: Wed, 5 Mar 2008 07:58:03 -0800
Subject: [coreboot] first output: dbe62 and v3
In-Reply-To: <47CEA4D8.8080405@gmx.net>
References: <13426df10803042223j425b7e39jf071ca211d7106bd@mail.gmail.com>
	<47CEA4D8.8080405@gmx.net>
Message-ID: <13426df10803050758t292ea76fpfe5737a691cc44ea@mail.gmail.com>

On Wed, Mar 5, 2008 at 5:49 AM, Carl-Daniel Hailfinger
<c-d.hailfinger.devel.2006 at gmx.net> wrote:

>  That depends on your goals. We once discussed how to fail over to a
>  initram/stage2/payload downloaded via serial. That can take a lot of
>  time. I seem to remember that some power button control on some Geode
>  boards has to be done in the first 4 seconds after poweron. That timing
>  constraint will bite us when downloading over serial. Of course, if I'm
>  wrong (or we can perform failsafe powerbutton control in stage 1),
>  discard my objection.

right, but the enable ENABLES the timeout. Safest thing to do is wait
until stage 2 at least to enable such things. I.e. later.

Although I see your point now. Sigh. mainboard_pre_payload?

We're finding that the device tree needs to span stage1 to
mainboard_pre_payload, now. We had not planned for this. We're going
to have to rethink it a bit.

If we do this it will clean a lot of things up.

Good work for denver.

ron



From rminnich at gmail.com  Wed Mar  5 17:01:08 2008
From: rminnich at gmail.com (ron minnich)
Date: Wed, 5 Mar 2008 08:01:08 -0800
Subject: [coreboot] patch: set dbe62 to have com2 on com1 address
In-Reply-To: <47CE9EB1.2010704@gmx.net>
References: <13426df10803042151y6f1f1e3fn4c179c264669f044@mail.gmail.com>
	<47CE9EB1.2010704@gmx.net>
Message-ID: <13426df10803050801k7b716f91k3feead1d8f3ce970@mail.gmail.com>

On Wed, Mar 5, 2008 at 5:22 AM, Carl-Daniel Hailfinger
<c-d.hailfinger.devel.2006 at gmx.net> wrote:

>  If you look at the dbe61 dts, you can see the same settings except that
>  dbe61 additionally sets com2_irq = "4".

and there is a good question. I might have misread the v2 code, I will
have to go back and check.

But will com2 still interrupt on irq 3 no matter what? I'm never sure
how things go on this chipset.

ron



From c-d.hailfinger.devel.2006 at gmx.net  Wed Mar  5 17:03:11 2008
From: c-d.hailfinger.devel.2006 at gmx.net (Carl-Daniel Hailfinger)
Date: Wed, 05 Mar 2008 17:03:11 +0100
Subject: [coreboot] some thoughts on dts vs. Kconfig vs. makefiles vs. C
 code
In-Reply-To: <13426df10803050753h52f8030fjfeee5b678ff8b4e6@mail.gmail.com>
References: <13426df10802281040n4afcdce1p1af052b71ce556f1@mail.gmail.com>	
	<47CEB36E.4010004@gmx.net>
	<13426df10803050753h52f8030fjfeee5b678ff8b4e6@mail.gmail.com>
Message-ID: <47CEC43F.8010307@gmx.net>

On 05.03.2008 16:53, ron minnich wrote:
> On Wed, Mar 5, 2008 at 6:51 AM, Carl-Daniel Hailfinger wrote:
>   
>>  How about a way to mark a dts property "must be available as #define in
>>  stage1"?
>>     
>
> not sure. statictree.c in stage 1? Then we bring in all that mechanism.
>   

No, not the tree mechanism. I was thinking more a long the lines of 
another dtc output mode which creates a flat .h file which has no 
structure, but contains all specially marked dts properties as #define.

> Think think ... not sure
>   

I hope I clarified this. statictree.c in stage 1 would indeed be a bad idea.

Regards,
Carl-Daniel

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




From c-d.hailfinger.devel.2006 at gmx.net  Wed Mar  5 17:06:58 2008
From: c-d.hailfinger.devel.2006 at gmx.net (Carl-Daniel Hailfinger)
Date: Wed, 05 Mar 2008 17:06:58 +0100
Subject: [coreboot] first output: dbe62 and v3
In-Reply-To: <13426df10803050758t292ea76fpfe5737a691cc44ea@mail.gmail.com>
References: <13426df10803042223j425b7e39jf071ca211d7106bd@mail.gmail.com>	
	<47CEA4D8.8080405@gmx.net>
	<13426df10803050758t292ea76fpfe5737a691cc44ea@mail.gmail.com>
Message-ID: <47CEC522.6000501@gmx.net>

On 05.03.2008 16:58, ron minnich wrote:
> On Wed, Mar 5, 2008 at 5:49 AM, Carl-Daniel Hailfinger
> <c-d.hailfinger.devel.2006 at gmx.net> wrote:
>   
>>  That depends on your goals. We once discussed how to fail over to a
>>  initram/stage2/payload downloaded via serial. That can take a lot of
>>  time. I seem to remember that some power button control on some Geode
>>  boards has to be done in the first 4 seconds after poweron. That timing
>>  constraint will bite us when downloading over serial. Of course, if I'm
>>  wrong (or we can perform failsafe powerbutton control in stage 1),
>>  discard my objection.
>>     
>
> right, but the enable ENABLES the timeout. Safest thing to do is wait
> until stage 2 at least to enable such things. I.e. later.
>   

OK, then I'm totally fine doing all the powerbutton handling in stage2.

> Although I see your point now. Sigh. mainboard_pre_payload?
>   

I'd simply decide on a phase in stage2 where all this happens (except 
time-critical stuff).

> We're finding that the device tree needs to span stage1 to
> mainboard_pre_payload, now. We had not planned for this. We're going
> to have to rethink it a bit.
>   

See my other mail from 5 minutes ago for a possible solution for that 
problem.

> If we do this it will clean a lot of things up.
>   

And the bootblock will grow a lot. I'd still like to avoid device tree 
handling in stage 1 and initram.

> Good work for denver.
>   

Speaking of Denver, how many people have confirmed to come?

Regards,
Carl-Daniel

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




From rminnich at gmail.com  Wed Mar  5 17:10:11 2008
From: rminnich at gmail.com (ron minnich)
Date: Wed, 5 Mar 2008 08:10:11 -0800
Subject: [coreboot] some thoughts on dts vs. Kconfig vs. makefiles vs. C
	code
In-Reply-To: <47CEC43F.8010307@gmx.net>
References: <13426df10802281040n4afcdce1p1af052b71ce556f1@mail.gmail.com>
	<47CEB36E.4010004@gmx.net>
	<13426df10803050753h52f8030fjfeee5b678ff8b4e6@mail.gmail.com>
	<47CEC43F.8010307@gmx.net>
Message-ID: <13426df10803050810u62fb6b68o3a3d7dc672bdfbe6@mail.gmail.com>

On Wed, Mar 5, 2008 at 8:03 AM, Carl-Daniel Hailfinger
<c-d.hailfinger.devel.2006 at gmx.net> wrote:

>  No, not the tree mechanism. I was thinking more a long the lines of
>  another dtc output mode which creates a flat .h file which has no
>  structure, but contains all specially marked dts properties as #define.

go ahead and propose a syntax, I'm very slow in the morning.

>  I hope I clarified this. statictree.c in stage 1 would indeed be a bad idea.

Ah, but would it. Look at the cs5536 startup code -- we don't
parameterize it yet. We need to.

We could do this: if there is a property in a node called "cpp", it is
a list of values in that node that should be emitted as #defines.
The names will be prefixed with the pathname of the dts, so
if we had
cpp = "com1enable";
we get (ugly)
SOUTHBRiDGE_AMD_CS5536_COM1ENABLE
or some such.

ron



From c-d.hailfinger.devel.2006 at gmx.net  Wed Mar  5 17:09:57 2008
From: c-d.hailfinger.devel.2006 at gmx.net (Carl-Daniel Hailfinger)
Date: Wed, 05 Mar 2008 17:09:57 +0100
Subject: [coreboot] patch: set dbe62 to have com2 on com1 address
In-Reply-To: <13426df10803050801k7b716f91k3feead1d8f3ce970@mail.gmail.com>
References: <13426df10803042151y6f1f1e3fn4c179c264669f044@mail.gmail.com>	
	<47CE9EB1.2010704@gmx.net>
	<13426df10803050801k7b716f91k3feead1d8f3ce970@mail.gmail.com>
Message-ID: <47CEC5D5.1060601@gmx.net>

On 05.03.2008 17:01, ron minnich wrote:
> On Wed, Mar 5, 2008 at 5:22 AM, Carl-Daniel Hailfinger
> <c-d.hailfinger.devel.2006 at gmx.net> wrote:
>
>   
>>  If you look at the dbe61 dts, you can see the same settings except that
>>  dbe61 additionally sets com2_irq = "4".
>>     
>
> and there is a good question. I might have misread the v2 code, I will
> have to go back and check.
>
> But will com2 still interrupt on irq 3 no matter what? I'm never sure
> how things go on this chipset.
>   

southbridge/amd/cs5536/cs5536.c: msr.lo |= sb->com2_irq << 28;
southbridge/amd/cs5536/dts:      com2_irq = "3";

The default is irq 3, can be overridden in the mainboard dts.

Regards,
Carl-Daniel

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




From rminnich at gmail.com  Wed Mar  5 17:11:41 2008
From: rminnich at gmail.com (ron minnich)
Date: Wed, 5 Mar 2008 08:11:41 -0800
Subject: [coreboot] first output: dbe62 and v3
In-Reply-To: <47CEC522.6000501@gmx.net>
References: <13426df10803042223j425b7e39jf071ca211d7106bd@mail.gmail.com>
	<47CEA4D8.8080405@gmx.net>
	<13426df10803050758t292ea76fpfe5737a691cc44ea@mail.gmail.com>
	<47CEC522.6000501@gmx.net>
Message-ID: <13426df10803050811x70d2c05fv36a9334bcc012d2a@mail.gmail.com>

On Wed, Mar 5, 2008 at 8:06 AM, Carl-Daniel Hailfinger
<c-d.hailfinger.devel.2006 at gmx.net> wrote:

>  Speaking of Denver, how many people have confirmed to come?

I will have to look. The checkbox for "linuxbios summit" was not
obvious to many people, so I don't have a good count.

It's amazing how hard it is to write a good web page. It makes me even
happier that the coreboot web page is so good.

ron



From c-d.hailfinger.devel.2006 at gmx.net  Wed Mar  5 17:31:06 2008
From: c-d.hailfinger.devel.2006 at gmx.net (Carl-Daniel Hailfinger)
Date: Wed, 05 Mar 2008 17:31:06 +0100
Subject: [coreboot] [PATCH] v3: move statictree.h
	to	build/mainboard/$vendor/$board/
In-Reply-To: <13426df10803050749l3a7c3c38p678fbbf98de1783f@mail.gmail.com>
References: <47BD8269.1010909@gmx.net>	<13426df10802210807m770a24dauc162c5cf1a74139b@mail.gmail.com>	<47CEB675.1030103@gmx.net>
	<13426df10803050749l3a7c3c38p678fbbf98de1783f@mail.gmail.com>
Message-ID: <47CECACA.6060601@gmx.net>

On 05.03.2008 16:49, ron minnich wrote:
> So, the real test here: can I build all the different targets without
> removing any other targets first?
>   

Not yet. There are more dependencies to fix, but it is a good start 
(less possible points of failure).

Regards,
Carl-Daniel

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




From marc.jones at amd.com  Wed Mar  5 17:33:59 2008
From: marc.jones at amd.com (Marc Jones)
Date: Wed, 05 Mar 2008 09:33:59 -0700
Subject: [coreboot] patch: set dbe62 to have com2 on com1 address
In-Reply-To: <13426df10803050801k7b716f91k3feead1d8f3ce970@mail.gmail.com>
References: <13426df10803042151y6f1f1e3fn4c179c264669f044@mail.gmail.com>	<47CE9EB1.2010704@gmx.net>
	<13426df10803050801k7b716f91k3feead1d8f3ce970@mail.gmail.com>
Message-ID: <47CECB77.8010001@amd.com>



ron minnich wrote:
> On Wed, Mar 5, 2008 at 5:22 AM, Carl-Daniel Hailfinger
> <c-d.hailfinger.devel.2006 at gmx.net> wrote:
> 
>>  If you look at the dbe61 dts, you can see the same settings except that
>>  dbe61 additionally sets com2_irq = "4".
> 
> and there is a good question. I might have misread the v2 code, I will
> have to go back and check.
> 
> But will com2 still interrupt on irq 3 no matter what? I'm never sure
> how things go on this chipset.
> 
> ron
> 

There is no chipset default. Each piece needs to be setup. If you didn't 
set it in the mainboard dts it will use the chipset dts default.
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 Mar  5 17:33:36 2008
From: c-d.hailfinger.devel.2006 at gmx.net (Carl-Daniel Hailfinger)
Date: Wed, 05 Mar 2008 17:33:36 +0100
Subject: [coreboot] some thoughts on dts vs. Kconfig vs. makefiles vs. C
 code
In-Reply-To: <13426df10803050810u62fb6b68o3a3d7dc672bdfbe6@mail.gmail.com>
References: <13426df10802281040n4afcdce1p1af052b71ce556f1@mail.gmail.com>	
	<47CEB36E.4010004@gmx.net>	
	<13426df10803050753h52f8030fjfeee5b678ff8b4e6@mail.gmail.com>	
	<47CEC43F.8010307@gmx.net>
	<13426df10803050810u62fb6b68o3a3d7dc672bdfbe6@mail.gmail.com>
Message-ID: <47CECB60.9060401@gmx.net>

On 05.03.2008 17:10, ron minnich wrote:
> On Wed, Mar 5, 2008 at 8:03 AM, Carl-Daniel Hailfinger
> <c-d.hailfinger.devel.2006 at gmx.net> wrote:
>
>   
>>  No, not the tree mechanism. I was thinking more a long the lines of
>>  another dtc output mode which creates a flat .h file which has no
>>  structure, but contains all specially marked dts properties as #define.
>>     
>
> go ahead and propose a syntax, I'm very slow in the morning.
>   

The syntax you propose below would suit me just fine.

>>  I hope I clarified this. statictree.c in stage 1 would indeed be a bad idea.
>>     
>
> Ah, but would it. Look at the cs5536 startup code -- we don't
> parameterize it yet. We need to.
>
> We could do this: if there is a property in a node called "cpp", it is
> a list of values in that node that should be emitted as #defines.
> The names will be prefixed with the pathname of the dts, so
> if we had
> cpp = "com1enable";
> we get (ugly)
> SOUTHBRiDGE_AMD_CS5536_COM1ENABLE
> or some such.
>   

Nice one! I really like it.

Regards,
Carl-Daniel

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




From marc.jones at amd.com  Wed Mar  5 18:13:41 2008
From: marc.jones at amd.com (Marc Jones)
Date: Wed, 05 Mar 2008 10:13:41 -0700
Subject: [coreboot] first output: dbe62 and v3
In-Reply-To: <13426df10803042223j425b7e39jf071ca211d7106bd@mail.gmail.com>
References: <13426df10803042223j425b7e39jf071ca211d7106bd@mail.gmail.com>
Message-ID: <47CED4C5.6040907@amd.com>



ron minnich wrote:
> attached. It dies and I'm sure it is bad ram settings, but it's a start.
> 
> One thing I plan to change pretty soon: power button control can move
> from stage1 to stage2, and power button control will be managed in dts
> (another dts setting we would NOT want visible in Kconfig; you could
> render a board totally unbootable and unrepairable with the wrong
> setting. Kconfig should be for settings that are safe to change).
> 

This would be great. It should be easy to add a dts item and call 
cs5536_setup_power_button or not. Moving it to stage 2 should be fine 
BUT until the power button is setup it won't work. Some people might not 
like that if you hang or delay somewhere prior to it being setup.

You might be able to move a few of the following but most are needed to 
do the ram init and the others are a chicken/egg problem.

> There are other things in stage1 for the lx that we should try to move
> to stage 2:
>         cs5536_setup_extmsr();
cs5536_setup_extmsr() can't be moved. It is required to write the MSR in 
the 5536 which is neeeded to setup the SMBus for RAM init.


>         cs5536_setup_cis_mode();
> 
These are the sideband signals from the 5536 to the LX. These include 
int, smi, susp, and some others. You could move it BUT if you setup the 
IRQ in the uart the 5536 could do an int and then you would miss it. 
Doing it early avoids issues.

>         msr = rdmsr(GLCP_SYS_RSTPLL);
>         if (msr.lo & (0x3f << 26)) {
>                 /* PLL is already set and we are reboot from PLL reset. */
>                 return;
>         }
> 
>         cs5536_setup_idsel();
Need this to do stage2. Without it the 5536 won't decode PCI.

>         cs5536_usb_swapsif();
This can move but needs to be done before any the other usbsetup.

>         cs5536_setup_iobase();
This is required before raminit. Specificly the smbus io bar but if you 
set one you should probably just set them all. Once VSA loads these 
settings are reflected in the BAR and then are changed during PCI 
enumeration.

>         cs5536_setup_smbus_gpio();
This is required to set SMBUS sda/scl lines. There is a question how 
common this is in the function header. I have never seen these gpios 
used for anything else. Their purpose is to be the smbus lines.

>         /* cs5536_enable_smbus(); -- Leave this out for now. */
I just noticed that this code moved to smbus_initram which isn't really 
correct. SMBus is important for reading the SPD but it isn't the only 
device on the SMBus. Even if you don't have an SPD you still might like 
SMBus setup (thermal, gpio expander, etc). If you need SMBus for RAM 
init it needs to be done early, if not it can be done in stage2 but I 
think that it being in two places would be confusing.

> //      cs5536_setup_power_button();
> 
Discussed it above.

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  Wed Mar  5 18:28:57 2008
From: marc.jones at amd.com (Marc Jones)
Date: Wed, 05 Mar 2008 10:28:57 -0700
Subject: [coreboot] first output: dbe62 and v3
In-Reply-To: <47CED4C5.6040907@amd.com>
References: <13426df10803042223j425b7e39jf071ca211d7106bd@mail.gmail.com>
	<47CED4C5.6040907@amd.com>
Message-ID: <47CED859.2040302@amd.com>



Marc Jones wrote:
> 
> ron minnich wrote:
>> attached. It dies and I'm sure it is bad ram settings, but it's a start.
>>
>> One thing I plan to change pretty soon: power button control can move
>> from stage1 to stage2, and power button control will be managed in dts
>> (another dts setting we would NOT want visible in Kconfig; you could
>> render a board totally unbootable and unrepairable with the wrong
>> setting. Kconfig should be for settings that are safe to change).
>>
> 
> This would be great. It should be easy to add a dts item and call 
> cs5536_setup_power_button or not. Moving it to stage 2 should be fine 
> BUT until the power button is setup it won't work. Some people might not 
> like that if you hang or delay somewhere prior to it being setup.
> 
> You might be able to move a few of the following but most are needed to 
> do the ram init and the others are a chicken/egg problem.
> 

Thinking about this further... isn't this a problem for the dts since it 
is pre static tree?  The simple way to handle this is to move the 
cs5536_setup_power_button call from 5536\stage1.c to the mainboard 
hardware_stage1().

Yes, the dts and kconfig are great for setting things up but sometimes 
platform code is easier.

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 Mar  5 18:48:13 2008
From: c-d.hailfinger.devel.2006 at gmx.net (Carl-Daniel Hailfinger)
Date: Wed, 05 Mar 2008 18:48:13 +0100
Subject: [coreboot] first output: dbe62 and v3
In-Reply-To: <47CED4C5.6040907@amd.com>
References: <13426df10803042223j425b7e39jf071ca211d7106bd@mail.gmail.com>
	<47CED4C5.6040907@amd.com>
Message-ID: <47CEDCDD.6080104@gmx.net>

On 05.03.2008 18:13, Marc Jones wrote:
> ron minnich wrote:
>   
>> One thing I plan to change pretty soon: power button control can move
>> from stage1 to stage2, and power button control will be managed in dts
>> (another dts setting we would NOT want visible in Kconfig; you could
>> render a board totally unbootable and unrepairable with the wrong
>> setting. Kconfig should be for settings that are safe to change).
>>     
>
> This would be great. It should be easy to add a dts item and call 
> cs5536_setup_power_button or not. Moving it to stage 2 should be fine 
> BUT until the power button is setup it won't work. Some people might not 
> like that if you hang or delay somewhere prior to it being setup.
>   

Can we set up the power button in a way that makes it work always, then 
change the setup in stage2?


>>         msr = rdmsr(GLCP_SYS_RSTPLL);
>>         if (msr.lo & (0x3f << 26)) {
>>                 /* PLL is already set and we are reboot from PLL reset. */
>>                 return;
>>         }
>>
>>         cs5536_setup_idsel();
>>     
> Need this to do stage2. Without it the 5536 won't decode PCI.
>   

Did you mean stage1?

Regards,
Carl-Daniel

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




From rminnich at gmail.com  Wed Mar  5 18:57:42 2008
From: rminnich at gmail.com (ron minnich)
Date: Wed, 5 Mar 2008 09:57:42 -0800
Subject: [coreboot] first output: dbe62 and v3
In-Reply-To: <47CEDCDD.6080104@gmx.net>
References: <13426df10803042223j425b7e39jf071ca211d7106bd@mail.gmail.com>
	<47CED4C5.6040907@amd.com> <47CEDCDD.6080104@gmx.net>
Message-ID: <13426df10803050957i62b8b9b3x9f37a283380c4561@mail.gmail.com>

On Wed, Mar 5, 2008 at 9:48 AM, Carl-Daniel Hailfinger
<c-d.hailfinger.devel.2006 at gmx.net> wrote:

>  Can we set up the power button in a way that makes it work always, then
>  change the setup in stage2?

you really don't want that button working pre stage2, because, if the
button is hardwired on, the machine turns off in 4 seconds :-)

So you don't want to "default enable" it. You want to "don't do
ANYTHING until you are sure". right now code is default enable, and I
had to comment that out to get dbe62 up.


>  > Need this to do stage2. Without it the 5536 won't decode PCI.
>  >
>
>  Did you mean stage1?

I don't think the 5536 is visible until you do this, i.e. is not
addressable? Is that what you meant Marc?

I am going to take this slowly. I am going to move power button to
stage 2, and make it a standard part of cs5536 bringup in stage 2. No
harm is done by delaying the enable of the power button, and I already
know lots of harm is done by enabling the power button too early.
Patch later tonight.

ron



From marc.jones at amd.com  Wed Mar  5 18:59:22 2008
From: marc.jones at amd.com (Marc Jones)
Date: Wed, 05 Mar 2008 10:59:22 -0700
Subject: [coreboot] first output: dbe62 and v3
In-Reply-To: <47CEDCDD.6080104@gmx.net>
References: <13426df10803042223j425b7e39jf071ca211d7106bd@mail.gmail.com>	<47CED4C5.6040907@amd.com>
	<47CEDCDD.6080104@gmx.net>
Message-ID: <47CEDF7A.9080201@amd.com>



Carl-Daniel Hailfinger wrote:
> On 05.03.2008 18:13, Marc Jones wrote:
>> ron minnich wrote:
>>   
>>> One thing I plan to change pretty soon: power button control can move
>>> from stage1 to stage2, and power button control will be managed in dts
>>> (another dts setting we would NOT want visible in Kconfig; you could
>>> render a board totally unbootable and unrepairable with the wrong
>>> setting. Kconfig should be for settings that are safe to change).
>>>     
>> This would be great. It should be easy to add a dts item and call 
>> cs5536_setup_power_button or not. Moving it to stage 2 should be fine 
>> BUT until the power button is setup it won't work. Some people might not 
>> like that if you hang or delay somewhere prior to it being setup.
>>   
> 
> Can we set up the power button in a way that makes it work always, then 
> change the setup in stage2?
> 
> 

That is the problem. For systems that don't have a powerbutton, enabling 
the button logic will cause a reset in 4 seconds which would be fine if 
you could gaurnettee that it would be reprogrammed by then but that is 
just the oposite problem described above. What if there is a delay prior 
to rprograming it?



>>>         msr = rdmsr(GLCP_SYS_RSTPLL);
>>>         if (msr.lo & (0x3f << 26)) {
>>>                 /* PLL is already set and we are reboot from PLL reset. */
>>>                 return;
>>>         }
>>>
>>>         cs5536_setup_idsel();
>>>     
>> Need this to do stage2. Without it the 5536 won't decode PCI.
>>   
> 
> Did you mean stage1?
> 

You need to do it in stage1 so you can do stage2 (stage 2 needs to find 
the device before it can program it).

Marc


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




From mylesgw at gmail.com  Wed Mar  5 19:27:18 2008
From: mylesgw at gmail.com (Myles Watson)
Date: Wed, 5 Mar 2008 11:27:18 -0700
Subject: [coreboot] Makefile simplification for v3
Message-ID: <2831fecf0803051027n113b8ffdl6140c746fd181b66@mail.gmail.com>

These patches are nearly identical.  The only difference is which
directory lar is invoked from.

They do away with lar.tmp because path handling in lar has been fixed.
 In other words, there is no need for copying files around.  Just use
them.

I like the second version better, because it makes it clear where all
the files live by prepending $(obj) in the right places.  I included
both versions because I think it is a matter of taste.

lar -l is identical before and after the patch, and it still boots
with and without payloads in qemu.

Myles

Signed-off-by: Myles Watson <mylesgw at gmail.com>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Makefile_simplify.patch
Type: text/x-patch
Size: 2794 bytes
Desc: not available
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20080305/8c68ecf7/attachment.patch>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Makefile_simplify.patch2
Type: application/octet-stream
Size: 2836 bytes
Desc: not available
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20080305/8c68ecf7/attachment.obj>

From rminnich at gmail.com  Wed Mar  5 20:33:19 2008
From: rminnich at gmail.com (ron minnich)
Date: Wed, 5 Mar 2008 11:33:19 -0800
Subject: [coreboot] first output: dbe62 and v3
In-Reply-To: <47CEDF7A.9080201@amd.com>
References: <13426df10803042223j425b7e39jf071ca211d7106bd@mail.gmail.com>
	<47CED4C5.6040907@amd.com> <47CEDCDD.6080104@gmx.net>
	<47CEDF7A.9080201@amd.com>
Message-ID: <13426df10803051133t252961a0w2768f3d82ee95126@mail.gmail.com>

On Wed, Mar 5, 2008 at 9:59 AM, Marc Jones <marc.jones at amd.com> wrote:

>  >> Need this to do stage2. Without it the 5536 won't decode PCI.
>  >>
>  >
>  > Did you mean stage1?
>  >
>
>  You need to do it in stage1 so you can do stage2 (stage 2 needs to find
>  the device before it can program it).
>
>

so we don't need this in stage 1? then we can do it in stage  1 phase
2, which is designed specifically for this type of operation: doing
something before you try to scan pci.

Thanks
ron



From rminnich at gmail.com  Wed Mar  5 20:33:52 2008
From: rminnich at gmail.com (ron minnich)
Date: Wed, 5 Mar 2008 11:33:52 -0800
Subject: [coreboot] first output: dbe62 and v3
In-Reply-To: <13426df10803051133t252961a0w2768f3d82ee95126@mail.gmail.com>
References: <13426df10803042223j425b7e39jf071ca211d7106bd@mail.gmail.com>
	<47CED4C5.6040907@amd.com> <47CEDCDD.6080104@gmx.net>
	<47CEDF7A.9080201@amd.com>
	<13426df10803051133t252961a0w2768f3d82ee95126@mail.gmail.com>
Message-ID: <13426df10803051133k3673433ev4c375bbd2471508d@mail.gmail.com>

On Wed, Mar 5, 2008 at 11:33 AM, ron minnich <rminnich at gmail.com> wrote:
> On Wed, Mar 5, 2008 at 9:59 AM, Marc Jones <marc.jones at amd.com> wrote:
>
>  >  >> Need this to do stage2. Without it the 5536 won't decode PCI.
>  >  >>
>  >  >
>  >  > Did you mean stage1?
>  >  >
>  >
>  >  You need to do it in stage1 so you can do stage2 (stage 2 needs to find
>  >  the device before it can program it).
>  >
>  >
>
>  so we don't need this in stage 1? then we can do it in stage  1 phase
>  2, which is designed specifically for this type of operation: doing
>  something before you try to scan pci.

Sorry! Stage 2 phase  1!

ron



From marc.jones at amd.com  Wed Mar  5 21:03:02 2008
From: marc.jones at amd.com (Marc Jones)
Date: Wed, 05 Mar 2008 13:03:02 -0700
Subject: [coreboot] first output: dbe62 and v3
In-Reply-To: <13426df10803051133k3673433ev4c375bbd2471508d@mail.gmail.com>
References: <13426df10803042223j425b7e39jf071ca211d7106bd@mail.gmail.com>	<47CED4C5.6040907@amd.com>
	<47CEDCDD.6080104@gmx.net>	<47CEDF7A.9080201@amd.com>	<13426df10803051133t252961a0w2768f3d82ee95126@mail.gmail.com>
	<13426df10803051133k3673433ev4c375bbd2471508d@mail.gmail.com>
Message-ID: <47CEFC76.6080401@amd.com>



ron minnich wrote:
> On Wed, Mar 5, 2008 at 11:33 AM, ron minnich <rminnich at gmail.com> wrote:
>> On Wed, Mar 5, 2008 at 9:59 AM, Marc Jones <marc.jones at amd.com> wrote:
>>
>>  >  >> Need this to do stage2. Without it the 5536 won't decode PCI.
>>  >  >>
>>  >  >
>>  >  > Did you mean stage1?
>>  >  >
>>  >
>>  >  You need to do it in stage1 so you can do stage2 (stage 2 needs to find
>>  >  the device before it can program it).
>>  >
>>  >
>>
>>  so we don't need this in stage 1? then we can do it in stage  1 phase
>>  2, which is designed specifically for this type of operation: doing
>>  something before you try to scan pci.
> 
> Sorry! Stage 2 phase  1!
> 
> ron
> 

I can't think of anything in stage1 that specifically needs it but it 
does seem risky. It would need to be the first thing ins stage2 phase1. 
I suppose you can always move it back if you find a problem.
Marc



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




From dsedrich at violin-memory.com  Wed Mar  5 21:50:25 2008
From: dsedrich at violin-memory.com (David Edrich)
Date: Wed, 5 Mar 2008 14:50:25 -0600
Subject: [coreboot] qemu error message: "Unrecognized partitioning
	scheme"
In-Reply-To: <13426df10803041502v37b079a7ob131b1e68f797ee8@mail.gmail.com>
References: <031701c87e48$7e531ba0$7af952e0$@com>
	<13426df10803041502v37b079a7ob131b1e68f797ee8@mail.gmail.com>
Message-ID: <035901c87f02$89a62b90$9cf282b0$@com>



> -----Original Message-----
> From: ron minnich [mailto:rminnich at gmail.com]
> Sent: Tuesday, March 04, 2008 5:02 PM
> To: David Edrich
> Cc: Coreboot
> Subject: Re: [coreboot] qemu error message: "Unrecognized partitioning scheme"
> 
> If it is not partitioned you can boot it raw:
> hda:/boot/filo/menu.lst
> 
> Note I left the '3' out
> 
[David Edrich] Yes you left the '3' out - I Don't know what that means. Can you tell me where I insert this string to make the 'raw'
boot happen?

> ron





From c-d.hailfinger.devel.2006 at gmx.net  Wed Mar  5 22:51:41 2008
From: c-d.hailfinger.devel.2006 at gmx.net (Carl-Daniel Hailfinger)
Date: Wed, 05 Mar 2008 22:51:41 +0100
Subject: [coreboot] first output: dbe62 and v3
In-Reply-To: <47CEDF7A.9080201@amd.com>
References: <13426df10803042223j425b7e39jf071ca211d7106bd@mail.gmail.com>	<47CED4C5.6040907@amd.com>
	<47CEDCDD.6080104@gmx.net> <47CEDF7A.9080201@amd.com>
Message-ID: <47CF15ED.8000908@gmx.net>

On 05.03.2008 18:59, Marc Jones wrote:
> Carl-Daniel Hailfinger wrote:
>> On 05.03.2008 18:13, Marc Jones wrote:
>>> ron minnich wrote:
>>>  
>>>> One thing I plan to change pretty soon: power button control can move
>>>> from stage1 to stage2, and power button control will be managed in dts
>>>> (another dts setting we would NOT want visible in Kconfig; you could
>>>> render a board totally unbootable and unrepairable with the wrong
>>>> setting. Kconfig should be for settings that are safe to change).
>>>>     
>>> This would be great. It should be easy to add a dts item and call 
>>> cs5536_setup_power_button or not. Moving it to stage 2 should be 
>>> fine BUT until the power button is setup it won't work. Some people 
>>> might not like that if you hang or delay somewhere prior to it being 
>>> setup.   
>>
>> Can we set up the power button in a way that makes it work always, 
>> then change the setup in stage2?
>
> That is the problem. For systems that don't have a powerbutton, 
> enabling the button logic will cause a reset in 4 seconds which would 
> be fine if you could gaurnettee that it would be reprogrammed by then 
> but that is just the oposite problem described above. What if there is 
> a delay prior to rprograming it?

Now that problem makes sense. Thanks for explaining it!


>>>>         msr = rdmsr(GLCP_SYS_RSTPLL);
>>>>         if (msr.lo & (0x3f << 26)) {
>>>>                 /* PLL is already set and we are reboot from PLL 
>>>> reset. */
>>>>                 return;
>>>>         }
>>>>
>>>>         cs5536_setup_idsel();
>>>>     
>>> Need this to do stage2. Without it the 5536 won't decode PCI.   
>>
>> Did you mean stage1?
>
> You need to do it in stage1 so you can do stage2 (stage 2 needs to 
> find the device before it can program it).

Sorry, I had misread your sentence as "Need to do this in stage2". 
That's why I was confused. Rereading it revealed my misunderstanding.

Regards,
Carl-Daniel

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




From joe at smittys.pointclark.net  Wed Mar  5 23:09:27 2008
From: joe at smittys.pointclark.net (joe at smittys.pointclark.net)
Date: Wed, 05 Mar 2008 17:09:27 -0500
Subject: [coreboot] Audio mute problem
Message-ID: <20080305170927.n4n5awqmgwwkkwsw@www.smittys.pointclark.net>

Hello,
The audio on the RM4100 is muted by default. I know the assembly code  
to unmute it but I am not so good with the assembly, could someone  
translate this for me into human???

seg000:00000000 mov edx, 84Dh
seg000:00000005 mov eax, 0C0h ; '+'
seg000:0000000A out dx, al


Thanks - Joe



From c-d.hailfinger.devel.2006 at gmx.net  Wed Mar  5 23:45:06 2008
From: c-d.hailfinger.devel.2006 at gmx.net (Carl-Daniel Hailfinger)
Date: Wed, 05 Mar 2008 23:45:06 +0100
Subject: [coreboot] Audio mute problem
In-Reply-To: <20080305170927.n4n5awqmgwwkkwsw@www.smittys.pointclark.net>
References: <20080305170927.n4n5awqmgwwkkwsw@www.smittys.pointclark.net>
Message-ID: <47CF2272.8000901@gmx.net>

On 05.03.2008 23:09, joe at smittys.pointclark.net wrote:
> Hello,
> The audio on the RM4100 is muted by default. I know the assembly code  
> to unmute it but I am not so good with the assembly, could someone  
> translate this for me into human???
>
> seg000:00000000 mov edx, 84Dh
> seg000:00000005 mov eax, 0C0h ; '+'
> seg000:0000000A out dx, al
>   

Write 0xc0 to port 0x84d.

Regards,
Carl-Daniel

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




From stepan at coresystems.de  Wed Mar  5 23:50:44 2008
From: stepan at coresystems.de (Stefan Reinauer)
Date: Wed, 05 Mar 2008 23:50:44 +0100
Subject: [coreboot] Problems with VIA EPIA-ME6000
In-Reply-To: <200803041710.41023.klaus123@ibnoetzold.de>
References: <200803031520.56570.klaus123@ibnoetzold.de>	<200803041442.19732.klaus123@ibnoetzold.de>	<20080304152323.GA1533@greenwood>
	<200803041710.41023.klaus123@ibnoetzold.de>
Message-ID: <47CF23C4.6030500@coresystems.de>

Klaus Stammermann wrote:
> Here the diff:
> -----------------------------------------------------------------------------------------------------------------------------------
> Index: src/mainboard/via/epia-m/Options.lb
> ===================================================================
> --- src/mainboard/via/epia-m/Options.lb	(Revision 3086)
> +++ src/mainboard/via/epia-m/Options.lb	(Arbeitskopie)
> @@ -51,8 +51,8 @@
>  ###
>  ### Build options
>  ###
> -default CONFIG_PCI_ROM_RUN=0
> -default CONFIG_CONSOLE_VGA=0
> +default CONFIG_PCI_ROM_RUN=1
> +default CONFIG_CONSOLE_VGA=1
>   
This won't work. Epia-M brings its own vm86 based pci option rom 
execution. The above additionally enables x86emu. Unfortunately x86emu 
is not capable of executing the Epia-M option rom. Sorry for the confusion.

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/20080305/c79f5b43/attachment.sig>

From mylesgw at gmail.com  Wed Mar  5 23:59:47 2008
From: mylesgw at gmail.com (Myles Watson)
Date: Wed, 5 Mar 2008 15:59:47 -0700
Subject: [coreboot] qemu error message: "Unrecognized partitioning
	scheme"
In-Reply-To: <035901c87f02$89a62b90$9cf282b0$@com>
References: <031701c87e48$7e531ba0$7af952e0$@com>
	<13426df10803041502v37b079a7ob131b1e68f797ee8@mail.gmail.com>
	<035901c87f02$89a62b90$9cf282b0$@com>
Message-ID: <2831fecf0803051459g8a361ddk2ee7f6f6a07c595a@mail.gmail.com>

On Wed, Mar 5, 2008 at 1:50 PM, David Edrich <dsedrich at violin-memory.com> wrote:
>
>
>  > -----Original Message-----
>  > From: ron minnich [mailto:rminnich at gmail.com]
>  > Sent: Tuesday, March 04, 2008 5:02 PM
>  > To: David Edrich
>  > Cc: Coreboot
>  > Subject: Re: [coreboot] qemu error message: "Unrecognized partitioning scheme"
>  >
>  > If it is not partitioned you can boot it raw:
>  > hda:/boot/filo/menu.lst
>  >
>  > Note I left the '3' out
>  >
>  [David Edrich] Yes you left the '3' out - I Don't know what that means. Can you tell me where I insert this string to make the 'raw'
>  boot happen?
>

He was telling you that hda3:... means look on the 3rd partition.  if
there are no partitions you use hda:...

This string should be in filo's Config file.

BTW: In my first response about killing qemu I didn't realize you were
using -nographic, so my advice probably didn't make sense.  I prefer
to redirect the serial output and use the graphical display.

Something like:
qemu -L BIOS disk.img -serial file:ser_out.txt

Myles



From stepan at coresystems.de  Thu Mar  6 00:03:03 2008
From: stepan at coresystems.de (Stefan Reinauer)
Date: Thu, 06 Mar 2008 00:03:03 +0100
Subject: [coreboot] patch: set dbe62 to have com2 on com1 address
In-Reply-To: <13426df10803042151y6f1f1e3fn4c179c264669f044@mail.gmail.com>
References: <13426df10803042151y6f1f1e3fn4c179c264669f044@mail.gmail.com>
Message-ID: <47CF26A7.9080204@coresystems.de>

ron minnich wrote:
> Index: mainboard/artecgroup/dbe62/dts
> ===================================================================
> --- mainboard/artecgroup/dbe62/dts      (revision 630)
> +++ mainboard/artecgroup/dbe62/dts      (working copy)
> @@ -43,6 +43,10 @@
>                         /* GPIO(0-0x20) for INT D:C:B:A, 0xFF=none.
>                          * See virtual PIC spec. */
>                         enable_gpio_int_route = "0x0D0C0700";
> +                       /* we use com2 since that is on the dongle */
> +                       com2_enable = "1";
> +                       /* Set com2 address to be COM1 */
> +                       com2_address = "0x3f8";
>   

Can't we use 2f8 as base address here and put console on COM2?

Reordering com ports is kind of evil. It will also change what is ttyS0 
in Linux..

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/20080306/ada55a58/attachment.sig>

From rminnich at gmail.com  Thu Mar  6 00:07:54 2008
From: rminnich at gmail.com (ron minnich)
Date: Wed, 5 Mar 2008 15:07:54 -0800
Subject: [coreboot] patch: set dbe62 to have com2 on com1 address
In-Reply-To: <47CF26A7.9080204@coresystems.de>
References: <13426df10803042151y6f1f1e3fn4c179c264669f044@mail.gmail.com>
	<47CF26A7.9080204@coresystems.de>
Message-ID: <13426df10803051507v299e25a0kd0382ef3ffb328fd@mail.gmail.com>

On Wed, Mar 5, 2008 at 3:03 PM, Stefan Reinauer <stepan at coresystems.de> wrote:

>
>  Can't we use 2f8 as base address here and put console on COM2?
>
>  Reordering com ports is kind of evil. It will also change what is ttyS0
>  in Linux..

actually it won't. All I'm doing is making the one available com port
that is connected BE COM1 -- base address, irq, everything. Linux
won't know. Linux will use ttyS0 and
as far as it is concerned, nothing is out of the ordinary. It all
looks like COM2. COM1 is not even connected to anything on this
platform.

I looked at both ways and this appears (to me) to be the best. It's
also what is done on v2.

ron



From c-d.hailfinger.devel.2006 at gmx.net  Thu Mar  6 00:12:49 2008
From: c-d.hailfinger.devel.2006 at gmx.net (Carl-Daniel Hailfinger)
Date: Thu, 06 Mar 2008 00:12:49 +0100
Subject: [coreboot] some thoughts on dts vs. Kconfig vs. makefiles vs. C
 code
In-Reply-To: <47CECB60.9060401@gmx.net>
References: <13426df10802281040n4afcdce1p1af052b71ce556f1@mail.gmail.com>		<47CEB36E.4010004@gmx.net>		<13426df10803050753h52f8030fjfeee5b678ff8b4e6@mail.gmail.com>		<47CEC43F.8010307@gmx.net>	<13426df10803050810u62fb6b68o3a3d7dc672bdfbe6@mail.gmail.com>
	<47CECB60.9060401@gmx.net>
Message-ID: <47CF28F1.3060605@gmx.net>

We have one really bad offender which totally violates the Kconfig vs. 
dts distinction:

config MAINBOARD_PCI_SUBSYSTEM_VENDOR_ID
	hex
	# TODO: Fix PCI ID.
	default 0x1022
	depends BOARD_AMD_NORWICH
	help
	  Mainboard specific PCI subsystem vendor ID.

config MAINBOARD_PCI_SUBSYSTEM_DEVICE_ID
	hex
	# TODO: Fix PCI ID.
	default 0x2323
	depends BOARD_AMD_NORWICH
	help
	  Mainboard specific PCI subsystem device ID.


This absolutely belongs in the dts. The question is: Where in the dts 
should it live?

Regards,
Carl-Daniel

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




From stepan at coresystems.de  Thu Mar  6 00:21:26 2008
From: stepan at coresystems.de (Stefan Reinauer)
Date: Thu, 06 Mar 2008 00:21:26 +0100
Subject: [coreboot] patch: set dbe62 to have com2 on com1 address
In-Reply-To: <13426df10803051507v299e25a0kd0382ef3ffb328fd@mail.gmail.com>
References: <13426df10803042151y6f1f1e3fn4c179c264669f044@mail.gmail.com>	
	<47CF26A7.9080204@coresystems.de>
	<13426df10803051507v299e25a0kd0382ef3ffb328fd@mail.gmail.com>
Message-ID: <47CF2AF6.3080304@coresystems.de>

ron minnich wrote:
> On Wed, Mar 5, 2008 at 3:03 PM, Stefan Reinauer <stepan at coresystems.de> wrote:
>
>   
>>  Can't we use 2f8 as base address here and put console on COM2?
>>
>>  Reordering com ports is kind of evil. It will also change what is ttyS0
>>  in Linux..
>>     
>
> actually it won't. All I'm doing is making the one available com port
> that is connected BE COM1 -- base address, irq, everything. Linux
> won't know. Linux will use ttyS0 and
> as far as it is concerned, nothing is out of the ordinary. It all
> looks like COM2. COM1 is not even connected to anything on this
> platform.
>   
Ah ok, that makes perfect sense.


-- 
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/20080306/ac8204d9/attachment.sig>

From rminnich at gmail.com  Thu Mar  6 00:27:41 2008
From: rminnich at gmail.com (ron minnich)
Date: Wed, 5 Mar 2008 15:27:41 -0800
Subject: [coreboot] some thoughts on dts vs. Kconfig vs. makefiles vs. C
	code
In-Reply-To: <47CF28F1.3060605@gmx.net>
References: <13426df10802281040n4afcdce1p1af052b71ce556f1@mail.gmail.com>
	<47CEB36E.4010004@gmx.net>
	<13426df10803050753h52f8030fjfeee5b678ff8b4e6@mail.gmail.com>
	<47CEC43F.8010307@gmx.net>
	<13426df10803050810u62fb6b68o3a3d7dc672bdfbe6@mail.gmail.com>
	<47CECB60.9060401@gmx.net> <47CF28F1.3060605@gmx.net>
Message-ID: <13426df10803051527v56be68e2tabfb37141a026ab4@mail.gmail.com>

On Wed, Mar 5, 2008 at 3:12 PM, Carl-Daniel Hailfinger
<c-d.hailfinger.devel.2006 at gmx.net> wrote:
> We have one really bad offender which totally violates the Kconfig vs.
>  dts distinction:
>
>  config MAINBOARD_PCI_SUBSYSTEM_VENDOR_ID
>         hex
>         # TODO: Fix PCI ID.
>         default 0x1022
>         depends BOARD_AMD_NORWICH
>         help
>           Mainboard specific PCI subsystem vendor ID.
>
>  config MAINBOARD_PCI_SUBSYSTEM_DEVICE_ID
>         hex
>         # TODO: Fix PCI ID.
>         default 0x2323
>         depends BOARD_AMD_NORWICH
>         help
>           Mainboard specific PCI subsystem device ID.
>
>

Right in the mainboard dts? Right at the top.

ron



From phanig at gmail.com  Thu Mar  6 01:06:46 2008
From: phanig at gmail.com (Phani Babu Giddi)
Date: Wed, 5 Mar 2008 16:06:46 -0800
Subject: [coreboot] FILO loads image but, Linux doesnt boot
Message-ID: <b61da340803051606n39098f55s17a2b065d44e24f9@mail.gmail.com>

Hello All,

I am running Coreboot v2 on AMD's db800 with FILO as the payload. It gets to
a point where it intialzes the kernel but the kernel doesnt boot. Any idea
whats going on.. I have captured the messages using the serial console. The
last few messages are...

linux-34w5:~ # tail minicom.cap
parse_command_line: initrd=/initrd-2.6.16.46-0.12-default
parse_command_line: kernel command line (64 bytes): "root=/dev/hda3
vga=0x317 resume=/dev/hda2 splash=silent showopts"
load_linux_kernel: offset=0x2000 addr=0x100000 size=0x13158c
Loading kernel... ok
file_open: dev=<NULL>, path=/initrd-2.6.16.46-0.12-default
load_initrd: start=0x1f502000 end=0x1f7aeb32
Loading initrd... ok
malloc_diag: alloc: 312 bytes (4 blocks), free: 16064 bytes (1 blocks)
start_linux: eip=0x100000
Jumping to entry point...

Is this the last message that one is suppose to see with coreboot ?

Regards,
Phani
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20080305/fc00b66c/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: minicom.cap
Type: application/octet-stream
Size: 23083 bytes
Desc: not available
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20080305/fc00b66c/attachment.obj>

From c-d.hailfinger.devel.2006 at gmx.net  Thu Mar  6 01:20:37 2008
From: c-d.hailfinger.devel.2006 at gmx.net (Carl-Daniel Hailfinger)
Date: Thu, 06 Mar 2008 01:20:37 +0100
Subject: [coreboot] [PATCH] v3: Move default mainboard vendor/subsystem from
 Kconfig to dts
In-Reply-To: <13426df10803051527v56be68e2tabfb37141a026ab4@mail.gmail.com>
References: <13426df10802281040n4afcdce1p1af052b71ce556f1@mail.gmail.com>	<47CEB36E.4010004@gmx.net>	<13426df10803050753h52f8030fjfeee5b678ff8b4e6@mail.gmail.com>	<47CEC43F.8010307@gmx.net>	<13426df10803050810u62fb6b68o3a3d7dc672bdfbe6@mail.gmail.com>	<47CECB60.9060401@gmx.net>
	<47CF28F1.3060605@gmx.net>
	<13426df10803051527v56be68e2tabfb37141a026ab4@mail.gmail.com>
Message-ID: <47CF38D5.3040608@gmx.net>

On 06.03.2008 00:27, ron minnich wrote:
> On Wed, Mar 5, 2008 at 3:12 PM, Carl-Daniel Hailfinger
> <c-d.hailfinger.devel.2006 at gmx.net> wrote:
>   
>> We have one really bad offender which totally violates the Kconfig vs.
>>  dts distinction:
>>
>>  config MAINBOARD_PCI_SUBSYSTEM_VENDOR_ID
>>         hex
>>         # TODO: Fix PCI ID.
>>         default 0x1022
>>         depends BOARD_AMD_NORWICH
>>         help
>>           Mainboard specific PCI subsystem vendor ID.
>>
>>  config MAINBOARD_PCI_SUBSYSTEM_DEVICE_ID
>>         hex
>>         # TODO: Fix PCI ID.
>>         default 0x2323
>>         depends BOARD_AMD_NORWICH
>>         help
>>           Mainboard specific PCI subsystem device ID.
>>
>>     
>
> Right in the mainboard dts? Right at the top.
>   

Done. Patch is compile tested.

Move default mainboard vendor/subsystem from Kconfig to dts.

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

Index: LinuxBIOSv3-mainboard_subsystem/mainboard/adl/msm800sev/Kconfig
===================================================================
--- LinuxBIOSv3-mainboard_subsystem/mainboard/adl/msm800sev/Kconfig	(Revision 632)
+++ LinuxBIOSv3-mainboard_subsystem/mainboard/adl/msm800sev/Kconfig	(Arbeitskopie)
@@ -26,19 +26,3 @@
 	help
 	  This is the name for the Advanced Digital Logic MSM800SEV mainboard.
 
-config MAINBOARD_PCI_SUBSYSTEM_VENDOR_ID
-	hex
-	# TODO: Fix the PCI ID.
-	default 0x1022
-	depends BOARD_ADL_MSM800SEV
-	help
-	  Mainboard specific PCI subsystem vendor ID.
-
-config MAINBOARD_PCI_SUBSYSTEM_DEVICE_ID
-	hex
-	# TODO: Fix the PCI ID.
-	default 0x2323
-	depends BOARD_ADL_MSM800SEV
-	help
-	  Mainboard specific PCI subsystem vendor ID.
-
Index: LinuxBIOSv3-mainboard_subsystem/mainboard/adl/msm800sev/dts
===================================================================
--- LinuxBIOSv3-mainboard_subsystem/mainboard/adl/msm800sev/dts	(Revision 632)
+++ LinuxBIOSv3-mainboard_subsystem/mainboard/adl/msm800sev/dts	(Arbeitskopie)
@@ -23,6 +23,8 @@
 /{
 	mainboard-vendor = "Advanced Digital Logic";
 	mainboard-name = "MSM800SEV";
+	mainboard_pci_subsystem_vendor = "0x1022";
+	mainboard_pci_subsystem_device = "0x2323";
 	cpus { };
 	apic at 0 {
 		/config/("northbridge/amd/geodelx/apic");
Index: LinuxBIOSv3-mainboard_subsystem/mainboard/amd/norwich/Kconfig
===================================================================
--- LinuxBIOSv3-mainboard_subsystem/mainboard/amd/norwich/Kconfig	(Revision 632)
+++ LinuxBIOSv3-mainboard_subsystem/mainboard/amd/norwich/Kconfig	(Arbeitskopie)
@@ -26,19 +26,3 @@
 	help
 	  This is the default mainboard name.
 
-config MAINBOARD_PCI_SUBSYSTEM_VENDOR_ID
-	hex
-	# TODO: Fix PCI ID.
-	default 0x1022
-	depends BOARD_AMD_NORWICH
-	help
-	  Mainboard specific PCI subsystem vendor ID.
-
-config MAINBOARD_PCI_SUBSYSTEM_DEVICE_ID
-	hex
-	# TODO: Fix PCI ID.
-	default 0x2323
-	depends BOARD_AMD_NORWICH
-	help
-	  Mainboard specific PCI subsystem device ID.
-
Index: LinuxBIOSv3-mainboard_subsystem/mainboard/amd/norwich/dts
===================================================================
--- LinuxBIOSv3-mainboard_subsystem/mainboard/amd/norwich/dts	(Revision 632)
+++ LinuxBIOSv3-mainboard_subsystem/mainboard/amd/norwich/dts	(Arbeitskopie)
@@ -21,6 +21,8 @@
 /{
 	mainboard-vendor = "AMD";
 	mainboard-name = "NORWICH";
+	mainboard_pci_subsystem_vendor = "0x1022";
+	mainboard_pci_subsystem_device = "0x2323";
 	cpus { };
 	apic at 0 {
 		/config/("northbridge/amd/geodelx/apic");
Index: LinuxBIOSv3-mainboard_subsystem/mainboard/artecgroup/dbe61/Kconfig
===================================================================
--- LinuxBIOSv3-mainboard_subsystem/mainboard/artecgroup/dbe61/Kconfig	(Revision 632)
+++ LinuxBIOSv3-mainboard_subsystem/mainboard/artecgroup/dbe61/Kconfig	(Arbeitskopie)
@@ -26,19 +26,3 @@
 	help
 	  This is the default mainboard name.
 
-config MAINBOARD_PCI_SUBSYSTEM_VENDOR_ID
-	hex
-	# TODO: Fix PCI ID.
-	default 0x1022
-	depends BOARD_ARTECGROUP_DBE61
-	help
-	  Mainboard specific PCI subsystem vendor ID.
-
-config MAINBOARD_PCI_SUBSYSTEM_DEVICE_ID
-	hex
-	# TODO: Fix PCI ID.
-	default 0x2323
-	depends BOARD_ARTECGROUP_DBE61
-	help
-	  Mainboard specific PCI subsystem device ID.
-
Index: LinuxBIOSv3-mainboard_subsystem/mainboard/artecgroup/dbe61/dts
===================================================================
--- LinuxBIOSv3-mainboard_subsystem/mainboard/artecgroup/dbe61/dts	(Revision 632)
+++ LinuxBIOSv3-mainboard_subsystem/mainboard/artecgroup/dbe61/dts	(Arbeitskopie)
@@ -75,6 +75,8 @@
 /{
 	mainboard-vendor = "Artec Group";
 	mainboard-name = "DBE61";
+	mainboard_pci_subsystem_vendor = "0x1022";
+	mainboard_pci_subsystem_device = "0x2323";
 	cpus { };
 	apic at 0 {
 		/config/("northbridge/amd/geodelx/apic");
Index: LinuxBIOSv3-mainboard_subsystem/mainboard/emulation/qemu-x86/Kconfig
===================================================================
--- LinuxBIOSv3-mainboard_subsystem/mainboard/emulation/qemu-x86/Kconfig	(Revision 632)
+++ LinuxBIOSv3-mainboard_subsystem/mainboard/emulation/qemu-x86/Kconfig	(Arbeitskopie)
@@ -27,17 +27,3 @@
 	help
 	  This is the default mainboard name.
 
-config MAINBOARD_PCI_SUBSYSTEM_VENDOR_ID
-	hex
-	default 0x15ad
-	depends BOARD_EMULATION_QEMU_X86
-	help
-	  Mainboard specific PCI subsystem vendor ID.
-
-config MAINBOARD_PCI_SUBSYSTEM_DEVICE_ID
-	hex
-	default 0x1976
-	depends BOARD_EMULATION_QEMU_X86
-	help
-	  Mainboard specific PCI subsystem device ID.
-
Index: LinuxBIOSv3-mainboard_subsystem/mainboard/emulation/qemu-x86/dts
===================================================================
--- LinuxBIOSv3-mainboard_subsystem/mainboard/emulation/qemu-x86/dts	(Revision 632)
+++ LinuxBIOSv3-mainboard_subsystem/mainboard/emulation/qemu-x86/dts	(Arbeitskopie)
@@ -21,6 +21,8 @@
 /{
 	mainboard-vendor = "Emulation";
 	mainboard-name = "QEMU x86";
+	mainboard_pci_subsystem_vendor = "0x15ad";
+	mainboard_pci_subsystem_device = "0x1976";
 	device_operations = "qemuvga_pci_ops_dev";
 	cpus {};
 	domain at 0 {
Index: LinuxBIOSv3-mainboard_subsystem/device/pci_device.c
===================================================================
--- LinuxBIOSv3-mainboard_subsystem/device/pci_device.c	(Revision 632)
+++ LinuxBIOSv3-mainboard_subsystem/device/pci_device.c	(Arbeitskopie)
@@ -50,6 +50,7 @@
 #if CONFIG_CARDBUS_PLUGIN_SUPPORT == 1
 #include <device/cardbus.h>
 #endif
+#include <statictree.h>
 
 u8 pci_moving_config8(struct device *dev, unsigned int reg)
 {
@@ -627,19 +628,17 @@
 	/* Set the subsystem vendor and device ID for mainboard devices. */
 	ops = ops_pci(dev);
 
-#if defined(CONFIG_MAINBOARD_PCI_SUBSYSTEM_VENDOR_ID) && \
-	defined(CONFIG_MAINBOARD_PCI_SUBSYSTEM_DEVICE_ID)
-	if (dev->on_mainboard && ops && ops->set_subsystem) {
+	if (mainboard_pci_subsystem_set && dev->on_mainboard && ops &&
+	    ops->set_subsystem) {
 		printk(BIOS_DEBUG,
 		       "%s: Setting subsystem VID/DID to %02x/%02x\n",
-		       dev_path(dev), CONFIG_MAINBOARD_PCI_SUBSYSTEM_VENDOR_ID,
-		       CONFIG_MAINBOARD_PCI_SUBSYSTEM_DEVICE_ID);
+		       dev_path(dev), mainboard_pci_subsystem_vendor,
+		       mainboard_pci_subsystem_device);
 
-		ops->set_subsystem(dev,
-				   CONFIG_MAINBOARD_PCI_SUBSYSTEM_VENDOR_ID,
-				   CONFIG_MAINBOARD_PCI_SUBSYSTEM_DEVICE_ID);
+		ops->set_subsystem(dev,	mainboard_pci_subsystem_vendor,
+				   mainboard_pci_subsystem_device);
 	}
-#endif
+
 	command = pci_read_config16(dev, PCI_COMMAND);
 	command |= dev->command;
 	command |= (PCI_COMMAND_PARITY + PCI_COMMAND_SERR); // Error check.
Index: LinuxBIOSv3-mainboard_subsystem/util/dtc/flattree.c
===================================================================
--- LinuxBIOSv3-mainboard_subsystem/util/dtc/flattree.c	(Revision 632)
+++ LinuxBIOSv3-mainboard_subsystem/util/dtc/flattree.c	(Arbeitskopie)
@@ -1304,7 +1304,7 @@
 	extern char *code;
 	struct node *next;
 	extern struct node *first_node;
-	int found_mainboard_vendor = 0, found_mainboard_partnumber = 0;
+	int found_mainboard_vendor = 0, found_mainboard_partnumber = 0, found_mainboard_subsys = 0;
 
 	labeltree(bi->dt);
 
@@ -1337,6 +1337,14 @@
 			found_mainboard_partnumber = 1;
 			fprintf(f, "const char *mainboard_part_number = \"%s\";\n", prop->val.val);
 		}
+		if (streq(prop->name, "mainboard_pci_subsystem_vendor")){
+			found_mainboard_subsys++;
+			fprintf(f, "const u16 mainboard_pci_subsystem_vendor = %s;\n", prop->val.val);
+		}
+		if (streq(prop->name, "mainboard_pci_subsystem_device")){
+			found_mainboard_subsys++;
+			fprintf(f, "const u16 mainboard_pci_subsystem_device = %s;\n", prop->val.val);
+		}
 	}
 
 	if (! 	found_mainboard_vendor){
@@ -1349,6 +1357,20 @@
 			"Please add one."
 			"(and make sure there is a mainboard-vendor property too");
 	}
+	switch (found_mainboard_subsys) {
+	case 0:
+		fprintf(f, "const u16 mainboard_pci_subsystem_vendor = 0;\n");
+		fprintf(f, "const u16 mainboard_pci_subsystem_device = 0;\n");
+		fprintf(f, "const char mainboard_pci_subsystem_set = 0;\n");
+	case 1:
+		die("There is only one of mainboard_pci_subsystem_vendor and "
+		    "mainboard_pci_subsystem_device properties in the root. "
+		    "Please add the other one or remove the existing one.");
+		break;
+	case 2:
+		fprintf(f, "const char mainboard_pci_subsystem_set = 1;\n");
+		break;
+	}
 
 
 	/* emit the code, if any */
@@ -1392,6 +1414,9 @@
 	/* emit any includes that we need  -- TODO: ONLY ONCE PER TYPE*/
 	fprintf(f, "#include <device/device.h>\n#include <device/pci.h>\n");
 	fprintf(f, "extern const char *mainboard_vendor, *mainboard_part_number;\n");
+	fprintf(f, "extern const u16 mainboard_pci_subsystem_vendor;\n");
+	fprintf(f, "extern const u16 mainboard_pci_subsystem_device;\n");
+	fprintf(f, "extern const char mainboard_pci_subsystem_set;\n");
 	flatten_tree_emit_includes(bi->dt, &coreboot_emitter, f, &strbuf, vi);
 
 	flatten_tree_emit_structdecls(bi->dt, &coreboot_emitter, f, &strbuf, vi);


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




From c-d.hailfinger.devel.2006 at gmx.net  Thu Mar  6 01:33:40 2008
From: c-d.hailfinger.devel.2006 at gmx.net (Carl-Daniel Hailfinger)
Date: Thu, 06 Mar 2008 01:33:40 +0100
Subject: [coreboot] [PATCH] v3: Move default mainboard vendor/subsystem
 from Kconfig to dts
In-Reply-To: <47CF38D5.3040608@gmx.net>
References: <13426df10802281040n4afcdce1p1af052b71ce556f1@mail.gmail.com>	<47CEB36E.4010004@gmx.net>	<13426df10803050753h52f8030fjfeee5b678ff8b4e6@mail.gmail.com>	<47CEC43F.8010307@gmx.net>	<13426df10803050810u62fb6b68o3a3d7dc672bdfbe6@mail.gmail.com>	<47CECB60.9060401@gmx.net>	<47CF28F1.3060605@gmx.net>	<13426df10803051527v56be68e2tabfb37141a026ab4@mail.gmail.com>
	<47CF38D5.3040608@gmx.net>
Message-ID: <47CF3BE4.1060200@gmx.net>

On 06.03.2008 01:20, Carl-Daniel Hailfinger wrote:
> Move default mainboard vendor/subsystem from Kconfig to dts.
>
> Signed-off-by: Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006 at gmx.net>
>   

And attached for Ron.

Regards,
Carl-Daniel

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

-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: linuxbios3_mainboard_subsystem_Kconfig_dts.diff
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20080306/53dea8ad/attachment.ksh>

From uwe at hermann-uwe.de  Thu Mar  6 01:34:58 2008
From: uwe at hermann-uwe.de (Uwe Hermann)
Date: Thu, 6 Mar 2008 01:34:58 +0100
Subject: [coreboot] FILO loads image but, Linux doesnt boot
In-Reply-To: <b61da340803051606n39098f55s17a2b065d44e24f9@mail.gmail.com>
References: <b61da340803051606n39098f55s17a2b065d44e24f9@mail.gmail.com>
Message-ID: <20080306003458.GA9750@greenwood>

On Wed, Mar 05, 2008 at 04:06:46PM -0800, Phani Babu Giddi wrote:
> Hello All,
> 
> I am running Coreboot v2 on AMD's db800 with FILO as the payload. It gets to
> a point where it intialzes the kernel but the kernel doesnt boot. Any idea
> whats going on.. I have captured the messages using the serial console. The
> last few messages are...
> 
> linux-34w5:~ # tail minicom.cap
> parse_command_line: initrd=/initrd-2.6.16.46-0.12-default
> parse_command_line: kernel command line (64 bytes): "root=/dev/hda3
> vga=0x317 resume=/dev/hda2 splash=silent showopts"
> load_linux_kernel: offset=0x2000 addr=0x100000 size=0x13158c
> Loading kernel... ok
> file_open: dev=<NULL>, path=/initrd-2.6.16.46-0.12-default
> load_initrd: start=0x1f502000 end=0x1f7aeb32
> Loading initrd... ok
> malloc_diag: alloc: 312 bytes (4 blocks), free: 16064 bytes (1 blocks)
> start_linux: eip=0x100000
> Jumping to entry point...
> 
> Is this the last message that one is suppose to see with coreboot ?

Your kernel command line seems to be

   root=/dev/hda3 vga=0x317    resume=/dev/hda2 splash=silent showopts initrd=/initrd-2.6.16.46-0.12-default

which does not tell the kernel to output messages on the serial console,
thus the output stops there.

Try adding 'console=tty0 console=ttyS0,115200' or similar to the kernel
commandline, and see if it helps.


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



From peter at stuge.se  Thu Mar  6 01:59:46 2008
From: peter at stuge.se (Peter Stuge)
Date: Thu, 6 Mar 2008 01:59:46 +0100
Subject: [coreboot] first output: dbe62 and v3
In-Reply-To: <13426df10803050957i62b8b9b3x9f37a283380c4561@mail.gmail.com>
	<47CED859.2040302@amd.com>
References: <13426df10803042223j425b7e39jf071ca211d7106bd@mail.gmail.com>
	<47CED4C5.6040907@amd.com> <47CEDCDD.6080104@gmx.net>
	<13426df10803050957i62b8b9b3x9f37a283380c4561@mail.gmail.com>
	<13426df10803042223j425b7e39jf071ca211d7106bd@mail.gmail.com>
	<47CED4C5.6040907@amd.com> <47CED859.2040302@amd.com>
Message-ID: <20080306005946.13168.qmail@stuge.se>

On Wed, Mar 05, 2008 at 10:28:57AM -0700, Marc Jones wrote:
> > This would be great. It should be easy to add a dts item and call
> > cs5536_setup_power_button or not.

Yes.


> The simple way to handle this is to move the
> cs5536_setup_power_button call from 5536\stage1.c to the mainboard
> hardware_stage1().

Better to eliminate mainboard code than add more.


> Yes, the dts and kconfig are great for setting things up but
> sometimes platform code is easier.

Then dts and Kconfig are not working well enough.

They (dts really) should be used for all hardware parameters and
behavior description. DisTilled netliSt. :p

The actual code should be in nobr/amd/geodelx or sobr/amd/cs5536
whichever is closer to the truth.

The code should use information entered into the dts.

This is exactly what the dts is for - describing how two mainboards
with the same devices are configured differently.


On Wed, Mar 05, 2008 at 09:57:42AM -0800, ron minnich wrote:
> you really don't want that button working pre stage2, because, if
> the button is hardwired on, the machine turns off in 4 seconds :-)

Agreed.


> So you don't want to "default enable" it. You want to "don't do
> ANYTHING until you are sure". right now code is default enable,
> and I had to comment that out to get dbe62 up.

It used to bite on the alix1c too.


//Peter



From rminnich at gmail.com  Thu Mar  6 02:00:19 2008
From: rminnich at gmail.com (ron minnich)
Date: Wed, 5 Mar 2008 17:00:19 -0800
Subject: [coreboot] [PATCH] v3: Move default mainboard vendor/subsystem
	from Kconfig to dts
In-Reply-To: <47CF38D5.3040608@gmx.net>
References: <13426df10802281040n4afcdce1p1af052b71ce556f1@mail.gmail.com>
	<47CEB36E.4010004@gmx.net>
	<13426df10803050753h52f8030fjfeee5b678ff8b4e6@mail.gmail.com>
	<47CEC43F.8010307@gmx.net>
	<13426df10803050810u62fb6b68o3a3d7dc672bdfbe6@mail.gmail.com>
	<47CECB60.9060401@gmx.net> <47CF28F1.3060605@gmx.net>
	<13426df10803051527v56be68e2tabfb37141a026ab4@mail.gmail.com>
	<47CF38D5.3040608@gmx.net>
Message-ID: <13426df10803051700j590288b4s12c0796d033eae2e@mail.gmail.com>

OK, the thought occurs:

/number,number{
}

and number, number is the thing we want.

Not sure. Just wondering. It fits the scheme.

ron



From peter at stuge.se  Thu Mar  6 02:02:21 2008
From: peter at stuge.se (Peter Stuge)
Date: Thu, 6 Mar 2008 02:02:21 +0100
Subject: [coreboot] Audio mute problem
In-Reply-To: <47CF2272.8000901@gmx.net>
References: <20080305170927.n4n5awqmgwwkkwsw@www.smittys.pointclark.net>
	<47CF2272.8000901@gmx.net>
Message-ID: <20080306010221.13859.qmail@stuge.se>

On Wed, Mar 05, 2008 at 11:45:06PM +0100, Carl-Daniel Hailfinger wrote:
> > seg000:00000000 mov edx, 84Dh
> > seg000:00000005 mov eax, 0C0h ; '+'
> > seg000:0000000A out dx, al
> 
> Write 0xc0 to port 0x84d.

printf '\xc0' | dd of=/dev/port bs=1 seek=$[0x84d]


//Peter



From joe at smittys.pointclark.net  Thu Mar  6 02:16:41 2008
From: joe at smittys.pointclark.net (joe at smittys.pointclark.net)
Date: Wed, 05 Mar 2008 20:16:41 -0500
Subject: [coreboot] Audio mute problem
In-Reply-To: <47CF2272.8000901@gmx.net>
References: <20080305170927.n4n5awqmgwwkkwsw@www.smittys.pointclark.net>
	<47CF2272.8000901@gmx.net>
Message-ID: <20080305201641.av817pd95wss8c4g@www.smittys.pointclark.net>

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

> On 05.03.2008 23:09, joe at smittys.pointclark.net wrote:
>> Hello,
>> The audio on the RM4100 is muted by default. I know the assembly   
>> code  to unmute it but I am not so good with the assembly, could   
>> someone  translate this for me into human???
>>
>> seg000:00000000 mov edx, 84Dh
>> seg000:00000005 mov eax, 0C0h ; '+'
>> seg000:0000000A out dx, al
>>
>
> Write 0xc0 to port 0x84d.
>
> printf '\xc0' | dd of=/dev/port bs=1 seek=$[0x84d]
>
>
Thanks, actually I am doing this in coreboot auto.c:

	outl(0xc0, PME_IO_BASE_ADDR + 0x4d); /* GP3 */

I already have the function setup for other GPIO SuperIO registers.



Thanks - Joe



From jonathanrrogers at gmail.com  Thu Mar  6 02:18:53 2008
From: jonathanrrogers at gmail.com (Jonathan Rogers)
Date: Wed, 05 Mar 2008 20:18:53 -0500
Subject: [coreboot] VGA and Asus a8v-e_se
In-Reply-To: <47CE6786.1000404@assembler.cz>
References: <47CA62D2.3040702@gmail.com>
	<47CA669B.9090202@assembler.cz>	<47CA6B0B.6080804@gmail.com>
	<47CAE831.9070402@assembler.cz>	<47CB1616.6070105@gmail.com>
	<47CB1D6D.9090904@assembler.cz> <47CCCADD.7060908@gmail.com>
	<47CDC901.1040307@assembler.cz> <47CE62F5.8010706@gmail.com>
	<47CE6786.1000404@assembler.cz>
Message-ID: <47CF467D.7010106@gmail.com>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Rudolf Marek wrote:
> For the silent fan, you can use /sys/class/hwmon/... interfacce. Check the
> http://git.kernel.org/?p=linux/kernel/git/stable/linux-2.6.24.y.git;a=blob;f=Documentation/hwmon/w83627ehf;h=ccc2bcb610686aaf44a0d38c5f67db44e8985e82;hb=HEAD
> 
> 
> Not all detailed parameters can be programmed by the driver, but all
> important yes. So you can use "echo " command to programm it. I think
> pwm2 is the CPU FAN header.

Yes, I understand now. Thanks for the pointer. The source file doesn't
seem to say anything about setting pwm[1-4]_enable to 0. Does the
hardware simply not support that? When attempting to write "0" to
pwm[1-4]_enable, I get "write error: Invalid argument", which seems to
be what causes pwmconfig and fancontrol to fail mysteriously. I did
manage to get fancontrol to work by modifying pwmconfig and fancontrol
to ignore that error. Of course, they probably aren't needed if the
w83627ehf can control the fan speed itself.

I have submitted a bug report <URL:http://lm-sensors.org/ticket/2305>
about those scripts, but I'm not sure if it should be considered a bug
in the scripts or in the kernel. Since you're one of the original
authors of the w83627ehf module, I thought you might know. This issue
isn't very high priority, since I now know that either the legacy BIOS
or the Linux w83627ehf driver can enable fan speed control.

I may try to take a crack add adding it to coreboot too, since it
appears that you've already done most of the hard work. Thanks again!

Jonathan Rogers
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFHz0Z8Ms6f82yVS5wRAuAGAJ9yKTREgGYmzyfKfgGfiBb28wBoogCeMAy2
3MyS6/GzAm/AveZNSnhQvBI=
=iXEP
-----END PGP SIGNATURE-----



From phanig at gmail.com  Thu Mar  6 02:19:11 2008
From: phanig at gmail.com (Phani Babu Giddi)
Date: Wed, 5 Mar 2008 17:19:11 -0800
Subject: [coreboot] FILO loads image but, Linux doesnt boot
In-Reply-To: <20080306003458.GA9750@greenwood>
References: <b61da340803051606n39098f55s17a2b065d44e24f9@mail.gmail.com>
	<20080306003458.GA9750@greenwood>
Message-ID: <b61da340803051719n63ff81davf403f1a0fbdb941d@mail.gmail.com>

Hi Uwe,

Thanks for the tip.

Actually Linux was starting and everthing was working fine. Its just that I
cannot see anything on the display. The messages that I get on the serial
console are just similar to what I would get when booting from the commerial
BIOS and GRUB.

What do you think is missing, I was under the impression that VGA ROM is
only required only for the BIOS and the kernel has its own driver.

Let me remove the vga=0x317 and make it normal and see how it goes.

Any other inputs are welcome.

Regards,
Phani

On Wed, Mar 5, 2008 at 4:34 PM, Uwe Hermann <uwe at hermann-uwe.de> wrote:

> On Wed, Mar 05, 2008 at 04:06:46PM -0800, Phani Babu Giddi wrote:
> > Hello All,
> >
> > I am running Coreboot v2 on AMD's db800 with FILO as the payload. It
> gets to
> > a point where it intialzes the kernel but the kernel doesnt boot. Any
> idea
> > whats going on.. I have captured the messages using the serial console.
> The
> > last few messages are...
> >
> > linux-34w5:~ # tail minicom.cap
> > parse_command_line: initrd=/initrd-2.6.16.46-0.12-default
> > parse_command_line: kernel command line (64 bytes): "root=/dev/hda3
> > vga=0x317 resume=/dev/hda2 splash=silent showopts"
> > load_linux_kernel: offset=0x2000 addr=0x100000 size=0x13158c
> > Loading kernel... ok
> > file_open: dev=<NULL>, path=/initrd-2.6.16.46-0.12-default
> > load_initrd: start=0x1f502000 end=0x1f7aeb32
> > Loading initrd... ok
> > malloc_diag: alloc: 312 bytes (4 blocks), free: 16064 bytes (1 blocks)
> > start_linux: eip=0x100000
> > Jumping to entry point...
> >
> > Is this the last message that one is suppose to see with coreboot ?
>
> Your kernel command line seems to be
>
>   root=/dev/hda3 vga=0x317    resume=/dev/hda2 splash=silent showopts
> initrd=/initrd-2.6.16.46-0.12-default
>
> which does not tell the kernel to output messages on the serial console,
> thus the output stops there.
>
> Try adding 'console=tty0 console=ttyS0,115200' or similar to the kernel
> commandline, and see if it helps.
>
>
> Uwe.
> --
> http://www.hermann-uwe.de  | http://www.holsham-traders.de
> http://www.crazy-hacks.org | http://www.unmaintained-free-software.org
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20080305/9c70745d/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: minicom.cap
Type: application/octet-stream
Size: 36878 bytes
Desc: not available
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20080305/9c70745d/attachment.obj>

From peter at stuge.se  Thu Mar  6 02:42:05 2008
From: peter at stuge.se (Peter Stuge)
Date: Thu, 6 Mar 2008 02:42:05 +0100
Subject: [coreboot] FILO loads image but, Linux doesnt boot
In-Reply-To: <b61da340803051719n63ff81davf403f1a0fbdb941d@mail.gmail.com>
References: <b61da340803051606n39098f55s17a2b065d44e24f9@mail.gmail.com>
	<20080306003458.GA9750@greenwood>
	<b61da340803051719n63ff81davf403f1a0fbdb941d@mail.gmail.com>
Message-ID: <20080306014205.22644.qmail@stuge.se>

On Wed, Mar 05, 2008 at 05:19:11PM -0800, Phani Babu Giddi wrote:
> Let me remove the vga=0x317 and make it normal and see how it goes.

vga= may not be appropriate when using the geodelx framebuffer
driver.

Also note that you currently have to patch the geodelx framebuffer
into your kernel manually.

Look into /usr/src/linux/Documentation/fb/


//Peter



From phanig at gmail.com  Thu Mar  6 02:47:27 2008
From: phanig at gmail.com (Phani Babu Giddi)
Date: Wed, 5 Mar 2008 17:47:27 -0800
Subject: [coreboot] FILO loads image but, Linux doesnt boot
In-Reply-To: <20080306014205.22644.qmail@stuge.se>
References: <b61da340803051606n39098f55s17a2b065d44e24f9@mail.gmail.com>
	<20080306003458.GA9750@greenwood>
	<b61da340803051719n63ff81davf403f1a0fbdb941d@mail.gmail.com>
	<20080306014205.22644.qmail@stuge.se>
Message-ID: <b61da340803051747y409935d7sb5aee09a7ecf8fde@mail.gmail.com>

Let me recheck if the geodelx frame buffer is already patched or not. I
think it was patched because X was working for with the commerial BIOS.

-Phani

On Wed, Mar 5, 2008 at 5:42 PM, Peter Stuge <peter at stuge.se> wrote:

> On Wed, Mar 05, 2008 at 05:19:11PM -0800, Phani Babu Giddi wrote:
> > Let me remove the vga=0x317 and make it normal and see how it goes.
>
> vga= may not be appropriate when using the geodelx framebuffer
> driver.
>
> Also note that you currently have to patch the geodelx framebuffer
> into your kernel manually.
>
> Look into /usr/src/linux/Documentation/fb/
>
>
> //Peter
>
> --
> 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/20080305/ccf5f852/attachment.html>

From peter at stuge.se  Thu Mar  6 02:50:41 2008
From: peter at stuge.se (Peter Stuge)
Date: Thu, 6 Mar 2008 02:50:41 +0100
Subject: [coreboot] FILO loads image but, Linux doesnt boot
In-Reply-To: <b61da340803051747y409935d7sb5aee09a7ecf8fde@mail.gmail.com>
References: <b61da340803051606n39098f55s17a2b065d44e24f9@mail.gmail.com>
	<20080306003458.GA9750@greenwood>
	<b61da340803051719n63ff81davf403f1a0fbdb941d@mail.gmail.com>
	<20080306014205.22644.qmail@stuge.se>
	<b61da340803051747y409935d7sb5aee09a7ecf8fde@mail.gmail.com>
Message-ID: <20080306015041.24601.qmail@stuge.se>

On Wed, Mar 05, 2008 at 05:47:27PM -0800, Phani Babu Giddi wrote:
> Let me recheck if the geodelx frame buffer is already patched or
> not. I think it was patched because X was working for with the
> commerial BIOS.

X could be using the VESA driver. There is also an Xorg driver for
the geodelx. Neither depend on kernel framebuffer.


//Peter



From rminnich at gmail.com  Thu Mar  6 02:51:42 2008
From: rminnich at gmail.com (ron minnich)
Date: Wed, 5 Mar 2008 17:51:42 -0800
Subject: [coreboot] patch: powerbutton and com2 for lx
Message-ID: <13426df10803051751qf61a9cbnf7e4c378974c9c4a@mail.gmail.com>

This is tested and working on DBE62.

powerbutton is now in stage2, controlled by dts.

ron
-------------- next part --------------
A non-text attachment was scrubbed...
Name: powerbutton.diff
Type: text/x-patch
Size: 5706 bytes
Desc: not available
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20080305/3c896356/attachment.diff>

From rminnich at gmail.com  Thu Mar  6 03:03:26 2008
From: rminnich at gmail.com (ron minnich)
Date: Wed, 5 Mar 2008 18:03:26 -0800
Subject: [coreboot] FILO loads image but, Linux doesnt boot
In-Reply-To: <20080306015041.24601.qmail@stuge.se>
References: <b61da340803051606n39098f55s17a2b065d44e24f9@mail.gmail.com>
	<20080306003458.GA9750@greenwood>
	<b61da340803051719n63ff81davf403f1a0fbdb941d@mail.gmail.com>
	<20080306014205.22644.qmail@stuge.se>
	<b61da340803051747y409935d7sb5aee09a7ecf8fde@mail.gmail.com>
	<20080306015041.24601.qmail@stuge.se>
Message-ID: <13426df10803051803y5321a82wacd65b84be8d563c@mail.gmail.com>

On Wed, Mar 5, 2008 at 5:50 PM, Peter Stuge <peter at stuge.se> wrote:
> On Wed, Mar 05, 2008 at 05:47:27PM -0800, Phani Babu Giddi wrote:
>  > Let me recheck if the geodelx frame buffer is already patched or
>  > not. I think it was patched because X was working for with the
>  > commerial BIOS.
>
>  X could be using the VESA driver. There is also an Xorg driver for
>  the geodelx. Neither depend on kernel framebuffer.


can someone remind me:do we need a special VSA to make the Linux geode
lx framebuffer driver work?

Phani, do you want my .config that works with linux and brings up the
frame buffer? it is for 2.6.24.2

ron



From phanig at gmail.com  Thu Mar  6 03:46:07 2008
From: phanig at gmail.com (Phani Babu Giddi)
Date: Wed, 5 Mar 2008 18:46:07 -0800
Subject: [coreboot] FILO loads image but, Linux doesnt boot
In-Reply-To: <13426df10803051803y5321a82wacd65b84be8d563c@mail.gmail.com>
References: <b61da340803051606n39098f55s17a2b065d44e24f9@mail.gmail.com>
	<20080306003458.GA9750@greenwood>
	<b61da340803051719n63ff81davf403f1a0fbdb941d@mail.gmail.com>
	<20080306014205.22644.qmail@stuge.se>
	<b61da340803051747y409935d7sb5aee09a7ecf8fde@mail.gmail.com>
	<20080306015041.24601.qmail@stuge.se>
	<13426df10803051803y5321a82wacd65b84be8d563c@mail.gmail.com>
Message-ID: <b61da340803051846s3cf8dc4bg3871301c08d0a628@mail.gmail.com>

Hi Ron,

Yeah please provide me the .config that will defnitely help me.

Regards,
Phani


On Wed, Mar 5, 2008 at 6:03 PM, ron minnich <rminnich at gmail.com> wrote:

> On Wed, Mar 5, 2008 at 5:50 PM, Peter Stuge <peter at stuge.se> wrote:
> > On Wed, Mar 05, 2008 at 05:47:27PM -0800, Phani Babu Giddi wrote:
> >  > Let me recheck if the geodelx frame buffer is already patched or
> >  > not. I think it was patched because X was working for with the
> >  > commerial BIOS.
> >
> >  X could be using the VESA driver. There is also an Xorg driver for
> >  the geodelx. Neither depend on kernel framebuffer.
>
>
> can someone remind me:do we need a special VSA to make the Linux geode
> lx framebuffer driver work?
>
> Phani, do you want my .config that works with linux and brings up the
> frame buffer? it is for 2.6.24.2
>
> ron
>
> --
> 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/20080305/e7aacd90/attachment.html>

From rminnich at gmail.com  Thu Mar  6 03:58:05 2008
From: rminnich at gmail.com (ron minnich)
Date: Wed, 5 Mar 2008 18:58:05 -0800
Subject: [coreboot] add ramtest to lib
Message-ID: <13426df10803051858p742ad2eat74abd735c49cb731@mail.gmail.com>

attached.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: addramtest.diff
Type: text/x-patch
Size: 3102 bytes
Desc: not available
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20080305/fc3d6c83/attachment.diff>

From rminnich at gmail.com  Thu Mar  6 04:07:48 2008
From: rminnich at gmail.com (ron minnich)
Date: Wed, 5 Mar 2008 19:07:48 -0800
Subject: [coreboot] [PATCH] more fake SPD debugging
In-Reply-To: <47CEA26E.7090500@gmx.net>
References: <13426df10803042223j425b7e39jf071ca211d7106bd@mail.gmail.com>
	<47CEA26E.7090500@gmx.net>
Message-ID: <13426df10803051907t1159d703r36b8ab2de055b19d@mail.gmail.com>

Tested and working on both dbe62 and alix1c. I can't commit as I have
other changes pending.

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


On Wed, Mar 5, 2008 at 5:38 AM, Carl-Daniel Hailfinger
<c-d.hailfinger.devel.2006 at gmx.net> wrote:
> On 05.03.2008 07:23, ron minnich wrote:
>  > attached. It dies and I'm sure it is bad ram settings, but it's a start.
>  >
>
>  Yes. Try the following patch.
>
>  Add debugging to fake SPD read functions. We want to know when we try to
>  read from a nonexisting member of the fake SPD.
>
>  Signed-off-by: Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006 at gmx.net>
>
>  Index: LinuxBIOSv3-spd_debug/mainboard/artecgroup/dbe61/initram.c
>  ===================================================================
>  --- LinuxBIOSv3-spd_debug/mainboard/artecgroup/dbe61/initram.c  (Revision 631)
>  +++ LinuxBIOSv3-spd_debug/mainboard/artecgroup/dbe61/initram.c  (Arbeitskopie)
>  @@ -97,7 +97,7 @@
>         /* returns 0xFF on any failures */
>         u8 ret = 0xff;
>
>  -       printk(BIOS_DEBUG, "spd_read_byte dev %04x\n", device);
>  +       printk(BIOS_DEBUG, "spd_read_byte dev %04x", device);
>         if (device == DIMM0) {
>                 for (i = 0; i < ARRAY_SIZE(spd_table); i++) {
>                         if (spd_table[i].address == address) {
>  @@ -105,6 +105,9 @@
>                         }
>                 }
>         }
>  +       if (i == ARRAY_SIZE(spd_table))
>  +               printk(BIOS_DEBUG, " addr %02x does not exist in SPD table",
>  +                       address);
>
>         printk(BIOS_DEBUG, " addr %02x returns %02x\n", address, ret);
>         return ret;
>  Index: LinuxBIOSv3-spd_debug/mainboard/artecgroup/dbe62/initram.c
>  ===================================================================
>  --- LinuxBIOSv3-spd_debug/mainboard/artecgroup/dbe62/initram.c  (Revision 631)
>  +++ LinuxBIOSv3-spd_debug/mainboard/artecgroup/dbe62/initram.c  (Arbeitskopie)
>  @@ -87,7 +87,7 @@
>         /* returns 0xFF on any failures */
>         u8 ret = 0xff;
>
>  -       printk(BIOS_DEBUG, "spd_read_byte dev %04x\n", device);
>  +       printk(BIOS_DEBUG, "spd_read_byte dev %04x", device);
>         if (device == DIMM0) {
>                 for (i = 0; i < ARRAY_SIZE(spd_table); i++) {
>                         if (spd_table[i].address == address) {
>  @@ -95,6 +95,9 @@
>                         }
>                 }
>         }
>  +       if (i == ARRAY_SIZE(spd_table))
>  +               printk(BIOS_DEBUG, " addr %02x does not exist in SPD table",
>  +                       address);
>
>         printk(BIOS_DEBUG, " addr %02x returns %02x\n", address, ret);
>         return ret;
>  Index: LinuxBIOSv3-spd_debug/mainboard/pcengines/alix1c/initram.c
>  ===================================================================
>  --- LinuxBIOSv3-spd_debug/mainboard/pcengines/alix1c/initram.c  (Revision 631)
>  +++ LinuxBIOSv3-spd_debug/mainboard/pcengines/alix1c/initram.c  (Arbeitskopie)
>  @@ -97,7 +97,7 @@
>         /* returns 0xFF on any failures */
>         u8 ret = 0xff;
>
>  -       printk(BIOS_DEBUG, "spd_read_byte dev %04x\n", device);
>  +       printk(BIOS_DEBUG, "spd_read_byte dev %04x", device);
>         if (device == DIMM0) {
>                 for (i = 0; i < ARRAY_SIZE(spd_table); i++) {
>                         if (spd_table[i].address == address) {
>  @@ -105,6 +105,9 @@
>                         }
>                 }
>         }
>  +       if (i == ARRAY_SIZE(spd_table))
>  +               printk(BIOS_DEBUG, " addr %02x does not exist in SPD table",
>  +                       address);
>
>         printk(BIOS_DEBUG, " addr %02x returns %02x\n", address, ret);
>         return ret;
>
>
>  --
>  http://www.hailfinger.org/
>
>



From rminnich at gmail.com  Thu Mar  6 04:13:28 2008
From: rminnich at gmail.com (ron minnich)
Date: Wed, 5 Mar 2008 19:13:28 -0800
Subject: [coreboot] programming 101
Message-ID: <13426df10803051913k5051f46dp503522bd423ec9f8@mail.gmail.com>

how the hell did we miss this:
        if (device == DIMM0) {
                for (i = 0; i < ARRAY_SIZE(spd_table); i++) {
                        if (spd_table[i].address == address) {
                                ret = spd_table[i].data;
                        }
                }
        }
        if (i == ARRAY_SIZE(spd_table))
                printk(BIOS_DEBUG, " addr %02x does not exist in SPD table",
                        address);


So, maybe we need a break in there? As it is, it always prints that
things are not found :-)

thanks

ron



From rminnich at gmail.com  Thu Mar  6 04:22:30 2008
From: rminnich at gmail.com (ron minnich)
Date: Wed, 5 Mar 2008 19:22:30 -0800
Subject: [coreboot] [PATCH] more fake SPD debugging
In-Reply-To: <13426df10803051907t1159d703r36b8ab2de055b19d@mail.gmail.com>
References: <13426df10803042223j425b7e39jf071ca211d7106bd@mail.gmail.com>
	<47CEA26E.7090500@gmx.net>
	<13426df10803051907t1159d703r36b8ab2de055b19d@mail.gmail.com>
Message-ID: <13426df10803051922gc92330ev4e75f0f9f54aaa04@mail.gmail.com>

On Wed, Mar 5, 2008 at 7:07 PM, ron minnich <rminnich at gmail.com> wrote:
> Tested and working on both dbe62 and alix1c. I can't commit as I have
>  other changes pending.
>
>  Acked-by: Ronald G. Minnich <rminnich at gmail.com>
>
>

Let me retract this ack until I fix the code. Don't commit it.

Thanks

ron



From rminnich at gmail.com  Thu Mar  6 06:15:28 2008
From: rminnich at gmail.com (ron minnich)
Date: Wed, 5 Mar 2008 21:15:28 -0800
Subject: [coreboot] denver summit, preliminary schedule
Message-ID: <13426df10803052115l216ec5d5v721bcd5fb53085c2@mail.gmail.com>

OK,first news, AMD is now a "Silver" sponsor of the Denver summit. I
can not thank AMD enough. I don't know
if all of us put together can thank AMD enough. But, we should try!

Thanks, AMD!

Here is a very tentative schedule. I think it's going to be pretty
exciting, I intend to bring as much hardware
as I can for us to work on. I still need to line up breaks, lunch,
dinner, etc. with the main workshop; this is
still a bit tentative.


1-2 Ron opens the meeting and discusses how things went in '07 and
late '06 from the last meeting.
I think the Big News is the meteoric rise of v3, how nice it is, and
the growth in our platforms.
Also talk about other things I learned from talks with vendors.
You'll be amazed by something I learned at SC 07 ...

2-230 break

230-400 Stepan talks about
-  the automated testbed, what it is, how to set it up. The automated
testbed is a quite amazing resource we
   should all understand.
- the GSOC projects
- his work with the german army
- his recent ports

4-430 break
430-rest of day hack session  -- Please, bring your hardware!

Friday

0830-1000 AMD talks about:
- consumer issues
- what's going on
- new ports this year
- "Fam 10".
- Jordan's fantastic new library and his use of Uwe's micro-curses
1000-1030 break
1030-1200 Marc talks about his work at Sun with the simulator
1200-0130 lunch
0130- 0300 an overview of v3, from the smallest to the large bits.
Sample v3 build/burn session
0300-0330 break
0330- 0400
open questions (please add some)
1. how do we tell when a board is good enough to move from v2 to v3?
What's the test?
2. How do we make life easy for vendors?
3. What pending issues are there.

0400-0500 The view from the FSF -- what's going on, etc.

Note: I hope to have one or two more hardware speakers. I welcome
volunteers from this list. We're a friendly
group and always interested in hearing more.

saturday -- hack, hack, hack. Please bring hardware for this session.
We hope to really do more improvement on v3!
sunday -- more hacking at starbucks :-) (but Ron has to leave, sadly,
about 3 or 4 pm)

Hope to see you there. This is going to be a good one.

Thanks

ron



From mercury at wirebros.com  Thu Mar  6 07:12:54 2008
From: mercury at wirebros.com (Jacek Chruscik)
Date: Thu, 06 Mar 2008 00:12:54 -0600
Subject: [coreboot] Problems with VIA EPIA-ME6000
In-Reply-To: <200803041442.19732.klaus123@ibnoetzold.de>
References: <200803031520.56570.klaus123@ibnoetzold.de>
	<200803040831.23138.klaus123@ibnoetzold.de>
	<20080304115054.GA17625@greenwood>
	<200803041442.19732.klaus123@ibnoetzold.de>
Message-ID: <1204783974.6732.13.camel@xx>


On Tue, 2008-03-04 at 14:42 +0100, Klaus Stammermann wrote:
> Am Dienstag, 4. M?rz 2008 12:50 schrieb Uwe Hermann:
> > On Tue, Mar 04, 2008 at 08:31:23AM +0100, Klaus Stammermann wrote:
> > > Am Montag, 3. M?rz 2008 21:33 schrieben Sie:
> > > > * Klaus Stammermann <klaus123 at ibnoetzold.de> [080303 15:20]:
> > > > > Hi there
> > > > >
> > > > > I have some trouble to use coreboot on my VIA EPIA-ME6000 so I hope
> > > > > someone could give me some hints.
> > > > >
> > > > > With epia-m and filo I can build a bios without vga. This runs till
> > > > > jumping to kernel. This breaks up with an error:
> > > > > Loading kernel... ok
> > > > > "Jumping to entry point...
> > > > > 0
> > > >
> > > > Was the kernel built with serial console support? Was console=ttyS0,...
> > > > specified as a command line option to the kernel?
> > >
> > > Yes, I use following startup parameters:
> > > "hda1:/boot/vmlinuz root=/dev/hda1 console=tty0 console=ttyS0,115200"
> >
> > And you also use 'USE_GRUB = 0'? Otherwise FILO will try to read your
> > menu.lst file from GRUB and ignore the above line.
> >
> > > I did not use that optionroms. But how can I use this optionrom? Where do
> > > I have to put it in my image?
> >
> > I think at the beginning (but someone please correct me if I'm wrong), i.e.
> >
> > cat vga.rom coreboot.com > coreboot_full.rom
> >
> > But you need to tweak the config files too in order to make the
> > coreboot.rom smaller (so there's place for vga.rom).
> >
> 
> I get some problem at making coreboot.rom smaller. Normal and fallback get 
> 128kb before. I tried two different possibilities to get space for it, but 
> both failed.
> 
> I need 57344b. But taking 57344/2 out of both raises error "XIP_ROM_BASE is 
> not multiple of XIP_ROM_SIZE". And reducing one of them about 57344b make 
> breaks because of overleaping sections.
> 
> Is there any overview how to use all these option in Config.lb? I think I 
> don't understand the structur of all these options and their results.
I think you don't really need "normal" image at all.
I was able to compile just "fallback" image (ROM_IMAGE_SIZE 64kB)
with filo payload (~48kB), and tried to save 57344 bytes for vga bios.
This makes ROM_SIZE=204800 , probably hou have to set up FALLBACK_SIZE
to same value, otherwise the build will end up being 131072 (I can't
understand why)
Unfortunately, this does not work, I mean, I compiled rom image of given
size, prepended vga bios, and it gave me exactly 256kB of the image.
The problem is that coreboot boots, then runs vgabios (my screen
initializes), but then fails on filo (cannot load ELF image).
It works fine without vgabios though.
I think there might be some bug in scripts, because buildtarget shows
correct ROM_SIZE, but the build is 128kB if I don't set-up
FALLBACK_SIZE.

good luck


> 
> Klaus
> 




From corey.osgood at gmail.com  Thu Mar  6 08:03:45 2008
From: corey.osgood at gmail.com (Corey Osgood)
Date: Thu, 6 Mar 2008 02:03:45 -0500
Subject: [coreboot] Problems with VIA EPIA-ME6000
In-Reply-To: <1204783974.6732.13.camel@xx>
References: <200803031520.56570.klaus123@ibnoetzold.de>
	<200803040831.23138.klaus123@ibnoetzold.de>
	<20080304115054.GA17625@greenwood>
	<200803041442.19732.klaus123@ibnoetzold.de>
	<1204783974.6732.13.camel@xx>
Message-ID: <dd3c80060803052303l3eb47bb1se24308f93eedb573@mail.gmail.com>

On Thu, Mar 6, 2008 at 1:12 AM, Jacek Chruscik <mercury at wirebros.com> wrote:

>
> On Tue, 2008-03-04 at 14:42 +0100, Klaus Stammermann wrote:
> > Am Dienstag, 4. M?rz 2008 12:50 schrieb Uwe Hermann:
> > > On Tue, Mar 04, 2008 at 08:31:23AM +0100, Klaus Stammermann wrote:
> > > > Am Montag, 3. M?rz 2008 21:33 schrieben Sie:
> > > > > * Klaus Stammermann <klaus123 at ibnoetzold.de> [080303 15:20]:
> > > > > > Hi there
> > > > > >
> > > > > > I have some trouble to use coreboot on my VIA EPIA-ME6000 so I
> hope
> > > > > > someone could give me some hints.
> > > > > >
> > > > > > With epia-m and filo I can build a bios without vga. This runs
> till
> > > > > > jumping to kernel. This breaks up with an error:
> > > > > > Loading kernel... ok
> > > > > > "Jumping to entry point...
> > > > > > 0
> > > > >
> > > > > Was the kernel built with serial console support? Was
> console=ttyS0,...
> > > > > specified as a command line option to the kernel?
> > > >
> > > > Yes, I use following startup parameters:
> > > > "hda1:/boot/vmlinuz root=/dev/hda1 console=tty0
> console=ttyS0,115200"
> > >
> > > And you also use 'USE_GRUB = 0'? Otherwise FILO will try to read your
> > > menu.lst file from GRUB and ignore the above line.
> > >
> > > > I did not use that optionroms. But how can I use this optionrom?
> Where do
> > > > I have to put it in my image?
> > >
> > > I think at the beginning (but someone please correct me if I'm wrong),
> i.e.
> > >
> > > cat vga.rom coreboot.com > coreboot_full.rom
> > >
> > > But you need to tweak the config files too in order to make the
> > > coreboot.rom smaller (so there's place for vga.rom).
> > >
> >
> > I get some problem at making coreboot.rom smaller. Normal and fallback
> get
> > 128kb before. I tried two different possibilities to get space for it,
> but
> > both failed.
> >
> > I need 57344b. But taking 57344/2 out of both raises error "XIP_ROM_BASE
> is
> > not multiple of XIP_ROM_SIZE". And reducing one of them about 57344b
> make
> > breaks because of overleaping sections.
> >
> > Is there any overview how to use all these option in Config.lb? I think
> I
> > don't understand the structur of all these options and their results.
> I think you don't really need "normal" image at all.
> I was able to compile just "fallback" image (ROM_IMAGE_SIZE 64kB)
> with filo payload (~48kB), and tried to save 57344 bytes for vga bios.


You can pad the end of the vga bios with zeros to make it exactly 64k. This
should do it:
$ dd if=/dev/zero of=goop bs=1 count=8192
$ cat vgabios.rom good > vgabios_64k.rom

That gets rid of, or at least eases, the confusion of trying to figure out
fallback and XIP sizes that compile.

This makes ROM_SIZE=204800 , probably hou have to set up FALLBACK_SIZE
> to same value, otherwise the build will end up being 131072 (I can't
> understand why)


Without the normal image, the build system gets confused and doesn't know
that it is supposed to fill another 128k. Pesky bug.


> Unfortunately, this does not work, I mean, I compiled rom image of given
> size, prepended vga bios, and it gave me exactly 256kB of the image.
> The problem is that coreboot boots, then runs vgabios (my screen
> initializes), but then fails on filo (cannot load ELF image).
> It works fine without vgabios though.


This sounds like an issue with the memory setup, VGA is probably claiming
memory that coreboot doesn't know about, so FILO tries to use it, and you
can see how well that would goes. Any chance you have the CLE266 datasheet?


> I think there might be some bug in scripts, because buildtarget shows
> correct ROM_SIZE, but the build is 128kB if I don't set-up
> FALLBACK_SIZE.
>
> good luck


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

From klaus123 at ibnoetzold.de  Thu Mar  6 08:36:09 2008
From: klaus123 at ibnoetzold.de (Klaus Stammermann)
Date: Thu, 6 Mar 2008 08:36:09 +0100 (CET)
Subject: [coreboot] Problems with VIA EPIA-ME6000
In-Reply-To: <47CF23C4.6030500@coresystems.de>
References: <200803031520.56570.klaus123@ibnoetzold.de>	<200803041442.19732.klaus123@ibnoetzold.de>	<20080304152323.GA1533@greenwood>
	<200803041710.41023.klaus123@ibnoetzold.de>
	<47CF23C4.6030500@coresystems.de>
Message-ID: <1715.213.61.222.30.1204788969.squirrel@www.ibnoetzold.de>

> Klaus Stammermann wrote:
>> Here the diff:
>> -----------------------------------------------------------------------------------------------------------------------------------
>> Index: src/mainboard/via/epia-m/Options.lb
>> ==================================================================> ---
>> src/mainboard/via/epia-m/Options.lb	(Revision 3086)
>> +++ src/mainboard/via/epia-m/Options.lb	(Arbeitskopie)
>> @@ -51,8 +51,8 @@
>>  ###
>>  ### Build options
>>  ###
>> -default CONFIG_PCI_ROM_RUN=0
>> -default CONFIG_CONSOLE_VGA=0
>> +default CONFIG_PCI_ROM_RUN=1
>> +default CONFIG_CONSOLE_VGA=1
>>
> This won't work. Epia-M brings its own vm86 based pci option rom
> execution. The above additionally enables x86emu. Unfortunately x86emu
> is not capable of executing the Epia-M option rom. Sorry for the
> confusion.
>
> 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
>

OK, I will try without these options. But if we get coreboot running on
this system we should update the examples for config files. So for others
it would be easier to use coreboot.

Klaus



From traut at gmx.de  Thu Mar  6 09:27:54 2008
From: traut at gmx.de (Martin Trautmann)
Date: Thu, 06 Mar 2008 09:27:54 +0100
Subject: [coreboot] libplayload and coreinfo
In-Reply-To: <20080304224535.GJ11357@cosmic.amd.com>
References: <20080304224535.GJ11357@cosmic.amd.com>
Message-ID: <47CFAB0A.9010307@gmx.de>

Jordan Crouse wrote:

> And to celebrate the good start, how about something practical to
> go with it?  Here is something I call coreinfo:
> 
> http://coreboot.org/~jcrouse/coreinfo_0.1.tar.gz

Thanks!

I'll have to find out about the proper stdio.h include file
or sprintf declaration.

When I use my /usr/include/stdio.h I get redefinitions of
  typedef ?FILE?
and
  struct _IO_FILE

Otherwise without including stdio.h I see
incompatible implicit declaration of built-in function ?sprintf?


Martin



From info at coresystems.de  Thu Mar  6 14:24:27 2008
From: info at coresystems.de (coreboot information)
Date: Thu, 06 Mar 2008 14:24:27 +0100
Subject: [coreboot] r3126 build service
Message-ID: <E1JXG5D-0000tA-JL@khepri.openbios.org>

Dear coreboot readers!

This is the automated build check service of coreboot.

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

Change Log:
Add missing license header to layout.c. The file was written by
Stefan Reinauer for coresystems GmbH in 2005, as confirmed on IRC.

Signed-off-by: Uwe Hermann <uwe at hermann-uwe.de>
Acked-by: Stefan Reinauer <stepan at coresystems.de>



Build Log:
Compilation of amd:serengeti_cheetah_fam10 is still broken
See the error log at http://qa.coreboot.org/log_buildbrd.php?revision=3126&device=serengeti_cheetah_fam10&vendor=amd


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

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

   Best regards,
     coreboot automatic build system





From Qingpei.Wang at amd.com  Thu Mar  6 08:26:08 2008
From: Qingpei.Wang at amd.com (Wang, Qingpei)
Date: Thu, 6 Mar 2008 15:26:08 +0800
Subject: [coreboot] add on
Message-ID: <DD1CC71B621B004FA76856E5129D6B172A34F1@sbjgexmb1.amd.com>

  

 

 

 

 

Jason Wang

Intern

Beijing Technology Development Center

Advanced Micro Devices(AMD)

E-mail:Qingpei.Wang at amd.com <mailto:Qingpei.Wang at amd.com> 

<mailto:i at hotmail.com> 

 

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20080306/069f06d5/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.gif
Type: image/gif
Size: 5999 bytes
Desc: image001.gif
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20080306/069f06d5/attachment.gif>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image002.gif
Type: image/gif
Size: 2493 bytes
Desc: image002.gif
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20080306/069f06d5/attachment-0001.gif>

From stepan at coresystems.de  Thu Mar  6 15:07:02 2008
From: stepan at coresystems.de (Stefan Reinauer)
Date: Thu, 6 Mar 2008 15:07:02 +0100
Subject: [coreboot] Makefile simplification for v3
In-Reply-To: <2831fecf0803051027n113b8ffdl6140c746fd181b66@mail.gmail.com>
References: <2831fecf0803051027n113b8ffdl6140c746fd181b66@mail.gmail.com>
Message-ID: <20080306140702.GA15996@coresystems.de>

* Myles Watson <mylesgw at gmail.com> [080305 19:27]:
>  	$(Q)# QEMU wants bios.bin:
>  	$(Q)# Run "qemu -L build/ -serial stdio -hda /dev/zero".
> -	$(Q)printf "  CP      $(subst $(shell pwd)/,,$(obj)/bios.bin)\n"
> -	$(Q)cp $@ $(obj)/bios.bin
> +	$(Q)# printf "  CP      $(subst $(shell pwd)/,,$(obj)/bios.bin)\n"
> +	$(Q)# cp $@ $(obj)/bios.bin
>  	$(Q)echo "Coreboot ROM Image:" > $(obj)/coreboot.map
>  	$(Q)$(obj)/util/lar/lar -l $(obj)/coreboot.rom >> $(obj)/coreboot.map
>  	$(Q)(echo; echo "Stage 0/1 Map:") >> $(obj)/coreboot.map

I think this sneaked in... Please make sure you don't commit this.

-- 
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 info at coresystems.de  Thu Mar  6 15:28:48 2008
From: info at coresystems.de (coreboot information)
Date: Thu, 06 Mar 2008 15:28:48 +0100
Subject: [coreboot] r3127 build service
Message-ID: <E1JXH5U-0003oe-QJ@khepri.openbios.org>

Dear coreboot readers!

This is the automated build check service of coreboot.

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

Change Log:
Drop some duplicate documentation from the README. The manpage and
'superiotool --help' already provide the same information (trivial).

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



Build Log:
Compilation of amd:serengeti_cheetah_fam10 is still broken
See the error log at http://qa.coreboot.org/log_buildbrd.php?revision=3127&device=serengeti_cheetah_fam10&vendor=amd


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

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

   Best regards,
     coreboot automatic build system





From svn at coreboot.org  Thu Mar  6 17:35:44 2008
From: svn at coreboot.org (svn at coreboot.org)
Date: Thu,  6 Mar 2008 17:35:44 +0100
Subject: [coreboot] r633 - coreboot-v3/lib
Message-ID: <mailman.1251.1355071275.16123.coreboot@coreboot.org>

Author: rminnich
Date: 2008-03-06 17:35:44 +0100 (Thu, 06 Mar 2008)
New Revision: 633

Added:
   coreboot-v3/lib/ramtest.c
Log:
Add ramtest for development.
Signed-off-by: Ronald G. Minnich <rminnich at gmail.com>
Acked-by: Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006 at gmx.net>



Added: coreboot-v3/lib/ramtest.c
===================================================================
--- coreboot-v3/lib/ramtest.c	                        (rev 0)
+++ coreboot-v3/lib/ramtest.c	2008-03-06 16:35:44 UTC (rev 633)
@@ -0,0 +1,108 @@
+/*
+ * This file is part of the coreboot project.
+ *
+ * Copyright (C) 2001 Tyson Sawyer, irobot
+ * Copyright (C) 2008 Ronald G. Minnich
+ *
+ * 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 <types.h>
+#include <lib.h>
+#include <console.h>
+
+
+static void write_phys(unsigned long addr, unsigned long value)
+{
+	volatile unsigned long *ptr;
+	ptr = (void *)addr;
+	*ptr = value;
+}
+
+static unsigned long read_phys(unsigned long addr)
+{
+	volatile unsigned long *ptr;
+	ptr = (void *)addr;
+	return *ptr;
+}
+
+static void ram_fill(unsigned long start, unsigned long stop)
+{
+	unsigned long addr;
+	/* 
+	 * Fill.
+	 */
+	printk(BIOS_DEBUG, "DRAM fill: %lx-%lx\n", start, stop);
+	for(addr = start; addr < stop ; addr += 4) {
+		/* Display address being filled */
+		if (!(addr & 0xffff)) {
+			printk(BIOS_DEBUG, "%lx\r", addr);
+		}
+		write_phys(addr, addr);
+	};
+	/* Display final address */
+	printk(BIOS_DEBUG, "%lx\nDRAM filled\n", addr);
+}
+
+static void ram_verify(unsigned long start, unsigned long stop)
+{
+	unsigned long addr;
+	int i = 0;
+	/* 
+	 * Verify.
+	 */
+	printk(BIOS_DEBUG, "DRAM verify: %lx-%lx\n", start, stop);
+	for(addr = start; addr < stop ; addr += 4) {
+		unsigned long value;
+		/* Display address being tested */
+		if (!(addr & 0xffff)) {
+			printk(BIOS_DEBUG, "%lx\r", addr);
+		}
+		value = read_phys(addr);
+		if (value != addr) {
+			/* Display address with error */
+			printk(BIOS_ERR, "Fail @%lx Read value=%lx\n", 
+				addr, value);
+			i++;
+			if(i>256) {
+				printk(BIOS_ERR, "Aborting.\n");
+				break;
+			}
+		}
+	}
+	/* Display final address */
+	printk(BIOS_DEBUG, "%lx\r", addr);
+	if (i) {
+		printk(BIOS_DEBUG, "\nDRAM did _NOT_ verify!\n");
+	}
+	else {
+		printk(BIOS_DEBUG, "\nDRAM range verified.\n");
+	}
+}
+
+
+void ram_check(unsigned long start, unsigned long stop)
+{
+	/*
+	 * This is much more of a "Is my DRAM properly configured?"
+	 * test than a "Is my DRAM faulty?" test.  Not all bits
+	 * are tested.   -Tyson
+	 */
+	printk(BIOS_DEBUG, "Testing DRAM: %lx-%lx\n", start, stop);
+	ram_fill(start, stop);
+	ram_verify(start, stop);
+	printk(BIOS_DEBUG, "Done.\n");
+}
+




From svn at coreboot.org  Thu Mar  6 19:26:45 2008
From: svn at coreboot.org (svn at coreboot.org)
Date: Thu,  6 Mar 2008 19:26:45 +0100
Subject: [coreboot] r634 - coreboot-v3/lib
Message-ID: <mailman.1252.1355071275.16123.coreboot@coreboot.org>

Author: uwe
Date: 2008-03-06 19:26:45 +0100 (Thu, 06 Mar 2008)
New Revision: 634

Modified:
   coreboot-v3/lib/ram.c
   coreboot-v3/lib/ramtest.c
Log:
Various cosmetic fixes, added Doxygen comments (trivial).

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



Modified: coreboot-v3/lib/ram.c
===================================================================
--- coreboot-v3/lib/ram.c	2008-03-06 16:35:44 UTC (rev 633)
+++ coreboot-v3/lib/ram.c	2008-03-06 18:26:45 UTC (rev 634)
@@ -33,10 +33,11 @@
 	hlt();
 }
 
-/* Northbridge or memory controller code must define these functions */
+/* Northbridge or memory controller code must define these functions. */
 void ram_set_registers(void *ctrl, int i);
 int ram_set_spd_registers(void *ctrl, int i);
 void ram_enable(int controllers, void *ctrl);
+
 /**
  * ram_initialize() is is the main RAM init function.
  *
@@ -45,10 +46,11 @@
  * of making it an empty function.
  *
  * @param controllers How many memory controllers there are.
- * @param ctrl Pointer to the mem control structure. This is a generic pointer, since the 
- *    structure is wholly chip-dependent, and a survey of all the types makes it clear that a common 
- *    struct is not possible. We can not use the device tree here as this code is run before the device tree
- *    is available. 
+ * @param ctrl Pointer to the mem control structure. This is a generic pointer,
+ *             since the structure is wholly chip-dependent, and a survey of
+ *             all the types makes it clear that a common struct is not
+ *             possible. We can not use the device tree here as this code is
+ *             run before the device tree is available. 
  */
 void ram_initialize(int controllers, void *ctrl)
 {
@@ -61,10 +63,10 @@
 		ram_set_registers(ctrl, i);
 	}
 
-	/* Now setup those things we can auto detect. */
+	/* Now setup those things we can auto-detect via SPD. */
 	for (i = 0; i < controllers; i++) {
 		printk(BIOS_INFO,
-		  "Setting SPD based registers of RAM controller %d\n", i);
+		       "Setting SPD based registers of RAM controller %d\n", i);
 		ram_set_spd_registers(ctrl, i);
 	}
 

Modified: coreboot-v3/lib/ramtest.c
===================================================================
--- coreboot-v3/lib/ramtest.c	2008-03-06 16:35:44 UTC (rev 633)
+++ coreboot-v3/lib/ramtest.c	2008-03-06 18:26:45 UTC (rev 634)
@@ -23,7 +23,12 @@
 #include <lib.h>
 #include <console.h>
 
-
+/**
+ * Write a value into memory.
+ *
+ * @param addr The memory address to write to.
+ * @param value The value to write into the specified memory address.
+ */
 static void write_phys(unsigned long addr, unsigned long value)
 {
 	volatile unsigned long *ptr;
@@ -31,6 +36,12 @@
 	*ptr = value;
 }
 
+/**
+ * Read a value from memory.
+ *
+ * @param addr The memory address to read from.
+ * @return The value read from the specified memory address.
+ */
 static unsigned long read_phys(unsigned long addr)
 {
 	volatile unsigned long *ptr;
@@ -38,71 +49,89 @@
 	return *ptr;
 }
 
+/**
+ * Fill the specified RAM area.
+ *
+ * The data which is written into RAM is the address of each memory location.
+ * E.g., we write a value of 0x1234 into address 0x1234, we write 0x1235 into
+ * memory address 0x1235, and so on.
+ *
+ * @param start The beginning of the RAM area.
+ * @param stop The end of the RAM area.
+ */
 static void ram_fill(unsigned long start, unsigned long stop)
 {
 	unsigned long addr;
-	/* 
-	 * Fill.
-	 */
+
 	printk(BIOS_DEBUG, "DRAM fill: %lx-%lx\n", start, stop);
-	for(addr = start; addr < stop ; addr += 4) {
-		/* Display address being filled */
-		if (!(addr & 0xffff)) {
+	for (addr = start; addr < stop; addr += 4) {
+		/* Display address being filled. */
+		if (!(addr & 0xffff))
 			printk(BIOS_DEBUG, "%lx\r", addr);
-		}
 		write_phys(addr, addr);
 	};
-	/* Display final address */
-	printk(BIOS_DEBUG, "%lx\nDRAM filled\n", addr);
+	/* Display final address. */
+	printk(BIOS_DEBUG, "%lx\nDRAM filled.\n", addr);
 }
 
+/**
+ * Verify the specified RAM area.
+ *
+ * This checks whether the specified RAM locations return the "correct" data
+ * as written by ram_fill(). The value at address 0x1234 for example should
+ * be 0x1234, the value of address 0x1235 should be 0x1235, and so on.
+ *
+ * @param start The beginning of the RAM area.
+ * @param stop The end of the RAM area.
+ */
 static void ram_verify(unsigned long start, unsigned long stop)
 {
-	unsigned long addr;
+	unsigned long addr, value;
 	int i = 0;
-	/* 
-	 * Verify.
-	 */
+
 	printk(BIOS_DEBUG, "DRAM verify: %lx-%lx\n", start, stop);
-	for(addr = start; addr < stop ; addr += 4) {
-		unsigned long value;
-		/* Display address being tested */
-		if (!(addr & 0xffff)) {
+	for (addr = start; addr < stop; addr += 4) {
+		/* Display address being tested. */
+		if (!(addr & 0xffff))
 			printk(BIOS_DEBUG, "%lx\r", addr);
-		}
 		value = read_phys(addr);
 		if (value != addr) {
-			/* Display address with error */
-			printk(BIOS_ERR, "Fail @%lx Read value=%lx\n", 
-				addr, value);
+			/* Display address with error. */
+			printk(BIOS_ERR, "Fail @%lx Read value=%lx\n",
+			       addr, value);
 			i++;
-			if(i>256) {
+			/* Abort after 256 verify errors. */
+			if (i > 256) {
 				printk(BIOS_ERR, "Aborting.\n");
 				break;
 			}
 		}
 	}
-	/* Display final address */
+
+	/* Display final address. */
 	printk(BIOS_DEBUG, "%lx\r", addr);
+
 	if (i) {
 		printk(BIOS_DEBUG, "\nDRAM did _NOT_ verify!\n");
-	}
-	else {
+	} else {
 		printk(BIOS_DEBUG, "\nDRAM range verified.\n");
 	}
 }
 
-
+/**
+ * Check whether the specified RAM area verifies correctly, and thus whether
+ * we can be reasonably confident that our DRAM setup is correct.
+ *
+ * This is much more of a "Is my DRAM properly configured?" test than
+ * a "Is my DRAM faulty?" test, though.
+ *
+ * @param start The beginning of the RAM area.
+ * @param stop The end of the RAM area.
+ */
 void ram_check(unsigned long start, unsigned long stop)
 {
-	/*
-	 * This is much more of a "Is my DRAM properly configured?"
-	 * test than a "Is my DRAM faulty?" test.  Not all bits
-	 * are tested.   -Tyson
-	 */
 	printk(BIOS_DEBUG, "Testing DRAM: %lx-%lx\n", start, stop);
 	ram_fill(start, stop);
 	ram_verify(start, stop);
 	printk(BIOS_DEBUG, "Done.\n");
 }
-




From peter at stuge.se  Thu Mar  6 13:56:18 2008
From: peter at stuge.se (Peter Stuge)
Date: Thu, 6 Mar 2008 13:56:18 +0100
Subject: [coreboot] programming 101
In-Reply-To: <13426df10803051913k5051f46dp503522bd423ec9f8@mail.gmail.com>
References: <13426df10803051913k5051f46dp503522bd423ec9f8@mail.gmail.com>
Message-ID: <20080306125618.5985.qmail@stuge.se>

On Wed, Mar 05, 2008 at 07:13:28PM -0800, ron minnich wrote:
> how the hell did we miss this:
>         if (device == DIMM0) {
>                 for (i = 0; i < ARRAY_SIZE(spd_table); i++) {
>                         if (spd_table[i].address == address) {
>                                 ret = spd_table[i].data;
> 
> So, maybe we need a break in there?

Or just return instead of ret = 


Good find!


//Peter



From savchenko at altell.ru  Thu Mar  6 15:58:25 2008
From: savchenko at altell.ru (Mikhail Savchenko)
Date: Thu, 6 Mar 2008 17:58:25 +0300
Subject: [coreboot] Amideco
Message-ID: <004e01c87f9a$885593a0$9900bae0$@ru>

Amideco download site is down, can anybody mail me this util sources? Thank
you!

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

From uwe at hermann-uwe.de  Thu Mar  6 19:35:26 2008
From: uwe at hermann-uwe.de (Uwe Hermann)
Date: Thu, 6 Mar 2008 19:35:26 +0100
Subject: [coreboot] [PATCH] Small lib/ramtest.c fixes
Message-ID: <20080306183526.GC30644@greenwood>

See patch.


Uwe.
-- 
http://www.hermann-uwe.de  | http://www.holsham-traders.de
http://www.crazy-hacks.org | http://www.unmaintained-free-software.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: v3_ramtest_fixes.patch
Type: text/x-diff
Size: 2171 bytes
Desc: not available
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20080306/5186f07d/attachment.bin>

From bgiraut at gmail.com  Thu Mar  6 21:08:19 2008
From: bgiraut at gmail.com (giraut benoit)
Date: Thu, 6 Mar 2008 21:08:19 +0100
Subject: [coreboot] LinuxBios for E-pc C10
In-Reply-To: <13426df10803030747g6075245du30f33a4203a0e58c@mail.gmail.com>
References: <272757430803030715v957eae6r26a3107d0c222cca@mail.gmail.com>
	<13426df10803030747g6075245du30f33a4203a0e58c@mail.gmail.com>
Message-ID: <272757430803061208h35c8b098u1b69c670bd4ae3a5@mail.gmail.com>

Here are the results :

00:00.0 Host bridge: Intel Corporation 82810E DC-133 (GMCH) Graphics Memory
Controller Hub (rev 03)
00:01.0 VGA compatible controller: Intel Corporation 82810E DC-133 (CGC)
Chipset Graphics Controller (rev 03)
00:1e.0 PCI bridge: Intel Corporation 82801AA PCI Bridge (rev 02)
00:1f.0 ISA bridge: Intel Corporation 82801AA ISA Bridge (LPC) (rev 02)
00:1f.1 IDE interface: Intel Corporation 82801AA IDE Controller (rev 02)
00:1f.2 USB Controller: Intel Corporation 82801AA USB Controller (rev 02)
00:1f.3 SMBus: Intel Corporation 82801AA SMBus Controller (rev 02)
00:1f.5 Multimedia audio controller: Intel Corporation 82801AA AC'97 Audio
Controller (rev 02)
01:02.0 Ethernet controller: 3Com Corporation 3c905C-TX/TX-M [Tornado] (rev
78)

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

00:00.0 Host bridge: Intel Corporation 82810E DC-133 (GMCH) Graphics Memory
Controller Hub (rev 03)
    Subsystem: Intel Corporation 82810E DC-133 (GMCH) Graphics Memory
Controller Hub
    Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr-
Stepping- SERR+ FastB2B-
    Status: Cap- 66MHz- UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- <TAbort-
<MAbort+ >SERR- <PERR-
    Latency: 0

00:01.0 VGA compatible controller: Intel Corporation 82810E DC-133 (CGC)
Chipset Graphics Controller (rev 03) (prog-if 00 [VGA])
    Subsystem: Hewlett-Packard Company Unknown device 1243
    Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr-
Stepping- SERR- FastB2B-
    Status: Cap+ 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort-
<TAbort- <MAbort- >SERR- <PERR-
    Latency: 0
    Interrupt: pin A routed to IRQ 10
    Region 0: Memory at e8000000 (32-bit, prefetchable) [size=64M]
    Region 1: Memory at eff80000 (32-bit, non-prefetchable) [size=512K]
    Capabilities: [dc] Power Management version 1
        Flags: PMEClk- DSI+ D1- D2- AuxCurrent=0mA
PME(D0-,D1-,D2-,D3hot-,D3cold-)
        Status: D0 PME-Enable- DSel=0 DScale=0 PME-

00:1e.0 PCI bridge: Intel Corporation 82801AA PCI Bridge (rev 02) (prog-if
00 [Normal decode])
    Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr-
Stepping- SERR+ FastB2B-
    Status: Cap- 66MHz- UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- <TAbort-
<MAbort- >SERR- <PERR-
    Latency: 0
    Bus: primary=00, secondary=01, subordinate=01, sec-latency=32
    I/O behind bridge: 0000b000-0000bfff
    Memory behind bridge: efd00000-efdfffff
    Prefetchable memory behind bridge: e7b00000-e7bfffff
    Secondary status: 66MHz- FastB2B+ ParErr- DEVSEL=medium >TAbort-
<TAbort- <MAbort- <SERR- <PERR-
    BridgeCtl: Parity- SERR+ NoISA- VGA- MAbort- >Reset- FastB2B-

00:1f.0 ISA bridge: Intel Corporation 82801AA ISA Bridge (LPC) (rev 02)
    Control: I/O+ Mem+ BusMaster+ SpecCycle+ MemWINV- VGASnoop- ParErr-
Stepping- SERR- FastB2B-
    Status: Cap- 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort-
<TAbort- <MAbort- >SERR- <PERR-
    Latency: 0

00:1f.1 IDE interface: Intel Corporation 82801AA IDE Controller (rev 02)
(prog-if 80 [Master])
    Subsystem: Intel Corporation 82801AA IDE Controller
    Control: I/O+ Mem- BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr-
Stepping- SERR- FastB2B-
    Status: Cap- 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort-
<TAbort- <MAbort- >SERR- <PERR-
    Latency: 0
    Region 0: [virtual] Memory at 000001f0 (32-bit, non-prefetchable)
[disabled] [size=8]
    Region 1: [virtual] Memory at 000003f0 (type 3, non-prefetchable)
[disabled] [size=1]
    Region 2: [virtual] Memory at 00000170 (32-bit, non-prefetchable)
[disabled] [size=8]
    Region 3: [virtual] Memory at 00000370 (type 3, non-prefetchable)
[disabled] [size=1]
    Region 4: I/O ports at ffa0 [size=16]

00:1f.2 USB Controller: Intel Corporation 82801AA USB Controller (rev 02)
(prog-if 00 [UHCI])
    Subsystem: Intel Corporation 82801AA USB Controller
    Control: I/O+ Mem- BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr-
Stepping- SERR- FastB2B-
    Status: Cap- 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort-
<TAbort- <MAbort- >SERR- <PERR-
    Latency: 0
    Interrupt: pin D routed to IRQ 9
    Region 4: I/O ports at d400 [size=32]

00:1f.3 SMBus: Intel Corporation 82801AA SMBus Controller (rev 02)
    Subsystem: Intel Corporation 82801AA SMBus Controller
    Control: I/O+ Mem- BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr-
Stepping- SERR- FastB2B-
    Status: Cap- 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort-
<TAbort- <MAbort- >SERR- <PERR-
    Interrupt: pin B routed to IRQ 0
    Region 4: I/O ports at 0540 [size=16]

00:1f.5 Multimedia audio controller: Intel Corporation 82801AA AC'97 Audio
Controller (rev 02)
    Subsystem: Hewlett-Packard Company Unknown device 1250
    Control: I/O+ Mem- BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr-
Stepping- SERR- FastB2B-
    Status: Cap- 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort-
<TAbort- <MAbort- >SERR- <PERR-
    Latency: 0
    Interrupt: pin B routed to IRQ 5
    Region 0: I/O ports at dc00 [size=256]
    Region 1: I/O ports at d800 [size=64]

01:02.0 Ethernet controller: 3Com Corporation 3c905C-TX/TX-M [Tornado] (rev
78)
    Subsystem: Hewlett-Packard Company Unknown device 1247
    Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV+ VGASnoop- ParErr-
Stepping- SERR+ FastB2B-
    Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort-
<TAbort- <MAbort- >SERR- <PERR-
    Latency: 64 (2500ns min, 2500ns max), Cache Line Size: 32 bytes
    Interrupt: pin A routed to IRQ 3
    Region 0: I/O ports at bc00 [size=128]
    Region 1: Memory at efdfff80 (32-bit, non-prefetchable) [size=128]
    Expansion ROM at e7b00000 [disabled] [size=128K]
    Capabilities: [dc] Power Management version 2
        Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=0mA
PME(D0+,D1+,D2+,D3hot+,D3cold+)
        Status: D0 PME-Enable- DSel=0 DScale=2 PME-

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

00:00.0 0600: 8086:7124 (rev 03)
00:01.0 0300: 8086:7125 (rev 03)
00:1e.0 0604: 8086:2418 (rev 02)
00:1f.0 0601: 8086:2410 (rev 02)
00:1f.1 0101: 8086:2411 (rev 02)
00:1f.2 0c03: 8086:2412 (rev 02)
00:1f.3 0c05: 8086:2413 (rev 02)
00:1f.5 0401: 8086:2415 (rev 02)
01:02.0 0200: 10b7:9200 (rev 78)


The Super IO is a NSC PC87364

What can i do next because i realy need a linuxbios on the board. The bios
chip can be remove from the motherboard.


thx benoit



2008/3/3, ron minnich <rminnich at gmail.com>:
>
> let's start with an lspci , lspci -v -v -v , lspci -n
>
>
> ron
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20080306/2971eb2d/attachment.html>

From Marc.Jones at AMD.com  Thu Mar  6 17:59:42 2008
From: Marc.Jones at AMD.com (Marc Jones)
Date: Thu, 06 Mar 2008 09:59:42 -0700
Subject: [coreboot] FILO loads image but, Linux doesnt boot
In-Reply-To: <13426df10803051803y5321a82wacd65b84be8d563c@mail.gmail.com>
References: <b61da340803051606n39098f55s17a2b065d44e24f9@mail.gmail.com>	<20080306003458.GA9750@greenwood>	<b61da340803051719n63ff81davf403f1a0fbdb941d@mail.gmail.com>	<20080306014205.22644.qmail@stuge.se>	<b61da340803051747y409935d7sb5aee09a7ecf8fde@mail
Message-ID: <47D022FE.40909@AMD.com>

ron minnich wrote:
> On Wed, Mar 5, 2008 at 5:50 PM, Peter Stuge <peter at stuge.se> wrote:
>   
>> On Wed, Mar 05, 2008 at 05:47:27PM -0800, Phani Babu Giddi wrote:
>>  > Let me recheck if the geodelx frame buffer is already patched or
>>  > not. I think it was patched because X was working for with the
>>  > commerial BIOS.
>>
>>  X could be using the VESA driver. There is also an Xorg driver for
>>  the geodelx. Neither depend on kernel framebuffer.
>>     
>
>
> can someone remind me:do we need a special VSA to make the Linux geode
> lx framebuffer driver work?
>
> Phani, do you want my .config that works with linux and brings up the
> frame buffer? it is for 2.6.24.2
>
> ron
>
>   

Ron,
You need VSA with LX. Not a special VSA. Just the same old one that 
buildrom will pull in for Geode platforms.
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  Thu Mar  6 21:42:21 2008
From: rminnich at gmail.com (ron minnich)
Date: Thu, 6 Mar 2008 12:42:21 -0800
Subject: [coreboot] patch: cumulative LX changes
Message-ID: <13426df10803061242s6d7d0ae9x239f3fba59b9c0af@mail.gmail.com>

This is all from work last night. I'd lke to get these in.

Thanks

ron
-------------- next part --------------
A non-text attachment was scrubbed...
Name: lxdiff.diff
Type: text/x-patch
Size: 11624 bytes
Desc: not available
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20080306/0a45a059/attachment.diff>

From jordan.crouse at amd.com  Thu Mar  6 17:06:29 2008
From: jordan.crouse at amd.com (Jordan Crouse)
Date: Thu, 6 Mar 2008 09:06:29 -0700
Subject: [coreboot] libplayload and coreinfo
In-Reply-To: <47CFAB0A.9010307@gmx.de>
References: <20080304224535.GJ11357@cosmic.amd.com> <47CFAB0A.9010307@gmx.de>
Message-ID: <20080306160629.GA9142@cosmic.amd.com>

On 06/03/08 09:27 +0100, Martin Trautmann wrote:
> Jordan Crouse wrote:
> 
> > And to celebrate the good start, how about something practical to
> > go with it?  Here is something I call coreinfo:
> > 
> > http://coreboot.org/~jcrouse/coreinfo_0.1.tar.gz
> 
> Thanks!
> 
> I'll have to find out about the proper stdio.h include file
> or sprintf declaration.
> 
> When I use my /usr/include/stdio.h I get redefinitions of
>   typedef ?FILE?
> and
>   struct _IO_FILE
> 
> Otherwise without including stdio.h I see
> incompatible implicit declaration of built-in function ?sprintf?

Oops - yep.  sprintf is missing from the header file.

Add:

int sprintf(char * buf, const char *fmt, ...);

to include/libpayload.h

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




From rminnich at gmail.com  Thu Mar  6 21:45:34 2008
From: rminnich at gmail.com (ron minnich)
Date: Thu, 6 Mar 2008 12:45:34 -0800
Subject: [coreboot] [PATCH] Small lib/ramtest.c fixes
In-Reply-To: <20080306183526.GC30644@greenwood>
References: <20080306183526.GC30644@greenwood>
Message-ID: <13426df10803061245q30b6294x454278273005db25@mail.gmail.com>

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

... who is delighted to see Uwe on the list again :-)

ron



From rminnich at gmail.com  Thu Mar  6 17:36:01 2008
From: rminnich at gmail.com (ron minnich)
Date: Thu, 6 Mar 2008 08:36:01 -0800
Subject: [coreboot] add ramtest to lib
In-Reply-To: <47D016DE.2060106@gmx.net>
References: <13426df10803051858p742ad2eat74abd735c49cb731@mail.gmail.com>
	<47D016DE.2060106@gmx.net>
Message-ID: <13426df10803060836o64c5d460j144503a06af17aa5@mail.gmail.com>

On Thu, Mar 6, 2008 at 8:07 AM, Carl-Daniel Hailfinger
<c-d.hailfinger.devel.2006 at gmx.net> wrote:
> On 06.03.2008 03:58, ron minnich wrote:
>  > attached.
>  >
>  > Add ramtest for development.
>  >
>  > Signed-off-by: Ronald G. Minnich <rminnich at gmail.com>
>  >
>
>  Acked-by: Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006 at gmx.net>
>
>
Committed revision 633.



From c-d.hailfinger.devel.2006 at gmx.net  Thu Mar  6 17:07:58 2008
From: c-d.hailfinger.devel.2006 at gmx.net (Carl-Daniel Hailfinger)
Date: Thu, 06 Mar 2008 17:07:58 +0100
Subject: [coreboot] add ramtest to lib
In-Reply-To: <13426df10803051858p742ad2eat74abd735c49cb731@mail.gmail.com>
References: <13426df10803051858p742ad2eat74abd735c49cb731@mail.gmail.com>
Message-ID: <47D016DE.2060106@gmx.net>

On 06.03.2008 03:58, ron minnich wrote:
> attached.
>   
> Add ramtest for development. 
>
> Signed-off-by: Ronald G. Minnich <rminnich at gmail.com>
>   

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




From mylesgw at gmail.com  Thu Mar  6 15:23:45 2008
From: mylesgw at gmail.com (Myles Watson)
Date: Thu, 6 Mar 2008 07:23:45 -0700
Subject: [coreboot] Makefile simplification for v3
In-Reply-To: <20080306140702.GA15996@coresystems.de>
References: <2831fecf0803051027n113b8ffdl6140c746fd181b66@mail.gmail.com>
	<20080306140702.GA15996@coresystems.de>
Message-ID: <019b01c87f95$b1abcc60$b522040a@chimp>



> -----Original Message-----
> From: Stefan Reinauer [mailto:stepan at coresystems.de]
> Sent: Thursday, March 06, 2008 7:07 AM
> To: Myles Watson
> Cc: Coreboot
> Subject: Re: [coreboot] Makefile simplification for v3
> 
> * Myles Watson <mylesgw at gmail.com> [080305 19:27]:
> >  	$(Q)# QEMU wants bios.bin:
> >  	$(Q)# Run "qemu -L build/ -serial stdio -hda /dev/zero".
> > -	$(Q)printf "  CP      $(subst $(shell pwd)/,,$(obj)/bios.bin)\n"
> > -	$(Q)cp $@ $(obj)/bios.bin
> > +	$(Q)# printf "  CP      $(subst $(shell pwd)/,,$(obj)/bios.bin)\n"
> > +	$(Q)# cp $@ $(obj)/bios.bin
> >  	$(Q)echo "Coreboot ROM Image:" > $(obj)/coreboot.map
> >  	$(Q)$(obj)/util/lar/lar -l $(obj)/coreboot.rom >>
> $(obj)/coreboot.map
> >  	$(Q)(echo; echo "Stage 0/1 Map:") >> $(obj)/coreboot.map
> 
> I think this sneaked in... Please make sure you don't commit this.

You're right.  It should be a separate patch.  I'll make sure I don't commit
it with the rest of this patch.  

I think it would be correct to remove it because it is mainboard specific.
Someone who wants to automate testing could use a symbolic link to
coreboot.rom from their BIOS directory.

Myles




From dsedrich at violin-memory.com  Thu Mar  6 18:46:17 2008
From: dsedrich at violin-memory.com (David Edrich)
Date: Thu, 6 Mar 2008 11:46:17 -0600
Subject: [coreboot] qemu error message: "Unrecognized partitioning
	scheme"
In-Reply-To: <2831fecf0803051459g8a361ddk2ee7f6f6a07c595a@mail.gmail.com>
References: <031701c87e48$7e531ba0$7af952e0$@com>	
	<13426df10803041502v37b079a7ob131b1e68f797ee8@mail.gmail.com>	
	<035901c87f02$89a62b90$9cf282b0$@com>
	<2831fecf0803051459g8a361ddk2ee7f6f6a07c595a@mail.gmail.com>
Message-ID: <03bc01c87fb1$fb73fa40$f25beec0$@com>



> -----Original Message-----
> From: Myles Watson [mailto:mylesgw at gmail.com]
> Sent: Wednesday, March 05, 2008 5:00 PM
> To: David Edrich
> Cc: Coreboot
> Subject: Re: [coreboot] qemu error message: "Unrecognized partitioning scheme"
> 
> On Wed, Mar 5, 2008 at 1:50 PM, David Edrich <dsedrich at violin-memory.com> wrote:
> >
> >
> >  > -----Original Message-----
> >  > From: ron minnich [mailto:rminnich at gmail.com]
> >  >
> >  > If it is not partitioned you can boot it raw:
> >  > hda:/boot/filo/menu.lst
> >  >
> >  > Note I left the '3' out
> >  >
> >  [David Edrich] Yes you left the '3' out - I Don't know what that means. Can you tell me where I
> insert this string to make the 'raw'
> >  boot happen?
> 
> He was telling you that hda3:... means look on the 3rd partition.  if
> there are no partitions you use hda:...
> 
> This string should be in filo's Config file.
> 
[David Edrich] So I modified filo to use hda without the '3'. I got additional message mounted extfs2  - which is great I guess
then....
"unrecognized partitioning scheme"
"unrecognized partitioning scheme"
twice... then nothing.

So...Is there anything else to do in filo to make it boot raw?
We added the appropriate menu in the file system in the image.

Does filo recognize only a few partitioning schemes and could we be using then an unusual one? 
All that we did was follow the instructions in the coreboot qemu wiki.
We did no special partitioning to create the image.

Thanks





From rminnich at gmail.com  Thu Mar  6 23:00:35 2008
From: rminnich at gmail.com (ron minnich)
Date: Thu, 6 Mar 2008 14:00:35 -0800
Subject: [coreboot] qemu error message: "Unrecognized partitioning
	scheme"
In-Reply-To: <03bc01c87fb1$fb73fa40$f25beec0$@com>
References: <031701c87e48$7e531ba0$7af952e0$@com>
	<13426df10803041502v37b079a7ob131b1e68f797ee8@mail.gmail.com>
	<035901c87f02$89a62b90$9cf282b0$@com>
	<2831fecf0803051459g8a361ddk2ee7f6f6a07c595a@mail.gmail.com>
	<03bc01c87fb1$fb73fa40$f25beec0$@com>
Message-ID: <13426df10803061400n7f00ee2bte7728f9e475643b9@mail.gmail.com>

david, can you just send me your disk image file?

ron



From ward at gnu.org  Thu Mar  6 23:02:19 2008
From: ward at gnu.org (Ward Vandewege)
Date: Thu, 6 Mar 2008 17:02:19 -0500
Subject: [coreboot] [patch] SST25VF016B (2MB) flash on m57sli (IT8716F).
In-Reply-To: <1204153526.2716.14.camel@amd-x2.grundel>
References: <13426df10801211853m2255bad6v6d0642e1ad888d26@mail.gmail.com>
	<4796056B.8050402@gmx.net>
	<1203371123.2691.12.camel@amd-x2.grundel>
	<20080220043454.GA11430@localdomain>
	<1203546070.3388.27.camel@amd-x2.grundel>
	<1203892642.2735.21.camel@amd-x2.grundel>
	<20080225201053.GA8932@localdomain>
	<1203975379.27008.4.camel@amd-x2.grundel>
	<47C3365D.1040205@gmx.net>
	<1204153526.2716.14.camel@amd-x2.grundel>
Message-ID: <20080306220219.GA28611@localdomain>

Hi Ronald,

On Thu, Feb 28, 2008 at 12:05:26AM +0100, Ronald Hoogenboom wrote:
> I've found a nicer way: make an init_gpio in the superio.c that puts the
> port value in a global var if the PIOROM_STREAM is enabled.

Uhm, ok, but this does not build for me (against r3127)? Looks like the
actual definition of init_gpio is missing from your patch?

I really want this to go into the tree. We'll get there eventually :)

Thanks,
Ward.

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



From phanig at gmail.com  Thu Mar  6 23:39:11 2008
From: phanig at gmail.com (Phani Babu Giddi)
Date: Thu, 6 Mar 2008 14:39:11 -0800
Subject: [coreboot] FILO loads image but, Linux doesnt boot
In-Reply-To: <13426df10803051803y5321a82wacd65b84be8d563c@mail.gmail.com>
References: <b61da340803051606n39098f55s17a2b065d44e24f9@mail.gmail.com>
	<20080306003458.GA9750@greenwood>
	<b61da340803051719n63ff81davf403f1a0fbdb941d@mail.gmail.com>
	<20080306014205.22644.qmail@stuge.se>
	<b61da340803051747y409935d7sb5aee09a7ecf8fde@mail.gmail.com>
	<20080306015041.24601.qmail@stuge.se>
	<13426df10803051803y5321a82wacd65b84be8d563c@mail.gmail.com>
Message-ID: <b61da340803061439w73d94396kf409f6e074c82fba@mail.gmail.com>

Hi Ron,

The Geode frame buffer driver is turned on the .config file SLES 10 SP1
kernel that I have and I am not sure why I cannot see anything on the
screen.

One more thing in the Config.lb file for db800, the pci device id
corresponding to this device has been turned off does that make a
difference. I thought this should be set only when VGA ROM is present
and CONFIG_CONSOLE_VGA and CONFIG_PCI_ROM_RUN is set ?
Regards,
Phani
On Wed, Mar 5, 2008 at 6:03 PM, ron minnich <rminnich at gmail.com> wrote:

> On Wed, Mar 5, 2008 at 5:50 PM, Peter Stuge <peter at stuge.se> wrote:
> > On Wed, Mar 05, 2008 at 05:47:27PM -0800, Phani Babu Giddi wrote:
> >  > Let me recheck if the geodelx frame buffer is already patched or
> >  > not. I think it was patched because X was working for with the
> >  > commerial BIOS.
> >
> >  X could be using the VESA driver. There is also an Xorg driver for
> >  the geodelx. Neither depend on kernel framebuffer.
>
>
> can someone remind me:do we need a special VSA to make the Linux geode
> lx framebuffer driver work?
>
> Phani, do you want my .config that works with linux and brings up the
> frame buffer? it is for 2.6.24.2
>
> ron
>
> --
> 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/20080306/de7f766c/attachment.html>

From corey.osgood at gmail.com  Thu Mar  6 23:53:26 2008
From: corey.osgood at gmail.com (Corey Osgood)
Date: Thu, 6 Mar 2008 17:53:26 -0500
Subject: [coreboot] LinuxBios for E-pc C10
In-Reply-To: <272757430803061208h35c8b098u1b69c670bd4ae3a5@mail.gmail.com>
References: <272757430803030715v957eae6r26a3107d0c222cca@mail.gmail.com>
	<13426df10803030747g6075245du30f33a4203a0e58c@mail.gmail.com>
	<272757430803061208h35c8b098u1b69c670bd4ae3a5@mail.gmail.com>
Message-ID: <dd3c80060803061453p5305b415uf2d87d624f38d589@mail.gmail.com>

The current i810 code and asus/mew-am would be a good place to start, but
you'll need the datasheets too (available on intel.com), because there are
some subtle differences between i810 and i810e. You'll also have to switch
the super IO. If you have any specific questions, feel free to ping me
either on the list or IRC (c_ozzie), I wrote the i810 code but no longer
have the board, and an i810e board but the bios is soldered on and in use
24/7. There are some comments in raminit.c that should tell you what values
need to be harvested from the factory bios.

-Corey

On Thu, Mar 6, 2008 at 3:08 PM, giraut benoit <bgiraut at gmail.com> wrote:

>
> Here are the results :
>
> 00:00.0 Host bridge: Intel Corporation 82810E DC-133 (GMCH) Graphics
> Memory Controller Hub (rev 03)
> 00:01.0 VGA compatible controller: Intel Corporation 82810E DC-133 (CGC)
> Chipset Graphics Controller (rev 03)
> 00:1e.0 PCI bridge: Intel Corporation 82801AA PCI Bridge (rev 02)
> 00:1f.0 ISA bridge: Intel Corporation 82801AA ISA Bridge (LPC) (rev 02)
> 00:1f.1 IDE interface: Intel Corporation 82801AA IDE Controller (rev 02)
> 00:1f.2 USB Controller: Intel Corporation 82801AA USB Controller (rev 02)
> 00:1f.3 SMBus: Intel Corporation 82801AA SMBus Controller (rev 02)
> 00:1f.5 Multimedia audio controller: Intel Corporation 82801AA AC'97 Audio
> Controller (rev 02)
> 01:02.0 Ethernet controller: 3Com Corporation 3c905C-TX/TX-M [Tornado]
> (rev 78)
>
> -------------------------------------------------
>
> 00:00.0 Host bridge: Intel Corporation 82810E DC-133 (GMCH) Graphics
> Memory Controller Hub (rev 03)
>     Subsystem: Intel Corporation 82810E DC-133 (GMCH) Graphics Memory
> Controller Hub
>     Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr-
> Stepping- SERR+ FastB2B-
>     Status: Cap- 66MHz- UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort-
> <TAbort- <MAbort+ >SERR- <PERR-
>     Latency: 0
>
> 00:01.0 VGA compatible controller: Intel Corporation 82810E DC-133 (CGC)
> Chipset Graphics Controller (rev 03) (prog-if 00 [VGA])
>     Subsystem: Hewlett-Packard Company Unknown device 1243
>     Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr-
> Stepping- SERR- FastB2B-
>     Status: Cap+ 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort-
> <TAbort- <MAbort- >SERR- <PERR-
>     Latency: 0
>     Interrupt: pin A routed to IRQ 10
>     Region 0: Memory at e8000000 (32-bit, prefetchable) [size=64M]
>     Region 1: Memory at eff80000 (32-bit, non-prefetchable) [size=512K]
>     Capabilities: [dc] Power Management version 1
>         Flags: PMEClk- DSI+ D1- D2- AuxCurrent=0mA
> PME(D0-,D1-,D2-,D3hot-,D3cold-)
>         Status: D0 PME-Enable- DSel=0 DScale=0 PME-
>
> 00:1e.0 PCI bridge: Intel Corporation 82801AA PCI Bridge (rev 02) (prog-if
> 00 [Normal decode])
>     Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr-
> Stepping- SERR+ FastB2B-
>     Status: Cap- 66MHz- UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort-
> <TAbort- <MAbort- >SERR- <PERR-
>     Latency: 0
>     Bus: primary=00, secondary=01, subordinate=01, sec-latency=32
>     I/O behind bridge: 0000b000-0000bfff
>     Memory behind bridge: efd00000-efdfffff
>     Prefetchable memory behind bridge: e7b00000-e7bfffff
>     Secondary status: 66MHz- FastB2B+ ParErr- DEVSEL=medium >TAbort-
> <TAbort- <MAbort- <SERR- <PERR-
>     BridgeCtl: Parity- SERR+ NoISA- VGA- MAbort- >Reset- FastB2B-
>
> 00:1f.0 ISA bridge: Intel Corporation 82801AA ISA Bridge (LPC) (rev 02)
>     Control: I/O+ Mem+ BusMaster+ SpecCycle+ MemWINV- VGASnoop- ParErr-
> Stepping- SERR- FastB2B-
>     Status: Cap- 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort-
> <TAbort- <MAbort- >SERR- <PERR-
>     Latency: 0
>
> 00:1f.1 IDE interface: Intel Corporation 82801AA IDE Controller (rev 02)
> (prog-if 80 [Master])
>     Subsystem: Intel Corporation 82801AA IDE Controller
>     Control: I/O+ Mem- BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr-
> Stepping- SERR- FastB2B-
>     Status: Cap- 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort-
> <TAbort- <MAbort- >SERR- <PERR-
>     Latency: 0
>     Region 0: [virtual] Memory at 000001f0 (32-bit, non-prefetchable)
> [disabled] [size=8]
>     Region 1: [virtual] Memory at 000003f0 (type 3, non-prefetchable)
> [disabled] [size=1]
>     Region 2: [virtual] Memory at 00000170 (32-bit, non-prefetchable)
> [disabled] [size=8]
>     Region 3: [virtual] Memory at 00000370 (type 3, non-prefetchable)
> [disabled] [size=1]
>     Region 4: I/O ports at ffa0 [size=16]
>
> 00:1f.2 USB Controller: Intel Corporation 82801AA USB Controller (rev 02)
> (prog-if 00 [UHCI])
>     Subsystem: Intel Corporation 82801AA USB Controller
>     Control: I/O+ Mem- BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr-
> Stepping- SERR- FastB2B-
>     Status: Cap- 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort-
> <TAbort- <MAbort- >SERR- <PERR-
>     Latency: 0
>     Interrupt: pin D routed to IRQ 9
>     Region 4: I/O ports at d400 [size=32]
>
> 00:1f.3 SMBus: Intel Corporation 82801AA SMBus Controller (rev 02)
>     Subsystem: Intel Corporation 82801AA SMBus Controller
>     Control: I/O+ Mem- BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr-
> Stepping- SERR- FastB2B-
>     Status: Cap- 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort-
> <TAbort- <MAbort- >SERR- <PERR-
>     Interrupt: pin B routed to IRQ 0
>     Region 4: I/O ports at 0540 [size=16]
>
> 00:1f.5 Multimedia audio controller: Intel Corporation 82801AA AC'97 Audio
> Controller (rev 02)
>     Subsystem: Hewlett-Packard Company Unknown device 1250
>     Control: I/O+ Mem- BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr-
> Stepping- SERR- FastB2B-
>     Status: Cap- 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort-
> <TAbort- <MAbort- >SERR- <PERR-
>     Latency: 0
>     Interrupt: pin B routed to IRQ 5
>     Region 0: I/O ports at dc00 [size=256]
>     Region 1: I/O ports at d800 [size=64]
>
> 01:02.0 Ethernet controller: 3Com Corporation 3c905C-TX/TX-M [Tornado]
> (rev 78)
>     Subsystem: Hewlett-Packard Company Unknown device 1247
>     Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV+ VGASnoop- ParErr-
> Stepping- SERR+ FastB2B-
>     Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort-
> <TAbort- <MAbort- >SERR- <PERR-
>     Latency: 64 (2500ns min, 2500ns max), Cache Line Size: 32 bytes
>     Interrupt: pin A routed to IRQ 3
>     Region 0: I/O ports at bc00 [size=128]
>     Region 1: Memory at efdfff80 (32-bit, non-prefetchable) [size=128]
>     Expansion ROM at e7b00000 [disabled] [size=128K]
>     Capabilities: [dc] Power Management version 2
>         Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=0mA
> PME(D0+,D1+,D2+,D3hot+,D3cold+)
>         Status: D0 PME-Enable- DSel=0 DScale=2 PME-
>
> ------------------------------------------------------------
>
> 00:00.0 0600: 8086:7124 (rev 03)
> 00:01.0 0300: 8086:7125 (rev 03)
> 00:1e.0 0604: 8086:2418 (rev 02)
> 00:1f.0 0601: 8086:2410 (rev 02)
> 00:1f.1 0101: 8086:2411 (rev 02)
> 00:1f.2 0c03: 8086:2412 (rev 02)
> 00:1f.3 0c05: 8086:2413 (rev 02)
> 00:1f.5 0401: 8086:2415 (rev 02)
> 01:02.0 0200: 10b7:9200 (rev 78)
>
>
> The Super IO is a NSC PC87364
>
> What can i do next because i realy need a linuxbios on the board. The bios
> chip can be remove from the motherboard.
>
>
> thx benoit
>
>
>
> 2008/3/3, ron minnich <rminnich at gmail.com>:
> >
> > let's start with an lspci , lspci -v -v -v , lspci -n
> >
> >
> > ron
> >
>
>
> --
> 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/20080306/8c0a2c8a/attachment.html>

From jordan.crouse at amd.com  Thu Mar  6 23:58:37 2008
From: jordan.crouse at amd.com (Jordan Crouse)
Date: Thu, 6 Mar 2008 15:58:37 -0700
Subject: [coreboot] [BUILDROM] Fix memtest bug
Message-ID: <20080306225837.GH11861@cosmic.amd.com>

Fix a bug in memtest - apparently we haven't _ever_ passed the
CFLAGS correctly.  Doesn't anybody ever try the memtest payload? :)

Jordan

-- 
Jordan Crouse
Systems Software Development Engineer 
Advanced Micro Devices, Inc.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: memtest-stack-breakage.patch
Type: text/x-diff
Size: 999 bytes
Desc: not available
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20080306/5d90a71b/attachment.bin>

From c-d.hailfinger.devel.2006 at gmx.net  Fri Mar  7 00:04:11 2008
From: c-d.hailfinger.devel.2006 at gmx.net (Carl-Daniel Hailfinger)
Date: Fri, 07 Mar 2008 00:04:11 +0100
Subject: [coreboot] patch: cumulative LX changes
In-Reply-To: <13426df10803061242s6d7d0ae9x239f3fba59b9c0af@mail.gmail.com>
References: <13426df10803061242s6d7d0ae9x239f3fba59b9c0af@mail.gmail.com>
Message-ID: <47D0786B.8060208@gmx.net>

On 06.03.2008 21:42, ron minnich wrote:
> This is all from work last night. I'd lke to get these in.
>
> This is a cumulative set of fixes for LX800 boards. These are all tested on ALIX 1C and DBE62. 
>
> This includes: 
> - the working power button patch. 
> - onchipuart2 for very early startup -- this will be replaced with a better mechanism soon. 
> - dts mod for powerbutton on cs5536
> - dbe62 dts fix for COM1 setup
> - ram check call in dbe62 initram.c
> - Carl-Daniel's fix to detect incorrect access to spd variables. 
> - more debug prints in geodelx northbridge support code. 
>
> This is cumulative since we're lagging on acks a bit and it's hard to keep this
> stuff all seperated out since it involves a common set of files. I'd like to get
> it acked and in tree today if possible. It's a very small set of lines changed so please
> forgive me for the cumulative nature. 
>
> Thanks
>
> Signed-off-by: Ronald G. Minnich <rminnich at gmail.com>
>   

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

It would be cool if you could add the attached changes on top before 
committing, though. They make cs5536_setup_onchipuart() handle both 
UARTs and add missing break in dbe61 initram.

Regards,
Carl-Daniel

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

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

From dsedrich at violin-memory.com  Fri Mar  7 00:06:24 2008
From: dsedrich at violin-memory.com (David Edrich)
Date: Thu, 6 Mar 2008 17:06:24 -0600
Subject: [coreboot] qemu error message: "Unrecognized partitioning
	scheme"
In-Reply-To: <13426df10803061400n7f00ee2bte7728f9e475643b9@mail.gmail.com>
References: <031701c87e48$7e531ba0$7af952e0$@com>	
	<13426df10803041502v37b079a7ob131b1e68f797ee8@mail.gmail.com>	
	<035901c87f02$89a62b90$9cf282b0$@com>	
	<2831fecf0803051459g8a361ddk2ee7f6f6a07c595a@mail.gmail.com>	
	<03bc01c87fb1$fb73fa40$f25beec0$@com>
	<13426df10803061400n7f00ee2bte7728f9e475643b9@mail.gmail.com>
Message-ID: <040501c87fde$b3642090$1a2c61b0$@com>

It's like 2 Gigabytes. Even if I Tar it, it will be 100's of megs so it doesn't seem practical to send


From uwe at hermann-uwe.de  Fri Mar  7 00:16:06 2008
From: uwe at hermann-uwe.de (Uwe Hermann)
Date: Fri, 7 Mar 2008 00:16:06 +0100
Subject: [coreboot] Makefile simplification for v3
In-Reply-To: <019b01c87f95$b1abcc60$b522040a@chimp>
References: <2831fecf0803051027n113b8ffdl6140c746fd181b66@mail.gmail.com>
	<20080306140702.GA15996@coresystems.de>
	<019b01c87f95$b1abcc60$b522040a@chimp>
Message-ID: <20080306231606.GA15848@greenwood>

On Thu, Mar 06, 2008 at 07:23:45AM -0700, Myles Watson wrote:
> 
> 
> > -----Original Message-----
> > From: Stefan Reinauer [mailto:stepan at coresystems.de]
> > Sent: Thursday, March 06, 2008 7:07 AM
> > To: Myles Watson
> > Cc: Coreboot
> > Subject: Re: [coreboot] Makefile simplification for v3
> > 
> > * Myles Watson <mylesgw at gmail.com> [080305 19:27]:
> > >  	$(Q)# QEMU wants bios.bin:
> > >  	$(Q)# Run "qemu -L build/ -serial stdio -hda /dev/zero".
> > > -	$(Q)printf "  CP      $(subst $(shell pwd)/,,$(obj)/bios.bin)\n"
> > > -	$(Q)cp $@ $(obj)/bios.bin
> > > +	$(Q)# printf "  CP      $(subst $(shell pwd)/,,$(obj)/bios.bin)\n"
> > > +	$(Q)# cp $@ $(obj)/bios.bin
> > >  	$(Q)echo "Coreboot ROM Image:" > $(obj)/coreboot.map
> > >  	$(Q)$(obj)/util/lar/lar -l $(obj)/coreboot.rom >>
> > $(obj)/coreboot.map
> > >  	$(Q)(echo; echo "Stage 0/1 Map:") >> $(obj)/coreboot.map
> > 
> > I think this sneaked in... Please make sure you don't commit this.
> 
> You're right.  It should be a separate patch.  I'll make sure I don't commit
> it with the rest of this patch.  
> 
> I think it would be correct to remove it because it is mainboard specific.
> Someone who wants to automate testing could use a symbolic link to
> coreboot.rom from their BIOS directory.

QEMU expects a file called bios.bin, that's why this is done. Now you
can just type 'qemu -L build ...' and it works. Not critical, but nice
to have, and it doesn't really hurt to leave it in.


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



From uwe at hermann-uwe.de  Fri Mar  7 00:17:19 2008
From: uwe at hermann-uwe.de (Uwe Hermann)
Date: Fri, 7 Mar 2008 00:17:19 +0100
Subject: [coreboot] Amideco
In-Reply-To: <004e01c87f9a$885593a0$9900bae0$@ru>
References: <004e01c87f9a$885593a0$9900bae0$@ru>
Message-ID: <20080306231719.GB15848@greenwood>

On Thu, Mar 06, 2008 at 05:58:25PM +0300, Mikhail Savchenko wrote:
> Amideco download site is down, can anybody mail me this util sources? Thank
> you!

Yes, there are Debian packages, so:

http://ftp.debian.org/debian/pool/main/a/amideco/amideco_0.31e.orig.tar.gz


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



From svn at coreboot.org  Fri Mar  7 00:18:14 2008
From: svn at coreboot.org (svn at coreboot.org)
Date: Fri,  7 Mar 2008 00:18:14 +0100
Subject: [coreboot] r635 - coreboot-v3/lib
Message-ID: <mailman.1254.1355071275.16123.coreboot@coreboot.org>

Author: uwe
Date: 2008-03-07 00:18:13 +0100 (Fri, 07 Mar 2008)
New Revision: 635

Modified:
   coreboot-v3/lib/ramtest.c
Log:
Small fixes for lib/ramtest.c:

 - Don't make write_phys/read_phys static, they can be useful elsewhere.

 - Rename write_phys/read_phys to ram_write_phys/ram_read_phys for
   consistency with the other RAM-related functions.

 - Simplify some parts of the code a bit.

Signed-off-by: Uwe Hermann <uwe at hermann-uwe.de>
Acked-by: Ronald G. Minnich <rminnich at gmail.com>



Modified: coreboot-v3/lib/ramtest.c
===================================================================
--- coreboot-v3/lib/ramtest.c	2008-03-06 18:26:45 UTC (rev 634)
+++ coreboot-v3/lib/ramtest.c	2008-03-06 23:18:13 UTC (rev 635)
@@ -29,7 +29,7 @@
  * @param addr The memory address to write to.
  * @param value The value to write into the specified memory address.
  */
-static void write_phys(unsigned long addr, unsigned long value)
+void ram_write_phys(unsigned long addr, unsigned long value)
 {
 	volatile unsigned long *ptr;
 	ptr = (void *)addr;
@@ -42,7 +42,7 @@
  * @param addr The memory address to read from.
  * @return The value read from the specified memory address.
  */
-static unsigned long read_phys(unsigned long addr)
+unsigned long ram_read_phys(unsigned long addr)
 {
 	volatile unsigned long *ptr;
 	ptr = (void *)addr;
@@ -68,7 +68,7 @@
 		/* Display address being filled. */
 		if (!(addr & 0xffff))
 			printk(BIOS_DEBUG, "%lx\r", addr);
-		write_phys(addr, addr);
+		ram_write_phys(addr, addr);
 	};
 	/* Display final address. */
 	printk(BIOS_DEBUG, "%lx\nDRAM filled.\n", addr);
@@ -94,14 +94,13 @@
 		/* Display address being tested. */
 		if (!(addr & 0xffff))
 			printk(BIOS_DEBUG, "%lx\r", addr);
-		value = read_phys(addr);
+		value = ram_read_phys(addr);
 		if (value != addr) {
 			/* Display address with error. */
 			printk(BIOS_ERR, "Fail @%lx Read value=%lx\n",
 			       addr, value);
-			i++;
 			/* Abort after 256 verify errors. */
-			if (i > 256) {
+			if (++i > 256) {
 				printk(BIOS_ERR, "Aborting.\n");
 				break;
 			}
@@ -111,11 +110,8 @@
 	/* Display final address. */
 	printk(BIOS_DEBUG, "%lx\r", addr);
 
-	if (i) {
-		printk(BIOS_DEBUG, "\nDRAM did _NOT_ verify!\n");
-	} else {
-		printk(BIOS_DEBUG, "\nDRAM range verified.\n");
-	}
+	/* Print whether or not the verify failed. */
+	printk(BIOS_DEBUG, "\nDRAM range %sverified.", i ? "_NOT_ " : "");
 }
 
 /**




From uwe at hermann-uwe.de  Fri Mar  7 00:18:34 2008
From: uwe at hermann-uwe.de (Uwe Hermann)
Date: Fri, 7 Mar 2008 00:18:34 +0100
Subject: [coreboot] [PATCH] Small lib/ramtest.c fixes
In-Reply-To: <13426df10803061245q30b6294x454278273005db25@mail.gmail.com>
References: <20080306183526.GC30644@greenwood>
	<13426df10803061245q30b6294x454278273005db25@mail.gmail.com>
Message-ID: <20080306231834.GC15848@greenwood>

On Thu, Mar 06, 2008 at 12:45:34PM -0800, ron minnich wrote:
> Acked-by: Ronald G. Minnich <rminnich at gmail.com>

Thanks, r635.


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



From rminnich at gmail.com  Fri Mar  7 00:25:31 2008
From: rminnich at gmail.com (ron minnich)
Date: Thu, 6 Mar 2008 15:25:31 -0800
Subject: [coreboot] patch: cumulative LX changes
In-Reply-To: <47D0786B.8060208@gmx.net>
References: <13426df10803061242s6d7d0ae9x239f3fba59b9c0af@mail.gmail.com>
	<47D0786B.8060208@gmx.net>
Message-ID: <13426df10803061525m454e1630o2d4d1de930e83d88@mail.gmail.com>

Carl-daniel, I will test your patch tonight or tomorrow night. I am
going to commit this because I don't like doing cumulative patches.
Your patches look fine, and should work fine, but I really am paranoid
about testing before commit due to recent problems I had.

Thanks for your patience :-)

ron



From uwe at hermann-uwe.de  Fri Mar  7 00:25:55 2008
From: uwe at hermann-uwe.de (Uwe Hermann)
Date: Fri, 7 Mar 2008 00:25:55 +0100
Subject: [coreboot] [PATCH] Merge lib/ramtest.c into lib/ram.c
Message-ID: <20080306232555.GD15848@greenwood>

See patch.


Uwe.
-- 
http://www.hermann-uwe.de  | http://www.holsham-traders.de
http://www.crazy-hacks.org | http://www.unmaintained-free-software.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: v3_merge_ramtest.patch
Type: text/x-diff
Size: 8350 bytes
Desc: not available
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20080307/76eaa469/attachment.bin>

From uwe at hermann-uwe.de  Fri Mar  7 00:31:48 2008
From: uwe at hermann-uwe.de (Uwe Hermann)
Date: Fri, 7 Mar 2008 00:31:48 +0100
Subject: [coreboot] [PATCH] v3: PIRQ table cosmetics
In-Reply-To: <47CDFACE.4040006@gmx.net>
References: <47CDFACE.4040006@gmx.net>
Message-ID: <20080306233148.GE15848@greenwood>

On Wed, Mar 05, 2008 at 02:43:42AM +0100, Carl-Daniel Hailfinger wrote:
> PIRQ table cosmetics/cleanup.
> 
> Signed-off-by: Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006 at gmx.net>

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

(but see below)


> Index: LinuxBIOSv3-db800/mainboard/amd/norwich/irq_tables.h
> ===================================================================
> --- LinuxBIOSv3-db800/mainboard/amd/norwich/irq_tables.h	(Revision 630)
> +++ LinuxBIOSv3-db800/mainboard/amd/norwich/irq_tables.h	(Arbeitskopie)
> @@ -17,17 +17,7 @@
>  * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA  02110-1301 USA
>  */
>  
> -#include <types.h>
> -#include <lib.h>
> -#include <console.h>
> -#include <device/device.h>
> -#include <device/pci.h>
> -#include <string.h>
> -#include <msr.h>
> -#include <io.h>
>  #include <pirq_routing.h>
> -#include <amd_geodelx.h>
> -#include "../../../southbridge/amd/cs5536/cs5536.h"

I assume it's compile-tested that these are not needed?


>  /* Number of slots and devices in the PIR table */
>  #define SLOT_COUNT 6
> @@ -83,13 +73,19 @@
>  	{0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0},	/* u8 rfu[11] */
>  	0x00,			/* Checksum */
>  	{
> -	 /* If you change the number of entries, change the IRQ_SLOT_COUNT above! */
> -	 /* bus, dev|fn,           {link, bitmap},      {link, bitmap},     {link, bitmap},     {link, bitmap},     slot, rfu */
> -	 {0x00, (0x01 << 3) | 0x0, {{L_PIRQA, M_PIRQA}, {0x00, 0x00}, {0x00, 0x00}, {0x00, 0x00}}, 0x0, 0x0},	/* cpu */
> -	 {0x00, (0x0F << 3) | 0x0, {{L_PIRQA, M_PIRQA}, {L_PIRQB, M_PIRQB}, {L_PIRQC, M_PIRQC}, {L_PIRQD, M_PIRQD}}, 0x0, 0x0},	/* chipset */
> -	 {0x00, (0x0D << 3) | 0x0, {{L_PIRQB, M_PIRQB}, {L_PIRQC, M_PIRQC}, {L_PIRQD, M_PIRQD}, {L_PIRQA, M_PIRQA}}, 0x1, 0x0},	/* slot1 */
> -	 {0x00, (0x0E << 3) | 0x0, {{L_PIRQC, M_PIRQC}, {L_PIRQD, M_PIRQD}, {L_PIRQA, M_PIRQA}, {L_PIRQB, M_PIRQB}}, 0x2, 0x0},	/* slot2 */
> -	 {0x00, (0x0B << 3) | 0x0, {{L_PIRQD, M_PIRQD}, {L_PIRQA, M_PIRQA}, {L_PIRQB, M_PIRQB}, {L_PIRQC, M_PIRQC}}, 0x3, 0x0},	/* slot3 */
> -	 {0x00, (0x0C << 3) | 0x0, {{L_PIRQA, M_PIRQA}, {L_PIRQB, M_PIRQB}, {L_PIRQC, M_PIRQC}, {L_PIRQD, M_PIRQD}}, 0x4, 0x0},	/* slot4 */

> +		/* If you change the number of entries, change IRQ_SLOT_COUNT above! */

IRQ_SLOT_COUNT -> SLOT_COUNT


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



From svn at coreboot.org  Fri Mar  7 00:33:59 2008
From: svn at coreboot.org (svn at coreboot.org)
Date: Fri,  7 Mar 2008 00:33:59 +0100
Subject: [coreboot] r636 - in coreboot-v3: include
	mainboard/artecgroup/dbe61 mainboard/artecgroup/dbe62
	mainboard/pcengines/alix1c northbridge/amd/geodelx
	southbridge/amd/cs5536
Message-ID: <mailman.1255.1355071275.16123.coreboot@coreboot.org>

Author: rminnich
Date: 2008-03-07 00:33:59 +0100 (Fri, 07 Mar 2008)
New Revision: 636

Modified:
   coreboot-v3/include/lib.h
   coreboot-v3/mainboard/artecgroup/dbe61/initram.c
   coreboot-v3/mainboard/artecgroup/dbe62/Makefile
   coreboot-v3/mainboard/artecgroup/dbe62/dts
   coreboot-v3/mainboard/artecgroup/dbe62/initram.c
   coreboot-v3/mainboard/artecgroup/dbe62/stage1.c
   coreboot-v3/mainboard/pcengines/alix1c/initram.c
   coreboot-v3/northbridge/amd/geodelx/raminit.c
   coreboot-v3/southbridge/amd/cs5536/cs5536.c
   coreboot-v3/southbridge/amd/cs5536/cs5536.h
   coreboot-v3/southbridge/amd/cs5536/dts
   coreboot-v3/southbridge/amd/cs5536/stage1.c
Log:
 This is a cumulative set of fixes for LX800 boards. These are all tested on ALIX 1C and DBE62.
 This includes:
 - the working power button patch.
 - onchipuart2 for very early startup -- this will be replaced with a better mechanism soon.
 - dts mod for powerbutton on cs5536
 - dbe62 dts fix for COM1 setup
 - ram check call in dbe62 initram.c
 - Carl-Daniel's fix to detect incorrect access to spd variables.
 - more debug prints in geodelx northbridge support code.

 This is cumulative since we're lagging on acks a bit and it's hard to keep this
 stuff all seperated out since it involves a common set of files. I'd like to get
 it acked and in tree today if possible. It's a very small set of lines changed so please
 forgive me for the cumulative nature.

 Thanks

 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/include/lib.h
===================================================================
--- coreboot-v3/include/lib.h	2008-03-06 23:18:13 UTC (rev 635)
+++ coreboot-v3/include/lib.h	2008-03-06 23:33:59 UTC (rev 636)
@@ -36,4 +36,7 @@
 void beep_short(void);
 void beep_long(void);
 
+/* Optional ramtest. */
+void ram_check(unsigned long start, unsigned long stop);
+
 #endif /* LIB_H */

Modified: coreboot-v3/mainboard/artecgroup/dbe61/initram.c
===================================================================
--- coreboot-v3/mainboard/artecgroup/dbe61/initram.c	2008-03-06 23:18:13 UTC (rev 635)
+++ coreboot-v3/mainboard/artecgroup/dbe61/initram.c	2008-03-06 23:33:59 UTC (rev 636)
@@ -97,13 +97,17 @@
 	/* returns 0xFF on any failures */
 	u8 ret = 0xff;
 
-	printk(BIOS_DEBUG, "spd_read_byte dev %04x\n", device);
+	printk(BIOS_DEBUG, "spd_read_byte dev %04x", device);
 	if (device == DIMM0) {
 		for (i = 0; i < ARRAY_SIZE(spd_table); i++) {
 			if (spd_table[i].address == address) {
 				ret = spd_table[i].data;
 			}
 		}
+
+		if (i == ARRAY_SIZE(spd_table))
+			printk(BIOS_DEBUG, " addr %02x does not exist in SPD table",
+				address);
 	}
 
 	printk(BIOS_DEBUG, " addr %02x returns %02x\n", address, ret);

Modified: coreboot-v3/mainboard/artecgroup/dbe62/Makefile
===================================================================
--- coreboot-v3/mainboard/artecgroup/dbe62/Makefile	2008-03-06 23:18:13 UTC (rev 635)
+++ coreboot-v3/mainboard/artecgroup/dbe62/Makefile	2008-03-06 23:33:59 UTC (rev 636)
@@ -23,7 +23,7 @@
 
 INITRAM_OBJ =   $(src)/mainboard/$(MAINBOARDDIR)/initram.c \
 		$(src)/northbridge/amd/geodelx/raminit.c \
-		$(src)/arch/x86/geodelx/geodelx.c
+		$(src)/arch/x86/geodelx/geodelx.c $(src)/lib/ramtest.c
 
 STAGE2_MAINBOARD_OBJ = 
 

Modified: coreboot-v3/mainboard/artecgroup/dbe62/dts
===================================================================
--- coreboot-v3/mainboard/artecgroup/dbe62/dts	2008-03-06 23:18:13 UTC (rev 635)
+++ coreboot-v3/mainboard/artecgroup/dbe62/dts	2008-03-06 23:33:59 UTC (rev 636)
@@ -43,6 +43,12 @@
 			/* GPIO(0-0x20) for INT D:C:B:A, 0xFF=none. 
 			 * See virtual PIC spec. */
 			enable_gpio_int_route = "0x0D0C0700";
+			/* we use com2 since that is on the dongle */
+			com2_enable = "1";
+			/* Set com2 address to be COM1 */
+			com2_address = "0x3f8";
+			/* Set com2 IRQ to be what is usually COM1 */
+			com2_irq = "4";
 		};
 	};
 };

Modified: coreboot-v3/mainboard/artecgroup/dbe62/initram.c
===================================================================
--- coreboot-v3/mainboard/artecgroup/dbe62/initram.c	2008-03-06 23:18:13 UTC (rev 635)
+++ coreboot-v3/mainboard/artecgroup/dbe62/initram.c	2008-03-06 23:33:59 UTC (rev 636)
@@ -53,7 +53,7 @@
 
 /* Save space by using a short list of SPD values used by Geode LX Memory init */
 static const struct spd_entry spd_table[] = {
-	{SPD_ACCEPTABLE_CAS_LATENCIES, 0x10},
+	{SPD_ACCEPTABLE_CAS_LATENCIES, 0xe},
 	{SPD_BANK_DENSITY, 0x40},
 	{SPD_DEVICE_ATTRIBUTES_GENERAL, 0xff},
 	{SPD_MEMORY_TYPE, 7},
@@ -63,7 +63,7 @@
 	{SPD_PRIMARY_SDRAM_WIDTH, 8},
 	{SPD_NUM_DIMM_BANKS, 1},
 	{SPD_NUM_COLUMNS, 0xa},
-	{SPD_NUM_ROWS, 3},
+	{SPD_NUM_ROWS, 13},
 	{SPD_REFRESH, 0x3a},
 	{SPD_SDRAM_CYCLE_TIME_2ND, 60},
 	{SPD_SDRAM_CYCLE_TIME_3RD, 75},
@@ -87,13 +87,18 @@
 	/* returns 0xFF on any failures */
 	u8 ret = 0xff;
 
-	printk(BIOS_DEBUG, "spd_read_byte dev %04x\n", device);
+	printk(BIOS_DEBUG, "spd_read_byte dev %04x", device);
 	if (device == DIMM0) {
 		for (i = 0; i < ARRAY_SIZE(spd_table); i++) {
 			if (spd_table[i].address == address) {
 				ret = spd_table[i].data;
+				break;
 			}
 		}
+
+		if (i == ARRAY_SIZE(spd_table))
+			printk(BIOS_DEBUG, " addr %02x does not exist in SPD table",
+				address);
 	}
 
 	printk(BIOS_DEBUG, " addr %02x returns %02x\n", address, ret);
@@ -147,7 +152,7 @@
 	printk(BIOS_DEBUG, "done sdram enable\n");
 
 	/* Check low memory */
-	/*ram_check(0x00000000, 640*1024); */
+	ram_check(0x00000000, 640*1024);
 
 	printk(BIOS_DEBUG, "stage1 returns\n");
 	return 0;

Modified: coreboot-v3/mainboard/artecgroup/dbe62/stage1.c
===================================================================
--- coreboot-v3/mainboard/artecgroup/dbe62/stage1.c	2008-03-06 23:18:13 UTC (rev 635)
+++ coreboot-v3/mainboard/artecgroup/dbe62/stage1.c	2008-03-06 23:33:59 UTC (rev 636)
@@ -58,7 +58,7 @@
 	 * NOTE: Must do this AFTER the early_setup! It is counting on some
 	 * early MSR setup for the CS5536.
 	 */
-	cs5536_setup_onchipuart();
+	cs5536_setup_onchipuart2();
 }
 
 void mainboard_pre_payload(void)

Modified: coreboot-v3/mainboard/pcengines/alix1c/initram.c
===================================================================
--- coreboot-v3/mainboard/pcengines/alix1c/initram.c	2008-03-06 23:18:13 UTC (rev 635)
+++ coreboot-v3/mainboard/pcengines/alix1c/initram.c	2008-03-06 23:33:59 UTC (rev 636)
@@ -97,13 +97,17 @@
 	/* returns 0xFF on any failures */
 	u8 ret = 0xff;
 
-	printk(BIOS_DEBUG, "spd_read_byte dev %04x\n", device);
+	printk(BIOS_DEBUG, "spd_read_byte dev %04x", device);
 	if (device == DIMM0) {
 		for (i = 0; i < ARRAY_SIZE(spd_table); i++) {
 			if (spd_table[i].address == address) {
 				ret = spd_table[i].data;
+				break;
 			}
 		}
+		if (i == ARRAY_SIZE(spd_table))
+			printk(BIOS_DEBUG, " addr %02x does not exist in SPD table",
+				address);
 	}
 
 	printk(BIOS_DEBUG, " addr %02x returns %02x\n", address, ret);

Modified: coreboot-v3/northbridge/amd/geodelx/raminit.c
===================================================================
--- coreboot-v3/northbridge/amd/geodelx/raminit.c	2008-03-06 23:18:13 UTC (rev 635)
+++ coreboot-v3/northbridge/amd/geodelx/raminit.c	2008-03-06 23:33:59 UTC (rev 636)
@@ -130,6 +130,7 @@
 	/* Module Density * Module Banks */
 	/* Shift to multiply by the number of DIMM banks. */
 	dimm_size <<= (dimm_setting >> CF07_UPPER_D0_MB_SHIFT) & 1;
+	printk(BIOS_DEBUG, "DIMM size is %x\n", dimm_size);
 	banner(BIOS_DEBUG, "BEFORT CTZ");
 	dimm_size = __builtin_ctz(dimm_size);
 	banner(BIOS_DEBUG, "TEST DIMM SIZE>8");
@@ -183,6 +184,7 @@
 	banner(BIOS_DEBUG, "RDMSR CF07");
 	msr = rdmsr(MC_CF07_DATA);
 	banner(BIOS_DEBUG, "WRMSR CF07");
+	printk(BIOS_DEBUG, "CF07(%x): %08x.%08x\n", MC_CF07_DATA, msr.hi, msr.lo);
 	if (dimm == dimm0) {
 		msr.hi &= 0xFFFF0000;
 		msr.hi |= dimm_setting;
@@ -223,6 +225,7 @@
 	/* Turn SPD ns time into MHz. Check what the asm does to this math. */
 	speed = 2 * ((10000 / (((spd_byte0 >> 4) * 10) + (spd_byte0 & 0x0F))));
 
+	printk(BIOS_DEBUG, "ddr max speed is %d\n", speed);
 	/* Current speed > max speed? */
 	if (geode_link_speed() > speed) {
 		printk(BIOS_EMERG, "DIMM overclocked. Check GeodeLink speed\n");
@@ -266,6 +269,7 @@
 	msr = rdmsr(MC_CF07_DATA);
 	msr.lo |= ((rate0 * (geode_link_speed() / 2)) / 16)
 		   << CF07_LOWER_REF_INT_SHIFT;
+	printk(BIOS_DEBUG, "Refresh rate set to %x\n", rate0);
 	wrmsr(MC_CF07_DATA, msr);
 }
 
@@ -385,6 +389,7 @@
 		hlt();
 	}
 
+	printk(BIOS_DEBUG, "Set cas latency to %x\n", spd_byte);
 	msr = rdmsr(MC_CF8F_DATA);
 	msr.lo &= ~(7 << CF8F_LOWER_CAS_LAT_SHIFT);
 	msr.lo |= spd_byte << CF8F_LOWER_CAS_LAT_SHIFT;

Modified: coreboot-v3/southbridge/amd/cs5536/cs5536.c
===================================================================
--- coreboot-v3/southbridge/amd/cs5536/cs5536.c	2008-03-06 23:18:13 UTC (rev 635)
+++ coreboot-v3/southbridge/amd/cs5536/cs5536.c	2008-03-06 23:33:59 UTC (rev 636)
@@ -89,6 +89,26 @@
 };
 
 /**
+ * Power button setup.
+ *
+ * Setup GPIO24, it is the external signal for CS5536 vsb_work_aux which
+ * controls all voltage rails except Vstandby & Vmem. We need to enable
+ * OUT_AUX1 and OUTPUT_ENABLE in this order.
+ *
+ * @param sb The southbridge config structure. 
+ * If GPIO24 is not enabled then soft-off will not work.
+ */
+static void cs5536_setup_power_button(struct southbridge_amd_cs5536_dts_config *sb )
+{
+	if (!sb->power_button)
+		return;
+	/* TODO: Should be a #define? */
+	outl(0x40020000, PMS_IO_BASE + 0x40);
+	outl(GPIOH_24_SET, GPIO_IO_BASE + GPIOH_OUT_AUX1_SELECT);
+	outl(GPIOH_24_SET, GPIO_IO_BASE + GPIOH_OUTPUT_ENABLE);
+}
+
+/**
  * Program ACPI LBAR and initialize ACPI registers.
  */
 static void pm_chipset_init(void)
@@ -617,6 +637,8 @@
 	if (sb->enable_ide)
 		ide_init(dev);
 
+	cs5536_setup_power_button(sb);
+
 	printk(BIOS_SPEW, "cs5536: %s() Exit\n", __FUNCTION__);
 }
 

Modified: coreboot-v3/southbridge/amd/cs5536/cs5536.h
===================================================================
--- coreboot-v3/southbridge/amd/cs5536/cs5536.h	2008-03-06 23:18:13 UTC (rev 635)
+++ coreboot-v3/southbridge/amd/cs5536/cs5536.h	2008-03-06 23:33:59 UTC (rev 636)
@@ -444,6 +444,7 @@
 /* Function prototypes */
 void cs5536_disable_internal_uart(void);
 void cs5536_setup_onchipuart(void);
+void cs5536_setup_onchipuart2(void);
 void cs5536_stage1(void);
 
 #endif /* SOUTHBRIDGE_AMD_CS5536_CS5536_H */

Modified: coreboot-v3/southbridge/amd/cs5536/dts
===================================================================
--- coreboot-v3/southbridge/amd/cs5536/dts	2008-03-06 23:18:13 UTC (rev 635)
+++ coreboot-v3/southbridge/amd/cs5536/dts	2008-03-06 23:33:59 UTC (rev 636)
@@ -56,4 +56,12 @@
 	com2_enable = "0";
 	com2_address = "0x2f8";
 	com2_irq = "3";
+
+	/* enable/disable power button. On systems with no power switch, 
+	 * one usually does not want the button enabled. Example: 
+	 * Alix1C, dbe62, dbe61. If you enable this, and the power is 
+	 * hard-wired, the board will turn off after 4 seconds, which is 
+	 * probably not what you want. 
+	 */
+	power_button = "0";
 };

Modified: coreboot-v3/southbridge/amd/cs5536/stage1.c
===================================================================
--- coreboot-v3/southbridge/amd/cs5536/stage1.c	2008-03-06 23:18:13 UTC (rev 635)
+++ coreboot-v3/southbridge/amd/cs5536/stage1.c	2008-03-06 23:33:59 UTC (rev 636)
@@ -113,23 +113,6 @@
 }
 
 /**
- * Power button setup.
- *
- * Setup GPIO24, it is the external signal for CS5536 vsb_work_aux which
- * controls all voltage rails except Vstandby & Vmem. We need to enable
- * OUT_AUX1 and OUTPUT_ENABLE in this order.
- *
- * If GPIO24 is not enabled then soft-off will not work.
- */
-static void cs5536_setup_power_button(void)
-{
-	/* TODO: Should be a #define? */
-	outl(0x40020000, PMS_IO_BASE + 0x40);
-	outl(GPIOH_24_SET, GPIO_IO_BASE + GPIOH_OUT_AUX1_SELECT);
-	outl(GPIOH_24_SET, GPIO_IO_BASE + GPIOH_OUTPUT_ENABLE);
-}
-
-/**
  * Set the various GPIOs.
  *
  * An unknown question at this point is how general this is to all mainboards.
@@ -239,6 +222,40 @@
 	wrmsr(MDD_UART1_CONF, msr);
 }
 
+void cs5536_setup_onchipuart2(void)
+{
+	struct msr msr;
+
+	/* GPIO4 - UART2_TX */
+	/* Set: Output Enable  (0x4) */
+	outl(GPIOL_4_SET, GPIO_IO_BASE + GPIOL_OUTPUT_ENABLE);
+	/* Set: OUTAUX1 Select (0x10) */
+	outl(GPIOL_4_SET, GPIO_IO_BASE + GPIOL_OUT_AUX1_SELECT);
+	/* GPIO4 - UART2_RX */
+	/* Set: Input Enable   (0x20) */
+	outl(GPIOL_3_SET, GPIO_IO_BASE + GPIOL_INPUT_ENABLE);
+	/* Set: INAUX1 Select  (0x34) */
+	outl(GPIOL_3_SET, GPIO_IO_BASE + GPIOL_IN_AUX1_SELECT);
+
+	/* Set: GPIO 3 + 3 Pull Up  (0x18) */
+	outl(GPIOL_3_SET | GPIOL_4_SET, GPIO_IO_BASE + GPIOL_PULLUP_ENABLE);
+
+	/* set address to 3F8 */
+	msr = rdmsr(MDD_LEG_IO);
+	msr.lo |= 0x7 << 20;
+	wrmsr(MDD_LEG_IO, msr);
+
+	/* Bit 1 = DEVEN (device enable)
+	 * Bit 4 = EN_BANKS (allow access to the upper banks
+	 */
+	msr.lo = (1 << 4) | (1 << 1);
+	msr.hi = 0;
+
+	/* enable COM2 */
+	wrmsr(MDD_UART2_CONF, msr);
+}
+
+
 /**
  * Board setup.
  *
@@ -279,5 +296,4 @@
 	cs5536_setup_iobase();
 	cs5536_setup_smbus_gpio();
 	/* cs5536_enable_smbus(); -- Leave this out for now. */
-	cs5536_setup_power_button();
 }




From rminnich at gmail.com  Fri Mar  7 00:34:20 2008
From: rminnich at gmail.com (ron minnich)
Date: Thu, 6 Mar 2008 15:34:20 -0800
Subject: [coreboot] patch: cumulative LX changes
In-Reply-To: <13426df10803061525m454e1630o2d4d1de930e83d88@mail.gmail.com>
References: <13426df10803061242s6d7d0ae9x239f3fba59b9c0af@mail.gmail.com>
	<47D0786B.8060208@gmx.net>
	<13426df10803061525m454e1630o2d4d1de930e83d88@mail.gmail.com>
Message-ID: <13426df10803061534m5b30ded7ndc0aa12a98027b49@mail.gmail.com>

commited rev 636, will test the other changes asap.

ron



From uwe at hermann-uwe.de  Fri Mar  7 00:45:10 2008
From: uwe at hermann-uwe.de (Uwe Hermann)
Date: Fri, 7 Mar 2008 00:45:10 +0100
Subject: [coreboot] libplayload and coreinfo
In-Reply-To: <20080304224535.GJ11357@cosmic.amd.com>
References: <20080304224535.GJ11357@cosmic.amd.com>
Message-ID: <20080306234510.GF15848@greenwood>

On Tue, Mar 04, 2008 at 03:45:35PM -0700, Jordan Crouse wrote:
> I am happy to release the first proof of concept for libpayload:
> 
> http://coreboot.org/~jcrouse/libpayload_0.1.tar.gz

Great stuff, thanks!


> This is a conglomeration of code from three projects - the 
> payload initialization code from FILO, superb curses code from
> our good friend Uwe Hermann, and various libc and driver bits
> from coreboot-v3.  I combined them together into a library,
> mixed kconfig into the mix and baked at 300F for 2 hours.  This is
> proof of concept code for the most part, and I wouldn't go off
> and put this in your airplane autopilot quite yet, but its a good
> start.
> 
> And to celebrate the good start, how about something practical to
> go with it?  Here is something I call coreinfo:
> 
> http://coreboot.org/~jcrouse/coreinfo_0.1.tar.gz

I think Jordan tested this on SimNow, but I'm happy to confirm that
it runs very nicely on real hardware, in my case on the ASUS A8V-E Deluxe.


FYI: We (or rather: mostly Jordan) are working on a fixed-up libpayload
version which will be BSD-licensed, so commercial users can benefit too.

For that to work, I'm hereby relicensing all my code which is part of
libpayload (tinycurses mostly) under the 3-clause BSD license. The plan
is that the same will happen with code written by Jordan, and the rest
of the currently non-BSD code which is not authored by us will be
shamelessly replaced by code stolen from FreeBSD/OpenBSD/NetBSD
and/or rewritten by us from scratch.

The goal is to have a small, fully-BSD libpayload soon, with each file
having a clear license header. This should then probably go into svn, maybe
under a new 'payloads' directory or so (where other libpayload-based
payloads will also live, e.g. coreinfo, lbmenu, etc).

Also, I'll rework my (long-overdue) GSoC project from last year (lbmenu)
to use libpayload after that is done, and beat it with a stick until it
becomes reasonably suited for real-life usage.
 

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



From mylesgw at gmail.com  Fri Mar  7 00:47:59 2008
From: mylesgw at gmail.com (Myles Watson)
Date: Thu, 6 Mar 2008 16:47:59 -0700
Subject: [coreboot] lar copy patch
Message-ID: <2831fecf0803061547j1888dffem928bd6a4d2c85dda@mail.gmail.com>

This patch adds copy functionality to lar via

lar -L srclar.file

It allows you to use payloads, bootblocks, or other entries from one
lar when creating or adding to another.

changes by file:
util/lar/lar.c:
	change usage
	add srcarchivename parameter for create_lar and add_lar
	add lar_copy functionality to create_lar and add_lar
	add -C keep for using the same compression as srclar
util/lar/lar.h:
	change invalid to invalid_or_keep in algo_strings

util/lar/lib.c:
	pull out function add_entry from add_files
	
util/lar/lib.h:
	add prototypes for add_entry and lar_copy
	change prototype for create_lar (wonder why add_lar doesn't have one)
	fix whitespace

util/lar/stream.c:
	pull out helper function file_in_list_where from file_in_list
	add lar_copy
	
This is a test of the copy functionality of lar.  I'll use C++-style comments
     // here's the original lar file
[myles at orangutan svn]$ build/util/lar/lar -l build/coreboot.rom
  normal/option_table (932 bytes @0x50);loadaddress 0x0 entry 0x0
  normal/initram/segment0 (432 bytes @0x450);loadaddress 0x0 entry 0x0x42
  normal/stage2/segment0 (191792 bytes, zeroes compressed to 1 bytes
@0x650);loadaddress 0x0xa540 entry 0x0x2000
  normal/stage2/segment1 (28172 bytes, lzma compressed to 15083 bytes
@0x6b0);loadaddress 0x0x2000 entry 0x0x2000
  normal/stage2/segment2 (5420 bytes, lzma compressed to 312 bytes
@0x41f0);loadaddress 0x0x9000 entry 0x0x2000
  bootblock (20480 bytes @0xfb000)
Total size = 37688B 36KB (0x9338)

     //create a new 256K lar file called bootblock.rom which has the
same bootblock as coreboot.rom
[myles at orangutan svn]$ build/util/lar/lar -c -s 256K bootblock.rom -L
build/coreboot.rom

     //create a new lar file with uncompressed normal/stage2
[myles at orangutan svn]$ build/util/lar/lar -c -s 256K normal_stage2.rom
-L build/coreboot.rom nocompress:normal/stage2:stage2

     //create a new lar file with lzma compressed normal/init
[myles at orangutan svn]$ build/util/lar/lar -c -s 256K normal_init.rom
-L build/coreboot.rom -C lzma normal/init

     //create a new lar file with normal/opt compressed the same as it was
[myles at orangutan svn]$ build/util/lar/lar -c -s 256K normal_opt.rom -L
build/coreboot.rom -C keep  normal/opt

     //create a new 1M lar using the bootblock in bootblock.rom
[myles at orangutan svn]$ build/util/lar/lar -c -s 1M new.rom -L bootblock.rom

     //add back in the components with the correct compression
[myles at orangutan svn]$ build/util/lar/lar -a new.rom -L normal_opt.rom
-C none normal/
[myles at orangutan svn]$ build/util/lar/lar -a new.rom -L
normal_init.rom -C none normal/init

     //use the verbose switch to see what you're getting
[myles at orangutan svn]$ build/util/lar/lar -av new.rom -L
normal_stage2.rom -C lzma stage2:normal/stage2
... adding stage2:normal/stage2
stage2:normal/stage2 (lzma) matches stage2/segment0 => normal/stage2/segment0.
stage2:normal/stage2 (lzma) matches stage2/segment1 => normal/stage2/segment1.
stage2:normal/stage2 (lzma) matches stage2/segment2 => normal/stage2/segment2.

     //diff the two files
[myles at orangutan svn]$ diff new.rom build/coreboot.rom
 // There's no difference

I think it would be nice if lar would warn you (or stop you) when you
try to add a duplicate entry.  Maybe that will be the next patch.

Myles

Signed-off-by: Myles Watson <mylesgw at gmail.com>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: lar_copy.patch
Type: text/x-patch
Size: 16424 bytes
Desc: not available
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20080306/49a95f3d/attachment.patch>

From uwe at hermann-uwe.de  Fri Mar  7 00:51:55 2008
From: uwe at hermann-uwe.de (Uwe Hermann)
Date: Fri, 7 Mar 2008 00:51:55 +0100
Subject: [coreboot] ASUS A8V-E Deluxe now supported
Message-ID: <20080306235155.GG15848@greenwood>

Hi,

I'm happy to announce that the ASUS A8V-E Deluxe board works pretty well
in coreboot v2 already. I haven't even touched more than 1 (in words: one)
lines of code. This is all thanks to Rudolf Marek's great work on the
ASUS A8V-E SE board, which is very similar to this one.

I've posted the full status table and a small build tutorial in the wiki:

http://www.coreboot.org/ASUS_A8V-E_Deluxe_Build_Tutorial

It boots up to a Linux login prompt, CPU, RAM, SATA (port 1), audio, ethernet,
USB, VGA, and lots of other stuff work fine. Even 'poweroff' and
'reboot' work, probably thanks to the ACPI implementation by Rudolf.

There are some TODOs left (IDE seems to have a problem, SATA port 2
also, and a few other things hasn't yet been tested), I'll work on
fixing them in the next few days or so.


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



From jordan.crouse at amd.com  Fri Mar  7 00:56:16 2008
From: jordan.crouse at amd.com (Jordan Crouse)
Date: Thu, 6 Mar 2008 16:56:16 -0700
Subject: [coreboot] libplayload and coreinfo
In-Reply-To: <20080306234510.GF15848@greenwood>
References: <20080304224535.GJ11357@cosmic.amd.com>
	<20080306234510.GF15848@greenwood>
Message-ID: <20080306235616.GI11861@cosmic.amd.com>

On 07/03/08 00:45 +0100, Uwe Hermann wrote:
> FYI: We (or rather: mostly Jordan) are working on a fixed-up libpayload
> version which will be BSD-licensed, so commercial users can benefit too.
> 
> For that to work, I'm hereby relicensing all my code which is part of
> libpayload (tinycurses mostly) under the 3-clause BSD license. The plan
> is that the same will happen with code written by Jordan, and the rest
> of the currently non-BSD code which is not authored by us will be
> shamelessly replaced by code stolen from FreeBSD/OpenBSD/NetBSD
> and/or rewritten by us from scratch.

Thanks Uwe!

To that end, here's our current status.  If anybody out there is 
bored, pick a feature and start rewriting (or borrow from *BSD).

These are the files of questionable license status from FILO - these need
to be replaced:

./libc/malloc.c
./include/elf_boot.h
./include/arch/io.h
./i386/context.c
./i386/context.h
./i386/segment.c
./i386/segment.h
./i386/switch.S

These are files of known status (all GPLv2) that have been borrowed from
various projects.  These either need to be replaced with BSD versions,
or permission acquired to relicense them:

./libc/memory.c (from coreboot-v3)
./libc/string.c (from coreboot-v3)
./libc/printf.c (from the kernel)
./libc/ipchecksum.c (from coreboot-v3)
./include/checksum.h (from coreboot-v3)
./drivers/serial.c (from coreboot-v3)

Jordan

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




From uwe at hermann-uwe.de  Fri Mar  7 01:02:03 2008
From: uwe at hermann-uwe.de (Uwe Hermann)
Date: Fri, 7 Mar 2008 01:02:03 +0100
Subject: [coreboot] r636 - in coreboot-v3:
	include	mainboard/artecgroup/dbe61
	mainboard/artecgroup/dbe62	mainboard/pcengines/alix1c
	northbridge/amd/geodelx	southbridge/amd/cs5536
In-Reply-To: <E1JXPbL-0000e8-Nk@mi011.mc1.hosteurope.de>
References: <E1JXPbL-0000e8-Nk@mi011.mc1.hosteurope.de>
Message-ID: <20080307000203.GH15848@greenwood>

On Fri, Mar 07, 2008 at 12:33:59AM +0100, svn at coreboot.org wrote:
> Modified: coreboot-v3/mainboard/artecgroup/dbe61/initram.c
> ===================================================================
> --- coreboot-v3/mainboard/artecgroup/dbe61/initram.c	2008-03-06 23:18:13 UTC (rev 635)
> +++ coreboot-v3/mainboard/artecgroup/dbe61/initram.c	2008-03-06 23:33:59 UTC (rev 636)
> @@ -97,13 +97,17 @@
>  	/* returns 0xFF on any failures */
>  	u8 ret = 0xff;
>  
> -	printk(BIOS_DEBUG, "spd_read_byte dev %04x\n", device);
> +	printk(BIOS_DEBUG, "spd_read_byte dev %04x", device);
>  	if (device == DIMM0) {
>  		for (i = 0; i < ARRAY_SIZE(spd_table); i++) {
>  			if (spd_table[i].address == address) {
>  				ret = spd_table[i].data;

No break here?


>  			}
>  		}
> +
> +		if (i == ARRAY_SIZE(spd_table))
> +			printk(BIOS_DEBUG, " addr %02x does not exist in SPD table",
> +				address);
>  	}
>  
>  	printk(BIOS_DEBUG, " addr %02x returns %02x\n", address, ret);
> 


> Modified: coreboot-v3/northbridge/amd/geodelx/raminit.c
> ===================================================================
> --- coreboot-v3/northbridge/amd/geodelx/raminit.c	2008-03-06 23:18:13 UTC (rev 635)
> +++ coreboot-v3/northbridge/amd/geodelx/raminit.c	2008-03-06 23:33:59 UTC (rev 636)
> @@ -130,6 +130,7 @@
>  	/* Module Density * Module Banks */
>  	/* Shift to multiply by the number of DIMM banks. */
>  	dimm_size <<= (dimm_setting >> CF07_UPPER_D0_MB_SHIFT) & 1;
> +	printk(BIOS_DEBUG, "DIMM size is %x\n", dimm_size);
>  	banner(BIOS_DEBUG, "BEFORT CTZ");
>  	dimm_size = __builtin_ctz(dimm_size);
>  	banner(BIOS_DEBUG, "TEST DIMM SIZE>8");
> @@ -183,6 +184,7 @@
>  	banner(BIOS_DEBUG, "RDMSR CF07");
>  	msr = rdmsr(MC_CF07_DATA);
>  	banner(BIOS_DEBUG, "WRMSR CF07");
> +	printk(BIOS_DEBUG, "CF07(%x): %08x.%08x\n", MC_CF07_DATA, msr.hi, msr.lo);
>  	if (dimm == dimm0) {
>  		msr.hi &= 0xFFFF0000;
>  		msr.hi |= dimm_setting;
> @@ -223,6 +225,7 @@
>  	/* Turn SPD ns time into MHz. Check what the asm does to this math. */
>  	speed = 2 * ((10000 / (((spd_byte0 >> 4) * 10) + (spd_byte0 & 0x0F))));
>  
> +	printk(BIOS_DEBUG, "ddr max speed is %d\n", speed);

ddr -> DDR


>  	/* Current speed > max speed? */
>  	if (geode_link_speed() > speed) {
>  		printk(BIOS_EMERG, "DIMM overclocked. Check GeodeLink speed\n");
> @@ -266,6 +269,7 @@
>  	msr = rdmsr(MC_CF07_DATA);
>  	msr.lo |= ((rate0 * (geode_link_speed() / 2)) / 16)
>  		   << CF07_LOWER_REF_INT_SHIFT;
> +	printk(BIOS_DEBUG, "Refresh rate set to %x\n", rate0);
>  	wrmsr(MC_CF07_DATA, msr);
>  }
>  
> @@ -385,6 +389,7 @@
>  		hlt();
>  	}
>  
> +	printk(BIOS_DEBUG, "Set cas latency to %x\n", spd_byte);

cas -> CAS


> Modified: coreboot-v3/southbridge/amd/cs5536/cs5536.h
> ===================================================================
> --- coreboot-v3/southbridge/amd/cs5536/cs5536.h	2008-03-06 23:18:13 UTC (rev 635)
> +++ coreboot-v3/southbridge/amd/cs5536/cs5536.h	2008-03-06 23:33:59 UTC (rev 636)
> @@ -444,6 +444,7 @@
>  /* Function prototypes */
>  void cs5536_disable_internal_uart(void);
>  void cs5536_setup_onchipuart(void);
> +void cs5536_setup_onchipuart2(void);

Is there some more descriptive suffix than "2" for this function?


>  void cs5536_stage1(void);
>  
>  #endif /* SOUTHBRIDGE_AMD_CS5536_CS5536_H */
> 
> @@ -239,6 +222,40 @@
>  	wrmsr(MDD_UART1_CONF, msr);
>  }
>  
> +void cs5536_setup_onchipuart2(void)

Please add a (doxygen-)comment for this function, which should also
mention what is different to cs5536_setup_onchipuart() and why we
need two such functions.


> +{
> +	struct msr msr;
> +
> +	/* GPIO4 - UART2_TX */
> +	/* Set: Output Enable  (0x4) */
> +	outl(GPIOL_4_SET, GPIO_IO_BASE + GPIOL_OUTPUT_ENABLE);
> +	/* Set: OUTAUX1 Select (0x10) */
> +	outl(GPIOL_4_SET, GPIO_IO_BASE + GPIOL_OUT_AUX1_SELECT);
> +	/* GPIO4 - UART2_RX */
> +	/* Set: Input Enable   (0x20) */
> +	outl(GPIOL_3_SET, GPIO_IO_BASE + GPIOL_INPUT_ENABLE);
> +	/* Set: INAUX1 Select  (0x34) */

The (0x4), (0x10), (0x20), (0x34) etc. should be dropped, that's what the
defines are used for. We don't _care_ about the actual numbers here.


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



From rminnich at gmail.com  Fri Mar  7 01:07:14 2008
From: rminnich at gmail.com (ron minnich)
Date: Thu, 6 Mar 2008 16:07:14 -0800
Subject: [coreboot] r636 - in coreboot-v3: include
	mainboard/artecgroup/dbe61 mainboard/artecgroup/dbe62
	mainboard/pcengines/alix1c northbridge/amd/geodelx
	southbridge/amd/cs5536
In-Reply-To: <20080307000203.GH15848@greenwood>
References: <E1JXPbL-0000e8-Nk@mi011.mc1.hosteurope.de>
	<20080307000203.GH15848@greenwood>
Message-ID: <13426df10803061607r568b09b0rd551484b8b584bd3@mail.gmail.com>

Thanks, Uwe, for the comments, I will fix these things in the next
patch, and will add Carl-Daniel's fixes too (which address some of
your comments)

thanks again

ron



From c-d.hailfinger.devel.2006 at gmx.net  Fri Mar  7 01:07:02 2008
From: c-d.hailfinger.devel.2006 at gmx.net (Carl-Daniel Hailfinger)
Date: Fri, 07 Mar 2008 01:07:02 +0100
Subject: [coreboot] [PATCH] v3: Move default mainboard vendor/subsystem
 from Kconfig to dts
In-Reply-To: <13426df10803051700j590288b4s12c0796d033eae2e@mail.gmail.com>
References: <13426df10802281040n4afcdce1p1af052b71ce556f1@mail.gmail.com>	
	<47CEB36E.4010004@gmx.net>	
	<13426df10803050753h52f8030fjfeee5b678ff8b4e6@mail.gmail.com>	
	<47CEC43F.8010307@gmx.net>	
	<13426df10803050810u62fb6b68o3a3d7dc672bdfbe6@mail.gmail.com>	
	<47CECB60.9060401@gmx.net> <47CF28F1.3060605@gmx.net>	
	<13426df10803051527v56be68e2tabfb37141a026ab4@mail.gmail.com>	
	<47CF38D5.3040608@gmx.net>
	<13426df10803051700j590288b4s12c0796d033eae2e@mail.gmail.com>
Message-ID: <47D08726.7010009@gmx.net>

On 06.03.2008 02:00, ron minnich wrote:
> OK, the thought occurs:
>
> /number,number{
> }
>
> and number, number is the thing we want.
>
> Not sure. Just wondering. It fits the scheme.
>   

It fits the scheme at first glance, but the sub{vendor,device} stuff is 
pci specific and having it in a place where the identifier/address would 
normally be makes me uncomfortable.

Regards,
Carl-Daniel

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




From c-d.hailfinger.devel.2006 at gmx.net  Fri Mar  7 01:20:34 2008
From: c-d.hailfinger.devel.2006 at gmx.net (Carl-Daniel Hailfinger)
Date: Fri, 07 Mar 2008 01:20:34 +0100
Subject: [coreboot] r636 - in
 coreboot-v3:	include	mainboard/artecgroup/dbe61
 mainboard/artecgroup/dbe62	mainboard/pcengines/alix1c	northbridge/amd/geodelx
 southbridge/amd/cs5536
In-Reply-To: <20080307000203.GH15848@greenwood>
References: <E1JXPbL-0000e8-Nk@mi011.mc1.hosteurope.de>
	<20080307000203.GH15848@greenwood>
Message-ID: <47D08A52.5000306@gmx.net>

On 07.03.2008 01:02, Uwe Hermann wrote:
> On Fri, Mar 07, 2008 at 12:33:59AM +0100, svn at coreboot.org wrote:
>   
>> Modified: coreboot-v3/mainboard/artecgroup/dbe61/initram.c
>> ===================================================================
>> --- coreboot-v3/mainboard/artecgroup/dbe61/initram.c	2008-03-06 23:18:13 UTC (rev 635)
>> +++ coreboot-v3/mainboard/artecgroup/dbe61/initram.c	2008-03-06 23:33:59 UTC (rev 636)
>> @@ -97,13 +97,17 @@
>>  	/* returns 0xFF on any failures */
>>  	u8 ret = 0xff;
>>  
>> -	printk(BIOS_DEBUG, "spd_read_byte dev %04x\n", device);
>> +	printk(BIOS_DEBUG, "spd_read_byte dev %04x", device);
>>  	if (device == DIMM0) {
>>  		for (i = 0; i < ARRAY_SIZE(spd_table); i++) {
>>  			if (spd_table[i].address == address) {
>>  				ret = spd_table[i].data;
>>     
>
> No break here?
>   

That break is part of the fixup patch I sent in response. It will be 
committed in due course.


>>  			}
>>  		}
>> +
>> +		if (i == ARRAY_SIZE(spd_table))
>> +			printk(BIOS_DEBUG, " addr %02x does not exist in SPD table",
>> +				address);
>>  	}
>>  
>>  	printk(BIOS_DEBUG, " addr %02x returns %02x\n", address, ret);
>>
>>     
>
>
>   
>> Modified: coreboot-v3/northbridge/amd/geodelx/raminit.c
>> ===================================================================
>> --- coreboot-v3/northbridge/amd/geodelx/raminit.c	2008-03-06 23:18:13 UTC (rev 635)
>> +++ coreboot-v3/northbridge/amd/geodelx/raminit.c	2008-03-06 23:33:59 UTC (rev 636)
>> @@ -130,6 +130,7 @@
>>  	/* Module Density * Module Banks */
>>  	/* Shift to multiply by the number of DIMM banks. */
>>  	dimm_size <<= (dimm_setting >> CF07_UPPER_D0_MB_SHIFT) & 1;
>> +	printk(BIOS_DEBUG, "DIMM size is %x\n", dimm_size);
>>  	banner(BIOS_DEBUG, "BEFORT CTZ");
>>  	dimm_size = __builtin_ctz(dimm_size);
>>  	banner(BIOS_DEBUG, "TEST DIMM SIZE>8");
>> @@ -183,6 +184,7 @@
>>  	banner(BIOS_DEBUG, "RDMSR CF07");
>>  	msr = rdmsr(MC_CF07_DATA);
>>  	banner(BIOS_DEBUG, "WRMSR CF07");
>> +	printk(BIOS_DEBUG, "CF07(%x): %08x.%08x\n", MC_CF07_DATA, msr.hi, msr.lo);
>>  	if (dimm == dimm0) {
>>  		msr.hi &= 0xFFFF0000;
>>  		msr.hi |= dimm_setting;
>> @@ -223,6 +225,7 @@
>>  	/* Turn SPD ns time into MHz. Check what the asm does to this math. */
>>  	speed = 2 * ((10000 / (((spd_byte0 >> 4) * 10) + (spd_byte0 & 0x0F))));
>>  
>> +	printk(BIOS_DEBUG, "ddr max speed is %d\n", speed);
>>     
>
> ddr -> DDR
>   

Ah, cosmetics. I almost never review patches for comment/message style. 
For me, code style and readability is all that matters.


>>  	/* Current speed > max speed? */
>>  	if (geode_link_speed() > speed) {
>>  		printk(BIOS_EMERG, "DIMM overclocked. Check GeodeLink speed\n");
>> @@ -266,6 +269,7 @@
>>  	msr = rdmsr(MC_CF07_DATA);
>>  	msr.lo |= ((rate0 * (geode_link_speed() / 2)) / 16)
>>  		   << CF07_LOWER_REF_INT_SHIFT;
>> +	printk(BIOS_DEBUG, "Refresh rate set to %x\n", rate0);
>>  	wrmsr(MC_CF07_DATA, msr);
>>  }
>>  
>> @@ -385,6 +389,7 @@
>>  		hlt();
>>  	}
>>  
>> +	printk(BIOS_DEBUG, "Set cas latency to %x\n", spd_byte);
>>     
>
> cas -> CAS
>
>
>   
>> Modified: coreboot-v3/southbridge/amd/cs5536/cs5536.h
>> ===================================================================
>> --- coreboot-v3/southbridge/amd/cs5536/cs5536.h	2008-03-06 23:18:13 UTC (rev 635)
>> +++ coreboot-v3/southbridge/amd/cs5536/cs5536.h	2008-03-06 23:33:59 UTC (rev 636)
>> @@ -444,6 +444,7 @@
>>  /* Function prototypes */
>>  void cs5536_disable_internal_uart(void);
>>  void cs5536_setup_onchipuart(void);
>> +void cs5536_setup_onchipuart2(void);
>>     
>
> Is there some more descriptive suffix than "2" for this function?
>   

See my fixup patch.


>>  void cs5536_stage1(void);
>>  
>>  #endif /* SOUTHBRIDGE_AMD_CS5536_CS5536_H */
>>
>> @@ -239,6 +222,40 @@
>>  	wrmsr(MDD_UART1_CONF, msr);
>>  }
>>  
>> +void cs5536_setup_onchipuart2(void)
>>     
>
> Please add a (doxygen-)comment for this function, which should also
> mention what is different to cs5536_setup_onchipuart() and why we
> need two such functions.
>   

Ditto (though not completely addressed by my patch).

>> +{
>> +	struct msr msr;
>> +
>> +	/* GPIO4 - UART2_TX */
>> +	/* Set: Output Enable  (0x4) */
>> +	outl(GPIOL_4_SET, GPIO_IO_BASE + GPIOL_OUTPUT_ENABLE);
>> +	/* Set: OUTAUX1 Select (0x10) */
>> +	outl(GPIOL_4_SET, GPIO_IO_BASE + GPIOL_OUT_AUX1_SELECT);
>> +	/* GPIO4 - UART2_RX */
>> +	/* Set: Input Enable   (0x20) */
>> +	outl(GPIOL_3_SET, GPIO_IO_BASE + GPIOL_INPUT_ENABLE);
>> +	/* Set: INAUX1 Select  (0x34) */
>>     
>
> The (0x4), (0x10), (0x20), (0x34) etc. should be dropped, that's what the
> defines are used for. We don't _care_ about the actual numbers here.
>   

Feel free to send a patch. My personal opinion is that the comments make 
datasheet reading easier when they include the value of the symbolic 
constants, but I won't force that view on you.

Regards,
Carl-Daniel

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




From rminnich at gmail.com  Fri Mar  7 01:32:47 2008
From: rminnich at gmail.com (ron minnich)
Date: Thu, 6 Mar 2008 16:32:47 -0800
Subject: [coreboot] [PATCH] v3: Move default mainboard vendor/subsystem
	from Kconfig to dts
In-Reply-To: <47D08726.7010009@gmx.net>
References: <13426df10802281040n4afcdce1p1af052b71ce556f1@mail.gmail.com>
	<13426df10803050753h52f8030fjfeee5b678ff8b4e6@mail.gmail.com>
	<47CEC43F.8010307@gmx.net>
	<13426df10803050810u62fb6b68o3a3d7dc672bdfbe6@mail.gmail.com>
	<47CECB60.9060401@gmx.net> <47CF28F1.3060605@gmx.net>
	<13426df10803051527v56be68e2tabfb37141a026ab4@mail.gmail.com>
	<47CF38D5.3040608@gmx.net>
	<13426df10803051700j590288b4s12c0796d033eae2e@mail.gmail.com>
	<47D08726.7010009@gmx.net>
Message-ID: <13426df10803061632j4878fe2dlebe335f3822957ab@mail.gmail.com>

On Thu, Mar 6, 2008 at 4:07 PM, Carl-Daniel Hailfinger
<c-d.hailfinger.devel.2006 at gmx.net> wrote:
>
>  It fits the scheme at first glance, but the sub{vendor,device} stuff is
>  pci specific and having it in a place where the identifier/address would
>  normally be makes me uncomfortable.

I think I agree. I'll test your patch on its own, before I test the other one.

Thanks

ron



From c-d.hailfinger.devel.2006 at gmx.net  Fri Mar  7 01:53:11 2008
From: c-d.hailfinger.devel.2006 at gmx.net (Carl-Daniel Hailfinger)
Date: Fri, 07 Mar 2008 01:53:11 +0100
Subject: [coreboot] [PATCH] v3: Move default mainboard vendor/subsystem
 from Kconfig to dts
In-Reply-To: <13426df10803061632j4878fe2dlebe335f3822957ab@mail.gmail.com>
References: <13426df10802281040n4afcdce1p1af052b71ce556f1@mail.gmail.com>	
	<13426df10803050753h52f8030fjfeee5b678ff8b4e6@mail.gmail.com>	
	<47CEC43F.8010307@gmx.net>	
	<13426df10803050810u62fb6b68o3a3d7dc672bdfbe6@mail.gmail.com>	
	<47CECB60.9060401@gmx.net> <47CF28F1.3060605@gmx.net>	
	<13426df10803051527v56be68e2tabfb37141a026ab4@mail.gmail.com>	
	<47CF38D5.3040608@gmx.net>	
	<13426df10803051700j590288b4s12c0796d033eae2e@mail.gmail.com>	
	<47D08726.7010009@gmx.net>
	<13426df10803061632j4878fe2dlebe335f3822957ab@mail.gmail.com>
Message-ID: <47D091F7.9060109@gmx.net>

On 07.03.2008 01:32, ron minnich wrote:
> On Thu, Mar 6, 2008 at 4:07 PM, Carl-Daniel Hailfinger
> <c-d.hailfinger.devel.2006 at gmx.net> wrote:
>   
>>  It fits the scheme at first glance, but the sub{vendor,device} stuff is
>>  pci specific and having it in a place where the identifier/address would
>>  normally be makes me uncomfortable.
>>     
>
> I think I agree. I'll test your patch on its own, before I test the other one.
>   

If possible, I'd like to delay committing the patch a bit until I'm sure 
about the final design.
Testing would be great, though.

Regards,
Carl-Daniel

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




From svn at coreboot.org  Fri Mar  7 02:20:36 2008
From: svn at coreboot.org (svn at coreboot.org)
Date: Fri,  7 Mar 2008 02:20:36 +0100
Subject: [coreboot] r637 - in coreboot-v3: arch/x86 mainboard/amd/norwich
	mainboard/artecgroup/dbe61 mainboard/artecgroup/dbe62
	mainboard/pcengines/alix1c
Message-ID: <mailman.1256.1355071276.16123.coreboot@coreboot.org>

Author: hailfinger
Date: 2008-03-07 02:20:36 +0100 (Fri, 07 Mar 2008)
New Revision: 637

Modified:
   coreboot-v3/arch/x86/pirq_routing.c
   coreboot-v3/mainboard/amd/norwich/irq_tables.h
   coreboot-v3/mainboard/artecgroup/dbe61/irq_tables.h
   coreboot-v3/mainboard/artecgroup/dbe62/irq_tables.h
   coreboot-v3/mainboard/pcengines/alix1c/irq_tables.h
Log:
PIRQ table cosmetics/cleanup. Bugfixes and #error for uninitialized
memory accesses.

Signed-off-by: Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006 at gmx.net>
Acked-by: Uwe Hermann <uwe at hermann-uwe.de>


Modified: coreboot-v3/arch/x86/pirq_routing.c
===================================================================
--- coreboot-v3/arch/x86/pirq_routing.c	2008-03-06 23:33:59 UTC (rev 636)
+++ coreboot-v3/arch/x86/pirq_routing.c	2008-03-07 01:20:36 UTC (rev 637)
@@ -37,16 +37,6 @@
 
 	printk(BIOS_INFO, "Checking IRQ routing table consistency...\n");
 
-#if defined(IRQ_SLOT_COUNT)
-	if (sizeof(struct irq_routing_table) != rt->size) {
-		printk_warning("Inconsistent IRQ routing table size (0x%x/0x%x)\n",
-			       sizeof(struct irq_routing_table),
-			       rt->size
-			);
-		rt->size=sizeof(struct irq_routing_table);
-	}
-#endif
-
 	for (i = 0; i < rt->size; i++)
 		sum += addr[i];
 

Modified: coreboot-v3/mainboard/amd/norwich/irq_tables.h
===================================================================
--- coreboot-v3/mainboard/amd/norwich/irq_tables.h	2008-03-06 23:33:59 UTC (rev 636)
+++ coreboot-v3/mainboard/amd/norwich/irq_tables.h	2008-03-07 01:20:36 UTC (rev 637)
@@ -17,20 +17,10 @@
 * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA  02110-1301 USA
 */
 
-#include <types.h>
-#include <lib.h>
-#include <console.h>
-#include <device/device.h>
-#include <device/pci.h>
-#include <string.h>
-#include <msr.h>
-#include <io.h>
 #include <pirq_routing.h>
-#include <amd_geodelx.h>
-#include "../../../southbridge/amd/cs5536/cs5536.h"
 
 /* Number of slots and devices in the PIR table */
-#define SLOT_COUNT 6
+#define IRQ_SLOT_COUNT 6
 
 /* Platform IRQs */
 #define PIRQA 11
@@ -73,7 +63,7 @@
 const struct irq_routing_table intel_irq_routing_table = {
 	PIRQ_SIGNATURE,
 	PIRQ_VERSION,
-	32 + 16 * SLOT_COUNT,	/* Max. number of devices on the bus */
+	32 + 16 * IRQ_SLOT_COUNT,	/* Max. number of devices on the bus */
 	0x00,			/* Where the interrupt router lies (bus) */
 	(0x0F << 3) | 0x0,      /* Where the interrupt router lies (dev) */
 	0x00,			/* IRQs devoted exclusively to PCI usage */
@@ -83,13 +73,19 @@
 	{0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0},	/* u8 rfu[11] */
 	0x00,			/* Checksum */
 	{
-	 /* If you change the number of entries, change the IRQ_SLOT_COUNT above! */
-	 /* bus, dev|fn,           {link, bitmap},      {link, bitmap},     {link, bitmap},     {link, bitmap},     slot, rfu */
-	 {0x00, (0x01 << 3) | 0x0, {{L_PIRQA, M_PIRQA}, {0x00, 0x00}, {0x00, 0x00}, {0x00, 0x00}}, 0x0, 0x0},	/* cpu */
-	 {0x00, (0x0F << 3) | 0x0, {{L_PIRQA, M_PIRQA}, {L_PIRQB, M_PIRQB}, {L_PIRQC, M_PIRQC}, {L_PIRQD, M_PIRQD}}, 0x0, 0x0},	/* chipset */
-	 {0x00, (0x0D << 3) | 0x0, {{L_PIRQB, M_PIRQB}, {L_PIRQC, M_PIRQC}, {L_PIRQD, M_PIRQD}, {L_PIRQA, M_PIRQA}}, 0x1, 0x0},	/* slot1 */
-	 {0x00, (0x0E << 3) | 0x0, {{L_PIRQC, M_PIRQC}, {L_PIRQD, M_PIRQD}, {L_PIRQA, M_PIRQA}, {L_PIRQB, M_PIRQB}}, 0x2, 0x0},	/* slot2 */
-	 {0x00, (0x0B << 3) | 0x0, {{L_PIRQD, M_PIRQD}, {L_PIRQA, M_PIRQA}, {L_PIRQB, M_PIRQB}, {L_PIRQC, M_PIRQC}}, 0x3, 0x0},	/* slot3 */
-	 {0x00, (0x0C << 3) | 0x0, {{L_PIRQA, M_PIRQA}, {L_PIRQB, M_PIRQB}, {L_PIRQC, M_PIRQC}, {L_PIRQD, M_PIRQD}}, 0x4, 0x0},	/* slot4 */
+		/* If you change the number of entries, change IRQ_SLOT_COUNT above! */
+		/* bus, dev|fn,           {link, bitmap},      {link, bitmap},     {link, bitmap},     {link, bitmap},     slot, rfu */
+		/* CPU */
+		{0x00, (0x01 << 3) | 0x0, {{L_PIRQA, M_PIRQA}, {0x00, 0x00}, {0x00, 0x00}, {0x00, 0x00}}, 0x0, 0x0},
+		/* chipset */
+		{0x00, (0x0F << 3) | 0x0, {{L_PIRQA, M_PIRQA}, {L_PIRQB, M_PIRQB}, {L_PIRQC, M_PIRQC}, {L_PIRQD, M_PIRQD}}, 0x0, 0x0},
+		/* slot1 */
+		{0x00, (0x0D << 3) | 0x0, {{L_PIRQB, M_PIRQB}, {L_PIRQC, M_PIRQC}, {L_PIRQD, M_PIRQD}, {L_PIRQA, M_PIRQA}}, 0x1, 0x0},
+		/* slot2 */
+		{0x00, (0x0E << 3) | 0x0, {{L_PIRQC, M_PIRQC}, {L_PIRQD, M_PIRQD}, {L_PIRQA, M_PIRQA}, {L_PIRQB, M_PIRQB}}, 0x2, 0x0},
+		/* slot3 */
+		{0x00, (0x0B << 3) | 0x0, {{L_PIRQD, M_PIRQD}, {L_PIRQA, M_PIRQA}, {L_PIRQB, M_PIRQB}, {L_PIRQC, M_PIRQC}}, 0x3, 0x0},
+		/* slot4 */
+		{0x00, (0x0C << 3) | 0x0, {{L_PIRQA, M_PIRQA}, {L_PIRQB, M_PIRQB}, {L_PIRQC, M_PIRQC}, {L_PIRQD, M_PIRQD}}, 0x4, 0x0},
 	 }
 };

Modified: coreboot-v3/mainboard/artecgroup/dbe61/irq_tables.h
===================================================================
--- coreboot-v3/mainboard/artecgroup/dbe61/irq_tables.h	2008-03-06 23:33:59 UTC (rev 636)
+++ coreboot-v3/mainboard/artecgroup/dbe61/irq_tables.h	2008-03-07 01:20:36 UTC (rev 637)
@@ -5,7 +5,7 @@
  * Documentation at : http://www.microsoft.com/hwdev/busbios/PCIIRQ.HTM
 */
 
-#include <arch/pirq_routing.h>
+#include <pirq_routing.h>
 
 #define ID_SLOT_PCI_NET		1			// ThinCan ethernet
 #define ID_SLOT_PCI_RSVD1	2           // reserved entry 1

Modified: coreboot-v3/mainboard/artecgroup/dbe62/irq_tables.h
===================================================================
--- coreboot-v3/mainboard/artecgroup/dbe62/irq_tables.h	2008-03-06 23:33:59 UTC (rev 636)
+++ coreboot-v3/mainboard/artecgroup/dbe62/irq_tables.h	2008-03-07 01:20:36 UTC (rev 637)
@@ -17,20 +17,12 @@
 * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA  02110-1301 USA
 */
 
-#include <types.h>
-#include <lib.h>
-#include <console.h>
-#include <device/device.h>
-#include <device/pci.h>
-#include <string.h>
-#include <msr.h>
-#include <io.h>
 #include <pirq_routing.h>
-#include <amd_geodelx.h>
-#include "../../../southbridge/amd/cs5536/cs5536.h"
 
+/* Number of slots and devices in the PIR table */
+#error IRQ_SLOT_COUNT does not match PIR table contents, IRQ routing setup will access uninitialied memory
+#define IRQ_SLOT_COUNT 5
 
-
 /* Platform IRQs */
 #define PIRQA 10
 #define PIRQB 11
@@ -52,7 +44,7 @@
 const struct irq_routing_table intel_irq_routing_table = {
 	PIRQ_SIGNATURE,
 	PIRQ_VERSION,
-	32 + 16 * 5,		/* Max. number of devices on the bus */
+	32 + 16 * IRQ_SLOT_COUNT,	/* Max. number of devices on the bus */
 	0x00,			/* Where the interrupt router lies (bus) */
 	(0x0F << 3) | 0x0,      /* Where the interrupt router lies (dev) */
 	0x00,			/* IRQs devoted exclusively to PCI usage */
@@ -62,9 +54,13 @@
 	{0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0},	/* u8 rfu[11] */
 	0x00,			/* Checksum */
 	{
-	 /* bus, dev|fn,           {link, bitmap},      {link, bitmap},     {link, bitmap},     {link, bitmap},     slot, rfu */
-	 {0x00, (0x01 << 3) | 0x0, {{L_PIRQA, M_PIRQA}, {0x00, 0x00}, {0x00, 0x00}, {0x00, 0x00}}, 0x0, 0x0},	/* cpu */
-	 {0x00, (0x0F << 3) | 0x0, {{L_PIRQA, M_PIRQA}, {L_PIRQB, M_PIRQB}, {L_PIRQC, M_PIRQC}, {L_PIRQD, M_PIRQD}}, 0x0, 0x0},	/* chipset */
-	 {0x00, (0x0D << 3) | 0x0, {{L_PIRQC, M_PIRQC}, {0x00, 0x00}, {0x00, 0x00}, {0x00, 0x00}}, 0x0, 0x0},	/* ethernet */
+		/* If you change the number of entries, change IRQ_SLOT_COUNT above! */
+		/* bus, dev|fn,           {link, bitmap},      {link, bitmap},     {link, bitmap},     {link, bitmap},     slot, rfu */
+		/* CPU */
+		{0x00, (0x01 << 3) | 0x0, {{L_PIRQA, M_PIRQA}, {0x00, 0x00}, {0x00, 0x00}, {0x00, 0x00}}, 0x0, 0x0},
+		/* chipset */
+		{0x00, (0x0F << 3) | 0x0, {{L_PIRQA, M_PIRQA}, {L_PIRQB, M_PIRQB}, {L_PIRQC, M_PIRQC}, {L_PIRQD, M_PIRQD}}, 0x0, 0x0},
+		/* ethernet */
+		{0x00, (0x0D << 3) | 0x0, {{L_PIRQC, M_PIRQC}, {0x00, 0x00}, {0x00, 0x00}, {0x00, 0x00}}, 0x0, 0x0},
 	}
 };

Modified: coreboot-v3/mainboard/pcengines/alix1c/irq_tables.h
===================================================================
--- coreboot-v3/mainboard/pcengines/alix1c/irq_tables.h	2008-03-06 23:33:59 UTC (rev 636)
+++ coreboot-v3/mainboard/pcengines/alix1c/irq_tables.h	2008-03-07 01:20:36 UTC (rev 637)
@@ -19,6 +19,8 @@
 
 #include <pirq_routing.h>
 
+/* Number of slots and devices in the PIR table */
+#define IRQ_SLOT_COUNT 5
 
 /* Platform IRQs */
 #define PIRQA 11
@@ -71,7 +73,7 @@
 const struct irq_routing_table intel_irq_routing_table = {
 	PIRQ_SIGNATURE,
 	PIRQ_VERSION,
-	32 + 16 * 5,		/* Max. number of devices on the bus */
+	32 + 16 * IRQ_SLOT_COUNT,	/* Max. number of devices on the bus */
 	0x00,			/* Where the interrupt router lies (bus) */
 	(0x0F << 3) | 0x0,      /* Where the interrupt router lies (dev) */
 	0x00,			/* IRQs devoted exclusively to PCI usage */




From c-d.hailfinger.devel.2006 at gmx.net  Fri Mar  7 02:20:57 2008
From: c-d.hailfinger.devel.2006 at gmx.net (Carl-Daniel Hailfinger)
Date: Fri, 07 Mar 2008 02:20:57 +0100
Subject: [coreboot] [PATCH] v3: PIRQ table cosmetics
In-Reply-To: <20080306233148.GE15848@greenwood>
References: <47CDFACE.4040006@gmx.net> <20080306233148.GE15848@greenwood>
Message-ID: <47D09879.5010704@gmx.net>

On 07.03.2008 00:31, Uwe Hermann wrote:
> On Wed, Mar 05, 2008 at 02:43:42AM +0100, Carl-Daniel Hailfinger wrote:
>   
>> PIRQ table cosmetics/cleanup.
>>
>> Signed-off-by: Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006 at gmx.net>
>>     
>
> Acked-by: Uwe Hermann <uwe at hermann-uwe.de>
>   

Thanks.


> (but see below)
>
>   
>> Index: LinuxBIOSv3-db800/mainboard/amd/norwich/irq_tables.h
>> ===================================================================
>> --- LinuxBIOSv3-db800/mainboard/amd/norwich/irq_tables.h	(Revision 630)
>> +++ LinuxBIOSv3-db800/mainboard/amd/norwich/irq_tables.h	(Arbeitskopie)
>> @@ -17,17 +17,7 @@
>>  * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA  02110-1301 USA
>>  */
>>  
>> -#include <types.h>
>> -#include <lib.h>
>> -#include <console.h>
>> -#include <device/device.h>
>> -#include <device/pci.h>
>> -#include <string.h>
>> -#include <msr.h>
>> -#include <io.h>
>>  #include <pirq_routing.h>
>> -#include <amd_geodelx.h>
>> -#include "../../../southbridge/amd/cs5536/cs5536.h"
>>     
>
> I assume it's compile-tested that these are not needed?
>   

This bit was forgotten in an earlier commit of similar files in other 
mainboard directories.


>>  /* Number of slots and devices in the PIR table */
>>  #define SLOT_COUNT 6
>> @@ -83,13 +73,19 @@
>>  	{0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0},	/* u8 rfu[11] */
>>  	0x00,			/* Checksum */
>>  	{
>> -	 /* If you change the number of entries, change the IRQ_SLOT_COUNT above! */
>> -	 /* bus, dev|fn,           {link, bitmap},      {link, bitmap},     {link, bitmap},     {link, bitmap},     slot, rfu */
>> -	 {0x00, (0x01 << 3) | 0x0, {{L_PIRQA, M_PIRQA}, {0x00, 0x00}, {0x00, 0x00}, {0x00, 0x00}}, 0x0, 0x0},	/* cpu */
>> -	 {0x00, (0x0F << 3) | 0x0, {{L_PIRQA, M_PIRQA}, {L_PIRQB, M_PIRQB}, {L_PIRQC, M_PIRQC}, {L_PIRQD, M_PIRQD}}, 0x0, 0x0},	/* chipset */
>> -	 {0x00, (0x0D << 3) | 0x0, {{L_PIRQB, M_PIRQB}, {L_PIRQC, M_PIRQC}, {L_PIRQD, M_PIRQD}, {L_PIRQA, M_PIRQA}}, 0x1, 0x0},	/* slot1 */
>> -	 {0x00, (0x0E << 3) | 0x0, {{L_PIRQC, M_PIRQC}, {L_PIRQD, M_PIRQD}, {L_PIRQA, M_PIRQA}, {L_PIRQB, M_PIRQB}}, 0x2, 0x0},	/* slot2 */
>> -	 {0x00, (0x0B << 3) | 0x0, {{L_PIRQD, M_PIRQD}, {L_PIRQA, M_PIRQA}, {L_PIRQB, M_PIRQB}, {L_PIRQC, M_PIRQC}}, 0x3, 0x0},	/* slot3 */
>> -	 {0x00, (0x0C << 3) | 0x0, {{L_PIRQA, M_PIRQA}, {L_PIRQB, M_PIRQB}, {L_PIRQC, M_PIRQC}, {L_PIRQD, M_PIRQD}}, 0x4, 0x0},	/* slot4 */
>>     
>
>   
>> +		/* If you change the number of entries, change IRQ_SLOT_COUNT above! */
>>     
>
> IRQ_SLOT_COUNT -> SLOT_COUNT
>   

Thanks. I've fixed this in reverse because it's about IRQ slots and not 
any other type of slots.

Committed with fixes outlined above plus minor deathtrap avoidance.

Regards,
Carl-Daniel

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




From rminnich at gmail.com  Fri Mar  7 02:22:20 2008
From: rminnich at gmail.com (ron minnich)
Date: Thu, 6 Mar 2008 17:22:20 -0800
Subject: [coreboot] [PATCH] Merge lib/ramtest.c into lib/ram.c
In-Reply-To: <20080306232555.GD15848@greenwood>
References: <20080306232555.GD15848@greenwood>
Message-ID: <13426df10803061722m2ac3242bl55b0bf0150ba1639@mail.gmail.com>

one reason I kept it seperate is that maybe it should depend on a
Kconfig variable? Just wondering.

ron



From c-d.hailfinger.devel.2006 at gmx.net  Fri Mar  7 02:34:37 2008
From: c-d.hailfinger.devel.2006 at gmx.net (Carl-Daniel Hailfinger)
Date: Fri, 07 Mar 2008 02:34:37 +0100
Subject: [coreboot] lar copy patch
In-Reply-To: <2831fecf0803061547j1888dffem928bd6a4d2c85dda@mail.gmail.com>
References: <2831fecf0803061547j1888dffem928bd6a4d2c85dda@mail.gmail.com>
Message-ID: <47D09BAD.7090305@gmx.net>

On 07.03.2008 00:47, Myles Watson wrote:
> This patch adds copy functionality to lar via
>
> lar -L srclar.file
>   

Although I appreciate the work you've done, I still feel the lar copy 
approach is not right.

> It allows you to use payloads, bootblocks, or other entries from one
> lar when creating or adding to another.
>
> changes by file:
> util/lar/lar.c:
> 	change usage
> 	add srcarchivename parameter for create_lar and add_lar
> 	add lar_copy functionality to create_lar and add_lar
> 	add -C keep for using the same compression as srclar
> util/lar/lar.h:
> 	change invalid to invalid_or_keep in algo_strings
>
> util/lar/lib.c:
> 	pull out function add_entry from add_files
> 	
> util/lar/lib.h:
> 	add prototypes for add_entry and lar_copy
> 	change prototype for create_lar (wonder why add_lar doesn't have one)
> 	fix whitespace
>
> util/lar/stream.c:
> 	pull out helper function file_in_list_where from file_in_list
> 	add lar_copy
> 	
> This is a test of the copy functionality of lar.  I'll use C++-style comments
>      // here's the original lar file
> [myles at orangutan svn]$ build/util/lar/lar -l build/coreboot.rom
>   normal/option_table (932 bytes @0x50);loadaddress 0x0 entry 0x0
>   normal/initram/segment0 (432 bytes @0x450);loadaddress 0x0 entry 0x0x42
>   normal/stage2/segment0 (191792 bytes, zeroes compressed to 1 bytes
> @0x650);loadaddress 0x0xa540 entry 0x0x2000
>   normal/stage2/segment1 (28172 bytes, lzma compressed to 15083 bytes
> @0x6b0);loadaddress 0x0x2000 entry 0x0x2000
>   normal/stage2/segment2 (5420 bytes, lzma compressed to 312 bytes
> @0x41f0);loadaddress 0x0x9000 entry 0x0x2000
>   bootblock (20480 bytes @0xfb000)
> Total size = 37688B 36KB (0x9338)
>
>      //create a new 256K lar file called bootblock.rom which has the
> same bootblock as coreboot.rom
> [myles at orangutan svn]$ build/util/lar/lar -c -s 256K bootblock.rom -L
> build/coreboot.rom
>
>      //create a new lar file with uncompressed normal/stage2
> [myles at orangutan svn]$ build/util/lar/lar -c -s 256K normal_stage2.rom
> -L build/coreboot.rom nocompress:normal/stage2:stage2
>   

Wait. You add a file with path "stage2" as "normal/stage2"? That's wrong.

>      //create a new lar file with lzma compressed normal/init
> [myles at orangutan svn]$ build/util/lar/lar -c -s 256K normal_init.rom
> -L build/coreboot.rom -C lzma normal/init
>   

What is normal/init? That thing does not exist as path.

>      //create a new lar file with normal/opt compressed the same as it was
> [myles at orangutan svn]$ build/util/lar/lar -c -s 256K normal_opt.rom -L
> build/coreboot.rom -C keep  normal/opt
>
>      //create a new 1M lar using the bootblock in bootblock.rom
> [myles at orangutan svn]$ build/util/lar/lar -c -s 1M new.rom -L bootblock.rom
>   

How does LAR know that you want to copy the bootblock instead of an 
empty operation?

>      //add back in the components with the correct compression
> [myles at orangutan svn]$ build/util/lar/lar -a new.rom -L normal_opt.rom
> -C none normal/
> [myles at orangutan svn]$ build/util/lar/lar -a new.rom -L
> normal_init.rom -C none normal/init
>
>      //use the verbose switch to see what you're getting
> [myles at orangutan svn]$ build/util/lar/lar -av new.rom -L
> normal_stage2.rom -C lzma stage2:normal/stage2
>   

Here the stange stage2 mentioning happens again.

> ... adding stage2:normal/stage2
> stage2:normal/stage2 (lzma) matches stage2/segment0 => normal/stage2/segment0.
> stage2:normal/stage2 (lzma) matches stage2/segment1 => normal/stage2/segment1.
> stage2:normal/stage2 (lzma) matches stage2/segment2 => normal/stage2/segment2.
>
>      //diff the two files
> [myles at orangutan svn]$ diff new.rom build/coreboot.rom
>  // There's no difference
>
> I think it would be nice if lar would warn you (or stop you) when you
> try to add a duplicate entry.  Maybe that will be the next patch.
>
> Myles
>
> Signed-off-by: Myles Watson <mylesgw at gmail.com>
>   

Regards,
Carl-Daniel

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




From c-d.hailfinger.devel.2006 at gmx.net  Fri Mar  7 02:37:07 2008
From: c-d.hailfinger.devel.2006 at gmx.net (Carl-Daniel Hailfinger)
Date: Fri, 07 Mar 2008 02:37:07 +0100
Subject: [coreboot] [PATCH] Merge lib/ramtest.c into lib/ram.c
In-Reply-To: <13426df10803061722m2ac3242bl55b0bf0150ba1639@mail.gmail.com>
References: <20080306232555.GD15848@greenwood>
	<13426df10803061722m2ac3242bl55b0bf0150ba1639@mail.gmail.com>
Message-ID: <47D09C43.3030002@gmx.net>

On 07.03.2008 02:22, ron minnich wrote:
> one reason I kept it seperate is that maybe it should depend on a
> Kconfig variable? Just wondering.
>   

Yes, it really should depend on Kconfig. However, we will have to 
provide an empty ramtest function to make this mostly transparent or 
work with ifdefs in the mainboard code.

Regards,
Carl-Daniel

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




From rminnich at gmail.com  Fri Mar  7 06:10:50 2008
From: rminnich at gmail.com (ron minnich)
Date: Thu, 6 Mar 2008 21:10:50 -0800
Subject: [coreboot] qemu error message: "Unrecognized partitioning
	scheme"
In-Reply-To: <040501c87fde$b3642090$1a2c61b0$@com>
References: <031701c87e48$7e531ba0$7af952e0$@com>
	<13426df10803041502v37b079a7ob131b1e68f797ee8@mail.gmail.com>
	<035901c87f02$89a62b90$9cf282b0$@com>
	<2831fecf0803051459g8a361ddk2ee7f6f6a07c595a@mail.gmail.com>
	<03bc01c87fb1$fb73fa40$f25beec0$@com>
	<13426df10803061400n7f00ee2bte7728f9e475643b9@mail.gmail.com>
	<040501c87fde$b3642090$1a2c61b0$@com>
Message-ID: <13426df10803062110s37962c46he6573a90e51a50ad@mail.gmail.com>

On Thu, Mar 6, 2008 at 3:06 PM, David Edrich <dsedrich at violin-memory.com> wrote:
> It's like 2 Gigabytes. Even if I Tar it, it will be 100's of megs so it doesn't seem practical to send
>
>  From my understanding FILO gets to the "menu" file, in the disk image, without any problems. Then, to access files after that, FILO
>  want to read some partition information from, I would guess, the MBR -- and there is no MBR from the process we used to generate the
>  disk image file. I think that is the problem. I don't know much about qemu-img options that may get around this or if some FILO
>  options do this. I would guess that that would be where to try and find a way out of this.
>

what's your menu file look like? This stuff should all work without
partitions or MBR. We solved the first problem -- by saying hda
instead of hda3 -- I guess the
second problem is solved in the menu file. Can you show us that file?

ron



From svn at coreboot.org  Fri Mar  7 07:33:06 2008
From: svn at coreboot.org (svn at coreboot.org)
Date: Fri,  7 Mar 2008 07:33:06 +0100
Subject: [coreboot] r638 - in coreboot-v3: mainboard/amd/norwich
	mainboard/artecgroup/dbe61 mainboard/artecgroup/dbe62
	southbridge/amd/cs5536
Message-ID: <mailman.1257.1355071276.16123.coreboot@coreboot.org>

Author: rminnich
Date: 2008-03-07 07:33:05 +0100 (Fri, 07 Mar 2008)
New Revision: 638

Modified:
   coreboot-v3/mainboard/amd/norwich/stage1.c
   coreboot-v3/mainboard/artecgroup/dbe61/initram.c
   coreboot-v3/mainboard/artecgroup/dbe61/stage1.c
   coreboot-v3/mainboard/artecgroup/dbe62/irq_tables.h
   coreboot-v3/mainboard/artecgroup/dbe62/stage1.c
   coreboot-v3/southbridge/amd/cs5536/cs5536.h
   coreboot-v3/southbridge/amd/cs5536/stage1.c
Log:
Make cs5536_setup_onchipuart() handle both UARTs and add missing break in dbe61 initram.

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

Tested on dbe62. I had to run cs5536/stage1.c through indent -kr -i8 because emacs is somehow 
confused by parts of it. Weird. indent made some parts ugly, at least to my eyes. Oh well. 
Acked-by: Ronald G. Minnich <rminnich at gmail.com>




Modified: coreboot-v3/mainboard/amd/norwich/stage1.c
===================================================================
--- coreboot-v3/mainboard/amd/norwich/stage1.c	2008-03-07 01:20:36 UTC (rev 637)
+++ coreboot-v3/mainboard/amd/norwich/stage1.c	2008-03-07 06:33:05 UTC (rev 638)
@@ -42,7 +42,7 @@
 	 * early MSR setup for the CS5536. We do this early for debug. 
 	 * Real setup should be done in chipset init via dts settings.
 	 */
-	cs5536_setup_onchipuart();
+	cs5536_setup_onchipuart(1);
 }
 
 void mainboard_pre_payload(void)

Modified: coreboot-v3/mainboard/artecgroup/dbe61/initram.c
===================================================================
--- coreboot-v3/mainboard/artecgroup/dbe61/initram.c	2008-03-07 01:20:36 UTC (rev 637)
+++ coreboot-v3/mainboard/artecgroup/dbe61/initram.c	2008-03-07 06:33:05 UTC (rev 638)
@@ -102,6 +102,7 @@
 		for (i = 0; i < ARRAY_SIZE(spd_table); i++) {
 			if (spd_table[i].address == address) {
 				ret = spd_table[i].data;
+                                break;
 			}
 		}
 

Modified: coreboot-v3/mainboard/artecgroup/dbe61/stage1.c
===================================================================
--- coreboot-v3/mainboard/artecgroup/dbe61/stage1.c	2008-03-07 01:20:36 UTC (rev 637)
+++ coreboot-v3/mainboard/artecgroup/dbe61/stage1.c	2008-03-07 06:33:05 UTC (rev 638)
@@ -59,7 +59,7 @@
 	 * NOTE: Must do this AFTER the early_setup! It is counting on some
 	 * early MSR setup for the CS5536.
 	 */
-	cs5536_setup_onchipuart();
+	cs5536_setup_onchipuart(2);
 }
 
 void mainboard_pre_payload(void)

Modified: coreboot-v3/mainboard/artecgroup/dbe62/irq_tables.h
===================================================================
--- coreboot-v3/mainboard/artecgroup/dbe62/irq_tables.h	2008-03-07 01:20:36 UTC (rev 637)
+++ coreboot-v3/mainboard/artecgroup/dbe62/irq_tables.h	2008-03-07 06:33:05 UTC (rev 638)
@@ -20,8 +20,7 @@
 #include <pirq_routing.h>
 
 /* Number of slots and devices in the PIR table */
-#error IRQ_SLOT_COUNT does not match PIR table contents, IRQ routing setup will access uninitialied memory
-#define IRQ_SLOT_COUNT 5
+#define IRQ_SLOT_COUNT 3
 
 /* Platform IRQs */
 #define PIRQA 10

Modified: coreboot-v3/mainboard/artecgroup/dbe62/stage1.c
===================================================================
--- coreboot-v3/mainboard/artecgroup/dbe62/stage1.c	2008-03-07 01:20:36 UTC (rev 637)
+++ coreboot-v3/mainboard/artecgroup/dbe62/stage1.c	2008-03-07 06:33:05 UTC (rev 638)
@@ -58,7 +58,7 @@
 	 * NOTE: Must do this AFTER the early_setup! It is counting on some
 	 * early MSR setup for the CS5536.
 	 */
-	cs5536_setup_onchipuart2();
+	cs5536_setup_onchipuart(2);
 }
 
 void mainboard_pre_payload(void)

Modified: coreboot-v3/southbridge/amd/cs5536/cs5536.h
===================================================================
--- coreboot-v3/southbridge/amd/cs5536/cs5536.h	2008-03-07 01:20:36 UTC (rev 637)
+++ coreboot-v3/southbridge/amd/cs5536/cs5536.h	2008-03-07 06:33:05 UTC (rev 638)
@@ -443,8 +443,7 @@
 
 /* Function prototypes */
 void cs5536_disable_internal_uart(void);
-void cs5536_setup_onchipuart(void);
-void cs5536_setup_onchipuart2(void);
+void cs5536_setup_onchipuart(int uart);
 void cs5536_stage1(void);
 
 #endif /* SOUTHBRIDGE_AMD_CS5536_CS5536_H */

Modified: coreboot-v3/southbridge/amd/cs5536/stage1.c
===================================================================
--- coreboot-v3/southbridge/amd/cs5536/stage1.c	2008-03-07 01:20:36 UTC (rev 637)
+++ coreboot-v3/southbridge/amd/cs5536/stage1.c	2008-03-07 06:33:05 UTC (rev 638)
@@ -49,10 +49,10 @@
 	/* TODO: unsigned char -> u8? */
 #if CS5536_GLINK_PORT_NUM <= 4
 	msr.lo = CS5536_DEV_NUM <<
-	    (unsigned char)((CS5536_GLINK_PORT_NUM - 1) * 8);
+	    (unsigned char) ((CS5536_GLINK_PORT_NUM - 1) * 8);
 #else
 	msr.hi = CS5536_DEV_NUM <<
-	    (unsigned char)((CS5536_GLINK_PORT_NUM - 5) * 8);
+	    (unsigned char) ((CS5536_GLINK_PORT_NUM - 5) * 8);
 #endif
 
 	wrmsr(GLPCI_ExtMSR, msr);
@@ -90,11 +90,11 @@
 }
 
 static const struct msrinit msr_table[] = {
-	{MDD_LBAR_SMB,   {.hi = 0x0000f001, .lo = SMBUS_IO_BASE}},
-	{MDD_LBAR_GPIO,  {.hi = 0x0000f001, .lo = GPIO_IO_BASE}},
-	{MDD_LBAR_MFGPT, {.hi = 0x0000f001, .lo = MFGPT_IO_BASE}},
-	{MDD_LBAR_ACPI,  {.hi = 0x0000f001, .lo = ACPI_IO_BASE}},
-	{MDD_LBAR_PMS,   {.hi = 0x0000f001, .lo = PMS_IO_BASE}},
+	{MDD_LBAR_SMB, {.hi = 0x0000f001,.lo = SMBUS_IO_BASE}},
+	{MDD_LBAR_GPIO, {.hi = 0x0000f001,.lo = GPIO_IO_BASE}},
+	{MDD_LBAR_MFGPT, {.hi = 0x0000f001,.lo = MFGPT_IO_BASE}},
+	{MDD_LBAR_ACPI, {.hi = 0x0000f001,.lo = ACPI_IO_BASE}},
+	{MDD_LBAR_PMS, {.hi = 0x0000f001,.lo = PMS_IO_BASE}},
 };
 
 /**
@@ -147,15 +147,15 @@
 	 * Disable and reset them and configure them later (SIO init).
 	 */
 	msr = rdmsr(MDD_UART1_CONF);
-	msr.lo = 1;			/* Reset */
+	msr.lo = 1;		/* Reset */
 	wrmsr(MDD_UART1_CONF, msr);
-	msr.lo = 0;			/* Disable */
+	msr.lo = 0;		/* Disable */
 	wrmsr(MDD_UART1_CONF, msr);
 
 	msr = rdmsr(MDD_UART2_CONF);
-	msr.lo = 1;			/* Reset */
+	msr.lo = 1;		/* Reset */
 	wrmsr(MDD_UART2_CONF, msr);
-	msr.lo = 0;			/* Disable */
+	msr.lo = 0;		/* Disable */
 	wrmsr(MDD_UART2_CONF, msr);
 }
 
@@ -182,7 +182,7 @@
  *
  * See page 412 of the AMD Geode CS5536 Companion Device data book.
  */
-void cs5536_setup_onchipuart(void)
+void cs5536_setup_onchipuart1(void)
 {
 	struct msr msr;
 
@@ -238,7 +238,8 @@
 	outl(GPIOL_3_SET, GPIO_IO_BASE + GPIOL_IN_AUX1_SELECT);
 
 	/* Set: GPIO 3 + 3 Pull Up  (0x18) */
-	outl(GPIOL_3_SET | GPIOL_4_SET, GPIO_IO_BASE + GPIOL_PULLUP_ENABLE);
+	outl(GPIOL_3_SET | GPIOL_4_SET,
+	     GPIO_IO_BASE + GPIOL_PULLUP_ENABLE);
 
 	/* set address to 3F8 */
 	msr = rdmsr(MDD_LEG_IO);
@@ -255,7 +256,19 @@
 	wrmsr(MDD_UART2_CONF, msr);
 }
 
+void cs5536_setup_onchipuart(int uart)
+{
+	switch (uart) {
+	case 1:
+		cs5536_setup_onchipuart1();
+		break;
+	case 2:
+		cs5536_setup_onchipuart2();
+		break;
+	}
+}
 
+
 /**
  * Board setup.
  *




From rminnich at gmail.com  Fri Mar  7 07:33:47 2008
From: rminnich at gmail.com (ron minnich)
Date: Thu, 6 Mar 2008 22:33:47 -0800
Subject: [coreboot] patch: cumulative LX changes
In-Reply-To: <47D0786B.8060208@gmx.net>
References: <13426df10803061242s6d7d0ae9x239f3fba59b9c0af@mail.gmail.com>
	<47D0786B.8060208@gmx.net>
Message-ID: <13426df10803062233ycd0adeclb1269ebbcc0ab621@mail.gmail.com>

On Thu, Mar 6, 2008 at 3:04 PM, Carl-Daniel Hailfinger
<c-d.hailfinger.devel.2006 at gmx.net> wrote:
> On 06.03.2008 21:42, ron minnich wrote:
>  > This is all from work last night. I'd lke to get these in.
>  >
>  > This is a cumulative set of fixes for LX800 boards. These are all tested on ALIX 1C and DBE62.
>  >
>  > This includes:
>  > - the working power button patch.
>  > - onchipuart2 for very early startup -- this will be replaced with a better mechanism soon.
>  > - dts mod for powerbutton on cs5536
>  > - dbe62 dts fix for COM1 setup
>  > - ram check call in dbe62 initram.c
>  > - Carl-Daniel's fix to detect incorrect access to spd variables.
>  > - more debug prints in geodelx northbridge support code.
>  >
>  > This is cumulative since we're lagging on acks a bit and it's hard to keep this
>  > stuff all seperated out since it involves a common set of files. I'd like to get
>  > it acked and in tree today if possible. It's a very small set of lines changed so please
>  > forgive me for the cumulative nature.
>  >
>  > Thanks
>  >
>  > Signed-off-by: Ronald G. Minnich <rminnich at gmail.com>
>  >
>
>  Acked-by: Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006 at gmx.net>
>
>  It would be cool if you could add the attached changes on top before
>  committing, though. They make cs5536_setup_onchipuart() handle both
>  UARTs and add missing break in dbe61 initram.

Tested on dbe62.
Committed revision 638.
ron



From jtd at mtnl.net.in  Fri Mar  7 10:15:28 2008
From: jtd at mtnl.net.in (jtd)
Date: Fri, 7 Mar 2008 14:45:28 +0530
Subject: [coreboot] Via epia
Message-ID: <200803071445.28448.jtd@sparc.net>

Hi all,

I have a mother board with the following

00:00.0 Host bridge: VIA Technologies, Inc. VT8623 [Apollo CLE266]
00:01.0 PCI bridge: VIA Technologies, Inc. VT8633 [Apollo Pro266 AGP]
00:08.0 Ethernet controller: Realtek Semiconductor Co., Ltd. 
RTL-8139/8139C/8139C+ (rev 10)
00:0d.0 Ethernet controller: Realtek Semiconductor Co., Ltd. 
RTL-8139/8139C/8139C+ (rev 10)
00:10.0 USB Controller: VIA Technologies, Inc. VT82xxxxx UHCI USB 1.1 
Controller (rev 80)
00:10.1 USB Controller: VIA Technologies, Inc. VT82xxxxx UHCI USB 1.1 
Controller (rev 80)
00:10.2 USB Controller: VIA Technologies, Inc. VT82xxxxx UHCI USB 1.1 
Controller (rev 80)
00:10.3 USB Controller: VIA Technologies, Inc. USB 2.0 (rev 82)
00:11.0 ISA bridge: VIA Technologies, Inc. VT8235 ISA Bridge
00:11.1 IDE interface: VIA Technologies, Inc. 
VT82C586A/B/VT82C686/A/B/VT823x/A/C PIPC Bus Master IDE (rev 06)
00:11.5 Multimedia audio controller: VIA Technologies, Inc. 
VT8233/A/8235/8237 AC97 Audio Controller (rev 50)
01:00.0 VGA compatible controller: VIA Technologies, Inc. VT8623 
[Apollo CLE266] integrated CastleRock graphics (rev 03)

The superio is ITE IT8705F (markings on the chip)

superiotool r3127
Found ITE IT8705F/AF / IT8700F (id=0x8705, rev=0x3) at 0x2e
Found ITE IT8705F/AF / IT8700F (id=0x8705, rev=0x3) at 0x4e

Flash is a 32 pin PLCC winbond 49V002AP and is flashable by the dos 
prog (actually i run freedos over tftp).

I already have the v2 tree installed and can compile the epia / epia-m 
target . Since these have vt1611 superio, how do I go about porting 
to my board with the rtl8139 and IT8705F.


Rgds
JTD



From r.marek at assembler.cz  Fri Mar  7 11:03:51 2008
From: r.marek at assembler.cz (Rudolf Marek)
Date: Fri, 07 Mar 2008 11:03:51 +0100
Subject: [coreboot] ASUS A8V-E Deluxe now supported
In-Reply-To: <20080306235155.GG15848@greenwood>
References: <20080306235155.GG15848@greenwood>
Message-ID: <47D11307.6080309@assembler.cz>

Hi,

> I'm happy to announce that the ASUS A8V-E Deluxe board works pretty well
> in coreboot v2 already. I haven't even touched more than 1 (in words: one)
> lines of code. This is all thanks to Rudolf Marek's great work on the
> ASUS A8V-E SE board, which is very similar to this one.

Cool!

> I've posted the full status table and a small build tutorial in the wiki:
> 
> http://www.coreboot.org/ASUS_A8V-E_Deluxe_Build_Tutorial

Good that the gameport and parport works.

> 
> It boots up to a Linux login prompt, CPU, RAM, SATA (port 1), audio, ethernet,
> USB, VGA, and lots of other stuff work fine. Even 'poweroff' and
> 'reboot' work, probably thanks to the ACPI implementation by Rudolf.

Yes, you need to add ACPI IRQ routing for 0x7 and 0x8

   +-07.0  Marvell Technology Group Ltd. 88W8310 and 88W8000G [Libertas] 802.11g 
client chipset [11ab:1fa7]
            +-08.0  Texas Instruments TSB43AB22/A IEEE-1394a-2000 Controller 
(PHY/Link) [104c:8023]


> There are some TODOs left (IDE seems to have a problem, SATA port 2
> also, and a few other things hasn't yet been tested), I'll work on
> fixing them in the next few days or so.

I think it is FILO problem. Please test the devices in Linux first.
SATA is in "legacy" mode, so each SATA port has 2 master/slave devices.

In FILO:
SATA1 - hd0 (hd1 shadow)
SATA2 - hd2  (hd3 shadow)
IDE0  - hd4 master
IDE0 - hd5 slave
IDE1 - hd6 master
IDE1 - hd7 slave

Thanks,
Rudolf



From traut at gmx.de  Fri Mar  7 14:23:40 2008
From: traut at gmx.de (Martin Trautmann)
Date: Fri, 07 Mar 2008 14:23:40 +0100
Subject: [coreboot] Geode GX / CS5535 / PIC
In-Reply-To: <20080229153624.GB14418@cosmic.amd.com>
References: <47C73861.3010802@gmx.de> <20080229004346.5836.qmail@stuge.se>
	<20080229153624.GB14418@cosmic.amd.com>
Message-ID: <47D141DC.2040504@gmx.de>

Jordan Crouse wrote:

> GX/5535 in v3 would be a fairly straightforward port of the already
> existing LX support, and would be a great way for somebody who wants
> to learn about the deep down internals of the Geode architecture.

Is there any HOWTO migrate? I know that there are about 1000 lines of 
different code between CS5535 and CS5536 in v2, while CS5536 in v2 is 
very different to the same in v3.

I did try to find out about the differnces in v2 and repeat the same 
process in v3 from CS5536 to CS5535 - but I feel I miss the basic 
understanding and do some simple try'n'error only.

Thanks,
Martin



From c-d.hailfinger.devel.2006 at gmx.net  Fri Mar  7 15:20:56 2008
From: c-d.hailfinger.devel.2006 at gmx.net (Carl-Daniel Hailfinger)
Date: Fri, 07 Mar 2008 15:20:56 +0100
Subject: [coreboot] [PATCH] v3: fix bugs in Geode LX RAMinit
Message-ID: <47D14F48.8020508@gmx.net>

Marc? It would be nice if you could read through the code and verify the 
things I did.

northbridge/amd/geodelx/raminit.c:auto_size_dimm() checks for the 
mathematically impossible condition of a value being above and below the 
specified range at the same time. Change it to check for out-of-range.
arch/x86/geodelx/geodelx.c:set_delay_control() is missing a break, it 
will keep going and mess up DRAM timings.

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

Index: LinuxBIOSv3-geodelx_dram_fixes/northbridge/amd/geodelx/raminit.c
===================================================================
--- LinuxBIOSv3-geodelx_dram_fixes/northbridge/amd/geodelx/raminit.c	(Revision 638)
+++ LinuxBIOSv3-geodelx_dram_fixes/northbridge/amd/geodelx/raminit.c	(Arbeitskopie)
@@ -79,7 +79,7 @@
 	/* EEPROM byte usage: (5) Number of DIMM Banks */
 	banner(BIOS_DEBUG, "MODBANKS");
 	spd_byte = spd_read_byte(dimm, SPD_NUM_DIMM_BANKS);
-	if ((MIN_MOD_BANKS > spd_byte) && (spd_byte > MAX_MOD_BANKS)) {
+	if ((MIN_MOD_BANKS > spd_byte) || (spd_byte > MAX_MOD_BANKS)) {
 		printk(BIOS_EMERG, "Number of module banks not compatible\n");
 		post_code(ERROR_BANK_SET);
 		hlt();
@@ -90,7 +90,7 @@
 	/* EEPROM byte usage: (17) Number of Banks on SDRAM Device */
 	banner(BIOS_DEBUG, "FIELDBANKS");
 	spd_byte = spd_read_byte(dimm, SPD_NUM_BANKS_PER_SDRAM);
-	if ((MIN_DEV_BANKS > spd_byte) && (spd_byte > MAX_DEV_BANKS)) {
+	if ((MIN_DEV_BANKS > spd_byte) || (spd_byte > MAX_DEV_BANKS)) {
 		printk(BIOS_EMERG, "Number of device banks not compatible\n");
 		post_code(ERROR_BANK_SET);
 		hlt();
Index: LinuxBIOSv3-geodelx_dram_fixes/arch/x86/geodelx/geodelx.c
===================================================================
--- LinuxBIOSv3-geodelx_dram_fixes/arch/x86/geodelx/geodelx.c	(Revision 638)
+++ LinuxBIOSv3-geodelx_dram_fixes/arch/x86/geodelx/geodelx.c	(Arbeitskopie)
@@ -386,6 +386,7 @@
 				msr.hi |= delay_control_table[i].fast_hi;
 				msr.lo |= delay_control_table[i].fast_low;
 			}
+			break;
 		}
 	}
 	wrmsr(GLCP_DELAY_CONTROLS, msr);


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




From peter at stuge.se  Fri Mar  7 15:24:54 2008
From: peter at stuge.se (Peter Stuge)
Date: Fri, 7 Mar 2008 15:24:54 +0100
Subject: [coreboot] [PATCH] Merge lib/ramtest.c into lib/ram.c
In-Reply-To: <47D09C43.3030002@gmx.net>
References: <20080306232555.GD15848@greenwood>
	<13426df10803061722m2ac3242bl55b0bf0150ba1639@mail.gmail.com>
	<47D09C43.3030002@gmx.net>
Message-ID: <20080307142454.23151.qmail@stuge.se>

On Fri, Mar 07, 2008 at 02:37:07AM +0100, Carl-Daniel Hailfinger wrote:
> Yes, it really should depend on Kconfig. However, we will have to
> provide an empty ramtest function to make this mostly transparent
> or work with ifdefs in the mainboard code.

I prefer the ifdef.


//Peter



From mylesgw at gmail.com  Fri Mar  7 17:11:45 2008
From: mylesgw at gmail.com (Myles Watson)
Date: Fri, 7 Mar 2008 09:11:45 -0700
Subject: [coreboot] lar copy patch
In-Reply-To: <47D09BAD.7090305@gmx.net>
References: <2831fecf0803061547j1888dffem928bd6a4d2c85dda@mail.gmail.com>
	<47D09BAD.7090305@gmx.net>
Message-ID: <000901c8806d$f16f6860$7d23040a@chimp>



> -----Original Message-----
> From: Carl-Daniel Hailfinger [mailto:c-d.hailfinger.devel.2006 at gmx.net]
> Sent: Thursday, March 06, 2008 6:35 PM
> To: Myles Watson
> Cc: Coreboot
> Subject: Re: [coreboot] lar copy patch
> 
> On 07.03.2008 00:47, Myles Watson wrote:
> > This patch adds copy functionality to lar via
> >
> > lar -L srclar.file
> >
> 
> Although I appreciate the work you've done, I still feel the lar copy
> approach is not right.
 
The other options I've seen are:
	1. Invent a new file format
	2. Extract to ELF minus some information

> > It allows you to use payloads, bootblocks, or other entries from one
> > lar when creating or adding to another.
> >
> > changes by file:
> > util/lar/lar.c:
> > 	change usage
> > 	add srcarchivename parameter for create_lar and add_lar
> > 	add lar_copy functionality to create_lar and add_lar
> > 	add -C keep for using the same compression as srclar
> > util/lar/lar.h:
> > 	change invalid to invalid_or_keep in algo_strings
> >
> > util/lar/lib.c:
> > 	pull out function add_entry from add_files
> >
> > util/lar/lib.h:
> > 	add prototypes for add_entry and lar_copy
> > 	change prototype for create_lar (wonder why add_lar doesn't have
> one)
> > 	fix whitespace
> >
> > util/lar/stream.c:
> > 	pull out helper function file_in_list_where from file_in_list
> > 	add lar_copy
> >
> > This is a test of the copy functionality of lar.  I'll use C++-style
> comments
> >      // here's the original lar file
> > [myles at orangutan svn]$ build/util/lar/lar -l build/coreboot.rom
> >   normal/option_table (932 bytes @0x50);loadaddress 0x0 entry 0x0
> >   normal/initram/segment0 (432 bytes @0x450);loadaddress 0x0 entry
> 0x0x42
> >   normal/stage2/segment0 (191792 bytes, zeroes compressed to 1 bytes
> > @0x650);loadaddress 0x0xa540 entry 0x0x2000
> >   normal/stage2/segment1 (28172 bytes, lzma compressed to 15083 bytes
> > @0x6b0);loadaddress 0x0x2000 entry 0x0x2000
> >   normal/stage2/segment2 (5420 bytes, lzma compressed to 312 bytes
> > @0x41f0);loadaddress 0x0x9000 entry 0x0x2000
> >   bootblock (20480 bytes @0xfb000)
> > Total size = 37688B 36KB (0x9338)
> >
> >      //create a new 256K lar file called bootblock.rom which has the
> > same bootblock as coreboot.rom
> > [myles at orangutan svn]$ build/util/lar/lar -c -s 256K bootblock.rom -L
> > build/coreboot.rom
> >
> >      //create a new lar file with uncompressed normal/stage2
> > [myles at orangutan svn]$ build/util/lar/lar -c -s 256K normal_stage2.rom
> > -L build/coreboot.rom nocompress:normal/stage2:stage2
> >
> 
> Wait. You add a file with path "stage2" as "normal/stage2"? That's wrong.

That's backward.  The first part of the argument is the original or file
name.  I'm adding the entries from build/coreboot.rom named normal/stage2*
and renaming them stage2*. 

> >      //create a new lar file with lzma compressed normal/init
> > [myles at orangutan svn]$ build/util/lar/lar -c -s 256K normal_init.rom
> > -L build/coreboot.rom -C lzma normal/init
> >
> 
> What is normal/init? That thing does not exist as path.

I changed the matching to greedy matching in an earlier path, since it makes
sense to get the whole payload at once.  In other words, when you extract
normal/payload, you get normal/payload/segment0, normal/payload/segment1,
etc.  I put this in there to make that clear.

> >      //create a new lar file with normal/opt compressed the same as it
> was
> > [myles at orangutan svn]$ build/util/lar/lar -c -s 256K normal_opt.rom -L
> > build/coreboot.rom -C keep  normal/opt
> >
> >      //create a new 1M lar using the bootblock in bootblock.rom
> > [myles at orangutan svn]$ build/util/lar/lar -c -s 1M new.rom -L
> bootblock.rom
> >
> 
> How does LAR know that you want to copy the bootblock instead of an
> empty operation?

Since it is a create operation with a source lar, it copies the bootblock.
It made sense to me that if you want a new lar starting with an old one, you
were asking for the bootblock.  

> 
> >      //add back in the components with the correct compression
> > [myles at orangutan svn]$ build/util/lar/lar -a new.rom -L normal_opt.rom
> > -C none normal/
> > [myles at orangutan svn]$ build/util/lar/lar -a new.rom -L
> > normal_init.rom -C none normal/init
> >
> >      //use the verbose switch to see what you're getting
> > [myles at orangutan svn]$ build/util/lar/lar -av new.rom -L
> > normal_stage2.rom -C lzma stage2:normal/stage2
> >
> 
> Here the stange stage2 mentioning happens again.
> 

This is the opposite of what happened earlier.  Now I'm taking the files
named stage2* and putting them into the new lar with base name normal/stage2
so that the new lar will have the same format as build/coreboot.rom.

> > ... adding stage2:normal/stage2
> > stage2:normal/stage2 (lzma) matches stage2/segment0 =>
> normal/stage2/segment0.
> > stage2:normal/stage2 (lzma) matches stage2/segment1 =>
> normal/stage2/segment1.
> > stage2:normal/stage2 (lzma) matches stage2/segment2 =>
> normal/stage2/segment2.
> >
> >      //diff the two files
> > [myles at orangutan svn]$ diff new.rom build/coreboot.rom
> >  // There's no difference
> >
> > I think it would be nice if lar would warn you (or stop you) when you
> > try to add a duplicate entry.  Maybe that will be the next patch.
> >
> > Myles
> >
> > Signed-off-by: Myles Watson <mylesgw at gmail.com>
> >
> 
> Regards,
> Carl-Daniel

Thanks for looking over it.

Myles




From mylesgw at gmail.com  Fri Mar  7 17:17:16 2008
From: mylesgw at gmail.com (Myles Watson)
Date: Fri, 7 Mar 2008 09:17:16 -0700
Subject: [coreboot] [BUILDROM] Fix memtest bug
In-Reply-To: <20080306225837.GH11861@cosmic.amd.com>
References: <20080306225837.GH11861@cosmic.amd.com>
Message-ID: <000a01c8806e$b6c41200$7d23040a@chimp>


> 
> Fix a bug in memtest - apparently we haven't _ever_ passed the
> CFLAGS correctly.  Doesn't anybody ever try the memtest payload? :)

It compiles either way for me, but your patch makes it correct.

Acked-by: Myles Watson mylesgw at gmail.com






From svn at coreboot.org  Fri Mar  7 17:22:35 2008
From: svn at coreboot.org (svn at coreboot.org)
Date: Fri,  7 Mar 2008 17:22:35 +0100
Subject: [coreboot] r135 - buildrom-devel/packages/memtest
Message-ID: <mailman.1258.1355071276.16123.coreboot@coreboot.org>

Author: jcrouse
Date: 2008-03-07 17:22:35 +0100 (Fri, 07 Mar 2008)
New Revision: 135

Modified:
   buildrom-devel/packages/memtest/memtest.mk
Log:
[BUILDROM] Fix typo in memtest

Fix a typo in memtest that let our good friend _stack_chk_fail
get through.  How did this buglet last this long?

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


Modified: buildrom-devel/packages/memtest/memtest.mk
===================================================================
--- buildrom-devel/packages/memtest/memtest.mk	2008-02-26 04:38:29 UTC (rev 134)
+++ buildrom-devel/packages/memtest/memtest.mk	2008-03-07 16:22:35 UTC (rev 135)
@@ -36,7 +36,7 @@
 	
 $(MEMTEST_SRC_DIR)/memtest: $(MEMTEST_CONFIG_TARGET)
 	@ echo "Building memtest..."
-	@ $(MAKE) -C $(MEMTEST_SRC_DIR) AS="$(AS) $(CROSS_ASFLAGS)" CC="$(CC) $(CROSS_CFLAGS)" LD="$(LD) $(CROSS_LDFLAGS)" CCFLAGS="$(CFLAGS)" memtest > $(MEMTEST_BUILD_LOG) 2>&1
+	@ $(MAKE) -C $(MEMTEST_SRC_DIR) AS="$(AS) $(CROSS_ASFLAGS)" CC="$(CC) $(CROSS_CFLAGS)" LD="$(LD) $(CROSS_LDFLAGS)" CFLAGS="$(CFLAGS)" memtest > $(MEMTEST_BUILD_LOG) 2>&1
 
 $(MEMTEST_STAMP_DIR) $(MEMTEST_LOG_DIR):
 	@ mkdir -p $@




From jordan.crouse at amd.com  Fri Mar  7 17:23:10 2008
From: jordan.crouse at amd.com (Jordan Crouse)
Date: Fri, 7 Mar 2008 09:23:10 -0700
Subject: [coreboot] Fix memtest bug
In-Reply-To: <000a01c8806e$b6c41200$7d23040a@chimp>
References: <20080306225837.GH11861@cosmic.amd.com>
	<000a01c8806e$b6c41200$7d23040a@chimp>
Message-ID: <20080307162310.GJ11861@cosmic.amd.com>

On 07/03/08 09:17 -0700, Myles Watson wrote:
> 
> > 
> > Fix a bug in memtest - apparently we haven't _ever_ passed the
> > CFLAGS correctly.  Doesn't anybody ever try the memtest payload? :)
> 
> It compiles either way for me, but your patch makes it correct.

Yeah, this was the usual Ubuntu thing.  Thanks.

> Acked-by: Myles Watson mylesgw at gmail.com

r135

> 
> 
> 
> -- 
> 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 mylesgw at gmail.com  Fri Mar  7 19:02:58 2008
From: mylesgw at gmail.com (Myles Watson)
Date: Fri, 7 Mar 2008 11:02:58 -0700
Subject: [coreboot] buildrom rom size patch
Message-ID: <2831fecf0803071002q30275baej7d195f6825270d05@mail.gmail.com>

This patch makes use of the CONFIG_COREBOOT_V3_ROM_SIZE variable in buildrom.
The hope is that eventually we could do some math with it if we want.  The
only problem is that when you don't have it set, it gives you an error when
you do make menuconfig.  Here is the error:

#
# using defaults found in .config
#
.config:23:warning: symbol value '' invalid for COREBOOT_V3_ROM_SIZE
.config:83:warning: symbol value '' invalid for LAB_PAUSE

Notice that LAB_PAUSE has the same problem.  Setting the value to be a string
instead of an int removes the warning, but removes the error checking as well.

Myles

Signed-off-by: Myles Watson <mylesgw at gmail.com>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: rom_size.patch
Type: text/x-patch
Size: 1641 bytes
Desc: not available
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20080307/5900d029/attachment.patch>

From marc.jones at amd.com  Fri Mar  7 19:16:29 2008
From: marc.jones at amd.com (Marc Jones)
Date: Fri, 07 Mar 2008 11:16:29 -0700
Subject: [coreboot] [PATCH] v3: fix bugs in Geode LX RAMinit
In-Reply-To: <47D14F48.8020508@gmx.net>
References: <47D14F48.8020508@gmx.net>
Message-ID: <47D1867D.7050602@amd.com>



Carl-Daniel Hailfinger wrote:
> Marc? It would be nice if you could read through the code and verify the 
> things I did.
> 
> northbridge/amd/geodelx/raminit.c:auto_size_dimm() checks for the 
> mathematically impossible condition of a value being above and below the 
> specified range at the same time. Change it to check for out-of-range.
> arch/x86/geodelx/geodelx.c:set_delay_control() is missing a break, it 
> will keep going and mess up DRAM timings.
> 
> Signed-off-by: Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006 at gmx.net>
> 

Strange, The raminit in v2 was correct. Both changes look right to me. I 
didn't build or run it. I am a bit swamped in something else right now.

Ron, can you test this?

BTW, Thanks to Carl-Daniel, Ron, and Uwe for recent work on LX. You are 
making good improvements to the code.

Acked-by: Marc Jones <marc.jones at amd.com>




> Index: LinuxBIOSv3-geodelx_dram_fixes/northbridge/amd/geodelx/raminit.c
> ===================================================================
> --- LinuxBIOSv3-geodelx_dram_fixes/northbridge/amd/geodelx/raminit.c    
> (Revision 638)
> +++ LinuxBIOSv3-geodelx_dram_fixes/northbridge/amd/geodelx/raminit.c    
> (Arbeitskopie)
> @@ -79,7 +79,7 @@
>     /* EEPROM byte usage: (5) Number of DIMM Banks */
>     banner(BIOS_DEBUG, "MODBANKS");
>     spd_byte = spd_read_byte(dimm, SPD_NUM_DIMM_BANKS);
> -    if ((MIN_MOD_BANKS > spd_byte) && (spd_byte > MAX_MOD_BANKS)) {
> +    if ((MIN_MOD_BANKS > spd_byte) || (spd_byte > MAX_MOD_BANKS)) {
>         printk(BIOS_EMERG, "Number of module banks not compatible\n");
>         post_code(ERROR_BANK_SET);
>         hlt();
> @@ -90,7 +90,7 @@
>     /* EEPROM byte usage: (17) Number of Banks on SDRAM Device */
>     banner(BIOS_DEBUG, "FIELDBANKS");
>     spd_byte = spd_read_byte(dimm, SPD_NUM_BANKS_PER_SDRAM);
> -    if ((MIN_DEV_BANKS > spd_byte) && (spd_byte > MAX_DEV_BANKS)) {
> +    if ((MIN_DEV_BANKS > spd_byte) || (spd_byte > MAX_DEV_BANKS)) {
>         printk(BIOS_EMERG, "Number of device banks not compatible\n");
>         post_code(ERROR_BANK_SET);
>         hlt();
> Index: LinuxBIOSv3-geodelx_dram_fixes/arch/x86/geodelx/geodelx.c
> ===================================================================
> --- LinuxBIOSv3-geodelx_dram_fixes/arch/x86/geodelx/geodelx.c    
> (Revision 638)
> +++ LinuxBIOSv3-geodelx_dram_fixes/arch/x86/geodelx/geodelx.c    
> (Arbeitskopie)
> @@ -386,6 +386,7 @@
>                 msr.hi |= delay_control_table[i].fast_hi;
>                 msr.lo |= delay_control_table[i].fast_low;
>             }
> +            break;
>         }
>     }
>     wrmsr(GLCP_DELAY_CONTROLS, msr);
> 
> 

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




From dsedrich at violin-memory.com  Fri Mar  7 20:05:21 2008
From: dsedrich at violin-memory.com (David Edrich)
Date: Fri, 7 Mar 2008 13:05:21 -0600
Subject: [coreboot] qemu error message: "Unrecognized
	partitioning	scheme"
In-Reply-To: <13426df10803062110s37962c46he6573a90e51a50ad@mail.gmail.com>
References: <031701c87e48$7e531ba0$7af952e0$@com>	<13426df10803041502v37b079a7ob131b1e68f797ee8@mail.gmail.com>	<035901c87f02$89a62b90$9cf282b0$@com>	<2831fecf0803051459g8a361ddk2ee7f6f6a07c595a@mail.gmail.com>	<03bc01c87fb1$fb73fa40$f25beec0$@com>	<13426df10803061400n7f00ee2bte7728f9e475643b9@mail.gmail.com>	<040501c87fde$b3642090$1a2c61b0$@com>
	<13426df10803062110s37962c46he6573a90e51a50ad@mail.gmail.com>
Message-ID: <043601c88086$33ec3430$9bc49c90$@com>

It's attached.

> -----Original Message-----
> From: coreboot-bounces at coreboot.org [mailto:coreboot-bounces at coreboot.org] On Behalf Of ron minnich
> Sent: Thursday, March 06, 2008 11:11 PM
> To: David Edrich
> Cc: Myles Watson; Coreboot
> Subject: Re: [coreboot] qemu error message: "Unrecognized partitioning scheme"
> 
> On Thu, Mar 6, 2008 at 3:06 PM, David Edrich <dsedrich at violin-memory.com> wrote:
> > It's like 2 Gigabytes. Even if I Tar it, it will be 100's of megs so it doesn't seem practical to
> send
> >
> >  From my understanding FILO gets to the "menu" file, in the disk image, without any problems. Then,
> to access files after that, FILO
> >  want to read some partition information from, I would guess, the MBR -- and there is no MBR from
> the process we used to generate the
> >  disk image file. I think that is the problem. I don't know much about qemu-img options that may get
> around this or if some FILO
> >  options do this. I would guess that that would be where to try and find a way out of this.
> >
> 
> what's your menu file look like? This stuff should all work without
> partitions or MBR. We solved the first problem -- by saying hda
> instead of hda3 -- I guess the
> second problem is solved in the menu file. Can you show us that file?
> 
> ron
> 
> --
> coreboot mailing list
> coreboot at coreboot.org
> http://www.coreboot.org/mailman/listinfo/coreboot

-------------- next part --------------
A non-text attachment was scrubbed...
Name: menu.lst
Type: application/octet-stream
Size: 550 bytes
Desc: not available
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20080307/af071163/attachment.obj>

From rminnich at gmail.com  Fri Mar  7 20:09:25 2008
From: rminnich at gmail.com (ron minnich)
Date: Fri, 7 Mar 2008 11:09:25 -0800
Subject: [coreboot] qemu error message: "Unrecognized partitioning
	scheme"
In-Reply-To: <043601c88086$33ec3430$9bc49c90$@com>
References: <031701c87e48$7e531ba0$7af952e0$@com>
	<13426df10803041502v37b079a7ob131b1e68f797ee8@mail.gmail.com>
	<035901c87f02$89a62b90$9cf282b0$@com>
	<2831fecf0803051459g8a361ddk2ee7f6f6a07c595a@mail.gmail.com>
	<03bc01c87fb1$fb73fa40$f25beec0$@com>
	<13426df10803061400n7f00ee2bte7728f9e475643b9@mail.gmail.com>
	<040501c87fde$b3642090$1a2c61b0$@com>
	<13426df10803062110s37962c46he6573a90e51a50ad@mail.gmail.com>
	<043601c88086$33ec3430$9bc49c90$@com>
Message-ID: <13426df10803071109g7738c39qc1267ade26808b45@mail.gmail.com>

yes, it is specifying the equivalent of a partition in the menu.lst.

Now I realize -- I don't know how to NOT do this in filo. Anyone know?

hd(0) instead of hd(0,0)?

ron



From c-d.hailfinger.devel.2006 at gmx.net  Fri Mar  7 20:15:23 2008
From: c-d.hailfinger.devel.2006 at gmx.net (Carl-Daniel Hailfinger)
Date: Fri, 07 Mar 2008 20:15:23 +0100
Subject: [coreboot] [PATCH] v3: fix bugs in Geode LX RAMinit
In-Reply-To: <47D1867D.7050602@amd.com>
References: <47D14F48.8020508@gmx.net> <47D1867D.7050602@amd.com>
Message-ID: <47D1944B.7000102@gmx.net>

On 07.03.2008 19:16, Marc Jones wrote:
> Carl-Daniel Hailfinger wrote:
>   
>> Marc? It would be nice if you could read through the code and verify the 
>> things I did.
>>
>> northbridge/amd/geodelx/raminit.c:auto_size_dimm() checks for the 
>> mathematically impossible condition of a value being above and below the 
>> specified range at the same time. Change it to check for out-of-range.
>> arch/x86/geodelx/geodelx.c:set_delay_control() is missing a break, it 
>> will keep going and mess up DRAM timings.
>>
>> Signed-off-by: Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006 at gmx.net>
>>
>>     
>
> Strange, The raminit in v2 was correct. Both changes look right to me. I 
> didn't build or run it. I am a bit swamped in something else right now.
>   

The raminit in v2 was fixed in r2899 | rminnich | 2007-10-26 with this log:
> The lxraminit change fixes a bug (&& used instead of ||) [...]
> Signed-off-by: Ronald G. Minnich <rminnich at gmail.com>
> Acked-by: Peter Stuge <peter at stuge.se>


On 07.03.2008 19:16, Marc Jones wrote:
> Ron, can you test this?
>
> BTW, Thanks to Carl-Daniel, Ron, and Uwe for recent work on LX. You are 
> making good improvements to the code.
>   

You're welcome.

> Acked-by: Marc Jones <marc.jones at amd.com>
>   

Thanks! I will wait a bit before committing to give Ron the chance to test.

Regards,
Carl-Daniel

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




From uwe at hermann-uwe.de  Fri Mar  7 21:50:06 2008
From: uwe at hermann-uwe.de (Uwe Hermann)
Date: Fri, 7 Mar 2008 21:50:06 +0100
Subject: [coreboot] [PATCH] Make RAM check configurable via Kconfig
In-Reply-To: <20080307142454.23151.qmail@stuge.se>
References: <20080306232555.GD15848@greenwood>
	<13426df10803061722m2ac3242bl55b0bf0150ba1639@mail.gmail.com>
	<47D09C43.3030002@gmx.net> <20080307142454.23151.qmail@stuge.se>
Message-ID: <20080307205006.GA7013@greenwood>

On Fri, Mar 07, 2008 at 03:24:54PM +0100, Peter Stuge wrote:
> On Fri, Mar 07, 2008 at 02:37:07AM +0100, Carl-Daniel Hailfinger wrote:
> > Yes, it really should depend on Kconfig. However, we will have to
> > provide an empty ramtest function to make this mostly transparent
> > or work with ifdefs in the mainboard code.
> 
> I prefer the ifdef.

Here's a first patch to make it configurable via Kconfig.

I'm getting some linker errors when I try to merge ram.c and ramtest.c,
(probably needs some Makefile changes), so that's deferred to later.


Uwe.
-- 
http://www.hermann-uwe.de  | http://www.holsham-traders.de
http://www.crazy-hacks.org | http://www.unmaintained-free-software.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: v3_ramtest_kconfig.patch
Type: text/x-diff
Size: 4034 bytes
Desc: not available
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20080307/194ae24b/attachment.bin>

From kbaski at yahoo.com  Fri Mar  7 23:31:30 2008
From: kbaski at yahoo.com (Baski)
Date: Fri, 7 Mar 2008 14:31:30 -0800 (PST)
Subject: [coreboot] s2881 - IDE path problem in GRUB if SATA is enabled
In-Reply-To: <mailman.748.1204143475.27277.coreboot@coreboot.org>
Message-ID: <542248.44788.qm@web51608.mail.re2.yahoo.com>

My Config - tyan 2881 + FILO payload + ubuntu on IDE-0 + LBv2

So far I've been using this setup with onboard SATA disabled.
Today I opened the jumper and enabled the SATA.  It stopped at Grub console.  I manually entered the path for the boot drive "root (hd0,0)", but it says something like 
hda1:/boot/vmlinuz.... 'Drive 0 not present'.
The original BIOS boots ok.
Any ideas?
TIA- Baski

       
---------------------------------
Never miss a thing.   Make Yahoo your homepage.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20080307/2579c55e/attachment.html>

From rminnich at gmail.com  Sat Mar  8 00:10:27 2008
From: rminnich at gmail.com (ron minnich)
Date: Fri, 7 Mar 2008 15:10:27 -0800
Subject: [coreboot] [PATCH] Make RAM check configurable via Kconfig
In-Reply-To: <20080307205006.GA7013@greenwood>
References: <20080306232555.GD15848@greenwood>
	<13426df10803061722m2ac3242bl55b0bf0150ba1639@mail.gmail.com>
	<47D09C43.3030002@gmx.net> <20080307142454.23151.qmail@stuge.se>
	<20080307205006.GA7013@greenwood>
Message-ID: <13426df10803071510q46bcbc5eoca4bf96635d66144@mail.gmail.com>

So, I am curious.

I see this:
	ram_check(0, 640 * 1024);

in a file. Could I be forgiven in thinking that a ram check might be
done? I realize this is the "linux style" but I have never
particularly liked it.

What is wrong with
#ifdef RAMTEST
	ram_check(0, 640 * 1024);
#endif

What do people prefer? Maybe I am just out of touch.

thanks

ron



From c-d.hailfinger.devel.2006 at gmx.net  Sat Mar  8 00:31:22 2008
From: c-d.hailfinger.devel.2006 at gmx.net (Carl-Daniel Hailfinger)
Date: Sat, 08 Mar 2008 00:31:22 +0100
Subject: [coreboot] [PATCH] Make RAM check configurable via Kconfig
In-Reply-To: <13426df10803071510q46bcbc5eoca4bf96635d66144@mail.gmail.com>
References: <20080306232555.GD15848@greenwood>	<13426df10803061722m2ac3242bl55b0bf0150ba1639@mail.gmail.com>	<47D09C43.3030002@gmx.net>
	<20080307142454.23151.qmail@stuge.se>	<20080307205006.GA7013@greenwood>
	<13426df10803071510q46bcbc5eoca4bf96635d66144@mail.gmail.com>
Message-ID: <47D1D04A.7000000@gmx.net>

On 08.03.2008 00:10, ron minnich wrote:
> So, I am curious.
>
> I see this:
> 	ram_check(0, 640 * 1024);
>
> in a file. Could I be forgiven in thinking that a ram check might be
> done? I realize this is the "linux style" but I have never
> particularly liked it.
>
> What is wrong with
> #ifdef RAMTEST
> 	ram_check(0, 640 * 1024);
> #endif
>
> What do people prefer? Maybe I am just out of touch.
>   

That's fine with me as well. It all depends on your expectations and how
well you know these config options. Right now, an #ifdef might be the
best solution, especially now that v3 has a lot of momentum and we
expect people less familiar with the code to contribute.

Regards,
Carl-Daniel

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




From ward at gnu.org  Sat Mar  8 01:11:50 2008
From: ward at gnu.org (Ward Vandewege)
Date: Fri, 7 Mar 2008 19:11:50 -0500
Subject: [coreboot] s2881 - IDE path problem in GRUB if SATA is enabled
In-Reply-To: <542248.44788.qm@web51608.mail.re2.yahoo.com>
References: <mailman.748.1204143475.27277.coreboot@coreboot.org>
	<542248.44788.qm@web51608.mail.re2.yahoo.com>
Message-ID: <20080308001150.GA16050@localdomain>

On Fri, Mar 07, 2008 at 02:31:30PM -0800, Baski wrote:
>    My Config - tyan 2881 + FILO payload + ubuntu on IDE-0 + LBv2
> 
>    So far I've been using this setup with onboard SATA disabled.
>    Today I opened the jumper and enabled the SATA.  It stopped at Grub
>    console.  I manually entered the path for the boot drive "root (hd0,0)",
>    but it says something like
>    hda1:/boot/vmlinuz.... 'Drive 0 not present'.
>    The original BIOS boots ok.

Try (hd4,0), and hde1.

Thanks,
Ward.

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



From uwe at hermann-uwe.de  Sat Mar  8 02:09:22 2008
From: uwe at hermann-uwe.de (Uwe Hermann)
Date: Sat, 8 Mar 2008 02:09:22 +0100
Subject: [coreboot] [PATCH] Make RAM check configurable via Kconfig
In-Reply-To: <13426df10803071510q46bcbc5eoca4bf96635d66144@mail.gmail.com>
References: <20080306232555.GD15848@greenwood>
	<13426df10803061722m2ac3242bl55b0bf0150ba1639@mail.gmail.com>
	<47D09C43.3030002@gmx.net> <20080307142454.23151.qmail@stuge.se>
	<20080307205006.GA7013@greenwood>
	<13426df10803071510q46bcbc5eoca4bf96635d66144@mail.gmail.com>
Message-ID: <20080308010921.GA18899@greenwood>

On Fri, Mar 07, 2008 at 03:10:27PM -0800, ron minnich wrote:
> So, I am curious.
> 
> I see this:
> 	ram_check(0, 640 * 1024);
> 
> in a file. Could I be forgiven in thinking that a ram check might be
> done? I realize this is the "linux style" but I have never
> particularly liked it.
> 
> What is wrong with
> #ifdef RAMTEST
> 	ram_check(0, 640 * 1024);
> #endif
> 
> What do people prefer? Maybe I am just out of touch.

It's mostly a matter of preference, yes. The nice thing here is that
you have an #ifdef _once_ and not in every single location where
the function is called. Looks much cleaner overall in the code.

We do similar stuff with printk btw. Depending on the loglevel a

  prink(BIOS_INFO, "Hello world");

does something or does nothing. You wouldn't want to write 

  #if (LOGLEVEL >= x)
  printk(...);
  #endif

everytime you want to print a messge.


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



From rminnich at gmail.com  Sat Mar  8 02:41:35 2008
From: rminnich at gmail.com (ron minnich)
Date: Fri, 7 Mar 2008 17:41:35 -0800
Subject: [coreboot] [PATCH] Make RAM check configurable via Kconfig
In-Reply-To: <20080308010921.GA18899@greenwood>
References: <20080306232555.GD15848@greenwood>
	<13426df10803061722m2ac3242bl55b0bf0150ba1639@mail.gmail.com>
	<47D09C43.3030002@gmx.net> <20080307142454.23151.qmail@stuge.se>
	<20080307205006.GA7013@greenwood>
	<13426df10803071510q46bcbc5eoca4bf96635d66144@mail.gmail.com>
	<20080308010921.GA18899@greenwood>
Message-ID: <13426df10803071741k12feebedr16bfcda0a0a8bc26@mail.gmail.com>

OK,how about we do something like this:

ram_check(BIOS_DEBUG, 0, 640*1024);

so it is clear to the casual browser that the ram_check happens at
that debug level? Or condition it on some other cpp symbol?

I'm just very concerned that we not have confusion about this type of
function and whether it is active.

thanks

ron



From c-d.hailfinger.devel.2006 at gmx.net  Sat Mar  8 03:36:00 2008
From: c-d.hailfinger.devel.2006 at gmx.net (Carl-Daniel Hailfinger)
Date: Sat, 08 Mar 2008 03:36:00 +0100
Subject: [coreboot] [PATCH] Make RAM check configurable via Kconfig
In-Reply-To: <13426df10803071741k12feebedr16bfcda0a0a8bc26@mail.gmail.com>
References: <20080306232555.GD15848@greenwood>	<13426df10803061722m2ac3242bl55b0bf0150ba1639@mail.gmail.com>	<47D09C43.3030002@gmx.net>
	<20080307142454.23151.qmail@stuge.se>	<20080307205006.GA7013@greenwood>	<13426df10803071510q46bcbc5eoca4bf96635d66144@mail.gmail.com>	<20080308010921.GA18899@greenwood>
	<13426df10803071741k12feebedr16bfcda0a0a8bc26@mail.gmail.com>
Message-ID: <47D1FB90.1000307@gmx.net>

On 08.03.2008 02:41, ron minnich wrote:
> OK,how about we do something like this:
>
> ram_check(BIOS_DEBUG, 0, 640*1024);
>
> so it is clear to the casual browser that the ram_check happens at
> that debug level? Or condition it on some other cpp symbol?
>
> I'm just very concerned that we not have confusion about this type of
> function and whether it is active.
>   

I'd say have the ram_check with ifdef in mainboard code right now and
once we have k8, rethink the way we do it. Please no dependency on debug
level or similar stuff.

Regards,
Carl-Daniel

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




From c-d.hailfinger.devel.2006 at gmx.net  Sat Mar  8 04:02:31 2008
From: c-d.hailfinger.devel.2006 at gmx.net (Carl-Daniel Hailfinger)
Date: Sat, 08 Mar 2008 04:02:31 +0100
Subject: [coreboot] OLPC A-Test and flash compatibility
Message-ID: <47D201C7.4050507@gmx.net>

Hi,

since the laptop.org lists are mostly software-oriented nowadays and
they dropped support for A-Test boards long ago, I'm going to ask here:
Does anybody know whether I can also flash LPC SST49LF080A in the PLCC32
socket on that board or am I limited to LPC flash? Booting from that
flash chip is not necessary, flashing the chip is my only goal right now.

Regards,
Carl-Daniel

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




From tsylla at gmail.com  Sat Mar  8 04:10:32 2008
From: tsylla at gmail.com (Tom Sylla)
Date: Fri, 07 Mar 2008 22:10:32 -0500
Subject: [coreboot] OLPC A-Test and flash compatibility
In-Reply-To: <47D201C7.4050507@gmx.net>
References: <47D201C7.4050507@gmx.net>
Message-ID: <47D203A8.7050307@gmail.com>

Carl-Daniel Hailfinger wrote:
> Does anybody know whether I can also flash LPC SST49LF080A in the PLCC32
> socket on that board or am I limited to LPC flash? Booting from that
> flash chip is not necessary, flashing the chip is my only goal right now.

In general, that is true for any 5536 platform. Just set PRI_BOOT_LOC 
appropriately in the DIVIL_BALL_OPTS register, and 5536 will generate 
transactions to match.




From c-d.hailfinger.devel.2006 at gmx.net  Sat Mar  8 04:31:23 2008
From: c-d.hailfinger.devel.2006 at gmx.net (Carl-Daniel Hailfinger)
Date: Sat, 08 Mar 2008 04:31:23 +0100
Subject: [coreboot] OLPC A-Test and flash compatibility
In-Reply-To: <47D203A8.7050307@gmail.com>
References: <47D201C7.4050507@gmx.net> <47D203A8.7050307@gmail.com>
Message-ID: <47D2088B.9010907@gmx.net>

On 08.03.2008 04:10, Tom Sylla wrote:
> Carl-Daniel Hailfinger wrote:
>> Does anybody know whether I can also flash LPC SST49LF080A in the PLCC32
>> socket on that board or am I limited to LPC flash? Booting from that
>> flash chip is not necessary, flashing the chip is my only goal right
>> now.
>
> In general, that is true for any 5536 platform. Just set PRI_BOOT_LOC
> appropriately in the DIVIL_BALL_OPTS register, and 5536 will generate
> transactions to match.

Great, thanks!


Regards,
Carl-Daniel

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




From peter at stuge.se  Sat Mar  8 04:47:14 2008
From: peter at stuge.se (Peter Stuge)
Date: Sat, 8 Mar 2008 04:47:14 +0100
Subject: [coreboot] [PATCH] Make RAM check configurable via Kconfig
In-Reply-To: <13426df10803071510q46bcbc5eoca4bf96635d66144@mail.gmail.com>
References: <20080306232555.GD15848@greenwood>
	<13426df10803061722m2ac3242bl55b0bf0150ba1639@mail.gmail.com>
	<47D09C43.3030002@gmx.net> <20080307142454.23151.qmail@stuge.se>
	<20080307205006.GA7013@greenwood>
	<13426df10803071510q46bcbc5eoca4bf96635d66144@mail.gmail.com>
Message-ID: <20080308034714.10689.qmail@stuge.se>

On Fri, Mar 07, 2008 at 03:10:27PM -0800, ron minnich wrote:
> What is wrong with
> #ifdef RAMTEST
> 	ram_check(0, 640 * 1024);
> #endif
> 
> What do people prefer?

This is what I meant that I prefer.


//Peter



From rminnich at gmail.com  Sat Mar  8 05:06:09 2008
From: rminnich at gmail.com (ron minnich)
Date: Fri, 7 Mar 2008 20:06:09 -0800
Subject: [coreboot] OLPC A-Test and flash compatibility
In-Reply-To: <47D2088B.9010907@gmx.net>
References: <47D201C7.4050507@gmx.net> <47D203A8.7050307@gmail.com>
	<47D2088B.9010907@gmx.net>
Message-ID: <13426df10803072006m6cd7d5d9ja6b09eb9b1a29d9e@mail.gmail.com>

I'm going to make a little cluster of my a-test boards. Just cut some
slots in a 2x4 and line them up. Kind of fun.

ron



From rminnich at gmail.com  Sat Mar  8 06:11:24 2008
From: rminnich at gmail.com (ron minnich)
Date: Fri, 7 Mar 2008 21:11:24 -0800
Subject: [coreboot] [PATCH] Make RAM check configurable via Kconfig
In-Reply-To: <20080308034714.10689.qmail@stuge.se>
References: <20080306232555.GD15848@greenwood>
	<13426df10803061722m2ac3242bl55b0bf0150ba1639@mail.gmail.com>
	<47D09C43.3030002@gmx.net> <20080307142454.23151.qmail@stuge.se>
	<20080307205006.GA7013@greenwood>
	<13426df10803071510q46bcbc5eoca4bf96635d66144@mail.gmail.com>
	<20080308034714.10689.qmail@stuge.se>
Message-ID: <13426df10803072111r282c5875n812ff6156f9d6755@mail.gmail.com>

I'm being foolish, forgetting a lesson from Plan 9 style.

This will work fine:
if (RAMTEST) {
    ram_test(0, 640*1024);
    ram_test(whatever);
}

The compiler will optimize out the whole block if RAMTEST is 0.

I think this best.

ron



From kbaski at yahoo.com  Sat Mar  8 17:26:17 2008
From: kbaski at yahoo.com (Baski)
Date: Sat, 8 Mar 2008 08:26:17 -0800 (PST)
Subject: [coreboot] s2881 - IDE path problem in GRUB if SATA is enabled
In-Reply-To: <20080308001150.GA16050@localdomain>
Message-ID: <75260.94892.qm@web51606.mail.re2.yahoo.com>

Hi,
I had originally configured FILO for PCI support in IDE driver.  When SATA was enabled, it moved around the bus/slot.  Now I compiled FILO without PCI support and it works fine now.
Thanks - Baski

Ward Vandewege <ward at gnu.org> wrote: On Fri, Mar 07, 2008 at 02:31:30PM -0800, Baski wrote:
>    My Config - tyan 2881 + FILO payload + ubuntu on IDE-0 + LBv2
> 
>    So far I've been using this setup with onboard SATA disabled.
>    Today I opened the jumper and enabled the SATA.  It stopped at Grub
>    console.  I manually entered the path for the boot drive "root (hd0,0)",
>    but it says something like
>    hda1:/boot/vmlinuz.... 'Drive 0 not present'.
>    The original BIOS boots ok.

Try (hd4,0), and hde1.

Thanks,
Ward.

-- 
Ward Vandewege 
Free Software Foundation - Senior System Administrator


       
---------------------------------
Looking for last minute shopping deals?  Find them fast with Yahoo! Search.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20080308/9db0dce1/attachment.html>

From svn at coreboot.org  Sat Mar  8 20:14:43 2008
From: svn at coreboot.org (svn at coreboot.org)
Date: Sat,  8 Mar 2008 20:14:43 +0100
Subject: [coreboot] r3128 - trunk/coreboot-v2/src/mainboard/asus/a8v-e_se
Message-ID: <mailman.1259.1355071276.16123.coreboot@coreboot.org>

Author: uwe
Date: 2008-03-08 20:14:42 +0100 (Sat, 08 Mar 2008)
New Revision: 3128

Modified:
   trunk/coreboot-v2/src/mainboard/asus/a8v-e_se/Config.lb
   trunk/coreboot-v2/src/mainboard/asus/a8v-e_se/Options.lb
   trunk/coreboot-v2/src/mainboard/asus/a8v-e_se/acpi_tables.c
   trunk/coreboot-v2/src/mainboard/asus/a8v-e_se/cache_as_ram_auto.c
   trunk/coreboot-v2/src/mainboard/asus/a8v-e_se/chip.h
   trunk/coreboot-v2/src/mainboard/asus/a8v-e_se/dsdt.asl
   trunk/coreboot-v2/src/mainboard/asus/a8v-e_se/fadt.c
   trunk/coreboot-v2/src/mainboard/asus/a8v-e_se/mainboard.c
   trunk/coreboot-v2/src/mainboard/asus/a8v-e_se/mptable.c
Log:
Various cosmetic and coding style fixes for ASUS A8V-E SE (trivial).
No functional changes, only cosmetics. This is compile-tested.

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



Modified: trunk/coreboot-v2/src/mainboard/asus/a8v-e_se/Config.lb
===================================================================
--- trunk/coreboot-v2/src/mainboard/asus/a8v-e_se/Config.lb	2008-03-04 17:21:04 UTC (rev 3127)
+++ trunk/coreboot-v2/src/mainboard/asus/a8v-e_se/Config.lb	2008-03-08 19:14:42 UTC (rev 3128)
@@ -2,8 +2,7 @@
 ## This file is part of the coreboot project.
 ## 
 ## Copyright (C) 2007 AMD
-## Written by Yinghai Lu <yinghailu at amd.com> for AMD.
-##
+## (Written by Yinghai Lu <yinghailu at amd.com> for AMD)
 ## Copyright (C) 2007 Rudolf Marek <r.marek at assembler.cz>
 ## 
 ## This program is free software; you can redistribute it and/or modify
@@ -21,260 +20,195 @@
 ## Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA  02110-1301 USA
 ## 
 
-##
-## Compute the location and size of where this firmware image
-## (coreboot plus bootloader) will live in the boot rom chip.
-##
-    if USE_FALLBACK_IMAGE
-	default ROM_SECTION_SIZE   = FALLBACK_SIZE
-	default ROM_SECTION_OFFSET = ( ROM_SIZE - FALLBACK_SIZE )
-    else
-	default ROM_SECTION_SIZE   = ( ROM_SIZE - FALLBACK_SIZE )
-	default ROM_SECTION_OFFSET = 0
-    end
+if USE_FALLBACK_IMAGE
+  default ROM_SECTION_SIZE   = FALLBACK_SIZE
+  default ROM_SECTION_OFFSET = ( ROM_SIZE - FALLBACK_SIZE )
+else
+  default ROM_SECTION_SIZE   = ( ROM_SIZE - FALLBACK_SIZE )
+  default ROM_SECTION_OFFSET = 0
+end
 
-##
-## Compute the start location and size size of
-## The coreboot bootloader.
-##
-default PAYLOAD_SIZE            = ( ROM_SECTION_SIZE - ROM_IMAGE_SIZE )
+default PAYLOAD_SIZE             = ( ROM_SECTION_SIZE - ROM_IMAGE_SIZE )
 default CONFIG_ROM_PAYLOAD_START = (0xffffffff - ROM_SIZE + ROM_SECTION_OFFSET + 1)
-default CONFIG_ROM_PAYLOAD     = 1
+default CONFIG_ROM_PAYLOAD       = 1
+default _ROMBASE     = (CONFIG_ROM_PAYLOAD_START + PAYLOAD_SIZE)
+default XIP_ROM_SIZE = 65536
+default XIP_ROM_BASE = (_ROMBASE + ROM_IMAGE_SIZE - XIP_ROM_SIZE)
 
-##
-## Compute where this copy of coreboot will start in the boot rom
-##
-default _ROMBASE      = ( CONFIG_ROM_PAYLOAD_START + PAYLOAD_SIZE )
-
-##
-## Compute a range of ROM that can cached to speed up coreboot,
-## execution speed.
-##
-## XIP_ROM_SIZE must be a power of 2.
-## XIP_ROM_BASE must be a multiple of XIP_ROM_SIZE
-##
-default XIP_ROM_SIZE=65536
-default XIP_ROM_BASE = ( _ROMBASE + ROM_IMAGE_SIZE - XIP_ROM_SIZE )
-
 arch i386 end 
 
-##
-## Build the objects we have code for in this directory.
-##
-
 driver mainboard.o
-
 if HAVE_ACPI_TABLES
-        object acpi_tables.o
-        object fadt.o
-	makerule dsdt.c
-		depends "$(MAINBOARD)/dsdt.asl"
-		action  "iasl -p $(PWD)/dsdt -tc $(MAINBOARD)/dsdt.asl"
-		action  "mv dsdt.hex dsdt.c"
-	end
-        object ./dsdt.o
+  object acpi_tables.o
+  object fadt.o
+  makerule dsdt.c
+    depends "$(MAINBOARD)/dsdt.asl"
+    action  "iasl -p $(PWD)/dsdt -tc $(MAINBOARD)/dsdt.asl"
+    action  "mv dsdt.hex dsdt.c"
+  end
+  object ./dsdt.o
 end
-
 if HAVE_MP_TABLE object mptable.o end
 if HAVE_PIRQ_TABLE object irq_tables.o end
-#object reset.o
-if USE_DCACHE_RAM
+# object reset.o
 
-	if CONFIG_USE_INIT	
-		makerule ./cache_as_ram_auto.o
-		        depends "$(MAINBOARD)/cache_as_ram_auto.c option_table.h"
-        		action "$(CC) $(DISTRO_CFLAGS) -I$(TOP)/src -I. $(CPPFLAGS) $(MAINBOARD)/cache_as_ram_auto.c -Os -nostdinc -nostdlib -fno-builtin -Wall -c -o $@"
-		end
-	else
-		makerule ./cache_as_ram_auto.inc
-        		depends "$(MAINBOARD)/cache_as_ram_auto.c option_table.h"
-		        action "$(CC) $(DISTRO_CFLAGS) -I$(TOP)/src -I. $(CPPFLAGS) $(MAINBOARD)/cache_as_ram_auto.c -Os -nostdinc -nostdlib -fno-builtin -Wall -c -S -o $@"
-		        action "perl -e 's/.rodata/.rom.data/g' -pi $@"
-        		action "perl -e 's/.text/.section .rom.text/g' -pi $@"
-		end
-	end
-
+if USE_DCACHE_RAM
+  if CONFIG_USE_INIT
+    makerule ./cache_as_ram_auto.o
+      depends "$(MAINBOARD)/cache_as_ram_auto.c option_table.h"
+      action "$(CC) $(DISTRO_CFLAGS) -I$(TOP)/src -I. $(CPPFLAGS) $(MAINBOARD)/cache_as_ram_auto.c -Os -nostdinc -nostdlib -fno-builtin -Wall -c -o $@"
+    end
+  else
+    makerule ./cache_as_ram_auto.inc
+      depends "$(MAINBOARD)/cache_as_ram_auto.c option_table.h"
+      action "$(CC) $(DISTRO_CFLAGS) -I$(TOP)/src -I. $(CPPFLAGS) $(MAINBOARD)/cache_as_ram_auto.c -Os -nostdinc -nostdlib -fno-builtin -Wall -c -S -o $@"
+      action "perl -e 's/.rodata/.rom.data/g' -pi $@"
+      action "perl -e 's/.text/.section .rom.text/g' -pi $@"
+    end
+  end
 end
 
-##
-## Build our 16 bit and 32 bit coreboot entry code
-##
-
 if USE_FALLBACK_IMAGE
-        mainboardinit cpu/x86/16bit/entry16.inc
-        ldscript /cpu/x86/16bit/entry16.lds
-	mainboardinit southbridge/via/k8t890/romstrap.inc
-	ldscript /southbridge/via/k8t890/romstrap.lds
-
+  mainboardinit cpu/x86/16bit/entry16.inc
+  ldscript /cpu/x86/16bit/entry16.lds
+  mainboardinit southbridge/via/k8t890/romstrap.inc
+  ldscript /southbridge/via/k8t890/romstrap.lds
 end
 
 mainboardinit cpu/x86/32bit/entry32.inc
 
 if USE_DCACHE_RAM
-        if CONFIG_USE_INIT
-                ldscript /cpu/x86/32bit/entry32.lds
-        end
-
-        if CONFIG_USE_INIT
-                ldscript /cpu/amd/car/cache_as_ram.lds
-        end
+  if CONFIG_USE_INIT
+    ldscript /cpu/x86/32bit/entry32.lds
+  end
+  if CONFIG_USE_INIT
+    ldscript /cpu/amd/car/cache_as_ram.lds
+  end
 end
 
-
-##
-## Build our reset vector (This is where coreboot is entered)
-##
-
-if USE_FALLBACK_IMAGE 
-	mainboardinit cpu/x86/16bit/reset16.inc 
-	ldscript /cpu/x86/16bit/reset16.lds 
+if USE_FALLBACK_IMAGE
+  mainboardinit cpu/x86/16bit/reset16.inc
+  ldscript /cpu/x86/16bit/reset16.lds
 else
-	mainboardinit cpu/x86/32bit/reset32.inc 
-	ldscript /cpu/x86/32bit/reset32.lds 
+  mainboardinit cpu/x86/32bit/reset32.inc
+  ldscript /cpu/x86/32bit/reset32.lds
 end
 
 if USE_DCACHE_RAM
-	##
-	## Setup Cache-As-Ram
-	##
-	mainboardinit cpu/amd/car/cache_as_ram.inc
+  mainboardinit cpu/amd/car/cache_as_ram.inc
 end
 
-###
-### This is the early phase of coreboot startup 
-### Things are delicate and we test to see if we should
-### failover to another image.
-###
-
 if USE_FALLBACK_IMAGE
-	if USE_DCACHE_RAM
-		ldscript /arch/i386/lib/failover.lds
-	end
+  if USE_DCACHE_RAM
+    ldscript /arch/i386/lib/failover.lds
+  end
 end
 
-
-##
-## Setup RAM
-##
 if USE_DCACHE_RAM
-
-	if CONFIG_USE_INIT
-		initobject cache_as_ram_auto.o
-	else
-		mainboardinit ./cache_as_ram_auto.inc
-	end
+  if CONFIG_USE_INIT
+    initobject cache_as_ram_auto.o
+  else
+    mainboardinit ./cache_as_ram_auto.inc
+  end
 end
 
-##
-## Include the secondary Configuration files 
-##
 if CONFIG_CHIP_NAME
-	config chip.h
+  config chip.h
 end
 
-chip northbridge/amd/amdk8/root_complex
-        device apic_cluster 0 on
-                chip cpu/amd/socket_939
-                        device apic 0 on end
-                end
+chip northbridge/amd/amdk8/root_complex		# Root complex
+  device apic_cluster 0 on			# APIC cluster
+    chip cpu/amd/socket_939			# CPU
+      device apic 0 on end			# APIC
+    end
+  end
+  device pci_domain 0 on			# PCI domain
+    chip northbridge/amd/amdk8			# mc0
+      device pci 18.0 on			# Northbridge
+        # Devices on link 0, link 0 == LDT 0
+        chip southbridge/via/vt8237r		# Southbridge
+          register "ide0_enable" = "1"		# Enable IDE channel 0
+          register "ide1_enable" = "1"		# Enable IDE channel 1
+          register "ide0_80pin_cable" = "1"	# 80pin cable on IDE channel 0
+          register "ide1_80pin_cable" = "1"	# 80pin cable on IDE channel 1
+          register "fn_ctrl_lo" = "0"		# Enable SB functions
+          register "fn_ctrl_hi" = "0xad"	# Enable SB functions
+          device pci 0.0 on end			# HT
+          device pci f.1 on end			# IDE
+          device pci 11.0 on			# LPC
+            chip drivers/generic/generic	# DIMM 0-0-0
+              device i2c 50 on end
+            end
+            chip drivers/generic/generic	# DIMM 0-0-1
+              device i2c 51 on end
+            end
+            chip drivers/generic/generic	# DIMM 0-1-0
+              device i2c 52 on end
+            end
+            chip drivers/generic/generic	# DIMM 0-1-1
+              device i2c 53 on end
+            end
+            chip superio/winbond/w83627ehg	# Super I/O
+              device pnp 2e.0 on		# Floppy
+                io 0x60 = 0x3f0
+                irq 0x70 = 6
+                drq 0x74 = 2
+              end
+              device pnp 2e.1 on		# Parallel port
+                io 0x60 = 0x378
+                irq 0x70 = 7
+                drq 0x74 = 3
+              end
+              device pnp 2e.2 on		# Com1
+                io 0x60 = 0x3f8
+                irq 0x70 = 4
+              end
+              device pnp 2e.3 off		# Com2 (N/A on this board)
+                io 0x60 = 0x2f8
+                irq 0x70 = 3
+              end
+              device pnp 2e.5 off		# PS/2 keyboard (off)
+              end
+              device pnp 2e.106 off		# Serial flash
+                io 0x60 = 0x100
+              end
+              device pnp 2e.007 off		# GPIO 1
+              end
+              device pnp 2e.107 on		# Game port
+                io 0x60 = 0x201
+              end
+              device pnp 2e.207 on		# MIDI
+                io 0x62 = 0x330
+                irq 0x70 = 0xa
+              end
+              device pnp 2e.307 off		# GPIO 6
+              end
+              device pnp 2e.8 off		# WDTO_PLED
+              end
+              device pnp 2e.009 on		# GPIO 2 on LDN 9 is in sio_setup
+              end
+              device pnp 2e.109 off		# GPIO 3
+              end
+              device pnp 2e.209 off		# GPIO 4
+              end
+              device pnp 2e.309 on		# GPIO5
+              end
+              device pnp 2e.a off		# ACPI
+              end
+              device pnp 2e.b on		# Hardware monitor
+                io 0x60 = 0x290
+                irq 0x70 = 0
+              end
+            end
+          end
+          device pci 12.0 off end		# VIA LAN (off, other chip used)
         end
-
-       device pci_domain 0 on
-               chip northbridge/amd/amdk8 #mc0
-                       device pci 18.0 on #  northbridge
-                               #  devices on link 0, link 0 == LDT 0
-                               chip southbridge/via/vt8237r
-					#both IDE channels
-					register "ide0_enable" = "1"
-					register "ide1_enable" = "1"
-					#both cables are 80pin
-					register "ide0_80pin_cable" = "1"
-					register "ide1_80pin_cable" = "1"
-					#enables the functions of SB
-					register "fn_ctrl_lo" = "0"
-					register "fn_ctrl_hi" = "0xad"
-					
-                                       device pci 0.0 on end   # HT
-                                       device pci f.1 on end   # IDE
-                                       device pci 11.0 on # LPC
-                                                chip drivers/generic/generic #dimm 0-0-0
-                                                        device i2c 50 on end  
-                                                end              
-                                                chip drivers/generic/generic #dimm 0-0-1
-                                                        device i2c 51 on end
-                                                end     
-                                                chip drivers/generic/generic #dimm 0-1-0
-                                                        device i2c 52 on end
-                                                end             
-                                                chip drivers/generic/generic #dimm 0-1-1
-                                                        device i2c 53 on end
-                                                end              
-
-                                               chip superio/winbond/w83627ehg
-                                                       device pnp 2e.0 on #  Floppy
-                                                               io 0x60 = 0x3f0
-                                                               irq 0x70 = 6
-                                                               drq 0x74 = 2
-                                                       end
-                                                       device pnp 2e.1 on #  Parallel Port
-                                                               io 0x60 = 0x378
-                                                               irq 0x70 = 7
-                                                               drq 0x74 = 3
-                                                       end
-                                                       device pnp 2e.2 on #  Com1
-                                                               io 0x60 = 0x3f8
-                                                               irq 0x70 = 4
-                                                       end
-                                                       device pnp 2e.3 off #  Com2
-                                                               io 0x60 = 0x2f8
-                                                               irq 0x70 = 3
-                                                       end
-                                                       device pnp 2e.5 off #keyb OFF
-                                                       end
-                                                       device pnp 2e.106 off #  SERIAL_FLASH
-                                                               io 0x60 = 0x100
-                                                       end
-
-                                                       device pnp 2e.007 off #GPIO1 off
-                                                       end
-                                                       device pnp 2e.107 on #GAME on
-                                                               io 0x60 = 0x201
-                                                       end
-                                                       device pnp 2e.207 on #MIDI on
-                                                               io 0x62 = 0x330
-                                                               irq 0x70 = 0xa
-                                                       end
-                                                       device pnp 2e.307 off #GPIO6 off
-                                                       end
-                                                       device pnp 2e.8 off end #  WDTO_PLED
-                                                       device pnp 2e.009 on #GPIO2 on Logical device 9 is in sio_setup
-                                                       end
-                                                       device pnp 2e.109 off #GPIO3 off
-                                                       end
-                                                       device pnp 2e.209 off #GPIO4 off
-                                                       end
-                                                       device pnp 2e.309 on #GPIO5 on
-                                                       end
-                                                       device pnp 2e.a off end #  ACPI
-                                                       device pnp 2e.b on #  HW Monitor
-                                                               io 0x60 = 0x290
-                                                               irq 0x70 = 0
-                                                       end
-                                               end #end SIO
-                                       end #end 11
-
-                                       device pci 12.0 off end # VIA LAN is disabled, Asus used other chip
-                               end
-
-                               chip southbridge/via/k8t890
-				end
-
-                       end #  device pci 18.0
-                       device pci 18.1 on end
-                       device pci 18.2 on end
-                       device pci 18.3 on end
-               end #mc0
-
-       end # pci_domain
-
-end # root_complex
+        chip southbridge/via/k8t890		# "Southbridge" K8T890
+        end
+      end
+      device pci 18.1 on end
+      device pci 18.2 on end
+      device pci 18.3 on end
+    end
+  end
+end

Modified: trunk/coreboot-v2/src/mainboard/asus/a8v-e_se/Options.lb
===================================================================
--- trunk/coreboot-v2/src/mainboard/asus/a8v-e_se/Options.lb	2008-03-04 17:21:04 UTC (rev 3127)
+++ trunk/coreboot-v2/src/mainboard/asus/a8v-e_se/Options.lb	2008-03-08 19:14:42 UTC (rev 3128)
@@ -43,11 +43,9 @@
 uses XIP_ROM_BASE
 uses STACK_SIZE
 uses HEAP_SIZE
-##uses USE_OPTION_TABLE
-##uses CONFIG_LB_MEM_TOPK
-
+# uses USE_OPTION_TABLE
+# uses CONFIG_LB_MEM_TOPK
 uses HAVE_ACPI_TABLES
-
 uses LB_CKS_RANGE_START
 uses LB_CKS_RANGE_END
 uses LB_CKS_LOC
@@ -75,242 +73,96 @@
 uses CONFIG_CHIP_NAME
 uses CONFIG_CONSOLE_VGA
 uses CONFIG_PCI_ROM_RUN
-#bx_b001- uses K8_HW_MEM_HOLE_SIZEK
+# bx_b001- uses K8_HW_MEM_HOLE_SIZEK
 uses K8_HT_FREQ_1G_SUPPORT
-
 uses USE_DCACHE_RAM
 uses DCACHE_RAM_BASE
 uses DCACHE_RAM_SIZE
 uses DCACHE_RAM_GLOBAL_VAR_SIZE
 uses CONFIG_USE_INIT
-
 uses ENABLE_APIC_EXT_ID
 uses APIC_ID_OFFSET
 uses LIFT_BSP_APIC_ID
-
 uses HT_CHAIN_UNITID_BASE
 uses HT_CHAIN_END_UNITID_BASE
-#bx_b001- uses K8_SB_HT_CHAIN_ON_BUS0
+# bx_b001- uses K8_SB_HT_CHAIN_ON_BUS0
 uses SB_HT_CHAIN_UNITID_OFFSET_ONLY
-#bx_b005+
+# bx_b005+
 uses SB_HT_CHAIN_ON_BUS0
-
 uses CONFIG_COMPRESSED_PAYLOAD_NRV2B
 uses CONFIG_COMPRESSED_PAYLOAD_LZMA
 
-## ROM_SIZE is the size of boot ROM that this board will use.
-#512K bytes
-default ROM_SIZE=512 * 1024
+default ROM_SIZE = 512 * 1024
+default FALLBACK_SIZE = 256 * 1024
+default HAVE_FALLBACK_BOOT = 1
+default HAVE_HARD_RESET = 0
+default HAVE_PIRQ_TABLE = 0
+default IRQ_SLOT_COUNT = 11	# FIXME?
+default HAVE_MP_TABLE = 1
+default HAVE_OPTION_TABLE = 0	# FIXME
+# Move the default coreboot CMOS range off of AMD RTC registers.
+default LB_CKS_RANGE_START = 49
+default LB_CKS_RANGE_END = 122
+default LB_CKS_LOC = 123
+default CONFIG_SMP = 1
+default CONFIG_MAX_CPUS = 2
+default CONFIG_MAX_PHYSICAL_CPUS = 1
+default CONFIG_LOGICAL_CPUS = 1
+default HAVE_ACPI_TABLES = 1
+# default CONFIG_CHIP_NAME = 1
 
-#1M bytes
-#bx- default ROM_SIZE=1024 * 1024
+# 1G memory hole
+# bx_b001- default K8_HW_MEM_HOLE_SIZEK = 0x100000
 
-##
-## FALLBACK_SIZE is the amount of the ROM the complete fallback image will use
-##
-#256K
-default FALLBACK_SIZE=256 * 1024
+# Opteron K8 1G HT support
+default K8_HT_FREQ_1G_SUPPORT = 1
 
-###
-### Build options
-###
+# HT Unit ID offset, default is 1, the typical one.
+default HT_CHAIN_UNITID_BASE = 0x0
 
-##
-## Build code for the fallback boot
-##
-default HAVE_FALLBACK_BOOT=1
+# Real SB Unit ID, default is 0x20, mean don't touch it at last.
+# default HT_CHAIN_END_UNITID_BASE = 0x0
 
-##
-## Build code to reset the motherboard from coreboot
-##
-default HAVE_HARD_RESET=0
+# Make the SB HT chain on bus 0, default is not (0).
+# bx_b001- default K8_SB_HT_CHAIN_ON_BUS0 = 2
 
-##
-## Build code to export a programmable irq routing table
-##
-default HAVE_PIRQ_TABLE=0
-default IRQ_SLOT_COUNT=11
+# bx_b005+ make the SB HT chain on bus 0.
+default SB_HT_CHAIN_ON_BUS0 = 1
 
-##
-## Build code to export an x86 MP table
-## Useful for specifying IRQ routing values
-##
-default HAVE_MP_TABLE=1
+# Only offset for SB chain?, default is yes(1).
+default SB_HT_CHAIN_UNITID_OFFSET_ONLY = 0
 
-##
-## Build code to export a CMOS option table
-##
-default HAVE_OPTION_TABLE=0
-
-##
-## Move the default coreboot cmos range off of AMD RTC registers
-##
-default LB_CKS_RANGE_START=49
-default LB_CKS_RANGE_END=122
-default LB_CKS_LOC=123
-
-##
-## Build code for SMP support
-## Only worry about 2 micro processors
-##
-default CONFIG_SMP=1
-default CONFIG_MAX_CPUS=2
-default CONFIG_MAX_PHYSICAL_CPUS=1
-default CONFIG_LOGICAL_CPUS=1
-
-#acpi
-default HAVE_ACPI_TABLES=1
-
-#CHIP_NAME ?
-#default CONFIG_CHIP_NAME=1
-
-#1G memory hole
-#bx_b001- default K8_HW_MEM_HOLE_SIZEK=0x100000
-
-#Opteron K8 1G HT Support
-default K8_HT_FREQ_1G_SUPPORT=1
-
-##HT Unit ID offset, default is 1, the typical one
-default HT_CHAIN_UNITID_BASE=0x0
-
-##real SB Unit ID, default is 0x20, mean dont touch it at last
-#default HT_CHAIN_END_UNITID_BASE=0x0
-
-#make the SB HT chain on bus 0, default is not (0)
-#bx_b001- default K8_SB_HT_CHAIN_ON_BUS0=2
-
-##bx_b005+ make the SB HT chain on bus 0
-default SB_HT_CHAIN_ON_BUS0=1
-
-##only offset for SB chain?, default is yes(1)
-default SB_HT_CHAIN_UNITID_OFFSET_ONLY=0
-
-#VGA
-default CONFIG_CONSOLE_VGA=1
-default CONFIG_PCI_ROM_RUN=1
-
-##
-## enable CACHE_AS_RAM specifics
-##
-default USE_DCACHE_RAM=1
-default DCACHE_RAM_BASE=0xcc000
-default DCACHE_RAM_SIZE=0x4000
-default DCACHE_RAM_GLOBAL_VAR_SIZE=0x01000
-default CONFIG_USE_INIT=0
-
-default ENABLE_APIC_EXT_ID=0
-default APIC_ID_OFFSET=0x10
-default LIFT_BSP_APIC_ID=0
-
-
-##
-## Build code to setup a generic IOAPIC
-##
-default CONFIG_IOAPIC=1
-
-##
-## Clean up the motherboard id strings
-##
-default MAINBOARD_PART_NUMBER="A8V-E SE"
-default MAINBOARD_VENDOR="ASUS"
-default MAINBOARD_PCI_SUBSYSTEM_VENDOR_ID=0x1043
-#default MAINBOARD_PCI_SUBSYSTEM_DEVICE_ID=0x1234
-
-###
-### coreboot layout values
-###
-
-## ROM_IMAGE_SIZE is the amount of space to allow coreboot to occupy.
+default CONFIG_CONSOLE_VGA = 1		# Needed for VGA.
+default CONFIG_PCI_ROM_RUN = 1		# Needed for VGA.
+default USE_DCACHE_RAM = 1
+default DCACHE_RAM_BASE = 0xcc000
+default DCACHE_RAM_SIZE = 0x4000
+default DCACHE_RAM_GLOBAL_VAR_SIZE = 0x01000
+default CONFIG_USE_INIT = 0
+default ENABLE_APIC_EXT_ID = 0
+default APIC_ID_OFFSET = 0x10
+default LIFT_BSP_APIC_ID = 0
+default CONFIG_IOAPIC = 1
+default MAINBOARD_VENDOR = "ASUS"
+default MAINBOARD_PART_NUMBER = "A8V-E SE"
+default MAINBOARD_PCI_SUBSYSTEM_VENDOR_ID = 0x1043
+# default MAINBOARD_PCI_SUBSYSTEM_DEVICE_ID = 0x1234	# FIXME
 default ROM_IMAGE_SIZE = 64 * 1024
-
-##
-## Use a small 8K stack
-##
-default STACK_SIZE= 8 * 1024
-
-##
-## Use a small 256K heap
-##
-default HEAP_SIZE=256 * 1024
-
-#more 1M for pgtbl
-##default CONFIG_LB_MEM_TOPK=2048
-
-##
-## Only use the option table in a normal image
-##
-##default USE_OPTION_TABLE = !USE_FALLBACK_IMAGE
-
-##
-## Coreboot C code runs at this location in RAM
-##
-default _RAMBASE=0x00004000
-
-##
-## Load the payload from the ROM
-##
+default STACK_SIZE = 8 * 1024
+default HEAP_SIZE = 256 * 1024
+# More 1M for pgtbl.
+# default CONFIG_LB_MEM_TOPK = 2048
+default _RAMBASE = 0x00004000
+# default USE_OPTION_TABLE = !USE_FALLBACK_IMAGE
 default CONFIG_ROM_PAYLOAD = 1
-
-###
-### Defaults of options that you may want to override in the target config file
-###
-
-##
-## The default compiler
-##
-default CC="$(CROSS_COMPILE)gcc -m32"
-default HOSTCC="gcc"
-
-##
-## Disable the gdb stub by default
-##
-default CONFIG_GDB_STUB=0
-
-##
-## The Serial Console
-##
-
-# To Enable the Serial Console
-default CONFIG_CONSOLE_SERIAL8250=1
-
-## Select the serial console baud rate
-default TTYS0_BAUD=115200
-#default TTYS0_BAUD=57600
-#default TTYS0_BAUD=38400
-#default TTYS0_BAUD=19200
-#default TTYS0_BAUD=9600
-#default TTYS0_BAUD=4800
-#default TTYS0_BAUD=2400
-#default TTYS0_BAUD=1200
-
-# Select the serial console base port
-default TTYS0_BASE=0x3f8
-
-# Select the serial protocol
-# This defaults to 8 data bits, 1 stop bit, and no parity
-default TTYS0_LCS=0x3
-
-##
-### Select the coreboot loglevel
-##
-## EMERG      1   system is unusable
-## ALERT      2   action must be taken immediately
-## CRIT       3   critical conditions
-## ERR        4   error conditions
-## WARNING    5   warning conditions
-## NOTICE     6   normal but significant condition
-## INFO       7   informational
-## DEBUG      8   debug-level messages
-## SPEW       9   Way too many details
-
-## Request this level of debugging output
-default  DEFAULT_CONSOLE_LOGLEVEL=8
-## At a maximum only compile in this level of debugging
-default  MAXIMUM_CONSOLE_LOGLEVEL=8
-
-##
-## Select power on after power fail setting
-default MAINBOARD_POWER_ON_AFTER_POWER_FAIL="MAINBOARD_POWER_ON"
-
-### End Options.lb
+default CC = "$(CROSS_COMPILE)gcc -m32"
+default HOSTCC = "gcc"
+default CONFIG_GDB_STUB = 0
+default CONFIG_CONSOLE_SERIAL8250 = 1
+default TTYS0_BAUD = 115200
+default TTYS0_BASE = 0x3f8
+default TTYS0_LCS = 0x3		# 8n1
+default DEFAULT_CONSOLE_LOGLEVEL = 8
+default MAXIMUM_CONSOLE_LOGLEVEL = 8
+default MAINBOARD_POWER_ON_AFTER_POWER_FAIL = "MAINBOARD_POWER_ON"
 end

Modified: trunk/coreboot-v2/src/mainboard/asus/a8v-e_se/acpi_tables.c
===================================================================
--- trunk/coreboot-v2/src/mainboard/asus/a8v-e_se/acpi_tables.c	2008-03-04 17:21:04 UTC (rev 3127)
+++ trunk/coreboot-v2/src/mainboard/asus/a8v-e_se/acpi_tables.c	2008-03-08 19:14:42 UTC (rev 3128)
@@ -1,6 +1,7 @@
 /*
  * This file is part of the coreboot project.
- * written by Stefan Reinauer <stepan at openbios.org>
+ *
+ * Written by Stefan Reinauer <stepan at openbios.org>.
  * ACPI FADT, FACS, and DSDT table support added by 
  *
  * Copyright (C) 2004 Stefan Reinauer <stepan at openbios.org>
@@ -27,7 +28,6 @@
 #include <arch/smp/mpspec.h>
 #include <device/device.h>
 #include <device/pci_ids.h>
-
 #include <../../../southbridge/via/vt8237r/vt8237r.h>
 #include <../../../southbridge/via/k8t890/k8t890.h>
 
@@ -37,6 +37,7 @@
 {
 	device_t dev;
 	struct resource *res;
+
 	dev = dev_find_device(PCI_VENDOR_ID_VIA, PCI_DEVICE_ID_VIA_K8T890CE_5, 0);
 	if (!dev)
 		return current;
@@ -53,36 +54,32 @@
 {
 	unsigned int gsi_base = 0x18;
 
-	/* create all subtables for processors */
+	/* Create all subtables for processors. */
 	current = acpi_create_madt_lapics(current);
 
-	/* Write SB IOAPIC */
-	current +=
-	    acpi_create_madt_ioapic((acpi_madt_ioapic_t *) current, VT8237R_APIC_ID,
-				    VT8237R_APIC_BASE, 0);
+	/* Write SB IOAPIC. */
+	current += acpi_create_madt_ioapic((acpi_madt_ioapic_t *) current,
+				VT8237R_APIC_ID, VT8237R_APIC_BASE, 0);
 
-	/* Write NB IOAPIC */
-	current +=
-	    acpi_create_madt_ioapic((acpi_madt_ioapic_t *) current, K8T890_APIC_ID,
-				    K8T890_APIC_BASE, gsi_base);
-	/* IRQ9 ACPI active low */
+	/* Write NB IOAPIC. */
+	current += acpi_create_madt_ioapic((acpi_madt_ioapic_t *) current,
+				K8T890_APIC_ID, K8T890_APIC_BASE, gsi_base);
+
+	/* IRQ9 ACPI active low. */
 	current += acpi_create_madt_irqoverride((acpi_madt_irqoverride_t *)
-						current, 0, 9, 9, MP_IRQ_TRIGGER_LEVEL | MP_IRQ_POLARITY_LOW);
+		current, 0, 9, 9, MP_IRQ_TRIGGER_LEVEL | MP_IRQ_POLARITY_LOW);
 
-	/* IRQ0 -> APIC IRQ2 */
+	/* IRQ0 -> APIC IRQ2. */
 	current += acpi_create_madt_irqoverride((acpi_madt_irqoverride_t *)
 						current, 0, 0, 2, 0x0);	
 
-	/* create all subtables for processors */
-	current =
-	    acpi_create_madt_lapic_nmis(current,
-					MP_IRQ_TRIGGER_EDGE |
-					MP_IRQ_POLARITY_HIGH, 1);
+	/* Create all subtables for processors. */
+	current = acpi_create_madt_lapic_nmis(current,
+			MP_IRQ_TRIGGER_EDGE | MP_IRQ_POLARITY_HIGH, 1);
 
 	return current;
 }
 
-
 unsigned long write_acpi_tables(unsigned long start)
 {
 	unsigned long current;
@@ -96,27 +93,25 @@
 	acpi_facs_t *facs;
 	acpi_header_t *dsdt;
 
-	/* Align ACPI tables to 16byte */
+	/* Align ACPI tables to 16 byte. */
 	start = (start + 0x0f) & -0x10;
 	current = start;
 
 	printk_info("ACPI: Writing ACPI tables at %lx...\n", start);
 
-	/* We need at least an RSDP and an RSDT Table */
+	/* We need at least an RSDP and an RSDT table. */
 	rsdp = (acpi_rsdp_t *) current;
 	current += sizeof(acpi_rsdp_t);
 	rsdt = (acpi_rsdt_t *) current;
 	current += sizeof(acpi_rsdt_t);
 
-	/* clear all table memory */
+	/* Clear all table memory. */
 	memset((void *) start, 0, current - start);
 
 	acpi_write_rsdp(rsdp, rsdt);
 	acpi_write_rsdt(rsdt);
 
-	/*
-	 * We explicitly add these tables later on:
-	 */
+	/* We explicitly add these tables later on: */
 	printk_debug("ACPI:     * FACS\n");
 	facs = (acpi_facs_t *) current;
 	current += sizeof(acpi_facs_t);
@@ -126,7 +121,7 @@
 	current += ((acpi_header_t *) AmlCode)->length;
 	memcpy((void *) dsdt, (void *) AmlCode,
 	       ((acpi_header_t *) AmlCode)->length);
-	dsdt->checksum = 0;	// don't trust intel iasl compiler to get this right
+	dsdt->checksum = 0;	/* Don't trust iasl to get this right. */
 	dsdt->checksum = acpi_checksum(dsdt, dsdt->length);
 	printk_debug("ACPI:     * DSDT @ %08x Length %x\n", dsdt,
 		     dsdt->length);
@@ -144,7 +139,7 @@
 	acpi_create_hpet(hpet);
 	acpi_add_table(rsdt, hpet);
 
-	/* If we want to use HPET Timers Linux wants an MADT */
+	/* If we want to use HPET timers Linux wants an MADT. */
 	printk_debug("ACPI:    * MADT\n");
 	madt = (acpi_madt_t *) current;
 	acpi_create_madt(madt);
@@ -157,7 +152,6 @@
 	current += mcfg->header.length;
 	acpi_add_table(rsdt, mcfg);
 
-	/* SRAT */
 	printk_debug("ACPI:    * SRAT\n");
 	srat = (acpi_srat_t *) current;
 	acpi_create_srat(srat);

Modified: trunk/coreboot-v2/src/mainboard/asus/a8v-e_se/cache_as_ram_auto.c
===================================================================
--- trunk/coreboot-v2/src/mainboard/asus/a8v-e_se/cache_as_ram_auto.c	2008-03-04 17:21:04 UTC (rev 3127)
+++ trunk/coreboot-v2/src/mainboard/asus/a8v-e_se/cache_as_ram_auto.c	2008-03-08 19:14:42 UTC (rev 3128)
@@ -2,10 +2,9 @@
  * This file is part of the coreboot project.
  *
  * Copyright (C) 2006 AMD
- * Written by Yinghai Lu <yinghailu at amd.com> for AMD.
+ * (Written by Yinghai Lu <yinghailu at amd.com> for AMD)
  * Copyright (C) 2006 MSI
- * Written by Bingxun Shi <bingxunshi at gmail.com> for MSI.
- *
+ * (Written by Bingxun Shi <bingxunshi at gmail.com> for MSI)
  * Copyright (C) 2007 Rudolf Marek <r.marek at assembler.cz> 
  *
  * This program is free software; you can redistribute it and/or modify
@@ -32,15 +31,16 @@
 
 unsigned int get_sbdn(unsigned bus);
 
-//used by raminit
+/* Used by raminit. */
 #define QRANK_DIMM_SUPPORT 1
 
-//used by init_cpus and fidvid
+/* Used by init_cpus and fidvid */
 #define K8_SET_FIDVID 1
-//if we want to wait for core1 done before DQS training, set it to 0
+
+/* If we want to wait for core1 done before DQS training, set it to 0. */
 #define K8_SET_FIDVID_CORE0_ONLY 1
 
-//#define DEBUG_SMBUS 1
+/* #define DEBUG_SMBUS 1 */
 
 #include <stdint.h>
 #include <device/pci_def.h>
@@ -50,31 +50,23 @@
 #include <cpu/x86/lapic.h>
 #include "option_table.h"
 #include "pc80/mc146818rtc_early.c"
-
 #include "pc80/serial.c"
 #include "arch/i386/lib/console.c"
-
 #include <cpu/amd/model_fxx_rev.h>
 #include "northbridge/amd/amdk8/raminit.h"
 #include "cpu/amd/model_fxx/apic_timer.c"
 #include "lib/delay.c"
-
 #if CONFIG_USE_INIT == 0
 #include "lib/memcpy.c"
 #endif
-
 #include "cpu/x86/lapic/boot_cpu.c"
 #include "northbridge/amd/amdk8/reset_test.c"
 #include "northbridge/amd/amdk8/debug.c"
 #include "northbridge/amd/amdk8/early_ht.c"
-
-
 #include "superio/winbond/w83627ehg/w83627ehg_early_serial.c"
 #include "southbridge/via/vt8237r/vt8237r_early_smbus.c"
-
 #include "cpu/amd/mtrr/amd_earlymtrr.c"
 #include "cpu/x86/bist.h"
-
 #include "northbridge/amd/amdk8/setup_resource_map.c"
 
 #define SERIAL_DEV PNP_DEV(0x2e, W83627EHG_SP1)
@@ -90,7 +82,6 @@
 {
 }
 
-
 static inline int spd_read_byte(unsigned device, unsigned address)
 {
 	return smbus_read_byte(device, address);
@@ -103,34 +94,27 @@
 #include "northbridge/amd/amdk8/coherent_ht.c"
 #include "northbridge/amd/amdk8/incoherent_ht.c"
 #include "sdram/generic_sdram.c"
-
 #include "cpu/amd/dualcore/dualcore.c"
-
 #include "southbridge/via/k8t890/k8t890_early_car.c"
-
 #include "cpu/amd/car/copy_and_run.c"
-
 #include "cpu/amd/car/post_cache_as_ram.c"
-
 #include "cpu/amd/model_fxx/init_cpus.c"
 #include "cpu/amd/model_fxx/fidvid.c"
-
 #include "northbridge/amd/amdk8/resourcemap.c"
 
-
 void activate_spd_rom(const struct mem_controller *ctrl)
 {
-
 }
 
 void hard_reset(void)
 {
-	print_info("NO HARD RESET  FIX ME!\n");
+	print_info("NO HARD RESET. FIX ME!\n");
 }
 
 void soft_reset(void)
 {
 	uint8_t tmp;
+
 	set_bios_reset();
 	print_debug("soft reset \r\n");
 
@@ -154,26 +138,29 @@
 	return (dev >> 15) & 0x1f;
 }
 
-
-void sio_init(void) {
+void sio_init(void)
+{
 	u8 reg;
 
 	pnp_enter_ext_func_mode(SERIAL_DEV);
+	/* We have 24MHz input. */
 	reg = pnp_read_config(SERIAL_DEV, 0x24);
-	pnp_write_config(SERIAL_DEV, 0x24, (reg & ~0x40));	/* we have 24MHz input */
-
-	reg = pnp_read_config(SERIAL_DEV, 0x2A);
-	pnp_write_config(SERIAL_DEV, 0x2A, (reg | 1));	/* we have GPIO for KB/MS PIN */
-
-	reg = pnp_read_config(SERIAL_DEV, 0x2C);
-	pnp_write_config(SERIAL_DEV, 0x2C, (reg | 0xf0));	/* we have all RESTOUT and even some reserved bits too */
-
+	pnp_write_config(SERIAL_DEV, 0x24, (reg & ~0x40));
+	/* We have GPIO for KB/MS pin. */
+	reg = pnp_read_config(SERIAL_DEV, 0x2a);
+	pnp_write_config(SERIAL_DEV, 0x2a, (reg | 1));
+	/* We have all RESTOUT and even some reserved bits, too. */
+	reg = pnp_read_config(SERIAL_DEV, 0x2c);
+	pnp_write_config(SERIAL_DEV, 0x2c, (reg | 0xf0));
 	pnp_exit_ext_func_mode(SERIAL_DEV);
 
 	pnp_enter_ext_func_mode(ACPI_DEV);
 	pnp_set_logical_device(ACPI_DEV);
+	/*
+	 * Set the delay rising time from PWROK_LP to PWROK_ST to
+	 * 300 - 600ms, and 0 to vice versa.
+	 */
 	reg = pnp_read_config(ACPI_DEV, 0xe6);
-	/* Set the delay rising time from PWROK_LP to PWROK_ST to 300 - 600ms, and 0 to vice versa */ 
 	pnp_write_config(ACPI_DEV, 0xe6, (reg & 0xf0));
 	/* 1 Use external suspend clock source 32.768KHz. Undocumented?? */
 	reg = pnp_read_config(ACPI_DEV, 0xe4);
@@ -182,15 +169,14 @@
 
 	pnp_enter_ext_func_mode(GPIO_DEV);
 	pnp_set_logical_device(GPIO_DEV);
-	
-	/* set memory voltage to 2.75V, vcore offset + 100mV, 1.5V Chipset voltage */
-	pnp_write_config(GPIO_DEV, 0x30, 0x9);	/* Enable GPIO 2 & GPIO 5 */
-	pnp_write_config(GPIO_DEV, 0xe2, 0x0);	/* no inversion */
-	pnp_write_config(GPIO_DEV, 0xe5, 0x0);	/* no inversion */
-	pnp_write_config(GPIO_DEV, 0xe3, 0x3);	/* 0000 0011 0=output 1=input */
-	pnp_write_config(GPIO_DEV, 0xe0, 0xde);	/* 1101110  0=output 1=input */
-	pnp_write_config(GPIO_DEV, 0xe1, 0x1);	/* set output val */
-	pnp_write_config(GPIO_DEV, 0xe4, 0xb4);	/* set output val  1011 0100 */
+	/* Set memory voltage to 2.75V, vcore offset + 100mV, 1.5V chipset voltage. */
+	pnp_write_config(GPIO_DEV, 0x30, 0x09);	/* Enable GPIO 2 & GPIO 5. */
+	pnp_write_config(GPIO_DEV, 0xe2, 0x00);	/* No inversion */
+	pnp_write_config(GPIO_DEV, 0xe5, 0x00);	/* No inversion */
+	pnp_write_config(GPIO_DEV, 0xe3, 0x03);	/* 0000 0011, 0=output 1=input */
+	pnp_write_config(GPIO_DEV, 0xe0, 0xde);	/* 1101 1110, 0=output 1=input */
+	pnp_write_config(GPIO_DEV, 0xe1, 0x01);	/* Set output val. */
+	pnp_write_config(GPIO_DEV, 0xe4, 0xb4);	/* Set output val (1011 0100). */
 	pnp_exit_ext_func_mode(GPIO_DEV);
 }
 
@@ -198,8 +184,8 @@
 
 void failover_process(unsigned long bist, unsigned long cpu_init_detectedx)
 {
-//        unsigned last_boot_normal_x = last_boot_normal();
-//FIXME
+	/* unsigned last_boot_normal_x = last_boot_normal(); */
+	/* FIXME */
 	unsigned last_boot_normal_x = 1;
 
 	sio_init();
@@ -209,56 +195,50 @@
 
 	print_info("now booting... fallback\r\n");
 
-	/* Is this a cpu only reset? or Is this a secondary cpu? */
+	/* Is this a CPU only reset? Or is this a secondary CPU? */
 	if ((cpu_init_detectedx) || (!boot_cpu())) {
-		if (last_boot_normal_x) {
+		if (last_boot_normal_x)
 			goto normal_image;
-		} else {
+		else
 			goto fallback_image;
-		}
 	}
 
-	/* Nothing special needs to be done to find bus 0 */
-	/* Allow the HT devices to be found */
-
+	/* Nothing special needs to be done to find bus 0. */
+	/* Allow the HT devices to be found. */
 	enumerate_ht_chain();
 
-	/* Is this a deliberate reset by the bios */
+	/* Is this a deliberate reset by the BIOS? */
 	if (bios_reset_detected() && last_boot_normal_x) {
 		goto normal_image;
 	}
-	/* This is the primary cpu how should I boot? */
+	/* This is the primary CPU, how should I boot? */
 	else if (do_normal_boot()) {
 		goto normal_image;
 	} else {
 		goto fallback_image;
 	}
-      normal_image:
-	//print_info("JMP normal image\r\n");
 
-	__asm__ volatile ("jmp __normal_image":	/* outputs */
-			  :"a" (bist), "b"(cpu_init_detectedx)	/* inputs */
-	    );
+normal_image:
+	/* print_info("JMP normal image\r\n"); */
 
-      fallback_image:
+	__asm__ __volatile__("jmp __normal_image":
+			     :"a" (bist), "b" (cpu_init_detectedx));
+
+fallback_image:
 	;
 }
 #endif
 
 void real_main(unsigned long bist, unsigned long cpu_init_detectedx);
 
-void cache_as_ram_main(unsigned long bist,
-		       unsigned long cpu_init_detectedx)
+void cache_as_ram_main(unsigned long bist, unsigned long cpu_init_detectedx)
 {
-
 #if USE_FALLBACK_IMAGE == 1
 	failover_process(bist, cpu_init_detectedx);
 #endif
 	real_main(bist, cpu_init_detectedx);
-
 }
 
-
 void real_main(unsigned long bist, unsigned long cpu_init_detectedx)
 {
 	static const uint16_t spd_addr[] = {
@@ -272,8 +252,7 @@
 	unsigned bsp_apicid = 0;
 	int needs_reset = 0;
 	struct sys_info *sysinfo =
-	    (DCACHE_RAM_BASE + DCACHE_RAM_SIZE -
-	     DCACHE_RAM_GLOBAL_VAR_SIZE);
+	    (DCACHE_RAM_BASE + DCACHE_RAM_SIZE - DCACHE_RAM_GLOBAL_VAR_SIZE);
 	char *p;
 
 	sio_init();
@@ -283,23 +262,25 @@
 
 	print_info("now booting... real_main\r\n");
 
-	if (bist == 0) {
+	if (bist == 0)
 		bsp_apicid = init_cpus(cpu_init_detectedx, sysinfo);
-	}
-	/* Halt if there was a built in self test failure */
+
+	/* Halt if there was a built in self test failure. */
 	report_bist_failure(bist);
+
 	setup_default_resource_map();
 	setup_coherent_ht_domain();
 	wait_all_core0_started();
+
 	print_info("now booting... Core0 started\r\n");
 
 #if CONFIG_LOGICAL_CPUS==1
-	// It is said that we should start core1 after all core0 launched
+	/* It is said that we should start core1 after all core0 launched. */
 	start_other_cores();
 	wait_all_other_cores_started(bsp_apicid);
 #endif
 	init_timer();
-	ht_setup_chains_x(sysinfo);	// it will init sblnk and sbbusn, nodes, sbdn
+	ht_setup_chains_x(sysinfo); /* Init sblnk and sbbusn, nodes, sbdn. */
 
 	enable_fid_change();
 	init_fidvid_bsp(bsp_apicid);
@@ -307,20 +288,22 @@
 	needs_reset = optimize_link_coherent_ht();
 	needs_reset |= optimize_link_incoherent_ht(sysinfo);
 
-	/* Fixme it assumes that 1000MHz LDT is selected. */
+	/* FIXME: Assumes that 1000MHz LDT is selected. */
 	needs_reset |= k8t890_early_setup_car(16, 0x6);
 
 	if (needs_reset) {
 		print_debug("ht reset -\r\n");
 		soft_reset();
 	}
-	/* stop the APs so we can start them later in init */
-        allow_all_aps_stop(bsp_apicid);
-	/* It's the time to set ctrl now; */
+
+	/* Stop the APs so we can start them later in init. */
+	allow_all_aps_stop(bsp_apicid);
+
+	/* It's the time to set ctrl now. */
 	fill_mem_ctrl(sysinfo->nodes, sysinfo->ctrl, spd_addr);
+
 	enable_smbus();
 	memreset_setup();
 	sdram_initialize(sysinfo->nodes, sysinfo->ctrl, sysinfo);
 	post_cache_as_ram();
 }
-

Modified: trunk/coreboot-v2/src/mainboard/asus/a8v-e_se/chip.h
===================================================================
--- trunk/coreboot-v2/src/mainboard/asus/a8v-e_se/chip.h	2008-03-04 17:21:04 UTC (rev 3127)
+++ trunk/coreboot-v2/src/mainboard/asus/a8v-e_se/chip.h	2008-03-08 19:14:42 UTC (rev 3128)
@@ -20,5 +20,4 @@
 extern struct chip_operations mainboard_asus_a8v_e_se_ops;
 
 struct mainboard_asus_a8v_e_se_config {
-     
 };

Modified: trunk/coreboot-v2/src/mainboard/asus/a8v-e_se/dsdt.asl
===================================================================
--- trunk/coreboot-v2/src/mainboard/asus/a8v-e_se/dsdt.asl	2008-03-04 17:21:04 UTC (rev 3127)
+++ trunk/coreboot-v2/src/mainboard/asus/a8v-e_se/dsdt.asl	2008-03-08 19:14:42 UTC (rev 3128)
@@ -1,12 +1,11 @@
 /*
  * This file is part of the coreboot project.
  *
- * Minimalist ACPI DSDT table for EPIA-M / MII
  * (C) Copyright 2004 Nick Barker <Nick.Barker9 at btinternet.com>
- *
  * (C) Copyright 2007 Rudolf Marek <r.marek at assembler.cz>
  *
- * ISA portions taken from QEMU acpi-dsdt.dsl  
+ * ISA portions taken from QEMU acpi-dsdt.dsl.
+ *
  * This program is free software; you can redistribute it and/or modify
  * it under the terms of the GNU General Public License v2 as published by
  * the Free Software Foundation.
@@ -21,16 +20,9 @@
  * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA  02110-1301 USA
  */
 
-
 DefinitionBlock ("DSDT.aml", "DSDT", 1, "LXBIOS", "LXB-DSDT", 1)
 {
-
-
-
-
-	/*  
-	 * Define the main processor
-	 */
+	/* Define the main processor.*/
 	Scope (\_PR)
 	{
 		Processor (\_PR.CPU0, 0x00, 0x000000, 0x00) {}
@@ -40,206 +32,178 @@
 	/* For now only define 2 power states:
 	 *  - S0 which is fully on
 	 *  - S5 which is soft off
-	 * any others would involve declaring the wake up methods
+	 * Any others would involve declaring the wake up methods.
 	 */
-	Name (\_S0, Package () {0x00, 0x00, 0x00, 0x00 })
-	Name (\_S5, Package () {0x02, 0x02, 0x00, 0x00 })
+	Name (\_S0, Package () { 0x00, 0x00, 0x00, 0x00 })
+	Name (\_S5, Package () { 0x02, 0x02, 0x00, 0x00 })
 
 	/* Root of the bus hierarchy */
 	Scope (\_SB)
-    	{
-		/* top PCI device */
+	{
+		/* Top PCI device */
 		Device (PCI0)
 		{
 			Name (_HID, EisaId ("PNP0A03"))
 			Name (_ADR, 0x00)
 			Name (_UID, 0x00)
 			Name (_BBN, 0x00)
-			
+
 			/* PCI Routing Table */
-			//aaa
+			/* aaa */
 			Name (_PRT, Package () {
-	                    Package (0x04) { 0x000BFFFF, 0x00, 0x00, 0x10 }, //slot 0xB
-        	            Package (0x04) { 0x000BFFFF, 0x01, 0x00, 0x11 },
-                	    Package (0x04) { 0x000BFFFF, 0x02, 0x00, 0x12 },
-	                    Package (0x04) { 0x000BFFFF, 0x03, 0x00, 0x13 },
-        	            Package (0x04) { 0x000CFFFF, 0x00, 0x00, 0x11 }, //Slot 0xC
-                	    Package (0x04) { 0x000CFFFF, 0x01, 0x00, 0x12 },
-                	    Package (0x04) { 0x000CFFFF, 0x02, 0x00, 0x13 },
-			    Package (0x04) { 0x000CFFFF, 0x03, 0x00, 0x10 },
-        	            Package (0x04) { 0x000DFFFF, 0x00, 0x00, 0x12 }, //Slot 0xD
-                	    Package (0x04) { 0x000DFFFF, 0x01, 0x00, 0x13 },
-                	    Package (0x04) { 0x000DFFFF, 0x02, 0x00, 0x10 },
-			    Package (0x04) { 0x000DFFFF, 0x03, 0x00, 0x11 },
-        	            Package (0x04) { 0x000F0000, 0x01, 0x00, 0x14 }, //0xf SATA IRQ 20
-                	    Package (0x04) { 0x000F0001, 0x00, 0x00, 0x14 }, //0xf NAtive IDE IRQ 20
-        	            Package (0x04) { 0x0010FFFF, 0x00, 0x00, 0x15 }, //USB routing
-                	    Package (0x04) { 0x0010FFFF, 0x01, 0x00, 0x15 },
-                	    Package (0x04) { 0x0010FFFF, 0x02, 0x00, 0x15 },
-			    Package (0x04) { 0x0010FFFF, 0x03, 0x00, 0x15 },
-			    Package (0x04) { 0x0011FFFF, 0x02, 0x00, 0x16 }, //AC97 MC97
-        	            Package (0x04) { 0x0002FFFF, 0x00, 0x00, 0x1B }, //PCIE16 bridge IRQ27
-                	    Package (0x04) { 0x0002FFFF, 0x01, 0x00, 0x1B },
-                	    Package (0x04) { 0x0002FFFF, 0x02, 0x00, 0x1B },
-			    Package (0x04) { 0x0002FFFF, 0x03, 0x00, 0x1B },
-        	            Package (0x04) { 0x0003FFFF, 0x00, 0x00, 0x1F }, //PCIE bridge IRQ31
-                	    Package (0x04) { 0x0003FFFF, 0x01, 0x00, 0x23 }, //IRQ36
-                	    Package (0x04) { 0x0003FFFF, 0x02, 0x00, 0x27 }, //IRQ39
-			    Package (0x04) { 0x0003FFFF, 0x03, 0x00, 0x2B } //IRQ43
-            		})
+				Package (0x04) { 0x000BFFFF, 0x00, 0x00, 0x10 }, /* Slot 0xB */
+				Package (0x04) { 0x000BFFFF, 0x01, 0x00, 0x11 },
+				Package (0x04) { 0x000BFFFF, 0x02, 0x00, 0x12 },
+				Package (0x04) { 0x000BFFFF, 0x03, 0x00, 0x13 },
+				Package (0x04) { 0x000CFFFF, 0x00, 0x00, 0x11 }, /* Slot 0xC */
+				Package (0x04) { 0x000CFFFF, 0x01, 0x00, 0x12 },
+				Package (0x04) { 0x000CFFFF, 0x02, 0x00, 0x13 },
+				Package (0x04) { 0x000CFFFF, 0x03, 0x00, 0x10 },
+				Package (0x04) { 0x000DFFFF, 0x00, 0x00, 0x12 }, /* Slot 0xD */
+				Package (0x04) { 0x000DFFFF, 0x01, 0x00, 0x13 },
+				Package (0x04) { 0x000DFFFF, 0x02, 0x00, 0x10 },
+				Package (0x04) { 0x000DFFFF, 0x03, 0x00, 0x11 },
+				Package (0x04) { 0x000F0000, 0x01, 0x00, 0x14 }, /* 0xf SATA IRQ 20 */
+				Package (0x04) { 0x000F0001, 0x00, 0x00, 0x14 }, /* 0xf Native IDE IRQ 20 */
+				Package (0x04) { 0x0010FFFF, 0x00, 0x00, 0x15 }, /* USB routing */
+				Package (0x04) { 0x0010FFFF, 0x01, 0x00, 0x15 },
+				Package (0x04) { 0x0010FFFF, 0x02, 0x00, 0x15 },
+				Package (0x04) { 0x0010FFFF, 0x03, 0x00, 0x15 },
+				Package (0x04) { 0x0011FFFF, 0x02, 0x00, 0x16 }, /* AC97, MC97 */
+				Package (0x04) { 0x0002FFFF, 0x00, 0x00, 0x1B }, /* PCIE16 bridge IRQ27 */
+				Package (0x04) { 0x0002FFFF, 0x01, 0x00, 0x1B },
+				Package (0x04) { 0x0002FFFF, 0x02, 0x00, 0x1B },
+				Package (0x04) { 0x0002FFFF, 0x03, 0x00, 0x1B },
+				Package (0x04) { 0x0003FFFF, 0x00, 0x00, 0x1F }, /* PCIE bridge IRQ31 */
+				Package (0x04) { 0x0003FFFF, 0x01, 0x00, 0x23 }, /* IRQ36 */
+				Package (0x04) { 0x0003FFFF, 0x02, 0x00, 0x27 }, /* IRQ39 */
+				Package (0x04) { 0x0003FFFF, 0x03, 0x00, 0x2B }  /* IRQ43 */
+			})
 
-		
-		Device (PEGG)
-		{
-			Name (_ADR, 0x00020000)
-			Name (_UID, 0x00)
-			Name (_BBN, 0x02)
-			
-			Name (_PRT, Package () {
-	                    Package (0x04) { 0x0000FFFF, 0x00, 0x00, 0x18 }, //PCIE IRQ24-IRQ27
-        	            Package (0x04) { 0x0000FFFF, 0x01, 0x00, 0x19 },
-                	    Package (0x04) { 0x0000FFFF, 0x02, 0x00, 0x1A },
-	                    Package (0x04) { 0x0000FFFF, 0x03, 0x00, 0x1B },
-			})	
-		} //end of PCIEG
+			Device (PEGG)
+			{
+				Name (_ADR, 0x00020000)
+				Name (_UID, 0x00)
+				Name (_BBN, 0x02)
+				Name (_PRT, Package () {
+					Package (0x04) { 0x0000FFFF, 0x00, 0x00, 0x18 }, /* PCIE IRQ24-IRQ27 */
+					Package (0x04) { 0x0000FFFF, 0x01, 0x00, 0x19 },
+					Package (0x04) { 0x0000FFFF, 0x02, 0x00, 0x1A },
+					Package (0x04) { 0x0000FFFF, 0x03, 0x00, 0x1B },
+				})
+			}
 
-		Device (PEX0)
-		{
-			Name (_ADR, 0x00030000)
-			Name (_UID, 0x00)
-			Name (_BBN, 0x03)
-			
-			Name (_PRT, Package () {
-	                    Package (0x04) { 0x0000FFFF, 0x00, 0x00, 0x1C }, //PCIE IRQ28-IRQ31
-        	            Package (0x04) { 0x0000FFFF, 0x01, 0x00, 0x1D },
-                	    Package (0x04) { 0x0000FFFF, 0x02, 0x00, 0x1E },
-	                    Package (0x04) { 0x0000FFFF, 0x03, 0x00, 0x1F },
-			})	
-		} //end of PEX0
+			Device (PEX0)
+			{
+				Name (_ADR, 0x00030000)
+				Name (_UID, 0x00)
+				Name (_BBN, 0x03)
+				Name (_PRT, Package () {
+					Package (0x04) { 0x0000FFFF, 0x00, 0x00, 0x1C }, /* PCIE IRQ28-IRQ31 */
+					Package (0x04) { 0x0000FFFF, 0x01, 0x00, 0x1D },
+					Package (0x04) { 0x0000FFFF, 0x02, 0x00, 0x1E },
+					Package (0x04) { 0x0000FFFF, 0x03, 0x00, 0x1F },
+				})
+			}
 
-		Device (PEX1)
-		{
-			Name (_ADR, 0x00030001)
-			Name (_UID, 0x00)
-			Name (_BBN, 0x04)
-			
-			Name (_PRT, Package () {
-	                    Package (0x04) { 0x0000FFFF, 0x00, 0x00, 0x20 }, //PCIE IRQ32-IRQ35
-        	            Package (0x04) { 0x0000FFFF, 0x01, 0x00, 0x21 },
-                	    Package (0x04) { 0x0000FFFF, 0x02, 0x00, 0x22 },
-	                    Package (0x04) { 0x0000FFFF, 0x03, 0x00, 0x23 },
-			})	
-		} //end f PEX1
+			Device (PEX1)
+			{
+				Name (_ADR, 0x00030001)
+				Name (_UID, 0x00)
+				Name (_BBN, 0x04)
+				Name (_PRT, Package () {
+					Package (0x04) { 0x0000FFFF, 0x00, 0x00, 0x20 }, /* PCIE IRQ32-IRQ35 */
+					Package (0x04) { 0x0000FFFF, 0x01, 0x00, 0x21 },
+					Package (0x04) { 0x0000FFFF, 0x02, 0x00, 0x22 },
+					Package (0x04) { 0x0000FFFF, 0x03, 0x00, 0x23 },
+				})
+			}
 
-		Device (PEX2)
-		{
-			Name (_ADR, 0x00030002)
-			Name (_UID, 0x00)
-			Name (_BBN, 0x05)
-			
-			Name (_PRT, Package () {
-	                    Package (0x04) { 0x0000FFFF, 0x00, 0x00, 0x24 }, //PCIE IRQ36-IRQ39
-        	            Package (0x04) { 0x0000FFFF, 0x01, 0x00, 0x25 },
-                	    Package (0x04) { 0x0000FFFF, 0x02, 0x00, 0x26 },
-	                    Package (0x04) { 0x0000FFFF, 0x03, 0x00, 0x27 },
-			})	
-		} //end f PEX2
+			Device (PEX2)
+			{
+				Name (_ADR, 0x00030002)
+				Name (_UID, 0x00)
+				Name (_BBN, 0x05)
+				Name (_PRT, Package () {
+					Package (0x04) { 0x0000FFFF, 0x00, 0x00, 0x24 }, /* PCIE IRQ36-IRQ39 */
+					Package (0x04) { 0x0000FFFF, 0x01, 0x00, 0x25 },
+					Package (0x04) { 0x0000FFFF, 0x02, 0x00, 0x26 },
+					Package (0x04) { 0x0000FFFF, 0x03, 0x00, 0x27 },
+				})
+			}
 
-		Device (PEX3)
-		{
-			Name (_ADR, 0x00030003)
-			Name (_UID, 0x00)
-			Name (_BBN, 0x06)
-			
-			Name (_PRT, Package () {
-	                    Package (0x04) { 0x0000FFFF, 0x00, 0x00, 0x28 }, //PCIE IRQ40-IRQ43
-        	            Package (0x04) { 0x0000FFFF, 0x01, 0x00, 0x29 },
-                	    Package (0x04) { 0x0000FFFF, 0x02, 0x00, 0x2A },
-	                    Package (0x04) { 0x0000FFFF, 0x03, 0x00, 0x2B },
-			})	
-		} //end f PEX3
+			Device (PEX3)
+			{
+				Name (_ADR, 0x00030003)
+				Name (_UID, 0x00)
+				Name (_BBN, 0x06)
+				Name (_PRT, Package () {
+					Package (0x04) { 0x0000FFFF, 0x00, 0x00, 0x28 }, /* PCIE IRQ40-IRQ43 */
+					Package (0x04) { 0x0000FFFF, 0x01, 0x00, 0x29 },
+					Package (0x04) { 0x0000FFFF, 0x02, 0x00, 0x2A },
+					Package (0x04) { 0x0000FFFF, 0x03, 0x00, 0x2B },
+				})
+			}
 
-        Device (ISA) {
-            Name (_ADR, 0x00110000)
-        
-            /* Keyboard seems to be important for WinXP install */
-            Device (KBD)
-            {
-                Name (_HID, EisaId ("PNP0303"))
-                Method (_STA, 0, NotSerialized)
-                {
-                    Return (0x0f)
-                }
+			Device (ISA) {
+				Name (_ADR, 0x00110000)
 
-                Method (_CRS, 0, NotSerialized)
-                {
-                     Name (TMP, ResourceTemplate ()
-                     {
-                    IO (Decode16,
-                        0x0060,             // Address Range Minimum
-                        0x0060,             // Address Range Maximum
-                        0x01,               // Address Alignment
-                        0x01,               // Address Length
-                        )
-                    IO (Decode16,
-                        0x0064,             // Address Range Minimum
-                        0x0064,             // Address Range Maximum
-                        0x01,               // Address Alignment
-                        0x01,               // Address Length
-                        )
-                    IRQNoFlags ()
-                        {1}
-                    })
-                    Return (TMP)
-                }
-            }
+				/* PS/2 keyboard (seems to be important for WinXP install) */
+				Device (KBD)
+				{
+					Name (_HID, EisaId ("PNP0303"))
+					Method (_STA, 0, NotSerialized)
+					{
+						Return (0x0f)
+					}
+					Method (_CRS, 0, NotSerialized)
+					{
+						Name (TMP, ResourceTemplate () {
+							IO (Decode16, 0x0060, 0x0060, 0x01, 0x01)
+							IO (Decode16, 0x0064, 0x0064, 0x01, 0x01)
+							IRQNoFlags () {1}
+						})
+						Return (TMP)
+					}
+				}
 
-	    /* PS/2 mouse */
-            Device (MOU) 
-            {
-                Name (_HID, EisaId ("PNP0F13"))
-                Method (_STA, 0, NotSerialized)
-                {
-                    Return (0x0f)
-                }
+				/* PS/2 mouse */
+				Device (MOU)
+				{
+					Name (_HID, EisaId ("PNP0F13"))
+					Method (_STA, 0, NotSerialized)
+					{
+						Return (0x0f)
+					}
+					Method (_CRS, 0, NotSerialized)
+					{
+						Name (TMP, ResourceTemplate () {
+						     IRQNoFlags () {12}
+						})
+						Return (TMP)
+					}
+				}
 
-                Method (_CRS, 0, NotSerialized)
-                {
-                    Name (TMP, ResourceTemplate ()
-                    {
-                         IRQNoFlags () {12}
-                    })
-                    Return (TMP)
-                }
-            }
-
-	    /* PS/2 floppy controller */
-	    Device (FDC0)
-	    {
-	        Name (_HID, EisaId ("PNP0700"))
-		Method (_STA, 0, NotSerialized)
-		{
-		    Return (0x0F)
+				/* PS/2 floppy controller */
+				Device (FDC0)
+				{
+					Name (_HID, EisaId ("PNP0700"))
+					Method (_STA, 0, NotSerialized)
+					{
+						Return (0x0f)
+					}
+					Method (_CRS, 0, NotSerialized)
+					{
+						Name (BUF0, ResourceTemplate () {
+							IO (Decode16, 0x03F2, 0x03F2, 0x00, 0x04)
+							IO (Decode16, 0x03F7, 0x03F7, 0x00, 0x01)
+							IRQNoFlags () {6}
+							DMA (Compatibility, NotBusMaster, Transfer8) {2}
+						})
+						Return (BUF0)
+					}
+				}
+			}
 		}
-		Method (_CRS, 0, NotSerialized)
-		{
-		    Name (BUF0, ResourceTemplate ()
-                    {
-                        IO (Decode16, 0x03F2, 0x03F2, 0x00, 0x04)
-                        IO (Decode16, 0x03F7, 0x03F7, 0x00, 0x01)
-                        IRQNoFlags () {6}
-                        DMA (Compatibility, NotBusMaster, Transfer8) {2}
-                    })
-		    Return (BUF0)
-		}
-	    } //FD END
-
-        } //ISA END
-
-	} // End of PCI0
-		
-		
-	} // End of _SB
-
-} // End of Definition Block
-
+	}
+}

Modified: trunk/coreboot-v2/src/mainboard/asus/a8v-e_se/fadt.c
===================================================================
--- trunk/coreboot-v2/src/mainboard/asus/a8v-e_se/fadt.c	2008-03-04 17:21:04 UTC (rev 3127)
+++ trunk/coreboot-v2/src/mainboard/asus/a8v-e_se/fadt.c	2008-03-08 19:14:42 UTC (rev 3128)
@@ -1,8 +1,9 @@
 /*
- * ACPI - create the Fixed ACPI Description Tables (FADT)
- * (C) Copyright 2004 Nick Barker <nick.barker9 at btinternet.com>
- * (C) Copyright 2007 Rudolf Marek <r.marek at assembler.cz>
+ * This file is part of the coreboot project.
  *
+ * Copyright (C) 2004 Nick Barker <nick.barker9 at btinternet.com>
+ * Copyright (C) 2007 Rudolf Marek <r.marek at assembler.cz>
+ *
  * 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
@@ -15,15 +16,17 @@
  *
  * 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
+ * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA  02110-1301 USA
  */
 
 #include <string.h>
 #include <arch/acpi.h>
 #include <../../../southbridge/via/vt8237r/vt8237r.h>
 
-void acpi_create_fadt(acpi_fadt_t * fadt, acpi_facs_t * facs, void *dsdt)
+/**
+ * Create the Fixed ACPI Description Tables (FADT) for this board.
+ */
+void acpi_create_fadt(acpi_fadt_t *fadt, acpi_facs_t *facs, void *dsdt)
 {
 	acpi_header_t *header = &(fadt->header);
 
@@ -146,6 +149,5 @@
 	fadt->x_gpe1_blk.addrl = 0x0;
 	fadt->x_gpe1_blk.addrh = 0x0;
 
-	header->checksum =
-	    acpi_checksum((void *) fadt, sizeof(acpi_fadt_t));
+	header->checksum = acpi_checksum((void *) fadt, sizeof(acpi_fadt_t));
 }

Modified: trunk/coreboot-v2/src/mainboard/asus/a8v-e_se/mainboard.c
===================================================================
--- trunk/coreboot-v2/src/mainboard/asus/a8v-e_se/mainboard.c	2008-03-04 17:21:04 UTC (rev 3127)
+++ trunk/coreboot-v2/src/mainboard/asus/a8v-e_se/mainboard.c	2008-03-08 19:14:42 UTC (rev 3128)
@@ -21,7 +21,6 @@
 #include <device/device.h>
 #include <device/pci.h>
 #include <device/pci_ids.h>
-#include <device/pci_ops.h>
 #include "chip.h"
 
 #if CONFIG_CHIP_NAME == 1

Modified: trunk/coreboot-v2/src/mainboard/asus/a8v-e_se/mptable.c
===================================================================
--- trunk/coreboot-v2/src/mainboard/asus/a8v-e_se/mptable.c	2008-03-04 17:21:04 UTC (rev 3127)
+++ trunk/coreboot-v2/src/mainboard/asus/a8v-e_se/mptable.c	2008-03-08 19:14:42 UTC (rev 3128)
@@ -17,43 +17,42 @@
  * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA  02110-1301 USA
  */
 
-#include <arch/smp/mpspec.h>
 #include <string.h>
 #include <stdint.h>
-
+#include <arch/smp/mpspec.h>
 #include <../../../southbridge/via/vt8237r/vt8237r.h>
 #include <../../../southbridge/via/k8t890/k8t890.h>
 
 void *smp_write_config_table(void *v)
 {
-        static const char sig[4] = "PCMP";
-        static const char oem[8] = "LNXB    ";
-        static const char productid[12] = "A8V-E SE    ";
-        struct mp_config_table *mc;
+	static const char sig[4] = "PCMP";
+	static const char oem[8] = "LNXB    ";
+	static const char productid[12] = "A8V-E SE    ";
+	struct mp_config_table *mc;
 	unsigned int conforms = 0;
 	int bus_isa = 42;
 
-        mc = (void *)(((char *)v) + SMP_FLOATING_TABLE_LEN);
-        memset(mc, 0, sizeof(*mc));
+	mc = (void *)(((char *)v) + SMP_FLOATING_TABLE_LEN);
+	memset(mc, 0, sizeof(*mc));
 
-        memcpy(mc->mpc_signature, sig, sizeof(sig));
-        mc->mpc_length = sizeof(*mc); /* initially just the header */
-        mc->mpc_spec = 0x04;
-        mc->mpc_checksum = 0; /* not yet computed */
-        memcpy(mc->mpc_oem, oem, sizeof(oem));
-        memcpy(mc->mpc_productid, productid, sizeof(productid));
-        mc->mpc_oemptr = 0;
-        mc->mpc_oemsize = 0;
-        mc->mpc_entry_count = 0; /* No entries yet... */
-        mc->mpc_lapic = LAPIC_ADDR;
-        mc->mpe_length = 0;
-        mc->mpe_checksum = 0;
-        mc->reserved = 0;
+	memcpy(mc->mpc_signature, sig, sizeof(sig));
+	mc->mpc_length = sizeof(*mc); /* Initially just the header. */
+	mc->mpc_spec = 0x04;
+	mc->mpc_checksum = 0; /* Not yet computed. */
+	memcpy(mc->mpc_oem, oem, sizeof(oem));
+	memcpy(mc->mpc_productid, productid, sizeof(productid));
+	mc->mpc_oemptr = 0;
+	mc->mpc_oemsize = 0;
+	mc->mpc_entry_count = 0; /* No entries yet. */
+	mc->mpc_lapic = LAPIC_ADDR;
+	mc->mpe_length = 0;
+	mc->mpe_checksum = 0;
+	mc->reserved = 0;
 
-        smp_write_processors(mc);
+	smp_write_processors(mc);
 
 
-/*Bus:		Bus ID	Type*/
+	/* Bus:		Bus ID	Type */
 	smp_write_bus(mc, 0, "PCI   ");
 	smp_write_bus(mc, 1, "PCI   ");
 	smp_write_bus(mc, 2, "PCI   ");
@@ -62,12 +61,11 @@
 	smp_write_bus(mc, 5, "PCI   ");
 	smp_write_bus(mc, 6, "PCI   ");
 	smp_write_bus(mc, bus_isa, "ISA   ");
-/*I/O APICs:	APIC ID	Version	State		Address*/
 
+	/* I/O APICs:	APIC ID	Version	State		Address */
 	smp_write_ioapic(mc, VT8237R_APIC_ID, 0x20, VT8237R_APIC_BASE);
 	smp_write_ioapic(mc, K8T890_APIC_ID, 0x20, K8T890_APIC_BASE);
 
-
 	smp_write_intsrc(mc, mp_ExtINT, MP_IRQ_TRIGGER_EDGE|MP_IRQ_POLARITY_HIGH, bus_isa, 0x0, VT8237R_APIC_ID, 0x0);
 	smp_write_intsrc(mc, mp_INT, MP_IRQ_TRIGGER_EDGE|MP_IRQ_POLARITY_HIGH, bus_isa, 0x1, VT8237R_APIC_ID, 0x1);
 	smp_write_intsrc(mc, mp_INT, MP_IRQ_TRIGGER_EDGE|MP_IRQ_POLARITY_HIGH, bus_isa, 0x0, VT8237R_APIC_ID, 0x2);
@@ -142,14 +140,16 @@
 	smp_write_intsrc(mc, mp_INT, MP_IRQ_TRIGGER_LEVEL|MP_IRQ_POLARITY_LOW, 0x6,  (0x00 << 2) | 2, K8T890_APIC_ID, 0x12);
 	smp_write_intsrc(mc, mp_INT, MP_IRQ_TRIGGER_LEVEL|MP_IRQ_POLARITY_LOW, 0x6,  (0x00 << 2) | 3, K8T890_APIC_ID, 0x13);
 
-/*Local Ints:	Type	Polarity    Trigger	Bus ID	 IRQ	APIC ID	PIN#*/
-	smp_write_intsrc(mc, mp_ExtINT, MP_IRQ_TRIGGER_EDGE|MP_IRQ_POLARITY_HIGH, bus_isa, 0x0, MP_APIC_ALL, 0x0);
-	smp_write_intsrc(mc, mp_NMI, MP_IRQ_TRIGGER_EDGE|MP_IRQ_POLARITY_HIGH, bus_isa, 0x0, MP_APIC_ALL, 0x1);
+	/* Local Ints:	Type	Polarity    Trigger	Bus ID	 IRQ	APIC ID	PIN# */
+	smp_write_intsrc(mc, mp_ExtINT,	MP_IRQ_TRIGGER_EDGE|MP_IRQ_POLARITY_HIGH, bus_isa, 0x0, MP_APIC_ALL, 0x0);
+	smp_write_intsrc(mc, mp_NMI,	MP_IRQ_TRIGGER_EDGE|MP_IRQ_POLARITY_HIGH, bus_isa, 0x0, MP_APIC_ALL, 0x1);
 	/* There is no extension information... */
 
-	/* Compute the checksums */
-	mc->mpe_checksum = smp_compute_checksum(smp_next_mpc_entry(mc), mc->mpe_length);
+	/* Compute the checksums. */
+	mc->mpe_checksum = smp_compute_checksum(smp_next_mpc_entry(mc),
+						mc->mpe_length);
 	mc->mpc_checksum = smp_compute_checksum(mc, mc->mpc_length);
+
 	return smp_next_mpe_entry(mc);
 }
 




From uwe at hermann-uwe.de  Sat Mar  8 20:39:16 2008
From: uwe at hermann-uwe.de (Uwe Hermann)
Date: Sat, 8 Mar 2008 20:39:16 +0100
Subject: [coreboot] [PATCH] Make RAM check configurable via Kconfig
In-Reply-To: <13426df10803072111r282c5875n812ff6156f9d6755@mail.gmail.com>
References: <20080306232555.GD15848@greenwood>
	<13426df10803061722m2ac3242bl55b0bf0150ba1639@mail.gmail.com>
	<47D09C43.3030002@gmx.net> <20080307142454.23151.qmail@stuge.se>
	<20080307205006.GA7013@greenwood>
	<13426df10803071510q46bcbc5eoca4bf96635d66144@mail.gmail.com>
	<20080308034714.10689.qmail@stuge.se>
	<13426df10803072111r282c5875n812ff6156f9d6755@mail.gmail.com>
Message-ID: <20080308193915.GA25815@greenwood>

On Fri, Mar 07, 2008 at 09:11:24PM -0800, ron minnich wrote:
> I'm being foolish, forgetting a lesson from Plan 9 style.
> 
> This will work fine:
> if (RAMTEST) {
>     ram_test(0, 640*1024);
>     ram_test(whatever);
> }
> 
> The compiler will optimize out the whole block if RAMTEST is 0.

Nice trick, but it won't work in this case. Kconfig variables are
#defined to 1 if they're selected in menuconfig, but they're not
defined at all otherwise.

So 'if (CONFIG_RAMTEST)' will not compile if you don't select it via
Kconfig.

I still prefer the version in my patch because it makes the majority of
the code look clean and short (no #ifdefs). We could add a '_maybe'
prefix/suffix to function names which are conditionally compiled like
that (I think some Linux code does that).

E.g. ram_check_maybe(0, 640 * 1024), which should make it clear to
readers that the function may or may not have any effect depending
on kconfig variables.


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



From rminnich at gmail.com  Sat Mar  8 20:44:21 2008
From: rminnich at gmail.com (ron minnich)
Date: Sat, 8 Mar 2008 11:44:21 -0800
Subject: [coreboot] [PATCH] Make RAM check configurable via Kconfig
In-Reply-To: <20080308193915.GA25815@greenwood>
References: <20080306232555.GD15848@greenwood>
	<13426df10803061722m2ac3242bl55b0bf0150ba1639@mail.gmail.com>
	<47D09C43.3030002@gmx.net> <20080307142454.23151.qmail@stuge.se>
	<20080307205006.GA7013@greenwood>
	<13426df10803071510q46bcbc5eoca4bf96635d66144@mail.gmail.com>
	<20080308034714.10689.qmail@stuge.se>
	<13426df10803072111r282c5875n812ff6156f9d6755@mail.gmail.com>
	<20080308193915.GA25815@greenwood>
Message-ID: <13426df10803081144l2537d245we03a3625ef52b4d4@mail.gmail.com>

On Sat, Mar 8, 2008 at 11:39 AM, Uwe Hermann <uwe at hermann-uwe.de> wrote:

>  Nice trick, but it won't work in this case. Kconfig variables are
>  #defined to 1 if they're selected in menuconfig, but they're not
>  defined at all otherwise.

Which, now that I think of it, is probably why they always have a
defined value in linux and are not just undefined. By going with
variables that are undefined or not, we lose some nice ways to write
clear code and get optimization.

>  I still prefer the version in my patch because it makes the majority of
>  the code look clean and short (no #ifdefs). We could add a '_maybe'
>  prefix/suffix to function names which are conditionally compiled like
>  that (I think some Linux code does that).

I still have concerns that it will confuse people. At first glance it
looks like we're going to test ram. Oh, we're not, because of this
config variable? It's just not clear to me.

But it may be I am just out of sync :-)

ron



From info at coresystems.de  Sat Mar  8 21:01:22 2008
From: info at coresystems.de (coreboot information)
Date: Sat, 08 Mar 2008 21:01:22 +0100
Subject: [coreboot] r3128 build service
Message-ID: <E1JY5EQ-00033Q-25@khepri.openbios.org>

Dear coreboot readers!

This is the automated build check service of coreboot.

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

Change Log:
Various cosmetic and coding style fixes for ASUS A8V-E SE (trivial).
No functional changes, only cosmetics. This is compile-tested.

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



Build Log:
Compilation of amd:serengeti_cheetah_fam10 is still broken
See the error log at http://qa.coreboot.org/log_buildbrd.php?revision=3128&device=serengeti_cheetah_fam10&vendor=amd


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

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

   Best regards,
     coreboot automatic build system





From joe at smittys.pointclark.net  Sun Mar  9 05:17:24 2008
From: joe at smittys.pointclark.net (joe at smittys.pointclark.net)
Date: Sat, 08 Mar 2008 23:17:24 -0500
Subject: [coreboot] v2[PATCH]RCA RM4100 i82830 support
In-Reply-To: <dd3c80060803042230y56ba10dcif065d722350dbc36@mail.gmail.com>
References: <20080225122041.1b4k68468gkwcoow@www.smittys.pointclark.net>
	<1203995881.6248.56.camel@Mobulus>
	<20080226161958.hs8k5z3aos0ckgoc@www.smittys.pointclark.net>
	<1204063995.6248.65.camel@Mobulus>
	<20080226200223.phifyjor0g0gc0kk@www.smittys.pointclark.net>
	<20080226213345.mux04iosrkgoosks@www.smittys.pointclark.net>
	<1204090436.6695.9.camel@Mobulus>
	<20080227071619.3kvzfiyu8ksksoco@www.smittys.pointclark.net>
	<dd3c80060802282108t434afff0pdf1aecdddf811d1e@mail.gmail.com>
	<20080304233713.9ebennthfks4wg48@www.smittys.pointclark.net>
	<dd3c80060803042230y56ba10dcif065d722350dbc36@mail.gmail.com>
Message-ID: <20080308231724.nxhhoe5nsow88g40@www.smittys.pointclark.net>

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

> Try this instead, IIRC there are 4 DRBs. If it fails to build with too few
> registers, I think you can nuke the extra variable and just do multiple
> reads to the same location, or else reuse reg32 in place of reg8_2. I'm not
> really sure why the previous version failed, it looks sound to me. It might
> be interesting to put in some debugging output, to see what's going wrong.
>
Yep that worked great:-)
Here is a revised patch with all the suggested changes.

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

Thanks - Joe
-------------- next part --------------
Index: src/mainboard/rca/rm4100/gpio.c
===================================================================
--- src/mainboard/rca/rm4100/gpio.c	(revision 0)
+++ src/mainboard/rca/rm4100/gpio.c	(revision 0)
@@ -0,0 +1,121 @@
+/*
+ * This file is part of the coreboot project.
+ *
+ * Copyright (C) 2008 Joseph Smith <joe at smittys.pointclark.net>
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA  02110-1301 USA
+ */
+
+#define PME_DEV PNP_DEV(0x2e, 0x0a)
+#define PME_IO_BASE_ADDR	0x800 /* Runtime Register Base Address  */
+#define ICH_IO_BASE_ADDR	0x00000500 /* GPIO Base Address Register */
+
+/* Early mainboard specific GPIO setup. */
+static void mb_gpio_init(void)
+{
+	device_t dev;
+	uint16_t port;
+	uint32_t set_gpio;
+
+	/* Southbridge GPIO's */
+	/* Set the lpc device staticly. */
+	dev = PCI_DEV(0x0, 0x1f, 0x0);
+
+	/* Set the value for GPIO base address register and enable GPIO. */
+	pci_write_config32(dev, GPIO_BASE_ICH0_5, (ICH_IO_BASE_ADDR | 1));
+	pci_write_config8(dev, GPIO_CNTL_ICH0_5, 0x10);
+
+	/* Set GPIO25 to input and drive GPIO23 to high, 
+	 * this enables the LAN controller. 
+	 */
+	udelay(10);
+	set_gpio = 0x0000ffff;
+	set_gpio |= 1 << 25;
+	outl(set_gpio, ICH_IO_BASE_ADDR + 0x04);
+
+	set_gpio = 0x1b3f0000;
+	set_gpio |= 1 << 23;
+	outl(set_gpio, ICH_IO_BASE_ADDR + 0x0c);
+
+	/* SuperIO GPIO's */
+	dev = PME_DEV;
+	port = dev >> 8;
+
+	outb(0x55, port);		/* Enter the configuration state. */
+	pnp_set_logical_device(dev);
+	pnp_set_enable(dev, 0);
+	pnp_set_iobase(dev, PNP_IDX_IO0, PME_IO_BASE_ADDR);
+	pnp_set_enable(dev, 1);
+	outl(0x03, PME_IO_BASE_ADDR + 0x1e); /* Force Disk Change */
+	outl(0x02, PME_IO_BASE_ADDR + 0x1f); /* Floppy Data Rate */
+	outl(0x81, PME_IO_BASE_ADDR + 0x20); /* UART1 FIFO */
+	outl(0x00, PME_IO_BASE_ADDR + 0x21); /* UART2 FIFO */
+	outl(0x00, PME_IO_BASE_ADDR + 0x22); /* Device Disable */
+	outl(0x01, PME_IO_BASE_ADDR + 0x23); /* GP10 */
+	outl(0x01, PME_IO_BASE_ADDR + 0x24); /* GP11 */
+	outl(0x01, PME_IO_BASE_ADDR + 0x25); /* GP12 */
+	outl(0x01, PME_IO_BASE_ADDR + 0x26); /* GP13 */
+	outl(0x01, PME_IO_BASE_ADDR + 0x27); /* GP14 */
+	outl(0x01, PME_IO_BASE_ADDR + 0x28); /* GP15 */
+	outl(0x01, PME_IO_BASE_ADDR + 0x29); /* GP16 */
+	outl(0x01, PME_IO_BASE_ADDR + 0x2a); /* GP17 */
+	outl(0x01, PME_IO_BASE_ADDR + 0x2b); /* GP20 */
+	outl(0x01, PME_IO_BASE_ADDR + 0x2c); /* GP21 */
+	outl(0x01, PME_IO_BASE_ADDR + 0x2d); /* GP22 */
+	outl(0x01, PME_IO_BASE_ADDR + 0x2f); /* GP24 */
+	outl(0x01, PME_IO_BASE_ADDR + 0x30); /* GP25 */
+	outl(0x01, PME_IO_BASE_ADDR + 0x31); /* GP26 */
+	outl(0x01, PME_IO_BASE_ADDR + 0x32); /* GP27 */
+	outl(0x05, PME_IO_BASE_ADDR + 0x33); /* GP30 */
+	outl(0x05, PME_IO_BASE_ADDR + 0x34); /* GP31 */
+	outl(0x00, PME_IO_BASE_ADDR + 0x35); /* GP32 */
+	outl(0x00, PME_IO_BASE_ADDR + 0x36); /* GP33 */
+	outl(0x00, PME_IO_BASE_ADDR + 0x37); /* GP34 */
+	outl(0x04, PME_IO_BASE_ADDR + 0x38); /* GP35 */
+	outl(0x01, PME_IO_BASE_ADDR + 0x39); /* GP36 */
+	outl(0x01, PME_IO_BASE_ADDR + 0x3a); /* GP37 */
+	outl(0x01, PME_IO_BASE_ADDR + 0x3b); /* GP40 */
+	outl(0x01, PME_IO_BASE_ADDR + 0x3c); /* GP41 */
+	outl(0x86, PME_IO_BASE_ADDR + 0x3d); /* GP42 */
+	outl(0x01, PME_IO_BASE_ADDR + 0x3e); /* GP43 */
+	outl(0x05, PME_IO_BASE_ADDR + 0x3f); /* GP50 */
+	outl(0x05, PME_IO_BASE_ADDR + 0x40); /* GP51 */
+	outl(0x05, PME_IO_BASE_ADDR + 0x41); /* GP52 */
+	outl(0x04, PME_IO_BASE_ADDR + 0x42); /* GP53 */
+	outl(0x05, PME_IO_BASE_ADDR + 0x43); /* GP54 */
+	outl(0x04, PME_IO_BASE_ADDR + 0x44); /* GP55 */
+	outl(0x05, PME_IO_BASE_ADDR + 0x45); /* GP56 */
+	outl(0x04, PME_IO_BASE_ADDR + 0x46); /* GP57 */
+	outl(0x01, PME_IO_BASE_ADDR + 0x47); /* GP58 */
+	outl(0x01, PME_IO_BASE_ADDR + 0x48); /* GP59 */
+	outl(0x00, PME_IO_BASE_ADDR + 0x4b); /* GP1 */
+	outl(0x04, PME_IO_BASE_ADDR + 0x4c); /* GP2 */
+	outl(0xc0, PME_IO_BASE_ADDR + 0x4d); /* GP3 */
+	outl(0x00, PME_IO_BASE_ADDR + 0x4e); /* GP4 */
+	outl(0x07, PME_IO_BASE_ADDR + 0x4f); /* GP5 */
+	outl(0x00, PME_IO_BASE_ADDR + 0x50); /* GP6 */
+	outl(0x00, PME_IO_BASE_ADDR + 0x56); /* FAN1 */
+	outl(0x00, PME_IO_BASE_ADDR + 0x57); /* FAN2 */
+	outl(0x50, PME_IO_BASE_ADDR + 0x58); /* Fan Control */
+	outl(0xff, PME_IO_BASE_ADDR + 0x59); /* Fan1 Tachometer */
+	outl(0xff, PME_IO_BASE_ADDR + 0x5a); /* Fan2 Tachometer */
+	outl(0x00, PME_IO_BASE_ADDR + 0x5b); /* Fan1 Preload */
+	outl(0x00, PME_IO_BASE_ADDR + 0x5c); /* Fan2 Preload */
+	outl(0x00, PME_IO_BASE_ADDR + 0x5d); /* LED1 */
+	outl(0x00, PME_IO_BASE_ADDR + 0x5e); /* LED2 */
+	outl(0x00, PME_IO_BASE_ADDR + 0x5f); /* Keyboard Scan Code */
+	outb(0xaa, port);		/* Exit the configuration state. */
+
+}
\ No newline at end of file
Index: src/mainboard/rca/rm4100/Config.lb
===================================================================
--- src/mainboard/rca/rm4100/Config.lb	(revision 0)
+++ src/mainboard/rca/rm4100/Config.lb	(revision 0)
@@ -0,0 +1,214 @@
+##
+## This file is part of the coreboot project.
+##
+## Copyright (C) 2008 Joseph Smith <joe at smittys.pointclark.net>
+##
+## This program is free software; you can redistribute it and/or modify
+## it under the terms of the GNU General Public License as published by
+## the Free Software Foundation; either version 2 of the License, or
+## (at your option) any later version.
+##
+## This program is distributed in the hope that it will be useful,
+## but WITHOUT ANY WARRANTY; without even the implied warranty of
+## MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+## GNU General Public License for more details.
+##
+## You should have received a copy of the GNU General Public License
+## along with this program; if not, write to the Free Software
+## Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA  02110-1301 USA
+##
+##
+## Compute the location and size of where this firmware image
+## (coreboot plus bootloader) will live in the boot rom chip.
+##
+if USE_FALLBACK_IMAGE
+	default ROM_SECTION_SIZE = FALLBACK_SIZE
+	default ROM_SECTION_OFFSET = ( ROM_SIZE - FALLBACK_SIZE )
+else
+	default ROM_SECTION_SIZE = ( ROM_SIZE - FALLBACK_SIZE )
+	default ROM_SECTION_OFFSET = 0
+end
+
+##
+## Compute the start location and size size of
+## The coreboot bootloader.
+##
+default CONFIG_ROM_PAYLOAD_START = (0xffffffff - ROM_SIZE + ROM_SECTION_OFFSET + 1)
+default PAYLOAD_SIZE = ( ROM_SECTION_SIZE - ROM_IMAGE_SIZE )
+
+##
+## Compute where this copy of coreboot will start in the boot rom
+##
+default _ROMBASE = ( CONFIG_ROM_PAYLOAD_START + PAYLOAD_SIZE )
+
+##
+## Compute a range of ROM that can cached to speed up coreboot,
+## execution speed.
+##
+## XIP_ROM_SIZE must be a power of 2.
+## XIP_ROM_BASE must be a multiple of XIP_ROM_SIZE
+##
+default XIP_ROM_SIZE = 65536
+default XIP_ROM_BASE = ( _ROMBASE + ROM_IMAGE_SIZE - XIP_ROM_SIZE )
+
+##
+## Set all of the defaults for an x86 architecture
+##
+
+arch i386 end
+
+##
+## Build the objects we have code for in this directory.
+##
+
+driver mainboard.o
+
+if HAVE_PIRQ_TABLE object irq_tables.o end
+#object reset.o
+
+if HAVE_ACPI_TABLES
+	object fadt.o
+	object dsdt.o
+	object acpi_tables.o
+end
+
+##
+## Romcc output
+##
+makerule ./failover.E
+	depends "$(MAINBOARD)/../../../arch/i386/lib/failover.c ./romcc"
+	action "./romcc -E -O --label-prefix=failover -I$(TOP)/src -I. $(CPPFLAGS) $(MAINBOARD)/../../../arch/i386/lib/failover.c -o $@"
+end
+makerule ./failover.inc
+	depends "$(MAINBOARD)/../../../arch/i386/lib/failover.c ./romcc"
+	action "./romcc    -O --label-prefix=failover -I$(TOP)/src -I. $(CPPFLAGS) $(MAINBOARD)/../../../arch/i386/lib/failover.c -o $@"
+end
+
+makerule ./auto.E 
+	# depends "$(MAINBOARD)/auto.c option_table.h ./romcc"
+	depends	"$(MAINBOARD)/auto.c ./romcc"
+	action	"./romcc -E -mcpu=p3 -O -I$(TOP)/src -I. $(CPPFLAGS) $(MAINBOARD)/auto.c -o $@"
+end
+makerule ./auto.inc 
+	# depends "$(MAINBOARD)/auto.c option_table.h ./romcc"
+	depends	"$(MAINBOARD)/auto.c ./romcc"
+	action	"./romcc    -mcpu=p3 -O -I$(TOP)/src -I. $(CPPFLAGS) $(MAINBOARD)/auto.c -o $@"
+end
+
+##
+## Build our 16 bit and 32 bit coreboot entry code
+##
+mainboardinit cpu/x86/16bit/entry16.inc
+mainboardinit cpu/x86/32bit/entry32.inc
+ldscript /cpu/x86/16bit/entry16.lds
+ldscript /cpu/x86/32bit/entry32.lds
+
+##
+## Build our reset vector (This is where coreboot is entered)
+##
+if USE_FALLBACK_IMAGE 
+	mainboardinit cpu/x86/16bit/reset16.inc 
+	ldscript /cpu/x86/16bit/reset16.lds 
+else
+	mainboardinit cpu/x86/32bit/reset32.inc 
+	ldscript /cpu/x86/32bit/reset32.lds 
+end
+
+### Should this be in the northbridge code?
+mainboardinit arch/i386/lib/cpu_reset.inc
+
+##
+## Include an id string (For safe flashing)
+##
+mainboardinit arch/i386/lib/id.inc
+ldscript /arch/i386/lib/id.lds
+
+###
+### This is the early phase of coreboot startup 
+### Things are delicate and we test to see if we should
+### failover to another image.
+###
+if USE_FALLBACK_IMAGE
+	ldscript /arch/i386/lib/failover.lds 
+	mainboardinit ./failover.inc
+end
+
+###
+### O.k. We aren't just an intermediary anymore!
+###
+
+##
+## Setup RAM
+##
+mainboardinit cpu/x86/fpu/enable_fpu.inc
+mainboardinit cpu/x86/mmx/enable_mmx.inc
+mainboardinit ./auto.inc
+mainboardinit cpu/x86/mmx/disable_mmx.inc
+
+##
+## Include the secondary Configuration files 
+##
+dir /pc80
+config chip.h
+
+chip northbridge/intel/i82830
+	device pci_domain 0 on 
+		device pci 0.0 on end # Host bridge: Intel Corporation 82830 830 Chipset Host Bridge
+		chip drivers/pci/onboard
+			device pci 2.0 on end # VGA compatible controller: Intel Corporation 82830 CGC
+			register "rom_address" = "0xfff00000"
+		end
+		chip southbridge/intel/i82801xx
+			device pci 1d.0 on end # USB UHCI Controller #1
+			device pci 1d.1 on end # USB UHCI Controller #2
+			device pci 1d.2 on end # USB UHCI Controller #3
+			device pci 1d.7 on end # USB2 EHCI Controller
+			device pci 1e.0 on # PCI bridge: Intel Corporation 82801 PCI Bridge
+				device pci 08.0 on end # Intel Corporation 82801DB PRO/100 VE Ethernet Controller
+			end
+			device pci 1f.0 on # ISA bridge: Intel Corporation 82801DB LPC Interface SouthBridge
+				chip superio/smsc/smscsuperio 
+					device pnp 2e.0 off # Floppy
+						io 0x60 = 0x3f0
+						irq 0x70 = 6
+						drq 0x74 = 2
+					end
+					device pnp 2e.3 on # Parallel Port
+						io 0x60 = 0x378
+						irq 0x70 = 7
+						drq 0x74 = 4
+					end
+					device pnp 2e.4 on # Com1
+						io 0x60 = 0x3f8
+						irq 0x70 = 4
+					end
+					device pnp 2e.5 on # Com2 / IR
+						io 0x60 = 0x2f8
+						irq 0x70 = 3
+					end
+					device pnp 2e.7 on # Keyboard
+						io 0x60 = 0x60
+						io 0x62 = 0x64
+						irq 0x70 = 1 # Keyboard interrupt
+						irq 0x72 = 12 # Mouse interrupt
+					end
+					device pnp 2e.9 off end # Game Port
+					device pnp 2e.a on # PME
+						io 0x60 = 0x800
+					end
+					device pnp 2e.b off end # MPU-401
+				end
+			end
+			device pci 1f.1 on end # IDE interface: Intel Corporation 82801DB IDE Controller
+			device pci 1f.3 on end # SMBus: Intel Corporation 82801DB SMBus Controller
+			device pci 1f.5 on end # Multimedia audio controller: AC'97 Audio Controller
+			device pci 1f.6 on end # Modem: AC'97 Modem Controller
+		end
+	end
+	device apic_cluster 0 on # APIC cluster
+		chip cpu/intel/socket_PGA370 # Mobile Intel Celeron Processor Micro-FCBGA Socket 479
+		device apic 0 on end # APIC
+		end
+	end
+end
+
Index: src/mainboard/rca/rm4100/spd_table.h
===================================================================
--- src/mainboard/rca/rm4100/spd_table.h	(revision 0)
+++ src/mainboard/rca/rm4100/spd_table.h	(revision 0)
@@ -0,0 +1,43 @@
+/*
+ * This file is part of the coreboot project.
+ *
+ * Copyright (C) 2008 Joseph Smith <joe at smittys.pointclark.net>
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA  02110-1301 USA
+ */
+
+#include <spd.h>
+
+struct spd_entry {
+	unsigned int address;
+	unsigned int data;
+	};
+
+/* 
+ * The onboard 128MB PC133 memory does not have a SPD eeprom so the
+ * values have to be set manually, 
+ * the onboard memory is located in socket1 (0x51).
+*/
+
+const struct spd_entry spd_table [] = 
+{
+{SPD_MEMORY_TYPE,                     0x04}, /* (Fundamental) memory type */
+{SPD_NUM_COLUMNS,                     0x09}, /* Number of column address bits */
+{SPD_NUM_DIMM_BANKS,                  0x01}, /* Number of module rows (banks) */
+{SPD_MODULE_DATA_WIDTH_LSB,           0x40}, /* Module data width (LSB) */
+{SPD_MIN_CYCLE_TIME_AT_CAS_MAX,       0x75}, /* SDRAM cycle time (highest CAS latency), RAS access time (tRAC) */
+{SPD_ACCESS_TIME_FROM_CLOCK,          0x54}, /* SDRAM access time from clock (highest CAS latency), CAS access time (Tac, tCAC) */
+{SPD_DENSITY_OF_EACH_ROW_ON_MODULE,   0x20}, /* Density of each row on module */
+};
Index: src/mainboard/rca/rm4100/irq_tables.c
===================================================================
--- src/mainboard/rca/rm4100/irq_tables.c	(revision 0)
+++ src/mainboard/rca/rm4100/irq_tables.c	(revision 0)
@@ -0,0 +1,53 @@
+/*
+ * This file is part of the coreboot project.
+ *
+ * Copyright (C) 2008 Joseph Smith <joe at smittys.pointclark.net>
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA  02110-1301 USA
+ */
+
+#include <arch/pirq_routing.h>
+
+const struct irq_routing_table intel_irq_routing_table = {
+	PIRQ_SIGNATURE,  /* u32 signature */
+	PIRQ_VERSION,    /* u16 version   */
+	32+16*IRQ_SLOT_COUNT,	 /* there can be total 10 devices on the bus */
+	0x00,		 /* Where the interrupt router lies (bus) */
+	(0x1f<<3)|0x0,   /* Where the interrupt router lies (dev) */
+	0,		 /* IRQs devoted exclusively to PCI usage */
+	0x8086,		 /* Vendor */
+	0x24c0,		 /* Device */
+	0,		 /* Crap (miniport) */
+	{ 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0 }, /* u8 rfu[11] */
+	0x14,         /*  u8 checksum , this hase to set to some value that would give 0 after the sum of all bytes for this structure (including checksum) */
+	{
+		/* bus,     dev|fn,   {link, bitmap}, {link, bitmap}, {link, bitmap}, {link, bitmap},  slot, rfu */
+		{0x00,(0x1d<<3)|0x0, {{0x60, 0x1ef8}, {0x61, 0x1ef8}, {0x62, 0x1ef8}, {0x63, 0x01ef8}}, 0x0, 0x0}, /* [A] USB UHCI Controller #1 */
+		{0x00,(0x1d<<3)|0x1, {{0x61, 0x1ef8}, {0x62, 0x1ef8}, {0x63, 0x1ef8}, {0x60, 0x01ef8}}, 0x0, 0x0}, /* [B] USB UHCI Controller #2 */
+		{0x00,(0x1d<<3)|0x2, {{0x62, 0x1ef8}, {0x63, 0x1ef8}, {0x60, 0x1ef8}, {0x61, 0x01ef8}}, 0x0, 0x0}, /* [C] USB UHCI Controller #3 */
+		{0x00,(0x1d<<3)|0x7, {{0x63, 0x1ef8}, {0x60, 0x1ef8}, {0x61, 0x1ef8}, {0x62, 0x01ef8}}, 0x0, 0x0}, /* [D] USB2 EHCI Controller */
+		{0x00,(0x1f<<3)|0x1, {{0x60, 0x1ef8}, {0x61, 0x1ef8}, {0x62, 0x1ef8}, {0x63, 0x01ef8}}, 0x0, 0x0}, /* [A] IDE Controller */
+		{0x00,(0x1f<<3)|0x3, {{0x61, 0x1ef8}, {0x62, 0x1ef8}, {0x63, 0x1ef8}, {0x60, 0x01ef8}}, 0x0, 0x0}, /* [B] SMBus Controller */
+		{0x00,(0x02<<3)|0x0, {{0x60, 0x1ef8}, {0x61, 0x1ef8}, {0x62, 0x1ef8}, {0x63, 0x01ef8}}, 0x0, 0x0}, /* [A] VGA compatible controller */
+		{0x00,(0x1f<<3)|0x5, {{0x61, 0x1ef8}, {0x62, 0x1ef8}, {0x63, 0x1ef8}, {0x60, 0x01ef8}}, 0x0, 0x0}, /* [B] AC'97 Audio Controller */
+		{0x01,(0x08<<3)|0x0, {{0x68, 0x1ef8}, {0x00, 0x0000}, {0x00, 0x0000}, {0x00, 0x00000}}, 0x0, 0x0}, /* [A] Ethernet controller */
+		{0x00,(0x1f<<3)|0x6, {{0x61, 0x1ef8}, {0x62, 0x1ef8}, {0x63, 0x1ef8}, {0x64, 0x01ef8}}, 0x0, 0x0}, /* [B] AC'97 Modem Controller */
+	}
+};
+
+unsigned long write_pirq_routing_table(unsigned long addr)
+{
+	return copy_pirq_routing_table(addr);
+}
\ No newline at end of file
Index: src/mainboard/rca/rm4100/Options.lb
===================================================================
--- src/mainboard/rca/rm4100/Options.lb	(revision 0)
+++ src/mainboard/rca/rm4100/Options.lb	(revision 0)
@@ -0,0 +1,216 @@
+##
+## This file is part of the coreboot project.
+##
+## Copyright (C) 2008 Joseph Smith <joe at smittys.pointclark.net>
+##
+## This program is free software; you can redistribute it and/or modify
+## it under the terms of the GNU General Public License as published by
+## the Free Software Foundation; either version 2 of the License, or
+## (at your option) any later version.
+##
+## This program is distributed in the hope that it will be useful,
+## but WITHOUT ANY WARRANTY; without even the implied warranty of
+## MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+## GNU General Public License for more details.
+##
+## You should have received a copy of the GNU General Public License
+## along with this program; if not, write to the Free Software
+## Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA  02110-1301 USA
+##
+
+uses CC
+uses CONFIG_CONSOLE_SERIAL8250
+uses CONFIG_CONSOLE_VGA
+uses CONFIG_COMPRESSED_PAYLOAD_LZMA
+uses CONFIG_IOAPIC
+uses CONFIG_PCI_ROM_RUN
+uses CONFIG_ROM_PAYLOAD
+uses CONFIG_ROM_PAYLOAD_START
+uses CONFIG_TSC_X86RDTSC_CALIBRATE_WITH_TIMER2
+uses CONFIG_UDELAY_TSC
+uses CONFIG_VIDEO_MB
+uses CROSS_COMPILE
+uses DEFAULT_CONSOLE_LOGLEVEL
+uses FALLBACK_SIZE
+uses HAVE_ACPI_TABLES
+uses HAVE_FALLBACK_BOOT
+uses HAVE_MP_TABLE
+uses HAVE_OPTION_TABLE
+uses HAVE_PIRQ_TABLE
+uses HEAP_SIZE
+uses HOSTCC
+uses IRQ_SLOT_COUNT
+uses COREBOOT_EXTRA_VERSION
+uses MAINBOARD
+uses MAINBOARD_VENDOR
+uses MAINBOARD_PART_NUMBER
+uses MAXIMUM_CONSOLE_LOGLEVEL
+uses OBJCOPY
+uses PAYLOAD_SIZE
+uses _RAMBASE
+uses _ROMBASE
+uses ROM_IMAGE_SIZE
+uses ROM_SECTION_SIZE
+uses ROM_SECTION_OFFSET
+uses ROM_SIZE
+uses STACK_SIZE
+uses TTYS0_BASE
+uses TTYS0_BAUD
+uses TTYS0_LCS
+uses USE_FALLBACK_IMAGE
+uses USE_OPTION_TABLE
+uses XIP_ROM_SIZE
+uses XIP_ROM_BASE
+
+
+###
+### Build options
+###
+
+##
+## ROM_SIZE is the size of boot ROM that this board will use.
+##
+default ROM_SIZE = 512 * 1024
+default ROM_IMAGE_SIZE = 128 * 1024
+
+##
+## Build code for the fallback boot?
+##
+default HAVE_FALLBACK_BOOT = 1
+default FALLBACK_SIZE = 512 * 1024
+
+##
+## Delay timer options
+##
+default CONFIG_UDELAY_TSC = 1
+default CONFIG_TSC_X86RDTSC_CALIBRATE_WITH_TIMER2 = 1
+
+##
+## Build code to export a programmable irq routing table
+##
+default HAVE_PIRQ_TABLE = 1
+default IRQ_SLOT_COUNT = 10
+
+##
+## Build code to export an x86 MP table
+## Useful for specifying IRQ routing values
+##
+default HAVE_MP_TABLE = 0
+
+##
+## Build code to export ACPI tables?
+##
+default HAVE_ACPI_TABLES = 0
+
+##
+## Build code to setup a generic IOAPIC
+##
+default CONFIG_IOAPIC = 0
+
+##
+## Build code to export a CMOS option table?
+##
+default HAVE_OPTION_TABLE = 0
+
+##
+## VGA Console
+## NOTE: to initialize VGA, need to copy the VGA 
+## option ROM from the factory BIOS to VGA.rom
+##
+default CONFIG_CONSOLE_VGA = 0
+default CONFIG_PCI_ROM_RUN = 0
+
+default CONFIG_VIDEO_MB = 0
+
+
+###
+### LinuxBIOS layout values
+###
+
+##
+## Use a small 8K stack
+##
+default STACK_SIZE = 0x2000
+
+##
+## Use a small 16K heap
+##
+default HEAP_SIZE = 0x4000
+
+##
+## LinuxBIOS C code runs at this location in RAM
+##
+default _RAMBASE = 0x00004000
+
+##
+## Use the CMOS option table
+##
+default USE_OPTION_TABLE = 0
+
+##
+## Load the payload from the ROM
+##
+default CONFIG_ROM_PAYLOAD = 1
+
+##
+## The default compiler
+##
+default CC="$(CROSS_COMPILE)gcc -m32"
+default HOSTCC="gcc"
+
+##
+## The Serial Console
+##
+
+##
+## To Enable the Serial Console
+##
+default CONFIG_CONSOLE_SERIAL8250=1
+
+##
+## Select the serial console baud rate
+##
+default TTYS0_BAUD=115200
+
+##
+## Select the serial console base port
+##
+default TTYS0_BASE=0x3f8
+
+##
+## Select the serial protocol
+## This defaults to 8 data bits, 1 stop bit, and no parity
+##
+default TTYS0_LCS=0x3
+
+##
+### Select the linuxBIOS loglevel
+##
+## EMERG      1   system is unusable               
+## ALERT      2   action must be taken immediately 
+## CRIT       3   critical conditions              
+## ERR        4   error conditions                 
+## WARNING    5   warning conditions               
+## NOTICE     6   normal but significant condition 
+## INFO       7   informational                    
+## DEBUG      8   debug-level messages             
+## SPEW       9   Way too many details             
+
+##
+## Request this level of debugging output
+##
+default  DEFAULT_CONSOLE_LOGLEVEL = 9
+
+##
+## At a maximum only compile in this level of debugging
+##
+default  MAXIMUM_CONSOLE_LOGLEVEL = 9
+
+##
+## Set the mainboard vender name
+##
+default MAINBOARD_VENDOR = "RCA"
+default MAINBOARD_PART_NUMBER = "RM4100"
+
+### End Options.lb
+end
Index: src/mainboard/rca/rm4100/chip.h
===================================================================
--- src/mainboard/rca/rm4100/chip.h	(revision 0)
+++ src/mainboard/rca/rm4100/chip.h	(revision 0)
@@ -0,0 +1,25 @@
+/*
+ * This file is part of the coreboot project.
+ *
+ * Copyright (C) 2008 Joseph Smith <joe at smittys.pointclark.net>
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA  02110-1301 USA
+ */
+
+extern struct chip_operations mainboard_rca_rm4100_ops;
+
+struct mainboard_rca_rm4100_config {
+	int nothing;
+};
Index: src/mainboard/rca/rm4100/auto.c
===================================================================
--- src/mainboard/rca/rm4100/auto.c	(revision 0)
+++ src/mainboard/rca/rm4100/auto.c	(revision 0)
@@ -0,0 +1,138 @@
+/*
+ * This file is part of the coreboot project.
+ *
+ * Copyright (C) 2008 Joseph Smith <joe at smittys.pointclark.net>
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA  02110-1301 USA
+ */
+
+#define ASSEMBLY 1
+
+#include <stdint.h>
+#include <device/pci_def.h>
+#include <arch/io.h>
+#include <device/pnp_def.h>
+#include <arch/romcc_io.h>
+#include <arch/hlt.h>
+#include "pc80/serial.c"
+#include "pc80/udelay_io.c"
+#include "arch/i386/lib/console.c"
+#include "ram/ramtest.c"
+#include "superio/smsc/smscsuperio/smscsuperio_early_serial.c"
+#include "northbridge/intel/i82830/raminit.h"
+#include "southbridge/intel/i82801xx/i82801xx.h"
+#include "cpu/x86/mtrr/earlymtrr.c"
+#include "cpu/x86/bist.h"
+#include "spd_table.h"
+#include "gpio.c"
+
+#define SERIAL_DEV PNP_DEV(0x2e, SMSCSUPERIO_SP1)
+
+#include "southbridge/intel/i82801xx/i82801xx_early_smbus.c"
+
+/* 
+ * The onboard 128MB PC133 memory does not have a SPD eeprom so the
+ * values have to be set manually, 
+ * the so-dimm socket is located in socket0 (0x50),
+ * and the onboard memory is located in socket1 (0x51).
+*/
+static inline int spd_read_byte(unsigned device, unsigned address)
+{
+	int i;
+
+	if (device == 0x50){
+		return smbus_read_byte(device, address);
+	} else if (device == 0x51){
+		for (i=0; i < (sizeof spd_table/sizeof spd_table[0]); i++){
+			if (spd_table[i].address == address){
+				return spd_table[i].data;
+			}
+		}
+		return 0xFF; /* This line returns 0xFF when address not found */
+	} else {
+		return 0xFF; /* returns 0xFF on any failures */
+	}
+}
+
+#include "northbridge/intel/i82830/raminit.c"
+#include "sdram/generic_sdram.c"
+
+/* We have to disable the TCO Timer system reboot feature
+ * or we get several reboots through out the boot processes
+ */
+static void disable_tco_timer(void)
+{
+	device_t dev;
+	u8 reg8;
+
+	/* Set the lpc device staticly. */
+	dev = PCI_DEV(0x0, 0x1f, 0x0);
+
+	/* Disable the TCO Timer system reboot feature */
+	reg8 = pci_read_config8(dev, 0xd4);
+	reg8 |= (1 << 1);
+	pci_write_config8(dev, 0xd4, reg8);
+}
+
+/* 
+ * The AC'97 Audio Controller I/O space registers
+ * are read only by default so we need to enable
+ * them by setting register 0x41 to 0x01
+*/
+static void ac97_io_enable(void)
+{
+	device_t dev;
+
+	/* Set the ac97 audio device staticly. */
+	dev = PCI_DEV(0x0, 0x1f, 0x5);
+
+	/* Enable access to the IO space. */
+	pci_write_config8(dev, 0x41, 0x01);
+}
+
+static void main(unsigned long bist)
+{
+	static const struct mem_controller memctrl[] = {
+		{
+		 .d0 = PCI_DEV(0, 0, 0),
+		 .channel0 = {0x50, 0x51},
+		 }
+	};
+
+	if (bist == 0) {
+		early_mtrr_init();
+	}
+
+	enable_smbus();
+
+	smscsuperio_enable_serial(SERIAL_DEV, TTYS0_BASE);
+	mb_gpio_init();
+	uart_init();
+	console_init();
+
+	/* Halt if there was a built in self test failure. */
+	report_bist_failure(bist);
+
+	sdram_set_registers(memctrl);
+	sdram_set_spd_registers(memctrl);
+	sdram_enable(0, memctrl);
+
+	/* Check RAM. */
+	/* ram_check(0, 640 * 1024); */
+	/* ram_check(130048 * 1024, 131072 * 1024); */
+
+	disable_tco_timer();
+	ac97_io_enable();
+}
Index: src/mainboard/rca/rm4100/mainboard.c
===================================================================
--- src/mainboard/rca/rm4100/mainboard.c	(revision 0)
+++ src/mainboard/rca/rm4100/mainboard.c	(revision 0)
@@ -0,0 +1,26 @@
+/*
+ * This file is part of the coreboot project.
+ *
+ * Copyright (C) 2008 Joseph Smith <joe at smittys.pointclark.net>
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA  02110-1301 USA
+ */
+
+#include <device/device.h>
+#include "chip.h"
+
+struct chip_operations mainboard_rca_rm4100_ops = {
+	CHIP_NAME("RCA RM4100 Mainboard")
+};
Index: src/northbridge/intel/i82830/Config.lb
===================================================================
--- src/northbridge/intel/i82830/Config.lb	(revision 0)
+++ src/northbridge/intel/i82830/Config.lb	(revision 0)
@@ -0,0 +1,22 @@
+##
+## This file is part of the coreboot project.
+##
+## Copyright (C) 2008 Joseph Smith <joe at smittys.pointclark.net>
+##
+## This program is free software; you can redistribute it and/or modify
+## it under the terms of the GNU General Public License as published by
+## the Free Software Foundation; either version 2 of the License, or
+## (at your option) any later version.
+##
+## This program is distributed in the hope that it will be useful,
+## but WITHOUT ANY WARRANTY; without even the implied warranty of
+## MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+## GNU General Public License for more details.
+##
+## You should have received a copy of the GNU General Public License
+## along with this program; if not, write to the Free Software
+## Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA  02110-1301 USA
+##
+
+config chip.h
+object northbridge.o
Index: src/northbridge/intel/i82830/i82830.h
===================================================================
--- src/northbridge/intel/i82830/i82830.h	(revision 0)
+++ src/northbridge/intel/i82830/i82830.h	(revision 0)
@@ -0,0 +1,62 @@
+/*
+ * This file is part of the coreboot project.
+ *
+ * Copyright (C) 2008 Joseph Smith <joe at smittys.pointclark.net>
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA  02110-1301 USA
+ */
+
+/* Not all of these are used just listed for informational purposes */
+
+#define SVID 0X2C    /* Subsystem Vendor ID - Default Value 0X0000 - 16 bits */
+#define SID 0X2E    /* Subsystem ID - Default Value 0X0000 - 16 bits */
+
+#define RRBAR 0X48    /* Register Range Base Address Register - Default Value 0X00000000 - 32 bits */
+#define GCC0 0X50    /* GMCH Control Register #0 - Default Value 0XA072 - 16 bits */
+#define GCC1 0X52    /* GMCH Control Register #1 - Default Value 0X0000 - 16 bits */
+#define FDHC 0X58    /* Fixed DRAM Hole Control Register - Default Value 0X00 - 8 bits */
+#define PAM0 0X59     /* Programable Attribute Map Register #0 - Default Value 0X00 - 8 bits */
+#define PAM1 0X5A     /* Programable Attribute Map Register #1 - Default Value 0X00 - 8 bits */
+#define PAM2 0X5B     /* Programable Attribute Map Register #2 - Default Value 0X00 - 8 bits */
+#define PAM3 0X5C     /* Programable Attribute Map Register #3 - Default Value 0X00 - 8 bits */
+#define PAM4 0X5D     /* Programable Attribute Map Register #4 - Default Value 0X00 - 8 bits */
+#define PAM5 0X5E     /* Programable Attribute Map Register #5 - Default Value 0X00 - 8 bits */
+#define PAM6 0X5F     /* Programable Attribute Map Register #6 - Default Value 0X00 - 8 bits */
+#define DRB 0X60     /* DRAM Row Boundary Register #0 - Default Value 0X00 - 8 bits */
+#define DRB1 0X61     /* DRAM Row Boundary Register #1 - Default Value 0X00 - 8 bits */
+#define DRB2 0X62     /* DRAM Row Boundary Register #2 - Default Value 0X00 - 8 bits */
+#define DRB3 0X63     /* DRAM Row Boundary Register #3 - Default Value 0X00 - 8 bits */
+#define DRA 0X70     /* DRAM Row Attribute Register #0 - Default Value 0XFF - 8 bits */
+#define DRA1 0X71     /* DRAM Row Attribute Register #1 - Default Value 0XFF - 8 bits */
+#define DRT	0X78     /* DRAM Timing Register - Default Value 0X00000010 - 32 bits */
+#define DRC  0X7C     /* DRAM Controller Mode Register #0 - Default Value 0X00000000 - 32 bits */
+#define DRC1 0X7D     /* DRAM Controller Mode Register #1 - Default Value 0X00000000 - 32 bits */
+#define DRC2 0X7E     /* DRAM Controller Mode Register #2 - Default Value 0X00000000 - 32 bits */
+#define DRC3 0X7F     /* DRAM Controller Mode Register #3 - Default Value 0X00000000 - 32 bits */
+#define DTC	0X8C     /* DRAM Throttling Control Register - Default Value 0X00000000 - 32 bits */
+#define SMRAM 0X90   /* System Management RAM Control Register - Default Value 0X02 - 8 bits */
+#define ESMRAMC 0X91 /* Extended System Management RAM Control Register - Default Value 0X38 - 8 bits */
+
+#define ERRSTS 0X92    /* Error Status Register - Default Value 0X0000 - 16 bits */
+#define ERRCMD 0X94    /* Error Command Register - Default Value 0X0000 - 16 bits */
+
+#define BUFF_SC 0XEC     /* System Memory Buffer Strength Control Register - Default Value 0X00000000 - 32 bits */
+
+#define APBASE 0X10    /* Aperture Base Configuration Register - Default Value 0X00000008 - 32 bits */
+#define APSIZE 0XB4     /* Apterture Size - Default Value 0X00 - 8 bits */
+#define ATTBASE 0XB8     /* Aperture Translation Table Base Register - Default Value 0X00000000 - 32 bits */
+
+
+
Index: src/northbridge/intel/i82830/raminit.c
===================================================================
--- src/northbridge/intel/i82830/raminit.c	(revision 0)
+++ src/northbridge/intel/i82830/raminit.c	(revision 0)
@@ -0,0 +1,522 @@
+/*
+ * This file is part of the coreboot project.
+ *
+ * Copyright (C) 2008 Joseph Smith <joe at smittys.pointclark.net>
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA  02110-1301 USA
+ *
+ */
+
+#include <spd.h>
+#include <sdram_mode.h>
+#include <delay.h>
+#include "debug.c"
+#include "i82830.h"
+
+/*-----------------------------------------------------------------------------
+Macros and definitions.
+-----------------------------------------------------------------------------*/
+
+/* Uncomment this to enable debugging output. */
+/* #define DEBUG_RAM_SETUP 1 */
+
+/* Debugging macros. */
+#if defined(DEBUG_RAM_SETUP)
+#define PRINT_DEBUG(x)		print_debug(x)
+#define PRINT_DEBUG_HEX8(x)	print_debug_hex8(x)
+#define PRINT_DEBUG_HEX16(x)	print_debug_hex16(x)
+#define PRINT_DEBUG_HEX32(x)	print_debug_hex32(x)
+#define DUMPNORTH()		dump_pci_device(PCI_DEV(0, 0, 0))
+#else
+#define PRINT_DEBUG(x)
+#define PRINT_DEBUG_HEX8(x)
+#define PRINT_DEBUG_HEX16(x)
+#define PRINT_DEBUG_HEX32(x)
+#define DUMPNORTH()
+#endif
+
+/* DRC[10:8] - Refresh Mode Select (RMS).
+ * 0x0 for Refresh Disabled (Self Refresh)
+ * 0x1 for Refresh interval 15.6 us for 133MHz
+ * 0x2 for Refresh interval 7.8 us for 133MHz
+ * 0x7 /* Refresh interval 128 Clocks. (Fast Refresh Mode)
+ */
+#define RAM_COMMAND_REFRESH      0x2
+
+/* DRC[6:4] - SDRAM Mode Select (SMS). */
+#define RAM_COMMAND_SELF_REFRESH 0x0
+#define RAM_COMMAND_NOP		   0x1
+#define RAM_COMMAND_PRECHARGE	   0x2
+#define RAM_COMMAND_MRS		   0x3
+#define RAM_COMMAND_CBR		   0x6
+#define RAM_COMMAND_NORMAL	   0x7
+
+/* DRC[29] - Initialization Complete (IC). */
+#define RAM_COMMAND_IC           0x1
+
+/*-----------------------------------------------------------------------------
+SDRAM configuration functions.
+-----------------------------------------------------------------------------*/
+
+/* Send the specified RAM command to all DIMMs. */
+
+static void do_ram_command(const struct mem_controller *ctrl, uint32_t command, uint32_t addr_offset)
+{
+	int i;
+	uint8_t reg8, reg8_2 = 0;
+	uint32_t reg32;
+
+	/* Configure the RAM command. */
+	reg32 = pci_read_config32(ctrl->d0, DRC);
+	/* 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; */
+
+	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;
+       }
+}
+
+/*-----------------------------------------------------------------------------
+DIMM-independant configuration functions.
+-----------------------------------------------------------------------------*/
+
+struct dimm_size {
+	unsigned long side1;
+	unsigned long side2;
+};
+
+static struct dimm_size spd_get_dimm_size(unsigned device)
+{
+	struct dimm_size sz;
+	int i, module_density, dimm_banks;
+	sz.side1 = 0;
+	module_density = spd_read_byte(device, 31);
+	dimm_banks = spd_read_byte(device, 5);
+
+	/* Find the size of side1 */
+	/* Find the larger value. The larger value is always side1 */	
+	for (i = 512; i >= 0; i >>= 1) {
+		if ((module_density & i) == i) {
+			sz.side1 = i;
+			break;
+		}
+	}
+
+	/* Set to 0 in case it's single sided */
+	sz.side2 = 0;
+
+	/* Test if it's a dual-sided dimm */
+	if (dimm_banks > 1) {
+
+		/* Test to see if there's a second value, if so it's asymmetrical */
+		if (module_density != i) {
+
+		/* Find the second value, picking up where we left off */
+		/* i >>= 1 done initially to make sure we don't get the same value again */
+			for (i >>= 1; i >= 0; i >>= 1) {
+				if (module_density == (sz.side1 | i)) {
+					sz.side2 = i;
+					break;
+				}
+			}
+
+		/* If not, it's symmetrical */
+		} else {
+		sz.side2 = sz.side1;
+		}
+	}
+	/* SPD byte 31 is the memory size divided by 4 so we
+	 * need to muliply by 4 to get the total size.
+	 */
+	sz.side1 *= 4;
+	sz.side2 *= 4;
+	return sz;
+}
+
+static void spd_set_dram_size(const struct mem_controller *ctrl)
+{
+	int i, value, drb1, drb2;
+
+	for (i = 0; i < DIMM_SOCKETS; i++) {
+		struct dimm_size sz;
+		unsigned device;
+		device = ctrl->channel0[i];
+		drb1 = 0;
+		drb2 = 0;
+
+		/* First check if a DIMM is actually present. */
+		if (spd_read_byte(device, 2) == 0x4) {
+			print_debug("Found DIMM in slot ");
+			print_debug_hex8(i);
+			print_debug("\r\n");
+
+			sz = spd_get_dimm_size(device);
+
+			/* WISHLIST: would be nice to display it as decimal? */
+			print_debug("DIMM is 0x");
+			print_debug_hex16(sz.side1);
+			print_debug(" on side 1\r\n");
+			print_debug("DIMM is 0x");
+			print_debug_hex16(sz.side2);
+			print_debug(" on side 2\r\n");
+
+			/* Test for PC133 (i82830 only supports PC133) */
+			/* PC133 SPD9 - cycle time is always 75 */
+			if (spd_read_byte(device, 9) != 0x75) {
+				print_err("SPD9 DIMM Is Not PC133 Compatable\r\n");
+				die("HALT\r\n");
+			}
+			/* PC133 SPD10 - access time is always 54 */
+			if (spd_read_byte(device, 10) != 0x54) {
+				print_err("SPD10 DIMM Is Not PC133 Compatable\r\n");
+				die("HALT\r\n");
+			}
+
+			/* The i82830 only supports a symmetrical dual-sided dimms
+			 * and can't handle DIMMs smaller than 32MB per
+			 * side or larger than 256MB per side.
+			 */
+			if ((sz.side2 != 0) && (sz.side1 != sz.side2)) {
+				print_err("This northbridge only supports\r\n");
+				print_err("symmetrical dual-sided DIMMs\r\n");
+				print_err("booting as a single-sided DIMM\r\n");
+				sz.side2 = 0;
+			}
+			if ((sz.side1 < 32)) {
+				print_err("DIMMs smaller than 32MB per side\r\n");
+				print_err("are not supported on this northbridge\r\n");
+				die("HALT\r\n");
+			}
+
+			if ((sz.side1 > 256)) {
+				print_err("DIMMs larger than 256MB per side\r\n");
+				print_err("are not supported on this northbridge\r\n");
+				die("HALT\r\n");
+			}
+
+			/* We need to divide size by 32 to set up the
+			 * DRB registers.
+			*/
+			if (sz.side1) {
+				drb1 = sz.side1 / 32;
+			}
+			if (sz.side2) {
+				drb2 = sz.side2 / 32;
+			}
+		} else {
+			PRINT_DEBUG("No DIMM found in slot ");
+			PRINT_DEBUG_HEX8(i);
+			PRINT_DEBUG("\r\n");
+
+			/* If there's no DIMM in the slot, set value to 0. */
+			drb1 = 0;
+			drb2 = 0;
+		}
+      	/* Set the value for DRAM Row Boundary Registers */
+		if (i == 0) {
+			pci_write_config8(ctrl->d0, DRB, drb1);
+			pci_write_config8(ctrl->d0, DRB + 1, drb1 + drb2);
+			PRINT_DEBUG("DRB 0x");
+			PRINT_DEBUG_HEX8(DRB);
+			PRINT_DEBUG(" has been set to 0x");
+			PRINT_DEBUG_HEX8(drb1);
+			PRINT_DEBUG("\r\n");
+			PRINT_DEBUG("DRB1 0x");
+			PRINT_DEBUG_HEX8(DRB + 1);
+			PRINT_DEBUG(" has been set to 0x");
+			PRINT_DEBUG_HEX8(drb1 + drb2);
+			PRINT_DEBUG("\r\n");
+		} else if (i == 1) {
+			value = pci_read_config8(ctrl->d0, DRB + 1);
+			pci_write_config8(ctrl->d0, DRB + 2, value + drb1);
+			pci_write_config8(ctrl->d0, DRB + 3, value + drb1 + drb2);
+			PRINT_DEBUG("DRB2 0x");
+			PRINT_DEBUG_HEX8(DRB + 2);
+			PRINT_DEBUG(" has been set to 0x");
+			PRINT_DEBUG_HEX8(value + drb1);
+			PRINT_DEBUG("\r\n");
+			PRINT_DEBUG("DRB3 0x");
+			PRINT_DEBUG_HEX8(DRB + 3);
+			PRINT_DEBUG(" has been set to 0x");
+			PRINT_DEBUG_HEX8(value + drb1 + drb2);
+			PRINT_DEBUG("\r\n");
+
+			/* We need to set the highest DRB value to 0x64 and 0x65.
+			 * These are supposed to be "Reserved" but memory will
+			 * not initialize properly if we don't.
+			 */
+			value = pci_read_config8(ctrl->d0, DRB + 3);
+			pci_write_config8(ctrl->d0, DRB + 4, value);
+			pci_write_config8(ctrl->d0, DRB + 5, value);
+		}
+	}
+}
+
+static void set_dram_row_attributes(const struct mem_controller *ctrl)
+{
+	int i, dra, col, width, value;
+
+	for (i = 0; i < DIMM_SOCKETS; i++) {
+		unsigned device;
+		device = ctrl->channel0[i];
+
+		/* First check if a DIMM is actually present. */
+		if (spd_read_byte(device, 2) == 0x4) {
+			print_debug("Found DIMM in slot ");
+			print_debug_hex8(i);
+			print_debug(", setting DRA...\r\n");
+
+			dra = 0x00;
+
+			/* columns */
+			col = spd_read_byte(device, 4);
+
+			/* data width */
+			width = spd_read_byte(device, 6);
+
+			/* calculate page size in bits */
+			value = ((1 << col) * width);
+
+			/* convert to Kilobytes */
+			dra = ((value / 8) >> 10);
+
+			/* # of banks of DIMM (single or double sided) */
+			value = spd_read_byte(device, 5);
+
+			if (value == 1) {
+				switch(dra) {
+					/* 2KB */
+					case 2:
+						dra = 0xF0;
+						break;
+					/* 4KB */
+					case 4:
+						dra = 0xF1;
+						break;
+					/* 8KB */
+					case 8:
+						dra = 0xF2;
+						break;
+					/* 16KB */
+					case 16:
+						dra = 0xF3;
+						break;
+					default:
+						print_err("Page size not supported\r\n");
+						die("HALT\r\n");
+				}
+			} else if (value == 2) {
+				switch(dra) {
+					/* 2KB */
+					case 2:
+						dra = 0x00;
+						break;
+					/* 4KB */
+					case 4:
+						dra = 0x11;
+						break;
+					/* 8KB */
+					case 8:
+						dra = 0x22;
+						break;
+					/* 16KB */
+					case 16:
+						dra = 0x33;
+						break;
+					default:
+						print_err("Page size not supported\r\n");
+						die("HALT\r\n");
+				}
+			}else {
+				print_err("# of banks of DIMM not supported\r\n");
+				die("HALT\r\n");
+			}
+
+		} else {
+			PRINT_DEBUG("No DIMM found in slot ");
+			PRINT_DEBUG_HEX8(i);
+			PRINT_DEBUG(", setting DRA to 0xFF\r\n");
+
+			/* If there's no DIMM in the slot, set dra value to 0xFF. */
+			dra = 0xFF;
+		}
+
+		/* Set the value for DRAM Row Attribute Registers */
+      	pci_write_config8(ctrl->d0, DRA + i, dra);
+		PRINT_DEBUG("DRA 0x");
+		PRINT_DEBUG_HEX8(DRA + i);
+		PRINT_DEBUG(" has been set to 0x");
+		PRINT_DEBUG_HEX8(dra);
+		PRINT_DEBUG("\r\n");
+	}
+}
+
+static void set_dram_timing(const struct mem_controller *ctrl)
+{
+	/* Set the value for DRAM Timing Register */
+	/* TODO: Configure the value according to SPD values. */
+	pci_write_config32(ctrl->d0, DRT, 0x00000010);
+}
+
+static void set_dram_buffer_strength(const struct mem_controller *ctrl)
+{
+	/* TODO: This needs to be set according to the DRAM tech
+	 * (x8, x16, or x32). Argh, Intel provides no docs on this!
+	 * Currently, it needs to be pulled from the output of
+	 * lspci -xxx Rx92
+	*/
+
+	/* Set the value for System Memory Buffer Strength Control Registers */
+	pci_write_config32(ctrl->d0, BUFF_SC, 0xFC9B491B);
+}
+
+/*-----------------------------------------------------------------------------
+Public interface.
+-----------------------------------------------------------------------------*/
+
+static void sdram_set_registers(const struct mem_controller *ctrl)
+{
+	uint16_t value;
+	int igd_memory = 0;
+
+	PRINT_DEBUG("Setting initial registers....\r\n");
+
+	/* Set the value for GMCH Control Register #0 */
+	pci_write_config16(ctrl->d0, GCC0, 0xA072);
+
+	/* Set the value for GMCH Control Register #1 */
+	switch (CONFIG_VIDEO_MB) {
+		/* 512K of memory */
+		case 512:
+			igd_memory = 0x2;
+			break;
+		/* 1M of memory */
+		case 1:
+			igd_memory = 0x3;
+			break;
+		/* 8M of memory */
+		case 8:
+			igd_memory = 0x4;
+			break;
+		/* No memory */
+		default:
+			pci_write_config16(ctrl->d0, GCC1, 0x0002);
+			igd_memory = 0x0;
+	}
+	value = pci_read_config16(ctrl->d0, GCC1);
+	value |= igd_memory << 4;
+	pci_write_config16(ctrl->d0, GCC1, value);
+
+	/* Set the value for Aperture Base Configuration Register  */
+	pci_write_config32(ctrl->d0, APBASE, 0x00000008);
+
+	/* Set the value for Register Range Base Address Register */
+	pci_write_config32(ctrl->d0, RRBAR, 0x00000000);
+
+	/* Set the value for Fixed DRAM Hole Control Register */
+	pci_write_config8(ctrl->d0, FDHC, 0x00);
+
+	/* Set the value for Programable Attribute Map Registers
+	 * Ideally, this should be R/W for as many ranges as possible.
+	 */
+	pci_write_config8(ctrl->d0, PAM0, 0x30);
+	pci_write_config8(ctrl->d0, PAM1, 0x33);
+	pci_write_config8(ctrl->d0, PAM2, 0x33);
+	pci_write_config8(ctrl->d0, PAM3, 0x33);
+	pci_write_config8(ctrl->d0, PAM4, 0x33);
+	pci_write_config8(ctrl->d0, PAM5, 0x33);
+	pci_write_config8(ctrl->d0, PAM6, 0x33);
+
+	/* Set the value for DRAM Throttling Control Register */
+	pci_write_config32(ctrl->d0, DTC, 0x00000000);
+
+	/* Set the value for System Management RAM Control Register */
+	pci_write_config8(ctrl->d0, SMRAM, 0x02);
+
+	/* Set the value for Extended System Management RAM Control Register */
+	pci_write_config8(ctrl->d0, ESMRAMC, 0x38);
+
+	PRINT_DEBUG("Initial registers have been set.\r\n");
+}
+
+static void sdram_set_spd_registers(const struct mem_controller *ctrl)
+{
+	spd_set_dram_size(ctrl);
+
+	set_dram_row_attributes(ctrl);
+
+	set_dram_timing(ctrl);
+
+	set_dram_buffer_strength(ctrl);
+}
+
+static void sdram_enable(int controllers, const struct mem_controller *ctrl)
+{
+	int i;
+
+	/* 0. Wait until power/voltages and clocks are stable (200us). */
+	udelay(200);
+
+	/* 1. Apply NOP. */
+	PRINT_DEBUG("RAM Enable 1: Apply NOP\r\n");
+	do_ram_command(ctrl, RAM_COMMAND_NOP, 0);
+	udelay(200);
+
+	/* 2. Precharge all. Wait tRP. */
+	PRINT_DEBUG("RAM Enable 2: Precharge all\r\n");
+	do_ram_command(ctrl, RAM_COMMAND_PRECHARGE, 0);
+	udelay(1);
+
+	/* 3. Perform 8 refresh cycles. Wait tRC each time. */
+	PRINT_DEBUG("RAM Enable 3: CBR\r\n");
+	for (i = 0; i < 8; i++) {
+		do_ram_command(ctrl, RAM_COMMAND_CBR, 0);
+		udelay(1);
+	}
+
+	/* 4. Mode register set. Wait two memory cycles. */
+	/* TODO: Set offset according to DRT values */
+	PRINT_DEBUG("RAM Enable 4: Mode register set\r\n");
+	do_ram_command(ctrl, RAM_COMMAND_MRS, 0x1d0);
+	udelay(2);
+
+	/* 5. Normal operation (enables refresh) */
+	PRINT_DEBUG("RAM Enable 5: Normal operation\r\n");
+	do_ram_command(ctrl, RAM_COMMAND_NORMAL, 0);
+	udelay(1);
+
+	PRINT_DEBUG("Northbridge following SDRAM init:\r\n");
+	DUMPNORTH();
+}
Index: src/northbridge/intel/i82830/debug.c
===================================================================
--- src/northbridge/intel/i82830/debug.c	(revision 0)
+++ src/northbridge/intel/i82830/debug.c	(revision 0)
@@ -0,0 +1,66 @@
+
+static void print_debug_pci_dev(unsigned dev)
+{
+	print_debug("PCI: ");
+	print_debug_hex8((dev >> 16) & 0xff);
+	print_debug_char(':');
+	print_debug_hex8((dev >> 11) & 0x1f);
+	print_debug_char('.');
+	print_debug_hex8((dev >> 8) & 7);
+}
+
+static void print_pci_devices(void)
+{
+	device_t dev;
+	for(dev = PCI_DEV(0, 0, 0); 
+		dev <= PCI_DEV(0, 0x1f, 0x7); 
+		dev += PCI_DEV(0,0,1)) {
+		uint32_t id;
+		id = pci_read_config32(dev, PCI_VENDOR_ID);
+		if (((id & 0xffff) == 0x0000) || ((id & 0xffff) == 0xffff) ||
+			(((id >> 16) & 0xffff) == 0xffff) ||
+			(((id >> 16) & 0xffff) == 0x0000)) {
+			continue;
+		}
+		print_debug_pci_dev(dev);
+		print_debug("\r\n");
+	}
+}
+
+static void dump_pci_device(unsigned dev)
+{
+	int i;
+	print_debug_pci_dev(dev);
+	print_debug("\r\n");
+	
+	for(i = 0; i <= 255; i++) {
+		unsigned char val;
+		if ((i & 0x0f) == 0) {
+			print_debug_hex8(i);
+			print_debug_char(':');
+		}
+		val = pci_read_config8(dev, i);
+		print_debug_char(' ');
+		print_debug_hex8(val);
+		if ((i & 0x0f) == 0x0f) {
+			print_debug("\r\n");
+		}
+	}
+}
+
+static void dump_pci_devices(void)
+{
+	device_t dev;
+	for(dev = PCI_DEV(0, 0, 0); 
+		dev <= PCI_DEV(0, 0x1f, 0x7); 
+		dev += PCI_DEV(0,0,1)) {
+		uint32_t id;
+		id = pci_read_config32(dev, PCI_VENDOR_ID);
+		if (((id & 0xffff) == 0x0000) || ((id & 0xffff) == 0xffff) ||
+			(((id >> 16) & 0xffff) == 0xffff) ||
+			(((id >> 16) & 0xffff) == 0x0000)) {
+			continue;
+		}
+		dump_pci_device(dev);
+	}
+}
Index: src/northbridge/intel/i82830/northbridge.c
===================================================================
--- src/northbridge/intel/i82830/northbridge.c	(revision 0)
+++ src/northbridge/intel/i82830/northbridge.c	(revision 0)
@@ -0,0 +1,207 @@
+/*
+ * This file is part of the coreboot project.
+ *
+ * Copyright (C) 2008 Joseph Smith <joe at smittys.pointclark.net>
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA  02110-1301 USA
+ */
+
+#include <console/console.h>
+#include <arch/io.h>
+#include <stdint.h>
+#include <device/device.h>
+#include <device/pci.h>
+#include <device/pci_ids.h>
+#include <stdlib.h>
+#include <string.h>
+#include <bitops.h>
+#include "chip.h"
+#include "i82830.h"
+
+static void northbridge_init(device_t dev)
+{
+	printk_spew("Northbridge init\n");
+}
+
+static struct device_operations northbridge_operations = {
+	.read_resources	= pci_dev_read_resources,
+	.set_resources	= pci_dev_set_resources,
+	.enable_resources	= pci_dev_enable_resources,
+	.init			= northbridge_init,
+	.enable		= 0,
+	.ops_pci		= 0,
+};
+
+static struct pci_driver northbridge_driver __pci_driver = {
+	.ops	= &northbridge_operations,
+	.vendor	= PCI_VENDOR_ID_INTEL,
+	.device	= 0x3575,
+};
+
+#define BRIDGE_IO_MASK (IORESOURCE_IO | IORESOURCE_MEM)
+
+static void pci_domain_read_resources(device_t dev)
+{
+	struct resource *resource;
+
+	/* Initialize the system wide io space constraints */
+	resource = new_resource(dev, IOINDEX_SUBTRACTIVE(0, 0));
+	resource->limit = 0xffffUL;
+	resource->flags = IORESOURCE_IO | IORESOURCE_SUBTRACTIVE | IORESOURCE_ASSIGNED;
+
+	/* Initialize the system wide memory resources constraints */
+	resource = new_resource(dev, IOINDEX_SUBTRACTIVE(1, 0));
+	resource->limit = 0xffffffffULL;
+	resource->flags = IORESOURCE_MEM | IORESOURCE_SUBTRACTIVE | IORESOURCE_ASSIGNED;
+}
+
+static void ram_resource(device_t dev, unsigned long index,
+			 unsigned long basek, unsigned long sizek)
+{
+	struct resource *resource;
+
+	if (!sizek) {
+		return;
+	}
+	resource = new_resource(dev, index);
+	resource->base = ((resource_t) basek) << 10;
+	resource->size = ((resource_t) sizek) << 10;
+	resource->flags = IORESOURCE_MEM | IORESOURCE_CACHEABLE |
+	    IORESOURCE_FIXED | IORESOURCE_STORED | IORESOURCE_ASSIGNED;
+}
+
+static void tolm_test(void *gp, struct device *dev, struct resource *new)
+{
+	struct resource **best_p = gp;
+	struct resource *best;
+	best = *best_p;
+	if (!best || (best->base > new->base)) {
+		best = new;
+	}
+	*best_p = best;
+}
+
+static uint32_t find_pci_tolm(struct bus *bus)
+{
+	struct resource *min;
+	uint32_t tolm;
+	min = 0;
+	search_bus_resources(bus, IORESOURCE_MEM, IORESOURCE_MEM, tolm_test, &min);
+	tolm = 0xffffffffUL;
+	if (min && tolm > min->base) {
+		tolm = min->base;
+	}
+	return tolm;
+}
+
+static void pci_domain_set_resources(device_t dev)
+{
+	device_t mc_dev;
+        uint32_t pci_tolm;
+	int igd_memory = 0;
+
+        pci_tolm = find_pci_tolm(&dev->link[0]);
+	mc_dev = dev->link[0].children;
+	if (mc_dev) {
+		/* Figure out which areas are/should be occupied by RAM.
+		 * This is all computed in kilobytes and converted to/from
+		 * the memory controller right at the edges.
+		 * Having different variables in different units is
+		 * too confusing to get right.  Kilobytes are good up to
+		 * 4 Terabytes of RAM...
+		 */
+
+		unsigned long tomk, tolmk;
+		int idx;
+
+		if (CONFIG_VIDEO_MB == 512) {
+			igd_memory = (CONFIG_VIDEO_MB);
+		} else {
+			igd_memory = (CONFIG_VIDEO_MB * 1024);
+		}
+
+		/* Get the value of the highest DRB. This tells the end of
+		 * the physical memory.  The units are ticks of 32MB
+		 * i.e. 1 means 32MB.
+		 */
+		tomk = ((unsigned long)pci_read_config8(mc_dev, DRB+3)) << 15;
+		tomk -= igd_memory;
+
+		printk_debug("Setting RAM size to %d\n", tomk);
+
+		/* Compute the top of Low memory */
+		tolmk = pci_tolm >> 10;
+		if (tolmk >= tomk) {
+			/* The PCI hole does does not overlap the memory.
+			 */
+			tolmk = tomk;
+		}
+
+		/* Report the memory regions */
+		idx = 10;
+		ram_resource(dev, idx++, 0, 640);
+		ram_resource(dev, idx++, 1024, tolmk - 1024);
+	}
+	assign_resources(&dev->link[0]);
+}
+
+static unsigned int pci_domain_scan_bus(device_t dev, unsigned int max)
+{
+	max = pci_scan_bus(&dev->link[0], PCI_DEVFN(0, 0), 0xff, max);
+	return max;
+}
+
+static struct device_operations pci_domain_ops = {
+	.read_resources	= pci_domain_read_resources,
+	.set_resources	= pci_domain_set_resources,
+	.enable_resources	= enable_childrens_resources,
+	.init			= 0,
+	.scan_bus		= pci_domain_scan_bus,
+};
+
+static void cpu_bus_init(device_t dev)
+{
+	initialize_cpus(&dev->link[0]);
+}
+
+static void cpu_bus_noop(device_t dev)
+{
+}
+
+static struct device_operations cpu_bus_ops = {
+	.read_resources	= cpu_bus_noop,
+	.set_resources	= cpu_bus_noop,
+	.enable_resources	= cpu_bus_noop,
+	.init			= cpu_bus_init,
+	.scan_bus		= 0,
+};
+
+static void enable_dev(struct device *dev)
+{
+	struct device_path;
+
+	/* Set the operations if it is a special bus type */
+	if (dev->path.type == DEVICE_PATH_PCI_DOMAIN) {
+		dev->ops = &pci_domain_ops;
+		pci_set_method(dev);
+	} else if (dev->path.type == DEVICE_PATH_APIC_CLUSTER) {
+		dev->ops = &cpu_bus_ops;
+	}
+}
+
+struct chip_operations northbridge_intel_i82830_ops = {
+	CHIP_NAME("Intel 82830 Northbridge")
+	.enable_dev = enable_dev,
+};
Index: src/northbridge/intel/i82830/raminit.h
===================================================================
--- src/northbridge/intel/i82830/raminit.h	(revision 0)
+++ src/northbridge/intel/i82830/raminit.h	(revision 0)
@@ -0,0 +1,32 @@
+/*
+ * This file is part of the coreboot project.
+ *
+ * Copyright (C) 2008 Joseph Smith <joe at smittys.pointclark.net>
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA  02110-1301 USA
+ */
+
+#ifndef NORTHBRIDGE_INTEL_I82830_RAMINIT_H
+#define NORTHBRIDGE_INTEL_I82830_RAMINIT_H
+
+/* The 82830 supports max. 2 dual-sided SO-DIMMs. */
+#define DIMM_SOCKETS	2
+
+struct mem_controller {
+	device_t d0;
+	uint16_t channel0[DIMM_SOCKETS];
+};
+
+#endif /* NORTHBRIDGE_INTEL_I82830_RAMINIT_H */
Index: src/northbridge/intel/i82830/chip.h
===================================================================
--- src/northbridge/intel/i82830/chip.h	(revision 0)
+++ src/northbridge/intel/i82830/chip.h	(revision 0)
@@ -0,0 +1,24 @@
+/*
+ * This file is part of the coreboot project.
+ *
+ * Copyright (C) 2008 Joseph Smith <joe at smittys.pointclark.net>
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA  02110-1301 USA
+ */
+
+struct northbridge_intel_i82830_config {
+};
+
+extern struct chip_operations northbridge_intel_i82830_ops;
Index: targets/rca/rm4100/Config.lb
===================================================================
--- targets/rca/rm4100/Config.lb	(revision 0)
+++ targets/rca/rm4100/Config.lb	(revision 0)
@@ -0,0 +1,63 @@
+##
+## This file is part of the coreboot project.
+##
+## Copyright (C) 2008 Joseph Smith <joe at smittys.pointclark.net>
+##
+## This program is free software; you can redistribute it and/or modify
+## it under the terms of the GNU General Public License as published by
+## the Free Software Foundation; either version 2 of the License, or
+## (at your option) any later version.
+##
+## This program is distributed in the hope that it will be useful,
+## but WITHOUT ANY WARRANTY; without even the implied warranty of
+## MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+## GNU General Public License for more details.
+##
+## You should have received a copy of the GNU General Public License
+## along with this program; if not, write to the Free Software
+## Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA  02110-1301 USA
+##
+
+target rm4100
+mainboard rca/rm4100
+
+##
+## Total number of bytes allocated for coreboot use
+## (fallback images and payloads).
+##
+# option ROM_SIZE = 1024 * 1024
+## For VGA BIOS (-64k)
+option ROM_SIZE = (1024 * 1024) - (64 * 1024)
+
+##
+## VGA Console
+## NOTE: to initialize VGA, you need to copy 
+## the VGA option ROM from the factory BIOS
+## 0=disable  1=enable
+##
+option CONFIG_CONSOLE_VGA = 1
+option CONFIG_PCI_ROM_RUN = 1
+
+##
+## Choose the amount of memory pre-allocated for VGA
+## 0 for No memory pre-allocated (Graphics memory Disabled)
+## 512 for DVMT (UMA) mode, 512K of memory pre-allocated for frame buffer
+## 1 for DVMT (UMA) mode, 1M of memory pre-allocated for frame buffer
+## 8 for DVMT (UMA) mode, 8M of memory pre-allocated for frame buffer
+##
+option CONFIG_VIDEO_MB = 8
+
+##
+## Request this level of debugging output
+##
+option DEFAULT_CONSOLE_LOGLEVEL = 7
+
+romimage "fallback"
+	option USE_FALLBACK_IMAGE = 1
+	option FALLBACK_SIZE = ROM_SIZE
+	option COREBOOT_EXTRA_VERSION = "_RM4100"
+	payload /tmp/filo.elf
+#	payload /tmp/eb-5.4.3-eepro100.elf
+end
+
+buildrom ./coreboot.rom ROM_SIZE "fallback"

From joe at smittys.pointclark.net  Sun Mar  9 05:20:49 2008
From: joe at smittys.pointclark.net (joe at smittys.pointclark.net)
Date: Sat, 08 Mar 2008 23:20:49 -0500
Subject: [coreboot] [PATCH]ich_gpio_dump util ACK?
In-Reply-To: <20080229203945.GA8306@coresystems.de>
References: <20080224120416.8bfhu8y74kkow808@www.smittys.pointclark.net>
	<47C486DF.7080903@gmx.net>
	<20080226180241.2vy3q1nm040sw04o@www.smittys.pointclark.net>
	<20080229203945.GA8306@coresystems.de>
Message-ID: <20080308232049.yceuvfqvaysg8ssw@www.smittys.pointclark.net>

>
> Signed-off-by: Stefan Reinauer <stepan at coresystems.de>
>
Here is the util patch updated with suggestions from Uwe.

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

Thanks - Joe
-------------- next part --------------
Index: intel-debugtools/ich_gpio_dump/ich_gpio.c
===================================================================
--- intel-debugtools/ich_gpio_dump/ich_gpio.c	(revision 0)
+++ intel-debugtools/ich_gpio_dump/ich_gpio.c	(revision 0)
@@ -0,0 +1,95 @@
+/*
+ * dump gpio on intel ICH series southbridges
+ *
+ * Copyright (C) 2008 by coresystems GmbH 
+ * written by Stefan Reinauer <stepan at coresystems.de> 
+ * Copyright (C) 2008 Joseph Smith <joe at smittys.pointclark.net>
+ * 
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.
+ */
+
+#include <errno.h>
+#include <fcntl.h>
+#include <sys/mman.h>
+#include <unistd.h>
+#include <stdio.h>
+#include <string.h>
+#include <stdlib.h>
+#include <stdint.h>
+#include <getopt.h>
+
+#include <sys/io.h>
+#include <pci/pci.h>
+
+int map_gpio(uint16_t gpio)
+{
+	int i;
+	unsigned long size=0x40;
+
+	for (i=0; i<size; i+=4) {
+		printf("gpiobase+0x%04x: 0x%08x\n", i, inl(gpio+i));
+	}
+
+	return 0;
+}
+
+int main(int argc, char *argv[])
+{
+	struct pci_access *pacc;
+	struct pci_dev *sb;
+	uint16_t gpiobadd;
+	uint16_t device;
+
+	if (iopl(3)) { printf("You need to be root.\n"); exit(1); }
+
+	pacc = pci_alloc();
+	pci_init(pacc);
+	pci_scan_bus(pacc);
+
+	sb = pci_get_dev(pacc, 0, 0, 0x1f, 0);
+	if (!sb) {
+		printf("No southbridge found.\n");
+		pci_cleanup(pacc);
+		exit(1);
+	}
+
+	if (pci_read_word(sb, 0) != 0x8086) {
+		printf("Not an Intel southbridge.\n");
+		
+		pci_free_dev(sb);
+		pci_cleanup(pacc);
+		exit(1);
+	}
+
+	printf("Intel Southbridge: %04x:%04x\n", 
+		pci_read_word(sb, 0), pci_read_word(sb, 2));
+
+	device = pci_read_word(sb, 2);
+
+	if (device < 0x2640) {
+		gpiobadd = pci_read_word(sb, 0x58) & 0xfffc; 
+	} else if (device >= 0x2640) {
+		gpiobadd = pci_read_word(sb, 0x48) & 0xfffc;
+	}
+	printf("GPIOBASE = 0x%04x\n\n", gpiobadd);
+
+	pci_free_dev(sb);
+	pci_cleanup(pacc);
+
+	map_gpio(gpiobadd);
+
+
+	return 0;
+}

Property changes on: intel-debugtools/ich_gpio_dump/ich_gpio.c
___________________________________________________________________
Name: svn:executable
   + *

Index: intel-debugtools/ich_gpio_dump/ich_gpio.8
===================================================================
--- intel-debugtools/ich_gpio_dump/ich_gpio.8	(revision 0)
+++ intel-debugtools/ich_gpio_dump/ich_gpio.8	(revision 0)
@@ -0,0 +1,59 @@
+.TH ICH_GPIO 8 "March 8, 2008"
+.SH NAME
+ich_gpio \- Intel southbridge GPIO Dump Utility
+.SH SYNOPSIS
+.B ich_gpio
+.SH DESCRIPTION
+.B ich_gpio 
+is a user-space utility which can dump all 
+register contents of the Intel ICH series Southbridges.
+.PP
+It is mainly used for coreboot development purposes (see coreboot.org
+for details on coreboot), but it may also be useful for other things.
+.PP
+Here is an example output:
+.br
+[root at localhost dumpgpio]# ich_gpio
+.br
+Intel Southbridge: 8086:24c0
+.br
+GPIOBASE = 0x0500
+.br
+gpiobase+0x0000: 0x1a003180
+.br
+gpiobase+0x0004: 0x0900ffff
+.br
+gpiobase+0x0008: 0x00000000
+.br
+gpiobase+0x000c: 0x1bbf0000
+.br
+gpiobase+0x0010: 0x00000000
+.br
+gpiobase+0x0014: 0x00000000
+.br
+gpiobase+0x0018: 0x00040000
+.br
+gpiobase+0x001c: 0x00000000
+.br
+gpiobase+0x0020: 0x00000000
+.br
+gpiobase+0x0024: 0x00000000
+.br
+gpiobase+0x0028: 0x00000000
+.br
+gpiobase+0x002c: 0x00003000
+.br
+gpiobase+0x0030: 0x00000fff
+.br
+gpiobase+0x0034: 0x00000e00
+.br
+gpiobase+0x0038: 0x00000fff
+.br
+gpiobase+0x003c: 0x00000000
+.PP
+Please consult your datasheet for the register meanings.
+.SH OPTIONS
+No command line options needed just run ich_gpio.
+.SH AUTHORS
+Please see the individual source code files.
+
Index: intel-debugtools/ich_gpio_dump/Makefile
===================================================================
--- intel-debugtools/ich_gpio_dump/Makefile	(revision 0)
+++ intel-debugtools/ich_gpio_dump/Makefile	(revision 0)
@@ -0,0 +1,62 @@
+#
+# Makefile for ich_gpio utility
+# 
+# (C) 2008 by coresystems GmbH
+# written by Stefan Reinauer <stepan at coresystems.de>
+# Copyright (C) 2008 Joseph Smith <joe at smittys.pointclark.net>
+#
+
+PROGRAM = ich_gpio
+
+CC = gcc
+STRIP	= strip
+INSTALL = /usr/bin/install
+PREFIX = /usr/local
+CFLAGS = -O2 -g -Wall
+OS_ARCH = $(shell uname)
+ifeq ($(OS_ARCH), SunOS)
+LDFLAGS = -lpci -lz
+else
+LDFLAGS = -lpci -lz -static 
+STRIP_ARGS = -s
+endif
+
+OBJS = ich_gpio.o
+
+all: pciutils dep $(PROGRAM)
+
+$(PROGRAM): $(OBJS)
+	$(CC) -o $(PROGRAM) $(OBJS) $(LDFLAGS)
+	$(STRIP) $(STRIP_ARGS) $(PROGRAM)
+
+clean:
+	rm -f *.o *~
+
+distclean: clean
+	rm -f $(PROGRAM) .dependencies
+	
+dep:
+	@$(CC) -MM *.c > .dependencies
+
+pciutils:
+	@echo; echo -n "Checking for pciutils and zlib... "
+	@$(shell ( echo "#include <pci/pci.h>";		   \
+		   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 &&	\
+		echo "found." || ( echo "not found."; echo;		\
+		echo "Please install pciutils-devel and zlib-devel.";	\
+		echo "See README for more information."; echo;		\
+		rm -f .test.c .test; exit 1)
+	@rm -f .test.c .test
+
+install: $(PROGRAM)
+	$(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
+

Property changes on: intel-debugtools/ich_gpio_dump/Makefile
___________________________________________________________________
Name: svn:executable
   + *


From rminnich at gmail.com  Sun Mar  9 06:48:37 2008
From: rminnich at gmail.com (ron minnich)
Date: Sat, 8 Mar 2008 21:48:37 -0800
Subject: [coreboot] [PATCH]ich_gpio_dump util ACK?
In-Reply-To: <20080308232049.yceuvfqvaysg8ssw@www.smittys.pointclark.net>
References: <20080224120416.8bfhu8y74kkow808@www.smittys.pointclark.net>
	<47C486DF.7080903@gmx.net>
	<20080226180241.2vy3q1nm040sw04o@www.smittys.pointclark.net>
	<20080229203945.GA8306@coresystems.de>
	<20080308232049.yceuvfqvaysg8ssw@www.smittys.pointclark.net>
Message-ID: <13426df10803082148g69e73abbvdaaed3e2a0230fe7@mail.gmail.com>

A few things caught my eye:
+	if (iopl(3)) { printf("You need to be root.\n"); exit(1); }

Just use perror. This is going to be confusing if there is an error
and you're running as root :-)

There are a few cases where there are pci cleanups and frees and such
and then an immediate exit. I applaud the sentiment but, really,
you're just as safe exiting without the cleanup. Just a thought ...

thanks, this is neat stuff.

ron



From joe at smittys.pointclark.net  Sun Mar  9 08:07:05 2008
From: joe at smittys.pointclark.net (joe at smittys.pointclark.net)
Date: Sun, 09 Mar 2008 03:07:05 -0400
Subject: [coreboot] [PATCH]ich_gpio_dump util ACK?
In-Reply-To: <13426df10803082148g69e73abbvdaaed3e2a0230fe7@mail.gmail.com>
References: <20080224120416.8bfhu8y74kkow808@www.smittys.pointclark.net>
	<47C486DF.7080903@gmx.net>
	<20080226180241.2vy3q1nm040sw04o@www.smittys.pointclark.net>
	<20080229203945.GA8306@coresystems.de>
	<20080308232049.yceuvfqvaysg8ssw@www.smittys.pointclark.net>
	<13426df10803082148g69e73abbvdaaed3e2a0230fe7@mail.gmail.com>
Message-ID: <20080309030705.nure77cigco04ww0@www.smittys.pointclark.net>

Quoting ron minnich <rminnich at gmail.com>:

> A few things caught my eye:
> +	if (iopl(3)) { printf("You need to be root.\n"); exit(1); }
>
> Just use perror. This is going to be confusing if there is an error
> and you're running as root :-)
>
> There are a few cases where there are pci cleanups and frees and such
> and then an immediate exit. I applaud the sentiment but, really,
> you're just as safe exiting without the cleanup. Just a thought ...
>
> thanks, this is neat stuff.
>
> ron
>
Ok, I changed the printf to perror and removed the pci frees and  
cleanups from the errors and just left it on the main function.  
Attached is the revised patch.


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

Thanks - Joe
-------------- next part --------------
Index: intel-debugtools/ich_gpio_dump/ich_gpio.c
===================================================================
--- intel-debugtools/ich_gpio_dump/ich_gpio.c	(revision 0)
+++ intel-debugtools/ich_gpio_dump/ich_gpio.c	(revision 0)
@@ -0,0 +1,94 @@
+/*
+ * dump gpio on intel ICH series southbridges
+ *
+ * Copyright (C) 2008 by coresystems GmbH 
+ * written by Stefan Reinauer <stepan at coresystems.de> 
+ * Copyright (C) 2008 Joseph Smith <joe at smittys.pointclark.net>
+ * 
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.
+ */
+
+#include <errno.h>
+#include <fcntl.h>
+#include <sys/mman.h>
+#include <unistd.h>
+#include <stdio.h>
+#include <string.h>
+#include <stdlib.h>
+#include <stdint.h>
+#include <getopt.h>
+
+#include <sys/io.h>
+#include <pci/pci.h>
+
+int map_gpio(uint16_t gpio)
+{
+	int i;
+	unsigned long size=0x40;
+
+	for (i=0; i<size; i+=4) {
+		printf("gpiobase+0x%04x: 0x%08x\n", i, inl(gpio+i));
+	}
+
+	return 0;
+}
+
+int main(int argc, char *argv[])
+{
+	struct pci_access *pacc;
+	struct pci_dev *sb;
+	uint16_t gpiobadd;
+	uint16_t device;
+
+	if (iopl(3)) { 
+		perror("You need to be root.\n"); 
+		exit(1);
+	}
+
+	pacc = pci_alloc();
+	pci_init(pacc);
+	pci_scan_bus(pacc);
+
+	sb = pci_get_dev(pacc, 0, 0, 0x1f, 0);
+	if (!sb) {
+		printf("No southbridge found.\n");
+		exit(1);
+	}
+
+	if (pci_read_word(sb, 0) != 0x8086) {
+		printf("Not an Intel southbridge.\n");
+		exit(1);
+	}
+
+	printf("Intel Southbridge: %04x:%04x\n", 
+		pci_read_word(sb, 0), pci_read_word(sb, 2));
+
+	device = pci_read_word(sb, 2);
+
+	if (device < 0x2640) {
+		gpiobadd = pci_read_word(sb, 0x58) & 0xfffc; 
+	} else if (device >= 0x2640) {
+		gpiobadd = pci_read_word(sb, 0x48) & 0xfffc;
+	}
+	printf("GPIOBASE = 0x%04x\n\n", gpiobadd);
+
+	pci_free_dev(sb);
+	pci_cleanup(pacc);
+
+	map_gpio(gpiobadd);
+
+
+	return 0;
+}
Index: intel-debugtools/ich_gpio_dump/ich_gpio.8
===================================================================
--- intel-debugtools/ich_gpio_dump/ich_gpio.8	(revision 0)
+++ intel-debugtools/ich_gpio_dump/ich_gpio.8	(revision 0)
@@ -0,0 +1,59 @@
+.TH ICH_GPIO 8 "March 8, 2008"
+.SH NAME
+ich_gpio \- Intel southbridge GPIO Dump Utility
+.SH SYNOPSIS
+.B ich_gpio
+.SH DESCRIPTION
+.B ich_gpio 
+is a user-space utility which can dump all 
+register contents of the Intel ICH series Southbridges.
+.PP
+It is mainly used for coreboot development purposes (see coreboot.org
+for details on coreboot), but it may also be useful for other things.
+.PP
+Here is an example output:
+.br
+[root at localhost dumpgpio]# ich_gpio
+.br
+Intel Southbridge: 8086:24c0
+.br
+GPIOBASE = 0x0500
+.br
+gpiobase+0x0000: 0x1a003180
+.br
+gpiobase+0x0004: 0x0900ffff
+.br
+gpiobase+0x0008: 0x00000000
+.br
+gpiobase+0x000c: 0x1bbf0000
+.br
+gpiobase+0x0010: 0x00000000
+.br
+gpiobase+0x0014: 0x00000000
+.br
+gpiobase+0x0018: 0x00040000
+.br
+gpiobase+0x001c: 0x00000000
+.br
+gpiobase+0x0020: 0x00000000
+.br
+gpiobase+0x0024: 0x00000000
+.br
+gpiobase+0x0028: 0x00000000
+.br
+gpiobase+0x002c: 0x00003000
+.br
+gpiobase+0x0030: 0x00000fff
+.br
+gpiobase+0x0034: 0x00000e00
+.br
+gpiobase+0x0038: 0x00000fff
+.br
+gpiobase+0x003c: 0x00000000
+.PP
+Please consult your datasheet for the register meanings.
+.SH OPTIONS
+No command line options needed just run ich_gpio.
+.SH AUTHORS
+Please see the individual source code files.
+
Index: intel-debugtools/ich_gpio_dump/Makefile
===================================================================
--- intel-debugtools/ich_gpio_dump/Makefile	(revision 0)
+++ intel-debugtools/ich_gpio_dump/Makefile	(revision 0)
@@ -0,0 +1,62 @@
+#
+# Makefile for ich_gpio utility
+# 
+# (C) 2008 by coresystems GmbH
+# written by Stefan Reinauer <stepan at coresystems.de>
+# Copyright (C) 2008 Joseph Smith <joe at smittys.pointclark.net>
+#
+
+PROGRAM = ich_gpio
+
+CC = gcc
+STRIP	= strip
+INSTALL = /usr/bin/install
+PREFIX = /usr/local
+CFLAGS = -O2 -g -Wall
+OS_ARCH = $(shell uname)
+ifeq ($(OS_ARCH), SunOS)
+LDFLAGS = -lpci -lz
+else
+LDFLAGS = -lpci -lz -static 
+STRIP_ARGS = -s
+endif
+
+OBJS = ich_gpio.o
+
+all: pciutils dep $(PROGRAM)
+
+$(PROGRAM): $(OBJS)
+	$(CC) -o $(PROGRAM) $(OBJS) $(LDFLAGS)
+	$(STRIP) $(STRIP_ARGS) $(PROGRAM)
+
+clean:
+	rm -f *.o *~
+
+distclean: clean
+	rm -f $(PROGRAM) .dependencies
+	
+dep:
+	@$(CC) -MM *.c > .dependencies
+
+pciutils:
+	@echo; echo -n "Checking for pciutils and zlib... "
+	@$(shell ( echo "#include <pci/pci.h>";		   \
+		   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 &&	\
+		echo "found." || ( echo "not found."; echo;		\
+		echo "Please install pciutils-devel and zlib-devel.";	\
+		echo "See README for more information."; echo;		\
+		rm -f .test.c .test; exit 1)
+	@rm -f .test.c .test
+
+install: $(PROGRAM)
+	$(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 rminnich at gmail.com  Sun Mar  9 08:23:47 2008
From: rminnich at gmail.com (ron minnich)
Date: Sat, 8 Mar 2008 23:23:47 -0800
Subject: [coreboot] [PATCH]ich_gpio_dump util ACK?
In-Reply-To: <20080309030705.nure77cigco04ww0@www.smittys.pointclark.net>
References: <20080224120416.8bfhu8y74kkow808@www.smittys.pointclark.net>
	<47C486DF.7080903@gmx.net>
	<20080226180241.2vy3q1nm040sw04o@www.smittys.pointclark.net>
	<20080229203945.GA8306@coresystems.de>
	<20080308232049.yceuvfqvaysg8ssw@www.smittys.pointclark.net>
	<13426df10803082148g69e73abbvdaaed3e2a0230fe7@mail.gmail.com>
	<20080309030705.nure77cigco04ww0@www.smittys.pointclark.net>
Message-ID: <13426df10803082323n759e72d4w67ebbf101c92e85d@mail.gmail.com>

I should have been clearer.

+		perror("You need to be root.\n");

No, the issue here is the iopl failed. In many cases it will be "you
need to be root" but you can't be sure in all.

So you want this:

+		perror("Enabling IO ports via iopl(3)");

perror will take care of telling why; you need to let the user know
what the program
was trying to do.

Also, just FYI:
+	printf("GPIOBASE = 0x%04x\n\n", gpiobadd);
+
+	pci_free_dev(sb);
+	pci_cleanup(pacc);
+
+	map_gpio(gpiobadd);

It's clean coding style, but the pci_free_dev and pci_cleanup are not
really necessary ... your program is leaving right after the map_gpio,
and these operations are not doing anything that you need to. Plus, if
someone wants to add some more looking around in the