I *think* I did this right. I'm getting a 64k linuxbios.rom and a 512k romimage file. I'm using 2.4.19 with the SIS patch (as per the SBC710 port doc).
If I run the bios inside of bochs, I get a segfault (yes, bochs crashes!) after saying "prefetch: running in bogus memory". It does this for either the 64k rom image or the 512k one.
Now my biggest concern is that the target board has a 256k flash device. I don't think I can fit 512k into 256k. :-)
I'm using the digitallogic smartcore-p5 as a guide, as my target board is also a 430tx-based board. I've written an SMC FDC37n958fr super io intializer (based on the 37c67x) but otherwise they're pretty similar.
My intention is to use the LinuxBIOS to either boot a real kernel using etherboot (I have to compile in PCMCIA then though) or to boot from a IDE-attached CompactFlash card.
At this stage in the game my kernel is pared down just about as much as I can think to do it. no VT (serial console only), IDE, direct PCI and that's about it.
Am I missing something?
Regards, Andrew
Hello from Gregg C Levine That problem with Bochs, happens to me, all the time, and I am trying my best to get a 440FX image to work there. Can you send me a copy of the src file that you chose to create, for the 440FX? Off line. ------------------- Gregg C Levine hansolofalcon@worldnet.att.net ------------------------------------------------------------ "The Force will be with you...Always." Obi-Wan Kenobi "Use the Force, Luke." Obi-Wan Kenobi (This company dedicates this E-Mail to General Obi-Wan Kenobi ) (This company dedicates this E-Mail to Master Yoda )
-----Original Message----- From: linuxbios-admin@clustermatic.org [mailto:linuxbios- admin@clustermatic.org] On Behalf Of Andrew Kohlsmith Sent: Wednesday, November 13, 2002 9:14 PM To: linuxbios@clustermatic.org Subject: Can't get a rom image below 512k?
I *think* I did this right. I'm getting a 64k linuxbios.rom and a
512k
romimage file. I'm using 2.4.19 with the SIS patch (as per the SBC710
port
doc).
If I run the bios inside of bochs, I get a segfault (yes, bochs
crashes!)
after saying "prefetch: running in bogus memory". It does this for
either
the 64k rom image or the 512k one.
Now my biggest concern is that the target board has a 256k flash
device. I
don't think I can fit 512k into 256k. :-)
I'm using the digitallogic smartcore-p5 as a guide, as my target board
is also
a 430tx-based board. I've written an SMC FDC37n958fr super io
intializer
(based on the 37c67x) but otherwise they're pretty similar.
My intention is to use the LinuxBIOS to either boot a real kernel
using
etherboot (I have to compile in PCMCIA then though) or to boot from a IDE-attached CompactFlash card.
At this stage in the game my kernel is pared down just about as much
as I can
think to do it. no VT (serial console only), IDE, direct PCI and
that's
about it.
Am I missing something?
Regards, Andrew _______________________________________________ Linuxbios mailing list Linuxbios@clustermatic.org http://www.clustermatic.org/mailman/listinfo/linuxbios
That problem with Bochs, happens to me, all the time, and I am trying my best to get a 440FX image to work there. Can you send me a copy of the src file that you chose to create, for the 440FX? Off line.
Hmm so does this mean the kernel is likely alright?
I'm building for 430tx, BTW. I can send you what I have but it's not for the 440fx.
Regards, Andrew
Hello from Gregg C Levine It will work. I don't think your kernel is flakey. If anything, I think the problem is elsewhere. And I think the fault is in the simulator, but I can't get the Bochs team to agree one way, or the other, with my suggestions regarding this project. Yes, please do. ------------------- Gregg C Levine hansolofalcon@worldnet.att.net ------------------------------------------------------------ "The Force will be with you...Always." Obi-Wan Kenobi "Use the Force, Luke." Obi-Wan Kenobi (This company dedicates this E-Mail to General Obi-Wan Kenobi ) (This company dedicates this E-Mail to Master Yoda )
-----Original Message----- From: linuxbios-admin@clustermatic.org [mailto:linuxbios- admin@clustermatic.org] On Behalf Of Andrew Kohlsmith Sent: Wednesday, November 13, 2002 10:24 PM To: linuxbios@clustermatic.org Subject: Re: Can't get a rom image below 512k?
That problem with Bochs, happens to me, all the time, and I am
trying my
best to get a 440FX image to work there. Can you send me a copy of
the
src file that you chose to create, for the 440FX? Off line.
Hmm so does this mean the kernel is likely alright?
I'm building for 430tx, BTW. I can send you what I have but it's not
for the
440fx.
Regards, Andrew _______________________________________________ Linuxbios mailing list Linuxbios@clustermatic.org http://www.clustermatic.org/mailman/listinfo/linuxbios
It will work. I don't think your kernel is flakey. If anything, I think the problem is elsewhere. And I think the fault is in the simulator, but I can't get the Bochs team to agree one way, or the other, with my suggestions regarding this project. Yes, please do.
I traced through my rom image. at t=511471, the BIOS jumps to 10:4000 (selector 16 starts at 0, so it's jumping into very low memory, where it was busy putting something earlier. I think it was decompressing something there from the looks of the trace and the map file.)
Once at 0x04000, it outputx 0x13 to port 0x80 and seems to commit suicide shortly thereafter.
I'll send you what I have offlist.
Regards, Andrew
On Wed, 13 Nov 2002, Andrew Kohlsmith wrote:
Once at 0x04000, it outputx 0x13 to port 0x80 and seems to commit suicide shortly thereafter.
Can you disassemble what is at 0x4000? this is beginning to sound like a decompressor isssue?
ron
On Wed, 13 Nov 2002, Andrew Kohlsmith wrote:
I *think* I did this right. I'm getting a 64k linuxbios.rom and a 512k romimage file. I'm using 2.4.19 with the SIS patch (as per the SBC710 port doc).
I missed something, is your kernel in the 512k romimage?
Now my biggest concern is that the target board has a 256k flash device. I don't think I can fit 512k into 256k. :-)
so you'll need etherboot.
I'm using the digitallogic smartcore-p5 as a guide, as my target board is also a 430tx-based board. I've written an SMC FDC37n958fr super io intializer (based on the 37c67x) but otherwise they're pretty similar.
the smartcore-p5 I think builds a 256KB romimage.
My intention is to use the LinuxBIOS to either boot a real kernel using etherboot (I have to compile in PCMCIA then though) or to boot from a IDE-attached CompactFlash card.
IDE-attached CF works now for me on several platforms.
I'm intrigued though, how small is your kernel again?
Are you sure that a 512KB flash won't work in your board? the address lines might be there.
ron
It will work. I don't think your kernel is flakey. If anything, I think the problem is elsewhere. And I think the fault is in the simulator, but I can't get the Bochs team to agree one way, or the other, with my suggestions regarding this project. Yes, please do.
Oops... It doesn't commit suicide when at 0x04000; it is doing more unpacking. I am now tracing it printing "LinuxBIOS", trying to see where it *does* jump off in to never-never land, eventually tripping bochs out by going over my memory size.
Yes, I figured out why it was giving me that error -- just after returning from the PCI mapping (it prints the string "PCI: pci_scan_bus for bus %d" (I guess I'm in a printf()), it tries jumping to a far pointer but fails. (the pointer points to 0x0000, which (I think) is the GDT, followed by a whole lot of nuthin'. :-) I've included a bit of the trace at the end of this email.
The crash always occured at the 16M mark, where is what I have my RAM size set to. I guess there was enough random data in RAM that got it to jump over the RAM image and continue on to the end of RAM.
Regards, Andrew
(0).[545025] 0010:00007246 (unknown context): 55: push EBP (0).[545026] 0010:00007247 (unknown context): 89e5: mov EBP, ESP (0).[545027] 0010:00007249 (unknown context): ff7514: push SS:[EBP + 14] (0).[545028] 0010:0000724c (unknown context): 0fb64510: movzx EAX, SS:[EBP + 10] (0).[545029] 0010:00007250 (unknown context): 50: push EAX (0).[545030] 0010:00007251 (unknown context): 0fb6450c: movzx EAX, SS:[EBP + 0C] (0).[545031] 0010:00007255 (unknown context): 50: push EAX (0).[545032] 0010:00007256 (unknown context): 0fb64508: movzx EAX, SS:[EBP + 08] (0).[545033] 0010:0000725a (unknown context): 50: push EAX (0).[545034] 0010:0000725b (unknown context): a140b50000: mov EAX, [DS:0000B540] (0).[545035] 0010:00007260 (unknown context): ff5008: call DS:[EAX + 08] (0).[545036] 0010:00000000 (unknown context): 0201: add AL, DS:[ECX] (0).[545037] 0010:00000002 (unknown context): 0000: add DS:[EAX], AL
I missed something, is your kernel in the 512k romimage?
Was. I've now removed it and have a 64k rom image (no payload, I must get etherboot + IDE into the payload as an elf image [yes, I *have* been scouring the mailing lists!]).
Incidentally, I'm running as 2.11.90.0.19 and compiling etherboot 5.0.6 + the IDE boot patch found on the list causes problems:
$ make gcc -E -Wp,-Wall -DASK_BOOT=3 -DANS_DEFAULT=ANS_NETWORK -DMOTD -DIMAGE_MENU -DBACKOFF_LIMIT=7 -DCONGESTED -DLINUXBIOS -DCONFIG_TSC_CURRTICKS -DCONSOLE_SERIAL -DCOMCONSOLE=0x3f8 -DCOMPRESERVE -DCONFIG_PCI_DIRECT -DELF_IMAGE -DPOLLED_IDE -Os -ffreestanding -fstrength-reduce -fomit-frame-pointer -mcpu=i386 -malign-jumps=1 -malign-loops=1 -malign-functions=1 -Wall -W -Wno-format -Wno-unused -DVERSION_MAJOR=5 -DVERSION_MINOR=0 -DVERSION="5.0.6" -DRELOC=0x400000 start32.S | as -o bin32/start32.o {standard input}: Assembler messages: {standard input}:87: Warning: indirect ljmp without `*' {standard input}:197: Error: suffix or operands invalid for `ljmp' make: *** [bin32/start32.o] Error 1
I'm going to upgrade as tomorrow and see if that helps. as sure is a bicky bugger.
Now my biggest concern is that the target board has a 256k flash device. I don't think I can fit 512k into 256k. :-)
so you'll need etherboot.
*nod* -- I got that figured out this evening. :-)
the smartcore-p5 I think builds a 256KB romimage.
Yes, I was using config.example instead of config.etherboot. My config file (attached) is currently payload-less, but I am trying to get etherboot+ide on it.
I'm intrigued though, how small is your kernel again?
Are you sure that a 512KB flash won't work in your board? the address lines might be there.
heh, the kernel isn't very useful, but the bzImage is 360625 bytes. Just IDE + serial console ATM (no networking support). I think it was just over 400k with networking support.
Is there a location where I can find out what all the options are and what they mean? I haven't been able to locate any documentation to that effect yet. Similarly, is there a clear distinction between the Config and config files?
Regards, Andrew Regards, Andrew
can you send teh serial output too?
ron
On Thu, 14 Nov 2002, Andrew Kohlsmith wrote:
heh, the kernel isn't very useful, but the bzImage is 360625 bytes. Just IDE
- serial console ATM (no networking support). I think it was just over 400k
with networking support.
wow. 2.4 sure did start to grow, but I'd still like a copy of that .config
Is there a location where I can find out what all the options are and what they mean? I haven't been able to locate any documentation to that effect yet. Similarly, is there a clear distinction between the Config and config files?
Ah, yes, the options. On the todo list: build a web page with all the options and what they mean. And fix all those option names that are config dependent with a CONFIG_ prefix so you can tell. Sorry.
Config files are in directories in the src tree and describe how to use and build the .c files in that directory. Config files can pull in Config files from other places.
The config.example etc. are top-level files which are handed to the NLBConfig tool (New Linux Bios Config) and which start the process of building a build directory.
ron
I'm going to upgrade as tomorrow and see if that helps. as sure is a bicky bugger.
Bicky? *P*icky. :-)
Regards, Andrew
Greetings,
If all else fails, it should be possable to generate an image by just concatenating the etherboot .elf binary, some padding, and the two linuxbios.strip binaries together.
recent objdump (that supports i8086 arch) with -D (disassemble all) can help to see where the pieces should go. Just remember that the top of the rom will appear at f0000 at boot time in real mode. Once it gets through __protected_start, you'll be up at the top of memory in i386 arch (ffffxxxx or in primary linuxbios at fffexxxx). One of these days, I'll need to write this up :-)
G'day, sjames
On Thu, 14 Nov 2002, Andrew Kohlsmith wrote:
I missed something, is your kernel in the 512k romimage?
Was. I've now removed it and have a 64k rom image (no payload, I must get etherboot + IDE into the payload as an elf image [yes, I *have* been scouring the mailing lists!]).
Incidentally, I'm running as 2.11.90.0.19 and compiling etherboot 5.0.6 + the IDE boot patch found on the list causes problems:
$ make gcc -E -Wp,-Wall -DASK_BOOT=3 -DANS_DEFAULT=ANS_NETWORK -DMOTD -DIMAGE_MENU -DBACKOFF_LIMIT=7 -DCONGESTED -DLINUXBIOS -DCONFIG_TSC_CURRTICKS -DCONSOLE_SERIAL -DCOMCONSOLE=0x3f8 -DCOMPRESERVE -DCONFIG_PCI_DIRECT -DELF_IMAGE -DPOLLED_IDE -Os -ffreestanding -fstrength-reduce -fomit-frame-pointer -mcpu=i386 -malign-jumps=1 -malign-loops=1 -malign-functions=1 -Wall -W -Wno-format -Wno-unused -DVERSION_MAJOR=5 -DVERSION_MINOR=0 -DVERSION="5.0.6" -DRELOC=0x400000 start32.S | as -o bin32/start32.o {standard input}: Assembler messages: {standard input}:87: Warning: indirect ljmp without `*' {standard input}:197: Error: suffix or operands invalid for `ljmp' make: *** [bin32/start32.o] Error 1
I'm going to upgrade as tomorrow and see if that helps. as sure is a bicky bugger.
Now my biggest concern is that the target board has a 256k flash device. I don't think I can fit 512k into 256k. :-)
so you'll need etherboot.
*nod* -- I got that figured out this evening. :-)
the smartcore-p5 I think builds a 256KB romimage.
Yes, I was using config.example instead of config.etherboot. My config file (attached) is currently payload-less, but I am trying to get etherboot+ide on it.
I'm intrigued though, how small is your kernel again?
Are you sure that a 512KB flash won't work in your board? the address lines might be there.
heh, the kernel isn't very useful, but the bzImage is 360625 bytes. Just IDE
- serial console ATM (no networking support). I think it was just over 400k
with networking support.
Is there a location where I can find out what all the options are and what they mean? I haven't been able to locate any documentation to that effect yet. Similarly, is there a clear distinction between the Config and config files?
Regards, Andrew Regards, Andrew _______________________________________________ Linuxbios mailing list Linuxbios@clustermatic.org http://www.clustermatic.org/mailman/listinfo/linuxbios
wow. 2.4 sure did start to grow, but I'd still like a copy of that .config
Indeed. Attached is my kernel .config and my toplevel configuration file for the Dauphin Orasis model 1.
Ah, yes, the options. On the todo list: build a web page with all the options and what they mean. And fix all those option names that are config dependent with a CONFIG_ prefix so you can tell. Sorry.
heh, no problem. In the meantime, is it possible for me to pick through NLBConfig and glean the easier ones? I haven't looked at the source for NLBConfig yet, so I may be asking a dumb question here. :-)
Config files are in directories in the src tree and describe how to use and build the .c files in that directory. Config files can pull in Config files from other places.
Ok so am I correct in assuming that since there are on Config files in any of the superio/SMC/ directories that the superio.c file is not used at all? I based my fdc37n958fr configuration off of the fdc37c67x's configuration, but did not bother with the superio.c since it went off on an entirely different tangent. (enable PNP?)
The config.example etc. are top-level files which are handed to the NLBConfig tool (New Linux Bios Config) and which start the process of building a build directory.
Alright, I think I have some semblance of a clue. :-) Is there any documentation on the general boot process that LinuxBIOS uses? i.e. very basic init, superio init (so we have a serial port), chipset init (enable sdram, ide, whatever, test RAM if enabled), decompress to RAM address 0xwhatever (why/how 0xwhatever was chosen), other init, jump to payload? Or did I just pretty much describe it? :-)
Regards, Andrew
If all else fails, it should be possable to generate an image by just concatenating the etherboot .elf binary, some padding, and the two linuxbios.strip binaries together.
The _two_ linuxbios.strip binaries? I only see the one in my build tree. I was going to try and use mkflashimg but I think I need a DoC bit or two I haven't figured out yet. :-)
recent objdump (that supports i8086 arch) with -D (disassemble all) can help to see where the pieces should go. Just remember that the top of the rom will appear at f0000 at boot time in real mode. Once it gets through __protected_start, you'll be up at the top of memory in i386 arch (ffffxxxx or in primary linuxbios at fffexxxx). One of these days, I'll need to write this up :-)
:-) I am an old x86 hacker (real and protected modes), but I haven't actively used my old knowledge for several years. It's embarassing how much I've lost. I will do what I can along the way to try and document it as I (re)learn it (especially the boot process that LinuxBIOS takes).
Regards, Andrew
On Thu, 14 Nov 2002, Andrew Kohlsmith wrote:
If all else fails, it should be possable to generate an image by just concatenating the etherboot .elf binary, some padding, and the two linuxbios.strip binaries together.
The _two_ linuxbios.strip binaries? I only see the one in my build tree. I was going to try and use mkflashimg but I think I need a DoC bit or two I haven't figured out yet. :-)
Greetings,
One will be the fallback image, the other is the primary. If you're not building for fallback, then you'll just have the primary, but will need to adjust things so that it's base is at ffffxxxx rather than fffexxxx, or build a 'fallback' image but with ZKERNEL_START moved down to the bottom of your FLASH instead of ffff0000. In a fallback image, ZKERNEL_START normally points so that the fallback image can find the primary. In a primary image, it points to the bottom of flash (typically) and is used to find your primary payload.
G'day, sjames
recent objdump (that supports i8086 arch) with -D (disassemble all) can help to see where the pieces should go. Just remember that the top of the rom will appear at f0000 at boot time in real mode. Once it gets through __protected_start, you'll be up at the top of memory in i386 arch (ffffxxxx or in primary linuxbios at fffexxxx). One of these days, I'll need to write this up :-)
:-) I am an old x86 hacker (real and protected modes), but I haven't actively used my old knowledge for several years. It's embarassing how much I've lost. I will do what I can along the way to try and document it as I (re)learn it (especially the boot process that LinuxBIOS takes).
Regards, Andrew _______________________________________________ Linuxbios mailing list Linuxbios@clustermatic.org http://www.clustermatic.org/mailman/listinfo/linuxbios
On Thu, 14 Nov 2002, Andrew Kohlsmith wrote:
heh, no problem. In the meantime, is it possible for me to pick through NLBConfig and glean the easier ones? I haven't looked at the source for NLBConfig yet, so I may be asking a dumb question here. :-)
no, because arbitrary options can be set in Config files.
So do a findgrep for all the option commands in all the Config files, sort and uniq it, and you have a list.
Ok so am I correct in assuming that since there are on Config files in any of the superio/SMC/ directories that the superio.c file is not used at all? I based my fdc37n958fr configuration off of the fdc37c67x's configuration, but did not bother with the superio.c since it went off on an entirely different tangent. (enable PNP?)
No, because some mainboard files yank in superios directory.
Alright, I think I have some semblance of a clue. :-) Is there any documentation on the general boot process that LinuxBIOS uses? i.e. very basic init, superio init (so we have a serial port), chipset init (enable sdram, ide, whatever, test RAM if enabled), decompress to RAM address 0xwhatever (why/how 0xwhatever was chosen), other init, jump to payload? Or did I just pretty much describe it? :-)
I did a summary a few years ago, which I *should* have put on the web page and did not. We need somebody to write it up, it has changed a lot.
ron
can you send teh serial output too?
Working on it (there are no F#*%&%#$ing serial ports on this laptop, if you can believe it), and bochs isn't smart enough to spit anything going out a serial port to a file (or maybe I am just dumb). :-)
Regards, Andrew
One will be the fallback image, the other is the primary. If you're not building for fallback, then you'll just have the primary, but will need to adjust things so that it's base is at ffffxxxx rather than fffexxxx, or build a 'fallback' image but with ZKERNEL_START moved down to the bottom of your FLASH instead of ffff0000. In a fallback image, ZKERNEL_START normally points so that the fallback image can find the primary. In a primary image, it points to the bottom of flash (typically) and is used to find your primary payload.
Hmmm... Bochs seems to find the BIOS and execute it just fine (well until later on, that is) without mucking with anything. Attached are my Config and config files.
The payload will eventually be an etherboot image which will boot from IDE (CompactFlash) -- offhand, do I use any old ethernet driver for etherboot, since I'm falling back to IDE? And do I use (for example) ne.img, ne.lzrom, ne.o or ne.rom? None of them are being identified as an ELF image, even though the etherboot config file is saying to create ELF images.
Regards, Andrew
Ok so am I correct in assuming that since there are on Config files in any of the superio/SMC/ directories that the superio.c file is not used at all? I based my fdc37n958fr configuration off of the fdc37c67x's configuration, but did not bother with the superio.c since it went off on an entirely different tangent. (enable PNP?)
No, because some mainboard files yank in superios directory.
Hmm... so should i have superio.c just do what setup_serial.inc is doing? Why are there two initializations?
Regards, Andrew
On Thu, 14 Nov 2002, Andrew Kohlsmith wrote:
Hmm... so should i have superio.c just do what setup_serial.inc is doing?
setup_serial.inc is for very early in the game, before memory is up, so that we have some diagnostic output. It is mainboard, chipset, and superio-sensitive.
superio.c is for initializing all the resources on a given superio.
ron
It will work. I don't think your kernel is flakey. If anything, I think the problem is elsewhere. And I think the fault is in the simulator, but I can't get the Bochs team to agree one way, or the other, with my suggestions regarding this project. Yes, please do.
Oops... It doesn't commit suicide when at 0x04000; it is doing more unpacking. I am now tracing it printing "LinuxBIOS", trying to see where it *does* jump off in to never-never land, eventually tripping bochs out by going over my memory size.
Yes, I figured out why it was giving me that error -- the BIOS eventually jumped in to zeroed RAM and just kept going. The crash always occured at the 16M mark, where is what I have my RAM size set to. :-)
Regards, Andrew
-
Andrew Kohlsmith -
Andrew Kohlsmith -
Gregg C Levine -
Ronald G. Minnich -
steven james