hi, On Di, 2009-02-10 at 16:34 -0800, Marc Singer wrote: > > as soon as i switch to 16 blocks (2097152 bytes which is needed for the > > above kernel size) apex gets stuck at copying the kernel, after a day of > > digging top to bottom through slugimage and apex i still dont understand > > why this limitation exists, could someone enlighten me ? > > I responded to L. Minier with the suggestion that you move the load > address for the kernel to something after APEX. Try 0x01000000. You > could also change the VMA address for APEX to be 3MiB from the base of > RAM instead of 2MiB. thanks for the quick answer :) i got a booting image now, a few open questions remain though... after testing out both opportunities i personally prefer the APEX VMA address change since moving the kernel load address towards 0x01000000 indeed forces me to also move the ramdisk load adress away from 0x01000000 ... changing only one value as a delta against the default setup seems more appropriate here. wouldn't it make sense to use the 3 MiB setting in general in the debian config to add more flexibility to the defaults or are here drawbacks i dont see in this ? there is another issue i faced during my tinkering. raising the kernel partition to 16 blocks indeed shrinks my ramdisk partition by five blocks so the 0x005FFFF0 for CONFIG_RAMDISK_SIZE leaves me with a panicking kernel that doesnt find it's ramdisk (apparently all values between the actual initrd.gz size and the partition end (i.e. any corresponding value out of the zero padded area of the partition) seem to work for this setting) as there might be users that roll initramfs'es bigger than 5636080 bytes. is there any way around this limitation that i'm missing to see ? ciao oli
Attachment:
signature.asc
Description: This is a digitally signed message part