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 [EMAIL PROTECTED] | http://www.cpu.lu/~mlan | Learn Always. "
