summaryrefslogtreecommitdiff
path: root/arch
AgeCommit message (Collapse)AuthorFilesLines
2021-07-16stm32mp: configs: activate the command stm32key only for ST boardsPatrick Delaunay1-1/+3
This command is used to evaluate the secure boot on stm32mp SOC, it is deactivated by default in real products. We activate this command only in STMicroelectronics defconfig used with the evaluation boards. Signed-off-by: Patrick Delaunay <patrick.delaunay@foss.st.com> Reviewed-by: Patrice Chotard <patrice.chotard@foss.st.com>
2021-07-16stm32mp: stm32prog: fix the content of short help messagePatrick Delaunay1-5/+5
Reduce the content of short help message for stm32prog command and removed the carriage return to fix the display of 'help' command when this command is activated. Fixes: 954bd1a923a6 ("stm32mp: add the command stm32prog") Signed-off-by: Patrick Delaunay <patrick.delaunay@foss.st.com>
2021-07-16sandbox: Silence coverity warning in state_read_file()Simon Glass1-0/+4
In this case the value seems save to pass to os_free(). Add a comment. Signed-off-by: Simon Glass <sjg@chromium.org> Reported-by: Coverity (CID: 165109)
2021-07-15Merge https://source.denx.de/u-boot/custodians/u-boot-x86Tom Rini8-16/+46
- x86: various improvements made in getting Chromium OS verified boot running on top of coreboot, booting into U-Boot.
2021-07-15arm/dts: k3-j7200-r5-common: Hook buck1_reg to vtm supplyGowtham Tammana1-0/+5
Hook buck1_reg to vtm avs supply. Signed-off-by: Gowtham Tammana <g-tammana@ti.com> Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com> Link: https://lore.kernel.org/r/20210714205300.17424-5-g-tammana@ti.com
2021-07-15arm/dts: k3-j7200-r5-common: Add VTM nodeGowtham Tammana1-0/+7
Add voltage and thermal management (VTM) node. The efuse values for the OPPs are stored under the VTM, and is needed for AVS class 0 support. Signed-off-by: Gowtham Tammana <g-tammana@ti.com> Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com> Link: https://lore.kernel.org/r/20210714205300.17424-4-g-tammana@ti.com
2021-07-15arm/dts: k3-j7200-r5-common: Add pmic lp876441 nodeGowtham Tammana1-0/+26
Add pmic lp876411 node needed for CPU AVS support. Signed-off-by: Gowtham Tammana <g-tammana@ti.com> Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com> Link: https://lore.kernel.org/r/20210714205300.17424-3-g-tammana@ti.com
2021-07-15arm: omap3: Make secure_unlock_mem() staticAdam Ford1-9/+9
secure_unlock_mem() is only used in one file, so make it static in that file. Signed-off-by: Adam Ford <aford173@gmail.com> Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com> Link: https://lore.kernel.org/r/20210625192308.277136-4-aford173@gmail.com
2021-07-15arm: omap3: Make secureworld_exit() staticAdam Ford2-2/+1
secureworld_exit() is only used in one file, so make it static to that file and remove it from sys_proto.h. This may help with some further optimization in the future. Signed-off-by: Adam Ford <aford173@gmail.com> Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com> Link: https://lore.kernel.org/r/20210625192308.277136-3-aford173@gmail.com
2021-07-15arm: omap3: Make try_unlock_memory() staticAdam Ford2-9/+9
try_unlock_memory() is only used in one file, so make it static in that file,remove it from the sys_proto header file, and relocate it into the #ifdef section that call it. This will make it only built under the conditions when it is called, and it may help with some further optimization in the future. Signed-off-by: Adam Ford <aford173@gmail.com> Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com> Link: https://lore.kernel.org/r/20210625192308.277136-2-aford173@gmail.com
2021-07-15arm: mach-k3: am642_init: Add missing ddr guardGowtham Tammana1-1/+1
The `struct udevice *` reference is needed for either of the K3_LOAD_SYSFW, K3_AM64_DDRSS config guards. Adding the missing K3_AM64_DDRSS guard. Signed-off-by: Gowtham Tammana <g-tammana@ti.com> Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com> Link: https://lore.kernel.org/r/20210624171614.14244-1-g-tammana@ti.com
2021-07-15arm: dts: ti: k3-am65-main: Add ICSSG nodesLokesh Vutla2-0/+535
Add the DT nodes for the ICSSG0, ICSSG1 and ICSSG2 processor subsystems that are present on the K3 AM65x SoCs. The three ICSSGs are identical to each other for the most part, with the ICSSG2 supporting slightly enhanced features for supporting SGMII PRU Ethernet. Each ICSSG instance is represented by a PRUSS subsystem node. These nodes are enabled by default. DT nodes are fetch from Linux 5.13 Kernel. Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com> Link: https://lore.kernel.org/r/20210622063431.3151-5-lokeshvutla@ti.com
2021-07-15arm: dts: k3-am654-base-board: Add r5 specific u-boot dtsiLokesh Vutla3-205/+209
So far all the u-boot specific properties for both r5 and a53 are placed in k3-am654-base-board-u-boot.dtsi. But there are few a53 nodes that should be updated but doesn't belong to r5. So create a separate r5 specific u-boot dtsi. Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com> Link: https://lore.kernel.org/r/20210622063431.3151-4-lokeshvutla@ti.com
2021-07-15arm: dts: k3-am64-main: Reserve OCMRAM for DMSC-lite and secure proxy ↵Aswath Govindraju1-0/+8
communication The final 128KB in SRAM is reserved by default for DMSC-lite code and secure proxy communication buffer. The memory region used for DMSC-lite code can be optionally freed up by secure firmware API[1]. However, the buffer for secure proxy communication is not configurable. This default hardware configuration is unique for AM64. Therefore, indicate the area reserved for DMSC-lite code and secure proxy communication buffer in the oc_sram device tree node. [1] - http://downloads.ti.com/tisci/esd/latest/6_topic_user_guides/security_handover.html#triggering-security-handover Signed-off-by: Aswath Govindraju <a-govindraju@ti.com> Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com> Acked-by: Suman Anna <s-anna@ti.com> Link: https://lore.kernel.org/r/20210616163821.20457-3-a-govindraju@ti.com
2021-07-15configs: am64x_evm_a53_defconfig: Move TF-A load address to 0x701c0000Aswath Govindraju1-2/+2
Earlier, the region 0x701c0000 to 0x701dffff was firewalled off because of a bug in SYSFW. In the v2021.05 release of SYSFW this bug has been fixed and this region can now be used for other allocations. Therefore, move TF-A's load address to 0x701c0000 and update its location in the device tree node. Also, increase the size allocated for TF-A to account for future expansions. Fixes: defd62ca137b ("arm: dts: k3-am64-main: Update the location of ATF in SRAM and increase its max size") Signed-off-by: Aswath Govindraju <a-govindraju@ti.com> Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com> Reviewed-by: Suman Anna <s-anna@ti.com> Link: https://lore.kernel.org/r/20210616163821.20457-2-a-govindraju@ti.com
2021-07-15am335x, guardian: Enable panel driver Himax HX8238DGireesh Hiremath3-1/+20
- Enable lcd controller - Display splash screen Signed-off-by: Gireesh Hiremath <Gireesh.Hiremath@in.bosch.com> Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com> Link: https://lore.kernel.org/r/20210611161350.2141-16-Gireesh.Hiremath@in.bosch.com
2021-07-15am335x, guardian: Update pinmux configurationMoses Christopher1-3/+3
pinmux update for guardian board - control ASP Board Power: GPIO, on/off ASP Board Power - control Coincell Voltage Measurement: GPIO, enable/disable ADC measurements - powerOff Device GPIO-PowerOff, cut the PMIC supply Signed-off-by: Moses Christopher <BollavarapuMoses.Christopher@in.bosch.com> Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com> Link: https://lore.kernel.org/r/20210611161350.2141-7-Gireesh.Hiremath@in.bosch.com
2021-07-15am335x, guardian: mem: Add board dependent mem valuesMoses Christopher3-0/+71
- Add mem-guardian.h derived from am33xx/mem.h * Add GPMC config values optimized for Bosch Guardian Board * NAND Chip used by Bosch Guardian Board is Micron MT29F4G08ABBFA Signed-off-by: Moses Christopher <BollavarapuMoses.Christopher@in.bosch.com> Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com> Link: https://lore.kernel.org/r/20210611161350.2141-3-Gireesh.Hiremath@in.bosch.com
2021-07-15x86: Ensure the e820 map is installed in all casesSimon Glass1-4/+4
This is a revert of a recent logic change in setup_zimage(). We do actually need to install this information always. Change it to install from the Coreboot tables if available, else the normal source. Fixes: e7bae8283fe ("x86: Allow installing an e820 when booting from coreboot") Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
2021-07-15x86: cros: Check ROM exists before building vbootSimon Glass2-2/+2
All the x86 devicetree files are built at once, whichever board is actually being built. If coreboot is the target build, CONFIG_ROM_SIZE is not defined and samus cannot build Chromium OS verified boot. Add this condition to avoid errors about CONFIG_ROM_SIZE being missing. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Bin Meng <bmeng.cn@gmail.com> Reviewed-by: Jaehoon Chung <jh80.chung@samsung.com>
2021-07-15x86: coreboot: Use vendor in the KconfigSimon Glass1-1/+1
Use VENDOR_COREBOOT instead of TARGET_COREBOOT so we can have multiple coreboot boards, sharing options. Only SYS_CONFIG_NAME needs to be defined TARGET_COREBOOT. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
2021-07-15x86: Add function comments to cb_sysinfo.hSimon Glass1-0/+16
Add a function comment for get_coreboot_info() and a declaration for cb_get_sysinfo(), since this may be called from elsewhere. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
2021-07-15x86: Do cache set-up by default when booting from corebootSimon Glass1-4/+14
A recent change to disable cache setup when booting from coreboot assumed that this has been done by SPL. The result is that for the coreboot board, the cache is disabled (in start.S) and never re-enabled. If the cache was turned off, as it is on boards without SPL, we should turn it back on. Add this new condition. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
2021-07-15x86: Update the MP constants to avoid conflictsSimon Glass1-4/+8
These constants conflict with error codes returned by the MP implementation when something is wrong. In particular, mp_first_cpu() returns MP_SELECT_BSP when running without multiprocessing enabled. Since this is -2, it is interpreted as an error by callers, which expect a positive CPU number for the first CPU. Correct this by using a different range for the pre-defined CPU numbers, above zero and out of the range of possible CPU values. For now it is safe to assume there are no more than 64K CPUs. This fixes the 'mtrr' command when CONFIG_SMP is not enabled. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
2021-07-15x86: Don't set up MTRRs if previously doneSimon Glass1-1/+1
When starting U-Boot from a previous-stage bootloader we presumably don't need to set up the variable MTRRs. In fact this could be harmful if the existing settings are not what U-Boot uses. Skip that step in this case. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
2021-07-15arm: a37xx: pci: Optimize a3700_fdt_fix_pcie_regions() when fixup offset is zeroPali Rohár1-0/+4
If fixup offset is zero then there is nothing to fix. All calculation in this case just increase addresses by value zero which results in identity. So in this case skip whole fixup re-calculation as it is not needed. This is just an optimization for special case when fix_offset is zero which skips code path which does only identity operations (meaning nothing). No functional changes. Signed-off-by: Pali Rohár <pali@kernel.org> Reviewed-by: Konstantin Porotchkin <kostap@marvell.com> Reviewed-by: Stefan Roese <sr@denx.de>
2021-07-14board: stemmy: Copy atags for booting downstream/vendor kernelStephan Gerhold1-0/+1
The U-Boot "stemmy" board is mainly intended to simplify booting mainline Linux on various smartphones from Samsung based on ST-Ericsson Ux500. While the mainline kernel is working great, there are still some features missing there. In particular, it is currently not possible to charge the battery when using the mainline kernel. This means that it is still necessary to boot the downstream/vendor kernel from Samsung sometimes to charge the device. That kernel is ancient, still uses board files + ATAGS instead of device trees and relies on a strange very long kernel command line hardcoded in the Samsung bootloader. Actually, since mainline is booted with device trees there is a very simple way to make the old downstream kernel work as well: We can simply take most of the ATAGS passed to U-Boot from the Samsung bootloader and copy them as-is when booting a kernel without device tree. That way the long command line and other needed ATAGS are copied as-is without having to bother with them. The only exception is the ATAG_INITRD - since the initrd is loaded by U-Boot, the atag for that should be generated in U-Boot so it points to the correct address. All other ATAGS are copied as-is and not generated in U-Boot. Also use the chance and provide a serial# for U-Boot by parsing the ATAG_SERIAL that is also passed by the Samsung bootloader. Signed-off-by: Stephan Gerhold <stephan@gerhold.net> Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
2021-07-14board: stemmy: Parse atags to get available memoryStephan Gerhold1-0/+1
At the moment the "stemmy" board attempts to detect the RAM size with a simple memory test (get_ram_size()). Unfortunately, this does not work correctly for devices with 768 MiB RAM (e.g. Samsung Galaxy Ace 2 (GT-I8160), "codina"). Reading/writing memory after the 768 MiB RAM succeeds but actually overwrites some earlier parts of the memory. For U-Boot this does not result in any major problems, but on Linux this will eventually lead to strange crashes because of the memory corruption. Since the "stemmy" U-Boot port is designed to be chainloaded from the original Samsung bootloader, the most reliable way to get the available amount of RAM is to look at the ATAGS passed by the Samsung bootloader. Fortunately, the header used to generate ATAGS in U-Boot (asm/setup.h) can also be easily used to parse them. Also clarify and simplify stemmy.h a bit to make it more clear where some of the magic values in there are actually coming from. Signed-off-by: Stephan Gerhold <stephan@gerhold.net> Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
2021-07-14ARM: dts: uniphier: Add support for Akebi96Kunihiko Hayashi2-0/+190
Add the device tree for Akebi96. Akebi96 is a 96boards certified development board based on UniPhier LD20. ( https://www.96boards.org/product/akebi96/ ) Signed-off-by: Masami Hiramatsu <masami.hiramatsu@linaro.org> Signed-off-by: Kunihiko Hayashi <hayashi.kunihiko@socionext.com>
2021-07-14arm: mach-snapdragon: pinctrl: Place pin_name in .data sectionStephan Gerhold2-3/+2
According to arch/arm/lib/crt0_64.S, the BSS section is "UNAVAILABLE" and uninitialized before relocation. Also, it overlaps with the appended DTB before relocation, so writing data into a variable in the BSS section might corrupt the appended DTB. Unfortunately, pinctrl-apq8016.c and pinctrl-apq8096.c do place the "pin_name" variable in the BSS section (since it's uninitialized). It's also used before relocation, when setting up the pinctrl for the serial driver. On DB410c this causes "GPIO_5" to be written into some part of an appended DTB, e.g.: 80111820: edfe0dd0 9f100000 38000000 c00e0000 ...........8.... 80111830: 28000000 11000000 10000000 00000000 ...(............ 80111840: 4f495047 8800355f 00000000 00000000 GPIO_5.......... 80111850: 00000000 00000000 01000000 00000000 ................ 80111860: 03000000 04000000 00000000 02000000 ................ 80111870: 03000000 04000000 0f000000 02000000 ................ 80111880: 03000000 2d000000 1b000000 6c617551 .......-....Qual 80111890: 6d6d6f63 63655420 6c6f6e68 6569676f comm Technologie Depending on the part of the DTB that is corrupted this might not cause any problems, but it can also result in strange reboots without any serial output. Fortunately, in practice this does not cause issues on DB410c yet because board_fdt_blob_setup() in dragonboard410c.c currently overrides the appended DTB with the one passed by the previous bootloader (LK) (which does not get corrupted). DB820c does not have board_fdt_blob_setup() so I would expect it to be affected by this problem. Perhaps everyone was just fortunate to not compile an U-Boot configuration where the pin_name corrupts an important part of the DTB. Make sure "pin_name" is explicitly placed in the .data section instead of .bss to fix this. Cc: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Stephan Gerhold <stephan@gerhold.net> Reviewed-by: Ramon Fried <rfried.dev@gmail.com>
2021-07-10ARM: imx: Pick correct eMMC boot partition from ROM logMarek Vasut1-0/+61
In case the iMX8M boot from eMMC boot partition and the primary image is corrupted, the BootROM is capable of starting a secondary image in the other eMMC boot partition as a fallback. However, the BootROM leaves the eMMC BOOT_PARTITION_ENABLE setting as it was, i.e. pointing to the boot partition containing the corrupted image, and the BootROM does not provide any indication that this sort of fallback occured. According to AN12853 i.MX ROMs Log Events, Rev. 0, May 2020, it is possible to determine whether fallback event occurred by parsing the ROM event log. In case ROM event ID 0x51 is present, fallback event did occur. This patch implements ROM event log parsing and search for event ID 0x51 for all iMX8M SoCs, and based on that corrects the eMMC boot partition selection. This way, the SPL loads the remaining boot components from the same eMMC boot partition from which it was started, even in case of the fallback. Signed-off-by: Marek Vasut <marex@denx.de> Cc: Faiz Abbas <faiz_abbas@ti.com> Cc: Harald Seiler <hws@denx.de> Cc: Lokesh Vutla <lokeshvutla@ti.com> Cc: Simon Glass <sjg@chromium.org> Cc: Fabio Estevam <festevam@gmail.com> Cc: Peng Fan <peng.fan@nxp.com> Cc: Stefano Babic <sbabic@denx.de> Cc: Ye Li <ye.li@nxp.com>
2021-07-10arm: dts: imx8mm-venice-gw7901.dts: fix dsa switch configurationTim Harvey1-1/+36
Fix the dsa switch config: - remove the unnecessary phy-mode from the switch itself - added the necessary fixed-link node to the non-cpu ports required for U-Boot DSA Signed-off-by: Tim Harvey <tharvey@gateworks.com>
2021-07-10board: gateworks: venice: add imx8mm-gw7901 supportTim Harvey3-0/+1138
The Gateworks GW7901 is an ARM based single board computer (SBC) featuring: - i.MX8M Mini SoC - LPDDR4 DRAM - eMMC FLASH - SPI FRAM - Gateworks System Controller (GSC) - Atmel ATECC Crypto Authentication - USB 2.0 - Microchip GbE Switch - Multiple multi-protocol RS232/RS485/RS422 Serial ports - onboard 802.11ac WiFi / BT - microSD socket - miniPCIe socket with PCIe, USB 2.0 and dual SIM sockets - Wide range DC power input - 802.3at PoE To add support for this board: - add dts from Linux (accepted for v5.14) - add SPL PMIC config Signed-off-by: Tim Harvey <tharvey@gateworks.com>
2021-07-10arm/mach-imx: Fix macros in mmdc_size.cKacper Kubkowski1-5/+5
Make macros actually use passed parameter instead of local variables that happen to be named the same as symbols in macro expansion. Signed-off-by: Kacper Kubkowski <kkubkowski@fluence.pl>
2021-07-10board: phytec: imx8mp-phycore: Switch to binmanTeresa Remmet1-0/+1
Use now binman for image creation. Signed-off-by: Teresa Remmet <t.remmet@phytec.de> Reviewed-by: Fabio Estevam <festevam@gmail.com> Reviewed-by: Heiko Schocher <hs@denx.de>
2021-07-10arm: dts: imx8mp-phyboard-pollux-rdk-u-boot: Add wdog pinctrl entryTeresa Remmet1-0/+4
Add missing pinctrl entry in spl. Signed-off-by: Teresa Remmet <t.remmet@phytec.de> Reviewed-by: Fabio Estevam <festevam@gmail.com>
2021-07-10board: phytec: phycore_imx8mp: Change debug UARTTeresa Remmet2-8/+8
With the first redesign the debug UART had changed from UART2 to UART1. As the first hardware revision is considered as alpha and will not be supported in future. The old setup will not be preserved. Signed-off-by: Teresa Remmet <t.remmet@phytec.de> Reviewed-by: Fabio Estevam <festevam@gmail.com> Reviewed-by: Heiko Schocher <hs@denx.de>
2021-07-10arm: dts: imx8mp-phyboard-pollux: Sync dts files with kernelTeresa Remmet2-2/+46
This update includes eqos support and some minor changes. Synced with kernel commit 412627f6ffe3 ("arm64: dts: imx8mp-phyboard-pollux-rdk: Add missing pinctrl entry") Signed-off-by: Teresa Remmet <t.remmet@phytec.de> Reviewed-by: Fabio Estevam <festevam@gmail.com> Reviewed-by: Heiko Schocher <hs@denx.de>
2021-07-10arm: dts: imx8mp: Add common u-boot dtsiTeresa Remmet3-178/+153
Factor out the common node settings for dm-spl and dm-pre-reloc and move them to imx8mp-u-boot.dtsi Signed-off-by: Teresa Remmet <t.remmet@phytec.de> Reviewed-by: Fabio Estevam <festevam@gmail.com> Reviewed-by: Heiko Schocher <hs@denx.de>
2021-07-10arm: dts: imx8mp: Resync imx8mp device tree includeTeresa Remmet1-5/+141
Sync imx8mp include with kernel commit: d1689cd3c0f4 ("arm64: dts: imx8mp: Use the correct name for child node "snps, dwc3"") Signed-off-by: Teresa Remmet <t.remmet@phytec.de> Reviewed-by: Fabio Estevam <festevam@gmail.com> Reviewed-by: Heiko Schocher <hs@denx.de>
2021-07-10pci: imx: use reset-gpios if defined by device-treeTim Harvey1-1/+2
If reset-gpio is defined by device-tree use that if CONFIG_PCIE_IMX_PERST_GPIO is not defined. Note that after this the following boards which define CONFIG_PCIE_IMX_PERST_GPIO in their board header file as well as their device-tree should be able to remove CONFIG_PCIE_IMX_PERST_GPIO without consequence: - mx6sabresd - mx6sxsabresd - novena - tbs2910 - vining_2000 Note that the ge_bx50v3 board uses CONFIG_PCIE_IMX_PERST_GPIO and does not have reset-gpios defined it it's pcie node in the dt thus removing CONFIG_PCIE_IMX_PERST_GPIO globally can't be done until that board adds reset-gpios. Cc: Ian Ray <ian.ray@ge.com> (maintainer:GE BX50V3 BOARD) Cc: Sebastian Reichel <sebastian.reichel@collabora.com> (maintainer:GE BX50V3 BOARD) Cc: Fabio Estevam <festevam@gmail.com> (maintainer:MX6SABRESD BOARD) Cc: Marek Vasut <marex@denx.de> (maintainer:NOVENA BOARD) Cc: Soeren Moch <smoch@web.de> (maintainer:TBS2910 BOARD) Cc: Silvio Fricke <open-source@softing.de> (maintainer:VINING_2000 BOARD) Signed-off-by: Tim Harvey <tharvey@gateworks.com>
2021-07-10imx8m: Restrict usable memory to space below 4G boundaryFrieder Schrempf1-0/+14
Some IPs have their accessible address space restricted by the interconnect. Let's make sure U-Boot only ever uses the space below the 4G address boundary (which is 3GiB big), even when the effective available memory is bigger. We implement board_get_usable_ram_top() for all i.MX8M SoCs, as the whole family is affected by this. Signed-off-by: Frieder Schrempf <frieder.schrempf@kontron.de>
2021-07-10Merge branch 'master' of https://source.denx.de/u-boot/custodians/u-boot-sunxiTom Rini36-71/+592
Aside from the usual fixes and updates one visible change is the MMC update, which fixes some lingering bugs and gives a decent speed increase on some boards (9->19 MB/s on H6, 21->43 MB/s on A64 eMMC). I am keeping an watchful eye on bug reports here, to spot any correctness regressions. Another change is finally the enablement of the first USB host port on many boards without micro-USB (data) sockets, like the Pine64 family. That doubles the number of usable USB ports from 1 to 2 on those boards. Some smaller fixes, 4GB DRAM support (on the H616) and a new board (ZeroPi) conclude this first round of changes. Compile-tested for all 157 sunxi boards, boot-tested on Pine H64, Pine64-LTS, OrangePi Zero 2 and BananaPi M2 Berry. Summary: - DT update for H3/H5/H6 - Enable first USB port on boards without micro-USB - ZeroPi board support - 4GB DRAM support for H616 boards - MMC fixes and speed improvement - some fixes
2021-07-10mmc: sunxi: Increase MMIO FIFO read performanceAndre Przywara1-0/+1
To avoid the complexity of DMA operations (with chained descriptors), we use repeated MMIO reads and writes to the SD_FIFO_REG, which allows us to drain or fill the MMC data buffer FIFO very easily. However those MMIO accesses are somewhat costly, so this limits our MMC performance, to between 17 and 22 MB/s, but down to 9.5 MB/s on the H6 (partly due to the lower AHB1 frequency). As it turns out we read the FIFO status register after *every* word we read or write, which effectively doubles the number of MMIO accesses, thus effectively more than halving our performance. To avoid this overhead, we can make use of the FIFO level bits, which are in the very same FIFO status registers. So for a read request, we now can collect as many words as the FIFO level originally indicated, and only then need to update the status register. We don't know for sure the size of the FIFO (and it seems to differ across SoCs anyway), so writing is more fragile, which is why we still use the old method for that. If we find a minimum FIFO size available on all SoCs, we could use that, in a later optimisation. This patch increases the eMMC read speed on a Pine64-LTS from about 22MB/s to 44 MB/s. SD card reads don't gain that much, but with 23 MB/s we now reach the practical limit for 3.3V SD cards. On the H6 we double our transfer speed, from 9.5 MB/s to 19.7 MB/s. Signed-off-by: Andre Przywara <andre.przywara@arm.com>
2021-07-10mmc: sunxi: Enable "new timing mode" on all new SoCsAndre Przywara1-0/+3
All SoCs since the Allwinner A64 (H5, H6, R40, H616) feature the so called "new timing mode", so enable this in Kconfig for those SoCs. Signed-off-by: Andre Przywara <andre.przywara@arm.com>
2021-07-10mmc: sunxi: Fix MMC clock parent selectionAndre Przywara1-1/+1
Most Allwinner SoCs which use the so called "new timing mode" in their MMC controllers actually use the double-rate PLL6/PERIPH0 clock as their parent input clock. This is interestingly enough compensated by a hidden "by 2" post-divider in the mod clock, so the divider and actual output rate stay the same. Even though for the H6 and H616 (but only for them!) we use the doubled input clock for the divider computation, we never accounted for the implicit post-divider, so the clock was only half the speed on those SoCs. This didn't really matter so far, as our slow MMIO routine limits the transfer speed anyway, but we will fix this soon. Clean up the code around that selection, to always use the normal PLL6 (PERIPH0(1x)) clock as an input. As the rate and divider are the same, that makes no difference. Explain the hardware differences in a comment. Signed-off-by: Andre Przywara <andre.przywara@arm.com>
2021-07-10sunxi: H616: Enable full 4GB of DRAMAndre Przywara2-3/+12
The H616 is our first supported Allwinner SoC which goes beyond the 4GB address space "barrier", by having more than 32 address bits. Lift the preliminary 3GB DRAM limit for the H616, and update the page table setup on the way, to actually map that last GB as well. As not all devices are actually capable of dealing with more than 32 bits (the DMA in the EMAC for instance), we also limit U-Boot's own DRAM usage to 4GB on the way. Signed-off-by: Andre Przywara <andre.przywara@arm.com>
2021-07-10sunxi: h3: Add initial ZeroPi supportYu-Tung Chang2-1/+87
ZeroPi is a new board of high performance with low cost designed by FriendlyElec., using the Allwinner H3 SOC. ZeroPi features - Allwinner H3, Quad-core Cortex-A7@1.2GHz - 256MB/512MB DDR3 RAM - microsd slot - 10/100/1000Mbps Ethernet - Debug Serial Port - DC 5V/2A power-supply Signed-off-by: Yu-Tung Chang <mtwget@gmail.com> Reviewed-by: Andre Przywara <andre.przywara@arm.com> Signed-off-by: Andre Przywara <andre.przywara@arm.com>
2021-07-10sunxi: clock: H6/H616: Fix PLL clock factor encodingsAndre Przywara4-5/+5
Most clock factors and dividers in the H6 PLLs use a "+1 encoding", which we were missing on two occasions. This fixes the MMC clock setup on the H6, which could be slightly off due to the wrong parent frequency: mmc 2 set mod-clk req 52000000 parent 1176000000 n 2 m 12 rate 49000000 Also the CPU frequency (PLL1) was a tad too high before. For PLL5 (DRAM) we already accounted for this +1, but in the DRAM code itself, not in the bit field macro. Move this there to be aligned with what the other SoCs and other PLLs do. Signed-off-by: Andre Przywara <andre.przywara@arm.com> Reviewed-by: Jernej Skrabec <jernej.skrabec@gmail.com>
2021-07-10arm: dts: sunxi: h3: Update DT filesAndre Przywara8-15/+142
Update the H3 DT files from the Linux 5.12 release. The changes update some boards, and don't affect U-Boot, but fix Gigabit Ethernet when this DT is passed on to the Linux kernel. Signed-off-by: Andre Przywara <andre.przywara@arm.com>
generated by cgit v1.2.3 (git 2.39.0) at 2025-09-17 21:37:59 +0300