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>
This patch adds support for MediaTek MT7988.
MT7988 features MediaTek NETSYS v3, including three GMACs, and two
of them supports 10Gbps USXGMII.
MT7988 embeds a MT7531 switch (not MCM) which supports accessing
internal registers through MMIO instead of MDIO.
Signed-off-by: Weijie Gao <weijie.gao@mediatek.com>
MT7981 has its GMAC2 PHY shared with USB3. To enable GMAC2, mux
register must be set to connect the SGMII phy to GMAC2.
Signed-off-by: Weijie Gao <weijie.gao@mediatek.com>
Now that individual 2.5Gbps SGMII support has been added to
mtk-eth, all boards that use 2.5Gbps link with mt7531 must be
converted to use "2500base-x" instead of "sgmii".
Signed-off-by: Weijie Gao <weijie.gao@mediatek.com>
Existing SGMII support of mtk-eth is actually a MediaTek-specific
2.5Gbps high-speed SGMII (HSGMII) which does not support
auto-negotiation mode.
This patch adds SGMII 1Gbps auto-negotiation mode and rename the
existing HSGMII to 2500basex.
Signed-off-by: Weijie Gao <weijie.gao@mediatek.com>
mt7531_mmd_ind_read and mt753x_switch_init are defined without static.
Since they're not used outside this file, we should add them back.
Signed-off-by: Weijie Gao <weijie.gao@mediatek.com>
fixup to add static qualifier
The original direct MDIO clause 45 access via SoC is missing the
data output. This patch adds it back to ensure MDIO clause 45 can
work properly for external PHYs.
Signed-off-by: Weijie Gao <weijie.gao@mediatek.com>
Not all switches requires 1 second delay after deasserting reset.
MT7531 requires only maximum 200ms.
This patch defines dedicated reset wait time for each switch chip, and will
significantly improve the boot time for boards using MT7531.
Signed-off-by: Weijie Gao <weijie.gao@mediatek.com>
So far the switch is initialized in probe stage and is connected to PSE
unconditionally. This will cause all packets being flooded to PSE and may
cause PSE hang before entering linux.
This patch changes the connection between switch and PSE:
- Still initialize switch in probe stage, but disconnect it with PSE
- Connect switch with PSE on eth start
- Disconnect on eth stop
Signed-off-by: Weijie Gao <weijie.gao@mediatek.com>
The original mediatek pinctrl functions for driving configuration
'mtk_pinconf_drive_set_*' do not return -ENOSUPP even if input
parameters are not supported.
This patch fixes the return value in those functions.
Signed-off-by: Sam Shih <sam.shih@mediatek.com>
Signed-off-by: Weijie Gao <weijie.gao@mediatek.com>
There exists a situation of the mediatek pinctrl driver that may return
wrong pin function value for the pinmux driver:
- All pin function arrays are defined without const
- Some pin function arrays contain all-zero value, e.g.:
static int mt7622_spi_funcs[] = { 0, 0, 0, 0, 0, 0, };
- These arrays will be put into .bss section during compilation
- .bss section has no "a" attribute and does not exist in the final binary
file after objcopy.
- FDT binary blob is appended to the u-boot binary, which occupies the
.bss section.
- During board_f stage, .bss has not been initialized, and contains the
data of FDT, which is not full-zero data.
- pinctrl driver is initialized in board_f stage, and it will get wrong
data if another driver is going to set default pinctrl.
Since pinmux information and soc data are only meant to be read-only, thus
should be declared as const. This will force all pinctrl data being put
into .rodata section. Since .rodata has "a" attribute, even the all-zero
data will be allocated and filled with correct value in to u-boot binary.
Signed-off-by: Weijie Gao <weijie.gao@mediatek.com>
MT7981 actually uses MediaTek I2C controller v3 instead of v1.
This patch adds support for I2C controller v3 fix fixes the I2C usability
for MT7981.
Signed-off-by: Sam Shih <sam.shih@mediatek.com>
Signed-off-by: Weijie Gao <weijie.gao@mediatek.com>
This patch add missing return value check for allocating the driver's
private data. -ENOMEM will be returned if malloc() fails.
Signed-off-by: Sam Shih <sam.shih@mediatek.com>
Signed-off-by: Weijie Gao <weijie.gao@mediatek.com>
This patch ensures driver private data being fully initialized in
_debug_uart_init which is not covered by .priv_auto ops.
Signed-off-by: Sam Shih <sam.shih@mediatek.com>
Signed-off-by: Weijie Gao <weijie.gao@mediatek.com>
Reviewed-by: Stefan Roese <sr@denx.de>
In u-boot we don't use IRQ. Instead, we poll busy bit in SPI_STATUS.
However these IRQ enable bits may be set in previous boot stage (BootROM).
If we leave these bits not cleared, although u-boot has disabled IRQ and
nothing will happen, the linux kernel may encounter panic during
initializing the spim driver due to IRQ event happens before IRQ handler
is properly setup.
This patch clear IRQ bits to prevent this from happening.
Signed-off-by: SkyLake.Huang <skylake.huang@mediatek.com>
Signed-off-by: Weijie Gao <weijie.gao@mediatek.com>
Reviewed-by: Jagan Teki <jagan@amarulasolutions.com>
We don't really need to switch clk rate during operating SPIM controller.
Get clk rate only once at driver probing.
Signed-off-by: SkyLake.Huang <skylake.huang@mediatek.com>
Signed-off-by: Weijie Gao <weijie.gao@mediatek.com>
Reviewed-by: Jagan Teki <jagan@amarulasolutions.com>
Now we use fdtdec_setup_mem_size_base() to get DRAM base from fdt ram node
and update gd->ram_base. CFG_SYS_SDRAM_BASE is unused and will be removed.
Also, since mt7622 always passes fdt to linux kernel, there's no need to
assign value to gd->bd->bi_boot_params.
Signed-off-by: Weijie Gao <weijie.gao@mediatek.com>
Three boards use a phandle in a FIT generator and the maintainer is
away. For now, add a hack to allow this.
Signed-off-by: Simon Glass <sjg@chromium.org>
device_probe() called by the 'bootdev info' command
returns 0 or a negative error code.
itoa() cannot print negative numbers.
Convert the error code to a positive number.
Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
uclass_get_device_by_name() is meant to return 0 or a negative error code.
simple_itoa() cannot handle negative numbers.
This leads to output like:
=> bootdev list -p
Seq Probed Status Uclass Name
--- ------ ------ -------- ------------------
c [ ] 18446744073709551614 spi_flash spi.bin@0.bootdev
Convert the status to a positive number. Now we get
Seq Probed Status Uclass Name
--- ------ ------ -------- ------------------
c [ ] 2 spi_flash spi.bin@0.bootdev
Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
This provides support for phandles to be copied over from templates. This
is not quite safe, since if the template is instantiated twice (i.e. in
two different nodes), then duplicate phandles will be found. This will
result in an error.
Signed-off-by: Simon Glass <sjg@chromium.org>
It is not necessary to keep templates around after they have been
processed. They can cause confusion and potentially duplicate phandles.
Remove them.
Use the same means of detecting a template node in _ReadImageDesc so that
the two places are consistent.
Signed-off-by: Simon Glass <sjg@chromium.org>
Allow phandles to be copied over from a template. This can potentially
cause duplicate phandles, so detect this and report an error.
Signed-off-by: Simon Glass <sjg@chromium.org>
