March 2019 - U-Boot

[U-Boot] [PATCH] rockchip: arm: remove no use macro
by Kever Yang 28 Mar '19

28 Mar '19

Signed-off-by: Kever Yang <kever.yang(a)rock-chips.com> --- arch/arm/include/asm/arch-rockchip/hardware.h | 2 -- 1 file changed, 2 deletions(-) diff --git a/arch/arm/include/asm/arch-rockchip/hardware.h b/arch/arm/include/asm/arch-rockchip/hardware.h index cd94bdd1ba..62e8bed8f3 100644 --- a/arch/arm/include/asm/arch-rockchip/hardware.h +++ b/arch/arm/include/asm/arch-rockchip/hardware.h @@ -10,8 +10,6 @@ #define RK_SETBITS(set) RK_CLRSETBITS(0, set) #define RK_CLRBITS(clr) RK_CLRSETBITS(clr, 0) -#define TIMER7_BASE 0xff810020 - #define rk_clrsetreg(addr, clr, set) \ writel(((clr) | (set)) << 16 | (set), addr) #define rk_clrreg(addr, clr) writel((clr) << 16, addr) -- 2.20.1

2 1

[U-Boot] [PATCH 0/3] ARM: meson: Add G12A USB Support
by Neil Armstrong 28 Mar '19

28 Mar '19

This patchset adds support for USB on Amlogic G12A SoCs. This patchset is composed with : - PHY Drivers - USB Control Glue driver - G12A board setup for Device mode Device Tree nodes will be added in a separate patchset when applied on a tagged Linux tree. The Amlogic G12A USB Complex is composed of : - 2 USB Controllers : * DWC3 for USB2 and USB3 Host functionality * DWC2 for USB2 Peripheral functionality - 2 USB2 OTG PHYs, only a single one will be routed to either DWC2 to DWC3 - 1 USB3 PHY shared with PCIE funcionnality - A Glue to control PHY routing, setup and OTG detection The Glue configures the UTMI 8bit interfaces for the USB2 PHYs, including routing of the OTG PHY between the DWC3 and DWC2 controllers, and setups the on-chip OTG mode selection for this PHY. This drivers supports the on-probe setup of the OTG mode, and manually via a setup function in the G12A common board code. Neil Armstrong (3): usb: dwc3: Add Meson G12A USB Glue phy: meson: add Amlogic G12A USB2 and USB3+PCIE PHY drivers mach-meson: g12a: add DWC2 peripheral mode support arch/arm/include/asm/arch-meson/usb.h | 12 + arch/arm/mach-meson/board-g12a.c | 126 +++++++ drivers/phy/Kconfig | 8 + drivers/phy/Makefile | 1 + drivers/phy/meson-g12a-usb2.c | 216 ++++++++++++ drivers/phy/meson-g12a-usb3-pcie.c | 345 +++++++++++++++++++ drivers/usb/dwc3/Kconfig | 8 + drivers/usb/dwc3/Makefile | 1 + drivers/usb/dwc3/dwc3-meson-g12a.c | 456 ++++++++++++++++++++++++++ 9 files changed, 1173 insertions(+) create mode 100644 arch/arm/include/asm/arch-meson/usb.h create mode 100644 drivers/phy/meson-g12a-usb2.c create mode 100644 drivers/phy/meson-g12a-usb3-pcie.c create mode 100644 drivers/usb/dwc3/dwc3-meson-g12a.c -- 2.21.0

2 6

[U-Boot] Questions/RFC about overlay compatible strings and device tree compression in uImage.FIT
by Julius Werner 28 Mar '19

28 Mar '19

Hi U-Boot developers, (I picked a few of you out that seem to be most related to this code, hope that's okay,) I am interested in booting device trees with overlays from a FIT image (actually for a different bootloader, but we're trying to stay compatible with U-Boot's FIT format so I'm asking here), and I came up with some questions about how this is supposed to work that I hope you can answer: I found the basic description of overlay support in FIT here: https://github.com/u-boot/u-boot/blob/master/doc/uImage.FIT/overlay-fdt-boo… However, what it doesn't really say is how compatible string matching works in the face of overlays. From my reading of the code it seems that U-Boot tries to match the compatible string in the FDT that is listed leftmost in the 'fdt' property of the config node (fit_conf_find_compat() just calls fdt_getprop(fit, "fdt") and uses the result as a string, so since the different FDT names in the property are separated by '\0' chars I assume that will act on the first name?), which according to the documentation should be the base device tree. Is that correct? I don't see how that would make sense... for overlays to make sense you would want to have multiple config nodes that all use the same base device tree and stack different overlays on top of it (the example in the docs also looks that way). But if the compatible string matcher only checks the base device tree, all of those config nodes will have the same strings to match -- how could it find the right node? I think the correct scheme would be to scan through all overlays from right to left (i.e. in reverse application order) until you find a compatible string somewhere. Was the current overlay support just only implemented with pre-selected config nodes (i.e. passing a fit_uname_configp to boot_get_fdt_fit()) in mind? On a somewhat related note, I was also thinking about allowing compression for the 'data' property of individual fdt@X nodes (similar to how you can already do it for kernel@X nodes), which can cut them down to about 15% of their size with LZ4 or even 5% with LZMA. The main problem with this is that you would have to decompress all device trees during the compatible string match to get at their embedded compatible strings. An obvious solution would be to copy the compatible string out into an explicit property in the config node at build time, so that the 'fdt' property (and the node it points to) doesn't have to be parsed before you're actually loading the full DT (and at that time you could decompress only the one(s) you're using). This would also help the compatible string problem with overlays, since then the config node has the compatible string right there and you don't need to worry about which overlay to extract it from anymore. Would it be an acceptable change if I added support for that to U-Boot? Of course, the code could gracefully fall back to scanning the whole FDT (decompressing if necessary) if the config node has no 'compatible' property. Please let me know what you think! Thanks, Julius

1 0

[U-Boot] [PATCH] pico-imx7d: README: Recommend the usage of a USB hub
by Fabio Estevam 28 Mar '19

28 Mar '19

Since commit 9e3c0174da842 ("pico-imx7d: Add LCD support") we started to notice some hangs in U-Boot. There is not an issue on such commit per se, but due to the LCD support the current drawn is increased and this may cause issues when powering pico-imx7d-pi from USB. Some computers may be a bit strict with USB current draw and will shut down their ports if the draw is too high. The solution for that is to use an externally powered USB hub between the board and the host computer. Add such recommendation to the README file. Signed-off-by: Fabio Estevam <festevam(a)gmail.com> --- board/technexion/pico-imx7d/README | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/board/technexion/pico-imx7d/README b/board/technexion/pico-imx7d/README index 24eb97e82c..f21d8301cb 100644 --- a/board/technexion/pico-imx7d/README +++ b/board/technexion/pico-imx7d/README @@ -26,6 +26,10 @@ Connect a USB to serial adapter between the host PC and pico. Connect a USB cable between the OTG pico port and the host PC. +Note: Some computers may be a bit strict with USB current draw and will +shut down their ports if the draw is too high. The solution for that is +to use an externally powered USB hub between the board and the host computer. + Open a terminal program such as minicom. Copy SPL and u-boot.img to the imx_usb_loader folder. -- 2.17.1

1 0

[U-Boot] 'U-Boot parlella board support'
by Terrance Chiang 27 Mar '19

27 Mar '19

Greetings Martin, I'm not sure if I'm related to it. But looking at the geo location. I have a discovered a new Russia GMT settings in my router as default this morning, which is different from my location. I'm not sure when this was applied. Have not been applying or changing scripts for a few days due to trying to resolve, my android phone mobile had some weird changes, Router keeps resetting or unable to connect properly, DHCP issues, some PPC drivers unable to update after clean install with a default disc, e.g. nvidia, intel, sam internal 512GBssd, forced MS updates related to arm64 device and no permissions to uninstall it, some drivers without doing anything have e.g. class, parent, child, nodes attached and lastly, some policy notifications from few vendors. Updated my bios clock according to my country because it is reflecting a different time. Is there any way that I could provide information that it's related? Or should I abandon project and dispose device since it's my first failed attempt. Any advise would be appreciated. Alexander Dahl, Rick Chen, Troy Benjegerdes, Lukas Auer, Atish Patra, Oskari Lemmela, Paul Kocialkowski, Takahiro Akashi, Eugen Hristev and many rest of the U-Boot administrators has been very helpful with my issues and deeply appreciated it. Thank you. Thanks and best regards Bin meng

1 0

[U-Boot] [PATCH v4 0/1] efi_loader: support BootNext and BootCurrent
by AKASHI Takahiro 27 Mar '19

27 Mar '19

This patch was originally posted as a single one, but then was merged in my "run -e." Now I would like to post it on its own. With this patch, EFI Boot Manager will handles BootNext and BootCurrent variable as UEFI specification describes. Changes in v4 (Mar 20, 2019) * strictly check the size of BootNext Changes in v3 (Mar 8, 2019) * add error messages around BootNext * delete BootNext anyway when processing BootOrder Changes in v2 (Mar 5, 2019) * extract this patch from my "run -e" patch set * use efi_[get|set]_variable instead of 'rs->*' * add EFI_CALL * cosmetic changes AKASHI Takahiro (1): efi_loader: bootmgr: support BootNext and BootCurrent variable behavior lib/efi_loader/efi_bootmgr.c | 51 +++++++++++++++++++++++++++++++++--- 1 file changed, 47 insertions(+), 4 deletions(-) -- 2.20.1

2 4

[U-Boot] [PATCH 1/1] efi_loader: TODO for the EFI file protocol
by Heinrich Schuchardt 27 Mar '19

27 Mar '19

We currently only support EFI_FILE_PROTOCOL_REVISION while UEFI specs 2.4 - 2.7 prescribe EFI_FILE_PROTOCOL_REVISION2. Add a todo. Add missing constants for the EFI file protocol revision. Signed-off-by: Heinrich Schuchardt <xypron.glpk(a)gmx.de> --- doc/README.uefi | 3 +++ include/efi_api.h | 8 +++++++- lib/efi_loader/efi_file.c | 4 ++++ 3 files changed, 14 insertions(+), 1 deletion(-) diff --git a/doc/README.uefi b/doc/README.uefi index 0982fad92e..cda29cdcf7 100644 --- a/doc/README.uefi +++ b/doc/README.uefi @@ -329,6 +329,9 @@ This driver is only available if U-Boot is configured with * persistence * runtime support +* incompletely implemented protocols + * support version 0x00020000 of the EFI file protocol + ## Links * [1](http://uefi.org/specifications) diff --git a/include/efi_api.h b/include/efi_api.h index 63b703c951..407acacc81 100644 --- a/include/efi_api.h +++ b/include/efi_api.h @@ -1326,7 +1326,9 @@ struct efi_pxe { #define EFI_SIMPLE_FILE_SYSTEM_PROTOCOL_GUID \ EFI_GUID(0x964e5b22, 0x6459, 0x11d2, \ 0x8e, 0x39, 0x0, 0xa0, 0xc9, 0x69, 0x72, 0x3b) -#define EFI_FILE_PROTOCOL_REVISION 0x00010000 +#define EFI_FILE_PROTOCOL_REVISION 0x00010000 +#define EFI_FILE_PROTOCOL_REVISION2 0x00020000 +#define EFI_FILE_PROTOCOL_LATEST_REVISION EFI_FILE_PROTOCOL_REVISION2 struct efi_file_handle { u64 rev; @@ -1350,6 +1352,10 @@ struct efi_file_handle { const efi_guid_t *info_type, efi_uintn_t buffer_size, void *buffer); efi_status_t (EFIAPI *flush)(struct efi_file_handle *file); + /* + * TODO: We currently only support EFI file protocol revision 0x00010000 + * while UEFI specs 2.4 - 2.7 prescribe revision 0x00020000. + */ }; #define EFI_SIMPLE_FILE_SYSTEM_PROTOCOL_REVISION 0x00010000 diff --git a/lib/efi_loader/efi_file.c b/lib/efi_loader/efi_file.c index bc715218a1..f2843cad2d 100644 --- a/lib/efi_loader/efi_file.c +++ b/lib/efi_loader/efi_file.c @@ -628,6 +628,10 @@ static efi_status_t EFIAPI efi_file_flush(struct efi_file_handle *file) } static const struct efi_file_handle efi_file_handle_protocol = { + /* + * TODO: We currently only support EFI file protocol revision 0x00010000 + * while UEFI specs 2.4 - 2.7 prescribe revision 0x00020000. + */ .rev = EFI_FILE_PROTOCOL_REVISION, .open = efi_file_open, .close = efi_file_close, -- 2.20.1

1 0

[U-Boot] X850 V1.3 hat for Raspberry Pi 3 is not working with u-boot
by Guillaume GARDET 27 Mar '19

27 Mar '19

Hi, I am trying to use a X850 V1.3 hat (USB/mSATA) for Raspberry Pi 3: http://www.raspberrypiwiki.com/index.php/X850#Installation_Guide_For_X850_V… It works to load firmware (most of the time), but it fails in u-boot with: starting USB... USB0: scanning bus 0 for devices... usb_new_device: Cannot read configuration, skipping device 152d:0578 or just fails to find it (after a long timeout): USB0: scanning bus 0 for devices... 4 USB Device(s) found scanning usb for storage devices... 0 Storage Device(s) found Only once I got it detected: starting USB... USB0: scanning bus 0 for devices... 4 USB Device(s) found scanning usb for storage devices... 1 Storage Device(s) found Hit any key to stop autoboot: 0 (snip) Device 0: Vendor: JMicron Rev: 0204 Prod: Generic Type: Hard Disk Capacity: 238475.1 MB = 232.8 GB (488397168 x 512) ... is now current device But then, the loaded EFI payload seems to be corrupted (bad read?). Please note it is working fine when connected to a Linux PC host, without external 5V. Cheers, Guillaume

1 0

[U-Boot] [PATCH 0/5] pico-imx7d: Add support for BL33 case
by Jun Nie 27 Mar '19

27 Mar '19

Add configuration to boot U-boot as BL33 case. The boot flow is ATF -> OPTEE -> U-boot. Jun Nie (5): mx7_common: Share configs to skip low level init imx: mx7: Add empty arch_cpu_init if skipped pico-imx7d: Reserve region of memory to OPTEE pico-imx7d: Add boot option for verified boot pico-imx7d: Add bl33 config arch/arm/mach-imx/mx7/soc.c | 2 + board/technexion/pico-imx7d/imximage-512MB.cfg | 95 ++++++++++++++++++++++++++ board/technexion/pico-imx7d/pico-imx7d.c | 5 ++ configs/pico-pi-imx7d_bl33_defconfig | 62 +++++++++++++++++ include/configs/mx7_common.h | 11 +++ include/configs/pico-imx7d.h | 38 ++++++++++- include/configs/warp7.h | 11 --- 7 files changed, 210 insertions(+), 14 deletions(-) create mode 100644 board/technexion/pico-imx7d/imximage-512MB.cfg create mode 100644 configs/pico-pi-imx7d_bl33_defconfig -- 2.7.4

3 18

[U-Boot] [SoCFPGA] co-custodianship
by Marek Vasut 27 Mar '19

27 Mar '19

Hi, I would like to nominate Simon Goldschmidt as a co-custodian for the SoCFPGA platform to help me review patches and collect them into PRs. Any objections ? Thanks -- Best regards, Marek Vasut

4 3