Peter Robinson [Mon, 8 Jun 2020 22:50:30 +0000 (23:50 +0100)]
rockchip: Pinebook Pro: Fix SPI flash and store env on it
Some minor fixes for SPI flash on the Pinebook Pro and also
default to saving environment to the SPI flash as it's
guaranteed to be on board.
Signed-off-by: Peter Robinson <pbrobinson@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
(applied with make savedefconfig) Signed-off-by: Kever Yang <kever.yang@rock-chips.com>
With video output enabled and USB keyboard supported there is no need
for serial console. So let initialize USB subsystem so keyboard connected to
board (either directly or via hub) can be used to interrupt autoboot.
U-Boot TPL 2020.07-rc3-00123-g52d6cbd1a7 (Jun 03 2020 - 17:34:20)
Channel 0: LPDDR4, 50MHz
BW=32 Col=10 Bk=8 CS0 Row=16/15 CS=1 Die BW=16 Size=2048MB
Channel 1: LPDDR4, 50MHz
BW=32 Col=10 Bk=8 CS0 Row=16/15 CS=1 Die BW=16 Size=2048MB
256B stride
256B stride
lpddr4_set_rate: change freq to 400000000 mhz 0, 1
lpddr4_set_rate: change freq to 800000000 mhz 1, 0
Trying to boot from BOOTROM
Returning to boot ROM...
SoC: Rockchip rk3399
Reset cause: RST
Model: Pine64 RockPro64 v2.1
DRAM: 3.9 GiB
PMIC: RK808
MMC: mmc@fe310000: 2, mmc@fe320000: 1, sdhci@fe330000: 0
Loading Environment from SPI Flash... SF: Detected gd25q128 with page size 256 Bytes, erase size 4 KiB, total 16 MiB
OK
In: serial
Out: vidconsole
Err: vidconsole
Model: Pine64 RockPro64 v2.1
Net: eth0: ethernet@fe300000
starting USB...
Bus usb@fe380000: USB EHCI 1.00
Bus usb@fe3a0000: USB OHCI 1.0
Bus usb@fe3c0000: USB EHCI 1.00
Bus usb@fe3e0000: USB OHCI 1.0
Bus dwc3: Register 2000140 NbrPorts 2
Starting the controller
USB XHCI 1.10
Bus dwc3: Register 2000140 NbrPorts 2
Starting the controller
USB XHCI 1.10
scanning bus usb@fe380000 for devices... 1 USB Device(s) found
scanning bus usb@fe3a0000 for devices... 1 USB Device(s) found
scanning bus usb@fe3c0000 for devices... 1 USB Device(s) found
scanning bus usb@fe3e0000 for devices... 2 USB Device(s) found
scanning bus dwc3 for devices... 1 USB Device(s) found
scanning bus dwc3 for devices... 2 USB Device(s) found
scanning usb for storage devices... 1 Storage Device(s) found
Hit any key to stop autoboot: 0
=>
Signed-off-by: Marcin Juszkiewicz <marcin@juszkiewicz.com.pl> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
Tom Rini [Fri, 3 Jul 2020 16:00:36 +0000 (12:00 -0400)]
Merge branch 'master' of https://gitlab.denx.de/u-boot/custodians/u-boot-riscv
- sbi: Add newline to error message
- fu540: dts: Correct reg size of otp and dmc nodes
- Enhance reserved memory fixup about PMP information passed from OpenSBI
- sifive: fu540: Add gpio-restart support
- qemu-riscv: Update QEMU run command
- Assorted fixes related to reserved memory
- fu540: enable all cache ways from U-Boot proper
- use log functions in fdt_fixup
Bin Meng [Tue, 23 Jun 2020 12:23:15 +0000 (05:23 -0700)]
doc: qemu-riscv: Update QEMU run command
Explicitly pass the "-bios" option to QEMU to run U-Boot, instead
of the "-kernel" option, as we know that "-bios" behavior will be
changed since QEMU 5.1.0.
This also updates validated QEMU version to 5.0.0.
Signed-off-by: Bin Meng <bin.meng@windriver.com> Reviewed-by: Atish Patra <atish.patra@wdc.com>
Bin Meng [Fri, 26 Jun 2020 01:16:08 +0000 (18:16 -0700)]
riscv: Enable CONFIG_OF_BOARD_FIXUP by default for OF_SEPARATE
Starting from OpenSBI v0.7, the SBI firmware inserts/fixes up the
reserved memory node for PMP protected memory regions. All RISC-V
boards need to copy the reserved memory node from the device tree
provided by the firmware to the device tree used by U-Boot.
Turn on CONFIG_OF_BOARD_FIXUP by default for OF_SEPARATE.
Signed-off-by: Bin Meng <bin.meng@windriver.com> Reviewed-by: Atish Patra <atish.patra@wdc.com> Reviewed-by: Rick Chen <rick@andestech.com>
Bin Meng [Fri, 26 Jun 2020 01:16:06 +0000 (18:16 -0700)]
riscv: Avoid the reserved memory fixup if src and dst point to the same place
The copy of reserved memory node from source dtb to destination dtb
can be avoided if they point to the same place. This is useful when
OF_PRIOR_STAGE is used.
Signed-off-by: Bin Meng <bin.meng@windriver.com> Reviewed-by: Rick Chen <rick@andestech.com> Reviewed-by: Atish Patra <atish.patra@wdc.com>
Tom Rini [Tue, 30 Jun 2020 21:15:39 +0000 (17:15 -0400)]
Merge tag 'efi-2020-07-rc6-2' of https://gitlab.denx.de/u-boot/custodians/u-boot-efi
Pull request for UEFI sub-system for efi-2020-07-rc6 (2)
Fix an incorrect update of the GD register in efi_get_variable_common().
Fix an incorrect check for an FDT reg property.
Fix a device tree used for Python testing.
Bin Meng [Sun, 28 Jun 2020 01:03:17 +0000 (18:03 -0700)]
test/py: test_efi_fit: Update #size-cells to 1
test_efi_fit tests fail on RISC-V currently. This is due to the
RISC-V arch_fixup_fdt() checks the #size-cells of the root node
in order to correctly fix up the reserved memory node.
Per the DT binding, the /reserved-memory node requires both
<#address-cells> and <#size-cells> and they should use the same
values as the root node. For the root node, it's not very useful
if <#size-cells> is zero.
efi_loader: incorrect check against FDT_ADDR_T_NONE
With commit 0d7c2913fdf7 ("cmd: bootefi: Honor the address & size cells
properties correctly") addr was replaced by fdt_addr. But not in the check
against FDT_ADDR_T_NONE.
Fixes: 0d7c2913fdf7 ("cmd: bootefi: Honor the address & size cells properties
correctly") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Tom Rini [Sun, 28 Jun 2020 14:12:25 +0000 (10:12 -0400)]
Merge tag 'fixes-for-v2020.07' of https://gitlab.denx.de/u-boot/custodians/u-boot-video
- fix logo on mx6ul_14x14_evk with DM_VIDEO enabled
- fix banner string overwriting the logo on small displays
- fix splash warning when building for ARM64
- fix STM32 DSI driver to probe only on supported hardware
- fix memory corruption with DSI panel drivers
Ye Li [Wed, 10 Jun 2020 09:52:22 +0000 (02:52 -0700)]
splash: Fix build warning on 64 bits CPU
Get below warning on ARM64 platform, because the bmp_load_addr
is defined to u32.
common/splash.c: In function ‘splash_video_logo_load’:
common/splash.c:74:9: warning: cast to pointer from integer
of different size [-Wint-to-pointer-cast]
74 | memcpy((void *)bmp_load_addr, bmp_logo_bitmap,
Signed-off-by: Ye Li <ye.li@nxp.com> Reviewed-by: Jagan Teki <jagan@amarulasolutions.com> Tested-by: Jagan Teki <jagan@amarulasolutions.com> # bpi-m1+, bpi-m64
Ye Li [Wed, 10 Jun 2020 09:52:21 +0000 (02:52 -0700)]
video: vidconsole: avoid multiple lines overwrite logo
Fix the bug that multiple lines wraps to overwrite logo bmp
display.
Signed-off-by: Ye Li <ye.li@nxp.com> Reviewed-by: Jagan Teki <jagan@amarulasolutions.com> Tested-by: Jagan Teki <jagan@amarulasolutions.com> # bpi-m1+, bpi-m64
Ye Li [Wed, 10 Jun 2020 09:52:23 +0000 (02:52 -0700)]
video: bmp: support 8bits BMP drawing on 24/32 bpp framebuffer
Update video bmp code so that we can display 8 bits logo on
24 or 32 bpp framebuffer.
Signed-off-by: Ye Li <ye.li@nxp.com> Signed-off-by: Anatolij Gustschin <agust@denx.de> Reviewed-by: Jagan Teki <jagan@amarulasolutions.com> Tested-by: Jagan Teki <jagan@amarulasolutions.com> # bpi-m1+, bpi-m64
The commit 84a6a27ae3ff ("rockchip: rk3188: init CPU freq in clock
driver") changed ARM clock from 600MHz to 1600MHz. It made boot
unstable due to the fact that PMIC at the start generates insufficient
voltage for operation. See also: commit f4f57c58b589 ("rockchip:
rk3188: Setup the armclk in spl").
Fixes commit 84a6a27ae3ff ("rockchip: rk3188: init CPU freq in clock
driver").
Signed-off-by: Alexander Kochetkov <al.kochet@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
We can configure the clock output in the device tree. Disable the
hardcoded one in here. This is highly board-specific and should have
never been enabled in the PHY driver.
If bisecting shows that this commit breaks your board it probably
depends on the clock output of your Atheros AR8035 PHY. Please have a
look at doc/device-tree-bindings/net/phy/atheros.txt. You need to set
"clk-out-frequency = <125000000>" because that value was the hardcoded
value until this commit.
Signed-off-by: Michael Walle <michael@walle.cc> Acked-by: Joe Hershberger <joe.hershberger@ni.com>
, the clock output setting for the AR803x driver is removed from being
hardcoded in the PHY driver and should be passed via device tree instead.
Update the device tree with the "qca,clk-out-frequency" property so that
Ethernet can work again.
Haibo Chen [Mon, 15 Jun 2020 09:18:12 +0000 (17:18 +0800)]
mmc: retry CMD1 in mmc_send_op_cond() until the eMMC is ready
According to eMMC specification v5.1 section 6.4.3, we should issue
CMD1 repeatedly in the idle state until the eMMC is ready even if
mmc_send_op_cond() send CMD1 with argument = 0. Otherwise some eMMC
devices seems to enter the inactive mode after mmc_complete_op_cond()
issued CMD0 when the eMMC device is busy.
Signed-off-by: Haibo Chen <haibo.chen@nxp.com> Reviewed-by: Peng Fan <peng.fan@nxp.com>
Haibo Chen [Mon, 22 Jun 2020 11:38:04 +0000 (19:38 +0800)]
mmc: fsl_esdhc_imx: disable the CMD CRC check for standard tuning
In current code, we add 1ms dealy after each tuning command for standard
tuning method. Adding this 1ms dealy is because USDHC default check the
CMD CRC and DATA line. If detect the CMD CRC, USDHC standard tuning
IC logic do not wait for the tuning data sending out by the card, trigger
the buffer read ready interrupt immediately, and step to next cycle. So
when next time the new tuning command send out by USDHC, card may still
not send out the tuning data of the upper command，then some eMMC cards
may stuck, can't response to any command, block the whole tuning procedure.
If do not check the CMD CRC for tuning, then do not has this issue. USDHC
will wait for the tuning data of each tuning command and check them. If the
tuning data pass the check, it also means the CMD line also okay for tuning.
So this patch disable the CMD CRC check for tuning, save some time for the
whole tuning procedure.
Haibo Chen [Mon, 22 Jun 2020 11:38:03 +0000 (19:38 +0800)]
mmc: fsl_esdhc_imx: fix the mask for tuning start point
According the RM, the bit[6~0] of register ESDHC_TUNING_CTRL is
TUNING_START_TAP, bit[7] of this register is to disable the command
CRC check for standard tuning. So fix it here.
Jagan Teki [Wed, 10 Jun 2020 19:18:23 +0000 (21:18 +0200)]
nvme: Invalidate dcache before submitting admin cmd
This patch try to avoids eviction of dirty lines during DMA
transfer. The code right now execute the following step:
- allocate the buffer
- start a dma operation using the non-coherent dma buffer
- invalidate cache lines associated with the buffer
- read the buffer
This can lead to reading back not valid information, because the cache
controller could evict dirty cache lines belonging to the buffer *after*
the DMA operation has started to fill the DRAM.
In order to avoid this, a new invalidation is required *before* starting
the DMA operation. The patch just adds an invalidation before submitting
the DMA command.
Example below shows the nvme disk scan result without the following
patch
Joel Johnson [Sat, 20 Jun 2020 04:45:47 +0000 (22:45 -0600)]
zfs: fix missing include for disk_partition definition
Commit 0528979fa7ab ("part: Drop disk_partition_t typedef") changed to
a struct. As a result it uncovered an apparent missing include in
zfs_common.h for part.h which actually contains the definition. The ZFS
handles the struct exclusively as pointers so it was only a warning.
warning: ‘struct disk_partition’ declared inside parameter list
will not be visible outside of this definition or declaration
void zfs_set_blk_dev(struct blk_desc *rbdd, struct disk_partition *info);
Signed-off-by: Joel Johnson <mrjoel@lixil.net>
Series-CC: Simon Glass <sjg@chromium.org>
Walter Lozano [Tue, 19 May 2020 18:24:22 +0000 (15:24 -0300)]
mx6cuboxi: customize board_boot_order to access eMMC
In SPL legacy code only one MMC device is created, based on BOOT_CFG
register, which can be either SD or eMMC. In this context
board_boot_order return always MMC1 when configure to boot from
SD/eMMC. After switching to DM both SD and eMMC devices are created
based on the information available on DT, but as board_boot_order
only returns MMC1 is not possible to boot from eMMC.
This patch customizes board_boot_order taking into account BOOT_CFG
register to point to correct MMC1 / MMC2 device. Additionally, handle
IO mux for the desired boot device.
Signed-off-by: Walter Lozano <walter.lozano@collabora.com>
Ye Li [Wed, 10 Jun 2020 03:28:03 +0000 (20:28 -0700)]
arm: dts: imx: fsl-imx8qm.dtsi: fix gpio aliases
Current aliases missed gpio0 node, and this node shoud be
aliased to gpio index 0 to align with i.MX8QXP. Otherwise, we
will get below message when running "gpio status" command, and
see the reason by "dm uclass".
Marek Vasut [Thu, 21 May 2020 23:13:54 +0000 (01:13 +0200)]
ARM: imx: soc: Select default TEXT_BASE for MX7
Select default U-Boot and SPL text base for the MX7 SoC. The U-Boot
text base is picked as the one used by various MX7 boards. The SPL
text base however is different.
The SPL text base is set to 0x912000 instead of the usual 0x911000,
that is because the 0x911000 value cannot work. Using 0x911000 as a
SPL text base will result in the DCD header being placed below the
0x911000 address, which is a reserved SRAM area which must not be
used. This will actually trigger eMMC boot failure on MX7D at least.
Hence the increment.
Update all boards affected by this SPL problem to the new SPL_TEXT_BASE.
Signed-off-by: Marek Vasut <marex@denx.de> Cc: Fabio Estevam <festevam@gmail.com> Cc: NXP i.MX U-Boot Team <uboot-imx@nxp.com> Cc: Peng Fan <peng.fan@nxp.com> Cc: Stefano Babic <sbabic@denx.de>
Marek Vasut [Thu, 21 May 2020 23:13:00 +0000 (01:13 +0200)]
ARM: imx: soc: Switch BOARD_EARLY_INIT_F to imply on MX7
There are systems where board_early_init_f() is plain empty. Switch
the config option from "select" to "imply", to permit user to unset
the BOARD_EARLY_INIT_F if it were to be empty.
Signed-off-by: Marek Vasut <marex@denx.de> Cc: Fabio Estevam <festevam@gmail.com> Cc: NXP i.MX U-Boot Team <uboot-imx@nxp.com> Cc: Peng Fan <peng.fan@nxp.com> Cc: Stefano Babic <sbabic@denx.de>
Marek Vasut [Thu, 21 May 2020 23:12:39 +0000 (01:12 +0200)]
ARM: imx: ddr: Fill in missing DDRC ZQCTLx on i.MX7
The iMX7 defines further DDRC ZQCTLx registers, however those were
thus far missing from the list of registers and not programmed. On
systems with LPDDR2 or DDR3, those registers must be programmed with
correct values, otherwise the DRAM may not work. However, existing
systems which worked without programming these registers before are
now setting those registers to 0, which is the default value, so no
functional change there.
Signed-off-by: Marek Vasut <marex@denx.de> Cc: Fabio Estevam <festevam@gmail.com> Cc: NXP i.MX U-Boot Team <uboot-imx@nxp.com> Cc: Peng Fan <peng.fan@nxp.com> Cc: Stefano Babic <sbabic@denx.de>
Marek Vasut [Thu, 14 May 2020 16:49:10 +0000 (18:49 +0200)]
ARM: imx6: Fetch MAC address in board_init_late() on DH iMX6 PDK2
This is needed to obtain the MAC from EEPROM/OTP only after the final
env is populated, otherwise the ethaddr might be overriden.
Signed-off-by: Marek Vasut <marex@denx.de> Cc: Claudius Heine <ch@denx.de> Cc: Harald Seiler <hws@denx.de> Cc: Ludwig Zenz <lzenz@dh-electronics.com> Cc: Stefano Babic <sbabic@denx.de>
Igor Opaniuk [Tue, 16 Jun 2020 19:20:08 +0000 (22:20 +0300)]
toradex: imx: enable BOOTCOUNT feature
This introduces automatic boot counter that increases after every
reset.After a power-on reset, it will be initialized with 1,
and each reboot will increment the value by 1. By default it's
disabled if bootlimit isn't set.
To enable this feature you have set bootcount limit ("bootlimit"),
alternate boot action ("altbootcmd") that will be performed if
the new value of bootcount exceeds the value of bootlimit, and
"upgrade_available" to let U-Boot automatically increase and save
the counter value after every reset:
Igor Opaniuk [Tue, 16 Jun 2020 19:20:06 +0000 (22:20 +0300)]
apalis-tk1: enable distroboot
1. Use distro_bootcmd as default boot command instead of
legacy emmcboot wrapper.
2. Drop emmcboot and sdboot wrappers.
3. Provide proper boot order for Distro Boot.
Signed-off-by: Igor Opaniuk <igor.opaniuk@toradex.com>
Max Krummenacher [Tue, 16 Jun 2020 19:20:05 +0000 (22:20 +0300)]
configs/colibri_vf.h: drop sdboot in favour of distro_bootcmd
The distro bootscript uses kernel_image to get the file name of
the kernel, so change that variable name.
UBI boot has precedence in the default boot command. If one wants
to boot from SD with a working NAND installation stop in U-Boot
and enter:
setenv fdtfile ${soc}-colibri-${fdt_board}.dtb && run distro_bootcmd
Signed-off-by: Max Krummenacher <max.krummenacher@toradex.com>
Stefan Agner [Tue, 16 Jun 2020 19:20:03 +0000 (22:20 +0300)]
colibri-imx6ull/imx7: define bootubipart for distro boot
When using distro boot to boot from UBI volumes the boot partition
has been hardcoded to "UBI" (capital letters). However, our default
MTD layout uses "ubi" (lower case letter). Define "ubi" as the
default UBI partition for distro boot for Toradex. This allows to
use distro boot without having to redefine the MTD partition layout
which is useful for TorizonCore.
Signed-off-by: Stefan Agner <stefan.agner@toradex.com>
Fabio Estevam [Wed, 17 Jun 2020 17:33:16 +0000 (14:33 -0300)]
ARM: dts: imx6qdl-sabresd: Fix AR8031 phy-mode
As per kernel commit 0672d22a1924 ("ARM: dts: imx: Fix the AR803X phy-mode)
the correct phy-mode should be "rgmii-id", so fix it accordingly
to fix the Ethernet regression.
To eliminate any doubts about the out-of-reset value of the PHY, that
the driver previously relied on.
If bisecting shows that this commit breaks your board you probably have
a wrong PHY interface mode. You probably want the
PHY_INTERFACE_MODE_RGMII_RXID or PHY_INTERFACE_MODE_RGMII_ID mode.
Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com> Acked-by: Joe Hershberger <joe.hershberger@ni.com> Signed-off-by: Fabio Estevam <festevam@gmail.com>
Fabio Estevam [Fri, 19 Jun 2020 01:14:42 +0000 (22:14 -0300)]
ARM: dts: imx6qdl-sabreauto: Fix AR8031 phy-mode
As per kernel commit 0672d22a1924 ("ARM: dts: imx: Fix the AR803X phy-mode)
the correct phy-mode should be "rgmii-id", so fix it accordingly
to fix the Ethernet regression.
To eliminate any doubts about the out-of-reset value of the PHY, that
the driver previously relied on.
If bisecting shows that this commit breaks your board you probably have
a wrong PHY interface mode. You probably want the
PHY_INTERFACE_MODE_RGMII_RXID or PHY_INTERFACE_MODE_RGMII_ID mode.
Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com> Acked-by: Joe Hershberger <joe.hershberger@ni.com>
Fix the phy-mode accordingly to fix the regression.
projects / u-boot.git / log