| Age | Commit message (Collapse) | Author |
|---|
|
Implement digest shim layer on top of MbedTLS crypto library.
Introduce <alg>_MBEDTLS kconfig for MbedTLS crypto implementations.
Signed-off-by: Raymond Mao <[email protected]>
|
|
We don't need an API specially for non-watchdog since sha1_csum_wd
supports it by disabling CONFIG_HW_WATCHDOG and CONFIG_WATCHDOG.
Set 0x10000 as default chunk size for SHA1.
Signed-off-by: Raymond Mao <[email protected]>
Reviewed-by: Ilias Apalodimas <[email protected]>
|
|
We don't need an API specially for non-watchdog since md5_wd supports
it by disabling CONFIG_HW_WATCHDOG and CONFIG_WATCHDOG.
Set 0x10000 as default chunk size for MD5.
Signed-off-by: Raymond Mao <[email protected]>
Reviewed-by: Ilias Apalodimas <[email protected]>
Reviewed-by: Michal Simek <[email protected]>
|
|
Adapt digest header files to support both original libs and MbedTLS
by switching on/off MBEDTLS_LIB_CRYPTO.
Introduce <alg>_LEGACY kconfig for legacy hash implementations.
sha256.o should depend on SHA256 kconfig only but not SUPPORT_EMMC_RPMB,
SHA256 should be selected when SUPPORT_EMMC_RPMB is enabled instead.
`IS_ENABLED` or `CONFIG_IS_ENABLED` is not applicable here, since
including <linux/kconfig.h> causes undefined reference on schedule()
with sandbox build, as <linux/kconfig.h> includes <generated/autoconf.h>
which enables `CONFIG_HW_WATCHDOG` and `CONFIG_WATCHDOG` but no schedule()
are defined in sandbox build,
Thus we use `#if defined(CONFIG_MBEDTLS_LIB_CRYPTO)` instead.
Signed-off-by: Raymond Mao <[email protected]>
Reviewed-by: Ilias Apalodimas <[email protected]>
|
|
Port mbedtls with adapted libc header files.
Add mbedtls default config header file.
Optimize mbedtls default config by disabling unused features to
reduce the target size.
Add mbedtls kbuild makefile.
Add Kconfig skeleton and config submenu entry for selecting
crypto libraries between mbedtls and legacy ones.
Add the mbedtls include directories into the build system.
Port u-boot hash functions as MbedTLS crypto alternatives and set
it as default.
Subsequent patches will separate those Kconfigs into pairs of
_LEGACY and _MBEDTLS for controlling the implementations of legacy
crypto libraries and MbedTLS ones respectively.
The motivation of moving and adapting *INT* macros from kernel.h
to limits.h is to fulfill the MbedTLS building requirement.
The conditional compilation statements in MbedTLS expects the
*INT* macros as constant expressions, thus expressions like
`((int)(~0U >> 1))` will not work.
Prerequisite
------------
This patch series requires mbedtls git repo to be added as a
subtree to the main U-Boot repo via:
$ git subtree add --prefix lib/mbedtls/external/mbedtls \
https://github.com/Mbed-TLS/mbedtls.git \
v3.6.0 --squash
Moreover, due to the Windows-style files from mbedtls git repo,
we need to convert the CRLF endings to LF and do a commit manually:
$ git add --renormalize .
$ git commit
Signed-off-by: Raymond Mao <[email protected]>
|
|
Right now xhci header file defines XHCI_MAX_HALT_USEC macro
twice. Fix the same.
Cc: Bin Meng <[email protected]>
Signed-off-by: Bhupesh Sharma <[email protected]>
Reviewed-by: Marek Vasut <[email protected]>
|
|
https://source.denx.de/u-boot/custodians/u-boot-amlogic
- Add Libre Computer boards into proper libre-computer board directory
- Add new Boards:
- Libre Computer aml-s905d3-cc
- Libre Computer aml-a311d-cc
- Add capsule update to libretech-ac and the new boards since they have an onboard SPI nor flash
- Fix HDMI support after sync to v6.11 and regulator enable from Marek
- Fix khadas-vim3 android config for android-mainline kernel
- Disable meson64 boot targets when configs are not eavailable
|
|
When populating BOOT_TARGET_DEVICES on Amlogic Meson platforms, verify
that the shell commands for accessing the relevant media have been
enabled in the build configuration.
This was already being done for USB, NVME and SCSI devices, but not
for MMC devices or network boot. This meant that configuring U-Boot
without the networking or MMC subsystems/drivers would cause an error
to be thrown during preprocessing.
Signed-off-by: Callum Parsey <[email protected]>
Reviewed-by: Neil Armstrong <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Neil Armstrong <[email protected]>
|
|
The device tree overlays are not part of the
Android Common Kernel code [1]
Historically, they existed to enable some Android specific
features but they have been removed.
Remove the dtbos logic since these files do no longer exist.
[1] https://android.googlesource.com/kernel/common/+/ac2ea0bb91a3b5f5e71eba66c441e58beca6767e/arch/arm64/boot/dts/amlogic/
Signed-off-by: Mattijs Korpershoek <[email protected]>
Reviewed-by: Guillaume La Roque <[email protected]>
Reviewed-by: Neil Armstrong <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Neil Armstrong <[email protected]>
|
|
The Android Common Kernel is over 34MiB now [1]. This does not
include any kernel modules nor the Android ramdisk.
To make sure we are future proof, increase both recovery
and boot partitions to 64 MiB.
[1] https://source.android.com/docs/core/architecture/kernel/gki-android15-6_6-release-builds
Signed-off-by: Mattijs Korpershoek <[email protected]>
Reviewed-by: Guillaume La Roque <[email protected]>
Reviewed-by: Neil Armstrong <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Neil Armstrong <[email protected]>
|
|
This switches all boards with the Allwinner H616/H618/H313/H700 SoCs over to
use OF_UPSTREAM. We are doing it for this SoC family only since the DTs
between the U-Boot and the kernel repo are exactly identical, whereas other
families have one compatibility fix in U-Boot to allow booting older kernels.
Other will follow if this plays out well.
The biggest chunk otherwise is adding support for an Anbernic game console,
using the H700 SoC. For that we need to enhance the DRAM support code, and
pick two DT commits from the mainline kernel/DT rebasing repo, followed
by the defconfig patch.
On top of that two small fixes for the old Allwinner A80.
Gitlab CI passed, and I booted that briefly on some boards, including an
H616 and an H618 one (with LPDDR4).
|
|
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.
Signed-off-by: Tom Rini <[email protected]>
|
|
In some cases access to GPIOs is needed so early that DM
is not ready even nearly. These functions are exactly for
this case.
Signed-off-by: Svyatoslav Ryhel <[email protected]>
|
|
Convert boards to use text based env. This is the first stage of
conversion, common inclusions should be converted next.
Acked-by: Francesco Dolcini <[email protected]> # Toradex Apalis TK1
Reviewed-by: Simon Glass <[email protected]>
Signed-off-by: Svyatoslav Ryhel <[email protected]>
|
|
Simon Glass <[email protected]> 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:
#if defined(CONFIG_SPL_BUILD) && !defined(CONFIG_TPL_BUILD)
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.
|
|
Rename these to use the word PHASE instead.
Signed-off-by: Simon Glass <[email protected]>
|
|
Now that SPL means SPL (only) and is not defined for other phases,
update kconfig rules.
This is done in one patch since otherwise many Binman tests fail.
Signed-off-by: Simon Glass <[email protected]>
|
|
Use the new symbol to refer to any 'SPL' build, including TPL and VPL
Signed-off-by: Simon Glass <[email protected]>
|
|
This should now refer to xPL rather than SPL, so update it throughout
the tree.
Signed-off-by: Simon Glass <[email protected]>
|
|
Use simpler names for these functions.
Signed-off-by: Simon Glass <[email protected]>
|
|
Rename this to use the xpl prefix.
Signed-off-by: Simon Glass <[email protected]>
|
|
Add the opposite function to not_xpl() for completeness.
Signed-off-by: Simon Glass <[email protected]>
|
|
Give this function a slightly easier name.
Signed-off-by: Simon Glass <[email protected]>
|
|
Rename this function to indicate that it refers to any xPL phase.
Signed-off-by: Simon Glass <[email protected]>
|
|
This name fits better with the new naming scheme, so update it.
Signed-off-by: Simon Glass <[email protected]>
|
|
This is a better name for this function, so update it.
Tidy up the function comment to mention VPL.
Signed-off-by: Simon Glass <[email protected]>
|
|
This is always enabled for U-Boot proper, so simplify the condition
in the common Makefile.
Signed-off-by: Simon Glass <[email protected]>
Reviewed-by: Tom Rini <[email protected]>
|
|
Christian Marangi <[email protected]> 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.
|
|
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 <[email protected]>
Reviewed-by: Simon Glass <[email protected]>
|
|
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 <[email protected]>
Reviewed-by: Simon Glass <[email protected]>
|
|
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 <[email protected]>
Reviewed-by: Simon Glass <[email protected]>
|
|
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 <[email protected]>
Reviewed-by: Simon Glass <[email protected]>
|
|
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 <[email protected]>
Reviewed-by: Simon Glass <[email protected]>
|
|
Add PCA9452 PMIC/Regulator support.
Signed-off-by: Joy Zou <[email protected]>
Reviewed-by: Ye Li <[email protected]>
Signed-off-by: Peng Fan <[email protected]>
|
|
The MP5416 PMIC's LDO set-value formula is incorrect. This patch fixes
it by using the correct formula.
Signed-off-by: Sidharth Prabukumar <[email protected]>
Cc: Jaehoon Chung <[email protected]>
Reviewed-by: Jaehoon Chung <[email protected]>
|
|
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 <[email protected]>
|
|
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 <[email protected]>
Signed-off-by: Heinrich Schuchardt <[email protected]>
|
|
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 <[email protected]>
|
|
Venkatesh Yadav Abbarapu <[email protected]> says:
This series adds support for Xilinx qspi parallel and
stacked memeories.
In parallel mode, the current implementation assumes that a maximum
of two flashes are connected. The QSPI controller splits the data
evenly between both the flashes so, both the flashes that are connected
in parallel mode should be identical.
During each operation SPI-NOR sets 0th bit for CS0 & 1st bit for CS1 in
nor->flags.
In stacked mode the current implementation assumes that a maximum of two
flashes are connected and both the flashes are of same make but can differ
in sizes. So, except the sizes all other flash parameters of both the flashes
are identical.
Spi-nor will pass on the appropriate flash select flag to low level driver,
and it will select pass all the data to that particular flash.
Write operation in parallel mode are performed in page size * 2 chunks as
each write operation results in writing both the flashes. For doubling the
address space each operation is performed at addr/2 flash offset, where addr
is the address specified by the user.
Similarly for read and erase operations it will read from both flashes, so
size and offset are divided by 2 and send to flash.
|
|
Add support for parallel memories in zynqmp_gqspi.c driver. In case of
parallel memories STRIPE bit is set and sent to the qspi ip, which will
send data bits to both the flashes in parallel. However for few commands
we should not use stripe, instead send same data to both the flashes.
Those commands are exclueded by using zynqmp_qspi_update_stripe().
Also update copyright info for this file.
Signed-off-by: Ashok Reddy Soma <[email protected]>
Signed-off-by: Venkatesh Yadav Abbarapu <[email protected]>
|
|
Read chipselect properties from DT which are populated using 'reg'
property and save it in plat->cs[] array for later use.
Also read multi chipselect capability which is used for
parallel-memories and return errors if they are passed on using DT but
driver is not capable of handling it.
Signed-off-by: Ashok Reddy Soma <[email protected]>
Signed-off-by: Venkatesh Yadav Abbarapu <[email protected]>
|
|
In parallel mode, the current implementation assumes that a maximum of
two flashes are connected. The QSPI controller splits the data evenly
between both the flashes so, both the flashes that are connected in
parallel mode should be identical.
During each operation SPI-NOR sets 0th bit for CS0 & 1st bit for CS1 in
nor->flags.
In stacked mode the current implementation assumes that a maximum of two
flashes are connected and both the flashes are of same make but can
differ in sizes. So, except the sizes all other flash parameters of both
the flashes are identical
Spi-nor will pass on the appropriate flash select flag to low level
driver, and it will select pass all the data to that particular flash.
Write operation in parallel mode are performed in page size * 2 chunks as
each write operation results in writing both the flashes. For doubling
the address space each operation is performed at addr/2 flash offset,
where addr is the address specified by the user.
Similarly for read and erase operations it will read from both flashes,
so size and offset are divided by 2 and send to flash.
Adding the config option SPI_ADVANCE for non SPL code.
Signed-off-by: Ashok Reddy Soma <[email protected]>
Signed-off-by: Venkatesh Yadav Abbarapu <[email protected]>
|
|
|
|
When supporting partition reset for SoC such as i.MX95 , the Linux
Kernel may have configured the tuning, while after force reset by
wdog or else, uboot CMD0 will never pass unless config RSTT to reset
tuning logic.
Since RSTA and RSTT are independent, so need both to be reseted in the
controller.
Acked-by: Haibo Chen <[email protected]>
Signed-off-by: Peng Fan <[email protected]>
|
|
https://source.denx.de/u-boot/custodians/u-boot-dfu into next
u-boot-dfu-next-20241003
CI: https://source.denx.de/u-boot/custodians/u-boot-dfu/-/pipelines/22516
DFU:
- Reinitialize only if dfu_alt_info changed
USB Gadget:
- New usb gadget driver for Renesas USBHS
- Simplify kconfig deps for CMD_USB_MASS_STORAGE
Android:
- Provide bootloader version to android via kernel commandline
|
|
Simon Glass <[email protected]> says:
This includes various patches towards implementing the VBE abrec
bootmeth in U-Boot.
|
|
This doesn't describe the length parameter correctly. Fix it and
zunzip() too.
Signed-off-by: Simon Glass <[email protected]>
|
|
When bootstd is not enabled, bootdevs should not be set up. Add a
static inline function to see to this.
Signed-off-by: Simon Glass <[email protected]>
|
|
Oliver Gaskell <[email protected]> says:
ADSP-SC5xx is a series of ARM-based DSPs.
This comprises the armv7 based SC57x, SC58x and SC594 series, and the
armv8 based SC598.
This patch series includes configurations, init code, and minimal DTs
to enable Analog Devices' evaluation boards for these SoCs to boot
through SPL and into U-Boot Proper, as well as devicetree schemas for
the added DTs.
This patch series depends on ("arm: Add Analog Devices SC5xx Machine
Type") (https://lists.denx.de/pipermail/u-boot/2024-April/552043.html)
|
|
Adds support for Analog Devices' SC573-EZKIT board. Includes:
- SoC specific configs in mach-sc5xx/Kconfig
- Memory Map for SPL
- Necessary board-specific init functions
- Board-specific Kconfig and environment in board/adi/
- Memory configuration
Co-developed-by: Greg Malysa <[email protected]>
Signed-off-by: Greg Malysa <[email protected]>
Co-developed-by: Nathan Barrett-Morrison <[email protected]>
Signed-off-by: Nathan Barrett-Morrison <[email protected]>
Signed-off-by: Oliver Gaskell <[email protected]>
|
