On Thu, Jul 29, 2010 at 06:48:24PM -0700, Hollis Blanchard wrote: > The kernel's BSS size is lost by mkimage, which only considers file > size. As a result, loading other blobs (e.g. device tree, initrd) > immediately after the kernel location can result in them being zeroed by > the kernel's BSS initialization code. > > Signed-off-by: Hollis Blanchard <hollis@xxxxxxxxxxxxxx> > --- > hw/loader.c | 7 +++++++ > 1 files changed, 7 insertions(+), 0 deletions(-) > > diff --git a/hw/loader.c b/hw/loader.c > index 79a6f95..35bc25a 100644 > --- a/hw/loader.c > +++ b/hw/loader.c > @@ -507,6 +507,13 @@ int load_uimage(const char *filename, target_phys_addr_t *ep, > > ret = hdr->ih_size; > > + /* The kernel's BSS size is lost by mkimage, which only considers file > + * size. We don't know how big it is, but we do know we can't place > + * anything immediately after the kernel. The padding seems like it should > + * be proportional to overall file size, but we also make sure it's at > + * least 4-byte aligned. */ > + ret += (hdr->ih_size / 16) & ~0x3; Maybe it's only me, but it feels a bit akward to push down this kind of knowledge down the abstraction layers. Does it work for you to have your caller of load_uimage apply whatever resizing magic needed for your kernel and arch? Cheers -- To unsubscribe from this list: send the line "unsubscribe kvm-ppc" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
