Peng Fan [Sun, 6 Oct 2024 00:22:51 +0000 (08:22 +0800)]
misc: ele_mu: Clear RR when initialize MU
When OS is doing ELE API call, before OS get the response, OS is force
reseted, then it is possible that MU RR has data during initialization
in SPL stage. So clear the RR registers, otherwise SPL ELE API call will
work abnormal.
Cc: Alice Guo <alice.guo@nxp.com> Cc: Marek Vasut <marex@denx.de> Signed-off-by: Peng Fan <peng.fan@nxp.com>
Ye Li [Sun, 6 Oct 2024 00:22:50 +0000 (08:22 +0800)]
misc: ele_mu: Update ELE MU to get TR/RR number from HW
The MU parameter register can provide the TR and RR number.
For i.MX95 which has 8 RR is different with i.MX93 and i.MX8ULP,
so update the driver to read the PAR for exact TR and RR number.
Also update compatible string for i.MX95 ELE MU.
Cc: Alice Guo <alice.guo@nxp.com> Cc: Marek Vasut <marex@denx.de> Reviewed-by: Peng Fan <peng.fan@nxp.com> Signed-off-by: Ye Li <ye.li@nxp.com>
Linus Walleij [Fri, 11 Oct 2024 14:49:56 +0000 (16:49 +0200)]
board: bcm96846: Enable NAND options
This adds reasonable NAND options to the BCM96846 reference design:
- CMD_NAND, MTD_RAW_NAND
- Disable SYS_NAND_ONFI_DETECTION as this just give error messages
- MTD, MTDPARTS with DM and related config options
- CMD_UBI and CMD_UBIFS as this is likely used with ubi/ubifs
What I didn't add was something like the following:
Because I don't actually have a BCM96846 reference design. These
are only available to Broadcom and their customers I think,
but perhaps the people at Broadcom can provide the detail of
the flash layout for BCM96846 so we can add this too so the
bcm96846_config is usable out of the box.
Linus Walleij [Fri, 11 Oct 2024 14:49:54 +0000 (16:49 +0200)]
mtd: rawnand: brcmnand: Add BCMBCA RAW NAND driver
The Broadcom BCA platforms are broadband access SoCs.
This is a port of the upstream Linux driver to U-Boot.
It was based on drivers/mtd/nand/raw/brcmnand/bcmbca_nand.c
from Linux v6.11.
Reviewed-by: Michael Trimarchi <michael@amarulasolutions.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Zixun LI [Sun, 21 Jul 2024 21:45:52 +0000 (23:45 +0200)]
mtd: nand: raw: atmel: Use ONFI ECC params if available
When ECC parameters are not specified in DT, first try ONFI ECC parameters
before fallback to maximum strength.
It's the Linux driver behavior since the driver rewriting in f88fc12.
From then 2 nand system refactors have been done in 6a1b66d6 and 53576c7b,
chip->ecc_strength_ds and chip->ecc_step_ds became
nanddev_get_ecc_requirements(). U-Boot didn't follow the refactor and
always use these 2 fields.
v2: Fix formatting, add upstream commit hash.
Signed-off-by: Zixun LI <zli@ogga.fr> Reviewed-by: Michael Trimarchi <michael@amarulasolutions.com> Acked-by: Balamanikandan Gunasundar
Tom Rini [Fri, 11 Oct 2024 18:23:25 +0000 (12:23 -0600)]
Merge patch series "Tidy up use of 'SPL' and CONFIG_SPL_BUILD"
Simon Glass <sjg@chromium.org> says:
When the SPL build-phase was first created it was designed to solve a
particular problem (the need to init SDRAM so that U-Boot proper could
be loaded). It has since expanded to become an important part of U-Boot,
with three phases now present: TPL, VPL and SPL
Due to this history, the term 'SPL' is used to mean both a particular
phase (the one before U-Boot proper) and all the non-proper phases.
This has become confusing.
For a similar reason CONFIG_SPL_BUILD is set to 'y' for all 'SPL'
phases, not just SPL. So code which can only be compiled for actual SPL,
for example, must use something like this:
In Makefiles we have similar issues. SPL_ has been used as a variable
which expands to either SPL_ or nothing, to chose between options like
CONFIG_BLK and CONFIG_SPL_BLK. When TPL appeared, a new SPL_TPL variable
was created which expanded to 'SPL_', 'TPL_' or nothing. Later it was
updated to support 'VPL_' as well.
This series starts a change in terminology and usage to resolve the
above issues:
- The word 'xPL' is used instead of 'SPL' to mean a non-proper build
- A new CONFIG_XPL_BUILD define indicates that the current build is an
'xPL' build
- The existing CONFIG_SPL_BUILD is changed to mean SPL; it is not now
defined for TPL and VPL phases
- The existing SPL_ Makefile variable is renamed to SPL_
- The existing SPL_TPL Makefile variable is renamed to PHASE_
It should be noted that xpl_phase() can generally be used instead of
the above CONFIGs without a code-space or run-time penalty.
This series does not attempt to convert all of U-Boot to use this new
terminology but it makes a start. In particular, renaming spl.h and
common/spl seems like a bridge too far at this point.
The series is fully bisectable. It has also been checked to ensure there
are no code-size changes on any commit.
Simon Glass [Mon, 30 Sep 2024 01:49:31 +0000 (19:49 -0600)]
scripts: Add some comments about autoconf.mk
Now that the conversion of all CONFIG options to Kconfig is complete,
these files only contain the xPL_BUILD defines. Add a comment to make
this clear.
usb: gadget: cdns3: Fix cdns3_ep_config() by setting ep.maxpacket
The function cdns3_ep_config() calculates the maximum packet size based
on the Endpoint Type and the Gadget Speed and stores it in the variable
"max_packet_size". This value is then programmed in the USB Controller
for the corresponding Endpoint. This may result in a mismatch between
the maximum packet size programmed in the USB controller and the maximum
packet size seen by the UDC Core via "maxpacket" member of "struct usb_ep".
Additionally, since TD_SIZE is calculated in cdns3_ep_run_transfer() on the
basis of the maximum packet size stored in the "maxpacket" member of
"struct usb_ep", it may lead to an incorrect value of TD_SIZE when compared
with what the USB controller actually expects (max_packet_size).
Tom Rini [Thu, 10 Oct 2024 22:02:37 +0000 (16:02 -0600)]
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.
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>
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>
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>
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>
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>
Joy Zou [Mon, 23 Sep 2024 13:11:31 +0000 (21:11 +0800)]
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>
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
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.
Marek Vasut [Fri, 6 Sep 2024 21:09:16 +0000 (23:09 +0200)]
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>
Marek Vasut [Mon, 4 Mar 2024 16:16:05 +0000 (17:16 +0100)]
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.
Tom Rini [Wed, 9 Oct 2024 22:58:42 +0000 (16:58 -0600)]
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
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>
Simon Glass [Thu, 26 Sep 2024 21:59:31 +0000 (23:59 +0200)]
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>
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.
Chris Morgan [Wed, 10 Jul 2024 23:17:17 +0000 (18:17 -0500)]
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.
Jernej Skrabec [Fri, 30 Aug 2024 15:55:10 +0000 (10:55 -0500)]
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>
Jernej Skrabec [Fri, 30 Aug 2024 15:55:09 +0000 (10:55 -0500)]
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>
Chris Morgan [Fri, 30 Aug 2024 15:55:07 +0000 (10:55 -0500)]
sunxi: H616: DRAM: Add alternative pin mapping
It seems that different dies need different PHY pin mapping. Select
alternatives at compile time.
Signed-off-by: Jernej Skrabec <jernej.skrabec@gmail.com>
[adapted to switch from runtime to compile time config] Signed-off-by: Chris Morgan <macromorgan@hotmail.com>
Andre Przywara [Mon, 7 Oct 2024 22:09:45 +0000 (23:09 +0100)]
sunxi: power: axp809: Fix DCDC4 programming
When trying to set the DCDC4 regulator, the code was accidentally
setting the voltage register for DCDC5 (VCC-DRAM). The higher voltage
doesn't harm the DRAM chips, but upsets the Linux regulator driver: when
it tried to correct that, it tripped over a separate DT bug.
The DCDC5 DT limits are 1.425 and 1.575V, which cannot bet set with the
rail's resolution of 50mV. The kernel driver gave up, and made in turn
the system hang, as the PMIC powers essential devices.
Fix the copy&paste bug by using the correct PMIC voltage register.
Signed-off-by: Andre Przywara <andre.przywara@arm.com>
Andre Przywara [Mon, 12 Feb 2024 23:13:01 +0000 (23:13 +0000)]
clk: sunxi: a80: Fix reset description
Clock gates and reset lines share a common structure in the sunxi clock
driver descriptions, but use different flags to tell them apart.
The description of the Allwinner A80 MMC clock reset lines was
erroneously using the "GATE" macro, which made the reset driver ignore
that entry, complaining with:
sunxi_set_reset: (RST-reset:#0) unhandled
Change that to the correct "RESET" macro, to make the reset driver
happy.
Andre Przywara [Wed, 7 Aug 2024 23:08:45 +0000 (00:08 +0100)]
sunxi: H616: switch to OF_UPSTREAM
With the recent "old-style sunxi" sync and the penultimate OF_UPSTREAM DT
update, both directories were based on the same v6.10 kernel tree.
And while there is one subtle difference in many Allwinner SoC's DT
files, the H616 ones turn out to be identical.
Remove the old copies of the H616 related .dts and .dtsi files, and
switch the whole H616 SoC over to use OF_UPSTREAM. This immediately
benefits from the recent upstream DT update, to kernel v6.11.
Signed-off-by: Andre Przywara <andre.przywara@arm.com>
Tom Rini [Wed, 9 Oct 2024 18:25:39 +0000 (12:25 -0600)]
Merge patch series "spi: Various Kconfig fixes"
John Watts <contact@jookia.org> says:
I'm doing some SPI work so I tried to compile all the drivers on my
sunxi board to try and avoid some regressions. This failed, so here are
some fixes for this.
projects / thirdparty / u-boot.git / log
