[U-Boot] image: fix Android ramdisk support when dtb is specified

If a dtb is specified on the command-line, the Android boot image ramdisk
will not be found. Fix this so that we can specify the ramdisk address and
dtb address. The syntax is to enter the Android boot image address for
both the kernel and ramdisk.

Signed-off-by: Rob Herring <robh@kernel.org>
---
 common/image.c | 18 ++++++++----------
 1 file changed, 8 insertions(+), 10 deletions(-)

On Fri, Jul 17, 2015 at 10:57:17AM -0500, Rob Herring wrote:

> If a dtb is specified on the command-line, the Android boot image ramdisk
> will not be found. Fix this so that we can specify the ramdisk address and
> dtb address. The syntax is to enter the Android boot image address for
> both the kernel and ramdisk.
> 
> Signed-off-by: Rob Herring <robh@kernel.org>

Applied to u-boot/master, thanks!

Le vendredi 17 juillet 2015 à 10:57 -0500, Rob Herring a écrit :
> If a dtb is specified on the command-line, the Android boot image ramdisk
> will not be found. Fix this so that we can specify the ramdisk address and
> dtb address. The syntax is to enter the Android boot image address for
> both the kernel and ramdisk.

This commit breaks booting non-fdt Android images (the kernel doesn't
find the initramfs, and neither does U-Boot).

The test to enter the code block where Android ramdisk support was moved
is accessed with:
else if (select || genimg_has_config(images)) {

However, in a non-fdt context, select is NULL and genimg_has_config
returns 0.

I suggest we either duplicate Android ramdisk support in the non-fdt
path or adapt the condition to enter the code block where it was moved.

> Signed-off-by: Rob Herring <robh@kernel.org>
> ---
>  common/image.c | 18 ++++++++----------
>  1 file changed, 8 insertions(+), 10 deletions(-)
> 
> diff --git a/common/image.c b/common/image.c
> index f0f0135..73fc288 100644
> --- a/common/image.c
> +++ b/common/image.c
> @@ -896,6 +896,7 @@ int boot_get_ramdisk(int argc, char * const argv[], bootm_headers_t *images,
>  
>  	if (argc >= 2)
>  		select = argv[1];
> +
>  	/*
>  	 * Look for a '-' which indicates to ignore the
>  	 * ramdisk argument
> @@ -995,6 +996,12 @@ int boot_get_ramdisk(int argc, char * const argv[], bootm_headers_t *images,
>  			images->fit_noffset_rd = rd_noffset;
>  			break;
>  #endif
> +#ifdef CONFIG_ANDROID_BOOT_IMAGE
> +		case IMAGE_FORMAT_ANDROID:
> +			android_image_get_ramdisk((void *)images->os.start,
> +				&rd_data, &rd_len);
> +			break;
> +#endif
>  		default:
>  #ifdef CONFIG_SUPPORT_RAW_INITRD
>  			end = NULL;
> @@ -1025,16 +1032,7 @@ int boot_get_ramdisk(int argc, char * const argv[], bootm_headers_t *images,
>  				(ulong)images->legacy_hdr_os);
>  
>  		image_multi_getimg(images->legacy_hdr_os, 1, &rd_data, &rd_len);
> -	}
> -#ifdef CONFIG_ANDROID_BOOT_IMAGE
> -	else if ((genimg_get_format((void *)images->os.start)
> -			== IMAGE_FORMAT_ANDROID) &&
> -		 (!android_image_get_ramdisk((void *)images->os.start,
> -		 &rd_data, &rd_len))) {
> -		/* empty */
> -	}
> -#endif
> -	else {
> +	} else {
>  		/*
>  		 * no initrd image
>  		 */

On Thu, Aug 27, 2015 at 08:22:36PM +0200, Paul Kocialkowski wrote:
> Le vendredi 17 juillet 2015 à 10:57 -0500, Rob Herring a écrit :
> > If a dtb is specified on the command-line, the Android boot image ramdisk
> > will not be found. Fix this so that we can specify the ramdisk address and
> > dtb address. The syntax is to enter the Android boot image address for
> > both the kernel and ramdisk.
> 
> This commit breaks booting non-fdt Android images (the kernel doesn't
> find the initramfs, and neither does U-Boot).
> 
> The test to enter the code block where Android ramdisk support was moved
> is accessed with:
> else if (select || genimg_has_config(images)) {
> 
> However, in a non-fdt context, select is NULL and genimg_has_config
> returns 0.
> 
> I suggest we either duplicate Android ramdisk support in the non-fdt
> path or adapt the condition to enter the code block where it was moved.

I've taken a third path, make the code check for Android images and then
"know" what the address we want to check should be.  Let me know if that
patch fixes your problem, thanks!