For lockstep mode, cpu_release function is expecting to execute
on R5 core 0, if there is attempt to pass other than R5 core 0,
through an error saying "Lockstep mode should run on R5 core 0 only".
Signed-off-by: Venkatesh Yadav Abbarapu <venkatesh.abbarapu@amd.com>
Link: https://lore.kernel.org/r/20230608032152.980-3-venkatesh.abbarapu@amd.com
Signed-off-by: Michal Simek <michal.simek@amd.com>
While invoking "zynqmp tcminit mode" command (which is invalid command)
on U-Boot, it just works. Check the mode param, if it is valid then
only initialize the TCM.
Signed-off-by: Venkatesh Yadav Abbarapu <venkatesh.abbarapu@amd.com>
Link: https://lore.kernel.org/r/20230608032152.980-2-venkatesh.abbarapu@amd.com
Signed-off-by: Michal Simek <michal.simek@amd.com>
This patch adds the PCIe controller driver for the Xilinx / AMD ZynqMP
NWL PCIe Bridge as root port. The driver source is partly copied from
the Linux PCI driver and modified to enable usage in U-Boot (e.g.
simplified and interrupt support removed).
Signed-off-by: Stefan Roese <sr@denx.de>
Cc: Simon Glass <sjg@chromium.org>
Cc: Pali Rohár <pali@kernel.org>
Cc: Bin Meng <bmeng.cn@gmail.com>
Cc: Michal Simek <michal.simek@amd.com>
Tested-by: Michal Simek <michal.simek@amd.com>
Acked-by: Michal Simek <michal.simek@amd.com>
Reviewed-by: Pali Rohár <pali@kernel.org>
Link: https://lore.kernel.org/r/20230525094918.111949-1-sr@denx.de
Signed-off-by: Michal Simek <michal.simek@amd.com>
Process errors from command via cmd_process_error() as is done on Versal.
When internal function returns different number then CMD_RET_SUCCESS(0),
CMD_RET_FAILURE(1) or CMD_RET_USAGE(-1) shell react on these errors by
throwing an error like
"exit not allowed from main input shell." that's why use
cmd_process_error() to make sure that error code is all the time correct.
Signed-off-by: Michal Simek <michal.simek@amd.com>
Link: https://lore.kernel.org/r/d511935ba10daf95c70996fae6e6ffc374efffa0.1685618464.git.michal.simek@amd.com
The Xilinx ZynqMP SoC has a hardened display pipeline named DisplayPort
Subsystem. It includes a buffer manager, blender, an audio mixer and a
DisplayPort source controller (transmitter). The DisplayPort controller can
source data from memory (non-live input) or the stream (live input). The
DisplayPort controller is responsible for managing the link and physical
layer functionality. The controller packs audio/video data into transfer
units and sends them over the main link. The link rate and lane counts can
be selected based on the application bandwidth requirements. The
DisplayPort pipeline consists of the DisplayPort direct memory access (DMA)
for fetching data from memory. The DisplayPort DMA controller (DPDMA)
supports up to six input channels as non-live input.
This driver supports the DisplayPort Subsystem and implements
1)640x480 resolution
2)RGBA8888 32bpp format
3)DPDMA channel 3 for Graphics
4)Non-live input
5)Fixed 5.4G link rate
6)Tested on ZCU102 board
There will be additional work to configure GT lines based on DT, higher
resolutions, support for more compressed video formats, spliting code to
more files, add support for EDID, audio support, using clock framework for
all clocks and in general code clean up.
Codevelop-by: Michal Simek <michal.simek@amd.com>
Signed-off-by: Venkatesh Yadav Abbarapu <venkatesh.abbarapu@amd.com>
Signed-off-by: Michal Simek <michal.simek@amd.com>
Link: https://lore.kernel.org/r/5c1567b63d0280dacc7efba2998857c399c25358.1684312924.git.michal.simek@amd.com
Add support for RGBA8888 32bpp format where pixels are picked in
32-bit integers, where the colors are stored in memory such that
R is at lowest address, G after that, B after that, and A last.
Signed-off-by: Venkatesh Yadav Abbarapu <venkatesh.abbarapu@amd.com>
Signed-off-by: Michal Simek <michal.simek@amd.com>
Link: https://lore.kernel.org/r/aa1de54b7d4ff46df6858f76d52634e0c5c71a4a.1684312924.git.michal.simek@amd.com
Store the driver data in the data section to make the data usable before
relocation. Additionally mark the driver data static to restrict the
access.
Signed-off-by: Stefan Herbrechtsmeier <stefan.herbrechtsmeier@weidmueller.com>
Link: https://lore.kernel.org/r/20230523124215.30915-5-stefan.herbrechtsmeier-oss@weidmueller.com
Signed-off-by: Michal Simek <michal.simek@amd.com>
Move the permission to change a config object message from
zynqmp_pmufw_load_config_object function to zynqmp_pmufw_node function
to simplify the code and check the permission only if required.
Signed-off-by: Stefan Herbrechtsmeier <stefan.herbrechtsmeier@weidmueller.com>
Link: https://lore.kernel.org/r/20230523124215.30915-4-stefan.herbrechtsmeier-oss@weidmueller.com
Signed-off-by: Michal Simek <michal.simek@amd.com>
Remove the redundant child device bind from the driver bind function and
rely on the post_bind of the class which calls the same function.
Signed-off-by: Stefan Herbrechtsmeier <stefan.herbrechtsmeier@weidmueller.com>
Link: https://lore.kernel.org/r/20230523124215.30915-2-stefan.herbrechtsmeier-oss@weidmueller.com
Signed-off-by: Michal Simek <michal.simek@amd.com>
Return a common -EACCES error value instead of a positive private error
value XST_PM_NO_ACCESS (2002) in zynqmp_pmufw_load_config_object
function if the config object is not loadable to simplify the error
checking.
Signed-off-by: Stefan Herbrechtsmeier <stefan.herbrechtsmeier@weidmueller.com>
Link: https://lore.kernel.org/r/20230523124215.30915-1-stefan.herbrechtsmeier-oss@weidmueller.com
Signed-off-by: Michal Simek <michal.simek@amd.com>
Production version restarting platform version field from 0 that's why add
new calculation to be able to use different DT for these platforms.
Requested DT names for production silicons for IPP/SPP and EMU platform are
versal-net-ipp-rev2.0.dts and versal-net-emu-rev2.0.dts.
If platform version increase numbers revision can be even higher.
As of today platform version is 2 that's why expected is rev2.2.
Signed-off-by: Michal Simek <michal.simek@amd.com>
Link: https://lore.kernel.org/r/691e166b3cf2643d7edf482bda5500163eecb35a.1684311689.git.michal.simek@amd.com
For sf commands, when '0' length is passed for erase, update, write or
read, there might be undesired results. Ideally '0' length means nothing to
do.
So print 'ERROR: Invalid size 0' and return cmd failure when length '0' is
passed to sf commands. Same thing applies for nand commands also.
Example:
ZynqMP> sf erase 0 0
ERROR: Invalid size 0
ZynqMP> sf write 10000 0 0
ERROR: Invalid size 0
ZynqMP> sf read 10000 0 0
ERROR: Invalid size 0
ZynqMP> sf update 1000 10000 0
ERROR: Invalid size 0
ZynqMP>
Signed-off-by: Ashok Reddy Soma <ashok.reddy.soma@amd.com>
Link: https://lore.kernel.org/r/20230516115236.22458-1-ashok.reddy.soma@amd.com
Signed-off-by: Michal Simek <michal.simek@amd.com>
Add fallthrough statement in switch case to fix the sparse warning.
In function 'zynqmp_clk_get_rate': warning: this statement may
fall through [-Wimplicit-fallthrough=]
Signed-off-by: Algapally Santosh Sagar <santoshsagar.algapally@amd.com>
Signed-off-by: Venkatesh Yadav Abbarapu <venkatesh.abbarapu@amd.com>
Link: https://lore.kernel.org/r/20230519113816.22083-2-venkatesh.abbarapu@amd.com
Signed-off-by: Michal Simek <michal.simek@amd.com>
Read boodmode register using versal_net_get_bootmode() in board_late_init
and prepare corresponding distro boot command sequence based on it.
versal_net_get_bootmode() will be changed to use smc calls later, but
for now directly reads the register.
Signed-off-by: Ashok Reddy Soma <ashok.reddy.soma@amd.com>
Link: https://lore.kernel.org/r/20230516144753.30869-1-ashok.reddy.soma@amd.com
Signed-off-by: Michal Simek <michal.simek@amd.com>
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>
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]
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]
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>
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.
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>
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>
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
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
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>
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>
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
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>
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>
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>
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()
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>
