Heiko Stuebner [Mon, 10 Jun 2024 13:13:32 +0000 (15:13 +0200)]
arm64: dts: rockchip: move uart2 pinmux to dtsi on rk3588-tiger
The association of uart2 to the q7-uart pins is part of the module
itself and not the baseboard used. Therefore move the pinctrl over
to the tiger dtsi.
Quentin Schulz [Thu, 6 Jun 2024 08:45:36 +0000 (10:45 +0200)]
rockchip: ringneck-px30: fix TPL_MAX_SIZE
Ringneck was mistakenly set to allow up to 128KiB for the TPL code size
while PX30 SoC only has 16KiB of SRAM.
Therefore, let's use the default value of TPL_MAX_SIZE from the SoC
(which is 10KiB) so that the max code size is actually checked and
useful.
Fixes: c925be73a0a8 ("rockchip: add support for PX30 Ringneck SoM on Haikou Devkit") Reviewed-by: Kever Yang <kever.yang@rock-chips.com> Signed-off-by: Quentin Schulz <quentin.schulz@cherry.de>
Quentin Schulz [Thu, 6 Jun 2024 08:45:35 +0000 (10:45 +0200)]
power: rk8xx: properly print all supported PMICs name
The ID of the PMIC is stored in the 2 16b registers but the only part
that matters right now is the 3 MSB, which make the 3 digits (in hex) of
the part number.
Right now, only RK808 was properly displayed, with this all currently
supported PMICs should display the proper part number.
Additionally, when the PMIC variant is not found, print that value
instead of the masked unshifted value as all PMICs we support for now
have their LSB ignored to represent the actual part number.
Tested on RK806 (RK3588 Jaguar), RK808 (RK3399 Puma) and RK809 (PX30
Ringneck).
Reviewed-by: Kever Yang <kever.yang@rock-chips.com> Signed-off-by: Quentin Schulz <quentin.schulz@cherry.de>
On px30-ringneck the FIT payload is located at sector 0x200 compared to
the more Rockchip common sector 0x4000 offset:
SYS_MMCSD_RAW_MODE_U_BOOT_SECTOR=0x200
Because FIT payload is located at sector 0x200 and the TPL+SPL is
located at sector 64, the combined size of TPL+SPL cannot take up more
than 224KiB:
(0x200 - 64) x 512 = 0x38000 (224 KiB)
Adjust SPL_PAD_TO to match the used 0x200 sector offset.
While at it, update the px30-ringneck-u-boot.dtsi to remove the now
unnecessary override of simple-bin:fit:offset since SPL_PAD_TO matches
with the current formula.
Reviewed-by: Kever Yang <kever.yang@rock-chips.com> Signed-off-by: Quentin Schulz <quentin.schulz@cherry.de>
Since commit 6007b69d544e ("rockchip: rk3399-puma: Update SPL_PAD_TO
Kconfig option"), SPL_PAD_TO matches
(CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_SECTOR - 64) * 512 and the default
value for simple-bin:fit:offset in rockchip-u-boot.dtsi is
SPL_PAD_TO, so let's remove this override.
Reviewed-by: Kever Yang <kever.yang@rock-chips.com> Signed-off-by: Quentin Schulz <quentin.schulz@cherry.de>
Jianfeng Liu [Tue, 28 May 2024 17:04:06 +0000 (01:04 +0800)]
board: rockchip: add ArmSoM Sige7 Rk3588 board
ArmSoM Sige7 is a Rockchip RK3588 based SBC (Single Board Computer) by
ArmSoM.
There are two variants depending on the DRAM size : 8G and 16G.
Specification:
Rockchip Rk3588 SoC
4x ARM Cortex-A76, 4x ARM Cortex-A55
8/16GB memory LPDDR4x
Mali G610MC4 GPU
2x MIPI CSI 2 multiple lanes connector
64GB/128GB on board eMMC
uSD slot
1x USB 2.0 Type-A, 1x USB 3.0 Type-A, 1x USB 3.0 Type-C
1x HDMI 2.1 output
2x 2.5 Gbps Ethernet port
40-pin IO header including UART, SPI and I2C
USB PD over USB Type-C
Size: 92mm x 62mm
Niklas Cassel [Tue, 28 May 2024 17:04:03 +0000 (01:04 +0800)]
arm64: dts: rockchip: add rk3588 pcie and php IOMMUs
The mmu600_pcie is connected with the five PCIe controllers.
The mmu600_php is connected with the USB3 controller, the GMAC
controllers, and the SATA controllers.
See 8.2 Block Diagram, in rk3588 TRM (Technical Reference Manual).
The IOMMUs are disabled by default, as further patches are needed to
program the SID/SSIDs in to the IOMMUs.
Additionally, the IOMMU correctly triggers an IOMMU fault when
a PCIe device performs a write (since the device hasn't been
assigned a SID/SSID):
arm-smmu-v3 fc900000.iommu: event 0x02 received:
arm-smmu-v3 fc900000.iommu: 0x0000010000000002
arm-smmu-v3 fc900000.iommu: 0x0000000000000000
arm-smmu-v3 fc900000.iommu: 0x0000000000000000
arm-smmu-v3 fc900000.iommu: 0x0000000000000000
While this doesn't provide much value as is, having the devices as
disabled in the device tree will allow developers to see that the rk3588
actually has IOMMUs on the SoC.
(cherry picked from commit ea9a34aa0d786cbf4b87f1ba528e69b07219738f) Signed-off-by: Jianfeng Liu <liujianfeng1994@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
(cherry picked from commit c7ed588e14f7dd04a92fb55f12680f94c7b14edf) Signed-off-by: Jianfeng Liu <liujianfeng1994@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
(cherry picked from commit 5110caca9865718616cf7093ed4a9a1bc54780db) Signed-off-by: Jianfeng Liu <liujianfeng1994@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
(cherry picked from commit f6835a60a8a28ff14ffb3dd80c99ce1c137d06c5) Signed-off-by: Jianfeng Liu <liujianfeng1994@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
(cherry picked from commit 5a3e4638492497ae81b9bd4a8627f4727e312ccc) Signed-off-by: Jianfeng Liu <liujianfeng1994@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
(cherry picked from commit bbf7c16f2f1208b96349f6f6648b69cfaa1a482b) Signed-off-by: Jianfeng Liu <liujianfeng1994@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
(cherry picked from commit 3cd15354ea0c8668812bc0b3a4136606c10803e9) Signed-off-by: Jianfeng Liu <liujianfeng1994@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
Quentin Schulz [Fri, 24 May 2024 09:23:33 +0000 (11:23 +0200)]
rockchip: px30/rk3326: migrate to OF_UPSTREAM
Migrate PX30/RK3326 boards that exists in Linux v6.8 to use OF_UPSTREAM.
firefly-px30 is not migrated to OF_UPSTREAM because there's no Device
Tree in the Linux kernel.
Differences between U-Boot's Odroid-Go2 and Linux's are now moved to the
-u-boot.dtsi, though I have a gut feeling that the existing cru
overrides aren't necessary (anymore?).
The U-Boot GPIO led-0 is on GPIO0_C1 but such is the pin of PWM3 which
is used for Linux's PWM led-2 so keep Linux's.
I also doubt vcc_cam is actually used, though the Odroid-Go2 Black
Edition uses this dcdc regulator for WiFi, so let's just move it to the
-u-boot.dtsi to play it safe.
Quentin Schulz [Fri, 24 May 2024 09:23:32 +0000 (11:23 +0200)]
rockchip: evb-px30: make UART5 the debug UART
In the Device Tree, UART5 is the system UART, but in the defconfig it
currently is UART2. Let's sync the two by making the defconfig use UART5
as well.
Reviewed-by: Kever Yang <kever.yang@rock-chips.com> Signed-off-by: Quentin Schulz <quentin.schulz@cherry.de>
Quentin Schulz [Fri, 24 May 2024 09:23:30 +0000 (11:23 +0200)]
rockchip: px30: make UART pinmux accessible to TPL/SPL DTB
This adds the default pinmux for UART2 and UART5 to the TPL/SPL DTB (if
not removed through the CONFIG_OF_SPL_REMOVE_PROPS symbol) as those two
controllers are always made available to all boards.
Reviewed-by: Kever Yang <kever.yang@rock-chips.com> Signed-off-by: Quentin Schulz <quentin.schulz@cherry.de>
Quentin Schulz [Fri, 24 May 2024 09:23:29 +0000 (11:23 +0200)]
rockchip: px30-core-*: Use common bss and stack addresses
U-Boot proper pre-reloc is currently running out of memory on PX30
Ringneck and it is thus impossible to boot into U-Boot CLI. It is
assumed the same problem can be seen on other PX30 boards though I
cannot guarantee it since I don't have access to them.
Fix this by migrating to the common bss and stack addresses for PX30,
which drastically increases the size of the pre-reloc allocation pool (8
times bigger now). The memory layout in SPL and U-Boot proper now
match the other SoCs' using ROCKCHIP_COMMON_STACK_ADDR.
Reviewed-by: Kever Yang <kever.yang@rock-chips.com> Signed-off-by: Quentin Schulz <quentin.schulz@cherry.de>
Quentin Schulz [Fri, 24 May 2024 09:23:28 +0000 (11:23 +0200)]
rockchip: odroid-go2: Use common bss and stack addresses
U-Boot proper pre-reloc is currently running out of memory on PX30
Ringneck and it is thus impossible to boot into U-Boot CLI. It is
assumed the same problem can be seen on other PX30 boards though I
cannot guarantee it since I don't have access to them.
Fix this by migrating to the common bss and stack addresses for PX30,
which drastically increases the size of the pre-reloc allocation pool (8
times bigger now). The memory layout in SPL and U-Boot proper now
match the other SoCs' using ROCKCHIP_COMMON_STACK_ADDR.
Quentin Schulz [Fri, 24 May 2024 09:23:27 +0000 (11:23 +0200)]
rockchip: firefly-px30: Use common bss and stack addresses
U-Boot proper pre-reloc is currently running out of memory on PX30
Ringneck and it is thus impossible to boot into U-Boot CLI. It is
assumed the same problem can be seen on other PX30 boards though I
cannot guarantee it since I don't have access to them.
Fix this by migrating to the common bss and stack addresses for PX30,
which drastically increases the size of the pre-reloc allocation pool (8
times bigger now). The memory layout in SPL and U-Boot proper now
match the other SoCs' using ROCKCHIP_COMMON_STACK_ADDR.
Reviewed-by: Kever Yang <kever.yang@rock-chips.com> Signed-off-by: Quentin Schulz <quentin.schulz@cherry.de>
Quentin Schulz [Fri, 24 May 2024 09:23:26 +0000 (11:23 +0200)]
rockchip: evb-px30: Use common bss and stack addresses
U-Boot proper pre-reloc is currently running out of memory on PX30
Ringneck and it is thus impossible to boot into U-Boot CLI. It is
assumed the same problem can be seen on other PX30 boards though I
cannot guarantee it since I don't have access to them.
Fix this by migrating to the common bss and stack addresses for PX30,
which drastically increases the size of the pre-reloc allocation pool (8
times bigger now). The memory layout in SPL and U-Boot proper now
match the other SoCs' using ROCKCHIP_COMMON_STACK_ADDR.
Reviewed-by: Kever Yang <kever.yang@rock-chips.com> Signed-off-by: Quentin Schulz <quentin.schulz@cherry.de>
arch: arm: dts: k3-j721s2-r5: Override ospi and fss for 32-bit mode
R5 being a 32-bit processor can't understand the 64-bit mapping being
done in ospi node. Override the ospi node for 32-bit register ranges and
the fss node ( the parent node of ospi ) to map the ranges for the
updated child node correctly.
Pratyush Yadav [Tue, 4 Jun 2024 06:09:10 +0000 (11:39 +0530)]
mtd: spi-nor-core: Do not start or end writes at odd address in DTR mode
On DTR capable flashes like Micron Xcella the writes cannot start or end
at an odd address in DTR mode. Extra 0xff bytes need to be prepended or
appended respectively to make sure both the start and end addresses are
even.
* Allow specifying a device-tree in an EFI load option
using the efidebug or eficonfig command.
* Let the EFI boot manager fall back to an OS provided device-tree
if no device-tree is specified.
If no device-tree is specified, try to load a device-tree from the boot
device use the $fdtfile concatenated to either of the paths '/dtb/', '/',
'/dtb/current/'.
Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com> Reviewed-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
We already support creating a load option where the device-path
field contains the concatenation of the binary device-path and
optionally the device path of the initrd which we expose via the
EFI_LOAD_FILE2_PROTOCOL.
Allow to append another device-path pointing to the device-tree
identified by the device-tree GUID.
Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com> Reviewed-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
We already support creating a load option where the device-path
field contains the concatenation of the binary device-path and
optionally the device path of the initrd which we expose via the
EFI_LOAD_FILE2_PROTOCOL.
Allow to append another device-path pointing to the device-tree
identified by the device-tree GUID.
Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com> Reviewed-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
efi_loader: allow concatenation with contained end node
Allow appending a device-path to a device-path that contains an end node
as separator. We need this feature for creating boot options specifying
kernel, initrd, and dtb.
Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com> Reviewed-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
Brunham, Kalen [Fri, 17 May 2024 19:13:48 +0000 (19:13 +0000)]
Added arm64 assembly for examples/api crt0
I've encountered a problem when compiling the 'examples/api' directory for ARM64 in U-boot. The problem lies in the assembly code in 'examples/api/crt0.S' where the current CONFIG_ARM code is only 32-bit. When targeting ARM64, a 64-bit version is necessary.
I have proposed a fix by including a 'CONFIG_ARM64' section in the assembly code as shown below. These changes have been check via https://github.com/u-boot/u-boot/pull/538.
"For devices launching with Android 13, the generic ramdisk is removed
from the boot image and placed in a separate init_boot image.
This change leaves the boot image with only the GKI kernel."
While at it, update wrong error handling message when vendor_boot
cannot be loaded.
The boot_ramdisk and vendor_ramdisk must be both concatenated together.
Without this change, Android root is missing some of the necessary tools
to complete virtual AB OTA.
Signed-off-by: Roman Stratiienko <r.stratiienko@gmail.com> Reviewed-by: Mattijs Korpershoek <mkorpershoek@baylibre.com>
Ilias Apalodimas [Tue, 28 May 2024 06:18:27 +0000 (09:18 +0300)]
arm: move _end to linker symbols
commit 6e2228fb052b ("Merge patch series "Clean up arm linker scripts")
was cleaning up linker scripts for armv7 and v8 but was leaving
_end and __secure_stack_start/end.
commit d0b5d9da5de2 ("arm: make _end compiler-generated")
was moving _end to be compiler generated. _end is defined as c variable
in its own section to force the compiler emit relative a reference.
However, defining those in the linker script will do the same thing
since [0].
So let's remove the special sections from the linker scripts, the
variable definitions from sections.c and define them as a symbols.
It's worth noting that _image_binary_end symbol is now redundant and
can be removed in the future.
When decompressing, it's possible that the algorithm only performs
a partial decompression.
This usually happens when CONFIG_SYS_BOOTM_LEN is too small for
the uncompressed image.
When that happens, image_decomp() returns an error and *load_end == load.
The error is then handled by handle_decomp_error().
handle_decomp_error() expects the number of uncompressed bytes in
uncomp_size but receives *load_end - load == load - load == 0.
Because of this, handle_decomp_error does not report the expected
"Image too large: increase CONFIG_SYS_BOOTM_LEN" error message.
Modify the image_decomp() logic to always report the decompressed size,
even when a partial decompression happened.
Roger Quadros [Wed, 15 May 2024 12:20:08 +0000 (15:20 +0300)]
memory: ti-gpmc: use printf to dump settings/timings
pr_info() depends on CONFIG_LOGLEVEL > 6. If user has
enabled CONFIG_TI_GPMC_DEBUG then we should print the
GPMC settings/timings regardless of CONFIG_LOGLEVEL.
Daniel Schultz [Wed, 22 May 2024 07:21:00 +0000 (00:21 -0700)]
include: extension_board: Increase overlay file name size
Upstream overlays like the ARM64 TI
k3-am625-beagleplay-csi2-tevi-ov5640.dtso can easily have more then
32 characters. Increase the overlay length to 64 characters to
apply overlays with longer names.
Signed-off-by: Daniel Schultz <d.schultz@phytec.de> Acked-by: Kory Maincent <kory.maincent@bootlin.com>
Changes in v2:
- Reabse to current next
- Add Tested-by: John Ma <jma@phytec.com>
- Add Kconfig option to select RAM size statically
- Make board/phytec/common/k3 always compile for CONFIG_ARCH_K3
Wadim Egorov [Wed, 22 May 2024 07:55:05 +0000 (09:55 +0200)]
board: phytec: am62x: Add support for 1 & 4 GB RAM variants
Use content of EEPROM to detect the actual RAM size and adjust
DDR timings, size and banks accordingly.
Also enable the SoM detection per default in the defconfigs.
Signed-off-by: Wadim Egorov <w.egorov@phytec.de> Tested-by: John Ma <jma@phytec.com>
Tom Rini [Fri, 7 Jun 2024 20:02:02 +0000 (14:02 -0600)]
Merge patch series "PHYTEC SOM Detection API v3"
Daniel Schultz <d.schultz@phytec.de> says:
This patch series adds support for the EEPROM v3 API.
V3 is backwards compatible to V2 and therefore, the V2 image still
exists at the beginning. Only the API version changed from 2 to 3.
V3 is a block-based memory layout organized as singled-linked list
with different types of blocks. This is a more flexible approach and
allows us to extend it by more block types in the future.
The V3 data starts with a 8-byte large header which defines the
block count (u8), V3 subversion (u8) and data payload length (u16).
Additionally the header contains a CRC8 checksum a 3 reserved bytes.
Each block starts with a 4-byte large header which defined the
block type (u8), the absolute address of the next block (u16) and a
CRC8 checksum. The content itself is defined via the block type and
we currently have 2 different types:
1) MAC: Contains the Ethernet interface number (u8), MAC address
(6 x u8) and a CRC8 checksum.
Daniel Schultz [Wed, 22 May 2024 06:18:25 +0000 (23:18 -0700)]
board: phytec: common: Add API v3
This API is based on a block structure with a 8 Byte large
API v3 header and various of different blocks following. It extends
our current API v2, which is always 32 Byte large, and is located
directly after v2.
Add the MAC block as first block type. It contains the physical
Ehternet interface number, a MAC address and a CRC checksum over the
MAC payload.
Signed-off-by: Daniel Schultz <d.schultz@phytec.de> Tested-by: Wadim Egorov <w.egorov@phytec.de>
Daniel Schultz [Wed, 22 May 2024 06:18:24 +0000 (23:18 -0700)]
board: phytec: common: Move API v2 init to new function
Move the entire initialization code for API v2 into a dedicated
function. This rework will allow to easily integrate the API v3
as next step during init.
Signed-off-by: Daniel Schultz <d.schultz@phytec.de> Tested-by: Wadim Egorov <w.egorov@phytec.de>
The EEPROM image length for API v2 is fixed to 32 bytes. No need
to use sizeof while this value won't change. This value is
also be required for API v3 to know where the API v3 header starts.
Signed-off-by: Daniel Schultz <d.schultz@phytec.de> Tested-by: Wadim Egorov <w.egorov@phytec.de>
Daniel Schultz [Wed, 22 May 2024 06:18:22 +0000 (23:18 -0700)]
board: phytec: common: Move eeprom read to new function
We need to read multiple times from different offsets in API v3.
Move the EEPROM read logic into a dedicated function to make it
usable multiple times.
Signed-off-by: Daniel Schultz <d.schultz@phytec.de> Tested-by: Wadim Egorov <w.egorov@phytec.de>
Tom Rini [Fri, 7 Jun 2024 20:01:38 +0000 (14:01 -0600)]
Merge patch series "Add remoteproc support for J784S4 SoCs"
Beleswar Padhi <b-padhi@ti.com> says:
Hello All,
This series adds remoteproc support for TI's J784S4 SoCs. The K3 J784S4
SoCs have four dual-core R5F subsystems and four C71x DSP subsystems.
Enable the remoteproc drivers in defconfig and set the rproc firmware
names to add remoteproc support.
Note: No driver changes are required as J784S4 SoCs have the same data
as J721S2 SoCs. Thus, utilize the existing compatible string for driver
probe.
The K3 J784S4 SoC has four dual-core R5F subsystems and four C71x DSP
subsystems. Set config values to enable the remoteproc functionality
with these R5F and DSP subsystems.
Tom Rini [Fri, 7 Jun 2024 20:01:15 +0000 (14:01 -0600)]
Merge patch series "Adding support to load secure firmware for HS devices"
Udit Kumar <u-kumar1@ti.com> says:
Some use case needs rproc firmware to be loaded at u-boot stage,
using following commands at u-boot shell, firmware could be loaded
=> setenv dorprocboot 1
=> run boot_rprocs
For Secure devices, secure version of rproc firmware should be loaded,
which is appended by sec keyword[0].
but currently non-secure firmware is loaded even for secure devices.
So adding support for loading secure firmware on Secured devices.
Manorit Chawdhry [Tue, 21 May 2024 10:56:46 +0000 (16:26 +0530)]
drivers: remoteproc: ti_k3 : enable secure booting with firmware images
Remoteproc firmware images aren't authenticated in the current boot flow.
Authenticates remoteproc firmware images to complete the root of trust
in secure booting.
Signed-off-by: Manorit Chawdhry <m-chawdhry@ti.com> Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> # Intel Edison Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
Manorit Chawdhry [Tue, 21 May 2024 10:56:45 +0000 (16:26 +0530)]
include: mach-k3: move k3 security functions to security.h
ti_secure_image_post_process and ti_secure_image_check_binary is used
for the authentication purposes in the current boot flow. Authentication
of remoteproc firmware images require ti_secure_image_post_process to be
available outside mach-k3.
Signed-off-by: Manorit Chawdhry <m-chawdhry@ti.com> Signed-off-by: Udit Kumar <u-kumar1@ti.com> Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> # Intel Edison Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
Tom Rini [Fri, 7 Jun 2024 20:00:26 +0000 (14:00 -0600)]
Merge patch series "k3-j721e: Enable OF_UPSTREAM for J721E"
Neha Malcom Francis <n-francis@ti.com> says:
This series was plucked out from the larger series [1] that did some
templating reformatting and also enabled OF_UPSTREAM for J721E. The
former has been kept aside till all the platforms affected have moved to
using OF_UPSTREAM to have less conflicts while merging.
Patches split J721E EVM and J721E SK to using separate builds, as well
as enable OF_UPSTREAM for both the platforms.
Manually, since SysConfig tool do not have the relevant option,
set PHY_LP4_WDQS_OE_EXTEND to 1.
Since WDQS control mode is required on our modules LPDDR4,
this enables WDQS control mode 1.
Emanuele Ghidoli [Wed, 15 May 2024 08:00:58 +0000 (10:00 +0200)]
arm: dts: k3-am625-verdin: Enable LPDDR4 WDQS control
Manually, since SysConfig tool do not have the relevant option,
set PHY_LP4_WDQS_OE_EXTEND to 1.
Since WDQS control mode is required on our modules LPDDR4,
this enables WDQS control mode 1.
Update the autogenerated LPDDR4 configuration using the latest available
SysConfig tool.
This changes are cosmetic and are made to track the last used tool version.
Tom Rini [Fri, 7 Jun 2024 16:48:41 +0000 (10:48 -0600)]
Merge patch series "'eeprom' command improvements"
Marek Behún <kabel@kernel.org> says:
This series contains improvements for the 'eeprom' command:
- refactors
- fixes
- improvements
- ability to use driver model EEPROMs (uclass UCLASS_I2C_EEPROM)
- more flexible EEPROM layout support
It should not cause any behavior change for any existing board.
This series is a dependency for some DDR issue fixes for Turris Omnia.
I will be sending that one separately.
github PR link (with CI):
https://github.com/u-boot/u-boot/pull/540
- there is a failure for
test.py for sandbox sandbox_clang
but it seems unrelated to these changes
Marek Behún [Tue, 21 May 2024 07:13:35 +0000 (09:13 +0200)]
cmd: eeprom: Extend to EEPROMs probed via driver model
Extend the 'eeprom' command to allow accessing EEPROMs probed via
driver model, uclass UCLASS_I2C_EEPROM.
When the CONFIG_I2C_EEPROM config option is enabled (and so the
i2c-eeprom driver is built), the 'eeprom' command now accepts driver
model device name as EEPROM specifier for the 'eeprom' command, in
addition to the legacy [[bus] devaddr] specifier.
Moreover if no device specifier is given, then the first
UCLASS_I2C_EEPROM device is used, if found.
In preparation for allowing to access eeprom by driver-model device
name, refactor the eeprom device specifier parsing. Instead of filling
two parameters (i2c_bus, i2c_addr), the parsing function now fills one
parameter of type struct eeprom_dev_spec.
Marek Behún [Tue, 21 May 2024 07:13:30 +0000 (09:13 +0200)]
cmd: eeprom: Hide eeprom layout versioning behind a Kconfig option
Add a new Kconfig option EEPROM_LAYOUT_VERSIONS, and hide eeprom
layout versionsing code behind it. Only print the relevant help in
'eeprom' command usage if this option is enabled.
Enable this new option for cm_fx6_defconfig and cm_t43_defconfig.
These are the only boards using EEPROM layout versioning.
Marek Behún [Tue, 21 May 2024 07:13:29 +0000 (09:13 +0200)]
cmd: eeprom: Fix usage help for the eeprom command
The bus and devaddr arguments of the eeprom command are optional, and if
only one is given, it is assumed to be devaddr. Change the usage help
from
<bus> <devaddr>
to
[[bus] [devaddr]
Marek Behún [Tue, 21 May 2024 07:13:27 +0000 (09:13 +0200)]
common: eeprom_field: Fix updating binary field
The __eeprom_field_update_bin() function is expected to parse a hex
string into bytes (potentially in reverse order), but the
simple_strtoul() function is given 0 as base. This does not work since
the string does not contain '0x' prefix. Add explicit base 16.
Marek Behún [Tue, 21 May 2024 07:13:26 +0000 (09:13 +0200)]
common: eeprom_layout: Split field finding code from the field update function
Split the eeprom layout field finding code from the
eeprom_layout_update_field() function in order to make it usable in
alternative implementations of update method.
Marek Behún [Tue, 21 May 2024 07:13:25 +0000 (09:13 +0200)]
common: eeprom_layout: Assign default layout methods and parameters before specific ones
Assign the default eeprom layout parameter .data_size and methods
.print() and .update() before calling eeprom_layout_assign() in
eeprom_layout_setup().
This allows eeprom_layout_assign() to overwrite these if needed.
- Support different RAM sizes on imx8m phycoce boards.
- Support new toradex variants.
- Support Samsung 4GB DDR and Realtek RTL8211E PHY on imx8mm-cl-iot-gate.
- Convert imx8mm-phycore and imx8mp-phycore boards to use OF_UPSTREAM.
projects / u-boot.git / log
