January 2019 - U-Boot

[U-Boot] [PATCH v2 00/15] AVB using OP-TEE
by Jens Wiklander 08 Jan '20

08 Jan '20

Hi, This adds support for storing AVB rollback indexes in the RPMB partition. The RPMB partition (content and key) is managed by OP-TEE (https://www.op-tee.org/) which is a secure OS leveraging ARM TrustZone. The Linux kernel can already support OP-TEE with reading and updating rollback indexes in the RPMB partition, the catch is that this is needed before the kernel has booted. The design here is the same as what is in the Linux kernel, with the exception that the user space daemon tee-supplicant is integrated in the OP-TEE driver here (drivers/tee/optee/supplicant.c) instead. A new uclass (UCLASS_TEE) is introduced to provide an abstraction for interfacing with a Trusted Execution Environment (TEE). There's also the OP-TEE driver using UCLASS_TEE for registration. A Trusted Application (TA) interface is added to be used by the AVB verify functions which are updated accordingly. The TA is managed by OP-TEE and is executed in a secure TrustZone protected environment. The header files drivers/tee/optee/optee_{msg,msg_supplicant,smc}.h and include/tee/optee_ta_avb.h are copied from https://github.com/OP-TEE/optee_os/tree/master more or less unmodified. They may need to be updated from time to time in order to support new features. In MMC there's a new function, mmc_rpmb_route_frames(), which as the name suggests is used to route RPMB frames to/from the MMC. This saves OP-TEE from implementing an MMC driver which would need to share resources with its counterpart here in U-boot. This was tested on a Hikey (Kirin 620) board. I've added myself as maintainer of the TEE stuff. v2: * Added sandbox driver and a test in test/dm for the new TEE uclass: Commit ("test: tee: test TEE uclass") and the enabling commits ("sandbox: dt: add sandbox_tee node") and ("configs: sandbox: enable CONFIG_TEE (TEE uclass)") * Added descriptions of exported structs and functions * Added documentation for the TEE uclass and the OP-TEE driver with the new commit ("Documentation: tee uclass and op-tee driver") * Added documentation for the changes in avb_verify * Addressed review comments from Simon Glass * Added the commit ("cmd: avb: print error message if command fails") * Made a few functions static in the OP-TEE driver * Commit ("cmd: avb read_rb: print rb_idx in hexadecimal") and ("tee: optee: support AVB trusted application"); Reviewed-by: Igor Opaniuk <igor.opaniuk(a)linaro.org> Thanks, Jens Jens Wiklander (15): dm: fdt: scan for devices under /firmware too cmd: avb read_rb: print rb_idx in hexadecimal cmd: avb: print error message if command fails mmc: rpmb: add mmc_rpmb_route_frames() Add UCLASS_TEE for Trusted Execution Environment dt/bindings: add bindings for optee tee: add OP-TEE driver Documentation: tee uclass and op-tee driver test: tee: test TEE uclass sandbox: dt: add sandbox_tee node configs: sandbox: enable CONFIG_TEE (TEE uclass) arm: dt: hikey: Add optee node optee: support routing of rpmb data frames to mmc tee: optee: support AVB trusted application avb_verify: support using OP-TEE TA AVB MAINTAINERS | 7 + arch/arm/dts/hi6220-hikey.dts | 7 + arch/sandbox/dts/sandbox.dts | 4 + arch/sandbox/dts/sandbox64.dts | 4 + arch/sandbox/dts/test.dts | 4 + cmd/avb.c | 19 +- common/avb_verify.c | 132 +++- configs/sandbox64_defconfig | 1 + configs/sandbox_defconfig | 1 + configs/sandbox_flattree_defconfig | 1 + configs/sandbox_noblk_defconfig | 1 + configs/sandbox_spl_defconfig | 1 + doc/README.avb2 | 13 + doc/README.tee | 112 ++++ .../firmware/linaro,optee-tz.txt | 31 + drivers/Kconfig | 2 + drivers/Makefile | 1 + drivers/core/root.c | 15 +- drivers/mmc/rpmb.c | 160 +++++ drivers/tee/Kconfig | 17 + drivers/tee/Makefile | 4 + drivers/tee/optee/Kconfig | 23 + drivers/tee/optee/Makefile | 5 + drivers/tee/optee/core.c | 622 ++++++++++++++++++ drivers/tee/optee/optee_msg.h | 423 ++++++++++++ drivers/tee/optee/optee_msg_supplicant.h | 234 +++++++ drivers/tee/optee/optee_private.h | 41 ++ drivers/tee/optee/optee_smc.h | 444 +++++++++++++ drivers/tee/optee/rpmb.c | 184 ++++++ drivers/tee/optee/supplicant.c | 92 +++ drivers/tee/tee-uclass.c | 192 ++++++ include/avb_verify.h | 4 + include/dm/uclass-id.h | 1 + include/mmc.h | 2 + include/tee.h | 297 +++++++++ include/tee/optee_ta_avb.h | 48 ++ test/dm/Makefile | 1 + test/dm/tee.c | 182 +++++ 38 files changed, 3325 insertions(+), 7 deletions(-) create mode 100644 doc/README.tee create mode 100644 doc/device-tree-bindings/firmware/linaro,optee-tz.txt create mode 100644 drivers/tee/Kconfig create mode 100644 drivers/tee/Makefile create mode 100644 drivers/tee/optee/Kconfig create mode 100644 drivers/tee/optee/Makefile create mode 100644 drivers/tee/optee/core.c create mode 100644 drivers/tee/optee/optee_msg.h create mode 100644 drivers/tee/optee/optee_msg_supplicant.h create mode 100644 drivers/tee/optee/optee_private.h create mode 100644 drivers/tee/optee/optee_smc.h create mode 100644 drivers/tee/optee/rpmb.c create mode 100644 drivers/tee/optee/supplicant.c create mode 100644 drivers/tee/tee-uclass.c create mode 100644 include/tee.h create mode 100644 include/tee/optee_ta_avb.h create mode 100644 test/dm/tee.c -- 2.17.1

3 37

[U-Boot] [PATCH v4 1/2] common: Add support for Android DT image
by Sam Protsenko 02 Dec '19

02 Dec '19

Android documentation recommends new image format for storing DTB/DTBO files: [1]. To support that format, this patch adds 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 This patch uses dt_table.h file, that was added in commit 643cefa4d848 ("Import Android's dt_table.h for DT image format") by Alex Deymo. [1] https://source.android.com/devices/architecture/dto/partitions Signed-off-by: Sam Protsenko <semen.protsenko(a)linaro.org> --- Changes in v4: - fix SPDX tags - renamed .reserved[] to .version (just reflect changes in dt_image.h) Changes in v3: - dropped include/dt_image.h (was sent in another patch by Alex Deymo) - rebased on top of last master common/image-android-dt.c | 156 +++++++++++++++++++++++++++++++++++++ include/image-android-dt.h | 20 +++++ 2 files changed, 176 insertions(+) create mode 100644 common/image-android-dt.c create mode 100644 include/image-android-dt.h diff --git a/common/image-android-dt.c b/common/image-android-dt.c new file mode 100644 index 0000000000..c0683ee70f --- /dev/null +++ b/common/image-android-dt.c @@ -0,0 +1,156 @@ +// SPDX-License-Identifier: GPL-2.0+ +/* + * (C) Copyright 2018 Linaro Ltd. + * Sam Protsenko <semen.protsenko(a)linaro.org> + */ + +#include <image-android-dt.h> +#include <dt_table.h> +#include <common.h> +#include <linux/libfdt.h> +#include <mapmem.h> + +/** + * Check if image header is correct. + * + * @param hdr_addr Start address of DT image + * @return true if header is correct or false if header is incorrect + */ +bool android_dt_check_header(ulong hdr_addr) +{ + const struct dt_table_header *hdr; + u32 magic; + + hdr = map_sysmem(hdr_addr, sizeof(*hdr)); + magic = fdt32_to_cpu(hdr->magic); + unmap_sysmem(hdr); + + return magic == DT_TABLE_MAGIC; +} + +/** + * Get the address of FDT (dtb or dtbo) in memory by its index in image. + * + * @param hdr_addr Start address of DT image + * @param index Index of desired FDT in image (starting from 0) + * @param[out] addr If not NULL, will contain address to specified FDT + * @param[out] size If not NULL, will contain size of specified FDT + * + * @return true on success or false on error + */ +bool android_dt_get_fdt_by_index(ulong hdr_addr, u32 index, ulong *addr, + u32 *size) +{ + const struct dt_table_header *hdr; + const struct dt_table_entry *e; + u32 entry_count, entries_offset, entry_size; + ulong e_addr; + u32 dt_offset, dt_size; + + hdr = map_sysmem(hdr_addr, sizeof(*hdr)); + entry_count = fdt32_to_cpu(hdr->dt_entry_count); + entries_offset = fdt32_to_cpu(hdr->dt_entries_offset); + entry_size = fdt32_to_cpu(hdr->dt_entry_size); + unmap_sysmem(hdr); + + if (index > entry_count) { + printf("Error: index > dt_entry_count (%u > %u)\n", index, + entry_count); + return false; + } + + e_addr = hdr_addr + entries_offset + index * entry_size; + e = map_sysmem(e_addr, sizeof(*e)); + dt_offset = fdt32_to_cpu(e->dt_offset); + dt_size = fdt32_to_cpu(e->dt_size); + unmap_sysmem(e); + + if (addr) + *addr = hdr_addr + dt_offset; + if (size) + *size = dt_size; + + return true; +} + +#if !defined(CONFIG_SPL_BUILD) +static void android_dt_print_fdt_info(const struct fdt_header *fdt) +{ + u32 fdt_size; + int root_node_off; + const char *compatible = NULL; + + fdt_size = fdt_totalsize(fdt); + root_node_off = fdt_path_offset(fdt, "/"); + if (root_node_off < 0) { + printf("Error: Root node not found\n"); + } else { + compatible = fdt_getprop(fdt, root_node_off, "compatible", + NULL); + } + + printf(" (FDT)size = %d\n", fdt_size); + printf(" (FDT)compatible = %s\n", + compatible ? compatible : "(unknown)"); +} + +/** + * Print information about DT image structure. + * + * @param hdr_addr Start address of DT image + */ +void android_dt_print_contents(ulong hdr_addr) +{ + const struct dt_table_header *hdr; + u32 entry_count, entries_offset, entry_size; + u32 i; + + hdr = map_sysmem(hdr_addr, sizeof(*hdr)); + entry_count = fdt32_to_cpu(hdr->dt_entry_count); + entries_offset = fdt32_to_cpu(hdr->dt_entries_offset); + entry_size = fdt32_to_cpu(hdr->dt_entry_size); + + /* Print image header info */ + printf("dt_table_header:\n"); + printf(" magic = %08x\n", fdt32_to_cpu(hdr->magic)); + printf(" total_size = %d\n", fdt32_to_cpu(hdr->total_size)); + printf(" header_size = %d\n", fdt32_to_cpu(hdr->header_size)); + printf(" dt_entry_size = %d\n", entry_size); + printf(" dt_entry_count = %d\n", entry_count); + printf(" dt_entries_offset = %d\n", entries_offset); + printf(" page_size = %d\n", fdt32_to_cpu(hdr->page_size)); + printf(" version = %d\n", fdt32_to_cpu(hdr->version)); + + unmap_sysmem(hdr); + + /* Print image entries info */ + for (i = 0; i < entry_count; ++i) { + const ulong e_addr = hdr_addr + entries_offset + i * entry_size; + const struct dt_table_entry *e; + const struct fdt_header *fdt; + u32 dt_offset, dt_size; + u32 j; + + e = map_sysmem(e_addr, sizeof(*e)); + dt_offset = fdt32_to_cpu(e->dt_offset); + dt_size = fdt32_to_cpu(e->dt_size); + + printf("dt_table_entry[%d]:\n", i); + printf(" dt_size = %d\n", dt_size); + printf(" dt_offset = %d\n", dt_offset); + printf(" id = %08x\n", fdt32_to_cpu(e->id)); + printf(" rev = %08x\n", fdt32_to_cpu(e->rev)); + for (j = 0; j < 4; ++j) { + printf(" custom[%d] = %08x\n", j, + fdt32_to_cpu(e->custom[j])); + } + + unmap_sysmem(e); + + /* Print FDT info for this entry */ + fdt = map_sysmem(hdr_addr + dt_offset, sizeof(*fdt)); + android_dt_print_fdt_info(fdt); + unmap_sysmem(fdt); + } +} +#endif diff --git a/include/image-android-dt.h b/include/image-android-dt.h new file mode 100644 index 0000000000..9a3aa8fa30 --- /dev/null +++ b/include/image-android-dt.h @@ -0,0 +1,20 @@ +/* SPDX-License-Identifier: GPL-2.0+ */ +/* + * (C) Copyright 2018 Linaro Ltd. + * Sam Protsenko <semen.protsenko(a)linaro.org> + */ + +#ifndef IMAGE_ANDROID_DT_H +#define IMAGE_ANDROID_DT_H + +#include <linux/types.h> + +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.18.0

5 11

[U-Boot] [PATCH v2] fw_setenv: avoid writing environment when nothing has changed
by Rasmus Villemoes 20 Nov '19

20 Nov '19

In the case where one deletes an already-non-existing variable, or sets a variable to the value it already has, there is no point in writing the environment back, thus reducing wear on the underlying storage device. In the case of redundant environments, if the two environments differ (e.g. because one is corrupt), make sure that any call of fw_setenv causes the two to become synchronized, even if the fw_setenv call does not change anything in the good copy. Signed-off-by: Rasmus Villemoes <rasmus.villemoes(a)prevas.dk> --- Add logic to ensure a corrupt copy gets replaced, even if fw_setenv wouldn't change anything in the good copy. tools/env/fw_env.c | 20 +++++++++++++++++++- 1 file changed, 19 insertions(+), 1 deletion(-) diff --git a/tools/env/fw_env.c b/tools/env/fw_env.c index a5d75958e1..66372dad55 100644 --- a/tools/env/fw_env.c +++ b/tools/env/fw_env.c @@ -110,6 +110,7 @@ struct environment { unsigned char *flags; char *data; enum flag_scheme flag_scheme; + int dirty; }; static struct environment environment = { @@ -508,6 +509,9 @@ int fw_env_flush(struct env_opts *opts) if (!opts) opts = &default_opts; + if (!environment.dirty) + return 0; + /* * Update CRC */ @@ -553,7 +557,8 @@ int fw_env_write(char *name, char *value) deleting = (oldval && !(value && strlen(value))); creating = (!oldval && (value && strlen(value))); - overwriting = (oldval && (value && strlen(value))); + overwriting = (oldval && (value && strlen(value) && + strcmp(oldval, value))); /* check for permission */ if (deleting) { @@ -593,6 +598,7 @@ int fw_env_write(char *name, char *value) /* Nothing to do */ return 0; + environment.dirty = 1; if (deleting || overwriting) { if (*++nxt == '\0') { *env = '\0'; @@ -1441,6 +1447,7 @@ int fw_env_open(struct env_opts *opts) "Warning: Bad CRC, using default environment\n"); memcpy(environment.data, default_environment, sizeof(default_environment)); + environment.dirty = 1; } } else { flag0 = *environment.flags; @@ -1494,6 +1501,16 @@ int fw_env_open(struct env_opts *opts) crc1_ok = (crc1 == redundant->crc); flag1 = redundant->flags; + /* + * environment.data still points to ((struct + * env_image_redundant *)addr0)->data. If the two + * environments differ, or one has bad crc, force a + * write-out by marking the environment dirty. + */ + if (memcmp(environment.data, redundant->data, ENV_SIZE) || + !crc0_ok || !crc1_ok) + environment.dirty = 1; + if (crc0_ok && !crc1_ok) { dev_current = 0; } else if (!crc0_ok && crc1_ok) { @@ -1503,6 +1520,7 @@ int fw_env_open(struct env_opts *opts) "Warning: Bad CRC, using default environment\n"); memcpy(environment.data, default_environment, sizeof(default_environment)); + environment.dirty = 1; dev_current = 0; } else { switch (environment.flag_scheme) { -- 2.16.4

2 2

[U-Boot] [PATCH] api: storage: Add the missing write operation support
by Cristian Ciocaltea 08 Nov '19

08 Nov '19

API_dev_write(va_list ap) is currently lacking the write support to storage devices because, historically, those devices did not implement block_write() The solution has been tested by loading and booting a (patched) GRUB instance in a QEMU vexpress-a9 environment. The disk write operations were triggered with GRUB's save_env command. Signed-off-by: Cristian Ciocaltea <cristian.ciocaltea(a)gmail.com> --- api/api.c | 59 ++++++++++++++++++++++++++++++----------------- api/api_private.h | 1 + api/api_storage.c | 24 +++++++++++++++++++ 3 files changed, 63 insertions(+), 21 deletions(-) diff --git a/api/api.c b/api/api.c index 9f03f1a35b..f7cfcc9ebc 100644 --- a/api/api.c +++ b/api/api.c @@ -294,27 +294,31 @@ static int API_dev_close(va_list ap) /* - * Notice: this is for sending network packets only, as U-Boot does not - * support writing to storage at the moment (12.2007) - * * pseudo signature: * * int API_dev_write( * struct device_info *di, * void *buf, - * int *len + * int *len, + * unsigned long *start * ) * * buf: ptr to buffer from where to get the data to send * - * len: length of packet to be sent (in bytes) + * len: ptr to length to be read + * - network: len of packet to be sent (in bytes) + * - storage: # of blocks to write (can vary in size depending on define) * + * start: ptr to start block (only used for storage devices, ignored for + * network) */ static int API_dev_write(va_list ap) { struct device_info *di; void *buf; - int *len; + lbasize_t *len_stor, act_len_stor; + lbastart_t *start; + int *len_net; int err = 0; /* 1. arg is ptr to the device_info struct */ @@ -332,23 +336,36 @@ static int API_dev_write(va_list ap) if (buf == NULL) return API_EINVAL; - /* 3. arg is length of buffer */ - len = (int *)va_arg(ap, uintptr_t); - if (len == NULL) - return API_EINVAL; - if (*len <= 0) - return API_EINVAL; + if (di->type & DEV_TYP_STOR) { + /* 3. arg - ptr to var with # of blocks to write */ + len_stor = (lbasize_t *)va_arg(ap, uintptr_t); + if (!len_stor) + return API_EINVAL; + if (*len_stor <= 0) + return API_EINVAL; - if (di->type & DEV_TYP_STOR) - /* - * write to storage is currently not supported by U-Boot: - * no storage device implements block_write() method - */ - return API_ENODEV; + /* 4. arg - ptr to var with start block */ + start = (lbastart_t *)va_arg(ap, uintptr_t); - else if (di->type & DEV_TYP_NET) - err = dev_write_net(di->cookie, buf, *len); - else + act_len_stor = dev_write_stor(di->cookie, buf, *len_stor, *start); + if (act_len_stor != *len_stor) { + debugf("write @ %llu: done %llu out of %llu blocks", + (uint64_t)blk, (uint64_t)act_len_stor, + (uint64_t)len_stor); + return API_EIO; + } + + } else if (di->type & DEV_TYP_NET) { + /* 3. arg points to the var with length of packet to write */ + len_net = (int *)va_arg(ap, uintptr_t); + if (!len_net) + return API_EINVAL; + if (*len_net <= 0) + return API_EINVAL; + + err = dev_write_net(di->cookie, buf, *len_net); + + } else err = API_ENODEV; return err; diff --git a/api/api_private.h b/api/api_private.h index 8d97ca95a2..07fd50ad3a 100644 --- a/api/api_private.h +++ b/api/api_private.h @@ -22,6 +22,7 @@ int dev_close_stor(void *); int dev_close_net(void *); lbasize_t dev_read_stor(void *, void *, lbasize_t, lbastart_t); +lbasize_t dev_write_stor(void *, void *, lbasize_t, lbastart_t); int dev_read_net(void *, void *, int); int dev_write_net(void *, void *, int); diff --git a/api/api_storage.c b/api/api_storage.c index 2b90c18aae..7ae03ac230 100644 --- a/api/api_storage.c +++ b/api/api_storage.c @@ -349,3 +349,27 @@ lbasize_t dev_read_stor(void *cookie, void *buf, lbasize_t len, lbastart_t start return dd->block_read(dd, start, len, buf); #endif /* defined(CONFIG_BLK) */ } + + +lbasize_t dev_write_stor(void *cookie, void *buf, lbasize_t len, lbastart_t start) +{ + struct blk_desc *dd = (struct blk_desc *)cookie; + int type = dev_stor_type(dd); + + if (type == ENUM_MAX) + return 0; + + if (!dev_stor_is_valid(type, dd)) + return 0; + +#ifdef CONFIG_BLK + return blk_dwrite(dd, start, len, buf); +#else + if (dd->block_write == NULL) { + debugf("no block_write() for device 0x%08x\n", cookie); + return 0; + } + + return dd->block_write(dd, start, len, buf); +#endif /* defined(CONFIG_BLK) */ +} -- 2.17.1

2 1

[U-Boot] [PATCH 0/1] board: arm: Add support for Broadcom BCM7445D0
by Thomas Fitzsimmons 28 Sep '19

28 Sep '19

Hi, This patch adds support for loading U-Boot on the Broadcom 7445D0 SoC, as a third stage bootloader loaded by Broadcom's BOLT bootloader. While this is only a partial port, it does enable some of U-Boot's flexibility on this SoC, functionality beyond what BOLT provides. Specifically, it brings: - ext4 file system traversal - support for loading FIT images - advanced scripting - support for FIT-provided DTBs instead of relying on the BOLT-provided DTB My team at Cisco is using a customized version of this port in production. The same approach may work on other BCM7xxx boards, with some configuration adjustments and memory layout experimentation. Stefan Roese reviewed (off-list) some early revisions of these changes. This patch is my attempt to rebase on the current U-Boot master branch. I'm submitting it in case there is interest in including this port in upstream U-Boot. Thomas Thomas Fitzsimmons (1): board: arm: Add support for Broadcom BCM7445D0 arch/arm/Kconfig | 12 + arch/arm/cpu/armv7/Makefile | 1 + arch/arm/cpu/armv7/bcm7445d0/Makefile | 11 + arch/arm/cpu/armv7/bcm7445d0/lowlevel_init.S | 24 ++ arch/arm/lib/crt0.S | 2 + arch/arm/mach-bcm7445d0/include/mach/gpio.h | 12 + arch/arm/mach-bcm7445d0/include/mach/hardware.h | 12 + arch/arm/mach-bcm7445d0/include/mach/sdhci.h | 15 + board/broadcom/bcm7445d0/Kconfig | 132 ++++++++ board/broadcom/bcm7445d0/Makefile | 11 + board/broadcom/bcm7445d0/bcm7445d0.c | 147 ++++++++ common/fdt_support.c | 9 +- common/image-fit.c | 2 + configs/bcm7445d0_defconfig | 21 ++ drivers/mmc/Makefile | 1 + drivers/mmc/bcmstb_sdhci.c | 59 ++++ drivers/spi/Kconfig | 7 + drivers/spi/Makefile | 1 + drivers/spi/bcmstb_spi.c | 428 ++++++++++++++++++++++++ dts/Kconfig | 6 + include/configs/bcm7445d0.h | 227 +++++++++++++ include/configs/bcmstb.h | 57 ++++ lib/fdtdec.c | 8 + 23 files changed, 1204 insertions(+), 1 deletion(-) create mode 100644 arch/arm/cpu/armv7/bcm7445d0/Makefile create mode 100644 arch/arm/cpu/armv7/bcm7445d0/lowlevel_init.S create mode 100644 arch/arm/mach-bcm7445d0/include/mach/gpio.h create mode 100644 arch/arm/mach-bcm7445d0/include/mach/hardware.h create mode 100644 arch/arm/mach-bcm7445d0/include/mach/sdhci.h create mode 100644 board/broadcom/bcm7445d0/Kconfig create mode 100644 board/broadcom/bcm7445d0/Makefile create mode 100644 board/broadcom/bcm7445d0/bcm7445d0.c create mode 100644 configs/bcm7445d0_defconfig create mode 100644 drivers/mmc/bcmstb_sdhci.c create mode 100644 drivers/spi/bcmstb_spi.c create mode 100644 include/configs/bcm7445d0.h create mode 100644 include/configs/bcmstb.h -- 1.8.3.1

6 36

[U-Boot] [usb dwc3] xHCI driver -- a hint needed.
by Yuri Frolov 11 Sep '19

11 Sep '19

Hi, I've been trying to bring up a dwc3 usb controller included in 32-bit MIPS chip. Usb is the one port usb2.0 host module, compliant with xHCI Revision 1.0, UTMI+ Low Pin interface (ULPI) Revision 1.1 and AMBA AXI Protocol specification. g_snpsid register reports 0x5533290a revision. It's verified, that linux kernel support is ok, usb is fully functional. axi { <...> usb@1F04D050 { compatible = "be,baikal-dwc3"; reg = <0x1f04d050 0x4>; interrupts = <0x0 0x45 0x4>; #address-cells = <0x1>; #size-cells = <0x1>; clocks = <0xf 0x0>; clock-names = "usb"; ranges; status = "okay"; dwc3@1F100000 { compatible = "snps,dwc3", "synopsys,dwc3", "generic-xhci"; reg = <0x1f100000 0x10000>; interrupts = <0x0 0x44 0x4>; dr_mode = "host"; tx-fifo-resize; maximum-speed = "high-speed"; }; }; }; whereas in u-boot 'usb start' fails on hub initialization (as I can see): Any ideas why this could happen?.. Any direction where to look at? Any suggestions will be greatly appreciated. # usb start (Re)start USB... USB0: dwc3_reg->g_snpsid: 0x5533290a Register 1000140 NbrPorts 1 Starting the controller USB XHCI 1.00 scanning bus 0 for devices... New Device 0 set address 1 usb_control_msg: request: 0x5, requesttype: 0x0, value 0x1 index 0x0 length 0x0 usb_control_msg: request: 0x6, requesttype: 0x80, value 0x100 index 0x0 length 0x12 usb_control_msg: request: 0x6, requesttype: 0x80, value 0x200 index 0x0 length 0x9 usb_control_msg: request: 0x6, requesttype: 0x80, value 0x200 index 0x0 length 0x1F get_conf_no 0 Result 25, wLength 31 if 0, ep 0 ##EP epmaxpacketin[1] = 8 set configuration 1 usb_control_msg: request: 0x9, requesttype: 0x0, value 0x1 index 0x0 length 0x0 new device strings: Mfr=1, Product=2, SerialNumber=0 usb_control_msg: request: 0x6, requesttype: 0x80, value 0x300 index 0x0 length 0xFF USB device number 1 default language ID 0x409 usb_control_msg: request: 0x6, requesttype: 0x80, value 0x301 index 0x409 length 0xFF usb_control_msg: request: 0x6, requesttype: 0x80, value 0x302 index 0x409 length 0xFF Manufacturer U-Boot Product XHCI Host Controller SerialNumber USB hub found usb_control_msg: request: 0x6, requesttype: 0xA0, value 0x2A00 index 0x0 length 0x4 usb_control_msg: request: 0x6, requesttype: 0xA0, value 0x2A00 index 0x0 length 0xC 1 ports detected ganged power switching standalone hub individual port over-current protection TT requires at most 8 FS bit times (666 ns) power on to power good time: 20ms hub controller current requirement: 0mA port 1 is removable usb_control_msg: request: 0x0, requesttype: 0xA0, value 0x0 index 0x0 length 0x4 get_hub_status returned status 1, change 801 local power source is lost (inactive) no over-current condition exists enabling power on all ports usb_control_msg: request: 0x3, requesttype: 0x23, value 0x8 index 0x1 length 0x0 port 1 returns 0 devnum=1 poweron: query_delay=100 connect_timeout=1100 usb_control_msg: request: 0x0, requesttype: 0xA3, value 0x0 index 0x1 length 0x4 Port 1 Status 101 Change 1 devnum=1 port=1: USB dev found usb_control_msg: request: 0x0, requesttype: 0xA3, value 0x0 index 0x1 length 0x4 portstatus 101, change 1, 12 Mb/s usb_control_msg: request: 0x1, requesttype: 0x23, value 0x10 index 0x1 length 0x0 usb_hub_port_reset: resetting port 1... usb_control_msg: request: 0x3, requesttype: 0x23, value 0x4 index 0x1 length 0x0 usb_control_msg: request: 0x0, requesttype: 0xA3, value 0x0 index 0x1 length 0x4 portstatus 111, change 0, 12 Mb/s STAT_C_CONNECTION = 0 STAT_CONNECTION = 1 USB_PORT_STAT_ENABLE 0 usb_control_msg: request: 0x3, requesttype: 0x23, value 0x4 index 0x1 length 0x0 usb_control_msg: request: 0x0, requesttype: 0xA3, value 0x0 index 0x1 length 0x4 portstatus 503, change 10, 480 Mb/s STAT_C_CONNECTION = 0 STAT_CONNECTION = 1 USB_PORT_STAT_ENABLE 1 usb_control_msg: request: 0x1, requesttype: 0x23, value 0x14 index 0x1 length 0x0 New Device 1 XHCI timeout on event type 33... cannot recover. BUG: failure at drivers/usb/host/xhci-ring.c:474/xhci_wait_for_event()! BUG! Reset CPU by CPC Here is the drivers/usb/host/xhci-baikal.c: #include <common.h> #include <usb.h> #include <linux/errno.h> #include <linux/compat.h> #include <linux/usb/dwc3.h> #include <linux/usb/xhci-omap.h> #include "xhci.h" /* Declare global data pointer */ DECLARE_GLOBAL_DATA_PTR; struct baikal_xhci { struct xhci_hccr *hcd; struct dwc3 *dwc3_reg; }; static struct baikal_xhci baikal; int __attribute__((weak)) board_usb_init(int index, enum usb_init_type init); static int baikal_xhci_core_init(struct baikal_xhci *baikal) { int ret = 0; ret = dwc3_core_init(baikal->dwc3_reg); if (ret) { debug("%s:failed to initialize core\n", __func__); return ret; } /* We are hard-coding DWC3 core to Host Mode */ dwc3_set_mode(baikal->dwc3_reg, DWC3_GCTL_PRTCAP_HOST); return ret; } static void baikal_xhci_core_exit(struct baikal_xhci *baikal) { } int xhci_hcd_init(int index, struct xhci_hccr **hccr, struct xhci_hcor **hcor) { struct baikal_xhci *ctx = &baikal; int ret = 0; ctx->hcd = (struct xhci_hccr *)CONFIG_USB_XHCI_BAIKAL_BASE; ctx->dwc3_reg = (struct dwc3 *)((char *)(ctx->hcd) + DWC3_REG_OFFSET); ret = board_usb_init(index, USB_INIT_HOST); if (ret != 0) { puts("Failed to initialize board for USB\n"); return ret; } ret = baikal_xhci_core_init(ctx); if (ret < 0) { puts("Failed to initialize xhci\n"); return ret; } *hccr = (struct xhci_hccr *)(CONFIG_USB_XHCI_BAIKAL_BASE); *hcor = (struct xhci_hcor *)((uint32_t) *hccr + HC_LENGTH(xhci_readl(&(*hccr)->cr_capbase))); debug("baikal-xhci: init hccr %x and hcor %x hc_length %d\n", (uint32_t)*hccr, (uint32_t)*hcor, (uint32_t)HC_LENGTH(xhci_readl(&(*hccr)->cr_capbase))); return ret; } void xhci_hcd_stop(int index) { } TIA, Yuri

4 6

[U-Boot] [PATCH] cros: Expand the Chromium OS documentation
by Simon Glass 13 Aug '19

13 Aug '19

The current documentation only covers how to chain-load U-Boot on a Chromebook. Add more information about the other ways to use U-Boot on Chromebooks. In particular it is again possible to build it with Chromium OS verified boot. Signed-off-by: Simon Glass <sjg(a)chromium.org> --- doc/README.chromium | 296 ++++++++++++++-------------------- doc/README.chromium-chainload | 239 +++++++++++++++++++++++++++ 2 files changed, 356 insertions(+), 179 deletions(-) create mode 100644 doc/README.chromium-chainload diff --git a/doc/README.chromium b/doc/README.chromium index 45eaeced2d..096bc4f1f7 100644 --- a/doc/README.chromium +++ b/doc/README.chromium @@ -1,239 +1,177 @@ -Running U-Boot from coreboot on Chromebooks -=========================================== +Chromium OS Support in U-Boot +============================= -U-Boot can be used as a secondary boot loader in a few situations such as from -UEFI and coreboot (see README.x86). Recent Chromebooks use coreboot even on -ARM platforms to start up the machine. +Introduction +------------ -This document aims to provide a guide to booting U-Boot on a Chromebook. It -is only a starting point, and there are many guides on the interwebs. But -placing this information in the U-Boot tree should make it easier to find for -those who use U-Boot habitually. +This describes how to use U-Boot with Chromium OS. Several options are +available: -Most of these platforms are supported by U-Boot natively, but it is risky to -replace the ROM unless you have a servo board and cable to restore it with. + - Running U-Boot from the 'altfw' feature, which is available on selected + Chromebooks from 2019 onwards (initially Grunt). Press '1' from the + developer-mode screen to get into U-Boot. See here for details: + https://sites.google.com/a/chromium.org/dev/chromium-os/poking-around-your-… + - Running U-Boot from the disk partition. This involves signing U-Boot and + placing it on the disk, for booting as a 'kernel'. See + README.chromium-chainload for information on this. This is the only + option on non-U-Boot Chromebooks from 2013 to 2018 and is somewhat + more involved. -For all of these the standard U-Boot build instructions apply. For example on -ARM: + - Running U-Boot with Chromium OS verified boot. This allows U-Boot to be + used instead of either or both of depthcharge (a bootloader which forked + from U-Boot in 2013) and coreboot. See below for more information on + this. - sudo apt install gcc-arm-linux-gnueabi - mkdir b - make O=b/nyan_big CROSS_COMPILE=arm-linux-gnueabi- nyan-big_defconfig all -You can obtain the vbutil_kernel utility here: +U-Boot with Chromium OS verified boot +------------------------------------- - https://drive.google.com/open?id=0B7WYZbZ9zd-3dHlVVXo4VXE2T0U +To obtain: + git clone https://github.com/sglass68/u-boot.git + cd u-boot + git checkout cros-master -Snow (Samsung ARM Chromebook) ------------------------------ +To build for sandbox: -See here: + UB=/tmp/b/chromeos_sandbox # U-Boot build directory + CROS=/home/sglass/cosarm # Chromium OS directory + make O=$UB/chromeos_sandbox_defconfig + make O=$UB -j20 -s VBOOT_SOURCE=$CROS/src/platform/vboot_reference \ + MAKEFLAGS_VBOOT=DEBUG=1 QUIET=1 -https://www.chromium.org/chromium-os/firmware-porting-guide/using-nv-u-boot-on-the-samsung-arm-chromebook +Replace sandbox with another supported target. +This produces $UB/image.bin which contains the firmware binaries in a SPI +flash image. -Nyan-big --------- - -Compiled based on information here: -https://lists.denx.de/pipermail/u-boot/2015-March/209530.html -https://git.collabora.com/cgit/user/tomeu/u-boot.git/commit/?h=nyan-big -https://lists.denx.de/pipermail/u-boot/2017-May/289491.html -https://github.com/chromeos-nvidia-androidtv/gnu-linux-on-acer-chromebook-13#copy-data-to-the-sd-card - -1. Build U-Boot - - mkdir b - make -j8 O=b/nyan-big CROSS_COMPILE=arm-linux-gnueabi- nyan-big_defconfig all - - -2. Select a .its file - -Select something from doc/chromium which matches your board, or create your -own. - -Note that the device tree node is required, even though it is not actually -used by U-Boot. This is because the Chromebook expects to pass it to the -kernel, and crashes if it is not present. - - -3. Build and sign an image - - ./b/nyan-big/tools/mkimage -f doc/chromium/nyan-big.its u-boot-chromium.fit - echo test >dummy.txt - vbutil_kernel --arch arm --keyblock doc/chromium/devkeys/kernel.keyblock \ - --signprivate doc/chromium/devkeys/kernel_data_key.vbprivk \ - --version 1 --config dummy.txt --vmlinuz u-boot-chromium.fit \ - --bootloader dummy.txt --pack u-boot.kpart - - -4. Prepare an SD card - - DISK=/dev/sdc # Replace with your actual SD card device - sudo cgpt create $DISK - sudo cgpt add -b 34 -s 32768 -P 1 -S 1 -t kernel $DISK - sudo cgpt add -b 32802 -s 2000000 -t rootfs $DISK - sudo gdisk $DISK # Enter command 'w' to write a protective MBR to the disk - - -5. Write U-Boot to the SD card +To run on sandbox: - sudo dd if=u-boot.kpart of=/dev/sdc1; sync + $UB/tpl/u-boot-tpl -d $UB/u-boot.dtb.out \ + -L6 -c "host bind 0 $CROS/src/build/images/cheza/latest/chromiumos_image.bin; vboot go auto" \ + -l -w -s state.dtb -r +To run on other boards: + Install image.bin in the SPI flash of your device + Boot your system -6. Start it up -Reboot the device in dev mode. Make sure that you have USB booting enabled. To -do this, login as root (via Ctrl-Alt-forward_arrow) and type -'enable_dev_usb_boot'. You only need to do this once. +Sandbox +------- -Reboot the device with the SD card inserted. Press Clrl-U at the developer -mode screen. It should show something like the following on the display: +Most Chromium OS development with U-Boot is undertaken using sandbox. There is +a sandbox target available (chromeos_sandbox) which allows running U-Boot on +a Linux machine completion with emulations of the display, TPM, disk, etc. - U-Boot 2017.07-00637-g242eb42-dirty (May 22 2017 - 06:14:21 -0600) +Running sandbox starts TPL, which contains the first phase of vboot, providing +a device tree and binding a Chromium OS disk image for use to find kernels +(any Chromium OS image will do). It also saves driver state between U-Boot +phases into state.dtb and will automatically ensure that memory is shared +between all phases. TPL will jump to SPL and then on to U-Boot proper. - Model: Acer Chromebook 13 CB5-311 - Board: Google/NVIDIA Nyan-big, ID: 1 +It is possible to run with debugging on, e.g. - Net: No ethernet found. - Hit any key to stop autoboot: 0 - Tegra124 (Nyan-big) # + gdb --args $UB/tpl/u-boot-tpl -d .... +Breakpoints can be set in any U-Boot phase. Overall this is a good debugging +environment for new verified-boot features. -7. Known problems -On the serial console the word MMC is chopped at the start of the line: +Samus +----- -C: sdhci@700b0000: 2, sdhci@700b0400: 1, sdhci@700b0600: 0 +Basic support is available for samus, using the chromeos_samus target. If you +have an em100, use: -This is likely due to some problem with change-over of the serial driver -during relocation (or perhaps updating the clock setup in board_init()). + sudo em100 -s -c W25Q128FW -d $UB/image.bin -t -r +to write the image and then boot samus (Power-Refresh). -9. Notes -To check that you copied the u-boot.its file correctly, use these commands. -You should see that the data at 0x100 in u-boot-chromium.fit is the first few -bytes of U-Boot: +Boot flow +--------- - hd u-boot-chromium.fit |head -20 - ... - 00000100 b8 00 00 ea 14 f0 9f e5 14 f0 9f e5 14 f0 9f e5 |................| +Verified boot starts in TPL, which selects the A or B SPL, which in turn selects +the A or B U-Boot. Then this jumps to the selected kernel. If anything goes +wrong, the device reboots and the recovery SPL and U-Boot are used instead. - hd b/nyan-big/u-boot.bin |head - 00000000 b8 00 00 ea 14 f0 9f e5 14 f0 9f e5 14 f0 9f e5 |................| +More details are available here: + https://www.chromium.org/chromium-os/chromiumos-design-docs/firmware-boot-a… -The 'data' property of the FIT is set up to start at offset 0x100 bytes into -the file. The change to CONFIG_SYS_TEXT_BASE is also an offset of 0x100 bytes -from the load address. If this changes, you either need to modify U-Boot to be -fully relocatable, or expect it to hang. +New uclasses +------------ -chromebook_jerry ----------------- +Several uclasses are provided in cros/: -The instruction are similar to those for Nyan with changes as noted below: + UCLASS_CROS_AUX_FW Chrome OS auxiliary firmware + UCLASS_CROS_FWSTORE Chrome OS firmware storage + UCLASS_CROS_NVDATA Chrome OS non-volatile data device + UCLASS_CROS_VBOOT_EC Chrome OS vboot EC operations + UCLASS_CROS_VBOOT_FLAG Chrome OS verified boot flag -1. Patch U-Boot +The existing UCLASS_CROS_EC is also used. -Open include/configs/rk3288_common.h -Change: - -#define CONFIG_SYS_TEXT_BASE 0x00100000 - -to: - -#define CONFIG_SYS_TEXT_BASE 0x02000100 - - - -2. Build U-Boot - - mkdir b - make -j8 O=b/chromebook_jerry CROSS_COMPILE=arm-linux-gnueabi- \ - chromebook_jerry_defconfig all - - -3. See above - -4. Build and sign an image - - ./b/chromebook_jerry/tools/mkimage -f doc/chromium/chromebook_jerry.its \ - u-boot-chromium.fit - echo test >dummy.txt - vbutil_kernel --arch arm --keyblock doc/chromium/devkeys/kernel.keyblock \ - --signprivate doc/chromium/devkeys/kernel_data_key.vbprivk \ - --version 1 --config dummy.txt --vmlinuz u-boot-chromium.fit \ - --bootloader dummy.txt --pack u-boot.kpart - - -5. See above +Commands +-------- -6. See above +A new 'vboot' command is provided to run particular vboot stages. The most +useful command is 'vboot go auto', which continues where the last stage left +off. -7. Start it up +Note that TPL and SPL do not supports commands as yet, so the vboot code is +called directly from the SPL boot devices (BOOT_DEVICE_CROS_VBOOT). See +cros_load_image_tpl() and cros_load_image_spl() which both call +vboot_run_auto(). -Reboot the device in dev mode. Make sure that you have USB booting enabled. To -do this, login as root (via Ctrl-Alt-forward_arrow) and type -'enable_dev_usb_boot'. You only need to do this once. -Reboot the device with the SD card inserted. Press Clrl-U at the developer -mode screen. It should show something like the following on the display: +Config options +-------------- - U-Boot 2017.05-00649-g72acdbf-dirty (May 29 2017 - 14:57:05 -0600) +The main option is CONFIG_CHROMEOS, which enables a wide array of other options +so that the required features are present. - Model: Google Jerry - Net: Net Initialization Skipped - No ethernet found. - Hit any key to stop autoboot: 0 +Device-tree config +------------------ -8. Known problems +Various options are available which control the operation of verified boot. +See cros/dts/bindings/config.txt for details. Most config is handled at run- +time, although build-time config (with Kconfig) could also be added fairly +easily. -None as yet. +Porting to other hardware +------------------------- -9. Notes +A basic port to samus (Chromebook Pixel 2015) is in a basic working state, +using the chromeos_samus target. Patches will likely be forthcoming in early +2019. Ports to an ARM board and coreboot (for x86 Chromebooks) are in the +dreaming state. -None as yet. +Tests +----- -Other notes -=========== +Chromium OS firmware has a very limited set of tests. The tests that originally +existed in U-Boot were not brought over to coreboot or depthcharge. -flashrom --------- +The U-Boot tests ('make check') do operate, but at present there are no +Chromium OS tests available. These will hopefully come together over time. Of +course the above sandbox feature provides a sort of functional test and can +detecte problems that affect the flow or particular vboot features. - Used to make a backup of your firmware, or to replace it. - See: https://www.chromium.org/chromium-os/packages/cros-flashrom +TO DO +----- +- Support for booting from coreboot (patches expected March 2019) +- Support for booting from an ARM board, e.g. bob -coreboot --------- -Coreboot itself is not designed to actually boot an OS. Instead, a program -called Depthcharge is used. This originally came out of U-Boot and was then -heavily hacked and modified such that is is almost unrecognisable. It does -include a very small part of the U-Boot command-line interface but is not -usable as a general-purpose boot loader. - -In addition, it has a very unusual design in that it does not do device init -itself, but instead relies on coreboot. This is similar to (in U-Boot) having -a SPI driver with an empty probe() method, relying on whatever was set up -beforehand. It can be quite hard to figure out between these two code bases -what settings are actually used. When chain-loading into U-Boot we must be -careful to reinit anything that U-Boot expects. If not, some peripherals (or -the whole machine) may not work. This makes the process of chainloading more -complicated than it could be on some platforms. - -Finally, it supports only a subset of the U-Boot's FIT format. In particular -it uses a fixed address to load the FIT and does not support load/exec -addresses. This means that U-Boot must be able to boot from whatever -address Depthcharge happens to use (it is the CONFIG_KERNEL_START setting -in Depthcharge). In practice this means that the data in the kernel@1 FIT node -(see above) must start at the same address as U-Boot's CONFIG_SYS_TEXT_BASE. +Simon Glass +sjg(a)chromium.org +7 October 2018 diff --git a/doc/README.chromium-chainload b/doc/README.chromium-chainload new file mode 100644 index 0000000000..45eaeced2d --- /dev/null +++ b/doc/README.chromium-chainload @@ -0,0 +1,239 @@ +Running U-Boot from coreboot on Chromebooks +=========================================== + +U-Boot can be used as a secondary boot loader in a few situations such as from +UEFI and coreboot (see README.x86). Recent Chromebooks use coreboot even on +ARM platforms to start up the machine. + +This document aims to provide a guide to booting U-Boot on a Chromebook. It +is only a starting point, and there are many guides on the interwebs. But +placing this information in the U-Boot tree should make it easier to find for +those who use U-Boot habitually. + +Most of these platforms are supported by U-Boot natively, but it is risky to +replace the ROM unless you have a servo board and cable to restore it with. + + +For all of these the standard U-Boot build instructions apply. For example on +ARM: + + sudo apt install gcc-arm-linux-gnueabi + mkdir b + make O=b/nyan_big CROSS_COMPILE=arm-linux-gnueabi- nyan-big_defconfig all + +You can obtain the vbutil_kernel utility here: + + https://drive.google.com/open?id=0B7WYZbZ9zd-3dHlVVXo4VXE2T0U + + +Snow (Samsung ARM Chromebook) +----------------------------- + +See here: + +https://www.chromium.org/chromium-os/firmware-porting-guide/using-nv-u-boot-on-the-samsung-arm-chromebook + + +Nyan-big +-------- + +Compiled based on information here: +https://lists.denx.de/pipermail/u-boot/2015-March/209530.html +https://git.collabora.com/cgit/user/tomeu/u-boot.git/commit/?h=nyan-big +https://lists.denx.de/pipermail/u-boot/2017-May/289491.html +https://github.com/chromeos-nvidia-androidtv/gnu-linux-on-acer-chromebook-13#copy-data-to-the-sd-card + +1. Build U-Boot + + mkdir b + make -j8 O=b/nyan-big CROSS_COMPILE=arm-linux-gnueabi- nyan-big_defconfig all + + +2. Select a .its file + +Select something from doc/chromium which matches your board, or create your +own. + +Note that the device tree node is required, even though it is not actually +used by U-Boot. This is because the Chromebook expects to pass it to the +kernel, and crashes if it is not present. + + +3. Build and sign an image + + ./b/nyan-big/tools/mkimage -f doc/chromium/nyan-big.its u-boot-chromium.fit + echo test >dummy.txt + vbutil_kernel --arch arm --keyblock doc/chromium/devkeys/kernel.keyblock \ + --signprivate doc/chromium/devkeys/kernel_data_key.vbprivk \ + --version 1 --config dummy.txt --vmlinuz u-boot-chromium.fit \ + --bootloader dummy.txt --pack u-boot.kpart + + +4. Prepare an SD card + + DISK=/dev/sdc # Replace with your actual SD card device + sudo cgpt create $DISK + sudo cgpt add -b 34 -s 32768 -P 1 -S 1 -t kernel $DISK + sudo cgpt add -b 32802 -s 2000000 -t rootfs $DISK + sudo gdisk $DISK # Enter command 'w' to write a protective MBR to the disk + + +5. Write U-Boot to the SD card + + sudo dd if=u-boot.kpart of=/dev/sdc1; sync + + +6. Start it up + +Reboot the device in dev mode. Make sure that you have USB booting enabled. To +do this, login as root (via Ctrl-Alt-forward_arrow) and type +'enable_dev_usb_boot'. You only need to do this once. + +Reboot the device with the SD card inserted. Press Clrl-U at the developer +mode screen. It should show something like the following on the display: + + U-Boot 2017.07-00637-g242eb42-dirty (May 22 2017 - 06:14:21 -0600) + + Model: Acer Chromebook 13 CB5-311 + Board: Google/NVIDIA Nyan-big, ID: 1 + + Net: No ethernet found. + Hit any key to stop autoboot: 0 + Tegra124 (Nyan-big) # + + +7. Known problems + +On the serial console the word MMC is chopped at the start of the line: + +C: sdhci@700b0000: 2, sdhci@700b0400: 1, sdhci@700b0600: 0 + +This is likely due to some problem with change-over of the serial driver +during relocation (or perhaps updating the clock setup in board_init()). + + +9. Notes + +To check that you copied the u-boot.its file correctly, use these commands. +You should see that the data at 0x100 in u-boot-chromium.fit is the first few +bytes of U-Boot: + + hd u-boot-chromium.fit |head -20 + ... + 00000100 b8 00 00 ea 14 f0 9f e5 14 f0 9f e5 14 f0 9f e5 |................| + + hd b/nyan-big/u-boot.bin |head + 00000000 b8 00 00 ea 14 f0 9f e5 14 f0 9f e5 14 f0 9f e5 |................| + + +The 'data' property of the FIT is set up to start at offset 0x100 bytes into +the file. The change to CONFIG_SYS_TEXT_BASE is also an offset of 0x100 bytes +from the load address. If this changes, you either need to modify U-Boot to be +fully relocatable, or expect it to hang. + + +chromebook_jerry +---------------- + +The instruction are similar to those for Nyan with changes as noted below: + +1. Patch U-Boot + +Open include/configs/rk3288_common.h + +Change: + +#define CONFIG_SYS_TEXT_BASE 0x00100000 + +to: + +#define CONFIG_SYS_TEXT_BASE 0x02000100 + + + +2. Build U-Boot + + mkdir b + make -j8 O=b/chromebook_jerry CROSS_COMPILE=arm-linux-gnueabi- \ + chromebook_jerry_defconfig all + + +3. See above + +4. Build and sign an image + + ./b/chromebook_jerry/tools/mkimage -f doc/chromium/chromebook_jerry.its \ + u-boot-chromium.fit + echo test >dummy.txt + vbutil_kernel --arch arm --keyblock doc/chromium/devkeys/kernel.keyblock \ + --signprivate doc/chromium/devkeys/kernel_data_key.vbprivk \ + --version 1 --config dummy.txt --vmlinuz u-boot-chromium.fit \ + --bootloader dummy.txt --pack u-boot.kpart + + +5. See above + +6. See above + +7. Start it up + +Reboot the device in dev mode. Make sure that you have USB booting enabled. To +do this, login as root (via Ctrl-Alt-forward_arrow) and type +'enable_dev_usb_boot'. You only need to do this once. + +Reboot the device with the SD card inserted. Press Clrl-U at the developer +mode screen. It should show something like the following on the display: + + U-Boot 2017.05-00649-g72acdbf-dirty (May 29 2017 - 14:57:05 -0600) + + Model: Google Jerry + Net: Net Initialization Skipped + No ethernet found. + Hit any key to stop autoboot: 0 + + +8. Known problems + +None as yet. + + +9. Notes + +None as yet. + + +Other notes +=========== + +flashrom +-------- + + Used to make a backup of your firmware, or to replace it. + + See: https://www.chromium.org/chromium-os/packages/cros-flashrom + + +coreboot +-------- + +Coreboot itself is not designed to actually boot an OS. Instead, a program +called Depthcharge is used. This originally came out of U-Boot and was then +heavily hacked and modified such that is is almost unrecognisable. It does +include a very small part of the U-Boot command-line interface but is not +usable as a general-purpose boot loader. + +In addition, it has a very unusual design in that it does not do device init +itself, but instead relies on coreboot. This is similar to (in U-Boot) having +a SPI driver with an empty probe() method, relying on whatever was set up +beforehand. It can be quite hard to figure out between these two code bases +what settings are actually used. When chain-loading into U-Boot we must be +careful to reinit anything that U-Boot expects. If not, some peripherals (or +the whole machine) may not work. This makes the process of chainloading more +complicated than it could be on some platforms. + +Finally, it supports only a subset of the U-Boot's FIT format. In particular +it uses a fixed address to load the FIT and does not support load/exec +addresses. This means that U-Boot must be able to boot from whatever +address Depthcharge happens to use (it is the CONFIG_KERNEL_START setting +in Depthcharge). In practice this means that the data in the kernel@1 FIT node +(see above) must start at the same address as U-Boot's CONFIG_SYS_TEXT_BASE. -- 2.20.1.495.gaa96b0ce6b-goog

2 4

[U-Boot] [PATCH 0/3] Ethernet support for QEMU sifive_u machine
by Anup Patel 07 Aug '19

07 Aug '19

This patchset enables Cadance MACB ethernet driver for QEMU sifive_u machine. The Cadance MACB ethernet driver works fine for QEMU sifive_u machince in both M-mode and S-mode with some minor fixes. The patches are based upon latest RISC-V U-Boot tree (git://git.denx.de/u-boot-riscv.git) at commit id 9deb8d2fcd13d4a40a4e63c396fe4376af46efac To try on QEMU, please ensure following patches are applied to QEMU sources: https://patchwork.kernel.org/patch/10729579/ https://patchwork.kernel.org/patch/10729581/ Anup Patel (3): riscv: Add asm/dma-mapping.h for DMA mappings net: macb: Fix clk API usage for RISC-V systems riscv: qemu: Imply MACB ethernet for emulation arch/riscv/include/asm/dma-mapping.h | 37 ++++++++++++++++++++++++++++ board/emulation/qemu-riscv/Kconfig | 4 +++ drivers/net/macb.c | 4 ++- 3 files changed, 44 insertions(+), 1 deletion(-) create mode 100644 arch/riscv/include/asm/dma-mapping.h -- 2.17.1

2 25

[U-Boot] [PATCH 2/2] efi_loader: set the dhcp ack received flag
by Patrick Wildt 06 Aug '19

06 Aug '19

The PXE object contains a flag that specifies whether or not a DHCP ACK has been received. This can be used by EFI Applications to find out whether or not it is worth to read the DHCP information from our object. Signed-off-by: Patrick Wildt <patrick(a)blueri.se> --- lib/efi_loader/efi_net.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/lib/efi_loader/efi_net.c b/lib/efi_loader/efi_net.c index 8c5d5b492c..0b9c7b9345 100644 --- a/lib/efi_loader/efi_net.c +++ b/lib/efi_loader/efi_net.c @@ -332,8 +332,10 @@ int efi_net_register(void) netobj->net_mode.max_packet_size = PKTSIZE; netobj->pxe.mode = &netobj->pxe_mode; - if (dhcp_ack) + if (dhcp_ack) { netobj->pxe_mode.dhcp_ack = *dhcp_ack; + netobj->pxe_mode.dhcp_ack_received = 1; + } /* * Create WaitForPacket event. -- 2.14.3 (Apple Git-98)

5 19

[U-Boot] [PATCH 0/10] x86: Add generic VESA video driver
by Simon Glass 01 Aug '19

01 Aug '19

This series introduces a generic VESA video driver and adjusts the generic PCI ROM support to support it. It also fixes up some problems which prevent this from working on PowerPC at present. It is now possible to use VESA graphics: - On PowerPC, using the x86 emulator - On x86, using either the x86 emulator or native code execution As it turns out, on the only platform I have tested (link), the x86 emulator is only slightly slower that native code execution (200ms difference). Still, we may as well leave this feature in there. VGA ROMs are a very old technology but they are still used by modern platforms, including at least link and some Atom designs. Simon Glass (10): bios_emulator: Fix an #ifdef typo in the header file x86: Correct endianness isues in pci_rom x86: Support ROMs on other archs bios_emulator: Don't display error when emulator terminates bios_emulator: Add some VESA interface debugging x86: pci: Don't stop when we get a vendor/device mismatch x86: Add a VESA video driver x86: Drop the x86_fb driver x86: Access the VGA ROM when needed RFC: Test code for glacier PCI video support arch/x86/include/asm/u-boot-x86.h | 2 + drivers/bios_emulator/atibios.c | 161 +++++++++++++++++++++++---- drivers/bios_emulator/include/x86emu/debug.h | 2 +- drivers/bios_emulator/x86emu/ops.c | 2 +- drivers/pci/pci_auto.c | 28 ++++- drivers/pci/pci_rom.c | 40 ++++--- drivers/video/Makefile | 2 +- drivers/video/vesa_fb.c | 64 +++++++++++ drivers/video/x86_fb.c | 38 ------- include/configs/canyonlands.h | 31 ++++++ include/configs/chromebook_link.h | 2 +- include/pci.h | 9 ++ include/pci_rom.h | 1 - include/vbe.h | 9 +- 14 files changed, 312 insertions(+), 79 deletions(-) create mode 100644 drivers/video/vesa_fb.c delete mode 100644 drivers/video/x86_fb.c -- 2.2.0.rc0.207.ga3a616c

3 42