The NanoPi R6S is a SBC by FriendlyElec based on the Rockchip RK3588s.
It comes with 4GB or 8GB of RAM, a microSD card slot, 32GB eMMC storage,
one RTL8211F 1GbE and two RTL8125 2.5GbE Ethernet ports, one USB 2.0
Type-A and one USB 3.0 Type-A port, a HDMI port, a 12-pin GPIO FPC
connector, a fan connector, IR receiver as well as some buttons and LEDs.
Add initial support for this board using the upstream devicetree sources.
Kernel commit:
f1b11f43b3e9 ("arm64: dts: rockchip: Add support for NanoPi R6S")
Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
Signed-off-by: Sebastian Kropatsch <seb-dev@mail.de>
The NanoPi R6C is a SBC by FriendlyElec based on the Rockchip RK3588s.
It comes with 4GB or 8GB of RAM, a microSD card slot, optional 32GB eMMC
storage, one M.2 M-Key connector, one RTL8211F 1GbE and one RTL8125
2.5GbE Ethernet port, one USB 2.0 Type-A and one USB 3.0 Type-A port, a
HDMI port, a 30-pin GPIO header as well as multiple buttons and LEDs.
Add initial support for this board using the upstream devicetree sources.
Tested in U-Boot proper:
- Booting from eMMC works
- 1GbE Ethernet works using the eth_eqos driver (tested by ping)
- 2.5GbE Ethernet works using the eth_rtl8169 driver (tested by ping),
but the status LEDs on this specific port currently aren't working
- NVMe SSD in M.2 socket does get recognized (tested with `nvme scan`
followed by `nvme details`)
Kernel commit:
d5f1d7437451 ("arm64: dts: rockchip: Add support for NanoPi R6C")
Reviewed-by: Quentin Schulz <quentin.schulz@cherry.de>
Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
Signed-off-by: Sebastian Kropatsch <seb-dev@mail.de>
ROCK Pi E v3.0 uses DDR4 SDRAM instead of DDR3 SDRAM used in v1.2x.
prepare new rk3328-rock-pi-e-v3.dts in u-boot which just includes
upstream rk3328-rock-pi-e.dts.
defconfig still uses
CONFIG_DEFAULT_FDT_FILE="rockchip/rk3328-rock-pi-e.dtb"
because v3.0 and prior are compatible.
Suggested-by: Jonas Karlman <jonas@kwiboo.se>
Signed-off-by: FUKAUMI Naoki <naoki@radxa.com>
Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
No meaningful changes were made to this SoM since February 2021. Nobody
from Theobroma has booted anything recent on that product since July
2021 at the latest. The product isn't available to buy anymore and
disappeared from our website.
This product is therefore unmaintained and it would be disingenuous to
say the opposite, so drop support for RK3368 Lion.
If you're a user of Lion, feel free to revert this patch or contact our
sales/support department.
Signed-off-by: Quentin Schulz <quentin.schulz@cherry.de>
Acked-by: Heiko Stuebner <heiko@sntech.de>
Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
In commit 100f489f58 ("rockchip: rk3399: Fix loading FIT from SD-card
when booting from eMMC"), the spi1 bootph properties were mistakenly
removed meaning, so re-add them back to fix SPI-NOR flash not being
found in U-Boot pre-reloc as required for RK3399 Puma.
Fixes: 100f489f58 ("rockchip: rk3399: Fix loading FIT from SD-card when booting from eMMC")
Signed-off-by: Quentin Schulz <quentin.schulz@cherry.de>
Reviewed-by: Jonas Karlman <jonas@kwiboo.se>
Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
There are some sub-nodes under the grf DT nodes, so add bind callback
function in syscon_px30 driver to scan them recursively.
Fixes: e9ccb2f526 ("rockchip: add px30 architecture core")
Signed-off-by: Quentin Schulz <quentin.schulz@cherry.de>
Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
We don't set many options in the board Kconfig entry file but instead
use defconfigs, select in some cases on the target itself, or update the
"default" options of the main entries when needed. In this case we can
remove most of the board Kconfig entries and just add them to the
defconfig like other platforms.
Signed-off-by: Tom Rini <trini@konsulko.com>
Marek Mojík <marek.mojik@nic.cz> says:
Hello all,
this is a continuation of previous work by Pali to add support for the
Turris 1.x board. As the patches were based on u-boot v2022.04, a
nontrivial rebasing was needed.
Some notes:
- Some options that are in SD defconfig are disabled in NOR defconfig
because over the years u-boot grew and the old NOR defconfig will not
fit into NOR memory.
- SD boot with RAM larger than 2GB will only allocate 2GB of RAM (We
were not able to fix this yet)
Add support for CZ.NIC Turris 1.x routers.
CZ.NIC Turris 1.0 (RTRS01) and 1.1 (RTRS02) are open source routers, they
have dual-core PowerPC Freescale P2020 CPU and are based on reference
Freescale P2020RDB-PC-A board design.
Hardware design is fully open source, all firmware and hardware design
files are available at Turris project website:
https://docs.turris.cz/hw/turris-1x/turris-1x/https://project.turris.cz/en/hardware.html
The P2020 BootROM can load U-Boot either from NOR flash or from SD card.
We add the new defconfigs, turris_1x_nor_defconfig, which configures
U-Boot for building the NOR image, and turris_1x_sdcard_defconfig, which
configures U-Boot for building an image suitable for SD card.
The defconfig for NOR image is stripped-down a - many config options
enabled in SD defconfig are disabled for NOR defconfig. This is because
U-Boot grew non-trivially in the last two years and it would not fit
into the space allocated for U-Boot in the NOR memory. In the future we
may try to use LTO to reduce the size of the code and enable more
options.
The design of CZ.NIC Turris 1.x routers is based on Freescale P2020RDB-PC-A
board, so some code from boards/freescale/p1_p2_rdb_pc is used and linked
into Turris 1.x board code.
Turris 1.x code in this patch uses modern distroboot and can boot Linux
kernel from various locations, including NAND, SD card, USB flash disks,
NVMe disks or SATA disks (connected to extra SATA/SCSI PCIe controllers).
Via distroboot is implemented also rescue NOR boot for factory recovery,
triggered by reset button, like on other existing Turris routers.
SD boot with RAM larger than 2GB will only allocate 2GB of RAM (We were
not able to fix this yet)
[ Because various CONFIG_ macros were migrated to Kconfig since the last
time this worked on upstream U-Boot (in 2022), a non-trivial rebasing
was needed and some issues were solved. ]
Signed-off-by: Pali Rohár <pali@kernel.org>
Signed-off-by: Marek Mojík <marek.mojik@nic.cz>
Reviewed-by: Marek Behún <kabel@kernel.org>
Use the CONFIG_IS_ENABLED() macro when checking for DM_SERIAL so that
CFG_SYS_NS16550_CLK is not defined as get_serial_clock() in SPL if SPL
does not have DM_SERIAL enabled.
Signed-off-by: Marek Mojík <marek.mojik@nic.cz>
Reviewed-by: Marek Behún <kabel@kernel.org>
Use CONFIG_VAL() for SYS_MONITOR_BASE in start.S so that correct value
is used for SPL.
Signed-off-by: Marek Mojík <marek.mojik@nic.cz>
Reviewed-by: Marek Behún <kabel@kernel.org>
The find_law() function searches for LAW just by physical address. This
is unsuitable for cases with overlapping LAWs. Extend it to
find_law_by_addr_id(), which searches for LAW by physical address and
target id.
Add a static inline definition of the original find_law() into fsl_law.h
header.
Signed-off-by: Pali Rohár <pali@kernel.org>
Signed-off-by: Marek Mojík <marek.mojik@nic.cz>
Reviewed-by: Marek Behún <kabel@kernel.org>
This empty stub was originally added as one branch of an #ifdef in
commit 45a6d231b2 (bcm2835_wdt: support for the BCM2835/2836
watchdog). That incarnation of the rpi watchdog driver was later
removed in c7adc0b5f9 (watchdog: bcm2835_wdt: Remove unused BCM283x
watchdog driver and its references), but this now unused stub was left
behind. The later (re-)added rpi watchdog driver does not define a
hw_watchdog_disable() function, as that is properly integrated in the
watchdog framework.
Reviewed-by: Stefan Roese <sr@denx.de>
Signed-off-by: Rasmus Villemoes <rasmus.villemoes@prevas.dk>
Reviewed-by: Peter Robinson <pbrobinson@gmail.com>
This reverts commit 3304197272.
With the ability to generate this SMBIOS details autmotically the
small amount of details that this patch provided are generated
automatically so this is now obsolete so we can just drop it.
Signed-off-by: Peter Robinson <pbrobinson@gmail.com>
Acked-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
Acked-by: Matthias Brugger <mbrugger@suse.com>
- Add mvebu_espressobin_ultra-88f3720_defconfig (Benjamin)
- Update DTS for Thecus N2350 board (Tony)
- Add "old" Marvell DDR3 training for Armada 38x and Turris Omnia
(Marek)
- Misc turris_omnia changes (Marek)
Support old DDR3 training code on Turris Omnia, selectable via EEPROM
field.
Users experiencing DDR3 initialization failures or random crashes of the
operating system due to incorrect DDR3 configuration can select the old
DDR3 training implementation to fix those issues by setting the EEPROM
field "Use old DDR training":
eeprom update "Use old DDR training" 1
Signed-off-by: Marek Behún <kabel@kernel.org>
Add optional support for using old DDR3 training code from 2017.
The code lives in drivers/ddr/marvell/a38x/old/. To prevent symbol
clashing with new DDR3 training code, a special header which renames all
clashing symbols via macros is included and the symbols are prefixed
with 'old_'.
If old DDR3 training support is selected for a board, then the SPL
initialization code calls a new function
board_use_old_ddr3_training()
to check whether it should use old DDR3 training code. The default
weak implementation returns false, defaulting to new DDR3 training code.
Boards that wish to support this need to select the
ARMADA_38X_SUPPORT_OLD_DDR3_TRAINING
config option and implement the old version of DDR topology provider,
ddr3_get_topology_map().
Signed-off-by: Marek Behún <kabel@kernel.org>
Allow compiling with immutable debug settings:
- DEBUG_LEVEL is always set to DEBUG_LEVEL_ERROR
- register dumps are disabled
This can save around 10 KiB of space in the resulting binary, which is a
lot in U-Boot SPL.
Signed-off-by: Marek Behún <kabel@kernel.org>
The CONFIG_ENV_OFFSET is undefined if boot device is UART
(CONFIG_MVEBU_SPL_BOOT_DEVICE_UART), or envs are not stored on flash
(CONFIG_ENV_IS_NOWHERE). Check for CONFIG_ENV_IS_IN_SPI_FLASH as the first
condition to determine whether env_sf_get_env_addr() should be provided.
Signed-off-by: Tony Dinh <mibodhi@gmail.com>
Since commit ecb1c37a7b ("clk: imx8mp: Add EQoS MAC clock"),
the clocks for the DWMAC driver can be configured, and removing
them breaks operation.
Fixes: ecb1c37a7b ("clk: imx8mp: Add EQoS MAC clock")
Suggested-by: Tim Harvey <tharvey@gateworks.com>
Signed-off-by: Adam Ford <aford173@gmail.com>
Reviewed-by: Peng Fan <peng.fan@nxp.com>
The production DH i.MX8MP DHCOM SoM rev.200 uses updated PHY MDIO addresses
for the Fast ethernet PHYs. Update the base SoM DT and SoM rev.100 backward
compatibility DTO to cater for this change.
Since the MDIO address adjustment is now also in the rev.100 SoM DTO, not
only in the rev.100 PDK3 DTO, update Makefile accordingly as well, else the
DTC would complain about the DTO overriding the 'reg' property without also
updating the node unit-address, which is not doable without duplicating the
entire PHY node in the DTO, which leads to large amount of duplication with
no gain.
Fixes: 9de599ec3d ("arm64: dts: imx8mp: Update i.MX8MP DHCOM SoM DT to production rev.200")
Signed-off-by: Marek Vasut <marex@denx.de>
Various minor fixes and improvements:
* Fix Qualcomm SPMI v5 support
* Move default environment to a file
* Add support for special pins (e.g ufs/mmc reset/data pins)
* IPQ moves to OF_UPSTREAM and receives some cleanup and MAINTAINERS
changes
* Add a reset driver for devices without PSCI
* msm8916 USB clock improvements for mobile devices
In order to help setup pin configuration for special pins (UFS, SDCard),
introduce the msm_special_pin_data struct largely inspired from the
Linux conterpart but with only U-Boot required fields.
This struct is added to the pins_data to allow specifying the special
pins data for each SoC.
Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org>
Reviewed-by: Sumit Garg <sumit.garg@linaro.org>
Now that drivers are compatible enough with the upstream DTS, there is no
reason to not use the upstream DTS, so imply OF_UPSTREAM by default.
Signed-off-by: Robert Marko <robert.marko@sartura.hr>
Acked-by: Caleb Connolly <caleb.connolly@linaro.org>
Signed-off-by: Caleb Connolly <caleb.connolly@linaro.org>
The Lenovo IdeaPad Yoga 11 is a hybrid laptop/tablet Windows RT-based
computer released in late 2012. The device uses a 1.3 GHz quad-core
Nvidia Tegra 3 chipset with 2 GB of RAM, features a 11.6 inch 1366x768
screen and 32/64 GB of internal memory that can be supplemented with
a microSDXC card slot, full size SD card slot and 2 full size USB 2.0
ports.
Tested-by: Jethro Bull <jethrob@hotmail.com>
Signed-off-by: Jonas Schwöbel <jonasschwoebel@yahoo.de>
Signed-off-by: Svyatoslav Ryhel <clamor95@gmail.com>
Surface RT is a hybrid tablet computer developed and manufactured
by Microsoft and shipped with Windows RT. The tablet uses a 1.3 GHz
quad-core Nvidia Tegra 3 chipset with 2 GB of RAM, features 10.8
inch 1366x768 screen and 32/64 GB of internal memory that can be
supplemented with a microSDXC card giving up to 200 GB of
additional storage.
Tested-by: Jethro Bull <jethrob@hotmail.com>
Signed-off-by: Jonas Schwöbel <jonasschwoebel@yahoo.de>
Signed-off-by: Svyatoslav Ryhel <clamor95@gmail.com>
WEXLER Tab 7t is a mini tablet computer developed by WEXLER that
runs the Android operating system. The device features a 7.0-inch
(180 mm) HD display, an Nvidia Tegra 3 quad-core chip, 1 GB of RAM,
8, 16 or 32 GB of storage that can be supplemented with a microSDXC
card giving up to 64 GB of additional storage and a full size USB
port.
Tested-by: Maksim Kurnosenko <asusx2@mail.ru>
Signed-off-by: Svyatoslav Ryhel <clamor95@gmail.com>
The Asus Eee Pad Transformer family are 2-in-1 detachable/slider
tablets developed by Asus that run the Android operating system.
The Eee Pad Transformers feature a 10.1-inch (260 mm) display,
an Nvidia Tegra 2 dual-core chip, 1 GB of RAM, and 16/32 GB of storage.
Transformers board derives from Nvidia Ventana development board.
This patch brings support for all 3 known T20 Transformers:
- Asus Eee Pad Transformer TF101
- Asus Eee Pad Transformer TF101G
- Asus Eee Pad Slider SL101
Tested-by: Robert Eckelmann <longnoserob@gmail.com> # ASUS TF101
Tested-by: Antoni Aloy Torrens <aaloytorrens@gmail.com> # ASUS TF101
Signed-off-by: Svyatoslav Ryhel <clamor95@gmail.com>
Jiaxun Yang <jiaxun.yang@flygoat.com> says:
Hi all,
This series enabled qemu-xtensa board.
For dc232b CPU it needs to be built with toolchain[1].
This is a side product of me investigating architectures
physical address != virtual address in U-Boot. Now we can
get it covered under CI and regular tests.
VirtIO devices are not working as expected, due to U-Boot's
assumption on VA == PA everywhere, I'm going to get this fixed
later.
My Xtensa knowledge is pretty limited, Xtensa people please
feel free to point out if I got anything wrong.
Thanks
[1]: https://github.com/foss-xtensa/toolchain/releases/download/2020.07/x86_64-2020.07-xtensa-dc232b-elf.tar.gz
For PTP_MMU our physical address is not directly mapped
into virtual address space, we need to access physical
memory from those fixed map segments.
Implement phys_to_virt and virt_to_phys hook to reflect
this setting.
Tested-by: Max Filippov <jcmvbkbc@gmail.com>
Signed-off-by: Jiaxun Yang <jiaxun.yang@flygoat.com>
So U-Boot is using _end symbol to detect location of devicetree
appended at the end of the ROM.
It needs to be calculated based on end of .data load address,
as in our lds .current address is address in RAM.
Tested-by: Max Filippov <jcmvbkbc@gmail.com>
Signed-off-by: Jiaxun Yang <jiaxun.yang@flygoat.com>
This binary does not prevent the system from booting. Mark it optional
so that U-Boot can be built without it.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Andre Przywara <andre.przywara@arm.com>
Since commit 0dba45864b ("arm: Init the debug UART") the debug UART is
set up in _main() before early_system_init() is called.
Add a suitable board_debug_uart_init() function to set up the UART in
SPL.
Signed-off-by: Simon Glass <sjg@chromium.org>
Tom Rini <trini@konsulko.com> says:
Prior to this series we had some de-facto required cache functions that
were either unimplemented on some architectures or differently named.
This would lead in some cases to having multiple "weak" functions
available as well. Rework things so that an architecture must provide
these functions and it is up to that architecture if a "weak" default
function makes sense, or not.
Implement a weak default version of flush_dcache_all which is based on
the ARM default, which is to flush the entire range via
flush_dcache_range(...).
Acked-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
Signed-off-by: Tom Rini <trini@konsulko.com>
Implement a weak default version of flush_dcache_all which is based on
the ARM default, which is to flush the entire range via
flush_dcache_range(...).
Acked-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
Signed-off-by: Tom Rini <trini@konsulko.com>
The implementation of icache_invalid appears to be doing what other
architectures call invalidate_icache_all so rename to match.
Reviewed-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
Signed-off-by: Tom Rini <trini@konsulko.com>
