On Fri, Jul 12, 2002 at 01:40:01PM -0600, Eric W Biederman wrote: > "Richard A. Smith" <[EMAIL PROTECTED]> writes: > > > On 12 Jul 2002 12:42:02 -0600, Eric W Biederman wrote: > > > > > Eric Seppanen <[EMAIL PROTECTED]> writes: > > > > > > > Am I missing something, or shouldn't it be fairly straightforward to push > > > > the image out to 128k or 256k, fixing up the boot vector and other > > > > addresses to match? > > > > > > The limiting factor is the transition from real to protected mode. As > > > soon as you are in protected mode, and have enabled full decode of > > > the ROM it should be straight forward to do a lot more. > > > > I thought LinuxBIOS went to protected mode right out of the gate at > > least thats what I thought entry32.inc says it does.. > > 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. > > It isn't insolvable. Or even terrifically hard to fix. But it must > be fixed to have LinuxBIOS > 64K.
OK, so as a possible solution to Tony's problem, it should be straightforward to do something like this: - Relocate the 32-bit mode switch code to a fixed location near the reset vector. - Modify the reset jump instruction to jump to that location. - Modify the linuxbios addressing scheme and linker scripts to locate the bulk of the linuxbios code at top-of-memory minus 128k. Cover and stir for 15 minutes, and you have a tasty treat for the whole family. Unfortunately since you're not publishing code at the moment it seems to be pretty much your problem to do this if you want it done. Or you could try and bribe one of the folks here to do some contract work for you :) > 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. > > 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. > > Eric
