u-boot.git/board, branch v2022.10

board: ti: common: board_detect: Fix EEPROM read quirk for AM6 style data

2022-09-29T14:10:39Z

The situation is similar to commit bf6376642fe8 ("board: ti: common: board_detect: Fix EEPROM read quirk"). This is seen on a variant of eeproms seen on some BeagleBone-AI64 which now has a mix of both 1 byte addressing and 2 byte addressing eeproms. Unlike the am335x (ti_i2c_eeprom_am_get) and dra7 (ti_i2c_eeprom_dra7_get) which use constant data structure which allows us to do a complete read of the data, the am6(ti_i2c_eeprom_am6_get) eeprom parse operation is dynamic. This removes the option of being able to read the complete eeprom data in one single shot. Fortunately, on the I2C bus, we do see the following behavior: In 1 byte mode, if we attempt to read the first header data yet again, the misbehaving 2 byte addressing device acts in constant addressing mode which results in the header not matching up and follow on attempt at 2 byte addressing scheme grabs the correct data. This costs us an extra ~3 milliseconds, which is a minor penalty compared to the consistent image support we need to have. Reported-by: Jason Kridner Fixes: a58147c2dbbf ("board: ti: common: board_detect: Do 1byte address checks first.") Signed-off-by: Nishanth Menon

vexpress64: also consider DTB pointer in x1

2022-09-29T14:10:39Z

Commit c0fce929564f("vexpress64: fvp: enable OF_CONTROL") added code to consider a potential DTB address being passed in the x0 register, or revert to the built-in DTB otherwise. The former case was used when using the boot-wrapper, to which we sell U-Boot as a Linux kernel. The latter was meant for TF-A, for which we couldn't find an easy way to use the DTB it uses itself. We have some quirk to filter for a valid DTB, as TF-A happens to pass a pointer to some special devicetree blob in x0 as well. Now the TF-A case is broken, when enabling proper emulation of secure memory (-C bp.secure_memory=1). TF-A carves out some memory at the top of the first DRAM bank for its own purposes, and configures the TrustZone DRAM controller to make this region secure-only. U-Boot will then hang when it tries to relocate itself exactly to the end of DRAM. TF-A announces this by carving out that region of the /memory node, in the DT it passes on to BL33 in x1, but we miss that so far. Instead of repeating this carveout in our DT copy, let's try to look for a DTB at the address x1 points to as well. This will let U-Boot pick up the DTB provided by TF-A, which has the correct carveout in place, avoiding the hang. While we are at it, make the detection more robust: the length test (is the DT larger than 256 bytes?) is too fragile, in fact the TF-A port for a new FVP model already exceeds this. So we test x1 first, consider 0 an invalid address, and also require a /memory node to detect a valid DTB. And for the records: Some asking around revealed what is really going on with TF-A and that ominous DTB pointer in x0: TF-A expects EDK-2 as its non-secure payload (BL33), and there apparently was some long-standing ad-hoc boot protocol defined just between the two: x0 would carry the MPIDR register value of the boot CPU, and the hardware DTB address would be stored in x1. Now the MPIDR of CPU 0 is typically 0, plus bit 31 set, which is defined as RES1 in the ARMv7 and ARMv8 architectures. This gives 0x80000000, which is the same value as the address of the beginning of DRAM (2GB). And coincidentally TF-A put some DTB structure exactly there, for its own purposes (passing it between stages). So U-Boot was trying to use this DTB, which requires the quirk to check for its validity. Signed-off-by: Andre Przywara Tested-by: Peter Hoyes

ARM: imx: Deduplicate i.MX8M SNVS LPGPR unlock

2022-09-20T16:30:02Z

Pull this LPGPR unlock into common code, since it is used in multiple systems already. Signed-off-by: Marek Vasut

Merge tag 'u-boot-imx-20220919' of https://gitlab.denx.de/u-boot/custodians/u-boot-imx

2022-09-19T12:38:32Z

u-boot-imx-20220919 ------------------- CI: https://source.denx.de/u-boot/custodians/u-boot-imx/-/pipelines/13500 - Fix imx8mn-beacon-kit-u-boot - Merged Purism - imxrt1170 (already merged in u-boot-imx) - Fixes in crypto FSL - Toradex : fixes Verdin - Serial Driver: fixes when not used as console - DH Boards : fixes + USB - Fix CONFIG_SYS_MALLOC_F_LEN (Kconfig) - Add imx6ulz_smm_m2

bsh: imx6ulz_smm_m2: Add imx6ulz BSH SMM M2 boards

2022-09-18T20:56:18Z

Introduce BSH SystemMaster (SMM) M2 board family, which consists of: imx6ulz SMM M2 and imx6ulz SMM M2 PRO boards. Add support for imx6ulz BSH SMM M2 board: - 128 MiB DDR3 RAM - 256MiB Nand - USBOTG1 peripheral - fastboot. Signed-off-by: Michael Trimarchi Reviewed-by: Fabio Estevam

ARM: imx: Update Data Modul i.MX8M Mini eDM SBC DRAM timing

2022-09-18T20:56:10Z

Adjust the DRAM timing settings for this board per ones provided by hardware department. The change is applied to the LPDDR4 MR11 register CA ODT configuration, from RZQ/6 to RZQ/3, which fixes stability issues on subset of boards. The DDR PHY PIE block has been updated accordingly. Signed-off-by: Marek Vasut Cc: Fabio Estevam Cc: Peng Fan Cc: Stefano Babic Reviewed-by: Fabio Estevam

board: purism: add the Purism Librem5 phone

2022-09-18T20:56:10Z

Initial commit of Librem5 u-boot and SPL Signed-off-by: Angus Ainslie Co-developed-by: Sebastian Krzyszkowiak Signed-off-by: Sebastian Krzyszkowiak Reviewed-by: Fabio Estevam

verdin-imx8mp: do not save environment when it's nowhere

2022-09-18T20:56:10Z

This code part is broken, remove it. Signed-off-by: Andrejs Cainikovs Signed-off-by: Denys Drozdov

verdin-imx8mm: do not save environment when it's nowhere

2022-09-18T20:56:10Z

This code part is broken, remove it. Signed-off-by: Andrejs Cainikovs Signed-off-by: Denys Drozdov

verdin-imx8mm: improve and extend boot devices

2022-09-18T20:56:10Z

- Annotate boot devices available in spl_board_boot_device(). - Drop SD3_BOOT/MMC3_BOOT not available for boot on Verdin iMX8M Mini. Signed-off-by: Marcel Ziswiler