According to the FAQ, it's possible to boot Linux using Etherboot with LinuxBIOS. This appears to be a pretty simple and straightforward process, but I was wandering if it were possible to render the system unbootable? That is, is it posible that overwriting the BIOS will cause boot to fail (because of misconfiguration, etc.)? If this happens, is there anyway to recover? What are the pitfalls and how can I avoid them?
The idea of overwriting the BIOS makes me a bit nervous, but the potential benefits of this boot-up process could save us quite a bit when it comes to configuring our clustered systems.
Thanks, Sterling
On Fri, 15 Aug 2003, Andrew Sterling Hanenkamp wrote:
According to the FAQ, it's possible to boot Linux using Etherboot with LinuxBIOS. This appears to be a pretty simple and straightforward process, but I was wandering if it were possible to render the system unbootable? That is, is it posible that overwriting the BIOS will cause boot to fail (because of misconfiguration, etc.)? If this happens, is there anyway to recover? What are the pitfalls and how can I avoid them?
There is a fallback bios mechanism for linuxbios, and in V2 it is easy to build fallback/normal images. It's quite an interesting design, Eric developed it, and it's worth a read of the code to see how it works.
We use this fallback system on the 1024 node pink system, and it has served us well through many flash cycles.
ron
Purchase yourself a BIOS Savior. They're about $20-$25 depending on the motherboard and provide absolute protection against screwups. http://www.pcmods.com/
Basically you end up with two BIOS chips on the motherboard, and a little toggle switch to select one or the other. That way you don't need to "hotswap" BIOS chips, either.
On Fri, Aug 15, 2003 at 09:41:42AM -0500, Andrew Sterling Hanenkamp wrote:
According to the FAQ, it's possible to boot Linux using Etherboot with LinuxBIOS. This appears to be a pretty simple and straightforward process, but I was wandering if it were possible to render the system unbootable? That is, is it posible that overwriting the BIOS will cause boot to fail (because of misconfiguration, etc.)? If this happens, is there anyway to recover? What are the pitfalls and how can I avoid them?
The idea of overwriting the BIOS makes me a bit nervous, but the potential benefits of this boot-up process could save us quite a bit when it comes to configuring our clustered systems.
Thanks, Sterling
On Fri, 15 Aug 2003, Jeff Noxon wrote:
Purchase yourself a BIOS Savior. They're about $20-$25 depending on the motherboard and provide absolute protection against screwups. http://www.pcmods.com/
This is ok on a onesy-twosy scale, but it won't help people who are looking at larger numbers of nodes. It's a wondeful too however.
ron
On Fri, Aug 15, 2003 at 08:59:53AM -0600, ron minnich wrote:
Purchase yourself a BIOS Savior. They're about $20-$25 depending
This is ok on a onesy-twosy scale, but it won't help people who are looking at larger numbers of nodes. It's a wondeful too however.
Agreed, but I think the poster's concern was rendering a machine unbootable. Once LinuxBIOS is working on one node, it can be copied to the others easily and without much concern. I still don't have LB working properly on my Tyan TigerMPX board. It's nice to have a way to continue booting it ;)
Regards,
Jeff
ron minnich wrote:
It's quite an interesting design, Eric developed it, and it's worth a read of the code to see how it works.
^^^^^^^^^^^^^^^^^^^^^^^^^^^^ One of the things we very much need to work on, and of course I'm just as guilty, but so many things in linuxbios require a "read of the code".
-Steve
On Fri, 15 Aug 2003, Jeff Noxon wrote:
Agreed, but I think the poster's concern was rendering a machine unbootable. Once LinuxBIOS is working on one node, it can be copied to the others easily and without much concern. I still don't have LB working properly on my Tyan TigerMPX board. It's nice to have a way to continue booting it ;)
not always true. On one 1024 node update, a linuxbios update uncovered a problem in the hardware, such that 5 of the 1024 nodes had trouble booting. Times like those you really need a fallback. It's easy to see, given the general bugginess of so much PC hardware, why the BIOSes run it so slow.
ron
On Fri, 15 Aug 2003, Steve Gehlbach wrote:
One of the things we very much need to work on, and of course I'm just as guilty, but so many things in linuxbios require a "read of the code".
on the list.
ron
ron minnich wrote:
On one 1024 node update, a linuxbios update uncovered a problem in the hardware, such that 5 of the 1024 nodes had trouble booting. Times like those you really need a fallback. It's easy to see, given the general bugginess of so much PC hardware, why the BIOSes run it so slow.
I'm actually amazed you can get 1024 PC mobos all going at once. Many if not most mobo mfrs turn their designs 4 times a year, that is not much time to do exhaustive design checks. And the power conversion circuits are frequently running components beyond spec, so that this area has a life expectancy of 1-2 years, on many boards. I guess PC mfrs figure you'll buy a new one by then so what the heck. But it varies with the mfr and the specific board. I've had some with <5% failure in 10 years, others 25% failure in 5 years. And dont get me started on the power supply and the fans...
-Steve
Greetings,
It IS possible to render a board unbootable with a bad flash, but there are a few protections in place.
The trickiest part is the initial loading where a fallback image is flashed into the top of the BIOS. The fallback block can (should) be set up as a completely independant boot image with a copy of Etherboot built in.
Most of the boards have a socketed flash so that the worst case scenerio for a mis-flashed fallback is that you'll have to boot from a spare chip, hot swap in the mis-flashed chip, and try again.
Unfortunatly, a few boards do have a soldered down flash. In those cases, the only way to recover is to de-solder the chip (which may not be worth the cost vs. a new board)
Once in place and functioning, the fallback should never be changed. Many mainboards (all of the i7501 based boards for example) have a jumper that can be set to prevent accidental flashing of the top block.
The rest of the flash contains the primary LinuxBIOS image and the preferred boot payload (often another copy of Etherboot), and can then be flashed at will. The worst case will be that you'll have to hit reset a few times to cause the fallback image to boot the system.
G'day, sjames
On Fri, 15 Aug 2003, Andrew Sterling Hanenkamp wrote:
According to the FAQ, it's possible to boot Linux using Etherboot with LinuxBIOS. This appears to be a pretty simple and straightforward process, but I was wandering if it were possible to render the system unbootable? That is, is it posible that overwriting the BIOS will cause boot to fail (because of misconfiguration, etc.)? If this happens, is there anyway to recover? What are the pitfalls and how can I avoid them?
The idea of overwriting the BIOS makes me a bit nervous, but the potential benefits of this boot-up process could save us quite a bit when it comes to configuring our clustered systems.
Thanks, Sterling
Would you please elaborate on this a little?
I still don't have my Tyan board working properly, but I can tell you this -- my fallback image doesn't have any payload at all. I thought it just ran the payload from the other image. (Which puzzled me.)
I was just burning the linuxbios.rom into top 64KB of flash.
Now that I'm clued in, I'm not sure how it's supposed to work.
The fallback file "linuxbios" is 48884 bytes in size. For some reason when it is run through objdump to create linuxbios.strip, it ends up being 65536 bytes. That doesn't leave room for any payload. Is this another binutils problem?
Here you can see how make dies:
objcopy -O binary linuxbios linuxbios.strip export size=`ls -l linuxbios.strip | (read p c u g size r ; echo $size)` ; \ echo $size ; \ dd if=linuxbios.strip of=linuxbios.rom bs=1 seek=`expr 65536 - $size` 65536 65536+0 records in 65536+0 records out dd conv=sync bs=0 if=/usr/src/linuxbios/3c90x.elf of=payload.block dd: invalid number `0' make: *** [payload.block] Error 1
Of course, dd fails because PAYLOAD_SIZE is not set.
I can't use my working EPIA board as an example, because that board doesn't have "normal" and "fallback" images -- it just has one image.
It would be very helpful for me to have your diffs against CVS, or the config files you're actually using to build these ROM images.
Thanks,
Jeff (Trying not to look like a total idiot)
On Sat, Aug 16, 2003 at 02:27:07PM -0400, steven james wrote:
Greetings,
It IS possible to render a board unbootable with a bad flash, but there are a few protections in place.
The trickiest part is the initial loading where a fallback image is flashed into the top of the BIOS. The fallback block can (should) be set up as a completely independant boot image with a copy of Etherboot built in.
Most of the boards have a socketed flash so that the worst case scenerio for a mis-flashed fallback is that you'll have to boot from a spare chip, hot swap in the mis-flashed chip, and try again.
Unfortunatly, a few boards do have a soldered down flash. In those cases, the only way to recover is to de-solder the chip (which may not be worth the cost vs. a new board)
Once in place and functioning, the fallback should never be changed. Many mainboards (all of the i7501 based boards for example) have a jumper that can be set to prevent accidental flashing of the top block.
The rest of the flash contains the primary LinuxBIOS image and the preferred boot payload (often another copy of Etherboot), and can then be flashed at will. The worst case will be that you'll have to hit reset a few times to cause the fallback image to boot the system.
G'day, sjames
Greetings,
The fallback image has to be pieced together. Just create a pad file sized 0x10000 - (lb image + etherboot image) and dd if=/dev/zero bs=1 count=<size> of=pad then cat etherboot pad linuxbios>fallback_block
and flash the result.
G'day, sjames
On Sat, 16 Aug 2003, Jeff Noxon wrote:
Would you please elaborate on this a little?
I still don't have my Tyan board working properly, but I can tell you this -- my fallback image doesn't have any payload at all. I thought it just ran the payload from the other image. (Which puzzled me.)
I was just burning the linuxbios.rom into top 64KB of flash.
Now that I'm clued in, I'm not sure how it's supposed to work.
The fallback file "linuxbios" is 48884 bytes in size. For some reason when it is run through objdump to create linuxbios.strip, it ends up being 65536 bytes. That doesn't leave room for any payload. Is this another binutils problem?
Here you can see how make dies:
objcopy -O binary linuxbios linuxbios.strip export size=`ls -l linuxbios.strip | (read p c u g size r ; echo $size)` ; \ echo $size ; \ dd if=linuxbios.strip of=linuxbios.rom bs=1 seek=`expr 65536 - $size` 65536 65536+0 records in 65536+0 records out dd conv=sync bs=0 if=/usr/src/linuxbios/3c90x.elf of=payload.block dd: invalid number `0' make: *** [payload.block] Error 1
Of course, dd fails because PAYLOAD_SIZE is not set.
I can't use my working EPIA board as an example, because that board doesn't have "normal" and "fallback" images -- it just has one image.
It would be very helpful for me to have your diffs against CVS, or the config files you're actually using to build these ROM images.
Thanks,
Jeff (Trying not to look like a total idiot)
On Sat, Aug 16, 2003 at 02:27:07PM -0400, steven james wrote:
Greetings,
It IS possible to render a board unbootable with a bad flash, but there are a few protections in place.
The trickiest part is the initial loading where a fallback image is flashed into the top of the BIOS. The fallback block can (should) be set up as a completely independant boot image with a copy of Etherboot built in.
Most of the boards have a socketed flash so that the worst case scenerio for a mis-flashed fallback is that you'll have to boot from a spare chip, hot swap in the mis-flashed chip, and try again.
Unfortunatly, a few boards do have a soldered down flash. In those cases, the only way to recover is to de-solder the chip (which may not be worth the cost vs. a new board)
Once in place and functioning, the fallback should never be changed. Many mainboards (all of the i7501 based boards for example) have a jumper that can be set to prevent accidental flashing of the top block.
The rest of the flash contains the primary LinuxBIOS image and the preferred boot payload (often another copy of Etherboot), and can then be flashed at will. The worst case will be that you'll have to hit reset a few times to cause the fallback image to boot the system.
G'day, sjames
That gets back to my original question:
I have a "linuxbios.strip" file that's exactly 64KB. How can I add Etherboot to it and still have a 64KB image?
Is this a problem with my objdump utility? Or do I have to manually _overlay_ the linuxbios.strip file and Etherboot? And if the latter, how do I know how much space I have for Etherboot?
Where have I gone wrong?
Thanks,
Jeff
On Sat, Aug 16, 2003 at 07:08:51PM -0400, steven james wrote:
Greetings,
The fallback image has to be pieced together. Just create a pad file sized 0x10000 - (lb image + etherboot image) and dd if=/dev/zero bs=1 count=<size> of=pad then cat etherboot pad linuxbios>fallback_block
and flash the result.
On Sat, 16 Aug 2003, Jeff Noxon wrote:
Would you please elaborate on this a little?
I still don't have my Tyan board working properly, but I can tell you this -- my fallback image doesn't have any payload at all. I thought it just ran the payload from the other image. (Which puzzled me.)
I was just burning the linuxbios.rom into top 64KB of flash.
Now that I'm clued in, I'm not sure how it's supposed to work.
The fallback file "linuxbios" is 48884 bytes in size. For some reason when it is run through objdump to create linuxbios.strip, it ends up being 65536 bytes. That doesn't leave room for any payload. Is this another binutils problem?
On Sat, 16 Aug 2003, Jeff Noxon wrote:
I still don't have my Tyan board working properly, but I can tell you this -- my fallback image doesn't have any payload at all. I thought it just ran the payload from the other image. (Which puzzled me.)
the fallback must have a payload. Fallback and normal are two totally independent things.
I was just burning the linuxbios.rom into top 64KB of flash.
oh, gosh, are you using v1 or v2?
objcopy -O binary linuxbios linuxbios.strip export size=`ls -l linuxbios.strip | (read p c u g size r ; echo $size)` ; \ echo $size ; \ dd if=linuxbios.strip of=linuxbios.rom bs=1 seek=`expr 65536 - $size` 65536 65536+0 records in 65536+0 records out dd conv=sync bs=0 if=/usr/src/linuxbios/3c90x.elf of=payload.block dd: invalid number `0' make: *** [payload.block] Error 1
sorry for this, I am going off the air soon but I think Andrew Ip or the other EIPA guys on this list might be able to help.
I will send you my config under seperate cover.
ron
On Sat, 16 Aug 2003, steven james wrote:
The fallback image has to be pieced together. Just create a pad file sized 0x10000 - (lb image + etherboot image) and dd if=/dev/zero bs=1 count=<size> of=pad then cat etherboot pad linuxbios>fallback_block
yes, this is fixed on v2. I got rid of all the 'dd' magic and have a trivial C program.
ron
-
Andrew Sterling Hanenkamp -
Jeff Noxon -
ron minnich -
Steve Gehlbach -
steven james