Tom Rini [Fri, 24 Dec 2021 14:31:35 +0000 (09:31 -0500)]
Merge branch '2021-12-23-make-OF_BOARD-a-boolean' into next
Merge v8 of Simon's series to make CONFIG_OF_BOARD a boolean option.
Quoting him:
With Ilias' efforts we have dropped OF_PRIOR_STAGE and OF_HOSTFILE so
there are only three ways to obtain a devicetree:
- OF_SEPARATE - the normal way, where the devicetree is built and
appended to U-Boot
- OF_EMBED - for development purposes, the devicetree is embedded in
the ELF file (also used for EFI)
- OF_BOARD - the board figures it out on its own
The last one is currently set up so that no devicetree is needed at all
in the U-Boot tree. Most boards do provide one, but some don't. Some
don't even provide instructions on how to boot on the board.
The problems with this approach were covered in another patch[1], since
removed from this series.
In practice, OF_BOARD is not really distinct from OF_SEPARATE. Any board
can obtain its devicetree at runtime, even it is has a devicetree built
in U-Boot. This is because U-Boot may be a second-stage bootloader and its
caller may have a better idea about the hardware available in the machine.
This is the case with a few QEMU boards, for example.
So it makes no sense to have OF_BOARD as a 'choice'. It should be an
option, available with either OF_SEPARATE or OF_EMBED. This would allow
rpi3, for example, to run with the devicetree provided by the prior
bootloader.
This series makes this change, adding various missing devicetree files
(and placeholders) to make the build work.
To make the 'prior stage' side of things more deterministic, a new
OF_HAS_PRIOR_STAGE is added, which cannot be disabled by updated a board's
defconfig. This should help to prevent mistakes.
It also adds a run-time message showing where the devicetree came from,
as well as warnings if the board's expected flow is not being used. This
comes originally from the 'standard passage' series, which depends on
this series.
It also provides a few qemu clean-ups discovered along the way. The
qemu-riscv64_spl problem is fixed.
Please see [2] for discussion on the v6 series.
I put Heinrich's Tested-by tag[3] for the series onto the three devicetree
patches (ARM and RISC-V) that I think it most affects. It isn't possible
to apply a tag to a whole series at present and in any case there are
changes in v7.
Simon Glass [Fri, 17 Dec 2021 03:59:39 +0000 (20:59 -0700)]
fdt: Show a runtime warning based on devicetree source
When running, if the devicetree failed to come from the expected source,
show a warning, e.g:
U-Boot ...
DRAM: 128 MiB
Core: 42 devices, 11 uclasses, devicetree: separate
Warning: Unexpected devicetree source (not from a prior stage)
Warning: U-Boot may not function properly
Flash: 64 MiB
...
These warnings should only appear if the board config has been changed, or
the prior stage is broken.
Simon Glass [Fri, 17 Dec 2021 03:59:38 +0000 (20:59 -0700)]
fdt: Avoid emitting an device tree when not needed
U-Boot always needs some sort of a device tree in the build. Some boards
never actually use this, at least in production systems, since a prior
firmware stage sets one up and passes it to U-Boot. At present the only
mechanism to do that is with custom function (OF_BOARD), but future work
will include a standard way of doing this ('standard passage').
It can be confusing to see a device tree emitted from the U-Boot build in
this situation. Add an option to drop it.
Simon Glass [Fri, 17 Dec 2021 03:59:36 +0000 (20:59 -0700)]
fdt: Enable OF_HAS_PRIOR_STAGE for most boards with OF_BOARD
Use this new Kconfig instead of OF_BOARD, so we know for sure which boards
obtain their devicetree from a prior stage. Leave sandbox alone since it
does not. Also don't touch xilinx_versal_virt since it does not have a
specific TARGET Kconfig.
This option implies OF_BOARD for now, but with future work standard
passage may be used instead.
Signed-off-by: Simon Glass <sjg@chromium.org>
[trini: Add rpi_4_32b and rpi_arm64 to the list of boards converted] Signed-off-by: Tom Rini <trini@konsulko.com>
Simon Glass [Fri, 17 Dec 2021 03:59:35 +0000 (20:59 -0700)]
fdt: Add a Kconfig for boards with a prior stage
When U-Boot is started from another firmware program, not just a prior
phase of U-Boot, special behaviour is typically used. In particular, the
device tree may come from that prior stage.
At present this is sort-of indicated by OF_BOARD, although the
correlation is not 1:1, since that option simply means that the board has
a custom mechanism for obtaining the device tree. For example, sandbox
defines OF_BOARD. Also the board_fdt_blob_setup() function can in fact
make use of the devicetree in U-Boot if it wishes, as used by
dragonboard410c until very recently.
Add an explicit Kconfig for this situation. Update the OF_BOARD option to
more-accurately reflect what it is doing, e.g. for sandbox.
Simon Glass [Fri, 17 Dec 2021 03:59:34 +0000 (20:59 -0700)]
fdt: Report the devicetree source
It can be confusing to figure out where the devicetree came from. It seems
important enough to warrant a message during boot. Add information about
the number of devices and uclasses too since it is helpful to have some
idea what is going on with driver model.
Report the devicetree source in bdinfo too.
This looks something like this, with > marking the new line.
Simon Glass [Fri, 17 Dec 2021 03:59:31 +0000 (20:59 -0700)]
fdt: Don't call board_fdt_blob_setup() without OF_BOARD
At present this override function is called even when OF_BOARD is not
enabled. This makes it impossible to disable this feature and in fact
makes the OF_BOARD option useless.
Reinstate its intended purpose, so that it is possible to switch between
the appended devicetree and one provided by the board's custom function.
A follower patch adds warnings for this scenario, but for now we don't
have a Kconfig that definitively tells us that OF_BOARD should be used.
Simon Glass [Fri, 17 Dec 2021 03:59:29 +0000 (20:59 -0700)]
fdt: Drop OF_CONTROL check in fdtdec_setup()
This function should only be called when OF_CONTROL is enabled. It
fails in fdtdec_prepare_fdt() anyway, since gd->fdt_blob stays as NULL
if OF_CONTROL is not enabled.
Simon Glass [Fri, 17 Dec 2021 03:59:18 +0000 (20:59 -0700)]
arm: bcm7xxx: Add a devicetree file
Add an empty devicetree file for these boards. It seems to be possible to
obtain a real one from another bootloader called 'bolt' but I will leave
this to the maintainer.
Simon Glass [Fri, 17 Dec 2021 03:59:12 +0000 (20:59 -0700)]
riscv: qemu: Split devicetree files for qemu_riscv32/64
This uses QEMU virt which creates its own devicetree.
Copy the existing empty version of this file, so splitting the existing
qemu-virt into two, since anyone actually trying to use this will need a
different devicetree for 32- and 64-bit machines.
Tested-by: Heinrich Schuchardt <heinrich.schuchardt@canaonical.com> Signed-off-by: Simon Glass <sjg@chromium.org>
Pali Rohár [Thu, 11 Nov 2021 15:35:42 +0000 (16:35 +0100)]
pci: pci_mvebu: Move setup for BAR[0] where other BARs are setup
Function mvebu_pcie_setup_wins() sets up all other BARs, so move setup of
BAR[0] to this function to have common code at one place.
In the past, commit 102b3cee3e9b ("pci: pci_mvebu: set BAR0 after memory
space is set") moved setup of BAR[0] to another location, due to ath10k
not working in kernel, but the reason why was unknown, but it seems to
work now, and we think the issue then was cause by the PCIe Root Port
presenting itself as a Memory Controller and therefore U-Boot's code
have overwritten the BAR. Since the driver now ignores any write
operations to PCIe Root Port BARs, this should not be an issue anymore.
Signed-off-by: Pali Rohár <pali@kernel.org> Signed-off-by: Marek Behún <marek.behun@nic.cz> Reviewed-by: Stefan Roese <sr@denx.de>
fw_setenv: Unbreak fw_setenv caused by buggy MEMISLOCKED use
Commit "fw_setenv: lock the flash only if it was locked before"
checks for Locked status with uninitialized erase data.
Address by moving the test for MEMISLOCKED.
Fixes: 8a726b852502 ("fw_setenv: lock the flash only if it was locked before") Signed-off-by: Joakim Tjernlund <joakim.tjernlund@infinera.com>
Stefan Roese [Thu, 18 Nov 2021 08:18:41 +0000 (09:18 +0100)]
i2c: mvtwsi: Swab the register address if its size is > 1
Testing on Armada XP with an EEPROM using register address with size
of 2 has shown, that the register address bytes are sent to the I2C
EEPROM in the incorrect order. This patch swabs the address bytes so
that the correct address is transferred to the I2C device.
BTW: This worked without any issues before migrating Armada XP to
DM I2C.
Signed-off-by: Stefan Roese <sr@denx.de> Cc: Heiko Schocher <hs@denx.de> Cc: Samuel Holland <samuel@sholland.org> Cc: Baruch Siach <baruch@tkos.co.il> Cc: Pali Rohár <pali@kernel.org> Cc: Marek Behún <marek.behun@nic.cz> Tested-by: Marek Behún <marek.behun@nic.cz>
This is a backport from Marvell U-Boot:
https://github.com/MarvellEmbeddedProcessors/u-boot-marvell
commit 381d029e7a ("fix: serdes: a38x, a39x: Improve USB3 electrical
configuration")
- De-Emphasize force, in functional mode the transmitter should always
have 3.5db de-emphasize, so we are forcing it.
- After forcing De-Emphasize, choose 3.5db (After forcing, default is
6dB so need to change it to 3.5dB).
- Align90 set to 0x58 - this is the sample point in the receiver, after
the clock is recovered this sampler samples at the chosen value, usually
it is supposed to be 0x60(which is the center of the eye), but sometimes
after adding jitter and ISI the center of the eye can move slightly and
the sample point is not necessarily the exact center, and after
optimization (searching the middle of the eye manually) it was seen that
the center of the eye is actually 0x58 and not 0x60.
- FFE Res and FFE Cap set to 0xE & 0xF respectively: improves this
settings is adequate according to how the USB3 spec defines the
interconnect, thus improves USB3 jitter tolerance settings.
- Change the resolution of the DFE to 0x3 which is 6mV(highest
resolution) , this avoids the DFE to saturate and cease to work.
- HPF set to 0x3 which is 5Khz high pass filter, the function of the HPF
is to filter the low frequency patterns(below 5Khz) to make sure that
the signal is not a noise, the setting before was 0x1(205Khz), and the
change came since the USB3 CP0 pattern, that is used in the USB3 jitter
tolerance testing, is similar to PRBS15, which has 2^15=32768bits which
is 32768*200ps (200ps is one Unit interval in USB3(5Gbps)) = 6.5us,
which is in frequency terms: 152Khz. since the PRBS15 is a random
pattern and can theoretically have once in a while a pattern that will
be at frequency of 152Khz, hence the previous setting (205khz HPF) can
possibly filter this pattern which can cause to an error in the
receiver, thus this change to avoid such scenarios.
Signed-off-by: Stefan Eichenberger <eichest@gmail.com> Signed-off-by: René Straub <rene.straub@netmodule.com> Reviewed-by: Stefan Roese <sr@denx.de>
arm: mvebu: a38x: serdes: fix serdes config for USB3
The electrical serdes configuration for USB3 expects an array as data
argument. For USB3 the second value is used (see data_arr_idx = USB3 =
1). However, because only one value is inside the array mv_seq_exec is
accessing an invalid element and the serdes is configured wrongly.
This wrong initialization is leading to an unreliable detection
mechanism for some USB3 devices. We were able to reproduce the issue
regularly with an LTE modem from Sierra Wireless (SM7455) where it was
not detected as USB3 device in 1/3 of all tests.
This commit fixes the issue by setting data_arr_idx to 0. This is the
same value as the original U-Boot from Marvell is using. There it is
called FIRST_CELL which is a define for 0.
See: https://github.com/MarvellEmbeddedProcessors/u-boot-marvell
commit 56f963ce4c ("fix: serdes: a38x, a39x: Fix USB3 serdes DB
initialization")
Signed-off-by: Stefan Eichenberger <eichest@gmail.com> Signed-off-by: René Straub <rene.straub@netmodule.com> Reviewed-by: Stefan Roese <sr@denx.de>
Pali Rohár [Fri, 26 Nov 2021 13:57:13 +0000 (14:57 +0100)]
phy: marvell: a3700: Convert to official DT bindings in COMPHY driver
Convert A3720 common PHY driver to official DT bindings.
This puts us closer to be able to synchronize A3720 device-trees with
those from Linux.
Signed-off-by: Pali Rohár <pali@kernel.org> Signed-off-by: Marek Behún <marek.behun@nic.cz> Cc: Konstantin Porotchkin <kostap@marvell.com> Cc: Robert Marko <robert.marko@sartura.hr> Cc: Luka Perkov <luka.perkov@sartura.hr> Cc: Marcin Wojtas <mw@semihalf.com> Cc: Grzegorz Jaszczyk <jaz@semihalf.com> Reviewed-by: Stefan Roese <sr@denx.de>
Marek Behún [Fri, 26 Nov 2021 13:57:10 +0000 (14:57 +0100)]
fdt_support: Add some useful functions
Add functions
fdt_node_offset_by_pathf(),
fdt_create_phandle_by_pathf(),
fdt_set_status_by_pathf()
to get node offset, get/create node phandle and set status for node
given by path/alias formatted with sprintf.
Add functions
fdt_create_phandle_by_compatible(),
fdt_set_status_by_compatible()
to get/create node phandle and set status for first node given by
compatible.
Signed-off-by: Marek Behún <marek.behun@nic.cz> Reviewed-by: Stefan Roese <sr@denx.de>
Marek Behún [Fri, 26 Nov 2021 13:57:07 +0000 (14:57 +0100)]
fdt_support: Remove fdt_alloc_phandle() in favor of fdt_generate_phandle()
Commit 87361ea2511 ("fdt: Sync up to the latest libfdt") introduced
fdt_generate_phandle() in libfdt, making fdt_alloc_phandle() obsolete in
fdt_support.
Signed-off-by: Marek Behún <marek.behun@nic.cz> Reviewed-by: Stefan Roese <sr@denx.de> Cc: Simon Glass <sjg@chromium.org> Cc: "hui.song" <hui.song_1@nxp.com> Cc: Meenakshi Aggarwal <meenakshi.aggarwal@nxp.com> Cc: Priyanka Jain <priyanka.jain@nxp.com> Cc: Ioana Ciornei <ioana.ciornei@nxp.com> Reviewed-by: Simon Glass <sjg@chromium.org>
Marek Behún [Fri, 26 Nov 2021 13:57:06 +0000 (14:57 +0100)]
treewide: Use fdt_create_phandle() where appropriate
Replace fdt_alloc_phandle() with subsequent fdt_set_phandle() by
fdt_create_phandle().
Signed-off-by: Marek Behún <marek.behun@nic.cz> Reviewed-by: Stefan Roese <sr@denx.de> Cc: Aaron Williams <awilliams@marvell.com> Cc: Ramon Fried <rfried.dev@gmail.com> Cc: Vladimir Oltean <vladimir.oltean@nxp.com>
Pali Rohár [Fri, 26 Nov 2021 13:57:05 +0000 (14:57 +0100)]
include/linux/byteorder: Fix compilation of __constant_cpu_to_be32()
The macro __constant_cpu_to_be32() uses ___constant_swab32(), which for
some reason is not defined and causes the following error during
compilation:
include/linux/byteorder/little_endian.h:28:52: warning:
implicit declaration of function ‘___constant_swab32’;
did you mean ‘__builtin_bswap32’? [-Wimplicit-function-declaration]
#define __constant_cpu_to_be32(x) ((__force __be32)___constant_swab32((x)))
Declare all ___constant_swabXX() macros.
Signed-off-by: Pali Rohár <pali@kernel.org> Signed-off-by: Marek Behún <marek.behun@nic.cz> Reviewed-by: Stefan Roese <sr@denx.de>
AKASHI Takahiro [Fri, 10 Dec 2021 06:49:36 +0000 (15:49 +0900)]
dm: fix an 'undefined' error in some macros
Due to a non-existing parameter name in macro's, use of those macro's will
cause a compiler error of "undefined reference".
Unfortunately, dm test doesn't fail because a wrong name ("&dev", hence it
is accidentally a valid name in the context of a caller site) is passed on.
Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org> Fixes: 8f033241c9ca ("dm: core: Add a way to read platdata for all
child devices") Fixes: 16786fe70931 ("dm: core: Add a way to iterate through children,
probing each") Reviewed-by: Simon Glass <sjg@chromium.org>
AKASHI Takahiro [Fri, 10 Dec 2021 06:49:28 +0000 (15:49 +0900)]
part: call part_init() in blk_get_device_by_str() only for MMC
In blk_get_device_by_str(), the comment says: "Updates the partition table
for the specified hw partition."
Since hw partition is supported only on MMC, it makes no sense to do so
for other devices.
Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org> Reviewed-by: Simon Glass <sjg@chromium.org>
The Calxeda servers are using U-Boot as the primary bootloader, which
was shipped as part of a firmware upgrade package.
Even though the machines are considered legacy at this point, the port
still works, so deserves some documentation.
Signed-off-by: Andre Przywara <andre.przywara@arm.com> Reviewed-by: Simon Glass <sjg@chromium.org>
Simon Glass [Wed, 8 Dec 2021 16:55:35 +0000 (09:55 -0700)]
fdtgrep: Handle an empty output tree
In strange cases it is possible for fdtgrep to find nothing to output.
Typically this means that the resulting SPL device tree is not going to
allow anything to boot, but at present the tree is actually invalid,
since it only has an END tag in the struct region.
The FDT spec requires at least a root node. So add a special case to
include at least this, if the FDT_REG_SUPERNODES flag is set.
This ensures that grepping an empty tree still produces a valid tree.
Also add comments to the enum since it is not completely obvious from
the names now.
The typical symptom of this problem is a message from binman:
Ivan Mikhaylov [Thu, 9 Dec 2021 16:10:53 +0000 (16:10 +0000)]
iot2050: binman: add missing-msg for blobs
Add the 'missing-msg' for blobs for more detailed output on missing system
firmware and SEBoot blobs.
Signed-off-by: Ivan Mikhaylov <ivan.mikhaylov@siemens.com> Reviewed-by: Simon Glass <sjg@chromium.org>
Fix minor typos: Signed-off-by: Simon Glass <sjg@chromium.org>
Andy Shevchenko [Mon, 6 Dec 2021 11:44:13 +0000 (14:44 +0300)]
binman: Use less hard coded magic when inserting new PATH
Instead of joining hard coded '..' to the run-time path of the executable,
take just a dirname out of it. Besides that, use $(srctree) where it makes
sense.
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Andy Shevchenko [Mon, 6 Dec 2021 11:44:12 +0000 (14:44 +0300)]
binman: Do not pollute source tree when build with `make O=...`
Importing libraries in Python caches the bytecode by default.
Since we run scripts in source tree it ignores the current directory
settings, which is $(srctree), and creates cache just in the middle
of the source tree. Move cache to the current directory.
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Simon Glass [Wed, 24 Nov 2021 04:08:59 +0000 (21:08 -0700)]
binman: Add support for ATF FIP
This format is used in firmware binaries so we may as well supported it.
With this patch binman supports creating, listing and updating FIPs, as
well as extracting files from one, provided that an FDTMAP is also present
somewhere in the image.
Tom Rini [Fri, 17 Dec 2021 12:25:34 +0000 (07:25 -0500)]
Merge tag 'u-boot-at91-2022.04-a' of https://source.denx.de/u-boot/custodians/u-boot-at91 into next
First set of u-boot-at91 features for the 2022.04 cycle:
This feature set includes : support for the new QSPI hardware on
sama7g5, small fixes on sam9x60 and sama7g5, some additions of commands
and PIO controller on sam9x60/sam9x60ek.
Double peripheral RBF configuration are needed on some devices or boards
to stabilize the IO configuration system.
Signed-off-by: Tien Fong Chee <tien.fong.chee@intel.com> Signed-off-by: Sin Hui Kho <sin.hui.kho@intel.com> Reviewed-by: Tien Fong Chee <tien.fong.chee@intel.com>
Tien Fong Chee [Sun, 7 Nov 2021 15:08:55 +0000 (23:08 +0800)]
arm: socfpga: arria10: Reset MPFE NoC after program periph / combined RBF
This patch triggers warm reset to recover the MPFE NoC from corruption
due to high frequency transient clock output from HPS EMIF IOPLL at
VCO startup after peripheral RBF is programmed.
Signed-off-by: Tien Fong Chee <tien.fong.chee@intel.com> Signed-off-by: Sin Hui Kho <sin.hui.kho@intel.com> Reviewed-by: Tien Fong Chee <tien.fong.chee@intel.com>
Tien Fong Chee [Sun, 7 Nov 2021 15:08:54 +0000 (23:08 +0800)]
arm: socfpga: arria10: Setting image magic value to romcode initswstate reg
The romcode_initswstate register need to be set with FSBL_IMAGE_IS_VALID
value if the current FSBL image is found valid, otherwise BootROM will
look for next subsequent valid FSBL image when warm reset is triggered.
Signed-off-by: Tien Fong Chee <tien.fong.chee@intel.com> Signed-off-by: Sin Hui Kho <sin.hui.kho@intel.com> Reviewed-by: Tien Fong Chee <tien.fong.chee@intel.com>
Hari Prasath [Mon, 13 Dec 2021 05:00:03 +0000 (10:30 +0530)]
ARM: mach-at91: Add compile time option to choose proper timer
New SoC's of AT91 family with ARM-9 core includes a regular timer and a 64-bit
timer.This patch adds a compile time option to the Makefile such that the old
timer driver is chosen and compiled as default if none of timer configuration
options are explicitly defined in the board configs.
Signed-off-by: Hari Prasath <Hari.PrasathGE@microchip.com> Reviewed-by: Eugen Hristev <eugen.hristev@microchip.com>
Giulio Benetti [Sun, 14 Feb 2021 02:17:18 +0000 (03:17 +0100)]
clk: fix clk_get_rate() documentation
Improve clk_get_rate() @return documentation that otherwise is a bit
ambiguous. At the moment I expect to return 0 as error since the return
type is 'ulong', instead the function really returns negative value in
case the corresponding function pointer is null and returns 0 if the clock
is invalid.
Signed-off-by: Giulio Benetti <giulio.benetti@benettiengineering.com> Reviewed-by: Sean Anderson <seanga2@gmail.com>
Pali Rohár [Thu, 11 Nov 2021 15:35:48 +0000 (16:35 +0100)]
arm: a37xx: pci: Do not allow setting ROM BAR on PCI Bridge
PCI Bridge which represents aardvark PCIe Root Port has Expansion ROM Base
Address register at offset 0x30 but its meaning is different than PCI's
Expansion ROM BAR register. Only address format of register is same.
In reality, this device does not have any configurable PCI BARs. So ensure
that write operation into BARs (including Expansion ROM BAR) is noop and
registers always contain zero address which indicates that bars are
unsupported.
Fixes: 7b758b439474 ("arm: a37xx: pci: Add support for accessing PCI Bridge on root bus") Signed-off-by: Pali Rohár <pali@kernel.org> Signed-off-by: Marek Behún <marek.behun@nic.cz> Reviewed-by: Stefan Roese <sr@denx.de>
Pali Rohár [Thu, 11 Nov 2021 15:35:45 +0000 (16:35 +0100)]
pci: pci_mvebu: Do not allow setting ROM BAR on PCI Bridge
The PCI Bridge which represents mvebu PCIe Root Port has Expansion ROM
Base Address register at offset 0x30 but its meaning is different that
of PCI's Expansion ROM BAR register, although the address format of
the register is the same.
In reality, this device does not have any configurable PCI BARs. So
ensure that write operation into BARs (including Expansion ROM BAR) is a
noop and registers always contain zero address which indicates that BARs
are unsupported.
Fixes: 18e57fe33755 ("pci: pci_mvebu: Properly configure and use PCI Bridge (PCIe Root Port)") Signed-off-by: Pali Rohár <pali@kernel.org> Signed-off-by: Marek Behún <marek.behun@nic.cz> Reviewed-by: Stefan Roese <sr@denx.de>
projects / uboot.git / log