Tom Rini [Fri, 17 Dec 2021 23:08:39 +0000 (18:08 -0500)]
serial: arm_dcc: Use CONFIG_ARM64 not CONFIG_CPU_ARMV8
The only place we use CONFIG_CPU_ARMV8 was in the arm_dcc serial driver.
Switch this to CONFIG_ARM64 today, and if in the future we need finer
granularity tuning here, a new CONFIG_SERIAL option needs to be
introduced.
Tom Rini [Tue, 14 Dec 2021 18:36:41 +0000 (13:36 -0500)]
CI: Test for unmigrated CONFIG symbols in board config.h files
Now that all symbols that exist in Kconfig no longer also have boards
setting them in the board config.h file, add a CI test to catch new
instances of this, and fail.
Tom Rini [Tue, 14 Dec 2021 18:36:40 +0000 (13:36 -0500)]
Finish conversion of CONFIG_SYS_CLK_FREQ to Kconfig
In order to finish moving this symbol to Kconfig for all platforms, we
need to do a few more things. First, for all platforms that define this
to a function, introduce CONFIG_DYNAMIC_SYS_CLK_FREQ, similar to
CONFIG_DYNAMIC_DDR_CLK_FREQ and populate clock_legacy.h. This entails
also switching all users from CONFIG_SYS_CLK_FREQ to get_board_sys_clk()
and updating a few preprocessor tests.
With that done, all platforms that define a value here can be converted
to Kconfig, and a fall-back of zero is sufficiently safe to use (and
what is used today in cases where code may or may not have this
available). Make sure that code which calls this function includes
<clock_legacy.h> to get the prototype.
Tom Rini [Tue, 14 Dec 2021 18:36:39 +0000 (13:36 -0500)]
CONFIG_SYS_CLK_FREQ: Consistently be static or get_board_sys_clk()
This CONFIG option is used in one of two ways. The first way is that it
is defined to a static value, of an unsigned long size. The second way
is that it is defined to something, typically a function, to determine
this value at run time.
However, in a few cases that function returns a static value. Change
that to using the static value directly.
In the case of using something at run time, convert everything to using
a function of the same name and prototype. This will allow for further
cleanups.
Finally, we have a few cases where the function is just not used, so
drop it.
Tom Rini [Tue, 14 Dec 2021 18:36:38 +0000 (13:36 -0500)]
nxp: ics307_clk: Guard get_board_ddr_clk function correctly
When we have CONFIG_DYNAMIC_DDR_CLK_FREQ set is the only time we should
have this function, so guard it so that we can include <clock_legacy.h>
in this file later on.
Tom Rini [Tue, 14 Dec 2021 18:36:37 +0000 (13:36 -0500)]
ls1088a: Guard get_board_ddr_clk function correctly
When we have CONFIG_DYNAMIC_DDR_CLK_FREQ set is the only time we should
have this function, so guard it so that we can include <clock_legacy.h>
in this file later on.
Tom Rini [Tue, 14 Dec 2021 18:36:36 +0000 (13:36 -0500)]
arm: s5pc1xx: Move CONFIG_SYS_CLK_FREQ_C1x0 out of CONFIG namespace
The values CONFIG_SYS_CLK_FREQ_C100 and CONFIG_SYS_CLK_FREQ_C110 are
only used in one place and not changed by the board config file. Move
these out of the CONFIG namespace and in to the CFG namespace.
Tom Rini [Mon, 13 Dec 2021 03:12:36 +0000 (22:12 -0500)]
Finish conversion CONFIG_SYS_NAND_SELF_INIT to Kconfig
In order to finish this conversion we need to add a symbols for
SPL_SYS_NAND_SELF_INIT and TPL_SYS_NAND_SELF_INIT as there are cases
there where we need to, or need to not, use that framework as things
stand.
Tom Rini [Mon, 13 Dec 2021 03:12:34 +0000 (22:12 -0500)]
Finish converting CONFIG_SYS_FSL_CLK to Kconfig
This converts the following to Kconfig:
CONFIG_SYS_FSL_CLK
We move the exiting option to common/Kconfig near the other options to
control the contents of board_init_f() and note that this is a legacy
option. We further restrict this to where the call is going to be
non-empty, for the SoCs that had only been using this for some
MMC-related clocks.
Tom Rini [Mon, 13 Dec 2021 03:12:33 +0000 (22:12 -0500)]
warp7, pic32mzdask: Remove SYS_FDT_ADDR/SYS_ENV_ADDR from CONFIG namespace
In the case of CONFIG_SYS_FDT_ADDR this was being used to modify the
default value of fdt_addr / fdt_addr_r, which is not something to expose
in this manner and is not otherwise done. The case of SYS_ENV_ADDR is
similar but only done on the pic32mzdask platform, for scriptaddr.
Tom Rini [Mon, 13 Dec 2021 03:12:31 +0000 (22:12 -0500)]
Finish CONFIG_VID et al conversion to Kconfig
This converts the following to Kconfig:
CONFIG_VID
CONFIG_VOL_MONITOR_INA220
CONFIG_VOL_MONITOR_IR36021_READ
CONFIG_VOL_MONITOR_IR36021_SET
CONFIG_VOL_MONITOR_LTC3882_READ
CONFIG_VOL_MONITOR_LTC3882_SET
To finish this migration, we first need to introduce CONFIG_SPL_VID as
some platforms only use this code in full U-Boot while others use it in
SPL as well. To make the Kconfig logic clearer, guard all of the
sub-options with a if VID || SPL_VID check. Finally, add Kconfig
options for the remaining related options that did not previously have
one.
Tom Rini [Mon, 13 Dec 2021 03:12:30 +0000 (22:12 -0500)]
Convert CONFIG_SYS_IMMR to Kconfig
This converts the following to Kconfig:
CONFIG_SYS_IMMR
We do this by consolidating the SYS_IMMR options we have and providing
defaults.
We also, in the few places where M68K was also sharing code with these
platforms, define it within the file to CONFIG_SYS_MBAR to match usage.
This should be cleaned up longer term.
Tom Rini [Mon, 13 Dec 2021 03:12:27 +0000 (22:12 -0500)]
Finish converting CONFIG_WATCHDOG, HW_WATCHDOG and WDT to Kconfig
Because of how these symbols work, and the remaining board config.h file
uses, we need to do these at the same time. In some cases we just get
to move rather directly to the defconfigs. A few cases require manual
intervention.
For the case of the eb_cpu5282 we need to select HW_WATCHDOG for the
target, given how it's implemented.
For the cases of m53menlo, dh_imx6, display5, and display5_factory we
disable SPL watchdog support as the particular combination of options
they want would require either more symbols or enabling SPL_DM.
Tom Rini [Sat, 11 Dec 2021 19:55:52 +0000 (14:55 -0500)]
Remove CONFIG_SYS_MMC_IMG_LOAD_PART from CONFIG namespace
This option is used as part of configuring the default environment for a
number of platforms. However, it is always set to 1 and the only time
it is part of Kconfig, it is used in a hard-coded manner. Hard-code the
value in the environment instead.
Tom Rini [Sat, 11 Dec 2021 19:55:48 +0000 (14:55 -0500)]
Convert CONFIG_ENV_SPI_BUS et al to Kconfig
This converts the following to Kconfig:
CONFIG_ENV_SPI_BUS
CONFIG_ENV_SPI_CS
CONFIG_ENV_SPI_MAX_HZ
CONFIG_ENV_SPI_MODE
As part of this, we use Kconfig to provide the defaults now that were
done in include/spi_flash.h. We also in some cases change from using
CONFIG_ENV_SPI_FOO to CONFIG_SF_DEFAULT_FOO as those were the values in
use anyhow as ENV was not enabled.
Tom Rini [Sat, 11 Dec 2021 19:55:47 +0000 (14:55 -0500)]
Clarify CONFIG_SYS_I2C_EEPROM_ADDR_OVERFLOW in Kconfig
This is a "hex" prompt but the default value was given as an int.
Switch the default to hex (0x0) and remove the defconfigs that were
using the default, but as hex before.
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>
projects / uboot.git / log