>> Whilst the bzImage format itsef can handle kernels up to 16M in
>> size, there is a problem with boot loaders once the kernel gets
>> to be over 1M in size, and that is the current limit.
>> There HAS to be a way round that limit, but I for one haven't
>> the foggiest what it is...
> Zeroeth-order: change the 0xffff constant on line 173 of
> linux/arch/i386/boot/tools/build.c to something more appropriate
> (0xfffff for example) and see what breaks...
Thanks, that's what I was looking for...
> Actually, I don't see why 16 MB would be a limit for bzImage
> either...
Memory says that the 16 MB limit is because the bzImage copying code
works in 286 protected mode, as that's the mode used by the BIOS
copying routines that it depends on, and 16 MB is the hardware limit
in that mode.
If my patch works the way it looks like, then 64 Terabytes will be the
actual kernel size limit as far as storage is concerned, so having a
gzImage format that could work past that limit would be feasible. Such
would presumably be done via a two-stage process, with the bzImage
code copying the first 16 MB, and a secondary routine then copying the
rest of the kernel into place.
Best wishes from Riley.
+----------------------------------------------------------------------+
| There is something frustrating about the quality and speed of Linux |
| development, ie., the quality is too high and the speed is too high, |
| in other words, I can implement this XXXX feature, but I bet someone |
| else has already done so and is just about to release their patch. |
+----------------------------------------------------------------------+
* ftp://ftp.MemAlpha.cx/pub/rhw/Linux
* http://www.MemAlpha.cx/kernel.versions.html
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/