Message ID | 1480717624-24994-2-git-send-email-raltherr@google.com |
---|---|
State | Superseded, archived |
Headers | show |
On 2 December 2016 at 15:27, Rick Altherr <raltherr@google.com> wrote: > From: Cédric Le Goater <clg@kaod.org> > > Signed-off-by: Cédric Le Goater <clg@kaod.org> > Signed-off-by: Rick Altherr <raltherr@google.com> > --- > common/image.c | 11 ----------- > 1 file changed, 11 deletions(-) Reviewed-by: Simon Glass <sjg@chromium.org>
Hello, On 12/05/2016 07:24 AM, Simon Glass wrote: > On 2 December 2016 at 15:27, Rick Altherr <raltherr@google.com> wrote: >> From: Cédric Le Goater <clg@kaod.org> >> >> Signed-off-by: Cédric Le Goater <clg@kaod.org> >> Signed-off-by: Rick Altherr <raltherr@google.com> >> --- >> common/image.c | 11 ----------- >> 1 file changed, 11 deletions(-) > > Reviewed-by: Simon Glass <sjg@chromium.org> > So how do you fix the ramdisk loading ? is using the FIT images enough to work around this problem ? For legacy type images, this patch seemed to work : https://github.com/legoater/u-boot/commit/86fd073a12650ee7fc4e6514f2b0f159be275f29 I am not sure if this is a good approach though. Thanks, C.
See the next patch in this series. OpenBMC uses ATAGS when building a legacy image. U-Boot ATAGS support wasn't causing ramdisk relocation. It's not really a FIT vs legacy issue so much as a FDT vs ATAGS issue. We could still use legacy images with FDT and the ramdisk would be relocated fine. I fixed the ATAGS support to trigger ramdisk relocation as that's the actual bug. On Mon, Dec 5, 2016 at 12:13 AM, Cédric Le Goater <clg@kaod.org> wrote: > Hello, > > On 12/05/2016 07:24 AM, Simon Glass wrote: > > On 2 December 2016 at 15:27, Rick Altherr <raltherr@google.com> wrote: > >> From: Cédric Le Goater <clg@kaod.org> > >> > >> Signed-off-by: Cédric Le Goater <clg@kaod.org> > >> Signed-off-by: Rick Altherr <raltherr@google.com> > >> --- > >> common/image.c | 11 ----------- > >> 1 file changed, 11 deletions(-) > > > > Reviewed-by: Simon Glass <sjg@chromium.org> > > > > So how do you fix the ramdisk loading ? is using the FIT images > enough to work around this problem ? > > For legacy type images, this patch seemed to work : > > https://github.com/legoater/u-boot/commit/ > 86fd073a12650ee7fc4e6514f2b0f159be275f29 > > I am not sure if this is a good approach though. > > Thanks, > > C. >
diff --git a/common/image.c b/common/image.c index 20c4807..0be09e5 100644 --- a/common/image.c +++ b/common/image.c @@ -1069,17 +1069,6 @@ int boot_get_ramdisk(int argc, char * const argv[], bootm_headers_t *images, return 1; } } -/// TODO ... Check Why .................. -#if defined(CONFIG_ARCH_ASPEED) - /* - * We need to copy the ramdisk to SRAM to let Linux boot - */ - if (rd_data) { - memmove ((void *)rd_load, (uchar *)rd_data, rd_len); - rd_data = rd_load; - } -#endif /* CONFIG_ASPEED */ - } else if (images->legacy_hdr_valid && image_check_type(&images->legacy_hdr_os_copy, IH_TYPE_MULTI)) {