| Age | Commit message (Collapse) | Author |
|---|
|
In the test.py stage of the build we mark the pytest results as
artifacts to save, so that they can be used for reports. This however
leads to all of the artifacts being downloaded (and then not used) in
later stages. Optimize this out by using an empty list of dependencies
here (which is the keyword for which artifacts are needed).
Signed-off-by: Tom Rini <[email protected]>
Reviewed-by: Simon Glass <[email protected]>
|
|
When validating our current pipeline, a warning is produced about a lack
of a default workflow. For how we use it, we can add a simple default of
"always".
Signed-off-by: Tom Rini <[email protected]>
Reviewed-by: Simon Glass <[email protected]>
|
|
First, introduce DEFAULT_ALL_TAG, DEFAULT_ARM64_TAG, DEFAULT_AMD64_TAG
and DEFAULT_FAST_AMD64_TAG and remove the previous DEFAULT_TAG (as
anyone making use of that will need to adjust their jobs). This allows
us to say that some jobs can run on amd64 or arm64 hosts under the all
tag, while some jobs must run on amd64 (the Xtensa jobs due to
binary-only toolchains and sandbox for now) Then we rework the world
build stage to only run on our very fast amd64 hosts, or our arm64 hosts
(which are also very fast). This should result in a similar overall
build time but also a much more consistent overall build time as we
won't have the two big world jobs possibly run on our slower build
nodes.
Signed-off-by: Tom Rini <[email protected]>
|
|
Remove the rest of the places where we hard-code the version of the
toolchain we're using.
Signed-off-by: Tom Rini <[email protected]>
Reviewed-by: Simon Glass <[email protected]>
|
|
The xtensa architecture is interesting in that the platforms we support
are only valid on the binary-only toolchains as the DC233C instruction
set requires those toolchains (and not the FSF instruction set). Only
install the binary toolchain on amd64 hosts and only run the tests on
them as well.
Signed-off-by: Tom Rini <[email protected]>
Reviewed-by: Simon Glass <[email protected]>
|
|
- Two rswitch fixes and a clock fix
|
|
TFTP transfers of large files, for example 128 MiB, can sporadically
get stuck and the transfer slows down considerably.
This happens because the TX DMA descriptor in DRAM becomes out of sync
with the view of the TX DMA descriptor content from the CPU side, which
is viewed through the CPU caches. In order to guarantee these two views
are consistent, the cache over TX DMA descriptor that has possibly been
written by the rswitch hardware must first be invalidated, only then can
the descriptor be cleared and updated by the CPU, and finally the cache
over that area must be flushed back into DRAM to make sure the rswitch
hardware has consistent view of the updated descriptor content.
The very first invalidation operation was missing, which led to sporadic
corruption of the TX DMA descriptor. Fix it, add the missing invalidation
operation.
Reported-by: Enric Balletbo i Serra <[email protected]>
Signed-off-by: Marek Vasut <[email protected]>
Tested-by: Enric Balletbo i Serra <[email protected]>
|
|
TFTP transfer size can be used to re-size the TFTP progress bar on
single line based on the server reported file size. Enable it by
default for Renesas hardware to avoid long scrolling walls of '#'
character during long TFTP transfers.
Signed-off-by: Marek Vasut <[email protected]>
|
|
Early revisions of the R-Car V4M Series Hardware User’s Manual
contained an incorrect formula for the CPU core clocks:
ZCnφ = (PLL2VCO x 1/2) x mult/32
Dang-san fixed this by using CLK_PLL2_DIV2 instead of CLK_PLL2 as the
parent clock.
In Rev.0.70 of the documentation, the formula was corrected to:
ZCnφ = (PLL2VCO x 1/4) x mult/32
As the CPG Block Diagram now shows a separate 1/4 post-divider for PLL2,
the use of CLK_PLL2_DIV2 is a recurring source of confusion. Hence get
rid of CLK_PLL2_DIV2, and include the proper 1/4 post-divider in the
invocation of the DEF_GEN4_Z() macro, like is done on other R-Car Gen4
(and Gen3) SoCs.
Ported from Linux commit
92850bed9d4d ("clk: renesas: r8a779h0: Drop CLK_PLL2_DIV2 to clarify ZCn clocks")
Reported-by: Vinh Nguyen <[email protected]>
Signed-off-by: Geert Uytterhoeven <[email protected]>
Link: https://lore.kernel.org/0d2789cac2bf306145fe0bbf269c2da5942bb68f.1728377724.git.geert+renesas@glider.be
Signed-off-by: Marek Vasut <[email protected]>
|
|
https://source.denx.de/u-boot/custodians/u-boot-microblaze
AMD/Xilinx changes for v2025.01-rc5 - second
- Fix find_ram_top() return to support configs > 4GB
|
|
As the return type is "int" for find_ram_top() function and
returning the "base" which is of phys_addr_t is breaking when the
"base" address is 64-bit. So fix this by updating the return type as
phys_addr_t.
Signed-off-by: Venkatesh Yadav Abbarapu <[email protected]>
Reviewed-by: Michal Simek <[email protected]>
Acked-by: Sughosh Ganu <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Michal Simek <[email protected]>
|
|
One can use ccache by keeping ccache in PATH or by providing the full
path to ccache as well. Providing the full path to ccache fails as the
current regex tries to look for ccache being the initial token during
filtering.
Do a greedy search to remove anything before ccache for regex matching.
Fixes: 04b1d84221d5 ("Makefile: fix empty MK_ARCH when using ccache")
Signed-off-by: Manorit Chawdhry <[email protected]>
|
|
commit e27bddff4b97 ("imx8m: Restrict usable memory to space below 4G boundary")
tried to adjust the usable memory limits on a 4GB boundary.
ram_top is described as 'top address of RAM used by U-Boot' and we want
to preserve that. This is defined as a phys_addr_t and unfortunately
its size differs across architectures. This has lead us to a weird
state where 32bit boards define it 'SZ_4GB - 1' and 64bit boards as
'SZ_4GB' unless it was otherwise defined.
With some recent LMB changes and specifically
commit 1a48b0be93d4 ("lmb: prohibit allocations above ram_top even from same bank")
the board fails to boot properly although the commit above is correct
since it's making sure that no memory above ram_top is usable -- but
added to our memory map so EFI can hand it over to the booted OS.
The reason for that is that during the LMB init we add all usable memory
in lmb_add_memory(). In that function any memory above ram_top gets added
as 'reserved' for LMB. With the current values tha's set to 0xFFFF_FFFF
for this board. Later LMB is trying to protect the memory area U-Boot lives
in with lmb_reserve_common(). The latter fails though since it tries to
add U-Boot top (which is 0xFFFF_FFFF as well) to U-Boot 'bottom'. This call
will fail since 1 byte of that memory range is already marked as 'reserved'.
Since we are close to the release, LMB seems to assume that the address
is rounded up and is the 'next address' and so does parsing and adding
memory ranges from DT files, bump the ram_top of the board by 1byte.
In the long run we should change all of the above and have 32b and 64b
platforms define ram_top identically.
Add a Fixes tag although the commit is correct, so people can figure out
the broken scenarios in the future.
Suggested-by: Sughosh Ganu <[email protected]>
Fixes: commit 1a48b0be93d4 ("lmb: prohibit allocations above ram_top even from same bank")
Signed-off-by: Ilias Apalodimas <[email protected]>
Reviewed-by: Frieder Schrempf <[email protected]>
Reported-by: João Paulo Gonçalves <[email protected]>
Closes: https://lore.kernel.org/all/[email protected]/
Reviewed-by: Peng Fan <[email protected]>
Fixes: 74f88b72219e ("ARM: imx: imx8m: Fix board_get_usable_ram_top()")
|
|
("Enable EFI_LOADER_BOUNCE_BUFFER") is not the correct fix for the
problem it describes.
The change of memory addressing leading to side-effects in commit
22f2c9ed9f53 ("efi: memory: use the lmb API's for allocating and
freeing memory") is remedied by commit 1a48b0be93d4 ("lmb: prohibit
allocations above ram_top even from same bank").
This reverts commit 9c792ab336f7146e8d49bca6d9d093d2392ded5d.
|
|
eth_get_dev() returns NULL if no network device is available.
Not checking the return value leads to a crash when the device
pointer is dereferenced.
Signed-off-by: Heinrich Schuchardt <[email protected]>
Reviewed-by: Jerome Forissier <[email protected]>
|
|
If the dns command cannot find a network interface, we should return
CMD_RETFAIURE and not -1 (CMD_RET_USAGE).
Signed-off-by: Heinrich Schuchardt <[email protected]>
Reviewed-by: Jerome Forissier <[email protected]>
|
|
There have been a few changes to the areas that this file documents
without having regenerated the file. Do so now.
Signed-off-by: Tom Rini <[email protected]>
|
|
https://source.denx.de/u-boot/custodians/u-boot-dfu
CI: https://source.denx.de/u-boot/custodians/u-boot-dfu/-/pipelines/23951
Android:
- Fix kcmdline_extra support when parsing boot image
- Fix memory leak when after bootargs concatenation
- Fix length calculation when merging bootargs, cmdline and kcmdline
|
|
This brings in assortment of updates to our python tooling, from Paul
HENRYS <[email protected]>
|
|
When specifying a directory containing DTBs with 'fit,fdt-list-dir', it can be
handy not to have to also specify this directory to the input directories of
binman with '-I' option and use the method tools.append_input_dirs() append it.
This avoids to have to specify the DTB directory in both the device tree
provided to binman and through '-I' option to binman.
Signed-off-by: Paul HENRYS <[email protected]>
Reviewed-by: Simon Glass <[email protected]>
|
|
append_input_dirs() can be used to append a list of input directories to indir
global list.
Signed-off-by: Paul HENRYS <[email protected]>
Reviewed-by: Simon Glass <[email protected]>
|
|
This change allows to replace both 'SEQ' and 'NAME' keywords by respectively a
sequence number and the name of the FDT to provide more flexibility in the node
name for the device trees included in the FIT.
Signed-off-by: Paul HENRYS <[email protected]>
Reviewed-by: Simon Glass <[email protected]>
|
|
Input directories can be passed to binman using the '-I' option and those
input directories are now also passed to 'dtc' when run by binman.
Signed-off-by: Paul HENRYS <[email protected]>
Reviewed-by: Simon Glass <[email protected]>
|
|
An optional list of input directories can be passed to EnsureCompiled() which
allows to pass a list of directories where input files can be searched.
Signed-off-by: Paul HENRYS <[email protected]>
Reviewed-by: Simon Glass <[email protected]>
|
|
Test the property 'fit,encrypt' to encrypt FIT data.
Signed-off-by: Paul HENRYS <[email protected]>
|
|
mkimage can be used for both signing the FIT or encrypt its content and the
option '-k' can be used to pass a directory where both signing and encryption
keys can be retrieved. Adding 'fit,encrypt' property to the 'fit' node, leads to
try to find keys directory among binman include directories.
_get_priv_keys_dir() is renamed as _get_keys_dir() and adapted to support both
signing and encryption nodes in the FIT.
Signed-off-by: Paul HENRYS <[email protected]>
Reviewed-by: Simon Glass <[email protected]>
|
|
When the initialisation vector is randomly generated, its value shall be
stored in the FIT together with the encrypted data. The changes allow to
store the IV in the FIT also in the case where the key is not stored in
the DTB but retrieved somewhere else at runtime.
Signed-off-by: Paul HENRYS <[email protected]>
Reviewed-by: Simon Glass <[email protected]>
|
|
For new PowerPC developments, it will be useful to borrow devicetrees
from Linux. This patch makes it possible.
Signed-off-by: J. Neuschäfer <[email protected]>
Reviewed-by: Sumit Garg <[email protected]>
|
|
In generic_phy_get_bulk(), if 'phys' property is absent in
the device node then it is not an error condition.
Change print message verbosity to debug to avoid spamming
console in such cases.
Signed-off-by: Roger Quadros <[email protected]>
Reviewed-by: Siddharth Vadapalli <[email protected]>
|
|
The current value of CONFIG_FASTBOOT_BUF_ADDR is incorrect for hardware
with 512MB and 1GB of RAM. The RAM address ranges for these devices are:
- 512MB:
- Start: 0x80000000
- End: 0xA0000000
- 1GB:
- Start: 0x80000000
- End: 0xC0000000
The current buffer address makes fastboot downloads work only on
hardware with 2GB of RAM.
To fix this issue:
1. Lower CONFIG_FASTBOOT_BUF_ADDR to 0x88200000. This makes the buffer
to be equal ot CONFIG_SYS_LOAD_ADDR, which is a safe address to
download files using fastboot.
2. Reduce the size of the download buffer to 128MB, avoiding overlaps
with RAMDISK_ADDR_R. This is a good enough value for individual
downloads.
These changes make fastboot downloads work with 512MB and 1GB devices.
Fixes: defe30a78b76 ("verdin-am62: add DFU, USB and UUU fastboot support")
Signed-off-by: Hiago De Franco <[email protected]>
Acked-by: Francesco Dolcini <[email protected]>
|
|
Support of legacy 64-bit entry point was already present when booting a bzimage
with 'zboot' but not supported with 'bootm' when the x86_64 Linux kernel is
embedded in a FIT image.
Signed-off-by: Paul HENRYS <[email protected]>
Reviewed-by: Simon Glass <[email protected]>
|
|
Evgeny Bachinin <[email protected]> says:
This patch-set repairs ability to use sandbox with CONFIG_OF_EMBED=y.
For now, to use OF_EMBED, the following must be done
1) sandbox64_defconfig should have:
```
-CONFIG_OF_LIVE=y
+CONFIG_OF_EMBED=y
```
2) On sandbox when CONFIG_OF_EMBED=y, the u-boot process can't start
due to:
```
Bloblist at b000 not found (err=-2)
initcall failed at call 000000000011829c (err=-2: No such file or \
directory)
### ERROR ### Please RESET the board ###
```
So, it is natural desire to disable CONFIG_BLOBLIST just to test
sandbox with OF_EMBED=y (disable it one way or another):
```
config SANDBOX
- select BLOBLIST
+ select BLOBLIST if SOME_NON_EXISTING_OPTION
```
3) As a result, having such changes (CONFIG_OF_EMBED=y &&
CONFIG_BLOBLIST=n) leads to the link & run-time errors, being fixed
by this patch series.
Link: https://lore.kernel.org/r/20241202-sandbox_repair_of_embed-v1-0-05aff4b0ccf7@salutedevices.com
[trini: The final patch is dropped as no longer relevant with Simon's
rework to that function which is now applied.]
|
|
This series is from Simon Glass <[email protected]>.
It first corrects the test for checking if a bloblist could have come
from TPL and so we check for a device tree, and then changes the
argument order for board_fdt_blob_setup() to be more inline with our
usual argument ordering.
Link: https://lore.kernel.org/r/[email protected]
|
|
Having CONFIG_OF_EMBED=y && CONFIG_BLOBLIST=n leads to the link
error:
```
ld: /tmp/ccwtRVty.ltrans28.ltrans.o:(.data.rel+0x4e8): undefined \
reference to `do_ut_bootm'
```
Fixes: fe158657a5b ("test: inconsistent bootm tests")
Signed-off-by: Evgeny Bachinin <[email protected]>
|
|
Having CONFIG_OF_EMBED=y && CONFIG_BLOBLIST=n leads to the link
error:
```
ld: /tmp/ccwtRVty.ltrans28.ltrans.o:(.data.rel+0x4b0): undefined \
reference to `do_ut_bloblist'
```
Fixes: 6ea5df39e8d ("test: Only enable bloblist test when supported")
Signed-off-by: Evgeny Bachinin <[email protected]>
Reviewed-by: Simon Glass <[email protected]>
|
|
Having CONFIG_OF_EMBED=y && CONFIG_BLOBLIST=n leads to the link
error:
```
ld: /tmp/ccRVty.ltrans40.ltrans.o: in function `lib_test_is_enabled':
test/lib/kconfig.c:24: undefined reference to \
`invalid_use_of_IF_ENABLED_INT'
ld: test/lib/kconfig.c:26: undefined reference to \
`invalid_use_of_CONFIG_IF_ENABLED_INT'
```
Fixes: 29784d62ede ("test: Add some tests for kconfig.h")
Signed-off-by: Evgeny Bachinin <[email protected]>
Reviewed-by: Simon Glass <[email protected]>
|
|
Having CONFIG_OF_EMBED=y && CONFIG_BLOBLIST=n leads to the link
error:
```
ld: /tmp/ccwtRVty.ltrans0.ltrans.o: in function `state_uninit':
arch/sandbox/cpu/state.c:508: undefined reference to `bloblist_finish'
```
Fixes: 1c52fcca72b ("sandbox: Write out bloblist when exiting")
Signed-off-by: Evgeny Bachinin <[email protected]>
Reviewed-by: Simon Glass <[email protected]>
|
|
This returns a devicetree and updates a parameter with an error code.
Swap it, since this fits better with the way U-Boot normally works. It
also (more easily) allows leaving the existing pointer unchanged.
No yaks were harmed in this change, but there is a very small code-size
reduction.
For sifive, the OF_BOARD option must be set for the function to be
called, so there is no point in checking it again. Also OF_SEPARATE is
defined always.
Signed-off-by: Simon Glass <[email protected]>
Reviewed-by: Matthias Brugger <[email protected]>
Reviewed-by: Patrice Chotard <[email protected]>
[trini: Update total_compute]
Signed-off-by: Tom Rini <[email protected]>
|
|
The condition for receiving a bloblist from TPL is reversed. This was
only noticed are the other fixes landed. Fix it.
Signed-off-by: Simon Glass <[email protected]>
Reviewed-by: Matthias Brugger <[email protected]>
|
|
into next
CI: https://source.denx.de/u-boot/custodians/u-boot-riscv/-/pipelines/23926
- Board: Support LicheeRV Nano
- Board: Support bananapi-f3
- Board: Switch to OF_UPSTREAM for StarFive JH7110
- Board: Add sdhci driver for TH1520 SoC
|
|
https://source.denx.de/u-boot/custodians/u-boot-stm
CI: https://source.denx.de/u-boot/custodians/u-boot-stm/-/pipelines/23931
- Restore SPL boot from sdcard for STM32MP1 platforms
- Fix STACK_SIZE for STM32 MCU's board
|
|
Rework the bootargs concatenation allocating more accurately
the length that is needed.
Do not forget an extra byte for the null termination byte as,
in some cases, the allocation was 1 byte short.
Fixes: 86f4695b ("image: Fix Android boot image support")
Signed-off-by: Nicolas Belin <[email protected]>
Reviewed-by: Mattijs Korpershoek <[email protected]>
Link: https://lore.kernel.org/r/20241217-fix-bootargs-concatenation-v2-3-b2fd7cf4e130@baylibre.com
Signed-off-by: Mattijs Korpershoek <[email protected]>
|
|
Free newbootargs when the concatenation is done and bootargs env
is set.
Fixes: 86f4695b ("image: Fix Android boot image support")
Reviewed-by: Mattijs Korpershoek <[email protected]>
Signed-off-by: Nicolas Belin <[email protected]>
Link: https://lore.kernel.org/r/20241217-fix-bootargs-concatenation-v2-2-b2fd7cf4e130@baylibre.com
Signed-off-by: Mattijs Korpershoek <[email protected]>
|
|
Check that the value at the address kcmdline_extra is not 0
instead of checking the address value itself keeping it
consistent with what is done for kcmdline.
Fixes: b36b227b ("android: boot: support extra command line")
Reviewed-by: Mattijs Korpershoek <[email protected]>
Signed-off-by: Nicolas Belin <[email protected]>
Link: https://lore.kernel.org/r/20241217-fix-bootargs-concatenation-v2-1-b2fd7cf4e130@baylibre.com
Signed-off-by: Mattijs Korpershoek <[email protected]>
|
|
C.TOUCH 2.0
Restore boot SPL from sdcard for Engicam i.Core STM32MP1 C.TOUCH 2.0.
Fixes: 2a00d73d081a ("spl: mmc: Try to clean up raw-mode options")
Signed-off-by: Patrice Chotard <[email protected]>
Reviewed-by: Patrick Delaunay <[email protected]>
|
|
STM32MP1 MicroDev 2.0 7" OF
Restore boot SPL from sdcard for Engicam MicroGEA STM32MP1 MicroDev 2.0 7" OF
Fixes: 2a00d73d081a ("spl: mmc: Try to clean up raw-mode options")
Signed-off-by: Patrice Chotard <[email protected]>
Reviewed-by: Patrick Delaunay <[email protected]>
|
|
EDIMM2.2
Restore boot SPL from sdcard for Engicam i.Core STM32MP1 EDIMM2.2.
Fixes: 2a00d73d081a ("spl: mmc: Try to clean up raw-mode options")
Signed-off-by: Patrice Chotard <[email protected]>
Reviewed-by: Patrick Delaunay <[email protected]>
|
|
C.TOUCH 2.0
Restore boot SPL from sdcard for Engicam i.Core STM32MP1 C.TOUCH 2.0.
Fixes: 2a00d73d081a ("spl: mmc: Try to clean up raw-mode options")
Signed-off-by: Patrice Chotard <[email protected]>
Reviewed-by: Patrick Delaunay <[email protected]>
|
|
Restore boot SPL from sdcard for STM32MP1 platforms.
Fixes: 2a00d73d081a ("spl: mmc: Try to clean up raw-mode options")
Signed-off-by: Patrice Chotard <[email protected]>
Reviewed-by: Patrick Delaunay <[email protected]>
|
|
The content of CONFIG_OF_SPL_REMOVE_PROPS is the same in both
STM32MP15xx DHCOM and DHCOR defconfigs, deduplicate the content
into stm32mp15_dhsom.config .
Signed-off-by: Marek Vasut <[email protected]>
Reviewed-by: Patrice Chotard <[email protected]>
|
