| Age | Commit message (Collapse) | Author |
|---|
|
Enable LED_BOOT to use led_boot_on/off() API in board file.
Signed-off-by: Patrice Chotard <[email protected]>
Reviewed-by: Quentin Schulz <[email protected]>
|
|
Enable LED_BOOT to use led_boot_on/off() API in board file.
Signed-off-by: Patrice Chotard <[email protected]>
Reviewed-by: Quentin Schulz <[email protected]>
|
|
Enable LED_BOOT to use led_boot_on/off() API in board file.
Signed-off-by: Patrice Chotard <[email protected]>
Reviewed-by: Quentin Schulz <[email protected]>
|
|
Enable LED, LED_BOOT and LED_GPIO flags.
Signed-off-by: Patrice Chotard <[email protected]>
Reviewed-by: Quentin Schulz <[email protected]>
|
|
Enable LED, LED_BOOT and LED_GPIO flags.
Signed-off-by: Patrice Chotard <[email protected]>
Reviewed-by: Quentin Schulz <[email protected]>
|
|
Enable LED, LED_BOOT and LED_GPIO flags.
Signed-off-by: Patrice Chotard <[email protected]>
Reviewed-by: Quentin Schulz <[email protected]>
|
|
Enable LED, LED_BOOT and LED_GPIO flags.
Signed-off-by: Patrice Chotard <[email protected]>
Reviewed-by: Quentin Schulz <[email protected]>
|
|
Enable LED, LED_BOOT and LED_GPIO flags.
Signed-off-by: Patrice Chotard <[email protected]>
Reviewed-by: Quentin Schulz <[email protected]>
|
|
Enable LED, LED_BOOT and LED_GPIO flags.
Signed-off-by: Patrice Chotard <[email protected]>
Reviewed-by: Quentin Schulz <[email protected]>
|
|
Enable LED, LED_BOOT and LED_GPIO flags.
Signed-off-by: Patrice Chotard <[email protected]>
Reviewed-by: Quentin Schulz <[email protected]>
|
|
Remove get_led() and setup_led() which became obsolete since
led_boot_on() introduction. led_boot_on() is automatically called
from board_r.c
Signed-off-by: Patrice Chotard <[email protected]>
Reviewed-by: Quentin Schulz <[email protected]>
|
|
Remove get_led() and setup_led() which became obsolete since
led_boot_on() introduction. led_boot_on() is automatically called
from board_r.c
Regarding "u-boot,error-led" property can't be used anymore since commit
Since commit 516a13e8db32 ("led: update LED boot/activity to new property implementation")
Instead get the LED labeled "red:status".
See kernel series: https://patchwork.kernel.org/project/linux-arm-kernel/list/?series=1022570
Signed-off-by: Patrice Chotard <[email protected]>
|
|
This predates the LED framework, so drop it.
Signed-off-by: Simon Glass <[email protected]>
Signed-off-by: Patrice Chotard <[email protected]>
Reviewed-by: Quentin Schulz <[email protected]>
|
|
Commit c37a6684818d ("stm32mp: fix compilation issue with DEBUG_UART")
split the debug UART initialization code into two files, but failed to
update other non-ST boards. This did not lead to noticeable breakage
until debug UART is enabled, which is not the default. Update the
Makefile accordingly to allow debug UART to work.
Fixes: c37a6684818d ("stm32mp: fix compilation issue with DEBUG_UART")
Signed-off-by: Marek Vasut <[email protected]>
Reviewed-by: Patrice Chotard <[email protected]>
|
|
Add DRAM settings for 1 GiB variant of DH STM32MP13xx DHCOR SoM
and support for SoM DRAM coding HW straps decoding and automatic
DRAM configuration selection. Enable CONFIG_BOARD_EARLY_INIT_F on
all STM32MP1 DHSOM, as it is required for the HW straps decoding.
Signed-off-by: Marek Vasut <[email protected]>
Reviewed-by: Patrice Chotard <[email protected]>
|
|
Update DRAM chip type and density comment for 512 MiB DRAM settings for
DH STM32MP13xx DHCOR DHSBC to match the chip on the SoM. No functional
change.
Signed-off-by: Marek Vasut <[email protected]>
Reviewed-by: Patrice Chotard <[email protected]>
|
|
STM32MP13xx may have OPTEE-OS at 0xdd000000 even on systems with 1 GiB
of DRAM at 0xc0000000, which is not the end of DRAM anymore. This puts
the OPTEE-OS in the middle of DRAM. Currently, the code sets RAM top to
0xdd000000 and prevents the DRAM range past OPTEE at 0xe0000000..0xffffffff
from being set as cacheable and from being usable. The code also sets the
area over OPTEE as invalid region in MMU tables, which is not correct.
Adjust the code such, that it only ever sets RAM top just before OPTEE
in case the OPTEE is really at the end of DRAM, mainly to be backward
compatible. Furthermore, adjust the MMU table configuration such, that
the regions over the OPTEE are simply skipped and not reconfigured, and
the regions between end of OPTEE and RAM top are set as cacheable, if
any actually exist.
Signed-off-by: Marek Vasut <[email protected]>
Reviewed-by: Patrice Chotard <[email protected]>
Tested-by: Patrice Chotard <[email protected]>
|
|
Remove setting of fdt_high to ~0, which disables device tree relocation,
from the default environment. Doing so prevents U-Boot from correcting
problems such as having an unaligned device tree and leads to various
failure modes in the OS.
Signed-off-by: Tom Rini <[email protected]>
|
|
Remove setting of fdt_high to ~0, which disables device tree relocation,
from the default environment. Doing so prevents U-Boot from correcting
problems such as having an unaligned device tree and leads to various
failure modes in the OS.
Signed-off-by: Tom Rini <[email protected]>
|
|
Remove setting of fdt_high to ~0, which disables device tree relocation,
from the default environment. Doing so prevents U-Boot from correcting
problems such as having an unaligned device tree and leads to various
failure modes in the OS.
Signed-off-by: Tom Rini <[email protected]>
|
|
Remove setting of fdt_high to ~0, which disables device tree relocation,
from the default environment. Doing so prevents U-Boot from correcting
problems such as having an unaligned device tree and leads to various
failure modes in the OS.
Signed-off-by: Tom Rini <[email protected]>
|
|
Remove setting of fdt_high to ~0, which disables device tree relocation,
from the default environment. Doing so prevents U-Boot from correcting
problems such as having an unaligned device tree and leads to various
failure modes in the OS.
Signed-off-by: Tom Rini <[email protected]>
|
|
Remove setting of fdt_high to ~0, which disables device tree relocation,
from the default environment. Doing so prevents U-Boot from correcting
problems such as having an unaligned device tree and leads to various
failure modes in the OS. However, this platform also has a large comment
block that explains that given previous stage loaders and other parts of
the memory map (that may not be in the device tree we see?), adjust this
to use bootm_size to restrict relocation to be below the CMA area and
update the comment to match.
Signed-off-by: Tom Rini <[email protected]>
|
|
Remove setting of fdt_high to ~0, which disables device tree relocation,
from the default environment. Doing so prevents U-Boot from correcting
problems such as having an unaligned device tree and leads to various
failure modes in the OS.
Reviewed-by: Heiko Schocher <[email protected]>
Signed-off-by: Tom Rini <[email protected]>
|
|
Remove setting of fdt_high to ~0, which disables device tree relocation,
from the default environment. Doing so prevents U-Boot from correcting
problems such as having an unaligned device tree and leads to various
failure modes in the OS.
Signed-off-by: Tom Rini <[email protected]>
|
|
When this platform was removed the config header file was missed. Remove
that now.
Fixes: ddfc00400965 ("arm: Remove xpress board")
Signed-off-by: Tom Rini <[email protected]>
|
|
When these platforms were removed the common config header file was
missed. Remove that now.
Fixes: a0cacddcafe5 ("arm: Remove zc5202 and zc5601 boards")
Signed-off-by: Tom Rini <[email protected]>
|
|
Remove setting of fdt_high to ~0, which disables device tree relocation,
from the default environment. Doing so prevents U-Boot from correcting
problems such as having an unaligned device tree and leads to various
failure modes in the OS.
Tested-by: Greg Malysa <[email protected]>
Signed-off-by: Tom Rini <[email protected]>
|
|
With the changes in commit 8fbcc0e0e839 ("boot: Assure FDT is always at
8-byte aligned address") to call memalign(...) we now always call
memalign(...) rather than malloc(...) when allocating a buffer that may
contain a device tree. However, memalign(...) is not portable among all
of the host OSes we support. The C11 standard does require that
aligned_alloc(...) exist and it takes the same parameters as
memalign(...) does. Change this file to call aligned_alloc rather than
memalign, and for the non-USE_HOSTCC case define that function back to
memalign.
Fixes: 8fbcc0e0e839 ("boot: Assure FDT is always at 8-byte aligned address")
Suggested-by: Heinrich Schuchardt <[email protected]>
Signed-off-by: Tom Rini <[email protected]>
|
|
Unfortunately I don't really have time to review clock patches. When I
initially started maintaining this subsystem I had more free time than I do
now. But I also found it hard to motivate myself to review patches. Many
clock patches add support for new SoCs and they are time consuming to
review properly. You effectively have to spend a few hours reading the
reference manual (if it's public!) and reviewing drivers is no small feat
either. This is made more difficult since clocking is often very different
between SoCs and it can be difficult to determine whether something is a
bug in the driver or a workaround for some hardware behavior. I mostly
don't care about any given SoC unless I'm hacking on it so I ended up with
a ton (more than 7000) of unreviewed patches piling up in my inbox. I'd
love to be more active, but I have a day job and I usually want to work on
something more interesting when I get home. I still think the clock
subsystem is a major mess but I don't care enough to fix it :l
The subsystem itself should probably get orphaned since AFAICT all patches
go through the mach/arch maintainer or to Tom.
Signed-off-by: Sean Anderson <[email protected]>
|
|
When I modified this code I meant to accept the LGPL offer to convert the
license to GPL. However, while there is an LGPL 2.1, the next version of
the GPL after 2.0 is 3.0. Fix the license version
Fixess: c4ac52f55d9 ("test: Add test for strlcat")
Signed-off-by: Sean Anderson <[email protected]>
|
|
Python 3.7 and 3.8 lack the files attribute in importlib.resources.
Use importlib_resources to fix build errors with Python 3.8:
binman: module 'importlib.resources' has no attribute 'files'
Fixes: 538719cb6a77 ("binman: migrate from pkg_resources to importlib")
Signed-off-by: Chukun Pan <[email protected]>
Acked-by: Quentin Schulz <[email protected]>
[trini: Re-add # pragma: no cover line]
Signed-off-by: Tom Rini <[email protected]>
|
|
The MAINTAINERS files for B&R boards are not in sync
with the current file names. Update the files so
that they are correct again.
Signed-off-by: Wolfgang Wallner <[email protected]>
|
|
B&R Industrial Automation has been acquired by ABB in 2017, and this
will be reflected in our email addresses beginning from December 2025.
The email addresses change as follows:
@br-automation.com -> @<country-code>.abb.com
The existing email addresses will be valid until December 2026.
Add entries for Bernhard Messerklinger and myself to .mailmap, and
update the MAINTAINERS files.
Signed-off-by: Wolfgang Wallner <[email protected]>
Signed-off-by: Wolfgang Wallner <[email protected]>
|
|
The current implementation of clk_set_parent() unconditionally enables
the new parent clock, even if the target clock was not previously enabled.
To avoid this implicit behavior, this patch adds a check for whether
the target clock has been enabled before parent enabling..
Fixes: ac30d90f336 ("clk: Ensure the parent clocks are enabled while reparenting")
Signed-off-by: Maksim Kiselev <[email protected]>
Reviewed-by: Miquel Raynal <[email protected]>
|
|
Heiko Schocher <[email protected]> says:
Add SM3 secure hash, as specified by OSCCA GM/T 0004-2012 SM3 and described
at https://datatracker.ietf.org/doc/html/draft-sca-cfrg-sm3-02
TPMv2 defines hash algo sm3_256, which is currently
not supported and prevented TPMv2 chip with newer
firmware to work with U-Boot. Seen this on a ST33TPHF2XI2C
u-boot=> tpm2 init
u-boot=> tpm2 autostart
tpm2_get_pcr_info: too many pcrs: 5
Error: -90
u-boot=>
Implement sm3 hash, so we can fix this problem.
Link: https://lore.kernel.org/r/[email protected]
|
|
In dm_test_cmd_hash_md5 accidentially sha256 hash
ist used. Use the correct md5 hash instead.
Signed-off-by: Heiko Schocher <[email protected]>
Reviewed-by: Heinrich Schuchardt <[email protected]>
Reviewed-by: Ilias Apalodimas <[email protected]>
|
|
add sm3 256 hash support, so TPM2 chips which report
5 pcrs with sm3 hash do not fail with:
u-boot=> tpm2 autostart
tpm2_get_pcr_info: too many pcrs: 5
Error: -90
Signed-off-by: Heiko Schocher <[email protected]>
|
|
add simple test for sm3 256 hash
Signed-off-by: Heiko Schocher <[email protected]>
|
|
add the U-Boot specific parts for the SM3 hash
implementation:
Signed-off-by: Heiko Schocher <[email protected]>
|
|
Implement SM3_256 Hash algorithm, based on
linux commit f83a4f2a4d8c: ("Merge tag 'erofs-for-6.17-rc6-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/xiang/erofs")
Therefore add the needed parts from linux.
Signed-off-by: Heiko Schocher <[email protected]>
Acked-by: Ilias Apalodimas <[email protected]>
|
|
sm3 crypto algorithm uses rol32 function from linux, so
import it. Linux base was:
commit ca91b9500108:("Merge tag 'v6.15-rc4-ksmbd-server-fixes' of git://git.samba.org/ksmbd")
Signed-off-by: Heiko Schocher <[email protected]>
Reviewed-by: Ilias Apalodimas <[email protected]>
|
|
Andrew Goodbody <[email protected]> says:
The function clk_get_rate() returns a ulong with 0 meaning an invalid
clock rate and also negative error codes being returned for other
errors. But being an unsigned return value this cannot simply be tested
for with a < 0 test. Instead use the IS_ERR_VALUE() macro to check for
negative errors appearing as very large positive values. Fix those
places that test for <= 0. Also fix some places checking the return of
clk_register() that incorrectly used ERR_PTR().
Link: https://lore.kernel.org/r/[email protected]
|
|
Testing an unisgned ivariable to be <= 0 will only detect the
case when it is 0. So correct this error test to a working version that
will behave as expected.
Signed-off-by: Andrew Goodbody <[email protected]>
|
|
Testing an unisgned ivariable to be <= 0 will only detect the
case when it is 0. So correct this error test to a working version that
will behave as expected.
Signed-off-by: Andrew Goodbody <[email protected]>
Reviewed-by: Heiko Schocher <[email protected]>
|
|
Testing an unisgned member of a struct to be <= 0 will only detect the
case when it is 0. So correct this error test to a working version that
will behave as expected.
Signed-off-by: Andrew Goodbody <[email protected]>
Reviewed-by: Heiko Schocher <[email protected]>
|
|
clk_register() will return standard error codes so the use of ERR_PTR()
is incorrect. Furthermore the code was ineffective as it lacked a return
statement that would have actually made use of the result. Add the
return statement and remove the use of ERR_PTR to correct this.
Signed-off-by: Andrew Goodbody <[email protected]>
Acked-by: Conor Dooley <[email protected]>
|
|
Testing an unisgned member of a struct to be <= 0 will only detect the
case when it is 0. So correct this error test to a working version that
will behave as expected.
Signed-off-by: Andrew Goodbody <[email protected]>
|
|
clk_get_rate() returns a ulong and that return value is assigned to a
member of a struct that is an unsigned int. So testing this value to <=
0 will only detect a return of 0. Also the code in the if block assumes
ret holds the return value when it does not. So update the test to one
that will work as intended and update the if block to actually refer to
the return value.
Signed-off-by: Andrew Goodbody <[email protected]>
|
|
https://source.denx.de/u-boot/custodians/u-boot-dfu into next
u-boot-dfu-next-20251203:
CI: https://source.denx.de/u-boot/custodians/u-boot-dfu/-/pipelines/28617
Fastboot:
- Add generic flashing support using BLK
|
