[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: quik kernel size limit

On  14 Oct, this message from Benjamin Herrenschmidt echoed through
>> Recently it was discussed here whether quik has a limit on kernel
>> size.
>> Well, while playing with 2.6 kernels I found out: yes, quik _does_
>> have a limit on kernel size. It is exactly 3981312 bytes. In fact,
>> quik allocates a fixed-size buffer in which the kernel is loaded, and
>> that buffer is from 0x14000 to SECOND_BASE (second/main.c), and
>> SECOND_BASE is 0x3e0000 (include/layout.h).
> And you can't extend it as those oldworld OFs love to have things
> of their own between 0x3e0000 and 0x500000.

OK, but what are the options for 2.6 kernels? Is it possible to compile
kernels small enough?

> What I did to 'fix'
> coffboot (but that means I bumped the minimal mem requirement to 16Mb)
> was to load the kernel at 0x800000 instead. That gives me 8Mb for 8Mb
> to 16Mb, though with quik, you can probably load it a bit lower than
> that (depends where quik itself is linked). For coffboot, I needed the
> room between 5Mb and 8Mb for the compressed image. Actually, I even
> bumped that to 5Mb to 9Mb and from 9Mb to 16Mb for the kernel+ramdisk
> Note also that when doing that, you also want to:
>  - Update the BAT mapping code to map 16Mb instead of just 8
>  - Use an OF map() call to create a 1:1 mapping in the OF own
>    tables (not that the MAP may be useless thanks to that mapping,
>    but we keep it for efficiency on oldworld). Without this map()
>    call, you'll end up with the OF "translate" call failing in the
>    kernel entry.

Anybody up for hacking this into quik? Not me :-)



Michel Lanners                 |  " Read Philosophy.  Study Art.
23, Rue Paul Henkes            |    Ask Questions.  Make Mistakes.
L-1710 Luxembourg              |
email   mlan@cpu.lu            |
http://www.cpu.lu/~mlan        |                     Learn Always. "

Reply to: