The Clearfog devices have only one SDHC device. This is either eMMC if
it is populated on the SOM or SDHC if not. The Linux device tree assumes
the SDHC case. Detect if the device is an eMMC and fixup the device-tree
so it will be detected by Linux.
Ported from vendor repo at https://github.com/SolidRun/u-boot
Signed-off-by: Martin Rowe <martin.p.rowe@gmail.com> Reviewed-by: Stefan Roese <sr@denx.de>
Martin Rowe [Sat, 25 Mar 2023 00:02:44 +0000 (10:02 +1000)]
arm: mvebu: clearfog: Add defconfig for SPI booting
This new clearfog_spi_defconfig file is a copy of existing
clearfog_defconfig file modified to instruct build system to generate
final kwbimage for SPI booting and to store the environment in SPI.
Signed-off-by: Martin Rowe <martin.p.rowe@gmail.com> Reviewed-by: Stefan Roese <sr@denx.de>
Martin Rowe [Sat, 25 Mar 2023 00:02:43 +0000 (10:02 +1000)]
arm: mvebu: clearfog: Fix MMC detection
A388 Clearfog MMC is either SD Card or eMMC with different behaviour for
both. Setting the device to non-removable in the u-boot.dtsi allows both
to correctly detect the device.
Signed-off-by: Martin Rowe <martin.p.rowe@gmail.com> Reviewed-by: Stefan Roese <sr@denx.de>
Bryan Brattlof [Fri, 17 Mar 2023 23:37:11 +0000 (18:37 -0500)]
configs: am62ax: enable secure device configs by default
TI's security enforcing SoCs will authenticate each binary it loads by
comparing it's signature with keys etched into the SoC during the boot
up process. The am62ax family of SoCs by default will have some level of
security enforcement checking. To keep things as simple as possible,
enable the CONFIG_TI_SECURE_DEVICE options by default so all levels of
secure SoCs will work out of the box
include: environment: ti: Use .env for environment variables
Add K3 common environment variables to .env. We retain the old-style C
environment .h files to maintain compatibility with other K3 boards that
have not moved to using .env yet.
Signed-off-by: Neha Malcom Francis <n-francis@ti.com> Reviewed-by: Tom Rini <trini@konsulko.com>
Janne Grunau [Mon, 13 Mar 2023 13:54:32 +0000 (14:54 +0100)]
apple_m1_defconfig: Bump CONFIG_LMB_MAX_REGIONS to 64
Apple silicon SoCs have numerous embedded co-processors with pre-loaded
firmware. The co-processors text and data sections need to be mapped via
DART iommus controlled by the main processor. Those sections are
exported as reserved-memory. Bump CONFIG_LMB_MAX_REGIONS from 8 to 64 to
deal with the large amount of reserved-memory regions.
Signed-off-by: Janne Grunau <j@jannau.net> Reviewed-by: Mark Kettenis <kettenis@openbsd.org>
Sinthu Raja [Mon, 13 Mar 2023 12:42:24 +0000 (18:12 +0530)]
phy: ti: j721e-wiz: Add support to enable LN23 Type-C swap
The WIZ acts as a wrapper for SerDes and has Lanes 0 and 2 reserved
for USB for type-C lane swap if Lane 1 and Lane 3 are linked to the
USB PHY that is integrated into the SerDes IP. The WIZ control register
has to be configured to support this lane swap feature.
The support for swapping lanes 2 and 3 is missing and therefore
add support to configure the control register to swap between
lanes 2 and 3 if PHY type is USB.
Sinthu Raja [Mon, 13 Mar 2023 12:42:23 +0000 (18:12 +0530)]
phy: ti: j721e-wiz: Manage TypeC lane swap if typec-dir-gpios not specified
It's possible that the Type-C plug orientation on the DIR line will be
implemented through hardware design. In that situation, there won't be
an external GPIO line available, but the driver still needs to address
this since the DT won't use the typec-dir-gpios property.
Add code to handle LN10 Type-C swap if typec-dir-gpios property is not
specified in DT.
Kconfig does not support using 'select' to select a 'choice'. A choice
can be configured by either setting the choice symbol to 'y' in a
configuration file or by setting a 'default' of the choice.
In board/ti/*/Kconfig the SOC_K3_* choice is already set to 'y' in their
corresponding configs/*_defconfig file. So remove selecting it.
Signed-off-by: Neha Malcom Francis <n-francis@ti.com>
Jan Kiszka [Tue, 28 Feb 2023 18:19:23 +0000 (19:19 +0100)]
iot2050: Add support for configuring M.2 connector
The M.2 slots of the related IOT2050 variant need to be configured
according to the plugged cards. This tries to detect the card using the
M.2 configuration pins of the B-key slot. If that fails, a U-Boot
environment variable can be set to configure manually. This variable is
write-permitted also in secure boot mode as it is not able to undermine
the integrity of the booted system.
The configuration is then applied to mux the serdes and to fix up the
device tree passed to or loaded by the bootloader. The fix-ups are
coming from device tree overlays that are embedded into the firmware
image and there also integrity protected. The OS remains free to load
a device tree to which they do not apply: U-Boot will not fail to boot
in that case.
Based on original patch by Chao Zeng.
Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>
chao zeng [Tue, 28 Feb 2023 18:19:22 +0000 (19:19 +0100)]
arm: dts: iot2050: Add support for M.2 variant
Add support for the M.2 board based on the iot2050 advanced board.
The board has two m.2 connectors, one is B-keyed, the other E-keyed.
The B-key slot can connect 5G/SSD devices, and E-key can be used for
WIFI/BT devices.
This variant is covered by PG2 firmware image.
Signed-off-by: chao zeng <chao.zeng@siemens.com>
[Jan: align DT to kernel, polish wording] Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>
Jan Kiszka [Tue, 28 Feb 2023 18:19:18 +0000 (19:19 +0100)]
arm: dts: iot2050: Optionally embed OTP programming data into image
Use external blob otpcmd.bin to replace the 0xff filled OTP programming
command block to create a firmware image that provisions the OTP on
first boot. This otpcmd.bin is generated from the customer keys using
steps described in the meta-iot2050 integration layer for the device.
Based on original patch by Baocheng Su.
Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>
Jan Kiszka [Tue, 28 Feb 2023 18:19:17 +0000 (19:19 +0100)]
iot2050: Add script for signing artifacts
There are many ways to get a signed firmware for the IOT2050 devices,
namely for the parts under user-control. This script documents one way
of doing it, given a signing key. Augment the board documentation with
the required procedure around it.
Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>
Jan Kiszka [Tue, 28 Feb 2023 18:19:16 +0000 (19:19 +0100)]
tools: Add script for converting public key into device tree include
Allows to create a public key device tree dtsi for inclusion into U-Boot
SPL and proper during first build already. This can be achieved via
CONFIG_DEVICE_TREE_INCLUDES.
Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>
Jan Kiszka [Tue, 28 Feb 2023 18:19:14 +0000 (19:19 +0100)]
iot2050: Add CFG_ENV_FLAGS_LIST_STATIC
Will be needed when CONFIG_ENV_WRITEABLE_LIST is enabled. The listed
variables shall remain writable, for informational purposes - they have
to be considered untrusted because the persistent U-Boot env is not
protected.
Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>
Jan Kiszka [Tue, 28 Feb 2023 18:19:13 +0000 (19:19 +0100)]
iot2050: Add watchdog start to bootcmd
Allows run-time control over watchdog auto-start and the timeout via
setting the environment variable watchdog_timeout_ms. A value of zero
means "do not start". Use CONFIG_WATCHDOG_TIMEOUT_MSECS as initial value
and this to zero by default. Users can then enable the watchdog once the
use and OS which picks it up during boot.
Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>
Jan Kiszka [Tue, 28 Feb 2023 18:19:11 +0000 (19:19 +0100)]
iot2050: Update firmware layout
The latest version of the binary-only firmware parts come in a combined
form of FSBL and sysfw containers. This implies some layout changes to
the generated firmware image but also makes handling of artifacts much
simpler (4 files less). The env locations will not change, just the
space reserved for U-Boot will shrink from 4 to 3 MB - still plenty of
space left in practice.
Adjust configuration and documentation accordingly.
Along this change, add a new reservation for update commands of the
user-controlled OTP part. A specific userspace tool will fill it, and
the FSBL will evaluate it during boot. This reservation will use 64K of
the former sysfw section.
Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>
Su Baocheng [Tue, 28 Feb 2023 18:19:10 +0000 (19:19 +0100)]
arm: dts: iot2050: Use the auto generator nodes for fdt
Refactor according to the entry `fit: Entry containing a FIT` of
document tools/binman/README.entries.
As the generator uses the device tree name for the config description,
board_fit_config_name_match requires a small adjustment as well.
Signed-off-by: Su Baocheng <baocheng.su@siemens.com>
[Jan: re-add now required CONFIG_OF_LIST, update config matching] Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com> Reviewed-by: Simon Glass <sjg@chromium.org>
Su Baocheng [Tue, 28 Feb 2023 18:19:09 +0000 (19:19 +0100)]
board: siemens: iot2050: Split the build for PG1 and PG2
Due to different signature keys, the PG1 and the PG2 boards can no
longer use the same FSBL (tiboot3). This makes it impossible anyway to
maintaine a single flash.bin for both variants, so we can also split the
build.
A new target is added to indicates the build is for PG1 vs. PG2 boards.
Hence now the variants have separated defconfig files.
The runtime board_is_sr1() check does make no sense anymore, so remove
it and replace with build time check.
Documentation is updated accordingly. New binary artifacts are already
available via meta-iot2050.
Signed-off-by: Su Baocheng <baocheng.su@siemens.com>
[Jan: refactor config option into targets, tweak some wordings] Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>
Tom Rini [Mon, 27 Mar 2023 15:16:51 +0000 (11:16 -0400)]
Merge branch '2023-03-27-rockchip-rk3399-fixes'
- A series of minor cleanups to DISTRO_DEFAULTS and BOOTSTD so that the
rk3399 bootstd migration can be complete and functional now, and make
future migrations easier.
Tom Rini [Fri, 24 Mar 2023 20:58:15 +0000 (16:58 -0400)]
rockchip: Use BOOTSTD_DEFAULTS if not DISTRO_DEFAULTS
When we do not enable DISTRO_DEFAULTS (generally, to get distro_bootcmd)
we instea do want to imply BOOTSTD_DEFAULTS so that when using bootstd
the general distro boot functionality will still work.
Simon Glass [Fri, 24 Mar 2023 20:58:13 +0000 (16:58 -0400)]
boot: Create a common BOOT_DEFAULTS for distro and bootstd
These two features use a lot of common options. Move them into a common
CONFIG to reduce duplication.
Use 'select' for most options since these are things that boards aren't
supposed to override. For now it is not possible to disable
BOOT_DEFAULTS but we may take another look later.
Note that five options use 'imply' to match existing behaviour.
Signed-off-by: Simon Glass <sjg@chromium.org>
[trini: Rework a bit so we don't grow so many platforms unintentionally] Signed-off-by: Tom Rini <trini@konsulko.com>
Simon Glass [Fri, 24 Mar 2023 20:58:10 +0000 (16:58 -0400)]
rockchip: Drop bootstage stash in TPL and SPL for rockpro64
Unfortunately the IRAM used to stash the bootstage records in TPL
becomes inaccessible after SPL runs. Presumably this is because of ATF
taking it over.
We could move the stash to another address in SPL, before passing it to
U-Boot proper. But it seems easier to wait until we have support for
standard passage[1] which should not be too far away.
Sergiu Moga [Wed, 8 Mar 2023 14:39:53 +0000 (16:39 +0200)]
clk: at91: sam9x60: Add initial setup of UPLL and USBCK rates
In order for some of the functionalities, such as the USB clocks,
to work properly we need some clocks to be properly initialised
at the very beginning of booting.
Claudiu Beznea [Wed, 8 Mar 2023 14:39:52 +0000 (16:39 +0200)]
clk: at91: pmc: export clock setup to pmc
Clock setup was intended for setting clocks at boot time on SAMA7G5,
e.g. for root clocks like PLLs, that were used to feed IPs needed alive
in u-boot (e.g. Ethernet clock feed by a PLL). Export this functionality
to all at91 clocks as it may be necessary on other SoCs.
Sergiu Moga [Wed, 8 Mar 2023 14:39:50 +0000 (16:39 +0200)]
clk: at91: Add support for sam9x60 USB clock
Implement sam9x60 USB clock driver. This clock has
three parents: PLLA, UPLL and MAINXTAL. The driver is
aware of the three possible parents with the help of the
two mux tables provied to the driver during the registration
of the clock.
* Let EFI app call ExitBootServices() before legacy booting kernel
* Support zboot and bootm in the EFI app
* Let efi command show configuration tables
* Support booting a 64-bit kernel from 64-bit EFI app
* Allocate device-tree copy from high memory
* simplify efi_str_to_u16()
cmd: bootefi: allocate device-tree copy from high memory
The bootefi command creates a copy of the device-tree within the first
127 MiB of memory. This may lead to overwriting previously loaded binaries
(e.g. kernel, initrd).
Linux EFI stub itself copies U-Boot's copy of the device-tree. This means
there is not restriction for U-Boot to place the device-tree copy to any
address. (Restrictions existed for 32bit ARM before Linux commit 7a1be318f579 ("ARM: 9012/1: move device tree mapping out of linear region")
for legacy booting.
Simon Glass [Sun, 19 Mar 2023 19:30:15 +0000 (08:30 +1300)]
efi: Support showing tables
Add a command (for the app and payload) to display the tables provided
by EFI. Note that for the payload the tables should always be present, so
an error message is unnecessary and would bloat the code.
Simon Glass [Sun, 19 Mar 2023 19:30:12 +0000 (08:30 +1300)]
efi: Include GUID names with EFI app and payload
These are currently only available when running with EFI_LOADER.
Expand this to include the app and payload, since it is useful to be
able to decode things there.
Simon Glass [Sun, 19 Mar 2023 19:30:05 +0000 (08:30 +1300)]
efi: Set RUN_64BIT correctly for the EFI app
The U-Boot EFI app can run as a 64-bit program, so set the Kconfig
correctly in that case. Make sure it doesn't build SPL, since there is
no need to switch from 32 to 64 bit when running.
EFI device paths for block devices must be unique. If a non-unique device
path is discovered, probing of the block device fails.
Currently we use UsbClass() device path nodes. As multiple devices may
have the same vendor and product id these are non-unique. Instead we
should use Usb() device path nodes. They include the USB port on the
parent hub. Hence they are unique.
A USB storage device may contain multiple logical units. These can be
modeled as Ctrl() nodes.
Reported-by: Patrick Delaunay <patrick.delaunay@foss.st.com> Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com> Reviewed-by: Simon Glass <sjg@chromium.org>
EFI device paths for block devices must be unique. If a non-unique device
path is discovered, probing of the block device fails.
Currently we use UsbClass() device path nodes. As multiple devices may
have the same vendor and product id these are non-unique. Instead we
should use Usb() device path nodes. They include the USB port on the
parent hub. Hence they are unique.
A USB storage device may contain multiple logical units. These can be
modeled as Ctrl() nodes.
Reported-by: Patrick Delaunay <patrick.delaunay@foss.st.com> Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com> Reviewed-by: Simon Glass <sjg@chromium.org>
Tom Rini [Fri, 24 Mar 2023 21:00:41 +0000 (17:00 -0400)]
Merge branch 'rpi-2023.04' of https://source.denx.de/u-boot/custodians/u-boot-raspberrypi
- Fixes for booting newer revs of the SoC in the Raspberry Pi 4
- Propagate some firmware DT properties to the loaded DT
- Update the Zero2W upstream DT name
Due to this change in firmware behavior, bcm2835_get_mmc_clock now
returns a clock rate of zero since we do not issue SET_CLOCK_RATE.
This results in degraded MMC performance.
SET_CLOCK_RATE fixes the clock to a specific value and disables scaling
so is not an ideal solution.
Instead, fallback to GET_MAX_CLOCK_RATE in bcm2835_get_mmc_clock if
GET_CLOCK_RATE returns zero.
Signed-off-by: Vincent Fazio <vfazio@xes-inc.com> Signed-off-by: Peter Robinson <pbrobinson@gmail.com>
Pali Rohár [Thu, 23 Mar 2023 19:57:55 +0000 (20:57 +0100)]
tools: kwboot: Workaround A38x BootROM bug for images with a gap
A38x BootROM has a bug which cause that BootROM loads data part of UART
image into RAM target address increased by one byte when source address
and header size stored in the image header are not same.
Workaround this bug by completely removing a gap between header and data
part of the UART image. Without gap, this BootROM bug is not triggered.
This gap can be present in SDIO or SATA image types which have aligned
start of the data part to the media sector size. With this workaround
kwboot should be able to convert and send SDIO or SATA images for UART
booting.
Signed-off-by: Pali Rohár <pali@kernel.org> Reviewed-by: Stefan Roese <sr@denx.de>
Pali Rohár [Thu, 23 Mar 2023 19:57:54 +0000 (20:57 +0100)]
tools: kwboot: Fix sending very small images
Sending of very small images (smaller than 128 bytes = xmodem block size)
cause out-of-bound memory read access. Fix this issue by ensuring that
hdrsz when sending image is not larger than total size of the image.
Issue was introduced in commit f8017c37799c ("tools: kwboot: Fix sending
Kirkwood v0 images"). Special case when total image is smaller than header
size aligned to multiply of xmodem size is already handled since that
commit.
Pali Rohár [Thu, 23 Mar 2023 19:57:53 +0000 (20:57 +0100)]
tools: kwboot: Fix inserting UART data checksum without -B option
Commit 7665ed2fa04e ("tools: kwboot: Fix parsing UART image without data
checksum") added fixup code to insert place for data checksum if UART image
does not have it. Together with option -B (change baudrate), kwboot
calculates this checksum. Without option -B, it inserts only place for
checksum but does not calculate it.
This commit fix above logic and calculate data checksum also when kwboot is
used without -B option.
Fixes: 7665ed2fa04e ("tools: kwboot: Fix parsing UART image without data checksum") Signed-off-by: Pali Rohár <pali@kernel.org> Reviewed-by: Stefan Roese <sr@denx.de>
Ensure that UART aligned header size is always stored into kwbimage v1
header. It is needed for proper UART booting. Calculation of headersz field
was broken in commit d656f5a0ee22 ("tools: kwboot: Calculate real used
space in kwbimage header when calling kwboot_img_grow_hdr()") which
introduced optimization of kwboot_img_grow_hdr() function.
Fixes: d656f5a0ee22 ("tools: kwboot: Calculate real used space in kwbimage header when calling kwboot_img_grow_hdr()") Signed-off-by: Pali Rohár <pali@kernel.org> Reviewed-by: Stefan Roese <sr@denx.de>
Armada 385 BootROM ignores low 7 bits of headersz when parsing kwbimage
header of UART type, which effectively means that headersz is rounded down
to multiply of 128 bytes. For all other image types BootROM reads and use
all bits of headersz. Therefore fill into UART type of kwbimage v1 headersz
aligned to 128 bytes.
Fixes: 2b0980c24027 ("tools: kwbimage: Fill the real header size into the main header") Signed-off-by: Pali Rohár <pali@kernel.org> Reviewed-by: Stefan Roese <sr@denx.de>
Tony Dinh [Fri, 3 Mar 2023 03:27:29 +0000 (19:27 -0800)]
arm: mvebu: Set common SPI flash default speed and mode
CONFIG_SF_DEFAULT_SPEED is used in SPL SPI to configure and probe the
flash device during DM SPI uclass probing process, if the
spi-max-frequency is not available in the DTB. Currently the max
frequency is not available, because of the probing mechanism in SPI
uclass has not been fully updated to DM.
The CONFIG_SF_DEFAULT_SPEED is set to 1Mhz if a board defconfig
does not specify it. This speed is too slow and result in a few
seconds delay while the u-boot image is loaded from flash. Based on a
survey of the device tree specifications for MVEBU boards, a sane default
value should be 10Mhz. The default of 10Mhz enables an almost
instantaneously loading of the u-boot image.
Note that this patch depends on this patch series (has been merged to
u-boot-marvell/next):
https://lists.denx.de/pipermail/u-boot/2023-March/511038.html
- RESEND: correct spelling of SF_DEFAULT_MODE
Signed-off-by: Tony Dinh <mibodhi@gmail.com> Reviewed-by: Stefan Roese <sr@denx.de>
Tom Rini [Thu, 9 Mar 2023 16:22:11 +0000 (11:22 -0500)]
purism: librem5: Fix a function declaration in spl.c
Here we implement usb_gadget_handle_interrupts() but did not include
<linux/usb/gadget.h> so did not have the declaration correct. Fix this
and add the missing include.
projects / u-boot.git / log
