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 <mikhail.kshevetskiy@iopsys.eu>
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 <mikhail.kshevetskiy@iopsys.eu>
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 <mikhail.kshevetskiy@iopsys.eu>
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 <mikhail.kshevetskiy@iopsys.eu>
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 <mikhail.kshevetskiy@iopsys.eu>
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 <mikhail.kshevetskiy@iopsys.eu>
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 <mikhail.kshevetskiy@iopsys.eu>
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 <mikhail.kshevetskiy@iopsys.eu>
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 <mikhail.kshevetskiy@iopsys.eu>
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 <mikhail.kshevetskiy@iopsys.eu>
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 <mikhail.kshevetskiy@iopsys.eu>
This option is only meaningful within the davinci nand driver, so drop
the statement here (which had no effect).
Signed-off-by: Tom Rini <trini@konsulko.com>
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 <mikhail.kshevetskiy@iopsys.eu>
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 <trini@konsulko.com>
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 <miquel.raynal@bootlin.com>
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 <marek.vasut@mailbox.org>
Reviewed-by: Patrice Chotard <patrice.chotard@foss.st.com>
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 <marek.vasut@mailbox.org>
Reviewed-by: Patrice Chotard <patrice.chotard@foss.st.com>
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 <marek.vasut@mailbox.org>
Reviewed-by: Patrice Chotard <patrice.chotard@foss.st.com>
Commit 6d91f0a3a1 ("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: 6d91f0a3a1 ("board: st: common: cleanup dfu support")
Signed-off-by: Marek Vasut <marek.vasut@mailbox.org>
Reviewed-by: Patrice Chotard <patrice.chotard@foss.st.com>
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 <marek.vasut@mailbox.org>
Reviewed-by: Patrice Chotard <patrice.chotard@foss.st.com>
Switch etzpc bus to simple-bus to prevent breakage on non-TFA systems.
This fixes boot of every STM32MP15xx DHSOM device.
Fixes: ad3cdc677d ("ARM: stm32mp: add ETZPC system bus driver for STM32MP1")
Signed-off-by: Marek Vasut <marek.vasut@mailbox.org>
Reviewed-by: Patrice Chotard <patrice.chotard@foss.st.com>
Add missing CPU_STM32MP255* cases in get_eth_nb() so that U-Boot
correctly reports 2 Ethernet interfaces on stm32mp255 devices.
This fixes the "ethernet not found" error during boot.
Signed-off-by: Md Asadullah <md.asadullah@eds-india.com>
Initially there was only one DSI bridge with one panel attached to this
device. This explained the call to uclass_first_device_err(UCLASS_PANEL,
...) which worked fine at the time.
Now that multiple bridges and panels, with different technologies, can
be plugged onto the board this way to get the panel device is outdated.
The lookup is done is two steps. First we circle through the
UCLASS_VIDEO_BRIDGE, and once we get one, we search through its
endpoints until we get a UCLASS_PANEL device available.
Acked-by: Yannick Fertre <yannick.fertre@foss.st.com>
Signed-off-by: Raphael Gallais-Pou <raphael.gallais-pou@foss.st.com>
Reviewed-by: Patrice Chotard <patrice.chotard@foss.st.com>
STM32MP2 SoCs feature a new version of the LTDC IP. This new version
features a bus clock, as well as a 150MHz pad frequency. Add its
compatible to the list of device to probe and handle quirks. The new
hardware version features a bus clock.
Reviewed-by: Patrice Chotard <patrice.chotard@foss.st.com>
Acked-by: Yannick Fertre <yannick.fertre@foss.st.com>
Signed-off-by: Raphael Gallais-Pou <raphael.gallais-pou@foss.st.com>
The LVDS Display Interface Transmitter handles the LVDS protocol:
it maps the pixels received from the upstream Pixel-DMA (LTDC)
onto the LVDS PHY.
The LVDS controller driver supports the following high-level features:
• FDP-Link-I and OpenLDI (v0.95) protocols
• Single-Link or Dual-Link operation
• Single-Display or Double-Display (with the same content
duplicated on both)
• Flexible Bit-Mapping, including JEIDA and VESA
• RGB888 or RGB666 output
• Synchronous design, with one input pixel per clock cycle
• No resolution limitation.
Acked-by: Yannick Fertre <yannick.fertre@foss.st.com>
Signed-off-by: Raphael Gallais-Pou <raphael.gallais-pou@foss.st.com>
Add the compatible "panel-lvds" for simple-panel driver in U-Boot. In
Linux this compatible is managed by the driver
drivers/gpu/drm/panel/panel-lvds.c but in U-Boot the specific LVDS
features (bus_format/bus_flags) are not supported.
Reviewed-by: Patrice Chotard <patrice.chotard@foss.st.com>
Reviewed-by: Yannick Fertre <yannick.fertre@foss.st.com>
Signed-off-by: Raphael Gallais-Pou <raphael.gallais-pou@foss.st.com>
The "Display Timings" in panel-common.yaml can be provided by 2 properties
- panel-timing: when display panels are restricted to a single resolution
the "panel-timing" node expresses the required timings.
- display-timings: several resolutions with different timings are supported
with several timing subnode of "display-timings" node
This patch update the parsing function to handle this 2 possibility
when index = 0.
Reviewed-by: Patrice Chotard <patrice.chotard@foss.st.com>
Reviewed-by: Yannick Fertre <yannick.fertre@foss.st.com>
Signed-off-by: Raphael Gallais-Pou <raphael.gallais-pou@foss.st.com>
Add st,adc_usb_pd property in /config node for stm32mp135-dk-u-boot.
This needed to check board USB power delivery.
Signed-off-by: Patrice Chotard <patrice.chotard@foss.st.com>
Reviewed-by: Patrick Delaunay <patrick.delaunay@foss.st.com>
Add support of STM32 ADCs to STM32MP13x. This patch introduces
stm32_adc_regspec structure, as this is already done in kernel
driver, to manage smartly the differences in register set
between STMP32MP15 and STM32MP13 ADCs.
Signed-off-by: Olivier Moysan <olivier.moysan@foss.st.com>
Signed-off-by: Patrice Chotard <patrice.chotard@foss.st.com>
Reviewed-by: Patrick Delaunay <patrick.delaunay@foss.st.com>
OP-TEE "arm,smc-id" is equal to 0xbc000000 but kernel DT has been
upstream with an incorrect value.
Fix it temporarily until kernel DT is fixed.
Signed-off-by: Patrice Chotard <patrice.chotard@foss.st.com>
Reviewed-by: Patrick Delaunay <patrick.delaunay@foss.st.com>
OP-TEE "arm,smc-id" is equal to 0xbc000000 but kernel DT has been
upstream with an incorrect value.
Fix it temporarily until kernel DT is fixed.
Signed-off-by: Patrice Chotard <patrice.chotard@foss.st.com>
Reviewed-by: Patrick Delaunay <patrick.delaunay@foss.st.com>
Pull request efi-2026-01-rc3
CI:
* https://source.denx.de/u-boot/custodians/u-boot-efi/-/pipelines/28355
Documentation:
* Correct the linux/arm64 platform string for Docker builds
* Complete pytest dependencies list with missing packages
UEFI:
* Use Sphinx style comments in efi_selftest_console.c
* Don't include asm/global_data.h in lib/efi_client/efi_app.c twice
* efi_client: correct memset() return value
* Assure fitImage from capsule is used from 8-byte aligned address
* Fix warning when building efi_selftest_snp with clang
The fitImage may be stored in EFI update capsule at address that
is not aligned to 8 bytes. Since fitImage is a DT, new version of
libfdt 1.7.2 rejects such an unaligned DT. Patch the code and copy
the fitImage into aligned buffer in case it is not aligned. This
does increase overhead for unaligned fitImages in EFI capsules, but
tries to keep the overhead low for aligned ones.
Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
Reviewed-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
When building with clang, we see a warning:
lib/efi_selftest/efi_selftest_snp.c:63:18: error: field dhcp_hdr within
'struct dhcp' is less aligned than 'struct dhcp_hdr' and is usually due
to 'struct dhcp' being packed, which can lead to unaligned accesses
[-Werror,-Wunaligned-access]
when building lib/efi_selftest/efi_selftest_snp.c. Resolve this error by
packing struct dhcp_hdr as well, as the only place it is used also is
packed.
Signed-off-by: Tom Rini <trini@konsulko.com>
Reviewed-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
Memset() must return a pointer to the start of the updated memory block.
Fixes: 476476e73b ("efi: Add support for loading U-Boot through an EFI stub")
Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
Convert function comments in efi_selftest_console.c to match
Sphinx style.
Correct function name in print_uuid() comment.
Acked-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
