Commit graph

87354 commits

Author SHA1 Message Date
Marek Vasut
b0866db2dc ARM: rmobile: Factor out common R-Car V3M/V3H board code
Pull common board initialization code from V3M Eagle board
into rcar-common/v3-common.c so it can be re-used by other
V3M/V3H boards.

Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
2023-06-08 22:26:51 +02:00
Marek Vasut
ad1616f0e8 ARM: rmobile: Reduce R-Car V3H Condor header usage
There is no need to pull in all those headers as the board file is
basically empty. Drop them all.

Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
2023-06-08 22:26:51 +02:00
Marek Vasut
5b90b22407 ARM: rmobile: Reduce R-Car E3 Ebisu header usage
There is no need to pull in all those headers as the board file is
basically empty. Drop them all.

Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
2023-06-08 22:26:51 +02:00
Marek Vasut
a4fc6ee9e7 ARM: rmobile: Deduplicate R-Car Gen3/Gen4 reset_cpu()
The reset_cpu() implementation is basically the same across Gen3
SoCs and identical across Gen4 SoCs. Introduce weak default for
reset_cpu(), so that it does not have to be duplicated in every
board file again.

There is a slight difference for CA53 only systems, like E3 and D3,
which now check MIDR for CPU ID first just like the other systems,
but this is OK since the MIDR always returns CA53 core type and the
correct reset register is written.

Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
2023-06-08 22:26:51 +02:00
Hai Pham
b597b6f986 pinctrl: renesas: r8a779a0: Remove incorrect AVB[01] pinmux configuration
AVB[01]_{MAGIC,MDC,MDIO,TXCREFCLK} are registered as both
PINMUX_SINGLE(fn) and PINMUX_IPSR_GPSR(fn) in the pinmux_data array.

The latter are correct, hence remove the former.
Without this fix, the Ethernet PHY is not operational on the MDIO bus.

Ported from Linux kernel commit a145c9a8674ac8fbfa1595276e1b6cbfc5139038 .

Signed-off-by: Hai Pham <hai.pham.ud@renesas.com>
Signed-off-by: LUU HOAI <hoai.luu.ub@renesas.com>
Fixes: 741a7370fc3b8b54 ("pinctrl: renesas: Initial R8A779A0 (V3U) PFC support")
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Link: https://lore.kernel.org/r/6fd217b71e83ba9a8157513ed671a1fa218b23b6.1674824958.git.geert+renesas@glider.be
---
Cc: Geert Uytterhoeven <geert+renesas@glider.be>
Cc: Hai Pham <hai.pham.ud@renesas.com>
Cc: LUU HOAI <hoai.luu.ub@renesas.com>
Cc: Marek Vasut <marek.vasut+renesas@mailbox.org>
2023-06-08 22:22:38 +02:00
Hai Pham
13c8a0717d ARM: rmobile: Identify R-Car D3 R8A77995 r1.1 SoC
Add support to identify R8A77995 r1.1 SoC.

Reviewed-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
Signed-off-by: Hai Pham <hai.pham.ud@renesas.com>
[Marek: Slight update to commit message, spell out the SoC model]
2023-06-08 22:22:38 +02:00
Hiroyuki Yokoyama
08260efdaf ARM: rmobile: Identify R-Car M3-W R8A7796 r1.1/1.2 SoC
r8a7796 cpu revision v1.2 has the same information as revision v1.1.
This patch fixes revision display at startup to "rev 1.1/1.2".

Reviewed-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
Signed-off-by: Hiroyuki Yokoyama <hiroyuki.yokoyama.vx@renesas.com>
Signed-off-by: Hai Pham <hai.pham.ud@renesas.com>
[Marek: Slight update to commit message, spell out the SoC model]
2023-06-08 22:22:38 +02:00
Sam Edwards
e10f964149 usb: musb-new: sunxi: remove unused define
This is a remnant from when the USB controller driver managed
the reset signal itself. A patch from the very end of 2018 changed
this driver to delegate reset (and clock) management to the proper
control unit driver, but left this unused define behind.

Signed-off-by: Sam Edwards <CFSworks@gmail.com>
Reviewed-by: Marek Vasut <marex@denx.de>
2023-06-08 21:57:01 +02:00
Tom Rini
3aa4fb12f4 Pull request efi-next-20230608
UEFI:
 
 * Support for firmware versions in capsule updates
 -----BEGIN PGP SIGNATURE-----
 
 iQIzBAABCAAdFiEEbcT5xx8ppvoGt20zxIHbvCwFGsQFAmSBowkACgkQxIHbvCwF
 GsQ8QxAAjDlvi1Z+EI6bo/Y870PM+R0QIjkz3biU5fr0ZAoCo/ejIQJjzf0WFRr6
 Z/iTNUskIGQ9tgx3wF4qc3gPDWxK6XucmJSqoCQo7VjrlbTgImoQVoFLG9SyJ3cV
 bzYQOPys0YIDg+MIu1CkjvGcK5kbO5cH86SYANIn92EKvDpo5nUqdO1Vd2yL9K6s
 cIoQ/krbM6LUmypUORDZfTj7Ca35KYfUabJ7j3LMZfvltEVH85wj74UeX13wM/3C
 Ks8pDZoitCgYxrL31L8zwn9oxfQGIdrHcJ/1JR+tVoh09XcwDXaAxLlrVSwc803E
 o+7kun8ziV1v/icSMYE6+kGUM9nXUAwbH6UGubkG6DR7mNTYU+4YT9CVY0XuuLEE
 Ygc8+rSZGnffNkC9JisGMiaoiT/ovfDtPb+gs7euYdbsKIgLhxfXFuvDBviUduAl
 57egx13q4EMu+6N1anDuirskhrQPEvK5bGmm9JLLcYDLduwA8qaXPtYgKhWxDzw3
 4WkxtbyQWSjEuhLcWpV9jrCTlGK0gnleNfGgHnDF3cXPaGh1fUCfhrMoPXpvk3ef
 tgn6EdCWhqj88vDwboyMSZFm/+Dri5LEWHINxoZY+JaMtBb/sFj/bmN7eXWIVX4a
 cqq2VRSH5n8/rdbyVp+o8y9iO8gdB9znEhYtg7boD2ToKF2xb0U=
 =Y2Kt
 -----END PGP SIGNATURE-----

Merge tag 'efi-next-20230608' of https://source.denx.de/u-boot/custodians/u-boot-efi into next

Pull request efi-next-20230608

UEFI:

* Support for firmware versions in capsule updates
2023-06-08 11:19:27 -04:00
Masahisa Kojima
b6f954e5b0 test/py: efi_capsule: test for FMP versioning
This test covers the FMP versioning for both raw and FIT image,
and both signed and non-signed capsule update.

Signed-off-by: Masahisa Kojima <masahisa.kojima@linaro.org>
Acked-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
2023-06-08 09:20:36 +02:00
Masahisa Kojima
482ef90aeb test: efi_capsule: refactor efi_capsule test
Current efi capsule python tests have much code duplication.
This commit creates the common function
in test/py/tests/test_efi_capsule/capsule_common.py,
aim to reduce the code size and improve maintainability.

Reviewed-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Masahisa Kojima <masahisa.kojima@linaro.org>
Acked-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
2023-06-08 09:20:36 +02:00
Masahisa Kojima
027f8a82ea doc: uefi: add anti-rollback documentation
This commit describe the procedure to configure lowest supported
version in the device tree for anti-rollback protection.

Signed-off-by: Masahisa Kojima <masahisa.kojima@linaro.org>
2023-06-08 09:20:36 +02:00
Masahisa Kojima
83be41049b doc: uefi: add firmware versioning documentation
This commit describes the procedure to add the firmware version
into the capsule file.

Signed-off-by: Masahisa Kojima <masahisa.kojima@linaro.org>
2023-06-08 09:20:36 +02:00
Masahisa Kojima
000806f76b mkeficapsule: add FMP Payload Header
Current mkeficapsule tool does not provide firmware
version management. EDK II reference implementation inserts
the FMP Payload Header right before the payload.
It coutains the fw_version and lowest supported version.

This commit adds a new parameters required to generate
the FMP Payload Header for mkeficapsule tool.
 '-v' indicates the firmware version.

When mkeficapsule tool is invoked without '-v' option,
FMP Payload Header is not inserted, the behavior is same as
current implementation.

The lowest supported version included in the FMP Payload Header
is not used, the value stored in the device tree is used instead.

Signed-off-by: Masahisa Kojima <masahisa.kojima@linaro.org>
Acked-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
2023-06-08 09:20:36 +02:00
Masahisa Kojima
6ab7a6853f efi_loader: check lowest supported version
The FMP Payload Header which EDK II capsule generation scripts
insert has a firmware version.
This commit reads the lowest supported version stored in the
device tree, then check if the firmware version in FMP payload header
of the ongoing capsule is equal or greater than the
lowest supported version. If the firmware version is lower than
lowest supported version, capsule update will not be performed.

Signed-off-by: Masahisa Kojima <masahisa.kojima@linaro.org>
2023-06-08 09:20:36 +02:00
Masahisa Kojima
25dc7d5aed efi_loader: get lowest supported version from device tree
This commit gets the lowest supported version from device tree,
then fills the lowest supported version in FMP->GetImageInfo().

Signed-off-by: Masahisa Kojima <masahisa.kojima@linaro.org>
Reviewed-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
2023-06-08 09:20:36 +02:00
Masahisa Kojima
3cba9702d1 efi_loader: versioning support in GetImageInfo
Current FMP->GetImageInfo() always return 0 for the firmware
version, user can not identify which firmware version is currently
running through the EFI interface.

This commit reads the "FmpStateXXXX" EFI variable, then fills the
firmware version in FMP->GetImageInfo().

Now FMP->GetImageInfo() and ESRT have the meaningful version number.

Signed-off-by: Masahisa Kojima <masahisa.kojima@linaro.org>
Reviewed-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
2023-06-08 09:20:36 +02:00
Masahisa Kojima
bfaa1fbc62 efi_loader: store firmware version into FmpState variable
Firmware version management is not implemented in the current
FMP protocol.
EDK II reference implementation capsule generation script inserts
the FMP Payload Header right before the payload, FMP Payload Header
contains the firmware version and lowest supported version.

This commit utilizes the FMP Payload Header, reads the header and
stores the firmware version into "FmpStateXXXX" EFI non-volatile variable.
XXXX indicates the image index, since FMP protocol handles multiple
image indexes.
Note that lowest supported version included in the FMP Payload Header
is not used. If the platform uses file-based EFI variable storage,
it can be tampered. The file-based EFI variable storage is not the
right place to store the lowest supported version for anti-rollback
protection.

This change is compatible with the existing FMP implementation.
This change does not mandate the FMP Payload Header.
If no FMP Payload Header is found in the capsule file, fw_version,
lowest supported version, last attempt version and last attempt
status is 0 and this is the same behavior as existing FMP
implementation.

Signed-off-by: Masahisa Kojima <masahisa.kojima@linaro.org>
2023-06-08 09:20:36 +02:00
Masahisa Kojima
cccea18813 efi_loader: add the number of image entries in efi_capsule_update_info
The number of image array entries global variable is required
to support EFI capsule update. This information is exposed as a
num_image_type_guids variable, but this information
should be included in the efi_capsule_update_info structure.

This commit adds the num_images member in the
efi_capsule_update_info structure. All board files supporting
EFI capsule update are updated.

Signed-off-by: Masahisa Kojima <masahisa.kojima@linaro.org>
Reviewed-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
2023-06-08 09:20:36 +02:00
Tom Rini
661332a074 Merge https://source.denx.de/u-boot/custodians/u-boot-sunxi
A small late pull request for Allwinner. The main feature is just a DT
update, matching the v6.4 Linux kernel DT files. This also enables a
board (LCTech Pi F1C200s) which got its .dts file merged into Linux.
Plus a tiny typo fix from Sam.

Gitlab CI passed, briefly tested on an H616 board and the new LCTech Pi.
2023-06-07 22:05:16 -04:00
Sam Edwards
9bc6f1a4d0 sunxi: Fix typo in include guard
Signed-off-by: Sam Edwards <CFSworks@gmail.com>
Reviewed-by: Andre Przywara <andre.przywara@arm.com>
2023-06-07 22:45:02 +01:00
Andre Przywara
b0816e3bd3 sunxi: defconfig: Add Lctech Pi F1C200s board
The Lctech Pi F1C200s (also previously known under the Cherry Pi brand)
is a small development board with the Allwinner F1C200s SoC. This is the
same as the F1C100s, but with 64MB instead of 32MB co-packaged DRAM.

Add a defconfig for this board, enabling the most basic features. This
uses the new 64MB memory map, which avoids the very tight memory map we
use for the 32MB F1C100s board(s).
The devicetree file is already in the tree, courtesy of the previous
Linux repo sync.

Signed-off-by: Andre Przywara <andre.przywara@arm.com>
2023-06-07 22:44:40 +01:00
Andre Przywara
57285737cb sunxi: dts: arm/arm64: update devicetree files from Linux-v6.4-rc2
Sync the devicetree files from the official Linux kernel tree, v6.4-rc2.
This is covering both 64-bit and 32-bit Allwinner SoCs with Arm Ltd.
cores, we skip the new RISC-V bits for now, as sunxi RISC-V support
is still work in progress.

Among smaller cosmetic changes, this adds a SATA regulator node which we
need in U-Boot to get rid of hard-coded GPIOs.
Also this updates the Allwinner F1C100s DTs, enabling USB support, and
also adds the DTs for two new boards.

As before, this omits the non-backwards compatible changes to the R_INTC
controller, to remain compatible with older kernels.

Signed-off-by: Andre Przywara <andre.przywara@arm.com>
2023-06-07 22:44:40 +01:00
Xavier Drudis Ferran
40359c9440 phy: rockchip-inno-usb2: Implement clock operations for usb2phy clock
This clock doesn't seem needed but appears in a phandle list used by
ehci-generic.c to bulk enable it. The phandle list comes from linux,
where it is needed for suspend/resume to work [1].

My tests give the same results with or without this patch, but Marek
Vasut found it weird to declare an empty clk_ops [2].

So I adapted the code from linux 6.1-rc8 so that it hopefully works
if it ever has some user. For now, without real use, it seems to
at least not give any errors when called.

Link: [1] https://lkml.kernel.org/lkml/1731551.Q6cHK6n5ZM@phil/T/
      [2] https://patchwork.ozlabs.org/project/uboot/patch/Y5IWpjYLB4aXMy9o@localhost/

Cc: Simon Glass <sjg@chromium.org>
Cc: Philipp Tomsich <philipp.tomsich@vrull.eu>
Cc: Kever Yang <kever.yang@rock-chips.com>
Cc: Lukasz Majewski <lukma@denx.de>
Cc: Sean Anderson <seanga2@gmail.com>
Cc: Marek Vasut <marex@denx.de>
Cc: Christoph Fritz <chf.fritz@googlemail.com>
Cc: Jagan Teki <jagan@amarulasolutions.com>

Signed-off-by: Xavier Drudis Ferran <xdrudis@tinet.cat>
Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
Reviewed-by: Jagan Teki <jagan@amarulasolutions.com>
Tested-by: Jagan Teki <jagan@amarulasolutions.com> # rk3399, rk3328, rv1126
2023-06-07 23:41:47 +02:00
Xavier Drudis Ferran
e81512ac30 phy: rockchip-inno-usb2: Add usb2phy clock provider of 480MHz clock
arch/arm/dts/rk3399.dtsi has a node

  usb_host0_ehci: usb@fe380000 {
       compatible = "generic-ehci";

with clocks:

       clocks = <&cru HCLK_HOST0>, <&cru HCLK_HOST0_ARB>,
                <&u2phy0>;

The first 2 refer to nodes with class UCLASS_CLK, but &u2phy0
has class UCLASS_PHY.

  u2phy0: usb2phy@e450 {
       compatible = "rockchip,rk3399-usb2phy";

Since clk_get_bulk() only looks for devices with UCLASS_CLK,
it fails with -ENODEV and then ehci_usb_probe() aborts.

The consequence is peripherals connected to a USB 2 port (e.g. in a
Rock Pi 4 the white port, nearer the edge) not being detected.
They're detected if CONFIG_USB_OHCI_GENERIC is selected in Kconfig,
because ohci_usb_probe() does not abort when one clk_get_by_index()
fails, but then they work in USB 1 mode.

rk3399.dtsi comes from linux and the  u2phy0 was added[1] to the clock
list in:

    commit b5d1c57299734f5b54035ef2e61706b83041f20c
    Author: William wu <wulf@rock-chips.com>
    Date:   Wed Dec 21 18:41:05 2016 +0800

    arm64: dts: rockchip: add u2phy clock for ehci and ohci of rk3399

    We found that the suspend process was blocked when it run into
    ehci/ohci module due to clk-480m of usb2-phy was disabled.
    [...]

Suspend concerns don't apply to U-Boot, and the problem with U-Boot
failing to probe EHCI doesn't apply to linux, because in linux
rockchip_usb2phy_clk480m_register makes u2phy0 a proper clock provider
when called by rockchip_usb2phy_probe().

So I can think of a few alternative solutions:

1- Change ehci_usb_probe() to make it more similar to
   ohci_usb_probe(), and survive failure to get one clock. Looks a
   little harder, and I don't know whether it could break something if
   it ignored a clock that was important for something else than
   suspend.

2- Change rk3399.dtsi effectively reverting the linux commit
   b5d1c57299734f5b54035ef2e61706b83041f20c. This dealigns the .dtsi
   from linux and seems fragile at the next synchronisation.

3- Change the clock list in rk3399-u-boot.dtsi or somewhere else.
   This survives .dts* sync but may survive "too much" and miss some
   change from linux that we might want.

4- Enable CONFIG_USB_OHCI_GENERIC and use the ports in USB 1 mode.
   This would need to be made for all boards using rk3399.  In a
   simple test reading one file from USB storage it gave 769.5 KiB/s
   instead of 20.5 MiB/s with solution 2.

5- Trying to replicate linux and have usb2phy somehow provide a clk,
   or have a separate clock device for usb2phy in addition to the phy
   device.

This patch tries to implement option 5 as Marek Vasut requested in
December 5th.  Options 1 and 3 didn't get through [2][3].

It just registers usb2phy as a clock driver (device_bind_driver()
didn't work but device_bind_driver_to_node() did), without any
specific operations, so that ehci-generic.c finds it and is happy. It
worked in my tests on a Rock Pi 4 B+ (rk3399).

Link: [1] https://lkml.kernel.org/lkml/1731551.Q6cHK6n5ZM@phil/T/
      [2] https://patchwork.ozlabs.org/project/uboot/patch/20220701185959.GC1700@begut/
      [3] https://patchwork.ozlabs.org/project/uboot/patch/Y44+ayJfUlI08ptM@localhost/

Cc: Simon Glass <sjg@chromium.org>
Cc: Philipp Tomsich <philipp.tomsich@vrull.eu>
Cc: Kever Yang <kever.yang@rock-chips.com>
Cc: Lukasz Majewski <lukma@denx.de>
Cc: Sean Anderson <seanga2@gmail.com>
Cc: Marek Vasut <marex@denx.de>
Cc: Christoph Fritz <chf.fritz@googlemail.com>
Cc: Jagan Teki <jagan@amarulasolutions.com>

Signed-off-by: Xavier Drudis Ferran <xdrudis@tinet.cat>
Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
Reviewed-by: Jagan Teki <jagan@amarulasolutions.com>
Tested-by: Jagan Teki <jagan@amarulasolutions.com> # rk3399, rk3328, rv1126
2023-06-07 23:41:47 +02:00
Sam Edwards
3cbd92da9f usb: musb-new: sunxi: fix error check
The `musb_register` function returns some ERR_PTR(...) on failure,
not NULL, so update the check here appropriately.

Signed-off-by: Sam Edwards <CFSworks@gmail.com>
Reviewed-by: Marek Vasut <marex@denx.de>
2023-06-07 23:38:51 +02:00
Tom Rini
0a8a4b8642 - meson_uart empty logic fix
-----BEGIN PGP SIGNATURE-----
 
 iQIzBAABCgAdFiEEPVPGJshWBf4d9CyLd9zb2sjISdEFAmSAbY0ACgkQd9zb2sjI
 SdGUlA/9FWZ+VEl/Q13Kdzpa765NYWXFDx2qsZgufDxEpw7TzP1gf2OktqlPW8t3
 gTl5AsLkD2nIdmzFDAWPz1rWINoxQ1AYlsj3xiRq8/Zjpn9Z9dtOODjfQvxQQ7kh
 YU3qJhQM/pNzieG25LU9uvRAkugwXztzlBw73I41zWoLMJ0kwm3amOGD7P5jyQk3
 CUL54qk1TU8NRSPsI49hrE2ZFkNNaed+rrFVLc95L40ekIGMMvtsEeAWyUm02bjp
 2Sy57+J5g1b313/C6wldP2YwqEGIORGyobKXg775Fvh+bU5kaYLY1cAaS2O8ZM2Z
 BTmjq4IZhDB3FS81KbtEBR2l/12Mdf4ColrM6xOo7rFBGEQypyU9DcxH2kK2o16O
 jul6dadlC3wXkzUTGwAfrf1l7PKMsT32XqHgD9qVogRyMeRe95izdyy30CV2DwGy
 +3aMOx1rZC/ia9MDjlHAh5kHBA3JkrlJW66ng7wTLQM6c2PVBU8E9UbHt2oX1z7c
 6n4Z8fT5VsoTZIYf3YIq/TMwBqOXK7Gy/JloKZUPzaZ9xxV22v/PXvYJT4mM5S+T
 Z1Xop/+l343m2X2E2mjanLlGxcWagcG83IDLdcr9y7OK7lJJGUz2bQHPwnlFUhZI
 IWNllB9xKQX6wBjFqs3HWalZ5BDXzy09OaFGiH/8TXW84cldus0=
 =9zwb
 -----END PGP SIGNATURE-----

Merge tag 'u-boot-amlogic-20230607' of https://source.denx.de/u-boot/custodians/u-boot-amlogic

- meson_uart empty logic fix
2023-06-07 12:17:06 -04:00
Mattijs Korpershoek
afa85a2247 serial: meson: fix meson_serial_pending() tx logic
According to the dm_serial_ops documentation, pending() should:
> @return number of waiting characters, 0 for none, -ve on error

And:
> It is acceptable to return 1 if an indeterminant number
> of characters is waiting.

With the current implementation, we have:
* FIFO is full           -> pending() returns 0
* FIFO is partially used -> pending() returns 1
* FIFO is empty          -> pending() returns 1

This is not the same as what the documentation requires.

Moreover, since [1], arm reset now flushes all console devices
(including serial) before the cpu gets reset.
Because of the flawed logic:

  => reset # user calls reset
  flush() is called
  _serial_flush() is called
  ops->pending(dev, false) # never returns false
  # board hangs indefinitely without resetting.

Fix it by using AML_UART_TX_EMPTY instead of AML_UART_TX_FULL.

[1] commit c5f4cdb8eb ("console: Use flush() before panic and reset"),

Signed-off-by: Mattijs Korpershoek <mkorpershoek@baylibre.com>
Acked-by: Neil Armstrong <neil.armstrong@linaro.org>
Link: https://lore.kernel.org/r/20230606-fix-meson-serial-pending-v1-1-6a54d4a01f76@baylibre.com
Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org>
2023-06-07 10:09:20 +02:00
Tom Rini
fadf83c86d Merge tag 'ubifixes-for-v2023-07-rc4' of https://source.denx.de/u-boot/custodians/u-boot-ubi
ubifs changes for v2023.07-rc4

UBIFS fixes from Ben Dooks

- ubifs: allow loading to above 4GiB
2023-06-06 09:47:17 -04:00
Tom Rini
d39277ff42 Merge tag 'for-v2023-07-rc4' of https://source.denx.de/u-boot/custodians/u-boot-i2c
i2c updates for v2023-07-rc4

Bugfixes:
- rockchip: De-initialize the bus after start bit failure
  from Ondrej Jirman

- cdns: Fix broken retry mechanism on arbitration lost
2023-06-06 09:46:27 -04:00
Ben Dooks
b46cec4166 ubifs: allow loading to above 4GiB
The ubifsload command is truncating any address above 4GiB as it casts
this address to an u32, instead of using an unsigned long which most of
the other load commands do. Change this to an unsigned long to allow
loading into high memory for boards which use these areas.

Fixes the following error:

=> ubifsload 0x2100000000 /boot/Image.lzma
Loading file '/boot/Image.lzma' to addr 0x00000000...
Unhandled exception: Store/AMO access fault

Signed-off-by: Ben Dooks <ben.dooks@sifive.com>
Signed-off-by: Ben Dooks <ben.dooks@codethink.co.uk>
2023-06-06 10:37:25 +02:00
Andrea Merello
419ddf944c I2C: cdns: Fix broken retry mechanism on arbitration lost.
In the current implementation, in case of I2C arbitration lost, a retry is
attempted; the message counter and pointer are reset to the original values
and the I2C xfer process is restart from the beginning.

However the message counter and message pointer are respectively
decremented and incremented by one before attempting any transfer, causing
the 1st transfer not to be actually retried (in case of a single transfer,
nothing is actually retried at all).

This patch fixes this: in case of retry, the 1st transfer is also retried.

Tested on a ZynqMP Kria board, with upstream older u-boot, but the involved
file and underlying logic seem basically the same.

Signed-off-by: Andrea Merello <andrea.merello@iit.it>
2023-06-05 06:54:25 +02:00
Ondrej Jirman
ba5b9203f5 i2c: rockchip: De-initialize the bus after start bit failure
Failure can happen when i2c is used without initializing pinctrl properly,
which U-Boot happily allows in SPL. Without this fix, further I2C access would
fail, even after proper pinctrl initialization.

Signed-off-by: Ondrej Jirman <megi@xff.cz>
Cc: Heiko Schocher <hs@denx.de>
Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
Reviewed-by: Heiko Schocher <hs@denx.de>
2023-06-05 06:52:46 +02:00
Tom Rini
26659d4265 Pull request efi-2023-07-rc4
Documentation:
 
 * man pages for loadb, loadx
 
 UEFI:
 
 * check return value of part_get_info()
 * improve unit test for RegisterProtocolNotify()
 -----BEGIN PGP SIGNATURE-----
 
 iQIzBAABCAAdFiEEbcT5xx8ppvoGt20zxIHbvCwFGsQFAmR5wToACgkQxIHbvCwF
 GsRSeA//bNyY18niu1qBL4gKhljyRv/rurqU3a5hiyC8yOcbSXsHh0cmFoi++yrj
 PxE0urD2CIMaXMnp97aFjcR4JweIjlV9PSAOcnvrjERJYJSZ7+dOeRQS6LUQuQxf
 1AaEu0HGljflfuUL4IZEBUYukeLAY4qMUCpI/Etq89XFXxELWTmUi0Rm/KtUmPmb
 /BP6Hto8+Mj26HOkUWeWA7AhCpNH7HPz8/PyE2BMWEgCh1vFUHmG0iRv92SPzkLp
 vR/V/0jhWTIYNGrdOeQHTmWcFaca6DrrSXMbEcCwsEPaMv4YJy49XKjhe40IMhZv
 Mj7k5jaEVE/M+QG3VUCinwe5zayPvlooSDO+2VQ2DRm6akqBc+gumb4D6fjaRrTt
 /+PO44zO0T0D5qyY4cPgYZvVXsodBzQ20C3OAJw8LNPhw2MTAPTnmS810X9aSSsc
 V9w/J2Hu+RzIzSF5wQrP3ZLKhFS2hvjm2I4DENCj8MUCdQ15UaCkWi2vUBLOMCcy
 hngTOEyWFJc/YtAf3Eak39a0k0EqIDQggLVaCPFKeictG2nF9YsiEzyctiAXPVn0
 rWF9aULa26jc8bs9Yw0nz39uIqNpPKjEwJKXZZT9AAGOi06tvRNk6Is56v89gC6h
 bYHoErdQcaJK6f3MUzCCtDmw29tO+oBKKv0MbTXszqp6VT25/vg=
 =rUPv
 -----END PGP SIGNATURE-----

Merge tag 'efi-2023-07-rc4' of https://source.denx.de/u-boot/custodians/u-boot-efi

Pull request efi-2023-07-rc4

Documentation:

* man pages for loadb, loadx

UEFI:

* check return value of part_get_info()
* improve unit test for RegisterProtocolNotify()
2023-06-02 12:13:01 -04:00
Heinrich Schuchardt
75ebeb4d94 efi_selftest: LocateHandleBuffer return code
Check that LocateHandleBuffer() return EFI_NOT_FOUND when called with
ByRegisterNotify and all handles already have been retrieved.

Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
Reviewed-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
2023-06-02 10:59:15 +02:00
Heinrich Schuchardt
1becdfcdc1 efi_loader: check return value of part_get_info()
part_get_info() may return an error code. Check it.
Update function description of dp_part_node().

Addresses-Coverity-ID: 184067 ("Unchecked return value")
Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
2023-06-02 10:59:15 +02:00
Bin Meng
5a2d5cbd31 doc: android: Fix a typo
%s/than/then

Signed-off-by: Bin Meng <bmeng@tinylab.org>
Reviewed-by: Mattijs Korpershoek <mkorpershoek@baylibre.com>
Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
2023-06-02 10:59:15 +02:00
Heinrich Schuchardt
f37513c3ad doc: fix loady man-page
* loady may return $? = 1.
* Move misplaced description

Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
2023-06-02 10:59:15 +02:00
Heinrich Schuchardt
a2c0e3595a doc: loadx man-page
Provide a man-page for the loadx command.

Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
2023-06-02 10:59:15 +02:00
Heinrich Schuchardt
e48f29d7ca doc: loadb man-page
Provide a man-page for the loadb command.

Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
2023-06-02 10:59:15 +02:00
Tom Rini
ac6096fe9c Merge branch '2023-06-01-assorted-platform-updates' into next
- Assorted updates for TI, nuvoton, sandbox and Xen platforms
2023-06-01 15:43:38 -04:00
Nishanth Menon
fb3474bef0 arm: mach-k3: am625_init: Add Erratum WA for RTC startup
In the first silicon revision of the am62x family of SoCs, the hardware
wakeup event cannot be used if software is unable to unlock the RTC
device within one second after boot. To work around this limitation
unlock RTC as soon as possible in the boot flow to maximize our chance
of linux being able to use this device.

Add the erratum i2327 workaround to initialize the RTC.

Signed-off-by: Nishanth Menon <nm@ti.com>
[bb@ti.com: rebased from 2021.01 and expanded commit and code messages]
Signed-off-by: Bryan Brattlof <bb@ti.com>
2023-06-01 12:40:16 -04:00
Yegor Yefremov
e0feee58ac arm: baltos: switch to CONFIG_DM_I2C
Also use the TPS65910 driver directly.

Signed-off-by: Yegor Yefremov <yegorslists@googlemail.com>
2023-06-01 12:40:16 -04:00
Ravi Gunasekaran
eab13ca620 phy: ti: phy-j721e-wiz: Add j721s2-wiz-10g module support
Add support for j721s2-wiz-10g device to use clock-names interface
instead of explicitly defining clock nodes within device tree node.

Signed-off-by: Ravi Gunasekaran <r-gunasekaran@ti.com>
2023-06-01 12:40:16 -04:00
Kamlesh Gurudasani
0688ff3ae2 arm: mach-k3: arm64-mmu: do not map ATF and OPTEE regions in A53 MMU
ATF and OPTEE regions may be firewalled from non-secure entities.
If we still map them for non-secure A53, speculative access may happen,
which will not cause any faults and related error response will be ignored,
but it's better to not to map those regions for non-secure A53 as there
will be no actual access at all.

Create separate table as ATF region is at different locations for am64
and am62/am62a.

Signed-off-by: Kamlesh Gurudasani <kamlesh@ti.com>
2023-06-01 12:40:16 -04:00
Bhavya Kapoor
414cad08cb arm: mach-k3: j7200: clk-data.c: Add main_uart1 clock data
Add main_uart1 clocks in clk-data.c for J7200. Now,
main_uart1 clocks will be set up while booting the J7200 SoC.

Signed-off-by: Bhavya Kapoor <b-kapoor@ti.com>
2023-06-01 12:40:16 -04:00
Bhavya Kapoor
f8504792e8 arm: mach-k3: j7200: dev-data.c: Add main_uart1 device data
Add device data for main_uart1 in dev-data.c for J7200. Now,
main_uart1 will be powered on while booting the J7200 SoC.

Signed-off-by: Bhavya Kapoor <b-kapoor@ti.com>
2023-06-01 12:40:16 -04:00
Udit Kumar
5019170970 arch: arm: mach-k3: j721e: add support for UDA FS
When selecting UDA partition for booting. MMC read
mode was selected as RAW.

Due to growing/changing size of u-boot and tispl
images.
It will be better change to FS in case of UDA FS instead of
adjusting offsets with new change.

Signed-off-by: Udit Kumar <u-kumar1@ti.com>
2023-06-01 12:32:04 -04:00
Udit Kumar
0eade94f80 configs: j7200: correct mmc offset
This patch corrects the MMC raw mode sector offset.

Current allocated size for tiboot3 is 1MB and 2MB for tispl.

Without this correct offset eMMC boot will fail.

Fixes: f8c1e893c8 (configs: j7200_evm_a72: Add Initial suppot)
Fixes: 02dff65efe (configs: j7200_evm_r5: Add initial support)
Fixes: 360c7f46f3 (configs: Add configs for J7200 High Security EVM)

Way to test with eMMC boot from boot0/1 partition
Boot with SD card, copy images to eMMC boot0 or boot1 partition

=> mmc dev 0 (1 or 2)
=> fatload mmc 1 ${loadaddr} tiboot3.bin
=> mmc write ${loadaddr} 0x0 0x800
=> fatload mmc 1 ${loadaddr} tispl.bin
=> mmc write ${loadaddr} 0x800 0x1000
=> fatload mmc 1 ${loadaddr} u-boot.img
=> mmc write ${loadaddr} 0x1800 0x2000
=> mmc partconf 0 1 (1 or 2) 1
=> mmc bootbus 0 2 0 0

Cc: Bhavya Kapoor <b-kapoor@ti.com>
Cc: Diwakar Dhyani <d-dhyani@ti.com>
Cc: KEERTHY <j-keerthy@ti.com>
Signed-off-by: Udit Kumar <u-kumar1@ti.com>
2023-06-01 12:32:04 -04:00
Udit Kumar
db7af51020 doc: board: ti: add documenation for j7200
This patch adds documentation for j7200.

TRM link
https://www.ti.com/lit/pdf/spruiu1

Signed-off-by: Udit Kumar <u-kumar1@ti.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
2023-06-01 12:32:03 -04:00