| Age | Commit message (Collapse) | Author |
|---|
|
https://git.u-boot-project.org/u-boot/custodians/u-boot-dfu into next
CI: https://git.u-boot-project.org/u-boot/custodians/u-boot-dfu/-/pipelines/1016
u-boot-dfu-next-20260819
Android:
* avb: Make the AVB root key source pluggable
* avb: Add OP-TEE root key digest provider
* avb: Add board-specific root key provider
* avb: Update docs for root key source
|
|
load_simple_fit() is expected to fill in the image_info structure it
receives upon successful return, but the path which skips a zero-sized
image returns success without touching it. The result is that
spl_fit_record_loadable() then publishes whatever else the descriptor
happened to hold in /fit-images under the skipped image's name: the size
and entry point of the previous loadable, or - for the first one, since
image_info is declared without an initialiser - uninitialised stack.
This is reachable whenever a FIT carries an image node with no content,
which binman produces for an optional blob that was not supplied, such as
an OP-TEE which the build did not provide.
Ensure that the image_info structure is filled in with a size and entry
point before returning, same way as other successful paths do (but
skipping the actual load).
Fixes: 6d99f866952b ("spl: fit: Skip attempting to load 0 length image")
Signed-off-by: Alexey Charkov <[email protected]>
Reviewed-by: Simon Glass <[email protected]>
|
|
Current code tries to print information about the reset method whenever
sysreset support is enabled. This causes the core to try to bind the
sysreset device in board_init_f, even if the driver doesn't support
reset status reporting, causing pure waste on some platforms (e.g. on
Rockchip RK3576 it increases the boot time by ~0.4s even though the driver
doesn't support reset status reporting).
Make the printing of reset information optional, so that it can be
enabled only on platforms where it is supported and useful.
Only four sysreset drivers actually implement the get_status() op, so
default the new symbol to y wherever one of them can be in use to avoid
regressing those platforms:
- sysreset_sandbox
- sysreset_mpc83xx
- sysreset_psci, whose weak stub get_status() is only overridden by i.MX9;
- the pca9450 PMIC sysreset child driver.
Signed-off-by: Alexey Charkov <[email protected]>
|
|
The strongest anchor for the root of trust is a key hash burned into
hardware (OTP/eFuse), which is inherently SoC-specific and cannot live in
common code. Give boards a hook to supply it from wherever their hardware
keeps it.
The default is deliberately fail-closed: a board that has not wired up a
provider refuses verification rather than silently trusting whatever key it
is handed. A misconfiguration should stop the boot, not quietly weaken it.
Signed-off-by: Igor Opaniuk <[email protected]>
Reviewed-by: Mattijs Korpershoek <[email protected]>
Link: https://patch.msgid.link/[email protected]
Signed-off-by: Mattijs Korpershoek <[email protected]>
|
|
When a device already runs OP-TEE, its root-of-trust key should live in the
same secure, RPMB-backed storage that already holds the AVB rollback
indexes and lock state, so it is provisioned per device and protected by
the secure world -- not shipped inside the bootloader image.
Let AVB fetch the trusted digest from the OP-TEE AVB TA. It reuses the
existing persistent-value interface, so no change to the TA is required,
and a missing value fails closed.
Signed-off-by: Igor Opaniuk <[email protected]>
Reviewed-by: Mattijs Korpershoek <[email protected]>
Link: https://patch.msgid.link/[email protected]
Signed-off-by: Mattijs Korpershoek <[email protected]>
|
|
AVB's whole chain of trust reduces to a single public key, and that key is
currently hard-coded in U-Boot as the AVB reference/test key, whose private
half is public. That is fine for bring-up but unusable for a locked
product, which must anchor its root of trust in something an attacker
cannot swap out -- a hash fused into the SoC, a secure element -- rather
than a blob compiled into the bootloader.
Make the source of the trusted key digest selectable so a board can decide
where its root of trust lives, without touching the verification logic and
with any lookup failure treated as untrusted. The built-in key remains the
default, so existing users are unaffected; the sources a production device
actually needs are added in the following patches.
Signed-off-by: Igor Opaniuk <[email protected]>
Reviewed-by: Mattijs Korpershoek <[email protected]>
Link: https://patch.msgid.link/[email protected]
Signed-off-by: Mattijs Korpershoek <[email protected]>
|
|
Anshul Dalal <[email protected]> says:
This patch series fixes the negation on modern hush shell and adds a
sandbox test for the same.
Link: https://lore.kernel.org/r/[email protected]
|
|
The negation rule was not being applied when run_pipe was executed
leading to '! command' not actually negating the return code when using
modern shell.
=> cli set modern
=> ! false
=> echo $?
<Prints 1 before this patch with the expected output being 0>
Reported-by: Rasmus Villemoes <[email protected]>
Closes: https://lore.kernel.org/u-boot/[email protected]/
Signed-off-by: Anshul Dalal <[email protected]>
|
|
https://git.u-boot-project.org/u-boot/custodians/u-boot-snapdragon into next
* Support for building mbn files during the build with the new mkmbn
tool.
* Remove UCLASS_SMEM and the old smem driver (Qualcomm was the only
user of both), replace it with a port of the Linux SMEM driver.
* Refactor memory map parsing and support reading the memory layout from
the SMEM database.
* Set the serial# from SMEM.
* Introduce initial support for SPL in mach-snapdragon.
* Add a defconfig for sm8650 with U-Boot as the primary bootloader.
* Workaround an MMC issue by limiting the transfer size.
* Add support for SM7125/SC7180 (clock/pinctrl drivers and UFS phy).
* Add support for the QCS6490 powered Rubik Pi 3 board and document it.
|
|
In case MULTI_DTB_FIT_GZIP is enabled, fdtdec_setup() does uncompress
the compressed DTs in uncompress_blob() using gunzip(), which invokes
malloc() internally. The early simple malloc is initialized in board_f
initf_malloc() call, which sets up the early simple malloc limit and
offset pointer in global data. Currently, the initf_malloc() is called
after fdtdec_setup(), which leads to malloc failure in fdtdec_setup()
during the gzip decompression, because the early simple malloc is not
initialized yet.
Call initf_malloc() before fdtdec_setup() to assure fdtdec_setup() can
use malloc() during gzip decompression of the DTs.
The impact of this change on boot time is negligible, because the
initf_malloc() only assigns two fields in global data.
Signed-off-by: Marek Vasut <[email protected]>
Fixes: 95f4bbd581cf ("lib: fdt: Allow LZO and GZIP DT compression in U-Boot")
Reviewed-by: Simon Glass <[email protected]>
[trini: Update test/py/tests/test_trace.py]
Signed-off-by: Tom Rini <[email protected]>
|
|
Add CONFIG_SPL_OF_LIVE and if set, initialize of_live in spl.c
Signed-off-by: Michael Srba <[email protected]>
Reviewed-by: Simon Glass <[email protected]>
Reviewed-by: Casey Connolly <[email protected]>
Link: https://patch.msgid.link/[email protected]
Signed-off-by: Casey Connolly <[email protected]>
|
|
Some platforms (e.g. at least Qualcomm) use the ELF format in creative
ways, including in the bootrom. Make SPL_REMAKE_ELF use a linker script
specified in SPL_REMAKE_ELF_LDSCRIPT (with the previously hardcoded path
as the default).
Signed-off-by: Michael Srba <[email protected]>
Reviewed-by: Simon Glass <[email protected]>
Reviewed-by: Casey Connolly <[email protected]>
Link: https://patch.msgid.link/[email protected]
Signed-off-by: Casey Connolly <[email protected]>
|
|
It is possible that schedule(), and hence cyclic_run(), gets called
very early, perhaps even from assembly code. With
commit 9c1b13b3fd27 ("cyclic: reduce get_timer_us() calls inside
hlist_for_each_entry_safe()"), there is now an unconditional
get_timer_us(0) done outside the loop, and depending on the platform,
the timer infrastructure may not be set up yet. In at least one case,
that has caused a divide-by-0 and hence a failure to boot.
Platforms should really ensure their timers are ready ASAP, and in the
concrete case reported, that was indeed possible to fix that
way. However, it doesn't hurt to also insert an early return here, and
that could prevent other such hard-to-debug boot failures.
Reported-by: Emanuele Ghidoli <[email protected]>
Link: https://marc.info/?l=u-boot&m=178481834846283&w=2
Fixes: 9c1b13b3fd27 ("cyclic: reduce get_timer_us() calls inside hlist_for_each_entry_safe()")
Signed-off-by: Rasmus Villemoes <[email protected]>
Reviewed-by: Emanuele Ghidoli <[email protected]>
Reviewed-by: Stefan Roese <[email protected]>
[sr: fix Fixes: tag SHA length and return statement indentation]
|
|
As the comment indicates, this was used to silence a warning without
having to add casts everywhere gd->cyclic_list was referenced. But
nowadays gd is not volatile qualified, so this helper is not needed
and only obfuscates the code somewhat, because the head of the list
being operated on with the hlist_ or list_ macros is usually not
obtained via a function call.
Remove the helper and refer to the list head using the idiomatic
&gd->cyclic_list.
Signed-off-by: Rasmus Villemoes <[email protected]>
Reviewed-by: Stefan Roese <[email protected]>
|
|
The hash command currently always uses the software implementation for
the selected algorithm, even when driver-model hash providers are
available.
Add a hash_digest_wd_lookup() helper which probes UCLASS_HASH devices in
order and uses the first provider supporting the requested algorithm.
Continue past unavailable providers and unsupported operations, but
propagate a hard digest failure once a provider accepts the operation.
Remember probe failures so they are not silently hidden by software
fallback when no later provider succeeds.
Use the helper from the hash command and retain its software fallback
when no usable provider is present. Add sandbox tests covering provider
fallback and hard-error propagation.
Signed-off-by: James Hilliard <[email protected]>
|
|
binman's split-elf operation records one FIT image node per ELF
segment, all with os = "tee", and only the segment containing the ELF
entry point carries an entry property. Since fdt_add_subnode() inserts
new subnodes in front of existing ones, the /fit-images nodes end up in
reverse recording order, so spl_fit_images_find() would return the
*last* TEE segment and its load address was passed to BL31 as the BL32
entry point.
On RK3588 with an OP-TEE tee.elf consisting of two PT_LOAD segments
this made BL31 (SPD=opteed) ERET into OP-TEE's data segment at
0x30200000 instead of the entry point at 0x30000000, hanging the boot
right after 'BL31: Initializing BL32'.
Prefer the FIT image node which provides an entry property and only
fall back to the first matching node when none of them has one.
Signed-off-by: Daniel Golle <[email protected]>
|
|
get_partition() returns a malloc()'d struct mmc_part and only frees it on
its own internal error path. None of its callers - mmc_byte_io(),
get_unique_guid_for_partition() and get_size_of_partition() - free the
returned pointer, so every partition access leaks one struct mmc_part.
A single "avb verify" issues many such accesses (footer, vbmeta and the
hashed image chunks), so the leak accumulates quickly.
Free the descriptor in all three callers. mmc_byte_io() is reworked to
use a single exit path so the partition is released on every return.
Fixes: 3af30e4443aa ("avb2.0: implement AVB ops")
Signed-off-by: Igor Opaniuk <[email protected]>
Reviewed-by: Mattijs Korpershoek <[email protected]>
Link: https://patch.msgid.link/[email protected]
Signed-off-by: Mattijs Korpershoek <[email protected]>
|
|
load_simple_fit() loads an image stored as external data by reading
it from the boot device with a transfer sized from the FIT data-size
property. That property is listed in exc_prop[] in image-fit-sig.c,
so it is excluded from the configuration signature and stays under
the control of anyone able to modify the boot medium even when
CONFIG_SPL_FIT_SIGNATURE is enabled. The read happens before
fit_image_verify_with_data() checks the image hash, so an inflated
data-size overruns the destination before the corruption can be
detected. The device-tree overlay path is the sharpest case, because
there the destination is a fixed CONFIG_SPL_LOAD_FIT_APPLY_OVERLAY_BUF_SZ
heap buffer.
Pass the size of the destination into load_simple_fit() and reject
an image whose data does not fit before the read is issued. The
check is done in two places: an early bail on len > max_size, then a
bail on the block-aligned size > max_size. The size check is the
mathematically binding one because size is len rounded up to the
device block length. The early bail exists so that
get_aligned_image_size() never runs on a hostile len, where its int
arithmetic would invoke signed-integer overflow.
For the overlay path the bound is exact: the caller passes the size
of its temporary buffer. For the firmware, loadables, FDT and FPGA
call sites the destination is wherever the load_addr field points,
with no defined upper limit at the call site. Those callers pass
CONFIG_SYS_BOOTM_LEN as a conservative ceiling, matching the same
limit spl_parse_legacy_validate() already applies to legacy images.
It is not a tight bound on the actual capacity at the destination,
just a cap that rejects implausibly-sized data.
Signed-off-by: Aristo Chen <[email protected]>
Reviewed-by: Simon Glass <[email protected]>
|
|
Now that we have made bloblist have distinct "find" and "create"
functions, the global data tag "GD_FLG_BLOBLIST_READY" doesn't quite
make sense anymore. Rename it to GD_FLG_BLOBLIST_HANDOFF.
Suggested-by: Raymond Mao <[email protected]>
Reviewed-by: Raymond Mao <[email protected]>
Signed-off-by: Tom Rini <[email protected]>
|
|
Patrice Chotard <[email protected]> says:
First patch is replacing uint64_t by u64 as suggested by b4
Second patch optimizes cyclic_run() to parse cyclic list only
if a cyclic function's timestamp is elapsed.
Link: https://lore.kernel.org/r/[email protected]
|
|
On STM32MP157C-DK2, when using the "ums" command, in sleep_thread(),
ctrlc() is called every ~640ms which doesn't allows high reactivity when
user press CTRL+C in U-Boot console.
In sleep_thread() loop, ctrlc() is called every 200000 iterations.
But schedule is called on each loop iteration.
Optimize cyclic_run() in order to not call get_timer_us() on each entry.
This allow to save computation time :
_ before : ctrlc() is called every ~640ms
_ after : ctrlc() is called every ~230ms
Signed-off-by: Rasmus Villemoes <[email protected]>
Signed-off-by: Patrice Chotard <[email protected]>
Cc: Marek Vasut <[email protected]>
|
|
For new patch, b4 is suggested to replace type 'uint64_t' by 'u64' :
CHECK: Prefer kernel type 'u64' over 'uint64_t'
Update cyclic.c accordingly in order to be coherent with following commit.
Signed-off-by: Patrice Chotard <[email protected]>
Reviewed-by: Marek Vasut <[email protected]>
|
|
|
|
Restyle all Kconfigs for "common":
Menu entries : no space left
Menu attributes: 1 TAB
Help text : 1 TAB + 2 spaces
Replace '---help---' by 'help'
Signed-off-by: Johan Jonker <[email protected]>
|
|
Right now we only relocate u-boot to the top of the first
memory bank unless the board specific code overwrites it.
This is problematic when loading big binaries as it
fragments the contiguous memory space for no apparent reason.
On certain platforms, it is currently not possible to relocate U-Boot
above the 32bit boundary, due to various dependencies on content located
below the 32bit boundary. One such example is ethernet, where the packet
buffer built into U-Boot binary is placed below the 32bit boundary and
allows loading of data via ethernet even above 32bit boundary due to
memory copy from the packet buffer to the destination location.
A previous patch moves the bi_dram[] info from bd to gd and make
the memory bank information available early. So move the
dram_init_banksize() INITCALL before the relocation address calculation
and use it to derive the address.
Also add a Kconfig option and allow the common code to relocate U-Boot
to the top of the last discovered bank.
It's worth noting that this patch changes when dram_init_banksize()
is called. It's now called much earlier in the board init process.
That is a significant ordering change for every board with a custom
dram_init_banksize(), and it is unconditional (not gated on RELOC_ADDR_TOP).
Reviewed-by: Marek Vasut <[email protected]>
Reviewed-by: Simon Glass <[email protected]>
Tested-by: Simon Glass <[email protected]> # Radxa ROCK 5B
Signed-off-by: Ilias Apalodimas <[email protected]>
Tested-by: Christophe Leroy (CS GROUP) <[email protected]>
|
|
Right now the function does
- Re-adjust the ram_size based on Kconfig options
- Set ram_top
- Set the relocation address
It also does not set the ram_size in case ram_top grew
from it's initial value. But ram_top and ram_size should
always be changed together.
So let's make things a bit cleaner and move the ram calculations
in their own INITCALL
Reviewed-by: Simon Glass <[email protected]>
Tested-by: Anshul Dalal <[email protected]>
Tested-by: Michal Simek <[email protected]> # Versal Gen 2 Vek385
Reviewed-by: Marek Vasut <[email protected]>
Signed-off-by: Ilias Apalodimas <[email protected]>
Tested-by: Christophe Leroy (CS GROUP) <[email protected]>
|
|
Currently, ram_base is calculated within setup_dest_addr().
However, upcoming patches that enable U-Boot relocation to the highest
DRAM bank require ram_base to be initialized earlier.
The default dram_init_banksize() definition relies on ram_base
to calculate the start of the first bank. But following patches
will move that function to execute immediately before setup_dest_addr().
So let's split the ram_base initialization in its own INITCALL.
Reviewed-by: Simon Glass <[email protected]>
Tested-by: Anshul Dalal <[email protected]>
Tested-by: Michal Simek <[email protected]> # Versal Gen 2 Vek385
Reviewed-by: Marek Vasut <[email protected]>
Signed-off-by: Ilias Apalodimas <[email protected]>
Tested-by: Christophe Leroy (CS GROUP) <[email protected]>
|
|
Currently, the bi_dram[] information is stored in the board info
structure (bd). Because bd is only valid after reserve_board(),
dram_init_banksize() must be called late in the initialization process.
This limitation is problematic, as it forces us to rely on a variety of
bespoke functions to determine board RAM, bank memory sizes, and other
early setup requirements.
By moving bi_dram[] into the global data (gd), we can run it earlier.
This is particularly convenient since boards define their own
dram_init_banksize() routines, which do not always rely on parsing
Device Tree (DT) memory nodes.
Additionally, U-Boot defaults to relocating to the top of the first memory
bank. While boards currently use custom functions to override this
behavior, having the DRAM bank information available earlier in gd makes
relocating to a different bank trivial and standardizes the process.
Reviewed-by: Anshul Dalal <[email protected]>
Tested-by: Michal Simek <[email protected]> # Versal Gen 2 Vek385
Tested-by: Anshul Dalal <[email protected]>
Reviewed-by: Simon Glass <[email protected]>
Signed-off-by: Ilias Apalodimas <[email protected]>
Tested-by: Christophe Leroy (CS GROUP) <[email protected]>
|
|
Corechips SL6341 is a 4-port USB 2.0 and 3.0 hub controller. It always
requires external 1V1 power and can optionally use external 3V3 power
(or alternatively it has a 5V->3V3 LDO built in to derive 3V3 power from
VBUS). It also exposes a reset pin.
Device tree bindings are merged for upstream release with Linux 7.1 as
commit bfcb86e58f3a ("dt-bindings: usb: Add Corechips SL6341 USB2.0/3.0
hub controller") [1]
Link: https://github.com/torvalds/linux/commit/bfcb86e58f3a58d05b95970d81b94cb011982780 [1]
Signed-off-by: Alexey Charkov <[email protected]>
Reviewed-by: Marek Vasut <[email protected]>
Reviewed-by: Quentin Schulz <[email protected]>
|
|
Francesco Valla <[email protected]> says:
This patch set contains a collection of small fixes and cleanups for the
"full" FIT loader that can be used for the SPL. The main beneficiary is
the falcon boot flow, but the same loader can be used also for U-Boot
proper.
Patch 1 was part of another set, but I decided to put it here for a
better separation between plumbing (here) and new features (there). I
kept the Reviewed-by tag collected from Simon in that occasion.
Patch 6 introduces a new unit test covering most of the code that is
being cleaned up.
The set was tested on a i.MX93 FRDM, both with and without signature and
to boot both U-Boot proper and the Linux kernel directly (i.e., falcon
boot).
Link: https://lore.kernel.org/r/[email protected]
|
|
Replace #ifdef directives with the CONFIG_IS_ENABLED() for better
coverage and cleaner code. In the mean time, convert the last
IS_ENABLED() to CONFIG_IS_ENABLED().
Signed-off-by: Francesco Valla <[email protected]>
|
|
The 'standalone =' config property has been deprecated for ~5 years [1],
with the loud warn about the deprecation lasting much more than the
foreseen couple of releases.
Remove the attempt to load the primary image through this property to
save some boot time and code complexity.
[1] https://lore.kernel.org/u-boot/[email protected]/
Signed-off-by: Francesco Valla <[email protected]>
|
|
U-Boot proper expects its FDT to be right after its binary image; the
"full" FIT image loader thus adopts an hack to relocate it, ignoring
the specified load address.
Rework the current form of the hack to:
- support the 'sandbox' environment with a sysmem-aware memcpy;
- use the ALIGN() macro instead of raw alignment logic;
- align the FDT to 8-byte boundary as per FDT specifications;
- fix the debug print (which was reporting the source address for the
relocation instead of the destination one).
Signed-off-by: Francesco Valla <[email protected]>
|
|
Align the fit_image_load() call done for the loadables to the ones for
other artifatcs (firmware, kernel, fdt), calling virt_to_phys() on the
pointer that contains the FIT location.
This is needed to support the 'sandbox' environment.
Signed-off-by: Francesco Valla <[email protected]>
|
|
Bastien Curutchet <[email protected]> says:
This series aims to add back the omap4 support. This support was removed
by commit b0ee3fe642c ("arm: ti: Remove omap4 platform support") because
at that moment, none of the OMAP4-based boards had done the migration to
DM_I2C.
My use case is an old product based on the Variscite's omap4 system on
module. I needed to upgrade U-Boot on it for security reasons. I think
that this work could benefit to other people who may have same kind of
product to maintain.
Patch 1 to 3 remove the omap's clock driver dependency to the AM33xx
as it is also present in omap4 platforms. I tested these changes on the
beaglebone black to ensure I didn't break the AM33xx case.
Patch 4 & 5 revert the deletion of the omap4 support. The revert makes
checkpatch.pl angry. I fixed quite a lots of warnings already but it
remains two kinds of warnings:
- CamelCase on timings structure, I left the CamelCase because IMHO it's
more readable this way.
- #ifdef CONFIG_XYZ shouldn't be used anymore. I left one of this because
I didn't find a clean way to get rid of it.
Patch 6 adds support for the Variscite's system on module. This system on
module is supported by the Linux project through
ti/omap/omap4-var-som-om44.dtsi
Link: https://lore.kernel.org/r/[email protected]
|
|
omap4 support was dropped by b0ee3fe642c ("arm: ti: Remove omap4 platform
support") because the supported boards hadn't done the conversion to
CONFIG_DM_I2C in time. It still exists some omap4-based products and
they could benefit from the latest U-Boot support for obvious security
reasons.
Revert part of b0ee3fe642c to introduce back a minimal support for the
omap4 platform.
Fix the checkpatch's warning/errors induced by this revert. Following
warnings are still present:
| arch/arm/include/asm/arch-omap4/clock.h:445: WARNING: added, moved or deleted file(s), does MAINTAINERS need updating?
| arch/arm/mach-omap2/omap4/hwinit.c:24: WARNING: Use 'if (IS_ENABLED(CONFIG...))' instead of '#if or #ifdef' where possible
| arch/arm/mach-omap2/omap4/sdram_elpida.c:142: CHECK: Avoid CamelCase: <tRPab>
| arch/arm/mach-omap2/omap4/sdram_elpida.c:143: CHECK: Avoid CamelCase: <tRCD>
| arch/arm/mach-omap2/omap4/sdram_elpida.c:144: CHECK: Avoid CamelCase: <tWR>
| arch/arm/mach-omap2/omap4/sdram_elpida.c:145: CHECK: Avoid CamelCase: <tRASmin>
| arch/arm/mach-omap2/omap4/sdram_elpida.c:146: CHECK: Avoid CamelCase: <tRRD>
| arch/arm/mach-omap2/omap4/sdram_elpida.c:147: CHECK: Avoid CamelCase: <tWTRx2>
| arch/arm/mach-omap2/omap4/sdram_elpida.c:148: CHECK: Avoid CamelCase: <tXSR>
| arch/arm/mach-omap2/omap4/sdram_elpida.c:149: CHECK: Avoid CamelCase: <tXPx2>
| arch/arm/mach-omap2/omap4/sdram_elpida.c:150: CHECK: Avoid CamelCase: <tRFCab>
| arch/arm/mach-omap2/omap4/sdram_elpida.c:151: CHECK: Avoid CamelCase: <tRTPx2>
| arch/arm/mach-omap2/omap4/sdram_elpida.c:152: CHECK: Avoid CamelCase: <tCKE>
| arch/arm/mach-omap2/omap4/sdram_elpida.c:153: CHECK: Avoid CamelCase: <tCKESR>
| arch/arm/mach-omap2/omap4/sdram_elpida.c:154: CHECK: Avoid CamelCase: <tZQCS>
| arch/arm/mach-omap2/omap4/sdram_elpida.c:155: CHECK: Avoid CamelCase: <tZQCL>
| arch/arm/mach-omap2/omap4/sdram_elpida.c:156: CHECK: Avoid CamelCase: <tZQINIT>
| arch/arm/mach-omap2/omap4/sdram_elpida.c:157: CHECK: Avoid CamelCase: <tDQSCKMAXx2>
| arch/arm/mach-omap2/omap4/sdram_elpida.c:158: CHECK: Avoid CamelCase: <tRASmax>
| arch/arm/mach-omap2/omap4/sdram_elpida.c:159: CHECK: Avoid CamelCase: <tFAW>
| arch/arm/mach-omap2/omap4/sdram_elpida.c:209: CHECK: Avoid CamelCase: <tRL>
| arch/arm/mach-omap2/omap4/sdram_elpida.c:210: CHECK: Avoid CamelCase: <tRP_AB>
| arch/arm/mach-omap2/omap4/sdram_elpida.c:213: CHECK: Avoid CamelCase: <tRAS_MIN>
| arch/arm/mach-omap2/omap4/sdram_elpida.c:215: CHECK: Avoid CamelCase: <tWTR>
| arch/arm/mach-omap2/omap4/sdram_elpida.c:216: CHECK: Avoid CamelCase: <tXP>
| arch/arm/mach-omap2/omap4/sdram_elpida.c:217: CHECK: Avoid CamelCase: <tRTP>
I didn't find an clean way to fix the "don't use #ifdef" warning as we
need to define the gpio_bank for the SPL build only.
For the CamelCase warnings, the incriminated attributes represent
timings, so IMHO, it is more readable with CamelCase.
Set myself as OMAP4 maintainer.
Signed-off-by: Bastien Curutchet <[email protected]>
|
|
[email protected] <[email protected]> says:
From: Randolph Sapp <[email protected]>
Nitpicks and fixes from the discovery thread on adding PocketBeagle2 support
[1]. This does a lot of general setup required for the device, but these
modifications themselves aren't device specific. For those specifically
interested in PocketBeagle2 support and don't care about these details, my
development branch is public [2].
That first patch may provoke some opinions, but honestly if that warning was
still present I wouldn't have spent a week poking holes in both the EFI and LMB
allocations systems. Please let me know if there is a specific usecase that it
breaks though.
[1] https://lore.kernel.org/all/[email protected]/
[2] https://github.com/StaticRocket/u-boot/tree/feature/pocketbeagle2
Link: https://lore.kernel.org/r/[email protected]
|
|
Add a new global data struct member called initial_relocaddr. This
stores the original value of relocaddr, directly from setup_dest_addr.
This is specifically to avoid any adjustments made by other init
functions.
Reserve the memory from gd->start_addr_sp - CONFIG_STACK_SIZE to
gd->initial_relocaddr instead of gd->ram_top. This allows platform
specific relocation addresses to work without unnecessarily painting
over a large range.
Signed-off-by: Randolph Sapp <[email protected]>
Reviewed-by: Simon Glass <[email protected]>
Reviewed-by: Ilias Apalodimas <[email protected]>
|
|
Tom Rini <[email protected]> says:
This series does a few small but important cleanups to how we check for,
and initialize a bloblist. The first thing is that the way things are
done today, our HANDOFF code can only work with a fixed bloblist
location, so express that requirement in Kconfig. Next, we demote the
scary message about "Bloblist at ... not found" to a debug because we
most often see that because the bloblist doesn't (and can't) exist yet.
Finally, we remove bloblist_maybe_init and split this in to an exists
and a real init. This results in practically no growth (between 8 bytes
growth to 12 bytes saved, with some outliers saving much more thanks to
knowing it's impossible to have been passed a bloblist yet). This also
cleans up some of the code around checking for / knowing about a
bloblist existing.
Link: https://lore.kernel.org/r/[email protected]
|
|
With bloblist, we need to both see if one already exists as well as
create one if it does not. However, the current implementation leads to
odd cases where we attempt to create a bloblist before this is possible
and have things be overly complicated when we are given one to work
with.
This reworks things to instead have a bloblist_exists function, which as
the name implies checks for an existing bloblist. This is used in
the case of booting, to see if we have one and in turn if we have a
device tree there as well as in the bloblist_init function to see if we
need to do anything.
In practical details, we move the logic from bloblist_init that was
checking for a bloblist to the new bloblist_exists function and then can
clarify the logic as it is much easier to state when we know we do not
have one rather than all the ways we might have one. Then we have the
locations that set gd->bloblist now also set the GD_FLG_BLOBLIST_READY
flag.
Reviewed-by: Raymond Mao <[email protected]>
Tested-by: Alexander Stein <[email protected]>
Signed-off-by: Tom Rini <[email protected]>
|
|
The message about not finding a bloblist will quite often be seen at
least once, and is non-fatal. Demote this to a log_debug message from a
log_warning message.
Reviewed-by: Raymond Mao <[email protected]>
Tested-by: Alexander Stein <[email protected]>
Signed-off-by: Tom Rini <[email protected]>
|
|
Currently, the only way we support passing a bloblist from one stage to
the next is via the BLOBLIST_FIXED mechanism. Update the Kconfig logic
to express this constraint.
Reviewed-by: Raymond Mao <[email protected]>
Tested-by: Alexander Stein <[email protected]>
Signed-off-by: Tom Rini <[email protected]>
|
|
Some error messages emitted while loading the splash image are too
cryptic and don't provide any insights into the failure being a splash
related issue, such as 'Error (-2): cannot determine file size' etc.
This patch fixes the error codes by adding the function name to the
error print.
Signed-off-by: Anshul Dalal <[email protected]>
[trini: Add missing ',' and wrap to 80-width]
Signed-off-by: Tom Rini <[email protected]>
|
|
Avoid using ps_prompt having a NULL pointer. For that, use the same
approach as in uboot_cli_readline().
Suggested-by: Simon Glass <[email protected]>
Signed-off-by: Adam Lackorzynski <[email protected]>
Reviewed-by: Simon Glass <[email protected]>
|
|
Prepare v2026.07-rc3
|
|
When loading container image, the container header is loaded into
heap memory. If ahab is enabled, the header is be copied to another
fixed RAM for authentication in ahab_auth_cntr_hdr. The better method
is using container header memory being authenticated for following
image loading.
So update ahab_auth_cntr_hdr to return the address of container header
being authenticated. Caller uses this header for following parsing
and image loading.
Signed-off-by: Ye Li <[email protected]>
Reviewed-by: Peng Fan <[email protected]>
|
|
Commit 6c171f7a184c ("common: board: make initcalls static") broke the
call to cpu_init_r. That is because PPC is already defined to 1, see:
powerpc-linux-gnu-gcc -dM -E - < /dev/null
This will conflict with the CONFIG_IS_ENABLED(PPC). Change it to
IS_ENABLED(CONFIG_PPC).
Fixes: 6c171f7a184c ("common: board: make initcalls static")
Signed-off-by: Michael Walle <[email protected]>
Signed-off-by: Peng Fan <[email protected]>
|
|
Rasmus Villemoes <[email protected]> says:
There are quite a few places where we allocate X+1 bytes, initialize
the first X bytes via memcpy() and then set the last byte to 0.
The kernel has a helper for that, kmemdup_nul(). Introduce a similar
one, and start making use of it in a few places. Also the existing
memdup() helper can be put to more use.
There are lots more places one could modify. But for code shared with
host tools, one would need to do some refactoring, putting memdup()
and memdup_nul() in their own str-util.c TU which could then also be
included in the tools build.
Link: https://lore.kernel.org/r/[email protected]
|
|
Use memdup_nul() instead of open-coding it.
Reviewed-by: Simon Glass <[email protected]>
Signed-off-by: Rasmus Villemoes <[email protected]>
|
|
The helper stdio_clone only has a single caller, so it certainly
doesn't need to be public. But in fact, it is merely an open-coded
memdup() - which for some reason uses calloc() even if the whole
allocation is obviously immediately overwritten.
Drop it and just use memdup() directly.
Reviewed-by: Simon Glass <[email protected]>
Signed-off-by: Rasmus Villemoes <[email protected]>
|
