Sughosh Ganu [Fri, 22 Mar 2024 10:57:33 +0000 (16:27 +0530)]
configs: fwu: re-enable FWU configs
Now that support for FWU metadata version 2 has been added, the
feature can be enabled on platforms which had enabled it. A new config
symbol for selecting the metadata version for the platform is also
being added.
Signed-off-by: Sughosh Ganu <sughosh.ganu@linaro.org> Tested-by: Michal Simek <michal.simek@amd.com>
Sughosh Ganu [Fri, 22 Mar 2024 10:57:29 +0000 (16:27 +0530)]
tools: mkfwumdata: add logic to append vendor data to the FWU metadata
The version 2 of the FWU metadata allows for appending opaque vendor
specific data to the metadata structure. Add support for appending
this data to the metadata. The vendor specific data needs to be
provided through a file, passed through a command-line parameter. Make
corresponding changes to the tool's manpage.
Signed-off-by: Sughosh Ganu <sughosh.ganu@linaro.org> Tested-by: Michal Simek <michal.simek@amd.com>
Sughosh Ganu [Fri, 22 Mar 2024 10:57:28 +0000 (16:27 +0530)]
tools: mkfwumdata: add support for metadata version 2
Add support for generating the FWU metadata version 2. The tool now
requires the version to be provided as a command-line option. Make
corresponding changes to the tool's manpage.
Signed-off-by: Sughosh Ganu <sughosh.ganu@linaro.org> Tested-by: Michal Simek <michal.simek@amd.com>
Sughosh Ganu [Fri, 22 Mar 2024 10:57:27 +0000 (16:27 +0530)]
cmd: fwu: make changes for supporting FWU metadata version 2
Add support for displaying data specific to FWU metadata version
2. Because the size of the v2 metadata structure is read from the
structure itself, allocate memory for the metadata structure by first
getting the size of the structure.
Signed-off-by: Sughosh Ganu <sughosh.ganu@linaro.org> Tested-by: Michal Simek <michal.simek@amd.com>
Sughosh Ganu [Fri, 22 Mar 2024 10:57:26 +0000 (16:27 +0530)]
fwu: mtd: obtain image information from version agnostic structure
Make changes to the functions used for generating the DFU's alt
variable so that the FWU image information is obtained from the common
version agnostic structure instead of reading the metadata.
While here, also update the name of the field used for storing the
image GUID in the FWU metadata.
Signed-off-by: Sughosh Ganu <sughosh.ganu@linaro.org> Tested-by: Michal Simek <michal.simek@amd.com>
Sughosh Ganu [Fri, 22 Mar 2024 10:57:25 +0000 (16:27 +0530)]
fwu: mtd: get MTD partition specific info from driver
Information about FWU images on MTD partitions is now stored with the
corresponding driver instead of a global variable. Get this
information from the driver.
Signed-off-by: Sughosh Ganu <sughosh.ganu@linaro.org> Tested-by: Michal Simek <michal.simek@amd.com>
Sughosh Ganu [Fri, 22 Mar 2024 10:57:22 +0000 (16:27 +0530)]
capsule: fwu: transition the platform state on a successful update
Transition the platform to either Trial State or Regular State on a
successful update. Do this by calling the fwu_state_machine_updates()
API function.
For version 1 of the FWU metadata, the transition to Trial State is
done by starting the Trial State counter, while for version 2, in
addition to the counter, the bank_state field of the FWU metadata is
also updated to Valid.
For transitioning the platform to Regular State, no action is needed
with version 1 of the FWU metadata structure, while for version 2, the
bank_state field is set to Accepted.
Signed-off-by: Sughosh Ganu <sughosh.ganu@linaro.org> Tested-by: Michal Simek <michal.simek@amd.com>
Sughosh Ganu [Fri, 22 Mar 2024 10:57:21 +0000 (16:27 +0530)]
fwu: make changes to access version agnostic structure fields
With addition of support for version 2 of the FWU metadata structure,
the metadata information is collected into a version agnostic
structure. Make changes to the FWU functions so that the information
that was earlier obtained by reading the metadata structure is now
obtained through this version agnostic structure.
Signed-off-by: Sughosh Ganu <sughosh.ganu@linaro.org> Tested-by: Michal Simek <michal.simek@amd.com>
Sughosh Ganu [Fri, 22 Mar 2024 10:57:20 +0000 (16:27 +0530)]
fwu: metadata: add functions for handling version specific metadata fields
Support is being added in U-Boot for version 2 of the FWU
metadata. Support for this version is to co-exist with version 1
support. To achieve this, a common, version agnostic structure has
been added to keep information provided by the FWU metadata
structure.
Add API's to handle the version specific FWU metadata fields. The
version agnostic structure gets initialized at boot by reading the FWU
metadata. Updates to the FWU metadata result in the API's getting
called to populate the version specific fields of the strucure, before
the metadata gets written to the storage media.
Signed-off-by: Sughosh Ganu <sughosh.ganu@linaro.org> Tested-by: Michal Simek <michal.simek@amd.com>
Sughosh Ganu [Fri, 22 Mar 2024 10:57:19 +0000 (16:27 +0530)]
fwu: metadata: add a version agnostic structure
The FWU specification now has two versions of the FWU metadata
structure, and both are to be supported. Introduce a version agnostic
structure for storing information about the FWU updatable images. This
allows for a split of common version agnostic FWU code and version
specific code.
The version specific code is then responsible for arranging the data
as per the corresponding metadata structure before it gets written to
the metadata partitions.
Signed-off-by: Sughosh Ganu <sughosh.ganu@linaro.org> Tested-by: Michal Simek <michal.simek@amd.com>
Sughosh Ganu [Fri, 22 Mar 2024 10:57:18 +0000 (16:27 +0530)]
fwu: metadata: add support for version 2 of the structure
Add support for version 2 of the FWU metadata structure. The top level
structure is kept separate through a config symbol. Most of the
fields, primarily used for providing information on updatable images
are common across the two versions.
Also change a few existing structure members used for image
identification to reflect the fact that these are GUIDs, and not
UUIDs.
Signed-off-by: Sughosh Ganu <sughosh.ganu@linaro.org> Tested-by: Michal Simek <michal.simek@amd.com>
Sughosh Ganu [Fri, 22 Mar 2024 10:57:17 +0000 (16:27 +0530)]
drivers: fwu: mtd: allocate buffer for image info dynamically
The FWU metadata access driver for MTD partitioned devices currently
uses a statically allocated array for storing the updatable image
information. This array depends on the number of banks and images per
bank. With migration of the FWU metadata to version 2, these
parameters are now obtained at runtime from the metadata.
Make changes to the FWU metadata access driver for MTD devices to
allocate memory for the image information dynamically in the driver's
probe function, after having obtained the number of banks and images
per bank by reading the metadata. Move the image information as part
of the driver's private structure, instead of using a global variable.
Signed-off-by: Sughosh Ganu <sughosh.ganu@linaro.org> Tested-by: Michal Simek <michal.simek@amd.com>
Sughosh Ganu [Fri, 22 Mar 2024 10:57:16 +0000 (16:27 +0530)]
drivers: fwu: add the size parameter to the metadata access API's
In version 2 of the metadata structure, the size of the structure
cannot be determined statically at build time. The structure is now
broken into the top level structure which contains a field indicating
the total size of the structure.
Add a size parameter to the metadata access API functions to indicate
the number of bytes to be accessed. This is then used to either read
the entire structure, or only the top level structure.
Signed-off-by: Sughosh Ganu <sughosh.ganu@linaro.org> Tested-by: Michal Simek <michal.simek@amd.com>
Sughosh Ganu [Fri, 22 Mar 2024 10:57:15 +0000 (16:27 +0530)]
tools: mkfwumdata: fix the size parameter to the fwrite call
The fwrite call returns the number of bytes transferred as part of the
write only when the size parameter is 1. Pass the size parameter to
the library call as 1 so that the correct number of bytes transferred
are returned.
Fixes: fdd56bfd3ad ("tools: Add mkfwumdata tool for FWU metadata image") Signed-off-by: Sughosh Ganu <sughosh.ganu@linaro.org> Tested-by: Michal Simek <michal.simek@amd.com>
Sughosh Ganu [Fri, 22 Mar 2024 10:57:14 +0000 (16:27 +0530)]
configs: fwu: remove FWU configs for metadata V2 support
Support is to be added in the following commits for the FWU metadata
version 2. Disable the FWU feature on platforms that enable it for the
V2 addition work.
Marek Vasut [Mon, 18 Mar 2024 15:03:14 +0000 (16:03 +0100)]
Makefile: Add missing OF_UPSTREAM Makefile for 32bit ARM
Copy dts/upstream/src/arm64/Makefile into dts/upstream/src/arm/Makefile
and create a commit. This makes 32bit ARM buildable with OF_UPSTREAM .
Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org> Reviewed-by: Sumit Garg <sumit.garg@linaro.org> Tested-by: Adam Ford <aford173@gmail.com> #am3517-evm Tested-by: Tony Dinh <mibodhi@gmail.com>
Tom Rini [Wed, 20 Mar 2024 12:39:05 +0000 (08:39 -0400)]
Merge branch '2024-03-19-assorted-updates' into next
- TI J7200 updates, GIC-600 support, 2 more tests, fix parsing
ccsidr_el1 register in some cases, prepare for allowing remoteproc to
use fs_loader and make the binary_size_check rule not require 'bc'.
The error message "bc: command not found" is easily missed since the
build continues.
bc is not a part of coreutils or base-devel. POSIX sh can also do the
calculation.
Signed-off-by: Leon M. Busch-George <leon@georgemail.eu> Reviewed-by: Dragan Simic <dsimic@manjaro.org>
Lukasz Wiecaszek [Sun, 10 Mar 2024 10:29:58 +0000 (11:29 +0100)]
arm: Check FEAT_CCIDX when parsing ccsidr_el1 register
Current Cache Size ID Register (ccsidr_el1) has two "flavors"
depending on whether FEAT_CCIDX is implemented or not.
When FEAT_CCIDX is implemented Associativity parameter
is coded on bits [23:3] and NumSets parameter on bits [55:32].
When FEAT_CCIDX is not implemented then Associativity parameter
is coded on bits [12:3] and NumSets parameter on bits [27:13].
Current U-Boot code does not check whether FEAT_CCIDX is implemented
and always parses ccsidr_el1 as if FEAT_CCIDX was not implemented.
This is of course wrong on systems where FEAT_CCIDX is implemented.
This patch fixes that problems and tests whether FEAT_CCIDX
is implemented or not and accordingly parses the ccsidr_el1 register.
Arm's GIC-600 features a Power Register (GICR_PWRR),
which needs to be programmed to enable redistributor
operation. Power on the redistributor and wait until
the power on state is reflected by checking the bit
GICR_PWRR.RDPD == 0. While running U-Boot in EL3
without enabling this register, GICR_WAKER.ChildrenAsleep
bit is not getting cleared and loops infinitely.
This register(GICR_PWRR) must be programmed to mark the frame
as powered on, before accessing other registers in the frame.
Rest of initialization sequence remains the same.
ARM GIC-600 IP complies with ARM GICv3 architecture.
Enable this config if GIC-600 IP present.
load_firmware() API calls fs-loader APIs and checks for CONFIG_FS_LOADER
before calling those APIs. The if check only checks for CONFIG_FS_LOADER
but not for CONFIG_SPL_FS_LOADER.
When CONFIG_FS_LOADER is enabled, load_firmware() API calls fs-loader APIs
but this is done at SPL stage and at this time FS_LOADER is not built yet
as a result we see below build error.
AR spl/boot/built-in.o
LD spl/u-boot-spl
arm-none-linux-gnueabihf-ld.bfd: arch/arm/mach-k3/common.o: in function
`load_firmware':
/home/danish/workspace/u-boot/arch/arm/mach-k3/common.c:184: undefined
reference to `get_fs_loader'
arm-none-linux-gnueabihf-ld.bfd:
/home/danish/workspace/u-boot/arch/arm/mach-k3/common.c:185: undefined
reference to `request_firmware_into_buf'
make[2]: *** [/home/danish/workspace/u-boot/scripts/Makefile.spl:527:
spl/u-boot-spl] Error 1
make[1]: *** [/home/danish/workspace/u-boot/Makefile:2055:
spl/u-boot-spl] Error 2
make[1]: Leaving directory '/home/danish/uboot_images/am64x/r5'
make: *** [Makefile:177: sub-make] Error 2
Fix this by modifying the if check to CONFIG_IS_ENABLED(FS_LOADER) instead
of IS_ENABLED(CONFIG_FS_LOADER) as the former will check for the
appropriate config option (CONFIG_SPL_FS_LOADER / CONFIG_FS_LOADER) based
on the build stage.
Signed-off-by: MD Danish Anwar <danishanwar@ti.com> Acked-by: Ravi Gunasekaran <r-gunasekaran@ti.com>
Tom Rini [Tue, 19 Mar 2024 13:10:30 +0000 (09:10 -0400)]
Merge tag 'u-boot-socfpga-next-20240319' of https://source.denx.de/u-boot/custodians/u-boot-socfpga into next
- A new driver in the misc to register setting from device tree. This
also provides user a clean interface and all register settings are
centralized in one place, device tree.
- Enable Agilex5 platform for Intel product. Changes, modification and
new files are created for board, dts, configs and makefile to create
the base for Agilex5.
Build-tested on SoC64 boards, boot tested on some of them.
This patch is to enable Agilex5 platform for Intel
product. Changes, modification and new files are
created for board, dts, configs and makefile to
create the base for Agilex5.
Signed-off-by: Jit Loon Lim <jit.loon.lim@intel.com> Reviewed-by: Tien Fong Chee <tien.fong.chee@intel.com>
- Select polling-rate from cpu-thermal devicetree node on imx_tmu.
- Re-organize the U-Boot environment and add RAUC logic for
phycore_imx8mp.
- Enable watchdog on colibri-imx7.
- Move imx8mm-venice to use OF_UPSTREAM.
Tim Harvey [Tue, 12 Mar 2024 19:05:43 +0000 (12:05 -0700)]
imx8m*_venice: move venice to OF_UPSTREAM
Move to imx8m{m,n,p}-venice to OF_UPSTREAM:
- replace the non-upstream generic imx8m{m,n,p}-venice dt with one of the
dt's from the OF_LIST
- handle the fact that dtbs now have a 'freescale/' prefix
- imply OF_UPSTREAM
- remove rudundant files from arch/arm/dts leaving only the
*-u-boot.dtsi files
Benjamin Hahn [Mon, 4 Mar 2024 11:48:54 +0000 (12:48 +0100)]
drivers: imx_tmu: Select polling-rate from cpu-thermal devicetree node
The polling rate is already specified in some devicetrees, like
imx8mp.dtsi for example, but was not selected so far. For the
trippoints, the cpu-thermal node is used. Also get the polling rate from
this node. Use the default of 5000ms if the polling rate should not be
specified in the devicetree.
NOTE: The polling rate from the devicetree will be used after this
patch. In imx8*.dtsi devicetrees the polling delay is set to 2000ms for
example.
Signed-off-by: Benjamin Hahn <B.Hahn@phytec.de> Reviewed-by: Fabio Estevam <festevam@gmail.com>
Tom Rini [Fri, 15 Mar 2024 13:15:31 +0000 (09:15 -0400)]
Merge tag 'u-boot-rockchip-20240315' of https://source.denx.de/u-boot/custodians/u-boot-rockchip into next
Please pull the updates for rockchip platform:
- Add board: rk3588 Generic, Cool Pi CM5, Theobroma-Systems RK3588 Jaguar SBC,
Toybrick TB-RK3588X;
rk3588s Cool Pi 4B;
rk3566 Pine64 PineTab2;
- Add saradc v2 support;
- Add PMIC RK806 support;
- rk3588 disable force_jtag by default;
- Migrate to use IO-domain driver for all boards;
- Use common bss and stack addresses for rk33xx and rk35xx boards;
- Other updates for driver, config and dts;
Quentin Schulz [Thu, 14 Mar 2024 09:36:29 +0000 (10:36 +0100)]
rockchip: boot_mode: fix rockchip_dnl_key_pressed requiring ADC support
ADC support is implied by the Rockchip arch Kconfig but that means it
should be possible to disable ADC support and still be able to build.
However the weak implementation of rockchip_dnl_key_pressed() currently
blindly use functions from the ADC subsystem which do not exist when ADC
is not enabled, failing the build.
Therefore, let's encapsulate this logic with a check on the ADC symbol
being selected.
Quentin Schulz [Thu, 14 Mar 2024 09:36:27 +0000 (10:36 +0100)]
adc: add missing depends on ADC for controller drivers
The ADC controller drivers are obviously all depending on ADC symbol
being selected.
While they don't seem to fail to build without, they won't be useful
without that symbol selected, so let's make sure the options aren't
shown in menuconfig when ADC isn't selected.
Quentin Schulz [Thu, 14 Mar 2024 09:36:26 +0000 (10:36 +0100)]
rockchip: jaguar-rk3588: enable SARADC and derivatives
The SARADC is used on Jaguar for multiple things:
- channel 0 is used (at runtime) as a BIOS button,
- channel 2 is exposed on the Mezzanine connector for customer specific
logic,
- channel 5 and 6 are used for identification,
Since the SARADC requires a vref-supply provided by the RK806 PMIC, its
support and the support for its regulators are also enabled.
The button, adc, pmic and regulator commands are also enabled for CLI
use in U-Boot for debugging and scripting purposes.
The RK806 PMIC on Jaguar being routed on the SPI bus, let's enable
Rockchip SPI controller driver.
Finally, the SARADC channel 1 on Jaguar is hardwired so will never
change in the lifetime of a unit, for that reason, disable the Rockchip
Download Mode check by setting ROCKCHIP_BOOT_MODE_REG symbol to 0.
Quentin Schulz [Thu, 14 Mar 2024 09:36:25 +0000 (10:36 +0100)]
power: pmic: rk8xx: fix duplicate prompt
SPL_PMIC_RK8XX and PMIC_RK8XX both share the same prompt making it
difficult to know at first glance in menuconfig what's for what, let's
fix this by adding "in SPL" at the end of the prompt for the SPL symbol.
Quentin Schulz [Thu, 14 Mar 2024 09:36:24 +0000 (10:36 +0100)]
rockchip: adc: rockchip-saradc: add support for RK3588
This adds support for the SARADCv2 found on RK3588.
There is no stop callback as it is currently configured in single
conversion mode, where the ADC is powered down after a single conversion
has been made.
Due to what seems to be a silicon bug, a controller reset needs to be
issued before starting a channel conversion otherwise Rockchip says that
channel 1 will error whatever that means. This is aligned with upstream
and downstream Linux kernel as well as downstream U-Boot.
Quentin Schulz [Thu, 14 Mar 2024 09:36:23 +0000 (10:36 +0100)]
rockchip: adc: rockchip-saradc: factor out stop callback
SARADC v2 doesn't have a stop mechanism once in single mode. In series
conversion, the logic is different anyway. Therefore, let's abstract
this function so that it can be provided from the udevice.data pointer.
Quentin Schulz [Thu, 14 Mar 2024 09:36:22 +0000 (10:36 +0100)]
rockchip: adc: rockchip-saradc: factor out start_channel callback
SARADC v1 and v2 have a different way of starting a channel, therefore
let's abstract this function so that it can be provided from the
udevice.data pointer.
Quentin Schulz [Thu, 14 Mar 2024 09:36:21 +0000 (10:36 +0100)]
rockchip: adc: rockchip-saradc: factor out channel_data callback
SARADC v1 and v2 have a different way of reading data, therefore let's
abstract this function so that it can be provided from the udevice.data
pointer.
Quentin Schulz [Thu, 14 Mar 2024 09:36:20 +0000 (10:36 +0100)]
rockchip: adc: rockchip-saradc: use union for preparing for v2
The registers are entirely different between SARADC v1 and SARADC v2, so
let's prepare to add another struct for accessing v2 registers by adding
a union.
Quentin Schulz [Thu, 14 Mar 2024 09:36:18 +0000 (10:36 +0100)]
power: rk8xx: add support for RK806
This adds support for RK806, only the SPI variant has been tested.
The communication "protocol" over SPI is the following:
- write three bytes:
- 1 byte: [0:3] length of the payload, [6] Enable CRC, [7] Write
- 1 byte: LSB register address
- 1 byte: MSB register address
- write/read length of payload
The CRC is always disabled for now.
The RK806 technically supports I2C as well, and this should be able to
support it without any change, but it wasn't tested.
The DT node name prefix for the buck converters has changed in the
Device Tree and is now dcdc-reg. The logic for buck converters is
however manageable within the current logic inside the rk8xx regulator
driver. The same cannot be said for the NLDO and PLDO.
Because pmic_bind_children() parses the DT nodes and extracts the LDO
index from the DT node name, NLDO and PLDO will have overlapping
indices. Therefore, we need a separate logic from the already-existing
ldo callbacks. Let's reuse as much as possible though.
Quentin Schulz [Thu, 14 Mar 2024 09:36:17 +0000 (10:36 +0100)]
regulator: rk8xx: add indirection level for some ldo callbacks
By passing a rk8xx_reg_info directly to the internal get_value, it'd be
possible to call this same function with a logic for getting the
rk8xx_reg_info different from the current get_ldo_reg, e.g. for NLDO and
PLDO support for RK806.
Quentin Schulz [Thu, 14 Mar 2024 09:36:15 +0000 (10:36 +0100)]
regulator: rk8xx: remove unused functions
Those two functions had their last user removed in commit f9c68a566c4d
("rockchip: phycore_rk3288: remove phycore_init() function") part of
v2023.01 release, so let's do some cleanup here.
Quentin Schulz [Thu, 14 Mar 2024 09:36:14 +0000 (10:36 +0100)]
rockchip: spi: rk_spi: do not write bytes when in read-only mode
The read-only mode is currently supported but only for 16b-aligned
buffers. For unaligned buffers, the last byte will be read in RW mode
right now, which isn't what is desired. Instead, let's put the
controller back into RO mode for that last byte and skip any write in
the xfer loop.
This is required for 3-wire SPI mode where PICO/POCI lanes are shorted
on HW level. This incidentally the recommended design for RK806 PMIC for
RK3588 products.
Ben Wolsieffer [Fri, 8 Mar 2024 03:00:51 +0000 (22:00 -0500)]
rockchip: load env from boot MMC device
Currently, if the environment is stored on an MMC device, the device
number is hardcoded by CONFIG_SYS_MMC_ENV_DEV. This is problematic
because many boards can choose between booting from an SD card or a
removable eMMC. For example, the Rock64 defconfig sets
CONFIG_SYS_MMC_ENV_DEV=1, which corresponds to the SD card. If an eMMC
is used as the boot device and no SD card is installed, it is impossible
to save the environment.
To avoid this problem, we can choose the environment MMC device based on
the boot device. The theobroma-systems boards already contain code to do
this, so this commit simply moves it to the common Rockchip board file,
with some refactoring. I also removed another implementation of
mmc_get_env_dev() from tinker_rk3288 that performed MMC boot device
detection by reading a bootrom register.
This has been tested on a Rock64v2.
Signed-off-by: Ben Wolsieffer <benwolsieffer@gmail.com> Reviewed-by: Quentin Schulz <quentin.schulz@theobroma-systems.com>
Chris Morgan [Mon, 5 Feb 2024 18:58:55 +0000 (12:58 -0600)]
board: rockchip: Add early ADC button detect for RGxx3
Add ADC button detect for early SPL stage for RGxx3 device. This is
important because on at least the RG353P and RG353V a clk pin is not
exposed that would allow us to take the eMMC out of the boot path.
Signed-off-by: Chris Morgan <macromorgan@hotmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
Chris Morgan [Mon, 5 Feb 2024 18:58:54 +0000 (12:58 -0600)]
configs: Remove unnecessary options from RGxx3 config
Based on feedback from the mailing list while adding support for a new
device (the Powkiddy X55), correct the config options for the RGxx3
as well to remove unnecessary drivers and increase the SPL stack size.
Signed-off-by: Chris Morgan <macromorgan@hotmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
Chris Morgan [Mon, 5 Feb 2024 18:58:53 +0000 (12:58 -0600)]
board: rockchip: Add support for Powkiddy RGB10MAX3
Add support to the RGxx3 device for the Powkiddy RGB10MAX3. This device
is extremely similar to all the other devices and can use the same
bootloader with the same detection logic.
Signed-off-by: Chris Morgan <macromorgan@hotmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
Jonas Karlman [Tue, 12 Mar 2024 23:36:15 +0000 (23:36 +0000)]
rockchip: io-domain: Add support for RK3399
Port the RK3399 part of the Rockchip IO-domain driver from linux.
This differs from linux version in that pmu io iodomain bit is enabled
in the write ops instead of in an init ops as in linux, this way we can
avoid keeping a full state of all supply that have been configured.
Signed-off-by: Jonas Karlman <jonas@kwiboo.se> Reviewed-by: Quentin Schulz <quentin.schulz@theobroma-systems.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
Jonas Karlman [Tue, 12 Mar 2024 23:36:14 +0000 (23:36 +0000)]
board: rockchip: Add a common ROCK Pi 4 target
Move ROCK Pi 4 specific board code from the shared evb_rk3399 target
into its own board target and update related defconfigs to use the new
TARGET_ROCKPI4_RK3399 option.
Signed-off-by: Jonas Karlman <jonas@kwiboo.se> Reviewed-by: Christopher Obbard <chris.obbard@collabora.com> Reviewed-by: Peter Robinson <pbrobinson@gmail.com>
These functions is excluded from SPL build and BOARD_EARLY_INIT_F is not
enabled for any of the affected boards, so this legacy code is not used.
Rockchip common board code already enable all regulators flagged as
always-on or boot-on in device tree, and fixed/gpio regulators now have
basic reference counting support so the original intent of this code is
no longer valid.
Remove the unneeded and unused code that used to enable usb regulators.
Signed-off-by: Jonas Karlman <jonas@kwiboo.se> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
Jonas Karlman [Sun, 10 Mar 2024 18:51:00 +0000 (18:51 +0000)]
rockchip: Migrate to use DM_USB_GADGET on RK3328
USB gadget is not working fully as expected on RK3328, it uses a
board_usb_init() function to initialize the DWC2 OTG port.
The board_usb_init() function does not intgrate with the generic phy
framework and as a result the USB phy is not properly configured before
or after USB gadget use.
Having both USB_DWC2 and DWC2_OTG enabled for the same board is also
causing some issues.
Trying to use rockusb or ums command after usb stop result in a freeze
due to usb stop is putting the phy in a suspended state.
=> usb start
=> usb stop
=> ums 0 mmc 0
--> freeze due to usb phy is suspended <--
Fix this by only using one of USB_DWC2 (host) or DWC2_OTG (peripheral)
depending on the most likely usage of the otg port and by migrating to
use DM_USB_GADGET instead of a board_usb_init() function.
The nanopi-r2 and orangepi-r1-plus variants share OTG and power using a
Type-C connector, mark these boards dr_mode as peripheral, the most
likely usage is for recovery and image download.
The rock64 and roc-cc currently use dr_mode as host, remove the DWC2_OTG
driver from these boards to ensure that the USB_DWC2 driver is used.
The rock-pi-e board does not enable the usb20_otg node so both USB_DWC2
and DWC2_OTG is removed from this board.
Enable RockUSB and UMS on all boards with a otg port in peripheral mode.
Also with the migration to DM_USB_GADGET completed the U-Boot specific
change to reorder usb nodes in the soc device tree can be reverted.
Signed-off-by: Jonas Karlman <jonas@kwiboo.se> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
Jonas Karlman [Sun, 10 Mar 2024 18:50:58 +0000 (18:50 +0000)]
rockchip: board: Prepare for use of DM_USB_GADGET with DWC2_OTG
The board_usb_init() and board_usb_cleanup() functions is always
included when USB_GADGET and USB_GADGET_DWC2_OTG is enabled.
Prepare for a change to use DM_USB_GADGET with DWC2_OTG by adding an
extra ifdef condition. The extra separate ifdef for USB_GADGET prepare
for next patch that adds a g_dnl_bind_fixup() function.
Signed-off-by: Jonas Karlman <jonas@kwiboo.se> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
Jonas Karlman [Sun, 10 Mar 2024 18:50:57 +0000 (18:50 +0000)]
rockchip: Update the default USB Product ID value
RK3036 is using the USB product id normally used by RK3066B, and RK3328
is using the product id normally used by RK3368.
Fix this and update the default USB_GADGET_PRODUCT_NUM Kconfig option
for remaining supported Rockchip SoCs to match the product id used in
Maskrom mode.
Also remove a reference to an undefined ROCKCHIP_RK3229 Kconfig symbol.
SPL can safely load U-Boot proper + FDT to [10M, 11.5M) with this layout.
However, on ROCK 5A the SPL stacks is overlapping:
[ -X, 16M) - SPL pre-reloc stack (SPL_STACK)
[15.5M, 16M) - pre-reloc malloc heap (SPL_SYS_MALLOC_F_LEN)
[ -X, 16M) - SPL reloc stack (SPL_STACK_R_ADDR)
[ 15M, 16M) - reloc malloc heap (SPL_STACK_R_MALLOC_SIMPLE_LEN)
Because bind and probe udevice instanses is allocated on the pre-reloc
malloc heap, there is going to be an overlap when reloc malloc heap
reaches close to 512 KiB of usage.
Migrate to use common bss, stack and malloc heap size and addresses to
mitigate these limitations and allow for a larger U-Boot proper size.
Signed-off-by: Jonas Karlman <jonas@kwiboo.se> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
(Update for new boards defconfig) Signed-off-by: Kever Yang <kever.yang@rock-chips.com>
SPL can safely load U-Boot proper + FDT to [10M, 12M-128K) with this
layout.
Migrate to use common bss, stack and malloc heap size and addresses to
remove this size limitation.
Signed-off-by: Jonas Karlman <jonas@kwiboo.se> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
(Update for pinetab2-rk3566_defconfig) Signed-off-by: Kever Yang <kever.yang@rock-chips.com>
Jonas Karlman [Sat, 2 Mar 2024 19:16:14 +0000 (19:16 +0000)]
rockchip: Use common bss and stack addresses on RK3399
With the stack and text base used by U-Boot SPL and proper on RK3399
there is a high likelihood of overlapping when U-Boot proper + FDT nears
or exceeded 1 MiB in size.
SPL can safely load U-Boot proper + FDT to [2M, 4M-16K) with this layout.
However, the stack at [-X, 3M) used during U-Boot proper pre-reloc is
restricting the safe size of U-Boot proper + FDT to be less than 1 MiB.
Migrate to use common bss, stack and malloc heap size and addresses to
fix this restriction and allow for a larger U-Boot proper image size.
Signed-off-by: Jonas Karlman <jonas@kwiboo.se> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
Jonas Karlman [Sat, 2 Mar 2024 19:16:13 +0000 (19:16 +0000)]
rockchip: Use common bss and stack addresses on RK3328
With the stack and text base used by U-Boot SPL and proper on RK3328
there is a high likelihood of overlapping when U-Boot proper + FDT nears
or exceeded 1 MiB in size.
SPL can safely load U-Boot proper + FDT to [2M, 4M-8K) with this layout.
However, the stack at [-X, 3M) used during U-Boot proper pre-reloc is
restricting the safe size of U-Boot proper + FDT to be less than 1 MiB.
Migrate to use common bss, stack and malloc heap size and addresses to
fix this restriction and allow for a larger U-Boot proper image size.
Signed-off-by: Jonas Karlman <jonas@kwiboo.se> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
Jonas Karlman [Sat, 2 Mar 2024 19:16:11 +0000 (19:16 +0000)]
rockchip: Add common default bss and stack addresses
On Rockchip the typical aarch64 boot steps are as follows:
- BROM load TPL to SRAM
- TPL init full DRAM
- use stack in SRAM at TPL_STACK addr
- use malloc heap on stack, size is TPL_SYS_MALLOC_F_LEN
- TPL jump back to BROM
- BROM load SPL to beginning of DRAM
- SPL init storage devices
- use bss in DRAM at SPL_BSS_START_ADDR, size is SPL_BSS_MAX_SIZE
- use stack in DRAM at SPL_STACK addr (or CUSTOM_SYS_INIT_SP_ADDR)
- use malloc heap on stack, size is SPL_SYS_MALLOC_F_LEN
- SPL load FIT images from storage to DRAM
- use stack in DRAM at SPL_STACK_R_ADDR
- use new malloc heap on stack, size is SPL_STACK_R_MALLOC_SIMPLE_LEN
- SPL jump to TF-A at 0x40000
- (optional) TF-A load OPTEE
- TF-A jump to U-Boot proper at TEXT_BASE
- U-Boot proper init pre-reloc devices
- use stack in DRAM at CUSTOM_SYS_INIT_SP_ADDR
- use malloc heap on stack, size is SYS_MALLOC_F_LEN
- U-Boot proper relocate to end of usable DRAM
- U-Boot proper init devices and complete boot
SPL have access to full DRAM, however, current configuration for text
base, stack addr and malloc heap size used at the different boot steps
are at risk of overlapping, e.g. when U-Boot proper + FDT grows close
to 1 MiB on RK3328/RK3399 or when pre-reloc and reloc stack and malloc
heap overlap on ROCK 5A.
Fix this by defining safe defaults for bss, stack and malloc size and
addresses. A range at around [60 MiB, 64 MiB) was chosen to be used for
bss and stack until U-Boot proper have been relocated to end of usable
DRAM. The range was primarily chosen to be able to accommodate SoCs with
a small amount of embedded DRAM, e.g. RK3308G has 64 MiB DRAM.
Overiew of the new common memory layout:
[ 0, 2M) - SPL / TF-A / reserved
[ 2M, +X) - U-Boot proper pre-reloc
[ -X, 64M) - bss, stack and malloc heap
During SPL pre-reloc phase:
[ 0, 256K) - SPL binary is loaded by BROM to beginning of DRAM
[ -X, 63M) - SPL pre-reloc stack
[ -32K, 63M) - SPL pre-reloc malloc heap
[63.5M, +32K) - SPL bss
After SPL reloc phase:
[ 0, 256K) - SPL binary
[ 256K, +X) - TF-A image is loaded by SPL
[ 2M, +X) - U-Boot proper + FDT image is loaded by SPL
[ -X, 62M) - SPL reloc stack
[ 60M, 62M) - SPL reloc malloc heap
[ -32K, 63M) - SPL init malloc heap, memory allocated during SPL
pre-reloc phase is still in use at reloc phase
[63.5M, +32K) - SPL bss
Jonas Karlman [Sun, 4 Feb 2024 17:30:35 +0000 (17:30 +0000)]
board: rockchip: Add Pine64 PineTab2
The Pine64 PineTab2 is a tablet computer based on the Rockchip RK3566
SoC. The table features 4/8 GB LPDDR4 RAM and 64/128 GB eMMC storage.
Features tested on a Pine64 PineTab2 8GB v2.0:
- SD-card boot
- eMMC boot
- SPI Flash boot
- USB host
Device tree is imported from linux maintainer branch v6.9-armsoc/dts64,
commit 1b7e19448f8f ("arm64: dts: rockchip: Add devicetree for Pine64
PineTab2").
Signed-off-by: Jonas Karlman <jonas@kwiboo.se> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
Add a minimal generic RK3588S/RK3588 board that only have eMMC and SDMMC
enabled. This defconfig can be used to boot from eMMC or SD-card on most
RK3588S/RK3588 boards that follow reference board design.
Also fix the alphabetical order of RK3588 boards listed in Makefile and
documentation.
TB-RK3588X board is a Rockchip Toybrick RK3588 based development board.
Specification:
Rockchip Rk3588 SoC
4x ARM Cortex-A76, 4x ARM Cortex-A55
8/16GB Memory LPDDR4x
Mali G610MC4 GPU
2× MIPI-CSI0 Connector
1x 2Lanes PCIe3.0 Connector
1x SATA3.0 Connector
32GB eMMC Module
2x USB 2.0, 2x USB 3.0
1x HDMI Output, 1x HDMI Input
2x Ethernet Port
Functions work normally:
[1] USB2.0 Host
[2] Ethernet0 with PHY RTL8211F
More information can be obtained from the following websites:
[1] https://t.rock-chips.com/en/wiki/EN/tb-rk3588x_en/index.html
[2] http://t.rock-chips.com/
Kernel commits: 8ffe365f8dc7 ("arm64: dts: rockchip: Add devicetree support for TB-RK3588X board") 7140387ff49d ("dt-bindings: arm: rockchip: Add Toybrick TB-RK3588X")
Jonas Karlman [Sun, 25 Feb 2024 22:10:20 +0000 (22:10 +0000)]
phy: rockchip-inno-usb2: Limit changes made to regs
The USB2PHY regs already contain working default reset values for RK3328
and RK35xx as evidenced by the fact that this driver never has changed a
single value for these SoCs.
Reduce to only configure utmi_suspend_n and utmi_sel bits similar to
what is currently done on RK3399. Also add missing clkout_ctl for RK3588.
When enabled utmi_suspend_n is changed to normal mode and utmi_sel to
use otg/host controller utmi interface to phy. When disabled
utmi_suspend_n is changed to suspend mode and utmi_sel to use GRF utmi
interface to phy.
projects / u-boot.git / log