When OP-TEE is used, the SMC for BSEC management are not available and
the STM32MP BSEC pseudo TA must be used (it is mandatory for STM32MP13
and it is a new feature for STM32MP15x).
The BSEC driver try to open a session to this PTA BSEC at probe
and use it for OTP read or write access to fuse or to shadow.
This patch also adapts the commands stm32key and stboard to handle
the BSEC_LOCK_PERM lock value instead of 1.
Signed-off-by: Patrick Delaunay <patrick.delaunay@foss.st.com>
Reviewed-by: Patrice Chotard <patrice.chotard@foss.st.com>
Before this was named just evm, which doesn't match the naming
of the other TI board file directory and makes it look like a
common directory for evms. Name this omap3evm.
Signed-off-by: Andrew Davis <afd@ti.com>
Reviewed-by: Derald Woods <woods.technical@gmail.com>
-----BEGIN PGP SIGNATURE-----
iQFQBAABCgA6FiEEqxhEmNJ6d7ZdeFLIHrMeAg6sL8gFAmO2mnEcHGV1Z2VuLmhy
aXN0ZXZAbWljcm9jaGlwLmNvbQAKCRAesx4CDqwvyBAOB/4y7e9y0jdKSWDwMdZj
enXK/U/GREFyuiSdadil0aJl9WfayjwZkh7uHSTj4pi9ApNivfoqsL7WZYpJxhRD
WlpNhs3TZ70i8CgKUosdzcpquAQZUZhg6iV5DCObrK6yNJRGOXLIwMOd+vw/Xz6/
YTGqzivEDMBuH/9HLuC0m+26PEpff8nenNEjC2k8ssG26ojLz7oCQh2HoHcSgNRc
HkEYlFJ/Le8kM8Ak2F3ebmsfgMTnFrRVwV1BsZa5vO0BrMYgJCORsl7Cnfcw6/2N
LEHG7kwlSorJeETn/gkLiZ+NyqzU+oFH0jGRZ5Ciqg1qcCO3k9yBMgWQzd7nTL6C
5oZA
=Ocdd
-----END PGP SIGNATURE-----
Merge tag 'u-boot-at91-2023.04-a' of https://source.denx.de/u-boot/custodians/u-boot-at91 into next
First set of u-boot-at91 features for the 2023.04 cycle:
This feature set includes the new DM-based NAND flash driver (old non-DM
driver is still kept for backwards compatibility), and the move to DM
NAND flash driver for sam9x60ek board. Feature set also includes
devicetree alignment for sama7g5 with Linux, devicetree alignment on USB
with Linux for all boards (sama5, sam9x60), chip id for sama7g5, minor
configs and tweaks.
Set blue led on at boot time in order to highlight that u-boot is loaded.
This is done for all sam9x60 based boards which contain an RGB led.
Signed-off-by: Mihai Sain <mihai.sain@microchip.com>
EEPROM detection logic in ti_i2c_eeprom_get() involves figuring out
whether addressing is 1-byte or 2-byte. There are currently different
behaviours seen across boards as documented in commit bf6376642f
("board: ti: common: board_detect: Fix EEPROM read quirk"). Adding to
the list, we see that there are 2-byte EEPROMs that read properly
with 1-byte addressing with no offset.
For ti_i2c_eeprom_am6_get where eeprom parse operation is dynamic, the
earlier commit d2ab2a2baf ("board: ti: common: board_detect: Fix
EEPROM read quirk for AM6 style data") tried to resolve this by running
ti_i2c_eeprom_get() twice. However this commit along with its former
commit fails on J7 platforms where EEPROM successfully return back the
header on 1-byte addressing and continues to do so until an offset is
introduced. So the second read incorrectly determines the EEPROM as
1-byte addressing.
A more generic solution is introduced here to solve
this issue: 1-byte read without offset and 1-byte read with offset. If
both passes, it follows 1-byte addressing else we proceed with 2-byte
addressing check.
Tested on J721E, J7200, DRA7xx, AM64x
Signed-off-by: Neha Malcom Francis <n-francis@ti.com>
Fixes: d2ab2a2baf (board: ti: common: board_detect: Fix EEPROM read quirk for AM6 style data)
Fixes: bf6376642f (board: ti: common: board_detect: Fix EEPROM read quirk)
Tested-By: Matwey V. Kornilov <matwey.kornilov@gmail.com>
At this point in the conversion there should be no need to have logic to
disable some symbol during the SPL build as all symbols should have an
SPL counterpart.
The main real changes done here are that we now must make proper use of
CONFIG_IS_ENABLED(DM_SERIAL) rather than many of the odd tricks we
developed prior to CONFIG_IS_ENABLED() being available.
Signed-off-by: Tom Rini <trini@konsulko.com>
Rename the CONFIG_POWER_BD71837_I2C_* symbols to not have the CONFIG
prefix and be local to the file they are used in.
Signed-off-by: Tom Rini <trini@konsulko.com>
Perform simple renames of:
CONFIG_VSC7385_IMAGE to CFG_VSC7385_IMAGE
CONFIG_VSC7385_IMAGE_SIZE to CFG_VSC7385_IMAGE_SIZE
Signed-off-by: Tom Rini <trini@konsulko.com>
Perform simple renames of:
CONFIG_DFU_ALT to CFG_DFU_ALT
CONFIG_DFU_ALT_BOOT_EMMC to CFG_DFU_ALT_BOOT_EMMC
CONFIG_DFU_ALT_BOOT_SD to CFG_DFU_ALT_BOOT_SD
CONFIG_DFU_ALT_SYSTEM to CFG_DFU_ALT_SYSTEM
CONFIG_DFU_ENV_SETTINGS to CFG_DFU_ENV_SETTINGS
Signed-off-by: Tom Rini <trini@konsulko.com>
The way that the timer support is currently done for exynos/nexell
platforms relies on the legacy PWM infrastructure, and that needs to be
updated. However, we really cannot safely undef CONFIG_DM_PWM to build
the timer.c file without warnings. For now, rename the relevant legacy
functions to be prefixed with s5p_ and add prototypes to the arch pwm.h
files.
Cc: Minkyu Kang <mk7.kang@samsung.com>
Cc: Jaehoon Chung <jh80.chung@samsung.com>
Cc: Dzmitry Sankouski <dsankouski@gmail.com>
Cc: Stefan Bosch <stefan_b@posteo.net>
Signed-off-by: Tom Rini <trini@konsulko.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
At this point only the TARGET_T1042D4RDB variant of this is supported in
tree, so remove the remaining parts of the other platforms.
Signed-off-by: Tom Rini <trini@konsulko.com>
This is always defined to 16K, so we move this over to
include/fsl_validate.h to start with. Next, we rename this from CONFIG_
to FSL_. Coalesce the various comments around this definition to be in
fsl_validate.h as well to explain the usage.
Signed-off-by: Tom Rini <trini@konsulko.com>
Enable this in the board Kconfig file, but then check for it via
CONFIG_IS_ENABLED so that it will only be true in the non-SPL case, as
is done today. As part of this we move some defines local to where
they are used as it's board specific.
Cc: Samuel Egli <samuel.egli@siemens.com>
Signed-off-by: Tom Rini <trini@konsulko.com>
This converts the following to Kconfig:
CONFIG_MONITOR_IS_IN_RAM
As part of this, reword some of the documentation slightly to reflect
that this is in Kconfig and not a define now.
Signed-off-by: Tom Rini <trini@konsulko.com>
Following how g_dnl_bind_fixup is used on other platforms, rename the
unchanging defines used here to be prefixed with EXYNOS rather than
Samsung, and define them here.
Cc: Minkyu Kang <mk7.kang@samsung.com>
Cc: Jaehoon Chung <jh80.chung@samsung.com>
Signed-off-by: Tom Rini <trini@konsulko.com>
This converts the following to Kconfig:
CONFIG_FLASH_SPANSION_S29WS_N
CONFIG_FLASH_VERIFY
CONFIG_FSL_FM_10GEC_REGULAR_NOTATION
CONFIG_FSL_ISBC_KEY_EXT
CONFIG_FSL_TRUST_ARCH_v1
CONFIG_FSL_SDHC_V2_3
CONFIG_MAX_DSP_CPUS
CONFIG_MIU_2BIT_INTERLEAVED
CONFIG_SERIAL_BOOT
CONFIG_SPI_BOOTING
CONFIG_X86EMU_RAW_IO
Signed-off-by: Tom Rini <trini@konsulko.com>
This converts the following to Kconfig:
CONFIG_DM9000_BYTE_SWAPPED
CONFIG_DM9000_NO_SROM
CONFIG_DM9000_USE_16BIT
CONFIG_DM9000_DEBUG
CONFIG_MXC_GPT_HCLK
CONFIG_NAND_6BYTES_OOB_FREE_10BYTES_ECC
Signed-off-by: Tom Rini <trini@konsulko.com>
Add information that will be needed for enabling the UEFI capsule
update feature on the RockPi4 boards. With the feature enabled, it
would be possible to update the idbloader and u-boot.itb images on the
RockPi4B and RockPi4C variants.
Signed-off-by: Sughosh Ganu <sughosh.ganu@linaro.org>
Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
The legacy Allwinner code is cluttered with #ifdef's, some of them even
nested, which makes the code hard to read and error prone.
Eventually we will get rid of most of them, but for now let's at least
annotate the #endif lines with the corresponding symbol the bracket
started with.
Reviewed-by: Samuel Holland <samuel@sholland.org>
Tested-by: Samuel Holland <samuel@sholland.org>
Signed-off-by: Andre Przywara <andre.przywara@arm.com>
Since all callers of mmc_pinmux_setup() are located after the definition
of that function, there is no need for a forward declaration (anymore?).
Remove the prototype along with its #ifdef guards.
Reviewed-by: Samuel Holland <samuel@sholland.org>
Tested-by: Samuel Holland <samuel@sholland.org>
Signed-off-by: Andre Przywara <andre.przywara@arm.com>
There is a CONFIG_MMC_SUNXI_SLOT definition in our sunxi_common.h config
header, which was used to note the first MMC controller to initialise.
The definition in that header was always set to 0, with no easy way of
overriding this, and certainly none of the existing boards made any use
of that (non-)feature.
Remove that definition and replace it with a constant 0 in the only
user, in board.c. It turns out that this is safe, as this is only used
in the SPL, and the BROM also unconditionally initialises MMC0.
This also removes the last legacy config symbol with SUN*I in it from
the whitelist.
Reviewed-by: Samuel Holland <samuel@sholland.org>
Tested-by: Samuel Holland <samuel@sholland.org>
Signed-off-by: Andre Przywara <andre.przywara@arm.com>
Use like the other boards a text file for the environment.
As this is the last user of keymile-common.h we can now remove this
file completely.
Signed-off-by: Holger Brunck <holger.brunck@hitachienergy.com>
Use already present common.env file and add a powerpc specific env
so that we can move all the environment defines to text files.
Signed-off-by: Holger Brunck <holger.brunck@hitachienergy.com>
The functions board_fit_image_post_process() and board_tee_image_process()
are not actually board specific (despite their names). Any board using the
OMAP2 family can use these functions. Move them to boot-common.c.
Signed-off-by: Andrew Davis <afd@ti.com>
Reviewed-by: Tom Rini <trini@konsulko.com>
Default env variables on Espressobin boards are broken since commit c4df0f6f31
("arm: mvebu: Espressobin: Set default value for $fdtfile env variable") as well
as the 'env default -a' command.
The algorithm to find free space in the default_environment[] array returns
after the first env variable instead of the correct position of the last
variable, where there is allocated free space.
This causes that U-Boot board_late_init() function to overwrite a portion of the
default environment with $ethXaddr and $fdtfile variables immediately after the
first env variable and so it is overwriting other variables.
This patch also adds an additional null byte to terminate the environment array.
But U-Boot board_late_init() function do not fill this nul byte explicitly. And
because of that, U-Boot is later trying to interpret remaining buffer as a
continuation of variable list. Normally buffer should be empty but due to the
above issue, it contains garbage from remaining env variables.
For example 'env default -a' command results in damaging variable names. It was
observed that scritaddr variable name was changed to criptaddr (without leading
's').
This bug was reported and discussed on the Armbian forum:
https://forum.armbian.com/topic/19564-making-espressobin-v7-work-in-2022/?do=findComment&comment=138136
Fix these issues in two steps:
1) Change code which finds free space for dynamic env variables in
default_environment[] array by jumping to the end of the variable list instead
of jumping after the first defined variable. [By Derek]
2) Add code which appends terminating nul byte as indication of the end of the
env list, after the last nul term env string. [By Pali]
Fixes: c4df0f6f31 ("arm: mvebu: Espressobin: Set default value for $fdtfile env variable")
Signed-off-by: Derek LaHousse <derek@seaofdirac.org>
Signed-off-by: Pali Rohár <pali@kernel.org>
Signed-off-by: Stefan Roese <sr@denx.de>
ENTRY/ENDPROC macros from linux/linkage.h will make code more readable and
also will properly mark assembly symbol in ELF binary as function symbol.
Signed-off-by: Pali Rohár <pali@kernel.org>
Move this out of board file as this is done by the DM based NAND flash
driver. The EBI chip select configuration, iomux and timings are
handled by the driver
Signed-off-by: Balamanikandan Gunasundar <balamanikandan.gunasundar@microchip.com>
As DM_ETH is required for all network drivers, it's now safe to remove
the non-DM_ETH support code. Doing this removes some board support code
which was also unused. Finally, this removes some CONFIG symbols that
otherwise needed to be migrated to Kconfig, but were unused in code now.
Signed-off-by: Tom Rini <trini@konsulko.com>
We only need to enable DM_ETH if we have a networking driver. All
networking drivers depend on DM_ETH being enabled, and their selection
ensures DM_ETH will be enabled.
Signed-off-by: Tom Rini <trini@konsulko.com>
Move a number of legacy USB UDC options to Kconfig, over from the config
header.
Cc: Pali Rohár <pali@kernel.org>
Signed-off-by: Tom Rini <trini@konsulko.com>
This option controls using board/samsung/common/misc.c, so add a Kconfig
file there as well and select it from the boards which use this
functionality.
Signed-off-by: Tom Rini <trini@konsulko.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Minkyu Kang <mk7.kang@samsung.com>
This converts the following to Kconfig:
CONFIG_POWER_FSL
CONFIG_POWER_FSL_MC13892
CONFIG_POWER_HI6553
CONFIG_POWER_LTC3676
CONFIG_POWER_PFUZE100
CONFIG_POWER_PFUZE3000
CONFIG_POWER_SPI
CONFIG_POWER_TPS65090_EC
CONFIG_POWER_TPS65218
CONFIG_POWER_TPS65910
Signed-off-by: Tom Rini <trini@konsulko.com>
The rest of the unmigrated CONFIG symbols in the CONFIG_SYS namespace do
not easily transition to Kconfig. In many cases they likely should come
from the device tree instead. Move these out of CONFIG namespace and in
to CFG namespace.
Signed-off-by: Tom Rini <trini@konsulko.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
The rest of the unmigrated CONFIG symbols in the SRIO namespace do not
easily transition to Kconfig. In many cases they likely should come from
the device tree instead. Move these out of CONFIG namespace and in to
CFG namespace.
Signed-off-by: Tom Rini <trini@konsulko.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
The rest of the unmigrated CONFIG symbols in the CONFIG_SYS_SDRAM
namespace do not easily transition to Kconfig. In many cases they likely
should come from the device tree instead. Move these out of CONFIG
namespace and in to CFG namespace.
Signed-off-by: Tom Rini <trini@konsulko.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
The rest of the unmigrated CONFIG symbols in the CONFIG_SYS_PCI and
CONFIG_SYS_PCIE namespace do not easily transition to Kconfig. In many
cases they likely should come from the device tree instead. Move these
out of CONFIG namespace and in to CFG namespace.
Signed-off-by: Tom Rini <trini@konsulko.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
The rest of the unmigrated CONFIG symbols in the CONFIG_SYS_NUM
namespace do not easily transition to Kconfig. In many cases they likely
should come from the device tree instead. Move these out of CONFIG
namespace and in to CFG namespace.
Signed-off-by: Tom Rini <trini@konsulko.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
The rest of the unmigrated CONFIG symbols in the CONFIG_SYS_NS16550
namespace do not easily transition to Kconfig. In many cases they likely
should come from the device tree instead. Move these out of CONFIG
namespace and in to CFG namespace.
Signed-off-by: Tom Rini <trini@konsulko.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
The rest of the unmigrated CONFIG symbols in the CONFIG_SYS_NOR
namespace do not easily transition to Kconfig. In many cases they likely
should come from the device tree instead. Move these out of CONFIG
namespace and in to CFG namespace.
Signed-off-by: Tom Rini <trini@konsulko.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
The rest of the unmigrated CONFIG symbols in the CONFIG_SYS_NAND
namespace do not easily transition to Kconfig. In many cases they likely
should come from the device tree instead. Move these out of CONFIG
namespace and in to CFG namespace.
Signed-off-by: Tom Rini <trini@konsulko.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
SPL_FS_LOAD_PAYLOAD_NAME depends on SPL to be enabled.
If SPL is not enabled code still expects SPL_FS_LOAD_PAYLOAD_NAME to be
present. That's why setup proper dependency in the code.
And by doing so also change the logic around dfu_alt_info string
composition to be simpler.
Signed-off-by: Michal Simek <michal.simek@amd.com>
Link: https://lore.kernel.org/r/3989c390a4acae13a1b05c040e14fb3d68bced02.1669986373.git.michal.simek@amd.com
The commit ed35de6170 ("Convert CONFIG_ZYNQMP_PSU_INIT_ENABLED to
Kconfig") converted CONFIG_ZYNQMP_PSU_INIT_ENABLED symbol and enabled it by
default which is not correct configuration.
Intention of this config was to have it enabled by default for SPL and
provide an option to users to also do low level initialization directly
from U-Boot.
That's why it is necessary to define second symbol with SPL marking in it
and properly use symbols depends on usage in Makefile.
Also disable ZYNQMP_PSU_INIT_ENABLED from boards which enables it by
default. CONFIG_SPL_ZYNQMP_PSU_INIT_ENABLED is enabled by default when SPL
is enabled.
Reported-by: Venkatesh Yadav Abbarapu <venkatesh.abbarapu@amd.com>
Reviewed-by: Luca Ceresoli <luca@lucaceresoli.net>
Signed-off-by: Michal Simek <michal.simek@amd.com>
Link: https://lore.kernel.org/r/d5fcbd66b05bf0d7ef594e66464ee23b48c5e4cc.1669969083.git.michal.simek@amd.com
My Bootlin address is the preferred one now.
Signed-off-by: Luca Ceresoli <luca.ceresoli@bootlin.com>
Signed-off-by: Luca Ceresoli <luca@lucaceresoli.net>
Link: https://lore.kernel.org/r/20221203214939.56608-1-luca@lucaceresoli.net
Signed-off-by: Michal Simek <michal.simek@amd.com>
Peter accpeted to step up as a co-maintainer for the RPis.
Reflect that in the corresponding MAINTAINERS files.
Signed-off-by: Matthias Brugger <mbrugger@suse.com>
Reviewed-by: Peter Robinson <pbrobinson@gmail.com>
The sandbox config file is to be removed. Move the GUID declarations
needed for capsule update functionality to the board file where they
are used.
Signed-off-by: Sughosh Ganu <sughosh.ganu@linaro.org>
Reviewed-by: Simon Glass <sjg@chromium.org>
vck190 system controller low level setup is the same for revB that's why
also create symlink to revA.
Signed-off-by: Michal Simek <michal.simek@amd.com>
Removing the zynq_board_read_rom_ethaddr() function as
xlnx,eeprom is not used anymore. As all board dts to use
nvmem alias instead of xlnx,eeprom.
Signed-off-by: Venkatesh Yadav Abbarapu <venkatesh.abbarapu@amd.com>
Link: https://lore.kernel.org/r/20221017094818.17996-1-venkatesh.abbarapu@amd.com
Signed-off-by: Michal Simek <michal.simek@amd.com>
Due to usage of PREBOOT in Kconfig, macro CONFIG_PREBOOT is always defined
when CONFIG_USE_PREBOOT is enabled. In case CONFIG_PREBOOT is not
explicitly enabled it is set to empty C string and therefore
'#ifdef CONFIG_PREBOOT' guard does not work. Fix this issue by introducing
a new Kconfig symbol PREBOOT_DEFINED which cause to define new C macro
CONFIG_PREBOOT_DEFINED only when CONFIG_PREBOOT is really defined.
Change usage of '#ifdef CONFIG_PREBOOT' by '#ifdef CONFIG_USE_PREBOOT' for
code which checks if preboot code would be called and by
'#ifdef CONFIG_PREBOOT_DEFINED' for defining preboot code.
Signed-off-by: Pali Rohár <pali@kernel.org>
This converts the following to Kconfig:
CONFIG_SYS_I2C_INIT_BOARD
Signed-off-by: Tom Rini <trini@konsulko.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Switch to use binman to pack images
Signed-off-by: Oliver Graute <oliver.graute@kococonnector.com>
Reviewed-by: Fabio Estevam <festevam@denx.de>
Reviewed-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Peng Fan <peng.fan@nxp.com>
commit 0543a1ed27 ("imx8m: fixup thermal trips") moved updating the
thermal trip points to all IMX8M so we can remove it from our board
specific dt config.
Signed-off-by: Tim Harvey <tharvey@gateworks.com>
Add support for the MSC SM2S-IMX8PLUS SMARC Module. Tested in conjunction
with the MSC SM2-MB-EP1 Mini-ITX Carrier Board.
Signed-off-by: Martyn Welch <martyn.welch@collabora.com>
Signed-off-by: Fabio Estevam <festevam@denx.de>
In order to boot over USB, the device tree needs to enable
a few extra nodes in SPL. Since the USB driver has the
ability to detect host/device, the dr_mode can be removed
from the device tree since it needs to act as a device when
booting and OTG is the default mode. Add USB boot support
to spl_board_boot_device and enable the corresponding config
options.
Signed-off-by: Adam Ford <aford173@gmail.com>
Reviewed-by: Fabio Estevam <festevam@denx.de>
There are a few functions which are not essential for use in
SPL, but they take up enough space to make other preferred
features not fit. Remove the extras.
Signed-off-by: Adam Ford <aford173@gmail.com>
Reviewed-by: Fabio Estevam <festevam@denx.de>
The DDR is configured for LPDDR4 running at 1.6GHz which requires
the voltage on the PMIC to rise a bit before initializing LPDDR4
or it will be running out of spec.
Signed-off-by: Adam Ford <aford173@gmail.com>
Reviewed-by: Fabio Estevam <festevam@denx.de>
Reviewed-by: Peng Fan <peng.fan@nxp.com>
The RD-AC5X-32G16HVG6HLG-A0 development board main components and
features include:
* Main 12V/54V power supply
* 270 Gbps throughput packet processor on the main board
* DDR4:
* SR1: 2GB DDR4 2400MT/S(1GB x 2 pcs ) with ECC(1GB x 1 pcs)
* SR2: 4GB DDR4 2400MT/S(2GB x 2 pcs ) with ECC(2GB x 1 pcs)
* PCB co-layout with 4GB device to support 8GB (Dual CS) requirement
* 16GB eMMC (Samsung KLMAG1JETD-B041006)
* 16MB SPI NOR(GD25Q127C)
* 32 x 1000 Base-T interfaces
* 16 x 2500 Base-T interfaces
* SR1: 88E2540*4
* SR2: 88E2580*1+88E2540*2
* Six (6) x 25G Base-R SFP28 interfaces
* One (1) x RJ-45 console connector, interfacing to the on board UART
* One (1) x USB Type-A connector, interfacing to the USB 2.0 port (0)
* One (1) x USB Type-mini B connector, interfacing to the USB 2.0 port (1)
* One (1) x RJ-45 1G Base-T Management port, interfacing to the host
port (shared with PCIe) Connected to 88E1512 Gigabit Ethernet Phy
* One (1) x Oculink port, interfacing to the PCIe port for external CPU
connection
* POE 802.3AT support on Port 1 ~ Port 32, 802.3BT support on Port 33 ~
Port 48 (Microsemi PD69208T4, PD69208M or TI TPS2388,TPS23881
solution)
* POE total power budget 780W
* LED interfaces per network port/POE
* LED interfaces (common) showing system status
* PTP TC mode Supported (Reserved M.2 connector to support BC mode)
Signed-off-by: Chris Packham <judge.packham@gmail.com>
File name with pattern u-boot-spl* is used on all places except in kwb
image for binary with SPL-only code. Combined binary with both SPL and
proper U-Boot in other places has file name pattern u-boot-with-spl*.
Make it consistent also for kwb image and rename u-boot-spl.kwb to
u-boot-with-spl.kwb as this image contains both SPL and proper U-Boot code.
Also update documentation about file name changes.
Signed-off-by: Pali Rohár <pali@kernel.org>
Reviewed-by: Stefan Roese <sr@denx.de>
This patch updates Microchip MPFS Icicle Kit support. For now,
add Microchip QSPI driver and a small 4MB reservation is
made at the end of 32-bit DDR to provide some memory for
the HSS to use.
Signed-off-by: Padmarao Begari <padmarao.begari@microchip.com>
Reviewed-by: Conor Dooley <conor.dooley@microchip.com>
Reviewed-by: Rick Chen <rick@andestech.com>
Resolve all uses of CONFIG_SYS_MHZ with the currently defined value.
Remove code which depends on CONFIG_SYS_MHZ but where no board configs
actually use that code.
Signed-off-by: Daniel Schwierzeck <daniel.schwierzeck@gmail.com>
Reviewed-by: Stefan Roese <sr@denx.de>
The DT used for Calxeda Highbank and Midway systems exposes a "system
registers" block, modeled as a DT subnode.
This includes several clocks, including the two fixed clocks for the
main oscillator and timer.
So far U-Boot was ignorant of this special construct (a "clocks" node
within the "hb-sregs" node), as it didn't need the PLL clocks in there.
But that also meant we lost the fixed clocks, which form the base for
the UART baudrate generator and also the SP804 timer.
To allow the generic PL011 and SP804 driver to read the clock rate,
add a simple bus driver, which triggers the DT node discovery inside this
special node. As we only care about the fixed clocks (we don't have
drivers for the PLLs anyway), just ignore the address translation (for
now).
The binding is described in bindings/arm/calxeda/hb-sregs.yaml, the DT
snippet in question looks like:
=======================
sregs@fff3c000 {
compatible = "calxeda,hb-sregs";
reg = <0xfff3c000 0x1000>;
clocks {
#address-cells = <1>;
#size-cells = <0>;
osc: oscillator {
#clock-cells = <0>;
compatible = "fixed-clock";
clock-frequency = <33333000>;
};
....
};
};
=======================
Signed-off-by: Andre Przywara <andre.przywara@arm.com>
Add test cases for accessing the FWU Metadata on the sandbox
platform. The sandbox platform also uses the metadata access driver
for GPT partitioned block devices.
The FWU feature will be tested on the sandbox64 variant with a raw
capsule. Remove the FIT capsule testing from sandbox64 defconfig --
the FIT capsule test will be run on the sandbox_flattree variant.
Signed-off-by: Sughosh Ganu <sughosh.ganu@linaro.org>
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Acked-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
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>
Before this patch you could see in the log:
U-Boot SPL 2022.10-rc5 (Sep 29 2022 - 15:29:27 +0200)
PMUFW: v1.1
Loading new PMUFW cfg obj (32 bytes)
PMUFW: No permission to change config object
Loading new PMUFW cfg obj (2032 bytes)
where it is visible that permission is check before sending PMUFW
configuration (big size).
When this patch is applied it is visible that order is correct.
U-Boot SPL 2022.10-rc5 (Sep 29 2022 - 15:47:08 +0200)
Loading new PMUFW cfg obj (2032 bytes)
PMUFW: v1.1
Loading new PMUFW cfg obj (32 bytes)
Signed-off-by: Michal Simek <michal.simek@amd.com>
Link: https://lore.kernel.org/r/a0bf4f46d670023da4f848790eece6fff22090c2.1664962765.git.michal.simek@amd.com
Compiling with GCC-12 leads to an error:
+board/xilinx/common/board.c:479:37: error: the comparison will always
evaluate as 'true' for the address of 'mac_addr' will never be NULL
[-Werror=address]
+ 479 | if (!desc->mac_addr[i])
+ | ^
Remove the redundant check.
Fixes: a03b594738 ("xilinx: board: Add support for additional card detection")
Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
Link: https://lore.kernel.org/r/20221008091317.52838-1-heinrich.schuchardt@canonical.com
Signed-off-by: Michal Simek <michal.simek@amd.com>
In function ‘set_dfu_alt_info’ a comparison of a u8 value against
0 is done. Since it is always false, change the signature of this
function to use an `int` instead, which match the type used in caller:
`multi_boot()`.
Fix the following warning triggered with W=1:
board/xilinx/zynqmp/zynqmp.c:651:23:
warning: comparison is always false due to limited range of data type
[-Wtype-limits]
651 | if (multiboot < 0)
Signed-off-by: Venkatesh Yadav Abbarapu <venkatesh.abbarapu@amd.com>
Link: https://lore.kernel.org/r/20221004055254.26246-1-venkatesh.abbarapu@amd.com
Signed-off-by: Michal Simek <michal.simek@amd.com>
cpu-info.c defines print_cpuinfo(), but neglected to
include its declaration, causing the following sparse and
compile time warnings:
board/xilinx/common/cpu-info.c:10:5:
warning: no previous prototype for 'print_cpuinfo'
[-Wmissing-prototypes]
Include init.h, which includes the missing declaration.
Signed-off-by: Venkatesh Yadav Abbarapu <venkatesh.abbarapu@amd.com>
Link: https://lore.kernel.org/r/20221004055053.26047-1-venkatesh.abbarapu@amd.com
Signed-off-by: Michal Simek <michal.simek@amd.com>
dram_init() can't modify global/static variables, so
move the mem_map setup later when bss is available.
Signed-off-by: Jassi Brar <jaswinder.singh@linaro.org>
These boards are out of maintenance and can be removed.
Signed-off-by: Holger Brunck <holger.brunck@hitachienergy.com>
Reviewed-by: Stefan Roese <sr@denx.de>
This is not needed and we should avoid typedefs. Use the struct instead
and rename it to indicate that it really is a legacy struct.
Signed-off-by: Simon Glass <sjg@chromium.org>
The situation is similar to commit bf6376642f ("board: ti: common:
board_detect: Fix EEPROM read quirk"). This is seen on a variant of
eeproms seen on some BeagleBone-AI64 which now has a mix of both 1 byte
addressing and 2 byte addressing eeproms.
Unlike the am335x (ti_i2c_eeprom_am_get) and dra7
(ti_i2c_eeprom_dra7_get) which use constant data structure which allows
us to do a complete read of the data, the
am6(ti_i2c_eeprom_am6_get) eeprom parse operation is dynamic.
This removes the option of being able to read the complete eeprom data
in one single shot.
Fortunately, on the I2C bus, we do see the following behavior: In 1
byte mode, if we attempt to read the first header data yet again, the
misbehaving 2 byte addressing device acts in constant addressing mode
which results in the header not matching up and follow on attempt at 2
byte addressing scheme grabs the correct data.
This costs us an extra ~3 milliseconds, which is a minor penalty
compared to the consistent image support we need to have.
Reported-by: Jason Kridner <jkridner@beagleboard.org>
Fixes: a58147c2db ("board: ti: common: board_detect: Do 1byte address checks first.")
Signed-off-by: Nishanth Menon <nm@ti.com>
Commit c0fce929564f("vexpress64: fvp: enable OF_CONTROL") added code to
consider a potential DTB address being passed in the x0 register, or
revert to the built-in DTB otherwise.
The former case was used when using the boot-wrapper, to which we sell
U-Boot as a Linux kernel. The latter was meant for TF-A, for which we
couldn't find an easy way to use the DTB it uses itself. We have some
quirk to filter for a valid DTB, as TF-A happens to pass a pointer to
some special devicetree blob in x0 as well.
Now the TF-A case is broken, when enabling proper emulation of secure
memory (-C bp.secure_memory=1). TF-A carves out some memory at the top
of the first DRAM bank for its own purposes, and configures the
TrustZone DRAM controller to make this region secure-only. U-Boot will
then hang when it tries to relocate itself exactly to the end of DRAM.
TF-A announces this by carving out that region of the /memory node, in
the DT it passes on to BL33 in x1, but we miss that so far.
Instead of repeating this carveout in our DT copy, let's try to look for
a DTB at the address x1 points to as well. This will let U-Boot pick up
the DTB provided by TF-A, which has the correct carveout in place,
avoiding the hang.
While we are at it, make the detection more robust: the length test (is
the DT larger than 256 bytes?) is too fragile, in fact the TF-A port for
a new FVP model already exceeds this. So we test x1 first, consider 0
an invalid address, and also require a /memory node to detect a valid DTB.
And for the records:
Some asking around revealed what is really going on with TF-A and that
ominous DTB pointer in x0: TF-A expects EDK-2 as its non-secure payload
(BL33), and there apparently was some long-standing ad-hoc boot protocol
defined just between the two: x0 would carry the MPIDR register value of
the boot CPU, and the hardware DTB address would be stored in x1.
Now the MPIDR of CPU 0 is typically 0, plus bit 31 set, which is defined
as RES1 in the ARMv7 and ARMv8 architectures. This gives 0x80000000,
which is the same value as the address of the beginning of DRAM (2GB).
And coincidentally TF-A put some DTB structure exactly there, for its
own purposes (passing it between stages). So U-Boot was trying to use
this DTB, which requires the quirk to check for its validity.
Signed-off-by: Andre Przywara <andre.przywara@arm.com>
Tested-by: Peter Hoyes <peter.hoyes@arm.com>
- SPL fixes for STM32F7 MCUs
- Device tree alignement with kernelv6.0-rc4 for MCU's board
- Device tree alignement with kernelv6.0-rc3 for MPU's board
- Update DDR node for STM32MP15
- Cleanup config file for STM32MP1
- Update for cmd_stm32key command
- Fix compatible string to add partitions for STM32MP1
- Update for stm32programmer tool
-----BEGIN PGP SIGNATURE-----
iQJQBAABCgA6FiEEXyrViUccKBz9c35Jysd4L3sz/6YFAmMy5KMcHHBhdHJpY2Uu
Y2hvdGFyZEBmb3NzLnN0LmNvbQAKCRDKx3gvezP/phGoEACO/DdR5qrZcWYZhK8t
4ZhCYW3+anI7hx/aOx2k36JIw8V7kTCivBszTXtvEFLoPARKSt2RCGKRrSciyPw8
e5HaX85fvOum1+p555LzGBerleezz3dMIE6PgjuWHQgznVh5jaJPvu5SacOoU2yt
RCQbrBUqMxZ9HPFWOWsmqBo5rIskgn0fhkSDaqj+v0yqnj/HLZk5NtAy4q3KYxA1
yL4rHB5+SM7ENh1KsPJm+8M5FTjBmVBZKp17mcu/3z3RwNNCjEVG0aXw8Im7pzb8
b0pwnOqxRMBsBNOqnZ6kmNdKeOBZVfh35dBXplUxfMG6VYWwrNUTAgLnwPIFbFWX
qaMiyRdAK5KArOCWFzbJN8oqCrM7hrTnlpmK9ilILJ81VuN/JDvFmLle31DrOxm6
XzVh8GOp+cjEmJckcm8ChAUGB/Q1ToTZd6TMXN69IzcmE0t0rW/j+muILVeq+rT5
JmWz+5av9W1nKRVP9WzfjOVASNdNgNRQMYAn8jJwUU/oiEw6QIZUP4m5rngSNMzQ
f3Jzl+zO7QfFtT4NHir1HNguJRnZxuzxBc3Ok639UwzMJQwHuy6LPJnAlKLUoYuE
LYkplLn7UA8aSbiWJq04fws0xrTYMvK1VWZp5CFgsnsc2usLy4Sks9JIwyqmAxme
dF0ut2NYT3o8Ctn9ppezA+sx2w==
=iA80
-----END PGP SIGNATURE-----
Merge tag 'u-boot-stm32-20220927' of https://source.denx.de/u-boot/custodians/u-boot-stm into next
- Increase SYS_MALLOC_F_LEN for STM32 MCU's board
- SPL fixes for STM32F7 MCUs
- Device tree alignement with kernelv6.0-rc4 for MCU's board
- Device tree alignement with kernelv6.0-rc3 for MPU's board
- Update DDR node for STM32MP15
- Cleanup config file for STM32MP1
- Update for cmd_stm32key command
- Fix compatible string to add partitions for STM32MP1
- Update for stm32programmer tool
xilinx:
- Add support for new Versal NET SOC
zynqmp:
- Use mdio bus for ethernet phy description
- Wire ethernet phy reset via i2c-gpio
versal:
- Config cleanup
-----BEGIN PGP SIGNATURE-----
iF0EABECAB0WIQQbPNTMvXmYlBPRwx7KSWXLKUoMIQUCYzGwogAKCRDKSWXLKUoM
Ial4AJ9+4WHn0MV2X7gK1fyh4lUW7ggPhQCggsYlSoACgMgdji17SAPhCv/W3IA=
=BmA9
-----END PGP SIGNATURE-----
Merge tag 'xilinx-for-v2023.01-rc1-v2' of https://gitlab.denx.de/u-boot/custodians/u-boot-microblaze into next
Xilinx changes for v2023.01-rc1 (round 2)
xilinx:
- Add support for new Versal NET SOC
zynqmp:
- Use mdio bus for ethernet phy description
- Wire ethernet phy reset via i2c-gpio
versal:
- Config cleanup
Versal NET platform is based on Versal chip which is reusing a lot of IPs.
For more information about new IPs please take a look at DT which describe
currently supported devices.
The patch is adding architecture and board support with soc detection
algorithm. Generic setting should be very similar to Versal but it will
likely diverge in longer run.
Signed-off-by: Michal Simek <michal.simek@amd.com>
Link: https://lore.kernel.org/r/320206853dc370ce290a4e7b6d0bb26b05206021.1663589964.git.michal.simek@amd.com
Commit 37dc958947 ("global_data.h: Change ram_top type to phys_addr_t")
changed type of ram_top member from ulong to phys_addr_t but did not
changed types in board_get_usable_ram_top() function which returns value
for ram_top.
So change ulong to phys_addr_t type also in board_get_usable_ram_top()
signature and implementations.
Fixes: 37dc958947 ("global_data.h: Change ram_top type to phys_addr_t")
Signed-off-by: Pali Rohár <pali@kernel.org>
Reviewed-by: Simon Glass <sjg@chromium.org>
This patch adds general board files based on MT7981 SoCs.
MT7981 uses one mmc controller for booting from both SD and eMMC, and the
pins of mmc controller are also shared with spi controller.
So three configs are need for these boot types:
1. mt7981_rfb_defconfig - SPI-NOR and SPI-NAND
2. mt7981_emmc_rfb_defconfig - eMMC only
3. mt7981_sd_rfb_defconfig - SD only
Reviewed-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Weijie Gao <weijie.gao@mediatek.com>
Add general board files based on MT7986 SoCs.
MT7986 uses one mmc controller for booting from both SD and eMMC.
Both MT7986A and MT7986B use the same pins for spi controller.
Configs for various boot types:
1. mt7986_rfb_defconfig - SPI-NOR and SPI-NAND for MT7986A/B
2. mt7986a_bpir3_emmc_defconfig - eMMC for MT7986A only
3. mt7986a_bpir3_sd_defconfig - SD for MT7986A only
Reviewed-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Weijie Gao <weijie.gao@mediatek.com>
Current compatible string used to update SPI NAND and SPI NOR devices
can lead to a wrong partitions update (for example, SPI NAND partitions
added to SPI NOR node in the device tree). To avoid this wrong behavior,
use jedec,spi-nor compatible string for SPI NOR devices and spi-nand
compatible string for SPI NAND devices.
Signed-off-by: Christophe Kerello <christophe.kerello@foss.st.com>
Signed-off-by: Patrick Delaunay <patrick.delaunay@foss.st.com>
Reviewed-by: Patrice Chotard <patrice.chotard@foss.st.com>
-----BEGIN PGP SIGNATURE-----
iQFQBAABCgA6FiEEqxhEmNJ6d7ZdeFLIHrMeAg6sL8gFAmMoEdgcHGV1Z2VuLmhy
aXN0ZXZAbWljcm9jaGlwLmNvbQAKCRAesx4CDqwvyNvEB/4nEeiBx7Lo1gK+79PJ
9kCUngglHRu3/+FJMpcOp+2b6sSW1IZs8qGBMAMFSRoFElrLMMbVEgBR0ZfJCl3c
It0xN9Buhe8muwtAdE8Amr4PddUEynzglVPpFUFfir6ZqFAcedmN6iuh+K82r7Be
7s/8tRb2hVp//TpkEntf2yxrYnyeW4qiXyUxbUhaUyyhkM3RBXySuY4qnaaLp3NY
R9rsIY5j3kA2QylebEamlXI+KDvszrGbkUOUUrlwkygQNR/GmAYQPlY1TdBwk0wE
U1CO8zQYaL3OY998lU32pMVClmwyXbn2i7KAyMm3TEgrfpjQsLTS2BK+w+RBdMGL
XGnt
=lRvM
-----END PGP SIGNATURE-----
Merge tag 'u-boot-at91-2023.01-a' of https://source.denx.de/u-boot/custodians/u-boot-at91 into next
First set of u-boot-at91 features for the 2023.01 cycle:
This feature set includes the important update on PIO4 pinctrl driver
that solves a long time mismatch between Linux and U-boot, related on
the unification of pinctrl and gpio driver support, now respecting the
pinctrl bindings ABI; and also support for pinctrl subnodes. The feature
set also adds support for PDA screen detection for sam9x60_curiosity
board , one fix for SD-Card reinsertion and one fix for sam9x60 clocks.
Call the PDA detection mechanism at boot time so that we can
have the pda environment variable ready for use.
Signed-off-by: Durai Manickam KR <durai.manickamkr@microchip.com>
Adjust the DRAM timing settings for this board per ones provided
by hardware department. The change is applied to the LPDDR4 MR11
register CA ODT configuration, from RZQ/6 to RZQ/3, which fixes
stability issues on subset of boards. The DDR PHY PIE block has
been updated accordingly.
Signed-off-by: Marek Vasut <marex@denx.de>
Cc: Fabio Estevam <festevam@gmail.com>
Cc: Peng Fan <peng.fan@nxp.com>
Cc: Stefano Babic <sbabic@denx.de>
Reviewed-by: Fabio Estevam <festevam@denx.de>
This code part is broken, remove it.
Signed-off-by: Andrejs Cainikovs <andrejs.cainikovs@toradex.com>
Signed-off-by: Denys Drozdov <denys.drozdov@toradex.com>
This code part is broken, remove it.
Signed-off-by: Andrejs Cainikovs <andrejs.cainikovs@toradex.com>
Signed-off-by: Denys Drozdov <denys.drozdov@toradex.com>
- Annotate boot devices available in spl_board_boot_device().
- Drop SD3_BOOT/MMC3_BOOT not available for boot on Verdin iMX8M Mini.
Signed-off-by: Marcel Ziswiler <marcel.ziswiler@toradex.com>
Prepare for optional job ring driver model. Sec may be initialized based
on the job ring information processed from the device tree.
Signed-off-by: Marcel Ziswiler <marcel.ziswiler@toradex.com>
Commit 99c7cc58e1 ("ddr: imx: Add i.MX9 DDR controller driver")
contains an inobvious side-effect which renders all systems using
DRAM controller at 3732 MT/s unbootable. The change is located in
ddrphy_init_set_dfi_clk(), where the switch case statement entry
3732 changed to entry 3733, so any board with DDR calibration data
for 3732 MT/s operations needs to be updated to 3733 MT/s to match
the change.
Since there is currently only one such board, update the board instead
of handling both 3732 and 3733 options in the driver. It is likely the
NXP MX8MP RPA update will follow and use the later value too.
Signed-off-by: Marek Vasut <marex@denx.de>
Cc: Fabio Estevam <festevam@denx.de>
Cc: Peng Fan <peng.fan@nxp.com>
Cc: Stefano Babic <sbabic@denx.de>
Cc: Ye Li <ye.li@nxp.com>
Cc: uboot-imx <uboot-imx@nxp.com>
Reviewed-by: Fabio Estevam <festevam@denx.de>
The GW73xx-C revision and onward replaced the 5-port PCIe switch with a
4-port (dropping PCIe to one of the miniPCIe sockets) due to part
availability. This moved the PCI bus of the GbE eth1 device. Use a fixup
to adjust the dt accordingly so that local-mac-address assigned from dt
works on new revision boards.
While we are at it, rename 'blob' to 'fdt' for clarity.
Signed-off-by: Tim Harvey <tharvey@gateworks.com>
This commit adds board support for i.MXRT1170-EVK from NXP. This board
is an evaluation kit provided by NXP for i.MXRT117x processor family.
Signed-off-by: Jesse Taube <Mr.Bossman075@gmail.com>
It seems that waiting only 10 ms after releasing LAN switch from reset
is not enough for the strapping pins to latch the requested values.
P6_MODE[0] is latched to 0 instead of 1.
Increasing the delay to 50 ms fixes this issue.
Signed-off-by: Marek Behún <kabel@kernel.org>
Reviewed-by: Stefan Roese <sr@denx.de>
Globally replace all occurances of WATCHDOG_RESET() with schedule(),
which handles the HW_WATCHDOG functionality and the cyclic
infrastructure.
Signed-off-by: Stefan Roese <sr@denx.de>
Reviewed-by: Simon Glass <sjg@chromium.org>
Tested-by: Tom Rini <trini@konsulko.com> [am335x_evm, mx6cuboxi, rpi_3,dra7xx_evm, pine64_plus, am65x_evm, j721e_evm]
Currently Makefile produces final mpc85xx image when SPL is not used in
custom file u-boot-with-dtb.bin. It is quite confusing name as build
process produce also intermediate file standard file u-boot-dtb.bin (which
is just intermediate and not bootable). Other platforms use u-boot.bin
(UBOOT_BIN) as standard name for final bootable raw image.
So change Makefile rules and binman to produce final bootable file for
mpc85xx also into file u-boot.bin. There is just need for mpc85xx to not
define default rule for u-boot.bin then instruct binman (via DTS file) to
store final image into u-boot.bin (instead of u-boot-with-dtb.bin) and
finally rename target u-boot-with-dtb.bin to u-boot.bin.
With this change are also removed custom Makefile hacks for mpc85xx that it
produced non-standard output file. And also updated documentation.
Signed-off-by: Pali Rohár <pali@kernel.org>
Reviewed-by: Tom Rini <trini@konsulko.com>
Signed-off-by: Marek Behún <kabel@kernel.org>
We currently have an if_type (interface type) and a uclass id. These are
closely related and we don't need to have both.
Drop the if_type values and use the uclass ones instead.
Maintain the existing, subtle, one-way conversion between UCLASS_USB and
UCLASS_MASS_STORAGE for now, and add a comment.
Signed-off-by: Simon Glass <sjg@chromium.org>
If kernel image in uImage or zImage format is not detected by
lowlevel_init.S code then do not clear memory location where image was
expected. If image is not detected then this memory region is unknown.
So do not unconditionally clear it.
Signed-off-by: Pali Rohár <pali@kernel.org>
The SPI and NAND board variants never went into production.
Drop those board variants.
Signed-off-by: Bernhard Messerklinger <bernhard.messerklinger@br-automation.com>
Reviewed-by: Wolfgang Wallner <wolfgang.wallner@br-automation.com>
This patch adds a fixup function related to a PCIe FLR (Function Level
Reset) problem on the NIC23 PCIe board. This function is imported from
the Marvell Octeon 2013 U-Boot version as a (nearly) verbatim copy. It
uses the newly introduced cyclic infrastructure, so that this function
gets called every 100us, which is needed to detect this FLR issue.
Signed-off-by: Aaron Williams <awilliams@marvell.com>
Signed-off-by: Stefan Roese <sr@denx.de>
Code supports board detection based on information available in EEPROM in
legacy or FRU format. But this is not enough for emulation and simulation
systems which are lacking these identification EEPROMs. But SOC itself has
normally registers for SOC identification. Based on them it is possible to
compose detected name. That's why prepare infrastructure in common location
for SOC platform detection which is called before board platform detection.
SOC platform detection shouldn't detect real silicon and should fallback to
current existing mechanism to identify boards based on EEPROMs.
Signed-off-by: Michal Simek <michal.simek@amd.com>
Link: https://lore.kernel.org/r/329a8da338927b082e26a958bf69bb18af072420.1662460837.git.michal.simek@amd.com
The commit ce39ee28ec ("zynqmp: Do not place u-boot to reserved memory
location") adds functionality for ZynqMP to read reserved memory node and
do not place U-Boot to reserved location. This functionality is generic
across all Xilinx SOCs that's why move it to common location to be used by
all Xilinx SOCs.
On zynq platform this is also fixing issue where U-Boot was placed to
locating which was reserved already which ends up with error message
"ERROR: reserving fdt memory region failed (addr=30000000 size=10000000
flags=4)" which is shown when bdinfo is called.
Tested on vck190, zcu102, zc706 and kc705 to cover all platforms.
Signed-off-by: Michal Simek <michal.simek@amd.com>
Link: https://lore.kernel.org/r/b0817807912f7c7af6a8e1cf9ee04e5ab5de5f6a.1661430188.git.michal.simek@amd.com
The commit 53b406369e ("DFU: Check the number of arguments and argument
string strictly") added strict control over string that 0:1 partition
definition is not valid anymore that's why use only device number without
partition ID. Device is specified by 2nd parameter and partition by 3rd.
Signed-off-by: Michal Simek <michal.simek@amd.com>
Link: https://lore.kernel.org/r/840eca944f4f2abeeb63b5d724f9ba5fe9a9213b.1660055571.git.michal.simek@amd.com
$fdt_addr is mandatory for systems which provides DTB in HW (e.g. ROM) and
wishes to pass that DTB to Linux.
Turris Mox contains DTB binary in SPI NOR memory at "dtb" partition which
starts at offset 0x7f0000 and is 0x10000 bytes long.
Armada 3700 CPU does not allow mapping SPI NOR memory into physical address
space like on other architectures and therefore set $fdt_addr variable to
memory range in RAM and loads this DTB binary from SPI NOR in misc_init_r()
function.
Signed-off-by: Pali Rohár <pali@kernel.org>
Reviewed-by: Stefan Roese <sr@denx.de>
When rescue mode was activated reset also bootdelay env variable to its
default value. This will ensure that reset button works and starts rescue
mode also in the case when user changed bootdelay env variable to -1 (which
has meaning to not start autoboot).
Signed-off-by: Pali Rohár <pali@kernel.org>
Reviewed-by: Marek Behún <kabel@kernel.org>
Reviewed-by: Stefan Roese <sr@denx.de>
Store serial number from atsha cryptochip into the serial# env variable.
U-Boot automatically puts content of this variable into the root device
tree property serial-number when booting Linux kernel. Refactor turris
atsha code and from turris_atsha_otp_get_serial_number() function returns
directly string suitable for printing or storing into device tree. Because
during different boot stages is env storage read-only, it is not possible
to always store serial number into env storage. So introduce a new function
turris_atsha_otp_init_serial_number() which is called at later stage and
which ensures that serial number is correctly stored into env.
Signed-off-by: Pali Rohár <pali@kernel.org>
Reviewed-by: Marek Behún <kabel@kernel.org>
Reviewed-by: Stefan Roese <sr@denx.de>
The user provided key address was not flushed in struct aes because of
the flushing location in the function.
Signed-off-by: Janne Ylalehto <ylalehto@gmail.com>
Link: https://lore.kernel.org/r/20220816124525.19671-1-ylalehto@gmail.com
Signed-off-by: Michal Simek <michal.simek@amd.com>
- remove test on CONFIG_DM_REGULATOR in stm32mp1 board
and enable CONFIG_DM_REGULATOR for stm32f769-disco
- handle ck_usbo_48m clock provided by USBPHYC to fix the command 'usb start'
after alignment with Linux kernel v5.19 DT (clocks = <&usbphyc>)
- Fix SYS_HZ_CLOCK value for stih410-b2260 board
- Switch STMM32MP15x DHSOM to FMC2 EBI driver
- Remove hwlocks from pinctrl in STM32MP15x to avoid issue with kernel
-----BEGIN PGP SIGNATURE-----
iQEzBAABCgAdFiEE56Yx6b9SnloYCWtD4rK92eCqk3UFAmMZoW4ACgkQ4rK92eCq
k3W2MAgAsmy2aSlMYo/AGlJ/KCrZuk6OirNHtdOdacvbcdUUbpkNpBSjdkrRm2If
VUnY1utIIJe6gFgnBUxXJ3RF5FZuhkdawc6V25HtDp6H3WamzJknKs5Vc4TlKp59
hZCOto7/+G/cd2XLdCKFUBl+new1pdDPsEm56+57DeZ7QGAQRX35PUQ5+HBjQJ/N
n/wJgS6wkEdIQLLwmCVxbHUkC+pRotTza5F2A0qZJgYPMcMpVFYKtzIa4GbWB5YS
MKGHbM8f3C8RLPQaHHTRycoA2Yor1I52B4Oi7605c5zHQr9pjrgtWsernDzkIhsB
ThYHSYQBUBTY4HBfzFwzCkVGqqLWNg==
=PMFY
-----END PGP SIGNATURE-----
Merge tag 'u-boot-stm32-20220907' of https://source.denx.de/u-boot/custodians/u-boot-stm
- simplify the STM32MP15x package parsing code
- remove test on CONFIG_DM_REGULATOR in stm32mp1 board
and enable CONFIG_DM_REGULATOR for stm32f769-disco
- handle ck_usbo_48m clock provided by USBPHYC to fix the command 'usb start'
after alignment with Linux kernel v5.19 DT (clocks = <&usbphyc>)
- Fix SYS_HZ_CLOCK value for stih410-b2260 board
- Switch STMM32MP15x DHSOM to FMC2 EBI driver
- Remove hwlocks from pinctrl in STM32MP15x to avoid issue with kernel
CPLD in load_default mode ignores watchdog reset signal. It does not reset
board when watchdog triggers reset signal.
Detect load_default mode by GPIO7 - LOAD_DEFAULT_N and delete watchdog
max6370 node from device to prevent registering driver for non-working
watchdog.
Signed-off-by: Pali Rohár <pali@kernel.org>
Signed-off-by: Peng Fan <peng.fan@nxp.com>
Perform long overdue conversion of ad-hoc FMC2 EBI bus initialization
to upstream FMC2 EBI driver. No functional change.
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>
Reviewed-by: Patrick Delaunay <patrick.delaunay@foss.st.com>
The tests on CONFIG_DM_REGULATOR, added to avoid compilation issues, can
now be removed, they are no more needed since the commit 16cc5ad0b4
("power: regulator: add dummy helper").
Signed-off-by: Patrick Delaunay <patrick.delaunay@foss.st.com>
Reviewed-by: Patrice Chotard <patrice.chotard@foss.st.com>
P1/P2 RDB boards have external max6370 watchdog connected to CPLD and this
watchdog is not deactivated on board reset. So if it is active during board
reset, it can trigger another reset when CPU is booting U-Boot. To prevent
possible infinite reset loop caused by external watchdog, turn it off
before reset.
Do it via a new board_reset_prepare() callback which is called from
do_reset() function before any reset sequence.
Signed-off-by: Pali Rohár <pali@kernel.org>
Signed-off-by: Peng Fan <peng.fan@nxp.com>
CPLD's system reset register is buggy and requires workaround in U-Boot.
So use this kind of board reset only when there is no other reset option.
Introduce a new board_reset_last() callback which is last-stage
board-specific reset and implement CPLD's system reset in this new
board_reset_last() callback instead of board_reset() callback.
Fixes: 20fb58fc5a ("board: freescale: p1_p2_rdb_pc: Implement board_reset()")
Signed-off-by: Pali Rohár <pali@kernel.org>
Signed-off-by: Peng Fan <peng.fan@nxp.com>
If watchdog timer was already set to non-disabled value then it means that
watchdog timer was already activated, has already expired and caused CPU
reset. If this happened then due to CPLD firmware bug, writing to wd_cfg
register has no effect and therefore it is not possible to reactivate
watchdog timer again. Watchdog starts working again after CPU reset via
non-watchdog method.
Implement this workaround (reset CPU when it was reset by watchdog) to make
watchdog usable again. Watchdog timer logic on these P1/P2 RDB boards is
connected to CPLD, not to SoC itself.
Note that reset does not occur immediately after calling do_reset(), but
after few ms later as real reset is done by CPLD. So it is normal that
function do_reset() returns. Therefore hangs after calling do_reset() to
prevent CPU execution of the rest U-Boot code.
Signed-off-by: Pali Rohár <pali@kernel.org>
Signed-off-by: Peng Fan <peng.fan@nxp.com>
CPLD's system reset register on P1/P2 RDB boards is not autocleared after
flipping it. If this register is set to one in 100ms after reset starts
then CPLD triggers another CPU reset.
This means that trying to reset board via CPLD system reset register cause
reboot loop. To prevent this reboot loop, the only workaround is to try to
clear CPLD's system reset register as early as possible. U-Boot is already
doing it in its board_early_init_f() function, which seems to be enough as
register is cleared prior CPLD triggers another reset.
But board_early_init_f() is not called from SPL and therefore usage of SPL
can cause reboot loop.
To prevent reboot loop when using SPL, call board_early_init_f() function
in SPL too. For accessing CPLD memory space it is needed to have CPLD entry
in TLB.
With this change it is possible to trigger board reset via CPLD's system
reset register on P2020 RDB board.
Signed-off-by: Pali Rohár <pali@kernel.org>
Signed-off-by: Peng Fan <peng.fan@nxp.com>
In both the Freescale DDR controller and the SPD spec, bank address bits
are stored as the number of bank address bits minus 2. For example, if a
chip had 8 banks (3 total bank address bits), the value of
bank_addr_bits would be 1. This is rather surprising for users
configuring their memory manually, since they can't set bank_addr_bits
to the actual number of bank address bits. Rectify this.
There is at least one example of this kind of mistake already, in
board/freescale/t102xrdb/ddr.c. The documented MT40A512M8HX has two bank
address bits, but bank_addr_bits was set to 2, implying 4 bank address
bits. Such a value is reserved in BA_BITS_CS, but I suspect the
controller simply ignores the top bit, making this kind of mistake
harmless, if misleading.
Fixes: e8a7f1c32b ("powerpc/t1023rdb: Add T1023 RDB board support")
Signed-off-by: Sean Anderson <sean.anderson@seco.com>
Signed-off-by: Peng Fan <peng.fan@nxp.com>
Depending on the boot source, set different CLI prompts. This will help
the user to figure out in which mode the bootloader was started. There
are two special modes: failsafe and SDHC boot.
Signed-off-by: Michael Walle <michael@walle.cc>
Signed-off-by: Peng Fan <peng.fan@nxp.com>
During startup the SPL will print where the u-boot proper is read from.
Instead of using the default names, provide more user friendly names.
Signed-off-by: Michael Walle <michael@walle.cc>
Signed-off-by: Peng Fan <peng.fan@nxp.com>
The board is able to boot from the following source:
- user-updateble SPI flash
- write-protected part of the same SPI flash
- eMMC
- SD card
Implement the needed function hooks to support all of these boot
sources.
Signed-off-by: Michael Walle <michael@walle.cc>
Signed-off-by: Peng Fan <peng.fan@nxp.com>
Commit 6aa4fe3912 ("dm: core: Rename and fix uclass_get_by_name_len()")
changed uclass_get_device_by_name() to an exact match when previously it
behaved as a prefix match.
The roc-cc code relied on this prefix match by only specifying part of
the device name. Fix this by using the full name including the address.
Signed-off-by: John Keeping <john@metanate.com>
Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
As the Renesas Reduced Pin Count Interface may be locked by TF-A, it is
disabled by default[1]. When unlocked, TF-A passes a DT fragment to
enable it, which is applied to the U-Boot DT[2].
Unlike the memory layout, the RPC-IF enablement is not propagated to
subsequent software. Hence e.g. Linux cannot know if the RPC-IF is
locked or not, and will lock-up when trying to access the RPC-IF when
locked.
Fix this by checking if the RPC-IF is enabled in the TF-A DT fragment, and
setting the status of the RPC-IF device node in the target DT, if
present, to "okay". Do this only when a "flash" subnode is found, to
avoid errors in subsequent software when the RPC-IF is not intended to
be used.
Note that this requires the status of the RPC-IF node to be set to
"disabled" in the target DT, just like in the U-Boot DT.
[1] commit 3d5f45c95c ("ARM: dts: rmobile: Disable RPC HF by
default")
[2] commit 361377dbdb ("ARM: rmobile: Merge prior-stage firmware
DT fragment into U-Boot DT on Gen3")
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Enable d-cache early in SPL right after DRAM is started up.
This reduces U-Boot proper load time by 650ms when loaded
from SPI NOR.
Signed-off-by: Marek Vasut <marex@denx.de>
Signed-off-by: Philip Oberfichtner <pro@denx.de>
There are three different kinds of EEPROM possibly present on boards.
1. 1byte address. For those we should avoid 2byte address in order
not to rewrite the data. Second byte of the address can potentially
be interpreted as the data to write.
2. 2byte address with defined behaviour. When we try to use 1byte
address they just return "FF FF FF FF ... FF"
3. 2byte address with undefined behaviour (for instance, 24LC32AI).
When we try to use 1byte address, then their internal read
pointer is changed to some value. Subsequential reads may be
broken.
To gracefully handle both case #1 and case #3 we read all required
data from EEPROM at once (about 80 bytes). So either all the data is
valid or we fallback to 2byte address.
Cc: Nishanth Menon <nm@ti.com>
Fixes: a58147c2db ("board: ti: common: board_detect: Do 1byte address checks first.")
Reference: https://lore.kernel.org/all/CAJs94Ebdd4foOjhGFu9Bop0v=B1US9neDLxfhgcY23ukgLzFOQ@mail.gmail.com/
Signed-off-by: Matwey V. Kornilov <matwey.kornilov@gmail.com>
Acked-by: Nishanth Menon <nm@ti.com>
For USB3 host controller to detect devices on the bus it is required to
enable a PMIC GPIO: usb_vbus_boost_pin. So enable that during board
specific initialization.
And since this PMIC GPIO parsing is quite u-boot specific, so add a
DT override to qcs404-evb-uboot.dtsi to represent usb_vbus_boost_pin.
Signed-off-by: Sumit Garg <sumit.garg@linaro.org>
Use the new mvebu GPIO driver and convert all the function calls to the
former kirkwood GPIO driver. This means that we are now using the LED
uclass and the regulator uclass. Unfortunately, the GPIO LED doesn't
offer a blinking method. Thus we are now stuck with solid on and off
states, which makes debugging a bit harder. Also, there is no GPIO fan
driver for now.
Signed-off-by: Michael Walle <michael@walle.cc>
Reviewed-by: Stefan Roese <sr@denx.de>
If something is wrong with the environment, we cannot rely on a proper
u-boot operation anymore. In fact, it is possible, that we never reach
misc_init_r() with a broken environment.
Also don't enable the netconsole by environment settings. This way the
user don't have to reconfigure the environment. Instead the network
console is only enabled when the push button is pressed during boot.
Signed-off-by: Michael Walle <michael@walle.cc>
Reviewed-by: Stefan Roese <sr@denx.de>
The board code needs this to be set. Otherwise, the recovery mechanism
doesn't work. Therefore, select this option automatically with the
board.
Signed-off-by: Michael Walle <michael@walle.cc>
Reviewed-by: Stefan Roese <sr@denx.de>
Cleanup the included header files in the board code. These are all
leftovers from earlier days.
Signed-off-by: Michael Walle <michael@walle.cc>
Reviewed-by: Stefan Roese <sr@denx.de>
This is not needed. The user can force setting the variables with
"setenv -f".
Signed-off-by: Michael Walle <michael@walle.cc>
Reviewed-by: Stefan Roese <sr@denx.de>
