<div dir="ltr">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.</div><div class="gmail_extra"><br><div class="gmail_quote">On Sun, Dec 4, 2016 at 10:24 PM, Simon Glass <span dir="ltr"><<a href="mailto:sjg@chromium.org" target="_blank">sjg@chromium.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi Rick,<br>
<span class=""><br>
On 2 December 2016 at 15:27, Rick Altherr <<a href="mailto:raltherr@google.com">raltherr@google.com</a>> wrote:<br>
> In 35fc84f, bootm was refactored so plain 'bootm' and<br>
> 'bootm <subcommand>' shared a common implementation.<br>
> The 'bootm ramdisk' command implementation is now part of the common<br>
> implementation but not invoke by plain 'bootm' since the original<br>
> implementation never did ramdisk relocation.  Instead, ramdisk<br>
> relocation happened in image_setup_linux() which is typically called<br>
> during the OS portion of 'bootm'.<br>
><br>
> On ARM, parameters to the Linux kernel can either be passed by FDT or<br>
> ATAGS. When using FDT, image_setup_linux() is called which also triggers<br>
> ramdisk relocation.  When using ATAGS, image_setup_linux() is _not_<br>
> called because it mostly does FDT setup.<br>
><br>
> Instead of calling image_setup_linux() in both FDT and ATAGS cases,<br>
> include BOOTM_STATE_RAMDISK in the requested states during a plain<br>
> 'bootm' if CONFIG_SYS_BOOT_RAMDISK_HIGH is set and remove the ramdisk<br>
> relocation from image_setup_linux().  This causes ramdisk relocation to<br>
> happen on any system where CONFIG_SYS_BOOT_RAMDISK_HIGH regardless of<br>
> the OS being booted.<br>
><br>
> Signed-off-by: Rick Altherr <<a href="mailto:raltherr@google.com">raltherr@google.com</a>><br>
> ---<br>
>  cmd/bootm.c    | 3 +++<br>
>  common/image.c | 7 -------<br>
>  2 files changed, 3 insertions(+), 7 deletions(-)<br>
<br>
</span>Reviewed-by: Simon Glass <<a href="mailto:sjg@chromium.org">sjg@chromium.org</a>><br>
<br>
But why would you still be using ATAGS?<br>
<br>
Regards,<br>
Simon<br>
</blockquote></div><br></div>