Re: [Etherboot-developers] Re: [RFC] Relocation techniques...

[<ebi...@ln...>]

pjc...@el... writes:

> I'm not sure if this precisely fits in with the relocation being discussed
> here, but it foiled my efforts to etherboot from my existing network 
> cards.
> 
> I've got one of the 3com 3C905B-NM cards, for which 
> disklessworkstations.com sells proms.  These are the cards that overload 
> the MII signal to choose which ROM bank to read.  The current (hack) 
> solution is to use a boot disk which locks the MII setting on.  That way 
> the card can see more than 4KB of the boot rom, and load the etherboot
> code into memory.
> 
> However, this is rather sloppy.  It leaves the one signal stuck on.  
> Always.  Even when you don't boot from the bootrom.  Linux handles this 
> situation just fine.  However, DOS TCP stacks pitch a fit.  This makes our 
> Ghost boot disks fail, rendering the machines rather useless.
> 
> Apparently the right solution is to have a small piece of code which lives 
> in the low 4KB of the ROM.  It switches the banks, copies the ROM into RAM 
> somewhere, and switches back.  Then it boots.
> 
> All that to say, if you're toying with relocation and other such memory 
> constraints, please consider building the little low-memory shim into your 
> plans.

We need a loader shim for loading the code somewhere in memory.
Currently this is loader.S and it needs updating, to handle your
interesting case.

Of course the other possibility is to actually fix the DOS driver so
it doesn't have a problem with this case.

When we start relocating etherboot to live at different memory
locations we will probably need to touch loader.S as well.

Go ahead and submit the code, only someone with the same hardware
as you can test it, so you look like the perfect canidate. 

Eric