Tom Rini [Tue, 3 May 2022 12:30:14 +0000 (08:30 -0400)]
CI: Azure: Rework how we update MSYS2
Based on reading https://www.msys2.org/docs/ci/ and "Other Systems"
rework how we update MSYS2 to the current version. We run it once, to
perform nothing other than being the first run, then we run pacman
twice.
U-Boot provides a verified-boot feature based around FIT, but there is
no standard way of implementing it for a board. At present the various
required pieces must be built up separately, to produce a working
implementation. In particular, there is no built-in support for selecting
A/B boot or recovery mode.
This series introduces VPL, a verified program loader phase for U-Boot.
Its purpose is to run the verified-boot process and decide which SPL
binary should be run. It is critical that this decision happens before
SPL runs, since SPL sets up SDRAM and we need to be able to update the
SDRAM-init code in the field.
Adding VPL into the boot flow provides a standard place to implement
verified boot. This series includes the phase itself, some useful Kconfig
options and a sandbox_vpl build for sandbox. No verfied-boot support is
provided in this series.
Most of the patches in this series are fixes and improvements to docs and
various Kconfig conditions for SPL.
Simon Glass [Sat, 30 Apr 2022 06:56:52 +0000 (00:56 -0600)]
Introduce Verifying Program Loader (VPL)
Add support for VPL, a new phase of U-Boot. This runs after TPL. It is
responsible for selecting which SPL binary to run, based on a
verified-boot process.
Simon Glass [Sat, 30 Apr 2022 06:56:50 +0000 (00:56 -0600)]
Makefile: Simplify devicetree rules for SPL/TPL
The current logic checks several options to decide whether SPL/TPL need
the U-Boot devicetree to be built. In fact we can check OF_CONTROL, which
is enabled in all cases that matter.
Chris Packham [Mon, 2 May 2022 03:16:25 +0000 (15:16 +1200)]
ARM: mvebu: x530: set MPP55 to gpio
MPP55 is used as a reset connected to the L3 switch chip. This doesn't
matter for u-boot as it doesn't use the L3 switch but it is useful to
be able to toggle the switch in/out of reset for the OS.
Signed-off-by: Chris Packham <judge.packham@gmail.com> Reviewed-by: Stefan Roese <sr@denx.de>
This command is useful in U-boot scripts and it is being used by
OpenWrt bootscript for this board [1]. Otherwise shell scripting
commands are enabled by default in cmd/Kconfig.
Tony Dinh [Sun, 17 Apr 2022 20:42:42 +0000 (13:42 -0700)]
arm: kirkwood: nsa310s: Use Marvell uclass mvgbe and PHY driver for DM Ethernet
The Zyxel NSA310s board has the network chip Marvell Alaska 88E1318S.
Use uclass mvgbe and the compatible driver M88E1310 driver to bring
up Ethernet.
- Use uclass mvgbe to bring up the network. And remove ad-hoc code.
- Remove CONFIG_RESET_PHY_R.
- Enable CONFIG_PHY_MARVELL to properly configure the network.
- Add phy mode RGMII to kirkwood-nsa310s.dts
- Miscellaneous changes: Move constants to .c file and remove header file
board/zyxel/nsa310s/nsa310s.h, add support for large USB and SATA HDDs,
use BIT macro, add/cleanup comments, and cosmetic changes.
Note that this patch is depended on the following patch:
https://patchwork.ozlabs.org/project/uboot/patch/20220412201820.10291-1-mibodhi@gmail.com/
Tony Dinh [Tue, 12 Apr 2022 20:18:19 +0000 (13:18 -0700)]
net: marvell: mvgbe: Set PHY page 0 before phy_connect
For most Kirkwood boards, the PHY page is already set to page 0
(in register 22) before phy_connect is invoked. But some board like
the Zyxel NSA310S (which uses the network chip MV88E1318S), the PHY page
is not set to page 0. There seems to be some bad data remained in
register 22 when the uclass MVGBE about to invoke phy_connect().
This patch enables the uclass MVGBE to always set the PHY page to 0
before phy_connect.
For reference, please see this discussion:
[RFC PATCH v2] arm: kirkwood: nsa310s: Use Marvell uclass mvgbe
and PHY driver for DM Ethernet.
https://lists.denx.de/pipermail/u-boot/2022-April/480946.html
This patch has been tested with the following Kirkwood boards:
Pali Rohár [Wed, 2 Mar 2022 11:47:58 +0000 (12:47 +0100)]
arm: mvebu: turris_omnia: Add support for USB3.0 mode in WWAN MiniPCIe slot
PCIe Mini CEM 2.1 spec added support for USB3.0 mode on MiniPCIe cards.
USB3.0 and PCIe share same pins and only one function can be active at the
same time. PCIe Mini CEM 2.1 spec says that determining function is
platform specific and spec does not define any dedicated pin which could
say if card is USB3.0-based or PCIe-based.
Implement this platform specific decision (USB3.0 vs PCIe) for WWAN
MiniPCIe slot on Turris Omnia via U-Boot env variable "omnia_wwan_slot",
similarly like is implemented forced mode for MiniPCIe/mSATA slot via
"omnia_msata_slot" env variable. Value "usb3" for "omnia_wwan_slot" would
mean to set USB3.0 mode and value "pcie" original PCIe mode.
A385 SoC on Turris Omnia has configurable fifth SerDes line (exported to
MiniPCIe WWAN slot with SIM card) either to USB3.0 or PCIe functionality,
so implementation of this new PCIe Mini CEM 2.1 feature is simple, by just
configuring SerDes to USB 3.0 mode.
Other twos MiniPCIe slots on Turris Omnia do not have this new
functionality as their SerDes lines cannot be switched to USB3.0
functionality.
Note that A385 SoC does not have too many USB3.0 blocks, so activating
USB3.0 in MiniPCIe cause that one external USB3.0 USB-A port would loose
USB3.0 functionality and would be downgraded just to USB2.0.
By default this MiniPCIe WWAN slot is in PCIe mode, like before.
To set this MiniPCIe WWAN slot to USB3.0 mode, call U-Boot commands:
Pali Rohár [Wed, 2 Mar 2022 11:47:57 +0000 (12:47 +0100)]
arm: mvebu: turris_omnia: Signal error when sata/pcie DT mode
Show error message when DT file does not contain sata or pcie node which
should be explicitly disabled. This can happen when U-Boot code for finding
those nodes is incomplete or when those DT nodes are in different
unexpected location. In any case it is needed to know if DT not was not
explicitly disabled as it could mean that combo slots where setup
incorrectly.
Pali Rohár [Wed, 2 Mar 2022 11:47:55 +0000 (12:47 +0100)]
arm: mvebu: turris_omnia: Allow to configure mSATA slot via env variable
Some PCIe-based MiniPCIe cards are broken and they do not ground PIN 43
which is required by PCIe mini CEM specs. Such broken cards are incorrectly
detected as mSATA cards because SATA specs requires that PIN 43 on mSATA
cards has to be disconnected.
PIN 43 on Turris Omnia is used only for MiniPCIe/mSATA card detection by
software in U-Boot SPL. Allow to override that U-Boot SPL detection by a
new "omnia_msata_slot" env variable (to value "pcie" or "sata") so broken
MiniPCIe cards can be used in combo mSATA/MiniPCIe slot too.
As configuration of PCIe vs SATA functionality is done in U-Boot SPL,
it is required to change env variable in permanent storage and reset the
board to take effect.
To force PCIe mode for broken MiniPCIe cards, call U-Boot commands:
Pali Rohár [Wed, 2 Mar 2022 11:47:52 +0000 (12:47 +0100)]
arm: mvebu: turris_omnia: Provide env_sf_get_env_addr() function
BootROM maps SPI Flash to fixed address 0xD4000000 and this mapping is
active also when BootROM is executing binary kwbimage headers, which
includes also U-Boot SPL.
Therefore no initialization code is required to access SPI Flags from
U-Boot SPL. In proper U-Boot it is remapped to other location.
So in mvebu implementation of env_sf_get_env_addr() function returns
0xD4000000 when running in SPL and NULL when in proper U-Boot.
This change would allow to use U-Boot ENV in U-Boot SPL. Normally it is not
possible to read ENV because it is too big and U-Boot SPL does not have
such big malloc() pool to real all ENV variables.
Signed-off-by: Pali Rohár <pali@kernel.org> Reviewed-by: Marek Behún <marek.behun@nic.cz>
Pali Rohár [Wed, 2 Mar 2022 11:47:51 +0000 (12:47 +0100)]
env: sf: Allow to use env_sf_init_addr() at any stage
In some cases it makes sense to use env_sf_init_addr() also in SPL mode.
Allow it for boards by providing custom implementation of weak function
env_sf_get_env_addr(). When this function returns NULL it signals that
address is invalid, like config option CONFIG_ENV_ADDR.
There is no change in default behavior or in config options.
Tom Rini [Fri, 29 Apr 2022 18:04:08 +0000 (14:04 -0400)]
Merge tag 'efi-2022-07-rc2' of https://source.denx.de/u-boot/custodians/u-boot-efi
Pull request for efi-2022-07-rc2
UEFI:
* fix UEFI booting after integration of UEFI sub-system with driver model
* avoid random return values from devpath_is_partition()
* minor code clean ups
Tom Rini [Fri, 29 Apr 2022 15:25:06 +0000 (11:25 -0400)]
Merge branch '2022-04-29-fuzzing-and-asan-fixes'
To quote the author:
I've been experimenting with ASAN on sandbox and turned up a few issues
that are fixed in this series.
Basic ASAN was easy to turn on, but integrating with dlmalloc was
messier and fairly intrusive. Even when I had it working, there was only
a small redzone between allocations which limits the usefulness.
I saw another series on the list by Sean Anderson to enable valgrind
which was finding a different set of issues, though there was one
overlap that Sean is fixing with
"[PATCH] IOMUX: Fix access past end of console_devices".
With these issues fixed, I was able to run the dm tests without any ASAN
issues. There are a couple of leaks reported at the end, but that's for
another day.
Andrew Scull [Sun, 3 Apr 2022 10:39:14 +0000 (10:39 +0000)]
test: Fix pointer overrun in dm_test_devm_regmap()
This tests calls regmap_read() which takes a uint pointer as an output
parameter. The test was passing a pointer to a u16 which resulted in an
overflow when the output was written. Fix this by following the
regmap_read() API and passing a uint pointer instead.
Signed-off-by: Andrew Scull <ascull@google.com> Cc: Simon Glass <sjg@chromium.org> Cc: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Jean-Jacques Hiblot <jjhiblot@ti.com> Cc: Pratyush Yadav <p.yadav@ti.com> Reviewed-by: Simon Glass <sjg@chromium.org>
Andrew Scull [Sun, 3 Apr 2022 10:39:13 +0000 (10:39 +0000)]
sound: Fix buffer overflow in square wave generation
Data is written for each channel but is only tracked as having one
channel written. This resulted in a buffer overflow and corruption of
the allocator's metadata which caused further problems when the buffer
was later freed. This could be observed with sandbox unit tests.
Resolve the overflow by tracking the writes for each channel.
Fixes: f987177db9 ("dm: sound: Use the correct number of channels for sound") Signed-off-by: Andrew Scull <ascull@google.com> Cc: Simon Glass <sjg@chromium.org> Reviewed-by: Simon Glass <sjg@chromium.org>
Andrew Scull [Sun, 3 Apr 2022 10:39:12 +0000 (10:39 +0000)]
usb: sandbox: Bounds check read from buffer
The buffer is 512 bytes but read requests can be 800 bytes. Limit the
request to the size of the buffer.
Signed-off-by: Andrew Scull <ascull@google.com> Cc: Simon Glass <sjg@chromium.org> Cc: Marek Vasut <marex@denx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
Andrew Scull [Sun, 3 Apr 2022 10:39:11 +0000 (10:39 +0000)]
usb: sandbox: Check for string end in copy_to_unicode()
When copying the string in copy_to_unicode(), check for the null
terminator in each position, not just at the start, to avoid reading
beyond the end of the string.
Signed-off-by: Andrew Scull <ascull@google.com> Cc: Simon Glass <sjg@chromium.org> Cc: Marek Vasut <marex@denx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
Andrew Scull [Sun, 3 Apr 2022 10:39:10 +0000 (10:39 +0000)]
x86: sandbox: Add missing PCI bar to barinfo
There are expecte to be bars 0 through 5, but the last of these was
missing leading to an read beyond the buffer. Add the missing element
with zero values.
Signed-off-by: Andrew Scull <ascull@google.com> Cc: Simon Glass <sjg@chromium.org> Cc: Bin Meng <bmeng.cn@gmail.com> Reviewed-by: Simon Glass <sjg@chromium.org>
Andrew Scull [Sun, 3 Apr 2022 10:39:09 +0000 (10:39 +0000)]
acpi: Fix buffer overflow in do_acpi_dump()
When do_acpi_dump() converts the table name to upper case, pass the
actual size of the output buffer so that the null terminator doesn't get
written beyond the end of the buffer.
Signed-off-by: Andrew Scull <ascull@google.com> Cc: Simon Glass <sjg@chromium.org> Cc: Wolfgang Wallner <wolfgang.wallner@br-automation.com> Cc: Bin Meng <bmeng.cn@gmail.com> Reviewed-by: Simon Glass <sjg@chromium.org>
Andrew Scull [Sun, 3 Apr 2022 10:39:08 +0000 (10:39 +0000)]
doc: Correct position of gdb '--args' parameter
The '--args' parameter to gdb comes before the binary that the debugger
will be attached to rather than after the binary and before the
arguments. Fix that in the docs.
Signed-off-by: Andrew Scull <ascull@google.com> Cc: Simon Glass <sjg@chromium.org> Reviewed-by: Simon Glass <sjg@chromium.org>
efi_loader: disk: allow blk devices even without UCLASS_PARTITION
While GPT partition is mandated in UEFI specification, CONFIG_PARTITION is
seen optional under the current implementation.
So modify efi_disk_rw_blocks() to allow accepting UCLASS_BLK devices.
Fixes: commit d97e98c887ed ("efi_loader: disk: use udevice instead of blk_desc") Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Mark Kettenis <kettenis@openbsd.org>
Marek Vasut [Mon, 25 Apr 2022 16:33:51 +0000 (18:33 +0200)]
test: dm: pinmux: Get LED2 udevice in the pinmux test
The UT reinitializes the pin controller state, get LED2 udevice
to trigger its probe and configure the pin controller pin state
as it is expected by the test.
Signed-off-by: Marek Vasut <marex@denx.de> Cc: Patrice Chotard <patrice.chotard@foss.st.com> Cc: Patrick Delaunay <patrick.delaunay@foss.st.com> Cc: Sean Anderson <seanga2@gmail.com> Cc: Simon Glass <sjg@chromium.org> Cc: Steven Lawrance <steven.lawrance@softathome.com>
Marek Vasut [Mon, 25 Apr 2022 16:33:50 +0000 (18:33 +0200)]
test: dm: led: Fix LED enumeration
The GPIO LED driver no longer considers the top level node an LED,
because it is not an LED. With this bug fixed, the LED enumeration
has changed. Update the test accordingly.
Signed-off-by: Marek Vasut <marex@denx.de> Cc: Patrice Chotard <patrice.chotard@foss.st.com> Cc: Patrick Delaunay <patrick.delaunay@foss.st.com> Cc: Sean Anderson <seanga2@gmail.com> Cc: Simon Glass <sjg@chromium.org> Cc: Steven Lawrance <steven.lawrance@softathome.com>
Marek Vasut [Fri, 22 Apr 2022 13:41:42 +0000 (15:41 +0200)]
led: Drop led_default_state()
This function is empty, drop it.
Signed-off-by: Marek Vasut <marex@denx.de> Cc: Patrice Chotard <patrice.chotard@foss.st.com> Cc: Patrick Delaunay <patrick.delaunay@foss.st.com> Cc: Sean Anderson <seanga2@gmail.com> Cc: Simon Glass <sjg@chromium.org> Cc: Steven Lawrance <steven.lawrance@softathome.com> Reviewed-by: Patrice Chotard <patrice.chotard@foss.st.com>
Marek Vasut [Fri, 22 Apr 2022 13:34:00 +0000 (15:34 +0200)]
led: gpio: Use NOP uclass driver for top-level node
The top level DT node of gpio-leds is not a LED itself, bind NOP uclass
driver to it, and bind different LED uclass driver to its subnodes which
represent the actual LEDs. This simplifies the probe() implementation
and fixes the bogus top-level not-an-LED in 'led list' command output:
```
=> led list
led Error -121 <--- This is removed/fixed by this patch
green:user0 off
```
Signed-off-by: Marek Vasut <marex@denx.de> Cc: Patrice Chotard <patrice.chotard@foss.st.com> Cc: Patrick Delaunay <patrick.delaunay@foss.st.com> Cc: Sean Anderson <seanga2@gmail.com> Cc: Simon Glass <sjg@chromium.org> Cc: Steven Lawrance <steven.lawrance@softathome.com> Reviewed-by: Patrice Chotard <patrice.chotard@foss.st.com> Tested-by: Patrice Chotard <patrice.chotard@foss.st.com>
Marek Vasut [Fri, 22 Apr 2022 13:15:55 +0000 (15:15 +0200)]
led: gpio: Check device compatible string to determine the top level node
Since 2d1deaf88ed ("led: gpio: Drop duplicate OF "label" property parsing"),
all LED nodes have some sort of label. Use device_is_compatible(..."leds-gpio")
to determine whether this is a top-level node, since it is only the top
level node which is compatible with "leds-gpio", the GPIO LEDs subnodes
are not.
Fixes: 2d1deaf88ed ("led: gpio: Drop duplicate OF "label" property parsing") Signed-off-by: Marek Vasut <marex@denx.de> Cc: Patrice Chotard <patrice.chotard@foss.st.com> Cc: Patrick Delaunay <patrick.delaunay@foss.st.com> Cc: Sean Anderson <seanga2@gmail.com> Cc: Simon Glass <sjg@chromium.org> Cc: Steven Lawrance <steven.lawrance@softathome.com> Reviewed-by: Patrice Chotard <patrice.chotard@foss.st.com> Tested-by: Patrice Chotard <patrice.chotard@foss.st.com>
Marek Vasut [Fri, 22 Apr 2022 13:15:54 +0000 (15:15 +0200)]
led: Mark device instance with DM_FLAG_PROBE_AFTER_BIND
Calling device_probe() from uclass .post_bind() callback has all kinds
of odd side-effects, e.g. device instances not being available just yet.
Make use of the DM_FLAG_PROBE_AFTER_BIND instead, mark device instances
which need to be probe()d in order to configure the LED default state
with this flag and let the DM core do the device_probe() at the right
time instead.
Fixes: 72675b063b6 ("led: Configure LED default-state on boot") Signed-off-by: Marek Vasut <marex@denx.de> Cc: Patrice Chotard <patrice.chotard@foss.st.com> Cc: Patrick Delaunay <patrick.delaunay@foss.st.com> Cc: Sean Anderson <seanga2@gmail.com> Cc: Simon Glass <sjg@chromium.org> Cc: Steven Lawrance <steven.lawrance@softathome.com> Reviewed-by: Patrice Chotard <patrice.chotard@foss.st.com> Tested-by: Patrice Chotard <patrice.chotard@foss.st.com>
Marek Vasut [Fri, 22 Apr 2022 13:15:53 +0000 (15:15 +0200)]
dm: core: Add DM_FLAG_PROBE_AFTER_BIND flag
Introduce DM_FLAG_PROBE_AFTER_BIND flag, which can be set by driver or
uclass in .bind(), to indicate such driver instance should be probe()d
once binding of all devices is complete.
This is useful in case the driver determines that hardware initialization
is mandatory on boot, and such initialization happens only in probe().
This also solves the inability to call device_probe() from .bind().
Signed-off-by: Marek Vasut <marex@denx.de> Cc: Patrice Chotard <patrice.chotard@foss.st.com> Cc: Patrick Delaunay <patrick.delaunay@foss.st.com> Cc: Sean Anderson <seanga2@gmail.com> Cc: Simon Glass <sjg@chromium.org> Cc: Steven Lawrance <steven.lawrance@softathome.com> Reviewed-by: Patrice Chotard <patrice.chotard@foss.st.com> Tested-by: Patrice Chotard <patrice.chotard@foss.st.com>
Tom Rini [Tue, 26 Apr 2022 11:54:12 +0000 (07:54 -0400)]
Merge tag 'u-boot-at91-2022.07-b' of https://source.denx.de/u-boot/custodians/u-boot-at91
Second set of u-boot-at91 features for the 2022.07 cycle:
This feature set includes the new driver for the AT91 reset controller,
a new board called sam9x60 curiosity, and several other fixes and
clean-ups (sama7g5ek qspi clock, impedance; remove unused code,
introduce Kconfig symbols for SPL timers)
pci: fsl: Change compatible string for mpc8548 to "fsl, mpc8548-pcie"
Upstream Linux kernel uses for mpc8548-based PCIe controllers compatible
string "fsl,mpc8548-pcie". So change U-Boot fsl PCIe driver and all DTS
files to use "fsl,mpc8548-pcie" instead of "fsl,pcie-mpc8548" to be
compatible with Linux kernel.
powerpc: dts: p2020: Make usb@22000 node compatible for Linux kernel driver
Linux P2020 USB kernel driver uses compatible string fsl-usb2-dr-v1.6 and
needs more DT properties. Copy P2020 usb@22000 properties from upstream
Linux kernel.
powerpc: dts: p2020: Do not automatically disable spi@7000 node in p2020-post.dtsi
Device tree include file p2020-post.dtsi should be included after the board
device tree file and overrides settings of the board. So it should not
disable some node as board cannot enable it via normal way (it has to
enable it after inclusion of p2020-post.dtsi file).
Fix it by removal of explicit disable in p2020-post.dtsi file and then
remove explicit post-post enable in all P2020 board device tree files.
Currently no P2020 board has spi@7000 node disabled.
powerpc: dts: p2020: Add Linux compatible string and property for eSDHC
Linux kernel eSDHC driver for P2020 requires additional compatible string
fsl,p2020-esdhc and interrupts property. Add them to p2020-post.dtsi file
to make U-Boot board DTS files compatible for Linux kernel.
powerpc: dts: p2020: Add ptp_clock@24e00 node via pq3-etsec1-timer-0.dtsi
Import pq3-etsec1-timer-0.dtsi device tree include file from upstream Linux
kernel for P2020. This allows U-Boot to use P2020 device tree files from
upstream Linux kernel which reference ptp_clock@24e00 device.
powerpc: dts: p2020: Make PCIe nodes compatible for Linux kernel driver
Linux P2020 PCIe kernel driver uses compatible string fsl,mpc8548-pcie and
needs more DT properties. Copy P2020 PCIe nodes and definitions from
upstream Linux kernel.
powerpc: dts: p2020: Add gpio-controller@fc00 node via pq3-gpio-0.dtsi
Import pq3-gpio-0.dtsi device tree include file from upstream Linux kernel
for P2020. This allows U-Boot to use P2020 device tree files from upstream
Linux kernel which reference gpio-controller@fc00 device.
Do not stringify env $vscfw_addr two times (once implicitly via string
operator "" and second time explicitly via __stringify() macro) and allow
to compile U-Boot without CONFIG_VSC7385_ENET (when __VSCFW_ADDR was not
defined and so macro name was stringified into CONFIG_EXTRA_ENV_SETTINGS).
board: freescale: p1_p2_rdb_pc: Fix page attributes for second 1G SDRAM map
Like for first 1G SDRAM map, do not enable Caching-inhibited nor Guarded
attribute for second 1G SDRAM mapping. Whole 2G SDRAM should use caches and
also allow speculative loading (by not setting Guarded attribute).
Also enable Memory Coherency attribute for second 1G SDRAM map. In commit 316f0d0f8f3c ("powerpc: mpc85xx: Fix static TLB table for SDRAM") it was
enabled for all SDRAM maps on all other boards, just missed this one case.
As a last thing, first 1G SDRAM map has wrong comment, so adjust it.
Currently CONFIG_OF_SEPARATE is completely broken and U-Boot for some
mpc85xx board (e.g. P2020) has to be compiled with CONFIG_OF_EMBED.
Otherwise it crashes during early init.
When debug console is enabled and all debug logging options are turned on
then U-Boot on P2020 with CONFIG_OF_SEPARATE prints following error:
No valid device tree binary found at 110dc300
initcall sequence 110d3560 failed at call 1109535c (err=-1)
### ERROR ### Please RESET the board ###
Problem is with appended DTB. When CONFIG_SYS_MPC85XX_NO_RESETVEC is set
U-Boot binary image without DTB ends immediately after the .u_boot_list
section. At this position is defined _end symbol at which U-Boot expects
start of the appended DTB.
Problem is that after .u_boot_list section are in linker script defined
another sections with 256 byte long padding which are completely empty.
During conversion of U-Boot ELF binary to RAW binary u-boot-nodtb.bin,
objcopy removes trailing zero padding and therefore DTB is appended at
wrong position.
Changing alignment from 256 bytes to 4 bytes fixes this issue. And appended
DTB is finally at he correct position. With this fix U-Boot on P2020 with
CONFIG_OF_SEPARATE option starts working again.
projects / u-boot.git / log