"Myles Watson" <[email protected]> writes: >> >> 20M is indeed to small. >> > My understanding is that 20M is a location, not a size. >> >> Yes. >> >> >> The ramdisk (incl. kernel modules) is on the >> >> order of 26M; I've tried setting it to 32M - this setting is what >> allows >> >> the kernel to actually start; however (as previously mentioned), the >> >> kernel is unable to mount the ramdisk. >> > Because the kernel is looking at 20M and you moved it to 32M? >> >> No. These are the parameters passed to the kernel. What I have seen >> in the past is the ramdisk being loaded close enough to the kernel >> that the kernel stomps it, and corrupts it in early startup. This should >> be diagnosable by looking at the boot up messages from the kernel startup. > > Sorry I misunderstood. I'm surprised that 16M wasn't enough room to keep > the kernel from overwriting the initrd.
I am a bit surprised as well. It smells a bit like a kernel bug. To the wider audience I have a question. How do most folks making coreboot images use mkelfImage? With an uncompressed vmlinux? With a bzImage? At the moment I want to mandate a bzImage for x86, but I'm not certain if that is practical the way we build images for coreboot. Eric -- coreboot mailing list: [email protected] http://www.coreboot.org/mailman/listinfo/coreboot
