Set default COUNTER_FREQUENCY according to config header file
under include/configs/
i.MX6UL/ULL/7D/8QM/8QXP all has system counter frequency run at 8MHz,
so set default value for them.
SUNXI/EXYNOS/ROCKCHIP_RK3128/ROCKCHIP_RK3288/ROCKCHIP_RK322X/ROCKCHIP_RK3036
at 24MHz. ARCH_LX2160A at 25MHz
ARCH_ZYNQMP at 100MHz
Since versal has CONFIG_COUNTER_FREQUENCY, so use it. And
COUNTER_FREQUENCY will be dropped.
Signed-off-by: Peng Fan <peng.fan@nxp.com>
Reviewed-by: Michal Simek <michal.simek@xilinx.com>
ATSHA204A uses bit-reversed checksum of standard CRC-16 with polynomial
x^16 + x^15 + x^2 + 1.
This ATSHA204A specific checksum can be calculated just by using common
U-Boot functions bitrev16() and crc16().
So replace custom driver CRC-16 implementation by common U-Boot functions.
Signed-off-by: Pali Rohár <pali@kernel.org>
Reviewed-by: Stefan Roese <sr@denx.de>
Implementation in linux/crc16.h provides standard CRC-16 algorithm with
polynomial x^16 + x^15 + x^2 + 1. Use it and remove duplicate ext4 CRC-16
specific code.
Signed-off-by: Pali Rohár <pali@kernel.org>
Reviewed-by: Stefan Roese <sr@denx.de>
File fs/ubifs/crc16.h is standard linux's crc16.h include file. So move it
from fs/ubifs to include/linux where are also other linux include files.
Signed-off-by: Pali Rohár <pali@kernel.org>
Reviewed-by: Stefan Roese <sr@denx.de>
U-Boot CRC-16 implementation uses polynomial x^16 + x^12 + x^5 + 1 which is
not standard CRC-16 algorithm, but it is known as CRC-16-CCITT. Rename file
crc16.c to crc16-ccitt.c to reduce confusion.
Signed-off-by: Pali Rohár <pali@kernel.org>
Reviewed-by: Stefan Roese <sr@denx.de>
On P2020 board is SPL malloc simple always failing with error and loops:
SD boot...
alloc space exhausted
Bad trap at PC: f8f8b5f0, SR: 21200, vector=d00
NIP: 00000000 XER: 00000000 LR: 00000000 REGS: f8f8b5f0 TRAP: 20000000 DAR: 00000000
MSR: 00021200 EE: 0 PR: 0 FP: 0 ME: 1 IR/DR: 00
GPR00: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
GPR08: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
GPR16: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
GPR24: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
Call backtrace:
Exception in kernel pc f8f8b5f0 signal 0
Inspection showed that gd->malloc_limit is zero. And it is because
generally SPL_FRAMEWORK initialize SPL's gd->malloc_limit. But when
SPL_FRAMEWORK is not enabled then in most cases nobody initialize
gd->malloc_limit and so SPL malloc simple does not work.
So disable SPL_SYS_MALLOC_SIMPLE by default when SPL_FRAMEWORK is not
enabled. SPL_SYS_MALLOC_SIMPLE can be disabled only by setting
SPL_SYS_MALLOC_F_LEN to zero. So do it.
This change fixes SPL error "alloc space exhausted" on P2020 board.
Signed-off-by: Pali Rohár <pali@kernel.org>
- For the environment, add a arch_env_get_location hook and make use of
it on some NXP platforms (so that boards can override SoCs).
- Remove some unused squashfs code from SPL
- Resync am335x beaglebone related DTS files
- Enable SPL_SEPARATE_BSS if SPL_BSS_START_ADDR is used
If .bss does not immediately follow the end of the image, then
CONFIG_SPL_SEPARATE_BSS must be selected. Typically, the location of bss
is specified by using CONFIG_SPL_BSS_START_ADDR in a linker script. On
these arches, CONFIG_SPL_SEPARATE_BSS should be enabled. If there is an
option to use an alternate boot script (e.g. CONFIG_SPL_LDSCRIPT is just
a default), just imply. If there is not, select.
Signed-off-by: Sean Anderson <sean.anderson@seco.com>
The Sancloud BeagleBone Enhanced Extended WiFi (BBE Extended WiFi) has
its own devicetree file and the board can be identified by the 2nd
letter of the config string within the common EEPROM.
Signed-off-by: Paul Barker <paul.barker@sancloud.com>
The Sancloud BeagleBone Enhanced Lite (BBE Lite) has its own devicetree
file and the board can be identified by the 2nd letter of the config
string within the common EEPROM.
Signed-off-by: Paul Barker <paul.barker@sancloud.com>
Sync BeagleBone dts files & TPS dtsi files with Linux v5.17 and include
the SanCloud BBE Extended WiFi dts added in v5.18-rc1. Also pull in
changes to am33xx-l4.dtsi needed to support the BeagleBone Blue.
The change to use the cpsw switch driver (commit c477358e66a3 in Linux)
is excluded from the sync as u-boot does not recognise the new
compatible string.
Signed-off-by: Paul Barker <paul.barker@sancloud.com>
Implement arch_env_get_location() instead of env_get_location(), so that
the env_get_location() can be implemented on board level and override the
arch_env_get_location() architecture defaults.
Signed-off-by: Marek Vasut <marex@denx.de>
Cc: Adam Ford <aford173@gmail.com>
Cc: Fabio Estevam <festevam@denx.de>
Cc: Marek Behún <marek.behun@nic.cz>
Cc: Peng Fan <peng.fan@nxp.com>
Cc: Simon Glass <sjg@chromium.org>
Cc: Stefano Babic <sbabic@denx.de>
Cc: Tim Harvey <tharvey@gateworks.com>
Cc: Tom Rini <trini@konsulko.com>
Cc: Tommaso Merciai <tomm.merciai@gmail.com>
Cc: Vladimir Oltean <vladimir.oltean@nxp.com>
Implement arch_env_get_location() instead of env_get_location(), so that
the env_get_location() can be implemented on board level and override the
arch_env_get_location() architecture defaults.
Signed-off-by: Marek Vasut <marex@denx.de>
Cc: Adam Ford <aford173@gmail.com>
Cc: Fabio Estevam <festevam@denx.de>
Cc: Marek Behún <marek.behun@nic.cz>
Cc: Peng Fan <peng.fan@nxp.com>
Cc: Simon Glass <sjg@chromium.org>
Cc: Stefano Babic <sbabic@denx.de>
Cc: Tim Harvey <tharvey@gateworks.com>
Cc: Tom Rini <trini@konsulko.com>
Cc: Tommaso Merciai <tomm.merciai@gmail.com>
Cc: Vladimir Oltean <vladimir.oltean@nxp.com>
Currently there is only one way to override desired environment location,
by implementing env_get_location(). This is increasingly being conflated
both on board level and architecture level, which leads to a problem on
boards where this function is already implemented on architecture level,
since those boards have no way to override this environment location on
board level anymore.
Implement arch_env_get_location() function which is architecture specific
and should only ever be implemented in architecture code. This function
has lower priority than env_get_location(), which should only ever be
implemented in board code, and which overrides the arch_env_get_location()
architecture environment selection.
This way, architecture can define its default environment chooser, while
board can now override it as needed at all times.
There is no functional change, since env_get_location() simply returns
arch_env_get_location(), and arch_env_get_location() implements the
current env_get_location() default content.
Signed-off-by: Marek Vasut <marex@denx.de>
Cc: Adam Ford <aford173@gmail.com>
Cc: Fabio Estevam <festevam@denx.de>
Cc: Marek Behún <marek.behun@nic.cz>
Cc: Peng Fan <peng.fan@nxp.com>
Cc: Simon Glass <sjg@chromium.org>
Cc: Stefano Babic <sbabic@denx.de>
Cc: Tim Harvey <tharvey@gateworks.com>
Cc: Tom Rini <trini@konsulko.com>
Cc: Tommaso Merciai <tomm.merciai@gmail.com>
Cc: Vladimir Oltean <vladimir.oltean@nxp.com>
The Globalscale Technologies Sheevaplug board has the network chip
Marvell 88E1116R. Use uclass mvgbe and the compatible driver M88E1310
driver to bring up Ethernet.
- Remove CONFIG_RESET_PHY_R symbol from all board files
- Use uclass mvgbe to bring up the network. And remove ad-hoc code.
- Enable CONFIG_PHY_MARVELL to properly configure the network.
- Miscellaneous changes: Move constants to .c file and remove header file
board/Marvell/sheevaplug/sheevaplug.h, use BIT macro, and add/cleanup
comments.
Signed-off-by: Tony Dinh <mibodhi@gmail.com>
DT node name should be generic, therefore rename atsha204a@64 to crypto@64.
Signed-off-by: Pali Rohár <pali@kernel.org>
Reviewed-by: Marek Behún <marek.behun@nic.cz>
Turris Omnia uses first MAC address from OTP for second ethernet interface.
Second MAC address for third interface and third MAC address for first
interface.
Other Turris routers do not have this rotate by one mapping. So add
function parameter for specifying id of the first ethernet interface.
Signed-off-by: Pali Rohár <pali@kernel.org>
Reviewed-by: Marek Behún <marek.behun@nic.cz>
Atsha device is used prior relocation and at this early stage BSS does not
have to be ready yet. So do not cache Atsha device in BSS.
Fixes support for other Turris routers.
Signed-off-by: Pali Rohár <pali@kernel.org>
Reviewed-by: Marek Behún <marek.behun@nic.cz>
OTP code is not Atsha generic but also it is not Omnia specific. It is
common for all Turris routers which use Atsha cryptochip for storing OTP.
So move this common Turris specific Atsha OTP code from Turris Omnia into
separate file. It will be used also by other Turris routers.
Signed-off-by: Pali Rohár <pali@kernel.org>
Reviewed-by: Marek Behún <marek.behun@nic.cz>
Implement write support for Security OTP values via mailbox API commands
MBOX_CMD_OTP_WRITE_32B and MBOX_CMD_OTP_WRITE.
Write support for North and South Bridge OTPs are not implemented as these
OTPs are already burned in factory with some data.
Signed-off-by: Pali Rohár <pali@kernel.org>
Reviewed-by: Marek Behún <marek.behun@nic.cz>
U-Boot SPL is on 32-bit mvebu executed by the BootROM. And BootROM expects
that U-Boot SPL returns execution back to the BootROM. Vectors during
execution of U-Boot SPL should not be changed as BootROM does not expect it
and uses its own vectors. So do not overwrite vectors in SPL build.
Signed-off-by: Pali Rohár <pali@kernel.org>
fstat()'s st_size works only for regular files. lseek() with SEEK_END works
also for block or MTD devices. This replacement allows kwboot to load
kwbimage from /dev/mtd0 for booting another device over /dev/ttyS0.
Signed-off-by: Pali Rohár <pali@kernel.org>
Reviewed-by: Marek Behún <marek.behun@nic.cz>
Armada 385 contains 64 lines of HD eFuse and 2 lines of LD eFuse. HD eFuse
is used for secure boot and each line is 64 bits long + 1 lock bit. LD
eFuse lines are 256 bits long + 1 lock bit. LD 0 line is reserved for
Marvell Internal Use and LD 1 line is for General Purpose Data. U-Boot
already contains HD eFuse reading and programming support.
This patch implements LD eFuse reading support. LD 0 line is mapped to
U-Boot fuse bank 64 and LD 1 line to fuse bank 65.
LD 0 Marvell Internal Use line seems that was burned in factory with some
data and can be read by U-Boot fuse command:
=> fuse read 64 0 9
LD 1 General Purpose Data line is by default empty and can be read by
U-Boot fuse command:
=> fuse read 65 0 9
Signed-off-by: Pali Rohár <pali@kernel.org>
Reviewed-by: Marek Behún <marek.behun@nic.cz>
Update the current uDPU defconfig with following changes:
* Disable CONFIG_SPI_BOOT, its not needed for booting and the device boots
from eMMC anyway.
* Disable CONFIG_SYS_CONSOLE_INFO_QUIET, there is no need to diverge from
other boards by not priting the console device
* Enable CONFIG_CMD_MTD in order to allow use of the MTD tool
* Disable CONFIG_CMD_MTDPARTS, with MTD now being able to parse partitions
from DTS there is no need for it, the default MTDPARTS were incorrect
anyway
* Enable CONFIG_MMC_HS200_SUPPORT, the eMMC used support both HS200 and
HS400 modes, so enable at least HS200 because Xenon driver does not
support HS400 currently
* Replace CONFIG_SPI_FLASH_BAR with CONFIG_SPI_FLASH_SFDP_SUPPORT
Utilize SFDP parsing instead of relying on the extended address registers
Signed-off-by: Robert Marko <robert.marko@sartura.hr>
Reviewed-by: Stefan Roese <sr@denx.de>
uDPU is a bit of a specific device in that it does not have any copper
ports nor any ethernet PHY-s but 2 SFP ports.
This is an issue since MVNETA requires a PHY phandle or a fixed-link to
be defined under its node.
Since U-boot has no SFP support this is reasonable in order to know how
to configure the MAC.
However this also means that networking does not work on uDPU at all
currently, and fails with:
uDPU>> dhcp
Could not get PHY for neta@30000: addr 0
phy_connect failed
Could not get PHY for neta@40000: addr 1
phy_connect failed
So, to provide working networking using only SFP-s let add the fixed-link
at 1G which is much more common than 2.5G SFP-s as well as disable the
TX_DISABLE pins like done on Armada 7040 and 8040 platforms.
Since uDPU is not using any of the GPIO-s on the SB controller for any
purpose other than GPIO, a call to the pinctrl must be made in order for
it to get probed and thus register the SB GPIO bank, otherwise SB GPIO-s
are not registered at all.
Signed-off-by: Robert Marko <robert.marko@sartura.hr>
Reviewed-by: Stefan Roese <sr@denx.de>
Add support for handling SFP TX disable for MVNETA in the same fashion as
to what MVPP2 is doing in order to enable using SFP-s.
This allows using ethernet on SFP only boards.
Signed-off-by: Robert Marko <robert.marko@sartura.hr>
Reviewed-by: Marek Behún <marek.behun@nic.cz>
Reviewed-by: Ramon Fried <rfried.dev@gmail.com>
Reviewed-by: Stefan Roese <sr@denx.de>
It is not possible for the A53 core (on which U-Boot is running) to read it
directly. For this purpose Marvell defined mbox API for sending OTP
commands between CM3 and A53 cores.
Implement these Marvell fuse reading mbox commands via U-Boot fuse API.
Banks 0-43 are used for accessing Security OTP (44 rows with 67 bits via 44
banks and words 0-2).
Note that of the 67 bits, the 3 upper bits are: 1 lock bit and 2
auxiliary bits (meant for testing during the manufacture of the SOC, as
I understand it).
Also note that the lock bit and the auxiliary bits are not readable
via Marvell commands.
With CZ.NIC's commands the lock bit is readable.
Write support is not implemented yet.
Signed-off-by: Pali Rohár <pali@kernel.org>
Reviewed-by: Marek Behún <marek.behun@nic.cz>
Reviewed-by: Stefan Roese <sr@denx.de>
Allow to specify input parameters, define all available mbox commands
supported by CZ.NIC's secure firmware and also Marvell's fuse.bin firmware
and fix parsing response from Marvell OTP commands.
Signed-off-by: Pali Rohár <pali@kernel.org>
Reviewed-by: Marek Behún <marek.behun@nic.cz>
Reviewed-by: Stefan Roese <sr@denx.de>
Generic A3720 mbox code is currently in Turris Mox specific board file
board/CZ.NIC/turris_mox/mox_sp.c. Move it to board independent arch file
arch/arm/mach-mvebu/armada3700/mbox.c.
Signed-off-by: Pali Rohár <pali@kernel.org>
Reviewed-by: Marek Behún <marek.behun@nic.cz>
Reviewed-by: Stefan Roese <sr@denx.de>
Allow to read OTP bits via U-Boot fuse command on all Armada 3720 boards.
Signed-off-by: Pali Rohár <pali@kernel.org>
Reviewed-by: Marek Behún <marek.behun@nic.cz>
Reviewed-by: Stefan Roese <sr@denx.de>
Implement reading NB and SB fuses of Armada 37xx SOC via U-Boot fuse API.
Banks 0-43 are reserved for accessing Security OTP (not implemented yet).
Bank 44 is used for accessing North Bridge OTP (69 bits via words 0-2).
Bank 45 is used for accessing South Bridge OTP (97 bits via words 0-3).
Write support is not implemented yet because it looks like that both North
and South Bridge OTPs are already burned in factory with some data. The
meaning of some bits of North Bridge is documented in WTMI source code.
The meaning of bits in South Bridge is unknown.
Signed-off-by: Pali Rohár <pali@kernel.org>
Reviewed-by: Marek Behún <marek.behun@nic.cz>
Reviewed-by: Stefan Roese <sr@denx.de>
When storing the UBoot Environment in for example EXT4,
the U-Boot build is broken for several reasons:
1. armada-385-turris-omnia-u-boot.dtsi will not allow
CONFIG_ENV_OFFSET and CONFIG_ENV_SIZE to be undefined
2. armada-37xx/board.c ft_board_setup function does not
exist if CONFIG_ENV_IS_IN_SPI_FLASH is not defined
This commit changes these files so that selecting a
different location for the environment is possible.
Signed-off-by: Rogier Stam <rogier@unrailed.org>
Reviewed-by: Pali Rohár <pali@kernel.org>
There are two tools for sending images over UART to Marvell SoCs: kwboot
and mrvl_uart.sh. kwboot received lot of new features and improvements in
last few months. There is no need to maintain two tools in U-Boot, so
remove old mrvl_uart.sh tool.
Signed-off-by: Pali Rohár <pali@kernel.org>
Reviewed-by: Marek Behún <marek.behun@nic.cz>
Reviewed-by: Marcel Ziswiler <marcel@ziswiler.com>
Tested-by: Marcel Ziswiler <marcel@ziswiler.com>
Reviewed-by: Tony Dinh <mibodhi@gmail.com>
- Two TI K3 updates, update SYS_MALLOC_F_LEN default to be 0x2000 and
move TI am33xx to use that as well, fix DT relocation with multiple
DRAM banks, and add a gpio read sub-command.
As explained in commit 4af2a33ee5 ("cmd: gpio: Make `gpio input`
return pin value again") the `gpio input` is used in scripts to obtain
the value of a pin, despite the fact that CMD_RET_FAILURE is
indistinguishable from a valid pin value.
To be able to detect failures and properly use the value of a GPIO in
scripts we introduce the `gpio read` command that sets the variable
`name` to the value of the pin. Return code of the `gpio read` command
can be used to check for CMD_RET_SUCCESS or CMD_RET_FAILURE.
CONFIG_CMD_GPIO_READ is used to enable the `gpio read` command.
Signed-off-by: Diego Rondini <diego.rondini@kynetics.com>
Allow device tree to provide ti,ddr-freq0 to be used as the initial DDR
frequency that is set for lpddr4 before initialization of the
controller. Make this optional and continue to use PLL bypass frequency
as is done currently if ti,ddr-freq0 is not provided.
Signed-off-by: Dave Gerlach <d-gerlach@ti.com>
The current implementation of boot_relocate_fdt() places DT at the
highest usable DRAM address, which is calculated as:
env_get_bootm_low() + env_get_bootm_mapsize()
which by default becomes gd->ram_base + gd->ram_size.
Systems like i.MX53 can have multiple DRAM banks with gap between them,
e.g. have DRAM at 0x70000000-0x8fffffff and 0xb0000000-0xcfffffff , so
for them the calculated highest DRAM address is 0xafffffff, which is
exactly in the gap and thus not usable.
Fix this by iterating over all DRAM banks and tracking the remaining
amount of the total mapping size obtained from env_get_bootm_mapsize().
Limit the maximum LMB area size to each bank, to avoid using nonexistent
DRAM.
Reviewed-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Marek Vasut <marex@denx.de>
Cc: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Simon Glass <sjg@chromium.org>
Cc: Tom Rini <trini@konsulko.com>
The k3-ddrss driver wants to configure the DDRSS_V2A_CTL_REG to reflect
the maximum possible SDRAM of 2 GB for AM64x (instead of the register's
default that says 8 GB, which the AM64x DDR controller wouldn't support).
The offset 0x20 was correct, but the register name DDRSS_V2A_R1_MAT_REG
was that of the next register at offset 0x24.
Signed-off-by: Dominic Rath <rath@ibv-augsburg.net>
