* Eric W Biederman <[EMAIL PROTECTED]> [020712 21:40]:
> It does. It is just that entry16.inc is located at the opposite
> end of the LinuxBIOS image from reset16.inc. And that 16bit jump
> must cover the whole distane.
Is this just an implementation detail or is some higher magic involved
that makes it necessary to tare entry16.inc and reset16.inc apart?
> Until I can see a justification keeping LinuxBIOS into 64K, sounds
> reasonable. And we can put a bootloader in the rest of the ROM chip,
> that has the sophistiacted user interaction features.
>
> Personally I'd like to shrink LinuxBIOS down even further than 64K but
> we will see where that goes.
This sounds very interesting. Do you have any estimation of the minimum
size a stripped down LinuxBIOS image can/would have? I.e. how much of
the pci interface has to be initialized to make all the dram controller
init work sane? A lot of flash devices have 8 or 16k blocks for
emergency/small ipl code. Is it a dream to push a version of LinuxBIOS
that does nothing but load an ELF image from the other blocks to one of
those?
> But given all of the troubles I have had with the kernel being too big
> I don't even want to consider totally ignoring the size issue.
100% agreed. The simpler LinuxBIOS is kept the more space can be used
for an actual bootloader/interface between user or os or whatever is
needed. LinuxBIOS is great at the IPL code and it is universal because
it is so small. Keeping this as a small layer to put any "higher level"
code on top of it looks nice in my eyes.
Stefan
--
The x86 isn't all that complex - it just doesn't make a lot of
sense. -- Mike Johnson, Leader of 80x86 Design at AMD
Microprocessor Report (1994)
