I'm still trying to get LinuxBIOS booting on my Tyan S2462 board, and encountering some problems.
This is with mkelfImage-1.17, binutils 2.13.90.0.2, etherboot-5.1.0.eb1, and LinuxBIOS from CVS.
[ Building the LinuxBIOS CVS tree requires: perl -ni -e 'print if !/secondary.inc/' src/mainboard/tyan/guiness/Config perl -pi -e 's/w832627hf/w83627hf/' src/mainboard/tyan/guiness/mainboard.c ]
What I've done is produce a "normal" and a "fallback" romimage, catenated them together, and written the whole 512kB to the flash chip. [ At first glance I couldn't grok the whole fallback logic. ]
Normal:
option USE_FALLBACK_IMAGE=0 option ROM_SIZE=524288 option ROM_IMAGE_SIZE=65536
Fallback:
option USE_FALLBACK_IMAGE=1 option ROM_SIZE=524288 option ROM_IMAGE_SIZE=45056
I tried several kernels with/without ramdisk; same results. At this point the sun was coming up and it was time to go to work. :-/
The boot log follows.
Regards,
Bill Rugolsky
====
LinuxBIOS-1.0.0 Wed Nov 13 00:17:27 EST 2002 starting... LinuxBIOS-1.0.0 Wed Nov 13 00:17:27 EST 2002 booting... Finding PCI configuration type. handle_superio port 0x0, defaultport 0x2e handle_superio Using port 0x2e Scanning PCI bus...done Allocating PCI resources...done. Enabling PCI resourcess...done. Initializing PCI devices... PCI devices initialized totalram: 1024M Initializing CPU #1 Enabling cache...done. Setting up local apic...done. CPU #1 Initialized clocks_per_usec: 1152 Initializing CPU #0 handle_superio port 0x2e, defaultport 0x2e handle_superio Using port 0x2e Enabling cache...done. Setting up local apic...done. CPU #0 Initialized handle_superio port 0x2e, defaultport 0x2e handle_superio Using port 0x2e
Welcome to elfboot, the open sourced starter. January 2002, Eric Biederman. Version 1.2
Searching for 16 byte tags 63:rom_read_bytes() - overflowed source buffer. max_block = 0 init_bytes found 0 tags ROM segment 0x0000 length 0x0000 reloc 0x9400 clocks_per_tick = 753184 Etherboot 5.1.0.eb1 (GPL) ELF (Multiboot) for [3C90X] Boot from (N)etwork or from (L)ocal? N Found 3Com980-Cyclone at 0x1C00, ROM address 0x0000 Probing...[3C90X] The PCI BIOS has not enabled this device! Updating PCI command 0003->0007. pci_bus 0000 pci_device_fn 0078
3C90X Driver 2.00 Copyright 1999 LightSys Technology Services, Inc. Portions Copyright 1999 Steve Smith Provided with ABSOLUTELY NO WARRANTY. ------------------------------------------------------------------------------- MAC Address = 00:E0:81:03:4A:31 Connectors present: 10Base-T / 100Base-TX. Searching for server (DHCP)... -\Me: 192.168.0.251, Server: 192.168.0.1, Gateway 192.168.0.1 Loading 192.168.0.1:kernel |/-(ELF)... No base memory found assuming 640K segment exceeding memory Unable to load file. <sleep> <abort> Issuing RESET: Boot from (N)etwork or from (L)ocal? N Found 3Com980-Cyclone at 0x1C00, ROM address 0x0000 Probing...[3C90X]
3C90X Driver 2.00 Copyright 1999 LightSys Technology Services, Inc. Portions Copyright 1999 Steve Smith Provided with ABSOLUTELY NO WARRANTY. ------------------------------------------------------------------------------- MAC Address = 00:E0:81:03:4A:31 Connectors present: 10Base-T / 100Base-TX. Searching for server (DHCP)... \|/-\|/Me: 192.168.0.251, Server: 192.168.0.1, Gateway 192.168.0.1 Loading 192.168.0.1:kernel -\|/(ELF)... segment exceeding memory Unable to load file. <sleep> <abort> Issuing RESET: Boot from (N)etwork or from (L)ocal? N Found 3Com980-Cyclone at 0x1C00, ROM address 0x0000 Probing...[3C90X]
I'll try to look at this but my time is consumed with SC 2002, so it will have to wait until later next week.
It does seem that the compressed bios stuff has made linuxbios very unstable at the moment. You could try disabling it -- it worked for Andrew Ip. See the earlier note.
I don't want to upgrade my tree at present as I have things that need to work next week.
ron
Greetings,
I don't think it's the compression here. I have a working BIOS built from CVS on 11/05/2002. I don't think it matters to this, but I did hack zkernel_start on the fallback image to be fff00000 and modify the linker script to hard code the primary image at fffe0000 - 8.
I can look at it closer when I get into the office today.
G'day, sjames
On Wed, 13 Nov 2002, Ronald G. Minnich wrote:
I'll try to look at this but my time is consumed with SC 2002, so it will have to wait until later next week.
It does seem that the compressed bios stuff has made linuxbios very unstable at the moment. You could try disabling it -- it worked for Andrew Ip. See the earlier note.
I don't want to upgrade my tree at present as I have things that need to work next week.
ron
Linuxbios mailing list Linuxbios@clustermatic.org http://www.clustermatic.org/mailman/listinfo/linuxbios
On Thu, Nov 14, 2002 at 08:17:21AM -0500, steven james wrote:
I don't think it's the compression here. I have a working BIOS built from CVS on 11/05/2002. I don't think it matters to this, but I did hack zkernel_start on the fallback image to be fff00000 and modify the linker script to hard code the primary image at fffe0000 - 8.
OK, well I was doing a bunch of things wrong. But I'm getting closer.
First, CVS is using the linuxbios table, but Eric's etherboot-5.1.0 patch does not include it. It is in the 5.0.5 patchset.
Doing that, etherboot loads the kernel, and jumps to it. I've applied Eric's linux-2.4.18-pre7.linuxbios.diff on top of 2.4.20-rc1.
The mkelfImage-1.18 startup code prints "LinuxBIOS" and then does nothing.
Should I be applying a more recent patch to my kernel? Do I need other patches?
My next step is to sprinkle the mkelfImage header with debugging puts() and the kernel startup with early_printk.
Thanks for your help.
-Bill
Greetings,
Hrmm, the kernel should be in control by that point. The most likely problems are kernel compiled fro wrong processor type, and not passing console=ttyS0,115200n8 (or whatever speed you're using) to the kernel (using mkelfImage's --command-line switch).
G'day, sjames
On Thu, 14 Nov 2002, Bill Rugolsky Jr. wrote:
On Thu, Nov 14, 2002 at 08:17:21AM -0500, steven james wrote:
I don't think it's the compression here. I have a working BIOS built from CVS on 11/05/2002. I don't think it matters to this, but I did hack zkernel_start on the fallback image to be fff00000 and modify the linker script to hard code the primary image at fffe0000 - 8.
OK, well I was doing a bunch of things wrong. But I'm getting closer.
First, CVS is using the linuxbios table, but Eric's etherboot-5.1.0 patch does not include it. It is in the 5.0.5 patchset.
Doing that, etherboot loads the kernel, and jumps to it. I've applied Eric's linux-2.4.18-pre7.linuxbios.diff on top of 2.4.20-rc1.
The mkelfImage-1.18 startup code prints "LinuxBIOS" and then does nothing.
Should I be applying a more recent patch to my kernel? Do I need other patches?
My next step is to sprinkle the mkelfImage header with debugging puts() and the kernel startup with early_printk.
Thanks for your help.
-Bill
On Fri, 15 Nov 2002, steven james wrote:
Hrmm, the kernel should be in control by that point. The most likely problems are kernel compiled fro wrong processor type, and not passing console=ttyS0,115200n8 (or whatever speed you're using) to the kernel (using mkelfImage's --command-line switch).
if you are seeing 98/99 posts, the kernel is in the idle loop.
The odds are good that you don't have a serial console compiled in, OR you have vga test console compiled in, OR you did't give the console= switches james mentioned.
I am actually running a smartcore-p3 right now that doesn't output anything after boot, and it turned out I forgot to put in a serial console. Happens to me about once a month.
ron
I got LinuxBIOS booted on the Tyan S2462 this morning, using:
LinuxBIOS CVS + compile fixes CONFIG_COMPRESS=0 (haven't tested CONFIG_COMPRESS=1 yet) etherboot-5.0.7 3c9805.ebi mkelfImage-1.18 Linux-2.4.20-rc1 RedHat 8 (gcc-3.2 and 2.13.*)
Lack of understanding + outdated tools (downloaded a while back) complicated things enormously. It helps if one Read[s] The Fine Source.
HOWTO for Dummies (I'm overqualified :-)) to follow.
Thanks.
Bill Rugolsky
LinuxBIOS CVS + compile fixes CONFIG_COMPRESS=0 (haven't tested CONFIG_COMPRESS=1 yet) etherboot-5.0.7 3c9805.ebi mkelfImage-1.18 Linux-2.4.20-rc1 RedHat 8 (gcc-3.2 and 2.13.*)
.ebi -- is that just the .rom file? or is it an elf image? I was following the howto mentioned at http://www.missl.cs.umd.edu/archives/linuxbios/msg11992.html and they have etherboot making an elf image for natsemi without the use of mkelfimage (I think).
Regards, Andrew
On Fri, Nov 15, 2002 at 09:26:13AM -0500, Andrew Kohlsmith wrote:
LinuxBIOS CVS + compile fixes CONFIG_COMPRESS=0 (haven't tested CONFIG_COMPRESS=1 yet) etherboot-5.0.7 3c9805.ebi mkelfImage-1.18 Linux-2.4.20-rc1 RedHat 8 (gcc-3.2 and 2.13.*)
.ebi -- is that just the .rom file?
no
or is it an elf image?
yes.
I was following the howto mentioned at http://www.missl.cs.umd.edu/archives/linuxbios/msg11992.html and they have etherboot making an elf image for natsemi without the use of mkelfimage (I think).
Simply comment out PCBIOS and uncomment -DLINUXBIOS line in Config. (I used the attached patch), then
make bin32/3c9805.ebi
Regards,
Bill Rugolsky
Bill, it sounds like gcc 3.2 + linuxbios worked for you? if so, that is good news.
ron
On Fri, Nov 15, 2002 at 07:51:34AM -0700, Ronald G. Minnich wrote:
Bill, it sounds like gcc 3.2 + linuxbios worked for you? if so, that is good news.
Yes. The only 3.2 nit was annoying warnings compiling etherboot-5.0.7; changing -m flags to -f, does the trick, i.e.,
@@ -316,7 +316,7 @@ # Otherwise use -O2 (under no circumstance use -O3 or above!). CFLAGS32+= -Os -ffreestanding -fstrength-reduce -fomit-frame-pointer -mcpu=i386 # Squeeze the code in as little space as possible. -CFLAGS32+= -malign-jumps=1 -malign-loops=1 -malign-functions=1 +CFLAGS32+= -falign-jumps=1 -falign-loops=1 -falign-functions=1 CFLAGS32+= -Wall -W -Wno-format -Wno-unused ASFLAGS32= LDFLAGS32+= -N -Ttext $(RELOCADDR) -e _start
-
Andrew Kohlsmith -
Bill Rugolsky Jr. -
Ronald G. Minnich -
steven james