95729 Commits

Author SHA1 Message Date
Simon Glass
01ab644ebc Makefile: Add a u-boot.cfg file for VPL
Create this file for VPL as well, for consistency.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>
2024-10-11 11:44:46 -06:00
Tom Rini
5d899fc58c Merge branch 'master' of https://source.denx.de/u-boot/custodians/u-boot-usb 2024-10-11 09:35:49 -06:00
Jan Kiszka
c69ba5a4fe usb: dwc3-generic: fix CONFIG_DM_REGULATOR-off case
When DM_REGULATOR is disabled, all calls will return -ENOSYS. Account
for that so that targets like the IOT2050 will work again.

Fixes: de451d5d5b6f ("usb: dwc3-generic: support external vbus regulator")
Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>
Reviewed-by: Caleb Connolly <caleb.connolly@linaro.org>
2024-10-11 05:11:06 +02:00
Tom Rini
c264a5940e Merge patch series "led: introduce LED boot and activity function"
Christian Marangi <ansuelsmth@gmail.com> says:

This series is a reworked version of the previous seried:
misc: introduce STATUS LED activity function

This series port and expand the legacy concept of LED boot from
the legacy Status LED API to new LED API.

One thing that many device need is a way to communicate to the
user that the device is actually doing something.

This is especially useful for recovery steps where an
user (for example) insert an USB drive, keep a button pressed
and the device autorecover.

There is currently no way to signal the user externally that
the bootloader is processing/recoverying aside from setting
a LED on.

A solid LED on is not enough and won't actually signal any
kind of progress.
Solution is the good old blinking LED but uboot doesn't
suggest (and support) interrupts and almost all the LED
are usually GPIO LED that doesn't support HW blink.

Additional Kconfg are also introduced to set the LED boot and
activity. Those are referenced by label.

A documentation for old and these new LED API is created.
2024-10-10 16:02:37 -06:00
Christian Marangi
aadf575050 test: dm: Expand ofnode options test with new helper
Expand ofnode options test with new generic helper for bool, int and
string.

Signed-off-by: Christian Marangi <ansuelsmth@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
2024-10-10 16:02:20 -06:00
Christian Marangi
9046279d92 test: dm: Add tests for LED boot and activity
Add tests for LED boot and activity feature and add required property in
sandbox test DTS.

Signed-off-by: Christian Marangi <ansuelsmth@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
2024-10-10 16:02:20 -06:00
Christian Marangi
051c448c8b doc: introduce led.rst documentation
Introduce simple led.rst documentation to document all the additional
Kconfig and the current limitation of LED_BLINK and GPIO software blink.

Also add missing definition for sw_blink in led_uc_plat struct.

Signed-off-by: Christian Marangi <ansuelsmth@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
2024-10-10 16:02:20 -06:00
Christian Marangi
990f726ce7 ubi: implement support for LED activity
Implement support for LED activity. If the feature is enabled,
make the defined ACTIVITY LED to signal ubi write operation.

Signed-off-by: Christian Marangi <ansuelsmth@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
2024-10-10 16:02:20 -06:00
Christian Marangi
0319bae9e7 mtd: implement support for LED activity
Implement support for LED activity. If the feature is enabled,
make the defined ACTIVITY LED to signal mtd operations.

LED activity is implemented HERE and not in the subsystem side to limit
any performance degradation in case multiple call to MTD subsystem read/write
are done.

Signed-off-by: Christian Marangi <ansuelsmth@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
2024-10-10 16:02:20 -06:00
Christian Marangi
5d162bbb20 tftp: implement support for LED activity
Implement support for LED activity. If the feature is enabled,
make the defined ACTIVITY LED to signal traffic.

Also turn the ACTIVITY LED OFF if a CTRL-C is detected in the main
net loop function.

Signed-off-by: Christian Marangi <ansuelsmth@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
2024-10-10 16:02:20 -06:00
Christian Marangi
aad8cfa3ca led: implement LED activity API
Implement LED activity API similar to BOOT LED API.

Usual activity might be a file transfer with TFTP, a flash write...

User of this API will call led_activity_on/off/blink() to signal these
kind of activity.

New Kconfig is implemented similar to BOOT LED, LED_ACTIVITY to
enable support for it.

It's introduced a new /options/u-boot property "activity-led" and
"activity-led-period" to define the activity LED label and the
default period when the activity LED is set to blink mode.

If "activity-led-period" is not defined, the value of 250 (ms) is
used by default.

If CONFIG_LED_BLINK or CONFIG_LED_SW_BLINK is not enabled,
led_boot_blink call will fallback to simple LED ON.

Signed-off-by: Christian Marangi <ansuelsmth@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
2024-10-10 16:02:20 -06:00
Christian Marangi
fc55ae03fd common: board_r: rework BOOT LED handling
Rework BOOT LED handling. There is currently one legacy implementation
for BOOT LED from Status Led API.

This work on ancient implementation used by BOOTP by setting the LED
to Blink on boot and to turn it OFF when the firmware was correctly
received by network.

Now that we new LED implementation have support for LED boot, rework
this by also set the new BOOT LED to blink and also set it to ON before
entering main loop to confirm successful boot.

Signed-off-by: Christian Marangi <ansuelsmth@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
2024-10-10 16:02:20 -06:00
Christian Marangi
914fd75a5d led: implement LED boot API
Implement LED boot API to signal correct boot of the system.

led_boot_on/off/blink() are introduced to turn ON, OFF and BLINK the
designated boot LED.

New Kconfig is introduced, CONFIG_LED_BOOT to enable the feature.
This makes use of the /options/u-boot property "boot-led" to the
define the boot LED.
It's also introduced a new /options/u-boot property "boot-led-period"
to define the default period when the LED is set to blink mode.

If "boot-led-period" is not defined, the value of 250 (ms) is
used by default.

If CONFIG_LED_BLINK or CONFIG_LED_SW_BLINK is not enabled,
led_boot_blink call will fallback to simple LED ON.

To cache the data we repurpose the now unused led_uc_priv for storage of
global LED uclass info.

Signed-off-by: Christian Marangi <ansuelsmth@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
2024-10-10 16:02:20 -06:00
Christian Marangi
30f6ea5138 dm: core: implement ofnode_options helpers
Implement ofnode_options helpers to read options in /options/u-boot to
adapt to the new way to declare options as described in [1].

[1] dtschema/schemas/options/u-boot.yaml

Signed-off-by: Christian Marangi <ansuelsmth@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
2024-10-10 16:02:20 -06:00
Christian Marangi
9e3d83301e led: toggle LED on initial SW blink
We currently init the LED OFF when SW blink is triggered when
on_state_change() is called. This can be problematic for very short
period as the ON/OFF blink might never trigger.

Toggle the LED (ON if OFF, OFF if ON) on initial SW blink to handle this
corner case and better display a LED blink from the user.

Signed-off-by: Christian Marangi <ansuelsmth@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Michael Trimarchi <michael@amarulasolutions.com>
2024-10-10 16:02:20 -06:00
Joy Zou
a404065479 power: pmic: pca9450: Add missing newline
Add newline character in log info end.

Signed-off-by: Joy Zou <joy.zou@nxp.com>
Reviewed-by: Ye Li <ye.li@nxp.com>
Signed-off-by: Peng Fan <peng.fan@nxp.com>
2024-10-10 12:17:46 -06:00
Joy Zou
a857e47263 power: pmic/regulator: Support pca9452
Add PCA9452 PMIC/Regulator support.

Signed-off-by: Joy Zou <joy.zou@nxp.com>
Reviewed-by: Ye Li <ye.li@nxp.com>
Signed-off-by: Peng Fan <peng.fan@nxp.com>
2024-10-10 12:17:46 -06:00
Joy Zou
cd63c4a79a power: regulator: pca9450: Update the BUCK1 voltage range
The pmic could be trimed with updated BUCK1 range, so update the range
for trimed pmic. The default value of Toff_Deb is used to distinguish
the non-trimed and trimed pmic.

Signed-off-by: Joy Zou <joy.zou@nxp.com>
Reviewed-by: Ye Li <ye.li@nxp.com>
Signed-off-by: Peng Fan <peng.fan@nxp.com>
2024-10-10 12:17:46 -06:00
Sidharth Prabukumar
6417ee7ec5 power: mp5416: Fix LDO SVAL for MP5416 PMIC
The MP5416 PMIC's LDO set-value formula is incorrect. This patch fixes
it by using the correct formula.

Signed-off-by: Sidharth Prabukumar <sidharth.prabukumar@gmail.com>
Cc: Jaehoon Chung <jh80.chung@samsung.com>
Reviewed-by: Jaehoon Chung <jh80.chung@samsung.com>
2024-10-10 11:59:50 -06:00
Takahiro Kuwano
db11dfdac5 mtd: spi-nor-ids: Add support for S28HS256T
Infineon S28HS256T is 256Mb Octal SPI device which has same
functionalities with 512Mb and 1Gb parts.

Link:https://www.infineon.com/dgdl/Infineon-S28HS256T_S28HL256T_256Mb_SEMPER_Flash_Octal_interface_1_8V_3-DataSheet-v02_00-EN.pdf?fileId=8ac78c8c8fc2dd9c018fc66787aa0657

Signed-off-by: Takahiro Kuwano <Takahiro.Kuwano@infineon.com>
Reviewed-by: Pratyush Yadav <pratyush@kernel.org>
Reviewed-by: Tudor Ambarus <tudor.ambarus@linaro.org>
2024-10-10 08:13:23 -06:00
Tom Rini
113b1a86ce Merge patch series "mtd: spi-nor-ids: Add NO_CHIP_ERASE flag to Infineon 2Gb parts"
Takahiro Kuwano <Takahiro.Kuwano@infineon.com> says:

S25HS02GT, S25HL02GT, and S28HS02GT are dual-die package parts and do
not support chip erase.

In v2, split the patch and add fixes tag.

Takahiro Kuwano (2):
  mtd: spi-nor-ids: Add NO_CHIP_ERASE flag to Infineon s25hl02Gt and
    s25hs02gt
  mtd: spi-nor-ids: Add NO_CHIP_ERASE flag to Infineon s28hs02gt
2024-10-10 08:13:02 -06:00
Takahiro Kuwano
abb8213b4b mtd: spi-nor-ids: Add NO_CHIP_ERASE flag to Infineon s28hs02gt
S28HS02GT is dual-die package parts and do not support chip erase.

Fixes: 16dd1095101 ("mtd: spi-nor-ids: Add Infineon(Cypress) s28hs02gt ID")
Reviewed-by: Tudor Ambarus <tudor.ambarus@linaro.org>
Signed-off-by: Takahiro Kuwano <Takahiro.Kuwano@infineon.com>
2024-10-10 08:12:58 -06:00
Takahiro Kuwano
ae391a2c87 mtd: spi-nor-ids: Add NO_CHIP_ERASE flag to Infineon s25hl02Gt and s25hs02gt
S25HL02GT and S25HS02GT are dual-die package parts and do not support
chip erase.

Fixes: c95a914aed7 ("mtd: spi-nor-ids: Add Cypress s25hl-t/s25hs-t")
Reviewed-by: Tudor Ambarus <tudor.ambarus@linaro.org>
Signed-off-by: Takahiro Kuwano <Takahiro.Kuwano@infineon.com>
2024-10-10 08:12:58 -06:00
Tom Rini
fbab6b3b9a Merge patch series "mtd: spi-nor: Add support for S25FS-S family"
tkuw584924@gmail.com <tkuw584924@gmail.com> says:

From: Takahiro Kuwano <Takahiro.Kuwano@infineon.com>

The S25FS064S, S25FS128S, and S25FS256S are the same family of SPI NOR
Flash devices with S25FS512S.

Datasheets:
https://www.infineon.com/dgdl/Infineon-S25FS064S_64_Mb_8_MB_FS-S_Flash_SPI_Multi-I_O_1-DataSheet-v10_00-EN.pdf?fileId=8ac78c8c7d0d8da4017d0ed526b25412
https://www.infineon.com/dgdl/Infineon-S25FS128S_S25FS256S_1.8_V_Serial_Peripheral_Interface_with_Multi-I_O_MirrorBit(R)_Non-Volatile_Flash-DataSheet-v15_00-EN.pdf?fileId=8ac78c8c7d0d8da4017d0ed6b5ab5758
2024-10-10 08:12:18 -06:00
Takahiro Kuwano
f42e72972f mtd: spi-nor-id: Add S25FS064S, S25FS128S, S25FS256S IDs
The S25FS064S, S25FS128S, and S25FS256S are the same family of SPI NOR
Flash devices with S25FS512S. Some difference depending on the device
densities are taken care in post SFDP fixup.

Signed-off-by: Takahiro Kuwano <Takahiro.Kuwano@infineon.com>
Reviewed-by: Pratyush Yadav <pratyush@kernel.org>
2024-10-10 08:12:13 -06:00
Takahiro Kuwano
021015ac3d mtd: spi-nor-id: Use INFO6 macro for S25FL-S
The 6th ID byte is needed to distiguish S25FL-S and S25FS-S families.

Signed-off-by: Takahiro Kuwano <Takahiro.Kuwano@infineon.com>
Reviewed-by: Pratyush Yadav <pratyush@kernel.org>
Reviewed-by: Dhruva Gole <d-gole@ti.com>
2024-10-10 08:12:13 -06:00
Takahiro Kuwano
2d7a35d90e mtd: spi-nore-core: Fix 4KB erase opcode for s25fs-s
The correct 4KB erase opcode should be selected based on the address width
currently used.

Fixes: 562d166a13 ("mtd: spi-nor-core: Add fixups for s25fs512s")
Signed-off-by: Takahiro Kuwano <Takahiro.Kuwano@infineon.com>
Reviewed-by: Pratyush Yadav <pratyush@kernel.org>
Reviewed-by: Dhruva Gole <d-gole@ti.com>
2024-10-10 08:12:12 -06:00
Marek Vasut
3c5dcde699 mtd: spi-nor-ids: Extend w25q16cl entry with locking support
The w25q16cl does support locking the same way w25q16dw does,
fill in the missing flags.

Signed-off-by: Marek Vasut <marex@denx.de>
2024-10-10 08:11:27 -06:00
Marek Vasut
aa7d0f575f mtd: spi-nor-ids: Deduplicate mx25u25635f entry
The mx25u25635f entry exists twice in spi_nor_ids, remove the less
complete variant of the entry and keep only one copy of it.

Fixes: f0084f1dfdbc ("drivers/mtd/spi/spi-nor-ids.c: add mx25u25635f support")
Signed-off-by: Marek Vasut <marex@denx.de>
Reviewed-by: Michal Simek <michal.simek@amd.com>
Reviewed-by: Tudor Ambarus <tudor.ambarus@linaro.org>
2024-10-10 08:11:21 -06:00
Marek Vasut
f52ec82fa0 mtd: spi-nor-ids: Deduplicate w25q16dw entry
The w25q16dw entry exists twice in spi_nor_ids, remove the less
complete variant of the entry and keep only one copy of it.

Fixes: baef13ec9d59 ("mtd: spi-nor-ids: Add support for flashes tested by xilinx")
Signed-off-by: Marek Vasut <marex@denx.de>
Reviewed-by: Michal Simek <michal.simek@amd.com>
Reviewed-by: Tudor Ambarus <tudor.ambarus@linaro.org>
2024-10-10 08:11:11 -06:00
Marek Vasut
215f1d5794 mtd: spi-nor: Clear Winbond SR3 WPS bit on boot
Some Winbond SPI NORs have special SR3 register which is
used among other things to control whether non-standard
"Individual Block/Sector Write Protection" (WPS bit)
locking scheme is activated. This non-standard locking
scheme is not supported by either U-Boot or Linux SPI
NOR stack so make sure it is disabled, otherwise the
SPI NOR may appear locked for no obvious reason.

This SR3 WPS appears e.g. on W25Q16FW which has the same ID as
W25Q16DW, but the W25Q16DW does not implement the SR3 WPS bit.

Signed-off-by: Marek Vasut <marex@denx.de>
2024-10-10 08:10:12 -06:00
Tom Rini
1ff60b1f0a Merge tag 'efi-2025-01-rc1' of https://source.denx.de/u-boot/custodians/u-boot-efi
Pull request efi-2025-01-rc1

Documentation:

* Move the generic memory-documentation to doc/
* Fix typo boormethod

UEFI:

* Delete rng-seed if having EFI RNG protocol
* Don't call restart_uboot in EFI watchdog test
* Simplify building EFI binaries in Makefile
* Show FirmwareVendor and FirmwareRevision in helloworld
* Add debug output for efi bootmeth

Other:

* CONFIG_CMD_CLK should depend on CONFIG_CLK
* simplify clk command
* enable clk command on the sandbox
2024-10-09 22:04:56 -06:00
Heinrich Schuchardt
5ba825194a sandbox: enable clk command on the sandbox
Enabling the clk command on the sandbox will allow us to write tests
for it.

Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
2024-10-09 22:04:56 -06:00
Heinrich Schuchardt
6015f59086 cmd: clk: simplify clk command
CONFIG_DM is always true.
The clk command is only built if CONFIG_CLK=y.

Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
2024-10-09 22:04:56 -06:00
Heinrich Schuchardt
56efea8805 cmd/Kconfig: CONFIG_CMD_CLK should depend on CONFIG_CLK
The clk command cannot provide useful output without a clock driver.
So let it depend on CONFIG_CLK.

Since commit 258c1002383e ("cmd: clk: Use dump function from clk_ops")
the remark about deprecation is obsolete. Remove it.

Since commit 7ab418fbe612 ("clk: add support for setting clk rate from
cmdline") the clk command can be used to set clock frequencies. Mention
it.

Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
2024-10-09 22:04:56 -06:00
Heinrich Schuchardt
d25a10401d boot: typo boormethod
%s/boormethod/bootmethod/

Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
Reviewed-by: Peter Robinson <pbrobinson@gmail.com>
2024-10-09 22:04:56 -06:00
Heinrich Schuchardt
ee34507f70 test: don't call restart_uboot in EFI watchdog test
Calling u_boot_console.restart_uboot() in
test_efi_selftest_watchdog_reboot() may lead to incorrect results.

While the watchdog triggered reboot is running thee test environment may
need some time before triggering a reboot itself. This may lead to
duplicate output of the U-Boot greeter which is recorded as an error.

Reported-by: Tom Rini <trini@konsulko.com>
Fixes: df172e117d1d ("test/py: test reboot by EFI watchdog")
Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
Reviewed-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
2024-10-09 22:04:56 -06:00
Simon Glass
4e97d9b259 bootstd: Add debugging for efi bootmeth
Add a little debugging so we can see what is happening.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
2024-10-09 22:04:56 -06:00
Simon Glass
3899e3f0ba efi_loader: Show FirmwareVendor and FirmwareRevision in helloworld
Show the firmware vendor and revision to make it clear which firmware is
used, e.g. whether U-Boot is providing the boot services.

The output will look like

    Firmware vendor: Das U-Boot
    Firmware revision: 20241000

Signed-off-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
2024-10-09 22:04:56 -06:00
Simon Glass
3697344866 efi_loader: Shorten the app rules further
Add a way to factor out the CFLAGS changes for each app, since they are
all the same.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
2024-10-09 22:04:56 -06:00
Simon Glass
0cee367848 efi_loader: Shorten the app rules
We have quite a few apps now, so create a way to specify them as a list
rather than repeating the same rules again and again.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
2024-10-09 22:04:56 -06:00
Simon Glass
69616cec72 efi: arm: x86: riscv: Drop crt0/relocal extra- rules
The link rule (for $(obj)/%_efi.so) in scripts/Makefile.lib handles
pulling in efi_crt0.o and efi_reloc.o so drop the 'extra' rules.

Signed-off-by: Simon Glass <sjg@chromium.org>
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
2024-10-09 22:04:56 -06:00
Simon Glass
6fe80876dc efi_loader: Rename and move CMD_BOOTEFI_HELLO_COMPILE
This is not actually a command so the name is confusing. Use
BOOTEFI_HELLO_COMPILE instead. Put it in the efi_loader directory
with the other such config options.

The link rule (for $(obj)/%_efi.so) in scripts/Makefile.lib handles
pulling in efi_crt0.o and efi_reloc.o so drop the 'extra' rules.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
2024-10-09 22:04:56 -06:00
Simon Glass
77a93ae681 doc: Move the generic memory-documentation to doc/
Move this section of the README into doc/ with some minor updates to
mention SPL and user lower-case hex.

Signed-off-by: Simon Glass <sjg@chromium.org>
Acked-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
2024-10-09 22:04:56 -06:00
Heinrich Schuchardt
b03b2a45f9 efi_leader: delete rng-seed if having EFI RNG protocol
For measured be boot we must avoid any volatile values in the device-tree.
We already delete /chosen/kaslr-seed if we provide and EFI RNG protocol.

Additionally remove /chosen/rng-seed provided by QEMU or U-Boot.

Reviewed-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
2024-10-09 22:04:56 -06:00
Chris Morgan
2f7ab49644 sunxi: Add support for Anbernic RG35XX-2024
The Anbernic RG35XX series of devices are based around an Allwinner
H700 SoC with 1GB of RAM, 2 SD cards, and multiple input buttons.

This bootloader has been tested on the Anbernic RG35XX-2024 and
RG35XX-H, but should be suitable for the entire lineup of H700 based
devices.

A future series of updates will add board selection logic to identify
and load the correct device tree automatically.

Signed-off-by: Chris Morgan <macromorgan@hotmail.com>
2024-10-10 00:43:51 +01:00
Chris Morgan
c9fbe861a2 arm64: dts: allwinner: h616: Add r_i2c pinctrl nodes
Add pinctrl nodes for the r_i2c node. Without the pinmux defined the
r_i2c bus may fail to work, possibly if the bootloader uses rsb mode
for the PMIC.

Fixes: 0d17c8651188 ("arm64: dts: allwinner: Add Allwinner H616 .dtsi file")

Reviewed-by: Andre Przywara <andre.przywara@arm.com>
Signed-off-by: Chris Morgan <macromorgan@hotmail.com>
Fixes: 0d17c8651188 ("arm64: dts: allwinner: Add Allwinner H616 .dtsi file")
Link: https://lore.kernel.org/r/20240710231718.106894-3-macroalpha82@gmail.com
Signed-off-by: Chen-Yu Tsai <wens@csie.org>

[ upstream commit: 7c9ea4ab76176f65f4f55aa144f9145a4bccaacb ]

(cherry-picked from commit 1665557aa57c2140d014d68dfe1a1f92f9baac82)
Reviewed-by: Andre Przywara <andre.przywara@arm.com>
2024-10-10 00:43:51 +01:00
Chris Morgan
46ada3d42e arm64: dts: allwinner: h616: Change RG35XX Series from r_rsb to r_i2c
Change the Anbernic RG35XX series to use the r_i2c bus for the PMIC
instead of the r_rsb bus. This is to keep the device tree consistent
as there are at least 3 devices (the RG35XX-SP, RG28XX, and RG40XX-H)
that have an external RTC on the r_i2c bus.

Signed-off-by: Chris Morgan <macromorgan@hotmail.com>
Reviewed-by: Andre Przywara <andre.przywara@arm.com>
Tested-by: Ryan Walklin <ryan@testtoast.com>
Link: https://lore.kernel.org/r/20240710231718.106894-4-macroalpha82@gmail.com
Signed-off-by: Chen-Yu Tsai <wens@csie.org>

[ upstream commit: c712e5d0985628b1df13930489b49b740e610a2b ]

(cherry picked from commit 43c3a035746af3c8cad5b65055d88f1de8406823)
Reviewed-by-by: Andre Przywara <andre.przywara@arm.com>
2024-10-10 00:43:51 +01:00
Jernej Skrabec
6c49270960 sunxi: H616: dram: Update mbus priorities
CSI1 channel (22) is missing and IOMMU (25) has priority flag set in
vendor bootloader. Fix that.

While at it, replace bandwidth flag with priority since original flag has
always value "true".

Signed-off-by: Jernej Skrabec <jernej.skrabec@gmail.com>
Tested-by: Chris Morgan <macromorgan@hotmail.com>
Reviewed-by: Andre Przywara <andre.przywara@arm.com>
2024-10-10 00:23:42 +01:00
Jernej Skrabec
b37edefc20 sunxi: H616: DRAM: Adjust size scan procedure
It's safer to start scanning for columns first and then rows. Columns
reside on LSB address pins, which means that second configuration will
already have all needed row pins active.

This is also preparation for introducing DDR4 support, which need scan
for banks and bank groups too.

Signed-off-by: Jernej Skrabec <jernej.skrabec@gmail.com>
Tested-by: Chris Morgan <macromorgan@hotmail.com>
2024-10-10 00:23:42 +01:00