Etherboot in the BIOS?

[steven james]

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
> 

-- 
-------------------------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
-----------------------------------------------------------------------