[PATCH u-boot v2 2/3] bootm: relocate ramdisk if CONFIG_SYS_BOOT_RAMDISK_HIGH set

Rick Altherr raltherr at google.com
Tue Dec 6 05:01:43 AEDT 2016


I think that is an artifact of starting from the Aspeed SDK.  Once these
changes are in, I plan to propose changing to FIT+FDT.

On Sun, Dec 4, 2016 at 10:24 PM, Simon Glass <sjg at chromium.org> wrote:

> Hi Rick,
>
> On 2 December 2016 at 15:27, Rick Altherr <raltherr at google.com> wrote:
> > In 35fc84f, bootm was refactored so plain 'bootm' and
> > 'bootm <subcommand>' shared a common implementation.
> > The 'bootm ramdisk' command implementation is now part of the common
> > implementation but not invoke by plain 'bootm' since the original
> > implementation never did ramdisk relocation.  Instead, ramdisk
> > relocation happened in image_setup_linux() which is typically called
> > during the OS portion of 'bootm'.
> >
> > On ARM, parameters to the Linux kernel can either be passed by FDT or
> > ATAGS. When using FDT, image_setup_linux() is called which also triggers
> > ramdisk relocation.  When using ATAGS, image_setup_linux() is _not_
> > called because it mostly does FDT setup.
> >
> > Instead of calling image_setup_linux() in both FDT and ATAGS cases,
> > include BOOTM_STATE_RAMDISK in the requested states during a plain
> > 'bootm' if CONFIG_SYS_BOOT_RAMDISK_HIGH is set and remove the ramdisk
> > relocation from image_setup_linux().  This causes ramdisk relocation to
> > happen on any system where CONFIG_SYS_BOOT_RAMDISK_HIGH regardless of
> > the OS being booted.
> >
> > Signed-off-by: Rick Altherr <raltherr at google.com>
> > ---
> >  cmd/bootm.c    | 3 +++
> >  common/image.c | 7 -------
> >  2 files changed, 3 insertions(+), 7 deletions(-)
>
> Reviewed-by: Simon Glass <sjg at chromium.org>
>
> But why would you still be using ATAGS?
>
> Regards,
> Simon
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ozlabs.org/pipermail/openbmc/attachments/20161205/2787488b/attachment-0001.html>


More information about the openbmc mailing list