This adds a new etype 'xilinx-bootgen'. By using this etype it is
possible to created an signed SPL (FSBL in Xilinx terms) for
ZynqMP boards.
The etype uses Xilinx Bootgen tools in order to transform the SPL into
a bootable image and sign the image with a given primary and secondary
public key. For more information to signing the FSBL please refer to the
Xilinx Bootgen documentation.
Here is an example of the etype in use:
spl {
filename = "boot.signed.bin";
xilinx-bootgen {
pmufw-filename = "pmu-firmware.elf";
psk-key-name-hint = "psk0";
ssk-key-name-hint = "ssk0";
auth-params = "ppk_select=0", "spk_id=0x00000000";
u-boot-spl-nodtb {
};
u-boot-spl-dtb {
};
};
};
For this to work the hash of the primary public key has to be fused
into the ZynqMP device and authentication (RSA_EN) has to be set.
For testing purposes: if ppk hash check should be skipped one can add
the property 'fsbl_config = "bh_auth_enable";' to the etype. However,
this should only be used for testing(!).
Signed-off-by: Lukas Funke <lukas.funke@weidmueller.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Add the Xilinx Bootgen as bintool. Xilinx Bootgen is used to create
bootable SPL (FSBL in Xilinx terms) images for Zynq/ZynqMP devices. The
btool creates a signed version of the SPL. Additionally to signing the
key source for the decryption engine can be passend to the boot image.
Signed-off-by: Lukas Funke <lukas.funke@weidmueller.com>
The nature of the network stack means that if we are going to use the
gadget mode USB network driver there's no easy path to implicitly
bind/unbind the driver. Enable the "bind" command by default here so
that we can bind/unbind this as needed.
Signed-off-by: Tom Rini <trini@konsulko.com>
Reviewed-by: Miquel Raynal <miquel.raynal@bootlin.com>
Move the ethernet gadget driver registration and removal from ethernet
bind and unbind callbacks into driver DM probe and remove callbacks.
This way, when the driver is bound, which is triggered deliberately
using 'bind' command, the USB ethernet gadget driver is instantiated
and bound to the matching UDC. In reverse, when the driver is unbound,
which is again triggered deliberately using 'unbind' command, the USB
ethernet gadget driver instance is removed.
Effectively, this now behaves like running either 'ums' or 'dfu' or
any other commands utilizing USB gadget functionality.
This also drops use of usb_gadget_release() and moves the use of
usb_gadget_initialize() into usb_ether_init() used only by legacy
platforms that do not use 'bind' command properly yet. Those have
no place in drivers.
Signed-off-by: Marek Vasut <marex@denx.de>
Tested-by: Tom Rini <trini@konsulko.com>
Reviewed-by: Tom Rini <trini@konsulko.com>
Move the driver probe function above the driver structure, so it
can be placed alongside other related functions, like upcoming
remove function. No functional change.
Signed-off-by: Marek Vasut <marex@denx.de>
Tested-by: Tom Rini <trini@konsulko.com>
Tested-by: Miquel Raynal <miquel.raynal@bootlin.com>
Tested-by: Miquel Raynal <miquel.raynal@bootlin.com>
Reviewed-by: Tom Rini <trini@konsulko.com>
These functions here are only ever called once since drop of non-DM
networking code. Inline them. No functional change.
Signed-off-by: Marek Vasut <marex@denx.de>
Tested-by: Tom Rini <trini@konsulko.com>
Tested-by: Miquel Raynal <miquel.raynal@bootlin.com>
Reviewed-by: Tom Rini <trini@konsulko.com>
Two Toradex platform series. First, to quote Andrejs:
This series adds Yavia Carrier board name string to the known
Toradex carrier board list, and reworks carrier board and display
adapter name handling.
And then to quote Marcel:
This series adds initial support for the Toradex Verdin AM62 SoM.
The first commit adds resp. PID4s to the ConfigBlock, the second one
fixes an early clocking issue confirmed to be a weird bug in TI's
scripting, the third one fixes some binman labeling issue. And last but
not least support for the Toradex Verdin AM62 is added.
This adds initial support for the Toradex Verdin AM62 Quad 1GB WB IT
V1.0A module and subsequent V1.1 launch configuration SKUs. They are
strapped to boot from their on-module eMMC. U-Boot supports booting
from the on-module eMMC only, DFU support is disabled for now due to
missing AM62x USB support.
The device trees were taken straight from Linux v6.5-rc1.
Boot sequence is:
SYSFW ---> R5 SPL (both in tiboot3.bin) ---> ATF (TF-A) ---> OP-TEE
---> A53 SPL (part of tispl.bin) ---> U-boot proper (u-boot.img)
Signed-off-by: Marcel Ziswiler <marcel.ziswiler@toradex.com>
Reviewed-by: Nishanth Menon <nm@ti.com>
Fix rcfg_yaml to really point to rm-cfg.yaml and pcfg_yaml to really
point to pm-cfg.yaml which likely is the intention.
While at it also add labels for the remaining items like custmpk_pem,
dkey_pem, bcfg_yaml_sysfw, scfg_yaml_sysfw, pcfg_yaml_sysfw and
rcfg_yaml_sysfw.
Signed-off-by: Marcel Ziswiler <marcel.ziswiler@toradex.com>
Reviewed-by: Neha Malcom Francis <n-francis@ti.com>
Reviewed-by: Nishanth Menon <nm@ti.com>
Fix second mux option of clkout0 which should really be
DEV_BOARD0_CLKOUT0_IN_PARENT_HSDIV4_16FFT_MAIN_2_HSDIVOUT1_CLK10
rather than twice the same according to [1].
[1] https://software-dl.ti.com/tisci/esd/latest/5_soc_doc/am62x/clocks.html#clocks-for-board0-device
Signed-off-by: Marcel Ziswiler <marcel.ziswiler@toradex.com>
Reviewed-by: Bryan Brattlof <bb@ti.com>
Reviewed-by: Nishanth Menon <nm@ti.com>
Rework the rather big array of zero length strings with 4 entries of
actual display adapter names to a array of structs which ties a pid4
to its correspondent human readable string.
Provide an accessor to get the string for a given PID4.
Signed-off-by: Max Krummenacher <max.krummenacher@toradex.com>
Signed-off-by: Andrejs Cainikovs <andrejs.cainikovs@toradex.com>
Rework the rather big array of zero length strings with 4 entries of
actual carrier board names to a array of structs which ties a pid4
to its correspondent human readable string.
Provide an accessor to get the string for a given PID4.
Rework the user of the information to use the accessor.
Note that check_pid8_sanity() is used for early samples of Dahlia and
the development board. Yavia isn't affected.
Signed-off-by: Max Krummenacher <max.krummenacher@toradex.com>
Signed-off-by: Andrejs Cainikovs <andrejs.cainikovs@toradex.com>
Add the Yavia Carrier board name string to the known carrier
board list.
Signed-off-by: Max Krummenacher <max.krummenacher@toradex.com>
Signed-off-by: Andrejs Cainikovs <andrejs.cainikovs@toradex.com>
The implementation in extlinux_pxe_getfile() does not pass a valid size
to bootmeth_read_file(), so this can fail if the uninited value happens to
be too small.
Fix this.
Signed-off-by: Simon Glass <sjg@chromium.org>
The implementation in distro_efi_try_bootflow_files() does not pass a
valid size to bootmeth_common_read_file(), so this can fail if the
uninted value happens to be too small.
Fix this.
This was reported by someone but I cannot now find the email.
Signed-off-by: Simon Glass <sjg@chromium.org>
The current bootflow-iteration algorithm reads the bootflow file into
an allocated memory buffer so it can be examined. This works well in
most cases.
However, while the common case is that the first bootflow is immediately
booted, it is also possible just to scan for available bootflows, perhaps
selecting one to boot later.
Even with the common case, EFI bootflows can be quite large. It doesn't
make sense to read it into an allocated buffer when we have kernel_addr_t
providing a suitable address for it. Even if we do have plenty of malloc()
space available, it is a violation of U-Boot's lazy-init principle to
read the bootflow before it is needed.
So overall it seems better to make a change.
Adjust the logic to read just the size of the EFI file at first. Later,
when the bootflow is booted, read the rest of the file into the designated
kernel buffer.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reported-by: Da Xue <da@libre.computer>
Reported-by: Vincent Stehlé <vincent.stehle@arm.com>
This checks for a network-based bootflow in two places, one of which is
less than ideal. Move the correct test into a function and use it in both
places.
Signed-off-by: Simon Glass <sjg@chromium.org>
If a driver cannot be bound, provide the driver name in the debug
message. Now the debug message may look like this:
(virtio-pci.l#0): virtio-rng driver not configured
Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
The FAT file systems uses character '\xe5' to mark a deleted directory
entry. If a file name starts with this character, it is substituted by
'\x05' in the directory entry.
While (signed char)'\xe5' is a negative number 0xe5 is a positive integer
number. We therefore have define a constant DELETED_MARK which matches the
signedness of the characters in the directory entry.
Correct a comparison where we used the constant 0xe5 with the wrong sign.
Use the constant aRING instead of 0x05 like in the rest of the code.
Reported-by: Dan Carpenter <dan.carpenter@linaro.org>
Fixes: 57b745e238 ("fs: fat: call set_name() only once")
Fixes: 28cef9ca2e ("fs: fat: create correct short names")
Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
As the defconfig files here have been removed we can also remove the
entries.
Signed-off-by: Tom Rini <trini@konsulko.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Given that we no longer have a configs/vexpress_aemv8a_defconfig file,
drop that and then include at least the aarch64-specific config.h file
here. Also move Linus and Peter up to the main entry as well so that
they'll get tagged for the board code too and not literally only the
defconfig.
Signed-off-by: Tom Rini <trini@konsulko.com>
Rajesh's email bounces. Remove his email from all boards he maintains.
Fortunately, he has co-maintainers on most boards. I have taken the
liberty of volunteering Pramod to maintain the LS1012AFRDM, since he
also maintains the LS1012AFRWY. Let me know if the board should be
orphaned instead.
Signed-off-by: Sean Anderson <sean.anderson@seco.com>
Merge in a series for MediaTek update and another for Ten64.
To quote Weijie Gao for MediaTek:
This patch series add support for MediaTek MT7988 SoC with its reference
boards and related drivers.
This patch series add basic boot support on eMMC/SD/SPI-NOR/SPI-NAND for
these boards. The clock, pinctrl drivers and the SoC initializaton code
are also included.
Product spec for MT7988:
https://www.mediatek.com/products/broadband-wifi/mediatek-filogic-880
And to quote Mathew McBride for Ten64:
This is a series of updates for the Ten64 board,
that are part of our firmware releases but not yet upstreamed
into U-Boot.
Changes of note include:
- Turning on standard boot support
Standard boot improves the user experience over distroboot on Ten64,
as we had various hacks in our firmware to solve some corner-case
issues (e.g DTB handling) in distroboot, which are not needed with the
bootflow system.
- Recognition of the new 'RevD' board variant distributed to OEM
customers
- Fixing various boot issues related to FIT images and operating systems
running out of the NAND (OpenWrt, recovery environment).
- A better 'opt-out' solution for fsl_setenv_bootcmd for Layerscape
platforms booting from TF-A.
This was discussed when the Ten64 was upstreamed into U-Boot. I think
declaring fsl_setenv_bootcmd as __weak and allowing individual boards
to override is the best way to do this without significant rework.
(We actually depend on a similar feature for the DPAA2/MC firmware
loading)
Compared to our firmware branch, there is still a few features missing (e.g USB
Hub, fan controller and fixes for the VSC8514). Some of these depend on other
things (like sorting out device tree schemas) so may not appear in mainline
U-Boot for a while yet.
The u-boot version of the LS1088A device tree has
an extra compatible (simple-mfd) added to &fsl_mc
to facilitate usage with U-Boot's device model.
Unfortunately FreeBSD will only match the single
"fsl,qoriq-mc" exactly when the node is a "bus"
object, so we need to strip out the extra compatible
before presenting it to the operating system.
Signed-off-by: Mathew McBride <matt@traverse.com.au>
Reviewed-by: Peng Fan <peng.fan@nxp.com>
Our bootcmd is the same regardless of where the SoC
loaded it's code from, so we don't want
fsl_setenv_bootcmd to do anything.
Signed-off-by: Mathew McBride <matt@traverse.com.au>
Reviewed-by: Peng Fan <peng.fan@nxp.com>
Allow individual Layerscape boards to opt-out of fsl_setenv_bootcmd
by declaring the original function as weak.
fsl_setenv_bootcmd is used to change the bootcmd based on the
TF-A boot source (e.g QSPI vs SD/MMC) for reasons including
secure boot / integrity measurements and DPAA2 configuration loading.
See previous discussion at [1].
On the Ten64 board, our bootcmd is the same across
all TF-A boot sources so we don't want this behaviour.
Signed-off-by: Mathew McBride <matt@traverse.com.au>
[1] https://patchwork.ozlabs.org/project/uboot/patch/20211110044639.7070-3-matt@traverse.com.au/#2790037
Reviewed-by: Peng Fan <peng.fan@nxp.com>
With the previous updates to the device tree, Ten64
can use Standard Boot 'out of the box'.
Signed-off-by: Mathew McBride <matt@traverse.com.au>
Reviewed-by: Peng Fan <peng.fan@nxp.com>
The watchdog driver was previously enabled but not used
until U-Boot's fsl-ls1088a.dtsi was updated to describe them.
Some Linux distributions (e.g Debian 11) do not engage the
SP805 watchdogs, causing unexpected resets after boot.
To conserve the user experience, turn off the autostart,
and we will provide a mechanism to turn them on at boot
via env vars.
Signed-off-by: Mathew McBride <matt@traverse.com.au>
Reviewed-by: Peng Fan <peng.fan@nxp.com>
The GE0 (first Gigabit Ethernet interface) is used as the
'serial number' for the board and appliance.
To ensure the 'true' board S/N is available regardless of how
the DPAA2 subsystem is configured, use serial# so it is passed in
the device tree.
Signed-off-by: Mathew McBride <matt@traverse.com.au>
Reviewed-by: Peng Fan <peng.fan@nxp.com>
On Ten64 boards, the "serial number" is the MAC address of the
first Gigabit Ethernet interface (labelled GE0 on the appliance),
and counted up from there.
The previous logic did not take into account U-Boot's ordering
of the network interfaces. By setting aliases/ethernetX in the device
tree we can ensure the U-Boot 'ethX' is the same as the labelled
port order on the unit, as well as the one adopted by Linux.
Signed-off-by: Mathew McBride <matt@traverse.com.au>
Ensure nvme devices are scanned before reaching the shell,
otherwise extra user intervention ("nvme scan") is required
before they are visible to bootdev/bootflow.
Signed-off-by: Mathew McBride <matt@traverse.com.au>
Reviewed-by: Peng Fan <peng.fan@nxp.com>
This restores NVMe functionality after PCI(e) NVMe support
was split out from the NVMe driver.
Signed-off-by: Mathew McBride <matt@traverse.com.au>
Reviewed-by: Peng Fan <peng.fan@nxp.com>
The recovery-firmware and OpenWrt-NAND do not yet have bootflow
/bootstd entrypoints, so add bootmenu entries to make them
accessible.
Signed-off-by: Mathew McBride <matt@traverse.com.au>
Reviewed-by: Peng Fan <peng.fan@nxp.com>
The default Ten64 MTD configuration reserves two ubifs partitions
for OpenWrt residing on NAND flash. Add the bootcmd for this system
into the default environment.
Signed-off-by: Mathew McBride <matt@traverse.com.au>
Reviewed-by: Peng Fan <peng.fan@nxp.com>
The recovery environment[1] on the Ten64 is a OpenWrt-
based ramdisk stored on the NAND intended to help with
system setup tasks.
Before the bootargs were not being set for the recovery
command, relying instead on the existing bootargs variable.
Ensure the bootargs are set correctly prior to booting recovery.
Signed-off-by: Mathew McBride <matt@traverse.com.au>
[1] https://ten64doc.traverse.com.au/software/recovery/
Reviewed-by: Peng Fan <peng.fan@nxp.com>
Change the firmware on microSD path to "firmware/traverse/ten64"
as per EBBR section 4.2[1].
The Traverse firmware tools now locate the DPAA2 firmware
and configuration files under that path on the rescue
SD card image.
If a user then installs a standard Linux
distribution over the top of that sdcard, (in theory)
it will be left alone by distribution boot tooling.
Signed-off-by: Mathew McBride <matt@traverse.com.au>
[1] https://arm-software.github.io/ebbr/index.html#firmware-partition-filesystem
Reviewed-by: Peng Fan <peng.fan@nxp.com>
The DPAA2 DPL (data plane layout) file was previously
being loaded into 0x80300000, and set to be applied
just before hand off to the kernel.
When a FIT image with a load_address of 0x80000000 was
booted with bootm, the DPL in memory was overwritten.
Move the DPL load to 0x8E000000 (196MiB away from 0x80000000,
and below the other typical load addr of 0x90000000).
Ideally in the future, the DPL lazyapply command
("fsl_mc lazyapply DPL $dpl_addr") should be set to
load the DPL contents into a memory area owned by U-Boot.
Signed-off-by: Mathew McBride <matt@traverse.com.au>
Reviewed-by: Peng Fan <peng.fan@nxp.com>
Board revision C (production) and later require the SFP+
retimer to be turned on (or reset) on boot, by way of issuing
a command to the board's microcontroller (via I2C).
The comparison statement here was incorrect, as the board
ID decrements every revision (from 0xFF downwards),
so this was matching board RevA,B,C instead of Rev >= C.
Another oops that transpired when working on this issue,
is that if the board controller is not called (such as
CONFIG_TEN64_CONTROLLER=n or earlier board rev), then
the retimer udevice was not obtained. So the board
version check has to be moved inside board_cycle_retimer
(which probes/fetches the retimer device) as well.
Signed-off-by: Mathew McBride <matt@traverse.com.au>
Ten64 board revision D is a variant that removes the USB hub
and PCIe expander/switch, but is otherwise compatible with the
main production "C" version.
At the same time, revise the printf specifiers (PCB version
"1064-0201%s") to reduce the number of string characters related
to the boot printout.
Signed-off-by: Mathew McBride <matt@traverse.com.au>
Reviewed-by: Peng Fan <peng.fan@nxp.com>
This patch adds general board files based on MT7988 SoCs.
MT7988 uses one mmc controller for booting from both SD and eMMC,
and the pins of mmc controller booting from SD are also shared with
one of spi controllers.
So two configs are need for these boot types:
1. mt7988_rfb_defconfig - SPI-NOR, SPI-NAND and eMMC
2. mt7988_sd_rfb_defconfig - SPI-NAND and SD
Signed-off-by: Weijie Gao <weijie.gao@mediatek.com>
This patch adds basic support for MediaTek MT7988 SoC.
This includes files that will initialize the SoC after boot and
its device tree.
Signed-off-by: Weijie Gao <weijie.gao@mediatek.com>
This patch converts magic and version fields of ghf common header
to one field with the type of uint32_t to make this header flexible
for futher updates.
Signed-off-by: Weijie Gao <weijie.gao@mediatek.com>
