December 2018 - U-Boot

[U-Boot] [PATCH] MAINTAINERS: update NXP i.MX mail list address
by Peng Fan 15 Dec '18

15 Dec '18

Update NXP i.MX mail list address Signed-off-by: Peng Fan <peng.fan(a)nxp.com> --- MAINTAINERS | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/MAINTAINERS b/MAINTAINERS index 0cec39c542..fe2a1c9db5 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -123,7 +123,7 @@ F: drivers/spi/bcmstb_spi.c ARM FREESCALE IMX M: Stefano Babic <sbabic(a)denx.de> M: Fabio Estevam <fabio.estevam(a)nxp.com> -R: NXP Linux Team <linux-imx(a)nxp.com> +R: NXP Linux Team <uboot-imx(a)nxp.com> S: Maintained T: git git://git.denx.de/u-boot-imx.git F: arch/arm/cpu/arm1136/mx*/ -- 2.14.1

3 2

[U-Boot] [PATCH v3 0/2] SiFive UART support
by Anup Patel 15 Dec '18

15 Dec '18

This patchset adds SiFive UART driver for SiFive UART found on SiFive boards. The driver is tested on QEMU sifive_u machine. In fact, with this patchset same U-Boot binary boots on QEMU virt machine and QEMU sifive_u machine in both M-mode and S-mode. The patches are based upon latest RISC-V UBoot tree (git://git.denx.de/u-boot-riscv.git) at commit id 48cbf6246052de10d35b616b5efb2f783904a49d Changes since v2: - Added pending() callback implementation for tstc() console API to work correctly. Changes since v1: - Fixed copyright header in SiFive UART driver - Imply SIFIVE_SERIAL for QEMU emulation instead of enabling it in defconfigs. Anup Patel (2): drivers: serial: Add SiFive UART driver riscv: qemu: Imply SIFIVE_SERIAL for emulation board/emulation/qemu-riscv/Kconfig | 1 + drivers/serial/Kconfig | 13 ++ drivers/serial/Makefile | 1 + drivers/serial/serial_sifive.c | 215 +++++++++++++++++++++++++++++ 4 files changed, 230 insertions(+) create mode 100644 drivers/serial/serial_sifive.c -- 2.17.1

1 2

[U-Boot] Quick question on i.MX8MQ
by Sergey Kubushyn 15 Dec '18

15 Dec '18

I'm working on a i.MX8MQ port to our new device that is in very advanced manufacturing stage. It is not a board but a self-contained terminal that is going into production really soon (various molds are being done, mechanical parts, wire harnesses and so on) so it would hardly be of general interest i.e. I might submit some patches but not a new board. I have one question right now for those involved and maintaning IMX tree. What platform name is more likely to win, MX8M as in the main source tree right now or IMX8M as in u-boot-imx.git? It doesn't make a real difference but I would like to pick the more probable one for my port so I won't have to add/remove that 'I' in a hundred different files when u-boot-imx is merged into main tree. I can use either one but would like to avoid that possible unnecessary job later on when re-syncing with the main tree. --- ****************************************************************** * KSI@home KOI8 Net < > The impossible we do immediately. * * Las Vegas NV, USA < > Miracles require 24-hour notice. * ******************************************************************

2 1

[U-Boot] [PATCH V2 01/15] Introduce CONFIG_FIT_EXTERNAL_OFFSET
by Peng Fan 15 Dec '18

15 Dec '18

Introduce CONFIG_FIT_EXTERNAL_OFFSET to give user a choice to choose where to put the external data. Signed-off-by: Peng Fan <peng.fan(a)nxp.com> --- V2: Add more help information Kconfig | 10 ++++++++++ Makefile | 2 +- 2 files changed, 11 insertions(+), 1 deletion(-) diff --git a/Kconfig b/Kconfig index dca9bb4e43..f74d662358 100644 --- a/Kconfig +++ b/Kconfig @@ -248,6 +248,16 @@ config FIT if FIT +config FIT_EXTERNAL_OFFSET + hex "Text Base" + default 0x0 + help + This specifies a data offset in fit image. + The offset is from data payload offset to the beginning of + fit image header. When specifies a offset, specific data + could be put in the hole between data payload and fit image + header, such as CSF data on i.MX platform. + config FIT_ENABLE_SHA256_SUPPORT bool "Support SHA256 checksum of FIT image contents" default y diff --git a/Makefile b/Makefile index 552687db53..ee97601ec3 100644 --- a/Makefile +++ b/Makefile @@ -893,7 +893,7 @@ cmd_mkimage = $(objtree)/tools/mkimage $(MKIMAGEFLAGS_$(@F)) -d $< $@ \ >$(MKIMAGEOUTPUT) $(if $(KBUILD_VERBOSE:0=), && cat $(MKIMAGEOUTPUT)) quiet_cmd_mkfitimage = MKIMAGE $@ -cmd_mkfitimage = $(objtree)/tools/mkimage $(MKIMAGEFLAGS_$(@F)) -f $(U_BOOT_ITS) -E $@ \ +cmd_mkfitimage = $(objtree)/tools/mkimage $(MKIMAGEFLAGS_$(@F)) -f $(U_BOOT_ITS) -E $@ -p $(CONFIG_FIT_EXTERNAL_OFFSET)\ >$(MKIMAGEOUTPUT) $(if $(KBUILD_VERBOSE:0=), && cat $(MKIMAGEOUTPUT)) quiet_cmd_cat = CAT $@ -- 2.14.1

6 27

[U-Boot] [PATCH] ARM: mach-omap2: omap3: Fix GPIO clocking in SPL
by Adam Ford 15 Dec '18

15 Dec '18

OMAP3_GPIO_x is needed to enable each GPIO bank on the OMAP3 boards. At one point, the #ifdef's were replaced with if CONFIG_IS_ENABLED but this won't work for people who need OMAP3_GPIO_x in SPL since the SPL prefix for this option isn't used in Kconfig. This patch moves the check to #if defined and also makes Kconfig select the banks if CMD_GPIO is used which makes the checks in the code less cumbersome. Fixes: bd8a9c14c91c ("arm: mach-omap2/omap3/clock.c: Enable all GPIO with CMD_GPIO") Reported-by: Liam O'Shaughnessy <liam.o.shaughnessy(a)gumstix.com> Signed-off-by: Adam Ford <aford173(a)gmail.com> diff --git a/arch/arm/mach-omap2/omap3/Kconfig b/arch/arm/mach-omap2/omap3/Kconfig index e0d02fb4e5..0286b0daa3 100644 --- a/arch/arm/mach-omap2/omap3/Kconfig +++ b/arch/arm/mach-omap2/omap3/Kconfig @@ -3,18 +3,23 @@ if OMAP34XX # We only enable the clocks for the GPIO banks that a given board requies. config OMAP3_GPIO_2 bool + default y if CMD_GPIO config OMAP3_GPIO_3 bool + default y if CMD_GPIO config OMAP3_GPIO_4 bool + default y if CMD_GPIO config OMAP3_GPIO_5 bool + default y if CMD_GPIO config OMAP3_GPIO_6 bool + default y if CMD_GPIO choice prompt "OMAP3 board select" diff --git a/arch/arm/mach-omap2/omap3/clock.c b/arch/arm/mach-omap2/omap3/clock.c index 9a03bfa9d3..817fbb3383 100644 --- a/arch/arm/mach-omap2/omap3/clock.c +++ b/arch/arm/mach-omap2/omap3/clock.c @@ -750,23 +750,23 @@ void per_clocks_enable(void) setbits_le32(&prcm_base->iclken_per, 0x00000800); #endif -#if (CONFIG_IS_ENABLED(OMAP3_GPIO_2) || CONFIG_IS_ENABLED(CMD_GPIO)) +#if defined(OMAP3_GPIO_2) setbits_le32(&prcm_base->fclken_per, 0x00002000); setbits_le32(&prcm_base->iclken_per, 0x00002000); #endif -#if (CONFIG_IS_ENABLED(OMAP3_GPIO_3) || CONFIG_IS_ENABLED(CMD_GPIO)) +#if defined(OMAP3_GPIO_3) setbits_le32(&prcm_base->fclken_per, 0x00004000); setbits_le32(&prcm_base->iclken_per, 0x00004000); #endif -#if (CONFIG_IS_ENABLED(OMAP3_GPIO_4) || CONFIG_IS_ENABLED(CMD_GPIO)) +#if defined(OMAP3_GPIO_4) setbits_le32(&prcm_base->fclken_per, 0x00008000); setbits_le32(&prcm_base->iclken_per, 0x00008000); #endif -#if (CONFIG_IS_ENABLED(OMAP3_GPIO_5) || CONFIG_IS_ENABLED(CMD_GPIO)) +#if defined(OMAP3_GPIO_5) setbits_le32(&prcm_base->fclken_per, 0x00010000); setbits_le32(&prcm_base->iclken_per, 0x00010000); #endif -#if (CONFIG_IS_ENABLED(OMAP3_GPIO_6) || CONFIG_IS_ENABLED(CMD_GPIO)) +#if defined(OMAP3_GPIO_6) setbits_le32(&prcm_base->fclken_per, 0x00020000); setbits_le32(&prcm_base->iclken_per, 0x00020000); #endif -- 2.17.1

2 3

[U-Boot] SPL boot on linaro qemu
by Matthew Weber 14 Dec '18

14 Dec '18

Does anyone happen to know why I'd see the following output when trying to boot the latest uboot configs/omap3_overo_defconfig target's SPL in a SD image on linaro's qemu? U-Boot SPL 2018.09 (Dec 14 2018 - 15:15:38 -0600) SPL: failed to boot from all boot devices After manually setting the boot device to have MMC1 and 2 in the list I see the following which feels like something in the board init isn't getting set. U-Boot SPL 2018.09 (Dec 14 2018 - 15:15:38 -0600) Trying to boot from MMC1 MMC Device 0 not found spl: could not find mmc device. error: -19 Trying to boot from MMC2 MMC Device 1 not found spl: could not find mmc device. error: -19 SPL: failed to boot from all boot devices I went back to some really old MLO and uboot from Gumstick and packaged them up with my script. I was able to boot that SD image, so I know the SD make script and QEMU work. QEMU launch qemu-system-arm -M overo -drive file=sd.img,if=sd -serial stdio mk img script https://wiki.gumstix.com/index.php/Overo_qemu_script Any tips would be much appreciated! -- *Matthew Weber | Pr. Software Engineer | Commercial Avionics* *COLLINS AEROSPACE* 400 Collins Road NE, Cedar Rapids, Iowa 52498, USA *Tel:* +1 319 295 7349 | *FAX:* +1 319 263 6099 *matthew.weber(a)collins.com <matthew.weber(a)collins.com>* | *collinsaerospace.com <http://collinsaerospace.com>* CONFIDENTIALITY WARNING: This message may contain proprietary and/or privileged information of Collins Aerospace and its affiliated companies. If you are not the intended recipient, please 1) Do not disclose, copy, distribute or use this message or its contents. 2) Advise the sender by return email. 3) Delete all copies (including all attachments) from your computer. Your cooperation is greatly appreciated.

1 0

[U-Boot] [PATCH 1/1] tests: enable DT overlay tests by default
by Heinrich Schuchardt 14 Dec '18

14 Dec '18

Enable device tree overlay tests by default if unit tests are selected. Overlays have been mainlined in the device tree compiler so there is no reason anymore to disable the tests by default. Signed-off-by: Heinrich Schuchardt <xypron.glpk(a)gmx.de> --- test/overlay/Kconfig | 5 ++--- 1 file changed, 2 insertions(+), 3 deletions(-) diff --git a/test/overlay/Kconfig b/test/overlay/Kconfig index 13c85428cba..f39966623dc 100644 --- a/test/overlay/Kconfig +++ b/test/overlay/Kconfig @@ -1,11 +1,10 @@ config UT_OVERLAY bool "Enable Device Tree Overlays Unit Tests" - depends on OF_LIBFDT_OVERLAY depends on UNIT_TEST + default y + select OF_LIBFDT_OVERLAY help This enables the 'ut overlay' command which runs a series of unit tests on the fdt overlay code. If all is well then all tests pass although there will be a few messages printed along the way. - Be warned that it requires an out-of-tree dtc compiler with patches - to support the DT overlays, otherwise it will fail. -- 2.19.2

1 0

[U-Boot] [PATCH v2 0/2] Update RV3029 driver to DM and add DM-backed bootcount support
by Philipp Tomsich 14 Dec '18

14 Dec '18

On one of our application-specific carrier boards, a MicroCrystal RV3029 acts as an off-module battery-backed RTC for the RK3399-Q7. The RV3029 is intended both to provide RTC services (to Linux) and to store the bootcount in its battery-backed SRAM section. To support this use-case, this series adds the following: * replaces the existing RV3029 driver by a DM-based one (note that the existing driver appears unused and didn't even have a Kconfig entry) that closely mirrors its incarnation in Linux 4.17 * adds a bootcount-method interfacing back into DM devices (implementing support for the RTC uclass as of now). Changes in v2: - changed to provide a UCLASS-based implementation, as requested by SJG in his earlier review - split off the RV3029 driver into a separate series Philipp Tomsich (2): bootcount: add uclass for bootcount bootcount: add a DM RTC backing store for bootcount doc/device-tree-bindings/chosen.txt | 30 ++++++++++++ drivers/bootcount/Kconfig | 28 +++++++++++ drivers/bootcount/Makefile | 3 ++ drivers/bootcount/bootcount-uclass.c | 93 ++++++++++++++++++++++++++++++++++++ drivers/bootcount/rtc.c | 89 ++++++++++++++++++++++++++++++++++ include/bootcount.h | 48 +++++++++++++++++++ include/dm/uclass-id.h | 1 + 7 files changed, 292 insertions(+) create mode 100644 drivers/bootcount/bootcount-uclass.c create mode 100644 drivers/bootcount/rtc.c -- 2.1.4

3 11

[U-Boot] U-Boot test failures; rebase on master
by Stephen Warren 14 Dec '18

14 Dec '18

The following U-Boot repos have recently rebased on u-boot.git master branch, and picked up some changes that cause test failures on one/both of NVIDIA Jetson TX2 and sandbox. That potentially prevents any testing from finding any additional issues that are introduced in these repos. If you rebase on the latest u-boot.git master branch you'll pick up fixes that solve these failures, and make all of test/py pass on all the boards I test... u-boot-usb.git master u-boot-video.git master u-boot-dfu.git master u-boot-spi.git master Thanks!

3 2

[U-Boot] changing of fastboot index
by Sam Protsenko 14 Dec '18

14 Dec '18

Hi Jean-Jacques, After commit aec0081093e7 ("configs: am57xx_evm: Enable DM_USB and DM_USB_DEV") I noticed that "fastboot 1" command doesn't work anymore on BeagleBoard X15. Instead, "fastboot 0" works. I can see that this happens because in dwc3_glue_bind() we only register usb@488d0000 as OTG controller ("dwc3-generic-peripheral"), and usb@48890000 is registered as HOST controller ("xhci-dwc3"). This leads for dwc3_glue_probe() to be only called once (for OTG controller), so now we only have registered controller with index = 0, when we are calling usb_gadget_initialize() from do_fastboot_usb(). The reason why I'm bringing this up is that we still have CONFIG_FASTBOOT_USB_DEV=1 for AM57x-based boards, and "fastboot reboot-bootloader" won't work, and all documentation needs to be changed. In "help fastboot" output it only says that <controller> must be passed. Do we actually understand which controller is referred here? Frankly, I never thought about this before. Is it OTG controller number, or USB controller number? As I understand it, it should be USB controller index, so on X15 it actually should be "fastboot 1". But I can be mistaken :) Is this an intended behavior or should we fix it? If so, can you please help me here? Thanks!

2 1