U-Boot for Turris Omnia is always compiled with MMC, SCSI and USB support,
so always enable macros for booting from these devices.
Signed-off-by: Pali Rohár <pali@kernel.org>
CONFIG_ETHPRIME defines primary ethernet device and env variable $ethact
stores currently active ethernet device.
So there is no point to set ethact= in default environment. Instead set
CONFIG_ETHPRIME properly.
Signed-off-by: Pali Rohár <pali@kernel.org>
Reviewed-by: Marek Behún <marek.behun@nic.cz>
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:
=> setenv omnia_wwan_slot usb3
=> saveenv
=> reset
Signed-off-by: Pali Rohár <pali@kernel.org>
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.
Signed-off-by: Pali Rohár <pali@kernel.org>
Move code for disabling sata and pcie DT nodes to own functions, so this
code can be called from other places in follow up patches.
Signed-off-by: Pali Rohár <pali@kernel.org>
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:
=> setenv omnia_msata_slot pcie
=> saveenv
=> reset
Signed-off-by: Pali Rohár <pali@kernel.org>
By default use primary serdes map with PCIe function in combined
miniPCIe/mSATA slot. When SATA is detected change serdes map variable at
runtime.
Signed-off-by: Pali Rohár <pali@kernel.org>
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>
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.
Signed-off-by: Pali Rohár <pali@kernel.org>
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
-----BEGIN PGP SIGNATURE-----
iQIzBAABCAAdFiEEbcT5xx8ppvoGt20zxIHbvCwFGsQFAmJr9IkACgkQxIHbvCwF
GsSk1A/+OfrvC92hBSGk6WdyVAjdpkOZRJ2SghMaC7k1bA+Me8zj+8oKW78qqH5o
5ylL4F68Cp0h8esFLaqXCj8Een2atmQzwOdj8MFqIZaLxjawTZ96P6dkFD27S6m9
egUOM0fpiCDc5aLPU090adFXhst0bZoxgnss+UofHaAbGVTlKVfuvpG28wgUNNi5
kbSj4Pu1DpQbTYHBvKFoIkKY7+isjuaIlhoQtMO8zfvXgqZuYJGcIml+JJHUJ6S1
uqwxDEJSwZu6qKNMdmogPBrxM1HHjSg31JB/WMjsd0aSC0ud+3PeZNohvLY3tEei
KUXW6hEyunKbme/sg7DXk1tkr8izd/paA/pyPpAcvFKPpWLBSBIJAxtbMkJCg8Zd
pl5uSBUgfGRk9nf0F0+zxQCfdTffFKBRu/t0TGr+h1NZdMYi73CbiZ9vHJbJLuro
cLN9hXwY+Ap0DialHrRqes4uqjHAIM7Tj3gEEx0+emukY0CT67uum2HtLHm+OzaD
B5J8sOzEhJRCqBh3E4qap2Q4+weE2LVF4Nza7wchZGv5/LiPES3gGcdyZHpwKebl
vPc09GnaQZp5hyejOh/1c8/tJCm/CFffwNzrYqbCsKqVSGOVxyYnPl4eelP13oHs
6YYyZ3+h+JuFwQon51mGjPMVZCVz9ObOQMbBACpcInymhcy8bks=
=IdkS
-----END PGP SIGNATURE-----
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
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.
Use-after-free shouldn't be used, even in tests. It's bad practice and
makes the test brittle.
Signed-off-by: Andrew Scull <ascull@google.com>
Cc: Simon Glass <sjg@chromium.org>
Reviewed-by: Simon Glass <sjg@chromium.org>
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>
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>
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>
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>
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>
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>
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_init_early() creates an event hook for block device probing.
It has to be called before any block device is probed.
Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
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 d97e98c887 ("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>
If the path consists only of an end node, it does not refer to a partition.
Avoid returning a random value from the stack in this case.
Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
The log functions print file name, line number, and function name if
selected via the log command or customizing. Don't print the function
name twice.
Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
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>
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>
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>
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>
Since 2d1deaf88e ("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: 2d1deaf88e ("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>
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: 72675b063b ("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>
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>
-----BEGIN PGP SIGNATURE-----
iQFQBAABCgA6FiEEqxhEmNJ6d7ZdeFLIHrMeAg6sL8gFAmJnmF8cHGV1Z2VuLmhy
aXN0ZXZAbWljcm9jaGlwLmNvbQAKCRAesx4CDqwvyOXHCACYH5s6xsbp+vXFXOUb
aPuLcidQXQLbK6akK7b8chJgXbXw0h/4aJzwv5HyXiTHUtMF4+JfkEwsn7tGjC74
lcqeaV3/UaKkp6qA64xA6Nw3uhL8Qd81iFVcKMy7sG0uEVM+DnDwyynFsz/IqUkK
+kaPJKwSTz4xzbbNEeWo7ZPDy71ptHFwVt0rQqCDCEdhi9nB7lG1kHxMxb54CRaD
cce3mpPl782wMEvwety9o8MmPx8ieydT9joQwS9hwaBSOPLn/bjXtQfZog56DyVp
7mo1nZWJDKaeDCQqbxUszLGRNoPZfmiFVHDJ9Ph5sih8PA461xMyXWWGZcR9LEgL
03Ok
=HyYz
-----END PGP SIGNATURE-----
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)
It looks quite weird that for non PPC platforms cpu driver for MPC83xx can
be selected. That's why define proper dependency.
Signed-off-by: Michal Simek <michal.simek@xilinx.com>
Reviewed-by: Tom Rini <trini@konsulko.com>
Reviewed-by: Priyanka Jain <priyanka.jain@nxp.com>
Manish Tomar's email bounces. Remove it, and reassign the config he was
maintaining to the primary maintainer for the board.
Signed-off-by: Sean Anderson <sean.anderson@seco.com>
Reviewed-by: Priyanka Jain <priyanka.jain@nxp.com>
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.
Signed-off-by: Pali Rohár <pali@kernel.org>
Reviewed-by: Priyanka Jain <priyanka.jain@nxp.com>
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.
Signed-off-by: Pali Rohár <pali@kernel.org>
Reviewed-by: Priyanka Jain <priyanka.jain@nxp.com>
interrupts property for spi@7000 node is needed for compatibility with
Linux kernel.
Signed-off-by: Pali Rohár <pali@kernel.org>
Reviewed-by: Priyanka Jain <priyanka.jain@nxp.com>
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.
Signed-off-by: Pali Rohár <pali@kernel.org>
Reviewed-by: Priyanka Jain <priyanka.jain@nxp.com>
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.
Signed-off-by: Pali Rohár <pali@kernel.org>
Reviewed-by: Priyanka Jain <priyanka.jain@nxp.com>
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.
Signed-off-by: Pali Rohár <pali@kernel.org>
Reviewed-by: Priyanka Jain <priyanka.jain@nxp.com>
