From pada at chemonline.de  Mon May  1 00:23:30 2006
From: pada at chemonline.de (Daniel Parthey)
Date: Mon, 1 May 2006 00:23:30 +0200
Subject: [LinuxBIOS] Epia ML 5000 VGA (Again!) -- Moving backwards,
	somehow.
In-Reply-To: <44544DE9.1050701@zyxod.com>
References: <44544DE9.1050701@zyxod.com>
Message-ID: <20060430222330.GA19676@daniel.localdomain>

Eric Poulsen schrieb:
> I went back to the "stock" LinuxBIOSv2, revision 2100, known to 
> work with the Epia M.  This particular revision worked for me, albeit 
> with the long delay at the beginning because of the firewire search.
> 
> Essentially, whenever, I add ...
> 
>     #VGA Console
>     option CONFIG_CONSOLE_VGA=1
>     option CONFIG_PCI_ROM_RUN=1
> 
> .... to the Config.lb, it doesn't work, giving the error below.
> 
> Any ideas?
> 
> --------------------------------------------------------------------
> 
> [...]
> VGA random fixup ...
> INSTALL REAL-MODE IDT
> DO THE VGA BIOS
> found VGA: vid=1106, did=3122
> rom base, size: fffc0000
> write_protect_vgabios
  ^^^^^^^^^^^^^^^^^^^^^
Did you change the line in mainboard.c from
 dev = dev_find_device(PCI_VENDOR_ID_VIA, 0x3123, 0);
to
 dev = dev_find_device(PCI_VENDOR_ID_VIA, PCI_DEVICE_ID_VIA_CLE266_VGA, 0);
in order to write-protect the vgabios correctly?

> bus/devfn = 0x100
> Unexpected Exception: 13 @ 10:000121c3 - Halting
> Code: 0 eflags: 00010012
> eax: 00000012 ebx: 00024530 ecx: 00023fa8 edx: 00000012
> edi: 00018a90 esi: ffff946b ebp: 00023f84 esp: 00023f84

Daniel.
-- 
Jabber: pada at jabber.ccc.de



From rminnich at lanl.gov  Mon May  1 00:36:03 2006
From: rminnich at lanl.gov (Ronald G Minnich)
Date: Sun, 30 Apr 2006 16:36:03 -0600
Subject: [LinuxBIOS] newbi questions for VIA EPIS MII6000E target
In-Reply-To: <Pine.LNX.4.63.0604302309070.5800@web.seicento.selfip.org>
References: <Pine.LNX.4.63.0604302309070.5800@web.seicento.selfip.org>
Message-ID: <44553BD3.7080607@lanl.gov>

lists at seicento.selfip.org wrote:
> Hi all ... I'm about to make my first attempt to boot my MII6000E from the 
> onboard CF adapter so pleas forgive my possibly stupid questions.
> 
> I have a few questions regarding this:
> VIA's fartboot firmware tells me that it's mandatory to use mkelfImage on 
         ^^^^^^^^
is this intentional :-)

> bothe kernel and initrd, is this also true for linuxBIOS ?

Yes. Claim is that fartboot is actually linuxbios; who knows?

> Even if vga bios is copied over from original flash will video be blank 
> untill kernel initializes the video card or will it be possible to see the 
> tipical "loading linux ......" and consequent tipical kernel messages on 
> video ?

if vga is enabled in linuxbios, you'll see all output.

> If the latter is possible would I need to avoid passing console to be 
> serial amongst the kernel options ?

yes.

> According to documentation on the linuxBIOS home
> http://www.linuxbios.org/index.php/Payloads
> the etherboot payload has bothe ide and net boot capabilities ... will 
> this let me boot from the onboard CF adapter ?

yes.

> What adjustments must I make to the EPIA-M-howto documentation to use the 
> etherboot payload ?

Someone else will have to answer that.

I can never get etherboot to build :-)

ron



From rminnich at lanl.gov  Mon May  1 00:37:06 2006
From: rminnich at lanl.gov (Ronald G Minnich)
Date: Sun, 30 Apr 2006 16:37:06 -0600
Subject: [LinuxBIOS] S2882 Video
In-Reply-To: <20060430075529.GA25145@coresystems.de>
References: <1901629097.20060429222851@e-tiger.net>
	<2ea3fae10604291421w20c4dc86w21a96828c59514d@mail.gmail.com>
	<97921176.20060429233758@e-tiger.net> <44543397.6080204@lanl.gov>
	<20060430075529.GA25145@coresystems.de>
Message-ID: <44553C12.10601@lanl.gov>

Stefan Reinauer wrote:
> * Ronald G Minnich <rminnich at lanl.gov> [060430 05:48]:
> 
>>Hidasi Jozsef wrote:
>>
>>>Hi!
>>>
>>> Thank you, but instead of this text it would be nicer to display
>>> everything is ok:) 
>>
>>
>>Agreed. That message SUCKS. I will accept patches :-)
> 
>  
> This is the code that prints the message in src/include/x86emu/x86emu.h
> 
> #ifdef  DEBUG
> #define HALT_SYS()      \
>         printk("halt_sys: file %s, line %d\n", __FILE__, __LINE__); \
>         X86EMU_halt_sys();
> #else
> #define HALT_SYS()      X86EMU_halt_sys()
> #endif
> 
> DEBUG is undefined in devices/emulator/x86emu/debug.h and never set in
> the emulator files.. any idea why the message is printed at all? 

so we know that vga emulation terminated correctly ...

ron



From stepan at coresystems.de  Mon May  1 02:39:18 2006
From: stepan at coresystems.de (Stefan Reinauer)
Date: Mon, 1 May 2006 02:39:18 +0200
Subject: [LinuxBIOS] S2882 Video
In-Reply-To: <44553C12.10601@lanl.gov>
References: <1901629097.20060429222851@e-tiger.net>
	<2ea3fae10604291421w20c4dc86w21a96828c59514d@mail.gmail.com>
	<97921176.20060429233758@e-tiger.net> <44543397.6080204@lanl.gov>
	<20060430075529.GA25145@coresystems.de> <44553C12.10601@lanl.gov>
Message-ID: <20060501003918.GB29175@coresystems.de>

* Ronald G Minnich <rminnich at lanl.gov> [060501 00:37]:
> >This is the code that prints the message in src/include/x86emu/x86emu.h
> >
> >#ifdef  DEBUG
> >#define HALT_SYS()      \
> >        printk("halt_sys: file %s, line %d\n", __FILE__, __LINE__); \
> >        X86EMU_halt_sys();
> >#else
> >#define HALT_SYS()      X86EMU_halt_sys()
> >#endif
> >
> >DEBUG is undefined in devices/emulator/x86emu/debug.h and never set in
> >the emulator files.. any idea why the message is printed at all? 
> 
> so we know that vga emulation terminated correctly ...
 
I agree that a message makes sense. I just wonder where DEBUG gest set
in this context. devices/emulator/x86emu/debug.h explicitly undefs DEBUG
so I'd assume the message would not be printed by default?!

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 yinghailu at gmail.com  Mon May  1 04:07:36 2006
From: yinghailu at gmail.com (yhlu)
Date: Sun, 30 Apr 2006 19:07:36 -0700
Subject: [LinuxBIOS] WORK! :) Power button question
In-Reply-To: <386809661.20060430220955@e-tiger.net>
References: <592068803.20060430001151@e-tiger.net> <445433CD.9080308@lanl.gov>
	<1085214046.20060430144337@e-tiger.net>
	<2ea3fae10604300921h68e77875mcedd0ee1c7caa530@mail.gmail.com>
	<1646875161.20060430182811@e-tiger.net>
	<2ea3fae10604301124n1c1a0f53yba734c1ab4752f08@mail.gmail.com>
	<386809661.20060430220955@e-tiger.net>
Message-ID: <2ea3fae10604301907q8ebe36fif037272a552b83eb@mail.gmail.com>

your iasl seems too new...

YH

On 4/30/06, Hidasi Jozsef <hidi at e-tiger.net> wrote:
> Hi!
>
> /usr/sbin/iasl -tc /src/LinuxBIOSv2/src/mainboard/tyan/s2882/dx/pci2.asl
>
> Intel ACPI Component Architecture
> ASL Optimizing Compiler version 20060421 [Apr 30 2006]
> Copyright (C) 2000 - 2006 Intel Corporation
> Supports ACPI Specification Revision 3.0a
>
> Segmentation fault
>
>
> any suggestions?
>
>
>
> Sunday, April 30, 2006, 8:24:08 PM, you wrote:
>
> > what is your Linux dist...? If it is suse, you can install the package
> > from the source disk...
>
> > YH
>
>
>
> --
> Best regards,
>  Hidasi                            mailto:hidi at e-tiger.net
>
>
> --
> linuxbios mailing list
> linuxbios at linuxbios.org
> http://www.openbios.org/mailman/listinfo/linuxbios
>
>
>



From eric at zyxod.com  Mon May  1 04:52:09 2006
From: eric at zyxod.com (Eric Poulsen)
Date: Sun, 30 Apr 2006 19:52:09 -0700
Subject: [LinuxBIOS] Epia ML 5000 VGA (Again!) -- Moving backwards,
	somehow.
In-Reply-To: <20060430222330.GA19676@daniel.localdomain>
References: <44544DE9.1050701@zyxod.com>
	<20060430222330.GA19676@daniel.localdomain>
Message-ID: <445577D9.6060005@zyxod.com>

Daniel,

mainboard.c already looks like this in src/mainboard/via/epia-m.  It 
seems to take care of both the $3122 and $3123 devices.

There are other weird things happening.  LB _does not_ compile the way 
it used to out-of-the-box, even for older revisions.  It gives me 
linking errors every time I try to enable VGA 
(CONFIG_CONSOLE_VGA,CONFIG_PCI_ROM_RUN), unless I increase the 
ROM_IMAGE_SIZE, as recommended by Stefan.  I figured maybe my payload 
was too large and pushing the image > $10000, so I recompiled filo with 
a bunch fewer options, and it was only 26K (vs 39K before), and it still 
won't link without increasing ROM_IMAGE_SIZE to $12000.  I'm not sure if 
this is related, but it is weird.  Can ROM_IMAGE_SIZE be changed w/o 
changing any of the other parameters?

Also, does anyone have a good explaination of:

ROM_SIZE (Appears to be total size of your rom chip)
ROM_IMAGE_SIZE (Size of this rom image, fallback or normal),  defaults 
to $10000 (64K)
ROM_SECTION_OFFSET=0x10000 ???
ROM_SECTION_SIZE=0x30000 ??? ROM section == total used by LB minus VGA 
rom size???





void write_protect_vgabios(void)
{
  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);
}

Daniel Parthey wrote:

>Eric Poulsen schrieb:
>  
>
>>I went back to the "stock" LinuxBIOSv2, revision 2100, known to 
>>work with the Epia M.  This particular revision worked for me, albeit 
>>with the long delay at the beginning because of the firewire search.
>>
>>Essentially, whenever, I add ...
>>
>>    #VGA Console
>>    option CONFIG_CONSOLE_VGA=1
>>    option CONFIG_PCI_ROM_RUN=1
>>
>>.... to the Config.lb, it doesn't work, giving the error below.
>>
>>Any ideas?
>>
>>--------------------------------------------------------------------
>>
>>[...]
>>VGA random fixup ...
>>INSTALL REAL-MODE IDT
>>DO THE VGA BIOS
>>found VGA: vid=1106, did=3122
>>rom base, size: fffc0000
>>write_protect_vgabios
>>    
>>
>  ^^^^^^^^^^^^^^^^^^^^^
>Did you change the line in mainboard.c from
> dev = dev_find_device(PCI_VENDOR_ID_VIA, 0x3123, 0);
>to
> dev = dev_find_device(PCI_VENDOR_ID_VIA, PCI_DEVICE_ID_VIA_CLE266_VGA, 0);
>in order to write-protect the vgabios correctly?
>
>  
>
>>bus/devfn = 0x100
>>Unexpected Exception: 13 @ 10:000121c3 - Halting
>>Code: 0 eflags: 00010012
>>eax: 00000012 ebx: 00024530 ecx: 00023fa8 edx: 00000012
>>edi: 00018a90 esi: ffff946b ebp: 00023f84 esp: 00023f84
>>    
>>
>
>Daniel.
>  
>




From rminnich at lanl.gov  Mon May  1 05:46:03 2006
From: rminnich at lanl.gov (Ronald G Minnich)
Date: Sun, 30 Apr 2006 21:46:03 -0600
Subject: [LinuxBIOS] Epia ML 5000 VGA (Again!) -- Moving backwards,
	somehow.
In-Reply-To: <445577D9.6060005@zyxod.com>
References: <44544DE9.1050701@zyxod.com>	<20060430222330.GA19676@daniel.localdomain>
	<445577D9.6060005@zyxod.com>
Message-ID: <4455847B.4030000@lanl.gov>

Eric Poulsen wrote:
> Daniel,
> 
> mainboard.c already looks like this in src/mainboard/via/epia-m.  It 
> seems to take care of both the $3122 and $3123 devices.
> 
> There are other weird things happening.  LB _does not_ compile the way 
> it used to out-of-the-box, even for older revisions.  It gives me 
> linking errors every time I try to enable VGA 
> (CONFIG_CONSOLE_VGA,CONFIG_PCI_ROM_RUN), unless I increase the 
> ROM_IMAGE_SIZE, as recommended by Stefan.  I figured maybe my payload 
> was too large and pushing the image > $10000, so I recompiled filo with 
> a bunch fewer options, and it was only 26K (vs 39K before), and it still 
> won't link without increasing ROM_IMAGE_SIZE to $12000.  I'm not sure if 
> this is related, but it is weird.  Can ROM_IMAGE_SIZE be changed w/o 
> changing any of the other parameters?
> 
> Also, does anyone have a good explaination of:
> 
> ROM_SIZE (Appears to be total size of your rom chip)
> ROM_IMAGE_SIZE (Size of this rom image, fallback or normal),  defaults 
> to $10000 (64K)
> ROM_SECTION_OFFSET=0x10000 ???
> ROM_SECTION_SIZE=0x30000 ??? ROM section == total used by LB minus VGA 
> rom size???

see my linux journal article on the web. I think that's where it is. 
There is a figure there that might clear it up.

Or I can send you the article directly.

ron



From eric at zyxod.com  Mon May  1 06:36:21 2006
From: eric at zyxod.com (Eric Poulsen)
Date: Sun, 30 Apr 2006 21:36:21 -0700
Subject: [LinuxBIOS] Ron's Linux Journal article
In-Reply-To: <4455847B.4030000@lanl.gov>
References: <44544DE9.1050701@zyxod.com>	<20060430222330.GA19676@daniel.localdomain>
	<445577D9.6060005@zyxod.com> <4455847B.4030000@lanl.gov>
Message-ID: <44559045.8000806@zyxod.com>

Found it, posting it to the list for the benefit of others:

"Porting LinuxBIOS to the AMD SC520: A Follow-up Report"
[This has the nifty diagram of how all the *_SIZE options work together]
http://www.linuxjournal.com/article/8310

"LinuxBIOS at Four"
http://www.linuxjournal.com/article/7170

Ronald G Minnich wrote:

>>
>> Also, does anyone have a good explaination of:
>>
>> ROM_SIZE (Appears to be total size of your rom chip)
>> ROM_IMAGE_SIZE (Size of this rom image, fallback or normal),  
>> defaults to $10000 (64K)
>> ROM_SECTION_OFFSET=0x10000 ???
>> ROM_SECTION_SIZE=0x30000 ??? ROM section == total used by LB minus 
>> VGA rom size???
>
>
> see my linux journal article on the web. I think that's where it is. 
> There is a figure there that might clear it up.
>
> Or I can send you the article directly.
>
> ron
>




From eric at zyxod.com  Mon May  1 06:45:35 2006
From: eric at zyxod.com (Eric Poulsen)
Date: Sun, 30 Apr 2006 21:45:35 -0700
Subject: [LinuxBIOS] Solved: Makefile weirdness (was: Epia ML 5000 VGA
 (Again!) -- Moving backwards, somehow.)
In-Reply-To: <44544DE9.1050701@zyxod.com>
References: <44544DE9.1050701@zyxod.com>
Message-ID: <4455926F.50007@zyxod.com>

Okay, I got it to work again.  This is weird, but I figured out what the
issue is.  I think the build system for LB (at least for the Epia-M
branch) is bad.  I don't have any experience with romcc or building
BIOSes, but I do have quite a bit of experience with C,C++, and using
makefiles -- something seems very wrong here, especially when you look
at the details of the two build processes shown below.  IMHO, "make
clean" should set you back to the beginning (as it seems to),  and a
compile after that should fix any weirdnesses with linking.

Just in case it's not clear, in both examples below, there are NO "real"
code changes between them, only configuration changes.  Also, this is
with my own Epia-ML branch (derived from Epia-M) -- the only difference
is that I removed the ieee1394 init code in auto.c and edited the
Config.lb for the mainboard so that it doesn't init the floppy and the
CF card reader, which don't exist on the ML.  I was having the exact
same issues with the out-of-the-box Epia-M branch. When I built it (both
Epia-M and Epia-ML branches) successfully in the past, I _never_ used
make clean because I figured buildtarget would fix any issues,
especially since a 'make' after 'buildtarget' resulted in recompilation
of several files.

In short, my recent use of 'make clean' seems to be hosing the process.

This _DOES NOT WORK_ (but it should):

(pseudocode -- not literal)
]Set CONFIG_CONSOLE_VGA=1, CONFIG_PCI_ROM_RUN=1 in Config.lb
]buildtarget via/epia-m
]cd via/epia-m/epia-m
]make clean
]make
][Bunches of link errors because of overlapping sections]
|set ROM_IMAGE_SIZE to 0x12000 (previously 0x10000), as per Stefan's
suggestion.
buildtarget
make clean
make
[successful compile]
cat vga_bios linuxbios.rom > lb.rom
flashrom
[Reboot]
Crash, exception 13 just after vga write protect

This _DOES WORK_

Start with default epia-m config.lb
buildtarget
[compiles clean, but no vga options on -- If I were to flash and reboot,
this would work as-is, sans VGA]
Edit Config.lb add CONFIG_CONSOLE_VGA=1
buildtarget
make [_IMPORTANT_ -- NOTICE THERE IS NO 'make clean' LINE!]
[compiles clean]
Edit Config.lb add CONFIG_PCI_ROM_RUN=1
buildtarget
make [_IMPORTANT_ -- NOTICE THERE IS NO 'make clean' LINE!]
[compiles clean]
cat vga_bios linuxbios.rom
flashrom
[reboot]
[Everything works -- boots, VGA works, etc. ]
[Important thing to note about the above is that the ROM_IMAGE_SIZE _was
not_ increased]




Eric Poulsen wrote:

> I've been trying to accomplish several things:
> 
> 1) LB on Via Epia ML 5000 2) VGA working 3) Figuring out weird boot
> errors that seem to be "fixed" by the factory BIOS.  Running
> memtest86+ under LB.
> 
> I _was_ on step 3, but in the course of events, I went back to step
> 2. VGA is now NOT working again, but with a different error; see
> below.
> 
> Since I was messing around with making an ML tree, adding a bit of 
> custom stuff, and removing initializations for devices that don't
> exist on the ML (floppy, CF reader), I figured I had done something
> wrong.
> 
> Soooo, I went back to the "stock" LinuxBIOSv2, revision 2100, known
> to work with the Epia M.  This particular revision worked for me,
> albeit with the long delay at the beginning because of the firewire
> search.
> 
> Essentially, whenever, I add ...
> 
> #VGA Console option CONFIG_CONSOLE_VGA=1 option CONFIG_PCI_ROM_RUN=1
> 
> ... to the Config.lb, it doesn't work, giving the error below.
> 
> Mysteriously, my "weird boot crashes that are fixed by factory CMOS"
>  problems aren't exhibiting themselves.
> 
> Unfortunately, I cannot run memtest86 under LB without VGA.
> 
> Any ideas?
> 
> --------------------------------------------------------------------
> 
> 0
> 
> LinuxBIOS-1.1.8.0Fallback Sat Apr 29 22:12:48 PDT 2006 starting... 
> Enabling mainboard devices Enabling shadow ram vt8623 init starting 
> Detecting Memory Number of Banks 04 Number of Rows 0d Priamry DRAM
> width08 No Columns 0a MA type e0 Bank 0 (*16 Mb) 10 No Physical Banks
> 01 Total Memory (*16 Mb) 10 CAS Supported 2 2.5 3 Cycle time at CL X
> (nS)50 Cycle time at CL X-0.5 (nS)60 Cycle time at CL X-1   (nS)75 
> Starting at CAS 3 We can do CAS 2.5 We can do CAS 2 tRP 48 tRCD 48 
> tRAS 28 Low Bond 00  High Bondbe  Setting DQS delay7evt8623 done 
> 00:06 11 23 31 06 00 30 22 00 00 00 06 00 00 00 00 10:08 00 00 d0 00
> 00 00 00 00 00 00 00 00 00 00 00 20:00 00 00 00 00 00 00 00 00 00 00
> 00 00 00 00 00 30:00 00 00 00 a0 00 00 00 00 00 00 00 00 00 00 00 
> 40:00 18 88 80 82 44 00 00 18 99 88 80 82 44 00 00 50:c8 de cf 88 e0
> 07 00 00 e0 00 10 10 10 10 00 00 60:02 ff 00 30 d6 32 01 2a 42 2d 43
> 58 00 44 00 00 70:82 48 00 01 01 08 50 00 01 00 00 00 00 00 00 02 
> 80:0f 65 00 00 80 00 00 00 02 00 00 00 00 00 00 00 90:00 00 00 00 00
> 00 00 00 00 00 00 00 00 00 00 00 a0:02 c0 20 00 07 02 00 1f 04 00 00
> 00 2f 02 04 00 b0:00 00 00 00 80 00 00 00 88 00 00 00 00 00 00 00 
> c0:01 00 02 00 00 00 00 00 00 00 00 00 00 00 00 00 d0:00 00 00 00 00
> 00 00 00 00 00 00 00 00 00 00 00 e0:00 dd 00 00 00 00 01 00 40 00 00
> 00 00 00 00 00 f0:00 00 00 00 00 00 12 13 00 00 00 00 00 00 00 00 AGP
>  Doing MTRR init. Copying LinuxBIOS to ram. Jumping to LinuxBIOS. 
> LinuxBIOS-1.1.8.0Fallback Sat Apr 29 22:12:48 PDT 2006 booting... 
> clocks_per_usec: 838 Enumerating buses... Finding PCI configuration
> type. PCI: Using configuration type 1 PCI_DOMAIN: 0000 enabled 
> APIC_CLUSTER: 0 enabled PCI: pci_scan_bus for bus 0 PCI: 00:00.0
> [1106/3123] enabled PCI: 00:01.0 [1106/b091] enabled Disabling static
> device: PCI: 00:0a.0 Disabling static device: PCI: 00:0a.1 In
> vt8235_enable 1106 3038. PCI: 00:10.0 [1106/3038] enabled In
> vt8235_enable 1106 3038. PCI: 00:10.1 [1106/3038] enabled In
> vt8235_enable 1106 3038. PCI: 00:10.2 [1106/3038] enabled In
> vt8235_enable 1106 3104. PCI: 00:10.3 [1106/3104] enabled In
> vt8235_enable 1106 3177. Initialising Devices PCI: 00:11.0
> [1106/3177] enabled In vt8235_enable 1106 0571. PCI: 00:11.1
> [1106/0571] enabled In vt8235_enable 1106 3059. PCI: 00:11.5
> [1106/3059] enabled In vt8235_enable ffff ffff. In vt8235_enable 1106
> 3065. PCI: 00:12.0 [1106/3065] enabled PCI: pci_scan_bus for bus 1 
> PCI: 01:00.0 [1106/3122] enabled PCI: pci_scan_bus returning with
> max=01 vt1211 enabling PNP devices. PNP: 002e.0 enabled vt1211
> enabling PNP devices. PNP: 002e.1 enabled vt1211 enabling PNP
> devices. PNP: 002e.2 enabled vt1211 enabling PNP devices. PNP: 002e.3
> enabled vt1211 enabling PNP devices. PNP: 002e.b enabled PCI:
> pci_scan_bus returning with max=01 done Allocating resources... 
> Reading resources... Done reading resources. Allocating VGA resource
> PCI: 01:00.0 Setting PCI_BRIDGE_CTL_VGA for bridge PCI: 00:01.0 
> Setting PCI_BRIDGE_CTL_VGA for bridge PCI_DOMAIN: 0000 Setting
> PCI_BRIDGE_CTL_VGA for bridge Root Device Setting resources... I
> would set ram size to 0x40000 Kbytes PCI: 00:10.0 20 <- [0x0000001800
> - 0x000000181f] io PCI: 00:10.1 20 <- [0x0000001820 - 0x000000183f]
> io PCI: 00:10.2 20 <- [0x0000001840 - 0x000000185f] io PCI: 00:10.3
> 10 <- [0x00febff000 - 0x00febff0ff] mem PNP: 002e.0 60 <-
> [0x00000003f0 - 0x00000003f7] io PNP: 002e.0 70 <- [0x0000000006 -
> 0x0000000006] irq PNP: 002e.0 74 <- [0x0000000002 - 0x0000000002] drq
>  PNP: 002e.1 60 <- [0x0000000378 - 0x000000037f] io PNP: 002e.1 70 <-
> [0x0000000007 - 0x0000000007] irq PNP: 002e.1 74 <- [0x0000000003 -
> 0x0000000003] drq 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 PNP: 002e.b 60 <- [0x000000ec00 - 0x000000ecff] io 
> PCI: 00:11.1 20 <- [0x0000001860 - 0x000000186f] io PCI: 00:11.5 10
> <- [0x0000001000 - 0x00000010ff] io PCI: 00:12.0 10 <- [0x0000001400
> - 0x00000014ff] io PCI: 00:12.0 14 <- [0x00fec00000 - 0x00fec000ff]
> mem Done setting resources. Done allocating resources. Enabling
> resourcess... PCI: 00:00.0 cmd <- 146 PCI: 00:01.0 bridge ctrl <-
> 000f PCI: 00:01.0 cmd <- 147 PCI: 01:00.0 cmd <- 143 PCI: 00:10.0
> subsystem <- 00/00 PCI: 00:10.0 cmd <- 141 PCI: 00:10.1 subsystem <-
> 00/00 PCI: 00:10.1 cmd <- 141 PCI: 00:10.2 subsystem <- 00/00 PCI:
> 00:10.2 cmd <- 141 PCI: 00:10.3 subsystem <- 00/00 PCI: 00:10.3 cmd
> <- 142 PCI: 00:11.0 cmd <- 147 PNP: 002e.0 - enabling PNP: 002e.1 -
> enabling PNP: 002e.2 - enabling PNP: 002e.3 - enabling PNP: 002e.b -
> enabling PCI: 00:11.1 cmd <- 147 PCI: 00:11.5 subsystem <- 00/00 PCI:
> 00:11.5 cmd <- 141 PCI: 00:12.0 cmd <- 1c3 done. Initializing
> devices... Root Device init PCI: 00:10.0 init PCI: 00:10.1 init PCI:
> 00:10.2 init PCI: 00:10.3 init PCI: 00:11.0 init vt8235 init RTC Init
>  Invalid CMOS LB checksum pci_routing_fixup: dev is 0001ad40 setting
> firewire setting usb Assigning IRQ 5 to 0:10.0 Readback = 5 
> pci_level_irq: lower order bits are wrong: want 0x0, got 0x20 
> Assigning IRQ 9 to 0:10.1 Readback = 9 pci_level_irq: lower order
> bits are wrong: want 0x0, got 0x20 Assigning IRQ 9 to 0:10.2 Readback
> = 9 pci_level_irq: lower order bits are wrong: want 0x0, got 0x20 
> Assigning IRQ 5 to 0:10.3 Readback = 5 pci_level_irq: lower order
> bits are wrong: want 0x0, got 0x20 setting vt8235 Assigning IRQ 5 to
> 0:11.1 Readback = 5 pci_level_irq: lower order bits are wrong: want
> 0x0, got 0x20 Assigning IRQ 9 to 0:11.5 Readback = 9 pci_level_irq:
> lower order bits are wrong: want 0x0, got 0x20 setting ethernet 
> Assigning IRQ 5 to 0:12.0 Readback = 5 pci_level_irq: lower order
> bits are wrong: want 0x0, got 0x20 setting vga Assigning IRQ 5 to
> 1:0.0 Readback = 5 pci_level_irq: lower order bits are wrong: want
> 0x0, got 0x20 setting pci slot setting cardbus slot setting riser
> slot PNP: 002e.0 init PNP: 002e.1 init PNP: 002e.2 init PNP: 002e.3
> init PNP: 002e.b init PCI: 00:11.1 init Enabling VIA IDE. ide_init:
> enabling compatibility IDE addresses enables in reg 0x42 0x0 enables
> in reg 0x42 read back as 0x0 enables in reg 0x40 0x13 enables in reg
> 0x40 read back as 0x13 enables in reg 0x9 0x8a enables in reg 0x9
> read back as 0x8a command in reg 0x4 0x7 command in reg 0x4 reads
> back as 0x7 PCI: 00:11.5 init PCI: 00:12.0 init Configuring VIA Rhine
> LAN APIC_CLUSTER: 0 init Initializing CPU #0 CPU: vendor Centaur
> device 673 Enabling cache
> 
> Setting fixed MTRRs(0-88) type: UC Setting fixed MTRRs(0-16) Type: WB
>  Setting fixed MTRRs(24-88) Type: WB DONE fixed MTRRs Setting
> variable MTRR 0, base:    0MB, range:  128MB, type WB Setting
> variable MTRR 1, base:  128MB, range:   64MB, type WB Setting
> variable MTRR 2, base:  192MB, range:   32MB, type WB DONE variable
> MTRRs Clear out the extra MTRR's
> 
> MTRR check Fixed MTRRs   : Enabled Variable MTRRs: Enabled
> 
> Disabling local apic...done. CPU #0 Initialized PCI: 00:00.0 init 
> VT8623 random fixup ... Frame buffer at d0000000 PCI: 00:01.0 init 
> VT8623 AGP random fixup ... PCI: 01:00.0 init VGA random fixup ... 
> INSTALL REAL-MODE IDT DO THE VGA BIOS found VGA: vid=1106, did=3122 
> rom base, size: fffc0000 write_protect_vgabios bus/devfn = 0x100 
> Unexpected Exception: 13 @ 10:000121c3 - Halting Code: 0 eflags:
> 00010012 eax: 00000012 ebx: 00024530 ecx: 00023fa8 edx: 00000012 edi:
> 00018a90 esi: ffff946b ebp: 00023f84 esp: 00023f84
> 
> 
> 
> 





From chris at suehsi.de  Mon May  1 11:13:44 2006
From: chris at suehsi.de (=?ISO-8859-1?Q?Christian_S=FChs?=)
Date: Mon, 01 May 2006 11:13:44 +0200
Subject: [LinuxBIOS] MB1030 / 3036 VGA comes up :D
In-Reply-To: <8a0c36780604301419y7f9b8045ie57b8f19bdeb6e2b@mail.gmail.com>
References: <0E81348C5627674A9C0061413EBFF5F74F4442@SAUSEXMB2.amd.com>	
	<20060428084154.GA26438@coresystems.de>	
	<8a0c36780604280849l2fa2cb32va9f5581f6dbf749e@mail.gmail.com>	
	<4454A226.3020108@suehsi.de>
	<20060430103923.GA19323@coresystems.de>	
	<4454C416.4040906@suehsi.de>
	<8a0c36780604301419y7f9b8045ie57b8f19bdeb6e2b@mail.gmail.com>
Message-ID: <4455D148.1050202@suehsi.de>


>>
>> Yeah, but I can't get a point to start :D I'm not sure what we need.
> 
> 
> Now you know why I haven't done it yet.  Its a little more than just a
> diff of the trees.

;)

> 
>> The inTree stuff based on X.org?
> 
> 
> The in-tree stuf is based on the ./util/vgabios stuff which came from
> xfree86 long ago.  The X.org fork should not be that much different
> than the xfree86 stuff.  The stuff in-tree has the directory structure
> cleaned up so its more sane.

Yeah, the X.org version based on an older xfree86 one.

> 
> Rather than diff the in-tree to the X.org or xfree86 I would start by
> diffing the stuff in util/vgabios/x86emu first.  That will let you see
> what has been introduced into the X* stuff.  I would then fork a copy
> of vgabios and test all the updates.  Then when you understand what
> changes were made you can try to roll them into the in-tree.

I was a little confused about some functions, which are not declared in 
the header files and also not present in the orginal :D
However, than I have found the calls somewhere in the LB stuff :D
Furthermore, it seems that somebody has changed a few diffs to the 
inTree version, but not all.

The rest of changes are not very interessting. i.e in ops.c all 
functions are static, now.

> 
> Chris, please disable all your current emu debug stuff and then apply
> this patch and send the output.
> This should show the timer IO accesses but not  all the other stuff to
> keep the noise level down

Thanks, I will try this today.

chris



From chris at suehsi.de  Mon May  1 12:23:38 2006
From: chris at suehsi.de (=?ISO-8859-1?Q?Christian_S=FChs?=)
Date: Mon, 01 May 2006 12:23:38 +0200
Subject: [LinuxBIOS] MB1030 / 3036 VGA comes up :D
In-Reply-To: <8a0c36780604301419y7f9b8045ie57b8f19bdeb6e2b@mail.gmail.com>
References: <0E81348C5627674A9C0061413EBFF5F74F4442@SAUSEXMB2.amd.com>	
	<20060428084154.GA26438@coresystems.de>	
	<8a0c36780604280849l2fa2cb32va9f5581f6dbf749e@mail.gmail.com>	
	<4454A226.3020108@suehsi.de>
	<20060430103923.GA19323@coresystems.de>	
	<4454C416.4040906@suehsi.de>
	<8a0c36780604301419y7f9b8045ie57b8f19bdeb6e2b@mail.gmail.com>
Message-ID: <4455E1AA.7070902@suehsi.de>


> 
> Chris, please disable all your current emu debug stuff and then apply
> this patch and send the output.
> This should show the timer IO accesses but not  all the other stuff to
> keep the noise level down
> .

Sorry, but there is no more output with the applied patch.

chris



From chris at suehsi.de  Mon May  1 13:21:01 2006
From: chris at suehsi.de (=?ISO-8859-1?Q?Christian_S=FChs?=)
Date: Mon, 01 May 2006 13:21:01 +0200
Subject: [LinuxBIOS] MB1030 / 3036 VGA comes up :D
In-Reply-To: <4455E1AA.7070902@suehsi.de>
References: <0E81348C5627674A9C0061413EBFF5F74F4442@SAUSEXMB2.amd.com>		<20060428084154.GA26438@coresystems.de>		<8a0c36780604280849l2fa2cb32va9f5581f6dbf749e@mail.gmail.com>		<4454A226.3020108@suehsi.de>	<20060430103923.GA19323@coresystems.de>		<4454C416.4040906@suehsi.de>	<8a0c36780604301419y7f9b8045ie57b8f19bdeb6e2b@mail.gmail.com>
	<4455E1AA.7070902@suehsi.de>
Message-ID: <4455EF1D.9060500@suehsi.de>

Christian S?hs schrieb:
>>Chris, please disable all your current emu debug stuff and then apply
>>this patch and send the output.
>>This should show the timer IO accesses but not  all the other stuff to
>>keep the noise level down
>>.
> 
> 
> Sorry, but there is no more output with the applied patch.
> 
> chris
> 

I have forgotten to post the results for changing BC_XMAP_1 values.

BC_XMAP_2 / 3 are set to 0x77777777

first I have tried the AMD preffered values:
The emulatur is entered, machine seems to hang. There is no more output 
after entering.


After that I have enabled the whole video RAM section A0000 - BFFFF as 
read/write/cache 0x07070067:
I have also the long delay by vga initializing, but after upcoming there 
are only unreadable characters on the screen.

Now I also think, that there is a problem with the emu and my board.

chris




From hidi at e-tiger.net  Mon May  1 12:36:59 2006
From: hidi at e-tiger.net (Hidasi Jozsef)
Date: Mon, 1 May 2006 12:36:59 +0200
Subject: [LinuxBIOS] Slow kernel loading?
Message-ID: <1347456839.20060501123659@e-tiger.net>

 Hi List!

 Yesterday I've manged some kind of ACPI into my S2882 after iasl
 segmentation faults I've dumped the original DSTC ant it compiles
 cleanly for now. BUT, is it normal when I load a kernel via network
 the decompression takes about minutes? So etherboot says Done and I
 have to wait a lot to boot the kernel, THERE'S NO OUTPUT AT ALL TILL
 THAT!

  

-- 
Best regards,
 Hidasi                          mailto:hidi at e-tiger.net
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 456 bytes
Desc: not available
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20060501/51c9a50f/attachment.sig>

From smithbone at gmail.com  Mon May  1 16:06:30 2006
From: smithbone at gmail.com (Richard Smith)
Date: Mon, 1 May 2006 09:06:30 -0500
Subject: [LinuxBIOS] MB1030 / 3036 VGA comes up :D
In-Reply-To: <4455E1AA.7070902@suehsi.de>
References: <0E81348C5627674A9C0061413EBFF5F74F4442@SAUSEXMB2.amd.com>
	<20060428084154.GA26438@coresystems.de>
	<8a0c36780604280849l2fa2cb32va9f5581f6dbf749e@mail.gmail.com>
	<4454A226.3020108@suehsi.de> <20060430103923.GA19323@coresystems.de>
	<4454C416.4040906@suehsi.de>
	<8a0c36780604301419y7f9b8045ie57b8f19bdeb6e2b@mail.gmail.com>
	<4455E1AA.7070902@suehsi.de>
Message-ID: <8a0c36780605010706m2bed1a6eja546e5b941f46c1a@mail.gmail.com>

On 5/1/06, Christian S?hs <chris at suehsi.de> wrote:

> > Chris, please disable all your current emu debug stuff and then apply
> > this patch and send the output.
> > This should show the timer IO accesses but not  all the other stuff to
> > keep the noise level down
> > .
>
> Sorry, but there is no more output with the applied patch.

Hmmm... That seems doubtful.  Did I screw up the patch somehow?  If
you look back through some of your debug logs do you see any IO to
ports 0x40-0x43 or 0x50-53?

--
Richard A. Smith



From lists at seicento.selfip.org  Mon May  1 16:22:58 2006
From: lists at seicento.selfip.org (lists at seicento.selfip.org)
Date: Mon, 1 May 2006 16:22:58 +0200 (CEST)
Subject: [LinuxBIOS] Another newbi question
Message-ID: <Pine.LNX.4.63.0605011606340.11308@web.seicento.selfip.org>

I see that flash_rom has the capability to read/write AMD AM-29F040B which 
is a 512Kbyte device and I've been able to read and write it from my 
motherboard (EPIA MII6000E). I was wondering if :
I can use the increased flash size to do anithing usefull ?
Could it be possible to use the extra space to have multiple payloads and 
have a choice as to which one to use ? (giving you the possibility to boot 
from disk, cdrom,floppy and onboard CF adapter maybe)

A few years ago I got etherboot working from the eprom on a NIC, allowiing 
me to remove the nic and get the machine to do normal boot with the 
original bios, would it be possible to do the same thing with linuxBIOS ?
this would let me do some attempts without having to buy any bios savior 
and whitout having to replace the flash in a really unconfortable 
position.

Regards
David Rao



From ward at gnu.org  Mon May  1 17:55:45 2006
From: ward at gnu.org (Ward Vandewege)
Date: Mon, 1 May 2006 11:55:45 -0400
Subject: [LinuxBIOS] etherboot/filo + sata startup timing
In-Reply-To: <20060428231617.GA28043@coresystems.de>
References: <20060424220147.GA26709@io.pong.be> <444D4AED.3020805@lanl.gov>
	<20060424222144.GA17934@coresystems.de>
	<20060424222501.GC27028@io.pong.be>
	<20060428231617.GA28043@coresystems.de>
Message-ID: <20060501155545.GA3652@io.pong.be>

Hi Stefan,

On Sat, Apr 29, 2006 at 01:16:17AM +0200, Stefan Reinauer wrote:
> The latest Subversion revision at
> 
>    svn://openbios.org/filo/trunk/filo-0.5
> 
> should have working S-ATA. I have no S-ATA here so I could not test it.
> It's the version that also comes with the GRUB user interface.
> 
> It still lacks two things:
> 
>  - reading syslinux.cfg from cdroms/dvds to allow really easy CD booting
>  - zelf support

Not sure what happened, but it seems we're not 100% there yet. I've attached
a boot log, and my filo Config file. It hangs after saying 'IDE channel 2
not found'.

I wonder if this is because it ignored (!) the AUTOBOOT_DELAY, which would
mean the SATA drives would not be fully ready yet. This was a cold boot.

Suggestions?
Ward.

-- 
Ward Vandewege <ward at fsf.org>
Free Software Foundation - Senior System Administrator
-------------- next part --------------
LinuxBIOS-1.1.8_s2881_Fallback Mon May  1 11:03:27 EDT 2006 starting...
(0,1) link=00
(1,0) link=00
02 nodes initialized.
SBLink=02
NC node|link=02
ht reset -


LinuxBIOS-1.1.8_s2881_Fallback Mon May  1 11:03:27 EDT 2006 starting...
(0,1) link=00
(1,0) link=00
02 nodes initialized.
SBLink=02
NC node|link=02
Ram1.00
Ram1.01
Ram2.00
Ram2.01
Ram3
Initializing memory:  done
Initializing memory:  done
Ram4
v_esp=000cfd4c
testx = 5a5a5a5a
Copying data from cache to ram -- switching to use ram as stack... Done
testx = 5a5a5a5a
Disabling cache as ram now 
Clearing initial memory region: Done
Copying LinuxBIOS to ram.
src=fffe0004
dst=00004000
linxbios_ram.bin length = 00019770
Jumping to LinuxBIOS.
LinuxBIOS-1.1.8_s2881_Fallback Mon May  1 11:03:27 EDT 2006 booting...
Enumerating buses...
APIC_CLUSTER: 0 enabled
PCI_DOMAIN: 0000 enabled
  PCI: 00:18.3 siblings=1
CPU: APIC: 00 enabled
CPU: APIC: 01 enabled
PCI: 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=1
CPU: APIC: 02 enabled
CPU: APIC: 03 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: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: pci_scan_bus for bus 3
PCI: pci_scan_bus returning with max=03
PCI: 03: 133MHz PCI-X
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 enabled
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 1c <- [0x00fffff000 - 0x00ffffefff] bus 2 io
PCI: 01:01.0 24 <- [0xfffffffffff00000 - 0xffffffffffefffff] bus 2 prefmem
PCI: 01:03.0 24 <- [0x00fff00000 - 0x00ffefffff] bus 4 prefmem
Done reading resources.
Setting resources...
PCI: 00:18.0 1ba <- [0x00fd300000 - 0x00fd2fffff] prefmem <node 0 link 2>
PCI: 00:18.0 1c2 <- [0x0000001000 - 0x0000002fff] io <node 0 link 2>
PCI: 00:18.0 1b2 <- [0x00fc000000 - 0x00fd2fffff] mem <node 0 link 2>
PCI: 01:01.0 20 <- [0x00fd100000 - 0x00fd1fffff] bus 2 mem
PCI: 02:09.0 10 <- [0x00fd100000 - 0x00fd10ffff] mem64
PCI: 02:09.0 18 <- [0x00fd110000 - 0x00fd11ffff] mem64
PCI: 02:09.1 10 <- [0x00fd120000 - 0x00fd12ffff] mem64
PCI: 02:09.1 18 <- [0x00fd130000 - 0x00fd13ffff] mem64
PCI: 01:01.1 10 <- [0x00fd200000 - 0x00fd200fff] mem64
PCI: 01:02.1 10 <- [0x00fd201000 - 0x00fd201fff] mem64
PCI: 01:03.0 1c <- [0x0000001000 - 0x0000001fff] bus 4 io
PCI: 01:03.0 20 <- [0x00fc000000 - 0x00fd0fffff] bus 4 mem
PCI: 04:00.0 10 <- [0x00fd000000 - 0x00fd000fff] mem
PCI: 04:00.1 10 <- [0x00fd001000 - 0x00fd001fff] mem
PCI: 04:05.0 10 <- [0x0000001410 - 0x0000001417] io
PCI: 04:05.0 14 <- [0x0000001430 - 0x0000001433] io
PCI: 04:05.0 18 <- [0x0000001420 - 0x0000001427] io
PCI: 04:05.0 1c <- [0x0000001440 - 0x0000001443] io
PCI: 04:05.0 20 <- [0x0000001400 - 0x000000140f] io
PCI: 04:05.0 24 <- [0x00fd003000 - 0x00fd0033ff] mem
PCI: 04:06.0 10 <- [0x00fc000000 - 0x00fcffffff] mem
PCI: 04:06.0 14 <- [0x0000001000 - 0x00000010ff] io
PCI: 04:06.0 18 <- [0x00fd002000 - 0x00fd002fff] 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.3 60 <- [0x00000002f8 - 0x00000002ff] io
PNP: 002e.3 70 <- [0x0000000003 - 0x0000000003] 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 <- [0x0000002420 - 0x000000242f] io
PCI: 01:04.2 10 <- [0x0000002400 - 0x000000241f] io
PCI: 01:04.3 58 <- [0x0000002000 - 0x00000020ff] io
PCI: 00:18.3 94 <- [0x00f8000000 - 0x00fbffffff] mem <gart>
PCI: 00:19.3 94 <- [0x00f8000000 - 0x00fbffffff] mem <gart>
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 <- 146
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.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 20f12
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: 4096MB, type WB
Setting variable MTRR 1, base: 4096MB, range: 1024MB, type WB
Setting variable MTRR 2, base: 3072MB, range: 1024MB, type UC
DONE variable MTRRs
Clear out the extra MTRR's

MTRR check
Fixed MTRRs   : Enabled
Variable MTRRs: Enabled

microcode: equivalent processor rev id  = 0x0210, patch id = 0x00000000
microcode: patch id that want to apply= 0x0000004d
microcode: updated to patch id = 0x0000004d  success
Setting up local apic... apic_id: 0 done.
Clearing memory 2048K - 2097152K: ------------------------------- done
CPU #0 Initialized
start_eip=0x00010000
Initializing CPU #1
CPU: vendor AMD device 20f12
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: 4096MB, type WB
Setting variable MTRR 1, base: 4096MB, range: 1024MB, type WB
Setting variable MTRR 2, base: 3072MB, range: 1024MB, type UC
DONE variable MTRRs
Clear out the extra MTRR's

MTRR check
Fixed MTRRs   : Enabled
Variable MTRRs: Enabled

microcode: equivalent processor rev id  = 0x0210, patch id = 0x00000000
microcode: patch id that want to apply= 0x0000004d
microcode: updated to patch id = 0x0000004d  success
Setting up local apic... apic_id: 1 done.
CPU #1 Initialized
start_eip=0x00010000
Initializing CPU #2
CPU: vendor AMD device 20f12
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: 4096MB, type WB
Setting variable MTRR 1, base: 4096MB, range: 1024MB, type WB
Setting variable MTRR 2, base: 3072MB, range: 1024MB, type UC
DONE variable MTRRs
Clear out the extra MTRR's

MTRR check
Fixed MTRRs   : Enabled
Variable MTRRs: Enabled

microcode: equivalent processor rev id  = 0x0210, patch id = 0x00000000
microcode: patch id that want to apply= 0x0000004d
microcode: updated to patch id = 0x0000004d  success
Setting up local apic... apic_id: 2 done.
Clearing memory 2097152K - 5242880K: ----------------++++++++++++++++ done
CPU #2 Initialized
start_eip=0x00010000
Initializing CPU #3
Waiting for 1 CPUS to stop
CPU: vendor AMD device 20f12
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: 4096MB, type WB
Setting variable MTRR 1, base: 4096MB, range: 1024MB, type WB
Setting variable MTRR 2, base: 3072MB, range: 1024MB, type UC
DONE variable MTRRs
Clear out the extra MTRR's

MTRR check
Fixed MTRRs   : Enabled
Variable MTRRs: Enabled

microcode: equivalent processor rev id  = 0x0210, patch id = 0x00000000
microcode: patch id that want to apply= 0x0000004d
microcode: updated to patch id = 0x0000004d  success
Setting up local apic... apic_id: 3 done.
CPU #3 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:03.0 init
PCI: 04:05.0 init
PCI: 04:06.0 init
PCI: 01:04.0 init
amd8111: ioapic bsp_apicid = 00
RTC Init
RTC: Checksum invalid zeroing cmos
Invalid CMOS LB checksum
enabling HPET @0xfed00000
PNP: 002e.0 init
PNP: 002e.2 init
PNP: 002e.3 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.
Devices initialized
Writing IRQ routing tables to 0xf0000...done.
Wrote the mp table end at: 00000020 - 000001f4
Moving GDT to 0x500...ok
Wrote linuxbios table at: 00000530 - 00000e28  checksum 4d73

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

    33:stream_init() - rom_stream: 0xfffc0000 - 0xfffdffff
Found ELF candiate at offset 0
New segment addr 0x100000 size 0x2bdc0 offset 0xc0 filesize 0xd2a8
(cleaned up) New segment addr 0x100000 size 0x2bdc0 offset 0xc0 filesize 0xd2a8
New segment addr 0x12bdc0 size 0x48 offset 0xd380 filesize 0x48
(cleaned up) New segment addr 0x12bdc0 size 0x48 offset 0xd380 filesize 0x48
Dropping non PT_LOAD segment
Dropping non PT_LOAD segment
Loading Segment: addr: 0x0000000000100000 memsz: 0x000000000002bdc0 filesz: 0x000000000000d2a8
Clearing Segment: addr: 0x000000000010d2a8 memsz: 0x000000000001eb18
Loading Segment: addr: 0x000000000012bdc0 memsz: 0x0000000000000048 filesz: 0x0000000000000048
Jumping to boot code at 0x108cc4
FILO version 0.5 (root at countzero.vandewege.net) Mon May  1 10:59:12 EDT 2006
collect_linuxbios_info: Searching for LinuxBIOS tables...
find_lb_table: Found canidate at: 00000530
find_lb_table: header checksum o.k.
find_lb_table: table checksum o.k.
find_lb_table: record count o.k.
collect_linuxbios_info: Found LinuxBIOS table at: 00000530
convert_memmap: 0x00000000000000 0x00000000000e94 16
convert_memmap: 0x00000000000e94 0x0000000009f16c 1
convert_memmap: 0x000000000c0000 0x00000000030000 1
convert_memmap: 0x000000000f0000 0x00000000000400 16
convert_memmap: 0x000000000f0400 0x0000007ff0fc00 1
convert_memmap: 0x00000080000000 0x00000040000000 1
convert_memmap: 0x00000100000000 0x00000040000000 1
IDE channel 2 not found
-------------- next part --------------
# !!! NOTE !!!
# Do NOT add spaces or comments at the end of option lines.
# It confuses some versions of make.

# Use grub instead of autoboot?
USE_GRUB = 1

# Grub menu.lst path
#MENULST_FILE = "hda3:/boot/filo/menu.lst"
MENULST_FILE = "hde1:/grub/menu.lst"

# Image filename for automatic boot and optional command line parameter
#AUTOBOOT_FILE = "hda1:/vmlinuz root=/dev/hda1 console=tty0 console=ttyS0,115200"
AUTOBOOT_FILE = "hde1:/linuxbios.elf"
#AUTOBOOT_FILE = "mem at 0xfff80000"
#AUTOBOOT_FILE = "hde1 at 0"
#AUTOBOOT_FILE = "uda1:/vmlinuz.elf"

# Time in second before booting AUTOBOOT_FILE
AUTOBOOT_DELAY = 5

# Driver for hard disk, CompactFlash, and CD-ROM on IDE bus
IDE_DISK = 1

# Driver for USB Storage
#USB_DISK = 1

# VGA text console
VGA_CONSOLE = 1
PC_KEYBOARD = 1

# Serial console 
SERIAL_CONSOLE = 1
SERIAL_IOBASE = 0x3f8
# if SERIAL_SPEED is commented out, the speed will not be changed.
#SERIAL_SPEED = 115200

# Filesystems
FSYS_EXT2FS = 1
#FSYS_FAT = 1
#FSYS_JFS = 1
#FSYS_MINIX = 1
#FSYS_REISERFS = 1
#FSYS_XFS = 1
FSYS_ISO9660 = 1

# Support for boot disk image in bootable CD-ROM (El Torito)
ELTORITO = 1

# PCI support
SUPPORT_PCI = 1

# Enable this to scan PCI busses above bus 0
# AMD64 based boards do need this.
PCI_BRUTE_SCAN = 1

# Sound support (needs SUPPORT_PCI)
#SUPPORT_SOUND = 1

# Sound drivers
#VIA_SOUND = 1

# Debugging
#DEBUG_ALL = 1
DEBUG_ELFBOOT = 1
#DEBUG_ELFNOTE = 1
DEBUG_LINUXBIOS = 1
#DEBUG_MALLOC = 1
#DEBUG_MULTIBOOT = 1
#DEBUG_SEGMENT = 1
#DEBUG_SYS_INFO = 1
#DEBUG_TIMER = 1
#DEBUG_BLOCKDEV = 1
#DEBUG_PCI = 1
#DEBUG_VIA_SOUND = 1
#DEBUG_LINUXLOAD = 1
#DEBUG_IDE = 1
#DEBUG_USB = 1
#DEBUG_ELTORITO = 1

# i386 options

# Loader for standard Linux kernel image, a.k.a. /vmlinuz
LINUX_LOADER = 1

# Boot FILO from Multiboot loader (eg. GRUB)
#MULTIBOOT_IMAGE = 1

# Use PCI Configuration Mechanism #1 (most boards)
PCI_CONFIG_1 = 1

From hidi at e-tiger.net  Mon May  1 18:06:44 2006
From: hidi at e-tiger.net (Hidasi Jozsef)
Date: Mon, 1 May 2006 18:06:44 +0200
Subject: [LinuxBIOS] (no subject)
Message-ID: <648950734.20060501180644@e-tiger.net>

  HELP!

  Who has a working IASL compiler?!?! I'm going to be crazy because of
  these segmentation faults! I can't find the bug, I know it halts
  because of these for lines:

        External (\_SB.PCI1.LNKA, DeviceObj)
        External (\_SB.PCI1.LNKB, DeviceObj)
        External (\_SB.PCI1.LNKC, DeviceObj)
        External (\_SB.PCI1.LNKD, DeviceObj)

        

  

-- 
Best regards,
 Hidasi                          mailto:hidi at e-tiger.net
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 456 bytes
Desc: not available
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20060501/64016135/attachment.sig>

From chris at suehsi.de  Mon May  1 20:27:06 2006
From: chris at suehsi.de (=?ISO-8859-1?Q?Christian_S=FChs?=)
Date: Mon, 01 May 2006 20:27:06 +0200
Subject: [LinuxBIOS] MB1030 / 3036 VGA comes up :D
In-Reply-To: <8a0c36780605010706m2bed1a6eja546e5b941f46c1a@mail.gmail.com>
References: <0E81348C5627674A9C0061413EBFF5F74F4442@SAUSEXMB2.amd.com>	<20060428084154.GA26438@coresystems.de>	<8a0c36780604280849l2fa2cb32va9f5581f6dbf749e@mail.gmail.com>	<4454A226.3020108@suehsi.de>
	<20060430103923.GA19323@coresystems.de>	<4454C416.4040906@suehsi.de>	<8a0c36780604301419y7f9b8045ie57b8f19bdeb6e2b@mail.gmail.com>	<4455E1AA.7070902@suehsi.de>
	<8a0c36780605010706m2bed1a6eja546e5b941f46c1a@mail.gmail.com>
Message-ID: <445652FA.7030009@suehsi.de>


> 
> Hmmm... That seems doubtful.  Did I screw up the patch somehow?  If

The patch looks ok ;)

> you look back through some of your debug logs do you see any IO to
> ports 0x40-0x43 or 0x50-53?
> 

I'm not sure, but I have had a run with enabled printk in sys.c

result is attached.

Currently I don't know what happens on the commented lines, but the rest 
  is fast. Only on the commented lines it stops and takes the long delays.

after the first call on c000:4d4d about 20s
after the second call on c000:4d4d about 30s, short flickering jump to 
c000:5506 nothing for about 40s, console comes up.

Why c000, I think it should be c0000??

chris

Furthermore there are differents to the Userspace run.

> --
> Richard A. Smith
> 

-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: int10.cap
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20060501/c41e17f3/attachment.ksh>

From yinghai.lu at amd.com  Mon May  1 19:10:17 2006
From: yinghai.lu at amd.com (Lu, Yinghai)
Date: Mon, 1 May 2006 10:10:17 -0700
Subject: [LinuxBIOS] (no subject)
Message-ID: <6F7DA19D05F3CF40B890C7CA2DB13A4203094C27@ssvlexmb2.amd.com>

Can you use iasl of version 20050513?

YH





From smithbone at gmail.com  Mon May  1 20:33:55 2006
From: smithbone at gmail.com (Richard Smith)
Date: Mon, 1 May 2006 13:33:55 -0500
Subject: [LinuxBIOS] MB1030 / 3036 VGA comes up :D
In-Reply-To: <445652FA.7030009@suehsi.de>
References: <0E81348C5627674A9C0061413EBFF5F74F4442@SAUSEXMB2.amd.com>
	<20060428084154.GA26438@coresystems.de>
	<8a0c36780604280849l2fa2cb32va9f5581f6dbf749e@mail.gmail.com>
	<4454A226.3020108@suehsi.de> <20060430103923.GA19323@coresystems.de>
	<4454C416.4040906@suehsi.de>
	<8a0c36780604301419y7f9b8045ie57b8f19bdeb6e2b@mail.gmail.com>
	<4455E1AA.7070902@suehsi.de>
	<8a0c36780605010706m2bed1a6eja546e5b941f46c1a@mail.gmail.com>
	<445652FA.7030009@suehsi.de>
Message-ID: <8a0c36780605011133l5be7d2e8sbf8fa875824ffe8a@mail.gmail.com>

>
> I'm not sure, but I have had a run with enabled printk in sys.c
>
> result is attached.

Comment out the if() sections on the IO and just leave the printks
(enable the 32 bit IO prints as well) and send it to me.  The log is
generates will be huge so send it to me direct.  No need to clutter
the list.

> Currently I don't know what happens on the commented lines, but the rest
>   is fast. Only on the commented lines it stops and takes the long delays.

I'm going to try and match up your commented lines with what IO is
happening at that time and perhaps generate a clue.

> Why c000, I think it should be c0000??

No its correct.

16-bit 0xc000:0000 = 32-bit 0xc0000

--
Richard A. Smith



From chris at suehsi.de  Mon May  1 22:25:43 2006
From: chris at suehsi.de (=?ISO-8859-1?Q?Christian_S=FChs?=)
Date: Mon, 01 May 2006 22:25:43 +0200
Subject: [LinuxBIOS] MB1030 / 3036 VGA comes up :D
In-Reply-To: <8a0c36780605011133l5be7d2e8sbf8fa875824ffe8a@mail.gmail.com>
References: <0E81348C5627674A9C0061413EBFF5F74F4442@SAUSEXMB2.amd.com>	
	<20060428084154.GA26438@coresystems.de>	
	<8a0c36780604280849l2fa2cb32va9f5581f6dbf749e@mail.gmail.com>	
	<4454A226.3020108@suehsi.de>
	<20060430103923.GA19323@coresystems.de>	
	<4454C416.4040906@suehsi.de>	
	<8a0c36780604301419y7f9b8045ie57b8f19bdeb6e2b@mail.gmail.com>	
	<4455E1AA.7070902@suehsi.de>	
	<8a0c36780605010706m2bed1a6eja546e5b941f46c1a@mail.gmail.com>	
	<445652FA.7030009@suehsi.de>
	<8a0c36780605011133l5be7d2e8sbf8fa875824ffe8a@mail.gmail.com>
Message-ID: <44566EC7.4090104@suehsi.de>


> 
> Comment out the if() sections on the IO and just leave the printks
> (enable the 32 bit IO prints as well) and send it to me.  The log is
> generates will be huge so send it to me direct.  No need to clutter
> the list.
> 

No way,

with to much debug, the system hangs after a few lines.
The same for the emu debug.

What is the interessting stuff?
I can try one debug line for a run
and merge the stuff together.

chris




From chris at suehsi.de  Mon May  1 23:03:58 2006
From: chris at suehsi.de (=?ISO-8859-1?Q?Christian_S=FChs?=)
Date: Mon, 01 May 2006 23:03:58 +0200
Subject: [LinuxBIOS] MB1030 / 3036 VGA comes up :D
In-Reply-To: <44566EC7.4090104@suehsi.de>
References: <0E81348C5627674A9C0061413EBFF5F74F4442@SAUSEXMB2.amd.com>		<20060428084154.GA26438@coresystems.de>		<8a0c36780604280849l2fa2cb32va9f5581f6dbf749e@mail.gmail.com>		<4454A226.3020108@suehsi.de>	<20060430103923.GA19323@coresystems.de>		<4454C416.4040906@suehsi.de>		<8a0c36780604301419y7f9b8045ie57b8f19bdeb6e2b@mail.gmail.com>		<4455E1AA.7070902@suehsi.de>		<8a0c36780605010706m2bed1a6eja546e5b941f46c1a@mail.gmail.com>		<445652FA.7030009@suehsi.de>	<8a0c36780605011133l5be7d2e8sbf8fa875824ffe8a@mail.gmail.com>
	<44566EC7.4090104@suehsi.de>
Message-ID: <445677BE.4080201@suehsi.de>


> 
> No way,
> 
> with to much debug, the system hangs after a few lines.
> The same for the emu debug.
> 
> What is the interessting stuff?
> I can try one debug line for a run

As I say, I get only 2 - 3 lines, than it hangs :(
but it should be possible to fetch the interessting IO on an other way.
I will try that tomorrow.

n8

chris

> and merge the stuff together.
> 
> chris
> 
> 




From smithbone at gmail.com  Mon May  1 21:54:14 2006
From: smithbone at gmail.com (Richard Smith)
Date: Mon, 1 May 2006 14:54:14 -0500
Subject: [LinuxBIOS] MB1030 / 3036 VGA comes up :D
In-Reply-To: <44566EC7.4090104@suehsi.de>
References: <0E81348C5627674A9C0061413EBFF5F74F4442@SAUSEXMB2.amd.com>
	<4454A226.3020108@suehsi.de> <20060430103923.GA19323@coresystems.de>
	<4454C416.4040906@suehsi.de>
	<8a0c36780604301419y7f9b8045ie57b8f19bdeb6e2b@mail.gmail.com>
	<4455E1AA.7070902@suehsi.de>
	<8a0c36780605010706m2bed1a6eja546e5b941f46c1a@mail.gmail.com>
	<445652FA.7030009@suehsi.de>
	<8a0c36780605011133l5be7d2e8sbf8fa875824ffe8a@mail.gmail.com>
	<44566EC7.4090104@suehsi.de>
Message-ID: <8a0c36780605011254i2edfa710h5ba481b7ae0a6093@mail.gmail.com>

On 5/1/06, Christian S?hs <chris at suehsi.de> wrote:

> > Comment out the if() sections on the IO and just leave the printks
> > (enable the 32 bit IO prints as well) and send it to me.  The log is
> > generates will be huge so send it to me direct.  No need to clutter
> > the list.
> >
>
> No way,
>
> with to much debug, the system hangs after a few lines.
> The same for the emu debug.

So enableing the printks causes the emulator to hang.  Interesting. 
This seems to suggest there may be some sort of subtle timing problem.
 With the printks it should run painfully slow but it should not hang?
 printk generate IO to the serial port.  I wonder if that is some how
messing it up.

What happens if you change the printks into a long delay? say like
udelay(1500) or udelay(3000)?

> What is the interessting stuff?

Thats part of the problem. I don't know whats interesting yet.

> I can try one debug line for a run
> and merge the stuff together.

I suppose you could use the if() blocks and just grab ranges.  But
when you get into the legacy vga range it will spew.

--
Richard A. Smith



From smithbone at gmail.com  Mon May  1 21:59:52 2006
From: smithbone at gmail.com (Richard Smith)
Date: Mon, 1 May 2006 14:59:52 -0500
Subject: [LinuxBIOS] MB1030 / 3036 VGA comes up :D
In-Reply-To: <445677BE.4080201@suehsi.de>
References: <0E81348C5627674A9C0061413EBFF5F74F4442@SAUSEXMB2.amd.com>
	<20060430103923.GA19323@coresystems.de> <4454C416.4040906@suehsi.de>
	<8a0c36780604301419y7f9b8045ie57b8f19bdeb6e2b@mail.gmail.com>
	<4455E1AA.7070902@suehsi.de>
	<8a0c36780605010706m2bed1a6eja546e5b941f46c1a@mail.gmail.com>
	<445652FA.7030009@suehsi.de>
	<8a0c36780605011133l5be7d2e8sbf8fa875824ffe8a@mail.gmail.com>
	<44566EC7.4090104@suehsi.de> <445677BE.4080201@suehsi.de>
Message-ID: <8a0c36780605011259p721fb330j4d640fc17857cae8@mail.gmail.com>

> > What is the interessting stuff?
> > I can try one debug line for a run
>
> As I say, I get only 2 - 3 lines, than it hangs :

Post up the output then.

--
Richard A. Smith



From rminnich at lanl.gov  Mon May  1 22:01:45 2006
From: rminnich at lanl.gov (Ronald G Minnich)
Date: Mon, 01 May 2006 14:01:45 -0600
Subject: [LinuxBIOS] Slow kernel loading?
In-Reply-To: <1347456839.20060501123659@e-tiger.net>
References: <1347456839.20060501123659@e-tiger.net>
Message-ID: <44566929.3050802@lanl.gov>

Hidasi Jozsef wrote:
>  Hi List!
> 
>  Yesterday I've manged some kind of ACPI into my S2882 after iasl
>  segmentation faults I've dumped the original DSTC ant it compiles
>  cleanly for now. BUT, is it normal when I load a kernel via network
>  the decompression takes about minutes? So etherboot says Done and I
>  have to wait a lot to boot the kernel, THERE'S NO OUTPUT AT ALL TILL
>  THAT!

no, that's weird. Can you enable earlyprintk? It's very useful for this 
type of thing.

ron



From rminnich at lanl.gov  Mon May  1 22:07:01 2006
From: rminnich at lanl.gov (Ronald G Minnich)
Date: Mon, 01 May 2006 14:07:01 -0600
Subject: [LinuxBIOS] Another newbi question
In-Reply-To: <Pine.LNX.4.63.0605011606340.11308@web.seicento.selfip.org>
References: <Pine.LNX.4.63.0605011606340.11308@web.seicento.selfip.org>
Message-ID: <44566A65.9030708@lanl.gov>

if you can get a tiny linux in 400K or so, you could boot linux from 
flash. I would LOVE to see this happen.

ron



From stepan at coresystems.de  Mon May  1 23:37:41 2006
From: stepan at coresystems.de (Stefan Reinauer)
Date: Mon, 1 May 2006 23:37:41 +0200
Subject: [LinuxBIOS] WORK! :) Power button question
In-Reply-To: <2ea3fae10604301907q8ebe36fif037272a552b83eb@mail.gmail.com>
References: <592068803.20060430001151@e-tiger.net> <445433CD.9080308@lanl.gov>
	<1085214046.20060430144337@e-tiger.net>
	<2ea3fae10604300921h68e77875mcedd0ee1c7caa530@mail.gmail.com>
	<1646875161.20060430182811@e-tiger.net>
	<2ea3fae10604301124n1c1a0f53yba734c1ab4752f08@mail.gmail.com>
	<386809661.20060430220955@e-tiger.net>
	<2ea3fae10604301907q8ebe36fif037272a552b83eb@mail.gmail.com>
Message-ID: <20060501213741.GA19173@coresystems.de>

* yhlu <yinghailu at gmail.com> [060501 04:07]:
> your iasl seems too new...
> 
> YH
 
I'm using this one (SUSE 10) and it works fine..

Intel ACPI Component Architecture
ASL Optimizing Compiler version 20050902 [Sep  9 2005]
Copyright (C) 2000 - 2005 Intel Corporation
Supports ACPI Specification Revision 3.0

Can you compile iasl with -g and run it in gdb to find out where and why
it crashes...


> On 4/30/06, Hidasi Jozsef <hidi at e-tiger.net> wrote:
> > Hi!
> >
> > /usr/sbin/iasl -tc /src/LinuxBIOSv2/src/mainboard/tyan/s2882/dx/pci2.asl
> >
> > Intel ACPI Component Architecture
> > ASL Optimizing Compiler version 20060421 [Apr 30 2006]
> > Copyright (C) 2000 - 2006 Intel Corporation
> > Supports ACPI Specification Revision 3.0a
> >
> > Segmentation fault
> >
> >
> > any suggestions?


-- 
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 eric at zyxod.com  Tue May  2 07:32:44 2006
From: eric at zyxod.com (Eric Poulsen)
Date: Mon, 01 May 2006 22:32:44 -0700
Subject: [LinuxBIOS] Solved: Makefile weirdness
In-Reply-To: <4455926F.50007@zyxod.com>
References: <44544DE9.1050701@zyxod.com> <4455926F.50007@zyxod.com>
Message-ID: <4456EEFC.4020904@zyxod.com>

Can anyone confirm that this is a problem?  Or am I barking up the wrong 
tree?

Eric Poulsen wrote:

>Okay, I got it to work again.  This is weird, but I figured out what the
>issue is.  I think the build system for LB (at least for the Epia-M
>branch) is bad.  I don't have any experience with romcc or building
>BIOSes, but I do have quite a bit of experience with C,C++, and using
>makefiles -- something seems very wrong here, especially when you look
>at the details of the two build processes shown below.  IMHO, "make
>clean" should set you back to the beginning (as it seems to),  and a
>compile after that should fix any weirdnesses with linking.
>
>Just in case it's not clear, in both examples below, there are NO "real"
>code changes between them, only configuration changes.  Also, this is
>with my own Epia-ML branch (derived from Epia-M) -- the only difference
>is that I removed the ieee1394 init code in auto.c and edited the
>Config.lb for the mainboard so that it doesn't init the floppy and the
>CF card reader, which don't exist on the ML.  I was having the exact
>same issues with the out-of-the-box Epia-M branch. When I built it (both
>Epia-M and Epia-ML branches) successfully in the past, I _never_ used
>make clean because I figured buildtarget would fix any issues,
>especially since a 'make' after 'buildtarget' resulted in recompilation
>of several files.
>
>In short, my recent use of 'make clean' seems to be hosing the process.
>
>This _DOES NOT WORK_ (but it should):
>
>(pseudocode -- not literal)
>]Set CONFIG_CONSOLE_VGA=1, CONFIG_PCI_ROM_RUN=1 in Config.lb
>]buildtarget via/epia-m
>]cd via/epia-m/epia-m
>]make clean
>]make
>][Bunches of link errors because of overlapping sections]
>|set ROM_IMAGE_SIZE to 0x12000 (previously 0x10000), as per Stefan's
>suggestion.
>buildtarget
>make clean
>make
>[successful compile]
>cat vga_bios linuxbios.rom > lb.rom
>flashrom
>[Reboot]
>Crash, exception 13 just after vga write protect
>
>This _DOES WORK_
>
>Start with default epia-m config.lb
>buildtarget
>[compiles clean, but no vga options on -- If I were to flash and reboot,
>this would work as-is, sans VGA]
>Edit Config.lb add CONFIG_CONSOLE_VGA=1
>buildtarget
>make [_IMPORTANT_ -- NOTICE THERE IS NO 'make clean' LINE!]
>[compiles clean]
>Edit Config.lb add CONFIG_PCI_ROM_RUN=1
>buildtarget
>make [_IMPORTANT_ -- NOTICE THERE IS NO 'make clean' LINE!]
>[compiles clean]
>cat vga_bios linuxbios.rom
>flashrom
>[reboot]
>[Everything works -- boots, VGA works, etc. ]
>[Important thing to note about the above is that the ROM_IMAGE_SIZE _was
>not_ increased]
>
>
>
>
>Eric Poulsen wrote:
>
>  
>
>>I've been trying to accomplish several things:
>>
>>1) LB on Via Epia ML 5000 2) VGA working 3) Figuring out weird boot
>>errors that seem to be "fixed" by the factory BIOS.  Running
>>memtest86+ under LB.
>>
>>I _was_ on step 3, but in the course of events, I went back to step
>>2. VGA is now NOT working again, but with a different error; see
>>below.
>>
>>Since I was messing around with making an ML tree, adding a bit of 
>>custom stuff, and removing initializations for devices that don't
>>exist on the ML (floppy, CF reader), I figured I had done something
>>wrong.
>>
>>Soooo, I went back to the "stock" LinuxBIOSv2, revision 2100, known
>>to work with the Epia M.  This particular revision worked for me,
>>albeit with the long delay at the beginning because of the firewire
>>search.
>>
>>Essentially, whenever, I add ...
>>
>>#VGA Console option CONFIG_CONSOLE_VGA=1 option CONFIG_PCI_ROM_RUN=1
>>
>>... to the Config.lb, it doesn't work, giving the error below.
>>
>>Mysteriously, my "weird boot crashes that are fixed by factory CMOS"
>> problems aren't exhibiting themselves.
>>
>>Unfortunately, I cannot run memtest86 under LB without VGA.
>>
>>Any ideas?
>>
>>--------------------------------------------------------------------
>>
>>0
>>
>>LinuxBIOS-1.1.8.0Fallback Sat Apr 29 22:12:48 PDT 2006 starting... 
>>Enabling mainboard devices Enabling shadow ram vt8623 init starting 
>>Detecting Memory Number of Banks 04 Number of Rows 0d Priamry DRAM
>>width08 No Columns 0a MA type e0 Bank 0 (*16 Mb) 10 No Physical Banks
>>01 Total Memory (*16 Mb) 10 CAS Supported 2 2.5 3 Cycle time at CL X
>>(nS)50 Cycle time at CL X-0.5 (nS)60 Cycle time at CL X-1   (nS)75 
>>Starting at CAS 3 We can do CAS 2.5 We can do CAS 2 tRP 48 tRCD 48 
>>tRAS 28 Low Bond 00  High Bondbe  Setting DQS delay7evt8623 done 
>>00:06 11 23 31 06 00 30 22 00 00 00 06 00 00 00 00 10:08 00 00 d0 00
>>00 00 00 00 00 00 00 00 00 00 00 20:00 00 00 00 00 00 00 00 00 00 00
>>00 00 00 00 00 30:00 00 00 00 a0 00 00 00 00 00 00 00 00 00 00 00 
>>40:00 18 88 80 82 44 00 00 18 99 88 80 82 44 00 00 50:c8 de cf 88 e0
>>07 00 00 e0 00 10 10 10 10 00 00 60:02 ff 00 30 d6 32 01 2a 42 2d 43
>>58 00 44 00 00 70:82 48 00 01 01 08 50 00 01 00 00 00 00 00 00 02 
>>80:0f 65 00 00 80 00 00 00 02 00 00 00 00 00 00 00 90:00 00 00 00 00
>>00 00 00 00 00 00 00 00 00 00 00 a0:02 c0 20 00 07 02 00 1f 04 00 00
>>00 2f 02 04 00 b0:00 00 00 00 80 00 00 00 88 00 00 00 00 00 00 00 
>>c0:01 00 02 00 00 00 00 00 00 00 00 00 00 00 00 00 d0:00 00 00 00 00
>>00 00 00 00 00 00 00 00 00 00 00 e0:00 dd 00 00 00 00 01 00 40 00 00
>>00 00 00 00 00 f0:00 00 00 00 00 00 12 13 00 00 00 00 00 00 00 00 AGP
>> Doing MTRR init. Copying LinuxBIOS to ram. Jumping to LinuxBIOS. 
>>LinuxBIOS-1.1.8.0Fallback Sat Apr 29 22:12:48 PDT 2006 booting... 
>>clocks_per_usec: 838 Enumerating buses... Finding PCI configuration
>>type. PCI: Using configuration type 1 PCI_DOMAIN: 0000 enabled 
>>APIC_CLUSTER: 0 enabled PCI: pci_scan_bus for bus 0 PCI: 00:00.0
>>[1106/3123] enabled PCI: 00:01.0 [1106/b091] enabled Disabling static
>>device: PCI: 00:0a.0 Disabling static device: PCI: 00:0a.1 In
>>vt8235_enable 1106 3038. PCI: 00:10.0 [1106/3038] enabled In
>>vt8235_enable 1106 3038. PCI: 00:10.1 [1106/3038] enabled In
>>vt8235_enable 1106 3038. PCI: 00:10.2 [1106/3038] enabled In
>>vt8235_enable 1106 3104. PCI: 00:10.3 [1106/3104] enabled In
>>vt8235_enable 1106 3177. Initialising Devices PCI: 00:11.0
>>[1106/3177] enabled In vt8235_enable 1106 0571. PCI: 00:11.1
>>[1106/0571] enabled In vt8235_enable 1106 3059. PCI: 00:11.5
>>[1106/3059] enabled In vt8235_enable ffff ffff. In vt8235_enable 1106
>>3065. PCI: 00:12.0 [1106/3065] enabled PCI: pci_scan_bus for bus 1 
>>PCI: 01:00.0 [1106/3122] enabled PCI: pci_scan_bus returning with
>>max=01 vt1211 enabling PNP devices. PNP: 002e.0 enabled vt1211
>>enabling PNP devices. PNP: 002e.1 enabled vt1211 enabling PNP
>>devices. PNP: 002e.2 enabled vt1211 enabling PNP devices. PNP: 002e.3
>>enabled vt1211 enabling PNP devices. PNP: 002e.b enabled PCI:
>>pci_scan_bus returning with max=01 done Allocating resources... 
>>Reading resources... Done reading resources. Allocating VGA resource
>>PCI: 01:00.0 Setting PCI_BRIDGE_CTL_VGA for bridge PCI: 00:01.0 
>>Setting PCI_BRIDGE_CTL_VGA for bridge PCI_DOMAIN: 0000 Setting
>>PCI_BRIDGE_CTL_VGA for bridge Root Device Setting resources... I
>>would set ram size to 0x40000 Kbytes PCI: 00:10.0 20 <- [0x0000001800
>>- 0x000000181f] io PCI: 00:10.1 20 <- [0x0000001820 - 0x000000183f]
>>io PCI: 00:10.2 20 <- [0x0000001840 - 0x000000185f] io PCI: 00:10.3
>>10 <- [0x00febff000 - 0x00febff0ff] mem PNP: 002e.0 60 <-
>>[0x00000003f0 - 0x00000003f7] io PNP: 002e.0 70 <- [0x0000000006 -
>>0x0000000006] irq PNP: 002e.0 74 <- [0x0000000002 - 0x0000000002] drq
>> PNP: 002e.1 60 <- [0x0000000378 - 0x000000037f] io PNP: 002e.1 70 <-
>>[0x0000000007 - 0x0000000007] irq PNP: 002e.1 74 <- [0x0000000003 -
>>0x0000000003] drq 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 PNP: 002e.b 60 <- [0x000000ec00 - 0x000000ecff] io 
>>PCI: 00:11.1 20 <- [0x0000001860 - 0x000000186f] io PCI: 00:11.5 10
>><- [0x0000001000 - 0x00000010ff] io PCI: 00:12.0 10 <- [0x0000001400
>>- 0x00000014ff] io PCI: 00:12.0 14 <- [0x00fec00000 - 0x00fec000ff]
>>mem Done setting resources. Done allocating resources. Enabling
>>resourcess... PCI: 00:00.0 cmd <- 146 PCI: 00:01.0 bridge ctrl <-
>>000f PCI: 00:01.0 cmd <- 147 PCI: 01:00.0 cmd <- 143 PCI: 00:10.0
>>subsystem <- 00/00 PCI: 00:10.0 cmd <- 141 PCI: 00:10.1 subsystem <-
>>00/00 PCI: 00:10.1 cmd <- 141 PCI: 00:10.2 subsystem <- 00/00 PCI:
>>00:10.2 cmd <- 141 PCI: 00:10.3 subsystem <- 00/00 PCI: 00:10.3 cmd
>><- 142 PCI: 00:11.0 cmd <- 147 PNP: 002e.0 - enabling PNP: 002e.1 -
>>enabling PNP: 002e.2 - enabling PNP: 002e.3 - enabling PNP: 002e.b -
>>enabling PCI: 00:11.1 cmd <- 147 PCI: 00:11.5 subsystem <- 00/00 PCI:
>>00:11.5 cmd <- 141 PCI: 00:12.0 cmd <- 1c3 done. Initializing
>>devices... Root Device init PCI: 00:10.0 init PCI: 00:10.1 init PCI:
>>00:10.2 init PCI: 00:10.3 init PCI: 00:11.0 init vt8235 init RTC Init
>> Invalid CMOS LB checksum pci_routing_fixup: dev is 0001ad40 setting
>>firewire setting usb Assigning IRQ 5 to 0:10.0 Readback = 5 
>>pci_level_irq: lower order bits are wrong: want 0x0, got 0x20 
>>Assigning IRQ 9 to 0:10.1 Readback = 9 pci_level_irq: lower order
>>bits are wrong: want 0x0, got 0x20 Assigning IRQ 9 to 0:10.2 Readback
>>= 9 pci_level_irq: lower order bits are wrong: want 0x0, got 0x20 
>>Assigning IRQ 5 to 0:10.3 Readback = 5 pci_level_irq: lower order
>>bits are wrong: want 0x0, got 0x20 setting vt8235 Assigning IRQ 5 to
>>0:11.1 Readback = 5 pci_level_irq: lower order bits are wrong: want
>>0x0, got 0x20 Assigning IRQ 9 to 0:11.5 Readback = 9 pci_level_irq:
>>lower order bits are wrong: want 0x0, got 0x20 setting ethernet 
>>Assigning IRQ 5 to 0:12.0 Readback = 5 pci_level_irq: lower order
>>bits are wrong: want 0x0, got 0x20 setting vga Assigning IRQ 5 to
>>1:0.0 Readback = 5 pci_level_irq: lower order bits are wrong: want
>>0x0, got 0x20 setting pci slot setting cardbus slot setting riser
>>slot PNP: 002e.0 init PNP: 002e.1 init PNP: 002e.2 init PNP: 002e.3
>>init PNP: 002e.b init PCI: 00:11.1 init Enabling VIA IDE. ide_init:
>>enabling compatibility IDE addresses enables in reg 0x42 0x0 enables
>>in reg 0x42 read back as 0x0 enables in reg 0x40 0x13 enables in reg
>>0x40 read back as 0x13 enables in reg 0x9 0x8a enables in reg 0x9
>>read back as 0x8a command in reg 0x4 0x7 command in reg 0x4 reads
>>back as 0x7 PCI: 00:11.5 init PCI: 00:12.0 init Configuring VIA Rhine
>>LAN APIC_CLUSTER: 0 init Initializing CPU #0 CPU: vendor Centaur
>>device 673 Enabling cache
>>
>>Setting fixed MTRRs(0-88) type: UC Setting fixed MTRRs(0-16) Type: WB
>> Setting fixed MTRRs(24-88) Type: WB DONE fixed MTRRs Setting
>>variable MTRR 0, base:    0MB, range:  128MB, type WB Setting
>>variable MTRR 1, base:  128MB, range:   64MB, type WB Setting
>>variable MTRR 2, base:  192MB, range:   32MB, type WB DONE variable
>>MTRRs Clear out the extra MTRR's
>>
>>MTRR check Fixed MTRRs   : Enabled Variable MTRRs: Enabled
>>
>>Disabling local apic...done. CPU #0 Initialized PCI: 00:00.0 init 
>>VT8623 random fixup ... Frame buffer at d0000000 PCI: 00:01.0 init 
>>VT8623 AGP random fixup ... PCI: 01:00.0 init VGA random fixup ... 
>>INSTALL REAL-MODE IDT DO THE VGA BIOS found VGA: vid=1106, did=3122 
>>rom base, size: fffc0000 write_protect_vgabios bus/devfn = 0x100 
>>Unexpected Exception: 13 @ 10:000121c3 - Halting Code: 0 eflags:
>>00010012 eax: 00000012 ebx: 00024530 ecx: 00023fa8 edx: 00000012 edi:
>>00018a90 esi: ffff946b ebp: 00023f84 esp: 00023f84
>>
>>
>>
>>
>>    
>>
>
>
>
>  
>




From chris at suehsi.de  Tue May  2 12:26:24 2006
From: chris at suehsi.de (=?ISO-8859-1?Q?Christian_S=FChs?=)
Date: Tue, 02 May 2006 12:26:24 +0200
Subject: [LinuxBIOS] MB1030 / 3036 VGA comes up :D
In-Reply-To: <8a0c36780605011259p721fb330j4d640fc17857cae8@mail.gmail.com>
References: <0E81348C5627674A9C0061413EBFF5F74F4442@SAUSEXMB2.amd.com>	<20060430103923.GA19323@coresystems.de>
	<4454C416.4040906@suehsi.de>	<8a0c36780604301419y7f9b8045ie57b8f19bdeb6e2b@mail.gmail.com>	<4455E1AA.7070902@suehsi.de>	<8a0c36780605010706m2bed1a6eja546e5b941f46c1a@mail.gmail.com>	<445652FA.7030009@suehsi.de>	<8a0c36780605011133l5be7d2e8sbf8fa875824ffe8a@mail.gmail.com>	<44566EC7.4090104@suehsi.de>
	<445677BE.4080201@suehsi.de>
	<8a0c36780605011259p721fb330j4d640fc17857cae8@mail.gmail.com>
Message-ID: <445733D0.6050004@suehsi.de>

Richard Smith schrieb:
>>>What is the interessting stuff?
>>>I can try one debug line for a run
>>
>>As I say, I get only 2 - 3 lines, than it hangs :
> 
> 
> Post up the output then.
> 
> --
> Richard A. Smith
> 
Yesterday, I have only done x_inb and x_inw
here is the output for both.

first is the u8 function.
No more output, nothing happens.

second the u16 function.
before the system hangs for the u16 output the screen goes to ON

Now I will insert delays, for a run.

chris
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: u8.cap
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20060502/831db18e/attachment.ksh>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: u16.cap
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20060502/831db18e/attachment-0001.ksh>

From chris at suehsi.de  Tue May  2 13:01:26 2006
From: chris at suehsi.de (=?ISO-8859-1?Q?Christian_S=FChs?=)
Date: Tue, 02 May 2006 13:01:26 +0200
Subject: [LinuxBIOS] MB1030 / 3036 VGA comes up :D
In-Reply-To: <8a0c36780605011254i2edfa710h5ba481b7ae0a6093@mail.gmail.com>
References: <0E81348C5627674A9C0061413EBFF5F74F4442@SAUSEXMB2.amd.com>	<4454A226.3020108@suehsi.de>
	<20060430103923.GA19323@coresystems.de>	<4454C416.4040906@suehsi.de>	<8a0c36780604301419y7f9b8045ie57b8f19bdeb6e2b@mail.gmail.com>	<4455E1AA.7070902@suehsi.de>	<8a0c36780605010706m2bed1a6eja546e5b941f46c1a@mail.gmail.com>	<445652FA.7030009@suehsi.de>	<8a0c36780605011133l5be7d2e8sbf8fa875824ffe8a@mail.gmail.com>	<44566EC7.4090104@suehsi.de>
	<8a0c36780605011254i2edfa710h5ba481b7ae0a6093@mail.gmail.com>
Message-ID: <44573C06.5030709@suehsi.de>


> 
> So enableing the printks causes the emulator to hang.  Interesting. 
> This seems to suggest there may be some sort of subtle timing problem.
>  With the printks it should run painfully slow but it should not hang?
>  printk generate IO to the serial port.  I wonder if that is some how
> messing it up.
> 

Could it be a interrupt problem between the vga device and the serial port ?

This board is highly integrated, and after a successful boot, I have got 
sometimes a kernel panic with a non-syncing interrupt handler.
Furthermore the vga device is located with interrupt 0 under lspci.

Ok, it is theory only :D

chris



From paul.collomb1 at libertysurf.fr  Tue May  2 13:02:22 2006
From: paul.collomb1 at libertysurf.fr (=?iso-8859-1?Q?paul.collomb1@libertysurf.fr?=)
Date: Tue,  2 May 2006 13:02:22 +0200
Subject: [LinuxBIOS] =?iso-8859-1?q?Another_newbi_question_/_TYAN_TIGER_MP?=
	=?iso-8859-1?q?_S2460?=
Message-ID: <IYMXBY$6AC9EF76882C9B4BA039C98DD34DB749@aliceadsl.fr>

Hi, i am newbi on linuxbios ... 
I have bought a TYAN TIGER MP S 2460 motherboard model ( to a friend ) and i want to know 
( if possible ) if linuxbios could work fine on this mobo. 
In your opinion, is it possible ? 
Thanks for your response. 
Best regards 

-------------- ALICE HAUT DEBIT : TRIPLE PLAY A 29,95 EUR/MOIS -------------- 
D?couvrez vite ALICEBOX : avec le modem WIFI, profitez de l'ADSL, de la TELEPHONIE et en exclusivit? de la TELEVISION ! 
B?n?ficiez aussi de la hotline gratuite 24h/24 ! Soumis ? conditions. Pour en profiter cliquez ici http://abonnement.aliceadsl.fr







From stepan at coresystems.de  Tue May  2 13:17:49 2006
From: stepan at coresystems.de (Stefan Reinauer)
Date: Tue, 2 May 2006 13:17:49 +0200
Subject: [LinuxBIOS] Solved: Makefile weirdness (was: Epia ML 5000 VGA
	(Again!) -- Moving backwards, somehow.)
In-Reply-To: <4455926F.50007@zyxod.com>
References: <44544DE9.1050701@zyxod.com> <4455926F.50007@zyxod.com>
Message-ID: <20060502111749.GA7339@coresystems.de>

* Eric Poulsen <eric at zyxod.com> [060501 06:45]:
> buildtarget
> make clean
> make
> Crash, exception 13 just after vga write protect
 
 - vs -

> buildtarget
> make
> [Everything works -- boots, VGA works, etc. ]
> [Important thing to note about the above is that the ROM_IMAGE_SIZE _was
> not_ increased]
 
This sounds very weird. Are you doing this on the same system using the
same compiler? I suspect this is on 2 systems or using different
compilers or binutils, since these factors can and do affect code size a
lot (and make things break)

I just tried a "make clean" in a freshly created buildtree (using
buildtarget) and its exactly the same as without "make clean"

Can you try the same and check whether its different?

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 stepan at coresystems.de  Tue May  2 13:53:33 2006
From: stepan at coresystems.de (Stefan Reinauer)
Date: Tue, 2 May 2006 13:53:33 +0200
Subject: [LinuxBIOS] MB1030 / 3036 VGA comes up :D
In-Reply-To: <4455EF1D.9060500@suehsi.de>
References: <0E81348C5627674A9C0061413EBFF5F74F4442@SAUSEXMB2.amd.com>
	<20060428084154.GA26438@coresystems.de>
	<8a0c36780604280849l2fa2cb32va9f5581f6dbf749e@mail.gmail.com>
	<4454A226.3020108@suehsi.de>
	<20060430103923.GA19323@coresystems.de>
	<4454C416.4040906@suehsi.de>
	<8a0c36780604301419y7f9b8045ie57b8f19bdeb6e2b@mail.gmail.com>
	<4455E1AA.7070902@suehsi.de> <4455EF1D.9060500@suehsi.de>
Message-ID: <20060502115333.GA10803@coresystems.de>

* Christian S?hs <chris at suehsi.de> [060501 13:21]:
> After that I have enabled the whole video RAM section A0000 - BFFFF as 
> read/write/cache 0x07070067:

I would assume that the video ram must not be cacheable! It doesn't get
written to very much by the bios anyways (except probably the int10
calls)

> I have also the long delay by vga initializing, but after upcoming there 
> are only unreadable characters on the screen.

Yes, cacheable video memory does not work. When the CPU caches things
there the VGA controller only sees half of what it is supposed to see.

S.

-- 
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 chris at suehsi.de  Tue May  2 15:15:12 2006
From: chris at suehsi.de (=?ISO-8859-1?Q?Christian_S=FChs?=)
Date: Tue, 02 May 2006 15:15:12 +0200
Subject: [LinuxBIOS] MB1030 / 3036 VGA comes up :D
In-Reply-To: <445733D0.6050004@suehsi.de>
References: <0E81348C5627674A9C0061413EBFF5F74F4442@SAUSEXMB2.amd.com>	<20060430103923.GA19323@coresystems.de>
	<4454C416.4040906@suehsi.de>	<8a0c36780604301419y7f9b8045ie57b8f19bdeb6e2b@mail.gmail.com>	<4455E1AA.7070902@suehsi.de>	<8a0c36780605010706m2bed1a6eja546e5b941f46c1a@mail.gmail.com>	<445652FA.7030009@suehsi.de>	<8a0c36780605011133l5be7d2e8sbf8fa875824ffe8a@mail.gmail.com>	<44566EC7.4090104@suehsi.de>
	<445677BE.4080201@suehsi.de>
	<8a0c36780605011259p721fb330j4d640fc17857cae8@mail.gmail.com>
	<445733D0.6050004@suehsi.de>
Message-ID: <44575B60.7050406@suehsi.de>


> Now I will insert delays, for a run.
> 

Ok, first I have insert one udelay(1500) call for the u8 function.
the system gets the first int10 vector and the screen switches to ON.
After that nor more happens.

Than I have insert delay(1500) for all u8-u32 functions.
The result is the same as before, the first int10 vector switches the 
screen ON.

as I say, the problem is after the first int10 and between the second 
and third call.

chris



From stepan at coresystems.de  Tue May  2 14:10:00 2006
From: stepan at coresystems.de (Stefan Reinauer)
Date: Tue, 2 May 2006 14:10:00 +0200
Subject: [LinuxBIOS] [FEATURE] payload compression
In-Reply-To: <2ea3fae10604291510w2625ed47ida699b7d966e8251@mail.gmail.com>
References: <20060429195700.GA12529@coresystems.de>
	<2ea3fae10604291433m5b316527vfd51af5b1f2afee9@mail.gmail.com>
	<20060429215649.GA22296@coresystems.de>
	<2ea3fae10604291510w2625ed47ida699b7d966e8251@mail.gmail.com>
Message-ID: <20060502121000.GA11764@coresystems.de>

* yhlu <yinghailu at gmail.com> [060430 00:10]:
> payloads will be
> 1. Etherboot, zelf
> 2. FILO,
> 3. OpenBIOS
> 4. zelf from kernel and initram disk...less than 4Mbyte or 16Mbyte...
> 
> How about compress ratio for nrv2b?

filo has 1:1.76, openbios even 1:2.12 due to the forth dictionary.
The compression rate is the same as zelf, as its the same compression
algorithm.

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 smithbone at gmail.com  Tue May  2 15:32:43 2006
From: smithbone at gmail.com (Richard Smith)
Date: Tue, 2 May 2006 08:32:43 -0500
Subject: [LinuxBIOS] Solved: Makefile weirdness
In-Reply-To: <4456EEFC.4020904@zyxod.com>
References: <44544DE9.1050701@zyxod.com> <4455926F.50007@zyxod.com>
	<4456EEFC.4020904@zyxod.com>
Message-ID: <8a0c36780605020632q2f19a0b1wed3d7b559ed44823@mail.gmail.com>

On 5/2/06, Eric Poulsen <eric at zyxod.com> wrote:
> Can anyone confirm that this is a problem?  Or am I barking up the wrong
> tree?
>

Do a diff between your target trees that have just a buildtarget and
one that has a buildtarget followed by a make clean.  Don't actually
do a compile.

They should be identical.

--
Richard A. Smith



From smithbone at gmail.com  Tue May  2 15:55:51 2006
From: smithbone at gmail.com (Richard Smith)
Date: Tue, 2 May 2006 08:55:51 -0500
Subject: [LinuxBIOS] Another newbi question / TYAN TIGER MP S2460
In-Reply-To: <IYMXBY$6AC9EF76882C9B4BA039C98DD34DB749@aliceadsl.fr>
References: <IYMXBY$6AC9EF76882C9B4BA039C98DD34DB749@aliceadsl.fr>
Message-ID: <8a0c36780605020655r33acad75tde674dda271259ca@mail.gmail.com>

On 5/2/06, paul.collomb1 at libertysurf.fr <paul.collomb1 at libertysurf.fr> wrote:

> Hi, i am newbi on linuxbios ...
> I have bought a TYAN TIGER MP S 2460 motherboard model ( to a friend ) and i want to know
> ( if possible ) if linuxbios could work fine on this mobo.
> In your opinion, is it possible ?
> Thanks for your response.
> Best regards

We need an 'lspci' of the system booted under linux.

--
Richard A. Smith



From smithbone at gmail.com  Tue May  2 16:21:57 2006
From: smithbone at gmail.com (Richard Smith)
Date: Tue, 2 May 2006 09:21:57 -0500
Subject: [LinuxBIOS] MB1030 / 3036 VGA comes up :D
In-Reply-To: <44573C06.5030709@suehsi.de>
References: <0E81348C5627674A9C0061413EBFF5F74F4442@SAUSEXMB2.amd.com>
	<4454C416.4040906@suehsi.de>
	<8a0c36780604301419y7f9b8045ie57b8f19bdeb6e2b@mail.gmail.com>
	<4455E1AA.7070902@suehsi.de>
	<8a0c36780605010706m2bed1a6eja546e5b941f46c1a@mail.gmail.com>
	<445652FA.7030009@suehsi.de>
	<8a0c36780605011133l5be7d2e8sbf8fa875824ffe8a@mail.gmail.com>
	<44566EC7.4090104@suehsi.de>
	<8a0c36780605011254i2edfa710h5ba481b7ae0a6093@mail.gmail.com>
	<44573C06.5030709@suehsi.de>
Message-ID: <8a0c36780605020721v279f153ev7da4dc3ebb2d42d@mail.gmail.com>

>copying VGA ROM Image from 0xfffc0000 to 0xc0000, 0x8000 bytes
>entering emulator
>inb(0x03cf) = 0x00
>inb(0x03cf) = 0x00
>inb(0x03cf) = 0x88
>i

So its crashing 'inside' of a printk.  0x3cf is a VGA index register.

> Could it be a interrupt problem between the vga device and the serial port ?

LinuxBIOS serial debug output is PIO. No interrupts.

Did you disable the SMI interrupt trap for access to VGA registers? 
That may be getting fired and tripping things up.

--
Richard A. Smith



From eric at zyxod.com  Tue May  2 16:29:05 2006
From: eric at zyxod.com (Eric Poulsen)
Date: Tue, 02 May 2006 07:29:05 -0700
Subject: [LinuxBIOS] Solved: Makefile weirdness
In-Reply-To: <8a0c36780605020632q2f19a0b1wed3d7b559ed44823@mail.gmail.com>
References: <44544DE9.1050701@zyxod.com>
	<4455926F.50007@zyxod.com>	<4456EEFC.4020904@zyxod.com>
	<8a0c36780605020632q2f19a0b1wed3d7b559ed44823@mail.gmail.com>
Message-ID: <44576CB1.8000408@zyxod.com>

I just checked ... they are identical.

I don't think this addresses the issue, however.  It happens to _work_ 
when I do a make, update Config.lb, buildtarget, then a final make.  If 
I put a make clean in after the buildtarget, that's where it fails.

Here's what I think might be going on:

The first make w/o the options compiles all of the object files 
correctly, but without VGA (as expected).  After the buildtarget, _some_ 
of the object files need to be updated to support the new options.  This 
subset of object files is recompiled correctly, and then all of the 
object files are linked into a working executable.  When you do a 'make 
clean' after the build target, all of the object files are wiped out and 
recompiled.  Some of the object files that wouldn't normally be touched 
on the second make are now re-compiled, but they're re-compiled 
incorrectly because of the updated options.

*shrug*

Richard Smith wrote:
> On 5/2/06, Eric Poulsen <eric at zyxod.com> wrote:
>   
>> Can anyone confirm that this is a problem?  Or am I barking up the wrong
>> tree?
>>
>>     
>
> Do a diff between your target trees that have just a buildtarget and
> one that has a buildtarget followed by a make clean.  Don't actually
> do a compile.
>
> They should be identical.
>
> --
> Richard A. Smith
>
>   




From smithbone at gmail.com  Tue May  2 16:31:46 2006
From: smithbone at gmail.com (Richard Smith)
Date: Tue, 2 May 2006 09:31:46 -0500
Subject: [LinuxBIOS] MB1030 / 3036 VGA comes up :D
In-Reply-To: <44575B60.7050406@suehsi.de>
References: <0E81348C5627674A9C0061413EBFF5F74F4442@SAUSEXMB2.amd.com>
	<4455E1AA.7070902@suehsi.de>
	<8a0c36780605010706m2bed1a6eja546e5b941f46c1a@mail.gmail.com>
	<445652FA.7030009@suehsi.de>
	<8a0c36780605011133l5be7d2e8sbf8fa875824ffe8a@mail.gmail.com>
	<44566EC7.4090104@suehsi.de> <445677BE.4080201@suehsi.de>
	<8a0c36780605011259p721fb330j4d640fc17857cae8@mail.gmail.com>
	<445733D0.6050004@suehsi.de> <44575B60.7050406@suehsi.de>
Message-ID: <8a0c36780605020731w7d9d7048g524d640b4d3ed665@mail.gmail.com>

On 5/2/06, Christian S?hs <chris at suehsi.de> wrote:

> as I say, the problem is after the first int10 and between the second
> and third call.
>

Thats much later than when it hangs with a printk right?

Try decreasing the delay until you find the smallest delay that does not hang.

--
Richard A. Smith



From smithbone at gmail.com  Tue May  2 16:40:20 2006
From: smithbone at gmail.com (Richard Smith)
Date: Tue, 2 May 2006 09:40:20 -0500
Subject: [LinuxBIOS] Solved: Makefile weirdness
In-Reply-To: <44576CB1.8000408@zyxod.com>
References: <44544DE9.1050701@zyxod.com> <4455926F.50007@zyxod.com>
	<4456EEFC.4020904@zyxod.com>
	<8a0c36780605020632q2f19a0b1wed3d7b559ed44823@mail.gmail.com>
	<44576CB1.8000408@zyxod.com>
Message-ID: <8a0c36780605020740v25d46fdeg1f4f7156f5ae594e@mail.gmail.com>

> recompiled.  Some of the object files that wouldn't normally be touched
> on the second make are now re-compiled, but they're re-compiled
> incorrectly because of the updated options.
>

So that would mean that a fresh buildtarget and make with the vga
options enabled should fail?  Is this what you orginally reported?

--
Richard A. Smith



From stepan at coresystems.de  Tue May  2 16:48:09 2006
From: stepan at coresystems.de (Stefan Reinauer)
Date: Tue, 2 May 2006 16:48:09 +0200
Subject: [LinuxBIOS] Solved: Makefile weirdness
In-Reply-To: <44576CB1.8000408@zyxod.com>
References: <44544DE9.1050701@zyxod.com> <4455926F.50007@zyxod.com>
	<4456EEFC.4020904@zyxod.com>
	<8a0c36780605020632q2f19a0b1wed3d7b559ed44823@mail.gmail.com>
	<44576CB1.8000408@zyxod.com>
Message-ID: <20060502144809.GA19445@coresystems.de>

* Eric Poulsen <eric at zyxod.com> [060502 16:29]:
> I don't think this addresses the issue, however.  It happens to _work_ 
> when I do a make, update Config.lb, buildtarget, then a final make.  If 
> I put a make clean in after the buildtarget, that's where it fails.
 
So could you diff the object files so see where the difference is?

S.

-- 
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 lanl.gov  Tue May  2 16:49:36 2006
From: rminnich at lanl.gov (Ronald G Minnich)
Date: Tue, 02 May 2006 08:49:36 -0600
Subject: [LinuxBIOS] MB1030 / 3036 VGA comes up :D
In-Reply-To: <8a0c36780605020721v279f153ev7da4dc3ebb2d42d@mail.gmail.com>
References: <0E81348C5627674A9C0061413EBFF5F74F4442@SAUSEXMB2.amd.com>	<4454C416.4040906@suehsi.de>	<8a0c36780604301419y7f9b8045ie57b8f19bdeb6e2b@mail.gmail.com>	<4455E1AA.7070902@suehsi.de>	<8a0c36780605010706m2bed1a6eja546e5b941f46c1a@mail.gmail.com>	<445652FA.7030009@suehsi.de>	<8a0c36780605011133l5be7d2e8sbf8fa875824ffe8a@mail.gmail.com>	<44566EC7.4090104@suehsi.de>	<8a0c36780605011254i2edfa710h5ba481b7ae0a6093@mail.gmail.com>	<44573C06.5030709@suehsi.de>
	<8a0c36780605020721v279f153ev7da4dc3ebb2d42d@mail.gmail.com>
Message-ID: <44577180.8090802@lanl.gov>

Richard Smith wrote:

> Did you disable the SMI interrupt trap for access to VGA registers? 
> That may be getting fired and tripping things up.

Man, this is a weird one.

Disabling SMI on this thing can be touchy. Steve?

ron



From chris at suehsi.de  Tue May  2 18:36:30 2006
From: chris at suehsi.de (=?ISO-8859-1?Q?Christian_S=FChs?=)
Date: Tue, 02 May 2006 18:36:30 +0200
Subject: [LinuxBIOS] MB1030 / 3036 VGA comes up :D
In-Reply-To: <8a0c36780605020721v279f153ev7da4dc3ebb2d42d@mail.gmail.com>
References: <0E81348C5627674A9C0061413EBFF5F74F4442@SAUSEXMB2.amd.com>	<4454C416.4040906@suehsi.de>	<8a0c36780604301419y7f9b8045ie57b8f19bdeb6e2b@mail.gmail.com>	<4455E1AA.7070902@suehsi.de>	<8a0c36780605010706m2bed1a6eja546e5b941f46c1a@mail.gmail.com>	<445652FA.7030009@suehsi.de>	<8a0c36780605011133l5be7d2e8sbf8fa875824ffe8a@mail.gmail.com>	<44566EC7.4090104@suehsi.de>	<8a0c36780605011254i2edfa710h5ba481b7ae0a6093@mail.gmail.com>	<44573C06.5030709@suehsi.de>
	<8a0c36780605020721v279f153ev7da4dc3ebb2d42d@mail.gmail.com>
Message-ID: <44578A8E.9060608@suehsi.de>

Richard Smith schrieb:
>>copying VGA ROM Image from 0xfffc0000 to 0xc0000, 0x8000 bytes
>>entering emulator
>>inb(0x03cf) = 0x00
>>inb(0x03cf) = 0x00
>>inb(0x03cf) = 0x88
>>i
> 
> 
> So its crashing 'inside' of a printk.  0x3cf is a VGA index register.

Well, I think so. Many logs looks like the one above. The first 
character is printed. Than nothing no more.

> 
> 
>>Could it be a interrupt problem between the vga device and the serial port ?
> 
> 
> LinuxBIOS serial debug output is PIO. No interrupts.

:D Ok, ok ;)

> 
> Did you disable the SMI interrupt trap for access to VGA registers? 

Good question, there is a write to the CPU config registers. It is 
commented with "No SMI".

> That may be getting fired and tripping things up.

Fine :)

chris




From chris at suehsi.de  Tue May  2 18:41:15 2006
From: chris at suehsi.de (=?ISO-8859-1?Q?Christian_S=FChs?=)
Date: Tue, 02 May 2006 18:41:15 +0200
Subject: [LinuxBIOS] MB1030 / 3036 VGA comes up :D
In-Reply-To: <8a0c36780605020731w7d9d7048g524d640b4d3ed665@mail.gmail.com>
References: <0E81348C5627674A9C0061413EBFF5F74F4442@SAUSEXMB2.amd.com>	
	<4455E1AA.7070902@suehsi.de>	
	<8a0c36780605010706m2bed1a6eja546e5b941f46c1a@mail.gmail.com>	
	<445652FA.7030009@suehsi.de>	
	<8a0c36780605011133l5be7d2e8sbf8fa875824ffe8a@mail.gmail.com>	
	<44566EC7.4090104@suehsi.de> <445677BE.4080201@suehsi.de>	
	<8a0c36780605011259p721fb330j4d640fc17857cae8@mail.gmail.com>	
	<445733D0.6050004@suehsi.de> <44575B60.7050406@suehsi.de>
	<8a0c36780605020731w7d9d7048g524d640b4d3ed665@mail.gmail.com>
Message-ID: <44578BAB.80008@suehsi.de>

Richard Smith schrieb:
> On 5/2/06, Christian S?hs <chris at suehsi.de> wrote:
> 
>> as I say, the problem is after the first int10 and between the second
>> and third call.
>>
> 
> Thats much later than when it hangs with a printk right?

Sure, If I remember right, I have never seen an int10 vector before the 
system hangs with printk.
> 
> Try decreasing the delay until you find the smallest delay that does not 
> hang.

Ok, I will try 500, if that runs 1000 and so on.

chris


> 
> -- 
> Richard A. Smith
> 
> 





From smithbone at gmail.com  Tue May  2 17:49:51 2006
From: smithbone at gmail.com (Richard Smith)
Date: Tue, 2 May 2006 10:49:51 -0500
Subject: [LinuxBIOS] MB1030 / 3036 VGA comes up :D
In-Reply-To: <44577180.8090802@lanl.gov>
References: <0E81348C5627674A9C0061413EBFF5F74F4442@SAUSEXMB2.amd.com>
	<4455E1AA.7070902@suehsi.de>
	<8a0c36780605010706m2bed1a6eja546e5b941f46c1a@mail.gmail.com>
	<445652FA.7030009@suehsi.de>
	<8a0c36780605011133l5be7d2e8sbf8fa875824ffe8a@mail.gmail.com>
	<44566EC7.4090104@suehsi.de>
	<8a0c36780605011254i2edfa710h5ba481b7ae0a6093@mail.gmail.com>
	<44573C06.5030709@suehsi.de>
	<8a0c36780605020721v279f153ev7da4dc3ebb2d42d@mail.gmail.com>
	<44577180.8090802@lanl.gov>
Message-ID: <8a0c36780605020849pd65eacdlbe517bf3c08722f8@mail.gmail.com>

On 5/2/06, Ronald G Minnich <rminnich at lanl.gov> wrote:
> Richard Smith wrote:
>
> > Did you disable the SMI interrupt trap for access to VGA registers?
> > That may be getting fired and tripping things up.
>
> Man, this is a weird one.
>
> Disabling SMI on this thing can be touchy. Steve?

I think we are ok.  There is no SMM in the whole system.  The GX1
actually has real PCI config space registers.  And since he has an
external VGA VSA isn't necessary to do any of the VGA stuff.  But
Steve's previous mail on _completely_ disabling the internal VGA of
the cs5530 also mentioned that for an external setup some SMM trap
needs to be disabled.

I just went back and re-read steve's mail:

>If the F4 Video Configuration trap bit (F0, Index 42h, bit 1) is set,
the system will generate >SMIs when trying to access the PCI header
registers.  This should be clear for a non-SMM >system.

So he was talking about PCI acceses not generic IO accesses.  Not what
I was thinking.

What I was thinking of was the power mangement traps on the the IO
access.  But I just looked at the datasheet and they default to
disabled.  So unless we are turning them on I don't think they are
enabled.

>> So its crashing 'inside' of a printk.  0x3cf is a VGA index register.

>Well, I think so. Many logs looks like the one above. The first
>character is printed. Than nothing no more.

Man, this just smells like some sort of interrupt problem.  Can we
have printk do a cli() and  disable all interrupts when it runs?

--
Richard A. Smith



From chris at suehsi.de  Tue May  2 19:13:04 2006
From: chris at suehsi.de (=?ISO-8859-1?Q?Christian_S=FChs?=)
Date: Tue, 02 May 2006 19:13:04 +0200
Subject: [LinuxBIOS] MB1030 / 3036 VGA comes up :D
In-Reply-To: <44578BAB.80008@suehsi.de>
References: <0E81348C5627674A9C0061413EBFF5F74F4442@SAUSEXMB2.amd.com>		<4455E1AA.7070902@suehsi.de>		<8a0c36780605010706m2bed1a6eja546e5b941f46c1a@mail.gmail.com>		<445652FA.7030009@suehsi.de>		<8a0c36780605011133l5be7d2e8sbf8fa875824ffe8a@mail.gmail.com>		<44566EC7.4090104@suehsi.de>
	<445677BE.4080201@suehsi.de>		<8a0c36780605011259p721fb330j4d640fc17857cae8@mail.gmail.com>		<445733D0.6050004@suehsi.de>
	<44575B60.7050406@suehsi.de>	<8a0c36780605020731w7d9d7048g524d640b4d3ed665@mail.gmail.com>
	<44578BAB.80008@suehsi.de>
Message-ID: <44579320.90206@suehsi.de>


> 
>>Try decreasing the delay until you find the smallest delay that does not 
>>hang.
> 
> 
> Ok, I will try 500, if that runs 1000 and so on.
> 


udelay(250) for all functions work.
But VGA needs 3-4 minutes to come up ;)

Before, I have had a run with 500, but it seems I havn't wait long 
enough. :D I'm not sure but I think 500 should work to in 7-8 minutes.

chris



From eric at zyxod.com  Tue May  2 17:59:59 2006
From: eric at zyxod.com (Eric Poulsen)
Date: Tue, 02 May 2006 08:59:59 -0700
Subject: [LinuxBIOS] Solved: Makefile weirdness
In-Reply-To: <8a0c36780605020740v25d46fdeg1f4f7156f5ae594e@mail.gmail.com>
References: <44544DE9.1050701@zyxod.com> <4455926F.50007@zyxod.com>	
	<4456EEFC.4020904@zyxod.com>	
	<8a0c36780605020632q2f19a0b1wed3d7b559ed44823@mail.gmail.com>	
	<44576CB1.8000408@zyxod.com>
	<8a0c36780605020740v25d46fdeg1f4f7156f5ae594e@mail.gmail.com>
Message-ID: <445781FF.7090308@zyxod.com>

Referring only to the epia-m target:

Yes, it will fail, but strangely.  You'll get a bunch of linking errors
that says sections are overlapping.  You can increase ROM_IMAGE_SIZE,
buildtarget, make clean, make, and it will then compile, but it won't
actually run in-situ (Exception 13 just after protect vga bios).

Richard Smith wrote:
>> recompiled.  Some of the object files that wouldn't normally be touched
>> on the second make are now re-compiled, but they're re-compiled
>> incorrectly because of the updated options.
>>
>
> So that would mean that a fresh buildtarget and make with the vga
> options enabled should fail?  Is this what you orginally reported?
>
> -- 
> Richard A. Smith
>





From chris at suehsi.de  Tue May  2 19:43:29 2006
From: chris at suehsi.de (=?ISO-8859-1?Q?Christian_S=FChs?=)
Date: Tue, 02 May 2006 19:43:29 +0200
Subject: [LinuxBIOS] MB1030 / 3036 VGA comes up :D
In-Reply-To: <8a0c36780605020849pd65eacdlbe517bf3c08722f8@mail.gmail.com>
References: <0E81348C5627674A9C0061413EBFF5F74F4442@SAUSEXMB2.amd.com>	<4455E1AA.7070902@suehsi.de>	<8a0c36780605010706m2bed1a6eja546e5b941f46c1a@mail.gmail.com>	<445652FA.7030009@suehsi.de>	<8a0c36780605011133l5be7d2e8sbf8fa875824ffe8a@mail.gmail.com>	<44566EC7.4090104@suehsi.de>	<8a0c36780605011254i2edfa710h5ba481b7ae0a6093@mail.gmail.com>	<44573C06.5030709@suehsi.de>	<8a0c36780605020721v279f153ev7da4dc3ebb2d42d@mail.gmail.com>	<44577180.8090802@lanl.gov>
	<8a0c36780605020849pd65eacdlbe517bf3c08722f8@mail.gmail.com>
Message-ID: <44579A41.6080504@suehsi.de>


> 
> I think we are ok.  There is no SMM in the whole system.  The GX1
> actually has real PCI config space registers.  And since he has an
> external VGA VSA isn't necessary to do any of the VGA stuff.  But
> Steve's previous mail on _completely_ disabling the internal VGA of
> the cs5530 also mentioned that for an external setup some SMM trap
> needs to be disabled.

Can you have a second look to the cpu_setup section under 
/src/cpu/amd/model_gx1

I have read this again and again, but for me it seems there are some 
false writings to the registers.

However, the datasheet says, that the SMM bit can only be set, if CCR3 
is 0 or the CPU is in SMI mode.

If I'm right, this bit is not correct set, doesn't matter default is 00 
and so there should be no SMM.

Later CCR3 is set to 0x14 in that case there is a try to set a reserved 
bit. I'm not sure what happens in those case.

Also there is a third write to CCR3 0xf8 for that write the SUSP_SSM_EN 
bit is set to 1 whatever this means ;)

Datasheet page 50 - 56



>>>So its crashing 'inside' of a printk.  0x3cf is a VGA index register.
> 
> 
>>Well, I think so. Many logs looks like the one above. The first
>>character is printed. Than nothing no more.
> 
> 
> Man, this just smells like some sort of interrupt problem.  Can we
> have printk do a cli() and  disable all interrupts when it runs?
> 

I hope somebody has the answer.

> --
> Richard A. Smith
> 




From smithbone at gmail.com  Tue May  2 18:25:52 2006
From: smithbone at gmail.com (Richard Smith)
Date: Tue, 2 May 2006 11:25:52 -0500
Subject: [LinuxBIOS] MB1030 / 3036 VGA comes up :D
In-Reply-To: <44579320.90206@suehsi.de>
References: <0E81348C5627674A9C0061413EBFF5F74F4442@SAUSEXMB2.amd.com>
	<8a0c36780605011133l5be7d2e8sbf8fa875824ffe8a@mail.gmail.com>
	<44566EC7.4090104@suehsi.de> <445677BE.4080201@suehsi.de>
	<8a0c36780605011259p721fb330j4d640fc17857cae8@mail.gmail.com>
	<445733D0.6050004@suehsi.de> <44575B60.7050406@suehsi.de>
	<8a0c36780605020731w7d9d7048g524d640b4d3ed665@mail.gmail.com>
	<44578BAB.80008@suehsi.de> <44579320.90206@suehsi.de>
Message-ID: <8a0c36780605020925h6110f2d8pa656fde32cc5adfb@mail.gmail.com>

On 5/2/06, Christian S?hs <chris at suehsi.de> wrote:

> udelay(250) for all functions work.
> But VGA needs 3-4 minutes to come up ;)

That seems to suggest that it is some sort of time thing.  Both printk
and udelay do similar IO operations. A couple of writes to set things
up and then loads of reads waiting on it to happen.

Its not dying due to the fact that there is additional IO happening or
you should have been able to get down to udelay(0) and it still hang.

Man.. like Ron says this is wierd..

So how can we get more debug info out of this system?  Our primary
debug method dies.

You can run this under the user mode emulator with the IO prints
enabled it works right?

Can you do that and look at what IO its doing when it starts up?. 
Probally don't need more than the first 50 lines or so.  Maybe we can
exclude printing on IO port ranges that cause  problems.

All I want to see it how it accesses the timer.  Add my original
if(port < 0x53) stuff to the usermode emu and send that to me as well.

--
Richard A. Smith



From smithbone at gmail.com  Tue May  2 18:31:04 2006
From: smithbone at gmail.com (Richard Smith)
Date: Tue, 2 May 2006 11:31:04 -0500
Subject: [LinuxBIOS] MB1030 / 3036 VGA comes up :D
In-Reply-To: <44579A41.6080504@suehsi.de>
References: <0E81348C5627674A9C0061413EBFF5F74F4442@SAUSEXMB2.amd.com>
	<445652FA.7030009@suehsi.de>
	<8a0c36780605011133l5be7d2e8sbf8fa875824ffe8a@mail.gmail.com>
	<44566EC7.4090104@suehsi.de>
	<8a0c36780605011254i2edfa710h5ba481b7ae0a6093@mail.gmail.com>
	<44573C06.5030709@suehsi.de>
	<8a0c36780605020721v279f153ev7da4dc3ebb2d42d@mail.gmail.com>
	<44577180.8090802@lanl.gov>
	<8a0c36780605020849pd65eacdlbe517bf3c08722f8@mail.gmail.com>
	<44579A41.6080504@suehsi.de>
Message-ID: <8a0c36780605020931m76b4265em26f6a7027c510eae@mail.gmail.com>

> > the cs5530 also mentioned that for an external setup some SMM trap
> > needs to be disabled.
>
> Can you have a second look to the cpu_setup section under
> /src/cpu/amd/model_gx1
>
> I have read this again and again, but for me it seems there are some
> false writings to the registers.
>
> However, the datasheet says, that the SMM bit can only be set, if CCR3
> is 0 or the CPU is in SMI mode.
>
> If I'm right, this bit is not correct set, doesn't matter default is 00
> and so there should be no SMM.
>
> Later CCR3 is set to 0x14 in that case there is a try to set a reserved
> bit. I'm not sure what happens in those case.
>
> Also there is a third write to CCR3 0xf8 for that write the SUSP_SSM_EN
> bit is set to 1 whatever this means ;)
>
> Datasheet page 50 - 56

I'll let Steve comment on all this before I try to wrap my head around it.

--
Richard A. Smith



From eric at zyxod.com  Tue May  2 18:45:33 2006
From: eric at zyxod.com (Eric Poulsen)
Date: Tue, 02 May 2006 09:45:33 -0700
Subject: [LinuxBIOS] Solved: Makefile weirdness
In-Reply-To: <20060502144809.GA19445@coresystems.de>
References: <44544DE9.1050701@zyxod.com>
	<4455926F.50007@zyxod.com>	<4456EEFC.4020904@zyxod.com>	<8a0c36780605020632q2f19a0b1wed3d7b559ed44823@mail.gmail.com>	<44576CB1.8000408@zyxod.com>
	<20060502144809.GA19445@coresystems.de>
Message-ID: <44578CAD.8060405@zyxod.com>

Attached below.

The LinuxBIOSv2.bad directory is the one that doesn't complete the
compile, because of linking errors.  This is why some files are
missing.  The LinuxBIOSv2 directory is the "working" build.

Here's the build process (done in a way so that the diff file won't be
cluttered with directory names):

   1. svn download LinuxBIOS
   2. Enter via/epia-m target
   3. Edit Config.lb, adding  CONFIG_CONSOLE_VGA, CONFIG_PCI_ROM_RUN
   4. builtarget
   5. make
   6. [link errors]
   7. Copy entire LinuxBIOSv2 tree to LinuxBIOSv2.bad.
   8. (still within LinuxBIOSv2, _not_ .bad version), Edit Config.lb,
      _removing_ CONFIG_CONSOLE_VGA, CONFIG_PCI_ROM_RUN
   9. buildtarget
  10. make clean (merely to clear out the "bad" object files)
  11. make
  12. Edit Config.lb, re-enable CONFIG_CONSOLE_VGA, CONFIG_PCI_ROM_RUN
  13. buildtarget
  14. make [Note, _no_ use of make clean]
  15. [successful compile, working linuxbios.rom]
  16. diff LinuxBIOSv2 LinuxBIOSv2.bad -r > diff.txt [Attached below]

That's all, folks.

Stefan Reinauer wrote:
> * Eric Poulsen <eric at zyxod.com> [060502 16:29]:
>   
>> I don't think this addresses the issue, however.  It happens to _work_ 
>> when I do a make, update Config.lb, buildtarget, then a final make.  If 
>> I put a make clean in after the buildtarget, that's where it fails.
>>     
>  
> So could you diff the object files so see where the difference is?
>
> S.
>
>   



diff -r LinuxBIOSv2/targets/via/epia-m/epia-m/fallback/auto.inc
LinuxBIOSv2.bad/targets/via/epia-m/epia-m/fallback/auto.inc
61c61
< .byte 0x33
---
> .byte 0x32
63,64c63,64
< .byte 0x35
< .byte 0x30
---
> .byte 0x33
> .byte 0x31
Only in LinuxBIOSv2/targets/via/epia-m/epia-m/fallback: buildrom
Binary files LinuxBIOSv2/targets/via/epia-m/epia-m/fallback/crt0.o and
LinuxBIOSv2.bad/targets/via/epia-m/epia-m/fallback/crt0.o differ
diff -r LinuxBIOSv2/targets/via/epia-m/epia-m/fallback/crt0.s
LinuxBIOSv2.bad/targets/via/epia-m/epia-m/fallback/crt0.s
276c276
< .byte 0x33
---
> .byte 0x32
278,279c278,279
< .byte 0x35
< .byte 0x30
---
> .byte 0x33
> .byte 0x31
Binary files LinuxBIOSv2/targets/via/epia-m/epia-m/fallback/device.o and
LinuxBIOSv2.bad/targets/via/epia-m/epia-m/fallback/device.o differ
Only in LinuxBIOSv2/targets/via/epia-m/epia-m/fallback: linuxbios
Binary files LinuxBIOSv2/targets/via/epia-m/epia-m/fallback/linuxbios.a
and LinuxBIOSv2.bad/targets/via/epia-m/epia-m/fallback/linuxbios.a differ
Only in LinuxBIOSv2/targets/via/epia-m/epia-m/fallback: linuxbios.map
Only in LinuxBIOSv2/targets/via/epia-m/epia-m/fallback: linuxbios.rom
Only in LinuxBIOSv2/targets/via/epia-m/epia-m/fallback: linuxbios.strip
Binary files
LinuxBIOSv2/targets/via/epia-m/epia-m/fallback/linuxbios_ram and
LinuxBIOSv2.bad/targets/via/epia-m/epia-m/fallback/linuxbios_ram differ
Binary files
LinuxBIOSv2/targets/via/epia-m/epia-m/fallback/linuxbios_ram.bin and
LinuxBIOSv2.bad/targets/via/epia-m/epia-m/fallback/linuxbios_ram.bin differ
diff -r LinuxBIOSv2/targets/via/epia-m/epia-m/fallback/linuxbios_ram.map
LinuxBIOSv2.bad/targets/via/epia-m/epia-m/fallback/linuxbios_ram.map
171,499c171,537
< 0000611c T pci_probe_dev
< 0000643d T pci_scan_bus
< 00006591 T do_pci_scan_bridge
< 0000666e T pci_scan_bridge
< 00006683 T pci_assign_irqs
< 000067c4 T console_init
< 000067f9 t __console_tx_byte
< 00006823 T console_tx_flush
< 00006845 T console_tx_byte
< 0000686e T console_rx_byte
< 000068af T console_tst_byte
< 000068da T post_code
< 000068e4 T die
< 00006908 T hardwaremain
< 000069ac T setup_i8259
< 000069d8 T mdelay
< 000069fb T delay
< 00006a20 T x86_exception
< 00006a68 t ht_lookup_slave_capability
< 00006a9e T hypertransport_scan_chain
< 00006fce T ht_scan_bridge
< 00006fe4 t skip_atoi
< 00007019 t number
< 0000720b T vtxprintf
< 00007594 T root_dev_read_resources
< 0000764e T root_dev_set_resources
< 00007695 T scan_static_bus
< 000077ca T enable_childrens_resources
< 0000780e T root_dev_enable_resources
< 00007817 T root_dev_scan_bus
< 00007820 T root_dev_init
< 00007825 T root_dev_reset
< 0000783c t cardbus_record_bridge_resource
< 0000791b t cardbus_size_bridge_resource
< 00007970 T cardbus_read_resources
< 00007b22 T cardbus_enable_resources
< 00007b7d T cardbus_scan_bus
< 00007b86 T cardbus_scan_bridge
< 00007c68 T uart8250_tx_byte
< 00007c8a T uart8250_can_rx_byte
< 00007c99 T uart8250_rx_byte
< 00007cb2 T uart8250_init
< 00007cf3 T init_uart8250
< 00007d24 T dev_find_slot
< 00007d5f T dev_find_slot_on_smbus
< 00007d9a T dev_find_device
< 00007dc4 T dev_find_class
< 00007ded T path_eq
< 00007e4c T find_dev_path
< 00007e7c T alloc_find_dev
< 00007ea4 T dev_path
< 00007f93 T bus_path
< 00007fbe T compact_resources
< 00008024 T probe_resource
< 00008055 T new_resource
< 000080f4 T find_resource
< 0000813c T resource_end
< 0000819c T resource_max
< 000081f7 T resource_type
< 0000827c T report_resource_stored
< 00008314 T search_bus_resources
< 00008395 T search_global_resources
< 000083f1 T dev_set_enabled
< 0000843f T disable_children
< 0000848c T alloc_dev
< 00008525 t round
< 00008574 t read_resources
< 00008642 t pick_largest_resource
< 000086ca T compute_allocate_resource
< 000088f0 T assign_resources
< 00008946 T enable_resources
< 00008982 T reset_bus
< 000089b9 T scan_bus
< 00008a50 T dev_enumerate
< 00008aa9 T dev_configure
< 00008b8c T dev_enable
< 00008bb3 T dev_initialize
< 00008c50 T init_timer
< 00008c93 T udelay
< 00008cf4 T memcpy
< 00008d18 T memmove
< 00008d60 t pci_conf2_read_config8
< 00008da8 t pci_conf2_read_config16
< 00008df1 t pci_conf2_read_config32
< 00008e38 t pci_conf2_write_config8
< 00008e7b t pci_conf2_write_config16
< 00008ebf t pci_conf2_write_config32
< 00008f00 t pci_conf1_read_config8
< 00008f38 t pci_conf1_read_config16
< 00008f71 t pci_conf1_read_config32
< 00008f9b t pci_conf1_write_config8
< 00008fd7 t pci_conf1_write_config16
< 00009014 t pci_conf1_write_config32
< 00009044 t rtc_checksum_valid
< 00009089 T rtc_init
< 00009188 T x86_enable_cache
< 000091b0 t str_tx_byte
< 000091c5 T vsprintf
< 000091eb T sprintf
< 00009200 T malloc_mark
< 00009210 T malloc_release
< 0000921f T malloc
< 00009267 T free
< 0000926c T memset
< 00009288 T pciexp_scan_bus
< 000092ee T pciexp_scan_bridge
< 00009304 T move_gdt
< 00009357 T write_tables
< 000093dc T acpi_fill_madt
< 000093e1 T acpi_fill_srat
< 000093e6 T write_acpi_tables
< 000094c0 T write_pirq_routing_table
< 000094cc T pcix_scan_bus
< 000095ce T pcix_speed
< 00009618 T pcix_scan_bridge
< 00009684 T acpi_create_fadt
< 00009988 T verify_ip_checksum
< 00009a6f T elfload
< 0000a2bb T elfboot
< 0000a424 T elf_check_arch
< 0000a44b T jmp_to_elf_entry
< 0000a518 T memcmp
< 0000a544 T acpi_checksum
< 0000a561 T acpi_add_table
< 0000a5cd T acpi_create_madt_lapic
< 0000a5f4 T acpi_create_madt_ioapic
< 0000a61e T acpi_create_madt_irqoverride
< 0000a64b T acpi_create_madt_lapic_nmi
< 0000a672 T acpi_create_madt
< 0000a6fc T acpi_create_srat_lapic
< 0000a723 T acpi_create_srat_mem
< 0000a768 T acpi_create_srat
< 0000a7eb T acpi_create_hpet
< 0000a888 T acpi_create_facs
< 0000a8e0 T acpi_write_rsdt
< 0000a942 T acpi_write_rsdp
< 0000a994 t rl5c476_init
< 0000aad0 T rl5c476_read_resources
< 0000ab2a T rl5c476_set_resources
< 0000abbd T southbridge_init
< 0000abd4 T compute_ip_checksum
< 0000ac25 T add_ip_checksums
< 0000ac6c t northbridge_init
< 0000ad87 t nullfunc
< 0000ad8c t agp_init
< 0000adef t vga_init
< 0000ae6c t vga_read_resources
< 0000ae86 t pci_domain_read_resources
< 0000aed5 t ram_resource
< 0000af15 t tolm_test
< 0000af47 t pci_domain_set_resources
< 0000b05f t pci_domain_scan_bus
< 0000b07c t cpu_bus_init
< 0000b08c t cpu_bus_noop
< 0000b091 t enable_dev
< 0000b0c0 t gdtarg
< 0000b0c6 t __mygdtaddr
< 0000b0cc t __mygdt
< 0000b104 t __mygdt_end
< 0000b104 t __myidt
< 0000b10c T vga_enable_console
< 0000b10c t real_mode_switch_end
< 0000b125 t __vga_ec_16bit
< 0000b141 t __vga_ec_real
< 0000b18b t vga_ec_restart
< 0000b1a8 t vga_ec_exit
< 0000b1b1 T do_vgabios
< 0000b292 t __stack
< 0000b2aa t __rms_16bit
< 0000b2c6 t __rms_real
< 0000b301 t vgarestart
< 0000b31e T vga_exit
< 0000b365 T handler
< 0000b368 t idthandle
< 0000b371 t end_idthandle
< 0000b373 T debughandler
< 0000b376 t debughandle
< 0000b37a t dbh1
< 0000b37e t end_debughandle
< 0000b380 T callbiosint
< 0000b383 t callbiosint16
< 0000b3a3 t biosprotect
< 0000b3c4 t __rms_16bit2
< 0000b3e0 t __rms_real2
< 0000b40a T handleint21
< 0000b4ac T setup_realmode_idt
< 0000b544 T pcibios
< 0000b741 T biosint
< 0000b8f0 T copy_pirq_routing_table
< 0000ba88 t pnp_enter_ext_func_mode
< 0000ba96 t pnp_exit_ext_func_mode
< 0000baa4 t vt1211_init
< 0000bb29 T vt1211_pnp_enable_resources
< 0000bb60 T vt1211_pnp_set_resources
< 0000bce9 T vt1211_pnp_enable
< 0000bd1e t enable_dev
< 0000bd44 T stream_init
< 0000bd6f T stream_fini
< 0000bd74 T stream_skip
< 0000bdbf T stream_read
< 0000bde8 T initialize_cpus
< 0000be28 t pci_sanity_check
< 0000be9c T pci_check_direct
< 0000bf44 T pci_set_method
< 0000bf78 T lb_table_init
< 0000bfb8 T lb_first_record
< 0000bfc3 T lb_last_record
< 0000bfd1 T lb_next_record
< 0000bfdc T lb_new_record
< 0000c01d T lb_memory
< 0000c037 T lb_mainboard
< 0000c113 T lb_cmos_checksum
< 0000c149 T lb_strings
< 0000c1a7 T lb_memory_range
< 0000c20c T get_lb_mem
< 0000c216 T lb_table_fini
< 0000c3d4 t lb_cleanup_memory_ranges
< 0000c66f t lb_add_memory_range
< 0000c94e t build_lb_mem_range
< 0000c96b T write_linuxbios_table
< 0000ca38 T set_boot_successful
< 0000ca63 T boot_successful
< 0000ca6c T pnp_write_config
< 0000ca86 T pnp_read_config
< 0000ca9c T pnp_set_logical_device
< 0000cab1 T pnp_set_enable
< 0000caca T pnp_read_enable
< 0000cae3 T pnp_set_iobase
< 0000cb23 T pnp_set_irq
< 0000cb3a T pnp_set_drq
< 0000cb51 T pnp_read_resources
< 0000cb56 T pnp_set_resources
< 0000cc43 T pnp_enable_resources
< 0000cc5d T pnp_enable
< 0000cc80 t pnp_get_ioresource
< 0000ccff T pnp_enable_devices
< 0000ce80 t have_cpuid_p
< 0000cea2 T cpu_initialize
< 0000d0e0 R _rodata
< 0000d0e0 R console_drivers
< 0000d0e0 T _etext
< 0000d0e0 r uart8250_console
< 0000d0f4 r vga_console
< 0000d108 R econsole_drivers
< 0000d108 R pci_drivers
< 0000d108 r lpc_driver
< 0000d110 r northbridge_driver
< 0000d118 r northbridge_driver
< 0000d120 r ricoh_rl5c476_driver
< 0000d128 r vga_driver
< 0000d130 r agp_driver
< 0000d138 r northbridge_driver
< 0000d140 R cpu_drivers
< 0000d140 R epci_drivers
< 0000d140 r driver
< 0000d148 R ecpu_drivers
< 0000d160 r riserPins
< 0000d164 r cbPins
< 0000d168 r slotPins
< 0000d16c r vgaPins
< 0000d170 r enetPins
< 0000d174 r vt8235Pins
< 0000d178 r usbPins
< 0000d17c r firewirePins
< 0000d180 r pciIrqs
< 0000d184 r __FUNCTION__.0
< 0000d196 r div.0
< 0000d19e r __FUNCTION__.0
< 0000d1a7 r __func__.0
< 0000d1c0 R linuxbios_assembler
< 0000d220 R linuxbios_linker
< 0000d260 R linuxbios_compiler
< 0000d2a2 R linuxbios_compile_domain
< 0000d2a3 R linuxbios_compile_host
< 0000d2a6 R linuxbios_compile_by
< 0000d2ab R linuxbios_compile_time
< 0000d2b4 R linuxbios_build
< 0000d2d1 R linuxbios_extra_version
< 0000d2dc R linuxbios_version
< 0000d2e2 R mainboard_part_number
< 0000d2e9 R mainboard_vendor
< 0000d2ed r link_width_to_pow2.0
< 0000d2f5 r pow2_to_link_width.1
< 0000d348 R pci_cf8_conf2
< 0000d360 R pci_cf8_conf1
< 0000d380 R intel_irq_routing_table
< 0000d3f0 r conventional.0
< 0000d401 r pcix_66mhz.1
< 0000d40d r pcix_100mhz.2
< 0000d41a r pcix_133mhz.3
< 0000d427 r pcix_266mhz.4
< 0000d434 r pcix_533mhz.5
< 0000d441 r unknown.6
< 0000d48c r ramregs.0
< 0000d4a8 r __FUNCTION__.0
< 0000d4f4 r __FUNCTION__.1
< 0000d500 r __FUNCTION__.0
< 0000d520 r strings.0
< 0000eed4 R _erodata
< 0000eee0 D _data
< 0000eee0 D gdt
< 0000ef08 D gdt_end
< 0000ef08 D idtarg
< 0000ef10 d _idt
< 0000efb0 d _idt_end
< 0000efc0 d vt8235_lpc_ops
< 0000efec D southbridge_via_vt8235_ops
< 0000f000 d ide_ops
< 0000f040 d nic_ops
< 0000f080 d cpu_table
< 0000f100 d cpu_dev_ops
< 0000f140 d mtrr_msr
< 0000f16c D default_console_loglevel
< 0000f170 D minimum_console_loglevel
< 0000f174 D default_message_loglevel
< 0000f178 D console_loglevel
< 0000f180 D default_pci_ops_bus
< 0000f1c0 D default_pci_ops_dev
< 0000f1ec d pci_dev_ops_pci
< 0000f200 D default_ht_ops_bus
< 0000f240 D default_dev_ops_root
< 0000f280 D default_cardbus_ops_bus
< 0000f2ac D all_devices
< 0000f2c0 D _dev25
< 0000f560 D _dev22
< 0000f800 D _dev21
< 0000faa0 D _dev15
< 0000fd40 D _dev14
< 0000ffe0 D _dev13
---
> 00006142 T pci_probe_dev
> 00006461 T pci_scan_bus
> 000065b5 T do_pci_scan_bridge
> 00006692 T pci_scan_bridge
> 000066a7 T pci_assign_irqs
> 000067e8 T console_init
> 0000681d t __console_tx_byte
> 00006847 T console_tx_flush
> 00006869 T console_tx_byte
> 00006892 T console_rx_byte
> 000068d3 T console_tst_byte
> 000068fe T post_code
> 00006908 T die
> 0000692c T hardwaremain
> 000069d0 T setup_i8259
> 000069fc T mdelay
> 00006a1f T delay
> 00006a44 T x86_exception
> 00006a8c t ht_lookup_slave_capability
> 00006ac2 T hypertransport_scan_chain
> 00006ff2 T ht_scan_bridge
> 00007008 t skip_atoi
> 0000703d t number
> 0000722f T vtxprintf
> 000075b8 T root_dev_read_resources
> 00007672 T root_dev_set_resources
> 000076b9 T scan_static_bus
> 000077ee T enable_childrens_resources
> 00007832 T root_dev_enable_resources
> 0000783b T root_dev_scan_bus
> 00007844 T root_dev_init
> 00007849 T root_dev_reset
> 00007860 t cardbus_record_bridge_resource
> 0000793f t cardbus_size_bridge_resource
> 00007994 T cardbus_read_resources
> 00007b46 T cardbus_enable_resources
> 00007ba1 T cardbus_scan_bus
> 00007baa T cardbus_scan_bridge
> 00007c8c T uart8250_tx_byte
> 00007cae T uart8250_can_rx_byte
> 00007cbd T uart8250_rx_byte
> 00007cd6 T uart8250_init
> 00007d17 T init_uart8250
> 00007d48 T dev_find_slot
> 00007d83 T dev_find_slot_on_smbus
> 00007dbe T dev_find_device
> 00007de8 T dev_find_class
> 00007e11 T path_eq
> 00007e70 T find_dev_path
> 00007ea0 T alloc_find_dev
> 00007ec8 T dev_path
> 00007fb7 T bus_path
> 00007fe2 T compact_resources
> 00008048 T probe_resource
> 00008079 T new_resource
> 00008118 T find_resource
> 00008160 T resource_end
> 000081c0 T resource_max
> 0000821b T resource_type
> 000082a0 T report_resource_stored
> 00008338 T search_bus_resources
> 000083b9 T search_global_resources
> 00008415 T dev_set_enabled
> 00008463 T disable_children
> 000084b0 T alloc_dev
> 00008549 t round
> 00008598 t read_resources
> 00008666 t pick_largest_resource
> 000086ee T compute_allocate_resource
> 00008914 T assign_resources
> 0000896a T enable_resources
> 000089a6 T reset_bus
> 000089dd T scan_bus
> 00008a74 T dev_enumerate
> 00008acd T dev_configure
> 00008c69 T dev_enable
> 00008c90 T dev_initialize
> 00008d2c T init_timer
> 00008d6f T udelay
> 00008dd0 T memcpy
> 00008df4 T memmove
> 00008e3c T pci_rom_probe
> 00008f1d T pci_rom_load
> 00008fd8 t pci_conf2_read_config8
> 00009020 t pci_conf2_read_config16
> 00009069 t pci_conf2_read_config32
> 000090b0 t pci_conf2_write_config8
> 000090f3 t pci_conf2_write_config16
> 00009137 t pci_conf2_write_config32
> 00009178 t pci_conf1_read_config8
> 000091b0 t pci_conf1_read_config16
> 000091e9 t pci_conf1_read_config32
> 00009213 t pci_conf1_write_config8
> 0000924f t pci_conf1_write_config16
> 0000928c t pci_conf1_write_config32
> 000092bc t rtc_checksum_valid
> 00009301 T rtc_init
> 00009400 T x86_enable_cache
> 00009428 T getIntVect
> 00009455 T pushw
> 0000947f T run_bios_int
> 000094d5 T x_inb
> 000094e1 T x_inw
> 000094ee T x_inl
> 000094f7 T x_outb
> 00009503 T x_outw
> 00009510 T x_outl
> 0000951c T do_int
> 00009583 T run_bios
> 000096d4 t str_tx_byte
> 000096e9 T vsprintf
> 0000970f T sprintf
> 00009724 T malloc_mark
> 00009734 T malloc_release
> 00009743 T malloc
> 0000978b T free
> 00009790 T memset
> 000097ac T pciexp_scan_bus
> 00009812 T pciexp_scan_bridge
> 00009828 T move_gdt
> 0000987b T write_tables
> 00009900 T acpi_fill_madt
> 00009905 T acpi_fill_srat
> 0000990a T write_acpi_tables
> 000099e4 T write_pirq_routing_table
> 000099f0 T pcix_scan_bus
> 00009af2 T pcix_speed
> 00009b3c T pcix_scan_bridge
> 00009ba8 T x86emu_intr_raise
> 00009be1 T X86EMU_exec
> 00009ceb T X86EMU_halt_sys
> 00009cfd T fetch_decode_modrm
> 00009d49 T fetch_byte_imm
> 00009d76 T fetch_word_imm
> 00009da0 T fetch_long_imm
> 00009dc7 t get_data_segment
> 00009e69 T fetch_data_byte
> 00009e83 T fetch_data_word
> 00009e9d T fetch_data_long
> 00009ebb T fetch_data_byte_abs
> 00009ed3 T fetch_data_word_abs
> 00009eeb T fetch_data_long_abs
> 00009f03 T store_data_byte
> 00009f28 T store_data_word
> 00009f4d T store_data_long
> 00009f6b T store_data_byte_abs
> 00009f8c T store_data_word_abs
> 00009fad T store_data_long_abs
> 00009fcd T decode_rm_byte_register
> 0000a036 T decode_rm_word_register
> 0000a09f T decode_rm_long_register
> 0000a108 T decode_rm_seg_register
> 0000a163 T decode_sib_si
> 0000a1d3 T decode_sib_address
> 0000a2b9 T decode_rm00_address
> 0000a3ba T decode_rm01_address
> 0000a4e3 T decode_rm10_address
> 0000a61d T decode_rmXX_address
> 0000a648 T acpi_create_fadt
> 0000a94c T verify_ip_checksum
> 0000aa33 T elfload
> 0000b27f T elfboot
> 0000b3e8 T elf_check_arch
> 0000b40f T jmp_to_elf_entry
> 0000b4dc T memcmp
> 0000b508 T acpi_checksum
> 0000b525 T acpi_add_table
> 0000b591 T acpi_create_madt_lapic
> 0000b5b8 T acpi_create_madt_ioapic
> 0000b5e2 T acpi_create_madt_irqoverride
> 0000b60f T acpi_create_madt_lapic_nmi
> 0000b636 T acpi_create_madt
> 0000b6c0 T acpi_create_srat_lapic
> 0000b6e7 T acpi_create_srat_mem
> 0000b72c T acpi_create_srat
> 0000b7af T acpi_create_hpet
> 0000b84c T acpi_create_facs
> 0000b8a4 T acpi_write_rsdt
> 0000b906 T acpi_write_rsdp
> 0000b958 T pcibios_handler
> 0000bb88 T x86emuOp_illegal_op
> 0000bbb4 T x86emuOp_genop_byte_RM_R
> 0000bc66 T x86emuOp_genop_word_RM_R
> 0000bd88 T x86emuOp_genop_byte_R_RM
> 0000be0e T x86emuOp_genop_word_R_RM
> 0000bef6 T x86emuOp_genop_byte_AL_IMM
> 0000bf32 T x86emuOp_genop_word_AX_IMM
> 0000bfa7 T x86emuOp_push_ES
> 0000bfc3 T x86emuOp_pop_ES
> 0000bfdd T x86emuOp_push_CS
> 0000bff9 T x86emuOp_two_byte
> 0000c032 T x86emuOp_push_SS
> 0000c04e T x86emuOp_pop_SS
> 0000c068 T x86emuOp_push_DS
> 0000c084 T x86emuOp_pop_DS
> 0000c09e T x86emuOp_segovr_ES
> 0000c0aa T x86emuOp_daa
> 0000c0cb T x86emuOp_segovr_CS
> 0000c0d7 T x86emuOp_das
> 0000c0f8 T x86emuOp_segovr_SS
> 0000c104 T x86emuOp_aaa
> 0000c126 T x86emuOp_segovr_DS
> 0000c132 T x86emuOp_aas
> 0000c154 T x86emuOp_inc_register
> 0000c1a5 T x86emuOp_dec_register
> 0000c1f6 T x86emuOp_push_register
> 0000c23a T x86emuOp_pop_register
> 0000c284 T x86emuOp_push_all
> 0000c366 T x86emuOp_pop_all
> 0000c422 T x86emuOp_segovr_FS
> 0000c42e T x86emuOp_segovr_GS
> 0000c43a T x86emuOp_prefix_data
> 0000c449 T x86emuOp_prefix_addr
> 0000c458 T x86emuOp_push_word_IMM
> 0000c49a T x86emuOp_imul_word_IMM
> 0000c5f4 T x86emuOp_push_byte_IMM
> 0000c613 T x86emuOp_imul_byte_IMM
> 0000c778 T x86emuOp_ins_byte
> 0000c78e T x86emuOp_ins_word
> 0000c7b2 T x86emuOp_outs_byte
> 0000c7c8 T x86emuOp_outs_word
> 0000c7ec T x86emuOp_jump_near_cond
> 0000c827 T x86emuOp_opc80_byte_RM_IMM
> 0000c8c3 T x86emuOp_opc81_word_RM_IMM
> 0000c9c3 T x86emuOp_opc82_byte_RM_IMM
> 0000ca5f T x86emuOp_opc83_word_RM_IMM
> 0000cb6d T x86emuOp_test_byte_RM_R
> 0000cbec T x86emuOp_test_word_RM_R
> 0000cca8 T x86emuOp_xchg_byte_RM_R
> 0000cd29 T x86emuOp_xchg_word_RM_R
> 0000cdf8 T x86emuOp_mov_byte_RM_R
> 0000ce64 T x86emuOp_mov_word_RM_R
> 0000cf10 T x86emuOp_mov_byte_R_RM
> 0000cf7a T x86emuOp_mov_word_R_RM
> 0000d02d T x86emuOp_mov_word_RM_SR
> 0000d09b T x86emuOp_lea_word_R_M
> 0000d0e6 T x86emuOp_mov_word_SR_RM
> 0000d153 T x86emuOp_pop_RM
> 0000d20f T x86emuOp_nop
> 0000d21e T x86emuOp_xchg_word_AX_register
> 0000d275 T x86emuOp_cbw
> 0000d2c0 T x86emuOp_cwd
> 0000d2fe T x86emuOp_call_far_IMM
> 0000d34a T x86emuOp_wait
> 0000d359 T x86emuOp_pushf_word
> 0000d38d T x86emuOp_popf_word
> 0000d3b9 T x86emuOp_sahf
> 0000d3d4 T x86emuOp_lahf
> 0000d3f0 T x86emuOp_mov_AL_M_IMM
> 0000d412 T x86emuOp_mov_AX_M_IMM
> 0000d44c T x86emuOp_mov_M_AL_IMM
> 0000d471 T x86emuOp_mov_M_AX_IMM
> 0000d4af T x86emuOp_movs_byte
> 0000d542 T x86emuOp_movs_word
> 0000d61e T x86emuOp_cmps_byte
> 0000d729 T x86emuOp_cmps_word
> 0000d8a1 T x86emuOp_test_AL_IMM
> 0000d8c6 T x86emuOp_test_AX_IMM
> 0000d917 T x86emuOp_stos_byte
> 0000d9bf T x86emuOp_stos_word
> 0000da83 T x86emuOp_lods_byte
> 0000db11 T x86emuOp_lods_word
> 0000dbc0 T x86emuOp_scas_byte
> 0000dce9 T x86emuOp_scas_word
> 0000deab T x86emuOp_mov_byte_register_IMM
> 0000ded4 T x86emuOp_mov_word_register_IMM
> 0000df1e T x86emuOp_opcC0_byte_RM_MEM
> 0000dfb6 T x86emuOp_opcC1_word_RM_MEM
> 0000e0b5 T x86emuOp_ret_near_IMM
> 0000e0df T x86emuOp_ret_near
> 0000e0f9 T x86emuOp_les_R_IMM
> 0000e15e T x86emuOp_lds_R_IMM
> 0000e1c3 T x86emuOp_mov_byte_RM_IMM
> 0000e24a T x86emuOp_mov_word_RM_IMM
> 0000e30e T x86emuOp_enter
> 0000e3a7 T x86emuOp_leave
> 0000e3cd T x86emuOp_ret_far_IMM
> 0000e402 T x86emuOp_ret_far
> 0000e427 T x86emuOp_int3
> 0000e49c T x86emuOp_int_IMM
> 0000e52a T x86emuOp_into
> 0000e5a8 T x86emuOp_iret
> 0000e5da T x86emuOp_opcD0_byte_RM_1
> 0000e65b T x86emuOp_opcD1_word_RM_1
> 0000e72f T x86emuOp_opcD2_byte_RM_CL
> 0000e7c4 T x86emuOp_opcD3_word_RM_CL
> 0000e8b6 T x86emuOp_aam
> 0000e8ff T x86emuOp_aad
> 0000e926 T x86emuOp_xlat
> 0000e952 T x86emuOp_loopne
> 0000e993 T x86emuOp_loope
> 0000e9d4 T x86emuOp_loop
> 0000ea0c T x86emuOp_jcxz
> 0000ea39 T x86emuOp_in_byte_AL_IMM
> 0000ea5c T x86emuOp_in_word_AX_IMM
> 0000ea9b T x86emuOp_out_byte_IMM_AL
> 0000eac1 T x86emuOp_out_word_IMM_AX
> 0000eb06 T x86emuOp_call_near_IMM
> 0000eb36 T x86emuOp_jump_near_IMM
> 0000eb52 T x86emuOp_jump_far_IMM
> 0000eb7c T x86emuOp_jump_byte_IMM
> 0000eb99 T x86emuOp_in_byte_AL_DX
> 0000ebbb T x86emuOp_in_word_AX_DX
> 0000ebfb T x86emuOp_out_byte_DX_AL
> 0000ec20 T x86emuOp_out_word_DX_AX
> 0000ec65 T x86emuOp_lock
> 0000ec74 T x86emuOp_repne
> 0000ec8b T x86emuOp_repe
> 0000eca1 T x86emuOp_halt
> 0000eccb T x86emuOp_cmc
> 0000ece1 T x86emuOp_opcF6_byte_RM
> 0000ee2d T x86emuOp_opcF7_word_RM
> 0000f08a T x86emuOp_clc
> 0000f0a0 T x86emuOp_stc
> 0000f0b6 T x86emuOp_cli
> 0000f0cf T x86emuOp_sti
> 0000f0e8 T x86emuOp_cld
> 0000f101 T x86emuOp_std
> 0000f11a T x86emuOp_opcFE_byte_RM
> 0000f1b4 T x86emuOp_opcFF_word_RM
> 0000f438 t set_parity_flag
> 0000f469 t set_szp_flags_8
> 0000f4a2 t set_szp_flags_16
> 0000f4e0 t set_szp_flags_32
> 0000f519 t no_carry_byte_side_eff
> 0000f52f t no_carry_word_side_eff
> 0000f545 t no_carry_long_side_eff
> 0000f555 t calc_carry_chain
> 0000f5d5 t calc_borrow_chain
> 0000f650 T aaa_word
> 0000f694 T aas_word
> 0000f6d8 T aad_word
> 0000f6fa T aam_word
> 0000f732 T adc_byte
> 0000f77a T adc_word
> 0000f7c2 T adc_long
> 0000f83c T add_byte
> 0000f874 T add_word
> 0000f8ac T add_long
> 0000f8f7 T and_byte
> 0000f910 T and_word
> 0000f929 T and_long
> 0000f93f T cmp_byte
> 0000f975 T cmp_word
> 0000f9a9 T cmp_long
> 0000f9da T daa_byte
> 0000fa29 T das_byte
> 0000fa74 T dec_byte
> 0000faa8 T dec_word
> 0000fada T dec_long
> 0000fb06 T inc_byte
> 0000fb3a T inc_word
> 0000fb6c T inc_long
> 0000fb98 T or_byte
> 0000fbb1 T or_word
> 0000fbca T or_long
> 0000fbe0 T neg_byte
> 0000fc2b T neg_word
> 0000fc74 T neg_long
> 0000fcb6 T not_byte
> 0000fcc3 T not_word
> 0000fcd0 T not_long
> 0000fcda T rcl_byte
> 0000fd8a T rcl_word
> 0000fe3a T rcl_long
> 0000fedd T rcr_byte
> 0000ffb2 T rcr_word
503,578c541,863
< 00010280 D _dev12
< 00010520 D _dev11
< 000107c0 D _dev19
< 00010a60 D _dev18
< 00010d00 D _dev17
< 00010fa0 D _dev16
< 00011240 D _dev9
< 000114e0 D _dev8
< 00011780 D _dev7
< 00011a20 D _dev6
< 00011cc0 D _dev5
< 00011f5c D southbridge_ricoh_rl5c476_info_20
< 00011f60 D _dev23
< 00012200 D _dev3
< 000124a0 D dev_root
< 0001273c D last_dev_p
< 00012740 d free_mem_end_ptr
< 00012744 d free_mem_ptr
< 00012760 D default_pciexp_ops_bus
< 000127a0 D AmlCode
< 00012ba0 D default_pcix_ops_bus
< 00012be0 d elf_boot_notes
< 00012c40 D southbridge_ricoh_rl5c476_ops
< 00012c60 d ricoh_rl5c476_ops
< 00012ca0 D northbridge_via_vt8623_ops
< 00012cc0 d vga_operations
< 00012d00 d agp_operations
< 00012d40 d northbridge_operations
< 00012d80 d cpu_bus_ops
< 00012dc0 d pci_domain_ops
< 00012e00 D superio_via_vt1211_ops
< 00012e20 D ops
< 00012e60 d vt1211hwmonitorinits
< 00012ee0 d pnp_dev_info
< 00012fbc D rom_end
< 00012fc0 D rom_start
< 00012fe0 D pnp_ops
< 00013020 D option_table
< 000134c0 d x86_vendors
< 00013520 d x86_vendor_name
< 0001354c A _bss
< 0001354c D _edata
< 00013560 b Irqs.1
< 00013564 B mainboard_via_epia_m_ops
< 00013568 B vga_inited
< 0001356c b vga_console_inited
< 00013570 b vidmem
< 00013574 b pci_bus_ops_pci
< 00013578 b initialized
< 0001357c b ht_bus_ops_pci
< 00013580 b smbus_max
< 000135a0 b buffer.2
< 000135c0 b buffer.1
< 000135e8 b buffer.0
< 000135fc b clocks_per_usec
< 00013600 b str_buf
< 00013604 b pciexp_bus_ops_pci
< 00013608 b pcix_bus_ops_pci
< 00013620 b header.0
< 00015620 b enable_cf_boot
< 00015624 b cf_base
< 00015628 b rom
< 0001562c b mem_ranges
< 00015630 B northbridge_via_vt8623_info_2
< 00015630 B superio_via_vt1211_info_10
< 00015638 B southbridge_via_vt8235_info_4
< 00015650 B vga_col
< 00015654 B vga_line
< 00015658 B mainboard_via_epia_m_info_0
< 0001565c A _ebss
< 0001565c A _end
< 00016000 A _stack
< 00018000 A _estack
< 00018000 A _heap
< 0001c000 A _eheap
< 0001c000 A _eram_seg
---
> 00010083 T rcr_long
> 0001014f T rol_byte
> 000101fe T rol_word
> 000102ab T rol_long
> 00010356 T ror_byte
> 000103f6 T ror_word
> 00010498 T ror_long
> 00010534 T shl_byte
> 000105f1 T shl_word
> 000106aa T shl_long
> 00010750 T shr_byte
> 0001080b T shr_word
> 000108a1 T shr_long
> 0001092c T sar_byte
> 000109d2 T sar_word
> 00010a74 T sar_long
> 00010b16 T shld_word
> 00010bdd T shld_long
> 00010c8e T shrd_word
> 00010d3a T shrd_long
> 00010dd7 T sbb_byte
> 00010e7c T sbb_word
> 00010f19 T sbb_long
> 00010fa6 T sub_byte
> 00011027 T sub_word
> 000110aa T sub_long
> 00011123 T test_byte
> 00011147 T test_word
> 0001116b T test_long
> 0001118c T xor_byte
> 000111a5 T xor_word
> 000111be T xor_long
> 000111d4 T imul_byte
> 00011218 T imul_word
> 00011263 T imul_long_direct
> 00011278 T imul_long
> 000112c9 T mul_byte
> 000112fb T mul_word
> 00011337 T mul_long
> 0001136c T idiv_byte
> 000113b4 T idiv_word
> 0001143b T idiv_long
> 000114d6 T div_byte
> 00011514 T div_word
> 0001159c T div_long
> 00011636 t single_in
> 000116c2 T ins
> 0001174a t single_out
> 000117d4 T outs
> 0001185c T mem_access_word
> 0001186d T push_word
> 0001189e T push_long
> 000118cd T pop_word
> 000118f7 T pop_long
> 00011920 T mem_ptr
> 0001195b T rdb
> 0001196d T rdw
> 0001197f T rdl
> 00011990 T wrb
> 000119a8 T wrw
> 000119c1 T wrl
> 000119d5 t p_inb
> 000119e1 t p_inw
> 000119ee t p_inl
> 000119f7 t p_outb
> 00011a03 t p_outw
> 00011a10 t p_outl
> 00011a1c T X86EMU_setupMemFuncs
> 00011a53 T X86EMU_setupPioFuncs
> 00011a8a T X86EMU_setupIntrFuncs
> 00011ac1 T X86EMU_prepareForInt
> 00011b26 T X86EMU_setMemBase
> 00011b3c t rl5c476_init
> 00011c78 T rl5c476_read_resources
> 00011cd2 T rl5c476_set_resources
> 00011d65 T southbridge_init
> 00011d7c T compute_ip_checksum
> 00011dcd T add_ip_checksums
> 00011e14 t northbridge_init
> 00011f2f t nullfunc
> 00011f34 t agp_init
> 00011f97 t vga_init
> 00012014 t vga_read_resources
> 0001202e t pci_domain_read_resources
> 0001207d t ram_resource
> 000120bd t tolm_test
> 000120ef t pci_domain_set_resources
> 00012207 t pci_domain_scan_bus
> 00012224 t cpu_bus_init
> 00012234 t cpu_bus_noop
> 00012239 t enable_dev
> 00012268 t gdtarg
> 0001226e t __mygdtaddr
> 00012274 t __mygdt
> 000122ac t __mygdt_end
> 000122ac t __myidt
> 000122b4 T vga_enable_console
> 000122b4 t real_mode_switch_end
> 000122cd t __vga_ec_16bit
> 000122e9 t __vga_ec_real
> 00012333 t vga_ec_restart
> 00012350 t vga_ec_exit
> 00012359 T do_vgabios
> 0001243a t __stack
> 00012452 t __rms_16bit
> 0001246e t __rms_real
> 000124a9 t vgarestart
> 000124c6 T vga_exit
> 0001250d T handler
> 00012510 t idthandle
> 00012519 t end_idthandle
> 0001251b T debughandler
> 0001251e t debughandle
> 00012522 t dbh1
> 00012526 t end_debughandle
> 00012528 T callbiosint
> 0001252b t callbiosint16
> 0001254b t biosprotect
> 0001256c t __rms_16bit2
> 00012588 t __rms_real2
> 000125b2 T handleint21
> 00012654 T setup_realmode_idt
> 000126ec T pcibios
> 000128e9 T biosint
> 00012a98 T copy_pirq_routing_table
> 00012c30 t pnp_enter_ext_func_mode
> 00012c3e t pnp_exit_ext_func_mode
> 00012c4c t vt1211_init
> 00012cd1 T vt1211_pnp_enable_resources
> 00012d08 T vt1211_pnp_set_resources
> 00012e91 T vt1211_pnp_enable
> 00012ec6 t enable_dev
> 00012eec T x86emuOp_esc_coprocess_d8
> 00012efb T x86emuOp_esc_coprocess_d9
> 00012f55 T x86emuOp_esc_coprocess_da
> 00012faf T x86emuOp_esc_coprocess_db
> 00013009 T x86emuOp_esc_coprocess_dc
> 00013063 T x86emuOp_esc_coprocess_dd
> 000130bd T x86emuOp_esc_coprocess_de
> 00013117 T x86emuOp_esc_coprocess_df
> 00013174 T stream_init
> 0001319f T stream_fini
> 000131a4 T stream_skip
> 000131ef T stream_read
> 00013218 T x86emu_dump_regs
> 0001342c T x86emu_dump_xregs
> 00013630 T x86emuOp2_illegal_op
> 00013673 T x86emu_check_jump_condition
> 00013738 T x86emuOp2_long_jump
> 00013777 T x86emuOp2_set_byte
> 000138aa T x86emuOp2_push_FS
> 000138c6 T x86emuOp2_pop_FS
> 000138e0 T x86emuOp2_bt_R
> 000139e0 T x86emuOp2_shld_IMM
> 00013aff T x86emuOp2_shld_CL
> 00013c08 T x86emuOp2_push_GS
> 00013c24 T x86emuOp2_pop_GS
> 00013c3e T x86emuOp2_bts_R
> 00013dcd T x86emuOp2_shrd_IMM
> 00013eec T x86emuOp2_shrd_CL
> 00013ff5 T x86emuOp2_imul_R_RM
> 00014131 T x86emuOp2_lss_R_IMM
> 00014196 T x86emuOp2_btr_R
> 0001432d T x86emuOp2_lfs_R_IMM
> 00014392 T x86emuOp2_lgs_R_IMM
> 000143f7 T x86emuOp2_movzx_byte_R_RM
> 000144b3 T x86emuOp2_movzx_word_R_RM
> 00014521 T x86emuOp2_btX_I
> 00014769 T x86emuOp2_btc_R
> 000148f8 T x86emuOp2_bsf
> 00014a82 T x86emuOp2_bsr
> 00014c08 T x86emuOp2_movsx_byte_R_RM
> 00014cc2 T x86emuOp2_movsx_word_R_RM
> 00014d30 T initialize_cpus
> 00014d70 t pci_sanity_check
> 00014de4 T pci_check_direct
> 00014e8c T pci_set_method
> 00014ec0 T lb_table_init
> 00014f00 T lb_first_record
> 00014f0b T lb_last_record
> 00014f19 T lb_next_record
> 00014f24 T lb_new_record
> 00014f65 T lb_memory
> 00014f7f T lb_mainboard
> 0001505b T lb_cmos_checksum
> 00015091 T lb_strings
> 000150ef T lb_memory_range
> 00015154 T get_lb_mem
> 0001515e T lb_table_fini
> 0001531c t lb_cleanup_memory_ranges
> 000155b7 t lb_add_memory_range
> 00015896 t build_lb_mem_range
> 000158b3 T write_linuxbios_table
> 00015980 T set_boot_successful
> 000159ab T boot_successful
> 000159b4 T pnp_write_config
> 000159ce T pnp_read_config
> 000159e4 T pnp_set_logical_device
> 000159f9 T pnp_set_enable
> 00015a12 T pnp_read_enable
> 00015a2b T pnp_set_iobase
> 00015a6b T pnp_set_irq
> 00015a82 T pnp_set_drq
> 00015a99 T pnp_read_resources
> 00015a9e T pnp_set_resources
> 00015b8b T pnp_enable_resources
> 00015ba5 T pnp_enable
> 00015bc8 t pnp_get_ioresource
> 00015c47 T pnp_enable_devices
> 00015dc8 t have_cpuid_p
> 00015dea T cpu_initialize
> 00016030 T __divdi3
> 000161c0 T __moddi3
> 000163f0 T __udivdi3
> 00016540 T __umoddi3
> 00016720 R _rodata
> 00016720 R console_drivers
> 00016720 T _etext
> 00016720 r uart8250_console
> 00016734 r vga_console
> 00016748 R econsole_drivers
> 00016748 R pci_drivers
> 00016748 r lpc_driver
> 00016750 r northbridge_driver
> 00016758 r northbridge_driver
> 00016760 r ricoh_rl5c476_driver
> 00016768 r vga_driver
> 00016770 r agp_driver
> 00016778 r northbridge_driver
> 00016780 R cpu_drivers
> 00016780 R epci_drivers
> 00016780 r driver
> 00016788 R ecpu_drivers
> 000167a0 r riserPins
> 000167a4 r cbPins
> 000167a8 r slotPins
> 000167ac r vgaPins
> 000167b0 r enetPins
> 000167b4 r vt8235Pins
> 000167b8 r usbPins
> 000167bc r firewirePins
> 000167c0 r pciIrqs
> 000167c4 r __FUNCTION__.0
> 000167d6 r div.0
> 000167de r __FUNCTION__.0
> 000167e7 r __func__.0
> 00016800 R linuxbios_assembler
> 00016860 R linuxbios_linker
> 000168a0 R linuxbios_compiler
> 000168e2 R linuxbios_compile_domain
> 000168e3 R linuxbios_compile_host
> 000168e6 R linuxbios_compile_by
> 000168eb R linuxbios_compile_time
> 000168f4 R linuxbios_build
> 00016911 R linuxbios_extra_version
> 0001691c R linuxbios_version
> 00016922 R mainboard_part_number
> 00016929 R mainboard_vendor
> 0001692d r link_width_to_pow2.0
> 00016935 r pow2_to_link_width.1
> 00016988 R pci_cf8_conf2
> 000169a0 R pci_cf8_conf1
> 000169c0 R intel_irq_routing_table
> 00016a30 r conventional.0
> 00016a41 r pcix_66mhz.1
> 00016a4d r pcix_100mhz.2
> 00016a5a r pcix_133mhz.3
> 00016a67 r pcix_266mhz.4
> 00016a74 r pcix_533mhz.5
> 00016a81 r unknown.6
> 00016acc r __func__.0
> 00016d7c r ramregs.0
> 00016d98 r __FUNCTION__.0
> 00016de4 r __FUNCTION__.1
> 00016df0 r __FUNCTION__.0
> 00016e80 r strings.0
> 00018c84 R _erodata
> 00018d20 D _data
> 00018d20 D gdt
> 00018d48 D gdt_end
> 00018d48 D idtarg
> 00018d50 d _idt
> 00018df0 d _idt_end
> 00018e00 d vt8235_lpc_ops
> 00018e2c D southbridge_via_vt8235_ops
> 00018e40 d ide_ops
> 00018e80 d nic_ops
> 00018ec0 d cpu_table
> 00018f40 d cpu_dev_ops
> 00018f80 d mtrr_msr
> 00018fac D default_console_loglevel
> 00018fb0 D minimum_console_loglevel
> 00018fb4 D default_message_loglevel
> 00018fb8 D console_loglevel
> 00018fc0 D default_pci_ops_bus
> 00019000 D default_pci_ops_dev
> 0001902c d pci_dev_ops_pci
> 00019040 D default_ht_ops_bus
> 00019080 D default_dev_ops_root
> 000190c0 D default_cardbus_ops_bus
> 000190ec D all_devices
> 000190f0 d pci_ram_image_start
> 000190f4 D myfuncs
> 00019120 D _dev25
> 000193c0 D _dev22
> 00019660 D _dev21
> 00019900 D _dev15
> 00019ba0 D _dev14
> 00019e40 D _dev13
> 0001a0e0 D _dev12
> 0001a380 D _dev11
> 0001a620 D _dev19
> 0001a8c0 D _dev18
> 0001ab60 D _dev17
> 0001ae00 D _dev16
> 0001b0a0 D _dev9
> 0001b340 D _dev8
> 0001b5e0 D _dev7
> 0001b880 D _dev6
> 0001bb20 D _dev5
> 0001bdbc D southbridge_ricoh_rl5c476_info_20
> 0001bdc0 D _dev23
> 0001c060 D _dev3
579a865,937
> 0001c300 D dev_root
> 0001c59c D last_dev_p
> 0001c5a0 d free_mem_end_ptr
> 0001c5a4 d free_mem_ptr
> 0001c5c0 D default_pciexp_ops_bus
> 0001c600 D AmlCode
> 0001ca00 D default_pcix_ops_bus
> 0001ca40 d elf_boot_notes
> 0001caa0 D x86emu_optab
> 0001cea0 d opcD1_word_operation
> 0001cec0 d opcD1_long_operation
> 0001cee0 d opcD0_byte_operation
> 0001cf00 d genop_word_operation
> 0001cf20 d genop_long_operation
> 0001cf40 d genop_byte_operation
> 0001cf60 d x86emu_parity_tab
> 0001cf80 D sys_outl
> 0001cf84 D sys_outw
> 0001cf88 D sys_outb
> 0001cf8c D sys_inl
> 0001cf90 D sys_inw
> 0001cf94 D sys_inb
> 0001cf98 D sys_wrl
> 0001cf9c D sys_wrw
> 0001cfa0 D sys_wrb
> 0001cfa4 D sys_rdl
> 0001cfa8 D sys_rdw
> 0001cfac D sys_rdb
> 0001cfc0 D southbridge_ricoh_rl5c476_ops
> 0001cfe0 d ricoh_rl5c476_ops
> 0001d020 D northbridge_via_vt8623_ops
> 0001d040 d vga_operations
> 0001d080 d agp_operations
> 0001d0c0 d northbridge_operations
> 0001d100 d cpu_bus_ops
> 0001d140 d pci_domain_ops
> 0001d180 D superio_via_vt1211_ops
> 0001d1a0 D ops
> 0001d1e0 d vt1211hwmonitorinits
> 0001d260 d pnp_dev_info
> 0001d33c D rom_end
> 0001d340 D rom_start
> 0001d360 D x86emu_optab2
> 0001d760 D pnp_ops
> 0001d7a0 D option_table
> 0001dc40 d x86_vendors
> 0001dca0 d x86_vendor_name
> 0001dccc A _bss
> 0001dccc D _edata
> 0001dce0 b Irqs.1
> 0001dce4 B mainboard_via_epia_m_ops
> 0001dce8 B vga_inited
> 0001dcec b vga_console_inited
> 0001dcf0 b vidmem
> 0001dcf4 b pci_bus_ops_pci
> 0001dcf8 b initialized
> 0001dcfc b ht_bus_ops_pci
> 0001dd00 b smbus_max
> 0001dd20 b buffer.2
> 0001dd40 b buffer.1
> 0001dd68 b buffer.0
> 0001dd7c B vga_pri
> 0001dd80 b clocks_per_usec
> 0001dd84 b str_buf
> 0001dd88 b pciexp_bus_ops_pci
> 0001dd8c b pcix_bus_ops_pci
> 0001dda0 b header.0
> 0001fda0 b enable_cf_boot
> 0001fda4 b cf_base
> 0001fda8 b rom
> 0001fdac b mem_ranges
> 0001fdc0 B _X86EMU_intrTab
> 0001fdc0 B northbridge_via_vt8623_info_2
580a939,951
> 000201c0 B superio_via_vt1211_info_10
> 000201c8 B southbridge_via_vt8235_info_4
> 000201e0 B vga_col
> 000201e4 B vga_line
> 000201e8 B mainboard_via_epia_m_info_0
> 00020200 B _X86EMU_env
> 00020384 A _ebss
> 00020384 A _end
> 00022000 A _stack
> 00024000 A _estack
> 00024000 A _heap
> 00028000 A _eheap
> 00028000 A _eram_seg
Binary files
LinuxBIOSv2/targets/via/epia-m/epia-m/fallback/linuxbios_ram.nrv2b and
LinuxBIOSv2.bad/targets/via/epia-m/epia-m/fallback/linuxbios_ram.nrv2b
differ
Binary files
LinuxBIOSv2/targets/via/epia-m/epia-m/fallback/linuxbios_ram.o and
LinuxBIOSv2.bad/targets/via/epia-m/epia-m/fallback/linuxbios_ram.o differ
Binary files
LinuxBIOSv2/targets/via/epia-m/epia-m/fallback/linuxbios_ram.rom and
LinuxBIOSv2.bad/targets/via/epia-m/epia-m/fallback/linuxbios_ram.rom differ
Only in LinuxBIOSv2/targets/via/epia-m/epia-m/fallback: payload
Binary files LinuxBIOSv2/targets/via/epia-m/epia-m/fallback/pci_device.o
and LinuxBIOSv2.bad/targets/via/epia-m/epia-m/fallback/pci_device.o differ
Binary files LinuxBIOSv2/targets/via/epia-m/epia-m/fallback/version.o
and LinuxBIOSv2.bad/targets/via/epia-m/epia-m/fallback/version.o differ
Only in LinuxBIOSv2/targets/via/epia-m/epia-m: linuxbios.rom





From yinghai.lu at amd.com  Tue May  2 18:56:36 2006
From: yinghai.lu at amd.com (Lu, Yinghai)
Date: Tue, 2 May 2006 09:56:36 -0700
Subject: [LinuxBIOS] Another newbi question / TYAN TIGER MP S2460
Message-ID: <6F7DA19D05F3CF40B890C7CA2DB13A4203094C32@ssvlexmb2.amd.com>

In the LinuxBIOS V1, there is support for Tyan K7 MB.

If you want support in LinuxBIOS v2, Someone need to check northbridge/amd/amd76x and reformat the interface or translate to C....

YH

-----Original Message-----
From: linuxbios-bounces at linuxbios.org [mailto:linuxbios-bounces at linuxbios.org] On Behalf Of paul.collomb1 at libertysurf.fr
Sent: Tuesday, May 02, 2006 4:02 AM
To: _linuxbios
Subject: [LinuxBIOS] Another newbi question / TYAN TIGER MP S2460

Hi, i am newbi on linuxbios ... 
I have bought a TYAN TIGER MP S 2460 motherboard model ( to a friend ) and i want to know 
( if possible ) if linuxbios could work fine on this mobo. 
In your opinion, is it possible ? 
Thanks for your response. 
Best regards 

-------------- ALICE HAUT DEBIT : TRIPLE PLAY A 29,95 EUR/MOIS -------------- 
D?couvrez vite ALICEBOX : avec le modem WIFI, profitez de l'ADSL, de la TELEPHONIE et en exclusivit? de la TELEVISION ! 
B?n?ficiez aussi de la hotline gratuite 24h/24 ! Soumis ? conditions. Pour en profiter cliquez ici http://abonnement.aliceadsl.fr





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





From chris at suehsi.de  Tue May  2 21:07:02 2006
From: chris at suehsi.de (=?ISO-8859-1?Q?Christian_S=FChs?=)
Date: Tue, 02 May 2006 21:07:02 +0200
Subject: [LinuxBIOS] MB1030 / 3036 VGA comes up :D
In-Reply-To: <8a0c36780605020925h6110f2d8pa656fde32cc5adfb@mail.gmail.com>
References: <0E81348C5627674A9C0061413EBFF5F74F4442@SAUSEXMB2.amd.com>	<8a0c36780605011133l5be7d2e8sbf8fa875824ffe8a@mail.gmail.com>	<44566EC7.4090104@suehsi.de>
	<445677BE.4080201@suehsi.de>	<8a0c36780605011259p721fb330j4d640fc17857cae8@mail.gmail.com>	<445733D0.6050004@suehsi.de>
	<44575B60.7050406@suehsi.de>	<8a0c36780605020731w7d9d7048g524d640b4d3ed665@mail.gmail.com>	<44578BAB.80008@suehsi.de>
	<44579320.90206@suehsi.de>
	<8a0c36780605020925h6110f2d8pa656fde32cc5adfb@mail.gmail.com>
Message-ID: <4457ADD6.8020608@suehsi.de>


> 
> So how can we get more debug info out of this system?  Our primary
> debug method dies.
> 
> You can run this under the user mode emulator with the IO prints
> enabled it works right?
>

It don't work :D

I can't believe that, whit enabled orginal printfs it don't work.
Whit disabled ones it work normally.

the output is attached.
I have tried it twice, under LB and factory Bios.

now I will do a run with your patch.
But I think I get no output.

chris

> Can you do that and look at what IO its doing when it starts up?. 
> Probally don't need more than the first 50 lines or so.  Maybe we can
> exclude printing on IO port ranges that cause  problems.
> 
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: testbios_vga.cap
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20060502/4b6df2ad/attachment.ksh>

From rminnich at lanl.gov  Tue May  2 20:41:53 2006
From: rminnich at lanl.gov (Ronald G Minnich)
Date: Tue, 02 May 2006 12:41:53 -0600
Subject: [LinuxBIOS] MB1030 / 3036 VGA comes up :D
In-Reply-To: <44578A8E.9060608@suehsi.de>
References: <0E81348C5627674A9C0061413EBFF5F74F4442@SAUSEXMB2.amd.com>	<4454C416.4040906@suehsi.de>	<8a0c36780604301419y7f9b8045ie57b8f19bdeb6e2b@mail.gmail.com>	<4455E1AA.7070902@suehsi.de>	<8a0c36780605010706m2bed1a6eja546e5b941f46c1a@mail.gmail.com>	<445652FA.7030009@suehsi.de>	<8a0c36780605011133l5be7d2e8sbf8fa875824ffe8a@mail.gmail.com>	<44566EC7.4090104@suehsi.de>	<8a0c36780605011254i2edfa710h5ba481b7ae0a6093@mail.gmail.com>	<44573C06.5030709@suehsi.de>	<8a0c36780605020721v279f153ev7da4dc3ebb2d42d@mail.gmail.com>
	<44578A8E.9060608@suehsi.de>
Message-ID: <4457A7F1.10800@lanl.gov>

Christian S?hs wrote:
> Richard Smith schrieb:
> 
>>>copying VGA ROM Image from 0xfffc0000 to 0xc0000, 0x8000 bytes
>>>entering emulator
>>>inb(0x03cf) = 0x00
>>>inb(0x03cf) = 0x00
>>>inb(0x03cf) = 0x88
>>>i
>>
>>
>>So its crashing 'inside' of a printk.  0x3cf is a VGA index register.
> 
> 
> Well, I think so. Many logs looks like the one above. The first 
> character is printed. Than nothing no more.

Is the fifo enabled on this uart? if it is, then the output can be kind 
of non-deterministic.

ron



From stepan at coresystems.de  Tue May  2 21:09:46 2006
From: stepan at coresystems.de (Stefan Reinauer)
Date: Tue, 2 May 2006 21:09:46 +0200
Subject: [LinuxBIOS] MB1030 / 3036 VGA comes up :D
In-Reply-To: <8a0c36780605020721v279f153ev7da4dc3ebb2d42d@mail.gmail.com>
References: <4454C416.4040906@suehsi.de>
	<8a0c36780604301419y7f9b8045ie57b8f19bdeb6e2b@mail.gmail.com>
	<4455E1AA.7070902@suehsi.de>
	<8a0c36780605010706m2bed1a6eja546e5b941f46c1a@mail.gmail.com>
	<445652FA.7030009@suehsi.de>
	<8a0c36780605011133l5be7d2e8sbf8fa875824ffe8a@mail.gmail.com>
	<44566EC7.4090104@suehsi.de>
	<8a0c36780605011254i2edfa710h5ba481b7ae0a6093@mail.gmail.com>
	<44573C06.5030709@suehsi.de>
	<8a0c36780605020721v279f153ev7da4dc3ebb2d42d@mail.gmail.com>
Message-ID: <20060502190946.GA4620@coresystems.de>

* Richard Smith <smithbone at gmail.com> [060502 16:21]:
> >inb(0x03cf) = 0x00
> >inb(0x03cf) = 0x00
> >inb(0x03cf) = 0x88
> >i
> 
> So its crashing 'inside' of a printk.  0x3cf is a VGA index register.
 
coincidence. The printk is probably "long" done but the serial port did
not send it all out yet. I've seen this in quite some cases.

-- 
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 chris at suehsi.de  Tue May  2 22:30:00 2006
From: chris at suehsi.de (=?ISO-8859-1?Q?Christian_S=FChs?=)
Date: Tue, 02 May 2006 22:30:00 +0200
Subject: [LinuxBIOS] MB1030 / 3036 VGA comes up :D
In-Reply-To: <4457ADD6.8020608@suehsi.de>
References: <0E81348C5627674A9C0061413EBFF5F74F4442@SAUSEXMB2.amd.com>	<8a0c36780605011133l5be7d2e8sbf8fa875824ffe8a@mail.gmail.com>	<44566EC7.4090104@suehsi.de>
	<445677BE.4080201@suehsi.de>	<8a0c36780605011259p721fb330j4d640fc17857cae8@mail.gmail.com>	<445733D0.6050004@suehsi.de>
	<44575B60.7050406@suehsi.de>	<8a0c36780605020731w7d9d7048g524d640b4d3ed665@mail.gmail.com>	<44578BAB.80008@suehsi.de>
	<44579320.90206@suehsi.de>
	<8a0c36780605020925h6110f2d8pa656fde32cc5adfb@mail.gmail.com>
	<4457ADD6.8020608@suehsi.de>
Message-ID: <4457C148.50802@suehsi.de>


>>
> 
> It don't work :D
> 
> I can't believe that, whit enabled orginal printfs it don't work.
> Whit disabled ones it work normally.
> 


Sorry, for this run I have made a mistake.

You can ignore the results. The proper logs was sent to Richard.

With testbios there is also a long delay after the first int10.

The debug spokes out about 5MB of ff for inb, than I have stop the run.
After that I have disabled the inb printf and all went fine.

Now I wait for an answer from Richard.

chris



From chris at suehsi.de  Tue May  2 22:34:14 2006
From: chris at suehsi.de (=?ISO-8859-1?Q?Christian_S=FChs?=)
Date: Tue, 02 May 2006 22:34:14 +0200
Subject: [LinuxBIOS] MB1030 / 3036 VGA comes up :D
In-Reply-To: <4457A7F1.10800@lanl.gov>
References: <0E81348C5627674A9C0061413EBFF5F74F4442@SAUSEXMB2.amd.com>	<4454C416.4040906@suehsi.de>	<8a0c36780604301419y7f9b8045ie57b8f19bdeb6e2b@mail.gmail.com>	<4455E1AA.7070902@suehsi.de>	<8a0c36780605010706m2bed1a6eja546e5b941f46c1a@mail.gmail.com>	<445652FA.7030009@suehsi.de>	<8a0c36780605011133l5be7d2e8sbf8fa875824ffe8a@mail.gmail.com>	<44566EC7.4090104@suehsi.de>	<8a0c36780605011254i2edfa710h5ba481b7ae0a6093@mail.gmail.com>	<44573C06.5030709@suehsi.de>	<8a0c36780605020721v279f153ev7da4dc3ebb2d42d@mail.gmail.com>	<44578A8E.9060608@suehsi.de>
	<4457A7F1.10800@lanl.gov>
Message-ID: <4457C246.1060702@suehsi.de>


>>Well, I think so. Many logs looks like the one above. The first 
>>character is printed. Than nothing no more.
>

This happens only with enabled printks.

> 
> Is the fifo enabled on this uart? if it is, then the output can be kind 
> of non-deterministic.
> 

Where is this done? I have a look to the superIO stuff.

chris

> ron
> 




From stepan at coresystems.de  Tue May  2 21:16:52 2006
From: stepan at coresystems.de (Stefan Reinauer)
Date: Tue, 2 May 2006 21:16:52 +0200
Subject: [LinuxBIOS] MB1030 / 3036 VGA comes up :D
In-Reply-To: <44578A8E.9060608@suehsi.de>
References: <8a0c36780604301419y7f9b8045ie57b8f19bdeb6e2b@mail.gmail.com>
	<4455E1AA.7070902@suehsi.de>
	<8a0c36780605010706m2bed1a6eja546e5b941f46c1a@mail.gmail.com>
	<445652FA.7030009@suehsi.de>
	<8a0c36780605011133l5be7d2e8sbf8fa875824ffe8a@mail.gmail.com>
	<44566EC7.4090104@suehsi.de>
	<8a0c36780605011254i2edfa710h5ba481b7ae0a6093@mail.gmail.com>
	<44573C06.5030709@suehsi.de>
	<8a0c36780605020721v279f153ev7da4dc3ebb2d42d@mail.gmail.com>
	<44578A8E.9060608@suehsi.de>
Message-ID: <20060502191652.GB4620@coresystems.de>

* Christian S?hs <chris at suehsi.de> [060502 18:36]:
> >>inb(0x03cf) = 0x00
> >>inb(0x03cf) = 0x88
> >>i
> >
> >
> >So its crashing 'inside' of a printk.  0x3cf is a VGA index register.
> 
> Well, I think so. Many logs looks like the one above. The first 
> character is printed. Than nothing no more.
 
again, because I fear the thread is getting too big to get everything
with full attention almost: 

The hand is pretty likely caused by a race or something in the graphics
card bios caused by the delays of the serial output.

So while the serial interface (which has a buffer of at least 16 bytes)
is still sending at a certain baud rate, the program is already further
when the machine hangs and prevents the UART FIFO to be transferred
completely. This is rather common when debugging such stuff over serial.

To get back to the issues: What are we trying to solve exactly?

 - the 90s delay during VGA init.
 - anything else?

We have a lot of good suggestions in this thread but I think we need to 
get focus again and go smaller steps.

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 stepan at coresystems.de  Tue May  2 21:28:23 2006
From: stepan at coresystems.de (Stefan Reinauer)
Date: Tue, 2 May 2006 21:28:23 +0200
Subject: [LinuxBIOS] MB1030 / 3036 VGA comes up :D
In-Reply-To: <4457ADD6.8020608@suehsi.de>
References: <44566EC7.4090104@suehsi.de> <445677BE.4080201@suehsi.de>
	<8a0c36780605011259p721fb330j4d640fc17857cae8@mail.gmail.com>
	<445733D0.6050004@suehsi.de> <44575B60.7050406@suehsi.de>
	<8a0c36780605020731w7d9d7048g524d640b4d3ed665@mail.gmail.com>
	<44578BAB.80008@suehsi.de> <44579320.90206@suehsi.de>
	<8a0c36780605020925h6110f2d8pa656fde32cc5adfb@mail.gmail.com>
	<4457ADD6.8020608@suehsi.de>
Message-ID: <20060502192823.GC4620@coresystems.de>

* Christian S?hs <chris at suehsi.de> [060502 21:07]:
> outw(0x0052, 0x03ce)
> outw(0x0053, 0x03ce)
> outw(0x0054, 0x03ce)
> outw(0x0055, 0x03ce)
> outw(0x3073, 0x03ce)
> outw(0x1b74, 0x03ce)
> outw(0x1e75, 0x03ce)
> outw(0x0076, 0x03ce)
> outw(0x0078, 0x03ce)
> outw(0x3079, 0x03ce)
> outw(0xc87a, 0x03ce)
> outw(0x01bf, 0x03ce)
thats the graphics index register


> inb(0x03da) = 0xff
> inb(0x03da) = 0xff
> inb(0x03da) = 0xff
> inb(0x03da) = 0xff
> 
> // after her always the same inb line

it waits for a vertical blank interrupt which never happens.
At this point it probably expects the video to become light.

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 chris at suehsi.de  Tue May  2 23:12:10 2006
From: chris at suehsi.de (=?UTF-8?B?Q2hyaXN0aWFuIFPDvGhz?=)
Date: Tue, 02 May 2006 23:12:10 +0200
Subject: [LinuxBIOS] MB1030 / 3036 VGA comes up :D
In-Reply-To: <20060502192823.GC4620@coresystems.de>
References: <44566EC7.4090104@suehsi.de> <445677BE.4080201@suehsi.de>
	<8a0c36780605011259p721fb330j4d640fc17857cae8@mail.gmail.com>
	<445733D0.6050004@suehsi.de> <44575B60.7050406@suehsi.de>
	<8a0c36780605020731w7d9d7048g524d640b4d3ed665@mail.gmail.com>
	<44578BAB.80008@suehsi.de> <44579320.90206@suehsi.de>
	<8a0c36780605020925h6110f2d8pa656fde32cc5adfb@mail.gmail.com>
	<4457ADD6.8020608@suehsi.de> <20060502192823.GC4620@coresystems.de>
Message-ID: <4457CB2A.4030908@suehsi.de>


>>outw(0x3079, 0x03ce)
>>outw(0xc87a, 0x03ce)
>>outw(0x01bf, 0x03ce)
> 
> thats the graphics index register
> 
> 
> 
>>inb(0x03da) = 0xff
>>inb(0x03da) = 0xff
>>inb(0x03da) = 0xff
>>inb(0x03da) = 0xff
>>
>>// after her always the same inb line
> 
> 
> it waits for a vertical blank interrupt which never happens.
> At this point it probably expects the video to become light.
>

ok, this is a wrong log, but for the right logs it is the same.
There is the delay after the first int10 at c000:xxxxx with the same output.

And yes, after the first run_bios_int the screen switches from standby 
to on.

But what means never happens? It happens after 20s without debug under 
LB or immediatly without debug under testbios. After that it takes the 
second run with longer delay.

What causes the vertical blank interrupt?


chris



> Stefan
> 
> 




From stepan at coresystems.de  Tue May  2 22:56:54 2006
From: stepan at coresystems.de (Stefan Reinauer)
Date: Tue, 2 May 2006 22:56:54 +0200
Subject: [LinuxBIOS] MB1030 / 3036 VGA comes up :D
In-Reply-To: <4457CB2A.4030908@suehsi.de>
References: <8a0c36780605011259p721fb330j4d640fc17857cae8@mail.gmail.com>
	<445733D0.6050004@suehsi.de> <44575B60.7050406@suehsi.de>
	<8a0c36780605020731w7d9d7048g524d640b4d3ed665@mail.gmail.com>
	<44578BAB.80008@suehsi.de> <44579320.90206@suehsi.de>
	<8a0c36780605020925h6110f2d8pa656fde32cc5adfb@mail.gmail.com>
	<4457ADD6.8020608@suehsi.de> <20060502192823.GC4620@coresystems.de>
	<4457CB2A.4030908@suehsi.de>
Message-ID: <20060502205654.GB11460@coresystems.de>

* Christian S?hs <chris at suehsi.de> [060502 23:12]:
> >>inb(0x03da) = 0xff
> >>inb(0x03da) = 0xff
> >>inb(0x03da) = 0xff
> >>inb(0x03da) = 0xff
> >>
> >>// after her always the same inb line
> >
> >it waits for a vertical blank interrupt which never happens.
> >At this point it probably expects the video to become light.
> 
> But what means never happens? It happens after 20s without debug under 
> LB or immediatly without debug under testbios. After that it takes the 
> second run with longer delay.
 
Ah, sorry, I thought when you enable the output of inb(0x03da) = 0xff
it would not come to an end but print always the same inb line.

So it works when you enable above debug and wait long enough?

> What causes the vertical blank interrupt?

When the ray moves from the end of the screen to the beginning there's a
time frame which can safely be used to update the screen without any
flickering, thats the vertical blank. Its actually not an interrupt
because in above example the bios polls for that event rather than
getting an interrupt when its there.


-- 
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 smithbone at gmail.com  Tue May  2 23:02:47 2006
From: smithbone at gmail.com (Richard Smith)
Date: Tue, 2 May 2006 16:02:47 -0500
Subject: [LinuxBIOS] MB1030 / 3036 VGA comes up :D
In-Reply-To: <20060502191652.GB4620@coresystems.de>
References: <8a0c36780604301419y7f9b8045ie57b8f19bdeb6e2b@mail.gmail.com>
	<8a0c36780605010706m2bed1a6eja546e5b941f46c1a@mail.gmail.com>
	<445652FA.7030009@suehsi.de>
	<8a0c36780605011133l5be7d2e8sbf8fa875824ffe8a@mail.gmail.com>
	<44566EC7.4090104@suehsi.de>
	<8a0c36780605011254i2edfa710h5ba481b7ae0a6093@mail.gmail.com>
	<44573C06.5030709@suehsi.de>
	<8a0c36780605020721v279f153ev7da4dc3ebb2d42d@mail.gmail.com>
	<44578A8E.9060608@suehsi.de> <20060502191652.GB4620@coresystems.de>
Message-ID: <8a0c36780605021402j7902e11y54b2ca66de551500@mail.gmail.com>

> So while the serial interface (which has a buffer of at least 16 bytes)
> is still sending at a certain baud rate, the program is already further

I looked at the serial code and the FIFO is enabled but bypassed.  The
code waits for the transmit done flag after each byte and that is only
set when both the FIFO and TX reg are empty.

--
Richard A. Smith



From smithbone at gmail.com  Tue May  2 23:14:22 2006
From: smithbone at gmail.com (Richard Smith)
Date: Tue, 2 May 2006 16:14:22 -0500
Subject: [LinuxBIOS] MB1030 / 3036 VGA comes up :D
In-Reply-To: <20060502205654.GB11460@coresystems.de>
References: <8a0c36780605011259p721fb330j4d640fc17857cae8@mail.gmail.com>
	<44575B60.7050406@suehsi.de>
	<8a0c36780605020731w7d9d7048g524d640b4d3ed665@mail.gmail.com>
	<44578BAB.80008@suehsi.de> <44579320.90206@suehsi.de>
	<8a0c36780605020925h6110f2d8pa656fde32cc5adfb@mail.gmail.com>
	<4457ADD6.8020608@suehsi.de> <20060502192823.GC4620@coresystems.de>
	<4457CB2A.4030908@suehsi.de> <20060502205654.GB11460@coresystems.de>
Message-ID: <8a0c36780605021414y5bb2a0ek2b93d71a004580de@mail.gmail.com>

> When the ray moves from the end of the screen to the beginning there's a
> time frame which can safely be used to update the screen without any
> flickering, thats the vertical blank. Its actually not an interrupt
> because in above example the bios polls for that event rather than
> getting an interrupt when its there.

Is that bit latched or is it a direct indication of the state of the
CRTC.  If its not latched then due to the reduced speed of the
emulator we could miss the bit.  But that dosen't really explain why
the in-tree has the 90 second and the usermode dosen't.

Could the size compression on the in tree emu affect the speed that much?

--
Richard A. Smith



From smithbone at gmail.com  Wed May  3 00:27:41 2006
From: smithbone at gmail.com (Richard Smith)
Date: Tue, 2 May 2006 17:27:41 -0500
Subject: [LinuxBIOS] MB1030 / 3036 VGA comes up :D
In-Reply-To: <4457B6C8.1070404@suehsi.de>
References: <0E81348C5627674A9C0061413EBFF5F74F4442@SAUSEXMB2.amd.com>
	<445733D0.6050004@suehsi.de> <44575B60.7050406@suehsi.de>
	<8a0c36780605020731w7d9d7048g524d640b4d3ed665@mail.gmail.com>
	<44578BAB.80008@suehsi.de> <44579320.90206@suehsi.de>
	<8a0c36780605020925h6110f2d8pa656fde32cc5adfb@mail.gmail.com>
	<4457ADD6.8020608@suehsi.de> <4457B0C0.8080304@suehsi.de>
	<4457B6C8.1070404@suehsi.de>
Message-ID: <8a0c36780605021527s5f8fal5f17a895c075f6a6@mail.gmail.com>

> No way, after the first int I have wait 5min and captured 5MB of ff.
> However, I have disabled the inb printf and all works fine for the rest :D
>

I'm afraid its the in's that I am interested in seeing.  You have said
earlier that the long delay is during the first couple of int10's. 
Thats where I want to see what its waiting on.

I know the log will be huge.  Go ahead and run the user emu with the
IO enabled for say 10 seconds and then quit.  That should be enough to
start with.  It should compress down alot since its all text.

Also did you run the user emu with the if (port < 0x53) filter on the
IO?   I want to first rule out that its an issue with reading the
system timer.

--
Richard A. Smith



From eric at zyxod.com  Wed May  3 03:49:54 2006
From: eric at zyxod.com (Eric Poulsen)
Date: Tue, 02 May 2006 18:49:54 -0700
Subject: [LinuxBIOS] Solved: Makefile weirdness
In-Reply-To: <20060502111749.GA7339@coresystems.de>
References: <44544DE9.1050701@zyxod.com> <4455926F.50007@zyxod.com>
	<20060502111749.GA7339@coresystems.de>
Message-ID: <44580C42.6020302@zyxod.com>

Stefan Reinauer wrote:

>* Eric Poulsen <eric at zyxod.com> [060501 06:45]:
>  
>
>>buildtarget
>>make clean
>>make
>>Crash, exception 13 just after vga write protect
>>    
>>
> 
> - vs -
>
>  
>
>>buildtarget
>>make
>>[Everything works -- boots, VGA works, etc. ]
>>[Important thing to note about the above is that the ROM_IMAGE_SIZE _was
>>not_ increased]
>>    
>>
> 
>This sounds very weird. Are you doing this on the same system using the
>same compiler? I suspect this is on 2 systems or using different
>compilers or binutils, since these factors can and do affect code size a
>lot (and make things break)
>
>I just tried a "make clean" in a freshly created buildtree (using
>buildtarget) and its exactly the same as without "make clean"
>
>Can you try the same and check whether its different?
>  
>
It's the same for me, too.

>Stefan
>
>  
>




From smithbone at gmail.com  Wed May  3 07:07:47 2006
From: smithbone at gmail.com (Richard Smith)
Date: Wed, 3 May 2006 00:07:47 -0500
Subject: [LinuxBIOS] Error in FSF high priority list LinuxBIOS description
Message-ID: <8a0c36780605022207s499eeaaehb77c6edbad08d1dd@mail.gmail.com>

After reading an article describing the High-priority list for the FSF
I checked out our listing.

And found the following.

"""
The way to solve the problem is to run a free BIOS. And our community
has developed free BIOSes--for instance, LinuxBIOS, which is a
modified version of the kernel, Linux. However,
"""

Seems to me this is not really true.  LinuxBIOS is _vastly_ different
than the Linux Kernel.  We ripped some PCI code, printk code and a few
other bits but I can't see us being a "modified version of the
kernel..."

We can load a kernel and our ultimate goal is to use a kernel as a
super-bootloader but not to be a kernel.

Anyone else think it needs changing?

--
Richard A. Smith



From stuge-linuxbios at cdy.org  Wed May  3 08:29:14 2006
From: stuge-linuxbios at cdy.org (Peter Stuge)
Date: Wed, 3 May 2006 08:29:14 +0200
Subject: [LinuxBIOS] Error in FSF high priority list LinuxBIOS
	description
In-Reply-To: <8a0c36780605022207s499eeaaehb77c6edbad08d1dd@mail.gmail.com>
References: <8a0c36780605022207s499eeaaehb77c6edbad08d1dd@mail.gmail.com>
Message-ID: <20060503062914.22735.qmail@cdy.org>

On Wed, May 03, 2006 at 12:07:47AM -0500, Richard Smith wrote:
> Anyone else think it needs changing?

Yes. Who do we ask? Can Ward make the change?

I suggest "LinuxBIOS, that can boot several free operating systems on
various hardware today, and hopes to utilize the Linux kernel as main
bootloader in the future."


//Peter



From yinghailu at gmail.com  Wed May  3 09:18:17 2006
From: yinghailu at gmail.com (yhlu)
Date: Wed, 3 May 2006 00:18:17 -0700
Subject: [LinuxBIOS] Error in FSF high priority list LinuxBIOS
	description
In-Reply-To: <20060503062914.22735.qmail@cdy.org>
References: <8a0c36780605022207s499eeaaehb77c6edbad08d1dd@mail.gmail.com>
	<20060503062914.22735.qmail@cdy.org>
Message-ID: <2ea3fae10605030018v3a2e9b87hc4b1f72a417ec0c3@mail.gmail.com>

Not future, with LinuxBIOS+kernel+kexec..we already can use kernel as
bootloader...

current we only put some effects to provide tiny kernel and small ramdisk...

fastboot seems to provide the ramdisk...

YH

On 5/2/06, Peter Stuge <stuge-linuxbios at cdy.org> wrote:
> On Wed, May 03, 2006 at 12:07:47AM -0500, Richard Smith wrote:
> > Anyone else think it needs changing?
>
> Yes. Who do we ask? Can Ward make the change?
>
> I suggest "LinuxBIOS, that can boot several free operating systems on
> various hardware today, and hopes to utilize the Linux kernel as main
> bootloader in the future."
>
>
> //Peter
>
> --
> linuxbios mailing list
> linuxbios at linuxbios.org
> http://www.openbios.org/mailman/listinfo/linuxbios
>



From chris at suehsi.de  Wed May  3 10:42:07 2006
From: chris at suehsi.de (=?UTF-8?B?Q2hyaXN0aWFuIFPDvGhz?=)
Date: Wed, 03 May 2006 10:42:07 +0200
Subject: [LinuxBIOS] MB1030 / 3036 VGA comes up :D
In-Reply-To: <20060502205654.GB11460@coresystems.de>
References: <8a0c36780605011259p721fb330j4d640fc17857cae8@mail.gmail.com>	<445733D0.6050004@suehsi.de>
	<44575B60.7050406@suehsi.de>	<8a0c36780605020731w7d9d7048g524d640b4d3ed665@mail.gmail.com>	<44578BAB.80008@suehsi.de>
	<44579320.90206@suehsi.de>	<8a0c36780605020925h6110f2d8pa656fde32cc5adfb@mail.gmail.com>	<4457ADD6.8020608@suehsi.de>
	<20060502192823.GC4620@coresystems.de>	<4457CB2A.4030908@suehsi.de>
	<20060502205654.GB11460@coresystems.de>
Message-ID: <44586CDF.2060809@suehsi.de>


>  
> Ah, sorry, I thought when you enable the output of inb(0x03da) = 0xff
> it would not come to an end but print always the same inb line.
>

I'm not sure, as I say.
Yesterday I have wait about one cigarette length and captured 5MB of 
(0x03da) = 0xff ;) before stopping the test.
But the screen comes not completly up.

But think about the udelay(xxx) tests with the inTree emu, with a time 
of 250 for each function and I guess the inb function is called most, I 
have to wait about 5 minutes for a complete initialization.

I think the printf stuff takes a longer time ( like 500us) that means 
that a whole run takes for example 10 minutes or longer.

> So it works when you enable above debug and wait long enough?

It could, but I don't know it. I will try it again and wait longer 
without capturing the output.



chris




From chris at suehsi.de  Wed May  3 10:55:41 2006
From: chris at suehsi.de (=?ISO-8859-1?Q?Christian_S=FChs?=)
Date: Wed, 03 May 2006 10:55:41 +0200
Subject: [LinuxBIOS] MB1030 / 3036 VGA comes up :D
In-Reply-To: <8a0c36780605021527s5f8fal5f17a895c075f6a6@mail.gmail.com>
References: <0E81348C5627674A9C0061413EBFF5F74F4442@SAUSEXMB2.amd.com>	<445733D0.6050004@suehsi.de>
	<44575B60.7050406@suehsi.de>	<8a0c36780605020731w7d9d7048g524d640b4d3ed665@mail.gmail.com>	<44578BAB.80008@suehsi.de>
	<44579320.90206@suehsi.de>	<8a0c36780605020925h6110f2d8pa656fde32cc5adfb@mail.gmail.com>	<4457ADD6.8020608@suehsi.de>
	<4457B0C0.8080304@suehsi.de>	<4457B6C8.1070404@suehsi.de>
	<8a0c36780605021527s5f8fal5f17a895c075f6a6@mail.gmail.com>
Message-ID: <4458700D.5060103@suehsi.de>

Richard Smith schrieb:
>>No way, after the first int I have wait 5min and captured 5MB of ff.
>>However, I have disabled the inb printf and all works fine for the rest :D
>>
> 
> 
> I'm afraid its the in's that I am interested in seeing.  You have said
> earlier that the long delay is during the first couple of int10's. 
> Thats where I want to see what its waiting on.

To clear this:

normally with disabled debug for the inTree emu there are three lines like

int10 vector at c000:xxxx
short after each line normally the run_bios_int function is called.

the long delays are after the first call (20-30s)
and after the second call (60-70s)
The second delay is divided in two parts, because at the middle there is 
a flickering.


> 
> I know the log will be huge.  Go ahead and run the user emu with the
> IO enabled for say 10 seconds and then quit.  That should be enough to
> start with.  It should compress down alot since its all text.
> 

I have send the log to you, yesterday. Or not ??

> Also did you run the user emu with the if (port < 0x53) filter on the
> IO?   I want to first rule out that its an issue with reading the
> system timer.

I have tried this, but remember there was no debug outbut for port < 
0x53 for the inTree emu.

However, I will do it for the userspace emu.

chris

> 
> --
> Richard A. Smith
> 




From chris at suehsi.de  Wed May  3 11:04:21 2006
From: chris at suehsi.de (=?UTF-8?B?Q2hyaXN0aWFuIFPDvGhz?=)
Date: Wed, 03 May 2006 11:04:21 +0200
Subject: [LinuxBIOS] MB1030 / 3036 VGA comes up :D
In-Reply-To: <20060502191652.GB4620@coresystems.de>
References: <8a0c36780604301419y7f9b8045ie57b8f19bdeb6e2b@mail.gmail.com>
	<4455E1AA.7070902@suehsi.de>
	<8a0c36780605010706m2bed1a6eja546e5b941f46c1a@mail.gmail.com>
	<445652FA.7030009@suehsi.de>
	<8a0c36780605011133l5be7d2e8sbf8fa875824ffe8a@mail.gmail.com>
	<44566EC7.4090104@suehsi.de>
	<8a0c36780605011254i2edfa710h5ba481b7ae0a6093@mail.gmail.com>
	<44573C06.5030709@suehsi.de>
	<8a0c36780605020721v279f153ev7da4dc3ebb2d42d@mail.gmail.com>
	<44578A8E.9060608@suehsi.de> <20060502191652.GB4620@coresystems.de>
Message-ID: <44587215.6010507@suehsi.de>


> To get back to the issues: What are we trying to solve exactly?
> 
>  - the 90s delay during VGA init.
>  - anything else?

yeah,

copying LB to RAM seems to be very slow ?!
after boot, uncompressing the kernel is much slower as under factory bios.

I think the RAM is not proper init.

The filesystem is for any reason readonly after a boot?!
Not under factory.


chris



From chris at suehsi.de  Wed May  3 11:46:06 2006
From: chris at suehsi.de (=?ISO-8859-1?Q?Christian_S=FChs?=)
Date: Wed, 03 May 2006 11:46:06 +0200
Subject: [LinuxBIOS] MB1030 / 3036 VGA comes up :D
In-Reply-To: <8a0c36780605021527s5f8fal5f17a895c075f6a6@mail.gmail.com>
References: <0E81348C5627674A9C0061413EBFF5F74F4442@SAUSEXMB2.amd.com>	<445733D0.6050004@suehsi.de>
	<44575B60.7050406@suehsi.de>	<8a0c36780605020731w7d9d7048g524d640b4d3ed665@mail.gmail.com>	<44578BAB.80008@suehsi.de>
	<44579320.90206@suehsi.de>	<8a0c36780605020925h6110f2d8pa656fde32cc5adfb@mail.gmail.com>	<4457ADD6.8020608@suehsi.de>
	<4457B0C0.8080304@suehsi.de>	<4457B6C8.1070404@suehsi.de>
	<8a0c36780605021527s5f8fal5f17a895c075f6a6@mail.gmail.com>
Message-ID: <44587BDE.9010800@suehsi.de>


> 
> Also did you run the user emu with the if (port < 0x53) filter on the
> IO?   I want to first rule out that its an issue with reading the
> system timer.


Here is the user emu output with enabled (port < 0x53) filter.
as I say, no output for that ;)

chris
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: patch_io_vga.cap
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20060503/eca4da01/attachment.ksh>

From stuge-linuxbios at cdy.org  Wed May  3 11:27:58 2006
From: stuge-linuxbios at cdy.org (Peter Stuge)
Date: Wed, 3 May 2006 11:27:58 +0200
Subject: [LinuxBIOS] Error in FSF high priority list LinuxBIOS
	description
In-Reply-To: <2ea3fae10605030018v3a2e9b87hc4b1f72a417ec0c3@mail.gmail.com>
References: <8a0c36780605022207s499eeaaehb77c6edbad08d1dd@mail.gmail.com>
	<20060503062914.22735.qmail@cdy.org>
	<2ea3fae10605030018v3a2e9b87hc4b1f72a417ec0c3@mail.gmail.com>
Message-ID: <20060503092758.11891.qmail@cdy.org>

On Wed, May 03, 2006 at 12:18:17AM -0700, yhlu wrote:
> Not future, with LinuxBIOS+kernel+kexec..we already can use kernel
> as bootloader...

I agree, it can be done today, but..


> current we only put some effects to provide tiny kernel and small
> ramdisk...

..because of these issues it isn't the norm.

Has anyone even gotten a LinuxBIOS with Linux payload into 512KB?


> fastboot seems to provide the ramdisk...

Do you know if it's an initramfs? I haven't gotten around to
experimenting with that yet, but it looks nice.


//Peter



From stepan at coresystems.de  Wed May  3 11:47:25 2006
From: stepan at coresystems.de (Stefan Reinauer)
Date: Wed, 3 May 2006 11:47:25 +0200
Subject: [LinuxBIOS] MB1030 / 3036 VGA comes up :D
In-Reply-To: <44587215.6010507@suehsi.de>
References: <8a0c36780605010706m2bed1a6eja546e5b941f46c1a@mail.gmail.com>
	<445652FA.7030009@suehsi.de>
	<8a0c36780605011133l5be7d2e8sbf8fa875824ffe8a@mail.gmail.com>
	<44566EC7.4090104@suehsi.de>
	<8a0c36780605011254i2edfa710h5ba481b7ae0a6093@mail.gmail.com>
	<44573C06.5030709@suehsi.de>
	<8a0c36780605020721v279f153ev7da4dc3ebb2d42d@mail.gmail.com>
	<44578A8E.9060608@suehsi.de> <20060502191652.GB4620@coresystems.de>
	<44587215.6010507@suehsi.de>
Message-ID: <20060503094725.GA9317@coresystems.de>

* Christian S?hs <chris at suehsi.de> [060503 11:04]:
> > To get back to the issues: What are we trying to solve exactly?
> > 
> >  - the 90s delay during VGA init.
> >  - anything else?
> 
> copying LB to RAM seems to be very slow ?!
> after boot, uncompressing the kernel is much slower as under factory bios.
 
How many megabytes in how many seconds? is it compressed?

> The filesystem is for any reason readonly after a boot?!
> Not under factory.
 
readonly root filesystem is the default. Maybe the boot parameters of
your "other" boot loader contain "rw" ?

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 chris at suehsi.de  Wed May  3 14:17:15 2006
From: chris at suehsi.de (=?UTF-8?B?Q2hyaXN0aWFuIFPDvGhz?=)
Date: Wed, 03 May 2006 14:17:15 +0200
Subject: [LinuxBIOS] MB1030 / 3036 VGA comes up :D
In-Reply-To: <20060503094725.GA9317@coresystems.de>
References: <8a0c36780605010706m2bed1a6eja546e5b941f46c1a@mail.gmail.com>	<445652FA.7030009@suehsi.de>	<8a0c36780605011133l5be7d2e8sbf8fa875824ffe8a@mail.gmail.com>	<44566EC7.4090104@suehsi.de>	<8a0c36780605011254i2edfa710h5ba481b7ae0a6093@mail.gmail.com>	<44573C06.5030709@suehsi.de>	<8a0c36780605020721v279f153ev7da4dc3ebb2d42d@mail.gmail.com>	<44578A8E.9060608@suehsi.de>
	<20060502191652.GB4620@coresystems.de>	<44587215.6010507@suehsi.de>
	<20060503094725.GA9317@coresystems.de>
Message-ID: <44589F4B.7070202@suehsi.de>


>>> - the 90s delay during VGA init.
>>> - anything else?
>>
>>copying LB to RAM seems to be very slow ?!

takes about 3 - 4 seconds for the 256k image

>>after boot, uncompressing the kernel is much slower as under factory bios.
>  

> How many megabytes in how many seconds? is it compressed?

Its done in 8 - 9 seconds. kernel is 700k big.
Well, it is a bzImage and should be compressed.
> 
> 
>>The filesystem is for any reason readonly after a boot?!
>>Not under factory.
> 
>  
> readonly root filesystem is the default. Maybe the boot parameters of
> your "other" boot loader contain "rw" ?

Waaaah, yeah I have forgotten to insert "rw" parameter for the 
commandline in filo.

Thanks for the hint.

chris
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: final_bios1.cap
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20060503/8679b3a0/attachment.ksh>

From stepan at coresystems.de  Wed May  3 13:12:01 2006
From: stepan at coresystems.de (Stefan Reinauer)
Date: Wed, 3 May 2006 13:12:01 +0200
Subject: [LinuxBIOS] MB1030 / 3036 VGA comes up :D
In-Reply-To: <44589F4B.7070202@suehsi.de>
References: <8a0c36780605011133l5be7d2e8sbf8fa875824ffe8a@mail.gmail.com>
	<44566EC7.4090104@suehsi.de>
	<8a0c36780605011254i2edfa710h5ba481b7ae0a6093@mail.gmail.com>
	<44573C06.5030709@suehsi.de>
	<8a0c36780605020721v279f153ev7da4dc3ebb2d42d@mail.gmail.com>
	<44578A8E.9060608@suehsi.de> <20060502191652.GB4620@coresystems.de>
	<44587215.6010507@suehsi.de> <20060503094725.GA9317@coresystems.de>
	<44589F4B.7070202@suehsi.de>
Message-ID: <20060503111201.GA13072@coresystems.de>

* Christian S?hs <chris at suehsi.de> [060503 14:17]:
> >>copying LB to RAM seems to be very slow ?!
> 
> takes about 3 - 4 seconds for the 256k image
 
> >>after boot, uncompressing the kernel is much slower as under factory bios.

> >How many megabytes in how many seconds? is it compressed?
> 
> Its done in 8 - 9 seconds. kernel is 700k big.
> Well, it is a bzImage and should be compressed.


Ok, all this sounds as if all memory as such is either not cacheable
or cache is deactivated. 

Questions to solve:

 * Are there mechanisms specific to the GX1 that are not required on 
   other systems to enable cache? 

 * Are the MTRRs set correctly?

 * Does this occur on other GX1 boards as well, but was not detected so
   far?

 * If yes, whats the difference to LinuxBIOSv1 here, because I seem to
   remember we did not have such a problem back then.

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 chris at suehsi.de  Wed May  3 15:21:33 2006
From: chris at suehsi.de (=?UTF-8?B?Q2hyaXN0aWFuIFPDvGhz?=)
Date: Wed, 03 May 2006 15:21:33 +0200
Subject: [LinuxBIOS] MB1030 / 3036 VGA comes up :D
In-Reply-To: <20060503111201.GA13072@coresystems.de>
References: <8a0c36780605011133l5be7d2e8sbf8fa875824ffe8a@mail.gmail.com>
	<44566EC7.4090104@suehsi.de>
	<8a0c36780605011254i2edfa710h5ba481b7ae0a6093@mail.gmail.com>
	<44573C06.5030709@suehsi.de>
	<8a0c36780605020721v279f153ev7da4dc3ebb2d42d@mail.gmail.com>
	<44578A8E.9060608@suehsi.de> <20060502191652.GB4620@coresystems.de>
	<44587215.6010507@suehsi.de> <20060503094725.GA9317@coresystems.de>
	<44589F4B.7070202@suehsi.de>
	<20060503111201.GA13072@coresystems.de>
Message-ID: <4458AE5D.5010100@suehsi.de>


> 
> Ok, all this sounds as if all memory as such is either not cacheable
> or cache is deactivated. 
> 
> Questions to solve:
> 
>  * Are there mechanisms specific to the GX1 that are not required on 
>    other systems to enable cache?

I'm not sure, but this cpu works for many functions not on the normal way.

> 
>  * Are the MTRRs set correctly?

MTRR seems not present for this CPU

> 
>  * Does this occur on other GX1 boards as well, but was not detected so
>    far?

I don't know ;)

> 
>  * If yes, whats the difference to LinuxBIOSv1 here, because I seem to
>    remember we did not have such a problem back then.


I have catched the Kernel output for both Bioses
(attachement)

There are some differents for the memory configuration.

Have a look

> 
> Stefan
> 

-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: mtrr.cap
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20060503/50741ba0/attachment.ksh>

From stepan at coresystems.de  Wed May  3 14:38:39 2006
From: stepan at coresystems.de (Stefan Reinauer)
Date: Wed, 3 May 2006 14:38:39 +0200
Subject: [LinuxBIOS] MB1030 / 3036 VGA comes up :D
In-Reply-To: <4458AE5D.5010100@suehsi.de>
References: <8a0c36780605011254i2edfa710h5ba481b7ae0a6093@mail.gmail.com>
	<44573C06.5030709@suehsi.de>
	<8a0c36780605020721v279f153ev7da4dc3ebb2d42d@mail.gmail.com>
	<44578A8E.9060608@suehsi.de> <20060502191652.GB4620@coresystems.de>
	<44587215.6010507@suehsi.de> <20060503094725.GA9317@coresystems.de>
	<44589F4B.7070202@suehsi.de>
	<20060503111201.GA13072@coresystems.de>
	<4458AE5D.5010100@suehsi.de>
Message-ID: <20060503123839.GA15356@coresystems.de>

* Christian S?hs <chris at suehsi.de> [060503 15:21]:
> >
> > * If yes, whats the difference to LinuxBIOSv1 here, because I seem to
> >   remember we did not have such a problem back then.
> 
> 
> I have catched the Kernel output for both Bioses
> (attachement)
> 
> There are some differents for the memory configuration.
 
Ok, one thing is you can change this:
#define FRAMEBUFFERK 4096
  to 
#define FRAMEBUFFERK 0
 in

src/northbridge/amd/gx1/northbridge.c. But this will do nothing but gain
you the 4 Megabytes of RAM that are normally reserved for the onchip vga
(which you dont use anyways)

> hm, page 00000000 reserved twice.		// what does it mean

good question. Anyone?

> DMI not present.				// Why not ?

Because its not needed. We dont do DMI but we have a mechanism called
the "LinuxBIOS table"

LinuxBIOS:
> PCI: Using IRQ router NatSemi [1078/0100] at 00:12.0
> PCI: Fixup for MediaGX/Geode Slave Disconnect Boundary (0x41=0x10)

factory:
> PCI: Using IRQ router NatSemi [1078/0100] at 00:12.0

... Ok. other attempt.

Boot up with LinuxBIOS and boot up with factory bios, and do 

lspci -xxx  > pcioutput.txt

as root.
Then send the two files to this list.

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 smithbone at gmail.com  Wed May  3 14:46:21 2006
From: smithbone at gmail.com (Richard Smith)
Date: Wed, 3 May 2006 07:46:21 -0500
Subject: [LinuxBIOS] MB1030 / 3036 VGA comes up :D
In-Reply-To: <4458700D.5060103@suehsi.de>
References: <0E81348C5627674A9C0061413EBFF5F74F4442@SAUSEXMB2.amd.com>
	<8a0c36780605020731w7d9d7048g524d640b4d3ed665@mail.gmail.com>
	<44578BAB.80008@suehsi.de> <44579320.90206@suehsi.de>
	<8a0c36780605020925h6110f2d8pa656fde32cc5adfb@mail.gmail.com>
	<4457ADD6.8020608@suehsi.de> <4457B0C0.8080304@suehsi.de>
	<4457B6C8.1070404@suehsi.de>
	<8a0c36780605021527s5f8fal5f17a895c075f6a6@mail.gmail.com>
	<4458700D.5060103@suehsi.de>
Message-ID: <8a0c36780605030546q2900f3bcqdd2127346fc7fd62@mail.gmail.com>

> > I know the log will be huge.  Go ahead and run the user emu with the
> > IO enabled for say 10 seconds and then quit.  That should be enough to
> > start with.  It should compress down alot since its all text.
> >
> I have send the log to you, yesterday. Or not ??

The only thing I got yesterday was a 90k log that did not include any
in statements.

--
Richard A. Smith



From smithbone at gmail.com  Wed May  3 14:47:46 2006
From: smithbone at gmail.com (Richard Smith)
Date: Wed, 3 May 2006 07:47:46 -0500
Subject: [LinuxBIOS] MB1030 / 3036 VGA comes up :D
In-Reply-To: <44587BDE.9010800@suehsi.de>
References: <0E81348C5627674A9C0061413EBFF5F74F4442@SAUSEXMB2.amd.com>
	<8a0c36780605020731w7d9d7048g524d640b4d3ed665@mail.gmail.com>
	<44578BAB.80008@suehsi.de> <44579320.90206@suehsi.de>
	<8a0c36780605020925h6110f2d8pa656fde32cc5adfb@mail.gmail.com>
	<4457ADD6.8020608@suehsi.de> <4457B0C0.8080304@suehsi.de>
	<4457B6C8.1070404@suehsi.de>
	<8a0c36780605021527s5f8fal5f17a895c075f6a6@mail.gmail.com>
	<44587BDE.9010800@suehsi.de>
Message-ID: <8a0c36780605030547o3c5ab2c0g8049e5f306f34143@mail.gmail.com>

On 5/3/06, Christian S?hs <chris at suehsi.de> wrote:

> >
> > Also did you run the user emu with the if (port < 0x53) filter on the
> > IO?   I want to first rule out that its an issue with reading the
> > system timer.
>
>
> Here is the user emu output with enabled (port < 0x53) filter.
> as I say, no output for that ;)
>

Ok. Thanks.  Well then that rules out timer 1 or 2 issues.  Very
interesting that it does not use the timer for any delays.

--
Richard A. Smith



From chris at suehsi.de  Wed May  3 16:13:33 2006
From: chris at suehsi.de (=?UTF-8?B?Q2hyaXN0aWFuIFPDvGhz?=)
Date: Wed, 03 May 2006 16:13:33 +0200
Subject: [LinuxBIOS] MB1030 / 3036 VGA comes up :D
In-Reply-To: <20060503123839.GA15356@coresystems.de>
References: <8a0c36780605011254i2edfa710h5ba481b7ae0a6093@mail.gmail.com>
	<44573C06.5030709@suehsi.de>
	<8a0c36780605020721v279f153ev7da4dc3ebb2d42d@mail.gmail.com>
	<44578A8E.9060608@suehsi.de> <20060502191652.GB4620@coresystems.de>
	<44587215.6010507@suehsi.de> <20060503094725.GA9317@coresystems.de>
	<44589F4B.7070202@suehsi.de>
	<20060503111201.GA13072@coresystems.de>
	<4458AE5D.5010100@suehsi.de>
	<20060503123839.GA15356@coresystems.de>
Message-ID: <4458BA8D.20205@suehsi.de>


> 
> ... Ok. other attempt.
> 
> Boot up with LinuxBIOS and boot up with factory bios, and do 
> 
> lspci -xxx  > pcioutput.txt
> 


Ok, here are the two files.

chris
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: pci_factory.cap
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20060503/cf8a2781/attachment.ksh>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: pci_lb.cap
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20060503/cf8a2781/attachment-0001.ksh>

From smithbone at gmail.com  Wed May  3 14:53:47 2006
From: smithbone at gmail.com (Richard Smith)
Date: Wed, 3 May 2006 07:53:47 -0500
Subject: [LinuxBIOS] MB1030 / 3036 VGA comes up :D
In-Reply-To: <44589F4B.7070202@suehsi.de>
References: <8a0c36780605010706m2bed1a6eja546e5b941f46c1a@mail.gmail.com>
	<44566EC7.4090104@suehsi.de>
	<8a0c36780605011254i2edfa710h5ba481b7ae0a6093@mail.gmail.com>
	<44573C06.5030709@suehsi.de>
	<8a0c36780605020721v279f153ev7da4dc3ebb2d42d@mail.gmail.com>
	<44578A8E.9060608@suehsi.de> <20060502191652.GB4620@coresystems.de>
	<44587215.6010507@suehsi.de> <20060503094725.GA9317@coresystems.de>
	<44589F4B.7070202@suehsi.de>
Message-ID: <8a0c36780605030553i6306cb42r19cc558be3af0db8@mail.gmail.com>

> // I'm not sure, vga console says on this point "uncompressing the kernel"
> // is done in 8-9 seconds kernel is 700k big
> // under factory this is done much faster (1-2s)
>
> Linux version 2.4.22 (root at linux) (gcc version 3.3 20030226 (prerelease) (SuSE Linux)) #11 Sat Apr 22 18:51:23 CEST 2006
>

All of this slow if probally some sort of caching issue like Ron has
been saying all along.

--
Richard A. Smith



From smithbone at gmail.com  Wed May  3 14:56:29 2006
From: smithbone at gmail.com (Richard Smith)
Date: Wed, 3 May 2006 07:56:29 -0500
Subject: [LinuxBIOS] MB1030 / 3036 VGA comes up :D
In-Reply-To: <44587215.6010507@suehsi.de>
References: <8a0c36780604301419y7f9b8045ie57b8f19bdeb6e2b@mail.gmail.com>
	<445652FA.7030009@suehsi.de>
	<8a0c36780605011133l5be7d2e8sbf8fa875824ffe8a@mail.gmail.com>
	<44566EC7.4090104@suehsi.de>
	<8a0c36780605011254i2edfa710h5ba481b7ae0a6093@mail.gmail.com>
	<44573C06.5030709@suehsi.de>
	<8a0c36780605020721v279f153ev7da4dc3ebb2d42d@mail.gmail.com>
	<44578A8E.9060608@suehsi.de> <20060502191652.GB4620@coresystems.de>
	<44587215.6010507@suehsi.de>
Message-ID: <8a0c36780605030556w904e6aepbee9c77d5025b753@mail.gmail.com>

On 5/3/06, Christian S?hs <chris at suehsi.de> wrote:

> > To get back to the issues: What are we trying to solve exactly?
> >
> >  - the 90s delay during VGA init.
> >  - anything else?

I'm currently trying to understand 2 issues the 90 second in-tree emu
delay and why the in-tree emu dies when a long delay is inserted in
between IO statements.

--
Richard A. Smith



From chris at suehsi.de  Wed May  3 16:23:55 2006
From: chris at suehsi.de (=?ISO-8859-1?Q?Christian_S=FChs?=)
Date: Wed, 03 May 2006 16:23:55 +0200
Subject: [LinuxBIOS] MB1030 / 3036 VGA comes up :D
In-Reply-To: <8a0c36780605030553i6306cb42r19cc558be3af0db8@mail.gmail.com>
References: <8a0c36780605010706m2bed1a6eja546e5b941f46c1a@mail.gmail.com>	
	<44566EC7.4090104@suehsi.de>	
	<8a0c36780605011254i2edfa710h5ba481b7ae0a6093@mail.gmail.com>	
	<44573C06.5030709@suehsi.de>	
	<8a0c36780605020721v279f153ev7da4dc3ebb2d42d@mail.gmail.com>	
	<44578A8E.9060608@suehsi.de>
	<20060502191652.GB4620@coresystems.de>	
	<44587215.6010507@suehsi.de>
	<20060503094725.GA9317@coresystems.de>	
	<44589F4B.7070202@suehsi.de>
	<8a0c36780605030553i6306cb42r19cc558be3af0db8@mail.gmail.com>
Message-ID: <4458BCFB.7020801@suehsi.de>

Richard Smith schrieb:
>> // I'm not sure, vga console says on this point "uncompressing the 
>> kernel"
>> // is done in 8-9 seconds kernel is 700k big
>> // under factory this is done much faster (1-2s)
>>
>> Linux version 2.4.22 (root at linux) (gcc version 3.3 20030226 
>> (prerelease) (SuSE Linux)) #11 Sat Apr 22 18:51:23 CEST 2006
>>
> 
> All of this slow if probally some sort of caching issue like Ron has
> been saying all along.
> 

Yeah, I have compared the whole kernel boot time for both. (after jump 
to entry point)

Factory bios is 15seconds faster as LB.

factory = 23s
LinuxBios = 38s

chris



From smithbone at gmail.com  Wed May  3 15:04:43 2006
From: smithbone at gmail.com (Richard Smith)
Date: Wed, 3 May 2006 08:04:43 -0500
Subject: [LinuxBIOS] MB1030 / 3036 VGA comes up :D
In-Reply-To: <44586CDF.2060809@suehsi.de>
References: <8a0c36780605011259p721fb330j4d640fc17857cae8@mail.gmail.com>
	<8a0c36780605020731w7d9d7048g524d640b4d3ed665@mail.gmail.com>
	<44578BAB.80008@suehsi.de> <44579320.90206@suehsi.de>
	<8a0c36780605020925h6110f2d8pa656fde32cc5adfb@mail.gmail.com>
	<4457ADD6.8020608@suehsi.de> <20060502192823.GC4620@coresystems.de>
	<4457CB2A.4030908@suehsi.de> <20060502205654.GB11460@coresystems.de>
	<44586CDF.2060809@suehsi.de>
Message-ID: <8a0c36780605030604k2f33d00l33619a65a9876051@mail.gmail.com>

On 5/3/06, Christian S?hs <chris at suehsi.de> wrote:

> I'm not sure, as I say.
> Yesterday I have wait about one cigarette length and captured 5MB of
> (0x03da) = 0xff ;) before stopping the test.
> But the screen comes not completly up.

So you sent me that log?  If you did then resend and give it a
different subject.

> I think the printf stuff takes a longer time ( like 500us) that means
> that a whole run takes for example 10 minutes or longer.

The printk stuff will take 87us per character sent.  With the strings
we are sending that works out to about 1.1 mS.  Thats why I wanted to
start with udelay(1500) as a replacement.

> > So it works when you enable above debug and wait long enough?

> It could, but I don't know it. I will try it again and wait longer
> without capturing the output.

I missed the result of this test.

--
Richard A. Smith



From chris at suehsi.de  Wed May  3 16:34:24 2006
From: chris at suehsi.de (=?ISO-8859-1?Q?Christian_S=FChs?=)
Date: Wed, 03 May 2006 16:34:24 +0200
Subject: [LinuxBIOS] MB1030 / 3036 VGA comes up :D
In-Reply-To: <8a0c36780605030556w904e6aepbee9c77d5025b753@mail.gmail.com>
References: <8a0c36780604301419y7f9b8045ie57b8f19bdeb6e2b@mail.gmail.com>	<445652FA.7030009@suehsi.de>	<8a0c36780605011133l5be7d2e8sbf8fa875824ffe8a@mail.gmail.com>	<44566EC7.4090104@suehsi.de>	<8a0c36780605011254i2edfa710h5ba481b7ae0a6093@mail.gmail.com>	<44573C06.5030709@suehsi.de>	<8a0c36780605020721v279f153ev7da4dc3ebb2d42d@mail.gmail.com>	<44578A8E.9060608@suehsi.de>
	<20060502191652.GB4620@coresystems.de>	<44587215.6010507@suehsi.de>
	<8a0c36780605030556w904e6aepbee9c77d5025b753@mail.gmail.com>
Message-ID: <4458BF70.5080900@suehsi.de>

Richard Smith schrieb:
> On 5/3/06, Christian S?hs <chris at suehsi.de> wrote:
> 
> 
>>>To get back to the issues: What are we trying to solve exactly?
>>>
>>> - the 90s delay during VGA init.
>>> - anything else?
> 
> 
> I'm currently trying to understand 2 issues the 90 second in-tree emu
> delay and why the in-tree emu dies when a long delay is inserted in
> between IO statements.

We are not sure, if it dies. I havn't tried this yet.
Because with udelay(250) it tooks about 5 minutes to completly init the vga.

It could be that a udelay of 500 increase this time to 10 minutes or more.

The printfs for the user space emu i.e takes a time of 500 and that for 
each of them. Remember I have captured 5MB of 0xff. This are I guess 
300.000 lines or more, before I stopped this test. Compute this with 500us.

But I think there is no sense to test it.

Failing of the printks for the inTree emu seems to be an other problem.

chris



> 
> --
> Richard A. Smith
> 





From smithbone at gmail.com  Wed May  3 15:16:57 2006
From: smithbone at gmail.com (Richard Smith)
Date: Wed, 3 May 2006 08:16:57 -0500
Subject: [LinuxBIOS] MB1030 / 3036 VGA comes up :D
In-Reply-To: <4458BF70.5080900@suehsi.de>
References: <8a0c36780604301419y7f9b8045ie57b8f19bdeb6e2b@mail.gmail.com>
	<44566EC7.4090104@suehsi.de>
	<8a0c36780605011254i2edfa710h5ba481b7ae0a6093@mail.gmail.com>
	<44573C06.5030709@suehsi.de>
	<8a0c36780605020721v279f153ev7da4dc3ebb2d42d@mail.gmail.com>
	<44578A8E.9060608@suehsi.de> <20060502191652.GB4620@coresystems.de>
	<44587215.6010507@suehsi.de>
	<8a0c36780605030556w904e6aepbee9c77d5025b753@mail.gmail.com>
	<4458BF70.5080900@suehsi.de>
Message-ID: <8a0c36780605030616u562ab41cm75c86e48588ef761@mail.gmail.com>

On 5/3/06, Christian S?hs <chris at suehsi.de> wrote:

> The printfs for the user space emu i.e takes a time of 500 and that for
> each of them. Remember I have captured 5MB of 0xff. This are I guess
> 300.000 lines or more, before I stopped this test. Compute this with 500us.
>
> But I think there is no sense to test it.

Ah.. Ok.  I understand now.


--
Richard A. Smith



From chris at suehsi.de  Wed May  3 17:02:40 2006
From: chris at suehsi.de (=?UTF-8?B?Q2hyaXN0aWFuIFPDvGhz?=)
Date: Wed, 03 May 2006 17:02:40 +0200
Subject: [LinuxBIOS] MB1030 / 3036 VGA comes up :D
In-Reply-To: <20060503123839.GA15356@coresystems.de>
References: <8a0c36780605011254i2edfa710h5ba481b7ae0a6093@mail.gmail.com>
	<44573C06.5030709@suehsi.de>
	<8a0c36780605020721v279f153ev7da4dc3ebb2d42d@mail.gmail.com>
	<44578A8E.9060608@suehsi.de> <20060502191652.GB4620@coresystems.de>
	<44587215.6010507@suehsi.de> <20060503094725.GA9317@coresystems.de>
	<44589F4B.7070202@suehsi.de>
	<20060503111201.GA13072@coresystems.de>
	<4458AE5D.5010100@suehsi.de>
	<20060503123839.GA15356@coresystems.de>
Message-ID: <4458C610.2050407@suehsi.de>


> LinuxBIOS:
> 
>>PCI: Using IRQ router NatSemi [1078/0100] at 00:12.0
>>PCI: Fixup for MediaGX/Geode Slave Disconnect Boundary (0x41=0x10)
> 
> 
> factory:
> 
>>PCI: Using IRQ router NatSemi [1078/0100] at 00:12.0
> 

I have found some stuff about this fixup.

It solves a problem with master PCI transfers

without this fixup the transfer is lowered from 70MB/s to 25MB/s.

Ok, that could be solve some problems, but what about the copying and 
uncompressig stuff. I think there is the pci bus not affected.

However, we should try to set this bit and seen what happens.

chris



From ward at gnu.org  Wed May  3 16:44:48 2006
From: ward at gnu.org (Ward Vandewege)
Date: Wed, 3 May 2006 10:44:48 -0400
Subject: [LinuxBIOS] Error in FSF high priority list LinuxBIOS
	description
In-Reply-To: <20060503062914.22735.qmail@cdy.org>
References: <8a0c36780605022207s499eeaaehb77c6edbad08d1dd@mail.gmail.com>
	<20060503062914.22735.qmail@cdy.org>
Message-ID: <20060503144448.GA4006@localdomain>

On Wed, May 03, 2006 at 08:29:14AM +0200, Peter Stuge wrote:
> On Wed, May 03, 2006 at 12:07:47AM -0500, Richard Smith wrote:
> > Anyone else think it needs changing?
> 
> Yes. Who do we ask? Can Ward make the change?

Yes; as soon as there is consensus on a better wording?

Ward.

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



From smithbone at gmail.com  Wed May  3 16:49:17 2006
From: smithbone at gmail.com (Richard Smith)
Date: Wed, 3 May 2006 09:49:17 -0500
Subject: [LinuxBIOS] Error in FSF high priority list LinuxBIOS
	description
In-Reply-To: <20060503144448.GA4006@localdomain>
References: <8a0c36780605022207s499eeaaehb77c6edbad08d1dd@mail.gmail.com>
	<20060503062914.22735.qmail@cdy.org>
	<20060503144448.GA4006@localdomain>
Message-ID: <8a0c36780605030749u6d44fe21y14b21556db00ef4b@mail.gmail.com>

> >
> > Yes. Who do we ask? Can Ward make the change?
>
> Yes; as soon as there is consensus on a better wording?
>

Perhaps there is already something on the wiki that will work?

--
Richard A. Smith



From rminnich at lanl.gov  Wed May  3 17:45:28 2006
From: rminnich at lanl.gov (Ronald G Minnich)
Date: Wed, 03 May 2006 09:45:28 -0600
Subject: [LinuxBIOS] Error in FSF high priority list LinuxBIOS
	description
In-Reply-To: <8a0c36780605022207s499eeaaehb77c6edbad08d1dd@mail.gmail.com>
References: <8a0c36780605022207s499eeaaehb77c6edbad08d1dd@mail.gmail.com>
Message-ID: <4458D018.6020503@lanl.gov>

Richard Smith wrote:

> Anyone else think it needs changing?

The original goal of linuxbios was that linux would be the bios.

sadly, linux got big and flash got small.

That said, on OLPC, we're going to try again. In fact I'm gearing up to 
try putting some gcc code into linux and loading linux direct from 
romcc-based code. I think it might work.

Who knows what's true :-)

ron



From chris at suehsi.de  Wed May  3 19:15:33 2006
From: chris at suehsi.de (=?ISO-8859-1?Q?Christian_S=FChs?=)
Date: Wed, 03 May 2006 19:15:33 +0200
Subject: [LinuxBIOS] MB1030 / 3036 VGA comes up :D
In-Reply-To: <4458C610.2050407@suehsi.de>
References: <8a0c36780605011254i2edfa710h5ba481b7ae0a6093@mail.gmail.com>	<44573C06.5030709@suehsi.de>	<8a0c36780605020721v279f153ev7da4dc3ebb2d42d@mail.gmail.com>	<44578A8E.9060608@suehsi.de>
	<20060502191652.GB4620@coresystems.de>	<44587215.6010507@suehsi.de>
	<20060503094725.GA9317@coresystems.de>	<44589F4B.7070202@suehsi.de>	<20060503111201.GA13072@coresystems.de>	<4458AE5D.5010100@suehsi.de>	<20060503123839.GA15356@coresystems.de>
	<4458C610.2050407@suehsi.de>
Message-ID: <4458E535.6040303@suehsi.de>


> 
> However, we should try to set this bit and seen what happens.
>

ok, I have set 41h in northbridge.c to 0x10
but the problems are the same as before

very slow vga ;)
slow boottime

> chris
> 




From rminnich at lanl.gov  Wed May  3 17:47:29 2006
From: rminnich at lanl.gov (Ronald G Minnich)
Date: Wed, 03 May 2006 09:47:29 -0600
Subject: [LinuxBIOS] Error in FSF high priority list
	LinuxBIOS	description
In-Reply-To: <20060503092758.11891.qmail@cdy.org>
References: <8a0c36780605022207s499eeaaehb77c6edbad08d1dd@mail.gmail.com>	<20060503062914.22735.qmail@cdy.org>	<2ea3fae10605030018v3a2e9b87hc4b1f72a417ec0c3@mail.gmail.com>
	<20060503092758.11891.qmail@cdy.org>
Message-ID: <4458D091.9020905@lanl.gov>

Peter Stuge wrote:

> Has anyone even gotten a LinuxBIOS with Linux payload into 512KB?

Oh yea. In 2000, it was very common to jam a 2.2 kernel into a 512kb 
flash part ... very easy. Etherboot etc. came much later, and were ONLY 
put in because vendors moved to 256KB flash parts, which killed us.

in fact, back then, there was an uncompressor in linuxbios itself, much 
like what stefan just added to V2. It was later removed -- long story. I 
was glad to see it return.

ron



From rminnich at lanl.gov  Wed May  3 17:48:19 2006
From: rminnich at lanl.gov (Ronald G Minnich)
Date: Wed, 03 May 2006 09:48:19 -0600
Subject: [LinuxBIOS] MB1030 / 3036 VGA comes up :D
In-Reply-To: <44586CDF.2060809@suehsi.de>
References: <8a0c36780605011259p721fb330j4d640fc17857cae8@mail.gmail.com>	<445733D0.6050004@suehsi.de>	<44575B60.7050406@suehsi.de>	<8a0c36780605020731w7d9d7048g524d640b4d3ed665@mail.gmail.com>	<44578BAB.80008@suehsi.de>	<44579320.90206@suehsi.de>	<8a0c36780605020925h6110f2d8pa656fde32cc5adfb@mail.gmail.com>	<4457ADD6.8020608@suehsi.de>	<20060502192823.GC4620@coresystems.de>	<4457CB2A.4030908@suehsi.de>	<20060502205654.GB11460@coresystems.de>
	<44586CDF.2060809@suehsi.de>
Message-ID: <4458D0C3.7020308@lanl.gov>

how about we take a different approach here. How big is your flash?

ron



From rminnich at lanl.gov  Wed May  3 17:48:52 2006
From: rminnich at lanl.gov (Ronald G Minnich)
Date: Wed, 03 May 2006 09:48:52 -0600
Subject: [LinuxBIOS] MB1030 / 3036 VGA comes up :D
In-Reply-To: <20060503094725.GA9317@coresystems.de>
References: <8a0c36780605010706m2bed1a6eja546e5b941f46c1a@mail.gmail.com>	<445652FA.7030009@suehsi.de>	<8a0c36780605011133l5be7d2e8sbf8fa875824ffe8a@mail.gmail.com>	<44566EC7.4090104@suehsi.de>	<8a0c36780605011254i2edfa710h5ba481b7ae0a6093@mail.gmail.com>	<44573C06.5030709@suehsi.de>	<8a0c36780605020721v279f153ev7da4dc3ebb2d42d@mail.gmail.com>	<44578A8E.9060608@suehsi.de>
	<20060502191652.GB4620@coresystems.de>	<44587215.6010507@suehsi.de>
	<20060503094725.GA9317@coresystems.de>
Message-ID: <4458D0E4.6080201@lanl.gov>

Stefan Reinauer wrote:
> * Christian S?hs <chris at suehsi.de> [060503 11:04]:
> 
>>>To get back to the issues: What are we trying to solve exactly?
>>>
>>> - the 90s delay during VGA init.
>>> - anything else?
>>
>>copying LB to RAM seems to be very slow ?!
>>after boot, uncompressing the kernel is much slower as under factory bios.
> 
>  
> How many megabytes in how many seconds? is it compressed?

There is a caching, MTRR, or special register problem here. That's got 
to be happening.

ron




From yinghai.lu at amd.com  Wed May  3 18:01:29 2006
From: yinghai.lu at amd.com (Lu, Yinghai)
Date: Wed, 3 May 2006 09:01:29 -0700
Subject: [LinuxBIOS] Error in FSF high priority list LinuxBIOS
 description
Message-ID: <6F7DA19D05F3CF40B890C7CA2DB13A4203094C38@ssvlexmb2.amd.com>

You don't need linuxbios_ram part to scan pci and allocate resource for
PCI devices? Or let kernel to do these allocation?

YH

-----Original Message-----
From: linuxbios-bounces at linuxbios.org
[mailto:linuxbios-bounces at linuxbios.org] On Behalf Of Ronald G Minnich
Sent: Wednesday, May 03, 2006 8:45 AM
To: Richard Smith
Cc: LinuxBIOS
Subject: Re: [LinuxBIOS] Error in FSF high priority list LinuxBIOS
description

Richard Smith wrote:

> Anyone else think it needs changing?

The original goal of linuxbios was that linux would be the bios.

sadly, linux got big and flash got small.

That said, on OLPC, we're going to try again. In fact I'm gearing up to 
try putting some gcc code into linux and loading linux direct from 
romcc-based code. I think it might work.

Who knows what's true :-)

ron

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





From rminnich at lanl.gov  Wed May  3 18:10:54 2006
From: rminnich at lanl.gov (Ronald G Minnich)
Date: Wed, 03 May 2006 10:10:54 -0600
Subject: [LinuxBIOS] MB1030 / 3036 VGA comes up :D
In-Reply-To: <4458E535.6040303@suehsi.de>
References: <8a0c36780605011254i2edfa710h5ba481b7ae0a6093@mail.gmail.com>	<44573C06.5030709@suehsi.de>	<8a0c36780605020721v279f153ev7da4dc3ebb2d42d@mail.gmail.com>	<44578A8E.9060608@suehsi.de>	<20060502191652.GB4620@coresystems.de>	<44587215.6010507@suehsi.de>	<20060503094725.GA9317@coresystems.de>	<44589F4B.7070202@suehsi.de>	<20060503111201.GA13072@coresystems.de>	<4458AE5D.5010100@suehsi.de>	<20060503123839.GA15356@coresystems.de>	<4458C610.2050407@suehsi.de>
	<4458E535.6040303@suehsi.de>
Message-ID: <4458D60E.10709@lanl.gov>

Christian S?hs wrote:
>>However, we should try to set this bit and seen what happens.
>>
> 
> 
> ok, I have set 41h in northbridge.c to 0x10
> but the problems are the same as before
> 
> very slow vga ;)
> slow boottime

so the question is, is there a range descriptor hidden somewhere that is 
controlling this. There are such registers in GX2 AND SC520 AND ....

it's common in this embedded stuff. What are we missing? Where are the 
docs on this chip. I can try to read them.

ron



From rminnich at lanl.gov  Wed May  3 18:14:08 2006
From: rminnich at lanl.gov (Ronald G Minnich)
Date: Wed, 03 May 2006 10:14:08 -0600
Subject: [LinuxBIOS] Error in FSF high priority list LinuxBIOS
	description
In-Reply-To: <6F7DA19D05F3CF40B890C7CA2DB13A4203094C38@ssvlexmb2.amd.com>
References: <6F7DA19D05F3CF40B890C7CA2DB13A4203094C38@ssvlexmb2.amd.com>
Message-ID: <4458D6D0.8070506@lanl.gov>

Lu, Yinghai wrote:
> You don't need linuxbios_ram part to scan pci and allocate resource for
> PCI devices? Or let kernel to do these allocation?

I want to find out how to let the kernel do it. It's almost capable. 
This was our goal, 6 years ago; maybe the kernel is ready.

ron



From yinghai.lu at amd.com  Wed May  3 18:28:37 2006
From: yinghai.lu at amd.com (Lu, Yinghai)
Date: Wed, 3 May 2006 09:28:37 -0700
Subject: [LinuxBIOS] Error in FSF high priority list LinuxBIOS
 description
Message-ID: <6F7DA19D05F3CF40B890C7CA2DB13A4203094C39@ssvlexmb2.amd.com>

1. So the kernel need to know Hypertransport HT scan.
2. Also we need to move silicon bug fix code to kernel driver..., or
cache_as_ram stage code...

YH

-----Original Message-----
From: Ronald G Minnich [mailto:rminnich at lanl.gov] 
Sent: Wednesday, May 03, 2006 9:14 AM
To: Lu, Yinghai
Cc: Richard Smith; LinuxBIOS
Subject: Re: [LinuxBIOS] Error in FSF high priority list LinuxBIOS
description

Lu, Yinghai wrote:
> You don't need linuxbios_ram part to scan pci and allocate resource
for
> PCI devices? Or let kernel to do these allocation?

I want to find out how to let the kernel do it. It's almost capable. 
This was our goal, 6 years ago; maybe the kernel is ready.

ron





From chris at suehsi.de  Wed May  3 19:51:24 2006
From: chris at suehsi.de (=?ISO-8859-1?Q?Christian_S=FChs?=)
Date: Wed, 03 May 2006 19:51:24 +0200
Subject: [LinuxBIOS] MB1030 / 3036 VGA comes up :D
In-Reply-To: <4458D60E.10709@lanl.gov>
References: <8a0c36780605011254i2edfa710h5ba481b7ae0a6093@mail.gmail.com>	<44573C06.5030709@suehsi.de>	<8a0c36780605020721v279f153ev7da4dc3ebb2d42d@mail.gmail.com>	<44578A8E.9060608@suehsi.de>	<20060502191652.GB4620@coresystems.de>	<44587215.6010507@suehsi.de>	<20060503094725.GA9317@coresystems.de>	<44589F4B.7070202@suehsi.de>	<20060503111201.GA13072@coresystems.de>	<4458AE5D.5010100@suehsi.de>	<20060503123839.GA15356@coresystems.de>	<4458C610.2050407@suehsi.de>
	<4458E535.6040303@suehsi.de> <4458D60E.10709@lanl.gov>
Message-ID: <4458ED9C.9090509@suehsi.de>


> 
> it's common in this embedded stuff. What are we missing? Where are the 
> docs on this chip. I can try to read them.
> 

here is the datasheet for the gx1

http://www.routerboard.com/PDF/gx1.pdf



> ron
> 




From chris at suehsi.de  Wed May  3 19:48:43 2006
From: chris at suehsi.de (=?ISO-8859-1?Q?Christian_S=FChs?=)
Date: Wed, 03 May 2006 19:48:43 +0200
Subject: [LinuxBIOS] MB1030 / 3036 VGA comes up :D
In-Reply-To: <4458E535.6040303@suehsi.de>
References: <8a0c36780605011254i2edfa710h5ba481b7ae0a6093@mail.gmail.com>	<44573C06.5030709@suehsi.de>	<8a0c36780605020721v279f153ev7da4dc3ebb2d42d@mail.gmail.com>	<44578A8E.9060608@suehsi.de>	<20060502191652.GB4620@coresystems.de>	<44587215.6010507@suehsi.de>	<20060503094725.GA9317@coresystems.de>	<44589F4B.7070202@suehsi.de>	<20060503111201.GA13072@coresystems.de>	<4458AE5D.5010100@suehsi.de>	<20060503123839.GA15356@coresystems.de>	<4458C610.2050407@suehsi.de>
	<4458E535.6040303@suehsi.de>
Message-ID: <4458ECFB.5030705@suehsi.de>

Christian S?hs schrieb:
>>However, we should try to set this bit and seen what happens.
>>
> 
> 
> ok, I have set 41h in northbridge.c to 0x10
> but the problems are the same as before
> 
> very slow vga ;)
> slow boottime

Oh, I forgot. The kernel fixup message is not longer shown.

> 
> 
>>chris
>>
> 
> 
> 





From rminnich at lanl.gov  Wed May  3 18:26:19 2006
From: rminnich at lanl.gov (Ronald G Minnich)
Date: Wed, 03 May 2006 10:26:19 -0600
Subject: [LinuxBIOS] Error in FSF high priority list LinuxBIOS
	description
In-Reply-To: <6F7DA19D05F3CF40B890C7CA2DB13A4203094C39@ssvlexmb2.amd.com>
References: <6F7DA19D05F3CF40B890C7CA2DB13A4203094C39@ssvlexmb2.amd.com>
Message-ID: <4458D9AB.80808@lanl.gov>

Lu, Yinghai wrote:
> 1. So the kernel need to know Hypertransport HT scan.
> 2. Also we need to move silicon bug fix code to kernel driver..., or
> cache_as_ram stage code...
> 
> 


I'm doing this on OLPC to start. HT is too much for me to think about.

Simple things first.

ron



From arc at xiph.org  Wed May  3 18:42:23 2006
From: arc at xiph.org (Arc Riley)
Date: Wed, 3 May 2006 09:42:23 -0700
Subject: [LinuxBIOS] Error in FSF high priority list LinuxBIOS
	description
In-Reply-To: <4458D018.6020503@lanl.gov>
References: <8a0c36780605022207s499eeaaehb77c6edbad08d1dd@mail.gmail.com>
	<4458D018.6020503@lanl.gov>
Message-ID: <20060503164223.GA6289@xiph.org>

On Wed, May 03, 2006 at 09:45:28AM -0600, Ronald G Minnich wrote:
> 
> sadly, linux got big and flash got small.

Linux can still be compiled down to under a meg, especially if many of 
the post-boot things are compiled as modules.



From MSamet at ea.com  Wed May  3 18:52:52 2006
From: MSamet at ea.com (Samet, Matt)
Date: Wed, 3 May 2006 09:52:52 -0700
Subject: [LinuxBIOS] State of vt8237 and consequently epia-ms
Message-ID: <9D3D7CEF3A236243AF0335652672E34810D19F04@maxis-mb1.max.ad.ea.com>

Hi Adam - 

I'd like to start looking into the VT8237 myself.
If possible, could I get that VT8237 doc from you? And possibly your WIP
code?
I can start to take a look, I have some time.

Thanks...
-=matt

-----Original Message-----
From: linuxbios-bounces at linuxbios.org
[mailto:linuxbios-bounces at linuxbios.org] On Behalf Of Adam Talbot
Sent: Saturday, April 29, 2006 12:37 PM
To: Andy Somerville
Cc: linuxbios at linuxbios.org
Subject: Re: [LinuxBIOS] State of vt8237 and consequently epia-ms

-Andy
Currently the is no support for the vt8237.
What would it take to support?  Some one who has a few weeks to work on
it.
I spent a few weeks, but was never able to get the console running. 
With out that, I had no way of doing debugging.  My board does not have
any PCI slots, so I was unable to use a post card to debug.
-Adam

Andy Somerville wrote:
> Hi all,
>
>
>      Im new to linuxbios and the mailing list so please excuse any
> newbie stupidity. I was wondering about the state of vt8237
> southbridge support. From my limited understanding of linuxBios this
> is virtually all that is missing for Epia-MS support since CLE266
> northbridge is already supported.
>
> I saw a post in february which mentioned vt8237 and that it was being
> worked on, but I have seen nothing since. Forgive me if Ive missed
> something.
>
> So I guess my overall question is: Is Epia-MS support a near
> possiblity, and what would it take to produce?
>
>
>        Andy
>
>   


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




From chris at suehsi.de  Wed May  3 20:41:47 2006
From: chris at suehsi.de (=?ISO-8859-1?Q?Christian_S=FChs?=)
Date: Wed, 03 May 2006 20:41:47 +0200
Subject: [LinuxBIOS] MB1030 / 3036 VGA comes up :D
In-Reply-To: <4458D0C3.7020308@lanl.gov>
References: <8a0c36780605011259p721fb330j4d640fc17857cae8@mail.gmail.com>	<445733D0.6050004@suehsi.de>	<44575B60.7050406@suehsi.de>	<8a0c36780605020731w7d9d7048g524d640b4d3ed665@mail.gmail.com>	<44578BAB.80008@suehsi.de>	<44579320.90206@suehsi.de>	<8a0c36780605020925h6110f2d8pa656fde32cc5adfb@mail.gmail.com>	<4457ADD6.8020608@suehsi.de>	<20060502192823.GC4620@coresystems.de>	<4457CB2A.4030908@suehsi.de>	<20060502205654.GB11460@coresystems.de>
	<44586CDF.2060809@suehsi.de> <4458D0C3.7020308@lanl.gov>
Message-ID: <4458F96B.1070002@suehsi.de>

Ronald G Minnich schrieb:
> how about we take a different approach here. How big is your flash?
> 
> ron
> 

256k.
I will have a look for a greater one in my boxes.

chris



From yinghai.lu at amd.com  Wed May  3 20:40:10 2006
From: yinghai.lu at amd.com (Lu, Yinghai)
Date: Wed, 3 May 2006 11:40:10 -0700
Subject: [LinuxBIOS] [FEATURE] payload compression
Message-ID: <6F7DA19D05F3CF40B890C7CA2DB13A4203094C3A@ssvlexmb2.amd.com>

Please check the attached zrom fix up.
1. copy_and_run.c double skip length
2. merge zrom_stream.c into rom_stream.c
3. ram position check to skip 0xa0000, and 0xf0000...

YH

-----Original Message-----
From: linuxbios-bounces at linuxbios.org
[mailto:linuxbios-bounces at linuxbios.org] On Behalf Of yhlu
Sent: Saturday, April 29, 2006 3:12 PM
To: Stefan Reinauer
Cc: linuxbios at linuxbios.org
Subject: Re: [LinuxBIOS] [FEATURE] payload compression

Good.  lib/unrv2b.c and CAR could include it....

YH

On 4/29/06, Stefan Reinauer <stepan at coresystems.de> wrote:
> * yhlu <yinghailu at gmail.com> [060429 23:41]:
> > the copy_and_run already have the same function that from nrv2b.c,
So
> > we share the function...
>
> Yes. I actually took it from copy_and_run.c.
>
> Should we put it to lib/unrv2b.c or similar and reference it in both
> places?
>
> I would assume that we have to compile it twice in any case, as the
one
> time it is running in CAR/romcc context and the other time we're in
> "late gcc" context.
>
> 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 --------------
A non-text attachment was scrubbed...
Name: 05032006_zrom_bugfix.diff
Type: application/octet-stream
Size: 8677 bytes
Desc: 05032006_zrom_bugfix.diff
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20060503/4a5e1ea1/attachment.obj>

From rminnich at lanl.gov  Wed May  3 20:41:19 2006
From: rminnich at lanl.gov (Ronald G Minnich)
Date: Wed, 03 May 2006 12:41:19 -0600
Subject: [LinuxBIOS] Error in FSF high priority list
	LinuxBIOS	description
In-Reply-To: <20060503164223.GA6289@xiph.org>
References: <8a0c36780605022207s499eeaaehb77c6edbad08d1dd@mail.gmail.com>	<4458D018.6020503@lanl.gov>
	<20060503164223.GA6289@xiph.org>
Message-ID: <4458F94F.5030706@lanl.gov>

Arc Riley wrote:
> On Wed, May 03, 2006 at 09:45:28AM -0600, Ronald G Minnich wrote:
> 
>>sadly, linux got big and flash got small.
> 
> 
> Linux can still be compiled down to under a meg, especially if many of 
> the post-boot things are compiled as modules.
> 

yeah, but it needs to be under (512-32)K. Plus, you need to stuff an 
initrd in there for basic utilities.

That's been harder.

ron



From c.jones at f5.com  Wed May  3 23:08:31 2006
From: c.jones at f5.com (Clay Jones)
Date: Wed, 3 May 2006 14:08:31 -0700
Subject: [LinuxBIOS] Error in FSF high priority listLinuxBIOS	description
Message-ID: <4E497EE4DD5F9347B242A83387F27DC84473EE@exchsix.olympus.f5net.com>


Or you can go the opposite direction. I have been using an sst49lf016c
2MB flash in a motherboard with an AMD8111 as the southbridge. Then I
used the kboot project to build a kernel and initrd that fits and can
kexec from ide, usb, or network.





 

Clay Jones  senior software engineer  |  c.jones at f5.com  | www.f5.com
P.  509 343 3500 |  F.  509 343 3501 | D.  509 343 3519 
F5 Networks  | 1322 North Whitman Lane  |  Liberty Lake, Washington
99019 

The Leader in Application Traffic Management
Ensuring secure and optimized application delivery for global
enterprises 
-----Original Message-----
From: linuxbios-bounces at linuxbios.org
[mailto:linuxbios-bounces at linuxbios.org] On Behalf Of Ronald G Minnich
Sent: Wednesday, May 03, 2006 11:41 AM
To: Arc Riley
Cc: linuxbios at linuxbios.org
Subject: Re: [LinuxBIOS] Error in FSF high priority listLinuxBIOS
description

Arc Riley wrote:
> On Wed, May 03, 2006 at 09:45:28AM -0600, Ronald G Minnich wrote:
> 
>>sadly, linux got big and flash got small.
> 
> 
> Linux can still be compiled down to under a meg, especially if many of

> the post-boot things are compiled as modules.
> 

yeah, but it needs to be under (512-32)K. Plus, you need to stuff an 
initrd in there for basic utilities.

That's been harder.

ron

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



From stepan at coresystems.de  Wed May  3 23:16:37 2006
From: stepan at coresystems.de (Stefan Reinauer)
Date: Wed, 3 May 2006 23:16:37 +0200
Subject: [LinuxBIOS] [FEATURE] payload compression
In-Reply-To: <6F7DA19D05F3CF40B890C7CA2DB13A4203094C3A@ssvlexmb2.amd.com>
References: <6F7DA19D05F3CF40B890C7CA2DB13A4203094C3A@ssvlexmb2.amd.com>
Message-ID: <20060503211636.GB1625@coresystems.de>

* Lu, Yinghai <yinghai.lu at amd.com> [060503 20:40]:
> Please check the attached zrom fix up.
> 1. copy_and_run.c double skip length
> 2. merge zrom_stream.c into rom_stream.c
> 3. ram position check to skip 0xa0000, and 0xf0000...

Makes perfect sense!

-- 
coresystems GmbH ? Brahmsstr. 16 ? D-79104 Freiburg i. Br.
      Tel.: +49 761 7668825 ? Fax: +49 761 7664613
Email: info at coresystems.de  ? http://www.coresystems.de/



From smithbone at gmail.com  Wed May  3 23:27:21 2006
From: smithbone at gmail.com (Richard Smith)
Date: Wed, 3 May 2006 16:27:21 -0500
Subject: [LinuxBIOS] Error in FSF high priority list LinuxBIOS
	description
In-Reply-To: <4458D018.6020503@lanl.gov>
References: <8a0c36780605022207s499eeaaehb77c6edbad08d1dd@mail.gmail.com>
	<4458D018.6020503@lanl.gov>
Message-ID: <8a0c36780605031427q5975fa22h12847eb0299e2300@mail.gmail.com>

On 5/3/06, Ronald G Minnich <rminnich at lanl.gov> wrote:

> That said, on OLPC, we're going to try again. In fact I'm gearing up to
> try putting some gcc code into linux and loading linux direct from
> romcc-based code. I think it might work.

So that may be true in the (near) future but its not true now and may
not ever be true for a lot of motherboards.
Perhaps then just a more detailed description that covers both where
it is and the ultimate goal?

--
Richard A. Smith



From yinghai.lu at amd.com  Wed May  3 23:29:07 2006
From: yinghai.lu at amd.com (Lu, Yinghai)
Date: Wed, 3 May 2006 14:29:07 -0700
Subject: [LinuxBIOS] Error in FSF high priority listLinuxBIOS description
Message-ID: <6F7DA19D05F3CF40B890C7CA2DB13A4203094C3B@ssvlexmb2.amd.com>

Good to hear that! 32 bit kernel?

What is size for kernel and initrd?

YH





From yinghai.lu at amd.com  Wed May  3 23:34:53 2006
From: yinghai.lu at amd.com (Lu, Yinghai)
Date: Wed, 3 May 2006 14:34:53 -0700
Subject: [LinuxBIOS] [FEATURE] payload compression
Message-ID: <6F7DA19D05F3CF40B890C7CA2DB13A4203094C3C@ssvlexmb2.amd.com>

The Etherboot 5.4 later has different size in elf prefix... to real file
size.

So we need to align rom_end to 16 bytes or use dd to make payload to 16
bytes align before nrv2b payload.nrv2b...

Which one is good?

YH



-----Original Message-----
From: Stefan Reinauer [mailto:stepan at coresystems.de] 
Sent: Wednesday, May 03, 2006 2:17 PM
To: Lu, Yinghai
Cc: linuxbios at linuxbios.org
Subject: Re: [LinuxBIOS] [FEATURE] payload compression

* Lu, Yinghai <yinghai.lu at amd.com> [060503 20:40]:
> Please check the attached zrom fix up.
> 1. copy_and_run.c double skip length
> 2. merge zrom_stream.c into rom_stream.c
> 3. ram position check to skip 0xa0000, and 0xf0000...

Makes perfect sense!

-- 
coresystems GmbH * Brahmsstr. 16 * D-79104 Freiburg i. Br.
      Tel.: +49 761 7668825 * Fax: +49 761 7664613
Email: info at coresystems.de  * http://www.coresystems.de/





From rminnich at lanl.gov  Wed May  3 23:56:50 2006
From: rminnich at lanl.gov (Ronald G Minnich)
Date: Wed, 03 May 2006 15:56:50 -0600
Subject: [LinuxBIOS] Error in FSF high priority list LinuxBIOS
	description
In-Reply-To: <8a0c36780605031427q5975fa22h12847eb0299e2300@mail.gmail.com>
References: <8a0c36780605022207s499eeaaehb77c6edbad08d1dd@mail.gmail.com>	
	<4458D018.6020503@lanl.gov>
	<8a0c36780605031427q5975fa22h12847eb0299e2300@mail.gmail.com>
Message-ID: <44592722.90205@lanl.gov>

Richard Smith wrote:
> On 5/3/06, Ronald G Minnich <rminnich at lanl.gov> wrote:
> 
>> That said, on OLPC, we're going to try again. In fact I'm gearing up to
>> try putting some gcc code into linux and loading linux direct from
>> romcc-based code. I think it might work.
> 
> 
> So that may be true in the (near) future but its not true now and may
> not ever be true for a lot of motherboards.

maybe. But that can be said in general about linuxbios :-)

> Perhaps then just a more detailed description that covers both where
> it is and the ultimate goal?

it's a phantasm in my brain at present.

ron



From stepan at coresystems.de  Thu May  4 00:33:16 2006
From: stepan at coresystems.de (Stefan Reinauer)
Date: Thu, 4 May 2006 00:33:16 +0200
Subject: [LinuxBIOS] [FEATURE] payload compression
In-Reply-To: <6F7DA19D05F3CF40B890C7CA2DB13A4203094C3C@ssvlexmb2.amd.com>
References: <6F7DA19D05F3CF40B890C7CA2DB13A4203094C3C@ssvlexmb2.amd.com>
Message-ID: <20060503223316.GA26396@coresystems.de>

* Lu, Yinghai <yinghai.lu at amd.com> [060503 23:34]:
> The Etherboot 5.4 later has different size in elf prefix... to real file
> size.
 
So Etherboot produces corrupt ELF files per default? Can we fix this in
Etherboot?

> So we need to align rom_end to 16 bytes or use dd to make payload to 16
> bytes align before nrv2b payload.nrv2b...

Hm - whatever produces the smaller or cleaner patch..

-- 
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 ward at gnu.org  Thu May  4 00:39:08 2006
From: ward at gnu.org (Ward Vandewege)
Date: Wed, 3 May 2006 18:39:08 -0400
Subject: [LinuxBIOS] s2881 build broken
Message-ID: <20060503223908.GA16539@localdomain>

Hi all,

It seems that revision 2288 broke something in the tyan/s2881 build; 2289 and
2290 are also bad. 2287 is ok.

Boot log attached; it just keeps rebooting after the 'Jumping to LinuxBIOS'
line. This is gcc 3.4.

Suggestions?

Thanks,
Ward.

-- 
Ward Vandewege <ward at fsf.org>
Free Software Foundation - Senior System Administrator
-------------- next part --------------
A non-text attachment was scrubbed...
Name: bootlog-2288.cap.gz
Type: application/octet-stream
Size: 605 bytes
Desc: not available
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20060503/e47b0a91/attachment.obj>

From stepan at coresystems.de  Thu May  4 00:44:13 2006
From: stepan at coresystems.de (Stefan Reinauer)
Date: Thu, 4 May 2006 00:44:13 +0200
Subject: [LinuxBIOS] [FEATURE] payload compression
In-Reply-To: <6F7DA19D05F3CF40B890C7CA2DB13A4203094C3A@ssvlexmb2.amd.com>
References: <6F7DA19D05F3CF40B890C7CA2DB13A4203094C3A@ssvlexmb2.amd.com>
Message-ID: <20060503224413.GA26790@coresystems.de>

* Lu, Yinghai <yinghai.lu at amd.com> [060503 20:40]:
> Please check the attached zrom fix up.
> 1. copy_and_run.c double skip length
> 2. merge zrom_stream.c into rom_stream.c
> 3. ram position check to skip 0xa0000, and 0xf0000...

I suggest you drop the following from the patch:

+#if ENDIAN == 0 && BITSIZE == 8
+#define GETBIT(bb, src, ilen) GETBIT_8(bb, src, ilen)
+#endif
+#if ENDIAN == 0 && BITSIZE == 16
+#define GETBIT(bb, src, ilen) GETBIT_LE16(bb, src, ilen)
+#endif
+#if ENDIAN == 0 && BITSIZE == 32
+#define GETBIT(bb, src, ilen) GETBIT_LE32(bb, src, ilen)
+#endif

The algorithm does not work with anything than 32bit and little endian
anyways as it is written down.

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 stepan at coresystems.de  Thu May  4 01:05:01 2006
From: stepan at coresystems.de (Stefan Reinauer)
Date: Thu, 4 May 2006 01:05:01 +0200
Subject: [LinuxBIOS] Error in FSF high priority list LinuxBIOS
	description
In-Reply-To: <6F7DA19D05F3CF40B890C7CA2DB13A4203094C39@ssvlexmb2.amd.com>
References: <6F7DA19D05F3CF40B890C7CA2DB13A4203094C39@ssvlexmb2.amd.com>
Message-ID: <20060503230501.GB26790@coresystems.de>

* Lu, Yinghai <yinghai.lu at amd.com> [060503 18:28]:
> 1. So the kernel need to know Hypertransport HT scan.
> 2. Also we need to move silicon bug fix code to kernel driver..., or
> cache_as_ram stage code...
> 
> YH
 
All in all I like the fact that we take this kind of stuff out of "the
kernel", and have it seperately. I agree that the line that is drawn by
the proprietary BIOS that makes up the interface today is less than 
optimal. 

On the other hand, Linux is really complex already and for me small
parallel and understandable systems are worth a lot more than creating
an egg-laying wool-milk-pig (heck, is there something like this in
english? all-in-one device suitable for every purpose..)

The linuxbios <--> payload determination is a really good one. For one 
real reason: I take the same kernel that works with legacy bios and I
put it into flash given thats big enough. 

When I am going to flash LinuxBIOS, I know that I will not have to look
at much more than the ~ 200,000 lines of LinuxBIOS code (wc -l on all
files, including documentation).

The idea that we want to or should cope with the several millions of
Linux code in the very same code is very ambitious. And scares me a bit,
thinking of the mess I had with MILO. 

Stefan

> -----Original Message-----
> From: Ronald G Minnich [mailto:rminnich at lanl.gov] 
> Sent: Wednesday, May 03, 2006 9:14 AM
> To: Lu, Yinghai
> Cc: Richard Smith; LinuxBIOS
> Subject: Re: [LinuxBIOS] Error in FSF high priority list LinuxBIOS
> description
> 
> Lu, Yinghai wrote:
> > You don't need linuxbios_ram part to scan pci and allocate resource
> for
> > PCI devices? Or let kernel to do these allocation?
> 
> I want to find out how to let the kernel do it. It's almost capable. 
> This was our goal, 6 years ago; maybe the kernel is ready.
> 
> ron
> 
> 
> 
> -- 
> linuxbios mailing list
> linuxbios at linuxbios.org
> http://www.openbios.org/mailman/listinfo/linuxbios
> 
-- 
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 mdc at etherboot.org  Thu May  4 01:03:19 2006
From: mdc at etherboot.org (Marty Connor)
Date: Wed, 3 May 2006 19:03:19 -0400
Subject: [LinuxBIOS] [Etherboot-discuss] Re: [FEATURE] payload
	compression
In-Reply-To: <20060503223316.GA26396@coresystems.de>
References: <6F7DA19D05F3CF40B890C7CA2DB13A4203094C3C@ssvlexmb2.amd.com>
	<20060503223316.GA26396@coresystems.de>
Message-ID: <E604F690-ABBF-4CE3-B56E-78C725066F22@etherboot.org>

On May 3, 2006, at 6:33 PM, Stefan Reinauer wrote:
> * Lu, Yinghai <yinghai.lu at amd.com> [060503 23:34]:
>> The Etherboot 5.4 later has different size in elf prefix... to  
>> real file
>> size.
> So Etherboot produces corrupt ELF files per default? Can we fix  
> this in
> Etherboot?
>> So we need to align rom_end to 16 bytes or use dd to make payload  
>> to 16
>> bytes align before nrv2b payload.nrv2b...
> Hm - whatever produces the smaller or cleaner patch..

Hello,

We will be happy to fix this.  Can you be more specific about what is  
wrong with the elf prefix that Etherboot is creating?  Better yet, if  
you could download an Etherboot-5.4.2 tarball from:

     http://prdownloads.sourceforge.net/etherboot/ 
etherboot-5.4.2.tar.gz?download

  and look at:

     etherboot-5.4.2/src/arch/i386/prefix/elfprefix/elfprefix.S

it might shed some light on the problem.

Thanks,

Marty

-- 
     Try: http://rom-o-matic.net/ to make Etherboot images instantly.

    Name: Marty Connor
US Mail: Entity Cyber, Inc.; P.O. Box 391827;
          Cambridge, MA 02139; USA
     Tel: +1 617 491 6935
   Email: mdc at etherboot.org
     Web: http://www.etherboot.org/





From stepan at coresystems.de  Thu May  4 01:12:08 2006
From: stepan at coresystems.de (Stefan Reinauer)
Date: Thu, 4 May 2006 01:12:08 +0200
Subject: [LinuxBIOS] s2881 build broken
In-Reply-To: <20060503223908.GA16539@localdomain>
References: <20060503223908.GA16539@localdomain>
Message-ID: <20060503231208.GA28727@coresystems.de>

* Ward Vandewege <ward at gnu.org> [060504 00:39]:
> Hi all,
> 
> It seems that revision 2288 broke something in the tyan/s2881 build; 2289 and
> 2290 are also bad. 2287 is ok.
> 
> Boot log attached; it just keeps rebooting after the 'Jumping to LinuxBIOS'
> line. This is gcc 3.4.
> 
> Suggestions?

Yes, I suggest I owe you a beer next time we meet and you try 2291.

Yinghai Lu has sent a patch that is more complete but also more
intrusive, which will go in later I guess. Until then this should work
fine.

This one is a good reason for automated testing on hardware.. 8)

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  Thu May  4 01:19:36 2006
From: yinghai.lu at amd.com (Lu, Yinghai)
Date: Wed, 3 May 2006 16:19:36 -0700
Subject: [LinuxBIOS] [Etherboot-discuss] Re: [FEATURE] payload
 compression
Message-ID: <6F7DA19D05F3CF40B890C7CA2DB13A4203094C3D@ssvlexmb2.amd.com>

In arch/i386/core/Etherboot.prefix.lds
_veratim_end is 16 byte align, So _verbatim_size is 16 byte align.

And in  arch/i386/prefix/elf/prefix.S, phdr2_p_filesz is set to
_verbatim_size...

But final tg3.elf size is not 16 byte align...

So I have to use "dd s=16 conv=sync " to make the image more big several
bytes to 16 byte align...

YH







From yinghai.lu at amd.com  Thu May  4 01:24:23 2006
From: yinghai.lu at amd.com (Lu, Yinghai)
Date: Wed, 3 May 2006 16:24:23 -0700
Subject: [LinuxBIOS] [FEATURE] payload compression
Message-ID: <6F7DA19D05F3CF40B890C7CA2DB13A4203094C3E@ssvlexmb2.amd.com>

Just want to keep it consistent with util/nrv2b/nrv2b.c

YH

-----Original Message-----
From: Stefan Reinauer [mailto:stepan at coresystems.de] 
Sent: Wednesday, May 03, 2006 3:44 PM
To: Lu, Yinghai
Cc: linuxbios at linuxbios.org
Subject: Re: [LinuxBIOS] [FEATURE] payload compression

* Lu, Yinghai <yinghai.lu at amd.com> [060503 20:40]:
> Please check the attached zrom fix up.
> 1. copy_and_run.c double skip length
> 2. merge zrom_stream.c into rom_stream.c
> 3. ram position check to skip 0xa0000, and 0xf0000...

I suggest you drop the following from the patch:

+#if ENDIAN == 0 && BITSIZE == 8
+#define GETBIT(bb, src, ilen) GETBIT_8(bb, src, ilen)
+#endif
+#if ENDIAN == 0 && BITSIZE == 16
+#define GETBIT(bb, src, ilen) GETBIT_LE16(bb, src, ilen)
+#endif
+#if ENDIAN == 0 && BITSIZE == 32
+#define GETBIT(bb, src, ilen) GETBIT_LE32(bb, src, ilen)
+#endif

The algorithm does not work with anything than 32bit and little endian
anyways as it is written down.

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  Thu May  4 01:27:33 2006
From: yinghai.lu at amd.com (Lu, Yinghai)
Date: Wed, 3 May 2006 16:27:33 -0700
Subject: [LinuxBIOS] s2881 build broken
Message-ID: <6F7DA19D05F3CF40B890C7CA2DB13A4203094C3F@ssvlexmb2.amd.com>

That should be double skip length problem..., remove one +4 in
copy_and_run.c could make it work.

YH

-----Original Message-----
From: linuxbios-bounces at linuxbios.org
[mailto:linuxbios-bounces at linuxbios.org] On Behalf Of Stefan Reinauer
Sent: Wednesday, May 03, 2006 4:12 PM
To: Ward Vandewege
Cc: linuxbios at linuxbios.org
Subject: Re: [LinuxBIOS] s2881 build broken

* Ward Vandewege <ward at gnu.org> [060504 00:39]:
> Hi all,
> 
> It seems that revision 2288 broke something in the tyan/s2881 build;
2289 and
> 2290 are also bad. 2287 is ok.
> 
> Boot log attached; it just keeps rebooting after the 'Jumping to
LinuxBIOS'
> line. This is gcc 3.4.
> 
> Suggestions?

Yes, I suggest I owe you a beer next time we meet and you try 2291.

Yinghai Lu has sent a patch that is more complete but also more
intrusive, which will go in later I guess. Until then this should work
fine.

This one is a good reason for automated testing on hardware.. 8)

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




From rminnich at lanl.gov  Thu May  4 01:59:39 2006
From: rminnich at lanl.gov (Ronald G Minnich)
Date: Wed, 03 May 2006 17:59:39 -0600
Subject: [LinuxBIOS] s2881 build broken
In-Reply-To: <6F7DA19D05F3CF40B890C7CA2DB13A4203094C3F@ssvlexmb2.amd.com>
References: <6F7DA19D05F3CF40B890C7CA2DB13A4203094C3F@ssvlexmb2.amd.com>
Message-ID: <445943EB.9010503@lanl.gov>

Lu, Yinghai wrote:
> That should be double skip length problem..., remove one +4 in
> copy_and_run.c could make it work.
> 
> YH
> 
> -----Original Message-----
> From: linuxbios-bounces at linuxbios.org
> [mailto:linuxbios-bounces at linuxbios.org] On Behalf Of Stefan Reinauer
> Sent: Wednesday, May 03, 2006 4:12 PM
> To: Ward Vandewege
> Cc: linuxbios at linuxbios.org
> Subject: Re: [LinuxBIOS] s2881 build broken
> 
> * Ward Vandewege <ward at gnu.org> [060504 00:39]:
> 
>>Hi all,
>>
>>It seems that revision 2288 broke something in the tyan/s2881 build;
> 
> 2289 and
> 
>>2290 are also bad. 2287 is ok.
>>
>>Boot log attached; it just keeps rebooting after the 'Jumping to
> 
> LinuxBIOS'
> 
>>line. This is gcc 3.4.
>>
>>Suggestions?
> 
> 
> Yes, I suggest I owe you a beer next time we meet and you try 2291.
> 
> Yinghai Lu has sent a patch that is more complete but also more
> intrusive, which will go in later I guess. Until then this should work
> fine.
> 
> This one is a good reason for automated testing on hardware.. 8)
> 
> Stefan
> 

hey guys, sorry but I'm lost. did the compress patch bust Ward's 
linuxbios? Why would that happen? Did the behaviour default to 'new 
feetchur enabled'?

ron



From rminnich at lanl.gov  Thu May  4 02:00:41 2006
From: rminnich at lanl.gov (Ronald G Minnich)
Date: Wed, 03 May 2006 18:00:41 -0600
Subject: [LinuxBIOS] Error in FSF high priority list LinuxBIOS
	description
In-Reply-To: <20060503230501.GB26790@coresystems.de>
References: <6F7DA19D05F3CF40B890C7CA2DB13A4203094C39@ssvlexmb2.amd.com>
	<20060503230501.GB26790@coresystems.de>
Message-ID: <44594429.1030309@lanl.gov>

Stefan Reinauer wrote:

> On the other hand, Linux is really complex already and for me small
> parallel and understandable systems are worth a lot more than creating
> an egg-laying wool-milk-pig (heck, is there something like this in
> english? all-in-one device suitable for every purpose..)

ok you win.

I won't do it :-)

ron



From ward at gnu.org  Thu May  4 02:10:13 2006
From: ward at gnu.org (Ward Vandewege)
Date: Wed, 3 May 2006 20:10:13 -0400
Subject: [LinuxBIOS] s2881 build broken
In-Reply-To: <20060503231208.GA28727@coresystems.de>
References: <20060503223908.GA16539@localdomain>
	<20060503231208.GA28727@coresystems.de>
Message-ID: <20060504001013.GB3723@localdomain>

On Thu, May 04, 2006 at 01:12:08AM +0200, Stefan Reinauer wrote:
> * Ward Vandewege <ward at gnu.org> [060504 00:39]:
> > Hi all,
> > 
> > It seems that revision 2288 broke something in the tyan/s2881 build; 2289 and
> > 2290 are also bad. 2287 is ok.
> > 
> > Boot log attached; it just keeps rebooting after the 'Jumping to LinuxBIOS'
> > line. This is gcc 3.4.
> > 
> > Suggestions?
> 
> Yes, I suggest I owe you a beer next time we meet and you try 2291.

:) all right, will do so on Friday; not in the office tomorrow. I'll put a
note on the s2881 build page that 2288 through 2290 are known bad.

> Yinghai Lu has sent a patch that is more complete but also more
> intrusive, which will go in later I guess. Until then this should work
> fine.
> 
> This one is a good reason for automated testing on hardware.. 8)

Yes. I was thinking about that today while trying different revisions to see
which one was the culprit. Would there be an easier way to do automated
testing than having lots of boxes with some sort of software switchable
BIOSsavior (actually, that would be a nice thing to have in any case)?
Emulation, perhaps?

Ward.

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



From yinghai.lu at amd.com  Thu May  4 03:06:04 2006
From: yinghai.lu at amd.com (Lu, Yinghai)
Date: Wed, 3 May 2006 18:06:04 -0700
Subject: [LinuxBIOS] s2881 build broken
Message-ID: <6F7DA19D05F3CF40B890C7CA2DB13A4203094C44@ssvlexmb2.amd.com>

I commit the fix up, please check it...

Thanks

Yinghai Lu

-----Original Message-----
From: linuxbios-bounces at linuxbios.org
[mailto:linuxbios-bounces at linuxbios.org] On Behalf Of Ward Vandewege
Sent: Wednesday, May 03, 2006 5:10 PM
To: Stefan Reinauer
Cc: linuxbios at linuxbios.org
Subject: Re: [LinuxBIOS] s2881 build broken

On Thu, May 04, 2006 at 01:12:08AM +0200, Stefan Reinauer wrote:
> * Ward Vandewege <ward at gnu.org> [060504 00:39]:
> > Hi all,
> > 
> > It seems that revision 2288 broke something in the tyan/s2881 build;
2289 and
> > 2290 are also bad. 2287 is ok.
> > 
> > Boot log attached; it just keeps rebooting after the 'Jumping to
LinuxBIOS'
> > line. This is gcc 3.4.
> > 
> > Suggestions?
> 
> Yes, I suggest I owe you a beer next time we meet and you try 2291.

:) all right, will do so on Friday; not in the office tomorrow. I'll put
a
note on the s2881 build page that 2288 through 2290 are known bad.

> Yinghai Lu has sent a patch that is more complete but also more
> intrusive, which will go in later I guess. Until then this should work
> fine.
> 
> This one is a good reason for automated testing on hardware.. 8)

Yes. I was thinking about that today while trying different revisions to
see
which one was the culprit. Would there be an easier way to do automated
testing than having lots of boxes with some sort of software switchable
BIOSsavior (actually, that would be a nice thing to have in any case)?
Emulation, perhaps?

Ward.

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

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





From russ at ashlandhome.net  Thu May  4 03:21:59 2006
From: russ at ashlandhome.net (Russell Whitaker)
Date: Wed, 3 May 2006 18:21:59 -0700 (PDT)
Subject: [LinuxBIOS] MB1030 / 3036 VGA comes up :D
In-Reply-To: <44589F4B.7070202@suehsi.de>
References: <8a0c36780605010706m2bed1a6eja546e5b941f46c1a@mail.gmail.com>
	<445652FA.7030009@suehsi.de>
	<8a0c36780605011133l5be7d2e8sbf8fa875824ffe8a@mail.gmail.com>
	<44566EC7.4090104@suehsi.de>
	<8a0c36780605011254i2edfa710h5ba481b7ae0a6093@mail.gmail.com>
	<44573C06.5030709@suehsi.de>
	<8a0c36780605020721v279f153ev7da4dc3ebb2d42d@mail.gmail.com>
	<44578A8E.9060608@suehsi.de> <20060502191652.GB4620@coresystems.de>
	<44587215.6010507@suehsi.de> <20060503094725.GA9317@coresystems.de>
	<44589F4B.7070202@suehsi.de>
Message-ID: <Pine.LNX.4.63.0605031817570.2406@bigred.russwhit.org>



On Wed, 3 May 2006, Christian S??hs wrote:

>
>>>> - the 90s delay during VGA init.
>>>> - anything else?
>>> 
>>> copying LB to RAM seems to be very slow ?!
>
> takes about 3 - 4 seconds for the 256k image
>
>>> after boot, uncompressing the kernel is much slower as under factory bios.
>> 
>
>> How many megabytes in how many seconds? is it compressed?
>
> Its done in 8 - 9 seconds. kernel is 700k big.
> Well, it is a bzImage and should be compressed.
>> 
>> 
>>> The filesystem is for any reason readonly after a boot?!
>>> Not under factory.
>>
>>  readonly root filesystem is the default. Maybe the boot parameters of
>> your "other" boot loader contain "rw" ?
>
> Waaaah, yeah I have forgotten to insert "rw" parameter for the commandline in 
> filo.
>
in linux, the root is first mounted read only. the boot process does a 
file system check and if no errors then remounts rw.

   russ

From chris at suehsi.de  Thu May  4 10:53:18 2006
From: chris at suehsi.de (=?ISO-8859-1?Q?Christian_S=FChs?=)
Date: Thu, 04 May 2006 10:53:18 +0200
Subject: [LinuxBIOS] MB1030 / 3036 VGA resume
In-Reply-To: <4458D0C3.7020308@lanl.gov>
References: <8a0c36780605011259p721fb330j4d640fc17857cae8@mail.gmail.com>	<445733D0.6050004@suehsi.de>	<44575B60.7050406@suehsi.de>	<8a0c36780605020731w7d9d7048g524d640b4d3ed665@mail.gmail.com>	<44578BAB.80008@suehsi.de>	<44579320.90206@suehsi.de>	<8a0c36780605020925h6110f2d8pa656fde32cc5adfb@mail.gmail.com>	<4457ADD6.8020608@suehsi.de>	<20060502192823.GC4620@coresystems.de>	<4457CB2A.4030908@suehsi.de>	<20060502205654.GB11460@coresystems.de>	<44586CDF.2060809@suehsi.de>
	<4458D0C3.7020308@lanl.gov>
Message-ID: <4459C0FE.6070104@suehsi.de>

Ok,

with your help, currently I get almost the same bootloog as under 
factory bios.
The main initializing of the board, seems to be ok.

But you know, that there are two big problems for me and the board.

First:

The whole boottime is slow.
Lb is 15s slower as the factory bios in kernel booting.

1. copying LB to RAM seems slow.
2. copying kernel and intitrd.gz to RAM seems slow
3. uncompressing kernel seems slow.

All operations to or in RAM seems to be 3 times slower as under factory.


Second:
VGA initialization is very very slow ;)




I have compared all register settings for the CPU with the datasheet. 
For me the settings are ok. The RAM is detected right. CPU is set with 
the right values.

The only thing I can't see, are the settings for the refresh cycles and 
clock stuff for the RAM?! I will try to debug these settings.

Richard, Ron and Stefan means, that there are problems with the caching 
stuff.

However, currently I think there is a problem with the internal X-Bus or 
Memory refresh settings.

I hope somebody have an answer for this problems.

Also there is one last question for me.
lspci shows no interrupts for the vga and usb device, both are set to 0.
How can I set them. I this done with the irq_table?

chris



From stepan at coresystems.de  Thu May  4 11:33:38 2006
From: stepan at coresystems.de (Stefan Reinauer)
Date: Thu, 4 May 2006 11:33:38 +0200
Subject: [LinuxBIOS] s2881 build broken
In-Reply-To: <445943EB.9010503@lanl.gov>
References: <6F7DA19D05F3CF40B890C7CA2DB13A4203094C3F@ssvlexmb2.amd.com>
	<445943EB.9010503@lanl.gov>
Message-ID: <20060504093337.GA7133@coresystems.de>

* Ronald G Minnich <rminnich at lanl.gov> [060504 01:59]:
> hey guys, sorry but I'm lost. did the compress patch bust Ward's 
> linuxbios? Why would that happen? Did the behaviour default to 'new 
> feetchur enabled'?

It was indirectly connected to the new feature. Since we're using the
same compression algorithm as we use for CONFIG_COMPRESS I switched
things so that they share code - 
... and tested on a system with CONFIG_COMPRESS disabled.

The bug was that nrv2b puts the length of the decompressed file in the
first 4 bytes of the result file. unrv2b() skips those. And so does
copy_and_run.c in the assembler part which I missed.

I fixed it in 2291 though.

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 stepan at coresystems.de  Thu May  4 11:35:02 2006
From: stepan at coresystems.de (Stefan Reinauer)
Date: Thu, 4 May 2006 11:35:02 +0200
Subject: [LinuxBIOS] s2881 build broken
In-Reply-To: <20060504001013.GB3723@localdomain>
References: <20060503223908.GA16539@localdomain>
	<20060503231208.GA28727@coresystems.de>
	<20060504001013.GB3723@localdomain>
Message-ID: <20060504093502.GB7133@coresystems.de>

* Ward Vandewege <ward at gnu.org> [060504 02:10]:
> > This one is a good reason for automated testing on hardware.. 8)
> 
> Yes. I was thinking about that today while trying different revisions to see
> which one was the culprit. Would there be an easier way to do automated
> testing than having lots of boxes with some sort of software switchable
> BIOSsavior (actually, that would be a nice thing to have in any case)?
> Emulation, perhaps?

It will come.

-- 
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 mdc at etherboot.org  Thu May  4 01:03:19 2006
From: mdc at etherboot.org (Marty Connor)
Date: Wed, 3 May 2006 19:03:19 -0400
Subject: [LinuxBIOS] [Etherboot-discuss] Re: [FEATURE] payload
	compression
In-Reply-To: <20060503223316.GA26396@coresystems.de>
References: <6F7DA19D05F3CF40B890C7CA2DB13A4203094C3C@ssvlexmb2.amd.com>
	<20060503223316.GA26396@coresystems.de>
Message-ID: <E604F690-ABBF-4CE3-B56E-78C725066F22@etherboot.org>

On May 3, 2006, at 6:33 PM, Stefan Reinauer wrote:
> * Lu, Yinghai <yinghai.lu at amd.com> [060503 23:34]:
>> The Etherboot 5.4 later has different size in elf prefix... to  
>> real file
>> size.
> So Etherboot produces corrupt ELF files per default? Can we fix  
> this in
> Etherboot?
>> So we need to align rom_end to 16 bytes or use dd to make payload  
>> to 16
>> bytes align before nrv2b payload.nrv2b...
> Hm - whatever produces the smaller or cleaner patch..

Hello,

We will be happy to fix this.  Can you be more specific about what is  
wrong with the elf prefix that Etherboot is creating?  Better yet, if  
you could download an Etherboot-5.4.2 tarball from:

     http://prdownloads.sourceforge.net/etherboot/ 
etherboot-5.4.2.tar.gz?download

  and look at:

     etherboot-5.4.2/src/arch/i386/prefix/elfprefix/elfprefix.S

it might shed some light on the problem.

Thanks,

Marty

-- 
     Try: http://rom-o-matic.net/ to make Etherboot images instantly.

    Name: Marty Connor
US Mail: Entity Cyber, Inc.; P.O. Box 391827;
          Cambridge, MA 02139; USA
     Tel: +1 617 491 6935
   Email: mdc at etherboot.org
     Web: http://www.etherboot.org/




-------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
_______________________________________________
Etherboot-discuss mailing list
Etherboot-discuss at lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/etherboot-discuss



From stepan at coresystems.de  Thu May  4 12:13:48 2006
From: stepan at coresystems.de (Stefan Reinauer)
Date: Thu, 4 May 2006 12:13:48 +0200
Subject: [LinuxBIOS] s2881 build broken
In-Reply-To: <6F7DA19D05F3CF40B890C7CA2DB13A4203094C44@ssvlexmb2.amd.com>
References: <6F7DA19D05F3CF40B890C7CA2DB13A4203094C44@ssvlexmb2.amd.com>
Message-ID: <20060504101348.GA10472@coresystems.de>

* Lu, Yinghai <yinghai.lu at amd.com> [060504 03:06]:
> I commit the fix up, please check it...
> 
> Thanks

Hey Yinghai!

Congratulations, after I broke operation, you broke compilation of the
complete tree ;-)) 

   http://snapshots.linuxbios.org/stats/abuild-LinuxBIOSv2-2292.log

I fixed this in r2296 again.


For everyone who is doing checkins, as every one of us makes this
mistake one time or the other:

Please

  - DO RUN abuild.sh BEFORE CHECKING IN! This will find the most stupid
    typos.

  - If you change something in the cpu/amd/ tree that breaks compilation
    of the rest, do change it in the cpu/x86 part as well.

  - Please check http://snapshots.linuxbios.org/ after checking in,
    whether your checkin is correct and flawless.

  - If you make a commit, and it breaks compilation of _any_ mainboard
    that you are not explicitly working on _at the moment_, fix it
    within 2h. If this is not possible, revert the patch. 
    We might also set up a script that enforces this revertion, if
    people feel this helps.

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 chris at suehsi.de  Thu May  4 14:09:25 2006
From: chris at suehsi.de (=?ISO-8859-1?Q?Christian_S=FChs?=)
Date: Thu, 04 May 2006 14:09:25 +0200
Subject: [LinuxBIOS] MB1030 / 3036 VGA resume
In-Reply-To: <4459C0FE.6070104@suehsi.de>
References: <8a0c36780605011259p721fb330j4d640fc17857cae8@mail.gmail.com>	<445733D0.6050004@suehsi.de>	<44575B60.7050406@suehsi.de>	<8a0c36780605020731w7d9d7048g524d640b4d3ed665@mail.gmail.com>	<44578BAB.80008@suehsi.de>	<44579320.90206@suehsi.de>	<8a0c36780605020925h6110f2d8pa656fde32cc5adfb@mail.gmail.com>	<4457ADD6.8020608@suehsi.de>	<20060502192823.GC4620@coresystems.de>	<4457CB2A.4030908@suehsi.de>	<20060502205654.GB11460@coresystems.de>	<44586CDF.2060809@suehsi.de>	<4458D0C3.7020308@lanl.gov>
	<4459C0FE.6070104@suehsi.de>
Message-ID: <4459EEF5.3070509@suehsi.de>


> 
> However, currently I think there is a problem with the internal X-Bus or 
> Memory refresh settings.
> 

detected memory seetings are also ok.

chris




From stepan at coresystems.de  Thu May  4 12:58:24 2006
From: stepan at coresystems.de (Stefan Reinauer)
Date: Thu, 4 May 2006 12:58:24 +0200
Subject: [LinuxBIOS] MB1030 / 3036 VGA resume
In-Reply-To: <4459EEF5.3070509@suehsi.de>
References: <44579320.90206@suehsi.de>
	<8a0c36780605020925h6110f2d8pa656fde32cc5adfb@mail.gmail.com>
	<4457ADD6.8020608@suehsi.de> <20060502192823.GC4620@coresystems.de>
	<4457CB2A.4030908@suehsi.de>
	<20060502205654.GB11460@coresystems.de>
	<44586CDF.2060809@suehsi.de> <4458D0C3.7020308@lanl.gov>
	<4459C0FE.6070104@suehsi.de> <4459EEF5.3070509@suehsi.de>
Message-ID: <20060504105824.GA11837@coresystems.de>

* Christian S?hs <chris at suehsi.de> [060504 14:09]:
> 
> >
> >However, currently I think there is a problem with the internal X-Bus or 
> >Memory refresh settings.
> >
> 
> detected memory seetings are also ok.

north bridge configuration is pretty much the same. 

I would check the 5530/5535 sheets for the differences below..

-// LinuxBios
+// Factory Bios

 00:00.0 0600: 1078:0001
-00: 78 10 01 00 47 01 80 83 00 00 00 06 00 00 00 00
+00: 78 10 01 00 07 00 80 02 00 00 00 06 00 00 00 00
 10: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

One of those is busmastering iirc.


wheras the "Kahlua Legacy" is very different..

 00:12.0 0601: 1078:0100
-00: 78 10 00 01 5f 01 80 02 00 00 01 06 04 40 80 00
+00: 78 10 00 01 1f 00 80 02 00 00 01 06 04 40 80 00
 10: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
 20: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
 30: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
-40: 89 10 ac 03 01 00 00 00 00 00 00 00 00 00 00 00
+40: 81 50 ce 45 01 00 00 00 00 00 00 00 00 00 00 00
-50: 7b 40 ee 00 00 00 00 00 03 00 03 38 00 00 00 00
+50: 7b 44 e8 0b 00 00 00 00 00 00 03 18 0b 0a 01 00
-60: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
+60: 40 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
 70: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
-80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
+80: 1f 00 40 00 00 00 00 00 00 00 01 08 04 32 00 00
-90: 00 0f 00 00 00 00 00 00 00 00 00 00 00 00 00 00
+90: 0c 0b 10 f0 02 04 02 00 04 00 04 00 04 00 02 00
-a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
+a0: 00 00 00 00 00 00 00 00 00 00 00 00 04 00 00 00
-b0: 00 00 00 00 0c 00 00 00 fd 4a e9 12 00 00 00 00
+b0: 00 00 00 00 0c 00 00 00 40 11 9c 12 00 00 00 00
-c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
+c0: 00 00 00 00 00 00 00 00 a0 00 00 00 00 00 40 00
 d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
 e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
 f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

So is the SMI configuration:

 00:12.2 0101: 1078:0102
 00: 78 10 02 01 05 00 80 02 00 80 01 01 00 00 00 00
 10: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
-20: 01 10 00 00 00 00 00 00 00 00 00 00 00 00 00 00
+20: 01 f0 00 00 00 00 00 00 00 00 00 00 00 00 00 00
 30: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
 40: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
-50: 7b 40 ee 00 00 00 00 00 03 00 03 38 00 00 00 00
+50: 7b 44 e8 0b 00 00 00 00 00 00 03 18 0b 0a 01 00
-60: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
+60: 40 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
 70: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
-80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
+80: 1f 00 40 00 00 00 00 00 00 00 01 08 04 32 00 00
-90: 00 0f 00 00 00 00 00 00 00 00 00 00 00 00 00 00
+90: 0c 0b 10 f0 02 04 02 00 04 00 04 00 04 00 02 00
-a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
+a0: 00 00 00 00 00 00 00 00 00 00 00 00 04 00 00 00
-b0: 00 00 00 00 0c 00 00 00 ff 28 00 12 00 00 00 00
+b0: 00 00 00 00 0c 00 00 00 42 04 12 12 00 00 00 00
-c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
+c0: 00 00 00 00 00 00 00 00 a0 00 00 00 00 00 40 00
 d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00



-- 
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 yinghailu at gmail.com  Thu May  4 13:12:42 2006
From: yinghailu at gmail.com (yhlu)
Date: Thu, 4 May 2006 04:12:42 -0700
Subject: [LinuxBIOS] s2881 build broken
In-Reply-To: <20060504101348.GA10472@coresystems.de>
References: <6F7DA19D05F3CF40B890C7CA2DB13A4203094C44@ssvlexmb2.amd.com>
	<20060504101348.GA10472@coresystems.de>
Message-ID: <2ea3fae10605040412m660a4147o595f7a11166aac03@mail.gmail.com>

You revert the ilen print out?

if you nrv2b one zelf image, you will get more bigger ilen instead...

YH



From stepan at coresystems.de  Thu May  4 13:40:24 2006
From: stepan at coresystems.de (Stefan Reinauer)
Date: Thu, 4 May 2006 13:40:24 +0200
Subject: [LinuxBIOS] s2881 build broken
In-Reply-To: <2ea3fae10605040412m660a4147o595f7a11166aac03@mail.gmail.com>
References: <6F7DA19D05F3CF40B890C7CA2DB13A4203094C44@ssvlexmb2.amd.com>
	<20060504101348.GA10472@coresystems.de>
	<2ea3fae10605040412m660a4147o595f7a11166aac03@mail.gmail.com>
Message-ID: <20060504114024.GA12976@coresystems.de>

* yhlu <yinghailu at gmail.com> [060504 13:12]:
> You revert the ilen print out?
 
we could add that into the unrv2b() function, but I think we should not
change the API for debugging only.

> if you nrv2b one zelf image, you will get more bigger ilen instead...

Can we detect whether we're decompressing a zelf image and print a
message instead? or cause that the uncompressed version is used?

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 mirskid at gmail.com  Thu May  4 17:20:23 2006
From: mirskid at gmail.com (MIJAIL)
Date: Thu, 4 May 2006 10:20:23 -0500
Subject: [LinuxBIOS] WRITE FROM COLOMBIA
Message-ID: <12ab777a0605040820o2c6d0fcdmbad15ef27f59a3eb@mail.gmail.com>

HI...
SORRY BY MY ENGLISH
I WROTE TO YOU FROM BOGOTA COLOMBIA..
WE WANT TO TRY TO DO A CLUSTER WITH A LINUXBIOS....
MY QUESTION ARE:
1. WHEN I UPDATE MY MOTHERBOARD BIOS WITH LINUXBIOS (MAKE IN A FLASH BIOS)I
HAVE A RISK TO NEVER WORK AGAIN MY BOARD??
2. WHEN I UPDATE MY MOTHERBOARD BIOS WITH LINUXBIOS I NEED ALSO INTAL THE
BPROC PROGRAM??
3. IF I HAVE INSTALED DEBIAN AND I WANT INSTAL LINUXBIOS THE INFORMATION AND
SISTEM WILL BE LOST??
4. IF I HAVE MANY OLD PC'S...(LIKE PENTIUM III) WHITH PROCESOR, RAM, WITHOUT
HARD DRIVE, CAN I INSTAL LINUX BIOS??
5. HOW I TO FORM THE IP ADRESS IN THE BIOS TO MAKE THE MACHINE ABLE TO USE
IN MY LAN??

TANK VERY MUCH...
LAST QUESTION....YOU SEND ME A ANSWER TO THIS MAIL OR I NEED TO FIND IT IN
SOME WEB PAGE??

--
Mijail Valderrama Kireeva
Ingeniero de Sistemas
Tel. (571) 227 1236
Cel. 300-5705741
Bogot? - Colombia
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20060504/619f6836/attachment.html>

From yinghailu at gmail.com  Thu May  4 17:44:25 2006
From: yinghailu at gmail.com (yhlu)
Date: Thu, 4 May 2006 08:44:25 -0700
Subject: [LinuxBIOS] s2881 build broken
In-Reply-To: <20060504114024.GA12976@coresystems.de>
References: <6F7DA19D05F3CF40B890C7CA2DB13A4203094C44@ssvlexmb2.amd.com>
	<20060504101348.GA10472@coresystems.de>
	<2ea3fae10605040412m660a4147o595f7a11166aac03@mail.gmail.com>
	<20060504114024.GA12976@coresystems.de>
Message-ID: <2ea3fae10605040844k7bc03bc0x67a0303c16ccdebf@mail.gmail.com>

that will need another 4 byte header before the stream.

YH

On 5/4/06, Stefan Reinauer <stepan at coresystems.de> wrote:
> * yhlu <yinghailu at gmail.com> [060504 13:12]:
> > You revert the ilen print out?
>
> we could add that into the unrv2b() function, but I think we should not
> change the API for debugging only.
>
> > if you nrv2b one zelf image, you will get more bigger ilen instead...
>
> Can we detect whether we're decompressing a zelf image and print a
> message instead? or cause that the uncompressed version is used?
>
> 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 smithbone at gmail.com  Thu May  4 18:00:50 2006
From: smithbone at gmail.com (Richard Smith)
Date: Thu, 4 May 2006 11:00:50 -0500
Subject: [LinuxBIOS] WRITE FROM COLOMBIA
In-Reply-To: <12ab777a0605040820o2c6d0fcdmbad15ef27f59a3eb@mail.gmail.com>
References: <12ab777a0605040820o2c6d0fcdmbad15ef27f59a3eb@mail.gmail.com>
Message-ID: <8a0c36780605040900t2767d2f9vd0c6ec642332a80@mail.gmail.com>

On 5/4/06, MIJAIL <mirskid at gmail.com> wrote:
>

> HI...
> SORRY BY MY ENGLISH

Your english is fine.  Your choice of ALL UPPERCASE however could use
a bit of tweaking. *grin*

> MY QUESTION ARE:
> 1. WHEN I UPDATE MY MOTHERBOARD BIOS WITH LINUXBIOS (MAKE IN A FLASH BIOS)I
> HAVE A RISK TO NEVER WORK AGAIN MY BOARD??

Yes and no.  If the ROM chip on the board is not removeable then if
the re-program does not go well or linuxbios dosen' work then yes you
now have a brick.  If you can remove the chip then you can reprogram
back with the factory or a new version of linuxbios.

> 2. WHEN I UPDATE MY MOTHERBOARD BIOS WITH LINUXBIOS I NEED ALSO INTAL THE
> BPROC PROGRAM??

Yes. LinuxBIOS and bproc are completely different.

> 3. IF I HAVE INSTALED DEBIAN AND I WANT INSTAL LINUXBIOS THE INFORMATION AND
> SISTEM WILL BE LOST??

If you are asking if you will have to Re-install Debian then no.  But
LinuxBIOS will use a different bootloader so the boot process is
slightly different.

> 4. IF I HAVE MANY OLD PC'S...(LIKE PENTIUM III) WHITH PROCESOR, RAM, WITHOUT
> HARD DRIVE, CAN I INSTAL LINUX BIOS?

If the chipset is supported then yes.  Very few of the older chipsets
are supported.  We would need an lspci of the system to know if the
chipset is supported.

> 5. HOW I TO FORM THE IP ADRESS IN THE BIOS TO MAKE THE MACHINE ABLE TO USE
> IN MY LAN??

I think what you want is etherboot.  http://etherboot.org.  LinuxBIOS
can load etherboot as a payload.

> TANK VERY MUCH...
> LAST QUESTION....YOU SEND ME A ANSWER TO THIS MAIL OR I NEED TO FIND IT IN
> SOME WEB PAGE??

The linuxbios page,  http://linuxbios.org has lots of useful info.

--
Richard A. Smith



From eric at zyxod.com  Thu May  4 18:31:24 2006
From: eric at zyxod.com (Eric Poulsen)
Date: Thu, 04 May 2006 09:31:24 -0700
Subject: [LinuxBIOS] Epia M tree build issue
Message-ID: <445A2C5C.5050200@zyxod.com>

I know I'm beginning to sound like a broken record here, but I can't 
seem to get a definitive answer, and the build process for LB is ... 
complex.

1) Is the effect reproducible on other systems? Has anyone else tried to 
follow the same steps I have?*
2) If so, is this a "real" issue?  Or do I just badly mis-understand the 
LB build process?

* I realize that most people don't have Epia motherboards to try this 
on, but if the "right" way compiles the first time around, that'd be 
something.

---

The issue: There are two distinct ways I've attempted to build an Epia-M 
target. 

The first way I tried it was "wrong" because I didn't do a 'make clean' 
after changing config options and re-running 'builtarget'. Oddly, this 
"wrong" way resulted in a working LB install.

Later, when modifying LB itself to better support the Epia ML (NB: These 
changes have no affect on the effect seen, and everything mentioned here 
applies to a stock Epia M target), I was more careful about my build 
process, and found that building from fully cleaned ('make clean') 
target directory resulted in a LB binary that did not work.


The "wrong" way that works:

'buildtarget via/epia-m'
make
[compiles OK, but we don't have VGA options]
Edit Config.lb; add the vga options (CONFIG_CONSOLE_VGA=1, 
CONFIG_PCI_ROM_RUN=1)
'buildtarget via/epia-m'
make
[Compiles successfully -- We now have a working LB + VGA ]
[If you do a "make clean" just before the _second_ make, you'll have the 
same linking errors you see below]


The "right" way that doesn't work:

Enter the targets/via/epia-m directory
Edit Config.lb; add the vga options (CONFIG_CONSOLE_VGA=1, 
CONFIG_PCI_ROM_RUN=1)
'buildtarget via/epia-m'
make
[Linking errors -- I'd say this is where the issue first manifests itself]
Edit Config.lb again, increase ROM_IMAGE_SIZE
'buildtarget via/epia-m'
make
[Compiles successfully, but with a bad LB image -- Exception 13 during 
attempts to init VGA]




From a.borisov at tesv.tmb.ru  Thu May  4 18:39:29 2006
From: a.borisov at tesv.tmb.ru (Anton Borisov)
Date: Thu, 4 May 2006 20:39:29 +0400
Subject: [LinuxBIOS] Epia M tree build issue
In-Reply-To: <445A2C5C.5050200@zyxod.com>
References: <445A2C5C.5050200@zyxod.com>
Message-ID: <20060504203929.01f46b70.a.borisov@tesv.tmb.ru>

On Thu, 04 May 2006 09:31:24 -0700
Eric Poulsen <eric at zyxod.com> wrote:

> I know I'm beginning to sound like a broken record here, but I can't 
> seem to get a definitive answer, and the build process for LB is ... 
> complex.
> 
> 1) Is the effect reproducible on other systems? Has anyone else tried to 
> follow the same steps I have?*
> 2) If so, is this a "real" issue?  Or do I just badly mis-understand the 
> LB build process?
> 
> * I realize that most people don't have Epia motherboards to try this 
> on, but if the "right" way compiles the first time around, that'd be 
> something.

	What is your snapshot version? VGA ROM revision?


-Anton



From stepan at coresystems.de  Thu May  4 18:44:02 2006
From: stepan at coresystems.de (Stefan Reinauer)
Date: Thu, 4 May 2006 18:44:02 +0200
Subject: [LinuxBIOS] Epia M tree build issue
In-Reply-To: <445A2C5C.5050200@zyxod.com>
References: <445A2C5C.5050200@zyxod.com>
Message-ID: <20060504164401.GA26534@coresystems.de>

* Eric Poulsen <eric at zyxod.com> [060504 18:31]:
> I know I'm beginning to sound like a broken record here, but I can't 
> seem to get a definitive answer, and the build process for LB is ... 
> complex.
> 
> 1) Is the effect reproducible on other systems? Has anyone else tried to 
> follow the same steps I have?*

No, I've never seen this effect and could therefore not analyze it in
detail.

> 2) If so, is this a "real" issue?  Or do I just badly mis-understand the 
> LB build process?

If it does not work for you, it is a real issue. Then either the docs or
the code need fixing. 

> * I realize that most people don't have Epia motherboards to try this 
> on, but if the "right" way compiles the first time around, that'd be 
> something.
 
What exact version of an Epia board do you have? Maybe someone else with
the same version can comment more qualified

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 lanl.gov  Thu May  4 18:42:58 2006
From: rminnich at lanl.gov (Ronald G Minnich)
Date: Thu, 04 May 2006 10:42:58 -0600
Subject: [LinuxBIOS] Epia M tree build issue
In-Reply-To: <445A2C5C.5050200@zyxod.com>
References: <445A2C5C.5050200@zyxod.com>
Message-ID: <445A2F12.3070709@lanl.gov>

eric, it's on my list. I just have not had time to look at it. Will try 
next week on the plane. I don't know what's going on here.

ron



From eric at zyxod.com  Thu May  4 18:51:21 2006
From: eric at zyxod.com (Eric Poulsen)
Date: Thu, 04 May 2006 09:51:21 -0700
Subject: [LinuxBIOS] Epia M tree build issue
In-Reply-To: <20060504164401.GA26534@coresystems.de>
References: <445A2C5C.5050200@zyxod.com>
	<20060504164401.GA26534@coresystems.de>
Message-ID: <445A3109.9080500@zyxod.com>

Stefan Reinauer wrote:
> * Eric Poulsen <eric at zyxod.com> [060504 18:31]:
>   
>> I know I'm beginning to sound like a broken record here, but I can't 
>> seem to get a definitive answer, and the build process for LB is ... 
>> complex.
>>
>> 1) Is the effect reproducible on other systems? Has anyone else tried to 
>> follow the same steps I have?*
>>     
>
> No, I've never seen this effect and could therefore not analyze it in
> detail.
>   
Do you mean "No, I didn't try" or "I tried, but it didn't happen to me"?

>   
>> 2) If so, is this a "real" issue?  Or do I just badly mis-understand the 
>> LB build process?
>>     
>
> If it does not work for you, it is a real issue. Then either the docs or
> the code need fixing. 
>   
I can make it work, but only in a way I would consider "work around" or
"hackish".
>   
>> * I realize that most people don't have Epia motherboards to try this 
>> on, but if the "right" way compiles the first time around, that'd be 
>> something.
>>     
>  
> What exact version of an Epia board do you have? Maybe someone else with
> the same version can comment more qualified
>   
I have an Epia ML 5000 (I don't know the revision off the top of my
head), which is very similar to the M, but with less hardware.  I really
don't think the hardware is an issue.  The Epia-M tree works fine
(albeit with a delay at the beginning, which is easily removed by
disabling the firewire code), as does my modified Epia ML tree.  I've
used both the 2100 and the "newest" SVN revision without any issues,
other than the build issue I mentioned.
> Stefan
>
>   





From eric at zyxod.com  Thu May  4 18:53:10 2006
From: eric at zyxod.com (Eric Poulsen)
Date: Thu, 04 May 2006 09:53:10 -0700
Subject: [LinuxBIOS] Epia M tree build issue
In-Reply-To: <20060504203929.01f46b70.a.borisov@tesv.tmb.ru>
References: <445A2C5C.5050200@zyxod.com>
	<20060504203929.01f46b70.a.borisov@tesv.tmb.ru>
Message-ID: <445A3176.3010402@zyxod.com>

Anton Borisov wrote:
> On Thu, 04 May 2006 09:31:24 -0700
> Eric Poulsen <eric at zyxod.com> wrote:
>
>   
>> I know I'm beginning to sound like a broken record here, but I can't 
>> seem to get a definitive answer, and the build process for LB is ... 
>> complex.
>>
>> 1) Is the effect reproducible on other systems? Has anyone else tried to 
>> follow the same steps I have?*
>> 2) If so, is this a "real" issue?  Or do I just badly mis-understand the 
>> LB build process?
>>
>> * I realize that most people don't have Epia motherboards to try this 
>> on, but if the "right" way compiles the first time around, that'd be 
>> something.
>>     
>
> 	What is your snapshot version? VGA ROM revision?
>   
I've used Revisions 2100 and the newest -- this doesn't seem to matter.  
The VGA ROM version is 1.13, which I'm told (and my working LB build 
tells me) is the only version that works with LB.  The VGA rom that came 
with my system did not ever work with LB.
>
> -Anton
>
>   




From noodles at earth.li  Thu May  4 19:07:04 2006
From: noodles at earth.li (Jonathan McDowell)
Date: Thu, 4 May 2006 18:07:04 +0100
Subject: [LinuxBIOS] Epia M tree build issue
In-Reply-To: <445A2C5C.5050200@zyxod.com>
References: <445A2C5C.5050200@zyxod.com>
Message-ID: <20060504170704.GT7570@earth.li>

On Thu, May 04, 2006 at 09:31:24AM -0700, Eric Poulsen wrote:
> I know I'm beginning to sound like a broken record here, but I can't 
> seem to get a definitive answer, and the build process for LB is ... 
> complex.
> 
> 1) Is the effect reproducible on other systems? Has anyone else tried to 
> follow the same steps I have?*
> 2) If so, is this a "real" issue?  Or do I just badly mis-understand the 
> LB build process?
 
FWIW I tend to do "./buildtarget via/epia-m/Config.lb" in the targets
directory, then change to the via/epia-m/epia-m/ directory that gets
made, type "make" and it works. I have found that the build system
doesn't always take account of changes I make such that I end up
removing via/epia-m/epia-m/ and rerunning buildtarget to be sure of a
clean build.

J.

-- 
] http://www.earth.li/~noodles/ []  The problem with the gene pool is  [
]  PGP/GPG Key @ the.earth.li   []        there's no lifeguard.        [
] via keyserver, web or email.  []                                     [
] RSA: 4DC4E7FD / DSA: 5B430367 []                                     [



From chris at suehsi.de  Thu May  4 20:38:57 2006
From: chris at suehsi.de (=?UTF-8?B?Q2hyaXN0aWFuIFPDvGhz?=)
Date: Thu, 04 May 2006 20:38:57 +0200
Subject: [LinuxBIOS] Epia M tree build issue
In-Reply-To: <20060504164401.GA26534@coresystems.de>
References: <445A2C5C.5050200@zyxod.com>
	<20060504164401.GA26534@coresystems.de>
Message-ID: <445A4A41.4090906@suehsi.de>


>  
> What exact version of an Epia board do you have? Maybe someone else with
> the same version can comment more qualified
>

I could try it, but on an EPIA ME6000, which is almost the same 
hardware. Only the TV Out is missing on the M.

I think tomorrow I can test Eric's ways to get an working or non-working 
Image ;)

chris

> Stefan
> 




From rminnich at lanl.gov  Thu May  4 19:12:25 2006
From: rminnich at lanl.gov (Ronald G Minnich)
Date: Thu, 04 May 2006 11:12:25 -0600
Subject: [LinuxBIOS] Epia M tree build issue
In-Reply-To: <20060504170704.GT7570@earth.li>
References: <445A2C5C.5050200@zyxod.com> <20060504170704.GT7570@earth.li>
Message-ID: <445A35F9.1040008@lanl.gov>

Jonathan McDowell wrote:
> On Thu, May 04, 2006 at 09:31:24AM -0700, Eric Poulsen wrote:
> 
>>I know I'm beginning to sound like a broken record here, but I can't 
>>seem to get a definitive answer, and the build process for LB is ... 
>>complex.
>>
>>1) Is the effect reproducible on other systems? Has anyone else tried to 
>>follow the same steps I have?*
>>2) If so, is this a "real" issue?  Or do I just badly mis-understand the 
>>LB build process?
> 
>  
> FWIW I tend to do "./buildtarget via/epia-m/Config.lb" in the targets
> directory, then change to the via/epia-m/epia-m/ directory that gets
> made, type "make" and it works. I have found that the build system
> doesn't always take account of changes I make such that I end up
> removing via/epia-m/epia-m/ and rerunning buildtarget to be sure of a
> clean build.
> 
> J.
> 

There's no question that the dependency information is missing bits.

ron



From yinghai.lu at amd.com  Thu May  4 19:26:01 2006
From: yinghai.lu at amd.com (Lu, Yinghai)
Date: Thu, 4 May 2006 10:26:01 -0700
Subject: [LinuxBIOS] s2881 build broken
Message-ID: <6F7DA19D05F3CF40B890C7CA2DB13A4203094C4D@ssvlexmb2.amd.com>

If the compressed_stream is enabled, 
1. when build the payload.nrv2b_x, 
	if ratio <= 1, the head four byte will be "0x5a5a5a5a", and use
ori payload.
	else the head four byte will be "0xaaaaaaaa", and used
payload.nrv2b image instead.
2. when rom_steam_init is called, it will check the head signature to
decide if uncompress it, or just use it.

YH

-----Original Message-----
From: linuxbios-bounces at linuxbios.org
[mailto:linuxbios-bounces at linuxbios.org] On Behalf Of yhlu
Sent: Thursday, May 04, 2006 8:44 AM
To: Stefan Reinauer
Cc: Ward Vandewege; linuxbios at linuxbios.org
Subject: Re: [LinuxBIOS] s2881 build broken

that will need another 4 byte header before the stream.

YH

On 5/4/06, Stefan Reinauer <stepan at coresystems.de> wrote:
> * yhlu <yinghailu at gmail.com> [060504 13:12]:
> > You revert the ilen print out?
>
> we could add that into the unrv2b() function, but I think we should
not
> change the API for debugging only.
>
> > if you nrv2b one zelf image, you will get more bigger ilen
instead...
>
> Can we detect whether we're decompressing a zelf image and print a
> message instead? or cause that the uncompressed version is used?
>
> 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





From eric at zyxod.com  Thu May  4 19:29:19 2006
From: eric at zyxod.com (Eric Poulsen)
Date: Thu, 04 May 2006 10:29:19 -0700
Subject: [LinuxBIOS] Epia M tree build issue
In-Reply-To: <445A2F12.3070709@lanl.gov>
References: <445A2C5C.5050200@zyxod.com> <445A2F12.3070709@lanl.gov>
Message-ID: <445A39EF.5070204@zyxod.com>

Ron,

I appreciate that.  I've been trying different versions of GCC, all with 
the same result.

-- Eric

Ronald G Minnich wrote:
> eric, it's on my list. I just have not had time to look at it. Will 
> try next week on the plane. I don't know what's going on here.
>
> ron
>




From eric at zyxod.com  Thu May  4 19:33:50 2006
From: eric at zyxod.com (Eric Poulsen)
Date: Thu, 04 May 2006 10:33:50 -0700
Subject: [LinuxBIOS] Epia M tree build issue
In-Reply-To: <20060504170704.GT7570@earth.li>
References: <445A2C5C.5050200@zyxod.com> <20060504170704.GT7570@earth.li>
Message-ID: <445A3AFE.3060906@zyxod.com>

Jonathan McDowell wrote:
> On Thu, May 04, 2006 at 09:31:24AM -0700, Eric Poulsen wrote:
>   
>> I know I'm beginning to sound like a broken record here, but I can't 
>> seem to get a definitive answer, and the build process for LB is ... 
>> complex.
>>
>> 1) Is the effect reproducible on other systems? Has anyone else tried to 
>> follow the same steps I have?*
>> 2) If so, is this a "real" issue?  Or do I just badly mis-understand the 
>> LB build process?
>>     
>  
> FWIW I tend to do "./buildtarget via/epia-m/Config.lb" in the targets
> directory, then change to the via/epia-m/epia-m/ directory that gets
> made, type "make" and it works. I have found that the build system
> doesn't always take account of changes I make such that I end up
> removing via/epia-m/epia-m/ and rerunning buildtarget to be sure of a
> clean build.
>   

Did you add the VGA options (CONFIG_CONSOLE_VGA=1,CONFIG_PCI_ROM_RUN=1) 
to Config.lb before the buildtarget?  This is crucial to making the 
issue exhibit itself -- without these options, it compiles cleanly for 
me, as well.  After adding them, a "cleaned" target dir has linking 
errors, whereas a "dirty" target dir (make was run without these 
options) will compile cleanly.
> J.
>
>   




From noodles at earth.li  Thu May  4 19:39:31 2006
From: noodles at earth.li (Jonathan McDowell)
Date: Thu, 4 May 2006 18:39:31 +0100
Subject: [LinuxBIOS] Epia M tree build issue
In-Reply-To: <445A3AFE.3060906@zyxod.com>
References: <445A2C5C.5050200@zyxod.com> <20060504170704.GT7570@earth.li>
	<445A3AFE.3060906@zyxod.com>
Message-ID: <20060504173931.GV7570@earth.li>

On Thu, May 04, 2006 at 10:33:50AM -0700, Eric Poulsen wrote:
> Jonathan McDowell wrote:
> > On Thu, May 04, 2006 at 09:31:24AM -0700, Eric Poulsen wrote:
> >> I know I'm beginning to sound like a broken record here, but I can't 
> >> seem to get a definitive answer, and the build process for LB is ... 
> >> complex.
> >>
> >> 1) Is the effect reproducible on other systems? Has anyone else tried to 
> >> follow the same steps I have?*
> >> 2) If so, is this a "real" issue?  Or do I just badly mis-understand the 
> >> LB build process?
> >>     
> >  
> > FWIW I tend to do "./buildtarget via/epia-m/Config.lb" in the targets
> > directory, then change to the via/epia-m/epia-m/ directory that gets
> > made, type "make" and it works. I have found that the build system
> > doesn't always take account of changes I make such that I end up
> > removing via/epia-m/epia-m/ and rerunning buildtarget to be sure of a
> > clean build.
> Did you add the VGA options (CONFIG_CONSOLE_VGA=1,CONFIG_PCI_ROM_RUN=1) 
> to Config.lb before the buildtarget?  This is crucial to making the 
> issue exhibit itself -- without these options, it compiles cleanly for 
> me, as well.

Ah, right. No. Part of my interest in LinuxBIOS is proper serial console
support, so I'm not using VGA at all.

J.

-- 
] http://www.earth.li/~noodles/ []  When the DM smiles, it's already   [
]  PGP/GPG Key @ the.earth.li   []              too late.              [
] via keyserver, web or email.  []                                     [
] RSA: 4DC4E7FD / DSA: 5B430367 []                                     [



From smithbone at gmail.com  Fri May  5 01:44:31 2006
From: smithbone at gmail.com (Richard Smith)
Date: Thu, 4 May 2006 18:44:31 -0500
Subject: [LinuxBIOS] MB1030 / 3036 VGA comes up :D
In-Reply-To: <4458D60E.10709@lanl.gov>
References: <8a0c36780605011254i2edfa710h5ba481b7ae0a6093@mail.gmail.com>
	<44587215.6010507@suehsi.de> <20060503094725.GA9317@coresystems.de>
	<44589F4B.7070202@suehsi.de> <20060503111201.GA13072@coresystems.de>
	<4458AE5D.5010100@suehsi.de> <20060503123839.GA15356@coresystems.de>
	<4458C610.2050407@suehsi.de> <4458E535.6040303@suehsi.de>
	<4458D60E.10709@lanl.gov>
Message-ID: <8a0c36780605041644q52deae75ja20c3acb5f095698@mail.gmail.com>

> so the question is, is there a range descriptor hidden somewhere that is
> controlling this. There are such registers in GX2 AND SC520 AND ....
>
> it's common in this embedded stuff. What are we missing? Where are the
> docs on this chip. I can try to read them.

Anybody know if the tools on the AMD developer site can read all the
setup registers in the gx1 and dump them out?  From looking at the
data sheet a lot of the stuff we probably need to be diffing vs
factory won't show up in an lspci -xxx.

--
Richard A. Smith



From paul.collomb1 at libertysurf.fr  Fri May  5 02:55:11 2006
From: paul.collomb1 at libertysurf.fr (=?iso-8859-1?Q?paul.collomb1@libertysurf.fr?=)
Date: Fri,  5 May 2006 02:55:11 +0200
Subject: [LinuxBIOS] =?iso-8859-1?q?__Another_newbi_question_/_TYAN_TIGER_?=
	=?iso-8859-1?q?MP_S2460?=
Message-ID: <IYRP7Z$089F09F06C4A440FA3EEDC4239E05A43@aliceadsl.fr>

Thanks for your response. I do not prefer LinuxBIOS v2 than LinuxBIOS v1. I am not a 
specialist, my goal is just to work with a " LinuxBIOS moherboard compatible ", in the 
support of LinuxBIOS v1 I have only see the " S2466 " model ( for K7 ). It's almost the same 
model but is it compatible with " S2460 " ?
Thanks
--------------------------------------------------------------------------------------------------------------------------------------



From: "Lu, Yinghai" <yinghai.lu at amd.com>
To: paul.collomb1 at libertysurf.fr, "_linuxbios"
	<linuxbios at linuxbios.org>

In the LinuxBIOS V1, there is support for Tyan K7 MB.

If you want support in LinuxBIOS v2, Someone need to check northbridge/amd/amd76x and 
reformat the interface or translate to C....



-------------- ALICE HAUT DEBIT : TRIPLE PLAY A 29,95 EUR/MOIS -------------- 
D?couvrez vite ALICEBOX : avec le modem WIFI, profitez de l'ADSL, de la TELEPHONIE et en exclusivit? de la TELEVISION ! 
B?n?ficiez aussi de la hotline gratuite 24h/24 ! Soumis ? conditions. Pour en profiter cliquez ici http://abonnement.aliceadsl.fr







From chris at suehsi.de  Fri May  5 10:40:03 2006
From: chris at suehsi.de (=?ISO-8859-1?Q?Christian_S=FChs?=)
Date: Fri, 05 May 2006 10:40:03 +0200
Subject: [LinuxBIOS] MB1030 / 3036 VGA comes up :D
In-Reply-To: <8a0c36780605041644q52deae75ja20c3acb5f095698@mail.gmail.com>
References: <8a0c36780605011254i2edfa710h5ba481b7ae0a6093@mail.gmail.com>	
	<44587215.6010507@suehsi.de>
	<20060503094725.GA9317@coresystems.de>	
	<44589F4B.7070202@suehsi.de>
	<20060503111201.GA13072@coresystems.de>	
	<4458AE5D.5010100@suehsi.de>
	<20060503123839.GA15356@coresystems.de>	
	<4458C610.2050407@suehsi.de> <4458E535.6040303@suehsi.de>	
	<4458D60E.10709@lanl.gov>
	<8a0c36780605041644q52deae75ja20c3acb5f095698@mail.gmail.com>
Message-ID: <445B0F63.2040003@suehsi.de>

Richard Smith schrieb:
>> so the question is, is there a range descriptor hidden somewhere that is
>> controlling this. There are such registers in GX2 AND SC520 AND ....
>>
>> it's common in this embedded stuff. What are we missing? Where are the
>> docs on this chip. I can try to read them.
> 
> 
> Anybody know if the tools on the AMD developer site can read all the
> setup registers in the gx1 and dump them out?  From looking at the
> data sheet a lot of the stuff we probably need to be diffing vs
> factory won't show up in an lspci -xxx.
> 
> -- 
> Richard A. Smith
> 
> 


I'm not sure, did you recieve that ?

As I say. The main settings done by LB to the cpu register are ok.
There is nothing, what seems to be wrong, but look here.

>> -// LinuxBios
>> +// Factory Bios
>>
>>  00:00.0 0600: 1078:0001
>> -00: 78 10 01 00 47 01 80 83 00 00 00 06 00 00 00 00
>> +00: 78 10 01 00 07 00 80 02 00 00 00 06 00 00 00 00
> 
>        ^^^^^ ^^^^^ ^^^^^ ^^^^^ ^^^^^^^^^^^^^^^^^^^^^^^
>         VID   DID   PCI  Device   default values
> 
> PCI Command is different and Device Status differs
> 
> PCI Command (default 0007h set by factory)
> LB enables two additional functions for the PCI Command registers.
> 1. Processor checks for parity errors
> 2. SERR# enabled (is used for a special SERR driver ?!)
> 
> Device Status (default 0280h (RO) set by factory)
> If I understand that right, the differences here results of the enabled Parity Error checks.
> This register is to read out those errors and is cleard by a R/W on this register.
> 
> Check for errors means a lowered perfomance, right??
> Unfortunatly, I can't find the sections in the LB Code, were this is done.

I can't find the section, were these registers are set in LB
Later I found them too in the other devices on the bus, like 00:12.0

> 
>>
>> One of those is busmastering iirc.
>>
>>
> 
> Busmaster for the northbridge is enabled in both cases.
> 
> 
> chris
> 



From chris at suehsi.de  Fri May  5 11:49:11 2006
From: chris at suehsi.de (=?UTF-8?B?Q2hyaXN0aWFuIFPDvGhz?=)
Date: Fri, 05 May 2006 11:49:11 +0200
Subject: [LinuxBIOS] MB1030 / 3036 VGA resume
In-Reply-To: <20060504105824.GA11837@coresystems.de>
References: <44579320.90206@suehsi.de>
	<8a0c36780605020925h6110f2d8pa656fde32cc5adfb@mail.gmail.com>
	<4457ADD6.8020608@suehsi.de> <20060502192823.GC4620@coresystems.de>
	<4457CB2A.4030908@suehsi.de>
	<20060502205654.GB11460@coresystems.de>
	<44586CDF.2060809@suehsi.de> <4458D0C3.7020308@lanl.gov>
	<4459C0FE.6070104@suehsi.de> <4459EEF5.3070509@suehsi.de>
	<20060504105824.GA11837@coresystems.de>
Message-ID: <445B1F97.3000001@suehsi.de>


> 
> wheras the "Kahlua Legacy" is very different..
> 
>  00:12.0 0601: 1078:0100
> -00: 78 10 00 01 5f 01 80 02 00 00 01 06 04 40 80 00
> +00: 78 10 00 01 1f 00 80 02 00 00 01 06 04 40 80 00
                    ^^^^^

PCI Command register (default 000Fh)
Factory bios adds here Memory write and Invalidate for the 5530
LB enables additional Parity check and SERR as for the gx1.
Could be that this is done automatically, besides the settings before to 
the gx1

rest are default values

>  10: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
>  20: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
>  30: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> -40: 89 10 ac 03 01 00 00 00 00 00 00 00 00 00 00 00
> +40: 81 50 ce 45 01 00 00 00 00 00 00 00 00 00 00 00
        ^^ ^^ ^^ ^^
LB uses default for index 40 (89h)
Factory disables the PCI slave write buffer

LB uses default for index 41 (10h)
Factory enables/adds F2 IDE Configuration trap (this is a SMI thing)

42 ( default ACh) usb settings

LB uses default for index 43 (03h)
Factory disables PCI retry cycles and set a special PIN configuration bit.

rest is default

> -50: 7b 40 ee 00 00 00 00 00 03 00 03 38 00 00 00 00
> +50: 7b 44 e8 0b 00 00 00 00 00 00 03 18 0b 0a 01 00

PIT / ISA CLK / ISA ROM

> -60: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> +60: 40 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
        ^^
is reserved

>  70: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> -80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> +80: 1f 00 40 00 00 00 00 00 00 00 01 08 04 32 00 00

Power Managment Purpose/IRQ/Video/VGA timer

> -90: 00 0f 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> +90: 0c 0b 10 f0 02 04 02 00 04 00 04 00 04 00 02 00
> -a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> +a0: 00 00 00 00 00 00 00 00 00 00 00 00 04 00 00 00
> -b0: 00 00 00 00 0c 00 00 00 fd 4a e9 12 00 00 00 00
> +b0: 00 00 00 00 0c 00 00 00 40 11 9c 12 00 00 00 00

user defined Pin settings and and and

> -c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> +c0: 00 00 00 00 00 00 00 00 a0 00 00 00 00 00 40 00
>  d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
>  e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
>  f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 



From rminnich at lanl.gov  Fri May  5 15:16:15 2006
From: rminnich at lanl.gov (Ronald G Minnich)
Date: Fri, 05 May 2006 07:16:15 -0600
Subject: [LinuxBIOS] MB1030 / 3036 VGA resume
In-Reply-To: <445B1F97.3000001@suehsi.de>
References: <44579320.90206@suehsi.de>
	<8a0c36780605020925h6110f2d8pa656fde32cc5adfb@mail.gmail.com>
	<4457ADD6.8020608@suehsi.de> <20060502192823.GC4620@coresystems.de>
	<4457CB2A.4030908@suehsi.de>
	<20060502205654.GB11460@coresystems.de>
	<44586CDF.2060809@suehsi.de> <4458D0C3.7020308@lanl.gov>
	<4459C0FE.6070104@suehsi.de> <4459EEF5.3070509@suehsi.de>
	<20060504105824.GA11837@coresystems.de>
	<445B1F97.3000001@suehsi.de>
Message-ID: <445B501F.7060900@lanl.gov>

Christian S?hs wrote:
> 
>>
>> wheras the "Kahlua Legacy" is very different..
>>
>>  00:12.0 0601: 1078:0100
>> -00: 78 10 00 01 5f 01 80 02 00 00 01 06 04 40 80 00
>> +00: 78 10 00 01 1f 00 80 02 00 00 01 06 04 40 80 00
> 
>                    ^^^^^
> 
> PCI Command register (default 000Fh)
> Factory bios adds here Memory write and Invalidate for the 5530
> LB enables additional Parity check and SERR as for the gx1.
> Could be that this is done automatically, besides the settings before to 
> the gx1
> 
> rest are default values
> 
>>  10: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
>>  20: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
>>  30: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
>> -40: 89 10 ac 03 01 00 00 00 00 00 00 00 00 00 00 00
>> +40: 81 50 ce 45 01 00 00 00 00 00 00 00 00 00 00 00
> 
>        ^^ ^^ ^^ ^^
> LB uses default for index 40 (89h)
> Factory disables the PCI slave write buffer
> 
> LB uses default for index 41 (10h)
> Factory enables/adds F2 IDE Configuration trap (this is a SMI thing)

oh boy. I HOPE we don't need the SMI support just to run the IDE 
hardware! we didn't need this before on GX1.

ron



From stepan at coresystems.de  Fri May  5 15:26:40 2006
From: stepan at coresystems.de (Stefan Reinauer)
Date: Fri, 5 May 2006 15:26:40 +0200
Subject: [LinuxBIOS] MB1030 / 3036 VGA resume
In-Reply-To: <445B501F.7060900@lanl.gov>
References: <20060502192823.GC4620@coresystems.de> <4457CB2A.4030908@suehsi.de>
	<20060502205654.GB11460@coresystems.de>
	<44586CDF.2060809@suehsi.de> <4458D0C3.7020308@lanl.gov>
	<4459C0FE.6070104@suehsi.de> <4459EEF5.3070509@suehsi.de>
	<20060504105824.GA11837@coresystems.de>
	<445B1F97.3000001@suehsi.de> <445B501F.7060900@lanl.gov>
Message-ID: <20060505132640.GA1643@coresystems.de>

* Ronald G Minnich <rminnich at lanl.gov> [060505 15:16]:
> >LB uses default for index 41 (10h)
> >Factory enables/adds F2 IDE Configuration trap (this is a SMI thing)
> 
> oh boy. I HOPE we don't need the SMI support just to run the IDE 
> hardware! we didn't need this before on GX1.

I bet they use that to implement memory mapped ide flash or
something like that..

One second... Could we do bios based transparent hard disk encryption
this way? That would be kind of cool ;-))

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 lanl.gov  Fri May  5 15:31:17 2006
From: rminnich at lanl.gov (Ronald G Minnich)
Date: Fri, 05 May 2006 07:31:17 -0600
Subject: [LinuxBIOS] MB1030 / 3036 VGA resume
In-Reply-To: <20060505132640.GA1643@coresystems.de>
References: <20060502192823.GC4620@coresystems.de> <4457CB2A.4030908@suehsi.de>
	<20060502205654.GB11460@coresystems.de>
	<44586CDF.2060809@suehsi.de> <4458D0C3.7020308@lanl.gov>
	<4459C0FE.6070104@suehsi.de> <4459EEF5.3070509@suehsi.de>
	<20060504105824.GA11837@coresystems.de>
	<445B1F97.3000001@suehsi.de> <445B501F.7060900@lanl.gov>
	<20060505132640.GA1643@coresystems.de>
Message-ID: <445B53A5.7080203@lanl.gov>

Stefan Reinauer wrote:
> * Ronald G Minnich <rminnich at lanl.gov> [060505 15:16]:
> 
>>>LB uses default for index 41 (10h)
>>>Factory enables/adds F2 IDE Configuration trap (this is a SMI thing)
>>
>>oh boy. I HOPE we don't need the SMI support just to run the IDE 
>>hardware! we didn't need this before on GX1.
> 
> 
> I bet they use that to implement memory mapped ide flash or
> something like that..
> 
> One second... Could we do bios based transparent hard disk encryption
> this way? That would be kind of cool ;-))
> 
> Stefan
> 


I am told that this type of thing might go into EFI. You don't get 
direct access to your disk. Looking at the EFI docs, it seems you could 
do it ... you no longer get access to raw hardware. OW!

ron



From stepan at coresystems.de  Fri May  5 15:47:09 2006
From: stepan at coresystems.de (Stefan Reinauer)
Date: Fri, 5 May 2006 15:47:09 +0200
Subject: [LinuxBIOS] etherboot/filo + sata startup timing
In-Reply-To: <20060501155545.GA3652@io.pong.be>
References: <20060424220147.GA26709@io.pong.be> <444D4AED.3020805@lanl.gov>
	<20060424222144.GA17934@coresystems.de>
	<20060424222501.GC27028@io.pong.be>
	<20060428231617.GA28043@coresystems.de>
	<20060501155545.GA3652@io.pong.be>
Message-ID: <20060505134709.GA2422@coresystems.de>

* Ward Vandewege <ward at gnu.org> [060501 17:55]:
> Hi Stefan,
> 
> > should have working S-ATA. I have no S-ATA here so I could not test it.
> > It's the version that also comes with the GRUB user interface.
 
> Not sure what happened, but it seems we're not 100% there yet. I've attached
> a boot log, and my filo Config file. It hangs after saying 'IDE channel 2
> not found'.
> 
> I wonder if this is because it ignored (!) the AUTOBOOT_DELAY, which would
> mean the SATA drives would not be fully ready yet. This was a cold boot.

AUTOBOOT_DELAY is a different one, it waits for user interaction before
trying to start the kernel..

drive startup times could be an issue though

Could you try some things:

 * update to the latest svn revision (17 as I write this) and make sure
   you enabled the following option (which is new)

     # Add a short delay when polling status registers
     # (required on some broken SATA controllers)
     IDE_DISK_POLL_DELAY = 1

 * if that doesnt help: try whether the disk is detected as hda instead
   of hde. This might happen with the current code.

 * enable the two options: DEBUG_PCI and DEBUG_IDE in the config file.

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 stepan at coresystems.de  Fri May  5 15:50:26 2006
From: stepan at coresystems.de (Stefan Reinauer)
Date: Fri, 5 May 2006 15:50:26 +0200
Subject: [LinuxBIOS] MB1030 / 3036 VGA resume
In-Reply-To: <445B53A5.7080203@lanl.gov>
References: <20060502205654.GB11460@coresystems.de>
	<44586CDF.2060809@suehsi.de> <4458D0C3.7020308@lanl.gov>
	<4459C0FE.6070104@suehsi.de> <4459EEF5.3070509@suehsi.de>
	<20060504105824.GA11837@coresystems.de>
	<445B1F97.3000001@suehsi.de> <445B501F.7060900@lanl.gov>
	<20060505132640.GA1643@coresystems.de> <445B53A5.7080203@lanl.gov>
Message-ID: <20060505135026.GA3428@coresystems.de>

* Ronald G Minnich <rminnich at lanl.gov> [060505 15:31]:
> > One second... Could we do bios based transparent hard disk encryption
> > this way? That would be kind of cool ;-))
> > 
> > Stefan
> 
> I am told that this type of thing might go into EFI. You don't get 
> direct access to your disk. Looking at the EFI docs, it seems you could 
> do it ... you no longer get access to raw hardware. OW!

With Vanderpool and Pacifica this should be fairly easy. 

The fact that stuff like this is possible (maybe even with SMI) is not
the scary part. The scary part is we might never get control over any
piece of hardware again.

Talking about EFI, has anyone been able to get into the UEFI group as
announced on the LinuxBIOS summit last year? 

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 c-d.hailfinger.devel.2006 at gmx.net  Fri May  5 16:01:06 2006
From: c-d.hailfinger.devel.2006 at gmx.net (Carl-Daniel Hailfinger)
Date: Fri, 05 May 2006 16:01:06 +0200
Subject: [LinuxBIOS] MB1030 / 3036 VGA resume
In-Reply-To: <20060505135026.GA3428@coresystems.de>
References: <20060502205654.GB11460@coresystems.de>	<44586CDF.2060809@suehsi.de>
	<4458D0C3.7020308@lanl.gov>	<4459C0FE.6070104@suehsi.de>
	<4459EEF5.3070509@suehsi.de>	<20060504105824.GA11837@coresystems.de>	<445B1F97.3000001@suehsi.de>
	<445B501F.7060900@lanl.gov>	<20060505132640.GA1643@coresystems.de>
	<445B53A5.7080203@lanl.gov> <20060505135026.GA3428@coresystems.de>
Message-ID: <445B5AA2.1080003@gmx.net>

Stefan Reinauer schrieb:
> * Ronald G Minnich <rminnich at lanl.gov> [060505 15:31]:
> 
>>>One second... Could we do bios based transparent hard disk encryption
>>>this way? That would be kind of cool ;-))
>>>
>>I am told that this type of thing might go into EFI. You don't get 
>>direct access to your disk. Looking at the EFI docs, it seems you could 
>>do it ... you no longer get access to raw hardware. OW!
> 
> With Vanderpool and Pacifica this should be fairly easy. 
> 
> The fact that stuff like this is possible (maybe even with SMI) is not
> the scary part. The scary part is we might never get control over any
> piece of hardware again.

But LinuxBIOS would suddenly become a lot more attractive if it was the
only way to get real access to the hardware. Unless somebody decides to
run that scary software below LinuxBIOS. I believe with BIOS-embedded-in-
chipset like the Xbox has we really might be stuck.

Regards,
Carl-Daniel



From chris at suehsi.de  Fri May  5 17:34:04 2006
From: chris at suehsi.de (=?UTF-8?B?Q2hyaXN0aWFuIFPDvGhz?=)
Date: Fri, 05 May 2006 17:34:04 +0200
Subject: [LinuxBIOS] MB1030 / 3036 VGA resume
In-Reply-To: <20060505132640.GA1643@coresystems.de>
References: <20060502192823.GC4620@coresystems.de> <4457CB2A.4030908@suehsi.de>
	<20060502205654.GB11460@coresystems.de>
	<44586CDF.2060809@suehsi.de> <4458D0C3.7020308@lanl.gov>
	<4459C0FE.6070104@suehsi.de> <4459EEF5.3070509@suehsi.de>
	<20060504105824.GA11837@coresystems.de>
	<445B1F97.3000001@suehsi.de> <445B501F.7060900@lanl.gov>
	<20060505132640.GA1643@coresystems.de>
Message-ID: <445B706C.6010400@suehsi.de>


> 
> I bet they use that to implement memory mapped ide flash or
> something like that..

cs5530 datasheet, page 155

> 
> One second... Could we do bios based transparent hard disk encryption
> this way? That would be kind of cool ;-))
> 
> Stefan
> 




From chris at suehsi.de  Fri May  5 17:37:19 2006
From: chris at suehsi.de (=?ISO-8859-1?Q?Christian_S=FChs?=)
Date: Fri, 05 May 2006 17:37:19 +0200
Subject: [LinuxBIOS] MB1030 / 3036 VGA resume
In-Reply-To: <445B501F.7060900@lanl.gov>
References: <44579320.90206@suehsi.de>
	<8a0c36780605020925h6110f2d8pa656fde32cc5adfb@mail.gmail.com>
	<4457ADD6.8020608@suehsi.de> <20060502192823.GC4620@coresystems.de>
	<4457CB2A.4030908@suehsi.de>
	<20060502205654.GB11460@coresystems.de>
	<44586CDF.2060809@suehsi.de> <4458D0C3.7020308@lanl.gov>
	<4459C0FE.6070104@suehsi.de> <4459EEF5.3070509@suehsi.de>
	<20060504105824.GA11837@coresystems.de>
	<445B1F97.3000001@suehsi.de> <445B501F.7060900@lanl.gov>
Message-ID: <445B712F.9030604@suehsi.de>


>>        ^^ ^^ ^^ ^^
>> LB uses default for index 40 (89h)
>> Factory disables the PCI slave write buffer
>>
>> LB uses default for index 41 (10h)
>> Factory enables/adds F2 IDE Configuration trap (this is a SMI thing)
> 
> 
> oh boy. I HOPE we don't need the SMI support just to run the IDE 
> hardware! we didn't need this before on GX1.

IDE works fine, a little bit slower as under factory.
What about the parity checks, could that be the reason for lowered 
performance for the whole system ?

chris

> 
> ron
> 




From rminnich at lanl.gov  Fri May  5 16:53:59 2006
From: rminnich at lanl.gov (Ronald G Minnich)
Date: Fri, 05 May 2006 08:53:59 -0600
Subject: [LinuxBIOS] UEFI discussion
In-Reply-To: <20060505135026.GA3428@coresystems.de>
References: <20060502205654.GB11460@coresystems.de>
	<44586CDF.2060809@suehsi.de> <4458D0C3.7020308@lanl.gov>
	<4459C0FE.6070104@suehsi.de> <4459EEF5.3070509@suehsi.de>
	<20060504105824.GA11837@coresystems.de>
	<445B1F97.3000001@suehsi.de> <445B501F.7060900@lanl.gov>
	<20060505132640.GA1643@coresystems.de> <445B53A5.7080203@lanl.gov>
	<20060505135026.GA3428@coresystems.de>
Message-ID: <445B6707.6030705@lanl.gov>

Stefan Reinauer wrote:


> Talking about EFI, has anyone been able to get into the UEFI group as
> announced on the LinuxBIOS summit last year? 

I've talked to UEFI about this. I think the fact is that most UEFI 
participants are not that interested in seeing an open source UEFI. I 
don't know if they're opposed, but I don't think they see any reason for 
it.

AMD is, of course, one of the exceptions.

Look at the vendors and you can see why they might not care about open 
source BIOSes.

ron



From rminnich at lanl.gov  Fri May  5 16:54:36 2006
From: rminnich at lanl.gov (Ronald G Minnich)
Date: Fri, 05 May 2006 08:54:36 -0600
Subject: [LinuxBIOS] MB1030 / 3036 VGA resume
In-Reply-To: <445B706C.6010400@suehsi.de>
References: <20060502192823.GC4620@coresystems.de> <4457CB2A.4030908@suehsi.de>
	<20060502205654.GB11460@coresystems.de>
	<44586CDF.2060809@suehsi.de> <4458D0C3.7020308@lanl.gov>
	<4459C0FE.6070104@suehsi.de> <4459EEF5.3070509@suehsi.de>
	<20060504105824.GA11837@coresystems.de>
	<445B1F97.3000001@suehsi.de> <445B501F.7060900@lanl.gov>
	<20060505132640.GA1643@coresystems.de> <445B706C.6010400@suehsi.de>
Message-ID: <445B672C.7060707@lanl.gov>

Christian S?hs wrote:
> 
>>
>> I bet they use that to implement memory mapped ide flash or
>> something like that..
> 
> 
> cs5530 datasheet, page 155
> 
>>


make sure that SMI trap is DISABLED, as it is now :-)

ron



From rminnich at lanl.gov  Fri May  5 16:55:57 2006
From: rminnich at lanl.gov (Ronald G Minnich)
Date: Fri, 05 May 2006 08:55:57 -0600
Subject: [LinuxBIOS] MB1030 / 3036 VGA resume
In-Reply-To: <445B712F.9030604@suehsi.de>
References: <44579320.90206@suehsi.de>
	<8a0c36780605020925h6110f2d8pa656fde32cc5adfb@mail.gmail.com>
	<4457ADD6.8020608@suehsi.de> <20060502192823.GC4620@coresystems.de>
	<4457CB2A.4030908@suehsi.de>
	<20060502205654.GB11460@coresystems.de>
	<44586CDF.2060809@suehsi.de> <4458D0C3.7020308@lanl.gov>
	<4459C0FE.6070104@suehsi.de> <4459EEF5.3070509@suehsi.de>
	<20060504105824.GA11837@coresystems.de>
	<445B1F97.3000001@suehsi.de> <445B501F.7060900@lanl.gov>
	<445B712F.9030604@suehsi.de>
Message-ID: <445B677D.8040809@lanl.gov>

Christian S?hs wrote:

> IDE works fine, a little bit slower as under factory.
> What about the parity checks, could that be the reason for lowered 
> performance for the whole system ?

I doubt it. I still think there is a memory control register somewhere 
that is not set right, so caching is not happening.

I have been able in the past to use lmbench memory diags to locate this 
type of thing. I realize you have done an awful lot, but could we ask 
you to do one more thing? lmbench under factory and under linuxbios? If 
caching is not happening, it will be very obvious under lmbench.

thanks

ron



From chaoseternal at gmail.com  Fri May  5 17:40:01 2006
From: chaoseternal at gmail.com (Chaos Eternal)
Date: Fri, 5 May 2006 23:40:01 +0800
Subject: [LinuxBIOS] MSI K8N Neo4-F (PCB 1.0)
Message-ID: <6456782e0605050840m78911772t7edfdc576e4811ce@mail.gmail.com>

I'v got a motherboard:
MSI K8N Neo4-F (PCB 1.0) URL IS
http://www.msi.com.tw/program/products/mainboard/mbd/pro_mbd_detail.php?UID=652

Typically it's a CK804 board, so I want to make it run linux bios, 
can anybody give me some comments?

lspci's result:

0000:00:00.0 Memory controller: nVidia Corporation CK804 Memory
Controller (rev a3)
	Subsystem: Micro-Star International Co., Ltd.: Unknown device 7125
	Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr-
Stepping- SERR- FastB2B-
	Status: Cap+ 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort-
<TAbort- <MAbort- >SERR- <PERR-
	Latency: 0
	Capabilities: [44] #08 [01e0]
	Capabilities: [e0] #08 [a801]

0000:00:01.0 ISA bridge: nVidia Corporation CK804 ISA Bridge (rev a3)
	Subsystem: Micro-Star International Co., Ltd.: Unknown device 7125
	Control: I/O+ Mem+ BusMaster+ SpecCycle+ MemWINV- VGASnoop- ParErr-
Stepping- SERR- FastB2B-
	Status: Cap- 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort-
<TAbort- <MAbort- >SERR- <PERR-
	Latency: 0

0000:00:01.1 SMBus: nVidia Corporation CK804 SMBus (rev a2)
	Subsystem: Micro-Star International Co., Ltd.: Unknown device 7125
	Control: I/O+ Mem- BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr-
Stepping- SERR- FastB2B-
	Status: Cap+ 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort-
<TAbort- <MAbort- >SERR- <PERR-
	Interrupt: pin A routed to IRQ 3
	Region 0: I/O ports at fc00 [size=32]
	Region 4: I/O ports at 4c00 [size=64]
	Region 5: I/O ports at 4c40 [size=64]
	Capabilities: [44] Power Management version 2
		Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot+,D3cold+)
		Status: D0 PME-Enable- DSel=0 DScale=0 PME-

0000:00:02.0 USB Controller: nVidia Corporation CK804 USB Controller
(rev a2) (prog-if 10 [OHCI])
	Subsystem: Micro-Star International Co., Ltd.: Unknown device 7125
	Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr-
Stepping- SERR- FastB2B-
	Status: Cap+ 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort-
<TAbort- <MAbort- >SERR- <PERR-
	Latency: 0 (750ns min, 250ns max)
	Interrupt: pin A routed to IRQ 50
	Region 0: Memory at fe02f000 (32-bit, non-prefetchable) [size=4K]
	Capabilities: [44] Power Management version 2
		Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=0mA PME(D0+,D1+,D2+,D3hot+,D3cold+)
		Status: D0 PME-Enable- DSel=0 DScale=0 PME-

0000:00:02.1 USB Controller: nVidia Corporation CK804 USB Controller
(rev a3) (prog-if 20 [EHCI])
	Subsystem: Micro-Star International Co., Ltd.: Unknown device 7125
	Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr-
Stepping- SERR- FastB2B-
	Status: Cap+ 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort-
<TAbort- <MAbort- >SERR- <PERR-
	Latency: 0 (750ns min, 250ns max)
	Interrupt: pin B routed to IRQ 217
	Region 0: Memory at feb00000 (32-bit, non-prefetchable) [size=256]
	Capabilities: [44] #0a [2098]
	Capabilities: [80] Power Management version 2
		Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=0mA PME(D0+,D1+,D2+,D3hot+,D3cold+)
		Status: D0 PME-Enable- DSel=0 DScale=0 PME-

0000:00:06.0 IDE interface: nVidia Corporation CK804 IDE (rev f2)
(prog-if 8a [Master SecP PriP])
	Subsystem: Micro-Star International Co., Ltd.: Unknown device 7125
	Control: I/O+ Mem- BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr-
Stepping- SERR- FastB2B-
	Status: Cap+ 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort-
<TAbort- <MAbort- >SERR- <PERR-
	Latency: 0 (750ns min, 250ns max)
	Region 4: I/O ports at e000 [size=16]
	Capabilities: [44] Power Management version 2
		Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-)
		Status: D0 PME-Enable- DSel=0 DScale=0 PME-

0000:00:07.0 IDE interface: nVidia Corporation CK804 Serial ATA
Controller (rev f3) (prog-if 85 [Master SecO PriO])
	Subsystem: Micro-Star International Co., Ltd.: Unknown device 7125
	Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr-
Stepping- SERR- FastB2B-
	Status: Cap+ 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort-
<TAbort- <MAbort- >SERR- <PERR-
	Latency: 0 (750ns min, 250ns max)
	Interrupt: pin A routed to IRQ 217
	Region 0: I/O ports at 09f0 [size=8]
	Region 1: I/O ports at 0bf0 [size=4]
	Region 2: I/O ports at 0970 [size=8]
	Region 3: I/O ports at 0b70 [size=4]
	Region 4: I/O ports at cc00 [size=16]
	Region 5: Memory at fe02b000 (32-bit, non-prefetchable) [size=4K]
	Capabilities: [44] Power Management version 2
		Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-)
		Status: D0 PME-Enable- DSel=0 DScale=0 PME-

0000:00:08.0 IDE interface: nVidia Corporation CK804 Serial ATA
Controller (rev f3) (prog-if 85 [Master SecO PriO])
	Subsystem: Micro-Star International Co., Ltd.: Unknown device 7125
	Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr-
Stepping- SERR- FastB2B-
	Status: Cap+ 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort-
<TAbort- <MAbort- >SERR- <PERR-
	Latency: 0 (750ns min, 250ns max)
	Interrupt: pin A routed to IRQ 225
	Region 0: I/O ports at 09e0 [size=8]
	Region 1: I/O ports at 0be0 [size=4]
	Region 2: I/O ports at 0960 [size=8]
	Region 3: I/O ports at 0b60 [size=4]
	Region 4: I/O ports at b800 [size=16]
	Region 5: Memory at fe02a000 (32-bit, non-prefetchable) [size=4K]
	Capabilities: [44] Power Management version 2
		Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-)
		Status: D0 PME-Enable- DSel=0 DScale=0 PME-

0000:00:09.0 PCI bridge: nVidia Corporation CK804 PCI Bridge (rev a2)
(prog-if 01 [Subtractive decode])
	Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr-
Stepping- SERR- FastB2B-
	Status: Cap- 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort-
<TAbort- <MAbort- >SERR- <PERR-
	Latency: 0
	Bus: primary=00, secondary=01, subordinate=01, sec-latency=32
	I/O behind bridge: 0000a000-0000afff
	Memory behind bridge: fde00000-fdefffff
	Prefetchable memory behind bridge: fdf00000-fdffffff
	BridgeCtl: Parity- SERR- NoISA+ VGA- MAbort- >Reset- FastB2B-

0000:00:0a.0 Bridge: nVidia Corporation CK804 Ethernet Controller (rev a3)
	Subsystem: Micro-Star International Co., Ltd.: Unknown device 7125
	Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr-
Stepping- SERR- FastB2B-
	Status: Cap+ 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort-
<TAbort- <MAbort- >SERR- <PERR-
	Latency: 0 (250ns min, 5000ns max)
	Interrupt: pin A routed to IRQ 233
	Region 0: Memory at fe029000 (32-bit, non-prefetchable) [size=4K]
	Region 1: I/O ports at b400 [size=8]
	Capabilities: [44] Power Management version 2
		Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=0mA PME(D0+,D1+,D2+,D3hot+,D3cold+)
		Status: D0 PME-Enable+ DSel=0 DScale=0 PME-

0000:00:0b.0 PCI bridge: nVidia Corporation CK804 PCIE Bridge (rev a3)
(prog-if 00 [Normal decode])
	Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr-
Stepping- SERR- FastB2B-
	Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort-
<TAbort- <MAbort- >SERR- <PERR-
	Latency: 0, Cache Line Size: 0x08 (32 bytes)
	Bus: primary=00, secondary=02, subordinate=02, sec-latency=0
	I/O behind bridge: 00009000-00009fff
	Memory behind bridge: fdd00000-fddfffff
	Prefetchable memory behind bridge: 00000000fdc00000-00000000fdc00000
	BridgeCtl: Parity- SERR- NoISA+ VGA- MAbort- >Reset- FastB2B-
	Capabilities: [40] Power Management version 2
		Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0+,D1+,D2+,D3hot+,D3cold+)
		Status: D0 PME-Enable- DSel=0 DScale=0 PME-
	Capabilities: [48] Message Signalled Interrupts: 64bit+ Queue=0/1 Enable+
		Address: 00000000fee00000  Data: 40b9
	Capabilities: [58] #08 [a800]
	Capabilities: [80] #10 [0141]

0000:00:0c.0 PCI bridge: nVidia Corporation CK804 PCIE Bridge (rev a3)
(prog-if 00 [Normal decode])
	Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr-
Stepping- SERR- FastB2B-
	Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort-
<TAbort- <MAbort- >SERR- <PERR-
	Latency: 0, Cache Line Size: 0x08 (32 bytes)
	Bus: primary=00, secondary=03, subordinate=03, sec-latency=0
	I/O behind bridge: 00008000-00008fff
	Memory behind bridge: fdb00000-fdbfffff
	Prefetchable memory behind bridge: 00000000fda00000-00000000fda00000
	BridgeCtl: Parity- SERR- NoISA+ VGA- MAbort- >Reset- FastB2B-
	Capabilities: [40] Power Management version 2
		Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0+,D1+,D2+,D3hot+,D3cold+)
		Status: D0 PME-Enable- DSel=0 DScale=0 PME-
	Capabilities: [48] Message Signalled Interrupts: 64bit+ Queue=0/1 Enable+
		Address: 00000000fee00000  Data: 40c1
	Capabilities: [58] #08 [a800]
	Capabilities: [80] #10 [0141]

0000:00:0d.0 PCI bridge: nVidia Corporation CK804 PCIE Bridge (rev a3)
(prog-if 00 [Normal decode])
	Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr-
Stepping- SERR- FastB2B-
	Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort-
<TAbort- <MAbort- >SERR- <PERR-
	Latency: 0, Cache Line Size: 0x08 (32 bytes)
	Bus: primary=00, secondary=04, subordinate=04, sec-latency=0
	I/O behind bridge: 00007000-00007fff
	Memory behind bridge: fd900000-fd9fffff
	Prefetchable memory behind bridge: 00000000fd800000-00000000fd800000
	BridgeCtl: Parity- SERR- NoISA+ VGA- MAbort- >Reset- FastB2B-
	Capabilities: [40] Power Management version 2
		Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0+,D1+,D2+,D3hot+,D3cold+)
		Status: D0 PME-Enable- DSel=0 DScale=0 PME-
	Capabilities: [48] Message Signalled Interrupts: 64bit+ Queue=0/1 Enable+
		Address: 00000000fee00000  Data: 40c9
	Capabilities: [58] #08 [a800]
	Capabilities: [80] #10 [0141]

0000:00:0e.0 PCI bridge: nVidia Corporation CK804 PCIE Bridge (rev a3)
(prog-if 00 [Normal decode])
	Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr-
Stepping- SERR- FastB2B-
	Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort-
<TAbort- <MAbort- >SERR- <PERR-
	Latency: 0, Cache Line Size: 0x08 (32 bytes)
	Bus: primary=00, secondary=05, subordinate=05, sec-latency=0
	I/O behind bridge: 00006000-00006fff
	Memory behind bridge: fd700000-fd7fffff
	Prefetchable memory behind bridge: 00000000fd600000-00000000fd600000
	BridgeCtl: Parity- SERR- NoISA+ VGA- MAbort- >Reset- FastB2B-
	Capabilities: [40] Power Management version 2
		Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0+,D1+,D2+,D3hot+,D3cold+)
		Status: D0 PME-Enable- DSel=0 DScale=0 PME-
	Capabilities: [48] Message Signalled Interrupts: 64bit+ Queue=0/1 Enable+
		Address: 00000000fee00000  Data: 40d1
	Capabilities: [58] #08 [a800]
	Capabilities: [80] #10 [0141]

0000:00:18.0 Host bridge: Advanced Micro Devices [AMD] K8
[Athlon64/Opteron] HyperTransport Technology Configuration
	Control: I/O- Mem- BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr-
Stepping- SERR- FastB2B-
	Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort-
<TAbort- <MAbort- >SERR- <PERR-
	Capabilities: [80] #08 [2101]

0000:00:18.1 Host bridge: Advanced Micro Devices [AMD] K8
[Athlon64/Opteron] Address Map
	Control: I/O- Mem- BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr-
Stepping- SERR- FastB2B-
	Status: Cap- 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort-
<TAbort- <MAbort- >SERR- <PERR-

0000:00:18.2 Host bridge: Advanced Micro Devices [AMD] K8
[Athlon64/Opteron] DRAM Controller
	Control: I/O- Mem- BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr-
Stepping- SERR- FastB2B-
	Status: Cap- 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort-
<TAbort- <MAbort- >SERR- <PERR-

0000:00:18.3 Host bridge: Advanced Micro Devices [AMD] K8
[Athlon64/Opteron] Miscellaneous Control
	Control: I/O- Mem- BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr-
Stepping- SERR- FastB2B-
	Status: Cap- 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort-
<TAbort- <MAbort- >SERR- <PERR-



From eric at zyxod.com  Fri May  5 18:33:36 2006
From: eric at zyxod.com (Eric Poulsen)
Date: Fri, 05 May 2006 09:33:36 -0700
Subject: [LinuxBIOS] Rapid booting of Linux -- Recommended distributions /
	Kernel options?
Message-ID: <445B7E60.7000405@zyxod.com>

I've been using Ubuntu (because of ease of install / familiarity with 
Debian) as my test platform for rapid booting.  Ubuntu is remarkably 
slow at booting -- It's made to work with just about any hardware.  Can 
anyone recommend any distributions that are more geared towards the 
embedded rapid-boot?  Essentially, I'd like to have a user-space program 
that's doing I/O via serial / usb to do data logging as quickly as 
possible, and everything else (display, mounting a mechanical hard 
drive) can wait.  Essentially, steps 1-3 have to be as fast as possible.

1) LB + Filo -- Load Kernel from CF
2) Kernel init (I have this down to 0.9 seconds)
3) User space program that loads USB drivers and begins data logging
4) Everything else: network, display (X.org), hard drive mount etc

I need a distro that lets you do most of the usual startup stuff later.

---

Here's a list of kernel options that I'm using -- anybody have any other 
"tricks" to speed this up?

root=/dev/hda1
console=ttyS0,115200 [I know this slows it down]
console=tty0 [This might be a major time waster, also -- I suspect the 
kernel VGA init is slow]
lpj=2136847
dhash_entries=16000 [I'm not sure if making the Dentry hash is slow, or 
if the VGA init routine just before it is the culprit]
ide0=0x1f0,0x3f6,14
ide0=noprobe
ide1=noprobe 
ide2=noprobe
ide3=noprobe
ide4=noprobe
ide5=noprobe
hda=65535,16,63
hdb=none
hdc=noprobe [This is the CF -- don't need it after boot]
hdd=none
no_hlt

Also, If I do hda=noprobe, I guess the kernel won't mount it, so it 
fails.  Seems like the kernel *must* probe the hd?  I thought as long as 
it has the CHS, it didn't need to probe.




From yinghai.lu at amd.com  Fri May  5 18:49:45 2006
From: yinghai.lu at amd.com (Lu, Yinghai)
Date: Fri, 5 May 2006 09:49:45 -0700
Subject: [LinuxBIOS] MSI K8N Neo4-F (PCB 1.0)
Message-ID: <6F7DA19D05F3CF40B890C7CA2DB13A4203094C5C@ssvlexmb2.amd.com>

It could be supported.

1. Ck804 support is in the tree.
2. athlon64 support is in the tree. But need to check to make it support
1 above dimms
3. Athlon64 FX support need to use fidvid to set correct FID, otherwise
it will only run at low freq. ---- we need to provide
enable_fid_change_on_sb for Ck804.

You can start from make a clone mb and target dir for it from tyan
s2891...

YH





From ward at gnu.org  Fri May  5 18:53:06 2006
From: ward at gnu.org (Ward Vandewege)
Date: Fri, 5 May 2006 12:53:06 -0400
Subject: [LinuxBIOS] s2881 build broken
In-Reply-To: <20060504001013.GB3723@localdomain>
References: <20060503223908.GA16539@localdomain>
	<20060503231208.GA28727@coresystems.de>
	<20060504001013.GB3723@localdomain>
Message-ID: <20060505165306.GA13211@localdomain>

On Wed, May 03, 2006 at 08:10:13PM -0400, Ward Vandewege wrote:
> On Thu, May 04, 2006 at 01:12:08AM +0200, Stefan Reinauer wrote:
> > * Ward Vandewege <ward at gnu.org> [060504 00:39]:
> > > Hi all,
> > > 
> > > It seems that revision 2288 broke something in the tyan/s2881 build; 2289 and
> > > 2290 are also bad. 2287 is ok.
> > > 
> > > Boot log attached; it just keeps rebooting after the 'Jumping to LinuxBIOS'
> > > line. This is gcc 3.4.
> > > 
> > > Suggestions?
> > 
> > Yes, I suggest I owe you a beer next time we meet and you try 2291.
> 
> :) all right, will do so on Friday; not in the office tomorrow. I'll put a
> note on the s2881 build page that 2288 through 2290 are known bad.

Cool; 2298 works. Thanks.

Ward.

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



From smithbone at gmail.com  Fri May  5 19:03:43 2006
From: smithbone at gmail.com (Richard Smith)
Date: Fri, 5 May 2006 12:03:43 -0500
Subject: [LinuxBIOS] Rapid booting of Linux -- Recommended distributions
	/ Kernel options?
In-Reply-To: <445B7E60.7000405@zyxod.com>
References: <445B7E60.7000405@zyxod.com>
Message-ID: <8a0c36780605051003j4f6b9894k2ecbe645972765ac@mail.gmail.com>

> that's doing I/O via serial / usb to do data logging as quickly as
> possible, and everything else (display, mounting a mechanical hard
> drive) can wait.  Essentially, steps 1-3 have to be as fast as possible.

What about building everything as modules and boot with an initrd that
just has your user app static linked on it and the ide + fs modules?

You can boot get your app up and going first and then go do the
probe/mount ide and then pivot_root once you get it all setup.

> Also, If I do hda=noprobe, I guess the kernel won't mount it, so it
> fails.  Seems like the kernel *must* probe the hd?  I thought as long as
> it has the CHS, it didn't need to probe.

It needs to know lots of other stuff, ATA mode, etc.

--
Richard A. Smith



From ward at gnu.org  Fri May  5 22:57:17 2006
From: ward at gnu.org (Ward Vandewege)
Date: Fri, 5 May 2006 16:57:17 -0400
Subject: [LinuxBIOS] s2881 fan control
In-Reply-To: <6F7DA19D05F3CF40B890C7CA2DB13A4203094BD5@ssvlexmb2.amd.com>
References: <6F7DA19D05F3CF40B890C7CA2DB13A4203094BD5@ssvlexmb2.amd.com>
Message-ID: <20060505205717.GA20174@localdomain>

On Thu, Apr 20, 2006 at 04:59:52PM -0700, Lu, Yinghai wrote:
> I have inited the hw sensors in LinuxBIOS for s2881. So you could use
> lmsensor to check the FAN speed. The config file is on Tyan web.
> 
> For the Fan control, there should more some reg setting...to reduce the
> FAN speed winbond and adm1027...

An update on this.

As I reported earlier, setting fan speed works fine from LinuxBIOS. But it
seems this is only the case until I unplug the power from the machine.

When the machine is newly powered in, I need to boot up the proprietary bios
first to be able to _set_ the fan speed. 

Once I've done that, I can reboot into LinuxBIOS, and set the speed just fine
using 

  /sys/bus/i2c/drivers/lm85/0-002d/pwm1

for instance like this:

  echo '60' > /sys/bus/i2c/drivers/lm85/0-002d/pwm1

See attached set_fan_speed_ok.txt for a typical output.

I can shut the machine down, do a cold boot into LinuxBIOS, and it still
works.

Until I unplug the power to the machine, that is.
  
After that, I can still read out everything (see attached
set_fan_speed_bad.txt) correctly, but now also _set_ the fan speed.

Suggestions?

Thanks,
Ward.

-- 
Ward Vandewege <ward at fsf.org>
Free Software Foundation - Senior System Administrator
-------------- next part --------------
root at chimera:~# /usr/bin/sensors
adt7463-i2c-0-2d
Adapter: SMBus AMD8111 adapter at 20e0
DDR 2.5V:  +2.653 V  (min =  +2.53 V, max =  +2.79 V)
DDR VTT:   +1.333 V  (min =  +1.23 V, max =  +1.36 V)
3VSB:      +3.317 V  (min =  +3.13 V, max =  +3.47 V)
+5 V:     +5.111 V  (min =  +4.74 V, max =  +5.26 V)
+12V:     +12.016 V  (min = +10.81 V, max = +13.19 V)
CPU0 Fan: 17307 RPM  (min =    0 RPM)
CPU1 Fan: 17419 RPM  (min =    0 RPM)
Fan9:     17307 RPM  (min =    0 RPM)
CPU1 Temp:+47.25?C  (low  =  -127?C, high =  +127?C)
CPU0 Temp:+49.50?C  (low  =  -127?C, high =  +127?C)
pwm1:      255
pwm2:      255
pwm3:      255
vid:      +1.350 V  (VRM Version 2.4)

w83627hf-isa-0290
Adapter: ISA adapter
CPU0 Volt: +1.41 V  (min =  +1.28 V, max =  +1.42 V)
CPU1 Volt: +1.41 V  (min =  +1.28 V, max =  +1.42 V)
3.3V:      +3.46 V  (min =  +3.14 V, max =  +3.47 V)
DDR VREF:  +1.33 V  (min =  +1.23 V, max =  +1.36 V)
DDR VCORE: +2.67 V  (min =  +2.38 V, max =  +2.93 V)
HT CORE:   +1.34 V  (min =  +1.26 V, max =  +1.39 V)
CPU0 Fan: 17307 RPM  (min = 2657 RPM, div = 2)
CPU1 Fan: 18243 RPM  (min = 2657 RPM, div = 2)
Fan8:     15697 RPM  (min = 2657 RPM, div = 2)
vid:      +1.350 V  (VRM Version 2.4)
alarms:
beep_enable:
          Sound alarm disabled

eeprom-i2c-0-54
Adapter: SMBus AMD8111 adapter at 20e0
Memory type:            DDR SDRAM DIMM
Memory size (MB):       1024

eeprom-i2c-0-50
Adapter: SMBus AMD8111 adapter at 20e0
Memory type:            DDR SDRAM DIMM
Memory size (MB):       1024

-------------- next part --------------
root at chimera:~# /usr/bin/sensors
adt7463-i2c-0-2d
Adapter: SMBus AMD8111 adapter at 10e0
DDR 2.5V:  +2.646 V  (min =  +2.53 V, max =  +2.80 V)
DDR VTT:   +1.324 V  (min =  +1.23 V, max =  +1.36 V)
3VSB:      +3.321 V  (min =  +3.13 V, max =  +3.47 V)
+5 V:     +5.104 V  (min =  +4.74 V, max =  +5.26 V)
+12V:     +12.063 V  (min = +10.81 V, max = +13.19 V)
CPU0 Fan: 11273 RPM  (min =    0 RPM)
CPU1 Fan: 11464 RPM  (min =    0 RPM)
Fan9:     11320 RPM  (min =    0 RPM)
CPU1 Temp:+48.25?C  (low  =  -127?C, high =  +127?C)
CPU0 Temp:+49.00?C  (low  =  -127?C, high =  +127?C)
pwm1:       60
pwm2:       60
pwm3:       60
vid:      +1.350 V  (VRM Version 2.4)

w83627hf-isa-0290
Adapter: ISA adapter
CPU0 Volt: +1.41 V  (min =  +1.28 V, max =  +1.42 V)
CPU1 Volt: +1.41 V  (min =  +1.28 V, max =  +1.42 V)
3.3V:      +3.46 V  (min =  +3.14 V, max =  +3.47 V)
DDR VREF:  +1.34 V  (min =  +1.23 V, max =  +1.36 V)
DDR VCORE: +2.66 V  (min =  +2.42 V, max =  +2.96 V)
HT CORE:   +1.33 V  (min =  +1.26 V, max =  +1.39 V)
CPU0 Fan: 11250 RPM  (min = 2657 RPM, div = 2)
CPU1 Fan: 11842 RPM  (min = 2657 RPM, div = 2)
Fan8:     10546 RPM  (min = 2657 RPM, div = 2)
vid:      +1.350 V  (VRM Version 2.4)
alarms:
beep_enable:
          Sound alarm disabled

eeprom-i2c-0-54
Adapter: SMBus AMD8111 adapter at 10e0
Memory type:            DDR SDRAM DIMM
Memory size (MB):       1024


From ward at gnu.org  Fri May  5 22:58:33 2006
From: ward at gnu.org (Ward Vandewege)
Date: Fri, 5 May 2006 16:58:33 -0400
Subject: [LinuxBIOS] some more tyan/s2881 questions
In-Reply-To: <8a0c36780604201625m4424248fn3ce45d8dca138fb4@mail.gmail.com>
References: <6F7DA19D05F3CF40B890C7CA2DB13A4203094B90@ssvlexmb2.amd.com>
	<20060420231127.GA27488@io.pong.be>
	<8a0c36780604201625m4424248fn3ce45d8dca138fb4@mail.gmail.com>
Message-ID: <20060505205833.GB20174@localdomain>

On Thu, Apr 20, 2006 at 06:25:29PM -0500, Richard Smith wrote:
> On 4/20/06, Ward Vandewege <ward at gnu.org> wrote:
> > On Mon, Apr 10, 2006 at 04:00:27PM -0700, Lu, Yinghai wrote:
> > > 1. need to add acpi support in s2881 LinuxBIOS support to get it.
> > > Anyway 8111 acpi support is already there in Serengeti_leopard, so it
> > > will be easy to get that.
> >
> > So.... if there is no ACPI support yet for this board in LinuxBIOS, does that
> > mean that there is no automatic fan control in hardware? In other words, that
> > the CPUs will cook if they get too hot, because the fans won't start blowing
> > harder automatically?
> 
> If they do then the hardware designers failed miserably.  Generally
> what I find is that when you first power on the machine the fans come
> on full.  Then the bios takes over.

I can confirm that this is what happens when the s2881 is first plugged in.
The fans go full speed, regardless of the BIOS.

Ward.

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



From ward at pong.be  Fri May  5 23:01:05 2006
From: ward at pong.be (Ward Vandewege)
Date: Fri, 5 May 2006 17:01:05 -0400
Subject: [LinuxBIOS] s2881 fan control
In-Reply-To: <20060505205717.GA20174@localdomain>
References: <6F7DA19D05F3CF40B890C7CA2DB13A4203094BD5@ssvlexmb2.amd.com>
	<20060505205717.GA20174@localdomain>
Message-ID: <20060505210105.GC20174@localdomain>

On Fri, May 05, 2006 at 04:57:17PM -0400, Ward Vandewege wrote:
> On Thu, Apr 20, 2006 at 04:59:52PM -0700, Lu, Yinghai wrote:
> > I have inited the hw sensors in LinuxBIOS for s2881. So you could use
> > lmsensor to check the FAN speed. The config file is on Tyan web.
> > 
> > For the Fan control, there should more some reg setting...to reduce the
> > FAN speed winbond and adm1027...

> I can shut the machine down, do a cold boot into LinuxBIOS, and it still
> works.
> 
> Until I unplug the power to the machine, that is.
>   
> After that, I can still read out everything (see attached
> set_fan_speed_bad.txt) correctly, but now also _set_ the fan speed.

I'm sorry this is confusing. After unplugging and replugging the power to the
machine, I need to boot the proprietary BIOS once to be able to set the fan
speed on any consecutive (cold) boot. 

Ward.

-- 
Pong.be         -(       Writing software is more fun than working.        )-
Virtual hosting -(                                                         )-
http://pong.be  -(                                                         )-
GnuPG public key: http://gpg.dtype.org



From ward at gnu.org  Fri May  5 23:19:23 2006
From: ward at gnu.org (Ward Vandewege)
Date: Fri, 5 May 2006 17:19:23 -0400
Subject: [LinuxBIOS] s2881 fan control
In-Reply-To: <20060505205717.GA20174@localdomain>
References: <6F7DA19D05F3CF40B890C7CA2DB13A4203094BD5@ssvlexmb2.amd.com>
	<20060505205717.GA20174@localdomain>
Message-ID: <20060505211923.GA22205@localdomain>

On Fri, May 05, 2006 at 04:57:17PM -0400, Ward Vandewege wrote:
> On Thu, Apr 20, 2006 at 04:59:52PM -0700, Lu, Yinghai wrote:
> > I have inited the hw sensors in LinuxBIOS for s2881. So you could use
> > lmsensor to check the FAN speed. The config file is on Tyan web.
> > 
> > For the Fan control, there should more some reg setting...to reduce the
> > FAN speed winbond and adm1027...

> I can shut the machine down, do a cold boot into LinuxBIOS, and it still
> works.
> 
> Until I unplug the power to the machine, that is.
>   
> After that, I can still read out everything (see attached
> set_fan_speed_bad.txt) correctly, but now also _set_ the fan speed.

I'm sorry this is confusing. After unplugging and replugging the power to the
machine, I need to boot the proprietary BIOS once to be able to set the fan
speed on any consecutive (cold) boot. 

Ward.

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



From smithbone at gmail.com  Fri May  5 23:23:48 2006
From: smithbone at gmail.com (Richard Smith)
Date: Fri, 5 May 2006 16:23:48 -0500
Subject: [LinuxBIOS] some more tyan/s2881 questions
In-Reply-To: <20060505205833.GB20174@localdomain>
References: <6F7DA19D05F3CF40B890C7CA2DB13A4203094B90@ssvlexmb2.amd.com>
	<20060420231127.GA27488@io.pong.be>
	<8a0c36780604201625m4424248fn3ce45d8dca138fb4@mail.gmail.com>
	<20060505205833.GB20174@localdomain>
Message-ID: <8a0c36780605051423r43e98121o9dd64ae242bec735@mail.gmail.com>

> > If they do then the hardware designers failed miserably.  Generally
> > what I find is that when you first power on the machine the fans come
> > on full.  Then the bios takes over.
>
> I can confirm that this is what happens when the s2881 is first plugged in.
> The fans go full speed, regardless of the BIOS.
>

Soif you set the fan speed really low does the system override you
when you run something like cpuburn?

--
Richard A. Smith



From ward at gnu.org  Fri May  5 23:38:30 2006
From: ward at gnu.org (Ward Vandewege)
Date: Fri, 5 May 2006 17:38:30 -0400
Subject: [LinuxBIOS] etherboot/filo + sata startup timing
In-Reply-To: <20060505134709.GA2422@coresystems.de>
References: <20060424220147.GA26709@io.pong.be> <444D4AED.3020805@lanl.gov>
	<20060424222144.GA17934@coresystems.de>
	<20060424222501.GC27028@io.pong.be>
	<20060428231617.GA28043@coresystems.de>
	<20060501155545.GA3652@io.pong.be>
	<20060505134709.GA2422@coresystems.de>
Message-ID: <20060505213830.GA23965@localdomain>

On Fri, May 05, 2006 at 03:47:09PM +0200, Stefan Reinauer wrote:
> AUTOBOOT_DELAY is a different one, it waits for user interaction before
> trying to start the kernel..

Right - FILO never even gets to that point.

> drive startup times could be an issue though
> 
> Could you try some things:
> 
>  * update to the latest svn revision (17 as I write this) and make sure
>    you enabled the following option (which is new)

I've tried rev 19.

>      # Add a short delay when polling status registers
>      # (required on some broken SATA controllers)
>      IDE_DISK_POLL_DELAY = 1

I've tried this; the boot log is attached (minicom-20060505.cap) with
DEBUG_PCI, DEBUG_IDE and DEBUG_LINUXBIOS enabled. Didn't help.

>  * if that doesnt help: try whether the disk is detected as hda instead
>    of hde. This might happen with the current code.

I've tried that too, the bootlog is also attached (minicom-20060505-2.cap).
Still no luck; though here it does seem to find the IDE controller. But not
the drive...

Ward.

-- 
Ward Vandewege <ward at fsf.org>
Free Software Foundation - Senior System Administrator
-------------- next part --------------
A non-text attachment was scrubbed...
Name: minicom-20060505.cap.gz
Type: application/octet-stream
Size: 3424 bytes
Desc: not available
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20060505/79e50100/attachment.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: minicom-20060505-2.cap.gz
Type: application/octet-stream
Size: 3055 bytes
Desc: not available
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20060505/79e50100/attachment-0001.obj>

From stuge-linuxbios at cdy.org  Sat May  6 01:02:18 2006
From: stuge-linuxbios at cdy.org (Peter Stuge)
Date: Sat, 6 May 2006 01:02:18 +0200
Subject: [LinuxBIOS] Rapid booting of Linux -- Recommended distributions
	/ Kernel options?
In-Reply-To: <445B7E60.7000405@zyxod.com>
References: <445B7E60.7000405@zyxod.com>
Message-ID: <20060505230219.9392.qmail@cdy.org>

On Fri, May 05, 2006 at 09:33:36AM -0700, Eric Poulsen wrote:
> Can anyone recommend any distributions that are more geared towards
> the embedded rapid-boot?

Besides rolling your own bare-minimum distribution perhaps GNAP would
fit:

http://www.gentoo.org/proj/en/base/embedded/gnap.xml

(Gentoo Network Appliance)

The system footprint seems to be around 15MB, don't know about boot
times.


For my soekris boxes (which btw are Geode SC1100s just begging for
LinuxBIOS, they have serial, ethernet(s!), various expansion
possibilities, no VGA, no sound and a proprietary BIOS :) I used the
Gentoo catalyst tool to make a stage4 glibc-based system in about
38MB (including quite a lot of tools) but beware that it's a bit
messy since you have to list all files from packages that you don't
want in the end result (man pages, other docs, development stuff etc)
 - on the other hand you can create local packages in the portage
overlay directory to customize the system and boot process
completely. I haven't optimized for speed at all so boot takes about
80 seconds. Maybe ten seconds from power on until init exec, so
there's a lot of room for improvement.

Some Gentooers frown upon making a stage4 for an embedded system but
I found that doing so simply allows me more choice than GNAP would.


//Peter



From eric at zyxod.com  Sat May  6 09:11:00 2006
From: eric at zyxod.com (Eric Poulsen)
Date: Sat, 06 May 2006 00:11:00 -0700
Subject: [LinuxBIOS] LB vs Factory BIOS -- more weirdness
Message-ID: <445C4C04.6090302@zyxod.com>

In response to the instability issues I've had with LB (It's not ram -- 
memtest86+ ran for hours under LB with no errors), someone here 
suggested that there are chipset registers that are reset by the factory 
BIOS that LB isn't (re)setting correctly, and that LB works well right 
after using the factory BIOS because those registers hold their values 
for a while.

I'm conviced this is the case -- I have too many weird issues that can 
be fixed by simply flipping back to the factory BIOS, turning the system 
on, getting a "bad CMOS" error, then immediately powering off and 
switching to LB, which suddenly works again.

I'm pretty sure the DMA transfer under Linux bug (this is a chipset bug 
specific to some Epia models that can be fixed (in theory) with a BIOS 
upgrade) is exhibiting itself -- I get hard locks with the HD light on 
when xferring larger files.  It's really easy to reproduce.  I tried to 
lock it under the factory bios, but it wouldn't lock.  After I rebooted 
using LB, the problem went away in LB as well.  This tends to support 
the "chipset register remembrance" theory.

Here's the latest.  The full serial caps are at the bottom, but here are 
the differences.  I set all the kernel times to zero so that diff would 
work.

Differences in LB output:

 Crash: Low Bond 00  High Bondc0  Setting DQS delay80vt8623 done
Worked: Low Bond 00  High Bondc1  Setting DQS delay80vt8623 done

I'm no expert, but this appears to be looking for a range of usable RAM 
under 1M.  Should the High Bond values be different, ever?

Differences in kernel output:
 Crash: [00000.00000] DMI 2.2 present.
Worked: [00000.00000] DMI not present or invalid.

I'm not sure if this is relevant or not ...


And finally, the crash itself:

  [00000.00000] PCI: If a device doesn't work, try "pci=routeirq".  If 
it helps, post a report
  [00000.00000] general protection fault: 3120 [#1]
  [00000.00000] Modules linked in:
  [00000.00000] CPU:    0
  [00000.00000] EIP:    0060:[<c00faa2c>]    Not tainted VLI
  [00000.00000] EFLAGS: 00010013   (2.6.16.5 #4)
  [00000.00000] EIP is at 0xc00faa2c
  [00000.00000] eax: 0000b102   ebx: c13f7400   ecx: 00003123   edx: 
00001106
  [00000.00000] esi: 00000000   edi: c03016cc   ebp: 00000000   esp: 
c11fff76
  [00000.00000] ds: 007b   es: 007b   ss: 0068
  [00000.00000] Process swapper (pid: 1, threadinfo=c11fe000 task=c11fba70)
  [00000.00000] Stack: <0>31230000 c03016cc c00fa97c 0000b102 00001106 
072c0246 0060c024 74000000
  [00000.00000]        0000c13f 00000000 09fb0000 1106c024 31230000 
00000000 ffba0000 ffbbc11f
  [00000.00000]        0000c11f ffbc0000 ffbcc11f 1274c11f 0000c036 
00000000 7d150000 06fbc035
  [00000.00000] Call Trace:
  [00000.00000] Code: cb 87 db b4 81 f9 c3 e8 aa 03 00 00 ba 50 43 49 20 
66 b8 11 00 66 bb 10 02 f8 c3 57 66 51 66 56 66 83   fa ff 75 05 b4 83 
f9 eb 53 <66> cb f9 c1 e7 10 66 8b fa e8 7d 03 00 00 8a d9 32 ff 32 ed 80
  [00000.00000]  <0>Kernel panic - not syncing: Attempted to kill init!
  [00000.00000]

------------------------------
Full Text, working boot:
------------------------------
0

LinuxBIOS-1.1.8.0Fallback Thu May  4 18:03:52 PDT 2006 starting...
 Enabling mainboard devices
 Enabling shadow ram
vt8623 init starting
Detecting Memory
Number of Banks 04
Number of Rows 0d
Priamry DRAM width08
No Columns 0a
MA type e0
Bank 0 (*16 Mb) 10
No Physical Banks 01
Total Memory (*16 Mb) 10
CAS Supported 2 2.5 3
Cycle time at CL X     (nS)50
Cycle time at CL X-0.5 (nS)60
Cycle time at CL X-1   (nS)75
Starting at CAS 3
We can do CAS 2.5
We can do CAS 2
tRP 48
tRCD 48
tRAS 28
Low Bond 00  High Bondc1  Setting DQS delay80vt8623 done
00:06 11 23 31 06 00 30 22 00 00 00 06 00 00 00 00
10:08 00 00 d0 00 00 00 00 00 00 00 00 00 00 00 00
20:00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
30:00 00 00 00 a0 00 00 00 00 00 00 00 00 00 00 00
40:00 18 88 80 82 44 00 00 18 99 88 80 82 44 00 00
50:c8 de cf 88 e0 07 00 00 e0 00 10 10 10 10 00 00
60:02 ff 00 30 d6 32 01 2a 42 2d 43 58 00 44 00 00
70:82 48 00 01 01 08 50 00 01 00 00 00 00 00 02 02
80:0f 65 00 00 80 00 00 00 02 00 00 00 00 00 00 00
90:00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
a0:02 c0 20 00 07 02 00 1f 04 00 00 00 2f 02 04 00
b0:00 00 00 00 80 00 00 00 88 00 00 00 00 00 00 00
c0:01 00 02 00 00 00 00 00 00 00 00 00 00 00 00 00
d0:00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
e0:00 dd 00 00 00 00 01 00 40 00 00 00 00 00 00 00
f0:00 00 00 00 00 00 12 13 00 00 00 00 00 00 00 00
AGP
 Doing MTRR init.
Copying LinuxBIOS to ram.
Jumping to LinuxBIOS.
LinuxBIOS-1.1.8.0Fallback Fri May  5 19:03:15 PDT 2006 booting...
clocks_per_usec: 838
Enumerating buses...
Finding PCI configuration type.
PCI: Using configuration type 1
PCI_DOMAIN: 0000 enabled
APIC_CLUSTER: 0 enabled
PCI: pci_scan_bus for bus 0
PCI: 00:00.0 [1106/3123] enabled
PCI: 00:01.0 [1106/b091] enabled
In vt8235_enable 1106 3038.
PCI: 00:10.0 [1106/3038] enabled
In vt8235_enable 1106 3038.
PCI: 00:10.1 [1106/3038] enabled
In vt8235_enable 1106 3038.
PCI: 00:10.2 [1106/3038] enabled
In vt8235_enable 1106 3104.
PCI: 00:10.3 [1106/3104] enabled
In vt8235_enable 1106 3177.
Initialising Devices
PCI: 00:11.0 [1106/3177] enabled
In vt8235_enable 1106 0571.
PCI: 00:11.1 [1106/0571] enabled
In vt8235_enable 1106 3059.
PCI: 00:11.5 [1106/3059] enabled
In vt8235_enable ffff ffff.
In vt8235_enable 1106 3065.
PCI: 00:12.0 [1106/3065] enabled
PCI: pci_scan_bus for bus 1
PCI: 01:00.0 [1106/3122] enabled
PCI: pci_scan_bus returning with max=01
vt1211 enabling PNP devices.
PNP: 002e.1 enabled
vt1211 enabling PNP devices.
PNP: 002e.2 enabled
vt1211 enabling PNP devices.
PNP: 002e.3 enabled
vt1211 enabling PNP devices.
PNP: 002e.b enabled
PNP: 002e.0 enabled
PCI: pci_scan_bus returning with max=01
done
Allocating resources...
Reading resources...
Done reading resources.
Setting resources...
I would set ram size to 0x40000 Kbytes
PCI: 00:10.0 20 <- [0x0000001800 - 0x000000181f] io
PCI: 00:10.1 20 <- [0x0000001820 - 0x000000183f] io
PCI: 00:10.2 20 <- [0x0000001840 - 0x000000185f] io
PCI: 00:10.3 10 <- [0x00febff000 - 0x00febff0ff] mem
PNP: 002e.1 60 <- [0x0000000378 - 0x000000037f] io
PNP: 002e.1 70 <- [0x0000000007 - 0x0000000007] irq
PNP: 002e.1 74 <- [0x0000000003 - 0x0000000003] drq
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
PNP: 002e.b 60 <- [0x000000ec00 - 0x000000ecff] io
ERROR: PNP: 002e.0 60 io size: 0x0000000008 not assigned
ERROR: PNP: 002e.0 60 irq size: 0x0000000001 not assigned
ERROR: PNP: 002e.0 60 drq size: 0x0000000001 not assigned
PCI: 00:11.1 20 <- [0x0000001860 - 0x000000186f] io
PCI: 00:11.5 10 <- [0x0000001000 - 0x00000010ff] io
PCI: 00:12.0 10 <- [0x0000001400 - 0x00000014ff] io
PCI: 00:12.0 14 <- [0x00fec00000 - 0x00fec000ff] mem
Done setting resources.
Done allocating resources.
Enabling resources...
PCI: 00:00.0 cmd <- 146
PCI: 00:01.0 bridge ctrl <- 000f
PCI: 00:01.0 cmd <- 147
PCI: 01:00.0 cmd <- 140
PCI: 00:10.0 subsystem <- 00/00
PCI: 00:10.0 cmd <- 141
PCI: 00:10.1 subsystem <- 00/00
PCI: 00:10.1 cmd <- 141
PCI: 00:10.2 subsystem <- 00/00
PCI: 00:10.2 cmd <- 141
PCI: 00:10.3 subsystem <- 00/00
PCI: 00:10.3 cmd <- 142
PCI: 00:11.0 cmd <- 147
PNP: 002e.1 - enabling
PNP: 002e.2 - enabling
PNP: 002e.3 - enabling
PNP: 002e.b - enabling
PNP: 002e.0 - enabling
PCI: 00:11.1 cmd <- 147
PCI: 00:11.5 subsystem <- 00/00
PCI: 00:11.5 cmd <- 141
PCI: 00:12.0 cmd <- 1c3
done.
Initializing devices...
Root Device init
PCI: 00:10.0 init
PCI: 00:10.1 init
PCI: 00:10.2 init
PCI: 00:10.3 init
PCI: 00:11.0 init
vt8235 init
RTC Init
Invalid CMOS LB checksum
pci_routing_fixup: dev is 000107c0
setting firewire
setting usb
Assigning IRQ 5 to 0:10.0
  Readback = 5
pci_level_irq: lower order bits are wrong: want 0x0, got 0x20
Assigning IRQ 9 to 0:10.1
  Readback = 9
pci_level_irq: lower order bits are wrong: want 0x0, got 0x20
Assigning IRQ 9 to 0:10.2
  Readback = 9
pci_level_irq: lower order bits are wrong: want 0x0, got 0x20
Assigning IRQ 5 to 0:10.3
  Readback = 5
pci_level_irq: lower order bits are wrong: want 0x0, got 0x20
setting vt8235
Assigning IRQ 5 to 0:11.1
  Readback = 5
pci_level_irq: lower order bits are wrong: want 0x0, got 0x20
Assigning IRQ 9 to 0:11.5
  Readback = 9
pci_level_irq: lower order bits are wrong: want 0x0, got 0x20
setting ethernet
Assigning IRQ 5 to 0:12.0
  Readback = 5
pci_level_irq: lower order bits are wrong: want 0x0, got 0x20
setting vga
Assigning IRQ 5 to 1:0.0
  Readback = 5
pci_level_irq: lower order bits are wrong: want 0x0, got 0x20
setting pci slot
setting cardbus slot
setting riser slot
PNP: 002e.1 init
PNP: 002e.2 init
PNP: 002e.3 init
PNP: 002e.b init
PCI: 00:11.1 init
Enabling VIA IDE.
ide_init: enabling compatibility IDE addresses
enables in reg 0x42 0x0
enables in reg 0x42 read back as 0x0
enables in reg 0x40 0x13
enables in reg 0x40 read back as 0x13
enables in reg 0x9 0x8a
enables in reg 0x9 read back as 0x8a
command in reg 0x4 0x7
command in reg 0x4 reads back as 0x7
PCI: 00:11.5 init
PCI: 00:12.0 init
Configuring VIA Rhine LAN
APIC_CLUSTER: 0 init
Initializing CPU #0
CPU: vendor Centaur device 673
Enabling cache

Setting fixed MTRRs(0-88) type: UC
Setting fixed MTRRs(0-16) Type: WB
Setting fixed MTRRs(24-88) Type: WB
DONE fixed MTRRs
Setting variable MTRR 0, base:    0MB, range:  128MB, type WB
Setting variable MTRR 1, base:  128MB, range:   64MB, type WB
Setting variable MTRR 2, base:  192MB, range:   32MB, type WB
DONE variable MTRRs
Clear out the extra MTRR's

MTRR check
Fixed MTRRs   : Enabled
Variable MTRRs: Enabled

Disabling local apic...done.
CPU #0 Initialized
PCI: 00:00.0 init
VT8623 random fixup ...
Frame buffer at d0000000
PCI: 00:01.0 init
VT8623 AGP random fixup ...
PCI: 01:00.0 init
VGA random fixup ...
INSTALL REAL-MODE IDT
DO THE VGA BIOS
found VGA: vid=1106, did=3122
rom base, size: fffc0000
write_protect_vgabios
bus/devfn = 0x100
biosint: INT# 0x15
biosint: eax 0x5f00 ebx 0x18538 ecx 0x17fa8 edx 0x12
biosint: ebp 0x17f84 esp 0xff2 edi 0xed10 esi 0xffff6f55
biosint:  ip 0x637f   cs 0xc000  flags 0x46
biosint: INT# 0x1a
biosint: eax 0xb108 ebx 0x10000 ecx 0x10000 edx 0x3d5
biosint: ebp 0x17f84 esp 0xfcc edi 0xf6 esi 0xffff55eb
biosint:  ip 0x40da   cs 0xc000  flags 0x46
0xb108: bus 0 devfn 0x0 reg 0xf6 val 0x12
biosint: INT# 0x15
biosint: eax 0x5f0f ebx 0x18538 ecx 0x7fa8 edx 0x3d5
biosint: ebp 0x17f84 esp 0xfee edi 0x44 esi 0xffff6f55
biosint:  ip 0x647e   cs 0xc000  flags 0x7
biosint: INT# 0x15
biosint: eax 0x5f02 ebx 0x18538 ecx 0x7f01 edx 0x3d5
biosint: ebp 0x17f84 esp 0xfdc edi 0x44 esi 0xffff6f55
biosint:  ip 0x63cb   cs 0xc000  flags 0x46
biosint: INT# 0x15
biosint: eax 0x5f18 ebx 0x18501 ecx 0x7fa8 edx 0x3d5
biosint: ebp 0x17f84 esp 0xfde edi 0x44 esi 0xffff6f55
biosint:  ip 0x6496   cs 0xc000  flags 0x46
biosint: INT# 0x15
biosint: eax 0x5f06 ebx 0x18001 ecx 0x1 edx 0x0
biosint: ebp 0x10fd6 esp 0xfa4 edi 0x0 esi 0xffff4672
biosint:  ip 0x63dc   cs 0xc000  flags 0x246
biosint: INT# 0x15
biosint: eax 0x5f08 ebx 0x10d01 ecx 0x8301 edx 0xd4
biosint: ebp 0x10fd6 esp 0xfa4 edi 0x0 esi 0xffff0d0e
biosint:  ip 0x63e8   cs 0xc000  flags 0x246
PNP: 002e.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.
ACPI: Writing ACPI tables at f0400...
ACPI:     * FACS
ACPI:     * DSDT @ 000f049e Length 3f0
ACPI:     * FADT
ACPI: added table 1/5 Length now 40
ACPI: done.
Moving GDT to 0x500...ok
Wrote linuxbios table at: 00000530 - 00000b80  checksum e5ca

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

    33:stream_init() - rom_stream: 0xfffd0000 - 0xfffeffff
Found ELF candiate at offset 0
New segment addr 0x100000 size 0x204a0 offset 0xc0 filesize 0x6508
(cleaned up) New segment addr 0x100000 size 0x204a0 offset 0xc0 filesize 
0x6508
New segment addr 0x1204a0 size 0x48 offset 0x65e0 filesize 0x48
(cleaned up) New segment addr 0x1204a0 size 0x48 offset 0x65e0 filesize 0x48
Dropping non PT_LOAD segment
Dropping non PT_LOAD segment
Loading Segment: addr: 0x0000000000100000 memsz: 0x00000000000204a0 
filesz: 0x0000000000006508
Clearing Segment: addr: 0x0000000000106508 memsz: 0x0000000000019f98
Loading Segment: addr: 0x00000000001204a0 memsz: 0x0000000000000048 
filesz: 0x0000000000000048
Jumping to boot code at 0x10480c
FILO version 0.4.2 (root at embedded) Fri May  5 19:02:14 PDT 2006
Press <Enter> for default boot, or <Esc> for boot prompt... 1 
boot: hda1:/boot/vmlinuz root=/dev/hda1 console=tty0 lpj=2136847 
dhash_entries=4000 ide0=0x1f0,0x3f6,14 ide0=noprobe ide1=noprobe  
ide2=noprobe ide3=noprobe ide4=noprobe ide5=noprobe hda=65535,16,63 
hdb=none hdc=noprobe hdd=none no_hlt console=ttyS0,115200
hda: LBA 80GB: WDC WD800JB-00FMA0                     
Mounted ext2fs
Found Linux version 2.6.16.5 (root at ep) #4 Wed Apr 26 09:34:01 PDT 2006 
bzImage.
Loading kernel... ok
Jumping to entry point...
[00000.00000] Linux version 2.6.16.5 (root at ep) (gcc version 3.4.5 
20050809 (prerelease) (Ubuntu 3.4.4-6ubuntu8.1)) #4 Wed Apr 26 09:34:01 
PDT 2006
[00000.00000] BIOS-provided physical RAM map:
[00000.00000]  BIOS-e820: 0000000000000be0 - 00000000000a0000 (usable)
[00000.00000]  BIOS-e820: 0000000000100000 - 000000000e000000 (usable)
[00000.00000] 0MB HIGHMEM available.
[00000.00000] 224MB LOWMEM available.
[00000.00000] DMI not present or invalid.
[00000.00000] ACPI: PM-Timer IO Port: 0x408
[00000.00000] Allocating PCI resources starting at 10000000 (gap: 
0e000000:f2000000)
[00000.00000] Built 1 zonelists
[00000.00000] Kernel command line: root=/dev/hda1 console=tty0 
lpj=2136847 dhash_entries=4000 ide0=0x1f0,0x3f6,14 ide0=noprobe 
ide1=noprobe ide2=noprobe ide3=noprobe ide4=noprobe ide5=noprobe 
hda=65535,16,63 hdb=none hdc=noprobe hdd=none no_hlt console=ttyS0,115200
[00000.00000] ide_setup: ide0=0x1f0,0x3f6,14
[00000.00000]  -- OBSOLETE OPTION, WILL BE REMOVED SOON!
[00000.00000] ide_setup: ide0=noprobe
[00000.00000] ide_setup: ide1=noprobe
[00000.00000] ide_setup: ide2=noprobe
[00000.00000] ide_setup: ide3=noprobe
[00000.00000] ide_setup: ide4=noprobe
[00000.00000] ide_setup: ide5=noprobe
[00000.00000] ide_setup: hda=65535,16,63
[00000.00000] ide_setup: hdb=none
[00000.00000] ide_setup: hdc=noprobe
[00000.00000] ide_setup: hdd=none
[00000.00000] No local APIC present or hardware disabled
[00000.00000] Initializing CPU#0
[00000.00000] PID hash table entries: 1024 (order: 10, 16384 bytes)
[00000.00000] Detected 533.151 MHz processor.
[00000.00000] Using pmtmr for high-res timesource
[00000.00000] Console: colour VGA+ 80x25
[00000.00000] Dentry cache hash table entries: 4096 (order: 2, 16384 bytes)
[00000.00000] Inode-cache hash table entries: 16384 (order: 4, 65536 bytes)
[00000.00000] Memory: 224128k/229376k available (1666k kernel code, 
4848k reserved, 622k data, 148k init, 0k highmem)
[00000.00000] Checking if this processor honours the WP bit even in 
supervisor mode... Ok.
[00000.00000] Calibrating delay loop (skipped)... 1068.42 BogoMIPS preset
[00000.00000] Security Framework v1.0.0 initialized
[00000.00000] SELinux:  Disabled at boot.
[00000.00000] Mount-cache hash table entries: 512
[00000.00000] CPU: L1 I Cache: 64K (32 bytes/line), D cache 64K (32 
bytes/line)
[00000.00000] CPU: L2 Cache: 64K (32 bytes/line)
[00000.00000] CPU: Centaur VIA Samuel 2 stepping 03
[00000.00000] Checking 'hlt' instruction... OK.
[00000.00000] ACPI: setting ELCR to 0020 (from 0220)
[00000.00000] NET: Registered protocol family 16
[00000.00000] ACPI: bus type pci registered
[00000.00000] PCI: PCI BIOS revision 2.10 entry at 0xfa960, last bus=1
[00000.00000] PCI: Using configuration type 1
[00000.00000] ACPI: Subsystem revision 20060127
[00000.00000] ACPI: Interpreter enabled
[00000.00000] ACPI: Using PIC for interrupt routing
[00000.00000] ACPI: PCI Interrupt Link [LNKA] (IRQs *5 9 10)
[00000.00000] ACPI: PCI Interrupt Link [LNKB] (IRQs 5 *9 10)
[00000.00000] ACPI: PCI Interrupt Link [LNKC] (IRQs 5 *9 10)
[00000.00000] ACPI: PCI Interrupt Link [LNKD] (IRQs *5 9 10)
[00000.00000] ACPI: PCI Root Bridge [PCI0] (0000:00)
[00000.00000] PCI quirk: region 0400-047f claimed by vt8235 PM
[00000.00000] PCI quirk: region 0f00-0f0f claimed by vt8235 SMB
[00000.00000] Linux Plug and Play Support v0.97 (c) Adam Belay
[00000.00000] pnp: PnP ACPI init
[00000.00000] pnp: PnP ACPI: found 0 devices
[00000.00000] usbcore: registered new driver usbfs
[00000.00000] usbcore: registered new driver hub
[00000.00000] PCI: Using ACPI for IRQ routing
[00000.00000] PCI: If a device doesn't work, try "pci=routeirq".  If it 
helps, post a report
[00000.00000] PCI: Bridge: 0000:00:01.0
[00000.00000]   IO window: disabled.
[00000.00000]   MEM window: dc000000-ddffffff
[00000.00000]   PREFETCH window: d8000000-dbffffff
[00000.00000] audit: initializing netlink socket (disabled)
[00000.00000] audit(1146895449.196:1): initialized
[00000.00000] VFS: Disk quotas dquot_6.5.1
[00000.00000] Dquot-cache hash table entries: 1024 (order 0, 4096 bytes)
[00000.00000] Initializing Cryptographic API
[00000.00000] io scheduler noop registered
[00000.00000] io scheduler anticipatory registered (default)
[00000.00000] io scheduler deadline registered
[00000.00000] io scheduler cfq registered
[00000.00000] PNP: No PS/2 controller found. Probing ports directly.
[00000.00000] serio: i8042 AUX port at 0x60,0x64 irq 12
[00000.00000] serio: i8042 KBD port at 0x60,0x64 irq 1
[00000.00000] Serial: 8250/16550 driver $Revision: 1.90 $ 4 ports, IRQ 
sharing enabled
[00000.00000] serial8250: ttyS0 at I/O 0x3f8 (irq = 4) is a 16550A
[00000.00000] serial8250: ttyS1 at I/O 0x2f8 (irq = 3) is a 16550A
[00000.00000] RAMDISK driver initialized: 16 RAM disks of 65536K size 
1024 blocksize
[00000.00000] Uniform Multi-Platform E-IDE driver Revision: 7.00alpha2
[00000.00000] ide: Assuming 33MHz system bus speed for PIO modes; 
override with idebus=xx
[00000.00000] VP_IDE: IDE controller at PCI slot 0000:00:11.1
[00000.00000] ACPI: PCI Interrupt Link [LNKA] enabled at IRQ 5
[00000.00000] ACPI: PCI Interrupt 0000:00:11.1[A] -> Link [LNKA] -> GSI 
5 (level, low) -> IRQ 5
[00000.00000] VP_IDE: chipset revision 6
[00000.00000] VP_IDE: not 100% native mode: will probe irqs later
[00000.00000] VP_IDE: VIA vt8235 (rev 00) IDE UDMA133 controller on 
pci0000:00:11.1
[00000.00000]     ide0: BM-DMA at 0x1860-0x1867, BIOS settings: hda:pio, 
hdb:pio
[00000.00000]     ide1: BM-DMA at 0x1868-0x186f, BIOS settings: hdc:pio, 
hdd:pio
[00000.00000] hda: WDC WD800JB-00FMA0, ATA DISK drive
[00000.00000] ide0 at 0x1f0-0x1f7,0x3f6 on irq 14
[00000.00000] hda: max request size: 128KiB
[00000.00000] hda: 156301488 sectors (80026 MB) w/8192KiB Cache, 
CHS=65535/16/63, UDMA(33)
[00000.00000] hda: cache flushes supported
[00000.00000]  hda: hda1 hda2 < hda5 >
[00000.00000] usbmon: debugfs is not available
[00000.00000] NET: Registered protocol family 2
[00000.00000] IP route cache hash table entries: 2048 (order: 1, 8192 bytes)
[00000.00000] TCP established hash table entries: 8192 (order: 3, 32768 
bytes)
[00000.00000] TCP bind hash table entries: 8192 (order: 3, 32768 bytes)
[00000.00000] TCP: Hash tables configured (established 8192 bind 8192)
[00000.00000] TCP reno registered
[00000.00000] TCP bic registered
[00000.00000] NET: Registered protocol family 8
[00000.00000] NET: Registered protocol family 20
[00000.00000] Using IPI Shortcut mode
[00000.00000] ACPI wakeup devices:
[00000.00000]
[00000.00000] ACPI: (supports S0 S5)
[00000.00000] EXT2-fs warning (device hda1): ext2_fill_super: mounting 
ext3 filesystem as ext2
[00000.00000] VFS: Mounted root (ext2 filesystem) readonly.
[00000.00000] Freeing unused kernel memory: 148k freed
[00000.00000] input: AT Translated Set 2 keyboard as /class/input/input0
 * version 2.86 booting
[17179573.668000] NET: Registered protocol family 1
 * Starting hardware event daemon...        [ ok ]
 * Mounting a tmpfs over /dev...        [ ok ]
 * Creating initial device nodes...        [ ok ]
 * Setting disc parameters...        [ ok ]
[17179580.708000] Adding 746980k swap on /dev/hda5.  Priority:-1 
extents:1 across:746980k
 * Checking root file system...        /: clean, 123856/9682944 files, 
838361/19350284 blocks
[ ok ]
 * Initializing modules...        [ ok ]
 * Cleaning up ifupdown...        [ ok ]
 * Calculating module dependencies...        [ ok ]
 * Loading modules...        [17179582.652000] parport0: PC-style at 
0x378 (0x778) [PCSPP,TRISTATE]
[17179582.784000] parport0: irq 7 detected
[17179582.904000] lp0: using parport0 (polling).
[17179583.060000] mice: PS/2 mouse device common for all mice
[ ok ]
 * Setting the system clock...        [ ok ]
 * Setting up LVM Volume Groups...        [ ok ]
[ ok ]
 * Starting Enterprise Volume Management System...        [ ok ]
 * Checking all file systems...        [ ok ]
 * Mounting local filesystems...        [ ok ]
 * Restoring resolver state...        [ ok ]
 * Setting up networking...        [ ok ]
 * Reading desktop files...        [ ok ]
 * Starting hotplug subsystem...       

----------------
Full Text, Crash
----------------

0

LinuxBIOS-1.1.8.0Fallback Thu May  4 18:03:52 PDT 2006 starting...
 Enabling mainboard devices
 Enabling shadow ram
vt8623 init starting
Detecting Memory
Number of Banks 04
Number of Rows 0d
Priamry DRAM width08
No Columns 0a
MA type e0
Bank 0 (*16 Mb) 10
No Physical Banks 01
Total Memory (*16 Mb) 10
CAS Supported 2 2.5 3
Cycle time at CL X     (nS)50
Cycle time at CL X-0.5 (nS)60
Cycle time at CL X-1   (nS)75
Starting at CAS 3
We can do CAS 2.5
We can do CAS 2
tRP 48
tRCD 48
tRAS 28
Low Bond 00  High Bondc0  Setting DQS delay80vt8623 done
00:06 11 23 31 06 00 30 22 00 00 00 06 00 00 00 00 
10:08 00 00 d0 00 00 00 00 00 00 00 00 00 00 00 00 
20:00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
30:00 00 00 00 a0 00 00 00 00 00 00 00 00 00 00 00 
40:00 18 88 80 82 44 00 00 18 99 88 80 82 44 00 00 
50:c8 de cf 88 e0 07 00 00 e0 00 10 10 10 10 00 00 
60:02 ff 00 30 d6 32 01 2a 42 2d 43 58 00 44 00 00 
70:82 48 00 01 01 08 50 00 01 00 00 00 00 00 02 02 
80:0f 65 00 00 80 00 00 00 02 00 00 00 00 00 00 00 
90:00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
a0:02 c0 20 00 07 02 00 1f 04 00 00 00 2f 02 04 00 
b0:00 00 00 00 80 00 00 00 88 00 00 00 00 00 00 00 
c0:01 00 02 00 00 00 00 00 00 00 00 00 00 00 00 00 
d0:00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
e0:00 dd 00 00 00 00 01 00 40 00 00 00 00 00 00 00 
f0:00 00 00 00 00 00 12 13 00 00 00 00 00 00 00 00 
AGP
 Doing MTRR init.
Copying LinuxBIOS to ram.
Jumping to LinuxBIOS.
LinuxBIOS-1.1.8.0Fallback Fri May  5 19:03:15 PDT 2006 booting...
clocks_per_usec: 838
Enumerating buses...
Finding PCI configuration type.
PCI: Using configuration type 1
PCI_DOMAIN: 0000 enabled
APIC_CLUSTER: 0 enabled
PCI: pci_scan_bus for bus 0
PCI: 00:00.0 [1106/3123] enabled
PCI: 00:01.0 [1106/b091] enabled
In vt8235_enable 1106 3038.
PCI: 00:10.0 [1106/3038] enabled
In vt8235_enable 1106 3038.
PCI: 00:10.1 [1106/3038] enabled
In vt8235_enable 1106 3038.
PCI: 00:10.2 [1106/3038] enabled
In vt8235_enable 1106 3104.
PCI: 00:10.3 [1106/3104] enabled
In vt8235_enable 1106 3177.
Initialising Devices
PCI: 00:11.0 [1106/3177] enabled
In vt8235_enable 1106 0571.
PCI: 00:11.1 [1106/0571] enabled
In vt8235_enable 1106 3059.
PCI: 00:11.5 [1106/3059] enabled
In vt8235_enable ffff ffff.
In vt8235_enable 1106 3065.
PCI: 00:12.0 [1106/3065] enabled
PCI: pci_scan_bus for bus 1
PCI: 01:00.0 [1106/3122] enabled
PCI: pci_scan_bus returning with max=01
vt1211 enabling PNP devices.
PNP: 002e.1 enabled
vt1211 enabling PNP devices.
PNP: 002e.2 enabled
vt1211 enabling PNP devices.
PNP: 002e.3 enabled
vt1211 enabling PNP devices.
PNP: 002e.b enabled
PNP: 002e.0 enabled
PCI: pci_scan_bus returning with max=01
done
Allocating resources...
Reading resources...
Done reading resources.
Setting resources...
I would set ram size to 0x40000 Kbytes
PCI: 00:10.0 20 <- [0x0000001800 - 0x000000181f] io
PCI: 00:10.1 20 <- [0x0000001820 - 0x000000183f] io
PCI: 00:10.2 20 <- [0x0000001840 - 0x000000185f] io
PCI: 00:10.3 10 <- [0x00febff000 - 0x00febff0ff] mem
PNP: 002e.1 60 <- [0x0000000378 - 0x000000037f] io
PNP: 002e.1 70 <- [0x0000000007 - 0x0000000007] irq
PNP: 002e.1 74 <- [0x0000000003 - 0x0000000003] drq
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
PNP: 002e.b 60 <- [0x000000ec00 - 0x000000ecff] io
ERROR: PNP: 002e.0 60 io size: 0x0000000008 not assigned
ERROR: PNP: 002e.0 60 irq size: 0x0000000001 not assigned
ERROR: PNP: 002e.0 60 drq size: 0x0000000001 not assigned
PCI: 00:11.1 20 <- [0x0000001860 - 0x000000186f] io
PCI: 00:11.5 10 <- [0x0000001000 - 0x00000010ff] io
PCI: 00:12.0 10 <- [0x0000001400 - 0x00000014ff] io
PCI: 00:12.0 14 <- [0x00fec00000 - 0x00fec000ff] mem
Done setting resources.
Done allocating resources.
Enabling resources...
PCI: 00:00.0 cmd <- 146
PCI: 00:01.0 bridge ctrl <- 000f
PCI: 00:01.0 cmd <- 147
PCI: 01:00.0 cmd <- 140
PCI: 00:10.0 subsystem <- 00/00
PCI: 00:10.0 cmd <- 141
PCI: 00:10.1 subsystem <- 00/00
PCI: 00:10.1 cmd <- 141
PCI: 00:10.2 subsystem <- 00/00
PCI: 00:10.2 cmd <- 141
PCI: 00:10.3 subsystem <- 00/00
PCI: 00:10.3 cmd <- 142
PCI: 00:11.0 cmd <- 147
PNP: 002e.1 - enabling
PNP: 002e.2 - enabling
PNP: 002e.3 - enabling
PNP: 002e.b - enabling
PNP: 002e.0 - enabling
PCI: 00:11.1 cmd <- 147
PCI: 00:11.5 subsystem <- 00/00
PCI: 00:11.5 cmd <- 141
PCI: 00:12.0 cmd <- 1c3
done.
Initializing devices...
Root Device init
PCI: 00:10.0 init
PCI: 00:10.1 init
PCI: 00:10.2 init
PCI: 00:10.3 init
PCI: 00:11.0 init
vt8235 init
RTC Init
Invalid CMOS LB checksum
pci_routing_fixup: dev is 000107c0
setting firewire
setting usb
Assigning IRQ 5 to 0:10.0
  Readback = 5
pci_level_irq: lower order bits are wrong: want 0x0, got 0x20
Assigning IRQ 9 to 0:10.1
  Readback = 9
pci_level_irq: lower order bits are wrong: want 0x0, got 0x20
Assigning IRQ 9 to 0:10.2
  Readback = 9
pci_level_irq: lower order bits are wrong: want 0x0, got 0x20
Assigning IRQ 5 to 0:10.3
  Readback = 5
pci_level_irq: lower order bits are wrong: want 0x0, got 0x20
setting vt8235
Assigning IRQ 5 to 0:11.1
  Readback = 5
pci_level_irq: lower order bits are wrong: want 0x0, got 0x20
Assigning IRQ 9 to 0:11.5
  Readback = 9
pci_level_irq: lower order bits are wrong: want 0x0, got 0x20
setting ethernet
Assigning IRQ 5 to 0:12.0
  Readback = 5
pci_level_irq: lower order bits are wrong: want 0x0, got 0x20
setting vga
Assigning IRQ 5 to 1:0.0
  Readback = 5
pci_level_irq: lower order bits are wrong: want 0x0, got 0x20
setting pci slot
setting cardbus slot
setting riser slot
PNP: 002e.1 init
PNP: 002e.2 init
PNP: 002e.3 init
PNP: 002e.b init
PCI: 00:11.1 init
Enabling VIA IDE.
ide_init: enabling compatibility IDE addresses
enables in reg 0x42 0x0
enables in reg 0x42 read back as 0x0
enables in reg 0x40 0x13
enables in reg 0x40 read back as 0x13
enables in reg 0x9 0x8a
enables in reg 0x9 read back as 0x8a
command in reg 0x4 0x7
command in reg 0x4 reads back as 0x7
PCI: 00:11.5 init
PCI: 00:12.0 init
Configuring VIA Rhine LAN
APIC_CLUSTER: 0 init
Initializing CPU #0
CPU: vendor Centaur device 673
Enabling cache

Setting fixed MTRRs(0-88) type: UC
Setting fixed MTRRs(0-16) Type: WB
Setting fixed MTRRs(24-88) Type: WB
DONE fixed MTRRs
Setting variable MTRR 0, base:    0MB, range:  128MB, type WB
Setting variable MTRR 1, base:  128MB, range:   64MB, type WB
Setting variable MTRR 2, base:  192MB, range:   32MB, type WB
DONE variable MTRRs
Clear out the extra MTRR's

MTRR check
Fixed MTRRs   : Enabled
Variable MTRRs: Enabled

Disabling local apic...done.
CPU #0 Initialized
PCI: 00:00.0 init
VT8623 random fixup ...
Frame buffer at d0000000
PCI: 00:01.0 init
VT8623 AGP random fixup ...
PCI: 01:00.0 init
VGA random fixup ...
INSTALL REAL-MODE IDT
DO THE VGA BIOS
found VGA: vid=1106, did=3122
rom base, size: fffc0000
write_protect_vgabios
bus/devfn = 0x100
biosint: INT# 0x15
biosint: eax 0x5f00 ebx 0x18538 ecx 0x17fa8 edx 0x12
biosint: ebp 0x17f84 esp 0xff2 edi 0xed10 esi 0xffff6f55
biosint:  ip 0x637f   cs 0xc000  flags 0x46
biosint: INT# 0x1a
biosint: eax 0xb108 ebx 0x10000 ecx 0x10000 edx 0x3d5
biosint: ebp 0x17f84 esp 0xfcc edi 0xf6 esi 0xffff55eb
biosint:  ip 0x40da   cs 0xc000  flags 0x46
0xb108: bus 0 devfn 0x0 reg 0xf6 val 0x12
biosint: INT# 0x15
biosint: eax 0x5f0f ebx 0x18538 ecx 0x7fa8 edx 0x3d5
biosint: ebp 0x17f84 esp 0xfee edi 0x44 esi 0xffff6f55
biosint:  ip 0x647e   cs 0xc000  flags 0x7
biosint: INT# 0x15
biosint: eax 0x5f02 ebx 0x18538 ecx 0x7f01 edx 0x3d5
biosint: ebp 0x17f84 esp 0xfdc edi 0x44 esi 0xffff6f55
biosint:  ip 0x63cb   cs 0xc000  flags 0x46
biosint: INT# 0x15
biosint: eax 0x5f18 ebx 0x18501 ecx 0x7fa8 edx 0x3d5
biosint: ebp 0x17f84 esp 0xfde edi 0x44 esi 0xffff6f55
biosint:  ip 0x6496   cs 0xc000  flags 0x46
biosint: INT# 0x15
biosint: eax 0x5f06 ebx 0x18001 ecx 0x1 edx 0x0
biosint: ebp 0x10fd6 esp 0xfa4 edi 0x0 esi 0xffff4672
biosint:  ip 0x63dc   cs 0xc000  flags 0x246
biosint: INT# 0x15
biosint: eax 0x5f08 ebx 0x10d01 ecx 0x8301 edx 0xd4
biosint: ebp 0x10fd6 esp 0xfa4 edi 0x0 esi 0xffff0d0e
biosint:  ip 0x63e8   cs 0xc000  flags 0x246
PNP: 002e.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.
ACPI: Writing ACPI tables at f0400...
ACPI:     * FACS
ACPI:     * DSDT @ 000f049e Length 3f0
ACPI:     * FADT
ACPI: added table 1/5 Length now 40
ACPI: done.
Moving GDT to 0x500...ok
Wrote linuxbios table at: 00000530 - 00000b80  checksum e5ca

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

    33:stream_init() - rom_stream: 0xfffd0000 - 0xfffeffff
Found ELF candiate at offset 0
New segment addr 0x100000 size 0x204a0 offset 0xc0 filesize 0x6508
(cleaned up) New segment addr 0x100000 size 0x204a0 offset 0xc0 filesize 0x6508
New segment addr 0x1204a0 size 0x48 offset 0x65e0 filesize 0x48
(cleaned up) New segment addr 0x1204a0 size 0x48 offset 0x65e0 filesize 0x48
Dropping non PT_LOAD segment
Dropping non PT_LOAD segment
Loading Segment: addr: 0x0000000000100000 memsz: 0x00000000000204a0 filesz: 0x0000000000006508
Clearing Segment: addr: 0x0000000000106508 memsz: 0x0000000000019f98
Loading Segment: addr: 0x00000000001204a0 memsz: 0x0000000000000048 filesz: 0x0000000000000048
Jumping to boot code at 0x10480c
FILO version 0.4.2 (root at embedded) Fri May  5 19:02:14 PDT 2006
Press <Enter> for default boot, or <Esc> for boot prompt... 1 
boot: hda1:/boot/vmlinuz root=/dev/hda1 console=tty0 lpj=2136847 dhash_entries=4000 ide0=0x1f0,0x3f6,14 ide0=noprobe ide1=noprobe  ide2=noprobe ide3=noprobe ide4=noprobe ide5=noprobe hda=65535,16,63 hdb=none hdc=noprobe hdd=none no_hlt  console=ttyS0,115200
hda: LBA 80GB: WDC WD800JB-00FMA0                      
Mounted ext2fs
Found Linux version 2.6.16.5 (root at ep) #4 Wed Apr 26 09:34:01 PDT 2006 bzImage.
Loading kernel... ok
Jumping to entry point...
[00000.00000] Linux version 2.6.16.5 (root at ep) (gcc version 3.4.5 20050809 (prerelease) (Ubuntu 3.4.4-6ubuntu8.1)) #4 Wed Apr 26 09:34:01 PDT 2006
[00000.00000] BIOS-provided physical RAM map:
[00000.00000]  BIOS-e820: 0000000000000be0 - 00000000000a0000 (usable)
[00000.00000]  BIOS-e820: 0000000000100000 - 000000000e000000 (usable)
[00000.00000] 0MB HIGHMEM available.
[00000.00000] 224MB LOWMEM available.
[00000.00000] DMI 2.2 present.
[00000.00000] ACPI: PM-Timer IO Port: 0x408
[00000.00000] Allocating PCI resources starting at 10000000 (gap: 0e000000:f2000000)
[00000.00000] Built 1 zonelists
[00000.00000] Kernel command line: root=/dev/hda1 console=tty0 lpj=2136847 dhash_entries=4000 ide0=0x1f0,0x3f6,14 ide0=noprobe ide1=noprobe ide2=noprobe ide3=noprobe ide4=noprobe ide5=noprobe hda=65535,16,63 hdb=none hdc=noprobe hdd=none no_hlt console=ttyS0,115200
[00000.00000] ide_setup: ide0=0x1f0,0x3f6,14
[00000.00000]  -- OBSOLETE OPTION, WILL BE REMOVED SOON!
[00000.00000] ide_setup: ide0=noprobe
[00000.00000] ide_setup: ide1=noprobe
[00000.00000] ide_setup: ide2=noprobe
[00000.00000] ide_setup: ide3=noprobe
[00000.00000] ide_setup: ide4=noprobe
[00000.00000] ide_setup: ide5=noprobe
[00000.00000] ide_setup: hda=65535,16,63
[00000.00000] ide_setup: hdb=none
[00000.00000] ide_setup: hdc=noprobe
[00000.00000] ide_setup: hdd=none
[00000.00000] No local APIC present or hardware disabled
[00000.00000] Initializing CPU#0
[00000.00000] PID hash table entries: 1024 (order: 10, 16384 bytes)
[00000.00000] Detected 533.151 MHz processor.
[00000.00000] Using pmtmr for high-res timesource
[00000.00000] Console: colour VGA+ 80x25
[00000.00000] Dentry cache hash table entries: 4096 (order: 2, 16384 bytes)
[00000.00000] Inode-cache hash table entries: 16384 (order: 4, 65536 bytes)
[00000.00000] Memory: 224128k/229376k available (1666k kernel code, 4848k reserved, 622k data, 148k init, 0k highmem)
[00000.00000] Checking if this processor honours the WP bit even in supervisor mode... Ok.
[00000.00000] Calibrating delay loop (skipped)... 1068.42 BogoMIPS preset
[00000.00000] Security Framework v1.0.0 initialized
[00000.00000] SELinux:  Disabled at boot.
[00000.00000] Mount-cache hash table entries: 512
[00000.00000] CPU: L1 I Cache: 64K (32 bytes/line), D cache 64K (32 bytes/line)
[00000.00000] CPU: L2 Cache: 64K (32 bytes/line)
[00000.00000] CPU: Centaur VIA Samuel 2 stepping 03
[00000.00000] Checking 'hlt' instruction... OK.
[00000.00000] ACPI: setting ELCR to 0020 (from 0220)
[00000.00000] NET: Registered protocol family 16
[00000.00000] ACPI: bus type pci registered
[00000.00000] PCI: PCI BIOS revision 2.10 entry at 0xfa960, last bus=1
[00000.00000] PCI: Using configuration type 1
[00000.00000] ACPI: Subsystem revision 20060127
[00000.00000] ACPI: Interpreter enabled
[00000.00000] ACPI: Using PIC for interrupt routing
[00000.00000] ACPI: PCI Interrupt Link [LNKA] (IRQs *5 9 10)
[00000.00000] ACPI: PCI Interrupt Link [LNKB] (IRQs 5 *9 10)
[00000.00000] ACPI: PCI Interrupt Link [LNKC] (IRQs 5 *9 10)
[00000.00000] ACPI: PCI Interrupt Link [LNKD] (IRQs *5 9 10)
[00000.00000] ACPI: PCI Root Bridge [PCI0] (0000:00)
[00000.00000] PCI quirk: region 0400-047f claimed by vt8235 PM
[00000.00000] PCI quirk: region 0f00-0f0f claimed by vt8235 SMB
[00000.00000] Linux Plug and Play Support v0.97 (c) Adam Belay
[00000.00000] pnp: PnP ACPI init
[00000.00000] pnp: PnP ACPI: found 0 devices
[00000.00000] usbcore: registered new driver usbfs
[00000.00000] usbcore: registered new driver hub
[00000.00000] PCI: Using ACPI for IRQ routing
[00000.00000] PCI: If a device doesn't work, try "pci=routeirq".  If it helps, post a report
[00000.00000] general protection fault: 3120 [#1]
[00000.00000] Modules linked in:
[00000.00000] CPU:    0
[00000.00000] EIP:    0060:[<c00faa2c>]    Not tainted VLI
[00000.00000] EFLAGS: 00010013   (2.6.16.5 #4) 
[00000.00000] EIP is at 0xc00faa2c
[00000.00000] eax: 0000b102   ebx: c13f7400   ecx: 00003123   edx: 00001106
[00000.00000] esi: 00000000   edi: c03016cc   ebp: 00000000   esp: c11fff76
[00000.00000] ds: 007b   es: 007b   ss: 0068
[00000.00000] Process swapper (pid: 1, threadinfo=c11fe000 task=c11fba70)
[00000.00000] Stack: <0>31230000 c03016cc c00fa97c 0000b102 00001106 072c0246 0060c024 74000000 
[00000.00000]        0000c13f 00000000 09fb0000 1106c024 31230000 00000000 ffba0000 ffbbc11f 
[00000.00000]        0000c11f ffbc0000 ffbcc11f 1274c11f 0000c036 00000000 7d150000 06fbc035 
[00000.00000] Call Trace:
[00000.00000] Code: cb 87 db b4 81 f9 c3 e8 aa 03 00 00 ba 50 43 49 20 66 b8 11 00 66 bb 10 02 f8 c3 57 66 51 66 56 66 83 fa ff 75 05 b4 83 f9 eb 53 <66> cb f9 c1 e7 10 66 8b fa e8 7d 03 00 00 8a d9 32 ff 32 ed 80 
[00000.00000]  <0>Kernel panic - not syncing: Attempted to kill init!
[00000.00000]  





From bios at lists.actweb.info  Sat May  6 10:05:12 2006
From: bios at lists.actweb.info (Matt)
Date: Sat,  6 May 2006 09:05:12 +0100 (BST)
Subject: [LinuxBIOS] Can anyone confirm if linuxbios works on EPIA PD10000?
Message-ID: <1146902712.12651@actweb.info>

Hi
Im new to the list, so apoligise if this has been asked before :(
I use the EPIA PD10000 boards for various projects and would like to use linux bios on the boards, the PD range is not listed on the site, so i thought id ask here :)
I understand that video can be a problem with the EPIA boards but all i realy want is a serial output :)

The PD10000 board has the following chipsets :-
# Processor   	VIA C3?/ VIA Eden? EBGA processor
# Chipset 	VIA CLE266 North Bridge
# VIA VT8235 South Bridge
# System Memory 	1 DDR266 DIMM socket
# Up to 1GB memory size
# VGA 	Integrated VIA UniChrome? AGP graphics with MPEG-2 Accelerator
# Expansion Slots 	1 PCI
# Onboard IDE 	2 X UltraDMA 133/100/66 Connector
# Onboard LAN 	VIA VT6105 LOM+VT6103 10/100 Base-T Ethernet PHY
# Onboard Audio 	VIA VT1612A 2 channel AC' 97 codec
# Award BIOS
# 2/4Mbit flash memory
# CPU voltage monitoring
# Wake-on-LAN, Keyboard Power-on, Timer Power-on
# System power management
# AC power failure recovery
(data taken from VIA website : http://www.via.com.tw/en/products/mainboards/mini_itx/epia_pd/)

as i use these boards mainly as routers, all i realy need functioning is the IDE and LAN, and serial access (VERY basic 80x40 video text output might be nice thow :) )
the only other thing might be to have the audio working and the pci slot, as i have used these boards in the past for Asterisk PBX sytsem.

Again, if this has been asked before im sorry

any help would be great


Yours


Matt

From chris at suehsi.de  Sat May  6 13:24:30 2006
From: chris at suehsi.de (=?windows-1252?Q?Christian_S=FChs?=)
Date: Sat, 06 May 2006 13:24:30 +0200
Subject: [LinuxBIOS] Can anyone confirm if linuxbios works on EPIA
	PD10000?
In-Reply-To: <1146902712.12651@actweb.info>
References: <1146902712.12651@actweb.info>
Message-ID: <445C876E.7060402@suehsi.de>

Matt schrieb:
> Hi
> Im new to the list, so apoligise if this has been asked before :(
> I use the EPIA PD10000 boards for various projects and would like to use linux bios on the boards, the PD range is not listed on the site, so i thought id ask here :)
> I understand that video can be a problem with the EPIA boards but all i realy want is a serial output :)
>

Should work with epia-m as target, its almost the same hardware.

> The PD10000 board has the following chipsets :-
> # Processor   	VIA C3?/ VIA Eden? EBGA processor
> # Chipset 	VIA CLE266 North Bridge
> # VIA VT8235 South Bridge
> # System Memory 	1 DDR266 DIMM socket
> # Up to 1GB memory size
> # VGA 	Integrated VIA UniChrome? AGP graphics with MPEG-2 Accelerator
> # Expansion Slots 	1 PCI
> # Onboard IDE 	2 X UltraDMA 133/100/66 Connector
> # Onboard LAN 	VIA VT6105 LOM+VT6103 10/100 Base-T Ethernet PHY
> # Onboard Audio 	VIA VT1612A 2 channel AC' 97 codec
> # Award BIOS
> # 2/4Mbit flash memory
> # CPU voltage monitoring
> # Wake-on-LAN, Keyboard Power-on, Timer Power-on
> # System power management
> # AC power failure recovery
> (data taken from VIA website : http://www.via.com.tw/en/products/mainboards/mini_itx/epia_pd/)
> 


> 





From stepan at coresystems.de  Sat May  6 14:25:21 2006
From: stepan at coresystems.de (Stefan Reinauer)
Date: Sat, 6 May 2006 14:25:21 +0200
Subject: [LinuxBIOS] s2881 fan control
In-Reply-To: <20060505211923.GA22205@localdomain>
References: <6F7DA19D05F3CF40B890C7CA2DB13A4203094BD5@ssvlexmb2.amd.com>
	<20060505205717.GA20174@localdomain>
	<20060505211923.GA22205@localdomain>
Message-ID: <20060506122521.GA9586@coresystems.de>

* Ward Vandewege <ward at gnu.org> [060505 23:19]:
> > I can shut the machine down, do a cold boot into LinuxBIOS, and it still
> > works.
> > 
> > Until I unplug the power to the machine, that is.
> >   
> > After that, I can still read out everything (see attached
> > set_fan_speed_bad.txt) correctly, but now also _set_ the fan speed.
> 
> I'm sorry this is confusing. After unplugging and replugging the power to the
> machine, I need to boot the proprietary BIOS once to be able to set the fan
> speed on any consecutive (cold) boot. 

Can you do an lspci -xxx on the machine while running LinuxBIOS after a
cold boot

a) without factory bios running once before
b) with factory bios running once before

and diff them to see if there's something we can easily do. (ie. in the 
"ACPI bridge" device?)

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 stepan at coresystems.de  Sat May  6 14:29:28 2006
From: stepan at coresystems.de (Stefan Reinauer)
Date: Sat, 6 May 2006 14:29:28 +0200
Subject: [LinuxBIOS] [linuxbios-checkins] r2301 -
	trunk/LinuxBIOSv2/src/cpu/amd/model_gx2
In-Reply-To: <E1FcCwP-0007xK-FU@khepri.openbios.org>
References: <E1FcCwP-0007xK-FU@khepri.openbios.org>
Message-ID: <20060506122928.GA10512@coresystems.de>

* svn at openbios.org <svn at openbios.org> [060506 04:54]:
> Modified:
>    trunk/LinuxBIOSv2/src/cpu/amd/model_gx2/vsmsetup.c
> Log:
> Use a real variable to configure rom base for vsa ...
> 
> 
> Modified: trunk/LinuxBIOSv2/src/cpu/amd/model_gx2/vsmsetup.c
> ===================================================================
> --- trunk/LinuxBIOSv2/src/cpu/amd/model_gx2/vsmsetup.c	2006-05-06 02:35:08 UTC (rev 2300)
> +++ trunk/LinuxBIOSv2/src/cpu/amd/model_gx2/vsmsetup.c	2006-05-06 02:54:45 UTC (rev 2301)
> +	//rom = 0xfffc0000;
> +	/* the VSA starts at the base of rom - 128k */
> +	rom = ((unsigned long) 0) - (ROM_SIZE  + 128*1024);


dumb question:
Since this is in the CPU code and not motherboard specific, should this
be a config variable, in case someone uses different VSMs? Or are they
always 128k?

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 stepan at coresystems.de  Sat May  6 14:39:13 2006
From: stepan at coresystems.de (Stefan Reinauer)
Date: Sat, 6 May 2006 14:39:13 +0200
Subject: [LinuxBIOS] etherboot/filo + sata startup timing
In-Reply-To: <20060505213830.GA23965@localdomain>
References: <20060424220147.GA26709@io.pong.be> <444D4AED.3020805@lanl.gov>
	<20060424222144.GA17934@coresystems.de>
	<20060424222501.GC27028@io.pong.be>
	<20060428231617.GA28043@coresystems.de>
	<20060501155545.GA3652@io.pong.be>
	<20060505134709.GA2422@coresystems.de>
	<20060505213830.GA23965@localdomain>
Message-ID: <20060506123913.GA11451@coresystems.de>

* Ward Vandewege <ward at gnu.org> [060505 23:38]:
> I've tried this; the boot log is attached (minicom-20060505.cap) with
> DEBUG_PCI, DEBUG_IDE and DEBUG_LINUXBIOS enabled. Didn't help.
> 
> >  * if that doesnt help: try whether the disk is detected as hda instead
> >    of hde. This might happen with the current code.
> 
> I've tried that too, the bootlog is also attached (minicom-20060505-2.cap).
> Still no luck; though here it does seem to find the IDE controller. But not
> the drive...

Aha! It shows a floating IDE bus... Does anyone have an idea what's
wrong exactly if this shows up? It might just be an issue of waiting
just a little bit longer..

Sorry, what board was this again?

Stefan


-- 
coresystems GmbH ? Brahmsstr. 16 ? D-79104 Freiburg i. Br.
      Tel.: +49 761 7668825 ? Fax: +49 761 7664613
Email: info at coresystems.de  ? http://www.coresystems.de/



From ward at gnu.org  Sat May  6 15:11:49 2006
From: ward at gnu.org (Ward Vandewege)
Date: Sat, 6 May 2006 09:11:49 -0400
Subject: [LinuxBIOS] etherboot/filo + sata startup timing
In-Reply-To: <20060506123913.GA11451@coresystems.de>
References: <20060424220147.GA26709@io.pong.be> <444D4AED.3020805@lanl.gov>
	<20060424222144.GA17934@coresystems.de>
	<20060424222501.GC27028@io.pong.be>
	<20060428231617.GA28043@coresystems.de>
	<20060501155545.GA3652@io.pong.be>
	<20060505134709.GA2422@coresystems.de>
	<20060505213830.GA23965@localdomain>
	<20060506123913.GA11451@coresystems.de>
Message-ID: <20060506131149.GD20174@localdomain>

On Sat, May 06, 2006 at 02:39:13PM +0200, Stefan Reinauer wrote:
> * Ward Vandewege <ward at gnu.org> [060505 23:38]:
> > I've tried this; the boot log is attached (minicom-20060505.cap) with
> > DEBUG_PCI, DEBUG_IDE and DEBUG_LINUXBIOS enabled. Didn't help.
> > 
> > >  * if that doesnt help: try whether the disk is detected as hda instead
> > >    of hde. This might happen with the current code.
> > 
> > I've tried that too, the bootlog is also attached (minicom-20060505-2.cap).
> > Still no luck; though here it does seem to find the IDE controller. But not
> > the drive...
> 
> Aha! It shows a floating IDE bus... Does anyone have an idea what's
> wrong exactly if this shows up? It might just be an issue of waiting
> just a little bit longer..
> 
> Sorry, what board was this again?

Tyan s2881; onboard sata controller.

Ward.

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



From smithbone at gmail.com  Sat May  6 18:29:37 2006
From: smithbone at gmail.com (Richard Smith)
Date: Sat, 6 May 2006 11:29:37 -0500
Subject: [LinuxBIOS] LB vs Factory BIOS -- more weirdness
In-Reply-To: <445C4C04.6090302@zyxod.com>
References: <445C4C04.6090302@zyxod.com>
Message-ID: <8a0c36780605060929x79ae210aw1a31014636f0e5e1@mail.gmail.com>

> suggested that there are chipset registers that are reset by the factory
> BIOS that LB isn't (re)setting correctly, and that LB works well right
> after using the factory BIOS because those registers hold their values
> for a while.

Do a 'lspci -xxx' diff on the north and southbridges beween factory
and LB and investigate all the differences.

--
Richard A. Smith



From scott at waye.co.uk  Sat May  6 18:58:25 2006
From: scott at waye.co.uk (scott)
Date: Sat, 06 May 2006 17:58:25 +0100
Subject: [LinuxBIOS] FILO build error
Message-ID: <445CD5B1.1010704@waye.co.uk>

Hi,

I am new to this project, but I want to flash my EPIA MII 6000 to get 
better boot times.  I have downloaded filo (0.5) and have edited the 
Config file to remove GRUB because I dont want a menu, I just want it to 
boot a single image which I understand to be the autoboot option.  I get 
this error when I run make:

ld -N -T i386/ldscript -o filo main/builtin.o main/grub/builtin.o 
fs/builtin.o drivers/builtin.o drivers/usb/builtin.o i386/builtin.o 
/usr/lib/gcc-lib/i486-slackware-linux/3.2.3/libgcc.a
drivers/usb/builtin.o(.text+0xcb): In function `dump_td':
: undefined reference to `grub_strcpy'
drivers/usb/builtin.o(.text+0x19d): In function `dump_queue_head':
: undefined reference to `grub_strcpy'
drivers/usb/builtin.o(.text+0x2c4): In function `dump_transaction':
: undefined reference to `grub_strcpy'
drivers/usb/builtin.o(.text+0x306): In function `dump_usbdev':
: undefined reference to `grub_strcpy'
drivers/usb/builtin.o(.text+0x37e): In function `dump_config_descriptor':
: undefined reference to `grub_strcpy'
drivers/usb/builtin.o(.text+0x3a0): more undefined references to 
`grub_strcpy' follow
drivers/usb/builtin.o(.text+0x3089): In function `configure_device':
: undefined reference to `grub_printf'
drivers/usb/builtin.o(.text+0x32e7): In function `configure_device':
: undefined reference to `grub_printf'
drivers/usb/builtin.o(.text+0x3321): In function `configure_device':
: undefined reference to `grub_printf'
drivers/usb/builtin.o(.text+0x3345): In function `configure_device':
: undefined reference to `grub_printf'
drivers/usb/builtin.o(.text+0x3366): In function `configure_device':
: undefined reference to `grub_printf'

Here is my Config:

# !!! NOTE !!!
# Do NOT add spaces or comments at the end of option lines.
# It confuses some versions of make.

# Use grub instead of autoboot?
USE_GRUB = 0

# Grub menu.lst path
#MENULST_FILE = "hda3:/boot/filo/menu.lst"

# Image filename for automatic boot and optional command line parameter
AUTOBOOT_FILE = "hda1:/boot/vmlinuz root=/dev/hda1 console=ttyS0,38400"
#AUTOBOOT_FILE = "mem at 0xfff80000"
#AUTOBOOT_FILE = "hde1 at 0"
#AUTOBOOT_FILE = "uda1:/vmlinuz.elf"

# Time in second before booting AUTOBOOT_FILE
AUTOBOOT_DELAY = 1

# Driver for hard disk, CompactFlash, and CD-ROM on IDE bus
IDE_DISK = 1

# Add a short delay when polling status registers
# (required on some broken SATA controllers)
IDE_DISK_POLL_DELAY = 1

# Driver for USB Storage
USB_DISK = 1

# VGA text console
VGA_CONSOLE = 1
PC_KEYBOARD = 1

# Serial console
SERIAL_CONSOLE = 1
SERIAL_IOBASE = 0x3f8
# if SERIAL_SPEED is commented out, the speed will not be changed.
#SERIAL_SPEED = 115200

# Filesystems
FSYS_EXT2FS = 1
#FSYS_FAT = 1
#FSYS_JFS = 1
#FSYS_MINIX = 1
FSYS_REISERFS = 1
#FSYS_XFS = 1
#FSYS_ISO9660 = 1

# Support for boot disk image in bootable CD-ROM (El Torito)
#ELTORITO = 1

# PCI support
SUPPORT_PCI = 1

# Enable this to scan PCI busses above bus 0
# AMD64 based boards do need this.
#PCI_BRUTE_SCAN = 1

# Sound support (needs SUPPORT_PCI)
#SUPPORT_SOUND = 1

# Sound drivers
#VIA_SOUND = 1

# Debugging
#DEBUG_ALL = 1
#DEBUG_ELFBOOT = 1
#DEBUG_ELFNOTE = 1
#DEBUG_LINUXBIOS = 1
#DEBUG_MALLOC = 1
#DEBUG_MULTIBOOT = 1
#DEBUG_SEGMENT = 1
#DEBUG_SYS_INFO = 1
#DEBUG_TIMER = 1
#DEBUG_BLOCKDEV = 1
#DEBUG_PCI = 1
#DEBUG_VIA_SOUND = 1
#DEBUG_LINUXLOAD = 1
#DEBUG_IDE = 1
#DEBUG_USB = 1
#DEBUG_ELTORITO = 1

# i386 options

# Loader for standard Linux kernel image, a.k.a. /vmlinuz
LINUX_LOADER = 1

# Boot FILO from Multiboot loader (eg. GRUB)
#MULTIBOOT_IMAGE = 1

# Use PCI Configuration Mechanism #1 (most boards)
PCI_CONFIG_1 = 1






From stepan at coresystems.de  Sat May  6 21:10:22 2006
From: stepan at coresystems.de (Stefan Reinauer)
Date: Sat, 6 May 2006 21:10:22 +0200
Subject: [LinuxBIOS] FILO build error
In-Reply-To: <445CD5B1.1010704@waye.co.uk>
References: <445CD5B1.1010704@waye.co.uk>
Message-ID: <20060506191022.GA21928@coresystems.de>

* scott <scott at waye.co.uk> [060506 18:58]:
> Hi,
> 
> I am new to this project, but I want to flash my EPIA MII 6000 to get 
> better boot times.  I have downloaded filo (0.5) and have edited the 
> Config file to remove GRUB because I dont want a menu, I just want it to 
> boot a single image which I understand to be the autoboot option.  I get 
> this error when I run make:

Thanks for spotting this. It's fixed in filo svn r20 now. Please go
ahead and try it..

Stefan

-- 
coresystems GmbH ? Brahmsstr. 16 ? D-79104 Freiburg i. Br.
      Tel.: +49 761 7668825 ? Fax: +49 761 7664613
Email: info at coresystems.de  ? http://www.coresystems.de/



From scott at waye.co.uk  Sat May  6 21:38:34 2006
From: scott at waye.co.uk (scott)
Date: Sat, 06 May 2006 20:38:34 +0100
Subject: [LinuxBIOS] FILO build error
In-Reply-To: <20060506191022.GA21928@coresystems.de>
References: <445CD5B1.1010704@waye.co.uk>
	<20060506191022.GA21928@coresystems.de>
Message-ID: <445CFB3A.1030305@waye.co.uk>

That was quick.  It works,  thanks.


Stefan Reinauer wrote:

>* scott <scott at waye.co.uk> [060506 18:58]:
>  
>
>>Hi,
>>
>>I am new to this project, but I want to flash my EPIA MII 6000 to get 
>>better boot times.  I have downloaded filo (0.5) and have edited the 
>>Config file to remove GRUB because I dont want a menu, I just want it to 
>>boot a single image which I understand to be the autoboot option.  I get 
>>this error when I run make:
>>    
>>
>
>Thanks for spotting this. It's fixed in filo svn r20 now. Please go
>ahead and try it..
>
>Stefan
>
>  
>




From russ at ashlandhome.net  Sun May  7 01:53:50 2006
From: russ at ashlandhome.net (Russell Whitaker)
Date: Sat, 6 May 2006 16:53:50 -0700 (PDT)
Subject: [LinuxBIOS] LB vs Factory BIOS -- more weirdness
In-Reply-To: <445C4C04.6090302@zyxod.com>
References: <445C4C04.6090302@zyxod.com>
Message-ID: <Pine.LNX.4.63.0605061645570.2367@bigred.russwhit.org>



On Sat, 6 May 2006, Eric Poulsen wrote:

> In response to the instability issues I've had with LB (It's not ram --
> memtest86+ ran for hours under LB with no errors), someone here
> suggested that there are chipset registers that are reset by the factory
> BIOS that LB isn't (re)setting correctly, and that LB works well right
> after using the factory BIOS because those registers hold their values
> for a while.
>
> I'm conviced this is the case -- I have too many weird issues that can
> be fixed by simply flipping back to the factory BIOS, turning the system
> on, getting a "bad CMOS" error, then immediately powering off and
> switching to LB, which suddenly works again.

Check the CMOS battery voltage. If it's low the CMOS will loose a bit or
two over time. Ran into that problem years ago on a 286 mb.

   Russ



From andy.somerville at gmail.com  Sun May  7 05:16:51 2006
From: andy.somerville at gmail.com (Andy Somerville)
Date: Sat, 6 May 2006 23:16:51 -0400
Subject: [LinuxBIOS] State of vt8237 and consequently epia-ms
In-Reply-To: <9D3D7CEF3A236243AF0335652672E34810D19F04@maxis-mb1.max.ad.ea.com>
References: <9D3D7CEF3A236243AF0335652672E34810D19F04@maxis-mb1.max.ad.ea.com>
Message-ID: <ca787df10605062016t3fea7e95o66b795b4bc6cd4bb@mail.gmail.com>

Matt,

    If you get anywhere, it would be great if you keep the list up to
date on your progress. I might be able to help you test, though I
might have to find a solution to backup/restore my current bios before
I do.

Btw, which board are you looking into the vt8237 for? (epia-n, epia-ms, other?)

     Andy

On 5/3/06, Samet, Matt <MSamet at ea.com> wrote:
> Hi Adam -
>
> I'd like to start looking into the VT8237 myself.
> If possible, could I get that VT8237 doc from you? And possibly your WIP
> code?
> I can start to take a look, I have some time.
>
> Thanks...
> -=matt
>
> -----Original Message-----
> From: linuxbios-bounces at linuxbios.org
> [mailto:linuxbios-bounces at linuxbios.org] On Behalf Of Adam Talbot
> Sent: Saturday, April 29, 2006 12:37 PM
> To: Andy Somerville
> Cc: linuxbios at linuxbios.org
> Subject: Re: [LinuxBIOS] State of vt8237 and consequently epia-ms
>
> -Andy
> Currently the is no support for the vt8237.
> What would it take to support?  Some one who has a few weeks to work on
> it.
> I spent a few weeks, but was never able to get the console running.
> With out that, I had no way of doing debugging.  My board does not have
> any PCI slots, so I was unable to use a post card to debug.
> -Adam
>
> Andy Somerville wrote:
> > Hi all,
> >
> >
> >      Im new to linuxbios and the mailing list so please excuse any
> > newbie stupidity. I was wondering about the state of vt8237
> > southbridge support. From my limited understanding of linuxBios this
> > is virtually all that is missing for Epia-MS support since CLE266
> > northbridge is already supported.
> >
> > I saw a post in february which mentioned vt8237 and that it was being
> > worked on, but I have seen nothing since. Forgive me if Ive missed
> > something.
> >
> > So I guess my overall question is: Is Epia-MS support a near
> > possiblity, and what would it take to produce?
> >
> >
> >        Andy
> >
> >
>
>
> --
> linuxbios mailing list
> linuxbios at linuxbios.org
> http://www.openbios.org/mailman/listinfo/linuxbios
>
>
> --
> linuxbios mailing list
> linuxbios at linuxbios.org
> http://www.openbios.org/mailman/listinfo/linuxbios
>



From rminnich at lanl.gov  Sun May  7 17:56:59 2006
From: rminnich at lanl.gov (Ronald G Minnich)
Date: Sun, 07 May 2006 09:56:59 -0600
Subject: [LinuxBIOS] [linuxbios-checkins] r2301
	-	trunk/LinuxBIOSv2/src/cpu/amd/model_gx2
In-Reply-To: <20060506122928.GA10512@coresystems.de>
References: <E1FcCwP-0007xK-FU@khepri.openbios.org>
	<20060506122928.GA10512@coresystems.de>
Message-ID: <445E18CB.5000105@lanl.gov>

Stefan Reinauer wrote:
> * svn at openbios.org <svn at openbios.org> [060506 04:54]:
> 
>>Modified:
>>   trunk/LinuxBIOSv2/src/cpu/amd/model_gx2/vsmsetup.c
>>Log:
>>Use a real variable to configure rom base for vsa ...
>>
>>
>>Modified: trunk/LinuxBIOSv2/src/cpu/amd/model_gx2/vsmsetup.c
>>===================================================================
>>--- trunk/LinuxBIOSv2/src/cpu/amd/model_gx2/vsmsetup.c	2006-05-06 02:35:08 UTC (rev 2300)
>>+++ trunk/LinuxBIOSv2/src/cpu/amd/model_gx2/vsmsetup.c	2006-05-06 02:54:45 UTC (rev 2301)
>>+	//rom = 0xfffc0000;
>>+	/* the VSA starts at the base of rom - 128k */
>>+	rom = ((unsigned long) 0) - (ROM_SIZE  + 128*1024);
> 
> 
> 
> dumb question:
> Since this is in the CPU code and not motherboard specific, should this
> be a config variable, in case someone uses different VSMs? Or are they
> always 128k?
> 
> Stefan
> 

it's a good question. What I really want to do is kill VSA in the 
linuxbios world. Until I know for sure, let's leave this hack in.

Actually, the variable should be set at buildrom time, but we can't 
accomodate that sort of thing yet.

ron



From eric at zyxod.com  Sun May  7 22:44:20 2006
From: eric at zyxod.com (Eric Poulsen)
Date: Sun, 07 May 2006 13:44:20 -0700
Subject: [LinuxBIOS] LB vs Factory BIOS -- more weirdness
In-Reply-To: <Pine.LNX.4.63.0605061645570.2367@bigred.russwhit.org>
References: <445C4C04.6090302@zyxod.com>
	<Pine.LNX.4.63.0605061645570.2367@bigred.russwhit.org>
Message-ID: <445E5C24.5030708@zyxod.com>

I measured 3.08 V, using a Fluke.  Since it's a CR2032 battery, it's 
good to go.

Russell Whitaker wrote:

>
>
> On Sat, 6 May 2006, Eric Poulsen wrote:
>
>> In response to the instability issues I've had with LB (It's not ram --
>> memtest86+ ran for hours under LB with no errors), someone here
>> suggested that there are chipset registers that are reset by the factory
>> BIOS that LB isn't (re)setting correctly, and that LB works well right
>> after using the factory BIOS because those registers hold their values
>> for a while.
>>
>> I'm conviced this is the case -- I have too many weird issues that can
>> be fixed by simply flipping back to the factory BIOS, turning the system
>> on, getting a "bad CMOS" error, then immediately powering off and
>> switching to LB, which suddenly works again.
>
>
> Check the CMOS battery voltage. If it's low the CMOS will loose a bit or
> two over time. Ran into that problem years ago on a 286 mb.
>
>   Russ
>




From chris at suehsi.de  Wed May 10 00:18:24 2006
From: chris at suehsi.de (=?ISO-8859-1?Q?Christian_S=FChs?=)
Date: Wed, 10 May 2006 00:18:24 +0200
Subject: [LinuxBIOS] MB1030 / 3036 VGA resume
In-Reply-To: <4459C0FE.6070104@suehsi.de>
References: <8a0c36780605011259p721fb330j4d640fc17857cae8@mail.gmail.com>	<445733D0.6050004@suehsi.de>	<44575B60.7050406@suehsi.de>	<8a0c36780605020731w7d9d7048g524d640b4d3ed665@mail.gmail.com>	<44578BAB.80008@suehsi.de>	<44579320.90206@suehsi.de>	<8a0c36780605020925h6110f2d8pa656fde32cc5adfb@mail.gmail.com>	<4457ADD6.8020608@suehsi.de>	<20060502192823.GC4620@coresystems.de>	<4457CB2A.4030908@suehsi.de>	<20060502205654.GB11460@coresystems.de>	<44586CDF.2060809@suehsi.de>	<4458D0C3.7020308@lanl.gov>
	<4459C0FE.6070104@suehsi.de>
Message-ID: <44611530.3070202@suehsi.de>


> 
> The whole boottime is slow.
> Lb is 15s slower as the factory bios in kernel booting.
> 
> 1. copying LB to RAM seems slow.
> 2. copying kernel and intitrd.gz to RAM seems slow
> 3. uncompressing kernel seems slow.
> 
> All operations to or in RAM seems to be 3 times slower as under factory.
> 
> 


For all:

I have test the system under factory and LB with lmbench.
Here are the results in textform.
PostScript output files were sent to Ron. Is somebody interested, I 
could send these files to him/her, too.

I hope somebody has an good answer, for the differences ;)
I need the final hint.

chris

-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: benchmark.txt
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20060510/649e2056/attachment.txt>

From nick.barker9 at btinternet.com  Mon May  8 16:05:57 2006
From: nick.barker9 at btinternet.com (Nick Barker)
Date: Mon, 8 May 2006 15:05:57 +0100
Subject: [LinuxBIOS] LB vs Factory BIOS -- more weirdness
In-Reply-To: <445C4C04.6090302@zyxod.com>
Message-ID: <LBEPJONEBEDMPPCKLBBIOEAJCEAA.nick.barker9@btinternet.com>

Eric

One further observation re this locking up is that you seem to be using
fast memory compared to the speed of the chipset. The debug output:

CAS Supported 2 2.5 3
Cycle time at CL X     (nS)50
Cycle time at CL X-0.5 (nS)60
Cycle time at CL X-1   (nS)75
Starting at CAS 3
We can do CAS 2.5
We can do CAS 2

tells me that LB has spotted memory rated as DDR400, and is consequently
trying to use it with a 'tuned' CAS setting of only 2. DDR266 usually
works at CAS of 2.5 or 3. It 'MAY' be the case that working the chipset /
memory interface at this 'tuned' setting is marginal - OK under memtest,
but as soon as you have other bus masters trying to access the memory as
well then you get problems.

You could test out this hypothesis by forcing CAS of 2.5 or 3 in the memory
detection routines. Should be easy to do since the code starts out with 3
and then decides if it could do better. Simply comment out those tests.

Or try it out with DDR266.

Nick Barker


-----Original Message-----
From: linuxbios-bounces at linuxbios.org
[mailto:linuxbios-bounces at linuxbios.org]On Behalf Of Eric Poulsen
Sent: 06 May 2006 08:11
To: linuxbios at linuxbios.org
Subject: [LinuxBIOS] LB vs Factory BIOS -- more weirdness


In response to the instability issues I've had with LB (It's not ram --
memtest86+ ran for hours under LB with no errors), someone here
suggested that there are chipset registers that are reset by the factory
BIOS that LB isn't (re)setting correctly, and that LB works well right
after using the factory BIOS because those registers hold their values
for a while.

I'm conviced this is the case -- I have too many weird issues that can
be fixed by simply flipping back to the factory BIOS, turning the system
on, getting a "bad CMOS" error, then immediately powering off and
switching to LB, which suddenly works again.

I'm pretty sure the DMA transfer under Linux bug (this is a chipset bug
specific to some Epia models that can be fixed (in theory) with a BIOS
upgrade) is exhibiting itself -- I get hard locks with the HD light on
when xferring larger files.  It's really easy to reproduce.  I tried to
lock it under the factory bios, but it wouldn't lock.  After I rebooted
using LB, the problem went away in LB as well.  This tends to support
the "chipset register remembrance" theory.

Here's the latest.  The full serial caps are at the bottom, but here are
the differences.  I set all the kernel times to zero so that diff would
work.

Differences in LB output:

 Crash: Low Bond 00  High Bondc0  Setting DQS delay80vt8623 done
Worked: Low Bond 00  High Bondc1  Setting DQS delay80vt8623 done

I'm no expert, but this appears to be looking for a range of usable RAM
under 1M.  Should the High Bond values be different, ever?

Differences in kernel output:
 Crash: [00000.00000] DMI 2.2 present.
Worked: [00000.00000] DMI not present or invalid.

I'm not sure if this is relevant or not ...


And finally, the crash itself:

  [00000.00000] PCI: If a device doesn't work, try "pci=routeirq".  If
it helps, post a report
  [00000.00000] general protection fault: 3120 [#1]
  [00000.00000] Modules linked in:
  [00000.00000] CPU:    0
  [00000.00000] EIP:    0060:[<c00faa2c>]    Not tainted VLI
  [00000.00000] EFLAGS: 00010013   (2.6.16.5 #4)
  [00000.00000] EIP is at 0xc00faa2c
  [00000.00000] eax: 0000b102   ebx: c13f7400   ecx: 00003123   edx:
00001106
  [00000.00000] esi: 00000000   edi: c03016cc   ebp: 00000000   esp:
c11fff76
  [00000.00000] ds: 007b   es: 007b   ss: 0068
  [00000.00000] Process swapper (pid: 1, threadinfo=c11fe000 task=c11fba70)
  [00000.00000] Stack: <0>31230000 c03016cc c00fa97c 0000b102 00001106
072c0246 0060c024 74000000
  [00000.00000]        0000c13f 00000000 09fb0000 1106c024 31230000
00000000 ffba0000 ffbbc11f
  [00000.00000]        0000c11f ffbc0000 ffbcc11f 1274c11f 0000c036
00000000 7d150000 06fbc035
  [00000.00000] Call Trace:
  [00000.00000] Code: cb 87 db b4 81 f9 c3 e8 aa 03 00 00 ba 50 43 49 20
66 b8 11 00 66 bb 10 02 f8 c3 57 66 51 66 56 66 83   fa ff 75 05 b4 83
f9 eb 53 <66> cb f9 c1 e7 10 66 8b fa e8 7d 03 00 00 8a d9 32 ff 32 ed 80
  [00000.00000]  <0>Kernel panic - not syncing: Attempted to kill init!
  [00000.00000]

------------------------------
Full Text, working boot:
------------------------------
0

LinuxBIOS-1.1.8.0Fallback Thu May  4 18:03:52 PDT 2006 starting...
 Enabling mainboard devices
 Enabling shadow ram
vt8623 init starting
Detecting Memory
Number of Banks 04
Number of Rows 0d
Priamry DRAM width08
No Columns 0a
MA type e0
Bank 0 (*16 Mb) 10
No Physical Banks 01
Total Memory (*16 Mb) 10
CAS Supported 2 2.5 3
Cycle time at CL X     (nS)50
Cycle time at CL X-0.5 (nS)60
Cycle time at CL X-1   (nS)75
Starting at CAS 3
We can do CAS 2.5
We can do CAS 2
tRP 48
tRCD 48
tRAS 28
Low Bond 00  High Bondc1  Setting DQS delay80vt8623 done
00:06 11 23 31 06 00 30 22 00 00 00 06 00 00 00 00
10:08 00 00 d0 00 00 00 00 00 00 00 00 00 00 00 00
20:00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
30:00 00 00 00 a0 00 00 00 00 00 00 00 00 00 00 00
40:00 18 88 80 82 44 00 00 18 99 88 80 82 44 00 00
50:c8 de cf 88 e0 07 00 00 e0 00 10 10 10 10 00 00
60:02 ff 00 30 d6 32 01 2a 42 2d 43 58 00 44 00 00
70:82 48 00 01 01 08 50 00 01 00 00 00 00 00 02 02
80:0f 65 00 00 80 00 00 00 02 00 00 00 00 00 00 00
90:00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
a0:02 c0 20 00 07 02 00 1f 04 00 00 00 2f 02 04 00
b0:00 00 00 00 80 00 00 00 88 00 00 00 00 00 00 00
c0:01 00 02 00 00 00 00 00 00 00 00 00 00 00 00 00
d0:00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
e0:00 dd 00 00 00 00 01 00 40 00 00 00 00 00 00 00
f0:00 00 00 00 00 00 12 13 00 00 00 00 00 00 00 00
AGP
 Doing MTRR init.
Copying LinuxBIOS to ram.
Jumping to LinuxBIOS.
LinuxBIOS-1.1.8.0Fallback Fri May  5 19:03:15 PDT 2006 booting...
clocks_per_usec: 838
Enumerating buses...
Finding PCI configuration type.
PCI: Using configuration type 1
PCI_DOMAIN: 0000 enabled
APIC_CLUSTER: 0 enabled
PCI: pci_scan_bus for bus 0
PCI: 00:00.0 [1106/3123] enabled
PCI: 00:01.0 [1106/b091] enabled
In vt8235_enable 1106 3038.
PCI: 00:10.0 [1106/3038] enabled
In vt8235_enable 1106 3038.
PCI: 00:10.1 [1106/3038] enabled
In vt8235_enable 1106 3038.
PCI: 00:10.2 [1106/3038] enabled
In vt8235_enable 1106 3104.
PCI: 00:10.3 [1106/3104] enabled
In vt8235_enable 1106 3177.
Initialising Devices
PCI: 00:11.0 [1106/3177] enabled
In vt8235_enable 1106 0571.
PCI: 00:11.1 [1106/0571] enabled
In vt8235_enable 1106 3059.
PCI: 00:11.5 [1106/3059] enabled
In vt8235_enable ffff ffff.
In vt8235_enable 1106 3065.
PCI: 00:12.0 [1106/3065] enabled
PCI: pci_scan_bus for bus 1
PCI: 01:00.0 [1106/3122] enabled
PCI: pci_scan_bus returning with max=01
vt1211 enabling PNP devices.
PNP: 002e.1 enabled
vt1211 enabling PNP devices.
PNP: 002e.2 enabled
vt1211 enabling PNP devices.
PNP: 002e.3 enabled
vt1211 enabling PNP devices.
PNP: 002e.b enabled
PNP: 002e.0 enabled
PCI: pci_scan_bus returning with max=01
done
Allocating resources...
Reading resources...
Done reading resources.
Setting resources...
I would set ram size to 0x40000 Kbytes
PCI: 00:10.0 20 <- [0x0000001800 - 0x000000181f] io
PCI: 00:10.1 20 <- [0x0000001820 - 0x000000183f] io
PCI: 00:10.2 20 <- [0x0000001840 - 0x000000185f] io
PCI: 00:10.3 10 <- [0x00febff000 - 0x00febff0ff] mem
PNP: 002e.1 60 <- [0x0000000378 - 0x000000037f] io
PNP: 002e.1 70 <- [0x0000000007 - 0x0000000007] irq
PNP: 002e.1 74 <- [0x0000000003 - 0x0000000003] drq
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
PNP: 002e.b 60 <- [0x000000ec00 - 0x000000ecff] io
ERROR: PNP: 002e.0 60 io size: 0x0000000008 not assigned
ERROR: PNP: 002e.0 60 irq size: 0x0000000001 not assigned
ERROR: PNP: 002e.0 60 drq size: 0x0000000001 not assigned
PCI: 00:11.1 20 <- [0x0000001860 - 0x000000186f] io
PCI: 00:11.5 10 <- [0x0000001000 - 0x00000010ff] io
PCI: 00:12.0 10 <- [0x0000001400 - 0x00000014ff] io
PCI: 00:12.0 14 <- [0x00fec00000 - 0x00fec000ff] mem
Done setting resources.
Done allocating resources.
Enabling resources...
PCI: 00:00.0 cmd <- 146
PCI: 00:01.0 bridge ctrl <- 000f
PCI: 00:01.0 cmd <- 147
PCI: 01:00.0 cmd <- 140
PCI: 00:10.0 subsystem <- 00/00
PCI: 00:10.0 cmd <- 141
PCI: 00:10.1 subsystem <- 00/00
PCI: 00:10.1 cmd <- 141
PCI: 00:10.2 subsystem <- 00/00
PCI: 00:10.2 cmd <- 141
PCI: 00:10.3 subsystem <- 00/00
PCI: 00:10.3 cmd <- 142
PCI: 00:11.0 cmd <- 147
PNP: 002e.1 - enabling
PNP: 002e.2 - enabling
PNP: 002e.3 - enabling
PNP: 002e.b - enabling
PNP: 002e.0 - enabling
PCI: 00:11.1 cmd <- 147
PCI: 00:11.5 subsystem <- 00/00
PCI: 00:11.5 cmd <- 141
PCI: 00:12.0 cmd <- 1c3
done.
Initializing devices...
Root Device init
PCI: 00:10.0 init
PCI: 00:10.1 init
PCI: 00:10.2 init
PCI: 00:10.3 init
PCI: 00:11.0 init
vt8235 init
RTC Init
Invalid CMOS LB checksum
pci_routing_fixup: dev is 000107c0
setting firewire
setting usb
Assigning IRQ 5 to 0:10.0
  Readback = 5
pci_level_irq: lower order bits are wrong: want 0x0, got 0x20
Assigning IRQ 9 to 0:10.1
  Readback = 9
pci_level_irq: lower order bits are wrong: want 0x0, got 0x20
Assigning IRQ 9 to 0:10.2
  Readback = 9
pci_level_irq: lower order bits are wrong: want 0x0, got 0x20
Assigning IRQ 5 to 0:10.3
  Readback = 5
pci_level_irq: lower order bits are wrong: want 0x0, got 0x20
setting vt8235
Assigning IRQ 5 to 0:11.1
  Readback = 5
pci_level_irq: lower order bits are wrong: want 0x0, got 0x20
Assigning IRQ 9 to 0:11.5
  Readback = 9
pci_level_irq: lower order bits are wrong: want 0x0, got 0x20
setting ethernet
Assigning IRQ 5 to 0:12.0
  Readback = 5
pci_level_irq: lower order bits are wrong: want 0x0, got 0x20
setting vga
Assigning IRQ 5 to 1:0.0
  Readback = 5
pci_level_irq: lower order bits are wrong: want 0x0, got 0x20
setting pci slot
setting cardbus slot
setting riser slot
PNP: 002e.1 init
PNP: 002e.2 init
PNP: 002e.3 init
PNP: 002e.b init
PCI: 00:11.1 init
Enabling VIA IDE.
ide_init: enabling compatibility IDE addresses
enables in reg 0x42 0x0
enables in reg 0x42 read back as 0x0
enables in reg 0x40 0x13
enables in reg 0x40 read back as 0x13
enables in reg 0x9 0x8a
enables in reg 0x9 read back as 0x8a
command in reg 0x4 0x7
command in reg 0x4 reads back as 0x7
PCI: 00:11.5 init
PCI: 00:12.0 init
Configuring VIA Rhine LAN
APIC_CLUSTER: 0 init
Initializing CPU #0
CPU: vendor Centaur device 673
Enabling cache

Setting fixed MTRRs(0-88) type: UC
Setting fixed MTRRs(0-16) Type: WB
Setting fixed MTRRs(24-88) Type: WB
DONE fixed MTRRs
Setting variable MTRR 0, base:    0MB, range:  128MB, type WB
Setting variable MTRR 1, base:  128MB, range:   64MB, type WB
Setting variable MTRR 2, base:  192MB, range:   32MB, type WB
DONE variable MTRRs
Clear out the extra MTRR's

MTRR check
Fixed MTRRs   : Enabled
Variable MTRRs: Enabled

Disabling local apic...done.
CPU #0 Initialized
PCI: 00:00.0 init
VT8623 random fixup ...
Frame buffer at d0000000
PCI: 00:01.0 init
VT8623 AGP random fixup ...
PCI: 01:00.0 init
VGA random fixup ...
INSTALL REAL-MODE IDT
DO THE VGA BIOS
found VGA: vid=1106, did=3122
rom base, size: fffc0000
write_protect_vgabios
bus/devfn = 0x100
biosint: INT# 0x15
biosint: eax 0x5f00 ebx 0x18538 ecx 0x17fa8 edx 0x12
biosint: ebp 0x17f84 esp 0xff2 edi 0xed10 esi 0xffff6f55
biosint:  ip 0x637f   cs 0xc000  flags 0x46
biosint: INT# 0x1a
biosint: eax 0xb108 ebx 0x10000 ecx 0x10000 edx 0x3d5
biosint: ebp 0x17f84 esp 0xfcc edi 0xf6 esi 0xffff55eb
biosint:  ip 0x40da   cs 0xc000  flags 0x46
0xb108: bus 0 devfn 0x0 reg 0xf6 val 0x12
biosint: INT# 0x15
biosint: eax 0x5f0f ebx 0x18538 ecx 0x7fa8 edx 0x3d5
biosint: ebp 0x17f84 esp 0xfee edi 0x44 esi 0xffff6f55
biosint:  ip 0x647e   cs 0xc000  flags 0x7
biosint: INT# 0x15
biosint: eax 0x5f02 ebx 0x18538 ecx 0x7f01 edx 0x3d5
biosint: ebp 0x17f84 esp 0xfdc edi 0x44 esi 0xffff6f55
biosint:  ip 0x63cb   cs 0xc000  flags 0x46
biosint: INT# 0x15
biosint: eax 0x5f18 ebx 0x18501 ecx 0x7fa8 edx 0x3d5
biosint: ebp 0x17f84 esp 0xfde edi 0x44 esi 0xffff6f55
biosint:  ip 0x6496   cs 0xc000  flags 0x46
biosint: INT# 0x15
biosint: eax 0x5f06 ebx 0x18001 ecx 0x1 edx 0x0
biosint: ebp 0x10fd6 esp 0xfa4 edi 0x0 esi 0xffff4672
biosint:  ip 0x63dc   cs 0xc000  flags 0x246
biosint: INT# 0x15
biosint: eax 0x5f08 ebx 0x10d01 ecx 0x8301 edx 0xd4
biosint: ebp 0x10fd6 esp 0xfa4 edi 0x0 esi 0xffff0d0e
biosint:  ip 0x63e8   cs 0xc000  flags 0x246
PNP: 002e.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.
ACPI: Writing ACPI tables at f0400...
ACPI:     * FACS
ACPI:     * DSDT @ 000f049e Length 3f0
ACPI:     * FADT
ACPI: added table 1/5 Length now 40
ACPI: done.
Moving GDT to 0x500...ok
Wrote linuxbios table at: 00000530 - 00000b80  checksum e5ca

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

    33:stream_init() - rom_stream: 0xfffd0000 - 0xfffeffff
Found ELF candiate at offset 0
New segment addr 0x100000 size 0x204a0 offset 0xc0 filesize 0x6508
(cleaned up) New segment addr 0x100000 size 0x204a0 offset 0xc0 filesize
0x6508
New segment addr 0x1204a0 size 0x48 offset 0x65e0 filesize 0x48
(cleaned up) New segment addr 0x1204a0 size 0x48 offset 0x65e0 filesize 0x48
Dropping non PT_LOAD segment
Dropping non PT_LOAD segment
Loading Segment: addr: 0x0000000000100000 memsz: 0x00000000000204a0
filesz: 0x0000000000006508
Clearing Segment: addr: 0x0000000000106508 memsz: 0x0000000000019f98
Loading Segment: addr: 0x00000000001204a0 memsz: 0x0000000000000048
filesz: 0x0000000000000048
Jumping to boot code at 0x10480c
FILO version 0.4.2 (root at embedded) Fri May  5 19:02:14 PDT 2006
Press <Enter> for default boot, or <Esc> for boot prompt... 1 
boot: hda1:/boot/vmlinuz root=/dev/hda1 console=tty0 lpj=2136847
dhash_entries=4000 ide0=0x1f0,0x3f6,14 ide0=noprobe ide1=noprobe
ide2=noprobe ide3=noprobe ide4=noprobe ide5=noprobe hda=65535,16,63
hdb=none hdc=noprobe hdd=none no_hlt console=ttyS0,115200
hda: LBA 80GB: WDC WD800JB-00FMA0
Mounted ext2fs
Found Linux version 2.6.16.5 (root at ep) #4 Wed Apr 26 09:34:01 PDT 2006
bzImage.
Loading kernel... ok
Jumping to entry point...
[00000.00000] Linux version 2.6.16.5 (root at ep) (gcc version 3.4.5
20050809 (prerelease) (Ubuntu 3.4.4-6ubuntu8.1)) #4 Wed Apr 26 09:34:01
PDT 2006
[00000.00000] BIOS-provided physical RAM map:
[00000.00000]  BIOS-e820: 0000000000000be0 - 00000000000a0000 (usable)
[00000.00000]  BIOS-e820: 0000000000100000 - 000000000e000000 (usable)
[00000.00000] 0MB HIGHMEM available.
[00000.00000] 224MB LOWMEM available.
[00000.00000] DMI not present or invalid.
[00000.00000] ACPI: PM-Timer IO Port: 0x408
[00000.00000] Allocating PCI resources starting at 10000000 (gap:
0e000000:f2000000)
[00000.00000] Built 1 zonelists
[00000.00000] Kernel command line: root=/dev/hda1 console=tty0
lpj=2136847 dhash_entries=4000 ide0=0x1f0,0x3f6,14 ide0=noprobe
ide1=noprobe ide2=noprobe ide3=noprobe ide4=noprobe ide5=noprobe
hda=65535,16,63 hdb=none hdc=noprobe hdd=none no_hlt console=ttyS0,115200
[00000.00000] ide_setup: ide0=0x1f0,0x3f6,14
[00000.00000]  -- OBSOLETE OPTION, WILL BE REMOVED SOON!
[00000.00000] ide_setup: ide0=noprobe
[00000.00000] ide_setup: ide1=noprobe
[00000.00000] ide_setup: ide2=noprobe
[00000.00000] ide_setup: ide3=noprobe
[00000.00000] ide_setup: ide4=noprobe
[00000.00000] ide_setup: ide5=noprobe
[00000.00000] ide_setup: hda=65535,16,63
[00000.00000] ide_setup: hdb=none
[00000.00000] ide_setup: hdc=noprobe
[00000.00000] ide_setup: hdd=none
[00000.00000] No local APIC present or hardware disabled
[00000.00000] Initializing CPU#0
[00000.00000] PID hash table entries: 1024 (order: 10, 16384 bytes)
[00000.00000] Detected 533.151 MHz processor.
[00000.00000] Using pmtmr for high-res timesource
[00000.00000] Console: colour VGA+ 80x25
[00000.00000] Dentry cache hash table entries: 4096 (order: 2, 16384 bytes)
[00000.00000] Inode-cache hash table entries: 16384 (order: 4, 65536 bytes)
[00000.00000] Memory: 224128k/229376k available (1666k kernel code,
4848k reserved, 622k data, 148k init, 0k highmem)
[00000.00000] Checking if this processor honours the WP bit even in
supervisor mode... Ok.
[00000.00000] Calibrating delay loop (skipped)... 1068.42 BogoMIPS preset
[00000.00000] Security Framework v1.0.0 initialized
[00000.00000] SELinux:  Disabled at boot.
[00000.00000] Mount-cache hash table entries: 512
[00000.00000] CPU: L1 I Cache: 64K (32 bytes/line), D cache 64K (32
bytes/line)
[00000.00000] CPU: L2 Cache: 64K (32 bytes/line)
[00000.00000] CPU: Centaur VIA Samuel 2 stepping 03
[00000.00000] Checking 'hlt' instruction... OK.
[00000.00000] ACPI: setting ELCR to 0020 (from 0220)
[00000.00000] NET: Registered protocol family 16
[00000.00000] ACPI: bus type pci registered
[00000.00000] PCI: PCI BIOS revision 2.10 entry at 0xfa960, last bus=1
[00000.00000] PCI: Using configuration type 1
[00000.00000] ACPI: Subsystem revision 20060127
[00000.00000] ACPI: Interpreter enabled
[00000.00000] ACPI: Using PIC for interrupt routing
[00000.00000] ACPI: PCI Interrupt Link [LNKA] (IRQs *5 9 10)
[00000.00000] ACPI: PCI Interrupt Link [LNKB] (IRQs 5 *9 10)
[00000.00000] ACPI: PCI Interrupt Link [LNKC] (IRQs 5 *9 10)
[00000.00000] ACPI: PCI Interrupt Link [LNKD] (IRQs *5 9 10)
[00000.00000] ACPI: PCI Root Bridge [PCI0] (0000:00)
[00000.00000] PCI quirk: region 0400-047f claimed by vt8235 PM
[00000.00000] PCI quirk: region 0f00-0f0f claimed by vt8235 SMB
[00000.00000] Linux Plug and Play Support v0.97 (c) Adam Belay
[00000.00000] pnp: PnP ACPI init
[00000.00000] pnp: PnP ACPI: found 0 devices
[00000.00000] usbcore: registered new driver usbfs
[00000.00000] usbcore: registered new driver hub
[00000.00000] PCI: Using ACPI for IRQ routing
[00000.00000] PCI: If a device doesn't work, try "pci=routeirq".  If it
helps, post a report
[00000.00000] PCI: Bridge: 0000:00:01.0
[00000.00000]   IO window: disabled.
[00000.00000]   MEM window: dc000000-ddffffff
[00000.00000]   PREFETCH window: d8000000-dbffffff
[00000.00000] audit: initializing netlink socket (disabled)
[00000.00000] audit(1146895449.196:1): initialized
[00000.00000] VFS: Disk quotas dquot_6.5.1
[00000.00000] Dquot-cache hash table entries: 1024 (order 0, 4096 bytes)
[00000.00000] Initializing Cryptographic API
[00000.00000] io scheduler noop registered
[00000.00000] io scheduler anticipatory registered (default)
[00000.00000] io scheduler deadline registered
[00000.00000] io scheduler cfq registered
[00000.00000] PNP: No PS/2 controller found. Probing ports directly.
[00000.00000] serio: i8042 AUX port at 0x60,0x64 irq 12
[00000.00000] serio: i8042 KBD port at 0x60,0x64 irq 1
[00000.00000] Serial: 8250/16550 driver $Revision: 1.90 $ 4 ports, IRQ
sharing enabled
[00000.00000] serial8250: ttyS0 at I/O 0x3f8 (irq = 4) is a 16550A
[00000.00000] serial8250: ttyS1 at I/O 0x2f8 (irq = 3) is a 16550A
[00000.00000] RAMDISK driver initialized: 16 RAM disks of 65536K size
1024 blocksize
[00000.00000] Uniform Multi-Platform E-IDE driver Revision: 7.00alpha2
[00000.00000] ide: Assuming 33MHz system bus speed for PIO modes;
override with idebus=xx
[00000.00000] VP_IDE: IDE controller at PCI slot 0000:00:11.1
[00000.00000] ACPI: PCI Interrupt Link [LNKA] enabled at IRQ 5
[00000.00000] ACPI: PCI Interrupt 0000:00:11.1[A] -> Link [LNKA] -> GSI
5 (level, low) -> IRQ 5
[00000.00000] VP_IDE: chipset revision 6
[00000.00000] VP_IDE: not 100% native mode: will probe irqs later
[00000.00000] VP_IDE: VIA vt8235 (rev 00) IDE UDMA133 controller on
pci0000:00:11.1
[00000.00000]     ide0: BM-DMA at 0x1860-0x1867, BIOS settings: hda:pio,
hdb:pio
[00000.00000]     ide1: BM-DMA at 0x1868-0x186f, BIOS settings: hdc:pio,
hdd:pio
[00000.00000] hda: WDC WD800JB-00FMA0, ATA DISK drive
[00000.00000] ide0 at 0x1f0-0x1f7,0x3f6 on irq 14
[00000.00000] hda: max request size: 128KiB
[00000.00000] hda: 156301488 sectors (80026 MB) w/8192KiB Cache,
CHS=65535/16/63, UDMA(33)
[00000.00000] hda: cache flushes supported
[00000.00000]  hda: hda1 hda2 < hda5 >
[00000.00000] usbmon: debugfs is not available
[00000.00000] NET: Registered protocol family 2
[00000.00000] IP route cache hash table entries: 2048 (order: 1, 8192 bytes)
[00000.00000] TCP established hash table entries: 8192 (order: 3, 32768
bytes)
[00000.00000] TCP bind hash table entries: 8192 (order: 3, 32768 bytes)
[00000.00000] TCP: Hash tables configured (established 8192 bind 8192)
[00000.00000] TCP reno registered
[00000.00000] TCP bic registered
[00000.00000] NET: Registered protocol family 8
[00000.00000] NET: Registered protocol family 20
[00000.00000] Using IPI Shortcut mode
[00000.00000] ACPI wakeup devices:
[00000.00000]
[00000.00000] ACPI: (supports S0 S5)
[00000.00000] EXT2-fs warning (device hda1): ext2_fill_super: mounting
ext3 filesystem as ext2
[00000.00000] VFS: Mounted root (ext2 filesystem) readonly.
[00000.00000] Freeing unused kernel memory: 148k freed
[00000.00000] input: AT Translated Set 2 keyboard as /class/input/input0
 * version 2.86 booting
[17179573.668000] NET: Registered protocol family 1
 * Starting hardware event daemon...        [ ok ]
 * Mounting a tmpfs over /dev...        [ ok ]
 * Creating initial device nodes...        [ ok ]
 * Setting disc parameters...        [ ok ]
[17179580.708000] Adding 746980k swap on /dev/hda5.  Priority:-1
extents:1 across:746980k
 * Checking root file system...        /: clean, 123856/9682944 files,
838361/19350284 blocks
[ ok ]
 * Initializing modules...        [ ok ]
 * Cleaning up ifupdown...        [ ok ]
 * Calculating module dependencies...        [ ok ]
 * Loading modules...        [17179582.652000] parport0: PC-style at
0x378 (0x778) [PCSPP,TRISTATE]
[17179582.784000] parport0: irq 7 detected
[17179582.904000] lp0: using parport0 (polling).
[17179583.060000] mice: PS/2 mouse device common for all mice
[ ok ]
 * Setting the system clock...        [ ok ]
 * Setting up LVM Volume Groups...        [ ok ]
[ ok ]
 * Starting Enterprise Volume Management System...        [ ok ]
 * Checking all file systems...        [ ok ]
 * Mounting local filesystems...        [ ok ]
 * Restoring resolver state...        [ ok ]
 * Setting up networking...        [ ok ]
 * Reading desktop files...        [ ok ]
 * Starting hotplug subsystem...

----------------
Full Text, Crash
----------------

0

LinuxBIOS-1.1.8.0Fallback Thu May  4 18:03:52 PDT 2006 starting...
 Enabling mainboard devices
 Enabling shadow ram
vt8623 init starting
Detecting Memory
Number of Banks 04
Number of Rows 0d
Priamry DRAM width08
No Columns 0a
MA type e0
Bank 0 (*16 Mb) 10
No Physical Banks 01
Total Memory (*16 Mb) 10
CAS Supported 2 2.5 3
Cycle time at CL X     (nS)50
Cycle time at CL X-0.5 (nS)60
Cycle time at CL X-1   (nS)75
Starting at CAS 3
We can do CAS 2.5
We can do CAS 2
tRP 48
tRCD 48
tRAS 28
Low Bond 00  High Bondc0  Setting DQS delay80vt8623 done
00:06 11 23 31 06 00 30 22 00 00 00 06 00 00 00 00
10:08 00 00 d0 00 00 00 00 00 00 00 00 00 00 00 00
20:00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
30:00 00 00 00 a0 00 00 00 00 00 00 00 00 00 00 00
40:00 18 88 80 82 44 00 00 18 99 88 80 82 44 00 00
50:c8 de cf 88 e0 07 00 00 e0 00 10 10 10 10 00 00
60:02 ff 00 30 d6 32 01 2a 42 2d 43 58 00 44 00 00
70:82 48 00 01 01 08 50 00 01 00 00 00 00 00 02 02
80:0f 65 00 00 80 00 00 00 02 00 00 00 00 00 00 00
90:00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
a0:02 c0 20 00 07 02 00 1f 04 00 00 00 2f 02 04 00
b0:00 00 00 00 80 00 00 00 88 00 00 00 00 00 00 00
c0:01 00 02 00 00 00 00 00 00 00 00 00 00 00 00 00
d0:00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
e0:00 dd 00 00 00 00 01 00 40 00 00 00 00 00 00 00
f0:00 00 00 00 00 00 12 13 00 00 00 00 00 00 00 00
AGP
 Doing MTRR init.
Copying LinuxBIOS to ram.
Jumping to LinuxBIOS.
LinuxBIOS-1.1.8.0Fallback Fri May  5 19:03:15 PDT 2006 booting...
clocks_per_usec: 838
Enumerating buses...
Finding PCI configuration type.
PCI: Using configuration type 1
PCI_DOMAIN: 0000 enabled
APIC_CLUSTER: 0 enabled
PCI: pci_scan_bus for bus 0
PCI: 00:00.0 [1106/3123] enabled
PCI: 00:01.0 [1106/b091] enabled
In vt8235_enable 1106 3038.
PCI: 00:10.0 [1106/3038] enabled
In vt8235_enable 1106 3038.
PCI: 00:10.1 [1106/3038] enabled
In vt8235_enable 1106 3038.
PCI: 00:10.2 [1106/3038] enabled
In vt8235_enable 1106 3104.
PCI: 00:10.3 [1106/3104] enabled
In vt8235_enable 1106 3177.
Initialising Devices
PCI: 00:11.0 [1106/3177] enabled
In vt8235_enable 1106 0571.
PCI: 00:11.1 [1106/0571] enabled
In vt8235_enable 1106 3059.
PCI: 00:11.5 [1106/3059] enabled
In vt8235_enable ffff ffff.
In vt8235_enable 1106 3065.
PCI: 00:12.0 [1106/3065] enabled
PCI: pci_scan_bus for bus 1
PCI: 01:00.0 [1106/3122] enabled
PCI: pci_scan_bus returning with max=01
vt1211 enabling PNP devices.
PNP: 002e.1 enabled
vt1211 enabling PNP devices.
PNP: 002e.2 enabled
vt1211 enabling PNP devices.
PNP: 002e.3 enabled
vt1211 enabling PNP devices.
PNP: 002e.b enabled
PNP: 002e.0 enabled
PCI: pci_scan_bus returning with max=01
done
Allocating resources...
Reading resources...
Done reading resources.
Setting resources...
I would set ram size to 0x40000 Kbytes
PCI: 00:10.0 20 <- [0x0000001800 - 0x000000181f] io
PCI: 00:10.1 20 <- [0x0000001820 - 0x000000183f] io
PCI: 00:10.2 20 <- [0x0000001840 - 0x000000185f] io
PCI: 00:10.3 10 <- [0x00febff000 - 0x00febff0ff] mem
PNP: 002e.1 60 <- [0x0000000378 - 0x000000037f] io
PNP: 002e.1 70 <- [0x0000000007 - 0x0000000007] irq
PNP: 002e.1 74 <- [0x0000000003 - 0x0000000003] drq
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
PNP: 002e.b 60 <- [0x000000ec00 - 0x000000ecff] io
ERROR: PNP: 002e.0 60 io size: 0x0000000008 not assigned
ERROR: PNP: 002e.0 60 irq size: 0x0000000001 not assigned
ERROR: PNP: 002e.0 60 drq size: 0x0000000001 not assigned
PCI: 00:11.1 20 <- [0x0000001860 - 0x000000186f] io
PCI: 00:11.5 10 <- [0x0000001000 - 0x00000010ff] io
PCI: 00:12.0 10 <- [0x0000001400 - 0x00000014ff] io
PCI: 00:12.0 14 <- [0x00fec00000 - 0x00fec000ff] mem
Done setting resources.
Done allocating resources.
Enabling resources...
PCI: 00:00.0 cmd <- 146
PCI: 00:01.0 bridge ctrl <- 000f
PCI: 00:01.0 cmd <- 147
PCI: 01:00.0 cmd <- 140
PCI: 00:10.0 subsystem <- 00/00
PCI: 00:10.0 cmd <- 141
PCI: 00:10.1 subsystem <- 00/00
PCI: 00:10.1 cmd <- 141
PCI: 00:10.2 subsystem <- 00/00
PCI: 00:10.2 cmd <- 141
PCI: 00:10.3 subsystem <- 00/00
PCI: 00:10.3 cmd <- 142
PCI: 00:11.0 cmd <- 147
PNP: 002e.1 - enabling
PNP: 002e.2 - enabling
PNP: 002e.3 - enabling
PNP: 002e.b - enabling
PNP: 002e.0 - enabling
PCI: 00:11.1 cmd <- 147
PCI: 00:11.5 subsystem <- 00/00
PCI: 00:11.5 cmd <- 141
PCI: 00:12.0 cmd <- 1c3
done.
Initializing devices...
Root Device init
PCI: 00:10.0 init
PCI: 00:10.1 init
PCI: 00:10.2 init
PCI: 00:10.3 init
PCI: 00:11.0 init
vt8235 init
RTC Init
Invalid CMOS LB checksum
pci_routing_fixup: dev is 000107c0
setting firewire
setting usb
Assigning IRQ 5 to 0:10.0
  Readback = 5
pci_level_irq: lower order bits are wrong: want 0x0, got 0x20
Assigning IRQ 9 to 0:10.1
  Readback = 9
pci_level_irq: lower order bits are wrong: want 0x0, got 0x20
Assigning IRQ 9 to 0:10.2
  Readback = 9
pci_level_irq: lower order bits are wrong: want 0x0, got 0x20
Assigning IRQ 5 to 0:10.3
  Readback = 5
pci_level_irq: lower order bits are wrong: want 0x0, got 0x20
setting vt8235
Assigning IRQ 5 to 0:11.1
  Readback = 5
pci_level_irq: lower order bits are wrong: want 0x0, got 0x20
Assigning IRQ 9 to 0:11.5
  Readback = 9
pci_level_irq: lower order bits are wrong: want 0x0, got 0x20
setting ethernet
Assigning IRQ 5 to 0:12.0
  Readback = 5
pci_level_irq: lower order bits are wrong: want 0x0, got 0x20
setting vga
Assigning IRQ 5 to 1:0.0
  Readback = 5
pci_level_irq: lower order bits are wrong: want 0x0, got 0x20
setting pci slot
setting cardbus slot
setting riser slot
PNP: 002e.1 init
PNP: 002e.2 init
PNP: 002e.3 init
PNP: 002e.b init
PCI: 00:11.1 init
Enabling VIA IDE.
ide_init: enabling compatibility IDE addresses
enables in reg 0x42 0x0
enables in reg 0x42 read back as 0x0
enables in reg 0x40 0x13
enables in reg 0x40 read back as 0x13
enables in reg 0x9 0x8a
enables in reg 0x9 read back as 0x8a
command in reg 0x4 0x7
command in reg 0x4 reads back as 0x7
PCI: 00:11.5 init
PCI: 00:12.0 init
Configuring VIA Rhine LAN
APIC_CLUSTER: 0 init
Initializing CPU #0
CPU: vendor Centaur device 673
Enabling cache

Setting fixed MTRRs(0-88) type: UC
Setting fixed MTRRs(0-16) Type: WB
Setting fixed MTRRs(24-88) Type: WB
DONE fixed MTRRs
Setting variable MTRR 0, base:    0MB, range:  128MB, type WB
Setting variable MTRR 1, base:  128MB, range:   64MB, type WB
Setting variable MTRR 2, base:  192MB, range:   32MB, type WB
DONE variable MTRRs
Clear out the extra MTRR's

MTRR check
Fixed MTRRs   : Enabled
Variable MTRRs: Enabled

Disabling local apic...done.
CPU #0 Initialized
PCI: 00:00.0 init
VT8623 random fixup ...
Frame buffer at d0000000
PCI: 00:01.0 init
VT8623 AGP random fixup ...
PCI: 01:00.0 init
VGA random fixup ...
INSTALL REAL-MODE IDT
DO THE VGA BIOS
found VGA: vid=1106, did=3122
rom base, size: fffc0000
write_protect_vgabios
bus/devfn = 0x100
biosint: INT# 0x15
biosint: eax 0x5f00 ebx 0x18538 ecx 0x17fa8 edx 0x12
biosint: ebp 0x17f84 esp 0xff2 edi 0xed10 esi 0xffff6f55
biosint:  ip 0x637f   cs 0xc000  flags 0x46
biosint: INT# 0x1a
biosint: eax 0xb108 ebx 0x10000 ecx 0x10000 edx 0x3d5
biosint: ebp 0x17f84 esp 0xfcc edi 0xf6 esi 0xffff55eb
biosint:  ip 0x40da   cs 0xc000  flags 0x46
0xb108: bus 0 devfn 0x0 reg 0xf6 val 0x12
biosint: INT# 0x15
biosint: eax 0x5f0f ebx 0x18538 ecx 0x7fa8 edx 0x3d5
biosint: ebp 0x17f84 esp 0xfee edi 0x44 esi 0xffff6f55
biosint:  ip 0x647e   cs 0xc000  flags 0x7
biosint: INT# 0x15
biosint: eax 0x5f02 ebx 0x18538 ecx 0x7f01 edx 0x3d5
biosint: ebp 0x17f84 esp 0xfdc edi 0x44 esi 0xffff6f55
biosint:  ip 0x63cb   cs 0xc000  flags 0x46
biosint: INT# 0x15
biosint: eax 0x5f18 ebx 0x18501 ecx 0x7fa8 edx 0x3d5
biosint: ebp 0x17f84 esp 0xfde edi 0x44 esi 0xffff6f55
biosint:  ip 0x6496   cs 0xc000  flags 0x46
biosint: INT# 0x15
biosint: eax 0x5f06 ebx 0x18001 ecx 0x1 edx 0x0
biosint: ebp 0x10fd6 esp 0xfa4 edi 0x0 esi 0xffff4672
biosint:  ip 0x63dc   cs 0xc000  flags 0x246
biosint: INT# 0x15
biosint: eax 0x5f08 ebx 0x10d01 ecx 0x8301 edx 0xd4
biosint: ebp 0x10fd6 esp 0xfa4 edi 0x0 esi 0xffff0d0e
biosint:  ip 0x63e8   cs 0xc000  flags 0x246
PNP: 002e.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.
ACPI: Writing ACPI tables at f0400...
ACPI:     * FACS
ACPI:     * DSDT @ 000f049e Length 3f0
ACPI:     * FADT
ACPI: added table 1/5 Length now 40
ACPI: done.
Moving GDT to 0x500...ok
Wrote linuxbios table at: 00000530 - 00000b80  checksum e5ca

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

    33:stream_init() - rom_stream: 0xfffd0000 - 0xfffeffff
Found ELF candiate at offset 0
New segment addr 0x100000 size 0x204a0 offset 0xc0 filesize 0x6508
(cleaned up) New segment addr 0x100000 size 0x204a0 offset 0xc0 filesize
0x6508
New segment addr 0x1204a0 size 0x48 offset 0x65e0 filesize 0x48
(cleaned up) New segment addr 0x1204a0 size 0x48 offset 0x65e0 filesize 0x48
Dropping non PT_LOAD segment
Dropping non PT_LOAD segment
Loading Segment: addr: 0x0000000000100000 memsz: 0x00000000000204a0 filesz:
0x0000000000006508
Clearing Segment: addr: 0x0000000000106508 memsz: 0x0000000000019f98
Loading Segment: addr: 0x00000000001204a0 memsz: 0x0000000000000048 filesz:
0x0000000000000048
Jumping to boot code at 0x10480c
FILO version 0.4.2 (root at embedded) Fri May  5 19:02:14 PDT 2006
Press <Enter> for default boot, or <Esc> for boot prompt... 1 
boot: hda1:/boot/vmlinuz root=/dev/hda1 console=tty0 lpj=2136847
dhash_entries=4000 ide0=0x1f0,0x3f6,14 ide0=noprobe ide1=noprobe
ide2=noprobe ide3=noprobe ide4=noprobe ide5=noprobe hda=65535,16,63 hdb=none
hdc=noprobe hdd=none no_hlt  console=ttyS0,115200
hda: LBA 80GB: WDC WD800JB-00FMA0
Mounted ext2fs
Found Linux version 2.6.16.5 (root at ep) #4 Wed Apr 26 09:34:01 PDT 2006
bzImage.
Loading kernel... ok
Jumping to entry point...
[00000.00000] Linux version 2.6.16.5 (root at ep) (gcc version 3.4.5 20050809
(prerelease) (Ubuntu 3.4.4-6ubuntu8.1)) #4 Wed Apr 26 09:34:01 PDT 2006
[00000.00000] BIOS-provided physical RAM map:
[00000.00000]  BIOS-e820: 0000000000000be0 - 00000000000a0000 (usable)
[00000.00000]  BIOS-e820: 0000000000100000 - 000000000e000000 (usable)
[00000.00000] 0MB HIGHMEM available.
[00000.00000] 224MB LOWMEM available.
[00000.00000] DMI 2.2 present.
[00000.00000] ACPI: PM-Timer IO Port: 0x408
[00000.00000] Allocating PCI resources starting at 10000000 (gap:
0e000000:f2000000)
[00000.00000] Built 1 zonelists
[00000.00000] Kernel command line: root=/dev/hda1 console=tty0 lpj=2136847
dhash_entries=4000 ide0=0x1f0,0x3f6,14 ide0=noprobe ide1=noprobe
ide2=noprobe ide3=noprobe ide4=noprobe ide5=noprobe hda=65535,16,63 hdb=none
hdc=noprobe hdd=none no_hlt console=ttyS0,115200
[00000.00000] ide_setup: ide0=0x1f0,0x3f6,14
[00000.00000]  -- OBSOLETE OPTION, WILL BE REMOVED SOON!
[00000.00000] ide_setup: ide0=noprobe
[00000.00000] ide_setup: ide1=noprobe
[00000.00000] ide_setup: ide2=noprobe
[00000.00000] ide_setup: ide3=noprobe
[00000.00000] ide_setup: ide4=noprobe
[00000.00000] ide_setup: ide5=noprobe
[00000.00000] ide_setup: hda=65535,16,63
[00000.00000] ide_setup: hdb=none
[00000.00000] ide_setup: hdc=noprobe
[00000.00000] ide_setup: hdd=none
[00000.00000] No local APIC present or hardware disabled
[00000.00000] Initializing CPU#0
[00000.00000] PID hash table entries: 1024 (order: 10, 16384 bytes)
[00000.00000] Detected 533.151 MHz processor.
[00000.00000] Using pmtmr for high-res timesource
[00000.00000] Console: colour VGA+ 80x25
[00000.00000] Dentry cache hash table entries: 4096 (order: 2, 16384 bytes)
[00000.00000] Inode-cache hash table entries: 16384 (order: 4, 65536 bytes)
[00000.00000] Memory: 224128k/229376k available (1666k kernel code, 4848k
reserved, 622k data, 148k init, 0k highmem)
[00000.00000] Checking if this processor honours the WP bit even in
supervisor mode... Ok.
[00000.00000] Calibrating delay loop (skipped)... 1068.42 BogoMIPS preset
[00000.00000] Security Framework v1.0.0 initialized
[00000.00000] SELinux:  Disabled at boot.
[00000.00000] Mount-cache hash table entries: 512
[00000.00000] CPU: L1 I Cache: 64K (32 bytes/line), D cache 64K (32
bytes/line)
[00000.00000] CPU: L2 Cache: 64K (32 bytes/line)
[00000.00000] CPU: Centaur VIA Samuel 2 stepping 03
[00000.00000] Checking 'hlt' instruction... OK.
[00000.00000] ACPI: setting ELCR to 0020 (from 0220)
[00000.00000] NET: Registered protocol family 16
[00000.00000] ACPI: bus type pci registered
[00000.00000] PCI: PCI BIOS revision 2.10 entry at 0xfa960, last bus=1
[00000.00000] PCI: Using configuration type 1
[00000.00000] ACPI: Subsystem revision 20060127
[00000.00000] ACPI: Interpreter enabled
[00000.00000] ACPI: Using PIC for interrupt routing
[00000.00000] ACPI: PCI Interrupt Link [LNKA] (IRQs *5 9 10)
[00000.00000] ACPI: PCI Interrupt Link [LNKB] (IRQs 5 *9 10)
[00000.00000] ACPI: PCI Interrupt Link [LNKC] (IRQs 5 *9 10)
[00000.00000] ACPI: PCI Interrupt Link [LNKD] (IRQs *5 9 10)
[00000.00000] ACPI: PCI Root Bridge [PCI0] (0000:00)
[00000.00000] PCI quirk: region 0400-047f claimed by vt8235 PM
[00000.00000] PCI quirk: region 0f00-0f0f claimed by vt8235 SMB
[00000.00000] Linux Plug and Play Support v0.97 (c) Adam Belay
[00000.00000] pnp: PnP ACPI init
[00000.00000] pnp: PnP ACPI: found 0 devices
[00000.00000] usbcore: registered new driver usbfs
[00000.00000] usbcore: registered new driver hub
[00000.00000] PCI: Using ACPI for IRQ routing
[00000.00000] PCI: If a device doesn't work, try "pci=routeirq".  If it
helps, post a report
[00000.00000] general protection fault: 3120 [#1]
[00000.00000] Modules linked in:
[00000.00000] CPU:    0
[00000.00000] EIP:    0060:[<c00faa2c>]    Not tainted VLI
[00000.00000] EFLAGS: 00010013   (2.6.16.5 #4)
[00000.00000] EIP is at 0xc00faa2c
[00000.00000] eax: 0000b102   ebx: c13f7400   ecx: 00003123   edx: 00001106
[00000.00000] esi: 00000000   edi: c03016cc   ebp: 00000000   esp: c11fff76
[00000.00000] ds: 007b   es: 007b   ss: 0068
[00000.00000] Process swapper (pid: 1, threadinfo=c11fe000 task=c11fba70)
[00000.00000] Stack: <0>31230000 c03016cc c00fa97c 0000b102 00001106
072c0246 0060c024 74000000
[00000.00000]        0000c13f 00000000 09fb0000 1106c024 31230000 00000000
ffba0000 ffbbc11f
[00000.00000]        0000c11f ffbc0000 ffbcc11f 1274c11f 0000c036 00000000
7d150000 06fbc035
[00000.00000] Call Trace:
[00000.00000] Code: cb 87 db b4 81 f9 c3 e8 aa 03 00 00 ba 50 43 49 20 66 b8
11 00 66 bb 10 02 f8 c3 57 66 51 66 56 66 83 fa ff 75 05 b4 83 f9 eb 53 <66>
cb f9 c1 e7 10 66 8b fa e8 7d 03 00 00 8a d9 32 ff 32 ed 80
[00000.00000]  <0>Kernel panic - not syncing: Attempted to kill init!
[00000.00000]



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




From eric at zyxod.com  Mon May  8 17:23:23 2006
From: eric at zyxod.com (Eric Poulsen)
Date: Mon, 08 May 2006 08:23:23 -0700
Subject: [LinuxBIOS] LB vs Factory BIOS -- more weirdness
In-Reply-To: <8a0c36780605060929x79ae210aw1a31014636f0e5e1@mail.gmail.com>
References: <445C4C04.6090302@zyxod.com>
	<8a0c36780605060929x79ae210aw1a31014636f0e5e1@mail.gmail.com>
Message-ID: <445F626B.5090801@zyxod.com>

Richard,

I originally posted two serial captures from a "good" lb boot, and one 
where it crashes.  I hadn't realized it at the time, but the block of 
hex numbers at the top of each is a dump of the northbridge 
configuration space.  They are identical.  Going on the assumption that 
if the PCI configurations are the same, then the chip must be configured 
correctly, I must assume that the problem lies with the south bridge ... 
Or am I way off?

Unfortunately, LB doesn't dump the south bridge to serial -- I'm working 
on changing that =)

Richard Smith wrote:
>> suggested that there are chipset registers that are reset by the factory
>> BIOS that LB isn't (re)setting correctly, and that LB works well right
>> after using the factory BIOS because those registers hold their values
>> for a while.
>>     
>
> Do a 'lspci -xxx' diff on the north and southbridges beween factory
> and LB and investigate all the differences.
>
> --
> Richard A. Smith
>
>   




From eric at zyxod.com  Mon May  8 17:29:11 2006
From: eric at zyxod.com (Eric Poulsen)
Date: Mon, 08 May 2006 08:29:11 -0700
Subject: [LinuxBIOS] LB vs Factory BIOS -- more weirdness
In-Reply-To: <LBEPJONEBEDMPPCKLBBIOEAJCEAA.nick.barker9@btinternet.com>
References: <LBEPJONEBEDMPPCKLBBIOEAJCEAA.nick.barker9@btinternet.com>
Message-ID: <445F63C7.4010100@zyxod.com>

Nick,

When I bought that ram, I was looking for "low profile" ram so that 
everything would fit into my tiny case.  That was either the only speed 
they had or the lowest speed ram they had in low profile.  I have a lot 
of ram lying around -- I can try different ones.

One question -- why would this problem be 'fixed' by allowing the 
Factory Bios to set some registers?  Or are you referring to the DMA 
lock issues?

Nick Barker wrote:
> Eric
>
> One further observation re this locking up is that you seem to be using
> fast memory compared to the speed of the chipset. The debug output:
>
> CAS Supported 2 2.5 3
> Cycle time at CL X     (nS)50
> Cycle time at CL X-0.5 (nS)60
> Cycle time at CL X-1   (nS)75
> Starting at CAS 3
> We can do CAS 2.5
> We can do CAS 2
>
> tells me that LB has spotted memory rated as DDR400, and is consequently
> trying to use it with a 'tuned' CAS setting of only 2. DDR266 usually
> works at CAS of 2.5 or 3. It 'MAY' be the case that working the chipset /
> memory interface at this 'tuned' setting is marginal - OK under memtest,
> but as soon as you have other bus masters trying to access the memory as
> well then you get problems.
>
> You could test out this hypothesis by forcing CAS of 2.5 or 3 in the memory
> detection routines. Should be easy to do since the code starts out with 3
> and then decides if it could do better. Simply comment out those tests.
>
> Or try it out with DDR266.
>
> Nick Barker
>   




From eric at zyxod.com  Mon May  8 17:49:20 2006
From: eric at zyxod.com (Eric Poulsen)
Date: Mon, 08 May 2006 08:49:20 -0700
Subject: [LinuxBIOS] Need: PCI FIXUP HOWTO (was: LB vs Factory BIOS -- more
	weirdness)
In-Reply-To: <445C4C04.6090302@zyxod.com>
References: <445C4C04.6090302@zyxod.com>
Message-ID: <445F6880.7080201@zyxod.com>

I've dived into the northbridge/southbridge fixup code in LB, in 
response to Richard Smith's suggestion that I check for differences in 
the PCI configuration space between the Factory and LB boots.  I've 
learned a lot about how PCI works, but I've got a long ways to go.

Here's what I've noticed:

Some of the data in 0x00 --> 0x3f is different.  I'm guessing this isn't 
a big deal, since (in theory) the  kernel knows how to deal with the 
"standard" PCI registers, and some of them (IRQ/IO port settings) 
can/will be different.  Is my assumption correct?

Some of the values in the higher addresses are different.  Some of the 
values are placed there by the PCI fixup, and many match the values 
found when running the factory BIOS.  Oddly, some of the values placed 
by the fixup are different, but the 'lspci' output is the same.  For 
example, the fixup calls:

pci_write_config32(dev, 0x88, 0x00000002);

However, the value in the configuration for lb and factory after boot is:

Factory:  80: 0f 65 00 00 80 00 00 00 _03 00 d6 0c_ 00 00 00 00
     LB:  80: 0f 65 00 00 80 00 00 00 _03 00 98 0c_ 00 00 00 00

There's a 0x03 byte in location 0x88, and the upper word is NOT zeroes 
on either one of them.  This leads me to believe that either the chip 
itself changed the value, or the Kernel did.

Of course, there may be other LB code sections that put more/different 
values into the northbridge PCI config.

Is there anyone who can give me some tips on extracting the "magic 
fixups" from a factory BIOS?  I know that there are probably newer 
factory BIOSes since LB was ported to the Epia M.


Eric Poulsen wrote:
> In response to the instability issues I've had with LB (It's not ram -- 
> memtest86+ ran for hours under LB with no errors), someone here 
> suggested that there are chipset registers that are reset by the factory 
> BIOS that LB isn't (re)setting correctly, and that LB works well right 
> after using the factory BIOS because those registers hold their values 
> for a while.
>
> I'm conviced this is the case -- I have too many weird issues that can 
> be fixed by simply flipping back to the factory BIOS, turning the system 
> on, getting a "bad CMOS" error, then immediately powering off and 
> switching to LB, which suddenly works again.
>
> I'm pretty sure the DMA transfer under Linux bug (this is a chipset bug 
> specific to some Epia models that can be fixed (in theory) with a BIOS 
> upgrade) is exhibiting itself -- I get hard locks with the HD light on 
> when xferring larger files.  It's really easy to reproduce.  I tried to 
> lock it under the factory bios, but it wouldn't lock.  After I rebooted 
> using LB, the problem went away in LB as well.  This tends to support 
> the "chipset register remembrance" theory.
>
> Here's the latest.  The full serial caps are at the bottom, but here are 
> the differences.  I set all the kernel times to zero so that diff would 
> work.
>
> Differences in LB output:
>
>  Crash: Low Bond 00  High Bondc0  Setting DQS delay80vt8623 done
> Worked: Low Bond 00  High Bondc1  Setting DQS delay80vt8623 done
>
> I'm no expert, but this appears to be looking for a range of usable RAM 
> under 1M.  Should the High Bond values be different, ever?
>
> Differences in kernel output:
>  Crash: [00000.00000] DMI 2.2 present.
> Worked: [00000.00000] DMI not present or invalid.
>
> I'm not sure if this is relevant or not ...
>
>
> And finally, the crash itself:
>
>   [00000.00000] PCI: If a device doesn't work, try "pci=routeirq".  If 
> it helps, post a report
>   [00000.00000] general protection fault: 3120 [#1]
>   [00000.00000] Modules linked in:
>   [00000.00000] CPU:    0
>   [00000.00000] EIP:    0060:[<c00faa2c>]    Not tainted VLI
>   [00000.00000] EFLAGS: 00010013   (2.6.16.5 #4)
>   [00000.00000] EIP is at 0xc00faa2c
>   [00000.00000] eax: 0000b102   ebx: c13f7400   ecx: 00003123   edx: 
> 00001106
>   [00000.00000] esi: 00000000   edi: c03016cc   ebp: 00000000   esp: 
> c11fff76
>   [00000.00000] ds: 007b   es: 007b   ss: 0068
>   [00000.00000] Process swapper (pid: 1, threadinfo=c11fe000 task=c11fba70)
>   [00000.00000] Stack: <0>31230000 c03016cc c00fa97c 0000b102 00001106 
> 072c0246 0060c024 74000000
>   [00000.00000]        0000c13f 00000000 09fb0000 1106c024 31230000 
> 00000000 ffba0000 ffbbc11f
>   [00000.00000]        0000c11f ffbc0000 ffbcc11f 1274c11f 0000c036 
> 00000000 7d150000 06fbc035
>   [00000.00000] Call Trace:
>   [00000.00000] Code: cb 87 db b4 81 f9 c3 e8 aa 03 00 00 ba 50 43 49 20 
> 66 b8 11 00 66 bb 10 02 f8 c3 57 66 51 66 56 66 83   fa ff 75 05 b4 83 
> f9 eb 53 <66> cb f9 c1 e7 10 66 8b fa e8 7d 03 00 00 8a d9 32 ff 32 ed 80
>   [00000.00000]  <0>Kernel panic - not syncing: Attempted to kill init!
>   [00000.00000]
>




From chris at suehsi.de  Mon May  8 19:27:07 2006
From: chris at suehsi.de (=?ISO-8859-1?Q?Christian_S=FChs?=)
Date: Mon, 08 May 2006 19:27:07 +0200
Subject: [LinuxBIOS] MB1030 / 3036 VGA resume
In-Reply-To: <4459C0FE.6070104@suehsi.de>
References: <8a0c36780605011259p721fb330j4d640fc17857cae8@mail.gmail.com>	<445733D0.6050004@suehsi.de>	<44575B60.7050406@suehsi.de>	<8a0c36780605020731w7d9d7048g524d640b4d3ed665@mail.gmail.com>	<44578BAB.80008@suehsi.de>	<44579320.90206@suehsi.de>	<8a0c36780605020925h6110f2d8pa656fde32cc5adfb@mail.gmail.com>	<4457ADD6.8020608@suehsi.de>	<20060502192823.GC4620@coresystems.de>	<4457CB2A.4030908@suehsi.de>	<20060502205654.GB11460@coresystems.de>	<44586CDF.2060809@suehsi.de>
	<4458D0C3.7020308@lanl.gov> <4459C0FE.6070104@suehsi.de>
Message-ID: <445F7F6B.9060309@suehsi.de>


> First:
> 
> The whole boottime is slow.
> Lb is 15s slower as the factory bios in kernel booting.
> 
> 1. copying LB to RAM seems slow.
> 2. copying kernel and intitrd.gz to RAM seems slow
> 3. uncompressing kernel seems slow.
> 
> All operations to or in RAM seems to be 3 times slower as under factory.


Can somebody have a look to the gx1 datasheet on page 42 - 50.

I'm not sure, but CR0 (Control Register 0) is set to 60000010h after a 
hardware reset.
That means, that the 16K L1 Cache is disabled !?

I can't see any code in LB which enables L1 cache on cpu init.

Could somebody compare this.

chris



From stuge-linuxbios at cdy.org  Mon May  8 21:09:02 2006
From: stuge-linuxbios at cdy.org (Peter Stuge)
Date: Mon, 8 May 2006 21:09:02 +0200
Subject: [LinuxBIOS] MB1030 / 3036 VGA resume
In-Reply-To: <445F7F6B.9060309@suehsi.de>
References: <44579320.90206@suehsi.de>
	<8a0c36780605020925h6110f2d8pa656fde32cc5adfb@mail.gmail.com>
	<4457ADD6.8020608@suehsi.de> <20060502192823.GC4620@coresystems.de>
	<4457CB2A.4030908@suehsi.de>
	<20060502205654.GB11460@coresystems.de>
	<44586CDF.2060809@suehsi.de> <4458D0C3.7020308@lanl.gov>
	<4459C0FE.6070104@suehsi.de> <445F7F6B.9060309@suehsi.de>
Message-ID: <20060508190903.27473.qmail@cdy.org>

On Mon, May 08, 2006 at 07:27:07PM +0200, Christian S?hs wrote:
> Can somebody have a look to the gx1 datasheet on page 42 - 50.
> 
> I'm not sure, but CR0 (Control Register 0) is set to 60000010h
> after a hardware reset.
> That means, that the 16K L1 Cache is disabled !?

Yep.


> I can't see any code in LB which enables L1 cache on cpu init.
> 
> Could somebody compare this.

Hmm.

--8<-- include/cpu/x86/cache.h
static inline void enable_cache(void)
{
        unsigned long cr0;
        cr0 = read_cr0();
        cr0 &= 0x9fffffff;
        write_cr0(cr0);
}
-->8--

--8<-- cpu/x86/cache/cache.c
void x86_enable_cache(void)
{
        post_code(0x60);
        printk_info("Enabling cache\n");
        enable_cache();
}
-->8--

--8<-- cpu/amd/model_gx1/model_gx1_init.c
static void model_gx1_init(device_t dev)
{
#if 0
        gx1_cpu_setup();
        gx1_gx_setup();
#endif
        /* Turn on caching if we haven't already */
        x86_enable_cache();

        /* Enable the local cpu apics */
        setup_lapic();
};

..

static struct device_operations cpu_dev_ops = {
        .init   = model_gx1_init,
};

-->8--

--8<-- cpu/amd/model_gx1/Config.lb
dir /cpu/x86/cache
driver model_gx1_init.o
-->8--

--8<-- Message-ID: <43A551D8.5060208 at suehsi.de> (Dec 2005)
Initializing CPU #0   
CPU: vendor Centaur device 698
Enabling cache
-->8--

That email is the only one I found from you to the list where
Enabling cache occurs. Check your serial output to see if it's still
there, as it should be.


//Peter



From chris at suehsi.de  Mon May  8 21:21:07 2006
From: chris at suehsi.de (=?ISO-8859-1?Q?Christian_S=FChs?=)
Date: Mon, 08 May 2006 21:21:07 +0200
Subject: [LinuxBIOS] MB1030 / 3036 VGA resume
In-Reply-To: <20060508190903.27473.qmail@cdy.org>
References: <44579320.90206@suehsi.de>	<8a0c36780605020925h6110f2d8pa656fde32cc5adfb@mail.gmail.com>	<4457ADD6.8020608@suehsi.de>
	<20060502192823.GC4620@coresystems.de>	<4457CB2A.4030908@suehsi.de>	<20060502205654.GB11460@coresystems.de>	<44586CDF.2060809@suehsi.de>
	<4458D0C3.7020308@lanl.gov>	<4459C0FE.6070104@suehsi.de>
	<445F7F6B.9060309@suehsi.de> <20060508190903.27473.qmail@cdy.org>
Message-ID: <445F9A23.3070602@suehsi.de>

Peter Stuge schrieb:
> On Mon, May 08, 2006 at 07:27:07PM +0200, Christian S?hs wrote:
> 
>>Can somebody have a look to the gx1 datasheet on page 42 - 50.
>>
>>I'm not sure, but CR0 (Control Register 0) is set to 60000010h
>>after a hardware reset.
>>That means, that the 16K L1 Cache is disabled !?
> 
> 
> Yep.
> 
> 
> 
>>I can't see any code in LB which enables L1 cache on cpu init.
>>
>>Could somebody compare this.
> 
> 
> Hmm.
> 
> --8<-- include/cpu/x86/cache.h
> static inline void enable_cache(void)
> {
>         unsigned long cr0;
>         cr0 = read_cr0();
>         cr0 &= 0x9fffffff;
>         write_cr0(cr0);
> }
> -->8--
> 

Well, I have seen that code, but what about the registers.
Is cache enabling a standard x86 prozedur?

> 
> --8<-- cpu/amd/model_gx1/Config.lb
> dir /cpu/x86/cache
> driver model_gx1_init.o
> -->8--
> 
> --8<-- Message-ID: <43A551D8.5060208 at suehsi.de> (Dec 2005)
> Initializing CPU #0   
> CPU: vendor Centaur device 698
> Enabling cache

That is my epia M Board ;)
Currently we talk about MB3036 from Allwell.

> -->8--
> 
> That email is the only one I found from you to the list where
> Enabling cache occurs. Check your serial output to see if it's still
> there, as it should be.
> 

Ok, I will have a look.
thanks

chris

> 
> //Peter
> 





From stuge-linuxbios at cdy.org  Mon May  8 21:41:50 2006
From: stuge-linuxbios at cdy.org (Peter Stuge)
Date: Mon, 8 May 2006 21:41:50 +0200
Subject: [LinuxBIOS] MB1030 / 3036 I like 13 :D
In-Reply-To: <445F9A23.3070602@suehsi.de>
References: <444D3E07.6010209@suehsi.de>
	<20060424201007.GA32112@coresystems.de>
	<444D4E7A.6040408@suehsi.de> <444D5318.3000707@suehsi.de>
	<444D5610.7050207@suehsi.de>
	<20060424220735.GA15237@coresystems.de>
	<444DE14C.8050402@suehsi.de> <444E50A4.9080208@suehsi.de>
	<444E44F9.3080107@lanl.gov> <444E64BA.40306@suehsi.de>
Message-ID: <20060508194151.31416.qmail@cdy.org>

On Mon, May 08, 2006 at 09:21:07PM +0200, Christian S?hs wrote:
> That is my epia M Board ;)
> Currently we talk about MB3036 from Allwell.

Oops. Sorry. :)


On Tue, Apr 25, 2006 at 08:04:42PM +0200, Christian S?hs wrote:
> LinuxBIOS-1.1.8.0Fallback Tue Apr 25 19:44:31 CEST 2006 starting...

[...]

No "Enabling cache" in there..


//Peter



From chris at suehsi.de  Mon May  8 21:41:47 2006
From: chris at suehsi.de (=?ISO-8859-1?Q?Christian_S=FChs?=)
Date: Mon, 08 May 2006 21:41:47 +0200
Subject: [LinuxBIOS] MB1030 / 3036 VGA resume
In-Reply-To: <445F9A23.3070602@suehsi.de>
References: <44579320.90206@suehsi.de>	<8a0c36780605020925h6110f2d8pa656fde32cc5adfb@mail.gmail.com>	<4457ADD6.8020608@suehsi.de>	<20060502192823.GC4620@coresystems.de>	<4457CB2A.4030908@suehsi.de>	<20060502205654.GB11460@coresystems.de>	<44586CDF.2060809@suehsi.de>	<4458D0C3.7020308@lanl.gov>	<4459C0FE.6070104@suehsi.de>	<445F7F6B.9060309@suehsi.de>
	<20060508190903.27473.qmail@cdy.org> <445F9A23.3070602@suehsi.de>
Message-ID: <445F9EFB.5010303@suehsi.de>


>>Enabling cache occurs. Check your serial output to see if it's still
>>there, as it should be.
>>
> 
> 
> Ok, I will have a look.
> thanks
> 


Enable Caching is debugged with printk_info. Therefore it should shown 
under LogLevel 8

But I can't see this stuff in the current log file.
Furthermore, I have never seen this message :(


What happens here?!

What could be the reasons for failing?

chris


-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: currentlb.cap
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20060508/c136e50f/attachment.ksh>

From rminnich at lanl.gov  Mon May  8 21:59:14 2006
From: rminnich at lanl.gov (Ronald G Minnich)
Date: Mon, 08 May 2006 13:59:14 -0600
Subject: [LinuxBIOS] MB1030 / 3036 VGA resume
In-Reply-To: <445F9EFB.5010303@suehsi.de>
References: <44579320.90206@suehsi.de>	<8a0c36780605020925h6110f2d8pa656fde32cc5adfb@mail.gmail.com>	<4457ADD6.8020608@suehsi.de>	<20060502192823.GC4620@coresystems.de>	<4457CB2A.4030908@suehsi.de>	<20060502205654.GB11460@coresystems.de>	<44586CDF.2060809@suehsi.de>	<4458D0C3.7020308@lanl.gov>	<4459C0FE.6070104@suehsi.de>	<445F7F6B.9060309@suehsi.de>	<20060508190903.27473.qmail@cdy.org>
	<445F9A23.3070602@suehsi.de> <445F9EFB.5010303@suehsi.de>
Message-ID: <445FA312.3050300@lanl.gov>

looking at these graphs, it sort of looks like what I used to see when 
l1 was on, but L2 is off. factory has two bumps: one at 16k, and one at 
256k.

linuxbios has a huge bump at 16k. But the results look incomplete. I 
have 3 graphs for factory and only one for linuxbios.

can we get all the graphs in the series? I am comparing factory2.ps and 
lb2.ps

ron



From chris at suehsi.de  Mon May  8 22:13:35 2006
From: chris at suehsi.de (=?ISO-8859-1?Q?Christian_S=FChs?=)
Date: Mon, 08 May 2006 22:13:35 +0200
Subject: [LinuxBIOS] MB1030 / 3036 VGA resume
In-Reply-To: <445F9EFB.5010303@suehsi.de>
References: <44579320.90206@suehsi.de>	<8a0c36780605020925h6110f2d8pa656fde32cc5adfb@mail.gmail.com>	<4457ADD6.8020608@suehsi.de>	<20060502192823.GC4620@coresystems.de>	<4457CB2A.4030908@suehsi.de>	<20060502205654.GB11460@coresystems.de>	<44586CDF.2060809@suehsi.de>	<4458D0C3.7020308@lanl.gov>	<4459C0FE.6070104@suehsi.de>	<445F7F6B.9060309@suehsi.de>	<20060508190903.27473.qmail@cdy.org>
	<445F9A23.3070602@suehsi.de> <445F9EFB.5010303@suehsi.de>
Message-ID: <445FA66F.3000309@suehsi.de>


> 
> Enable Caching is debugged with printk_info. Therefore it should shown 
> under LogLevel 8
> 
> But I can't see this stuff in the current log file.
> Furthermore, I have never seen this message :(
> 

There is also no CPU init.
Mmmmh, how is this done.

gx1_cpu_setup and gx1_gx_setup is done, because I'm able to change the 
BC_* registers and the other stuff.

but it seems, that the x86_enable_cache function is not called.

Sorry, currently I don't understand this.



> 
> What happens here?!
> 
> What could be the reasons for failing?
> 
> chris
> 
> 
> 




From scott at waye.co.uk  Mon May  8 23:38:12 2006
From: scott at waye.co.uk (scott)
Date: Mon, 08 May 2006 22:38:12 +0100
Subject: [LinuxBIOS] No VGA with EPIA-MII 6000
Message-ID: <445FBA44.2000900@waye.co.uk>

I am getting to grips with flashing my bios.  I have followed the
documentation in the EPIA_M HOWTO and I have flashed a couple bios'es
and my epia still works, so far so good.  I do not want a serial console
(I have the serial port connected to the car, so I dont want stuff going
down there), but I would like a VGA console.  I copied the
Config.vga.filo as it comes from svn to Config.lb (just changing the
path to filo.elf), but I get this after running buildtarget, then make:

"XIP_ROM_BASE is not a multiple of XIP_ROM_SIZE"
make[1]: *** [auto.inc] Error 1
make[1]: Leaving directory
`/home/scott/ibus/bios/LinuxBIOSv2/targets/via/epia-m/epia-m/normal'
make: *** [normal/linuxbios.rom] Error 1


So I went back to my Config.lb which did work (but with no VGA) and I
changed:

< option  CONFIG_CONSOLE_SERIAL8250=1
---
> option  CONFIG_CONSOLE_SERIAL8250=0
> option CONFIG_CONSOLE_VGA=1


in an attempt to turn off serial console and turn on the VGA console,
this builds fine, and boots, but with no VGA output.  I think I am
missing a trick here?

Anyone have a Config file for the EPIA M II 6000 with VGA enabled?

My Config file is below:

# Sample config file for EPIA-M
# This will make a target directory of ./epia-m

target epia-m

mainboard via/epia-m

option  MAXIMUM_CONSOLE_LOGLEVEL=8
option  DEFAULT_CONSOLE_LOGLEVEL=8
option  CONFIG_CONSOLE_SERIAL8250=0
option CONFIG_CONSOLE_VGA=1


option ROM_SIZE=256*1024
option HAVE_OPTION_TABLE=1
option CONFIG_ROM_STREAM=1
option HAVE_FALLBACK_BOOT=1

###
### Compute the location and size of where this firmware image
### (linuxBIOS plus bootloader) will live in the boot rom chip.
###
option FALLBACK_SIZE=0x30000

## LinuxBIOS C code runs at this location in RAM
option _RAMBASE=0x00004000

#
###
### Compute the start location and size size of
### The linuxBIOS bootloader.
###

#
# EPIA-M
#
#romimage "normal"
#    option USE_FALLBACK_IMAGE=0
#    option ROM_IMAGE_SIZE=0xc000
#    option ROM_SECTION_OFFSET=0x10000
#    option ROM_SECTION_SIZE=0x18000
#    option XIP_ROM_BASE=0xfffd0000
#    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 /filo.elf
#end

romimage "fallback"
    option USE_FALLBACK_IMAGE=1
    option ROM_IMAGE_SIZE=0x10000
    option ROM_SECTION_OFFSET=0x10000
    option ROM_SECTION_SIZE=0x30000
#    option XIP_ROM_BASE=0xfffe0000
    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.ebi
    payload /home/scott/ibus/bios/filo-0.5/filo.elf
end

buildrom ./linuxbios.rom ROM_SIZE  "fallback"





From hawke at hawkesnest.net  Tue May  9 07:34:13 2006
From: hawke at hawkesnest.net (Alex L. Mauer)
Date: Tue, 09 May 2006 00:34:13 -0500
Subject: [LinuxBIOS] EPIA non-M?
In-Reply-To: <8a0c36780604301307k4de0f25fx618aa50d97fd98be@mail.gmail.com>
References: <e30v1u$d74$1@sea.gmane.org>
	<4454342B.3080107@lanl.gov>	<e31mo9$2bj$1@sea.gmane.org>
	<8a0c36780604301307k4de0f25fx618aa50d97fd98be@mail.gmail.com>
Message-ID: <e3p9ls$nhr$1@sea.gmane.org>

Richard Smith wrote:

> What happens wne you boot with the current version?
> Don't try any  vga just do serial to start with.

Well, if I boot LB alone, I get the following (at debug level 9):

[line noise?]

LinuxBIOS-1.1.8.0Normal Mon May  8 23:51:16 CDT 2006 starting...
87 is the comm register
SMBus controller enabled
vt8601 init starting
00000000 is the north
                     1106 0601
0120d4 is the computed timing
                             NOP
PRECHARGE
DUMMY READS
CBR
MRS
NORMAL
set ref. rate
enable multi-page open
Slot 00 is SDRAM 08000000 bytes x2
0100 is the chip size
000e is the MA type
Slot 01 is SDRAM 08000000 bytes x2
0100 is the chip size
000e is the MA type
Slot 02 is empty
Slot 03 is empty
vt8601 done
Copying LinuxBIOS to ram.
Jumping to LinuxBIOS.

....But if I boot from the normal BIOS, and then do a soft reset, it
actually works...almost.  A transcript of that (not attaching as it's
about 16k) is available at
http://web.hawkesnest.net/users/hawke/minicom.cap.txt

interesting portion: it loads Linux (Ubuntu), and gets to:

 * Loading hardware drivers...
[   30.094223] Unable to handle kernel paging request at virtual address
89000005
[   30.118509]  printing eip:
[   30.127570] c0120468
[   30.134920] *pde = 00000000
[   30.144278] Oops: 0002 [#1]
[   30.153623] PREEMPT
[   30.161026] Modules linked in: evdev ext3 jbd dm_mod raid1 md_mod
ide_generic uhci_hcd usbcore ide_cd cdrom ide_disk via82cxxx generic
processor fbcon tileblit font bitblit softcursor capability commoncap
[   30.222441] CPU:    0
[   30.222446] EIP:    0060:[<c0120468>]    Not tainted VLI
[   30.222454] EFLAGS: 00010086   (2.6.15-22-386)
[   30.262820] EIP is at do_setitimer+0x98/0x6c0
[   30.277328] eax: 00000000   ebx: deca0000   ecx: de8724c0   edx: 00000000
[   30.299826] esi: de8724c0   edi: deca1fa8   ebp: df22f030   esp: deca1f2c
[   30.322318] ds: 007b   es: 007b   ss: 0068
[   30.335957] Process udevd (pid: 2741, threadinfo=deca0000 task=df22f030)
[   30.357457] Stack: 00000000 00000000 df1feb7c deca0000 c17b5850
b7e14080 c0150e05 df607560
[   30.385794]        deca7cd4 b7e14080 c17b5850 df1feb7c 00000000
00000000 df607560 de8724c0
[   30.414057]        deca7cd4 c0116a36 df607560 000000b4 00000003
08089d78 deca0000 c0125b62
[   30.442320] Call Trace:
[   30.451297]  [<c0150e05>] __handle_mm_fault+0xa5/0x210
[   30.468488]  [<c0116a36>] do_page_fault+0x216/0x61a
[   30.484823]  [<c0125b62>] sys_alarm+0x32/0x70
[   30.499452]  [<c0103089>] syscall_call+0x7/0xb
[   30.514367] Code: 04 00 00 83 c0 40 50 e8 57 4e 00 00 59 5e 85 c0 78
c1 8b 8d 6c 04 00 00 89 4c 24 3c 8b 7c 24 64 8b 07 8b 57 04 3d 54 c3 20
00 0f <87> 1d 05 00 00 89 c6 31 ff 89 54 24 0c 89 d0 c1 f8 1f 89 44 24
[   30.580230]  <6>note: udevd[2741] exited with preempt_count 1
[   32.620544] parport_pc: VIA 686A/8231 detected
[   32.635539] parport_pc: probing current configuration
[   32.652379] parport_pc: Current parallel port base: 0x378
[   32.670341] parport_pc: VIA parallel port disabled in BIOS
[   32.688650] parport: PnPBIOS parport detected.
[   32.703766] pnp: Device 00:10 disabled.
[   32.759075] pci_hotplug: PCI Hot Plug PCI Core version: 0.5
[   32.794165] shpchp: Standard Hot Plug PCI Controller Driver version: 0.4
[   32.940348] irda_init()
[   32.948760] NET: Registered protocol family 23
[   33.192448] Linux agpgart interface v0.101 (c) Dave Jones
[   33.219506] agpgart: Detected VIA Apollo ProMedia/PLE133Ta chipset
[line noise?] 23:51:25 CDT 2006 starting...

and then it looks like it resets several times, and finally appears to
give up.

Let me know what if any additional info would be helpful.

-Alex Mauer "hawke"
-- 
Bad - You get pulled over for doing 90 in a school zone and you're drunk
off your ass again at three in the afternoon.
Worse - The cop is drunk too, and he's a mean drunk.
FUCK! - A mean drunk that's actually a swarm of semi-sentient
flesh-eating beetles.
OpenPGP key id: 51192FF2 @ subkeys.pgp.net

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

From rminnich at lanl.gov  Tue May  9 07:31:30 2006
From: rminnich at lanl.gov (Ronald G Minnich)
Date: Mon, 08 May 2006 23:31:30 -0600
Subject: [LinuxBIOS] EPIA non-M?
In-Reply-To: <e3p9ls$nhr$1@sea.gmane.org>
References: <e30v1u$d74$1@sea.gmane.org>	<4454342B.3080107@lanl.gov>	<e31mo9$2bj$1@sea.gmane.org>	<8a0c36780604301307k4de0f25fx618aa50d97fd98be@mail.gmail.com>
	<e3p9ls$nhr$1@sea.gmane.org>
Message-ID: <44602932.4060203@lanl.gov>

some commit totally busted memory timings on non-M. I have not had time 
to even think about it.

thanks

ron



From chris at suehsi.de  Tue May  9 15:46:23 2006
From: chris at suehsi.de (=?ISO-8859-1?Q?Christian_S=FChs?=)
Date: Tue, 09 May 2006 15:46:23 +0200
Subject: [LinuxBIOS] MB1030 / 3036 VGA resume
In-Reply-To: <445FA66F.3000309@suehsi.de>
References: <44579320.90206@suehsi.de>	<8a0c36780605020925h6110f2d8pa656fde32cc5adfb@mail.gmail.com>	<4457ADD6.8020608@suehsi.de>	<20060502192823.GC4620@coresystems.de>	<4457CB2A.4030908@suehsi.de>	<20060502205654.GB11460@coresystems.de>	<44586CDF.2060809@suehsi.de>	<4458D0C3.7020308@lanl.gov>	<4459C0FE.6070104@suehsi.de>	<445F7F6B.9060309@suehsi.de>	<20060508190903.27473.qmail@cdy.org>	<445F9A23.3070602@suehsi.de>
	<445F9EFB.5010303@suehsi.de> <445FA66F.3000309@suehsi.de>
Message-ID: <44609D2F.3040305@suehsi.de>


> but it seems, that the x86_enable_cache function is not called.
> 
> Sorry, currently I don't understand this.
> 
> 
> 
> 
>>What happens here?!
>>
>>What could be the reasons for failing?


What about the Config.lb under the mainboard folder.
Most Boards enables the apic cluster, the eaglelion/5bcm does not.

I think all devices should be init, which are set to on in the Config file.

However, the CPU is not init by LB and therefor there is no L1 cache.
Can somebody have a second look to the eaglelion Config.lb under the 
mainboard folder. The file could be wrong.

Also it seems that the cpus normally enabled at last on other boards 
like the epia-m.  Enabling first should be better.

chris



From smithbone at gmail.com  Tue May  9 16:26:18 2006
From: smithbone at gmail.com (Richard Smith)
Date: Tue, 9 May 2006 09:26:18 -0500
Subject: [LinuxBIOS] EPIA non-M?
In-Reply-To: <44602932.4060203@lanl.gov>
References: <e30v1u$d74$1@sea.gmane.org> <4454342B.3080107@lanl.gov>
	<e31mo9$2bj$1@sea.gmane.org>
	<8a0c36780604301307k4de0f25fx618aa50d97fd98be@mail.gmail.com>
	<e3p9ls$nhr$1@sea.gmane.org> <44602932.4060203@lanl.gov>
Message-ID: <8a0c36780605090726p47464840kbd93d0607108aaee@mail.gmail.com>

On 5/9/06, Ronald G Minnich <rminnich at lanl.gov> wrote:
> some commit totally busted memory timings on non-M. I have not had time
> to even think about it.

Attached is the svn log for mods to vt8601 raminit.c.  Try pulling
some of these old versions and see if you can find one that works. 
Then you can diff it and we can see what changed.

Looking at the code I see many #defines that set memory speed and CL
timing.    You should check those out and see if they match your
board.

--
Richard A. Smith
-------------- next part --------------
------------------------------------------------------------------------
r1978 | arch | 2005-07-06 13:17:33 -0500 (Wed, 06 Jul 2005) | 7 lines

Revision: linuxbios at linuxbios.org--devel/freebios--devel--2.0--patch-60
Creator:  Li-Ta Lo <ollie at lanl.gov>

More Via EPIA 

more via epia stuff, including the trival but fatal bug in auto.c

------------------------------------------------------------------------
r1954 | arch | 2005-07-06 12:15:54 -0500 (Wed, 06 Jul 2005) | 7 lines

Revision: linuxbios at linuxbios.org--devel/freebios--devel--2.0--patch-38
Creator:  Li-Ta Lo <ollie at lanl.gov>

emulator update

x96emu update from Paulo

------------------------------------------------------------------------
r1952 | arch | 2005-07-06 12:15:48 -0500 (Wed, 06 Jul 2005) | 7 lines

Revision: linuxbios at linuxbios.org--devel/freebios--devel--2.0--patch-36
Creator:  Li-Ta Lo <ollie at lanl.gov>

emulator update

Correction to the reduce emulator from Paulo

------------------------------------------------------------------------
r1808 | mwrwilkinson | 2004-12-01 10:59:05 -0600 (Wed, 01 Dec 2004) | 2 lines

Updates to raminit.c correcting for new version of smbus_read_byte.

------------------------------------------------------------------------
r1726 | mwrwilkinson | 2004-10-29 11:16:43 -0500 (Fri, 29 Oct 2004) | 26 lines

Changes to allow Via/Epia code to be compiled after recent code changes.

New Files :-
	src/cpu/via/model_centaur/Config.lb
	src/cpu/via/model_centaur/model_centaur_init.c

Updated Files :-
	src/arch/i386/include/arch/smp/mpspec.h
		- make write_smp_table a define for non smp systems
	src/cpu/x86/lapic/lapic_cpu_init.c
		- change possible typo
	src/mainboard/via/epia/Config.lb
	src/mainboard/via/epia/Options.lb

	src/mainboard/via/epia/auto.c
	src/mainboard/via/epia/chip.h
	src/mainboard/via/epia/failover.c
		- updated after recent code changes
	src/northbridge/via/vt8601/chip.h
	src/northbridge/via/vt8601/northbridge.c
	src/northbridge/via/vt8601/raminit.c
		- corrections after recent code changes to allow compiling
	src/southbridge/via/vt8231/chip.h
	src/southbridge/via/vt8231/vt8231.c
		- initial pass to allow compiling after recent code changes.

------------------------------------------------------------------------
r1619 | rminnich | 2004-07-06 11:57:44 -0500 (Tue, 06 Jul 2004) | 3 lines


fixed again.

------------------------------------------------------------------------
r1618 | rminnich | 2004-07-06 11:35:50 -0500 (Tue, 06 Jul 2004) | 2 lines

fix for simple error

------------------------------------------------------------------------
r1259 | rminnich | 2003-11-05 13:55:20 -0600 (Wed, 05 Nov 2003) | 2 lines

fixes for epia, attempts to fix arima

------------------------------------------------------------------------
r1228 | rminnich | 2003-10-23 10:09:58 -0500 (Thu, 23 Oct 2003) | 2 lines

fixes from SONE

------------------------------------------------------------------------
r1227 | rminnich | 2003-10-22 16:54:19 -0500 (Wed, 22 Oct 2003) | 2 lines

fixes for EPIA.

------------------------------------------------------------------------
r1180 | ebiederm | 2003-10-02 21:53:02 -0500 (Thu, 02 Oct 2003) | 2 lines

- Modify the code to C style indenting.

------------------------------------------------------------------------
r1179 | rminnich | 2003-10-02 18:33:01 -0500 (Thu, 02 Oct 2003) | 2 lines

Some timing in here, but we don't set; it breaks.

------------------------------------------------------------------------
r1177 | rminnich | 2003-10-02 17:48:28 -0500 (Thu, 02 Oct 2003) | 2 lines

First SPD code in and working!

------------------------------------------------------------------------
r1159 | rminnich | 2003-09-29 21:16:47 -0500 (Mon, 29 Sep 2003) | 4 lines

The epia now works.

Now to fix the ram ...

------------------------------------------------------------------------
r1157 | rminnich | 2003-09-26 23:28:39 -0500 (Fri, 26 Sep 2003) | 2 lines

ok that's it. I think this might work.

------------------------------------------------------------------------
r1156 | rminnich | 2003-09-26 23:18:31 -0500 (Fri, 26 Sep 2003) | 4 lines

a few tweaks etc.

Still probably wrong.

------------------------------------------------------------------------
r1155 | rminnich | 2003-09-26 18:22:31 -0500 (Fri, 26 Sep 2003) | 2 lines

it's getting through the 8601 but the values are still not right.

------------------------------------------------------------------------
r1154 | rminnich | 2003-09-26 17:45:54 -0500 (Fri, 26 Sep 2003) | 4 lines

something is wrong here but not sure what.

But nothing is getting set into the north bridge.

------------------------------------------------------------------------
r1151 | rminnich | 2003-09-26 12:16:14 -0500 (Fri, 26 Sep 2003) | 2 lines

just to get us back where we were.

------------------------------------------------------------------------
r1138 | rminnich | 2003-09-25 23:45:52 -0500 (Thu, 25 Sep 2003) | 2 lines

via epia; also yh lu tyan.

------------------------------------------------------------------------
r1131 | rminnich | 2003-09-25 12:01:28 -0500 (Thu, 25 Sep 2003) | 2 lines

first cut at 8601 support

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


From smithbone at gmail.com  Tue May  9 16:32:38 2006
From: smithbone at gmail.com (Richard Smith)
Date: Tue, 9 May 2006 09:32:38 -0500
Subject: [LinuxBIOS] MB1030 / 3036 VGA resume
In-Reply-To: <44609D2F.3040305@suehsi.de>
References: <44579320.90206@suehsi.de> <44586CDF.2060809@suehsi.de>
	<4458D0C3.7020308@lanl.gov> <4459C0FE.6070104@suehsi.de>
	<445F7F6B.9060309@suehsi.de> <20060508190903.27473.qmail@cdy.org>
	<445F9A23.3070602@suehsi.de> <445F9EFB.5010303@suehsi.de>
	<445FA66F.3000309@suehsi.de> <44609D2F.3040305@suehsi.de>
Message-ID: <8a0c36780605090732k52415350w523df8dfbf95c547@mail.gmail.com>

> What about the Config.lb under the mainboard folder.
> Most Boards enables the apic cluster, the eaglelion/5bcm does not.

Do you have an apic?

> I think all devices should be init, which are set to on in the Config file.
>
> However, the CPU is not init by LB and therefor there is no L1 cache.
> Can somebody have a second look to the eaglelion Config.lb under the
> mainboard folder. The file could be wrong.

What boards are you comparing against?

I haven't had a chance to look at the registers you listed for the CPU
datasheet.  But my suggestion would be to just try them and see what
happens.

--
Richard A. Smith



From smithbone at gmail.com  Tue May  9 16:40:29 2006
From: smithbone at gmail.com (Richard Smith)
Date: Tue, 9 May 2006 09:40:29 -0500
Subject: [LinuxBIOS] svn logs
Message-ID: <8a0c36780605090740k70d16070vae52b7ae6db62273@mail.gmail.com>

Going back and looking at the logfiles it seems we havn't done a very
good job of detailing things when they get changed.

ie a log commit that just says:

'fixes'

Dosen't really tell you much.  Say when you are reviewing the logs a
year later to try and find possible areas that might have busted a
board.

I think a little more verbosity in the logs for future commits would
help a bit.  At least some more verbosity when you think you have
fixed up things to a point that they work.

--
Richard A. Smith



From chris at suehsi.de  Tue May  9 18:07:34 2006
From: chris at suehsi.de (=?ISO-8859-1?Q?Christian_S=FChs?=)
Date: Tue, 09 May 2006 16:07:34 -0000
Subject: [LinuxBIOS] MB1030 / 3036 VGA resume
In-Reply-To: <8a0c36780605090732k52415350w523df8dfbf95c547@mail.gmail.com>
References: <44579320.90206@suehsi.de>
	<44586CDF.2060809@suehsi.de>	<4458D0C3.7020308@lanl.gov>
	<4459C0FE.6070104@suehsi.de>	<445F7F6B.9060309@suehsi.de>
	<20060508190903.27473.qmail@cdy.org>	<445F9A23.3070602@suehsi.de>
	<445F9EFB.5010303@suehsi.de>	<445FA66F.3000309@suehsi.de>
	<44609D2F.3040305@suehsi.de>
	<8a0c36780605090732k52415350w523df8dfbf95c547@mail.gmail.com>
Message-ID: <4424C30E.8010901@suehsi.de>

Richard Smith schrieb:
>>What about the Config.lb under the mainboard folder.
>>Most Boards enables the apic cluster, the eaglelion/5bcm does not.
> 
> 
> Do you have an apic?

Well I don't think so ;)

I'm not really sure what this is, i.e in the epia-m Config.lb is it 
enabled too, has/is the epia-m an apic?

Means apic, some boards get together in a cluster ??

> 
> 
>>I think all devices should be init, which are set to on in the Config file.
>>
>>However, the CPU is not init by LB and therefor there is no L1 cache.
>>Can somebody have a second look to the eaglelion Config.lb under the
>>mainboard folder. The file could be wrong.
> 
> 
> What boards are you comparing against?

It seems that almost any board has enabled apic in the Config.lb

> 
> I haven't had a chance to look at the registers you listed for the CPU
> datasheet.  But my suggestion would be to just try them and see what
> happens.

Yeah, I have tried these and that, but nothing helps. Currently I think 
that the GX1 L1 cache is disabled. Because it seems that the CPU is not 
init by LinuxBios on startup.

Last, I don't know how I should set those special cpu registers.

chris
> 
> --
> Richard A. Smith
> 




From chris at suehsi.de  Tue May  9 19:09:20 2006
From: chris at suehsi.de (=?ISO-8859-1?Q?Christian_S=FChs?=)
Date: Tue, 09 May 2006 19:09:20 +0200
Subject: [LinuxBIOS] MB1030 / 3036 VGA resume
In-Reply-To: <4424C30E.8010901@suehsi.de>
References: <44579320.90206@suehsi.de>
	<44586CDF.2060809@suehsi.de>	<4458D0C3.7020308@lanl.gov>
	<4459C0FE.6070104@suehsi.de>	<445F7F6B.9060309@suehsi.de>
	<20060508190903.27473.qmail@cdy.org>	<445F9A23.3070602@suehsi.de>
	<445F9EFB.5010303@suehsi.de>	<445FA66F.3000309@suehsi.de>
	<44609D2F.3040305@suehsi.de>
	<8a0c36780605090732k52415350w523df8dfbf95c547@mail.gmail.com>
	<4424C30E.8010901@suehsi.de>
Message-ID: <4460CCC0.3000706@suehsi.de>


> 
> 
> Yeah, I have tried these and that, but nothing helps. Currently I think 
> that the GX1 L1 cache is disabled. Because it seems that the CPU is not 
> init by LinuxBios on startup.


Well, CPU is init in early state by the two *.inc files under model_gx1, 
but the L1 cache should be enabled later by the init prozedur, but this 
function is never called.

Question is, how can I set the L1 cache in early state, means set the 
necassary registers.
Or how can I solve the not called init section for the gx1.



chris



From ward at gnu.org  Tue May  9 21:03:09 2006
From: ward at gnu.org (Ward Vandewege)
Date: Tue, 9 May 2006 15:03:09 -0400
Subject: [LinuxBIOS] s2881 fan control
In-Reply-To: <20060506122521.GA9586@coresystems.de>
References: <6F7DA19D05F3CF40B890C7CA2DB13A4203094BD5@ssvlexmb2.amd.com>
	<20060505205717.GA20174@localdomain>
	<20060505211923.GA22205@localdomain>
	<20060506122521.GA9586@coresystems.de>
Message-ID: <20060509190309.GA8910@localdomain>

On Sat, May 06, 2006 at 02:25:21PM +0200, Stefan Reinauer wrote:
> * Ward Vandewege <ward at gnu.org> [060505 23:19]:
> > > I can shut the machine down, do a cold boot into LinuxBIOS, and it still
> > > works.
> > > 
> > > Until I unplug the power to the machine, that is.
> > >   
> > > After that, I can still read out everything (see attached
> > > set_fan_speed_bad.txt) correctly, but now also _set_ the fan speed.
> > 
> > I'm sorry this is confusing. After unplugging and replugging the power to the
> > machine, I need to boot the proprietary BIOS once to be able to set the fan
> > speed on any consecutive (cold) boot. 
> 
> Can you do an lspci -xxx on the machine while running LinuxBIOS after a
> cold boot
> 
> a) without factory bios running once before
> b) with factory bios running once before
> 
> and diff them to see if there's something we can easily do. (ie. in the 
> "ACPI bridge" device?)

OK; I've attached the two files. Only three bytes are different in the ACPI
bridge (in this comparison the first file is after proprietary boot, the
second without).

 0000:01:04.3 Bridge: Advanced Micro Devices [AMD] AMD-8111 ACPI (rev 05)
 00: 22 10 6b 74 00 00 80 02 05 00 80 06 00 40 00 00
 10: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
 20: 00 00 00 00 00 00 00 00 00 00 00 00 f1 10 81 28
 30: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
 40: 80 f1 00 07 00 00 00 00 20 14 50 00 00 00 00 00
 50: 00 80 00 00 0f 00 00 00 01 20 00 00 00 00 00 00
 60: 00 00 80 06 13 00 00 00 00 00 00 00 00 00 00 00
 70: 00 00 00 00 00 00 00 00 00 00 00 00 f1 10 81 28
 80: 00 00 00 00 01 00 00 00 00 00 00 00 00 00 00 00
 90: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
 a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
 b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
 c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
 d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
 e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
-f0: 19 5f 3b 00 00 00 00 00 00 00 00 00 00 00 00 00
+f0: c3 ad 1e 00 00 00 00 00 00 00 00 00 00 00 00 00

But there are actually quite a few other differences throughout the file,
which surprises me a litte. Lots of differences in the various northbridge
entries, and even the network cards and the sata controller. Is this normal?

Thanks,
Ward.

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



From smithbone at gmail.com  Tue May  9 21:04:21 2006
From: smithbone at gmail.com (Richard Smith)
Date: Tue, 9 May 2006 14:04:21 -0500
Subject: [LinuxBIOS] MB1030 / 3036 VGA resume
In-Reply-To: <4460CCC0.3000706@suehsi.de>
References: <44579320.90206@suehsi.de> <445F7F6B.9060309@suehsi.de>
	<20060508190903.27473.qmail@cdy.org> <445F9A23.3070602@suehsi.de>
	<445F9EFB.5010303@suehsi.de> <445FA66F.3000309@suehsi.de>
	<44609D2F.3040305@suehsi.de>
	<8a0c36780605090732k52415350w523df8dfbf95c547@mail.gmail.com>
	<4424C30E.8010901@suehsi.de> <4460CCC0.3000706@suehsi.de>
Message-ID: <8a0c36780605091204l1a72e4b8lc377169b0473a510@mail.gmail.com>

> Question is, how can I set the L1 cache in early state, means set the
> necassary registers.

I'm a bit bandwith restricted at the moment so I can't offer a whole
lot of help..

There should be some examples of setting CPU registers in the CPU init code.

> Or how can I solve the not called init section for the gx1.

Which init function is not being called and what C file is it in?

--
Richard A. Smith



From ward at gnu.org  Tue May  9 21:05:07 2006
From: ward at gnu.org (Ward Vandewege)
Date: Tue, 9 May 2006 15:05:07 -0400
Subject: [LinuxBIOS] s2881 fan control
In-Reply-To: <20060506122521.GA9586@coresystems.de>
References: <6F7DA19D05F3CF40B890C7CA2DB13A4203094BD5@ssvlexmb2.amd.com>
	<20060505205717.GA20174@localdomain>
	<20060505211923.GA22205@localdomain>
	<20060506122521.GA9586@coresystems.de>
Message-ID: <20060509190507.GB8910@localdomain>

(and now _with_ attachments... sigh)

On Sat, May 06, 2006 at 02:25:21PM +0200, Stefan Reinauer wrote:
> * Ward Vandewege <ward at gnu.org> [060505 23:19]:
> > > I can shut the machine down, do a cold boot into LinuxBIOS, and it still
> > > works.
> > > 
> > > Until I unplug the power to the machine, that is.
> > >   
> > > After that, I can still read out everything (see attached
> > > set_fan_speed_bad.txt) correctly, but now also _set_ the fan speed.
> > 
> > I'm sorry this is confusing. After unplugging and replugging the power to the
> > machine, I need to boot the proprietary BIOS once to be able to set the fan
> > speed on any consecutive (cold) boot. 
> 
> Can you do an lspci -xxx on the machine while running LinuxBIOS after a
> cold boot
> 
> a) without factory bios running once before
> b) with factory bios running once before
> 
> and diff them to see if there's something we can easily do. (ie. in the 
> "ACPI bridge" device?)

OK; I've attached the two files. Only three bytes are different in the ACPI
bridge (in this comparison the first file is after proprietary boot, the
second without). Both times the system was running LinuxBIOS.

 0000:01:04.3 Bridge: Advanced Micro Devices [AMD] AMD-8111 ACPI (rev 05)
 00: 22 10 6b 74 00 00 80 02 05 00 80 06 00 40 00 00
 10: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
 20: 00 00 00 00 00 00 00 00 00 00 00 00 f1 10 81 28
 30: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
 40: 80 f1 00 07 00 00 00 00 20 14 50 00 00 00 00 00
 50: 00 80 00 00 0f 00 00 00 01 20 00 00 00 00 00 00
 60: 00 00 80 06 13 00 00 00 00 00 00 00 00 00 00 00
 70: 00 00 00 00 00 00 00 00 00 00 00 00 f1 10 81 28
 80: 00 00 00 00 01 00 00 00 00 00 00 00 00 00 00 00
 90: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
 a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
 b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
 c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
 d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
 e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
-f0: 19 5f 3b 00 00 00 00 00 00 00 00 00 00 00 00 00
+f0: c3 ad 1e 00 00 00 00 00 00 00 00 00 00 00 00 00

But there are actually quite a few other differences throughout the file,
which surprises me a litte. Lots of differences in the various northbridge
entries, and even the network cards and the sata controller. Is this normal?

Thanks,
Ward.

-- 
Ward Vandewege <ward at fsf.org>
Free Software Foundation - Senior System Administrator
-------------- next part --------------
0000:00:18.0 Host bridge: Advanced Micro Devices [AMD] K8 NorthBridge
00: 22 10 00 11 00 00 10 00 00 00 00 06 00 00 80 00
10: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
20: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
30: 00 00 00 00 80 00 00 00 00 00 00 00 00 00 00 00
40: 01 01 03 00 02 02 01 00 01 01 01 00 01 01 01 00
50: 01 01 01 00 01 01 01 00 01 01 01 00 01 01 01 00
60: 10 00 03 00 e4 02 00 00 20 c0 00 0f 70 00 00 00
70: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
80: 08 a0 01 21 20 00 11 11 22 05 75 80 02 00 00 00
90: 13 56 13 04 00 00 00 00 03 00 00 00 00 00 00 00
a0: 08 c0 01 21 d0 00 11 77 22 00 75 80 02 00 00 00
b0: f6 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
c0: 08 00 01 21 20 00 11 11 22 04 75 80 02 00 00 00
d0: 56 04 51 02 00 01 04 00 07 00 00 00 00 00 00 00
e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

0000:00:18.1 Host bridge: Advanced Micro Devices [AMD] K8 NorthBridge
00: 22 10 01 11 00 00 00 00 00 00 00 06 00 00 80 00
10: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
20: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
30: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
40: 03 00 00 00 00 00 3f 00 03 00 40 00 01 00 7f 00
50: 00 00 00 00 02 00 00 00 00 00 00 00 03 00 00 00
60: 00 00 00 00 04 00 00 00 00 00 00 00 05 00 00 00
70: 00 00 00 00 06 00 00 00 00 00 00 00 07 00 00 00
80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
90: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
b0: 03 00 fc 00 20 2f fd 00 03 30 fd 00 20 2f fd 00
c0: 03 10 00 00 20 20 00 00 00 00 00 00 00 00 00 00
d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
e0: 03 02 01 04 00 00 00 00 00 00 00 00 00 00 00 00
f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

0000:00:18.2 Host bridge: Advanced Micro Devices [AMD] K8 NorthBridge
00: 22 10 02 11 00 00 00 00 00 00 00 06 00 00 80 00
10: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
20: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
30: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
40: 01 00 00 00 01 10 00 00 00 00 00 00 00 00 00 00
50: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
60: 00 ee e0 03 00 ee e0 03 00 00 00 00 00 00 00 00
70: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
80: 07 00 00 00 00 00 00 00 42 35 82 13 20 0b 10 00
90: 00 8c 0a 08 08 0a 7b 06 00 00 00 00 00 00 00 00
a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
b0: 45 04 c9 0e 37 00 00 00 ff ff 80 08 4e 42 3d 02
c0: 00 00 02 00 00 00 00 00 00 00 00 00 00 00 00 00
d0: 43 49 00 0a 02 22 20 18 42 d0 09 13 40 30 00 93
e0: 0b 28 42 95 00 43 40 2e 48 e8 c9 03 38 38 80 71
f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

0000:00:18.3 Host bridge: Advanced Micro Devices [AMD] K8 NorthBridge
00: 22 10 03 11 00 00 00 00 00 00 00 06 00 00 80 00
10: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
20: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
30: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
40: ff 3b 00 00 40 00 40 0a 00 00 00 00 00 00 00 00
50: 28 01 88 60 1a 00 00 00 16 16 16 00 c0 5c 01 00
60: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
70: 11 01 02 51 11 80 00 50 00 38 00 08 1a 22 00 00
80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
90: 02 00 00 00 7c 00 00 00 00 00 00 00 00 00 00 00
a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
b0: 00 00 00 00 00 00 00 00 3f 00 00 00 00 00 00 00
c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
d0: 00 00 00 00 00 a0 00 00 00 00 00 00 25 00 25 00
e0: 00 00 00 00 20 02 59 09 1b 11 00 00 00 00 00 00
f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

0000:00:19.0 Host bridge: Advanced Micro Devices [AMD] K8 NorthBridge
00: 22 10 00 11 00 00 10 00 00 00 00 06 00 00 80 00
10: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
20: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
30: 00 00 00 00 80 00 00 00 00 00 00 00 00 00 00 00
40: 02 02 01 00 01 01 03 00 01 01 01 00 01 01 01 00
50: 01 01 01 00 01 01 01 00 01 01 01 00 01 01 01 00
60: 11 00 03 00 e4 00 00 00 20 c0 00 0f 7c 00 00 00
70: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
80: 08 a0 01 21 20 00 11 11 22 05 75 80 02 00 00 00
90: 13 56 13 04 00 00 00 00 03 00 00 00 00 00 00 00
a0: 08 c0 01 21 d0 00 11 77 22 00 75 80 02 00 00 00
b0: 00 20 00 06 00 00 00 00 00 00 00 00 00 00 00 00
c0: 08 00 01 21 d0 00 11 77 22 00 75 80 02 00 00 00
d0: 80 48 00 04 00 00 00 00 00 00 00 00 00 00 00 00
e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

0000:00:19.1 Host bridge: Advanced Micro Devices [AMD] K8 NorthBridge
00: 22 10 01 11 00 00 00 00 00 00 00 06 00 00 80 00
10: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
20: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
30: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
40: 03 00 00 00 00 00 3f 00 03 00 40 00 01 00 7f 00
50: 00 00 00 00 02 00 00 00 00 00 00 00 03 00 00 00
60: 00 00 00 00 04 00 00 00 00 00 00 00 05 00 00 00
70: 00 00 00 00 06 00 00 00 00 00 00 00 07 00 00 00
80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
90: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
b0: 03 00 fc 00 20 2f fd 00 03 30 fd 00 20 2f fd 00
c0: 03 10 00 00 20 20 00 00 00 00 00 00 00 00 00 00
d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
e0: 03 02 01 04 00 00 00 00 00 00 00 00 00 00 00 00
f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

0000:00:19.2 Host bridge: Advanced Micro Devices [AMD] K8 NorthBridge
00: 22 10 02 11 00 00 00 00 00 00 00 06 00 00 80 00
10: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
20: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
30: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
40: 01 00 00 00 01 10 00 00 00 00 00 00 00 00 00 00
50: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
60: 00 ee e0 03 00 ee e0 03 00 00 00 00 00 00 00 00
70: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
80: 07 00 00 00 00 00 00 00 42 35 82 13 20 0b 10 00
90: 00 8c 0a 08 08 0a 7b 06 00 00 00 00 00 00 00 00
a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
b0: e9 bd cb 0e 37 00 00 00 7d 7e 00 00 8e 44 ca 14
c0: 00 00 01 00 00 00 00 00 00 00 00 00 00 00 00 00
d0: 31 04 92 82 90 3a 80 b0 1e 80 22 a2 2c 82 01 00
e0: b5 20 82 87 e0 62 40 0e 00 42 43 e5 10 00 21 c0
f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

0000:00:19.3 Host bridge: Advanced Micro Devices [AMD] K8 NorthBridge
00: 22 10 03 11 00 00 00 00 00 00 00 06 00 00 80 00
10: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
20: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
30: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
40: ff 3b 00 00 40 00 40 0a 00 00 00 00 00 00 00 00
50: 00 00 00 00 00 00 00 00 16 16 16 00 00 5b 01 40
60: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
70: 11 01 02 51 11 80 00 50 00 38 00 08 1a 22 00 00
80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
90: 02 00 00 00 7c 00 00 00 00 00 00 00 00 00 00 00
a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
b0: 00 00 00 00 00 00 00 00 3e 00 00 00 00 00 00 00
c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
d0: 00 00 00 00 00 a0 00 00 00 00 00 00 25 00 00 00
e0: 00 00 00 00 20 01 51 09 1b 11 00 00 00 00 00 00
f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

0000:01:01.0 PCI bridge: Advanced Micro Devices [AMD] AMD-8131 PCI-X Bridge (rev 12)
00: 22 10 50 74 56 01 30 02 12 00 04 06 00 40 81 00
10: 00 00 00 00 00 00 00 00 01 02 02 40 f1 01 20 22
20: 10 fd 10 fd f1 ff 01 00 00 00 00 00 00 00 00 00
30: 00 00 00 00 a0 00 00 00 00 00 00 00 ff 00 03 00
40: 05 00 1f 00 00 00 00 00 02 0c 00 00 01 2c 00 00
50: 00 00 03 00 00 00 04 00 00 00 00 00 00 00 00 00
60: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
70: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
90: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
a0: 07 b8 83 00 08 01 03 00 0e 00 0e 00 02 00 02 00
b0: 00 00 00 00 00 00 00 00 08 c0 00 80 00 00 00 05
c0: 08 00 41 00 22 00 11 11 22 00 00 00 22 04 35 00
d0: 02 00 35 00 00 00 00 00 00 00 00 00 00 00 00 00
e0: 04 04 0c 00 04 04 0c 00 04 04 14 00 00 00 00 00
f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

0000:01:01.1 PIC: Advanced Micro Devices [AMD] AMD-8131 PCI-X APIC (rev 01)
00: 22 10 51 74 06 00 00 02 01 10 00 08 00 00 00 00
10: 04 00 20 fd 00 00 00 00 00 00 00 00 00 00 00 00
20: 00 00 00 00 00 00 00 00 00 00 00 00 f1 10 81 28
30: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
40: 00 00 00 00 03 00 00 00 04 00 20 fd 00 00 00 00
50: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
60: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
70: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
90: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

0000:01:02.0 PCI bridge: Advanced Micro Devices [AMD] AMD-8131 PCI-X Bridge (rev 12)
00: 22 10 50 74 04 00 30 02 12 00 04 06 00 40 81 00
10: 00 00 00 00 00 00 00 00 01 03 03 40 f1 01 20 22
20: f0 ff 00 00 f1 ff 01 00 00 00 00 00 00 00 00 00
30: 00 00 00 00 a0 00 00 00 00 00 00 00 ff 00 00 00
40: 05 00 00 00 00 00 00 00 00 00 00 00 00 2c 00 00
50: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
60: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
70: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
90: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
a0: 07 b8 c3 00 10 01 03 00 0e 00 ff ff 02 00 ff ff
b0: 00 00 00 00 00 00 00 00 08 00 00 80 00 00 00 06
c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

0000:01:02.1 PIC: Advanced Micro Devices [AMD] AMD-8131 PCI-X APIC (rev 01)
00: 22 10 51 74 06 00 00 02 01 10 00 08 00 00 00 00
10: 04 10 20 fd 00 00 00 00 00 00 00 00 00 00 00 00
20: 00 00 00 00 00 00 00 00 00 00 00 00 f1 10 81 28
30: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
40: 00 00 00 00 03 00 00 00 04 10 20 fd 00 00 00 00
50: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
60: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
70: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
90: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

0000:01:03.0 PCI bridge: Advanced Micro Devices [AMD] AMD-8111 PCI (rev 07)
00: 22 10 60 74 47 01 30 02 07 00 04 06 00 40 01 00
10: 00 00 00 00 00 00 00 00 01 04 04 40 10 10 00 02
20: 00 fc 00 fd 00 88 00 88 00 00 00 00 00 00 00 00
30: 00 00 00 00 c0 00 00 00 00 00 00 00 ff 00 23 04
40: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
50: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
60: 00 00 04 06 00 00 00 00 00 00 00 00 00 00 00 00
70: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
90: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
c0: 08 f0 83 00 22 00 00 00 d0 00 00 00 22 00 01 00
d0: 02 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
e0: 08 00 0d 00 08 00 0e 00 0f 00 0c 00 00 00 00 00
f0: 08 00 00 80 00 00 00 00 00 00 00 00 00 00 00 00

0000:01:04.0 ISA bridge: Advanced Micro Devices [AMD] AMD-8111 LPC (rev 05)
00: 22 10 68 74 0f 00 20 02 05 00 01 06 00 00 80 00
10: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
20: 00 00 00 00 00 00 00 00 00 00 00 00 f1 10 81 28
30: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
40: 00 30 07 c0 01 00 00 82 9f fd 00 01 00 00 00 c0
50: 00 00 00 00 85 01 00 00 4d 00 00 00 00 00 00 00
60: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
70: f1 10 81 28 00 de 00 00 00 00 00 00 00 00 00 00
80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
90: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
a0: 01 00 d0 fe 00 00 00 00 00 00 00 00 00 00 00 00
b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

0000:01:04.1 IDE interface: Advanced Micro Devices [AMD] AMD-8111 IDE (rev 03)
00: 22 10 69 74 05 00 00 02 03 8a 01 01 00 20 00 00
10: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
20: 21 24 00 00 00 00 00 00 00 00 00 00 f1 10 81 28
30: 00 00 00 00 00 00 00 00 00 00 00 00 ff 00 00 00
40: 03 f0 0f 00 00 00 00 00 20 a8 a8 a8 fc 00 20 ff
50: 03 03 03 03 00 00 00 00 00 00 00 00 00 00 00 00
60: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
70: f1 10 81 28 00 00 00 00 00 00 00 00 00 00 00 00
80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
90: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

0000:01:04.2 SMBus: Advanced Micro Devices [AMD] AMD-8111 SMBus 2.0 (rev 02)
00: 22 10 6a 74 01 00 00 02 02 00 05 0c 00 40 00 00
10: 01 24 00 00 00 00 00 00 00 00 00 00 00 00 00 00
20: 00 00 00 00 00 00 00 00 00 00 00 00 f1 10 81 28
30: 00 00 00 00 00 00 00 00 00 00 00 00 00 04 00 00
40: 02 00 05 0c f1 10 81 28 00 00 00 00 00 00 00 00
50: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
60: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
70: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
90: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

0000:01:04.3 Bridge: Advanced Micro Devices [AMD] AMD-8111 ACPI (rev 05)
00: 22 10 6b 74 00 00 80 02 05 00 80 06 00 40 00 00
10: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
20: 00 00 00 00 00 00 00 00 00 00 00 00 f1 10 81 28
30: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
40: 80 f1 00 07 00 00 00 00 20 14 50 00 00 00 00 00
50: 00 80 00 00 0f 00 00 00 01 20 00 00 00 00 00 00
60: 00 00 80 06 13 00 00 00 00 00 00 00 00 00 00 00
70: 00 00 00 00 00 00 00 00 00 00 00 00 f1 10 81 28
80: 00 00 00 00 01 00 00 00 00 00 00 00 00 00 00 00
90: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
f0: 19 5f 3b 00 00 00 00 00 00 00 00 00 00 00 00 00

0000:02:09.0 Ethernet controller: Broadcom Corporation NetXtreme BCM5704 Gigabit Ethernet (rev 03)
00: e4 14 48 16 46 01 b0 02 03 00 00 02 10 40 80 00
10: 04 00 10 fd 00 00 00 00 04 00 11 fd 00 00 00 00
20: 00 00 00 00 00 00 00 00 00 00 00 00 e4 14 44 16
30: 00 00 00 00 40 00 00 00 00 00 00 00 00 01 40 00
40: 07 48 08 00 48 02 43 04 01 50 02 c0 00 21 00 64
50: 03 58 00 00 c0 30 f9 41 05 00 86 00 60 02 98 02
60: 64 d4 08 63 61 00 00 00 98 02 03 20 00 40 9f 76
70: e2 30 00 00 c6 00 00 80 50 00 00 00 00 00 00 00
80: 03 58 00 00 9d b2 86 bc 34 00 13 04 82 90 28 02
90: 09 df 00 01 00 00 00 6a 00 00 00 00 b2 01 00 00
a0: 00 00 00 00 ea 00 00 00 00 00 00 00 99 00 00 00
b0: 00 00 00 00 00 00 00 63 00 00 00 00 00 00 00 00
c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

0000:02:09.1 Ethernet controller: Broadcom Corporation NetXtreme BCM5704 Gigabit Ethernet (rev 03)
00: e4 14 48 16 46 01 b0 02 03 00 00 02 10 40 80 00
10: 04 00 12 fd 00 00 00 00 04 00 13 fd 00 00 00 00
20: 00 00 00 00 00 00 00 00 00 00 00 00 e4 14 44 16
30: 00 00 00 00 40 00 00 00 00 00 00 00 00 02 40 00
40: 07 48 02 00 49 02 43 04 01 50 02 c0 00 20 00 64
50: 03 58 08 00 00 42 01 40 05 00 86 00 20 c1 00 48
60: 93 02 02 00 80 00 00 00 9a 02 03 20 00 40 9f 76
70: 82 32 00 00 c6 00 00 00 50 00 00 00 00 00 00 00
80: 03 58 08 00 f5 7e 80 9a 34 00 00 00 fe 90 60 02
90: 01 07 00 01 00 00 00 00 00 00 00 00 00 00 00 00
a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
b0: 00 00 00 00 00 00 00 00 04 00 00 00 00 00 00 00
c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

0000:04:00.0 USB Controller: Advanced Micro Devices [AMD] AMD-8111 USB (rev 0b)
00: 22 10 64 74 06 01 80 02 0b 10 03 0c 00 40 80 00
10: 00 00 00 fd 00 00 00 00 00 00 00 00 00 00 00 00
20: 00 00 00 00 00 00 00 00 00 00 00 00 f1 10 81 28
30: 00 00 00 00 00 00 00 00 00 00 00 00 00 04 00 50
40: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
50: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
60: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
70: f1 10 81 28 00 00 00 00 00 00 00 00 00 00 00 00
80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
90: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

0000:04:00.1 USB Controller: Advanced Micro Devices [AMD] AMD-8111 USB (rev 0b)
00: 22 10 64 74 06 01 80 02 0b 10 03 0c 00 40 00 00
10: 00 10 00 fd 00 00 00 00 00 00 00 00 00 00 00 00
20: 00 00 00 00 00 00 00 00 00 00 00 00 f1 10 81 28
30: 00 00 00 00 00 00 00 00 00 00 00 00 00 04 00 50
40: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
50: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
60: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
70: f1 10 81 28 00 00 00 00 00 00 00 00 00 00 00 00
80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
90: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

0000:04:05.0 Unknown mass storage controller: Silicon Image, Inc. (formerly CMD Technology Inc) SiI 3114 [SATALink/SATARaid] Serial ATA Controller (rev 02)
00: 95 10 14 31 47 01 b0 02 02 00 80 01 10 40 00 00
10: 11 14 00 00 31 14 00 00 21 14 00 00 41 14 00 00
20: 01 14 00 00 00 30 00 fd 00 00 00 00 95 10 14 31
30: 00 00 00 00 60 00 00 00 00 00 00 00 00 01 00 00
40: 00 00 00 00 00 02 80 02 00 00 00 00 00 00 00 00
50: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
60: 01 00 22 06 00 40 00 64 00 00 00 00 00 00 00 00
70: 08 00 00 00 00 b0 ad 3f 00 00 00 00 00 20 fe 01
80: 03 00 00 00 03 00 00 00 00 00 00 00 e0 f7 97 3e
90: 00 00 00 08 00 00 00 00 00 00 00 18 00 00 00 00
a0: 01 01 15 65 dd 62 dd 62 92 43 92 43 09 40 09 40
b0: 01 01 15 65 dd 62 dd 62 92 43 92 43 09 40 09 40
c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

0000:04:06.0 VGA compatible controller: ATI Technologies Inc Rage XL (rev 27)
00: 02 10 52 47 83 00 90 02 27 00 00 03 10 40 00 00
10: 00 00 00 fc 01 10 00 00 00 20 00 fd 00 00 00 00
20: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
30: 00 00 f8 ff 5c 00 00 00 00 00 00 00 00 01 08 00
40: 0c 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
50: 02 5c 10 00 01 00 00 ff 00 00 00 00 01 00 02 06
60: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
70: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
90: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

-------------- next part --------------
0000:00:18.0 Host bridge: Advanced Micro Devices [AMD] K8 NorthBridge
00: 22 10 00 11 00 00 10 00 00 00 00 06 00 00 80 00
10: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
20: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
30: 00 00 00 00 80 00 00 00 00 00 00 00 00 00 00 00
40: 01 01 03 00 02 02 01 00 01 01 01 00 01 01 01 00
50: 01 01 01 00 01 01 01 00 01 01 01 00 01 01 01 00
60: 10 00 03 00 e4 02 00 00 20 c0 00 0f 70 00 00 00
70: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
80: 08 a0 01 21 20 00 11 11 22 05 75 80 02 00 00 00
90: 13 56 13 04 00 00 00 00 03 00 00 00 00 00 00 00
a0: 08 c0 01 21 d0 00 11 77 22 00 75 80 02 00 00 00
b0: f6 c0 40 03 00 00 00 00 00 00 00 00 00 00 00 00
c0: 08 00 01 21 20 00 11 11 22 04 75 80 02 00 00 00
d0: 56 04 51 02 00 01 04 00 07 00 00 00 00 00 00 00
e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

0000:00:18.1 Host bridge: Advanced Micro Devices [AMD] K8 NorthBridge
00: 22 10 01 11 00 00 00 00 00 00 00 06 00 00 80 00
10: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
20: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
30: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
40: 03 00 00 00 00 00 3f 00 03 00 40 00 01 00 7f 00
50: 00 00 00 00 02 00 00 00 00 00 00 00 03 00 00 00
60: 00 00 00 00 04 00 00 00 00 00 00 00 05 00 00 00
70: 00 00 00 00 06 00 00 00 00 00 00 00 07 00 00 00
80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
90: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
b0: 03 00 fc 00 20 2f fd 00 03 30 fd 00 20 2f fd 00
c0: 03 10 00 00 20 20 00 00 00 00 00 00 00 00 00 00
d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
e0: 03 02 01 04 00 00 00 00 00 00 00 00 00 00 00 00
f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

0000:00:18.2 Host bridge: Advanced Micro Devices [AMD] K8 NorthBridge
00: 22 10 02 11 00 00 00 00 00 00 00 06 00 00 80 00
10: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
20: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
30: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
40: 01 00 00 00 01 10 00 00 00 00 00 00 00 00 00 00
50: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
60: 00 ee e0 03 00 ee e0 03 00 00 00 00 00 00 00 00
70: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
80: 07 00 00 00 00 00 00 00 42 35 82 13 20 0b 10 00
90: 00 8c 0a 08 08 0a 7b 06 00 00 00 00 00 00 00 00
a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
b0: aa be 1d 77 1c 00 00 00 ff 3f 82 08 4c c6 35 20
c0: 00 00 02 00 00 00 00 00 00 00 00 00 00 00 00 00
d0: 43 69 a0 0b 42 22 a0 0c c2 71 0d 13 d2 30 78 d3
e0: a9 29 e2 bd aa e3 40 36 c9 38 c1 03 38 38 e8 f1
f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

0000:00:18.3 Host bridge: Advanced Micro Devices [AMD] K8 NorthBridge
00: 22 10 03 11 00 00 00 00 00 00 00 06 00 00 80 00
10: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
20: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
30: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
40: ff 3b 00 00 40 00 40 0a 00 00 00 00 00 00 00 00
50: 08 05 d0 69 1a 00 00 00 16 16 16 00 c0 b2 00 00
60: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
70: 11 01 02 51 11 80 00 50 00 38 00 08 1a 22 00 00
80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
90: 02 00 00 00 7c 00 00 00 00 00 00 00 00 00 00 00
a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
b0: 00 00 00 00 00 00 00 00 3f 00 00 20 00 00 00 00
c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
d0: 00 00 00 00 00 a0 00 00 00 00 00 00 25 00 25 00
e0: 00 00 00 00 20 02 54 09 1b 11 00 00 00 00 00 00
f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

0000:00:19.0 Host bridge: Advanced Micro Devices [AMD] K8 NorthBridge
00: 22 10 00 11 00 00 10 00 00 00 00 06 00 00 80 00
10: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
20: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
30: 00 00 00 00 80 00 00 00 00 00 00 00 00 00 00 00
40: 02 02 01 00 01 01 03 00 01 01 01 00 01 01 01 00
50: 01 01 01 00 01 01 01 00 01 01 01 00 01 01 01 00
60: 11 00 03 00 e4 00 00 00 20 c0 00 0f 7c 00 00 00
70: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
80: 08 a0 01 21 20 00 11 11 22 05 75 80 02 00 00 00
90: 13 56 13 04 00 00 00 00 03 00 00 00 00 00 00 00
a0: 08 c0 01 21 d0 00 11 77 22 00 75 80 02 00 00 00
b0: 00 00 00 06 00 00 00 00 00 00 00 00 00 00 00 00
c0: 08 00 01 21 d0 00 11 77 22 00 75 80 02 00 00 00
d0: 80 08 00 00 00 00 00 00 00 00 00 00 00 00 00 00
e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

0000:00:19.1 Host bridge: Advanced Micro Devices [AMD] K8 NorthBridge
00: 22 10 01 11 00 00 00 00 00 00 00 06 00 00 80 00
10: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
20: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
30: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
40: 03 00 00 00 00 00 3f 00 03 00 40 00 01 00 7f 00
50: 00 00 00 00 02 00 00 00 00 00 00 00 03 00 00 00
60: 00 00 00 00 04 00 00 00 00 00 00 00 05 00 00 00
70: 00 00 00 00 06 00 00 00 00 00 00 00 07 00 00 00
80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
90: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
b0: 03 00 fc 00 20 2f fd 00 03 30 fd 00 20 2f fd 00
c0: 03 10 00 00 20 20 00 00 00 00 00 00 00 00 00 00
d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
e0: 03 02 01 04 00 00 00 00 00 00 00 00 00 00 00 00
f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

0000:00:19.2 Host bridge: Advanced Micro Devices [AMD] K8 NorthBridge
00: 22 10 02 11 00 00 00 00 00 00 00 06 00 00 80 00
10: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
20: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
30: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
40: 01 00 00 00 01 10 00 00 00 00 00 00 00 00 00 00
50: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
60: 00 ee e0 03 00 ee e0 03 00 00 00 00 00 00 00 00
70: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
80: 07 00 00 00 00 00 00 00 42 35 82 13 20 0b 10 00
90: 00 8c 0a 08 08 0a 7b 06 00 00 00 00 00 00 00 00
a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
b0: 78 8a 20 77 1c 00 00 00 fd 7e 00 00 a6 44 86 14
c0: 00 00 01 00 00 00 00 00 00 00 00 00 00 00 00 00
d0: 3e 04 92 82 98 3a 80 b0 1e c0 00 a2 2c 82 06 01
e0: b5 20 c2 9f e0 62 49 0e 04 42 c3 45 00 00 21 c0
f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

0000:00:19.3 Host bridge: Advanced Micro Devices [AMD] K8 NorthBridge
00: 22 10 03 11 00 00 00 00 00 00 00 06 00 00 80 00
10: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
20: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
30: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
40: ff 3b 00 00 40 00 40 0a 00 00 00 00 00 00 00 00
50: 00 04 02 00 00 00 00 00 16 16 16 00 00 b1 00 40
60: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
70: 11 01 02 51 11 80 00 50 00 38 00 08 1a 22 00 00
80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
90: 02 00 00 00 7c 00 00 00 00 00 00 00 00 00 00 00
a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
b0: 00 00 00 00 00 00 00 00 3f 00 00 00 00 00 00 00
c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
d0: 00 00 00 00 00 a0 00 00 00 00 00 00 25 00 00 00
e0: 00 00 00 00 20 01 4e 09 1b 11 00 00 00 00 00 00
f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

0000:01:01.0 PCI bridge: Advanced Micro Devices [AMD] AMD-8131 PCI-X Bridge (rev 12)
00: 22 10 50 74 56 01 30 02 12 00 04 06 00 40 81 00
10: 00 00 00 00 00 00 00 00 01 02 02 40 f1 01 20 22
20: 10 fd 10 fd f1 ff 01 00 00 00 00 00 00 00 00 00
30: 00 00 00 00 a0 00 00 00 00 00 00 00 ff 00 03 00
40: 05 00 1f 00 00 00 00 00 02 0c 00 00 01 2c 00 00
50: 00 00 03 00 00 00 04 00 00 00 00 00 00 00 00 00
60: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
70: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
90: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
a0: 07 b8 83 00 08 01 03 00 0e 00 0e 00 02 00 02 00
b0: 00 00 00 00 00 00 00 00 08 c0 00 80 00 00 00 05
c0: 08 00 41 00 22 00 11 11 22 00 00 00 22 04 35 00
d0: 02 00 35 00 00 00 00 00 00 00 00 00 00 00 00 00
e0: 04 04 0c 00 04 04 0c 00 04 04 14 00 00 00 00 00
f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

0000:01:01.1 PIC: Advanced Micro Devices [AMD] AMD-8131 PCI-X APIC (rev 01)
00: 22 10 51 74 06 00 00 02 01 10 00 08 00 00 00 00
10: 04 00 20 fd 00 00 00 00 00 00 00 00 00 00 00 00
20: 00 00 00 00 00 00 00 00 00 00 00 00 f1 10 81 28
30: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
40: 00 00 00 00 03 00 00 00 04 00 20 fd 00 00 00 00
50: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
60: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
70: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
90: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

0000:01:02.0 PCI bridge: Advanced Micro Devices [AMD] AMD-8131 PCI-X Bridge (rev 12)
00: 22 10 50 74 04 00 30 02 12 00 04 06 00 40 81 00
10: 00 00 00 00 00 00 00 00 01 03 03 40 f1 01 20 22
20: f0 ff 00 00 f1 ff 01 00 00 00 00 00 00 00 00 00
30: 00 00 00 00 a0 00 00 00 00 00 00 00 ff 00 00 00
40: 05 00 00 00 00 00 00 00 00 00 00 00 00 2c 00 00
50: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
60: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
70: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
90: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
a0: 07 b8 c3 00 10 01 03 00 0e 00 ff ff 02 00 ff ff
b0: 00 00 00 00 00 00 00 00 08 00 00 80 00 00 00 06
c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

0000:01:02.1 PIC: Advanced Micro Devices [AMD] AMD-8131 PCI-X APIC (rev 01)
00: 22 10 51 74 06 00 00 02 01 10 00 08 00 00 00 00
10: 04 10 20 fd 00 00 00 00 00 00 00 00 00 00 00 00
20: 00 00 00 00 00 00 00 00 00 00 00 00 f1 10 81 28
30: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
40: 00 00 00 00 03 00 00 00 04 10 20 fd 00 00 00 00
50: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
60: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
70: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
90: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

0000:01:03.0 PCI bridge: Advanced Micro Devices [AMD] AMD-8111 PCI (rev 07)
00: 22 10 60 74 47 01 30 02 07 00 04 06 00 40 01 00
10: 00 00 00 00 00 00 00 00 01 04 04 40 10 10 00 02
20: 00 fc 00 fd 00 88 00 88 00 00 00 00 00 00 00 00
30: 00 00 00 00 c0 00 00 00 00 00 00 00 ff 00 23 04
40: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
50: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
60: 00 00 04 06 00 00 00 00 00 00 00 00 00 00 00 00
70: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
90: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
c0: 08 f0 83 00 22 00 00 00 d0 00 00 00 22 00 01 00
d0: 02 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
e0: 08 00 0d 00 08 00 0e 00 0f 00 0c 00 00 00 00 00
f0: 08 00 00 80 00 00 00 00 00 00 00 00 00 00 00 00

0000:01:04.0 ISA bridge: Advanced Micro Devices [AMD] AMD-8111 LPC (rev 05)
00: 22 10 68 74 0f 00 20 02 05 00 01 06 00 00 80 00
10: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
20: 00 00 00 00 00 00 00 00 00 00 00 00 f1 10 81 28
30: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
40: 00 30 07 c0 01 00 00 82 9f fd 00 01 00 00 00 c0
50: 00 00 00 00 85 01 00 00 48 00 00 00 00 00 00 00
60: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
70: f1 10 81 28 00 de 00 00 00 00 00 00 00 00 00 00
80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
90: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
a0: 01 00 d0 fe 00 00 00 00 00 00 00 00 00 00 00 00
b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

0000:01:04.1 IDE interface: Advanced Micro Devices [AMD] AMD-8111 IDE (rev 03)
00: 22 10 69 74 05 00 00 02 03 8a 01 01 00 20 00 00
10: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
20: 21 24 00 00 00 00 00 00 00 00 00 00 f1 10 81 28
30: 00 00 00 00 00 00 00 00 00 00 00 00 ff 00 00 00
40: 03 f0 0f 00 00 00 00 00 20 a8 a8 a8 fc 00 20 ff
50: 03 03 03 03 00 00 00 00 00 00 00 00 00 00 00 00
60: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
70: f1 10 81 28 00 00 00 00 00 00 00 00 00 00 00 00
80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
90: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

0000:01:04.2 SMBus: Advanced Micro Devices [AMD] AMD-8111 SMBus 2.0 (rev 02)
00: 22 10 6a 74 01 00 00 02 02 00 05 0c 00 40 00 00
10: 01 24 00 00 00 00 00 00 00 00 00 00 00 00 00 00
20: 00 00 00 00 00 00 00 00 00 00 00 00 f1 10 81 28
30: 00 00 00 00 00 00 00 00 00 00 00 00 00 04 00 00
40: 02 00 05 0c f1 10 81 28 00 00 00 00 00 00 00 00
50: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
60: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
70: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
90: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

0000:01:04.3 Bridge: Advanced Micro Devices [AMD] AMD-8111 ACPI (rev 05)
00: 22 10 6b 74 00 00 80 02 05 00 80 06 00 40 00 00
10: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
20: 00 00 00 00 00 00 00 00 00 00 00 00 f1 10 81 28
30: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
40: 80 f1 00 04 00 00 00 00 20 14 50 00 00 00 00 00
50: 00 80 00 00 0f 00 00 00 01 20 00 00 00 00 00 00
60: 00 00 80 06 13 00 00 00 00 00 00 00 00 00 00 00
70: 00 00 00 00 00 00 00 00 00 00 00 00 f1 10 81 28
80: 00 00 00 00 01 00 00 00 00 00 00 00 00 00 00 00
90: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
f0: c3 ad 1e 00 00 00 00 00 00 00 00 00 00 00 00 00

0000:02:09.0 Ethernet controller: Broadcom Corporation NetXtreme BCM5704 Gigabit Ethernet (rev 03)
00: e4 14 48 16 46 01 b0 02 03 00 00 02 10 40 80 00
10: 04 00 10 fd 00 00 00 00 04 00 11 fd 00 00 00 00
20: 00 00 00 00 00 00 00 00 00 00 00 00 e4 14 44 16
30: 00 00 00 00 40 00 00 00 00 00 00 00 00 01 40 00
40: 07 48 08 00 48 02 43 04 01 50 02 c0 00 21 00 64
50: 03 58 00 00 c0 20 f9 41 05 00 86 00 60 02 98 00
60: 64 d4 48 43 71 00 00 00 98 02 03 20 00 40 9f 76
70: e2 30 00 00 c6 00 00 80 50 00 00 00 00 00 00 00
80: 03 58 00 00 9d b2 86 38 34 00 13 04 82 90 28 02
90: 09 df 00 01 00 00 00 00 00 00 00 00 3b 01 00 00
a0: 00 00 00 00 73 00 00 00 00 00 00 00 4f 00 00 00
b0: 00 00 00 00 00 00 00 c3 00 00 00 00 00 00 00 00
c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

0000:02:09.1 Ethernet controller: Broadcom Corporation NetXtreme BCM5704 Gigabit Ethernet (rev 03)
00: e4 14 48 16 46 01 b0 02 03 00 00 02 10 40 80 00
10: 04 00 12 fd 00 00 00 00 04 00 13 fd 00 00 00 00
20: 00 00 00 00 00 00 00 00 00 00 00 00 e4 14 44 16
30: 00 00 00 00 40 00 00 00 00 00 00 00 00 02 40 00
40: 07 48 02 00 49 02 43 04 01 50 02 c0 00 20 00 64
50: 03 58 08 00 01 42 01 40 05 00 86 00 20 c1 10 48
60: 91 00 02 20 82 00 00 00 9a 02 03 20 00 40 9f 76
70: 82 32 00 00 c6 00 00 00 50 00 00 00 00 00 00 00
80: 03 58 08 00 f5 7e 80 9e 34 00 00 00 fe 90 60 02
90: 01 07 00 01 00 00 00 00 00 00 00 00 00 00 00 00
a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
b0: 00 00 00 00 00 00 00 00 04 00 00 00 00 00 00 00
c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

0000:04:00.0 USB Controller: Advanced Micro Devices [AMD] AMD-8111 USB (rev 0b)
00: 22 10 64 74 06 01 80 02 0b 10 03 0c 00 40 80 00
10: 00 00 00 fd 00 00 00 00 00 00 00 00 00 00 00 00
20: 00 00 00 00 00 00 00 00 00 00 00 00 f1 10 81 28
30: 00 00 00 00 00 00 00 00 00 00 00 00 00 04 00 50
40: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
50: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
60: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
70: f1 10 81 28 00 00 00 00 00 00 00 00 00 00 00 00
80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
90: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

0000:04:00.1 USB Controller: Advanced Micro Devices [AMD] AMD-8111 USB (rev 0b)
00: 22 10 64 74 06 01 80 02 0b 10 03 0c 00 40 00 00
10: 00 10 00 fd 00 00 00 00 00 00 00 00 00 00 00 00
20: 00 00 00 00 00 00 00 00 00 00 00 00 f1 10 81 28
30: 00 00 00 00 00 00 00 00 00 00 00 00 00 04 00 50
40: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
50: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
60: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
70: f1 10 81 28 00 00 00 00 00 00 00 00 00 00 00 00
80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
90: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

0000:04:05.0 Unknown mass storage controller: Silicon Image, Inc. (formerly CMD Technology Inc) SiI 3114 [SATALink/SATARaid] Serial ATA Controller (rev 02)
00: 95 10 14 31 47 01 b0 02 02 00 80 01 10 40 00 00
10: 11 14 00 00 31 14 00 00 21 14 00 00 41 14 00 00
20: 01 14 00 00 00 30 00 fd 00 00 00 00 95 10 14 31
30: 00 00 00 00 60 00 00 00 00 00 00 00 00 01 00 00
40: 00 00 00 00 00 02 80 00 00 00 00 00 00 00 00 00
50: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
60: 01 00 22 06 00 40 00 64 00 00 00 00 00 00 00 00
70: 08 00 00 00 00 60 ac 3f 08 00 00 00 00 f0 94 3f
80: 03 00 00 00 03 00 00 00 00 00 00 00 e0 f7 9f 7e
90: 00 00 00 08 00 00 00 00 00 00 00 18 00 00 00 00
a0: 01 01 15 65 dd 62 dd 62 92 43 92 43 09 40 09 40
b0: 01 01 15 65 dd 62 dd 62 92 43 92 43 09 40 09 40
c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

0000:04:06.0 VGA compatible controller: ATI Technologies Inc Rage XL (rev 27)
00: 02 10 52 47 83 00 90 02 27 00 00 03 10 40 00 00
10: 00 00 00 fc 01 10 00 00 00 20 00 fd 00 00 00 00
20: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
30: 00 00 f8 ff 5c 00 00 00 00 00 00 00 00 01 08 00
40: 0c 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
50: 02 5c 10 00 01 00 00 ff 00 00 00 00 01 00 02 06
60: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
70: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
90: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00


From chris at suehsi.de  Tue May  9 22:38:13 2006
From: chris at suehsi.de (=?ISO-8859-1?Q?Christian_S=FChs?=)
Date: Tue, 09 May 2006 22:38:13 +0200
Subject: [LinuxBIOS] MB1030 / 3036 VGA resume
In-Reply-To: <8a0c36780605091204l1a72e4b8lc377169b0473a510@mail.gmail.com>
References: <44579320.90206@suehsi.de> <445F7F6B.9060309@suehsi.de>	
	<20060508190903.27473.qmail@cdy.org>
	<445F9A23.3070602@suehsi.de>	 <445F9EFB.5010303@suehsi.de>
	<445FA66F.3000309@suehsi.de>	 <44609D2F.3040305@suehsi.de>	
	<8a0c36780605090732k52415350w523df8dfbf95c547@mail.gmail.com>	
	<4424C30E.8010901@suehsi.de> <4460CCC0.3000706@suehsi.de>
	<8a0c36780605091204l1a72e4b8lc377169b0473a510@mail.gmail.com>
Message-ID: <4460FDB5.5080606@suehsi.de>

Richard Smith schrieb:
>> Question is, how can I set the L1 cache in early state, means set the
>> necassary registers.
> 
> 
> I'm a bit bandwith restricted at the moment so I can't offer a whole
> lot of help..

:D

> 
> There should be some examples of setting CPU registers in the CPU init 
> code.

Problem is, I couldn't find the indexes of this registers in the datasheet.

> 
>> Or how can I solve the not called init section for the gx1.
> 
> 
> Which init function is not being called and what C file is it in?

under src/cpu/amd/model_gx1 are three files:
cpu_setup.inc; gx_setup.inc and model_gx1_init.c

First I have thought, that all stuff is done by the C file, but later I 
have recognized that the other two files initialize the cpu in early 
state, short after or before the RAM init is done.

The C file does exactly the same, but there are the init functions, 
which are not called.

If I understand these mess right, normally this function is called by 
device operations. i.e initializing. But these happens on enabled 
devices, only. cpu_dev_ops seems to be a special case.

However, the function model_gx1_init() is never called for some reason. 
Therefor, x86_enable_cache is not called, too.

The northbridge.c file under src/northbridge/amd/gx1 has a similiar init 
function, it calls the initialize_cpus() function which later calls the 
cpu_initialize function. But this never happens, too.

The captured serial logs have not any debug lines about cpu initializing.

chris


> 
> -- 
> Richard A. Smith
> 
> 




From eric at zyxod.com  Tue May  9 23:16:50 2006
From: eric at zyxod.com (Eric Poulsen)
Date: Tue, 09 May 2006 14:16:50 -0700
Subject: [LinuxBIOS] I give up -- time for a new plan.
Message-ID: <446106C2.3050405@zyxod.com>

I've been researching the IDE/DMA/Linux issue that appears to plague the 
VT8235 southbridge.  Seems there is _no_ reliable fix for this issue, 
which has been known to exhibit itself even in Windows if you're using 
the old/stock via drivers.    Even if I do get the LB issues figured 
out, the DMA issue (as far as I can tell) is _unfixable_.  Reliability 
is a huge thing for me (hence the use of Linux).  The Epia board is 
bound for Ebay.

Here's the big question:

Can someone recommend a _NON-VIA_ small form factor motherboard 
(mini-itx, preferrably), that has all the usual goodies 
(IDE,USB,VGA,serial, etc) that is known to work well with LinuxBios?  
Naturally, one without a VIA chipset?



From smithbone at gmail.com  Tue May  9 23:59:02 2006
From: smithbone at gmail.com (Richard Smith)
Date: Tue, 9 May 2006 16:59:02 -0500
Subject: [LinuxBIOS] I give up -- time for a new plan.
In-Reply-To: <446106C2.3050405@zyxod.com>
References: <446106C2.3050405@zyxod.com>
Message-ID: <8a0c36780605091459s27d4a6bcx82047b9d8fe963e3@mail.gmail.com>

On 5/9/06, Eric Poulsen <eric at zyxod.com> wrote:

> I've been researching the IDE/DMA/Linux issue that appears to plague the
> VT8235 southbridge.  Seems there is _no_ reliable fix for this issue,
> which has been known to exhibit itself even in Windows if you're using
> the old/stock via drivers.    Even if I do get the LB issues figured
> out, the DMA issue (as far as I can tell) is _unfixable_.  Reliability
> is a huge thing for me (hence the use of Linux).  The Epia board is
> bound for Ebay.

Wow thats a major bummer.  Can you summarize up everthing you have
found?  If that is really true that its _unfixable_  then it probally
needs to be up on the wiki.  Save someone else the trouble.

What epia boards does this affect?

> (mini-itx, preferrably), that has all the usual goodies
> (IDE,USB,VGA,serial, etc) that is known to work well with LinuxBios?
> Naturally, one without a VIA chipset?

Working well with LB is the kicker.  You could join us on the GX1
quest.  There are several GX1 boards out there.  If you get one like
Chris's with an external VGA chip then you won't have to mess with the
VSA stuff.  I think the GX1 is close to working good but it just need
a few tweaks to get there.

--
Richard A. Smith



From smithbone at gmail.com  Wed May 10 04:55:59 2006
From: smithbone at gmail.com (Richard Smith)
Date: Tue, 9 May 2006 21:55:59 -0500
Subject: [LinuxBIOS] MB1030 / 3036 VGA resume
In-Reply-To: <4460FDB5.5080606@suehsi.de>
References: <44579320.90206@suehsi.de> <445F9A23.3070602@suehsi.de>
	<445F9EFB.5010303@suehsi.de> <445FA66F.3000309@suehsi.de>
	<44609D2F.3040305@suehsi.de>
	<8a0c36780605090732k52415350w523df8dfbf95c547@mail.gmail.com>
	<4424C30E.8010901@suehsi.de> <4460CCC0.3000706@suehsi.de>
	<8a0c36780605091204l1a72e4b8lc377169b0473a510@mail.gmail.com>
	<4460FDB5.5080606@suehsi.de>
Message-ID: <8a0c36780605091955s6fe971eap8369ed9ff8532fb1@mail.gmail.com>

On 5/9/06, Christian S?hs <chris at suehsi.de> wrote:

> If I understand these mess right, normally this function is called by
> device operations. i.e initializing. But these happens on enabled
> devices, only. cpu_dev_ops seems to be a special case.

Its a maze of little passages linked only by function pointers.

But I think you are correct. I don't think x86_enable_cache() is getting called.

If you look at the northbridge.c for the gx1 you will see that
initialize_cpus() is called by cpu_bus_init() which is in the
cpu_bus_ops struct.  But cpu_bus_ops only gets installed as the init
handler in enable_dev() if the device is marked as
DEVICE_PATH_APIC_CLUSTER.  Looking in the static.c that my tree
generates for the 5bcm I see that the gx1 northbridge is marked as
DEVICE_PATH_PCI_DOMAIN which will cause the .init handler to be 0.

Apply the following patch to your tree and run in spew debug mode. 
This will show if initialize_cpus() is getting called or not.  Perhaps
its getting called by some other path that I don't see.

You can also try adding x86_enable_cache() into the northbridge_init()
function but you will probally need to include the cpu/x86/cache.h
file and perhaps some other header files.

--
Richard A. Smith
-------------- next part --------------
A non-text attachment was scrubbed...
Name: pci_path_debug.patch
Type: application/octet-stream
Size: 1176 bytes
Desc: not available
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20060509/5a2d9d89/attachment.obj>

From eric at zyxod.com  Wed May 10 06:13:39 2006
From: eric at zyxod.com (Eric Poulsen)
Date: Tue, 09 May 2006 21:13:39 -0700
Subject: [LinuxBIOS] I give up -- time for a new plan.
In-Reply-To: <8a0c36780605091459s27d4a6bcx82047b9d8fe963e3@mail.gmail.com>
References: <446106C2.3050405@zyxod.com>
	<8a0c36780605091459s27d4a6bcx82047b9d8fe963e3@mail.gmail.com>
Message-ID: <44616873.8050707@zyxod.com>

Richard Smith wrote:

> On 5/9/06, Eric Poulsen <eric at zyxod.com> wrote:
>
>> I've been researching the IDE/DMA/Linux issue that appears to plague the
>> VT8235 southbridge.  Seems there is _no_ reliable fix for this issue,
>> which has been known to exhibit itself even in Windows if you're using
>> the old/stock via drivers.    Even if I do get the LB issues figured
>> out, the DMA issue (as far as I can tell) is _unfixable_.  Reliability
>> is a huge thing for me (hence the use of Linux).  The Epia board is
>> bound for Ebay.
>
>
> Wow thats a major bummer.  Can you summarize up everthing you have
> found?  If that is really true that its _unfixable_  then it probally
> needs to be up on the wiki.  Save someone else the trouble. 

Not "unfixable" per se, but no fix that I could find that actually works 
100%.  There a bunch of hoops you can jump through that mostly involve 
recompiling the kernel and turning off several features (or turning off 
DMA -- not an option).  In the end, you'll only reduce the likelyhood of 
a crash.

 > What epia boards does this affect?

Well, there's a known issue with the VT8235 Southbridge under heavy DMA 
usage. typically: Heavy IDE usage + Network | PVR | Audio.


From chris at suehsi.de  Wed May 10 10:25:57 2006
From: chris at suehsi.de (=?ISO-8859-1?Q?Christian_S=FChs?=)
Date: Wed, 10 May 2006 10:25:57 +0200
Subject: [LinuxBIOS] I give up -- time for a new plan.
In-Reply-To: <8a0c36780605091459s27d4a6bcx82047b9d8fe963e3@mail.gmail.com>
References: <446106C2.3050405@zyxod.com>
	<8a0c36780605091459s27d4a6bcx82047b9d8fe963e3@mail.gmail.com>
Message-ID: <4461A395.5040009@suehsi.de>

Richard Smith schrieb:
> On 5/9/06, Eric Poulsen <eric at zyxod.com> wrote:
> 
> 
>>I've been researching the IDE/DMA/Linux issue that appears to plague the
>>VT8235 southbridge.  Seems there is _no_ reliable fix for this issue,
>>which has been known to exhibit itself even in Windows if you're using
>>the old/stock via drivers.    Even if I do get the LB issues figured
>>out, the DMA issue (as far as I can tell) is _unfixable_.  Reliability
>>is a huge thing for me (hence the use of Linux).  The Epia board is
>>bound for Ebay.
> 

Somewhere I have read, that disabling the acpi function in the kernel 
solve many problems for the epia.
I use an Epia-M for myself and it works stable, without acpi.
Ok, the running applications for my board don't make high loads on the 
cpu/ide or network.

> Working well with LB is the kicker.  You could join us on the GX1
> quest.  There are several GX1 boards out there.  If you get one like
> Chris's with an external VGA chip then you won't have to mess with the
> VSA stuff.  I think the GX1 is close to working good but it just need
> a few tweaks to get there.

My stb3036 is not the fastet thing I guess ;)
It is a question of usage.

> 
> --
> Richard A. Smith
> 




From chris at suehsi.de  Wed May 10 10:33:10 2006
From: chris at suehsi.de (=?ISO-8859-1?Q?Christian_S=FChs?=)
Date: Wed, 10 May 2006 10:33:10 +0200
Subject: [LinuxBIOS] MB1030 / 3036 VGA resume
In-Reply-To: <8a0c36780605091955s6fe971eap8369ed9ff8532fb1@mail.gmail.com>
References: <44579320.90206@suehsi.de> <445F9A23.3070602@suehsi.de>	
	<445F9EFB.5010303@suehsi.de> <445FA66F.3000309@suehsi.de>	
	<44609D2F.3040305@suehsi.de>	
	<8a0c36780605090732k52415350w523df8dfbf95c547@mail.gmail.com>	
	<4424C30E.8010901@suehsi.de> <4460CCC0.3000706@suehsi.de>	
	<8a0c36780605091204l1a72e4b8lc377169b0473a510@mail.gmail.com>	
	<4460FDB5.5080606@suehsi.de>
	<8a0c36780605091955s6fe971eap8369ed9ff8532fb1@mail.gmail.com>
Message-ID: <4461A546.3060504@suehsi.de>


> If you look at the northbridge.c for the gx1 you will see that
> initialize_cpus() is called by cpu_bus_init() which is in the
> cpu_bus_ops struct.  But cpu_bus_ops only gets installed as the init
> handler in enable_dev() if the device is marked as
> DEVICE_PATH_APIC_CLUSTER.  Looking in the static.c that my tree
> generates for the 5bcm I see that the gx1 northbridge is marked as
> DEVICE_PATH_PCI_DOMAIN which will cause the .init handler to be 0.
> 
> Apply the following patch to your tree and run in spew debug mode. This 
> will show if initialize_cpus() is getting called or not.  Perhaps
> its getting called by some other path that I don't see.
> 

Thanks for the patch, here is the result.

initialize_cpus() is not called.

Currently I used an other Config.lb therefor the northbridge is init not 
as first.
However I will modify the Config.lb back and try it again, but I think 
the result is the nearly the same ;)

Doesn't matter. I think the best way is to init the cpu in early state 
and set the registers for L1 caching before LB does the other stuff. It 
should be much faster as now.

chris
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: pci_patch.cap
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20060510/9da2b640/attachment.ksh>

From stepan at coresystems.de  Wed May 10 11:07:07 2006
From: stepan at coresystems.de (Stefan Reinauer)
Date: Wed, 10 May 2006 11:07:07 +0200
Subject: [LinuxBIOS] I give up -- time for a new plan.
In-Reply-To: <44616873.8050707@zyxod.com>
References: <446106C2.3050405@zyxod.com>
	<8a0c36780605091459s27d4a6bcx82047b9d8fe963e3@mail.gmail.com>
	<44616873.8050707@zyxod.com>
Message-ID: <20060510090707.GA30044@coresystems.de>

* Eric Poulsen <eric at zyxod.com> [060510 06:13]:
> Note that the "fix" is a new BIOS, which is useless to potential LB 
> users.  Also, the ML (my board) is not on there, but it has the EXACT 
> same symptoms.

Does the bios update fix the problem completely? Maybe they do some
smart pci configuration thing or they load a microcode update?

If its pci configuration we might compare the pci config space with the 
old and the new factory bios to find out the fix.

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 chris at suehsi.de  Wed May 10 11:23:08 2006
From: chris at suehsi.de (=?ISO-8859-1?Q?Christian_S=FChs?=)
Date: Wed, 10 May 2006 11:23:08 +0200
Subject: [LinuxBIOS] MB1030 / 3036 VGA resume
In-Reply-To: <4461A546.3060504@suehsi.de>
References: <44579320.90206@suehsi.de>
	<445F9A23.3070602@suehsi.de>		<445F9EFB.5010303@suehsi.de>
	<445FA66F.3000309@suehsi.de>		<44609D2F.3040305@suehsi.de>		<8a0c36780605090732k52415350w523df8dfbf95c547@mail.gmail.com>		<4424C30E.8010901@suehsi.de>
	<4460CCC0.3000706@suehsi.de>		<8a0c36780605091204l1a72e4b8lc377169b0473a510@mail.gmail.com>		<4460FDB5.5080606@suehsi.de>	<8a0c36780605091955s6fe971eap8369ed9ff8532fb1@mail.gmail.com>
	<4461A546.3060504@suehsi.de>
Message-ID: <4461B0FC.3080902@suehsi.de>


> 
> Currently I used an other Config.lb therefor the northbridge is init not 
> as first.
> However I will modify the Config.lb back and try it again, but I think 
> the result is the nearly the same ;)

Ok, here is the second result with the old Config.lb
the different is, that here is the device 0.0 is set to on after the 
PCI_DOMAIN 0 is set on.

Now it seems there are to calls to the dev_enable() function in the 
northbridge.c

chris
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: pci_patch2.cap
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20060510/bd51f38c/attachment.ksh>

From smithbone at gmail.com  Wed May 10 13:18:31 2006
From: smithbone at gmail.com (Richard Smith)
Date: Wed, 10 May 2006 06:18:31 -0500
Subject: [LinuxBIOS] MB1030 / 3036 VGA resume
In-Reply-To: <4461A546.3060504@suehsi.de>
References: <44579320.90206@suehsi.de> <445FA66F.3000309@suehsi.de>
	<44609D2F.3040305@suehsi.de>
	<8a0c36780605090732k52415350w523df8dfbf95c547@mail.gmail.com>
	<4424C30E.8010901@suehsi.de> <4460CCC0.3000706@suehsi.de>
	<8a0c36780605091204l1a72e4b8lc377169b0473a510@mail.gmail.com>
	<4460FDB5.5080606@suehsi.de>
	<8a0c36780605091955s6fe971eap8369ed9ff8532fb1@mail.gmail.com>
	<4461A546.3060504@suehsi.de>
Message-ID: <8a0c36780605100418o1eced8cdr6642561e93ad3aa0@mail.gmail.com>

> Doesn't matter. I think the best way is to init the cpu in early state
> and set the registers for L1 caching before LB does the other stuff. It
> should be much faster as now.

Try the attached patch and see if it helps

--
Richard A. Smith
-------------- next part --------------
A non-text attachment was scrubbed...
Name: gx1_early_L1.patch
Type: application/octet-stream
Size: 473 bytes
Desc: not available
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20060510/8d12bef6/attachment.obj>

From eric at zyxod.com  Wed May 10 17:35:29 2006
From: eric at zyxod.com (Eric Poulsen)
Date: Wed, 10 May 2006 08:35:29 -0700
Subject: [LinuxBIOS] I give up -- time for a new plan.
In-Reply-To: <20060510090707.GA30044@coresystems.de>
References: <446106C2.3050405@zyxod.com>
	<8a0c36780605091459s27d4a6bcx82047b9d8fe963e3@mail.gmail.com>
	<44616873.8050707@zyxod.com>
	<20060510090707.GA30044@coresystems.de>
Message-ID: <44620841.8090509@zyxod.com>

Stefan Reinauer wrote:
> * Eric Poulsen <eric at zyxod.com> [060510 06:13]:
>   
>> Note that the "fix" is a new BIOS, which is useless to potential LB 
>> users.  Also, the ML (my board) is not on there, but it has the EXACT 
>> same symptoms.
>>     
>
> Does the bios update fix the problem completely? Maybe they do some
> smart pci configuration thing or they load a microcode update?
>   
Some people say that it works for them, other people say it's useless.

Upon further reading, there might be two distinct problems: DMA bugs in 
8235/8237 and/or Linux CPU scaling (longhaul).
> If its pci configuration we might compare the pci config space with the 
> old and the new factory bios to find out the fix.
>   
Only if the bios actually works, and there isn't any reason to believe 
it does.  Additionally, there isn't a "fix" bios for my board.  Best I 
can do is try the M bios and hope that it works for the ML boards.
> Stefan
>
>   




From chris at suehsi.de  Wed May 10 19:04:14 2006
From: chris at suehsi.de (=?ISO-8859-1?Q?Christian_S=FChs?=)
Date: Wed, 10 May 2006 19:04:14 +0200
Subject: [LinuxBIOS] MB1030 / 3036 VGA resume
In-Reply-To: <8a0c36780605100418o1eced8cdr6642561e93ad3aa0@mail.gmail.com>
References: <44579320.90206@suehsi.de>
	<445FA66F.3000309@suehsi.de>	<44609D2F.3040305@suehsi.de>	<8a0c36780605090732k52415350w523df8dfbf95c547@mail.gmail.com>	<4424C30E.8010901@suehsi.de>
	<4460CCC0.3000706@suehsi.de>	<8a0c36780605091204l1a72e4b8lc377169b0473a510@mail.gmail.com>	<4460FDB5.5080606@suehsi.de>	<8a0c36780605091955s6fe971eap8369ed9ff8532fb1@mail.gmail.com>	<4461A546.3060504@suehsi.de>
	<8a0c36780605100418o1eced8cdr6642561e93ad3aa0@mail.gmail.com>
Message-ID: <44621D0E.70205@suehsi.de>


> Try the attached patch and see if it helps
> 

shit, that didn't work.
Now the RAM is not proper detected and LB fails on start by jumping to.

should it be addl or andl, 0x9fffffff ??

However I have tried both and for both cases it fails.

I think is it not possible to easy write to cr0, I will try the patch 
later in the code after enabling these registers.

chris

> -- 
> Richard A. Smit
> h
> 




From stuge-linuxbios at cdy.org  Wed May 10 20:21:48 2006
From: stuge-linuxbios at cdy.org (Peter Stuge)
Date: Wed, 10 May 2006 20:21:48 +0200
Subject: [LinuxBIOS] MB1030 / 3036 VGA resume
In-Reply-To: <44621D0E.70205@suehsi.de>
References: <44609D2F.3040305@suehsi.de>
	<8a0c36780605090732k52415350w523df8dfbf95c547@mail.gmail.com>
	<4424C30E.8010901@suehsi.de> <4460CCC0.3000706@suehsi.de>
	<8a0c36780605091204l1a72e4b8lc377169b0473a510@mail.gmail.com>
	<4460FDB5.5080606@suehsi.de>
	<8a0c36780605091955s6fe971eap8369ed9ff8532fb1@mail.gmail.com>
	<4461A546.3060504@suehsi.de>
	<8a0c36780605100418o1eced8cdr6642561e93ad3aa0@mail.gmail.com>
	<44621D0E.70205@suehsi.de>
Message-ID: <20060510182148.19201.qmail@cdy.org>

On Wed, May 10, 2006 at 07:04:14PM +0200, Christian S?hs wrote:
> should it be addl or andl, 0x9fffffff ??

andl, intent is to clear bits 2,1 in the top nibble.


> However I have tried both and for both cases it fails.
> 
> I think is it not possible to easy write to cr0, I will try the
> patch later in the code after enabling these registers.

Hmm, cr0 should always be available..


//Peter



From rminnich at lanl.gov  Wed May 10 20:11:53 2006
From: rminnich at lanl.gov (Ronald G Minnich)
Date: Wed, 10 May 2006 12:11:53 -0600
Subject: [LinuxBIOS] LB vs Factory BIOS -- more weirdness
In-Reply-To: <445C4C04.6090302@zyxod.com>
References: <445C4C04.6090302@zyxod.com>
Message-ID: <44622CE9.2020200@lanl.gov>

Eric Poulsen wrote:

> 
> I'm conviced this is the case -- I have too many weird issues that can 
> be fixed by simply flipping back to the factory BIOS, turning the system 
> on, getting a "bad CMOS" error, then immediately powering off and 
> switching to LB, which suddenly works again.
> 


You could try this: do the exact same test, but turn off the board, 
*disconnect the power connector*, let it sit 30 seconds, and then put in 
LB and see if it works or not.

I'd be interested to hear this result.

ron



From pada at chemonline.de  Wed May 10 21:30:07 2006
From: pada at chemonline.de (Daniel Parthey)
Date: Wed, 10 May 2006 21:30:07 +0200
Subject: [LinuxBIOS] I give up -- time for a new plan.
In-Reply-To: <4461A395.5040009@suehsi.de>
References: <446106C2.3050405@zyxod.com>
	<8a0c36780605091459s27d4a6bcx82047b9d8fe963e3@mail.gmail.com>
	<4461A395.5040009@suehsi.de>
Message-ID: <20060510193007.GA11995@daniel.localdomain>

Christian S?hs schrieb:
> Richard Smith schrieb:
>> On 5/9/06, Eric Poulsen <eric at zyxod.com> wrote:
>> 
>>>I've been researching the IDE/DMA/Linux issue that appears to plague
>>>the VT8235 southbridge.  Seems there is _no_ reliable fix for this
>>>issue, [...] Reliability is a huge thing for me (hence the use of
>>>Linux).  The Epia board is bound for Ebay.
> 
> Somewhere I have read, that disabling the acpi function in the kernel 
> solve many problems for the epia.
> I use an Epia-M for myself and it works stable, without acpi.

Somebody on this list recommended me to disable ACPI in the Linux kernel.
This had solved my kernel panic on EPIA ML.
Eric, please try to disable ACPI, even if it is merely a workaround.

Any ideas why kernel ACPI works with factory BIOS but panics
with LinuxBIOS on VIA EPIA ML?

Thanks,
Daniel.
-- 
Jabber: pada at jabber.ccc.de



From hawke at hawkesnest.net  Wed May 10 21:50:28 2006
From: hawke at hawkesnest.net (Alex Mauer)
Date: Wed, 10 May 2006 14:50:28 -0500
Subject: [LinuxBIOS] EPIA non-M?
In-Reply-To: <8a0c36780605090726p47464840kbd93d0607108aaee@mail.gmail.com>
References: <e30v1u$d74$1@sea.gmane.org>
	<4454342B.3080107@lanl.gov>	<e31mo9$2bj$1@sea.gmane.org>	<8a0c36780604301307k4de0f25fx618aa50d97fd98be@mail.gmail.com>	<e3p9ls$nhr$1@sea.gmane.org>
	<44602932.4060203@lanl.gov>
	<8a0c36780605090726p47464840kbd93d0607108aaee@mail.gmail.com>
Message-ID: <e3tg6c$s1e$1@sea.gmane.org>

Richard Smith wrote:
> On 5/9/06, Ronald G Minnich <rminnich at lanl.gov> wrote:
>> some commit totally busted memory timings on non-M. I have not had time
>> to even think about it.
> 
> Attached is the svn log for mods to vt8601 raminit.c.  Try pulling
> some of these old versions and see if you can find one that works. 

OK.

First I tried pulling those revisions of the entire tree.

r1954 and earlier, romcc wouldn't compile.  r1619 and earlier,
buildtarget failed on the config files.

So I tried just pulling src/northbridge/via/vt8601/raminit.c in from
each of those revisions.

None of them got past the jump to LinuxBIOS.

Tonight I'll try versions between 1619 and current with romcc from the
current version but all else being their own versions.

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

From smithbone at gmail.com  Wed May 10 21:53:01 2006
From: smithbone at gmail.com (Richard Smith)
Date: Wed, 10 May 2006 14:53:01 -0500
Subject: [LinuxBIOS] MB1030 / 3036 VGA resume
In-Reply-To: <44621D0E.70205@suehsi.de>
References: <44579320.90206@suehsi.de>
	<8a0c36780605090732k52415350w523df8dfbf95c547@mail.gmail.com>
	<4424C30E.8010901@suehsi.de> <4460CCC0.3000706@suehsi.de>
	<8a0c36780605091204l1a72e4b8lc377169b0473a510@mail.gmail.com>
	<4460FDB5.5080606@suehsi.de>
	<8a0c36780605091955s6fe971eap8369ed9ff8532fb1@mail.gmail.com>
	<4461A546.3060504@suehsi.de>
	<8a0c36780605100418o1eced8cdr6642561e93ad3aa0@mail.gmail.com>
	<44621D0E.70205@suehsi.de>
Message-ID: <8a0c36780605101253p5542bf6dpcd9c711e563f8020@mail.gmail.com>

On 5/10/06, Christian S?hs <chris at suehsi.de> wrote:
>
> > Try the attached patch and see if it helps
> >
>
> shit, that didn't work.
> Now the RAM is not proper detected and LB fails on start by jumping to.
>

After I sent that I wondered to myself what that would do.  That
enables the cache before the RAM is initialized.  Thats probally the
reason that its not done that way already.

Ok so here's a new northbridge.c patch reverse the previous one and
apply.  This will call cache_enable() in northbridge_init().

Its a hack but should be ok for our test.

--
Richard A. Smith
-------------- next part --------------
A non-text attachment was scrubbed...
Name: gx1_northbridge_cache_hack.patch
Type: application/octet-stream
Size: 1477 bytes
Desc: not available
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20060510/7e1b36ed/attachment.obj>

From smithbone at gmail.com  Wed May 10 21:56:43 2006
From: smithbone at gmail.com (Richard Smith)
Date: Wed, 10 May 2006 14:56:43 -0500
Subject: [LinuxBIOS] EPIA non-M?
In-Reply-To: <e3tg6c$s1e$1@sea.gmane.org>
References: <e30v1u$d74$1@sea.gmane.org> <4454342B.3080107@lanl.gov>
	<e31mo9$2bj$1@sea.gmane.org>
	<8a0c36780604301307k4de0f25fx618aa50d97fd98be@mail.gmail.com>
	<e3p9ls$nhr$1@sea.gmane.org> <44602932.4060203@lanl.gov>
	<8a0c36780605090726p47464840kbd93d0607108aaee@mail.gmail.com>
	<e3tg6c$s1e$1@sea.gmane.org>
Message-ID: <8a0c36780605101256v4a606ccds1a8335bc60955581@mail.gmail.com>

On 5/10/06, Alex Mauer <hawke at hawkesnest.net> wrote:

>
> So I tried just pulling src/northbridge/via/vt8601/raminit.c in from
> each of those revisions.
>

Have you looked at the #defines in raminit.c?  I see serveral that you
may need to verify are set the right way for you board.

--
Richard A. Smith



From chris at suehsi.de  Wed May 10 21:45:44 2006
From: chris at suehsi.de (=?ISO-8859-1?Q?Christian_S=FChs?=)
Date: Wed, 10 May 2006 21:45:44 +0200
Subject: [LinuxBIOS] MB1030 / 3036 VGA resume
In-Reply-To: <20060510182148.19201.qmail@cdy.org>
References: <44609D2F.3040305@suehsi.de>	<8a0c36780605090732k52415350w523df8dfbf95c547@mail.gmail.com>	<4424C30E.8010901@suehsi.de>
	<4460CCC0.3000706@suehsi.de>	<8a0c36780605091204l1a72e4b8lc377169b0473a510@mail.gmail.com>	<4460FDB5.5080606@suehsi.de>	<8a0c36780605091955s6fe971eap8369ed9ff8532fb1@mail.gmail.com>	<4461A546.3060504@suehsi.de>	<8a0c36780605100418o1eced8cdr6642561e93ad3aa0@mail.gmail.com>	<44621D0E.70205@suehsi.de>
	<20060510182148.19201.qmail@cdy.org>
Message-ID: <446242E8.5070209@suehsi.de>

Peter Stuge schrieb:
> On Wed, May 10, 2006 at 07:04:14PM +0200, Christian S?hs wrote:
> 
>>should it be addl or andl, 0x9fffffff ??
> 
> 
> andl, intent is to clear bits 2,1 in the top nibble.
> 
> 
> 
>>However I have tried both and for both cases it fails.
>>
>>I think is it not possible to easy write to cr0, I will try the
>>patch later in the code after enabling these registers.
> 
> 
> Hmm, cr0 should always be available..
> 
> 
> //Peter
> 

Could be the patch wrong?

In cache.h the enable_cache function looks different.

there is a "asm volatile" for read/write operation.
movl %%cr0, %0
movl %0, %%cr0

I mean the double "%%"


chris





From rminnich at lanl.gov  Wed May 10 22:09:30 2006
From: rminnich at lanl.gov (Ronald G Minnich)
Date: Wed, 10 May 2006 14:09:30 -0600
Subject: [LinuxBIOS] I give up -- time for a new plan.
In-Reply-To: <20060510193007.GA11995@daniel.localdomain>
References: <446106C2.3050405@zyxod.com>	<8a0c36780605091459s27d4a6bcx82047b9d8fe963e3@mail.gmail.com>	<4461A395.5040009@suehsi.de>
	<20060510193007.GA11995@daniel.localdomain>
Message-ID: <4462487A.60607@lanl.gov>

Daniel Parthey wrote:
> Christian S?hs schrieb:
> 
>>Richard Smith schrieb:
>>
>>>On 5/9/06, Eric Poulsen <eric at zyxod.com> wrote:
>>>
>>>
>>>>I've been researching the IDE/DMA/Linux issue that appears to plague
>>>>the VT8235 southbridge.  Seems there is _no_ reliable fix for this
>>>>issue, [...] Reliability is a huge thing for me (hence the use of
>>>>Linux).  The Epia board is bound for Ebay.
>>
>>Somewhere I have read, that disabling the acpi function in the kernel 
>>solve many problems for the epia.
>>I use an Epia-M for myself and it works stable, without acpi.
> 
> 
> Somebody on this list recommended me to disable ACPI in the Linux kernel.
> This had solved my kernel panic on EPIA ML.
> Eric, please try to disable ACPI, even if it is merely a workaround.
> 
> Any ideas why kernel ACPI works with factory BIOS but panics
> with LinuxBIOS on VIA EPIA ML?
> 

oh, there's all kinds of fun possibilities :-)

possible the ML says 'tweak this bit' and the bit is set up wrong on LB.

ACPI is Yer Basic Shoppe of Horrors

ron



From smithbone at gmail.com  Wed May 10 22:25:28 2006
From: smithbone at gmail.com (Richard Smith)
Date: Wed, 10 May 2006 15:25:28 -0500
Subject: [LinuxBIOS] MB1030 / 3036 VGA resume
In-Reply-To: <446242E8.5070209@suehsi.de>
References: <44609D2F.3040305@suehsi.de> <4460CCC0.3000706@suehsi.de>
	<8a0c36780605091204l1a72e4b8lc377169b0473a510@mail.gmail.com>
	<4460FDB5.5080606@suehsi.de>
	<8a0c36780605091955s6fe971eap8369ed9ff8532fb1@mail.gmail.com>
	<4461A546.3060504@suehsi.de>
	<8a0c36780605100418o1eced8cdr6642561e93ad3aa0@mail.gmail.com>
	<44621D0E.70205@suehsi.de> <20060510182148.19201.qmail@cdy.org>
	<446242E8.5070209@suehsi.de>
Message-ID: <8a0c36780605101325r29ad0a90s49b9d5cce545665c@mail.gmail.com>

> there is a "asm volatile" for read/write operation.
> movl %%cr0, %0
> movl %0, %%cr0
>
> I mean the double "%%"

Thats because it's used in a .c file.  I did it in straight assembly
in an .inc file

--
Richard A. Smith



From chris at suehsi.de  Thu May 11 09:17:45 2006
From: chris at suehsi.de (=?ISO-8859-1?Q?Christian_S=FChs?=)
Date: Thu, 11 May 2006 09:17:45 +0200
Subject: [LinuxBIOS] MB1030 / 3036 VGA resume
In-Reply-To: <8a0c36780605101253p5542bf6dpcd9c711e563f8020@mail.gmail.com>
References: <44579320.90206@suehsi.de>	
	<8a0c36780605090732k52415350w523df8dfbf95c547@mail.gmail.com>	
	<4424C30E.8010901@suehsi.de> <4460CCC0.3000706@suehsi.de>	
	<8a0c36780605091204l1a72e4b8lc377169b0473a510@mail.gmail.com>	
	<4460FDB5.5080606@suehsi.de>	
	<8a0c36780605091955s6fe971eap8369ed9ff8532fb1@mail.gmail.com>	
	<4461A546.3060504@suehsi.de>	
	<8a0c36780605100418o1eced8cdr6642561e93ad3aa0@mail.gmail.com>	
	<44621D0E.70205@suehsi.de>
	<8a0c36780605101253p5542bf6dpcd9c711e563f8020@mail.gmail.com>
Message-ID: <4462E519.90101@suehsi.de>


> 
> Its a hack but should be ok for our test.
>

Woooooooooooow, LB boots like a rocket ;)

Ok, now it is much faster as before.
The vga initialization is done in ca. 9s.
copying initrd and the kernel and also uncompressing the kernel is like 
under factory bios.

The only thing which is slow, is to copy LB in the RAM.

The perfect sulotion seems to be enabling the L1 cache in the early 
state of LB.

9s for vga is not fast, but I think we would find the reason for that.
if there is any.


chris



> -- 
> Richard A. Smit
> h




From vincentetsou at nexcom.com.tw  Thu May 11 11:30:55 2006
From: vincentetsou at nexcom.com.tw (Vincente Tsou)
Date: Thu, 11 May 2006 17:30:55 +0800
Subject: [LinuxBIOS] New guy in LinuxBios
In-Reply-To: <41fde3420605102111t1759001cm44888d1be62be7b3@mail.gmail.com>
References: <41fde3420605102111t1759001cm44888d1be62be7b3@mail.gmail.com>
Message-ID: <41fde3420605110230j7e40fb7es7de020d18e13a091@mail.gmail.com>

 Hello LinuxBios elders,

I'm sorry to bother you.

I'm begining to study LinuxBios and I have some problem in it.
Hope you can give me some idea.

My target board is an AMD Opteron (chipset: K8 / 8111 / 8131) mainboard,
it is similar to Tyan s2880 / s2881 / s2882.

So I base on Tyan s2880 to change some config file to compile a
linuxbios.rom,
but it doesn't work.

Following is what do I changed in s2880:
1. I changed the payload path in targets/tyan/s2880/Config.lb.
2. modify src/mainboard/tyan/s2880/Config.lb as 42812-pci.txt. ( as
attachment )
    I don't know is it correct that I modified. If you have interest you can
refer to Attachment.
3. generated irq_tables.c by getpir.c and replaced the original one.

compile and burn it in rom.

After I boot up the target board, it always alert emergency beep.

Then, I unmark some debug message in 'src/northbridge/amd/amdk8/raminit.c'
to see where is it hang.
The last step is hang on setup_default_resource_map() in
'src/mainboard/tyan/s2880/cache_as_ram_auto.c',
I can see it from serial console ( as attachment again. )

Is there any configuration I should change, and I didn't do ?
How can I debug it ?

Thanks a lot.



-- 
Best Regards,
Vincente Tsou

Engineer
R/D, S/W Dept.
NEXCOM International Co.
Tel: 886-2-82280606 Ext. 3205
Fax: 886-2-82280506
E-mail: vincentetsou at nexcom.com.tw
Web: http://www.nexcom.com.tw/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20060511/3a8e88cd/attachment.html>
-------------- next part --------------
##
## 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 PAYLOAD_SIZE            = ( ROM_SECTION_SIZE - ROM_IMAGE_SIZE )
default CONFIG_ROM_STREAM_START = (0xffffffff - ROM_SIZE + ROM_SECTION_OFFSET + 1)

##
## 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 )

arch i386 end 

##
## Build the objects we have code for in this directory.
##

driver mainboard.o

#dir /drivers/si/3114

if HAVE_MP_TABLE object mptable.o end
if HAVE_PIRQ_TABLE object irq_tables.o end

if USE_DCACHE_RAM

if CONFIG_USE_INIT

makerule ./auto.o
        depends "$(MAINBOARD)/cache_as_ram_auto.c option_table.h"
        action "$(CC) -I$(TOP)/src -I. $(CPPFLAGS) $(MAINBOARD)/cache_as_ram_auto.c -Os -nostdinc -nostdlib -fno-builtin -Wall -c -o auto.o" 
end

else    
                
makerule ./auto.inc
        depends "$(MAINBOARD)/cache_as_ram_auto.c option_table.h"
        action "$(CC) -I$(TOP)/src -I. $(CPPFLAGS) $(MAINBOARD)/cache_as_ram_auto.c -Os -nostdinc -nostdlib -fno-builtin -Wall -c -S -o $@"         
        action "perl -e 's/.rodata/.rom.data/g' -pi $@"
        action "perl -e 's/.text/.section .rom.text/g' -pi $@"
end

end
else

##
## 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=k8 -O2 -I$(TOP)/src -I. $(CPPFLAGS) $(MAINBOARD)/auto.c -o $@"
end
makerule ./auto.inc
        depends "$(MAINBOARD)/auto.c option_table.h ./romcc"
        action  "./romcc    -mcpu=k8 -O2 -I$(TOP)/src -I. $(CPPFLAGS) $(MAINBOARD)/auto.c -o $@"
end

end
##
## Build our 16 bit and 32 bit linuxBIOS entry code
##
if USE_FALLBACK_IMAGE
        mainboardinit cpu/x86/16bit/entry16.inc
        ldscript /cpu/x86/16bit/entry16.lds
end

mainboardinit cpu/x86/32bit/entry32.inc

if USE_DCACHE_RAM
        if CONFIG_USE_INIT
                ldscript /cpu/x86/32bit/entry32.lds
        end

        if CONFIG_USE_INIT
                ldscript      /cpu/amd/car/cache_as_ram.lds
        end
end

##
## 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

if USE_DCACHE_RAM
else
### Should this be in the northbridge code?
mainboardinit arch/i386/lib/cpu_reset.inc
end

##
## Include an id string (For safe flashing)
##
mainboardinit arch/i386/lib/id.inc
ldscript /arch/i386/lib/id.lds

if USE_DCACHE_RAM
##
## Setup Cache-As-Ram
##
mainboardinit cpu/amd/car/cache_as_ram.inc
end

###
### 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
if USE_DCACHE_RAM
       ldscript /arch/i386/lib/failover.lds
else
       ldscript /arch/i386/lib/failover.lds
        mainboardinit ./failover.inc
end
end

###
### O.k. We aren't just an intermediary anymore!
###

##
## Setup RAM
##
if USE_DCACHE_RAM

if CONFIG_USE_INIT
initobject auto.o
else
mainboardinit ./auto.inc
end

else

##
## Setup RAM
##
mainboardinit cpu/x86/fpu/enable_fpu.inc
mainboardinit cpu/x86/mmx/enable_mmx.inc
mainboardinit cpu/x86/sse/enable_sse.inc
mainboardinit ./auto.inc
mainboardinit cpu/x86/sse/disable_sse.inc
mainboardinit cpu/x86/mmx/disable_mmx.inc

end

##
## Include the secondary Configuration files 
##
if CONFIG_CHIP_NAME
	config chip.h
end

# sample config for tyan/s2880
chip northbridge/amd/amdk8/root_complex
        device apic_cluster 0 on
                chip cpu/amd/socket_940
                        device apic 0 on end
                end
        end
	device pci_domain 0 on
		chip northbridge/amd/amdk8
                        device pci 18.0 on end # LDT0
                        device pci 18.0 on end # LDT1
			device pci 18.0 on #  northbridge 
				#  devices on link 0, link 0 == LDT 0
				chip southbridge/amd/amd8131
					# the on/off keyword is mandatory
					device pci 8.0 on
                                                chip drivers/pci/onboard
                                                        device pci 4.0 on end #broadcom
							device pci 4.1 on end 
                                                end
					end
					device pci 8.1 on end
					device pci 9.0 on end
					device pci 9.1 on end
				end
				chip southbridge/amd/amd8111
					# this "device pci 0.0" is the parent the next one
					# PCI bridge
					device pci 6.0 on
						device pci 6.0 on end
						device pci 6.1 on end
						device pci 6.2 off end
						device pci 7.0 off end
                                                chip drivers/pci/onboard
                                                        #device pci 5.0 on end #some sata
                                                        device pci 0.0 on end	# AMD-8111 USB 
                                                        device pci 0.1 on end	# AMD-8111 USB 
                                                        device pci 2.0 on end	# ATI Rage XL
                                                        device pci 4.0 on end	# Intel Ethernet Pro 100
                                                end
                                                #chip drivers/pci/onboard
                                                #        device pci 6.0 on end #adti
                                                #        register "rom_address" = "0xfff80000"
                                                #end
					end
					# ISA bridge
					device pci 7.0 on
						chip superio/winbond/w83627hf
							device pnp 2e.0 on #  Floppy
                	                 			io 0x60 = 0x3f0
                	                			irq 0x70 = 6
                	                			drq 0x74 = 2
							end
                	        			device pnp 2e.1 off #  Parallel Port
                	                 			io 0x60 = 0x378
                	                			irq 0x70 = 7
							end
                	        			device pnp 2e.2 on #  Com1
                	                 			io 0x60 = 0x3f8
                	                			irq 0x70 = 4
							end
                	        			device pnp 2e.3 off #  Com2
                	                 			io 0x60 = 0x2f8
                	                			irq 0x70 = 3
							end
                	        			device pnp 2e.5 on #  Keyboard
                	                 			io 0x60 = 0x60
                	                 			io 0x62 = 0x64
                	                			irq 0x70 = 1
								irq 0x72 = 12
							end
                	                                device pnp 2e.6 off #  CIR
                	                                        io 0x60 = 0x100
                	                                end
                	                                device pnp 2e.7 off #  GAME_MIDI_GIPO1
                	                                        io 0x60 = 0x220
                	                                        io 0x62 = 0x300
                	                                        irq 0x70 = 9
                	                                end  
                	                                device pnp 2e.8 off end #  GPIO2
                	                                device pnp 2e.9 off end #  GPIO3
                	                                device pnp 2e.a off end #  ACPI
                	                                device pnp 2e.b on #  HW Monitor
                	                                        io 0x60 = 0x290
                	                                        irq 0x70 = 5
                	                                end
						end
					end
					device pci 7.1 on end	# AMD-8111 IDE
					device pci 7.2 on end	# AMD-8111 SMBus 2.0
					device pci 7.3 on end	# AMD-8111 ACPI
					device pci 7.5 off end
					device pci 7.6 off end
                                        register "ide0_enable" = "1"
                                        register "ide1_enable" = "1"
				end
			end #  device pci 18.0 
			
                	device pci 18.0 on end	#K8 HyperTransport Technology Configuration
                	device pci 18.0 on end	#K8 HyperTransport Technology Configuration
			
			device pci 18.1 on end	#K8 Address Map
			device pci 18.2 on end	#K8 DRAM Controller
			device pci 18.3 on end	#K8 Miscellaneous Control
		end
	end 
end












-------------- next part --------------
00:06.0 PCI bridge: Advanced Micro Devices [AMD] AMD-8111 PCI (rev 07)
00:07.0 ISA bridge: Advanced Micro Devices [AMD] AMD-8111 LPC (rev 05)
00:07.1 IDE interface: Advanced Micro Devices [AMD] AMD-8111 IDE (rev 03)
00:07.2 SMBus: Advanced Micro Devices [AMD] AMD-8111 SMBus 2.0 (rev 02)
00:07.3 Bridge: Advanced Micro Devices [AMD] AMD-8111 ACPI (rev 05)
00:08.0 PCI bridge: Advanced Micro Devices [AMD] AMD-8131 PCI-X Bridge (rev 12)
00:08.1 PIC: Advanced Micro Devices [AMD] AMD-8131 PCI-X APIC (rev 01)
00:09.0 PCI bridge: Advanced Micro Devices [AMD] AMD-8131 PCI-X Bridge (rev 12)
00:09.1 PIC: Advanced Micro Devices [AMD] AMD-8131 PCI-X APIC (rev 01)
00:18.0 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] HyperTransport Technology Configuration
00:18.1 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] Address Map
00:18.2 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] DRAM Controller
00:18.3 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] Miscellaneous Control
01:00.0 USB Controller: Advanced Micro Devices [AMD] AMD-8111 USB (rev 0b)
01:00.1 USB Controller: Advanced Micro Devices [AMD] AMD-8111 USB (rev 0b)
01:02.0 VGA compatible controller: ATI Technologies Inc Rage XL (rev 27)
01:04.0 Ethernet controller: Intel Corp. 82557/8/9 [Ethernet Pro 100] (rev 10)
03:04.0 Ethernet controller: Broadcom Corporation NetXtreme BCM5704S Gigabit Ethernet (rev 03)
03:04.1 Ethernet controller: Broadcom Corporation NetXtreme BCM5704S Gigabit Ethernet (rev 03)



00:06.0 Class 0604: 1022:7460 (rev 07)
00:07.0 Class 0601: 1022:7468 (rev 05)
00:07.1 Class 0101: 1022:7469 (rev 03)
00:07.2 Class 0c05: 1022:746a (rev 02)
00:07.3 Class 0680: 1022:746b (rev 05)
00:08.0 Class 0604: 1022:7450 (rev 12)
00:08.1 Class 0800: 1022:7451 (rev 01)
00:09.0 Class 0604: 1022:7450 (rev 12)
00:09.1 Class 0800: 1022:7451 (rev 01)
00:18.0 Class 0600: 1022:1100
00:18.1 Class 0600: 1022:1101
00:18.2 Class 0600: 1022:1102
00:18.3 Class 0600: 1022:1103
01:00.0 Class 0c03: 1022:7464 (rev 0b)
01:00.1 Class 0c03: 1022:7464 (rev 0b)
01:02.0 Class 0300: 1002:4752 (rev 27)
01:04.0 Class 0200: 8086:1229 (rev 10)
03:04.0 Class 0200: 14e4:16a8 (rev 03)
03:04.1 Class 0200: 14e4:16a8 (rev 03)



00:06.0 PCI bridge: Advanced Micro Devices [AMD] AMD-8111 PCI (rev 07) (prog-if 00 [Normal decode])
	Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV+ VGASnoop- ParErr- Stepping- SERR+ FastB2B-
	Status: Cap+ 66Mhz+ UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
	Latency: 64
	Bus: primary=00, secondary=01, subordinate=01, sec-latency=64
	I/O behind bridge: 00009000-0000bfff
	Memory behind bridge: fc900000-fe9fffff
	Prefetchable memory behind bridge: fff00000-000fffff
	Secondary status: 66Mhz- FastB2B- ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort+ <SERR- <PERR-
	BridgeCtl: Parity+ SERR+ NoISA- VGA+ MAbort- >Reset- FastB2B-
	Capabilities: [c0] HyperTransport: Slave or Primary Interface
	!!! Possibly incomplete decoding
		Command: BaseUnitID=6 UnitCnt=4 MastHost- DefDir-
		Link Control 0: CFlE- CST- CFE- <LkFail- Init+ EOC- TXO- <CRCErr=0
		Link Config 0: MLWI=8bit MLWO=8bit LWI=8bit LWO=8bit
		Link Control 1: CFlE- CST- CFE- <LkFail+ Init- EOC+ TXO+ <CRCErr=0
		Link Config 1: MLWI=8bit MLWO=8bit LWI=8bit LWO=8bit
		Revision ID: 1.02
	Capabilities: [f0] HyperTransport: Interrupt Discovery and Configuration

00:07.0 ISA bridge: Advanced Micro Devices [AMD] AMD-8111 LPC (rev 05)
	Subsystem: Advanced Micro Devices [AMD] AMD-8111 LPC
	Control: I/O+ Mem+ BusMaster+ SpecCycle+ MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
	Status: Cap- 66Mhz+ UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
	Latency: 0

00:07.1 IDE interface: Advanced Micro Devices [AMD] AMD-8111 IDE (rev 03) (prog-if 8a [Master SecP PriP])
	Subsystem: Advanced Micro Devices [AMD] AMD-8111 IDE
	Control: I/O+ Mem- BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
	Status: Cap- 66Mhz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
	Latency: 32
	Region 4: I/O ports at ffa0 [size=16]

00:07.2 SMBus: Advanced Micro Devices [AMD] AMD-8111 SMBus 2.0 (rev 02)
	Subsystem: Advanced Micro Devices [AMD] AMD-8111 SMBus 2.0
	Control: I/O+ Mem- BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
	Status: Cap- 66Mhz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
	Interrupt: pin D routed to IRQ 11
	Region 0: I/O ports at cc00 [size=32]

00:07.3 Bridge: Advanced Micro Devices [AMD] AMD-8111 ACPI (rev 05)
	Subsystem: Advanced Micro Devices [AMD] AMD-8111 ACPI
	Control: I/O- Mem- BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
	Status: Cap- 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-

00:08.0 PCI bridge: Advanced Micro Devices [AMD] AMD-8131 PCI-X Bridge (rev 12) (prog-if 00 [Normal decode])
	Control: I/O- Mem- BusMaster+ SpecCycle- MemWINV+ VGASnoop- ParErr- Stepping- SERR+ FastB2B-
	Status: Cap+ 66Mhz+ UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
	Latency: 64
	Bus: primary=00, secondary=02, subordinate=02, sec-latency=64
	I/O behind bridge: 0000f000-00000fff
	Memory behind bridge: fff00000-000fffff
	Prefetchable memory behind bridge: 00000000fff00000-0000000000000000
	Secondary status: 66Mhz+ FastB2B- ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort+ <SERR- <PERR-
	BridgeCtl: Parity+ SERR+ NoISA+ VGA- MAbort- >Reset- FastB2B-
	Capabilities: [a0] PCI-X bridge device.
		Secondary Status: 64bit+, 133MHz+, SCD-, USC-, SCO-, SRD- Freq=3
		Status: Bus=0 Dev=8 Func=0 64bit+ 133MHz+ SCD- USC-, SCO-, SRD-
		: Upstream: Capacity=14, Commitment Limit=65535
		: Downstream: Capacity=2, Commitment Limit=65535
	Capabilities: [b8] HyperTransport: Interrupt Discovery and Configuration
	Capabilities: [c0] HyperTransport: Slave or Primary Interface
	!!! Possibly incomplete decoding
		Command: BaseUnitID=8 UnitCnt=2 MastHost- DefDir-
		Link Control 0: CFlE- CST- CFE- <LkFail- Init+ EOC- TXO- <CRCErr=0
		Link Config 0: MLWI=16bit MLWO=16bit LWI=8bit LWO=8bit
		Link Control 1: CFlE- CST- CFE- <LkFail- Init+ EOC- TXO- <CRCErr=0
		Link Config 1: MLWI=8bit MLWO=8bit LWI=8bit LWO=8bit
		Revision ID: 1.02

00:08.1 PIC: Advanced Micro Devices [AMD] AMD-8131 PCI-X APIC (rev 01) (prog-if 10 [IO-APIC])
	Subsystem: Advanced Micro Devices [AMD] AMD-8131 PCI-X APIC
	Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
	Status: Cap- 66Mhz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
	Latency: 0
	Region 0: Memory at febff000 (64-bit, non-prefetchable) [size=4K]

00:09.0 PCI bridge: Advanced Micro Devices [AMD] AMD-8131 PCI-X Bridge (rev 12) (prog-if 00 [Normal decode])
	Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV+ VGASnoop- ParErr- Stepping- SERR+ FastB2B-
	Status: Cap+ 66Mhz+ UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
	Latency: 64
	Bus: primary=00, secondary=03, subordinate=03, sec-latency=64
	I/O behind bridge: 0000f000-00000fff
	Memory behind bridge: fea00000-feafffff
	Prefetchable memory behind bridge: 00000000fff00000-0000000000000000
	Secondary status: 66Mhz+ FastB2B- ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort+ <SERR- <PERR-
	BridgeCtl: Parity+ SERR+ NoISA+ VGA- MAbort- >Reset- FastB2B-
	Capabilities: [a0] PCI-X bridge device.
		Secondary Status: 64bit+, 133MHz+, SCD-, USC-, SCO-, SRD- Freq=3
		Status: Bus=0 Dev=9 Func=0 64bit+ 133MHz+ SCD- USC-, SCO-, SRD-
		: Upstream: Capacity=14, Commitment Limit=65535
		: Downstream: Capacity=2, Commitment Limit=65535
	Capabilities: [b8] HyperTransport: Interrupt Discovery and Configuration

00:09.1 PIC: Advanced Micro Devices [AMD] AMD-8131 PCI-X APIC (rev 01) (prog-if 10 [IO-APIC])
	Subsystem: Advanced Micro Devices [AMD] AMD-8131 PCI-X APIC
	Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
	Status: Cap- 66Mhz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
	Latency: 0
	Region 0: Memory at febfe000 (64-bit, non-prefetchable) [size=4K]

00:18.0 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] HyperTransport Technology Configuration
	Control: I/O- Mem- BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
	Status: Cap+ 66Mhz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR-
	Capabilities: [80] HyperTransport: Host or Secondary Interface
	!!! Possibly incomplete decoding
		Command: WarmRst+ DblEnd-
		Link Control: CFlE- CST- CFE- <LkFail+ Init- EOC+ TXO+ <CRCErr=0
		Link Config: MLWI=16bit MLWO=16bit LWI=N/C LWO=N/C
		Revision ID: 1.02
	Capabilities: [a0] HyperTransport: Host or Secondary Interface
	!!! Possibly incomplete decoding
		Command: WarmRst+ DblEnd-
		Link Control: CFlE- CST- CFE- <LkFail- Init+ EOC- TXO- <CRCErr=0
		Link Config: MLWI=16bit MLWO=16bit LWI=8bit LWO=8bit
		Revision ID: 1.02
	Capabilities: [c0] HyperTransport: Host or Secondary Interface
	!!! Possibly incomplete decoding
		Command: WarmRst+ DblEnd-
		Link Control: CFlE- CST- CFE- <LkFail+ Init- EOC+ TXO+ <CRCErr=0
		Link Config: MLWI=16bit MLWO=16bit LWI=N/C LWO=N/C
		Revision ID: 1.02

00:18.1 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] Address Map
	Control: I/O- Mem- BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
	Status: Cap- 66Mhz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR-

00:18.2 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] DRAM Controller
	Control: I/O- Mem- BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
	Status: Cap- 66Mhz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR-

00:18.3 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] Miscellaneous Control
	Control: I/O- Mem- BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
	Status: Cap- 66Mhz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR-

01:00.0 USB Controller: Advanced Micro Devices [AMD] AMD-8111 USB (rev 0b) (prog-if 10 [OHCI])
	Subsystem: Advanced Micro Devices [AMD] AMD-8111 USB
	Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV+ VGASnoop- ParErr- Stepping- SERR+ FastB2B-
	Status: Cap- 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
	Latency: 64 (20000ns max)
	Interrupt: pin D routed to IRQ 11
	Region 0: Memory at fe9fd000 (32-bit, non-prefetchable) [size=4K]

01:00.1 USB Controller: Advanced Micro Devices [AMD] AMD-8111 USB (rev 0b) (prog-if 10 [OHCI])
	Subsystem: Advanced Micro Devices [AMD] AMD-8111 USB
	Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV+ VGASnoop- ParErr- Stepping- SERR+ FastB2B-
	Status: Cap- 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
	Latency: 64 (20000ns max)
	Interrupt: pin D routed to IRQ 11
	Region 0: Memory at fe9fe000 (32-bit, non-prefetchable) [size=4K]

01:02.0 VGA compatible controller: ATI Technologies Inc Rage XL (rev 27) (prog-if 00 [VGA])
	Subsystem: ATI Technologies Inc Rage XL
	Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping+ SERR- FastB2B-
	Status: Cap+ 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
	Latency: 64 (2000ns min), Cache Line Size 10
	Interrupt: pin A routed to IRQ 10
	Region 0: Memory at fd000000 (32-bit, non-prefetchable) [size=16M]
	Region 1: I/O ports at b000 [size=256]
	Region 2: Memory at fe9ff000 (32-bit, non-prefetchable) [size=4K]
	Expansion ROM at fe9c0000 [disabled] [size=128K]
	Capabilities: [5c] Power Management version 2
		Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-)
		Status: D0 PME-Enable- DSel=0 DScale=0 PME-

01:04.0 Ethernet controller: Intel Corp. 82557/8/9 [Ethernet Pro 100] (rev 10)
	Subsystem: Intel Corp.: Unknown device 0070
	Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV+ VGASnoop- ParErr- Stepping- SERR+ FastB2B-
	Status: Cap+ 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
	Latency: 64 (2000ns min, 14000ns max), Cache Line Size 10
	Interrupt: pin A routed to IRQ 9
	Region 0: Memory at fe9fc000 (32-bit, non-prefetchable) [size=4K]
	Region 1: I/O ports at bc00 [size=64]
	Region 2: Memory at fe9a0000 (32-bit, non-prefetchable) [size=128K]
	Expansion ROM at fe9e0000 [disabled] [size=64K]
	Capabilities: [dc] Power Management version 2
		Flags: PMEClk- DSI+ D1+ D2+ AuxCurrent=0mA PME(D0+,D1+,D2+,D3hot+,D3cold+)
		Status: D0 PME-Enable+ DSel=0 DScale=2 PME-

03:04.0 Ethernet controller: Broadcom Corporation NetXtreme BCM5704S Gigabit Ethernet (rev 03)
	Subsystem: Broadcom Corporation NetXtreme BCM5704S Gigabit Ethernet
	Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR+ FastB2B-
	Status: Cap+ 66Mhz+ UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
	Latency: 64 (16000ns min), Cache Line Size 10
	Interrupt: pin A routed to IRQ 9
	Region 0: Memory at fead0000 (64-bit, non-prefetchable) [size=64K]
	Region 2: Memory at feac0000 (64-bit, non-prefetchable) [size=64K]
	Capabilities: [40] PCI-X non-bridge device.
		Command: DPERE- ERO+ RBC=0 OST=0
		Status: Bus=3 Dev=4 Func=0 64bit+ 133MHz+ SCD- USC-, DC=simple, DMMRBC=2, DMOST=0, DMCRS=1, RSCEM-
	Capabilities: [48] Power Management version 2
		Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot+,D3cold+)
		Status: D0 PME-Enable- DSel=0 DScale=1 PME-
	Capabilities: [50] Vital Product Data
	Capabilities: [58] Message Signalled Interrupts: 64bit+ Queue=0/3 Enable-
		Address: dfa422e80ca5c568  Data: 3204

03:04.1 Ethernet controller: Broadcom Corporation NetXtreme BCM5704S Gigabit Ethernet (rev 03)
	Subsystem: Broadcom Corporation NetXtreme BCM5704S Gigabit Ethernet
	Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR+ FastB2B-
	Status: Cap+ 66Mhz+ UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
	Latency: 64 (16000ns min), Cache Line Size 10
	Interrupt: pin B routed to IRQ 5
	Region 0: Memory at feaf0000 (64-bit, non-prefetchable) [size=64K]
	Region 2: Memory at feae0000 (64-bit, non-prefetchable) [size=64K]
	Capabilities: [40] PCI-X non-bridge device.
		Command: DPERE- ERO+ RBC=0 OST=0
		Status: Bus=3 Dev=4 Func=1 64bit+ 133MHz+ SCD- USC-, DC=simple, DMMRBC=2, DMOST=0, DMCRS=1, RSCEM-
	Capabilities: [48] Power Management version 2
		Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot+,D3cold+)
		Status: D0 PME-Enable- DSel=0 DScale=1 PME-
	Capabilities: [50] Vital Product Data
	Capabilities: [58] Message Signalled Interrupts: 64bit+ Queue=0/3 Enable-
		Address: 67b8a6dfdfacc548  Data: 77bf









-------------- next part --------------
LinuxBIOS-1.1.8_s2880_Fallback Wed May 10 17:57:29 CST 2006 starting...

00  cache_as_ram_auto.c 

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

0000c1bc <-00ffff00

0000c180 <-00000000

0000c188 <-00000000

0000c190 <-00000000

0000c198 <-00000000

0000c1a0 <-00000000

0000c1a8 <-00000000

0000c1b0 <-00000000

0000c1b8 <-00fc0003

0000c1c4 <-01fff000

0000c1cc <-00000000

0000c1d4 <-

From stepan at coresystems.de  Thu May 11 12:48:14 2006
From: stepan at coresystems.de (Stefan Reinauer)
Date: Thu, 11 May 2006 12:48:14 +0200
Subject: [LinuxBIOS] New guy in LinuxBios
In-Reply-To: <41fde3420605110230j7e40fb7es7de020d18e13a091@mail.gmail.com>
References: <41fde3420605102111t1759001cm44888d1be62be7b3@mail.gmail.com>
	<41fde3420605110230j7e40fb7es7de020d18e13a091@mail.gmail.com>
Message-ID: <20060511104814.GB9396@coresystems.de>

* Vincente Tsou <vincentetsou at nexcom.com.tw> [060511 11:30]:
> My target board is an AMD Opteron (chipset: K8 / 8111 / 8131) mainboard,
> it is similar to Tyan s2880 / s2881 / s2882.
>  
> So I base on Tyan s2880 to change some config file to compile a linuxbios.rom,
> but it doesn't work.
>  
> Following is what do I changed in s2880:
> 3. generated irq_tables.c by getpir.c and replaced the original one.
 
getpir doesnt work for opteron boards. you should change an existing one
 
> compile and burn it in rom.
>  
> After I boot up the target board, it always alert emergency beep.
 
Some onboard watchdog? this one should probably be disabled until it is
set up correctly.
 
> Then, I unmark some debug message in 'src/northbridge/amd/amdk8/raminit.c' to
> see where is it hang.
> The last step is hang on setup_default_resource_map() in 'src/mainboard/tyan/
> s2880/cache_as_ram_auto.c',

You need to change the board target to use your own resourcemap.c file. 
The southbridge is probably not connected to Link0 of CPU0.

i.e. 
-       PCI_ADDR(0, 0x18, 1, 0xBC), 0x00000048, 0x00ffff00,
+       PCI_ADDR(0, 0x18, 1, 0xBC), 0x00000048, 0x00ffff10, // Link 1 CPU 0

-       PCI_ADDR(0, 0x18, 1, 0xC4), 0xFE000FC8, 0x01fff000,
+       PCI_ADDR(0, 0x18, 1, 0xC4), 0xFE000FC8, 0x01fff010, // CPU0 LDT1


> I can see it from serial console ( as attachment again. )

See mainboard/agami/aruma/resourcemap.c for an example

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 myneil at gmail.com  Thu May 11 15:09:39 2006
From: myneil at gmail.com (Neil)
Date: Thu, 11 May 2006 21:09:39 +0800
Subject: [LinuxBIOS] show config.lb error
Message-ID: <5c5dcf370605110609h59c3931cx9853a562d87885eb@mail.gmail.com>

Dear all:

My MB has two cpu (AMD opteron) , chipset is broadcom bcm5780 and bcm5785
,after I flash my linuxbios ,It hang ,and from minicom ,
we can see the error below(attchment is the whole log ):

PCI: 00:0a.0 [1166/0130] enabled
PCI: 00:0b.0 [1166/0130] enabled
PCI: 00:0c.0 [1166/0132] enabled
PCI: 00:0d.0 [1166/0132] enabled
PCI: 00:0e.0 [1166/0132] enabled
PCI: 00:0f.0 [1166/0132] enabled
PCI: 00: 0a.0
PCI: Left over static devices.  Check your Config.lb <http://config.lb/>

could anyone tell me what is the problem? Thank you very much!
Neil
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20060511/d85a4cbc/attachment.html>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: debugcode.txt
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20060511/d85a4cbc/attachment.txt>

From chris at suehsi.de  Thu May 11 14:51:38 2006
From: chris at suehsi.de (=?ISO-8859-1?Q?Christian_S=FChs?=)
Date: Thu, 11 May 2006 14:51:38 +0200
Subject: [LinuxBIOS] MB1030 / 3036 VGA resume
In-Reply-To: <4462E519.90101@suehsi.de>
References: <44579320.90206@suehsi.de>		<8a0c36780605090732k52415350w523df8dfbf95c547@mail.gmail.com>		<4424C30E.8010901@suehsi.de>
	<4460CCC0.3000706@suehsi.de>		<8a0c36780605091204l1a72e4b8lc377169b0473a510@mail.gmail.com>		<4460FDB5.5080606@suehsi.de>		<8a0c36780605091955s6fe971eap8369ed9ff8532fb1@mail.gmail.com>		<4461A546.3060504@suehsi.de>		<8a0c36780605100418o1eced8cdr6642561e93ad3aa0@mail.gmail.com>		<44621D0E.70205@suehsi.de>	<8a0c36780605101253p5542bf6dpcd9c711e563f8020@mail.gmail.com>
	<4462E519.90101@suehsi.de>
Message-ID: <4463335A.3080308@suehsi.de>


> The perfect sulotion seems to be enabling the L1 cache in the early 
> state of LB.
> 
> 9s for vga is not fast, but I think we would find the reason for that.
> if there is any.
> 


Ok, There are a few questions for me exspecially for the cr0 register.

as I say default is 60000010h

for that default the CPU is in real Mode. If I understand that right, it 
is a 16bit machine ?!

More, in the Config.lb under the motherboard folder is following line in 
the Setup RAM Section.

mainboardint cpu/x86/fpu/enable_fpu.inc

that file does something on register cr0, but for the GX1 in cr0 is 
nothing about fpu?!

question:

what do this line

andl $~(1<<2), %eax /* found in enable_fpu.inc */

can anybody explain this in easy words ;)
which bits are set in that case.

chris




From stepan at coresystems.de  Thu May 11 15:51:54 2006
From: stepan at coresystems.de (Stefan Reinauer)
Date: Thu, 11 May 2006 15:51:54 +0200
Subject: [LinuxBIOS] MB1030 / 3036 VGA resume
In-Reply-To: <4463335A.3080308@suehsi.de>
References: <4460CCC0.3000706@suehsi.de>
	<8a0c36780605091204l1a72e4b8lc377169b0473a510@mail.gmail.com>
	<4460FDB5.5080606@suehsi.de>
	<8a0c36780605091955s6fe971eap8369ed9ff8532fb1@mail.gmail.com>
	<4461A546.3060504@suehsi.de>
	<8a0c36780605100418o1eced8cdr6642561e93ad3aa0@mail.gmail.com>
	<44621D0E.70205@suehsi.de>
	<8a0c36780605101253p5542bf6dpcd9c711e563f8020@mail.gmail.com>
	<4462E519.90101@suehsi.de> <4463335A.3080308@suehsi.de>
Message-ID: <20060511135154.GA14964@coresystems.de>

* Christian S?hs <chris at suehsi.de> [060511 14:51]:
> Ok, There are a few questions for me exspecially for the cr0 register.
> 
> as I say default is 60000010h
> 
> for that default the CPU is in real Mode. If I understand that right, it 
> is a 16bit machine ?!
 
yes, the x86 architecture is a drilled 16bit architecture with 32bit and
nowadays 64bit plugged on top. When the CPU is powered on, it still
comes up in 16bit mode.

One of the many delicacies of LinuxBIOS is that it enters protected mode
(32bit mode) after only 17(!) CPU instructions. 

> mainboardint cpu/x86/fpu/enable_fpu.inc
 
This enables the FPU so the romcc generated code can use the FPU
registers for spilling.

> that file does something on register cr0, but for the GX1 in cr0 is 
> nothing about fpu?!

I would assume it is there anyways, or the FPU is always enabled for the
GX1?

> andl $~(1<<2), %eax /* found in enable_fpu.inc */
 
this clears bit 1.

 1<<2 is the value with only bit 2 set. The decimal value is 4

 $~(x) inverts the value of x, so the result is a value with all
 bits set except bit 2.

 the and operator sets all bits in eax that are
   - already set in eax
   - set in the value you provide
 so since only 1 bit is cleared in the value, the expression clears that
 one bit in eax.

> can anybody explain this in easy words ;)
> which bits are set in that case.

in easy words: none. bit 2 is cleared though. 

To set bits you would OR/ORL them into a value. Rather simple bitwise
arithmetics.

  set bit 5:

   orl $(1<<5), %eax

NOTE: bits are counted from 0 here. So bit 2 is the third least
significant bit.

Hoe this helps..

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 chris at suehsi.de  Thu May 11 15:33:42 2006
From: chris at suehsi.de (=?UTF-8?B?Q2hyaXN0aWFuIFPDvGhz?=)
Date: Thu, 11 May 2006 15:33:42 +0200
Subject: [LinuxBIOS] MB1030 / 3036 VGA resume
In-Reply-To: <20060511135154.GA14964@coresystems.de>
References: <4460CCC0.3000706@suehsi.de>
	<8a0c36780605091204l1a72e4b8lc377169b0473a510@mail.gmail.com>
	<4460FDB5.5080606@suehsi.de>
	<8a0c36780605091955s6fe971eap8369ed9ff8532fb1@mail.gmail.com>
	<4461A546.3060504@suehsi.de>
	<8a0c36780605100418o1eced8cdr6642561e93ad3aa0@mail.gmail.com>
	<44621D0E.70205@suehsi.de>
	<8a0c36780605101253p5542bf6dpcd9c711e563f8020@mail.gmail.com>
	<4462E519.90101@suehsi.de> <4463335A.3080308@suehsi.de>
	<20060511135154.GA14964@coresystems.de>
Message-ID: <44633D36.5080009@suehsi.de>


> One of the many delicacies of LinuxBIOS is that it enters protected mode
> (32bit mode) after only 17(!) CPU instructions. 

Ok, were is it done in LB
is entering protected mode a standard procedur of LB.

I.e. the GX1 have to set bit 0 on CR0 to 1

> 
>
>>that file does something on register cr0, but for the GX1 in cr0 is 
>>nothing about fpu?!
> 
> 
> I would assume it is there anyways, or the FPU is always enabled for the
> GX1?
> 

Maybe, I have to read the datasheet for FPU

> 
>>can anybody explain this in easy words ;)
>>which bits are set in that case.
> 
> 
> in easy words: none. bit 2 is cleared though. 

Thanks for the leson ;)

Ok, for the GX1 the EM is set to 0; Emulate Processor Extension, if EM = 
1 all flaoting point instructions causes a DNA fault 7

Seems that the FPU is always enabled.

chris


> Stefan
> 




From chris at suehsi.de  Thu May 11 15:54:45 2006
From: chris at suehsi.de (=?ISO-8859-1?Q?Christian_S=FChs?=)
Date: Thu, 11 May 2006 15:54:45 +0200
Subject: [LinuxBIOS] MB1030 / 3036 VGA resume
In-Reply-To: <44633D36.5080009@suehsi.de>
References: <4460CCC0.3000706@suehsi.de>	<8a0c36780605091204l1a72e4b8lc377169b0473a510@mail.gmail.com>	<4460FDB5.5080606@suehsi.de>	<8a0c36780605091955s6fe971eap8369ed9ff8532fb1@mail.gmail.com>	<4461A546.3060504@suehsi.de>	<8a0c36780605100418o1eced8cdr6642561e93ad3aa0@mail.gmail.com>	<44621D0E.70205@suehsi.de>	<8a0c36780605101253p5542bf6dpcd9c711e563f8020@mail.gmail.com>	<4462E519.90101@suehsi.de>
	<4463335A.3080308@suehsi.de>	<20060511135154.GA14964@coresystems.de>
	<44633D36.5080009@suehsi.de>
Message-ID: <44634225.1000709@suehsi.de>

Christian S?hs schrieb:
>>One of the many delicacies of LinuxBIOS is that it enters protected mode
>>(32bit mode) after only 17(!) CPU instructions. 
> 
> 
> Ok, were is it done in LB
> is entering protected mode a standard procedur of LB.
> 
> I.e. the GX1 have to set bit 0 on CR0 to 1

Oh, I have found that stuff :D
And I'm confused now.

It seems, I have to write my own entry16.inc code for the gx1.
The default entry16.inc should enable the cache for example, but there 
are written false values to the cr0 register.



>>
>>in easy words: none. bit 2 is cleared though. 
> 
> 
> Thanks for the leson ;)
> 
> Ok, for the GX1 the EM is set to 0; Emulate Processor Extension, if EM = 
> 1 all flaoting point instructions causes a DNA fault 7
> 

This is done twice for the gx1.
First in entry16.inc
Later with enable_fpu.inc

Is it posible to remove the line from the Config.lb for the fpu?

chris




From stepan at coresystems.de  Thu May 11 16:37:41 2006
From: stepan at coresystems.de (Stefan Reinauer)
Date: Thu, 11 May 2006 16:37:41 +0200
Subject: [LinuxBIOS] MB1030 / 3036 VGA resume
In-Reply-To: <44633D36.5080009@suehsi.de>
References: <4460FDB5.5080606@suehsi.de>
	<8a0c36780605091955s6fe971eap8369ed9ff8532fb1@mail.gmail.com>
	<4461A546.3060504@suehsi.de>
	<8a0c36780605100418o1eced8cdr6642561e93ad3aa0@mail.gmail.com>
	<44621D0E.70205@suehsi.de>
	<8a0c36780605101253p5542bf6dpcd9c711e563f8020@mail.gmail.com>
	<4462E519.90101@suehsi.de> <4463335A.3080308@suehsi.de>
	<20060511135154.GA14964@coresystems.de>
	<44633D36.5080009@suehsi.de>
Message-ID: <20060511143741.GA17028@coresystems.de>

* Christian S?hs <chris at suehsi.de> [060511 15:33]:
> 
> > One of the many delicacies of LinuxBIOS is that it enters protected mode
> > (32bit mode) after only 17(!) CPU instructions. 
> 
> Ok, were is it done in LB
> is entering protected mode a standard procedur of LB.
 
Yes, this is a standard procedure on all x86 CPUs

I wrote the attached document quite a long time ago. Its not all current
but it might help to understand the concept

> > I would assume it is there anyways, or the FPU is always enabled for the
> > GX1?
> 
> Maybe, I have to read the datasheet for FPU
 
I would not care any further. This part works...

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 --------------
Ok, 

I think I got it now, except some minor things. I would like to add this
explanation to my LinuxBIOS document. Please help me advance it with
some expert comments, since I feel rather like a novice in this part of
the code. Has there been anyone describing this in detail, while
still being understandable? I remember seeing something a long time ago
for v1, but I couldnt find it in the archives anymore.

It seems that my current approach, leaving everything up to failover.c
untouched, might not be the best way to go. From early_mtrr.inc on we
have XIP acceleration available, thus it seems that we hook in after
this point, and do everything afterwards in gcc, creating an extra hunk
with an extra .lds file to pack it all into. 


reset16.[inc|lds]
-----------------
 Description:
  * code placed at reset vector (0xfffffff0)
  * jump to _start in entry16.inc
  * jump to protected_start in entry32.inc (what is this good for??)

 Comments:
  reset16.lds supports ROMBASEs smaller than 0xffff0000. reset16.inc does
  not. Do we ever need anything else on x86 based systems? If not, I
  suggest to drop the conditionals.
  It seems to me that the second jump is later done by entry16.inc, and
  the reset vector is never reached. Is it used by something else?

entry16.[inc|lds]
-----------------
 Description:
  * linker script provides 16bit versions of the addresses (?)
  * switch to protected mode.
  * jump to __protected_start in entry32.inc
 
 Comments:
  Can someone enlighten me on the restriction comments here? given that 
  we are always on a standard x86 system, we are always above
  0xffff0000?

entry32.[inc|lds]
-----------------
 Description:
  * linker script is a noop.
  * sets up all segment registers to the same value. (ROM_CODE_SEG)
  * falls through to bist32.inc

 Comments:
  there's two entry points here, protected_start and __protected_start.
  Are they both needed? protected_start seems to do the same thing as
  the end of entry16.inc.
  The comment states that we do something with memory here. It seems
  this is wrong, since we are far before enabling memory.

bist32.inc
----------
 Description:
  * Checks EAX for BIST failures.
  * if everything is ok, falls through (skipping next 
    files that put code in different sections: reset16.inc,
    cpu_reset.inc, id.inc) On K8 this goes to early_mtrr.inc

early_mtrr.inc
--------------
 Description:
  * set up variable and fixed mtrrs.
  * set up XIP

 Comments:
  Will this hurt C-A-R? Can we somehow derive the XIP addresses from the
  information that we know, making XIP more solid?

failover.c
----------
 Description:
  * romcc generated code
  * if normal boot, we jump into normal image.
  * if cpu reset, we jump into __cpu_reset, which jumps into 
    __main (Where is this one? crt0.base? auto.inc?)
  * if we're running on the second CPU, we jump into normal/fallback
    image (???)
  * if no problems appeared, jump into normal image
  * otherwise fall through (to auto.c ??)

 Comments:
  What's HAVE_REGPARM_SUPPORT? There's a lot of conditions in this file.
  I did not follow all the branches yet. Maybe someone can explain more?
  it seems that __cpu_reset jumps into __main - does this mean the dram
  init survives a cpu reset?


> -------------- part 1: creating init code -----------------------------
>  1) compile romcc
>  2) create option table
>  3) process and compile romcc based code
>  4) create crt0.o from romcc based code
> 
> -------------- part 2: creating payload -------------------------------
>  5) compile all drivers
>  6) compile all objects
>  7) compile static device tree
>  8) link objects and static tree --> linuxbios.a
>  9) create linuxbios_c from start.o, drivers and linuxbios.a
>  a) create linuxbios_payload from linuxbios_c (with or w/o nrv2b)
> 
> -------------- part 3: final image ------------------------------------
>  b) create "linuxbios" from crt0.o (including linuxbios_payload via
>     linker script arch/i386/config/ldscript.lb)
>  c) create romimage linuxbios.rom from "linuxbios" with buildrom



From stepan at coresystems.de  Thu May 11 16:40:32 2006
From: stepan at coresystems.de (Stefan Reinauer)
Date: Thu, 11 May 2006 16:40:32 +0200
Subject: [LinuxBIOS] MB1030 / 3036 VGA resume
In-Reply-To: <44634225.1000709@suehsi.de>
References: <8a0c36780605091955s6fe971eap8369ed9ff8532fb1@mail.gmail.com>
	<4461A546.3060504@suehsi.de>
	<8a0c36780605100418o1eced8cdr6642561e93ad3aa0@mail.gmail.com>
	<44621D0E.70205@suehsi.de>
	<8a0c36780605101253p5542bf6dpcd9c711e563f8020@mail.gmail.com>
	<4462E519.90101@suehsi.de> <4463335A.3080308@suehsi.de>
	<20060511135154.GA14964@coresystems.de>
	<44633D36.5080009@suehsi.de> <44634225.1000709@suehsi.de>
Message-ID: <20060511144032.GA17661@coresystems.de>

* Christian S?hs <chris at suehsi.de> [060511 15:54]:
> It seems, I have to write my own entry16.inc code for the gx1.
> The default entry16.inc should enable the cache for example, but there 
> are written false values to the cr0 register.
 
no. very very unlikely. Just write the correct values in auto.c is
enough.
 
> >Ok, for the GX1 the EM is set to 0; Emulate Processor Extension, if EM = 
> >1 all flaoting point instructions causes a DNA fault 7
> 
> This is done twice for the gx1.
> First in entry16.inc
> Later with enable_fpu.inc
> 
> Is it posible to remove the line from the Config.lb for the fpu?

Possibly possible, if the gx1 does all that.. But this will not take
more than a couple cycles, so the difference in size and time is not
measurable without quite some effort.

-- 
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  Thu May 11 18:32:44 2006
From: yinghai.lu at amd.com (Lu, Yinghai)
Date: Thu, 11 May 2006 09:32:44 -0700
Subject: [LinuxBIOS] New guy in LinuxBios
Message-ID: <6F7DA19D05F3CF40B890C7CA2DB13A4203094C84@ssvlexmb2.amd.com>

Comment out several lines about links in resourcemap.c.

 

Current inherent_ht.c already could probe the links automatically...

 

amd/Serengeti_leopard is good model. If you want mptable and irqtable
and acpitable create automatically.

 

YH

 

________________________________

From: linuxbios-bounces at linuxbios.org
[mailto:linuxbios-bounces at linuxbios.org] On Behalf Of Vincente Tsou
Sent: Thursday, May 11, 2006 2:31 AM
To: linuxbios at linuxbios.org
Subject: [LinuxBIOS] New guy in LinuxBios

 

 

Hello LinuxBios elders,

 

I'm sorry to bother you.

 

I'm begining to study LinuxBios and I have some problem in it.

Hope you can give me some idea.

 

My target board is an AMD Opteron (chipset: K8 / 8111 / 8131) mainboard,

it is similar to Tyan s2880 / s2881 / s2882.

 

So I base on Tyan s2880 to change some config file to compile a
linuxbios.rom,

but it doesn't work.

 

Following is what do I changed in s2880:

1. I changed the payload path in targets/tyan/s2880/Config.lb.

2. modify src/mainboard/tyan/s2880/Config.lb as 42812-pci.txt. ( as
attachment )

    I don't know is it correct that I modified. If you have interest you
can refer to Attachment.

3. generated irq_tables.c by getpir.c and replaced the original one.

 

compile and burn it in rom.

 

After I boot up the target board, it always alert emergency beep.

 

Then, I unmark some debug message in
'src/northbridge/amd/amdk8/raminit.c' to see where is it hang.

The last step is hang on setup_default_resource_map() in
'src/mainboard/tyan/s2880/cache_as_ram_auto.c',

I can see it from serial console ( as attachment again. ) 

 

Is there any configuration I should change, and I didn't do ?

How can I debug it ?

 

Thanks a lot.

 



-- 
Best Regards,
Vincente Tsou

Engineer
R/D, S/W Dept.
NEXCOM International Co.
Tel: 886-2-82280606 Ext. 3205
Fax: 886-2-82280506
E-mail: vincentetsou at nexcom.com.tw
Web: http://www.nexcom.com.tw/ 

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

From eric at zyxod.com  Thu May 11 18:51:38 2006
From: eric at zyxod.com (Eric Poulsen)
Date: Thu, 11 May 2006 09:51:38 -0700
Subject: [LinuxBIOS] LB vs Factory BIOS -- more weirdness
In-Reply-To: <44622CE9.2020200@lanl.gov>
References: <445C4C04.6090302@zyxod.com> <44622CE9.2020200@lanl.gov>
Message-ID: <44636B9A.5000108@zyxod.com>

I have done this -- It doesn't cause the problem.  I had the machine off 
for two days with the PS unplugged (no aux power), and the power 
connected disconnected from the MLB.  Booted just fine after that.   I 
think whoever mentioned the CAS setting being too fast might be on the 
right track, but it's weird that the factory BIOS fixes it (for a while).


WRT DMA issue:

(I only booted using LB)

Also, last night, I _hammered_ the southbridge by copying 50M files on 
the HD, FTPing 50Meg files, and Copying 100M files from usb stick to 
HDA.  I ran this for several hours.  The CPU heatsink got pretty warm.  
No crashes.  Previously, just copying from HDA to HDC would crash it, or 
from USB >> HDA, regularly.

So I Power down, Reboot (LB again), restarted the HDA >> HDA copy and 
the FTP.  Froze up within 10 minutes.

I'll re-run the tests tonight using the factory BIOS -- who knows what's 
going to happen.



Ronald G Minnich wrote:
> Eric Poulsen wrote:
>
>>
>> I'm conviced this is the case -- I have too many weird issues that 
>> can be fixed by simply flipping back to the factory BIOS, turning the 
>> system on, getting a "bad CMOS" error, then immediately powering off 
>> and switching to LB, which suddenly works again.
>>
>
>
> You could try this: do the exact same test, but turn off the board, 
> *disconnect the power connector*, let it sit 30 seconds, and then put 
> in LB and see if it works or not.
>
> I'd be interested to hear this result.
>
> ron
>




From stepan at coresystems.de  Thu May 11 19:01:05 2006
From: stepan at coresystems.de (Stefan Reinauer)
Date: Thu, 11 May 2006 19:01:05 +0200
Subject: [LinuxBIOS] New guy in LinuxBios
In-Reply-To: <6F7DA19D05F3CF40B890C7CA2DB13A4203094C84@ssvlexmb2.amd.com>
References: <6F7DA19D05F3CF40B890C7CA2DB13A4203094C84@ssvlexmb2.amd.com>
Message-ID: <20060511170105.GA22768@coresystems.de>

* Lu, Yinghai <yinghai.lu at amd.com> [060511 18:32]:
> Comment out several lines about links in resourcemap.c.

Can we just comment this out? Or would we need to put the link number in
the registers before writing?

-- 
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  Thu May 11 19:11:08 2006
From: yinghai.lu at amd.com (Lu, Yinghai)
Date: Thu, 11 May 2006 10:11:08 -0700
Subject: [LinuxBIOS] New guy in LinuxBios
Message-ID: <6F7DA19D05F3CF40B890C7CA2DB13A4203094C87@ssvlexmb2.amd.com>

No. It seems there is one MB need to set..., I forget the model...

But amd chipset base MB should be ok to comment that out...

YH

-----Original Message-----
From: Stefan Reinauer [mailto:stepan at coresystems.de] 
Sent: Thursday, May 11, 2006 10:01 AM
To: Lu, Yinghai
Cc: vincentetsou at nexcom.com.tw; linuxbios at linuxbios.org
Subject: Re: [LinuxBIOS] New guy in LinuxBios

* Lu, Yinghai <yinghai.lu at amd.com> [060511 18:32]:
> Comment out several lines about links in resourcemap.c.

Can we just comment this out? Or would we need to put the link number in
the registers before writing?

-- 
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 stepan at coresystems.de  Thu May 11 19:53:53 2006
From: stepan at coresystems.de (Stefan Reinauer)
Date: Thu, 11 May 2006 19:53:53 +0200
Subject: [LinuxBIOS] SMM is evil?
Message-ID: <20060511175353.GA24554@coresystems.de>

Hi,

Lo?c Duflot, security engineer and researcher for the scientific
division of the french Central Directorate for Information Systems
Security ("french version of the NSA"), gives some insight on fun that
can be had with the system management mode (SMM) of x86 CPUs.

See http://www.securityfocus.com/print/columnists/402 for more
information.

While, as Lo?c writes later in his article, the whole issue of
exploiting SMM is pretty pointless in Linux as the super user can
conquer ring 0 without further effort, the idea of fixing what we
can fix on the bios level seems worthwhile.

If something seems as simple as setting the D_LCK bit of SMM, we should
definitely do it.. It will at least be a marketable feature against
other upcoming firmware implementations.

Comments?

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 c-d.hailfinger.devel.2006 at gmx.net  Thu May 11 22:06:24 2006
From: c-d.hailfinger.devel.2006 at gmx.net (Carl-Daniel Hailfinger)
Date: Thu, 11 May 2006 22:06:24 +0200
Subject: [LinuxBIOS] SMM is evil?
In-Reply-To: <20060511175353.GA24554@coresystems.de>
References: <20060511175353.GA24554@coresystems.de>
Message-ID: <44639940.5080604@gmx.net>

Hi,

Stefan Reinauer wrote:
> 
> If something seems as simple as setting the D_LCK bit of SMM, we should
> definitely do it.. It will at least be a marketable feature against
> other upcoming firmware implementations.

I believe that setting D_LCK will mitigate a few attacks but I strongly
doubt that it cannot be cleared during system operation. Yes, the manual
specifies it, but manuals have been underspecified before. Since we don't
use SMM for anything, we might as well
* clear D_OPEN
* set D_CLOSE
* clear "Enable"
* set D_LCK.

So, by all means, do it now. Until somebody figures out a way to disable
D_LCK again we offer a much higher degree of security than everybody
else.

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



From ward at gnu.org  Thu May 11 22:45:10 2006
From: ward at gnu.org (Ward Vandewege)
Date: Thu, 11 May 2006 16:45:10 -0400
Subject: [LinuxBIOS] s2881 fan control
In-Reply-To: <20060509190507.GB8910@localdomain>
References: <6F7DA19D05F3CF40B890C7CA2DB13A4203094BD5@ssvlexmb2.amd.com>
	<20060505205717.GA20174@localdomain>
	<20060505211923.GA22205@localdomain>
	<20060506122521.GA9586@coresystems.de>
	<20060509190507.GB8910@localdomain>
Message-ID: <20060511204457.GA24351@localdomain>

On Tue, May 09, 2006 at 03:05:07PM -0400, Ward Vandewege wrote:
... lspci output ...
> But there are actually quite a few other differences throughout the file,
> which surprises me a litte. Lots of differences in the various northbridge
> entries, and even the network cards and the sata controller. Is this normal?

A followup on this. First of all, I didn't realize that the PCI configuration
space is dynamic - things change all the time.

Secondly; 

>  0000:01:04.3 Bridge: Advanced Micro Devices [AMD] AMD-8111 ACPI (rev 05)
... snip ...
> -f0: 19 5f 3b 00 00 00 00 00 00 00 00 00 00 00 00 00
> +f0: c3 ad 1e 00 00 00 00 00 00 00 00 00 00 00 00 00

As it turns out, those three bytes change constantly, so I guess they are not
significant.

Also, I missed one byte that IS consistently different after a boot with the
proprietary BIOS:

0000:01:04.3 Bridge: Advanced Micro Devices [AMD] AMD-8111 ACPI (rev 05)
...
-40: 80 f1 00 04 00 00 00 00 20 14 50 00 00 00 00 00
+40: 80 f1 00 07 00 00 00 00 20 14 50 00 00 00 00 00

How would I go about changing that byte during the LinuxBIOS boot? Do I need
to edit resourcemap.c in src/mainboard/tyan/s2881?

Thanks,
Ward.

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



From yinghai.lu at amd.com  Thu May 11 22:49:07 2006
From: yinghai.lu at amd.com (Lu, Yinghai)
Date: Thu, 11 May 2006 13:49:07 -0700
Subject: [LinuxBIOS] s2881 fan control
Message-ID: <6F7DA19D05F3CF40B890C7CA2DB13A4203094C89@ssvlexmb2.amd.com>

init() in amd8111_acpi.c

YH

-----Original Message-----
From: Ward Vandewege [mailto:ward at gnu.org] 
Sent: Thursday, May 11, 2006 1:45 PM
To: Stefan Reinauer
Cc: linuxbios at linuxbios.org; Lu, Yinghai
Subject: Re: [LinuxBIOS] s2881 fan control

On Tue, May 09, 2006 at 03:05:07PM -0400, Ward Vandewege wrote:
... lspci output ...
> But there are actually quite a few other differences throughout the
file,
> which surprises me a litte. Lots of differences in the various
northbridge
> entries, and even the network cards and the sata controller. Is this
normal?

A followup on this. First of all, I didn't realize that the PCI
configuration
space is dynamic - things change all the time.

Secondly; 

>  0000:01:04.3 Bridge: Advanced Micro Devices [AMD] AMD-8111 ACPI (rev
05)
... snip ...
> -f0: 19 5f 3b 00 00 00 00 00 00 00 00 00 00 00 00 00
> +f0: c3 ad 1e 00 00 00 00 00 00 00 00 00 00 00 00 00

As it turns out, those three bytes change constantly, so I guess they
are not
significant.

Also, I missed one byte that IS consistently different after a boot with
the
proprietary BIOS:

0000:01:04.3 Bridge: Advanced Micro Devices [AMD] AMD-8111 ACPI (rev 05)
...
-40: 80 f1 00 04 00 00 00 00 20 14 50 00 00 00 00 00
+40: 80 f1 00 07 00 00 00 00 20 14 50 00 00 00 00 00

How would I go about changing that byte during the LinuxBIOS boot? Do I
need
to edit resourcemap.c in src/mainboard/tyan/s2881?

Thanks,
Ward.

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





From stepan at coresystems.de  Thu May 11 22:51:41 2006
From: stepan at coresystems.de (Stefan Reinauer)
Date: Thu, 11 May 2006 22:51:41 +0200
Subject: [LinuxBIOS] SMM is evil?
In-Reply-To: <44639940.5080604@gmx.net>
References: <20060511175353.GA24554@coresystems.de> <44639940.5080604@gmx.net>
Message-ID: <20060511205141.GA29824@coresystems.de>



* Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006 at gmx.net> [060511 22:06]:
> Stefan Reinauer wrote:
> > 
> > If something seems as simple as setting the D_LCK bit of SMM, we should
> > definitely do it.. It will at least be a marketable feature against
> > other upcoming firmware implementations.
> 
> I believe that setting D_LCK will mitigate a few attacks but I strongly
> doubt that it cannot be cleared during system operation. Yes, the manual
> specifies it, but manuals have been underspecified before. Since we don't
> use SMM for anything, we might as well

While the mechanism might indeed provide some protection its maybe
possible to assert a reset signal to the chipset while not dropping out
of the code path, as a possible workaround. No idea whether this is
possible without "bios support" though.

> So, by all means, do it now. Until somebody figures out a way to disable
> D_LCK again we offer a much higher degree of security than everybody
> else.

Ok, D_LCK/D_OPEN/D_CLOSE is intel vocabulary. There is no such thing on
AMD. They call it SMMLOCK in their BKDG:

6.11.6 Locking SMM

The SMM registers can be locked by setting the SMMLOCK (HWCR, bit 0).
Once set, the SMM_BASE, the SMM_ADDR, all but the two close bits of
SMM_MASK and the RSMSPCYCDIS, SMISPCYCDIS, and SMMLOCK bits of HWCR are
locked and cannot be changed. The only way to unlock the SMM registers
is to assert reset.  This provides security to the SMM mechanism. The
BIOS can lock the SMM environment after setting it up so that it can not
be tampered with.

So I propose the following patch for LinuxBIOS to fix the SMM problem
for all supported AMD K8 mainboards:

Index: src/cpu/amd/model_fxx/model_fxx_init.c
===================================================================
--- src/cpu/amd/model_fxx/model_fxx_init.c      (revision 2302)
+++ src/cpu/amd/model_fxx/model_fxx_init.c      (working copy)
@@ -454,6 +454,12 @@

        k8_errata();

+       /* Set SMMLOCK to avoid exploits messing with SMM */
+       msr = rdmsr(HWCR_MSR);
+       msr.lo |= (1 << 0);
+       wrmsr(HWCR_MSR, msr);
+
+
        enable_cache();

        /* Enable the local cpu apics */





Anyone opposing?

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 stepan at coresystems.de  Thu May 11 22:59:56 2006
From: stepan at coresystems.de (Stefan Reinauer)
Date: Thu, 11 May 2006 22:59:56 +0200
Subject: [LinuxBIOS] s2881 fan control
In-Reply-To: <20060511204457.GA24351@localdomain>
References: <6F7DA19D05F3CF40B890C7CA2DB13A4203094BD5@ssvlexmb2.amd.com>
	<20060505205717.GA20174@localdomain>
	<20060505211923.GA22205@localdomain>
	<20060506122521.GA9586@coresystems.de>
	<20060509190507.GB8910@localdomain>
	<20060511204457.GA24351@localdomain>
Message-ID: <20060511205956.GA30588@coresystems.de>

* Ward Vandewege <ward at gnu.org> [060511 22:45]:
> On Tue, May 09, 2006 at 03:05:07PM -0400, Ward Vandewege wrote:
> ... lspci output ...
> > But there are actually quite a few other differences throughout the file,
> > which surprises me a litte. Lots of differences in the various northbridge
> > entries, and even the network cards and the sata controller. Is this normal?
> 
> A followup on this. First of all, I didn't realize that the PCI configuration
> space is dynamic - things change all the time.

Its probably some timer that counts there. This kind of thing almost
requires having the datasheet sitting in another window or printed out
next to you.

> Also, I missed one byte that IS consistently different after a boot with the
> proprietary BIOS:
> 
> 0000:01:04.3 Bridge: Advanced Micro Devices [AMD] AMD-8111 ACPI (rev 05)
> ...
> -40: 80 f1 00 04 00 00 00 00 20 14 50 00 00 00 00 00
> +40: 80 f1 00 07 00 00 00 00 20 14 50 00 00 00 00 00

Try the attached patch


-- 
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 2302)
+++ src/southbridge/amd/amd8111/amd8111_acpi.c	(working copy)
@@ -119,6 +119,10 @@
 	if (!on) {
 		byte |= 0x40;
 	}
+
+	/* Does this fix the fans? */
+	byte |= ( (1<<0) | (1<<1);
+	
 	pci_write_config8(dev, PREVIOUS_POWER_STATE, byte);
 	printk_info("set power %s after power fail\n", on?"on":"off");
 

From ward at gnu.org  Thu May 11 23:50:15 2006
From: ward at gnu.org (Ward Vandewege)
Date: Thu, 11 May 2006 17:50:15 -0400
Subject: [LinuxBIOS] s2881 fan control
In-Reply-To: <20060511205956.GA30588@coresystems.de>
References: <6F7DA19D05F3CF40B890C7CA2DB13A4203094BD5@ssvlexmb2.amd.com>
	<20060505205717.GA20174@localdomain>
	<20060505211923.GA22205@localdomain>
	<20060506122521.GA9586@coresystems.de>
	<20060509190507.GB8910@localdomain>
	<20060511204457.GA24351@localdomain>
	<20060511205956.GA30588@coresystems.de>
Message-ID: <20060511215015.GA26395@localdomain>

On Thu, May 11, 2006 at 10:59:56PM +0200, Stefan Reinauer wrote:
> Its probably some timer that counts there. This kind of thing almost
> requires having the datasheet sitting in another window or printed out
> next to you.

Right.

> > Also, I missed one byte that IS consistently different after a boot with the
> > proprietary BIOS:
> > 
> > 0000:01:04.3 Bridge: Advanced Micro Devices [AMD] AMD-8111 ACPI (rev 05)
> > ...
> > -40: 80 f1 00 04 00 00 00 00 20 14 50 00 00 00 00 00
> > +40: 80 f1 00 07 00 00 00 00 20 14 50 00 00 00 00 00
> 
> Try the attached patch

That didn't help. 0x43 was still set to 04, and I could not set the fan
speed. There was a bracket missing from the patch, btw.

Suggestions?
Ward.

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



From stepan at coresystems.de  Fri May 12 00:11:43 2006
From: stepan at coresystems.de (Stefan Reinauer)
Date: Fri, 12 May 2006 00:11:43 +0200
Subject: [LinuxBIOS] etherboot/filo + sata startup timing
In-Reply-To: <20060506131149.GD20174@localdomain>
References: <20060424220147.GA26709@io.pong.be> <444D4AED.3020805@lanl.gov>
	<20060424222144.GA17934@coresystems.de>
	<20060424222501.GC27028@io.pong.be>
	<20060428231617.GA28043@coresystems.de>
	<20060501155545.GA3652@io.pong.be>
	<20060505134709.GA2422@coresystems.de>
	<20060505213830.GA23965@localdomain>
	<20060506123913.GA11451@coresystems.de>
	<20060506131149.GD20174@localdomain>
Message-ID: <20060511221143.GA2260@coresystems.de>

* Ward Vandewege <ward at gnu.org> [060506 15:11]:
> On Sat, May 06, 2006 at 02:39:13PM +0200, Stefan Reinauer wrote:
> > * Ward Vandewege <ward at gnu.org> [060505 23:38]:
> > > I've tried this; the boot log is attached (minicom-20060505.cap) with
> > > DEBUG_PCI, DEBUG_IDE and DEBUG_LINUXBIOS enabled. Didn't help.
> > > 
> > > >  * if that doesnt help: try whether the disk is detected as hda instead
> > > >    of hde. This might happen with the current code.
> > > 
> > > I've tried that too, the bootlog is also attached (minicom-20060505-2.cap).
> > > Still no luck; though here it does seem to find the IDE controller. But not
> > > the drive...
> > 
> > Aha! It shows a floating IDE bus... Does anyone have an idea what's
> > wrong exactly if this shows up? It might just be an issue of waiting
> > just a little bit longer..

Hm. can you set the timeout from 20ms to 200ms?

Does it work with the etherboot filo btw?

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 scott at waye.co.uk  Thu May 11 23:16:34 2006
From: scott at waye.co.uk (scott)
Date: Thu, 11 May 2006 22:16:34 +0100
Subject: [LinuxBIOS] 2 Beginner questions
Message-ID: <4463A9B2.2080507@waye.co.uk>

I'm a little confused about getting a console on a screen:

Do I need the VGA stuff in order to get just text output from the 
onboard video (EPIA MII) or is it only needed to do graphics?

What is a "uniq console" as activated by :

CONFIG_CONSOLE_BTEXT=1

?

Thanks,

--
Scott





From ward at gnu.org  Fri May 12 00:40:47 2006
From: ward at gnu.org (Ward Vandewege)
Date: Thu, 11 May 2006 18:40:47 -0400
Subject: [LinuxBIOS] etherboot/filo + sata startup timing
In-Reply-To: <20060511221143.GA2260@coresystems.de>
References: <444D4AED.3020805@lanl.gov> <20060424222144.GA17934@coresystems.de>
	<20060424222501.GC27028@io.pong.be>
	<20060428231617.GA28043@coresystems.de>
	<20060501155545.GA3652@io.pong.be>
	<20060505134709.GA2422@coresystems.de>
	<20060505213830.GA23965@localdomain>
	<20060506123913.GA11451@coresystems.de>
	<20060506131149.GD20174@localdomain>
	<20060511221143.GA2260@coresystems.de>
Message-ID: <20060511224047.GA27483@localdomain>

On Fri, May 12, 2006 at 12:11:43AM +0200, Stefan Reinauer wrote:
> * Ward Vandewege <ward at gnu.org> [060506 15:11]:
> > On Sat, May 06, 2006 at 02:39:13PM +0200, Stefan Reinauer wrote:
> > > * Ward Vandewege <ward at gnu.org> [060505 23:38]:
> > > > I've tried this; the boot log is attached (minicom-20060505.cap) with
> > > > DEBUG_PCI, DEBUG_IDE and DEBUG_LINUXBIOS enabled. Didn't help.
> > > > 
> > > > >  * if that doesnt help: try whether the disk is detected as hda instead
> > > > >    of hde. This might happen with the current code.
> > > > 
> > > > I've tried that too, the bootlog is also attached (minicom-20060505-2.cap).
> > > > Still no luck; though here it does seem to find the IDE controller. But not
> > > > the drive...
> > > 
> > > Aha! It shows a floating IDE bus... Does anyone have an idea what's
> > > wrong exactly if this shows up? It might just be an issue of waiting
> > > just a little bit longer..
> 
> Hm. can you set the timeout from 20ms to 200ms?

Do you mean this line

    timeout = currticks() + 20 * TICKS_PER_SEC / 1000;

in ide_bus_floating() in drivers/ide.c? 

> Does it work with the etherboot filo btw?

Yes; that's what I've been using. But it _only_ works if I guarantee at least
3 to 4 seconds of bootup delay; that's why I have the AUTOBOOT_DELAY set to
5. But that doesn't work for Filo 0.5 - maybe it tries to find the disks
before doing the AUTOBOOT_DELAY?

Ward.

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



From yinghai.lu at amd.com  Fri May 12 00:43:51 2006
From: yinghai.lu at amd.com (Lu, Yinghai)
Date: Thu, 11 May 2006 15:43:51 -0700
Subject: [LinuxBIOS] etherboot/filo + sata startup timing
Message-ID: <6F7DA19D05F3CF40B890C7CA2DB13A4203094C8C@ssvlexmb2.amd.com>

It seems TICKS_PER_SEC definition Etherboot is different from that in
FILO....


YH




From ward at gnu.org  Fri May 12 00:53:34 2006
From: ward at gnu.org (Ward Vandewege)
Date: Thu, 11 May 2006 18:53:34 -0400
Subject: [LinuxBIOS] etherboot/filo + sata startup timing
In-Reply-To: <20060511224047.GA27483@localdomain>
References: <20060424222144.GA17934@coresystems.de>
	<20060424222501.GC27028@io.pong.be>
	<20060428231617.GA28043@coresystems.de>
	<20060501155545.GA3652@io.pong.be>
	<20060505134709.GA2422@coresystems.de>
	<20060505213830.GA23965@localdomain>
	<20060506123913.GA11451@coresystems.de>
	<20060506131149.GD20174@localdomain>
	<20060511221143.GA2260@coresystems.de>
	<20060511224047.GA27483@localdomain>
Message-ID: <20060511225334.GA30513@localdomain>

On Thu, May 11, 2006 at 06:40:47PM -0400, Ward Vandewege wrote:
> On Fri, May 12, 2006 at 12:11:43AM +0200, Stefan Reinauer wrote:
> > * Ward Vandewege <ward at gnu.org> [060506 15:11]:
> > > On Sat, May 06, 2006 at 02:39:13PM +0200, Stefan Reinauer wrote:
> > > > * Ward Vandewege <ward at gnu.org> [060505 23:38]:
> > > > > I've tried this; the boot log is attached (minicom-20060505.cap) with
> > > > > DEBUG_PCI, DEBUG_IDE and DEBUG_LINUXBIOS enabled. Didn't help.
> > > > > 
> > > > > >  * if that doesnt help: try whether the disk is detected as hda instead
> > > > > >    of hde. This might happen with the current code.
> > > > > 
> > > > > I've tried that too, the bootlog is also attached (minicom-20060505-2.cap).
> > > > > Still no luck; though here it does seem to find the IDE controller. But not
> > > > > the drive...
> > > > 
> > > > Aha! It shows a floating IDE bus... Does anyone have an idea what's
> > > > wrong exactly if this shows up? It might just be an issue of waiting
> > > > just a little bit longer..
> > 
> > Hm. can you set the timeout from 20ms to 200ms?
> 
> Do you mean this line
> 
>     timeout = currticks() + 20 * TICKS_PER_SEC / 1000;
> 
> in ide_bus_floating() in drivers/ide.c? 

I've modified that to 200, but to no avail. Still the same problem after a
cold boot (see attached boot log - minicom-20060511-coldboot.cap).

A warm boot works fine though (minicom-20060511-warmboot.cap).

Ward.

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


LinuxBIOS-1.1.8_s2881_Fallback Thu May 11 18:44:48 EDT 2006 starting...
(0,1) link=00
(1,0) link=00
02 nodes initialized.
SBLink=02
NC node|link=02
ht reset -


LinuxBIOS-1.1.8_s2881_Fallback Thu May 11 18:44:48 EDT 2006 starting...
(0,1) link=00
(1,0) link=00
02 nodes initialized.
SBLink=02
NC node|link=02
Ram1.00
Ram1.01
Ram2.00
Ram2.01
Ram3
Initializing memory:  done
Initializing memory:  done
Ram4
v_esp=000cfd64
testx = 5a5a5a5a
Copying data from cache to ram -- switching to use ram as stack... Done
testx = 5a5a5a5a
Disabling cache as ram now 
Clearing initial memory region: Done
Copying LinuxBIOS to ram.
src=fffe0000
dst=00004000
linxbios_ram.bin   length = 00022ff0
Jumping to LinuxBIOS.
LinuxBIOS-1.1.8_s2881_Fallback Thu May 11 18:44:48 EDT 2006 booting...
Enumerating buses...
APIC_CLUSTER: 0 enabled
PCI_DOMAIN: 0000 enabled
  PCI: 00:18.3 siblings=1
CPU: APIC: 00 enabled
CPU: APIC: 01 enabled
PCI: 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=1
CPU: APIC: 02 enabled
CPU: APIC: 03 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: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: pci_scan_bus for bus 3
PCI: pci_scan_bus returning with max=03
PCI: 03: 133MHz PCI-X
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 1c <- [0x00fffff000 - 0x00ffffefff] bus 2 io
PCI: 01:01.0 24 <- [0xfffffffffff00000 - 0xffffffffffefffff] bus 2 prefmem
PCI: 01:03.0 24 <- [0x00fff00000 - 0x00ffefffff] bus 4 prefmem
Done reading resources.
Allocating VGA resource PCI: 04:06.0
Setting PCI_BRIDGE_CTL_VGA for bridge PCI: 01:03.0
Setting PCI_BRIDGE_CTL_VGA for bridge PCI: 00:18.0
Setting PCI_BRIDGE_CTL_VGA for bridge PCI_DOMAIN: 0000
Setting PCI_BRIDGE_CTL_VGA for bridge Root Device
Setting resources...
VGA: PCI: 00:18.0 (aka node 0) link 2 has VGA device
PCI: 00:18.0 1ba <- [0x00fd300000 - 0x00fd2fffff] prefmem <node 0 link 2>
PCI: 00:18.0 1c2 <- [0x0000001000 - 0x0000002fff] io <node 0 link 2>
PCI: 00:18.0 1b2 <- [0x00fc000000 - 0x00fd2fffff] mem <node 0 link 2>
PCI: 01:01.0 20 <- [0x00fd100000 - 0x00fd1fffff] bus 2 mem
PCI: 02:09.0 10 <- [0x00fd100000 - 0x00fd10ffff] mem64
PCI: 02:09.0 18 <- [0x00fd110000 - 0x00fd11ffff] mem64
PCI: 02:09.1 10 <- [0x00fd120000 - 0x00fd12ffff] mem64
PCI: 02:09.1 18 <- [0x00fd130000 - 0x00fd13ffff] mem64
PCI: 01:01.1 10 <- [0x00fd200000 - 0x00fd200fff] mem64
PCI: 01:02.1 10 <- [0x00fd201000 - 0x00fd201fff] mem64
PCI: 01:03.0 1c <- [0x0000001000 - 0x0000001fff] bus 4 io
PCI: 01:03.0 20 <- [0x00fc000000 - 0x00fd0fffff] bus 4 mem
PCI: 04:00.0 10 <- [0x00fd000000 - 0x00fd000fff] mem
PCI: 04:00.1 10 <- [0x00fd001000 - 0x00fd001fff] mem
PCI: 04:05.0 10 <- [0x0000001410 - 0x0000001417] io
PCI: 04:05.0 14 <- [0x0000001430 - 0x0000001433] io
PCI: 04:05.0 18 <- [0x0000001420 - 0x0000001427] io
PCI: 04:05.0 1c <- [0x0000001440 - 0x0000001443] io
PCI: 04:05.0 20 <- [0x0000001400 - 0x000000140f] io
PCI: 04:05.0 24 <- [0x00fd003000 - 0x00fd0033ff] mem
PCI: 04:06.0 10 <- [0x00fc000000 - 0x00fcffffff] mem
PCI: 04:06.0 14 <- [0x0000001000 - 0x00000010ff] io
PCI: 04:06.0 18 <- [0x00fd002000 - 0x00fd002fff] 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 <- [0x0000002420 - 0x000000242f] io
PCI: 01:04.2 10 <- [0x0000002400 - 0x000000241f] io
PCI: 01:04.3 58 <- [0x0000002000 - 0x00000020ff] io
PCI: 00:18.3 94 <- [0x00f8000000 - 0x00fbffffff] mem <gart>
PCI: 00:19.3 94 <- [0x00f8000000 - 0x00fbffffff] mem <gart>
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 <- 146
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.1 subsystem <- 10f1/2881
PCI: 01:02.1 cmd <- 146
PCI: 01:03.0 bridge ctrl <- 000b
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 20f12
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
DONE variable MTRRs
Clear out the extra MTRR's

MTRR check
Fixed MTRRs   : Enabled
Variable MTRRs: Enabled

microcode: equivalent processor rev id  = 0x0210, patch id = 0x00000000
microcode: patch id that want to apply= 0x0000004d
microcode: updated to patch id = 0x0000004d  success
Setting up local apic... apic_id: 0 done.
Clearing memory 2048K - 1048576K: --------------- done
CPU #0 Initialized
start_eip=0x00018000
Initializing CPU #1
CPU: vendor AMD device 20f12
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
DONE variable MTRRs
Clear out the extra MTRR's

MTRR check
Fixed MTRRs   : Enabled
Variable MTRRs: Enabled

microcode: equivalent processor rev id  = 0x0210, patch id = 0x00000000
microcode: patch id that want to apply= 0x0000004d
microcode: updated to patch id = 0x0000004d  success
Setting up local apic... apic_id: 1 done.
CPU #1 Initialized
start_eip=0x00018000
Initializing CPU #2
CPU: vendor AMD device 20f12
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
DONE variable MTRRs
Clear out the extra MTRR's

MTRR check
Fixed MTRRs   : Enabled
Variable MTRRs: Enabled

microcode: equivalent processor rev id  = 0x0210, patch id = 0x00000000
microcode: patch id that want to apply= 0x0000004d
microcode: updated to patch id = 0x0000004d  success
Setting up local apic... apic_id: 2 done.
Clearing memory 1048576K - 2097152K: ---------------- done
CPU #2 Initialized
start_eip=0x00018000
Initializing CPU #3
Waiting for 1 CPUS to stop
CPU: vendor AMD device 20f12
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
DONE variable MTRRs
Clear out the extra MTRR's

MTRR check
Fixed MTRRs   : Enabled
Variable MTRRs: Enabled

microcode: equivalent processor rev id  = 0x0210, patch id = 0x00000000
microcode: patch id that want to apply= 0x0000004d
microcode: updated to patch id = 0x0000004d  success
Setting up local apic... apic_id: 3 done.
CPU #3 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:03.0 init
PCI: 04:05.0 init
PCI: 04:06.0 init
rom address for PCI: 04:06.0 = fff80000
copying VGA ROM Image from 0xfff80000 to 0xc0000, 0x8000 bytes
entering emulator
halt_sys: file /data/personal/data/2006/projects/gnu/chimera/linuxbios/lbv2/rev-latest/LinuxBIOSv2/src/devices/emulator/x86emu/ops.c, line 4387
PCI: 01:04.0 init
amd8111: ioapic bsp_apicid = 00
RTC Init
Invalid CMOS LB checksum
enabling HPET @0xfed00000
PNP: 002e.0 init
PNP: 002e.2 init
PNP: 002e.5 init
PNP: 002e.b init
PCI: 01: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.
Devices initialized
Writing IRQ routing tables to 0xf0000...done.
Wrote the mp table end at: 00000020 - 000001f4
Moving GDT to 0x500...ok
Wrote linuxbios table at: 00000530 - 00000df8  checksum f454

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

rom_stream: 0xfffc0000 - 0xfffdffff
Found ELF candiate at offset 0
New segment addr 0x100000 size 0x3b500 offset 0xc0 filesize 0x11748
(cleaned up) New segment addr 0x100000 size 0x3b500 offset 0xc0 filesize 0x11748
New segment addr 0x13b500 size 0x48 offset 0x11820 filesize 0x48
(cleaned up) New segment addr 0x13b500 size 0x48 offset 0x11820 filesize 0x48
Dropping non PT_LOAD segment
Dropping non PT_LOAD segment
Loading Segment: addr: 0x0000000000100000 memsz: 0x000000000003b500 filesz: 0x0000000000011748
Clearing Segment: addr: 0x0000000000111748 memsz: 0x0000000000029db8
Loading Segment: addr: 0x000000000013b500 memsz: 0x0000000000000048 filesz: 0x0000000000000048
Jumping to boot code at 0x10cbcc
FILO version 0.5 (root at countzero) Thu May 11 18:21:40 EDT 2006
collect_linuxbios_info: Searching for LinuxBIOS tables...
find_lb_table: Found canidate at: 00000530
find_lb_table: header checksum o.k.
find_lb_table: table checksum o.k.
find_lb_table: record count o.k.
collect_linuxbios_info: Found LinuxBIOS table at: 00000530
convert_memmap: 0x00000000000000 0x00000000000e64 16
convert_memmap: 0x00000000000e64 0x0000000009f19c 1
convert_memmap: 0x000000000c0000 0x00000000030000 1
convert_memmap: 0x000000000f0000 0x00000000000400 16
convert_memmap: 0x000000000f0400 0x0000003ff0fc00 1
convert_memmap: 0x00000040000000 0x00000040000000 1
pci_init: Scanning PCI: found 23 devices
pci_init: 00:18.0 1022:1100 0600 00
pci_init: 00:18.1 1022:1101 0600 00
pci_init: 00:18.2 1022:1102 0600 00
pci_init: 00:18.3 1022:1103 0600 00
pci_init: 00:19.0 1022:1100 0600 00
pci_init: 00:19.1 1022:1101 0600 00
pci_init: 00:19.2 1022:1102 0600 00
pci_init: 00:19.3 1022:1103 0600 00
pci_init: 01:01.0 1022:7450 0604 00
pci_init: 01:01.1 1022:7451 0800 10
pci_init: 01:02.0 1022:7450 0604 00
pci_init: 01:02.1 1022:7451 0800 10
pci_init: 01:03.0 1022:7460 0604 00
pci_init: 01:04.0 1022:7468 0601 00
pci_init: 01:04.1 1022:7469 0101 8a
pci_init: 01:04.2 1022:746a 0c05 00
pci_init: 01:04.3 1022:746b 0680 00
pci_init: 02:09.0 14e4:1648 0200 00
pci_init: 02:09.1 14e4:1648 0200 00
pci_init: 04:00.0 1022:7464 0c03 10
pci_init: 04:00.1 1022:7464 0c03 10
pci_init: 04:05.0 1095:3114 0180 00
pci_init: 04:06.0 1002:4752 0300 00
find_ide_controller: found PCI IDE controller 1095:3114 prog_if=0x0
find_ide_controller: primary channel: native PCI mode
find_ide_controller: cmd_base=0x1410 ctrl_base=0x1430
Detected floating bus
No drive detected on IDE channel 0
-------------- next part --------------
INIT detected from  --- {  APICID = 00 NODEID = 00 COREID = 00} ---

Issuing SOFT_RESET...


LinuxBIOS-1.1.8_s2881_Fallback Thu May 11 18:44:48 EDT 2006 starting...
(0,1) link=00
(1,0) link=00
02 nodes initialized.
SBLink=02
NC node|link=02
Ram1.00
Ram1.01
Ram2.00
Ram2.01
Ram3
Initializing memory:  done
Initializing memory:  done
Ram4
v_esp=000cfd64
testx = 5a5a5a5a
Copying data from cache to ram -- switching to use ram as stack... Done
testx = 5a5a5a5a
Disabling cache as ram now 
Clearing initial memory region: Done
Copying LinuxBIOS to ram.
src=fffe0000
dst=00004000
linxbios_ram.bin   length = 00022ff0
Jumping to LinuxBIOS.
LinuxBIOS-1.1.8_s2881_Fallback Thu May 11 18:44:48 EDT 2006 booting...
Enumerating buses...
APIC_CLUSTER: 0 enabled
PCI_DOMAIN: 0000 enabled
  PCI: 00:18.3 siblings=1
CPU: APIC: 00 enabled
CPU: APIC: 01 enabled
PCI: 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=1
CPU: APIC: 02 enabled
CPU: APIC: 03 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: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: pci_scan_bus for bus 3
PCI: pci_scan_bus returning with max=03
PCI: 03: 133MHz PCI-X
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 1c <- [0x00fffff000 - 0x00ffffefff] bus 2 io
PCI: 01:01.0 24 <- [0xfffffffffff00000 - 0xffffffffffefffff] bus 2 prefmem
PCI: 01:03.0 24 <- [0x00fff00000 - 0x00ffefffff] bus 4 prefmem
Done reading resources.
Allocating VGA resource PCI: 04:06.0
Setting PCI_BRIDGE_CTL_VGA for bridge PCI: 01:03.0
Setting PCI_BRIDGE_CTL_VGA for bridge PCI: 00:18.0
Setting PCI_BRIDGE_CTL_VGA for bridge PCI_DOMAIN: 0000
Setting PCI_BRIDGE_CTL_VGA for bridge Root Device
Setting resources...
VGA: PCI: 00:18.0 (aka node 0) link 2 has VGA device
PCI: 00:18.0 1ba <- [0x00fd300000 - 0x00fd2fffff] prefmem <node 0 link 2>
PCI: 00:18.0 1c2 <- [0x0000001000 - 0x0000002fff] io <node 0 link 2>
PCI: 00:18.0 1b2 <- [0x00fc000000 - 0x00fd2fffff] mem <node 0 link 2>
PCI: 01:01.0 20 <- [0x00fd100000 - 0x00fd1fffff] bus 2 mem
PCI: 02:09.0 10 <- [0x00fd100000 - 0x00fd10ffff] mem64
PCI: 02:09.0 18 <- [0x00fd110000 - 0x00fd11ffff] mem64
PCI: 02:09.1 10 <- [0x00fd120000 - 0x00fd12ffff] mem64
PCI: 02:09.1 18 <- [0x00fd130000 - 0x00fd13ffff] mem64
PCI: 01:01.1 10 <- [0x00fd200000 - 0x00fd200fff] mem64
PCI: 01:02.1 10 <- [0x00fd201000 - 0x00fd201fff] mem64
PCI: 01:03.0 1c <- [0x0000001000 - 0x0000001fff] bus 4 io
PCI: 01:03.0 20 <- [0x00fc000000 - 0x00fd0fffff] bus 4 mem
PCI: 04:00.0 10 <- [0x00fd000000 - 0x00fd000fff] mem
PCI: 04:00.1 10 <- [0x00fd001000 - 0x00fd001fff] mem
PCI: 04:05.0 10 <- [0x0000001410 - 0x0000001417] io
PCI: 04:05.0 14 <- [0x0000001430 - 0x0000001433] io
PCI: 04:05.0 18 <- [0x0000001420 - 0x0000001427] io
PCI: 04:05.0 1c <- [0x0000001440 - 0x0000001443] io
PCI: 04:05.0 20 <- [0x0000001400 - 0x000000140f] io
PCI: 04:05.0 24 <- [0x00fd003000 - 0x00fd0033ff] mem
PCI: 04:06.0 10 <- [0x00fc000000 - 0x00fcffffff] mem
PCI: 04:06.0 14 <- [0x0000001000 - 0x00000010ff] io
PCI: 04:06.0 18 <- [0x00fd002000 - 0x00fd002fff] 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 <- [0x0000002420 - 0x000000242f] io
PCI: 01:04.2 10 <- [0x0000002400 - 0x000000241f] io
PCI: 01:04.3 58 <- [0x0000002000 - 0x00000020ff] io
PCI: 00:18.3 94 <- [0x00f8000000 - 0x00fbffffff] mem <gart>
PCI: 00:19.3 94 <- [0x00f8000000 - 0x00fbffffff] mem <gart>
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 <- 146
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.1 subsystem <- 10f1/2881
PCI: 01:02.1 cmd <- 146
PCI: 01:03.0 bridge ctrl <- 040b
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 20f12
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
DONE variable MTRRs
Clear out the extra MTRR's

MTRR check
Fixed MTRRs   : Enabled
Variable MTRRs: Enabled

microcode: equivalent processor rev id  = 0x0210, patch id = 0x00000000
microcode: patch id that want to apply= 0x0000004d
microcode: updated to patch id = 0x0000004d  success
Setting up local apic... apic_id: 0 done.
Clearing memory 2048K - 1048576K: --------------- done
CPU #0 Initialized
start_eip=0x00018000
Initializing CPU #1
CPU: vendor AMD device 20f12
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
DONE variable MTRRs
Clear out the extra MTRR's

MTRR check
Fixed MTRRs   : Enabled
Variable MTRRs: Enabled

microcode: equivalent processor rev id  = 0x0210, patch id = 0x00000000
microcode: patch id that want to apply= 0x0000004d
microcode: updated to patch id = 0x0000004d  success
Setting up local apic... apic_id: 1 done.
CPU #1 Initialized
start_eip=0x00018000
Initializing CPU #2
CPU: vendor AMD device 20f12
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
DONE variable MTRRs
Clear out the extra MTRR's

MTRR check
Fixed MTRRs   : Enabled
Variable MTRRs: Enabled

microcode: equivalent processor rev id  = 0x0210, patch id = 0x00000000
microcode: patch id that want to apply= 0x0000004d
microcode: updated to patch id = 0x0000004d  success
Setting up local apic... apic_id: 2 done.
Clearing memory 1048576K - 2097152K: ---------------- done
CPU #2 Initialized
start_eip=0x00018000
Initializing CPU #3
Waiting for 1 CPUS to stop
CPU: vendor AMD device 20f12
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
DONE variable MTRRs
Clear out the extra MTRR's

MTRR check
Fixed MTRRs   : Enabled
Variable MTRRs: Enabled

microcode: equivalent processor rev id  = 0x0210, patch id = 0x00000000
microcode: patch id that want to apply= 0x0000004d
microcode: updated to patch id = 0x0000004d  success
Setting up local apic... apic_id: 3 done.
CPU #3 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:03.0 init
PCI: 04:05.0 init
PCI: 04:06.0 init
rom address for PCI: 04:06.0 = fff80000
copying VGA ROM Image from 0xfff80000 to 0xc0000, 0x8000 bytes
entering emulator
halt_sys: file /data/personal/data/2006/projects/gnu/chimera/linuxbios/lbv2/rev-latest/LinuxBIOSv2/src/devices/emulator/x86emu/ops.c, line 4387
PCI: 01:04.0 init
amd8111: ioapic bsp_apicid = 00
RTC Init
Invalid CMOS LB checksum
enabling HPET @0xfed00000
PNP: 002e.0 init
PNP: 002e.2 init
PNP: 002e.5 init
PNP: 002e.b init
PCI: 01: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.
Devices initialized
Writing IRQ routing tables to 0xf0000...done.
Wrote the mp table end at: 00000020 - 000001f4
Moving GDT to 0x500...ok
Wrote linuxbios table at: 00000530 - 00000df8  checksum f454

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

rom_stream: 0xfffc0000 - 0xfffdffff
Found ELF candiate at offset 0
New segment addr 0x100000 size 0x3b500 offset 0xc0 filesize 0x11748
(cleaned up) New segment addr 0x100000 size 0x3b500 offset 0xc0 filesize 0x11748
New segment addr 0x13b500 size 0x48 offset 0x11820 filesize 0x48
(cleaned up) New segment addr 0x13b500 size 0x48 offset 0x11820 filesize 0x48
Dropping non PT_LOAD segment
Dropping non PT_LOAD segment
Loading Segment: addr: 0x0000000000100000 memsz: 0x000000000003b500 filesz: 0x0000000000011748
Clearing Segment: addr: 0x0000000000111748 memsz: 0x0000000000029db8
Loading Segment: addr: 0x000000000013b500 memsz: 0x0000000000000048 filesz: 0x0000000000000048
Jumping to boot code at 0x10cbcc
FILO version 0.5 (root at countzero) Thu May 11 18:21:40 EDT 2006
collect_linuxbios_info: Searching for LinuxBIOS tables...
find_lb_table: Found canidate at: 00000530
find_lb_table: header checksum o.k.
find_lb_table: table checksum o.k.
find_lb_table: record count o.k.
collect_linuxbios_info: Found LinuxBIOS table at: 00000530
convert_memmap: 0x00000000000000 0x00000000000e64 16
convert_memmap: 0x00000000000e64 0x0000000009f19c 1
convert_memmap: 0x000000000c0000 0x00000000030000 1
convert_memmap: 0x000000000f0000 0x00000000000400 16
convert_memmap: 0x000000000f0400 0x0000003ff0fc00 1
convert_memmap: 0x00000040000000 0x00000040000000 1
pci_init: Scanning PCI: found 23 devices
pci_init: 00:18.0 1022:1100 0600 00
pci_init: 00:18.1 1022:1101 0600 00
pci_init: 00:18.2 1022:1102 0600 00
pci_init: 00:18.3 1022:1103 0600 00
pci_init: 00:19.0 1022:1100 0600 00
pci_init: 00:19.1 1022:1101 0600 00
pci_init: 00:19.2 1022:1102 0600 00
pci_init: 00:19.3 1022:1103 0600 00
pci_init: 01:01.0 1022:7450 0604 00
pci_init: 01:01.1 1022:7451 0800 10
pci_init: 01:02.0 1022:7450 0604 00
pci_init: 01:02.1 1022:7451 0800 10
pci_init: 01:03.0 1022:7460 0604 00
pci_init: 01:04.0 1022:7468 0601 00
pci_init: 01:04.1 1022:7469 0101 8a
pci_init: 01:04.2 1022:746a 0c05 00
pci_init: 01:04.3 1022:746b 0680 00
pci_init: 02:09.0 14e4:1648 0200 00
pci_init: 02:09.1 14e4:1648 0200 00
pci_init: 04:00.0 1022:7464 0c03 10
pci_init: 04:00.1 1022:7464 0c03 10
pci_init: 04:05.0 1095:3114 0180 00
pci_init: 04:06.0 1002:4752 0300 00
find_ide_controller: found PCI IDE controller 1095:3114 prog_if=0x0
find_ide_controller: primary channel: native PCI mode
find_ide_controller: cmd_base=0x1410 ctrl_base=0x1430
ide_software_reset: Waiting for ide0 to become ready for reset... ok
init_drive: Testing for hda
init_drive: Probing for hda
init_drive: LBA mode, sectors=145226112
init_drive: LBA48 mode, sectors=145226112
init_drive: Init device params... ok
hda: LBA48 74GB: WDC WD740GD-00FLC0                      
init_drive: Testing for hdb
init_drive: Probing for hdb
init_drive: LBA mode, sectors=145226112
init_drive: LBA48 mode, sectors=145226112
init_drive: Init device params... ok
hdb: LBA48 74GB: WDC WD740GD-00FLC0                      
Mounted ext2fs
Found Linux version 2.6.16.2 (root at chimera.gnu.org) #3 SMP Thu Apr 20 13:49:15 EDT 2006 bzImage.
Loading kernel... ok
Jumping to entry point...
ACPI: Unable to locate RSDP
 * Starting RAID devices...        [ ok ]
 * Starting hardware event daemon...        [ ok ]
 * Mounting a tmpfs over /dev...        [ ok ]
 * Creating initial device nodes...        [ ok ]
 * Setting disc parameters...        [ ok ]
 * Checking root file system...        /: clean, 2752621/25378816 files, 47171788/50743248 blocks
[ ok ]
 * Initializing modules...        [ ok ]
 * Cleaning up ifupdown...        [ ok ]
 * Setting the system clock...        [ ok ]
 * Setting up LVM Volume Groups...        [ ok ]
 * Checking all file systems...        /boot: clean, 41/32064 files, 32823/64128 blocks
/tmp: clean, 11/732960 files, 55826/1463856 blocks
[ ok ]
 * Mounting local filesystems...        /dev/md0 on /boot type ext3 (rw)
/dev/md1 on /tmp type ext3 (rw)
[ ok ]
 * Setting sensors limits...        [ ok ]
 * Restoring resolver state...        [ ok ]
 * Setting up networking...        [ ok ]
 * Starting hotplug subsystem...        [ ok ]
 * Configuring network interfaces...        [ ok ]
 * Waiting for network interface to come up...        [ ok ]
Loading the saved-state of the serial devices... 
/dev/ttyS0 at 0x03f8 (irq = 4) is a 16550A
/dev/ttyS1 at 0x02f8 (irq = 3) is a 16550A
 * Setting up ALSA...        [ ok ]
 * Setting the system clock...        [ ok ]
 * Synchronizing clock to ntp.ubuntulinux.org...        [ ok ]
 * Initializing random number generator...        [ ok ]
 * Entering runlevel: 2
 * Starting system log daemon...        [ ok ]
 * Starting kernel log daemon...        [ ok ]
Starting amavisd: head: cannot open `/etc/mailname' for reading: No such file or directory
amavisd-new.
 * Starting OpenBSD Secure Shell server...        [ ok ]
Setting sysfs variables...done.
sadc not enabled in /etc/default/sysstat, not starting.
 * Starting RAID monitoring services...        [ ok ]
 * Starting deferred execution scheduler...        [ ok ]
 * Starting periodic command scheduler...        [ ok ]
 * Id "T0" respawning too fast: disabled for 5 minutes
Debian GNU/Linux ttyS0 115200 (DIRECT)
**EMSI_REQA77E              
chimera.gnu.org login: 

From stepan at coresystems.de  Fri May 12 01:13:20 2006
From: stepan at coresystems.de (Stefan Reinauer)
Date: Fri, 12 May 2006 01:13:20 +0200
Subject: [LinuxBIOS] etherboot/filo + sata startup timing
In-Reply-To: <20060511224047.GA27483@localdomain>
References: <20060424222144.GA17934@coresystems.de>
	<20060424222501.GC27028@io.pong.be>
	<20060428231617.GA28043@coresystems.de>
	<20060501155545.GA3652@io.pong.be>
	<20060505134709.GA2422@coresystems.de>
	<20060505213830.GA23965@localdomain>
	<20060506123913.GA11451@coresystems.de>
	<20060506131149.GD20174@localdomain>
	<20060511221143.GA2260@coresystems.de>
	<20060511224047.GA27483@localdomain>
Message-ID: <20060511231320.GA5584@coresystems.de>

* Ward Vandewege <ward at gnu.org> [060512 00:40]:
> On Fri, May 12, 2006 at 12:11:43AM +0200, Stefan Reinauer wrote:
> > * Ward Vandewege <ward at gnu.org> [060506 15:11]:
> > > On Sat, May 06, 2006 at 02:39:13PM +0200, Stefan Reinauer wrote:
> > > > * Ward Vandewege <ward at gnu.org> [060505 23:38]:
> > > > > I've tried this; the boot log is attached (minicom-20060505.cap) with
> > > > > DEBUG_PCI, DEBUG_IDE and DEBUG_LINUXBIOS enabled. Didn't help.
> > > > > 
> > > > > >  * if that doesnt help: try whether the disk is detected as hda instead
> > > > > >    of hde. This might happen with the current code.
> > > > > 
> > > > > I've tried that too, the bootlog is also attached (minicom-20060505-2.cap).
> > > > > Still no luck; though here it does seem to find the IDE controller. But not
> > > > > the drive...
> > > > 
> > > > Aha! It shows a floating IDE bus... Does anyone have an idea what's
> > > > wrong exactly if this shows up? It might just be an issue of waiting
> > > > just a little bit longer..
> > 
> > Hm. can you set the timeout from 20ms to 200ms?
> 
> Do you mean this line
> 
>     timeout = currticks() + 20 * TICKS_PER_SEC / 1000;
> 
> in ide_bus_floating() in drivers/ide.c? 
> 
> > Does it work with the etherboot filo btw?
> 
> Yes; that's what I've been using. But it _only_ works if I guarantee at least
> 3 to 4 seconds of bootup delay; that's why I have the AUTOBOOT_DELAY set to
> 5. But that doesn't work for Filo 0.5 - maybe it tries to find the disks
> before doing the AUTOBOOT_DELAY?

Yes, it immediately tries to load the menu.lst file. If you dont want a
grub style menu you can disable USE_GRUB to get the old behavior

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 stepan at coresystems.de  Fri May 12 01:14:31 2006
From: stepan at coresystems.de (Stefan Reinauer)
Date: Fri, 12 May 2006 01:14:31 +0200
Subject: [LinuxBIOS] etherboot/filo + sata startup timing
In-Reply-To: <6F7DA19D05F3CF40B890C7CA2DB13A4203094C8C@ssvlexmb2.amd.com>
References: <6F7DA19D05F3CF40B890C7CA2DB13A4203094C8C@ssvlexmb2.amd.com>
Message-ID: <20060511231431.GB5584@coresystems.de>

* Lu, Yinghai <yinghai.lu at amd.com> [060512 00:43]:
> It seems TICKS_PER_SEC definition Etherboot is different from that in
> FILO....

Yeah, it's 1000 vs 18. Shouldn't matter too much though as its all
relatively coded as far as I can see..

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 ward at gnu.org  Fri May 12 02:16:39 2006
From: ward at gnu.org (Ward Vandewege)
Date: Thu, 11 May 2006 20:16:39 -0400
Subject: [LinuxBIOS] etherboot/filo + sata startup timing
In-Reply-To: <20060511231320.GA5584@coresystems.de>
References: <20060424222501.GC27028@io.pong.be>
	<20060428231617.GA28043@coresystems.de>
	<20060501155545.GA3652@io.pong.be>
	<20060505134709.GA2422@coresystems.de>
	<20060505213830.GA23965@localdomain>
	<20060506123913.GA11451@coresystems.de>
	<20060506131149.GD20174@localdomain>
	<20060511221143.GA2260@coresystems.de>
	<20060511224047.GA27483@localdomain>
	<20060511231320.GA5584@coresystems.de>
Message-ID: <20060512001639.GA31328@localdomain>

On Fri, May 12, 2006 at 01:13:20AM +0200, Stefan Reinauer wrote:
> > > Does it work with the etherboot filo btw?
> > 
> > Yes; that's what I've been using. But it _only_ works if I guarantee at least
> > 3 to 4 seconds of bootup delay; that's why I have the AUTOBOOT_DELAY set to
> > 5. But that doesn't work for Filo 0.5 - maybe it tries to find the disks
> > before doing the AUTOBOOT_DELAY?
> 
> Yes, it immediately tries to load the menu.lst file. If you dont want a
> grub style menu you can disable USE_GRUB to get the old behavior

Actually, I was looking forward to having a GRUB style bootloader - for a
production machine in a datacenter that's a nice thing to have.

Ward.

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



From stepan at coresystems.de  Fri May 12 02:44:12 2006
From: stepan at coresystems.de (Stefan Reinauer)
Date: Fri, 12 May 2006 02:44:12 +0200
Subject: [LinuxBIOS] etherboot/filo + sata startup timing
In-Reply-To: <20060512001639.GA31328@localdomain>
References: <20060428231617.GA28043@coresystems.de>
	<20060501155545.GA3652@io.pong.be>
	<20060505134709.GA2422@coresystems.de>
	<20060505213830.GA23965@localdomain>
	<20060506123913.GA11451@coresystems.de>
	<20060506131149.GD20174@localdomain>
	<20060511221143.GA2260@coresystems.de>
	<20060511224047.GA27483@localdomain>
	<20060511231320.GA5584@coresystems.de>
	<20060512001639.GA31328@localdomain>
Message-ID: <20060512004412.GA8883@coresystems.de>

* Ward Vandewege <ward at gnu.org> [060512 02:16]:
> On Fri, May 12, 2006 at 01:13:20AM +0200, Stefan Reinauer wrote:
> > > > Does it work with the etherboot filo btw?
> > > 
> > > Yes; that's what I've been using. But it _only_ works if I guarantee at least
> > > 3 to 4 seconds of bootup delay; that's why I have the AUTOBOOT_DELAY set to
> > > 5. But that doesn't work for Filo 0.5 - maybe it tries to find the disks
> > > before doing the AUTOBOOT_DELAY?
> > 
> > Yes, it immediately tries to load the menu.lst file. If you dont want a
> > grub style menu you can disable USE_GRUB to get the old behavior
> 
> Actually, I was looking forward to having a GRUB style bootloader - for a
> production machine in a datacenter that's a nice thing to have.

can you add a delay(5); or delay(10); before grub_main(); in main/filo.c
and see if that helps?

-- 
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 smithbone at gmail.com  Fri May 12 05:03:12 2006
From: smithbone at gmail.com (Richard Smith)
Date: Thu, 11 May 2006 22:03:12 -0500
Subject: [LinuxBIOS] 2 Beginner questions
In-Reply-To: <4463A9B2.2080507@waye.co.uk>
References: <4463A9B2.2080507@waye.co.uk>
Message-ID: <8a0c36780605112003i1a20263dr47891c0c7ae111f5@mail.gmail.com>

On 5/11/06, scott <scott at waye.co.uk> wrote:
> I'm a little confused about getting a console on a screen:
>
> Do I need the VGA stuff in order to get just text output from the
> onboard video (EPIA MII) or is it only needed to do graphics?

You have to do the VGA stuff to initialize the vga card correctly.  So
it has to be done before any video output text or otherwise.

> What is a "uniq console" as activated by :
> CONFIG_CONSOLE_BTEXT=1

I vaguely remember this.  grepping through the code it only looks like
its used in the ragexl code so you probally don't have to mess with it

-- 
Richard A. Smith



From vincentetsou at nexcom.com.tw  Fri May 12 06:22:31 2006
From: vincentetsou at nexcom.com.tw (Vincente Tsou)
Date: Fri, 12 May 2006 12:22:31 +0800
Subject: [LinuxBIOS] New guy in LinuxBios
In-Reply-To: <6F7DA19D05F3CF40B890C7CA2DB13A4203094C87@ssvlexmb2.amd.com>
References: <6F7DA19D05F3CF40B890C7CA2DB13A4203094C87@ssvlexmb2.amd.com>
Message-ID: <41fde3420605112122h675cf1e1j3b54ee4803d3a802@mail.gmail.com>

Dear Lu and Stefan,

Thank you very much for your reply.

But I can't find the inherent_ht.c in my LinuxBios source tree.
Should I download this one from somewhere?
or you can send one to me.



Thanks.



2006/5/12, Lu, Yinghai <yinghai.lu at amd.com>:
>
> No. It seems there is one MB need to set..., I forget the model...
>
> But amd chipset base MB should be ok to comment that out...
>
> YH
>
> -----Original Message-----
> From: Stefan Reinauer [mailto:stepan at coresystems.de]
> Sent: Thursday, May 11, 2006 10:01 AM
> To: Lu, Yinghai
> Cc: vincentetsou at nexcom.com.tw; linuxbios at linuxbios.org
> Subject: Re: [LinuxBIOS] New guy in LinuxBios
>
> * Lu, Yinghai <yinghai.lu at amd.com> [060511 18:32]:
> > Comment out several lines about links in resourcemap.c.
>
> Can we just comment this out? Or would we need to put the link number in
> the registers before writing?
>
> --
> 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/
>
>
>
>


-- 
Best Regards,
Vincente Tsou

Engineer
R/D, S/W Dept.
NEXCOM International Co.
Tel: 886-2-82280606 Ext. 3205
Fax: 886-2-82280506
E-mail: vincentetsou at nexcom.com.tw
Web: http://www.nexcom.com.tw/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20060512/51905ef9/attachment.html>

From stepan at coresystems.de  Fri May 12 12:03:34 2006
From: stepan at coresystems.de (Stefan Reinauer)
Date: Fri, 12 May 2006 12:03:34 +0200
Subject: [LinuxBIOS] New guy in LinuxBios
In-Reply-To: <41fde3420605112122h675cf1e1j3b54ee4803d3a802@mail.gmail.com>
References: <6F7DA19D05F3CF40B890C7CA2DB13A4203094C87@ssvlexmb2.amd.com>
	<41fde3420605112122h675cf1e1j3b54ee4803d3a802@mail.gmail.com>
Message-ID: <20060512100334.GB22489@coresystems.de>

* Vincente Tsou <vincentetsou at nexcom.com.tw> [060512 06:22]:
> Dear Lu and Stefan,
>  
> Thank you very much for your reply.
>  
> But I can't find the inherent_ht.c in my LinuxBios source tree.

Yinghai is talking about src/northbridge/amd/amdk8/incoherent_ht.c

You need to try commenting out the lines I sent in the last mail from
src/northbridge/amd/amdk8/resourcemap.c

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 marcelocoelho at gmail.com  Fri May 12 15:59:03 2006
From: marcelocoelho at gmail.com (Marcelo Coelho)
Date: Fri, 12 May 2006 14:59:03 +0100
Subject: [LinuxBIOS] Asrock mobo with SiS chipset
Message-ID: <20c6f18e0605120659ye0e3ed6jecd0e7fe2417d5b6@mail.gmail.com>

Hi!

I have an Asrock k7s41 motherboard, with a notebook cpu. I'm willing
to test linuxbios in it. Does anyone has linuxbios working with the
SiS chipset? This motherboard has lan, audio and vga onboard.

Any comments will be appreciated!!

Thanks!

From ward at gnu.org  Fri May 12 16:10:12 2006
From: ward at gnu.org (Ward Vandewege)
Date: Fri, 12 May 2006 10:10:12 -0400
Subject: [LinuxBIOS] etherboot/filo + sata startup timing
In-Reply-To: <20060512004412.GA8883@coresystems.de>
References: <20060501155545.GA3652@io.pong.be>
	<20060505134709.GA2422@coresystems.de>
	<20060505213830.GA23965@localdomain>
	<20060506123913.GA11451@coresystems.de>
	<20060506131149.GD20174@localdomain>
	<20060511221143.GA2260@coresystems.de>
	<20060511224047.GA27483@localdomain>
	<20060511231320.GA5584@coresystems.de>
	<20060512001639.GA31328@localdomain>
	<20060512004412.GA8883@coresystems.de>
Message-ID: <20060512141012.GA16042@localdomain>

On Fri, May 12, 2006 at 02:44:12AM +0200, Stefan Reinauer wrote:
> * Ward Vandewege <ward at gnu.org> [060512 02:16]:
> > On Fri, May 12, 2006 at 01:13:20AM +0200, Stefan Reinauer wrote:
> > > > > Does it work with the etherboot filo btw?
> > > > 
> > > > Yes; that's what I've been using. But it _only_ works if I guarantee at least
> > > > 3 to 4 seconds of bootup delay; that's why I have the AUTOBOOT_DELAY set to
> > > > 5. But that doesn't work for Filo 0.5 - maybe it tries to find the disks
> > > > before doing the AUTOBOOT_DELAY?
> > > 
> > > Yes, it immediately tries to load the menu.lst file. If you dont want a
> > > grub style menu you can disable USE_GRUB to get the old behavior
> > 
> > Actually, I was looking forward to having a GRUB style bootloader - for a
> > production machine in a datacenter that's a nice thing to have.
> 
> can you add a delay(5); or delay(10); before grub_main(); in main/filo.c
> and see if that helps?

Yes, delay(5) does the trick. Maybe this could be made into a configurable
parameter?

Thanks,
Ward.

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



From rminnich at lanl.gov  Fri May 12 17:19:52 2006
From: rminnich at lanl.gov (Ronald G Minnich)
Date: Fri, 12 May 2006 09:19:52 -0600
Subject: [LinuxBIOS] show config.lb error
In-Reply-To: <5c5dcf370605110609h59c3931cx9853a562d87885eb@mail.gmail.com>
References: <5c5dcf370605110609h59c3931cx9853a562d87885eb@mail.gmail.com>
Message-ID: <4464A798.4050401@lanl.gov>

Neil wrote:
> Dear all:
>  
> My MB has two cpu (AMD opteron) , chipset is broadcom bcm5780 and 
> bcm5785 ,after I flash my linuxbios ,It hang ,and from minicom ,
> we can see the error below(attchment is the whole log ):
>  
> PCI: 00:0a.0 [1166/0130] enabled
> PCI: 00:0b.0 [1166/0130] enabled
> PCI: 00:0c.0 [1166/0132] enabled
> PCI: 00:0d.0 [1166/0132] enabled
> PCI: 00:0e.0 [1166/0132] enabled
> PCI: 00:0f.0 [1166/0132] enabled
> PCI: 00: 0a.0
> PCI: Left over static devices.  Check your Config.lb <http://config.lb/>
>  
> could anyone tell me what is the problem? Thank you very much!
> Neil
> 
> 
> ------------------------------------------------------------------------
> 
> 
> LinuxBIOS-1.1.8_Fallback Thu May 11 14:53:42 CST 2006 starting...
> real main sysinfo =000cf000
> bsp_apicid=00
> (0,1) link=01
> (1,0) link=01
> 02 nodes initialized.
> SBLink=02
> NC node|link=02
> SMBus controller enabled
> Ram1.00
> Ram1.01
> Ram2.00
> Registered
> 200Mhz
> RAM: 0x00100000 KB
> Ram2.01
> Registered
> 200Mhz
> RAM: 0x00200000 KB
> Ram3
> Initializing memory:  done
> Initializing memory:  done
> Setting variable MTRR 02, base: 0000MB, range: 0800MB, type WB
> DQS Training:RcvrEn:Pass1: 00 CTLRMaxDelay=06 done
> DQS Training:RcvrEn:Pass1: 01 CTLRMaxDelay=ae done
> DQS Training:DQSPos: 00 done
> DQS Training:DQSPos: 01
> DQS Training Rd Wr failed ctrl01
>  done
> DQS Training:RcvrEn:Pass2: 00 CTLRMaxDelay=38 done
> DQS Training:RcvrEn:Pass2: 01 CTLRMaxDelay=ae done
> DQS Training:tsc[00]=00000000251a65f8
> DQS Training:tsc[01]=000000002a97a605
> DQS Training:tsc[02]=000000003f4c0937
> DQS Training:tsc[03]=000000031eb6b53c
> DQS Training:tsc[04]=0000000320edcf05
> Ram4
> v_esp=000cefc4
> testx = 5a5a5a5a
> Copying data from cache to ram -- switching to use ram as stack... Done
> testx = 5a5a5a5a
> Disabling cache as ram now
> Clearing initial memory region: Done
> Copying LinuxBIOS to ram.
> src=fffe0004
> dst=00004000
> linxbios_ram.bin length = 00022c10
> Jumping to LinuxBIOS.
> LinuxBIOS-1.1.8_Fallback Thu May 11 14:53:42 CST 2006 booting...
> Enumerating buses...
> APIC_CLUSTER: 0 enabled
> PCI_DOMAIN: 0000 enabled
>   PCI: 00:18.3 siblings=1
> CPU: APIC: 00 enabled
> CPU: APIC: 01 enabled
>   PCI: 00:19.3 siblings=1
> CPU: APIC: 02 enabled
> CPU: APIC: 03 enabled
> PCI: pci_scan_bus for bus 00
> PCI: 00:18.0 [1022/1100] enabled
> PCI: 00:18.1 [1022/1101] enabled
> PCI: 00:18.2 [1022/1102] enabled
> PCI: 00:18.3 [1022/1103] enabled
> PCI: 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:00.0 [1166/0130] enabled
> PCI: 00:0a.0 [1166/0130] enabled next_unitid: 0010
> PCI: 00:00.0 subbordinate bus PCI-X
> PCI: 00:00.0 [1166/0036] enabled
> PCI: 00:10.0 [1166/0036] enabled next_unitid: 0015
> PCI: pci_scan_bus for bus 00
> PCI: 00:04.0 [1002/5159] enabled
> PCI: 00:06.0 [1166/0036] enabled
> PCI: 00:07.0 [1166/0205] enabled
> Disabling static device: PCI: 00:07.1
> PCI: 00:07.2 [1166/0234] enabled
> PCI: 00:07.3 [1166/0238] enabled
> Disabling static device: PCI: 00:07.4
> Disabling static device: PCI: 00:07.5
> Disabling static device: PCI: 00:07.6
> Disabling static device: PCI: 00:08.0
> Disabling static device: PCI: 00:08.1
> Disabling static device: PCI: 00:08.2
> PCI: 00:0a.0 [1166/0130] enabled
> PCI: 00:0b.0 [1166/0130] enabled
> PCI: 00:0c.0 [1166/0132] enabled
> PCI: 00:0d.0 [1166/0132] enabled
> PCI: 00:0e.0 [1166/0132] enabled
> PCI: 00:0f.0 [1166/0132] enabled
> PCI: 00:0a.0
> PCI: Left over static devices.  Check your Config.lb
> 

This is an annoying message. It is saying that you have spec'ed out more 
devices than exist. You need to look at your mobo more closely.

thanks

ron



From stepan at coresystems.de  Fri May 12 17:43:41 2006
From: stepan at coresystems.de (Stefan Reinauer)
Date: Fri, 12 May 2006 17:43:41 +0200
Subject: [LinuxBIOS] s2881 fan control
In-Reply-To: <20060511215015.GA26395@localdomain>
References: <6F7DA19D05F3CF40B890C7CA2DB13A4203094BD5@ssvlexmb2.amd.com>
	<20060505205717.GA20174@localdomain>
	<20060505211923.GA22205@localdomain>
	<20060506122521.GA9586@coresystems.de>
	<20060509190507.GB8910@localdomain>
	<20060511204457.GA24351@localdomain>
	<20060511205956.GA30588@coresystems.de>
	<20060511215015.GA26395@localdomain>
Message-ID: <20060512154341.GA1748@coresystems.de>

* Ward Vandewege <ward at gnu.org> [060511 23:50]:
> > > 0000:01:04.3 Bridge: Advanced Micro Devices [AMD] AMD-8111 ACPI (rev 05)
> > > ...
> > > -40: 80 f1 00 04 00 00 00 00 20 14 50 00 00 00 00 00
> > > +40: 80 f1 00 07 00 00 00 00 20 14 50 00 00 00 00 00
> > 
> > Try the attached patch
> 
> That didn't help. 0x43 was still set to 04, and I could not set the fan
> speed. There was a bracket missing from the patch, btw.

Looking at the datasheet of the 8111 this was a blind shot in the wrong
direction.

The bits 0:2 in this register are:

PPSTATE. Previous power state. Read-only. This ?eld holds the most
previous power state from which the system came into the FON state. This
field resides on the VDD_COREX plane. Here are the possible states:

PPSTATE Power state
0h Reserved
1h POS power on suspend
2h C2
3h C3
4h MOFF mechanical off
5h STR suspend to RAM
6h STD suspend to disk
7h SOFF soft off

So LinuxBIOS reports mechanical off while factory bios reports soft off.
Interesting.

But I found some stuff that is worth following. Fans are controlled by
the IO mapped power management registers (PMxx) of the 8111. They are
called System Management I/O Mapped Registers in the specs on pages 
218 et sqq.

The base of the PMxx registers can be read from DevB:3x58 (32bit)
bits 15:8. (ie. pmbase=pci_read_dword(acpi_dev, 0x58) & 0xff00;)
See the aruma acpi code for more information. 
Iirc PMbase is 0xDD00 per default. So PM12 would require inb/outb to
0xdd12.

Also, there's GPIOs connected with FAN control: (pg 244 et sqq)
GPIO9  PMC9 FANCON1 08h (FANCON1 output) 1Xb N/A
GPIO10 PMCA FANRPM  08h (FANRPM input)   1Xb direct

And on the SMBus you have the following registers:
Fan Control Register PMF8 (Sounds like this belongs to the PMxx
registers)

Ok, now we need to glue this all together so that it works.

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 lanl.gov  Fri May 12 17:35:05 2006
From: rminnich at lanl.gov (Ronald G Minnich)
Date: Fri, 12 May 2006 09:35:05 -0600
Subject: [LinuxBIOS] SMM is evil?
In-Reply-To: <20060511205141.GA29824@coresystems.de>
References: <20060511175353.GA24554@coresystems.de> <44639940.5080604@gmx.net>
	<20060511205141.GA29824@coresystems.de>
Message-ID: <4464AB29.7050002@lanl.gov>

Stefan Reinauer wrote:
> 
> * Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006 at gmx.net> [060511 22:06]:
> 
>>Stefan Reinauer wrote:
>>
>>>If something seems as simple as setting the D_LCK bit of SMM, we should
>>>definitely do it.. It will at least be a marketable feature against
>>>other upcoming firmware implementations.
>>
>>I believe that setting D_LCK will mitigate a few attacks but I strongly
>>doubt that it cannot be cleared during system operation. Yes, the manual
>>specifies it, but manuals have been underspecified before. Since we don't
>>use SMM for anything, we might as well
> 
> 
> While the mechanism might indeed provide some protection its maybe
> possible to assert a reset signal to the chipset while not dropping out
> of the code path, as a possible workaround. No idea whether this is
> possible without "bios support" though.
> 
> 
>>So, by all means, do it now. Until somebody figures out a way to disable
>>D_LCK again we offer a much higher degree of security than everybody
>>else.
> 
> 
> Ok, D_LCK/D_OPEN/D_CLOSE is intel vocabulary. There is no such thing on
> AMD. They call it SMMLOCK in their BKDG:
> 
> 6.11.6 Locking SMM
> 
> The SMM registers can be locked by setting the SMMLOCK (HWCR, bit 0).
> Once set, the SMM_BASE, the SMM_ADDR, all but the two close bits of
> SMM_MASK and the RSMSPCYCDIS, SMISPCYCDIS, and SMMLOCK bits of HWCR are
> locked and cannot be changed. The only way to unlock the SMM registers
> is to assert reset.  This provides security to the SMM mechanism. The
> BIOS can lock the SMM environment after setting it up so that it can not
> be tampered with.
> 
> So I propose the following patch for LinuxBIOS to fix the SMM problem
> for all supported AMD K8 mainboards:
> 
> Index: src/cpu/amd/model_fxx/model_fxx_init.c
> ===================================================================
> --- src/cpu/amd/model_fxx/model_fxx_init.c      (revision 2302)
> +++ src/cpu/amd/model_fxx/model_fxx_init.c      (working copy)
> @@ -454,6 +454,12 @@
> 
>         k8_errata();
> 
> +       /* Set SMMLOCK to avoid exploits messing with SMM */
> +       msr = rdmsr(HWCR_MSR);
> +       msr.lo |= (1 << 0);
> +       wrmsr(HWCR_MSR, msr);
> +
> +
>         enable_cache();
> 
>         /* Enable the local cpu apics */
> 
> 
> 
> 
> 
> Anyone opposing?

cool. another advantage for us. Esp. since intel really counts on SMM 
being there for EFI ...

ron



From scott at waye.co.uk  Fri May 12 18:13:39 2006
From: scott at waye.co.uk (scott)
Date: Fri, 12 May 2006 17:13:39 +0100
Subject: [LinuxBIOS] Is VGABIOS_START still used?
Message-ID: <4464B433.6070906@waye.co.uk>

http://www.linuxbios.org/data/lbdoc/lb-5.html

On this page about the EPIA-M it mentions setting VGABIOS_START, so I 
tried to do that in my Config.lb, but I get this:

Will place Makefile, crt0.S, etc. in via/epia-m/epia-m
===> ERROR: Attempt to set nonexistent option VGABIOS_START (missing USES?)
via/epia-m/Config.lb:0


so I add:

uses VGABIOS_START

after the mainboard line and I get:


Trying to find one of ROMIMAGE, BUILDROM, OPTION, IF, PRINT, EOF, ELSE, 
END, PAYLOAD, ARCH, ADDACTION, CONFIG, DEFAULT, DIR, DRIVER, INIT, 
INITINCLUDE, INITOBJECT, LDSCRIPT, MAINBOARDINIT, MAKEDEFINE, MAKERULE, 
OBJECT, CHIP, REGISTER, DEVICE on line 7:
 >  uses VGABIOS_START
 >  ^
List of nearby tokens:
  (@81)  TARGET  =  'target'
  (@88)  DIRPATH  =  'epia-m'
  (@96)  MAINBOARD  =  'mainboard'
  (@106)  PATH  =  'via/epia-m'
===> ERROR: Could not parse file
via/epia-m/Config.lb:0


I run from the top of the LinuxBIOS tree:

bash-2.05$ grep -r -i "uses VGABIOS" ../*
../src/mainboard/digitallogic/msm586seg/Options.lb:#uses VGABIOS_START
../src/mainboard/technologic/ts5300/Options.lb:#uses VGABIOS_START

....so is VGABIOS_START still required?





From rminnich at lanl.gov  Fri May 12 18:34:37 2006
From: rminnich at lanl.gov (Ronald G Minnich)
Date: Fri, 12 May 2006 10:34:37 -0600
Subject: [LinuxBIOS] LB vs Factory BIOS -- more weirdness
In-Reply-To: <44636B9A.5000108@zyxod.com>
References: <445C4C04.6090302@zyxod.com> <44622CE9.2020200@lanl.gov>
	<44636B9A.5000108@zyxod.com>
Message-ID: <4464B91D.1000206@lanl.gov>

Eric Poulsen wrote:
> I have done this -- It doesn't cause the problem.  I had the machine off 
> for two days with the PS unplugged (no aux power), and the power 
> connected disconnected from the MLB.  Booted just fine after that.   I 
> think whoever mentioned the CAS setting being too fast might be on the 
> right track, but it's weird that the factory BIOS fixes it (for a while).
> 
> 
> WRT DMA issue:
> 
> (I only booted using LB)
> 
> Also, last night, I _hammered_ the southbridge by copying 50M files on 
> the HD, FTPing 50Meg files, and Copying 100M files from usb stick to 
> HDA.  I ran this for several hours.  The CPU heatsink got pretty warm.  
> No crashes.  Previously, just copying from HDA to HDC would crash it, or 
> from USB >> HDA, regularly.
> 
> So I Power down, Reboot (LB again), restarted the HDA >> HDA copy and 
> the FTP.  Froze up within 10 minutes.
> 
> I'll re-run the tests tonight using the factory BIOS -- who knows what's 
> going to happen.
> 


There's a good chance that factory bios is bug-fixing another part and 
getting the programming via flash settings. This is commonly done in 
factory bioses. This is another part of our life that is made hard by 
proprietary bug-fix code.

ron



From smithbone at gmail.com  Fri May 12 18:51:29 2006
From: smithbone at gmail.com (Richard Smith)
Date: Fri, 12 May 2006 11:51:29 -0500
Subject: [LinuxBIOS] Is VGABIOS_START still used?
In-Reply-To: <4464B433.6070906@waye.co.uk>
References: <4464B433.6070906@waye.co.uk>
Message-ID: <8a0c36780605120951v4eaec4f1x15e68d635e879977@mail.gmail.com>

On 5/12/06, scott <scott at waye.co.uk> wrote:
> http://www.linuxbios.org/data/lbdoc/lb-5.html
>
> On this page about the EPIA-M it mentions setting VGABIOS_START, so I
> tried to do that in my Config.lb, but I get this:
>
> Will place Makefile, crt0.S, etc. in via/epia-m/epia-m
> ===> ERROR: Attempt to set nonexistent option VGABIOS_START (missing USES?)
> via/epia-m/Config.lb:0
>

The via epia video stuff dosen't work with the emulator.  So it was
reverted back to the orginal V1 method of dropping back to 16-bit real
mode and jumping to the bios by Nick Barker.  Its all done in the
motherboard specific files so as to not complicated the biosemu suff.

So all the docs in the wiki may not match reality for the epia VGA.

I've not looked at the code so I can't help you much.  Please read
HOWTO/EPIA-M-howto and see if it answers your questions.  Otherwise
you will just have to look at the source code.

Sorry.


INITINCLUDE, INITOBJECT, LDSCRIPT, MAINBOARDINIT, MAKEDEFINE, MAKERULE,
OBJECT, CHIP, REGISTER, DEVICE on line 7:
 >  uses VGABIOS_START
 >  ^
List of nearby tokens:

The 'uses' lines have to go in the 'Options.lb' file in the mainboard
directory not in the target config.

-- 
Richard A. Smith



From chris at suehsi.de  Fri May 12 18:06:21 2006
From: chris at suehsi.de (=?UTF-8?B?Q2hyaXN0aWFuIFPDvGhz?=)
Date: Fri, 12 May 2006 18:06:21 +0200
Subject: [LinuxBIOS] MB1030 / 3036 VGA resume
In-Reply-To: <20060511144032.GA17661@coresystems.de>
References: <8a0c36780605091955s6fe971eap8369ed9ff8532fb1@mail.gmail.com>	<4461A546.3060504@suehsi.de>	<8a0c36780605100418o1eced8cdr6642561e93ad3aa0@mail.gmail.com>	<44621D0E.70205@suehsi.de>	<8a0c36780605101253p5542bf6dpcd9c711e563f8020@mail.gmail.com>	<4462E519.90101@suehsi.de>
	<4463335A.3080308@suehsi.de>	<20060511135154.GA14964@coresystems.de>	<44633D36.5080009@suehsi.de>
	<44634225.1000709@suehsi.de>
	<20060511144032.GA17661@coresystems.de>
Message-ID: <4464B27D.2010004@suehsi.de>

Stefan Reinauer schrieb:
> * Christian S?hs <chris at suehsi.de> [060511 15:54]:
> 
>>It seems, I have to write my own entry16.inc code for the gx1.
>>The default entry16.inc should enable the cache for example, but there 
>>are written false values to the cr0 register.
> 
>  
> no. very very unlikely. Just write the correct values in auto.c is
> enough.
>  

Ok, ok ;)

now I have start with own folders for allwell/stb3036 under targets and 
mainboard.

Is there  a recommended way to use/call own functions/files under LB.

Because, I have to had change settings for the cpu/amd/model_gx1 and others.
You know, enabling the cache and so on.

But I think i.e enabling memory segments for vga support and so on is a 
good think for everybody :D

What about the emu support, is this rewritten to use any RAM?

>
>>Is it posible to remove the line from the Config.lb for the fpu?
> 
> 
> Possibly possible, if the gx1 does all that.. But this will not take
> more than a couple cycles, so the difference in size and time is not
> measurable without quite some effort.
> 

Yup ;)

chris




From paul.collomb1 at libertysurf.fr  Fri May 12 19:39:54 2006
From: paul.collomb1 at libertysurf.fr (=?iso-8859-1?Q?paul.collomb1@libertysurf.fr?=)
Date: Fri, 12 May 2006 19:39:54 +0200
Subject: [LinuxBIOS]
	=?iso-8859-1?q?Asrock_mobo_with_SiS_chipset_=28Marcel?=
	=?iso-8859-1?q?o_Coelho=29?=
Message-ID: <IZ5YEI$6D26C7A1008B10B4ECAA907AC8DFA03E@aliceadsl.fr>

Hi Marcelo,
your project enthousiasm me. I am not a programmer but difficulties don't 
afraid me. If you can obtain support for this project by LB community I will 
buy rapidely the same mobo and I will work with you .
Best regards.

-----------------------------------------------------------------------------------------------------------
Marcelo wrote:

I have an Asrock k7s41 motherboard, with a notebook cpu. I'm willing
to test linuxbios in it. Does anyone has linuxbios working with the
SiS chipset? This motherboard has lan, audio and vga onboard.



-------------- ALICE HAUT DEBIT : TRIPLE PLAY A 29,95 EUR/MOIS -------------- 
D?couvrez vite ALICEBOX : avec le modem WIFI, profitez de l'ADSL, de la TELEPHONIE et en exclusivit? de la TELEVISION ! 
B?n?ficiez aussi de la hotline gratuite 24h/24 ! Soumis ? conditions. Pour en profiter cliquez ici http://abonnement.aliceadsl.fr







From smithbone at gmail.com  Fri May 12 20:19:07 2006
From: smithbone at gmail.com (Richard Smith)
Date: Fri, 12 May 2006 13:19:07 -0500
Subject: [LinuxBIOS] MB1030 / 3036 VGA resume
In-Reply-To: <4464B27D.2010004@suehsi.de>
References: <8a0c36780605091955s6fe971eap8369ed9ff8532fb1@mail.gmail.com>
	<44621D0E.70205@suehsi.de>
	<8a0c36780605101253p5542bf6dpcd9c711e563f8020@mail.gmail.com>
	<4462E519.90101@suehsi.de> <4463335A.3080308@suehsi.de>
	<20060511135154.GA14964@coresystems.de> <44633D36.5080009@suehsi.de>
	<44634225.1000709@suehsi.de> <20060511144032.GA17661@coresystems.de>
	<4464B27D.2010004@suehsi.de>
Message-ID: <8a0c36780605121119w21c60f0bg9b14e0299aabcfe6@mail.gmail.com>

> now I have start with own folders for allwell/stb3036 under targets and
> mainboard.
>
> Is there  a recommended way to use/call own functions/files under LB.

I don't really understand what you are trying to do?

> Because, I have to had change settings for the cpu/amd/model_gx1 and others.
> You know, enabling the cache and so on.

That was just a hack.  What really need to happen is to figure out how
to make the northbridge code properly call initialize_cpus().

> But I think i.e enabling memory segments for vga support and so on is a
> good think for everybody :D

Not really. The cluster people don't care about VGA.

> What about the emu support, is this rewritten to use any RAM?

I've not seen any commit for this.  Ron did you talk to ollie on this?

-- 
Richard A. Smith



From smithbone at gmail.com  Fri May 12 20:29:21 2006
From: smithbone at gmail.com (Richard Smith)
Date: Fri, 12 May 2006 13:29:21 -0500
Subject: [LinuxBIOS] Asrock mobo with SiS chipset (Marcelo Coelho)
In-Reply-To: <IZ5YEI$6D26C7A1008B10B4ECAA907AC8DFA03E@aliceadsl.fr>
References: <IZ5YEI$6D26C7A1008B10B4ECAA907AC8DFA03E@aliceadsl.fr>
Message-ID: <8a0c36780605121129m3753cbf0obe8988e1ea3c01d1@mail.gmail.com>

On 5/12/06, paul.collomb1 at libertysurf.fr <paul.collomb1 at libertysurf.fr> wrote:

> Hi Marcelo,
> your project enthousiasm me. I am not a programmer but difficulties don't
> afraid me. If you can obtain support for this project by LB community I will
> buy rapidely the same mobo and I will work with you .

The core question is do you have the datasheets?  If you don't have
the datasheets then you have a really rough road ahead.

Notebooks are problematic since they are usually very custom.

-- 
Richard A. Smith



From ward at gnu.org  Fri May 12 22:17:24 2006
From: ward at gnu.org (Ward Vandewege)
Date: Fri, 12 May 2006 16:17:24 -0400
Subject: [LinuxBIOS] VGA (Tyan s2881)
Message-ID: <20060512201724.GA22270@localdomain>

Hi all,

I'm trying to get VGA working on the Tyan s2881. 

I've extracted a 32KB VGA rom image while running under the proprietary BIOS.
It looks all right: it starts with 55 AA, has ATI strings in it, and it stops
just before the next option rom starts with 55 AA.

I've enabled

  #VGA Console
  default CONFIG_CONSOLE_VGA=1
  default CONFIG_PCI_ROM_RUN=1

in src/mainboard/tyan/s2881/Options.lb

I've modified the ROM_SIZE in targets/tyan/s2881/Config.lb:

  option ROM_SIZE = 491520

I've appended the linuxbios rom to the vgabios, and burned that image.

It boots fine, but no VGA output.

I've verified the contents of the video memory after booting:

  dd if=/dev/mem of=vga.bios bs=1 count=32768 skip=786432

The memory area is identical to the vga bios image I extracted.

I've attached the boot log. It sees the VGA device, and it says it copies the
ROM image to 0xc0000, all 0x8000 bytes of it.

I wonder about this halt_sys line:

...
copying VGA ROM Image from 0xfff80000 to 0xc0000, 0x8000 bytes
entering emulator
halt_sys: file
  /personal/projects/gnu/chimera/linuxbios/lbv2/rev-latest/LinuxBIOSv2/src/devices/emulator/x86emu/ops.c,
  line 4387
PCI: 01:04.0 init
...

I feel like I'm missing something pretty obvious here. Suggestions?

I also wonder why it's _always_ booting the fallback image. I have the same
payload for primary and fallback for now. Is this because there is 'dirty'
CMOS data?

Thanks,
Ward.

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



From ward at gnu.org  Fri May 12 22:19:09 2006
From: ward at gnu.org (Ward Vandewege)
Date: Fri, 12 May 2006 16:19:09 -0400
Subject: [LinuxBIOS] VGA (Tyan s2881)
Message-ID: <20060512201909.GB22270@localdomain>

(forgot attachment, sorry)

Hi all,

I'm trying to get VGA working on the Tyan s2881. 

I've extracted a 32KB VGA rom image while running under the proprietary BIOS.
It looks all right: it starts with 55 AA, has ATI strings in it, and it stops
just before the next option rom starts with 55 AA.

I've enabled

  #VGA Console
  default CONFIG_CONSOLE_VGA=1
  default CONFIG_PCI_ROM_RUN=1

in src/mainboard/tyan/s2881/Options.lb

I've modified the ROM_SIZE in targets/tyan/s2881/Config.lb:

  option ROM_SIZE = 491520

I've appended the linuxbios rom to the vgabios, and burned that image.

It boots fine, but no VGA output.

I've verified the contents of the video memory after booting:

  dd if=/dev/mem of=vga.bios bs=1 count=32768 skip=786432

The memory area is identical to the vga bios image I extracted.

I've attached the boot log. It sees the VGA device, and it says it copies the
ROM image to 0xc0000, all 0x8000 bytes of it.

I wonder about this halt_sys line:

...
copying VGA ROM Image from 0xfff80000 to 0xc0000, 0x8000 bytes
entering emulator
halt_sys: file
  /personal/projects/gnu/chimera/linuxbios/lbv2/rev-latest/LinuxBIOSv2/src/devices/emulator/x86emu/ops.c,
  line 4387
PCI: 01:04.0 init
...

I feel like I'm missing something pretty obvious here. Suggestions?

I also wonder why it's _always_ booting the fallback image. I have the same
payload for primary and fallback for now. Is this because there is 'dirty'
CMOS data?

Thanks,
Ward.

-- 
Ward Vandewege <ward at fsf.org>
Free Software Foundation - Senior System Administrator
-------------- next part --------------
LinuxBIOS-1.1.8_s2881_Fallback Fri May 12 10:49:19 EDT 2006 starting...
(0,1) link=00
(1,0) link=00
02 nodes initialized.
SBLink=02
NC node|link=02
ht reset -


LinuxBIOS-1.1.8_s2881_Fallback Fri May 12 10:49:19 EDT 2006 starting...
(0,1) link=00
(1,0) link=00
02 nodes initialized.
SBLink=02
NC node|link=02
Ram1.00
Ram1.01
Ram2.00
Ram2.01
Ram3
Initializing memory:  done
Initializing memory:  done
Ram4
v_esp=000cfd64
testx = 5a5a5a5a
Copying data from cache to ram -- switching to use ram as stack... Done
testx = 5a5a5a5a
Disabling cache as ram now 
Clearing initial memory region: Done
Copying LinuxBIOS to ram.
src=fffe0000
dst=00004000
linxbios_ram.bin   length = 00022fb0
Jumping to LinuxBIOS.
LinuxBIOS-1.1.8_s2881_Fallback Fri May 12 10:49:19 EDT 2006 booting...
Enumerating buses...
APIC_CLUSTER: 0 enabled
PCI_DOMAIN: 0000 enabled
  PCI: 00:18.3 siblings=1
CPU: APIC: 00 enabled
CPU: APIC: 01 enabled
PCI: 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=1
CPU: APIC: 02 enabled
CPU: APIC: 03 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: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: pci_scan_bus for bus 3
PCI: pci_scan_bus returning with max=03
PCI: 03: 133MHz PCI-X
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 1c <- [0x00fffff000 - 0x00ffffefff] bus 2 io
PCI: 01:01.0 24 <- [0xfffffffffff00000 - 0xffffffffffefffff] bus 2 prefmem
PCI: 01:03.0 24 <- [0x00fff00000 - 0x00ffefffff] bus 4 prefmem
Done reading resources.
Allocating VGA resource PCI: 04:06.0
Setting PCI_BRIDGE_CTL_VGA for bridge PCI: 01:03.0
Setting PCI_BRIDGE_CTL_VGA for bridge PCI: 00:18.0
Setting PCI_BRIDGE_CTL_VGA for bridge PCI_DOMAIN: 0000
Setting PCI_BRIDGE_CTL_VGA for bridge Root Device
Setting resources...
VGA: PCI: 00:18.0 (aka node 0) link 2 has VGA device
PCI: 00:18.0 1ba <- [0x00fd300000 - 0x00fd2fffff] prefmem <node 0 link 2>
PCI: 00:18.0 1c2 <- [0x0000001000 - 0x0000002fff] io <node 0 link 2>
PCI: 00:18.0 1b2 <- [0x00fc000000 - 0x00fd2fffff] mem <node 0 link 2>
PCI: 01:01.0 20 <- [0x00fd100000 - 0x00fd1fffff] bus 2 mem
PCI: 02:09.0 10 <- [0x00fd100000 - 0x00fd10ffff] mem64
PCI: 02:09.0 18 <- [0x00fd110000 - 0x00fd11ffff] mem64
PCI: 02:09.1 10 <- [0x00fd120000 - 0x00fd12ffff] mem64
PCI: 02:09.1 18 <- [0x00fd130000 - 0x00fd13ffff] mem64
PCI: 01:01.1 10 <- [0x00fd200000 - 0x00fd200fff] mem64
PCI: 01:02.1 10 <- [0x00fd201000 - 0x00fd201fff] mem64
PCI: 01:03.0 1c <- [0x0000001000 - 0x0000001fff] bus 4 io
PCI: 01:03.0 20 <- [0x00fc000000 - 0x00fd0fffff] bus 4 mem
PCI: 04:00.0 10 <- [0x00fd000000 - 0x00fd000fff] mem
PCI: 04:00.1 10 <- [0x00fd001000 - 0x00fd001fff] mem
PCI: 04:05.0 10 <- [0x0000001410 - 0x0000001417] io
PCI: 04:05.0 14 <- [0x0000001430 - 0x0000001433] io
PCI: 04:05.0 18 <- [0x0000001420 - 0x0000001427] io
PCI: 04:05.0 1c <- [0x0000001440 - 0x0000001443] io
PCI: 04:05.0 20 <- [0x0000001400 - 0x000000140f] io
PCI: 04:05.0 24 <- [0x00fd003000 - 0x00fd0033ff] mem
PCI: 04:06.0 10 <- [0x00fc000000 - 0x00fcffffff] mem
PCI: 04:06.0 14 <- [0x0000001000 - 0x00000010ff] io
PCI: 04:06.0 18 <- [0x00fd002000 - 0x00fd002fff] 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 <- [0x0000002420 - 0x000000242f] io
PCI: 01:04.2 10 <- [0x0000002400 - 0x000000241f] io
PCI: 01:04.3 58 <- [0x0000002000 - 0x00000020ff] io
PCI: 00:18.3 94 <- [0x00f8000000 - 0x00fbffffff] mem <gart>
PCI: 00:19.3 94 <- [0x00f8000000 - 0x00fbffffff] mem <gart>
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 <- 146
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.1 subsystem <- 10f1/2881
PCI: 01:02.1 cmd <- 146
PCI: 01:03.0 bridge ctrl <- 000b
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 20f12
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
DONE variable MTRRs
Clear out the extra MTRR's

MTRR check
Fixed MTRRs   : Enabled
Variable MTRRs: Enabled

microcode: equivalent processor rev id  = 0x0210, patch id = 0x00000000
microcode: patch id that want to apply= 0x0000004d
microcode: updated to patch id = 0x0000004d  success
Setting up local apic... apic_id: 0 done.
Clearing memory 2048K - 1048576K: --------------- done
CPU #0 Initialized
start_eip=0x00018000
Initializing CPU #1
CPU: vendor AMD device 20f12
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
DONE variable MTRRs
Clear out the extra MTRR's

MTRR check
Fixed MTRRs   : Enabled
Variable MTRRs: Enabled

microcode: equivalent processor rev id  = 0x0210, patch id = 0x00000000
microcode: patch id that want to apply= 0x0000004d
microcode: updated to patch id = 0x0000004d  success
Setting up local apic... apic_id: 1 done.
CPU #1 Initialized
start_eip=0x00018000
Initializing CPU #2
CPU: vendor AMD device 20f12
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
DONE variable MTRRs
Clear out the extra MTRR's

MTRR check
Fixed MTRRs   : Enabled
Variable MTRRs: Enabled

microcode: equivalent processor rev id  = 0x0210, patch id = 0x00000000
microcode: patch id that want to apply= 0x0000004d
microcode: updated to patch id = 0x0000004d  success
Setting up local apic... apic_id: 2 done.
Clearing memory 1048576K - 2097152K: ---------------- done
CPU #2 Initialized
start_eip=0x00018000
Initializing CPU #3
Waiting for 1 CPUS to stop
CPU: vendor AMD device 20f12
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
DONE variable MTRRs
Clear out the extra MTRR's

MTRR check
Fixed MTRRs   : Enabled
Variable MTRRs: Enabled

microcode: equivalent processor rev id  = 0x0210, patch id = 0x00000000
microcode: patch id that want to apply= 0x0000004d
microcode: updated to patch id = 0x0000004d  success
Setting up local apic... apic_id: 3 done.
CPU #3 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:03.0 init
PCI: 04:05.0 init
PCI: 04:06.0 init
rom address for PCI: 04:06.0 = fff80000
copying VGA ROM Image from 0xfff80000 to 0xc0000, 0x8000 bytes
entering emulator
halt_sys: file /personal/projects/gnu/chimera/linuxbios/lbv2/rev-latest/LinuxBIOSv2/src/devices/emulator/x86emu/ops.c, line 4387
PCI: 01:04.0 init
amd8111: ioapic bsp_apicid = 00
RTC Init
Invalid CMOS LB checksum
enabling HPET @0xfed00000
PNP: 002e.0 init
PNP: 002e.2 init
PNP: 002e.5 init
PNP: 002e.b init
PCI: 01: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.
Devices initialized
Writing IRQ routing tables to 0xf0000...done.
Wrote the mp table end at: 00000020 - 000001f4
Moving GDT to 0x500...ok
Wrote linuxbios table at: 00000530 - 00000df8  checksum ee73

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

rom_stream: 0xfffc0000 - 0xfffdffff
Found ELF candiate at offset 0
New segment addr 0x100000 size 0x3fd40 offset 0xc0 filesize 0x15f88
(cleaned up) New segment addr 0x100000 size 0x3fd40 offset 0xc0 filesize 0x15f88
New segment addr 0x13fd40 size 0x48 offset 0x16060 filesize 0x48
(cleaned up) New segment addr 0x13fd40 size 0x48 offset 0x16060 filesize 0x48
Dropping non PT_LOAD segment
Dropping non PT_LOAD segment
Loading Segment: addr: 0x0000000000100000 memsz: 0x000000000003fd40 filesz: 0x0000000000015f88
Clearing Segment: addr: 0x0000000000115f88 memsz: 0x0000000000029db8
Loading Segment: addr: 0x000000000013fd40 memsz: 0x0000000000000048 filesz: 0x0000000000000048
Jumping to boot code at 0x10f5d8
FILO version 0.5 (root at countzero) Fri May 12 10:16:22 EDT 2006
collect_sys_info: boot eax = 0xe1fb007
collect_sys_info: boot ebx = 0x7ffefe20
collect_sys_info: boot arg = 0x7ffefe20
malloc_diag: alloc: 0 bytes (0 blocks), free: 16376 bytes (1 blocks)
malloc_diag: alloc: 24 bytes (1 blocks), free: 16352 bytes (1 blocks)
collect_elfboot_info: Bootloader: elfboot
collect_elfboot_info: Version: 1.3
malloc_diag: alloc: 40 bytes (2 blocks), free: 16336 bytes (1 blocks)
collect_linuxbios_info: Searching for LinuxBIOS tables...
find_lb_table: Found canidate at: 00000530
find_lb_table: header checksum o.k.
find_lb_table: table checksum o.k.
find_lb_table: record count o.k.
collect_linuxbios_info: Found LinuxBIOS table at: 00000530
malloc_diag: alloc: 144 bytes (3 blocks), free: 16232 bytes (1 blocks)
convert_memmap: 0x00000000000000 0x00000000000e64 16
convert_memmap: 0x00000000000e64 0x0000000009f19c 1
convert_memmap: 0x000000000c0000 0x00000000030000 1
convert_memmap: 0x000000000f0000 0x00000000000400 16
convert_memmap: 0x000000000f0400 0x0000003ff0fc00 1
convert_memmap: 0x00000040000000 0x00000040000000 1
collect_sys_info: 0000000000000e64-00000000000a0000
collect_sys_info: 00000000000c0000-00000000000f0000
collect_sys_info: 00000000000f0400-0000000040000000
collect_sys_info: 0000000040000000-0000000080000000
collect_sys_info: RAM 2048 MB
relocate: Current location: 0x100000-0x13fd87
relocate: Relocating to 0x7ffc0270-0x7ffffff7... ok
setup_timers: CPU 1993 MHz
pci_init: Scanning PCI: found 23 devices
malloc_diag: alloc: 432 bytes (4 blocks), free: 15944 bytes (1 blocks)
pci_init: 00:18.0 1022:1100 0600 00
pci_init: 00:18.1 1022:1101 0600 00
pci_init: 00:18.2 1022:1102 0600 00
pci_init: 00:18.3 1022:1103 0600 00
pci_init: 00:19.0 1022:1100 0600 00
pci_init: 00:19.1 1022:1101 0600 00
pci_init: 00:19.2 1022:1102 0600 00
pci_init: 00:19.3 1022:1103 0600 00
pci_init: 01:01.0 1022:7450 0604 00
pci_init: 01:01.1 1022:7451 0800 10
pci_init: 01:02.0 1022:7450 0604 00
pci_init: 01:02.1 1022:7451 0800 10
pci_init: 01:03.0 1022:7460 0604 00
pci_init: 01:04.0 1022:7468 0601 00
pci_init: 01:04.1 1022:7469 0101 8a
pci_init: 01:04.2 1022:746a 0c05 00
pci_init: 01:04.3 1022:746b 0680 00
pci_init: 02:09.0 14e4:1648 0200 00
pci_init: 02:09.1 14e4:1648 0200 00
pci_init: 04:00.0 1022:7464 0c03 10
pci_init: 04:00.1 1022:7464 0c03 10
pci_init: 04:05.0 1095:3114 0180 00
pci_init: 04:06.0 1002:4752 0300 00
malloc_diag: alloc: 448 bytes (5 blocks), free: 15928 bytes (1 blocks)
file_open: dev=hda1, path=/grub/menu.lst
find_ide_controller: found PCI IDE controller 1095:3114 prog_if=0x0
find_ide_controller: primary channel: native PCI mode
find_ide_controller: cmd_base=0x1410 ctrl_base=0x1430
ide_software_reset: Waiting for ide0 to become ready for reset... ok
init_drive: Testing for hda
init_drive: Probing for hda
init_drive: LBA mode, sectors=145226112
init_drive: LBA48 mode, sectors=145226112
init_drive: Init device params... ok
hda: LBA48 74GB: WDC WD740GD-00FLC0                      
init_drive: Testing for hdb
init_drive: Probing for hdb
init_drive: LBA mode, sectors=145226112
init_drive: LBA48 mode, sectors=145226112
init_drive: Init device params... ok
hdb: LBA48 74GB: WDC WD740GD-00FLC0                      
devopen: Partition 1 start 63 length 128457
Mounted ext2fs
malloc_diag: alloc: 432 bytes (4 blocks), free: 15944 bytes (1 blocks)
Press `ESC' to enter the menu... 2   Press `ESC' to enter the menu... 1   Press `ESC' to enter the menu... 0     Booting 'Ubuntu, kernel 2.6.16.2 '

root  (hd0,0)
kernel  /vmlinuz-2.6.16.2 root=/dev/md3 ro quiet splash console=tty0 console=tt
yS0,115200"
boot

Booting 'hda1:/vmlinuz-2.6.16.2 root=/dev/md3 ro quiet splash console=tty0 cons
ole=ttyS0,115200"'
malloc_diag: alloc: 528 bytes (5 blocks), free: 15848 bytes (1 blocks)
malloc_diag: alloc: 544 bytes (6 blocks), free: 15832 bytes (1 blocks)
file_open: dev=hda1, path=/vmlinuz-2.6.16.2
devopen: already open
malloc_diag: alloc: 528 bytes (5 blocks), free: 15848 bytes (1 blocks)
elf_load: Not a bootable ELF image
malloc_diag: alloc: 544 bytes (6 blocks), free: 15832 bytes (1 blocks)
file_open: dev=hda1, path=/vmlinuz-2.6.16.2
devopen: already open
malloc_diag: alloc: 528 bytes (5 blocks), free: 15848 bytes (1 blocks)
Found Linux version 2.6.16.2 (root at chimera.gnu.org) #3 SMP Thu Apr 20 13:49:15 EDT 2006 (protocol 0x204) (loadflags 0x1) bzImage.
init_linux_params: Setting up paramters at 0x90000
set_memory_size: 0000000000000e64 - 00000000000a0000
set_memory_size: 00000000000c0000 - 00000000000f0000
set_memory_size: 00000000000f0400 - 0000000040000000
set_memory_size: 0000000040000000 - 0000000080000000
set_memory_size: ramtop=0x80000000
set_memory_size: ext_mem_k=64512, alt_mem_k=2096128
parse_command_line: original command line: "root=/dev/md3 ro quiet splash console=tty0 console=ttyS0,115200""
parse_command_line: kernel command line at 0x91000
parse_command_line: kernel command line (64 bytes): "root=/dev/md3 ro quiet splash console=tty0 console=ttyS0,115200""
load_linux_kernel: offset=0x1600 addr=0x100000 size=0x1bd561
Loading kernel... ok
start_linux: eip=0x100000
Jumping to entry point...
ACPI: Unable to locate RSDP
 * Starting RAID devices...        [ ok ]
 * Starting hardware event daemon...        [ ok ]
 * Mounting a tmpfs over /dev...        [ ok ]
 * Creating initial device nodes...        [ ok ]
 * Setting disc parameters...        [ ok ]
 * Checking root file system...        /: clean, 2752626/25378816 files, 47173325/50743248 blocks
[ ok ]
 * Initializing modules...        [ ok ]
 * Cleaning up ifupdown...        [ ok ]
 * Setting the system clock...        [ ok ]
 * Setting up LVM Volume Groups...        [ ok ]
 * Checking all file systems...        /boot: clean, 41/32064 files, 32823/64128 blocks
/tmp: clean, 13/732960 files, 55827/1463856 blocks
[ ok ]
 * Mounting local filesystems...        /dev/md0 on /boot type ext3 (rw)
/dev/md1 on /tmp type ext3 (rw)
[ ok ]
 * Setting sensors limits...        [ ok ]
 * Restoring resolver state...        [ ok ]
 * Setting up networking...        [ ok ]
 * Starting hotplug subsystem...        [ ok ]
 * Configuring network interfaces...        [ ok ]
 * Waiting for network interface to come up...        [ ok ]
Loading the saved-state of the serial devices... 
/dev/ttyS0 at 0x03f8 (irq = 4) is a 16550A
/dev/ttyS1 at 0x02f8 (irq = 3) is a 16550A
 * Setting up ALSA...        [ ok ]
 * Setting the system clock...        [ ok ]
 * Synchronizing clock to ntp.ubuntulinux.org...        [ ok ]
 * Initializing random number generator...        [ ok ]
 * Entering runlevel: 2
 * Starting system log daemon...        [ ok ]
 * Starting kernel log daemon...        [ ok ]
Starting amavisd: head: cannot open `/etc/mailname' for reading: No such file or directory
amavisd-new.
 * Starting OpenBSD Secure Shell server...        [ ok ]
Setting sysfs variables...done.
sadc not enabled in /etc/default/sysstat, not starting.
 * Starting RAID monitoring services...        [ ok ]
 * Starting deferred execution scheduler...        [ ok ]
 * Starting periodic command scheduler...        [ ok ]
 * Id "T0" respawning too fast: disabled for 5 minutes

From yinghai.lu at amd.com  Fri May 12 22:36:41 2006
From: yinghai.lu at amd.com (Lu, Yinghai)
Date: Fri, 12 May 2006 13:36:41 -0700
Subject: [LinuxBIOS] VGA (Tyan s2881)
Message-ID: <6F7DA19D05F3CF40B890C7CA2DB13A4203094C93@ssvlexmb2.amd.com>

It should be 36k...

YH

-----Original Message-----
From: linuxbios-bounces at linuxbios.org
[mailto:linuxbios-bounces at linuxbios.org] On Behalf Of Ward Vandewege
Sent: Friday, May 12, 2006 1:19 PM
To: linuxbios at linuxbios.org
Subject: [LinuxBIOS] VGA (Tyan s2881)

(forgot attachment, sorry)

Hi all,

I'm trying to get VGA working on the Tyan s2881. 

I've extracted a 32KB VGA rom image while running under the proprietary
BIOS.
It looks all right: it starts with 55 AA, has ATI strings in it, and it
stops
just before the next option rom starts with 55 AA.

I've enabled

  #VGA Console
  default CONFIG_CONSOLE_VGA=1
  default CONFIG_PCI_ROM_RUN=1

in src/mainboard/tyan/s2881/Options.lb

I've modified the ROM_SIZE in targets/tyan/s2881/Config.lb:

  option ROM_SIZE = 491520

I've appended the linuxbios rom to the vgabios, and burned that image.

It boots fine, but no VGA output.

I've verified the contents of the video memory after booting:

  dd if=/dev/mem of=vga.bios bs=1 count=32768 skip=786432

The memory area is identical to the vga bios image I extracted.

I've attached the boot log. It sees the VGA device, and it says it
copies the
ROM image to 0xc0000, all 0x8000 bytes of it.

I wonder about this halt_sys line:

...
copying VGA ROM Image from 0xfff80000 to 0xc0000, 0x8000 bytes
entering emulator
halt_sys: file
 
/personal/projects/gnu/chimera/linuxbios/lbv2/rev-latest/LinuxBIOSv2/src
/devices/emulator/x86emu/ops.c,
  line 4387
PCI: 01:04.0 init
...

I feel like I'm missing something pretty obvious here. Suggestions?

I also wonder why it's _always_ booting the fallback image. I have the
same
payload for primary and fallback for now. Is this because there is
'dirty'
CMOS data?

Thanks,
Ward.

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




From ward at gnu.org  Fri May 12 22:44:43 2006
From: ward at gnu.org (Ward Vandewege)
Date: Fri, 12 May 2006 16:44:43 -0400
Subject: [LinuxBIOS] VGA (Tyan s2881)
In-Reply-To: <6F7DA19D05F3CF40B890C7CA2DB13A4203094C93@ssvlexmb2.amd.com>
References: <6F7DA19D05F3CF40B890C7CA2DB13A4203094C93@ssvlexmb2.amd.com>
Message-ID: <20060512204443.GA22560@localdomain>

On Fri, May 12, 2006 at 01:36:41PM -0700, Lu, Yinghai wrote:
> It should be 36k...

I saw that somewhere - the last 4k is the bios for the onboard sata
controller though?

Ward.

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



From yinghai.lu at amd.com  Fri May 12 22:49:43 2006
From: yinghai.lu at amd.com (Lu, Yinghai)
Date: Fri, 12 May 2006 13:49:43 -0700
Subject: [LinuxBIOS] VGA (Tyan s2881)
Message-ID: <6F7DA19D05F3CF40B890C7CA2DB13A4203094C94@ssvlexmb2.amd.com>

BIOS engineer give the option rom (36k) and I dd that to 48k.

YH

-----Original Message-----
From: Ward Vandewege [mailto:ward at gnu.org] 
Sent: Friday, May 12, 2006 1:45 PM
To: Lu, Yinghai
Cc: linuxbios at linuxbios.org
Subject: Re: [LinuxBIOS] VGA (Tyan s2881)

On Fri, May 12, 2006 at 01:36:41PM -0700, Lu, Yinghai wrote:
> It should be 36k...

I saw that somewhere - the last 4k is the bios for the onboard sata
controller though?

Ward.

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





From hidi at e-tiger.net  Fri May 12 22:49:40 2006
From: hidi at e-tiger.net (Hidasi Jozsef)
Date: Fri, 12 May 2006 22:49:40 +0200
Subject: [LinuxBIOS] VGA (Tyan s2881)
In-Reply-To: <6F7DA19D05F3CF40B890C7CA2DB13A4203094C93@ssvlexmb2.amd.com>
References: <6F7DA19D05F3CF40B890C7CA2DB13A4203094C93@ssvlexmb2.amd.com>
Message-ID: <1662177765.20060512224940@e-tiger.net>

Try to dump it from the original BIOS use AMITOOL or whatever BIOS
s2881 uses... s2882 uses AMI ;( sorry for it...



Friday, May 12, 2006, 10:36:41 PM, you wrote:

> It should be 36k...

> YH

> -----Original Message-----
> From: linuxbios-bounces at linuxbios.org
> [mailto:linuxbios-bounces at linuxbios.org] On Behalf Of Ward Vandewege
> Sent: Friday, May 12, 2006 1:19 PM
> To: linuxbios at linuxbios.org
> Subject: [LinuxBIOS] VGA (Tyan s2881)

> (forgot attachment, sorry)

> Hi all,

> I'm trying to get VGA working on the Tyan s2881. 

> I've extracted a 32KB VGA rom image while running under the proprietary
> BIOS.
> It looks all right: it starts with 55 AA, has ATI strings in it, and it
> stops
> just before the next option rom starts with 55 AA.

> I've enabled

>   #VGA Console
>   default CONFIG_CONSOLE_VGA=1
>   default CONFIG_PCI_ROM_RUN=1

> in src/mainboard/tyan/s2881/Options.lb

> I've modified the ROM_SIZE in targets/tyan/s2881/Config.lb:

>   option ROM_SIZE = 491520

> I've appended the linuxbios rom to the vgabios, and burned that image.

> It boots fine, but no VGA output.

> I've verified the contents of the video memory after booting:

>   dd if=/dev/mem of=vga.bios bs=1 count=32768 skip=786432

> The memory area is identical to the vga bios image I extracted.

> I've attached the boot log. It sees the VGA device, and it says it
> copies the
> ROM image to 0xc0000, all 0x8000 bytes of it.

> I wonder about this halt_sys line:

> ...
> copying VGA ROM Image from 0xfff80000 to 0xc0000, 0x8000 bytes
> entering emulator
> halt_sys: file
>  
> /personal/projects/gnu/chimera/linuxbios/lbv2/rev-latest/LinuxBIOSv2/src
> /devices/emulator/x86emu/ops.c,
>   line 4387
> PCI: 01:04.0 init
> ...

> I feel like I'm missing something pretty obvious here. Suggestions?

> I also wonder why it's _always_ booting the fallback image. I have the
> same
> payload for primary and fallback for now. Is this because there is
> 'dirty'
> CMOS data?

> Thanks,
> Ward.

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




-- 
Best regards,
 Hidasi
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 456 bytes
Desc: not available
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20060512/11adf75e/attachment.sig>

From hidi at e-tiger.net  Fri May 12 22:51:05 2006
From: hidi at e-tiger.net (Hidasi Jozsef)
Date: Fri, 12 May 2006 22:51:05 +0200
Subject: [LinuxBIOS] VGA (Tyan s2881)
In-Reply-To: <20060512204443.GA22560@localdomain>
References: <6F7DA19D05F3CF40B890C7CA2DB13A4203094C93@ssvlexmb2.amd.com>
	<20060512204443.GA22560@localdomain>
Message-ID: <717663530.20060512225105@e-tiger.net>

Hello Ward,

 You are true somewhy the last 4k is invisible or overmapped I don't
 know but the real bios size is 36k!

Friday, May 12, 2006, 10:44:43 PM, you wrote:

> On Fri, May 12, 2006 at 01:36:41PM -0700, Lu, Yinghai wrote:
>> It should be 36k...

> I saw that somewhere - the last 4k is the bios for the onboard sata
> controller though?

> Ward.

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



-- 
Best regards,
 Hidasi                            mailto:hidi at e-tiger.net
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 456 bytes
Desc: not available
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20060512/63a44eb3/attachment.sig>

From ward at gnu.org  Fri May 12 23:19:09 2006
From: ward at gnu.org (Ward Vandewege)
Date: Fri, 12 May 2006 17:19:09 -0400
Subject: [LinuxBIOS] VGA (Tyan s2881)
In-Reply-To: <6F7DA19D05F3CF40B890C7CA2DB13A4203094C94@ssvlexmb2.amd.com>
References: <6F7DA19D05F3CF40B890C7CA2DB13A4203094C94@ssvlexmb2.amd.com>
Message-ID: <20060512211909.GA25438@localdomain>

On Fri, May 12, 2006 at 01:49:43PM -0700, Lu, Yinghai wrote:
> BIOS engineer give the option rom (36k) and I dd that to 48k.

OK; I made a 48K image (using dd running the proprietary bios).

Still no VGA; it seems linuxbios only loads 32K of the image:

 ...
 rom address for PCI: 04:06.0 = fff80000
 copying VGA ROM Image from 0xfff80000 to 0xc0000, 0x8000 bytes
 entering emulator
 ...

?

Ward.

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



From ward at pong.be  Fri May 12 23:34:12 2006
From: ward at pong.be (Ward Vandewege)
Date: Fri, 12 May 2006 17:34:12 -0400
Subject: [LinuxBIOS] VGA (Tyan s2881)
In-Reply-To: <1662177765.20060512224940@e-tiger.net>
References: <6F7DA19D05F3CF40B890C7CA2DB13A4203094C93@ssvlexmb2.amd.com>
	<1662177765.20060512224940@e-tiger.net>
Message-ID: <20060512213412.GA25451@localdomain>

On Fri, May 12, 2006 at 10:49:40PM +0200, Hidasi Jozsef wrote:
> Try to dump it from the original BIOS use AMITOOL or whatever BIOS
> s2881 uses... s2882 uses AMI ;( sorry for it...

The s2881 is AMI too.

How would I dump it from the original BIOS? The images I have are all
compressed somehow.

I find 4 references to AMITOOL using google - none of them say where it can
be found. Where can I find it?

Ward.

-- 
Pong.be         -(  "Just wait,  My crystal ball is infallible." -- Linus  )-
Virtual hosting -( Torvalds, discussing the future of smart I/O hardware.  )-
http://pong.be  -(                                                         )-
GnuPG public key: http://gpg.dtype.org



From paul.collomb1 at libertysurf.fr  Sat May 13 02:54:19 2006
From: paul.collomb1 at libertysurf.fr (=?iso-8859-1?Q?paul.collomb1@libertysurf.fr?=)
Date: Sat, 13 May 2006 02:54:19 +0200
Subject: [LinuxBIOS] =?iso-8859-1?q?_Re=3A__Asrock_mobo_with_SiS_chipset_?=
	=?iso-8859-1?q?=28Richard_A=2E_Smith_=29?=
Message-ID: <IZ6IIJ$A0355C1AC80512284E7ED953BAF1F69E@aliceadsl.fr>

Richard A. Smith wrote:   
  
>The core question is do you have the datasheets?  If you don't have   
>the datasheets then you have a really rough road ahead.   
>Notebooks are problematic since they are usually very custom.   
   
What are these datasheets ? I don't understand. ( do you mean 
datasheets for linuxbios ? ) 
Notebook ? It is not a notebook, it's just a good price mobo ( 45 Euros ) 
Thanks 
   
   

-------------- ALICE HAUT DEBIT : TRIPLE PLAY A 29,95 EUR/MOIS -------------- 
D?couvrez vite ALICEBOX : avec le modem WIFI, profitez de l'ADSL, de la TELEPHONIE et en exclusivit? de la TELEVISION ! 
B?n?ficiez aussi de la hotline gratuite 24h/24 ! Soumis ? conditions. Pour en profiter cliquez ici http://abonnement.aliceadsl.fr







From bari at onelabs.com  Sat May 13 03:16:13 2006
From: bari at onelabs.com (Bari Ari)
Date: Fri, 12 May 2006 20:16:13 -0500
Subject: [LinuxBIOS] Asrock mobo with SiS chipset (Richard A. Smith )
In-Reply-To: <IZ6IIJ$A0355C1AC80512284E7ED953BAF1F69E@aliceadsl.fr>
References: <IZ6IIJ$A0355C1AC80512284E7ED953BAF1F69E@aliceadsl.fr>
Message-ID: <4465335D.2080407@onelabs.com>

paul.collomb1 at libertysurf.fr wrote:

> What are these datasheets ? I don't understand. ( do you mean 
> datasheets for linuxbios ? ) 
> Notebook ? It is not a notebook, it's just a good price mobo ( 45 Euros ) 

Datasheets for the chipset used on the motherboard. You'll need to know 
what vales to place into the config registers and also when and in what 
order to do so.

-Bari



From roger at eskimo.com  Sat May 13 04:12:12 2006
From: roger at eskimo.com (roger)
Date: Fri, 12 May 2006 19:12:12 -0700
Subject: [LinuxBIOS] Mcumall.com Email activity?
Message-ID: <1147486333.30706.2.camel@localhost3.localdomain>

I'm located within the US and am curious about www.mcumall.com email
activity.

Every email I have sent to mcumall.com domain has bounced back.

There is no phone number for customer support to check for authenticity
of this online shopping company.  And payments are processed through
Paypal.

Can anybody comment on the authenticity of this company?

I was curious about purchasing a "PRG-001 Enhanced Willem Universal
EPROM Programmer".

--
Roger
http://www.eskimo.com/~roger/index.html
Key fingerprint = 8977 A252 2623 F567 70CD 1261 640F C963 1005 1D61

Fri May 12 19:09:44 PDT 2006




From russ at ashlandhome.net  Sat May 13 07:13:58 2006
From: russ at ashlandhome.net (Russell Whitaker)
Date: Fri, 12 May 2006 22:13:58 -0700 (PDT)
Subject: [LinuxBIOS] Mcumall.com Email activity?
In-Reply-To: <1147486333.30706.2.camel@localhost3.localdomain>
References: <1147486333.30706.2.camel@localhost3.localdomain>
Message-ID: <Pine.LNX.4.63.0605122154500.5309@bigred.russwhit.org>



On Fri, 12 May 2006, roger wrote:

> I'm located within the US and am curious about www.mcumall.com email
> activity.
>
> Every email I have sent to mcumall.com domain has bounced back.
>
> There is no phone number for customer support to check for authenticity
> of this online shopping company.  And payments are processed through
> Paypal.
>
> Can anybody comment on the authenticity of this company?
>
> I was curious about purchasing a "PRG-001 Enhanced Willem Universal
> EPROM Programmer".

"whois" reports no match. Apparently their domain name registration
has expired. Got a page from google but no telling how old it is.

Found "www.willem.org", there is a link to their online store.
Could not find a "PRG-001". Suspect it's obsolete. You might take a
close look at a "4.1", it might be just what you're looking for.

   Russ



From chris at suehsi.de  Sat May 13 10:47:02 2006
From: chris at suehsi.de (=?ISO-8859-1?Q?Christian_S=FChs?=)
Date: Sat, 13 May 2006 10:47:02 +0200
Subject: [LinuxBIOS] MB1030 / 3036 VGA resume
In-Reply-To: <8a0c36780605121119w21c60f0bg9b14e0299aabcfe6@mail.gmail.com>
References: <8a0c36780605091955s6fe971eap8369ed9ff8532fb1@mail.gmail.com>	<44621D0E.70205@suehsi.de>	<8a0c36780605101253p5542bf6dpcd9c711e563f8020@mail.gmail.com>	<4462E519.90101@suehsi.de>
	<4463335A.3080308@suehsi.de>	<20060511135154.GA14964@coresystems.de>
	<44633D36.5080009@suehsi.de>	<44634225.1000709@suehsi.de>
	<20060511144032.GA17661@coresystems.de>	<4464B27D.2010004@suehsi.de>
	<8a0c36780605121119w21c60f0bg9b14e0299aabcfe6@mail.gmail.com>
Message-ID: <44659D06.7070205@suehsi.de>

Richard Smith schrieb:
>>now I have start with own folders for allwell/stb3036 under targets and
>>mainboard.
>>
>>Is there  a recommended way to use/call own functions/files under LB.
> 
> 
> I don't really understand what you are trying to do?
> 

Because of the differences to the eaglelion/5bcm I have create own 
folders for mainboard and target in the LB tree called allwell/stb3036 
and allwell/stb1036 also changed some files to get proper Vendor and ID 
strings. So now I can make a ./buildtarget under targets to get a image 
for that mobo.

> 
>>Because, I have to had change settings for the cpu/amd/model_gx1 and others.
>>You know, enabling the cache and so on.
> 
> 
> That was just a hack.  What really need to happen is to figure out how
> to make the northbridge code properly call initialize_cpus().

I'm not sure, if we need that. because the model_gx1_init.c does the 
same as the cpu_setup.inc in early state to initialize the cpu.

There is only the cache_enable stuff which is not called. but as I say 
it would be better to do that earlier. I think that also the LB copying 
to RAM is faster than.

Stefan talked about the auto.c, with the new own folders, that is the 
only file I can touch without to make changes in the standard trees.

> 
> 
>>But I think i.e enabling memory segments for vga support and so on is a
>>good think for everybody :D
> 
> 
> Not really. The cluster people don't care about VGA.

Well, with own Config.lb everybody can decide to enable vga or not.
I need a way, to change cpu registers for the gx1, that all people are 
happy. Currently you have to enable c0000 writeable/cacheable for vga 
support.

Means, if CONSOLE_VGA = 1 make changes to the CPU registers BC_XMAP_2 
and so on.

chris





From stepan at coresystems.de  Sat May 13 11:34:47 2006
From: stepan at coresystems.de (Stefan Reinauer)
Date: Sat, 13 May 2006 11:34:47 +0200
Subject: [LinuxBIOS] Mcumall.com Email activity?
In-Reply-To: <Pine.LNX.4.63.0605122154500.5309@bigred.russwhit.org>
References: <1147486333.30706.2.camel@localhost3.localdomain>
	<Pine.LNX.4.63.0605122154500.5309@bigred.russwhit.org>
Message-ID: <20060513093447.GB5103@coresystems.de>

* Russell Whitaker <russ at ashlandhome.net> [060513 07:13]:
> > I'm located within the US and am curious about www.mcumall.com email
> > activity.
 
> "whois" reports no match. Apparently their domain name registration
> has expired. Got a page from google but no telling how old it is.

whois works fine here. You have to use mcumall.com for the query though,
not www.mcumall.com..

Stefan




From paul.collomb1 at libertysurf.fr  Sat May 13 13:45:34 2006
From: paul.collomb1 at libertysurf.fr (=?iso-8859-1?Q?paul.collomb1@libertysurf.fr?=)
Date: Sat, 13 May 2006 13:45:34 +0200
Subject: [LinuxBIOS] =?iso-8859-1?q?_9=2E_Re=3A_Asrock_mobo_with_SiS_chips?=
	=?iso-8859-1?q?et_=28Richard_A=2E_Smith_=29_=28Bari_Ari=29?=
Message-ID: <IZ7CNY$9169AEAA4B07E97B591252973BE962CC@aliceadsl.fr>

Bari Ari wrote :  
>Datasheets for the chipset used on the motherboard. You'll need to know   
>what vales to place into the config registers and also when and in what   
>order to do so.  
  
Ok. I understand. I will take contact with VIA. 
Thanks  

-------------- ALICE HAUT DEBIT : TRIPLE PLAY A 29,95 EUR/MOIS -------------- 
D?couvrez vite ALICEBOX : avec le modem WIFI, profitez de l'ADSL, de la TELEPHONIE et en exclusivit? de la TELEVISION ! 
B?n?ficiez aussi de la hotline gratuite 24h/24 ! Soumis ? conditions. Pour en profiter cliquez ici http://abonnement.aliceadsl.fr







From paul.collomb1 at libertysurf.fr  Sat May 13 14:24:44 2006
From: paul.collomb1 at libertysurf.fr (=?iso-8859-1?Q?paul.collomb1@libertysurf.fr?=)
Date: Sat, 13 May 2006 14:24:44 +0200
Subject: [LinuxBIOS] =?iso-8859-1?q?_Re=3A_Asrock_mobo_with_SiS_chipset_?=
	=?iso-8859-1?q?=28Richard_A=2E_Smith_=29_=28Bari_Ari=29?=
Message-ID: <IZ7EH8$4B7D4165DCF90313C3D7EBD29B1A5E76@aliceadsl.fr>

Sorry, chipset manufacturer is SIS ..... 

-------------- ALICE HAUT DEBIT : TRIPLE PLAY A 29,95 EUR/MOIS -------------- 
D?couvrez vite ALICEBOX : avec le modem WIFI, profitez de l'ADSL, de la TELEPHONIE et en exclusivit? de la TELEVISION ! 
B?n?ficiez aussi de la hotline gratuite 24h/24 ! Soumis ? conditions. Pour en profiter cliquez ici http://abonnement.aliceadsl.fr







From jonathan at sprintmail.com  Sat May 13 16:59:26 2006
From: jonathan at sprintmail.com (Jonathan Sturges)
Date: Sat, 13 May 2006 10:59:26 -0400
Subject: [LinuxBIOS] Another Geode GX1: status & questions
Message-ID: <4465F44E.6060205@sprintmail.com>

Hi,
I'm new to LB, and after studying the list archives for the past week, 
I've started working on getting LB installed on yet another Geode GX1 
board.  This system is actually a MaxSpeed MaxTerm 230, an old thin 
client system that had been surplussed.  The board inside was 
manufactured by DTRI (www.dtresearch.com), and is model WBTG v1.1.  The 
WBTG has a 300Mhz GX1, 64MB of on-board DRAM, and 8MB of on-board 
flash.  It uses the CS5530 southbridge, an NS PC97317 SuperIO, and an NS 
83815 10/100 Ethernet.

Since the CPU, southbridge, and SuperIO are the same as the Eaglelion 
5bcm, I have started with that target.  And my initial LB image, 
complete with FILO, basically works!  At least, it passes the smoke test.

Questions/issues thus far:
1)  IRQ questions.  I got the error about copying the IRQ table, and I 
know I can fix this by using an uncompressed image.  But that leaves me 
with a few questions:
a)  Does using an uncompressed LB image preclude having a failsafe 
image, due to uncompressed image size?  Not a problem for me, just curious.
b)  How can I create an IRQ map for this system, or do I not worry about 
it?  This machine was built to only run WinCE, so I can't take the stock 
BIOS, boot Linux, and do any investigating.

2)  When initializing the IDE on the CS5530, LB reports "missing 
enable_resources", even though a few lines prior, it looks like it 
assigns the proper I/O range for IDE.  What does this mean?  (See 
attached LB output.)

3)  I have several uses in mind for these boards, if I can get more of 
them.  Some uses would involve using the audio and VGA, both of which I 
know are problematic.  I think the VGA part I can do, but what about 
audio?  Is "VSA" required to initialize the audio?  I guess what I'm 
wondering is, what's the minimum LB has to do before Linux can see (and 
use) the audio.  FWIW, this board has an NS LM4548 audio chip, which I 
assume is a support chip for the XpressAudio?  Or better, maybe DTRI 
decided to scrap XpressAudio and this chip is standalone... that would 
make me happy.  :-)

Thanks to everyone on the LB team, it's clear from the archives that you 
all are really dedicated.  And thanks to Hamish for the GX1 work in LBv2.

-Jonathan

-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: MaxTerm230-first-LB-boot-20060512.txt
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20060513/d7b50c75/attachment.txt>

From chris at suehsi.de  Sat May 13 22:04:28 2006
From: chris at suehsi.de (=?ISO-8859-1?Q?Christian_S=FChs?=)
Date: Sat, 13 May 2006 22:04:28 +0200
Subject: [LinuxBIOS] Another Geode GX1: status & questions
In-Reply-To: <4465F44E.6060205@sprintmail.com>
References: <4465F44E.6060205@sprintmail.com>
Message-ID: <44663BCC.9040607@suehsi.de>


> 
> Questions/issues thus far:
> 1)  IRQ questions.  I got the error about copying the IRQ table, and I 
> know I can fix this by using an uncompressed image.  But that leaves me 
> with a few questions:

After enabling read/write/cache for BC_XMAP_2 and BC_XMAP_3 in 
gx_setup.inc under src/cpu/amd/model_gx1 the irq_table is copied and 
verified well.

You should set both to 0x33333333 or 0x77777777 to try this

> a)  Does using an uncompressed LB image preclude having a failsafe 
> image, due to uncompressed image size?  Not a problem for me, just curious.
> b)  How can I create an IRQ map for this system, or do I not worry about 
> it?  This machine was built to only run WinCE, so I can't take the stock 
> BIOS, boot Linux, and do any investigating.
> 
> 2)  When initializing the IDE on the CS5530, LB reports "missing 
> enable_resources", even though a few lines prior, it looks like it 
> assigns the proper I/O range for IDE.  What does this mean?  (See 
> attached LB output.)
>

Sorry no answer for that :(

> 3)  I have several uses in mind for these boards, if I can get more of 
> them.  Some uses would involve using the audio and VGA, both of which I 
> know are problematic.  I think the VGA part I can do, but what about

Read the allwell stb3036 threads, I run in several problems to get the 
vga working :D

> audio?  Is "VSA" required to initialize the audio?  I guess what I'm 
> wondering is, what's the minimum LB has to do before Linux can see (and 
> use) the audio.  FWIW, this board has an NS LM4548 audio chip, which I

You should set first the audio device to "on" in the Config.lb under 
src/mainboard/eaglelion/5bcm

I have the same NS audio companion chip on my board, but not test this yet.

> assume is a support chip for the XpressAudio?  Or better, maybe DTRI 
> decided to scrap XpressAudio and this chip is standalone... that would 
> make me happy.  :-)

Sorry, but the datasheets says that the NS LM4548 is a companion for the 
internal cs5530 audio stuff. Therefor I think that thing is not 
standalone. However, Linux detects this devices as Kalhua Audio.
I will test it in the next days.

chris



From stuge-linuxbios at cdy.org  Sun May 14 15:15:39 2006
From: stuge-linuxbios at cdy.org (Peter Stuge)
Date: Sun, 14 May 2006 15:15:39 +0200
Subject: [LinuxBIOS] Another Geode GX1: status & questions
In-Reply-To: <44663BCC.9040607@suehsi.de>
References: <4465F44E.6060205@sprintmail.com> <44663BCC.9040607@suehsi.de>
Message-ID: <20060514131539.25425.qmail@cdy.org>

On Sat, May 13, 2006 at 10:04:28PM +0200, Christian S?hs wrote:
> > assume is a support chip for the XpressAudio?  Or better, maybe
> > DTRI
> 
> Sorry, but the datasheets says that the NS LM4548 is a companion
> for the internal cs5530 audio stuff. Therefor I think that thing
> is not standalone. However, Linux detects this devices as Kalhua
> Audio.
> I will test it in the next days.

Would be neat if it works, I have a faint memory of XpressAudio
requiring the VSM in order for some driver to find it properly, but
ideally Linux has learned to do what the VSM does. :)


//Peter



From stepan at coresystems.de  Sun May 14 15:47:46 2006
From: stepan at coresystems.de (Stefan Reinauer)
Date: Sun, 14 May 2006 15:47:46 +0200
Subject: [LinuxBIOS] Another Geode GX1: status & questions
In-Reply-To: <20060514131539.25425.qmail@cdy.org>
References: <4465F44E.6060205@sprintmail.com> <44663BCC.9040607@suehsi.de>
	<20060514131539.25425.qmail@cdy.org>
Message-ID: <20060514134746.GB20184@coresystems.de>

* Peter Stuge <stuge-linuxbios at cdy.org> [060514 15:15]:
> On Sat, May 13, 2006 at 10:04:28PM +0200, Christian S?hs wrote:
> > > assume is a support chip for the XpressAudio?  Or better, maybe
> > > DTRI
> > 
> > Sorry, but the datasheets says that the NS LM4548 is a companion
> > for the internal cs5530 audio stuff. Therefor I think that thing
> > is not standalone. However, Linux detects this devices as Kalhua
> > Audio.
> > I will test it in the next days.
> 
> Would be neat if it works, I have a faint memory of XpressAudio
> requiring the VSM in order for some driver to find it properly, but
> ideally Linux has learned to do what the VSM does. :)

Does LinuxBIOS not support VSM now?

-- 
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 bchafy at ccs.neu.edu  Sun May 14 16:32:28 2006
From: bchafy at ccs.neu.edu (Bryan E. Chafy)
Date: Sun, 14 May 2006 10:32:28 -0400 (EDT)
Subject: [LinuxBIOS] Another Geode GX1: status & questions
In-Reply-To: <20060514131539.25425.qmail@cdy.org> from "Peter Stuge" at May 14,
	2006 03:15:39 PM
Message-ID: <E1FfHe0-0002vI-Ar@denali.ccs.neu.edu>


There is a native cx5530 audio driver, but it's for FreeBSD.
http://63.249.85.132/gx_audio/index.html
http://alumni.cse.ucsc.edu/~brucem/gx_audio/
It may just need to be ported over to linux if it hasn't been already.

Also, the latest kernels no longer use durango in the framebuffer driver.
It may be possible to port it to linuxbios and dispense with VGA
and even VSA altogether, which I think has been the goal for a long time.

Bryan



From jonathan at sprintmail.com  Sun May 14 18:14:22 2006
From: jonathan at sprintmail.com (Jonathan Sturges)
Date: Sun, 14 May 2006 12:14:22 -0400
Subject: [LinuxBIOS] Another Geode GX1: status & questions
In-Reply-To: <E1FfHe0-0002vI-Ar@denali.ccs.neu.edu>
References: <E1FfHe0-0002vI-Ar@denali.ccs.neu.edu>
Message-ID: <4467575E.2090707@sprintmail.com>

AMD provides an OSS audio driver patch for 2.4.x kernels, so I think 
that will suit my immediate needs.  So I think that just means LB has to 
know how to initialize the XpressAudio and assign resources to it.  I 
don't know how much, if any, VSA "stuff" is required to do this... 
hopefully not much.

-Jonathan

Bryan E. Chafy wrote:

>There is a native cx5530 audio driver, but it's for FreeBSD.
>http://63.249.85.132/gx_audio/index.html
>http://alumni.cse.ucsc.edu/~brucem/gx_audio/
>It may just need to be ported over to linux if it hasn't been already.
>
>Also, the latest kernels no longer use durango in the framebuffer driver.
>It may be possible to port it to linuxbios and dispense with VGA
>and even VSA altogether, which I think has been the goal for a long time.
>  
>



From stuge-linuxbios at cdy.org  Mon May 15 00:05:41 2006
From: stuge-linuxbios at cdy.org (Peter Stuge)
Date: Mon, 15 May 2006 00:05:41 +0200
Subject: [LinuxBIOS] Another Geode GX1: status & questions
In-Reply-To: <4467575E.2090707@sprintmail.com>
References: <E1FfHe0-0002vI-Ar@denali.ccs.neu.edu>
	<4467575E.2090707@sprintmail.com>
Message-ID: <20060514220542.1809.qmail@cdy.org>

On Sun, May 14, 2006 at 12:14:22PM -0400, Jonathan Sturges wrote:
> AMD provides an OSS audio driver patch for 2.4.x kernels, so I
> think that will suit my immediate needs.

The OSS driver could require a VSM.. Yes, I think LB does VSA now
thanks to Ollie, but I still consider VSA a hack. :p

Excellent news about scrapping durango, that was certainly a
"remarkable" piece of code. (100kb kernel module interfacing with the
graphics hardware..)

The FBSD audio driver looks great!


//Peter



From chris at suehsi.de  Mon May 15 11:14:57 2006
From: chris at suehsi.de (=?ISO-8859-1?Q?Christian_S=FChs?=)
Date: Mon, 15 May 2006 11:14:57 +0200
Subject: [LinuxBIOS] Another Geode GX1: status & questions
In-Reply-To: <20060514220542.1809.qmail@cdy.org>
References: <E1FfHe0-0002vI-Ar@denali.ccs.neu.edu>	<4467575E.2090707@sprintmail.com>
	<20060514220542.1809.qmail@cdy.org>
Message-ID: <44684691.8000909@suehsi.de>

Peter Stuge schrieb:
> On Sun, May 14, 2006 at 12:14:22PM -0400, Jonathan Sturges wrote:
> 
>>AMD provides an OSS audio driver patch for 2.4.x kernels, so I
>>think that will suit my immediate needs.

I'm not sure, but in the past I was able to use simple audio functions 
with kernel 2.4.22 and ALSA or OSS.

I think it was the great sb or sb16 modul in standard configuration 
under factory bios. without special drivers for the cs5530.

However, I was able to hear mp3 on that board.

Currently I played around with newer ALSA driver and kernel 2.4.25, but 
alsaconf don't detect the audio device.

With enabling the audio device located at 0:12.3 also the SMI stuff is 
enabled and shown under lspci. Eventually it have to enabled too, to get 
audio.

chris




From chris at suehsi.de  Tue May 16 14:39:08 2006
From: chris at suehsi.de (=?ISO-8859-1?Q?Christian_S=FChs?=)
Date: Tue, 16 May 2006 14:39:08 +0200
Subject: [LinuxBIOS] MB1030 / 3036 VGA problems with IRQs
In-Reply-To: <44659D06.7070205@suehsi.de>
References: <8a0c36780605091955s6fe971eap8369ed9ff8532fb1@mail.gmail.com>	<44621D0E.70205@suehsi.de>	<8a0c36780605101253p5542bf6dpcd9c711e563f8020@mail.gmail.com>	<4462E519.90101@suehsi.de>	<4463335A.3080308@suehsi.de>	<20060511135154.GA14964@coresystems.de>	<44633D36.5080009@suehsi.de>	<44634225.1000709@suehsi.de>	<20060511144032.GA17661@coresystems.de>	<4464B27D.2010004@suehsi.de>	<8a0c36780605121119w21c60f0bg9b14e0299aabcfe6@mail.gmail.com>
	<44659D06.7070205@suehsi.de>
Message-ID: <4469C7EC.7000302@suehsi.de>

I have created my own irq_tables.c file with getpir.

But there are the same problems as with the old eaglelion/5bcm one.
The only device which gets an irq is a PCI Network card.

The onboard devices (VGA; USB; Audio) gets IRQ 0 under linux. Is that 
normal ?

Is it possible to assign IRQs with the Config.lb file like the superIO 
devices?

chris




From stepan at coresystems.de  Tue May 16 12:32:03 2006
From: stepan at coresystems.de (Stefan Reinauer)
Date: Tue, 16 May 2006 12:32:03 +0200
Subject: [LinuxBIOS] MB1030 / 3036 VGA problems with IRQs
In-Reply-To: <4469C7EC.7000302@suehsi.de>
References: <4462E519.90101@suehsi.de> <4463335A.3080308@suehsi.de>
	<20060511135154.GA14964@coresystems.de>
	<44633D36.5080009@suehsi.de> <44634225.1000709@suehsi.de>
	<20060511144032.GA17661@coresystems.de>
	<4464B27D.2010004@suehsi.de>
	<8a0c36780605121119w21c60f0bg9b14e0299aabcfe6@mail.gmail.com>
	<44659D06.7070205@suehsi.de> <4469C7EC.7000302@suehsi.de>
Message-ID: <20060516103203.GA4791@coresystems.de>

* Christian S?hs <chris at suehsi.de> [060516 14:39]:
> I have created my own irq_tables.c file with getpir.
 
pirq tables of factory bios are very often incomplete or wrong.
One reason is that pirq and mptable are not used by the OS 
when ACPI is active. (Well, talking Linux) So this is an untested 
(and usually unused) path. 

> But there are the same problems as with the old eaglelion/5bcm one.
> The only device which gets an irq is a PCI Network card.
> 
> The onboard devices (VGA; USB; Audio) gets IRQ 0 under linux. Is that 
> normal ?
 
USB should get an IRQ, audio as well, probably. Don't think you need one
for VGA? What does your factory bios say?

> Is it possible to assign IRQs with the Config.lb file like the superIO 
> devices?

Nope. you have to write support in form of mptable, pirq or ACPI to get
this working.

-- 
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 chris at suehsi.de  Tue May 16 16:54:01 2006
From: chris at suehsi.de (=?UTF-8?B?Q2hyaXN0aWFuIFPDvGhz?=)
Date: Tue, 16 May 2006 16:54:01 +0200
Subject: [LinuxBIOS] MB1030 / 3036 VGA problems with IRQs
In-Reply-To: <20060516103203.GA4791@coresystems.de>
References: <4462E519.90101@suehsi.de>
	<4463335A.3080308@suehsi.de>	<20060511135154.GA14964@coresystems.de>	<44633D36.5080009@suehsi.de>
	<44634225.1000709@suehsi.de>	<20060511144032.GA17661@coresystems.de>	<4464B27D.2010004@suehsi.de>	<8a0c36780605121119w21c60f0bg9b14e0299aabcfe6@mail.gmail.com>	<44659D06.7070205@suehsi.de>
	<4469C7EC.7000302@suehsi.de> <20060516103203.GA4791@coresystems.de>
Message-ID: <4469E789.9030507@suehsi.de>

Stefan Reinauer schrieb:
> * Christian S?hs <chris at suehsi.de> [060516 14:39]:
> 
>>I have created my own irq_tables.c file with getpir.
> 
>  
> pirq tables of factory bios are very often incomplete or wrong.
> One reason is that pirq and mptable are not used by the OS 
> when ACPI is active. (Well, talking Linux) So this is an untested 
> (and usually unused) path. 

ACPI is not enabled in the kernel.
What about the bios parameters? There is a switch to enable/disable for 
pnp os intalled. Eventually there are differences if I run getpir in 
both cases? Or should I set the IRQs manually in the bios before I run 
getpir.


>  
> USB should get an IRQ, audio as well, probably. Don't think you need one
> for VGA? What does your factory bios say?

All devices gets an IRQ.

> 
> Nope. you have to write support in form of mptable, pirq or ACPI to get
> this working.
> 





From stepan at coresystems.de  Tue May 16 14:08:20 2006
From: stepan at coresystems.de (Stefan Reinauer)
Date: Tue, 16 May 2006 14:08:20 +0200
Subject: [LinuxBIOS] MB1030 / 3036 VGA problems with IRQs
In-Reply-To: <4469E789.9030507@suehsi.de>
References: <20060511135154.GA14964@coresystems.de>
	<44633D36.5080009@suehsi.de> <44634225.1000709@suehsi.de>
	<20060511144032.GA17661@coresystems.de>
	<4464B27D.2010004@suehsi.de>
	<8a0c36780605121119w21c60f0bg9b14e0299aabcfe6@mail.gmail.com>
	<44659D06.7070205@suehsi.de> <4469C7EC.7000302@suehsi.de>
	<20060516103203.GA4791@coresystems.de> <4469E789.9030507@suehsi.de>
Message-ID: <20060516120820.GA10158@coresystems.de>

* Christian S?hs <chris at suehsi.de> [060516 16:54]:
> >pirq tables of factory bios are very often incomplete or wrong.
> >One reason is that pirq and mptable are not used by the OS 
> >when ACPI is active. (Well, talking Linux) So this is an untested 
> >(and usually unused) path. 
> 
> ACPI is not enabled in the kernel.
> What about the bios parameters? There is a switch to enable/disable for 
> pnp os intalled. Eventually there are differences if I run getpir in 
> both cases? Or should I set the IRQs manually in the bios before I run 
> getpir.

Look at the hardware and write a valid pirq table.. getpir is a nice
tool but it starts out by utilizing a broken piece of software, the
factory bios. One entry in the pirq table for each device that gets an
interrupt and for each pci slot is needed.

Most factory bios versions explicitly allocate interrupts for the
existing hardware by writing to the PCI registers. 

LinuxBIOS does not do that, but instead provides the information to have
Linux do that. 

If the interrupts are already initialized by the bios, a broken pirq
table is not all too bad, except that its good for nothing except
forcing the kernel into certain code paths (no joke)

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 lanl.gov  Tue May 16 15:25:35 2006
From: rminnich at lanl.gov (Ronald G Minnich)
Date: Tue, 16 May 2006 07:25:35 -0600
Subject: [LinuxBIOS] MB1030 / 3036 VGA problems with IRQs
In-Reply-To: <4469C7EC.7000302@suehsi.de>
References: <8a0c36780605091955s6fe971eap8369ed9ff8532fb1@mail.gmail.com>	<44621D0E.70205@suehsi.de>	<8a0c36780605101253p5542bf6dpcd9c711e563f8020@mail.gmail.com>	<4462E519.90101@suehsi.de>	<4463335A.3080308@suehsi.de>	<20060511135154.GA14964@coresystems.de>	<44633D36.5080009@suehsi.de>	<44634225.1000709@suehsi.de>	<20060511144032.GA17661@coresystems.de>	<4464B27D.2010004@suehsi.de>	<8a0c36780605121119w21c60f0bg9b14e0299aabcfe6@mail.gmail.com>	<44659D06.7070205@suehsi.de>
	<4469C7EC.7000302@suehsi.de>
Message-ID: <4469D2CF.9010809@lanl.gov>

Christian S?hs wrote:

> Is it possible to assign IRQs with the Config.lb file like the superIO 
> devices?

not currently.

I would just go ahead and set IRQs in your mainboard config file. In 
many cases, we have found the BIOS $PIR table is wrong, and the BIOS 
just sets register 3c.

ron



From rminnich at lanl.gov  Tue May 16 15:26:40 2006
From: rminnich at lanl.gov (Ronald G Minnich)
Date: Tue, 16 May 2006 07:26:40 -0600
Subject: [LinuxBIOS] MB1030 / 3036 VGA problems with IRQs
In-Reply-To: <4469E789.9030507@suehsi.de>
References: <4462E519.90101@suehsi.de>	<4463335A.3080308@suehsi.de>	<20060511135154.GA14964@coresystems.de>	<44633D36.5080009@suehsi.de>	<44634225.1000709@suehsi.de>	<20060511144032.GA17661@coresystems.de>	<4464B27D.2010004@suehsi.de>	<8a0c36780605121119w21c60f0bg9b14e0299aabcfe6@mail.gmail.com>	<44659D06.7070205@suehsi.de>	<4469C7EC.7000302@suehsi.de>
	<20060516103203.GA4791@coresystems.de> <4469E789.9030507@suehsi.de>
Message-ID: <4469D310.8060901@lanl.gov>

again, on some platforms which are broken, in mainboard.c, I just force 
the value of the 0x3c byte register for each device which needs an  IRQ, 
the force the interupt router settings.

ron



From chris at suehsi.de  Tue May 16 18:54:48 2006
From: chris at suehsi.de (=?UTF-8?B?Q2hyaXN0aWFuIFPDvGhz?=)
Date: Tue, 16 May 2006 18:54:48 +0200
Subject: [LinuxBIOS] MB1030 / 3036 VGA problems with IRQs
In-Reply-To: <20060516120820.GA10158@coresystems.de>
References: <20060511135154.GA14964@coresystems.de>	<44633D36.5080009@suehsi.de>
	<44634225.1000709@suehsi.de>	<20060511144032.GA17661@coresystems.de>	<4464B27D.2010004@suehsi.de>	<8a0c36780605121119w21c60f0bg9b14e0299aabcfe6@mail.gmail.com>	<44659D06.7070205@suehsi.de>
	<4469C7EC.7000302@suehsi.de>	<20060516103203.GA4791@coresystems.de>
	<4469E789.9030507@suehsi.de>
	<20060516120820.GA10158@coresystems.de>
Message-ID: <446A03D8.5050307@suehsi.de>


> 
> Look at the hardware and write a valid pirq table.. getpir is a nice
> tool but it starts out by utilizing a broken piece of software, the
> factory bios. One entry in the pirq table for each device that gets an
> interrupt and for each pci slot is needed.
> 

Is it safe to comment not used devices
i.e. the created irq table by getpir shows a line for device 8, but 
there is currently no device, the same for some other currently not used 
devices.

Also the exclusive PCI IRQs are set to 10 and 11.
The Board has a combi PCI/ISA extension Slot. Can I add some IRQs like 5 
and 9.

Next Question:

Device where the interrupt router lies is set to
(0x12<<3)|0x00

the first seems to be wrong (0:16.0) 0x00 is the better choice.
I thing "|" means "OR" I'm right?


chris



From stepan at coresystems.de  Tue May 16 15:57:36 2006
From: stepan at coresystems.de (Stefan Reinauer)
Date: Tue, 16 May 2006 15:57:36 +0200
Subject: [LinuxBIOS] MB1030 / 3036 VGA problems with IRQs
In-Reply-To: <446A03D8.5050307@suehsi.de>
References: <44634225.1000709@suehsi.de>
	<20060511144032.GA17661@coresystems.de>
	<4464B27D.2010004@suehsi.de>
	<8a0c36780605121119w21c60f0bg9b14e0299aabcfe6@mail.gmail.com>
	<44659D06.7070205@suehsi.de> <4469C7EC.7000302@suehsi.de>
	<20060516103203.GA4791@coresystems.de> <4469E789.9030507@suehsi.de>
	<20060516120820.GA10158@coresystems.de>
	<446A03D8.5050307@suehsi.de>
Message-ID: <20060516135736.GA15023@coresystems.de>

* Christian S?hs <chris at suehsi.de> [060516 18:54]:
> Is it safe to comment not used devices
> i.e. the created irq table by getpir shows a line for device 8, but 
> there is currently no device, the same for some other currently not used 
> devices.

Yes, most likely you can just remove that entry. This might be entries
for PCI slots though, so a problem might only occur when you plug in a
PCI card..

> Also the exclusive PCI IRQs are set to 10 and 11.
> The Board has a combi PCI/ISA extension Slot. Can I add some IRQs like 5 
> and 9.
 
might work, might not. This depends of many things for example on how
the mainboard is wired.

> Device where the interrupt router lies is set to
> (0x12<<3)|0x00
> 
> the first seems to be wrong (0:16.0) 0x00 is the better choice.
> I thing "|" means "OR" I'm right?
 
yes, | is OR.

You should change the device position.

NOTE: 0:16.0 might be 0x16 or 16 (0x10) - you need to find to make it
work right. lspci shows hex values - this confused me quite some time
when we did the opteron port..

Not necessarily the device ID though, since Linux might not support the
actually used interrupt router. I think on K8 boards the IRQ router
device and vendor id is still set to the k7 interrupt router (it was in
the past) because the two devices were compatible and linux did only know
the older part.

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 lanl.gov  Tue May 16 16:35:56 2006
From: rminnich at lanl.gov (Ronald G Minnich)
Date: Tue, 16 May 2006 08:35:56 -0600
Subject: [LinuxBIOS] MB1030 / 3036 VGA problems with IRQs
In-Reply-To: <446A03D8.5050307@suehsi.de>
References: <20060511135154.GA14964@coresystems.de>	<44633D36.5080009@suehsi.de>	<44634225.1000709@suehsi.de>	<20060511144032.GA17661@coresystems.de>	<4464B27D.2010004@suehsi.de>	<8a0c36780605121119w21c60f0bg9b14e0299aabcfe6@mail.gmail.com>	<44659D06.7070205@suehsi.de>	<4469C7EC.7000302@suehsi.de>	<20060516103203.GA4791@coresystems.de>	<4469E789.9030507@suehsi.de>	<20060516120820.GA10158@coresystems.de>
	<446A03D8.5050307@suehsi.de>
Message-ID: <4469E34C.2080900@lanl.gov>

Christian S?hs wrote:

> Is it safe to comment not used devices
> i.e. the created irq table by getpir shows a line for device 8, but 
> there is currently no device, the same for some other currently not used 
> devices.

are you sure that's not the pci slot (is there one)?

if there really are impossible devices that is a sure sign that your 
$PIR is bogus.

ron

> the first seems to be wrong (0:16.0) 0x00 is the better choice.
> I thing "|" means "OR" I'm right?

bitwise or, yes.

ron



From rminnich at lanl.gov  Tue May 16 16:34:50 2006
From: rminnich at lanl.gov (Ronald G Minnich)
Date: Tue, 16 May 2006 08:34:50 -0600
Subject: [LinuxBIOS] MB1030 / 3036 VGA problems with IRQs
In-Reply-To: <4469D2CF.9010809@lanl.gov>
References: <8a0c36780605091955s6fe971eap8369ed9ff8532fb1@mail.gmail.com>	<44621D0E.70205@suehsi.de>	<8a0c36780605101253p5542bf6dpcd9c711e563f8020@mail.gmail.com>	<4462E519.90101@suehsi.de>	<4463335A.3080308@suehsi.de>	<20060511135154.GA14964@coresystems.de>	<44633D36.5080009@suehsi.de>	<44634225.1000709@suehsi.de>	<20060511144032.GA17661@coresystems.de>	<4464B27D.2010004@suehsi.de>	<8a0c36780605121119w21c60f0bg9b14e0299aabcfe6@mail.gmail.com>	<44659D06.7070205@suehsi.de>	<4469C7EC.7000302@suehsi.de>
	<4469D2CF.9010809@lanl.gov>
Message-ID: <4469E30A.5060702@lanl.gov>

Ronald G Minnich wrote:
> Christian S?hs wrote:
> 
> 
>>Is it possible to assign IRQs with the Config.lb file like the superIO 
>>devices?
> 
> 
> not currently.
> 
> I would just go ahead and set IRQs in your mainboard config file. In 
                                              mainboard.c
> many cases, we have found the BIOS $PIR table is wrong, and the BIOS 
> just sets register 3c.
> 
> ron
> 



sorry

ron



From chris at suehsi.de  Tue May 16 21:04:49 2006
From: chris at suehsi.de (=?UTF-8?B?Q2hyaXN0aWFuIFPDvGhz?=)
Date: Tue, 16 May 2006 21:04:49 +0200
Subject: [LinuxBIOS] MB1030 / 3036 VGA problems with IRQs
In-Reply-To: <20060516135736.GA15023@coresystems.de>
References: <44634225.1000709@suehsi.de>	<20060511144032.GA17661@coresystems.de>	<4464B27D.2010004@suehsi.de>	<8a0c36780605121119w21c60f0bg9b14e0299aabcfe6@mail.gmail.com>	<44659D06.7070205@suehsi.de>
	<4469C7EC.7000302@suehsi.de>	<20060516103203.GA4791@coresystems.de>
	<4469E789.9030507@suehsi.de>	<20060516120820.GA10158@coresystems.de>	<446A03D8.5050307@suehsi.de>
	<20060516135736.GA15023@coresystems.de>
Message-ID: <446A2251.1080503@suehsi.de>


> 
>>Device where the interrupt router lies is set to
>>(0x12<<3)|0x00
>>
>>the first seems to be wrong (0:16.0) 0x00 is the better choice.
>>I thing "|" means "OR" I'm right?
> 
uups,

I think my KCalc is on the woodway ;)
it says 0x12<<3 is 90h that is 10010000b

the upper five bits are the device.

  1 0 0 1 0 0 0 0
------------------
16 8 4 2 1

should be 18 in decimal

>  
> yes, | is OR.
> 
> You should change the device position.
> 
> NOTE: 0:16.0 might be 0x16 or 16 (0x10) - you need to find to make it
> work right. lspci shows hex values - this confused me quite some time
> when we did the opteron port..

Ok, lspci shows hex. What about cat /proc/pci? Is this decimal?
I will have a look with cat, because I remember that cat /proc/pci shows 
different device numbers.

> 
> Not necessarily the device ID though, since Linux might not support the
> actually used interrupt router. I think on K8 boards the IRQ router
> device and vendor id is still set to the k7 interrupt router (it was in
> the past) because the two devices were compatible and linux did only know
> the older part.

It seems that linux knows that router,

+++
PCI: Using IRQ router NatSemi [1078/0100] at 00:12.0
+++

in hex.

> 
> Stefan
> 
> 




From chris at suehsi.de  Tue May 16 21:22:43 2006
From: chris at suehsi.de (=?ISO-8859-1?Q?Christian_S=FChs?=)
Date: Tue, 16 May 2006 21:22:43 +0200
Subject: [LinuxBIOS] MB1030 / 3036 VGA problems with IRQs
In-Reply-To: <4469E34C.2080900@lanl.gov>
References: <20060511135154.GA14964@coresystems.de>	<44633D36.5080009@suehsi.de>	<44634225.1000709@suehsi.de>	<20060511144032.GA17661@coresystems.de>	<4464B27D.2010004@suehsi.de>	<8a0c36780605121119w21c60f0bg9b14e0299aabcfe6@mail.gmail.com>	<44659D06.7070205@suehsi.de>	<4469C7EC.7000302@suehsi.de>	<20060516103203.GA4791@coresystems.de>	<4469E789.9030507@suehsi.de>	<20060516120820.GA10158@coresystems.de>	<446A03D8.5050307@suehsi.de>
	<4469E34C.2080900@lanl.gov>
Message-ID: <446A2683.8070303@suehsi.de>

Ronald G Minnich schrieb:
> Christian S?hs wrote:
> 
> 
>>Is it safe to comment not used devices
>>i.e. the created irq table by getpir shows a line for device 8, but 
>>there is currently no device, the same for some other currently not used 
>>devices.
> 
> 
> are you sure that's not the pci slot (is there one)?

Good question,

There is first the onboard integrated vga device on 00:9.0
the southbridge on 00:12.0 and usb on 00:13.0

than a expansion slot for pci/isa riser cards. The network card is 
plugged in a adaptor and shown under lspci as 00:7.0 on this slot.

> 
> if there really are impossible devices that is a sure sign that your 
> $PIR is bogus.

Proplem is, normally the board has an integrated Network adaptor, which 
is not soldered in my case (optional) Should be a realtek 8139c. I guess 
that is a PCI device and eventually assign to 00:8.0

> 
> ron
> 
> 
>>the first seems to be wrong (0:16.0) 0x00 is the better choice.
>>I thing "|" means "OR" I'm right?
> 

Ok, the result is 18 in decimal. cat /proc/pci shows the southbridge 
with device 18, therefor it is right. I have made a mistake.

> 
> bitwise or, yes.
> 
> ron
> 





From chris at suehsi.de  Tue May 16 19:12:07 2006
From: chris at suehsi.de (=?ISO-8859-1?Q?Christian_S=FChs?=)
Date: Tue, 16 May 2006 19:12:07 +0200
Subject: [LinuxBIOS] MB1030 / 3036 VGA problems with IRQs
In-Reply-To: <446A2683.8070303@suehsi.de>
References: <20060511135154.GA14964@coresystems.de>	<44633D36.5080009@suehsi.de>	<44634225.1000709@suehsi.de>	<20060511144032.GA17661@coresystems.de>	<4464B27D.2010004@suehsi.de>	<8a0c36780605121119w21c60f0bg9b14e0299aabcfe6@mail.gmail.com>	<44659D06.7070205@suehsi.de>	<4469C7EC.7000302@suehsi.de>	<20060516103203.GA4791@coresystems.de>	<4469E789.9030507@suehsi.de>	<20060516120820.GA10158@coresystems.de>	<446A03D8.5050307@suehsi.de>	<4469E34C.2080900@lanl.gov>
	<446A2683.8070303@suehsi.de>
Message-ID: <446A07E7.3050405@suehsi.de>


>>
>>are you sure that's not the pci slot (is there one)?
> 
> 
> Good question,
> 
> There is first the onboard integrated vga device on 00:9.0
> the southbridge on 00:12.0 and usb on 00:13.0
> 
> than a expansion slot for pci/isa riser cards. The network card is 
> plugged in a adaptor and shown under lspci as 00:7.0 on this slot.
> 
> 

ok, can anybody have a look to the irq_tables.c

I have set all onboard components to slot 0x0 and assigned one link.
Or is there a better way?

chris

BTW:
Did you known, that the vt8235 southbridge from via have 8 INT Lines?
4 for external use #A - #D and 4 for onboard components only #E - #H


-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: irq_tables.c
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20060516/7785c3c8/attachment.c>

From stepan at coresystems.de  Tue May 16 19:30:55 2006
From: stepan at coresystems.de (Stefan Reinauer)
Date: Tue, 16 May 2006 19:30:55 +0200
Subject: [LinuxBIOS] MB1030 / 3036 VGA problems with IRQs
In-Reply-To: <446A07E7.3050405@suehsi.de>
References: <8a0c36780605121119w21c60f0bg9b14e0299aabcfe6@mail.gmail.com>
	<44659D06.7070205@suehsi.de> <4469C7EC.7000302@suehsi.de>
	<20060516103203.GA4791@coresystems.de> <4469E789.9030507@suehsi.de>
	<20060516120820.GA10158@coresystems.de>
	<446A03D8.5050307@suehsi.de> <4469E34C.2080900@lanl.gov>
	<446A2683.8070303@suehsi.de> <446A07E7.3050405@suehsi.de>
Message-ID: <20060516173055.GA25765@coresystems.de>

* Christian S?hs <chris at suehsi.de> [060516 19:12]:
> 
> ok, can anybody have a look to the irq_tables.c
> 
> I have set all onboard components to slot 0x0 and assigned one link.
> Or is there a better way?
 
to achieve what?

Does USB get an interrupt with that pirq table?


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 stepan at coresystems.de  Tue May 16 20:49:21 2006
From: stepan at coresystems.de (Stefan Reinauer)
Date: Tue, 16 May 2006 20:49:21 +0200
Subject: [LinuxBIOS] UEFI discussion
Message-ID: <20060516184921.GA28858@coresystems.de>

Hi,

I was about to have a look at implementing UEFI, when I noticed the
following:

    I understand that I may download and read the UEFI 2.0
    specification without the requirement of a license, and doing so
    creates no obligations or commitments on my part. I further
    understand and acknowledge that any distribution, additional
    reproduction, implementation or other use of the specification
    requires a license, which can be obtained by executing the UEFI
    Adopters' Agreement.

Reading further, this means I have to pay a yearly (voluntary?) fee to
be allowed to do anything with the UEFI spec.

Is there any interest at all in an Open Source UEFI implementation?

This discussion is popping up from time to time but it is never really
getting forward yet.

What do you think?


Best regards
 Stefan Reinauer


-- 
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 chris at suehsi.de  Tue May 16 21:19:08 2006
From: chris at suehsi.de (=?UTF-8?B?Q2hyaXN0aWFuIFPDvGhz?=)
Date: Tue, 16 May 2006 21:19:08 +0200
Subject: [LinuxBIOS] MB1030 / 3036 VGA problems with IRQs
In-Reply-To: <20060516173055.GA25765@coresystems.de>
References: <8a0c36780605121119w21c60f0bg9b14e0299aabcfe6@mail.gmail.com>	<44659D06.7070205@suehsi.de>
	<4469C7EC.7000302@suehsi.de>	<20060516103203.GA4791@coresystems.de>
	<4469E789.9030507@suehsi.de>	<20060516120820.GA10158@coresystems.de>	<446A03D8.5050307@suehsi.de>
	<4469E34C.2080900@lanl.gov>	<446A2683.8070303@suehsi.de>
	<446A07E7.3050405@suehsi.de>
	<20060516173055.GA25765@coresystems.de>
Message-ID: <446A25AC.1070302@suehsi.de>

Stefan Reinauer schrieb:
> * Christian S?hs <chris at suehsi.de> [060516 19:12]:
> 
>>ok, can anybody have a look to the irq_tables.c
>>
>>I have set all onboard components to slot 0x0 and assigned one link.
>>Or is there a better way?
> 
>  
> to achieve what?
> 
> Does USB get an interrupt with that pirq table?
> 
> 
> Stefan
> 
> 

Well,
the microsoft docu prefers to set onboard devices to 0x0 for slot 
numbers in the slot entrys.

First slot entry is device 7d, I think the pci/isa expansion slot, 
possible IRQs 10 and 11, because of the explicit settings.
Next device 9d onboard vga should be IRQ 10; 11 or 9
Next device 18d function 3 onboard audio should be IRQ 5
Last device 19d onboard usb should be IRQ 10; 11 or 9

I'm unsure about the linking for #A; #B; #C; #D

chris




From chris at suehsi.de  Tue May 16 21:40:59 2006
From: chris at suehsi.de (=?UTF-8?B?Q2hyaXN0aWFuIFPDvGhz?=)
Date: Tue, 16 May 2006 21:40:59 +0200
Subject: [LinuxBIOS] MB1030 / 3036 VGA problems with IRQs
In-Reply-To: <446A25AC.1070302@suehsi.de>
References: <8a0c36780605121119w21c60f0bg9b14e0299aabcfe6@mail.gmail.com>	<44659D06.7070205@suehsi.de>	<4469C7EC.7000302@suehsi.de>	<20060516103203.GA4791@coresystems.de>	<4469E789.9030507@suehsi.de>	<20060516120820.GA10158@coresystems.de>	<446A03D8.5050307@suehsi.de>	<4469E34C.2080900@lanl.gov>	<446A2683.8070303@suehsi.de>	<446A07E7.3050405@suehsi.de>	<20060516173055.GA25765@coresystems.de>
	<446A25AC.1070302@suehsi.de>
Message-ID: <446A2ACB.1070308@suehsi.de>


>>
>>Does USB get an interrupt with that pirq table?
>>

No, the datasheet says that the usb controller uses int#A for its output.

>>
>>Stefan





From ward at gnu.org  Tue May 16 23:46:21 2006
From: ward at gnu.org (Ward Vandewege)
Date: Tue, 16 May 2006 17:46:21 -0400
Subject: [LinuxBIOS] COM2 in tyan/s2881
Message-ID: <20060516214621.GA17146@localdomain>

Hi there,

It seems COM2 is disabled by default in the s2881/Config.lb file. Since the
board has a COM2 connector, and it is what you would use with the IPMI
daughter card, would it make sense to enable it by default?

I've got IPMI console redirection working by letting FILO 0.5 (in grub mode)
and the kernel talk to COM2 instead of COM1. COM2 is connected to the IPMI
card. With the latest ipmitool snapshot
(http://ipmitool.sourceforge.net/snapshot/), that gives me have a serial
console over the network without extra hardware (other than the IPMI card).

Pretty brilliant!
Ward.

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



From yinghai.lu at amd.com  Wed May 17 00:09:44 2006
From: yinghai.lu at amd.com (Lu, Yinghai)
Date: Tue, 16 May 2006 15:09:44 -0700
Subject: [LinuxBIOS] COM2 in tyan/s2881
Message-ID: <6F7DA19D05F3CF40B890C7CA2DB13A4203094CA2@ssvlexmb2.amd.com>

Good.

That will make you boot time longer. Because the com2 only need to set
to 19200.

YH

-----Original Message-----
From: linuxbios-bounces at linuxbios.org
[mailto:linuxbios-bounces at linuxbios.org] On Behalf Of Ward Vandewege
Sent: Tuesday, May 16, 2006 2:46 PM
To: linuxbios at linuxbios.org
Subject: [LinuxBIOS] COM2 in tyan/s2881

Hi there,

It seems COM2 is disabled by default in the s2881/Config.lb file. Since
the
board has a COM2 connector, and it is what you would use with the IPMI
daughter card, would it make sense to enable it by default?

I've got IPMI console redirection working by letting FILO 0.5 (in grub
mode)
and the kernel talk to COM2 instead of COM1. COM2 is connected to the
IPMI
card. With the latest ipmitool snapshot
(http://ipmitool.sourceforge.net/snapshot/), that gives me have a serial
console over the network without extra hardware (other than the IPMI
card).

Pretty brilliant!
Ward.

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

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





From rminnich at lanl.gov  Wed May 17 00:25:30 2006
From: rminnich at lanl.gov (Ronald G Minnich)
Date: Tue, 16 May 2006 16:25:30 -0600
Subject: [LinuxBIOS] UEFI discussion
In-Reply-To: <20060516184921.GA28858@coresystems.de>
References: <20060516184921.GA28858@coresystems.de>
Message-ID: <446A515A.2060403@lanl.gov>

I don't know what to do or say.

I will try to get some info from someone and then get back to this list.

ron



From ward at gnu.org  Wed May 17 00:36:02 2006
From: ward at gnu.org (Ward Vandewege)
Date: Tue, 16 May 2006 18:36:02 -0400
Subject: [LinuxBIOS] COM2 in tyan/s2881
In-Reply-To: <6F7DA19D05F3CF40B890C7CA2DB13A4203094CA2@ssvlexmb2.amd.com>
References: <6F7DA19D05F3CF40B890C7CA2DB13A4203094CA2@ssvlexmb2.amd.com>
Message-ID: <20060516223602.GA25813@localdomain>

On Tue, May 16, 2006 at 03:09:44PM -0700, Lu, Yinghai wrote:
> Good.
> 
> That will make you boot time longer. Because the com2 only need to set
> to 19200.

That is correct. But it will only make the boot time longer when using com2,
right? Not just when it's enabled. And reducing the verbosity of linuxbios
and the kernel at startup should remove most of the slowdown...

Ward.

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



From stepan at coresystems.de  Wed May 17 11:10:20 2006
From: stepan at coresystems.de (Stefan Reinauer)
Date: Wed, 17 May 2006 11:10:20 +0200
Subject: [LinuxBIOS] COM2 in tyan/s2881
In-Reply-To: <20060516223602.GA25813@localdomain>
References: <6F7DA19D05F3CF40B890C7CA2DB13A4203094CA2@ssvlexmb2.amd.com>
	<20060516223602.GA25813@localdomain>
Message-ID: <20060517091019.GA28510@coresystems.de>

* Ward Vandewege <ward at gnu.org> [060517 00:36]:
> On Tue, May 16, 2006 at 03:09:44PM -0700, Lu, Yinghai wrote:
> > Good.
> > 
> > That will make you boot time longer. Because the com2 only need to set
> > to 19200.
> 
> That is correct. But it will only make the boot time longer when using com2,
> right? Not just when it's enabled. And reducing the verbosity of linuxbios
> and the kernel at startup should remove most of the slowdown...

Right. If the hardware is physically there onboard it should be enabled
per default. 

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 bchafy at ccs.neu.edu  Wed May 17 17:26:13 2006
From: bchafy at ccs.neu.edu (Bryan E. Chafy)
Date: Wed, 17 May 2006 11:26:13 -0400 (EDT)
Subject: [LinuxBIOS] UEFI discussion
In-Reply-To: <20060516184921.GA28858@coresystems.de> from "Stefan Reinauer" at
	May 16, 2006 08:49:21 PM
Message-ID: <E1FgNuf-0001F3-7F@denali.ccs.neu.edu>

> What do you think?

IMO, lots of members-only "standards bodies" that should really end
in .com instead of .org

  is         reality
----------------------
uefi.org -> uefi.com
vesa.org -> vesa.com
iso.org  -> iso.com
ieee.org -> ieee.com
pcisig.com -> ok
wikipedia.org -> ok, so far

Maybe start by making a new framework that is similar/compatible but not
exactly the same as UEFI.  Call it FUefi or something :)



From rminnich at lanl.gov  Wed May 17 17:41:36 2006
From: rminnich at lanl.gov (Ronald G Minnich)
Date: Wed, 17 May 2006 09:41:36 -0600
Subject: [LinuxBIOS] UEFI discussion
In-Reply-To: <E1FgNuf-0001F3-7F@denali.ccs.neu.edu>
References: <E1FgNuf-0001F3-7F@denali.ccs.neu.edu>
Message-ID: <446B4430.7040705@lanl.gov>

Bryan E. Chafy wrote:
>>What do you think?
> 
> 
> IMO, lots of members-only "standards bodies" that should really end
> in .com instead of .org
> 
>   is         reality
> ----------------------
> uefi.org -> uefi.com
> vesa.org -> vesa.com
> iso.org  -> iso.com
> ieee.org -> ieee.com
> pcisig.com -> ok
> wikipedia.org -> ok, so far
> 
> Maybe start by making a new framework that is similar/compatible but not
> exactly the same as UEFI.  Call it FUefi or something :)
> 

I own both openefi.org and free-efi.org

ron



From stepan at coresystems.de  Wed May 17 20:22:01 2006
From: stepan at coresystems.de (Stefan Reinauer)
Date: Wed, 17 May 2006 20:22:01 +0200
Subject: [LinuxBIOS] UEFI discussion
In-Reply-To: <E1FgNuf-0001F3-7F@denali.ccs.neu.edu>
References: <20060516184921.GA28858@coresystems.de>
	<E1FgNuf-0001F3-7F@denali.ccs.neu.edu>
Message-ID: <20060517182201.GB22950@coresystems.de>

* Bryan E. Chafy <bchafy at ccs.neu.edu> [060517 17:26]:
> Maybe start by making a new framework that is similar/compatible but not
> exactly the same as UEFI.  Call it FUefi or something :)

Been there 12 years ago (actually since the 80ies): Open Firmware and
the industry standard IEEE 1275-1994

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  Wed May 17 18:22:11 2006
From: yinghai.lu at amd.com (Lu, Yinghai)
Date: Wed, 17 May 2006 09:22:11 -0700
Subject: [LinuxBIOS] UEFI discussion
Message-ID: <6F7DA19D05F3CF40B890C7CA2DB13A4203094CAB@ssvlexmb2.amd.com>

Then you have to look at efi support code in Linux kernel, and feed the
code with it wants.

YH

-----Original Message-----
From: linuxbios-bounces at linuxbios.org
[mailto:linuxbios-bounces at linuxbios.org] On Behalf Of Bryan E. Chafy
Sent: Wednesday, May 17, 2006 8:26 AM
To: linuxbios at linuxbios.org
Subject: Re: [LinuxBIOS] UEFI discussion

> What do you think?

IMO, lots of members-only "standards bodies" that should really end
in .com instead of .org

  is         reality
----------------------
uefi.org -> uefi.com
vesa.org -> vesa.com
iso.org  -> iso.com
ieee.org -> ieee.com
pcisig.com -> ok
wikipedia.org -> ok, so far

Maybe start by making a new framework that is similar/compatible but not
exactly the same as UEFI.  Call it FUefi or something :)

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





From yinghai.lu at amd.com  Wed May 17 20:39:20 2006
From: yinghai.lu at amd.com (Lu, Yinghai)
Date: Wed, 17 May 2006 11:39:20 -0700
Subject: [LinuxBIOS] laptop with nvidia ck804
Message-ID: <6F7DA19D05F3CF40B890C7CA2DB13A4203094CAC@ssvlexmb2.amd.com>

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

It's impressive.

With WUXGA(1920x1200), two sata disks, HDMI, nv SLI...

Memory is only 2G...

YH




From yinghai.lu at amd.com  Wed May 17 20:43:40 2006
From: yinghai.lu at amd.com (Lu, Yinghai)
Date: Wed, 17 May 2006 11:43:40 -0700
Subject: [LinuxBIOS] UEFI discussion
Message-ID: <6F7DA19D05F3CF40B890C7CA2DB13A4203094CAD@ssvlexmb2.amd.com>

fuefi is good.

YH

-----Original Message-----
From: linuxbios-bounces at linuxbios.org
[mailto:linuxbios-bounces at linuxbios.org] On Behalf Of Ronald G Minnich
Sent: Wednesday, May 17, 2006 8:42 AM
To: Bryan E. Chafy
Cc: linuxbios at linuxbios.org
Subject: Re: [LinuxBIOS] UEFI discussion

Bryan E. Chafy wrote:
>>What do you think?
> 
> 
> IMO, lots of members-only "standards bodies" that should really end
> in .com instead of .org
> 
>   is         reality
> ----------------------
> uefi.org -> uefi.com
> vesa.org -> vesa.com
> iso.org  -> iso.com
> ieee.org -> ieee.com
> pcisig.com -> ok
> wikipedia.org -> ok, so far
> 
> Maybe start by making a new framework that is similar/compatible but
not
> exactly the same as UEFI.  Call it FUefi or something :)
> 

I own both openefi.org and free-efi.org

ron

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





From lindahl at pathscale.com  Wed May 17 23:32:09 2006
From: lindahl at pathscale.com (Greg Lindahl)
Date: Wed, 17 May 2006 14:32:09 -0700
Subject: [LinuxBIOS] UEFI discussion
In-Reply-To: <6F7DA19D05F3CF40B890C7CA2DB13A4203094CAD@ssvlexmb2.amd.com>
References: <6F7DA19D05F3CF40B890C7CA2DB13A4203094CAD@ssvlexmb2.amd.com>
Message-ID: <20060517213209.GE2983@greglaptop.internal.keyresearch.com>

> fuefi is good.

I think I like fuefi better than guefi...



From hawke at hawkesnest.net  Thu May 18 00:04:05 2006
From: hawke at hawkesnest.net (Alex Mauer)
Date: Wed, 17 May 2006 17:04:05 -0500
Subject: [LinuxBIOS] EPIA non-M?
In-Reply-To: <e3tg6c$s1e$1@sea.gmane.org>
References: <e30v1u$d74$1@sea.gmane.org>	<4454342B.3080107@lanl.gov>	<e31mo9$2bj$1@sea.gmane.org>	<8a0c36780604301307k4de0f25fx618aa50d97fd98be@mail.gmail.com>	<e3p9ls$nhr$1@sea.gmane.org>	<44602932.4060203@lanl.gov>	<8a0c36780605090726p47464840kbd93d0607108aaee@mail.gmail.com>
	<e3tg6c$s1e$1@sea.gmane.org>
Message-ID: <e4g6ku$tta$1@sea.gmane.org>

Alex Mauer wrote:
> So I tried just pulling src/northbridge/via/vt8601/raminit.c in from
> each of those revisions.
> 
> None of them got past the jump to LinuxBIOS.

Alright, more info now.  I worked with Richard Smith for awhile, and did
the following using the latest BIOS available.  (my #defines were set at
reasonably conservative settings, and were fine for my board)

Enabled a call to ram_check.

Got the LB northbridge RAM configuration to be the same as it is for the
factory BIOS, to the extent possible, based on the datasheet for the
vt8601a and output of 'lspci -xxx'

Results from the ram_check seem to show that the ram is not being
properly intialized and/or refreshed.  I checked an area from 0x20000
through 0x21000.  As the ram check progresses, it starts out reading
values 0x0002ffcc, then gradually drops until it reads 0x00020000 and
finally 0x00000000.

At this point I'm rather stuck.

Ron (or anyone else, really), do you have a chance to look at this
and/or advise me on things I can do/try in order to get this working
again?  I can provide output from my test system, and am happy to test
as needed.

Thanks much

-Alex Mauer "hawke"

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

From smithbone at gmail.com  Thu May 18 00:16:20 2006
From: smithbone at gmail.com (Richard Smith)
Date: Wed, 17 May 2006 17:16:20 -0500
Subject: [LinuxBIOS] EPIA non-M?
In-Reply-To: <e4g6ku$tta$1@sea.gmane.org>
References: <e30v1u$d74$1@sea.gmane.org> <4454342B.3080107@lanl.gov>
	<e31mo9$2bj$1@sea.gmane.org>
	<8a0c36780604301307k4de0f25fx618aa50d97fd98be@mail.gmail.com>
	<e3p9ls$nhr$1@sea.gmane.org> <44602932.4060203@lanl.gov>
	<8a0c36780605090726p47464840kbd93d0607108aaee@mail.gmail.com>
	<e3tg6c$s1e$1@sea.gmane.org> <e4g6ku$tta$1@sea.gmane.org>
Message-ID: <8a0c36780605171516m11ec135ewb1e4a21c8e7ffd49@mail.gmail.com>

>
> At this point I'm rather stuck.
>
> Ron (or anyone else, really), do you have a chance to look at this
> and/or advise me on things I can do/try in order to get this working
> again?

I'll chime in here that we have pulled lots of different raminits from
past revs and replaced the one in the current rev but no success.

We have also reviewed the data sheet and as far as static config goes
we are set the same as the factory northbridge.  So its must be some
sort of magic method during the init.

One thing we haven't done is tested a complete tree build from some of
the older revs.  Mostly because the older trees don't seem to build
for Alex.

If anyone has a rev that they really think will work then we can pull
it and figure out why it won't build on Alex's system or perhaps build
it on a system that works and then send it to him for testing.

-- 
Richard A. Smith



From rminnich at gmail.com  Thu May 18 00:56:32 2006
From: rminnich at gmail.com (ron minnich)
Date: Wed, 17 May 2006 16:56:32 -0600
Subject: [LinuxBIOS] problem with compressed rom stream
Message-ID: <13426df10605171556h5d12b4a1s1154673150709374@mail.gmail.com>

I have an nrv compressed filo.elf that on linux I can uncompress and have
work.
~/src/LinuxBIOSv2/util/nrv2b/nrv2b d /tmp/filo.elf.nrv /tmp/xyz
       39496
in linuxbios, the uncompress is too short:

rom_stream: 0xfff90000 - 0xffff7fff
Uncompressing to RAM 0x00200000  olen = 0x000062fc done.
Cannot Load ELF Image
 print/x 39496
$1 = 0x9a48

Any idea what to look for?

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

From myles at pel.cs.byu.edu  Thu May 18 00:57:02 2006
From: myles at pel.cs.byu.edu (Myles Watson)
Date: Wed, 17 May 2006 16:57:02 -0600
Subject: [LinuxBIOS] Etherboot (FILO) with SATA on tyan s2895
Message-ID: <01M2JAU6MS688Y82H0@EMAIL1.BYU.EDU>

I am booting linuxbios with etherboot and filo as the payload. I tried to
follow the s2881 tutorial on the wiki.

Etherboot only finds my cd-rom. When I try to use hde:/ it tells me that
"Drive 4 does not exist". All drives up to j except hda (my cd-rom) give the
same error message. Sometimes if I try hdg it hangs.

I saw README.filo_in_etherboot where it says it only works on SATA port 1 or
2. I've tried on SATA 0 port 0 and 1, SATA 1 port 2 and 3.

I also seem to need to boot the factory BIOS in between each attempt, or I
won't get very far.

Is there something simple I've missed?

Thanks,
Myles

Output:

Etherboot 5.4.2
Drivers: TG3 FILO Images: NBI ELF
Protocols: DHCP TFTP
Relocating text ...
Scanning PCI: found 30 devices
Probing pci disk...
[FILO]FILO version 0.4.1
boot: hde3:/boot/vmlinuz... initrd=/boot/initrd...
IDE time out
No drive detected on IDE channel 2
boot: hdc:/ 
No drive detected on IDE channel 1





From yinghai.lu at amd.com  Thu May 18 01:08:58 2006
From: yinghai.lu at amd.com (Lu, Yinghai)
Date: Wed, 17 May 2006 16:08:58 -0700
Subject: [LinuxBIOS] Etherboot (FILO) with SATA on tyan s2895
Message-ID: <6F7DA19D05F3CF40B890C7CA2DB13A4203094CB0@ssvlexmb2.amd.com>

You can not boot from CK804 sata directly with FILO in Etherboot.

The code only support Sata that can work on compatible IDE mode. 

You need to use other media ( network, CF IDE flash) to load kernel with
ck804 sata and kexec support, and use kexec to load final kernel in your
sata disk.

YH

-----Original Message-----
From: linuxbios-bounces at linuxbios.org
[mailto:linuxbios-bounces at linuxbios.org] On Behalf Of Myles Watson
Sent: Wednesday, May 17, 2006 3:57 PM
To: linuxbios at linuxbios.org
Subject: [LinuxBIOS] Etherboot (FILO) with SATA on tyan s2895

I am booting linuxbios with etherboot and filo as the payload. I tried
to
follow the s2881 tutorial on the wiki.

Etherboot only finds my cd-rom. When I try to use hde:/ it tells me that
"Drive 4 does not exist". All drives up to j except hda (my cd-rom) give
the
same error message. Sometimes if I try hdg it hangs.

I saw README.filo_in_etherboot where it says it only works on SATA port
1 or
2. I've tried on SATA 0 port 0 and 1, SATA 1 port 2 and 3.

I also seem to need to boot the factory BIOS in between each attempt, or
I
won't get very far.

Is there something simple I've missed?

Thanks,
Myles

Output:

Etherboot 5.4.2
Drivers: TG3 FILO Images: NBI ELF
Protocols: DHCP TFTP
Relocating text ...
Scanning PCI: found 30 devices
Probing pci disk...
[FILO]FILO version 0.4.1
boot: hde3:/boot/vmlinuz... initrd=/boot/initrd...
IDE time out
No drive detected on IDE channel 2
boot: hdc:/ 
No drive detected on IDE channel 1



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





From rminnich at lanl.gov  Thu May 18 04:26:34 2006
From: rminnich at lanl.gov (Ronald G Minnich)
Date: Wed, 17 May 2006 20:26:34 -0600
Subject: [LinuxBIOS] UEFI discussion
In-Reply-To: <6F7DA19D05F3CF40B890C7CA2DB13A4203094CAD@ssvlexmb2.amd.com>
References: <6F7DA19D05F3CF40B890C7CA2DB13A4203094CAD@ssvlexmb2.amd.com>
Message-ID: <446BDB5A.20206@lanl.gov>

Lu, Yinghai wrote:
> fuefi is good.

fuefi? you really want us to say:
f u efi?

ron



From rminnich at lanl.gov  Thu May 18 04:29:17 2006
From: rminnich at lanl.gov (Ronald G Minnich)
Date: Wed, 17 May 2006 20:29:17 -0600
Subject: [LinuxBIOS] EPIA non-M?
In-Reply-To: <e4g6ku$tta$1@sea.gmane.org>
References: <e30v1u$d74$1@sea.gmane.org>	<4454342B.3080107@lanl.gov>	<e31mo9$2bj$1@sea.gmane.org>	<8a0c36780604301307k4de0f25fx618aa50d97fd98be@mail.gmail.com>	<e3p9ls$nhr$1@sea.gmane.org>	<44602932.4060203@lanl.gov>	<8a0c36780605090726p47464840kbd93d0607108aaee@mail.gmail.com>	<e3tg6c$s1e$1@sea.gmane.org>
	<e4g6ku$tta$1@sea.gmane.org>
Message-ID: <446BDBFD.9040107@lanl.gov>

Alex Mauer wrote:

> Ron (or anyone else, really), do you have a chance to look at this
> and/or advise me on things I can do/try in order to get this working
> again?  I can provide output from my test system, and am happy to test
> as needed.

Go to linuxbios v1, find the epia. Figure out the hard-codes I used for 
DRAM. Use them for v2 epia non-m, and see how it goes.

That chipset was rather buggy. It was a nightmare to get it to work.

ron



From rminnich at lanl.gov  Thu May 18 04:30:06 2006
From: rminnich at lanl.gov (Ronald G Minnich)
Date: Wed, 17 May 2006 20:30:06 -0600
Subject: [LinuxBIOS] EPIA non-M?
In-Reply-To: <8a0c36780605171516m11ec135ewb1e4a21c8e7ffd49@mail.gmail.com>
References: <e30v1u$d74$1@sea.gmane.org>
	<4454342B.3080107@lanl.gov>	<e31mo9$2bj$1@sea.gmane.org>	<8a0c36780604301307k4de0f25fx618aa50d97fd98be@mail.gmail.com>	<e3p9ls$nhr$1@sea.gmane.org>
	<44602932.4060203@lanl.gov>	<8a0c36780605090726p47464840kbd93d0607108aaee@mail.gmail.com>	<e3tg6c$s1e$1@sea.gmane.org>
	<e4g6ku$tta$1@sea.gmane.org>
	<8a0c36780605171516m11ec135ewb1e4a21c8e7ffd49@mail.gmail.com>
Message-ID: <446BDC2E.1020700@lanl.gov>

have you guys tried building from the old arch repo?

I would not forward-port code. Do a build using an entire old tree.

ron



From rminnich at lanl.gov  Thu May 18 04:33:54 2006
From: rminnich at lanl.gov (Ronald G Minnich)
Date: Wed, 17 May 2006 20:33:54 -0600
Subject: [LinuxBIOS] problem with compressed rom stream
In-Reply-To: <13426df10605171556h5d12b4a1s1154673150709374@mail.gmail.com>
References: <13426df10605171556h5d12b4a1s1154673150709374@mail.gmail.com>
Message-ID: <446BDD12.8090509@lanl.gov>

ron minnich wrote:
> I have an nrv compressed filo.elf that on linux I can uncompress and 
> have work.
> ~/src/LinuxBIOSv2/util/nrv2b/nrv2b d /tmp/filo.elf.nrv /tmp/xyz
>        39496
> in linuxbios, the uncompress is too short:
> 
> rom_stream: 0xfff90000 - 0xffff7fff
> Uncompressing to RAM 0x00200000  olen = 0x000062fc done.
> Cannot Load ELF Image
>  print/x 39496
> $1 = 0x9a48
> 
> Any idea what to look for?
> 
> ron
> 

I know what I need to look for. If I can find a spare brain, I won't 
make mistakes like this. I assumed I had to nrv2b the payload myself, 
but Stefan cleverly put it in the makefile. COOL.

I"m booting linux out of flash on the rumba! in 512k ...

I have fixed some minor nits with the implementation that resolve some 
error messages and a compilation failure if printk_debug was enabled. I 
will commit.

i want to fix the larger error of the include of ../lib/nrv2b.c, eeek!

We should not include .c files in the gcc half!

thanks

ron



From yinghailu at gmail.com  Thu May 18 05:40:49 2006
From: yinghailu at gmail.com (yhlu)
Date: Wed, 17 May 2006 20:40:49 -0700
Subject: [LinuxBIOS] problem with compressed rom stream
In-Reply-To: <446BDD12.8090509@lanl.gov>
References: <13426df10605171556h5d12b4a1s1154673150709374@mail.gmail.com>
	<446BDD12.8090509@lanl.gov>
Message-ID: <2ea3fae10605172040w7d3866cere5c42a3f3595679f@mail.gmail.com>

need to share nrv2b with CAR copy_and_run.c to uncompress
linuxbios_ram.nrb from rom to ram.

I also use that to uncompress code from rom to cache in AP.

You need to print out ilen, in case someone try to compress zelf. that
will produce one more big output instead.

YH

On 5/17/06, Ronald G Minnich <rminnich at lanl.gov> wrote:
> ron minnich wrote:
> > I have an nrv compressed filo.elf that on linux I can uncompress and
> > have work.
> > ~/src/LinuxBIOSv2/util/nrv2b/nrv2b d /tmp/filo.elf.nrv /tmp/xyz
> >        39496
> > in linuxbios, the uncompress is too short:
> >
> > rom_stream: 0xfff90000 - 0xffff7fff
> > Uncompressing to RAM 0x00200000  olen = 0x000062fc done.
> > Cannot Load ELF Image
> >  print/x 39496
> > $1 = 0x9a48
> >
> > Any idea what to look for?
> >
> > ron
> >
>
> I know what I need to look for. If I can find a spare brain, I won't
> make mistakes like this. I assumed I had to nrv2b the payload myself,
> but Stefan cleverly put it in the makefile. COOL.
>
> I"m booting linux out of flash on the rumba! in 512k ...
>
> I have fixed some minor nits with the implementation that resolve some
> error messages and a compilation failure if printk_debug was enabled. I
> will commit.
>
> i want to fix the larger error of the include of ../lib/nrv2b.c, eeek!
>
> We should not include .c files in the gcc half!
>
> thanks
>
> ron
>
> --
> linuxbios mailing list
> linuxbios at linuxbios.org
> http://www.openbios.org/mailman/listinfo/linuxbios
>



From rminnich at lanl.gov  Thu May 18 05:56:54 2006
From: rminnich at lanl.gov (Ronald G Minnich)
Date: Wed, 17 May 2006 21:56:54 -0600
Subject: [LinuxBIOS] problem with compressed rom stream
In-Reply-To: <2ea3fae10605172040w7d3866cere5c42a3f3595679f@mail.gmail.com>
References: <13426df10605171556h5d12b4a1s1154673150709374@mail.gmail.com>	
	<446BDD12.8090509@lanl.gov>
	<2ea3fae10605172040w7d3866cere5c42a3f3595679f@mail.gmail.com>
Message-ID: <446BF086.2030800@lanl.gov>

yhlu wrote:
> need to share nrv2b with CAR copy_and_run.c to uncompress
> linuxbios_ram.nrb from rom to ram.

ok. But we can still do this in a different way.

The reason is that I might want to use the unrv2b function even when I 
am not using compressed rom streams. The reason is that I will be nrv2b 
compressing the VSA object code on the OLPC. So that function can't be 
static. how do we handle this?

> 
> I also use that to uncompress code from rom to cache in AP.
> 
> You need to print out ilen, in case someone try to compress zelf. that
> will produce one more big output instead.

the problem is there is no ilen defined in the rom_stream.c code.

So you need to either create that variable or taek it out of the 
printk_debug (which I did).

thanks

ron



From yinghailu at gmail.com  Thu May 18 06:42:57 2006
From: yinghailu at gmail.com (yhlu)
Date: Wed, 17 May 2006 21:42:57 -0700
Subject: [LinuxBIOS] problem with compressed rom stream
In-Reply-To: <446BF086.2030800@lanl.gov>
References: <13426df10605171556h5d12b4a1s1154673150709374@mail.gmail.com>
	<446BDD12.8090509@lanl.gov>
	<2ea3fae10605172040w7d3866cere5c42a3f3595679f@mail.gmail.com>
	<446BF086.2030800@lanl.gov>
Message-ID: <2ea3fae10605172142p7e5cca09q17ff06b2272609df@mail.gmail.com>

which address for the final VSA code in RAM? under 1M?
you need execute the VSA code in hardwaremain or main in auto.c?

rom_stream need to create one ilen and get that via &ilen from unrv2b(, &ilen).

YH

On 5/17/06, Ronald G Minnich <rminnich at lanl.gov> wrote:
> yhlu wrote:
> > need to share nrv2b with CAR copy_and_run.c to uncompress
> > linuxbios_ram.nrb from rom to ram.
>
> ok. But we can still do this in a different way.
>
> The reason is that I might want to use the unrv2b function even when I
> am not using compressed rom streams. The reason is that I will be nrv2b
> compressing the VSA object code on the OLPC. So that function can't be
> static. how do we handle this?
>
> >
> > I also use that to uncompress code from rom to cache in AP.
> >
> > You need to print out ilen, in case someone try to compress zelf. that
> > will produce one more big output instead.
>
> the problem is there is no ilen defined in the rom_stream.c code.
>
> So you need to either create that variable or taek it out of the
> printk_debug (which I did).
>
> thanks
>
> ron
>



From c-d.hailfinger.devel.2006 at gmx.net  Thu May 18 11:47:15 2006
From: c-d.hailfinger.devel.2006 at gmx.net (Carl-Daniel Hailfinger)
Date: Thu, 18 May 2006 11:47:15 +0200
Subject: [LinuxBIOS] problem with compressed rom stream
In-Reply-To: <446BDD12.8090509@lanl.gov>
References: <13426df10605171556h5d12b4a1s1154673150709374@mail.gmail.com>
	<446BDD12.8090509@lanl.gov>
Message-ID: <446C42A3.4000401@gmx.net>

Ronald G Minnich wrote:
> 
> I"m booting linux out of flash on the rumba! in 512k ...

Cool!

Which kernel version? Any additional patches to get it
so small? Which gcc version? Could you post a .config?

I'd like to try this kernel for kexec-based booting of
a few of my systems. If it is successful, I can continue
working on LinuxBIOS support for my Asus boards.

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



From myles at pel.cs.byu.edu  Thu May 18 15:48:40 2006
From: myles at pel.cs.byu.edu (Myles Watson)
Date: Thu, 18 May 2006 07:48:40 -0600
Subject: [LinuxBIOS] Etherboot (FILO) with SATA on tyan s2895
In-Reply-To: <6F7DA19D05F3CF40B890C7CA2DB13A4203094CB0@ssvlexmb2.amd.com>
Message-ID: <01M2K5YMDCS88Y7MSM@EMAIL1.BYU.EDU>

It's starting to seem like a long chain of events from LinuxBIOS to
Etherboot to FILO to kernel on CF to myKernel.  I'd also like to be able to
get to grub eventually.  Is there a way to go from LinuxBIOS to grub more
directly on the s2895?

Thanks again for your help.

Myles

-----Original Message-----
From: Lu, Yinghai [mailto:yinghai.lu at amd.com] 
Sent: Wednesday, May 17, 2006 5:09 PM
To: myles at mouselemur.cs.byu.edu; linuxbios at linuxbios.org
Subject: RE: [LinuxBIOS] Etherboot (FILO) with SATA on tyan s2895

You can not boot from CK804 sata directly with FILO in Etherboot.

The code only support Sata that can work on compatible IDE mode. 

You need to use other media ( network, CF IDE flash) to load kernel with
ck804 sata and kexec support, and use kexec to load final kernel in your
sata disk.

YH

-----Original Message-----
From: linuxbios-bounces at linuxbios.org
[mailto:linuxbios-bounces at linuxbios.org] On Behalf Of Myles Watson
Sent: Wednesday, May 17, 2006 3:57 PM
To: linuxbios at linuxbios.org
Subject: [LinuxBIOS] Etherboot (FILO) with SATA on tyan s2895

I am booting linuxbios with etherboot and filo as the payload. I tried
to
follow the s2881 tutorial on the wiki.

Etherboot only finds my cd-rom. When I try to use hde:/ it tells me that
"Drive 4 does not exist". All drives up to j except hda (my cd-rom) give
the
same error message. Sometimes if I try hdg it hangs.

I saw README.filo_in_etherboot where it says it only works on SATA port
1 or
2. I've tried on SATA 0 port 0 and 1, SATA 1 port 2 and 3.

I also seem to need to boot the factory BIOS in between each attempt, or
I
won't get very far.

Is there something simple I've missed?

Thanks,
Myles

Output:

Etherboot 5.4.2
Drivers: TG3 FILO Images: NBI ELF
Protocols: DHCP TFTP
Relocating text ...
Scanning PCI: found 30 devices
Probing pci disk...
[FILO]FILO version 0.4.1
boot: hde3:/boot/vmlinuz... initrd=/boot/initrd...
IDE time out
No drive detected on IDE channel 2
boot: hdc:/ 
No drive detected on IDE channel 1



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





From stepan at coresystems.de  Thu May 18 17:13:21 2006
From: stepan at coresystems.de (Stefan Reinauer)
Date: Thu, 18 May 2006 17:13:21 +0200
Subject: [LinuxBIOS] Etherboot (FILO) with SATA on tyan s2895
In-Reply-To: <01M2K5YMDCS88Y7MSM@EMAIL1.BYU.EDU>
References: <6F7DA19D05F3CF40B890C7CA2DB13A4203094CB0@ssvlexmb2.amd.com>
	<01M2K5YMDCS88Y7MSM@EMAIL1.BYU.EDU>
Message-ID: <20060518151321.GA31083@coresystems.de>

* Myles Watson <myles at pel.cs.byu.edu> [060518 15:48]:
> It's starting to seem like a long chain of events from LinuxBIOS to
> Etherboot to FILO to kernel on CF to myKernel.  I'd also like to be able to
> get to grub eventually.  Is there a way to go from LinuxBIOS to grub more
> directly on the s2895?

Check out the real FILO (non-Etherboot version) - it features grub menu
support.

-- 
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  Thu May 18 18:14:47 2006
From: yinghai.lu at amd.com (Lu, Yinghai)
Date: Thu, 18 May 2006 09:14:47 -0700
Subject: [LinuxBIOS] Etherboot (FILO) with SATA on tyan s2895
Message-ID: <6F7DA19D05F3CF40B890C7CA2DB13A4203094CB4@ssvlexmb2.amd.com>

No FILO need...

Use mkelfImage to put tiny kernel and initrd to make one elf. And
LinuxBIOS can treat that as one payload and just like FILO and
Etherboot.

Someone (from F5) has used 2M flash ROM to put LinuxBIOS+kernel+initrd.
You could do that if you want to spare the CF IDE flash.

With the tiny kernel support, we can have support for all driver support
in kernel for SCSI, USB, Firewire, iSCSI, AOE, IB, Myrinet,
quadric...any media.

We don't need to port the driver to the boot loader. And everyone could
focus on driver in kernel instead of waste time to port driver back and
forth.

That is correct way.

Just like we are talking about UEFI support. We could add the table and
services in LinuxBIOS, but we like to run uefi as linux application on
kernel to re use the driver in kernel.

We don't need to spend dev time on FILO and Etherboot anymore. 

YH

-----Original Message-----
From: Myles Watson [mailto:myles at mouselemur.cs.byu.edu] 
Sent: Thursday, May 18, 2006 6:49 AM
To: Lu, Yinghai; linuxbios at linuxbios.org
Subject: RE: [LinuxBIOS] Etherboot (FILO) with SATA on tyan s2895

It's starting to seem like a long chain of events from LinuxBIOS to
Etherboot to FILO to kernel on CF to myKernel.  I'd also like to be able
to
get to grub eventually.  Is there a way to go from LinuxBIOS to grub
more
directly on the s2895?

Thanks again for your help.

Myles

-----Original Message-----
From: Lu, Yinghai [mailto:yinghai.lu at amd.com] 
Sent: Wednesday, May 17, 2006 5:09 PM
To: myles at mouselemur.cs.byu.edu; linuxbios at linuxbios.org
Subject: RE: [LinuxBIOS] Etherboot (FILO) with SATA on tyan s2895

You can not boot from CK804 sata directly with FILO in Etherboot.

The code only support Sata that can work on compatible IDE mode. 

You need to use other media ( network, CF IDE flash) to load kernel with
ck804 sata and kexec support, and use kexec to load final kernel in your
sata disk.

YH

-----Original Message-----
From: linuxbios-bounces at linuxbios.org
[mailto:linuxbios-bounces at linuxbios.org] On Behalf Of Myles Watson
Sent: Wednesday, May 17, 2006 3:57 PM
To: linuxbios at linuxbios.org
Subject: [LinuxBIOS] Etherboot (FILO) with SATA on tyan s2895

I am booting linuxbios with etherboot and filo as the payload. I tried
to
follow the s2881 tutorial on the wiki.

Etherboot only finds my cd-rom. When I try to use hde:/ it tells me that
"Drive 4 does not exist". All drives up to j except hda (my cd-rom) give
the
same error message. Sometimes if I try hdg it hangs.

I saw README.filo_in_etherboot where it says it only works on SATA port
1 or
2. I've tried on SATA 0 port 0 and 1, SATA 1 port 2 and 3.

I also seem to need to boot the factory BIOS in between each attempt, or
I
won't get very far.

Is there something simple I've missed?

Thanks,
Myles

Output:

Etherboot 5.4.2
Drivers: TG3 FILO Images: NBI ELF
Protocols: DHCP TFTP
Relocating text ...
Scanning PCI: found 30 devices
Probing pci disk...
[FILO]FILO version 0.4.1
boot: hde3:/boot/vmlinuz... initrd=/boot/initrd...
IDE time out
No drive detected on IDE channel 2
boot: hdc:/ 
No drive detected on IDE channel 1



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







From yinghai.lu at amd.com  Thu May 18 19:16:52 2006
From: yinghai.lu at amd.com (Lu, Yinghai)
Date: Thu, 18 May 2006 10:16:52 -0700
Subject: [LinuxBIOS] co processor support and other
Message-ID: <6F7DA19D05F3CF40B890C7CA2DB13A4203094CB5@ssvlexmb2.amd.com>

Just check in
1. r2308: Option CONFIG_CONSOLE_VGA_ONBOARD_AT_FIRST
	It decides use onboard VGA or add on vga adapter
2. r2309: reduce clear ECC time from 2.1x to 1.1x. need to enable
SERIAL_CPU_INIT
3. r2310: enable ht chain for drc co processor in s2891.

Please check that.

Steve,
I still wonder how do you init the memory on your co processor without
the spd rom access. ( hard coded)


Thanks

Yinghai Lu




From stepan at coresystems.de  Thu May 18 19:43:33 2006
From: stepan at coresystems.de (Stefan Reinauer)
Date: Thu, 18 May 2006 19:43:33 +0200
Subject: [LinuxBIOS] problem with compressed rom stream
In-Reply-To: <446BDD12.8090509@lanl.gov>
References: <13426df10605171556h5d12b4a1s1154673150709374@mail.gmail.com>
	<446BDD12.8090509@lanl.gov>
Message-ID: <20060518174333.GB6373@coresystems.de>

* Ronald G Minnich <rminnich at lanl.gov> [060518 04:33]:
> I"m booting linux out of flash on the rumba! in 512k ...
 
Is this with an initrd/kexec stuff?


-- 
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 lanl.gov  Fri May 19 00:00:33 2006
From: rminnich at lanl.gov (Ronald G Minnich)
Date: Thu, 18 May 2006 16:00:33 -0600
Subject: [LinuxBIOS] problem with compressed rom stream
In-Reply-To: <20060518174333.GB6373@coresystems.de>
References: <13426df10605171556h5d12b4a1s1154673150709374@mail.gmail.com>
	<446BDD12.8090509@lanl.gov> <20060518174333.GB6373@coresystems.de>
Message-ID: <446CEE81.8000306@lanl.gov>

Stefan Reinauer wrote:
> * Ronald G Minnich <rminnich at lanl.gov> [060518 04:33]:
> 
>>I"m booting linux out of flash on the rumba! in 512k ...
> 
>  
> Is this with an initrd/kexec stuff?
> 
> 

not yet. This is purely a vmlinux, nrv2b compressed in the BIOS flash.

ron



From rminnich at lanl.gov  Fri May 19 00:03:49 2006
From: rminnich at lanl.gov (Ronald G Minnich)
Date: Thu, 18 May 2006 16:03:49 -0600
Subject: [LinuxBIOS] Etherboot (FILO) with SATA on tyan s2895
In-Reply-To: <6F7DA19D05F3CF40B890C7CA2DB13A4203094CB4@ssvlexmb2.amd.com>
References: <6F7DA19D05F3CF40B890C7CA2DB13A4203094CB4@ssvlexmb2.amd.com>
Message-ID: <446CEF45.9030207@lanl.gov>

Lu, Yinghai wrote:
> No FILO need...
> 
> Use mkelfImage to put tiny kernel and initrd to make one elf. And
> LinuxBIOS can treat that as one payload and just like FILO and
> Etherboot.

plus, I am modifying mkelfimage to dispense with some of the messier 
bits ... now that we have compression back in linuxbios we don't need 
bzimage any more.


> We don't need to port the driver to the boot loader. And everyone could
> focus on driver in kernel instead of waste time to port driver back and
> forth.
> 
> That is correct way.

absolutely!



> 
> Just like we are talking about UEFI support. We could add the table and
> services in LinuxBIOS, but we like to run uefi as linux application on
> kernel to re use the driver in kernel.
> 
> We don't need to spend dev time on FILO and Etherboot anymore. 


yes, OLPC will have linux in flash. We are finally getting back to our 
original dream. Filo and Etherboot were temporary.

ron



From yinghai.lu at amd.com  Fri May 19 00:55:26 2006
From: yinghai.lu at amd.com (Lu, Yinghai)
Date: Thu, 18 May 2006 15:55:26 -0700
Subject: [LinuxBIOS] Etherboot (FILO) with SATA on tyan s2895
Message-ID: <6F7DA19D05F3CF40B890C7CA2DB13A4203094CBC@ssvlexmb2.amd.com>

So the vmlinux+initrd.gz--> elf, and nrv2b to be the payload...

What is size of final elf?
1. bzImage+initrd.gz
2. vmlinux+initrd.gz --> nrv2b

I wonder if 2 would be bigger than 1.

YH







From rminnich at lanl.gov  Fri May 19 00:52:52 2006
From: rminnich at lanl.gov (Ronald G Minnich)
Date: Thu, 18 May 2006 16:52:52 -0600
Subject: [LinuxBIOS] Etherboot (FILO) with SATA on tyan s2895
In-Reply-To: <6F7DA19D05F3CF40B890C7CA2DB13A4203094CBC@ssvlexmb2.amd.com>
References: <6F7DA19D05F3CF40B890C7CA2DB13A4203094CBC@ssvlexmb2.amd.com>
Message-ID: <446CFAC4.7060704@lanl.gov>

Lu, Yinghai wrote:
> So the vmlinux+initrd.gz--> elf, and nrv2b to be the payload...
> 
> What is size of final elf?
> 1. bzImage+initrd.gz
> 2. vmlinux+initrd.gz --> nrv2b
> 
> I wonder if 2 would be bigger than 1.

mkelfImage has a number of additional components, actually a fair bit of 
code. So far, (2) is winning -- put the cmdline (linux params) in an elf 
segment @0x90000, vmlinux and initrd in other segments.

Actually, in V1, I had a gunzip step built into linuxbios. I still think 
that was not a bad deal.

ron



From stepan at coresystems.de  Fri May 19 01:36:01 2006
From: stepan at coresystems.de (Stefan Reinauer)
Date: Fri, 19 May 2006 01:36:01 +0200
Subject: [LinuxBIOS] Etherboot (FILO) with SATA on tyan s2895
In-Reply-To: <446CFAC4.7060704@lanl.gov>
References: <6F7DA19D05F3CF40B890C7CA2DB13A4203094CBC@ssvlexmb2.amd.com>
	<446CFAC4.7060704@lanl.gov>
Message-ID: <20060518233601.GA5857@coresystems.de>

* Ronald G Minnich <rminnich at lanl.gov> [060519 00:52]:
> mkelfImage has a number of additional components, actually a fair bit of 
> code. So far, (2) is winning -- put the cmdline (linux params) in an elf 
> segment @0x90000, vmlinux and initrd in other segments.
> 
> Actually, in V1, I had a gunzip step built into linuxbios. I still think 
> that was not a bad deal.

Can you elaborate? And why did it go?

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 c-d.hailfinger.devel.2006 at gmx.net  Sun May 21 21:03:04 2006
From: c-d.hailfinger.devel.2006 at gmx.net (Carl-Daniel Hailfinger)
Date: Sun, 21 May 2006 21:03:04 +0200
Subject: [LinuxBIOS] selection of compression algorithm
Message-ID: <4470B968.5040100@gmx.net>

Hi,

what was the motivation to select nrv2b for compression?
Speed? Size of decompressor? Coding style?

Size   File
843910 vmlinux.bin
437684 vmlinux.bin.nrv2b
430890 vmlinux.bin.gz
414679 vmlinux.bin.bz2
357609 vmlinux.bin.7z

If the 7z decompressor is less than 80 kb bigger than
the nrv2b decompressor, would it make sense to switch?


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



From c-d.hailfinger.devel.2006 at gmx.net  Mon May 22 04:37:22 2006
From: c-d.hailfinger.devel.2006 at gmx.net (Carl-Daniel Hailfinger)
Date: Mon, 22 May 2006 04:37:22 +0200
Subject: [LinuxBIOS] selection of compression algorithm
In-Reply-To: <2ea3fae10605211352g1731bc62v16ddcda6c2e4b734@mail.gmail.com>
References: <4470B968.5040100@gmx.net>
	<2ea3fae10605211352g1731bc62v16ddcda6c2e4b734@mail.gmail.com>
Message-ID: <447123E2.6060000@gmx.net>

yhlu wrote:
> then how about the lines for 7z uncompress code?
> 
> YH

Working on it. 7z decompressor is really small (8 kb compiled on
i386) and written in ISO C (1884 lines of code), but compressor is
big and written in C++.

Does it still make sense to try to use 7z?

How much RAM is the decompressor allowed to use?

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



From yinghailu at gmail.com  Mon May 22 05:49:32 2006
From: yinghailu at gmail.com (yhlu)
Date: Sun, 21 May 2006 20:49:32 -0700
Subject: [LinuxBIOS] selection of compression algorithm
In-Reply-To: <447123E2.6060000@gmx.net>
References: <4470B968.5040100@gmx.net>
	<2ea3fae10605211352g1731bc62v16ddcda6c2e4b734@mail.gmail.com>
	<447123E2.6060000@gmx.net>
Message-ID: <2ea3fae10605212049o59d62ddfy673023056c0ffba1@mail.gmail.com>

8k bytes is too big...

unrv2b uses about several bytes for pointers only..

YH

On 5/21/06, Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006 at gmx.net> wrote:
> yhlu wrote:
> > then how about the lines for 7z uncompress code?
> >
> > YH
>
> Working on it. 7z decompressor is really small (8 kb compiled on
> i386) and written in ISO C (1884 lines of code), but compressor is
> big and written in C++.
>
> Does it still make sense to try to use 7z?
>
> How much RAM is the decompressor allowed to use?
>
> Regards,
> Carl-Daniel
> --
> http://www.hailfinger.org/
>



From rminnich at lanl.gov  Mon May 22 07:22:15 2006
From: rminnich at lanl.gov (Ronald G Minnich)
Date: Sun, 21 May 2006 23:22:15 -0600
Subject: [LinuxBIOS] selection of compression algorithm
In-Reply-To: <4470B968.5040100@gmx.net>
References: <4470B968.5040100@gmx.net>
Message-ID: <44714A87.1040402@lanl.gov>

Carl-Daniel Hailfinger wrote:
> Hi,
> 
> what was the motivation to select nrv2b for compression?
> Speed? Size of decompressor? Coding style?
> 
> Size   File
> 843910 vmlinux.bin
> 437684 vmlinux.bin.nrv2b
> 430890 vmlinux.bin.gz
> 414679 vmlinux.bin.bz2
> 357609 vmlinux.bin.7z
> 
> If the 7z decompressor is less than 80 kb bigger than
> the nrv2b decompressor, would it make sense to switch?


It's fine with me. As i said, I had a gzip decompressor in early 
linuxbios, and we can look at getting it back. I just stole the one from 
the kernel. nrv2b is nice, I understand, for the romcc section where you 
don't have many variables to play with, but it's been so long since I 
looked at the gunzip code that I have no idea if this is true.

ron



From rminnich at lanl.gov  Mon May 22 07:23:33 2006
From: rminnich at lanl.gov (Ronald G Minnich)
Date: Sun, 21 May 2006 23:23:33 -0600
Subject: [LinuxBIOS] selection of compression algorithm
In-Reply-To: <447123E2.6060000@gmx.net>
References: <4470B968.5040100@gmx.net>	<2ea3fae10605211352g1731bc62v16ddcda6c2e4b734@mail.gmail.com>
	<447123E2.6060000@gmx.net>
Message-ID: <44714AD5.8030201@lanl.gov>

Carl-Daniel Hailfinger wrote:
> yhlu wrote:
> 
>>then how about the lines for 7z uncompress code?
>>
>>YH
> 
> 
> Working on it. 7z decompressor is really small (8 kb compiled on
> i386) and written in ISO C (1884 lines of code), but compressor is
> big and written in C++.
> 
> Does it still make sense to try to use 7z?

yes, this is the perfect tradeoff. Highly complex, compute-intensive 
compressor and simple, small decompressor. Exactly what we want.


> 
> How much RAM is the decompressor allowed to use?

for the romcc section, you have about 6 32-bit words (or so). for the 
gcc section, you have all of memory more or less.

ron



From myneil at gmail.com  Mon May 22 09:53:00 2006
From: myneil at gmail.com (Neil)
Date: Mon, 22 May 2006 15:53:00 +0800
Subject: [LinuxBIOS] linux bios hang when jump in kernel
Message-ID: <5c5dcf370605220053r3a58b786j143d902a35951ff3@mail.gmail.com>

Dear all :

My linuxbios can jump to kernel now ,but it hang then ,and can't enter in
OS.

Use phoenix bios
============================== =====
ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx
PCI_IDE: unknown IDE controller on PCI bus 00 device 11, VID=1166, DID=0214
PCI_IDE: chipset revision 0
PCI_IDE: not 100% native mode: will probe irqs later
    ide0: BM-DMA at 0x2000-0x2007, BIOS settings: hda:DMA, hdb:pio
PCI_IDE: simplex device:  DMA disabled
ide1: PCI_IDE Bus-Master DMA disabled (BIOS)
PCI_IDE: unknown IDE controller on PCI bus 01 device 70, VID=1166, DID=024b
PCI_IDE: chipset revision 0
PCI_IDE: 100% native mode on irq 5
    ide2: BM-DMA at 0x3000-0x3007, BIOS settings: hde:pio, hdf:pio
    ide3: BM-DMA at 0x3008-0x300f, BIOS settings: hdg:pio, hdh:pio
PCI_IDE: unknown IDE controller on PCI bus 01 device 71, VID=1166, DID=024b
PCI_IDE: chipset revision 0
PCI_IDE: 100% native mode on irq 5
    ide4: BM-DMA at 0x3020-0x3027, BIOS settings: hdi:pio, hdj:pio
    ide5: BM-DMA at 0x3028-0x302f, BIOS settings: hdk:pio, hdl:pio
hda: WDC WD400BB-00FJA0, ATA DISK drive
ide0 at 0x1f0-0x1f7,0x3f6 on irq 14
hda: 78165360 sectors (40021 MB) w/2048KiB Cache, CHS=4865/255/63
ide-floppy driver 0.99.newide
Partition check:
 hda: hda1 hda2 hda3
Floppy drive(s): fd0 is 1.44M
...................................

Use linuxbios
======================================================
PCI_IDE: unknown IDE controller on PCI bus 00 device 11, VID=1166, DID=0214
PCI_IDE: chipset revision 0
PCI_IDE: not 100% native mode: will probe irqs later
    ide0: BM-DMA at 0x4010-0x4017, BIOS settings: hda:pio, hdb:pio
PCI_IDE: simplex device:  DMA disabled
ide1: PCI_IDE Bus-Master DMA disabled (BIOS)
hda: C/H/S=0/0/0 from BIOS ignored
hda: WDC WD400BB-00FJA0, ATA DISK drive
ide0 at 0x1f0-0x1f7,0x3f6 on irq 14

Then it hang here . could anyone tell me whant is the problem ?

Thank you .
Neil
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20060522/99be3a38/attachment.html>

From stepan at coresystems.de  Mon May 22 11:24:55 2006
From: stepan at coresystems.de (Stefan Reinauer)
Date: Mon, 22 May 2006 11:24:55 +0200
Subject: [LinuxBIOS] selection of compression algorithm
In-Reply-To: <2ea3fae10605212049o59d62ddfy673023056c0ffba1@mail.gmail.com>
References: <4470B968.5040100@gmx.net>
	<2ea3fae10605211352g1731bc62v16ddcda6c2e4b734@mail.gmail.com>
	<447123E2.6060000@gmx.net>
	<2ea3fae10605212049o59d62ddfy673023056c0ffba1@mail.gmail.com>
Message-ID: <20060522092455.GA32661@coresystems.de>

* yhlu <yinghailu at gmail.com> [060522 05:49]:
> 8k bytes is too big...
 
Its a lot smaller than the 80k you save compared to nrv2b, so the result
is still 72kb smaller.

> unrv2b uses about several bytes for pointers only..



-- 
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 stepan at coresystems.de  Mon May 22 11:27:25 2006
From: stepan at coresystems.de (Stefan Reinauer)
Date: Mon, 22 May 2006 11:27:25 +0200
Subject: [LinuxBIOS] selection of compression algorithm
In-Reply-To: <44714A87.1040402@lanl.gov>
References: <4470B968.5040100@gmx.net> <44714A87.1040402@lanl.gov>
Message-ID: <20060522092725.GB32661@coresystems.de>

* Ronald G Minnich <rminnich at lanl.gov> [060522 07:22]:
> It's fine with me. As i said, I had a gzip decompressor in early 
> linuxbios, and we can look at getting it back. I just stole the one from 
> the kernel. nrv2b is nice, I understand, for the romcc section where you 
> don't have many variables to play with, but it's been so long since I 
> looked at the gunzip code that I have no idea if this is true.

We never actually compile nrv2b with romcc, do we? At the point we run
nrv2b ram has to be enabled anyways - we uncompress the code somewhere.
So our limits are far bigger than that.

-- 
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 yinghailu at gmail.com  Mon May 22 12:22:46 2006
From: yinghailu at gmail.com (yhlu)
Date: Mon, 22 May 2006 03:22:46 -0700
Subject: [LinuxBIOS] selection of compression algorithm
In-Reply-To: <20060522092725.GB32661@coresystems.de>
References: <4470B968.5040100@gmx.net> <44714A87.1040402@lanl.gov>
	<20060522092725.GB32661@coresystems.de>
Message-ID: <2ea3fae10605220322x7ac5e2ds40410ac10ad93485@mail.gmail.com>

in crt0.s, and it is used to uncompress linuxbios_ram when using romcc.

YH

On 5/22/06, Stefan Reinauer <stepan at coresystems.de> wrote:
> * Ronald G Minnich <rminnich at lanl.gov> [060522 07:22]:
> > It's fine with me. As i said, I had a gzip decompressor in early
> > linuxbios, and we can look at getting it back. I just stole the one from
> > the kernel. nrv2b is nice, I understand, for the romcc section where you
> > don't have many variables to play with, but it's been so long since I
> > looked at the gunzip code that I have no idea if this is true.
>
> We never actually compile nrv2b with romcc, do we? At the point we run
> nrv2b ram has to be enabled anyways - we uncompress the code somewhere.
> So our limits are far bigger than that.
>
> --
> 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



From stepan at coresystems.de  Mon May 22 13:40:06 2006
From: stepan at coresystems.de (Stefan Reinauer)
Date: Mon, 22 May 2006 13:40:06 +0200
Subject: [LinuxBIOS] co processor support and other
In-Reply-To: <6F7DA19D05F3CF40B890C7CA2DB13A4203094CB5@ssvlexmb2.amd.com>
References: <6F7DA19D05F3CF40B890C7CA2DB13A4203094CB5@ssvlexmb2.amd.com>
Message-ID: <20060522114006.GA7102@coresystems.de>

* Lu, Yinghai <yinghai.lu at amd.com> [060518 19:16]:
> Just check in
> 1. r2308: Option CONFIG_CONSOLE_VGA_ONBOARD_AT_FIRST
> 	It decides use onboard VGA or add on vga adapter
> 2. r2309: reduce clear ECC time from 2.1x to 1.1x. need to enable
> SERIAL_CPU_INIT
> 3. r2310: enable ht chain for drc co processor in s2891.
> 
> Please check that.
> 
> Steve,
> I still wonder how do you init the memory on your co processor without
> the spd rom access. ( hard coded)

What coprocessor is that? A Xilinx FPGA? Are 2891 delivered with those
per default? Can LinuxBIOs fuel them with code now?

This sounds _very_ interesting.

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 windex at windex.org  Mon May 22 16:20:39 2006
From: windex at windex.org (Justin C. Darby)
Date: Mon, 22 May 2006 09:20:39 -0500
Subject: [LinuxBIOS] co processor support and other
In-Reply-To: <20060522114006.GA7102@coresystems.de>
References: <6F7DA19D05F3CF40B890C7CA2DB13A4203094CB5@ssvlexmb2.amd.com>
	<20060522114006.GA7102@coresystems.de>
Message-ID: <26c8ffd60605220720s6bde8d39h287b108ec45598b@mail.gmail.com>

I think he's talking about enabling the use of:

http://www.drccomputer.com/pages/products.html

with the board. That chip has already had my interest for awhile. :)

Justin

On 5/22/06, Stefan Reinauer <stepan at coresystems.de> wrote:
>
> * Lu, Yinghai <yinghai.lu at amd.com> [060518 19:16]:
> > Just check in
> > 1. r2308: Option CONFIG_CONSOLE_VGA_ONBOARD_AT_FIRST
> >       It decides use onboard VGA or add on vga adapter
> > 2. r2309: reduce clear ECC time from 2.1x to 1.1x. need to enable
> > SERIAL_CPU_INIT
> > 3. r2310: enable ht chain for drc co processor in s2891.
> >
> > Please check that.
> >
> > Steve,
> > I still wonder how do you init the memory on your co processor without
> > the spd rom access. ( hard coded)
>
> What coprocessor is that? A Xilinx FPGA? Are 2891 delivered with those
> per default? Can LinuxBIOs fuel them with code now?
>
> This sounds _very_ interesting.
>
> 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/20060522/32246f79/attachment.html>

From yinghai.lu at amd.com  Mon May 22 18:27:13 2006
From: yinghai.lu at amd.com (Lu, Yinghai)
Date: Mon, 22 May 2006 09:27:13 -0700
Subject: [LinuxBIOS] co processor support and other
Message-ID: <6F7DA19D05F3CF40B890C7CA2DB13A4203094CD2@ssvlexmb2.amd.com>

Yes. That is very interesting...

 

1.	Some guys is trying to use HTX connector to add co-processor
card. 
2.	Some guys is using GPU on PCI-E...

 

Current code treat that coproc as one extra HT chain...

 

YH

 

 

 

________________________________

From: linuxbios-bounces at linuxbios.org
[mailto:linuxbios-bounces at linuxbios.org] On Behalf Of Justin C. Darby
Sent: Monday, May 22, 2006 7:21 AM
To: Stefan Reinauer
Cc: linuxbios at linuxbios.org; Steve Casselman; Lu, Yinghai
Subject: Re: [LinuxBIOS] co processor support and other

 

I think he's talking about enabling the use of: 

http://www.drccomputer.com/pages/products.html

with the board. That chip has already had my interest for awhile. :) 

Justin

On 5/22/06, Stefan Reinauer <stepan at coresystems.de> wrote:

* Lu, Yinghai <yinghai.lu at amd.com> [060518 19:16]:
> Just check in
> 1. r2308: Option CONFIG_CONSOLE_VGA_ONBOARD_AT_FIRST
>       It decides use onboard VGA or add on vga adapter 
> 2. r2309: reduce clear ECC time from 2.1x to 1.1x. need to enable
> SERIAL_CPU_INIT
> 3. r2310: enable ht chain for drc co processor in s2891.
>
> Please check that.
>
> Steve, 
> I still wonder how do you init the memory on your co processor without
> the spd rom access. ( hard coded)

What coprocessor is that? A Xilinx FPGA? Are 2891 delivered with those
per default? Can LinuxBIOs fuel them with code now? 

This sounds _very_ interesting.

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/20060522/ac132469/attachment.html>

From c-d.hailfinger.devel.2006 at gmx.net  Mon May 22 21:29:28 2006
From: c-d.hailfinger.devel.2006 at gmx.net (Carl-Daniel Hailfinger)
Date: Mon, 22 May 2006 21:29:28 +0200
Subject: [LinuxBIOS] selection of compression algorithm
In-Reply-To: <2ea3fae10605220322x7ac5e2ds40410ac10ad93485@mail.gmail.com>
References: <4470B968.5040100@gmx.net>
	<44714A87.1040402@lanl.gov>	<20060522092725.GB32661@coresystems.de>
	<2ea3fae10605220322x7ac5e2ds40410ac10ad93485@mail.gmail.com>
Message-ID: <44721118.8010207@gmx.net>

> On 5/22/06, Stefan Reinauer <stepan at coresystems.de> wrote:
>> We never actually compile nrv2b with romcc, do we? At the point we run
>> nrv2b ram has to be enabled anyways - we uncompress the code somewhere.
>> So our limits are far bigger than that.

yhlu wrote:
> in crt0.s, and it is used to uncompress linuxbios_ram when using romcc.

You mean copy_and_run() is compiled with romcc? Can we change that?

What's the difference between CONFIG_COMPRESSED_ROM_STREAM and
CONFIG_COMPRESS? Can we use lzma compression for both?


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



From yinghai.lu at amd.com  Mon May 22 22:04:42 2006
From: yinghai.lu at amd.com (Lu, Yinghai)
Date: Mon, 22 May 2006 13:04:42 -0700
Subject: [LinuxBIOS] selection of compression algorithm
Message-ID: <6F7DA19D05F3CF40B890C7CA2DB13A4203094CD8@ssvlexmb2.amd.com>

Copy_and_run is used by CAR and included in cache_as_ram_auto.c and
compiled with gcc. That should be changed to use lzma easily.

CONFIG_COMPRESSED_ROM_STREAM is used for pay load. --- stream_init will
do the uncompressed. ( stream_init is in ram)

CONFIG_COMPRESS is for linuxbios_ram.rom --- copy_and_run will do the
uncompress. ( copy_and_run is ROM, and used ram as stack and local
variable)

You may create one file only that is corresponding to lib/nrv2b.c...

YH

-----Original Message-----
From: linuxbios-bounces at linuxbios.org
[mailto:linuxbios-bounces at linuxbios.org] On Behalf Of Carl-Daniel
Hailfinger
Sent: Monday, May 22, 2006 12:29 PM
To: yhlu
Cc: Stefan Reinauer; LinuxBIOS
Subject: Re: [LinuxBIOS] selection of compression algorithm

> On 5/22/06, Stefan Reinauer <stepan at coresystems.de> wrote:
>> We never actually compile nrv2b with romcc, do we? At the point we
run
>> nrv2b ram has to be enabled anyways - we uncompress the code
somewhere.
>> So our limits are far bigger than that.

yhlu wrote:
> in crt0.s, and it is used to uncompress linuxbios_ram when using
romcc.

You mean copy_and_run() is compiled with romcc? Can we change that?

What's the difference between CONFIG_COMPRESSED_ROM_STREAM and
CONFIG_COMPRESS? Can we use lzma compression for both?


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

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





From stepan at coresystems.de  Mon May 22 22:05:04 2006
From: stepan at coresystems.de (Stefan Reinauer)
Date: Mon, 22 May 2006 22:05:04 +0200
Subject: [LinuxBIOS] selection of compression algorithm
In-Reply-To: <44721118.8010207@gmx.net>
References: <4470B968.5040100@gmx.net> <44714A87.1040402@lanl.gov>
	<20060522092725.GB32661@coresystems.de>
	<2ea3fae10605220322x7ac5e2ds40410ac10ad93485@mail.gmail.com>
	<44721118.8010207@gmx.net>
Message-ID: <20060522200504.GA27672@coresystems.de>

* Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006 at gmx.net> [060522 21:29]:
> > On 5/22/06, Stefan Reinauer <stepan at coresystems.de> wrote:
> >> We never actually compile nrv2b with romcc, do we? At the point we run
> >> nrv2b ram has to be enabled anyways - we uncompress the code somewhere.
> >> So our limits are far bigger than that.
> 
> yhlu wrote:
> > in crt0.s, and it is used to uncompress linuxbios_ram when using romcc.
> 
> You mean copy_and_run() is compiled with romcc? Can we change that?
 
No, it is not. But src/arch/i386/init/crt0.S.lb contains another
assembly written version of an nrv2b decompressor. 

crt0.s should be changed to call the C version of unrv2b. 

Then it can easily be changed later to use any other algorithm.

Using assembly at this point even though ram is enabled already must be
some code fragment from old times when we did a lot more assembly.

This might require though that we have 

1. auto.c stage           (romcc)
2. uncompression stage    (gcc)
3. compressed linuxbios stage (gcc, initially compressed)

This reads ugly in a mail but is by no means uglier than keeping
assembler versions of decompressors in the code.

> What's the difference between CONFIG_COMPRESSED_ROM_STREAM and
> CONFIG_COMPRESS? Can we use lzma compression for both?

CONFIG_COMPRESSED_ROM_STREAM says: the payload is compressed.
CONFIG_COMPRESS says: LinuxBIOS is compressed.




-- 
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 c-d.hailfinger.devel.2006 at gmx.net  Tue May 23 04:43:30 2006
From: c-d.hailfinger.devel.2006 at gmx.net (Carl-Daniel Hailfinger)
Date: Tue, 23 May 2006 04:43:30 +0200
Subject: [LinuxBIOS] selection of compression algorithm
In-Reply-To: <44714AD5.8030201@lanl.gov>
References: <4470B968.5040100@gmx.net>	<2ea3fae10605211352g1731bc62v16ddcda6c2e4b734@mail.gmail.com>	<447123E2.6060000@gmx.net>
	<44714AD5.8030201@lanl.gov>
Message-ID: <447276D2.4090403@gmx.net>

Ronald G Minnich wrote:
> Carl-Daniel Hailfinger wrote:
>> yhlu wrote:
>>
>>> then how about the lines for 7z uncompress code?
>>>
>>> YH
>>
>> Working on it. 7z decompressor is really small (8 kb compiled on
>> i386) and written in ISO C (1884 lines of code), but compressor is
>> big and written in C++.
>>
>> Does it still make sense to try to use 7z?
> 
> yes, this is the perfect tradeoff. Highly complex, compute-intensive 
> compressor and simple, small decompressor. Exactly what we want.

I managed to trim this down further.
4 kb compiled code on i386, 497 lines of C code.

>> How much RAM is the decompressor allowed to use?
> 
> for the romcc section, you have about 6 32-bit words (or so). for the 
> gcc section, you have all of memory more or less.

OK, then we can call lzma decompressor only from the gcc section.
It needs to allocate some scratch space (between 5228 and 6295148 bytes,
default value is 15980 bytes) besides src and dst. The size of the
scratch space can be determined at compile time, so we can create
compressed images which only need 5228 bytes scratch space.
What is the best way to handle this? Dynamic allocation or fixed buffer?

Size comparison for OLPC target and small kernel:
843910 vmlinux.bin
437684 vmlinux.bin.nrv2b
377334 vmlinux.bin.lzma.smallscratchspace
373445 vmlinux.bin.lzma.default
 46832 linuxbios_ram.bin
 23923 linuxbios_ram.bin.nrv2b
 21829 linuxbios_ram.bin.lzma.smallscratchspace
 21738 linuxbios_ram.bin.lzma.default

The .lzma.smallscratchspace needs 5228 bytes scratch space,
the .lzma.default needs 15980 bytes scratch space.

lzma decompression can be called the same way as nrv2b decompression:
static unsigned long unlzma(unsigned char * src, unsigned char * dst);

Patch is attached. Please note that this patch doesn't change anything,
it only adds infrastructure. If you want a patch that builds most
targets (especially OLPC) with lzma, just ask. I have it sitting on
my hard drive.

To use lzma compression, download the LZMA SDK.

curl -O http://switch.dl.sourceforge.net/sourceforge/sevenzip/lzma442.tar.bz2
mkdir lzma442
cd lzma442
tar xfj ../lzma442.tar.bz2
cd C/7zip/Compress/LZMA_Alone/
make -f makefile.gcc
cp -a lzma /usr/local/bin/

Regards,
Carl-Daniel
-- 
http://www.hailfinger.org/
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: linuxbios_lzma.diff
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20060523/0445b197/attachment.ksh>

From yinghailu at gmail.com  Tue May 23 07:10:39 2006
From: yinghailu at gmail.com (yhlu)
Date: Mon, 22 May 2006 22:10:39 -0700
Subject: [LinuxBIOS] selection of compression algorithm
In-Reply-To: <447276D2.4090403@gmx.net>
References: <4470B968.5040100@gmx.net>
	<2ea3fae10605211352g1731bc62v16ddcda6c2e4b734@mail.gmail.com>
	<447123E2.6060000@gmx.net> <44714AD5.8030201@lanl.gov>
	<447276D2.4090403@gmx.net>
Message-ID: <2ea3fae10605222210o255485cw3422bd8788411692@mail.gmail.com>

Good.

1. We may need CONFIG_COMPRESS_TYPE to select nrv2b or lzma..or none
2. Add one compress type before compressed bin. 00: for none. 0x11:
for nrv2b or 0x22:  for lzma.

YH


On 5/22/06, Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006 at gmx.net> wrote:
> Ronald G Minnich wrote:
> > Carl-Daniel Hailfinger wrote:
> >> yhlu wrote:
> >>
> >>> then how about the lines for 7z uncompress code?
> >>>
> >>> YH
> >>
> >> Working on it. 7z decompressor is really small (8 kb compiled on
> >> i386) and written in ISO C (1884 lines of code), but compressor is
> >> big and written in C++.
> >>
> >> Does it still make sense to try to use 7z?
> >
> > yes, this is the perfect tradeoff. Highly complex, compute-intensive
> > compressor and simple, small decompressor. Exactly what we want.
>
> I managed to trim this down further.
> 4 kb compiled code on i386, 497 lines of C code.
>
> >> How much RAM is the decompressor allowed to use?
> >
> > for the romcc section, you have about 6 32-bit words (or so). for the
> > gcc section, you have all of memory more or less.
>
> OK, then we can call lzma decompressor only from the gcc section.
> It needs to allocate some scratch space (between 5228 and 6295148 bytes,
> default value is 15980 bytes) besides src and dst. The size of the
> scratch space can be determined at compile time, so we can create
> compressed images which only need 5228 bytes scratch space.
> What is the best way to handle this? Dynamic allocation or fixed buffer?
>
> Size comparison for OLPC target and small kernel:
> 843910 vmlinux.bin
> 437684 vmlinux.bin.nrv2b
> 377334 vmlinux.bin.lzma.smallscratchspace
> 373445 vmlinux.bin.lzma.default
>  46832 linuxbios_ram.bin
>  23923 linuxbios_ram.bin.nrv2b
>  21829 linuxbios_ram.bin.lzma.smallscratchspace
>  21738 linuxbios_ram.bin.lzma.default
>
> The .lzma.smallscratchspace needs 5228 bytes scratch space,
> the .lzma.default needs 15980 bytes scratch space.
>
> lzma decompression can be called the same way as nrv2b decompression:
> static unsigned long unlzma(unsigned char * src, unsigned char * dst);
>
> Patch is attached. Please note that this patch doesn't change anything,
> it only adds infrastructure. If you want a patch that builds most
> targets (especially OLPC) with lzma, just ask. I have it sitting on
> my hard drive.
>
> To use lzma compression, download the LZMA SDK.
>
> curl -O http://switch.dl.sourceforge.net/sourceforge/sevenzip/lzma442.tar.bz2
> mkdir lzma442
> cd lzma442
> tar xfj ../lzma442.tar.bz2
> cd C/7zip/Compress/LZMA_Alone/
> make -f makefile.gcc
> cp -a lzma /usr/local/bin/
>
> Regards,
> Carl-Daniel
> --
> http://www.hailfinger.org/
>
>
> diff -urN LinuxBIOSv2-2310/src/arch/i386/Config.lb LinuxBIOSv2-2310-lzma/src/arch/i386/Config.lb
> --- LinuxBIOSv2-2310/src/arch/i386/Config.lb    2006-05-18 19:29:27.000000000 +0200
> +++ LinuxBIOSv2-2310-lzma/src/arch/i386/Config.lb       2006-05-23 03:17:08.000000000 +0200
> @@ -13,6 +13,10 @@
>         action  "mcopy -o linuxbios.rom a:"
>  end
>
> +makerule lzma
> +       action  "test -f /usr/local/bin/lzma"
> +end
> +
>  makerule nrv2b
>         depends "$(TOP)/util/nrv2b/nrv2b.c"
>         action  "$(HOSTCC) -O2 -DENCODE -DDECODE -DMAIN -DVERBOSE -DNDEBUG -DBITSIZE=32 -DENDIAN=0 $< -o $@"
> @@ -23,6 +27,11 @@
>         action  "cp $< $@"
>  end
>
> +makerule payload.lzma
> +       depends "$(PAYLOAD) lzma"
> +       action  "lzma e $(PAYLOAD) $@"
> +end
> +
>  makerule payload.nrv2b
>         depends "$(PAYLOAD) nrv2b"
>         action  "./nrv2b e $(PAYLOAD) $@"
> diff -urN LinuxBIOSv2-2310/src/config/Config.lb LinuxBIOSv2-2310-lzma/src/config/Config.lb
> --- LinuxBIOSv2-2310/src/config/Config.lb       2006-05-18 19:29:24.000000000 +0200
> +++ LinuxBIOSv2-2310-lzma/src/config/Config.lb  2006-05-23 03:15:20.000000000 +0200
> @@ -53,6 +53,11 @@
>         action  "$(OBJCOPY) -O binary $< $@"
>  end
>
> +makerule linuxbios_ram.lzma
> +       depends "linuxbios_ram.bin lzma"
> +       action  "lzma e $< $@"
> +end
> +
>  makerule linuxbios_ram.nrv2b
>         depends "linuxbios_ram.bin nrv2b"
>         action  "./nrv2b e $< $@"
> diff -urN LinuxBIOSv2-2310/src/lib/lzma.c LinuxBIOSv2-2310-lzma/src/lib/lzma.c
> --- LinuxBIOSv2-2310/src/lib/lzma.c     1970-01-01 01:00:00.000000000 +0100
> +++ LinuxBIOSv2-2310-lzma/src/lib/lzma.c        2006-05-23 03:18:34.000000000 +0200
> @@ -0,0 +1,32 @@
> +/*
> +
> +LinuxBIOS interface to memory-saving variant of LZMA decoder
> +(C)opyright 2006 Carl-Daniel Hailfinger
> +Released under the GNU GPL
> +
> +*/
> +
> +#include "lzmadecode.c"
> +
> +static unsigned long unlzma(unsigned char * src, unsigned char * dst)
> +{
> +       unsigned char properties[LZMA_PROPERTIES_SIZE];
> +       UInt32 outSize;
> +       SizeT inProcessed;
> +       SizeT outProcessed;
> +       int res;
> +       CLzmaDecoderState state;
> +
> +       memcpy(properties, src, LZMA_PROPERTIES_SIZE);
> +       outSize = *(UInt32 *)(src + LZMA_PROPERTIES_SIZE);
> +       if (LzmaDecodeProperties(&state.Properties, properties, LZMA_PROPERTIES_SIZE) != LZMA_RESULT_OK) {
> +               printk_warning("Incorrect stream properties\n");
> +       }
> +       state.Probs = (CProb *)malloc(LzmaGetNumProbs(&state.Properties) * sizeof(CProb));
> +       res = LzmaDecode(&state, src + LZMA_PROPERTIES_SIZE + 8, (SizeT)0xffffffff, &inProcessed,
> +               dst, outSize, &outProcessed);
> +       if (res != 0) {
> +               printk_warning("Decoding error = %d\n", res);
> +       }
> +       return outSize;
> +}
> diff -urN LinuxBIOSv2-2310/src/lib/lzmadecode.c LinuxBIOSv2-2310-lzma/src/lib/lzmadecode.c
> --- LinuxBIOSv2-2310/src/lib/lzmadecode.c       1970-01-01 01:00:00.000000000 +0100
> +++ LinuxBIOSv2-2310-lzma/src/lib/lzmadecode.c  2006-05-23 03:13:01.000000000 +0200
> @@ -0,0 +1,398 @@
> +/*
> +  LzmaDecode.c
> +  LZMA Decoder (optimized for Speed version)
> +
> +  LZMA SDK 4.40 Copyright (c) 1999-2006 Igor Pavlov (2006-05-01)
> +  http://www.7-zip.org/
> +
> +  LZMA SDK is licensed under two licenses:
> +  1) GNU Lesser General Public License (GNU LGPL)
> +  2) Common Public License (CPL)
> +  It means that you can select one of these two licenses and
> +  follow rules of that license.
> +
> +  SPECIAL EXCEPTION:
> +  Igor Pavlov, as the author of this Code, expressly permits you to
> +  statically or dynamically link your Code (or bind by name) to the
> +  interfaces of this file without subjecting your linked Code to the
> +  terms of the CPL or GNU LGPL. Any modifications or additions
> +  to this file, however, are subject to the LGPL or CPL terms.
> +*/
> +
> +#include "lzmadecode.h"
> +
> +#define kNumTopBits 24
> +#define kTopValue ((UInt32)1 << kNumTopBits)
> +
> +#define kNumBitModelTotalBits 11
> +#define kBitModelTotal (1 << kNumBitModelTotalBits)
> +#define kNumMoveBits 5
> +
> +#define RC_READ_BYTE (*Buffer++)
> +
> +#define RC_INIT2 Code = 0; Range = 0xFFFFFFFF; \
> +  { int i; for(i = 0; i < 5; i++) { RC_TEST; Code = (Code << 8) | RC_READ_BYTE; }}
> +
> +
> +#define RC_TEST { if (Buffer == BufferLim) return LZMA_RESULT_DATA_ERROR; }
> +
> +#define RC_INIT(buffer, bufferSize) Buffer = buffer; BufferLim = buffer + bufferSize; RC_INIT2
> +
> +
> +#define RC_NORMALIZE if (Range < kTopValue) { RC_TEST; Range <<= 8; Code = (Code << 8) | RC_READ_BYTE; }
> +
> +#define IfBit0(p) RC_NORMALIZE; bound = (Range >> kNumBitModelTotalBits) * *(p); if (Code < bound)
> +#define UpdateBit0(p) Range = bound; *(p) += (kBitModelTotal - *(p)) >> kNumMoveBits;
> +#define UpdateBit1(p) Range -= bound; Code -= bound; *(p) -= (*(p)) >> kNumMoveBits;
> +
> +#define RC_GET_BIT2(p, mi, A0, A1) IfBit0(p) \
> +  { UpdateBit0(p); mi <<= 1; A0; } else \
> +  { UpdateBit1(p); mi = (mi + mi) + 1; A1; }
> +
> +#define RC_GET_BIT(p, mi) RC_GET_BIT2(p, mi, ; , ;)
> +
> +#define RangeDecoderBitTreeDecode(probs, numLevels, res) \
> +  { int i = numLevels; res = 1; \
> +  do { CProb *p = probs + res; RC_GET_BIT(p, res) } while(--i != 0); \
> +  res -= (1 << numLevels); }
> +
> +
> +#define kNumPosBitsMax 4
> +#define kNumPosStatesMax (1 << kNumPosBitsMax)
> +
> +#define kLenNumLowBits 3
> +#define kLenNumLowSymbols (1 << kLenNumLowBits)
> +#define kLenNumMidBits 3
> +#define kLenNumMidSymbols (1 << kLenNumMidBits)
> +#define kLenNumHighBits 8
> +#define kLenNumHighSymbols (1 << kLenNumHighBits)
> +
> +#define LenChoice 0
> +#define LenChoice2 (LenChoice + 1)
> +#define LenLow (LenChoice2 + 1)
> +#define LenMid (LenLow + (kNumPosStatesMax << kLenNumLowBits))
> +#define LenHigh (LenMid + (kNumPosStatesMax << kLenNumMidBits))
> +#define kNumLenProbs (LenHigh + kLenNumHighSymbols)
> +
> +
> +#define kNumStates 12
> +#define kNumLitStates 7
> +
> +#define kStartPosModelIndex 4
> +#define kEndPosModelIndex 14
> +#define kNumFullDistances (1 << (kEndPosModelIndex >> 1))
> +
> +#define kNumPosSlotBits 6
> +#define kNumLenToPosStates 4
> +
> +#define kNumAlignBits 4
> +#define kAlignTableSize (1 << kNumAlignBits)
> +
> +#define kMatchMinLen 2
> +
> +#define IsMatch 0
> +#define IsRep (IsMatch + (kNumStates << kNumPosBitsMax))
> +#define IsRepG0 (IsRep + kNumStates)
> +#define IsRepG1 (IsRepG0 + kNumStates)
> +#define IsRepG2 (IsRepG1 + kNumStates)
> +#define IsRep0Long (IsRepG2 + kNumStates)
> +#define PosSlot (IsRep0Long + (kNumStates << kNumPosBitsMax))
> +#define SpecPos (PosSlot + (kNumLenToPosStates << kNumPosSlotBits))
> +#define Align (SpecPos + kNumFullDistances - kEndPosModelIndex)
> +#define LenCoder (Align + kAlignTableSize)
> +#define RepLenCoder (LenCoder + kNumLenProbs)
> +#define Literal (RepLenCoder + kNumLenProbs)
> +
> +#if Literal != LZMA_BASE_SIZE
> +StopCompilingDueBUG
> +#endif
> +
> +int LzmaDecodeProperties(CLzmaProperties *propsRes, const unsigned char *propsData, int size)
> +{
> +  unsigned char prop0;
> +  if (size < LZMA_PROPERTIES_SIZE)
> +    return LZMA_RESULT_DATA_ERROR;
> +  prop0 = propsData[0];
> +  if (prop0 >= (9 * 5 * 5))
> +    return LZMA_RESULT_DATA_ERROR;
> +  {
> +    for (propsRes->pb = 0; prop0 >= (9 * 5); propsRes->pb++, prop0 -= (9 * 5));
> +    for (propsRes->lp = 0; prop0 >= 9; propsRes->lp++, prop0 -= 9);
> +    propsRes->lc = prop0;
> +    /*
> +    unsigned char remainder = (unsigned char)(prop0 / 9);
> +    propsRes->lc = prop0 % 9;
> +    propsRes->pb = remainder / 5;
> +    propsRes->lp = remainder % 5;
> +    */
> +  }
> +
> +  return LZMA_RESULT_OK;
> +}
> +
> +#define kLzmaStreamWasFinishedId (-1)
> +
> +int LzmaDecode(CLzmaDecoderState *vs,
> +    const unsigned char *inStream, SizeT inSize, SizeT *inSizeProcessed,
> +    unsigned char *outStream, SizeT outSize, SizeT *outSizeProcessed)
> +{
> +  CProb *p = vs->Probs;
> +  SizeT nowPos = 0;
> +  Byte previousByte = 0;
> +  UInt32 posStateMask = (1 << (vs->Properties.pb)) - 1;
> +  UInt32 literalPosMask = (1 << (vs->Properties.lp)) - 1;
> +  int lc = vs->Properties.lc;
> +
> +
> +  int state = 0;
> +  UInt32 rep0 = 1, rep1 = 1, rep2 = 1, rep3 = 1;
> +  int len = 0;
> +  const Byte *Buffer;
> +  const Byte *BufferLim;
> +  UInt32 Range;
> +  UInt32 Code;
> +
> +  *inSizeProcessed = 0;
> +  *outSizeProcessed = 0;
> +
> +  {
> +    UInt32 i;
> +    UInt32 numProbs = Literal + ((UInt32)LZMA_LIT_SIZE << (lc + vs->Properties.lp));
> +    for (i = 0; i < numProbs; i++)
> +      p[i] = kBitModelTotal >> 1;
> +  }
> +
> +  RC_INIT(inStream, inSize);
> +
> +
> +  while(nowPos < outSize)
> +  {
> +    CProb *prob;
> +    UInt32 bound;
> +    int posState = (int)(
> +        (nowPos
> +        )
> +        & posStateMask);
> +
> +    prob = p + IsMatch + (state << kNumPosBitsMax) + posState;
> +    IfBit0(prob)
> +    {
> +      int symbol = 1;
> +      UpdateBit0(prob)
> +      prob = p + Literal + (LZMA_LIT_SIZE *
> +        (((
> +        (nowPos
> +        )
> +        & literalPosMask) << lc) + (previousByte >> (8 - lc))));
> +
> +      if (state >= kNumLitStates)
> +      {
> +        int matchByte;
> +        matchByte = outStream[nowPos - rep0];
> +        do
> +        {
> +          int bit;
> +          CProb *probLit;
> +          matchByte <<= 1;
> +          bit = (matchByte & 0x100);
> +          probLit = prob + 0x100 + bit + symbol;
> +          RC_GET_BIT2(probLit, symbol, if (bit != 0) break, if (bit == 0) break)
> +        }
> +        while (symbol < 0x100);
> +      }
> +      while (symbol < 0x100)
> +      {
> +        CProb *probLit = prob + symbol;
> +        RC_GET_BIT(probLit, symbol)
> +      }
> +      previousByte = (Byte)symbol;
> +
> +      outStream[nowPos++] = previousByte;
> +      if (state < 4) state = 0;
> +      else if (state < 10) state -= 3;
> +      else state -= 6;
> +    }
> +    else
> +    {
> +      UpdateBit1(prob);
> +      prob = p + IsRep + state;
> +      IfBit0(prob)
> +      {
> +        UpdateBit0(prob);
> +        rep3 = rep2;
> +        rep2 = rep1;
> +        rep1 = rep0;
> +        state = state < kNumLitStates ? 0 : 3;
> +        prob = p + LenCoder;
> +      }
> +      else
> +      {
> +        UpdateBit1(prob);
> +        prob = p + IsRepG0 + state;
> +        IfBit0(prob)
> +        {
> +          UpdateBit0(prob);
> +          prob = p + IsRep0Long + (state << kNumPosBitsMax) + posState;
> +          IfBit0(prob)
> +          {
> +            UpdateBit0(prob);
> +
> +            if (nowPos == 0)
> +              return LZMA_RESULT_DATA_ERROR;
> +
> +            state = state < kNumLitStates ? 9 : 11;
> +            previousByte = outStream[nowPos - rep0];
> +            outStream[nowPos++] = previousByte;
> +
> +            continue;
> +          }
> +          else
> +          {
> +            UpdateBit1(prob);
> +          }
> +        }
> +        else
> +        {
> +          UInt32 distance;
> +          UpdateBit1(prob);
> +          prob = p + IsRepG1 + state;
> +          IfBit0(prob)
> +          {
> +            UpdateBit0(prob);
> +            distance = rep1;
> +          }
> +          else
> +          {
> +            UpdateBit1(prob);
> +            prob = p + IsRepG2 + state;
> +            IfBit0(prob)
> +            {
> +              UpdateBit0(prob);
> +              distance = rep2;
> +            }
> +            else
> +            {
> +              UpdateBit1(prob);
> +              distance = rep3;
> +              rep3 = rep2;
> +            }
> +            rep2 = rep1;
> +          }
> +          rep1 = rep0;
> +          rep0 = distance;
> +        }
> +        state = state < kNumLitStates ? 8 : 11;
> +        prob = p + RepLenCoder;
> +      }
> +      {
> +        int numBits, offset;
> +        CProb *probLen = prob + LenChoice;
> +        IfBit0(probLen)
> +        {
> +          UpdateBit0(probLen);
> +          probLen = prob + LenLow + (posState << kLenNumLowBits);
> +          offset = 0;
> +          numBits = kLenNumLowBits;
> +        }
> +        else
> +        {
> +          UpdateBit1(probLen);
> +          probLen = prob + LenChoice2;
> +          IfBit0(probLen)
> +          {
> +            UpdateBit0(probLen);
> +            probLen = prob + LenMid + (posState << kLenNumMidBits);
> +            offset = kLenNumLowSymbols;
> +            numBits = kLenNumMidBits;
> +          }
> +          else
> +          {
> +            UpdateBit1(probLen);
> +            probLen = prob + LenHigh;
> +            offset = kLenNumLowSymbols + kLenNumMidSymbols;
> +            numBits = kLenNumHighBits;
> +          }
> +        }
> +        RangeDecoderBitTreeDecode(probLen, numBits, len);
> +        len += offset;
> +      }
> +
> +      if (state < 4)
> +      {
> +        int posSlot;
> +        state += kNumLitStates;
> +        prob = p + PosSlot +
> +            ((len < kNumLenToPosStates ? len : kNumLenToPosStates - 1) <<
> +            kNumPosSlotBits);
> +        RangeDecoderBitTreeDecode(prob, kNumPosSlotBits, posSlot);
> +        if (posSlot >= kStartPosModelIndex)
> +        {
> +          int numDirectBits = ((posSlot >> 1) - 1);
> +          rep0 = (2 | ((UInt32)posSlot & 1));
> +          if (posSlot < kEndPosModelIndex)
> +          {
> +            rep0 <<= numDirectBits;
> +            prob = p + SpecPos + rep0 - posSlot - 1;
> +          }
> +          else
> +          {
> +            numDirectBits -= kNumAlignBits;
> +            do
> +            {
> +              RC_NORMALIZE
> +              Range >>= 1;
> +              rep0 <<= 1;
> +              if (Code >= Range)
> +              {
> +                Code -= Range;
> +                rep0 |= 1;
> +              }
> +            }
> +            while (--numDirectBits != 0);
> +            prob = p + Align;
> +            rep0 <<= kNumAlignBits;
> +            numDirectBits = kNumAlignBits;
> +          }
> +          {
> +            int i = 1;
> +            int mi = 1;
> +            do
> +            {
> +              CProb *prob3 = prob + mi;
> +              RC_GET_BIT2(prob3, mi, ; , rep0 |= i);
> +              i <<= 1;
> +            }
> +            while(--numDirectBits != 0);
> +          }
> +        }
> +        else
> +          rep0 = posSlot;
> +        if (++rep0 == (UInt32)(0))
> +        {
> +          /* it's for stream version */
> +          len = kLzmaStreamWasFinishedId;
> +          break;
> +        }
> +      }
> +
> +      len += kMatchMinLen;
> +      if (rep0 > nowPos)
> +        return LZMA_RESULT_DATA_ERROR;
> +
> +
> +      do
> +      {
> +        previousByte = outStream[nowPos - rep0];
> +        len--;
> +        outStream[nowPos++] = previousByte;
> +      }
> +      while(len != 0 && nowPos < outSize);
> +    }
> +  }
> +  RC_NORMALIZE;
> +
> +
> +  *inSizeProcessed = (SizeT)(Buffer - inStream);
> +  *outSizeProcessed = nowPos;
> +  return LZMA_RESULT_OK;
> +}
> diff -urN LinuxBIOSv2-2310/src/lib/lzmadecode.h LinuxBIOSv2-2310-lzma/src/lib/lzmadecode.h
> --- LinuxBIOSv2-2310/src/lib/lzmadecode.h       1970-01-01 01:00:00.000000000 +0100
> +++ LinuxBIOSv2-2310-lzma/src/lib/lzmadecode.h  2006-05-23 03:13:01.000000000 +0200
> @@ -0,0 +1,67 @@
> +/*
> +  LzmaDecode.h
> +  LZMA Decoder interface
> +
> +  LZMA SDK 4.40 Copyright (c) 1999-2006 Igor Pavlov (2006-05-01)
> +  http://www.7-zip.org/
> +
> +  LZMA SDK is licensed under two licenses:
> +  1) GNU Lesser General Public License (GNU LGPL)
> +  2) Common Public License (CPL)
> +  It means that you can select one of these two licenses and
> +  follow rules of that license.
> +
> +  SPECIAL EXCEPTION:
> +  Igor Pavlov, as the author of this code, expressly permits you to
> +  statically or dynamically link your code (or bind by name) to the
> +  interfaces of this file without subjecting your linked code to the
> +  terms of the CPL or GNU LGPL. Any modifications or additions
> +  to this file, however, are subject to the LGPL or CPL terms.
> +*/
> +
> +#ifndef __LZMADECODE_H
> +#define __LZMADECODE_H
> +
> +typedef unsigned char Byte;
> +typedef unsigned short UInt16;
> +typedef unsigned int UInt32;
> +typedef UInt32 SizeT;
> +
> +#define CProb UInt16
> +
> +#define LZMA_RESULT_OK 0
> +#define LZMA_RESULT_DATA_ERROR 1
> +
> +
> +#define LZMA_BASE_SIZE 1846
> +#define LZMA_LIT_SIZE 768
> +
> +#define LZMA_PROPERTIES_SIZE 5
> +
> +typedef struct _CLzmaProperties
> +{
> +  int lc;
> +  int lp;
> +  int pb;
> +}CLzmaProperties;
> +
> +int LzmaDecodeProperties(CLzmaProperties *propsRes, const unsigned char *propsData, int size);
> +
> +#define LzmaGetNumProbs(Properties) (LZMA_BASE_SIZE + (LZMA_LIT_SIZE << ((Properties)->lc + (Properties)->lp)))
> +
> +#define kLzmaNeedInitId (-2)
> +
> +typedef struct _CLzmaDecoderState
> +{
> +  CLzmaProperties Properties;
> +  CProb *Probs;
> +
> +
> +} CLzmaDecoderState;
> +
> +
> +int LzmaDecode(CLzmaDecoderState *vs,
> +    const unsigned char *inStream, SizeT inSize, SizeT *inSizeProcessed,
> +    unsigned char *outStream, SizeT outSize, SizeT *outSizeProcessed);
> +
> +#endif
>
>
> --
> linuxbios mailing list
> linuxbios at linuxbios.org
> http://www.openbios.org/mailman/listinfo/linuxbios
>
>



From smithbone at gmail.com  Tue May 23 07:19:32 2006
From: smithbone at gmail.com (Richard Smith)
Date: Tue, 23 May 2006 00:19:32 -0500
Subject: [LinuxBIOS] selection of compression algorithm
In-Reply-To: <20060522200504.GA27672@coresystems.de>
References: <4470B968.5040100@gmx.net> <44714A87.1040402@lanl.gov>
	<20060522092725.GB32661@coresystems.de>
	<2ea3fae10605220322x7ac5e2ds40410ac10ad93485@mail.gmail.com>
	<44721118.8010207@gmx.net> <20060522200504.GA27672@coresystems.de>
Message-ID: <8a0c36780605222219j76159dd3o25babb0080eae9cd@mail.gmail.com>

> > What's the difference between CONFIG_COMPRESSED_ROM_STREAM and
> > CONFIG_COMPRESS? Can we use lzma compression for both?
>
> CONFIG_COMPRESSED_ROM_STREAM says: the payload is compressed.
> CONFIG_COMPRESS says: LinuxBIOS is compressed.
>

Perhaps we should rename those to something more indicative of what they do?
Say:

CONFIG_COMPRESSED_ROM_STREAM -> CONFIG_COMPRESSED_PAYLOAD
CONFIG_COMPRESS -> CONFIG_COMPRESSED_LINUXBIOS

-- 
Richard A. Smith



From stepan at coresystems.de  Tue May 23 08:44:16 2006
From: stepan at coresystems.de (Stefan Reinauer)
Date: Tue, 23 May 2006 08:44:16 +0200
Subject: [LinuxBIOS] selection of compression algorithm
In-Reply-To: <2ea3fae10605222210o255485cw3422bd8788411692@mail.gmail.com>
References: <4470B968.5040100@gmx.net>
	<2ea3fae10605211352g1731bc62v16ddcda6c2e4b734@mail.gmail.com>
	<447123E2.6060000@gmx.net> <44714AD5.8030201@lanl.gov>
	<447276D2.4090403@gmx.net>
	<2ea3fae10605222210o255485cw3422bd8788411692@mail.gmail.com>
Message-ID: <20060523064416.GC3392@coresystems.de>

* yhlu <yinghailu at gmail.com> [060523 07:10]:
> Good.
> 
> 1. We may need CONFIG_COMPRESS_TYPE to select nrv2b or lzma..or none

Maybe it could even replace CONFIG_COMPRESS and
CONFIG_COMPRESS_ROM_STREAM?

> 2. Add one compress type before compressed bin. 00: for none. 0x11:
> for nrv2b or 0x22:  for lzma.

We could do this all at compile time so we don't need any "runtime
infrastructure"

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 yinghailu at gmail.com  Tue May 23 11:26:32 2006
From: yinghailu at gmail.com (yhlu)
Date: Tue, 23 May 2006 02:26:32 -0700
Subject: [LinuxBIOS] selection of compression algorithm
In-Reply-To: <20060523064416.GC3392@coresystems.de>
References: <4470B968.5040100@gmx.net>
	<2ea3fae10605211352g1731bc62v16ddcda6c2e4b734@mail.gmail.com>
	<447123E2.6060000@gmx.net> <44714AD5.8030201@lanl.gov>
	<447276D2.4090403@gmx.net>
	<2ea3fae10605222210o255485cw3422bd8788411692@mail.gmail.com>
	<20060523064416.GC3392@coresystems.de>
Message-ID: <2ea3fae10605230226o596398f1n726d1662fc9455cd@mail.gmail.com>

I may only want to lzma for payload if we can sqush tiny kernel and
initrd in 1M with LinuxBIOS.

I may need to use nrv2b for linuxbios_ram.rom and
linuxbios_ap_code.rom. These too can share the code in car stage. and
code in cache can not have too much space for lzma properties array.

YH

On 5/22/06, Stefan Reinauer <stepan at coresystems.de> wrote:
> * yhlu <yinghailu at gmail.com> [060523 07:10]:
> > Good.
> >
> > 1. We may need CONFIG_COMPRESS_TYPE to select nrv2b or lzma..or none
>
> Maybe it could even replace CONFIG_COMPRESS and
> CONFIG_COMPRESS_ROM_STREAM?
>
> > 2. Add one compress type before compressed bin. 00: for none. 0x11:
> > for nrv2b or 0x22:  for lzma.
>
> We could do this all at compile time so we don't need any "runtime
> infrastructure"
>
> 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 stepan at coresystems.de  Tue May 23 12:14:11 2006
From: stepan at coresystems.de (Stefan Reinauer)
Date: Tue, 23 May 2006 12:14:11 +0200
Subject: [LinuxBIOS] selection of compression algorithm
In-Reply-To: <2ea3fae10605230226o596398f1n726d1662fc9455cd@mail.gmail.com>
References: <4470B968.5040100@gmx.net>
	<2ea3fae10605211352g1731bc62v16ddcda6c2e4b734@mail.gmail.com>
	<447123E2.6060000@gmx.net> <44714AD5.8030201@lanl.gov>
	<447276D2.4090403@gmx.net>
	<2ea3fae10605222210o255485cw3422bd8788411692@mail.gmail.com>
	<20060523064416.GC3392@coresystems.de>
	<2ea3fae10605230226o596398f1n726d1662fc9455cd@mail.gmail.com>
Message-ID: <20060523101411.GA23954@coresystems.de>

* yhlu <yinghailu at gmail.com> [060523 11:26]:
> I may only want to lzma for payload if we can sqush tiny kernel and
> initrd in 1M with LinuxBIOS.
 
Thats why we all would want to see this, yes. But using nrv2b if lzma is
so much more efficient makes not much sense in any other case either.

> I may need to use nrv2b for linuxbios_ram.rom and
> linuxbios_ap_code.rom. 

 * What's linuxbios_ap_code.rom? 

> These too can share the code in car stage. and
> code in cache can not have too much space for lzma properties array.

When we're uncompressing, we do have memory. So cache sizes are no 
restriction at this point anymore.

-- 
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 c-d.hailfinger.devel.2006 at gmx.net  Tue May 23 14:39:55 2006
From: c-d.hailfinger.devel.2006 at gmx.net (Carl-Daniel Hailfinger)
Date: Tue, 23 May 2006 14:39:55 +0200
Subject: [LinuxBIOS] selection of compression algorithm
In-Reply-To: <6F7DA19D05F3CF40B890C7CA2DB13A4203094CD8@ssvlexmb2.amd.com>
References: <6F7DA19D05F3CF40B890C7CA2DB13A4203094CD8@ssvlexmb2.amd.com>
Message-ID: <4473029B.5040003@gmx.net>

Lu, Yinghai wrote:
> Copy_and_run is used by CAR and included in cache_as_ram_auto.c and
> compiled with gcc. That should be changed to use lzma easily.
> 
> CONFIG_COMPRESSED_ROM_STREAM is used for pay load. --- stream_init will
> do the uncompressed. ( stream_init is in ram)
> 
> CONFIG_COMPRESS is for linuxbios_ram.rom --- copy_and_run will do the
> uncompress. ( copy_and_run is ROM, and used ram as stack and local
> variable)

Patch attached to clear up the naming confusion. Applies on top of my
older patch.
Please apply.

Regards,
Carl-Daniel
-- 
http://www.hailfinger.org/
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: linuxbios_rename_CONFIG_COMPRESS.diff
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20060523/57da785f/attachment.ksh>

From c-d.hailfinger.devel.2006 at gmx.net  Tue May 23 15:29:17 2006
From: c-d.hailfinger.devel.2006 at gmx.net (Carl-Daniel Hailfinger)
Date: Tue, 23 May 2006 15:29:17 +0200
Subject: [LinuxBIOS] wiki access and commit rights
Message-ID: <44730E2D.8040609@gmx.net>

Hi,

is there any process to get commit rights or are they only
reserved for a core team? I'd like to work on integrating
lzma compression support in the following weeks. After that,
I plan to add support for a few SuperIO chips found on
Asus boards.


Regards,
Carl-Daniel



From stepan at coresystems.de  Tue May 23 17:00:36 2006
From: stepan at coresystems.de (Stefan Reinauer)
Date: Tue, 23 May 2006 17:00:36 +0200
Subject: [LinuxBIOS] wiki access and commit rights
In-Reply-To: <44730E2D.8040609@gmx.net>
References: <44730E2D.8040609@gmx.net>
Message-ID: <20060523150036.GA794@coresystems.de>

* Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006 at gmx.net> [060523 15:29]:
> Hi,
> 
> is there any process to get commit rights or are they only
> reserved for a core team? I'd like to work on integrating
> lzma compression support in the following weeks. After that,
> I plan to add support for a few SuperIO chips found on
> Asus boards.

The process has been very simple so far. Developers start out by 
sending patches to this list, so the work can be discussed and 
reviewed.

When developers start contributing on a regular basis and their
contributions are free of big issues in their reviews we add a
commit account.

We're not trying to scare people away, but as firmware is a very fragile
thing we are trying to establish a feeling for the necessary caution.

This has been done informally so far, but we are going to have the
development process and coding guidelines formalized and written down
soon.

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 rminnich at lanl.gov  Tue May 23 18:03:47 2006
From: rminnich at lanl.gov (Ronald G Minnich)
Date: Tue, 23 May 2006 10:03:47 -0600
Subject: [LinuxBIOS] linux bios hang when jump in kernel
In-Reply-To: <5c5dcf370605220053r3a58b786j143d902a35951ff3@mail.gmail.com>
References: <5c5dcf370605220053r3a58b786j143d902a35951ff3@mail.gmail.com>
Message-ID: <44733263.8020902@lanl.gov>

Neil wrote:
> Dear all :
> 
> My linuxbios can jump to kernel now ,but it hang then ,and can't enter 
> in OS.
> 
> Use phoenix bios
> ==============================
> =====
> ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx
> PCI_IDE: unknown IDE controller on PCI bus 00 device 11, VID=1166, DID=0214
> PCI_IDE: chipset revision 0
> PCI_IDE: not 100% native mode: will probe irqs later
>     ide0: BM-DMA at 0x2000-0x2007, BIOS settings: hda:DMA, hdb:pio
> PCI_IDE: simplex device:  DMA disabled
> ide1: PCI_IDE Bus-Master DMA disabled (BIOS)
> PCI_IDE: unknown IDE controller on PCI bus 01 device 70, VID=1166, DID=024b
> PCI_IDE: chipset revision 0
> PCI_IDE: 100% native mode on irq 5
>     ide2: BM-DMA at 0x3000-0x3007, BIOS settings: hde:pio, hdf:pio
>     ide3: BM-DMA at 0x3008-0x300f, BIOS settings: hdg:pio, hdh:pio
> PCI_IDE: unknown IDE controller on PCI bus 01 device 71, VID=1166, DID=024b
> PCI_IDE: chipset revision 0
> PCI_IDE: 100% native mode on irq 5
>     ide4: BM-DMA at 0x3020-0x3027, BIOS settings: hdi:pio, hdj:pio
>     ide5: BM-DMA at 0x3028-0x302f, BIOS settings: hdk:pio, hdl:pio
> hda: WDC WD400BB-00FJA0, ATA DISK drive
> ide0 at 0x1f0-0x1f7,0x3f6 on irq 14
> hda: 78165360 sectors (40021 MB) w/2048KiB Cache, CHS=4865/255/63
> ide-floppy driver 0.99.newide
> Partition check:
>  hda: hda1 hda2 hda3
> Floppy drive(s): fd0 is 1.44M         
> ...................................
> 
> Use linuxbios
> ======================================================
> PCI_IDE: unknown IDE controller on PCI bus 00 device 11, VID=1166, DID=0214
> PCI_IDE: chipset revision 0
> PCI_IDE: not 100% native mode: will probe irqs later
>     ide0: BM-DMA at 0x4010-0x4017, BIOS settings: hda:pio, hdb:pio
> PCI_IDE: simplex device:  DMA disabled
> ide1: PCI_IDE Bus-Master DMA disabled (BIOS)
> hda: C/H/S=0/0/0 from BIOS ignored
> hda: WDC WD400BB-00FJA0, ATA DISK drive
> ide0 at 0x1f0-0x1f7,0x3f6 on irq 14    
> 
> Then it hang here . could anyone tell me whant is the problem ?
> 
> Thank you .
> Neil
> 

This is the second time I'm seeing this. Note that on linuxbios, the 
message is :
PCI_IDE: not 100% native mode: will probe irqs later

that's different from phoenix. So there is a chipset setting here that 
is wrong. I think there is an IRQ issue here. Note that on the phoenix 
it is irq 5, and on linuxbios it assumes IRQ 14, since it is not a 
native controller (or so linux thinks).

What system is this on?

ron



From c-d.hailfinger.devel.2006 at gmx.net  Tue May 23 18:12:05 2006
From: c-d.hailfinger.devel.2006 at gmx.net (Carl-Daniel Hailfinger)
Date: Tue, 23 May 2006 18:12:05 +0200
Subject: [LinuxBIOS] Compressing the OLPC VSM?
Message-ID: <44733455.7010502@gmx.net>

Hi,

the VSM Ron mailed yesterday to olpc-devel can be compressed
very well to under 32 kb.

65536 vsa_test.64k-0001.bin
35587 vsa_test.64k-0001.bin.nrv2b
32143 vsa_test.64k-0001.bin.lzma

Is the VSM executed after RAM is there and can we use compression
for it? 50% savings are really good.


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



From rminnich at lanl.gov  Tue May 23 18:09:56 2006
From: rminnich at lanl.gov (Ronald G Minnich)
Date: Tue, 23 May 2006 10:09:56 -0600
Subject: [LinuxBIOS] selection of compression algorithm
In-Reply-To: <20060522200504.GA27672@coresystems.de>
References: <4470B968.5040100@gmx.net>
	<44714A87.1040402@lanl.gov>	<20060522092725.GB32661@coresystems.de>	<2ea3fae10605220322x7ac5e2ds40410ac10ad93485@mail.gmail.com>	<44721118.8010207@gmx.net>
	<20060522200504.GA27672@coresystems.de>
Message-ID: <447333D4.4000907@lanl.gov>

Stefan Reinauer wrote:

> 1. auto.c stage           (romcc)
> 2. uncompression stage    (gcc)
> 3. compressed linuxbios stage (gcc, initially compressed)

What I think of as the long term goal for OLPC:
1. auto.c stage: CAR, gunzip gcc code to ram
2. gcc stage: turn on the hardware, gunzip vga bios, other pieces, and 
payload to ram
3. payload runs, may do further gunzip work

the gunzip was removed from V1 because linux had its own decompressor in 
the bzimage. Given that there was, at the time, only one gunzip step, 
using the kernel's gunzip was deemed to save space. On OLPC, which is 
representative of the new systems, there are several distinct compressed 
bits:
1. nrv2b for gcc-compiled linuxbios
2. nrv2b for OLPC VSA binary
3. nrv2b for linux+initrd
4. nrv2b for VGA BIOS

it's clear that the balance of compression is now in linuxbios. So, in 
my view, it's time to move the decompressor back into linuxbios and dump 
the one we use in the kernel. This will help Plan 9 as well. We should 
also move to a better compression algorithm, I think.

I've already modified mkelfimage to just create 3 segments
1. kernel
2. cmdline+params (at 0x90000)
3. initrd (at 0x8000000)

So this is no real problem.

ron



From rminnich at lanl.gov  Tue May 23 18:11:45 2006
From: rminnich at lanl.gov (Ronald G Minnich)
Date: Tue, 23 May 2006 10:11:45 -0600
Subject: [LinuxBIOS] selection of compression algorithm
In-Reply-To: <4473029B.5040003@gmx.net>
References: <6F7DA19D05F3CF40B890C7CA2DB13A4203094CD8@ssvlexmb2.amd.com>
	<4473029B.5040003@gmx.net>
Message-ID: <44733441.7040707@lanl.gov>

Carl-Daniel Hailfinger wrote:
> Lu, Yinghai wrote:
> 
>>Copy_and_run is used by CAR and included in cache_as_ram_auto.c and
>>compiled with gcc. That should be changed to use lzma easily.
>>
>>CONFIG_COMPRESSED_ROM_STREAM is used for pay load. --- stream_init will
>>do the uncompressed. ( stream_init is in ram)
>>
>>CONFIG_COMPRESS is for linuxbios_ram.rom --- copy_and_run will do the
>>uncompress. ( copy_and_run is ROM, and used ram as stack and local
>>variable)
> 
> 
> Patch attached to clear up the naming confusion. Applies on top of my
> older patch.
> Please apply.

this has passed the abuild regression test and works on at least one 
platform, right?

ron



From c-d.hailfinger.devel.2006 at gmx.net  Tue May 23 18:04:27 2006
From: c-d.hailfinger.devel.2006 at gmx.net (Carl-Daniel Hailfinger)
Date: Tue, 23 May 2006 18:04:27 +0200
Subject: [LinuxBIOS] wiki access and commit rights
In-Reply-To: <20060523150036.GA794@coresystems.de>
References: <44730E2D.8040609@gmx.net> <20060523150036.GA794@coresystems.de>
Message-ID: <4473328B.7000907@gmx.net>

Stefan Reinauer wrote:
> * Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006 at gmx.net> [060523 15:29]:
>> Hi,
>>
>> is there any process to get commit rights or are they only
>> reserved for a core team? I'd like to work on integrating
>> lzma compression support in the following weeks. After that,
>> I plan to add support for a few SuperIO chips found on
>> Asus boards.
> 
> The process has been very simple so far. Developers start out by 
> sending patches to this list, so the work can be discussed and 
> reviewed.

OK, then I'll continue sending patches to the list.
Would you be so kind and review the patches I sent today and tell me
what to make better? Thanks!


> We're not trying to scare people away, but as firmware is a very fragile
> thing we are trying to establish a feeling for the necessary caution.

I'm already trying to be careful because of my kernel development
background, but I understand firmware requires even more caution.


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



From rminnich at lanl.gov  Tue May 23 18:45:03 2006
From: rminnich at lanl.gov (Ronald G Minnich)
Date: Tue, 23 May 2006 10:45:03 -0600
Subject: [LinuxBIOS] wiki access and commit rights
In-Reply-To: <4473328B.7000907@gmx.net>
References: <44730E2D.8040609@gmx.net> <20060523150036.GA794@coresystems.de>
	<4473328B.7000907@gmx.net>
Message-ID: <44733C0F.9030904@lanl.gov>

Carl-Daniel Hailfinger wrote:
> Stefan Reinauer wrote:
> 
>>* Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006 at gmx.net> [060523 15:29]:
>>
>>>Hi,
>>>
>>>is there any process to get commit rights or are they only
>>>reserved for a core team? I'd like to work on integrating
>>>lzma compression support in the following weeks. After that,
>>>I plan to add support for a few SuperIO chips found on
>>>Asus boards.
>>
>>The process has been very simple so far. Developers start out by 
>>sending patches to this list, so the work can be discussed and 
>>reviewed.
> 
> 
> OK, then I'll continue sending patches to the list.
> Would you be so kind and review the patches I sent today and tell me
> what to make better? Thanks!

Please, please make sure when you send a patch you have tested with a 
abuild.

Stefan, I recently found a build problem that only cropped up with 
maximum log levels set to 9. Can we have a Config.abuild in each target 
directory with "all options on"? How do we cover this?

thanks, Carl-Daniel, for your understanding and patience. I am glad we 
have another linuxbios hacker coming on board!

ron



From rminnich at lanl.gov  Tue May 23 19:07:44 2006
From: rminnich at lanl.gov (Ronald G Minnich)
Date: Tue, 23 May 2006 11:07:44 -0600
Subject: [LinuxBIOS] Compressing the OLPC VSM?
In-Reply-To: <44733455.7010502@gmx.net>
References: <44733455.7010502@gmx.net>
Message-ID: <44734160.8070206@lanl.gov>

Carl-Daniel Hailfinger wrote:
> Hi,
> 
> the VSM Ron mailed yesterday to olpc-devel can be compressed
> very well to under 32 kb.
> 
> 65536 vsa_test.64k-0001.bin
> 35587 vsa_test.64k-0001.bin.nrv2b
> 32143 vsa_test.64k-0001.bin.lzma
> 
> Is the VSM executed after RAM is there and can we use compression
> for it? 50% savings are really good.
> 
> 
> Regards,
> Carl-Daniel

yes, this is great. I want to move to the new compression asap.

ron



From russ at ashlandhome.net  Tue May 23 19:36:22 2006
From: russ at ashlandhome.net (Russell Whitaker)
Date: Tue, 23 May 2006 10:36:22 -0700 (PDT)
Subject: [LinuxBIOS] linux bios hang when jump in kernel
In-Reply-To: <44733263.8020902@lanl.gov>
References: <5c5dcf370605220053r3a58b786j143d902a35951ff3@mail.gmail.com>
	<44733263.8020902@lanl.gov>
Message-ID: <Pine.LNX.4.63.0605231014270.2398@bigred.russwhit.org>



On Tue, 23 May 2006, Ronald G Minnich wrote:

> Neil wrote:
>> Dear all :
>>
>> My linuxbios can jump to kernel now ,but it hang then ,and can't enter
>> in OS.
>>
>> Use phoenix bios
[..]
>> PCI_IDE: not 100% native mode: will probe irqs later
>>     ide0: BM-DMA at 0x2000-0x2007, BIOS settings: hda:DMA, hdb:pio
>> PCI_IDE: simplex device:  DMA disabled
>> ide1: PCI_IDE Bus-Master DMA disabled (BIOS)
>> PCI_IDE: unknown IDE controller on PCI bus 01 device 70, VID=1166, DID=024b
>> PCI_IDE: chipset revision 0
>> PCI_IDE: 100% native mode on irq 5
>>     ide2: BM-DMA at 0x3000-0x3007, BIOS settings: hde:pio, hdf:pio
>>     ide3: BM-DMA at 0x3008-0x300f, BIOS settings: hdg:pio, hdh:pio
>> PCI_IDE: unknown IDE controller on PCI bus 01 device 71, VID=1166, DID=024b
>> PCI_IDE: chipset revision 0
>> PCI_IDE: 100% native mode on irq 5
>>     ide4: BM-DMA at 0x3020-0x3027, BIOS settings: hdi:pio, hdj:pio
>>     ide5: BM-DMA at 0x3028-0x302f, BIOS settings: hdk:pio, hdl:pio
>> hda: WDC WD400BB-00FJA0, ATA DISK drive
>> ide0 at 0x1f0-0x1f7,0x3f6 on irq 14
>> hda: 78165360 sectors (40021 MB) w/2048KiB Cache, CHS=4865/255/63
[..]

>> Use linuxbios
[..]
>> PCI_IDE: not 100% native mode: will probe irqs later
>>     ide0: BM-DMA at 0x4010-0x4017, BIOS settings: hda:pio, hdb:pio
>> PCI_IDE: simplex device:  DMA disabled
>> ide1: PCI_IDE Bus-Master DMA disabled (BIOS)
>> hda: C/H/S=0/0/0 from BIOS ignored
>> hda: WDC WD400BB-00FJA0, ATA DISK drive
>> ide0 at 0x1f0-0x1f7,0x3f6 on irq 14
>>
>
> This is the second time I'm seeing this. Note that on linuxbios, the
> message is :
> PCI_IDE: not 100% native mode: will probe irqs later
> that's different from phoenix.

Ron, I think you read it too fast.
    ide0 - irq14
    ide2, etc - irq5

> So there is a chipset setting here that
> is wrong. I think there is an IRQ issue here. Note that on the phoenix
> it is irq 5, and on linuxbios it assumes IRQ 14, since it is not a
> native controller (or so linux thinks).
>

Looks like a box with an added pci-ide card. If so, would linuxbios
bootup with the added card removed? That might narrow down the problem
a little.

   russ



From jardel at lesc.ufc.br  Tue May 23 19:53:32 2006
From: jardel at lesc.ufc.br (jardel)
Date: Tue, 23 May 2006 14:53:32 -0300
Subject: [LinuxBIOS] Compressing the OLPC VSM?
In-Reply-To: <44734160.8070206@lanl.gov>
References: <44733455.7010502@gmx.net> <44734160.8070206@lanl.gov>
Message-ID: <44734C1C.9000508@lesc.ufc.br>


JCalg compression library is possible too, isn't ? It's open source and
the source is already assembly optimized. It was available
www.collakesoftware.com.


Thanks.


Jardel.

Ronald G Minnich wrote:

>Carl-Daniel Hailfinger wrote:
>  
>
>>Hi,
>>
>>the VSM Ron mailed yesterday to olpc-devel can be compressed
>>very well to under 32 kb.
>>
>>65536 vsa_test.64k-0001.bin
>>35587 vsa_test.64k-0001.bin.nrv2b
>>32143 vsa_test.64k-0001.bin.lzma
>>
>>Is the VSM executed after RAM is there and can we use compression
>>for it? 50% savings are really good.
>>
>>
>>Regards,
>>Carl-Daniel
>>    
>>
>
>yes, this is great. I want to move to the new compression asap.
>
>ron
>
>  
>

-------------- 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/20060523/1190784f/attachment.sig>

From c-d.hailfinger.devel.2006 at gmx.net  Tue May 23 19:52:46 2006
From: c-d.hailfinger.devel.2006 at gmx.net (Carl-Daniel Hailfinger)
Date: Tue, 23 May 2006 19:52:46 +0200
Subject: [LinuxBIOS] Compressing the OLPC VSM?
In-Reply-To: <44734160.8070206@lanl.gov>
References: <44733455.7010502@gmx.net> <44734160.8070206@lanl.gov>
Message-ID: <44734BEE.8020000@gmx.net>

Ronald G Minnich wrote:
> Carl-Daniel Hailfinger wrote:
>> Hi,
>>
>> the VSM Ron mailed yesterday to olpc-devel can be compressed
>> very well to under 32 kb.
>>
>> 65536 vsa_test.64k-0001.bin
>> 35587 vsa_test.64k-0001.bin.nrv2b
>> 32143 vsa_test.64k-0001.bin.lzma
>>
>> Is the VSM executed after RAM is there and can we use compression
>> for it? 50% savings are really good.
>>
> yes, this is great. I want to move to the new compression asap.

See my other patch to the list which adds the decompression code
and infrastructure. I'm preparing another patch which will make
use of all that code. The patches I sent until now do not modify
any existing code, so they should be safe to apply.

Regards,
Carl-Daniel

P.S. I have a script which will figure out the best compression
possible with lzma if you give it the memory scratch pad size
as an argument. This can yield up to 2% additional compression.
-- 
http://www.hailfinger.org/



From rminnich at lanl.gov  Tue May 23 19:48:38 2006
From: rminnich at lanl.gov (Ronald G Minnich)
Date: Tue, 23 May 2006 11:48:38 -0600
Subject: [LinuxBIOS] Compressing the OLPC VSM?
In-Reply-To: <44734C1C.9000508@lesc.ufc.br>
References: <44733455.7010502@gmx.net> <44734160.8070206@lanl.gov>
	<44734C1C.9000508@lesc.ufc.br>
Message-ID: <44734AF6.8010009@lanl.gov>

jardel wrote:
> JCalg compression library is possible too, isn't ? It's open source and
> the source is already assembly optimized. It was available
> www.collakesoftware.com.

you mean it contains assembly? No assembly allowed. :-)

ron



From c-d.hailfinger.devel.2006 at gmx.net  Tue May 23 19:58:28 2006
From: c-d.hailfinger.devel.2006 at gmx.net (Carl-Daniel Hailfinger)
Date: Tue, 23 May 2006 19:58:28 +0200
Subject: [LinuxBIOS] Compressing the OLPC VSM?
In-Reply-To: <44734C1C.9000508@lesc.ufc.br>
References: <44733455.7010502@gmx.net> <44734160.8070206@lanl.gov>
	<44734C1C.9000508@lesc.ufc.br>
Message-ID: <44734D44.3030606@gmx.net>

jardel wrote:
> JCalg compression library is possible too, isn't ? It's open source and
> the source is already assembly optimized. It was available
> www.collakesoftware.com.

How small does JCalg compress the VSA module at the link below?

http://laptop.org/pipermail/devel/attachments/20060521/e389e3ea/vsa_test.64k-0001.bin

>>> 65536 vsa_test.64k-0001.bin
>>> 35587 vsa_test.64k-0001.bin.nrv2b
>>> 32143 vsa_test.64k-0001.bin.lzma

If it is better than the lzma result, we may consider it.
But IIRC the JCalg author said that lzma should be better.

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



From rminnich at lanl.gov  Tue May 23 19:52:18 2006
From: rminnich at lanl.gov (Ronald G Minnich)
Date: Tue, 23 May 2006 11:52:18 -0600
Subject: [LinuxBIOS] selection of compression algorithm
In-Reply-To: <44734B20.3070306@gmx.net>
References: <6F7DA19D05F3CF40B890C7CA2DB13A4203094CD8@ssvlexmb2.amd.com>	<4473029B.5040003@gmx.net>
	<44733441.7040707@lanl.gov> <44734B20.3070306@gmx.net>
Message-ID: <44734BD2.9090007@lanl.gov>

Carl-Daniel Hailfinger wrote:

> 
> I have no platform on which LinuxBIOS runs on, but it caused no regression
> in abuild. (But a lot of targets do not seem to compile at all, even without
> my patch. Does this depend on the gcc version? I have gcc 3.3.5)

don't know, I will try to test your patch via abuild but I don't want to 
commit until then.

ron



From c-d.hailfinger.devel.2006 at gmx.net  Tue May 23 19:49:20 2006
From: c-d.hailfinger.devel.2006 at gmx.net (Carl-Daniel Hailfinger)
Date: Tue, 23 May 2006 19:49:20 +0200
Subject: [LinuxBIOS] selection of compression algorithm
In-Reply-To: <44733441.7040707@lanl.gov>
References: <6F7DA19D05F3CF40B890C7CA2DB13A4203094CD8@ssvlexmb2.amd.com>	<4473029B.5040003@gmx.net>
	<44733441.7040707@lanl.gov>
Message-ID: <44734B20.3070306@gmx.net>

Ronald G Minnich wrote:
> Carl-Daniel Hailfinger wrote:
>> Lu, Yinghai wrote:
>>
>>> Copy_and_run is used by CAR and included in cache_as_ram_auto.c and
>>> compiled with gcc. That should be changed to use lzma easily.
>>>
>>> CONFIG_COMPRESSED_ROM_STREAM is used for pay load. --- stream_init will
>>> do the uncompressed. ( stream_init is in ram)
>>>
>>> CONFIG_COMPRESS is for linuxbios_ram.rom --- copy_and_run will do the
>>> uncompress. ( copy_and_run is ROM, and used ram as stack and local
>>> variable)
>>
>> Patch attached to clear up the naming confusion. Applies on top of my
>> older patch.
>> Please apply.
> 
> this has passed the abuild regression test and works on at least one 
> platform, right?

I have no platform on which LinuxBIOS runs on, but it caused no regression
in abuild. (But a lot of targets do not seem to compile at all, even without
my patch. Does this depend on the gcc version? I have gcc 3.3.5)


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



From c-d.hailfinger.devel.2006 at gmx.net  Tue May 23 20:09:07 2006
From: c-d.hailfinger.devel.2006 at gmx.net (Carl-Daniel Hailfinger)
Date: Tue, 23 May 2006 20:09:07 +0200
Subject: [LinuxBIOS] selection of compression algorithm
In-Reply-To: <44734BD2.9090007@lanl.gov>
References: <6F7DA19D05F3CF40B890C7CA2DB13A4203094CD8@ssvlexmb2.amd.com>	<4473029B.5040003@gmx.net>
	<44733441.7040707@lanl.gov> <44734B20.3070306@gmx.net>
	<44734BD2.9090007@lanl.gov>
Message-ID: <44734FC3.4020906@gmx.net>

Ronald G Minnich wrote:
> Carl-Daniel Hailfinger wrote:
> 
>>
>> I have no platform on which LinuxBIOS runs on, but it caused no
>> regression
>> in abuild. (But a lot of targets do not seem to compile at all, even
>> without
>> my patch. Does this depend on the gcc version? I have gcc 3.3.5)
> 
> don't know, I will try to test your patch via abuild but I don't want to
> commit until then.

Yes, it was a gcc bug. gcc 4.1.0 has no problems compiling it.
I'll continue testing and developing with gcc 4.1.0 from now on.

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



From jardel at lesc.ufc.br  Tue May 23 20:36:18 2006
From: jardel at lesc.ufc.br (jardel)
Date: Tue, 23 May 2006 15:36:18 -0300
Subject: [LinuxBIOS] Compressing the OLPC VSM?
In-Reply-To: <44734D44.3030606@gmx.net>
References: <44733455.7010502@gmx.net>
	<44734160.8070206@lanl.gov>	<44734C1C.9000508@lesc.ufc.br>
	<44734D44.3030606@gmx.net>
Message-ID: <44735622.1040602@lesc.ufc.br>


    This is the result for compressing the file vsa_test.64k-0001.bin in
1 to 9 level compressions of JCalg:


23/07/1999  15:29    <DIR>          .
23/07/1999  15:29    <DIR>          ..
23/05/2006  15:28            65.536 vsa.bin
23/07/1999  15:28            36.382 vsa1.jc
23/07/1999  15:28            35.858 vsa2.jc
23/07/1999  15:28            35.414 vsa3.jc
23/07/1999  15:28            35.158 vsa4.jc
23/07/1999  15:28            34.970 vsa5.jc
23/07/1999  15:28            34.970 vsa6.jc
23/07/1999  15:28            34.970 vsa7.jc
23/07/1999  15:29            34.970 vsa8.jc
23/07/1999  15:29            34.970 vsa9.jc


Thanks.


Jardel.

Carl-Daniel Hailfinger wrote:

>jardel wrote:
>  
>
>>JCalg compression library is possible too, isn't ? It's open source and
>>the source is already assembly optimized. It was available
>>www.collakesoftware.com.
>>    
>>
>
>How small does JCalg compress the VSA module at the link below?
>
>http://laptop.org/pipermail/devel/attachments/20060521/e389e3ea/vsa_test.64k-0001.bin
>
>  
>
>>>>65536 vsa_test.64k-0001.bin
>>>>35587 vsa_test.64k-0001.bin.nrv2b
>>>>32143 vsa_test.64k-0001.bin.lzma
>>>>        
>>>>
>
>If it is better than the lzma result, we may consider it.
>But IIRC the JCalg author said that lzma should be better.
>
>Regards,
>Carl-Daniel
>  
>

-------------- 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/20060523/b0971d1c/attachment.sig>

From jardel at lesc.ufc.br  Tue May 23 20:52:15 2006
From: jardel at lesc.ufc.br (jardel)
Date: Tue, 23 May 2006 15:52:15 -0300
Subject: [LinuxBIOS] Compressing the OLPC VSM?
In-Reply-To: <44734AF6.8010009@lanl.gov>
References: <44733455.7010502@gmx.net>
	<44734160.8070206@lanl.gov>	<44734C1C.9000508@lesc.ufc.br>
	<44734AF6.8010009@lanl.gov>
Message-ID: <447359DF.7080102@lesc.ufc.br>


Dear Mr. Ronald G Minnich,


    It is. You're right. The algorthim is available in c too, but the
interesting is the assembly version which is assembly optmized.


Thanks.


Jardel.

Ronald G Minnich wrote:

>jardel wrote:
>  
>
>>JCalg compression library is possible too, isn't ? It's open source and
>>the source is already assembly optimized. It was available
>>www.collakesoftware.com.
>>    
>>
>
>you mean it contains assembly? No assembly allowed. :-)
>
>ron
>
>  
>

-------------- 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/20060523/2c8acc68/attachment.sig>

From c-d.hailfinger.devel.2006 at gmx.net  Tue May 23 20:52:00 2006
From: c-d.hailfinger.devel.2006 at gmx.net (Carl-Daniel Hailfinger)
Date: Tue, 23 May 2006 20:52:00 +0200
Subject: [LinuxBIOS] Compressing the OLPC VSM?
In-Reply-To: <44735622.1040602@lesc.ufc.br>
References: <44733455.7010502@gmx.net>
	<44734160.8070206@lanl.gov>	<44734C1C.9000508@lesc.ufc.br>
	<44734D44.3030606@gmx.net> <44735622.1040602@lesc.ufc.br>
Message-ID: <447359D0.5080105@gmx.net>

jardel wrote:
> Carl-Daniel Hailfinger wrote:
>> jardel wrote:
>>
>>> JCalg compression library is possible too, isn't ? It's open source and
>>> the source is already assembly optimized. It was available
>>> www.collakesoftware.com.
>>>
>> How small does JCalg compress the VSA module at the link below?
>>
>> http://laptop.org/pipermail/devel/attachments/20060521/e389e3ea/vsa_test.64k-0001.bin
>>
>>>>> 65536 vsa_test.64k-0001.bin
>>>>> 35587 vsa_test.64k-0001.bin.nrv2b
>>>>> 32143 vsa_test.64k-0001.bin.lzma
>>>>>        
>>>>>
>> If it is better than the lzma result, we may consider it.
>> But IIRC the JCalg author said that lzma should be better.
> 
> This is the result for compressing the file vsa_test.64k-0001.bin in
> 1 to 9 level compressions of JCalg:
> 
> 36382 vsa1.jc
> [...]
> 34970 vsa9.jc

OK, so it is worse than lzma. Thanks for checking that.

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



From c-d.hailfinger.devel.2006 at gmx.net  Tue May 23 21:13:28 2006
From: c-d.hailfinger.devel.2006 at gmx.net (Carl-Daniel Hailfinger)
Date: Tue, 23 May 2006 21:13:28 +0200
Subject: [LinuxBIOS] selection of compression algorithm
In-Reply-To: <447333D4.4000907@lanl.gov>
References: <4470B968.5040100@gmx.net>	<44714A87.1040402@lanl.gov>	<20060522092725.GB32661@coresystems.de>	<2ea3fae10605220322x7ac5e2ds40410ac10ad93485@mail.gmail.com>	<44721118.8010207@gmx.net>	<20060522200504.GA27672@coresystems.de>
	<447333D4.4000907@lanl.gov>
Message-ID: <44735ED8.9000303@gmx.net>

Ronald G Minnich wrote:
> Stefan Reinauer wrote:
> 
>> 1. auto.c stage           (romcc)
>> 2. uncompression stage    (gcc)
>> 3. compressed linuxbios stage (gcc, initially compressed)
> 
> What I think of as the long term goal for OLPC:
> 1. auto.c stage: CAR, gunzip gcc code to ram
> 2. gcc stage: turn on the hardware, gunzip vga bios, other pieces, and 
> payload to ram
> 3. payload runs, may do further gunzip work

Do we really want to gunzip anything in CAR stage? How big is the code
to turn on RAM? Will it really benefit from being compressed? I would
turn on RAM first and only then start uncompression.

At what stage am I allowed to use malloc? gcc stage? payload stage?
Can I abuse the function stack before?

Another thing that bothers me: It seems we include the uncompression code
multiple times. Can we include it only once and make all stages use it?


> the gunzip was removed from V1 because linux had its own decompressor in 
> the bzimage. Given that there was, at the time, only one gunzip step, 
> using the kernel's gunzip was deemed to save space. On OLPC, which is 
> representative of the new systems, there are several distinct compressed 
> bits:
> 1. nrv2b for gcc-compiled linuxbios
> 2. nrv2b for OLPC VSA binary
> 3. nrv2b for linux+initrd
> 4. nrv2b for VGA BIOS

Can you upload all these files somewhere so I can make a size comparison
and work out the best compression parameters for lzma?

I have a (not completely finished) script called squeeze_lzma which will
run lzma with different parameters and figure out which yield the best
compression for the unlimited RAM case and for the small RAM case. So
we can use compression which needs only 5k RAM for decompression in
stage 1 and 60k RAM in stage 2+3.


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



From yinghailu at gmail.com  Tue May 23 21:49:22 2006
From: yinghailu at gmail.com (yhlu)
Date: Tue, 23 May 2006 12:49:22 -0700
Subject: [LinuxBIOS] selection of compression algorithm
In-Reply-To: <44735ED8.9000303@gmx.net>
References: <4470B968.5040100@gmx.net> <44714A87.1040402@lanl.gov>
	<20060522092725.GB32661@coresystems.de>
	<2ea3fae10605220322x7ac5e2ds40410ac10ad93485@mail.gmail.com>
	<44721118.8010207@gmx.net> <20060522200504.GA27672@coresystems.de>
	<447333D4.4000907@lanl.gov> <44735ED8.9000303@gmx.net>
Message-ID: <2ea3fae10605231249w427bdfb1u736078b495d9a1e3@mail.gmail.com>

We at least need two times
1. one is in car stage, and the code is in rom, and it is used to
uncompress linuxbios_ram
2. one is in linuxbios_ram, and it is in ram, it is used to uncompress payload.

car stage, before call copy_and_run, the stack is already in ram. but
code is still in rom. So at this time we need to balance the lzma
benifit on compress linuxbios_ram and it's own code size increase in
rom. also need to set one extra buffer in ram for every ap code.

Hope we can squash car stage code + linuxbios_ram code into 64k again.

YH



From yinghailu at gmail.com  Tue May 23 21:53:05 2006
From: yinghailu at gmail.com (yhlu)
Date: Tue, 23 May 2006 12:53:05 -0700
Subject: [LinuxBIOS] selection of compression algorithm
In-Reply-To: <20060523101411.GA23954@coresystems.de>
References: <4470B968.5040100@gmx.net>
	<2ea3fae10605211352g1731bc62v16ddcda6c2e4b734@mail.gmail.com>
	<447123E2.6060000@gmx.net> <44714AD5.8030201@lanl.gov>
	<447276D2.4090403@gmx.net>
	<2ea3fae10605222210o255485cw3422bd8788411692@mail.gmail.com>
	<20060523064416.GC3392@coresystems.de>
	<2ea3fae10605230226o596398f1n726d1662fc9455cd@mail.gmail.com>
	<20060523101411.GA23954@coresystems.de>
Message-ID: <2ea3fae10605231253j60cda13byd2aa1c4dfa81b580@mail.gmail.com>

linuxbios_apc.rom is the code for ap. The code is in it's own cache.
So BSP is executing the code in ROM and RAM, and at the same time the
APs executing code in cache.

The AP uncompress the linuxbios_apc.rom from rom to it's cache before
jump it. At that time the RAM on BSP is ready already.

YH

On 5/23/06, Stefan Reinauer <stepan at coresystems.de> wrote:
> * yhlu <yinghailu at gmail.com> [060523 11:26]:
> > I may only want to lzma for payload if we can sqush tiny kernel and
> > initrd in 1M with LinuxBIOS.
>
> Thats why we all would want to see this, yes. But using nrv2b if lzma is
> so much more efficient makes not much sense in any other case either.
>
> > I may need to use nrv2b for linuxbios_ram.rom and
> > linuxbios_ap_code.rom.
>
>  * What's linuxbios_ap_code.rom?
>
> > These too can share the code in car stage. and
> > code in cache can not have too much space for lzma properties array.
>
> When we're uncompressing, we do have memory. So cache sizes are no
> restriction at this point anymore.
>
> --
> 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 stepan at coresystems.de  Wed May 24 00:35:30 2006
From: stepan at coresystems.de (Stefan Reinauer)
Date: Wed, 24 May 2006 00:35:30 +0200
Subject: [LinuxBIOS] linux bios hang when jump in kernel
In-Reply-To: <44733263.8020902@lanl.gov>
References: <5c5dcf370605220053r3a58b786j143d902a35951ff3@mail.gmail.com>
	<44733263.8020902@lanl.gov>
Message-ID: <20060523223530.GC3701@coresystems.de>

* Ronald G Minnich <rminnich at lanl.gov> [060523 18:03]:
> Neil wrote:
> > Use phoenix bios
> > ==============================
> > =====
> > ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx
> > PCI_IDE: unknown IDE controller on PCI bus 00 device 11, VID=1166, DID=0214
> > PCI_IDE: unknown IDE controller on PCI bus 01 device 70, VID=1166, DID=024b
> > PCI_IDE: unknown IDE controller on PCI bus 01 device 71, VID=1166, DID=024b
> > 
> > Use linuxbios
> > ======================================================
> > PCI_IDE: unknown IDE controller on PCI bus 00 device 11, VID=1166, DID=0214
> 
> This is the second time I'm seeing this. Note that on linuxbios, the 
> message is :
> PCI_IDE: not 100% native mode: will probe irqs later
> 
> that's different from phoenix. So there is a chipset setting here that 
> is wrong. I think there is an IRQ issue here. Note that on the phoenix 
> it is irq 5, and on linuxbios it assumes IRQ 14, since it is not a 
> native controller (or so linux thinks).

Good hint!

Is this with ACPI enabled in LinuxBIOS? If so you need to fix ACPI
tables, otherwise you need an entry for bus1 in the pirq table.
(I never understood why this would logically belong there, but I
remember it helped)

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 stepan at coresystems.de  Wed May 24 00:58:43 2006
From: stepan at coresystems.de (Stefan Reinauer)
Date: Wed, 24 May 2006 00:58:43 +0200
Subject: [LinuxBIOS] wiki access and commit rights
In-Reply-To: <44733C0F.9030904@lanl.gov>
References: <44730E2D.8040609@gmx.net> <20060523150036.GA794@coresystems.de>
	<4473328B.7000907@gmx.net> <44733C0F.9030904@lanl.gov>
Message-ID: <20060523225843.GD3701@coresystems.de>

* Ronald G Minnich <rminnich at lanl.gov> [060523 18:45]:
> Please, please make sure when you send a patch you have tested with a 
> abuild.
 
Yes, this helps a lot. We have seriously been considering to
automatically block patches that break builds in the tree automatically.

The reason we didnt was basically the time it takes to compile all
boards, and decoupling the processes to work concurrently hasnt been
done due to lack of time.

> Stefan, I recently found a build problem that only cropped up with 
> maximum log levels set to 9. Can we have a Config.abuild in each target 
> directory with "all options on"? How do we cover this?
 
Defining "on" with non-boolean values can be tricky ;-) We can go and 
compile everything with 9, then 8, then 7, ... and see where it starts
working.

I remember with the agami/aruma the reason I tried to push CAR is
because romcc would compile something like 10-20 minutes before you get
an error message that you are running out of registers.

Should we just force this low by setting ASM_CONSOLE_LOGLEVEL here?

So the question is: How do we want to cope with a board that compiles
with 8 but not with 9. Is this broken? Or would it be smart to say "this is
so complex it will never work with more than 8"?

   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 stepan at coresystems.de  Wed May 24 01:29:04 2006
From: stepan at coresystems.de (Stefan Reinauer)
Date: Wed, 24 May 2006 01:29:04 +0200
Subject: [LinuxBIOS] Compressing the OLPC VSM?
In-Reply-To: <44734BEE.8020000@gmx.net>
References: <44733455.7010502@gmx.net> <44734160.8070206@lanl.gov>
	<44734BEE.8020000@gmx.net>
Message-ID: <20060523232904.GB2942@coresystems.de>

* Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006 at gmx.net> [060523 19:52]:
> Ronald G Minnich wrote:
> > Carl-Daniel Hailfinger wrote:
> >> Hi,
> >>
> >> the VSM Ron mailed yesterday to olpc-devel can be compressed
> >> very well to under 32 kb.
> >>
> >> 65536 vsa_test.64k-0001.bin
> >> 35587 vsa_test.64k-0001.bin.nrv2b
> >> 32143 vsa_test.64k-0001.bin.lzma
> >>
> >> Is the VSM executed after RAM is there and can we use compression
> >> for it? 50% savings are really good.
> >>
> > yes, this is great. I want to move to the new compression asap.
> 
> See my other patch to the list which adds the decompression code
> and infrastructure. I'm preparing another patch which will make
> use of all that code. The patches I sent until now do not modify
> any existing code, so they should be safe to apply.

Can you try and see whether we can exchange the assembler nrv2b code 
in crt0.S.lb with something gcc compiled? This would make the whole
compression thing nicely pluggable..

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 stepan at coresystems.de  Wed May 24 01:31:38 2006
From: stepan at coresystems.de (Stefan Reinauer)
Date: Wed, 24 May 2006 01:31:38 +0200
Subject: [LinuxBIOS] Compressing the OLPC VSM?
In-Reply-To: <44734D44.3030606@gmx.net>
References: <44733455.7010502@gmx.net> <44734160.8070206@lanl.gov>
	<44734C1C.9000508@lesc.ufc.br> <44734D44.3030606@gmx.net>
Message-ID: <20060523233138.GC2942@coresystems.de>

* Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006 at gmx.net> [060523 19:58]:
> http://laptop.org/pipermail/devel/attachments/20060521/e389e3ea/vsa_test.64k-0001.bin
> 
> >>> 65536 vsa_test.64k-0001.bin
> >>> 35587 vsa_test.64k-0001.bin.nrv2b
> >>> 32143 vsa_test.64k-0001.bin.lzma
> 
> If it is better than the lzma result, we may consider it.
> But IIRC the JCalg author said that lzma should be better.

Just as a comparison:

34981 2006-05-22 07:25 vsa_test.64k-0001.bin.bz2

bzip2 is bigger than lzma here..

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 stepan at coresystems.de  Wed May 24 01:40:48 2006
From: stepan at coresystems.de (Stefan Reinauer)
Date: Wed, 24 May 2006 01:40:48 +0200
Subject: [LinuxBIOS] selection of compression algorithm
In-Reply-To: <44734B20.3070306@gmx.net>
References: <6F7DA19D05F3CF40B890C7CA2DB13A4203094CD8@ssvlexmb2.amd.com>
	<4473029B.5040003@gmx.net> <44733441.7040707@lanl.gov>
	<44734B20.3070306@gmx.net>
Message-ID: <20060523234048.GA4362@coresystems.de>

* Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006 at gmx.net> [060523 19:49]:
> Ronald G Minnich wrote:
> > Carl-Daniel Hailfinger wrote:
> >> Lu, Yinghai wrote:
> >>
> >>> Copy_and_run is used by CAR and included in cache_as_ram_auto.c and
> >>> compiled with gcc. That should be changed to use lzma easily.
> >>>
> >>> CONFIG_COMPRESSED_ROM_STREAM is used for pay load. --- stream_init will
> >>> do the uncompressed. ( stream_init is in ram)
> >>>
> >>> CONFIG_COMPRESS is for linuxbios_ram.rom --- copy_and_run will do the
> >>> uncompress. ( copy_and_run is ROM, and used ram as stack and local
> >>> variable)
> >>
> >> Patch attached to clear up the naming confusion. Applies on top of my
> >> older patch.
> >> Please apply.
> > 
> > this has passed the abuild regression test and works on at least one 
> > platform, right?
> 
> I have no platform on which LinuxBIOS runs on, but it caused no regression
> in abuild. (But a lot of targets do not seem to compile at all, even without
> my patch. Does this depend on the gcc version? I have gcc 3.3.5)

Is it different from this one?

http://snapshots.linuxbios.org/stats/abuild-LinuxBIOSv2-2310.log

This one seems to occur a couple of times, who's the culprit?
  crt0.S:(.rom.text+0x350b): undefined reference to `printk_debug'


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 stepan at coresystems.de  Wed May 24 01:42:09 2006
From: stepan at coresystems.de (Stefan Reinauer)
Date: Wed, 24 May 2006 01:42:09 +0200
Subject: [LinuxBIOS] selection of compression algorithm
In-Reply-To: <44734FC3.4020906@gmx.net>
References: <6F7DA19D05F3CF40B890C7CA2DB13A4203094CD8@ssvlexmb2.amd.com>
	<4473029B.5040003@gmx.net> <44733441.7040707@lanl.gov>
	<44734B20.3070306@gmx.net> <44734BD2.9090007@lanl.gov>
	<44734FC3.4020906@gmx.net>
Message-ID: <20060523234208.GB4362@coresystems.de>

* Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006 at gmx.net> [060523 20:09]:
> Ronald G Minnich wrote:
> > Carl-Daniel Hailfinger wrote:
> > 
> >>
> >> I have no platform on which LinuxBIOS runs on, but it caused no
> >> regression
> >> in abuild. (But a lot of targets do not seem to compile at all, even
> >> without
> >> my patch. Does this depend on the gcc version? I have gcc 3.3.5)
> > 
> > don't know, I will try to test your patch via abuild but I don't want to
> > commit until then.
> 
> Yes, it was a gcc bug. gcc 4.1.0 has no problems compiling it.
> I'll continue testing and developing with gcc 4.1.0 from now on.

Can we get it compiling with 3.3.5 as well? What's the bug about?
I'm using 4.1 as a reference compiler at the moment, but lots of people
out there have older compilers I think...

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 c-d.hailfinger.devel.2006 at gmx.net  Wed May 24 02:01:58 2006
From: c-d.hailfinger.devel.2006 at gmx.net (Carl-Daniel Hailfinger)
Date: Wed, 24 May 2006 02:01:58 +0200
Subject: [LinuxBIOS] selection of compression algorithm
In-Reply-To: <2ea3fae10605231253j60cda13byd2aa1c4dfa81b580@mail.gmail.com>
References: <4470B968.5040100@gmx.net>	<2ea3fae10605211352g1731bc62v16ddcda6c2e4b734@mail.gmail.com>	<447123E2.6060000@gmx.net>
	<44714AD5.8030201@lanl.gov>	<447276D2.4090403@gmx.net>	<2ea3fae10605222210o255485cw3422bd8788411692@mail.gmail.com>	<20060523064416.GC3392@coresystems.de>	<2ea3fae10605230226o596398f1n726d1662fc9455cd@mail.gmail.com>	<20060523101411.GA23954@coresystems.de>
	<2ea3fae10605231253j60cda13byd2aa1c4dfa81b580@mail.gmail.com>
Message-ID: <4473A276.6050602@gmx.net>

yhlu wrote:
> linuxbios_apc.rom is the code for ap. The code is in it's own cache.
> So BSP is executing the code in ROM and RAM, and at the same time the
> APs executing code in cache.
> 
> The AP uncompress the linuxbios_apc.rom from rom to it's cache before
> jump it. At that time the RAM on BSP is ready already.

Sorry, can you please explain what AP, APC and BSP are?


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



From c-d.hailfinger.devel.2006 at gmx.net  Wed May 24 02:06:11 2006
From: c-d.hailfinger.devel.2006 at gmx.net (Carl-Daniel Hailfinger)
Date: Wed, 24 May 2006 02:06:11 +0200
Subject: [LinuxBIOS] selection of compression algorithm
In-Reply-To: <20060523234208.GB4362@coresystems.de>
References: <6F7DA19D05F3CF40B890C7CA2DB13A4203094CD8@ssvlexmb2.amd.com>	<4473029B.5040003@gmx.net>
	<44733441.7040707@lanl.gov>	<44734B20.3070306@gmx.net>
	<44734BD2.9090007@lanl.gov>	<44734FC3.4020906@gmx.net>
	<20060523234208.GB4362@coresystems.de>
Message-ID: <4473A373.9010804@gmx.net>

Stefan Reinauer wrote:
> * Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006 at gmx.net> [060523 20:09]:
>> Ronald G Minnich wrote:
>>> Carl-Daniel Hailfinger wrote:
>>>
>>>> I have no platform on which LinuxBIOS runs on, but it caused no
>>>> regression
>>>> in abuild. (But a lot of targets do not seem to compile at all, even
>>>> without
>>>> my patch. Does this depend on the gcc version? I have gcc 3.3.5)
>>> don't know, I will try to test your patch via abuild but I don't want to
>>> commit until then.
>> Yes, it was a gcc bug. gcc 4.1.0 has no problems compiling it.
>> I'll continue testing and developing with gcc 4.1.0 from now on.
> 
> Can we get it compiling with 3.3.5 as well? What's the bug about?
> I'm using 4.1 as a reference compiler at the moment, but lots of people
> out there have older compilers I think...

LinuxBIOSv2-2310/src/cpu/amd/model_gx2/cpubug.c:199:75: missing terminating ' character
LinuxBIOSv2-2310/src/cpu/amd/model_gx2/cpubug.c:205:70: missing terminating ' character

I can retest once that is fixed.

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



From c-d.hailfinger.devel.2006 at gmx.net  Wed May 24 02:00:58 2006
From: c-d.hailfinger.devel.2006 at gmx.net (Carl-Daniel Hailfinger)
Date: Wed, 24 May 2006 02:00:58 +0200
Subject: [LinuxBIOS] selection of compression algorithm
In-Reply-To: <2ea3fae10605231249w427bdfb1u736078b495d9a1e3@mail.gmail.com>
References: <4470B968.5040100@gmx.net>
	<44714A87.1040402@lanl.gov>	<20060522092725.GB32661@coresystems.de>	<2ea3fae10605220322x7ac5e2ds40410ac10ad93485@mail.gmail.com>	<44721118.8010207@gmx.net>
	<20060522200504.GA27672@coresystems.de>	<447333D4.4000907@lanl.gov>
	<44735ED8.9000303@gmx.net>
	<2ea3fae10605231249w427bdfb1u736078b495d9a1e3@mail.gmail.com>
Message-ID: <4473A23A.5060002@gmx.net>

yhlu wrote:
> We at least need two times
> 1. one is in car stage, and the code is in rom, and it is used to
> uncompress linuxbios_ram
> 2. one is in linuxbios_ram, and it is in ram, it is used to uncompress payload.
> 
> car stage, before call copy_and_run, the stack is already in ram. but
> code is still in rom. So at this time we need to balance the lzma
> benifit on compress linuxbios_ram and it's own code size increase in
> rom. also need to set one extra buffer in ram for every ap code.

OK, so we have to check which of the two solutions is smaller.
1) lzma decompressor + lzma compressed linuxbios_ram
2) nrv2b decompressor + nrv2b compressed (linuxbios_ram + lzma decompressor)

I just checked this for all abuild targets. The second variant wins
for half of the targets. That brings me to a third option:
3) nrv2b decompressor + nrv2b compressed lzma decompressor + lzma
   compressed linuxbios_ram
nrv2b decompressor needs IIRC 512 bytes, lzma decompressor needs 4096
bytes, so if nrv2b only compresses the lzma decompressor and we assume
~50% savings by compression, option 3 is always 1.5k smaller than option 1
and option 3 is 1.5k-7.3k smaller (2k for OLPC) than option 2.

How difficult would it be for us to build option 3?

> Hope we can squash car stage code + linuxbios_ram code into 64k again.

Depending on the board, that might be difficult. For OLPC, everything fits
nicely into 32k. For most Tyan boards, we suffer from the fact that auto.o
is uncompressed and ~28k alone. That is really horrible. Any reasons for
that?


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



From c-d.hailfinger.devel.2006 at gmx.net  Wed May 24 02:49:44 2006
From: c-d.hailfinger.devel.2006 at gmx.net (Carl-Daniel Hailfinger)
Date: Wed, 24 May 2006 02:49:44 +0200
Subject: [LinuxBIOS] wiki access and commit rights
In-Reply-To: <20060523225843.GD3701@coresystems.de>
References: <44730E2D.8040609@gmx.net>
	<20060523150036.GA794@coresystems.de>	<4473328B.7000907@gmx.net>
	<44733C0F.9030904@lanl.gov> <20060523225843.GD3701@coresystems.de>
Message-ID: <4473ADA8.2090407@gmx.net>

Stefan Reinauer wrote:
> * Ronald G Minnich <rminnich at lanl.gov> [060523 18:45]:
>> Please, please make sure when you send a patch you have tested with a 
>> abuild.
>  
> Yes, this helps a lot. We have seriously been considering to
> automatically block patches that break builds in the tree automatically.
> 
> The reason we didnt was basically the time it takes to compile all
> boards, and decoupling the processes to work concurrently hasnt been
> done due to lack of time.

We still could check after the fact and mail the blame to this list.
Hm. I just hacked together a logfile analyzer. What about such a log:

New in revision 2303:
New in revision 2304:
New in revision 2305:
New in revision 2306:
New in revision 2307:
 Processing mainboard/broadcom/blast (i386: ok, we're amd64)
   Creating config file... ok
   Creating builddir...ok
-  Compiling image ..ok.
+  Compiling image ..FAILED! Log excerpt:
+crt0.S:(.rom.text+0x500f): undefined reference to `printk_debug'
+collect2: ld returned 1 exit status
+make[1]: *** [linuxbios] Error 1
+make[1]: Leaving directory `/srv/svn/linuxbios-extra/tmp/LinuxBIOSv2/util/abuild/linuxbios-builds/broadcom_blast/normal'
+make: *** [normal/linuxbios.rom] Error 1

 Processing mainboard/tyan/s2735 (i386: ok, we're amd64)
   Creating config file... ok
   Creating builddir...ok
-  Compiling image ..ok.
+  Compiling image ..FAILED! Log excerpt:
+crt0.S:(.rom.text+0x1e7f): undefined reference to `printk_debug'
+collect2: ld returned 1 exit status
+make[1]: *** [linuxbios] Error 1
+make[1]: Leaving directory `/srv/svn/linuxbios-extra/tmp/LinuxBIOSv2/util/abuild/linuxbios-builds/tyan_s2735/normal'
+make: *** [normal/linuxbios.rom] Error 1

 Processing mainboard/tyan/s2891 (i386: ok, we're amd64)
   Creating config file... ok
   Creating builddir...ok
-  Compiling image ..ok.
+  Compiling image ..FAILED! Log excerpt:
+crt0.S:(.rom.text+0x32e3): undefined reference to `printk_debug'
+collect2: ld returned 1 exit status
+make[1]: *** [linuxbios] Error 1
+make[1]: Leaving directory `/srv/svn/linuxbios-extra/tmp/LinuxBIOSv2/util/abuild/linuxbios-builds/tyan_s2891/normal'
+make: *** [normal/linuxbios.rom] Error 1

 Processing mainboard/tyan/s2895 (i386: ok, we're amd64)
   Creating config file... ok
   Creating builddir...ok
-  Compiling image ..ok.
+  Compiling image ..FAILED! Log excerpt:
+crt0.S:(.rom.text+0x350b): undefined reference to `printk_debug'
+collect2: ld returned 1 exit status
+make[1]: *** [linuxbios] Error 1
+make[1]: Leaving directory `/srv/svn/linuxbios-extra/tmp/LinuxBIOSv2/util/abuild/linuxbios-builds/tyan_s2895/normal'
+make: *** [normal/linuxbios.rom] Error 1

New in revision 2308:
New in revision 2309:
New in revision 2310:


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



From c-d.hailfinger.devel.2006 at gmx.net  Wed May 24 02:56:38 2006
From: c-d.hailfinger.devel.2006 at gmx.net (Carl-Daniel Hailfinger)
Date: Wed, 24 May 2006 02:56:38 +0200
Subject: [LinuxBIOS] Compressing the OLPC VSM?
In-Reply-To: <20060523232904.GB2942@coresystems.de>
References: <44733455.7010502@gmx.net>
	<44734160.8070206@lanl.gov>	<44734BEE.8020000@gmx.net>
	<20060523232904.GB2942@coresystems.de>
Message-ID: <4473AF46.30307@gmx.net>

Stefan Reinauer wrote:
> Can you try and see whether we can exchange the assembler nrv2b code 
> in crt0.S.lb with something gcc compiled? This would make the whole
> compression thing nicely pluggable..

Sorry, I'm swamped with university work right now. Maybe later.

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



From myneil at gmail.com  Wed May 24 03:48:41 2006
From: myneil at gmail.com (Neil)
Date: Wed, 24 May 2006 09:48:41 +0800
Subject: [LinuxBIOS] linux bios hang when jump in kernel
In-Reply-To: <20060523223530.GC3701@coresystems.de>
References: <5c5dcf370605220053r3a58b786j143d902a35951ff3@mail.gmail.com>
	<44733263.8020902@lanl.gov> <20060523223530.GC3701@coresystems.de>
Message-ID: <5c5dcf370605231848w53747eadi942a1cdecddef565@mail.gmail.com>

Thank you .

   I have not add ACPI function .If I need an entry for bus 1 means that :
write_pirq_info(pirq_info, bus_bcm5785_0, (sbdn<<3)|0, 0x1, 0xdef8, 0x2,
0xdef8, 0x3, 0xdef8, 0x4, 0xdef8, 0, 0);

before this string ,I should specify the irq rule ?

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

From stepan at coresystems.de  Wed May 24 11:48:50 2006
From: stepan at coresystems.de (Stefan Reinauer)
Date: Wed, 24 May 2006 11:48:50 +0200
Subject: [LinuxBIOS] selection of compression algorithm
In-Reply-To: <4473A373.9010804@gmx.net>
References: <6F7DA19D05F3CF40B890C7CA2DB13A4203094CD8@ssvlexmb2.amd.com>
	<4473029B.5040003@gmx.net> <44733441.7040707@lanl.gov>
	<44734B20.3070306@gmx.net> <44734BD2.9090007@lanl.gov>
	<44734FC3.4020906@gmx.net> <20060523234208.GB4362@coresystems.de>
	<4473A373.9010804@gmx.net>
Message-ID: <20060524094850.GB495@coresystems.de>

* Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006 at gmx.net> [060524 02:06]:
> Stefan Reinauer wrote:
> > * Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006 at gmx.net> [060523 20:09]:
> >> Ronald G Minnich wrote:
> >>> Carl-Daniel Hailfinger wrote:
> >>>
> >>>> I have no platform on which LinuxBIOS runs on, but it caused no
> >>>> regression
> >>>> in abuild. (But a lot of targets do not seem to compile at all, even
> >>>> without
> >>>> my patch. Does this depend on the gcc version? I have gcc 3.3.5)
> >>> don't know, I will try to test your patch via abuild but I don't want to
> >>> commit until then.
> >> Yes, it was a gcc bug. gcc 4.1.0 has no problems compiling it.
> >> I'll continue testing and developing with gcc 4.1.0 from now on.
> > 
> > Can we get it compiling with 3.3.5 as well? What's the bug about?
> > I'm using 4.1 as a reference compiler at the moment, but lots of people
> > out there have older compilers I think...
> 
> LinuxBIOSv2-2310/src/cpu/amd/model_gx2/cpubug.c:199:75: missing terminating ' character
> LinuxBIOSv2-2310/src/cpu/amd/model_gx2/cpubug.c:205:70: missing terminating ' character

Indeed weird! This is in the middle of #ifdef 0?


-- 
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 stepan at coresystems.de  Wed May 24 11:51:55 2006
From: stepan at coresystems.de (Stefan Reinauer)
Date: Wed, 24 May 2006 11:51:55 +0200
Subject: [LinuxBIOS] linux bios hang when jump in kernel
In-Reply-To: <5c5dcf370605231848w53747eadi942a1cdecddef565@mail.gmail.com>
References: <5c5dcf370605220053r3a58b786j143d902a35951ff3@mail.gmail.com>
	<44733263.8020902@lanl.gov> <20060523223530.GC3701@coresystems.de>
	<5c5dcf370605231848w53747eadi942a1cdecddef565@mail.gmail.com>
Message-ID: <20060524095155.GC495@coresystems.de>

* Neil <myneil at gmail.com> [060524 03:48]:
> Thank you .
> 
>    I have not add ACPI function .If I need an entry for bus 1 means that :
> write_pirq_info(pirq_info, bus_bcm5785_0, (sbdn<<3)|0, 0x1, 0xdef8, 0x2,
> 0xdef8, 0x3, 0xdef8, 0x4, 0xdef8, 0, 0);


arima/hdama/irq_tables.c:

                /* Let Linux know about bus 1 */
                IRQ_SLOT(0, 1,4,3, 0,0,0,0 ),

(1.4.3 is the irq router iirc)


-- 
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 stepan at coresystems.de  Wed May 24 12:45:33 2006
From: stepan at coresystems.de (Stefan Reinauer)
Date: Wed, 24 May 2006 12:45:33 +0200
Subject: [LinuxBIOS] selection of compression algorithm
In-Reply-To: <2ea3fae10605231249w427bdfb1u736078b495d9a1e3@mail.gmail.com>
References: <4470B968.5040100@gmx.net> <44714A87.1040402@lanl.gov>
	<20060522092725.GB32661@coresystems.de>
	<2ea3fae10605220322x7ac5e2ds40410ac10ad93485@mail.gmail.com>
	<44721118.8010207@gmx.net> <20060522200504.GA27672@coresystems.de>
	<447333D4.4000907@lanl.gov> <44735ED8.9000303@gmx.net>
	<2ea3fae10605231249w427bdfb1u736078b495d9a1e3@mail.gmail.com>
Message-ID: <20060524104533.GA3836@coresystems.de>

* yhlu <yinghailu at gmail.com> [060523 21:49]:
> 2. one is in linuxbios_ram, and it is in ram, it is used to uncompress 
> payload.
> 
> car stage, before call copy_and_run, the stack is already in ram. but
> code is still in rom. So at this time we need to balance the lzma
> benifit on compress linuxbios_ram and it's own code size increase in

We have to be careful here, indeed.

> rom. also need to set one extra buffer in ram for every ap code.

Can't the APs share the code?

-- 
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 c-d.hailfinger.devel.2006 at gmx.net  Wed May 24 15:19:47 2006
From: c-d.hailfinger.devel.2006 at gmx.net (Carl-Daniel Hailfinger)
Date: Wed, 24 May 2006 15:19:47 +0200
Subject: [LinuxBIOS] selection of compression algorithm
In-Reply-To: <20060524094850.GB495@coresystems.de>
References: <6F7DA19D05F3CF40B890C7CA2DB13A4203094CD8@ssvlexmb2.amd.com>	<4473029B.5040003@gmx.net>
	<44733441.7040707@lanl.gov>	<44734B20.3070306@gmx.net>
	<44734BD2.9090007@lanl.gov>	<44734FC3.4020906@gmx.net>
	<20060523234208.GB4362@coresystems.de>	<4473A373.9010804@gmx.net>
	<20060524094850.GB495@coresystems.de>
Message-ID: <44745D73.9000303@gmx.net>

Stefan Reinauer wrote:
> * Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006 at gmx.net> [060524 02:06]:
>> Stefan Reinauer wrote:
>>> * Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006 at gmx.net> [060523 20:09]:
>>>> Ronald G Minnich wrote:
>>>>> Carl-Daniel Hailfinger wrote:
>>>>>
>>>>>> I have no platform on which LinuxBIOS runs on, but it caused no
>>>>>> regression
>>>>>> in abuild. (But a lot of targets do not seem to compile at all, even
>>>>>> without
>>>>>> my patch. Does this depend on the gcc version? I have gcc 3.3.5)
>>>>> don't know, I will try to test your patch via abuild but I don't want to
>>>>> commit until then.
>>>> Yes, it was a gcc bug. gcc 4.1.0 has no problems compiling it.
>>>> I'll continue testing and developing with gcc 4.1.0 from now on.
>>> Can we get it compiling with 3.3.5 as well? What's the bug about?
>>> I'm using 4.1 as a reference compiler at the moment, but lots of people
>>> out there have older compilers I think...
>> LinuxBIOSv2-2310/src/cpu/amd/model_gx2/cpubug.c:199:75: missing terminating ' character
>> LinuxBIOSv2-2310/src/cpu/amd/model_gx2/cpubug.c:205:70: missing terminating ' character
> 
> Indeed weird! This is in the middle of #ifdef 0?

Yes.

Tom Sylla @ AMD just wrote off-list:
> You can safely just remove those ticks. They are in comments in an
> if 0'ed section of reference code.


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



From per.hallsmark at t2data.se  Wed May 24 16:53:12 2006
From: per.hallsmark at t2data.se (Per Hallsmark)
Date: Wed, 24 May 2006 16:53:12 +0200
Subject: [LinuxBIOS] selection of compression algorithm
In-Reply-To: <20060524094850.GB495@coresystems.de>
References: <6F7DA19D05F3CF40B890C7CA2DB13A4203094CD8@ssvlexmb2.amd.com>	<4473029B.5040003@gmx.net>
	<44733441.7040707@lanl.gov>	<44734B20.3070306@gmx.net>
	<44734BD2.9090007@lanl.gov>	<44734FC3.4020906@gmx.net>
	<20060523234208.GB4362@coresystems.de>	<4473A373.9010804@gmx.net>
	<20060524094850.GB495@coresystems.de>
Message-ID: <44747358.2020003@t2data.se>

well, perhaps not so weird... the #ifdef 0 is weird. Shouldn't it be #if 
0 instead to comment out stuff? :-)

Stefan Reinauer wrote:

>* Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006 at gmx.net> [060524 02:06]:
>  
>
>>Stefan Reinauer wrote:
>>    
>>
>>>* Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006 at gmx.net> [060523 20:09]:
>>>      
>>>
>>>>Ronald G Minnich wrote:
>>>>        
>>>>
>>>>>Carl-Daniel Hailfinger wrote:
>>>>>
>>>>>          
>>>>>
>>>>>>I have no platform on which LinuxBIOS runs on, but it caused no
>>>>>>regression
>>>>>>in abuild. (But a lot of targets do not seem to compile at all, even
>>>>>>without
>>>>>>my patch. Does this depend on the gcc version? I have gcc 3.3.5)
>>>>>>            
>>>>>>
>>>>>don't know, I will try to test your patch via abuild but I don't want to
>>>>>commit until then.
>>>>>          
>>>>>
>>>>Yes, it was a gcc bug. gcc 4.1.0 has no problems compiling it.
>>>>I'll continue testing and developing with gcc 4.1.0 from now on.
>>>>        
>>>>
>>>Can we get it compiling with 3.3.5 as well? What's the bug about?
>>>I'm using 4.1 as a reference compiler at the moment, but lots of people
>>>out there have older compilers I think...
>>>      
>>>
>>LinuxBIOSv2-2310/src/cpu/amd/model_gx2/cpubug.c:199:75: missing terminating ' character
>>LinuxBIOSv2-2310/src/cpu/amd/model_gx2/cpubug.c:205:70: missing terminating ' character
>>    
>>
>
>Indeed weird! This is in the middle of #ifdef 0?
>
>
>  
>

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

From rminnich at lanl.gov  Wed May 24 17:45:11 2006
From: rminnich at lanl.gov (Ronald G Minnich)
Date: Wed, 24 May 2006 09:45:11 -0600
Subject: [LinuxBIOS] wiki access and commit rights
In-Reply-To: <20060523225843.GD3701@coresystems.de>
References: <44730E2D.8040609@gmx.net> <20060523150036.GA794@coresystems.de>
	<4473328B.7000907@gmx.net> <44733C0F.9030904@lanl.gov>
	<20060523225843.GD3701@coresystems.de>
Message-ID: <44747F87.6000000@lanl.gov>

Stefan Reinauer wrote:

> So the question is: How do we want to cope with a board that compiles
> with 8 but not with 9. Is this broken? Or would it be smart to say "this is
> so complex it will never work with more than 8"?


my problem was simpler. A debug print used a variable that was only 
defined in the romcc world. It was a simple problem. But it only showed 
up when the debug print was enabled.

ron



From rminnich at lanl.gov  Wed May 24 17:45:51 2006
From: rminnich at lanl.gov (Ronald G Minnich)
Date: Wed, 24 May 2006 09:45:51 -0600
Subject: [LinuxBIOS] wiki access and commit rights
In-Reply-To: <4473ADA8.2090407@gmx.net>
References: <44730E2D.8040609@gmx.net>
	<20060523150036.GA794@coresystems.de>	<4473328B.7000907@gmx.net>
	<44733C0F.9030904@lanl.gov> <20060523225843.GD3701@coresystems.de>
	<4473ADA8.2090407@gmx.net>
Message-ID: <44747FAF.2090804@lanl.gov>

Carl-Daniel Hailfinger wrote:
> Stefan Reinauer wrote:
> 
>>* Ronald G Minnich <rminnich at lanl.gov> [060523 18:45]:
>>
>>>Please, please make sure when you send a patch you have tested with a 
>>>abuild.
>>
>> 
>>Yes, this helps a lot. We have seriously been considering to
>>automatically block patches that break builds in the tree automatically.
>>
>>The reason we didnt was basically the time it takes to compile all
>>boards, and decoupling the processes to work concurrently hasnt been
>>done due to lack of time.
> 
> 
> We still could check after the fact and mail the blame to this list.
> Hm. I just hacked together a logfile analyzer. What about such a log:

sure. this is a low-traffic list. I think letting people see the errors 
might be useful.

comments?

ron



From c-d.hailfinger.devel.2006 at gmx.net  Wed May 24 19:03:36 2006
From: c-d.hailfinger.devel.2006 at gmx.net (Carl-Daniel Hailfinger)
Date: Wed, 24 May 2006 19:03:36 +0200
Subject: [LinuxBIOS] [Report] Revision 2307 broke 4 targets
Message-ID: <447491E8.1090400@gmx.net>

This is a half-automatically generated report. If you are
the author of this patch, please fix it up.

Author: rminnich
Date: 2006-05-18 05:07:16 +0200 (Thu, 18 May 2006)
New Revision: 2307

Modified:
   trunk/LinuxBIOSv2/src/cpu/amd/model_gx2/vsmsetup.c
   trunk/LinuxBIOSv2/src/lib/nrv2b.c
   trunk/LinuxBIOSv2/src/mainboard/amd/rumba/Options.lb
   trunk/LinuxBIOSv2/src/mainboard/olpc/rev_a/Options.lb
   trunk/LinuxBIOSv2/src/stream/rom_stream.c
   trunk/LinuxBIOSv2/targets/olpc/rev_a/Config.lb
Log:
cleanup some of the compressed rom stream ugliness -- more to do!
olpc and rumba can now boot linux out of flash. vsa was resized to 64K.
olpc and rumba now used compressed payload -- thanks stefan!


ERRORS:
New in revision 2307:
 Processing mainboard/broadcom/blast (i386: ok, we're amd64)
   Creating config file... ok
   Creating builddir...ok
-  Compiling image ..ok.
+  Compiling image ..FAILED! Log excerpt:
+crt0.S:(.rom.text+0x500f): undefined reference to `printk_debug'
+collect2: ld returned 1 exit status
+make[1]: *** [linuxbios] Error 1
+make[1]: Leaving directory `/srv/svn/linuxbios-extra/tmp/LinuxBIOSv2/util/abuild/linuxbios-builds/broadcom_blast/normal'
+make: *** [normal/linuxbios.rom] Error 1

 Processing mainboard/tyan/s2735 (i386: ok, we're amd64)
   Creating config file... ok
   Creating builddir...ok
-  Compiling image ..ok.
+  Compiling image ..FAILED! Log excerpt:
+crt0.S:(.rom.text+0x1e7f): undefined reference to `printk_debug'
+collect2: ld returned 1 exit status
+make[1]: *** [linuxbios] Error 1
+make[1]: Leaving directory `/srv/svn/linuxbios-extra/tmp/LinuxBIOSv2/util/abuild/linuxbios-builds/tyan_s2735/normal'
+make: *** [normal/linuxbios.rom] Error 1

 Processing mainboard/tyan/s2891 (i386: ok, we're amd64)
   Creating config file... ok
   Creating builddir...ok
-  Compiling image ..ok.
+  Compiling image ..FAILED! Log excerpt:
+crt0.S:(.rom.text+0x32e3): undefined reference to `printk_debug'
+collect2: ld returned 1 exit status
+make[1]: *** [linuxbios] Error 1
+make[1]: Leaving directory `/srv/svn/linuxbios-extra/tmp/LinuxBIOSv2/util/abuild/linuxbios-builds/tyan_s2891/normal'
+make: *** [normal/linuxbios.rom] Error 1

 Processing mainboard/tyan/s2895 (i386: ok, we're amd64)
   Creating config file... ok
   Creating builddir...ok
-  Compiling image ..ok.
+  Compiling image ..FAILED! Log excerpt:
+crt0.S:(.rom.text+0x350b): undefined reference to `printk_debug'
+collect2: ld returned 1 exit status
+make[1]: *** [linuxbios] Error 1
+make[1]: Leaving directory `/srv/svn/linuxbios-extra/tmp/LinuxBIOSv2/util/abuild/linuxbios-builds/tyan_s2895/normal'
+make: *** [normal/linuxbios.rom] Error 1


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



From stepan at coresystems.de  Wed May 24 19:49:21 2006
From: stepan at coresystems.de (Stefan Reinauer)
Date: Wed, 24 May 2006 19:49:21 +0200
Subject: [LinuxBIOS] selection of compression algorithm
In-Reply-To: <44747358.2020003@t2data.se>
References: <6F7DA19D05F3CF40B890C7CA2DB13A4203094CD8@ssvlexmb2.amd.com>
	<4473029B.5040003@gmx.net> <44733441.7040707@lanl.gov>
	<44734B20.3070306@gmx.net> <44734BD2.9090007@lanl.gov>
	<44734FC3.4020906@gmx.net> <20060523234208.GB4362@coresystems.de>
	<4473A373.9010804@gmx.net> <20060524094850.GB495@coresystems.de>
	<44747358.2020003@t2data.se>
Message-ID: <20060524174920.GA3047@coresystems.de>

* Per Hallsmark <per.hallsmark at t2data.se> [060524 16:53]:
> well, perhaps not so weird... the #ifdef 0 is weird. Shouldn't it be #if 0
> instead to comment out stuff? :-)
 
heh.. No doubt. But the code says #if 0 indeed. It was just me who
messed the mail up.

  Stefan




From yinghailu at gmail.com  Wed May 24 20:28:43 2006
From: yinghailu at gmail.com (yhlu)
Date: Wed, 24 May 2006 11:28:43 -0700
Subject: [LinuxBIOS] selection of compression algorithm
In-Reply-To: <4473A23A.5060002@gmx.net>
References: <4470B968.5040100@gmx.net> <44714A87.1040402@lanl.gov>
	<20060522092725.GB32661@coresystems.de>
	<2ea3fae10605220322x7ac5e2ds40410ac10ad93485@mail.gmail.com>
	<44721118.8010207@gmx.net> <20060522200504.GA27672@coresystems.de>
	<447333D4.4000907@lanl.gov> <44735ED8.9000303@gmx.net>
	<2ea3fae10605231249w427bdfb1u736078b495d9a1e3@mail.gmail.com>
	<4473A23A.5060002@gmx.net>
Message-ID: <2ea3fae10605241128j2acfd325w8e7a34f06ba94049@mail.gmail.com>

On 5/23/06, Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006 at gmx.net> wrote:
> Depending on the board, that might be difficult. For OLPC, everything fits
> nicely into 32k. For most Tyan boards, we suffer from the fact that auto.o
> is uncompressed and ~28k alone. That is really horrible. Any reasons for

That is because of romcc can not have function call. with car
cache_as_ram_auto.c you can have that smaller.

YH



From yinghailu at gmail.com  Wed May 24 20:30:55 2006
From: yinghailu at gmail.com (yhlu)
Date: Wed, 24 May 2006 11:30:55 -0700
Subject: [LinuxBIOS] selection of compression algorithm
In-Reply-To: <4473A276.6050602@gmx.net>
References: <4470B968.5040100@gmx.net> <447123E2.6060000@gmx.net>
	<44714AD5.8030201@lanl.gov> <447276D2.4090403@gmx.net>
	<2ea3fae10605222210o255485cw3422bd8788411692@mail.gmail.com>
	<20060523064416.GC3392@coresystems.de>
	<2ea3fae10605230226o596398f1n726d1662fc9455cd@mail.gmail.com>
	<20060523101411.GA23954@coresystems.de>
	<2ea3fae10605231253j60cda13byd2aa1c4dfa81b580@mail.gmail.com>
	<4473A276.6050602@gmx.net>
Message-ID: <2ea3fae10605241130oc8e424fxa81525edd907e0ca@mail.gmail.com>

AP: application processor. it mean all processor except BSP
BSP: bootstrap processor. the first cpu is running, and it will start APs.
APC:  I call the code that is running on AP only.

YH


On 5/23/06, Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006 at gmx.net> wrote:
> yhlu wrote:
> > linuxbios_apc.rom is the code for ap. The code is in it's own cache.
> > So BSP is executing the code in ROM and RAM, and at the same time the
> > APs executing code in cache.
> >
> > The AP uncompress the linuxbios_apc.rom from rom to it's cache before
> > jump it. At that time the RAM on BSP is ready already.
>
> Sorry, can you please explain what AP, APC and BSP are?
>
>
> Regards,
> Carl-Daniel
> --
> http://www.hailfinger.org/
>



From yinghailu at gmail.com  Wed May 24 20:32:47 2006
From: yinghailu at gmail.com (yhlu)
Date: Wed, 24 May 2006 11:32:47 -0700
Subject: [LinuxBIOS] selection of compression algorithm
In-Reply-To: <20060524104533.GA3836@coresystems.de>
References: <4470B968.5040100@gmx.net> <44714A87.1040402@lanl.gov>
	<20060522092725.GB32661@coresystems.de>
	<2ea3fae10605220322x7ac5e2ds40410ac10ad93485@mail.gmail.com>
	<44721118.8010207@gmx.net> <20060522200504.GA27672@coresystems.de>
	<447333D4.4000907@lanl.gov> <44735ED8.9000303@gmx.net>
	<2ea3fae10605231249w427bdfb1u736078b495d9a1e3@mail.gmail.com>
	<20060524104533.GA3836@coresystems.de>
Message-ID: <2ea3fae10605241132l36ea9fd9m424d7aa2c80dab3@mail.gmail.com>

uncompress Code is shared because it is rom. and every CPU has its own
stack on its cache.

YH

On 5/24/06, Stefan Reinauer <stepan at coresystems.de> wrote:
> * yhlu <yinghailu at gmail.com> [060523 21:49]:
> > 2. one is in linuxbios_ram, and it is in ram, it is used to uncompress
> > payload.
> >
> > car stage, before call copy_and_run, the stack is already in ram. but
> > code is still in rom. So at this time we need to balance the lzma
> > benifit on compress linuxbios_ram and it's own code size increase in
>
> We have to be careful here, indeed.
>
> > rom. also need to set one extra buffer in ram for every ap code.
>
> Can't the APs share the code?
>
> --
> 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 yinghailu at gmail.com  Wed May 24 20:47:01 2006
From: yinghailu at gmail.com (yhlu)
Date: Wed, 24 May 2006 11:47:01 -0700
Subject: [LinuxBIOS] selection of compression algorithm
In-Reply-To: <4473A23A.5060002@gmx.net>
References: <4470B968.5040100@gmx.net> <44714A87.1040402@lanl.gov>
	<20060522092725.GB32661@coresystems.de>
	<2ea3fae10605220322x7ac5e2ds40410ac10ad93485@mail.gmail.com>
	<44721118.8010207@gmx.net> <20060522200504.GA27672@coresystems.de>
	<447333D4.4000907@lanl.gov> <44735ED8.9000303@gmx.net>
	<2ea3fae10605231249w427bdfb1u736078b495d9a1e3@mail.gmail.com>
	<4473A23A.5060002@gmx.net>
Message-ID: <2ea3fae10605241147n2673525blc5c344f6e414690c@mail.gmail.com>

OK, then We may let linuxbios_ram.rom and linuxbios_apc.rom and vsm code
stay with nrv2b if there is more overhead with lzma in CAR stage.


YH

On 5/23/06, Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006 at gmx.net> wrote:
> yhlu wrote:
> > We at least need two times
> > 1. one is in car stage, and the code is in rom, and it is used to
> > uncompress linuxbios_ram
> > 2. one is in linuxbios_ram, and it is in ram, it is used to uncompress payload.
> >
> > car stage, before call copy_and_run, the stack is already in ram. but
> > code is still in rom. So at this time we need to balance the lzma
> > benifit on compress linuxbios_ram and it's own code size increase in
> > rom. also need to set one extra buffer in ram for every ap code.
>
> OK, so we have to check which of the two solutions is smaller.
> 1) lzma decompressor + lzma compressed linuxbios_ram
> 2) nrv2b decompressor + nrv2b compressed (linuxbios_ram + lzma decompressor)
>
> I just checked this for all abuild targets. The second variant wins
> for half of the targets. That brings me to a third option:
> 3) nrv2b decompressor + nrv2b compressed lzma decompressor + lzma
>   compressed linuxbios_ram
> nrv2b decompressor needs IIRC 512 bytes, lzma decompressor needs 4096
> bytes, so if nrv2b only compresses the lzma decompressor and we assume
> ~50% savings by compression, option 3 is always 1.5k smaller than option 1
> and option 3 is 1.5k-7.3k smaller (2k for OLPC) than option 2.
>
> How difficult would it be for us to build option 3?
>
> > Hope we can squash car stage code + linuxbios_ram code into 64k again.
>
> Depending on the board, that might be difficult. For OLPC, everything fits
> nicely into 32k. For most Tyan boards, we suffer from the fact that auto.o
> is uncompressed and ~28k alone. That is really horrible. Any reasons for
> that?
>
>
> Regards,
> Carl-Daniel
> --
> http://www.hailfinger.org/
>



From yinghailu at gmail.com  Wed May 24 20:52:08 2006
From: yinghailu at gmail.com (yhlu)
Date: Wed, 24 May 2006 11:52:08 -0700
Subject: [LinuxBIOS] Compressing the OLPC VSM?
In-Reply-To: <20060523232904.GB2942@coresystems.de>
References: <44733455.7010502@gmx.net> <44734160.8070206@lanl.gov>
	<44734BEE.8020000@gmx.net> <20060523232904.GB2942@coresystems.de>
Message-ID: <2ea3fae10605241152v48f9b79bkc824ab04a4192e42@mail.gmail.com>

1. change crt0.s.lb to include another asm (set stack in ram)
and copy_and_run.asm produced by gcc.
2. you may need to use perl to replace some section name in copy_and_run.asm

look at cache_as_ram.inc and cach_as_ram_post.c to set the stack...

YH

On 5/23/06, Stefan Reinauer <stepan at coresystems.de> wrote:
> * Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006 at gmx.net> [060523 19:52]:
> > Ronald G Minnich wrote:
> > > Carl-Daniel Hailfinger wrote:
> > >> Hi,
> > >>
> > >> the VSM Ron mailed yesterday to olpc-devel can be compressed
> > >> very well to under 32 kb.
> > >>
> > >> 65536 vsa_test.64k-0001.bin
> > >> 35587 vsa_test.64k-0001.bin.nrv2b
> > >> 32143 vsa_test.64k-0001.bin.lzma
> > >>
> > >> Is the VSM executed after RAM is there and can we use compression
> > >> for it? 50% savings are really good.
> > >>
> > > yes, this is great. I want to move to the new compression asap.
> >
> > See my other patch to the list which adds the decompression code
> > and infrastructure. I'm preparing another patch which will make
> > use of all that code. The patches I sent until now do not modify
> > any existing code, so they should be safe to apply.
>
> Can you try and see whether we can exchange the assembler nrv2b code
> in crt0.S.lb with something gcc compiled? This would make the whole
> compression thing nicely pluggable..
>
> 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



From c-d.hailfinger.devel.2006 at gmx.net  Thu May 25 01:06:43 2006
From: c-d.hailfinger.devel.2006 at gmx.net (Carl-Daniel Hailfinger)
Date: Thu, 25 May 2006 01:06:43 +0200
Subject: [LinuxBIOS] selection of compression algorithm
In-Reply-To: <2ea3fae10605241132l36ea9fd9m424d7aa2c80dab3@mail.gmail.com>
References: <4470B968.5040100@gmx.net>
	<44714A87.1040402@lanl.gov>	<20060522092725.GB32661@coresystems.de>	<2ea3fae10605220322x7ac5e2ds40410ac10ad93485@mail.gmail.com>	<44721118.8010207@gmx.net>
	<20060522200504.GA27672@coresystems.de>	<447333D4.4000907@lanl.gov>
	<44735ED8.9000303@gmx.net>	<2ea3fae10605231249w427bdfb1u736078b495d9a1e3@mail.gmail.com>	<20060524104533.GA3836@coresystems.de>
	<2ea3fae10605241132l36ea9fd9m424d7aa2c80dab3@mail.gmail.com>
Message-ID: <4474E703.4060900@gmx.net>

yhlu wrote:
> uncompress Code is shared because it is rom. and every CPU has its own
> stack on its cache.

So a decompressor is in ROM, reads from ROM, writes to RAM and has its
stack in cache? Or do we uncompress to cache?

How big is that cache? I can modify lzma to only need 6000 bytes stack
and no additional memory allocations.

Are reads from ROM special (alignment problems etc)? Can I treat stack
like normal RAM?

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



From russ at ashlandhome.net  Thu May 25 06:12:22 2006
From: russ at ashlandhome.net (Russell Whitaker)
Date: Wed, 24 May 2006 21:12:22 -0700 (PDT)
Subject: [LinuxBIOS] gcc version
Message-ID: <Pine.LNX.4.63.0605242055290.3794@bigred.russwhit.org>


The other day there was a comment about a gcc-3.3 bug, so
ran abuild using gcc-3.4.6 on a i686-pc.
Made a diff of the result with the web page's abuild log.
Deleted pairs of successes.
Result is attachment.

Conclusion: 3.4.6 should work ok

    russ
-------------- next part --------------
16c16
< Processing mainboard/agami/aruma (i386: ok)
---
> Processing mainboard/agami/aruma (i386: ok, we're amd64)
19,24c19
<   Compiling image ..FAILED after 3s! Log excerpt:
< /usr/sbin/iasl -tc /home/russ/src/linuxbios/LinuxBIOSv2-2310/src/mainboard/agami/aruma/ssdt_lb_x.dsl
< make[1]: /usr/sbin/iasl: Command not found
< make[1]: *** [ssdt.c] Error 127
< make[1]: Leaving directory `/home/russ/src/linuxbios/LinuxBIOSv2-2310/util/abuild/linuxbios-builds/agami_aruma/normal'
< make: *** [normal/linuxbios.rom] Error 1
---
>   Compiling image ..ok. (took 23s)

41c36
< Processing mainboard/amd/serengeti_leopard (i386: ok)
---
> Processing mainboard/amd/serengeti_leopard (i386: ok, we're amd64)
44,49c39
<   Compiling image ..FAILED after 4s! Log excerpt:
< /usr/sbin/iasl -tc /home/russ/src/linuxbios/LinuxBIOSv2-2310/src/mainboard/amd/serengeti_leopard/ssdt_lb_x.dsl
< make[1]: /usr/sbin/iasl: Command not found
< make[1]: *** [ssdt.c] Error 127
< make[1]: Leaving directory `/home/russ/src/linuxbios/LinuxBIOSv2-2310/util/abuild/linuxbios-builds/amd_serengeti_leopard/normal'
< make: *** [normal/linuxbios.rom] Error 1
---
>   Compiling image ..ok. (took 24s)

61c51
< Processing mainboard/broadcom/blast (i386: ok)
---
> Processing mainboard/broadcom/blast (i386: ok, we're amd64)
64,65c54,55
<   Compiling image ..FAILED after 10s! Log excerpt:
< : undefined reference to `printk_debug'
---
>   Compiling image ..FAILED after 8s! Log excerpt:
> crt0.S:(.rom.text+0x500f): undefined reference to `printk_debug'

96c86,89
< Processing mainboard/embeddedplanet/ep405pc (ppc: skipped, we're i386)
---
> Processing mainboard/embeddedplanet/ep405pc (ppc: ok, we're amd64)
>   Creating config file... ok
>   Creating builddir...ok
>   Compiling image ..ok. (took 5s)

130c123,126
< Processing mainboard/motorola/sandpointx3_altimus_mpc7410 (ppc: skipped, we're i386)
---
> Processing mainboard/motorola/sandpointx3_altimus_mpc7410 (ppc: ok, we're amd64)
>   Creating config file... ok
>   Creating builddir...ok
>   Compiling image ..ok. (took 5s)

167,168c163,164
< Processing mainboard/technologic/ts5300 (i386: ok)
< Used existing test target /home/russ/src/linuxbios/LinuxBIOSv2-2310/targets/technologic/ts5300/Config-abuild.lb
---
> Processing mainboard/technologic/ts5300 (i386: ok, we're amd64)
> Used existing test target /srv/svn/linuxbios-extra/tmp/LinuxBIOSv2-2310/targets/technologic/ts5300/Config-abuild.lb
170,171c166,167
<   Compiling image ..FAILED after 15s! Log excerpt:
< : undefined reference to `stream_fini'
---
>   Compiling image ..FAILED after 13s! Log excerpt:
> (.text+0x3c38): undefined reference to `stream_fini'

174c170
< make[1]: Leaving directory `/home/russ/src/linuxbios/LinuxBIOSv2-2310/util/abuild/linuxbios-builds/technologic_ts5300/fallback'
---
> make[1]: Leaving directory `/srv/svn/linuxbios-extra/tmp/LinuxBIOSv2-2310/util/abuild/linuxbios-builds/technologic_ts5300/fallback'
177c173,176
< Processing mainboard/totalimpact/briq (ppc: skipped, we're i386)
---
> Processing mainboard/totalimpact/briq (ppc: ok, we're amd64)
>   Creating config file... ok
>   Creating builddir...ok
>   Compiling image ..ok. (took 4s)

179c178
< Processing mainboard/tyan/s2735 (i386: ok)
---
> Processing mainboard/tyan/s2735 (i386: ok, we're amd64)
182,183c181,182
<   Compiling image ..FAILED after 8s! Log excerpt:
< : undefined reference to `printk_debug'
---
>   Compiling image ..FAILED after 7s! Log excerpt:
> crt0.S:(.rom.text+0x1e7f): undefined reference to `printk_debug'

219c218
< Processing mainboard/tyan/s2891 (i386: ok)
---
> Processing mainboard/tyan/s2891 (i386: ok, we're amd64)
223,224c222,223
< /home/russ/src/linuxbios/LinuxBIOSv2-2310/src/mainboard/tyan/s2891/irq_tables.c:98: error: (Each undeclared identifier is reported only once
< /home/russ/src/linuxbios/LinuxBIOSv2-2310/src/mainboard/tyan/s2891/irq_tables.c:98: error: for each function it appears in.)
---
> /srv/svn/linuxbios-extra/tmp/LinuxBIOSv2-2310/src/mainboard/tyan/s2891/irq_tables.c:98: error: (Each undeclared identifier is reported only once
> /srv/svn/linuxbios-extra/tmp/LinuxBIOSv2-2310/src/mainboard/tyan/s2891/irq_tables.c:98: error: for each function it appears in.)
226c225
< make[1]: Leaving directory `/home/russ/src/linuxbios/LinuxBIOSv2-2310/util/abuild/linuxbios-builds/tyan_s2891/normal'
---
> make[1]: Leaving directory `/srv/svn/linuxbios-extra/tmp/LinuxBIOSv2-2310/util/abuild/linuxbios-builds/tyan_s2891/normal'

229c228
< Processing mainboard/tyan/s2892 (i386: ok)
---
> Processing mainboard/tyan/s2892 (i386: ok, we're amd64)
233,234c232,233
< /home/russ/src/linuxbios/LinuxBIOSv2-2310/src/cpu/amd/model_fxx/init_cpus.c:151: warning: 'wait_all_aps_started' defined but not used
< /home/russ/src/linuxbios/LinuxBIOSv2-2310/src/cpu/amd/model_fxx/init_cpus.c:161: warning: 'allow_all_aps_stop' defined but not used
---
> /srv/svn/linuxbios-extra/tmp/LinuxBIOSv2-2310/src/mainboard/tyan/s2892/cache_as_ram_auto.c:214: error: (Each undeclared identifier is reported only once
> /srv/svn/linuxbios-extra/tmp/LinuxBIOSv2-2310/src/mainboard/tyan/s2892/cache_as_ram_auto.c:214: error: for each function it appears in.)
236c235
< make[1]: Leaving directory `/home/russ/src/linuxbios/LinuxBIOSv2-2310/util/abuild/linuxbios-builds/tyan_s2892/normal'
---
> make[1]: Leaving directory `/srv/svn/linuxbios-extra/tmp/LinuxBIOSv2-2310/util/abuild/linuxbios-builds/tyan_s2892/normal'

239c238
< Processing mainboard/tyan/s2895 (i386: ok)
---
> Processing mainboard/tyan/s2895 (i386: ok, we're amd64)
242,243c241,242
<   Compiling image ..FAILED after 15s! Log excerpt:
< : undefined reference to `printk_debug'
---
>   Compiling image ..FAILED after 11s! Log excerpt:
> crt0.S:(.rom.text+0x350b): undefined reference to `printk_debug'
246c245
< make[1]: Leaving directory `/home/russ/src/linuxbios/LinuxBIOSv2-2310/util/abuild/linuxbios-builds/tyan_s2895/normal'
---
> make[1]: Leaving directory `/srv/svn/linuxbios-extra/tmp/LinuxBIOSv2-2310/util/abuild/linuxbios-builds/tyan_s2895/normal'

From yinghailu at gmail.com  Thu May 25 06:51:37 2006
From: yinghailu at gmail.com (yhlu)
Date: Wed, 24 May 2006 21:51:37 -0700
Subject: [LinuxBIOS] selection of compression algorithm
In-Reply-To: <4474E703.4060900@gmx.net>
References: <4470B968.5040100@gmx.net>
	<2ea3fae10605220322x7ac5e2ds40410ac10ad93485@mail.gmail.com>
	<44721118.8010207@gmx.net> <20060522200504.GA27672@coresystems.de>
	<447333D4.4000907@lanl.gov> <44735ED8.9000303@gmx.net>
	<2ea3fae10605231249w427bdfb1u736078b495d9a1e3@mail.gmail.com>
	<20060524104533.GA3836@coresystems.de>
	<2ea3fae10605241132l36ea9fd9m424d7aa2c80dab3@mail.gmail.com>
	<4474E703.4060900@gmx.net>
Message-ID: <2ea3fae10605242151l194ad103t963ddf96e889f995@mail.gmail.com>

just let the the uncompress take more parameter for the properties
buf, and every cpu find the correct buffer in RAM in BSP should be
OK...because the RAM on first node is ready at that time.

YH



On 5/24/06, Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006 at gmx.net> wrote:
> yhlu wrote:
> > uncompress Code is shared because it is rom. and every CPU has its own
> > stack on its cache.
>
> So a decompressor is in ROM, reads from ROM, writes to RAM and has its
> stack in cache? Or do we uncompress to cache?
>
> How big is that cache? I can modify lzma to only need 6000 bytes stack
> and no additional memory allocations.
>
> Are reads from ROM special (alignment problems etc)? Can I treat stack
> like normal RAM?
>
> Regards,
> Carl-Daniel
> --
> http://www.hailfinger.org/
>



From myneil at gmail.com  Thu May 25 14:14:56 2006
From: myneil at gmail.com (Neil)
Date: Thu, 25 May 2006 20:14:56 +0800
Subject: [LinuxBIOS] linux bios hang when jump in kernel
In-Reply-To: <20060524095155.GC495@coresystems.de>
References: <5c5dcf370605220053r3a58b786j143d902a35951ff3@mail.gmail.com>
	<44733263.8020902@lanl.gov> <20060523223530.GC3701@coresystems.de>
	<5c5dcf370605231848w53747eadi942a1cdecddef565@mail.gmail.com>
	<20060524095155.GC495@coresystems.de>
Message-ID: <5c5dcf370605250514m2a136d00va17d3ed73f4da73c@mail.gmail.com>

>
>

Dear Stefan:
        Thank you very much.but our Irq table tructure is quite different
from the arima/hdama.
I had modified my irq_table.c like this :

write_pirq_info(pirq_info, bus_bcm5785_0, (sbdn<<3)|0, 0x1, 0xdef8,
0x2,0xdef8, 0x3, 0xdef8, 0x4, 0xdef8, 0, 0);
pirq_info++ ;slot_num++;
/*let linux know the bus 1*/
write_pirq_info(0,1,(0x04<<3)|3, 0x1 ,0, 0x2,0, 0x3,0, 0x4, 0,0,0);

but it seems not function.

Neil(bxshi)




>
> >    I have not add ACPI function .If I need an entry for bus 1 means that
> :
> > write_pirq_info(pirq_info, bus_bcm5785_0, (sbdn<<3)|0, 0x1, 0xdef8, 0x2,
> > 0xdef8, 0x3, 0xdef8, 0x4, 0xdef8, 0, 0);
>
>
> arima/hdama/irq_tables.c:
>
>                /* Let Linux know about bus 1 */
>                IRQ_SLOT(0, 1,4,3, 0,0,0,0 ),
>
> (1.4.3 is the irq router iirc)
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20060525/91f2270f/attachment.html>

From stepan at coresystems.de  Thu May 25 14:24:04 2006
From: stepan at coresystems.de (Stefan Reinauer)
Date: Thu, 25 May 2006 14:24:04 +0200
Subject: [LinuxBIOS] linux bios hang when jump in kernel
In-Reply-To: <5c5dcf370605250514m2a136d00va17d3ed73f4da73c@mail.gmail.com>
References: <5c5dcf370605220053r3a58b786j143d902a35951ff3@mail.gmail.com>
	<44733263.8020902@lanl.gov> <20060523223530.GC3701@coresystems.de>
	<5c5dcf370605231848w53747eadi942a1cdecddef565@mail.gmail.com>
	<20060524095155.GC495@coresystems.de>
	<5c5dcf370605250514m2a136d00va17d3ed73f4da73c@mail.gmail.com>
Message-ID: <20060525122404.GA9917@coresystems.de>

* Neil <myneil at gmail.com> [060525 14:14]:
>      
> 
> Dear Stefan:
>         Thank you very much.but our Irq table tructure is quite different from
> the arima/hdama.

What do you mean by "irq table structure"?

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 c-d.hailfinger.devel.2006 at gmx.net  Thu May 25 22:11:08 2006
From: c-d.hailfinger.devel.2006 at gmx.net (Carl-Daniel Hailfinger)
Date: Thu, 25 May 2006 22:11:08 +0200
Subject: [LinuxBIOS] [OLPC-devel] Linux "bootloader" image - build
	instructions?
In-Reply-To: <0E81348C5627674A9C0061413EBFF5F7942A71@SAUSEXMB2.amd.com>
References: <0E81348C5627674A9C0061413EBFF5F7942A71@SAUSEXMB2.amd.com>
Message-ID: <44760F5C.1070104@gmx.net>

Hi Steven,

Goodrich,Steven wrote:
> In order to get an image I can build/test with:
> Where can I find instructions and a component list for the "bootloader"
> Linux image (in the ROM)?

this question is best asked on the LinuxBIOS list. I think Ron Minnich
has the most current ROM image for OLPC.

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



From c-d.hailfinger.devel.2006 at gmx.net  Thu May 25 23:05:42 2006
From: c-d.hailfinger.devel.2006 at gmx.net (Carl-Daniel Hailfinger)
Date: Thu, 25 May 2006 23:05:42 +0200
Subject: [LinuxBIOS] selection of compression algorithm
In-Reply-To: <2ea3fae10605242151l194ad103t963ddf96e889f995@mail.gmail.com>
References: <4470B968.5040100@gmx.net>	<2ea3fae10605220322x7ac5e2ds40410ac10ad93485@mail.gmail.com>	<44721118.8010207@gmx.net>
	<20060522200504.GA27672@coresystems.de>	<447333D4.4000907@lanl.gov>
	<44735ED8.9000303@gmx.net>	<2ea3fae10605231249w427bdfb1u736078b495d9a1e3@mail.gmail.com>	<20060524104533.GA3836@coresystems.de>	<2ea3fae10605241132l36ea9fd9m424d7aa2c80dab3@mail.gmail.com>	<4474E703.4060900@gmx.net>
	<2ea3fae10605242151l194ad103t963ddf96e889f995@mail.gmail.com>
Message-ID: <44761C26.1000406@gmx.net>

yhlu wrote:
> just let the the uncompress take more parameter for the properties
> buf, and every cpu find the correct buffer in RAM in BSP should be
> OK...because the RAM on first node is ready at that time.

How about

int uncompress_generic(void *src, void *dst, void *buf, int bufsize);

and uncompress_generic can assume that buf can be treated like RAM.
If bufsize is too small, it can return an error. An additional function

int needed_bufsize(void *src);

could be written to compute the minimum buffer size for a given
compressed image.

What do you think?


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



From rminnich at lanl.gov  Thu May 25 23:16:17 2006
From: rminnich at lanl.gov (Ronald G Minnich)
Date: Thu, 25 May 2006 15:16:17 -0600
Subject: [LinuxBIOS] selection of compression algorithm
In-Reply-To: <44761C26.1000406@gmx.net>
References: <4470B968.5040100@gmx.net>	<2ea3fae10605220322x7ac5e2ds40410ac10ad93485@mail.gmail.com>	<44721118.8010207@gmx.net>	<20060522200504.GA27672@coresystems.de>	<447333D4.4000907@lanl.gov>	<44735ED8.9000303@gmx.net>	<2ea3fae10605231249w427bdfb1u736078b495d9a1e3@mail.gmail.com>	<20060524104533.GA3836@coresystems.de>	<2ea3fae10605241132l36ea9fd9m424d7aa2c80dab3@mail.gmail.com>	<4474E703.4060900@gmx.net>	<2ea3fae10605242151l194ad103t963ddf96e889f995@mail.gmail.com>
	<44761C26.1000406@gmx.net>
Message-ID: <44761EA1.3090808@lanl.gov>

Carl-Daniel Hailfinger wrote:
> yhlu wrote:
> 
>>just let the the uncompress take more parameter for the properties
>>buf, and every cpu find the correct buffer in RAM in BSP should be
>>OK...because the RAM on first node is ready at that time.
> 
> 
> How about
> 
> int uncompress_generic(void *src, void *dst, void *buf, int bufsize);
> 
> and uncompress_generic can assume that buf can be treated like RAM.
> If bufsize is too small, it can return an error. An additional function
> 
> int needed_bufsize(void *src);
> 
> could be written to compute the minimum buffer size for a given
> compressed image.
> 
> What do you think?
> 
> 
> Regards,
> Carl-Danie



int needed_bufsize(void *src);

good. And in most cases it is:
size = *(unsigned long *)src;

int uncompress_generic(void *src, void *dst, void *buf)

if the programmer is too stupid to call needed_bufsize, they're probably 
too stupid to pass in a correct bufsize to this function, I think it is 
not needed.


ron



From myles at pel.cs.byu.edu  Thu May 25 23:38:39 2006
From: myles at pel.cs.byu.edu (Myles Watson)
Date: Thu, 25 May 2006 15:38:39 -0600
Subject: [LinuxBIOS] Etherboot (FILO) with SATA on tyan s2895
In-Reply-To: <01M2K5YMDCS88Y7MSM@EMAIL1.BYU.EDU>
Message-ID: <01M2UEFPEYP28YAERM@EMAIL1.BYU.EDU>

I decided to just add an IDE drive to boot the first kernel.  Until I had
LinuxBIOS booting, I felt like the 512KB that the BIOS Savior gave me was
too little to play with for adding tiny Linux. After I can reliably boot
from the 512KB "backup" I'll think about writing over my original 1 MB :)

When I boot from LinuxBIOS to the IDE drive it doesn't recognize my SATA
drives, even though sata_nv gets loaded. They get mounted normally when I
boot from the same drive with the factory BIOS.  Any ideas or hints?

Thanks,
Myles

-----Original Message-----
From: linuxbios-bounces at linuxbios.org
[mailto:linuxbios-bounces at linuxbios.org] On Behalf Of Myles Watson
Sent: Thursday, May 18, 2006 7:49 AM
To: 'Lu, Yinghai'; linuxbios at linuxbios.org
Subject: Re: [LinuxBIOS] Etherboot (FILO) with SATA on tyan s2895

It's starting to seem like a long chain of events from LinuxBIOS to
Etherboot to FILO to kernel on CF to myKernel.  I'd also like to be able to
get to grub eventually.  Is there a way to go from LinuxBIOS to grub more
directly on the s2895?

Thanks again for your help.

Myles

-----Original Message-----
From: Lu, Yinghai [mailto:yinghai.lu at amd.com] 
Sent: Wednesday, May 17, 2006 5:09 PM
To: myles at mouselemur.cs.byu.edu; linuxbios at linuxbios.org
Subject: RE: [LinuxBIOS] Etherboot (FILO) with SATA on tyan s2895

You can not boot from CK804 sata directly with FILO in Etherboot.

The code only support Sata that can work on compatible IDE mode. 

You need to use other media ( network, CF IDE flash) to load kernel with
ck804 sata and kexec support, and use kexec to load final kernel in your
sata disk.

YH

-----Original Message-----
From: linuxbios-bounces at linuxbios.org
[mailto:linuxbios-bounces at linuxbios.org] On Behalf Of Myles Watson
Sent: Wednesday, May 17, 2006 3:57 PM
To: linuxbios at linuxbios.org
Subject: [LinuxBIOS] Etherboot (FILO) with SATA on tyan s2895

I am booting linuxbios with etherboot and filo as the payload. I tried
to
follow the s2881 tutorial on the wiki.

Etherboot only finds my cd-rom. When I try to use hde:/ it tells me that
"Drive 4 does not exist". All drives up to j except hda (my cd-rom) give
the
same error message. Sometimes if I try hdg it hangs.

I saw README.filo_in_etherboot where it says it only works on SATA port
1 or
2. I've tried on SATA 0 port 0 and 1, SATA 1 port 2 and 3.

I also seem to need to boot the factory BIOS in between each attempt, or
I
won't get very far.

Is there something simple I've missed?

Thanks,
Myles

Output:

Etherboot 5.4.2
Drivers: TG3 FILO Images: NBI ELF
Protocols: DHCP TFTP
Relocating text ...
Scanning PCI: found 30 devices
Probing pci disk...
[FILO]FILO version 0.4.1
boot: hde3:/boot/vmlinuz... initrd=/boot/initrd...
IDE time out
No drive detected on IDE channel 2
boot: hdc:/ 
No drive detected on IDE channel 1



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



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





From fourstar10_2000 at yahoo.com  Fri May 26 00:08:42 2006
From: fourstar10_2000 at yahoo.com (steve yannalfo)
Date: Thu, 25 May 2006 15:08:42 -0700 (PDT)
Subject: [LinuxBIOS] PCI: 00:00.0 cmd <-146
Message-ID: <20060525220842.50942.qmail@web38913.mail.mud.yahoo.com>

PCI: 00:00.0 subsytem <- 00/00
 PCI: 00:00.0 cmd <-146
 
 This is the last message i see booting LB.
 
 Everything looks OK to this point. (devices are correct BUS:Device.func)
 
 My board is similar to tyan/s2891
 
 amdk8 LTD 0 -> CK804 -> W83627thf
  
 I have tried "getpir" to create a new irq_tables.c but it Segmentation faults after Validating.
 I don't know if my resourcemap.c & mptable.c is correct or where to get the proper info
 for them. I just copied the files from tyan/s2891.
 
 Does anyone have any suggestions?
 
 thank you.
 
 
 
 
 
 
 
__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20060525/f538d8ea/attachment.html>

From c-d.hailfinger.devel.2006 at gmx.net  Fri May 26 01:02:21 2006
From: c-d.hailfinger.devel.2006 at gmx.net (Carl-Daniel Hailfinger)
Date: Fri, 26 May 2006 01:02:21 +0200
Subject: [LinuxBIOS] Coding style
Message-ID: <4476377D.8010908@gmx.net>

What coding style is preferred if I want to merge the lzma
code into LinuxBIOS?

* plain code, as found in upstream sources (a mess)
* all unneeded #ifdef sections removed
* additionally proper indentation (tab=8)
* additionally replaced obfuscated #defines
* additionally Lindented to Linux kernel style

Also, what types should I use for variables?
* u8, u16, u32
* UInt8, UInt16, UInt32
* u_int8_t ...
* u_int8 ...
* uint8 ...
* uint8_t ...
* unsigned char, unsigned short, unsigned int


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



From rminnich at lanl.gov  Fri May 26 01:50:12 2006
From: rminnich at lanl.gov (Ronald G Minnich)
Date: Thu, 25 May 2006 17:50:12 -0600
Subject: [LinuxBIOS] Coding style
In-Reply-To: <4476377D.8010908@gmx.net>
References: <4476377D.8010908@gmx.net>
Message-ID: <447642B4.3000004@lanl.gov>

Carl-Daniel Hailfinger wrote:
> What coding style is preferred if I want to merge the lzma
> code into LinuxBIOS?
> 
> * plain code, as found in upstream sources (a mess)
> * all unneeded #ifdef sections removed
> * additionally proper indentation (tab=8)
> * additionally replaced obfuscated #defines
> * additionally Lindented to Linux kernel style

linux-c-mode, so yeah, lindent.

> 
> Also, what types should I use for variables?
> * u8, u16, u32
> * UInt8, UInt16, UInt32
> * u_int8_t ...
> * u_int8 ...
> * uint8 ...
> * uint8_t ...
> * unsigned char, unsigned short, unsigned int

that's a mess in linuxbios right now. Stefan, you have a preference?

ron



From yinghailu at gmail.com  Fri May 26 05:07:40 2006
From: yinghailu at gmail.com (yhlu)
Date: Thu, 25 May 2006 20:07:40 -0700
Subject: [LinuxBIOS] selection of compression algorithm
In-Reply-To: <44761EA1.3090808@lanl.gov>
References: <4470B968.5040100@gmx.net> <447333D4.4000907@lanl.gov>
	<44735ED8.9000303@gmx.net>
	<2ea3fae10605231249w427bdfb1u736078b495d9a1e3@mail.gmail.com>
	<20060524104533.GA3836@coresystems.de>
	<2ea3fae10605241132l36ea9fd9m424d7aa2c80dab3@mail.gmail.com>
	<4474E703.4060900@gmx.net>
	<2ea3fae10605242151l194ad103t963ddf96e889f995@mail.gmail.com>
	<44761C26.1000406@gmx.net> <44761EA1.3090808@lanl.gov>
Message-ID: <2ea3fae10605252007q37bc696dm4278b4da2c2156fa@mail.gmail.com>

int uncompress_generic(void *src, void *dst, void *buf)

==>

int uncompress_generic(void *src, void *dst, uint32_t *ilen, void *op_buf)

YH

On 5/25/06, Ronald G Minnich <rminnich at lanl.gov> wrote:
> Carl-Daniel Hailfinger wrote:
> > yhlu wrote:
> >
> >>just let the the uncompress take more parameter for the properties
> >>buf, and every cpu find the correct buffer in RAM in BSP should be
> >>OK...because the RAM on first node is ready at that time.
> >
> >
> > How about
> >
> > int uncompress_generic(void *src, void *dst, void *buf, int bufsize);
> >
> > and uncompress_generic can assume that buf can be treated like RAM.
> > If bufsize is too small, it can return an error. An additional function
> >
> > int needed_bufsize(void *src);
> >
> > could be written to compute the minimum buffer size for a given
> > compressed image.
> >
> > What do you think?
> >
> >
> > Regards,
> > Carl-Danie
>
>
>
> int needed_bufsize(void *src);
>
> good. And in most cases it is:
> size = *(unsigned long *)src;
>
> int uncompress_generic(void *src, void *dst, void *buf)
>
> if the programmer is too stupid to call needed_bufsize, they're probably
> too stupid to pass in a correct bufsize to this function, I think it is
> not needed.
>
>
> ron
>



From yinghailu at gmail.com  Fri May 26 05:11:17 2006
From: yinghailu at gmail.com (yhlu)
Date: Thu, 25 May 2006 20:11:17 -0700
Subject: [LinuxBIOS] Etherboot (FILO) with SATA on tyan s2895
In-Reply-To: <01M2UEFPEYP28YAERM@EMAIL1.BYU.EDU>
References: <01M2K5YMDCS88Y7MSM@EMAIL1.BYU.EDU>
	<01M2UEFPEYP28YAERM@EMAIL1.BYU.EDU>
Message-ID: <2ea3fae10605252011m6129a946q93cdbd65bbdc1ab7@mail.gmail.com>

It seems some old version sata disk has problem. Can you try some new sata disk?

YH

On 5/25/06, Myles Watson <myles at pel.cs.byu.edu> wrote:
> I decided to just add an IDE drive to boot the first kernel.  Until I had
> LinuxBIOS booting, I felt like the 512KB that the BIOS Savior gave me was
> too little to play with for adding tiny Linux. After I can reliably boot
> from the 512KB "backup" I'll think about writing over my original 1 MB :)
>
> When I boot from LinuxBIOS to the IDE drive it doesn't recognize my SATA
> drives, even though sata_nv gets loaded. They get mounted normally when I
> boot from the same drive with the factory BIOS.  Any ideas or hints?
>
> Thanks,
> Myles
>
> -----Original Message-----
> From: linuxbios-bounces at linuxbios.org
> [mailto:linuxbios-bounces at linuxbios.org] On Behalf Of Myles Watson
> Sent: Thursday, May 18, 2006 7:49 AM
> To: 'Lu, Yinghai'; linuxbios at linuxbios.org
> Subject: Re: [LinuxBIOS] Etherboot (FILO) with SATA on tyan s2895
>
> It's starting to seem like a long chain of events from LinuxBIOS to
> Etherboot to FILO to kernel on CF to myKernel.  I'd also like to be able to
> get to grub eventually.  Is there a way to go from LinuxBIOS to grub more
> directly on the s2895?
>
> Thanks again for your help.
>
> Myles
>
> -----Original Message-----
> From: Lu, Yinghai [mailto:yinghai.lu at amd.com]
> Sent: Wednesday, May 17, 2006 5:09 PM
> To: myles at mouselemur.cs.byu.edu; linuxbios at linuxbios.org
> Subject: RE: [LinuxBIOS] Etherboot (FILO) with SATA on tyan s2895
>
> You can not boot from CK804 sata directly with FILO in Etherboot.
>
> The code only support Sata that can work on compatible IDE mode.
>
> You need to use other media ( network, CF IDE flash) to load kernel with
> ck804 sata and kexec support, and use kexec to load final kernel in your
> sata disk.
>
> YH
>
> -----Original Message-----
> From: linuxbios-bounces at linuxbios.org
> [mailto:linuxbios-bounces at linuxbios.org] On Behalf Of Myles Watson
> Sent: Wednesday, May 17, 2006 3:57 PM
> To: linuxbios at linuxbios.org
> Subject: [LinuxBIOS] Etherboot (FILO) with SATA on tyan s2895
>
> I am booting linuxbios with etherboot and filo as the payload. I tried
> to
> follow the s2881 tutorial on the wiki.
>
> Etherboot only finds my cd-rom. When I try to use hde:/ it tells me that
> "Drive 4 does not exist". All drives up to j except hda (my cd-rom) give
> the
> same error message. Sometimes if I try hdg it hangs.
>
> I saw README.filo_in_etherboot where it says it only works on SATA port
> 1 or
> 2. I've tried on SATA 0 port 0 and 1, SATA 1 port 2 and 3.
>
> I also seem to need to boot the factory BIOS in between each attempt, or
> I
> won't get very far.
>
> Is there something simple I've missed?
>
> Thanks,
> Myles
>
> Output:
>
> Etherboot 5.4.2
> Drivers: TG3 FILO Images: NBI ELF
> Protocols: DHCP TFTP
> Relocating text ...
> Scanning PCI: found 30 devices
> Probing pci disk...
> [FILO]FILO version 0.4.1
> boot: hde3:/boot/vmlinuz... initrd=/boot/initrd...
> IDE time out
> No drive detected on IDE channel 2
> boot: hdc:/
> No drive detected on IDE channel 1
>
>
>
> --
> linuxbios mailing list
> linuxbios at linuxbios.org
> http://www.openbios.org/mailman/listinfo/linuxbios
>
>
>
> --
> linuxbios mailing list
> linuxbios at linuxbios.org
> http://www.openbios.org/mailman/listinfo/linuxbios
>
>
>
> --
> linuxbios mailing list
> linuxbios at linuxbios.org
> http://www.openbios.org/mailman/listinfo/linuxbios
>



From yinghailu at gmail.com  Fri May 26 05:13:18 2006
From: yinghailu at gmail.com (yhlu)
Date: Thu, 25 May 2006 20:13:18 -0700
Subject: [LinuxBIOS] Coding style
In-Reply-To: <447642B4.3000004@lanl.gov>
References: <4476377D.8010908@gmx.net> <447642B4.3000004@lanl.gov>
Message-ID: <2ea3fae10605252013o7f17f186r27fa7c6dacc549f4@mail.gmail.com>

uint8_t, uint16_t, uint32_t, uint64_t

YH

On 5/25/06, Ronald G Minnich <rminnich at lanl.gov> wrote:
> Carl-Daniel Hailfinger wrote:
> > What coding style is preferred if I want to merge the lzma
> > code into LinuxBIOS?
> >
> > * plain code, as found in upstream sources (a mess)
> > * all unneeded #ifdef sections removed
> > * additionally proper indentation (tab=8)
> > * additionally replaced obfuscated #defines
> > * additionally Lindented to Linux kernel style
>
> linux-c-mode, so yeah, lindent.
>
> >
> > Also, what types should I use for variables?
> > * u8, u16, u32
> > * UInt8, UInt16, UInt32
> > * u_int8_t ...
> > * u_int8 ...
> > * uint8 ...
> > * uint8_t ...
> > * unsigned char, unsigned short, unsigned int
>
> that's a mess in linuxbios right now. Stefan, you have a preference?
>
> ron
>
> --
> linuxbios mailing list
> linuxbios at linuxbios.org
> http://www.openbios.org/mailman/listinfo/linuxbios
>



From stepan at coresystems.de  Fri May 26 18:21:56 2006
From: stepan at coresystems.de (Stefan Reinauer)
Date: Fri, 26 May 2006 18:21:56 +0200
Subject: [LinuxBIOS] Coding style
In-Reply-To: <447642B4.3000004@lanl.gov>
References: <4476377D.8010908@gmx.net> <447642B4.3000004@lanl.gov>
Message-ID: <20060526162156.GA819@coresystems.de>

* Ronald G Minnich <rminnich at lanl.gov> [060526 01:50]:
> Carl-Daniel Hailfinger wrote:
> > What coding style is preferred if I want to merge the lzma
> > code into LinuxBIOS?
> > 
> > * plain code, as found in upstream sources (a mess)

Please don't. Except it is a part that must be updated frequently.
(x86emu would have been such an example)

> > * all unneeded #ifdef sections removed

definitely. This is becoming an issue. We have some code paths that are
not fundamentally different but still cause the code to be hard to read.
CONFIG_USE_INIT for example.

> > * additionally proper indentation (tab=8)

Yes, too deep code should hurt the eye and make the reader factor it.

> > * additionally Lindented to Linux kernel style
> 
> linux-c-mode, so yeah, lindent.

basically indent -kr -i8

> > Also, what types should I use for variables?
> > * uint8_t ...

> that's a mess in linuxbios right now. Stefan, you have a preference?

* uint8_t ... for types. The exception from the rule is romcc code which
  is said to be worse if you use types other than "unsigned" and
  "signed" (which should be fixed in the compiler, not in the code)



-- 
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 myles at pel.cs.byu.edu  Fri May 26 22:07:33 2006
From: myles at pel.cs.byu.edu (Myles Watson)
Date: Fri, 26 May 2006 14:07:33 -0600
Subject: [LinuxBIOS] Etherboot (FILO) with SATA on tyan s2895
Message-ID: <01M2VPJ5UKCK8YB56R@EMAIL1.BYU.EDU>

I didn't have another sata disk, but I looked again and noticed that the
network didn't work either.  Here is the first suspicious snippet of
/var/log/messages:

May 26 13:36:20 orangutan kernel: ACPI: Unable to locate RSDP
May 26 13:36:20 orangutan kernel: Scanning NUMA topology in Northbridge 24
May 26 13:36:20 orangutan kernel: Number of nodes 2
May 26 13:36:20 orangutan kernel: Node 0 MemBase 0000000000000000 Limit
0000000080000000
May 26 13:36:20 orangutan kernel: Node 1 MemBase 0000000080000000 Limit
0000000140000000
May 26 13:36:20 orangutan kernel: Using node hash shift of 31
May 26 13:36:20 orangutan kernel: Bootmem setup node 0
0000000000000000-0000000080000000
May 26 13:36:20 orangutan kernel: Bootmem setup node 1
0000000080000000-0000000140000000

Then part that talks about SATA:

May 26 13:36:27 orangutan kernel: SCSI subsystem initialized
May 26 13:36:27 orangutan kernel: ata1: SATA max UDMA/133 cmd 0x2850 ctl
0x28A2 bmdma 0x2830 irq 23
May 26 13:36:27 orangutan kernel: ata2: SATA max UDMA/133 cmd 0x2860 ctl
0x28B2 bmdma 0x2838 irq 23
May 26 13:36:27 orangutan kernel: input: ImPS/2 Generic Wheel Mouse as
/class/input/input1
May 26 13:36:27 orangutan kernel: ata1: SATA link down (SStatus 0)
May 26 13:36:27 orangutan kernel: scsi0 : sata_nv
May 26 13:36:27 orangutan kernel: ata2: SATA link down (SStatus 0)
May 26 13:36:27 orangutan kernel: scsi1 : sata_nv
May 26 13:36:27 orangutan kernel: ata3: SATA max UDMA/133 cmd 0x2870 ctl
0x28C2 bmdma 0x2840 irq 22
May 26 13:36:27 orangutan kernel: ata4: SATA max UDMA/133 cmd 0x2880 ctl
0x28D2 bmdma 0x2848 irq 22
May 26 13:36:27 orangutan kernel: ata3: SATA link down (SStatus 0)
May 26 13:36:27 orangutan kernel: scsi2 : sata_nv
May 26 13:36:27 orangutan kernel: ata4: SATA link down (SStatus 0)
May 26 13:36:27 orangutan kernel: scsi3 : sata_nv

And another with the network:

May 26 13:36:28 orangutan kernel: forcedeth.c: Reverse Engineered nForce
ethernet driver. Version 0.49.
May 26 13:36:28 orangutan kernel: PCI: Error while updating region
0000:00:0a.0/0 (f5205000 != 00000000)
May 26 13:36:28 orangutan kernel: PCI: Enabling device 0000:00:0a.0 (0000 ->
0003)
May 26 13:36:28 orangutan kernel: 0000:00:0a.0: Invalid Mac address
detected: ff:ff:ff:ff:ff:ff
May 26 13:36:28 orangutan kernel: Please complain to your hardware vendor.
Switching to a random MAC.
May 26 13:36:28 orangutan kernel: 0000:00:0a.0: open: Could not find a valid
PHY.
May 26 13:36:28 orangutan kernel: forcedeth: probe of 0000:00:0a.0 failed
with error -12
May 26 13:36:28 orangutan kernel: eth0: forcedeth.c: subsystem: 010f1:2895
bound to 0000:80:0a.0
May 26 13:36:28 orangutan kernel: nvnet: module license 'NVIDIA' taints
kernel.
May 26 13:36:28 orangutan kernel: ERROR: nvenet_probe, unable to create
adapter object
May 26 13:36:28 orangutan kernel: nvnet: probe of 0000:00:0a.0 failed with
error -12

Is there somewhere that the ACPI information should be getting passed
through, and it's getting clobbered? I'm booting LinuxBIOS -> FILO/Etherboot
-> Kernel on an IDE disk.

Thanks,
Myles




-----Original Message-----
From: linuxbios-bounces at linuxbios.org
[mailto:linuxbios-bounces at linuxbios.org] On Behalf Of yhlu
Sent: Thursday, May 25, 2006 9:11 PM
To: myles at mouselemur.cs.byu.edu
Cc: linuxbios at linuxbios.org
Subject: Re: [LinuxBIOS] Etherboot (FILO) with SATA on tyan s2895

It seems some old version sata disk has problem. Can you try some new sata
disk?

YH

On 5/25/06, Myles Watson <myles at pel.cs.byu.edu> wrote:
> I decided to just add an IDE drive to boot the first kernel.  Until I had
> LinuxBIOS booting, I felt like the 512KB that the BIOS Savior gave me was
> too little to play with for adding tiny Linux. After I can reliably boot
> from the 512KB "backup" I'll think about writing over my original 1 MB :)
>
> When I boot from LinuxBIOS to the IDE drive it doesn't recognize my SATA
> drives, even though sata_nv gets loaded. They get mounted normally when I
> boot from the same drive with the factory BIOS.  Any ideas or hints?
>
> Thanks,
> Myles
>
> -----Original Message-----
> From: linuxbios-bounces at linuxbios.org
> [mailto:linuxbios-bounces at linuxbios.org] On Behalf Of Myles Watson
> Sent: Thursday, May 18, 2006 7:49 AM
> To: 'Lu, Yinghai'; linuxbios at linuxbios.org
> Subject: Re: [LinuxBIOS] Etherboot (FILO) with SATA on tyan s2895
>
> It's starting to seem like a long chain of events from LinuxBIOS to
> Etherboot to FILO to kernel on CF to myKernel.  I'd also like to be able
to
> get to grub eventually.  Is there a way to go from LinuxBIOS to grub more
> directly on the s2895?
>
> Thanks again for your help.
>
> Myles
>
> -----Original Message-----
> From: Lu, Yinghai [mailto:yinghai.lu at amd.com]
> Sent: Wednesday, May 17, 2006 5:09 PM
> To: myles at mouselemur.cs.byu.edu; linuxbios at linuxbios.org
> Subject: RE: [LinuxBIOS] Etherboot (FILO) with SATA on tyan s2895
>
> You can not boot from CK804 sata directly with FILO in Etherboot.
>
> The code only support Sata that can work on compatible IDE mode.
>
> You need to use other media ( network, CF IDE flash) to load kernel with
> ck804 sata and kexec support, and use kexec to load final kernel in your
> sata disk.
>
> YH
>
> -----Original Message-----
> From: linuxbios-bounces at linuxbios.org
> [mailto:linuxbios-bounces at linuxbios.org] On Behalf Of Myles Watson
> Sent: Wednesday, May 17, 2006 3:57 PM
> To: linuxbios at linuxbios.org
> Subject: [LinuxBIOS] Etherboot (FILO) with SATA on tyan s2895
>
> I am booting linuxbios with etherboot and filo as the payload. I tried
> to
> follow the s2881 tutorial on the wiki.
>
> Etherboot only finds my cd-rom. When I try to use hde:/ it tells me that
> "Drive 4 does not exist". All drives up to j except hda (my cd-rom) give
> the
> same error message. Sometimes if I try hdg it hangs.
>
> I saw README.filo_in_etherboot where it says it only works on SATA port
> 1 or
> 2. I've tried on SATA 0 port 0 and 1, SATA 1 port 2 and 3.
>
> I also seem to need to boot the factory BIOS in between each attempt, or
> I
> won't get very far.
>
> Is there something simple I've missed?
>
> Thanks,
> Myles
>
> Output:
>
> Etherboot 5.4.2
> Drivers: TG3 FILO Images: NBI ELF
> Protocols: DHCP TFTP
> Relocating text ...
> Scanning PCI: found 30 devices
> Probing pci disk...
> [FILO]FILO version 0.4.1
> boot: hde3:/boot/vmlinuz... initrd=/boot/initrd...
> IDE time out
> No drive detected on IDE channel 2
> boot: hdc:/
> No drive detected on IDE channel 1
>
>
>
> --
> linuxbios mailing list
> linuxbios at linuxbios.org
> http://www.openbios.org/mailman/listinfo/linuxbios
>
>
>
> --
> linuxbios mailing list
> linuxbios at linuxbios.org
> http://www.openbios.org/mailman/listinfo/linuxbios
>
>
>
> --
> linuxbios mailing list
> linuxbios at linuxbios.org
> http://www.openbios.org/mailman/listinfo/linuxbios
>

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





From fourstar10_2000 at yahoo.com  Sat May 27 02:03:17 2006
From: fourstar10_2000 at yahoo.com (steve yannalfo)
Date: Fri, 26 May 2006 17:03:17 -0700 (PDT)
Subject: [LinuxBIOS] C style Formatting
Message-ID: <20060527000317.35862.qmail@web38903.mail.mud.yahoo.com>

I thought the community may like this.... I used it.
 from the command line....
 
 cd linuxbios
 find . -name "*.c" -exec beautify.sh {}  \;
 find . -name "*.h" -exec beautify.sh {}  \; 
 
 
 beautify.sh
 ------------------------------------------------
 #!/bin/bash
 
 echo "Beatifying $1..."
 
 # sed scrip = remove fore & aft spaces
 sed -e 's/^[ \t]*//;s/[ \t]*$//' $1 | indent -br -nce -nprs -nsaf -nsai -nut -ts2 -ut -l50 > tmp;
 mv -v tmp $1
 ------------------------------------------------
 
 
 steve
 
 
		
---------------------------------
Talk is cheap. Use Yahoo! Messenger to make PC-to-Phone calls.  Great rates starting at 1&cent;/min.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20060526/2eb9fbb8/attachment.html>

From tylerapohl at gmail.com  Sat May 27 04:09:20 2006
From: tylerapohl at gmail.com (Tyler Pohl)
Date: Fri, 26 May 2006 19:09:20 -0700
Subject: [LinuxBIOS] buildtarget problem
Message-ID: <503ab0210605261909l41bf5c86l5ca373d74f3b1876@mail.gmail.com>

Hi when i try to buildtarget i get this message

dell800:/home/tyler/LinuxBIOSv2/targets# ./buildtarget
/digitallogic/msm586seg
No target config file found
Tried both /digitallogic/msm586seg and /digitallogic/msm586seg/Config.lb

my config files are correct because i downloaded the zipped version and have
compare them to the Linux Journel website.

Any ideas?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20060526/06c4f25d/attachment.html>

From smithbone at gmail.com  Sat May 27 05:26:20 2006
From: smithbone at gmail.com (Richard Smith)
Date: Fri, 26 May 2006 22:26:20 -0500
Subject: [LinuxBIOS] buildtarget problem
In-Reply-To: <503ab0210605261909l41bf5c86l5ca373d74f3b1876@mail.gmail.com>
References: <503ab0210605261909l41bf5c86l5ca373d74f3b1876@mail.gmail.com>
Message-ID: <8a0c36780605262026l4201ab5du96cacace272360ee@mail.gmail.com>

On 5/26/06, Tyler Pohl <tylerapohl at gmail.com> wrote:
> Hi when i try to buildtarget i get this message
>
>  dell800:/home/tyler/LinuxBIOSv2/targets# ./buildtarget
> /digitallogic/msm586seg

Is that the exact line or did you just for get your './' on the target
path?  The above starts at the root directory.

I just tried and they work for me.

-- 
Richard A. Smith



From rminnich at lanl.gov  Sat May 27 05:28:41 2006
From: rminnich at lanl.gov (Ronald G Minnich)
Date: Fri, 26 May 2006 21:28:41 -0600
Subject: [LinuxBIOS] buildtarget problem
In-Reply-To: <503ab0210605261909l41bf5c86l5ca373d74f3b1876@mail.gmail.com>
References: <503ab0210605261909l41bf5c86l5ca373d74f3b1876@mail.gmail.com>
Message-ID: <4477C769.1040907@lanl.gov>

Tyler Pohl wrote:
> Hi when i try to buildtarget i get this message
> 
> dell800:/home/tyler/LinuxBIOSv2/targets# ./buildtarget 
> /digitallogic/msm586seg
   ^

are you really putting a / there?
> No target config file found
> Tried both /digitallogic/msm586seg and /digitallogic/msm586seg/Config.lb
              ^                           ^

you should not have a / there.

ron



From ward at gnu.org  Sun May 28 19:08:08 2006
From: ward at gnu.org (Ward Vandewege)
Date: Sun, 28 May 2006 13:08:08 -0400
Subject: [LinuxBIOS] Etherboot (FILO) with SATA on tyan s2895
In-Reply-To: <01M2VPJ5UKCK8YB56R@EMAIL1.BYU.EDU>
References: <01M2VPJ5UKCK8YB56R@EMAIL1.BYU.EDU>
Message-ID: <20060528170808.GA13782@localdomain>

On Fri, May 26, 2006 at 02:07:33PM -0600, Myles Watson wrote:
> Is there somewhere that the ACPI information should be getting passed
> through, and it's getting clobbered? I'm booting LinuxBIOS -> FILO/Etherboot
> -> Kernel on an IDE disk.

AFAIK, the LinuxBIOS code for the Tyan boards don't have ACPI support yet. YH
has said a few times it should be (relatively) easy to integrate based on the
ACPI code in the amd/serengeti directory.

Ward.

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



From tylerapohl at gmail.com  Sun May 28 23:54:18 2006
From: tylerapohl at gmail.com (Tyler Pohl)
Date: Sun, 28 May 2006 14:54:18 -0700
Subject: [LinuxBIOS] Intel 386 bios
Message-ID: <503ab0210605281454g6954c024p24a4e71fd54bc50f@mail.gmail.com>

I have a 386 - 233Mhz computer.  The EEprom bios chip is an AT28c010 (1MB
eeprom from Atmel)  I would like to install LinuxBios on this machine but I
can't seem to find any real good documentation on how to go about
configuring and compiling the bios to work for a machine like this.  I have
figured out how to compile a random motherboard using buildtarget but i
don't know exactly where the binary file ends up or how to make it work on a
intel 386 or Xbox or whatever i decide to use it.  I am a Electronic
Engineer but i am having a hard time figuring out how the LinuxBios can be
configured properly.  Can anyone help me to find good documentation on
configure files and what each program is used for in the LinuxBios directory
like for example buildtarget, and in the fallback directory buildrom,
linuxbios etc.   ?

Thank You so much for your time.

I am very interested in being able to use LinuxBios and will work like nuts
to get up to speed in the development of it.  I promise !!!!

Who ever have been working on LinuxBois to get it where this far you Rock !
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20060528/af04591d/attachment.html>

From smithbone at gmail.com  Mon May 29 04:54:16 2006
From: smithbone at gmail.com (Richard Smith)
Date: Sun, 28 May 2006 21:54:16 -0500
Subject: [LinuxBIOS] Intel 386 bios
In-Reply-To: <503ab0210605281454g6954c024p24a4e71fd54bc50f@mail.gmail.com>
References: <503ab0210605281454g6954c024p24a4e71fd54bc50f@mail.gmail.com>
Message-ID: <8a0c36780605281954r9fd96dbl42befbe731012a3f@mail.gmail.com>

On 5/28/06, Tyler Pohl <tylerapohl at gmail.com> wrote:
> I have a 386 - 233Mhz computer.  The EEprom bios chip is an AT28c010 (1MB
> eeprom from Atmel)  I would like to install LinuxBios on this machine but I

You need to have the docs for the chipset of the mainboard.  A good
place to start is booting linux and then listing the chips with
'lspci'.  If you can't get the docs for your chipset then you have a
really rough road ahead.

> can't seem to find any real good documentation on how to go about
> configuring and compiling the bios to work for a machine like this.

Have you gone through the wiki?  There is a lot of good info up there.
 Some of it takes a bit of looking to get to.  As a start go read the
FAQ, Documentation, and Port Guides.  That should get you started.
Some of the Port Guides have a lot of good basic info even if they are
a bit dated.

-- 
Richard A. Smith



From c-d.hailfinger.devel.2006 at gmx.net  Mon May 29 16:00:05 2006
From: c-d.hailfinger.devel.2006 at gmx.net (Carl-Daniel Hailfinger)
Date: Mon, 29 May 2006 16:00:05 +0200
Subject: [LinuxBIOS] Good JTAG debuggers?
Message-ID: <447AFE65.2020705@gmx.net>

Hi,

can anyone give me a hint where to get a good and affordable
JTAG debugger? Or which model I should look for?
I might need one for OLPC development.

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



From g.watson at computer.org  Mon May 29 16:41:13 2006
From: g.watson at computer.org (Greg Watson)
Date: Mon, 29 May 2006 08:41:13 -0600
Subject: [LinuxBIOS] Good JTAG debuggers?
In-Reply-To: <447AFE65.2020705@gmx.net>
References: <447AFE65.2020705@gmx.net>
Message-ID: <6E22782C-7CE6-402D-8DA8-8F2FBD458767@computer.org>

We've used an Abatron BDI 9000 with good success. It works nicely  
with gdb and allows kernel debugging. Ultimate Solutions Inc. (http:// 
ultsol.com) also have an Eclipse-based GUI interface for it, though I  
haven't tried it out.

IBM's Riscwatch is another one, but they are really hard to get hold  
of and more expensive than the Abatron. The debugger software only  
runs on Windows and Linux.

Greg

On May 29, 2006, at 8:00 AM, Carl-Daniel Hailfinger wrote:

> Hi,
>
> can anyone give me a hint where to get a good and affordable
> JTAG debugger? Or which model I should look for?
> I might need one for OLPC development.
>
> Regards,
> Carl-Daniel
> -- 
> http://www.hailfinger.org/
>
> -- 
> linuxbios mailing list
> linuxbios at linuxbios.org
> http://www.openbios.org/mailman/listinfo/linuxbios




From juergen127 at kreuzholzen.de  Mon May 29 17:46:49 2006
From: juergen127 at kreuzholzen.de (Juergen Beisert)
Date: Mon, 29 May 2006 17:46:49 +0200
Subject: [LinuxBIOS] Question about AMD/Cyrix Geode GX1 based system
Message-ID: <200605291746.49115.juergen127@kreuzholzen.de>

Hi all,

I am trying to bring up a small WinCE based terminal with LinuxBios instead. 
I'm using the eaglelion/5bcm as a starting point. With this the system comes 
up, starts etherboot, etherboot loads my Linux kernel (up to text "....done") 
and then nothing more happens.

Some things confuses me: 

....
Devices initialized
Copying IRQ routing tables to 0xf0000...done.
Verifing copy of IRQ routing tables at 0xf0000...failed
Wrote linuxbios table at: 00000000 - 0000017c  checksum 2df2
....

I read in the archives that this failure could be solved be undefining 
CONFIG_COMPRESS. But it did'nt help. Any other hint to solve it?

When etherboot starts:

.....
Etherboot 5.4.2 (GPL) http://etherboot.org
Drivers: RTL8139   Images: ELF
Protocols: DHCP TFTP
Relocating _text from: [000100e0,000219a0) to [03aee740,03b00000)
Boot from (N)etwork or (Q)uit?

Probing pci nic...
[rtl8139] - ioaddr 0X1000, irq 0, addr 00:30:AA:00:25:1B 100Mbps full-duplex
Searching for server (DHCP).....
Me: 192.168.1.5, DHCP: 192.168.1.2, TFTP: 192.168.1.2, Gateway 192.168.1.2
Loading 192.168.1.2:i586Linux ..(ELF)..
....done

Is "irq 0" correct at this point of time?

Does LinuxBIOS needs any preparations/patches on the Linux kernel to boot and 
run it?
I tried with enabled framebuffer console (and activated screen in the Geode) 
and with console on serial port. Both without success (also I tried 2.4 and 
2.6 kernels).

Thanks for any help in advance.

Juergen




From juergen127 at kreuzholzen.de  Mon May 29 18:37:32 2006
From: juergen127 at kreuzholzen.de (Juergen Beisert)
Date: Mon, 29 May 2006 18:37:32 +0200
Subject: [LinuxBIOS] Question about AMD/Cyrix Geode GX1 based system
In-Reply-To: <200605291746.49115.juergen127@kreuzholzen.de>
References: <200605291746.49115.juergen127@kreuzholzen.de>
Message-ID: <200605291837.32099.juergen127@kreuzholzen.de>

Hi all,

some news:

On Monday 29 May 2006 17:46, Juergen Beisert wrote:
> Some things confuses me:
>
> ....
> Devices initialized
> Copying IRQ routing tables to 0xf0000...done.
> Verifing copy of IRQ routing tables at 0xf0000...failed
> Wrote linuxbios table at: 00000000 - 0000017c  checksum 2df2
> ....

With write enabled E and F segments this message changes to:
....
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 linuxbios table at: 00000000 - 0000017c  checksum f206
....

But it still hangs after downloading the Linux kernel :-(

Juergen




From stepan at coresystems.de  Mon May 29 20:26:08 2006
From: stepan at coresystems.de (Stefan Reinauer)
Date: Mon, 29 May 2006 20:26:08 +0200
Subject: [LinuxBIOS] Question about AMD/Cyrix Geode GX1 based system
In-Reply-To: <200605291837.32099.juergen127@kreuzholzen.de>
References: <200605291746.49115.juergen127@kreuzholzen.de>
	<200605291837.32099.juergen127@kreuzholzen.de>
Message-ID: <20060529182608.GB30836@coresystems.de>

* Juergen Beisert <juergen127 at kreuzholzen.de> [060529 18:37]:
> With write enabled E and F segments this message changes to:
> ....
> 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.

Can you provide a patch?

> But it still hangs after downloading the Linux kernel :-(

Have you enabled serial console in your kernel config?
and did you specify it on the kernel command line? (ie.
console=ttyS0,115200n8)

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 stepan at coresystems.de  Mon May 29 22:01:14 2006
From: stepan at coresystems.de (Stefan Reinauer)
Date: Mon, 29 May 2006 22:01:14 +0200
Subject: [LinuxBIOS] Good JTAG debuggers?
In-Reply-To: <447AFE65.2020705@gmx.net>
References: <447AFE65.2020705@gmx.net>
Message-ID: <20060529200114.GA4962@coresystems.de>

* Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006 at gmx.net> [060529 16:00]:
> Hi,
> 
> can anyone give me a hint where to get a good and affordable
> JTAG debugger? Or which model I should look for?
> I might need one for OLPC development.

For some systems it is just enough to use a parallel port cable with
JTAG connector and an intelligent piece of software (some such can be
found on freshmeat) - never tried this with x86 though.

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 lanl.gov  Tue May 30 06:32:36 2006
From: rminnich at lanl.gov (Ronald G Minnich)
Date: Mon, 29 May 2006 22:32:36 -0600
Subject: [LinuxBIOS] Question about AMD/Cyrix Geode GX1 based system
In-Reply-To: <200605291837.32099.juergen127@kreuzholzen.de>
References: <200605291746.49115.juergen127@kreuzholzen.de>
	<200605291837.32099.juergen127@kreuzholzen.de>
Message-ID: <447BCAE4.9050804@lanl.gov>

what version kernel?

enable early printk and  boot with
earlyprintk=ttyS0,115200,keep

and see what you get (copy to me)

ron



From rminnich at lanl.gov  Tue May 30 06:38:46 2006
From: rminnich at lanl.gov (Ronald G Minnich)
Date: Mon, 29 May 2006 22:38:46 -0600
Subject: [LinuxBIOS] Good JTAG debuggers?
In-Reply-To: <20060529200114.GA4962@coresystems.de>
References: <447AFE65.2020705@gmx.net> <20060529200114.GA4962@coresystems.de>
Message-ID: <447BCC56.30502@lanl.gov>

for OLPC, you really ought to have an FS2

ron



From per at mellander.org  Tue May 30 09:05:18 2006
From: per at mellander.org (Per Mellander)
Date: Tue, 30 May 2006 09:05:18 +0200
Subject: [LinuxBIOS] EPIA-MII 12000, almost there.  ( newbie )
Message-ID: <20060530065020.M85269@mellander.org>

Hi list.

I've been trying to get LinuxBIOS going on my EPIA-MII 12000 system. I've read numerous
messages on the ML and Googling for answers. Still I can't get my system to boot properly.

Following the HOWTO I've managed to create a linuxbios.rom that actually boots, starts
the payload ( filo ) but then I don't get the kernel to load.

I'm using LinuxBIOS snapshot as of 24th of May and Filo 0.5. The VGA-rom is extracted with:

dd if=/dev/mem of=/video.bios.bin bs=65536 count=1 skip=12

My root is /dev/hdb1 and I've put my ( working ) kernel at /vmlinuz. ( It's a stock
Fedora 5 kernel, 2.6.16-1.2111_FC5. )

When I use  USE_GRUB = 1 and put a copy of my menu.lst in /boot/filo/menu.lst, I only
get a grub prompt and when trying to manually load the kernel with:

kernel /vmlinuz
root=/dev/hdb1
boot

It complains about unknown filetype, IIRC.

I've also tried using:

AUTOBOOT_FILE = "hdb1:/vmlinuz root=/dev/hdb1 console=tty0 console=ttyS0,115200"

With this I get the LinuxBIOS to constantly restart.

My actual question is therefore If there is anyone with a working setup that could
please give me some help?





From juergen127 at kreuzholzen.de  Tue May 30 11:08:54 2006
From: juergen127 at kreuzholzen.de (Juergen Beisert)
Date: Tue, 30 May 2006 11:08:54 +0200
Subject: [LinuxBIOS] Question about AMD/Cyrix Geode GX1 based system
In-Reply-To: <20060529182608.GB30836@coresystems.de>
References: <200605291746.49115.juergen127@kreuzholzen.de>
	<200605291837.32099.juergen127@kreuzholzen.de>
	<20060529182608.GB30836@coresystems.de>
Message-ID: <200605301108.54246.juergen127@kreuzholzen.de>

On Monday 29 May 2006 20:26, Stefan Reinauer wrote:
> * Juergen Beisert <juergen127 at kreuzholzen.de> [060529 18:37]:
> > With write enabled E and F segments this message changes to:
> > ....
> > 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.
>
> Can you provide a patch?

Yes, attached. But I'm not sure if this is the right place to patch. Maybe 
there is a better place to enable this feature?

> > But it still hangs after downloading the Linux kernel :-(
>
> Have you enabled serial console in your kernel config?
> and did you specify it on the kernel command line? (ie.
> console=ttyS0,115200n8)

Yes I did. Its not my first embedded target that I bring up (but my first with 
LinuxBios). So that was the first I care for.
The UART address seems ok, so I think Linux can find and use this device.

Regards

Juergen
-------------- next part --------------
A non-text attachment was scrubbed...
Name: northbridge.diff
Type: text/x-diff
Size: 611 bytes
Desc: not available
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20060530/f6097596/attachment.bin>

From juergen127 at kreuzholzen.de  Tue May 30 12:33:11 2006
From: juergen127 at kreuzholzen.de (Juergen Beisert)
Date: Tue, 30 May 2006 12:33:11 +0200
Subject: [LinuxBIOS] Question about AMD/Cyrix Geode GX1 based system
In-Reply-To: <447BCAE4.9050804@lanl.gov>
References: <200605291746.49115.juergen127@kreuzholzen.de>
	<200605291837.32099.juergen127@kreuzholzen.de>
	<447BCAE4.9050804@lanl.gov>
Message-ID: <200605301233.11249.juergen127@kreuzholzen.de>

Hi Ronald,

On Tuesday 30 May 2006 06:32, Ronald G Minnich wrote:
> what version kernel?

I tried with 2.4.28 and 2.6.16.

> enable early printk and  boot with
> earlyprintk=ttyS0,115200,keep

It seems only true for 2.6 kernels, isn't it? I did not find any menu entry in 
2.4.28 for this, right?

Kernel image created with:

mkelf-linux --output=/srv/tftpboot/i586Linux 
"--append=earlyprintk=ttyS0,115200,keep console=ttyS0,115200n8" 
--rootdir=/srv/nfsexport/rootfs-i486 --rootmode=rw --ip=dhcp 
/home/jb/Projekte/linux-2.6.16/arch/i386/boot/bzImage

<sound of powering on>
....
Probing pci nic...
[rtl8139] - ioaddr 0X1000, irq 0, addr 00:30:AA:00:25:1B 100Mbps full-duplex
Searching for server (DHCP).....
Me: 192.168.1.5, DHCP: 192.168.1.2, TFTP: 192.168.1.2, Gateway 192.168.1.2
Loading 192.168.1.2:i586Linux ..(ELF)... 
............................................................................
.............................................................................
............................................................................
............................................................................
............................................................................
<many dots snipped>
............................................................................
............................................................................
............................................................................
............................................................................
............................................................................
........done

> and see what you get (copy to me)

Sorry that's all. No more output after the word "done".

I also attach the kernel configuration file.

Maybe etherboot does a bad thing? I built this payload not by my own, I 
downloaded it from their website (as an "ELF (LinuxBIOS) ROM Image (.elf)"). 
I didn't touch any of the customising configurations.

Regards

Juergen
-------------- next part --------------
#
# Automatically generated make config: don't edit
# Linux kernel version: 2.6.16
# Tue May 30 11:56:24 2006
#
CONFIG_X86_32=y
CONFIG_SEMAPHORE_SLEEPERS=y
CONFIG_X86=y
CONFIG_MMU=y
CONFIG_GENERIC_ISA_DMA=y
CONFIG_GENERIC_IOMAP=y
CONFIG_ARCH_MAY_HAVE_PC_FDC=y
CONFIG_DMI=y

#
# Code maturity level options
#
CONFIG_EXPERIMENTAL=y
CONFIG_BROKEN_ON_SMP=y
CONFIG_INIT_ENV_ARG_LIMIT=32

#
# General setup
#
CONFIG_LOCALVERSION=""
CONFIG_LOCALVERSION_AUTO=y
# CONFIG_SWAP is not set
CONFIG_SYSVIPC=y
# CONFIG_POSIX_MQUEUE is not set
# CONFIG_BSD_PROCESS_ACCT is not set
CONFIG_SYSCTL=y
CONFIG_AUDIT=y
CONFIG_AUDITSYSCALL=y
# CONFIG_IKCONFIG is not set
CONFIG_INITRAMFS_SOURCE=""
CONFIG_UID16=y
CONFIG_VM86=y
# CONFIG_CC_OPTIMIZE_FOR_SIZE is not set
CONFIG_EMBEDDED=y
# CONFIG_KALLSYMS is not set
CONFIG_HOTPLUG=y
CONFIG_PRINTK=y
CONFIG_BUG=y
CONFIG_ELF_CORE=y
CONFIG_BASE_FULL=y
# CONFIG_FUTEX is not set
# CONFIG_EPOLL is not set
CONFIG_SHMEM=y
CONFIG_CC_ALIGN_FUNCTIONS=0
CONFIG_CC_ALIGN_LABELS=0
CONFIG_CC_ALIGN_LOOPS=0
CONFIG_CC_ALIGN_JUMPS=0
CONFIG_SLAB=y
# CONFIG_TINY_SHMEM is not set
CONFIG_BASE_SMALL=0
# CONFIG_SLOB is not set

#
# Loadable module support
#
CONFIG_MODULES=y
CONFIG_MODULE_UNLOAD=y
# CONFIG_MODULE_FORCE_UNLOAD is not set
CONFIG_OBSOLETE_MODPARM=y
# CONFIG_MODVERSIONS is not set
# CONFIG_MODULE_SRCVERSION_ALL is not set
# CONFIG_KMOD is not set

#
# Block layer
#
# CONFIG_LBD is not set

#
# IO Schedulers
#
CONFIG_IOSCHED_NOOP=y
# CONFIG_IOSCHED_AS is not set
# CONFIG_IOSCHED_DEADLINE is not set
# CONFIG_IOSCHED_CFQ is not set
# CONFIG_DEFAULT_AS is not set
# CONFIG_DEFAULT_DEADLINE is not set
# CONFIG_DEFAULT_CFQ is not set
CONFIG_DEFAULT_NOOP=y
CONFIG_DEFAULT_IOSCHED="noop"

#
# Processor type and features
#
CONFIG_X86_PC=y
# CONFIG_X86_ELAN is not set
# CONFIG_X86_VOYAGER is not set
# CONFIG_X86_NUMAQ is not set
# CONFIG_X86_SUMMIT is not set
# CONFIG_X86_BIGSMP is not set
# CONFIG_X86_VISWS is not set
# CONFIG_X86_GENERICARCH is not set
# CONFIG_X86_ES7000 is not set
# CONFIG_M386 is not set
# CONFIG_M486 is not set
# CONFIG_M586 is not set
# CONFIG_M586TSC is not set
# CONFIG_M586MMX is not set
# CONFIG_M686 is not set
# CONFIG_MPENTIUMII is not set
# CONFIG_MPENTIUMIII is not set
# CONFIG_MPENTIUMM is not set
# CONFIG_MPENTIUM4 is not set
# CONFIG_MK6 is not set
# CONFIG_MK7 is not set
# CONFIG_MK8 is not set
# CONFIG_MCRUSOE is not set
# CONFIG_MEFFICEON is not set
# CONFIG_MWINCHIPC6 is not set
# CONFIG_MWINCHIP2 is not set
# CONFIG_MWINCHIP3D is not set
CONFIG_MGEODEGX1=y
# CONFIG_MGEODE_LX is not set
# CONFIG_MCYRIXIII is not set
# CONFIG_MVIAC3_2 is not set
# CONFIG_X86_GENERIC is not set
CONFIG_X86_CMPXCHG=y
CONFIG_X86_XADD=y
CONFIG_X86_L1_CACHE_SHIFT=4
CONFIG_RWSEM_XCHGADD_ALGORITHM=y
CONFIG_GENERIC_CALIBRATE_DELAY=y
CONFIG_X86_PPRO_FENCE=y
CONFIG_X86_WP_WORKS_OK=y
CONFIG_X86_INVLPG=y
CONFIG_X86_BSWAP=y
CONFIG_X86_POPAD_OK=y
CONFIG_X86_CMPXCHG64=y
CONFIG_X86_ALIGNMENT_16=y
CONFIG_X86_TSC=y
# CONFIG_HPET_TIMER is not set
# CONFIG_SMP is not set
# CONFIG_PREEMPT_NONE is not set
CONFIG_PREEMPT_VOLUNTARY=y
# CONFIG_PREEMPT is not set
# CONFIG_X86_UP_APIC is not set
# CONFIG_X86_MCE is not set
# CONFIG_TOSHIBA is not set
# CONFIG_I8K is not set
# CONFIG_X86_REBOOTFIXUPS is not set
# CONFIG_MICROCODE is not set
# CONFIG_X86_MSR is not set
# CONFIG_X86_CPUID is not set

#
# Firmware Drivers
#
# CONFIG_EDD is not set
# CONFIG_DELL_RBU is not set
# CONFIG_DCDBAS is not set
CONFIG_NOHIGHMEM=y
# CONFIG_HIGHMEM4G is not set
# CONFIG_HIGHMEM64G is not set
CONFIG_VMSPLIT_3G=y
# CONFIG_VMSPLIT_3G_OPT is not set
# CONFIG_VMSPLIT_2G is not set
# CONFIG_VMSPLIT_1G is not set
CONFIG_PAGE_OFFSET=0xC0000000
CONFIG_ARCH_FLATMEM_ENABLE=y
CONFIG_ARCH_SPARSEMEM_ENABLE=y
CONFIG_ARCH_SELECT_MEMORY_MODEL=y
CONFIG_SELECT_MEMORY_MODEL=y
CONFIG_FLATMEM_MANUAL=y
# CONFIG_DISCONTIGMEM_MANUAL is not set
# CONFIG_SPARSEMEM_MANUAL is not set
CONFIG_FLATMEM=y
CONFIG_FLAT_NODE_MEM_MAP=y
CONFIG_SPARSEMEM_STATIC=y
CONFIG_SPLIT_PTLOCK_CPUS=4
# CONFIG_MATH_EMULATION is not set
# CONFIG_MTRR is not set
# CONFIG_REGPARM is not set
# CONFIG_SECCOMP is not set
CONFIG_HZ_100=y
# CONFIG_HZ_250 is not set
# CONFIG_HZ_1000 is not set
CONFIG_HZ=100
# CONFIG_KEXEC is not set
CONFIG_PHYSICAL_START=0x100000
# CONFIG_DOUBLEFAULT is not set

#
# Power management options (ACPI, APM)
#
# CONFIG_PM is not set

#
# ACPI (Advanced Configuration and Power Interface) Support
#
# CONFIG_ACPI is not set

#
# CPU Frequency scaling
#
# CONFIG_CPU_FREQ is not set

#
# Bus options (PCI, PCMCIA, EISA, MCA, ISA)
#
CONFIG_PCI=y
# CONFIG_PCI_GOBIOS is not set
# CONFIG_PCI_GOMMCONFIG is not set
# CONFIG_PCI_GODIRECT is not set
CONFIG_PCI_GOANY=y
CONFIG_PCI_BIOS=y
CONFIG_PCI_DIRECT=y
# CONFIG_PCIEPORTBUS is not set
# CONFIG_PCI_LEGACY_PROC is not set
# CONFIG_PCI_DEBUG is not set
CONFIG_ISA_DMA_API=y
CONFIG_ISA=y
# CONFIG_EISA is not set
# CONFIG_MCA is not set
# CONFIG_SCx200 is not set

#
# PCCARD (PCMCIA/CardBus) support
#
# CONFIG_PCCARD is not set

#
# PCI Hotplug Support
#
# CONFIG_HOTPLUG_PCI is not set

#
# Executable file formats
#
CONFIG_BINFMT_ELF=y
# CONFIG_BINFMT_AOUT is not set
# CONFIG_BINFMT_MISC is not set

#
# Networking
#
CONFIG_NET=y

#
# Networking options
#
# CONFIG_NETDEBUG is not set
CONFIG_PACKET=y
# CONFIG_PACKET_MMAP is not set
CONFIG_UNIX=y
# CONFIG_NET_KEY is not set
CONFIG_INET=y
# CONFIG_IP_MULTICAST is not set
# CONFIG_IP_ADVANCED_ROUTER is not set
CONFIG_IP_FIB_HASH=y
CONFIG_IP_PNP=y
CONFIG_IP_PNP_DHCP=y
# CONFIG_IP_PNP_BOOTP is not set
# CONFIG_IP_PNP_RARP is not set
# CONFIG_NET_IPIP is not set
# CONFIG_NET_IPGRE is not set
# CONFIG_ARPD is not set
# CONFIG_SYN_COOKIES is not set
# CONFIG_INET_AH is not set
# CONFIG_INET_ESP is not set
# CONFIG_INET_IPCOMP is not set
# CONFIG_INET_TUNNEL is not set
# CONFIG_INET_DIAG is not set
# CONFIG_TCP_CONG_ADVANCED is not set
CONFIG_TCP_CONG_BIC=y
# CONFIG_IPV6 is not set
# CONFIG_NETFILTER is not set

#
# DCCP Configuration (EXPERIMENTAL)
#
# CONFIG_IP_DCCP is not set

#
# SCTP Configuration (EXPERIMENTAL)
#
# CONFIG_IP_SCTP is not set

#
# TIPC Configuration (EXPERIMENTAL)
#
# CONFIG_TIPC is not set
# CONFIG_ATM is not set
# CONFIG_BRIDGE is not set
# CONFIG_VLAN_8021Q is not set
# CONFIG_DECNET is not set
# CONFIG_LLC2 is not set
# CONFIG_IPX is not set
# CONFIG_ATALK is not set
# CONFIG_X25 is not set
# CONFIG_LAPB is not set
# CONFIG_NET_DIVERT is not set
# CONFIG_ECONET is not set
# CONFIG_WAN_ROUTER is not set

#
# QoS and/or fair queueing
#
# CONFIG_NET_SCHED is not set

#
# Network testing
#
# CONFIG_NET_PKTGEN is not set
# CONFIG_HAMRADIO is not set
# CONFIG_IRDA is not set
# CONFIG_BT is not set
# CONFIG_IEEE80211 is not set

#
# Device Drivers
#

#
# Generic Driver Options
#
CONFIG_STANDALONE=y
CONFIG_PREVENT_FIRMWARE_BUILD=y
CONFIG_FW_LOADER=m
# CONFIG_DEBUG_DRIVER is not set

#
# Connector - unified userspace <-> kernelspace linker
#
# CONFIG_CONNECTOR is not set

#
# Memory Technology Devices (MTD)
#
# CONFIG_MTD is not set

#
# Parallel port support
#
# CONFIG_PARPORT is not set

#
# Plug and Play support
#
# CONFIG_PNP is not set

#
# Block devices
#
# CONFIG_BLK_DEV_FD is not set
# CONFIG_BLK_DEV_XD is not set
# CONFIG_BLK_CPQ_DA is not set
# CONFIG_BLK_CPQ_CISS_DA is not set
# CONFIG_BLK_DEV_DAC960 is not set
# CONFIG_BLK_DEV_UMEM is not set
# CONFIG_BLK_DEV_COW_COMMON is not set
# CONFIG_BLK_DEV_LOOP is not set
# CONFIG_BLK_DEV_NBD is not set
# CONFIG_BLK_DEV_SX8 is not set
# CONFIG_BLK_DEV_RAM is not set
CONFIG_BLK_DEV_RAM_COUNT=16
# CONFIG_CDROM_PKTCDVD is not set
# CONFIG_ATA_OVER_ETH is not set

#
# ATA/ATAPI/MFM/RLL support
#
# CONFIG_IDE is not set

#
# SCSI device support
#
# CONFIG_RAID_ATTRS is not set
# CONFIG_SCSI is not set

#
# Old CD-ROM drivers (not SCSI, not IDE)
#
# CONFIG_CD_NO_IDESCSI is not set

#
# Multi-device support (RAID and LVM)
#
# CONFIG_MD is not set

#
# Fusion MPT device support
#
# CONFIG_FUSION is not set

#
# IEEE 1394 (FireWire) support
#
# CONFIG_IEEE1394 is not set

#
# I2O device support
#
# CONFIG_I2O is not set

#
# Network device support
#
CONFIG_NETDEVICES=y
# CONFIG_DUMMY is not set
# CONFIG_BONDING is not set
# CONFIG_EQUALIZER is not set
# CONFIG_TUN is not set

#
# ARCnet devices
#
# CONFIG_ARCNET is not set

#
# PHY device support
#
# CONFIG_PHYLIB is not set

#
# Ethernet (10 or 100Mbit)
#
CONFIG_NET_ETHERNET=y
CONFIG_MII=y
# CONFIG_HAPPYMEAL is not set
# CONFIG_SUNGEM is not set
# CONFIG_CASSINI is not set
# CONFIG_NET_VENDOR_3COM is not set
# CONFIG_LANCE is not set
# CONFIG_NET_VENDOR_SMC is not set
# CONFIG_NET_VENDOR_RACAL is not set

#
# Tulip family network device support
#
# CONFIG_NET_TULIP is not set
# CONFIG_AT1700 is not set
# CONFIG_DEPCA is not set
# CONFIG_HP100 is not set
# CONFIG_NET_ISA is not set
CONFIG_NET_PCI=y
# CONFIG_PCNET32 is not set
# CONFIG_AMD8111_ETH is not set
# CONFIG_ADAPTEC_STARFIRE is not set
# CONFIG_AC3200 is not set
# CONFIG_APRICOT is not set
# CONFIG_B44 is not set
# CONFIG_FORCEDETH is not set
# CONFIG_CS89x0 is not set
# CONFIG_DGRS is not set
# CONFIG_EEPRO100 is not set
# CONFIG_E100 is not set
# CONFIG_FEALNX is not set
# CONFIG_NATSEMI is not set
# CONFIG_NE2K_PCI is not set
# CONFIG_8139CP is not set
CONFIG_8139TOO=y
CONFIG_8139TOO_PIO=y
# CONFIG_8139TOO_TUNE_TWISTER is not set
# CONFIG_8139TOO_8129 is not set
# CONFIG_8139_OLD_RX_RESET is not set
# CONFIG_SIS900 is not set
# CONFIG_EPIC100 is not set
# CONFIG_SUNDANCE is not set
# CONFIG_TLAN is not set
# CONFIG_VIA_RHINE is not set

#
# Ethernet (1000 Mbit)
#
# CONFIG_ACENIC is not set
# CONFIG_DL2K is not set
# CONFIG_E1000 is not set
# CONFIG_NS83820 is not set
# CONFIG_HAMACHI is not set
# CONFIG_YELLOWFIN is not set
# CONFIG_R8169 is not set
# CONFIG_SIS190 is not set
# CONFIG_SKGE is not set
# CONFIG_SKY2 is not set
# CONFIG_SK98LIN is not set
# CONFIG_VIA_VELOCITY is not set
# CONFIG_TIGON3 is not set
# CONFIG_BNX2 is not set

#
# Ethernet (10000 Mbit)
#
# CONFIG_CHELSIO_T1 is not set
# CONFIG_IXGB is not set
# CONFIG_S2IO is not set

#
# Token Ring devices
#
# CONFIG_TR is not set

#
# Wireless LAN (non-hamradio)
#
# CONFIG_NET_RADIO is not set

#
# Wan interfaces
#
# CONFIG_WAN is not set
# CONFIG_FDDI is not set
# CONFIG_HIPPI is not set
# CONFIG_PPP is not set
# CONFIG_SLIP is not set
# CONFIG_SHAPER is not set
# CONFIG_NETCONSOLE is not set
# CONFIG_NETPOLL is not set
# CONFIG_NET_POLL_CONTROLLER is not set

#
# ISDN subsystem
#
# CONFIG_ISDN is not set

#
# Telephony Support
#
# CONFIG_PHONE is not set

#
# Input device support
#
# CONFIG_INPUT is not set

#
# Hardware I/O ports
#
CONFIG_SERIO=y
CONFIG_SERIO_I8042=y
# CONFIG_SERIO_SERPORT is not set
# CONFIG_SERIO_CT82C710 is not set
# CONFIG_SERIO_PCIPS2 is not set
CONFIG_SERIO_LIBPS2=y
# CONFIG_SERIO_RAW is not set
# CONFIG_GAMEPORT is not set

#
# Character devices
#
# CONFIG_VT is not set
# CONFIG_SERIAL_NONSTANDARD is not set

#
# Serial drivers
#
CONFIG_SERIAL_8250=y
CONFIG_SERIAL_8250_CONSOLE=y
CONFIG_SERIAL_8250_NR_UARTS=2
CONFIG_SERIAL_8250_RUNTIME_UARTS=2
# CONFIG_SERIAL_8250_EXTENDED is not set

#
# Non-8250 serial port support
#
CONFIG_SERIAL_CORE=y
CONFIG_SERIAL_CORE_CONSOLE=y
# CONFIG_SERIAL_JSM is not set
# CONFIG_UNIX98_PTYS is not set
CONFIG_LEGACY_PTYS=y
CONFIG_LEGACY_PTY_COUNT=16

#
# IPMI
#
# CONFIG_IPMI_HANDLER is not set

#
# Watchdog Cards
#
# CONFIG_WATCHDOG is not set
# CONFIG_HW_RANDOM is not set
# CONFIG_NVRAM is not set
# CONFIG_RTC is not set
# CONFIG_GEN_RTC is not set
# CONFIG_DTLK is not set
# CONFIG_R3964 is not set
# CONFIG_APPLICOM is not set

#
# Ftape, the floppy tape device driver
#
# CONFIG_FTAPE is not set
# CONFIG_AGP is not set
# CONFIG_DRM is not set
# CONFIG_MWAVE is not set
# CONFIG_CS5535_GPIO is not set
# CONFIG_RAW_DRIVER is not set
# CONFIG_HANGCHECK_TIMER is not set

#
# TPM devices
#
# CONFIG_TCG_TPM is not set
# CONFIG_TELCLOCK is not set

#
# I2C support
#
# CONFIG_I2C is not set

#
# SPI support
#
# CONFIG_SPI is not set
# CONFIG_SPI_MASTER is not set

#
# Dallas's 1-wire bus
#
# CONFIG_W1 is not set

#
# Hardware Monitoring support
#
# CONFIG_HWMON is not set
# CONFIG_HWMON_VID is not set

#
# Misc devices
#
# CONFIG_IBM_ASM is not set

#
# Multimedia Capabilities Port drivers
#

#
# Multimedia devices
#
# CONFIG_VIDEO_DEV is not set

#
# Digital Video Broadcasting Devices
#
# CONFIG_DVB is not set

#
# Graphics support
#
# CONFIG_FB is not set

#
# Sound
#
# CONFIG_SOUND is not set

#
# USB support
#
CONFIG_USB_ARCH_HAS_HCD=y
CONFIG_USB_ARCH_HAS_OHCI=y
# CONFIG_USB is not set

#
# NOTE: USB_STORAGE enables SCSI, and 'SCSI disk support'
#

#
# USB Gadget Support
#
# CONFIG_USB_GADGET is not set

#
# MMC/SD Card support
#
# CONFIG_MMC is not set

#
# InfiniBand support
#
# CONFIG_INFINIBAND is not set

#
# EDAC - error detection and reporting (RAS) (EXPERIMENTAL)
#
# CONFIG_EDAC is not set

#
# File systems
#
# CONFIG_EXT2_FS is not set
# CONFIG_EXT3_FS is not set
# CONFIG_REISERFS_FS is not set
# CONFIG_JFS_FS is not set
# CONFIG_FS_POSIX_ACL is not set
# CONFIG_XFS_FS is not set
# CONFIG_OCFS2_FS is not set
# CONFIG_MINIX_FS is not set
# CONFIG_ROMFS_FS is not set
# CONFIG_INOTIFY is not set
# CONFIG_QUOTA is not set
# CONFIG_DNOTIFY is not set
# CONFIG_AUTOFS_FS is not set
# CONFIG_AUTOFS4_FS is not set
# CONFIG_FUSE_FS is not set

#
# CD-ROM/DVD Filesystems
#
# CONFIG_ISO9660_FS is not set
# CONFIG_UDF_FS is not set

#
# DOS/FAT/NT Filesystems
#
# CONFIG_MSDOS_FS is not set
# CONFIG_VFAT_FS is not set
# CONFIG_NTFS_FS is not set

#
# Pseudo filesystems
#
CONFIG_PROC_FS=y
CONFIG_PROC_KCORE=y
CONFIG_SYSFS=y
CONFIG_TMPFS=y
# CONFIG_HUGETLBFS is not set
# CONFIG_HUGETLB_PAGE is not set
CONFIG_RAMFS=y
# CONFIG_RELAYFS_FS is not set
# CONFIG_CONFIGFS_FS is not set

#
# Miscellaneous filesystems
#
# CONFIG_ADFS_FS is not set
# CONFIG_AFFS_FS is not set
# CONFIG_HFS_FS is not set
# CONFIG_HFSPLUS_FS is not set
# CONFIG_BEFS_FS is not set
# CONFIG_BFS_FS is not set
# CONFIG_EFS_FS is not set
# CONFIG_CRAMFS is not set
# CONFIG_VXFS_FS is not set
# CONFIG_HPFS_FS is not set
# CONFIG_QNX4FS_FS is not set
# CONFIG_SYSV_FS is not set
# CONFIG_UFS_FS is not set

#
# Network File Systems
#
CONFIG_NFS_FS=y
CONFIG_NFS_V3=y
# CONFIG_NFS_V3_ACL is not set
# CONFIG_NFS_V4 is not set
# CONFIG_NFS_DIRECTIO is not set
# CONFIG_NFSD is not set
# CONFIG_ROOT_NFS is not set
CONFIG_LOCKD=y
CONFIG_LOCKD_V4=y
CONFIG_NFS_COMMON=y
CONFIG_SUNRPC=y
# CONFIG_RPCSEC_GSS_KRB5 is not set
# CONFIG_RPCSEC_GSS_SPKM3 is not set
# CONFIG_SMB_FS is not set
# CONFIG_CIFS is not set
# CONFIG_NCP_FS is not set
# CONFIG_CODA_FS is not set
# CONFIG_AFS_FS is not set
# CONFIG_9P_FS is not set

#
# Partition Types
#
# CONFIG_PARTITION_ADVANCED is not set
CONFIG_MSDOS_PARTITION=y

#
# Native Language Support
#
CONFIG_NLS=y
CONFIG_NLS_DEFAULT="iso8859-15"
CONFIG_NLS_CODEPAGE_437=y
# CONFIG_NLS_CODEPAGE_737 is not set
# CONFIG_NLS_CODEPAGE_775 is not set
# CONFIG_NLS_CODEPAGE_850 is not set
# CONFIG_NLS_CODEPAGE_852 is not set
# CONFIG_NLS_CODEPAGE_855 is not set
# CONFIG_NLS_CODEPAGE_857 is not set
# CONFIG_NLS_CODEPAGE_860 is not set
# CONFIG_NLS_CODEPAGE_861 is not set
# CONFIG_NLS_CODEPAGE_862 is not set
# CONFIG_NLS_CODEPAGE_863 is not set
# CONFIG_NLS_CODEPAGE_864 is not set
# CONFIG_NLS_CODEPAGE_865 is not set
# CONFIG_NLS_CODEPAGE_866 is not set
# CONFIG_NLS_CODEPAGE_869 is not set
# CONFIG_NLS_CODEPAGE_936 is not set
# CONFIG_NLS_CODEPAGE_950 is not set
# CONFIG_NLS_CODEPAGE_932 is not set
# CONFIG_NLS_CODEPAGE_949 is not set
# CONFIG_NLS_CODEPAGE_874 is not set
# CONFIG_NLS_ISO8859_8 is not set
# CONFIG_NLS_CODEPAGE_1250 is not set
# CONFIG_NLS_CODEPAGE_1251 is not set
# CONFIG_NLS_ASCII is not set
CONFIG_NLS_ISO8859_1=y
# CONFIG_NLS_ISO8859_2 is not set
# CONFIG_NLS_ISO8859_3 is not set
# CONFIG_NLS_ISO8859_4 is not set
# CONFIG_NLS_ISO8859_5 is not set
# CONFIG_NLS_ISO8859_6 is not set
# CONFIG_NLS_ISO8859_7 is not set
# CONFIG_NLS_ISO8859_9 is not set
# CONFIG_NLS_ISO8859_13 is not set
# CONFIG_NLS_ISO8859_14 is not set
CONFIG_NLS_ISO8859_15=y
# CONFIG_NLS_KOI8_R is not set
# CONFIG_NLS_KOI8_U is not set
# CONFIG_NLS_UTF8 is not set

#
# Instrumentation Support
#
# CONFIG_PROFILING is not set
# CONFIG_KPROBES is not set

#
# Kernel hacking
#
# CONFIG_PRINTK_TIME is not set
# CONFIG_MAGIC_SYSRQ is not set
CONFIG_DEBUG_KERNEL=y
CONFIG_LOG_BUF_SHIFT=14
# CONFIG_DETECT_SOFTLOCKUP is not set
# CONFIG_SCHEDSTATS is not set
# CONFIG_DEBUG_SLAB is not set
# CONFIG_DEBUG_MUTEXES is not set
# CONFIG_DEBUG_SPINLOCK is not set
# CONFIG_DEBUG_SPINLOCK_SLEEP is not set
# CONFIG_DEBUG_KOBJECT is not set
# CONFIG_DEBUG_BUGVERBOSE is not set
# CONFIG_DEBUG_INFO is not set
# CONFIG_DEBUG_FS is not set
# CONFIG_DEBUG_VM is not set
# CONFIG_FRAME_POINTER is not set
# CONFIG_FORCED_INLINING is not set
# CONFIG_RCU_TORTURE_TEST is not set
CONFIG_EARLY_PRINTK=y
# CONFIG_DEBUG_STACKOVERFLOW is not set
# CONFIG_DEBUG_STACK_USAGE is not set
# CONFIG_DEBUG_PAGEALLOC is not set
# CONFIG_DEBUG_RODATA is not set
# CONFIG_4KSTACKS is not set

#
# Security options
#
# CONFIG_KEYS is not set
# CONFIG_SECURITY is not set

#
# Cryptographic options
#
# CONFIG_CRYPTO is not set

#
# Hardware crypto devices
#

#
# Library routines
#
# CONFIG_CRC_CCITT is not set
# CONFIG_CRC16 is not set
CONFIG_CRC32=y
# CONFIG_LIBCRC32C is not set
CONFIG_GENERIC_HARDIRQS=y
CONFIG_GENERIC_IRQ_PROBE=y
CONFIG_X86_BIOS_REBOOT=y
CONFIG_KTIME_SCALAR=y

From stepan at coresystems.de  Tue May 30 12:44:29 2006
From: stepan at coresystems.de (Stefan Reinauer)
Date: Tue, 30 May 2006 12:44:29 +0200
Subject: [LinuxBIOS] Question about AMD/Cyrix Geode GX1 based system
In-Reply-To: <200605301233.11249.juergen127@kreuzholzen.de>
References: <200605291746.49115.juergen127@kreuzholzen.de>
	<200605291837.32099.juergen127@kreuzholzen.de>
	<447BCAE4.9050804@lanl.gov>
	<200605301233.11249.juergen127@kreuzholzen.de>
Message-ID: <20060530104429.GA29798@coresystems.de>

* Juergen Beisert <juergen127 at kreuzholzen.de> [060530 12:33]:
> Kernel image created with:
> 
> mkelf-linux --output=/srv/tftpboot/i586Linux 
> "--append=earlyprintk=ttyS0,115200,keep console=ttyS0,115200n8" 
> --rootdir=/srv/nfsexport/rootfs-i486 --rootmode=rw --ip=dhcp 
> /home/jb/Projekte/linux-2.6.16/arch/i386/boot/bzImage

Uh.. what's mkelf-linux? Try mkelfImage from
ftp://ftp.lnxi.com/pub/mkelfImage


-- 
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 juergen127 at kreuzholzen.de  Tue May 30 13:13:08 2006
From: juergen127 at kreuzholzen.de (Juergen Beisert)
Date: Tue, 30 May 2006 13:13:08 +0200
Subject: [LinuxBIOS] Question about AMD/Cyrix Geode GX1 based system
In-Reply-To: <20060530104429.GA29798@coresystems.de>
References: <200605291746.49115.juergen127@kreuzholzen.de>
	<200605301233.11249.juergen127@kreuzholzen.de>
	<20060530104429.GA29798@coresystems.de>
Message-ID: <200605301313.08684.juergen127@kreuzholzen.de>

Hi Stefan,

On Tuesday 30 May 2006 12:44, Stefan Reinauer wrote:
> * Juergen Beisert <juergen127 at kreuzholzen.de> [060530 12:33]:
> > Kernel image created with:
> >
> > mkelf-linux --output=/srv/tftpboot/i586Linux
> > "--append=earlyprintk=ttyS0,115200,keep console=ttyS0,115200n8"
> > --rootdir=/srv/nfsexport/rootfs-i486 --rootmode=rw --ip=dhcp
> > /home/jb/Projekte/linux-2.6.16/arch/i386/boot/bzImage
>
> Uh.. what's mkelf-linux? Try mkelfImage from
> ftp://ftp.lnxi.com/pub/mkelfImage

All right, I tried now:

mkelfImage --command-line="earlyprintk=ttyS0,115200,keep 
console=ttyS0,115200n8 root=/srv/nfsexport/rootfs-i486 ip=dhcp rw" 
--kernel=/home/jb/Projekte/linux-2.6.16/vmlinux 
--output=/srv/tftpboot/i586Linux

The behavior is a _little_ bit different.

<many dots snipped>
....done
Unknown firmware type: LinuxBIOS
Firmware type: PCBIOS

But nothing else. What does it mean?

BTW: mkelf-linux is from the mknbi-packet that I'm using for other etherboot 
targets.

Juergen




From c-d.hailfinger.devel.2006 at gmx.net  Tue May 30 13:43:53 2006
From: c-d.hailfinger.devel.2006 at gmx.net (Carl-Daniel Hailfinger)
Date: Tue, 30 May 2006 13:43:53 +0200
Subject: [LinuxBIOS] Good JTAG debuggers?
In-Reply-To: <447BCC56.30502@lanl.gov>
References: <447AFE65.2020705@gmx.net> <20060529200114.GA4962@coresystems.de>
	<447BCC56.30502@lanl.gov>
Message-ID: <447C2FF9.6020800@gmx.net>

Ronald G Minnich wrote:
> for OLPC, you really ought to have an FS2

Even if I only want to reflash the BIOS?
FS2 products are waaay too expensive for me, I had
hoped for something well under 100$. Speed is not
important for me.

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



From juergen127 at kreuzholzen.de  Tue May 30 16:27:42 2006
From: juergen127 at kreuzholzen.de (Juergen Beisert)
Date: Tue, 30 May 2006 16:27:42 +0200
Subject: [LinuxBIOS] Question about AMD/Cyrix Geode GX1 based system
In-Reply-To: <200605301313.08684.juergen127@kreuzholzen.de>
References: <200605291746.49115.juergen127@kreuzholzen.de>
	<20060530104429.GA29798@coresystems.de>
	<200605301313.08684.juergen127@kreuzholzen.de>
Message-ID: <200605301627.42212.juergen127@kreuzholzen.de>

Hi all,

On Tuesday 30 May 2006 13:13, Juergen Beisert wrote:
> <many dots snipped>
> ....done
> Unknown firmware type: LinuxBIOS
> Firmware type: PCBIOS
>
> But nothing else. What does it mean?

Does anybody know who outputs this string? Is it etherboot or the Linux 
kernel? I cannot find these strings in the sources, neither in the kernel nor 
etherboot sources.

Juergen




From myles at pel.cs.byu.edu  Tue May 30 16:38:53 2006
From: myles at pel.cs.byu.edu (Myles Watson)
Date: Tue, 30 May 2006 08:38:53 -0600
Subject: [LinuxBIOS] EPIA-MII 12000, almost there.  ( newbie )
In-Reply-To: <20060530065020.M85269@mellander.org>
Message-ID: <01M30Z805DVY8YBMSF@EMAIL1.BYU.EDU>


Did you try using mkelfImage from ftp://ftp.lnxi.com/pub/mkelfImage ? It
combines the vmlinuz & initrd files into one.

To get my machine to boot I used the same kernel parameters as I found in
grub, set up by Fedora. 

-----Original Message-----
From: linuxbios-bounces at linuxbios.org
[mailto:linuxbios-bounces at linuxbios.org] On Behalf Of Per Mellander
Sent: Tuesday, May 30, 2006 1:05 AM
To: linuxbios at linuxbios.org
Subject: [LinuxBIOS] EPIA-MII 12000, almost there. ( newbie )

Hi list.

I've been trying to get LinuxBIOS going on my EPIA-MII 12000 system. I've
read numerous
messages on the ML and Googling for answers. Still I can't get my system to
boot properly.

Following the HOWTO I've managed to create a linuxbios.rom that actually
boots, starts
the payload ( filo ) but then I don't get the kernel to load.

I'm using LinuxBIOS snapshot as of 24th of May and Filo 0.5. The VGA-rom is
extracted with:

dd if=/dev/mem of=/video.bios.bin bs=65536 count=1 skip=12

My root is /dev/hdb1 and I've put my ( working ) kernel at /vmlinuz. ( It's
a stock
Fedora 5 kernel, 2.6.16-1.2111_FC5. )

When I use  USE_GRUB = 1 and put a copy of my menu.lst in
/boot/filo/menu.lst, I only
get a grub prompt and when trying to manually load the kernel with:

kernel /vmlinuz
root=/dev/hdb1
boot

It complains about unknown filetype, IIRC.

I've also tried using:

AUTOBOOT_FILE = "hdb1:/vmlinuz root=/dev/hdb1 console=tty0
console=ttyS0,115200"

With this I get the LinuxBIOS to constantly restart.

My actual question is therefore If there is anyone with a working setup that
could
please give me some help?



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





From yinghai.lu at amd.com  Tue May 30 18:28:30 2006
From: yinghai.lu at amd.com (Lu, Yinghai)
Date: Tue, 30 May 2006 09:28:30 -0700
Subject: [LinuxBIOS] Question about AMD/Cyrix Geode GX1 based system
Message-ID: <6F7DA19D05F3CF40B890C7CA2DB13A4203094CE2@ssvlexmb2.amd.com>

mkelfImage

YH

-----Original Message-----
From: linuxbios-bounces at linuxbios.org
[mailto:linuxbios-bounces at linuxbios.org] On Behalf Of Juergen Beisert
Sent: Tuesday, May 30, 2006 7:28 AM
To: linuxbios at linuxbios.org
Subject: Re: [LinuxBIOS] Question about AMD/Cyrix Geode GX1 based system

Hi all,

On Tuesday 30 May 2006 13:13, Juergen Beisert wrote:
> <many dots snipped>
> ....done
> Unknown firmware type: LinuxBIOS
> Firmware type: PCBIOS
>
> But nothing else. What does it mean?

Does anybody know who outputs this string? Is it etherboot or the Linux 
kernel? I cannot find these strings in the sources, neither in the
kernel nor 
etherboot sources.

Juergen


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





From rminnich at lanl.gov  Tue May 30 19:22:57 2006
From: rminnich at lanl.gov (Ronald G Minnich)
Date: Tue, 30 May 2006 11:22:57 -0600
Subject: [LinuxBIOS] Good JTAG debuggers?
In-Reply-To: <447C2FF9.6020800@gmx.net>
References: <447AFE65.2020705@gmx.net> <20060529200114.GA4962@coresystems.de>
	<447BCC56.30502@lanl.gov> <447C2FF9.6020800@gmx.net>
Message-ID: <447C7F71.9050401@lanl.gov>

Carl-Daniel Hailfinger wrote:
> Ronald G Minnich wrote:
> 
>>for OLPC, you really ought to have an FS2
> 
> 
> Even if I only want to reflash the BIOS?
oh. to reflash, you can use the olpc itself.

ron



From dhendrix at google.com  Tue May 30 20:52:35 2006
From: dhendrix at google.com (David Hendricks)
Date: Tue, 30 May 2006 11:52:35 -0700
Subject: [LinuxBIOS] Good JTAG debuggers?
In-Reply-To: <447C7F71.9050401@lanl.gov>
References: <447AFE65.2020705@gmx.net> <20060529200114.GA4962@coresystems.de>
	<447BCC56.30502@lanl.gov> <447C2FF9.6020800@gmx.net>
	<447C7F71.9050401@lanl.gov>
Message-ID: <ec9b26620605301152h5cd8f013pc5c516dd3b4577fd@mail.google.com>

If all you need is a reprogrammer, you can always use the hot swap trick
(Described on this list and the wiki). Or better yet, for about $25US (
http://froogle.google.com/froogle?q=bios+savior&btnG=Search ) you can get a
BIOS Savior to make the process less hazardous to your mainboard's health.
It's a piggyback device with a switch so you don't even need to remove it
once installed--Just flip the switch to go back and forth between ROMs.

On 5/30/06, Ronald G Minnich <rminnich at lanl.gov> wrote:
>
> Carl-Daniel Hailfinger wrote:
> > Ronald G Minnich wrote:
> >
> >>for OLPC, you really ought to have an FS2
> >
> >
> > Even if I only want to reflash the BIOS?
> oh. to reflash, you can use the olpc itself.
>
> ron
>
> --
> 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/20060530/1a1466ce/attachment.html>

From c-d.hailfinger.devel.2006 at gmx.net  Tue May 30 20:59:15 2006
From: c-d.hailfinger.devel.2006 at gmx.net (Carl-Daniel Hailfinger)
Date: Tue, 30 May 2006 20:59:15 +0200
Subject: [LinuxBIOS] Good JTAG debuggers?
In-Reply-To: <447C7F71.9050401@lanl.gov>
References: <447AFE65.2020705@gmx.net> <20060529200114.GA4962@coresystems.de>
	<447BCC56.30502@lanl.gov> <447C2FF9.6020800@gmx.net>
	<447C7F71.9050401@lanl.gov>
Message-ID: <447C9603.7090304@gmx.net>

Ronald G Minnich wrote:
> Carl-Daniel Hailfinger wrote:
>> Ronald G Minnich wrote:
>>
>>> for OLPC, you really ought to have an FS2
>>
>> Even if I only want to reflash the BIOS?
> 
> oh. to reflash, you can use the olpc itself.

Unless it doesn't boot. Which was the only reason I was looking for
a JTAG debugger. Do you know whether these cheap parallel port JTAG
cables are sufficient to reflash the OLPC BIOS in case I screw up
during flashing?


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



From c-d.hailfinger.devel.2006 at gmx.net  Tue May 30 21:03:27 2006
From: c-d.hailfinger.devel.2006 at gmx.net (Carl-Daniel Hailfinger)
Date: Tue, 30 May 2006 21:03:27 +0200
Subject: [LinuxBIOS] Good JTAG debuggers?
In-Reply-To: <ec9b26620605301152h5cd8f013pc5c516dd3b4577fd@mail.google.com>
References: <447AFE65.2020705@gmx.net>
	<20060529200114.GA4962@coresystems.de>	<447BCC56.30502@lanl.gov>
	<447C2FF9.6020800@gmx.net>	<447C7F71.9050401@lanl.gov>
	<ec9b26620605301152h5cd8f013pc5c516dd3b4577fd@mail.google.com>
Message-ID: <447C96FF.3040100@gmx.net>

David Hendricks wrote:
> If all you need is a reprogrammer, you can always use the hot swap trick
> (Described on this list and the wiki). Or better yet, for about $25US (
> http://froogle.google.com/froogle?q=bios+savior&btnG=Search ) you can get a
> BIOS Savior to make the process less hazardous to your mainboard's health.
> It's a piggyback device with a switch so you don't even need to remove it
> once installed--Just flip the switch to go back and forth between ROMs.

The OLPC BIOS chip is soldered on the board, so the BIOS saviour and the
hot swap trick unfortunately won't work.

Semi-OT: Does Google use LinuxBIOS? AFAICS that would be a natural fit.

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



From ollie at lanl.gov  Tue May 30 22:08:55 2006
From: ollie at lanl.gov (Li-Ta Lo)
Date: Tue, 30 May 2006 14:08:55 -0600
Subject: [LinuxBIOS] Good JTAG debuggers?
In-Reply-To: <447C96FF.3040100@gmx.net>
References: <447AFE65.2020705@gmx.net>
	<20060529200114.GA4962@coresystems.de>	<447BCC56.30502@lanl.gov>
	<447C2FF9.6020800@gmx.net>	<447C7F71.9050401@lanl.gov>
	<ec9b26620605301152h5cd8f013pc5c516dd3b4577fd@mail.google.com>
	<447C96FF.3040100@gmx.net>
Message-ID: <1149019736.21754.0.camel@logarithm.lanl.gov>

On Tue, 2006-05-30 at 21:03 +0200, Carl-Daniel Hailfinger wrote:
> David Hendricks wrote:
> > If all you need is a reprogrammer, you can always use the hot swap trick
> > (Described on this list and the wiki). Or better yet, for about $25US (
> > http://froogle.google.com/froogle?q=bios+savior&btnG=Search ) you can get a
> > BIOS Savior to make the process less hazardous to your mainboard's health.
> > It's a piggyback device with a switch so you don't even need to remove it
> > once installed--Just flip the switch to go back and forth between ROMs.
> 
> The OLPC BIOS chip is soldered on the board, so the BIOS saviour and the
> hot swap trick unfortunately won't work.
> 

The OLPC rev A should have a socket for the LPC flash rom.

> Semi-OT: Does Google use LinuxBIOS? AFAICS that would be a natural fit.
> 
> Regards,
> Carl-Daniel
> -- 
> http://www.hailfinger.org/
> 
-- 
Li-Ta Lo <ollie at lanl.gov>
Los Alamos National Lab




From juergen127 at kreuzholzen.de  Tue May 30 22:37:57 2006
From: juergen127 at kreuzholzen.de (Juergen Beisert)
Date: Tue, 30 May 2006 22:37:57 +0200
Subject: [LinuxBIOS] Question about AMD/Cyrix Geode GX1 based system
In-Reply-To: <6F7DA19D05F3CF40B890C7CA2DB13A4203094CE2@ssvlexmb2.amd.com>
References: <6F7DA19D05F3CF40B890C7CA2DB13A4203094CE2@ssvlexmb2.amd.com>
Message-ID: <200605302237.57048.juergen127@kreuzholzen.de>

Hi Yinghai,

On Tuesday 30 May 2006 18:28, Lu, Yinghai wrote:
> mkelfImage

thank you very much. You point me to the right direction. It was a simple 
pointer error in convert_parameters.c from the mkelfimage package. Now my 
kernel starts up (currently it fails when it tries to get ip configuration 
data through DHCP).

Patch attached.

Regards

Juergen
-------------- next part --------------
A non-text attachment was scrubbed...
Name: convert_params.diff
Type: text/x-diff
Size: 758 bytes
Desc: not available
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20060530/8862d811/attachment.bin>

From jg at laptop.org  Tue May 30 23:42:57 2006
From: jg at laptop.org (Jim Gettys)
Date: Tue, 30 May 2006 17:42:57 -0400
Subject: [LinuxBIOS] OLPC (One Laptop Per Child) Developer's program.
Message-ID: <1149025377.30703.141.camel@localhost.localdomain>

As you know, we've said we were going to have a developer's program. You
can find more information, including how to apply for boards at:

http://wiki.laptop.org/index.php/Developers_Program

Note that these are bare PC prototype boards, not packaged machines.
                           Jim Gettys


-- 
Jim Gettys
One Laptop Per Child





From rminnich at lanl.gov  Tue May 30 19:31:35 2006
From: rminnich at lanl.gov (Ronald G Minnich)
Date: Tue, 30 May 2006 11:31:35 -0600
Subject: [LinuxBIOS] Question about AMD/Cyrix Geode GX1 based system
In-Reply-To: <200605301233.11249.juergen127@kreuzholzen.de>
References: <200605291746.49115.juergen127@kreuzholzen.de>
	<200605291837.32099.juergen127@kreuzholzen.de>
	<447BCAE4.9050804@lanl.gov>
	<200605301233.11249.juergen127@kreuzholzen.de>
Message-ID: <447C8177.9060502@lanl.gov>

for 2.4 you want eric biederman's early printk patch, and I have it 
*somewhere*, but can't find it.

ron




From per at mellander.org  Wed May 31 09:44:33 2006
From: per at mellander.org (Per Mellander)
Date: Wed, 31 May 2006 09:44:33 +0200
Subject: [LinuxBIOS] Problem with flashrom -E  -c W49F002U
Message-ID: <20060531071946.M54760@mellander.org>

I'm experiencing problem with the flashrom utility. I have a BIOS SAVIOUR RD1-PL, and at
start it worked quite alright. I was able to flash the prom that's located on the RD1
and tried different settings in my LinuxBIOS. I was on the other hand not able to read
the contents out of the original BIOS because it was not detected properly. I have an
EPIA-MII 12000 with BIOS ver 1.35 ( bought it recently so it's quite new. ) The fact
that I couldn't read the original BIOS didn't on the other hand keep me from flashing
the part on the RD1.

The big problem now is that I'm not able to erase the flash anymore, making it quite
hard to continue developing my LinuxBIOS.

# flashrom -E'

Calibrating delay loop... ok
No LinuxBIOS table found.
Enabling flash write on VT8235...OK
W49F002U found at physical address: 0xfffc0000
Flash part is W49F002U
Erasing flash chip

but when I read it back it's not empty.

# flashrom -r test.bin
Calibrating delay loop... ok
No LinuxBIOS table found.
Enabling flash write on VT8235...OK
W49F002U found at physical address: 0xfffc0000
Flash part is W49F002U
Reading Flash...done

# hexdump test.bin | head -1
0000000 aa55 e970 7ffc 1b8b de34 83ca 0000 0000


# flashrom -E -V

Calibrating delay loop... Setting up microsecond timing loop
170M loops per second
ok
No LinuxBIOS table found.
Enabling flash write on VT8235...OK
Trying Am29F040B, 512 KB
probe_29f040b: id1 0xff, id2 0xff
Trying Am29F016D, 2048 KB
probe_29f040b: id1 0xff, id2 0xff
Trying At29C040A, 512 KB
probe_jedec: id1 0xff, id2 0xff
Trying Mx29f002, 256 KB
probe_29f002: id1 0xda, id2 0xb
Trying SST29EE020A, 256 KB
probe_jedec: id1 0xda, id2 0xb
Trying SST28SF040A, 512 KB
probe_28sf040: id1 0xff, id2 0xff
Trying SST39SF020A, 256 KB
probe_jedec: id1 0xda, id2 0xb
Trying SST39VF020, 256 KB
probe_jedec: id1 0xda, id2 0xb
Trying SST49LF040B, 512 KB
probe_jedec: id1 0xff, id2 0xff
Trying SST49LF040, 512 KB
probe_jedec: id1 0xff, id2 0xff
Trying SST49LF080A, 1024 KB
probe_jedec: id1 0xff, id2 0xff
Trying SST49LF002A/B, 256 KB
probe_jedec: id1 0xda, id2 0xb
Trying SST49LF003A/B, 384 KB
probe_jedec: id1 0xff, id2 0xff
Trying SST49LF004A/B, 512 KB
probe_jedec: id1 0xff, id2 0xff
Trying SST49LF008A, 1024 KB
probe_jedec: id1 0xff, id2 0xff
Trying Pm49FL004, 512 KB
probe_jedec: id1 0xff, id2 0xff
Trying W29C011, 128 KB
probe_jedec: id1 0xda, id2 0xb
Trying W29C020C, 256 KB
probe_jedec: id1 0x55, id2 0xaa
Trying W49F002U, 256 KB
probe_jedec: id1 0x55, id2 0xaa
Trying W39V040A, 512 KB
probe_jedec: id1 0xff, id2 0xff
Trying M29F040B, 512 KB
probe_29f040b: id1 0xff, id2 0xff
Trying M29F400BT, 512 KB
probe_m29f400bt: id1 0xff, id2 0xff
Trying 82802ab, 512 KB
probe_82802ab: id1 0xff, id2 0xff
Trying 82802ac, 1024 KB
probe_82802ab: id1 0xff, id2 0xff
Trying LHF00L04, 1024 KB
probe_lhf00l04: id1 0xff, id2 0xff
No EEPROM/flash device found.

which I find quite peculiar.

Why don't I get a success only because I've put on '-V'?

So I tried:

# flashrom -E -V -c W49F002U
Calibrating delay loop... Setting up microsecond timing loop
170M loops per second
ok
No LinuxBIOS table found.
Enabling flash write on VT8235...OK
Trying W49F002U, 256 KB
probe_jedec: id1 0x55, id2 0xaa
No EEPROM/flash device found.

Still the same problem!

Anyone that's have a hint why? I remember that when I started using the RD1-PL I noticed
that if I did a 'verify' after 'write' it said that it didn't match. On the other hand
was it the first time I flashed the device and if i read the flash I could see that it
had been flashed by doing a 'hexdump -C' and verify it by looking for the string section .

# hexdump -C test.bin | grep Linux | head -1
0001a800  00 4c 69 6e 75 78 42 49  4f 53 00 41 74 74 65 6d  |.LinuxBIOS.Attem|

My hair turns grey...








From a.borisov at tesv.tmb.ru  Wed May 31 09:56:16 2006
From: a.borisov at tesv.tmb.ru (Anton Borisov)
Date: Wed, 31 May 2006 11:56:16 +0400
Subject: [LinuxBIOS] Problem with flashrom -E  -c W49F002U
In-Reply-To: <20060531071946.M54760@mellander.org>
References: <20060531071946.M54760@mellander.org>
Message-ID: <20060531115616.4d727d9e.a.borisov@tesv.tmb.ru>

On Wed, 31 May 2006 09:44:33 +0200
"Per Mellander" <per at mellander.org> wrote:

> I'm experiencing problem with the flashrom utility. I have a BIOS SAVIOUR RD1-PL, and at
> start it worked quite alright. I was able to flash the prom that's located on the RD1
> and tried different settings in my LinuxBIOS. I was on the other hand not able to read
> the contents out of the original BIOS because it was not detected properly. I have an
> EPIA-MII 12000 with BIOS ver 1.35 ( bought it recently so it's quite new. ) The fact
> that I couldn't read the original BIOS didn't on the other hand keep me from flashing
> the part on the RD1.
> 
> The big problem now is that I'm not able to erase the flash anymore, making it quite
> hard to continue developing my LinuxBIOS.

	Wait, which kind of IC (manufacturer) have you inserted as a 'mirror'?


-Anton



From per at mellander.org  Wed May 31 14:53:19 2006
From: per at mellander.org (Per Mellander)
Date: Wed, 31 May 2006 14:53:19 +0200
Subject: [LinuxBIOS] EPIA-MII 12000, almost there.  ( newbie )
In-Reply-To: <01M30Z805DVY8YBMSF@EMAIL1.BYU.EDU>
References: <20060530065020.M85269@mellander.org>
	<01M30Z805DVY8YBMSF@EMAIL1.BYU.EDU>
Message-ID: <20060531124452.M69985@mellander.org>

Now I get so far that the kernel is identified and loaded but then it breaks :(

I created an elf with mkelfImage:

# mkelfImage --kernel=/vmlinuz-2.6.16-1.2111_FC5 --output=/vmlinuz.elf
--initrd=/initrd-2.6.16-1.2111_FC5.img --command-line="ro root=LABEL=/ rhgb quiet
console=ttyS0 console=ttyS0,115200"

----8<-------------------------------------------------------------

Jumping to boot code at 0x109ad4
FILO version 0.5 (root at mm.int.mmtab.se) Wed May 31 13:44:15 CEST 2006
Press <Enter> for default boot, or <Esc> for boot prompt... timed out
boot: hda1:/vmlinuz.elf
find_ide_controller: found PCI IDE controller 1106:0571 prog_if=0x8a
find_ide_controller: primary channel: compatibility mode
find_ide_controller: cmd_base=0x1f0 ctrl_base=0x3f4
ide_software_reset: Waiting for ide0 to become ready for reset... ok
init_drive: Testing for hda
init_drive: Probing for hda
init_drive: LBA mode, sectors=268435455
init_drive: LBA48 mode, sectors=321672960
init_drive: Init device params... ok
hda: LBA48 164GB: HDS722516VLAT80                        
Mounted ext2fs
Loading Linux version 2.6.16-1.2111_FC5 (bhcompile at hs20-bc1-3.build.redhat.com) #1 Thu
May 4 21:16:58 EDT 2006...
Jumping to entry point...
0

LinuxBIOS-1.1.8.0Fallback Wed May 31 13:15:25 CEST 2006 starting...
Enabling mainboard devices
Enabling shadow ram

----8<------------------------------------------------------------- 

I get the same result when I try,

AUTOBOOT_FILE = "hda1:/vmlinuz initrd=/initrd.img root=/dev/hda1 console=tty0
console=ttyS0,115200"

so the problem is not in the elf image.

Could you please send me a snippet from your AUTOBOOT or similar?

Btw. Do I have to make a 'special' kernel to make this work or should the stock FC5 work?

/Per

On Tue, 30 May 2006 08:38:53 -0600, Myles Watson wrote
> Did you try using mkelfImage from ftp://ftp.lnxi.com/pub/mkelfImage ? It
> combines the vmlinuz & initrd files into one.
> 
> To get my machine to boot I used the same kernel parameters as I found in
> grub, set up by Fedora.
> 




From myles at pel.cs.byu.edu  Wed May 31 15:56:44 2006
From: myles at pel.cs.byu.edu (Myles Watson)
Date: Wed, 31 May 2006 07:56:44 -0600
Subject: [LinuxBIOS] EPIA-MII 12000, almost there.  ( newbie )
Message-ID: <01M32C24KYG48YB0Y3@EMAIL1.BYU.EDU>


I used the stock FC4 kernel with the same command line as you used. My
autoboot was just hdb1:/linux_2.6.16.elf (I have a CD-ROM as hda)

Good luck,

Myles

-----Original Message-----
From: linuxbios-bounces at linuxbios.org
[mailto:linuxbios-bounces at linuxbios.org] On Behalf Of Per Mellander
Sent: Wednesday, May 31, 2006 6:53 AM
To: myles at mouselemur.cs.byu.edu
Cc: linuxbios at linuxbios.org
Subject: Re: [LinuxBIOS] EPIA-MII 12000, almost there. ( newbie )

Now I get so far that the kernel is identified and loaded but then it breaks
:(

I created an elf with mkelfImage:

# mkelfImage --kernel=/vmlinuz-2.6.16-1.2111_FC5 --output=/vmlinuz.elf
--initrd=/initrd-2.6.16-1.2111_FC5.img --command-line="ro root=LABEL=/ rhgb
quiet
console=ttyS0 console=ttyS0,115200"

----8<-------------------------------------------------------------

Jumping to boot code at 0x109ad4
FILO version 0.5 (root at mm.int.mmtab.se) Wed May 31 13:44:15 CEST 2006
Press <Enter> for default boot, or <Esc> for boot prompt... timed out
boot: hda1:/vmlinuz.elf
find_ide_controller: found PCI IDE controller 1106:0571 prog_if=0x8a
find_ide_controller: primary channel: compatibility mode
find_ide_controller: cmd_base=0x1f0 ctrl_base=0x3f4
ide_software_reset: Waiting for ide0 to become ready for reset... ok
init_drive: Testing for hda
init_drive: Probing for hda
init_drive: LBA mode, sectors=268435455
init_drive: LBA48 mode, sectors=321672960
init_drive: Init device params... ok
hda: LBA48 164GB: HDS722516VLAT80                        
Mounted ext2fs
Loading Linux version 2.6.16-1.2111_FC5
(bhcompile at hs20-bc1-3.build.redhat.com) #1 Thu
May 4 21:16:58 EDT 2006...
Jumping to entry point...
0

LinuxBIOS-1.1.8.0Fallback Wed May 31 13:15:25 CEST 2006 starting...
Enabling mainboard devices
Enabling shadow ram

----8<------------------------------------------------------------- 

I get the same result when I try,

AUTOBOOT_FILE = "hda1:/vmlinuz initrd=/initrd.img root=/dev/hda1
console=tty0
console=ttyS0,115200"

so the problem is not in the elf image.

Could you please send me a snippet from your AUTOBOOT or similar?

Btw. Do I have to make a 'special' kernel to make this work or should the
stock FC5 work?

/Per

On Tue, 30 May 2006 08:38:53 -0600, Myles Watson wrote
> Did you try using mkelfImage from ftp://ftp.lnxi.com/pub/mkelfImage ? It
> combines the vmlinuz & initrd files into one.
> 
> To get my machine to boot I used the same kernel parameters as I found in
> grub, set up by Fedora.
> 


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