Restyle all Kconfigs for "disk":
Menu entries : no space left
Menu attributes: 1 TAB
Help text : 1 TAB + 2 spaces
Replace '---help---' by 'help'
Signed-off-by: Johan Jonker <jbx6244@gmail.com>
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 <jbx6244@gmail.com>
Restyle all Kconfigs for "cmd":
Menu entries : no space left
Menu attributes: 1 TAB
Help text : 1 TAB + 2 spaces
Replace '---help---' by 'help'
Signed-off-by: Johan Jonker <jbx6244@gmail.com>
Restyle all Kconfigs for "boot":
Menu entries : no space left
Menu attributes: 1 TAB
Help text : 1 TAB + 2 spaces
Replace '---help---' by 'help'
Signed-off-by: Johan Jonker <jbx6244@gmail.com>
Johan Jonker <jbx6244@gmail.com> says:
The Kconfig menu attribute '---help---' is deprecated.
If we change to "help" the text has to indent.
This again has to align with other attributes,
so we have to restyle them as well.
And as there's a script then change all Kconfig
to start with the 'arch' and 'board' directories.
Restyle all Kconfigs:
Menu entries : no space left
Menu attributes: 1 TAB
Help text : 1 TAB + 2 spaces
Replace '---help---' by 'help'
Problems:
People creating indents in help texts.
The script doesn't care. It puts everything left aligned.
Help texts with empty lines. It stops aligning as help test.
Other fixes:
While using checkpatch.pl or the script some issues showed up,
so fix them as well.
Link: https://lore.kernel.org/r/d1270724-50eb-450d-8847-a3271ea27a2a@gmail.com
Restyle all Kconfigs:
Menu entries : no space left
Menu attributes: 1 TAB
Help text : 1 TAB + 2 spaces
Signed-off-by: Johan Jonker <jbx6244@gmail.com>
Reviewed-by: Tom Rini <trini@konsulko.com>
Restyle all Kconfigs other then "arm":
Menu entries : no space left
Menu attributes: 1 TAB
Help text : 1 TAB + 2 spaces
Signed-off-by: Johan Jonker <jbx6244@gmail.com>
Reviewed-by: Tom Rini <trini@konsulko.com>
Restyle all Kconfigs for "arm":
Menu entries : no space left
Menu attributes: 1 TAB
Help text : 1 TAB + 2 spaces
Replace '---help---' by 'help'
Signed-off-by: Johan Jonker <jbx6244@gmail.com>
Reviewed-by: Tom Rini <trini@konsulko.com>
While restyling Kconfig the script checkpatch.pl gives
this info:
WARNING: Possible repeated word: 'for'
Fix by changing 'for for' to 'for'.
Signed-off-by: Johan Jonker <jbx6244@gmail.com>
Reviewed-by: Tom Rini <trini@konsulko.com>
While restyling Kconfig the script checkpatch.pl gives
this info:
WARNING: 'refered' may be misspelled - perhaps 'referred'?
Fix by changing 'refered' to 'referred'.
Signed-off-by: Johan Jonker <jbx6244@gmail.com>
Reviewed-by: Tom Rini <trini@konsulko.com>
While restyling Kconfig the script checkpatch.pl gives
this info:
WARNING: 'Enble' may be misspelled - perhaps 'Enable'?
Fix by changing 'Enble' to 'Enable'.
Signed-off-by: Johan Jonker <jbx6244@gmail.com>
Reviewed-by: Tom Rini <trini@konsulko.com>
While restyling Kconfig the script checkpatch.pl gives
this info:
WARNING: 'suppport' may be misspelled - perhaps 'support'?
Fix by changing 'suppport' to 'support'.
Signed-off-by: Johan Jonker <jbx6244@gmail.com>
Reviewed-by: Tom Rini <trini@konsulko.com>
Ilias Apalodimas <ilias.apalodimas@linaro.org> says:
There was a discussion recently on the mailing lists regarding our
management of memory above ram_top [0]. The tl;dr is that we have two problems.
The first one is that U-Boot always relocates to the top of the first available
bank unless there's special board code to sidestep that. The second is we don't
successfully deal with devices that can only do 32-bit DMA.
This patch series deals with the first problem by adding a Kconfig option
allowing platforms to relocate to the top of the last discovered bank.
It's worth noting that this is easily testable with QEMU
qemu-system-aarch64 -m 8192 -smp 2 -nographic -cpu cortex-a57 \
-machine virt,secure=off \
-bios u-boot.bin \
-device virtio-rng-pci \
-drive id=os,if=none,file="$image" \
-device virtio-blk-device,drive=os \
-object memory-backend-ram,id=ram0,size=4G \
-object memory-backend-ram,id=ram1,size=4G \
-numa node,memdev=ram0 \
-numa node,memdev=ram1
# RELOC_ADDR_TOP not set
Hit any key to stop autoboot: 0
=> bdinfo
[...]
relocaddr = 0x000000013f66c000
reloc off = 0x000000013f66c000
[...]
lmb_dump_all:
memory.count = 0x1
memory[0] [0x40000000-0x23fffffff], 0x200000000 bytes, flags: none
reserved.count = 0x2
reserved[0] [0x13d507000-0x13d509fff], 0x3000 bytes, flags: no-notify, no-overwrite
reserved[1] [0x13d50aff0-0x23fffffff], 0x102af5010 bytes, flags: no-overwrite
devicetree = board
[...]
TLB addr = 0x000000013ffe0000
irq_sp = 0x000000013e50aff0
sp start = 0x000000013e50aff0
Early malloc usage: e88 / 2000
=>
# RELOC_ADDR_TOP enabled
=> bdinfo
[...]
relocaddr = 0x000000023f66c000
reloc off = 0x000000023f66c000
[...]
lmb_dump_all:
memory.count = 0x1
memory[0] [0x40000000-0x23fffffff], 0x200000000 bytes, flags: none
reserved.count = 0x2
reserved[0] [0x23d507000-0x23d509fff], 0x3000 bytes, flags: no-notify, no-overwrite
reserved[1] [0x23d50aff0-0x23fffffff], 0x2af5010 bytes, flags: no-overwrite
devicetree = board
[...]
TLB addr = 0x000000023ffe0000
irq_sp = 0x000000023e50aff0
sp start = 0x000000023e50aff0
Early malloc usage: e88 / 2000
=>
[0] https://lore.kernel.org/u-boot/CAC_iWjKFAzpj3B_MEW7-dnOrcAV-rfkhXXo8Bv0KgLNP2VJxRA@mail.gmail.com/
Link: https://lore.kernel.org/r/20260617074846.84362-1-ilias.apalodimas@linaro.org
Since devices that can't DMA above 4GiB will misbehave with this option
enabled add a warning on the documentation.
Reviewed-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
Tested-by: Christophe Leroy (CS GROUP) <chleroy@kernel.org>
Since we added an option for relocating U-Boot to the last memory bank,
enable it for QEMU to get some coverage
Reviewed-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
Tested-by: Christophe Leroy (CS GROUP) <chleroy@kernel.org>
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 <marek.vasut+renesas@mailbox.org>
Reviewed-by: Simon Glass <sjg@chromium.org>
Tested-by: Simon Glass <sjg@chromium.org> # Radxa ROCK 5B
Signed-off-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
Tested-by: Christophe Leroy (CS GROUP) <chleroy@kernel.org>
We are about to change the place we call dram_init_banksize().
The goal is to have all the information we need to pick a proper
relocation address in gd->dram[].
However, the RPI boards, and specifically the tested rpi4, seems
to hang if we relocate anywhere above the address returned from
bcm2835_mbox_call_prop().
So store that address and return it on get_effective_memsize()
which is used to calculate ram_top.
Reviewed-by: Simon Glass <sjg@chromium.org>
Tested-by: Simon Glass <sjg@chromium.org> # rpi, rpi4
Signed-off-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
Tested-by: Christophe Leroy (CS GROUP) <chleroy@kernel.org>
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 <sjg@chromium.org>
Tested-by: Anshul Dalal <anshuld@ti.com>
Tested-by: Michal Simek <michal.simek@amd.com> # Versal Gen 2 Vek385
Reviewed-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
Signed-off-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
Tested-by: Christophe Leroy (CS GROUP) <chleroy@kernel.org>
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 <sjg@chromium.org>
Tested-by: Anshul Dalal <anshuld@ti.com>
Tested-by: Michal Simek <michal.simek@amd.com> # Versal Gen 2 Vek385
Reviewed-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
Signed-off-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
Tested-by: Christophe Leroy (CS GROUP) <chleroy@kernel.org>
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 <anshuld@ti.com>
Tested-by: Michal Simek <michal.simek@amd.com> # Versal Gen 2 Vek385
Tested-by: Anshul Dalal <anshuld@ti.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
Tested-by: Christophe Leroy (CS GROUP) <chleroy@kernel.org>
goldfish_rtc_of_to_plat() currently returns success even when
dev_read_addr() fails to find a valid address. This leaves plat->reg
unset (or 0) and defers the failure to probe().
Return -EINVAL immediately when the address is FDT_ADDR_T_NONE so the
failure is reported at the of_to_plat stage where it belongs. This
aligns the driver with the recent fix introduced in the goldfish
serial driver by Naveen Kumar Chaudhary. [1]
Link: https://lore.kernel.org/u-boot/vgwnt6mnls3lf3zdm6mz5siztzkvppte4ykszbvifjzukvmksf@maaxe5agqpim/ [1]
Signed-off-by: Kuan-Wei Chiu <visitorckw@gmail.com>
goldfish_timer_of_to_plat() currently returns success even when
dev_read_addr() fails to find a valid address. This leaves plat->reg
unset and defers the failure to probe().
Return -EINVAL immediately when the address is FDT_ADDR_T_NONE so the
failure is reported at the of_to_plat stage where it belongs. This
aligns the driver with the recent fix introduced in the goldfish
serial driver by Naveen Kumar Chaudhary. [1]
Link: https://lore.kernel.org/u-boot/vgwnt6mnls3lf3zdm6mz5siztzkvppte4ykszbvifjzukvmksf@maaxe5agqpim/ [1]
Signed-off-by: Kuan-Wei Chiu <visitorckw@gmail.com>
goldfish_serial_of_to_plat() returns success even when dev_read_addr()
fails to find a valid address. This leaves plat->reg unset and defers
the failure to probe().
Return -EINVAL immediately when the address is FDT_ADDR_T_NONE so the
failure is reported at the of_to_plat stage where it belongs.
Signed-off-by: Naveen Kumar Chaudhary <naveen.osdev@gmail.com>
Acked-by: Kuan-Wei Chiu <visitorckw@gmail.com>
ca_serial_getc() reads from the URX_DATA register unconditionally
without first checking whether the RX FIFO contains valid data. When
the FIFO is empty, this returns whatever stale value is in the
register, which the DM serial framework interprets as a valid
character.
The DM serial framework expects getc() to return -EAGAIN when no data
is available, so it can handle retries and call schedule() to service
the watchdog between attempts.
Add a check of the UINFO register's UINFO_RX_FIFO_EMPTY bit before
reading URX_DATA, returning -EAGAIN when no data is pending. This
is consistent with how ca_serial_putc() already checks
UINFO_TX_FIFO_FULL before writing.
Signed-off-by: Naveen Kumar Chaudhary <naveen.osdev@gmail.com>
With commit 92aa3ec321 ("global_data: Reduce size of early-malloc vars")
the type changes from (unsigned) long to int. But the type for default
if SYS_MALLOC_F_LEN is unset was not changed. Remove the suffix.
Fixes the warning:
common/spl/spl.c:800:23: warning: format '%x' expects argument of type
'unsigned int', but argument 2 has type 'long int' [-Wformat=]
Fixes: 92aa3ec321 ("global_data: Reduce size of early-malloc vars")
Signed-off-by: Alexander Stein <alexander.stein@ew.tq-group.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
It's possible to interrupt the fastboot command from the U-Boot shell
using the Ctrl-c keybinding.
Document this.
Signed-off-by: Mattijs Korpershoek <mkorpershoek@kernel.org>
Reviewed-by: Sam Day <me@samcday.com>
When the `memory' efi selftest verifies the Devicetree memory reservation,
it accesses the memory_map buffer after it has been freed with free_pool().
Move the verification earlier to fix this.
Fixes: 34c96659ed ("efi_selftest: check fdt is marked as runtime data")
Signed-off-by: Vincent Stehlé <vincent.stehle@arm.com>
Cc: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Ilias Apalodimas <ilias.apalodimas@linaro.org>
Cc: Tom Rini <trini@konsulko.com>
Reviewed-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Barebox has now ported some of the UEFI code. In the process
they found some bugs.
In this case when the variable buffer is too small, efi_var_collect()
returns EFI_BUFFER_TOO_SMALL but doesn't free the allocated 'buf'.
Fixes: 5f7dcf079d ("efi_loader: UEFI variable persistence")
Signed-off-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
Reviewed-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
The `loaded image' efi selftest is comparing protocol GUIDs with the wrong
polarity.
This can be verified on the sandbox, where two protocols GUIDs are
retrieved by the test from the image handle in the following order:
1. Loaded Image Device Path Protocol GUID
2. Loaded Image Protocol GUID
The test matches on the first GUID, while it is in fact looking for the
second one; fix the comparison polarity.
Fixes: efe79a7c0d ("efi_selftest: test for loaded image protocol")
Signed-off-by: Vincent Stehlé <vincent.stehle@arm.com>
Cc: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Ilias Apalodimas <ilias.apalodimas@linaro.org>
Cc: Tom Rini <trini@konsulko.com>
Cc: Alexander Graf <agraf@csgraf.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Document support for Renesas Gray Hawk Single development board
based on Renesas R-Car V4M (R8A779H0) SoC.
Fixes: 53066deccb ("ARM: renesas: Add Renesas R8A779H0 V4M Gray Hawk board code")
Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
Document support for Renesas Geist development board
based on Renesas R-Car M3Le (R8A779MD) SoC.
Fixes: c8523795d7 ("arm64: dts: renesas: r8a779md: Add support for R-Car M3Le R8A779MD Geist")
Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
The RZ/N1D and RZ/N1S contain Cortex-A7 core, which is 32bit ARM core.
Document the SoC as 32bit ARM instead of aarch64.
Fixes: a5b9f95943 ("doc: renesas: add Renesas board docs")
Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
Reviewed-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
The read_poll_timeout() macro breaks out of its loop when the condition
evaluates to true. The current code uses "!tx_complete" as the
condition, which means it exits immediately when tx_complete is false
(i.e., transmission has NOT completed yet), rather than waiting for
completion.
Fix the condition to "tx_complete" so that the poll loop waits until
the TCPC signals transmission success/failure/discard before
proceeding.
Without this fix, tcpm_pd_transmit() returns before the TCPC has
finished transmitting, causing the PD state machine to proceed with
stale tx_status values.
Fixes: 1db4c0ac77 ("usb: tcpm: add core framework")
Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org>
Signed-off-by: Peng Fan <peng.fan@nxp.com>
Francesco Valla <francesco@valla.it> 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/20260604-spl_fit_full_cleanup-v1-0-ec036b5872e2@valla.it
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 <francesco@valla.it>
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/20210401182531.2147653-5-mr.nuke.me@gmail.com/
Signed-off-by: Francesco Valla <francesco@valla.it>
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 <francesco@valla.it>
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 <francesco@valla.it>
Align the behavior of fit_image_verify() called in SPL to the one in
full U-Boot. In particular, this function is called when both
CONFIG_SPL_LOAD_FIT_FULL and CONFIG_SPL_FIT_SIGNATURE are set (which can
happen e.g. in case of secure falcon boot).
Reviewed-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Francesco Valla <francesco@valla.it>
