Skip to content
Snippets Groups Projects
Select Git revision
  • master default
  • clk_doc
  • next
  • spl_load
  • nand_test
  • spl_test_load
  • ll_entry_fix
  • malloc_init
  • WIP/2022-03-30
  • WIP/2022-02-25
  • clk-2024.04-rc2
  • clk-2024.01-rc5
  • clk-2024.01-next
  • clk-2024.01-rc2
  • clk-2023.04-rc1
  • clk-2023.04
  • clk-2023.01
  • clk-2022.04-next
  • clk-2022.04-rc2
  • clk-2022.01-rc3
  • u-boot-clk-24Aug2020
  • u-boot-clk-26Jan2020
  • u-boot-clk-23Oct2019
  • ccf-pr-22.08
24 results
Search by author
  • Any Author
  • Lukasz Majewski Lukasz Majewski lukma
  • Tom Rini Tom Rini trini
2 authors
  1. Mar 18, 2022
    • Leonidas-Panagiotis Papadakos's avatar
      rockchip: rk3328: enable USB mass storage on Renegade · 5f4cc274
      Leonidas-Panagiotis Papadakos authored and Kever Yang's avatar Kever Yang committed 
      
This is very useful to access the LibreComputer eMMC as removable
storage from a PC (e.g. like so `ums 0 mmc 0`). It has been tested as
working on my Renegade board.

Signed-off-by: Leonidas P. Papadakos <papadakospan at gmail.com>
Reviewed-by: Kever Yang's avatarKever Yang <kever.yang@rock-chips.com>
      5f4cc274
    • Marty E. Plummer's avatar
      rockchip: rk3399: Add support for chromebook_kevin · 6d36e92d
      Marty E. Plummer authored and Kever Yang's avatar Kever Yang committed 
      
Add support for Kevin, an RK3399-based convertible chromebook that is
very similar to Bob. This patch is mostly based on existing support for
Bob, with only minor changes for Kevin-specific things.

Unlike other Gru boards, coreboot sets Kevin's center logic to 925 mV,
so adjust it here in the dts as well. The rk3399-gru-kevin devicetree
has an unknown event code reference which has to be defined, set it
to the Linux counterpart. The new defconfig is copied from Bob with the
diffconfig:

     DEFAULT_DEVICE_TREE "rk3399-gru-bob" -> "rk3399-gru-kevin"
     DEFAULT_FDT_FILE "rockchip/rk3399-gru-bob.dtb" -> "rockchip/rk3399-gru-kevin.dtb"
     VIDEO_ROCKCHIP_MAX_XRES 1280 -> 2400
     VIDEO_ROCKCHIP_MAX_YRES 800 -> 1600
    +TARGET_CHROMEBOOK_KEVIN y

With this Kevin can boot from SPI flash to a usable U-Boot prompt on the
display with the keyboard working, but cannot boot into Linux for
unknown reasons.

eMMC starts in a working state but fails to re-init, microSD card works
but at a lower-than-expected speed, USB works but causes a hang on
de-init. There are known workarounds to solve eMMC and USB issues.

Cc: Marty E. Plummer <hanetzer@startmail.com>
Cc: Simon Glass <sjg@chromium.org>
[Alper: commit message, resync config with Bob, update MAINTAINERS,
        add to Rockchip doc, add Kconfig help message, set regulator]
Co-developed-by: default avatarAlper Nebi Yasak <alpernebiyasak@gmail.com>
Signed-off-by: default avatarAlper Nebi Yasak <alpernebiyasak@gmail.com>
Reviewed-by: Kever Yang's avatarKever Yang <kever.yang@rock-chips.com>
Reviewed-by: Simon Glass's avatarSimon Glass <sjg@chromium.org>
Tested-by: Simon Glass's avatarSimon Glass <sjg@chromium.org>
      6d36e92d
    • Alper Nebi Yasak's avatar
      rockchip: bob: Enable more configs · e4015661
      Alper Nebi Yasak authored and Kever Yang's avatar Kever Yang committed 
      
This patch enables some configs that should be working on the Bob board,
based on what is observed to work on the Kevin board.

The Bob board uses an Embedded DisplayPort panel compatible with the
simple panel and Rockchip eDP drivers. Its backlight is controlled by
the Chromium OS Embedded Controller Pulse Width Modulator. Enable these
for the board.

Also set VIDEO_ROCKCHIP_MAX_{XRES,YRES} to 1280x800, the resolution of
its panel. This had to be done for the Kevin board, but it's untested if
this is actually necessary for Bob.

The Rockchip video driver needs to assert/deassert some resets, so also
enable the reset controller. RESET_ROCKCHIP defaults to y for this board
when DM_RESET=y, so it's enough to set that.

The Bob board has two USB 3.0 Type-C ports and one USB 2.0 Type-A port
on its right side. Enable the configs relevant to USB devices so these
can be used. This is despite a known issue with RK3399 boards where USB
de-init causes a hang, as there is a known workaround.

Some other rk3399-based devices enable support for the SoC's random
number generator in commit a475bef5 ("configs: rk3399: enable rng on
firefly/rock960/rockpro64"), as it can provide a KASLR seed when booting
using UEFI. Enable it for Bob as well.

The default misc_init_r() for Rockchip boards sets cpuid and ethernet
MAC address based on e-fuse block. A previous patch extends this on Gru
boards to set registers related to SoC IO domains as is necessary on
these boards. Enable this function and configs for it on Bob.

The microSD card slot on this board (and others based on Gru) is
connected to a GPIO controlled regulator (ppvar-sd-card-io), which must
be operable by U-Boot. Enable the relevant config option to allow this.

Bob boards also use the Winbond W25Q64DW SPI flash chip, enable support
for Winbond SPI flash chips in the board config so U-Boot can boot with
this chip.

Signed-off-by: default avatarAlper Nebi Yasak <alpernebiyasak@gmail.com>
Reviewed-by: Kever Yang's avatarKever Yang <kever.yang@rock-chips.com>
Reviewed-by: Simon Glass's avatarSimon Glass <sjg@chromium.org>
Tested-by: Simon Glass's avatarSimon Glass <sjg@chromium.org>
      e4015661
  3. Mar 15, 2022
    • Marek Vasut's avatar
      ARM: dts: stm32: Add DFU support for DHCOM recovery · 19fbe102
      Marek Vasut authored and Patrice Chotard's avatar Patrice Chotard committed 
      
This patch configures U-Boot SPL for DHCOM SoM to permit DFU upload of
SPL and subsequent u-boot.itb for recovery or commissioning purposes.

The DFU usage procedure is identical to STM32MP1 DHCOR SoM, see commit
3919aa17 ("ARM: dts: stm32: Add DFU support for DHCOR recovery") ,
except for switching the SoM into DFU mode. By default, the DHCOM SoM
has no dedicated mechanism for setting BOOTn straps into UART/USB mode,
therefore to enter DFU mode, the SoC must fail to boot from boot media
which can be selected by the BOOTn strap override mechanism first and
then fall back to DFU mode.

In case of a SoM with pre-populated BOOTn strap override button, power
the system off, remove microSD card (if applicable), hold down the BOOTn
strap override button located between eMMC and SoM edge connector, power
on the SoM. The SoC will fail to boot from SD card and fall back into
DFU mode.

Signed-off-by: default avatarMarek Vasut <marex@denx.de>
Cc: Patrice Chotard <patrice.chotard@foss.st.com>
Cc: Patrick Delaunay <patrick.delaunay@foss.st.com>
Reviewed-by: Patrice Chotard's avatarPatrice Chotard <patrice.chotard@foss.st.com>
      19fbe102
  5. Mar 14, 2022
  7. Mar 10, 2022
    • André Przywara's avatar
      sunxi: boards: Enable SPI flash support in U-Boot proper · 280294c5
      André Przywara authored and Jagan Teki's avatar Jagan Teki committed 
      
Some sunxi boards ship with SPI flash, which allows booting through the
BootROM. We cover this functionality by a separate SPL "mini" driver.
Separately we have a proper DM_SPI driver for U-Boot proper, which
provides access to the SPI flash through the "sf" command. That allows
to update the firmware on the SPI flash, also to store the environment
there.

However only very few boards actually enable support for U-Boot proper,
even though that would work and the SPL part is configured.

Use the cleaned up configuration scheme to enable SPI flash on those
boards which mention a SPI flash in their .dts, or which use the SPL SPI
support.

Out of the box this would enable storing the environment on the SPI
flash, and allows people to read or write the flash from U-Boot, for
instance to update the SPI flash when booted via an SD card.

For this to actually work there must be a "spi0" alias in the DT, which
most boards are missing. But this should be addressed separately.

Signed-off-by: default avatarAndre Przywara <andre.przywara@arm.com>
Reviewed-by: default avatarJagan Teki <jagan@amarulasolutions.com>
      280294c5
    • André Przywara's avatar
      sunxi: Kconfig: Fix up SPI configuration · 81a46c15
      André Przywara authored and Jagan Teki's avatar Jagan Teki committed 
      
Commit 7945caf2 ("arm: sunxi: Enable SPI/SPI-FLASH support for A64")
selected CONFIG_SPI by default on all Allwinner A64 boards, even though
only 4 out of the 14 A64 boards have a SPI flash chip. All other SoCs
had to manually select DM_SPI and friends, even though they are a
platform property (the sunxi SPI driver is DM_SPI only).

Clean this up to allow easy selection of SPI flash support in U-Boot
proper, by selecting DM_SPI and DM_SPI_FLASH *if* CONFIG_SPI is
selected, for *all* Allwinner SoCs. This simplifies the defconfig for
two Libretech boards already.

Also remove the forced CONFIG_SPI from the A64 Kconfig, instead let the
four boards which allow SPI booting select this explicitly.

Any board wishing to support SPI flash in U-Boot proper now just defines
CONFIG_SPI and CONFIG_SPI_FLASH_<vendor> in its defconfig, Kconfig takes
care of the rest.

Signed-off-by: default avatarAndre Przywara <andre.przywara@arm.com>
Reviewed-by: default avatarJagan Teki <jagan@amarulasolutions.com>
      81a46c15
  9. Mar 09, 2022
  11. Mar 04, 2022
  13. Mar 03, 2022
  15. Feb 28, 2022
    • Linus Walleij's avatar
      board: stemmy: Detect board variants and patch DTB · c2aed9cf
      Linus Walleij authored and Tom Rini's avatar Tom Rini committed 
      
This patch scans the cmdline from the Samsung SBL (second stage
bootloader) and stores the parameters board_id=N and lcdtype=N
in order to augment the DTB for different board and LCD types.

We then add a custom ft_board_setup() callback that will inspect
the DTB and patch it using the stored LCD type. At this point
we know which product we are dealing with, so using the passed
board_id we can also print the board variant for diagnostics.

We patch the Codina, Skomer and Kyle DTBs to use the right
LCD type as passed in lcdtype from the SBL.

This also creates an infrastructure for handling any other
Samsung U8500 board variants that may need a slightly augmented
DTB.

Cc: Markuss Broks <markuss.broks@gmail.com>
Cc: Stephan Gerhold <stephan@gerhold.net>
Signed-off-by: default avatarLinus Walleij <linus.walleij@linaro.org>
      c2aed9cf
    • Janne Grunau's avatar
      arm: apple: Switch to fully dynamic mem layout · 6fb4f738
      Janne Grunau authored and Tom Rini's avatar Tom Rini committed 
      
Support for Apple M1 Pro and Max will allow using a single binary for
all M1 SoCs. The M1 Pro/Max have a different memory layout. The RAM
start address is 0x100_0000_0000 instead of 0x8_0000_0000.
Replace the hardcoded memory layout with dynamic initialized
environment variables in board_late_init().

Tested on Mac Mini (2020) and Macbook Pro 14-inch (2021).

Signed-off-by: default avatarJanne Grunau <j@jannau.net>
Reviewed-by: default avatarMark Kettenis <kettenis@openbsd.org>
      6fb4f738
    • Michael Walle's avatar
      board: sl28: use fit image generator · 554a8531
      Michael Walle authored and Priyanka Jain's avatar Priyanka Jain committed 
      
Simplify the binman config and fdt nodes by using the "@..-SEQ"
substitutions and CONFIG_OF_LIST.

Signed-off-by: default avatarMichael Walle <michael@walle.cc>
[Rebased]
Signed-off-by: Priyanka Jain's avatarPriyanka Jain <priyanka.jain@nxp.com>
      554a8531
    • Michael Walle's avatar
      board: sl28: disable random MAC address generation · 62ba0e5d
      Michael Walle authored and Priyanka Jain's avatar Priyanka Jain committed 
      
Nowadays, u-boot (when CONFIG_NET_RANDOM_ETHADDR is set) will set
enetaddr to a random value if not set and then pass the randomly
generated MAC address to linux.

This is bad for the following reasons:
 (1) it makes it impossible for linux to detect this error
 (2) linux won't trigger any fallback mechanism for the case where
     it didn't find any valid MAC address
 (3) a saveenv will store this randomly generated MAC address in the
     environment

Probably, the user will also be unaware that something is wrong. He will
just get different MAC addresses on each reboot, asking himself why this
is the case.

As this board usually have a serial port, the user can just fix this by
setting the MAC address manually in the environment. Also disable the
netconsole just in case, because it cannot be guaranteed that it will
work in any case. After all, this was just a convenience option, because
the bootloader - right now - doesn't have the ability to read the MAC
address, which is stored in the OTP. But it is far more important to
have a clear view of whats wrong with a board and that means we can no
longer use this Kconfig option.

Signed-off-by: default avatarMichael Walle <michael@walle.cc>
[Rebased]
Signed-off-by: Priyanka Jain's avatarPriyanka Jain <priyanka.jain@nxp.com>
      62ba0e5d
    • Michael Walle's avatar
      board: sl28: enable SoC watchdog support · 2ba8a446
      Michael Walle authored and Priyanka Jain's avatar Priyanka Jain committed 
      
The SoC provides two additional watchdogs integrated in the SoC. Enable
support for these.

Signed-off-by: default avatarMichael Walle <michael@walle.cc>
Reviewed-by: Priyanka Jain's avatarPriyanka Jain <priyanka.jain@nxp.com>
      2ba8a446
    • Michael Walle's avatar
      board: sl28: enable sl28cpld support · 34502f7a
      Michael Walle authored and Priyanka Jain's avatar Priyanka Jain committed 
      
Enable the GPIO and watchdog driver. Don't start the watchdog
automatically, though.

Signed-off-by: default avatarMichael Walle <michael@walle.cc>
Reviewed-by: Priyanka Jain's avatarPriyanka Jain <priyanka.jain@nxp.com>
      34502f7a
  17. Feb 25, 2022
  19. Feb 23, 2022
  21. Feb 21, 2022
  23. Feb 19, 2022
  25. Feb 18, 2022
  27. Feb 17, 2022
    • Marek Behún's avatar
      arm: mvebu: turris_omnia: Reset the board immediately on DDR training failure · 4b7db756
      Marek Behún authored and Stefan Roese's avatar Stefan Roese committed 
      
The state of the current DDR training code for Armada 38x is such that
we cannot be sure it will always train successfully - although after the
last change we were yet unable to find a board that failed DDR training,
from experience in the last 2 years we know that it is possible.

The experience also tells us that in many cases the board fails training
only sometimes, and after a reset the training is successful.

Enable the new option that makes the board reset itself on DDR training
failure immediately. Until now we called hang() in such a case, which
meant that the board was reset by the MCU after 120 seconds.

Signed-off-by: default avatarMarek Behún <marek.behun@nic.cz>
Reviewed-by: default avatarStefan Roese <sr@denx.de>
Reviewed-by: default avatarPali Rohár <pali@kernel.org>
      4b7db756
  29. Feb 16, 2022

Imprint & Privacy Policy