| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
Manorit Chawdhry <m-chawdhry@ti.com> says:
fdtfile wasn't being populated in these boards in legacy boot using
bootcmd_ti_mmc, migrate these platforms to ti_set_fdt_env.
|
|
stdboot and legacy boot depend on fdtfile. Since findfdt is getting
deprecated, move the rest of k3 platforms dependent on findfdt to
ti_set_fdt_env.
Populate fdtfile by calling ti_set_fdt_env in board files.
Signed-off-by: Manorit Chawdhry <m-chawdhry@ti.com>
|
|
|
|
By moving the earlycon definition into a dedicated variable, it's
easier to change these values in case the kernel should print on
a different serial interface.
Signed-off-by: Daniel Schultz <d.schultz@phytec.de>
|
|
By moving the earlycon definition into a dedicated variable, it's
easier to change these values in case the kernel should print on
a different serial interface.
Signed-off-by: Daniel Schultz <d.schultz@phytec.de>
|
|
Nothing really major here, some rework of the SPL PMIC drivers, adding
support for the AXP717 on the way, which is showing up on newer boards
now, most prominently some Anbernic handheld gaming devices. The rest
is enabling Ethernet and SPI boot on the Allwinner V3s SoC, plus two
fixes. This also updates the "traditional U-Boot" DTs to that of kernel
v6.9. I will look into upgrading some SoCs to dts/upstream in the
coming cycle, though this will not cover all SoCs for now, as we carry
some non-mainline fix to improve compatibility with older kernels. Will
see how it goes, but for now we stick with the "old way".
The branch survived the gitlab CI run, and Linux boot testing on some
selected boards.
|
|
On boards using the AXP717 PMIC, the DRAM rail is often not setup
correctly at reset time, so we have to program the PMIC very early in
the SPL, before running the DRAM initialisation.
Using the new generic AXP SPL driver, add the Kconfig options and
platform bits needed to support an AXP717 PMIC chip in I2C mode.
This allows to set up the correct voltage for the DRAM chips and the
CPU cores.
Signed-off-by: Andre Przywara <andre.przywara@arm.com>
Tested-by: Ryan Walklin <ryan@testtoast.com>
|
|
- mvebu: Migrate to upstream DT for Synology DS116 (Armada 385) board
(Tony)
- mvebu: Enable bootstd and other modernization for Synology DS414
(Armada XP) board (Tony)
|
|
(Armada XP) board
- Switch to standard boot (in include/configs/ds414.h and
configs/ds414_defconfig)
- Implement board_late_init() to ensure successful enumeration
of USB3 devices
- Remove unnecessary checkboard()
- Updated IDENT_STRING to indicate this u-boot supports both Synology
DS414 and DS214+ boards
- Add SYS_THUMB_BUILD to reduce binary size
- Add NET_RANDOM_ETHADDR
- Add CONFIG_LBA48 and CONFIG_SYS_64BIT_LBA to support >2TB HDD/SDD
Signed-off-by: Tony Dinh <mibodhi@gmail.com>
Reviewed-by: Stefan Roese <sr@denx.de>
Acked-by: Phil Sutter <phil@nwl.cc>
|
|
bananapi_m64_defconfig with CONFIG_ENV_IS_NOWHERE results in:
board/sunxi/board.c: In function 'mmc_get_env_dev':
board/sunxi/board.c:535:24: error:
'CONFIG_SYS_MMC_ENV_DEV' undeclared (first use in this function)
535 | return CONFIG_SYS_MMC_ENV_DEV;
| ^~~~~~~~~~~~~~~~~~~~~~
Check if CONFIG_SYS_MMC_ENV_DEV is defined.
Fixes: 1011ebc72bda ("sunxi: Select environment MMC based on boot device")
Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
|
|
The EFI Capsule ESL file (EFI Signature List File) used for authentication
is a binary generated from the EFI Capsule public key certificate. Instead
of including it in the source repo, automatically generate it from the
certificate file during the build process.
Currently, sandbox is the only device using this, so removed its ESL file
and set the (new) CONFIG_EFI_CAPSULE_CRT_FILE config to point to its public
key certificate.
Signed-off-by: Jonathan Humphreys <j-humphreys@ti.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>
|
|
p1_p2_rdb_pc_fix_fdt_model() for fixing DT model string
This allows boards to fixup / overwrite DT model string when booting OS.
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>
|
|
https://source.denx.de/u-boot/custodians/u-boot-raspberrypi
Updates for RPi for 2024.10:
- board: rpi: remove leftover CONFIG_HW_WATCHDOG block
- arm: bcm283x: remove unused empty hw_watchdog_disable
- board: raspberrypi: Fix format specifier for printing rev_scheme
- Revert "arm: dts: bcm283x: Add minimal smbios information"
|
|
This was added in commit 45a6d231b2f (bcm2835_wdt: support for the
BCM2835/2836 watchdog), which did do 'select HW_WATCHDOG'. That
incarnation of the watchdog driver later got removed in
c7adc0b5f98 (watchdog: bcm2835_wdt: Remove unused BCM283x watchdog
driver and its references), but this block was left behind.
Another rpi watchdog driver has since been added, but that does not
select HW_WATCHDOG, so this remains dead and unused. Remove it.
Reviewed-by: Stefan Roese <sr@denx.de>
Signed-off-by: Rasmus Villemoes <rasmus.villemoes@prevas.dk>
Reviewed-by: Peter Robinson <pbrobinson@gmail.com>
|
|
rev_scheme is an unsigned integer and must not be printed
as a signed integer.
Signed-off-by: Francois Berder <fberder@outlook.fr>
Reviewed-by: Peter Robinson <pbrobinson@gmail.com>
|
|
Add and use the correct number of ddr phy registers to update the
corresponding settings.
Fixes: cbf5c99ef317 ("board: phytec: common: Introduce a method to inject DDR timings deltas")
Signed-off-by: Dominik Haller <d.haller@phytec.de>
Reviewed-by: Wadim Egorov <w.egorov@phytec.de>
|
|
- 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>
|
|
Some Turris Omnia boards experience memory issues, and by
experimentation we found that some of these issues can be solved by
slowing DDR speed.
Add a new field in the extended EEPROM information structure, ddr_speed.
Support several values in this field (for now 1066F, 1333H, and the
default, 1600K) and use it to overwrite the DDR topology parameters
used by the DDR training algorithm.
Signed-off-by: Marek Behún <kabel@kernel.org>
|
|
Extend the Omnia EEPROM information structure in preparation for more
variables to be stored there.
Signed-off-by: Marek Behún <kabel@kernel.org>
|
|
Implement Turris Omnia EEPROM layout for the 'eeprom' command.
When the 'eeprom' command (with layout support) is enabled, we can now
use the 'eeprom print' and 'eeprom update' commands, for example:
=> eeprom print
Magic constant 34a04103
RAM size in GB 2
Wi-Fi Region
CRC32 checksum cecbc2a1
Signed-off-by: Marek Behún <kabel@kernel.org>
|
|
For board revisions where the WAN ethernet PHY reset GPIO is controllable
via MCU we currently insert a phy-reset-gpios property into the ethernet
controller node. The mvneta driver parses this property and uses the
GPIO to reset the PHY.
But this phy-reset-gpios property is not a valid DT binding in upstream
kernel. Instead, a reset-gpios property should be inserted into the
ethernet PHY node. This correct DT binding is supported by the DM ETH PHY
U-Boot driver.
Insert the reset-gpios property into the WAN PHY node instead the
phy-reset-gpios property in WAN ETH node so that Linux will correctly use
the reset GPIO.
Enable the CONFIG_DM_ETH_PHY config option so that U-Boot will also use
the correct DT property.
Note: currently there are 4 ethernet controller drivers parsing the
wrong DT property: dwc_eth_qos, fex_mxc, mvneta and mvpp2. We should
convert all relevant device-trees to use reset-gpios so that we can get
rid of these drivers parsing this property.
Fixes: 1da53ae26afc ("arm: mvebu: turris_omnia: Add support for design with SW reset signals")
Signed-off-by: Marek Behún <kabel@kernel.org>
|
|
Add support for a Marvell Armada 3720 device variant
Signed-off-by: Benjamin Schneider <ben@bens.haus>
|
|
The older i.MX8M Mini Verdin SoMs may came with 20 MHz SPI CAN controller
oscillator, the newer SoMs always use 40 MHz oscillator. Handle both by
overriding the oscillator frequency just before booting the kernel.
These are the known variants with 20 MHz oscillator:
- 0055, V1.1A, V1.1B, V1.1C and V1.1D, use a 20MHz oscillator
- 0059, V1.1A and V1.1B, use a 20MHz oscillator
Signed-off-by: Marek Vasut <marex@denx.de>
Reviewed-by: Francesco Dolcini <francesco.dolcini@toradex.com>
|
|
https://source.denx.de/u-boot/custodians/u-boot-snapdragon
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
|
|
Make use of CONFIG_DEFAULT_ENV_FILE and move the default qcom
environment to a file under board/qualcomm.
This is much cleaner and means we don't need to recompile on changing
the environment.
Reviewed-by: Neil Armstrong <neil.armstrong@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
|
|
Introduce the new board, define every bits.
Tested-by: Max Filippov <jcmvbkbc@gmail.com>
Signed-off-by: Jiaxun Yang <jiaxun.yang@flygoat.com>
|
|
This is a board level stuff.
Tested-by: Max Filippov <jcmvbkbc@gmail.com>
Signed-off-by: Jiaxun Yang <jiaxun.yang@flygoat.com>
|
|
|
|
Tim Harvey <tharvey@gateworks.com> says:
This series will automatically add /chosen/kaslr-seed to the dt if
DM_RNG is enabled
during the boot process.
If RANDOMIZE_BASE is enabled in the Linux kernel instructing it to
randomize the virtual address at which the kernel image is loaded, it
expects entropy to be provided by the bootloader by populating
/chosen/kaslr-seed with a 64-bit value from source of entropy at boot.
If we have DM_RNG enabled populate this value automatically when
fdt_chosen is called. We skip this if ARMV8_SEC_FIRMWARE_SUPPORT
is enabled as its implementation uses a different source of entropy
that is not yet implemented as DM_RNG. We also skip this if
MEASURED_BOOT is enabled as in that case any modifications to the
dt will cause measured boot to fail (although there are many other
places the dt is altered).
As this fdt node is added elsewhere create a library function and
use it to deduplicate code. We will provide a parameter to overwrite
the node if present.
For our automatic injection, we will use the first rng device and
not overwrite if already present with a non-zero value (which may
have been populated by an earlier boot stage). This way if a board
specific ft_board_setup() function wants to customize this behavior
it can call fdt_kaslrseed with a rng device index of its choosing and
set overwrite true.
Note that the kalsrseed command (CMD_KASLRSEED) is likely pointless now
but left in place in case boot scripts exist that rely on this command
existing and returning success. An informational message is printed to
alert users of this command that it is likely no longer needed.
Note that the Kernel's EFI STUB only relies on EFI_RNG_PROTOCOL for
randomization and completely ignores the kaslr-seed for its own
randomness needs (i.e the randomization of the physical placement of
the kernel). It gets weeded out from the DTB that gets handed over via
efi_install_fdt() as it would also mess up the measured boot DTB TPM
measurements as well.
|
|
Use the fdt_kaslrseed function to deduplicate code doing the same thing.
Note that the kalsrseed command (CMD_KASLRSEED) is likely pointless now
but left in place in case boot scripts exist that rely on this command
existing and returning success. An informational message is printed to
alert users of this command that it is likely no longer needed.
Note that the Kernel's EFI STUB only relies on EFI_RNG_PROTOCOL for
randomization and completely ignores the kaslr-seed for its own
randomness needs (i.e the randomization of the physical placement of
the kernel). It gets weeded out from the DTB that gets handed over via
efi_install_fdt() as it would also mess up the measured boot DTB TPM
measurements as well.
Signed-off-by: Tim Harvey <tharvey@gateworks.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Cc: Michal Simek <michal.simek@amd.com>
Cc: Andy Yan <andy.yan@rock-chips.com>
Cc: Akash Gajjar <gajjar04akash@gmail.com>
Cc: Ilias Apalodimas <ilias.apalodimas@linaro.org>
Cc: Simon Glass <sjg@chromium.org>
Cc: Patrick Delaunay <patrick.delaunay@foss.st.com>
Cc: Patrice Chotard <patrice.chotard@foss.st.com>
Cc: Devarsh Thakkar <devarsht@ti.com>
Cc: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Hugo Villeneuve <hvilleneuve@dimonoff.com>
Cc: Marek Vasut <marex@denx.de>
Cc: Tom Rini <trini@konsulko.com>
Cc: Chris Morgan <macromorgan@hotmail.com>
Acked-by: Michal Simek <michal.simek@amd.com>
|
|
Now that am335x_evm boots OK on the Beaglebone black, drop the latter
and update the docs to cover the change.
Also add a few updates about 'make fit' and drop the note about the
security review, as U-Boot's verified boot has had quite extensive
review now.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>
|
|
Add better logging for power init so that CONFIG_LOG_ERROR_RETURN can
be enabled.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Quentin Schulz <quentin.schulz@cherry.de>
|
|
Padmarao is leaving Microchip soon, and suggested that I should take
over maintaining the Icicle in U-Boot in his stead.
Suggested-by: Padmarao Begari <padmarao.begari@microchip.com>
Signed-off-by: Conor Dooley <conor.dooley@microchip.com>
|
|
After adding the U_BOOT_LONGHELP macro some new commands came in still
that were not making use if it. Switch these cases over and in a few
places add missing newlines as well.
Signed-off-by: Tom Rini <trini@konsulko.com>
|
|
The Kernel Image and DTB files are supposed to be picked from the rootfs
of the SD Card, this fails in legacy boot flow because bootpart is set
to 1:1. Fix it.
Fixes: a200f428b5b21 ("board: ti: am62x: Add am62x_beagleplay_* defconfigs and env file")
Reviewed-by: Nishanth Menon <nm@ti.com>
Acked-by: Chirag Shilwant <c-shilwant@ti.com>
Signed-off-by: Dhruva Gole <d-gole@ti.com>
|
|
Unfortunately when enabling FDT fixups for the AM62x family of SoCs and
moving TF-A to the bottom of RAM we missed the BeaglePlay. This is
causing Linux's memory allocator to clobber TF-A and break its boot.
Enable OF_SYSTEM_SETUP to fixup the kernel's FDT to inform it of the
actual location of the firmware
CC: Andrew Davis <afd@ti.com>
CC: Nishanth Menon <nm@ti.com>
CC: Robert Nelson <robertcnelson@gmail.com>
Reported-by: Dhruva Gole <d-gole@ti.com>
Signed-off-by: Bryan Brattlof <bb@ti.com>
Acked-by: Andrew Davis <afd@ti.com>
Tested-by: Robert Nelson <robertcnelson@gmail.com>
Reviewed-by: Nishanth Menon <nm@ti.com>
Acked-by: Chirag Shilwant <c-shilwant@ti.com>
Tested-by: Dhruva Gole <d-gole@ti.com>
|
|
Prepare v2024.07-rc5
|
|
With DM enabled, there is no need for board code to initialize
the Ethernet interfaces.
Specifically board_interface_eth_init will handle the configuration of
GPR1.
Signed-off-by: Tim Harvey <tharvey@gateworks.com>
|
|
Due to supply chain issues Venice boards use either a DP83867 or a
GPY111 RGMII PHY. We already print an identifier for the DP83867 so add
one for the GPY111 to better identify what PHY is on a board:
Example:
Net: GPY111 eth0: ethernet@30be0000 [PRIME]
Net: DP83867 eth0: ethernet@30be0000 [PRIME]
Signed-off-by: Tim Harvey <tharvey@gateworks.com>
|
|
Extensive testing has shown that at higher temperatures operating
without a GSC backup battery, the GSC needs a small delay after
releasing the I2C SDA/SCL pins before it is ready to handle I2C
requests.
Add a delay to avoid errors such as:
wait_for_sr_state: Arbitration lost sr=93 cr=80 state=2020
i2c_init_transfer: failed for chip 0x20 retry=0
Signed-off-by: Tim Harvey <tharvey@gateworks.com>
|
|
The Gateworks System Controller (GSC) has a voltage supervisor which is
disabled by default. On older boards we want to maintian this but on
newer boards we wish to enable the voltage supervisor.
The Gateworks System Controller (GSC) can disable the board primary
power supply by driving a pin to a FET high. On older board models
the leakage of the GSC may exceed the leakage of the FET causing this
signal slowly rise when the GSC battery is low and the board is in a
powered down state resulting in the board being kept in a disabled
state.
Newer boards have a hardware fix to avoid this leakage and thus should
enable the voltage supervisor.
Signed-off-by: Tim Harvey <tharvey@gateworks.com>
|
