| Age | Commit message (Collapse) | Author |
|---|
|
Add a test suite exercising the whole lifetime and callbacks
of interconnect with a fake 5 providers with a split node graph.
The test suite checks the calculus are right and goes to the correct
nodes, and the lifetime of the node is correct.
Link: https://patch.msgid.link/[email protected]
Signed-off-by: Neil Armstrong <[email protected]>
|
|
Let's introduce the Generic System Interconnect subsystem based on
the counterpart Linux framework which is used to vote for bandwidth
across multiple SoC busses.
Documentation for the Linux Generic System Interconnect Subsystem can
be found at [1].
Each bus endpoints are materialised as "nodes" which are linked together,
and the DT will specify a pair of nodes to enable and set a bandwidth
on the route between those endpoints.
The hardware resources that provide those nodes and provides the way
to vote for the bandwidth are called "providers".
The Interconnect uclass code is heavily based on the Linux one, with
some small differences:
- nodes are allocated as udevices instead of Linux idr_alloc()
- tag management is minimal, only normal xlate is supported
- getting nodes states at probe is not implemented
- providers are probed on demand while the nodes links are traversed
- nodes are populated on bind
- id management is simplified, static IDs and dynamics IDs can be used
- identical consume API as Linux, only implementation differs
Fully tested with associated DM test suite.
[1] https://docs.kernel.org/driver-api/interconnect.html
Link: https://patch.msgid.link/[email protected]
Signed-off-by: Neil Armstrong <[email protected]>
|
|
https://source.denx.de/u-boot/custodians/u-boot-ufs
- Sort again the UFS Kconfig & Makefile
- Use unique name for the rcar-gen5 ufs driver
|
|
https://source.denx.de/u-boot/custodians/u-boot-microblaze
CI: https://source.denx.de/u-boot/custodians/u-boot-microblaze/-/pipelines/28413
AMD/Xilinx/FPGA changes for v2026.01-rc3
- Align brcp1 boot.bin location
- Fix MB-V compilation warning when AXI enet is enabled
|
|
https://source.denx.de/u-boot/custodians/u-boot-nand-flash
CI: https://source.denx.de/u-boot/custodians/u-boot-nand-flash/-/pipelines/28408
This pull request enhances NAND and SPI flash support, primarily
focusing on the Airoha EN7523 platform. The Airoha SPI driver receives
a major update, adding DMA, dual/quad-wire modes, and a critical
workaround to prevent flash damage if the UART_TXD pin shorts to Ground.
New chips supported include FudanMicro FM25S01A SPI-NAND and several
Winbond SPI NOR devices. Fixes include correcting Kconfig dependencies,
updating the mtd benchmark command to use lldiv(), and addressing minor
bugs in the generic spi-mem and SPL NAND code.
|
|
Fix compiler warnings about casting integers to pointers of different
sizes by using uintptr_t as intermediate type. This ensures proper
type conversion across 32-bit and 64-bit architectures.
Signed-off-by: Sai Varun Venkatapuram <[email protected]>
Signed-off-by: Michal Simek <[email protected]>
Link: https://lore.kernel.org/r/11b1d9b1a5589d06cff724e807832f366794c075.1762510401.git.michal.simek@amd.com
|
|
The ROM code of Xilinx Zynq searches the boot flash for a "BootROM header"
at increments of 32k (0x8000), beginning with 0x0000 for a
configuration without authentication and beginning with 0x8000
for a configuration with authentication. [1]
Move the offset of the SPL partition on the brcp1 board to 0x8000
so that both cases are the same, e.g. a board that is configured
without authentication can boot an SPL partition with or without
authentication.
[1] Zynq 7000 TRM, section 6.3 "BootROM Code"
Signed-off-by: Wolfgang Wallner <[email protected]>
Signed-off-by: Michal Simek <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
|
|
Use 'Sam Protsenko' as my name consistently in git-shortlog. Also map my
home email address (which I used at some point) to my current work
email.
Signed-off-by: Sam Protsenko <[email protected]>
|
|
The Linaro email address is no longer valid.
See commit 4cad9faf8d28 ("MAINTAINERS: update my email address")
Signed-off-by: Heinrich Schuchardt <[email protected]>
|
|
reserved-memory nodes
I've spent time trying to figure out why my board (Rockchip PX30-based)
suddenly boot loops when running a specific program in Linux userspace
after working on a U-Boot upgrade. I actually inadvertently had the TEE
environment variable set for a device which doesn't actually need to run
any TEE OS (so had OPTEE_LIB disabled).
It is currently possible to build an image with an OP-TEE OS (via the
TEE environment variable) without OPTEE_LIB. U-Boot will happily load
the TEE OS and the next OS (e.g. the Linux kernel).
This is an issue because on FDT-enabled devices, OP-TEE OS adds nodes to
the reserved-memory FDT node for the memory regions it just reserved for
itself. This updated FDT is then passed to U-Boot proper which should
know better not to use memory from there. The actual issue is that
without OPTEE_LIB and OF_LIBFDT enabled, U-Boot proper will not copy
those nodes over to the next OS's FDT before starting it. This results
in the next OS's (e.g. Linux kernel) to not be aware of reserved memory,
incurring random crashes or device reboots when it tries to access
secure reserved memory area.
On Rockchip, the U-Boot FIT image which contains both the TEE OS and
U-Boot proper is generated by binman. Unfortunately, binman doesn't seem
to have access to Kconfig symbols (grep CONFIG_ doesn't return anything
meaningful and binman is either configured through FDT nodes or via CLI
arguments, c.f. cmd_binman in the root Makefile) so we cannot try to be
smart and guide the user to the correct Kconfig option to select if TEE
is set. We could add a property based on the presence of OPTEE_LIB in
rockchip-u-boot.dtsi for example and have a custom message based on
that, the issue is that I assume all FDT-based platforms do actually
need to do this dance, and not only Rockchip.
Another option could be to add a CLI argument to binman through which
we would pass the state of OPTEE_LIB and error out the build in that
case, but that feels like opening the door to other various dirty hacks.
Another option is to propagate the TEE environment variable to the
preprocessor of the FDT (via dtc_cpp_flags) and then we can do
#if defined(TEE) && !IS_ENABLED(CONFIG_OPTEE_LIB)
#error "CONFIG_OPTEE_LIB must be enabled!"
#endif
but we have the same issue as above, it is then Rockchip-specific and
doesn't feel right to me.
Yet another option is to remove the @tee-SEQ node from the binman FIT
description when OPTEE_LIB isn't set but then we would lose the
following nice message when no TEE is provided:
Image 'simple-bin' is missing optional external blobs but is still functional: tee-os
and even worse, build without any TEE OS even though we could provide
one via the TEE environment variable.
Finally, another option could be to move this hack under
arch/arm/mach-rockchip/Kconfig to make it Rockchip-specific or add a
depends on ARCH_ROCKCHIP. However OP-TEE OS on Aarch32 Rockchip boards
doesn't actually need any of that if SPL_OPTEE_IMAGE is set because
arch/arm/mach-rockchip/sdram.c then marks some hardcoded memory regions
in RAM as holes in DRAM, which has the same effect as reserved memory
regions I guess. I assume other platforms may use something different,
so it may be casting too wide of a net.
This commit is what I could come up with as a stopgap measure to avoid
building images that simply cannot reliably work and fail randomly.
Signed-off-by: Quentin Schulz <[email protected]>
|
|
When building with clang, we see warnings such as:
error: field max_size within 'struct smbios_type7' is less aligned than
'union cache_size_word' and is usually due to 'struct smbios_type7'
being packed, which can lead to unaligned accesses
[-Werror,-Wunaligned-access]
when building drivers/sysinfo/smbios.c. Resolve this error by packing
the unions as well after verifying they are complete (16 or 32 bits).
Reviewed-by: Raymond Mao <[email protected]>
Reviewed-by: Ilias Apalodimas <[email protected]>
Signed-off-by: Tom Rini <[email protected]>
|
|
CROSS_COMPILE handling"
Dmitrii Sharshakov <[email protected]> says:
Initially fix the inconsistency reported in reply to the previous
series and also make sure AArch64 images can be built with latest
Clang versions by guarding AArch32-specific options behind extra
config checks.
Tested qemu_arm_defconfig and qemu_arm64_defconfig with Clang 21,
mainline (to be 22) ce7f9f9c and also Clang 18 (for AArch64 only, as I
have not managed to build an AArch32 image with clang-18).
Link: https://lore.kernel.org/r/[email protected]
|
|
Clang is strict with respect to unknown options.
Therefore, only enable AArch32-specific options when CONFIG_ARM64
is not set.
Signed-off-by: Dmitrii Sharshakov <[email protected]>
|
|
Clang cross-compilation worked when cross binutils were available
in PATH. However, when binutils are not in the PATH clang failed to
discover the assembler, falling back to host one.
Make --prefix always absolute, Clang supports this and will search for
e.g. $(prefix)-as for assembler. This makes sure user does not have to
add cross binutils to PATH for Clang build.
Fixes build for these examples (with qemu_arm(64)_defconfig):
make CC=clang-21 CROSS_COMPILE=/.../bin/arm-none-eabi-
make CC=clang-20 CROSS_COMPILE=/.../bin/aarch64-linux-gnu-
Also validated for the case when provided with cross toolchain on PATH:
PATH=/.../bin:$PATH make CC=clang-21 CROSS_COMPILE=arm-none-eabi- -j20
This patch does not affect GCC builds, and they have _not_ been
validated against regressions.
Reported-by: Tom Rini <[email protected]>
Closes: https://lore.kernel.org/u-boot/20251106221355.GZ6688@bill-the-cat/
Signed-off-by: Dmitrii Sharshakov <[email protected]>
|
|
We found that some serial console may pull TX line to GROUND during board
boot time. Airoha uses TX line as one of it's BOOT pins. This will lead
to booting in RESERVED boot mode.
It was found that some flashes operates incorrectly in RESERVED mode.
Micron and Skyhigh flashes are definitely affected by the issue,
Winbond flashes are NOT affected.
Details:
--------
DMA reading of odd pages on affected flashes operates incorrectly. Page
reading offset (start of the page) on hardware level is replaced by 0x10.
Thus results in incorrect data reading. Usage of UBI make things even
worse. Any attempt to access UBI leads to ubi damaging. As result OS loading
becomes impossible.
Non-DMA reading is OK.
This patch detects booting in reserved mode, turn off DMA and print big
fat warning.
Signed-off-by: Mikhail Kshevetskiy <[email protected]>
|
|
The spinand driver do 3 type of dirmap requests:
* read/write whole flash page without oob
(offs = 0, len = page_size)
* read/write whole flash page including oob
(offs = 0, len = page_size + oob_size)
* read/write oob area only
(offs = page_size, len = oob_size)
The trick is:
* read/write a single "sector"
* set a custom sector size equal to offs + len. It's a bit safer to
round up "sector size" value 64.
* set the transfer length equal to custom sector size
And it works!
Thus we can find all data directly from dirmap request, so flash specific
parameters is not needed anymore. Also
* airoha_snand_nfi_config(),
* airoha_snand_nfi_setup()
functions becomes unnecessary.
Signed-off-by: Mikhail Kshevetskiy <[email protected]>
|
|
Set custom sector size equal to flash page size including oob. Thus we
will always read a single sector. The maximum custom sector size is
8187, so all possible flash sector sizes are supported.
This patch is a necessary step to avoid usage of flash specific
parameters.
Signed-off-by: Mikhail Kshevetskiy <[email protected]>
|
|
REG_SPI_NFI_SECCUS_SIZE registers
This just reduce the number of modification of REG_SPI_NFI_CNFG and
REG_SPI_NFI_SECCUS_SIZE registers during dirmap operation.
This patch is a necessary step to avoid usage of flash specific
parameters.
Signed-off-by: Mikhail Kshevetskiy <[email protected]>
|
|
spi-airoha-snfi uses custom sector size in REG_SPI_NFI_SECCUS_SIZE
register, so setting of page/oob sizes in REG_SPI_NFI_PAGEFMT is not
required.
Signed-off-by: Mikhail Kshevetskiy <[email protected]>
|
|
it should work properly after the airoha-snfi driver patches
Signed-off-by: Mikhail Kshevetskiy <[email protected]>
|
|
During writing, the entire flash page (including OOB) will be updated
with the values from the temporary buffer, so we need to fill the
untouched areas of the buffer with 0xff value to prevent accidental
data overwriting.
Signed-off-by: Mikhail Kshevetskiy <[email protected]>
|
|
Airoha snfi spi controller supports acceleration of DUAL/QUAD
operations, but does not supports DUAL_IO/QUAD_IO operations.
Luckily DUAL/QUAD operations do the same as DUAL_IO/QUAD_IO ones,
so we can issue corresponding DUAL/QUAD operation instead of
DUAL_IO/QUAD_IO one.
Signed-off-by: Mikhail Kshevetskiy <[email protected]>
|
|
This driver can accelerate single page operations only, thus
continuous reading mode should not be used.
Continuous reading will use sizes up to the size of one erase block.
This size is much larger than the size of single flash page. Use this
difference to identify continuous reading and return an error.
Signed-off-by: Mikhail Kshevetskiy <[email protected]>
|
|
This patch speed up cache reading/writing/updating opearions.
It was tested on en7523/an7581 and some other Airoha chips.
It will speed up
* page reading/writing without oob
* page reading/writing with oob
* oob reading/writing (significant for UBI scanning)
The only know issue appears in a very specific conditions for en7523 family
chips only.
Signed-off-by: Mikhail Kshevetskiy <[email protected]>
|
|
Booting without this patch and disabled dirmap support results in
[ 2.980719] spi-nand spi0.0: Micron SPI NAND was found.
[ 2.986040] spi-nand spi0.0: 256 MiB, block size: 128 KiB, page size: 2048, OOB size: 128
[ 2.994709] 2 fixed-partitions partitions found on MTD device spi0.0
[ 3.001075] Creating 2 MTD partitions on "spi0.0":
[ 3.005862] 0x000000000000-0x000000020000 : "bl2"
[ 3.011272] 0x000000020000-0x000010000000 : "ubi"
...
[ 6.195594] ubi0: attaching mtd1
[ 13.338398] ubi0: scanning is finished
[ 13.342188] ubi0 error: ubi_read_volume_table: the layout volume was not found
[ 13.349784] ubi0 error: ubi_attach_mtd_dev: failed to attach mtd1, error -22
[ 13.356897] UBI error: cannot attach mtd1
If dirmap is disabled or not supported in the spi driver, the dirmap requests
will be executed via exec_op() handler. Thus, if the hardware supports
dual/quad spi modes, then corresponding requests will be sent to exec_op()
handler. Current driver does not support such requests, so error is arrised.
As result the flash can't be read/write.
This patch adds support of dual and quad wires spi modes to exec_op() handler.
Signed-off-by: Mikhail Kshevetskiy <[email protected]>
|
|
This operation is not needed because airoha_snand_write_data() and
airoha_snand_read_data() will properly handle data transfers above
SPI_MAX_TRANSFER_SIZE.
Signed-off-by: Mikhail Kshevetskiy <[email protected]>
|
|
Coverity finds a potential integer overflow in the following code:
ncycles += ((op->data.nbytes * 8) / op->data.buswidth) / (op->data.dtr ? 2 : 1);
A quick analysis shows that the only caller of the suspicious code is the
spinand_select_op_variant() function from the drivers/mtd/nand/spi/core.c
file.
According to the code the value of op->data.nbytes is equal to
nanddev_per_page_oobsize(nand) + nanddev_page_size(nand)
Therefore it's maximum value a bit larger than 4Kb (I never seen flashes
with page size large than 4Kb). So op->data.nbytes always fits within
13 bits. As result an overflow will never happen.
Anyway it's better fix an issue to eliminate the error message.
Signed-off-by: Mikhail Kshevetskiy <[email protected]>
|
|
This option is only meaningful within the davinci nand driver, so drop
the statement here (which had no effect).
Signed-off-by: Tom Rini <[email protected]>
|
|
Add support for FudanMicro FM25S01A SPI NAND.
This driver is ported from linux v6.18 and tested on a MT7981 board.
Link: https://lore.kernel.org/linux-mtd/[email protected]/
Reviewed-by: Mikhail Kshevetskiy <[email protected]>
Signed-off-by: Tianling Shen <[email protected]>
|
|
%s/destintion/destination/
Signed-off-by: Heinrich Schuchardt <[email protected]>
Reviewed-by: Bin Meng <[email protected]>
|
|
As was noted by Heinrich Schuchardt, some SoCs may not support 64-bit
divisions. Fix an issue by using lldiv() instead.
The code assumes that the benchmark never takes more than 4294 seconds
and thus the difference will be less than U32_MAX.
Also replace (speed / 1024) by (speed >> 10) to avoid potential 64-bit
division.
Signed-off-by: Mikhail Kshevetskiy <[email protected]>
|
|
The hidden symbol SPL_SYS_NAND_SELF_INIT was not being used correctly
leading to Kconfig dependency issues seen with "make allyesconfig". As
it's a select'd symbol we don't need to have a depends line on it, and
then in turn we need to also update the logic on SYS_NAND_PAGE_SIZE and
SYS_NAND_OOBSIZE.
Signed-off-by: Tom Rini <[email protected]>
|
|
All these chips are dual and quad capable. They are also DTR capable,
but the core is not yet ready for that.
Performances of all chips are comparable at 30MHz and are as follow:
Eraseblock single read speed: 938kiB/s
Eraseblock dual read speed: 1068kiB/s
Eraseblock quad read speed: 3751kiB/s
Signed-off-by: Miquel Raynal <[email protected]>
|
|
Rasmus Villemoes <[email protected]> says:
Implement a "part name" subcommand, mirroring the existing "part
number" subcommand.
In the discussion for v1 of that, it came up that there's a bit of
inconsistency in how much and what one can assume to be initialized in
'struct disk_partition' after a successful call of one of the
get_info* family of functions. Patch 1/2 tries to consolidate
that by making sure all ->get_info invocations go through a common
helper that at least always initializes the string members.
Quentin, I've taken the liberty of including your Acks, as the
incremental diff in patch 1 is quite minor, but do speak up if I
should not have done that.
Link: https://lore.kernel.org/r/[email protected]
|
|
This is a natural buddy to the existing "part number", allowing one to
get the partition name for a given partition number.
Acked-by: Quentin Schulz <[email protected]>
Signed-off-by: Rasmus Villemoes <[email protected]>
Acked-by: Quentin Schuloz <[email protected]>
Tested-by: Anshul Dalal <[email protected]>
|
|
successful get_info
Not all ->get_info implementations necessarily populate all the string
members of struct disk_partition.
Currently, only part_get_info_by_type() (and thereby part_get_info)
ensure that the uuid strings are initialized; part_get_info_by_type()
and part_get_info_by_uuid() do not. In fact, the latter could lead to
a false positive match - if the ->get_info backend does not populate
info->uuid, stale contents in info could cause the strncasecmp() to
succeed.
None of the functions currently ensure that the ->name and ->type
strings are initialized.
Instead of forcing all callers of any of these functions to
pre-initialize info, or all implementations of the ->get_info method
to ensure there are valid C strings in all four fields, create a small
helper function and factor all invocations of ->get_info through that.
This also consolidates the -ENOSYS check and standardizes on using
log_debug() for reporting absence, instead of the current mix of
PRINTF and log_debug(). It does mean we have to special-case -ENOSYS
in the error cases inside the loops in the _by_uuid() and _by_name()
functions, but it's still a net win in #LOC.
Acked-by: Quentin Schulz <[email protected]>
Signed-off-by: Rasmus Villemoes <[email protected]>
Tested-by: Anshul Dalal <[email protected]>
|
|
Philippe Schenker <[email protected]> says:
This series fixes compilation errors when building for R5 cores and
addresses a security issue where authenticated images were not being
used correctly.
Patch 1: Cosmetic removal of duplicate code
Patches 2-3: Fix build errors caused by type mismatches between
function signatures and the types used in R5 builds.
Patches 4-5: fix a bug where ti_secure_image_post_process() relocates
images during authentication, but callers were still using the original
unverified addresses.
Patch 6: Implements is_running operation to allow querying R5F core status.
Link: https://lore.kernel.org/r/[email protected]
|
|
Add is_running callback to query the R5F core halt status via the
TI-SCI processor control API. This allows the remoteproc framework
to determine whether the R5F core is currently runnin.
The core is considered running when the PROC_BOOT_CTRL_FLAG_R5_CORE_HALT
bit is not set in the control flags.
Signed-off-by: Philippe Schenker <[email protected]>
Reviewed-by: Andrew Davis <[email protected]>
|
|
After ti_secure_image_post_process() authenticates the image, it may
relocate it to a different memory location and update image_addr to
point to the verified image.
However, rproc_elf_load_image() and rproc_elf_get_boot_addr() were
still using the original "addr" parameter, potentially operating on
the unverified or stale image location instead of the authenticated
image.
Use image_addr (cast to ulong to match function signatures) after
authentication to ensure all operations work with the verified image.
Signed-off-by: Philippe Schenker <[email protected]>
|
|
The ti_secure_image_check() function may relocate the image during
authentication, updating image_addr to point to the verified location.
The caller was not updated with this new address, causing it to
reference the original unverified location.
Update p_image with the verified image address after authentication
to ensure subsequent operations use the correct location.
Signed-off-by: Philippe Schenker <[email protected]>
|
|
When compiling for R5 with CONFIG_TI_PRUSS enabled, the
pruss_probe() function passed a u64* to ofnode_get_addr_size_index(),
which expects an fdt_size_t*. This caused a compiler error
about incompatible pointer types.
Cast the size pointer to fdt_size_t* to match the function
signature.
Signed-off-by: Philippe Schenker <[email protected]>
|
|
When compiling for R5 core with CONFIG_REMOTEPROC_TI_K3_R5F,
passing 'size' (ulong) to ti_secure_image_post_process() caused
a type mismatch compiler error.
On platforms where ulong and size_t differ in size, directly
casting could lead to out-of-bounds memory access. Fix by
introducing a size_t temporary variable, passing it to the
function, and writing back the potentially modified value for
use in subsequent calls.
Signed-off-by: Philippe Schenker <[email protected]>
Acked-by: Andrew Davis <[email protected]>
|
|
The device tree contained a duplicate DT node 'main_mmc1_pins_default',
which was already defined a few lines below. This patch removes the
redundant entry.
Signed-off-by: Philippe Schenker <[email protected]>
Reviewed-by: Anshul Dalal <[email protected]>
|
|
Partially reverted commit "soc: qcom: cmd-db: drop unused
functions" by restoring only the cmd_db_read_slave_id() and
cmd_db_read_aux_data() functions, which were removed in that
commit. These functions are required for the RPMH Power Domain
Driver.
Reviewed-by: Neil Armstrong <[email protected]>
Reviewed-by: Casey Connolly <[email protected]>
Signed-off-by: Balaji Selvanathan <[email protected]>
Signed-off-by: Aswin Murugan <[email protected]>
Reviewed-by: Casey Connolly <[email protected]>> ---
Link: https://patch.msgid.link/[email protected]
Signed-off-by: Neil Armstrong <[email protected]>
|
|
https://source.denx.de/u-boot/custodians/u-boot-stm
CI: https://source.denx.de/u-boot/custodians/u-boot-stm/-/pipelines/28392
dhelectronics:
- Move dh_add_item_number_and_serial_to_env() to common code
- Read values from M24256 write-lockable page on STM32MP13xx DHCOR
- Add MAC address readout from fuses on DH STM32MP1 DHSOM
- Keep the reg11 and reg18 regulators always enabled on STM32MP13xx DHCOR.
- Fix boot for stm32mp15xx-dhsom.
- Fix build of ST DFU virt code on DH STM32MP1 DHSOM
- Introduce DH STM32MP13x target.
STM32MP2:
- Add support for stm32mp257-dk board.
- Fix arm, smc-id value for stm32mp23/25.
- Fix stm32mp235f-dk boot (add syscon compatible, add txbyteclk).
- Add display support:
- Introduce LVDS driver.
- Add LTDC support.
- Add Ethernet support for stm32mp255.
STM32MP13:
- Add ADC support.
- Add power check for stm32mp135f-dk board.
|
|
Add support for reading out the MAC address from SoC fuses on DH STM32MP1 DHSOM.
The DH STM32MP1 DHSOM may contain external ethernet MACs, which benefit from the
MAC address stored in SoC fuses as well, handle those consistently. This however
means the architecture setup_mac_address() cannot be used and instead a simpler
local fuse read out is implemented in the board file.
Signed-off-by: Marek Vasut <[email protected]>
Reviewed-by: Patrice Chotard <[email protected]>
|
|
The STM32MP13xx DHCOR SoM is populated with M24256 EEPROM that contains
an additional write-lockable page called ID page, which is populated with
a structure containing ethernet MAC addresses, DH item number and DH serial
number.
Read out the MAC address from the WL page between higher priority SoC fuses
and lower priority plain EEPROM storage area. Read out the DH item and serial
numbers and set environment variables accordingly.
Signed-off-by: Marek Vasut <[email protected]>
Reviewed-by: Patrice Chotard <[email protected]>
|
|
Move dh_add_item_number_and_serial_to_env() to common code, so it
can be used by both STM32MP13xx and iMX8MP DHSOM. No functional
change.
Signed-off-by: Marek Vasut <[email protected]>
Reviewed-by: Patrice Chotard <[email protected]>
|
|
Commit 6d91f0a3a14d ("board: st: common: cleanup dfu support") split
the vendor-specific DFU implementation into two files, but failed to
update other non-ST boards. This did not lead to noticeable breakage
with plain simple dfu-util, but it makes the ST proprietary programmer
CLI tool end in an infinite loop. Update the Makefile accordingly to
allow even that kind of tooling to work.
Fixes: 6d91f0a3a14d ("board: st: common: cleanup dfu support")
Signed-off-by: Marek Vasut <[email protected]>
Reviewed-by: Patrice Chotard <[email protected]>
|
|
Split the DH STM32MP13x based boards from ST STM32MP13x target,
this way the DH board specific code can be reused for STM32MP13x
DHSOM.
Signed-off-by: Marek Vasut <[email protected]>
Reviewed-by: Patrice Chotard <[email protected]>
|
