lkml.org 
[lkml]   [1999]   [Aug]   [6]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: bzImage patch ? for monolithic kernels
Hi Peter.

>>> I am using bzImage. I get the following errors that are all
>>> related to the fact that the kernel size is > 1 Meg.

>>> Root device is (8, 1)
>>> Boot sector 512 bytes.
>>> Setup is 3440 bytes.
>>> System is 1036 kB
>>> System is too big. Try using modules.
>>> make[1]: *** [bzImage] Error 1
>>> make[1]: Leaving directory
>>> `/mnt/micropolis2/src/linux.2312/arch/i386/boot'
>>> make: *** [bzImage] Error 2

>>> Anyone know a fix? I know that some previous debate had raged
>>> about bzImage should be able to handle up to 16M kernel sizes
>>> but have found no data/patches/etc on what to do to get past 1M.

>> 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...

> That's completely bogus. Those boot loaders (which??) are
> broken. I know for a fact that SYSLINUX has no such limit, lbcon
> definitely will not have it, and hard-coding that limit into the
> kernel compile sequence is a BUG.

> If LILO, say, doesn't support loading a bzImage > 1 MB then LILO
> should complain, but not prevent someone from compiling the
> image for use with another boot loader.

I've now done some more research into this, and the problem is that
the size of the kernel is stored near the end of the boot sector, as
per the following extract from arch/i386/boot/bootsect.S =>

Q> .org 497
Q> setup_sects:
Q> .byte SETUPSECS
Q> root_flags:
Q> .word CONFIG_ROOT_RDONLY
Q> syssize:
Q> .word SYSSIZE
Q> swap_dev:
Q> .word SWAP_DEV
Q> ram_size:
Q> .word RAMDISK
Q> vid_mode:
Q> .word SVGA_MODE
Q> root_dev:
Q> .word ROOT_DEV
Q> boot_flag:
Q> .word 0xAA55

Note the following lines in the above:

Q> syssize:
Q> .word SYSSIZE

This word stores the kernel size in 16-byte paragraphs, thus
restricting the kernel to be not more than 0xFFFF0 bytes in length.
That is the limit in question.

Based on your comments, I would assume that syslinux doesn't use that
word, which makes sense as it can obtain the kernel size from the
kernel file itself as it runs on a fully booted system. However, lilo
(and other similar bootloaders) that run as part of the hardware boot
process don't have that ability.

I'm looking into a patch to sort this out, and my current thoughts are
along the lines of the following:

Q> .org 493
Q> kernel_size:
Q> .word SYSSIZE_LOW
Q> .word SYSSIZE_HIGH
Q> setup_sects:
Q> .byte SETUPSECS
Q> root_flags:
Q> .word CONFIG_ROOT_RDONLY
Q> syssize:
Q> .word 0xFFFF
Q> swap_dev:
Q> .word SWAP_DEV
Q> ram_size:
Q> .word RAMDISK
Q> vid_mode:
Q> .word SVGA_MODE
Q> root_dev:
Q> .word ROOT_DEV
Q> boot_flag:
Q> .word 0xAA55

Note that the current syssize variable holds a 'magic' value that is
used to indicate that the quadbyte labelled kernel_size holds the
actual kernel length. Basically, if syssize holds any value other than
0xFFFF then the current method is used, but the presence of 0xFFFF in
that word causes the new method to be used.

Comments?

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/

\
 
 \ /
  Last update: 2005-03-22 13:53    [W:0.075 / U:1.308 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site