Stefan Reinauer <[EMAIL PROTECTED]> writes: > * 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?
reset16.inc is 16 bytes long, and it located 16bytes below 4GB. So for x86 nothing more can be put there physical limit. The LinuxBIOS image is divided into a couple of sections. The interesting division at this point is the .rom section which is used by code that is executing direction from the ROM chip. And the other sections used by code that is executing from RAM. Currently the code that executes from ram sits in between the .rom section and reset16.inc. This part is an implementation detail. > > 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 routinely put both LinuxBIOS and etherboot into 64K. With LinuxBIOS taking up between 32K and 48K. The biggest win I can see is compressing the code that runs from ram, and getting some good compaction on all of those debugging strings. So at 3 to 1 we might fit into 16k. > I.e. how much of > the pci interface has to be initialized to make all the dram controller > init work sane? The pci initialization isn't a big deal here. But you can't find out how much ram you have useable on x86 until you have done the resource allocation. There are two causes of this. - video framebuffers which share the ram. - exhausting the 32bit address space, so having to cover some ram with pci devices, or at the minimum make the ram only accessible above 4GB. > 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? My current .rom section is about 6k. And unless you like optimizing assembly code for size or have a compiler that just uses ram it is hard to improve on this, and still support a wide variety of memory sticks. > > 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. An interesting bit of controversy comes up with LinuxBIOS and resource allocation. A lot of this is motherboard dependent. And a lot of the rest is chipset dependent. There are two ways LinuxBIOS can go with this. Either provide tables for someone else to use or to allocate the resources itself. Given the simplicity of the rest of the system if it can assume resources have been assigned non-conflicting addresses, the synergy of having both all of the information and the allocator in the same code base, and the fact that many parts of resource allocation are indeed motherboard depending, I don't see a strong argument for removing this code from LinuxBIOS. What I see happening instead is the resource allocator becomming a general framework on which all of the device dependent code hangs. Making hardwaremain look something like. display_init(); static_device_enumerate(); /* Those devices we know at compile time */ dynamic_device_enumerate(); /* Those devices we can find at run time */ device_configure(); /* Don't call sizeram until here */ device_initialize(); /* Including cpus */ write_tables(); elfboot(); Eric
