Re: quik kernel size limit
On 14 Oct, this message from Benjamin Herrenschmidt echoed through
cyberspace:
>> 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 :-)
Cheers
Michel
-------------------------------------------------------------------------
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: