The FWU Multi Bank Update feature allows the platform to boot the
firmware images from one of the partitions(banks). The first stage
bootloader(fsbl) passes the value of the boot index, i.e. the bank
from which the firmware images were booted from to U-Boot. On the
STM32MP157C-DK2 board, this value is passed through one of the SoC's
backup register. Add a function to read the boot index value from the
backup register.
Signed-off-by: Sughosh Ganu <sughosh.ganu@linaro.org>
Reviewed-by: Patrick Delaunay <patrick.delaunay@foss.st.com>
Acked-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
Acked-by: Etienne Carriere <etienne.carriere@linaro.org>
Enabling capsule update functionality on the platform requires
populating information on the images that are to be updated using the
functionality. Do so for the DK2 board.
Signed-off-by: Sughosh Ganu <sughosh.ganu@linaro.org>
Reviewed-by: Patrick Delaunay <patrick.delaunay@foss.st.com>
Reviewed-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
Reviewed-by: Etienne Carriere <etienne.carriere@linaro.org>
The current name is inconsistent with SPL which uses CONFIG_SPL_TEXT_BASE
and this makes it imposible to use CONFIG_VAL().
Rename it to resolve this problem.
Signed-off-by: Simon Glass <sjg@chromium.org>
BCM6753 is essentially same as the main chip BCM6855 but with different
SKU number. Now that BCM6855 is supported under CONFIG_ARCH_BCMBCA and
CONFIG_BCM6855, remove the original ARCH_BCM6753 support and migrate its
configuration and dts settings. This includes:
- Remove the bcm96753ref board folder. It is replaced by the
generic bcmbca board folder.
- Merge the 6753.dtsi setting to the new 6855.dtsi file. Update
96753ref board dts with the new compatible string.
- Delete broadcom_bcm96763ref.h and merge its setting to the new
bcm96855.h file.
- Delete bcm96753ref_ram_defconfig and use a basic config version of
bcm96855_defconfig
Signed-off-by: William Zhang <william.zhang@broadcom.com>
Reviewed-by: Philippe Reynes <philippe.reynes@softathome.com>
BCM6855 is a Broadcom ARM A7 based PON Gateway SoC. It is part of the
BCA (Broadband Carrier Access origin) chipset family. Like other
broadband SoC, this patch adds it under CONFIG_BCM6855 chip config and
CONFIG_ARCH_BCMBCA platform config.
This initial support includes a bare-bone implementation and dts with
CPU subsystem, memory and ARM PL101 uart. This SoC is supported in the
linux-next git repository so the dts and dtsi files are copied from linux.
The u-boot image can be loaded from flash or network to the entry point
address in the memory and boot from there to the console.
Signed-off-by: William Zhang <william.zhang@broadcom.com>
Reviewed-by: Philippe Reynes <philippe.reynes@softathome.com>
Now that BCM6858 is supported under CONFIG_ARCH_BCMBCA and
CONFIG_BCM6858, remove the original ARCH_BCM6858 support and migrate its
configuration and dts settings. This includes:
- Remove the bcm968580xref board folder. It is replaced by the generic
bcmbca board folder.
- Update bcm968580xref board dts with the new compatible string.
- Delete broadcom_bcm968580xref.h and merge its setting to the new
bcm96858.h file.
- Remove bcm968580xref_ram_defconfig as a basic config version of
bcm96858_defconfig is now added.
Signed-off-by: William Zhang <william.zhang@broadcom.com>
Reviewed-by: Philippe Reynes <philippe.reynes@softathome.com>
BCM6858 is a Broadcom B53 based PON Gateway SoC. It is part of the BCA
(Broadband Carrier Access origin) chipset family. Like other broadband
SoC, this patch adds it under CONFIG_BCM6858 chip config and
CONFIG_ARCH_BCMBCA platform config.
This initial support includes a bare-bone implementation and the
original dts is updated with the one from linux next git repository.
The u-boot image can be loaded from flash or network to the entry point
address in the memory and boot from there to the console.
Signed-off-by: William Zhang <william.zhang@broadcom.com>
Reviewed-by: Philippe Reynes <philippe.reynes@softathome.com>
BCM68360 is a variant within the BCM6856 chip family. Now that BCM6856
is supported under CONFIG_ARCH_BCMBCA and CONFIG_BCM6856, remove the
original ARCH_BCM68360 support and migrate its configuration and dts
settings. This includes:
- Remove the bcm968360bg board folder. It is replaced by the generic
bcmbca board folder.
- Merge the 68360.dtsi setting to the new 6856.dtsi file. Update board
dts with the new compatible string.
- Merge broadcom_bcm968360bg.h setting to the new bcm96856.h file.
- Remove bcm968360bg_ram_defconfig as a basic config version of
bcm96856_defconfig is now added.
Signed-off-by: William Zhang <william.zhang@broadcom.com>
Reviewed-by: Philippe Reynes <philippe.reynes@softathome.com>
BCM6856 is a Broadcom B53 based PON Gateway SoC. It is part of the BCA
(Broadband Carrier Access origin) chipset family. Like other Broadband
SoC, this patch adds it under CONFIG_BCM6856 chip config and
CONFIG_ARCH_BCMBCA platform config.
This initial support includes a bare-bone implementation and dts with
CPU subsystem, memory and Broadcom uart. This SoC is supported in the
linux-next git repository so the dts and dtsi files are copied from
linux.
The u-boot image can be loaded from flash or network to the entry point
address in the memory and boot from there to the console.
Signed-off-by: William Zhang <william.zhang@broadcom.com>
Reviewed-by: Philippe Reynes <philippe.reynes@softathome.com>
BCM63158 carries the CONFIG_SYSRESET from the original configuration. It
provide reset_cpu function already so need to define weak version of the
dummy reset_cpu for other BCMBCA SoCs to avoid linking error.
Signed-off-by: William Zhang <william.zhang@broadcom.com>
Reviewed-by: Philippe Reynes <philippe.reynes@softathome.com>
Now that BCM63158 is supported under CONFIG_ARCH_BCMBCA and
CONFIG_BCM63158, remove the original ARCH_BCM63158 support and migrate
configuration settings.
Signed-off-by: William Zhang <william.zhang@broadcom.com>
Reviewed-by: Philippe Reynes <philippe.reynes@softathome.com>
BCM63158 is a Broadcom B53 based DSL Gateway SoC. It is part of the
BCA (Broadband Carrier Access origin) chipset family. Like other
Broadband SoC, this patch adds it under CONFIG_BCM63158 chip
config and CONFIG_ARCH_BCMBCA platform config.
This initial support includes a bare-bone implementation and dts with
CPU subsystem, memory and ARM PL011 uart. This SoC is supported in the
linux-next git repository so the dts and dtsi files are copied from
linux.
The u-boot image can be loaded from flash or network to the entry
point address in the memory and boot from there to the console.
Signed-off-by: William Zhang <william.zhang@broadcom.com>
Reviewed-by: Philippe Reynes <philippe.reynes@softathome.com>
BCM4908 is a Broadcom B53 based WLAN AP router SoC. It is part of the
BCA (Broadband Carrier Access origin) chipset family so it's added
under ARCH_BCMBCA platform. This initial support includes a bare-bone
implementation and dts with CPU subsystem, memory and Broadcom uart.
This SoC is supported in the linux git repository so the dts and dtsi
files are stripped down version of linux copies with mininum blocks
needed by u-boot.
The u-boot image can be loaded from flash or network to the entry point
address in the memory and boot from there to the console.
Signed-off-by: William Zhang <william.zhang@broadcom.com>
Reviewed-by: Florian Fainelli <f.fainelli@gmail.com>
BCM6813 is a Broadcom B53 based PON and WLAN AP router SoC. It is part
of the BCA (Broadband Carrier Access origin) chipset family so it's
added under ARCH_BCMBCA platform. This initial support includes a
bare-bone implementation and dts with CPU subsystem, memory and ARM
PL011 uart.
This SoC is supported in the linux-next git repository so the dts and
dtsi files are copied from linux.
The u-boot image can be loaded from flash or network to the entry point
address in the memory and boot from there to the console.
Signed-off-by: William Zhang <william.zhang@broadcom.com>
Reviewed-by: Florian Fainelli <f.fainelli@gmail.com>
BCM4912 is a Broadcom B53 based WLAN AP router SoC. It is part of the
BCA (Broadband Carrier Access origin) chipset family so it's added under
ARCH_BCMBCA platform. This initial support includes a bare-bone
implementation and dts with CPU subsystem, memory and ARM PL011 uart.
This SoC is supported in the linux-next git repository so the dts
and dtsi files are copied from linux.
The u-boot image can be loaded from flash or network to the entry
point address in the memory and boot from there to the console.
Signed-off-by: William Zhang <william.zhang@broadcom.com>
Reviewed-by: Florian Fainelli <f.fainelli@gmail.com>
BCM63146 is a Broadcom B53 based DSL Broadband SoC. It is part of the
BCA (Broadband Carrier Access origin) chipset family so it's added under
ARCH_BCMBCA platform. This initial support includes a bare-bone
implementation and dts with CPU subsystem, memory and ARM PL011 uart.
This SoC is supported in the linux-next git repository so the dts and
dtsi files are copied from linux.
The u-boot image can be loaded from flash or network to the entry point
address in the memory and boot from there to the console.
Signed-off-by: William Zhang <william.zhang@broadcom.com>
Reviewed-by: Florian Fainelli <f.fainelli@gmail.com>
BCM63138 is an ARM A9 based DSL Broadband SoC. It is part of the BCA
(Broadband Carrier Access origin) chipset family so it's added under
ARCH_BCMBCA platform. This initial support includes a bare-bone
implementation and dts with CPU subsystem, memory, ARM A9 global timer
and Broadcom uart.
This SoC is supported in the linux-next git repository so the dts and
dtsi files are stripped down version of linux copies with mininum blocks
needed by u-boot.
The u-boot image can be loaded from flash or network to the entry point
address in the memory and boot from there to the console.
This patch applies on top of the my previous patch [1].
[1] https://lists.denx.de/pipermail/u-boot/2022-August/490570.html
Signed-off-by: William Zhang <william.zhang@broadcom.com>
Reviewed-by: Florian Fainelli <f.fainelli@gmail.com>
Reviewed-by: Philippe Reynes <philippe.reynes@softathome.com>
BCM63148 is an Broadcom B15 based DSL Broadband SoC. It is part of the
BCA (Broadband Carrier Access origin) chipset family so it's added under
ARCH_BCMBCA platform. This initial support includes a bare-bone
implementation and dts with CPU subsystem, memory and Broadcom uart.
This SoC is supported in the linux-next git repository so the dts and
dtsi files are copied from linux.
The u-boot image can be loaded from flash or network to the entry point
address in the memory and boot from there.
Signed-off-by: William Zhang <william.zhang@broadcom.com>
BCM6756 is an ARM A7 based WLAN Gateway and Access Point Broadband SoC.
It is part of the BCA(Broadband Carrier Access origin) chipset family so
it's added under ARCH_BCMBCA platform. This initial support includes a
bare-bone implementation and dts with CPU subsystem, memory and ARM
PL011 uart.
This SoC is supported in the linux-next git repository so the dts and
dtsi files are copied from linux.
The u-boot image can be loaded from flash or network to the entry
point address in the memory and boot from there.
Signed-off-by: William Zhang <william.zhang@broadcom.com>
BCM6878 is an ARM A7 based PON Broadband SoC. It is part of the BCA
(Broadband Carrier Access origin) chipset family so it's added under
ARCH_BCMBCA platform. This initial support includes a bare-bone
implementation and dts with CPU subsystem, memory and ARM PL011
uart.
This SoC is supported in the linux-next git repository so the dts and
dtsi files are copied from linux with minor fix-up that needs to be
upstreamed to linux as well.
The u-boot image can be loaded from flash or network to the entry point
address in the memory and boot from there.
Signed-off-by: William Zhang <william.zhang@broadcom.com>
BCM6846 is an ARM A7 based PON Broadband SoC. It is part of the BCA
(Broadband Carrier Access origin) chipset family so it's added under
ARCH_BCMBCA platform. This initial support includes a bare-bone
implementation and dts with CPU subsystem, memory and Broadcom uart.
This SoC is supported in the linux-next git repository so the dts and
dtsi files are copied from linux with minor fix-up that needs to be
upstreamed to linux as well.
The u-boot image can be loaded from flash or network to the entry point
address in the memory and boot from there.
Signed-off-by: William Zhang <william.zhang@broadcom.com>
BCM63178 is an ARM A7 based DSL Broadband SoC. It is part of the BCA
(Broadband Carrier Access origin) chipset family so it's added under
ARCH_BCMBCA platform. This initial support includes a bare-bone
implementation and dts with CPU subsystem, memory and ARM PL011 uart.
This SoC is supported in the linux-next git repository so the dts and
dtsi files are copied from linux with minor fix-up that needs to be
upstreamed to linux as well.
The u-boot image can be loaded from flash or network to the entry
point address in the memory and boot from there.
Signed-off-by: William Zhang <william.zhang@broadcom.com>
- simplefb rotation support
- support splash as raw image from MMC
- enhancements to Truetype console (multiple fonts and sizes)
- drop old LCD support
-----BEGIN PGP SIGNATURE-----
iGwEABECACwWIQSC4hxrSoIUVfFO0kRM6ATMmsalXAUCY17nfA4cYWd1c3RAZGVu
eC5kZQAKCRBM6ATMmsalXPPoAJ0UYyt3kwslUlAJhOC+KU9UlYnVuwCbBXIQyBua
K5clq+GyxXfaDl2Hnvc=
=XXVp
-----END PGP SIGNATURE-----
Merge tag 'video-20221030' of https://source.denx.de/u-boot/custodians/u-boot-video
- fix [hv]sync active vs back porch in dw_mipi_dsi
- simplefb rotation support
- support splash as raw image from MMC
- enhancements to Truetype console (multiple fonts and sizes)
- drop old LCD support
This option should not have the SYS_ in it. Drop it so it fits in with the
other video options.
Also simplify the alignment code in gunzip_bmp(), since malloc() always
returns a 32-bit-aligned pointer.
Signed-off-by: Simon Glass <sjg@chromium.org>
Layerscape update
- support sysreset,
- de-select FSL_IFC when booting from SD
- disable unused parts of ICID tables
- reduce ns_dev size for csu
- enable dma snooping for ls104x
- nand driver fixups for ls1043ardb rev 7.0 boards.
The GW7904 is based on the i.MX 8M Mini SoC featuring:
- LPDDR4 DRAM
- eMMC FLASH
- microSD connector with UHS support
- LIS2DE12 3-axis accelerometer
- Gateworks System Controller
- IMX8M FEC
- 2x RS232 off-board connectors
- PMIC
- 10x bi-color LED's
- 1x miniPCIe socket with PCIe and USB2.0
- 802.3at Class 4 PoE
- 10-30VDC input via barrel-jack
Signed-off-by: Tim Harvey <tharvey@gateworks.com>
i.Core MX8M Plus is an EDIMM SoM based on NXP i.MX8M Plus from Engicam.
i.Core MX8M Plus needs to mount on top of this Evaluation board for
creating complete i.Core MX8M Plus EDIMM2.2 Starter Kit.
Add support for it.
Signed-off-by: Jagan Teki <jagan@amarulasolutions.com>
Signed-off-by: Manoj Sai <abbaraju.manojsai@amarulasolutions.com>
The GW7903 has a BD71847 PMIC on I2C1. Adjust the model compare strings
to add it.
Signed-off-by: Tim Harvey <tharvey@gateworks.com>
Reviewed-by: Fabio Estevam <festevam@denx.de>
Reviewed-by: Jaehoon Chung <jh80.chung@samsung.com>
Building with GCC 12.2 results in an error
board/gateworks/gw_ventana/gw_ventana.c:636:68: error: the comparison
will always evaluate as 'true' for the address of 'pwm_padmux' will
never be NULL [-Werror=address]
636 | } else if (hwconfig_subarg_cmp(arg, "mode", "pwm") &&
| ^~
Remove the superfluous check.
Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
Reviewed-By: Tim Harvey <tharvey@gateworks.com>
Reviewed-by: Fabio Estevam <festevam@denx.de>
There are no platforms that have not migrated to using DM_KEYBOARD,
remove the legacy option.
Cc: Simon Glass <sjg@chromium.org>
Signed-off-by: Tom Rini <trini@konsulko.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Fix the MMC env device for boards with eMMC by adding a
board_mmc_get_env_dev override to return the boot device as the
MMC env device.
Signed-off-by: Tim Harvey <tharvey@gateworks.com>
Add an entry for USB boot so that U-Boot could be loaded via
the Serial Download Protocol.
Signed-off-by: Fabio Estevam <festevam@denx.de>
Reviewed-by: Peng Fan <peng.fan@nxp.com>
The current implementation of spl_board_init() USB boot handling is
not correct, the MX8MM BootROM v1 does not support SDP load when
re-entered from U-Boot SPL, it is up to U-Boot to perform the next
stage load using its own internal CI gadget driver and SDP protocol
implementation. Drop the spl_board_init() to let SPL continue with
normal load in case the SDP support is enabled.
Signed-off-by: Marek Vasut <marex@denx.de>
Reviewed-by: Peng Fan <peng.fan@nxp.com>
The current implementation of spl_board_init() is not correct,
the MX8MM BootROM v1 does not support SDP load when re-entered
from U-Boot SPL, it is up to U-Boot to perform the next stage
load using its own internal CI gadget driver and SDP protocol
implementation. Drop the spl_board_init() to let SPL continue
with normal load in case the SDP support is enabled.
Signed-off-by: Marek Vasut <marex@denx.de>
Reviewed-by: Peng Fan <peng.fan@nxp.com>
Instead of duplicating code implemented by i.MX8M version of arch_misc_init()
in every board, enable CONFIG_ARCH_MISC_INIT and call arch_misc_init() from
spl_board_init(). This removes the duplication. No functional change.
Signed-off-by: Marek Vasut <marex@denx.de>
Reviewed-by: Peng Fan <peng.fan@nxp.com>
- dts update and sync for rk356x, rk3288, rk3399 from Linux;
- Add rk3399 EAIDK-610 board support;
- Update for puma-rk3399 board;
- some fix and typo fix in different drivers;
The first production revision of the MX8M Mini Menlo board implements
a hardware change which swaps console UART and another UART connector.
Implement the swap, which maps the console UART back to the way Verdin
console is mapped.
Signed-off-by: Marek Vasut <marex@denx.de>
Update the GW74xx PMIC configuration:
- increase VDD_SOC DVS1 to 0.85V per datasheet
- increase VDD_SOC DVS0 to 0.95V before first DRAM access
- increase VDD_ARM DVS0 to 0.95V to support kernel overdrive voltage (OD)
- remove unnecessary changes to VDD_DRAM as we don't use 3GHz DRAM
- remove unnecessary change to LDO2 as it is unused
Signed-off-by: Tim Harvey <tharvey@gateworks.com>
v2: update commit log with more detail
Add RAM auto-sizing, without this change memory size for all SKU is set
to 8GB and the system will crash on SKU with less memory as soon as the
non existent memory addresses are accessed.
Fixes: 2bc2f817ce ("board: toradex: add verdin imx8m plus support")
Signed-off-by: Francesco Dolcini <francesco.dolcini@toradex.com>
Acked-by: Marcel Ziswiler <marcel.ziswiler@toradex.com>
With this call the following attributes get set to the device-tree
and are then accessible from linux in /proc/device-tree/
serial-number: The serial number that is stored in config-block
toradex,board-rev: The version of the module (e.g. V1.1A)
toradex,product-id: The SKU number of the module runnin
Fixes: commit 2bc2f817ce ("board: toradex: add verdin imx8m plus support")
Signed-off-by: Philippe Schenker <philippe.schenker@toradex.com>
Acked-by: Marcel Ziswiler <marcel.ziswiler@toradex.com>
With this call the following attributes get set to the device-tree
and are then accessible from linux in /proc/device-tree/
serial-number: The serial number that is stored in config-block
toradex,board-rev: The version of the module (e.g. V1.1A)
toradex,product-id: The SKU number of the module running
Fixes: commit 14d5aeff77 ("board: toradex: Add Verdin iMX8M Mini support")
Signed-off-by: Philippe Schenker <philippe.schenker@toradex.com>
Acked-by: Marcel Ziswiler <marcel.ziswiler@toradex.com>
Enable the I2C bus and set a env variable for the reset GPIO of the touch
controller. This allows us to probe the panel in a script.
Signed-off-by: Frieder Schrempf <frieder.schrempf@kontron.de>
Reviewed-by: Fabio Estevam <festevam@denx.de>
This adds support for the Kontron Electronics SoM SL i.MX8MM OSM-S
and the matching baseboard BL i.MX8MM OSM-S.
The SoM hardware complies to the Open Standard Module (OSM) 1.0
specification, size S (https://sget.org/standards/osm).
The existing board configuration for the non-OSM SoM is reused and
allows to detect the SoM variant at runtime.
Signed-off-by: Frieder Schrempf <frieder.schrempf@kontron.de>
Reviewed-by: Fabio Estevam <festevam@denx.de>
Refactor the code a bit without any functional changes.
Signed-off-by: Frieder Schrempf <frieder.schrempf@kontron.de>
Reviewed-by: Fabio Estevam <festevam@denx.de>
This adjusts the names of the boards and SoMs to the official naming
used by Kontron marketing. These changes also affect devicetree
names and compatibles. The same changes have been submitted to the
Linux kernel.
Signed-off-by: Frieder Schrempf <frieder.schrempf@kontron.de>
Reviewed-by: Fabio Estevam <festevam@denx.de>
This sets an env variable 'som_type' from the board code. It can
later be used by environment scripts, e. g. to select the proper
devicetree for the board.
Signed-off-by: Frieder Schrempf <frieder.schrempf@kontron.de>
Reviewed-by: Fabio Estevam <festevam@denx.de>
These parameters are needed for stable performance on new hardware
with Nanya LPDDR4 chips.
Signed-off-by: Frieder Schrempf <frieder.schrempf@kontron.de>
Reviewed-by: Fabio Estevam <festevam@denx.de>
The new stable configuration is missing the 100mt setpoint, remove
it before updating the config to make sure the changes are separated
cleanly.
Signed-off-by: Frieder Schrempf <frieder.schrempf@kontron.de>
Reviewed-by: Fabio Estevam <festevam@denx.de>
Fix the spaces and alignment for easier tracking of changes and comparing
with configs generated by the tools.
Signed-off-by: Frieder Schrempf <frieder.schrempf@kontron.de>
Reviewed-by: Fabio Estevam <festevam@denx.de>
Move the environment from the board header to a separate text file
and also drop those variables that are already set in env_default.h
from the Kconfig options.
Signed-off-by: Frieder Schrempf <frieder.schrempf@kontron.de>
Reviewed-by: Fabio Estevam <festevam@denx.de>
In case we boot from SD card or eMMC, we also want to load
the environment from the according boot device.
Signed-off-by: Frieder Schrempf <frieder.schrempf@kontron.de>
Reviewed-by: Fabio Estevam <festevam@denx.de>
Nowadays detecting the SPI NOR as boot device from the ROMAPI is
fixed and works even if the SPI NOR is used as fallback boot device.
Therefore we don't need this workaround anymore.
Signed-off-by: Frieder Schrempf <frieder.schrempf@kontron.de>
Reviewed-by: Fabio Estevam <festevam@denx.de>
The display isn't and won't be used in U-Boot. Also the display setup
is not yet supported in mainline Linux, so even for cases where the
U-Boot devicetree is passed to the kernel there is currently no use
for this configuration.
Selecting the proper configuration in the kernel FIT image automatically
depending on the detected hardware can be handled by a script in the
environment.
Signed-off-by: Frieder Schrempf <frieder.schrempf@kontron.de>
Reviewed-by: Fabio Estevam <festevam@denx.de>
Move the environment from the board header to a separate text file
and also drop those variables that are already set in env_default.h
from the Kconfig options or are not needed anymore.
Signed-off-by: Frieder Schrempf <frieder.schrempf@kontron.de>
Instead of checking both, SPI NOR and MMC for loading U-Boot proper
and the environment, implement a way to detect the actual boot
device even if the BootROM doesn't report it and we can't rely
solely on the fuse settings, as by default we use MMC as primary
boot device and boot from SPI NOR via the secondary fallback device
(EEPROM Recovery Mode).
Signed-off-by: Frieder Schrempf <frieder.schrempf@kontron.de>
Beside some rather unexciting sync of the DTs from the kernel tree, and
some Kconfig cleanup, there are some improvements for the ARMv5 Allwinner
family, to support boards with the F1C200s (64MB DRAM) better. We will
get actual board support as soon as the DTs have passed the Linux review
process.
There is also support for the X96 Mate TV Box, featuring the H616 SoC and
a full 4GB of DRAM.
Also we found the secret to enable SPI booting on the H616 (pin PC5 must
be pulled to GND), so the SPI boot support patch is now good to go.
Passed the gitlab CI, plus briefly tested on Pine64-LTS, LicheePi Nano,
X96 Mate and OrangePi Zero.
Check firmware_fdt_addr header to see if it
is a valid fdt blob.
Signed-off-by: Rick Chen <rick@andestech.com>
Reviewed-by: Leo Yu-Chi Liang <ycliang@andestech.com>
Since OpenSBI commit bf3ef53bb7f5 ("firmware: Enable FW_PIC by default"),
OpenSBI runs directly at the load address without any code movement.
This causes the SPL version of QEMU 'virt' U-Boot does not boot Linux
kernel anymore. In that case, OpenSBI is loaded and runs at 0x81000000,
and it creates a 512KiB PMP window from that address. When booting
the Linux kernel, moving kernel to its linking address 0x80200000
overlaps the PMP window, and a PMP access failure is raised.
Update SPL_OPENSBI_LOAD_ADDR to load OpenSBI to a safe address.
Reported-by: Yangjie Zhang <pyjmstr@gmail.com>
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Tested-by: Yangjie Zhang <pyjmstr@gmail.com>
Reviewed-by: Rick Chen <rick@andestech.com>
The X96 Mate TV box is a TV box with the Allwinner H616 SoC. It is
available with up to 4GB of DRAM and 64GB eMMC.
The DRAM chips require a different configuration when compared to the
OrangePi Zero2, we must not use read/write training and write leveling.
Add a defconfig for the box, so that we can easily build U-Boot for it.
We synced the .dts file already from the kernel tree.
Signed-off-by: Andre Przywara <andre.przywara@arm.com>
Reviewed-by: Jernej Skrabec <jernej.skrabec@gmail.com>
Now that a single binary containing TPL/SPL correctly formatted for SPI
flashes and U-Boot proper, can be generated by binman, let's do it.
Also update the documentation to tell the user to use this newly
generated file instead of manually generating and flashing the binaries.
Cc: Quentin Schulz <foss+uboot@0leil.net>
Signed-off-by: Quentin Schulz <quentin.schulz@theobroma-systems.com>
Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
The offset of the SPL payload on Puma is different than for other
Rockchip devices in that it is stored at offset 256K instead of much
further away in the MMC.
Flashing one binary instead of two at different offsets is much more
user friendly so let's migrate to it by modifying the offset in the Puma
specific Device Tree.
Cc: Quentin Schulz <foss+uboot@0leil.net>
Signed-off-by: Quentin Schulz <quentin.schulz@theobroma-systems.com>
Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
Depending on the toolchain used to compile the SPL for Puma RK3399-Q7
module, the board does not boot because the resulting binary is too big
to fit in SRAM.
Let's add a TPL so that there's no need to fiddle with or hack the
defconfig to have a working bootloader.
This follows what's been done for the majority of other RK3399-based
boards.
See the original commit for the first migrations:
bdc0008011 "rockchip: rk3399: update defconfig for TPL"
Unfortunately, the offset in SPI-NOR for U-Boot proper needs to be
modified, since the move from SPL to TPL+SPL for idbloader.img (and the
"only the first 2KB per 4KB blocks are written" "hack" for rkspi format)
increased the size above 256KB. Let's move it to 512KB to, hopefully, be
safe.
Cc: Quentin Schulz <foss+uboot@0leil.net>
Signed-off-by: Quentin Schulz <quentin.schulz@theobroma-systems.com>
Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
Chances are when one boots U-Boot proper from a given storage medium,
they want the same medium to be used to load and store the environment.
This basically allows to have completely separate U-Boot (TPL/SPL/U-Boot
proper/environment) per storage medium which is convenient when working
with recovery from SD-Card as one would just need to insert a properly
configured SD-Card into the device to have access to their whole debug
setup.
No fallback mechanism is provided as to not dirty other storage medium
environment by mistake. However, since arch_env_get_location() is called
by env_init() which is part of the pre-relocation process, a valid,
non-ENVL_UNKNOWN, value shall be returned otherwise the relocation fails
with the following message:
initcall sequence 00000000002866c0 failed at call 0000000000256b34 (err=-19)
This valid, non-ENVL_UNKNOWN, value is ENVL_NOWHERE which requires to
always select CONFIG_ENV_IS_NOWHERE otherwise this work-around does not
work.
Cc: Quentin Schulz <foss+uboot@0leil.net>
Signed-off-by: Quentin Schulz <quentin.schulz@theobroma-systems.com>
Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
Automatically detect which MMC device (SD-Card or eMMC) was used to load
U-Boot proper and load the environment from that MMC device instead of
a hardcoded one.
Cc: Quentin Schulz <foss+uboot@0leil.net>
Signed-off-by: Quentin Schulz <quentin.schulz@theobroma-systems.com>
Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
CONFIG_ENV_OFFSET is set in the defconfig to a different value already
so this isn't used. Let's remove it as to not confuse users.
Cc: Quentin Schulz <foss+uboot@0leil.net>
Signed-off-by: Quentin Schulz <quentin.schulz@theobroma-systems.com>
Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
distroboot should try first on the same MMC medium as the one the SPL
loaded U-Boot proper from. This was the case when the introducing commit
was merged because the default order was eMMC first and then SD card.
The check was therefore made only on whether we booted from SD card,
because otherwise the order was the expected one.
However, in commit b212ad24a6 ("rockchip: Fix MMC boot order"), the
order was swapped. Meaning our simple check is now useless.
Let's fix that by accounting for all scenarii: default boot_targets has
mmc0 first but booting from SD Card, mmc1 first but booting from eMMC.
Fixes: b212ad24a6 ("rockchip: Fix MMC boot order")
Cc: Quentin Schulz <foss+uboot@0leil.net>
Signed-off-by: Quentin Schulz <quentin.schulz@theobroma-systems.com>
Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
Specification
- Rockchip RK3399
- LPDDR3 4GB
- TF sd scard slot
- eMMC
- AP6255 for WiFi + BT
- Gigabit ethernet
- HDMI out
- 40 pin header
- USB 2.0 x 2
- USB 3.0 x 1
- USB 3.0 Type-C x 1 work in otg mode
- 12V DC Power supply
The dts file is sync from linux-next[0].
[0]:https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/tree/arch/arm64/boot/dts/rockchip/rk3399-eaidk-610.dts
Signed-off-by: Andy Yan <andyshrk@163.com>
Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
CONFIG_SERIAL_TAG is not selectable for ARM64 machines. While
get_board_serial is weakly defined if ENV_VARS_UBOOT_RUNTIME_CONFIG is
defined, it is only called when CONFIG_SUPPORT_PASSING_ATAGS is defined,
which also is not selectable for ARM64 machines. Therefore this is dead
code so let's remove it.
Cc: Quentin Schulz <foss+uboot@0leil.net>
Signed-off-by: Quentin Schulz <quentin.schulz@theobroma-systems.com>
Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
The phycore_rk3288 board has a SPL size problem,
so remove phycore_init() function to stay within the limits.
Signed-off-by: Johan Jonker <jbx6244@gmail.com>
Reviewed-by: Wadim Egorov <w.egorov@phytec.de>
Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
For some unknown reason GNU assembler version 2.31.1 (arm-linux-gnueabi-as
from Debian Buster) cannot compile following code from located in file
board/nokia/rx51/lowlevel_init.S:
kernoffs:
.word KERNEL_OFFSET - (. - CONFIG_SYS_TEXT_BASE)
when CONFIG_SYS_TEXT_BASE is set to 0x80008000. It throws strange compile
error which is even without line number:
AS board/nokia/rx51/lowlevel_init.o
{standard input}: Assembler messages:
{standard input}: Error: attempt to get value of unresolved symbol `L0'
make[2]: *** [scripts/Makefile.build:293: board/nokia/rx51/lowlevel_init.o] Error 1
I have no idea about this error and my experiments showed that ARM GNU
assembler is happy with negation of that number. So changing code to:
kernoffs:
.word . - CONFIG_SYS_TEXT_BASE - KERNEL_OFFSET
and then replacing mathematical addition by substraction of "kernoffs"
value (so calculation of address does not change) compiles assembler file
without any error now.
There should be not any functional change.
Signed-off-by: Pali Rohár <pali@kernel.org>
Reviewed-by: Tom Rini <trini@konsulko.com>
Support VBE OS requests / fixups
Minor error-handling tweaks to bootm command
-----BEGIN PGP SIGNATURE-----
iQFFBAABCgAvFiEEslwAIq+Gp8wWVbYnfxc6PpAIreYFAmNOjr4RHHNqZ0BjaHJv
bWl1bS5vcmcACgkQfxc6PpAIreakFQf/bLTFMI8noOMa9d6Yo1RTSOa9wNiomgzC
JGY7g8i7b6cARwQ+QuSncnO/EOpwjzBLWkohUK3UAktJu2LURBPJFR4qeP01F7iz
4Mn3ikYlr3vRxAPeckN7l1aqSWrY/tEXbUdXLxSn+COzjxCQG5aBU1jd/tVBqIAk
XgZ0NGVHOQe8XOPNxDP9+EYHw4kmqMSdWZmpkb1w+Jh5AIYMMDgn1ktiNmnWXllx
LM89JxR8FMUJzFP9XBRtYemje55tAUPlENthRip9Zj9touEBbBKjV5eY8YsjpMMU
Vt5rK33vKWE4mdNBjRmOoe9xkUv/pRclpaGUFBNswf2LGw7/lsHd2A==
=3P/S
-----END PGP SIGNATURE-----
Merge tag 'dm-pull-18oct22' of https://source.denx.de/u-boot/custodians/u-boot-dm
Update uclass iterators to work better when devices fail to probe
Support VBE OS requests / fixups
Minor error-handling tweaks to bootm command
Fix the compilation issue when CONFIG_DEBUG_UART is activated
drivers/serial/serial_stm32.o: in function `debug_uart_init':
drivers/serial/serial_stm32.c:291: undefined reference to \
`board_debug_uart_init'
The board_debug_uart_init is needed for SPL boot, called in
cpu.c::mach_cpu_init(); it is defined in board/st/stm32mp1/spl.c.
But with the removal #ifdefs patch, the function debug_uart_init() is
always compiled even if not present in the final U-Boot image.
This patch adds a file to provided this function when DEBUG_UART and SPL
are activated.
Fixes: c8b2eef52b ("stm32mp15: tidy up #ifdefs in cpu.c")
Signed-off-by: Patrick Delaunay <patrick.delaunay@foss.st.com>
Reviewed-by: Patrice Chotard <patrice.chotard@foss.st.com>
Add DT for DHCOR Testbench board, which is a testbench for testing of
DHCOR SoM during manufacturing. This is effectively a trimmed down
version of AV96 board with CSI-2 bridge, HDMI bridge, WiFi, Audio and
LEDs removed and used as GPIOs instead. Furthermore, the PMIC Buck3
is always configured from PMIC NVM to cater for both 1V8 and 3V3 SoM
variant.
Signed-off-by: Marek Vasut <marex@denx.de>
Cc: Patrice Chotard <patrice.chotard@foss.st.com>
Cc: Patrick Delaunay <patrick.delaunay@foss.st.com>
Reviewed-by: Patrice Chotard <patrice.chotard@foss.st.com>
In case the regulator-always-on is present in regulator DT node,
the regulator is always reconfigured to the voltage set in DT on
probe, even if regulator_set_value() has been called before. Drop
the property from AV96 U-Boot DT and enable the regulator manually
in code, as the board already reconfigures the Buck3 regulator in
code per PMIC NVM content instead.
Fixes: 0adf10a87b ("ARM: dts: stm32: Configure Buck3 voltage per PMIC NVM on Avenger96")
Signed-off-by: Marek Vasut <marex@denx.de>
Reviewed-by: Patrice Chotard <patrice.chotard@foss.st.com>
In a later patch sysinfo_get will be changed to return the device in cae
of an error. Set sysinfo to NULL on error to preserve previous behavior.
Signed-off-by: Michal Suchanek <msuchanek@suse.de>
Reviewed-by: Simon Glass <sjg@chromium.org>
There are a couple users of uclass_next_device return value that get the
first device by other means and use uclass_next_device assuming the
following device in the uclass is related to the first one.
Use uclass_next_device_err because the return value from
uclass_next_device will be removed in a later patch.
Signed-off-by: Michal Suchanek <msuchanek@suse.de>
Reviewed-by: Simon Glass <sjg@chromium.org>
There is a number of users that use uclass_first_device to access the
first and (assumed) only device in uclass.
Some check the return value of uclass_first_device and also that a
device was returned which is exactly what uclass_first_device_err does.
Some are not checking that a device was returned and can potentially
crash if no device exists in the uclass. Finally there is one that
returns NULL on error either way.
Convert all of these to use uclass_first_device_err instead, the return
value will be removed from uclass_first_device in a later patch.
Signed-off-by: Michal Suchanek <msuchanek@suse.de>
Reviewed-by: Simon Glass <sjg@chromium.org>
The LS1043ARDB rev v7.0 board replace nand device MT29F4G08ABBDAH4-AITX:D
with MT29F4G08ABBFAH4-AIT:F. Reflecting this change in board_fix_fdt().
CPLD V3.0 is needed for nandboot as the nand device changed.
A new macro CPLD_CFG_RCW_SRC_NAND_4K(4Kpage) is added to distinguish from
CPLD_CFG_RCW_SRC_NAND(2Kpage) to support nandboot on rev v7.0 board.
Signed-off-by: Wei Lu <w.lu@nxp.com>
Signed-off-by: Peng Fan <peng.fan@nxp.com>
Space key is indicated by two different bits. Some HW models indicate press
of space key only by the first bit. Qemu indicates it by both bits at the
same time, which is currently interpreted by u-boot as double key press.
Fix this issue by setting first bit when only second is set (to support HW
models which indicate press only by second bit) and always clearing second
bit before processing to not report double space key press.
Signed-off-by: Pali Rohár <pali@kernel.org>
