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
signature.asc
Description: This is a digitally signed message part
