September 2016 - U-Boot

[U-Boot] [PATCH v3 0/7] Adds support for secure boot on Keystone SoCs (K2E)
by Srinivas, Madan 09 Sep '16

09 Sep '16

This series adds support for secure keystone family of devices, more specifically for K2E (Edison).This work is similar to what has already been done for the AM43xx and AM57xx SoCs and leverages much of the infrastructure from them. The big difference here is the ROM on keystone2 devices does not provide any APIs for image authentication. Rather, the image authentication and decryption routines and other security functions are provided by software and can run on the ARM in Trustzone as well as on secure DSPs. A component known as the boot monitor acts as they gateway to this secure processing, and abstracts out the details from the public world. Unlike OMAP class devices, where u-boot calls ROM APIs, u-boot calls into the boot- monitor on keystone devices. Other than this difference, most of the secure framework for AMxx and DRAxx devices have been re-used. Couple of other points to note :- -Support for SPL on secure keystone devices is still TBD, so boot from SPI flash, which needs SPL, is not supported currently on K2 devices. -A single image will work across all other boot media for secure K2 devices. Changes in v3: - Corrects commit message in patch 5/7 in this series to refer to u-boot_HS_MLO Changes in v2: - Corrects typo in commit message for PATCH 1/7 in this series - The following changes are made to mon.c based on review comments Adds NULL pointer check before calling authentication interface Removes an unnecessary printf Updates size of signed FIT blob after post processing removes header - Adds a new name for the signed output image in config_secure.mk to keep it in line with the image name used by non-secure keystone devices. - Changes the target for secure keystone devices in config.mk to u-boot_HS_MLO to keep it in line with the MLO target that is built for non-secure keystone devices. - Updates the secure keystone image name to u-boot_HS_MLO in README.ti-secure to match with the changes made to config.mk in this series version. - Updates k2e_hs_evm_defconfig to reduce the delta seen if one regenerates it using savedefconfig or similar tools. Madan Srinivas (4): include: image.h: Fixes build warning with CONFIG_FIT_IMAGE_POST_PROCESS arm: omap-common: adds secure image name common to OMAP and keystone arm: mach-keystone: config.mk: Adds support for secure images on K2 doc: Updates info on using keystone secure devices from TI Vitaly Andrianov (3): arm: mach-keystone: Implements FIT post-processing call for keystone SoCs arm: omap-common: Enable support for K2 HS devices in u-boot configs: Adds a defconfig for K2E High Security EVM arch/arm/cpu/armv7/omap-common/Kconfig | 2 +- arch/arm/cpu/armv7/omap-common/config_secure.mk | 6 +++ arch/arm/mach-keystone/config.mk | 6 +++ arch/arm/mach-keystone/mon.c | 55 +++++++++++++++++++++++++ configs/k2e_hs_evm_defconfig | 43 +++++++++++++++++++ doc/README.ti-secure | 20 +++++++++ include/image.h | 3 +- 7 files changed, 133 insertions(+), 2 deletions(-) create mode 100644 configs/k2e_hs_evm_defconfig -- 2.7.4

1 0

[U-Boot] config USB_STORAGE: defconfig vs include header
by Stephen Warren 09 Sep '16

09 Sep '16

Masahiro, In patch 6e7e9294d321 "usb: add basic USB configs in Kconfig", you added "config USB_STORAGE" to drivers/usb/Kconfig. However, it's still just #defined by many include/configs/*.h rather than being defined in configs/*_defconfig. Is that a problem? It seems to work in practice, but leads people adding new boards to put the definition in configs/*_defconfig which then may be inconsistent with similar existing boards which have it defined in include/configs/*.h.

3 6

Re: [U-Boot] [PATCH 3/3 v2] test/fs: strip carriage-return from sandbox output
by Stefan Bruens 08 Sep '16

08 Sep '16

On Donnerstag, 11. August 2016 22:52:05 CEST you wrote: > DM added carriage-returns to every newline. Strip everything after the > 32 character long mdsum. > > Signed-off-by: Stefan Brüns <stefan.bruens(a)rwth-aachen.de> > --- > test/fs/fs-test.sh | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/test/fs/fs-test.sh b/test/fs/fs-test.sh > index 043e5d0..171b1de 100755 > --- a/test/fs/fs-test.sh > +++ b/test/fs/fs-test.sh > @@ -402,7 +402,7 @@ check_md5() { > # the 7th field is the actual md5 > md5_src=`grep -A3 "$1" "$2" | grep "md5 for"` > md5_src=($md5_src) > - md5_src=${md5_src[6]} > + md5_src=${md5_src[6]:0:32} > > # The md5 list, each line is of the form: > # - <md5> This issue has been fixed in a different way. Superseded-by: 634a4d2e825ba2effc01298ca194cd5cb09f6e3a "fs-test.sh: Correct check_md5() test with newlines" Kind regards, Stefan -- Stefan Brüns / Bergstraße 21 / 52062 Aachen home: +49 241 53809034 mobile: +49 151 50412019 work: +49 2405 49936-424

2 1

[U-Boot] [PATCH] Fix fastboot boot address Fastboot loads an image at CONFIG_FASTBOOT_BUF_ADDR, but currently tells do_bootm() to look for an image at $loadaddr. This breaks if CONFIG_FASTBOOT_BUF_ADDR is different from the current user-set loadaddr.
by Peter.Chubb＠data61.csiro.au 08 Sep '16

08 Sep '16

Instead, tell do_bootm() to pick up the image where it was laoded. Signed-off-by: Peter Chubb <peter.chubb(a)data61.csiro.au> --- drivers/usb/gadget/f_fastboot.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/usb/gadget/f_fastboot.c b/drivers/usb/gadget/f_fastboot.c index 2160b1c..6d02248 100644 --- a/drivers/usb/gadget/f_fastboot.c +++ b/drivers/usb/gadget/f_fastboot.c @@ -553,7 +553,7 @@ static void do_bootm_on_complete(struct usb_ep *ep, struct usb_request *req) puts("Booting kernel..\n"); - sprintf(boot_addr_start, "0x%lx", load_addr); + sprintf(boot_addr_start, "0x%lx", CONFIG_FASTBOOT_BUF_ADDR); do_bootm(NULL, 0, 2, bootm_args); /* This only happens if image is somehow faulty so we start over */ -- 2.9.3

1 0

[U-Boot] EHCI timed out on TD - token=0x80008d80
by Andreas Neubacher 08 Sep '16

08 Sep '16

Hi Marek & Team :), i'm facing the same issue as Manju and all the others on the web (see mail below). i've tested it on different hardware-platforms and different uboot-versions... - ATMEL G45 (custom board), uboot 2015.01 - ATMEL G45 (custom board), uboot 2013.03 - ATMEL SAMA5D36 (custom board), uboot 2016.03 - ATMEL SAMA5D36 (custom board), uboot-mainline what we did: we are using usb-memory-sticks for updating our complete system (rootfs, kernel, etc.) and somtimes copy files larger than 50MB from USB to RAM (fatload usb 0 $loadaddr file.bin). we've tested different speed-classes, different stick-sizes and different quality-standards of the usb-sticks. from all the different type of sticks we've tested, we found some 'bad sticks' where we get the error-msg EHCI timed out on TD - token=0x9e008d80 EHCI timed out on TD - token=0x1e008d80 EHCI timed out on TD - token=0x1e008d80 ... in all uboot-versions and on all different boards the behaviour is the same -> so IMHO the issue depends on the 'bad usb-stick(s)' we are using. so we investigated the 'bad usb-sticks' with different diagnostic-tools on windows(10) and linux(ubuntu) host-machines without any result... means: it looks like the 'bad-stick' on any host-machine is working as expected (good r/w performance, no timeouts, no issues, etc.) if i can do further investigations please let me know :) br, Andy Hello Marek, If the USB is detected successfully, then below are the logs. U-Boot > usb start (Re)start USB... USB0: USB EHCI 1.00 scanning bus 0 for devices... New Device 0 usb_control_msg: request: 0x6, requesttype: 0x80, value 0x100 index 0x0 length 0x40 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 0x19 get_conf_no 0 Result 25, wLength 25 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 0x1 usb_control_msg: request: 0x6, requesttype: 0x80, value 0x301 index 0x1 length 0xFF usb_control_msg: request: 0x6, requesttype: 0x80, value 0x302 index 0x1 length 0xFF Manufacturer u-boot Product EHCI Host Controller SerialNumber usb_control_msg: request: 0x6, requesttype: 0xA0, value 0x2900 index 0x0 length 0x4 usb_control_msg: request: 0x6, requesttype: 0xA0, value 0x2900 index 0x0 length 0x8 usb_control_msg: request: 0x0, requesttype: 0xA0, value 0x0 index 0x0 length 0x4 usb_control_msg: request: 0x3, requesttype: 0x23, value 0x8 index 0x1 length 0x0 usb_control_msg: request: 0x0, requesttype: 0xA3, value 0x0 index 0x1 length 0x4 usb_control_msg: request: 0x0, requesttype: 0xA3, value 0x0 index 0x1 length 0x4 usb_control_msg: request: 0x1, requesttype: 0x23, value 0x10 index 0x1 length 0x0 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 usb_control_msg: request: 0x1, requesttype: 0x23, value 0x14 index 0x1 length 0x0 New Device 1 usb_control_msg: request: 0x6, requesttype: 0x80, value 0x100 index 0x0 length 0x40 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 usb_control_msg: request: 0x1, requesttype: 0x23, value 0x14 index 0x1 length 0x0 set address 2 usb_control_msg: request: 0x5, requesttype: 0x0, value 0x2 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 0x20 get_conf_no 0 Result 32, wLength 32 if 0, ep 0 if 0, ep 1 ##EP epmaxpacketin[1] = 512 ##EP epmaxpacketout[2] = 512 set configuration 1 usb_control_msg: request: 0x9, requesttype: 0x0, value 0x1 index 0x0 length 0x0 new device strings: Mfr=1, Product=2, SerialNumber=3 usb_control_msg: request: 0x6, requesttype: 0x80, value 0x300 index 0x0 length 0xFF USB device number 2 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 usb_control_msg: request: 0x6, requesttype: 0x80, value 0x303 index 0x409 length 0xFF Manufacturer JetFlash Product Mass Storage Device SerialNumber 99TL2DWA1OQMAIUS 2 USB Device(s) found USB1: USB EHCI 1.00 scanning bus 1 for devices... New Device 2 usb_control_msg: request: 0x6, requesttype: 0x80, value 0x100 index 0x0 length 0x40 set address 3 usb_control_msg: request: 0x5, requesttype: 0x0, value 0x3 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 0x19 get_conf_no 0 Result 25, wLength 25 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 3 default language ID 0x1 usb_control_msg: request: 0x6, requesttype: 0x80, value 0x301 index 0x1 length 0xFF usb_control_msg: request: 0x6, requesttype: 0x80, value 0x302 index 0x1 length 0xFF Manufacturer u-boot Product EHCI Host Controller SerialNumber usb_control_msg: request: 0x6, requesttype: 0xA0, value 0x2900 index 0x0 length 0x4 usb_control_msg: request: 0x6, requesttype: 0xA0, value 0x2900 index 0x0 length 0x8 usb_control_msg: request: 0x0, requesttype: 0xA0, value 0x0 index 0x0 length 0x4 usb_control_msg: request: 0x3, requesttype: 0x23, value 0x8 index 0x1 length 0x0 usb_control_msg: request: 0x0, requesttype: 0xA3, value 0x0 index 0x1 length 0x4 usb_control_msg: request: 0x0, requesttype: 0xA3, value 0x0 index 0x1 length 0x4 usb_control_msg: request: 0x1, requesttype: 0x23, value 0x10 index 0x1 length 0x0 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 usb_control_msg: request: 0x1, requesttype: 0x23, value 0x14 index 0x1 length 0x0 New Device 3 usb_control_msg: request: 0x6, requesttype: 0x80, value 0x100 index 0x0 length 0x40 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 usb_control_msg: request: 0x1, requesttype: 0x23, value 0x14 index 0x1 length 0x0 set address 4 usb_control_msg: request: 0x5, requesttype: 0x0, value 0x4 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 0x20 get_conf_no 0 Result 32, wLength 32 if 0, ep 0 if 0, ep 1 ##EP epmaxpacketin[1] = 512 ##EP epmaxpacketout[2] = 512 set configuration 1 usb_control_msg: request: 0x9, requesttype: 0x0, value 0x1 index 0x0 length 0x0 new device strings: Mfr=1, Product=2, SerialNumber=3 usb_control_msg: request: 0x6, requesttype: 0x80, value 0x300 index 0x0 length 0xFF USB device number 4 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 usb_control_msg: request: 0x6, requesttype: 0x80, value 0x303 index 0x409 length 0xFF Manufacturer JetFlash Product Mass Storage Device SerialNumber 99TL2DWA1OQMAIUS 2 USB Device(s) found scan end scanning usb for storage devices... usb_control_msg: request: 0xFE, requesttype: 0xA1, value 0x0 index 0x0 length 0x1 EHCI timed out on TD - token=0x80008c80 usb_control_msg: request: 0xFF, requesttype: 0x21, value 0x0 index 0x0 length 0x0 EHCI timed out on TD - token=0x80008d80 usb_control_msg: request: 0xFF, requesttype: 0x21, value 0x0 index 0x0 length 0x0 EHCI timed out on TD - token=0x80008d80 usb_control_msg: request: 0xFF, requesttype: 0x21, value 0x0 index 0x0 length 0x0 EHCI timed out on TD - token=0x80008d80 usb_control_msg: request: 0xFF, requesttype: 0x21, value 0x0 index 0x0 length 0x0 EHCI timed out on TD - token=0x80008d80 usb_control_msg: request: 0xFF, requesttype: 0x21, value 0x0 index 0x0 length 0x0 EHCI timed out on TD - token=0x80008d80 error in inquiry usb_control_msg: request: 0xFE, requesttype: 0xA1, value 0x0 index 0x0 length 0x1 1 Storage Device(s) found I would be really happy to receive your help. Regards, Manju ----- Original Message ----- From: "Manjunath" <manjunath at tes-dst.com <http://lists.denx.de/mailman/listinfo/u-boot>> To: "u-boot" <u-boot at lists.denx.de <http://lists.denx.de/mailman/listinfo/u-boot>> Cc: marex at denx.de <http://lists.denx.de/mailman/listinfo/u-boot>, "marek vasut" <marek.vasut at gmail.com <http://lists.denx.de/mailman/listinfo/u-boot>> Sent: Thursday, April 21, 2016 11:19:03 AM Subject: Fwd: EHCI timed out on TD - token=0x80008d80 ----- Forwarded Message ----- From: "Manjunath" <manjunath at tes-dst.com <http://lists.denx.de/mailman/listinfo/u-boot>> To: "fabio estevam" <fabio.estevam at nxp.com <http://lists.denx.de/mailman/listinfo/u-boot>> Sent: Wednesday, April 20, 2016 4:03:05 PM Subject: Re: EHCI timed out on TD - token=0x80008d80 Hi Fabio, No it doesn't. I enabled debug prints and i get the following. U-Boot > usb start (Re)start USB... USB0: USB EHCI 1.00 scanning bus 0 for devices... New Device 0 usb_control_msg: request: 0x6, requesttype: 0x80, value 0x100 index 0x0 length 0x40 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 0x19 get_conf_no 0 Result 25, wLength 25 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 0x1 usb_control_msg: request: 0x6, requesttype: 0x80, value 0x301 index 0x1 length 0xFF usb_control_msg: request: 0x6, requesttype: 0x80, value 0x302 index 0x1 length 0xFF Manufacturer u-boot Product EHCI Host Controller SerialNumber usb_control_msg: request: 0x6, requesttype: 0xA0, value 0x2900 index 0x0 length 0x4 usb_control_msg: request: 0x6, requesttype: 0xA0, value 0x2900 index 0x0 length 0x8 usb_control_msg: request: 0x0, requesttype: 0xA0, value 0x0 index 0x0 length 0x4 usb_control_msg: request: 0x3, requesttype: 0x23, value 0x8 index 0x1 length 0x0 usb_control_msg: request: 0x0, requesttype: 0xA3, value 0x0 index 0x1 length 0x4 1 USB Device(s) found USB1: USB EHCI 1.00 scanning bus 1 for devices... New Device 1 usb_control_msg: request: 0x6, requesttype: 0x80, value 0x100 index 0x0 length 0x40 set address 2 usb_control_msg: request: 0x5, requesttype: 0x0, value 0x2 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 0x19 get_conf_no 0 Result 25, wLength 25 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 2 default language ID 0x1 usb_control_msg: request: 0x6, requesttype: 0x80, value 0x301 index 0x1 length 0xFF usb_control_msg: request: 0x6, requesttype: 0x80, value 0x302 index 0x1 length 0xFF Manufacturer u-boot Product EHCI Host Controller SerialNumber usb_control_msg: request: 0x6, requesttype: 0xA0, value 0x2900 index 0x0 length 0x4 usb_control_msg: request: 0x6, requesttype: 0xA0, value 0x2900 index 0x0 length 0x8 usb_control_msg: request: 0x0, requesttype: 0xA0, value 0x0 index 0x0 length 0x4 usb_control_msg: request: 0x3, requesttype: 0x23, value 0x8 index 0x1 length 0x0 usb_control_msg: request: 0x0, requesttype: 0xA3, value 0x0 index 0x1 length 0x4 1 USB Device(s) found scan end scanning usb for storage devices... 0 Storage Device(s) found Regards, Manju ----- Original Message ----- From: "fabio estevam" <fabio.estevam at nxp.com <http://lists.denx.de/mailman/listinfo/u-boot>> To: "Manjunath" <manjunath at tes-dst.com <http://lists.denx.de/mailman/listinfo/u-boot>> Sent: Monday, April 18, 2016 6:16:18 PM Subject: Re: EHCI timed out on TD - token=0x80008d80 Hi Manju, Does setting USB_MAX_XFER_BLK to 32767 solve this issue? Regards, Fabio Estevam ________________________________________ From: Manjunath <manjunath at tes-dst.com <http://lists.denx.de/mailman/listinfo/u-boot>> Sent: Monday, April 18, 2016 4:14:08 AM To: Fabio Estevam Subject: EHCI timed out on TD - token=0x80008d80 Hello Fabio, Hope you are doing well. I needed your help in solving one issue that i am stuck with. The issue is regarding u-boot 2013.04 version. This version supports USB. The issue i am facing is, EHCI timed out on TD - token=0x80008d80 This time out error occurs when i flash u-boot first time on the board. But first time even though this error is seen the USB is detected and content of USB can be accessed./ For the second time when i reboot, the same USB key is not detected since i get below error, U-Boot > usb start (Re)start USB... USB0: USB EHCI 1.00 scanning bus 0 for devices... 1 USB Device(s) found USB1: USB EHCI 1.00 scanning bus 1 for devices... 1 USB Device(s) found scanning usb for storage devices... 0 Storage Device(s) found scanning usb for ethernet devices... 0 Ethernet Device(s) found Please let me know what is your view on this. Since you are a member of u-boot community i am assuming that somebody would have had this issue before. I have tried mailing to u-boot team but i didn't get any response. I need your help. Regards, Manju

2 1

[U-Boot] [RFC] bootm: fix passing argc to standalone apps
by Zubair Lutfullah Kakakhel 08 Sep '16

08 Sep '16

This bug appears in b6396403 which makes u-boot unable to pass arguments via bootm to a standalone application without this patch. Steps to reproduce. Compile a u-boot. Use mkimage to package the standalone hello_world.bin file. e.g. For the MIPS Boston platform mkimage -n "hello" -A mips -O u-boot -C none -T standalone \ -a 0xffffffff80200000 -d hello_world.bin \ -ep 0xffffffff80200000 hello_out Then tftp hello_out and run it using boston # dhcp 192.168.154.45:hello_out ... boston # bootm $loadaddr 123 321 Without the patch the following output is observed. Example expects ABI version 8 Actual U-Boot ABI version 8 Hello World argc = 0 argv[0] = "0xffffffff88000000" With the patch, you see the following. boston # bootm $loadaddr 123 321 Image Name: hello Image Type: MIPS U-Boot Standalone Program (uncompressed) Data Size: 1240 Bytes = 1.2 KiB Load Address: 80200000 Entry Point: 80200000 Verifying Checksum ... OK Loading Standalone Program ... OK Example expects ABI version 8 Actual U-Boot ABI version 8 Hello World argc = 0 argv[0] = "0xffffffff88000000" Hit any key to exit ... The go command at the entry point seems to work. boston # go 0xffffffff80200000 123 321 Example expects ABI version 8 Actual U-Boot ABI version 8 Hello World argc = 3 argv[0] = "0xffffffff80200000" argv[1] = "123" argv[2] = "321" argv[3] = "<NULL>" Hit any key to exit ... Signed-off-by: Zubair Lutfullah Kakakhel <Zubair.Kakakhel(a)imgtec.com> --- Tested on the MIPS Boston platform. --- common/bootm.c | 4 +--- 1 file changed, 1 insertion(+), 3 deletions(-) diff --git a/common/bootm.c b/common/bootm.c index a4d22a6..b2c0912 100644 --- a/common/bootm.c +++ b/common/bootm.c @@ -619,10 +619,8 @@ int do_bootm_states(cmd_tbl_t *cmdtp, int flag, int argc, char * const argv[], if (!ret && (states & BOOTM_STATE_FINDOS)) ret = bootm_find_os(cmdtp, flag, argc, argv); - if (!ret && (states & BOOTM_STATE_FINDOTHER)) { + if (!ret && (states & BOOTM_STATE_FINDOTHER)) ret = bootm_find_other(cmdtp, flag, argc, argv); - argc = 0; /* consume the args */ - } /* Load the OS */ if (!ret && (states & BOOTM_STATE_LOADOS)) { -- 1.9.1

2 2

[U-Boot] [PATCH 0/3] Fastboot MBR and generic partition support
by Petr Kulhavy 08 Sep '16

08 Sep '16

This set extends the Fastboot implementation from GPT-only to any partition support. Further it adds a special target "mbr" (configurable) to write the DOS MBR. Petr Kulhavy (3): disk: part: implement generic function part_get_info_by_name() fastboot: add support for writing MBR disk: part: refactor generic name creation for DOS and ISO README | 7 +++++ common/fb_mmc.c | 44 +++++++++++++++++++++++------ disk/part.c | 58 +++++++++++++++++++++++++++++++++++++ disk/part_amiga.c | 1 + disk/part_dos.c | 52 +++++++++++++++------------------- disk/part_efi.c | 20 +------------ disk/part_iso.c | 26 ++--------------- disk/part_mac.c | 1 + doc/README.android-fastboot | 38 +++++++++++++++++++++++++ include/part.h | 69 +++++++++++++++++++++++++++++++++++++-------- 10 files changed, 224 insertions(+), 92 deletions(-) -- 2.7.4

2 7

[U-Boot] RFC: 'fastboot boot' uses wrong address when calling bootm
by Peter.Chubb＠data61.csiro.au 08 Sep '16

08 Sep '16

Hi Folks, If you set CONFIG_FASTBOOT_BUF_ADDR to anything other than the same as $loadaddr then the call to do_bootm() in the fastboot code will call do_bootm on a memory region that has nothing to do with the image downloaded. Sometimes the result is a hung system, other times the system reboots. I'm not sure of the correct fix. The possibilities are: 1. Get rid of CONFIG_FASTBOOT_BUF_ADDR and use $loadaddr instead. All the defconfigs that enable fastboot currently set CONFIG_FASTBOOT_BUF_ADDR to the same value as CONFIG_LOADADDR at present. 2. memcpy from the downloaded image to $loadaddr if possible. This would allow other payloads than ANDROID boot images, with a bit more work. (For example, I'd love to be able to boot ELF images using fastboot -- which doesn't work at present, because the entry point in the elf header isn't used) 3. The simplest: call do_bootm() with the address where the image has just been downloaded. The attached patch does this. What do you think? Peter C drivers/usb/gadget/f_fastboot.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) Index: u-boot/drivers/usb/gadget/f_fastboot.c =================================================================== --- u-boot.orig/drivers/usb/gadget/f_fastboot.c 2016-09-06 14:10:55.791917017 +1000 +++ u-boot/drivers/usb/gadget/f_fastboot.c 2016-09-07 19:20:23.087155135 +1000 @@ -553,7 +553,7 @@ static void do_bootm_on_complete(struct puts("Booting kernel..\n"); - sprintf(boot_addr_start, "0x%lx", load_addr); + sprintf(boot_addr_start, "0x%lx", CONFIG_FASTBOOT_BUF_ADDR); do_bootm(NULL, 0, 2, bootm_args); /* This only happens if image is somehow faulty so we start over */ -- Dr Peter Chubb Tel: +61 2 9490 5852 http://ts.data61.csiro.au/ Trustworthy Systems Group Data61 (formerly NICTA)

2 1

[U-Boot] [PATCH v2 0/7] Adds support for secure boot on Keystone SoCs (K2E)
by Madan Srinivas 08 Sep '16

08 Sep '16

This series adds support for secure keystone family of devices, more specifically for K2E (Edison).This work is similar to what has already been done for the AM43xx and AM57xx SoCs and leverages much of the infrastructure from them. The big difference here is the ROM on keystone2 devices does not provide any APIs for image authentication. Rather, the image authentication and decryption routines and other security functions are provided by software and can run on the ARM in Trustzone as well as on secure DSPs. A component known as the boot monitor acts as they gateway to this secure processing, and abstracts out the details from the public world. Unlike OMAP class devices, where u-boot calls ROM APIs, u-boot calls into the boot- monitor on keystone devices. Other than this difference, most of the secure framework for AMxx and DRAxx devices have been re-used. Couple of other points to note :- -Support for SPL on secure keystone devices is still TBD, so boot from SPI flash, which needs SPL, is not supported currently on K2 devices. -A single image will work across all other boot media for secure K2 devices. Changes in v2: - Corrects typo in commit message for PATCH 1/7 in this series - The following changes are made to mon.c based on review comments Adds NULL pointer check before calling authentication interface Removes an unnecessary printf Updates size of signed FIT blob after post processing removes header - Adds a new name for the signed output image in config_secure.mk to keep it in line with the image name used by non-secure keystone devices. - Changes the target for secure keystone devices in config.mk to u-boot_HS_MLO to keep it in line with the MLO target that is built for non-secure keystone devices. - Updates k2e_hs_evm_defconfig to reduce the delta seen if one regenerates it using savedefconfig or similar tools. Madan Srinivas (4): include: image.h: Fixes build warning with CONFIG_FIT_IMAGE_POST_PROCESS arm: omap-common: adds secure image name common to OMAP and keystone arm: mach-keystone: config.mk: Adds support for secure images on K2 doc: Updates info on using keystone secure devices from TI Vitaly Andrianov (3): arm: mach-keystone: Implements FIT post-processing call for keystone SoCs arm: omap-common: Enable support for K2 HS devices in u-boot configs: Adds a defconfig for K2E High Security EVM arch/arm/cpu/armv7/omap-common/Kconfig | 2 +- arch/arm/cpu/armv7/omap-common/config_secure.mk | 6 +++ arch/arm/mach-keystone/config.mk | 6 +++ arch/arm/mach-keystone/mon.c | 55 +++++++++++++++++++++++++ configs/k2e_hs_evm_defconfig | 43 +++++++++++++++++++ doc/README.ti-secure | 20 +++++++++ include/image.h | 3 +- 7 files changed, 133 insertions(+), 2 deletions(-) create mode 100644 configs/k2e_hs_evm_defconfig -- 2.7.4

6 19

[U-Boot] [PATCH] usb: gadget: ci_udc: fix suspend/resume of USB Mass Storage
by John Tobias 08 Sep '16

08 Sep '16

When the host machine went to suspend mode and then wake it up, it send a USB_REQ_GET_STATUS. The existing case condition below, never become true and it causes the host machine to reset the connection. Once, it reset you will see an error "Disk Not Ejected Properly". case SETUP(USB_DIR_IN | USB_RECIP_DEVICE, USB_REQ_GET_STATUS): By applying this patch, the device could respond to the USB_REQ_GET_STATUS command correctly. --- drivers/usb/gadget/ci_udc.c | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/drivers/usb/gadget/ci_udc.c b/drivers/usb/gadget/ci_udc.c index d36bcf6..fdec613 100644 --- a/drivers/usb/gadget/ci_udc.c +++ b/drivers/usb/gadget/ci_udc.c @@ -703,8 +703,8 @@ static void handle_setup(void) list_del_init(&ci_req->queue); ci_ep->req_primed = false; - switch (SETUP(r.bRequestType, r.bRequest)) { - case SETUP(USB_RECIP_ENDPOINT, USB_REQ_CLEAR_FEATURE): + switch (r.bRequest) { + case USB_REQ_CLEAR_FEATURE: _num = r.wIndex & 15; _in = !!(r.wIndex & 0x80); @@ -729,7 +729,7 @@ static void handle_setup(void) } return; - case SETUP(USB_RECIP_DEVICE, USB_REQ_SET_ADDRESS): + case USB_REQ_SET_ADDRESS: /* * write address delayed (will take effect * after the next IN txn) @@ -739,7 +739,7 @@ static void handle_setup(void) usb_ep_queue(controller.gadget.ep0, req, 0); return; - case SETUP(USB_DIR_IN | USB_RECIP_DEVICE, USB_REQ_GET_STATUS): + case USB_REQ_GET_STATUS: req->length = 2; buf = (char *)req->buf; buf[0] = 1 << USB_DEVICE_SELF_POWERED; -- 2.9.3

3 8