Tom Rini [Thu, 12 Oct 2023 23:03:54 +0000 (19:03 -0400)]
include: Add <linux/types.h> in a few places
These files references a number of types that are defined in
<linux/types.h> (and so forth), so include it here rather than rely on
indirect inclusion.
Signed-off-by: Tom Rini <trini@konsulko.com> Reviewed-by: Simon Glass <sjg@chromium.org>
Yurii Monakov [Tue, 10 Oct 2023 08:16:39 +0000 (11:16 +0300)]
cli: Consume invalid escape sequences early
Unexpected 'Esc' key presses are accumulated internally, even if it is
already clear that the current escape sequence is invalid. This results
in weird behaviour. For example, the next character after 'Esc' key
simply disappears from input and 'Unknown command' is printed
after 'Enter'.
This commit fixes some issues with extra 'Esc' keys entered by user:
1. Sequence <Esc><Esc><Enter> right after autoboot stop gives:
=>
nknown command 'ry 'help'
=>
2. Sequence <Esc><p><r><i><Enter> gives:
=> ri
Unknown command 'ri' - try 'help'
=>
3. Extra 'Esc' key presses break backspace functionality.
Signed-off-by: Yurii Monakov <monakov.y@gmail.com> Reviewed-by: Simon Glass <sjg@chromium.org>
Tom Rini [Tue, 24 Oct 2023 13:39:52 +0000 (09:39 -0400)]
Merge tag 'u-boot-rockchip-20231024' of https://source.denx.de/u-boot/custodians/u-boot-rockchip
- Add Board: rk3588 NanoPC-T6, Orange Pi 5, Orange Pi 5 Plus;
- clk driver fix for rk3568 and rk3588;
- rkmtd cmd support for rockchip nand device;
- dts update and sync from linux;
Johan Jonker [Wed, 18 Oct 2023 14:01:59 +0000 (16:01 +0200)]
rockchip: test: dm: add rkmtd test
Add Rockchip rkmtd test:
Create/attach/detach RKMTD device.
Send/read data with Rockchip boot block header.
Test that reusing the same label should work.
Basic test of 'rkmtd' commands.
Signed-off-by: Johan Jonker <jbx6244@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com> Reviewed-by: Simon Glass <sjg@chromium.org>
Johan Jonker [Wed, 18 Oct 2023 14:01:40 +0000 (16:01 +0200)]
rockchip: cmd: add rkmtd command
The command rkmtd creates a virtual block device to transfer
Rockchip boot block data to and from NAND with block orientated
tools like "ums" and "rockusb".
It uses the Rockchip MTD driver to scan for boot blocks and copies
data from the first block in a GPT formated virtual disk.
Data must be written in U-boot "idbloader.img" format and start at
partition "loader1" offset 64. The data header is parsed
for length and offset. When the last sector is received
it erases up to 5 erase blocks on NAND and writes bootblocks
in a pattern depending on the NAND ID. Data is then verified.
When a block turns out bad the block header is discarded.
Signed-off-by: Johan Jonker <jbx6244@gmail.com> Reviewed-by: Simon Glass <sjg@chromium.org>
Johan Jonker [Wed, 18 Oct 2023 14:00:56 +0000 (16:00 +0200)]
rockchip: block: add rkmtd class and drivers
Add rkmtd class and drivers to create a virtual block device
to transfer Rockchip boot block data to and from NAND with
block orientated tools like "ums" and "rockusb".
Signed-off-by: Johan Jonker <jbx6244@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
On Rockchip SoCs the first boot stages are written on NAND
with help of manufacturer software that uses a different format
then the MTD framework. Skip the automatic BBT scan with the
NAND_SKIP_BBTSCAN option to be able to pass the driver probe
function and to let the original data unchanged.
Signed-off-by: Johan Jonker <jbx6244@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
Jonas Karlman [Tue, 17 Oct 2023 21:40:22 +0000 (21:40 +0000)]
board: rockchip: Add Xunlong Orange Pi 5 Plus
Xunlong Orange Pi 5 Plus is a single-board computer based on the
Rockchip RK3588 SoC. The board provides abundant interfaces, including
two HDMI output ports, one HDMI input port, two 2.5G Ethernet ports,
M.2 M-Key slot, M.2 E-Key slot, two USB 3.0, two USB 2.0, and two Type-C.
Features tested on a Orange Pi 5 Plus 4GB v1.2:
- SD-card boot
- eMMC boot
- SPI Flash boot
- PCIe/NVMe
- USB 2.0 host
- Ethernet
Device tree is imported from linux v6.7-rockchip-dts64-1 tag.
Signed-off-by: Jonas Karlman <jonas@kwiboo.se> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
Jonas Karlman [Tue, 17 Oct 2023 21:40:21 +0000 (21:40 +0000)]
board: rockchip: Add Xunlong Orange Pi 5
Xunlong Orange Pi 5 is a single-board computer based on the Rockchip
RK3588S SoC. The board provides abundant interfaces, HDMI output, GPIO
interface, M.2 PCIe2.0, Type-C, Gigabit LAN port, 2*USB2.0, 1*USB3.0,
etc.
Features tested on a Orange Pi 5 4GB v1.2:
- SD-card boot
- SPI Flash boot
- PCIe/NVMe
- USB 2.0 host
- Ethernet
Device tree is imported from linux v6.7-rockchip-dts64-1 tag.
Signed-off-by: Jonas Karlman <jonas@kwiboo.se> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
Jonas Karlman [Tue, 17 Oct 2023 17:02:11 +0000 (17:02 +0000)]
rockchip: rk3588-rock-5b: Sync USB3 nodes from mainline linux patches
The device tree for rk3588 and rock-5b contain usb3 nodes that have
deviated too much from current state of submitted mainline linux usb3
patches, see [1].
Sync usb3 related nodes from latest patches and collaboras rk3588 tree
so that dwc3-generic driver can be updated to include support for the
rockchip,rk3588-dwc3 compatible in the future, use rockchip,rk3568-dwc3
compatible until final node is merged in linux maintainer tree.
Jonas Karlman [Tue, 17 Oct 2023 17:02:10 +0000 (17:02 +0000)]
rockchip: rk3588-rock-5b: Enable support for PCIe SATA cards
Enable support for PCIe SATA cards and the on-board SATA controller.
This also revert use of CONFIG_PCI_INIT_R in order to speed up boot from
eMMC or SD-cards. Standard boot will initialize pci after faster boot
media have been enumerated.
Signed-off-by: Jonas Karlman <jonas@kwiboo.se> Reviewed-by: Christopher Obbard <chris.obbard@collabora.com> Tested-by: Christopher Obbard <chris.obbard@collabora.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
Jonas Karlman [Tue, 17 Oct 2023 17:02:08 +0000 (17:02 +0000)]
rockchip: rk3588: Sync device tree from v6.7-rockchip-dts64-1 tag
Sync rk3588 device tree from v6.7-rockchip-dts64-1 tag.
Adds PCIe, button and led nodes to rk3588-evb1-v10 and rk3588-rock-5b
boards. Also remove includes from u-boot.dtsi-files that is no longer
needed.
Linux commits: 42145b7a8235 ("arm64: dts: rockchip: add PCIe network controller to rock-5b") 199cbd5f195a ("arm64: dts: rockchip: add PCIe for M.2 M-key to rock-5b") da447ec38780 ("arm64: dts: rockchip: add PCIe for M.2 E-Key to rock-5b") 86a2024d95e2 ("arm64: dts: rockchip: add PCIe2 network controller to rk3588-evb1") 46bb398ea1d8 ("arm64: dts: rockchip: add PCIe3 bus to rk3588-evb1") 1c9a53ff7ece ("arm64: dts: rockchip: Add sdio node to rock-5b") 3eaf2abd11aa ("arm64: dts: rockchip: Add sfc node to rk3588s") bf012368bb0a ("arm64: dts: rockchip: Add I2S2 M0 pin definitions to rk3588s") 3d77a3e51b0f ("arm64: dts: rockchip: Add UART9 M0 pin definitions to rk3588s") 0002c377e862 ("arm64: dts: rockchip: Remove duplicate regulator vcc3v3_wf from rock-5b") a6169ab36923 ("arm64: dts: rockchip: Enable UART6 on rock-5b") dd6dc0c4c126 ("arm64: dts: rockchip: Add AV1 decoder node to rk3588s") afa933c208e5 ("arm64: dts: rockchip: add ADC buttons to rk3588-evb1") 7952cbbda301 ("arm64: dts: rockchip: add status LED to rock-5b")
Signed-off-by: Jonas Karlman <jonas@kwiboo.se> Reviewed-by: Christopher Obbard <chris.obbard@collabora.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
Simon Glass [Mon, 23 Oct 2023 07:02:13 +0000 (00:02 -0700)]
bootstd: Scan all bootdevs in a boot_targets entry (take 2)
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.
Simon Glass [Mon, 23 Oct 2023 07:02:12 +0000 (00:02 -0700)]
bootstd: Correct logic for single uclass
The current logic for "bootflow mmc" is flawed since it checks the
uclass of the bootdev instead of its parent, the media device. Correct
this and add a test that covers this scenario.
Signed-off-by: Simon Glass <sjg@chromium.org> Tested-by: Ivan T.Ivanov <iivanov@suse.de>
Simon Glass [Mon, 23 Oct 2023 07:02:10 +0000 (00:02 -0700)]
Revert "bootstd: Scan all bootdevs in a boot_targets entry"
This commit was intended to allow all bootdevs in each boot_targets
entry to be scanned. However it causes bad ordering with bootdevs, e.g.
scanning Ethernet bootdevs when it should be keeping to mmc.
Tom Rini [Mon, 23 Oct 2023 13:04:55 +0000 (09:04 -0400)]
Merge branch 'master' of https://source.denx.de/u-boot/custodians/u-boot-sunxi
This is mostly about support for the Allwinner R528/T113s SoC, which is
reportedly the same die as the Allwinner D1, but with the two
Arm Cortex-A7 cores activated instead of the RISC-V one.
Using sunxi code outside of arch/arm proved to be difficult, so apart
from enabling this Arm SoC, the patches also prepare for more refactoring
to get the D1 nicely supported some day:
- We get rid of some Kconfig (hard-)coded GPIO pins, responsible for
enabling regulators.
- The GPIO code is moved out of arch/arm, into drivers/gpio.
- Some definitions are moved out of header files under asm/arch.
- Some T113s/D1 specific definitions are guarded by a generic Kconfig
symbol (CONFIG_SUNXI_GEN_NCAT2).
- The DRAM controller initialisation code is located under drivers/ram.
- The base SoC .dtsi files are shared (under arch/riscv, as in Linux).
Of course there are also the usual new SoC specific patches, like clock
and pinmux descriptions, alongside a rework of the pinctrl code, since
Allwinner changed the GPIO register layout, for the first time since
sunxi's inception.
On top of this the PSCI code sees some update, to provide SMP services
for R528/T113s boards. Many thanks to Sam for providing this code and
staying strong through the review cycles.
The final patch enables support for one popular board, I hope to see
more DTs and defconfigs contributed in the future!
Many thanks to all the various contributors, testers and reviewers,
that series was a real team effort!
Artur Rojek [Wed, 18 Oct 2023 14:00:59 +0000 (16:00 +0200)]
board: Add support for Conclusive KSTR-SAMA5D27
Introduce support for Conclusive KSTR-SAMA5D27 Single Board Computer.
Co-developed-by: Jakub Klama <jakub@conclusive.pl> Signed-off-by: Jakub Klama <jakub@conclusive.pl> Co-developed-by: Marcin Jabrzyk <marcin@conclusive.pl> Signed-off-by: Marcin Jabrzyk <marcin@conclusive.pl> Signed-off-by: Artur Rojek <artur@conclusive.pl>
Artur Rojek [Wed, 18 Oct 2023 14:00:57 +0000 (16:00 +0200)]
event: add new EVT_SETTINGS_R event
Introduce EVT_SETTINGS_R, triggered post-relocation and before console
init.
This event gives an option to perform any platform-dependent setup,
which needs to take place before show_board_info(). Usage examples
include readout of EEPROM stored settings.
Signed-off-by: Artur Rojek <artur@conclusive.pl> Reviewed-by: Simon Glass <sjg@chromium.org>
Elaine Zhang [Thu, 12 Oct 2023 10:18:28 +0000 (18:18 +0800)]
clk: rockchip: rk3588: fix up the frac pll calculation
rk3588 frac pll:
FFVCO = ((m + k / 65536) * FFIN) / p
FFOUT = ((m + k / 65536) * FFIN) / (p * 2s)
k is the original code, but the K[15:0] is complement code
(6'b1000_0000_0000_0000 <= K[15:0] <= 16'b0111_1111_1111_1111),
need to be converted.
Signed-off-by: Elaine Zhang <zhangqing@rock-chips.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
Sam Edwards [Thu, 12 Oct 2023 01:47:56 +0000 (19:47 -0600)]
sunxi: psci: implement PSCI on R528
This patch adds the necessary code to make nonsec booting and PSCI
secondary core management functional on the R528/T113.
Signed-off-by: Sam Edwards <CFSworks@gmail.com> Tested-by: Maksim Kiselev <bigunclemax@gmail.com> Tested-by: Kevin Amadiva <kevin.amadiva@mec.at> Reviewed-by: Andre Przywara <andre.przywara@arm.com>
Sam Edwards [Thu, 12 Oct 2023 01:47:55 +0000 (19:47 -0600)]
sunxi: psci: stop modeling register layout with C structs
Since the sunxi support nowadays generally prefers #defined register
offsets instead of modeling register layouts using C structs, now is a
good time to do this for PSCI as well. This patch moves away from using
the structs `sunxi_cpucfg_reg` and `sunxi_prcm_reg` in psci.c.
The former struct and its associated header file existed only to support
PSCI code, so also delete them altogether.
Signed-off-by: Sam Edwards <CFSworks@gmail.com> Reviewed-by: Andre Przywara <andre.przywara@arm.com>
Sam Edwards [Thu, 12 Oct 2023 01:47:54 +0000 (19:47 -0600)]
sunxi: psci: refactor register access to separate functions
This is to prepare for R528, which does not have the typical
"CPUCFG" block; it has a "CPUX" block which provides these
same functions but is organized differently.
Moving the hardware-access bits to their own functions separates the
logic from the hardware so we can reuse the same logic.
Signed-off-by: Sam Edwards <CFSworks@gmail.com> Reviewed-by: Andre Przywara <andre.przywara@arm.com>
Sam Edwards [Thu, 12 Oct 2023 01:47:53 +0000 (19:47 -0600)]
sunxi: psci: clean away preprocessor macros
This patch restructures psci.c to get away from the "many different
function definitions switched by #ifdef" paradigm to the preferred style
of having a single function definition with `if (IS_ENABLED(...))` to
make the optimizer include only the appropriate function bodies instead.
There are no functional changes here.
Signed-off-by: Sam Edwards <CFSworks@gmail.com> Reviewed-by: Andre Przywara <andre.przywara@arm.com>
Andre Przywara [Sat, 2 Jul 2022 23:14:24 +0000 (00:14 +0100)]
sunxi: refactor serial base addresses to avoid asm/arch/cpu.h
At the moment we have each SoC's memory map defined in its own cpu.h,
which is included in include/configs/sunxi_common.h. This will be a
problem with the introduction of Allwinner RISC-V support.
Remove the inclusion of that header file from the common config header,
instead move the required serial base addresses (for the SPL) into a
separate header file. Then include the original cpu.h file only where
we really need it, which is only under arch/arm now.
This disentangles the architecture specific header files from the
generic code.
Signed-off-by: Andre Przywara <andre.przywara@arm.com>
Andre Przywara [Tue, 6 Sep 2022 14:59:57 +0000 (15:59 +0100)]
sunxi: add Allwinner R528/T113 SoC support
This adds the remaining code bits to teach U-Boot about Allwinner's
newest SoC generation. This was introduced with the RISC-V based
Allwinner D1 SoC, which actually shares a die with the ARM cores versions
called R528 (BGA, without DRAM) and T113s (QFP, with embedded DRAM).
This adds the new Kconfig stanza, using the two newly introduced symbols
for the new SoC generation and pincontroller. It also adds the new symbols
to the relavent code places, to set all the hardcoded bits directly.
We need one DT override:
The ARM core version of the DT specifies the CPUX watchdog as
"reserved", which means it won't be recognised by U-Boot. Override this
in our generic sunxi-u-boot.dtsi, to let U-Boot pick up this watchdog,
so that the generic reset driver will work.
Signed-off-by: Andre Przywara <andre.przywara@arm.com>
Andre Przywara [Sat, 31 Dec 2022 18:38:21 +0000 (18:38 +0000)]
sunxi: add R528/T113-s3/D1(s) DRAM initialisation code
The Allwinner R528/T113-s/D1/D1s SoCs all share the same die, so use the
same DRAM initialisation code.
Make use of prior art here and lift some code from awboot[1], which
carried init code based on earlier decompilation efforts, but with a
GPL2 license tag.
This code has been heavily reworked and cleaned up, to match previous
DRAM routines for other SoCs, and also to be closer to U-Boot's coding
style and support routines.
The actual DRAM chip timing parameters are included in the main file,
since they cover all DRAM types, and are protected by a new Kconfig
CONFIG_SUNXI_DRAM_TYPE symbol, which allows the compiler to pick only
the relevant settings, at build time.
The relevant DRAM chips/board specific configuration parameters are
delivered via Kconfig, so this code here should work for all supported
SoCs and DRAM chips combinations.
Signed-off-by: Andre Przywara <andre.przywara@arm.com> Tested-by: Sam Edwards <CFSworks@gmail.com>
Andre Przywara [Sun, 18 Dec 2022 00:12:07 +0000 (00:12 +0000)]
Kconfig: sunxi: prepare for using drivers/ram/sunxi
At the moment all Allwinner DRAM initialisation routines are stored in
arch/arm/mach-sunxi, even though those "drivers" are just a giant
collection of writel's, without any architectural dependency.
The R528/T113-s SoC (with ARM cores) and the D1/D1s Soc (with RISC-V
cores) share the same die, so should share the same DRAM init routines as
well.
To prepare for this, add a new sunxi directory inside drivers/ram, and
add some stub entries to prepare for the addition of the share DRAM code
for those SoCs.
The RISC-V D1(s) SoCs will probably use SPL_DM, so for that SoC this
would be the right directory anyway.
Signed-off-by: Andre Przywara <andre.przywara@arm.com>
Samuel Holland [Sun, 1 May 2022 03:38:37 +0000 (22:38 -0500)]
clk: sunxi: Add support for the D1 CCU
Since the D1 CCU binding is defined, we can add support for its
gates/resets, following the pattern of the existing drivers.
Signed-off-by: Samuel Holland <samuel@sholland.org> Reviewed-by: Andre Przywara <andre.przywara@arm.com> Acked-by: Sean Anderson <seanga2@gmail.com> Signed-off-by: Andre Przywara <andre.przywara@arm.com>
Apart from using the new pinctrl MMIO register layout, the Allwinner D1
and related SoCs still need to usual set of mux values hardcoded in
U-Boot's pinctrl driver.
Add the values we need so far to this list, so that DM based drivers
will just work without further ado.
Signed-off-by: Andre Przywara <andre.przywara@arm.com>
Andre Przywara [Wed, 5 Oct 2022 16:54:19 +0000 (17:54 +0100)]
sunxi: introduce NCAT2 generation model
Allwinner seems to typically stick to a common MMIO memory map for
several SoCs, but from time to time does some breaking changes, which
also introduce new generations of some peripherals. The last time this
happened with the H6, which apart from re-organising the base addresses
also changed the clock controller significantly. We added a
CONFIG_SUN50I_GEN_H6 symbol back then to mark SoCs sharing those traits.
Now the Allwinner D1 changes the memory map again, and also extends the
pincontroller, among other peripherals.
To mark this generation of SoCs, add a CONFIG_SUNXI_GEN_NCAT2 symbol,
this name is reportedly used in the Allwinner BSP code, and prevents us
from inventing our own name.
Add this new symbol to some guards that were already checking for the H6
generation, since many features are shared between the two (like the
renovated clock controller).
This paves the way to introduce a first user of this generation.
Signed-off-by: Andre Przywara <andre.przywara@arm.com> Tested-by: Samuel Holland <samuel@sholland.org>
Andre Przywara [Tue, 6 Sep 2022 11:12:50 +0000 (12:12 +0100)]
pinctrl: sunxi: add new D1 pinctrl support
For the first time since at least the Allwinner A10 SoCs, the D1 (and
related cores) use a new pincontroller MMIO register layout, so we
cannot use our hardcoded, fixed offsets anymore.
Ideally this would all be handled by devicetree and DM drivers, but for
the DT-less SPL we still need the legacy interfaces.
Add a new Kconfig symbol to differenciate between the two generations of
pincontrollers, and just use that to just switch some basic symbols.
The rest is already abstracted enough, so works out of the box.
Signed-off-by: Andre Przywara <andre.przywara@arm.com> Reviewed-by: Sam Edwards <CFSworks@gmail.com> Tested-by: Sam Edwards <CFSworks@gmail.com> Tested-by: Samuel Holland <samuel@sholland.org>
Andre Przywara [Tue, 6 Sep 2022 10:50:54 +0000 (11:50 +0100)]
pinctrl: sunxi: move PIO_BASE into sunxi_gpio.h
On the Allwinner platform we were describing a quite comprehensive
memory map in a per-SoC header unser arch/arm.
In the old days that was used by every driver, but nowadays it should
only be needed by SPL drivers (not using the DT). Many addresses in
there were never used, and some are not needed anymore.
To avoid a dependency on CPU specific headers in an arch specific
directory, move the definition of the pinctroller MMIO base address into
the sunxi_gpio.h header, because the SPL routines for GPIO should be the
only one needing this address.
This is a first step towards getting rid of cpu_sun[x]i.h completely,
and allows to remove the inclusion of that file from the sunxi_gpio.h
header.
Signed-off-by: Andre Przywara <andre.przywara@arm.com>
Andre Przywara [Tue, 6 Sep 2022 09:36:38 +0000 (10:36 +0100)]
pinctrl: sunxi: remove GPIO_EXTRA_HEADER
U-Boot's generic GPIO_EXTRA_HEADER is a convenience symbol to allow code
to more easily include platform specific GPIO headers. This should not
be needed in a DM world anymore, since the generic GPIO framework
handles that nicely.
For Allwinner boards we still need to deal with non-DM GPIO in the SPL,
but this should become the exception, not the rule.
Make this more obvious by removing the definition of GPIO_EXTRA_HEADER,
and just force every legacy user of platform specific GPIO to include
the new sunxi_gpio.h header explicitly. Everyone doing so should feel
ashamed and should find a way to avoid it from now on.
Signed-off-by: Andre Przywara <andre.przywara@arm.com> Tested-by: Samuel Holland <samuel@sholland.org>
Andre Przywara [Mon, 5 Sep 2022 17:12:39 +0000 (18:12 +0100)]
pinctrl: sunxi: remove struct sunxi_gpio
So far every Allwinner SoC used the same basic pincontroller/GPIO
register frame, and just differed by the number of implemented banks and
pins, plus some special functionality from time to time. However the D1
and successors use a slightly different pinctrl register layout.
Use that opportunity to drop "struct sunxi_gpio", that described that
MMIO frame in a C struct. That approach is somewhat frowned upon in the
Linux world and rarely used there, though still popular with U-Boot.
Switching from a C struct to a "base address plus offset" approach allows
to switch between the two models more dynamically, without reverting to
preprocessor macros and #ifdef's.
Model the pinctrl MMIO register frame in the usual "base address +
offset" way, and replace a hard-to-parse CPP macro with a more readable
static function.
All the users get converted over. There are no functional changes at
this point, it just prepares the stages for the D1 and friends.
Signed-off-by: Andre Przywara <andre.przywara@arm.com> Reviewed-by: Samuel Holland <samuel@sholland.org> Tested-by: Samuel Holland <samuel@sholland.org>
Andre Przywara [Tue, 6 Sep 2022 09:07:18 +0000 (10:07 +0100)]
pinctrl: sunxi: add GPIO in/out wrappers
So far we were open-coding the pincontroller's GPIO output/input access
in each function using that.
Provide functions that wrap that nicely, and follow the existing pattern
(set/get_{bank,}), so users don't need to know about the internals, and
we can abstract the new D1 pinctrl more easily.
Signed-off-by: Andre Przywara <andre.przywara@arm.com> Reviewed-by: Samuel Holland <samuel@sholland.org>
Andre Przywara [Tue, 6 Sep 2022 09:36:38 +0000 (10:36 +0100)]
pinctrl: sunxi: move pinctrl code
Move the existing sunxi-specific low level pinctrl routines from
arch/arm/mach-sunxi into the existing GPIO code under drivers/gpio, so
that the common code can be shared outside of arch/arm.
This also takes the opportunity to move some definitions from our
header file into the driver C file, as they are private to the driver
and are not needed elsewhere.
Signed-off-by: Andre Przywara <andre.przywara@arm.com> Reviewed-by: Samuel Holland <samuel@sholland.org> Tested-by: Samuel Holland <samuel@sholland.org>
Andre Przywara [Wed, 8 Jun 2022 13:56:56 +0000 (14:56 +0100)]
sunxi: remove CONFIG_MACPWR
The CONFIG_MACPWR Kconfig symbol is used to point to a GPIO that enables
the power for the Ethernet "MAC" (mostly PHY, really).
In the DT this is described with the phy-supply property in the MAC DT
node, pointing to a (GPIO controlled) regulator. Since we need Ethernet
only in U-Boot proper, and use a DM driver there, we should use the DT
instead of hardcoding this.
Add code to the sun8i_emac and sunxi_emac drivers to check the DT for
that regulator and enable it, at probe time. Then drop the current code
from board.c, which was doing that job before.
This allows us to remove the MACPWR Kconfig definition and the respective
values from the defconfigs.
Signed-off-by: Andre Przywara <andre.przywara@arm.com> Reviewed-by: Sam Edwards <CFSworks@gmail.com>
Andre Przywara [Tue, 13 Jun 2023 22:35:06 +0000 (23:35 +0100)]
net: sunxi_emac: chase DT nodes to find PHY regulator
At the moment the sun4i EMAC driver relies on hardcoded CONFIG_MACPWR
Kconfig symbols to enable potential PHY regulators. As we want to get rid
of those, we need to find the regulator by chasing up the DT.
The sun4i-emac binding puts the PHY regulator into the MDIO node, which
is the parent of the PHY device. U-Boot does not have (and does not
need) an MDIO driver, so we need to chase down the regulator through the
EMAC node: we follow the "phy-handle" property to find the PHY node,
then go up to its parent, where we find the "phy-supply" link to the
regulator. Let U-Boot find the associated regulator device, and put that
into the private device struct, so we can find and enable the regulator
at probe time, later.
Signed-off-by: Andre Przywara <andre.przywara@arm.com> Reviewed-by: Sam Edwards <CFSworks@gmail.com> Reviewed-by: Samuel Holland <samuel@sholland.org>
Andre Przywara [Fri, 15 Jul 2022 15:52:14 +0000 (16:52 +0100)]
sunxi: remove CONFIG_SATAPWR
The CONFIG_SATAPWR Kconfig symbol was used to point to a GPIO that
enables the power for a SATA harddisk.
In the DT this is described with the target-supply property in the AHCI
DT node, pointing to a (GPIO controlled) regulator. Since we need SATA
only in U-Boot proper, and use a DM driver for AHCI there, we should use
the DT instead of hardcoding this.
Add code to the sunxi AHCI driver to check the DT for that regulator and
enable it, at probe time. Then drop the current code from board.c, which
was doing that job before.
This allows us to remove the SATAPWR Kconfig definition and the
respective values from the defconfigs.
We also select the generic fixed regulator driver, which handles those
GPIO controlled regulators.
Please note that the OrangePi Plus is a bit special here, it's a H3
board without native SATA, but with a USB-to-SATA bridge. The DT models
the SATA power via a VBUS supply regulator, which we don't parse yet in
the USB PHY driver. Use the hardcoded CONFIG_USB3_VBUS_PIN for that
board meanwhile.
Signed-off-by: Andre Przywara <andre.przywara@arm.com> Reviewed-by: Sam Edwards <CFSworks@gmail.com> Reviewed-by: Samuel Holland <samuel@sholland.org>
video: tegra20: dsi: use regulator_set_enable_if_allowed
With the commit 4fcba5d556b4 ("regulator: implement basic reference
counter") the return value of regulator_set_enable may be EALREADY or
EBUSY for fixed/gpio regulators and may be further expanded on all
regulators.
Change to use the more relaxed regulator_set_enable_if_allowed to
continue if regulator already was enabled or disabled.
video: simple_panel: use regulator_set_enable_if_allowed
With the commit 4fcba5d556b4 ("regulator: implement basic reference
counter") the return value of regulator_set_enable may be EALREADY or
EBUSY for fixed/gpio regulators and may be further expanded on all
regulators.
Change to use the more relaxed regulator_set_enable_if_allowed to
continue if regulator already was enabled or disabled.
video: pwm_backlight: use regulator_set_enable_if_allowed
With the commit 4fcba5d556b4 ("regulator: implement basic reference
counter") the return value of regulator_set_enable may be EALREADY or
EBUSY for fixed/gpio regulators and may be further expanded on all
regulators.
Change to use the more relaxed regulator_set_enable_if_allowed to
continue if regulator already was enabled or disabled.
Andre Przywara [Thu, 19 Oct 2023 14:45:32 +0000 (15:45 +0100)]
sunxi: dts: arm: add T113s/D1 DT files from Linux-v6.6-rc6
This copies in some devicetree files from the official Linux kernel tree,
v6.6-rc6. It covers a board with the Allwinner T113s SoC, which shares
many devices with its RISC-V sibling, the Allwinner D1(s). This is the
reason for the core .dtsi files landing in the arch/riscv directory.
We are only adjusting the include path to accommodate for the differences
in the U-Boot build system.
Signed-off-by: Andre Przywara <andre.przywara@arm.com> Reviewed-by: Jernej Skrabec <jernej.skrabec@gmail.com>
Andre Przywara [Thu, 19 Oct 2023 14:45:32 +0000 (15:45 +0100)]
sunxi: dts: arm: update devicetree files from Linux-v6.6-rc6
Sync the devicetree files from the official Linux kernel tree, v6.6-rc6.
This is covering Allwinner SoCs with 32-bit ARM cores, minus the T113s
board and related .dtsi files, which come separately.
Only small changes: Bluetooth got enabled on the C.H.I.P., and a clock
got renamed. More interesting is the addition of a board, for which
U-Boot enablement patches are pending.
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> Reviewed-by: Jernej Skrabec <jernej.skrabec@gmail.com>
Paul Barker [Thu, 19 Oct 2023 14:30:44 +0000 (15:30 +0100)]
serial: sh: Add RZ/G2L SCIF support
Extend the existing driver to support the SCIF serial ports on the
Renesas RZ/G2L (R9A07G044) SoC. This also requires us to ensure that if
there is a reset signal defined in the device tree, it is de-asserted
before we try to talk to the SCIF module.
Signed-off-by: Paul Barker <paul.barker.ct@bp.renesas.com> Reviewed-by: Biju Das <biju.das.jz@bp.renesas.com> Reviewed-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com> Reviewed-by: Marek Vasut <marek.vasut+renesas@mailbox.org> Tested-by: Marek Vasut <marek.vasut+renesas@mailbox.org> # R-Car H3 Salvator-XS
Paul Barker [Thu, 19 Oct 2023 14:30:43 +0000 (15:30 +0100)]
serial: sh: Fix error handling
The current SCIF error handling is broken for the RZ/G2L. After a break
condition has been triggered, the current code is unable to clear the
error and serial port output never resumes.
The RZ/G2L datasheet says that most error conditions are cleared by
resetting the relevant error bits in the FSR & LSR registers to zero.
To clear framing errors on SCIF ports, the invalid data also needs to be
read out of the receive FIFO.
After reviewing datasheets for RZ/G2{H,M,N,E}, R-Car Gen4, R-Car Gen3
and even SH7751 SoCs, it's clear that this is the way to clear errors
for all of these SoCs.
While we're here, annotate the handle_error() function with a couple of
comments as the reads and writes themselves don't immediately make it
clear what we're doing.
Signed-off-by: Paul Barker <paul.barker.ct@bp.renesas.com> Tested-by: Chris Paterson <chris.paterson2@renesas.com> # HiHope RZ/G2M board Tested-by: Marek Vasut <marek.vasut+renesas@mailbox.org> # R-Car H3 Salvator-XS
This patch adds ISA string to the -march to generate zbb instructions
for U-Boot binaries, along with optimized string functions introduced
from Linux kernel.
Signed-off-by: Yu Chien Peter Lin <peterlin@andestech.com> Reviewed-by: Leo Yu-Chi Liang <ycliang@andestech.com>
Randolph [Thu, 12 Oct 2023 06:35:09 +0000 (14:35 +0800)]
riscv: spl: andes: Move the DTB in front of kernel
Originally, u-boot SPL will place the DTB directly after the kernel,
but the size of the kernel does not include the BSS section, This
means that u-boot SPL places the DTB in the kernel BSS section causing
the DTB to be cleared by the kernel BSS initialisation.
Moving the DTB in front of the kernel can avoid this error.
Signed-off-by: Randolph <randolph@andestech.com> Reviewed-by: Leo Yu-Chi Liang <ycliang@andestech.com>
Randolph [Thu, 12 Oct 2023 06:35:07 +0000 (14:35 +0800)]
spl: riscv: add os type for next booting stage
If SPL_LOAD_FIT_OPENSBI_OS_BOOT is enabled, the function
spl_invoke_opensbi should change the target OS type to IH_OS_LINUX.
OpenSBI will load the Linux image as the next boot stage.
The os_takes_devicetree function returns a value of true or false
depending on whether or not SPL_LOAD_FIT_OPENSBI_OS_BOOT is enabled.
Signed-off-by: Randolph <randolph@andestech.com> Reviewed-by: Simon Glass <sjg@chromium.org>
Randolph [Thu, 12 Oct 2023 06:35:05 +0000 (14:35 +0800)]
riscv: dts: binman: add condition for opensbi os boot
Add condition for OpenSBI OS boot mode, by default it is not enabled.
By default, binman creates the output file u-boot.itb.
If SPL_OPENSBI_OS_BOOT is enabled, linux.itb will be created
after compilation instead of the default u-boot.itb.
Signed-off-by: Randolph <randolph@andestech.com> Reviewed-by: Simon Glass <sjg@chromium.org>
Randolph [Thu, 12 Oct 2023 06:35:04 +0000 (14:35 +0800)]
riscv: kconfig: introduce SPL_LOAD_FIT_OPENSBI_OS_BOOT symbol
Introduce common Kconfig symbol for riscv architecture.
This symbol SPL_LOAD_FIT_OPENSBI_OS_BOOT is like falcon mode on ARM,
the Falcon boot is a shortcut boot method for SD/eMMC targets. It
skips the loading the RAM version U-Boot. Instead, it will loads
the FIT image and boots directly to Linux.
When SPL_OPENSBI_OS_BOOT is enabled, linux.itb is created after
compilation instead of the default u-boot.itb. It initialises memory
with the U-Boot SPL at the first stage, just as a normal boot process
does at the beginning. Instead of jumping to the U-Boot proper from
OpenSBI before booting the Linux kernel, the RISC-V falcon mode
process jumps directly to the Linux kernel to gain shorter booting time.
Signed-off-by: Randolph <randolph@andestech.com> Reviewed-by: Simon Glass <sjg@chromium.org>
Mayuresh Chitale [Wed, 11 Oct 2023 15:30:20 +0000 (21:00 +0530)]
riscv: binman: Fix compilation error
Some platforms may not have any DDR memory below 4G and for such platforms
the TEXT_BASE and LOAD addresses etc are all 64 bit addresses due to
which the u-boot build fails with below error:
u-boot/arch/riscv/dts/binman.dtsi:30.14-25
Value out of range for 32-bit array element
u-boot/arch/riscv/dts/binman.dtsi:43.14-25
Value out of range for 32-bit array element
u-boot/arch/riscv/dts/binman.dtsi:44.15-26
Value out of range for 32-bit array element
FATAL ERROR: Syntax error parsing input tree
Fix by setting the address-cells property to 2 and converting load
addresses to 64 bit values.
Signed-off-by: Mayuresh Chitale <mchitale@ventanamicro.com> Reviewed-by: Simon Glass <sjg@chromium.org>