u-boot.git/arch/arm/include/asm, branch v2022.07

arm: apple: nvme: Add SART support and RTKit buffer management

2022-06-23T12:24:49Z

The NVMe firmware in the macOS 13 beta blocks or crashes with u-boot's current minimal RTKit implementation. It does not provide buffers for the firmware's buffer requests. The ANS2 firmware included in macOS 11 and 12 tolerates this. The firmware included in the first macOS 13 beta requires buffers for the crashlog and ioreport endpoints to function. In the case of the NVMe the buffers are physical memory. Access to physical memory is guarded by what Apple calls SART. Import m1n1's SART driver (exclusively used for the NVMe controller). Implement buffer management helpers for RTKit. These are generic since other devices (none in u-boot so far) require different handling. Signed-off-by: Janne Grunau Reviewed-by: Mark Kettenis Tested-by: Mark Kettenis

armv8: always use current exception level for TCR_ELx access

2022-06-16T19:22:55Z

Currently get_tcr() takes an "el" parameter, to select the proper version of the TCR_ELx system register. This is problematic in case of the Apple M1, since it runs with HCR_EL2.E2H fixed to 1, so TCR_EL2 is actually using the TCR_EL1 layout, and we get the wrong version. For U-Boot's purposes the only sensible choice here is the current exception level, and indeed most callers treat it like that, so let's remove that parameter and read the current EL inside the function. This allows us to check for the E2H bit, and pretend it's EL1 in this case. There are two callers which don't care about the EL, and they pass 0, which looks wrong, but is irrelevant in these two cases, since we don't use the return value there. So the change cannot affect those two. Signed-off-by: Andre Przywara Reviewed-by: Mark Kettenis Tested-by: Mark Kettenis

armv8: Fix TCR 64-bit writes

2022-06-03T15:15:24Z

The AArch64 TCR_ELx register is a 64-bit register, and many newer architecture features use bits in the upper half. So far U-Boot was igorant of those bits, trying to leave them alone. However, in an effort to set bit 31 to 1, it failed doing so, because the compiler sign-extended "1 << 31", so that all bits[63:31] got set. Older ARMv8.0 cores don't define anything dangerous up there, but newer architecture revisions do, and setting all those bits will end badly: ================= $ qemu-system-aarch64 -cpu max .... U-Boot 2022.07-rc1 (May 09 2022 - 15:21:00 +0100) DRAM: 1.5 GiB ================= (hangs here) Defining TCR_ELx_RSVD to "1U << 31" avoids the sign-extension, so all upper bits stay at a safe 0 value. This means no more surprises when U-Boot runs on a more capable CPU core. Reported-by: Balaji Anandapadmanaban Signed-off-by: Andre Przywara Reviewed-by: Peng Fan Tested-by: Peter Collingbourne Reviewed-by: Peter Collingbourne

i.MX8ULP: add display_ele_fw_version api

2022-05-20T10:36:47Z

implement get f/w version api. print ele f/w version in spl. Signed-off-by: Gaurav Jain Reviewed-by: Peng Fan Reviewed-by: Pankaj Gupta

imx8m: fix reading of DDR4 MR registers

2022-05-20T07:30:28Z

I was trying to employ lpddr4_mr_read() to something similar to what the imx8mm-cl-iot-gate board is doing for auto-detecting the RAM type. However, the version in drivers/ddr/imx/imx8m/ddrphy_utils.c differs from the private one used by that board in how it extracts the byte value, and I was only getting zeroes. Adding a bit of debug printf'ing gives me tmp = 0x00ffff00 tmp = 0x00070700 tmp = 0x00000000 tmp = 0x00101000 and indeed I was expecting a (combined) value of 0xff070010 (0xff being Manufacturer ID for Micron). I can't find any documentation that says how the values are supposed to be read, but clearly the iot-gate definition is the right one, both for its use case as well as my imx8mp-based board. So lift the private definition of lpddr4_mr_read() from the imx8mm-cl-iot-gate board code to ddrphy_utils.c, and add a declaration in the ddr.h header where e.g. get_trained_CDD() is already declared. This has only been compile-tested for the imx8mm-cl-iot-gate board (since I don't have the hardware), but since I've merely moved its definition of lpddr4_mr_read(), I'd be surprised if it changed anything for that board. Signed-off-by: Rasmus Villemoes Tested-by: Ying-Chun Liu (PaulLiu) Reviewed-by: Fabio Estevam

ARM: imx: imx31: Introduce and use UART_BASE_ADDR(n)

2022-05-20T07:03:01Z

Introduce helper macro UART_BASE_ADDR(n), which returns Nth UART base address. Convert all board configurations to this new macro. This is the first step toward switching CONFIG_MXC_UART_BASE to Kconfig. This is a clean up, no functional change. The new macro contains compile-time test to verify N is in suitable range. The test works such that it multiplies constant N by constant double-negation of size of a non-empty structure, i.e. it multiplies constant N by constant 1 in each successful compilation case. The non-empty structure may contain C11 _Static_assert(), make use of this and place the kernel variant of static assert in there, so that it performs the compile-time check for N in the correct range. Note that it is not possible to directly use static_assert in compound statements, hence this convoluted construct. Signed-off-by: Marek Vasut Cc: Fabio Estevam Cc: Peng Fan Cc: Stefano Babic

ARM: imx: imx27: Introduce and use UART_BASE_ADDR(n)

2022-05-20T07:03:01Z

ARM: imx: imx8m: Introduce and use UART_BASE_ADDR(n)

2022-05-20T07:03:01Z

arm: nuvoton: Add support for Nuvoton NPCM750 BMC

2022-05-05T13:28:47Z

Add basic support for the Nuvoton NPCM750 EVB (Poleg). Signed-off-by: Jim Liu

pci: imx: remove weak overrides no longer used

2022-04-21T12:38:03Z

There are no users of the imx6_pcie_toggle_power and imx6_pcie_toggle_reset weak overrides and as these functions are able to be handled now via dt properties lets remove these. Cc: Marek Vasut Signed-off-by: Tim Harvey