Maximum bootable kernel size in current ARM linux

Maximum bootable kernel size in current ARM linux

[Bruce M. Penrod]

This seems like a pretty straightforward question, but extensive web 
searching hasn't shown a really clear, up-to-date answer.  The most 
recent info is circa 2004 and states that 4MB is the largest 
uncompressed ARM kernel that may be loaded.  Not being an ARM assembly 
guru (head.S baffles me), I'd like to know if that is still true in 
2010, and if it is, why?

I'm having one hell of a time compiling a monolithic kernel and keeping 
it under 4M without leaving out some core networking features I need. 
 From my searching, it looks like x86 has either removed the limit or 
raised it to a much higher number.  It's not clear to me why a 32 bit 
processor would not be able to boot a kernel larger than 4 MB.

Bruce

Maximum bootable kernel size in current ARM linux

[Marek Vasut]

Dne Po 13. z??? 2010 09:40:56 Bruce M. Penrod napsal(a):
> This seems like a pretty straightforward question, but extensive web
> searching hasn't shown a really clear, up-to-date answer.  The most
> recent info is circa 2004 and states that 4MB is the largest
> uncompressed ARM kernel that may be loaded.  Not being an ARM assembly
> guru (head.S baffles me), I'd like to know if that is still true in
> 2010, and if it is, why?
> 
> I'm having one hell of a time compiling a monolithic kernel and keeping
> it under 4M without leaving out some core networking features I need.
>  From my searching, it looks like x86 has either removed the limit or
> raised it to a much higher number.  It's not clear to me why a 32 bit
> processor would not be able to boot a kernel larger than 4 MB.

Hey, CCed Russell.

Btw. this shouldn't be true anymore. On the other hand, why do you need such a 
huge kernel?

It's not even possible to create kernel that big if you don't have some kind of 
initramfs in, right? Besides, you can use some kind of a compression, like LZMA 
or something to keep the size down.

Cheers
> 
> Bruce
> 
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Maximum bootable kernel size in current ARM linux

[Haojian Zhuang]

On Mon, Sep 13, 2010 at 4:43 PM, Marek Vasut <marek.vasut@gmail.com> wrote:
> Dne Po 13. z??? 2010 09:40:56 Bruce M. Penrod napsal(a):
>> This seems like a pretty straightforward question, but extensive web
>> searching hasn't shown a really clear, up-to-date answer. ?The most
>> recent info is circa 2004 and states that 4MB is the largest
>> uncompressed ARM kernel that may be loaded. ?Not being an ARM assembly
>> guru (head.S baffles me), I'd like to know if that is still true in
>> 2010, and if it is, why?
>>
>> I'm having one hell of a time compiling a monolithic kernel and keeping
>> it under 4M without leaving out some core networking features I need.
>> ?From my searching, it looks like x86 has either removed the limit or
>> raised it to a much higher number. ?It's not clear to me why a 32 bit
>> processor would not be able to boot a kernel larger than 4 MB.
>
> Hey, CCed Russell.
>
> Btw. this shouldn't be true anymore. On the other hand, why do you need such a
> huge kernel?
>
> It's not even possible to create kernel that big if you don't have some kind of
> initramfs in, right? Besides, you can use some kind of a compression, like LZMA
> or something to keep the size down.
>
> Cheers

If initramfs is built in, we'll get a huge kernel. Even using LZMA, my
kernel size is near 5MB.

Maximum bootable kernel size in current ARM linux

[Simon Guinot]

On Mon, Sep 13, 2010 at 05:56:30PM +0800, Haojian Zhuang wrote:
> On Mon, Sep 13, 2010 at 4:43 PM, Marek Vasut <marek.vasut@gmail.com> wrote:
> > Dne Po 13. z??? 2010 09:40:56 Bruce M. Penrod napsal(a):
> >> This seems like a pretty straightforward question, but extensive web
> >> searching hasn't shown a really clear, up-to-date answer. ?The most
> >> recent info is circa 2004 and states that 4MB is the largest
> >> uncompressed ARM kernel that may be loaded. ?Not being an ARM assembly
> >> guru (head.S baffles me), I'd like to know if that is still true in
> >> 2010, and if it is, why?
> >>
> >> I'm having one hell of a time compiling a monolithic kernel and keeping
> >> it under 4M without leaving out some core networking features I need.
> >> ?From my searching, it looks like x86 has either removed the limit or
> >> raised it to a much higher number. ?It's not clear to me why a 32 bit
> >> processor would not be able to boot a kernel larger than 4 MB.
> >
> > Hey, CCed Russell.
> >
> > Btw. this shouldn't be true anymore. On the other hand, why do you need such a
> > huge kernel?
> >
> > It's not even possible to create kernel that big if you don't have some kind of
> > initramfs in, right? Besides, you can use some kind of a compression, like LZMA
> > or something to keep the size down.
> >
> > Cheers
> 
> If initramfs is built in, we'll get a huge kernel. Even using LZMA, my
> kernel size is near 5MB.

The initramfs is located at the end of the init section and before the
text section. Because the kernel must be able to 'branch' between the
init and text sections, the initramfs size can't be greater than the
'branch' maximum offset. 32MB ?

I guess that relocate the initramfs just after the text section should
break this limitation.

Simon
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20100913/8210778f/attachment-0001.sig>

Maximum bootable kernel size in current ARM linux

[Russell King - ARM Linux]

On Mon, Sep 13, 2010 at 10:10:39AM +0000, Simon Guinot wrote:
> On Mon, Sep 13, 2010 at 05:56:30PM +0800, Haojian Zhuang wrote:
> > On Mon, Sep 13, 2010 at 4:43 PM, Marek Vasut <marek.vasut@gmail.com> wrote:
> > > Dne Po 13. z??? 2010 09:40:56 Bruce M. Penrod napsal(a):
> > >> This seems like a pretty straightforward question, but extensive web
> > >> searching hasn't shown a really clear, up-to-date answer. ?The most
> > >> recent info is circa 2004 and states that 4MB is the largest
> > >> uncompressed ARM kernel that may be loaded. ?Not being an ARM assembly
> > >> guru (head.S baffles me), I'd like to know if that is still true in
> > >> 2010, and if it is, why?
> > >>
> > >> I'm having one hell of a time compiling a monolithic kernel and keeping
> > >> it under 4M without leaving out some core networking features I need.
> > >> ?From my searching, it looks like x86 has either removed the limit or
> > >> raised it to a much higher number. ?It's not clear to me why a 32 bit
> > >> processor would not be able to boot a kernel larger than 4 MB.
> > >
> > > Hey, CCed Russell.
> > >
> > > Btw. this shouldn't be true anymore. On the other hand, why do you need such a
> > > huge kernel?
> > >
> > > It's not even possible to create kernel that big if you don't have some kind of
> > > initramfs in, right? Besides, you can use some kind of a compression, like LZMA
> > > or something to keep the size down.
> > >
> > > Cheers
> > 
> > If initramfs is built in, we'll get a huge kernel. Even using LZMA, my
> > kernel size is near 5MB.
> 
> The initramfs is located at the end of the init section and before the
> text section. Because the kernel must be able to 'branch' between the
> init and text sections, the initramfs size can't be greater than the
> 'branch' maximum offset. 32MB ?
> 
> I guess that relocate the initramfs just after the text section should
> break this limitation.

But then means that it won't be freed after init time.

If you want one monolithic kernel and filesystem, use the
arch/arm/boot/bootp instead - it doesn't have these restrictions as it
uses the age old initrd method of passing a filesystem/initramfs to the
kernel.

Maximum bootable kernel size in current ARM linux

[Matthieu CASTET]

Russell King - ARM Linux a ?crit :
> On Mon, Sep 13, 2010 at 10:10:39AM +0000, Simon Guinot wrote:
>> On Mon, Sep 13, 2010 at 05:56:30PM +0800, Haojian Zhuang wrote:
>>> On Mon, Sep 13, 2010 at 4:43 PM, Marek Vasut <marek.vasut@gmail.com> wrote:
>>>> Cheers
>>> If initramfs is built in, we'll get a huge kernel. Even using LZMA, my
>>> kernel size is near 5MB.
>> The initramfs is located at the end of the init section and before the
>> text section. Because the kernel must be able to 'branch' between the
>> init and text sections, the initramfs size can't be greater than the
>> 'branch' maximum offset. 32MB ?
>>
>> I guess that relocate the initramfs just after the text section should
>> break this limitation.
> 
> But then means that it won't be freed after init time.
And why not putting it before init section ?

Matthieu

Maximum bootable kernel size in current ARM linux

[Russell King - ARM Linux]

On Mon, Sep 13, 2010 at 01:58:14PM +0200, Matthieu CASTET wrote:
> Russell King - ARM Linux a ?crit :
>> On Mon, Sep 13, 2010 at 10:10:39AM +0000, Simon Guinot wrote:
>>> On Mon, Sep 13, 2010 at 05:56:30PM +0800, Haojian Zhuang wrote:
>>>> On Mon, Sep 13, 2010 at 4:43 PM, Marek Vasut <marek.vasut@gmail.com> wrote:
>>>>> Cheers
>>>> If initramfs is built in, we'll get a huge kernel. Even using LZMA, my
>>>> kernel size is near 5MB.
>>> The initramfs is located at the end of the init section and before the
>>> text section. Because the kernel must be able to 'branch' between the
>>> init and text sections, the initramfs size can't be greater than the
>>> 'branch' maximum offset. 32MB ?
>>>
>>> I guess that relocate the initramfs just after the text section should
>>> break this limitation.
>>
>> But then means that it won't be freed after init time.
> And why not putting it before init section ?

You still need code at the start of the kernel for the boot loader to
run, and some of that code needs to be reachable from the __init code.

You could move it away from the start of the kernel, replacing it with
a couple of instructions to branch to it, but then you're into problems
with setting up a 1:1 MMU mapping to cover the necessary code - and
making sure that the instructions don't overlap a mapping boundary.

Moreover, putting an initramfs at the very start risks making kernel
modules useless, as they're placed below the kernel in virtual space.
Adding an initramfs at the start of the kernel image pushes the kernel
text further away from the modules, possibly meaning that the modules
can't be linked.

So, all in all, having a large initramfs built into the kernel is a
stupid idea.  It's not going to work on ARM.

Maximum bootable kernel size in current ARM linux

[Dave P. Martin]

Hi,

> -----Original Message-----
> From: linux-arm-kernel-bounces at lists.infradead.org 
> [mailto:linux-arm-kernel-bounces at lists.infradead.org] On 
> Behalf Of Simon Guinot
> Sent: 13 September 2010 11:11
> To: Haojian Zhuang
> Cc: Marek Vasut; Russell King - ARM Linux; 
> linux-arm-kernel at lists.infradead.org; Bruce M. Penrod
> Subject: Re: Maximum bootable kernel size in current ARM linux

[...]

> The initramfs is located at the end of the init section and 
> before the text section. Because the kernel must be able to 
> 'branch' between the init and text sections, the initramfs 
> size can't be greater than the 'branch' maximum offset. 32MB ?

We can also build kernels in Thumb-2 (where the long branch range is +/- 4MB
IIRC)

I believe the linker should always generate trampolines to extend the range
of those branches where necessary, even when branching from assembler.  The
only case where this won't work is if you have individual objects whose text
section is so large there's nowhere to put the trampolines within the
required range, or where branch targets are fixed up by something other than
the linker (I'm guessing that's either a very rare situation or
nonexistent.)

These kind of fixup problems would result in link-time errors, but I don't
think I've observed this happening in practice.

Cheers
---Dave

Maximum bootable kernel size in current ARM linux

[Catalin Marinas]

On Tue, 2010-09-14 at 13:35 +0100, Dave P. Martin wrote:
> > The initramfs is located at the end of the init section and 
> > before the text section. Because the kernel must be able to 
> > 'branch' between the init and text sections, the initramfs 
> > size can't be greater than the 'branch' maximum offset. 32MB ?
> 
> We can also build kernels in Thumb-2 (where the long branch range is +/- 4MB
> IIRC)

I think the Thumb-2 branch goes up to 16MB range. The Thumb-1 may be
smaller but we don't support this in the kernel. That's why Thumb-2
modules are within 8MB below PAGE_OFFSET. But this leaves us with
maximum 8MB of kernel size.

> I believe the linker should always generate trampolines to extend the range
> of those branches where necessary, even when branching from assembler.  The
> only case where this won't work is if you have individual objects whose text
> section is so large there's nowhere to put the trampolines within the
> required range, or where branch targets are fixed up by something other than
> the linker (I'm guessing that's either a very rare situation or
> nonexistent.)

We would need some additional relocations handling in the modules
loading code.

-- 
Catalin

Maximum bootable kernel size in current ARM linux

[Nicolas Pitre]

On Tue, 14 Sep 2010, Catalin Marinas wrote:

> I think the Thumb-2 branch goes up to 16MB range. The Thumb-1 may be
> smaller but we don't support this in the kernel. That's why Thumb-2
> modules are within 8MB below PAGE_OFFSET. But this leaves us with
> maximum 8MB of kernel size.

Hmmm.  Would be worth moving the pkmap area below modules then.


Nicolas

Maximum bootable kernel size in current ARM linux

[Catalin Marinas]

On Tue, 2010-09-14 at 13:37 -0400, Nicolas Pitre wrote:
> On Tue, 14 Sep 2010, Catalin Marinas wrote:
> 
> > I think the Thumb-2 branch goes up to 16MB range. The Thumb-1 may be
> > smaller but we don't support this in the kernel. That's why Thumb-2
> > modules are within 8MB below PAGE_OFFSET. But this leaves us with
> > maximum 8MB of kernel size.
> 
> Hmmm.  Would be worth moving the pkmap area below modules then.

So currently the pkmap area is at PAGE_OFFSET - 2MB. On a Thumb-2 kernel
with highmem enabled we would have 6MB available to modules. Is this big
enough? If not, we could move the pkmap area.

BTW, can it be moved in the top part of the memory rather than below
PAGE_OFFSET?

-- 
Catalin

Maximum bootable kernel size in current ARM linux

[Russell King - ARM Linux]

On Thu, Sep 16, 2010 at 06:16:51PM +0100, Catalin Marinas wrote:
> On Tue, 2010-09-14 at 13:37 -0400, Nicolas Pitre wrote:
> > On Tue, 14 Sep 2010, Catalin Marinas wrote:
> > 
> > > I think the Thumb-2 branch goes up to 16MB range. The Thumb-1 may be
> > > smaller but we don't support this in the kernel. That's why Thumb-2
> > > modules are within 8MB below PAGE_OFFSET. But this leaves us with
> > > maximum 8MB of kernel size.
> > 
> > Hmmm.  Would be worth moving the pkmap area below modules then.
> 
> So currently the pkmap area is at PAGE_OFFSET - 2MB. On a Thumb-2 kernel
> with highmem enabled we would have 6MB available to modules. Is this big
> enough? If not, we could move the pkmap area.
> 
> BTW, can it be moved in the top part of the memory rather than below
> PAGE_OFFSET?

If you move it to the top part of memory, then it'll be about (sizeof
low memory) bytes - 32K away from the kernel code - which means it'll
mostly always be outside of the PC relative relocation range.

Indirecting all PC relative branches through trampolines quickly becomes
expensive, not only on CPUs which don't do branch prediction, but also
because of the mixed up code and data.

What might make sense is to move the init stuff between the kernel code
and kernel data - but that leads to a penalty of possibly 8 to 16K of
wasted space in the kernel image (for section alignment.)

I think we're better of staying as we are - thereby keeping the performance
for the majority use case, and telling those few people who want a massive
kernel binary not to do that.  In the case of a large initramfs, pass it
in as an initrd, possibly using the bootp stuff I've mentioned previously
if you want a single self-contained image.

Maximum bootable kernel size in current ARM linux

[Nicolas Pitre]

On Thu, 16 Sep 2010, Russell King - ARM Linux wrote:

> On Thu, Sep 16, 2010 at 06:16:51PM +0100, Catalin Marinas wrote:
> > On Tue, 2010-09-14 at 13:37 -0400, Nicolas Pitre wrote:
> > > On Tue, 14 Sep 2010, Catalin Marinas wrote:
> > > 
> > > > I think the Thumb-2 branch goes up to 16MB range. The Thumb-1 may be
> > > > smaller but we don't support this in the kernel. That's why Thumb-2
> > > > modules are within 8MB below PAGE_OFFSET. But this leaves us with
> > > > maximum 8MB of kernel size.
> > > 
> > > Hmmm.  Would be worth moving the pkmap area below modules then.
> > 
> > So currently the pkmap area is at PAGE_OFFSET - 2MB. On a Thumb-2 kernel
> > with highmem enabled we would have 6MB available to modules. Is this big
> > enough? If not, we could move the pkmap area.
> > 
> > BTW, can it be moved in the top part of the memory rather than below
> > PAGE_OFFSET?
> 
> If you move it to the top part of memory, then it'll be about (sizeof
> low memory) bytes - 32K away from the kernel code - which means it'll
> mostly always be outside of the PC relative relocation range.

This is a side discussion where I was talking about a possibly better 
location for the pkmap area, not the modules, given that the module area 
is made smaller with a T2 kernel.  I agree that moving modules at the 
top of memory is not a good idea, and moving the pkmap might not be a 
good idea either.  My suggestion was then to simply move it in the low 
8MB of the module space that is unused with a T2 kernel.

> Indirecting all PC relative branches through trampolines quickly becomes
> expensive, not only on CPUs which don't do branch prediction, but also
> because of the mixed up code and data.

Of course in that case it is best to interleave code and data but 
grouped on separate cache lines.

> What might make sense is to move the init stuff between the kernel code
> and kernel data - but that leads to a penalty of possibly 8 to 16K of
> wasted space in the kernel image (for section alignment.)

But that wasted space in the kernel image would be filled with zeroes 
and that usually compresses very well.  And since the use case would be 
for those people with big initramfs I doubt 16K makes a big difference 
to them.  But unless someone tries it out and provide numbers, I agree 
that this is not a pressing issue.



Nicolas

Maximum bootable kernel size in current ARM linux

[Catalin Marinas]

On Thu, 2010-09-16 at 18:51 +0100, Russell King - ARM Linux wrote:
> I think we're better of staying as we are - thereby keeping the performance
> for the majority use case, and telling those few people who want a massive
> kernel binary not to do that.  In the case of a large initramfs, pass it
> in as an initrd, possibly using the bootp stuff I've mentioned previously
> if you want a single self-contained image.

You can also create a big blob containing kernel and filesystem with
something like this (adapted for one's needs):

http://linux-arm.org/LinuxReference/RunningOnModel

-- 
Catalin

Maximum bootable kernel size in current ARM linux

[Nicolas Pitre]

On Thu, 16 Sep 2010, Catalin Marinas wrote:

> On Tue, 2010-09-14 at 13:37 -0400, Nicolas Pitre wrote:
> > On Tue, 14 Sep 2010, Catalin Marinas wrote:
> > 
> > > I think the Thumb-2 branch goes up to 16MB range. The Thumb-1 may be
> > > smaller but we don't support this in the kernel. That's why Thumb-2
> > > modules are within 8MB below PAGE_OFFSET. But this leaves us with
> > > maximum 8MB of kernel size.
> > 
> > Hmmm.  Would be worth moving the pkmap area below modules then.
> 
> So currently the pkmap area is at PAGE_OFFSET - 2MB. On a Thumb-2 kernel
> with highmem enabled we would have 6MB available to modules. Is this big
> enough? If not, we could move the pkmap area.

It is probably enough. But it is just not optimal.  If the area between 
TASK_SIZE and PAGE_OFFSET-8M is unused, then it would make sense to move 
the pkmap area there instead.

> BTW, can it be moved in the top part of the memory rather than below
> PAGE_OFFSET?

It could, but top memory layout tend to be machine specific, or already 
used by the consistent DMA.  And the module area is underused anyway.


Nicolas

Maximum bootable kernel size in current ARM linux

[Catalin Marinas]

On Thu, 2010-09-16 at 13:58 -0400, Nicolas Pitre wrote:
> On Thu, 16 Sep 2010, Catalin Marinas wrote:
> 
> > On Tue, 2010-09-14 at 13:37 -0400, Nicolas Pitre wrote:
> > > On Tue, 14 Sep 2010, Catalin Marinas wrote:
> > > 
> > > > I think the Thumb-2 branch goes up to 16MB range. The Thumb-1 may be
> > > > smaller but we don't support this in the kernel. That's why Thumb-2
> > > > modules are within 8MB below PAGE_OFFSET. But this leaves us with
> > > > maximum 8MB of kernel size.
> > > 
> > > Hmmm.  Would be worth moving the pkmap area below modules then.
> > 
> > So currently the pkmap area is at PAGE_OFFSET - 2MB. On a Thumb-2 kernel
> > with highmem enabled we would have 6MB available to modules. Is this big
> > enough? If not, we could move the pkmap area.
> 
> It is probably enough. But it is just not optimal.  If the area between 
> TASK_SIZE and PAGE_OFFSET-8M is unused, then it would make sense to move 
> the pkmap area there instead.

I agree.

-- 
Catalin

Maximum bootable kernel size in current ARM linux

[Russell King - ARM Linux]

On Mon, Sep 13, 2010 at 12:40:56AM -0700, Bruce M. Penrod wrote:
> This seems like a pretty straightforward question, but extensive web  
> searching hasn't shown a really clear, up-to-date answer.  The most  
> recent info is circa 2004 and states that 4MB is the largest  
> uncompressed ARM kernel that may be loaded.  Not being an ARM assembly  
> guru (head.S baffles me), I'd like to know if that is still true in  
> 2010, and if it is, why?

It is no longer true; the only limit now is the size of contiguous RAM
to fit the kernel image into.

Maximum bootable kernel size in current ARM linux

[Bruce M. Penrod]

Russell King - ARM Linux wrote:
> On Mon, Sep 13, 2010 at 12:40:56AM -0700, Bruce M. Penrod wrote:
>> This seems like a pretty straightforward question, but extensive web  
>> searching hasn't shown a really clear, up-to-date answer.  The most  
>> recent info is circa 2004 and states that 4MB is the largest  
>> uncompressed ARM kernel that may be loaded.  Not being an ARM assembly  
>> guru (head.S baffles me), I'd like to know if that is still true in  
>> 2010, and if it is, why?
> 
> It is no longer true; the only limit now is the size of contiguous RAM
> to fit the kernel image into.
> 

Interesting.  I finally was able to get an uncompressed kernel a little 
below 4MB, and now it boots.  I'm working with 2.6.35rc6 on an OpenRD 
Ultimate (Marvell Kirkwood) with Slackware, doing native compiles.  I'm 
wondering if there could be any problem with U-Boot for larger kernels 
than 4MB, but it doesn't complain and says that it is copying the image. 
  The symptom I had with a much larger kernel (~15MB) is a total hang, 
not even "Uncompressing linux".

I'll add some innocuous stuff back in until I get above 4MB again and 
see if it breaks again.
-- 
Bruce

Maximum bootable kernel size in current ARM linux

[Nicolas Pitre]

On Mon, 13 Sep 2010, Bruce M. Penrod wrote:

> 
> 
> Russell King - ARM Linux wrote:
> > On Mon, Sep 13, 2010 at 12:40:56AM -0700, Bruce M. Penrod wrote:
> > > This seems like a pretty straightforward question, but extensive web
> > > searching hasn't shown a really clear, up-to-date answer.  The most
> > > recent info is circa 2004 and states that 4MB is the largest  uncompressed
> > > ARM kernel that may be loaded.  Not being an ARM assembly  guru (head.S
> > > baffles me), I'd like to know if that is still true in  2010, and if it
> > > is, why?
> > 
> > It is no longer true; the only limit now is the size of contiguous RAM
> > to fit the kernel image into.
> > 
> 
> Interesting.  I finally was able to get an uncompressed kernel a little below
> 4MB, and now it boots.  I'm working with 2.6.35rc6 on an OpenRD Ultimate
> (Marvell Kirkwood) with Slackware, doing native compiles.  I'm wondering if
> there could be any problem with U-Boot for larger kernels than 4MB, but it
> doesn't complain and says that it is copying the image.  The symptom I had
> with a much larger kernel (~15MB) is a total hang, not even "Uncompressing
> linux".
> 
> I'll add some innocuous stuff back in until I get above 4MB again and see if
> it breaks again.

When it breaks, do you still see the "Uncompressing Linux... done, 
booting the kernel." message?


Nicolas

Maximum bootable kernel size in current ARM linux

[Bruce M. Penrod]

Nicolas Pitre wrote:
> On Mon, 13 Sep 2010, Bruce M. Penrod wrote:
> 
>>
>> Russell King - ARM Linux wrote:
>>> On Mon, Sep 13, 2010 at 12:40:56AM -0700, Bruce M. Penrod wrote:
>>>> This seems like a pretty straightforward question, but extensive web
>>>> searching hasn't shown a really clear, up-to-date answer.  The most
>>>> recent info is circa 2004 and states that 4MB is the largest  uncompressed
>>>> ARM kernel that may be loaded.  Not being an ARM assembly  guru (head.S
>>>> baffles me), I'd like to know if that is still true in  2010, and if it
>>>> is, why?
>>> It is no longer true; the only limit now is the size of contiguous RAM
>>> to fit the kernel image into.
>>>
>> Interesting.  I finally was able to get an uncompressed kernel a little below
>> 4MB, and now it boots.  I'm working with 2.6.35rc6 on an OpenRD Ultimate
>> (Marvell Kirkwood) with Slackware, doing native compiles.  I'm wondering if
>> there could be any problem with U-Boot for larger kernels than 4MB, but it
>> doesn't complain and says that it is copying the image.  The symptom I had
>> with a much larger kernel (~15MB) is a total hang, not even "Uncompressing
>> linux".
>>
>> I'll add some innocuous stuff back in until I get above 4MB again and see if
>> it breaks again.
> 
> When it breaks, do you still see the "Uncompressing Linux... done, 
> booting the kernel." message?
> 
> 
> Nicolas
> 

I think it depended upon how "too big" the kernel was.  With one only 
slightly larger than 4 MB, I did see "Uncompressing Linux...", but not 
"done, booting the kernel."  With a very large kernel (15MB), nothing 
printed at all.

I have not retested since successfully booting one slightly smaller than 
4096 * 1024.  When I do, I will post the results.  Should happen today.
-- 
Bruce

Maximum bootable kernel size in current ARM linux

[Nicolas Pitre]

On Tue, 14 Sep 2010, Bruce M. Penrod wrote:

> 
> 
> Nicolas Pitre wrote:
> > On Mon, 13 Sep 2010, Bruce M. Penrod wrote:
> > 
> > > 
> > > Russell King - ARM Linux wrote:
> > > > On Mon, Sep 13, 2010 at 12:40:56AM -0700, Bruce M. Penrod wrote:
> > > > > This seems like a pretty straightforward question, but extensive web
> > > > > searching hasn't shown a really clear, up-to-date answer.  The most
> > > > > recent info is circa 2004 and states that 4MB is the largest
> > > > > uncompressed
> > > > > ARM kernel that may be loaded.  Not being an ARM assembly  guru
> > > > > (head.S
> > > > > baffles me), I'd like to know if that is still true in  2010, and if
> > > > > it
> > > > > is, why?
> > > > It is no longer true; the only limit now is the size of contiguous RAM
> > > > to fit the kernel image into.
> > > > 
> > > Interesting.  I finally was able to get an uncompressed kernel a little
> > > below
> > > 4MB, and now it boots.  I'm working with 2.6.35rc6 on an OpenRD Ultimate
> > > (Marvell Kirkwood) with Slackware, doing native compiles.  I'm wondering
> > > if
> > > there could be any problem with U-Boot for larger kernels than 4MB, but it
> > > doesn't complain and says that it is copying the image.  The symptom I had
> > > with a much larger kernel (~15MB) is a total hang, not even "Uncompressing
> > > linux".
> > > 
> > > I'll add some innocuous stuff back in until I get above 4MB again and see
> > > if
> > > it breaks again.
> > 
> > When it breaks, do you still see the "Uncompressing Linux... done, booting
> > the kernel." message?
> > 
> > 
> > Nicolas
> > 
> 
> I think it depended upon how "too big" the kernel was.  With one only slightly
> larger than 4 MB, I did see "Uncompressing Linux...", but not "done, booting
> the kernel."  With a very large kernel (15MB), nothing printed at all.
> 
> I have not retested since successfully booting one slightly smaller than 4096
> * 1024.  When I do, I will post the results.  Should happen today.

OK.  Also please provide the size of your arch/arm/boot/zImage as well 
as arch/arm/boot/Image.  Also, at what address do you load your kernel 
in memory?


Nicolas

Maximum bootable kernel size in current ARM linux

[Bruce M. Penrod]

Nicolas Pitre wrote:
> On Tue, 14 Sep 2010, Bruce M. Penrod wrote:
> 
>>
>> Nicolas Pitre wrote:
>>> On Mon, 13 Sep 2010, Bruce M. Penrod wrote:
>>>
>>>> Russell King - ARM Linux wrote:
>>>>> On Mon, Sep 13, 2010 at 12:40:56AM -0700, Bruce M. Penrod wrote:
>>>>>> This seems like a pretty straightforward question, but extensive web
>>>>>> searching hasn't shown a really clear, up-to-date answer.  The most
>>>>>> recent info is circa 2004 and states that 4MB is the largest
>>>>>> uncompressed
>>>>>> ARM kernel that may be loaded.  Not being an ARM assembly  guru
>>>>>> (head.S
>>>>>> baffles me), I'd like to know if that is still true in  2010, and if
>>>>>> it
>>>>>> is, why?
>>>>> It is no longer true; the only limit now is the size of contiguous RAM
>>>>> to fit the kernel image into.
>>>>>
>>>> Interesting.  I finally was able to get an uncompressed kernel a little
>>>> below
>>>> 4MB, and now it boots.  I'm working with 2.6.35rc6 on an OpenRD Ultimate
>>>> (Marvell Kirkwood) with Slackware, doing native compiles.  I'm wondering
>>>> if
>>>> there could be any problem with U-Boot for larger kernels than 4MB, but it
>>>> doesn't complain and says that it is copying the image.  The symptom I had
>>>> with a much larger kernel (~15MB) is a total hang, not even "Uncompressing
>>>> linux".
>>>>
>>>> I'll add some innocuous stuff back in until I get above 4MB again and see
>>>> if
>>>> it breaks again.
>>> When it breaks, do you still see the "Uncompressing Linux... done, booting
>>> the kernel." message?
>>>
>>>
>>> Nicolas
>>>
>> I think it depended upon how "too big" the kernel was.  With one only slightly
>> larger than 4 MB, I did see "Uncompressing Linux...", but not "done, booting
>> the kernel."  With a very large kernel (15MB), nothing printed at all.
>>
>> I have not retested since successfully booting one slightly smaller than 4096
>> * 1024.  When I do, I will post the results.  Should happen today.
> 
> OK.  Also please provide the size of your arch/arm/boot/zImage as well 
> as arch/arm/boot/Image.  Also, at what address do you load your kernel 
> in memory?
> 
> 
> Nicolas

U-Boot loads the zImage at 0x800000.  Yesterday I added features back 
into the kernel and am up to 4600 * 1024 with no issues.  So definitely 
not a hard limit at 4MB.  It takes quite a while to compile on the 
OpenRD, so it may take a while for me to discover the magic combination 
that doesn't work.  I removed a LOT of stuff, and I'd rather add it back 
in gradually to get an idea whether it is a size issue or some bad other 
thing with a combination of options.

-- 
Bruce Penrod

Maximum bootable kernel size in current ARM linux

[Alexander Clouter]

Bruce M. Penrod <bmpenrod@endruntechnologies.com> wrote:
> 
> U-Boot loads the zImage at 0x800000.  Yesterday I added features back 
> into the kernel and am up to 4600 * 1024 with no issues.  So definitely 
> not a hard limit at 4MB.  It takes quite a while to compile on the 
> OpenRD, so it may take a while for me to discover the magic combination 
> that doesn't work.  I removed a LOT of stuff, and I'd rather add it back 
> in gradually to get an idea whether it is a size issue or some bad other 
> thing with a combination of options.
> 
Cross compiling is dead easy, if you are a Debian user (*always* use 
'lenny' for emdebian, even if you are locally using 'squeeze' or 'sid'):
----
# cat <<EOF > /etc/apt/sources.list.d/emdebian.list
deb http://www.emdebian.org/debian/ lenny main
EOF

# aptitude update
# aptitude install gcc-4.3-arm-linux-gnueabi libc6-dev-armel-cross
----

Then when cross compiling you can use the shell alias:
----
alias amake="ARCH=arm CROSS_COMPILE=arm-linux-gnueabi- make"
----

Then inside the Linux kernel directory just type 'amake menuconfig; 
amake'...much faster.

If you are not using Debian (why not? :) then you can use buildroot if 
your distro does not come with cross-compiling tools.  On my website I 
have a page describing the process for a MIPS platform, if you need any 
help do ask:

http://www.digriz.org.uk/wag54g

Cheers

-- 
Alexander Clouter
.sigmonster says: It's not the inital skirt length, it's the upcreep.

Maximum bootable kernel size in current ARM linux

[Nicolas Pitre]

On Wed, 15 Sep 2010, Bruce M. Penrod wrote:

> 
> 
> Nicolas Pitre wrote:
> > On Tue, 14 Sep 2010, Bruce M. Penrod wrote:
> > 
> > > I think it depended upon how "too big" the kernel was.  With one only
> > > slightly
> > > larger than 4 MB, I did see "Uncompressing Linux...", but not "done,
> > > booting
> > > the kernel."  With a very large kernel (15MB), nothing printed at all.
> > > 
> > > I have not retested since successfully booting one slightly smaller than
> > > 4096
> > > * 1024.  When I do, I will post the results.  Should happen today.
> > 
> > OK.  Also please provide the size of your arch/arm/boot/zImage as well as
> > arch/arm/boot/Image.  Also, at what address do you load your kernel in
> > memory?
> > 
> > 
> > Nicolas
> 
> U-Boot loads the zImage at 0x800000.  Yesterday I added features back into the
> kernel and am up to 4600 * 1024 with no issues.  So definitely not a hard
> limit at 4MB.  It takes quite a while to compile on the OpenRD, so it may take
> a while for me to discover the magic combination that doesn't work.  I removed
> a LOT of stuff, and I'd rather add it back in gradually to get an idea whether
> it is a size issue or some bad other thing with a combination of options.

There is definitely something in the code though.  It is assumed that 
the decompressed kernel code is 4 times larger than the compressed one.  
That is used to relocate the compressed kernel in case it was loaded in 
the final memory area where the decompressed kernel goes.  So two issues 
may occur:

1) Your decompressed kernel ends up being more than 4x larger than the 
   compressed one.  This would cause problems if the compressed data is 
   not moved away when it should be.

2) Your compressed kernel is big, but that's because it includes a big 
   initramfs or something similar which won't compress well.  In that 
   case the presumed 4x expansion factor might be way overestimated, and
   the location where to relocate the compressed kernel might end up 
   outside the available RAM if you don't have much of it.


Nicolas