In newer 1.2 PinePhone board revisions LIS3MDL magnetometer was replaced by
AF8133J. They use the same PB1 pin in different modes.
LIS3MDL uses it as an gpio input to handle interrupt.
AF8133J uses it as an gpio output as a reset signal.
It wasn't possible at runtime to enable both device tree
nodes and detect supported sensor at probe time.
AF8133J has reset pin (PB1) connected to the SoC. By default AF8133J
is in a reset state and don't respond to probe request on I2C
bus. Extra code would be needed to handle reset signal. Therefore this
code uses LIS3MDL magnetometer instead of AF8133J.
Introducing new dts 1.2b with AF8133J sensor would require probing in
SPL. That would lead to pulling in into SPL I2C controller driver,
RSB controller driver, introducing new AXP803 driver to power-up
sensors for probe. It's working, but SPL is pretty size-constrained on
A64 and doesn't have much space. Therefore fdt fixup is done in U-Boot
proper without introducing new board revision and new dts.
Signed-off-by: Andrey Skvortsov <andrej.skvortzov@gmail.com>
Link: https://lore.kernel.org/all/20240908214718.36316-1-andrej.skvortzov@gmail.com/
Link: https://lists.denx.de/pipermail/u-boot/2024-February/545700.html
Reviewed-by: Andre Przywara <andre.przywara@arm.com>
[Andre: fix formatting]
Signed-off-by: Andre Przywara <andre.przywara@arm.com>
pstore will allow users to catch kernel crashes and report them to
developers. Modern (Android) phones have pstore usually enabled to get
information about kernel crash, since it's the simplest way to get
kernel backtrace on mobile device without serial console. Usually it's
enabled by default in distribution kernels like Debian.
CONFIG_PSTORE=y
CONFIG_PSTORE_RAM=m
systemd has service that automatically handles pstore and saves them
in /var/lib/pstore for later usage.
In general any DRAM address, that isn't overwritten during a boot is
suitable for pstore.
Range from 0x40000000 - 0x50000000 is heavily used by u-boot for
internal use and to load kernel, fdt, fdto, scripts, pxefile and ramdisk
later in the boot process. Ramdisk start address is 0x4FF00000,
initramfs for kernel with some hacking features and debug info enabled
can take more than 100Mb and final address will be around 0x58000000.
Address 0x61000000 will most likely not overlap with that.
Signed-off-by: Andrey Skvortsov <andrej.skvortzov@gmail.com>
Reviewed-by: Andre Przywara <andre.przywara@arm.com>
So far all sunxi boards programming the DCDC1 power rail on the AXP PMIC
also set the DCDC5 rail, so we could handle both with the same DCDC1
guard.
Some boards using the AXP313 will need to set DCDC1 now as well, and
since the AXP313 only has three buck converters, there will be no DCDC5,
so this trick is not going to work anymore.
Don't try to be too clever, and just protect programming the two DCDC
rails with two separate guards.
This has the interesting side effect of fixing operation on A80 boards,
using the AXP809 PMIC. Apparently programming DCDC5 right after DCDC1,
but before the other three rails caused some glitch, which made the board
hang during Linux boot, during the PSCI handler in U-Boot. Just keeping
the old setup order (DCDC1,2,3,4,5) will make those boards boot to the
Linux prompt again.
Fixes: ffb02942fa ("sunxi: board: simplify early PMIC setup conditions")
Signed-off-by: Andre Przywara <andre.przywara@arm.com>
Reviewed-by: Chen-Yu Tsai <wens@csie.org>
The H616 DRAM controller requires some board specific parameters, which
we declare in Kconfig, let each board specify in their defconfig, and
then use in the DRAM init code.
Other DRAM controllers now require a very similar, if not identical
parameter set, with so far the same parameter names used.
To help keep the Kconfig file at bay, rename the existing parameter
names to drop the H616_ part in there, to make them more naturally
reusable for other SoCs.
No functional change, just a rename.
Signed-off-by: Andre Przywara <andre.przywara@arm.com>
Reviewed-by: Jernej Skrabec <jernej.skrabec@gmail.com>
With each new SoC added to the clock_sun50i_h6.h header file, we add a
list of default values for the bus clock registers. This list gets a bit
hard to read, as the spacing between the lines looks confusing.
Tighten the lines by removing empty lines, to make it more obvious which
values belong together. Also remove those comments that were more or
less duplicating the next code line, and didn't add any information.
This makes it easier to find existing values and to add support for new
SoCs.
Signed-off-by: Andre Przywara <andre.przywara@arm.com>
Reviewed-by: Jernej Skrabec <jernej.skrabec@gmail.com>
Use this function instead of fit_image_get_emb_data() data, since it
works will FITs that use external data.
Signed-off-by: Simon Glass <sjg@chromium.org>
This function is really just getting the data. The size comes along for
the ride. In fact this function is only reliable way to obtain the data
for an image in a FIT, since the FIT may use external data.
Rename it to fit_image_get_data()
Signed-off-by: Simon Glass <sjg@chromium.org>
This function can only be used with FITs that use embedded data. Rename
it so this is clear.
Signed-off-by: Simon Glass <sjg@chromium.org>
Acked-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Update ofnode_add_subnode() and ofnode_add_prop() to return a suitable
error when space is exhausted in the FDT. This makes it easier to see
what is going wrong.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>
At some point it would be nice to have the ofnode API automatically
expand the tree as required, to accommodate new nodes. For now, expand
the default size so that UPL can be supported.
Signed-off-by: Simon Glass <sjg@chromium.org>
Update the version of this function in mkimage so that it uses a const
pointer, as is done in the mapmem.h header file.
Signed-off-by: Simon Glass <sjg@chromium.org>
Some header files included on the host are moving to use abuf, so adjust
the header-inclusion to bring in size_t correctly.
Signed-off-by: Simon Glass <sjg@chromium.org>
In many cases it is useful to get the address of a buffer, e.g. when
booting from it. Add a function to handle this.
Signed-off-by: Simon Glass <sjg@chromium.org>
We want to encourage people to use an allocated bloblist since it is
more flexible than a fixed one. Make this the default, being sure not to
change existing users.
The unit tests require BLOBLIST_FIXED so add a dependency in the
Makefile to avoid build errors.
All sandbox builds require BLOBLIST_FIXED so make that the default for
sandbox.
Signed-off-by: Simon Glass <sjg@chromium.org>
The highlights are:
* Fixed boot regression due to broken memory parsing
* Enable HW RNG and KASLR on all platforms
* Add support for Snapdragon X1 Elite hardware (clk/pinctrl)
* Add support for QCS9100 ride automotive development platform (clk/ufs)
* Add support for PCIe on SM8550, SM8650 and X1E
* Implement software debounce for PMIC buttons
Additionally, some minor improvements to "ufetch" have been pulled in:
* Show CPU architecture (arm/mips/etc)
* Make CONFIG_BLK optional
* Fix 32-bit support
Simon Glass <sjg@chromium.org> says:
This includes various patches towards implementing the VBE abrec
bootmeth in U-Boot. It mostly focuses on introducing a relocating
SPL-loader so that VBE can run in the limited amount of SRAM available
on many devices.
Another minor new feature is support in VBE for specifying the image
phase when loading from a FIT. This allows a single FIT to include
images for several boot phases, thus simplifying image-creation.
One lingering niggle in this series is that it has a different code path
for sandbox, since it does not support the relocating jump. It should be
possible to resolve this with additional work, but I have not attempted
this so far.
For v2, I have split the first patch into 5 pieces, to make it easier to
see the code-size impact, plus added a few tweaks to reduce code size.
Again, only MMC is supported so far.
Looking ahead, series G will have some more plumbing and H some rk3399
pieces. That should be enough to complete these feature.
Here is a run in my lab, with the VBE ABrec bootmeth. You can see that
VPL runs before memory is set up. SPL sets up memory and can be upgraded
in the field reliably.
$ ub-int vbe
Building U-Boot in sourcedir for rk3399-generic
Bootstrapping U-Boot from dir /tmp/b/rk3399-generic
Writing U-Boot using method rockchip
U-Boot TPL 2025.01-rc3-00345-gdfbdbf1eb56c-dirty (Jan 08 2025 - 10:47:58)
Trying to boot from vbe_abrec
load: Firefly-RK3399 Board
Using 'config-3' configuration
Trying 'image-vpl' firmware subimage
Using 'config-3' configuration
Trying 'fdt-3' fdt subimage
U-Boot VPL 2025.01-rc3-00345-gdfbdbf1eb56c-dirty (Jan 08 2025 - 10:47:58)
Trying to boot from vbe_abrec
load: Firefly-RK3399 Board
Starting with empty state
VBE: Firmware pick A at 800000
Using 'config-3' configuration
Trying 'spl' firmware subimage
Using 'config-3' configuration
Trying 'fdt-3' fdt subimage
Channel 0: DDR3, 800MHz
BW=32 Col=10 Bk=8 CS0 Row=15 CS1 Row=15 CS=2 Die BW=16 Size=2048MB
Channel 1: DDR3, 800MHz
BW=32 Col=10 Bk=8 CS0 Row=15 CS1 Row=15 CS=2 Die BW=16 Size=2048MB
256B stride
U-Boot SPL 2025.01-rc3-00345-gdfbdbf1eb56c-dirty (Jan 08 2025 - 10:47:58 -0700)
Trying to boot from vbe_abrec
load: Firefly-RK3399 Board
VBE: Firmware pick A at 900000
load_simple_fit: Skip load 'atf-5': image size is 0!
Relocating bloblist ff8eff00 to 100000: done
ns16550_serial serial@ff1a0000: pinctrl_select_state_full: uclass_get_device_by_phandle_id: err=-19
U-Boot 2025.01-rc3-00345-gdfbdbf1eb56c-dirty (Jan 08 2025 - 10:47:58 -0700)
SoC: Rockchip rk3399
Reset cause: POR
Model: Firefly-RK3399 Board
DRAM: 4 GiB (effective 3.9 GiB)
Core: 314 devices, 33 uclasses, devicetree: separate
MMC: mmc@fe310000: 3, mmc@fe320000: 1, mmc@fe330000: 0
Loading Environment from SPIFlash... Invalid bus 0 (err=-19)
*** Warning - spi_flash_probe_bus_cs() failed, using default environment
In: serial,usbkbd
Out: serial,vidconsole
Err: serial,vidconsole
Model: Firefly-RK3399 Board
Net: PMIC: RK808
eth0: ethernet@fe300000
starting USB...
Bus usb@fe380000: USB EHCI 1.00
Bus usb@fe3a0000: USB OHCI 1.0
Bus usb@fe3c0000: USB EHCI 1.00
Bus usb@fe3e0000: USB OHCI 1.0
Bus usb@fe900000: Register 2000140 NbrPorts 2
Starting the controller
USB XHCI 1.10
scanning bus usb@fe380000 for devices... 1 USB Device(s) found
scanning bus usb@fe3a0000 for devices... 1 USB Device(s) found
scanning bus usb@fe3c0000 for devices... 2 USB Device(s) found
scanning bus usb@fe3e0000 for devices... 1 USB Device(s) found
scanning bus usb@fe900000 for devices... 1 USB Device(s) found
scanning usb for storage devices... 0 Storage Device(s) found
Hit any key to stop autoboot: 0
Link: https://lore.kernel.org/r/20250116012723.2820301-1-sjg@chromium.org
When building without DHCP/PXE configurations (NET disabled),
compilation errors may occur due to mismatched bootargs.
Ensure bootargs related to DHCP/PXE are not enabled if the
corresponding commands are disabled.
include/config_distro_bootcmd.h:443:9: error: expected ‘}’ before
‘BOOT_TARGET_DEVICES_references_PXE_without_CONFIG_CMD_DHCP_or_PXE’
443 | BOOT_TARGET_DEVICES_references_PXE_without_CONFIG_CMD_DHCP_or_PXE
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Signed-off-by: Chanho Park <parkch98@gmail.com>
Acked-by: Linus Walleij <linus.walleij@linaro.org>
The get_timer function returns an unsigned long which may be calculated
from the ARM system counter. This counter is reset only on a cold reset.
U-boot divides this counter down to a 1000 Hz counter that will cross
the 32bit barrier after a bit more than 49 days. Assigning the value to
an unsigned int will truncate it on 64bit systems.
Passing this truncated value back to the get_timer function will return
a very large value that is certainly larger than the timeout and so will
go down the error path and besides stopping U-Boot will lead to messages
like
"SPI: QSPI is still busy after poll for 5000 ms."
Signed-off-by: Ronald Wahl <ronald.wahl@legrand.com>
Cc: Vignesh R <vigneshr@ti.com>
Cc: Pratyush Yadav <p.yadav@ti.com>
Reviewed-by: Vignesh Raghavendra <vigneshr@ti.com>
We have a duplicate declaration of spi_mem_default_supports_op() which
was added twice, first with commit af6266c1c2 ("mem: spi-mem: add
declaration for spi_mem_default_supports_op") for v2021.04, and again
with commit 2299076e34 ("spi: spi-mem: export
spi_mem_default_supports_op()") for v2021.07.
The first commit is reverted here, because the second better matches the
definition and has a better place in the declaration order.
Note: Linux declares this in a different section of spi-mem.h which is
disabled in U-Boot through `#ifndef __UBOOT__`.
This reverts commit af6266c1c2.
Signed-off-by: Alexander Dahl <ada@thorsis.com>
First try dropping this was with commit 37434db29b ("spi: atmel: Drop
atmel_spi.h") back in 2018 which was reverted not much later with commit
5270df2836 ("Revert "spi: atmel: Drop atmel_spi.h"").
Second try dropping this was in 2020 with commit beeb34ac0c ("spi:
atmel: Drop atmel_spi.h"), but that only moved all the definitions into
the source file and did not remove the header file.
Currently all of the definitions in the header file are (still)
contained in the source file, and the header file is include nowhere.
Fixes: beeb34ac0c ("spi: atmel: Drop atmel_spi.h")
Signed-off-by: Alexander Dahl <ada@thorsis.com>
For a sandbox implementation, where code size is no object, it makes sense
to use the full bootstd drivers to load images.
For real boards, running from SRAM, this adds quite a bit of overhead.
Add a way to load the next phase using just the underlying storage
driver, to reduce code size. For now, only MMC is supported.
Change the log_debug() to show the load address and size in a more
neutral way, rather than suggesting that the load has already happened.
Signed-off-by: Simon Glass <sjg@chromium.org>
VBE needs to load different images from a FIT depending on the xPL phase
in use. The IH_PHASE value is used to select the image to load.
Add the required logic to handle this. For compatibility with the
SPL-loader driver, fill out a struct spl_image_info with the details
needed to boot the next phase.
This is good enough for VBE-simple but ABrec will need the full set of
bootstd features. So add a USE_BOOTMETH define to control this.
Signed-off-by: Simon Glass <sjg@chromium.org>
Add FDT support so that this can be copied down in memory after loading
and made available to the new image.
Signed-off-by: Simon Glass <sjg@chromium.org>
This is fairly easy to use. The SPL loader sets up some fields in the
spl_image_info struct and calls spl_reloc_prepare(). When SPL is ready
to do the jump it must call spl_reloc_jump() instead of jump_to_image().
Add this logic.
Signed-off-by: Simon Glass <sjg@chromium.org>
When one xPL phase wants to jump to the next, the next phase must be
loaded into its required address. This means that the TEXT_BASE for the
two phases must be different and there cannot be any memory overlap
between the code used by the two phases. It also can mean that phases
need to be moved around to accommodate any size growth.
Having two xPL phases in SRAM at the same time can be tricky if SRAM
is limited, which it often is. It would be better if the second phase
could be loaded somewhere else, then decompressed into place over the
top of the first phase.
Introduce a relocating jump for xPL to support this. This selects a
suitable place to load the (typically compressed) next phase, copies
some decompression code out of the first phase, then jumps to this code
to decompress and start the next phase.
This feature makes it much easier to support Verified Boot for Embedded
(VBE) on RK3399 boards, which have 192KB of SRAM.
Signed-off-by: Simon Glass <sjg@chromium.org>
This function will be used by the relocating jumper too, so add a
typedef to the header file to avoid mismatches.
Signed-off-by: Simon Glass <sjg@chromium.org>
In many cases the FIT includes a devicetree. Add support for loading
this into a suitable place in memory.
Signed-off-by: Simon Glass <sjg@chromium.org>
In some cases only the 'loadable' property is present in the FIT.
Handle this by loading the first such image.
Signed-off-by: Simon Glass <sjg@chromium.org>
There is no guarantee that an FIT image starts on a block boundary. When
it doesn't, the image starts part-way through the first block.
Add logic to detect this and copy the image down into place.
Signed-off-by: Simon Glass <sjg@chromium.org>
At present the VBE implementation is limited to sandbox only. Adjust the
call to fit_image_load() to remove this limitation.
Signed-off-by: Simon Glass <sjg@chromium.org>
It is convenient to use TEXT_BASE as a place to hold the FIT header, but
this does not work in VPL, since SDRAM is not inited yet.
Allocate the memory instead. Ensure the size is aligned to the media
block-size so that it can be read in directly. Improve the
error-checking for blk_read() and add some more debugging.
Keep the existing TEXT_BASE mechanism in sandbox to avoid an
'Exec format error' when trying to run the image.
Signed-off-by: Simon Glass <sjg@chromium.org>
Loading a FIT is useful for other VBE methods, such as ABrec. Create a
new function to handling reading it.
Signed-off-by: Simon Glass <sjg@chromium.org>
