To reduce code duplication, let the stm32 based DH boards use the common
code for setting up their MAC addresses.
Signed-off-by: Philip Oberfichtner <pro@denx.de> Tested-by: Marek Vasut <marex@denx.de> Reviewed-by: Marek Vasut <marex@denx.de> Reviewed-by: Patrick Delaunay <patrick.delaunay@foss.st.com>
board: dhelectronics: Implement common MAC address functions
This is a starting point for unifying duplicate code in the DH board
files. The functions for setting up MAC addresses are very similar for
the i.MX6, i.MX8 and stm32mp1 based boards.
All pre-existing implementations follow the same logic:
(1) Check if ethaddr is already set in the environment
(2) If not, try to get it from a board specific location (e.g. fuse)
(3) If not, try to get it from eeprom
After this commit, (1) and (3) are implemented as common functions,
ready to be used by board specific files.
Furthermore there is an implementation of (2) for imx based boards.
Signed-off-by: Philip Oberfichtner <pro@denx.de> Reviewed-by: Marek Vasut <marex@denx.de>
Tom Rini [Tue, 9 Aug 2022 02:44:45 +0000 (22:44 -0400)]
CI: Azure: Move to Ubuntu 22.04 image
As per https://github.com/actions/runner-images/issues/6002 the Ubuntu
18.04 image is deprecated and will be removed by December 1, 2022.
Move to the Ubuntu 22.04 image as our base for launching our containers
from.
Signed-off-by: Tom Rini <trini@konsulko.com> Reviewed-by: Simon Glass <sjg@chromium.org>
To quote Simon:
This adds the concept of a VBE method to U-Boot, along with an
implementation of the 'VBE simple' method, basically a simple way of
updating firmware in MMC from userspace and monitoring it from U-Boot.
VBE simple is implemented in fwupd. U-Boot's role is to set up the
device tree with the required firmware-update properties and provide the
developer with information about the current VBE state. To that end this
series includes a new 'vbe' command that allows VBE methods to be listed
and examined.
As part of this work, support for doing FDT fixups via the event interface
is provided, along with the ability to write to the device tree via the
ofnode interface.
Another (significant) change is that bootmeths now have a 'global' flag,
to allow the implementation of EFI bootmgr (and VBE) to be cleaned up.
The 'system' bootdev is no-longer needed and these bootmeths are scanned
first.
Further work is needed to pull everything together, but this is a step
along the way.
Simon Glass [Sat, 30 Jul 2022 21:52:34 +0000 (15:52 -0600)]
bootstd: Add vbe bootmeth into sandbox
Update sandbox to include the VBE bootmeth. Update a few existing tests to
take account of this change, specifically that the new bootmeth now
appears when scanning.
Simon Glass [Sat, 30 Jul 2022 21:52:31 +0000 (15:52 -0600)]
event: Add an event for device tree fixups
At present there is a confusing array of functions that handle the
device tree fix-ups needed for booting an OS. We should be able to switch
to using events to clean this up.
As a first step, create a new event type and call it from the standard
place.
Note that this event uses the ofnode interface only, since this can
support live tree which is more efficient when making lots of updates.
Simon Glass [Sat, 30 Jul 2022 21:52:29 +0000 (15:52 -0600)]
bootstd: Drop the system bootdev
This was a work-around for the fact that global bootmeths such as EFI
bootmgr and VBE don't use a particular bootdev, or at least select it
themselves so that we don't need to scan all bootdevs when using that
bootmeth.
Simon Glass [Sat, 30 Jul 2022 21:52:28 +0000 (15:52 -0600)]
bootstd: Always create the EFI bootmgr bootmeth
Now that we can separate this out from the normal bootmeths, update the
code to create it always.
We cannot rely on the device tree to create this, since the EFI project
is quite opposed to having anything in the device tree that helps U-Boot
with its processing.
Simon Glass [Sat, 30 Jul 2022 21:52:27 +0000 (15:52 -0600)]
bootstd: Allow scanning for global bootmeths separately
Typically we want to find and use global bootmeths first, since they have
the best idea of how the system should boot. We then use normal bootmeths
as a fallback.
Add the logic for this, putting global bootmeths at the end of the
ordering. We can then easily scan the global bootmeths first, then drop
them from the list for subsequent bootdev-centric scans.
This changes the ordering of global bootmeths, so update the
bootflow_system() accordingly.
Drop the comment from bootmeth_setup_iter_order() since this is an
exported function and it should be in the header file.
Simon Glass [Sat, 30 Jul 2022 21:52:25 +0000 (15:52 -0600)]
bootstd: Support bootflows with global bootmeths
Add support for handling this concept in bootflows. Update the 'bootflow'
command to allow only the normal bootmeths to be used. This alllows
skipping EFI bootmgr and VBE, for example.
Simon Glass [Sat, 30 Jul 2022 21:52:22 +0000 (15:52 -0600)]
bootstd: Allow EFI bootmgr to support an invalid bootflow
For most testing we don't want this bootmeth to actually do anything. For
the one test where we do, add a test hook to obtain the correct behaviour.
This will allow us to bind the device always, rather than just doing it
for this test.
Simon Glass [Sat, 30 Jul 2022 21:52:21 +0000 (15:52 -0600)]
bootstd: Allow bootmeths to be marked as global
The current way of handling things like EFI bootmgr is a bit odd, since
that bootmeth handles selection of the bootdev itself. VBE needs to work
the same way, so we should support it properly.
Add a flag that indicates that the bootmeth is global, rather than being
invoked on each bootdev. Provide a helper to read a bootflow from the
bootmeth.
Simon Glass [Sat, 30 Jul 2022 21:52:16 +0000 (15:52 -0600)]
bootstd: Drop delays in the tests
Some tests go as far as booting a distribution. In this case a menu is
presented to the user, with a two-second timeout. This adds a total of
12 seconds to the test runs at present.
Avoid this by inserting a response using the console-recording feature.
Simon Glass [Sat, 30 Jul 2022 21:52:13 +0000 (15:52 -0600)]
dm: core: Allow writing to a flat tree with ofnode
In generally it is not permitted to implement an ofnode function only for
flat tree or live tree. Both must be supported. Also the code for
live tree access should be in of_access.c rather than ofnode.c which is
really just for holding the API-conversion code.
Update ofnode_write_prop() accordingly and fix the test so it can work
with flat tree too.
Simon Glass [Sat, 30 Jul 2022 21:52:08 +0000 (15:52 -0600)]
dm: core: Introduce support for multiple trees
At present ofnode only works with a single device tree, for the most part.
This is the control FDT used by U-Boot.
When booting an OS we may obtain a different device tree and want to
modify it. Add some initial support for this into the ofnode API.
Note that we don't permit aliases in this other device tree, since the
of_access implementation maintains a list of aliases collected at
start-up. Also, we don't need aliases to do fixups in the other FDT. So
make sure that flat tree and live tree processing are consistent in this
area.
Simon Glass [Sat, 30 Jul 2022 21:52:07 +0000 (15:52 -0600)]
dm: core: Add a note about how livetree updates work
The unflattening algorithm results in a single block of memory being
allocated for the whole tree. When writing new properties, these are
allocated new memory outside that block. When the block is freed, the
allocated properties remain.
Document how this works and the potential memory leak, as well as
mentioning that updating the livetree is actually supported now.
Simon Glass [Sat, 30 Jul 2022 21:52:06 +0000 (15:52 -0600)]
dm: core: Split out the declaration of ofnode
This is used by a lot of files, but ofnode.h needs to include a lot of
header files. This can create dependency cycles, particularly with
global_data.h which must include various declarations.
Split the core delcarations into a separate file to fix this.
The booting flow is SPL -> OpenSBI -> U-Boot.
The boot hart may change after OpenSBI and may not always be hart0,
so wrap the related branch instruction with M-MODE.
Current DTB setup for XIP is not valid.
There is no chance for CONFIG_SYS_FDT_BASE, the DTB address used
in XIP mode, to be returned. Fix this.
Fixes: 2831fc2c4d19 ("riscv: Remove OF_PRIOR_STAGE from RISC-V boards") Signed-off-by: Rick Chen <rick@andestech.com> Signed-off-by: Leo Yu-Chi Liang <ycliang@andestech.com>
John Keeping [Thu, 28 Jul 2022 10:19:15 +0000 (11:19 +0100)]
boot: allow bootmeth-distro without CONFIG_NET
Remove the dependency on CMD_PXE from BOOTMETH_DISTRO by introducing a
new hidden kconfig symbol to control whether pxe_utils is compiled,
allowing bootstd's distro method to be compiled without needing
networking support enabled.
Signed-off-by: John Keeping <john@metanate.com> Reviewed-by: Tom Rini <trini@konsulko.com> Reviewed-by: Simon Glass <sjg@chromium.org>
Correct build errors when CMD_BOOTM is not enabled: Signed-off-by: Simon Glass <sjg@chromium.org>
lz4: Fix compile warning comparison of distinct pointer types
In file included from include/linux/bitops.h:22,
from include/log.h:15,
from include/linux/printk.h:4,
from include/common.h:20,
from lib/lz4_wrapper.c:6:
lib/lz4_wrapper.c: In function ‘ulz4fn’:
include/linux/kernel.h:184:17: warning: comparison of distinct pointer types lacks a cast
(void) (&_min1 == &_min2); \
^~
lib/lz4_wrapper.c:104:18: note: in expansion of macro ‘min’
size_t size = min((ptrdiff_t)block_size, end - out);
^~~
cmd: inconsistent return type of command_process()
The declarations in the header and in the implementation must match.
Reported-by: Sergei Antonov <saproj@gmail.com> Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com> Reviewed-by: Simon Glass <sjg@chromium.org>
Simon Glass [Mon, 1 Aug 2022 13:57:59 +0000 (07:57 -0600)]
test: Add some tests for kconfig.h
The macros in this file are a little confusing and we currently have no
tests to check that they work as expected.
Add some tests which check the macros in C code. Add a few tests which
check that the build errors are generated correctly too, using buildman's
-a option.
Patrice Chotard [Tue, 2 Aug 2022 08:21:35 +0000 (10:21 +0200)]
lmb: Fix LMB_MEMORY_REGIONS flag usage
This patch is fixing a broken boot observed on stm32mp157c-dk2 board.
IS_ENABLED macro should be used to check if a compilation flag is set
to "y" or "m".
LMB_MEMORY_REGIONS is set to a numerical value, IS_ENABLED macro is not
suitable in this case.
Fixes: 75c729cadc20 ("lmb: Fix lmb property's defination under struct lmb") Signed-off-by: Patrice Chotard <patrice.chotard@foss.st.com> Acked-by: Michal Simek <michal.simek@amd.com> Reviewed-by: Tom Rini <trini@konsulko.com>
Simon Glass [Wed, 3 Aug 2022 18:08:29 +0000 (12:08 -0600)]
Makefile: Correct the rule removing old of-platdata files
This makes use of makefile variables that don't exist anymore. Fix it and
also remove the object files in that directory.
Also add FORCE as a dependency as required by the if_changed macro.
Fixes ae639183906 ("Makefile: Remove old of-platdata files before regenerating") Reported-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com> Signed-off-by: Simon Glass <sjg@chromium.org>
Marek Vasut [Thu, 14 Jul 2022 23:58:24 +0000 (01:58 +0200)]
mmc: Do not send status of send_status is false
Commit d8fefc8a1fd ("mmc: Fix mmc_switch excessive timeout") introduced
a side effect where CMD13 SEND_STATUS is issued in case mmc_wait_dat0()
does not return -ENOSYS and $send_status is not set. This happens on all
hardware which does implement .mmc_wait_dat0 callback, e.g. i.MX8M .
This leads to lengthy timeout before booting OS in case of eMMC in one
of the HS200/HS400 modes, since the card cannot respond to CMD13 while
downgrading from HS200/HS400 to regular HS mode.
Fix this by adding the missing conditional.
Fixes: d8fefc8a1fd ("mmc: Fix mmc_switch excessive timeout") Signed-off-by: Marek Vasut <marex@denx.de> Cc: Jaehoon Chung <jh80.chung@samsung.com> Cc: Kirill Kapranov <kirill.kapranov@compulab.co.il> Cc: Marek Behún <marek.behun@nic.cz> Cc: Pantelis Antoniou <panto@antoniou-consulting.com> Cc: Ye Li <ye.li@nxp.com> Reviewed-by: Jaehoon Chung <jh80.chung@samsung.com>
Pali Rohár [Thu, 4 Aug 2022 11:03:44 +0000 (13:03 +0200)]
misc: atsha204a: Don't check for error when waking up the device
The device ignores any levels or transitions on the SCL pin when the device
is idle, asleep or during waking up.
Linux kernel driver for atsha204a (atmel-sha204a.ko) also ignores return
value from i2c wakeup send command, see:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/crypto/atmel-i2c.c?h=v5.19#n174
And also userspace Turris libatsha204 library ignores return value from
wakeup send command, see:
https://gitlab.nic.cz/turris/libatsha204/-/blob/v29.2/src/libatsha204/layer_ni2c.c#L75-76
U-Boot driver should do same thing.
Fixes waking up ATSHA204 on Turris 1.x boards.
Signed-off-by: Pali Rohár <pali@kernel.org> Reviewed-by: Stefan Roese <sr@denx.de> Tested-by: Paweł Anikiel <pan@semihalf.com> Reviewed-by: Marek Behún <kabel@kernel.org>
Pali Rohár [Thu, 4 Aug 2022 10:41:54 +0000 (12:41 +0200)]
arm64: a37xx: pinctrl: Fix definitions for MPP pins 20-22
All 3 MPP pins (20, 21 and 22) can be configured individually and also can
be configured to GPIO functions. Fix definitions for these MPP pins in
existing pin groups. After this change GPIO function can be enabled just
for one of these 3 pins.
Signed-off-by: Pali Rohár <pali@kernel.org> Reviewed-by: Stefan Roese <sr@denx.de>
Chris Packham [Thu, 4 Aug 2022 09:06:26 +0000 (21:06 +1200)]
ARM: kirkwood: SBx81LIFKW: disable KIRKWOOD_GPIO
DM_GPIO was already enabled so the MVEBU_GPIO was already available.
Having updated the board code to use the DM_GPIO APIs the KIRKWOOD_GPIO
driver became unnecessary. Disable it for SBx81LIFKW.
Signed-off-by: Chris Packham <judge.packham@gmail.com> Reviewed-by: Stefan Roese <sr@denx.de>
Pali Rohár [Wed, 3 Aug 2022 11:00:51 +0000 (13:00 +0200)]
arm: mvebu: Remove redundant u-boot, dm-pre-reloc from all 32-bit Armada SoCs
Replace it by including of mvebu-u-boot.dtsi file. When board does not use
-u-boot.dtsi then mvebu-u-boot.dtsi is included automatically by makefile
scripts/Makefile.lib.
Signed-off-by: Pali Rohár <pali@kernel.org> Reviewed-by: Stefan Roese <sr@denx.de> Tested-by: Stefan Roese <sr@denx.de>
Pali Rohár [Wed, 3 Aug 2022 11:00:50 +0000 (13:00 +0200)]
arm: mvebu: Introduce mvebu-u-boot.dtsi for 32-bit Armada SoCs
Set u-boot,dm-pre-reloc for /soc/, /soc/internal-regs/ and &uart0 nodes as
it is required on every 32-bit Armada SoCs. And set also u-boot,dm-pre-reloc
for &spi0 when going to boot from SPI because otherwise SPL SPI drivers do
not load.
Signed-off-by: Pali Rohár <pali@kernel.org> Reviewed-by: Stefan Roese <sr@denx.de> Tested-by: Stefan Roese <sr@denx.de>
Pali Rohár [Fri, 5 Aug 2022 11:37:25 +0000 (13:37 +0200)]
arm: mvebu: dts: Build only arch-compatible dts files
64-bit Armada DTS files are not build correctly during compilation of
32-bit Armada boards and vice versa. So fix makefile build system to
compile only those dts files which are compatible for the current build
(64-bit Armada DTS files only for 64-bit builds and 32-bit Armada DTS files
only for 32-bit builds).
Signed-off-by: Pali Rohár <pali@kernel.org> Reviewed-by: Stefan Roese <sr@denx.de>
Pali Rohár [Tue, 2 Aug 2022 09:55:19 +0000 (11:55 +0200)]
arm: mvebu: spl: Always fallback to BootROM boot method
BootROM boot method should always work so always add it as fallback method
to spl_boot_list. In case U-Boot SPI driver fails it is better to try using
BootROM than hanging as by default only one boot method is specified.
Signed-off-by: Pali Rohár <pali@kernel.org> Tested-by: Tony Dinh <mibodhi@gmail.com> Reviewed-by: Stefan Roese <sr@denx.de>
Pali Rohár [Mon, 1 Aug 2022 10:11:13 +0000 (12:11 +0200)]
gpio: turris_omnia_mcu: Fix usage of CMD_EXT_CONTROL
CMD_GENERAL_CONTROL takes two 8-bit arguments but CMD_EXT_CONTROL takes
two 16-bit arguments. Fix this issue and change CMD_EXT_CONTROL arguments
to 16-bit.
Fixes: c12d8a3b1405 ("gpio: Add Turris Omnia MCU driver") Signed-off-by: Pali Rohár <pali@kernel.org> Reviewed-by: Stefan Roese <sr@denx.de>
Pali Rohár [Mon, 1 Aug 2022 10:02:20 +0000 (12:02 +0200)]
arm: mvebu: turris_omnia: Increase fdt size in fixup_mtd_partitions
Sometimes fixup_mtd_partitions() prints during booting kernel error
"Failed fixing SPI NOR partitions!" because it does not have enough space
for creating all paritions nodes. So increase fdt size.
Fixes: 1f3c494182e8 ("arm: mvebu: turris_omnia: fixup MTD partitions in Linux' DTB") Signed-off-by: Pali Rohár <pali@kernel.org> Reviewed-by: Stefan Roese <sr@denx.de> Reviewed-by: Marek Behún <kabel@kernel.org>
arm: mvebu: turris_omnia: Add support for design with SW reset signals
New Turris Omnia HW board revision requires that software controls
peripheral reset signals, namely PERST# signals on mPCIe slots, ethernet
phy reset and lan switch reset. Those pins are connected to MCU controlled
by MCU i2c API as GPIOs. On new HW board revision those pins stay in reset
after board reset and software has to release these peripherals from reset
manually. MCU announce this requirement by FEAT_PERIPH_MCU bit in
CMD_GET_FEATURES command.
On older HW board revisions when FEAT_PERIPH_MCU is not announced, all
those reset signals are automatically released after board finish reset.
Detect FEAT_PERIPH_MCU bit in board_fix_fdt() and ft_board_setup()
functions and insert into device tree blob pcie "reset-gpios" and eth phy
"phy-reset-gpios" properties with corresponding MCU gpio definitions.
PCIe and eth PHY drivers then automatically release resets during device
initialization. Both U-Boot and Linux kernel drivers support those device
tree reset properties.
Initialization of lan switch on new HW board revision is more complicated.
Switch strapping pins are shared with switch RGMII pins. And strapping pins
must be in specific configuration after releasing switch reset. Due to pin
sharing, it is first required to switch A385 side of switch pins into GPIO
mode, set strapping configuration, release switch from reset and after that
switch A385 pins back to RGMII mode.
Because this complicated setup is not supported by switch DSA drivers and
cannot be expressed easily in device tree, implement it manually in SPL
function spl_board_init(). So in proper U-Boot and OS/kernel would be lan
switch initialized and be in same configuration like it was on old HW board
revisions (where reset sequence did those steps at hardware level).
Signed-off-by: Pali Rohár <pali@kernel.org> Reviewed-by: Stefan Roese <sr@denx.de> Reviewed-by: Marek Behún <kabel@kernel.org>
projects / uboot.git / log