Neil Armstrong [Fri, 20 Sep 2024 13:33:34 +0000 (15:33 +0200)]
ARM: meson: add support for Libre Computer aml-s905d3-cc
Add support for the Libre Computer aml-s905d3-cc "Solitude" board:
https://libre.computer/products/aml-s905d3-cc/
The Solitude board has a Credit Card form factor, similar to the
the previous "Le Potato" card, but with the Amlogic A311D SoC,
MIPI DSI and CSI connectors. PoE header and a single USB2 Type-C
connector replacing the microUSB one for power and USB 2.0.
The board has an embedded SPI NOR flash, and EFI Capsule support
is added.
The GUID is dynamically generated for the board, to get it:
=> efidebug capsule esrt
========================================
ESRT: fw_resource_count=1
ESRT: fw_resource_count_max=1
ESRT: fw_resource_version=1
[entry 0]==============================
ESRT: fw_class=4302C3CB-2502-5EFE-87E0-894A8A322893
ESRT: fw_type=unknown
ESRT: fw_version=0
ESRT: lowest_supported_fw_version=0
ESRT: capsule_flags=0
ESRT: last_attempt_version=0
ESRT: last_attempt_status=success
========================================
On the host (with the aml_encrypt_g12a result binary):
$ eficapsule --guid 4302C3CB-2502-5EFE-87E0-894A8A322893 -i 1 u-boot.bin u-boot.cap
On the board (from USB disk containing u-boot.cap at root):
=> load usb 0:1 $kernel_addr_r u-boot.cap
=> efidebug capsule update $kernel_addr_r
Neil Armstrong [Fri, 20 Sep 2024 13:33:33 +0000 (15:33 +0200)]
ARM: meson: add support for Libre Computer aml-a311d-cc
Add support for the Libre Computer aml-a311d-cc "Alta" board:
https://libre.computer/products/aml-a311d-cc/
The Alta board has a Credit Card form factor, similar to the
the prvevious "Le Potato" card, but with the Amlogic A311D SoC,
MIPI DSI and CSI connectors. PoE header and a single USB2 Type-C
connector replacing the microUSB one for power and USB 2.0.
The board has an embedded SPI NOR flash, and EFI Capsule support
is added.
The GUID is dynamically generated for the board, to get it:
=> efidebug capsule esrt
========================================
ESRT: fw_resource_count=1
ESRT: fw_resource_count_max=1
ESRT: fw_resource_version=1
[entry 0]==============================
ESRT: fw_class=17E07D9D-4D91-53F4-8780-1D91F279C1A5
ESRT: fw_type=unknown
ESRT: fw_version=0
ESRT: lowest_supported_fw_version=0
ESRT: capsule_flags=0
ESRT: last_attempt_version=0
ESRT: last_attempt_status=success
========================================
On the host (with the aml_encrypt_g12a result binary):
$ eficapsule --guid 17E07D9D-4D91-53F4-8780-1D91F279C1A5 -i 1 u-boot.bin u-boot.cap
On the board (from USB disk containing u-boot.cap at root):
=> load usb 0:1 $kernel_addr_r u-boot.cap
=> efidebug capsule update $kernel_addr_r
Since the aml-s805-cc works well using EFI, and now the capsule updates
backend has been merged, let's enable the missing configs and add
the required structures to support it.
The GUID is dynamically generated for the board, to get it:
=> efidebug capsule esrt
========================================
ESRT: fw_resource_count=1
ESRT: fw_resource_count_max=1
ESRT: fw_resource_version=1
[entry 0]==============================
ESRT: fw_class=B8079027-9B2C-57D4-86AA-CC782ADA598C
ESRT: fw_type=unknown
ESRT: fw_version=0
ESRT: lowest_supported_fw_version=0
ESRT: capsule_flags=0
ESRT: last_attempt_version=0
ESRT: last_attempt_status=success
========================================
On the host (with the aml_encrypt_gxl result binary):
$ eficapsule --guid B8079027-9B2C-57D4-86AA-CC782ADA598C -i 1 u-boot.bin u-boot.cap
On the board (from USB disk containing u-boot.cap at root):
=> load usb 0:1 $kernel_addr_r u-boot.cap
=> efidebug capsule update $kernel_addr_r
Neil Armstrong [Tue, 17 Sep 2024 12:34:45 +0000 (14:34 +0200)]
board: libretech-ac: move board support into dedicated directory
The libretech-ac aka aml-s805x-ac supports mainline U-boot
from a dedicated SPI flash, move the board support into
a dedicated vendor/board subdirectory in order to support
vendor specific customization.
It also aligns with the vendor downstream changes.
Tom Rini [Sun, 13 Oct 2024 16:19:05 +0000 (10:19 -0600)]
Merge branch 'staging' of https://source.denx.de/u-boot/custodians/u-boot-tegra
Assorted Tegra enhancements. Merged with the recent XPL_BUILD changes,
resolve some whitespace issues and fix the name of the new apalis-tk1
env file by Tom.
This module is a color active matrix LCD module incorporating
Oxide TFT (Thin Film Transistor). It is composed of a color TFT-LCD
panel, driver ICs, a control circuit and power supply circuit, and
a backlight unit. Graphics and texts can be displayed on a 2560×1600
dots panel with (16,777,216) colors by using MIPI DUAL DSI interface,
supplying +3.3V DC supply voltage for TFT-LCD panel driving and
supplying DC supply voltage for LED Backlight.
Implement ganged mode support for the Tegra DSI driver. The DSI host
controller to gang up with is specified via a phandle in the device tree
and the resolved DSI host controller used for the programming of the
ganged-mode registers.
Jonas Schwöbel [Mon, 22 Jan 2024 12:40:27 +0000 (14:40 +0200)]
Tegra30: Add funcmux for UART over SD slot
Tegra 3 has UART-E exposable via SD card slot which may be
handy for debugging. This change only adds funcmux part, to
use UART-E on the device you additionally would need:
- set stdout-path to serial@70006400 (uarte)
- configure sdmmc1_dat3_py4 and sdmmc1_dat2_py5 pinmux for
uarte
- disable or remove sdhci@7800000 node
- enable CONFIG_TEGRA_ENABLE_UARTE in defconfig
- set CFG_SYS_NS16550_COM to NV_PA_APB_UARTE_BASE in device
header
Signed-off-by: Jonas Schwöbel <jonasschwoebel@yahoo.de> Signed-off-by: Svyatoslav Ryhel <clamor95@gmail.com>
TegraPT is compatible with EFI part but it can't pass Protective MBR check.
Skip this check if CONFIG_TEGRA_PARTITION is enabled, storage uclass is MMC
and devnum is 0. Note, eMMC on supported devices MUST be aliased to mmc0.
Peng Fan [Sat, 12 Oct 2024 09:34:10 +0000 (17:34 +0800)]
clk: imx8mp: Add i.MX8MP Dummy clk
i.MX8MP SDHC use CLK_IMX8MP_DUMMY clk entry. Without the clk, the bulk
api will return failure.
The correct entry should be replaced with IMX8MP_IPG_ROOT clk in device
tree. This will be done in Kernel device tree and sync to U-Boot in
future:
https://lore.kernel.org/all/20241012025221.1728438-1-peng.fan@oss.nxp.com/
Brian Ruley [Tue, 1 Oct 2024 13:58:09 +0000 (16:58 +0300)]
binman: add fast authentication method for i.MX8M signing
Using the PKI tree with SRKs as intermediate CA isn't necessary or even
desirable in some situations (boot time, for example). Add the possibility
to use the "fast authentication" method where the image and CSF are both
signed using the SRK [1, p.63].
Simplify code and conform to the style guide used in the project by
making the following changes:
* Capitalize global constants
* Use single quotes for multiline strings (except docstrings)
* Fix line width to 79 cols
* Use f-string instead of formatting a regular string or using a
complicated concatenation
* Move common suffix used in keys to a global variable "KEY_NAME"
to reduce the likelihood of typos and making future changes
easier
Signed-off-by: Brian Ruley <brian.ruley@gehealthcare.com> Cc: Marek Vasut <marex@denx.de>
Ye Li [Sun, 6 Oct 2024 00:30:05 +0000 (08:30 +0800)]
misc: fuse: Update fuse driver
When OSCCA is enabled, FSB fuse shadow (offset 0x8000)
access is disabled for SOC. So update the driver to read fuse
from ELE API. The ELE has supported to read all shadow fuses like
FSB, reuse the table of FSB for the word index used by ELE API.
Add ELE shadow fuse read and write to current ELE fuse driver.
But when LC is OEM closed, the ELE read/write shadow fuse APIs are
forbidden. Reading from any fuse will return error. This causes
problem to u-boot which must read out some fuse no matter whatever LC.
So we have to change back to read from FSB and ELE common fuse read API.
For using ELE shadow read API for development purpose like checking
the ELE shadow fuse write result, user can set env variable
"enable_ele_shd" to y to switch it.
Reviewed-by: Peng Fan <peng.fan@nxp.com> Signed-off-by: Ye Li <ye.li@nxp.com> Signed-off-by: Peng Fan <peng.fan@nxp.com>
Ye Li [Sun, 6 Oct 2024 00:30:04 +0000 (08:30 +0800)]
misc: fuse: Fix FSB redundancy fuse word check and clear res
There is a bug when checking fuse word with redundancy fuse in FSB
table. The redundancy fuses are combined into 4 words, so we can't
directly use word index to do the check, otherwise the high 4 words
will fail to match.
And When calling ELE API, res parameter will pass to ELE API to get ELE
response value for failure. So most of usage does not initialize
this variable and print it after calling ELE API.
However, when ELE API returns failure, we can't ensure this res is
always set because there may be other failure like MU failure.
Reviewed-by: Peng Fan <peng.fan@nxp.com> Signed-off-by: Ye Li <ye.li@nxp.com> Signed-off-by: Peng Fan <peng.fan@nxp.com>
Peng Fan [Sun, 6 Oct 2024 00:30:02 +0000 (08:30 +0800)]
misc: ele_api: Update ELE read common fuse API
On iMX8ULP, the word index 1 is used to read OTP_UNIQ_ID with 4 words
data responsed. However this special index does not apply others.
So restrict the check to i.MX8ULP to avoid problem when reading from
fuse word 1 for others, such as i.MX93.
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>
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.
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.
projects / u-boot.git / log