From MSamet at ea.com  Wed Mar  1 00:18:42 2006
From: MSamet at ea.com (Samet, Matt)
Date: Tue, 28 Feb 2006 15:18:42 -0800
Subject: [LinuxBIOS] does any one have access to the VT8237 docs
Message-ID: <9D3D7CEF3A236243AF0335652672E34805E05B89@maxis-mb1.max.ad.ea.com>

I looked online for a while and could not find the VT8237 datasheet.  I
tried asking VIA for the doc (they have a form you can fill out for the
NDA) but they didn't respond either.

I looked through the list archives and saw that Bari Ari was working on
adding support for the vt8237 -- Bari, any chance of an update?

Thanks,

-=matt

-----Original Message-----
From: linuxbios-bounces at linuxbios.org
[mailto:linuxbios-bounces at linuxbios.org] On Behalf Of Adam Talbot
Sent: Tuesday, February 28, 2006 1:51 PM
To: linuxbios at linuxbios.org
Subject: [LinuxBIOS] does any one have access to the VT8237 docs

Still trying to get my EBC3266 board to post with linux bios.  That 
board is based on the VT8623 and VT8237 chips.  I currently am unable to

get any console.  I would guess that is because I am unable to start the

south bridge, where the vt1211 is attached. I was hoping that is was 
close enughf to the VT8235, but I guess I am wrong.  OK, time to start 
trying to add support for the VT8237 south bridge.  Does any one have 
access to the Docs for the VT8237?
-Adam Talbot

-- 
linuxbios mailing list
linuxbios at linuxbios.org
http://www.openbios.org/mailman/listinfo/linuxbios




From talbotx at comcast.net  Wed Mar  1 00:33:31 2006
From: talbotx at comcast.net (Adam Talbot)
Date: Tue, 28 Feb 2006 15:33:31 -0800
Subject: [LinuxBIOS] does any one have access to the VT8237 docs
In-Reply-To: <9D3D7CEF3A236243AF0335652672E34805E05B89@maxis-mb1.max.ad.ea.com>
References: <9D3D7CEF3A236243AF0335652672E34805E05B89@maxis-mb1.max.ad.ea.com>
Message-ID: <4404DDCB.9010303@comcast.net>

-Matt
Steve G was able to provide me with the correct doc.
-Adam Talbot

Samet, Matt wrote:

>I looked online for a while and could not find the VT8237 datasheet.  I
>tried asking VIA for the doc (they have a form you can fill out for the
>NDA) but they didn't respond either.
>
>I looked through the list archives and saw that Bari Ari was working on
>adding support for the vt8237 -- Bari, any chance of an update?
>
>Thanks,
>
>-=matt
>
>-----Original Message-----
>From: linuxbios-bounces at linuxbios.org
>[mailto:linuxbios-bounces at linuxbios.org] On Behalf Of Adam Talbot
>Sent: Tuesday, February 28, 2006 1:51 PM
>To: linuxbios at linuxbios.org
>Subject: [LinuxBIOS] does any one have access to the VT8237 docs
>
>Still trying to get my EBC3266 board to post with linux bios.  That 
>board is based on the VT8623 and VT8237 chips.  I currently am unable to
>
>get any console.  I would guess that is because I am unable to start the
>
>south bridge, where the vt1211 is attached. I was hoping that is was 
>close enughf to the VT8235, but I guess I am wrong.  OK, time to start 
>trying to add support for the VT8237 south bridge.  Does any one have 
>access to the Docs for the VT8237?
>-Adam Talbot
>
>  
>




From leonw at mailcan.com  Wed Mar  1 19:19:05 2006
From: leonw at mailcan.com (Leon Woestenberg)
Date: Wed, 01 Mar 2006 19:19:05 +0100
Subject: [LinuxBIOS] FILO: via_sound.c
Message-ID: <4405E599.9000001@mailcan.com>

Hello,

who developed the VIA sound support for FILO?
who has used it to output sound on a VIA board?

The current code seems to mute the device only, although there seems #if 
0 - #endif code in place to loop through a 16-bit DMA sample?

I would like to continue this work (using AC97 specs and whatever VIA 
doc is available) or at least hack with it a bit...

Regards,

Leon.



From stepan at coresystems.de  Wed Mar  1 19:42:27 2006
From: stepan at coresystems.de (Stefan Reinauer)
Date: Wed, 1 Mar 2006 19:42:27 +0100
Subject: [LinuxBIOS] FILO: via_sound.c
In-Reply-To: <4405E599.9000001@mailcan.com>
References: <4405E599.9000001@mailcan.com>
Message-ID: <20060301184227.GA29271@openbios.org>

* Leon Woestenberg <leonw at mailcan.com> [060301 19:19]:
> Hello,
> 
> who developed the VIA sound support for FILO?
> who has used it to output sound on a VIA board?
> 
> The current code seems to mute the device only, although there seems #if 
> 0 - #endif code in place to loop through a 16-bit DMA sample?
> 
> I would like to continue this work (using AC97 specs and whatever VIA 
> doc is available) or at least hack with it a bit...

SONE Takeshi <ts1 at tsn.or.jp> was the original author of this code. But I
mostly took over FILO maintenance and development with Takeshis
agreement.

If you want to add something, drop me a note (with patch preferred ;)

Regards,
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/



From okajima at digitalinfra.co.jp  Thu Mar  2 08:22:54 2006
From: okajima at digitalinfra.co.jp (Jun OKAJIMA)
Date: Thu, 02 Mar 2006 16:22:54 +0900
Subject: [LinuxBIOS] MACH BOOT
Message-ID: <200603020722.AA00729@bbb-jz5c7z9hn9y.digitalinfra.co.jp>



Hello. 
Check this out, please.
http://www.machboot.com/

This is the reason I have been sticking on fast booting BIOS.
Now, Linux boots within 10sec. But whole booting process
from power-on needs about 30 sec.

Yes, the biggest bottle neck is BIOS. and CD drive firmware also.
And this is the reason I have interest about this LinuxBIOS project.
Thanks, all.

BUT, MY EPIA-M STILL DOES NOT BOOT.......sigh.

                     --- Okajima, Jun. Tokyo, Japan.




From jardel at lesc.ufc.br  Thu Mar  2 15:54:21 2006
From: jardel at lesc.ufc.br (jardel)
Date: Thu, 02 Mar 2006 11:54:21 -0300
Subject: [LinuxBIOS] RES:  RES:  Rumba target and AMD RDK THINCLIENT
In-Reply-To: <1141064948.19385.51.camel@logarithm.lanl.gov>
References: <200602241929.k1OJSxT6009241@proofpoint2.lanl.gov>
	<1141064948.19385.51.camel@logarithm.lanl.gov>
Message-ID: <4407071D.8020602@lesc.ufc.br>

Dear Li-Ta Lo,


   I've just downloaded now the last version from svn. The make is 
reporting this output:




auto.c:13.0:
Cannot open `southbridge/amd/cs5535/cs5535_early_smbus.c'

make[1]: ** [auto.inc] Erro 1
make[1]: Leaving directory 
`/home/jardel/projetos/temp/LinuxBIOSv2/targets/amd/rumba/rumba/normal'
make: ** [normal/linuxbios.rom] Erro 1
jardel at jardel:~/projetos/temp/LinuxBIOSv2/targets/amd/rumba/rumba$  


Thanks.


Jardel.



Li-Ta Lo wrote:

>On Fri, 2006-02-24 at 16:28 -0300, Jardel Silveira wrote:
>  
>
>>Dear Li-Ta Lo,
>>
>>
>>	I?ve just tried to compile rumba now and i?ve got this ouput?
>>
>>N_OFFSET='0x0' -DXIP_ROM_SIZE='0x10000' -DXIP_ROM_BASE='0xfffd0000'
>>-DCONFIG_UDELAY_TSC='1' -DCONFIG_TSC_X86RDTSC_CALIBRATE_WITH_TIMER2='0'
>>-DCONFIG_UDELAY_IO='0'
>>/home/jardel/projetos/LinuxBIOSv2/src/mainboard/amd/rumba/auto.c -o auto.inc
>>raminit.c:3.61:
>>struct mem_controller undeclared
>>make[1]: ** [auto.inc] Erro 1
>>make[1]: Leaving directory
>>`/home/jardel/projetos/LinuxBIOSv2/targets/amd/rumba/rumba/normal'
>>make: ** [normal/linuxbios.rom] Erro 1
>>jardel at jardel:~/projetos/LinuxBIOSv2/targets/amd/rumba/rumba$ ls
>>
>>
>>    
>>
>
>I just committed other part of the change. Could you try it again?
>
>  
>




From stepan at openbios.org  Thu Mar  2 17:23:50 2006
From: stepan at openbios.org (Stefan Reinauer)
Date: Thu, 2 Mar 2006 17:23:50 +0100
Subject: [LinuxBIOS] AMD64 serial setup
Message-ID: <20060302162350.GB8644@openbios.org>

Hi,

I have a really weird problem on some amd64 machines running LinuxBIOS
(agami/aruma). The serial port doesn't seem to get initialized correctly.

LB seems to report it correctly in debug output (4 and 3 are normal):

PNP: 002e.2 60 <- [0x00000003f8 - 0x00000003ff] io
PNP: 002e.2 70 <- [0x0000000004 - 0x0000000004] irq
PNP: 002e.3 60 <- [0x00000002f8 - 0x00000002ff] io
PNP: 002e.3 70 <- [0x0000000003 - 0x0000000003] irq

but Linux doesn't set it up right - in fact, Linux sets it up *differently*
on occasion...

# grep ttyS.*irq messages
Feb 28 15:11:36 testnode kernel: ttyS0 at I/O 0x3f8 (irq = 0) is a 16550A
Feb 28 15:11:36 testnode kernel: ttyS1 at I/O 0x2f8 (irq = 0) is a 16550A
Feb 28 15:14:53 testnode kernel: ttyS0 at I/O 0x3f8 (irq = 0) is a 16550A
Feb 28 15:14:53 testnode kernel: ttyS1 at I/O 0x2f8 (irq = 4) is a 16550A
Feb 28 15:23:24 testnode kernel: ttyS0 at I/O 0x3f8 (irq = 0) is a 16550A
Feb 28 15:23:24 testnode kernel: ttyS1 at I/O 0x2f8 (irq = 4) is a 16550A
Feb 28 15:38:58 testnode kernel: ttyS0 at I/O 0x3f8 (irq = 0) is a 16550A
Feb 28 15:38:58 testnode kernel: ttyS1 at I/O 0x2f8 (irq = 4) is a 16550A
Feb 28 15:47:21 testnode kernel: ttyS0 at I/O 0x3f8 (irq = 0) is a 16550A
Feb 28 15:47:21 testnode kernel: ttyS1 at I/O 0x2f8 (irq = 0) is a 16550A
Feb 28 16:29:34 testnode kernel: ttyS0 at I/O 0x3f8 (irq = 0) is a 16550A
Feb 28 16:29:34 testnode kernel: ttyS1 at I/O 0x2f8 (irq = 4) is a 16550A
Feb 28 16:37:18 testnode kernel: ttyS0 at I/O 0x3f8 (irq = 0) is a 16550A
Feb 28 16:37:18 testnode kernel: ttyS1 at I/O 0x2f8 (irq = 4) is a 16550A
Feb 28 17:11:02 testnode kernel: ttyS0 at I/O 0x3f8 (irq = 0) is a 16550A
Feb 28 17:11:02 testnode kernel: ttyS1 at I/O 0x2f8 (irq = 4) is a 16550A
Feb 28 18:14:49 testnode kernel: ttyS0 at I/O 0x3f8 (irq = 0) is a 16550A
Feb 28 18:14:49 testnode kernel: ttyS1 at I/O 0x2f8 (irq = 4) is a 16550A


AMIBIOS:

Jan  3 14:34:39 testnode kernel: ttyS0 at I/O 0x3f8 (irq = 4) is a 16550A
Jan  3 14:34:39 testnode kernel: ttyS1 at I/O 0x2f8 (irq = 3) is a 16550A
Jan  3 16:18:45 testnode kernel: ttyS0 at I/O 0x3f8 (irq = 4) is a 16550A
Jan  3 16:18:45 testnode kernel: ttyS1 at I/O 0x2f8 (irq = 3) is a 16550A
Jan  3 18:22:20 testnode kernel: ttyS0 at I/O 0x3f8 (irq = 4) is a 16550A
Jan  3 18:22:20 testnode kernel: ttyS1 at I/O 0x2f8 (irq = 3) is a 16550A
Jan  3 18:29:46 testnode kernel: ttyS0 at I/O 0x3f8 (irq = 4) is a 16550A
Jan  3 18:29:46 testnode kernel: ttyS1 at I/O 0x2f8 (irq = 3) is a 16550A
Jan  4 00:11:21 testnode kernel: ttyS0 at I/O 0x3f8 (irq = 4) is a 16550A
Jan  4 00:11:21 testnode kernel: ttyS1 at I/O 0x2f8 (irq = 3) is a 16550A

Any idea why and how that could happen?

   Stefan



From rminnich at lanl.gov  Thu Mar  2 17:42:37 2006
From: rminnich at lanl.gov (Ronald G Minnich)
Date: Thu, 02 Mar 2006 09:42:37 -0700
Subject: [LinuxBIOS] Success report on VIA EPIA-M10000
In-Reply-To: <43FFB5D4.8020006@mailcan.com>
References: <43FFB5D4.8020006@mailcan.com>
Message-ID: <4407207D.1040802@lanl.gov>

I realize we should do a pci class, but this fix ought to work.

Leon, can you test?

[rminnich at q epia-m]$ svn diff mainboard.c
Index: mainboard.c
===================================================================
--- mainboard.c (revision 2188)
+++ mainboard.c (working copy)
@@ -30,6 +30,11 @@
         device_t dev;

         printk_info("write_protect_vgabios\n");
+       /* there are two possible devices. Just do both. */
+       dev = dev_find_device(PCI_VENDOR_ID_VIA, 0x3122, 0);
+       if(dev)
+               pci_write_config8(dev, 0x61, 0xaa);
+
         dev = dev_find_device(PCI_VENDOR_ID_VIA, 0x3123, 0);
         if(dev)
                 pci_write_config8(dev, 0x61, 0xaa);


ron



From yinghai.lu at amd.com  Thu Mar  2 17:50:44 2006
From: yinghai.lu at amd.com (Lu, Yinghai)
Date: Thu, 2 Mar 2006 08:50:44 -0800
Subject: [LinuxBIOS] AMD64 serial setup
Message-ID: <6F7DA19D05F3CF40B890C7CA2DB13A4203094A86@ssvlexmb2.amd.com>

I knew the problem, and still didn't find the root cause for that.

That happens on 8132/8111 system. (But it works well 8131/8111.)

You have to turn irq for serial port auto detect to make serial port
working...( get serial terminal...) and the console is some slow...

YH





From rminnich at lanl.gov  Thu Mar  2 17:47:11 2006
From: rminnich at lanl.gov (Ronald G Minnich)
Date: Thu, 02 Mar 2006 09:47:11 -0700
Subject: [LinuxBIOS] MACH BOOT
In-Reply-To: <200603020722.AA00729@bbb-jz5c7z9hn9y.digitalinfra.co.jp>
References: <200603020722.AA00729@bbb-jz5c7z9hn9y.digitalinfra.co.jp>
Message-ID: <4407218F.1030909@lanl.gov>

Jun OKAJIMA wrote:
> 
> Hello. 
> Check this out, please.
> http://www.machboot.com/
> 
> This is the reason I have been sticking on fast booting BIOS.
> Now, Linux boots within 10sec. But whole booting process
> from power-on needs about 30 sec.
> 
> Yes, the biggest bottle neck is BIOS. and CD drive firmware also.
> And this is the reason I have interest about this LinuxBIOS project.
> Thanks, all.
> 
> BUT, MY EPIA-M STILL DOES NOT BOOT.......sigh.
> 
>                      --- Okajima, Jun. Tokyo, Japan.
> 
> 

Mr. Okajima, we have recent reports of an Epia-m working. Could you try 
again. The working version is 2184. I would like to resolve this question.

Also, folks, I have talked to Stefan about this and we are going to 
start trying to offer binary images for people, so they don't have to 
build their own bios all the time. More on this later.

thanks

ron



From stepan at openbios.org  Thu Mar  2 19:44:13 2006
From: stepan at openbios.org (Stefan Reinauer)
Date: Thu, 2 Mar 2006 19:44:13 +0100
Subject: [LinuxBIOS] AMD64 serial setup
In-Reply-To: <6F7DA19D05F3CF40B890C7CA2DB13A4203094A86@ssvlexmb2.amd.com>
References: <6F7DA19D05F3CF40B890C7CA2DB13A4203094A86@ssvlexmb2.amd.com>
Message-ID: <20060302184413.GA16475@openbios.org>

* Lu, Yinghai <yinghai.lu at amd.com> [060302 17:50]:
> I knew the problem, and still didn't find the root cause for that.
> 
> That happens on 8132/8111 system. (But it works well 8131/8111.)

Weird. This is on an 8131/8111 system and it works fine on all 8132
counterparts.

> You have to turn irq for serial port auto detect to make serial port
> working...( get serial terminal...) and the console is some slow...
 
As in: CONFIG_SERIAL_8250_DETECT_IRQ? This is already switched on.

The console is also overrunning now and then, but I assume this is the
result of the missing IRQ. 

It seems to happen with 16G+ memory only, but I need to verify this
further.

Stefan
 



From miernik at ffii.org  Fri Mar  3 07:20:08 2006
From: miernik at ffii.org (Miernik)
Date: Fri, 3 Mar 2006 07:20:08 +0100
Subject: [LinuxBIOS] looking for a Slot1 or PGA370 motherboard recommendation
Message-ID: <20060303062008.10A4.8.NOFFLE@localhost.localdomain.local>

I am looking for a motherboard recommendation with the following features:

* at least one Slot-1 or PGA370 CPU socket, that I can put a VIA C5P
  Nehemiah CPU in it (PGA370 version), however I would prefer Slot-1
  mainboard for easier mounting of the heatsink away from the motherboard,
  without risk of damaging the motherboard while mounting the heatsink (I
  damaged one motherboard while doing this on a PGA socket)

* at least 5 PCI slots, at least PCI 2.0, faster versions welcome

* at least 1 ISA slot

* support 200 MHz FSB

* support DDR400 RAM in 1 GB DIMM modules - if that requires some
  LinuxBIOS hacking that's OK, I just want to avoid a a motherboard with
  something that definetly rules out 1 GB sticks because of some
  not-to-circumvent hardware limitations; I would appreciate 4 DIMM
  slots to fit 4 GB of RAM, however 3 GB will also be OK, and 2 slots
  will do if there is a chance of fillting future 2 GB DIMM sticks in them

* a chipset which is at least been supported in any version of LinuxBIOS,
  may be v1, which gives a chance to be supported in v2 after some
  hacking, I just want to avoid chipsets which never ever been
  supported, and has no available docs, giving no chance for support;
  the motherboard as a whole doesn't have to be supported, I am willing
  to do some minor hacking to fix some glitches, just not write support
  for a completely new chipset. So Intel BX and LX are OK I think. Any
  other PGA370 chipsets ever been supported by LinuxBIOS? Any VIA stuff
  used in non-EPIA, but ATX motherboards with sockets?

* USB 2.0 sockets welcome

Any chance to meet all or almost all of these requirements?
i just need 1 piece, so it may be of course an out-of-production
motherboard, even a rare one, that there is a chance of getting after
several weeks of hunting on eBay.

-- 
Miernik             _________________________  xmpp:miernik at amessage.info
___________________/_______________________/      mailto:miernik at ffii.org
Protect Europe from a legal disaster. Petition against software patents
http://www.noepatents.org/index_html?LANG=en




From pdj at knaldgas.dk  Fri Mar  3 17:42:54 2006
From: pdj at knaldgas.dk (Per Dalgas Jakobsen)
Date: Fri, 03 Mar 2006 17:42:54 +0100
Subject: [LinuxBIOS] Lippert Cool Roadrunner 2 (GX1)
Message-ID: <1141404174.15367.32.camel@pdj.knaldgas.dk>

Hi all,

At last... Finally I have had time to look at LinuxBIOS...
I have been playing around with Etherboot and Filo for booting a
development target, making good progress.

Up to now I have managed to add Etherboot to the original BIOS and have
it working fine.

But now I want to LinuxBIOS my system ;-)

I have a Lippert Cool Roadrunner II with 64MB memory and a 128MB
CompactFlash for disk, and I have tried to use LinuxBIOS v1 with its
support for this board, but no success.

The serial port is very quite, and unfortunately I have no POST card. I
have verified the serial connection: Linux on target "$ echo Hello
>/dev/ttyS0" gives a nice "Hello" on the receiving end (no handshakes),
so something seems odd with the LinuxBIOS image...

Host is i686-Linux using gcc-4.0.3

--- config ------------
target /home/pdj/tuxway/builds/roadrunner2
mainboard lippert/roadrunner2

# Enable Serial Console for debugging
option SERIAL_CONSOLE=1
option TTYS0_BAUD=57600

option DEFAULT_CONSOLE_LOGLEVEL=9
option DEBUG=1

option RAMTEST=1
option USE_GENERIC_ROM=1
option USE_ELF_BOOT=1
option ROM_SIZE=262144
option STD_FLASH=1

payload ~/tuxway/etherboot-5.0.6/src/bin32/eepro100.elf

option PAYLOAD_SIZE=196608
---------------

I've hexdump'd the resulting romimage, and it looks fine as far as I can
tell: (jmp far 0xf000:0x0004 at address 0x0003fff0, and payload image
starting at 0x00000000).

I've used the flashrom from LinuxBIOSv2-2191 for burning:
"# flashrom -w romimage"


Anyone able to give me a clue of what I've missed?

Anyone had success with LinuxBIOSv2 on a Roadrunner2 ?


~Per
-----------------

PS:
---
My ultimate goal is fast boot to either a remote image (through
Etherboot) or a local linux on CompactFlash (filo and ext2).

My plan was to use LinuxBIOS with a combined filo and etherboot image as
payload.
Like this:
0x000000 FILO
0x010000 ETHERBOOT
0x030000 LINUXBIOS
0x040000
---
I have already modified filo so an external switch can select the
boot-method.





From leonw at mailcan.com  Sat Mar  4 15:04:04 2006
From: leonw at mailcan.com (Leon Woestenberg)
Date: Sat, 04 Mar 2006 15:04:04 +0100
Subject: [LinuxBIOS] Success report on VIA EPIA-M10000
In-Reply-To: <4407207D.1040802@lanl.gov>
References: <43FFB5D4.8020006@mailcan.com> <4407207D.1040802@lanl.gov>
Message-ID: <44099E54.9000907@mailcan.com>

Hello Ronald,

Ronald G Minnich wrote:
> I realize we should do a pci class, but this fix ought to work.
>
> Leon, can you test?
Yes, the fix works.

Regards,

Leon.

>
> [rminnich at q epia-m]$ svn diff mainboard.c
> Index: mainboard.c
> ===================================================================
> --- mainboard.c (revision 2188)
> +++ mainboard.c (working copy)
> @@ -30,6 +30,11 @@
>         device_t dev;
>
>         printk_info("write_protect_vgabios\n");
> +       /* there are two possible devices. Just do both. */
> +       dev = dev_find_device(PCI_VENDOR_ID_VIA, 0x3122, 0);
> +       if(dev)
> +               pci_write_config8(dev, 0x61, 0xaa);
> +
>         dev = dev_find_device(PCI_VENDOR_ID_VIA, 0x3123, 0);
>         if(dev)
>                 pci_write_config8(dev, 0x61, 0xaa);
>
>
> ron




From rminnich at lanl.gov  Sat Mar  4 19:13:53 2006
From: rminnich at lanl.gov (Ronald G Minnich)
Date: Sat, 04 Mar 2006 11:13:53 -0700
Subject: [LinuxBIOS] Success report on VIA EPIA-M10000
In-Reply-To: <44099E54.9000907@mailcan.com>
References: <43FFB5D4.8020006@mailcan.com> <4407207D.1040802@lanl.gov>
	<44099E54.9000907@mailcan.com>
Message-ID: <4409D8E1.8070701@lanl.gov>

one last request: can you give us exact details of who you ordered your 
system from, part #s, etc? I want to make it very easy for people to get 
this working.

thanks again

ron



From stepan at openbios.org  Sun Mar  5 19:43:47 2006
From: stepan at openbios.org (Stefan Reinauer)
Date: Sun, 5 Mar 2006 19:43:47 +0100
Subject: [LinuxBIOS] AMD64 serial setup
In-Reply-To: <20060302162350.GB8644@openbios.org>
References: <20060302162350.GB8644@openbios.org>
Message-ID: <20060305184347.GA4097@openbios.org>

* Stefan Reinauer <stepan at openbios.org> [060302 17:23]:
> # grep ttyS.*irq messages
> Feb 28 15:11:36 testnode kernel: ttyS0 at I/O 0x3f8 (irq = 0) is a 16550A
> Feb 28 15:11:36 testnode kernel: ttyS1 at I/O 0x2f8 (irq = 0) is a 16550A
> Feb 28 18:14:49 testnode kernel: ttyS0 at I/O 0x3f8 (irq = 0) is a 16550A
> Feb 28 18:14:49 testnode kernel: ttyS1 at I/O 0x2f8 (irq = 4) is a 16550A
> 
> AMIBIOS:
> 
> Jan  3 14:34:39 testnode kernel: ttyS0 at I/O 0x3f8 (irq = 4) is a 16550A
> Jan  3 14:34:39 testnode kernel: ttyS1 at I/O 0x2f8 (irq = 3) is a 16550A
> Jan  3 18:29:46 testnode kernel: ttyS0 at I/O 0x3f8 (irq = 4) is a 16550A
> Jan  3 18:29:46 testnode kernel: ttyS1 at I/O 0x2f8 (irq = 3) is a 16550A
> 
> Any idea why and how that could happen?
 
Ok, here's some details:

The systems which are causing problems all have a

   W83627HF revision ID = 0x17

The OK systems with linuxbios all have:

   W83627HF revision ID = 0x41

Unfortunately there does not seem to be a revision guide on the winbond
website. Any ideas anyone?

  Stefan



From stepan at openbios.org  Sun Mar  5 19:49:29 2006
From: stepan at openbios.org (Stefan Reinauer)
Date: Sun, 5 Mar 2006 19:49:29 +0100
Subject: [LinuxBIOS] AMD64 serial setup
In-Reply-To: <20060305184347.GA4097@openbios.org>
References: <20060302162350.GB8644@openbios.org>
	<20060305184347.GA4097@openbios.org>
Message-ID: <20060305184929.GB6295@openbios.org>

* Stefan Reinauer <stepan at openbios.org> [060305 19:43]:
> The systems which are causing problems all have a
> 
>    W83627HF revision ID = 0x17
> 
> The OK systems with linuxbios all have:
> 
>    W83627HF revision ID = 0x41
> 
> Unfortunately there does not seem to be a revision guide on the winbond
> website. Any ideas anyone?

The only information I could find:
the W83627HF data sheet says:

Version | Device Rev
--------+-----------
    G   |     17
    J   |     3A
  UD-A  |     41

(http://www.winbond.com/e-winbondhtm/partner/PDFResult.asp?Pname=182)

Stefan






From rminnich at lanl.gov  Sun Mar  5 20:54:27 2006
From: rminnich at lanl.gov (Ronald G Minnich)
Date: Sun, 05 Mar 2006 12:54:27 -0700
Subject: [LinuxBIOS] AMD64 serial setup
In-Reply-To: <20060305184929.GB6295@openbios.org>
References: <20060302162350.GB8644@openbios.org>	<20060305184347.GA4097@openbios.org>
	<20060305184929.GB6295@openbios.org>
Message-ID: <440B41F3.90600@lanl.gov>

Stefan Reinauer wrote:
> * Stefan Reinauer <stepan at openbios.org> [060305 19:43]:
> 
>>The systems which are causing problems all have a
>>
>>   W83627HF revision ID = 0x17
>>
>>The OK systems with linuxbios all have:
>>
>>   W83627HF revision ID = 0x41
>>
>>Unfortunately there does not seem to be a revision guide on the winbond
>>website. Any ideas anyone?
> 
> 
> The only information I could find:
> the W83627HF data sheet says:
> 
> Version | Device Rev
> --------+-----------
>     G   |     17
>     J   |     3A
>   UD-A  |     41
> 
> (http://www.winbond.com/e-winbondhtm/partner/PDFResult.asp?Pname=182)
> 
> Stefan
> 
> 
> 
> 

sorry, I have not been following this one closely. Given that you can 
differentiate the chips, is there some workaround you can force in at 
bios time? How does one fix this?

ron



From stepan at openbios.org  Sun Mar  5 21:17:13 2006
From: stepan at openbios.org (Stefan Reinauer)
Date: Sun, 5 Mar 2006 21:17:13 +0100
Subject: [LinuxBIOS] AMD64 serial setup
In-Reply-To: <440B41F3.90600@lanl.gov>
References: <20060302162350.GB8644@openbios.org>
	<20060305184347.GA4097@openbios.org>
	<20060305184929.GB6295@openbios.org> <440B41F3.90600@lanl.gov>
Message-ID: <20060305201713.GA11650@openbios.org>

* Ronald G Minnich <rminnich at lanl.gov> [060305 20:54]:
> >The only information I could find:
> >the W83627HF data sheet says:
> >
> >Version | Device Rev
> >--------+-----------
> >    G   |     17
> >    J   |     3A
> >  UD-A  |     41
> >
> >(http://www.winbond.com/e-winbondhtm/partner/PDFResult.asp?Pname=182)
> 
> sorry, I have not been following this one closely. Given that you can 
> differentiate the chips, is there some workaround you can force in at 
> bios time? How does one fix this?
 
I have no idea whether it can be fixed at bios time. I think it worked
after running setserial on the device at linux runtime, but it did not
seem to need that running AMI bios, so it'd be nice to find some sort of
bios workaround here. I asked Winbond for a revision guide, but I doubt
I ever get an answer.

Stefan

 



From stuge-linuxbios at cdy.org  Mon Mar  6 00:05:47 2006
From: stuge-linuxbios at cdy.org (Peter Stuge)
Date: Mon, 6 Mar 2006 00:05:47 +0100
Subject: [LinuxBIOS] AMD64 serial setup
In-Reply-To: <20060305201713.GA11650@openbios.org>
References: <20060302162350.GB8644@openbios.org>
	<20060305184347.GA4097@openbios.org>
	<20060305184929.GB6295@openbios.org> <440B41F3.90600@lanl.gov>
	<20060305201713.GA11650@openbios.org>
Message-ID: <20060305230548.9062.qmail@cdy.org>

On Sun, Mar 05, 2006 at 09:17:13PM +0100, Stefan Reinauer wrote:
> I have no idea whether it can be fixed at bios time. I think it
> worked after running setserial on the device at linux runtime, but
> it did not seem to need that running AMI bios, so it'd be nice to
> find some sort of bios workaround here. I asked Winbond for a
> revision guide, but I doubt I ever get an answer.

What about chipset erratas? Sometimes they document really
interesting hardware bugs.


//Peter



From miernik at ffii.org  Mon Mar  6 08:52:26 2006
From: miernik at ffii.org (Miernik)
Date: Mon, 6 Mar 2006 08:52:26 +0100
Subject: [LinuxBIOS] RAM organization - can 8 16Mbx16 chips give a
	single-rank 32Mbx64 DIMM?
Message-ID: <20060306075226.1082.0.NOFFLE@localhost.localdomain.local>

I have a DDR266 SO-DIMM module with 8 chips on it. I only know the specs
on the chips, they are 16Mb x 16 organization. I don't know the specs of
the whole module, there isn't even a model number.

I want to know the organization of the whole module.
Is it a dual-rank ("double-sided") module with 16Mb x 64 in each rank?
Or is it a single-rank ("single-sided") module with 32Mb x 64
organization?

Is the latter at all possible?
If yes, how to tell the difference by looking at the module?

The reason I ask, is that
http://transmeta.com/crusoe_docs/TM5800v1.0_DataBook_030206.pdf
on page 19 states that the memory controller supports only 1 rank with
DDR. That limitation doesn't apply to SDR controller or to DDR
controller on version 2.1 chips - page 21 on
http://transmeta.com/crusoe_docs/TM5800v2.1_databook_030922.pdf

I have a 5800A073310 chip, and I would like to know if that DDR module
should work with it or not. And also will a 1 GB DDR module work with
it. With v1.0 documentation it appears that not, but with v2.1 on page
23 it lists a 1024 MB DDR configuration with two ranks, is it possible
that v1.0 will somehow support it, only the docs didn't list it?

The module in question is here:
http://217.17.47.111/items/SMART_TM2V16M1618U-4/SMART_TM2V16M1618U-4.front.jpeg
http://217.17.47.111/items/SMART_TM2V16M1618U-4/SMART_TM2V16M1618U-4.back.jpeg

-- 
Miernik             _________________________  xmpp:miernik at amessage.info
___________________/_______________________/      mailto:miernik at ffii.org
Protect Europe from a legal disaster. Petition against software patents
http://www.noepatents.org/index_html?LANG=en




From yinghai.lu at amd.com  Mon Mar  6 18:13:09 2006
From: yinghai.lu at amd.com (Lu, Yinghai)
Date: Mon, 6 Mar 2006 09:13:09 -0800
Subject: [LinuxBIOS] RAM organization - can 8 16Mbx16 chips give a
 single-rank 32Mbx64 DIMM?
Message-ID: <6F7DA19D05F3CF40B890C7CA2DB13A4203094A9A@ssvlexmb2.amd.com>

You can read the SPD ROM data on other Machine. And then check the value
according the DDR spd sepc.

YH

-----Original Message-----
From: linuxbios-bounces at linuxbios.org
[mailto:linuxbios-bounces at linuxbios.org] On Behalf Of Miernik
Sent: Sunday, March 05, 2006 11:52 PM
To: linuxbios at openbios.org
Subject: [LinuxBIOS] RAM organization - can 8 16Mbx16 chips give a
single-rank 32Mbx64 DIMM?

I have a DDR266 SO-DIMM module with 8 chips on it. I only know the specs
on the chips, they are 16Mb x 16 organization. I don't know the specs of
the whole module, there isn't even a model number.

I want to know the organization of the whole module.
Is it a dual-rank ("double-sided") module with 16Mb x 64 in each rank?
Or is it a single-rank ("single-sided") module with 32Mb x 64
organization?

Is the latter at all possible?
If yes, how to tell the difference by looking at the module?

The reason I ask, is that
http://transmeta.com/crusoe_docs/TM5800v1.0_DataBook_030206.pdf
on page 19 states that the memory controller supports only 1 rank with
DDR. That limitation doesn't apply to SDR controller or to DDR
controller on version 2.1 chips - page 21 on
http://transmeta.com/crusoe_docs/TM5800v2.1_databook_030922.pdf

I have a 5800A073310 chip, and I would like to know if that DDR module
should work with it or not. And also will a 1 GB DDR module work with
it. With v1.0 documentation it appears that not, but with v2.1 on page
23 it lists a 1024 MB DDR configuration with two ranks, is it possible
that v1.0 will somehow support it, only the docs didn't list it?

The module in question is here:
http://217.17.47.111/items/SMART_TM2V16M1618U-4/SMART_TM2V16M1618U-4.fro
nt.jpeg
http://217.17.47.111/items/SMART_TM2V16M1618U-4/SMART_TM2V16M1618U-4.bac
k.jpeg

-- 
Miernik             _________________________
xmpp:miernik at amessage.info
___________________/_______________________/
mailto:miernik at ffii.org
Protect Europe from a legal disaster. Petition against software patents
http://www.noepatents.org/index_html?LANG=en


-- 
linuxbios mailing list
linuxbios at linuxbios.org
http://www.openbios.org/mailman/listinfo/linuxbios





From miernik at ffii.org  Mon Mar  6 21:38:56 2006
From: miernik at ffii.org (Miernik)
Date: Mon, 6 Mar 2006 21:38:56 +0100
Subject: [LinuxBIOS] anyone with access to the VT8231 docs?
Message-ID: <20060306203856.1082.5.NOFFLE@localhost.localdomain.local>

I tried some webform on VIA website, but noone got back to me. Maybe
some good soul here can send the PDF to me?

-- 
Miernik             _________________________  xmpp:miernik at amessage.info
___________________/_______________________/      mailto:miernik at ffii.org
Why software shouldn't be covered by patents
http://bladeenc.mp3.no/articles/software_patents.html




From ragnar at hansarinne.fi  Mon Mar  6 22:30:48 2006
From: ragnar at hansarinne.fi (Ragnar Hansson)
Date: Mon, 06 Mar 2006 23:30:48 +0200
Subject: [LinuxBIOS] anyone with access to the VT8231 docs?
In-Reply-To: <20060306203856.1082.5.NOFFLE@localhost.localdomain.local>
References: <20060306203856.1082.5.NOFFLE@localhost.localdomain.local>
Message-ID: <440CAA08.1020504@hansarinne.fi>

If you search google with vt8231.pdf you will get the datasheet.
Google is great if you happen to know the exect name of the file.

Ragnar.

Miernik wrote:
> I tried some webform on VIA website, but noone got back to me. Maybe
> some good soul here can send the PDF to me?
> 




From stepan at coresystems.de  Tue Mar  7 14:17:56 2006
From: stepan at coresystems.de (Stefan Reinauer)
Date: Tue, 7 Mar 2006 14:17:56 +0100
Subject: [LinuxBIOS] AMD64 serial setup
In-Reply-To: <440B41F3.90600@lanl.gov>
References: <20060302162350.GB8644@openbios.org>
	<20060305184347.GA4097@openbios.org>
	<20060305184929.GB6295@openbios.org> <440B41F3.90600@lanl.gov>
Message-ID: <20060307131756.GA14276@openbios.org>

* Ronald G Minnich <rminnich at lanl.gov> [060305 20:54]:
> Stefan Reinauer wrote:
> >
> >>The systems which are causing problems all have a
> >>
> >>  W83627HF revision ID = 0x17
> >>
> >>The OK systems with linuxbios all have:
> >>
> >>  W83627HF revision ID = 0x41
> >>
> >>Unfortunately there does not seem to be a revision guide on the winbond
> >>website. Any ideas anyone?
> >
> >
> >The only information I could find:
> >the W83627HF data sheet says:
> >
> >Version | Device Rev
> >--------+-----------
> >    G   |     17
> >    J   |     3A
> >  UD-A  |     41
> >
> >(http://www.winbond.com/e-winbondhtm/partner/PDFResult.asp?Pname=182)
> 
> sorry, I have not been following this one closely. Given that you can 
> differentiate the chips, is there some workaround you can force in at 
> bios time? How does one fix this?
 
As a workaround/solution it is possible to add

pci_write_config8(PCI_DEV(0, 0x04, 3), 0x4a, 0x50);

right after console_init() in auto.c.

This switches the 8111 serial irq logic from quiet mode to continuous
mode:

   CONTMD. Continuous mode selected versus quiet mode. 1=The serial IRQ
   logic is in continuous mode. 0=The serial IRQ logic is in quiet mode.
   In continuous mode, the start frame is initiated by the IC
   immediately following each stop frame. In quiet mode, start frames
   are initiated by external slave devices.

I wonder whether this is generally a good idea and should go to 8111
setup for all boards?

Winbond has been very helpful in this issue. They've been answering
all my questions almost immediately.

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/



From yinghai.lu at amd.com  Tue Mar  7 20:02:16 2006
From: yinghai.lu at amd.com (Lu, Yinghai)
Date: Tue, 7 Mar 2006 11:02:16 -0800
Subject: [LinuxBIOS] AMD64 serial setup
References: <20060302162350.GB8644@openbios.org>
	<20060305184347.GA4097@openbios.org>
	<20060305184929.GB6295@openbios.org> <440B41F3.90600@lanl.gov>
	<20060307131756.GA14276@openbios.org>
Message-ID: <6F7DA19D05F3CF40B890C7CA2DB13A4201E08B6F@ssvlexmb2.amd.com>

can you do that on amd8111_lpc.c?
 
YH

________________________________

From: linuxbios-bounces at linuxbios.org on behalf of Stefan Reinauer
Sent: Tue 3/7/2006 5:17 AM
To: Ronald G Minnich
Cc: linuxbios at linuxbios.org
Subject: Re: [LinuxBIOS] AMD64 serial setup



* Ronald G Minnich <rminnich at lanl.gov> [060305 20:54]:
> Stefan Reinauer wrote:
> >
> >>The systems which are causing problems all have a
> >>
> >>  W83627HF revision ID = 0x17
> >>
> >>The OK systems with linuxbios all have:
> >>
> >>  W83627HF revision ID = 0x41
> >>
> >>Unfortunately there does not seem to be a revision guide on the winbond
> >>website. Any ideas anyone?
> >
> >
> >The only information I could find:
> >the W83627HF data sheet says:
> >
> >Version | Device Rev
> >--------+-----------
> >    G   |     17
> >    J   |     3A
> >  UD-A  |     41
> >
> >(http://www.winbond.com/e-winbondhtm/partner/PDFResult.asp?Pname=182)
>
> sorry, I have not been following this one closely. Given that you can
> differentiate the chips, is there some workaround you can force in at
> bios time? How does one fix this?

As a workaround/solution it is possible to add

pci_write_config8(PCI_DEV(0, 0x04, 3), 0x4a, 0x50);

right after console_init() in auto.c.

This switches the 8111 serial irq logic from quiet mode to continuous
mode:

   CONTMD. Continuous mode selected versus quiet mode. 1=The serial IRQ
   logic is in continuous mode. 0=The serial IRQ logic is in quiet mode.
   In continuous mode, the start frame is initiated by the IC
   immediately following each stop frame. In quiet mode, start frames
   are initiated by external slave devices.

I wonder whether this is generally a good idea and should go to 8111
setup for all boards?

Winbond has been very helpful in this issue. They've been answering
all my questions almost immediately.

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/

--
linuxbios mailing list
linuxbios at linuxbios.org
http://www.openbios.org/mailman/listinfo/linuxbios



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

From miernik at ffii.org  Tue Mar  7 21:32:39 2006
From: miernik at ffii.org (Miernik)
Date: Tue, 7 Mar 2006 21:32:39 +0100
Subject: [LinuxBIOS] IDE to CF adapters for 3.5" sockets - powered from
	motherboard?
Message-ID: <20060307203239.1082.e.NOFFLE@localhost.localdomain.local>

Can IDE to CF adpaters (female type - which connect directly to
motherboard, without any cable), the 3.5" disk connector type, can they
be powered directly from the motherboard? Most of them have a
floppy-type power connector on them, but some of them have a jumper
which allows them to be powered from the motherboard IDE socket, without
connecting the floppy power. But in some description I have read that
that only works on VIA EPIA motherboards.

How does the situation really look like? I want to use a CF-IDE female
adapter in a standard PGA370 motherboard (non-VIA-EPIA), and I don't
want to have to connect any extra power, like the floppy power to it.

Is that possible? I know it's possible for 2.5" disk connectors. because
they have 4 extra power pins, but I mean the standard 40-pin IDE
connectors.

-- 
Miernik             _________________________  xmpp:miernik at amessage.info
___________________/_______________________/      mailto:miernik at ffii.org
Protect Europe from a legal disaster. Petition against software patents
http://www.noepatents.org/index_html?LANG=en




From stuge-linuxbios at cdy.org  Tue Mar  7 22:46:15 2006
From: stuge-linuxbios at cdy.org (Peter Stuge)
Date: Tue, 7 Mar 2006 22:46:15 +0100
Subject: [LinuxBIOS] IDE to CF adapters for 3.5" sockets - powered from
	motherboard?
In-Reply-To: <20060307203239.1082.e.NOFFLE@localhost.localdomain.local>
References: <20060307203239.1082.e.NOFFLE@localhost.localdomain.local>
Message-ID: <20060307214615.3464.qmail@cdy.org>

On Tue, Mar 07, 2006 at 09:32:39PM +0100, Miernik wrote:
> How does the situation really look like? I want to use a CF-IDE
> female adapter in a standard PGA370 motherboard (non-VIA-EPIA), and
> I don't want to have to connect any extra power, like the floppy
> power to it.
> 
> Is that possible? I know it's possible for 2.5" disk connectors.
> because they have 4 extra power pins, but I mean the standard
> 40-pim IDE connectors.

The regular IDE connector has one unused pin which is sometimes used
for keying the connector mechanically. Some embedded systems put 5V
on that pin, but I doubt any standard motherboard does that.


//Peter



From stepan at coresystems.de  Tue Mar  7 22:55:00 2006
From: stepan at coresystems.de (Stefan Reinauer)
Date: Tue, 7 Mar 2006 22:55:00 +0100
Subject: [LinuxBIOS] AMD64 serial setup
In-Reply-To: <6F7DA19D05F3CF40B890C7CA2DB13A4201E08B6F@ssvlexmb2.amd.com>
References: <20060302162350.GB8644@openbios.org>
	<20060305184347.GA4097@openbios.org>
	<20060305184929.GB6295@openbios.org> <440B41F3.90600@lanl.gov>
	<20060307131756.GA14276@openbios.org>
	<6F7DA19D05F3CF40B890C7CA2DB13A4201E08B6F@ssvlexmb2.amd.com>
Message-ID: <20060307215500.GA12774@openbios.org>

* Lu, Yinghai <yinghai.lu at amd.com> [060307 20:02]:
> can you do that on amd8111_lpc.c?
 
it belongs to amd8111_acpi.c, nor?

> pci_write_config8(PCI_DEV(0, 0x04, 3), 0x4a, 0x50);

I propose the following generic patch. (attachment)

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/
-------------- next part --------------
Index: src/southbridge/amd/amd8111/amd8111_acpi.c
===================================================================
--- src/southbridge/amd/amd8111/amd8111_acpi.c	(revision 2191)
+++ src/southbridge/amd/amd8111/amd8111_acpi.c	(working copy)
@@ -122,6 +122,12 @@
 	pci_write_config8(dev, PREVIOUS_POWER_STATE, byte);
 	printk_info("set power %s after power fail\n", on?"on":"off");
 
+	/* switch serial irq logic from quiet mode to continuous
+	 * mode for Winbond W83627HF Rev. 17
+	 */
+	byte = pci_read_config8(dev, 0x4a);
+	pci_write_config8(dev, 0x4a, byte | (1<<6));
+	
 	/* Throttle the CPU speed down for testing */
 	on = SLOW_CPU_OFF;
 	get_option(&on, "slow_cpu");

From rminnich at lanl.gov  Tue Mar  7 23:41:56 2006
From: rminnich at lanl.gov (Ronald G Minnich)
Date: Tue, 07 Mar 2006 15:41:56 -0700
Subject: [LinuxBIOS] AMD64 serial setup
In-Reply-To: <20060307215500.GA12774@openbios.org>
References: <20060302162350.GB8644@openbios.org>
	<20060305184347.GA4097@openbios.org>
	<20060305184929.GB6295@openbios.org> <440B41F3.90600@lanl.gov>
	<20060307131756.GA14276@openbios.org>
	<6F7DA19D05F3CF40B890C7CA2DB13A4201E08B6F@ssvlexmb2.amd.com>
	<20060307215500.GA12774@openbios.org>
Message-ID: <440E0C34.3090608@lanl.gov>

Do you want this controlled by an option in the chip struct for that 
part? You're sure it does no harm to turn it on? it looks fine to me.

ron



From stepan at coresystems.de  Wed Mar  8 00:04:26 2006
From: stepan at coresystems.de (Stefan Reinauer)
Date: Wed, 8 Mar 2006 00:04:26 +0100
Subject: [LinuxBIOS] AMD64 serial setup
In-Reply-To: <440E0C34.3090608@lanl.gov>
References: <20060302162350.GB8644@openbios.org>
	<20060305184347.GA4097@openbios.org>
	<20060305184929.GB6295@openbios.org> <440B41F3.90600@lanl.gov>
	<20060307131756.GA14276@openbios.org>
	<6F7DA19D05F3CF40B890C7CA2DB13A4201E08B6F@ssvlexmb2.amd.com>
	<20060307215500.GA12774@openbios.org> <440E0C34.3090608@lanl.gov>
Message-ID: <20060307230426.GA17746@openbios.org>

* Ronald G Minnich <rminnich at lanl.gov> [060307 23:41]:
> Do you want this controlled by an option in the chip struct for that 
> part? You're sure it does no harm to turn it on? it looks fine to me.
 
It does not harm on any of the agami boards we've tried, no matter what
Winbond revision was used. On the 0x17 parts the problem went away.


From bari at onelabs.com  Wed Mar  8 03:35:36 2006
From: bari at onelabs.com (Bari Ari)
Date: Tue, 07 Mar 2006 20:35:36 -0600
Subject: [LinuxBIOS] IDE to CF adapters for 3.5" sockets - powered from
 motherboard?
In-Reply-To: <20060307214615.3464.qmail@cdy.org>
References: <20060307203239.1082.e.NOFFLE@localhost.localdomain.local>
	<20060307214615.3464.qmail@cdy.org>
Message-ID: <440E42F8.5020400@onelabs.com>

Peter Stuge wrote:
> The regular IDE connector has one unused pin which is sometimes used
> for keying the connector mechanically. Some embedded systems put 5V
> on that pin, but I doubt any standard motherboard does that.

Epia-SP's (Mini-ITX) have the extra #20 IDE pin with the 5V. A quick 
snip with the cutters and it's permanently cured. Or you can look for 
IDE cables with the full 40 pins.

-Bari



From yinghailu at gmail.com  Wed Mar  8 05:54:53 2006
From: yinghailu at gmail.com (yhlu)
Date: Tue, 7 Mar 2006 20:54:53 -0800
Subject: [LinuxBIOS] AMD64 serial setup
In-Reply-To: <20060307230426.GA17746@openbios.org>
References: <20060302162350.GB8644@openbios.org>
	<20060305184347.GA4097@openbios.org>
	<20060305184929.GB6295@openbios.org> <440B41F3.90600@lanl.gov>
	<20060307131756.GA14276@openbios.org>
	<6F7DA19D05F3CF40B890C7CA2DB13A4201E08B6F@ssvlexmb2.amd.com>
	<20060307215500.GA12774@openbios.org> <440E0C34.3090608@lanl.gov>
	<20060307230426.GA17746@openbios.org>
Message-ID: <2ea3fae10603072054l1422bf3axd96795d90f87fa56@mail.gmail.com>

let me try it tomorrow. Maybe this one solve the bug that 8132/8111
serial port can not get irq.

YH



From yinghailu at gmail.com  Wed Mar  8 20:08:36 2006
From: yinghailu at gmail.com (yhlu)
Date: Wed, 8 Mar 2006 11:08:36 -0800
Subject: [LinuxBIOS] AMD64 serial setup
In-Reply-To: <20060307230426.GA17746@openbios.org>
References: <20060302162350.GB8644@openbios.org>
	<20060305184347.GA4097@openbios.org>
	<20060305184929.GB6295@openbios.org> <440B41F3.90600@lanl.gov>
	<20060307131756.GA14276@openbios.org>
	<6F7DA19D05F3CF40B890C7CA2DB13A4201E08B6F@ssvlexmb2.amd.com>
	<20060307215500.GA12774@openbios.org> <440E0C34.3090608@lanl.gov>
	<20060307230426.GA17746@openbios.org>
Message-ID: <2ea3fae10603081108j208857a4pe24e1212d7a7e655@mail.gmail.com>

On 3/7/06, Stefan Reinauer <stepan at coresystems.de> wrote:
> Yinghai, can we switch this on unconditionally or might that hurt some
> motherboards?
>

OK to me.

YH



From jardel at lesc.ufc.br  Fri Mar 10 12:26:36 2006
From: jardel at lesc.ufc.br (jardel)
Date: Fri, 10 Mar 2006 08:26:36 -0300
Subject: [LinuxBIOS] RES:  RES:  Rumba target and AMD RDK THINCLIENT
In-Reply-To: <1141064948.19385.51.camel@logarithm.lanl.gov>
References: <200602241929.k1OJSxT6009241@proofpoint2.lanl.gov>
	<1141064948.19385.51.camel@logarithm.lanl.gov>
Message-ID: <4411626C.8020304@lesc.ufc.br>

Dear Mr. Li-Ta Lo,


     I've tried, but id didn't see any bytes on serial port 0 of the CS5535.
     What is the hardware description of rumba target ?  I'm trying it
on the AMD RDK THINCLIENT based on GEODE GX2.
     What are you doing about VSA ? I didn't see any binary with it  in
the LinuxBiosv2 source tree.
     So, Can systems based ond GEODE (GX1, GX2 or LX) work without VSA
initialization ?


Thanks for your precious help.


Jardel.

  

Li-Ta Lo wrote:

>On Fri, 2006-02-24 at 16:28 -0300, Jardel Silveira wrote:
>  
>
>>Dear Li-Ta Lo,
>>
>>
>>	I?ve just tried to compile rumba now and i?ve got this ouput?
>>
>>N_OFFSET='0x0' -DXIP_ROM_SIZE='0x10000' -DXIP_ROM_BASE='0xfffd0000'
>>-DCONFIG_UDELAY_TSC='1' -DCONFIG_TSC_X86RDTSC_CALIBRATE_WITH_TIMER2='0'
>>-DCONFIG_UDELAY_IO='0'
>>/home/jardel/projetos/LinuxBIOSv2/src/mainboard/amd/rumba/auto.c -o auto.inc
>>raminit.c:3.61:
>>struct mem_controller undeclared
>>make[1]: ** [auto.inc] Erro 1
>>make[1]: Leaving directory
>>`/home/jardel/projetos/LinuxBIOSv2/targets/amd/rumba/rumba/normal'
>>make: ** [normal/linuxbios.rom] Erro 1
>>jardel at jardel:~/projetos/LinuxBIOSv2/targets/amd/rumba/rumba$ ls
>>
>>
>>    
>>
>
>I just committed other part of the change. Could you try it again?
>
>  
>




From stuge-linuxbios at cdy.org  Fri Mar 10 16:46:50 2006
From: stuge-linuxbios at cdy.org (Peter Stuge)
Date: Fri, 10 Mar 2006 16:46:50 +0100
Subject: [LinuxBIOS] RES:  RES:  Rumba target and AMD RDK THINCLIENT
In-Reply-To: <4411626C.8020304@lesc.ufc.br>
References: <200602241929.k1OJSxT6009241@proofpoint2.lanl.gov>
	<1141064948.19385.51.camel@logarithm.lanl.gov>
	<4411626C.8020304@lesc.ufc.br>
Message-ID: <20060310154650.389.qmail@cdy.org>

On Fri, Mar 10, 2006 at 08:26:36AM -0300, jardel wrote:
> So, Can systems based ond GEODE (GX1, GX2 or LX) work without VSA
> initialization ?

Yes, they can. Only specific functionality requires VSA, perhaps most
notably XpressAUDIO.


//Peter



From bari at onelabs.com  Fri Mar 10 16:57:17 2006
From: bari at onelabs.com (Bari Ari)
Date: Fri, 10 Mar 2006 09:57:17 -0600
Subject: [LinuxBIOS] RES:  RES:  Rumba target and AMD RDK THINCLIENT
In-Reply-To: <20060310154650.389.qmail@cdy.org>
References: <200602241929.k1OJSxT6009241@proofpoint2.lanl.gov>	<1141064948.19385.51.camel@logarithm.lanl.gov>	<4411626C.8020304@lesc.ufc.br>
	<20060310154650.389.qmail@cdy.org>
Message-ID: <4411A1DD.4060905@onelabs.com>

Peter Stuge wrote:
> On Fri, Mar 10, 2006 at 08:26:36AM -0300, jardel wrote:
> 
>>So, Can systems based ond GEODE (GX1, GX2 or LX) work without VSA
>>initialization ?
> 
> Yes, they can. Only specific functionality requires VSA, perhaps most
> notably XpressAUDIO.

Has anyone ever been able to get source to the Insyde/AMD VSA?

Has anyone ever been able to work the Insyde/AMD VSA binaries into 
LinuxBIOS?

Has anyone ever gotten audio (or other VSA features) working on the 
Geodes without the VSA from Insyde/AMD?

-Bari



From jardel at lesc.ufc.br  Fri Mar 10 17:59:28 2006
From: jardel at lesc.ufc.br (jardel)
Date: Fri, 10 Mar 2006 13:59:28 -0300
Subject: [LinuxBIOS] RES:  RES:  Rumba target and AMD RDK THINCLIENT
In-Reply-To: <4411A1DD.4060905@onelabs.com>
References: <200602241929.k1OJSxT6009241@proofpoint2.lanl.gov>	<1141064948.19385.51.camel@logarithm.lanl.gov>	<4411626C.8020304@lesc.ufc.br>	<20060310154650.389.qmail@cdy.org>
	<4411A1DD.4060905@onelabs.com>
Message-ID: <4411B070.5090002@lesc.ufc.br>


Does any one know if the use of vsa binary is free of charge or if would
be necessary pay some kind of fee to Insyde  ?


Bari Ari wrote:

>Peter Stuge wrote:
>  
>
>>On Fri, Mar 10, 2006 at 08:26:36AM -0300, jardel wrote:
>>
>>    
>>
>>>So, Can systems based ond GEODE (GX1, GX2 or LX) work without VSA
>>>initialization ?
>>>      
>>>
>>Yes, they can. Only specific functionality requires VSA, perhaps most
>>notably XpressAUDIO.
>>    
>>
>
>Has anyone ever been able to get source to the Insyde/AMD VSA?
>
>Has anyone ever been able to work the Insyde/AMD VSA binaries into 
>LinuxBIOS?
>
>Has anyone ever gotten audio (or other VSA features) working on the 
>Geodes without the VSA from Insyde/AMD?
>
>-Bari
>
>  
>




From ollie at lanl.gov  Fri Mar 10 18:07:38 2006
From: ollie at lanl.gov (Li-Ta Lo)
Date: Fri, 10 Mar 2006 10:07:38 -0700 (MST)
Subject: [LinuxBIOS] RES:  RES:  Rumba target and AMD RDK THINCLIENT
In-Reply-To: <4411626C.8020304@lesc.ufc.br>
References: <200602241929.k1OJSxT6009241@proofpoint2.lanl.gov>
	<1141064948.19385.51.camel@logarithm.lanl.gov>
	<4411626C.8020304@lesc.ufc.br>
Message-ID: <8998.128.165.0.81.1142010458.squirrel@webmail.lanl.gov>

> Dear Mr. Li-Ta Lo,
>
>
>      I've tried, but id didn't see any bytes on serial port 0 of the
> CS5535.
>      What is the hardware description of rumba target ?  I'm trying it
> on the AMD RDK THINCLIENT based on GEODE GX2.

I think our board is the thinclient RDK with the winbond superio duaght
board. Did you get the lastest code? Does it compile?


>      What are you doing about VSA ? I didn't see any binary with it  in
> the LinuxBiosv2 source tree.

I haven't got that far yet. Probably somethin very similar to how we deal
VGA bios on Via.

>      So, Can systems based ond GEODE (GX1, GX2 or LX) work without VSA
> initialization ?
>

My first impression is it can be done but the more I know about Geode and
VSA, the more I doubt it. One serious problem is there is basically no PCI
system in the Geode GX. All PCI configuration space registers are emulated
by VSA. It is possible to have a heavily modified driver to access the MSR
register space than the emulated PCI space but it requires a lot of work.

BTW, VSA is supposed to do some other magic device init too.

Ollie



From ollie at lanl.gov  Fri Mar 10 18:13:47 2006
From: ollie at lanl.gov (Li-Ta Lo)
Date: Fri, 10 Mar 2006 10:13:47 -0700 (MST)
Subject: [LinuxBIOS] RES:  RES:  Rumba target and AMD RDK THINCLIENT
In-Reply-To: <4411A1DD.4060905@onelabs.com>
References: <200602241929.k1OJSxT6009241@proofpoint2.lanl.gov>	<1141064948.19385.51.camel@logarithm.lanl.gov>	<4411626C.8020304@lesc.ufc.br><20060310154650.389.qmail@cdy.org>
	<4411A1DD.4060905@onelabs.com>
Message-ID: <10233.128.165.0.81.1142010827.squirrel@webmail.lanl.gov>

> Peter Stuge wrote:
>> On Fri, Mar 10, 2006 at 08:26:36AM -0300, jardel wrote:
>>
>>>So, Can systems based ond GEODE (GX1, GX2 or LX) work without VSA
>>>initialization ?
>>
>> Yes, they can. Only specific functionality requires VSA, perhaps most
>> notably XpressAUDIO.
>
> Has anyone ever been able to get source to the Insyde/AMD VSA?
>


From ollie at lanl.gov  Fri Mar 10 18:14:52 2006
From: ollie at lanl.gov (Li-Ta Lo)
Date: Fri, 10 Mar 2006 10:14:52 -0700 (MST)
Subject: [LinuxBIOS] RES:  RES:  Rumba target and AMD RDK THINCLIENT
In-Reply-To: <4411B070.5090002@lesc.ufc.br>
References: <200602241929.k1OJSxT6009241@proofpoint2.lanl.gov>	<1141064948.19385.51.camel@logarithm.lanl.gov>	<4411626C.8020304@lesc.ufc.br>	<20060310154650.389.qmail@cdy.org><4411A1DD.4060905@onelabs.com>
	<4411B070.5090002@lesc.ufc.br>
Message-ID: <10599.128.165.0.81.1142010892.squirrel@webmail.lanl.gov>

>
> Does any one know if the use of vsa binary is free of charge or if would
> be necessary pay some kind of fee to Insyde  ?
>
>
> Bari Ari wrote:
>
>>Peter Stuge wrote:
>>
>>
>>>On Fri, Mar 10, 2006 at 08:26:36AM -0300, jardel wrote:
>>>
>>>
>>>
>>>>So, Can systems based ond GEODE (GX1, GX2 or LX) work without VSA
>>>>initialization ?
>>>>
>>>>
>>>Yes, they can. Only specific functionality requires VSA, perhaps most
>>>notably XpressAUDIO.
>>>
>>>
>>
>>Has anyone ever been able to get source to the Insyde/AMD VSA?
>>
>>Has anyone ever been able to work the Insyde/AMD VSA binaries into
>>LinuxBIOS?
>>
>>Has anyone ever gotten audio (or other VSA features) working on the
>>Geodes without the VSA from Insyde/AMD?
>>
>>-Bari
>>
>>
>>
>
>
> --
> linuxbios mailing list
> linuxbios at linuxbios.org
> http://www.openbios.org/mailman/listinfo/linuxbios
>




From ollie at lanl.gov  Fri Mar 10 18:16:40 2006
From: ollie at lanl.gov (Li-Ta Lo)
Date: Fri, 10 Mar 2006 10:16:40 -0700 (MST)
Subject: [LinuxBIOS] RES:  RES:  Rumba target and AMD RDK THINCLIENT
In-Reply-To: <4411B070.5090002@lesc.ufc.br>
References: <200602241929.k1OJSxT6009241@proofpoint2.lanl.gov>	<1141064948.19385.51.camel@logarithm.lanl.gov>	<4411626C.8020304@lesc.ufc.br>	<20060310154650.389.qmail@cdy.org><4411A1DD.4060905@onelabs.com>
	<4411B070.5090002@lesc.ufc.br>
Message-ID: <10903.128.165.0.81.1142011000.squirrel@webmail.lanl.gov>

>
> Does any one know if the use of vsa binary is free of charge or if would
> be necessary pay some kind of fee to Insyde  ?
>
>

If I am right at decoding the email transaction between AMD/OLPC/Quanta,
AMD holds the copyright of the VSA binary. We should be able to get
royality free distribution of the VSA binary (for the name of OLPC).

Ollie




From bari at onelabs.com  Fri Mar 10 18:22:34 2006
From: bari at onelabs.com (Bari Ari)
Date: Fri, 10 Mar 2006 11:22:34 -0600
Subject: [LinuxBIOS] RES:  RES:  Rumba target and AMD RDK THINCLIENT
In-Reply-To: <10233.128.165.0.81.1142010827.squirrel@webmail.lanl.gov>
References: <200602241929.k1OJSxT6009241@proofpoint2.lanl.gov>	<1141064948.19385.51.camel@logarithm.lanl.gov>	<4411626C.8020304@lesc.ufc.br><20060310154650.389.qmail@cdy.org>
	<4411A1DD.4060905@onelabs.com>
	<10233.128.165.0.81.1142010827.squirrel@webmail.lanl.gov>
Message-ID: <4411B5DA.2090904@onelabs.com>

Li-Ta Lo wrote:

> I have pretty much idea about how the VSA is working. Once I got the most
> basic chipset init done. I will try to integrate VSA into LinuxBIOS.
> 
> One advantage we just got is AMD has committed to provide support for
> the One Laptop per Poor Child project. Probably we will get something
> not normally avaliable to the public.
> 
> BTW, I really need help from the LB community. I simply can't do all
> the hacking and coding by myself and meet OLPC/Quanta's tight schedule.

Are you working with the current L.B. ver2 tree? What version of Geode 
are they using?

-Bari




From bari at onelabs.com  Fri Mar 10 18:27:27 2006
From: bari at onelabs.com (Bari Ari)
Date: Fri, 10 Mar 2006 11:27:27 -0600
Subject: [LinuxBIOS] RES:  RES:  Rumba target and AMD RDK THINCLIENT
In-Reply-To: <4411B070.5090002@lesc.ufc.br>
References: <200602241929.k1OJSxT6009241@proofpoint2.lanl.gov>	<1141064948.19385.51.camel@logarithm.lanl.gov>	<4411626C.8020304@lesc.ufc.br>	<20060310154650.389.qmail@cdy.org>
	<4411A1DD.4060905@onelabs.com> <4411B070.5090002@lesc.ufc.br>
Message-ID: <4411B6FF.6000403@onelabs.com>

jardel wrote:
> Does any one know if the use of vsa binary is free of charge or if would
> be necessary pay some kind of fee to Insyde  ?

AMD routinely points you to Insyde for any BIOS bits and pieces. I spoke 
to Insyde a few years ago about getting just the VSA. They were never 
approached about this in the past and didn't know how to respond. That 
project died and I never followed up with them.

Surely with the new laptop initiative they will have to open VSA up, 
unless they were planning on a closed BIOS for them.

-Bari



From bari at onelabs.com  Fri Mar 10 18:31:40 2006
From: bari at onelabs.com (Bari Ari)
Date: Fri, 10 Mar 2006 11:31:40 -0600
Subject: [LinuxBIOS] RES:  RES:  Rumba target and AMD RDK THINCLIENT
In-Reply-To: <10903.128.165.0.81.1142011000.squirrel@webmail.lanl.gov>
References: <200602241929.k1OJSxT6009241@proofpoint2.lanl.gov>	<1141064948.19385.51.camel@logarithm.lanl.gov>	<4411626C.8020304@lesc.ufc.br>	<20060310154650.389.qmail@cdy.org><4411A1DD.4060905@onelabs.com>
	<4411B070.5090002@lesc.ufc.br>
	<10903.128.165.0.81.1142011000.squirrel@webmail.lanl.gov>
Message-ID: <4411B7FC.9000906@onelabs.com>

Li-Ta Lo wrote:
>>Does any one know if the use of vsa binary is free of charge or if would
>>be necessary pay some kind of fee to Insyde  ?
>>
>>
> 
> 
> If I am right at decoding the email transaction between AMD/OLPC/Quanta,
> AMD holds the copyright of the VSA binary. We should be able to get
> royality free distribution of the VSA binary (for the name of OLPC).


Yes, AMD is the owner of VSA. I also hope they planned on opening this 
up vs. insisting on Insyde BIOS for the laptops.

-Bari



From jardel at lesc.ufc.br  Fri Mar 10 19:13:32 2006
From: jardel at lesc.ufc.br (jardel)
Date: Fri, 10 Mar 2006 15:13:32 -0300
Subject: [LinuxBIOS] RES:  RES:  Rumba target and AMD RDK THINCLIENT
In-Reply-To: <8998.128.165.0.81.1142010458.squirrel@webmail.lanl.gov>
References: <200602241929.k1OJSxT6009241@proofpoint2.lanl.gov>
	<1141064948.19385.51.camel@logarithm.lanl.gov>
	<4411626C.8020304@lesc.ufc.br>
	<8998.128.165.0.81.1142010458.squirrel@webmail.lanl.gov>
Message-ID: <4411C1CC.1000702@lesc.ufc.br>


>>Dear Mr. Li-Ta Lo,
>>
>>
>>     I've tried, but id didn't see any bytes on serial port 0 of the
>>CS5535.
>>     What is the hardware description of rumba target ?  I'm trying it
>>on the AMD RDK THINCLIENT based on GEODE GX2.
>>    
>>
>
>I think our board is the thinclient RDK with the winbond superio duaght
>board. Did you get the lastest code? Does it compile?
>  
>
My Daught board (LPC Expansion) uses the NSC PC87364, the wich is the
same WINBOND 87364. I compile successfull the last code, but i was not
able to see anything on serial port 0 of CS5535. But something is clear
for me now: if you don't have VSA initialized, you aren't able for using
serial port of companion chip.  As a matter of fact, you are probably
sending the bytes to port 0 of winbond super i/o, isn' t ?
Are you really sending the debug output for port 0 of  WINBOND 87364 ?

>
>  
>
>>     What are you doing about VSA ? I didn't see any binary with it  in
>>the LinuxBiosv2 source tree.
>>    
>>
>
>I haven't got that far yet. Probably somethin very similar to how we deal
>VGA bios on Via.
>
>  
>
>>     So, Can systems based ond GEODE (GX1, GX2 or LX) work without VSA
>>initialization ?
>>
>>    
>>
>
>My first impression is it can be done but the more I know about Geode and
>VSA, the more I doubt it. One serious problem is there is basically no PCI
>system in the Geode GX. All PCI configuration space registers are emulated
>by VSA. It is possible to have a heavily modified driver to access the MSR
>register space than the emulated PCI space but it requires a lot of work.
>
>BTW, VSA is supposed to do some other magic device init too.
>
>Ollie
>  
>




From ollie at lanl.gov  Fri Mar 10 19:40:13 2006
From: ollie at lanl.gov (Li-Ta Lo)
Date: Fri, 10 Mar 2006 11:40:13 -0700 (MST)
Subject: [LinuxBIOS] RES:  RES:  Rumba target and AMD RDK THINCLIENT
In-Reply-To: <4411B5DA.2090904@onelabs.com>
References: <200602241929.k1OJSxT6009241@proofpoint2.lanl.gov>	<1141064948.19385.51.camel@logarithm.lanl.gov>	<4411626C.8020304@lesc.ufc.br><20060310154650.389.qmail@cdy.org>
	<4411A1DD.4060905@onelabs.com>
	<10233.128.165.0.81.1142010827.squirrel@webmail.lanl.gov>
	<4411B5DA.2090904@onelabs.com>
Message-ID: <24946.128.165.0.81.1142016013.squirrel@webmail.lanl.gov>

> Li-Ta Lo wrote:
>
>> I have pretty much idea about how the VSA is working. Once I got the
>> most
>> basic chipset init done. I will try to integrate VSA into LinuxBIOS.
>>
>> One advantage we just got is AMD has committed to provide support for
>> the One Laptop per Poor Child project. Probably we will get something
>> not normally avaliable to the public.
>>
>> BTW, I really need help from the LB community. I simply can't do all
>> the hacking and coding by myself and meet OLPC/Quanta's tight schedule.
>
> Are you working with the current L.B. ver2 tree? What version of Geode
> are they using?
>

I am working on V2. The (hardcoded) DRAM init code is working and is in
the SVN. They are going to use GX with 5536.

> -Bari
>
>




From ollie at lanl.gov  Fri Mar 10 19:45:01 2006
From: ollie at lanl.gov (Li-Ta Lo)
Date: Fri, 10 Mar 2006 11:45:01 -0700 (MST)
Subject: [LinuxBIOS] RES:  RES:  Rumba target and AMD RDK THINCLIENT
In-Reply-To: <4411C1CC.1000702@lesc.ufc.br>
References: <200602241929.k1OJSxT6009241@proofpoint2.lanl.gov>   
	<1141064948.19385.51.camel@logarithm.lanl.gov>   
	<4411626C.8020304@lesc.ufc.br>
	<8998.128.165.0.81.1142010458.squirrel@webmail.lanl.gov>
	<4411C1CC.1000702@lesc.ufc.br>
Message-ID: <25687.128.165.0.81.1142016301.squirrel@webmail.lanl.gov>

>
>>>Dear Mr. Li-Ta Lo,
>>>
>>>
>>>     I've tried, but id didn't see any bytes on serial port 0 of the
>>>CS5535.
>>>     What is the hardware description of rumba target ?  I'm trying it
>>>on the AMD RDK THINCLIENT based on GEODE GX2.
>>>
>>>
>>
>>I think our board is the thinclient RDK with the winbond superio duaght
>>board. Did you get the lastest code? Does it compile?
>>
>>
> My Daught board (LPC Expansion) uses the NSC PC87364, the wich is the
> same WINBOND 87364. I compile successfull the last code, but i was not
> able to see anything on serial port 0 of CS5535. But something is clear
> for me now: if you don't have VSA initialized, you aren't able for using
> serial port of companion chip.  As a matter of fact, you are probably
> sending the bytes to port 0 of winbond super i/o, isn' t ?
> Are you really sending the debug output for port 0 of  WINBOND 87364 ?
>

Yes, I am sending to the serial port on the superio chip, not the
internal UART of GX/CS5535.

Ollie




From stuge-linuxbios at cdy.org  Fri Mar 10 20:34:48 2006
From: stuge-linuxbios at cdy.org (Peter Stuge)
Date: Fri, 10 Mar 2006 20:34:48 +0100
Subject: [LinuxBIOS] RES:  RES:  Rumba target and AMD RDK THINCLIENT
In-Reply-To: <10903.128.165.0.81.1142011000.squirrel@webmail.lanl.gov>
	<4411B6FF.6000403@onelabs.com> <4411B070.5090002@lesc.ufc.br>
	<10233.128.165.0.81.1142010827.squirrel@webmail.lanl.gov>
References: <200602241929.k1OJSxT6009241@proofpoint2.lanl.gov>
	<1141064948.19385.51.camel@logarithm.lanl.gov>
	<4411626C.8020304@lesc.ufc.br> <20060310154650.389.qmail@cdy.org>
	<4411A1DD.4060905@onelabs.com> <4411B070.5090002@lesc.ufc.br>
	<200602241929.k1OJSxT6009241@proofpoint2.lanl.gov>
	<1141064948.19385.51.camel@logarithm.lanl.gov>
	<4411A1DD.4060905@onelabs.com>
	<10233.128.165.0.81.1142010827.squirrel@webmail.lanl.gov>
Message-ID: <20060310193448.27424.qmail@cdy.org>

On Fri, Mar 10, 2006 at 10:13:47AM -0700, Li-Ta Lo wrote:
> > Has anyone ever been able to get source to the Insyde/AMD VSA?
> 
> From VSA docs, it seems it is possible to get the source from AMD.
> I don't know if anyone has tried to get it yet.

Not VSM sources, but VSA init sources.

Back in 2001 when I was working with the Geode SC1200 National
distributed the BLDT, BootLoader Development Toolkit, aka
XpressLOADER. It was a bunch of assembly source and some
documentation for making a minimal BIOS that would initialize the
system and provide just enough services to init also the VGA BIOS
but nothing more.

The BLDT was provided free of charge with no royalty fee required for
derived works.

The BLDT included documentation and source for VSA initialization as
well as VSM binaries.

I have posted the titles of the VSA documentation PDF files earlier
and can probably dig that out from my email archive but unfortunately
I no longer have access to the actual documents.

I seem to remember that we got the BLDT from National and not Insyde.

Insyde was only involved if we wanted to spend money on the BIOS, and
there were two options at the time: XpressROM and Insyde BIOS, the
former being a more bare-bones BIOS without a configuration menu and
the latter being the equivalent of an Award, AMI or Phoenix BIOS with
setup screen and all.

I assume the XpressLOADER was just a stripped-down version of the
XpressROM.


> > Has anyone ever been able to work the Insyde/AMD VSA binaries into
> > LinuxBIOS?
> 
> I have pretty much idea about how the VSA is working. Once I got the
> most basic chipset init done. I will try to integrate VSA into
> LinuxBIOS.
> 
> One advantage we just got is AMD has committed to provide support for
> the One Laptop per Poor Child project. Probably we will get something
> not normally avaliable to the public.

Cool. Perhaps you can pull some strings and see if you can get hold
of the BLDT once again.


On Fri, Mar 10, 2006 at 01:59:28PM -0300, jardel wrote:
> Does any one know if the use of vsa binary is free of charge or if
> would be necessary pay some kind of fee to Insyde  ?

We were allowed to redistribute the VSM binaries from the BLDT
royalty-free, but I do not remember if that included stand-alone as
well as linked to our own BIOS.


On Fri, Mar 10, 2006 at 11:27:27AM -0600, Bari Ari wrote:
> jardel wrote:
> > Does any one know if the use of vsa binary is free of charge or
> > if would be necessary pay some kind of fee to Insyde  ?
> 
> AMD routinely points you to Insyde for any BIOS bits and pieces. I
> spoke to Insyde a few years ago about getting just the VSA. They
> were never approached about this in the past and didn't know how to
> respond. That project died and I never followed up with them.

This reassures my memory of us getting the BLDT from National rather
than Insyde.


On Fri, Mar 10, 2006 at 10:16:40AM -0700, Li-Ta Lo wrote:
> If I am right at decoding the email transaction between
> AMD/OLPC/Quanta, AMD holds the copyright of the VSA binary. We
> should be able to get royality free distribution of the VSA binary
> (for the name of OLPC).

Possibly otherwise as well..


I guess the BLDT/XpressLOADER is little known since not many are
interested in writing their own BIOS software.


//Peter



From bari at onelabs.com  Fri Mar 10 22:14:54 2006
From: bari at onelabs.com (Bari Ari)
Date: Fri, 10 Mar 2006 15:14:54 -0600
Subject: [LinuxBIOS] RES:  RES:  Rumba target and AMD RDK THINCLIENT
In-Reply-To: <20060310193448.27424.qmail@cdy.org>
References: <200602241929.k1OJSxT6009241@proofpoint2.lanl.gov>	<1141064948.19385.51.camel@logarithm.lanl.gov>	<4411626C.8020304@lesc.ufc.br>
	<20060310154650.389.qmail@cdy.org>	<4411A1DD.4060905@onelabs.com>
	<4411B070.5090002@lesc.ufc.br>	<200602241929.k1OJSxT6009241@proofpoint2.lanl.gov>	<1141064948.19385.51.camel@logarithm.lanl.gov>	<4411A1DD.4060905@onelabs.com>	<10233.128.165.0.81.1142010827.squirrel@webmail.lanl.gov>
	<20060310193448.27424.qmail@cdy.org>
Message-ID: <4411EC4E.9010602@onelabs.com>

Peter Stuge wrote:
> On Fri, Mar 10, 2006 at 10:13:47AM -0700, Li-Ta Lo wrote:
> 
>>>Has anyone ever been able to get source to the Insyde/AMD VSA?
>>
>>From VSA docs, it seems it is possible to get the source from AMD.
>>I don't know if anyone has tried to get it yet.
> 
> 
> Not VSM sources, but VSA init sources.
> 
> Back in 2001 when I was working with the Geode SC1200 National
> distributed the BLDT, BootLoader Development Toolkit, aka
> XpressLOADER. It was a bunch of assembly source and some
> documentation for making a minimal BIOS that would initialize the
> system and provide just enough services to init also the VGA BIOS
> but nothing more.
> 
> The BLDT was provided free of charge with no royalty fee required for
> derived works.
> 
> The BLDT included documentation and source for VSA initialization as
> well as VSM binaries.

I still have all the BLDT kits from NSC. If we can use the VSA binaries 
the same as VideoBIOS then we are set.

-Bari



From jardel at lesc.ufc.br  Fri Mar 10 22:42:42 2006
From: jardel at lesc.ufc.br (jardel)
Date: Fri, 10 Mar 2006 18:42:42 -0300
Subject: [LinuxBIOS] RES:  RES:  Rumba target and AMD RDK THINCLIENT
In-Reply-To: <25687.128.165.0.81.1142016301.squirrel@webmail.lanl.gov>
References: <200602241929.k1OJSxT6009241@proofpoint2.lanl.gov>
	<1141064948.19385.51.camel@logarithm.lanl.gov>
	<4411626C.8020304@lesc.ufc.br>	<8998.128.165.0.81.1142010458.squirrel@webmail.lanl.gov>	<4411C1CC.1000702@lesc.ufc.br>
	<25687.128.165.0.81.1142016301.squirrel@webmail.lanl.gov>
Message-ID: <4411F2D2.70706@lesc.ufc.br>

Dear Ollie,


   It works !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
   See below the output that i get at serial port of super i/o:
   Please, do same comment about the output. Is the erro pointed below
according to the development stage of project or not ?
  
  
   LinuxBIOS-1.1.8.0Fallback Sex Mar  3 09:23:01 BRT 2006 starting...
CGLP_SYS_RSTPLL 00000010:02008470
prgramming PLL
Reset PLL


LinuxBIOS-1.1.8.0Fallback Sex Mar  3 09:23:01 BRT 2006 starting...
CGLP_SYS_RSTPLL 00000019:07de0378
reboot from BIOS reset
Ram1.00
Ram2.00
Ram3
sdram_enable step 1
sdram_enable step 2
sdram_enable step 3
sdram_enable step 4
sdram_enable step 5
sdram_enable step 6
sdram_enable step 7
sdram_enable step 8
Ram4
Testing DRAM : 00000000-000a0000
DRAM fill: 00000000-000a0000
00000000 00010000 00020000 00030000 00040000 00050000 00060000 00070000
00080000 00090000 000a0000
DRAM filled
DRAM verify: 00000000-000a0000
00000000 00010000 00020000 00030000 00040000 00050000 00060000 00070000
00080000 00090000 000a0000
DRAM verified
Done.
Copying LinuxBIOS to ram.
Jumping to LinuxBIOS.
LinuxBIOS-1.1.8.0Fallback Sex Mar  3 09:23:01 BRT 2006 booting...
clocks_per_usec: 643
Enumerating buses...
Finding PCI configuration type.
PCI: Sanity check failed
pci_check_direct failed



Thanks.


Jardel.



Li-Ta Lo wrote:

>>>>Dear Mr. Li-Ta Lo,
>>>>
>>>>
>>>>    I've tried, but id didn't see any bytes on serial port 0 of the
>>>>CS5535.
>>>>    What is the hardware description of rumba target ?  I'm trying it
>>>>on the AMD RDK THINCLIENT based on GEODE GX2.
>>>>
>>>>
>>>>        
>>>>
>>>I think our board is the thinclient RDK with the winbond superio duaght
>>>board. Did you get the lastest code? Does it compile?
>>>
>>>
>>>      
>>>
>>My Daught board (LPC Expansion) uses the NSC PC87364, the wich is the
>>same WINBOND 87364. I compile successfull the last code, but i was not
>>able to see anything on serial port 0 of CS5535. But something is clear
>>for me now: if you don't have VSA initialized, you aren't able for using
>>serial port of companion chip.  As a matter of fact, you are probably
>>sending the bytes to port 0 of winbond super i/o, isn' t ?
>>Are you really sending the debug output for port 0 of  WINBOND 87364 ?
>>
>>    
>>
>
>Yes, I am sending to the serial port on the superio chip, not the
>internal UART of GX/CS5535.
>
>Ollie
>
>
>  
>




From bari at onelabs.com  Fri Mar 10 22:47:02 2006
From: bari at onelabs.com (Bari Ari)
Date: Fri, 10 Mar 2006 15:47:02 -0600
Subject: [LinuxBIOS] RES:  RES:  Rumba target and AMD RDK THINCLIENT
In-Reply-To: <4411EC4E.9010602@onelabs.com>
References: <200602241929.k1OJSxT6009241@proofpoint2.lanl.gov>	<1141064948.19385.51.camel@logarithm.lanl.gov>	<4411626C.8020304@lesc.ufc.br>	<20060310154650.389.qmail@cdy.org>	<4411A1DD.4060905@onelabs.com>	<4411B070.5090002@lesc.ufc.br>	<200602241929.k1OJSxT6009241@proofpoint2.lanl.gov>	<1141064948.19385.51.camel@logarithm.lanl.gov>	<4411A1DD.4060905@onelabs.com>	<10233.128.165.0.81.1142010827.squirrel@webmail.lanl.gov>	<20060310193448.27424.qmail@cdy.org>
	<4411EC4E.9010602@onelabs.com>
Message-ID: <4411F3D6.1040402@onelabs.com>

Bari Ari wrote:
> I still have all the BLDT kits from NSC. If we can use the VSA binaries 
> the same as VideoBIOS then we are set.

News Update!!

VSA source and Xpressloader source is now available through the AMD 
Geode developer site!

-Bari




From rminnich at lanl.gov  Fri Mar 10 22:49:17 2006
From: rminnich at lanl.gov (Ronald G Minnich)
Date: Fri, 10 Mar 2006 14:49:17 -0700
Subject: [LinuxBIOS] RES:  RES:  Rumba target and AMD RDK THINCLIENT
In-Reply-To: <4411F3D6.1040402@onelabs.com>
References: <200602241929.k1OJSxT6009241@proofpoint2.lanl.gov>	<1141064948.19385.51.camel@logarithm.lanl.gov>	<4411626C.8020304@lesc.ufc.br>	<20060310154650.389.qmail@cdy.org>	<4411A1DD.4060905@onelabs.com>	<4411B070.5090002@lesc.ufc.br>	<200602241929.k1OJSxT6009241@proofpoint2.lanl.gov>	<1141064948.19385.51.camel@logarithm.lanl.gov>	<4411A1DD.4060905@onelabs.com>	<10233.128.165.0.81.1142010827.squirrel@webmail.lanl.gov>	<20060310193448.27424.qmail@cdy.org>	<4411EC4E.9010602@onelabs.com>
	<4411F3D6.1040402@onelabs.com>
Message-ID: <4411F45D.7020908@lanl.gov>

Bari Ari wrote:
> Bari Ari wrote:
> 
>>I still have all the BLDT kits from NSC. If we can use the VSA binaries 
>>the same as VideoBIOS then we are set.
> 
> 
> News Update!!
> 
> VSA source and Xpressloader source is now available through the AMD 
> Geode developer site!


with or without the clickthrough license?

As Ollie mentioned, we need help. It would be a real testament to this 
community if you all can give us a hand with this -- some of you already 
are. It would be great to deliver linuxbios to OLPC in about one month. 
That's when they need it.

Also, I should thank both AMD and the OLPC guys -- they have been very 
supportive of this work.

thanks

ron



From jardel at lesc.ufc.br  Fri Mar 10 23:05:12 2006
From: jardel at lesc.ufc.br (jardel)
Date: Fri, 10 Mar 2006 19:05:12 -0300
Subject: [LinuxBIOS] RES:  RES:  Rumba target and AMD RDK THINCLIENT
In-Reply-To: <4411F3D6.1040402@onelabs.com>
References: <200602241929.k1OJSxT6009241@proofpoint2.lanl.gov>	<1141064948.19385.51.camel@logarithm.lanl.gov>	<4411626C.8020304@lesc.ufc.br>	<20060310154650.389.qmail@cdy.org>	<4411A1DD.4060905@onelabs.com>	<4411B070.5090002@lesc.ufc.br>	<200602241929.k1OJSxT6009241@proofpoint2.lanl.gov>	<1141064948.19385.51.camel@logarithm.lanl.gov>	<4411A1DD.4060905@onelabs.com>	<10233.128.165.0.81.1142010827.squirrel@webmail.lanl.gov>	<20060310193448.27424.qmail@cdy.org>	<4411EC4E.9010602@onelabs.com>
	<4411F3D6.1040402@onelabs.com>
Message-ID: <4411F818.5020204@lesc.ufc.br>

Dear Bari,


   Please,  just point me where. I've access to the site, but i'm not
able to find it !!!!!!!!!


Thanks.


Jardel.



Bari Ari wrote:

>Bari Ari wrote:
>  
>
>>I still have all the BLDT kits from NSC. If we can use the VSA binaries 
>>the same as VideoBIOS then we are set.
>>    
>>
>
>News Update!!
>
>VSA source and Xpressloader source is now available through the AMD 
>Geode developer site!
>
>-Bari
>
>
>  
>




From smithbone at gmail.com  Fri Mar 10 23:12:48 2006
From: smithbone at gmail.com (Richard Smith)
Date: Fri, 10 Mar 2006 16:12:48 -0600
Subject: [LinuxBIOS] RES: RES: Rumba target and AMD RDK THINCLIENT
In-Reply-To: <4411F45D.7020908@lanl.gov>
References: <4411626C.8020304@lesc.ufc.br> <4411B070.5090002@lesc.ufc.br>
	<200602241929.k1OJSxT6009241@proofpoint2.lanl.gov>
	<1141064948.19385.51.camel@logarithm.lanl.gov>
	<4411A1DD.4060905@onelabs.com>
	<10233.128.165.0.81.1142010827.squirrel@webmail.lanl.gov>
	<20060310193448.27424.qmail@cdy.org> <4411EC4E.9010602@onelabs.com>
	<4411F3D6.1040402@onelabs.com> <4411F45D.7020908@lanl.gov>
Message-ID: <8a0c36780603101412p39786ff6s8dddf4e43c63752b@mail.gmail.com>

>
> As Ollie mentioned, we need help. It would be a real testament to this
> community if you all can give us a hand with this -- some of you already
> are. It would be great to deliver linuxbios to OLPC in about one month.
> That's when they need it.
>

Which board are you using and How can I get one?

--
Richard A. Smith

From bari at onelabs.com  Fri Mar 10 23:14:37 2006
From: bari at onelabs.com (Bari Ari)
Date: Fri, 10 Mar 2006 16:14:37 -0600
Subject: [LinuxBIOS] RES:  RES:  Rumba target and AMD RDK THINCLIENT
In-Reply-To: <4411F45D.7020908@lanl.gov>
References: <200602241929.k1OJSxT6009241@proofpoint2.lanl.gov>	<1141064948.19385.51.camel@logarithm.lanl.gov>	<4411626C.8020304@lesc.ufc.br>	<20060310154650.389.qmail@cdy.org>	<4411A1DD.4060905@onelabs.com>	<4411B070.5090002@lesc.ufc.br>	<200602241929.k1OJSxT6009241@proofpoint2.lanl.gov>	<1141064948.19385.51.camel@logarithm.lanl.gov>	<4411A1DD.4060905@onelabs.com>	<10233.128.165.0.81.1142010827.squirrel@webmail.lanl.gov>	<20060310193448.27424.qmail@cdy.org>	<4411EC4E.9010602@onelabs.com>
	<4411F3D6.1040402@onelabs.com> <4411F45D.7020908@lanl.gov>
Message-ID: <4411FA4D.7010606@onelabs.com>

Ronald G Minnich wrote:
> Bari Ari wrote:

>> VSA source and Xpressloader source is now available through the AMD 
>> Geode developer site!
> 
> 
> 
> with or without the clickthrough license?

With a clickthrough .... it's a start.

Are the libraries un ugly assembly?

Yes, some of the libraries are in ASM and others in C.

-Bari



From rminnich at lanl.gov  Fri Mar 10 23:35:26 2006
From: rminnich at lanl.gov (Ronald G Minnich)
Date: Fri, 10 Mar 2006 15:35:26 -0700
Subject: [LinuxBIOS] RES: RES: Rumba target and AMD RDK THINCLIENT
In-Reply-To: <8a0c36780603101412p39786ff6s8dddf4e43c63752b@mail.gmail.com>
References: <4411626C.8020304@lesc.ufc.br> <4411B070.5090002@lesc.ufc.br>	
	<200602241929.k1OJSxT6009241@proofpoint2.lanl.gov>	
	<1141064948.19385.51.camel@logarithm.lanl.gov>	
	<4411A1DD.4060905@onelabs.com>	
	<10233.128.165.0.81.1142010827.squirrel@webmail.lanl.gov>	
	<20060310193448.27424.qmail@cdy.org>
	<4411EC4E.9010602@onelabs.com>	 <4411F3D6.1040402@onelabs.com>
	<4411F45D.7020908@lanl.gov>
	<8a0c36780603101412p39786ff6s8dddf4e43c63752b@mail.gmail.com>
Message-ID: <4411FF2E.6080000@lanl.gov>

Richard Smith wrote:

> Which board are you using and How can I get one?

The lippert cool frontrunner is a good start.


Folks, linuxbios just got its first-ever design win (that I know of ...) 
It's going to be the first, and possibly only, BIOS to run on OLPC. What 
clinched the decision was capability: it is intrinsically easier to do 
clever things on a platform with an open source bios!

Now, of course, we have to deliver. If you have a gx2 system and want to 
help make this all go, we can use the help. This is a great opportunity 
for the open source community -- let's make the most of it.

thanks

ron



From jardel at lesc.ufc.br  Sat Mar 11 00:49:28 2006
From: jardel at lesc.ufc.br (jardel at lesc.ufc.br)
Date: Fri, 10 Mar 2006 20:49:28 -0300 (BRT)
Subject: [LinuxBIOS] RES:  RES:  Rumba target and AMD RDK THINCLIENT
In-Reply-To: <4411FA4D.7010606@onelabs.com>
References: <200602241929.k1OJSxT6009241@proofpoint2.lanl.gov>	<1141064948.19385.51.camel@logarithm.lanl.gov>	<4411626C.8020304@lesc.ufc.br>	<20060310154650.389.qmail@cdy.org>	<4411A1DD.4060905@onelabs.com>	<4411B070.5090002@lesc.ufc.br>	<200602241929.k1OJSxT6009241@proofpoint2.lanl.gov>	<1141064948.19385.51.camel@logarithm.lanl.gov>	<4411A1DD.4060905@onelabs.com>	<10233.128.165.0.81.1142010827.squirrel@webmail.lanl.gov>	<20060310193448.27424.qmail@cdy.org>	<4411EC4E.9010602@onelabs.com>
	<4411F3D6.1040402@onelabs.com> <4411F45D.7020908@lanl.gov>
	<4411FA4D.7010606@onelabs.com>
Message-ID: <3851.201.9.20.194.1142034568.squirrel@www.lesc.ufc.br>

Ok Bari,


   I got download. It where on insyde site.


Thanks.


Jardel.

> Ronald G Minnich wrote:
>> Bari Ari wrote:
>
>>> VSA source and Xpressloader source is now available through the AMD
>>> Geode developer site!
>>
>>
>>
>> with or without the clickthrough license?
>
> With a clickthrough .... it's a start.
>
> Are the libraries un ugly assembly?
>
> Yes, some of the libraries are in ASM and others in C.
>
> -Bari
>
> --
> linuxbios mailing list
> linuxbios at linuxbios.org
> http://www.openbios.org/mailman/listinfo/linuxbios
>





From bari at onelabs.com  Sat Mar 11 02:19:15 2006
From: bari at onelabs.com (Bari Ari)
Date: Fri, 10 Mar 2006 19:19:15 -0600
Subject: [LinuxBIOS] RES:  RES:  Rumba target and AMD RDK THINCLIENT
In-Reply-To: <3851.201.9.20.194.1142034568.squirrel@www.lesc.ufc.br>
References: <200602241929.k1OJSxT6009241@proofpoint2.lanl.gov>	<1141064948.19385.51.camel@logarithm.lanl.gov>	<4411626C.8020304@lesc.ufc.br>	<20060310154650.389.qmail@cdy.org>	<4411A1DD.4060905@onelabs.com>	<4411B070.5090002@lesc.ufc.br>	<200602241929.k1OJSxT6009241@proofpoint2.lanl.gov>	<1141064948.19385.51.camel@logarithm.lanl.gov>	<4411A1DD.4060905@onelabs.com>	<10233.128.165.0.81.1142010827.squirrel@webmail.lanl.gov>	<20060310193448.27424.qmail@cdy.org>	<4411EC4E.9010602@onelabs.com>
	<4411F3D6.1040402@onelabs.com> <4411F45D.7020908@lanl.gov>
	<4411FA4D.7010606@onelabs.com>
	<3851.201.9.20.194.1142034568.squirrel@www.lesc.ufc.br>
Message-ID: <44122593.7080904@onelabs.com>

jardel at lesc.ufc.br wrote:
> Ok Bari,
> 
> 
>    I got download. It where on insyde site.

It's in the Hawk section.

-Bari



From ollie at lanl.gov  Sat Mar 11 06:38:35 2006
From: ollie at lanl.gov (Li-Ta Lo)
Date: Fri, 10 Mar 2006 22:38:35 -0700 (MST)
Subject: [LinuxBIOS] RES:  RES:  Rumba target and AMD RDK THINCLIENT
In-Reply-To: <4411F2D2.70706@lesc.ufc.br>
References: <200602241929.k1OJSxT6009241@proofpoint2.lanl.gov>  
	<1141064948.19385.51.camel@logarithm.lanl.gov>  
	<4411626C.8020304@lesc.ufc.br>	<8998.128.165.0.81.1142010458.squirrel@webmail.lanl.gov>	<4411C1CC.1000702@lesc.ufc.br>
	<25687.128.165.0.81.1142016301.squirrel@webmail.lanl.gov>
	<4411F2D2.70706@lesc.ufc.br>
Message-ID: <45873.128.165.0.81.1142055515.squirrel@webmail.lanl.gov>

> Dear Ollie,
>
>
>    It works !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
>    See below the output that i get at serial port of super i/o:
>    Please, do same comment about the output. Is the erro pointed below
> according to the development stage of project or not ?
>
>

The "error" message is 100% normal. That is exactly what I got here.
Becuase there is acutally no PCI CS in Geode, the PCI enumeration
code in LinuxBIOS blows up.

We got to have VSA loaded before LB.

Ollie





From jardel at lesc.ufc.br  Sat Mar 11 11:42:20 2006
From: jardel at lesc.ufc.br (jardel at lesc.ufc.br)
Date: Sat, 11 Mar 2006 07:42:20 -0300 (BRT)
Subject: [LinuxBIOS] RES:  RES:  Rumba target and AMD RDK THINCLIENT
In-Reply-To: <45873.128.165.0.81.1142055515.squirrel@webmail.lanl.gov>
References: <200602241929.k1OJSxT6009241@proofpoint2.lanl.gov>  
	<1141064948.19385.51.camel@logarithm.lanl.gov>  
	<4411626C.8020304@lesc.ufc.br>	<8998.128.165.0.81.1142010458.squirrel@webmail.lanl.gov>	<4411C1CC.1000702@lesc.ufc.br>
	<25687.128.165.0.81.1142016301.squirrel@webmail.lanl.gov>
	<4411F2D2.70706@lesc.ufc.br>
	<45873.128.165.0.81.1142055515.squirrel@webmail.lanl.gov>
Message-ID: <1992.201.9.38.169.1142073740.squirrel@www.lesc.ufc.br>

Ok ollie,

  Very tahnk you for your excelent support.
  There is on thing i didn?t understand yet.
  The hardware i?ve done the test is GEODE GX + CS5535 + PC87364, while
RUMBA is GEODE GX + CS5536 + W83627.
  So, i don?t understand why is running 100%. Please, explain.
  What hardware are you using ?
  OLPC computer will be based on RUMBA ?
  I?m available for helping with development or debugging. I have an FS2
JTAG debugger too. But i don?t have RUMBA hardware.


Thanks.


Jardel.

>> Dear Ollie,
>>
>>
>>    It works !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
>>    See below the output that i get at serial port of super i/o:
>>    Please, do same comment about the output. Is the erro pointed below
>> according to the development stage of project or not ?
>>
>>
>
> The "error" message is 100% normal. That is exactly what I got here.
> Becuase there is acutally no PCI CS in Geode, the PCI enumeration
> code in LinuxBIOS blows up.
>
> We got to have VSA loaded before LB.
>
> Ollie
>
>
>
> --
> linuxbios mailing list
> linuxbios at linuxbios.org
> http://www.openbios.org/mailman/listinfo/linuxbios
>





From ollie at lanl.gov  Sat Mar 11 17:13:07 2006
From: ollie at lanl.gov (Li-Ta Lo)
Date: Sat, 11 Mar 2006 09:13:07 -0700 (MST)
Subject: [LinuxBIOS] RES:  RES:  Rumba target and AMD RDK THINCLIENT
In-Reply-To: <1992.201.9.38.169.1142073740.squirrel@www.lesc.ufc.br>
References: <200602241929.k1OJSxT6009241@proofpoint2.lanl.gov> 
	<1141064948.19385.51.camel@logarithm.lanl.gov> 
	<4411626C.8020304@lesc.ufc.br>	<8998.128.165.0.81.1142010458.squirrel@webmail.lanl.gov>	<4411C1CC.1000702@lesc.ufc.br><25687.128.165.0.81.1142016301.squirrel@webmail.lanl.gov><4411F2D2.70706@lesc.ufc.br><45873.128.165.0.81.1142055515.squirrel@webmail.lanl.gov>
	<1992.201.9.38.169.1142073740.squirrel@www.lesc.ufc.br>
Message-ID: <8475.128.165.0.81.1142093587.squirrel@webmail.lanl.gov>

> Ok ollie,
>
>   Very tahnk you for your excelent support.
>   There is on thing i didn?t understand yet.
>   The hardware i?ve done the test is GEODE GX + CS5535 + PC87364, while
> RUMBA is GEODE GX + CS5536 + W83627.
>   So, i don?t understand why is running 100%. Please, explain.

The LB is not actually working on rumba yet. You have the same output
as me.

>   What hardware are you using ?

Rumba.

>   OLPC computer will be based on RUMBA ?

They will base their development on rumba but they will have
their own hardware design eventually.

>   I?m available for helping with development or debugging. I have an FS2
> JTAG debugger too. But i don?t have RUMBA hardware.
>

I don't think there will be so much difference between your board and
rumba. I really appreciated your help.





From hachet.nicolas at free.fr  Sun Mar 12 23:17:17 2006
From: hachet.nicolas at free.fr (Nicolas HACHET)
Date: Sun, 12 Mar 2006 23:17:17 +0100
Subject: [LinuxBIOS] Old L440GX is it still bootable ?
Message-ID: <1142201108.8366.9.camel@localhost.localdomain>

Hello everyone on the list,

My name is Nicolas and I'm wondering about booting an old Intel L440GX
with dual PIII-850 and 2 Gb RAM off a USB Key ?

I guess I'm a little outdated but I got the hardware working and this
is just for me the occasion to get a use for the old pal.

Thanks for any answer,

Nico.




From nicolas.s.hachet at wanadoo.fr  Sun Mar 12 23:19:26 2006
From: nicolas.s.hachet at wanadoo.fr (Nicolas HACHET)
Date: Sun, 12 Mar 2006 23:19:26 +0100
Subject: [LinuxBIOS] Old L440GX is it still bootable under LinuxBios
Message-ID: <1142201967.8366.11.camel@localhost.localdomain>

Hello everyone on the list,

My name is Nicolas and I'm wondering about booting an old Intel L440GX
with dual PIII-850 and 2 Gb RAM off a USB Key ?

I guess I'm a little outdated but I got the hardware working and this
is just for me the occasion to get a use for the old pal.

Thanks for any answer,

Nico.




From rminnich at gmail.com  Mon Mar 13 02:55:15 2006
From: rminnich at gmail.com (ron minnich)
Date: Sun, 12 Mar 2006 18:55:15 -0700
Subject: [LinuxBIOS] Old L440GX is it still bootable under LinuxBios
In-Reply-To: <1142201967.8366.11.camel@localhost.localdomain>
References: <1142201967.8366.11.camel@localhost.localdomain>
Message-ID: <13426df10603121755k6283267eu5cf9e9c90b6e80d8@mail.gmail.com>

You'll just have to get the LinuxBIOS v1 and try it. I don't know any more
-- last 440GX I worked on was
5 years ago!

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

From jardel at lesc.ufc.br  Mon Mar 13 13:04:13 2006
From: jardel at lesc.ufc.br (jardel)
Date: Mon, 13 Mar 2006 09:04:13 -0300
Subject: [LinuxBIOS] GEODE VSA II COMPILATION
Message-ID: <44155FBD.3080202@lesc.ufc.br>

Dear,


   I downloaded the source code of VSA  II for hawk and compiled it
without problems. So, I would like share some information:


    1. The license terms are very restrict.
    2. I just follow the "VSA 2 ADAPTATION guide" available  on amd
site. So, I used MSVC 1.52 and MASM 6.11D
    3. It was necessary download SLIBC7.LIB form internet.
    4. It doesn't seems all the VSM are available. For example, sound VSM.
    5. Xpressloader, what seems to be entire source code bios, is to
available on insyde site.


Please, feel free to comment.


Thanks.


Jardel.



From jg at freedesktop.org  Sun Mar 12 13:31:51 2006
From: jg at freedesktop.org (Jim Gettys)
Date: Sun, 12 Mar 2006 07:31:51 -0500
Subject: [LinuxBIOS] OLPC hardware specification information
Message-ID: <1142166712.14329.161.camel@localhost.localdomain>

Is located here:

http://wiki.laptop.org/wiki/Hardware_specification

The board has started layout.
			- Regards,
				- Jim





From rminnich at lanl.gov  Mon Mar 13 16:17:34 2006
From: rminnich at lanl.gov (Ronald G Minnich)
Date: Mon, 13 Mar 2006 08:17:34 -0700
Subject: [LinuxBIOS] GEODE VSA II COMPILATION
In-Reply-To: <44155FBD.3080202@lesc.ufc.br>
References: <44155FBD.3080202@lesc.ufc.br>
Message-ID: <44158D0E.60302@lanl.gov>

jardel wrote:

> Please, feel free to comment.

we will of course not use source code from insyde web site, only that 
provided by AMD.

ron



From bari at onelabs.com  Mon Mar 13 16:51:32 2006
From: bari at onelabs.com (Bari Ari)
Date: Mon, 13 Mar 2006 09:51:32 -0600
Subject: [LinuxBIOS] GEODE VSA II COMPILATION
In-Reply-To: <44155FBD.3080202@lesc.ufc.br>
References: <44155FBD.3080202@lesc.ufc.br>
Message-ID: <44159504.5020206@onelabs.com>

jardel wrote:
> Dear,
> 
> 
>    I downloaded the source code of VSA  II for hawk and compiled it
> without problems. So, I would like share some information:
> 
> 
>     1. The license terms are very restrict.

I found it interesting that the license only mentions object and not source.

>     4. It doesn't seems all the VSM are available. For example, sound VSM.

Audio may be able to be extracted the same as VideoBIOS. PCI and power 
management seem to be there.

-Bari



From bari at onelabs.com  Mon Mar 13 16:56:53 2006
From: bari at onelabs.com (Bari Ari)
Date: Mon, 13 Mar 2006 09:56:53 -0600
Subject: [LinuxBIOS] GEODE VSA II COMPILATION
In-Reply-To: <44158D0E.60302@lanl.gov>
References: <44155FBD.3080202@lesc.ufc.br> <44158D0E.60302@lanl.gov>
Message-ID: <44159645.10802@onelabs.com>

Ronald G Minnich wrote:

> we will of course not use source code from insyde web site, only that 
> provided by AMD.

The copyright on the VSA source files I've seen are all by National 
Semiconductor.

Who is the legal contact at OLPC? They just need to get AMD to make this 
clear for everyone involved in the OLPC BIOS development.

-Bari



From bari at onelabs.com  Mon Mar 13 17:02:39 2006
From: bari at onelabs.com (Bari Ari)
Date: Mon, 13 Mar 2006 10:02:39 -0600
Subject: [LinuxBIOS] OLPC hardware specification information
In-Reply-To: <1142166712.14329.161.camel@localhost.localdomain>
References: <1142166712.14329.161.camel@localhost.localdomain>
Message-ID: <4415979F.4040909@onelabs.com>

Jim,

What's the status of any legal agreements with AMD on using their BIOS 
or VSA source for the OLPC project?

-Bari

Jim Gettys wrote:
> Is located here:
> 
> http://wiki.laptop.org/wiki/Hardware_specification
> 
> The board has started layout.
> 			- Regards,
> 				- Jim




From jg at laptop.org  Mon Mar 13 18:21:02 2006
From: jg at laptop.org (Jim Gettys)
Date: Mon, 13 Mar 2006 12:21:02 -0500
Subject: [LinuxBIOS] OLPC hardware specification information
In-Reply-To: <4415979F.4040909@onelabs.com>
References: <1142166712.14329.161.camel@localhost.localdomain>
	<4415979F.4040909@onelabs.com>
Message-ID: <1142270463.9254.89.camel@localhost.localdomain>

On a teleconference on March 2, AMD said that we can have/use any of
their code (e.g. VSA sources, as I understand it) that we need, and that
that code could be incorporated into LinuxBIOS.

What is more, they said that they had ensured that they owned all the IP
associated with this code since Geode's acquisition by AMD.

They also said that LinuxBIOS was now considered a peer of any
commercial BIOS and they would support the development. I know from
subsequent mail that AMD's expert on LinuxBIOS in the Opteron group has
spent a day with the Geode team to try to get them up to speed.

I don't know if AMD has a BIOS of their own; heretofore people have used
commercial BIOS's on Geode.  (says me the non-BIOS guy who usually
pushes packets and pixels around).

AMD, BTW, is one of the corporate sponsors of OLPC.  And I meet with
David Wahl of AMD later this week, who is in charge of the group in AMD
who support BIOS developers.
				Regards,
					- Jim Gettys
					OLPC





On Mon, 2006-03-13 at 10:02 -0600, Bari Ari wrote:
> Jim,
> 
> What's the status of any legal agreements with AMD on using their BIOS 
> or VSA source for the OLPC project?
> 
> -Bari
> 
> Jim Gettys wrote:
> > Is located here:
> > 
> > http://wiki.laptop.org/wiki/Hardware_specification
> > 
> > The board has started layout.
> > 			- Regards,
> > 				- Jim
> 
-- 
Jim Gettys
One Laptop Per Child





From rminnich at lanl.gov  Mon Mar 13 18:27:17 2006
From: rminnich at lanl.gov (Ronald G Minnich)
Date: Mon, 13 Mar 2006 10:27:17 -0700
Subject: [LinuxBIOS] OLPC hardware specification information
In-Reply-To: <1142270463.9254.89.camel@localhost.localdomain>
References: <1142166712.14329.161.camel@localhost.localdomain>	<4415979F.4040909@onelabs.com>
	<1142270463.9254.89.camel@localhost.localdomain>
Message-ID: <4415AB75.1070600@lanl.gov>

Jim Gettys wrote:

> What is more, they said that they had ensured that they owned all the IP
> associated with this code since Geode's acquisition by AMD.

they really do need to fix things so that all the stuff is at AMD, not 
insyde. It's confusing everyone.

Or, we can host it at linuxbios.org, no problem there.

thanks

ron



From jg at laptop.org  Mon Mar 13 18:36:36 2006
From: jg at laptop.org (Jim Gettys)
Date: Mon, 13 Mar 2006 12:36:36 -0500
Subject: [LinuxBIOS] OLPC hardware specification information
In-Reply-To: <4415979F.4040909@onelabs.com>
References: <1142166712.14329.161.camel@localhost.localdomain>
	<4415979F.4040909@onelabs.com>
Message-ID: <1142271396.9254.102.camel@localhost.localdomain>

Oh, and of course you know that AMD bought Geode from Nat. Semi...
				- Jim


On Mon, 2006-03-13 at 10:02 -0600, Bari Ari wrote:
> Jim,
> 
> What's the status of any legal agreements with AMD on using their BIOS 
> or VSA source for the OLPC project?
> 
> -Bari
> 
> Jim Gettys wrote:
> > Is located here:
> > 
> > http://wiki.laptop.org/wiki/Hardware_specification
> > 
> > The board has started layout.
> > 			- Regards,
> > 				- Jim
> 
-- 
Jim Gettys
One Laptop Per Child





From ollie at lanl.gov  Mon Mar 13 19:01:51 2006
From: ollie at lanl.gov (Li-Ta Lo)
Date: Mon, 13 Mar 2006 11:01:51 -0700
Subject: [LinuxBIOS] RES:  RES:  Rumba target and AMD RDK THINCLIENT
In-Reply-To: <1992.201.9.38.169.1142073740.squirrel@www.lesc.ufc.br>
References: <200602241929.k1OJSxT6009241@proofpoint2.lanl.gov>
	<1141064948.19385.51.camel@logarithm.lanl.gov>
	<4411626C.8020304@lesc.ufc.br>
	<8998.128.165.0.81.1142010458.squirrel@webmail.lanl.gov>
	<4411C1CC.1000702@lesc.ufc.br>
	<25687.128.165.0.81.1142016301.squirrel@webmail.lanl.gov>
	<4411F2D2.70706@lesc.ufc.br>
	<45873.128.165.0.81.1142055515.squirrel@webmail.lanl.gov>
	<1992.201.9.38.169.1142073740.squirrel@www.lesc.ufc.br>
Message-ID: <1142272911.12025.0.camel@logarithm.lanl.gov>

On Sat, 2006-03-11 at 07:42 -0300, jardel at lesc.ufc.br wrote:
> Ok ollie,
> 
>   Very tahnk you for your excelent support.
>   There is on thing i didn?t understand yet.
>   The hardware i?ve done the test is GEODE GX + CS5535 + PC87364, while
> RUMBA is GEODE GX + CS5536 + W83627.
>   So, i don?t understand why is running 100%. Please, explain.
>   What hardware are you using ?
>   OLPC computer will be based on RUMBA ?
>   I?m available for helping with development or debugging. I have an FS2
> JTAG debugger too. But i don?t have RUMBA hardware.
> 
> 

Where did you get the JTAG debugger for GX? We would like to order one.
Does it come with software (Windows?)?

-- 
Li-Ta Lo <ollie at lanl.gov>
Los Alamos National Lab




From jardel at lesc.ufc.br  Mon Mar 13 19:29:40 2006
From: jardel at lesc.ufc.br (jardel)
Date: Mon, 13 Mar 2006 15:29:40 -0300
Subject: [LinuxBIOS] RES:  RES:  Rumba target and AMD RDK THINCLIENT
In-Reply-To: <1142272911.12025.0.camel@logarithm.lanl.gov>
References: <200602241929.k1OJSxT6009241@proofpoint2.lanl.gov>	<1141064948.19385.51.camel@logarithm.lanl.gov>	<4411626C.8020304@lesc.ufc.br>	<8998.128.165.0.81.1142010458.squirrel@webmail.lanl.gov>	<4411C1CC.1000702@lesc.ufc.br>	<25687.128.165.0.81.1142016301.squirrel@webmail.lanl.gov>	<4411F2D2.70706@lesc.ufc.br>	<45873.128.165.0.81.1142055515.squirrel@webmail.lanl.gov>	<1992.201.9.38.169.1142073740.squirrel@www.lesc.ufc.br>
	<1142272911.12025.0.camel@logarithm.lanl.gov>
Message-ID: <4415BA14.9010203@lesc.ufc.br>

Dear Li-ta Lo,


   I've acquired my jtag debugger direct from fs2: www.fs2.com

Just for your rereference, the prices for two jtag debuggers were:

1       SNAV-GX-ETH                          USD 2.621,00
2       SUP-1YR-R                                USD 371,00
3       GX-EXDI                                    USD 371,00

The itens 2 and 3 are software of debugger and license for gdb,
respectively.


The software of the debugger runs in tcl/tk in rwindows (argh!). I never
tried run it in linux.


Jardel.


Li-Ta Lo wrote:

>On Sat, 2006-03-11 at 07:42 -0300, jardel at lesc.ufc.br wrote:
>  
>
>>Ok ollie,
>>
>>  Very tahnk you for your excelent support.
>>  There is on thing i didn?t understand yet.
>>  The hardware i?ve done the test is GEODE GX + CS5535 + PC87364, while
>>RUMBA is GEODE GX + CS5536 + W83627.
>>  So, i don?t understand why is running 100%. Please, explain.
>>  What hardware are you using ?
>>  OLPC computer will be based on RUMBA ?
>>  I?m available for helping with development or debugging. I have an FS2
>>JTAG debugger too. But i don?t have RUMBA hardware.
>>
>>
>>    
>>
>
>Where did you get the JTAG debugger for GX? We would like to order one.
>Does it come with software (Windows?)?
>
>  
>


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 256 bytes
Desc: OpenPGP digital signature
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20060313/5b1de557/attachment.sig>

From jardel at lesc.ufc.br  Mon Mar 13 19:41:58 2006
From: jardel at lesc.ufc.br (jardel)
Date: Mon, 13 Mar 2006 15:41:58 -0300
Subject: [LinuxBIOS] RES:  RES:  Rumba target and AMD RDK THINCLIENT
In-Reply-To: <4415BA14.9010203@lesc.ufc.br>
References: <200602241929.k1OJSxT6009241@proofpoint2.lanl.gov>	<1141064948.19385.51.camel@logarithm.lanl.gov>	<4411626C.8020304@lesc.ufc.br>	<8998.128.165.0.81.1142010458.squirrel@webmail.lanl.gov>	<4411C1CC.1000702@lesc.ufc.br>	<25687.128.165.0.81.1142016301.squirrel@webmail.lanl.gov>	<4411F2D2.70706@lesc.ufc.br>	<45873.128.165.0.81.1142055515.squirrel@webmail.lanl.gov>	<1992.201.9.38.169.1142073740.squirrel@www.lesc.ufc.br>	<1142272911.12025.0.camel@logarithm.lanl.gov>
	<4415BA14.9010203@lesc.ufc.br>
Message-ID: <4415BCF6.8000209@lesc.ufc.br>

Dear,

  I'm sorry. These are the prices for ONE jtag debugger and not for TWO.

Thanks.


Jardel.


jardel wrote:

>Dear Li-ta Lo,
>
>
>   I've acquired my jtag debugger direct from fs2: www.fs2.com
>
>Just for your rereference, the prices for two jtag debuggers were:
>
>1       SNAV-GX-ETH                          USD 2.621,00
>2       SUP-1YR-R                                USD 371,00
>3       GX-EXDI                                    USD 371,00
>
>The itens 2 and 3 are software of debugger and license for gdb,
>respectively.
>
>
>The software of the debugger runs in tcl/tk in rwindows (argh!). I never
>tried run it in linux.
>
>
>Jardel.
>
>
>Li-Ta Lo wrote:
>
>  
>
>>On Sat, 2006-03-11 at 07:42 -0300, jardel at lesc.ufc.br wrote:
>> 
>>
>>    
>>
>>>Ok ollie,
>>>
>>> Very tahnk you for your excelent support.
>>> There is on thing i didn?t understand yet.
>>> The hardware i?ve done the test is GEODE GX + CS5535 + PC87364, while
>>>RUMBA is GEODE GX + CS5536 + W83627.
>>> So, i don?t understand why is running 100%. Please, explain.
>>> What hardware are you using ?
>>> OLPC computer will be based on RUMBA ?
>>> I?m available for helping with development or debugging. I have an FS2
>>>JTAG debugger too. But i don?t have RUMBA hardware.
>>>
>>>
>>>   
>>>
>>>      
>>>
>>Where did you get the JTAG debugger for GX? We would like to order one.
>>Does it come with software (Windows?)?
>>
>> 
>>
>>    
>>
>
>
>  
>




From hugo.mercier at laposte.net  Mon Mar 13 21:08:56 2006
From: hugo.mercier at laposte.net (Hugo MERCIER)
Date: Mon, 13 Mar 2006 21:08:56 +0100
Subject: [LinuxBIOS] Asus A7v600
Message-ID: <1142280536.6451.8.camel@localhost>

Hi,

Here is a patch against current 2191 SVN revision to add support for the
ASUS A7V600 motherboard in the flashrom utility.

It disables flash write protection and detects the Pm49fl002 flash chip.

Concerning the port of LinuxBios to this board, I've just been able to
add support for the SuperIO (ITE8212F) and activate the serial port ...
more to come.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: flashrom.2191.diff
Type: text/x-patch
Size: 3005 bytes
Desc: not available
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20060313/01bfd642/attachment.diff>

From smithbone at gmail.com  Mon Mar 13 20:33:01 2006
From: smithbone at gmail.com (Richard Smith)
Date: Mon, 13 Mar 2006 13:33:01 -0600
Subject: [LinuxBIOS] Old L440GX is it still bootable under LinuxBios
In-Reply-To: <13426df10603121755k6283267eu5cf9e9c90b6e80d8@mail.gmail.com>
References: <1142201967.8366.11.camel@localhost.localdomain>
	<13426df10603121755k6283267eu5cf9e9c90b6e80d8@mail.gmail.com>
Message-ID: <8a0c36780603131133k5902f6bfl28523deac9c3051e@mail.gmail.com>

On 3/12/06, ron minnich <rminnich at gmail.com> wrote:

> You'll just have to get the LinuxBIOS v1 and try it. I don't know any more
> -- last 440GX I worked on was
>  5 years ago!

I re-worked some of the memory detection routines for the 440BX.  A
lot of it came from the 440GX code that was in the tree when I
started.  IIRC there were some bit polarity issues when talking to the
smbus controller.  I've never looked at a GX datasheet so I don't know
if it was a bug or if they switched things for the BX.

The v1 code may work but if it dosen't you might want to compare the
routines with the code in the bitworks mainboard directory and give
them a try.

Somewhere in that compile chain I think there is problem with newer
gcc's so if it chokes then you may have to tweak the makefiles to use
gcc-2.95.  (or fix the code)

--
Richard A. Smith

From stepan at openbios.org  Mon Mar 13 22:44:24 2006
From: stepan at openbios.org (Stefan Reinauer)
Date: Mon, 13 Mar 2006 22:44:24 +0100
Subject: [LinuxBIOS] RES:  RES:  Rumba target and AMD RDK THINCLIENT
In-Reply-To: <1142272911.12025.0.camel@logarithm.lanl.gov>
References: <200602241929.k1OJSxT6009241@proofpoint2.lanl.gov>
	<1141064948.19385.51.camel@logarithm.lanl.gov>
	<4411626C.8020304@lesc.ufc.br>
	<8998.128.165.0.81.1142010458.squirrel@webmail.lanl.gov>
	<4411C1CC.1000702@lesc.ufc.br>
	<25687.128.165.0.81.1142016301.squirrel@webmail.lanl.gov>
	<4411F2D2.70706@lesc.ufc.br>
	<45873.128.165.0.81.1142055515.squirrel@webmail.lanl.gov>
	<1992.201.9.38.169.1142073740.squirrel@www.lesc.ufc.br>
	<1142272911.12025.0.camel@logarithm.lanl.gov>
Message-ID: <20060313214424.GA28385@openbios.org>

* Li-Ta Lo <ollie at lanl.gov> [060313 19:01]:
> Where did you get the JTAG debugger for GX? We would like to order one.
> Does it come with software (Windows?)?

There's quite some Linux software for JTAG and you can do quite some
things with just a more complex parallel cable

http://freshmeat.net/search/?q=jtag

None of the software knows about geode though, but since it's opensource
it might be worth a look.

Stefan




From bari at onelabs.com  Mon Mar 13 22:43:42 2006
From: bari at onelabs.com (Bari Ari)
Date: Mon, 13 Mar 2006 15:43:42 -0600
Subject: [LinuxBIOS] OLPC hardware specification information
In-Reply-To: <1142270463.9254.89.camel@localhost.localdomain>
References: <1142166712.14329.161.camel@localhost.localdomain>	
	<4415979F.4040909@onelabs.com>
	<1142270463.9254.89.camel@localhost.localdomain>
Message-ID: <4415E78E.2000905@onelabs.com>

Jim,

It's great that AMD stated that they have agreed to allow use of their 
VSA code during a teleconference.

Can you ask David Wahl with AMD to release all the source to the VSA 
including XpressGRAPHICS and XpressAUDIO under GPL or similar license?

-Bari

Jim Gettys wrote:
> On a teleconference on March 2, AMD said that we can have/use any of
> their code (e.g. VSA sources, as I understand it) that we need, and that
> that code could be incorporated into LinuxBIOS.
> 
> What is more, they said that they had ensured that they owned all the IP
> associated with this code since Geode's acquisition by AMD.
> 
> They also said that LinuxBIOS was now considered a peer of any
> commercial BIOS and they would support the development. I know from
> subsequent mail that AMD's expert on LinuxBIOS in the Opteron group has
> spent a day with the Geode team to try to get them up to speed.
> 
> I don't know if AMD has a BIOS of their own; heretofore people have used
> commercial BIOS's on Geode.  (says me the non-BIOS guy who usually
> pushes packets and pixels around).
> 
> AMD, BTW, is one of the corporate sponsors of OLPC.  And I meet with
> David Wahl of AMD later this week, who is in charge of the group in AMD
> who support BIOS developers.
> 				Regards,
> 					- Jim Gettys
> 					OLPC
> 
> 
> 
> 
> 
> On Mon, 2006-03-13 at 10:02 -0600, Bari Ari wrote:
> 
>>Jim,
>>
>>What's the status of any legal agreements with AMD on using their BIOS 
>>or VSA source for the OLPC project?
>>
>>-Bari
>>
>>Jim Gettys wrote:
>>
>>>Is located here:
>>>
>>>http://wiki.laptop.org/wiki/Hardware_specification
>>>
>>>The board has started layout.
>>>			- Regards,
>>>				- Jim
>>



From jg at laptop.org  Mon Mar 13 23:03:48 2006
From: jg at laptop.org (Jim Gettys)
Date: Mon, 13 Mar 2006 17:03:48 -0500
Subject: [LinuxBIOS] OLPC hardware specification information
In-Reply-To: <4415E78E.2000905@onelabs.com>
References: <1142166712.14329.161.camel@localhost.localdomain>
	<4415979F.4040909@onelabs.com>
	<1142270463.9254.89.camel@localhost.localdomain>
	<4415E78E.2000905@onelabs.com>
Message-ID: <1142287428.9254.169.camel@localhost.localdomain>

On Mon, 2006-03-13 at 15:43 -0600, Bari Ari wrote:
> Jim,
> 
> It's great that AMD stated that they have agreed to allow use of their 
> VSA code during a teleconference.
> 
> Can you ask David Wahl with AMD to release all the source to the VSA 
> including XpressGRAPHICS and XpressAUDIO under GPL or similar license?
> 

I meet with David Thursday.  For my own education, what exactly is
XpressGraphics and XpressAudio?
			- Jim

> -Bari
> 
> Jim Gettys wrote:
> > On a teleconference on March 2, AMD said that we can have/use any of
> > their code (e.g. VSA sources, as I understand it) that we need, and that
> > that code could be incorporated into LinuxBIOS.
> > 
> > What is more, they said that they had ensured that they owned all the IP
> > associated with this code since Geode's acquisition by AMD.
> > 
> > They also said that LinuxBIOS was now considered a peer of any
> > commercial BIOS and they would support the development. I know from
> > subsequent mail that AMD's expert on LinuxBIOS in the Opteron group has
> > spent a day with the Geode team to try to get them up to speed.
> > 
> > I don't know if AMD has a BIOS of their own; heretofore people have used
> > commercial BIOS's on Geode.  (says me the non-BIOS guy who usually
> > pushes packets and pixels around).
> > 
> > AMD, BTW, is one of the corporate sponsors of OLPC.  And I meet with
> > David Wahl of AMD later this week, who is in charge of the group in AMD
> > who support BIOS developers.
> > 				Regards,
> > 					- Jim Gettys
> > 					OLPC
> > 
> > 
> > 
> > 
> > 
> > On Mon, 2006-03-13 at 10:02 -0600, Bari Ari wrote:
> > 
> >>Jim,
> >>
> >>What's the status of any legal agreements with AMD on using their BIOS 
> >>or VSA source for the OLPC project?
> >>
> >>-Bari
> >>
> >>Jim Gettys wrote:
> >>
> >>>Is located here:
> >>>
> >>>http://wiki.laptop.org/wiki/Hardware_specification
> >>>
> >>>The board has started layout.
> >>>			- Regards,
> >>>				- Jim
> >>
-- 
Jim Gettys
One Laptop Per Child





From ollie at lanl.gov  Mon Mar 13 23:24:09 2006
From: ollie at lanl.gov (Li-Ta Lo)
Date: Mon, 13 Mar 2006 15:24:09 -0700
Subject: [LinuxBIOS] OLPC hardware specification information
In-Reply-To: <1142287428.9254.169.camel@localhost.localdomain>
References: <1142166712.14329.161.camel@localhost.localdomain>
	<4415979F.4040909@onelabs.com>
	<1142270463.9254.89.camel@localhost.localdomain>
	<4415E78E.2000905@onelabs.com>
	<1142287428.9254.169.camel@localhost.localdomain>
Message-ID: <1142288650.12025.4.camel@logarithm.lanl.gov>

On Mon, 2006-03-13 at 17:03 -0500, Jim Gettys wrote:
> On Mon, 2006-03-13 at 15:43 -0600, Bari Ari wrote:
> > Jim,
> > 
> > It's great that AMD stated that they have agreed to allow use of their 
> > VSA code during a teleconference.
> > 
> > Can you ask David Wahl with AMD to release all the source to the VSA 
> > including XpressGRAPHICS and XpressAUDIO under GPL or similar license?
> > 
> 
> I meet with David Thursday.  For my own education, what exactly is
> XpressGraphics and XpressAudio?
> 			- Jim
> 

It for compatibility with the legacy VGA and Sound Blaster interface.
Probably we don't need them since we will use the so called "native
drivers".

We do need the VSA source for other stuff.
 
-- 
Li-Ta Lo <ollie at lanl.gov>
Los Alamos National Lab




From jardel at lesc.ufc.br  Mon Mar 13 23:31:02 2006
From: jardel at lesc.ufc.br (jardel at lesc.ufc.br)
Date: Mon, 13 Mar 2006 19:31:02 -0300 (BRT)
Subject: [LinuxBIOS] OLPC hardware specification information
In-Reply-To: <1142287428.9254.169.camel@localhost.localdomain>
References: <1142166712.14329.161.camel@localhost.localdomain>
	<4415979F.4040909@onelabs.com>
	<1142270463.9254.89.camel@localhost.localdomain>
	<4415E78E.2000905@onelabs.com>
	<1142287428.9254.169.camel@localhost.localdomain>
Message-ID: <1244.201.8.196.198.1142289062.squirrel@www.lesc.ufc.br>

Dear Sir,

   If you permit me answer,

   VSA (Virtual System Architecture) is an AMD technology that grants the
compatibility of AMD GEODE with i386 systems. VSA is composed of
various VSMs (Virtual Support Modules). XpressGRAPHICS and XpressAUDIO
are VSMs. The following VSMs are described in the document VSA
ADAPTATION GUIDE of AMD:

AUDIO VSM (XpressAUDIO)
LEGACY VSM
PM CORE VSM
APM VSM
ACPI VSM
RTC VSM
SOGTVGA VSM  (XpressGRAPHICS)
KEYBOARD VSM
OHCI VSM
UART VSM


Thanks.


Jardel.

> On Mon, 2006-03-13 at 15:43 -0600, Bari Ari wrote:
>> Jim,
>>
>> It's great that AMD stated that they have agreed to allow use of their
>> VSA code during a teleconference.
>>
>> Can you ask David Wahl with AMD to release all the source to the VSA
>> including XpressGRAPHICS and XpressAUDIO under GPL or similar license?
>>
>
> I meet with David Thursday.  For my own education, what exactly is
> XpressGraphics and XpressAudio?
> 			- Jim
>
>> -Bari
>>
>> Jim Gettys wrote:
>> > On a teleconference on March 2, AMD said that we can have/use any of
>> > their code (e.g. VSA sources, as I understand it) that we need, and
>> that
>> > that code could be incorporated into LinuxBIOS.
>> >
>> > What is more, they said that they had ensured that they owned all the
>> IP
>> > associated with this code since Geode's acquisition by AMD.
>> >
>> > They also said that LinuxBIOS was now considered a peer of any
>> > commercial BIOS and they would support the development. I know from
>> > subsequent mail that AMD's expert on LinuxBIOS in the Opteron group
>> has
>> > spent a day with the Geode team to try to get them up to speed.
>> >
>> > I don't know if AMD has a BIOS of their own; heretofore people have
>> used
>> > commercial BIOS's on Geode.  (says me the non-BIOS guy who usually
>> > pushes packets and pixels around).
>> >
>> > AMD, BTW, is one of the corporate sponsors of OLPC.  And I meet with
>> > David Wahl of AMD later this week, who is in charge of the group in
>> AMD
>> > who support BIOS developers.
>> > 				Regards,
>> > 					- Jim Gettys
>> > 					OLPC
>> >
>> >
>> >
>> >
>> >
>> > On Mon, 2006-03-13 at 10:02 -0600, Bari Ari wrote:
>> >
>> >>Jim,
>> >>
>> >>What's the status of any legal agreements with AMD on using their BIOS
>> >>or VSA source for the OLPC project?
>> >>
>> >>-Bari
>> >>
>> >>Jim Gettys wrote:
>> >>
>> >>>Is located here:
>> >>>
>> >>>http://wiki.laptop.org/wiki/Hardware_specification
>> >>>
>> >>>The board has started layout.
>> >>>			- Regards,
>> >>>				- Jim
>> >>
> --
> Jim Gettys
> One Laptop Per Child
>
>
>
> --
> linuxbios mailing list
> linuxbios at linuxbios.org
> http://www.openbios.org/mailman/listinfo/linuxbios
>





From jg at laptop.org  Tue Mar 14 00:21:11 2006
From: jg at laptop.org (Jim Gettys)
Date: Mon, 13 Mar 2006 18:21:11 -0500
Subject: [LinuxBIOS] OLPC hardware specification information
In-Reply-To: <1142288650.12025.4.camel@logarithm.lanl.gov>
References: <1142166712.14329.161.camel@localhost.localdomain>
	<4415979F.4040909@onelabs.com>
	<1142270463.9254.89.camel@localhost.localdomain>
	<4415E78E.2000905@onelabs.com>
	<1142287428.9254.169.camel@localhost.localdomain>
	<1142288650.12025.4.camel@logarithm.lanl.gov>
Message-ID: <1142292071.9254.199.camel@localhost.localdomain>

On Mon, 2006-03-13 at 15:24 -0700, Li-Ta Lo wrote:

> > 
> 
> It for compatibility with the legacy VGA and Sound Blaster interface.
> Probably we don't need them since we will use the so called "native
> drivers".

Thanks.  

We will certainly use an fbdev driver on the OLPC system in production
(we plan various magic which requires it); unfortunately, while there is
a fbdev driver for GX1 and LX, there isn't one yet for GX2 (ironic,
isn't it; we have a driver for the older chip and the newer chip;
sigh...).  It is on the "must implement" list.

This instant we need to find someone to hack the two drivers into one...

Anyone familiar with hacking fbdev drivers?

> 
> We do need the VSA source for other stuff.
>  

Yup.  That I understand.
			- Jim

-- 
Jim Gettys
One Laptop Per Child





From rminnich at lanl.gov  Tue Mar 14 00:24:53 2006
From: rminnich at lanl.gov (Ronald G Minnich)
Date: Mon, 13 Mar 2006 16:24:53 -0700
Subject: [LinuxBIOS] OLPC hardware specification information
In-Reply-To: <1142292071.9254.199.camel@localhost.localdomain>
References: <1142166712.14329.161.camel@localhost.localdomain>	<4415979F.4040909@onelabs.com>	<1142270463.9254.89.camel@localhost.localdomain>	<4415E78E.2000905@onelabs.com>	<1142287428.9254.169.camel@localhost.localdomain>	<1142288650.12025.4.camel@logarithm.lanl.gov>
	<1142292071.9254.199.camel@localhost.localdomain>
Message-ID: <4415FF45.8050806@lanl.gov>

Jim Gettys wrote:

> Anyone familiar with hacking fbdev drivers?


Ollie Lo. He wrote the sis-fbdev and many other sis video drivers.

ron



From jg at laptop.org  Tue Mar 14 00:37:55 2006
From: jg at laptop.org (Jim Gettys)
Date: Mon, 13 Mar 2006 18:37:55 -0500
Subject: [LinuxBIOS] OLPC hardware specification information
In-Reply-To: <4415FF45.8050806@lanl.gov>
References: <1142166712.14329.161.camel@localhost.localdomain>
	<4415979F.4040909@onelabs.com>
	<1142270463.9254.89.camel@localhost.localdomain>
	<4415E78E.2000905@onelabs.com>
	<1142287428.9254.169.camel@localhost.localdomain>
	<1142288650.12025.4.camel@logarithm.lanl.gov>
	<1142292071.9254.199.camel@localhost.localdomain>
	<4415FF45.8050806@lanl.gov>
Message-ID: <1142293075.9254.202.camel@localhost.localdomain>

On Mon, 2006-03-13 at 16:24 -0700, Ronald G Minnich wrote:
> Jim Gettys wrote:
> 
> > Anyone familiar with hacking fbdev drivers?
> 
> 
> Ollie Lo. He wrote the sis-fbdev and many other sis video drivers.
> 
> ron

OK, the GX1 code is in the main Linux kernel.

The LX code I gather is on the AMD web site, or so my memory is from one
of the copies pieces of mail of the last week.

			- Jim

-- 
Jim Gettys
One Laptop Per Child





From stuge-linuxbios at cdy.org  Tue Mar 14 00:44:48 2006
From: stuge-linuxbios at cdy.org (Peter Stuge)
Date: Tue, 14 Mar 2006 00:44:48 +0100
Subject: [LinuxBIOS] OLPC hardware specification information
In-Reply-To: <1142292071.9254.199.camel@localhost.localdomain>
References: <1142166712.14329.161.camel@localhost.localdomain>
	<4415979F.4040909@onelabs.com>
	<1142270463.9254.89.camel@localhost.localdomain>
	<4415E78E.2000905@onelabs.com>
	<1142287428.9254.169.camel@localhost.localdomain>
	<1142288650.12025.4.camel@logarithm.lanl.gov>
	<1142292071.9254.199.camel@localhost.localdomain>
Message-ID: <20060313234449.18694.qmail@cdy.org>

On Mon, Mar 13, 2006 at 06:21:11PM -0500, Jim Gettys wrote:
> while there is a fbdev driver for GX1 and LX, there isn't one yet
> for GX2 (ironic, isn't it; we have a driver for the older chip and
> the newer chip; sigh...).  It is on the "must implement" list.

A small word of warning, the durango codebase that NSC's GX1 fbdev
driver uses is some 100kb of code IIRC. It's unneccessary complicated
and should be avoided if at all possible.


//Peter



From smithbone at gmail.com  Tue Mar 14 01:05:00 2006
From: smithbone at gmail.com (Richard Smith)
Date: Mon, 13 Mar 2006 18:05:00 -0600
Subject: [LinuxBIOS] OLPC hardware specification information
In-Reply-To: <1142292071.9254.199.camel@localhost.localdomain>
References: <1142166712.14329.161.camel@localhost.localdomain>
	<4415979F.4040909@onelabs.com>
	<1142270463.9254.89.camel@localhost.localdomain>
	<4415E78E.2000905@onelabs.com>
	<1142287428.9254.169.camel@localhost.localdomain>
	<1142288650.12025.4.camel@logarithm.lanl.gov>
	<1142292071.9254.199.camel@localhost.localdomain>
Message-ID: <8a0c36780603131605y686db228ieb1727af8366e3a2@mail.gmail.com>

> (we plan various magic which requires it); unfortunately, while there is
> a fbdev driver for GX1 and LX, there isn't one yet for GX2 (ironic,
> isn't it; we have a driver for the older chip and the newer chip;
> sigh...).  It is on the "must implement" list.

Jim,

A fb patch for the GX allready exists...  See below and check the
fbdev archives for the patch.  Looks like it depends on some VSA magic
though.

============================
A framebuffer driver for the display controller in AMD Geode GX
processors (Geode GX533, Geode GX500 etc.).  Tested at 640x480, 800x600,
1024x768 and 1280x1024 at 8, 16, and 24 bpp with both CRT and TFT.  No
accelerated features currently implemented and compression remains disabled.

This driver requires that the BIOS (or the SoftVG/Firmbase code in the
BIOS) has created an appropriate virtual PCI header.

Signed-off-by: David Vrabel <dvrabel at arcom.com>
===========================

--
Richard A. Smith

From bari at onelabs.com  Tue Mar 14 15:13:13 2006
From: bari at onelabs.com (Bari Ari)
Date: Tue, 14 Mar 2006 08:13:13 -0600
Subject: [LinuxBIOS] OLPC Keyboard/System Controller ENE KB3920
Message-ID: <4416CF79.7070900@onelabs.com>

Jim,

I see from the OLPC Wiki

http://wiki.laptop.org/wiki/Hardware_specification

that the ENE KB3920

http://www.ene.com.tw/

is to be used for keyboard scan and system management.

Are there plans to keep the code for this open as well?

Many types of these controllers share memory space with the flash that 
stores the BIOS. The KB3920 data sheet is not available from the ENE 
website. Do you know if this device has enough flash, OTP or mask ROM to 
hold all of it's own code or will it share with the system BIOS?

-Bari



From pdj at knaldgas.dk  Tue Mar 14 21:20:19 2006
From: pdj at knaldgas.dk (Per Dalgas Jakobsen)
Date: Tue, 14 Mar 2006 21:20:19 +0100
Subject: [LinuxBIOS] Lippert Cool Roadrunner 2 (GX1)
In-Reply-To: <1141404174.15367.32.camel@pdj.knaldgas.dk>
References: <1141404174.15367.32.camel@pdj.knaldgas.dk>
Message-ID: <44172583.80807@knaldgas.dk>

Resounding silence...

Well I guess I will have to acquire a POST card and do some digging then.

~Per


Per Dalgas Jakobsen wrote:
> Hi all,
> 
> At last... Finally I have had time to look at LinuxBIOS...
> I have been playing around with Etherboot and Filo for booting a
> development target, making good progress.
> 
> Up to now I have managed to add Etherboot to the original BIOS and have
> it working fine.
> 
> But now I want to LinuxBIOS my system ;-)
> 
> I have a Lippert Cool Roadrunner II with 64MB memory and a 128MB
> CompactFlash for disk, and I have tried to use LinuxBIOS v1 with its
> support for this board, but no success.
> 
> The serial port is very quite, and unfortunately I have no POST card. I
> have verified the serial connection: Linux on target "$ echo Hello
> 
>>/dev/ttyS0" gives a nice "Hello" on the receiving end (no handshakes),
> 
> so something seems odd with the LinuxBIOS image...
> 
> Host is i686-Linux using gcc-4.0.3
> 
> --- config ------------
> target /home/pdj/tuxway/builds/roadrunner2
> mainboard lippert/roadrunner2
> 
> # Enable Serial Console for debugging
> option SERIAL_CONSOLE=1
> option TTYS0_BAUD=57600
> 
> option DEFAULT_CONSOLE_LOGLEVEL=9
> option DEBUG=1
> 
> option RAMTEST=1
> option USE_GENERIC_ROM=1
> option USE_ELF_BOOT=1
> option ROM_SIZE=262144
> option STD_FLASH=1
> 
> payload ~/tuxway/etherboot-5.0.6/src/bin32/eepro100.elf
> 
> option PAYLOAD_SIZE=196608
> ---------------
> 
> I've hexdump'd the resulting romimage, and it looks fine as far as I can
> tell: (jmp far 0xf000:0x0004 at address 0x0003fff0, and payload image
> starting at 0x00000000).
> 
> I've used the flashrom from LinuxBIOSv2-2191 for burning:
> "# flashrom -w romimage"
> 
> 
> Anyone able to give me a clue of what I've missed?
> 
> Anyone had success with LinuxBIOSv2 on a Roadrunner2 ?
> 
> 
> ~Per
> -----------------
> 
> PS:
> ---
> My ultimate goal is fast boot to either a remote image (through
> Etherboot) or a local linux on CompactFlash (filo and ext2).
> 
> My plan was to use LinuxBIOS with a combined filo and etherboot image as
> payload.
> Like this:
> 0x000000 FILO
> 0x010000 ETHERBOOT
> 0x030000 LINUXBIOS
> 0x040000
> ---
> I have already modified filo so an external switch can select the
> boot-method.
> 
> 
> 



From smithbone at gmail.com  Tue Mar 14 21:38:35 2006
From: smithbone at gmail.com (Richard Smith)
Date: Tue, 14 Mar 2006 14:38:35 -0600
Subject: [LinuxBIOS] Lippert Cool Roadrunner 2 (GX1)
In-Reply-To: <44172583.80807@knaldgas.dk>
References: <1141404174.15367.32.camel@pdj.knaldgas.dk>
	<44172583.80807@knaldgas.dk>
Message-ID: <8a0c36780603141238i7e919813m7cc792b60333655e@mail.gmail.com>

On 3/14/06, Per Dalgas Jakobsen <pdj at knaldgas.dk> wrote:
> Resounding silence...
>

Sorry, your post probally just got lost in all the stuff surrounding
the GX2 and OLPC.

> Well I guess I will have to acquire a POST card and do some digging then.
>

Until you get a post card my advice would be to edit the start up
assembly and add a series of 5 outs to port 80 in a row and then hang
in a spin loop.   Then you can look at the  ISA IO lines with a scope
and see if you are getting the 5 outs.

No outs then your image needs a closer look.

If you are then walk the outs and hang pattern up the boot chain until
you figure out why your serial port isn't up.

You can also fast track this by doing the same pattern in the early
serial init code and see if you are getting to that code.  if you are
then your super IO is just not getting set up correctly.  If not then
you have to start earlier.

If you don't have access to a scope, well then you may just have to
wait until you get a post card.

--
Richard A. Smith

From smithbone at gmail.com  Tue Mar 14 21:42:33 2006
From: smithbone at gmail.com (Richard Smith)
Date: Tue, 14 Mar 2006 14:42:33 -0600
Subject: [LinuxBIOS] Lippert Cool Roadrunner 2 (GX1)
In-Reply-To: <8a0c36780603141238i7e919813m7cc792b60333655e@mail.gmail.com>
References: <1141404174.15367.32.camel@pdj.knaldgas.dk>
	<44172583.80807@knaldgas.dk>
	<8a0c36780603141238i7e919813m7cc792b60333655e@mail.gmail.com>
Message-ID: <8a0c36780603141242je725b02md3ea52c30767f4ef@mail.gmail.com>

On 3/14/06, Richard Smith <smithbone at gmail.com> wrote:

> > Well I guess I will have to acquire a POST card and do some digging then.

The thought just occured to me.   How are the legacy ranges handled on
that platform?  Do you perhaps have to have some VSA magic to get the
legacy serial range up?

--
Richard A. Smith

From pdj at knaldgas.dk  Tue Mar 14 22:21:39 2006
From: pdj at knaldgas.dk (Per Dalgas Jakobsen)
Date: Tue, 14 Mar 2006 22:21:39 +0100
Subject: [LinuxBIOS] Lippert Cool Roadrunner 2 (GX1)
In-Reply-To: <8a0c36780603141238i7e919813m7cc792b60333655e@mail.gmail.com>
References: <1141404174.15367.32.camel@pdj.knaldgas.dk>	
	<44172583.80807@knaldgas.dk>
	<8a0c36780603141238i7e919813m7cc792b60333655e@mail.gmail.com>
Message-ID: <441733E3.7080404@knaldgas.dk>

 >>Resounding silence...
 >
 > Sorry, your post probally just got lost in all the stuff surrounding
 > the GX2 and OLPC.

Thanks for the feedback - I felt all alone ;-)


 > Until you get a post card my advice would be to edit the start up
 > assembly and add a series of 5 outs to port 80 in a row and then hang
 > in a spin loop.   Then you can look at the  ISA IO lines with a scope
 > and see if you are getting the 5 outs.

I have a scope at hand, but I just found a place where I can borrow a 
PC104-development kit with a POST card :-D
So I think I will fetch that kit and get going (I don't wan't to do too 
much hot-flash-switching if I can avoid it).

To be continued ;-)

~Per



From rminnich at lanl.gov  Tue Mar 14 22:46:26 2006
From: rminnich at lanl.gov (Ronald G Minnich)
Date: Tue, 14 Mar 2006 14:46:26 -0700
Subject: [LinuxBIOS] Lippert Cool Roadrunner 2 (GX1)
In-Reply-To: <44172583.80807@knaldgas.dk>
References: <1141404174.15367.32.camel@pdj.knaldgas.dk>
	<44172583.80807@knaldgas.dk>
Message-ID: <441739B2.5030504@lanl.gov>

you can look at the web article I did on debugging when things are going 
wrong.

Basically, infinite loops are your friend. :-)

ron



From jg at laptop.org  Wed Mar 15 00:42:57 2006
From: jg at laptop.org (Jim Gettys)
Date: Tue, 14 Mar 2006 18:42:57 -0500
Subject: [LinuxBIOS] OLPC Keyboard/System Controller ENE KB3920
In-Reply-To: <4416CF79.7070900@onelabs.com>
References: <4416CF79.7070900@onelabs.com>
Message-ID: <1142379778.8955.48.camel@localhost.localdomain>

On Tue, 2006-03-14 at 08:13 -0600, Bari Ari wrote:
> Jim,
> 
> I see from the OLPC Wiki
> 
> http://wiki.laptop.org/wiki/Hardware_specification
> 
> that the ENE KB3920
> 
> http://www.ene.com.tw/
> 
> is to be used for keyboard scan and system management.
> 
> Are there plans to keep the code for this open as well?
> 
> Many types of these controllers share memory space with the flash that 
> stores the BIOS. The KB3920 data sheet is not available from the ENE 
> website. Do you know if this device has enough flash, OTP or mask ROM to 
> hold all of it's own code or will it share with the system BIOS?

I think the part may not have been released yet;  so you get the part
number for now; or maybe it is just some variant of an existing part.  I
don't know the exact situation and will have to ask Quanta.

It isn't clear to me if we should release the code (at least without
some thought) to this part.

IIRC, the flash in which LinuxBIOS is getting stored is interfaced via
this controller and is a serial flash part; possible sizes are 4
megabits and 8 megabits.  We save something like $.3 to $.5 if we can
use the 4 megabit part.  Right now, we are carrying the 8 megabit
version on the BOM.

Here's what I'm paranoid about: that the serial flash rom in which
LinuxBIOS  and bootloader is stored gets overwritten, and the laptop is
no longer a laptop, but an expensive brick.  I particularly worry about
someone writing a worm that manages to do this, and that
thousands/millions of machines all over the world are unrecoverable.
The logistics of repair are impossible.  I will ask Mark Foster about
how that flash gets write enabled; if we can absolutely in hardware
inhibit write to the boot flash, then I get much less worried.  I've
sent him mail asking.

I do want the bootloader sequence in this flash to be able to load a
second copy of itself out of the regular main flash so that later
versions can be installed safely (with appropriate checksum checking).
I don't want the situation we had on the iPAQ where you could possibly
"brick" the unit when updating the bootloader.  The iPAQ valhalla we had
(you could send us a bricked iPAQ and we'd eventually reflash it via
jtag and return it) was a PITA, and not feasible for OLPC.  We have to
ensure boot and restore is absolutely bulletproof.
					- Jim

-- 
Jim Gettys
One Laptop Per Child





From bari at onelabs.com  Wed Mar 15 04:58:49 2006
From: bari at onelabs.com (Bari Ari)
Date: Tue, 14 Mar 2006 21:58:49 -0600
Subject: [LinuxBIOS] OLPC Keyboard/System Controller ENE KB3920
In-Reply-To: <1142379778.8955.48.camel@localhost.localdomain>
References: <4416CF79.7070900@onelabs.com>
	<1142379778.8955.48.camel@localhost.localdomain>
Message-ID: <441790F9.1070304@onelabs.com>

Jim Gettys wrote:

> It isn't clear to me if we should release the code (at least without
> some thought) to this part.

If it would help with "The Free Software Foundation's Campaign for Free 
BIOS" for laptops

http://www.fsf.org/campaigns/free-bios.html

OLPC would also gain support from this community and the whole open 
source community for laptops and tablets.

The keyboard/system controller in laptops is often used to control 
writes to the flash (and several other system areas) and has made it 
very difficult to support laptops with a Free BIOS.

> 
> Here's what I'm paranoid about: that the serial flash rom in which
> LinuxBIOS  and bootloader is stored gets overwritten, and the laptop is
> no longer a laptop, but an expensive brick.  I particularly worry about
> someone writing a worm that manages to do this, and that
> thousands/millions of machines all over the world are unrecoverable.
> The logistics of repair are impossible.  I will ask Mark Foster about
> how that flash gets write enabled; if we can absolutely in hardware
> inhibit write to the boot flash, then I get much less worried.  I've
> sent him mail asking.

Several vendors have relied on "security through obscurity" to prevent 
worms or a virus from modifying the system BIOS. It's always been 
defeated. A very difficult AES + SHA-1 or SHA-256 hash based security 
scheme could be used, but it still would not be 100% secure.

> I do want the bootloader sequence in this flash to be able to load a
> second copy of itself out of the regular main flash so that later
> versions can be installed safely (with appropriate checksum checking).
> I don't want the situation we had on the iPAQ where you could possibly
> "brick" the unit when updating the bootloader.  The iPAQ valhalla we had
> (you could send us a bricked iPAQ and we'd eventually reflash it via
> jtag and return it) was a PITA, and not feasible for OLPC.  We have to
> ensure boot and restore is absolutely bulletproof.
> 					- Jim

Fallback BIOS in ROM plus a hardware switch/jumper to control writes to 
flash is one 100% solution. Having a fallback BIOS image in flash would 
only be safe if writes to the memory area in flash that stores the 
fallback BIOS image is completely inaccessible to writes unless a 
hardware switch/jumper is enabled.

-Bari



From jg at laptop.org  Wed Mar 15 05:32:46 2006
From: jg at laptop.org (Jim Gettys)
Date: Tue, 14 Mar 2006 23:32:46 -0500
Subject: [LinuxBIOS] OLPC Keyboard/System Controller ENE KB3920
In-Reply-To: <441790F9.1070304@onelabs.com>
References: <4416CF79.7070900@onelabs.com>
	<1142379778.8955.48.camel@localhost.localdomain>
	<441790F9.1070304@onelabs.com>
Message-ID: <1142397167.8955.233.camel@localhost.localdomain>

On Tue, 2006-03-14 at 21:58 -0600, Bari Ari wrote:
> Jim Gettys wrote:
> 
> > It isn't clear to me if we should release the code (at least without
> > some thought) to this part.
> 
> If it would help with "The Free Software Foundation's Campaign for Free 
> BIOS" for laptops
> 
> http://www.fsf.org/campaigns/free-bios.html

I'm aware of the campaign.  I guess I'm more on the pragmatic Linus side
of the camp: my interest in LinuxBIOS is what it can do that we forsee
difficult or impossible using a conventional BIOS. LinuxBIOS looks to us
like *the best tool for our job*. I personally believe open source and
Free software should meet all comers on its own merits; the ideology is
secondary or tertiary in my view. I'm not saying I don't share much of
what the FSF advocates; I'm saying that by free software being the
obviously right technical solution to a problem is an even stronger,
cogent, compelling argument than ideology.

We have a secondary motivation that is educational: we'd like kids to be
able to take the software apart down to the bare silicon as a potential
learning experience: you can't do that on closed source BIOS's.

But if the commercial BIOS did all of what we need (and you aren't yet
aware how interestingly nuts we've all become, yet), I'd use it.  But
they don't, and LinuxBIOS means we can get in there and make whatever
changes are needed, and we know we need changes that go beyond the
usual.  When you fully understand what the DCON chip means, you'll have
an interesting revelation.  I'll guess we'll open up on that in a week
or two; definitely by the Linux Power management summit in April.

> 
> OLPC would also gain support from this community and the whole open 
> source community for laptops and tablets.
> 
> The keyboard/system controller in laptops is often used to control 
> writes to the flash (and several other system areas) and has made it 
> very difficult to support laptops with a Free BIOS.

Actually, I suspect we may end up with a separate keyboard controller to
save on wires.  The spec current calls for the keyboard to be
electrically PS/2.  That implies a separate keyboard scanner, or many
wires have to go through the hinge.

> 
> > 
> > Here's what I'm paranoid about: that the serial flash rom in which
> > LinuxBIOS  and bootloader is stored gets overwritten, and the laptop is
> > no longer a laptop, but an expensive brick.  I particularly worry about
> > someone writing a worm that manages to do this, and that
> > thousands/millions of machines all over the world are unrecoverable.
> > The logistics of repair are impossible.  I will ask Mark Foster about
> > how that flash gets write enabled; if we can absolutely in hardware
> > inhibit write to the boot flash, then I get much less worried.  I've
> > sent him mail asking.
> 
> Several vendors have relied on "security through obscurity" to prevent 
> worms or a virus from modifying the system BIOS. It's always been 
> defeated. A very difficult AES + SHA-1 or SHA-256 hash based security 
> scheme could be used, but it still would not be 100% secure.

I don't believe in security by obscurity.

I have asked Mark Foster to see if he can determine a way to write
protect the flash; he said he'd see what he can do.

Bullet proof solution is what we have to have. "Takes a licking and
keeps on ticking" as the old Timex commercials said (boy, I'm showing my
age, aren't I?

> 
> > I do want the bootloader sequence in this flash to be able to load a
> > second copy of itself out of the regular main flash so that later
> > versions can be installed safely (with appropriate checksum checking).
> > I don't want the situation we had on the iPAQ where you could possibly
> > "brick" the unit when updating the bootloader.  The iPAQ valhalla we had
> > (you could send us a bricked iPAQ and we'd eventually reflash it via
> > jtag and return it) was a PITA, and not feasible for OLPC.  We have to
> > ensure boot and restore is absolutely bulletproof.
> > 					- Jim
> 
> Fallback BIOS in ROM plus a hardware switch/jumper to control writes to 
> flash is one 100% solution. Having a fallback BIOS image in flash would 
> only be safe if writes to the memory area in flash that stores the 
> fallback BIOS image is completely inaccessible to writes unless a 
> hardware switch/jumper is enabled.

External switches cost money and are difficult to seal.  Internal
jumpers we may be able to afford.

As I said, I am hopeful we'll make the flash unwritable.  Then I can
sleep at night...
				- Jim



-- 
Jim Gettys
One Laptop Per Child





From bari at onelabs.com  Wed Mar 15 06:09:48 2006
From: bari at onelabs.com (Bari Ari)
Date: Tue, 14 Mar 2006 23:09:48 -0600
Subject: [LinuxBIOS] OLPC Keyboard/System Controller ENE KB3920
In-Reply-To: <1142397167.8955.233.camel@localhost.localdomain>
References: <4416CF79.7070900@onelabs.com>	
	<1142379778.8955.48.camel@localhost.localdomain>	
	<441790F9.1070304@onelabs.com>
	<1142397167.8955.233.camel@localhost.localdomain>
Message-ID: <4417A19C.7000906@onelabs.com>

Jim Gettys wrote:

> Actually, I suspect we may end up with a separate keyboard controller to
> save on wires.  The spec current calls for the keyboard to be
> electrically PS/2.  That implies a separate keyboard scanner, or many
> wires have to go through the hinge.
> 

If the code to whatever system controller ends up being used for the 
OLPC is free and open it will help that device get into and enable more 
fully open laptops, tablets and handhelds to be produced.

There is usually is not much to the code, a few of KB's of routines to 
handle the indicator LED's, power & lid switches, temperature 
management, and battery charging.

-Bari



From jg at laptop.org  Wed Mar 15 14:55:36 2006
From: jg at laptop.org (Jim Gettys)
Date: Wed, 15 Mar 2006 08:55:36 -0500
Subject: [LinuxBIOS] [olpc-software] How fast does it take to write a
	system from a	scratch?
In-Reply-To: <20060315134550.GB31726@devserv.devel.redhat.com>
References: <80d7e4090603141630l6cb2a2btdaea676ce5d118e7@mail.gmail.com>
	<1142386107.8955.127.camel@localhost.localdomain>
	<1142395062.19107.92.camel@peach.bkk.thaiopensource.com>
	<1142425377.9029.8.camel@localhost.localdomain>
	<20060315134550.GB31726@devserv.devel.redhat.com>
Message-ID: <1142430936.9029.30.camel@localhost.localdomain>

Nope.  News to me of its existence.  Have any idea of the ub driver's
size?

The trick is to get at least restore from USB storage able to be in the
boot flash; I don't mind so much if we have to put TCP/IP and wireless
modules into a partition on the regular flash.   And if we can get it
all to fit into less than 512K bytes (BIOS + Linux as bootloader), then
we get to save  $.3 to $.5, which over the number of units we're
building, is more than small change.
			Thanks,
				- Jim


On Wed, 2006-03-15 at 08:45 -0500, Alan Cox wrote:
> On Wed, Mar 15, 2006 at 07:22:57AM -0500, Jim Gettys wrote:
> > The biggest headache we have here is the size of the USB modules for usb
> > storage and wireless, 
> and the drivers themselves.  This is why we're
> 
> Have you looked at Pete Zaitcev's 'ub' driver instead of the full scsi 
> stack ?
> 
> --
> olpc-software mailing list
> olpc-software at redhat.com
> https://www.redhat.com/mailman/listinfo/olpc-software
-- 
Jim Gettys
One Laptop Per Child





From stepan at coresystems.de  Thu Mar 16 02:57:18 2006
From: stepan at coresystems.de (Stefan Reinauer)
Date: Thu, 16 Mar 2006 02:57:18 +0100
Subject: [LinuxBIOS] flashrom utility
Message-ID: <20060316015718.GA31174@openbios.org>

Hi,

I would like to reduce the address output during flashing, verifying etc
in the flashrom utility. Instead of printing each address, it would be 
sufficient to write every 256th address or even every 4096th address:

so we could write
                if (verbose && ((i&0xfff)==0))
                        printf("0x%08x", i);

instead of
                if (verbose)
                        printf("0x%08x", i);


The reason is if you are writing/verifying flash on a reasonably slow
serial console it will take several hours (and hopefully not mess with
the flash timing)

any vetos?

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/



From rminnich at gmail.com  Thu Mar 16 03:49:28 2006
From: rminnich at gmail.com (ron minnich)
Date: Wed, 15 Mar 2006 19:49:28 -0700
Subject: [LinuxBIOS] flashrom utility
In-Reply-To: <20060316015718.GA31174@openbios.org>
References: <20060316015718.GA31174@openbios.org>
Message-ID: <13426df10603151849m69d40b57v9f315809cb149afc@mail.gmail.com>

On 3/15/06, Stefan Reinauer <stepan at coresystems.de> wrote:
>
> Hi,
>
> I would like to reduce the address output during flashing, verifying etc
> in the flashrom utility. Instead of printing each address, it would be
> sufficient to write every 256th address or even every 4096th address:


Do it. I had to do this in my private copy the time I flashed 1024 machines
all at once. It just was not that fun watching every one of the 1024
machines print out every address. Even on a Myrinet-connected machine, it
was S*L*O*W.

I think it's a great idea.

ron
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20060315/41f05b6a/attachment.html>

From rminnich at gmail.com  Thu Mar 16 03:51:48 2006
From: rminnich at gmail.com (ron minnich)
Date: Wed, 15 Mar 2006 19:51:48 -0700
Subject: [LinuxBIOS] OLPC Keyboard/System Controller ENE KB3920
In-Reply-To: <4417A19C.7000906@onelabs.com>
References: <4416CF79.7070900@onelabs.com>
	<1142379778.8955.48.camel@localhost.localdomain>
	<441790F9.1070304@onelabs.com>
	<1142397167.8955.233.camel@localhost.localdomain>
	<4417A19C.7000906@onelabs.com>
Message-ID: <13426df10603151851u25227b68l156b9b540e4fd00@mail.gmail.com>

Jim, the write protect is pretty easy. It's a pullup on all the parts I'm
familiar with, unless I'm missing something -- Ollie?

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

From jg at laptop.org  Thu Mar 16 04:03:01 2006
From: jg at laptop.org (Jim Gettys)
Date: Wed, 15 Mar 2006 22:03:01 -0500
Subject: [LinuxBIOS] OLPC Keyboard/System Controller ENE KB3920
In-Reply-To: <13426df10603151851u25227b68l156b9b540e4fd00@mail.gmail.com>
References: <4416CF79.7070900@onelabs.com>
	<1142379778.8955.48.camel@localhost.localdomain>
	<441790F9.1070304@onelabs.com>
	<1142397167.8955.233.camel@localhost.localdomain>
	<4417A19C.7000906@onelabs.com>
	<13426df10603151851u25227b68l156b9b540e4fd00@mail.gmail.com>
Message-ID: <1142478181.9046.81.camel@localhost.localdomain>

I expect it is easy.

I just put it on Mark Foster's list, so that a jumper might appear in
the right place...  It is easy to overlook such details (though this one
is small enough it might have been simple to get added later); but the
closer to production the first board is, the better.
				- Jim



On Wed, 2006-03-15 at 19:51 -0700, ron minnich wrote:
> Jim, the write protect is pretty easy. It's a pullup on all the parts
> I'm familiar with, unless I'm missing something -- Ollie?
>  
> ron
-- 
Jim Gettys
One Laptop Per Child





From alan at redhat.com  Wed Mar 15 16:15:26 2006
From: alan at redhat.com (Alan Cox)
Date: Wed, 15 Mar 2006 10:15:26 -0500
Subject: [LinuxBIOS] [olpc-software] How fast does it take to write a
	system from a scratch?
In-Reply-To: <1142430936.9029.30.camel@localhost.localdomain>
References: <80d7e4090603141630l6cb2a2btdaea676ce5d118e7@mail.gmail.com>
	<1142386107.8955.127.camel@localhost.localdomain>
	<1142395062.19107.92.camel@peach.bkk.thaiopensource.com>
	<1142425377.9029.8.camel@localhost.localdomain>
	<20060315134550.GB31726@devserv.devel.redhat.com>
	<1142430936.9029.30.camel@localhost.localdomain>
Message-ID: <20060315151526.GA8408@devserv.devel.redhat.com>

On Wed, Mar 15, 2006 at 08:55:36AM -0500, Jim Gettys wrote:
> Nope.  News to me of its existence.  Have any idea of the ub driver's
> size?

On x86-64 (no legacy 32bit box to hand)

 15032    1400      28   16460    404c /lib/modules/2.6.9-ac3/kernel/drivers/block/ub.ko

If you are usign CF it will also be possible to do a dedicated PIO CF driver a
similar way to get rid of the IDE layer or libata. Wouldn't let you do CD tho.

Symbol set:
usb_deregister
unregister_blkdev
usb_register
register_blkdev
blk_cleanup_queue
del_gendisk
_spin_unlock_irq
_spin_lock_irq
usb_put_dev
device_remove_file
put_disk
add_disk
blk_max_low_pfn
blk_queue_max_sectors
blk_queue_max_phys_segments
blk_queue_max_hw_segments
blk_init_queue
alloc_disk
device_create_file
usb_get_dev
snprintf
tasklet_init
usb_init_urb
del_timer_sync
wait_for_completion
kmem_cache_alloc
malloc_sizes
complete
check_disk_change
usb_unlink_urb
del_timer
usb_submit_urb
__mod_timer
jiffies
memcpy
__tasklet_schedule
end_that_request_last
end_that_request_first
blk_start_queue
blk_stop_queue
elv_remove_request
elv_next_request
kfree
printk
sprintf
_spin_unlock_irqrestore
_spin_lock_irqsave




From smithbone at gmail.com  Fri Mar 17 21:07:43 2006
From: smithbone at gmail.com (Richard Smith)
Date: Fri, 17 Mar 2006 14:07:43 -0600
Subject: [LinuxBIOS] GX eval board
Message-ID: <8a0c36780603171207l265bda30h64e9f20746eba5a4@mail.gmail.com>

Ok.. I got our AMD vendor rep to send me a GX533 board.  Probably be
here Monday or Tuesday.

Whats the status of stuff and the TODO list?

--
Richard A. Smith

From rminnich at lanl.gov  Fri Mar 17 21:14:11 2006
From: rminnich at lanl.gov (Ronald G Minnich)
Date: Fri, 17 Mar 2006 13:14:11 -0700
Subject: [LinuxBIOS] GX eval board
In-Reply-To: <8a0c36780603171207l265bda30h64e9f20746eba5a4@mail.gmail.com>
References: <8a0c36780603171207l265bda30h64e9f20746eba5a4@mail.gmail.com>
Message-ID: <441B1893.7040405@lanl.gov>

Richard Smith wrote:
> Ok.. I got our AMD vendor rep to send me a GX533 board.  Probably be
> here Monday or Tuesday.
> 
> Whats the status of stuff and the TODO list?


just work with what is there, we have a batch of patches due to come in 
by monday.

ron



From smithbone at gmail.com  Fri Mar 17 21:27:15 2006
From: smithbone at gmail.com (Richard Smith)
Date: Fri, 17 Mar 2006 14:27:15 -0600
Subject: [LinuxBIOS] GX eval board
In-Reply-To: <8a0c36780603171226g7cc8a1cbo50417d50b2996967@mail.gmail.com>
References: <8a0c36780603171207l265bda30h64e9f20746eba5a4@mail.gmail.com>
	<441B1893.7040405@lanl.gov>
	<8a0c36780603171226g7cc8a1cbo50417d50b2996967@mail.gmail.com>
Message-ID: <8a0c36780603171227m4b53785bo28e3a8e1c20a4449@mail.gmail.com>

>
> just work with what is there, we have a batch of patches due to come in
> by monday.

So pretty much just report back what fails and try to fix it?

Do we have some sort of target feature set?

I don't wan't to spend my efforts on things that someone else is
already in the middle of working on or not relevant to the project.

--
Richard A. Smith


--
Richard A. Smith

From ollie at lanl.gov  Fri Mar 17 21:53:17 2006
From: ollie at lanl.gov (Li-Ta Lo)
Date: Fri, 17 Mar 2006 13:53:17 -0700
Subject: [LinuxBIOS] GX eval board
In-Reply-To: <8a0c36780603171207l265bda30h64e9f20746eba5a4@mail.gmail.com>
References: <8a0c36780603171207l265bda30h64e9f20746eba5a4@mail.gmail.com>
Message-ID: <1142628797.5314.3.camel@logarithm.lanl.gov>

On Fri, 2006-03-17 at 14:07 -0600, Richard Smith wrote: 
> Ok.. I got our AMD vendor rep to send me a GX533 board.  Probably be
> here Monday or Tuesday.
> 

We are under a very tight schedule. We are suppose to deliver a working
LB in early/mid April and fly to Taiwan in late April.

Currently we trying to get to the point that we can load and init VSA.

-- 
Li-Ta Lo <ollie at lanl.gov>
Los Alamos National Lab




From ollie at lanl.gov  Fri Mar 17 21:57:43 2006
From: ollie at lanl.gov (Li-Ta Lo)
Date: Fri, 17 Mar 2006 13:57:43 -0700
Subject: [LinuxBIOS] GX eval board
In-Reply-To: <8a0c36780603171227m4b53785bo28e3a8e1c20a4449@mail.gmail.com>
References: <8a0c36780603171207l265bda30h64e9f20746eba5a4@mail.gmail.com>
	<441B1893.7040405@lanl.gov>
	<8a0c36780603171226g7cc8a1cbo50417d50b2996967@mail.gmail.com>
	<8a0c36780603171227m4b53785bo28e3a8e1c20a4449@mail.gmail.com>
Message-ID: <1142629063.5314.8.camel@logarithm.lanl.gov>

On Fri, 2006-03-17 at 14:27 -0600, Richard Smith wrote:
> >
> > just work with what is there, we have a batch of patches due to come in
> > by monday.
> 
> So pretty much just report back what fails and try to fix it?
> 
> Do we have some sort of target feature set?
> 
> I don't wan't to spend my efforts on things that someone else is
> already in the middle of working on or not relevant to the project.
> 

For the moment, most the the registers are just hardcoded with
fuctory bios values. Out first mile stone would be loading and
initing the VSA. Only after that we can do the usual LinuxBIOS
thing (pci enumeration, loading kernel).

BTW, do you have a M$ C/ASM development platform? Probably we
will have to make our own VSA images some day.

-- 
Li-Ta Lo <ollie at lanl.gov>
Los Alamos National Lab




From smithbone at gmail.com  Fri Mar 17 22:02:24 2006
From: smithbone at gmail.com (Richard Smith)
Date: Fri, 17 Mar 2006 15:02:24 -0600
Subject: [LinuxBIOS] GX eval board
In-Reply-To: <1142629063.5314.8.camel@logarithm.lanl.gov>
References: <8a0c36780603171207l265bda30h64e9f20746eba5a4@mail.gmail.com>
	<441B1893.7040405@lanl.gov>
	<8a0c36780603171226g7cc8a1cbo50417d50b2996967@mail.gmail.com>
	<8a0c36780603171227m4b53785bo28e3a8e1c20a4449@mail.gmail.com>
	<1142629063.5314.8.camel@logarithm.lanl.gov>
Message-ID: <8a0c36780603171302o35534e65s5e9190a13bcb5a16@mail.gmail.com>

> BTW, do you have a M$ C/ASM development platform? Probably we
> will have to make our own VSA images some day.

I've got Visual C++ 6.0.  Will that work?

--
Richard A. Smith

From rminnich at lanl.gov  Fri Mar 17 22:04:58 2006
From: rminnich at lanl.gov (Ronald G Minnich)
Date: Fri, 17 Mar 2006 14:04:58 -0700
Subject: [LinuxBIOS] GX eval board
In-Reply-To: <8a0c36780603171302o35534e65s5e9190a13bcb5a16@mail.gmail.com>
References: <8a0c36780603171207l265bda30h64e9f20746eba5a4@mail.gmail.com>	<441B1893.7040405@lanl.gov>	<8a0c36780603171226g7cc8a1cbo50417d50b2996967@mail.gmail.com>	<8a0c36780603171227m4b53785bo28e3a8e1c20a4449@mail.gmail.com>	<1142629063.5314.8.camel@logarithm.lanl.gov>
	<8a0c36780603171302o35534e65s5e9190a13bcb5a16@mail.gmail.com>
Message-ID: <441B247A.7040508@lanl.gov>

Richard Smith wrote:
>>BTW, do you have a M$ C/ASM development platform? Probably we
>>will have to make our own VSA images some day.
> 
> 
> I've got Visual C++ 6.0.  Will that work?
> 


If it would, that would help. You could provide us with VSM that is 
built from scratch.


ron



From smithbone at gmail.com  Fri Mar 17 22:14:31 2006
From: smithbone at gmail.com (Richard Smith)
Date: Fri, 17 Mar 2006 15:14:31 -0600
Subject: [LinuxBIOS] GX eval board
In-Reply-To: <441B247A.7040508@lanl.gov>
References: <8a0c36780603171207l265bda30h64e9f20746eba5a4@mail.gmail.com>
	<441B1893.7040405@lanl.gov>
	<8a0c36780603171226g7cc8a1cbo50417d50b2996967@mail.gmail.com>
	<8a0c36780603171227m4b53785bo28e3a8e1c20a4449@mail.gmail.com>
	<1142629063.5314.8.camel@logarithm.lanl.gov>
	<8a0c36780603171302o35534e65s5e9190a13bcb5a16@mail.gmail.com>
	<441B247A.7040508@lanl.gov>
Message-ID: <8a0c36780603171314j6bd946aes7304f8d1e4e27dff@mail.gmail.com>

> >
> > I've got Visual C++ 6.0.  Will that work?
> >
>
>
> If it would, that would help. You could provide us with VSM that is
> built from scratch.

Ok..  I'll consider that my first task.  Not that I think about it 
I've also got a machine that has Visual Studio installed on it.

--
Richard A. Smith

From jardel at lesc.ufc.br  Fri Mar 17 22:17:48 2006
From: jardel at lesc.ufc.br (jardel)
Date: Fri, 17 Mar 2006 18:17:48 -0300
Subject: [LinuxBIOS] GX eval board
In-Reply-To: <8a0c36780603171302o35534e65s5e9190a13bcb5a16@mail.gmail.com>
References: <8a0c36780603171207l265bda30h64e9f20746eba5a4@mail.gmail.com>	<441B1893.7040405@lanl.gov>	<8a0c36780603171226g7cc8a1cbo50417d50b2996967@mail.gmail.com>	<8a0c36780603171227m4b53785bo28e3a8e1c20a4449@mail.gmail.com>	<1142629063.5314.8.camel@logarithm.lanl.gov>
	<8a0c36780603171302o35534e65s5e9190a13bcb5a16@mail.gmail.com>
Message-ID: <441B277C.3060307@lesc.ufc.br>


   I don't think so. You need MSVC 1.52. The last version of MSVC that
comes with MSVC 1.52 is MSVC 4.0. I've read in any location that MS SQL
comes with MSVC 1.52.
  

Richard Smith wrote:

>>BTW, do you have a M$ C/ASM development platform? Probably we
>>will have to make our own VSA images some day.
>>    
>>
>
>I've got Visual C++ 6.0.  Will that work?
>
>--
>Richard A. Smith
>  
>

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 256 bytes
Desc: OpenPGP digital signature
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20060317/8cd79e20/attachment.sig>

From smithbone at gmail.com  Fri Mar 17 22:26:54 2006
From: smithbone at gmail.com (Richard Smith)
Date: Fri, 17 Mar 2006 15:26:54 -0600
Subject: [LinuxBIOS] GX eval board
In-Reply-To: <441B277C.3060307@lesc.ufc.br>
References: <8a0c36780603171207l265bda30h64e9f20746eba5a4@mail.gmail.com>
	<441B1893.7040405@lanl.gov>
	<8a0c36780603171226g7cc8a1cbo50417d50b2996967@mail.gmail.com>
	<8a0c36780603171227m4b53785bo28e3a8e1c20a4449@mail.gmail.com>
	<1142629063.5314.8.camel@logarithm.lanl.gov>
	<8a0c36780603171302o35534e65s5e9190a13bcb5a16@mail.gmail.com>
	<441B277C.3060307@lesc.ufc.br>
Message-ID: <8a0c36780603171326o6d20af13n30ae3e3285e3a606@mail.gmail.com>

On 3/17/06, jardel <jardel at lesc.ufc.br> wrote:
>
>    I don't think so. You need MSVC 1.52. The last version of MSVC that
> comes with MSVC 1.52 is MSVC 4.0. I've read in any location that MS SQL
> comes with MSVC 1.52.

Ok... I just check and our PNX1500 dev machine has Visual Studio .net
2003 installed.  But I don't see anything in the bin dir that is MSVC.
 Is that the real name of the .exe?
I don't use M$ compiler stuff much.

--
Richard A. Smith

From bari at onelabs.com  Fri Mar 17 22:30:26 2006
From: bari at onelabs.com (Bari Ari)
Date: Fri, 17 Mar 2006 15:30:26 -0600
Subject: [LinuxBIOS] GX eval board
In-Reply-To: <8a0c36780603171302o35534e65s5e9190a13bcb5a16@mail.gmail.com>
References: <8a0c36780603171207l265bda30h64e9f20746eba5a4@mail.gmail.com>	<441B1893.7040405@lanl.gov>	<8a0c36780603171226g7cc8a1cbo50417d50b2996967@mail.gmail.com>	<8a0c36780603171227m4b53785bo28e3a8e1c20a4449@mail.gmail.com>	<1142629063.5314.8.camel@logarithm.lanl.gov>
	<8a0c36780603171302o35534e65s5e9190a13bcb5a16@mail.gmail.com>
Message-ID: <441B2A72.7090105@onelabs.com>

Richard Smith wrote:

> I've got Visual C++ 6.0.  Will that work?

M$ Visual c++ includes the masm but you'll have to check on the version 
  needed for the VSA source. Unless your version of C++ is very old it's 
probably fine.

-Bari



From jardel at lesc.ufc.br  Sat Mar 18 02:07:02 2006
From: jardel at lesc.ufc.br (jardel at lesc.ufc.br)
Date: Fri, 17 Mar 2006 22:07:02 -0300 (BRT)
Subject: [LinuxBIOS] GX eval board
In-Reply-To: <8a0c36780603171326o6d20af13n30ae3e3285e3a606@mail.gmail.com>
References: <8a0c36780603171207l265bda30h64e9f20746eba5a4@mail.gmail.com>
	<441B1893.7040405@lanl.gov>
	<8a0c36780603171226g7cc8a1cbo50417d50b2996967@mail.gmail.com>
	<8a0c36780603171227m4b53785bo28e3a8e1c20a4449@mail.gmail.com>
	<1142629063.5314.8.camel@logarithm.lanl.gov>
	<8a0c36780603171302o35534e65s5e9190a13bcb5a16@mail.gmail.com>
	<441B277C.3060307@lesc.ufc.br>
	<8a0c36780603171326o6d20af13n30ae3e3285e3a606@mail.gmail.com>
Message-ID: <1567.200.195.79.143.1142644022.squirrel@www.lesc.ufc.br>

> On 3/17/06, jardel <jardel at lesc.ufc.br> wrote:
>>
>>    I don't think so. You need MSVC 1.52. The last version of MSVC that
>> comes with MSVC 1.52 is MSVC 4.0. I've read in any location that MS SQL
>> comes with MSVC 1.52.
>
> Ok... I just check and our PNX1500 dev machine has Visual Studio .net
> 2003 installed.  But I don't see anything in the bin dir that is MSVC.
>  Is that the real name of the .exe?
> I don't use M$ compiler stuff much.

The name of the .exe is ml.exe. But it must generate 16 bit code. The last
version that generates 16 bit code is 1.52. You will need the file
SLIBC7.LIB too.

MASM 6.11 + Ms Visual C++ 1.52 (MSVC 1.52) + SLIBC7.LIB works fine. I
tried it.

>
> --
> Richard A. Smith
> --
> linuxbios mailing list
> linuxbios at linuxbios.org
> http://www.openbios.org/mailman/listinfo/linuxbios
>





From smithbone at gmail.com  Sat Mar 18 02:24:18 2006
From: smithbone at gmail.com (Richard Smith)
Date: Fri, 17 Mar 2006 19:24:18 -0600
Subject: [LinuxBIOS] GX eval board
In-Reply-To: <1567.200.195.79.143.1142644022.squirrel@www.lesc.ufc.br>
References: <8a0c36780603171207l265bda30h64e9f20746eba5a4@mail.gmail.com>
	<441B1893.7040405@lanl.gov>
	<8a0c36780603171226g7cc8a1cbo50417d50b2996967@mail.gmail.com>
	<8a0c36780603171227m4b53785bo28e3a8e1c20a4449@mail.gmail.com>
	<1142629063.5314.8.camel@logarithm.lanl.gov>
	<8a0c36780603171302o35534e65s5e9190a13bcb5a16@mail.gmail.com>
	<441B277C.3060307@lesc.ufc.br>
	<8a0c36780603171326o6d20af13n30ae3e3285e3a606@mail.gmail.com>
	<1567.200.195.79.143.1142644022.squirrel@www.lesc.ufc.br>
Message-ID: <8a0c36780603171724p626a1a7ekdca5494b9d0bed03@mail.gmail.com>

> The name of the .exe is ml.exe. But it must generate 16 bit code. The last
> version that generates 16 bit code is 1.52. You will need the file
> SLIBC7.LIB too.
>
> MASM 6.11 + Ms Visual C++ 1.52 (MSVC 1.52) + SLIBC7.LIB works fine. I
> tried it.

Apparently you need cl as well.  I've got MASM and the assembly
portions seem to be doing ok vsa_11\sysmgr\events.c however is giving
things fits.

I think my tools may be too _new_.  Even the cl that comes with VC 6 is pukeing

nonstandard extension used : __pascal is an obsolete keyword.

So I think I man need a 16bit C compiler as well.

Sheesh... I got into LinuxBIOS so I could get _away_ from all this crap.

--
Richard A. Smith

From smithbone at gmail.com  Sat Mar 18 02:30:41 2006
From: smithbone at gmail.com (Richard Smith)
Date: Fri, 17 Mar 2006 19:30:41 -0600
Subject: [LinuxBIOS] GX eval board
In-Reply-To: <8a0c36780603171724p626a1a7ekdca5494b9d0bed03@mail.gmail.com>
References: <8a0c36780603171207l265bda30h64e9f20746eba5a4@mail.gmail.com>
	<441B1893.7040405@lanl.gov>
	<8a0c36780603171226g7cc8a1cbo50417d50b2996967@mail.gmail.com>
	<8a0c36780603171227m4b53785bo28e3a8e1c20a4449@mail.gmail.com>
	<1142629063.5314.8.camel@logarithm.lanl.gov>
	<8a0c36780603171302o35534e65s5e9190a13bcb5a16@mail.gmail.com>
	<441B277C.3060307@lesc.ufc.br>
	<8a0c36780603171326o6d20af13n30ae3e3285e3a606@mail.gmail.com>
	<1567.200.195.79.143.1142644022.squirrel@www.lesc.ufc.br>
	<8a0c36780603171724p626a1a7ekdca5494b9d0bed03@mail.gmail.com>
Message-ID: <8a0c36780603171730j750f296ndb0caef69e59714c@mail.gmail.com>

> > MASM 6.11 + Ms Visual C++ 1.52 (MSVC 1.52) + SLIBC7.LIB works fine. I
> > tried it.
>

> I think my tools may be too _new_.  Even the cl that comes with VC 6 is pukeing
>

Ok.  So I read the docs... Yep.  You need MSVC 1.52.  I don't have
that.  Bummer.

--
Richard A. Smith

From smithbone at gmail.com  Tue Mar 21 04:52:37 2006
From: smithbone at gmail.com (Richard Smith)
Date: Mon, 20 Mar 2006 21:52:37 -0600
Subject: [LinuxBIOS] Firmware hub parts
Message-ID: <8a0c36780603201952t711b1612pf00de58373ab7e78@mail.gmail.com>

I got my eval board today.  The bios chip is a sst 49LF002A which is a
firmware hub part.
My ROM emulator won't work. :(

My programmer will program the parts but that means I'm swapping chips
every cycle which sucks.

Do all the GX2 parts use firmware hubs?

What are my non-programmer options for flashing this part?

--
Richard A. Smith

From stepan at openbios.org  Tue Mar 21 04:56:52 2006
From: stepan at openbios.org (Stefan Reinauer)
Date: Tue, 21 Mar 2006 04:56:52 +0100
Subject: [LinuxBIOS] Firmware hub parts
In-Reply-To: <8a0c36780603201952t711b1612pf00de58373ab7e78@mail.gmail.com>
References: <8a0c36780603201952t711b1612pf00de58373ab7e78@mail.gmail.com>
Message-ID: <20060321035652.GA19150@openbios.org>

* Richard Smith <smithbone at gmail.com> [060321 04:52]:
> I got my eval board today.  The bios chip is a sst 49LF002A which is a
> firmware hub part.
> My ROM emulator won't work. :(
> 
> My programmer will program the parts but that means I'm swapping chips
> every cycle which sucks.
> 
> Do all the GX2 parts use firmware hubs?
> 
> What are my non-programmer options for flashing this part?

BIOS Savior:
http://www.ioss.com.tw/web/English/RD1BIOSSavior.html

Regards,
  Stefan





From smithbone at gmail.com  Tue Mar 21 05:01:50 2006
From: smithbone at gmail.com (Richard Smith)
Date: Mon, 20 Mar 2006 22:01:50 -0600
Subject: [LinuxBIOS] Firmware hub parts
In-Reply-To: <20060321035652.GA19150@openbios.org>
References: <8a0c36780603201952t711b1612pf00de58373ab7e78@mail.gmail.com>
	<20060321035652.GA19150@openbios.org>
Message-ID: <8a0c36780603202001j2b271973v6546af36012dd168@mail.gmail.com>

> >
> > What are my non-programmer options for flashing this part?
>
> BIOS Savior:
> http://www.ioss.com.tw/web/English/RD1BIOSSavior.html
>

I thought I rember reading that they quit makeing these.  That keeps
me from swapping chips.

Will flashrom do this part?

--
Richard A. Smith

From rminnich at gmail.com  Tue Mar 21 05:07:24 2006
From: rminnich at gmail.com (ron minnich)
Date: Mon, 20 Mar 2006 21:07:24 -0700
Subject: [LinuxBIOS] Firmware hub parts
In-Reply-To: <8a0c36780603202001j2b271973v6546af36012dd168@mail.gmail.com>
References: <8a0c36780603201952t711b1612pf00de58373ab7e78@mail.gmail.com>
	<20060321035652.GA19150@openbios.org>
	<8a0c36780603202001j2b271973v6546af36012dd168@mail.gmail.com>
Message-ID: <13426df10603202007g5438bd2t99e70e24fe334bb7@mail.gmail.com>

nah, we just bought some, they are still around and they are working for us
for the 49lf part.

ron
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20060320/4b1798fb/attachment.html>

From rminnich at gmail.com  Tue Mar 21 05:08:26 2006
From: rminnich at gmail.com (ron minnich)
Date: Mon, 20 Mar 2006 21:08:26 -0700
Subject: [LinuxBIOS] Firmware hub parts
In-Reply-To: <13426df10603202007g5438bd2t99e70e24fe334bb7@mail.gmail.com>
References: <8a0c36780603201952t711b1612pf00de58373ab7e78@mail.gmail.com>
	<20060321035652.GA19150@openbios.org>
	<8a0c36780603202001j2b271973v6546af36012dd168@mail.gmail.com>
	<13426df10603202007g5438bd2t99e70e24fe334bb7@mail.gmail.com>
Message-ID: <13426df10603202008l4b62ab65sdc492bd3bc3c6305@mail.gmail.com>

FYI, I just put in the support for calling VSM, and it doubtless doesn't
work :-)

But you're going to need to put a vsm binary as the first piece of your rom.


ron


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

From bari at onelabs.com  Tue Mar 21 05:31:57 2006
From: bari at onelabs.com (Bari Ari)
Date: Mon, 20 Mar 2006 22:31:57 -0600
Subject: [LinuxBIOS] Firmware hub parts
In-Reply-To: <8a0c36780603201952t711b1612pf00de58373ab7e78@mail.gmail.com>
References: <8a0c36780603201952t711b1612pf00de58373ab7e78@mail.gmail.com>
Message-ID: <441F81BD.1020107@onelabs.com>

FWH + it's been EOLed already.

Just FYI... Here's a link to the SST source:
http://www.sst.com/downloads/software_driver/SST49LF002A.txt

The  SST49LF004B is backwards compatible with the SST49LF004A
http://www.sst.com/products.xhtml/serial_flash/49/SST49LF004B

which I recall had the same programming cycles and is still available.

-Bari

Richard Smith wrote:
> I got my eval board today.  The bios chip is a sst 49LF002A which is a
> firmware hub part.
> My ROM emulator won't work. :(
> 
> My programmer will program the parts but that means I'm swapping chips
> every cycle which sucks.
> 
> Do all the GX2 parts use firmware hubs?
> 
> What are my non-programmer options for flashing this part?
> 
> --
> Richard A. Smith



From bari at onelabs.com  Tue Mar 21 05:35:43 2006
From: bari at onelabs.com (Bari Ari)
Date: Mon, 20 Mar 2006 22:35:43 -0600
Subject: [LinuxBIOS] Firmware hub parts
In-Reply-To: <8a0c36780603201952t711b1612pf00de58373ab7e78@mail.gmail.com>
References: <8a0c36780603201952t711b1612pf00de58373ab7e78@mail.gmail.com>
Message-ID: <441F829F.3030309@onelabs.com>

If you are using the 5535 thin client reference design then you can make 
a couple of pin strap changes and have the board boot from the ide/flash 
interface vs the FWH.

-Bari

Richard Smith wrote:
> I got my eval board today.  The bios chip is a sst 49LF002A which is a
> firmware hub part.
> My ROM emulator won't work. :(
> 
> My programmer will program the parts but that means I'm swapping chips
> every cycle which sucks.
> 
> Do all the GX2 parts use firmware hubs?
> 
> What are my non-programmer options for flashing this part?
> 
> --
> Richard A. Smith



From smithbone at gmail.com  Tue Mar 21 15:05:31 2006
From: smithbone at gmail.com (Richard Smith)
Date: Tue, 21 Mar 2006 08:05:31 -0600
Subject: [LinuxBIOS] Firmware hub parts
In-Reply-To: <441F829F.3030309@onelabs.com>
References: <8a0c36780603201952t711b1612pf00de58373ab7e78@mail.gmail.com>
	<441F829F.3030309@onelabs.com>
Message-ID: <8a0c36780603210605q37951c6if378477f3b1743ae@mail.gmail.com>

On 3/20/06, Bari Ari <bari at onelabs.com> wrote:

> If you are using the 5535 thin client reference design then you can make
> a couple of pin strap changes and have the board boot from the ide/flash
> interface vs the FWH.
>

No. Its the SOM made by Advantech.  I'll have to look at the
schematics to see if it has anything like that.  Looking at the board
I doubt it.

--
Richard A. Smith

From bari at onelabs.com  Tue Mar 21 15:38:20 2006
From: bari at onelabs.com (Bari Ari)
Date: Tue, 21 Mar 2006 08:38:20 -0600
Subject: [LinuxBIOS] Firmware hub parts
In-Reply-To: <8a0c36780603210605q37951c6if378477f3b1743ae@mail.gmail.com>
References: <8a0c36780603201952t711b1612pf00de58373ab7e78@mail.gmail.com>	
	<441F829F.3030309@onelabs.com>
	<8a0c36780603210605q37951c6if378477f3b1743ae@mail.gmail.com>
Message-ID: <44200FDC.5050109@onelabs.com>

The 5535 has pin straps that Advantech would have to use.

What model number is your SOM? PCM-58xx seems to be the range of model 
numbers for their AMD Geode boards.

Does your board have an IDE interface?

If so, you should be able to have it boot from flash/ide by swapping a 
couple resistors on the board.

-Bari

Richard Smith wrote:
> On 3/20/06, Bari Ari <bari at onelabs.com> wrote:
> 
> 
>>If you are using the 5535 thin client reference design then you can make
>>a couple of pin strap changes and have the board boot from the ide/flash
>>interface vs the FWH.
>>
> 
> 
> No. Its the SOM made by Advantech.  I'll have to look at the
> schematics to see if it has anything like that.  Looking at the board
> I doubt it.
> 
> --
> Richard A. Smith



From smithbone at gmail.com  Tue Mar 21 15:44:50 2006
From: smithbone at gmail.com (Richard Smith)
Date: Tue, 21 Mar 2006 08:44:50 -0600
Subject: [LinuxBIOS] Firmware hub parts
In-Reply-To: <8a0c36780603210605q37951c6if378477f3b1743ae@mail.gmail.com>
References: <8a0c36780603201952t711b1612pf00de58373ab7e78@mail.gmail.com>
	<441F829F.3030309@onelabs.com>
	<8a0c36780603210605q37951c6if378477f3b1743ae@mail.gmail.com>
Message-ID: <8a0c36780603210644q3d2451c3jeb4fe2eae5eb7ac8@mail.gmail.com>

>
> No. Its the SOM made by Advantech.  I'll have to look at the
> schematics to see if it has anything like that.  Looking at the board.

Yeah.  I've got strappings for switching to NOR/IDE.

So how does that work?
Do you lose the IDE interface and it turns into address and data?

--
Richard A. Smith

From smithbone at gmail.com  Tue Mar 21 15:47:01 2006
From: smithbone at gmail.com (Richard Smith)
Date: Tue, 21 Mar 2006 08:47:01 -0600
Subject: [LinuxBIOS] Firmware hub parts
In-Reply-To: <44200FDC.5050109@onelabs.com>
References: <8a0c36780603201952t711b1612pf00de58373ab7e78@mail.gmail.com>
	<441F829F.3030309@onelabs.com>
	<8a0c36780603210605q37951c6if378477f3b1743ae@mail.gmail.com>
	<44200FDC.5050109@onelabs.com>
Message-ID: <8a0c36780603210647g7d227633pc6e0bbc271e047dd@mail.gmail.com>

On 3/21/06, Bari Ari <bari at onelabs.com> wrote:

> What model number is your SOM? PCM-58xx seems to be the range of model
> numbers for their AMD Geode boards.

SOM-2354V

> Does your board have an IDE interface?

Yeah.

> If so, you should be able to have it boot from flash/ide by swapping a
> couple resistors on the board.

I found the resistors on the schematic.  Finding them among the 0402s
on the board will be a challenge...

--
Richard A. Smith

From Rodney.Kittleson at bench.com  Tue Mar 21 16:14:40 2006
From: Rodney.Kittleson at bench.com (Rodney.Kittleson at bench.com)
Date: Tue, 21 Mar 2006 09:14:40 -0600
Subject: [LinuxBIOS] GX eval board
Message-ID: <2A4A703C1E2835429F547DFFD236B7D103C80E@mn-ex1.mn.bench.com>

2 years ago I lucked out and picked up a copy of MSVC 1.52 on ebay for a
couple of bucks.  It might be worth checking ebay.

Rod

-----Original Message-----
From: linuxbios-bounces at linuxbios.org
[mailto:linuxbios-bounces at linuxbios.org] On Behalf Of Richard Smith
Sent: Friday, March 17, 2006 7:31 PM
To: jardel at lesc.ufc.br
Cc: LinuxBIOS
Subject: Re: [LinuxBIOS] GX eval board


> > MASM 6.11 + Ms Visual C++ 1.52 (MSVC 1.52) + SLIBC7.LIB works fine.
I
> > tried it.
>

> I think my tools may be too _new_.  Even the cl that comes with VC 6
is pukeing
>

Ok.  So I read the docs... Yep.  You need MSVC 1.52.  I don't have
that.  Bummer.

--
Richard A. Smith
-- 
linuxbios mailing list
linuxbios at linuxbios.org
http://www.openbios.org/mailman/listinfo/linuxbios



From rminnich at lanl.gov  Tue Mar 21 16:24:12 2006
From: rminnich at lanl.gov (Ronald G Minnich)
Date: Tue, 21 Mar 2006 08:24:12 -0700
Subject: [LinuxBIOS] Firmware hub parts
In-Reply-To: <13426df10603202008l4b62ab65sdc492bd3bc3c6305@mail.gmail.com>
References: <8a0c36780603201952t711b1612pf00de58373ab7e78@mail.gmail.com>	<20060321035652.GA19150@openbios.org>	<8a0c36780603202001j2b271973v6546af36012dd168@mail.gmail.com>	<13426df10603202007g5438bd2t99e70e24fe334bb7@mail.gmail.com>
	<13426df10603202008l4b62ab65sdc492bd3bc3c6305@mail.gmail.com>
Message-ID: <44201A9C.9020205@lanl.gov>

ron minnich wrote:
> FYI, I just put in the support for calling VSM, and it doubtless doesn't 
> work :-)
> 
> But you're going to need to put a vsm binary as the first piece of your rom.
> 

I fixed this to look for a POST signature at start of vsainit.bin. If it 
does not find it, it will not try to run vsainit.bin

so you're still safe.

you can run linuxbios until it fails because there is no VSM :-)

ron



From stepan at openbios.org  Tue Mar 21 16:34:10 2006
From: stepan at openbios.org (Stefan Reinauer)
Date: Tue, 21 Mar 2006 16:34:10 +0100
Subject: [LinuxBIOS] GX eval board
In-Reply-To: <2A4A703C1E2835429F547DFFD236B7D103C80E@mn-ex1.mn.bench.com>
References: <2A4A703C1E2835429F547DFFD236B7D103C80E@mn-ex1.mn.bench.com>
Message-ID: <20060321153410.GA11987@openbios.org>

* Rodney.Kittleson at bench.com <Rodney.Kittleson at bench.com> [060321 16:14]:
> 2 years ago I lucked out and picked up a copy of MSVC 1.52 on ebay for a
> couple of bucks.  It might be worth checking ebay.

Does it not make sense to port that code to compile with gas? 

What's that magic that keeps the dependency to some pre-civilization
microsoft product?

Without me knowing the code it feels a bit against the LinuxBIOS idea to
ship binary stuff because noone can compile it.

Just my 2ct.

Stefan




From rminnich at lanl.gov  Tue Mar 21 16:43:48 2006
From: rminnich at lanl.gov (Ronald G Minnich)
Date: Tue, 21 Mar 2006 08:43:48 -0700
Subject: [LinuxBIOS] GX eval board
In-Reply-To: <20060321153410.GA11987@openbios.org>
References: <2A4A703C1E2835429F547DFFD236B7D103C80E@mn-ex1.mn.bench.com>
	<20060321153410.GA11987@openbios.org>
Message-ID: <44201F34.2030307@lanl.gov>

Stefan Reinauer wrote:
> * Rodney.Kittleson at bench.com <Rodney.Kittleson at bench.com> [060321 16:14]:
> 
>>2 years ago I lucked out and picked up a copy of MSVC 1.52 on ebay for a
>>couple of bucks.  It might be worth checking ebay.
> 
> 
> Does it not make sense to port that code to compile with gas? 


it will happen.

ron



From smithbone at gmail.com  Tue Mar 21 16:59:57 2006
From: smithbone at gmail.com (Richard Smith)
Date: Tue, 21 Mar 2006 09:59:57 -0600
Subject: [LinuxBIOS] GX eval board
In-Reply-To: <20060321153410.GA11987@openbios.org>
References: <2A4A703C1E2835429F547DFFD236B7D103C80E@mn-ex1.mn.bench.com>
	<20060321153410.GA11987@openbios.org>
Message-ID: <8a0c36780603210759t27ed1976yfb57aebb3e5ab08b@mail.gmail.com>

>
> Does it not make sense to port that code to compile with gas?
>
> What's that magic that keeps the dependency to some pre-civilization
> microsoft product?

You have to produce 16-bit output.  Both for assembly and the couple
of C files that are in there.  You could use NASM for the 16 bit
assembly but I'm not sure about the C. OpenWatcom still has a 16 bit C
compiler in thier offerings.  I pulled it down but I've not really
groked the license yet.

The ADLO code in V1 is mixed C/asm in 16-bit mode with NASM and gcc. 
I'm going to go back and take a look at how that was done.

> Without me knowing the code it feels a bit against the LinuxBIOS idea to
> ship binary stuff because noone can compile it.

I agree fully. It should be ported.  It will be a large project to
undertake since there is a pile of assembly code.

I also don't fully yet grok the inner workings of the VSA.  All you
who are in this deeper perhaps can comment.  Is there any hardware
reason that the VSA _has_ to be in 16-bit mode?  I know orginally it
had to be 16-bit for the BIOS callbacks, but we don't require all that
legacy stuff.

Can we port the necessary parts over to protected mode?

--
Richard A. Smith

From ollie at lanl.gov  Tue Mar 21 18:00:26 2006
From: ollie at lanl.gov (Li-Ta Lo)
Date: Tue, 21 Mar 2006 10:00:26 -0700
Subject: [LinuxBIOS] GX eval board
In-Reply-To: <8a0c36780603210759t27ed1976yfb57aebb3e5ab08b@mail.gmail.com>
References: <2A4A703C1E2835429F547DFFD236B7D103C80E@mn-ex1.mn.bench.com>
	<20060321153410.GA11987@openbios.org>
	<8a0c36780603210759t27ed1976yfb57aebb3e5ab08b@mail.gmail.com>
Message-ID: <1142960426.7457.23.camel@logarithm.lanl.gov>

On Tue, 2006-03-21 at 09:59 -0600, Richard Smith wrote:
> 
> I also don't fully yet grok the inner workings of the VSA.  All you
> who are in this deeper perhaps can comment.  Is there any hardware
> reason that the VSA _has_ to be in 16-bit mode?  I know orginally it
> had to be 16-bit for the BIOS callbacks, but we don't require all that
> legacy stuff.
> 

One problem is the VSA code is executed under the SMM. The SMM i
is 16-bit mode by default. Theoretically, we can have a 16-bit to
32-bit switch upon the entry of SMM and port the VSA to 32-bit
mode. I am not so sure if it is worth to do this.
 
> Can we port the necessary parts over to protected mode?
> 
> --
> Richard A. Smith
-- 
Li-Ta Lo <ollie at lanl.gov>
Los Alamos National Lab




From rminnich at lanl.gov  Tue Mar 21 18:57:02 2006
From: rminnich at lanl.gov (Ronald G Minnich)
Date: Tue, 21 Mar 2006 10:57:02 -0700
Subject: [LinuxBIOS] GX eval board
In-Reply-To: <8a0c36780603210759t27ed1976yfb57aebb3e5ab08b@mail.gmail.com>
References: <2A4A703C1E2835429F547DFFD236B7D103C80E@mn-ex1.mn.bench.com>	<20060321153410.GA11987@openbios.org>
	<8a0c36780603210759t27ed1976yfb57aebb3e5ab08b@mail.gmail.com>
Message-ID: <44203E6E.5090701@lanl.gov>

Richard Smith wrote:

> I also don't fully yet grok the inner workings of the VSA.  All you
> who are in this deeper perhaps can comment.  Is there any hardware
> reason that the VSA _has_ to be in 16-bit mode?  I know orginally it
> had to be 16-bit for the BIOS callbacks, but we don't require all that
> legacy stuff.

not that I know of.

> 
> Can we port the necessary parts over to protected mode?

  I want to have as little as possible in bios. NO reason not to put 
lots of stuff directly in linux.

ron



From rminnich at lanl.gov  Wed Mar 22 00:20:53 2006
From: rminnich at lanl.gov (Ronald G Minnich)
Date: Tue, 21 Mar 2006 16:20:53 -0700
Subject: [LinuxBIOS] gx2 status
Message-ID: <44208A55.9040408@lanl.gov>

ok, gx2 bios for lippert will now call vsm, and then ... lockup.

for those of you who want to experiment with this ... we're waiting on 
our jtag debugger.

ron



From stepan at openbios.org  Wed Mar 22 01:05:36 2006
From: stepan at openbios.org (Stefan Reinauer)
Date: Wed, 22 Mar 2006 01:05:36 +0100
Subject: [LinuxBIOS] GX eval board
In-Reply-To: <44203E6E.5090701@lanl.gov>
References: <2A4A703C1E2835429F547DFFD236B7D103C80E@mn-ex1.mn.bench.com>
	<20060321153410.GA11987@openbios.org>
	<8a0c36780603210759t27ed1976yfb57aebb3e5ab08b@mail.gmail.com>
	<44203E6E.5090701@lanl.gov>
Message-ID: <20060322000536.GB1890@openbios.org>

* Ronald G Minnich <rminnich at lanl.gov> [060321 18:57]:
> >Can we port the necessary parts over to protected mode?
> 
>  I want to have as little as possible in bios. NO reason not to put 
> lots of stuff directly in linux.
 
Except it wont help when you do Plan9 or BSD ;-)

Stefan 




From bari at onelabs.com  Wed Mar 22 03:56:03 2006
From: bari at onelabs.com (Bari Ari)
Date: Tue, 21 Mar 2006 20:56:03 -0600
Subject: [LinuxBIOS] Firmware hub parts
In-Reply-To: <8a0c36780603210644q3d2451c3jeb4fe2eae5eb7ac8@mail.gmail.com>
References: <8a0c36780603201952t711b1612pf00de58373ab7e78@mail.gmail.com>	
	<441F829F.3030309@onelabs.com>	
	<8a0c36780603210605q37951c6if378477f3b1743ae@mail.gmail.com>
	<8a0c36780603210644q3d2451c3jeb4fe2eae5eb7ac8@mail.gmail.com>
Message-ID: <4420BCC3.7030006@onelabs.com>

Richard Smith wrote:
> Yeah.  I've got strappings for switching to NOR/IDE.
> 
> So how does that work?
> Do you lose the IDE interface and it turns into address and data?

http://wwwd.amd.com/AMD/developer.NSF/files/Alchemy_15/$File/31506_cs5535_databook.pdf

Take a look at the cs5535 datasheet, starting at page 183 for the full 
scoop.

-Bari



From smithbone at gmail.com  Wed Mar 22 07:42:43 2006
From: smithbone at gmail.com (Richard Smith)
Date: Wed, 22 Mar 2006 00:42:43 -0600
Subject: [LinuxBIOS] Missing file from commit
Message-ID: <8a0c36780603212242y45f8eff7sbfeff7c8c597d271@mail.gmail.com>

Probally need to start doing a checkout and rebuild to a clean
directory after you commit since I suspect you will be adding a lot of
files in near future.

gcc -m32 ... -o crt0.o crt0.s
make[1]: *** No rule to make target
`/projects/LinuxBIOSv2/src/cpu/amd/model_gx2/vsmsetup.c', needed by
`vsmsetup.o'.  Stop.
make[1]: Leaving directory
`/projects/LinuxBIOSv2/targets/lippert/frontrunner/frontrunner/normal'
make: *** [normal/linuxbios.rom] Error 1
rsmith at richlap:/projects/LinuxBIOSv2/targets/lippert/frontrunner/frontrunner$

--
Richard A. Smith

From rminnich at lanl.gov  Wed Mar 22 17:19:31 2006
From: rminnich at lanl.gov (Ronald G Minnich)
Date: Wed, 22 Mar 2006 09:19:31 -0700
Subject: [LinuxBIOS] Missing file from commit
In-Reply-To: <8a0c36780603212242y45f8eff7sbfeff7c8c597d271@mail.gmail.com>
References: <8a0c36780603212242y45f8eff7sbfeff7c8c597d271@mail.gmail.com>
Message-ID: <44217913.6060300@lanl.gov>

Richard Smith wrote:
> Probally need to start doing a checkout and rebuild to a clean
> directory after you commit since I suspect you will be adding a lot of
> files in near future.
> 
> gcc -m32 ... -o crt0.o crt0.s
> make[1]: *** No rule to make target
> `/projects/LinuxBIOSv2/src/cpu/amd/model_gx2/vsmsetup.c', needed by
> `vsmsetup.o'.  Stop.
> make[1]: Leaving directory
> `/projects/LinuxBIOSv2/targets/lippert/frontrunner/frontrunner/normal'
> make: *** [normal/linuxbios.rom] Error 1
> rsmith at richlap:/projects/LinuxBIOSv2/targets/lippert/frontrunner/frontrunner$
> 
> --
> Richard A. Smith

fixed, sorry.

ron



From pdegler at rumms.uni-mannheim.de  Wed Mar 22 17:58:48 2006
From: pdegler at rumms.uni-mannheim.de (Philipp Degler)
Date: Wed, 22 Mar 2006 17:58:48 +0100
Subject: [LinuxBIOS] resourcemap for IWill dk8htx
Message-ID: <200603221758.51609.pdegler@rumms.uni-mannheim.de>

Hi 

I started porting LinuxBIOS to IWill dk8-htx board. I used the dk8s2 to start 
from.  After some smaller changes to the Config.lb I could compile it and 
flash it with flashrom. Unfortunately it seems that the default_resource_map 
is not working.

This is what I get when I debug a little.
LinuxBIOS-1.1.8_Fallback Wed Mar 22 16:32:37 CET 2006 starting...

i386 console_init

report_bist_failure

setup_default_resource_map

setting up resource map....

0000c14c <-00000001

0000c154 <-00000002

0000c15c <-00000003

0000c164 <-00000004

0000c16c <-00000005

0000c174 <-00000006

0000c17c <-00000007

0000c140 <-00000000

0000c148 <-00000000

0000c150 <-00000000

0000c158 <-00000000

0000c160 <-00000000

0000c168 <-00000000

0000c170 <-00000000

0000c178 <-00000000

0000c184 <-00000000

0000c18c <-00000000

0000c194 <-00000000

0000c19c <-00000000

0000c1a4 <-00000000

0000c1ac <-00000000

0000c1b4 <-00000000

0000c1bc <-00ffff00

0000c180 <-00000000

0000c188 <-00000000

0000c190 <-00000000

0000c198 <-00000000

0000c1a0 <-00000000

0000c1a8 <-00000000

0000c1b0 <-00000000

0000c1b8 <-00fc0003

0000c1c4 <-01fff000

0000c1cc <-00000000

0000c1d4 <-

Is there any documentation or specification that can help me setting up this 
resourcemap?

phil



From stepan at openbios.org  Wed Mar 22 18:04:31 2006
From: stepan at openbios.org (Stefan Reinauer)
Date: Wed, 22 Mar 2006 18:04:31 +0100
Subject: [LinuxBIOS] resourcemap for IWill dk8htx
In-Reply-To: <200603221758.51609.pdegler@rumms.uni-mannheim.de>
References: <200603221758.51609.pdegler@rumms.uni-mannheim.de>
Message-ID: <20060322170431.GA16091@openbios.org>

* Philipp Degler <pdegler at rumms.uni-mannheim.de> [060322 17:58]:
> Hi 
> 
> I started porting LinuxBIOS to IWill dk8-htx board. I used the dk8s2 to start 
> from.  After some smaller changes to the Config.lb I could compile it and 
> flash it with flashrom. Unfortunately it seems that the default_resource_map 
> is not working.


> Is there any documentation or specification that can help me setting up this 
> resourcemap?

Check the bios and kernel developers guide for K8.

i would guess your SB (8111?) is not hanging off Node0 Link LDT0
Check for example the newisys/khepri resourcemap.c to see how it could
look different.

Also, dumping the resource map with the factory bios running will
probably help.

Stefan



From yinghai.lu at amd.com  Wed Mar 22 18:26:20 2006
From: yinghai.lu at amd.com (Lu, Yinghai)
Date: Wed, 22 Mar 2006 09:26:20 -0800
Subject: [LinuxBIOS] resourcemap for IWill dk8htx
Message-ID: <6F7DA19D05F3CF40B890C7CA2DB13A4203094B03@ssvlexmb2.amd.com>

Comment several lines in resource.c

117,152,179,209,249.

These register will be set automatically later in the code.

YH


-----Original Message-----
From: linuxbios-bounces at linuxbios.org
[mailto:linuxbios-bounces at linuxbios.org] On Behalf Of Philipp Degler
Sent: Wednesday, March 22, 2006 8:59 AM
To: linuxbios at linuxbios.org
Subject: [LinuxBIOS] resourcemap for IWill dk8htx

Hi 

I started porting LinuxBIOS to IWill dk8-htx board. I used the dk8s2 to
start 
from.  After some smaller changes to the Config.lb I could compile it
and 
flash it with flashrom. Unfortunately it seems that the
default_resource_map 
is not working.

This is what I get when I debug a little.
LinuxBIOS-1.1.8_Fallback Wed Mar 22 16:32:37 CET 2006 starting...

i386 console_init

report_bist_failure

setup_default_resource_map

setting up resource map....

0000c14c <-00000001

0000c154 <-00000002

0000c15c <-00000003

0000c164 <-00000004

0000c16c <-00000005

0000c174 <-00000006

0000c17c <-00000007

0000c140 <-00000000

0000c148 <-00000000

0000c150 <-00000000

0000c158 <-00000000

0000c160 <-00000000

0000c168 <-00000000

0000c170 <-00000000

0000c178 <-00000000

0000c184 <-00000000

0000c18c <-00000000

0000c194 <-00000000

0000c19c <-00000000

0000c1a4 <-00000000

0000c1ac <-00000000

0000c1b4 <-00000000

0000c1bc <-00ffff00

0000c180 <-00000000

0000c188 <-00000000

0000c190 <-00000000

0000c198 <-00000000

0000c1a0 <-00000000

0000c1a8 <-00000000

0000c1b0 <-00000000

0000c1b8 <-00fc0003

0000c1c4 <-01fff000

0000c1cc <-00000000

0000c1d4 <-

Is there any documentation or specification that can help me setting up
this 
resourcemap?

phil

-- 
linuxbios mailing list
linuxbios at linuxbios.org
http://www.openbios.org/mailman/listinfo/linuxbios





From ollie at lanl.gov  Wed Mar 22 21:46:15 2006
From: ollie at lanl.gov (Li-Ta Lo)
Date: Wed, 22 Mar 2006 13:46:15 -0700
Subject: [LinuxBIOS] OLPC Keyboard/System Controller ENE KB3920
In-Reply-To: <1142478181.9046.81.camel@localhost.localdomain>
References: <4416CF79.7070900@onelabs.com>
	<1142379778.8955.48.camel@localhost.localdomain>
	<441790F9.1070304@onelabs.com>
	<1142397167.8955.233.camel@localhost.localdomain>
	<4417A19C.7000906@onelabs.com>
	<13426df10603151851u25227b68l156b9b540e4fd00@mail.gmail.com>
	<1142478181.9046.81.camel@localhost.localdomain>
Message-ID: <1143060375.7457.69.camel@logarithm.lanl.gov>

On Wed, 2006-03-15 at 22:03 -0500, Jim Gettys wrote:
> I expect it is easy.
> 
> I just put it on Mark Foster's list, so that a jumper might appear in
> the right place...  It is easy to overlook such details (though this one
> is small enough it might have been simple to get added later); but the
> closer to production the first board is, the better.
> 				- Jim
> 

The SPI flash rom they are going to use has a W# signal. When it is 
driven low and some register bit is set, certain part (programmable)
of the flash can't be programmed.

In the schematics, they pull the W# hi (software write protect).

-- 
Li-Ta Lo <ollie at lanl.gov>
Los Alamos National Lab




From jg at laptop.org  Thu Mar 23 16:25:57 2006
From: jg at laptop.org (Jim Gettys)
Date: Thu, 23 Mar 2006 10:25:57 -0500
Subject: [LinuxBIOS] [Fwd: Hardware Write-Protect for BIOS & EC]
Message-ID: <1143127557.6249.4.camel@localhost.localdomain>

OK, here's the proposed solution for write protect of the OLPC BIOS.

Short of phishing attacks, I think it should suffice; but I'd like
people here to shoot at the scheme in case I'm missing something.
                          Regards,
                              - Jim

-- 
Jim Gettys
One Laptop Per Child

-------------- next part --------------
An embedded message was scrubbed...
From: "Mark J. Foster" <markf at talix.com>
Subject: Hardware Write-Protect for BIOS & EC
Date: Wed, 22 Mar 2006 18:28:04 -0800
Size: 3123
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20060323/5a6f3753/attachment.mht>

From yinghai.lu at amd.com  Thu Mar 23 18:38:26 2006
From: yinghai.lu at amd.com (Lu, Yinghai)
Date: Thu, 23 Mar 2006 09:38:26 -0800
Subject: [LinuxBIOS] [Fwd: Hardware Write-Protect for BIOS & EC]
Message-ID: <6F7DA19D05F3CF40B890C7CA2DB13A4203094B0D@ssvlexmb2.amd.com>

1. in you suggestion. When you are flash the rom, if sth go wrong (lose
power), you will corrupt your rom.
2. are you going to use fallback image with normal image?
If so you can disable the write to last 128K ( fallback image part) via
HW jumper.  ---- No one could change the fallback image without remove
the jumper. Some MB already have that for last 64k.

YH



-----Original Message-----
From: linuxbios-bounces at linuxbios.org
[mailto:linuxbios-bounces at linuxbios.org] On Behalf Of Jim Gettys
Sent: Thursday, March 23, 2006 7:26 AM
To: LinuxBIOS
Subject: [LinuxBIOS] [Fwd: Hardware Write-Protect for BIOS & EC]

OK, here's the proposed solution for write protect of the OLPC BIOS.

Short of phishing attacks, I think it should suffice; but I'd like
people here to shoot at the scheme in case I'm missing something.
                          Regards,
                              - Jim

-- 
Jim Gettys
One Laptop Per Child





From rminnich at lanl.gov  Thu Mar 23 18:38:17 2006
From: rminnich at lanl.gov (Ronald G Minnich)
Date: Thu, 23 Mar 2006 10:38:17 -0700
Subject: [LinuxBIOS] [Fwd: Hardware Write-Protect for BIOS & EC]
In-Reply-To: <6F7DA19D05F3CF40B890C7CA2DB13A4203094B0D@ssvlexmb2.amd.com>
References: <6F7DA19D05F3CF40B890C7CA2DB13A4203094B0D@ssvlexmb2.amd.com>
Message-ID: <4422DD09.8040005@lanl.gov>

Lu, Yinghai wrote:
> 1. in you suggestion. When you are flash the rom, if sth go wrong (lose
> power), you will corrupt your rom.
> 2. are you going to use fallback image with normal image?
> If so you can disable the write to last 128K ( fallback image part) via
> HW jumper.  ---- No one could change the fallback image without remove
> the jumper. Some MB already have that for last 64k.


I think that having a 'you can never write this' bios image would be 
useful. The power fail scenario is a concern.

ron



From smithbone at gmail.com  Thu Mar 23 20:56:57 2006
From: smithbone at gmail.com (Richard Smith)
Date: Thu, 23 Mar 2006 13:56:57 -0600
Subject: [LinuxBIOS] [Fwd: Hardware Write-Protect for BIOS & EC]
In-Reply-To: <4422DD09.8040005@lanl.gov>
References: <6F7DA19D05F3CF40B890C7CA2DB13A4203094B0D@ssvlexmb2.amd.com>
	<4422DD09.8040005@lanl.gov>
Message-ID: <8a0c36780603231156h11abf901o40786ee3aefbd565@mail.gmail.com>

>
>
> I think that having a 'you can never write this' bios image would be
> useful. The power fail scenario is a concern.
>

Many flash parts support a hardware lock where you can set a split. 
Areas that have been hardware locked can only be reprogrammed via the
right programming voltage which is normally much higher than Vcc.

--
Richard A. Smith

From David.Wahl at amd.com  Fri Mar 24 18:31:29 2006
From: David.Wahl at amd.com (Wahl, David)
Date: Fri, 24 Mar 2006 11:31:29 -0600
Subject: [LinuxBIOS] [Fwd: Hardware Write-Protect for BIOS & EC]
Message-ID: <37344FD98E40254AB046B70719BA4F1E01D491B4@SAUSEXMB1.amd.com>

A corrupted ROM has to be followed by a system restore, either manual or
automatic, depending on the level of intelligence you want to build into
the hardware.  I have seen scenarios where restore partition is in an
unwritable location and there is a ROM in some safe location whose sole
purpose is to restore from the protected partition.

thanks,
d.

-----Original Message-----
From: linuxbios-bounces at linuxbios.org
[mailto:linuxbios-bounces at linuxbios.org] On Behalf Of Ronald G Minnich
Sent: Thursday, March 23, 2006 10:38 AM
To: Lu, Yinghai
Cc: jg at laptop.org; LinuxBIOS
Subject: Re: [LinuxBIOS] [Fwd: Hardware Write-Protect for BIOS & EC]

Lu, Yinghai wrote:
> 1. in you suggestion. When you are flash the rom, if sth go wrong 
> (lose power), you will corrupt your rom.
> 2. are you going to use fallback image with normal image?
> If so you can disable the write to last 128K ( fallback image part) 
> via HW jumper.  ---- No one could change the fallback image without 
> remove the jumper. Some MB already have that for last 64k.


I think that having a 'you can never write this' bios image would be
useful. The power fail scenario is a concern.

ron

--
linuxbios mailing list
linuxbios at linuxbios.org
http://www.openbios.org/mailman/listinfo/linuxbios





From yinghai.lu at amd.com  Fri Mar 24 21:57:28 2006
From: yinghai.lu at amd.com (Lu, Yinghai)
Date: Fri, 24 Mar 2006 12:57:28 -0800
Subject: [LinuxBIOS] S2881 and linuxbios
Message-ID: <6F7DA19D05F3CF40B890C7CA2DB13A4203094B23@ssvlexmb2.amd.com>

Good. 

Can you use memtest as your payload?

1. get memtest...enable serial port support, and compile it.
2. load it as payload for LinuxBIOS 
3. or use Etherboot or Filo to load memtest.

YH

-----Original Message-----
From: Per Gregers Bilse [mailto:bilse at networksignature.com] 
Sent: Friday, March 24, 2006 12:44 PM
To: Lu, Yinghai
Subject: RE: S2881 and linuxbios

On Mar 23,  1:56pm yinghai.lu at amd.com wrote:
> There is linux util under src/util/flashrom. Please use that to update
> your BIOS.

Thanks, that (and some payload tweaks) got me much further.  I now
have a kernel panic during booting.  Could you possibly take a look
at the output below and see if you spot something?  I notice that
it says the CMOS checksum is wrong, but I don't understand why;
I use cmos_utils to write a CMOS image to CMOS before trying to
boot with LinuxBIOS, so AFAIK it should have the correct checksum
for LinuxBIOS.

Thanks, best,

  -- Per


LinuxBIOS-1.1.8_s2881_Normal Fri Mar 24 19:45:27 GMT 2006 starting...
(0,1) link=00
(1,0) link=00
02 nodes in icotireal0:i ze d-.-- 
{  APICID = 01 NODEID = 01 COREID = 00} ---
SBLink=02
NC node|link=02
ht reset -


LinuxBIOS-1.1.8_s2881_Normal Fri Mar 24 19:45:27 GMT 2006 starting...
(0,1) link=00
(1,0) link=00
02 nodes i ncoirtei0a:l iz e--d-. {
  APICID = 01 NODEID = 01 COREID = 00} ---
SBLink=02
NC node|link=02
Ram1.00
Ram1.01
Ram2.00
Ram2.01
Ram3
Initializing memory:  done
Initializing memory:  done
Ram4
v_esp=000cfd3c
cpu_reset = 00000000
Clearing initial memory region: No cache as ram now - Use Ram as Stack
now - done
new_cpu_reset = 00000000
Copying LinuxBIOS to ram.
src=fffa0004
dst=00004000
linxbios_ram.bin length = 000192ac
Jumping to LinuxBIOS.
LinuxBIOS-1.1.8_s2881_Normal Fri Mar 24 19:45:27 GMT 2006 booting...
Enumerating buses...
APIC_CLUSTER: 0 enabled
PCI_DOMAIN: 0000 enabled
  PCI: 00:18.3 siblings=0
CPU: APIC: 00 enabled
PCI: 00:19.0 [1022/1100] enabled
PCI: 00:19.1 [1022/1101] enabled
PCI: 00:19.2 [1022/1102] enabled
PCI: 00:19.3 [1022/1103] enabled
  PCI: 00:19.3 siblings=0
CPU: APIC: 01 enabled
PCI: pci_scan_bus for bus 0
PCI: 00:18.0 [1022/1100] enabled
PCI: 00:18.1 [1022/1101] enabled
PCI: 00:18.2 [1022/1102] enabled
PCI: 00:18.3 [1022/1103] enabled
PCI: 00:19.0 [1022/1100] enabled
PCI: 00:19.1 [1022/1101] enabled
PCI: 00:19.2 [1022/1102] enabled
PCI: 00:19.3 [1022/1103] enabled
PCI: 01:00.0 [1022/7450] enabled
PCI: 01:01.0 [1022/7450] enabled next_unitid: 0003
PCI: 01:00.0 [1022/7460] enabled
PCI: 01:03.0 [1022/7460] enabled next_unitid: 0007
PCI: pci_scan_bus for bus 1
PCI: 01:01.0 [1022/7450] enabled
PCI: 01:01.1 [1022/7451] enabled
PCI: 01:02.0 [1022/7450] enabled
PCI: 01:02.1 [1022/7451] enabled
PCI: 01:03.0 [1022/7460] enabled
PCI: 01:04.0 [1022/7468] enabled
PCI: 01:04.1 [1022/7469] enabled
PCI: 01:04.2 [1022/746a] enabled
PCI: 01:04.3 [1022/746b] enabled
PCI: pci_scan_bus for bus 2
PCI: 02:08.0 [8086/1027] enabled
PCI: 02:09.0 [14e4/1648] enabled
PCI: 02:09.1 [14e4/1648] enabled
Disabling static device: PCI: 02:0a.0
Disabling static device: PCI: 02:0a.1
PCI: pci_scan_bus returning with max=02
PCI: 02: 100MHz PCI-X
PCI: 02:08.0 AMD8131 PCI-X tuning
PCI: pci_scan_bus for bus 3
PCI: 03:03.0 [14e4/16a7] enabled
PCI: pci_scan_bus returning with max=03
PCI: 03: 133MHz PCI-X
PCI: 03:03.0 AMD8131 PCI-X tuning
PCI: pci_scan_bus for bus 4
PCI: 04:00.0 [1022/7464] enabled
PCI: 04:00.1 [1022/7464] enabled
PCI: 04:05.0 [1095/3114] enabled
PCI: 04:06.0 [1002/4752] enabled
PCI: pci_scan_bus returning with max=04
PNP: 002e.0 enabled
PNP: 002e.1 disabled
PNP: 002e.2 enabled
PNP: 002e.3 disabled
PNP: 002e.5 enabled
PNP: 002e.6 disabled
PNP: 002e.7 disabled
PNP: 002e.8 disabled
PNP: 002e.9 disabled
PNP: 002e.a disabled
PNP: 002e.b enabled
smbus: PCI: 01:04.3[0]->I2C: 01:50 enabled
smbus: PCI: 01:04.3[0]->I2C: 01:51 enabled
smbus: PCI: 01:04.3[0]->I2C: 01:52 enabled
smbus: PCI: 01:04.3[0]->I2C: 01:53 enabled
smbus: PCI: 01:04.3[0]->I2C: 01:54 enabled
smbus: PCI: 01:04.3[0]->I2C: 01:55 enabled
smbus: PCI: 01:04.3[0]->I2C: 01:56 enabled
smbus: PCI: 01:04.3[0]->I2C: 01:57 enabled
smbus: PCI: 01:04.3[0]->I2C: 01:2d enabled
smbus: PCI: 01:04.3[0]->I2C: 01:2a enabled
smbus: PCI: 01:04.3[0]->I2C: 01:49 enabled
smbus: PCI: 01:04.3[0]->I2C: 01:4a enabled
PCI: pci_scan_bus returning with max=04
PCI: pci_scan_bus returning with max=04
done
Allocating resources...
Reading resources...
PCI: 01:01.0 24 <- [0xfffffffffff00000 - 0xffffffffffefffff] bus 2
prefmem
PCI: 01:02.0 1c <- [0x00fffff000 - 0x00ffffefff] bus 3 io
PCI: 01:02.0 24 <- [0xfffffffffff00000 - 0xffffffffffefffff] bus 3
prefmem
PCI: 01:03.0 24 <- [0x00fff00000 - 0x00ffefffff] bus 4 prefmem
Done reading resources.
Setting resources...
PCI: 00:18.0 1ba <- [0x00fe400000 - 0x00fe3fffff] prefmem <node 0 link
2>
PCI: 00:18.0 1c2 <- [0x0000001000 - 0x0000003fff] io <node 0 link 2>
PCI: 00:18.0 1b2 <- [0x00fd000000 - 0x00fe3fffff] mem <node 0 link 2>
PCI: 01:01.0 1c <- [0x0000001000 - 0x0000001fff] bus 2 io
PCI: 01:01.0 20 <- [0x00fe100000 - 0x00fe1fffff] bus 2 mem
PCI: 02:08.0 10 <- [0x00fe180000 - 0x00fe19ffff] mem64
PCI: 02:08.0 18 <- [0x00fe100000 - 0x00fe13ffff] mem64
PCI: 02:08.0 20 <- [0x0000001000 - 0x000000103f] io
PCI: 02:08.0 30 <- [0x00fe140000 - 0x00fe17ffff] romem
PCI: 02:09.0 10 <- [0x00fe1a0000 - 0x00fe1affff] mem64
PCI: 02:09.0 18 <- [0x00fe1b0000 - 0x00fe1bffff] mem64
PCI: 02:09.1 10 <- [0x00fe1c0000 - 0x00fe1cffff] mem64
PCI: 02:09.1 18 <- [0x00fe1d0000 - 0x00fe1dffff] mem64
PCI: 01:01.1 10 <- [0x00fe300000 - 0x00fe300fff] mem64
PCI: 01:02.0 20 <- [0x00fe200000 - 0x00fe2fffff] bus 3 mem
PCI: 03:03.0 10 <- [0x00fe200000 - 0x00fe20ffff] mem64
PCI: 01:02.1 10 <- [0x00fe301000 - 0x00fe301fff] mem64
PCI: 01:03.0 1c <- [0x0000002000 - 0x0000002fff] bus 4 io
PCI: 01:03.0 20 <- [0x00fd000000 - 0x00fe0fffff] bus 4 mem
PCI: 04:00.0 10 <- [0x00fe000000 - 0x00fe000fff] mem
PCI: 04:00.1 10 <- [0x00fe001000 - 0x00fe001fff] mem
PCI: 04:05.0 10 <- [0x0000002410 - 0x0000002417] io
PCI: 04:05.0 14 <- [0x0000002430 - 0x0000002433] io
PCI: 04:05.0 18 <- [0x0000002420 - 0x0000002427] io
PCI: 04:05.0 1c <- [0x0000002440 - 0x0000002443] io
PCI: 04:05.0 20 <- [0x0000002400 - 0x000000240f] io
PCI: 04:05.0 24 <- [0x00fe003000 - 0x00fe0033ff] mem
PCI: 04:06.0 10 <- [0x00fd000000 - 0x00fdffffff] mem
PCI: 04:06.0 14 <- [0x0000002000 - 0x00000020ff] io
PCI: 04:06.0 18 <- [0x00fe002000 - 0x00fe002fff] mem
PCI: 04:06.0 30 <- [0x00fff80000 - 0x00fff9ffff] romem
PNP: 002e.0 60 <- [0x00000003f0 - 0x00000003f7] io
PNP: 002e.0 70 <- [0x0000000006 - 0x0000000006] irq
PNP: 002e.0 74 <- [0x0000000002 - 0x0000000002] drq
PNP: 002e.2 60 <- [0x00000003f8 - 0x00000003ff] io
PNP: 002e.2 70 <- [0x0000000004 - 0x0000000004] irq
PNP: 002e.5 60 <- [0x0000000060 - 0x0000000060] io
PNP: 002e.5 62 <- [0x0000000064 - 0x0000000064] io
PNP: 002e.5 70 <- [0x0000000001 - 0x0000000001] irq
PNP: 002e.5 72 <- [0x000000000c - 0x000000000c] irq
PNP: 002e.b 60 <- [0x0000000290 - 0x0000000297] io
PNP: 002e.b 70 <- [0x0000000005 - 0x0000000005] irq
PCI: 01:04.1 20 <- [0x0000003420 - 0x000000342f] io
PCI: 01:04.2 10 <- [0x0000003400 - 0x000000341f] io
PCI: 01:04.3 58 <- [0x0000003000 - 0x00000030ff] io
Done setting resources.
Done allocating resources.
Enabling resources...
PCI: 00:18.0 cmd <- 140
PCI: 01:01.0 bridge ctrl <- 0003
PCI: 01:01.0 cmd <- 147
PCI: 02:08.0 cmd <- 143
PCI: 02:09.0 subsystem <- 10f1/2881
PCI: 02:09.0 cmd <- 142
PCI: 02:09.1 subsystem <- 10f1/2881
PCI: 02:09.1 cmd <- 142
PCI: 01:01.1 subsystem <- 10f1/2881
PCI: 01:01.1 cmd <- 146
PCI: 01:02.0 bridge ctrl <- 0003
PCI: 01:02.0 cmd <- 146
PCI: 03:03.0 cmd <- 142
PCI: 01:02.1 subsystem <- 10f1/2881
PCI: 01:02.1 cmd <- 146
PCI: 01:03.0 bridge ctrl <- 0003
PCI: 01:03.0 cmd <- 147
PCI: 04:00.0 subsystem <- 10f1/2881
PCI: 04:00.0 cmd <- 142
PCI: 04:00.1 subsystem <- 10f1/2881
PCI: 04:00.1 cmd <- 142
PCI: 04:05.0 subsystem <- 10f1/2881
PCI: 04:05.0 cmd <- 143
PCI: 04:06.0 subsystem <- 10f1/2881
PCI: 04:06.0 cmd <- 1c3
PCI: 01:04.0 subsystem <- 10f1/2881
PCI: 01:04.0 cmd <- 14f
w83627hf hwm smbus enabled
PCI: 01:04.1 subsystem <- 10f1/2881
PCI: 01:04.1 cmd <- 141
PCI: 01:04.2 subsystem <- 10f1/2881
PCI: 01:04.2 cmd <- 141
PCI: 01:04.3 subsystem <- 10f1/2881
PCI: 01:04.3 cmd <- 141
PCI: 00:18.1 subsystem <- 10f1/2881
PCI: 00:18.1 cmd <- 140
PCI: 00:18.2 subsystem <- 10f1/2881
PCI: 00:18.2 cmd <- 140
PCI: 00:18.3 cmd <- 140
PCI: 00:19.0 cmd <- 140
PCI: 00:19.1 cmd <- 140
PCI: 00:19.2 cmd <- 140
PCI: 00:19.3 cmd <- 140
done.
Initializing devices...
Root Device init
APIC_CLUSTER: 0 init
Initializing CPU #0
CPU: vendor AMD device f5a
Enabling cache

Setting fixed MTRRs(0-88) type: UC
Setting fixed MTRRs(0-16) Type: WB, RdMEM, WrMEM
Setting fixed MTRRs(24-88) Type: WB, RdMEM, WrMEM
DONE fixed MTRRs
Setting variable MTRR 0, base:    0MB, range: 1024MB, type WB
DONE variable MTRRs
Clear out the extra MTRR's

MTRR check
Fixed MTRRs   : Enabled
Variable MTRRs: Enabled

microcode: equivalent processor rev id  = 0x004a, patch id = 0x00000000
microcode: patch id that want to apply= 0x00000047
microcode: updated to patch id = 0x00000047  success
Setting up local apic... apic_id: 0 done.
Clearing memory 1024K - 524288K: ------- done
CPU #0 Initialized
start_eip=0x00010000
Initializing CPU #1
Waiting for 1 CPUS to stop
CPU: vendor AMD device f5a
Enabling cache

Setting fixed MTRRs(0-88) type: UC
Setting fixed MTRRs(0-16) Type: WB, RdMEM, WrMEM
Setting fixed MTRRs(24-88) Type: WB, RdMEM, WrMEM
DONE fixed MTRRs
Setting variable MTRR 0, base:    0MB, range: 1024MB, type WB
DONE variable MTRRs
Clear out the extra MTRR's

MTRR check
Fixed MTRRs   : Enabled
Variable MTRRs: Enabled

microcode: equivalent processor rev id  = 0x004a, patch id = 0x00000000
microcode: patch id that want to apply= 0x00000047
microcode: updated to patch id = 0x00000047  success
Setting up local apic... apic_id: 1 done.
Clearing memory 524288K - 1048576K: -------- done
CPU #1 Initialized
All AP CPUs stopped
PCI: 00:18.0 init
PCI: 01:01.0 init
PCI: 02:09.0 init
PCI: 02:09.1 init
PCI: 01:02.0 init
PCI: 01:03.0 init
PCI: 04:05.0 init
PCI: 04:06.0 init
PCI: 01:04.0 init
RTC Init
RTC: Checksum invalid zeroing cmos
enabling HPET @0xfed00000
PNP: 002e.0 init
PNP: 002e.2 init
PNP: 002e.5 init
PNP: 002e.b init
PCI: 01:04.1 init
IDE1 IDE0 PCI: 01:04.3 init
set power on after power fail
smbus: PCI: 01:04.3[0]->I2C: 01:2d init
PCI: 00:18.1 init
PCI: 00:18.2 init
PCI: 00:18.3 init
NB: Function 3 Misc Control.. done.
PCI: 00:19.0 init
PCI: 00:19.1 init
PCI: 00:19.2 init
PCI: 00:19.3 init
NB: Function 3 Misc Control.. done.
PCI: 02:08.0 init
PCI: 03:03.0 init
Devices initialized
Writing IRQ routing tables to 0xf0000...done.
Wrote the mp table end at: 00000020 - 000001cc
Moving GDT to 0x500...ok
Wrote linuxbios table at: 00000530 - 00000ddc  checksum 561a

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

    33:stream_init() - rom_stream: 0xfff80000 - 0xfff9ffff
Found ELF candiate at offset 0
Loading Etherboot version: 5.4.1
Dropping non PT_LOAD segment
New segment addr 0x10000 size 0x3e7a0 offset 0x0 filesize 0xb600
(cleaned up) New segment addr 0x10000 size 0x3e7a0 offset 0x0 filesize
0xb600
Loading Segment: addr: 0x000000003ff90000 memsz: 0x0000000000032000
filesz: 0x000000000000b600
Clearing Segment: addr: 0x000000003ff9b600 memsz: 0x0000000000026a00
Loading Segment: addr: 0x0000000000042000 memsz: 0x000000000000c7a0
filesz: 0x0000000000000000
Clearing Segment: addr: 0x0000000000042000 memsz: 0x000000000000c7a0
Jumping to boot code at 0x100b0
CPU 2065 Mhz
Etherboot 5.4.1 (GPL) http://etherboot.org
Drivers: FILO   Images: NBI ELF FreeBSD Multiboot a.out   
Protocols: DHCP TFTP 
Relocating _text from: [000101b0,0004e7a0) to [3fec1a10,3ff00000)
Scanning PCI: found 25 devices
Boot from (N)etwork (D)isk or (Q)uit? 

Probing pci disk...
[FILO]boot eax = 0xc50401ac
boot ebx = 0x00800401
boot arg = 0x00000000
FILO version 0.4.1 (bilse at sd3) Fri Mar 24 18:08:56 GMT 2006
Press <Enter> for default boot, or <Esc> for boot prompt... 5 4 3
2 1 timed out
boot: hda1:/boot/vmlinuz-2.6.9-1.667smp
initrd=/boot/initrd-2.6.9-1.667smp.img pci=noacpi ro root=/dev/hda1
console=ttyS0,19200
found PCI IDE controller 00001022:00007469 prog_if=0x0000008a
primary channel: compatibility mode
cmd_base=0x000001f0 ctrl_base=0x000003f4
Waiting for ide0 to become ready for reset... ok
Testing for hda
Probing for hda
Init device params... ok
hda: LBA: ST320413A                               
Partition 1 start u length u
Mounted ext2fs
Not a bootable ELF image
already open
Found Linux version 2.6.9-1.667smp (bhcompile at tweety.build.redhat.com)
#1 SMP Tue Nov 2 14:59:52 EST 2004 (protocol 0x00000203) (loadflags
0x00000001) bzImage.
Setting up paramters at 0x00090000
ramtop=0x000ffc00k
ext_mem_k=64512, alt_mem_k=1047552
original command line: "initrd=/boot/initrd-2.6.9-1.667smp.img
pci=noacpi ro root=/dev/hda1 console=ttyS0,19200"
kernel command line at 0x00091000
initrd=/boot/initrd-2.6.9-1.667smp.img
kernel command line (48 bytes): "pci=noacpi ro root=/dev/hda1
console=ttyS0,19200"
offset=0x00001600 addr=0x00100000 size=0x0014d2a0
Loading kernel... ok
start=0x3fe4d000 end=0x3fec10e1
Loading initrd... ok
eip=0x00100000
Jumping to entry point...
Linux version 2.6.9-1.667smp (bhcompile at tweety.build.redhat.com) (gcc
version 3.4.2 20041017 (Red Hat 3.4.2-6.fc3)) #1 SMP Tue Nov 2 14:59:52
EST 2004
BIOS-provided physical RAM map:
 BIOS-e820: 0000000000000000 - 0000000000000e44 type 16
 BIOS-e820: 0000000000000e44 - 00000000000a0000 (usable)
 BIOS-e820: 00000000000f0000 - 00000000000f0400 type 16
 BIOS-e820: 0000000000100000 - 0000000040000000 (usable)
0MB HIGHMEM available.
1024MB LOWMEM available.
found SMP MP-table at 00000010
NX (Execute Disable) protection: active
DMI not present.
Using APIC driver default
ACPI: Unable to locate RSDP
Intel MultiProcessor Specification v1.4
    Virtual Wire compatibility mode.
OEM ID: TYAN     Product ID: S2881        APIC at: 0xFEE00000
Processor #0 15:5 APIC version 16
Processor #1 15:5 APIC version 16
I/O APIC #2 Version 17 at 0xFEC00000.
I/O APIC #3 Version 17 at 0xFE300000.
I/O APIC #4 Version 17 at 0xFE301000.
Enabling APIC mode:  Flat.  Using 3 I/O APICs
Processors: 2
Built 1 zonelists
Kernel command line: pci=noacpi ro root=/dev/hda1 console=ttyS0,19200
mapped 4G/4G trampoline to fffec000.
Initializing CPU#0
CPU 0 irqstacks, hard=023ce000 soft=023ae000
PID hash table entries: 4096 (order: 12, 65536 bytes)
Detected 1993.323 MHz processor.
Using tsc for high-res timesource
Console: colour dummy device 80x25
Dentry cache hash table entries: 262144 (order: 8, 1048576 bytes)
Inode-cache hash table entries: 131072 (order: 7, 524288 bytes)
Memory: 1033248k/1048576k available (1772k kernel code, 14740k reserved,
736k data, 184k init, 0k highmem)
Security Scaffold v1.0.0 initialized
SELinux:  Initializing.
SELinux:  Starting in permissive mode
There is already a security framework initialized, register_security
failed.
selinux_register_security:  Registering secondary module capability
Capability LSM initialized as secondary
Mount-cache hash table entries: 512 (order: 0, 4096 bytes)
CPU: L1 I Cache: 64K (64 bytes/line), D cache 64K (64 bytes/line)
CPU: L2 Cache: 1024K (64 bytes/line)
Intel machine check architecture supported.
Intel machine check reporting enabled on CPU#0.
Enabling fast FPU save and restore... done.
Enabling unmasked SIMD FPU exception support... done.
Checking 'hlt' instruction... OK.
CPU0: AMD 02/05 stepping 0a
per-CPU timeslice cutoff: 2925.27 usecs.
task migration cache decay timeout: 3 msecs.
Booting processor 1/1 eip 3000
CPU 1 irqstacks, hard=023cf000 soft=023af000
Initializing CPU#1
CPU: L1 I Cache: 64K (64 bytes/line), D cache 64K (64 bytes/line)
CPU: L2 Cache: 1024K (64 bytes/line)
Intel machine check architecture supported.
Intel machine check reporting enabled on CPU#1.
CPU1: AMD 02/05 stepping 0a
Total of 2 processors activated (7897.08 BogoMIPS).
ENABLING IO-APIC IRQs
..TIMER: vector=0x31 pin1=2 pin2=0
checking TSC synchronization across 2 CPUs: passed.
Brought up 2 CPUs
zapping low mappings.
checking if image is initramfs... it is
Freeing initrd memory: 464k freed
NET: Registered protocol family 16
CPU 0: Machine Check Exception: 0000000000000004
Bank 4: f60320018f080813 at 00000000000e0010
Kernel panic - not syncing: CPU context corrupt
 

## ENDS





From bari at onelabs.com  Fri Mar 24 22:52:27 2006
From: bari at onelabs.com (Bari Ari)
Date: Fri, 24 Mar 2006 15:52:27 -0600
Subject: [LinuxBIOS] [Fwd: Hardware Write-Protect for BIOS & EC]
In-Reply-To: <8a0c36780603231156h11abf901o40786ee3aefbd565@mail.gmail.com>
References: <6F7DA19D05F3CF40B890C7CA2DB13A4203094B0D@ssvlexmb2.amd.com>	<4422DD09.8040005@lanl.gov>
	<8a0c36780603231156h11abf901o40786ee3aefbd565@mail.gmail.com>
Message-ID: <44246A1B.50000@onelabs.com>

Picking a flash device with a boot block that cannot be rewritten just 
via any possible software routine alone and only by being combined with 
hardware intervention will work.

The parts that require a higher programming voltage that Richard 
mentions is one good possible way.

This would also recover a damaged BIOS attacked by even phishers.

If the flash update was somehow corrupted via power interruption, 
infected BIOS update with a good checksum, etc. the boot section would 
still have an good booter.

-Bari

Richard Smith wrote:
>>
>>I think that having a 'you can never write this' bios image would be
>>useful. The power fail scenario is a concern.
>>
> 
> 
> Many flash parts support a hardware lock where you can set a split. 
> Areas that have been hardware locked can only be reprogrammed via the
> right programming voltage which is normally much higher than Vcc.
> 
> --
> Richard A. Smith



From smithbone at gmail.com  Sat Mar 25 10:26:42 2006
From: smithbone at gmail.com (Richard Smith)
Date: Sat, 25 Mar 2006 03:26:42 -0600
Subject: [LinuxBIOS] Patch for advantech som_gx533
Message-ID: <8a0c36780603250126m193ce120wc8a89d767b4483b0@mail.gmail.com>

- The attached diff sets up a config for the Advantech gx533 eval board I have.
- It also adds some verbosity and pass fail logic to the ram test. 
Since the ram test always printed "DRAM verified" regardless of pass
or fail I worked for a long time trying to understand why I died when
I jumped to RAM.  When the real reason was that my RAM is hosed.

So now if the RAM test fails then its _obvious_.

Is 256 failed attempts before aborting really necessary?  I mean > 1
is problem.  Will anyone object to making the abort number much
smaller?

The changes are trivial so unless someone has objections I'll commit.

Ok on to my debugging.  So my RAM isn't playing nice.  From the log
you can see that Bit 8 is not clearing.  Any suggestions on what
register I should go tweak on to tune up my RAM?


LinuxBIOS-1.1.8.0Fallback Sat Mar 25 03:09:37 CST 2006 starting...
reboot from BIOS reset
done cs5535 early
Cpu core is 0000014e
reboot from BIOS reset
done pll_reset
Ram1.00
Ram2.00
Ram3
Ram4
Done sdram_initialize
Disable watchdog
ffCAN NOT READ SUPERIO VID
ff:ff
Testing DRAM : 00000000-00004000
DRAM fill: 00000000-00004000
00000000 00004000
DRAM filled
DRAM verify: 00000000-00004000
00000000 Fail: @0x00000000 Read value=0x00001000
Fail: @0x00000004 Read value=0x00001004
Fail: @0x00000008 Read value=0x00001008
Fail: @0x0000000c Read value=0x0000100c
Fail: @0x00000010 Read value=0x00001010
Fail: @0x00000014 Read value=0x00001014
Fail: @0x00000018 Read value=0x00001018
Fail: @0x0000001c Read value=0x0000101c
Fail: @0x00000020 Read value=0x00001020
<snip>
Fail: @0x000003fc Read value=0x000013fc
Fail: @0x00000400 Read value=0x00001400
Aborting.
00000400
DRAM did _NOT_ verify!
Done.
Testing DRAM : 00020000-00024000
DRAM fill: 00020000-00024000
00020000 00024000
DRAM filled
DRAM verify: 00020000-00024000
00020000 Fail: @0x00020000 Read value=0x00021000
Fail: @0x00020004 Read value=0x00021004
Fail: @0x00020008 Read value=0x00021008
Fail: @0x0002000c Read value=0x0002100c
Fail: @0x00020010 Read value=0x00021010
Fail: @0x00020014 Read value=0x00021014
Fail: @0x00020018 Read value=0x00021018
Fail: @0x0002001c Read value=0x0002101c
<snip>
Fail: @0x000203f0 Read value=0x000213f0
Fail: @0x000203f4 Read value=0x000213f4
Fail: @0x000203f8 Read value=0x000213f8
Fail: @0x000203fc Read value=0x000213fc
Fail: @0x00020400 Read value=0x00021400
Aborting.
00020400
DRAM did _NOT_ verify!
Done.
Testing DRAM : 00000000-000a0000
DRAM fill: 00000000-000a0000
00000000 00010000 00020000 00030000 00040000 00050000 00060000
00070000 00080000 00090000 000a0000
DRAM filled
DRAM verify: 00000000-000a0000
00000000 Fail: @0x00000000 Read value=0x00001000
Fail: @0x00000004 Read value=0x00001004
Fail: @0x00000008 Read value=0x00001008
Fail: @0x0000000c Read value=0x0000100c
Fail: @0x00000010 Read value=0x00001010
Fail: @0x00000014 Read value=0x00001014
Fail: @0x00000018 Read value=0x00001018
Fail: @0x0000001c Read value=0x0000101c
Fail: @0x00000020 Read value=0x00001020
<snip>
Fail: @0x000003f0 Read value=0x000013f0
Fail: @0x000003f4 Read value=0x000013f4
Fail: @0x000003f8 Read value=0x000013f8
Fail: @0x000003fc Read value=0x000013fc
Fail: @0x00000400 Read value=0x00001400
Aborting.
00000400
DRAM did _NOT_ verify!
Done.
Copying LinuxBIOS to ram.
Jumping to LinuxBIOS.


--
Richard A. Smith
-------------- next part --------------
Index: src/ram/ramtest.c
===================================================================
--- src/ram/ramtest.c	(revision 2227)
+++ src/ram/ramtest.c	(working copy)
@@ -69,17 +69,26 @@
 		value = read_phys(addr);
 		if (value != addr) {
 			/* Display address with error */
+			print_err("Fail: @0x");
 			print_err_hex32(addr);
-			print_err_char(':');
+			print_err(" Read value=0x");
 			print_err_hex32(value);
 			print_err("\r\n");
 			i++;
-			if(i>256) break;
+			if(i>256) {
+				print_debug("Aborting.\n\r");
+				break;
+			}
 		}
 	}
 	/* Display final address */
 	print_debug_hex32(addr);
-	print_debug("\r\nDRAM verified\r\n");
+	if (i) {
+		print_debug("\r\nDRAM did _NOT_ verify!\r\n");
+	}
+	else {
+		print_debug("\r\nDRAM range verified.\r\n");
+	}
 }
 
 
Index: src/mainboard/advantech/som_gx533c/Config.lb
===================================================================
--- src/mainboard/advantech/som_gx533c/Config.lb	(revision 0)
+++ src/mainboard/advantech/som_gx533c/Config.lb	(revision 0)
@@ -0,0 +1,143 @@
+##
+## Compute the location and size of where this firmware image
+## (linuxBIOS 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 linuxBIOS bootloader.
+##
+default CONFIG_ROM_STREAM_START = (0xffffffff - ROM_SIZE + ROM_SECTION_OFFSET + 1)
+default PAYLOAD_SIZE            = ( ROM_SECTION_SIZE - ROM_IMAGE_SIZE )
+
+##
+## Compute where this copy of linuxBIOS will start in the boot rom
+##
+default _ROMBASE      = ( CONFIG_ROM_STREAM_START + PAYLOAD_SIZE )
+
+##
+## Compute a range of ROM that can cached to speed up linuxBIOS,
+## 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
+
+##
+## Romcc output
+##
+makerule ./failover.E
+	depends "$(MAINBOARD)/failover.c ./romcc" 
+	action "./romcc -E -O --label-prefix=failover -I$(TOP)/src -I. $(CPPFLAGS) $(MAINBOARD)/failover.c -o $@"
+end
+
+makerule ./failover.inc
+	depends "$(MAINBOARD)/failover.c ./romcc"
+	action "./romcc    -O --label-prefix=failover -I$(TOP)/src -I. $(CPPFLAGS) $(MAINBOARD)/failover.c -o $@"
+end
+
+makerule ./auto.E 
+	depends	"$(MAINBOARD)/auto.c option_table.h ./romcc" 
+	action	"./romcc -E -mcpu=i386 -O -I$(TOP)/src -I. $(CPPFLAGS) $(MAINBOARD)/auto.c -o $@"
+end
+makerule ./auto.inc 
+	depends "$(MAINBOARD)/auto.c option_table.h ./romcc"
+	action	"./romcc    -mcpu=i386 -O -I$(TOP)/src -I. $(CPPFLAGS) $(MAINBOARD)/auto.c -o $@"
+end
+
+##
+## Build our 16 bit and 32 bit linuxBIOS 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 linuxBIOS 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 linuxBIOS 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 ./auto.inc
+
+##
+## Include the secondary Configuration files 
+##
+dir /pc80
+config chip.h
+
+chip northbridge/amd/gx2
+  device pci_domain 0 on 
+    device pci 0.0 on end
+      chip southbridge/amd/cs5535
+        device pci 12.0 on
+        device pci 12.1 off end		# SMI
+        device pci 12.2 on  end		# IDE
+        device pci 12.3 off end 	# Audio
+        device pci 12.4 off end		# VGA
+      end
+    end
+  end
+
+  chip cpu/amd/model_gx2
+  end
+
+end
+
Index: src/mainboard/advantech/som_gx533c/reset.c
===================================================================
--- src/mainboard/advantech/som_gx533c/reset.c	(revision 0)
+++ src/mainboard/advantech/som_gx533c/reset.c	(revision 0)
@@ -0,0 +1,43 @@
+#if 0
+//#include "arch/romcc_io.h"
+#include <arch/io.h>
+
+typedef unsigned device_t;
+
+#define PCI_DEV(BUS, DEV, FN) ( \
+	(((BUS) & 0xFF) << 16) | \
+	(((DEV) & 0x1f) << 11) | \
+	(((FN)  & 0x7) << 8))
+
+static void pci_write_config8(device_t dev, unsigned where, unsigned char value)
+{
+        unsigned addr;
+        addr = dev | where;
+        outl(0x80000000 | (addr & ~3), 0xCF8);
+        outb(value, 0xCFC + (addr & 3));
+}
+
+static void pci_write_config32(device_t dev, unsigned where, unsigned value)
+{
+	unsigned addr;
+        addr = dev | where;
+        outl(0x80000000 | (addr & ~3), 0xCF8);
+        outl(value, 0xCFC);
+}
+
+static unsigned pci_read_config32(device_t dev, unsigned where)
+{
+	unsigned addr;
+        addr = dev | where;
+        outl(0x80000000 | (addr & ~3), 0xCF8);
+        return inl(0xCFC);
+}
+
+#include "../../../northbridge/amd/amdk8/reset_test.c"
+
+void hard_reset(void)
+{
+	set_bios_reset();
+	pci_write_config8(PCI_DEV(1, 0x04, 0), 0x47, 1);
+}
+#endif
Index: src/mainboard/advantech/som_gx533c/irq_tables.c
===================================================================
--- src/mainboard/advantech/som_gx533c/irq_tables.c	(revision 0)
+++ src/mainboard/advantech/som_gx533c/irq_tables.c	(revision 0)
@@ -0,0 +1,31 @@
+/* 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>
+
+const struct irq_routing_table intel_irq_routing_table = {
+	PIRQ_SIGNATURE,  /* u32 signature */
+	PIRQ_VERSION,    /* u16 version   */
+	32+16*2,	 /* 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) */
+	0x800,		 /* IRQs devoted exclusively to PCI usage */
+	0x1078,		 /* Vendor */
+	0x2,		 /* Device */
+	0,		 /* 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 */
+		{0x00,(0x0e<<3)|0x0, {{0x02, 0xdeb8}, {0x03, 0xdeb8}, {0x04, 0xdeb8}, {0x01, 0x0deb8}}, 0x1, 0x0},
+		{0x00,(0x0f<<3)|0x0, {{0x03, 0xdeb8}, {0x04, 0xdeb8}, {0x01, 0xdeb8}, {0x02, 0x0deb8}}, 0x2, 0x0},
+	}
+};
+unsigned long write_pirq_routing_table(unsigned long addr)
+{
+        return copy_pirq_routing_table(addr);
+}
Index: src/mainboard/advantech/som_gx533c/Options.lb
===================================================================
--- src/mainboard/advantech/som_gx533c/Options.lb	(revision 0)
+++ src/mainboard/advantech/som_gx533c/Options.lb	(revision 0)
@@ -0,0 +1,160 @@
+uses HAVE_MP_TABLE
+uses HAVE_PIRQ_TABLE
+uses USE_FALLBACK_IMAGE
+uses HAVE_FALLBACK_BOOT
+uses HAVE_HARD_RESET
+uses HAVE_OPTION_TABLE
+uses USE_OPTION_TABLE
+uses CONFIG_ROM_STREAM
+uses IRQ_SLOT_COUNT
+uses MAINBOARD
+uses MAINBOARD_VENDOR
+uses MAINBOARD_PART_NUMBER
+uses LINUXBIOS_EXTRA_VERSION
+uses ARCH
+uses FALLBACK_SIZE
+uses STACK_SIZE
+uses HEAP_SIZE
+uses ROM_SIZE
+uses ROM_SECTION_SIZE
+uses ROM_IMAGE_SIZE
+uses ROM_SECTION_SIZE
+uses ROM_SECTION_OFFSET
+uses CONFIG_ROM_STREAM_START
+uses PAYLOAD_SIZE
+uses _ROMBASE
+uses _RAMBASE
+uses XIP_ROM_SIZE
+uses XIP_ROM_BASE
+uses HAVE_MP_TABLE
+uses CROSS_COMPILE
+uses CC
+uses HOSTCC
+uses OBJCOPY
+uses DEFAULT_CONSOLE_LOGLEVEL
+uses MAXIMUM_CONSOLE_LOGLEVEL
+uses CONFIG_CONSOLE_SERIAL8250
+uses TTYS0_BAUD
+uses TTYS0_BASE
+uses TTYS0_LCS
+uses CONFIG_UDELAY_TSC
+uses CONFIG_TSC_X86RDTSC_CALIBRATE_WITH_TIMER2
+
+## ROM_SIZE is the size of boot ROM that this board will use.
+default ROM_SIZE  = 256*1024
+
+###
+### Build options
+###
+
+##
+## Build code for the fallback boot
+##
+default HAVE_FALLBACK_BOOT=1
+
+##
+## no MP table
+##
+default HAVE_MP_TABLE=0
+
+##
+## Build code to reset the motherboard from linuxBIOS
+##
+default HAVE_HARD_RESET=0
+
+## 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=2
+#object irq_tables.o
+
+##
+## Build code to export a CMOS option table
+##
+default HAVE_OPTION_TABLE=0
+
+###
+### LinuxBIOS layout values
+###
+
+## ROM_IMAGE_SIZE is the amount of space to allow linuxBIOS to occupy.
+default ROM_IMAGE_SIZE = 65536
+default FALLBACK_SIZE = 131072
+
+##
+## Use a small 8K stack
+##
+default STACK_SIZE=0x2000
+
+##
+## Use a small 16K heap
+##
+default HEAP_SIZE=0x4000
+
+##
+## Only use the option table in a normal image
+##
+#default USE_OPTION_TABLE = !USE_FALLBACK_IMAGE
+default USE_OPTION_TABLE = 0
+
+default _RAMBASE = 0x00004000
+
+default CONFIG_ROM_STREAM     = 1
+
+##
+## The default compiler
+##
+default CROSS_COMPILE=""
+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
+#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 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=8
+## At a maximum only compile in this level of debugging
+default  MAXIMUM_CONSOLE_LOGLEVEL=8
+
+end
+
Index: src/mainboard/advantech/som_gx533c/debug.c
===================================================================
--- src/mainboard/advantech/som_gx533c/debug.c	(revision 0)
+++ src/mainboard/advantech/som_gx533c/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/mainboard/advantech/som_gx533c/failover.c
===================================================================
--- src/mainboard/advantech/som_gx533c/failover.c	(revision 0)
+++ src/mainboard/advantech/som_gx533c/failover.c	(revision 0)
@@ -0,0 +1,32 @@
+#define ASSEMBLY 1
+#include <stdint.h>
+#include <device/pci_def.h>
+#include <device/pci_ids.h>
+#include <arch/io.h>
+#include "arch/romcc_io.h"
+#include "pc80/mc146818rtc_early.c"
+
+static unsigned long main(unsigned long bist)
+{
+	/* This is the primary cpu how should I boot? */
+	if (do_normal_boot()) {
+		goto normal_image;
+	}
+	else {
+		goto fallback_image;
+	}
+ normal_image:
+	asm volatile ("jmp __normal_image" 
+		: /* outputs */ 
+		: "a" (bist) /* inputs */
+		: /* clobbers */
+		);
+ cpu_reset:
+	asm volatile ("jmp __cpu_reset"
+		: /* outputs */ 
+		: "a"(bist) /* inputs */
+		: /* clobbers */
+		);
+ fallback_image:
+	return bist;
+}
Index: src/mainboard/advantech/som_gx533c/auto.c
===================================================================
--- src/mainboard/advantech/som_gx533c/auto.c	(revision 0)
+++ src/mainboard/advantech/som_gx533c/auto.c	(revision 0)
@@ -0,0 +1,134 @@
+#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 "arch/i386/lib/console.c"
+#include "ram/ramtest.c"
+#include "superio/NSC/pc87360/pc87360_early_serial.c"
+#include "cpu/x86/bist.h"
+#include "cpu/x86/msr.h"
+#include <cpu/amd/gx2def.h>
+
+#define SERIAL_DEV PNP_DEV(0x2e,  PC87360_SP1)
+
+#include "southbridge/amd/cs5535/cs5535_early_smbus.c"
+#include "southbridge/amd/cs5535/cs5535_early_setup.c"
+#include "northbridge/amd/gx2/raminit.h"
+
+/* this has to be done on a per-mainboard basis, esp. if you don't have smbus */
+static void sdram_set_spd_registers(const struct mem_controller *ctrl) 
+{
+	msr_t msr;
+	/* 1. Initialize GLMC registers base on SPD values,
+	 * Hard coded as XpressROM for now */
+	//print_debug("sdram_enable step 1\r\n");
+	msr = rdmsr(0x20000018);
+	msr.hi = 0x10076013;
+	msr.lo = 0x3400;
+	wrmsr(0x20000018, msr);
+
+	msr = rdmsr(0x20000019);
+	msr.hi = 0x18000008;
+	msr.lo = 0x696332a3;
+	wrmsr(0x20000019, msr);
+
+}
+
+#include "northbridge/amd/gx2/raminit.c"
+#include "sdram/generic_sdram.c"
+
+#define PLLMSRhi 0x00000226
+#define PLLMSRlo 0x00000008
+#define PLLMSRlo1 ((0xde << 16) | (1 << 26) | (1 << 24))
+#define PLLMSRlo2 ((1<<14) |(1<<13) | (1<<0))
+#include "northbridge/amd/gx2/pll_reset.c"
+
+
+static void msr_init(void)
+{
+	__builtin_wrmsr(0x1808,  0x10f3bf00, 0x22fffc02);
+
+	__builtin_wrmsr(0x10000020, 0xfff80, 0x20000000);
+        __builtin_wrmsr(0x10000021, 0x80fffe0, 0x20000000);
+        __builtin_wrmsr(0x10000026, 0x400fffc0, 0x2cfbc040);
+        __builtin_wrmsr(0x10000027, 0xfff00000, 0xff);
+        __builtin_wrmsr(0x10000028, 0x7bf00100, 0x2000000f);
+        __builtin_wrmsr(0x1000002c, 0xff030003, 0x20000000);
+
+        __builtin_wrmsr(0x10000080, 0x3, 0x0);
+
+        __builtin_wrmsr(0x40000020, 0xfff80, 0x20000000);
+        __builtin_wrmsr(0x40000021, 0x80fffe0, 0x20000000);
+	__builtin_wrmsr(0x40000023, 0x400fffc0, 0x20000040);
+        __builtin_wrmsr(0x40000024, 0xff4ffffc, 0x200000ef);
+        __builtin_wrmsr(0x40000029, 0x7bf00100, 0x2000000f);
+        __builtin_wrmsr(0x4000002d, 0xff030003, 0x20000000);
+
+
+        __builtin_wrmsr(0x50002001, 0x27, 0x0);
+        __builtin_wrmsr(0x4c002001, 0x1, 0x0);
+}
+
+
+static void main(unsigned long bist)
+{
+	static const struct mem_controller memctrl [] = {
+		{.channel0 = {(0xa<<3)|0, (0xa<<3)|1}}
+	};
+	unsigned char temp;
+
+	msr_init();
+
+	pc87360_enable_serial(SERIAL_DEV, TTYS0_BASE);
+	uart_init();
+	console_init();
+
+	cs5535_early_setup();
+	print_err("done cs5535 early\n");
+	pll_reset();
+	print_err("done pll_reset\n");
+	/* Halt if there was a built in self test failure */
+	//report_bist_failure(bist);
+	
+	sdram_initialize(1, memctrl);
+
+	print_err("Done sdram_initialize\n");
+	print_err("Disable watchdog\n");
+	outb( 0x87, 0x4E);                            //enter SuperIO configuration mode
+	outb( 0x87, 0x4E);
+
+
+   	outb(0x20, 0x4e);
+	temp = inb(0x4f);
+	print_debug_hex8(temp);
+	if (temp != 0x52){
+		print_err("CAN NOT READ SUPERIO VID\n");
+	}
+
+	outb(0x29, 0x4e);
+	outb(0x7c, 0x4f);
+
+	outb( 0x07, 0x4E);                            //enable logical device 9
+	outb( 0x09, 0x4F);
+	outb(0x30, 0x4e);
+	outb(1, 0x4f);
+	outb( 0xF0, 0x4E);                            //set GP33 as outbut in configuration register F0h     Bit4 = \u20180\u2019
+	outb( 0xC7, 0x4F);
+	outb( 0xF1, 0x4E);                            //clr GP33 (Bit4) value in cofiguration register F1h to \u20181\u2019 disables
+	temp = inb(0x4F);                            //watchdog function. Make sure to let the other Bits unchanged!
+	print_debug_hex8(temp);print_debug(":");
+	temp = temp & ~8;
+	outb( temp, 0x4F);
+	temp = inb(0x4F);                            //watchdog function. Make sure to let the other Bits unchanged!
+	print_debug_hex8(temp);print_debug("\n");
+	/* Check all of memory */
+	ram_check(0, 16384);
+	ram_check(0x20000, 0x24000);
+	ram_check(0x00000000, 640*1024);
+
+}
Index: src/mainboard/advantech/som_gx533c/chip.h
===================================================================
--- src/mainboard/advantech/som_gx533c/chip.h	(revision 0)
+++ src/mainboard/advantech/som_gx533c/chip.h	(revision 0)
@@ -0,0 +1,5 @@
+extern struct chip_operations mainboard_advantech_som_gx533c_ops;
+
+struct mainboard_advantech_som_gx533c_config {
+	int nothing;
+};
Index: src/mainboard/advantech/som_gx533c/cmos.layout
===================================================================
--- src/mainboard/advantech/som_gx533c/cmos.layout	(revision 0)
+++ src/mainboard/advantech/som_gx533c/cmos.layout	(revision 0)
@@ -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
+
+
Index: src/mainboard/advantech/som_gx533c/mainboard.c
===================================================================
--- src/mainboard/advantech/som_gx533c/mainboard.c	(revision 0)
+++ src/mainboard/advantech/som_gx533c/mainboard.c	(revision 0)
@@ -0,0 +1,12 @@
+#include <console/console.h>
+#include <device/device.h>
+#include <device/pci.h>
+#include <device/pci_ids.h>
+#include <device/pci_ops.h>
+#include <arch/io.h>
+#include "chip.h"
+
+struct chip_operations mainboard_advantech_som_gx533c_ops = {
+	CHIP_NAME("Advantech SOM GX DB533-C mainboard ")
+};
+
Index: targets/advantech/som_gx533c/Config.lb
===================================================================
--- targets/advantech/som_gx533c/Config.lb	(revision 0)
+++ targets/advantech/som_gx533c/Config.lb	(revision 0)
@@ -0,0 +1,37 @@
+# Config file for the Advantech eval kit with a SOM-DB2301 baseboard 
+# and a SOM 2354 Cpu module. (gx533)
+# This will make a target directory of som_gx533c
+
+target som_gx533c
+mainboard advantech/som_gx533c
+
+option ROM_SIZE=1024*512
+
+option MAXIMUM_CONSOLE_LOGLEVEL=9
+option DEFAULT_CONSOLE_LOGLEVEL=9
+
+romimage "normal"
+	option USE_FALLBACK_IMAGE=0
+	option ROM_IMAGE_SIZE=0x10000
+	option LINUXBIOS_EXTRA_VERSION=".0Normal"
+#	payload /usr/share/etherboot/5.1.9pre2-lnxi-lb/tg3--ide_disk.zelf
+#	payload ../../../../tg3--ide_disk.zelf	
+#	payload ../../../../../lnxieepro100.ebi
+	payload /etc/hosts
+#	payload /home/hamish/work/etherboot/eb-5.2.6-lne100.elf
+#	payload /tmp/filo.elf
+end
+
+romimage "fallback" 
+	option USE_FALLBACK_IMAGE=1
+	option ROM_IMAGE_SIZE=0x10000
+	option LINUXBIOS_EXTRA_VERSION=".0Fallback"
+#	payload /usr/share/etherboot/5.1.9pre2-lnxi-lb/tg3--ide_disk.zelf
+#	payload ../../../../tg3--ide_disk.zelf	
+#	payload ../../../../../lnxieepro100.ebia
+	payload /etc/hosts
+#	payload /home/hamish/work/etherboot/eb-5.2.6-lne100.elf
+#	payload /tmp/filo.elf
+end
+
+buildrom ./linuxbios.rom ROM_SIZE "normal" "fallback"



From ollie at lanl.gov  Mon Mar 27 17:54:33 2006
From: ollie at lanl.gov (Li-Ta Lo)
Date: Mon, 27 Mar 2006 08:54:33 -0700
Subject: [LinuxBIOS] Patch for advantech som_gx533
In-Reply-To: <8a0c36780603250126m193ce120wc8a89d767b4483b0@mail.gmail.com>
References: <8a0c36780603250126m193ce120wc8a89d767b4483b0@mail.gmail.com>
Message-ID: <1143474873.6105.5.camel@logarithm.lanl.gov>

On Sat, 2006-03-25 at 03:26 -0600, Richard Smith wrote:
> - The attached diff sets up a config for the Advantech gx533 eval board I have.
> - It also adds some verbosity and pass fail logic to the ram test. 
> Since the ram test always printed "DRAM verified" regardless of pass
> or fail I worked for a long time trying to understand why I died when
> I jumped to RAM.  When the real reason was that my RAM is hosed.
> 

Are you sure the value to set to msr 0x20000018 and 0x20000019 are
correct? The value is for the rumba board with 256MB DDR.

-- 
Li-Ta Lo <ollie at lanl.gov>
Los Alamos National Lab




From bari at onelabs.com  Mon Mar 27 18:26:20 2006
From: bari at onelabs.com (Bari Ari)
Date: Mon, 27 Mar 2006 10:26:20 -0600
Subject: [LinuxBIOS] Geode Utilities and Tools
Message-ID: <4428122C.2010704@onelabs.com>

Just FYI on the Geodes in case anyone missed them...

The AMD Geode dev site has a few handy utilities and tools for debugging 
BIOS and driver settings.

Cyreg -  Cyreg is a menu driven utility that displays memory, I/O and 
PCI configuration space data. The menus are defined in a text file that 
allows the user to easily modify each menu.

Loadreg - Loadreg is a command line utility that allows the user to read 
or modify any I/O, memory, or PCI configuration space location. It is 
ideally suited to modifying system registers via a batch file.

MCVAL - Mcval tests the state of the memory controller against known 
values, as well as lists all supported processor speeds and their 
associated memory controller register values.

-Bari



From v.r at vif.com  Tue Mar 28 08:35:04 2006
From: v.r at vif.com (v.r at vif.com)
Date: Tue, 28 Mar 2006 01:35:04 -0500
Subject: [LinuxBIOS] nforce2 geforce4
Message-ID: <20060328013504.bkgmi6zvwgw4s0wo@email.vif.com>

ami 4mb flash
asus a7n8x-vm 400mhz
nforce2 geforce4 agp
sempron 2500+ 333mhz
pc3200 512m kingston

I want to flash the board
Anyone interested to help?

Thanks




From pdegler at rumms.uni-mannheim.de  Tue Mar 28 16:24:49 2006
From: pdegler at rumms.uni-mannheim.de (Philipp Degler)
Date: Tue, 28 Mar 2006 16:24:49 +0200
Subject: [LinuxBIOS] Kernel will not boot
Message-ID: <200603281624.49589.pdegler@rumms.uni-mannheim.de>

Hi,

I tried various payloads to boot the system. Filo could not find my hda saying 
floating bus. Etherboot loads OK and gets a kernel elf image via tftp but 
kernel is not loading. Do you have an idea what could be the problem? Maybe 
some PCI-Devices not initialized correctly?

VGA-Support is turned off, no pci cards in the slots, 2GB RAM, Using 2.6 
static kernel with vga and fb options turned completely off. LinuxBIOS was 
compiled with gcc (GCC) 3.3.3 (SuSE Linux) and binutils-2.15.90.0.1.1-30
(binutils-32bit-9.1-200404070910)

I appended the trace of LinuxBIOS with loglevel 9.

thx
phil
---------

LinuxBIOS-1.1.8_Fallback Mon Mar 27 15:51:01 CEST 2006 starting...
i386 console_init
report_bist_failure
setup_default_resource_map
setting up resource map....
0000c144 <-00000000
0000c14c <-00000001
0000c154 <-00000002
0000c15c <-00000003
0000c164 <-00000004
0000c16c <-00000005
0000c174 <-00000006
0000c17c <-00000007
0000c140 <-00000000
0000c148 <-00000000
0000c150 <-00000000
0000c158 <-00000000
0000c160 <-00000000
0000c168 <-00000000
0000c170 <-00000000
0000c178 <-00000000
0000c184 <-00000000
0000c18c <-00000000
0000c194 <-00000000
0000c19c <-00000000
0000c1a4 <-00000000
0000c1ac <-00000000
0000c1b4 <-00000000
0000c180 <-00000000
0000c188 <-00000000
0000c190 <-00000000
0000c198 <-00000000
0000c1a0 <-00000000
0000c1a8 <-00000000
0000c1b0 <-00000000
0000c1cc <-00000000
0000c1d4 <-00000000
0000c1dc <-00000000
0000c1c8 <-00000000
0000c1d0 <-00000000
0000c1d8 <-00000000
0000c1e4 <-00000000
0000c1e8 <-00000000
0000c1ec <-00000000
done.
setup_coherent_ht_domain
Enabling routing table for node 00 done.
Enabling SMP settings
(0,1) link=01
(1,0) link=01
setup_remote_node: done
Renaming current temporary node to 01 done.
Enabling routing table for node 01 done.
02 nodes initialized.
coherent_ht_finalize
done
needs_reset
ht reset -
enable_smbus
SMBus controller enabled
memreset_setup
sdram_initialize
Ram1.00
setting up CPU00 northbridge registers
done.
Ram1.01
setting up CPU01 northbridge registers
done.
Ram2.00
Enabling dual channel memory
200Mhz
Interleaved
RAM: 0x00100000 KB
Ram2.01
Enabling dual channel memory
200Mhz
Interleaved
RAM: 0x00200000 KB
Ram3
ECC enabled
ECC enabled
Initializing memory:  done
Initializing memory:  done
Clearing initial memory region:  done
Ram4
Copying LinuxBIOS to ram.
Jumping to LinuxBIOS.
test
LinuxBIOS-1.1.8_Fallback Mon Mar 27 15:51:01 CEST 2006 booting...
Enumerating buses...
scan_static_bus for Root Device
PCI_DOMAIN: 0000 enabled
APIC_CLUSTER: 0 enabled
PCI_DOMAIN: 0000 scanning...
PCI: pci_scan_bus for bus 0
PCI: 00:18.0 [1022/1100] bus ops
PCI: 00:18.0 [1022/1100] enabled
PCI: 00:18.1 [1022/1101] enabled
PCI: 00:18.2 [1022/1102] enabled
PCI: 00:18.3 [1022/1103] ops
PCI: 00:18.3 [1022/1103] enabled
PCI: devfn 0xc4, bad id 0xffffffff
PCI: devfn 0xc5, bad id 0xffffffff
PCI: devfn 0xc6, bad id 0xffffffff
PCI: devfn 0xc7, bad id 0xffffffff
PCI: 00:19.0 [1022/1100] bus ops
PCI: 00:19.0 [1022/1100] enabled
PCI: 00:19.1 [1022/1101] enabled
PCI: 00:19.2 [1022/1102] enabled
PCI: 00:19.3 [1022/1103] ops
PCI: 00:19.3 [1022/1103] enabled
PCI: devfn 0xcc, bad id 0xffffffff
PCI: devfn 0xcd, bad id 0xffffffff
PCI: devfn 0xce, bad id 0xffffffff
PCI: devfn 0xcf, bad id 0xffffffff
PCI: devfn 0xd0, bad id 0xffffffff
PCI: devfn 0xd8, bad id 0xffffffff
PCI: devfn 0xe0, bad id 0xffffffff
PCI: devfn 0xe8, bad id 0xffffffff
PCI: devfn 0xf0, bad id 0xffffffff
PCI: devfn 0xf8, bad id 0xffffffff
malloc Enter, size 668, free_mem_ptr 00040000
malloc 0x00040000
PCI: 01:00.0 [1022/7450] bus ops
PCI: 01:00.0 [1022/7450] enabled
Capability: 0x08 @ 0xa0
Capability: 0x08 @ 0xb8
flags: 0x8000
Capability: 0x08 @ 0xa0
Capability: 0x08 @ 0xb8
Capability: 0x08 @ 0xc0
flags: 0x0040
PCI: 01:01.0 count: 0002 static_count: 0001
PCI: 01:01.0 [1022/7450] enabled next_unitid: 0003
malloc Enter, size 668, free_mem_ptr 0004029c
malloc 0x0004029c
PCI: 01:00.0 [1022/7460] bus ops
PCI: 01:00.0 [1022/7460] enabled
Capability: 0x08 @ 0xc0
flags: 0x0080
PCI: 01:03.0 count: 0004 static_count: 0001
PCI: 01:03.0 [1022/7460] enabled next_unitid: 0007
PCI: pci_scan_bus for bus 1
PCI: devfn 0x0, bad id 0xffffffff
PCI: 01:01.0 [1022/7450] enabled
malloc Enter, size 668, free_mem_ptr 00040538
malloc 0x00040538
PCI: 01:01.1 [1022/7451] ops
PCI: 01:01.1 [1022/7451] enabled
PCI: devfn 0xa, bad id 0xffffffff
PCI: devfn 0xb, bad id 0xffffffff
PCI: devfn 0xc, bad id 0xffffffff
PCI: devfn 0xd, bad id 0xffffffff
PCI: devfn 0xe, bad id 0xffffffff
PCI: devfn 0xf, bad id 0xffffffff
malloc Enter, size 668, free_mem_ptr 000407d4
malloc 0x000407d4
PCI: 01:02.0 [1022/7450] bus ops
PCI: 01:02.0 [1022/7450] enabled
malloc Enter, size 668, free_mem_ptr 00040a70
malloc 0x00040a70
PCI: 01:02.1 [1022/7451] ops
PCI: 01:02.1 [1022/7451] enabled
PCI: devfn 0x12, bad id 0xffffffff
PCI: devfn 0x13, bad id 0xffffffff
PCI: devfn 0x14, bad id 0xffffffff
PCI: devfn 0x15, bad id 0xffffffff
PCI: devfn 0x16, bad id 0xffffffff
PCI: devfn 0x17, bad id 0xffffffff
PCI: 01:03.0 [1022/7460] enabled
malloc Enter, size 668, free_mem_ptr 00040d0c
malloc 0x00040d0c
PCI: 01:04.0 [1022/7468] bus ops
PCI: 01:04.0 [1022/7468] enabled
malloc Enter, size 668, free_mem_ptr 00040fa8
malloc 0x00040fa8
PCI: 01:04.1 [1022/7469] ops
PCI: 01:04.1 [1022/7469] enabled
malloc Enter, size 668, free_mem_ptr 00041244
malloc 0x00041244
PCI: 01:04.2 [1022/746a] bus ops
PCI: 01:04.2 [1022/746a] enabled
malloc Enter, size 668, free_mem_ptr 000414e0
malloc 0x000414e0
PCI: 01:04.3 [1022/746b] bus ops
PCI: 01:04.3 [1022/746b] enabled
PCI: devfn 0x24, bad id 0x0
malloc Enter, size 668, free_mem_ptr 0004177c
malloc 0x0004177c
PCI: 01:04.5 [1022/746d] ops
PCI: 01:04.5 [1022/746d] enabled
malloc Enter, size 668, free_mem_ptr 00041a18
malloc 0x00041a18
PCI: 01:04.6 [1022/746e] ops
PCI: 01:04.6 [1022/746e] enabled
PCI: devfn 0x27, bad id 0x0
PCI: devfn 0x28, bad id 0xffffffff
PCI: devfn 0x30, bad id 0xffffffff
PCI: devfn 0x38, bad id 0xffffffff
do_pci_scan_bridge for PCI: 01:01.0
PCI: pci_scan_bus for bus 2
PCI: devfn 0x0, bad id 0xffffffff
PCI: devfn 0x8, bad id 0xffffffff
PCI: devfn 0x10, bad id 0xffffffff
malloc Enter, size 668, free_mem_ptr 00041cb4
malloc 0x00041cb4
PCI: 02:03.0 [8086/1076] enabled
malloc Enter, size 668, free_mem_ptr 00041f50
malloc 0x00041f50
PCI: 02:04.0 [8086/1076] enabled
malloc Enter, size 668, free_mem_ptr 000421ec
malloc 0x000421ec
PCI: 02:05.0 [1095/3114] enabled
PCI: devfn 0x30, bad id 0xffffffff
PCI: devfn 0x38, bad id 0xffffffff
PCI: devfn 0x40, bad id 0xffffffff
PCI: devfn 0x48, bad id 0xffffffff
PCI: devfn 0x50, bad id 0xffffffff
PCI: devfn 0x58, bad id 0xffffffff
PCI: devfn 0x60, bad id 0xffffffff
PCI: devfn 0x68, bad id 0xffffffff
PCI: devfn 0x70, bad id 0xffffffff
PCI: devfn 0x78, bad id 0xffffffff
PCI: devfn 0x80, bad id 0xffffffff
PCI: devfn 0x88, bad id 0xffffffff
PCI: devfn 0x90, bad id 0xffffffff
PCI: devfn 0x98, bad id 0xffffffff
PCI: devfn 0xa0, bad id 0xffffffff
PCI: devfn 0xa8, bad id 0xffffffff
PCI: devfn 0xb0, bad id 0xffffffff
PCI: devfn 0xb8, bad id 0xffffffff
PCI: devfn 0xc0, bad id 0xffffffff
PCI: devfn 0xc8, bad id 0xffffffff
PCI: devfn 0xd0, bad id 0xffffffff
PCI: devfn 0xd8, bad id 0xffffffff
PCI: devfn 0xe0, bad id 0xffffffff
PCI: devfn 0xe8, bad id 0xffffffff
PCI: devfn 0xf0, bad id 0xffffffff
PCI: devfn 0xf8, bad id 0xffffffff
PCI: pci_scan_bus returning with max=02
Capability: 0x07 @ 0xa0
PCI: 02: Conventional PCI
do_pci_scan_bridge returns max 2
do_pci_scan_bridge for PCI: 01:02.0
PCI: pci_scan_bus for bus 3
PCI: devfn 0x0, bad id 0xffffffff
PCI: devfn 0x8, bad id 0xffffffff
PCI: devfn 0x10, bad id 0xffffffff
PCI: devfn 0x18, bad id 0xffffffff
PCI: devfn 0x20, bad id 0xffffffff
PCI: devfn 0x28, bad id 0xffffffff
PCI: devfn 0x30, bad id 0xffffffff
PCI: devfn 0x38, bad id 0xffffffff
PCI: devfn 0x40, bad id 0xffffffff
PCI: devfn 0x48, bad id 0xffffffff
PCI: devfn 0x50, bad id 0xffffffff
PCI: devfn 0x58, bad id 0xffffffff
PCI: devfn 0x60, bad id 0xffffffff
PCI: devfn 0x68, bad id 0xffffffff
PCI: devfn 0x70, bad id 0xffffffff
PCI: devfn 0x78, bad id 0xffffffff
PCI: devfn 0x80, bad id 0xffffffff
PCI: devfn 0x88, bad id 0xffffffff
PCI: devfn 0x90, bad id 0xffffffff
PCI: devfn 0x98, bad id 0xffffffff
PCI: devfn 0xa0, bad id 0xffffffff
PCI: devfn 0xa8, bad id 0xffffffff
PCI: devfn 0xb0, bad id 0xffffffff
PCI: devfn 0xb8, bad id 0xffffffff
PCI: devfn 0xc0, bad id 0xffffffff
PCI: devfn 0xc8, bad id 0xffffffff
PCI: devfn 0xd0, bad id 0xffffffff
PCI: devfn 0xd8, bad id 0xffffffff
PCI: devfn 0xe0, bad id 0xffffffff
PCI: devfn 0xe8, bad id 0xffffffff
PCI: devfn 0xf0, bad id 0xffffffff
PCI: devfn 0xf8, bad id 0xffffffff
PCI: pci_scan_bus returning with max=03
Capability: 0x07 @ 0xa0
PCI: 03: 133MHz PCI-X
do_pci_scan_bridge returns max 3
do_pci_scan_bridge for PCI: 01:03.0
PCI: pci_scan_bus for bus 4
malloc Enter, size 668, free_mem_ptr 00042488
malloc 0x00042488
PCI: 04:00.0 [1022/7464] bus ops
PCI: 04:00.0 [1022/7464] enabled
malloc Enter, size 668, free_mem_ptr 00042724
malloc 0x00042724
PCI: 04:00.1 [1022/7464] bus ops
PCI: 04:00.1 [1022/7464] enabled
malloc Enter, size 668, free_mem_ptr 000429c0
malloc 0x000429c0
PCI: 04:00.2 [1022/7463] ops
USB2 disabled.
PCI: 04:00.2 [1022/7463] disabled
PCI: devfn 0x3, bad id 0xffffffff
PCI: devfn 0x4, bad id 0xffffffff
PCI: devfn 0x5, bad id 0xffffffff
PCI: devfn 0x6, bad id 0xffffffff
PCI: devfn 0x7, bad id 0xffffffff
malloc Enter, size 668, free_mem_ptr 00042c5c
malloc 0x00042c5c
PCI: 04:01.0 [1022/7462] ops
PCI: 04:01.0 [1022/7462] enabled
PCI: devfn 0x10, bad id 0xffffffff
PCI: devfn 0x18, bad id 0xffffffff
PCI: devfn 0x20, bad id 0xffffffff
PCI: devfn 0x28, bad id 0xffffffff
malloc Enter, size 668, free_mem_ptr 00042ef8
malloc 0x00042ef8
PCI: 04:06.0 [1002/4752] enabled
PCI: devfn 0x38, bad id 0xffffffff
PCI: devfn 0x40, bad id 0xffffffff
PCI: devfn 0x48, bad id 0xffffffff
PCI: devfn 0x50, bad id 0xffffffff
PCI: devfn 0x58, bad id 0xffffffff
PCI: devfn 0x60, bad id 0xffffffff
PCI: devfn 0x68, bad id 0xffffffff
PCI: devfn 0x70, bad id 0xffffffff
PCI: devfn 0x78, bad id 0xffffffff
PCI: devfn 0x80, bad id 0xffffffff
PCI: devfn 0x88, bad id 0xffffffff
PCI: devfn 0x90, bad id 0xffffffff
PCI: devfn 0x98, bad id 0xffffffff
PCI: devfn 0xa0, bad id 0xffffffff
PCI: devfn 0xa8, bad id 0xffffffff
PCI: devfn 0xb0, bad id 0xffffffff
PCI: devfn 0xb8, bad id 0xffffffff
PCI: devfn 0xc0, bad id 0xffffffff
PCI: devfn 0xc8, bad id 0xffffffff
PCI: devfn 0xd0, bad id 0xffffffff
PCI: devfn 0xd8, bad id 0xffffffff
PCI: devfn 0xe0, bad id 0xffffffff
PCI: devfn 0xe8, bad id 0xffffffff
PCI: devfn 0xf0, bad id 0xffffffff
PCI: devfn 0xf8, bad id 0xffffffff
scan_static_bus for PCI: 04:00.0
scan_static_bus for PCI: 04:00.0 done
scan_static_bus for PCI: 04:00.1
scan_static_bus for PCI: 04:00.1 done
PCI: pci_scan_bus returning with max=04
do_pci_scan_bridge returns max 4
scan_static_bus for PCI: 01:04.0
scan_static_bus for PCI: 01:04.0 done
scan_static_bus for PCI: 01:04.2
scan_static_bus for PCI: 01:04.2 done
scan_static_bus for PCI: 01:04.3
scan_static_bus for PCI: 01:04.3 done
PCI: pci_scan_bus returning with max=04
PCI: pci_scan_bus returning with max=04
PCI_DOMAIN: 0000 passpw: enabled
PCI_DOMAIN: 0000 passpw: enabled
APIC_CLUSTER: 0 scanning...
  PCI: 00:18.3 siblings=0
CPU: APIC: 00 enabled
  PCI: 00:19.3 siblings=0
CPU: APIC: 01 enabled
scan_static_bus for Root Device done
done
Allocating resources...
Reading resources...
Root Device compute_allocate_io: base: 00000400 size: 00000000 align: 0 gran: 
0
Root Device read_resources bus 0 link: 0
PCI_DOMAIN: 0000 read_resources bus 0 link: 0
PCI: 00:18.0 compute_allocate_io: base: 00000000 size: 00000000 align: 12 
gran: 12
PCI: 00:18.0 read_resources bus 0 link: 0
PCI: 00:00.0 missing read_resources
PCI: 00:00.1 missing read_resources
PCI: 00:01.0 missing read_resources
PCI: 00:01.1 missing read_resources
PCI: 00:00.0 missing read_resources
PCI: 00:01.0 missing read_resources
PCI: 00:01.1 missing read_resources
PCI: 00:01.2 missing read_resources
PCI: 00:01.3 missing read_resources
PCI: 00:18.0 read_resources bus 0 link: 0 done
PCI: 00:18.0 compute_allocate_io: base: 00000000 size: 00000000 align: 12 
gran: 12 done
PCI: 00:18.0 compute_allocate_prefmem: base: 00000000 size: 00000000 align: 20 
gran: 20
PCI: 00:18.0 read_resources bus 0 link: 0
PCI: 00:00.0 missing read_resources
PCI: 00:00.1 missing read_resources
PCI: 00:01.0 missing read_resources
PCI: 00:01.1 missing read_resources
PCI: 00:00.0 missing read_resources
PCI: 00:01.0 missing read_resources
PCI: 00:01.1 missing read_resources
PCI: 00:01.2 missing read_resources
PCI: 00:01.3 missing read_resources
PCI: 00:18.0 read_resources bus 0 link: 0 done
PCI: 00:18.0 compute_allocate_prefmem: base: 00000000 size: 00000000 align: 20 
gran: 20 done
PCI: 00:18.0 compute_allocate_mem: base: 00000000 size: 00000000 align: 20 
gran: 20
PCI: 00:18.0 read_resources bus 0 link: 0
PCI: 00:00.0 missing read_resources
PCI: 00:00.1 missing read_resources
PCI: 00:01.0 missing read_resources
PCI: 00:01.1 missing read_resources
PCI: 00:00.0 missing read_resources
PCI: 00:01.0 missing read_resources
PCI: 00:01.1 missing read_resources
PCI: 00:01.2 missing read_resources
PCI: 00:01.3 missing read_resources
PCI: 00:18.0 read_resources bus 0 link: 0 done
PCI: 00:18.0 compute_allocate_mem: base: 00000000 size: 00000000 align: 20 
gran: 20 done
PCI: 00:18.0 compute_allocate_io: base: 00000000 size: 00000000 align: 12 
gran: 12
PCI: 00:18.0 read_resources bus 1 link: 2
PCI: 01:01.0 compute_allocate_io: base: 00000000 size: 00000000 align: 12 
gran: 12
PCI: 01:01.0 read_resources bus 2 link: 0
PCI: 01:01.0 read_resources bus 2 link: 0 done
PCI: 02:03.0 18 *  [0x00000000 - 0x0000003f] io
PCI: 02:04.0 18 *  [0x00000040 - 0x0000007f] io
PCI: 02:05.0 20 *  [0x00000080 - 0x0000008f] io
PCI: 02:05.0 10 *  [0x00000090 - 0x00000097] io
PCI: 02:05.0 18 *  [0x000000a0 - 0x000000a7] io
PCI: 02:05.0 14 *  [0x000000b0 - 0x000000b3] io
PCI: 02:05.0 1c *  [0x000000c0 - 0x000000c3] io
PCI: 01:01.0 compute_allocate_io: base: 000000c4 size: 00001000 align: 12 
gran: 12 done
PCI: 01:01.0 compute_allocate_prefmem: base: 00000000 size: 00000000 align: 20 
gran: 20
PCI: 01:01.0 read_resources bus 2 link: 0
PCI: 01:01.0 read_resources bus 2 link: 0 done
PCI: 01:01.0 compute_allocate_prefmem: base: 00000000 size: 00000000 align: 20 
gran: 20 done
PCI: 01:01.0 compute_allocate_prefmem: base: fffffffffff00000 size: 00000000 
align: 20 gran: 20
PCI: 01:01.0 read_resources bus 2 link: 0
PCI: 01:01.0 read_resources bus 2 link: 0 done
PCI: 01:01.0 compute_allocate_prefmem: base: fffffffffff00000 size: 00000000 
align: 20 gran: 20 done
PCI: 01:01.0 24 <- [0xfffffffffff00000 - 0xffffffffffefffff] bus 2 prefmem
PCI: 01:01.0 compute_allocate_mem: base: 00000000 size: 00000000 align: 20 
gran: 20
PCI: 01:01.0 read_resources bus 2 link: 0
PCI: 01:01.0 read_resources bus 2 link: 0 done
PCI: 02:05.0 30 *  [0x00000000 - 0x0007ffff] mem
PCI: 02:03.0 10 *  [0x00080000 - 0x0009ffff] mem
PCI: 02:04.0 10 *  [0x000a0000 - 0x000bffff] mem
PCI: 02:04.0 14 *  [0x000c0000 - 0x000dffff] mem
PCI: 02:04.0 30 *  [0x000e0000 - 0x000fffff] mem
PCI: 02:05.0 24 *  [0x00100000 - 0x001003ff] mem
PCI: 01:01.0 compute_allocate_mem: base: 00100400 size: 00200000 align: 20 
gran: 20 done
PCI: 01:03.0 compute_allocate_io: base: 00000000 size: 00000000 align: 12 
gran: 12
PCI: 01:03.0 read_resources bus 4 link: 0
PCI: 01:03.0 read_resources bus 4 link: 0 done
PCI: 04:06.0 14 *  [0x00000000 - 0x000000ff] io
PCI: 01:03.0 compute_allocate_io: base: 00000100 size: 00001000 align: 12 
gran: 12 done
PCI: 01:03.0 compute_allocate_prefmem: base: 00000000 size: 00000000 align: 20 
gran: 20
PCI: 01:03.0 read_resources bus 4 link: 0
PCI: 01:03.0 read_resources bus 4 link: 0 done
PCI: 01:03.0 compute_allocate_prefmem: base: 00000000 size: 00000000 align: 20 
gran: 20 done
PCI: 01:03.0 compute_allocate_prefmem: base: fff00000 size: 00000000 align: 20 
gran: 20
PCI: 01:03.0 read_resources bus 4 link: 0
PCI: 01:03.0 read_resources bus 4 link: 0 done
PCI: 01:03.0 compute_allocate_prefmem: base: fff00000 size: 00000000 align: 20 
gran: 20 done
PCI: 01:03.0 24 <- [0x00fff00000 - 0x00ffefffff] bus 4 prefmem
PCI: 01:03.0 compute_allocate_mem: base: 00000000 size: 00000000 align: 20 
gran: 20
PCI: 01:03.0 read_resources bus 4 link: 0
PCI: 01:03.0 read_resources bus 4 link: 0 done
PCI: 04:06.0 10 *  [0x00000000 - 0x00ffffff] mem
PCI: 04:06.0 30 *  [0x01000000 - 0x0101ffff] mem
PCI: 04:01.0 30 *  [0x01020000 - 0x0102ffff] mem
PCI: 04:00.0 10 *  [0x01030000 - 0x01030fff] mem
PCI: 04:00.1 10 *  [0x01031000 - 0x01031fff] mem
PCI: 04:01.0 10 *  [0x01032000 - 0x01032fff] mem
PCI: 04:06.0 18 *  [0x01033000 - 0x01033fff] mem
PCI: 01:03.0 compute_allocate_mem: base: 01034000 size: 01100000 align: 24 
gran: 20 done
PCI: 01:04.0 read_resources bus 0 link: 0
PCI: 01:04.0 read_resources bus 0 link: 0 done
PCI: 00:18.0 read_resources bus 1 link: 2 done
PCI: 01:01.0 1c *  [0x00000000 - 0x00000fff] io
PCI: 01:03.0 1c *  [0x00001000 - 0x00001fff] io
PCI: 01:04.3 58 *  [0x00002000 - 0x000020ff] io
PCI: 01:04.5 10 *  [0x00002400 - 0x000024ff] io
PCI: 01:04.6 10 *  [0x00002800 - 0x000028ff] io
PCI: 01:04.6 14 *  [0x00002c00 - 0x00002c7f] io
PCI: 01:04.5 14 *  [0x00002c80 - 0x00002cbf] io
PCI: 01:04.2 10 *  [0x00002cc0 - 0x00002cdf] io
PCI: 01:04.1 20 *  [0x00002ce0 - 0x00002cef] io
PCI: 00:18.0 compute_allocate_io: base: 00002cf0 size: 00003000 align: 12 
gran: 12 done
PCI: 00:18.0 compute_allocate_prefmem: base: 00000000 size: 00000000 align: 20 
gran: 20
PCI: 00:18.0 read_resources bus 1 link: 2
PCI: 00:18.0 read_resources bus 1 link: 2 done
PCI: 00:18.0 compute_allocate_prefmem: base: 00000000 size: 00000000 align: 20 
gran: 20 done
PCI: 00:18.0 compute_allocate_mem: base: 00000000 size: 00000000 align: 20 
gran: 20
PCI: 00:18.0 read_resources bus 1 link: 2
PCI: 00:18.0 read_resources bus 1 link: 2 done
PCI: 01:03.0 20 *  [0x00000000 - 0x010fffff] mem
PCI: 01:01.0 20 *  [0x01100000 - 0x012fffff] mem
PCI: 01:01.1 10 *  [0x01300000 - 0x01300fff] mem
PCI: 01:02.1 10 *  [0x01301000 - 0x01301fff] mem
PCI: 00:18.0 compute_allocate_mem: base: 01302000 size: 01400000 align: 24 
gran: 20 done
PCI_DOMAIN: 0000 read_resources bus 0 link: 0 done
Root Device read_resources bus 0 link: 0 done
PCI: 00:18.0 1d2 *  [0x00001000 - 0x00003fff] io
PCI: 00:18.0 1d8 *  [0x00004000 - 0x00003fff] io
Root Device compute_allocate_io: base: 00004000 size: 00003c00 align: 12 gran: 
0 done
Root Device compute_allocate_mem: base: 00000000 size: 00000000 align: 0 gran: 
0
Root Device read_resources bus 0 link: 0
Root Device read_resources bus 0 link: 0 done
PCI: 00:18.3 94 *  [0x00000000 - 0x03ffffff] mem
PCI: 00:18.0 1a2 *  [0x04000000 - 0x053fffff] mem
PCI: 00:18.0 1b8 *  [0x05400000 - 0x053fffff] prefmem
PCI: 00:18.0 1b0 *  [0x05400000 - 0x053fffff] mem
PCI: 00:18.0 1aa *  [0x05400000 - 0x053fffff] prefmem
Root Device compute_allocate_mem: base: 05400000 size: 05400000 align: 26 
gran: 0 done
Done reading resources.
Setting resources...
Root Device compute_allocate_io: base: 00001000 size: 00003c00 align: 12 gran: 
0
Root Device read_resources bus 0 link: 0
Root Device read_resources bus 0 link: 0 done
PCI: 00:18.0 1d2 *  [0x00001000 - 0x00003fff] io
PCI: 00:18.0 1d8 *  [0x00004000 - 0x00003fff] io
Root Device compute_allocate_io: base: 00004000 size: 00003000 align: 12 gran: 
0 done
Root Device compute_allocate_mem: base: f8000000 size: 05400000 align: 26 
gran: 0
Root Device read_resources bus 0 link: 0
Root Device read_resources bus 0 link: 0 done
PCI: 00:18.3 94 *  [0xf8000000 - 0xfbffffff] mem
PCI: 00:18.0 1a2 *  [0xfc000000 - 0xfd3fffff] mem
PCI: 00:18.0 1b8 *  [0xfd400000 - 0xfd3fffff] prefmem
PCI: 00:18.0 1b0 *  [0xfd400000 - 0xfd3fffff] mem
PCI: 00:18.0 1aa *  [0xfd400000 - 0xfd3fffff] prefmem
Root Device compute_allocate_mem: base: fd400000 size: 05400000 align: 26 
gran: 0 done
Root Device assign_resources, bus 0 link: 0
PCI_DOMAIN: 0000 assign_resources, bus 0 link: 0
PCI: 00:18.0 compute_allocate_io: base: 00004000 size: 00000000 align: 12 
gran: 12
PCI: 00:18.0 read_resources bus 0 link: 0
PCI: 00:00.0 missing read_resources
PCI: 00:00.1 missing read_resources
PCI: 00:01.0 missing read_resources
PCI: 00:01.1 missing read_resources
PCI: 00:00.0 missing read_resources
PCI: 00:01.0 missing read_resources
PCI: 00:01.1 missing read_resources
PCI: 00:01.2 missing read_resources
PCI: 00:01.3 missing read_resources
PCI: 00:18.0 read_resources bus 0 link: 0 done
PCI: 00:18.0 compute_allocate_io: base: 00004000 size: 00000000 align: 12 
gran: 12 done
PCI: 00:18.0 1d8 <- [0x0000004000 - 0x0000003fff] io <node 0 link 0>
PCI: 00:18.0 compute_allocate_prefmem: base: fd400000 size: 00000000 align: 20 
gran: 20
PCI: 00:18.0 read_resources bus 0 link: 0
PCI: 00:00.0 missing read_resources
PCI: 00:00.1 missing read_resources
PCI: 00:01.0 missing read_resources
PCI: 00:01.1 missing read_resources
PCI: 00:00.0 missing read_resources
PCI: 00:01.0 missing read_resources
PCI: 00:01.1 missing read_resources
PCI: 00:01.2 missing read_resources
PCI: 00:01.3 missing read_resources
PCI: 00:18.0 read_resources bus 0 link: 0 done
PCI: 00:18.0 compute_allocate_prefmem: base: fd400000 size: 00000000 align: 20 
gran: 20 done
PCI: 00:18.0 1b8 <- [0x00fd400000 - 0x00fd3fffff] prefmem <node 0 link 0>
PCI: 00:18.0 compute_allocate_mem: base: fd400000 size: 00000000 align: 20 
gran: 20
PCI: 00:18.0 read_resources bus 0 link: 0
PCI: 00:00.0 missing read_resources
PCI: 00:00.1 missing read_resources
PCI: 00:01.0 missing read_resources
PCI: 00:01.1 missing read_resources
PCI: 00:00.0 missing read_resources
PCI: 00:01.0 missing read_resources
PCI: 00:01.1 missing read_resources
PCI: 00:01.2 missing read_resources
PCI: 00:01.3 missing read_resources
PCI: 00:18.0 read_resources bus 0 link: 0 done
PCI: 00:18.0 compute_allocate_mem: base: fd400000 size: 00000000 align: 20 
gran: 20 done
PCI: 00:18.0 1b0 <- [0x00fd400000 - 0x00fd3fffff] mem <node 0 link 0>
PCI: 00:18.0 compute_allocate_io: base: 00001000 size: 00003000 align: 12 
gran: 12
PCI: 00:18.0 read_resources bus 1 link: 2
PCI: 00:18.0 read_resources bus 1 link: 2 done
PCI: 01:01.0 1c *  [0x00001000 - 0x00001fff] io
PCI: 01:03.0 1c *  [0x00002000 - 0x00002fff] io
PCI: 01:04.3 58 *  [0x00003000 - 0x000030ff] io
PCI: 01:04.5 10 *  [0x00003400 - 0x000034ff] io
PCI: 01:04.6 10 *  [0x00003800 - 0x000038ff] io
PCI: 01:04.6 14 *  [0x00003c00 - 0x00003c7f] io
PCI: 01:04.5 14 *  [0x00003c80 - 0x00003cbf] io
PCI: 01:04.2 10 *  [0x00003cc0 - 0x00003cdf] io
PCI: 01:04.1 20 *  [0x00003ce0 - 0x00003cef] io
PCI: 00:18.0 compute_allocate_io: base: 00003cf0 size: 00003000 align: 12 
gran: 12 done
PCI: 00:18.0 1d2 <- [0x0000001000 - 0x0000003fff] io <node 0 link 2>
PCI: 00:18.0 compute_allocate_prefmem: base: fd400000 size: 00000000 align: 20 
gran: 20
PCI: 00:18.0 read_resources bus 1 link: 2
PCI: 00:18.0 read_resources bus 1 link: 2 done
PCI: 00:18.0 compute_allocate_prefmem: base: fd400000 size: 00000000 align: 20 
gran: 20 done
PCI: 00:18.0 1aa <- [0x00fd400000 - 0x00fd3fffff] prefmem <node 0 link 2>
PCI: 00:18.0 compute_allocate_mem: base: fc000000 size: 01400000 align: 24 
gran: 20
PCI: 00:18.0 read_resources bus 1 link: 2
PCI: 00:18.0 read_resources bus 1 link: 2 done
PCI: 01:03.0 20 *  [0xfc000000 - 0xfd0fffff] mem
PCI: 01:01.0 20 *  [0xfd100000 - 0xfd2fffff] mem
PCI: 01:01.1 10 *  [0xfd300000 - 0xfd300fff] mem
PCI: 01:02.1 10 *  [0xfd301000 - 0xfd301fff] mem
PCI: 00:18.0 compute_allocate_mem: base: fd302000 size: 01400000 align: 24 
gran: 20 done
PCI: 00:18.0 1a2 <- [0x00fc000000 - 0x00fd3fffff] mem <node 0 link 2>
PCI: 00:18.0 assign_resources, bus 0 link: 0
PCI: 00:18.0 assign_resources, bus 0 link: 0
PCI: 00:18.0 assign_resources, bus 1 link: 2
PCI: 01:01.0 compute_allocate_io: base: 00001000 size: 00001000 align: 12 
gran: 12
PCI: 01:01.0 read_resources bus 2 link: 0
PCI: 01:01.0 read_resources bus 2 link: 0 done
PCI: 02:03.0 18 *  [0x00001000 - 0x0000103f] io
PCI: 02:04.0 18 *  [0x00001040 - 0x0000107f] io
PCI: 02:05.0 20 *  [0x00001080 - 0x0000108f] io
PCI: 02:05.0 10 *  [0x00001090 - 0x00001097] io
PCI: 02:05.0 18 *  [0x000010a0 - 0x000010a7] io
PCI: 02:05.0 14 *  [0x000010b0 - 0x000010b3] io
PCI: 02:05.0 1c *  [0x000010c0 - 0x000010c3] io
PCI: 01:01.0 compute_allocate_io: base: 000010c4 size: 00001000 align: 12 
gran: 12 done
PCI: 01:01.0 1c <- [0x0000001000 - 0x0000001fff] bus 2 io
PCI: 01:01.0 compute_allocate_mem: base: fd100000 size: 00200000 align: 20 
gran: 20
PCI: 01:01.0 read_resources bus 2 link: 0
PCI: 01:01.0 read_resources bus 2 link: 0 done
PCI: 02:05.0 30 *  [0xfd100000 - 0xfd17ffff] mem
PCI: 02:03.0 10 *  [0xfd180000 - 0xfd19ffff] mem
PCI: 02:04.0 10 *  [0xfd1a0000 - 0xfd1bffff] mem
PCI: 02:04.0 14 *  [0xfd1c0000 - 0xfd1dffff] mem
PCI: 02:04.0 30 *  [0xfd1e0000 - 0xfd1fffff] mem
PCI: 02:05.0 24 *  [0xfd200000 - 0xfd2003ff] mem
PCI: 01:01.0 compute_allocate_mem: base: fd200400 size: 00200000 align: 20 
gran: 20 done
PCI: 01:01.0 20 <- [0x00fd100000 - 0x00fd2fffff] bus 2 mem
PCI: 01:01.0 assign_resources, bus 2 link: 0
PCI: 02:03.0 10 <- [0x00fd180000 - 0x00fd19ffff] mem
PCI: 02:03.0 18 <- [0x0000001000 - 0x000000103f] io
PCI: 02:04.0 10 <- [0x00fd1a0000 - 0x00fd1bffff] mem
PCI: 02:04.0 14 <- [0x00fd1c0000 - 0x00fd1dffff] mem
PCI: 02:04.0 18 <- [0x0000001040 - 0x000000107f] io
PCI: 02:04.0 30 <- [0x00fd1e0000 - 0x00fd1fffff] romem
PCI: 02:05.0 10 <- [0x0000001090 - 0x0000001097] io
PCI: 02:05.0 14 <- [0x00000010b0 - 0x00000010b3] io
PCI: 02:05.0 18 <- [0x00000010a0 - 0x00000010a7] io
PCI: 02:05.0 1c <- [0x00000010c0 - 0x00000010c3] io
PCI: 02:05.0 20 <- [0x0000001080 - 0x000000108f] io
PCI: 02:05.0 24 <- [0x00fd200000 - 0x00fd2003ff] mem
PCI: 02:05.0 30 <- [0x00fd100000 - 0x00fd17ffff] romem
PCI: 01:01.0 assign_resources, bus 2 link: 0
PCI: 01:01.1 10 <- [0x00fd300000 - 0x00fd300fff] mem64
PCI: 01:02.1 10 <- [0x00fd301000 - 0x00fd301fff] mem64
PCI: 01:03.0 compute_allocate_io: base: 00002000 size: 00001000 align: 12 
gran: 12
PCI: 01:03.0 read_resources bus 4 link: 0
PCI: 01:03.0 read_resources bus 4 link: 0 done
PCI: 04:06.0 14 *  [0x00002000 - 0x000020ff] io
PCI: 01:03.0 compute_allocate_io: base: 00002100 size: 00001000 align: 12 
gran: 12 done
PCI: 01:03.0 1c <- [0x0000002000 - 0x0000002fff] bus 4 io
PCI: 01:03.0 compute_allocate_mem: base: fc000000 size: 01100000 align: 24 
gran: 20
PCI: 01:03.0 read_resources bus 4 link: 0
PCI: 01:03.0 read_resources bus 4 link: 0 done
PCI: 04:06.0 10 *  [0xfc000000 - 0xfcffffff] mem
PCI: 04:06.0 30 *  [0xfd000000 - 0xfd01ffff] mem
PCI: 04:01.0 30 *  [0xfd020000 - 0xfd02ffff] mem
PCI: 04:00.0 10 *  [0xfd030000 - 0xfd030fff] mem
PCI: 04:00.1 10 *  [0xfd031000 - 0xfd031fff] mem
PCI: 04:01.0 10 *  [0xfd032000 - 0xfd032fff] mem
PCI: 04:06.0 18 *  [0xfd033000 - 0xfd033fff] mem
PCI: 01:03.0 compute_allocate_mem: base: fd034000 size: 01100000 align: 24 
gran: 20 done
PCI: 01:03.0 20 <- [0x00fc000000 - 0x00fd0fffff] bus 4 mem
PCI: 01:03.0 assign_resources, bus 4 link: 0
PCI: 04:00.0 10 <- [0x00fd030000 - 0x00fd030fff] mem
PCI: 04:00.1 10 <- [0x00fd031000 - 0x00fd031fff] mem
PCI: 04:01.0 10 <- [0x00fd032000 - 0x00fd032fff] mem
PCI: 04:01.0 30 <- [0x00fd020000 - 0x00fd02ffff] romem
PCI: 04:06.0 10 <- [0x00fc000000 - 0x00fcffffff] mem
PCI: 04:06.0 14 <- [0x0000002000 - 0x00000020ff] io
PCI: 04:06.0 18 <- [0x00fd033000 - 0x00fd033fff] mem
PCI: 04:06.0 30 <- [0x00fd000000 - 0x00fd01ffff] romem
PCI: 01:03.0 assign_resources, bus 4 link: 0
PCI: 01:04.1 20 <- [0x0000003ce0 - 0x0000003cef] io
PCI: 01:04.2 10 <- [0x0000003cc0 - 0x0000003cdf] io
PCI: 01:04.3 58 <- [0x0000003000 - 0x00000030ff] io
PCI: 01:04.5 10 <- [0x0000003400 - 0x00000034ff] io
PCI: 01:04.5 14 <- [0x0000003c80 - 0x0000003cbf] io
PCI: 01:04.6 10 <- [0x0000003800 - 0x00000038ff] io
PCI: 01:04.6 14 <- [0x0000003c00 - 0x0000003c7f] io
PCI: 00:18.0 assign_resources, bus 1 link: 2
PCI: 00:18.3 94 <- [0x00f8000000 - 0x00fbffffff] mem <gart>
PCI: 00:19.3 94 <- [0x00f8000000 - 0x00fbffffff] mem <gart>
PCI_DOMAIN: 0000 assign_resources, bus 0 link: 0
Root Device assign_resources, bus 0 link: 0
Done setting resources.
Done allocating resources.
Enabling resourcess...
PCI: 00:18.0 cmd <- 140
PCI: 00:00.0 missing enable_resources
PCI: 00:00.1 missing enable_resources
PCI: 00:01.0 missing enable_resources
PCI: 00:01.1 missing enable_resources
PCI: 00:00.0 missing enable_resources
PCI: 00:01.0 missing enable_resources
PCI: 00:01.1 missing enable_resources
PCI: 00:01.2 missing enable_resources
PCI: 00:01.3 missing enable_resources
PCI: 01:01.0 bridge ctrl <- 0003
PCI: 01:01.0 cmd <- 147
PCI: 02:03.0 cmd <- 143
PCI: 02:04.0 cmd <- 143
PCI: 02:05.0 cmd <- 143
PCI: 01:01.1 cmd <- 146
PCI: 01:02.1 cmd <- 146
PCI: 01:03.0 bridge ctrl <- 0003
PCI: 01:03.0 cmd <- 147
PCI: 04:00.0 cmd <- 142
PCI: 04:00.1 cmd <- 142
PCI: 04:01.0 cmd <- 142
PCI: 04:06.0 cmd <- 1c3
PCI: 01:04.0 cmd <- 14f
PCI: 01:04.1 cmd <- 141
PCI: 01:04.2 cmd <- 141
PCI: 01:04.3 cmd <- 141
PCI: 01:04.5 cmd <- 141
PCI: 01:04.6 cmd <- 141
PCI: 00:18.1 subsystem <- 161f/3017
PCI: 00:18.1 cmd <- 140
PCI: 00:18.2 subsystem <- 161f/3017
PCI: 00:18.2 cmd <- 140
PCI: 00:18.3 cmd <- 140
PCI: 00:19.0 cmd <- 140
PCI: 00:19.1 subsystem <- 161f/3017
PCI: 00:19.1 cmd <- 140
PCI: 00:19.2 subsystem <- 161f/3017
PCI: 00:19.2 cmd <- 140
PCI: 00:19.3 cmd <- 140
done.
Initializing devices...
Root Device init
PCI: 00:18.0 init
PCI: 00:18.1 init
PCI: 00:18.2 init
PCI: 00:18.3 init
NB: Function 3 Misc Control.. done.
PCI: 00:19.0 init
PCI: 00:19.1 init
PCI: 00:19.2 init
PCI: 00:19.3 init
NB: Function 3 Misc Control.. done.
APIC_CLUSTER: 0 init
Initializing CPU #0
CPU: vendor AMD device f5a
Enabling cache

Setting fixed MTRRs(0-88) type: UC
Setting fixed MTRRs(0-16) Type: WB, RdMEM, WrMEM
Setting fixed MTRRs(24-88) Type: WB, RdMEM, WrMEM
DONE fixed MTRRs
Setting variable MTRR 0, base:    0MB, range: 2048MB, type WB
ADDRESS_MASK_HIGH=0xff
DONE variable MTRRs
Clear out the extra MTRR's
ADDRESS_MASK_HIGH=0xff
ADDRESS_MASK_HIGH=0xff
ADDRESS_MASK_HIGH=0xff
ADDRESS_MASK_HIGH=0xff
ADDRESS_MASK_HIGH=0xff
ADDRESS_MASK_HIGH=0xff
ADDRESS_MASK_HIGH=0xff
call enable_var_mtrr()
Leave x86_setup_var_mtrrs

MTRR check
Fixed MTRRs   : Enabled
Variable MTRRs: Enabled

microcode: equivalent processor rev id  = 0x004a, patch id = 0x00000000
microcode: patch id that want to apply= 0x00000047
microcode: updated to patch id = 0x00000047  success
Setting up local apic... apic_id: 0 done.
Clearing memory 1024K - 1048576K: --------------- done
CPU #0 Initialized
Asserting INIT.
Waiting for send to finish...
+Deasserting INIT.
Waiting for send to finish...
+start_eip=0x00010000
#startup loops: 2.
Sending STARTUP #1 to 1.
After apic_write.
Initializing CPU #1
Startup point 1.
Waiting for send to finish...
+CPU: vendor AMD device f5a
Sending STARTUP #2 to 1.
After apic_write.
Enabling cache
at
 rSteutpt ipnogi nfti x1e.d
fMWTaRiRtsi(n0g- 8f8o)r  tsyepned:  tUoC
 inish...
fAfter SSteatrttiunpg.
RiWxaeidt iMnTgR Rfso(r0 -11 6C)P UTSy pteo:  sWtBo,p
 dMEM, WrMEM
Setting fixed MTRRs(24-88) Type: WB, RdMEM, WrMEM
DONE fixed MTRRs
Setting variable MTRR 0, base:    0MB, range: 2048MB, type WB
ADDRESS_MASK_HIGH=0xff
DONE variable MTRRs
Clear out the extra MTRR's
ADDRESS_MASK_HIGH=0xff
ADDRESS_MASK_HIGH=0xff
ADDRESS_MASK_HIGH=0xff
ADDRESS_MASK_HIGH=0xff
ADDRESS_MASK_HIGH=0xff
ADDRESS_MASK_HIGH=0xff
ADDRESS_MASK_HIGH=0xff
call enable_var_mtrr()
Leave x86_setup_var_mtrrs

MTRR check
Fixed MTRRs   : Enabled
Variable MTRRs: Enabled

microcode: equivalent processor rev id  = 0x004a, patch id = 0x00000000
microcode: patch id that want to apply= 0x00000047
microcode: updated to patch id = 0x00000047  success
Setting up local apic... apic_id: 1 done.
Clearing memory 1048576K - 2097152K: ---------------- done
CPU #1 Initialized
All AP CPUs stopped
PCI: 01:01.0 init
PCI: 01:03.0 init
PCI: 01:04.0 init
for IRQ, reg 0x00000000 value 0x00000700 0x00000000
for IRQ, reg 0x00000001 value 0x00010000 0x00000000
for IRQ, reg 0x00000002 value 0x00010000 0x00000000
for IRQ, reg 0x00000003 value 0x00010000 0x00000000
for IRQ, reg 0x00000004 value 0x00010000 0x00000000
for IRQ, reg 0x00000005 value 0x00010000 0x00000000
for IRQ, reg 0x00000006 value 0x00010000 0x00000000
for IRQ, reg 0x00000007 value 0x00010000 0x00000000
for IRQ, reg 0x00000008 value 0x00010000 0x00000000
for IRQ, reg 0x00000009 value 0x00010000 0x00000000
for IRQ, reg 0x0000000a value 0x00010000 0x00000000
for IRQ, reg 0x0000000b value 0x00010000 0x00000000
for IRQ, reg 0x0000000c value 0x00010000 0x00000000
for IRQ, reg 0x0000000d value 0x00010000 0x00000000
for IRQ, reg 0x0000000e value 0x00010000 0x00000000
for IRQ, reg 0x0000000f value 0x00010000 0x00000000
for IRQ, reg 0x00000010 value 0x00010000 0x00000000
for IRQ, reg 0x00000011 value 0x00010000 0x00000000
for IRQ, reg 0x00000012 value 0x00010000 0x00000000
for IRQ, reg 0x00000013 value 0x00010000 0x00000000
for IRQ, reg 0x00000014 value 0x00010000 0x00000000
for IRQ, reg 0x00000015 value 0x00010000 0x00000000
for IRQ, reg 0x00000016 value 0x00010000 0x00000000
for IRQ, reg 0x00000017 value 0x00010000 0x00000000
RTC Init
RTC: Checksum invalid zeroing cmos
Invalid CMOS LB checksum
enabling HPET @0xfed00000
PCI: 01:04.1 init
PCI: 01:04.3 init
set power on after power fail
PCI: 02:03.0 init
PCI: 02:04.0 init
PCI: 02:05.0 init
PCI: 04:01.0 init
Reseting PHY... Done
PCI: 04:06.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.
Wrote the mp table end at: 00000020 - 0000021c
Moving GDT to 0x500...ok
Wrote linuxbios table at: 00000530 - 00000df8  checksum 5f51

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

    33:stream_init() - rom_stream: 0xfffd0000 - 0xfffdee87
Found ELF candiate at offset 0
header_offset is 0
Try to load at offset 0x0
n_type: 00000001 n_name(8): ELFBoot  n_desc(10): Etherboot
n_type: 00000002 n_name(8): ELFBoot  n_desc(6): 5.2.6
Loading Etherboot version: 5.2.6
Dropping non PT_LOAD segment
malloc Enter, size 32, free_mem_ptr 00043194
malloc 0x00043194
New segment addr 0x20000 size 0x18024 offset 0xb0 filesize 0x891c
(cleaned up) New segment addr 0x20000 size 0x18024 offset 0xb0 filesize 0x891c
lb: [0x0000000000004000, 0x000000000004e000)
segment: [0x0000000000020000, 0x000000000002891c, 0x0000000000038024)
 bounce: [0x000000007ff88000, 0x000000007ff9091c, 0x000000007ffa0024)
Loading Segment: addr: 0x000000007ff88000 memsz: 0x0000000000018024 filesz: 
0x000000000000891c
[ 0x000000007ff88000, 000000007ff9091c, 0x000000007ffa0024) <- 
00000000000000b0
Clearing Segment: addr: 0x000000007ff9091c memsz: 0x000000000000f708
Loaded segments
verified segments
closed down stream
Jumping to boot code at 0x20000
entry    = 0x00020000
lb_start = 0x00004000
lb_size  = 0x0004a000
adjust   = 0x7ffb2000
buffer   = 0x7ff6c000
     elf_boot_notes = 0x0001b160
adjusted_boot_notes = 0x7ffcd160
ROM segment 0x0000 length 0x0000 reloc 0x00020000
CPU 2088 Mhz
Etherboot 5.2.6 (GPL) http://etherboot.org Tagged ELF for [E1000]
Relocating _text from: [00020000,00039710) to [7fee68f0,7ff00000)
Boot from (N)etwork or (Q)uit? N
.Probing pci nic...
[e1000-82541gi]Ethernet addr: 00:D0:68:09:EC:FD
e1000: Valid Link not detected

[e1000-82541gi]Ethernet addr: 00:D0:68:09:EC:FE
Searching for server (DHCP)...
...Me: xxx.xxx.xxx.xxx, Server: 134.155.45.16, Gateway xxx.xxx.xxx.xxx
Loading xxx.xxx.xxx.xxx:/htxlinux.0 ...
(ELF)... .............................................................................................................
...........................................................................................................................................................
...........................................................................................................................................................
...........................................................................................................................................................
...........................................................................................................................................................
...................................................................done
Firmware type: LinuxBIOS




From stepan at openbios.org  Tue Mar 28 16:47:40 2006
From: stepan at openbios.org (Stefan Reinauer)
Date: Tue, 28 Mar 2006 16:47:40 +0200
Subject: [LinuxBIOS] Kernel will not boot
In-Reply-To: <200603281624.49589.pdegler@rumms.uni-mannheim.de>
References: <200603281624.49589.pdegler@rumms.uni-mannheim.de>
Message-ID: <20060328144740.GA12187@openbios.org>

* Philipp Degler <pdegler at rumms.uni-mannheim.de> [060328 16:24]:
> I tried various payloads to boot the system. Filo could not find my hda saying 
for filo disable PCI, that should make it work. It expects ide to sit on
bus 0 which is normally not the case in linuxbios.

> floating bus. Etherboot loads OK and gets a kernel elf image via tftp but 
> kernel is not loading. Do you have an idea what could be the problem? Maybe 
> some PCI-Devices not initialized correctly?
 
Have you specified console=ttyS0 as a kernel parameter? Otherwise you
will not see anything when the kernel starts.


From ollie at lanl.gov  Tue Mar 28 18:32:07 2006
From: ollie at lanl.gov (Li-Ta Lo)
Date: Tue, 28 Mar 2006 09:32:07 -0700
Subject: [LinuxBIOS] Geode Utilities and Tools
In-Reply-To: <4428122C.2010704@onelabs.com>
References: <4428122C.2010704@onelabs.com>
Message-ID: <1143563527.9996.0.camel@logarithm.lanl.gov>

On Mon, 2006-03-27 at 10:26 -0600, Bari Ari wrote:
> Just FYI on the Geodes in case anyone missed them...
> 
> The AMD Geode dev site has a few handy utilities and tools for debugging 
> BIOS and driver settings.
> 
> Cyreg -  Cyreg is a menu driven utility that displays memory, I/O and 
> PCI configuration space data. The menus are defined in a text file that 
> allows the user to easily modify each menu.
> 
> Loadreg - Loadreg is a command line utility that allows the user to read 
> or modify any I/O, memory, or PCI configuration space location. It is 
> ideally suited to modifying system registers via a batch file.
> 
> MCVAL - Mcval tests the state of the memory controller against known 
> values, as well as lists all supported processor speeds and their 
> associated memory controller register values.
> 

Is there any Linux version?

> -Bari
> 
-- 
Li-Ta Lo <ollie at lanl.gov>
Los Alamos National Lab




From yinghai.lu at amd.com  Tue Mar 28 19:18:05 2006
From: yinghai.lu at amd.com (Lu, Yinghai)
Date: Tue, 28 Mar 2006 09:18:05 -0800
Subject: [LinuxBIOS] Kernel will not boot
Message-ID: <6F7DA19D05F3CF40B890C7CA2DB13A4203094B38@ssvlexmb2.amd.com>

Loglevel 8 is enough.

Also you code base is some old.


YH




From bari at onelabs.com  Tue Mar 28 22:59:01 2006
From: bari at onelabs.com (Bari Ari)
Date: Tue, 28 Mar 2006 14:59:01 -0600
Subject: [LinuxBIOS] Geode Utilities and Tools
In-Reply-To: <1143563527.9996.0.camel@logarithm.lanl.gov>
References: <4428122C.2010704@onelabs.com>
	<1143563527.9996.0.camel@logarithm.lanl.gov>
Message-ID: <4429A395.4060705@onelabs.com>

Li-Ta Lo wrote:
> Is there any Linux version?

Yes.

-Bari



From JJia at Fortinet.com  Thu Mar 30 22:35:48 2006
From: JJia at Fortinet.com (Jia Jianwei)
Date: Thu, 30 Mar 2006 12:35:48 -0800
Subject: [LinuxBIOS] broadcom HT1000 SATA PHY initializing
References: <4428122C.2010704@onelabs.com><1143563527.9996.0.camel@logarithm.lanl.gov>
	<4429A395.4060705@onelabs.com>
Message-ID: <018e01c65439$8771d090$3a4610ac@fortinet.com>

I'm porting BIOS on a AMD opteron system with broadcom HT2000 and HT1000
chipset.  I meet a problem when initilizing SATA device of HT1000.  The SATA
PHY status(0x40)always return a disable status(04), whatever I did with the
PHY reset ( set 0x48 bit 0 and clear it ).  Can anyone give me some advices?
Thanks in advance!

Best Regards,
Jianwei


*** Disclaimer: This message may contain privileged and/or confidential information.  If you have received this e-mail in error or are not the intended recipient, you may not use, copy, disseminate or distribute it; do not open any attachments, delete it immediately from your system and notify the sender promptly by e-mail that you have done so.  Thank you. ***




From yinghai.lu at amd.com  Fri Mar 31 04:08:04 2006
From: yinghai.lu at amd.com (Lu, Yinghai)
Date: Thu, 30 Mar 2006 18:08:04 -0800
Subject: [LinuxBIOS] broadcom HT1000 SATA PHY initializing
Message-ID: <6F7DA19D05F3CF40B890C7CA2DB13A4203094B56@ssvlexmb2.amd.com>

System BIOS or LinuxBIOS?

Did you base the code in the tree?

YH

-----Original Message-----
From: linuxbios-bounces at linuxbios.org
[mailto:linuxbios-bounces at linuxbios.org] On Behalf Of Jia Jianwei
Sent: Thursday, March 30, 2006 12:36 PM
To: linuxbios at linuxbios.org
Subject: [LinuxBIOS] broadcom HT1000 SATA PHY initializing

I'm porting BIOS on a AMD opteron system with broadcom HT2000 and HT1000
chipset.  I meet a problem when initilizing SATA device of HT1000.  The
SATA
PHY status(0x40)always return a disable status(04), whatever I did with
the
PHY reset ( set 0x48 bit 0 and clear it ).  Can anyone give me some
advices?
Thanks in advance!

Best Regards,
Jianwei


*** Disclaimer: This message may contain privileged and/or confidential
information.  If you have received this e-mail in error or are not the
intended recipient, you may not use, copy, disseminate or distribute it;
do not open any attachments, delete it immediately from your system and
notify the sender promptly by e-mail that you have done so.  Thank you.
***


-- 
linuxbios mailing list
linuxbios at linuxbios.org
http://www.openbios.org/mailman/listinfo/linuxbios





From yinghai.lu at amd.com  Fri Mar 31 04:13:58 2006
From: yinghai.lu at amd.com (Lu, Yinghai)
Date: Thu, 30 Mar 2006 18:13:58 -0800
Subject: [LinuxBIOS] CONFIG_LB_MEM_TOPK
Message-ID: <6F7DA19D05F3CF40B890C7CA2DB13A4203094B57@ssvlexmb2.amd.com>

I'm going to check in new cache_as_ram code. It is more solid and could
copy data from cache to ram. So we can pass some info from CAR stage to
RAM stage.

I want to change the default value for CONFIG_LB_MEM_TOPK from 1024 to
2048.
So I don't need to change every Opteron MB Config.lb...

Let me know if is ok to you.

YH




From stepan at openbios.org  Fri Mar 31 11:11:25 2006
From: stepan at openbios.org (Stefan Reinauer)
Date: Fri, 31 Mar 2006 11:11:25 +0200
Subject: [LinuxBIOS] CONFIG_LB_MEM_TOPK
In-Reply-To: <6F7DA19D05F3CF40B890C7CA2DB13A4203094B57@ssvlexmb2.amd.com>
References: <6F7DA19D05F3CF40B890C7CA2DB13A4203094B57@ssvlexmb2.amd.com>
Message-ID: <20060331091125.GA22390@openbios.org>

* Lu, Yinghai <yinghai.lu at amd.com> [060331 04:13]:
> I'm going to check in new cache_as_ram code. It is more solid and could
> copy data from cache to ram. So we can pass some info from CAR stage to
> RAM stage.
> 
> I want to change the default value for CONFIG_LB_MEM_TOPK from 1024 to
> 2048.
> So I don't need to change every Opteron MB Config.lb...

Sounds not too evil, every Opteron machine I saw has more than 2 MB RAM.
;)

Why is it necessary though? (just curious)


Stefan





From stepan at openbios.org  Fri Mar 31 12:39:31 2006
From: stepan at openbios.org (Stefan Reinauer)
Date: Fri, 31 Mar 2006 12:39:31 +0200
Subject: [LinuxBIOS] CONFIG_LB_MEM_TOPK
In-Reply-To: <6F7DA19D05F3CF40B890C7CA2DB13A4203094B57@ssvlexmb2.amd.com>
References: <6F7DA19D05F3CF40B890C7CA2DB13A4203094B57@ssvlexmb2.amd.com>
Message-ID: <20060331103931.GA26362@openbios.org>

* Lu, Yinghai <yinghai.lu at amd.com> [060331 04:13]:
> I'm going to check in new cache_as_ram code. It is more solid and could
> copy data from cache to ram. So we can pass some info from CAR stage to
> RAM stage.
> 
> I want to change the default value for CONFIG_LB_MEM_TOPK from 1024 to
> 2048.
> So I don't need to change every Opteron MB Config.lb...
> 
> Let me know if is ok to you.

Let me know where we can review that code before you go ahead and check
it in. It's not in the issue tracker yet, is it?

Stefan



From stepan at openbios.org  Fri Mar 31 12:50:24 2006
From: stepan at openbios.org (Stefan Reinauer)
Date: Fri, 31 Mar 2006 12:50:24 +0200
Subject: [LinuxBIOS] Issue Tracker Mails
Message-ID: <20060331105024.GB26362@openbios.org>

Hi,

to get rid of all the spam in the issue tracker it is no longer possible
to send mails to the tracker. 

Since we're going to switch over to bugzilla soon, this won't be a long
term restriction.

Stefan





From yinghai.lu at amd.com  Fri Mar 31 18:50:36 2006
From: yinghai.lu at amd.com (Lu, Yinghai)
Date: Fri, 31 Mar 2006 08:50:36 -0800
Subject: [LinuxBIOS] CONFIG_LB_MEM_TOPK
Message-ID: <6F7DA19D05F3CF40B890C7CA2DB13A4203094B58@ssvlexmb2.amd.com>

Some change in src/cpu/amd/car...

YH

-----Original Message-----
From: Stefan Reinauer [mailto:stepan at openbios.org] 
Sent: Friday, March 31, 2006 2:40 AM
To: Lu, Yinghai
Cc: Ronald G Minnich; Jason Schildt; linuxbios at linuxbios.org
Subject: Re: CONFIG_LB_MEM_TOPK

* Lu, Yinghai <yinghai.lu at amd.com> [060331 04:13]:
> I'm going to check in new cache_as_ram code. It is more solid and
could
> copy data from cache to ram. So we can pass some info from CAR stage
to
> RAM stage.
> 
> I want to change the default value for CONFIG_LB_MEM_TOPK from 1024 to
> 2048.
> So I don't need to change every Opteron MB Config.lb...
> 
> Let me know if is ok to you.

Let me know where we can review that code before you go ahead and check
it in. It's not in the issue tracker yet, is it?

Stefan





From stepan at openbios.org  Fri Mar 31 19:56:22 2006
From: stepan at openbios.org (Stefan Reinauer)
Date: Fri, 31 Mar 2006 19:56:22 +0200
Subject: [LinuxBIOS] CONFIG_LB_MEM_TOPK
In-Reply-To: <6F7DA19D05F3CF40B890C7CA2DB13A4203094B58@ssvlexmb2.amd.com>
References: <6F7DA19D05F3CF40B890C7CA2DB13A4203094B58@ssvlexmb2.amd.com>
Message-ID: <20060331175622.GA1375@openbios.org>

* Lu, Yinghai <yinghai.lu at amd.com> [060331 18:50]:
> Some change in src/cpu/amd/car...

Sorry, I must be blind. Still can't find it. What's the issue number?

Stefan




From JJia at Fortinet.com  Fri Mar 31 20:38:51 2006
From: JJia at Fortinet.com (Jia Jianwei)
Date: Fri, 31 Mar 2006 10:38:51 -0800
Subject: [LinuxBIOS] broadcom HT1000 SATA PHY initializing
References: <6F7DA19D05F3CF40B890C7CA2DB13A4203094B56@ssvlexmb2.amd.com>
Message-ID: <030b01c654f2$5b3fbb40$3a4610ac@fortinet.com>

I'm using LinuxBIOS to test it.  (Standard system BIOS seems linked an
option rom to do the initialization and working fine).

Jianwei

----- Original Message ----- 
From: "Lu, Yinghai" <yinghai.lu at amd.com>
To: "Jia Jianwei" <JJia at Fortinet.com>; <linuxbios at linuxbios.org>
Sent: Thursday, March 30, 2006 6:08 PM
Subject: RE: [LinuxBIOS] broadcom HT1000 SATA PHY initializing


> System BIOS or LinuxBIOS?
>
> Did you base the code in the tree?
>
> YH
>
> -----Original Message-----
> From: linuxbios-bounces at linuxbios.org
> [mailto:linuxbios-bounces at linuxbios.org] On Behalf Of Jia Jianwei
> Sent: Thursday, March 30, 2006 12:36 PM
> To: linuxbios at linuxbios.org
> Subject: [LinuxBIOS] broadcom HT1000 SATA PHY initializing
>
> I'm porting BIOS on a AMD opteron system with broadcom HT2000 and HT1000
> chipset.  I meet a problem when initilizing SATA device of HT1000.  The
> SATA
> PHY status(0x40)always return a disable status(04), whatever I did with
> the
> PHY reset ( set 0x48 bit 0 and clear it ).  Can anyone give me some
> advices?
> Thanks in advance!
>
> Best Regards,
> Jianwei
>
>
> *** Disclaimer: This message may contain privileged and/or confidential
> information.  If you have received this e-mail in error or are not the
> intended recipient, you may not use, copy, disseminate or distribute it;
> do not open any attachments, delete it immediately from your system and
> notify the sender promptly by e-mail that you have done so.  Thank you.
> ***
>
>
> -- 
> linuxbios mailing list
> linuxbios at linuxbios.org
> http://www.openbios.org/mailman/listinfo/linuxbios
>
>
>
>




From yinghai.lu at amd.com  Fri Mar 31 20:40:45 2006
From: yinghai.lu at amd.com (Lu, Yinghai)
Date: Fri, 31 Mar 2006 10:40:45 -0800
Subject: [LinuxBIOS] broadcom HT1000 SATA PHY initializing
Message-ID: <6F7DA19D05F3CF40B890C7CA2DB13A4203094B59@ssvlexmb2.amd.com>

You should be right.

When I was testing that on Broadcom BLAST ref board: STAT and IDE
doesn't work.

But on another MB (serverworks HT1000 based), IDE is working.

Maybe some magic bit in pci conf space need to set by option rom...

You could compare the pci conf dump between system bios and LinuxBIOS...

BTW, Can drop your funny signature in LinuxBIOS?

YH




From JJia at Fortinet.com  Fri Mar 31 20:52:48 2006
From: JJia at Fortinet.com (Jia Jianwei)
Date: Fri, 31 Mar 2006 10:52:48 -0800
Subject: [LinuxBIOS] broadcom HT1000 SATA PHY initializing
References: <6F7DA19D05F3CF40B890C7CA2DB13A4203094B59@ssvlexmb2.amd.com>
Message-ID: <031d01c654f4$4e3cd200$3a4610ac@fortinet.com>

Thank you very much!

If I find the solution, I'll submit a patch to you!

BTW, the funny signature is added by mail system, not controled by me. I
hate it.

Jianwei

----- Original Message ----- 
From: "Lu, Yinghai" <yinghai.lu at amd.com>
To: "Jia Jianwei" <JJia at Fortinet.com>; <linuxbios at linuxbios.org>
Sent: Friday, March 31, 2006 10:40 AM
Subject: RE: [LinuxBIOS] broadcom HT1000 SATA PHY initializing


> You should be right.
>
> When I was testing that on Broadcom BLAST ref board: STAT and IDE
> doesn't work.
>
> But on another MB (serverworks HT1000 based), IDE is working.
>
> Maybe some magic bit in pci conf space need to set by option rom...
>
> You could compare the pci conf dump between system bios and LinuxBIOS...
>
> BTW, Can drop your funny signature in LinuxBIOS?
>
> YH
>
>
>




From perh at t2data.se  Fri Mar 31 14:16:20 2006
From: perh at t2data.se (Per Hallsmark)
Date: Fri, 31 Mar 2006 14:16:20 +0200
Subject: [LinuxBIOS] Geode SC22000
Message-ID: <WorldClient-F200603311416.AA16200026@t2data.se>

Hello LB people,

First, a great thank for the quick boost I had from your project
in creating a special firmware for our project.

I've ported LB to a SC2200 based platform, NCG266 (you can see some
old photos at www.nano-system.com) The jump to the load just takes
a couple of secs instead of like a minute with the Insyde BIOS...

The LB base is svn ver 2171, I've got a 71K big patch for it.
How do I contribute it to LB tree?

Also during the learning and porting of LB, a couple of questions
popped up:

Q1: The source code files often include source files again instead
of like building object modules that are later linked together.
Why something like this? It seems odd to me as an perhaps oldschool
C programmer.

Q2: Why does the LB project need a special compiler?
I've done numberous of firmware stuff and ordinary gnu tools have a
good job so far.
Must admit though that these hasn't been x86 which of course has it
special boot mode, but there exist "standard" tools for that as well.
(RPM package dev86 for example)

Q3: Documentation...
I was perhaps a bit optimistic when I thought the LB port should
take one week, it was more like one month :-)
But more documentation could help here a lot, or are there docs
outside of linuxbios.org I've missed? Any work in progress here
or can I contribute to it somehow?


mvh Per Hallsmark

T2 Data