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

Re: using kernels bigger than 1966080 bytes on the nslug with slugimage



On Wed, Feb 11, 2009 at 05:04:20PM +0100, Oliver Grawert wrote:
> 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 ? 

No problem with is.

> 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 ? 

Ah yes, that configuration option can be made as large as you want.
It is a legacy that I've removed for some builds.  This value is only
used as the ramdisk size passed to the kernel.  There isn't a problem,
as far as I know, in setting this value to 8MiB.

Cheers.


Reply to: