Etherboot in the BIOS?
pyro at linuxlabs.com
Sat Aug 16 18:50:00 CEST 2003
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?
> 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+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.
> (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
-------------------------steven james, director of research, linux labs
... ........ ..... .... 230 peachtree st nw ste 2701
the original linux labs atlanta.ga.us 30303
-since 1995 http://www.linuxlabs.com
office 404.577.7747 fax 404.577.7743
More information about the coreboot