[U-Boot-Users] [PATCH] Fix initrd/dtb interaction

Andy Fleming afleming at gmail.com
Tue Aug 14 09:00:13 CEST 2007


> > diff --git a/common/cmd_bootm.c b/common/cmd_bootm.c
> > index 2436581..580a9f0 100644
> > --- a/common/cmd_bootm.c
> > +++ b/common/cmd_bootm.c
> > @@ -21,6 +21,7 @@
> >   * MA 02111-1307 USA
> >   */
> >
> > +#define DEBUG

Oops.  That was a stupid oversight.

> >               of_len = be32_to_cpu(fdt_totalsize(of_data));
> > -             /* position on a 4K boundary before the initrd/kbd */
> > -             if (initrd_start)
> > -                     of_start = initrd_start - of_len;
> > -             else
> > -                     of_start  = (ulong)kbd - of_len;
> > +
> > +             /* position on a 4K boundary before the kbd */
> > +             of_start  = (ulong)kbd - of_len;
>
> Second, I asked you before to implement this similar like the  initrd
> location  can  be  controlled  using  the  "initrd_high"  environment
> variable (see my message Tue, 07 Aug 2007 21:21:19 +0200). AFAICT you
> never replied to this.


Sorry, I ended up replying more to gvb's comment.  The initrd can go
wherever it wants.  The address of the ramdisk is contained in the
blob, and the kernel will map memory using the blob.  But the blob has
to be accessed before the kernel maps that memory.

So we can add an environment variable to override the 16M limit for
u-boot, but if anyone sets it above 16M (on 85xx), it'll screw things
up.  I don't have a fundamental issue with such a variable being
added, but I don't think I have time to figure it out this week, and I
don't think it solves the problem (though it would allow users to
solve it).

In other words, I think we need both.  BOOTMAPSZ is clearly meant to
serve as a ceiling for things like the blob (the bd_t, for instance,
is always put in that range if it exists).  The environment variable
would give everyone more flexibility.  Sadly, though, I only have time
to fix the obvious problem (leaving DEBUG defined).  I'd be happy to
implement the environment variable for the *next* merge window, but
I'd really hate to let this bug sit in u-boot for another release.

Andy




More information about the U-Boot mailing list