Teresa Remmet [Thu, 17 Aug 2023 08:57:06 +0000 (10:57 +0200)]
board: phytec: Add common PHYTEC SoM detection
Recent shipped PHYTEC SoMs come with an i2c EEPROM containing
information about the hardware such as board revision and variant.
This can be used for RAM detection and loading device tree overlays
during kernel start.
Eduard Strehlau [Tue, 10 Oct 2023 14:14:12 +0000 (11:14 -0300)]
smegw01: Remove misuse of CONFIG_ENV_IS_NOWHERE
When using a list of writeable variables, the initial values come
from the built-in default environment since commit 5ab81058364b ("env:
Complete generic support for writable list").
Remove unnecessary misuse of CONFIG_ENV_IS_NOWHERE as default environment.
Based on the fix done by commit b16fd7f75f6d ("imx6q: acc: Remove misuse
of env is nowhere driver").
Signed-off-by: Eduard Strehlau <eduard@lionizers.com> Signed-off-by: Fabio Estevam <festevam@denx.de>
Fabio Estevam [Mon, 9 Oct 2023 13:15:35 +0000 (10:15 -0300)]
usb: ehci: mxs: Use regulator_set_enable_if_allowed()
Since commit 4fcba5d556b4 ("regulator: implement basic reference
counter") the return value of regulator_set_enable() may be EALREADY or
EBUSY for fixed/GPIO regulators.
Switch to using the more relaxed regulator_set_enable_if_allowed() to
continue if regulator already was enabled or disabled.
This fixes the following error when running the 'ums' command:
Extend the padding process of u-boot-nand.imx target by adding 10k bytes
of zeros to the end of the binary using the 'dd' command.
The existing padding method did not generate a functional binary,
as discussed in more detail in this thread [1]. Instead, we adopt the
end-padding calculation method documented in 'board/doc/colibri_imx7.rst'
as a reference, which is relevant for iMX7 with NAND storage.
Adding 10k bytes of zeros provides an approximate value that makes the
proper padding for these NAND devices.
Hiago De Franco [Mon, 2 Oct 2023 11:57:49 +0000 (08:57 -0300)]
toradex: colibri_imx7: Enable nand/emmc detection and set boot variant
Add detection of eMMC vs NAND devices on the Colibri iMX7
board. A GPIO is configured to detect the presence of an on-board resistor
that is configured differently based on the flash memory used. Depending on
the detection result, the 'variant' environment variable is set to '-emmc'
or cleared, indicating the type of storage device.
This enhancement improves variant detection during system initialization
through USB recovery mode, where U-Boot is loaded directly to RAM. This
allows variant detection for an accurate device tree selection.
board: toradex: verdin-imx8mm: set fixed LPDDR4 refresh rate as per errata ERR050805
Update lpddr4 configuration and training using updated spreadsheet and
tools from NXP using data from previous spreadsheet and verified
toward datasheet:
The most relevant update is related to errata ERR050805:
"DRAM: Controller automatic derating logic may not work when
the LPDDR4 memory temperature is above 85 °C at initialization"
Other relevant fixes:
- DRAMTMG7 register: corrected calculation of T_CKPDX parameter
(equal to tCKCKEH for LPDDR4)
- RANKCTL register: corrected calculations for ODTLon and ODTLoff
to follow the JEDEC specification
- ADDRMAP7 register: added support for 17-row devices
As per errata ERR050805:
An issue exists with the automatic derating logic of the DDR
controller that only samples the LPDDR4 MR4 register when the
Temperature Update Flag (TUF) field (MR4[7] ) is 1’b1. If the
LPDDR4 memory is initialized and starts operation above 85 °C
(MR4[2:0] > 3’b011), the MR4 Temperature Update Flag (TUF) will
not be set. The DDR Controller will therefore not automatically
adjust the memory refresh rate or de-rate memory timings based
on the LPDDR4 memory temperature. This may cause the controller
incorrectly setting the refresh period, potentially cause the
LPDDR4 memory losing data contents and lead to possible data
integrity issues above 85 °C.
Errata provides three possible workaround options, while option 2
is the most reasonable:
Disable the automatic derating logic of the DDR controller and
apply fixed x2 refresh rate (0.5x refresh). This option is
suitable for designs that are expected to boot at or above 85 °C
and memory’s MR4[2:0] (Refresh Rate) DOES NOT report the following
conditions:
3b101: 0.25x refresh, no de-rating
3b110: 0.25x refresh, with de-rating
3b111: SDRAM High temperature operating limit exceeded
mx8m: csf.sh: pad csf blob for u-boot.itb to CSF_SIZE minus IVT header
When built with CONFIG_IMX_HAB, the full FIT image, including stuff
tacked on beyond the end of the fdt structure, is expected to be (fdt
size rounded up to 0x1000 boundary)+CONFIG_CSF_SIZE.
Now, when the FIT image is loaded from a storage device, it doesn't
really matter that the flash.bin that gets written to target isn't
quite that big - we will just load some garbage bytes that are never
read or used for anything. But when flash.bin is uploaded via uuu,
it's important that we actually serve at least as many bytes as the
target expects, or we will hang in rom_api_download_image().
Extend the logic in the csf.sh script so that the csf blob is padded
to CONFIG_CSF_SIZE minus the size of the IVT header.
imx: spl_imx_romapi: avoid tricky use of spl_load_simple_fit() to get full FIT size
Currently, spl_imx_romapi uses a somewhat tricky workaround for the
fact that a FIT image with external data doesn't directly allow one to
know the full size of the file: It does a dummy spl_load_simple_fit(),
having the ->read callback remember the largest offset requested, and
then does a last call to rom_api_download_image() to fetch the
remaining part of the full FIT image.
We can avoid that by just keeping track of how much we have downloaded
already, and if the ->read() requests something outside the current
valid buffer, fetch up to the end of the current request.
The current method also suffers from not working when CONFIG_IMX_HAB
is enabled: While in that case u-boot.itb is not built with external
data, so the fdt header does contain the full size of the dtb
structure. However, it does not account for the extra CONFIG_CSF_SIZE
added by board_spl_fit_size_align(). And also, the data it hands out
during the first dummy spl_load_simple_fit() is of course garbage, and
wouldn't pass the verification.
So we really need to call spl_load_simple_fit() only once, let that
figure out just how big the FIT image is (including whatever data, CSF
or "ordinary" external data, has been tacked on beyond the fdt
structure), and always provide valid data from the ->read callback.
This only affects the CONFIG_SPL_LOAD_FIT case - I don't have any
hardware or experience with the CONFIG_SPL_LOAD_IMX_CONTAINER case, so
I leave that alone for now.
The hab signing script doc/imx/habv4/csf_examples/mx8m/csf.sh does
fdtget -t x u-boot.dtb /binman/imx-boot/uboot offset
to figure out the offset of u-boot.itb inside flash.bin. That works
fine for imx8mm, imx8mn, imx8mq, but fails for imx8mp because in that
case 'uboot' is merely a label and not actually the node name.
Homogenize these cases and make imx8mp the same as the other imx8m*
variants. The binman type is explicitly given and no longer derived
from the node name, and the csf.sh script will work for all four SOCs.
Tim Harvey [Thu, 24 Aug 2023 19:03:56 +0000 (12:03 -0700)]
arm: dts: imx8m: move CAAM nodes into common u-boot.dtsi
Move the crypto and sec_jr* nodes from board-specific
u-boot.dtsi files into the common files. Additionally protect the
nodes with ifdef CONFIG_FSL_CAAM as they don't serve any purpose if
that is not enabled.
Signed-off-by: Tim Harvey <tharvey@gateworks.com> Reviewed-by: Marcel Ziswiler <marcel.ziswiler@toradex.com>
Tim Harvey [Thu, 24 Aug 2023 19:01:43 +0000 (12:01 -0700)]
arm: dts: imx8mp: move firmware/optee node to common imx8mp-u-boot.dtsi
Move the firmware/optee node to the common imx8mp-u-boot.dtsi and
protect it with an ifdef CONFIG_OPTEE as it is a meaningless node
without the optee driver enabled.
Signed-off-by: Tim Harvey <tharvey@gateworks.com> Reviewed-by: Fabio Estevam <festevam@denx.de>
Tim Harvey [Thu, 24 Aug 2023 19:01:42 +0000 (12:01 -0700)]
arm: dts: imx8mm: move firmware/optee node to common imx8mm-u-boot.dtsi
Move the firmware/optee node to the common imx8mm-u-boot.dtsi and
protect it with an ifdef CONFIG_OPTEE as it is a meaningless node
without the optee driver enabled.
Tim Harvey [Tue, 15 Aug 2023 22:01:15 +0000 (15:01 -0700)]
board: gateworks: venice: updates for imx8mp-venice-gw74xx revB PCB
Update the imx8mp-venice-gw74xx for revB:
- add CAN1
- add TIS-TPM on SPI2
- add FAN controller
- fix PMIC I2C bus (revA PMIC I2C was non-functional so no need for
backward compatible option)
- M2 socket GPIO's moved
Tim Harvey [Tue, 15 Aug 2023 22:01:14 +0000 (15:01 -0700)]
board: gateworks: venice: add imx8mm-gw7905-0x support
The Gateworks imx8mm-venice-gw7905-0x consists of a SOM + baseboard.
The GW700x SOM contains the following:
- i.MX8M Mini SoC
- LPDDR4 memory
- eMMC Boot device
- Gateworks System Controller (GSC) with integrated EEPROM, button
controller, and ADC's
- RGMII PHY
- PMIC
- SOM connector providing:
- FEC GbE MII
- 1x SPI
- 2x I2C
- 4x UART
- 2x USB 2.0
- 1x PCI
- 1x SDIO (4-bit 3.3V)
- 1x SDIO (4-bit 3.3V/1.8V)
- GPIO
The GW7905 Baseboard contains the following:
- GPS
- microSD
- off-board I/O connector with I2C, SPI, GPIO
- EERPOM
- PCIe clock generator
- 1x full-length miniPCIe socket with PCI/USB3 (via mux) and USB2.0
- 1x half-length miniPCIe socket with USB2.0 and USB3.0
- USB 3.0 HUB
- USB Type-C with USB PD Sink capability and peripheral support
- USB Type-C with USB 3.0 host support
Tim Harvey [Tue, 15 Aug 2023 22:01:13 +0000 (15:01 -0700)]
board: gateworks: venice: add imx8mp-gw73xx-2x support
The Gateworks imx8mp-venice-gw73xx-2x consists of a SOM + baseboard.
The GW702x SOM contains the following:
- i.MX8M Plus SoC
- LPDDR4 memory
- eMMC Boot device
- Gateworks System Controller (GSC) with integrated EEPROM, button
controller, and ADC's
- PMIC
- SOM connector providing:
- eQoS GbE MII
- 1x SPI
- 2x I2C
- 4x UART
- 2x USB 3.0
- 1x PCI
- 1x SDIO (4-bit 3.3V)
- 1x SDIO (4-bit 3.3V/1.8V)
- GPIO
The GW73xx Baseboard contains the following:
- 1x RJ45 GbE (eQoS from SOM)
- 1x RJ45 GbE (PCI)
- off-board I/O connector with MIPI-CSI (3-lane), MIPI-DSI (4-lane),
- off-board I/O connector with RS232/RS485
- off-board I/O connector with SPI
- off-board I/O connector with I2C, UART, and GPIO
I2C, I2S and GPIO
- microSD (1.8V/3.3V)
- GPS
- Accelerometer
- EERPOM
- USB 3.0 Hub
- Front Panel bi-color LED
- re-chargeable battery (for RTC)
- PCIe clock generator
- PCIe switch
- on-board 802.11abgnac 1x1 WiFi and Bluetooth 5.2
- 1x USB Type-A host socket with USB 3.0 support
- 1x USB OTG with USB 2.0 support
- 2x MiniPCIe socket with PCI and USB 2.0
- 1x MiniPCIe socket with SIM, PCI/USB 3.0 (mux), and USB 2.0
- Wide range DC input supply
Tim Harvey [Tue, 15 Aug 2023 22:01:12 +0000 (15:01 -0700)]
board: gateworks: venice: add imx8mp-gw72xx-2x support
The Gateworks imx8mp-venice-gw72xx-2x consists of a SOM + baseboard.
The GW702x SOM contains the following:
- i.MX8M Plus SoC
- LPDDR4 memory
- eMMC Boot device
- Gateworks System Controller (GSC) with integrated EEPROM, button
controller, and ADC's
- PMIC
- SOM connector providing:
- eQoS GbE MII
- 1x SPI
- 2x I2C
- 4x UART
- 2x USB 3.0
- 1x PCI
- 1x SDIO (4-bit 3.3V)
- 1x SDIO (4-bit 3.3V/1.8V)
- GPIO
The GW72xx Baseboard contains the following:
- 1x RJ45 GbE (eQoS from SOM)
- 1x RJ45 GbE (PCI)
- off-board I/O connector with MIPI-CSI (3-lane), MIPI-DSI (4-lane),
- off-board I/O connector with RS232/RS485
- off-board I/O connector with SPI
- off-board I/O connector with I2C, UART, and GPIO
I2C, I2S and GPIO
- microSD (1.8V/3.3V)
- GPS
- Accelerometer
- EERPOM
- USB 3.0 Hub
- Front Panel bi-color LED
- re-chargeable battery (for RTC)
- PCIe clock generator
- PCIe switch
- 1x USB Type-A host socket with USB 3.0 support
- 1x USB OTG with USB 2.0 support
- 1x MiniPCIe socket with PCI and USB 2.0
- 1x MiniPCIe socket with SIM, PCI/USB 3.0 (mux), and USB 2.0
- Wide range DC input supply
Tim Harvey [Tue, 15 Aug 2023 22:01:11 +0000 (15:01 -0700)]
board: gateworks: venice: add imx8mp-gw71xx-2x support
The Gateworks imx8mp-venice-gw71xx-2x consists of a SOM + baseboard.
The GW702x SOM contains the following:
- i.MX8M Plus SoC
- LPDDR4 memory
- eMMC Boot device
- Gateworks System Controller (GSC) with integrated EEPROM, button
controller, and ADC's
- PMIC
- SOM connector providing:
- eQoS GbE MII
- 1x SPI
- 2x I2C
- 4x UART
- 2x USB 3.0
- 1x PCI
- 1x SDIO (4-bit 3.3V)
- 1x SDIO (4-bit 3.3V/1.8V)
- GPIO
The GW71xx Baseboard contains the following:
- 1x RJ45 GbE (eQoS from SOM)
- off-board I/O connector with I2C, SPI, UART, and GPIO
- Front Panel bi-color LED
- re-chargeable battery (for RTC)
- PCIe clock generator
- 1x USB Type-C connector supporting USB 2.0 host mode with VBUS
- 1x MiniPCIe socket with SIM, PCI/USB 3.0 (mux), and USB 2.0
- GPS
- Accelerometer
- EERPOM
- Wide range DC input supply
Michael Scott [Thu, 3 Aug 2023 15:25:20 +0000 (18:25 +0300)]
imx: syscounter: allow timer_init for SPL build
With enabled SKIP_LOWLEVEL_INIT, the weak function timer_init() is
used in the SPL build. For iMX6 SoC, this leads MMC to fail once
u-boot proper is booted due to a timing issue.
Always use iMX-specific timer_init() in SPL to fix timing issues.
Fixes: be277c3a89 ("imx: mx7: avoid some initialization if low level is skipped") Signed-off-by: Michael Scott <mike@foundries.io> Co-developed-by: Oleksandr Suvorov <oleksandr.suvorov@foundries.io> Signed-off-by: Oleksandr Suvorov <oleksandr.suvorov@foundries.io> Reviewed-by: Peng Fan <peng.fan@nxp.com>
Tom Rini [Sat, 14 Oct 2023 14:47:52 +0000 (10:47 -0400)]
Merge branch '2023-10-13-firmware-scmi-updates'
- Fix a memset call in the optee_agent code.
Then to quote the author for the rest of the changes:
This patch series allows users to access SCMI base protocol provided by
SCMI server (platform). See SCMI specification document v3.2 beta[1]
for more details about SCMI base protocol.
What is currently not implemented is
- SCMI_BASE_NOTIFY_ERRORS command and notification callback mechanism
This feature won't be very useful in the current U-Boot environment.
AKASHI Takahiro [Wed, 11 Oct 2023 10:07:06 +0000 (19:07 +0900)]
test: dm: add SCMI base protocol test
Added is a new unit test for SCMI base protocol, which will exercise all
the commands provided by the protocol, except SCMI_BASE_NOTIFY_ERRORS.
$ ut dm scmi_base
It is assumed that test.dtb is used as sandbox's device tree.
AKASHI Takahiro [Wed, 11 Oct 2023 10:07:04 +0000 (19:07 +0900)]
firmware: scmi: install base protocol to SCMI agent
SCMI base protocol is mandatory, and once SCMI node is found in a device
tree, the protocol handle (udevice) is unconditionally installed to
the agent. Then basic information will be retrieved from SCMI server via
the protocol and saved into the agent instance's local storage.
AKASHI Takahiro [Wed, 11 Oct 2023 10:07:03 +0000 (19:07 +0900)]
test: dm: simplify SCMI unit test on sandbox
Adding SCMI base protocol makes it inconvenient to hold the agent instance
(udevice) locally since the agent device will be re-created per each test.
Just remove it and simplify the test flows.
The test scenario is not changed at all.
AKASHI Takahiro [Wed, 11 Oct 2023 10:07:01 +0000 (19:07 +0900)]
firmware: scmi: add a version check against base protocol
In SCMI base protocol version 2 (0x20000), new interfaces,
BASE_SET_DEVICE_PERMISSIONS/BASE_SET_PROTOCOL_PERMISSIONS/
BASE_RESET_AGENT_CONFIGURATION, were added. Moreover, the api of
BASE_DISCOVER_AGENT was changed to support self-agent discovery.
So the driver expects SCMI firmware support version 2 of base protocol.
AKASHI Takahiro [Wed, 11 Oct 2023 10:07:00 +0000 (19:07 +0900)]
firmware: scmi: implement SCMI base protocol
SCMI base protocol is mandatory according to the SCMI specification.
With this patch, SCMI base protocol can be accessed via SCMI transport
layers. All the commands, except SCMI_BASE_NOTIFY_ERRORS, are supported.
This is because U-Boot doesn't support interrupts and the current transport
layers are not able to handle asynchronous messages properly.
AKASHI Takahiro [Wed, 11 Oct 2023 10:06:55 +0000 (19:06 +0900)]
firmware: scmi: use a protocol's own channel if assigned
SCMI specification allows any protocol to have its own channel for
the transport. While the current SCMI driver may assign its channel
from a device tree, the core function, devm_scmi_process_msg(), doesn't
use a protocol's channel, but always use an agent's channel.
With this commit, devm_scmi_process_msg() tries to find and use
a protocol's channel. If it doesn't exist, use an agent's.
AKASHI Takahiro [Wed, 11 Oct 2023 10:06:54 +0000 (19:06 +0900)]
scmi: refactor the code to hide a channel from devices
The commit 85dc58289238 ("firmware: scmi: prepare uclass to pass channel
reference") added an explicit parameter, channel, but it seems to make
the code complex.
Hiding this parameter will allow for adding a generic (protocol-agnostic)
helper function, i.e. for PROTOCOL_VERSION, in a later patch.
Sughosh Ganu [Tue, 10 Oct 2023 09:10:59 +0000 (14:40 +0530)]
binman: capsule: Add support for generating EFI empty capsules
Add support in binman for generating EFI empty capsules. These
capsules are used in the FWU A/B update feature. Also add test cases
in binman for the corresponding code coverage.
Signed-off-by: Sughosh Ganu <sughosh.ganu@linaro.org> Reviewed-by: Simon Glass <sjg@chromium.org>
Sughosh Ganu [Tue, 10 Oct 2023 09:10:57 +0000 (14:40 +0530)]
binman: capsule: Use dumped capsule header contents for verification
The various fields of a generated capsule are currently verified
through hard-coded offsets. Use the dump-capsule feature for dumping
the capsule header contents and use those for capsule verification.
Signed-off-by: Sughosh Ganu <sughosh.ganu@linaro.org> Reviewed-by: Simon Glass <sjg@chromium.org>
Sughosh Ganu [Tue, 10 Oct 2023 09:10:54 +0000 (14:40 +0530)]
tools: mkeficapsule: Add support to print capsule headers
Add support to dump the contents of capsule headers. This is useful as
a debug feature for checking the contents of the capsule headers, and
can also be used in capsule verification.
Signed-off-by: Sughosh Ganu <sughosh.ganu@linaro.org> Reviewed-by: Simon Glass <sjg@chromium.org>
treewide: use dev_read_addr_*_ptr() where appropriate
A follow-up to commit 842fb5de424e
("drivers: use devfdt_get_addr_size_index_ptr when cast to pointer")
and commit 320a1938b6f7
("drivers: use devfdt_get_addr_index_ptr when cast to pointer").
In addition to using the *_ptr variants of these functions where the
address is cast to a pointer, this also changes devfdt_get_addr_*() to
dev_read_addr_*() in a few places. Some variable and field types are
changed from fdt_addr_t or phys_addr_t to void* where the cast was
happening later.
This patch fixes a number of compile warnings when building a 32bit
U-Boot with CONFIG_PHYS_64BIT=y. In some places, it also fixes error
handling where the return value of dev_read_addr() etc. was checked for
NULL instead of FDT_ADDR_T_NONE.
Signed-off-by: Matthias Schiffer <matthias.schiffer@ew.tq-group.com> Reviewed-by: Simon Glass <sjg@chromium.org>
pinctrl: single: fix compile warnings with PHYS_64BIT on 32bit
pinctrl-single uses fdt_addr_t and phys_addr_t inconsistently, but both
are wrong to be passed to readb() etc., which expect a pointer or
pointer-sized integer. Change the driver to use
dev_read_addr_size_index_ptr(), so we consistently deal with void*
(except for the sandbox case and single_get_pin_muxing()).
Signed-off-by: Matthias Schiffer <matthias.schiffer@ew.tq-group.com> Reviewed-by: Simon Glass <sjg@chromium.org>
Add missing mapmem.h header: Signed-off-by: Simon Glass <sjg@chromium.org>
core: return FDT_ADDR_T_NONE from devfdt_get_addr_[size_]name() on errors
Checking for the error cast to fdt_addr_t is rather awkward - IS_ERR()
can be used, but it's not really made to be used on fdt_addr_t, which
may not even be the same size as a native pointer.
Most places in U-Boot only check for FDT_ADDR_T_NONE; let's adjust the
error return to match the expectation.
Signed-off-by: Matthias Schiffer <matthias.schiffer@ew.tq-group.com> Reviewed-by: Simon Glass <sjg@chromium.org>
core: fix doc comments of dev_read_addr*() and related functions
- The dev_read_addr_name*() family of functions has no "index" argument,
doc comments should refer to "name"
- Specify the error return for several devfdt_get_addr*() functions
Signed-off-by: Matthias Schiffer <matthias.schiffer@ew.tq-group.com> Reviewed-by: Simon Glass <sjg@chromium.org>
Simon Glass [Sat, 23 Sep 2023 20:50:15 +0000 (14:50 -0600)]
bootstd: Scan all bootdevs in a boot_targets entry
When the boot_targets environment variable is used with the distro-boot
scripts, each device is included individually. For example, if there
are three mmc devices, then we will have something like:
boot_targets="mmc0 mmc1 mmc2"
In contrast, standard boot supports specifying just the uclass, i.e.:
boot_targets="mmc"
The intention is that this should scan all MMC devices, but in fact it
currently only scans the first.
Update the logic to handle this case, without required BOOTSTD_FULL to
be enabled.
I believe at least three people reported this, but I found two.
Signed-off-by: Simon Glass <sjg@chromium.org> Reported-by: Date Huang <tjjh89017@hotmail.com> Reported-by: Vincent Stehlé <vincent.stehle@arm.com>
Tom Rini [Fri, 13 Oct 2023 12:45:55 +0000 (08:45 -0400)]
Merge tag 'xilinx-for-v2024.01-rc1-v3' of https://source.denx.de/u-boot/custodians/u-boot-microblaze
Xilinx changes for v2024.01-rc1 v3
clk:
- remove additional compatible strings for Versal NET
net:
- zynq_gem: Fix clock calculation for MDC for higher frequencies
pinctrl:
- core: Extend pinmux status buffere size
- zynqmp driver: Show also tristate configuration
test:
- add test case for pxe get
Xilinx:
- describe SelectMAP boot mode
Zynq:
- Fix nand description in DT
ZynqMP:
- DTS sync patches with kernel and also W=1 related fixes
- Add support for KD240, zcu670, e-a2197 with x-prc cards, SC revB/C with i2c
description for other SC based boards
- k24 psu_init cleanup
The first 5 patches are from Mikhail Kshevetskiy, aligning the mtd spinand
core with kernel version 5.15.43, fixing a bug on Winbond, and adding
support for Winbond W25NO2KV.
The other 2 patches are from Patrick Delaunay and they fix a bug and mark
bad the MTD block on erase error.
Artur Rojek [Wed, 13 Sep 2023 15:00:58 +0000 (17:00 +0200)]
usb: gadget: atmel: fix transfer of queued requests
In the existing implementation, multiple requests queued up on an
endpoint are subject to getting evicted without transmission.
For both control and bulk endpoints, their respective logic found in
usba_control_irq()/usba_ep_irq() guarantees that TX FIFO is empty before
data is sent out, and that request_complete() gets called once the
transaction has been finished. At this point however, if any additional
requests are found on the endpoint queue, they will be processed by
submit_next_request(), which makes no checks against the above
conditions, trashing data on a busy FIFO and neglecting completion
handlers.
Fix the above issues by removing the calls to submit_next_request(),
and thus forcing the pending requests to be processed on the next pass
of the respective endpoint logic. While at it, remove a DBG message, as
that branch becomes part of regular flow.
This restores mass storage mode operation on Microchip ATSAMA5D27 SoC.
In the MTD DFU backend, it is needed to mark the NAND block bad when the
erase failed with the -EIO error, as it is done in UBI and JFFS2 code.
This operation is not done in the MTD framework, but the bad block
tag (in BBM or in BBT) is required to avoid to write data on this block
in the next DFU_OP_WRITE loop in mtd_block_op(): the code skip the bad
blocks, tested by mtd_block_isbad().
Without this patch, when the NAND block become bad on DFU write operation
- low probability on new NAND - the DFU write operation will always failed
because the failing block is never marked bad.
This patch also adds a test to avoid to request an erase operation on a
block already marked bad; this test is not performed in MTD framework
in mtd_erase().
Reviewed-by: Michael Trimarchi <michael@amarulasolutions.com> Signed-off-by: Patrick Delaunay <patrick.delaunay@foss.st.com>
The offset variable = 'off' used in the error trace when limit is reach
on erase operation is incorect as 'erase_op.addr' is used in the loop.
This patch corrects the copy paste issue between the erase loop and
the write loop.
This patch also adds the 'remaining' information to allow to debug of
limit issues.
Fixes: 6015af28ee6d ("dfu: add backend for MTD device") Signed-off-by: Patrick Delaunay <patrick.delaunay@foss.st.com> Reviewed-by: Patrice Chotard <patrice.chotard@foss.st.com>
Winbond uses 3 bytes to identify flash: vendor_id, dev_id_0, dev_id_1,
but current driver uses only first 2 bytes of it for devices
identification. As result Winbond W25N02KV flash (id_bytes: EF, AA, 22)
is identified as W25N01GV (id_bytes: EF, AA, 21).
mtd/spinand: sync supported devices with linux-5.15.43
This adds more supported spinand devices from the Linux kernel
implementation.
This does not include the latest kernel implementation as this would
require a substantial amount of extra work due to the missing
ECC engine abstraction layer in U-Boot.
mtd/spinand: sync core spinand code with linux-5.10.118
This brings us closer to the current Linux kernel implementation of
the spinand core and makes backporting features and fixes easier.
This does not include the latest kernel implementation as this would
require a substantial amount of extra work due to the missing
ECC engine abstraction layer in U-Boot.
mtd/spinand: rework detect procedure for different READ_ID operation
Currently there are 3 different variants of read_id implementation:
1. opcode only. Found in GD5FxGQ4xF.
2. opcode + 1 addr byte. Found in GD5GxGQ4xA/E
3. opcode + 1 dummy byte. Found in other currently supported chips.
Original implementation was for variant 1 and let detect function
of chips with variant 2 and 3 to ignore the first byte. This isn't
robust:
1. For chips of variant 2, if SPI master doesn't keep MOSI low
during read, chip will get a random id offset, and the entire id
buffer will shift by that offset, causing detect failure.
2. For chips of variant 1, if it happens to get a devid that equals
to manufacture id of variant 2 or 3 chips, it'll get incorrectly
detected.
This patch reworks detect procedure to address problems above. New
logic do detection for all variants separatedly, in 1-2-3 order.
Since all current detect methods do exactly the same id matching
procedure, unify them into core.c and remove detect method from
manufacture_ops.
This is a rework of Chuanhong Guo <gch981213@gmail.com> patch
submitted to linux kernel
TRM for J721S2/AM68: https://www.ti.com/lit/pdf/spruj28
Product Page for J721S2: https://www.ti.com/tool/J721S2XSOMXEVM
Product Page for AM68: https://www.ti.com/tool/SK-AM68
Udit Kumar [Fri, 6 Oct 2023 04:45:55 +0000 (10:15 +0530)]
configs: j721s2_evm_r5_defconfig: Increase malloc pool size in DRAM
The malloc capacity in DRAM at R5 SPL is set to 1MB which isn't
sufficient to load the new tispl.bin to
enable loading of tispl.bin the size is increased by 256KB to 1.25MB.
Reid Tonking [Thu, 5 Oct 2023 18:12:58 +0000 (13:12 -0500)]
arm: dts: j7200: dts sync with Linux 6.6-rc1
Sync j7200 dts with Linux 6.6-rc1
- k3-j7200-r5-common-proc-board.dts now inherits from
k3-j7200-common-proc-board.dts instead of k3-j7200-som-p0.dtsi. This
allows us to trim down the r5 file considerably by using existing
properties
- remove pimux nodes from r5 file
- remove duplicate nodes & node properties from r5/u-boot files
- mcu_timer0 now used instead of timer1
mcu_timer0 device id added to dev-data.c file in order to work
- remove cpsw node
This node is no longer required since the compatible is now fixed
- remove dummy_clock_19_2_mhz
This node wasn't being used anyhere, so it was removed
- remove dummy_clock_200mhz
main_sdhci0 & main_sdhci1 no longer need dummy clock for eMMC/SD
- fix secure proxy node
mcu_secproxy changed to used secure_prxy_mcu which is already
defined in k3-j7200-mcu-wakeup.dtsi
- removed &mcu_ringacc property override since they're present in
v6.6-rc1
Roger Quadros [Thu, 5 Oct 2023 13:06:42 +0000 (16:06 +0300)]
board: ti: am64x: Switch to standard boot flow
Switch to using bootstd. Note with this change, we will stop using
distro_bootcmd and instead depend entirely on bootflow method of
starting the system up.
Drop header files that are no longer needed in am64x_evm.h.
k3_dfu.h is available via k3_dfu.env in am64x.env.
Drop unused macro CFG_SYS_SDRAM_BASE1.
Signed-off-by: Roger Quadros <rogerq@kernel.org> Reviewed-by: Nishanth Menon <nm@ti.com>
To quote the author:
So far expo only supports menus. These are quite flexible for various
kinds of settings, but cannot deal with free-form input, such as a
serial number or a machine name.
This series adds support for a textline object, which is a single line
of text. It has a maximum length and its value is stored within the expo
structure.
U-Boot already has a command-line editor which provides most of the
features needed by expo. But the code runs in its own loop and only
returns when the line is finished. This is not suitable for expo, which
must handle a keypress at a time, returning to its caller after each
one.
In order to use the CLI code, some significant refactoring is included
here. This mostly involves moving the internal loop of the CLI to a
separate function and recording its state in a struct, just as was done
for single keypresses some time back. A minor addition is support for
Ctrl-W to delete a word, since strangely this is currently only present
in the simple version.
The video-console system provides most of the features needed by
testline, but a few things are missing. This series provides:
- primitive cursor support so the user can see where he is typing
- saving and restoring of the text-entry context, so that expo can allow
the user to continue where he left off, including deleting previously
entered characters correctly (for Truetype)
- obtaining the nominal width of a string of n characters, so that a
suitable width can be chosen for the textline object
Note that no support is provided for clearing the cursor. This was
addressed in a previous series[1] which could perhaps be rebased. For
this implementation, the cursor is therefore not enabled for the normal
command line, only for expo.
Reading and writing textline objects is supported for FDT and
environment, but not for CMOS RAM, since it would likely use too much
RAM to store a string.
In terms of code size, the overall size increase is 180 bytes for
Thumb02 boards, 160 of whcih is the addition of Ctrl-W to delete a word.
Masahisa Kojima [Thu, 12 Oct 2023 05:31:59 +0000 (14:31 +0900)]
efi_loader: use well-known guid for auto-created boot option
The boot option automatically created by efibootmgr is identified
by the special guid appended in the optional data of boot option.
The same mechanism is implemented in the EDK II reference
implementation, it uses the different guid from the one currently
U-Boot uses.
The guid indicating auto-created boot option is not defined in the
UEFI specification, but some userspace tools such as 'efivar' package
are aware of the guid used in EDK II as auto-created boot option.
So let's use the same guid as EDK II reference implementation.
Signed-off-by: Masahisa Kojima <masahisa.kojima@linaro.org> Reviewed-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
The BitBlt test leaves the serial console output in disarray.
* Call ClearScreen() where needed.
* Test CheckEvent() for EFI_SIMPLE_TEXT_INPUT_PROTOCOL.WaitForKey
via adding navigation keys
* Correct timer comment
Paul Barker [Mon, 9 Oct 2023 11:11:36 +0000 (12:11 +0100)]
doc: Migrate Renesas board docs to rst
Some of the information in README.rmobile is obsolete, references
defconfigs which no longer exist in u-boot or has broken links. The
information which is still relevant is moved into the reStructuredText
documentation under `doc/board/renesas`, and `doc/README.rmobile` is
dropped.
The list of boards in `doc/board/renesas` is converted into a table so
it's easier to see which defconfig to use. The list is expanded based on
reviewing the current u-boot code and the contents of the eLinux wiki
[1] [2].
Simon Glass [Sun, 8 Oct 2023 21:35:56 +0000 (15:35 -0600)]
doc: Add a short intro video
This video covers the basics in a short time, so add a link to it.
Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Paul Barker <paul.barker.ct@bp.renesas.com> Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
Weizhao Ouyang [Sat, 7 Oct 2023 10:52:36 +0000 (10:52 +0000)]
cyclic: doc: Update documentation for CONFIG_CYCLIC_MAX_CPU_TIME_US
Cyclic now just print a warning once instead of disabling the cyclic
function when the cyclic function upon exceeding CPU time usage.
Fixes: ddc8d36a7455 ("cyclic: Don't disable cylic function upon exceeding CPU time") Signed-off-by: Weizhao Ouyang <o451686892@gmail.com>
Rephrase the paragraph. Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
Tom Rini [Thu, 5 Oct 2023 16:27:38 +0000 (12:27 -0400)]
sphinx: Bump urllib3 version
While not a direct issue for us, urllib3 before 1.26.17 is vulnerable to
CVE-2023-43804 to bump our version up.
Reported-by: GitHub dependabot Signed-off-by: Tom Rini <trini@konsulko.com> Reviewed-by: Simon Glass <sjg@chromium.org>
Use urllib3 2.0.6 Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
projects / u-boot.git / log