Greg Malysa authored 1 year ago and Tom Rini committed 11 months ago

LDR format files are used primarily by Analog Devices processors but may
be of interest to other vendors. Previously support existed for this
format as part of the U-Boot build, but it has been unmaintained and
unused for a long time. In preparation for adding support for modern ADI
processors that use LDR, modernize the LDR support:

- Introduce CONFIG_LDR_CPU as the CPU string recognized by the LDR tool
  may not be the same as CONFIG_CPU
- Add an SPL target that repackages u-boot-spl inside an LDR file

An almost identical target for packaging u-boot into an LDR file already
exists and did not need to be created.

Co-developed-by: Nathan Barrett-Morrison <nathan.morrison@timesys.com>
Signed-off-by: Nathan Barrett-Morrison <nathan.morrison@timesys.com>
Signed-off-by: Ian Roberts <ian.roberts@timesys.com>
Signed-off-by: Greg Malysa <greg.malysa@timesys.com>

Jonas Karlman authored 1 year ago and Kever Yang committed 1 year ago

Currently the following memory layout is typically used on RK3308:
[    0, 256K) - SPL binary
[ 256K,   2M) - TF-A / reserved
[   -X,   4M) - SPL pre-reloc stack (SPL_STACK)
[  -8K,   4M)   - pre-reloc malloc heap (SPL_SYS_MALLOC_F_LEN)
[   4M,  +8K) - SPL bss (SPL_BSS_START_ADDR, SPL_BSS_MAX_SIZE)
[   6M,   +X) - U-Boot proper binary (TEXT_BASE)
[   -X,   8M) - U-Boot proper pre-reloc stack (CUSTOM_SYS_INIT_SP_ADDR)
[  -8K,   8M)   - pre-reloc malloc heap (SYS_MALLOC_F_LEN)
[   -X,  12M) - SPL reloc stack (SPL_STACK_R_ADDR)
[  11M,  12M)   - reloc malloc heap (SPL_STACK_R_MALLOC_SIMPLE_LEN)

SPL can safely load U-Boot proper + FDT to [6M, 8M-8K) with this layout.

Migrate to use common bss, stack and malloc heap size and addresses to
remove this size limitation and extend the malloc heap size being used.

Signed-off-by: Jonas Karlman <jonas@kwiboo.se>
Reviewed-by: Kever Yang <kever.yang@rock-chips.com>

The maximum size of u-boot.img on R-Car Gen2 is 0x80000 or 512 kiB,
set the limit to avoid overflows as new functionality gets pulled in.

Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
Reviewed-by: Paul Barker <paul.barker.ct@bp.renesas.com>

John Keeping authored 1 year ago and Tom Rini committed 1 year ago

This config option enables the malloc() pool in TPL not the SPL.  Fix
the description to accurately reflect this.

Fixes: fd8497da (spl: Create proper symbols for enabling the malloc() pool)
Signed-off-by: John Keeping <jkeeping@inmusicbrands.com>
Reviewed-by: Simon Glass <sjg@chromium.org>

Simon Glass authored 1 year ago and Tom Rini committed 1 year ago

Move the useful help to Kconfig.

Drop mention of CONFIG_SYS_MALLOC_SIMPLE since it doesn't exist.

Correct a 'CONFIGSYS_MALLOC_F_LEN' typo

Signed-off-by: Simon Glass <sjg@chromium.org>

Simon Glass authored 1 year ago and Tom Rini committed 1 year ago

Use the new SPL/TPL/VPL_SYS_MALLOC_F symbols to determine whether the
malloc pool exists.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Sean Anderson <sean.anderson@seco.com>

Simon Glass authored 1 year ago and Tom Rini committed 1 year ago

For U-Boot proper we have CONFIG_SYS_MALLOC_F which indicates that a
malloc() pool is available before relocation.

For SPL we only have CONFIG_SPL_SYS_MALLOC_F_LEN which indicates the
size of the pool.

In various places we use CONFIG_SPL_SYS_MALLOC_F_LEN == 0 to indicate
that there is no pool.

This differing approach is confusing. Add a new CONFIG_SPL_SYS_MALLOC_F
symbol for SPL (and similarly for TPL and VPL). Tidy up the Kconfig
help for clarity.

For now these symbols are not used. That is cleaned up in the following
patches.

Signed-off-by: Simon Glass <sjg@chromium.org>

Simon Glass authored 1 year ago and Tom Rini committed 1 year ago

We like to put the SPL first so it is clear that it relates to SPL. Rename
various malloc-related options which have crept in, to stick to this
convention.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Marcel Ziswiler <marcel.ziswiler@toradex.com>
Reviewed-by: Martyn Welch <martyn.welch@collabora.com>
Reviewed-by: Svyatoslav Ryhel <clamor95@gmail.com>

Jesse Taube authored 1 year ago and Tom Rini committed 1 year ago

Commit 65cc0e2a ("global: Move remaining CONFIG_SYS_* to CFG_SYS_*")
renamed CONFIG_SYS_UBOOT_START to CFG_SYS_UBOOT_START. Unfortunately,
this meant that the value was no longer available to the Makefile. This
caused imxrt to fail to boot. All the other boards that used this
variable were unaffected because they were using the default value
which is CONFIG_TEXT_BASE.

This commit converts CFG_SYS_UBOOT_START to Kconfig and sets the default
value to CONFIG_TEXT_BASE.

Suggested-by: Marek Vasut <marek.vasut+renesas@gmail.com>
Suggested-by: Tom Rini <trini@konsulko.com>
Signed-off-by: Jesse Taube <Mr.Bossman075@gmail.com>
Reviewed-by: Tom Rini <trini@konsulko.com>
Reviewed-by: Simon Glass <sjg@chromium.org>

Simon Glass authored 1 year ago and Tom Rini committed 1 year ago

These don't relate to booting. Move them out of there and into the same
place as the other related settings.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>

Simon Glass authored 1 year ago and Tom Rini committed 1 year ago

This is perhaps not a commonly used feature so should not have its own
option in the main menu. Move it under general setup.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>

Add SPL version of SYS_MALLOC_CLEAR_ON_INIT, this would help devices
that need to clear ram before use to work correctly.

Signed-off-by: Bo Gan <ganboing@gmail.com>
Signed-off-by: Shengyu Qu <wiagn233@outlook.com>
Reviewed-by: Tom Rini <trini@konsulko.com>

Heinrich Schuchardt authored 1 year ago and Tom Rini committed 1 year ago

CONFIG_$(SPL_TPL_)SYS_MALLOC_F_LEN is defined as hex. If set to zero
manually, .config contains '0x0' and not '0' as value.

The default value for CONFIG_SPL_SYS_MALLOC_F_LEN should not be set to 0
but to 0x0 if CONFIG_SPL_FRAMEWORK=n to match a manually set value.

Fixes: c0126bd8 ("spl: Support bootstage, log, hash and early malloc in TPL")
Fixes: b6169470 ("SPL: Do not enable SPL_SYS_MALLOC_SIMPLE without SPL_FRAMEWORK by default")
Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
Reviewed-by: Tom Rini <trini@konsulko.com>

Johan Jonker authored 2 years ago and Kever Yang committed 1 year ago

The DT specification supports CPUs with both 32-bit and 64-bit addressing
capabilities. In U-boot the fdt_addr_t and phys_addr_t size are coupled
by a typedef. The MTD NAND drivers for 32-bit CPU's can describe partitions
with a 64-bit reg property. These partitions synced from Linux end up with
the wrong offset and sizes when only the lower 32-bit is passed.
Decouple the fdt_addr_t and phys_addr_t size as they don't necessary
match.

Signed-off-by: Johan Jonker <jbx6244@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Kever Yang <kever.yang@rock-chips.com>

Samuel Holland authored 2 years ago and André Przywara committed 1 year ago

ARCH_SUNXI selects BINMAN, so the condition "!BINMAN && ARCH_SUNXI"
is impossible to satisfy.

Signed-off-by: Samuel Holland <samuel@sholland.org>
Acked-by: Andre Przywara <andre.przywara@arm.com>
Signed-off-by: Andre Przywara <andre.przywara@arm.com>

Michal Simek authored 1 year ago and Tom Rini committed 1 year ago

U-Boot currently implements hypervisor calls only for ARM64 that's why add
dependency on ARM64. The hardware functionality is also available on
ARMv7a, but currently not supported by U-Boot, hence it is not added to the
list of dependencies here.

Signed-off-by: Michal Simek <michal.simek@amd.com>

Michal Simek authored 1 year ago and Tom Rini committed 1 year ago

XEN config can be enabled by other platforms (even it doesn't need to make
sense) that's why fix dependencies. XEN (xenbus.c) requires sscanf (also
pvblock needs it). And PVBLOCK is inside drivers/xen folder which requires
XEN to be enabled.

Signed-off-by: Michal Simek <michal.simek@amd.com>
Reviewed-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>

This adds R-Car Generation 4 (Gen4) support as Renesas ARM64 SoC.

In this version, reusing R-Car Gen3 lowlevel initialize routine [1]
and R-Car Gen3 memory map tables [2] .

[1] arch/arm/mach-rmobile/lowlevel_init_gen3.S
[2] arch/arm/mach-rmobile/memmap-gen3.c

Reviewed-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
Signed-off-by: Hai Pham <hai.pham.ud@renesas.com>
Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
[Marek: - Enable DTO support by default
        - Sort the Kconfig lists
	- Select RCAR_64 Kconfig option to pull in all the shared
	  Kconfig options with Gen3, and use where applicable to
	  deduplicate entries.
	- Fix reference [2] typo in commit message
	- Drop config options moved to Kconfig, rename rest to CFG_
	  accordingly to synchronize with upstream changes. Drop
	  removed CONFIG_VERY_BIG_RAM.
        - Move board size limit to arch/Kconfig
	- Move GICR_BASE to headers instead of common config]

Heinrich Schuchardt authored 2 years ago and Tom Rini committed 1 year ago

Kconfig settings that are related to the API for standalone applications
should be in the API sub-menu and not on the top level.

CONFIG_STANDALONE_LOAD_ADDR is only relevant if standalone example
applications are built.

Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>

Marek Vasut authored 2 years ago and Tom Rini committed 1 year ago

Sort the defaults list in BUILD_TARGET Kconfig option. No functional change.

Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
Reviewed-by: Simon Glass <sjg@chromium.org>

Simon Glass authored 2 years ago and Tom Rini committed 1 year ago

This relates to booting so move it in to that Kconfig file, before
changing it.

Signed-off-by: Simon Glass <sjg@chromium.org>

This contributor prefers not to receive mails authored 2 years ago and Tom Rini committed 2 years ago

Final U-Boot binary for mpc85xx boards which use SPL and are not PBL-based
based is u-boot-with-spl.bin. PBL is not used only on boards with e500v1
and e500v2 cores. Apparently CONFIG_E500 is set not only for e500 cores,
but also for all other mpc85xx cores e500mc, e5500 and e5600. So do not use
CONFIG_E500 and instead filter new cores with PBL based bootrom.

Signed-off-by: Pali Rohár <pali@kernel.org>

This contributor prefers not to receive mails authored 2 years ago and Tom Rini committed 2 years ago

u-boot-with-spl.kwb is built only for SPL enabled 32-bit armada boards.
u-boot.kwb is built for 32-bit armada and kirkwood boards but only for
non-SPL targets.

So replace CONFIG_ARCH_MVEBU by CONFIG_ARMADA_32BIT (it implies
CONFIG_ARCH_MVEBU) for u-boot-with-spl.kwb.

And add additional CONFIG_ARMADA_32BIT && !CONFIG_SPL for u-boot.kwb.

Signed-off-by: Pali Rohár <pali@kernel.org>

Commit 08574ed3 ("Convert CONFIG_SYS_MONITOR_LEN to Kconfig") moved
the definition of said config variable from the common sunxi header to
*every board's* defconfig.
This is a platform choice, not board specific, so remove the variable
from there, instead set the one value for all Allwinner boards in
Kconfig.

Signed-off-by: Andre Przywara <andre.przywara@arm.com>
Acked-by: Jernej Skrabec <jernej.skrabec@gmail.com>

The rest of the unmigrated CONFIG symbols in the CONFIG_SYS namespace do
not easily transition to Kconfig. In many cases they likely should come
from the device tree instead. Move these out of CONFIG namespace and in
to CFG namespace.

Signed-off-by: Tom Rini <trini@konsulko.com>
Reviewed-by: Simon Glass <sjg@chromium.org>

This converts the following to Kconfig:
   CONFIG_SYS_MONITOR_LEN

To do this, we set a default of 0 for everyone because there are a
number of cases where we define CONFIG_SYS_MONITOR_LEN but the only
impact is that we set TOTAL_MALLOC_LEN to be CONFIG_SYS_MALLOC_LEN +
CONFIG_ENV_SIZE, so we must continue to allow all boards to set this
value. Update the SPL code to use 200 KB as the default raw U-Boot size
directly, if we don't have a real CONFIG_SYS_MONITOR_LEN value.

Signed-off-by: Tom Rini <trini@konsulko.com>
Reviewed-by: Simon Glass <sjg@chromium.org>

This contributor prefers not to receive mails authored 2 years ago and Stefan Roese committed 2 years ago

File name with pattern u-boot-spl* is used on all places except in kwb
image for binary with SPL-only code. Combined binary with both SPL and
proper U-Boot in other places has file name pattern u-boot-with-spl*.

Make it consistent also for kwb image and rename u-boot-spl.kwb to
u-boot-with-spl.kwb as this image contains both SPL and proper U-Boot code.

Also update documentation about file name changes.

Signed-off-by: Pali Rohár <pali@kernel.org>
Reviewed-by: Stefan Roese <sr@denx.de>

Simon Glass authored 2 years ago and Tom Rini committed 2 years ago

The current name is inconsistent with SPL which uses CONFIG_SPL_TEXT_BASE
and this makes it imposible to use CONFIG_VAL().

Rename it to resolve this problem.

Signed-off-by: Simon Glass <sjg@chromium.org>

Traditionally we assumed that every Allwinner board would come with at
least 256 MB of DRAM, and set our DRAM layout accordingly. This affected
both the default load addresses, but also U-Boot's own address
expectations (like being loaded at 160 MB).

Some SoCs come with co-packaged DRAM, but only provide 32 or 64MB. So
far we special-cased those *chips*, as there was only one chip per DRAM
size. However new chips force us to take a more general approach.

Introduce a Kconfig symbol, which provides the minimum DRAM size of the
board. If nothing else is specified, we use 256 MB, and default to
smaller values for those co-packaged SoCs.
Then select the different DRAM maps according to this new symbol, so
that different SoCs with the same DRAM size can share those definitions.

Inspired by an idea from Icenowy.

This is just refactoring: compiled for all boards before and after this
patch: the binaries were identical.

Signed-off-by: Andre Przywara <andre.przywara@arm.com>
Reviewed-by: Jernej Skrabec <jernej.skrabec@gmail.com>

Versal NET platform is based on Versal chip which is reusing a lot of IPs.
For more information about new IPs please take a look at DT which describe
currently supported devices.
The patch is adding architecture and board support with soc detection
algorithm. Generic setting should be very similar to Versal but it will
likely diverge in longer run.

Signed-off-by: Michal Simek <michal.simek@amd.com>
Link: https://lore.kernel.org/r/320206853dc370ce290a4e7b6d0bb26b05206021.1663589964.git.michal.simek@amd.com

Peng Fan authored 2 years ago and Stefano Babic committed 2 years ago

"alloc space exhausted" happens in very early stage, which could be seen
with DEBUG_UART options enabled and leeds to an non-functional board.

kontron_pitx_imx8m:
CONFIG_DEBUG_UART_BASE=0x30880000   # for serial3
CONFIG_DEBUG_UART_CLOCK=24000000

imx8mqevk:
CONFIG_DEBUG_UART_BASE=0x30860000      # for uart1
CONFIG_DEBUG_UART_CLOCK=24000000

It is because CONFIG_SYS_MALLOC_F_LEN is too small and still leave
CONFIG_SPL_SYS_MALLOC_F_LEN as 0x2000.

Reported-by: Heiko Thiery <heiko.thiery@gmail.com>
Signed-off-by: Peng Fan <peng.fan@nxp.com>
Reviewed-by: Heiko Thiery <heiko.thiery@gmail.com>
Tested-by: Heiko Thiery <heiko.thiery@gmail.com>
Reviewed-by: Fabio Estevam <festevam@denx.de>

Andrew Scull authored 2 years ago and Tom Rini committed 2 years ago

Add the basic infrastructure for declaring fuzz tests and a command to
invoke them.

Signed-off-by: Andrew Scull <ascull@google.com>
Reviewed-by: Simon Glass <sjg@chromium.org>

Andrew Scull authored 2 years ago and Tom Rini committed 2 years ago

Add CONFIG_ASAN to build with the Address Sanitizer. This only works
with the sandbox so the config is likewise dependent. The resulting
executable will have ASAN instrumentation, including the leak detector
that can be disabled with the ASAN_OPTIONS environment variable:

   ASAN_OPTIONS=detect_leaks=0 ./u-boot

Since u-boot uses its own dlmalloc, dynamic allocations aren't
automatically instrumented, but stack variables and globals are.

Instrumentation could be added to dlmalloc to poison and unpoison memory
as it is allocated and deallocated, and to introduce redzones between
allocations. Alternatively, the sandbox may be able to play games with
the system allocator and somehow still keep the required memory
abstraction. No effort to address dynamic allocation is made by this
patch.

The config is not yet enabled for any targets by default.

Signed-off-by: Andrew Scull <ascull@google.com>
Reviewed-by: Simon Glass <sjg@chromium.org>

- Make all users of CUSTOM_SYS_INIT_SP_ADDR reference SYS_INIT_SP_ADDR
- Introduce HAS_CUSTOM_SYS_INIT_SP_ADDR to allow for setting the stack
  pointer directly, otherwise we use the common calculation.
- On some platforms that were using the standard calculation but did not
  set CONFIG_SYS_INIT_RAM_SIZE / CONFIG_SYS_INIT_RAM_ADDR, set them.
- On a small number of platforms that were not subtracting
  GENERATED_GBL_DATA_SIZE do so now via the standard calculation.
- CONFIG_SYS_INIT_SP_OFFSET is now widely unused, so remove it from most
  board config header files.

Signed-off-by: Tom Rini <trini@konsulko.com>

This converts the following to Kconfig:
   CONFIG_SYS_BARGSIZE

Signed-off-by: Tom Rini <trini@konsulko.com>

Sean Anderson authored 2 years ago and Heinrich Schuchardt committed 2 years ago

There are no defined instruction sequences in include/valgrind.h for
Risc-V, so CONFIG_VALGRIND will do nothing on this arch (and possibly won't
compile?). Update Kconfig accordingly.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Reviewed-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>

Sean Anderson authored 2 years ago and Tom Rini committed 2 years ago

SPL_SYS_MALLOC_F_LEN defaults to SYS_MALLOC_F_LEN. 0x10000 is 64 KiB, or
around half of the total OCRAM size. Revert to the default of 0x2000. This
fixes SPL boot.

Fixes: 545eceb5 ("imx8/ls10xx: Use a sane SYS_MALLOC_F_LEN default")
Signed-off-by: Sean Anderson <sean.anderson@seco.com>
Reviewed-by: Fabio Estevam <festevam@denx.de>

Simon Glass authored 2 years ago and Tom Rini committed 2 years ago

Add VPL versions of commonly used Kconfig options.

Signed-off-by: Simon Glass <sjg@chromium.org>

This contributor prefers not to receive mails authored 2 years ago and Tom Rini committed 2 years ago

On P2020 board is SPL malloc simple always failing with error and loops:

  SD boot...
  alloc space exhausted
  Bad trap at PC: f8f8b5f0, SR: 21200, vector=d00
  NIP: 00000000 XER: 00000000 LR: 00000000 REGS: f8f8b5f0 TRAP: 20000000 DAR: 00000000
  MSR: 00021200 EE: 0 PR: 0 FP: 0 ME: 1 IR/DR: 00

  GPR00: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
  GPR08: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
  GPR16: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
  GPR24: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
  Call backtrace:
  Exception in kernel pc f8f8b5f0 signal 0

Inspection showed that gd->malloc_limit is zero. And it is because
generally SPL_FRAMEWORK initialize SPL's gd->malloc_limit. But when
SPL_FRAMEWORK is not enabled then in most cases nobody initialize
gd->malloc_limit and so SPL malloc simple does not work.

So disable SPL_SYS_MALLOC_SIMPLE by default when SPL_FRAMEWORK is not
enabled. SPL_SYS_MALLOC_SIMPLE can be disabled only by setting
SPL_SYS_MALLOC_F_LEN to zero. So do it.

This change fixes SPL error "alloc space exhausted" on P2020 board.

Signed-off-by: Pali Rohár <pali@kernel.org>

A number of platforms here had already been increasing the size a bit,
so lets moving all of them up.

Signed-off-by: Tom Rini <trini@konsulko.com>