Re: [PATCH v2] board: rockchip: Add the Turing RK1 SoM
Hey Sam,
On 24-04-11 16:35:57, Sam Edwards wrote:
On Thu, Apr 11, 2024 at 1:29 AM Florian Klink wrote:
On 23-12-14 18:46:47, Joshua Riek wrote:
>The Turing RK1 is a Rockchip RK3588 based SoM from Turing Machines.
>
>Specifications:
>
>Rockchip RK3588 SoC
>4x ARM Cortex-A76, 4x ARM Cortex-A55
>8/16/32GB memory LPDDR4x
>Mali G610MC4 GPU
>32GB eMMC HS400
>2x USB 2.0, 2x USB 3.0
>2x MIPI CSI 4x lanes
>1x MIPI-DSI DPHY 2x lanes
>PCIe 2.0 x1, PCIe 3.0 x4
>1x HDMI 2.1 output, 1x DP 1.4 output
>Gigabit Ethernet
>Size: 69.6mm x 45mm (260-pin SO-DIMM connector)
>
>Kernel commit:
>2806a69f3fef ("arm64: dts: rockchip: Add Turing RK1 SoM support")
[…]
>diff --git a/configs/turing-rk1-rk3588_defconfig
b/configs/turing-rk1-rk3588_defconfig
>new file mode 100644
>index 00..289f2da775
>--- /dev/null
>+++ b/configs/turing-rk1-rk3588_defconfig
>@@ -0,0 +1,133 @@
>+CONFIG_ARM=y
>+CONFIG_SKIP_LOWLEVEL_INIT=y
>+CONFIG_SYS_HAS_NONCACHED_MEMORY=y
>+CONFIG_COUNTER_FREQUENCY=2400
>+CONFIG_ARCH_ROCKCHIP=y
>+CONFIG_TEXT_BASE=0x00a0
>+CONFIG_SPL_LIBCOMMON_SUPPORT=y
>+CONFIG_SPL_LIBGENERIC_SUPPORT=y
>+CONFIG_NR_DRAM_BANKS=2
>+CONFIG_HAS_CUSTOM_SYS_INIT_SP_ADDR=y
>+CONFIG_CUSTOM_SYS_INIT_SP_ADDR=0xc0
>+CONFIG_SF_DEFAULT_SPEED=2400
>+CONFIG_SF_DEFAULT_MODE=0x2000
>+CONFIG_DEFAULT_DEVICE_TREE="rk3588-turing-rk1"
>+CONFIG_ROCKCHIP_RK3588=y
>+CONFIG_SPL_ROCKCHIP_COMMON_BOARD=y
>+CONFIG_ROCKCHIP_SPI_IMAGE=y
Hi Florian,
Thanks for getting in touch!
Does the RK1 have an SPI chip attached, and is is possible to flash
u-boot into SPI and boot from it?
The answer you want is "no." Though the RK1 does have an unpopulated
pad for SPI flash, actually installing one would be a pretty involved
user modification, and those users almost certainly can/will build the
SPI boot image themselves.
This has sparked some confusion on whether "u-boot-rockchip-spi.bin"
should be provided in a downstream build or not.
Ah yeah the CONFIG_ROCKCHIP_SPI_IMAGE=y might not be a sensible
default given that 99.9% of users don't need it. Is that config entry
the main thing creating the confusion? I think it should be removed
here in U-Boot if so.
Yes, it caused a "u-boot-rockchip-spi.bin" to be produced, and we were
wondering on whether it should be provided as a result of our build to
downstream users [1].
Removing it from the `defconfig` sounds like the best way to prevent
this confusion. If people solder on a SPI Flash manually, they probably
know how to re-add it to the uboot config ;-)
Could you send a patch for that?
Note that the RK1 is a little different from most RK3588 boards in
that UART9 at 115200 baud is the generally-accepted debug UART (due
both to the popularity of pairing it with the Turing Pi 2
clusterboard, and for pin-compatibility with most NVIDIA Jetson SoMs),
and setting this very early in boot requires using Rockchip's
"ddrbin_tool" to change the configuration embedded in the ddrbin/TPL
image. If you're already supporting other targets that require ddrbin
configuration changes, please add these for RK1:
uart id=9
uart iomux=0
uart baudrate=115200
...but if this would require going significantly out of your way,
don't worry about it. IIUC this is only required to get TPL+SPL output
routed correctly: the U-Boot monitor + kernel will still
(re)initialize UART9 appropriately.
We currently simply use
`bin/rk3588_ddr_lp4_2112MHz_lp5_2400MHz_v1.16.bin`
from https://github.com/rockchip-linux/rkbin for all RK3588 targets as
`ROCKCHIP_TPL`.
There doesn't seem to be a RK1-specific blob in the repo, and so far
we're not invoking the closed-source x86_64-linux-only
`tools/ddrbin_tool` binary to produce an alternative version of the SPL
for other targets either.
So if it also works without doing that (maybe with a little bit less
debug serial output during early boot) we'd probably keep it like this
;-)
Thanks,
Florian
[1]: https://github.com/NixOS/nixpkgs/pull/302138#discussion_r1560349114
Re: [PATCH v2] board: rockchip: Add the Turing RK1 SoM
On 23-12-14 18:46:47, Joshua Riek wrote:
The Turing RK1 is a Rockchip RK3588 based SoM from Turing Machines.
Specifications:
Rockchip RK3588 SoC
4x ARM Cortex-A76, 4x ARM Cortex-A55
8/16/32GB memory LPDDR4x
Mali G610MC4 GPU
32GB eMMC HS400
2x USB 2.0, 2x USB 3.0
2x MIPI CSI 4x lanes
1x MIPI-DSI DPHY 2x lanes
PCIe 2.0 x1, PCIe 3.0 x4
1x HDMI 2.1 output, 1x DP 1.4 output
Gigabit Ethernet
Size: 69.6mm x 45mm (260-pin SO-DIMM connector)
Kernel commit:
2806a69f3fef ("arm64: dts: rockchip: Add Turing RK1 SoM support")
[…]
diff --git a/configs/turing-rk1-rk3588_defconfig
b/configs/turing-rk1-rk3588_defconfig
new file mode 100644
index 00..289f2da775
--- /dev/null
+++ b/configs/turing-rk1-rk3588_defconfig
@@ -0,0 +1,133 @@
+CONFIG_ARM=y
+CONFIG_SKIP_LOWLEVEL_INIT=y
+CONFIG_SYS_HAS_NONCACHED_MEMORY=y
+CONFIG_COUNTER_FREQUENCY=2400
+CONFIG_ARCH_ROCKCHIP=y
+CONFIG_TEXT_BASE=0x00a0
+CONFIG_SPL_LIBCOMMON_SUPPORT=y
+CONFIG_SPL_LIBGENERIC_SUPPORT=y
+CONFIG_NR_DRAM_BANKS=2
+CONFIG_HAS_CUSTOM_SYS_INIT_SP_ADDR=y
+CONFIG_CUSTOM_SYS_INIT_SP_ADDR=0xc0
+CONFIG_SF_DEFAULT_SPEED=2400
+CONFIG_SF_DEFAULT_MODE=0x2000
+CONFIG_DEFAULT_DEVICE_TREE="rk3588-turing-rk1"
+CONFIG_ROCKCHIP_RK3588=y
+CONFIG_SPL_ROCKCHIP_COMMON_BOARD=y
+CONFIG_ROCKCHIP_SPI_IMAGE=y
Does the RK1 have an SPI chip attached, and is is possible to flash
u-boot into SPI and boot from it?
This has sparked some confusion on whether "u-boot-rockchip-spi.bin"
should be provided in a downstream build or not.
[…]
Thanks,
Florian
Re: [PATCH] rk3399: Add basic support for helios64
It boots fine with current Fedora IoT 34 nightlies, but kernel crashes are
very regular (sometimes recoverable, sometimes not), which looks to me like
the same problem that Armbian builds have, logs seem to point to an issue
with the dmc frequency.
I've compiled an excerpt of interesting looking logs from a couple of boots
here (you should be able to comment on the doc as well):
https://hackmd.io/@lorbus/SyXTj0lXu
Please take a look and let me know what you think.
I've been running eb607cd4957fb0ef97beb2a8293478be6a54240a from
git://git.kernel.org/pub/scm/linux/kernel/git/mmind/linux-rockchip.git
(which is 5.13-rc1, plus a whole bunch of helios64 and more generic
rk3399 fixes).
The system comes up. I couldn't immediately trigger any of the kernel
crashes (except one that regularly occurs on shutdown/reboot), which I
added to the hackmd document.
I think most of the kernel issues are a concern of refining the dtb in
the kernel itself, though, not an uboot issue per se, so not sure if
this should block the inclusion of this patch into u-boot, which seems
to work file (once there's a version with SPDX headers everywhere)
Florian
On 21-03-08 17:29:23, Christian Glombek wrote:
I've looked into this a bit over the weekend - my current WIP patch can be
found here:
https://src.fedoraproject.org/fork/lorbus/rpms/uboot-tools/blob/helios64/f/0001-arm-Add-support-for-Kobol-Helios64-board.patch
It's essentially the entire devicetree used in Armbian, only that I had to
remove the gpio{1,2,4} initialization since `gpio-hog` doesn't appear to
work with upstream u-boot.
It boots fine with current Fedora IoT 34 nightlies, but kernel crashes are
very regular (sometimes recoverable, sometimes not), which looks to me like
the same problem that Armbian builds have, logs seem to point to an issue
with the dmc frequency.
I've compiled an excerpt of interesting looking logs from a couple of boots
here (you should be able to comment on the doc as well):
https://hackmd.io/@lorbus/SyXTj0lXu
Please take a look and let me know what you think.
Best regards,
Christian
--
Florian Klink
Re: Setting DEVICE_TREE for xilinx_zynq_virt_defconfig?
On 20-12-27 17:48:51, Florian Klink wrote: On 20-06-22 14:12:59, Michal Simek wrote: I tried building latest master 2b8692bac1e8795cbb87b0d00213fd193409851d, for a zynq device, and did according to the documentation: $ export DEVICE_TREE=zynq-zc702 $ make xilinx_zynq_virt_defconfig $ make Reading f7c6ee7fe7bcc387de4c92300f46cb725b845b53, I assumed this should have fixed FDT loading, but for some reason u-boot still tries to look for a `zynq-zynq.dtb` in FDTDIR. Could it be this broke in the meantime, or is this expected? I am not aware about any issue like this. Can you please provide more logs to see what it is happening? Sorry for the super radio silence, this is mostly a hobby project, and now I finally have some time :-) My main understanding here is that if I build u-boot with DEVICE_TREE=zynq-zc702, and pass FDTDIR directive in extlinux.conf, it would try to load `zynq-zc702.dtb` from the FDTDIR on but, but apparently it always tries to load a "zynq-zynq.dtb" file. Apparently, this smells like I missed adding the zynq-pynq.dtb to the Makefile, and some time ago, it silently did fall back to zynq-zynq.dtb. I ran into a build failure after rebasing this patch earlier today. "[PATCH] dts: Log name of expected .dtb file" should make such mistakes easier recognizable. Regards, Florian signature.asc Description: PGP signature
[PATCH] dts: Log name of expected .dtb file
Make it more obvious what .dts file was expected by the build system. When adding support for a new board, I kept getting this error message, assuming I passed a wrong DEVICE_TREE parameter. However, what was really the mistake was that the entry in `arch/arm/dts/Makefile` was missing, and u-boot didn't like not being able to find the .dtb file that should have been produced. Simply logging the expected .dtb file name should make it easier to spot such mistakes. Signed-off-by: Florian Klink --- dts/Makefile | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/dts/Makefile b/dts/Makefile index a20930eb9a..a0347c9d34 100644 --- a/dts/Makefile +++ b/dts/Makefile @@ -32,7 +32,7 @@ targets += dt.dtb dt-spl.dtb $(DTB): arch-dtbs $(Q)test -e $@ || ( \ echo >&2; \ - echo >&2 "Device Tree Source is not correctly specified."; \ + echo >&2 "Device Tree Source ($@) is not correctly specified."; \ echo >&2 "Please define 'CONFIG_DEFAULT_DEVICE_TREE'"; \ echo >&2 "or build with 'DEVICE_TREE=' argument"; \ echo >&2; \ -- 2.29.2
[PATCH 1/2] ARM: zynq: add Digilent Zynq PYNQ Board(s)
This adds the dts and entry in CONFIG_OF_LIST for the Digilent Zynq PYNQ
Board(s).
They're Zynq 7000 - based boards, the Z1 is from Digilent, the Z2 from
TUL.
They have a slightly different audio system, and a different pin header,
but these aren't really accessible from the PS, only from the PL, so the
DTB is the same.
Co-authored-by: Thomas Heijligen
Signed-off-by: Florian Klink
Signed-off-by: Thomas Heijligen
---
arch/arm/dts/Makefile | 1 +
arch/arm/dts/zynq-pynq.dts | 68 ++
configs/xilinx_zynq_virt_defconfig | 2 +-
3 files changed, 70 insertions(+), 1 deletion(-)
create mode 100644 arch/arm/dts/zynq-pynq.dts
diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
index fd47e408f8..0631404dbd 100644
--- a/arch/arm/dts/Makefile
+++ b/arch/arm/dts/Makefile
@@ -267,6 +267,7 @@ dtb-$(CONFIG_ARCH_ZYNQ) += \
zynq-microzed.dtb \
zynq-minized.dtb \
zynq-picozed.dtb \
+ zynq-pynq.dtb \
zynq-syzygy-hub.dtb \
zynq-topic-miami.dtb \
zynq-topic-miamilite.dtb \
diff --git a/arch/arm/dts/zynq-pynq.dts b/arch/arm/dts/zynq-pynq.dts
new file mode 100644
index 00..04ac0f7cdc
--- /dev/null
+++ b/arch/arm/dts/zynq-pynq.dts
@@ -0,0 +1,68 @@
+// SPDX-License-Identifier: GPL-2.0+
+/dts-v1/;
+#include "zynq-7000.dtsi"
+#include
+
+/ {
+ model = "Digilent/TUL Zynq PYNQ";
+ compatible = "digilent,zynq-pynq", "digilent,zynq-pynq-z1",
"tul,zynq-pynq", "tul,zynq-pynq-z2", "xlnx,zynq-7000";
+
+ aliases {
+ ethernet0 =
+ serial0 =
+ };
+
+ memory@0 {
+ device_type = "memory";
+ reg = <0x0 0x2000>;
+ };
+
+ chosen {
+ bootargs = "";
+ stdout-path = "serial0:115200n8";
+ };
+
+ gpio-leds {
+ compatible = "gpio-leds";
+
+ ld4 {
+ label = "zynq-pynq:green:ld4";
+ gpios = < 7 GPIO_ACTIVE_HIGH>;
+ };
+ };
+
+ usb_phy0: phy0 {
+ #phy-cells = <0>;
+ compatible = "usb-nop-xceiv";
+ reset-gpios = < 46 GPIO_ACTIVE_LOW>;
+ };
+};
+
+ {
+ ps-clk-frequency = <5000>;
+};
+
+ {
+ status = "okay";
+ phy-mode = "rgmii-id";
+ phy-handle = <_phy>;
+
+ ethernet_phy: ethernet-phy@0 {
+ reg = <0>;
+ device_type = "ethernet-phy";
+ };
+};
+
+ {
+ status = "okay";
+};
+
+ {
+ status = "okay";
+};
+
+ {
+ status = "okay";
+ dr_mode = "host";
+ usb-phy = <_phy0>;
+};
diff --git a/configs/xilinx_zynq_virt_defconfig
b/configs/xilinx_zynq_virt_defconfig
index 552f1b4dfb..c46f531d4d 100644
--- a/configs/xilinx_zynq_virt_defconfig
+++ b/configs/xilinx_zynq_virt_defconfig
@@ -52,7 +52,7 @@ CONFIG_CMD_MTDPARTS=y
CONFIG_CMD_MTDPARTS_SPREAD=y
CONFIG_CMD_MTDPARTS_SHOW_NET_SIZES=y
CONFIG_CMD_UBI=y
-CONFIG_OF_LIST="zynq-zc702 zynq-zc706 zynq-zc770-xm010 zynq-zc770-xm011
zynq-zc770-xm011-x16 zynq-zc770-xm012 zynq-zc770-xm013 zynq-cc108 zynq-microzed
zynq-minized zynq-picozed zynq-zed zynq-zturn zynq-zturn-v5 zynq-zybo
zynq-zybo-z7 zynq-dlc20-rev1.0"
+CONFIG_OF_LIST="zynq-zc702 zynq-zc706 zynq-zc770-xm010 zynq-zc770-xm011
zynq-zc770-xm011-x16 zynq-zc770-xm012 zynq-zc770-xm013 zynq-cc108 zynq-microzed
zynq-minized zynq-picozed zynq-pynq zynq-zed zynq-zturn zynq-zturn-v5 zynq-zybo
zynq-zybo-z7 zynq-dlc20-rev1.0"
CONFIG_ENV_OVERWRITE=y
CONFIG_ENV_IS_IN_SPI_FLASH=y
CONFIG_SYS_RELOC_GD_ENV_ADDR=y
--
2.29.2
Re: Setting DEVICE_TREE for xilinx_zynq_virt_defconfig?
On 20-06-22 14:12:59, Michal Simek wrote: Hi, On 20. 06. 20 20:06, Florian Klink wrote: Hey, I tried building latest master 2b8692bac1e8795cbb87b0d00213fd193409851d, for a zynq device, and did according to the documentation: $ export DEVICE_TREE=zynq-zc702 $ make xilinx_zynq_virt_defconfig $ make Reading f7c6ee7fe7bcc387de4c92300f46cb725b845b53, I assumed this should have fixed FDT loading, but for some reason u-boot still tries to look for a `zynq-zynq.dtb` in FDTDIR. Could it be this broke in the meantime, or is this expected? I am not aware about any issue like this. Can you please provide more logs to see what it is happening? Sorry for the super radio silence, this is mostly a hobby project, and now I finally have some time :-) My main understanding here is that if I build u-boot with DEVICE_TREE=zynq-zc702, and pass FDTDIR directive in extlinux.conf, it would try to load `zynq-zc702.dtb` from the FDTDIR on but, but apparently it always tries to load a "zynq-zynq.dtb" file. My hardware currently at hand isn't a zynq-zc702, but a PYNQ - I'll send the patches for that in a bit and paste a proper log here. Regards, Florian signature.asc Description: PGP signature
Setting DEVICE_TREE for xilinx_zynq_virt_defconfig?
Hey, I tried building latest master 2b8692bac1e8795cbb87b0d00213fd193409851d, for a zynq device, and did according to the documentation: $ export DEVICE_TREE=zynq-zc702 $ make xilinx_zynq_virt_defconfig $ make Reading f7c6ee7fe7bcc387de4c92300f46cb725b845b53, I assumed this should have fixed FDT loading, but for some reason u-boot still tries to look for a `zynq-zynq.dtb` in FDTDIR. Could it be this broke in the meantime, or is this expected? Regards, Florian signature.asc Description: PGP signature
[PATCH] ARM: dts: xilinx: Fix I2C and SPI bus warnings
Ported over from https://patchwork.kernel.org/patch/10599941/
Signed-off-by: Florian Klink
---
arch/arm/dts/zynq-zc702.dts | 12 ++--
arch/arm/dts/zynq-zc770-xm010.dts | 2 +-
arch/arm/dts/zynq-zc770-xm013.dts | 2 +-
3 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/arch/arm/dts/zynq-zc702.dts b/arch/arm/dts/zynq-zc702.dts
index d10695740f..b043d341d6 100644
--- a/arch/arm/dts/zynq-zc702.dts
+++ b/arch/arm/dts/zynq-zc702.dts
@@ -181,17 +181,17 @@
#address-cells = <1>;
#size-cells = <0>;
reg = <7>;
- hwmon@52 {
+ hwmon@34 {
compatible = "ti,ucd9248";
- reg = <52>;
+ reg = <0x34>;
};
- hwmon@53 {
+ hwmon@35 {
compatible = "ti,ucd9248";
- reg = <53>;
+ reg = <0x35>;
};
- hwmon@54 {
+ hwmon@36 {
compatible = "ti,ucd9248";
- reg = <54>;
+ reg = <0x36>;
};
};
};
diff --git a/arch/arm/dts/zynq-zc770-xm010.dts
b/arch/arm/dts/zynq-zc770-xm010.dts
index e1f34653ec..c547d7921d 100644
--- a/arch/arm/dts/zynq-zc770-xm010.dts
+++ b/arch/arm/dts/zynq-zc770-xm010.dts
@@ -72,7 +72,7 @@
status = "okay";
num-cs = <4>;
is-decoded-cs = <0>;
- flash@0 {
+ flash@1 {
compatible = "sst25wf080", "jedec,spi-nor";
reg = <1>;
spi-max-frequency = <100>;
diff --git a/arch/arm/dts/zynq-zc770-xm013.dts
b/arch/arm/dts/zynq-zc770-xm013.dts
index 05a49982cc..bdf0c2f956 100644
--- a/arch/arm/dts/zynq-zc770-xm013.dts
+++ b/arch/arm/dts/zynq-zc770-xm013.dts
@@ -67,7 +67,7 @@
status = "okay";
num-cs = <4>;
is-decoded-cs = <0>;
- eeprom: eeprom@0 {
+ eeprom: eeprom@2 {
at25,byte-len = <8192>;
at25,addr-mode = <2>;
at25,page-size = <32>;
--
2.24.1
Re: [U-Boot] arm: mvebu: ClearFog: booting u-boot from ssd?
Hey Stefan, According to the clearfog wiki and uboot-armada38x src tree, there are separate images for sd and sata, with the makefile there calling $(obj)tools/marvell/doimage -T mmc -D 0x0 -E 0x0 -G $(obj)tools/marvell/bin_hdr/bin_hdr.bin u-boot.bin u-boot.mmc vs $(obj)tools/marvell/doimage -T sata -D 0x0 -E 0x0 -G $(obj)tools/marvell/bin_hdr/bin_hdr.bin u-boot.bin u-boot.sata Please note that this "should" not be needed when using mainline U-Boot on A38x. All necessary tools for image generation are included here. […] Am I missing something completely obvious, or does this mean there need to be different image headers depending on boot medium type BootROM tries to load u-boot from (so it might be desirable to make this configurable)? You are correct. The image header differs depending on the boot media. You need to change the BOOT_FROM line in the .cfg file accordingly, if you want to boot from SATA. Yes, this was more to find out in which ways the sata image differs from the sdcard image. Simply editing `board/solidrun/clearfog/kwbimage.cfg` and changing BOOT_FROM from `sdio` to `sata` got BootROM into accepting the image :-) Are there already any efforts being taken on that? Most likely we'd also need to enable SATA drivers, so u-boot is able to read the kernel, which might be on that disk. Correct. If the SATA driver is not enabled yet, then this has to be done for this board. A38x has an AHCI compatible SATA controller, so this is the controller / driver to use. I suggest to look at the Marvell dev-board "db-88f6820-gp" for this. I'll have a look on that, thanks! My question also aimed into the direction on how to make this best configurable via `.config`, instead of editing this file by hand. Are there any similar places were we set such things dynamically? Regards, Florian ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] arm: mvebu: ClearFog: booting u-boot from ssd?
Hey, I tried getting ClearFog to load u-boot from a M.2 SSD (via SATA) So I built u-boot-spl.kwb make clearfog_defconfig make -j4 ARCH=arm CROSS_COMPILE=arm-none-eabi- dd'ed it on the SSD: dd if=u-boot-spl.kwb of=/dev/sdX bs=512 seek=1 changed SW1 dip to 11100, and got this: BootROM - 1.73 Booting from AHCI Probing HBA- 0 port 0 SATA device found BootROM: Bad header at offset 0001 BootROM: Bad header at offset 0022 BootROM: Bad header at offset 1000 BootROM: Bad header at offset 2000 BootROM: Bad header at offset 3000 BootROM: Bad header at offset 4000 BootROM: Bad header at offset 5000 BootROM: Bad header at offset 6000 BootROM: Bad header at offset 7000 Trying Uart According to the clearfog wiki and uboot-armada38x src tree, there are separate images for sd and sata, with the makefile there calling $(obj)tools/marvell/doimage -T mmc -D 0x0 -E 0x0 -G $(obj)tools/marvell/bin_hdr/bin_hdr.bin u-boot.bin u-boot.mmc vs $(obj)tools/marvell/doimage -T sata -D 0x0 -E 0x0 -G $(obj)tools/marvell/bin_hdr/bin_hdr.bin u-boot.bin u-boot.sata According to uboot-armada38x's tools/marvell/doimage_mv/doimage.c, this seems to result in different hdr->blockID = IBR_HDR_SATA_ID; //0x78 hdr->blockID = IBR_HDR_MMC_ID; //0xAE and maybe another hdr->sourceAddr baked into the image header [1] Mainline u-boot also knows about IBR_HDR_SATA_ID (tools/kwbimage.h), and has a mapping in tools/kwbimage.c (boot_modes[]), which seems to decide depending on the 'BOOT_FROM' setting in board/solidrun/clearfog/kwbimage.cfg This is currently hardcoded to 'sdio' (which will be translated to 0xAE == IBR_HDR_MMC_ID). Am I missing something completely obvious, or does this mean there need to be different image headers depending on boot medium type BootROM tries to load u-boot from (so it might be desirable to make this configurable)? Are there already any efforts being taken on that? Most likely we'd also need to enable SATA drivers, so u-boot is able to read the kernel, which might be on that disk. Regards, Florian [1]: https://github.com/coreboot/coreboot/blob/master/util/marvell/doimage_mv/doimage.c#L575 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH] arm: mvebu: ClearFog: document boot selection switches, update UART
Signed-off-by: Florian Klink <flo...@flokli.de> --- board/solidrun/clearfog/README | 21 + 1 file changed, 17 insertions(+), 4 deletions(-) diff --git a/board/solidrun/clearfog/README b/board/solidrun/clearfog/README index ef1e3bf426..a7bc0d4e23 100644 --- a/board/solidrun/clearfog/README +++ b/board/solidrun/clearfog/README @@ -17,16 +17,29 @@ $ sudo dd if=u-boot-spl.kwb of=/dev/sdX bs=512 seek=1 Please use the correct device node for your setup instead of "/dev/sdX" here! +Boot selection: +--- + +Before powering up the board, boot selection should be done via the SW1 dip +switch (0: OFF, 1: ON): + + - SPI: 00010 + - SD/eMMC: 00111 + - M.2 SSD: 11100 + - UART:01001 [1] + +[1]: According to SolidRun's manual, 0 should be used for UART booting on + the ClearFog 'Pro' variant. + However, this doesn't work (anymore) at least on Rev. 2.1 (but '01001' as + mentionend for the 'Base' variant does). + Boot from UART: --- Connect the on-board micro-USB (CF Pro: CON11, CF Base: CON5) to your host. -Set the SW1 DIP switches to UART boot (0: OFF, 1: ON): - - ClearFog Base: 01001 - ClearFog Pro: 0 +Set the SW1 DIP switches to UART boot (see above). Run the following command to initiate U-Boot download: -- 2.15.1 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
