Re: [U-Boot] SPDX header might be wrong in 4 files from Android Open Source Project

[Alex Deymo]

Le lun. 25 nov. 2019 à 17:20, Igor Opaniuk  a
écrit :

> + Alex Deymo
>
> Hi Zdenek
>
> On Mon, Nov 25, 2019 at 6:05 PM zdenek.bou...@siemens.com
>  wrote:
> >
> > Hello,
> >
> > SPDX-License-Identifier: BSD-3-Clause might be wrong in the following 4
> files from Android Open Source Project (AOSP):
> >
> > include/android_bootloader_message.h
> > include/sparse_format.h
> > include/dt_table.h
> > include/android_image.h
>
> they were re-licensed by one of the Google employees specifically for
> U-boot [1].
>

That's correct, I tried to make this re-licensing step explicit in the
commit message. I sent the patches to add these headers re-licensed to
BSD-3 after checking with our Opensource Releasing Team and they were OK
with it in these particular cases. The original headers were Copyright "The
Android Open Source Project".

If you need help importing other AOSP headers with BSD-3 license instead of
the one we normally use in AOSP (Apache 2) I might be able to help with
that, but I do need to check with the team first.

Best regards,
deymo@
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

[U-Boot] [PATCH] Update include/android_image.h from AOSP

[Alex Deymo]

This takes the latest changes from AOSP from the file
include/bootimg/bootimg.h from the repository:
https://android.googlesource.com/platform/system/tools/mkbootimg
and update the U-Boot version with the latest changes.

This file keeps the changes from AOSP to a minimum:
 * Comments were converted from C++ to C style.
 * Code inside __cplusplus #ifdef blocks were removed.
 * C++11 struct extensions replaced with a single struct.

Signed-off-by: Alex Deymo 
---
 include/android_image.h | 120 ++--
 1 file changed, 90 insertions(+), 30 deletions(-)

diff --git a/include/android_image.h b/include/android_image.h
index d78db9e2b7..0519ece368 100644
--- a/include/android_image.h
+++ b/include/android_image.h
@@ -1,59 +1,78 @@
-/* SPDX-License-Identifier: BSD-2-Clause */
+/* SPDX-License-Identifier: BSD-3-Clause */
 /*
  * This is from the Android Project,
- * Repository: https://android.googlesource.com/platform/system/core/
- * File: mkbootimg/bootimg.h
- * Commit: d162828814b08ada310846a33205befb69ef5799
+ * Repository: https://android.googlesource.com/platform/system/tools/mkbootimg
+ * File: include/bootimg/bootimg.h
+ * Commit: e55998a0f2b61b685d5eb4a486ca3a0c680b1a2f
  *
- * Copyright (C) 2008 The Android Open Source Project
+ * Copyright (C) 2007 The Android Open Source Project
  */
 
 #ifndef _ANDROID_IMAGE_H_
 #define _ANDROID_IMAGE_H_
 
-typedef struct andr_img_hdr andr_img_hdr;
-
 #define ANDR_BOOT_MAGIC "ANDROID!"
 #define ANDR_BOOT_MAGIC_SIZE 8
 #define ANDR_BOOT_NAME_SIZE 16
 #define ANDR_BOOT_ARGS_SIZE 512
 #define ANDR_BOOT_EXTRA_ARGS_SIZE 1024
 
+/*
+ * It is expected that callers would explicitly specify which version of the
+ * boot image header they need to use.
+ */
+typedef struct andr_img_hdr andr_img_hdr;
+
+/* The bootloader expects the structure of andr_img_hdr with header
+ * version 0 to be as follows: */
 struct andr_img_hdr {
-   char magic[ANDR_BOOT_MAGIC_SIZE];
+/* Must be ANDR_BOOT_MAGIC. */
+char magic[ANDR_BOOT_MAGIC_SIZE];
 
-   u32 kernel_size;/* size in bytes */
-   u32 kernel_addr;/* physical load addr */
+u32 kernel_size; /* size in bytes */
+u32 kernel_addr; /* physical load addr */
 
-   u32 ramdisk_size;   /* size in bytes */
-   u32 ramdisk_addr;   /* physical load addr */
+u32 ramdisk_size; /* size in bytes */
+u32 ramdisk_addr; /* physical load addr */
 
-   u32 second_size;/* size in bytes */
-   u32 second_addr;/* physical load addr */
+u32 second_size; /* size in bytes */
+u32 second_addr; /* physical load addr */
 
-   u32 tags_addr;  /* physical addr for kernel tags */
-   u32 page_size;  /* flash page size we assume */
-   u32 unused; /* reserved for future expansion: MUST be 0 */
+u32 tags_addr; /* physical addr for kernel tags */
+u32 page_size; /* flash page size we assume */
 
-   /* operating system version and security patch level; for
-* version "A.B.C" and patch level "Y-M-D":
-* ver = A << 14 | B << 7 | C (7 bits for each of A, B, C)
-* lvl = ((Y - 2000) & 127) << 4 | M  (7 bits for Y, 4 bits for M)
-* os_version = ver << 11 | lvl */
-   u32 os_version;
+/* Version of the boot image header. */
+u32 header_version;
 
-   char name[ANDR_BOOT_NAME_SIZE]; /* asciiz product name */
+/* Operating system version and security patch level.
+ * For version "A.B.C" and patch level "Y-M-D":
+ *   (7 bits for each of A, B, C; 7 bits for (Y-2000), 4 bits for M)
+ *   os_version = A[31:25] B[24:18] C[17:11] (Y-2000)[10:4] M[3:0] */
+u32 os_version;
 
-   char cmdline[ANDR_BOOT_ARGS_SIZE];
+char name[ANDR_BOOT_NAME_SIZE]; /* asciiz product name */
 
-   u32 id[8]; /* timestamp / checksum / sha1 / etc */
+char cmdline[ANDR_BOOT_ARGS_SIZE];
 
-   /* Supplemental command line data; kept here to maintain
-* binary compatibility with older versions of mkbootimg */
-   char extra_cmdline[ANDR_BOOT_EXTRA_ARGS_SIZE];
+u32 id[8]; /* timestamp / checksum / sha1 / etc */
+
+/* Supplemental command line data; kept here to maintain
+ * binary compatibility with older versions of mkbootimg. */
+char extra_cmdline[ANDR_BOOT_EXTRA_ARGS_SIZE];
+
+/* Fields in boot_img_hdr_v1 and newer. */
+u32 recovery_dtbo_size;   /* size in bytes for recovery DTBO/ACPIO image */
+u64 recovery_dtbo_offset; /* offset to recovery dtbo/acpio in boot image */
+u32 header_size;
+
+/* Fields in boot_img_hdr_v2 and newer. */
+u32 dtb_size; /* size in bytes for DTB image */
+u64 dtb_addr; /* physical load address for DTB image */
 } __attribute__((packed));
 
-/*
+/* When a boot header is of version 0, the structure of boot image is as
+ * follows:
+ *
  * +-+
  * | boot head

[U-Boot] [PATCH] Import include/android_bootloader_message.h from AOSP

[Alex Deymo]

This takes the latest changes from AOSP from the file
bootloader_message/include/bootloader_message/bootloader_message.h
in the repository
https://android.googlesource.com/platform/bootable/recovery
and re-licensed them to BSD-3 for U-Boot.

Minimum local changes have been applied (convert C++ to C comments and
adding #ifndef __UBOOT__ block to skip all the function declarations).

Signed-off-by: Alex Deymo 
---
 include/android_bootloader_message.h | 246 +++
 1 file changed, 246 insertions(+)
 create mode 100644 include/android_bootloader_message.h

diff --git a/include/android_bootloader_message.h 
b/include/android_bootloader_message.h
new file mode 100644
index 00..b84789f022
--- /dev/null
+++ b/include/android_bootloader_message.h
@@ -0,0 +1,246 @@
+/*
+ * This is from the Android Project,
+ * Repository: https://android.googlesource.com/platform/bootable/recovery
+ * File: bootloader_message/include/bootloader_message/bootloader_message.h
+ * Commit: c784ce50e8c10eaf70e1f97e24e8324aef45faf5
+ *
+ * Copyright (C) 2008 The Android Open Source Project
+ *
+ * SPDX-License-Identifier: BSD-3-Clause
+ */
+
+#ifndef __ANDROID_BOOTLOADER_MESSAGE_H
+#define __ANDROID_BOOTLOADER_MESSAGE_H
+
+/* compiler.h defines the types that otherwise are included from stdint.h and
+ * stddef.h
+ */
+#include 
+
+/* Spaces used by misc partition are as below:
+ * 0   - 2K For bootloader_message
+ * 2K  - 16KUsed by Vendor's bootloader (the 2K - 4K range may be 
optionally used
+ *  as bootloader_message_ab struct)
+ * 16K - 64KUsed by uncrypt and recovery to store wipe_package for A/B 
devices
+ * Note that these offsets are admitted by bootloader,recovery and uncrypt, so 
they
+ * are not configurable without changing all of them. */
+static const size_t BOOTLOADER_MESSAGE_OFFSET_IN_MISC = 0;
+static const size_t WIPE_PACKAGE_OFFSET_IN_MISC = 16 * 1024;
+
+/* Bootloader Message (2-KiB)
+ *
+ * This structure describes the content of a block in flash
+ * that is used for recovery and the bootloader to talk to
+ * each other.
+ *
+ * The command field is updated by linux when it wants to
+ * reboot into recovery or to update radio or bootloader firmware.
+ * It is also updated by the bootloader when firmware update
+ * is complete (to boot into recovery for any final cleanup)
+ *
+ * The status field was used by the bootloader after the completion
+ * of an "update-radio" or "update-hboot" command, which has been
+ * deprecated since Froyo.
+ *
+ * The recovery field is only written by linux and used
+ * for the system to send a message to recovery or the
+ * other way around.
+ *
+ * The stage field is written by packages which restart themselves
+ * multiple times, so that the UI can reflect which invocation of the
+ * package it is.  If the value is of the format "#/#" (eg, "1/3"),
+ * the UI will add a simple indicator of that status.
+ *
+ * We used to have slot_suffix field for A/B boot control metadata in
+ * this struct, which gets unintentionally cleared by recovery or
+ * uncrypt. Move it into struct bootloader_message_ab to avoid the
+ * issue.
+ */
+struct bootloader_message {
+char command[32];
+char status[32];
+char recovery[768];
+
+/* The 'recovery' field used to be 1024 bytes.  It has only ever
+ * been used to store the recovery command line, so 768 bytes
+ * should be plenty.  We carve off the last 256 bytes to store the
+ * stage string (for multistage packages) and possible future
+ * expansion. */
+char stage[32];
+
+/* The 'reserved' field used to be 224 bytes when it was initially
+ * carved off from the 1024-byte recovery field. Bump it up to
+ * 1184-byte so that the entire bootloader_message struct rounds up
+ * to 2048-byte. */
+char reserved[1184];
+};
+
+/**
+ * We must be cautious when changing the bootloader_message struct size,
+ * because A/B-specific fields may end up with different offsets.
+ */
+#if (__STDC_VERSION__ >= 201112L) || defined(__cplusplus)
+static_assert(sizeof(struct bootloader_message) == 2048,
+  "struct bootloader_message size changes, which may break A/B 
devices");
+#endif
+
+/**
+ * The A/B-specific bootloader message structure (4-KiB).
+ *
+ * We separate A/B boot control metadata from the regular bootloader
+ * message struct and keep it here. Everything that's A/B-specific
+ * stays after struct bootloader_message, which should be managed by
+ * the A/B-bootloader or boot control HAL.
+ *
+ * The slot_suffix field is used for A/B implementations where the
+ * bootloader does not set the androidboot.ro.boot.slot_suffix kernel
+ * commandline parameter. This is used by fs_mgr to mount /system and
+ * other partitions with the slotselect flag set in fstab. A/B
+ * implementations are free to use all 32 bytes and may store private
+ * data past the fi

[U-Boot] [PATCH] Import Android's dt_table.h for DT image format

[Alex Deymo]

Android documentation defines the recommended image format for storing
DTB/DTBO files in a single dtbo.img image. This patch includes the
latest header file with the struct definitions for this format from
AOSP.

The header was adapted to U-Boot's coding style and the function
declarations were removed.

Signed-off-by: Alex Deymo 
---
 include/dt_table.h | 50 ++
 1 file changed, 50 insertions(+)
 create mode 100644 include/dt_table.h

diff --git a/include/dt_table.h b/include/dt_table.h
new file mode 100644
index 000..f91657c0c76
--- /dev/null
+++ b/include/dt_table.h
@@ -0,0 +1,50 @@
+/*
+ * This is from the Android Project,
+ * Repository: https://android.googlesource.com/platform/system/libufdt
+ * File: utils/src/dt_table.h
+ * Commit: 2626d8b9e4d8e8c6cc67ceb1dc4e05a47779785c
+ * Copyright (C) 2017 The Android Open Source Project
+ *
+ * SPDX-License-Identifier: BSD-3-Clause
+ */
+
+#ifndef DT_TABLE_H
+#define DT_TABLE_H
+
+#include 
+
+#define DT_TABLE_MAGIC 0xd7b7ab1e
+#define DT_TABLE_DEFAULT_PAGE_SIZE 2048
+#define DT_TABLE_DEFAULT_VERSION   0
+
+struct dt_table_header {
+   u32 magic;  /* DT_TABLE_MAGIC */
+   u32 total_size; /* includes dt_table_header + all dt_table_entry
+* and all dtb/dtbo
+*/
+   u32 header_size;/* sizeof(dt_table_header) */
+
+   u32 dt_entry_size;  /* sizeof(dt_table_entry) */
+   u32 dt_entry_count; /* number of dt_table_entry */
+   u32 dt_entries_offset;  /* offset to the first dt_table_entry
+* from head of dt_table_header.
+* The value will be equal to header_size if
+* no padding is appended
+*/
+   u32 page_size;  /* flash page size we assume */
+   u32 version;/* DTBO image version, the current version is 0.
+* The version will be incremented when the
+* dt_table_header struct is updated.
+*/
+};
+
+struct dt_table_entry {
+   u32 dt_size;
+   u32 dt_offset;  /* offset from head of dt_table_header */
+
+   u32 id; /* optional, must be zero if unused */
+   u32 rev;/* optional, must be zero if unused */
+   u32 custom[4];  /* optional, must be zero if unused */
+};
+
+#endif
-- 
2.17.0.921.gf22659ad46-goog

___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

[U-Boot] FYI: Android bootloader flow documentation published

[Alex Deymo]

Just an FYI, earlier this month the team spent some time polishing and
publishing in source.android.com documentation about the flows the
bootloader goes through in Android, specially true for stock Android like
in Pixels phones or other devices based of recent AOSP versions.

Take a look at https://source.android.com/devices/bootloader/

This documentation includes the interaction between userspace and the
bootloader such as the properties userspace expects when booting A/B
devices, the whole A/B flow, the bootloader message in the misc partition
(BCB), how they interact with the "recovery mode" in Android and much more.

Let us know if you have any feedback.
deymo@
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [U-Boot, v2, 1/2] common: Add support for Android DT image

[Alex Deymo]

Hi,
I checked with our team and the include/dt_table.h import as BSD-3 here is
fine with us. Would you like me to send a patch with just this header file
or just Signed-off-by this whole patch?
Thanks,
deymo@

Le ven. 25 mai 2018 à 03:54, Tom Rini  a écrit :

> On Fri, May 18, 2018 at 09:47:55PM +0300, Sam Protsenko wrote:
> > On 16 May 2018 at 15:08, Tom Rini  wrote:
> > > On Thu, Apr 19, 2018 at 11:51:36PM +0300, Sam Protsenko wrote:
> > >
> > >> Android documentation recommends new image format for storing DTB/DTBO
> > >> files: [1]. To support that format, two things should be done:
> > >>
> > >> 1. Add dt_table.h file from Android (BSD-3 relicensed version): [2].
> > >>This header defines structures and constants that we need to work
> > >>with that DT image format.
> > >>
> > >>Changes:
> > >> - re-licensed from Apache to BSD-3
> > >> - removed functions declarations
> > >> - change the coding style to kernel (make checkpatch happy)
> > >>
> > >> 2. Add helper functions for Android DTB/DTBO format. In
> > >>image-android-dt.* files you can find helper functions to work with
> > >>Android DT image format, such us routines for:
> > >> - printing the dump of image structure
> > >> - getting the address and size of desired dtb/dtbo file
> > >>
> > >> [1] https://source.android.com/devices/architecture/dto/partitions
> > >> [2]
> https://android.googlesource.com/platform/system/libufdt/+/58a7582180f477032cd6c74f8d9afad0038e74c3/utils/src/dt_table.h
> > >>
> > >> Signed-off-by: Sam Protsenko 
> > >
> > > Why is it OK to change the license on the code?  AFAICT someone can't
> > > just relicense Apache to BSD-3.  What happened for
> > > include/android_image.h was that Google relicensed the Android code in
> > > question to BSD-2 (which in turn allows us in GPL projects).  Thanks!
> >
> > Ok, I will try to ask Google to do the same for the header I used. Do
> > you know what exactly should be done? Do they need to publish
> > relicensed file somewhere, or exactly in Android, or we just need a
> > confirmation from their side? Also, which license is preferable for
> > us?
>
> I believe Alex helped us last time, and it was done, iirc, by someone
> from Google submitting the file with the license we need and a
> Signed-off-by from their google.com address.
>
> --
> Tom
>
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH v2 1/2] common: Add support for Android DT image

[Alex Deymo]

 * no padding is appended
> +*/
> +   u32 page_size;  /* flash page size we assume */
> +   u32 reserved[1];/* must be zero */
> +};
> +
> +struct dt_table_entry {
> +   u32 dt_size;
> +   u32 dt_offset;  /* offset from head of dt_table_header */
> +
> +   u32 id; /* optional, must be zero if unused */
> +   u32 rev;/* optional, must be zero if unused */
> +   u32 custom[4];  /* optional, must be zero if unused */
> +};
> +
> +#endif
> diff --git a/include/image-android-dt.h b/include/image-android-dt.h
> new file mode 100644
> index 00..08b810d461
> --- /dev/null
> +++ b/include/image-android-dt.h
> @@ -0,0 +1,21 @@
> +/*
> + * (C) Copyright 2018 Linaro Ltd.
> + * Sam Protsenko 
> + *
> + * SPDX-License-Identifier:GPL-2.0+
> + */
> +
> +#ifndef IMAGE_ANDROID_DT_H
> +#define IMAGE_ANDROID_DT_H
> +
> +#include 
> +
> +bool android_dt_check_header(ulong hdr_addr);
> +bool android_dt_get_fdt_by_index(ulong hdr_addr, u32 index, ulong *addr,
> +u32 *size);
> +
> +#if !defined(CONFIG_SPL_BUILD)
> +void android_dt_print_contents(ulong hdr_addr);
> +#endif
> +
> +#endif /* IMAGE_ANDROID_DT_H */
> --
> 2.17.0
>

I haven't test this. Again, you probably want some maintainer to take a
look too.
Reviewed-by: Alex Deymo 

Regards,
Alex
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH v2 2/2] cmd: Add dtimg command

[Alex Deymo]

har * const argv[])
> +{
> +   return dtimg_get_fdt(argc, argv, CMD_DTIMG_START);
> +}
> +
> +static int do_dtimg_size(cmd_tbl_t *cmdtp, int flag, int argc,
> +char * const argv[])
> +{
> +   return dtimg_get_fdt(argc, argv, CMD_DTIMG_SIZE);
> +}
> +
> +static cmd_tbl_t cmd_dtimg_sub[] = {
> +   U_BOOT_CMD_MKENT(dump, 2, 0, do_dtimg_dump, "", ""),
> +   U_BOOT_CMD_MKENT(start, 4, 0, do_dtimg_start, "", ""),
> +   U_BOOT_CMD_MKENT(size, 4, 0, do_dtimg_size, "", ""),
> +};
> +
> +static int do_dtimg(cmd_tbl_t *cmdtp, int flag, int argc, char * const
> argv[])
> +{
> +   cmd_tbl_t *cp;
> +
> +   cp = find_cmd_tbl(argv[1], cmd_dtimg_sub,
> ARRAY_SIZE(cmd_dtimg_sub));
> +
> +   /* Strip off leading 'dtimg' command argument */
> +   argc--;
> +   argv++;
> +
> +   if (!cp || argc > cp->maxargs)
> +   return CMD_RET_USAGE;
> +   if (flag == CMD_FLAG_REPEAT && !cp->repeatable)
> +   return CMD_RET_SUCCESS;
> +
> +   return cp->cmd(cmdtp, flag, argc, argv);
> +}
> +
> +U_BOOT_CMD(
> +   dtimg, CONFIG_SYS_MAXARGS, 0, do_dtimg,
> +   "manipulate dtb/dtbo Android image",
> +   "dump \n"
>
"dtimg dump \n"


> +   "- parse specified image and print its structure info\n"
> +   "  : image address in RAM, in hex\n"
> +   "dtimg start   \n"
> +   "- get address (hex) of FDT in the image, by index\n"
> +   "  : image address in RAM, in hex\n"
> +   "  : index of desired FDT in the image\n"
> +   "  : name of variable where to store address of FDT\n"
> +   "dtimg size   \n"
> +   "- get size (hex, bytes) of FDT in the image, by index\n"
> +   "  : image address in RAM, in hex\n"
> +   "  : index of desired FDT in the image\n"
> +   "  : name of variable where to store size of FDT"
> +);
> diff --git a/common/Makefile b/common/Makefile
> index 7011dada99..6ef55d0d7a 100644
> --- a/common/Makefile
> +++ b/common/Makefile
> @@ -111,6 +111,10 @@ obj-$(CONFIG_IO_TRACE) += iotrace.o
>  obj-y += memsize.o
>  obj-y += stdio.o
>
> +ifdef CONFIG_CMD_DTIMG
> +obj-y += image-android-dt.o
> +endif
> +
>  ifndef CONFIG_SPL_BUILD
>  # This option is not just y/n - it can have a numeric value
>  ifdef CONFIG_FASTBOOT_FLASH
> --
> 2.17.0
>

You would likely need review from a maintainer, but otherwise this looks
fine (just one nit)
Reviewed-by: Alex Deymo 
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] Appended DTB Android boot image support

[Alex Deymo]

Hi Ramon,

What "header_version" is the boot image you have? The
include/android_image.h in U-Boot is a little bit old so it only defines
the v0 format. The "unused" field in v0 was renamed to "header_version"
where 0 means v0. The v1 adds a few more fields, including a DTB/DTBO for
*recovery* mode.
See
https://android.googlesource.com/platform/system/core/+/master/mkbootimg/include/bootimg/bootimg.h

Having multiple DTs and picking one or merge overlays at runtime is a
reasonable thing and there's some documentation in AOSP on how to do it in
Android: https://source.android.com/devices/architecture/dto/multiple (and
other sections around it). There are some options on where to store these
and even a supported format for placing multiple .dtbo in a single "dtbo"
partition (but appending multiple DTBs at the end of the kernel is not one
of these).

Which are the "seconday" fields you are referring to?
I'm not familiar with the Dragonboard images, but it looks like they just
extended this over the reserved space in a different way. Maybe you can
convert the header to the newer format, but that still requires work in
U-Boot to support the new format.

Regards,
Alex


Le lun. 30 avr. 2018 à 16:17, Ramon Fried  a écrit :

> Hi all.
> I'm currently adding support for Qualcomm Dragonboards  to U-boot as a
> primary bootloader without chain-loading using LK which is currently
> already supported in mainline U-boot.
>
> Qualcomm Android images are regular android images where the DTB's are
> appended to the image. Qualcomm used the "unused" field in the image
> header to populate the size of the DTB *.
>
> I'm looking for a more standard version for supporting these kind of
> images.
> Currently, to boot these images, you must provide DTB somewhere in mem
> and provide it as argument to bootm for instance.
>
> My goal is to add support that U-boot will parse the image, see that
> the DTB is included and use that as the FDT automatically.
>
> I'm looking at the "secondary" fields which are currently not used as
> a valid option to point to the DTB and it's size.
>
> Do you know if someone is working on something similar, or do you have
> any suggestions for the right approach to this issue ?
>
> Thanks,
> Ramon
>
> * - Actually, Qualcomm appends a pack of DTBs with offset table and
> chooses the right DTB in runtime.
> ___
> U-Boot mailing list
> U-Boot@lists.denx.de
> https://lists.denx.de/listinfo/u-boot
>
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH 6/6] cmd: Add "boot_android" command.

[Alex Deymo]

Regarding the boot_android command, U-Boot supports loading Android-format
kernel images to memory and booting them. That's not the main purpose of
boot_android, it actually does that by just calling bootm.

The part that U-Boot doesn't support is all the flows around booting an
Android device that are expected in AOSP. A big one is reading and honoring
the Boot Control Block (BCB), normally the first 4KiB of the "misc"
partition. See
https://android.googlesource.com/platform/bootable/recovery/+/master/bootloader_message/include/bootloader_message/bootloader_message.h
for a definition.

BCB is used for factory reset (from the Settings UI in Android), which will
write a message in the BCB saying "boot-recovery":
https://android.googlesource.com/platform/bootable/recovery/+/master/recovery.cpp#135

On boot, the bootloader must read the BCB and decide whether to boot the
normal kernel or instead boot to "recovery" mode. During the Factory Reset,
it is important that this is stored somewhere on the emmc, otherwise if you
just rely on a memory flag to tell the bootloader to boot to "recovery"
mode and complete the factory reset; a cold start boot might forget that
value. There are other cases where the bootloader should enter recovery,
for example when you run "boot recovery" from adb, or whit a multi-stage
non-A/B update (needs to reboot multiple times to recovery).

There's the "bootonce-bootloader" message too, in bootloader_message.cpp in
AOSP as well which tells to boot in bootloader mode (essentially, fastboot
mode), which can be triggered by "reboot bootloader" from userspace.
Deciding this means changing the kernel command line in the bootloader, so
that also must be done somewhere.

On top of that there's all the A/B logic flow, to decide which slot to boot
from; which is also defined in the bootloader_message.h, explained here:
https://source.android.com/devices/tech/ota/ab/ (See "Implementing A/B
Updates" too).

All this is what the boot_android command is taking care of. I'm sorry that
I don't have a better self-contained documentation link about this flow.

I should note that these flows are not *required* for all Android devices.
Android partners are free to use their own format for A/B metadata, not use
the AOSP "recovery" program/updates at all, and I think that even
"fastboot" is not mandatory for some devices (but I really don't know). Of
course, if you don't use this, you have to implement your own (updates, A/B
flow, factory reset...). That said, in my opinion if you take the latest
AOSP, U-Boot and kernel and put them together in a reasonable unlocked
device they should all work with these features and flows. You shouldn't
need to write code to make that work, just enable them, so that's why I
think U-Boot should have these Android-specific flows in it, given that it
already supports loading Android-format kernels.

Best regards,
Alex

2018-04-27 0:41 GMT+02:00 Stanislas BERTRAND :

> Hi Sam,
>
> > Can I ask you some questions about this code?
> >  1. Do I understand correctly that this is just some old patch hanging
> > in mailing list [1]?
>
> Yes, it is from an old post to the mailing list.
>
> >  2. What is the motivation of adding this command? We already have
> > Android boot image support in bootm command, which we successfully use
> > in TI just by loading needed images to RAM and then passing them to
> > bootm, like this: [2].
>
> I am working to get a Android A/B System implementation on my board.
> I was looking to reuse existing implementation. Aiming to stay close to
> the mainline.
>
> The command boot_android performs the different loading and checks
> required before calling bootm.
>
> Like Alex mentioned [4], those patch series are not recent but it was good
> starting point of implementation.
> I had to perform some customization to have a functional boot flow adapted
> to my system ( Android 7.1.1, Linux 4.4.45, U-Boot 2017.0 ).
>
> I am not pushing to have this particular implementation mainline.
> However having a mainline implementation for Android A/B system,
> would be nice. I was giving feedback from my particular system usage.
>
> >  3. Can you provide more information about how this code works? And
> > probably show some relevant link from Android documentation where it
> > says about boot flow implemented here?
>
> >  [1] https://lists.denx.de/pipermail/u-boot/2017-April/285847.html
> > [2] http://git.denx.de/?p=u-boot.git;a=blob;f=include/
> environment/ti/boot.h;h=24b7783f88947db07480d814c798e5
> 1197c07ce2;hb=HEAD#l38
> 
> More information was posted by Alex in his original patch series [3].
>
> Alex, I did add loading of the FDT in the boot_android command. How did
> you load your at 'fdt_addr' ?
>

This was done for the raspberry pi and I was using the FDT that the
bootloader code in the Pi loads and assembles. This is so all the boot.txt
configs and overlays that people expect to work on the pi are used, plus
the cmdli

Re: [U-Boot] [PATCH 0/8] Initial integration of AVB2.0

[Alex Deymo]

Hi Kever,
  libavb and libavb_ab are different things, and we split them for a
reason. Adding libavb is great, but you don't need to add libavb_ab as an
A/B implementation. The boot_android command referenced by Igor doesn't use
that as an A/B implementation, but uses the structs already defined in
the Boot Control Block (BCB) and the android bootloader flow. I would
recommend to include the libavb only.

Igor,
What changes did you need to do to libavb to import it to U-Boot? The idea
with libavb is that it should be easy to integrate into your bootloader
without changes; and therefore easy to update and integrate new patches
when we release new versions of libavb. We would like to avoid diverting
from it to reduce the maintenance cost.

Best regards,
Alex


Le jeu. 26 avr. 2018 à 05:05, Kever Yang  a
écrit :

> Hi Igor,
>
> It's great to see the patch set to support AVB2.0, the upstream
> libavb(from aosp) combine the AVB with A/B which I think should be
> two separate feature, are you going to split them?
>
> BTW, do you have plan to update boot_android cmd to support avb?
> the command is too weak for use now.
> And any plan to add opptee_client/smcc to talk to OPTEE/ATF?
>
> Thanks,
> - Kever
> On 04/25/2018 09:17 PM, Igor Opaniuk wrote:
> > This series of patches introduces support of Android Verified Boot 2.0,
> > which provides integrity checking of Android partitions on MMC.
> >
> > It integrates libavb/libavb_ab into the U-boot, provides implementation
> of
> > AvbOps, subset of `avb` commands to run verification chain (and for
> debugging
> > purposes), and it enables AVB2.0 verification on AM57xx HS SoC by
> default.
> >
> > Currently, there is still no support for verification of A/B boot slots
> > and no rollback protection (for storing rollback indexes
> > there are plans to use eMMC RPMB)
> >
> > Libavb/libavb_ab will be deviated from AOSP upstream in the future,
> > that's why minimal amount of changes were introduced into the lib
> sources,
> > so checkpatch may fail.
> >
> > For additional details check [1] AVB 2.0 README and doc/README.avb2,
> which
> > is a part of this patchset.
> >
> > [1]
> https://android.googlesource.com/platform/external/avb/+/master/README.md
> >
> > Igor Opaniuk (8):
> >   avb2.0: add Android Verified Boot 2.0 libraries
> >   avb2.0: integrate avb 2.0 into the build system
> >   avb2.0: implement AVB ops
> >   cmd: avb2.0: avb command for performing verification
> >   avb2.0: add boot states and dm-verity support
> >   am57xx_hs: avb2.0: add support of AVB 2.0
> >   test/py: avb2.0: add tests for avb commands
> >   doc: avb2.0: add README about AVB2.0 integration
> >
> >  cmd/Kconfig  |   15 +
> >  cmd/Makefile |3 +
> >  cmd/avb.c|  366 
> >  common/Makefile  |2 +
> >  common/avb_verify.c  |  748 
> >  configs/am57xx_hs_evm_defconfig  |3 +
> >  doc/README.avb2  |  100 +++
> >  include/avb/avb_ab_flow.h|  235 ++
> >  include/avb/avb_ab_ops.h |   61 ++
> >  include/avb/avb_chain_partition_descriptor.h |   54 ++
> >  include/avb/avb_crypto.h |  147 
> >  include/avb/avb_descriptor.h |  113 +++
> >  include/avb/avb_footer.h |   68 ++
> >  include/avb/avb_hash_descriptor.h|   55 ++
> >  include/avb/avb_hashtree_descriptor.h|   65 ++
> >  include/avb/avb_kernel_cmdline_descriptor.h  |   63 ++
> >  include/avb/avb_ops.h|  196 +
> >  include/avb/avb_property_descriptor.h|   89 ++
> >  include/avb/avb_rsa.h|   55 ++
> >  include/avb/avb_sha.h|   72 ++
> >  include/avb/avb_slot_verify.h|  239 ++
> >  include/avb/avb_sysdeps.h|   97 +++
> >  include/avb/avb_util.h   |  259 ++
> >  include/avb/avb_vbmeta_image.h   |  272 ++
> >  include/avb/avb_version.h|   45 +
> >  include/avb/libavb.h |   32 +
> >  include/avb/libavb_ab.h  |   22 +
> >  include/avb_verify.h |   97 +++
> >  include/configs/am57xx_evm.h |   11 +
> >  include/environment/ti/boot.h|   15 +
> >  lib/Kconfig  |   20 +
> >  lib/Makefile |2 +
> >  lib/libavb/Makefile  |   15 +
> >  lib/libavb/avb_chain_partition_descriptor.c  |   46 +
> >  lib/libavb/avb_crypto.c  |  355 
> >  lib/libavb/avb_descriptor.c  |  142 
> >  lib/libavb/avb_footer.c  |   36 +
> >  lib/libavb/avb_hash_descriptor.c |   43 +
> >  lib/libav

Re: [U-Boot] [RFC PATCH v1 4/5] dfu: Resolve Kconfig dependency loops

[Alex Deymo]

2018-04-25 9:53 GMT+02:00 Lukasz Majewski :

> Hi Alex,
>
> > Fix recursive dependencies in Kconfig introduced by fastboot UDP
> >
> > Signed-off-by: Alex Kiernan 
> > ---
> >
> >  cmd/fastboot/Kconfig | 5 +++--
> >  1 file changed, 3 insertions(+), 2 deletions(-)
> >
> > diff --git a/cmd/fastboot/Kconfig b/cmd/fastboot/Kconfig
> > index 0c57616..0f804ea 100644
> > --- a/cmd/fastboot/Kconfig
> > +++ b/cmd/fastboot/Kconfig
> > @@ -2,13 +2,13 @@ comment "FASTBOOT"
> >
> >  menuconfig FASTBOOT
> >   bool "Fastboot support"
> > - depends on USB_GADGET
> >   default y if ARCH_SUNXI && USB_MUSB_GADGET
> >
> >  if FASTBOOT
> >
> >  config USB_FUNCTION_FASTBOOT
> >   bool "Enable USB fastboot gadget"
> > + depends on USB_GADGET
> >   default y
> >   select USB_GADGET_DOWNLOAD
> >   imply ANDROID_BOOT_IMAGE
> > @@ -17,7 +17,7 @@ config USB_FUNCTION_FASTBOOT
> > This enables the USB part of the fastboot gadget.
> >
> >  config UDP_FUNCTION_FASTBOOT
> > - select NET
> > + depends on NET
> >   bool "Enable fastboot protocol over UDP"
> >   help
> > This enables the fastboot protocol over UDP.
> > @@ -66,6 +66,7 @@ config FASTBOOT_BUF_SIZE
> >
> >  config FASTBOOT_USB_DEV
> >   int "USB controller number"
> > + depends on USB_FUNCTION_FASTBOOT
> >   default 0
> >   help
> > Some boards have USB OTG controller other than 0. Define
> > this
>
> I think that it should be possible to have fastboot support enabled for
> both USB and ETH if a board has those interfaces present.
>
> Then by using proper commands:
>
> fastboot usb or fastboot udp we can decide which medium would be used.
>
> I agree that compiling support for both should be possible (I'm not sure
if it is really that useful). I was referring to that supporting fastboot
in both interfaces at the same time would be very complicated; but
selecting at runtime whether you want "fastboot udp" or "fastboot usb" is
easy.

deymo
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [RFC PATCH v1 0/5] Add fastboot UDP support

[Alex Deymo]

2018-04-25 10:43 GMT+02:00 Alex Kiernan :

> >> - what's the correct way of attributing the original authors? I've
> >> added Co-authored-by, is that right? checkpatch doesn't seem to know
> >> any of the co- tags
> >
> > I think that two authors (Alex and Jocelyn) have replied to your e-mail.
> >
> > Maybe it would be doable to have S-o-B or Acked-by from them?
> >
>
> Alex, Jocelyn, would you be happy for me to add a Signed-off-by from you?
>

Sure!
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [RFC PATCH v1 0/5] Add fastboot UDP support

[Alex Deymo]

+Jocelyn.

Thanks Alex for taking the time to port this!! Some comments inline here
about your questions.

2018-04-24 11:37 GMT+02:00 Alex Kiernan :

>
> This series merges the fastboot UDP support from AOSP into mainline
> U-Boot.
>
> Open questions:
>
> - what's the correct way of attributing the original authors? I've added
>   Co-authored-by, is that right? checkpatch doesn't seem to know any
>   of the co- tags
> - currently there's no NAND support and I've no way of testing that, so
>   my inclination is towards leaving it like that until someone with that
>   particular itch to scratch can look at it
>

Fastboot uses partition names, like "system" and "boot" which have a
meaning in the Android partition scheme. For GPT, we just use the partition
names as the android names; but if you are booting from some other storage
like NAND where you don't have that then you need some mapping glue
("system" --> device and partition number). I've seen U-Boot modifications
for several devices where they just stick a table hard-coded in the U-Boot
code; which works great for that device but it isn't really a generic
approach. Other than handling the names issue, I don't see any problem with
supporting NAND here, but a generic way to set global names / alias would
be needed for this.



> - you can select both USB and UDP fastboot, but the comments in the
>   AOSP code suggest that needs fixing - again, I've no board I can test
>   USB fastboot on
>

I thought we checked in the Kconfig that you couldn't enable both. I don't
remember the details now but yeah you can't wait for network or USB traffic
on the current code.

- the USB and UDP code want consolidating, with this series there would
>   then be two separate implementations of the same protocol
> - the syntax for the USB fastboot command changes from `fastboot
> `
>   to `fastboot usb `, that feels unacceptable and we probably
>   want something like `fastboot ` or `fastboot udp`?
> - unrelated to this series, but a show-stopper for me, there's no FIT image
>   support, but that doesn't feel unsolveable - something like add an option
>   to pass in the load address and/or use loadaddr, then something else to
>   let you override the bootm invocation on the server side
>
> I've not tested all the code paths yet, but the obvious stuff works
> (basic interaction, download, boot) - every interaction elicits a
> `WARNING: unknown variable: slot-count` on the console; I'm guessing that
> my local end is sending a getvar for that, but I've not investigated.
>

Yes, there's a bit of different handling of partitions for A/B android
devices. Instead of "system" you have two partitions: "system_a" and
"system_b" (potentially more although 2 is the most common case) so to know
whether you have an old device or a newer device the fastboot client checks
the "slot-count" variable. Undefined means of course that you have an
old-style device, but if you return something like "2" you would be able to
flash "system" on the "slot A" which is translated (again in the fastboot
client) to flash "system_a" partition. This is useful when using the higher
level operations like flashall/update and you want to specify to flash only
"slot A", "slot B" or even both of them. There are other fastboot variables
that require some plumbing, such as "has-slot:" to tell whether
"system" is a partition that indeed has the two versions _a and _b.
Typically some partitions are twice (like "system" and "boot") and some
other are not (like "misc" or "userdata"). Anyway, this as is should work
for either old-style partition schemes or by force flashing "system_a" with
the system.img.



> Without any way of testing any of the USB/NAND code I'm nervous of wading
> into that kind of refactoring, would that be a pre-requisite for merging?
>
>
> Alex Kiernan (5):
>   dfu: Refactor fastboot_okay/fail to take response
>   dfu: Extract fastboot_okay/fail to fb_common.c
>   net: dfu: Merge AOSP UDP fastboot
>   dfu: Resolve Kconfig dependency loops
>   net: dfu: Support building without MMC
>
>  cmd/fastboot.c  |  32 ++-
>  cmd/fastboot/Kconfig|  21 +-
>  cmd/net.c   |   6 +
>  common/Makefile |   4 +
>  common/fb_common.c  |  44 
>  common/fb_mmc.c | 114 ++---
>  common/fb_nand.c|  31 +--
>  common/image-sparse.c   |  41 ++-
>  drivers/usb/gadget/f_fastboot.c |  36 +--
>  include/fastboot.h  |  17 +-
>  include/fb_mmc.h|   4 +-
>  include/fb_nand.h   |   4 +-
>  include/image-sparse.h  |   2 +-
>  include/net.h   |   6 +-
>  include/net/fastboot.h  |  27 ++
>  net/Makefile|   1 +
>  net/fastboot.c  | 548 ++
> ++
>  net/net.c   |   9 +
>  18 files changed, 824 insertions(+), 123 deletions(-)
>  create mode 100644 common/fb_co

Re: [U-Boot] [PATCH 0/6] Android A/B Bootloader support

[Alex Deymo]

Hi Stanislas,
This work is in use in Android Things preview U-Boot bootloader for the
raspberry pi. The code is available in
https://android.googlesource.com/platform/external/u-boot/+/android-o-mr1-iot-preview-7
. If I remember correctly, these patches are a cleanup of that code, but
they are a bit old now and would require some rebasing and testing to build
against the latest U-Boot. Would there be interest to integrate these
patches into U-Boot here? I don't think we have changed anything since.
Thanks,
deymo.





2018-04-13 2:57 GMT+02:00 Stanislas BERTRAND :

> Hi Alex,
>
> The Android A/B bootloader patch series looks good.
>
> How far along are you to have this work integrated ?
>
> Regards,
> Stan
>
> On 04/02/2017 04:49 PM, Alex Deymo wrote:
> >* An "Android Bootloader" has a lot of requirements about how it should
> *>* behave which Android partners must implement. In particular, the new
> *>* A/B updates [1] added more requirements and flows to the bootloader
> *>* which are not common, on top of the existing flows.
> *>>* For example, a few uncommon requirements include:
> *>* * Lookup in the BCB (boot control block) whether a "recovery" message
> *>*is stored. This is used by the recovery environment when applying a
> *>*multi-stage update in the legacy update model (recovery reboots to
> *>*recovery again) and for interrumpted factory-reset (a reboot during
> *>*the factory reset should continue to reboot into factory reset until
> *>*it is done).
> *>* * A new "repair" mode. In the A/B model, when none of the slots is
> *>*bootable, the device would boot into repair mode, which is often the
> *>*same as "bootloader" mode (fastboot).
> *>* * Recovery as root: In newer version of AOSP, it is possible to mount
> *>*the system image as / without an initramfs, which then frees up the
> *>*initramfs in the "boot" partition to hold the "recovery" initramfs.
> *>*This is the default for new devices and required for the A/B setup.
> *>>* This patchset updates the Android-related headers and introduces new
> *>* commands to boot a recent Android build. This work is based on the
> *>* bootloader used in the Raspberry Pi in Android Things and extensively
> *>* tested there.
> *>>* [1] https://source.android.com/devices/tech/ota/ab_updates.html 
> <https://source.android.com/devices/tech/ota/ab_updates.html>
> *>>>* Alex Deymo (6):
> *>*image: Update include/android_image.h
> *>*image: Implement a function to load Android Images.
> *>*cmd: Add 'load_android' command to load Android images.
> *>*disk: Return the partition number in part_get_info_by_name()
> *>*Initial support for the Android Bootloader flow
> *>*cmd: Add "boot_android" command.
> *>>*   README   |  25 ++-
> *>*   cmd/Kconfig  |  19 ++
> *>*   cmd/Makefile |   2 +
> *>*   cmd/boot_android.c   | 126 +
> *>*   cmd/load_android.c   |  56 ++
> *>*   common/Kconfig   |  19 ++
> *>*   common/Makefile  |   1 +
> *>*   common/android_bootloader.c  | 350 
> +++
> *>*   common/fb_mmc.c  |   6 +-
> *>*   common/image-android.c   |  60 ++
> *>*   disk/part.c  |   2 +-
> *>*   include/android_bootloader.h |  48 +
> *>*   include/android_bootloader_message.h | 174 +
> *>*   include/android_image.h  |  24 ++-
> *>*   include/image.h  |  19 ++
> *>*   include/part.h   |   3 +-
> *>*   16 files changed, 920 insertions(+), 14 deletions(-)
> *>*   create mode 100644 cmd/boot_android.c
> *>*   create mode 100644 cmd/load_android.c
> *>*   create mode 100644 common/android_bootloader.c
> *>*   create mode 100644 include/android_bootloader.h
> *>*   create mode 100644 include/android_bootloader_message.h
> *>
>
>
>
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [Feature] Android Fastboot over Ethernet

[Alex Deymo]

Hi all,

Android Things on rpi supports fastboot over udp since most rpis don't
expose a suitable USB port for fastboor over USB. It also uses the A/B
booting mechanism similar to Pixel phones.

The U-Boot code for the latest Android Things preview is in AOSP:
https://android.googlesource.com/platform/external/u-boot/+/android-o-mr1-iot-preview-7

In particular, the fastboot over UDP support was added by
https://android.googlesource.com/platform/external/u-boot/+/018e7c25c7c0260a6d021c84521eab808657c1a8
and subsequent commits. "git log android-o-mr1-iot-preview-7 --not v2017.07
--oneline --no-merges" should give you a cleaner list what was added on top
of 2017.07.

I believe most of those patches (or cleaned up versions) were shared in
this list at the time.

Best regards,
deymo.


2018-04-04 9:20 GMT+02:00 Lukasz Majewski :

> Hi Stanislas,
>
> > Has there been any development to support Android Fastboot Ethernet
> > feature in U-Boot ?
> >
> > https://android.googlesource.com/platform/system/core/+/
> android-7.1.2_r36/fastboot/fastboot_protocol.txt
> >
> >
> > The target board has not USB device port available to flash the
> > on-board eMMC.
>
> I'm not aware of any such effort.
>
> However, if you want to flash eMMC via ETH, then maybe you can look
> into DFU TFTP feature.
>
> Please read: ./doc/README.dfutftp
>
> >
> > Flashing the eMMC via U-Boot shell commands would be very much slower
> > and limited.
> >
> >
> > ___
> > U-Boot mailing list
> > U-Boot@lists.denx.de
> > https://lists.denx.de/listinfo/u-boot
>
>
>
>
> Best regards,
>
> Lukasz Majewski
>
> --
>
> DENX Software Engineering GmbH,  Managing Director: Wolfgang Denk
> HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
> Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de
>
> ___
> U-Boot mailing list
> U-Boot@lists.denx.de
> https://lists.denx.de/listinfo/u-boot
>
>
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH 0/2] Improve Raspberry Pi mmc writes.

[Alex Deymo]

2017-04-06 21:53 GMT-07:00 Jaehoon Chung :

> On 04/02/2017 03:58 PM, Alex Deymo wrote:
> > When experimenting with fastboot from U-Boot on the Raspberry Pi 3 we
> > found that the writes to the sdcard are much more slow than when
> > accessing it from the userspace. These two patches speed up the write
> > and allow us to reliably write the sdcard from U-Boot.
>
>
> I'm not sure you can see this email.
> If you can't receive this, I will resend with my gmail account.
>
I can, I'm on the list. If you cc me directly the chances of me seeing it
are much higher.


I want to know the situation after removing the BROKEN_R1B quirks.
>

How would I test that?
Basically trying to write 100s of MB to mmc on the rpi3 was failing very
often after applying the "Speed up mmc writes" patch. Without said patch
this was not a problem because the write were sooo slow that we would
never send two write commands too close to each other. Do you want me
re-test applying only "Speed up mmc writes." on top of master without the
second patch (Wait for SDHCI_INT_DATA_END when transferring)? Or just
re-test the mmc speed/reliability without neither of these patches?
deymo
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

[U-Boot] [PATCH 5/6] Initial support for the Android Bootloader flow

[Alex Deymo]

An Android Bootloader must comply with certain boot modes and change
the kernel command line accordingly. This patch introduces the Android
boot mode concept which determines whether the device should boot to
one of the following:
 * recovery: which should boot to the recovery image,
 * bootloader: which should boot to the "bootloader" (fastboot) and
 * normal: which should boot to the system image.

The boot mode is determined in part by the Boot Control Block (BCB)
which is stored at the beginning of the "misc" partition. The BCB
is defined in the "bootloader_message.h" file in AOSP, now copied
here as android_bootloader_message.h with minor modifications.

This patch implements the basic boot flow that loads and boots an
Android kernel image assuming an A/B device which implies that it uses
boot as recovery (BOARD_USES_RECOVERY_AS_BOOT in the BoardConfig.mk).
This means that the recovery image shares the same kernel with the
normal boot system image, but stores the recovery image as a ramdisk
which is not used in normal mode.

Among the limitations, this patch doesn't implement the A/B slot
selection, it only boots from the provided slot.

Test: Booted a rpi3 with this flow.
Signed-off-by: Alex Deymo 
---
 README   |  19 +-
 common/Kconfig   |  19 ++
 common/Makefile  |   1 +
 common/android_bootloader.c  | 350 +++
 include/android_bootloader.h |  48 +
 include/android_bootloader_message.h | 174 +
 6 files changed, 607 insertions(+), 4 deletions(-)
 create mode 100644 common/android_bootloader.c
 create mode 100644 include/android_bootloader.h
 create mode 100644 include/android_bootloader_message.h

diff --git a/README b/README
index aa907ced8a..384cc6aabb 100644
--- a/README
+++ b/README
@@ -1483,6 +1483,21 @@ The following options need to be configured:
entering dfuMANIFEST state. Host waits this timeout, before
sending again an USB request to the device.
 
+- Android Bootloader support:
+   CONFIG_ANDROID_BOOTLOADER
+   This enables support for the Android bootloader flow. Android
+   devices can boot in normal mode, recovery mode or bootloader
+   mode. The normal mode is the most common boot mode, but
+   recovery mode is often used to perform factory reset and OTA
+   (over-the-air) updates in the legacy updater. Also it is
+   possible for an Android system to request a reboot to the
+   "bootloader", which often means reboot to fastboot but may also
+   include a UI with a menu.
+
+   CONFIG_ANDROID_BOOT_IMAGE
+   This enables support for booting images which use the Android
+   image format header.
+
 - USB Device Android Fastboot support:
CONFIG_USB_FUNCTION_FASTBOOT
This enables the USB part of the fastboot gadget
@@ -1494,10 +1509,6 @@ The following options need to be configured:
used on Android devices.
See doc/README.android-fastboot for more information.
 
-   CONFIG_ANDROID_BOOT_IMAGE
-   This enables support for booting images which use the Android
-   image format header.
-
CONFIG_FASTBOOT_BUF_ADDR
The fastboot protocol requires a large memory buffer for
downloads. Define this to the starting RAM address to use for
diff --git a/common/Kconfig b/common/Kconfig
index 8f73c8f757..47e2ffa3d6 100644
--- a/common/Kconfig
+++ b/common/Kconfig
@@ -393,6 +393,25 @@ config DISPLAY_BOARDINFO
  when U-Boot starts up. The board function checkboard() is called
  to do this.
 
+config ANDROID_BOOTLOADER
+   bool "Support for Android Bootloader boot flow"
+   default n
+   depends on ANDROID_BOOT_IMAGE
+   help
+ If enabled, adds support to boot an Android device following the
+ Android Bootloader boot flow. This flow requires an Android Bootloader
+ to handle the Android Bootloader Message stored in the Boot Control
+ Block (BCB), normally in the "misc" partition of an Android device.
+ The BCB is used to determine the boot mode of the device (normal mode,
+ recovery mode or bootloader mode) and, if enabled, the slot to boot
+ from in devices with multiple boot slots (A/B devices).
+
+config ANDROID_BOOT_IMAGE
+   bool "Enable support for Android Boot Images"
+   help
+ This enables support for booting images which use the Android
+ image format header.
+
 menu "Start-up hooks"
 
 config ARCH_EARLY_INIT_R
diff --git a/common/Makefile b/common/Makefile
index 86225f1564..9de0a77063 100644
--- a/common/Makefile
+++ b/common/Makefile
@@ -147,6 +147,7 @@ end

[U-Boot] [PATCH 3/6] cmd: Add 'load_android' command to load Android images.

[Alex Deymo]

Android kernel images include a header that specifies addresses and
kernel size. This patch adds a command to load these images from
storage without specifying the size or address of them, and parsing
them from the header instead.
---
 cmd/Kconfig|  9 +
 cmd/Makefile   |  1 +
 cmd/load_android.c | 56 ++
 3 files changed, 66 insertions(+)
 create mode 100644 cmd/load_android.c

diff --git a/cmd/Kconfig b/cmd/Kconfig
index 25e3b783a8..87a445d269 100644
--- a/cmd/Kconfig
+++ b/cmd/Kconfig
@@ -422,6 +422,15 @@ config CMD_LOADS
help
  Load an S-Record file over serial line
 
+config CMD_LOAD_ANDROID
+   bool "load_android"
+   default n
+   depends on ANDROID_BOOT_IMAGE
+   help
+ Load an Android Boot image from storage. The Android Boot images
+ define the size and kernel address on the header, which are used by
+ this command.
+
 config CMD_FLASH
bool "flinfo, erase, protect"
default y
diff --git a/cmd/Makefile b/cmd/Makefile
index f13bb8c11e..2f75dab040 100644
--- a/cmd/Makefile
+++ b/cmd/Makefile
@@ -82,6 +82,7 @@ obj-$(CONFIG_CMD_LDRINFO) += ldrinfo.o
 obj-$(CONFIG_LED_STATUS_CMD) += led.o
 obj-$(CONFIG_CMD_LICENSE) += license.o
 obj-y += load.o
+obj-$(CONFIG_CMD_LOAD_ANDROID) += load_android.o
 obj-$(CONFIG_LOGBUFFER) += log.o
 obj-$(CONFIG_ID_EEPROM) += mac.o
 obj-$(CONFIG_CMD_MD5SUM) += md5sum.o
diff --git a/cmd/load_android.c b/cmd/load_android.c
new file mode 100644
index 00..b9f3b1b372
--- /dev/null
+++ b/cmd/load_android.c
@@ -0,0 +1,56 @@
+/*
+ * Copyright (C) 2016 The Android Open Source Project
+ *
+ * SPDX-License-Identifier: BSD-2-Clause
+ */
+
+#include 
+#include 
+
+static int do_load_android(cmd_tbl_t *cmdtp, int flag, int argc,
+  char * const argv[])
+{
+   int boot_partition;
+   unsigned long load_address;
+   char *addr_arg_endp, *addr_str;
+   struct blk_desc *dev_desc;
+   disk_partition_t part_info;
+
+   if (argc < 2)
+   return CMD_RET_USAGE;
+   if (argc > 4)
+   return CMD_RET_USAGE;
+
+   if (argc >= 4) {
+   load_address = simple_strtoul(argv[3], &addr_arg_endp, 16);
+   if (addr_arg_endp == argv[3] || *addr_arg_endp != '\0')
+   return CMD_RET_USAGE;
+   } else {
+   addr_str = getenv("loadaddr");
+   if (addr_str != NULL)
+   load_address = simple_strtoul(addr_str, NULL, 16);
+   else
+   load_address = CONFIG_SYS_LOAD_ADDR;
+   }
+
+   boot_partition = blk_get_device_part_str(argv[1],
+(argc >= 3) ? argv[2] : NULL,
+&dev_desc, &part_info, 1);
+   if (boot_partition < 0)
+   return CMD_RET_FAILURE;
+
+   if (android_image_load(dev_desc, &part_info, load_address, -1UL) < 0) {
+   printf("Error loading Android Image from %s %d:%d to 0x%lx.\n",
+  argv[1], dev_desc->devnum, boot_partition, load_address);
+   return CMD_RET_FAILURE;
+   }
+   return CMD_RET_SUCCESS;
+}
+
+U_BOOT_CMD(
+   load_android, 4, 0, do_load_android,
+   "load Android Boot image from storage.",
+   " [ []]\n"
+   "- Load a binary Android Boot image from the partition 'part' on\n"
+   "  device type 'interface' instance 'dev' to address 'addr'."
+);
-- 
2.12.2.564.g063fe858b8-goog

___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

[U-Boot] [PATCH 1/6] image: Update include/android_image.h

[Alex Deymo]

Update the Android image header format to the latest version published
in AOSP. The original code moved to a new repository, so this patch also
updates the reference to that path.

Signed-off-by: Alex Deymo 
---
 common/image-android.c  |  9 +
 include/android_image.h | 24 +++-
 2 files changed, 28 insertions(+), 5 deletions(-)

diff --git a/common/image-android.c b/common/image-android.c
index ee03b96aaa..c668407817 100644
--- a/common/image-android.c
+++ b/common/image-android.c
@@ -161,6 +161,9 @@ int android_image_get_ramdisk(const struct andr_img_hdr 
*hdr,
 void android_print_contents(const struct andr_img_hdr *hdr)
 {
const char * const p = IMAGE_INDENT_STRING;
+   /* os_version = ver << 11 | lvl */
+   u32 os_ver = hdr->os_version >> 11;
+   u32 os_lvl = hdr->os_version & ((1U << 11) - 1);
 
printf("%skernel size:  %x\n", p, hdr->kernel_size);
printf("%skernel address:   %x\n", p, hdr->kernel_addr);
@@ -170,6 +173,12 @@ void android_print_contents(const struct andr_img_hdr *hdr)
printf("%ssecond address:   %x\n", p, hdr->second_addr);
printf("%stags address: %x\n", p, hdr->tags_addr);
printf("%spage size:%x\n", p, hdr->page_size);
+   /* ver = A << 14 | B << 7 | C (7 bits for each of A, B, C)
+* lvl = ((Y - 2000) & 127) << 4 | M  (7 bits for Y, 4 bits for M) */
+   printf("%sos_version:   %x (ver: %u.%u.%u, level: %u.%u)\n",
+  p, hdr->os_version,
+  (os_ver >> 7) & 0x7F, (os_ver >> 14) & 0x7F, os_ver & 0x7F,
+  (os_lvl >> 4) + 2000, os_lvl & 0x0F);
printf("%sname: %s\n", p, hdr->name);
printf("%scmdline:  %s\n", p, hdr->cmdline);
 }
diff --git a/include/android_image.h b/include/android_image.h
index 094d60afe8..dfd4d9d72c 100644
--- a/include/android_image.h
+++ b/include/android_image.h
@@ -1,8 +1,8 @@
 /*
  * This is from the Android Project,
- * Repository: 
https://android.googlesource.com/platform/bootable/bootloader/legacy
- * File: include/boot/bootimg.h
- * Commit: 4205b865141ff2e255fe1d3bd16de18e217ef06a
+ * Repository: https://android.googlesource.com/platform/system/core/
+ * File: mkbootimg/bootimg.h
+ * Commit: d162828814b08ada310846a33205befb69ef5799
  *
  * Copyright (C) 2008 The Android Open Source Project
  *
@@ -12,10 +12,13 @@
 #ifndef _ANDROID_IMAGE_H_
 #define _ANDROID_IMAGE_H_
 
+typedef struct andr_img_hdr andr_img_hdr;
+
 #define ANDR_BOOT_MAGIC "ANDROID!"
 #define ANDR_BOOT_MAGIC_SIZE 8
 #define ANDR_BOOT_NAME_SIZE 16
 #define ANDR_BOOT_ARGS_SIZE 512
+#define ANDR_BOOT_EXTRA_ARGS_SIZE 1024
 
 struct andr_img_hdr {
char magic[ANDR_BOOT_MAGIC_SIZE];
@@ -31,14 +34,25 @@ struct andr_img_hdr {
 
u32 tags_addr;  /* physical addr for kernel tags */
u32 page_size;  /* flash page size we assume */
-   u32 unused[2];  /* future expansion: should be 0 */
+   u32 unused; /* reserved for future expansion: MUST be 0 */
+
+   /* operating system version and security patch level; for
+* version "A.B.C" and patch level "Y-M-D":
+* ver = A << 14 | B << 7 | C (7 bits for each of A, B, C)
+* lvl = ((Y - 2000) & 127) << 4 | M  (7 bits for Y, 4 bits for M)
+* os_version = ver << 11 | lvl */
+   u32 os_version;
 
char name[ANDR_BOOT_NAME_SIZE]; /* asciiz product name */
 
char cmdline[ANDR_BOOT_ARGS_SIZE];
 
u32 id[8]; /* timestamp / checksum / sha1 / etc */
-};
+
+   /* Supplemental command line data; kept here to maintain
+* binary compatibility with older versions of mkbootimg */
+   char extra_cmdline[ANDR_BOOT_EXTRA_ARGS_SIZE];
+} __attribute__((packed));
 
 /*
  * +-+
-- 
2.12.2.564.g063fe858b8-goog

___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

[U-Boot] [PATCH 0/6] Android A/B Bootloader support

[Alex Deymo]

An "Android Bootloader" has a lot of requirements about how it should
behave which Android partners must implement. In particular, the new
A/B updates [1] added more requirements and flows to the bootloader
which are not common, on top of the existing flows.

For example, a few uncommon requirements include:
* Lookup in the BCB (boot control block) whether a "recovery" message
  is stored. This is used by the recovery environment when applying a
  multi-stage update in the legacy update model (recovery reboots to
  recovery again) and for interrumpted factory-reset (a reboot during
  the factory reset should continue to reboot into factory reset until
  it is done).
* A new "repair" mode. In the A/B model, when none of the slots is
  bootable, the device would boot into repair mode, which is often the
  same as "bootloader" mode (fastboot).
* Recovery as root: In newer version of AOSP, it is possible to mount
  the system image as / without an initramfs, which then frees up the
  initramfs in the "boot" partition to hold the "recovery" initramfs.
  This is the default for new devices and required for the A/B setup.

This patchset updates the Android-related headers and introduces new
commands to boot a recent Android build. This work is based on the
bootloader used in the Raspberry Pi in Android Things and extensively
tested there.

[1] https://source.android.com/devices/tech/ota/ab_updates.html


Alex Deymo (6):
  image: Update include/android_image.h
  image: Implement a function to load Android Images.
  cmd: Add 'load_android' command to load Android images.
  disk: Return the partition number in part_get_info_by_name()
  Initial support for the Android Bootloader flow
  cmd: Add "boot_android" command.

 README   |  25 ++-
 cmd/Kconfig  |  19 ++
 cmd/Makefile |   2 +
 cmd/boot_android.c   | 126 +
 cmd/load_android.c   |  56 ++
 common/Kconfig   |  19 ++
 common/Makefile  |   1 +
 common/android_bootloader.c  | 350 +++
 common/fb_mmc.c  |   6 +-
 common/image-android.c   |  60 ++
 disk/part.c  |   2 +-
 include/android_bootloader.h |  48 +
 include/android_bootloader_message.h | 174 +
 include/android_image.h  |  24 ++-
 include/image.h  |  19 ++
 include/part.h   |   3 +-
 16 files changed, 920 insertions(+), 14 deletions(-)
 create mode 100644 cmd/boot_android.c
 create mode 100644 cmd/load_android.c
 create mode 100644 common/android_bootloader.c
 create mode 100644 include/android_bootloader.h
 create mode 100644 include/android_bootloader_message.h

-- 
2.12.2.564.g063fe858b8-goog

___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

[U-Boot] [PATCH 2/6] image: Implement a function to load Android Images.

[Alex Deymo]

This patch implements the logic needed to load an Android boot image
from storage, since the size and kernel address in Android images is
defined in its header.

Signed-off-by: Alex Deymo 
---
 common/image-android.c | 51 ++
 include/image.h| 19 +++
 2 files changed, 70 insertions(+)

diff --git a/common/image-android.c b/common/image-android.c
index c668407817..f040f5b400 100644
--- a/common/image-android.c
+++ b/common/image-android.c
@@ -8,6 +8,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 
 #define ANDROID_IMAGE_DEFAULT_KERNEL_ADDR  0x10008000
@@ -146,6 +147,56 @@ int android_image_get_ramdisk(const struct andr_img_hdr 
*hdr,
return 0;
 }
 
+long android_image_load(struct blk_desc *dev_desc,
+   const disk_partition_t *part_info,
+   unsigned long load_address,
+   unsigned long max_size) {
+   void *buf;
+   long blk_cnt, blk_read = 0;
+
+   if (max_size < part_info->blksz)
+   return -1;
+
+   /* We don't know the size of the Android image before reading the header
+* so we don't limit the size of the mapped memory.
+*/
+   buf = map_sysmem(load_address, 0 /* size */);
+
+   /* Read the Android header first and then read the rest. */
+   if (blk_dread(dev_desc, part_info->start, 1, buf) != 1)
+   blk_read = -1;
+
+   if (!blk_read && android_image_check_header(buf) != 0) {
+   printf("** Invalid Android Image header **\n");
+   blk_read = -1;
+   }
+   if (!blk_read) {
+   blk_cnt = (android_image_get_end(buf) - (ulong)buf +
+  part_info->blksz - 1) / part_info->blksz;
+   if (blk_cnt * part_info->blksz > max_size) {
+   debug("Android Image too big (%lu bytes, max %lu)\n",
+ android_image_get_end(buf) - (ulong)buf,
+ max_size);
+   blk_read = -1;
+   } else {
+   debug("Loading Android Image (%lu blocks) to 0x%lx... ",
+ blk_cnt, load_address);
+   blk_read = blk_dread(dev_desc, part_info->start,
+blk_cnt, buf);
+   }
+   }
+
+   unmap_sysmem(buf);
+   if (blk_read < 0)
+   return blk_read;
+
+   debug("%lu blocks read: %s\n",
+ blk_read, (blk_read == blk_cnt) ? "OK" : "ERROR");
+   if (blk_read != blk_cnt)
+   return -1;
+   return blk_read;
+}
+
 #if !defined(CONFIG_SPL_BUILD)
 /**
  * android_print_contents - prints out the contents of the Android format image
diff --git a/include/image.h b/include/image.h
index 2372518960..de448a9a01 100644
--- a/include/image.h
+++ b/include/image.h
@@ -1241,6 +1241,25 @@ ulong android_image_get_end(const struct andr_img_hdr 
*hdr);
 ulong android_image_get_kload(const struct andr_img_hdr *hdr);
 void android_print_contents(const struct andr_img_hdr *hdr);
 
+/** android_image_load - Load an Android Image from storage.
+ *
+ * Load an Android Image based on the header size in the storage. Return the
+ * number of bytes read from storage, which could be bigger than the actual
+ * Android Image as described in the header size. In case of error reading the
+ * image or if the image size needed to be read from disk is bigger than the
+ * the passed |max_size| a negative number is returned.
+ *
+ * @dev_desc:  The device where to read the image from
+ * @part_info: The partition in |dev_desc| where to read the image from
+ * @load_address:  The address where the image will be loaded
+ * @max_size:  The maximum loaded size, in bytes
+ * @return the number of bytes read or a negative number in case of error.
+ */
+long android_image_load(struct blk_desc *dev_desc,
+   const disk_partition_t *part_info,
+   unsigned long load_address,
+   unsigned long max_size);
+
 #endif /* CONFIG_ANDROID_BOOT_IMAGE */
 
 /**
-- 
2.12.2.564.g063fe858b8-goog

___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

[U-Boot] [PATCH 4/6] disk: Return the partition number in part_get_info_by_name()

[Alex Deymo]

Similar to what blk_get_device_part_str() does, this patch makes
part_get_info_by_name() return the partition number in case of a match.
This is useful when the partition number is needed and not just the
descriptor.

Signed-off-by: Alex Deymo 
---
 common/fb_mmc.c | 6 +++---
 disk/part.c | 2 +-
 include/part.h  | 3 ++-
 3 files changed, 6 insertions(+), 5 deletions(-)

diff --git a/common/fb_mmc.c b/common/fb_mmc.c
index 6cc113d825..866982e41c 100644
--- a/common/fb_mmc.c
+++ b/common/fb_mmc.c
@@ -37,7 +37,7 @@ static int part_get_info_by_name_or_alias(struct blk_desc 
*dev_desc,
int ret;
 
ret = part_get_info_by_name(dev_desc, name, info);
-   if (ret) {
+   if (ret < 0) {
/* strlen("fastboot_partition_alias_") + 32(part_name) + 1 */
char env_alias_name[25 + 32 + 1];
char *aliased_part_name;
@@ -153,7 +153,7 @@ void fb_mmc_flash_write(const char *cmd, void 
*download_buffer,
}
 #endif
 
-   if (part_get_info_by_name_or_alias(dev_desc, cmd, &info)) {
+   if (part_get_info_by_name_or_alias(dev_desc, cmd, &info) < 0) {
error("cannot find partition: '%s'\n", cmd);
fastboot_fail("cannot find partition");
return;
@@ -205,7 +205,7 @@ void fb_mmc_erase(const char *cmd)
}
 
ret = part_get_info_by_name_or_alias(dev_desc, cmd, &info);
-   if (ret) {
+   if (ret < 0) {
error("cannot find partition: '%s'", cmd);
fastboot_fail("cannot find partition");
return;
diff --git a/disk/part.c b/disk/part.c
index cd447024c0..491b02dc9c 100644
--- a/disk/part.c
+++ b/disk/part.c
@@ -635,7 +635,7 @@ int part_get_info_by_name(struct blk_desc *dev_desc, const 
char *name,
}
if (strcmp(name, (const char *)info->name) == 0) {
/* matched */
-   return 0;
+   return i;
}
}
}
diff --git a/include/part.h b/include/part.h
index b6d1b33167..83bce05a43 100644
--- a/include/part.h
+++ b/include/part.h
@@ -163,7 +163,8 @@ int blk_get_device_part_str(const char *ifname, const char 
*dev_part_str,
  * @param gpt_name - the specified table entry name
  * @param info - returns the disk partition info
  *
- * @return - '0' on match, '-1' on no match, otherwise error
+ * @return - the partition number on match (starting on 1), -1 on no match,
+ * otherwise error
  */
 int part_get_info_by_name(struct blk_desc *dev_desc,
  const char *name, disk_partition_t *info);
-- 
2.12.2.564.g063fe858b8-goog

___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

[U-Boot] [PATCH] Allow boards to initialize the DT at runtime.

[Alex Deymo]

In some boards like the Raspberry Pi the initial bootloader will pass
a DT to the kernel. When using U-boot as such kernel, the board code in
U-Boot should be able to provide U-boot with this, already assembled
device tree blob.

This patch introduces a new config option CONFIG_OF_BOARD to use instead
of CONFIG_OF_EMBED or CONFIG_OF_SEPARATE which will initialize the DT
from a board-specific funtion instead of bundling one with U-boot or as
a separated file. This allows boards like the Raspberry Pi to reuse the
device tree passed from the bootcode.bin and start.elf firmware
files, included the run-time selected device tree overlays.

Signed-off-by: Alex Deymo 
---
 README  |  8 +++-
 board/raspberrypi/rpi/rpi.c | 10 ++
 doc/README.fdt-control  |  4 
 dts/Kconfig |  8 
 include/fdtdec.h|  6 ++
 lib/fdtdec.c|  3 +++
 6 files changed, 38 insertions(+), 1 deletion(-)

diff --git a/README b/README
index aa907ced8a..e658f02a7e 100644
--- a/README
+++ b/README
@@ -975,7 +975,7 @@ The following options need to be configured:
tree is available in the global data as gd->fdt_blob.
 
U-Boot needs to get its device tree from somewhere. This can
-   be done using one of the two options below:
+   be done using one of the three options below:
 
CONFIG_OF_EMBED
If this variable is defined, U-Boot will embed a device tree
@@ -996,6 +996,12 @@ The following options need to be configured:
still use the individual files if you need something more
exotic.
 
+   CONFIG_OF_BOARD
+   If this variable is defined, U-Boot will use the device tree
+   provided by the board at runtime instead of embedding one with
+   the image. Only boards defining board_fdt_blob_setup() support
+   this option (see include/fdtdec.h file).
+
 - Watchdog:
CONFIG_WATCHDOG
If this variable is defined, it enables watchdog
diff --git a/board/raspberrypi/rpi/rpi.c b/board/raspberrypi/rpi/rpi.c
index 2146534b36..ef04d397d6 100644
--- a/board/raspberrypi/rpi/rpi.c
+++ b/board/raspberrypi/rpi/rpi.c
@@ -516,6 +516,16 @@ int board_mmc_init(bd_t *bis)
  msg_clk->get_clock_rate.body.resp.rate_hz);
 }
 
+/*
+ * If the firmware passed a device tree use it for U-Boot.
+ */
+void *board_fdt_blob_setup(void)
+{
+   if (fdt_magic(fw_dtb_pointer) != FDT_MAGIC)
+   return NULL;
+   return (void *)fw_dtb_pointer;
+}
+
 int ft_board_setup(void *blob, bd_t *bd)
 {
/*
diff --git a/doc/README.fdt-control b/doc/README.fdt-control
index c965629905..378b06b108 100644
--- a/doc/README.fdt-control
+++ b/doc/README.fdt-control
@@ -130,6 +130,10 @@ u-boot-dtb.bin which does the above step for you also. If 
you are using
 CONFIG_SPL_FRAMEWORK, then u-boot.img will be built to include the device
 tree binary.
 
+If CONFIG_OF_BOARD is defined, a board-specific routine will provide the
+device tree at runtime, for example if an earlier bootloader stage creates
+it and passes it to U-Boot.
+
 If CONFIG_OF_HOSTFILE is defined, then it will be read from a file on
 startup. This is only useful for sandbox. Use the -d flag to U-Boot to
 specify the file to read.
diff --git a/dts/Kconfig b/dts/Kconfig
index 3f64eda619..978b2d7f3d 100644
--- a/dts/Kconfig
+++ b/dts/Kconfig
@@ -51,6 +51,14 @@ config OF_EMBED
  and development only and is not recommended for production devices.
  Boards in the mainline U-Boot tree should not use it.
 
+config OF_BOARD
+   bool "Provided by the board at runtime"
+   depends on !SANDBOX
+   help
+ If this option is enabled, the device tree will be provided by
+ the board at runtime if the board supports it, instead of being
+ bundled with the image.
+
 config OF_HOSTFILE
bool "Host filed DTB for DT control"
depends on SANDBOX
diff --git a/include/fdtdec.h b/include/fdtdec.h
index d074478f14..5c54f71458 100644
--- a/include/fdtdec.h
+++ b/include/fdtdec.h
@@ -1015,4 +1015,10 @@ int fdtdec_setup_memory_banksize(void);
  */
 int fdtdec_setup(void);
 
+/**
+ * Board-specific FDT initialization. Returns the address to a device tree 
blob.
+ * Called when CONFIG_OF_BOARD is defined.
+ */
+void *board_fdt_blob_setup(void);
+
 #endif
diff --git a/lib/fdtdec.c b/lib/fdtdec.c
index 81f47ef2c7..2e1beb545b 100644
--- a/lib/fdtdec.c
+++ b/lib/fdtdec.c
@@ -1247,6 +1247,9 @@ int fdtdec_setup(void)
/* FDT is at end of image */
gd->fdt_blob = (ulong *)&_end;
 #  endif
+# elif defined(CONFIG_OF_BOARD)
+   /* Allow the board to override the fdt address. */
+   gd->fdt_blob = board_fdt_blob_setup();
 # elif defined(CONFIG_OF_HOSTFILE)
if (sandbox_read_fdt_from_file()) {
  

[U-Boot] [PATCH] rpi: Support both UART interfaces.

[Alex Deymo]

The Raspberry Pi 3 has two UART interfaces that can be pinmuxed to the
header pins. The PL011 is by default muxed to the Bluetooth chip and
the mini-UART can be muxed to the pin headers passing "enabled_uart=1"
in the config.txt file.

Passing "enable_uart=1" has other implications, since the baudrate of
the miniuart depends on the clock frequency of the main core, which
is normally dynamic unless enable_uart=1 is set. If Bluetooth is not
used or not required, it is possible to set the PL011 UART to the
header pins passing either "dtoverlay=pi3-disable-bt" or
"dtoverlay=pi3-miniuart-bt" to disable Bluetooth or use it via the
miniuart respectively.

This patch disables (for U-Boot) the UARTs modules not muxed to the
header pins so the serial port is used only if available in the
header pins, avoiding writing to the Bluetooth chip if needed. This
allows to enable the PL01X driver for the Raspberry Pi 3, previously
disabled for that board, which can be used for the U-Boot console if
properly configured in the device tree.

Note that in order to get the PL01X driver in the Raspberry Pi 3 to
work with U-Boot the device tree must set "skip-init" in the uart0
block, for example this device tree fragment would do it:

fragment@0 {
target = <&uart0>;
__overlay__ {
skip-init;
};
};

Test: Booted a rpi3 with either UART output.
Signed-off-by: Alex Deymo 
---
 board/raspberrypi/rpi/rpi.c | 78 +++--
 drivers/serial/serial_pl01x.c   |  3 ++
 include/configs/rpi.h   |  8 +++-
 include/dm/platform_data/serial_pl01x.h |  2 +
 4 files changed, 66 insertions(+), 25 deletions(-)

diff --git a/board/raspberrypi/rpi/rpi.c b/board/raspberrypi/rpi/rpi.c
index 2146534b36..58f07953f5 100644
--- a/board/raspberrypi/rpi/rpi.c
+++ b/board/raspberrypi/rpi/rpi.c
@@ -18,6 +18,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #ifdef CONFIG_ARM64
 #include 
@@ -442,8 +443,19 @@ static void get_board_rev(void)
printf("RPI %s (0x%x)\n", model->name, revision);
 }
 
-#ifndef CONFIG_PL01X_SERIAL
-static bool rpi_is_serial_active(void)
+/* An enum describing the pin muxing selection for the UART RX/TX pins. */
+enum rpi_uart_mux {
+   /* The pin is associated with the internal "miniuart" block. */
+   RPI_UART_BCM283X_MU,
+
+   /* The pin is associated with the PL01X uart driver. */
+   RPI_UART_PL01X,
+
+   /* The pin is associated with a different function. */
+   RPI_UART_OTHER,
+};
+
+static enum rpi_uart_mux rpi_get_uart_mux_setting(void)
 {
int serial_gpio = 15;
struct udevice *dev;
@@ -452,41 +464,61 @@ static bool rpi_is_serial_active(void)
 * The RPi3 disables the mini uart by default. The easiest way to find
 * out whether it is available is to check if the RX pin is muxed.
 */
-
if (uclass_first_device(UCLASS_GPIO, &dev) || !dev)
-   return true;
-
-   if (bcm2835_gpio_get_func_id(dev, serial_gpio) != BCM2835_GPIO_ALT5)
-   return false;
+   return RPI_UART_OTHER;
 
-   return true;
+   switch (bcm2835_gpio_get_func_id(dev, serial_gpio)) {
+   case BCM2835_GPIO_ALT5:
+   return RPI_UART_BCM283X_MU;
+   case BCM2835_GPIO_ALT0:
+   return RPI_UART_PL01X;
+   }
+   return RPI_UART_OTHER;
 }
 
-/* Disable mini-UART I/O if it's not pinmuxed to our pins.
- * The firmware only enables it if explicitly done in config.txt: enable_uart=1
+/* Disable UART I/O for the mini-UART and PL01X UART if they are not pinmuxed 
to
+ * the Raspberry Pi header. The mini-UART is only enabled in the header if
+ * explicitly done in config.txt: enable_uart=1, and the PL01X is only enabled
+ * if not used for Bluetooth and explicitly exposed in config.txt as either
+ * dtoverlay=pi3-disable-bt or dtoverlay=pi3-miniuart-bt.
  */
-static void rpi_disable_inactive_uart(void)
+static void rpi_disable_inactive_uarts(void)
 {
struct udevice *dev;
-   struct bcm283x_mu_serial_platdata *plat;
+   enum rpi_uart_mux mux;
 
-   if (uclass_get_device_by_driver(UCLASS_SERIAL,
-   DM_GET_DRIVER(serial_bcm283x_mu),
-   &dev) || !dev)
-   return;
+   mux = rpi_get_uart_mux_setting();
+
+#ifdef CONFIG_BCM283X_MU_SERIAL
+   struct bcm283x_mu_serial_platdata *bcm283x_mu_plat;
 
-   if (!rpi_is_serial_active()) {
-   plat = dev_get_platdata(dev);
-   plat->disabled = true;
+   if (mux != RPI_UART_BCM283X_MU &&
+   !uclass_get_device_by_driver(UCLASS_SERIAL,
+DM_GET_DRIVER(serial_bcm283x_mu),
+&dev) &&
+

[U-Boot] [PATCH 6/6] cmd: Add "boot_android" command.

[Alex Deymo]

The new "boot_android" command simply executes the Android Bootloader
flow. This receives the location (interface, dev, partition) of the
Android "misc" partition which is then used to lookup and infer the
kernel and system images that should be booted from the passed slot.

Test: Booted a rpi3 build with Android Things.
Signed-off-by: Alex Deymo 
---
 README |   6 +++
 cmd/Kconfig|  10 +
 cmd/Makefile   |   1 +
 cmd/boot_android.c | 126 +
 4 files changed, 143 insertions(+)
 create mode 100644 cmd/boot_android.c

diff --git a/README b/README
index 384cc6aabb..5f62e14d94 100644
--- a/README
+++ b/README
@@ -1484,6 +1484,12 @@ The following options need to be configured:
sending again an USB request to the device.
 
 - Android Bootloader support:
+   CONFIG_CMD_BOOT_ANDROID
+   This enables the command "boot_android" which executes the
+   Android Bootloader flow. Enabling CONFIG_CMD_FASTBOOT is
+   recommended to support the Android Fastboot protocol as part
+   of the bootloader.
+
CONFIG_ANDROID_BOOTLOADER
This enables support for the Android bootloader flow. Android
devices can boot in normal mode, recovery mode or bootloader
diff --git a/cmd/Kconfig b/cmd/Kconfig
index 87a445d269..c4c22464b1 100644
--- a/cmd/Kconfig
+++ b/cmd/Kconfig
@@ -431,6 +431,16 @@ config CMD_LOAD_ANDROID
  define the size and kernel address on the header, which are used by
  this command.
 
+config CMD_BOOT_ANDROID
+   bool "boot_android"
+   default n
+   depends on ANDROID_BOOTLOADER
+   help
+ Performs the Android Bootloader boot flow, loading the appropriate
+ Android image (normal kernel, recovery kernel or "bootloader" mode)
+ and booting it. The boot mode is determined by the contents of the
+ Android Bootloader Message.
+
 config CMD_FLASH
bool "flinfo, erase, protect"
default y
diff --git a/cmd/Makefile b/cmd/Makefile
index 2f75dab040..348cf75386 100644
--- a/cmd/Makefile
+++ b/cmd/Makefile
@@ -22,6 +22,7 @@ obj-$(CONFIG_CMD_BDI) += bdinfo.o
 obj-$(CONFIG_CMD_BEDBUG) += bedbug.o
 obj-$(CONFIG_CMD_BLOCK_CACHE) += blkcache.o
 obj-$(CONFIG_CMD_BMP) += bmp.o
+obj-$(CONFIG_CMD_BOOT_ANDROID) += boot_android.o
 obj-$(CONFIG_CMD_BOOTEFI) += bootefi.o
 obj-$(CONFIG_CMD_BOOTMENU) += bootmenu.o
 obj-$(CONFIG_CMD_BOOTLDR) += bootldr.o
diff --git a/cmd/boot_android.c b/cmd/boot_android.c
new file mode 100644
index 00..067d9c7637
--- /dev/null
+++ b/cmd/boot_android.c
@@ -0,0 +1,126 @@
+/*
+ * Copyright (C) 2016 The Android Open Source Project
+ *
+ * SPDX-License-Identifier: BSD-2-Clause
+ */
+
+#include 
+#include 
+#include 
+
+/**
+ * part_get_info_by_dev_and_name - Parse a device number and partition name
+ * string in the form of "device_num;partition_name", for example "0;misc".
+ * If the partition is found, sets dev_desc and part_info accordingly with the
+ * information of the partition with the given partition_name.
+ *
+ * @dev_iface: Device interface.
+ * @dev_part_str:  Input string argument, like "0;misc".
+ * @dev_desc:  Place to put the device description pointer.
+ * @part_info: Place to put the partition information.
+ * @return 0 on success, or -1 on error
+ */
+static int part_get_info_by_dev_and_name(const char *dev_iface,
+const char *dev_part_str,
+struct blk_desc **dev_desc,
+disk_partition_t *part_info)
+{
+   char *ep;
+   const char *part_str;
+   int dev_num;
+
+   part_str = strchr(dev_part_str, ';');
+   if (!part_str)
+   return -1;
+
+   dev_num = simple_strtoul(dev_part_str, &ep, 16);
+   if (ep != part_str) {
+   /* Not all the first part before the ; was parsed. */
+   return -1;
+   }
+   part_str++;
+
+   *dev_desc = blk_get_dev(dev_iface, dev_num);
+   if (!*dev_desc) {
+   printf("Could not find %s %d\n", dev_iface, dev_num);
+   return -1;
+   }
+   if (part_get_info_by_name(*dev_desc, part_str, part_info) < 0) {
+   printf("Could not find \"%s\" partition\n", part_str);
+   return -1;
+   }
+   return 0;
+}
+
+static int do_boot_android(cmd_tbl_t *cmdtp, int flag, int argc,
+  char * const argv[])
+{
+   unsigned long load_address;
+   int ret = CMD_RET_SUCCESS;
+   char *addr_arg_endp, *addr_str;
+   struct blk_desc *dev_desc;
+   disk_partition_t part_info;
+   const char *misc_part_iface;
+   const char *misc_part_desc;
+
+ 

[U-Boot] [PATCH 2/2] mmc: sdhci: Wait for SDHCI_INT_DATA_END when transferring.

[Alex Deymo]

sdhci_transfer_data() function transfers the blocks passed up to the
number of blocks defined in mmc_data, but returns immediately once all
the blocks are transferred, even if the loop exit condition is not met
(bit SDHCI_INT_DATA_END set in the STATUS word).

When doing multiple writes to mmc, returning right after the last block
is transferred can cause the write to fail when sending the
MMC_CMD_STOP_TRANSMISSION command right after the
MMC_CMD_WRITE_MULTIPLE_BLOCK command, leaving the mmc driver in an
unconsistent state until reboot. This error was observed in the rpi3
board.

This patch waits for the SDHCI_INT_DATA_END bit to be set even after
sending all the blocks.

Test: Reliably wrote 2GiB of data to mmc in a rpi3.

Signed-off-by: Alex Deymo 
---
 drivers/mmc/sdhci.c | 15 +++
 1 file changed, 11 insertions(+), 4 deletions(-)

diff --git a/drivers/mmc/sdhci.c b/drivers/mmc/sdhci.c
index c94d58db65..b745977b3f 100644
--- a/drivers/mmc/sdhci.c
+++ b/drivers/mmc/sdhci.c
@@ -72,6 +72,7 @@ static int sdhci_transfer_data(struct sdhci_host *host, 
struct mmc_data *data,
unsigned int start_addr)
 {
unsigned int stat, rdy, mask, timeout, block = 0;
+   bool transfer_done = false;
 #ifdef CONFIG_MMC_SDHCI_SDMA
unsigned char ctrl;
ctrl = sdhci_readb(host, SDHCI_HOST_CONTROL);
@@ -89,17 +90,23 @@ static int sdhci_transfer_data(struct sdhci_host *host, 
struct mmc_data *data,
   __func__, stat);
return -EIO;
}
-   if (stat & rdy) {
+   if (!transfer_done && (stat & rdy)) {
if (!(sdhci_readl(host, SDHCI_PRESENT_STATE) & mask))
continue;
sdhci_writel(host, rdy, SDHCI_INT_STATUS);
sdhci_transfer_pio(host, data);
data->dest += data->blocksize;
-   if (++block >= data->blocks)
-   break;
+   if (++block >= data->blocks) {
+   /* Keep looping until the SDHCI_INT_DATA_END is
+* cleared, even if we finished sending all the
+* blocks.
+*/
+   transfer_done = true;
+   continue;
+   }
}
 #ifdef CONFIG_MMC_SDHCI_SDMA
-   if (stat & SDHCI_INT_DMA_END) {
+   if (!transfer_done && (stat & SDHCI_INT_DMA_END)) {
sdhci_writel(host, SDHCI_INT_DMA_END, SDHCI_INT_STATUS);
start_addr &= ~(SDHCI_DEFAULT_BOUNDARY_SIZE - 1);
start_addr += SDHCI_DEFAULT_BOUNDARY_SIZE;
-- 
2.12.2.564.g063fe858b8-goog

___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

[U-Boot] [PATCH 1/2] mmc: bcm2835_sdhci: Speed up mmc writes.

[Alex Deymo]

From: Jocelyn Bohr 

The linux kernel driver for this module does not use a delay when
writing to the SDHCI_BUFFER register. This patch mimics that behavior
in order to speed up the mmc writes on the Raspberry Pi.

Signed-off-by: Alex Deymo 
---
 drivers/mmc/bcm2835_sdhci.c | 8 ++--
 1 file changed, 6 insertions(+), 2 deletions(-)

diff --git a/drivers/mmc/bcm2835_sdhci.c b/drivers/mmc/bcm2835_sdhci.c
index 29c2a85812..20079bce48 100644
--- a/drivers/mmc/bcm2835_sdhci.c
+++ b/drivers/mmc/bcm2835_sdhci.c
@@ -44,6 +44,7 @@
 
 /* 400KHz is max freq for card ID etc. Use that as min */
 #define MIN_FREQ 40
+#define SDHCI_BUFFER 0x20
 
 struct bcm2835_sdhci_host {
struct sdhci_host host;
@@ -69,8 +70,11 @@ static inline void bcm2835_sdhci_raw_writel(struct 
sdhci_host *host, u32 val,
 * (Which is just as well - otherwise we'd have to nobble the DMA engine
 * too)
 */
-   while (timer_get_us() - bcm_host->last_write < bcm_host->twoticks_delay)
-   ;
+   if (reg != SDHCI_BUFFER) {
+   while (timer_get_us() - bcm_host->last_write <
+  bcm_host->twoticks_delay)
+   ;
+   }
 
writel(val, host->ioaddr + reg);
bcm_host->last_write = timer_get_us();
-- 
2.12.2.564.g063fe858b8-goog

___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

[U-Boot] [PATCH 0/2] Improve Raspberry Pi mmc writes

[Alex Deymo]

When experimenting with fastboot from U-Boot on the Raspberry Pi 3 we
found that the writes to the sdcard are much more slow than when
accessing it from the userspace. These two patches speed up the write
and allow us to reliably write the sdcard from U-Boot.

Alex Deymo (1):
  mmc: sdhci: Wait for SDHCI_INT_DATA_END when transferring.

Jocelyn Bohr (1):
  mmc: bcm2835_sdhci: Speed up mmc writes.

 drivers/mmc/bcm2835_sdhci.c |  8 ++--
 drivers/mmc/sdhci.c | 15 +++
 2 files changed, 17 insertions(+), 6 deletions(-)

-- 
2.12.2.564.g063fe858b8-goog

___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot