Re: [PATCH 11/16] arm: xilinx_versal_virt: Add a devicetree file
On 10/13/21 03:01, Simon Glass wrote:
Add a devicetree file obtained from qemu for this board. This was obtained
with:
qemu-system-aarch64 -M xlnx-versal-virt -machine dumpdtb=dtb.dtb
Signed-off-by: Simon Glass
---
arch/arm/dts/Makefile| 3 +-
arch/arm/dts/xilinx-versal-virt.dts | 307 +++
configs/xilinx_versal_virt_defconfig | 1 +
3 files changed, 310 insertions(+), 1 deletion(-)
create mode 100644 arch/arm/dts/xilinx-versal-virt.dts
diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
index 0fec648dd77..dd6d66af5e6 100644
--- a/arch/arm/dts/Makefile
+++ b/arch/arm/dts/Makefile
@@ -352,7 +352,8 @@ dtb-$(CONFIG_ARCH_ZYNQMP) += \
dtb-$(CONFIG_ARCH_VERSAL) += \
versal-mini.dtb \
versal-mini-emmc0.dtb \
- versal-mini-emmc1.dtb
+ versal-mini-emmc1.dtb \
+ xilinx-versal-virt.dtb
dtb-$(CONFIG_ARCH_ZYNQMP_R5) += \
zynqmp-r5.dtb
dtb-$(CONFIG_AM33XX) += \
diff --git a/arch/arm/dts/xilinx-versal-virt.dts
b/arch/arm/dts/xilinx-versal-virt.dts
new file mode 100644
index 000..3712af9e7a4
--- /dev/null
+++ b/arch/arm/dts/xilinx-versal-virt.dts
@@ -0,0 +1,307 @@
+// SPDX-License-Identifier: GPL-2.0+ OR MIT
+/*
+ * Sample device tree for versal-virt board
+
+ * Copyright 2021 Google LLC
+ */
+
+/dts-v1/;
+
+/ {
+ compatible = "xlnx-versal-virt";
+ model = "Xilinx Versal Virtual development board";
+ #address-cells = <0x02>;
+ #size-cells = <0x02>;
+ interrupt-parent = <0x8000>;
+
+ memory@0 {
+ reg = <0x00 0x00 0x00 0x800>;
+ device_type = "memory";
+ };
+
+ clk25 {
+ u-boot,dm-pre-reloc;
+ compatible = "fixed-clock";
+ #clock-cells = <0x00>;
+ clock-frequency = <0x17d7840>;
+ phandle = <0x8003>;
+ };
+
+ clk125 {
+ u-boot,dm-pre-reloc;
+ compatible = "fixed-clock";
+ #clock-cells = <0x00>;
+ clock-frequency = <0x7735940>;
+ phandle = <0x8004>;
+ };
+
+ cpus {
+ #address-cells = <0x01>;
+ #size-cells = <0x00>;
+
+ cpu@0 {
+ compatible = "arm,cortex-a72";
+ device_type = "cpu";
+ reg = <0x00>;
+ };
+
+ cpu@1 {
+ compatible = "arm,cortex-a72";
+ device_type = "cpu";
+ reg = <0x01>;
+ };
+ };
+
+ rtc@f12a {
+ compatible = "xlnx,zynqmp-rtc";
+ reg = <0x00 0xf12a 0x00 0x1>;
+ interrupt-names = "alarm\0sec";
+ interrupts = <0x00 0x8e 0x04 0x00 0x8f 0x04>;
+ };
+
+ sdhci@f104 {
+ compatible = "arasan,sdhci-8.9a";
+ reg = <0x00 0xf104 0x00 0x1>;
+ interrupts = <0x00 0x7e 0x04>;
+ clock-names = "clk_xin\0clk_ahb";
+ clocks = <0x8003 0x8003>;
+ };
+
+ sdhci@f105 {
+ compatible = "arasan,sdhci-8.9a";
+ reg = <0x00 0xf105 0x00 0x1>;
+ interrupts = <0x00 0x80 0x04>;
+ clock-names = "clk_xin\0clk_ahb";
+ clocks = <0x8003 0x8003>;
+ };
+
+ usb@ff9d {
+ phandle = <0x8005>;
+ #size-cells = <0x02>;
+ #address-cells = <0x02>;
+ ranges;
+ clocks = <0x8003 0x8004>;
+ clock-names = "bus_clk\0ref_clk";
+ reg = <0x00 0xff9d 0x00 0x1>;
+ compatible = "xlnx,versal-dwc3";
+
+ dwc3@fe20 {
+ maximum-speed = "high-speed";
+ phandle = <0x8006>;
+ snps,mask_phy_reset;
+ snps,refclk_fladj;
+ snps,dis_u3_susphy_quirk;
+ snps,dis_u2_susphy_quirk;
+ phy-names = "usb3-phy";
+ dr_mode = "host";
+ #stream-id-cells = <0x01>;
+ snps,quirk-frame-length-adjustment = <0x20>;
+ interrupts = <0x00 0x16 0x04>;
+ interrupt-names = "dwc_usb3";
+ reg = <0x00 0xfe20 0x00 0x1>;
+ compatible = "snps,dwc3";
+ };
+ };
+
+ dma@ffa8 {
+ compatible = "xlnx,zynqmp-dma-1.0";
+ reg = <0x00 0xffa8 0x00 0x1000>;
+ interrupts = <0x00 0x3c 0x04>;
+ clock-names = "clk_main\0clk_apb";
+ clocks = <0x8003 0x8003>;
+ xlnx,bus-width = <0x40>;
+ };
+
+ dma@ffa9 {
+ compatible = "xlnx,zynqmp-dma-1.0";
+ reg = <0x00 0xffa9 0x00 0
please help, "Ram disk image is corrupt or invalid" (qemu virt machine, arm64)
Hello all,
I can boot linux kernel using this command line.
${QEMU_DIR}/qemu-system-aarch64 -M ${QMACHINE} -cpu cortex-a72 -kernel
${LINUX_DIR}/arch/arm64/boot/Image -initrd ${BUSYBOX_DIR}/initramfs.cpio.gz
--append "root=/dev/ram init=/init nokaslr earlycon ip=dhcp" -m 2048M
-nographic -netdev user,id=n1 -device e1000,netdev=n1
After reading some docs and getting helps, I tried u-boot.
After loading Image (for arm64) and dtb.dtb, I could see the kernel booting
to the final stage of deploying initramfs but it failed because I didn't
give the initramfs.cpio.gz address. (I used "booti 0x4020 - 0x4000)
So I added initramfs.cpio.gz under /opt/tftp, and loaded kernel, initramfs,
and dbt on memory and gave "booti 0x4020 0x4200 0x4000",
addresses are kernel, initramfs and dtb).
Below is the log. (please see the final error message below)
++ /home/ckim/QEMU/qemu/build/aarch64-softmmu/qemu-system-aarch64 -M virt
-bios u-boot.bin -cpu cortex-a57 -bios u-boot.bin -nographic -drive
if=pflash,format=raw,index=1,file=envstore.img -netdev
user,id=net0,tftp=/opt/tftp -device e1000,netdev=net0
U-Boot 2021.10-00455-g50c84208ad (Oct 13 2021 - 12:58:40 +0900)
DRAM: 128 MiB
Flash: 64 MiB
MMC:
Loading Environment from Flash... *** Warning - bad CRC, using default
environment
In:pl011@900
Out: pl011@900
Err: pl011@900
Net: e1000: 52:54:00:12:34:56
eth0: e1000#0
Hit any key to stop autoboot: 0
starting USB...
No working controllers found
USB is stopped. Please issue 'usb start' first.
scanning bus for devices...
Device 0: unknown device
Device 0: unknown device
starting USB...
No working controllers found
BOOTP broadcast 1
BOOTP broadcast 2
BOOTP broadcast 3
DHCP client bound to address 10.0.2.15 (1004 ms)
Using e1000#0 device
TFTP from server 10.0.2.2; our IP address is 10.0.2.15
Filename 'boot.scr.uimg'.
Load address: 0x4020
Loading: *
TFTP error: 'File not found' (1)
Not retrying...
BOOTP broadcast 1
BOOTP broadcast 2
BOOTP broadcast 3
DHCP client bound to address 10.0.2.15 (1001 ms)
Using e1000#0 device
TFTP from server 10.0.2.2; our IP address is 10.0.2.15
Filename 'boot.scr.uimg'.
Load address: 0x4040
Loading: *
TFTP error: 'File not found' (1)
Not retrying...
=> tftp 0x4000 dtb.dtb
Using e1000#0 device
TFTP from server 10.0.2.2; our IP address is 10.0.2.15
Filename 'dtb.dtb'.
Load address: 0x4000
Loading: #
#
963.9 KiB/s
done
Bytes transferred = 1048576 (10 hex)
=> tftp 0x4020 Image
Using e1000#0 device
TFTP from server 10.0.2.2; our IP address is 10.0.2.15
Filename 'Image'.
Load address: 0x4020
Loading: #
#
#
#
#
#
#
#
#
#
#
#
#
#
#
#
#
#
#
#
#
#
#
#
#
#
#
#
###
10 MiB/s
done
Bytes transferred = 26489344 (1943200 hex)
=> tftp 0x4200 initramfs.cpio.gz
Using e1000#0 device
TFTP from server 10.0.2.2; our IP address is 10.0.2.15
Filename 'initramfs.cpio.gz'.
Load address: 0x4200
Loading: ##
Re: Broken build with disabling OpenSSL crypto
Hi,
On 07/10/2021 00:05, Alex G. wrote:
Hi Jernej,
On 10/6/21 4:27 PM, Jernej Škrabec wrote:
Hi everyone!
Commit cb9faa6f98ae ("tools: Use a single target-independent config to
enable
OpenSSL") recently introduced option to disable usage of OpenSSL via
CONFIG_TOOLS_LIBCRYPTO. However, just a bit later, another commit
b4f3cc2c42d9
("tools: kwbimage: Do not hide usage of secure header under
CONFIG_ARMADA_38X") made U-Boot tools hard dependent on OpenSSL. That
totally
defeats the purpose of first commit. I suggest that it gets reverted.
I would like disable OpenSSL for my usage, since it gives me troubles
when
cross-compiling U-Boot inside LibreELEC build system. It's not needed
for our
case anyway.
Best regards,
Can you please give the following diff a try, and if it works for you,
submit as patch?
it looks like this is still required, as this fixes it for me too ;)
Thanks,
Andre
Alex
diff --git a/tools/Makefile b/tools/Makefile
index 4a86321f64..7f72ff9645 100644
--- a/tools/Makefile
+++ b/tools/Makefile
@@ -96,7 +96,8 @@ AES_OBJS-$(CONFIG_TOOLS_LIBCRYPTO) := $(addprefix
lib/aes/, \
# Cryptographic helpers that depend on openssl/libcrypto
LIBCRYPTO_OBJS-$(CONFIG_TOOLS_LIBCRYPTO) := $(addprefix lib/, \
- fdt-libcrypto.o)
+ fdt-libcrypto.o) \
+ kwbimage.o
ROCKCHIP_OBS = lib/rc4.o rkcommon.o rkimage.o rksd.o rkspi.o
@@ -117,7 +118,6 @@ dumpimage-mkimage-objs := aisimage.o \
imximage.o \
imx8image.o \
imx8mimage.o \
- kwbimage.o \
lib/md5.o \
lpc32xximage.o \
mxsimage.o \
@@ -169,8 +169,8 @@ HOST_EXTRACFLAGS +=
-DCONFIG_FIT_SIGNATURE_MAX_SIZE=0x
HOST_EXTRACFLAGS += -DCONFIG_FIT_CIPHER
endif
-# MXSImage needs LibSSL
-ifneq
($(CONFIG_MX23)$(CONFIG_MX28)$(CONFIG_ARMADA_38X)$(CONFIG_TOOLS_LIBCRYPTO),)
+# MXSImage needs LibSSL <- Nope! Read the frogging notice at the top
+ifneq ($(CONFIG_TOOLS_LIBCRYPTO),)
HOSTCFLAGS_kwbimage.o += \
$(shell pkg-config --cflags libssl libcrypto 2> /dev/null || echo "")
HOSTLDLIBS_mkimage += \
RE: how to run u-boot on qemu arm64 virt machine?
> > That's a very old QEMU version. We use v6.1.0 currently and v4.2.0 before > that. > > -- > Tom Thank you, Tom Yes, so I tried it now with v4.2.0 with "-nographic" option. (Without it I still see qemu manager window.) Chan Kim
Re: [PATCH 15/16] fdt: Make OF_BOARD a bool option
On 10/13/21 03:01, Simon Glass wrote: This should not be a separate option from OF_SEPARATE. It is a run-time option to override the devicetree, even if present. Move the option out of the choice. Disable BINMAN_FDT for a few boards which don't actually use it. You only sent patch 6/16 and 15/16 to me. No clue why. Please, send complete patch sets instead of selected patches which cannot be reviewed without the context. Best regards Heinrich Signed-off-by: Simon Glass --- configs/qemu-ppce500_defconfig | 1 + configs/qemu-riscv32_spl_defconfig | 2 ++ configs/qemu-riscv64_spl_defconfig | 1 + dts/Kconfig| 9 + 4 files changed, 9 insertions(+), 4 deletions(-) diff --git a/configs/qemu-ppce500_defconfig b/configs/qemu-ppce500_defconfig index 5bf3e8de37a..66411f73a11 100644 --- a/configs/qemu-ppce500_defconfig +++ b/configs/qemu-ppce500_defconfig @@ -54,4 +54,5 @@ CONFIG_VIRTIO_PCI=y CONFIG_VIRTIO_NET=y CONFIG_VIRTIO_BLK=y CONFIG_ADDR_MAP=y +# CONFIG_BINMAN_FDT is not set CONFIG_PANIC_HANG=y diff --git a/configs/qemu-riscv32_spl_defconfig b/configs/qemu-riscv32_spl_defconfig index 3909c9a15ad..4621afb1a87 100644 --- a/configs/qemu-riscv32_spl_defconfig +++ b/configs/qemu-riscv32_spl_defconfig @@ -6,6 +6,7 @@ CONFIG_DEFAULT_DEVICE_TREE="qemu-virt32" CONFIG_SPL=y CONFIG_TARGET_QEMU_VIRT=y CONFIG_RISCV_SMODE=y +# CONFIG_OF_BOARD_FIXUP is not set CONFIG_DISTRO_DEFAULTS=y CONFIG_SYS_LOAD_ADDR=0x8020 CONFIG_FIT=y @@ -18,3 +19,4 @@ CONFIG_OF_BOARD=y CONFIG_SYS_RELOC_GD_ENV_ADDR=y CONFIG_DM_MTD=y CONFIG_SYSRESET_SBI=y +# CONFIG_BINMAN_FDT is not set diff --git a/configs/qemu-riscv64_spl_defconfig b/configs/qemu-riscv64_spl_defconfig index 34d88da41b0..6f8ff91df9e 100644 --- a/configs/qemu-riscv64_spl_defconfig +++ b/configs/qemu-riscv64_spl_defconfig @@ -19,3 +19,4 @@ CONFIG_OF_BOARD=y CONFIG_SYS_RELOC_GD_ENV_ADDR=y CONFIG_DM_MTD=y CONFIG_SYSRESET_SBI=y +# CONFIG_BINMAN_FDT is not set diff --git a/dts/Kconfig b/dts/Kconfig index 313b9e5d70b..6be5710df7d 100644 --- a/dts/Kconfig +++ b/dts/Kconfig @@ -104,7 +104,6 @@ choice config OF_SEPARATE bool "Separate DTB for DT control" - depends on !SANDBOX help If this option is enabled, the device tree will be built and placed as a separate u-boot.dtb file alongside the U-Boot image. @@ -117,14 +116,16 @@ config OF_EMBED and development only and is not recommended for production devices. Boards in the mainline U-Boot tree should not use it. +endchoice + config OF_BOARD bool "Provided by the board (e.g a previous loader) at runtime" help If this option is enabled, the device tree will be provided by - the board at runtime if the board supports it, instead of being - bundled with the image. + the board at runtime if the board supports it. The device tree bundled + with the image (if any) will be overridden / ignored. -endchoice + A device tree file must be provided in the tree. config DEFAULT_DEVICE_TREE string "Default Device Tree for DT control"
Re: [PATCH 06/16] riscv: qemu: Add devicetree files for qemu_riscv32/64
On 10/13/21 03:01, Simon Glass wrote:
Add these files, generated from qemu, so there is a reference devicetree
in the U-Boot tree.
Split the existing qemu-virt into two, since we need a different
devicetree for 32- and 64-bit machines.
You only sent patch 6/16 and 15/16 to me. No clue why. Please, send
complete patchsets instead of selected patches which cannot be reviewed
without the context.
Which devices exist depends on the QEMU comannd line.
The files you create here do neither reflect the superset of all QEMU
settings nor the minimum set. They do not include all devices supported
on QEMU by U-Boot either.
You cannot assume that the values in this patch will match values used
by the next invocation of QEMU.
Hence it is totally unclear what this patch might be good for.
Best regards
Heinrich
Signed-off-by: Simon Glass
---
arch/riscv/dts/Makefile | 2 +-
arch/riscv/dts/qemu-virt.dts | 8 -
arch/riscv/dts/qemu-virt32.dts | 217 +++
arch/riscv/dts/qemu-virt64.dts | 217 +++
configs/qemu-riscv32_defconfig | 1 +
configs/qemu-riscv32_smode_defconfig | 1 +
configs/qemu-riscv32_spl_defconfig | 2 +-
configs/qemu-riscv64_defconfig | 1 +
configs/qemu-riscv64_smode_defconfig | 1 +
configs/qemu-riscv64_spl_defconfig | 2 +-
10 files changed, 441 insertions(+), 11 deletions(-)
delete mode 100644 arch/riscv/dts/qemu-virt.dts
create mode 100644 arch/riscv/dts/qemu-virt32.dts
create mode 100644 arch/riscv/dts/qemu-virt64.dts
diff --git a/arch/riscv/dts/Makefile b/arch/riscv/dts/Makefile
index b6e9166767b..90d3f35e6e3 100644
--- a/arch/riscv/dts/Makefile
+++ b/arch/riscv/dts/Makefile
@@ -2,7 +2,7 @@
dtb-$(CONFIG_TARGET_AX25_AE350) += ae350_32.dtb ae350_64.dtb
dtb-$(CONFIG_TARGET_MICROCHIP_ICICLE) += microchip-mpfs-icicle-kit.dtb
-dtb-$(CONFIG_TARGET_QEMU_VIRT) += qemu-virt.dtb
+dtb-$(CONFIG_TARGET_QEMU_VIRT) += qemu-virt32.dtb qemu-virt64.dtb
dtb-$(CONFIG_TARGET_OPENPITON_RISCV64) += openpiton-riscv64.dtb
dtb-$(CONFIG_TARGET_SIFIVE_UNLEASHED) += hifive-unleashed-a00.dtb
dtb-$(CONFIG_TARGET_SIFIVE_UNMATCHED) += hifive-unmatched-a00.dtb
diff --git a/arch/riscv/dts/qemu-virt.dts b/arch/riscv/dts/qemu-virt.dts
deleted file mode 100644
index fecff542b91..000
--- a/arch/riscv/dts/qemu-virt.dts
+++ /dev/null
@@ -1,8 +0,0 @@
-// SPDX-License-Identifier: GPL-2.0+
-/*
- * Copyright (C) 2021, Bin Meng
- */
-
-/dts-v1/;
-
-#include "binman.dtsi"
diff --git a/arch/riscv/dts/qemu-virt32.dts b/arch/riscv/dts/qemu-virt32.dts
new file mode 100644
index 000..3c449413523
--- /dev/null
+++ b/arch/riscv/dts/qemu-virt32.dts
@@ -0,0 +1,217 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Copyright (C) 2021, Bin Meng
+ */
+
+/dts-v1/;
+
+#include "binman.dtsi"
+
+/ {
+ #address-cells = <0x02>;
+ #size-cells = <0x02>;
+ compatible = "riscv-virtio";
+ model = "riscv-virtio,qemu";
+
+ fw-cfg@1010 {
+ dma-coherent;
+ reg = <0x00 0x1010 0x00 0x18>;
+ compatible = "qemu,fw-cfg-mmio";
+ };
+
+ flash@2000 {
+ bank-width = <0x04>;
+ reg = <0x00 0x2000 0x00 0x200
+ 0x00 0x2200 0x00 0x200>;
+ compatible = "cfi-flash";
+ };
+
+ chosen {
+ bootargs = [00];
+ stdout-path = "/soc/uart@1000";
+ };
+
+ memory@8000 {
+ device_type = "memory";
+ reg = <0x00 0x8000 0x00 0x800>;
+ };
+
+ cpus {
+ #address-cells = <0x01>;
+ #size-cells = <0x00>;
+ timebase-frequency = <0x989680>;
+
+ cpu@0 {
+ phandle = <0x01>;
+ device_type = "cpu";
+ reg = <0x00>;
+ status = "okay";
+ compatible = "riscv";
+ riscv,isa = "rv32imafdcsu";
+ mmu-type = "riscv,sv32";
+
+ interrupt-controller {
+ #interrupt-cells = <0x01>;
+ interrupt-controller;
+ compatible = "riscv,cpu-intc";
+ phandle = <0x02>;
+ };
+ };
+
+ cpu-map {
+
+ cluster0 {
+
+ core0 {
+ cpu = <0x01>;
+ };
+ };
+ };
+ };
+
+ soc {
+ #address-cells = <0x02>;
+ #size-cells = <0x02>;
+ compatible = "simple-bus";
+ ranges;
+
+ rtc@101000 {
+ interrupts = <0x0b>;
+ interrupt-parent = <0
Re: [PATCH] distro_boot: Fix bootfile env after calling boot_extlinux
Yes changes inside include/config_distro_bootcmd.h not the best solution
for this issue.
I think it is better to change sysboot cmd and i have prepared another
solution already!
https://patchwork.ozlabs.org/project/uboot/patch/20211013033912.3297227-1-...@khadas.com/
how about this ?
On Wed, Oct 13, 2021 at 5:07 AM Tom Rini wrote:
> On Tue, Oct 12, 2021 at 02:31:18PM -0600, Simon Glass wrote:
> > Hi Tom,
> >
> > On Tue, 12 Oct 2021 at 13:44, Tom Rini wrote:
> > >
> > > On Tue, Oct 12, 2021 at 04:55:44PM +0800, Artem Lapkin wrote:
> > >
> > > > Problem
> > > >
> > > > PXE cannot boot normally after Sysboot changed the bootfile env
> (called
> > > > from boot_extlinux) from the default "boot.scr.uimg" to
> > > > "/boot/extlinux/extlinux.conf".
> > > >
> > > > In addition, an unbootable extlinux configuration will also make the
> PXE
> > > > boot unbootable, because it will use the incorrect path
> "/boot/extlinux/"
> > > > from the bootfile env.
> > > >
> > > > Solution
> > > >
> > > > Save and restore default bootfile env value when boot_extlinux is
> used.
> > > >
> > > > Example
> > > >
> > > > Hit SPACE in 2 seconds to stop autoboot
> > > > ... is now current device
> > > > Found /boot/extlinux/extlinux.conf
> > > > Retrieving file: /boot/extlinux/extlinux.conf
> > > > 413 bytes read in 2 ms (201.2 KiB/s)
> > > > Skipping Krescue for failure retrieving kernel
> > > > SCRIPT FAILED: continuing...
> > > > ...
> > > > Speed: 1000, full duplex
> > > > BOOTP broadcast 1
> > > > DHCP client bound to address 192.168.11.151 (8 ms)
> > > > Using ethernet@ff3f device
> > > > TFTP from server 192.168.11.1; our IP address is 192.168.11.151
> > > > Filename '/boot/extlinux/pxelinux.cfg/default'.
> > > > Not retrying...
> > > >
> > > >
> > > > Signed-off-by: Artem Lapkin
> > > > ---
> > > > include/config_distro_bootcmd.h | 2 ++
> > > > 1 file changed, 2 insertions(+)
> > > >
> > > > diff --git a/include/config_distro_bootcmd.h
> b/include/config_distro_bootcmd.h
> > > > index 3f724aa10f..db3d1b2362 100644
> > > > --- a/include/config_distro_bootcmd.h
> > > > +++ b/include/config_distro_bootcmd.h
> > > > @@ -445,7 +445,9 @@
> > > > "${devnum}:${distro_bootpart} "
>\
> > > > "${prefix}${boot_syslinux_conf}; then
> " \
> > > > "echo Found ${prefix}${boot_syslinux_conf}; "
>\
> > > > + "bootfile_bak=${bootfile}; "
> \
> > > > "run boot_extlinux; "
>\
> > > > + "setenv bootfile ${bootfile_bak}; "
>\
> > > > "echo SCRIPT FAILED: continuing...; "
>\
> > > > "fi\0"
> \
> > > > \
> > >
> > > We've had this kind of problem before, and the answer is that variables
> > > should be local, not global in scope. In this case, I see that the way
> > > the pxe/sysboot code works is that we have to env_set("..") in one
> place
> > > to env_get("..") in another, so I don't see a way around this.
> > >
> > > Reviewed-by: Tom Rini
> >
> > IMO a better approach will be the bootflow implementation. I hope to
> > get v2 out early next week.
>
> I'm not sure if the bootflow way of going here would or would not have
> the same problem, or perhaps a slightly different problem. At heart
> here, "sysboot" calls env_set(...) and then calls in to the pxe code
> which does env_get(...). So now I wonder how this would be fixed in
> bootflow, since we aren't dealing with the environment directly.
>
> --
> Tom
>
[PATCH] cmd: sysboot: dont overwrite bootfile env
Problem
PXE cannot boot normally after Sysboot changed the bootfile env (called
from boot_extlinux) from the default "boot.scr.uimg" to
"/boot/extlinux/extlinux.conf".
In addition, an unbootable extlinux configuration will also make the PXE
boot unbootable, because it will use the incorrect path "/boot/extlinux/"
from the bootfile env.
Solution
sysboot must care about bootfile and restore default value after usage.
Come from:
https://patchwork.ozlabs.org/project/uboot/patch/20211012085544.3206394-1-...@khadas.com/
Signed-off-by: Artem Lapkin
---
cmd/sysboot.c | 30 --
1 file changed, 20 insertions(+), 10 deletions(-)
diff --git a/cmd/sysboot.c b/cmd/sysboot.c
index af6a2f1b7f..99b11cc127 100644
--- a/cmd/sysboot.c
+++ b/cmd/sysboot.c
@@ -2,6 +2,7 @@
#include
#include
+#include
#include
#include
#include "pxe_utils.h"
@@ -61,8 +62,9 @@ static int do_sysboot(struct cmd_tbl *cmdtp, int flag, int
argc,
unsigned long pxefile_addr_r;
struct pxe_menu *cfg;
char *pxefile_addr_str;
- char *filename;
+ char *filename, *filename_bak;
int prompt = 0;
+ int ret = 0;
is_pxe = false;
@@ -83,9 +85,10 @@ static int do_sysboot(struct cmd_tbl *cmdtp, int flag, int
argc,
pxefile_addr_str = argv[4];
}
- if (argc < 6) {
- filename = env_get("bootfile");
- } else {
+ filename = env_get("bootfile");
+ if (argc > 5) {
+ filename_bak = malloc(strlen(filename) + 1);
+ strcpy(filename_bak, filename);
filename = argv[5];
env_set("bootfile", filename);
}
@@ -98,26 +101,26 @@ static int do_sysboot(struct cmd_tbl *cmdtp, int flag, int
argc,
do_getfile = do_get_any;
} else {
printf("Invalid filesystem: %s\n", argv[3]);
- return 1;
+ goto err;
}
fs_argv[1] = argv[1];
fs_argv[2] = argv[2];
if (strict_strtoul(pxefile_addr_str, 16, &pxefile_addr_r) < 0) {
printf("Invalid pxefile address: %s\n", pxefile_addr_str);
- return 1;
+ goto err;
}
if (get_pxe_file(cmdtp, filename, pxefile_addr_r) < 0) {
printf("Error reading config file\n");
- return 1;
+ goto err;
}
cfg = parse_pxefile(cmdtp, pxefile_addr_r);
if (!cfg) {
printf("Error parsing config file\n");
- return 1;
+ goto err;
}
if (prompt)
@@ -126,8 +129,15 @@ static int do_sysboot(struct cmd_tbl *cmdtp, int flag, int
argc,
handle_pxe_menu(cmdtp, cfg);
destroy_pxe_menu(cfg);
-
- return 0;
+ goto ret;
+ err:
+ ret = 1;
+ ret:
+ if (filename_bak) {
+ env_set("bootfile", filename_bak);
+ free(filename_bak);
+ }
+ return ret;
}
U_BOOT_CMD(sysboot, 7, 1, do_sysboot,
--
2.25.1
[PATCH 3/3] sunxi: binman: Enable SPL FIT loading for 32-bit SoCs
Now that Crust (SCP firmware) has support for H3, we need a FIT image to
load it. H3 also needs to load a SoC-specific eGon blob to support CPU 0
hotplug. Let's first enable FIT support before adding extra firmware.
Update the binman description to work on either 32-bit or 64-bit SoCs:
- Make BL31 optional, since it is not used on 32-bit SoCs (though BL32
may be used in the future).
- Explicitly set the minimum offset of the FIT to 32 KiB, since SPL on
some boards is still only 24 KiB large even with FIT support enabled.
CONFIG_SPL_PAD_TO cannot be used because it is not defined for H616.
FIT unlocks more features (signatures, multiple DTBs, etc.), so enable
it by default. A10 (sun4i) only has 24 KiB of SRAM A1, so it needs
SPL_FIT_IMAGE_TINY. For simplicity, enable that option everywhere.
Signed-off-by: Samuel Holland
---
arch/arm/Kconfig | 1 +
arch/arm/dts/sunxi-u-boot.dtsi | 46 ++
common/spl/Kconfig | 3 +--
3 files changed, 32 insertions(+), 18 deletions(-)
diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index d8c041a877..f80f237f7e 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -1062,6 +1062,7 @@ config ARCH_SUNXI
imply SPL_GPIO
imply SPL_LIBCOMMON_SUPPORT
imply SPL_LIBGENERIC_SUPPORT
+ imply SPL_LOAD_FIT
imply SPL_MMC if MMC
imply SPL_POWER
imply SPL_SERIAL
diff --git a/arch/arm/dts/sunxi-u-boot.dtsi b/arch/arm/dts/sunxi-u-boot.dtsi
index 4a6ed3a7dd..ad1f976329 100644
--- a/arch/arm/dts/sunxi-u-boot.dtsi
+++ b/arch/arm/dts/sunxi-u-boot.dtsi
@@ -1,13 +1,19 @@
#include
-#ifdef CONFIG_MACH_SUN50I_H6
-#define BL31_ADDR 0x104000
-#define SCP_ADDR 0x114000
-#elif defined(CONFIG_MACH_SUN50I_H616)
-#define BL31_ADDR 0x4000
+#ifdef CONFIG_ARM64
+#define ARCH "arm64"
#else
-#define BL31_ADDR 0x44000
-#define SCP_ADDR 0x5
+#define ARCH "arm"
+#endif
+
+#if defined(CONFIG_MACH_SUN50I) || defined(CONFIG_MACH_SUN50I_H5)
+#define BL31_ADDR 0x00044000
+#define SCP_ADDR 0x0005
+#elif defined(CONFIG_MACH_SUN50I_H6)
+#define BL31_ADDR 0x00104000
+#define SCP_ADDR 0x00114000
+#elif defined(CONFIG_MACH_SUN50I_H616)
+#define BL31_ADDR 0x4000
#endif
/ {
@@ -30,30 +36,33 @@
filename = "spl/sunxi-spl.bin";
};
-#ifdef CONFIG_ARM64
+#ifdef CONFIG_SPL_LOAD_FIT
fit {
- description = "Configuration to load ATF before U-Boot";
+ description = "Configuration to load U-Boot and
firmware";
+ offset = <32768>;
#address-cells = <1>;
fit,fdt-list = "of-list";
images {
uboot {
- description = "U-Boot (64-bit)";
+ description = "U-Boot";
type = "standalone";
os = "u-boot";
- arch = "arm64";
+ arch = ARCH;
compression = "none";
load = ;
+ entry = ;
u-boot-nodtb {
};
};
+#ifdef BL31_ADDR
atf {
description = "ARM Trusted Firmware";
type = "firmware";
os = "arm-trusted-firmware";
- arch = "arm64";
+ arch = ARCH;
compression = "none";
load = ;
entry = ;
@@ -63,6 +72,7 @@
missing-msg = "atf-bl31-sunxi";
};
};
+#endif
#ifdef SCP_ADDR
scp {
@@ -91,19 +101,23 @@
@config-SEQ {
description = "NAME";
+#ifdef BL31_ADDR
firmware = "atf";
-#ifndef SCP_ADDR
- loadables = "uboot";
#else
- loadables = "scp", "uboot";
+ firmware = "uboot";
+#endif
+ loadables =
+#ifdef SCP_ADDR
+ "scp",
#endif
+ "uboot";
fdt = "fdt-SEQ";
};
};
[PATCH 2/3] binman: Prevent entries in a section from overlapping
Currently, if the "offset" property is given for an entry, the section's
running offset is completely ignored. This causes entries to overlap if
the provided offset is less than the size of the entries earlier in the
section. Avoid the overlap by only using the provided offset when it is
greater than the running offset.
The motivation for this change is the rule used by SPL to find U-Boot on
sunxi boards: U-Boot starts 32 KiB after the start of SPL, unless SPL is
larger than 32 KiB, in which case U-Boot immediately follows SPL.
Signed-off-by: Samuel Holland
---
tools/binman/entry.py | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/tools/binman/entry.py b/tools/binman/entry.py
index 70222718ea..61822eb5e4 100644
--- a/tools/binman/entry.py
+++ b/tools/binman/entry.py
@@ -404,7 +404,9 @@ class Entry(object):
if self.offset_unset:
self.Raise('No offset set with offset-unset: should another '
'entry provide this correct offset?')
-self.offset = tools.Align(offset, self.align)
+elif self.offset > offset:
+offset = self.offset
+self.offset = tools.Align(offset, self.align)
needed = self.pad_before + self.contents_size + self.pad_after
needed = tools.Align(needed, self.align_size)
size = self.size
--
2.32.0
[PATCH 0/3] sunxi: SPL FIT support for 32-bit sunxi SoCs
This series makes the necessary changes so 32-bit sunxi SoCs can load additional device trees or firmware from SPL along with U-Boot proper. There was no existing binman entry property that put the FIT at the right offset. The minimum offset is 32k, but this matches neither the SPL size (which is no more than 24k on some SoCs) nor the FIT alignment (which is 512 bytes in practice due to SPL size constraints). So instead of adding a new property, I fixed what is arguably a bug in the offset property -- though this strategy will not work if someone is intentionally creating overlapping entries. Samuel Holland (3): Kconfig: Remove an impossible condition binman: Prevent entries in a section from overlapping sunxi: binman: Enable SPL FIT loading for 32-bit SoCs Kconfig| 2 +- arch/arm/Kconfig | 1 + arch/arm/dts/sunxi-u-boot.dtsi | 46 ++ common/spl/Kconfig | 3 +-- tools/binman/entry.py | 4 ++- 5 files changed, 36 insertions(+), 20 deletions(-) -- 2.32.0
[PATCH 1/3] Kconfig: Remove an impossible condition
ARCH_SUNXI selects BINMAN, so the condition "!BINMAN && ARCH_SUNXI" is impossible to satisfy. Signed-off-by: Samuel Holland --- Kconfig | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Kconfig b/Kconfig index 931a22806e..ede20d74c9 100644 --- a/Kconfig +++ b/Kconfig @@ -359,7 +359,7 @@ config BUILD_TARGET default "u-boot-spl.kwb" if ARCH_MVEBU && SPL default "u-boot-elf.srec" if RCAR_GEN3 default "u-boot.itb" if !BINMAN && SPL_LOAD_FIT && (ARCH_ROCKCHIP || \ - ARCH_SUNXI || RISCV || ARCH_ZYNQMP) + RISCV || ARCH_ZYNQMP) default "u-boot.kwb" if ARCH_KIRKWOOD default "u-boot-with-spl.bin" if ARCH_AT91 && SPL_NAND_SUPPORT default "u-boot-with-spl.imx" if ARCH_MX6 && SPL -- 2.32.0
[PATCH] net: phy: realtek: Add tx/rx delay config for 8211e
Some boards need to change the tx/rx delay config in order for
gigabit Ethernet to work.
In Linux commit bbc4d71d6354 ("net: phy: realtek: fix rtl8211e rx/tx
delay config"), Realtek documented the bits for overriding the delays
from the hardware straps.
Copy the logic from linux, so the delay config is set from the PHY's
interface type (the phy-mode property in the device tree).
This removes the need for a one-off workaround for the Pine A64+ board.
Signed-off-by: Samuel Holland
---
This change is needed for the Allwinner D1 Nezha board, which has
incorrect hardware straps.
configs/pine64_plus_defconfig | 1 -
drivers/net/phy/Kconfig | 10 -
drivers/net/phy/realtek.c | 69 ++-
3 files changed, 43 insertions(+), 37 deletions(-)
diff --git a/configs/pine64_plus_defconfig b/configs/pine64_plus_defconfig
index d1c2c3c3cc..f42f4e5923 100644
--- a/configs/pine64_plus_defconfig
+++ b/configs/pine64_plus_defconfig
@@ -8,7 +8,6 @@ CONFIG_PINE64_DT_SELECTION=y
# CONFIG_SYS_MALLOC_CLEAR_ON_INIT is not set
CONFIG_OF_LIST="sun50i-a64-pine64 sun50i-a64-pine64-plus"
CONFIG_PHY_REALTEK=y
-CONFIG_RTL8211E_PINE64_GIGABIT_FIX=y
CONFIG_SUN8I_EMAC=y
CONFIG_USB_EHCI_HCD=y
CONFIG_USB_OHCI_HCD=y
diff --git a/drivers/net/phy/Kconfig b/drivers/net/phy/Kconfig
index 68ee7d7a2d..e69cd8a4b3 100644
--- a/drivers/net/phy/Kconfig
+++ b/drivers/net/phy/Kconfig
@@ -214,16 +214,6 @@ config PHY_NXP_C45_TJA11XX
config PHY_REALTEK
bool "Realtek Ethernet PHYs support"
-config RTL8211E_PINE64_GIGABIT_FIX
- bool "Fix gigabit throughput on some Pine64+ models"
- depends on PHY_REALTEK
- help
- Configure the Realtek RTL8211E found on some Pine64+ models
differently to
- fix throughput on Gigabit links, turning off all internal delays in
the
- process. The settings that this touches are not documented in the
CONFREG
- section of the RTL8211E datasheet, but come from Realtek by way of the
- Pine64 engineering team.
-
config RTL8211X_PHY_FORCE_MASTER
bool "Ethernet PHY RTL8211x: force 1000BASE-T master mode"
depends on PHY_REALTEK
diff --git a/drivers/net/phy/realtek.c b/drivers/net/phy/realtek.c
index b1b1fa5080..84c755525f 100644
--- a/drivers/net/phy/realtek.c
+++ b/drivers/net/phy/realtek.c
@@ -12,7 +12,6 @@
#include
#define PHY_RTL8211x_FORCE_MASTER BIT(1)
-#define PHY_RTL8211E_PINE64_GIGABIT_FIX BIT(2)
#define PHY_RTL8211F_FORCE_EEE_RXC_ON BIT(3)
#define PHY_RTL8201F_S700_RMII_TIMINGS BIT(4)
@@ -49,10 +48,10 @@
#define MIIM_RTL8211F_PHYSTAT_SPDDONE 0x0800
#define MIIM_RTL8211F_PHYSTAT_LINK 0x0004
-#define MIIM_RTL8211E_CONFREG 0x1c
-#define MIIM_RTL8211E_CONFREG_TXD 0x0002
-#define MIIM_RTL8211E_CONFREG_RXD 0x0004
-#define MIIM_RTL8211E_CONFREG_MAGIC0xb400 /* Undocumented */
+#define MIIM_RTL8211E_CONFREG 0x1c
+#define MIIM_RTL8211E_CTRL_DELAY BIT(13)
+#define MIIM_RTL8211E_TX_DELAY BIT(12)
+#define MIIM_RTL8211E_RX_DELAY BIT(11)
#define MIIM_RTL8211E_EXT_PAGE_SELECT 0x1e
@@ -108,10 +107,6 @@ static int rtl8211b_probe(struct phy_device *phydev)
static int rtl8211e_probe(struct phy_device *phydev)
{
-#ifdef CONFIG_RTL8211E_PINE64_GIGABIT_FIX
- phydev->flags |= PHY_RTL8211E_PINE64_GIGABIT_FIX;
-#endif
-
return 0;
}
@@ -154,22 +149,6 @@ static int rtl8211x_config(struct phy_device *phydev)
reg |= MIIM_RTL8211x_CTRL1000T_MASTER;
phy_write(phydev, MDIO_DEVAD_NONE, MII_CTRL1000, reg);
}
- if (phydev->flags & PHY_RTL8211E_PINE64_GIGABIT_FIX) {
- unsigned int reg;
-
- phy_write(phydev, MDIO_DEVAD_NONE, MIIM_RTL8211F_PAGE_SELECT,
- 7);
- phy_write(phydev, MDIO_DEVAD_NONE,
- MIIM_RTL8211E_EXT_PAGE_SELECT, 0xa4);
- reg = phy_read(phydev, MDIO_DEVAD_NONE, MIIM_RTL8211E_CONFREG);
- /* Ensure both internal delays are turned off */
- reg &= ~(MIIM_RTL8211E_CONFREG_TXD | MIIM_RTL8211E_CONFREG_RXD);
- /* Flip the magic undocumented bits */
- reg |= MIIM_RTL8211E_CONFREG_MAGIC;
- phy_write(phydev, MDIO_DEVAD_NONE, MIIM_RTL8211E_CONFREG, reg);
- phy_write(phydev, MDIO_DEVAD_NONE, MIIM_RTL8211F_PAGE_SELECT,
- 0);
- }
/* read interrupt status just to clear it */
phy_read(phydev, MDIO_DEVAD_NONE, MIIM_RTL8211x_PHY_INER);
@@ -201,6 +180,44 @@ static int rtl8201f_config(struct phy_device *phydev)
return 0;
}
+static int rtl8211e_config(struct phy_device *phydev)
+{
+ int reg, val;
+
+ /* enable TX/RX delay for rgmii-* modes, and disable them for rgmii. */
+ switch (phydev->interface) {
+ case PHY_INTERFACE_MODE_RGMII:
+ val = MIIM_RTL8211E_CTRL_DELAY;
+ break;
Re: [RFC 01/22] part: call part_init() in blk_get_device_by_str() only for MMC
On Tue, Oct 12, 2021 at 03:30:26PM +0200, Heinrich Schuchardt wrote: > > > On 10/12/21 05:26, AKASHI Takahiro wrote: > > Simon, Heinrich, > > > > On Mon, Oct 11, 2021 at 10:14:02AM -0600, Simon Glass wrote: > > > Hi Heinrich, > > > > > > On Mon, 11 Oct 2021 at 09:09, Heinrich Schuchardt > > > wrote: > > > > > > > > > > > > > > > > On 10/11/21 16:32, Simon Glass wrote: > > > > > Hi Heinrich, > > > > > > > > > > On Mon, 11 Oct 2021 at 04:07, Heinrich Schuchardt > > > > > wrote: > > > > > > > > > > > > > > > > > > > > > > > > On 10/1/21 13:48, Peter Robinson wrote: > > > > > > > On Fri, Oct 1, 2021 at 6:03 AM AKASHI Takahiro > > > > > > > wrote: > > > > > > > > > > > > > > > > In blk_get_device_by_str(), the comment says: "Updates the > > > > > > > > partition table > > > > > > > > for the specified hw partition." > > > > > > > > Since hw partition is supported only on MMC, it makes no sense > > > > > > > > to do so > > > > > > > > for other devices. > > > > > > > > > > > > > > Is it not also supported on UFS, and I believe it may also be an > > > > > > > option in the NVME spec too. > > > > > > > > > > > > An NVMe device may expose multiple namespaces. blk_create_devicef() > > > > > > is > > > > > > called for each namespace. > > > > > > > > > > > > A SCSI device may have multiple LUNs. blk_create_devicef() is > > > > > > called for > > > > > > each LUN. > > > > > > > > > > > > This is what the tree shown by 'dm tree' with on NVMe namespace and > > > > > > one LUN. > > > > > > > > > > > > Class Index Driver Name > > > > > > - > > > > > > root 0 root_driverroot_driver > > > > > > simple_bus 0 simple_bus |- soc > > > > > > spi1 sifive_spi | |- spi@1005 > > > > > > mmc0 mmc_spi| | `- mmc@0 > > > > > > blk0 mmc_blk| | `- m...@0.blk > > > > > > pci0 pcie_sifive| |- pcie@e > > > > > > pci1 pci_bridge_drv | | `- pci_0:0.0 > > > > > > pci2 pci_bridge_drv | | `- pci_1:0.0 > > > > > > pci5 pci_bridge_drv | ||- pci_2:3.0 > > > > > > ahci 0 ahci_pci | || `- ahci_pci > > > > > > scsi 0 ahci_scsi | || `- ahci_scsi > > > > > > blk2 scsi_blk | ||`- > > > > > > ahci_scsi.id0lun0 > > > > > > pci6 pci_bridge_drv | ||- pci_2:4.0 > > > > > > nvme 0 nvme | || `- nvme#0 > > > > > > blk1 nvme-blk | || `- nvme#0.blk#1 > > > > > > > > > > > > Namespaces and LUNs are modeled as block devices (class = 'blk'). > > > > > > > > > > So multiple block devices per NVMe device? I did not know that was > > > > > supported. > > > > > > > > > > We need a sandbox driver for NVMe as it has no tests at present. Since > > > > > it has no tests, I don't think we can expect people to know how to > > > > > maintain whatever functionality is there. > > > > > > > > NVMe drives with multiple namespaces exist for servers but not for > > > > consumer NVMe drives. > > > > > > > > In QEMU you can define an NVMe device with multiple namespaces. Cf. > > > > https://qemu.readthedocs.io/en/latest/system/devices/nvme.html?highlight=namespace#additional-namespaces > > > > > > > > So for a first glimpse at the handling I suggest to use QEMU. > > > > > > Well that's fine, but every uclass must have a test and a sandbox > > > emulator as well. > > > > Wait, it seems that you're discussing a different thing from my patch. > > > > While I don't know whether NVMe namespaces are a kind of "HW partitions", > > we don't care much here as long as any namespace can be handled simply > > as a normal block device, like scsi LUN's, in terms of U-Boot driver model. > > > > # On the other hand, we have to explicitly switch "hw partitions" > > # with blk_select_hwpart_devnum() on MMC devices even though we use > > # the *same* udevice(blk_desc). > > # See do_mmcrpmb() in cmd/mmc.c > > Each hardware partition should be a block device (class blk) which is > mirrored in the UEFI world by a CTRL() device. Yes, whether it is mirrored or not, a hw partition is to be a separate udevice from its associated raw device. > It is not necessary for > parent device to be a block device. I'm not sure what 'parent device' means here, but I guess that it is the raw MMC device (as a controller handle in UEFI terminology which is set to provide BLOCK_IO_PROTOCOL), isn't it? -Takahiro Akashi > Best regards > > Heinrich > > > > > So I hope that *your* discussion doesn't make any difference to my patch. > > Right? > > > > -Takahiro Akashi > > > > > > > Regards, > > > Simon
RE: [PATCH v4 23/29] pci: layerscape: add official ls1028a binding support
> -Original Message-
> From: Michael Walle
> Sent: 2021年10月5日 16:38
> To: u-boot@lists.denx.de
> Cc: Jagan Teki ; Priyanka Jain
> ; Vladimir Oltean ;
> Tom Rini ; Peter Griffin ;
> Manivannan Sadhasivam ; Michael
> Walle ; Z.Q. Hou
> Subject: [PATCH v4 23/29] pci: layerscape: add official ls1028a binding
> support
>
> The official bindind of the PCIe controller of the ls1028a has the following
> compatible string:
> compatible = "fsl,ls1028a-pcie";
>
> Additionally, the resource names and count are different. Update the driver
> to support this binding and change the entry in the ls1028a device tree.
>
> Cc: Hou Zhiqiang
> Signed-off-by: Michael Walle
> ---
> arch/arm/dts/fsl-ls1028a.dtsi| 20 +--
> drivers/pci/pcie_layerscape_rc.c | 61 +++-
> 2 files changed, 53 insertions(+), 28 deletions(-)
>
> diff --git a/arch/arm/dts/fsl-ls1028a.dtsi b/arch/arm/dts/fsl-ls1028a.dtsi
> index cc055e65e5..435b965d00 100644
> --- a/arch/arm/dts/fsl-ls1028a.dtsi
> +++ b/arch/arm/dts/fsl-ls1028a.dtsi
> @@ -344,12 +344,10 @@
> };
>
> pcie1: pcie@340 {
> - compatible = "fsl,ls-pcie", "fsl,ls1028-pcie",
> "snps,dw-pcie";
> - reg = <0x00 0x0340 0x0 0x8
> -0x00 0x0348 0x0 0x4 /* lut registers */
> -0x00 0x034c 0x0 0x4 /* pf controls
> registers */
> -0x80 0x 0x0 0x2>; /* configuration
> space */
> - reg-names = "dbi", "lut", "ctrl", "config";
> + compatible = "fsl,ls1028a-pcie";
> + reg = <0x00 0x0340 0x0 0x0010>, /* controller
> registers */
> + <0x80 0x 0x0 0x2000>; /* configuration
> space */
> + reg-names = "regs", "config";
> #address-cells = <3>;
> #size-cells = <2>;
> device_type = "pci";
> @@ -360,12 +358,10 @@
> };
>
> pcie2: pcie@350 {
> - compatible = "fsl,ls-pcie", "fsl,ls1028-pcie",
> "snps,dw-pcie";
> - reg = <0x00 0x0350 0x0 0x8
> -0x00 0x0358 0x0 0x4 /* lut registers */
> -0x00 0x035c 0x0 0x4 /* pf controls
> registers */
> -0x88 0x 0x0 0x2>; /* configuration
> space */
> - reg-names = "dbi", "lut", "ctrl", "config";
> + compatible = "fsl,ls1028a-pcie";
> + reg = <0x00 0x0350 0x0 0x0010>, /* controller
> registers */
> + <0x88 0x 0x0 0x2000>; /* configuration
> space */
> + reg-names = "regs", "config";
> #address-cells = <3>;
> #size-cells = <2>;
> device_type = "pci";
> diff --git a/drivers/pci/pcie_layerscape_rc.c
> b/drivers/pci/pcie_layerscape_rc.c
> index f50d6ef653..217b420076 100644
> --- a/drivers/pci/pcie_layerscape_rc.c
> +++ b/drivers/pci/pcie_layerscape_rc.c
> @@ -21,6 +21,12 @@
>
> DECLARE_GLOBAL_DATA_PTR;
>
> +struct ls_pcie_drvdata {
> + u32 lut_offset;
> + u32 ctrl_offset;
> + bool big_endian;
The endianness property is better only put in the DT nodes.
The others looks good for me.
Thanks,
Zhiqiang
Re: [PATCH 00/16] fdt: Make OF_BOARD a boolean option
On Wed, Oct 13, 2021 at 09:29:14AM +0800, Bin Meng wrote: > Hi Simon, > > On Wed, Oct 13, 2021 at 9:01 AM Simon Glass wrote: > > > > With Ilias' efforts we have dropped OF_PRIOR_STAGE and OF_HOSTFILE so > > there are only three ways to obtain a devicetree: > > > >- OF_SEPARATE - the normal way, where the devicetree is built and > > appended to U-Boot > >- OF_EMBED - for development purposes, the devicetree is embedded in > > the ELF file (also used for EFI) > >- OF_BOARD - the board figures it out on its own > > > > The last one is currently set up so that no devicetree is needed at all > > in the U-Boot tree. Most boards do provide one, but some don't. Some > > don't even provide instructions on how to boot on the board. > > > > The problems with this approach are documented at [1]. > > > > In practice, OF_BOARD is not really distinct from OF_SEPARATE. Any board > > can obtain its devicetree at runtime, even it is has a devicetree built > > in U-Boot. This is because U-Boot may be a second-stage bootloader and its > > caller may have a better idea about the hardware available in the machine. > > This is the case with a few QEMU boards, for example. > > > > So it makes no sense to have OF_BOARD as a 'choice'. It should be an > > option, available with either OF_SEPARATE or OF_EMBED. > > > > This series makes this change, adding various missing devicetree files > > (and placeholders) to make the build work. > > Adding device trees that are never used sounds like a hack to me. > > For QEMU, device tree is dynamically generated on the fly based on > command line parameters, and the device tree you put in this series > has various hardcoded values which normally do not show up > in hand-written dts files. > > I am not sure I understand the whole point of this. I am also confused and do not like the idea of adding device trees for platforms that are capable of and can / do have a device tree to give us at run time. -- Tom signature.asc Description: PGP signature
Re: [PATCH 00/16] fdt: Make OF_BOARD a boolean option
Hi Simon, On Wed, Oct 13, 2021 at 9:01 AM Simon Glass wrote: > > With Ilias' efforts we have dropped OF_PRIOR_STAGE and OF_HOSTFILE so > there are only three ways to obtain a devicetree: > >- OF_SEPARATE - the normal way, where the devicetree is built and > appended to U-Boot >- OF_EMBED - for development purposes, the devicetree is embedded in > the ELF file (also used for EFI) >- OF_BOARD - the board figures it out on its own > > The last one is currently set up so that no devicetree is needed at all > in the U-Boot tree. Most boards do provide one, but some don't. Some > don't even provide instructions on how to boot on the board. > > The problems with this approach are documented at [1]. > > In practice, OF_BOARD is not really distinct from OF_SEPARATE. Any board > can obtain its devicetree at runtime, even it is has a devicetree built > in U-Boot. This is because U-Boot may be a second-stage bootloader and its > caller may have a better idea about the hardware available in the machine. > This is the case with a few QEMU boards, for example. > > So it makes no sense to have OF_BOARD as a 'choice'. It should be an > option, available with either OF_SEPARATE or OF_EMBED. > > This series makes this change, adding various missing devicetree files > (and placeholders) to make the build work. Adding device trees that are never used sounds like a hack to me. For QEMU, device tree is dynamically generated on the fly based on command line parameters, and the device tree you put in this series has various hardcoded values which normally do not show up in hand-written dts files. I am not sure I understand the whole point of this. > > It also provides a few qemu clean-ups discovered along the way. > > This series is based on Ilias' two series for OF_HOSTFILE and > OF_PRIOR_STAGE removal. > > It is available at u-boot-dm/ofb-working > > [1] > https://patchwork.ozlabs.org/project/uboot/patch/20210919215111.3830278-3-...@chromium.org/ > Regards, Bin
Re: [PATCH 07/16] arm: rpi: Add a devicetree file for rpi_4
Hi Simon
This is making a clean environment go in the wrong direction. I have
witnessed that bus to mmio changed for instance, have seen patches to patch
live u-boot embedded DT because it does not do the work that Videocore
does.
The Videocore handles that properly so why adding this?
Si i would agree to have the file on the documentation directory not on the
dts with the same warning I mentioned earlier
Le mer. 13 oct. 2021 à 03:03, Simon Glass a écrit :
> Add this file, obtained from the Raspbian boot disk, so there is a
> reference devicetree in the U-Boot tree. The same one is used for
> 32- and 64-bit variants.
>
> Note that U-Boot does not normally need this at runtime, since
> CONFIG_OF_BOARD is enabled. The previous firmware stage provides a
> devicetree at runtime.
>
> Signed-off-by: Simon Glass
> ---
>
> arch/arm/dts/Makefile|3 +-
> arch/arm/dts/bcm2711-rpi-4-b.dts | 1958 ++
> configs/rpi_4_32b_defconfig |1 +
> configs/rpi_4_defconfig |1 +
> configs/rpi_arm64_defconfig |1 +
> 5 files changed, 1963 insertions(+), 1 deletion(-)
> create mode 100644 arch/arm/dts/bcm2711-rpi-4-b.dts
>
> diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
> index 52c586f3974..efc01a70bf2 100644
> --- a/arch/arm/dts/Makefile
> +++ b/arch/arm/dts/Makefile
> @@ -1062,7 +1062,8 @@ dtb-$(CONFIG_ARCH_BCM283X) += \
> bcm2837-rpi-3-a-plus.dtb \
> bcm2837-rpi-3-b.dtb \
> bcm2837-rpi-3-b-plus.dtb \
> - bcm2837-rpi-cm3-io3.dtb
> + bcm2837-rpi-cm3-io3.dtb \
> + bcm2711-rpi-4-b.dtb
>
> dtb-$(CONFIG_ARCH_BCM63158) += \
> bcm963158.dtb
> diff --git a/arch/arm/dts/bcm2711-rpi-4-b.dts
> b/arch/arm/dts/bcm2711-rpi-4-b.dts
> new file mode 100644
> index 000..425e9fb91c4
> --- /dev/null
> +++ b/arch/arm/dts/bcm2711-rpi-4-b.dts
> @@ -0,0 +1,1958 @@
> +// SPDX-License-Identifier: GPL-2.0+ OR MIT
> +/*
> + * Sample device tree for rpi_4
> +
> + * Copyright 2021 Google LLC
> + */
> +
> +/dts-v1/;
> +
> +/memreserve/ 0x 0x1000;
> +/ {
> + compatible = "raspberrypi,4-model-b\0brcm,bcm2838\0brcm,bcm2837";
> + model = "Raspberry Pi 4 Model B";
> + interrupt-parent = <0x01>;
> + #address-cells = <0x02>;
> + #size-cells = <0x01>;
> +
> + aliases {
> + serial0 = "/soc/serial@7e215040";
> + serial1 = "/soc/serial@7e201000";
> + audio = "/soc/audio";
> + aux = "/soc/aux@7e215000";
> + sound = "/soc/sound";
> + soc = "/soc";
> + dma = "/soc/dma@7e007000";
> + watchdog = "/soc/watchdog@7e10";
> + random = "/soc/rng@7e104000";
> + mailbox = "/soc/mailbox@7e00b880";
> + gpio = "/soc/gpio@7e20";
> + uart0 = "/soc/serial@7e201000";
> + sdhost = "/soc/mmc@7e202000";
> + mmc0 = "/soc/emmc2@7e34";
> + i2s = "/soc/i2s@7e203000";
> + spi0 = "/soc/spi@7e204000";
> + i2c0 = "/soc/i2c@7e205000";
> + uart1 = "/soc/serial@7e215040";
> + spi1 = "/soc/spi@7e215080";
> + spi2 = "/soc/spi@7e2150c0";
> + mmc = "/soc/mmc@7e30";
> + mmc1 = "/soc/mmcnr@7e30";
> + i2c1 = "/soc/i2c@7e804000";
> + i2c2 = "/soc/i2c@7e805000";
> + usb = "/soc/usb@7e98";
> + leds = "/leds";
> + fb = "/soc/fb";
> + thermal = "/soc/thermal@7d5d2200";
> + axiperf = "/soc/axiperf";
> + mmc2 = "/soc/mmc@7e202000";
> + ethernet0 = "/scb/genet@7d58";
> + };
> +
> + chosen {
> + bootargs = "8250.nr_uarts=1 cma=64M";
> + };
> +
> + thermal-zones {
> +
> + cpu-thermal {
> + polling-delay-passive = <0x00>;
> + polling-delay = <0x3e8>;
> + thermal-sensors = <0x02>;
> + coefficients = <0xfe19 0x641b8>;
> + phandle = <0x2f>;
> +
> + cooling-maps {
> + };
> + };
> + };
> +
> + soc {
> + compatible = "simple-bus";
> + #address-cells = <0x01>;
> + #size-cells = <0x01>;
> + ranges = <0x7e00 0x00 0xfe00 0x180
> + 0x7c00 0x00 0xfc00 0x200
> + 0x4000 0x00 0xff80 0x80>;
> + dma-ranges = <0xc000 0x00 0x00 0x3c00>;
> + phandle = <0x30>;
> +
> + txp@7e004000 {
> + compatible = "brcm,bcm2835-txp";
> + reg = <0x7e004000 0x20>;
> + interrupts = <0x00 0x4b 0x04>;
> +
[PATCH 00/16] fdt: Make OF_BOARD a boolean option
With Ilias' efforts we have dropped OF_PRIOR_STAGE and OF_HOSTFILE so there are only three ways to obtain a devicetree: - OF_SEPARATE - the normal way, where the devicetree is built and appended to U-Boot - OF_EMBED - for development purposes, the devicetree is embedded in the ELF file (also used for EFI) - OF_BOARD - the board figures it out on its own The last one is currently set up so that no devicetree is needed at all in the U-Boot tree. Most boards do provide one, but some don't. Some don't even provide instructions on how to boot on the board. The problems with this approach are documented at [1]. In practice, OF_BOARD is not really distinct from OF_SEPARATE. Any board can obtain its devicetree at runtime, even it is has a devicetree built in U-Boot. This is because U-Boot may be a second-stage bootloader and its caller may have a better idea about the hardware available in the machine. This is the case with a few QEMU boards, for example. So it makes no sense to have OF_BOARD as a 'choice'. It should be an option, available with either OF_SEPARATE or OF_EMBED. This series makes this change, adding various missing devicetree files (and placeholders) to make the build work. It also provides a few qemu clean-ups discovered along the way. This series is based on Ilias' two series for OF_HOSTFILE and OF_PRIOR_STAGE removal. It is available at u-boot-dm/ofb-working [1] https://patchwork.ozlabs.org/project/uboot/patch/20210919215111.3830278-3-...@chromium.org/ Simon Glass (16): arm: qemu: Mention -nographic in the docs arm: qemu: Explain how to extract the generate devicetree riscv: qemu: Explain how to extract the generate devicetree arm: qemu: Add a devicetree file for qemu_arm arm: qemu: Add a devicetree file for qemu_arm64 riscv: qemu: Add devicetree files for qemu_riscv32/64 arm: rpi: Add a devicetree file for rpi_4 arm: vexpress: Add a devicetree file for juno arm: xenguest_arm64: Add a fake devicetree file arm: octeontx: Add a fake devicetree file arm: xilinx_versal_virt: Add a devicetree file arm: bcm7xxx: Add a devicetree file arm: qemu-ppce500: Add a devicetree file arm: highbank: Add a fake devicetree file fdt: Make OF_BOARD a bool option Drop CONFIG_BINMAN_STANDALONE_FDT Makefile |3 +- arch/arm/dts/Makefile | 20 +- arch/arm/dts/bcm2711-rpi-4-b.dts | 1958 arch/arm/dts/bcm7xxx.dts | 15 + arch/arm/dts/highbank.dts | 14 + arch/arm/dts/juno-r2.dts | 1038 + arch/arm/dts/octeontx.dts | 14 + arch/arm/dts/qemu-arm.dts | 402 + arch/arm/dts/qemu-arm64.dts| 381 + arch/arm/dts/xenguest-arm64.dts| 15 + arch/arm/dts/xilinx-versal-virt.dts| 307 arch/powerpc/dts/Makefile |1 + arch/powerpc/dts/qemu-ppce500.dts | 264 arch/riscv/dts/Makefile|2 +- arch/riscv/dts/qemu-virt.dts |8 - arch/riscv/dts/qemu-virt32.dts | 217 +++ arch/riscv/dts/qemu-virt64.dts | 217 +++ configs/bcm7260_defconfig |1 + configs/bcm7445_defconfig |1 + configs/highbank_defconfig |2 +- configs/octeontx2_95xx_defconfig |1 + configs/octeontx2_96xx_defconfig |1 + configs/octeontx_81xx_defconfig|1 + configs/octeontx_83xx_defconfig|1 + configs/qemu-ppce500_defconfig |2 + configs/qemu-riscv32_defconfig |1 + configs/qemu-riscv32_smode_defconfig |1 + configs/qemu-riscv32_spl_defconfig |4 +- configs/qemu-riscv64_defconfig |1 + configs/qemu-riscv64_smode_defconfig |1 + configs/qemu-riscv64_spl_defconfig |3 +- configs/qemu_arm64_defconfig |1 + configs/qemu_arm_defconfig |1 + configs/rpi_4_32b_defconfig|1 + configs/rpi_4_defconfig|1 + configs/rpi_arm64_defconfig|1 + configs/vexpress_aemv8a_juno_defconfig |1 + configs/xenguest_arm64_defconfig |1 + configs/xilinx_versal_virt_defconfig |1 + doc/board/emulation/qemu-arm.rst | 19 +- doc/board/emulation/qemu-riscv.rst | 12 + dts/Kconfig| 27 +- tools/binman/binman.rst| 20 - 43 files changed, 4922 insertions(+), 61 deletions(-) create mode 100644 arch/arm/dts/bcm2711-rpi-4-b.dts create mode 100644 arch/arm/dts/bcm7xxx.dts create mode 100644 arch/arm/dts/highbank.dts create mode 100644 arch/arm/dts/juno-r2.dts create mode 100644 arch/arm/dts/octeontx.dts create mode 100644 arch/arm/dts/qemu-arm.dts create mode 100644 arch/arm/dts/qemu-arm64.dts create mode 100644 arch/arm/dts/xenguest-arm64.dts create mode 100644 arch/arm/dts/xilinx-versal-virt.dts create mode 100644 arch/powerpc/dts/qemu-ppce50
i.mx7ulp u-boot image flashing to SD card - Doesn't use the new image from SD card.
Hello imx7 developers, I have an i.mx7ulp evk board and have been chasing an issue that prevents me from using my own u-boot image flashed to the SD card to boot the board. The basic steps I followed are 1. build u-boot image using mx7ulp_evk_defconfig and I get u-boot-dtb.imx. I am using NXP's 5.4.x GA release. But would like to use the latest from upstream tree as well. So your response can be based on upstream version. 2. SD card formatting. create 2 partitions using fdisk command. u-boot image is at the start of partition 1 as per available information. So partition 1 starts with first section at 20480 and last at 1024000. Partition 2 at 1228800. 3. For now I just want to boot with u-boot only and not to Linux. So I program u-boot image using dd command as sudo dd if=u-boot-dtb.imx of=/dev/sde1 bs=1k seek=1 conv=fsync where u-boot-dtb.imx is my u-boot image from step 1. /dev/sde1 is device for the first partition >sudo dd if=u-boot-dtb.imx of=/dev/sde1 bs=1k seek=1 conv=fsync [sudo] password for sandc: 495+0 records in 495+0 records out 506880 bytes (507 kB, 495 KiB) copied, 0.127887 s, 4.0 MB/s sandc@sandc-VirtualBox:~/git/uboot-imx (imx_v2020.04_5.4.70_2.3.0)$ sync 4. Eject the sd card and boot i.mx7ulp evk with this SD card. Unfortunately the console shows the old image U-Boot 2020.04-5.4.47-2.2.0+gffc3fbe7e5 (Sep 11 2020 - 19:56:06 +) Have anyone seen similar issue and have clue on what is going on. Thanks for your feedback. Thanks Murali Karicheri NOTICE OF CONFIDENTIALITY: This message may contain information that is considered confidential and which may be prohibited from disclosure under applicable law or by contractual agreement. The information is intended solely for the use of the individual or entity named above. If you are not the intended recipient, you are hereby notified that any disclosure, copying, distribution or use of the information contained in or attached to this message is strictly prohibited. If you have received this email transmission in error, please notify the sender by replying to this email and then delete it from your system.
Re: [RFC 07/22] dm: blk: add UCLASS_PARTITION
On Tue, Oct 12, 2021 at 11:14:17AM -0400, Tom Rini wrote:
> On Mon, Oct 11, 2021 at 10:14:00AM -0600, Simon Glass wrote:
> > Hi Heinrich,
> >
> > On Mon, 11 Oct 2021 at 09:02, Heinrich Schuchardt
> > wrote:
> > >
> > >
> > >
> > > On 10/11/21 16:54, Simon Glass wrote:
> > > > Hi Takahiro,
> > > >
> > > > On Sun, 10 Oct 2021 at 20:29, AKASHI Takahiro
> > > > wrote:
> > > >>
> > > >> Heinrich,
> > > >>
> > > >> On Fri, Oct 08, 2021 at 10:23:52AM +0200, Heinrich Schuchardt wrote:
> > > >>>
> > > >>>
> > > >>> On 10/8/21 02:51, AKASHI Takahiro wrote:
> > > On Mon, Oct 04, 2021 at 12:27:59PM +0900, AKASHI Takahiro wrote:
> > > > On Fri, Oct 01, 2021 at 11:30:37AM +0200, Heinrich Schuchardt wrote:
> > > >>
> > > >>
> > > >> On 10/1/21 07:01, AKASHI Takahiro wrote:
> > > >>> UCLASS_PARTITION device will be created as a child node of
> > > >>> UCLASS_BLK device.
> > > >>>
> > > >>> Signed-off-by: AKASHI Takahiro
> > > >>> ---
> > > >>> drivers/block/blk-uclass.c | 111
> > > >>> +
> > > >>> include/blk.h | 9 +++
> > > >>> include/dm/uclass-id.h | 1 +
> > > >>> 3 files changed, 121 insertions(+)
> > > >>>
> > > >>> diff --git a/drivers/block/blk-uclass.c
> > > >>> b/drivers/block/blk-uclass.c
> > > >>> index 83682dcc181a..dd7f3c0fe31e 100644
> > > >>> --- a/drivers/block/blk-uclass.c
> > > >>> +++ b/drivers/block/blk-uclass.c
> > > >>> @@ -12,6 +12,7 @@
> > > >>> #include
> > > >>> #include
> > > >>> #include
> > > >>> +#include
> > > >>> #include
> > > >>> #include
> > > >>> #include
> > > >>> @@ -695,6 +696,44 @@ int blk_unbind_all(int if_type)
> > > >>>return 0;
> > > >>> }
> > > >>>
> > > >>> +int blk_create_partitions(struct udevice *parent)
> > > >>> +{
> > > >>> + int part, count;
> > > >>> + struct blk_desc *desc = dev_get_uclass_plat(parent);
> > > >>> + struct disk_partition info;
> > > >>> + struct disk_part *part_data;
> > > >>> + char devname[32];
> > > >>> + struct udevice *dev;
> > > >>> + int ret;
> > > >>> +
> > > >>> + if (!CONFIG_IS_ENABLED(PARTITIONS) ||
> > > >>> + !CONFIG_IS_ENABLED(HAVE_BLOCK_DEVICE))
> > > >>> + return 0;
> > > >>> +
> > > >>> + /* Add devices for each partition */
> > > >>> + for (count = 0, part = 1; part <= MAX_SEARCH_PARTITIONS;
> > > >>> part++) {
> > > >>> + if (part_get_info(desc, part, &info))
> > > >>> + continue;
> > > >>> + snprintf(devname, sizeof(devname), "%s:%d",
> > > >>> parent->name,
> > > >>> + part);
> > > >>> +
> > > >>> + ret = device_bind_driver(parent, "blk_partition",
> > > >>> + strdup(devname), &dev);
> > > >>> + if (ret)
> > > >>> + return ret;
> > > >>> +
> > > >>> + part_data = dev_get_uclass_plat(dev);
> > > >>> + part_data->partnum = part;
> > > >>> + part_data->gpt_part_info = info;
> > > >>> + count++;
> > > >>> +
> > > >>> + device_probe(dev);
> > > >>> + }
> > > >>> + debug("%s: %d partitions found in %s\n", __func__, count,
> > > >>> parent->name);
> > > >>> +
> > > >>> + return 0;
> > > >>> +}
> > > >>> +
> > > >>> static int blk_post_probe(struct udevice *dev)
> > > >>> {
> > > >>>if (IS_ENABLED(CONFIG_PARTITIONS) &&
> > > >>> @@ -713,3 +752,75 @@ UCLASS_DRIVER(blk) = {
> > > >>>.post_probe = blk_post_probe,
> > > >>>.per_device_plat_auto = sizeof(struct blk_desc),
> > > >>> };
> > > >>> +
> > > >>> +static ulong blk_part_read(struct udevice *dev, lbaint_t start,
> > > >>> +lbaint_t blkcnt, void *buffer)
> > > >>> +{
> > > >>> + struct udevice *parent;
> > > >>> + struct disk_part *part;
> > > >>> + const struct blk_ops *ops;
> > > >>> +
> > > >>> + parent = dev_get_parent(dev);
> > > >>
> > > >> What device type will the parent have if it is a eMMC hardware
> > > >> partition?
> > > >>
> > > >>> + ops = blk_get_ops(parent);
> > > >>> + if (!ops->read)
> > > >>> + return -ENOSYS;
> > > >>> +
> > > >>> + part = dev_get_uclass_plat(dev);
> > > >>
> > > >> You should check that we do not access the block device past the
> > > >> partition end:
> > > >
> > > > Yes, I will fix all of checks.
> > > >
> > > >> struct blk_desc *desc = dev_get_uclass_plat(parent);
> > > >> if ((start + blkcnt) * desc->blksz < part->gpt_part_
Re: [PATCH 10/16] arm: octeontx: Add a fake devicetree file
Hi Simon
It’s even in the title!
The idea of having a DT in dts for ALL boards is not properly rooted. You
may add some sample dts with warnings in the doc tree though.
Le mer. 13 oct. 2021 à 03:04, Simon Glass a écrit :
> Add an empty file to prevent build errors when building with
> CONFIG_OF_SEPARATE enabled.
>
> Unfortunately there are no build instructions in the U-Boot tree to enable
> a real file to be created.
>
> Signed-off-by: Simon Glass
> ---
>
> arch/arm/dts/Makefile| 3 +++
> arch/arm/dts/octeontx.dts| 14 ++
> configs/octeontx2_95xx_defconfig | 1 +
> configs/octeontx2_96xx_defconfig | 1 +
> configs/octeontx_81xx_defconfig | 1 +
> configs/octeontx_83xx_defconfig | 1 +
> 6 files changed, 21 insertions(+)
> create mode 100644 arch/arm/dts/octeontx.dts
>
> diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
> index f09a81eea8e..0fec648dd77 100644
> --- a/arch/arm/dts/Makefile
> +++ b/arch/arm/dts/Makefile
> @@ -1127,6 +1127,9 @@ dtb-$(CONFIG_ARCH_MEDIATEK) += \
>
> dtb-$(CONFIG_XEN) += xenguest-arm64.dtb
>
> +dtb-$(CONFIG_ARCH_OCTEONTX) += octeontx.dtb
> +dtb-$(CONFIG_ARCH_OCTEONTX2) += octeontx.dtb
> +
> dtb-$(CONFIG_TARGET_GE_BX50V3) += \
> imx6q-bx50v3.dtb \
> imx6q-b850v3.dtb \
> diff --git a/arch/arm/dts/octeontx.dts b/arch/arm/dts/octeontx.dts
> new file mode 100644
> index 000..60a15f5df23
> --- /dev/null
> +++ b/arch/arm/dts/octeontx.dts
> @@ -0,0 +1,14 @@
> +// SPDX-License-Identifier: GPL-2.0+
> +/*
> + * Dummy devicetre file for octeontx2 boards
> + *
> + * This is required to make the board build with CONFIG OF_SEPARATE
> + * I could not find any in-tree documentation at all so this is a dummy
> file.
> + *
> + * Copyright 2021 Google LLC
> + */
> +
> +/dts-v1/;
> +
> +/ {
> +};
> diff --git a/configs/octeontx2_95xx_defconfig
> b/configs/octeontx2_95xx_defconfig
> index 6d8457f1d07..fac4c50aec4 100644
> --- a/configs/octeontx2_95xx_defconfig
> +++ b/configs/octeontx2_95xx_defconfig
> @@ -12,6 +12,7 @@ CONFIG_ENV_SECT_SIZE=0x1
> CONFIG_TARGET_OCTEONTX2_95XX=y
> CONFIG_SYS_MALLOC_LEN=0x4008000
> CONFIG_DM_GPIO=y
> +CONFIG_DEFAULT_DEVICE_TREE="octeontx"
> CONFIG_DEBUG_UART_BASE=0x87e02800
> CONFIG_DEBUG_UART_CLOCK=2400
> CONFIG_DEBUG_UART=y
> diff --git a/configs/octeontx2_96xx_defconfig
> b/configs/octeontx2_96xx_defconfig
> index b72caef77d8..db883b5542c 100644
> --- a/configs/octeontx2_96xx_defconfig
> +++ b/configs/octeontx2_96xx_defconfig
> @@ -10,6 +10,7 @@ CONFIG_ENV_SECT_SIZE=0x1
> CONFIG_TARGET_OCTEONTX2_96XX=y
> CONFIG_SYS_MALLOC_LEN=0x4008000
> CONFIG_DM_GPIO=y
> +CONFIG_DEFAULT_DEVICE_TREE="octeontx"
> CONFIG_DEBUG_UART_BASE=0x87e02800
> CONFIG_DEBUG_UART_CLOCK=2400
> CONFIG_DEBUG_UART=y
> diff --git a/configs/octeontx_81xx_defconfig
> b/configs/octeontx_81xx_defconfig
> index 52678d59ff1..8309c29c091 100644
> --- a/configs/octeontx_81xx_defconfig
> +++ b/configs/octeontx_81xx_defconfig
> @@ -12,6 +12,7 @@ CONFIG_ENV_SECT_SIZE=0x1
> CONFIG_TARGET_OCTEONTX_81XX=y
> CONFIG_SYS_MALLOC_LEN=0x4008000
> CONFIG_DM_GPIO=y
> +CONFIG_DEFAULT_DEVICE_TREE="octeontx"
> CONFIG_DEBUG_UART_BASE=0x87e02800
> CONFIG_DEBUG_UART_CLOCK=2400
> CONFIG_DEBUG_UART=y
> diff --git a/configs/octeontx_83xx_defconfig
> b/configs/octeontx_83xx_defconfig
> index 3890c1e97d4..dae1d4880f8 100644
> --- a/configs/octeontx_83xx_defconfig
> +++ b/configs/octeontx_83xx_defconfig
> @@ -10,6 +10,7 @@ CONFIG_ENV_SECT_SIZE=0x1
> CONFIG_TARGET_OCTEONTX_83XX=y
> CONFIG_SYS_MALLOC_LEN=0x4008000
> CONFIG_DM_GPIO=y
> +CONFIG_DEFAULT_DEVICE_TREE="octeontx"
> CONFIG_DEBUG_UART_BASE=0x87e02800
> CONFIG_DEBUG_UART_CLOCK=2400
> CONFIG_DEBUG_UART=y
> --
> 2.33.0.882.g93a45727a2-goog
>
> --
François-Frédéric Ozog | *Director Business Development*
T: +33.67221.6485
francois.o...@linaro.org | Skype: ffozog
Re: [PATCH 02/16] arm: qemu: Explain how to extract the generate devicetree
Le mer. 13 oct. 2021 à 03:02, Simon Glass a écrit : > QEMU currently generates a devicetree for use with U-Boot. Explain how to > obtain it. > > Signed-off-by: Simon Glass > --- > > doc/board/emulation/qemu-arm.rst | 12 > 1 file changed, 12 insertions(+) > > diff --git a/doc/board/emulation/qemu-arm.rst > b/doc/board/emulation/qemu-arm.rst > index 97b6ec64905..b458a398c69 100644 > --- a/doc/board/emulation/qemu-arm.rst > +++ b/doc/board/emulation/qemu-arm.rst > @@ -91,3 +91,15 @@ The debug UART on the ARM virt board uses these > settings:: > CONFIG_DEBUG_UART_PL010=y > CONFIG_DEBUG_UART_BASE=0x900 > CONFIG_DEBUG_UART_CLOCK=0 > + > +Obtaining the QEMU devicetree > +- > + > +QEMU generates its own devicetree to pass to U-Boot and does this by > default. > +You can use `-dtb u-boot.dtb` to force QEMU to use U-Boot's in-tree > version. this is for either Qemu experts or u-boot for Qemu maintainers. Not for the kernel développer as it is recipe for problems: could you add this warning ? > > + > +To obtain the devicetree that qemu generates, add `-machine > dumpdtb=dtb.dtb`, > +e.g.:: > + > +qemu-system-aarch64 -machine virt -nographic -cpu cortex-a57 \ > + -bios u-boot.bin -machine dumpdtb=dtb.dtb > -- > 2.33.0.882.g93a45727a2-goog > > -- François-Frédéric Ozog | *Director Business Development* T: +33.67221.6485 francois.o...@linaro.org | Skype: ffozog
Re: [PATCH 05/16] arm: qemu: Add a devicetree file for qemu_arm64
Hi Simon
The only place I could agree with this file presence is in the
documentation directory, not in dts. It creates a mental picture for the
reader an entirely bad mind scheme around Qemu and DT.
And even in a documentation directory I would place a bug warning: don’t
use this with any kernel , Qemu generates a DT dynamically based on cpu,
memory and devices specified at the command line.
I would also document how to get the DT that Qemu generates (and lkvm btw)
outside any firmware/os provided.
Cheers
FF
Le mer. 13 oct. 2021 à 03:03, Simon Glass a écrit :
> Add this file, generated from qemu, so there is a reference devicetree
> in the U-Boot tree.
>
> Signed-off-by: Simon Glass
> ---
>
> arch/arm/dts/Makefile| 2 +-
> arch/arm/dts/qemu-arm64.dts | 381 +++
> configs/qemu_arm64_defconfig | 1 +
> 3 files changed, 383 insertions(+), 1 deletion(-)
> create mode 100644 arch/arm/dts/qemu-arm64.dts
>
> diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
> index e2fc0cb65fc..52c586f3974 100644
> --- a/arch/arm/dts/Makefile
> +++ b/arch/arm/dts/Makefile
> @@ -1145,7 +1145,7 @@ dtb-$(CONFIG_TARGET_IMX8MM_CL_IOT_GATE) +=
> imx8mm-cl-iot-gate.dtb
>
> dtb-$(CONFIG_TARGET_EA_LPC3250DEVKITV2) += lpc3250-ea3250.dtb
>
> -dtb-$(CONFIG_ARCH_QEMU) += qemu-arm.dtb
> +dtb-$(CONFIG_ARCH_QEMU) += qemu-arm.dtb qemu-arm64.dtb
>
> targets += $(dtb-y)
>
> diff --git a/arch/arm/dts/qemu-arm64.dts b/arch/arm/dts/qemu-arm64.dts
> new file mode 100644
> index 000..7590e49cc84
> --- /dev/null
> +++ b/arch/arm/dts/qemu-arm64.dts
> @@ -0,0 +1,381 @@
> +// SPDX-License-Identifier: GPL-2.0+ OR MIT
> +/*
> + * Sample device tree for qemu_arm64
> +
> + * Copyright 2021 Google LLC
> + */
> +
> +/dts-v1/;
> +
> +/ {
> + interrupt-parent = <0x8001>;
> + #size-cells = <0x02>;
> + #address-cells = <0x02>;
> + compatible = "linux,dummy-virt";
> +
> + psci {
> + migrate = <0xc405>;
> + cpu_on = <0xc403>;
> + cpu_off = <0x8402>;
> + cpu_suspend = <0xc401>;
> + method = "hvc";
> + compatible = "arm,psci-0.2\0arm,psci";
> + };
> +
> + memory@4000 {
> + reg = <0x00 0x4000 0x00 0x800>;
> + device_type = "memory";
> + };
> +
> + platform@c00 {
> + interrupt-parent = <0x8001>;
> + ranges = <0x00 0x00 0xc00 0x200>;
> + #address-cells = <0x01>;
> + #size-cells = <0x01>;
> + compatible = "qemu,platform\0simple-bus";
> + };
> +
> + fw-cfg@902 {
> + dma-coherent;
> + reg = <0x00 0x902 0x00 0x18>;
> + compatible = "qemu,fw-cfg-mmio";
> + };
> +
> + virtio_mmio@a00 {
> + dma-coherent;
> + interrupts = <0x00 0x10 0x01>;
> + reg = <0x00 0xa00 0x00 0x200>;
> + compatible = "virtio,mmio";
> + };
> +
> + virtio_mmio@a000200 {
> + dma-coherent;
> + interrupts = <0x00 0x11 0x01>;
> + reg = <0x00 0xa000200 0x00 0x200>;
> + compatible = "virtio,mmio";
> + };
> +
> + virtio_mmio@a000400 {
> + dma-coherent;
> + interrupts = <0x00 0x12 0x01>;
> + reg = <0x00 0xa000400 0x00 0x200>;
> + compatible = "virtio,mmio";
> + };
> +
> + virtio_mmio@a000600 {
> + dma-coherent;
> + interrupts = <0x00 0x13 0x01>;
> + reg = <0x00 0xa000600 0x00 0x200>;
> + compatible = "virtio,mmio";
> + };
> +
> + virtio_mmio@a000800 {
> + dma-coherent;
> + interrupts = <0x00 0x14 0x01>;
> + reg = <0x00 0xa000800 0x00 0x200>;
> + compatible = "virtio,mmio";
> + };
> +
> + virtio_mmio@a000a00 {
> + dma-coherent;
> + interrupts = <0x00 0x15 0x01>;
> + reg = <0x00 0xa000a00 0x00 0x200>;
> + compatible = "virtio,mmio";
> + };
> +
> + virtio_mmio@a000c00 {
> + dma-coherent;
> + interrupts = <0x00 0x16 0x01>;
> + reg = <0x00 0xa000c00 0x00 0x200>;
> + compatible = "virtio,mmio";
> + };
> +
> + virtio_mmio@a000e00 {
> + dma-coherent;
> + interrupts = <0x00 0x17 0x01>;
> + reg = <0x00 0xa000e00 0x00 0x200>;
> + compatible = "virtio,mmio";
> + };
> +
> + virtio_mmio@a001000 {
> + dma-coherent;
> + interrupts = <0x00 0x18 0x01>;
> + reg = <0x00 0xa001000 0x00 0x200>;
> + compatible = "virtio,mmio";
> + };
> +
> + virtio_mmio@a001200 {
> + dma-coherent;
> + i
[PATCH 16/16] Drop CONFIG_BINMAN_STANDALONE_FDT
This was added as a hack to work around not having an in-tree devicetree. Now that this is fixed it is not needed. Drop it. Signed-off-by: Simon Glass --- Makefile| 3 +-- dts/Kconfig | 18 -- tools/binman/binman.rst | 20 3 files changed, 1 insertion(+), 40 deletions(-) diff --git a/Makefile b/Makefile index 94c4fd548b4..c20aaf73710 100644 --- a/Makefile +++ b/Makefile @@ -939,7 +939,6 @@ endif endif INPUTS-$(CONFIG_TPL) += tpl/u-boot-tpl.bin INPUTS-$(CONFIG_OF_SEPARATE) += u-boot.dtb -INPUTS-$(CONFIG_BINMAN_STANDALONE_FDT) += u-boot.dtb ifeq ($(CONFIG_SPL_FRAMEWORK),y) INPUTS-$(CONFIG_OF_SEPARATE) += u-boot-dtb.img endif @@ -1406,7 +1405,7 @@ u-boot-lzma.img: u-boot.bin.lzma FORCE u-boot-dtb.img u-boot.img u-boot.kwb u-boot.pbl u-boot-ivt.img: \ $(if $(CONFIG_SPL_LOAD_FIT),u-boot-nodtb.bin \ - $(if $(CONFIG_OF_SEPARATE)$(CONFIG_OF_EMBED)$(CONFIG_SANDBOX)$(CONFIG_BINMAN_STANDALONE_FDT),dts/dt.dtb) \ + $(if $(CONFIG_OF_SEPARATE)$(CONFIG_OF_EMBED)$(CONFIG_SANDBOX),dts/dt.dtb) \ ,$(UBOOT_BIN)) FORCE $(call if_changed,mkimage) $(BOARD_SIZE_CHECK) diff --git a/dts/Kconfig b/dts/Kconfig index 6be5710df7d..58356b45e46 100644 --- a/dts/Kconfig +++ b/dts/Kconfig @@ -19,24 +19,6 @@ config BINMAN bool select DTOC -config BINMAN_STANDALONE_FDT - bool - depends on BINMAN - default y if OF_BOARD - help - This option tells U-Boot build system that a standalone device tree - source is explicitly required when using binman to package U-Boot. - - This is not necessary in a common scenario where a device tree source - that contains the binman node is provided in the arch//dts - directory for a specific board. Such device tree sources are built for - OF_SEPARATE or OF_EMBED. However for a scenario like the board device - tree blob is not provided in the U-Boot build tree, but fed to U-Boot - in the runtime, e.g.: in the OF_BOARD case that it is passed by - a prior stage bootloader. For such scenario, a standalone device tree - blob containing binman node to describe how to package U-Boot should - be provided explicitly. - menu "Device Tree Control" depends on SUPPORT_OF_CONTROL diff --git a/tools/binman/binman.rst b/tools/binman/binman.rst index 614df541c5a..f90dd3a5e5d 100644 --- a/tools/binman/binman.rst +++ b/tools/binman/binman.rst @@ -232,26 +232,6 @@ You can use other, more specific CONFIG options - see 'Automatic .dtsi inclusion' below. -Using binman with OF_BOARD - - -Normally binman is used with a board configured with OF_SEPARATE or OF_EMBED. -This is a typical scenario where a device tree source that contains the binman -node is provided in the arch//dts directory for a specific board. - -However for a board configured with OF_BOARD, no device tree blob is provided -in the U-Boot build phase hence the binman node information is not available. -In order to support such use case, a new Kconfig option BINMAN_STANDALONE_FDT -is introduced, to tell the build system that a standalone device tree blob -containing binman node is explicitly required. - -Note there is a Kconfig option BINMAN_FDT which enables U-Boot run time to -access information about binman entries, stored in the device tree in a binman -node. Generally speaking, this option makes sense for OF_SEPARATE or OF_EMBED. -For the other OF_CONTROL methods, it's quite possible binman node is not -available as binman is invoked during the build phase, thus this option is not -turned on by default for these OF_CONTROL methods. - Access to binman entry offsets at run time (symbols) -- 2.33.0.882.g93a45727a2-goog
[PATCH 15/16] fdt: Make OF_BOARD a bool option
This should not be a separate option from OF_SEPARATE. It is a run-time option to override the devicetree, even if present. Move the option out of the choice. Disable BINMAN_FDT for a few boards which don't actually use it. Signed-off-by: Simon Glass --- configs/qemu-ppce500_defconfig | 1 + configs/qemu-riscv32_spl_defconfig | 2 ++ configs/qemu-riscv64_spl_defconfig | 1 + dts/Kconfig| 9 + 4 files changed, 9 insertions(+), 4 deletions(-) diff --git a/configs/qemu-ppce500_defconfig b/configs/qemu-ppce500_defconfig index 5bf3e8de37a..66411f73a11 100644 --- a/configs/qemu-ppce500_defconfig +++ b/configs/qemu-ppce500_defconfig @@ -54,4 +54,5 @@ CONFIG_VIRTIO_PCI=y CONFIG_VIRTIO_NET=y CONFIG_VIRTIO_BLK=y CONFIG_ADDR_MAP=y +# CONFIG_BINMAN_FDT is not set CONFIG_PANIC_HANG=y diff --git a/configs/qemu-riscv32_spl_defconfig b/configs/qemu-riscv32_spl_defconfig index 3909c9a15ad..4621afb1a87 100644 --- a/configs/qemu-riscv32_spl_defconfig +++ b/configs/qemu-riscv32_spl_defconfig @@ -6,6 +6,7 @@ CONFIG_DEFAULT_DEVICE_TREE="qemu-virt32" CONFIG_SPL=y CONFIG_TARGET_QEMU_VIRT=y CONFIG_RISCV_SMODE=y +# CONFIG_OF_BOARD_FIXUP is not set CONFIG_DISTRO_DEFAULTS=y CONFIG_SYS_LOAD_ADDR=0x8020 CONFIG_FIT=y @@ -18,3 +19,4 @@ CONFIG_OF_BOARD=y CONFIG_SYS_RELOC_GD_ENV_ADDR=y CONFIG_DM_MTD=y CONFIG_SYSRESET_SBI=y +# CONFIG_BINMAN_FDT is not set diff --git a/configs/qemu-riscv64_spl_defconfig b/configs/qemu-riscv64_spl_defconfig index 34d88da41b0..6f8ff91df9e 100644 --- a/configs/qemu-riscv64_spl_defconfig +++ b/configs/qemu-riscv64_spl_defconfig @@ -19,3 +19,4 @@ CONFIG_OF_BOARD=y CONFIG_SYS_RELOC_GD_ENV_ADDR=y CONFIG_DM_MTD=y CONFIG_SYSRESET_SBI=y +# CONFIG_BINMAN_FDT is not set diff --git a/dts/Kconfig b/dts/Kconfig index 313b9e5d70b..6be5710df7d 100644 --- a/dts/Kconfig +++ b/dts/Kconfig @@ -104,7 +104,6 @@ choice config OF_SEPARATE bool "Separate DTB for DT control" - depends on !SANDBOX help If this option is enabled, the device tree will be built and placed as a separate u-boot.dtb file alongside the U-Boot image. @@ -117,14 +116,16 @@ config OF_EMBED and development only and is not recommended for production devices. Boards in the mainline U-Boot tree should not use it. +endchoice + config OF_BOARD bool "Provided by the board (e.g a previous loader) at runtime" help If this option is enabled, the device tree will be provided by - the board at runtime if the board supports it, instead of being - bundled with the image. + the board at runtime if the board supports it. The device tree bundled + with the image (if any) will be overridden / ignored. -endchoice + A device tree file must be provided in the tree. config DEFAULT_DEVICE_TREE string "Default Device Tree for DT control" -- 2.33.0.882.g93a45727a2-goog
[PATCH 13/16] arm: qemu-ppce500: Add a devicetree file
Add a devicetree file obtained from qemu for this board. This was obtained
with:
qemu-system-ppc64 -machine ppce500 -cpu e6500 -M dumpdtb=dtb.dtb
Signed-off-by: Simon Glass
---
arch/powerpc/dts/Makefile | 1 +
arch/powerpc/dts/qemu-ppce500.dts | 264 ++
configs/qemu-ppce500_defconfig| 1 +
3 files changed, 266 insertions(+)
create mode 100644 arch/powerpc/dts/qemu-ppce500.dts
diff --git a/arch/powerpc/dts/Makefile b/arch/powerpc/dts/Makefile
index ceaa8ce5c82..66d22ae8a45 100644
--- a/arch/powerpc/dts/Makefile
+++ b/arch/powerpc/dts/Makefile
@@ -18,6 +18,7 @@ dtb-$(CONFIG_TARGET_P2041RDB) += p2041rdb.dtb
dtb-$(CONFIG_TARGET_P3041DS) += p3041ds.dtb
dtb-$(CONFIG_TARGET_P4080DS) += p4080ds.dtb
dtb-$(CONFIG_TARGET_P5040DS) += p5040ds.dtb
+dtb-$(CONFIG_TARGET_QEMU_PPCE500) += qemu-ppce500.dtb
dtb-$(CONFIG_TARGET_SOCRATES) += socrates.dtb
dtb-$(CONFIG_TARGET_T1024RDB) += t1024rdb.dtb
dtb-$(CONFIG_TARGET_T1042D4RDB) += t1042d4rdb.dtb
diff --git a/arch/powerpc/dts/qemu-ppce500.dts
b/arch/powerpc/dts/qemu-ppce500.dts
new file mode 100644
index 000..92368e4d731
--- /dev/null
+++ b/arch/powerpc/dts/qemu-ppce500.dts
@@ -0,0 +1,264 @@
+// SPDX-License-Identifier: GPL-2.0+ OR MIT
+/*
+ * Sample device tree for qemu-ppce400
+
+ * Copyright 2021 Google LLC
+ */
+/dts-v1/;
+
+/ {
+ compatible = "fsl,qemu-e500";
+ model = "QEMU ppce500";
+ #size-cells = <0x02>;
+ #address-cells = <0x02>;
+
+ platform@f {
+ interrupt-parent = <0x8003>;
+ ranges = <0x00 0x0f 0x00 0x800>;
+ #address-cells = <0x01>;
+ #size-cells = <0x01>;
+ compatible = "qemu,platform\0simple-bus";
+ };
+
+ pci@fe0008000 {
+ #address-cells = <0x03>;
+ #size-cells = <0x02>;
+ #interrupt-cells = <0x01>;
+ clock-frequency = <0x3f940aa>;
+ reg = <0x0f 0xe0008000 0x00 0x1000>;
+ ranges = <0x200 0x00 0xe000 0x0c
+0x00 0x00 0x2000 0x100
+0x00 0x00 0x0f 0xe100
+0x00 0x1>;
+ fsl,msi = <0x8004>;
+ bus-range = <0x00 0xff>;
+ interrupts = <0x18 0x02>;
+ interrupt-parent = <0x8003>;
+ interrupt-map = <0x800 0x00 0x00 0x01 0x8003 0x02 0x01 0x800
+ 0x00 0x00 0x02 0x8003 0x03 0x01 0x800 0x00
+ 0x00 0x03 0x8003 0x04 0x01 0x800 0x00 0x00
+ 0x04 0x8003 0x01 0x01 0x1000 0x00 0x00 0x01
+ 0x8003 0x03 0x01 0x1000 0x00 0x00 0x02 0x8003
+ 0x04 0x01 0x1000 0x00 0x00 0x03 0x8003 0x01
+ 0x01 0x1000 0x00 0x00 0x04 0x8003 0x02 0x01
+ 0x1800 0x00 0x00 0x01 0x8003 0x04 0x01 0x1800
+ 0x00 0x00 0x02 0x8003 0x01 0x01 0x1800 0x00
+ 0x00 0x03 0x8003 0x02 0x01 0x1800 0x00 0x00
+ 0x04 0x8003 0x03 0x01 0x2000 0x00 0x00 0x01
+ 0x8003 0x01 0x01 0x2000 0x00 0x00 0x02 0x8003
+ 0x02 0x01 0x2000 0x00 0x00 0x03 0x8003 0x03
+ 0x01 0x2000 0x00 0x00 0x04 0x8003 0x04 0x01
+ 0x2800 0x00 0x00 0x01 0x8003 0x02 0x01 0x2800
+ 0x00 0x00 0x02 0x8003 0x03 0x01 0x2800 0x00
+ 0x00 0x03 0x8003 0x04 0x01 0x2800 0x00 0x00
+ 0x04 0x8003 0x01 0x01 0x3000 0x00 0x00 0x01
+ 0x8003 0x03 0x01 0x3000 0x00 0x00 0x02 0x8003
+ 0x04 0x01 0x3000 0x00 0x00 0x03 0x8003 0x01
+ 0x01 0x3000 0x00 0x00 0x04 0x8003 0x02 0x01
+ 0x3800 0x00 0x00 0x01 0x8003 0x04 0x01 0x3800
+ 0x00 0x00 0x02 0x8003 0x01 0x01 0x3800 0x00
+ 0x00 0x03 0x8003 0x02 0x01 0x3800 0x00 0x00
+ 0x04 0x8003 0x03 0x01 0x4000 0x00 0x00 0x01
+ 0x8003 0x01 0x01 0x4000 0x00 0x00 0x02 0x8003
+ 0x02 0x01 0x4000 0x00 0x00 0x03 0x8003 0x03
+ 0x01 0x4000 0x00 0x00 0x04 0x8003 0x04 0x01
+ 0x4800 0x00 0x00 0x01 0x8003 0x02 0x01 0x4800
+ 0x00 0x00 0x02 0x8003 0x03 0x01 0x4800 0x00
+ 0x00 0x03 0x8003 0x04 0x01 0x4800 0x00 0x00
+ 0x04 0x8003 0x01 0x01 0x5000 0x00 0x00 0x01
+ 0x8003 0x03 0x01 0x5000 0x00 0x00 0x02 0x8003
+ 0x04 0x01 0x5000 0x00 0x00 0x03 0x8003 0x01
+ 0x01 0x5000 0x00 0x00 0x04 0x8003 0x02 0x01
+ 0x5800 0x00 0x00 0x01 0x8003 0x04 0x01 0x5800
+ 0x00 0x00 0x02 0x8003 0x01 0x01 0x5800 0x00
+ 0x00 0x03 0x8003 0x02 0x01 0x5800 0x00 0x00
+
[PATCH 14/16] arm: highbank: Add a fake devicetree file
Add an empty file to prevent build errors when building with
CONFIG_OF_SEPARATE enabled.
Unfortunately there are no build instructions in the U-Boot tree to enable
a real file to be created.
Signed-off-by: Simon Glass
---
arch/arm/dts/Makefile | 2 ++
arch/arm/dts/highbank.dts | 14 ++
configs/highbank_defconfig | 2 +-
3 files changed, 17 insertions(+), 1 deletion(-)
create mode 100644 arch/arm/dts/highbank.dts
diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
index ea7a4cf87de..3499966bc23 100644
--- a/arch/arm/dts/Makefile
+++ b/arch/arm/dts/Makefile
@@ -858,6 +858,8 @@ dtb-$(CONFIG_MX7) += imx7d-sdb.dtb \
dtb-$(CONFIG_ARCH_MX7ULP) += imx7ulp-com.dtb \
imx7ulp-evk.dtb
+dtb-$(CONFIG_ARCH_HIGHBANK) += highbank.dtb
+
dtb-$(CONFIG_ARCH_IMX8) += \
fsl-imx8qm-apalis.dtb \
fsl-imx8qm-mek.dtb \
diff --git a/arch/arm/dts/highbank.dts b/arch/arm/dts/highbank.dts
new file mode 100644
index 000..29ac48f5788
--- /dev/null
+++ b/arch/arm/dts/highbank.dts
@@ -0,0 +1,14 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Dummy devicetre file for highbank board
+ *
+ * This is required to make the board build with CONFIG OF_SEPARATE
+ * There appears to be no in-tree documentation about this board at all.
+ *
+ * Copyright 2021 Google LLC
+ */
+
+/dts-v1/;
+
+/ {
+};
diff --git a/configs/highbank_defconfig b/configs/highbank_defconfig
index 43a070e7233..b9d325d391a 100644
--- a/configs/highbank_defconfig
+++ b/configs/highbank_defconfig
@@ -7,6 +7,7 @@ CONFIG_SYS_TEXT_BASE=0x8000
CONFIG_NR_DRAM_BANKS=2
CONFIG_ENV_SIZE=0x2000
CONFIG_SYS_MALLOC_LEN=0x8
+CONFIG_DEFAULT_DEVICE_TREE="highbank"
CONFIG_SYS_BOOTCOUNT_ADDR=0xfff3cf0c
CONFIG_SYS_BOOTCOUNT_SINGLEWORD=y
CONFIG_DISTRO_DEFAULTS=y
@@ -21,7 +22,6 @@ CONFIG_AUTOBOOT_KEYED_CTRLC=y
# CONFIG_DISPLAY_BOARDINFO is not set
CONFIG_MISC_INIT_R=y
# CONFIG_CMD_SETEXPR is not set
-CONFIG_OF_BOARD=y
CONFIG_ENV_IS_IN_NVRAM=y
CONFIG_ENV_ADDR=0xFFF88000
CONFIG_SCSI_AHCI=y
--
2.33.0.882.g93a45727a2-goog
[PATCH 12/16] arm: bcm7xxx: Add a devicetree file
Add a dummy devicetree file for these boards. It seems to be possible to
obtain a real one from another bootloader called 'bolt' but I will leave
this to the maintainer.
Signed-off-by: Simon Glass
---
arch/arm/dts/Makefile | 2 ++
arch/arm/dts/bcm7xxx.dts | 15 +++
configs/bcm7260_defconfig | 1 +
configs/bcm7445_defconfig | 1 +
4 files changed, 19 insertions(+)
create mode 100644 arch/arm/dts/bcm7xxx.dts
diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
index dd6d66af5e6..ea7a4cf87de 100644
--- a/arch/arm/dts/Makefile
+++ b/arch/arm/dts/Makefile
@@ -1077,6 +1077,8 @@ dtb-$(CONFIG_ARCH_BCM6858) += \
dtb-$(CONFIG_TARGET_BCMNS3) += ns3-board.dtb
+dtb-$(CONFIG_ARCH_BCMSTB) += bcm7xxx.dtb
+
dtb-$(CONFIG_ASPEED_AST2500) += ast2500-evb.dtb
dtb-$(CONFIG_ASPEED_AST2600) += ast2600-evb.dtb
diff --git a/arch/arm/dts/bcm7xxx.dts b/arch/arm/dts/bcm7xxx.dts
new file mode 100644
index 000..799cc9caad4
--- /dev/null
+++ b/arch/arm/dts/bcm7xxx.dts
@@ -0,0 +1,15 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Dummy devicetre file for bcm7260 board
+ *
+ * This is required to make the board build with CONFIG OF_SEPARATE
+ * In-tree document explains how to obtain a real devicetree using 'bolt' but
+ * I did not attempt this.
+ *
+ * Copyright 2021 Google LLC
+ */
+
+/dts-v1/;
+
+/ {
+};
diff --git a/configs/bcm7260_defconfig b/configs/bcm7260_defconfig
index 3afb909f712..89b5b01ad76 100644
--- a/configs/bcm7260_defconfig
+++ b/configs/bcm7260_defconfig
@@ -7,6 +7,7 @@ CONFIG_NR_DRAM_BANKS=1
CONFIG_ENV_SIZE=0x1
CONFIG_ENV_OFFSET=0x814800
CONFIG_SYS_MALLOC_LEN=0x280
+CONFIG_DEFAULT_DEVICE_TREE="bcm7xxx"
CONFIG_ENV_OFFSET_REDUND=0x824800
CONFIG_SYS_LOAD_ADDR=0x0200
CONFIG_FIT=y
diff --git a/configs/bcm7445_defconfig b/configs/bcm7445_defconfig
index 3726abd7354..92c1b36185a 100644
--- a/configs/bcm7445_defconfig
+++ b/configs/bcm7445_defconfig
@@ -8,6 +8,7 @@ CONFIG_ENV_SIZE=0x1
CONFIG_ENV_OFFSET=0x1E
CONFIG_ENV_SECT_SIZE=0x1
CONFIG_SYS_MALLOC_LEN=0xa0
+CONFIG_DEFAULT_DEVICE_TREE="bcm7xxx"
CONFIG_ENV_OFFSET_REDUND=0x1F
CONFIG_SYS_LOAD_ADDR=0x0200
CONFIG_FIT=y
--
2.33.0.882.g93a45727a2-goog
[PATCH 11/16] arm: xilinx_versal_virt: Add a devicetree file
Add a devicetree file obtained from qemu for this board. This was obtained
with:
qemu-system-aarch64 -M xlnx-versal-virt -machine dumpdtb=dtb.dtb
Signed-off-by: Simon Glass
---
arch/arm/dts/Makefile| 3 +-
arch/arm/dts/xilinx-versal-virt.dts | 307 +++
configs/xilinx_versal_virt_defconfig | 1 +
3 files changed, 310 insertions(+), 1 deletion(-)
create mode 100644 arch/arm/dts/xilinx-versal-virt.dts
diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
index 0fec648dd77..dd6d66af5e6 100644
--- a/arch/arm/dts/Makefile
+++ b/arch/arm/dts/Makefile
@@ -352,7 +352,8 @@ dtb-$(CONFIG_ARCH_ZYNQMP) += \
dtb-$(CONFIG_ARCH_VERSAL) += \
versal-mini.dtb \
versal-mini-emmc0.dtb \
- versal-mini-emmc1.dtb
+ versal-mini-emmc1.dtb \
+ xilinx-versal-virt.dtb
dtb-$(CONFIG_ARCH_ZYNQMP_R5) += \
zynqmp-r5.dtb
dtb-$(CONFIG_AM33XX) += \
diff --git a/arch/arm/dts/xilinx-versal-virt.dts
b/arch/arm/dts/xilinx-versal-virt.dts
new file mode 100644
index 000..3712af9e7a4
--- /dev/null
+++ b/arch/arm/dts/xilinx-versal-virt.dts
@@ -0,0 +1,307 @@
+// SPDX-License-Identifier: GPL-2.0+ OR MIT
+/*
+ * Sample device tree for versal-virt board
+
+ * Copyright 2021 Google LLC
+ */
+
+/dts-v1/;
+
+/ {
+ compatible = "xlnx-versal-virt";
+ model = "Xilinx Versal Virtual development board";
+ #address-cells = <0x02>;
+ #size-cells = <0x02>;
+ interrupt-parent = <0x8000>;
+
+ memory@0 {
+ reg = <0x00 0x00 0x00 0x800>;
+ device_type = "memory";
+ };
+
+ clk25 {
+ u-boot,dm-pre-reloc;
+ compatible = "fixed-clock";
+ #clock-cells = <0x00>;
+ clock-frequency = <0x17d7840>;
+ phandle = <0x8003>;
+ };
+
+ clk125 {
+ u-boot,dm-pre-reloc;
+ compatible = "fixed-clock";
+ #clock-cells = <0x00>;
+ clock-frequency = <0x7735940>;
+ phandle = <0x8004>;
+ };
+
+ cpus {
+ #address-cells = <0x01>;
+ #size-cells = <0x00>;
+
+ cpu@0 {
+ compatible = "arm,cortex-a72";
+ device_type = "cpu";
+ reg = <0x00>;
+ };
+
+ cpu@1 {
+ compatible = "arm,cortex-a72";
+ device_type = "cpu";
+ reg = <0x01>;
+ };
+ };
+
+ rtc@f12a {
+ compatible = "xlnx,zynqmp-rtc";
+ reg = <0x00 0xf12a 0x00 0x1>;
+ interrupt-names = "alarm\0sec";
+ interrupts = <0x00 0x8e 0x04 0x00 0x8f 0x04>;
+ };
+
+ sdhci@f104 {
+ compatible = "arasan,sdhci-8.9a";
+ reg = <0x00 0xf104 0x00 0x1>;
+ interrupts = <0x00 0x7e 0x04>;
+ clock-names = "clk_xin\0clk_ahb";
+ clocks = <0x8003 0x8003>;
+ };
+
+ sdhci@f105 {
+ compatible = "arasan,sdhci-8.9a";
+ reg = <0x00 0xf105 0x00 0x1>;
+ interrupts = <0x00 0x80 0x04>;
+ clock-names = "clk_xin\0clk_ahb";
+ clocks = <0x8003 0x8003>;
+ };
+
+ usb@ff9d {
+ phandle = <0x8005>;
+ #size-cells = <0x02>;
+ #address-cells = <0x02>;
+ ranges;
+ clocks = <0x8003 0x8004>;
+ clock-names = "bus_clk\0ref_clk";
+ reg = <0x00 0xff9d 0x00 0x1>;
+ compatible = "xlnx,versal-dwc3";
+
+ dwc3@fe20 {
+ maximum-speed = "high-speed";
+ phandle = <0x8006>;
+ snps,mask_phy_reset;
+ snps,refclk_fladj;
+ snps,dis_u3_susphy_quirk;
+ snps,dis_u2_susphy_quirk;
+ phy-names = "usb3-phy";
+ dr_mode = "host";
+ #stream-id-cells = <0x01>;
+ snps,quirk-frame-length-adjustment = <0x20>;
+ interrupts = <0x00 0x16 0x04>;
+ interrupt-names = "dwc_usb3";
+ reg = <0x00 0xfe20 0x00 0x1>;
+ compatible = "snps,dwc3";
+ };
+ };
+
+ dma@ffa8 {
+ compatible = "xlnx,zynqmp-dma-1.0";
+ reg = <0x00 0xffa8 0x00 0x1000>;
+ interrupts = <0x00 0x3c 0x04>;
+ clock-names = "clk_main\0clk_apb";
+ clocks = <0x8003 0x8003>;
+ xlnx,bus-width = <0x40>;
+ };
+
+ dma@ffa9 {
+ compatible = "xlnx,zynqmp-dma-1.0";
+ reg = <0x00 0xffa9 0x00 0x1000>;
+ interrupts = <0x00 0x3d 0x04
[PATCH 10/16] arm: octeontx: Add a fake devicetree file
Add an empty file to prevent build errors when building with
CONFIG_OF_SEPARATE enabled.
Unfortunately there are no build instructions in the U-Boot tree to enable
a real file to be created.
Signed-off-by: Simon Glass
---
arch/arm/dts/Makefile| 3 +++
arch/arm/dts/octeontx.dts| 14 ++
configs/octeontx2_95xx_defconfig | 1 +
configs/octeontx2_96xx_defconfig | 1 +
configs/octeontx_81xx_defconfig | 1 +
configs/octeontx_83xx_defconfig | 1 +
6 files changed, 21 insertions(+)
create mode 100644 arch/arm/dts/octeontx.dts
diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
index f09a81eea8e..0fec648dd77 100644
--- a/arch/arm/dts/Makefile
+++ b/arch/arm/dts/Makefile
@@ -1127,6 +1127,9 @@ dtb-$(CONFIG_ARCH_MEDIATEK) += \
dtb-$(CONFIG_XEN) += xenguest-arm64.dtb
+dtb-$(CONFIG_ARCH_OCTEONTX) += octeontx.dtb
+dtb-$(CONFIG_ARCH_OCTEONTX2) += octeontx.dtb
+
dtb-$(CONFIG_TARGET_GE_BX50V3) += \
imx6q-bx50v3.dtb \
imx6q-b850v3.dtb \
diff --git a/arch/arm/dts/octeontx.dts b/arch/arm/dts/octeontx.dts
new file mode 100644
index 000..60a15f5df23
--- /dev/null
+++ b/arch/arm/dts/octeontx.dts
@@ -0,0 +1,14 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Dummy devicetre file for octeontx2 boards
+ *
+ * This is required to make the board build with CONFIG OF_SEPARATE
+ * I could not find any in-tree documentation at all so this is a dummy file.
+ *
+ * Copyright 2021 Google LLC
+ */
+
+/dts-v1/;
+
+/ {
+};
diff --git a/configs/octeontx2_95xx_defconfig b/configs/octeontx2_95xx_defconfig
index 6d8457f1d07..fac4c50aec4 100644
--- a/configs/octeontx2_95xx_defconfig
+++ b/configs/octeontx2_95xx_defconfig
@@ -12,6 +12,7 @@ CONFIG_ENV_SECT_SIZE=0x1
CONFIG_TARGET_OCTEONTX2_95XX=y
CONFIG_SYS_MALLOC_LEN=0x4008000
CONFIG_DM_GPIO=y
+CONFIG_DEFAULT_DEVICE_TREE="octeontx"
CONFIG_DEBUG_UART_BASE=0x87e02800
CONFIG_DEBUG_UART_CLOCK=2400
CONFIG_DEBUG_UART=y
diff --git a/configs/octeontx2_96xx_defconfig b/configs/octeontx2_96xx_defconfig
index b72caef77d8..db883b5542c 100644
--- a/configs/octeontx2_96xx_defconfig
+++ b/configs/octeontx2_96xx_defconfig
@@ -10,6 +10,7 @@ CONFIG_ENV_SECT_SIZE=0x1
CONFIG_TARGET_OCTEONTX2_96XX=y
CONFIG_SYS_MALLOC_LEN=0x4008000
CONFIG_DM_GPIO=y
+CONFIG_DEFAULT_DEVICE_TREE="octeontx"
CONFIG_DEBUG_UART_BASE=0x87e02800
CONFIG_DEBUG_UART_CLOCK=2400
CONFIG_DEBUG_UART=y
diff --git a/configs/octeontx_81xx_defconfig b/configs/octeontx_81xx_defconfig
index 52678d59ff1..8309c29c091 100644
--- a/configs/octeontx_81xx_defconfig
+++ b/configs/octeontx_81xx_defconfig
@@ -12,6 +12,7 @@ CONFIG_ENV_SECT_SIZE=0x1
CONFIG_TARGET_OCTEONTX_81XX=y
CONFIG_SYS_MALLOC_LEN=0x4008000
CONFIG_DM_GPIO=y
+CONFIG_DEFAULT_DEVICE_TREE="octeontx"
CONFIG_DEBUG_UART_BASE=0x87e02800
CONFIG_DEBUG_UART_CLOCK=2400
CONFIG_DEBUG_UART=y
diff --git a/configs/octeontx_83xx_defconfig b/configs/octeontx_83xx_defconfig
index 3890c1e97d4..dae1d4880f8 100644
--- a/configs/octeontx_83xx_defconfig
+++ b/configs/octeontx_83xx_defconfig
@@ -10,6 +10,7 @@ CONFIG_ENV_SECT_SIZE=0x1
CONFIG_TARGET_OCTEONTX_83XX=y
CONFIG_SYS_MALLOC_LEN=0x4008000
CONFIG_DM_GPIO=y
+CONFIG_DEFAULT_DEVICE_TREE="octeontx"
CONFIG_DEBUG_UART_BASE=0x87e02800
CONFIG_DEBUG_UART_CLOCK=2400
CONFIG_DEBUG_UART=y
--
2.33.0.882.g93a45727a2-goog
[PATCH 09/16] arm: xenguest_arm64: Add a fake devicetree file
Add an empty file to prevent build errors when building with
CONFIG_OF_SEPARATE enabled.
The build instructions in U-Boot do not provide enough detail to build a
useful devicetree, unfortunately.
Signed-off-by: Simon Glass
---
arch/arm/dts/Makefile| 2 ++
arch/arm/dts/xenguest-arm64.dts | 15 +++
configs/xenguest_arm64_defconfig | 1 +
3 files changed, 18 insertions(+)
create mode 100644 arch/arm/dts/xenguest-arm64.dts
diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
index 57f06670b23..f09a81eea8e 100644
--- a/arch/arm/dts/Makefile
+++ b/arch/arm/dts/Makefile
@@ -1125,6 +1125,8 @@ dtb-$(CONFIG_ARCH_MEDIATEK) += \
mt8516-pumpkin.dtb \
mt8518-ap1-emmc.dtb
+dtb-$(CONFIG_XEN) += xenguest-arm64.dtb
+
dtb-$(CONFIG_TARGET_GE_BX50V3) += \
imx6q-bx50v3.dtb \
imx6q-b850v3.dtb \
diff --git a/arch/arm/dts/xenguest-arm64.dts b/arch/arm/dts/xenguest-arm64.dts
new file mode 100644
index 000..52d3b062248
--- /dev/null
+++ b/arch/arm/dts/xenguest-arm64.dts
@@ -0,0 +1,15 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Dummy devicetre file for xenguest_arm64
+ *
+ * This is required to make the board build with CONFIG OF_SEPARATE
+ * Build instructions at xenguest_arm64.rst are inadequate for obtaining a real
+ * devicetree.
+ *
+ * Copyright 2021 Google LLC
+ */
+
+/dts-v1/;
+
+/ {
+};
diff --git a/configs/xenguest_arm64_defconfig b/configs/xenguest_arm64_defconfig
index b72e40a1399..8e32cd63229 100644
--- a/configs/xenguest_arm64_defconfig
+++ b/configs/xenguest_arm64_defconfig
@@ -4,6 +4,7 @@ CONFIG_TARGET_XENGUEST_ARM64=y
CONFIG_SYS_TEXT_BASE=0x4008
CONFIG_SYS_MALLOC_F_LEN=0x2000
CONFIG_SYS_MALLOC_LEN=0x200
+CONFIG_DEFAULT_DEVICE_TREE="xenguest-arm64"
CONFIG_IDENT_STRING=" xenguest"
CONFIG_SYS_LOAD_ADDR=0x4000
CONFIG_BOOTDELAY=10
--
2.33.0.882.g93a45727a2-goog
[PATCH 08/16] arm: vexpress: Add a devicetree file for juno
Add this file, obtained from the Linaro website[1], so there is a
reference file in the U-Boot tree.
Note that U-Boot does not normally need this at runtime, since
CONFIG_OF_BOARD is enabled. The previous firmware stage provides a
devicetree at runtime.
[1] https://releases.linaro.org/android/reference-lcr/juno/7.1-17.05/
Signed-off-by: Simon Glass
---
arch/arm/dts/Makefile |3 +
arch/arm/dts/juno-r2.dts | 1038
configs/vexpress_aemv8a_juno_defconfig |1 +
3 files changed, 1042 insertions(+)
create mode 100644 arch/arm/dts/juno-r2.dts
diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
index efc01a70bf2..57f06670b23 100644
--- a/arch/arm/dts/Makefile
+++ b/arch/arm/dts/Makefile
@@ -1134,7 +1134,10 @@ dtb-$(CONFIG_TARGET_GE_BX50V3) += \
dtb-$(CONFIG_TARGET_GE_B1X5V2) += imx6dl-b1x5v2.dtb
dtb-$(CONFIG_TARGET_MX53PPD) += imx53-ppd.dtb
+# TODO(Linus Walleij ): Should us a single vexpress
+# Kconfig option to build all of these. See examples above.
dtb-$(CONFIG_TARGET_VEXPRESS_CA9X4) += vexpress-v2p-ca9.dtb
+dtb-$(CONFIG_TARGET_VEXPRESS64_JUNO) += juno-r2.dtb
dtb-$(CONFIG_TARGET_TOTAL_COMPUTE) += total_compute.dtb
diff --git a/arch/arm/dts/juno-r2.dts b/arch/arm/dts/juno-r2.dts
new file mode 100644
index 000..5a536d8100e
--- /dev/null
+++ b/arch/arm/dts/juno-r2.dts
@@ -0,0 +1,1038 @@
+// SPDX-License-Identifier: GPL-2.0+ OR MIT
+/*
+ * Sample device tree for juno
+
+ * Copyright 2021 Google LLC
+ */
+
+/dts-v1/;
+
+/ {
+ model = "ARM Juno development board (r2)";
+ compatible = "arm,juno-r2\0arm,juno";
+ interrupt-parent = <0x01>;
+ #address-cells = <0x02>;
+ #size-cells = <0x02>;
+
+ aliases {
+ serial0 = "/uart@7ff8";
+ };
+
+ chosen {
+ stdout-path = "serial0:115200n8";
+ };
+
+ psci {
+ compatible = "arm,psci-0.2";
+ method = "smc";
+ };
+
+ cpus {
+ #address-cells = <0x02>;
+ #size-cells = <0x00>;
+
+ cpu-map {
+
+ cluster0 {
+
+ core0 {
+ cpu = <0x02>;
+ };
+
+ core1 {
+ cpu = <0x03>;
+ };
+ };
+
+ cluster1 {
+
+ core0 {
+ cpu = <0x04>;
+ };
+
+ core1 {
+ cpu = <0x05>;
+ };
+
+ core2 {
+ cpu = <0x06>;
+ };
+
+ core3 {
+ cpu = <0x07>;
+ };
+ };
+ };
+
+ idle-states {
+ entry-method = "arm,psci";
+
+ cpu-sleep-0 {
+ compatible = "arm,idle-state";
+ arm,psci-suspend-param = <0x1>;
+ local-timer-stop;
+ entry-latency-us = <0x12c>;
+ exit-latency-us = <0x4b0>;
+ min-residency-us = <0x7d0>;
+ linux,phandle = <0x0a>;
+ phandle = <0x0a>;
+ };
+
+ cluster-sleep-0 {
+ compatible = "arm,idle-state";
+ arm,psci-suspend-param = <0x101>;
+ local-timer-stop;
+ entry-latency-us = <0x190>;
+ exit-latency-us = <0x4b0>;
+ min-residency-us = <0x9c4>;
+ linux,phandle = <0x0b>;
+ phandle = <0x0b>;
+ };
+ };
+
+ cpu@0 {
+ compatible = "arm,cortex-a72\0arm,armv8";
+ reg = <0x00 0x00>;
+ device_type = "cpu";
+ enable-method = "psci";
+ next-level-cache = <0x08>;
+ clocks = <0x09 0x00>;
+ cpu-idle-states = <0x0a 0x0b>;
+ sched-energy-costs = <0x0c 0x0d>;
+ #cooling-cells = <0x02>;
+ dynamic-power-coefficient = <0x1c2>;
+ linux,phandle = <0x02>;
+ phandle = <0x02>;
+ };
+
+ cpu@1 {
+ compatible = "arm,cortex-a72\0arm,armv8";
+ reg
[PATCH 07/16] arm: rpi: Add a devicetree file for rpi_4
Add this file, obtained from the Raspbian boot disk, so there is a
reference devicetree in the U-Boot tree. The same one is used for
32- and 64-bit variants.
Note that U-Boot does not normally need this at runtime, since
CONFIG_OF_BOARD is enabled. The previous firmware stage provides a
devicetree at runtime.
Signed-off-by: Simon Glass
---
arch/arm/dts/Makefile|3 +-
arch/arm/dts/bcm2711-rpi-4-b.dts | 1958 ++
configs/rpi_4_32b_defconfig |1 +
configs/rpi_4_defconfig |1 +
configs/rpi_arm64_defconfig |1 +
5 files changed, 1963 insertions(+), 1 deletion(-)
create mode 100644 arch/arm/dts/bcm2711-rpi-4-b.dts
diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
index 52c586f3974..efc01a70bf2 100644
--- a/arch/arm/dts/Makefile
+++ b/arch/arm/dts/Makefile
@@ -1062,7 +1062,8 @@ dtb-$(CONFIG_ARCH_BCM283X) += \
bcm2837-rpi-3-a-plus.dtb \
bcm2837-rpi-3-b.dtb \
bcm2837-rpi-3-b-plus.dtb \
- bcm2837-rpi-cm3-io3.dtb
+ bcm2837-rpi-cm3-io3.dtb \
+ bcm2711-rpi-4-b.dtb
dtb-$(CONFIG_ARCH_BCM63158) += \
bcm963158.dtb
diff --git a/arch/arm/dts/bcm2711-rpi-4-b.dts b/arch/arm/dts/bcm2711-rpi-4-b.dts
new file mode 100644
index 000..425e9fb91c4
--- /dev/null
+++ b/arch/arm/dts/bcm2711-rpi-4-b.dts
@@ -0,0 +1,1958 @@
+// SPDX-License-Identifier: GPL-2.0+ OR MIT
+/*
+ * Sample device tree for rpi_4
+
+ * Copyright 2021 Google LLC
+ */
+
+/dts-v1/;
+
+/memreserve/ 0x 0x1000;
+/ {
+ compatible = "raspberrypi,4-model-b\0brcm,bcm2838\0brcm,bcm2837";
+ model = "Raspberry Pi 4 Model B";
+ interrupt-parent = <0x01>;
+ #address-cells = <0x02>;
+ #size-cells = <0x01>;
+
+ aliases {
+ serial0 = "/soc/serial@7e215040";
+ serial1 = "/soc/serial@7e201000";
+ audio = "/soc/audio";
+ aux = "/soc/aux@7e215000";
+ sound = "/soc/sound";
+ soc = "/soc";
+ dma = "/soc/dma@7e007000";
+ watchdog = "/soc/watchdog@7e10";
+ random = "/soc/rng@7e104000";
+ mailbox = "/soc/mailbox@7e00b880";
+ gpio = "/soc/gpio@7e20";
+ uart0 = "/soc/serial@7e201000";
+ sdhost = "/soc/mmc@7e202000";
+ mmc0 = "/soc/emmc2@7e34";
+ i2s = "/soc/i2s@7e203000";
+ spi0 = "/soc/spi@7e204000";
+ i2c0 = "/soc/i2c@7e205000";
+ uart1 = "/soc/serial@7e215040";
+ spi1 = "/soc/spi@7e215080";
+ spi2 = "/soc/spi@7e2150c0";
+ mmc = "/soc/mmc@7e30";
+ mmc1 = "/soc/mmcnr@7e30";
+ i2c1 = "/soc/i2c@7e804000";
+ i2c2 = "/soc/i2c@7e805000";
+ usb = "/soc/usb@7e98";
+ leds = "/leds";
+ fb = "/soc/fb";
+ thermal = "/soc/thermal@7d5d2200";
+ axiperf = "/soc/axiperf";
+ mmc2 = "/soc/mmc@7e202000";
+ ethernet0 = "/scb/genet@7d58";
+ };
+
+ chosen {
+ bootargs = "8250.nr_uarts=1 cma=64M";
+ };
+
+ thermal-zones {
+
+ cpu-thermal {
+ polling-delay-passive = <0x00>;
+ polling-delay = <0x3e8>;
+ thermal-sensors = <0x02>;
+ coefficients = <0xfe19 0x641b8>;
+ phandle = <0x2f>;
+
+ cooling-maps {
+ };
+ };
+ };
+
+ soc {
+ compatible = "simple-bus";
+ #address-cells = <0x01>;
+ #size-cells = <0x01>;
+ ranges = <0x7e00 0x00 0xfe00 0x180
+ 0x7c00 0x00 0xfc00 0x200
+ 0x4000 0x00 0xff80 0x80>;
+ dma-ranges = <0xc000 0x00 0x00 0x3c00>;
+ phandle = <0x30>;
+
+ txp@7e004000 {
+ compatible = "brcm,bcm2835-txp";
+ reg = <0x7e004000 0x20>;
+ interrupts = <0x00 0x4b 0x04>;
+ status = "disabled";
+ phandle = <0x31>;
+ };
+
+ dma@7e007000 {
+ compatible = "brcm,bcm2835-dma";
+ reg = <0x7e007000 0xb00>;
+ interrupts = <0x00 0x50 0x04 0x00 0x51 0x04 0x00 0x52
+ 0x04 0x00 0x53 0x04 0x00 0x54 0x04 0x00
+ 0x55 0x04 0x00 0x56 0x04 0x00 0x57 0x04
+ 0x00 0x57 0x04 0x00 0x58 0x04 0x00 0x58
+ 0x04>;
+ interrupt-names =
"dma0\0dma1\0dma2\0dma3\0dma4\0dma5\0dma6\0dma7\0dma8\0dma9\0dma10";
+ #dma
[PATCH 06/16] riscv: qemu: Add devicetree files for qemu_riscv32/64
Add these files, generated from qemu, so there is a reference devicetree
in the U-Boot tree.
Split the existing qemu-virt into two, since we need a different
devicetree for 32- and 64-bit machines.
Signed-off-by: Simon Glass
---
arch/riscv/dts/Makefile | 2 +-
arch/riscv/dts/qemu-virt.dts | 8 -
arch/riscv/dts/qemu-virt32.dts | 217 +++
arch/riscv/dts/qemu-virt64.dts | 217 +++
configs/qemu-riscv32_defconfig | 1 +
configs/qemu-riscv32_smode_defconfig | 1 +
configs/qemu-riscv32_spl_defconfig | 2 +-
configs/qemu-riscv64_defconfig | 1 +
configs/qemu-riscv64_smode_defconfig | 1 +
configs/qemu-riscv64_spl_defconfig | 2 +-
10 files changed, 441 insertions(+), 11 deletions(-)
delete mode 100644 arch/riscv/dts/qemu-virt.dts
create mode 100644 arch/riscv/dts/qemu-virt32.dts
create mode 100644 arch/riscv/dts/qemu-virt64.dts
diff --git a/arch/riscv/dts/Makefile b/arch/riscv/dts/Makefile
index b6e9166767b..90d3f35e6e3 100644
--- a/arch/riscv/dts/Makefile
+++ b/arch/riscv/dts/Makefile
@@ -2,7 +2,7 @@
dtb-$(CONFIG_TARGET_AX25_AE350) += ae350_32.dtb ae350_64.dtb
dtb-$(CONFIG_TARGET_MICROCHIP_ICICLE) += microchip-mpfs-icicle-kit.dtb
-dtb-$(CONFIG_TARGET_QEMU_VIRT) += qemu-virt.dtb
+dtb-$(CONFIG_TARGET_QEMU_VIRT) += qemu-virt32.dtb qemu-virt64.dtb
dtb-$(CONFIG_TARGET_OPENPITON_RISCV64) += openpiton-riscv64.dtb
dtb-$(CONFIG_TARGET_SIFIVE_UNLEASHED) += hifive-unleashed-a00.dtb
dtb-$(CONFIG_TARGET_SIFIVE_UNMATCHED) += hifive-unmatched-a00.dtb
diff --git a/arch/riscv/dts/qemu-virt.dts b/arch/riscv/dts/qemu-virt.dts
deleted file mode 100644
index fecff542b91..000
--- a/arch/riscv/dts/qemu-virt.dts
+++ /dev/null
@@ -1,8 +0,0 @@
-// SPDX-License-Identifier: GPL-2.0+
-/*
- * Copyright (C) 2021, Bin Meng
- */
-
-/dts-v1/;
-
-#include "binman.dtsi"
diff --git a/arch/riscv/dts/qemu-virt32.dts b/arch/riscv/dts/qemu-virt32.dts
new file mode 100644
index 000..3c449413523
--- /dev/null
+++ b/arch/riscv/dts/qemu-virt32.dts
@@ -0,0 +1,217 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Copyright (C) 2021, Bin Meng
+ */
+
+/dts-v1/;
+
+#include "binman.dtsi"
+
+/ {
+ #address-cells = <0x02>;
+ #size-cells = <0x02>;
+ compatible = "riscv-virtio";
+ model = "riscv-virtio,qemu";
+
+ fw-cfg@1010 {
+ dma-coherent;
+ reg = <0x00 0x1010 0x00 0x18>;
+ compatible = "qemu,fw-cfg-mmio";
+ };
+
+ flash@2000 {
+ bank-width = <0x04>;
+ reg = <0x00 0x2000 0x00 0x200
+ 0x00 0x2200 0x00 0x200>;
+ compatible = "cfi-flash";
+ };
+
+ chosen {
+ bootargs = [00];
+ stdout-path = "/soc/uart@1000";
+ };
+
+ memory@8000 {
+ device_type = "memory";
+ reg = <0x00 0x8000 0x00 0x800>;
+ };
+
+ cpus {
+ #address-cells = <0x01>;
+ #size-cells = <0x00>;
+ timebase-frequency = <0x989680>;
+
+ cpu@0 {
+ phandle = <0x01>;
+ device_type = "cpu";
+ reg = <0x00>;
+ status = "okay";
+ compatible = "riscv";
+ riscv,isa = "rv32imafdcsu";
+ mmu-type = "riscv,sv32";
+
+ interrupt-controller {
+ #interrupt-cells = <0x01>;
+ interrupt-controller;
+ compatible = "riscv,cpu-intc";
+ phandle = <0x02>;
+ };
+ };
+
+ cpu-map {
+
+ cluster0 {
+
+ core0 {
+ cpu = <0x01>;
+ };
+ };
+ };
+ };
+
+ soc {
+ #address-cells = <0x02>;
+ #size-cells = <0x02>;
+ compatible = "simple-bus";
+ ranges;
+
+ rtc@101000 {
+ interrupts = <0x0b>;
+ interrupt-parent = <0x03>;
+ reg = <0x00 0x101000 0x00 0x1000>;
+ compatible = "google,goldfish-rtc";
+ };
+
+ uart@1000 {
+ interrupts = <0x0a>;
+ interrupt-parent = <0x03>;
+ clock-frequency = <0x384000>;
+ reg = <0x00 0x1000 0x00 0x100>;
+ compatible = "ns16550a";
+ };
+
+ poweroff {
+ value = <0x>;
+ offset = <0x00>;
+ regmap = <0x04>;
+ compatible = "syscon
[PATCH 05/16] arm: qemu: Add a devicetree file for qemu_arm64
Add this file, generated from qemu, so there is a reference devicetree
in the U-Boot tree.
Signed-off-by: Simon Glass
---
arch/arm/dts/Makefile| 2 +-
arch/arm/dts/qemu-arm64.dts | 381 +++
configs/qemu_arm64_defconfig | 1 +
3 files changed, 383 insertions(+), 1 deletion(-)
create mode 100644 arch/arm/dts/qemu-arm64.dts
diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
index e2fc0cb65fc..52c586f3974 100644
--- a/arch/arm/dts/Makefile
+++ b/arch/arm/dts/Makefile
@@ -1145,7 +1145,7 @@ dtb-$(CONFIG_TARGET_IMX8MM_CL_IOT_GATE) +=
imx8mm-cl-iot-gate.dtb
dtb-$(CONFIG_TARGET_EA_LPC3250DEVKITV2) += lpc3250-ea3250.dtb
-dtb-$(CONFIG_ARCH_QEMU) += qemu-arm.dtb
+dtb-$(CONFIG_ARCH_QEMU) += qemu-arm.dtb qemu-arm64.dtb
targets += $(dtb-y)
diff --git a/arch/arm/dts/qemu-arm64.dts b/arch/arm/dts/qemu-arm64.dts
new file mode 100644
index 000..7590e49cc84
--- /dev/null
+++ b/arch/arm/dts/qemu-arm64.dts
@@ -0,0 +1,381 @@
+// SPDX-License-Identifier: GPL-2.0+ OR MIT
+/*
+ * Sample device tree for qemu_arm64
+
+ * Copyright 2021 Google LLC
+ */
+
+/dts-v1/;
+
+/ {
+ interrupt-parent = <0x8001>;
+ #size-cells = <0x02>;
+ #address-cells = <0x02>;
+ compatible = "linux,dummy-virt";
+
+ psci {
+ migrate = <0xc405>;
+ cpu_on = <0xc403>;
+ cpu_off = <0x8402>;
+ cpu_suspend = <0xc401>;
+ method = "hvc";
+ compatible = "arm,psci-0.2\0arm,psci";
+ };
+
+ memory@4000 {
+ reg = <0x00 0x4000 0x00 0x800>;
+ device_type = "memory";
+ };
+
+ platform@c00 {
+ interrupt-parent = <0x8001>;
+ ranges = <0x00 0x00 0xc00 0x200>;
+ #address-cells = <0x01>;
+ #size-cells = <0x01>;
+ compatible = "qemu,platform\0simple-bus";
+ };
+
+ fw-cfg@902 {
+ dma-coherent;
+ reg = <0x00 0x902 0x00 0x18>;
+ compatible = "qemu,fw-cfg-mmio";
+ };
+
+ virtio_mmio@a00 {
+ dma-coherent;
+ interrupts = <0x00 0x10 0x01>;
+ reg = <0x00 0xa00 0x00 0x200>;
+ compatible = "virtio,mmio";
+ };
+
+ virtio_mmio@a000200 {
+ dma-coherent;
+ interrupts = <0x00 0x11 0x01>;
+ reg = <0x00 0xa000200 0x00 0x200>;
+ compatible = "virtio,mmio";
+ };
+
+ virtio_mmio@a000400 {
+ dma-coherent;
+ interrupts = <0x00 0x12 0x01>;
+ reg = <0x00 0xa000400 0x00 0x200>;
+ compatible = "virtio,mmio";
+ };
+
+ virtio_mmio@a000600 {
+ dma-coherent;
+ interrupts = <0x00 0x13 0x01>;
+ reg = <0x00 0xa000600 0x00 0x200>;
+ compatible = "virtio,mmio";
+ };
+
+ virtio_mmio@a000800 {
+ dma-coherent;
+ interrupts = <0x00 0x14 0x01>;
+ reg = <0x00 0xa000800 0x00 0x200>;
+ compatible = "virtio,mmio";
+ };
+
+ virtio_mmio@a000a00 {
+ dma-coherent;
+ interrupts = <0x00 0x15 0x01>;
+ reg = <0x00 0xa000a00 0x00 0x200>;
+ compatible = "virtio,mmio";
+ };
+
+ virtio_mmio@a000c00 {
+ dma-coherent;
+ interrupts = <0x00 0x16 0x01>;
+ reg = <0x00 0xa000c00 0x00 0x200>;
+ compatible = "virtio,mmio";
+ };
+
+ virtio_mmio@a000e00 {
+ dma-coherent;
+ interrupts = <0x00 0x17 0x01>;
+ reg = <0x00 0xa000e00 0x00 0x200>;
+ compatible = "virtio,mmio";
+ };
+
+ virtio_mmio@a001000 {
+ dma-coherent;
+ interrupts = <0x00 0x18 0x01>;
+ reg = <0x00 0xa001000 0x00 0x200>;
+ compatible = "virtio,mmio";
+ };
+
+ virtio_mmio@a001200 {
+ dma-coherent;
+ interrupts = <0x00 0x19 0x01>;
+ reg = <0x00 0xa001200 0x00 0x200>;
+ compatible = "virtio,mmio";
+ };
+
+ virtio_mmio@a001400 {
+ dma-coherent;
+ interrupts = <0x00 0x1a 0x01>;
+ reg = <0x00 0xa001400 0x00 0x200>;
+ compatible = "virtio,mmio";
+ };
+
+ virtio_mmio@a001600 {
+ dma-coherent;
+ interrupts = <0x00 0x1b 0x01>;
+ reg = <0x00 0xa001600 0x00 0x200>;
+ compatible = "virtio,mmio";
+ };
+
+ virtio_mmio@a001800 {
+ dma-coherent;
+ interrupts = <0x00 0x1c 0x01>;
+ reg = <0x00 0xa001800 0x00 0x200>;
+ compatible = "virtio,mmio";
+ };
+
+ virtio_mmio@a001a00 {
+ dma-coherent;
+
[PATCH 04/16] arm: qemu: Add a devicetree file for qemu_arm
Add this file, generated from qemu, so there is a reference devicetree
in the U-Boot tree.
Signed-off-by: Simon Glass
---
arch/arm/dts/Makefile | 2 +
arch/arm/dts/qemu-arm.dts | 402 +
configs/qemu_arm_defconfig | 1 +
3 files changed, 405 insertions(+)
create mode 100644 arch/arm/dts/qemu-arm.dts
diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
index b8a382d1539..e2fc0cb65fc 100644
--- a/arch/arm/dts/Makefile
+++ b/arch/arm/dts/Makefile
@@ -1145,6 +1145,8 @@ dtb-$(CONFIG_TARGET_IMX8MM_CL_IOT_GATE) +=
imx8mm-cl-iot-gate.dtb
dtb-$(CONFIG_TARGET_EA_LPC3250DEVKITV2) += lpc3250-ea3250.dtb
+dtb-$(CONFIG_ARCH_QEMU) += qemu-arm.dtb
+
targets += $(dtb-y)
# Add any required device tree compiler flags here
diff --git a/arch/arm/dts/qemu-arm.dts b/arch/arm/dts/qemu-arm.dts
new file mode 100644
index 000..790571a9d9e
--- /dev/null
+++ b/arch/arm/dts/qemu-arm.dts
@@ -0,0 +1,402 @@
+// SPDX-License-Identifier: GPL-2.0+ OR MIT
+/*
+ * Sample device tree for qemu_arm
+
+ * Copyright 2021 Google LLC
+ */
+
+/dts-v1/;
+
+/ {
+ interrupt-parent = <0x8001>;
+ #size-cells = <0x02>;
+ #address-cells = <0x02>;
+ compatible = "linux,dummy-virt";
+
+ psci {
+ migrate = <0x8405>;
+ cpu_on = <0x8403>;
+ cpu_off = <0x8402>;
+ cpu_suspend = <0x8401>;
+ method = "hvc";
+ compatible = "arm,psci-0.2\0arm,psci";
+ };
+
+ memory@4000 {
+ reg = <0x00 0x4000 0x00 0x800>;
+ device_type = "memory";
+ };
+
+ platform@c00 {
+ interrupt-parent = <0x8001>;
+ ranges = <0x00 0x00 0xc00 0x200>;
+ #address-cells = <0x01>;
+ #size-cells = <0x01>;
+ compatible = "qemu,platform\0simple-bus";
+ };
+
+ fw-cfg@902 {
+ dma-coherent;
+ reg = <0x00 0x902 0x00 0x18>;
+ compatible = "qemu,fw-cfg-mmio";
+ };
+
+ virtio_mmio@a00 {
+ dma-coherent;
+ interrupts = <0x00 0x10 0x01>;
+ reg = <0x00 0xa00 0x00 0x200>;
+ compatible = "virtio,mmio";
+ };
+
+ virtio_mmio@a000200 {
+ dma-coherent;
+ interrupts = <0x00 0x11 0x01>;
+ reg = <0x00 0xa000200 0x00 0x200>;
+ compatible = "virtio,mmio";
+ };
+
+ virtio_mmio@a000400 {
+ dma-coherent;
+ interrupts = <0x00 0x12 0x01>;
+ reg = <0x00 0xa000400 0x00 0x200>;
+ compatible = "virtio,mmio";
+ };
+
+ virtio_mmio@a000600 {
+ dma-coherent;
+ interrupts = <0x00 0x13 0x01>;
+ reg = <0x00 0xa000600 0x00 0x200>;
+ compatible = "virtio,mmio";
+ };
+
+ virtio_mmio@a000800 {
+ dma-coherent;
+ interrupts = <0x00 0x14 0x01>;
+ reg = <0x00 0xa000800 0x00 0x200>;
+ compatible = "virtio,mmio";
+ };
+
+ virtio_mmio@a000a00 {
+ dma-coherent;
+ interrupts = <0x00 0x15 0x01>;
+ reg = <0x00 0xa000a00 0x00 0x200>;
+ compatible = "virtio,mmio";
+ };
+
+ virtio_mmio@a000c00 {
+ dma-coherent;
+ interrupts = <0x00 0x16 0x01>;
+ reg = <0x00 0xa000c00 0x00 0x200>;
+ compatible = "virtio,mmio";
+ };
+
+ virtio_mmio@a000e00 {
+ dma-coherent;
+ interrupts = <0x00 0x17 0x01>;
+ reg = <0x00 0xa000e00 0x00 0x200>;
+ compatible = "virtio,mmio";
+ };
+
+ virtio_mmio@a001000 {
+ dma-coherent;
+ interrupts = <0x00 0x18 0x01>;
+ reg = <0x00 0xa001000 0x00 0x200>;
+ compatible = "virtio,mmio";
+ };
+
+ virtio_mmio@a001200 {
+ dma-coherent;
+ interrupts = <0x00 0x19 0x01>;
+ reg = <0x00 0xa001200 0x00 0x200>;
+ compatible = "virtio,mmio";
+ };
+
+ virtio_mmio@a001400 {
+ dma-coherent;
+ interrupts = <0x00 0x1a 0x01>;
+ reg = <0x00 0xa001400 0x00 0x200>;
+ compatible = "virtio,mmio";
+ };
+
+ virtio_mmio@a001600 {
+ dma-coherent;
+ interrupts = <0x00 0x1b 0x01>;
+ reg = <0x00 0xa001600 0x00 0x200>;
+ compatible = "virtio,mmio";
+ };
+
+ virtio_mmio@a001800 {
+ dma-coherent;
+ interrupts = <0x00 0x1c 0x01>;
+ reg = <0x00 0xa001800 0x00 0x200>;
+ compatible = "virtio,mmio";
+ };
+
+ virtio_mmio@a001a00 {
+ dma-coherent;
+ interrupts = <0x00 0x
[PATCH 02/16] arm: qemu: Explain how to extract the generate devicetree
QEMU currently generates a devicetree for use with U-Boot. Explain how to obtain it. Signed-off-by: Simon Glass --- doc/board/emulation/qemu-arm.rst | 12 1 file changed, 12 insertions(+) diff --git a/doc/board/emulation/qemu-arm.rst b/doc/board/emulation/qemu-arm.rst index 97b6ec64905..b458a398c69 100644 --- a/doc/board/emulation/qemu-arm.rst +++ b/doc/board/emulation/qemu-arm.rst @@ -91,3 +91,15 @@ The debug UART on the ARM virt board uses these settings:: CONFIG_DEBUG_UART_PL010=y CONFIG_DEBUG_UART_BASE=0x900 CONFIG_DEBUG_UART_CLOCK=0 + +Obtaining the QEMU devicetree +- + +QEMU generates its own devicetree to pass to U-Boot and does this by default. +You can use `-dtb u-boot.dtb` to force QEMU to use U-Boot's in-tree version. + +To obtain the devicetree that qemu generates, add `-machine dumpdtb=dtb.dtb`, +e.g.:: + +qemu-system-aarch64 -machine virt -nographic -cpu cortex-a57 \ + -bios u-boot.bin -machine dumpdtb=dtb.dtb -- 2.33.0.882.g93a45727a2-goog
[PATCH 03/16] riscv: qemu: Explain how to extract the generate devicetree
QEMU currently generates a devicetree for use with U-Boot. Explain how to obtain it. Signed-off-by: Simon Glass --- doc/board/emulation/qemu-riscv.rst | 12 1 file changed, 12 insertions(+) diff --git a/doc/board/emulation/qemu-riscv.rst b/doc/board/emulation/qemu-riscv.rst index 4b8e104a215..b3cf7085847 100644 --- a/doc/board/emulation/qemu-riscv.rst +++ b/doc/board/emulation/qemu-riscv.rst @@ -113,3 +113,15 @@ An attached disk can be emulated by adding:: -device ide-hd,drive=mydisk,bus=ahci.0 You will have to run 'scsi scan' to use it. + +Obtaining the QEMU devicetree +- + +QEMU generates its own devicetree to pass to U-Boot and does this by default. +You can use `-dtb u-boot.dtb` to force QEMU to use U-Boot's in-tree version. + +To obtain the devicetree that qemu generates, add `-machine dumpdtb=dtb.dtb`, +e.g.:: + +qemu-system-riscv64 -nographic -machine virt -bios u-boot \ + -machine dumpdtb=dtb.dtb -- 2.33.0.882.g93a45727a2-goog
[PATCH 01/16] arm: qemu: Mention -nographic in the docs
Without this option QEMU appears to hang. Add it to avoid confusion. Signed-off-by: Simon Glass --- doc/board/emulation/qemu-arm.rst | 7 --- 1 file changed, 4 insertions(+), 3 deletions(-) diff --git a/doc/board/emulation/qemu-arm.rst b/doc/board/emulation/qemu-arm.rst index 8d7fda10f15..97b6ec64905 100644 --- a/doc/board/emulation/qemu-arm.rst +++ b/doc/board/emulation/qemu-arm.rst @@ -41,14 +41,15 @@ The minimal QEMU command line to get U-Boot up and running is: - For ARM:: -qemu-system-arm -machine virt -bios u-boot.bin +qemu-system-arm -machine virt -nographic -bios u-boot.bin - For AArch64:: -qemu-system-aarch64 -machine virt -cpu cortex-a57 -bios u-boot.bin +qemu-system-aarch64 -machine virt -nographic -cpu cortex-a57 -bios u-boot.bin Note that for some odd reason qemu-system-aarch64 needs to be explicitly -told to use a 64-bit CPU or it will boot in 32-bit mode. +told to use a 64-bit CPU or it will boot in 32-bit mode. The -nographic argument +ensures that output appears on the terminal. Use Ctrl-A X to quit. Additional persistent U-boot environment support can be added as follows: -- 2.33.0.882.g93a45727a2-goog
Re: [resent RFC 17/22] efi_loader: add efi_remove_handle()
On Tue, Oct 12, 2021 at 11:16:03AM +0300, Ilias Apalodimas wrote:
> On Mon, Oct 04, 2021 at 12:44:25PM +0900, AKASHI Takahiro wrote:
> > This function is a counterpart of efi_add_handle() and will be used
> > in order to remove an efi_disk object in a later patch.
> >
> > Signed-off-by: AKASHI Takahiro
> > ---
> > include/efi_loader.h | 2 ++
> > lib/efi_loader/efi_boottime.c | 8
> > 2 files changed, 10 insertions(+)
> >
> > diff --git a/include/efi_loader.h b/include/efi_loader.h
> > index cfbe1fe659ef..50f4119dcdfb 100644
> > --- a/include/efi_loader.h
> > +++ b/include/efi_loader.h
> > @@ -579,6 +579,8 @@ void efi_save_gd(void);
> > void efi_runtime_relocate(ulong offset, struct efi_mem_desc *map);
> > /* Add a new object to the object list. */
> > void efi_add_handle(efi_handle_t obj);
> > +/* Remove a object from the object list. */
> > +void efi_remove_handle(efi_handle_t obj);
> > /* Create handle */
> > efi_status_t efi_create_handle(efi_handle_t *handle);
> > /* Delete handle */
> > diff --git a/lib/efi_loader/efi_boottime.c b/lib/efi_loader/efi_boottime.c
> > index f0283b539e46..b2503b74233b 100644
> > --- a/lib/efi_loader/efi_boottime.c
> > +++ b/lib/efi_loader/efi_boottime.c
> > @@ -503,6 +503,14 @@ void efi_add_handle(efi_handle_t handle)
> > list_add_tail(&handle->link, &efi_obj_list);
> > }
> >
> > +void efi_remove_handle(efi_handle_t handle)
> > +{
> > + if (!handle)
> > + return;
> > +
> > + list_del(&handle->link);
> > +}
> > +
>
> We already have efi_delete_handle(). You can't unconditionally remove a
> handle unless all protocols are removed. Can't you just use the existing
> function?
My intent was to add this function as a counterpart of efi_add_handle()
since not all the handles are dynamically allocated on its own.
As far as my usage in this patch series is concerned, however, it is always
used accompanying efi_remove_all_protocols() and free().
(See efi_disk_delete_xxx() in efi_disk.c)
So, yes we can use efi_delete_handle() instead.
(assuming 'header' is the first member in struct efi_disk_obj.)
-Takahiro Akashi
> Cheers
> /Ilias
> > /**
> > * efi_create_handle() - create handle
> > * @handle: new handle
> > --
> > 2.33.0
> >
[PATCH] clk: fixed_rate: add dummy disable() function
commit 6bf6d81c1112 ("clk: fixed_rate: add dummy enable() function")
implemented .enable, so fixed rate clocks can be used where drivers
might call clk_enable(). Implement the .disable op for the same reason;
some drivers, e.g. USB PHYs, may attempt to disable clocks at runtime.
Signed-off-by: Samuel Holland
---
drivers/clk/clk_fixed_rate.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/clk/clk_fixed_rate.c b/drivers/clk/clk_fixed_rate.c
index e0dc4ab85f..c5a2a42c92 100644
--- a/drivers/clk/clk_fixed_rate.c
+++ b/drivers/clk/clk_fixed_rate.c
@@ -26,6 +26,7 @@ static int dummy_enable(struct clk *clk)
const struct clk_ops clk_fixed_rate_ops = {
.get_rate = clk_fixed_rate_get_rate,
.enable = dummy_enable,
+ .disable = dummy_enable,
};
void clk_fixed_rate_ofdata_to_plat_(struct udevice *dev,
--
2.32.0
Re: [RFC 07/22] block: ide: call device_probe() after scanning
On Tue, Oct 12, 2021 at 08:53:54AM +0300, Ilias Apalodimas wrote:
> On Mon, Oct 11, 2021 at 08:54:13AM -0600, Simon Glass wrote:
> > Hi Takahiro,
> >
> > On Sun, 10 Oct 2021 at 19:43, AKASHI Takahiro
> > wrote:
> > >
> > > On Sun, Oct 10, 2021 at 08:14:13AM -0600, Simon Glass wrote:
> > > > On Thu, 30 Sept 2021 at 23:03, AKASHI Takahiro
> > > > wrote:
> > > > >
> > > > > Every time an ide bus/port is scanned and a new device is detected,
> > > > > we want to call device_probe() as it will give us a chance to run
> > > > > additional
> > > > > post-processings for some purposes.
> > > > >
> > > > > In particular, support for creating partitions on a device will be
> > > > > added.
> > > > >
> > > > > Signed-off-by: AKASHI Takahiro
> > > > > ---
> > > > > drivers/block/ide.c | 6 ++
> > > > > 1 file changed, 6 insertions(+)
> > > > >
> > > >
> > > > Reviewed-by: Simon Glass
> > > >
> > > > I'm starting to wonder if you can create a function that does the
> > > > probe and unbind? Something in the blk interface, perhaps? It would
> > > > reduce the duplicated code and provide a standard way of bringing up a
> > > > new device.
> > >
> > > That is exactly what Ilias suggested but I'm a bit declined to do :)
> > >
> > > Common 'scanning' code looks like:
> > > blk_create_devicef(... , &dev);
> > > desc = dev_get_uclass_data(dev);
> > > initialize some members in desc as well as device-specific info --- (A)
> > > (now dev can be accessible.)
> > > ret = device_probe(dev);
> > > if (ret) {
> > > de-initialize *dev* --- (B)
> > > device_unbind()
> > > }
> > >
> > > Basically (B) is supposed to undo (A) which may or may not exist,
> > > depending on types of block devices.
> > >
> > > So I'm not 100% sure that a combination of device_probe() and
> > > device_unbind()
> > > will fit to all the device types.
> > > (The only cases that I have noticed are fsl_sata.c and sata_sil.c. Both
> > > have their own xxx_unbind_device(), but they simply call device_remove()
> > > and
> > > device_unbind(), though. So no worry?)
> >
> > Yes I agree it would be a very strange function. But at least it would
> > have the benefit of grouping the code together under a particular
> > name, something like blk_back_out_bind(), but that's not a good
> > nameit just feels like this might get refactored in the future and
> > having the code in one place might be handy.
>
> naming is hard! try_device_probe() maybe?
Indeed. A name should come later.
So I will temporarily use blk_probe_or_unbind() :-)
-Takahiro Akashi
> Cheers
> /Ilias
> >
> > Regards,
> > Simon
[PATCH] tools: mksunxiboot: Use sunxi_image header directly
When adding eGON support to mkimage, the struct boot_file_head definition was moved to its own header. This is the only thing mksunxiboot needed out of asm/arch/spl.h. Clean up the relative include by switching to new header. Signed-off-by: Samuel Holland --- We switched from using mksunxiboot to mkimage in January, so maybe it is about time to consider dropping this tool? tools/mksunxiboot.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/tools/mksunxiboot.c b/tools/mksunxiboot.c index a18c9d98bc..becc36565b 100644 --- a/tools/mksunxiboot.c +++ b/tools/mksunxiboot.c @@ -12,10 +12,10 @@ #include #include #include +#include #include #include #include "imagetool.h" -#include "../arch/arm/include/asm/arch-sunxi/spl.h" #define STAMP_VALUE 0x5F0A6C39 -- 2.32.0
[PATCH] mkimage: sunxi_egon: Allow overriding the padding size
Due to a bug in the H3 SoC, where the CPU 0 hotplug flag cannot be
written, resuming CPU 0 requires using the "Super Standby" code path in
the BROM instead of the hotplug path. This path requires jumping to an
eGON image in SRAM.
This resume image, whose single purpose is to jump back to the secure
monitor, only needs to contain a single instruction. Padding the image
to 8 KiB would be wasteful of SRAM. Hook up the -B (block size) option
so users can set the block/padding size.
Signed-off-by: Samuel Holland
---
tools/sunxi_egon.c | 9 ++---
1 file changed, 6 insertions(+), 3 deletions(-)
diff --git a/tools/sunxi_egon.c b/tools/sunxi_egon.c
index a5299eb6a1..d1398c07fb 100644
--- a/tools/sunxi_egon.c
+++ b/tools/sunxi_egon.c
@@ -10,9 +10,10 @@
/*
* NAND requires 8K padding. SD/eMMC gets away with 512 bytes,
- * but let's use the larger padding to cover both.
+ * but let's use the larger padding by default to cover both.
*/
#define PAD_SIZE 8192
+#define PAD_SIZE_MIN 512
static int egon_check_params(struct image_tool_params *params)
{
@@ -114,10 +115,12 @@ static int egon_check_image_type(uint8_t type)
static int egon_vrec_header(struct image_tool_params *params,
struct image_type_params *tparams)
{
+ int pad_size = ALIGN(params->bl_len ?: PAD_SIZE, PAD_SIZE_MIN);
+
tparams->hdr = calloc(sizeof(struct boot_file_head), 1);
- /* Return padding to 8K blocks. */
- return ALIGN(params->file_size, PAD_SIZE) - params->file_size;
+ /* Return padding to complete blocks. */
+ return ALIGN(params->file_size, pad_size) - params->file_size;
}
U_BOOT_IMAGE_TYPE(
--
2.32.0
[PATCH] sunxi: A23/A33/H3: Actually move the secure monitor
commit 1ebfc0c631e3 ("sunxi: A23/A33/H3: Move sun8i secure monitor to
SRAM A2") attempted to move the secure monitor to SRAM A2. But not all
sun8i SoCs have SRAM A2, so a check was put in for SUNXI_SRAM_A2_SIZE to
avoid breaking the other SoCs.
However, because the header providing SUNXI_SRAM_A2_SIZE was not
included, this unintentionally skipped the new definitions on all SoCs.
Fix this by including the right header.
Fixes: 1ebfc0c631e3 ("sunxi: A23/A33/H3: Move sun8i secure monitor to SRAM A2")
Signed-off-by: Samuel Holland
---
include/configs/sun8i.h | 2 ++
1 file changed, 2 insertions(+)
diff --git a/include/configs/sun8i.h b/include/configs/sun8i.h
index 27c9808a49..5636356366 100644
--- a/include/configs/sun8i.h
+++ b/include/configs/sun8i.h
@@ -12,6 +12,8 @@
* A23 specific configuration
*/
+#include
+
#ifdef SUNXI_SRAM_A2_SIZE
/*
* If the SoC has enough SRAM A2, use that for the secure monitor.
--
2.32.0
Re: [RFC 00/22] efi_loader: more tightly integrate UEFI disks to device model
On Tue, Oct 12, 2021 at 05:37:45PM -0600, Simon Glass wrote: > Hi Tom, > > On Tue, 12 Oct 2021 at 15:13, Tom Rini wrote: > > > > On Tue, Oct 12, 2021 at 02:31:15PM -0600, Simon Glass wrote: > > > Hi Tom, > > > > > > On Tue, 12 Oct 2021 at 09:00, Tom Rini wrote: > > > > > > > > On Sun, Oct 10, 2021 at 08:14:00AM -0600, Simon Glass wrote: > > > > > Hi Takahiro, > > > > > > > > > > On Thu, 30 Sept 2021 at 23:02, AKASHI Takahiro > > > > > wrote: > > > > > > > > > > > > The purpose of this RPC is to reignite the discussion about how UEFI > > > > > > subystem would best be integrated into U-Boot device model. > > > > > > In the past, I poposed a couple of patch series, the latest one[1], > > > > > > while Heinrich revealed his idea[2], and the approach taken here is > > > > > > something between them, with a focus on block device handlings. > > > > > > > > > > > > # The code is a PoC and not well tested yet. > > > > > > > > > > > > Disks in UEFI world: > > > > > > > > > > > > In general in UEFI world, accessing to any device is performed > > > > > > through > > > > > > a 'protocol' interface which are installed to (or associated with) > > > > > > the device's > > > > > > UEFI handle (or an opaque pointer to UEFI object data). Protocols > > > > > > are > > > > > > implemented by either the UEFI system itself or UEFI drivers. > > > > > > > > > > > > For block IO's, it is a device which has EFI_BLOCK_IO_PROTOCOL > > > > > > (efi_disk > > > > > > hereafter). Currently, every efi_disk may have one of two origins: > > > > > > a.U-Boot's block devices or related partitions > > > > > > (lib/efi_loader/efi_disk.c) > > > > > > b.UEFI objects which are implemented as a block device by UEFI > > > > > > drivers. > > > > > > (lib/efi_driver/efi_block_device.c) > > > > > > > > > > > > All the efi_diskss as (a) will be enumelated and created only once > > > > > > at UEFI > > > > > > subsystem initialization (efi_disk_register()), which is triggered > > > > > > by > > > > > > first executing one of UEFI-related U-Boot commands, like "bootefi", > > > > > > "setenv -e" or "efidebug". > > > > > > EFI_BLOCK_IO_PROTOCOL is implemented by UEFI system using > > > > > > blk_desc(->ops) > > > > > > in the corresponding udevice(UCLASS_BLK). > > > > > > > > > > > > On the other hand, efi_disk as (b) will be created each time UEFI > > > > > > boot > > > > > > services' connect_controller() is executed in UEFI app which, as a > > > > > > (device) > > > > > > controller, gives the method to access the device's data, > > > > > > ie. EFI_BLOCK_IO_PROTOCOL. > > > > > > > > > > > > >>> more details >>> > > > > > > Internally, connect_controller() search for UEFI driver that can > > > > > > support > > > > > > this controller/protocol, 'efi_block' driver(UCLASS_EFI) in this > > > > > > case, > > > > > > then calls the driver's 'bind' interface, which eventually installs > > > > > > the controller's EFI_BLOCK_IO_PROTOCOL to efi_disk object. > > > > > > 'efi_block' driver also create a corresponding udevice(UCLASS_BLK) > > > > > > for > > > > > > * creating additional partitions efi_disk's, and > > > > > > * supporting a file system (EFI_SIMPLE_FILE_SYSTEM_PROTOCOL) on > > > > > > it. > > > > > > <<< <<< > > > > > > > > > > > > Issues: > > > > > > === > > > > > > 1. While an efi_disk represents a device equally for either a whole > > > > > > disk > > > > > >or a partition in UEFI world, the device model treats only a > > > > > > whole > > > > > >disk as a real block device or udevice(UCLASS_BLK). > > > > > > > > > > > > 2. efi_disk holds and makes use of "blk_desc" data even though > > > > > > blk_desc > > > > > >in plat_data is supposed to be private and not to be accessed > > > > > > outside > > > > > >the device model. > > > > > ># This issue, though, exists for all the implmenetation of U-Boot > > > > > ># file systems as well. > > > > > > > > > > Yes, this was a migration convenience and we should be able to unpick > > > > > it now. > > > > > > > > > > However we still have SPL_BLK so need to consider whether we can drop > > > > > that. > > > > > > > > To be clear here, in that I can hand-wave my way to seeing a use case > > > > for lib/efi_loader/ under SPL, it would not be in a world where we also > > > > still would be supporting the non-DM infrastructure, and is also not a > > > > near-term goal. > > > > > > OK good. Perhaps we should add a migration method for SPL_BLK? It > > > would be good to know where we are in terms of the size stuff. I don't > > > see a lot of boards rushing to use of-platdata, though. > > > > What do you mean? Since we have platforms that need to support 12 or 16 > > KiB of space for SPL, we're not going to enforce SPL_DM. But those > > platforms can / do need to boot from MMC (SD card I think usually). > > > > In terms of platforms that could, but don't, enable SPL_BLK, that's just > > the platforms that disable SPL_BLK today as it d
Re: [RFC 00/22] efi_loader: more tightly integrate UEFI disks to device model
Hi Tom, On Tue, 12 Oct 2021 at 15:13, Tom Rini wrote: > > On Tue, Oct 12, 2021 at 02:31:15PM -0600, Simon Glass wrote: > > Hi Tom, > > > > On Tue, 12 Oct 2021 at 09:00, Tom Rini wrote: > > > > > > On Sun, Oct 10, 2021 at 08:14:00AM -0600, Simon Glass wrote: > > > > Hi Takahiro, > > > > > > > > On Thu, 30 Sept 2021 at 23:02, AKASHI Takahiro > > > > wrote: > > > > > > > > > > The purpose of this RPC is to reignite the discussion about how UEFI > > > > > subystem would best be integrated into U-Boot device model. > > > > > In the past, I poposed a couple of patch series, the latest one[1], > > > > > while Heinrich revealed his idea[2], and the approach taken here is > > > > > something between them, with a focus on block device handlings. > > > > > > > > > > # The code is a PoC and not well tested yet. > > > > > > > > > > Disks in UEFI world: > > > > > > > > > > In general in UEFI world, accessing to any device is performed through > > > > > a 'protocol' interface which are installed to (or associated with) > > > > > the device's > > > > > UEFI handle (or an opaque pointer to UEFI object data). Protocols are > > > > > implemented by either the UEFI system itself or UEFI drivers. > > > > > > > > > > For block IO's, it is a device which has EFI_BLOCK_IO_PROTOCOL > > > > > (efi_disk > > > > > hereafter). Currently, every efi_disk may have one of two origins: > > > > > a.U-Boot's block devices or related partitions > > > > > (lib/efi_loader/efi_disk.c) > > > > > b.UEFI objects which are implemented as a block device by UEFI > > > > > drivers. > > > > > (lib/efi_driver/efi_block_device.c) > > > > > > > > > > All the efi_diskss as (a) will be enumelated and created only once at > > > > > UEFI > > > > > subsystem initialization (efi_disk_register()), which is triggered by > > > > > first executing one of UEFI-related U-Boot commands, like "bootefi", > > > > > "setenv -e" or "efidebug". > > > > > EFI_BLOCK_IO_PROTOCOL is implemented by UEFI system using > > > > > blk_desc(->ops) > > > > > in the corresponding udevice(UCLASS_BLK). > > > > > > > > > > On the other hand, efi_disk as (b) will be created each time UEFI boot > > > > > services' connect_controller() is executed in UEFI app which, as a > > > > > (device) > > > > > controller, gives the method to access the device's data, > > > > > ie. EFI_BLOCK_IO_PROTOCOL. > > > > > > > > > > >>> more details >>> > > > > > Internally, connect_controller() search for UEFI driver that can > > > > > support > > > > > this controller/protocol, 'efi_block' driver(UCLASS_EFI) in this case, > > > > > then calls the driver's 'bind' interface, which eventually installs > > > > > the controller's EFI_BLOCK_IO_PROTOCOL to efi_disk object. > > > > > 'efi_block' driver also create a corresponding udevice(UCLASS_BLK) for > > > > > * creating additional partitions efi_disk's, and > > > > > * supporting a file system (EFI_SIMPLE_FILE_SYSTEM_PROTOCOL) on it. > > > > > <<< <<< > > > > > > > > > > Issues: > > > > > === > > > > > 1. While an efi_disk represents a device equally for either a whole > > > > > disk > > > > >or a partition in UEFI world, the device model treats only a whole > > > > >disk as a real block device or udevice(UCLASS_BLK). > > > > > > > > > > 2. efi_disk holds and makes use of "blk_desc" data even though > > > > > blk_desc > > > > >in plat_data is supposed to be private and not to be accessed > > > > > outside > > > > >the device model. > > > > ># This issue, though, exists for all the implmenetation of U-Boot > > > > ># file systems as well. > > > > > > > > Yes, this was a migration convenience and we should be able to unpick > > > > it now. > > > > > > > > However we still have SPL_BLK so need to consider whether we can drop > > > > that. > > > > > > To be clear here, in that I can hand-wave my way to seeing a use case > > > for lib/efi_loader/ under SPL, it would not be in a world where we also > > > still would be supporting the non-DM infrastructure, and is also not a > > > near-term goal. > > > > OK good. Perhaps we should add a migration method for SPL_BLK? It > > would be good to know where we are in terms of the size stuff. I don't > > see a lot of boards rushing to use of-platdata, though. > > What do you mean? Since we have platforms that need to support 12 or 16 > KiB of space for SPL, we're not going to enforce SPL_DM. But those > platforms can / do need to boot from MMC (SD card I think usually). > > In terms of platforms that could, but don't, enable SPL_BLK, that's just > the platforms that disable SPL_BLK today as it defaults to enabled when > possible. Well I wonder if we can use of-platdata and DM then perhaps some of these will fit. The OMAP platform I sent patches for was close to complete, I think, and I believe that was one of the tightest. Actually I cannot remember what board that was... The overhead is perhaps 7KB though, so maybe not suitable for 16KB. Regards, Simon
Re: [PATCH v6 00/11] board: toradex: verdin-imx8mm: target refresh
Hi Tim
On Tue, 2021-10-12 at 12:46 -0700, Tim Harvey wrote:
> On Sat, Oct 9, 2021 at 1:43 PM Marcel Ziswiler wrote:
> >
> > From: Marcel Ziswiler
> >
> >
> > An assortment of fixes and improvements like an Ethernet PHY
> > configuration fix, DEK blob encapsulation preparation, migration to
> > using binman to pack images, SLEEP_MOCI# enablement, dropping of V1.0
> > hardware support [1], renaming kernel image variable, using preboot
> > for fdtfile evaluation and watchdog pinctrl fix.
> >
> > Note that this series is applied on top of Peng's Makefile fix [2] as
> > otherwise, it may not quite generate all binman artefacts in the right
> > order as discussed here [3].
> >
> > [1] https://developer.toradex.com/verdin-sample-phase-over
> > [2] https://marc.info/?l=u-boot&m=162908373904742
> > [3] https://marc.info/?l=u-boot&m=162945614207220
> >
> > Changes in v6:
> > - New patch re-ordering fdt nodes and properties.
> > - Update commit message as requested by Wolfgang.
> >
> > Changes in v5:
> > - Drop device tree part already done by Marek's patch.
> > - Add another fixes tag as his patch forgot the board code part.
> > - Re-based on top of u-boot-imx, master yet again.
> >
> > Changes in v4:
> > - Add Heiko Schocher's reviewed-by tag.
> > - Fix copyright periods.
> > - Re-based.
> >
> > Changes in v3:
> > - Case fold hex string.
> > - Revert binman part of imx8mm-verdin-u-boot.dtsi to a plain copy from
> > imx8mm-evk and postpone further improvements to after migrating to a
> > common binman config as agreed with Frieder and Simon.
> > - New patch cleaning up include order.
> > - Add Fabio's reviewed-by tag.
> > - Fix patch.
> > - Add missing apalis-imx8 part.
> > - While at it update copyright year resp. period.
> > - Fix closing endif comment.
> >
> > Changes in v2:
> > - Explicitly pass filename to binman when generating binaries as
> > suggested by Heiko.
> > - Use proper intermediate binary u-boot-spl-ddr.bin for imximage as
> > pointed out by Heiko.
> > - Drop first patch ("imx: mkimage_fit_atf: fix legacy image generation")
> > as a similar fix was already refused earlier.
> > - New patch allows booting recent embedded Linux BSPs.
> > - New patch addressing dynamic fdtfile definition.
> > - New patch fixing watchdog pinctrl issue.
> >
> > Igor Opaniuk (1):
> > verdin-imx8mm: use preboot for fdtfile evaluation
> >
> > Marcel Ziswiler (7):
> > imx8m: clean-up kconfig indentation
> > verdin-imx8mm: fix ethernet
> > ARM: dts: imx8mm-verdin: prepare for dek blob encapsulation
> > arm64: dts: imx8mm-verdin-u-boot.dtsi: alphabetically re-order
> > verdin-imx8mm: switch to use binman to pack images
> > verdin-imx8mm: clean-up include order
> > verdin-imx8mm: fix watchdog pinctrl issue
> >
> > Max Krummenacher (2):
> > verdin-imx8mm: enable sleep_moci output
> > verdin-imx8mm: drop support for v1.0 hardware
> >
> > Oleksandr Suvorov (1):
> > include/configs: apalis-imx8/verdin-imx8mm: rename kernel image
> > variable
> >
> > arch/arm/dts/imx8mm-verdin-u-boot.dtsi | 147 +++-
> > arch/arm/dts/imx8mm-verdin.dts | 18 +++
> > arch/arm/mach-imx/imx8m/Kconfig | 21 +--
> > board/toradex/verdin-imx8mm/imximage.cfg | 11 +-
> > board/toradex/verdin-imx8mm/verdin-imx8mm.c | 81 +--
> > configs/verdin-imx8mm_defconfig | 6 +-
> > doc/board/toradex/verdin-imx8mm.rst | 53 ---
> > include/configs/apalis-imx8.h | 6 +-
> > include/configs/verdin-imx8mm.h | 10 +-
> > 9 files changed, 220 insertions(+), 133 deletions(-)
> >
> > --
> > 2.26.2
> >
>
> Marcel,
>
> I've tested your series with mx8mm-venice and did not see any issues.
Note that I have currently several patch series in-flight. I assume you meant
this to go here [1] instead, not?
> Tested-by: Tim Harvey for imx8mm-venice-* boards
>
> Thanks, the common u-boot.dtsi is nice to see!
Thanks!
> I have a couple of patches that have not been picked up by Stefano yet
> due to I believe merge conflicts becuase his imx tree is behind master
> with respect to some of the Kconfig patches. You are likely in the
> same boat.
Yeah, however, with his pulls from Thursday evening imx/master is now based on
commit ea67f467a43 ("Merge
branch '2021-10-06-assorted-improvements'") which is very close to todays
origin/master. So I don't think there
should be any more conflicts if your stuff is re-based either on top of
imx/master or origin/master.
> Stefano, is it best for me to rebase my 'imx8mm_venice: switch to use
> binman to pack images' and 'board: gateworks: venice: add
> imx8mn-gw7902 support' patches on your tree or are you going to be
> merging in origin/master soon?
>
> Best regards,
>
> Tim
[1] https://marc.info/?l=u-boot&m=163372696806292
Cheers
Marcel
Re: [RFC 00/22] efi_loader: more tightly integrate UEFI disks to device model
On Tue, Oct 12, 2021 at 02:31:15PM -0600, Simon Glass wrote: > Hi Tom, > > On Tue, 12 Oct 2021 at 09:00, Tom Rini wrote: > > > > On Sun, Oct 10, 2021 at 08:14:00AM -0600, Simon Glass wrote: > > > Hi Takahiro, > > > > > > On Thu, 30 Sept 2021 at 23:02, AKASHI Takahiro > > > wrote: > > > > > > > > The purpose of this RPC is to reignite the discussion about how UEFI > > > > subystem would best be integrated into U-Boot device model. > > > > In the past, I poposed a couple of patch series, the latest one[1], > > > > while Heinrich revealed his idea[2], and the approach taken here is > > > > something between them, with a focus on block device handlings. > > > > > > > > # The code is a PoC and not well tested yet. > > > > > > > > Disks in UEFI world: > > > > > > > > In general in UEFI world, accessing to any device is performed through > > > > a 'protocol' interface which are installed to (or associated with) the > > > > device's > > > > UEFI handle (or an opaque pointer to UEFI object data). Protocols are > > > > implemented by either the UEFI system itself or UEFI drivers. > > > > > > > > For block IO's, it is a device which has EFI_BLOCK_IO_PROTOCOL (efi_disk > > > > hereafter). Currently, every efi_disk may have one of two origins: > > > > a.U-Boot's block devices or related partitions > > > > (lib/efi_loader/efi_disk.c) > > > > b.UEFI objects which are implemented as a block device by UEFI drivers. > > > > (lib/efi_driver/efi_block_device.c) > > > > > > > > All the efi_diskss as (a) will be enumelated and created only once at > > > > UEFI > > > > subsystem initialization (efi_disk_register()), which is triggered by > > > > first executing one of UEFI-related U-Boot commands, like "bootefi", > > > > "setenv -e" or "efidebug". > > > > EFI_BLOCK_IO_PROTOCOL is implemented by UEFI system using > > > > blk_desc(->ops) > > > > in the corresponding udevice(UCLASS_BLK). > > > > > > > > On the other hand, efi_disk as (b) will be created each time UEFI boot > > > > services' connect_controller() is executed in UEFI app which, as a > > > > (device) > > > > controller, gives the method to access the device's data, > > > > ie. EFI_BLOCK_IO_PROTOCOL. > > > > > > > > >>> more details >>> > > > > Internally, connect_controller() search for UEFI driver that can support > > > > this controller/protocol, 'efi_block' driver(UCLASS_EFI) in this case, > > > > then calls the driver's 'bind' interface, which eventually installs > > > > the controller's EFI_BLOCK_IO_PROTOCOL to efi_disk object. > > > > 'efi_block' driver also create a corresponding udevice(UCLASS_BLK) for > > > > * creating additional partitions efi_disk's, and > > > > * supporting a file system (EFI_SIMPLE_FILE_SYSTEM_PROTOCOL) on it. > > > > <<< <<< > > > > > > > > Issues: > > > > === > > > > 1. While an efi_disk represents a device equally for either a whole disk > > > >or a partition in UEFI world, the device model treats only a whole > > > >disk as a real block device or udevice(UCLASS_BLK). > > > > > > > > 2. efi_disk holds and makes use of "blk_desc" data even though blk_desc > > > >in plat_data is supposed to be private and not to be accessed outside > > > >the device model. > > > ># This issue, though, exists for all the implmenetation of U-Boot > > > ># file systems as well. > > > > > > Yes, this was a migration convenience and we should be able to unpick it > > > now. > > > > > > However we still have SPL_BLK so need to consider whether we can drop > > > that. > > > > To be clear here, in that I can hand-wave my way to seeing a use case > > for lib/efi_loader/ under SPL, it would not be in a world where we also > > still would be supporting the non-DM infrastructure, and is also not a > > near-term goal. > > OK good. Perhaps we should add a migration method for SPL_BLK? It > would be good to know where we are in terms of the size stuff. I don't > see a lot of boards rushing to use of-platdata, though. What do you mean? Since we have platforms that need to support 12 or 16 KiB of space for SPL, we're not going to enforce SPL_DM. But those platforms can / do need to boot from MMC (SD card I think usually). In terms of platforms that could, but don't, enable SPL_BLK, that's just the platforms that disable SPL_BLK today as it defaults to enabled when possible. -- Tom signature.asc Description: PGP signature
Re: [PATCH] distro_boot: Fix bootfile env after calling boot_extlinux
On Tue, Oct 12, 2021 at 02:31:18PM -0600, Simon Glass wrote:
> Hi Tom,
>
> On Tue, 12 Oct 2021 at 13:44, Tom Rini wrote:
> >
> > On Tue, Oct 12, 2021 at 04:55:44PM +0800, Artem Lapkin wrote:
> >
> > > Problem
> > >
> > > PXE cannot boot normally after Sysboot changed the bootfile env (called
> > > from boot_extlinux) from the default "boot.scr.uimg" to
> > > "/boot/extlinux/extlinux.conf".
> > >
> > > In addition, an unbootable extlinux configuration will also make the PXE
> > > boot unbootable, because it will use the incorrect path "/boot/extlinux/"
> > > from the bootfile env.
> > >
> > > Solution
> > >
> > > Save and restore default bootfile env value when boot_extlinux is used.
> > >
> > > Example
> > >
> > > Hit SPACE in 2 seconds to stop autoboot
> > > ... is now current device
> > > Found /boot/extlinux/extlinux.conf
> > > Retrieving file: /boot/extlinux/extlinux.conf
> > > 413 bytes read in 2 ms (201.2 KiB/s)
> > > Skipping Krescue for failure retrieving kernel
> > > SCRIPT FAILED: continuing...
> > > ...
> > > Speed: 1000, full duplex
> > > BOOTP broadcast 1
> > > DHCP client bound to address 192.168.11.151 (8 ms)
> > > Using ethernet@ff3f device
> > > TFTP from server 192.168.11.1; our IP address is 192.168.11.151
> > > Filename '/boot/extlinux/pxelinux.cfg/default'.
> > > Not retrying...
> > >
> > >
> > > Signed-off-by: Artem Lapkin
> > > ---
> > > include/config_distro_bootcmd.h | 2 ++
> > > 1 file changed, 2 insertions(+)
> > >
> > > diff --git a/include/config_distro_bootcmd.h
> > > b/include/config_distro_bootcmd.h
> > > index 3f724aa10f..db3d1b2362 100644
> > > --- a/include/config_distro_bootcmd.h
> > > +++ b/include/config_distro_bootcmd.h
> > > @@ -445,7 +445,9 @@
> > > "${devnum}:${distro_bootpart} " \
> > > "${prefix}${boot_syslinux_conf}; then " \
> > > "echo Found ${prefix}${boot_syslinux_conf}; " \
> > > + "bootfile_bak=${bootfile}; " \
> > > "run boot_extlinux; " \
> > > + "setenv bootfile ${bootfile_bak}; " \
> > > "echo SCRIPT FAILED: continuing...; " \
> > > "fi\0"\
> > > \
> >
> > We've had this kind of problem before, and the answer is that variables
> > should be local, not global in scope. In this case, I see that the way
> > the pxe/sysboot code works is that we have to env_set("..") in one place
> > to env_get("..") in another, so I don't see a way around this.
> >
> > Reviewed-by: Tom Rini
>
> IMO a better approach will be the bootflow implementation. I hope to
> get v2 out early next week.
I'm not sure if the bootflow way of going here would or would not have
the same problem, or perhaps a slightly different problem. At heart
here, "sysboot" calls env_set(...) and then calls in to the pxe code
which does env_get(...). So now I wonder how this would be fixed in
bootflow, since we aren't dealing with the environment directly.
--
Tom
signature.asc
Description: PGP signature
Re: [PATCH] distro_boot: Fix bootfile env after calling boot_extlinux
Hi Tom,
On Tue, 12 Oct 2021 at 13:44, Tom Rini wrote:
>
> On Tue, Oct 12, 2021 at 04:55:44PM +0800, Artem Lapkin wrote:
>
> > Problem
> >
> > PXE cannot boot normally after Sysboot changed the bootfile env (called
> > from boot_extlinux) from the default "boot.scr.uimg" to
> > "/boot/extlinux/extlinux.conf".
> >
> > In addition, an unbootable extlinux configuration will also make the PXE
> > boot unbootable, because it will use the incorrect path "/boot/extlinux/"
> > from the bootfile env.
> >
> > Solution
> >
> > Save and restore default bootfile env value when boot_extlinux is used.
> >
> > Example
> >
> > Hit SPACE in 2 seconds to stop autoboot
> > ... is now current device
> > Found /boot/extlinux/extlinux.conf
> > Retrieving file: /boot/extlinux/extlinux.conf
> > 413 bytes read in 2 ms (201.2 KiB/s)
> > Skipping Krescue for failure retrieving kernel
> > SCRIPT FAILED: continuing...
> > ...
> > Speed: 1000, full duplex
> > BOOTP broadcast 1
> > DHCP client bound to address 192.168.11.151 (8 ms)
> > Using ethernet@ff3f device
> > TFTP from server 192.168.11.1; our IP address is 192.168.11.151
> > Filename '/boot/extlinux/pxelinux.cfg/default'.
> > Not retrying...
> >
> >
> > Signed-off-by: Artem Lapkin
> > ---
> > include/config_distro_bootcmd.h | 2 ++
> > 1 file changed, 2 insertions(+)
> >
> > diff --git a/include/config_distro_bootcmd.h
> > b/include/config_distro_bootcmd.h
> > index 3f724aa10f..db3d1b2362 100644
> > --- a/include/config_distro_bootcmd.h
> > +++ b/include/config_distro_bootcmd.h
> > @@ -445,7 +445,9 @@
> > "${devnum}:${distro_bootpart} " \
> > "${prefix}${boot_syslinux_conf}; then " \
> > "echo Found ${prefix}${boot_syslinux_conf}; " \
> > + "bootfile_bak=${bootfile}; " \
> > "run boot_extlinux; " \
> > + "setenv bootfile ${bootfile_bak}; " \
> > "echo SCRIPT FAILED: continuing...; " \
> > "fi\0"\
> > \
>
> We've had this kind of problem before, and the answer is that variables
> should be local, not global in scope. In this case, I see that the way
> the pxe/sysboot code works is that we have to env_set("..") in one place
> to env_get("..") in another, so I don't see a way around this.
>
> Reviewed-by: Tom Rini
IMO a better approach will be the bootflow implementation. I hope to
get v2 out early next week.
Reviewed-by: Simon Glass
Regards,
Simon
Re: [RFC 00/22] efi_loader: more tightly integrate UEFI disks to device model
Hi Tom, On Tue, 12 Oct 2021 at 09:00, Tom Rini wrote: > > On Sun, Oct 10, 2021 at 08:14:00AM -0600, Simon Glass wrote: > > Hi Takahiro, > > > > On Thu, 30 Sept 2021 at 23:02, AKASHI Takahiro > > wrote: > > > > > > The purpose of this RPC is to reignite the discussion about how UEFI > > > subystem would best be integrated into U-Boot device model. > > > In the past, I poposed a couple of patch series, the latest one[1], > > > while Heinrich revealed his idea[2], and the approach taken here is > > > something between them, with a focus on block device handlings. > > > > > > # The code is a PoC and not well tested yet. > > > > > > Disks in UEFI world: > > > > > > In general in UEFI world, accessing to any device is performed through > > > a 'protocol' interface which are installed to (or associated with) the > > > device's > > > UEFI handle (or an opaque pointer to UEFI object data). Protocols are > > > implemented by either the UEFI system itself or UEFI drivers. > > > > > > For block IO's, it is a device which has EFI_BLOCK_IO_PROTOCOL (efi_disk > > > hereafter). Currently, every efi_disk may have one of two origins: > > > a.U-Boot's block devices or related partitions > > > (lib/efi_loader/efi_disk.c) > > > b.UEFI objects which are implemented as a block device by UEFI drivers. > > > (lib/efi_driver/efi_block_device.c) > > > > > > All the efi_diskss as (a) will be enumelated and created only once at UEFI > > > subsystem initialization (efi_disk_register()), which is triggered by > > > first executing one of UEFI-related U-Boot commands, like "bootefi", > > > "setenv -e" or "efidebug". > > > EFI_BLOCK_IO_PROTOCOL is implemented by UEFI system using blk_desc(->ops) > > > in the corresponding udevice(UCLASS_BLK). > > > > > > On the other hand, efi_disk as (b) will be created each time UEFI boot > > > services' connect_controller() is executed in UEFI app which, as a > > > (device) > > > controller, gives the method to access the device's data, > > > ie. EFI_BLOCK_IO_PROTOCOL. > > > > > > >>> more details >>> > > > Internally, connect_controller() search for UEFI driver that can support > > > this controller/protocol, 'efi_block' driver(UCLASS_EFI) in this case, > > > then calls the driver's 'bind' interface, which eventually installs > > > the controller's EFI_BLOCK_IO_PROTOCOL to efi_disk object. > > > 'efi_block' driver also create a corresponding udevice(UCLASS_BLK) for > > > * creating additional partitions efi_disk's, and > > > * supporting a file system (EFI_SIMPLE_FILE_SYSTEM_PROTOCOL) on it. > > > <<< <<< > > > > > > Issues: > > > === > > > 1. While an efi_disk represents a device equally for either a whole disk > > >or a partition in UEFI world, the device model treats only a whole > > >disk as a real block device or udevice(UCLASS_BLK). > > > > > > 2. efi_disk holds and makes use of "blk_desc" data even though blk_desc > > >in plat_data is supposed to be private and not to be accessed outside > > >the device model. > > ># This issue, though, exists for all the implmenetation of U-Boot > > ># file systems as well. > > > > Yes, this was a migration convenience and we should be able to unpick it > > now. > > > > However we still have SPL_BLK so need to consider whether we can drop that. > > To be clear here, in that I can hand-wave my way to seeing a use case > for lib/efi_loader/ under SPL, it would not be in a world where we also > still would be supporting the non-DM infrastructure, and is also not a > near-term goal. OK good. Perhaps we should add a migration method for SPL_BLK? It would be good to know where we are in terms of the size stuff. I don't see a lot of boards rushing to use of-platdata, though. Regards, Simon
Re: [RFC 12/22] dm: add a hidden link to efi object
Hi Takahiro,
On Mon, 11 Oct 2021 at 20:09, AKASHI Takahiro
wrote:
>
> On Mon, Oct 11, 2021 at 10:09:19AM -0600, Simon Glass wrote:
> > Hi Heinrich,
> >
> > On Mon, 11 Oct 2021 at 09:31, Heinrich Schuchardt
> > wrote:
> > >
> > >
> > >
> > > On 10/11/21 16:54, Simon Glass wrote:
> > > > Hi Takahiro,
> > > >
> > > > On Mon, 11 Oct 2021 at 00:43, AKASHI Takahiro
> > > > wrote:
> > > >>
> > > >> Simon,
> > > >>
> > > >> On Sun, Oct 10, 2021 at 08:14:18AM -0600, Simon Glass wrote:
> > > >>> Hi Takahiro,
> > > >>>
> > > >>> On Thu, 30 Sept 2021 at 23:04, AKASHI Takahiro
> > > >>> wrote:
> > >
> > > This member field in udevice will be used to dereference from udevice
> > > to efi_object (or efi_handle).
> > >
> > > Signed-off-by: AKASHI Takahiro
> > > ---
> > > include/dm/device.h | 4
> > > 1 file changed, 4 insertions(+)
> > > >>>
> > > >>> I think this should be generalised.
> > > >>>
> > > >>> Can we add a simple API for attaching things to devices? Something
> > > >>> like:
> > > >>
> > > >> Ok.
> > > >>
> > > >>
> > > >>> config DM_TAG
> > > >>> bool "Support tags attached to devices"
> > > >>>
> > > >>> enum dm_tag_t {
> > > >>> DM_TAG_EFI = 0,
> > > >>>
> > > >>> DM_TAG_COUNT,
> > > >>> };
> > > >>>
> > > >>> ret = dev_tag_set_ptr(dev, DM_TAG_EFI, ptr);
> > > >>>
> > > >>> void *ptr = dev_tag_get_ptr(dev, DM_TAG_EFI);
> > > >>>
> > > >>> ulong val = dev_tag_get_val(dev, DM_TAG_EFI);
> > > >>>
> > > >>> Under the hood I think for now we could have a simple list of tags for
> > > >>> all of DM:
> > > >>>
> > > >>> struct dmtag_node {
> > > >>> struct list_head sibling;
> > > >>> struct udevice *dev;
> > > >>> enum dm_tag_t tag;
> > > >>> union {
> > > >>>void *ptr;
> > > >>>ulong val;
> > > >>>};
> > > >>> };
> > > >>
> > > >> Just let me make sure; Do you intend that we have a *single* list of
> > > >> tags
> > > >> in the system instead of maintaining a list *per udevice*?
> > > >
> > > > Yes I would prefer not to have a list per udevice, although the API
> > > > could be adjusted to iterate through all tags for a particular
> > > > udevice, if that is needed (dev_tag_first...() dev_tag_next...().
> > >
> > > There will never be more than one UEFI handle for one udevice.
> > > We need a single field that points to the the handle if such a handle
> > > exists. But there will be devices for which UEFI protocols don't exist
> > > and where we need no handle. In this case the value can be NULL.
> > >
> > > Why should we complicate the picture with a list of tags?
> >
> > Let's not talk about complexity while we are discussing UEFI :-)
> >
> > There are other cases where we need to add info to a device. We cover
> > almost all the cases with the uclass-private, plat and priv data
> > attached to each device. But in some cases that is not enough,
>
> While I'm not sure whether it is "not enough", I used to think of using
> 'priv_auto' (or per_device_auto of UCLASS) to hold a pointer to efi_object,
> but we might see a conflicting situation in the future where some driver
> may also want to use 'priv_auto' for their own purpose.
> That is why I added an extra member to udevice.
Yes indeed, we are finding a few situations where there are not enough
places to put data attached to devices.
>
> # The real benefit might be to keep the size of udevice unchanged?
Yes, although I hope we can actually reduce it. Needs some analysis though.
>
> -Takahiro Akashi
>
> > as with
> > EFI. I have hit this before in a few other places but have tried to
> > work around it rather than extending driver model and adding to the
> > already-large struct udevice. But I think we are at the end of the
> > road on that.
> >
> > I'd also like to look at how much (for example) uclass-plat data is
> > used for devices, in case it would be more efficient to move it to a
> > tag model.
> >
> > I should also point out you are talking about the implementation
> > rather than the API. We can always change the impl later, so long as
> > we have a suitable API.
> >
> > > >
> > > > Looking at some of your other patches I think you might need to
> > > > support multiple tags for EFI, if there are different things. But
> > > > perhaps a list is necesary.
> > > >
> > > >>
> > > >> -Takahiro Akashi
> > > >>
> > > >>
> > > >>> This can be useful in other situations, for example I think we need to
> > > >>> be able to send an event when a device is probed so that other devices
> > > >>> (with tags attached) can take action. But in any case, it makes the
> > > >>> API separate from the data structure, so aids refactoring later.
> > > >>>
> > > >>> If we find that this is slow we can change the impl, but I doubt it
> > > >>> will matter fornow.
> > > >>>
Regards,
SImon
Re: [RFC 01/22] part: call part_init() in blk_get_device_by_str() only for MMC
Hi Takahiro, On Mon, 11 Oct 2021 at 21:26, AKASHI Takahiro wrote: > > Simon, Heinrich, > > On Mon, Oct 11, 2021 at 10:14:02AM -0600, Simon Glass wrote: > > Hi Heinrich, > > > > On Mon, 11 Oct 2021 at 09:09, Heinrich Schuchardt > > wrote: > > > > > > > > > > > > On 10/11/21 16:32, Simon Glass wrote: > > > > Hi Heinrich, > > > > > > > > On Mon, 11 Oct 2021 at 04:07, Heinrich Schuchardt > > > > wrote: > > > >> > > > >> > > > >> > > > >> On 10/1/21 13:48, Peter Robinson wrote: > > > >>> On Fri, Oct 1, 2021 at 6:03 AM AKASHI Takahiro > > > >>> wrote: > > > > > > In blk_get_device_by_str(), the comment says: "Updates the partition > > > table > > > for the specified hw partition." > > > Since hw partition is supported only on MMC, it makes no sense to do > > > so > > > for other devices. > > > >>> > > > >>> Is it not also supported on UFS, and I believe it may also be an > > > >>> option in the NVME spec too. > > > >> > > > >> An NVMe device may expose multiple namespaces. blk_create_devicef() is > > > >> called for each namespace. > > > >> > > > >> A SCSI device may have multiple LUNs. blk_create_devicef() is called > > > >> for > > > >> each LUN. > > > >> > > > >> This is what the tree shown by 'dm tree' with on NVMe namespace and > > > >> one LUN. > > > >> > > > >> Class Index Driver Name > > > >> - > > > >> root 0 root_driverroot_driver > > > >> simple_bus 0 simple_bus |- soc > > > >> spi1 sifive_spi | |- spi@1005 > > > >> mmc0 mmc_spi| | `- mmc@0 > > > >> blk0 mmc_blk| | `- m...@0.blk > > > >> pci0 pcie_sifive| |- pcie@e > > > >> pci1 pci_bridge_drv | | `- pci_0:0.0 > > > >> pci2 pci_bridge_drv | | `- pci_1:0.0 > > > >> pci5 pci_bridge_drv | ||- pci_2:3.0 > > > >> ahci 0 ahci_pci | || `- ahci_pci > > > >> scsi 0 ahci_scsi | || `- ahci_scsi > > > >> blk2 scsi_blk | ||`- ahci_scsi.id0lun0 > > > >> pci6 pci_bridge_drv | ||- pci_2:4.0 > > > >> nvme 0 nvme | || `- nvme#0 > > > >> blk1 nvme-blk | || `- nvme#0.blk#1 > > > >> > > > >> Namespaces and LUNs are modeled as block devices (class = 'blk'). > > > > > > > > So multiple block devices per NVMe device? I did not know that was > > > > supported. > > > > > > > > We need a sandbox driver for NVMe as it has no tests at present. Since > > > > it has no tests, I don't think we can expect people to know how to > > > > maintain whatever functionality is there. > > > > > > NVMe drives with multiple namespaces exist for servers but not for > > > consumer NVMe drives. > > > > > > In QEMU you can define an NVMe device with multiple namespaces. Cf. > > > https://qemu.readthedocs.io/en/latest/system/devices/nvme.html?highlight=namespace#additional-namespaces > > > > > > So for a first glimpse at the handling I suggest to use QEMU. > > > > Well that's fine, but every uclass must have a test and a sandbox > > emulator as well. > > Wait, it seems that you're discussing a different thing from my patch. > > While I don't know whether NVMe namespaces are a kind of "HW partitions", > we don't care much here as long as any namespace can be handled simply > as a normal block device, like scsi LUN's, in terms of U-Boot driver model. > > # On the other hand, we have to explicitly switch "hw partitions" > # with blk_select_hwpart_devnum() on MMC devices even though we use > # the *same* udevice(blk_desc). > # See do_mmcrpmb() in cmd/mmc.c > > So I hope that *your* discussion doesn't make any difference to my patch. > Right? >From my POV the patch is fine, which is why I added the review tag. We should continue the discussion on BLK versus PARTITION. Regards, Simon
Re: [PATCH v6 00/11] board: toradex: verdin-imx8mm: target refresh
On Sat, Oct 9, 2021 at 1:43 PM Marcel Ziswiler wrote:
>
> From: Marcel Ziswiler
>
>
> An assortment of fixes and improvements like an Ethernet PHY
> configuration fix, DEK blob encapsulation preparation, migration to
> using binman to pack images, SLEEP_MOCI# enablement, dropping of V1.0
> hardware support [1], renaming kernel image variable, using preboot
> for fdtfile evaluation and watchdog pinctrl fix.
>
> Note that this series is applied on top of Peng's Makefile fix [2] as
> otherwise, it may not quite generate all binman artefacts in the right
> order as discussed here [3].
>
> [1] https://developer.toradex.com/verdin-sample-phase-over
> [2] https://marc.info/?l=u-boot&m=162908373904742
> [3] https://marc.info/?l=u-boot&m=162945614207220
>
> Changes in v6:
> - New patch re-ordering fdt nodes and properties.
> - Update commit message as requested by Wolfgang.
>
> Changes in v5:
> - Drop device tree part already done by Marek's patch.
> - Add another fixes tag as his patch forgot the board code part.
> - Re-based on top of u-boot-imx, master yet again.
>
> Changes in v4:
> - Add Heiko Schocher's reviewed-by tag.
> - Fix copyright periods.
> - Re-based.
>
> Changes in v3:
> - Case fold hex string.
> - Revert binman part of imx8mm-verdin-u-boot.dtsi to a plain copy from
> imx8mm-evk and postpone further improvements to after migrating to a
> common binman config as agreed with Frieder and Simon.
> - New patch cleaning up include order.
> - Add Fabio's reviewed-by tag.
> - Fix patch.
> - Add missing apalis-imx8 part.
> - While at it update copyright year resp. period.
> - Fix closing endif comment.
>
> Changes in v2:
> - Explicitly pass filename to binman when generating binaries as
> suggested by Heiko.
> - Use proper intermediate binary u-boot-spl-ddr.bin for imximage as
> pointed out by Heiko.
> - Drop first patch ("imx: mkimage_fit_atf: fix legacy image generation")
> as a similar fix was already refused earlier.
> - New patch allows booting recent embedded Linux BSPs.
> - New patch addressing dynamic fdtfile definition.
> - New patch fixing watchdog pinctrl issue.
>
> Igor Opaniuk (1):
> verdin-imx8mm: use preboot for fdtfile evaluation
>
> Marcel Ziswiler (7):
> imx8m: clean-up kconfig indentation
> verdin-imx8mm: fix ethernet
> ARM: dts: imx8mm-verdin: prepare for dek blob encapsulation
> arm64: dts: imx8mm-verdin-u-boot.dtsi: alphabetically re-order
> verdin-imx8mm: switch to use binman to pack images
> verdin-imx8mm: clean-up include order
> verdin-imx8mm: fix watchdog pinctrl issue
>
> Max Krummenacher (2):
> verdin-imx8mm: enable sleep_moci output
> verdin-imx8mm: drop support for v1.0 hardware
>
> Oleksandr Suvorov (1):
> include/configs: apalis-imx8/verdin-imx8mm: rename kernel image
> variable
>
> arch/arm/dts/imx8mm-verdin-u-boot.dtsi | 147 +++-
> arch/arm/dts/imx8mm-verdin.dts | 18 +++
> arch/arm/mach-imx/imx8m/Kconfig | 21 +--
> board/toradex/verdin-imx8mm/imximage.cfg| 11 +-
> board/toradex/verdin-imx8mm/verdin-imx8mm.c | 81 +--
> configs/verdin-imx8mm_defconfig | 6 +-
> doc/board/toradex/verdin-imx8mm.rst | 53 ---
> include/configs/apalis-imx8.h | 6 +-
> include/configs/verdin-imx8mm.h | 10 +-
> 9 files changed, 220 insertions(+), 133 deletions(-)
>
> --
> 2.26.2
>
Marcel,
I've tested your series with mx8mm-venice and did not see any issues.
Tested-by: Tim Harvey for imx8mm-venice-* boards
Thanks, the common u-boot.dtsi is nice to see!
I have a couple of patches that have not been picked up by Stefano yet
due to I believe merge conflicts becuase his imx tree is behind master
with respect to some of the Kconfig patches. You are likely in the
same boat.
Stefano, is it best for me to rebase my 'imx8mm_venice: switch to use
binman to pack images' and 'board: gateworks: venice: add
imx8mn-gw7902 support' patches on your tree or are you going to be
merging in origin/master soon?
Best regards,
Tim
Re: [PATCH] distro_boot: Fix bootfile env after calling boot_extlinux
On Tue, Oct 12, 2021 at 04:55:44PM +0800, Artem Lapkin wrote:
> Problem
>
> PXE cannot boot normally after Sysboot changed the bootfile env (called
> from boot_extlinux) from the default "boot.scr.uimg" to
> "/boot/extlinux/extlinux.conf".
>
> In addition, an unbootable extlinux configuration will also make the PXE
> boot unbootable, because it will use the incorrect path "/boot/extlinux/"
> from the bootfile env.
>
> Solution
>
> Save and restore default bootfile env value when boot_extlinux is used.
>
> Example
>
> Hit SPACE in 2 seconds to stop autoboot
> ... is now current device
> Found /boot/extlinux/extlinux.conf
> Retrieving file: /boot/extlinux/extlinux.conf
> 413 bytes read in 2 ms (201.2 KiB/s)
> Skipping Krescue for failure retrieving kernel
> SCRIPT FAILED: continuing...
> ...
> Speed: 1000, full duplex
> BOOTP broadcast 1
> DHCP client bound to address 192.168.11.151 (8 ms)
> Using ethernet@ff3f device
> TFTP from server 192.168.11.1; our IP address is 192.168.11.151
> Filename '/boot/extlinux/pxelinux.cfg/default'.
> Not retrying...
>
>
> Signed-off-by: Artem Lapkin
> ---
> include/config_distro_bootcmd.h | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/include/config_distro_bootcmd.h b/include/config_distro_bootcmd.h
> index 3f724aa10f..db3d1b2362 100644
> --- a/include/config_distro_bootcmd.h
> +++ b/include/config_distro_bootcmd.h
> @@ -445,7 +445,9 @@
> "${devnum}:${distro_bootpart} " \
> "${prefix}${boot_syslinux_conf}; then " \
> "echo Found ${prefix}${boot_syslinux_conf}; " \
> + "bootfile_bak=${bootfile}; " \
> "run boot_extlinux; " \
> + "setenv bootfile ${bootfile_bak}; " \
> "echo SCRIPT FAILED: continuing...; " \
> "fi\0"\
> \
We've had this kind of problem before, and the answer is that variables
should be local, not global in scope. In this case, I see that the way
the pxe/sysboot code works is that we have to env_set("..") in one place
to env_get("..") in another, so I don't see a way around this.
Reviewed-by: Tom Rini
--
Tom
signature.asc
Description: PGP signature
Re: [PULL] Pull request for u-boot next / v2022.01 = u-boot-stm32-20211012
On Tue, Oct 12, 2021 at 04:54:03PM +0200, Patrice CHOTARD wrote: > Hi Tom > > Please pull the STM32 related patches for u-boot/next, v2022.01: > u-boot-stm32-20211012 > > CI status: > https://source.denx.de/u-boot/custodians/u-boot-stm/-/pipelines/9455 > > Thanks > Patrice > > > The following changes since commit d80bb749fab53da72c4a0e09b8c2d2aaa3103c91: > > Prepare v2021.10 (2021-10-04 11:09:26 -0400) > > are available in the Git repository at: > > https://source.denx.de/u-boot/custodians/u-boot-stm.git > tags/u-boot-stm32-20211012 > > for you to fetch changes up to 39bd2c8e1aa9143c22f1fd20d054fc895a0880d2: > > test/py: Add usb gadget binding test (2021-10-12 14:20:04 +0200) > Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature
Re: [PULL] u-boot-at91-2022.01-b
On Tue, Oct 12, 2021 at 02:18:29PM +, eugen.hris...@microchip.com wrote: > Hello Tom, > > Please pull tag u-boot-at91-2022.01-b , the second set of at91 features > for the next cycle 2022.01 . > > This small feature set adds the support for PWM driver for the sama5d2 > SoC. It also adds a node in the DT for this SoC. > > Thanks, > Eugen > > > The following changes since commit 4c1996ce374924a226c872e26a42cfcc7bf74da2: > >Merge branch '2021-10-11-TI-platform-updates' (2021-10-11 22:39:27 -0400) > > are available in the Git repository at: > >https://source.denx.de/u-boot/custodians/u-boot-at91.git > tags/u-boot-at91-2022.01-b > > for you to fetch changes up to 1f83bda7886c0e3fbb9aaf1d36dcaac27a7c92ea: > >ARM: dts: sama5d2: Add pwm0 definition (2021-10-12 15:18:39 +0300) > Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature
Re: how to run u-boot on qemu arm64 virt machine?
On Tue, Oct 12, 2021 at 01:46:33PM +0900, c...@etri.re.kr wrote: > Hello, u-boot mail list members, > > I'm trying to run u-boot on qemu arm64 virt machine to analyze how the S/W > runs. > > I followed "doc/board/emulation/qemu-arm.rst", and here is what I did. > > > > For qemu build (using qemu-2.9.0), I did under ~/QEMU/qemu directory, > > mkdir build; cd build; ../configure --target-list=aarch64-softmmu > --enable-debug --enable-gtk --disable-werror; make -j24 > > to build u-boot, I did under ~/U-BOOT/u-boot, > > make ARCH=arm CROSS_COMPILE=aarch64-none-elf- qemu_arm64_defconfig > > To run u-boot on qemu, I did under ~/U-BOOT/u-boot > > ~/QEMU/qemu/build/aarch64-softmmu/qemu-system-aarch64 -M virt -cpu > cortex-a57 -bios u-boot.bin > > > > But I see only qemu manager window and I don't know how to proceed. > > Am I not supposed to see u-boot program running? > > What am I doing wrong? Any help will be really appreciated. > > Thank you. That's a very old QEMU version. We use v6.1.0 currently and v4.2.0 before that. -- Tom signature.asc Description: PGP signature
Exception handling in HYP mode on ARMv7-A
I've run into an issue with exception handling on the Raspberry Pi 3 in 32-bit mode (config rpi_3_32b) and the ODroid XU4 (config odroid-xu3). When testing the "exception undefined" command, instead of printing out register info and resetting the CPU like it's supposed to, U-Boot just hangs. I noticed that on both of these boards, U-Boot runs in hypervisor mode (HYP) because both the Pi's Cortex-A53 and the ODroid's Cortex-A7 support virtualization extensions. This causes several issues with the ARMv7 exception handling code, which assumes that exceptions are taken in EL1. (All file names and line numbers referenced below are respect to the v2021.10 release) The first issue running in HYP mode is that the vector table base address is not set correctly. In arch/arm/cpu/armv7/start.S L78 and arch/arm/lib/relocate.S L45, the VBAR register is loaded with the vector table base address. However, exceptions taken to EL2 use the address in the HVBAR register, not VBAR. The next issue is that the get_bad_stack macro (arch/arm/lib/vectors.S) uses "movs pc, lr" to return from the exception into supervisor mode, but this is an illegal instruction in HYP mode as it was replaced by "eret". Also, the lr register does not hold the exception return address (which is used to determine the PC before the exception), since exceptions taken to EL2 store the return address in the new ELR_hyp register instead. I'm also not sure in reading this code why there's a switch to supervisor mode... So to handle an exception to EL2 properly, an instruction like "msr ELR_hyp, lr" needs to be assembled, and this requires "-march=armv7ve" in the CC flags, not "-march=armv7-a". I found it quite surprising that this didn't work correctly. I'd be happy to submit a patch for it, and could use some guidance. To change the CC flag to the correct architecture, it seems like introducing a CONFIG_CPU_V7VE may be the right approach. Then I'd say that for builds with this config, there should be two separate exception vector tables, one for EL1, which would be left as it currently is, and a new one for EL2, with this table loaded into HVBAR. I'd appreciate your thoughts, thanks.
[PULL] u-boot-at91-2022.01-b
Hello Tom, Please pull tag u-boot-at91-2022.01-b , the second set of at91 features for the next cycle 2022.01 . This small feature set adds the support for PWM driver for the sama5d2 SoC. It also adds a node in the DT for this SoC. Thanks, Eugen The following changes since commit 4c1996ce374924a226c872e26a42cfcc7bf74da2: Merge branch '2021-10-11-TI-platform-updates' (2021-10-11 22:39:27 -0400) are available in the Git repository at: https://source.denx.de/u-boot/custodians/u-boot-at91.git tags/u-boot-at91-2022.01-b for you to fetch changes up to 1f83bda7886c0e3fbb9aaf1d36dcaac27a7c92ea: ARM: dts: sama5d2: Add pwm0 definition (2021-10-12 15:18:39 +0300) Second set of u-boot-at91 features for the 2022.01 cycle Dan Sneddon (3): pwm: Add PWM driver for SAMA5D2 dt-bindings: pwm: pwm-at91: Add PWM bindings for A5D2 ARM: dts: sama5d2: Add pwm0 definition arch/arm/dts/sama5d2.dtsi | 8 ++ doc/device-tree-bindings/pwm/pwm-at91.txt | 16 +++ drivers/pwm/Kconfig | 6 + drivers/pwm/Makefile | 1 + drivers/pwm/pwm-at91.c| 207 ++ 5 files changed, 238 insertions(+) create mode 100644 doc/device-tree-bindings/pwm/pwm-at91.txt create mode 100644 drivers/pwm/pwm-at91.c
Re: [PATCH 0/3] Add SAMA5D2 PWM Support
On 9/21/21 2:28 AM, Dan Sneddon wrote: > Add support for the PWM found on SAMA5D2 SoCs. > > Dan Sneddon (3): >pwm: Add PWM driver for SAMA5D2 >dt-bindings: pwm: pwm-at91: Add PWM bindings for A5D2 >ARM:dts: sama5d2: Add pwm definition > > arch/arm/dts/sama5d2.dtsi | 8 + > doc/device-tree-bindings/pwm/pwm-at91.txt | 16 ++ > drivers/pwm/Kconfig | 6 + > drivers/pwm/Makefile | 1 + > drivers/pwm/pwm-at91.c| 207 ++ > 5 files changed, 238 insertions(+) > create mode 100644 doc/device-tree-bindings/pwm/pwm-at91.txt > create mode 100644 drivers/pwm/pwm-at91.c > > -- > 2.17.1 > Applied to u-boot-at91/master, thanks !
Re: IMX8M OP-TEE
Hi Tim On Mon, 2021-10-11 at 16:32 -0700, Tim Harvey wrote: > > ... > Marcel, > > Thanks for checking into OP-TEE for me. Sure thing. I meanwhile got reminded that Sergio Prado actually held a talk about this topic back at the Embedded World [1]. Not sure whether he played with mainline U-Boot and OP-TEE though. > I haven't tested your series yet as I tried to apply it and it failed. It should actually be based on latest imx/master but depends on a few other series as indicated in the cover letter. > Do you have a git repo I can cherry-pick from or what did you base it > on top of? For your convenience I just pushed my branch to my personal github now as well [2]. > Thanks, Thanks you! > Tim [1] https://www.youtube.com/watch?v=sBVzSQ5uvUw [2] https://github.com/ziswiler/u-boot/tree/20211008-imx-master_common_binman_v2 Cheers Marcel
[PATCH v1] board: toradex: add verdin imx8m plus support
From: Marcel Ziswiler
This adds initial support for the Toradex Verdin iMX8M Plus Quad 4GB WB
IT V1.0B module. They are strapped to boot from eFuses which are factory
fused to properly boot from their on-module eMMC. U-Boot supports
booting from the on-module eMMC only, SDP support is disabled for now
due to missing i.MX 8M Plus USB support.
Functionality wise the following is known to be working:
- eMMC, 8-bit and 4-bit MMC/SD card slots
- Ethernet both on-module eQoS and FEC (requires PHY on carrier board)
- GPIOs
- I2C
Boot sequence is:
SPL ---> ATF (TF-A) ---> U-boot proper
ATF, U-boot proper and u-boot.dtb images are packed into a FIT image,
loaded by SPL.
Boot:
U-Boot SPL 2021.10-00355-gb975dd54f37 (Oct 12 2021 - 18:32:08 +0200)
Quad die, dual rank failed, attempting dual die, single rank configuration.
Normal Boot
WDT: Started watchdog@3028 with servicing (60s timeout)
Trying to boot from BOOTROM
Find img info 0x&48025c00, size 872
Download 776704, Total size 777464
NOTICE: BL31: v2.2(release):rel_imx_5.4.70_2.3.2_rc1-5-g835a8f67b
NOTICE: BL31: Built : 16:52:37, Aug 26 2021
U-Boot 2021.10-00355-gb975dd54f37 (Oct 12 2021 - 18:32:08 +0200)
CPU: Freescale i.MX8MP[8] rev1.1 at 1200 MHz
Reset cause: POR
DRAM: 8 GiB
WDT: Started watchdog@3028 with servicing (60s timeout)
MMC: FSL_SDHC: 1, FSL_SDHC: 2
Loading Environment from MMC... OK
In:serial
Out: serial
Err: serial
Model: Toradex Verdin iMX8M Plus Quad 4GB Wi-Fi / BT IT V1.0B,
Serial# 06817281
Carrier: Toradex Verdin Development Board V1.1A, Serial# 10754333
Setting variant to wifi
Net: Hard-coding pdata->enetaddr
eth1: ethernet@30be, eth0: ethernet@30bf [PRIME]
Hit any key to stop autoboot: 0
Verdin iMX8MP #
Note that this series is applied on top of my patch set introducing
Colibri iMX6ULL 1GB eMMC variant [1], Peng's Makefile fix [2] as
otherwise, it may not quite generate all binman artefacts in the right
order as discussed here [3] and Ye Li's patch set enabling DWC EQoS iMX
driver [4].
[1] https://marc.info/?l=u-boot&m=163353937432582
[2] https://marc.info/?l=u-boot&m=162908373904742
[3] https://marc.info/?l=u-boot&m=162945614207220
[4] https://marc.info/?l=u-boot&m=162911073217202
Signed-off-by: Marcel Ziswiler
---
arch/arm/dts/Makefile |1 +
arch/arm/dts/imx8mp-verdin-u-boot.dtsi | 132 ++
arch/arm/dts/imx8mp-verdin.dts | 639 ++
arch/arm/mach-imx/imx8m/Kconfig |8 +
board/toradex/verdin-imx8mp/Kconfig | 42 +
board/toradex/verdin-imx8mp/MAINTAINERS | 10 +
board/toradex/verdin-imx8mp/Makefile| 11 +
board/toradex/verdin-imx8mp/imximage.cfg| 10 +
board/toradex/verdin-imx8mp/lpddr4_timing.c | 2168 +++
board/toradex/verdin-imx8mp/spl.c | 158 ++
board/toradex/verdin-imx8mp/verdin-imx8mp.c | 158 ++
configs/verdin-imx8mp_defconfig | 131 ++
doc/board/toradex/verdin-imx8mp.rst | 105 +
include/configs/verdin-imx8mp.h | 136 ++
14 files changed, 3709 insertions(+)
create mode 100644 arch/arm/dts/imx8mp-verdin-u-boot.dtsi
create mode 100644 arch/arm/dts/imx8mp-verdin.dts
create mode 100644 board/toradex/verdin-imx8mp/Kconfig
create mode 100644 board/toradex/verdin-imx8mp/MAINTAINERS
create mode 100644 board/toradex/verdin-imx8mp/Makefile
create mode 100644 board/toradex/verdin-imx8mp/imximage.cfg
create mode 100644 board/toradex/verdin-imx8mp/lpddr4_timing.c
create mode 100644 board/toradex/verdin-imx8mp/spl.c
create mode 100644 board/toradex/verdin-imx8mp/verdin-imx8mp.c
create mode 100644 configs/verdin-imx8mp_defconfig
create mode 100644 doc/board/toradex/verdin-imx8mp.rst
create mode 100644 include/configs/verdin-imx8mp.h
diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
index 2dd7ca68188..af1de695894 100644
--- a/arch/arm/dts/Makefile
+++ b/arch/arm/dts/Makefile
@@ -890,6 +890,7 @@ dtb-$(CONFIG_ARCH_IMX8M) += \
imx8mq-phanbell.dtb \
imx8mp-evk.dtb \
imx8mp-phyboard-pollux-rdk.dtb \
+ imx8mp-verdin.dtb \
imx8mq-pico-pi.dtb
dtb-$(CONFIG_ARCH_IMXRT) += imxrt1050-evk.dtb \
diff --git a/arch/arm/dts/imx8mp-verdin-u-boot.dtsi
b/arch/arm/dts/imx8mp-verdin-u-boot.dtsi
new file mode 100644
index 000..fb25b4a7ce4
--- /dev/null
+++ b/arch/arm/dts/imx8mp-verdin-u-boot.dtsi
@@ -0,0 +1,132 @@
+// SPDX-License-Identifier: GPL-2.0+ OR MIT
+/*
+ * Copyright 2021 Toradex
+ */
+
+#include "imx8mp-u-boot.dtsi"
+
+/ {
+ firmware {
+ optee {
+ compatible = "linaro,optee-tz";
+ method = "smc";
+ };
+ };
+
+ wdt-reboot {
+ compatible = "wdt-reboot";
+ u-boot,dm-spl;
+ wdt = <&wdog1>;
+ };
+};
+
+&clk {
+ u-boot,dm-pre-reloc;
+ u-boot,dm-spl;
+ /delete-property/ assigned-clocks;
+ /delete-property/ assigned-clock-parents;
+
Re: Pull request: u-boot-sunxi/master for v2022.01
On Tue, Oct 12, 2021 at 05:15:55PM +0100, Andre Przywara wrote: > On Tue, 12 Oct 2021 11:49:02 -0400 > Tom Rini wrote: > > Hi Tom, > > > On Tue, Oct 12, 2021 at 01:58:18PM +0100, Andre Przywara wrote: > > > > > Hi Tom, > > > > > > please pull the sunxi/master branch, containing the first part of the > > > 2022.01 changes. > > > > > > The bulk of it is Samuel's DM_I2C rework, which removes the nasty > > > I2C deprecation warnings for most 32-bit boards. It also includes some > > > smaller refactorings that pave the way for more changes, mostly driven > > > by needing to support the Allwinner RISC-V SoC later on. > > > > > > Board wise we gain support for the FriendlyARM NanoPi R1S H5 router board > > > and official Pinetab support. > > > > > > Build-tested for all 160 sunxi boards, and boot tested on a A64, A20, H3, > > > H6, and H616 board. USB, SD card, eMMC, and Ethernet all work there > > > (where applicable). > > > > > > Thanks, > > > Andre > > > > > > == > > > The following changes since commit > > > f331497d3ad4166f9826e7674793ae04094b29c1: > > > > > > Merge tag 'video-20211009' of > > > https://source.denx.de/u-boot/custodians/u-boot-video (2021-10-09 > > > 17:47:27 -0400) > > > > > > are available in the Git repository at: > > > > > > git://git.denx.de/u-boot-sunxi.git master > > > > > > for you to fetch changes up to f9437b00c06382d3edc623c10c69901786ad6317: > > > > > > sunxi: Enable DM_I2C for all sunxi boards (2021-10-12 11:01:27 +0100) > > > > > > > Note that the POWER_MC34VR500 PMIC driver is NOT converted to DM, so I > > had to move the Kconfig entry for that around in order to avoid a new > > Kconfig warning when building. > > Oh, sorry for that! I just see that the commit message speaks of > DM_PMIC_MC34708, but it's indeed POWER_MC34VR500 that (wrongfully) gains > the dependency. For the next tests I will try to find some idle machine > and build more boards than just sunxi! > So thanks for the heads up and the quick fix! Note that you should be able to enable CI runs in the custodian tree, if they aren't enabled by default. That said, you'll only spot this type of error if you check out the job output / summary as it's not a fatal error. That said, if there's some way to make Kconfig errors like this fatal, adding it to CI like we do for -Werror would be good :) -- Tom signature.asc Description: PGP signature
Re: Pull request: u-boot-sunxi/master for v2022.01
On Tue, 12 Oct 2021 11:49:02 -0400 Tom Rini wrote: Hi Tom, > On Tue, Oct 12, 2021 at 01:58:18PM +0100, Andre Przywara wrote: > > > Hi Tom, > > > > please pull the sunxi/master branch, containing the first part of the > > 2022.01 changes. > > > > The bulk of it is Samuel's DM_I2C rework, which removes the nasty > > I2C deprecation warnings for most 32-bit boards. It also includes some > > smaller refactorings that pave the way for more changes, mostly driven > > by needing to support the Allwinner RISC-V SoC later on. > > > > Board wise we gain support for the FriendlyARM NanoPi R1S H5 router board > > and official Pinetab support. > > > > Build-tested for all 160 sunxi boards, and boot tested on a A64, A20, H3, > > H6, and H616 board. USB, SD card, eMMC, and Ethernet all work there > > (where applicable). > > > > Thanks, > > Andre > > > > == > > The following changes since commit f331497d3ad4166f9826e7674793ae04094b29c1: > > > > Merge tag 'video-20211009' of > > https://source.denx.de/u-boot/custodians/u-boot-video (2021-10-09 17:47:27 > > -0400) > > > > are available in the Git repository at: > > > > git://git.denx.de/u-boot-sunxi.git master > > > > for you to fetch changes up to f9437b00c06382d3edc623c10c69901786ad6317: > > > > sunxi: Enable DM_I2C for all sunxi boards (2021-10-12 11:01:27 +0100) > > > > Note that the POWER_MC34VR500 PMIC driver is NOT converted to DM, so I > had to move the Kconfig entry for that around in order to avoid a new > Kconfig warning when building. Oh, sorry for that! I just see that the commit message speaks of DM_PMIC_MC34708, but it's indeed POWER_MC34VR500 that (wrongfully) gains the dependency. For the next tests I will try to find some idle machine and build more boards than just sunxi! So thanks for the heads up and the quick fix! > I've added some NXP folks to the email > here because that's a conversion that needs doing ASAP. > > With that said, this PR is applied to u-boot/master, thanks! Many thanks! Cheers, Andre
[PATCH] board/km: update MAINTAINERS files
Update the e-mail addresses and person responsible. Signed-off-by: Holger Brunck CC: Aleksandar Gerasimovski CC: Rainer Boschung --- board/keymile/km83xx/MAINTAINERS | 2 +- board/keymile/km_arm/MAINTAINERS | 2 +- board/keymile/pg-wcom-ls102xa/MAINTAINERS | 5 ++--- board/keymile/secu1/MAINTAINERS | 2 +- 4 files changed, 5 insertions(+), 6 deletions(-) diff --git a/board/keymile/km83xx/MAINTAINERS b/board/keymile/km83xx/MAINTAINERS index 9268719a74..9fd5a8500d 100644 --- a/board/keymile/km83xx/MAINTAINERS +++ b/board/keymile/km83xx/MAINTAINERS @@ -1,5 +1,5 @@ KM83XX BOARD -M: Holger Brunck +M: Holger Brunck M: Heiko Schocher S: Maintained F: board/keymile/km83xx/ diff --git a/board/keymile/km_arm/MAINTAINERS b/board/keymile/km_arm/MAINTAINERS index 8da58da962..bc6858be13 100644 --- a/board/keymile/km_arm/MAINTAINERS +++ b/board/keymile/km_arm/MAINTAINERS @@ -1,5 +1,5 @@ KM_ARM BOARD -M: Valentin Longchamp +M: Holger Brunck S: Maintained F: board/keymile/km_arm/ F: include/configs/km_kirkwood.h diff --git a/board/keymile/pg-wcom-ls102xa/MAINTAINERS b/board/keymile/pg-wcom-ls102xa/MAINTAINERS index 26b202316c..966c88b681 100644 --- a/board/keymile/pg-wcom-ls102xa/MAINTAINERS +++ b/board/keymile/pg-wcom-ls102xa/MAINTAINERS @@ -1,7 +1,6 @@ Hitachi Power Grids LS102XA BOARD -M: Aleksandar Gerasimovski -M: Rainer Boschung -M: Matteo Ghidoni +M: Aleksandar Gerasimovski +M: Rainer Boschung S: Maintained F: board/keymile/pg-wcom-ls102xa/ F: include/configs/km/pg-wcom-ls102xa.h diff --git a/board/keymile/secu1/MAINTAINERS b/board/keymile/secu1/MAINTAINERS index 3e40eef3cc..833b3fdeab 100644 --- a/board/keymile/secu1/MAINTAINERS +++ b/board/keymile/secu1/MAINTAINERS @@ -1,5 +1,5 @@ Hitachi Power Grids SECU1 BOARD -M: Holger Brunck +M: Holger Brunck S: Maintained F: include/configs/socfpga_arria5_secu1.h F: configs/socfpga_secu1_defconfig -- 2.31.0
[PATCH] net: bootp: Correct VCI string transmission
The VCI string sent during bootp of U-Boot-SPL is corrupt. This is because the byte counter is not adjusted within the bootp_extended() function when the VCI string is added. We fix this. Signed-off-by: Walter Stoll --- net/bootp.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/net/bootp.c b/net/bootp.c index 655b9cceb6..58e30cd6b0 100644 --- a/net/bootp.c +++ b/net/bootp.c @@ -647,7 +647,7 @@ static int bootp_extended(u8 *e) *e++ = (576 - 312 + OPT_FIELD_SIZE) & 0xff; #endif - add_vci(e); + e = add_vci(e); #if defined(CONFIG_BOOTP_SUBNETMASK) *e++ = 1; /* Subnet mask request */ -- 2.33.0
Re: Pull request: u-boot-sunxi/master for v2022.01
On Tue, Oct 12, 2021 at 01:58:18PM +0100, Andre Przywara wrote: > Hi Tom, > > please pull the sunxi/master branch, containing the first part of the > 2022.01 changes. > > The bulk of it is Samuel's DM_I2C rework, which removes the nasty > I2C deprecation warnings for most 32-bit boards. It also includes some > smaller refactorings that pave the way for more changes, mostly driven > by needing to support the Allwinner RISC-V SoC later on. > > Board wise we gain support for the FriendlyARM NanoPi R1S H5 router board > and official Pinetab support. > > Build-tested for all 160 sunxi boards, and boot tested on a A64, A20, H3, > H6, and H616 board. USB, SD card, eMMC, and Ethernet all work there > (where applicable). > > Thanks, > Andre > > == > The following changes since commit f331497d3ad4166f9826e7674793ae04094b29c1: > > Merge tag 'video-20211009' of > https://source.denx.de/u-boot/custodians/u-boot-video (2021-10-09 17:47:27 > -0400) > > are available in the Git repository at: > > git://git.denx.de/u-boot-sunxi.git master > > for you to fetch changes up to f9437b00c06382d3edc623c10c69901786ad6317: > > sunxi: Enable DM_I2C for all sunxi boards (2021-10-12 11:01:27 +0100) > Note that the POWER_MC34VR500 PMIC driver is NOT converted to DM, so I had to move the Kconfig entry for that around in order to avoid a new Kconfig warning when building. I've added some NXP folks to the email here because that's a conversion that needs doing ASAP. With that said, this PR is applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature
[PATCH 6/6 v4] board: samsung: add Samsung Galaxy S9/S9+(SM-G96x0) board
Samsung S9 SM-G9600 - Snapdragon SDM845 version of the phone,
for China \ Hong Kong markets.
Has unlockable bootloader, unlike SM-G960U (American market version),
which allows running u-boot as a chain-loaded bootloader.
Signed-off-by: Dzmitry Sankouski
Cc: Ramon Fried
Cc: Tom Rini
---
Changes for v2:
- Create documentation file for SDM845 boards
- Add starqltechn board documentation
Changes for v3:
- fix comment in starqltechn.c
Changes for v4:
- move configs to Kconfig file
- remove starqltechn.h file
- set SYS_CONFIG_NAME to default of sdm845
- remove unneeded options from starqltechn_defconfig
arch/arm/dts/Makefile | 1 +
arch/arm/dts/starqltechn-uboot.dtsi | 39 ++
arch/arm/dts/starqltechn.dts| 53 +
arch/arm/mach-snapdragon/Kconfig| 17
board/samsung/starqltechn/Kconfig | 22 ++
board/samsung/starqltechn/MAINTAINERS | 6 +++
board/samsung/starqltechn/Makefile | 9 +
board/samsung/starqltechn/starqltechn.c | 10 +
configs/starqltechn_defconfig | 30 ++
doc/board/qualcomm/index.rst| 1 +
doc/board/qualcomm/sdm845.rst | 38 ++
11 files changed, 226 insertions(+)
create mode 100644 arch/arm/dts/starqltechn-uboot.dtsi
create mode 100644 arch/arm/dts/starqltechn.dts
create mode 100644 board/samsung/starqltechn/Kconfig
create mode 100644 board/samsung/starqltechn/MAINTAINERS
create mode 100644 board/samsung/starqltechn/Makefile
create mode 100644 board/samsung/starqltechn/starqltechn.c
create mode 100644 configs/starqltechn_defconfig
create mode 100644 doc/board/qualcomm/sdm845.rst
diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
index 82a0790cc0..90d922dab7 100644
--- a/arch/arm/dts/Makefile
+++ b/arch/arm/dts/Makefile
@@ -467,6 +467,7 @@ dtb-$(CONFIG_TARGET_SL28) += fsl-ls1028a-kontron-sl28.dtb \
dtb-$(CONFIG_TARGET_DRAGONBOARD410C) += dragonboard410c.dtb
dtb-$(CONFIG_TARGET_DRAGONBOARD820C) += dragonboard820c.dtb
+dtb-$(CONFIG_TARGET_STARQLTECHN) += starqltechn.dtb
dtb-$(CONFIG_TARGET_STEMMY) += ste-ux500-samsung-stemmy.dtb
diff --git a/arch/arm/dts/starqltechn-uboot.dtsi
b/arch/arm/dts/starqltechn-uboot.dtsi
new file mode 100644
index 00..d8d75e018a
--- /dev/null
+++ b/arch/arm/dts/starqltechn-uboot.dtsi
@@ -0,0 +1,39 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * U-Boot addition to handle Samsung S9 SM-G9600 (starqltechn) pins
+ *
+ * (C) Copyright 2021 Dzmitry Sankouski
+ *
+ */
+
+/
+{
+ soc {
+ u-boot,dm-pre-reloc;
+ gcc {
+ clock-controller@10 {
+ u-boot,dm-pre-reloc;
+ };
+ serial@0xa84000 {
+ u-boot,dm-pre-reloc;
+ };
+ gpio_north@390 {
+ u-boot,dm-pre-reloc;
+ };
+ pinctrl@390 {
+ u-boot,dm-pre-reloc;
+ };
+ };
+ };
+};
+
+&pm8998_pon {
+ key_vol_down {
+ gpios = <&pm8998_pon 1 0>;
+ label = "key_vol_down";
+ };
+ key_power {
+ gpios = <&pm8998_pon 0 0>;
+ label = "key_power";
+ };
+};
diff --git a/arch/arm/dts/starqltechn.dts b/arch/arm/dts/starqltechn.dts
new file mode 100644
index 00..387420f30b
--- /dev/null
+++ b/arch/arm/dts/starqltechn.dts
@@ -0,0 +1,53 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Samsung S9 SM-G9600 (starqltechn) board device tree source
+ *
+ * (C) Copyright 2021 Dzmitry Sankouski
+ *
+ */
+
+/dts-v1/;
+
+#include "sdm845.dtsi"
+
+/ {
+ model = "Samsung S9 (SM-G9600)";
+ compatible = "qcom,sdm845-mtp", "qcom,sdm845", "qcom,mtp";
+ #address-cells = <2>;
+ #size-cells = <2>;
+
+ chosen {
+ stdout-path = "serial0:921600n8";
+ };
+
+ aliases {
+ serial0 = &debug_uart;
+ };
+
+ memory {
+ device_type = "memory";
+ reg = <0 0x8000 0 0xfe1b>;
+ };
+
+ psci {
+ compatible = "arm,psci-1.0";
+ method = "smc";
+ };
+
+ soc: soc {
+ serial@0xa84000 {
+ status = "ok";
+ };
+
+ pinctrl@390 {
+ muic_i2c: muic_i2c {
+ pins = "GPIO_33", "GPIO_34";
+ drive-strength = <0x2>;
+ function = "gpio";
+ bias-disable;
+ };
+ };
+ };
+};
+
+#include "starqltechn-uboot.dtsi"
diff --git a/arch/arm/mach-snapdragon/Kconfig b/arch/arm/mach-snapdragon/Kconfig
index 1a6a608967..12cf02a56a 100644
--- a/arch/arm/mach-sn
[PATCH 1/6 v4] serial: qcom: add support for GENI serial driver
Generic Interface (GENI) Serial Engine (SE) based uart can be found on newer qualcomm SOCs, starting from SDM845. Tested on Samsung SM-G9600(starqltechn) by chain-loading u-boot with stock bootloader. Signed-off-by: Dzmitry Sankouski Cc: Ramon Fried Cc: Tom Rini --- Changes for v2: - change functions return type to void, where possible - remove '.' from summary line Changes for v3: - move function open brace on new line - use tab between define name and value - define: wrap expression with braces, remove braces from constants Changes for v4: - add linux/delay.h header MAINTAINERS | 1 + .../serial/msm-geni-serial.txt| 6 + drivers/serial/Kconfig| 17 + drivers/serial/Makefile | 1 + drivers/serial/serial_msm_geni.c | 603 ++ 5 files changed, 628 insertions(+) create mode 100644 doc/device-tree-bindings/serial/msm-geni-serial.txt create mode 100644 drivers/serial/serial_msm_geni.c diff --git a/MAINTAINERS b/MAINTAINERS index 776ff703b9..52ddc99cda 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -390,6 +390,7 @@ F: drivers/gpio/msm_gpio.c F: drivers/mmc/msm_sdhci.c F: drivers/phy/msm8916-usbh-phy.c F: drivers/serial/serial_msm.c +F: drivers/serial/serial_msm_geni.c F: drivers/smem/msm_smem.c F: drivers/usb/host/ehci-msm.c diff --git a/doc/device-tree-bindings/serial/msm-geni-serial.txt b/doc/device-tree-bindings/serial/msm-geni-serial.txt new file mode 100644 index 00..9eadc2561b --- /dev/null +++ b/doc/device-tree-bindings/serial/msm-geni-serial.txt @@ -0,0 +1,6 @@ +Qualcomm GENI UART + +Required properties: +- compatible: must be "qcom,msm-geni-uart" +- reg: start address and size of the registers +- clock: interface clock (must accept baudrate as a frequency) diff --git a/drivers/serial/Kconfig b/drivers/serial/Kconfig index 93348c0929..b420a5720d 100644 --- a/drivers/serial/Kconfig +++ b/drivers/serial/Kconfig @@ -278,6 +278,14 @@ config DEBUG_UART_S5P will need to provide parameters to make this work. The driver will be available until the real driver-model serial is running. +config DEBUG_UART_MSM_GENI + bool "Qualcomm snapdragon" + depends on ARCH_SNAPDRAGON + help + Select this to enable a debug UART using the serial_msm driver. You + will need to provide parameters to make this work. The driver will + be available until the real driver-model serial is running. + config DEBUG_UART_MESON bool "Amlogic Meson" depends on MESON_SERIAL @@ -783,6 +791,15 @@ config MSM_SERIAL for example APQ8016 and MSM8916. Single baudrate is supported in current implementation (115200). +config MSM_GENI_SERIAL + bool "Qualcomm on-chip GENI UART" + help + Support UART based on Generic Interface (GENI) Serial Engine (SE), used on Qualcomm Snapdragon SoCs. + Should support all qualcomm SOCs with Qualcomm Universal Peripheral (QUP) Wrapper cores, + i.e. newer ones, starting from SDM845. + Driver works in FIFO mode. + Multiple baudrates supported. + config OCTEON_SERIAL_BOOTCMD bool "MIPS Octeon PCI remote bootcmd input" depends on ARCH_OCTEON diff --git a/drivers/serial/Makefile b/drivers/serial/Makefile index 3cbea8156f..d44caf4ea2 100644 --- a/drivers/serial/Makefile +++ b/drivers/serial/Makefile @@ -62,6 +62,7 @@ obj-$(CONFIG_PIC32_SERIAL) += serial_pic32.o obj-$(CONFIG_BCM283X_MU_SERIAL) += serial_bcm283x_mu.o obj-$(CONFIG_BCM283X_PL011_SERIAL) += serial_bcm283x_pl011.o obj-$(CONFIG_MSM_SERIAL) += serial_msm.o +obj-$(CONFIG_MSM_GENI_SERIAL) += serial_msm_geni.o obj-$(CONFIG_MVEBU_A3700_UART) += serial_mvebu_a3700.o obj-$(CONFIG_MPC8XX_CONS) += serial_mpc8xx.o obj-$(CONFIG_NULLDEV_SERIAL) += serial_nulldev.o diff --git a/drivers/serial/serial_msm_geni.c b/drivers/serial/serial_msm_geni.c new file mode 100644 index 00..c656d54cbb --- /dev/null +++ b/drivers/serial/serial_msm_geni.c @@ -0,0 +1,603 @@ +// SPDX-License-Identifier: GPL-2.0+ +/* + * Qualcomm GENI serial engine UART driver + * + * (C) Copyright 2021 Dzmitry Sankouski + * + * Based on Linux driver. + */ + +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include + +#define UART_OVERSAMPLING 32 +#define STALE_TIMEOUT 160 +#define SE_UART_RX_STALE_CNT 0x294 +#define S_GENI_CMD_ABORT (BIT(1)) + +#define SE_GENI_S_CMD_CTRL_REG 0x634 +#define SE_GENI_M_CMD_CTRL_REG 0x604 + +/* GENI_M_CMD_CTRL_REG */ +#define M_GENI_CMD_CANCEL (BIT(2)) +#define M_GENI_CMD_ABORT (BIT(1)) +#define M_GENI_DISABLE (BIT(0)) + +/* GENI_S_CMD0 fields */ +#define S_OPCODE_MSK (GENMASK(31, 27)) +#define S_OPCODE_SHFT 27 +#define S_PARAMS_MSK (GENMASK(26, 0)) + +/* GENI_STATUS fields */ +#define M_GENI_CMD_ACTIVE (BIT(0)) +#def
[PATCH 4/6] clocks: qcom: add clocks for SDM845 debug uart
Allows to change clock frequency of debug uart,
thus supporting wide range of baudrates.
Enable / disable functionality is not implemented yet.
In most use cases of SDM845 (i.e. mobile phones and tablets)
it's not needed, because qualcomm first stage bootloader leaves it
initialized, and on the other hand there's no possibility to
replace signed first stage bootloader with u-boot.
Signed-off-by: Dzmitry Sankouski
Cc: Ramon Fried
Cc: Tom Rini
---
arch/arm/mach-snapdragon/clock-sdm845.c | 92 +
arch/arm/mach-snapdragon/clock-snapdragon.c | 1 +
arch/arm/mach-snapdragon/clock-snapdragon.h | 3 +-
3 files changed, 95 insertions(+), 1 deletion(-)
create mode 100644 arch/arm/mach-snapdragon/clock-sdm845.c
diff --git a/arch/arm/mach-snapdragon/clock-sdm845.c
b/arch/arm/mach-snapdragon/clock-sdm845.c
new file mode 100644
index 00..9572639238
--- /dev/null
+++ b/arch/arm/mach-snapdragon/clock-sdm845.c
@@ -0,0 +1,92 @@
+// SPDX-License-Identifier: BSD-3-Clause
+/*
+ * Clock drivers for Qualcomm SDM845
+ *
+ * (C) Copyright 2017 Jorge Ramirez Ortiz
+ * (C) Copyright 2021 Dzmitry Sankouski
+ *
+ * Based on Little Kernel driver, simplified
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include "clock-snapdragon.h"
+
+#define F(f, s, h, m, n) { (f), (s), (2 * (h) - 1), (m), (n) }
+
+struct freq_tbl {
+ uint freq;
+ uint src;
+ u8 pre_div;
+ u16 m;
+ u16 n;
+};
+
+static const struct freq_tbl ftbl_gcc_qupv3_wrap0_s0_clk_src[] = {
+ F(7372800, CFG_CLK_SRC_GPLL0_EVEN, 1, 384, 15625),
+ F(14745600, CFG_CLK_SRC_GPLL0_EVEN, 1, 768, 15625),
+ F(1920, CFG_CLK_SRC_CXO, 1, 0, 0),
+ F(29491200, CFG_CLK_SRC_GPLL0_EVEN, 1, 1536, 15625),
+ F(3200, CFG_CLK_SRC_GPLL0_EVEN, 1, 8, 75),
+ F(4800, CFG_CLK_SRC_GPLL0_EVEN, 1, 4, 25),
+ F(6400, CFG_CLK_SRC_GPLL0_EVEN, 1, 16, 75),
+ F(8000, CFG_CLK_SRC_GPLL0_EVEN, 1, 4, 15),
+ F(9600, CFG_CLK_SRC_GPLL0_EVEN, 1, 8, 25),
+ F(1, CFG_CLK_SRC_GPLL0_EVEN, 3, 0, 0),
+ F(10240, CFG_CLK_SRC_GPLL0_EVEN, 1, 128, 375),
+ F(11200, CFG_CLK_SRC_GPLL0_EVEN, 1, 28, 75),
+ F(117964800, CFG_CLK_SRC_GPLL0_EVEN, 1, 6144, 15625),
+ F(12000, CFG_CLK_SRC_GPLL0_EVEN, 2.5, 0, 0),
+ F(12800, CFG_CLK_SRC_GPLL0, 1, 16, 75),
+ { }
+};
+
+static const struct bcr_regs uart2_regs = {
+ .cfg_rcgr = SE9_UART_APPS_CFG_RCGR,
+ .cmd_rcgr = SE9_UART_APPS_CMD_RCGR,
+ .M = SE9_UART_APPS_M,
+ .N = SE9_UART_APPS_N,
+ .D = SE9_UART_APPS_D,
+};
+
+const struct freq_tbl *qcom_find_freq(const struct freq_tbl *f, uint rate)
+{
+ if (!f)
+ return NULL;
+
+ if (!f->freq)
+ return f;
+
+ for (; f->freq; f++)
+ if (rate <= f->freq)
+ return f;
+
+ /* Default to our fastest rate */
+ return f - 1;
+}
+
+static int clk_init_uart(struct msm_clk_priv *priv, uint rate)
+{
+ const struct freq_tbl *freq =
qcom_find_freq(ftbl_gcc_qupv3_wrap0_s0_clk_src, rate);
+
+ clk_rcg_set_rate_mnd(priv->base, &uart2_regs,
+ freq->pre_div, freq->m,
freq->n, freq->src);
+
+ return 0;
+}
+
+ulong msm_set_rate(struct clk *clk, ulong rate)
+{
+ struct msm_clk_priv *priv = dev_get_priv(clk->dev);
+
+ switch (clk->id) {
+ case 0x58: /*UART2*/
+ return clk_init_uart(priv, rate);
+ default:
+ return 0;
+ }
+}
diff --git a/arch/arm/mach-snapdragon/clock-snapdragon.c
b/arch/arm/mach-snapdragon/clock-snapdragon.c
index 2b76371718..3deb08ac4a 100644
--- a/arch/arm/mach-snapdragon/clock-snapdragon.c
+++ b/arch/arm/mach-snapdragon/clock-snapdragon.c
@@ -135,6 +135,7 @@ static const struct udevice_id msm_clk_ids[] = {
{ .compatible = "qcom,gcc-apq8016" },
{ .compatible = "qcom,gcc-msm8996" },
{ .compatible = "qcom,gcc-apq8096" },
+ { .compatible = "qcom,gcc-sdm845" },
{ }
};
diff --git a/arch/arm/mach-snapdragon/clock-snapdragon.h
b/arch/arm/mach-snapdragon/clock-snapdragon.h
index 58fab40a2e..2ac53b538d 100644
--- a/arch/arm/mach-snapdragon/clock-snapdragon.h
+++ b/arch/arm/mach-snapdragon/clock-snapdragon.h
@@ -1,6 +1,6 @@
/* SPDX-License-Identifier: GPL-2.0+ */
/*
- * Qualcomm APQ8016, APQ8096
+ * Qualcomm APQ8016, APQ8096, SDM845
*
* (C) Copyright 2017 Jorge Ramirez-Ortiz
*/
@@ -9,6 +9,7 @@
#define CFG_CLK_SRC_CXO (0 << 8)
#define CFG_CLK_SRC_GPLL0 (1 << 8)
+#define CFG_CLK_SRC_GPLL0_EVEN (6 << 8)
#define CFG_CLK_SRC_MASK (7 << 8)
struct pll_vote_clk {
--
2.20.1
[PATCH 5/6 v2] SoC: qcom: add support for SDM845
Hi-end qualcomm chip, introduced in late 2017.
Mostly used in flagship phones and tablets of 2018.
Features:
- arm64 arch
- total of 8 Kryo 385 Gold / Silver cores
- Hexagon 685 DSP
- Adreno 630 GPU
Tested only as second-stage bootloader.
Signed-off-by: Dzmitry Sankouski
Cc: Ramon Fried
Cc: Tom Rini
Cc: Stephan Gerhold
---
Changes for v2:
- refactor sdm845.dtsi.
arch/arm/dts/sdm845.dtsi | 116 ++
arch/arm/mach-snapdragon/Kconfig | 4 +
arch/arm/mach-snapdragon/Makefile | 4 +
.../include/mach/sysmap-sdm845.h | 42 +++
arch/arm/mach-snapdragon/init_sdm845.c| 82 +
arch/arm/mach-snapdragon/sysmap-sdm845.c | 31 +
include/configs/sdm845.h | 33 +
7 files changed, 312 insertions(+)
create mode 100644 arch/arm/dts/sdm845.dtsi
create mode 100644 arch/arm/mach-snapdragon/include/mach/sysmap-sdm845.h
create mode 100644 arch/arm/mach-snapdragon/init_sdm845.c
create mode 100644 arch/arm/mach-snapdragon/sysmap-sdm845.c
create mode 100644 include/configs/sdm845.h
diff --git a/arch/arm/dts/sdm845.dtsi b/arch/arm/dts/sdm845.dtsi
new file mode 100644
index 00..1185b71216
--- /dev/null
+++ b/arch/arm/dts/sdm845.dtsi
@@ -0,0 +1,116 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Qualcomm SDM845 chip device tree source
+ *
+ * (C) Copyright 2021 Dzmitry Sankouski
+ *
+ */
+
+/dts-v1/;
+
+#include "skeleton64.dtsi"
+
+/ {
+ soc: soc {
+ #address-cells = <1>;
+ #size-cells = <1>;
+ ranges = <0 0 0 0x>;
+ compatible = "simple-bus";
+
+ gcc: clock-controller@10 {
+ u-boot,dm-pre-reloc;
+ compatible = "qcom,gcc-sdm845";
+ reg = <0x10 0x1f>;
+ #clock-cells = <1>;
+ #reset-cells = <1>;
+ #power-domain-cells = <1>;
+ };
+
+ gpio_north: gpio_north@390 {
+ u-boot,dm-pre-reloc;
+ #gpio-cells = <2>;
+ compatible = "qcom,sdm845-pinctrl";
+ reg = <0x390 0x40>;
+ gpio-count = <150>;
+ gpio-controller;
+ gpio-ranges = <&gpio_north 0 0 150>;
+ gpio-bank-name = "soc_north.";
+ };
+
+ tlmm_north: pinctrl_north@390 {
+ u-boot,dm-pre-reloc;
+ compatible = "qcom,tlmm-sdm845";
+ reg = <0x390 0x40>;
+ gpio-count = <150>;
+ gpio-controller;
+ #gpio-cells = <2>;
+ gpio-ranges = <&tlmm_north 0 0 150>;
+
+ /* DEBUG UART */
+ qup_uart9: qup-uart9-default {
+ pinmux {
+ pins = "GPIO_4", "GPIO_5";
+ function = "qup9";
+ };
+ };
+ };
+
+ debug_uart: serial@a84000 {
+ compatible = "qcom,msm-geni-uart";
+ reg = <0xa84000 0x4000>;
+ reg-names = "se_phys";
+ clock-names = "se-clk";
+ clocks = <&gcc 0x58>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&qup_uart9>;
+ qcom,wrapper-core = <0x8a>;
+ status = "disabled";
+ };
+
+ spmi@c44 {
+ compatible = "qcom,spmi-pmic-arb";
+ reg = <0xc44 0x1100>,
+ <0xc60 0x200>,
+ <0xe60 0x10>;
+ reg-names = "cnfg", "core", "obsrvr";
+ #address-cells = <0x1>;
+ #size-cells = <0x1>;
+
+ qcom,revid@100 {
+ compatible = "qcom,qpnp-revid";
+ reg = <0x100 0x100>;
+ };
+
+ pmic0: pm8998@0 {
+ compatible = "qcom,spmi-pmic";
+ reg = <0x0 0x1>;
+ #address-cells = <0x1>;
+ #size-cells = <0x1>;
+
+ pm8998_pon: pm8998_pon@800 {
+ compatible = "qcom,pm8998-pwrkey";
+ reg = <0x800 0x100>;
+ #gpio-cells = <2>;
+ gpio-controller;
+ gpio-bank-name = "pm8998_key.";
+
[PATCH 2/6 v4] spmi: msm: add arbiter version 5 support
Currently driver supports only version 1 and 2.
Version 5 has slightly different registers structure
Signed-off-by: Dzmitry Sankouski
Cc: Ramon Fried
Cc: Tom Rini
---
Changes for v2:
- change string formats in debug statements
Changes for v3:
- remove if else braces where possible
Changes for v4:
- change variable type to fix pointer cast warning
MAINTAINERS | 1 +
drivers/spmi/spmi-msm.c | 154 +++-
2 files changed, 105 insertions(+), 50 deletions(-)
diff --git a/MAINTAINERS b/MAINTAINERS
index 52ddc99cda..6b8b0783d2 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -392,6 +392,7 @@ F: drivers/phy/msm8916-usbh-phy.c
F: drivers/serial/serial_msm.c
F: drivers/serial/serial_msm_geni.c
F: drivers/smem/msm_smem.c
+F: drivers/spmi/spmi-msm.c
F: drivers/usb/host/ehci-msm.c
ARM STI
diff --git a/drivers/spmi/spmi-msm.c b/drivers/spmi/spmi-msm.c
index 5a335e50aa..27a035c0a5 100644
--- a/drivers/spmi/spmi-msm.c
+++ b/drivers/spmi/spmi-msm.c
@@ -19,39 +19,63 @@
DECLARE_GLOBAL_DATA_PTR;
/* PMIC Arbiter configuration registers */
-#define PMIC_ARB_VERSION 0x
-#define PMIC_ARB_VERSION_V2_MIN0x2001
-
-#define ARB_CHANNEL_OFFSET(n) (0x4 * (n))
-#define SPMI_CH_OFFSET(chnl) ((chnl) * 0x8000)
-
-#define SPMI_REG_CMD0 0x0
-#define SPMI_REG_CONFIG0x4
-#define SPMI_REG_STATUS0x8
-#define SPMI_REG_WDATA 0x10
-#define SPMI_REG_RDATA 0x18
-
-#define SPMI_CMD_OPCODE_SHIFT 27
-#define SPMI_CMD_SLAVE_ID_SHIFT20
-#define SPMI_CMD_ADDR_SHIFT12
-#define SPMI_CMD_ADDR_OFFSET_SHIFT 4
-#define SPMI_CMD_BYTE_CNT_SHIFT0
-
-#define SPMI_CMD_EXT_REG_WRITE_LONG0x00
-#define SPMI_CMD_EXT_REG_READ_LONG 0x01
-
-#define SPMI_STATUS_DONE 0x1
+#define PMIC_ARB_VERSION 0x
+#define PMIC_ARB_VERSION_V2_MIN 0x2001
+#define PMIC_ARB_VERSION_V3_MIN 0x3000
+#define PMIC_ARB_VERSION_V5_MIN 0x5000
+
+#define APID_MAP_OFFSET_V1_V2_V3 (0x800)
+#define APID_MAP_OFFSET_V5 (0x900)
+#define ARB_CHANNEL_OFFSET(n) (0x4 * (n))
+#define SPMI_CH_OFFSET(chnl) ((chnl) * 0x8000)
+#define SPMI_V5_OBS_CH_OFFSET(chnl) ((chnl) * 0x80)
+#define SPMI_V5_RW_CH_OFFSET(chnl) ((chnl) * 0x1)
+
+#define SPMI_REG_CMD0 0x0
+#define SPMI_REG_CONFIG 0x4
+#define SPMI_REG_STATUS 0x8
+#define SPMI_REG_WDATA 0x10
+#define SPMI_REG_RDATA 0x18
+
+#define SPMI_CMD_OPCODE_SHIFT 27
+#define SPMI_CMD_SLAVE_ID_SHIFT 20
+#define SPMI_CMD_ADDR_SHIFT 12
+#define SPMI_CMD_ADDR_OFFSET_SHIFT 4
+#define SPMI_CMD_BYTE_CNT_SHIFT 0
+
+#define SPMI_CMD_EXT_REG_WRITE_LONG 0x00
+#define SPMI_CMD_EXT_REG_READ_LONG 0x01
+
+#define SPMI_STATUS_DONE 0x1
+
+#define SPMI_MAX_CHANNELS 128
+#define SPMI_MAX_SLAVES 16
+#define SPMI_MAX_PERIPH 256
+
+enum arb_ver {
+ V1 = 1,
+ V2,
+ V3,
+ V5 = 5
+};
-#define SPMI_MAX_CHANNELS 128
-#define SPMI_MAX_SLAVES16
-#define SPMI_MAX_PERIPH256
+/*
+ * PMIC arbiter version 5 uses different register offsets for read/write vs
+ * observer channels.
+ */
+enum pmic_arb_channel {
+ PMIC_ARB_CHANNEL_RW,
+ PMIC_ARB_CHANNEL_OBS,
+};
struct msm_spmi_priv {
- phys_addr_t arb_chnl; /* ARB channel mapping base */
+ phys_addr_t arb_chnl; /* ARB channel mapping base */
phys_addr_t spmi_core; /* SPMI core */
- phys_addr_t spmi_obs; /* SPMI observer */
+ phys_addr_t spmi_obs; /* SPMI observer */
/* SPMI channel map */
uint8_t channel_map[SPMI_MAX_SLAVES][SPMI_MAX_PERIPH];
+ /* SPMI bus arbiter version */
+ u32 arb_ver;
};
static int msm_spmi_write(struct udevice *dev, int usid, int pid, int off,
@@ -59,6 +83,7 @@ static int msm_spmi_write(struct udevice *dev, int usid, int
pid, int off,
{
struct msm_spmi_priv *priv = dev_get_priv(dev);
unsigned channel;
+ unsigned int ch_offset;
uint32_t reg = 0;
if (usid >= SPMI_MAX_SLAVES)
@@ -69,8 +94,8 @@ static int msm_spmi_write(struct udevice *dev, int usid, int
pid, int off,
channel = priv->channel_map[usid][pid];
/* Disable IRQ mode for the current channel*/
- writel(0x0, priv->spmi_core + SPMI_CH_OFFSET(channel) +
- SPMI_REG_CONFIG);
+ writel(0x0,
+ priv->spmi_core + SPMI_CH_OFFSET(channel) + SPMI_REG_CONFIG);
/* Write single byte */
writel(val, priv->spmi_core + SPMI_CH_OFFSET(channel) + SPMI_REG_WDATA);
@@ -82,6 +107,11 @@ static int msm_spmi_write(struct udevice *dev, int usid,
int pid, int off,
reg |= (off << SPMI_CMD_ADDR_OFFSET_SHIFT);
reg |= 1; /* byte count */
+ if (priv->arb_ver == V5)
+ ch_offset = SPMI_V5_RW_CH_OFFSET(channel);
+ else
+ ch_offset = SPMI_CH_OFFSET(channel);
+
/* Send write
[PATCH 3/6 v2] pinctrl: qcom: add pinctrl and gpio drivers for SDM845 SoC
Signed-off-by: Dzmitry Sankouski
Cc: Ramon Fried
Cc: Tom Rini
Cc: Stephan Gerhold
---
Changes for v2:
- Add __section(".data") for pin_name variable.
arch/arm/mach-snapdragon/pinctrl-sdm845.c | 44 +++
arch/arm/mach-snapdragon/pinctrl-snapdragon.c | 1 +
arch/arm/mach-snapdragon/pinctrl-snapdragon.h | 1 +
drivers/gpio/msm_gpio.c | 1 +
drivers/gpio/pm8916_gpio.c| 8 ++--
5 files changed, 52 insertions(+), 3 deletions(-)
create mode 100644 arch/arm/mach-snapdragon/pinctrl-sdm845.c
diff --git a/arch/arm/mach-snapdragon/pinctrl-sdm845.c
b/arch/arm/mach-snapdragon/pinctrl-sdm845.c
new file mode 100644
index 00..40f2f012fa
--- /dev/null
+++ b/arch/arm/mach-snapdragon/pinctrl-sdm845.c
@@ -0,0 +1,44 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Qualcomm SDM845 pinctrl
+ *
+ * (C) Copyright 2021 Dzmitry Sankouski
+ *
+ */
+
+#include "pinctrl-snapdragon.h"
+#include
+
+#define MAX_PIN_NAME_LEN 32
+static char pin_name[MAX_PIN_NAME_LEN] __section(".data");
+
+static const struct pinctrl_function msm_pinctrl_functions[] = {
+ {"qup9", 1},
+ {"gpio", 0},
+};
+
+static const char *sdm845_get_function_name(struct udevice *dev,
+unsigned int selector)
+{
+ return msm_pinctrl_functions[selector].name;
+}
+
+static const char *sdm845_get_pin_name(struct udevice *dev,
+ unsigned int selector)
+{
+ snprintf(pin_name, MAX_PIN_NAME_LEN, "GPIO_%u", selector);
+ return pin_name;
+}
+
+static unsigned int sdm845_get_function_mux(unsigned int selector)
+{
+ return msm_pinctrl_functions[selector].val;
+}
+
+struct msm_pinctrl_data sdm845_data = {
+ .pin_count = 150,
+ .functions_count = ARRAY_SIZE(msm_pinctrl_functions),
+ .get_function_name = sdm845_get_function_name,
+ .get_function_mux = sdm845_get_function_mux,
+ .get_pin_name = sdm845_get_pin_name,
+};
diff --git a/arch/arm/mach-snapdragon/pinctrl-snapdragon.c
b/arch/arm/mach-snapdragon/pinctrl-snapdragon.c
index e6b87c3573..c0ed943036 100644
--- a/arch/arm/mach-snapdragon/pinctrl-snapdragon.c
+++ b/arch/arm/mach-snapdragon/pinctrl-snapdragon.c
@@ -116,6 +116,7 @@ static struct pinctrl_ops msm_pinctrl_ops = {
static const struct udevice_id msm_pinctrl_ids[] = {
{ .compatible = "qcom,tlmm-apq8016", .data = (ulong)&apq8016_data },
{ .compatible = "qcom,tlmm-apq8096", .data = (ulong)&apq8096_data },
+ { .compatible = "qcom,tlmm-sdm845", .data = (ulong)&sdm845_data },
{ }
};
diff --git a/arch/arm/mach-snapdragon/pinctrl-snapdragon.h
b/arch/arm/mach-snapdragon/pinctrl-snapdragon.h
index 61d466f4d8..ea524312a0 100644
--- a/arch/arm/mach-snapdragon/pinctrl-snapdragon.h
+++ b/arch/arm/mach-snapdragon/pinctrl-snapdragon.h
@@ -27,5 +27,6 @@ struct pinctrl_function {
extern struct msm_pinctrl_data apq8016_data;
extern struct msm_pinctrl_data apq8096_data;
+extern struct msm_pinctrl_data sdm845_data;
#endif
diff --git a/drivers/gpio/msm_gpio.c b/drivers/gpio/msm_gpio.c
index e1ff84c1c0..a3c3cd7824 100644
--- a/drivers/gpio/msm_gpio.c
+++ b/drivers/gpio/msm_gpio.c
@@ -120,6 +120,7 @@ static const struct udevice_id msm_gpio_ids[] = {
{ .compatible = "qcom,msm8916-pinctrl" },
{ .compatible = "qcom,apq8016-pinctrl" },
{ .compatible = "qcom,ipq4019-pinctrl" },
+ { .compatible = "qcom,sdm845-pinctrl" },
{ }
};
diff --git a/drivers/gpio/pm8916_gpio.c b/drivers/gpio/pm8916_gpio.c
index 40b0f2578b..7ad95784a8 100644
--- a/drivers/gpio/pm8916_gpio.c
+++ b/drivers/gpio/pm8916_gpio.c
@@ -202,6 +202,7 @@ static int pm8916_gpio_of_to_plat(struct udevice *dev)
static const struct udevice_id pm8916_gpio_ids[] = {
{ .compatible = "qcom,pm8916-gpio" },
{ .compatible = "qcom,pm8994-gpio" }, /* 22 GPIO's */
+ { .compatible = "qcom,pm8998-gpio" },
{ }
};
@@ -266,7 +267,7 @@ static int pm8941_pwrkey_probe(struct udevice *dev)
return log_msg_ret("bad type", -ENXIO);
reg = pmic_reg_read(dev->parent, priv->pid + REG_SUBTYPE);
- if (reg != 0x1)
+ if ((reg & 0x5) == 0)
return log_msg_ret("bad subtype", -ENXIO);
return 0;
@@ -287,11 +288,12 @@ static int pm8941_pwrkey_of_to_plat(struct udevice *dev)
static const struct udevice_id pm8941_pwrkey_ids[] = {
{ .compatible = "qcom,pm8916-pwrkey" },
{ .compatible = "qcom,pm8994-pwrkey" },
+ { .compatible = "qcom,pm8998-pwrkey" },
{ }
};
-U_BOOT_DRIVER(pwrkey_pm8941) = {
- .name = "pwrkey_pm8916",
+U_BOOT_DRIVER(pwrkey_pm89xx) = {
+ .name = "pwrkey_pm89xx",
.id = UCLASS_GPIO,
.of_match = pm8941_pwrkey_ids,
.of_to_plat = pm8941_pwrkey_of_to_plat,
--
2.20.1
[PATCH 0/6] Add support for SDM845 based boards, and SM-G9600
Snapdragon 845 - hi-end qualcomm chip, introduced in late 2017. Mostly used in flagship phones and tablets of 2018. Features: - arm64 arch - total of 8 Kryo 385 Gold / Silver cores - Hexagon 685 DSP - Adreno 630 GPU Tested only as second-stage bootloader. Samsung S9 SM-G9600 - Snapdragon SDM845 version of the phone, for China \ Hong Kong markets. Has unlockable bootloader, unlike SM-G960U (American market version), which allows running u-boot as a chain-loaded bootloader. Dzmitry Sankouski (6): serial: qcom: add support for GENI serial driver spmi: msm: add arbiter version 5 support pinctrl: qcom: add pinctrl and gpio drivers for SDM845 SoC clocks: qcom: add clocks for SDM845 debug uart SoC: qcom: add support for SDM845 board: samsung: add Samsung Galaxy S9/S9+(SM-G96x0) board MAINTAINERS | 2 + arch/arm/dts/Makefile | 1 + arch/arm/dts/sdm845.dtsi | 118 arch/arm/dts/starqltechn-uboot.dtsi | 39 ++ arch/arm/dts/starqltechn.dts | 53 ++ arch/arm/mach-snapdragon/Kconfig | 17 + arch/arm/mach-snapdragon/Makefile | 4 + arch/arm/mach-snapdragon/clock-sdm845.c | 92 +++ arch/arm/mach-snapdragon/clock-snapdragon.c | 1 + arch/arm/mach-snapdragon/clock-snapdragon.h | 3 +- .../include/mach/sysmap-sdm845.h | 42 ++ arch/arm/mach-snapdragon/init_sdm845.c| 82 +++ arch/arm/mach-snapdragon/pinctrl-sdm845.c | 44 ++ arch/arm/mach-snapdragon/pinctrl-snapdragon.c | 1 + arch/arm/mach-snapdragon/pinctrl-snapdragon.h | 1 + arch/arm/mach-snapdragon/sysmap-sdm845.c | 31 + board/samsung/starqltechn/Kconfig | 14 + board/samsung/starqltechn/MAINTAINERS | 6 + board/samsung/starqltechn/Makefile| 9 + board/samsung/starqltechn/starqltechn.c | 10 + configs/starqltechn_defconfig | 33 + doc/board/qualcomm/index.rst | 1 + doc/board/qualcomm/sdm845.rst | 38 ++ .../serial/msm-geni-serial.txt| 6 + drivers/gpio/msm_gpio.c | 1 + drivers/gpio/pm8916_gpio.c| 8 +- drivers/serial/Kconfig| 17 + drivers/serial/Makefile | 1 + drivers/serial/serial_msm_geni.c | 602 ++ drivers/spmi/spmi-msm.c | 156 +++-- include/configs/sdm845.h | 33 + include/configs/starqltechn.h | 16 + 32 files changed, 1428 insertions(+), 54 deletions(-) create mode 100644 arch/arm/dts/sdm845.dtsi create mode 100644 arch/arm/dts/starqltechn-uboot.dtsi create mode 100644 arch/arm/dts/starqltechn.dts create mode 100644 arch/arm/mach-snapdragon/clock-sdm845.c create mode 100644 arch/arm/mach-snapdragon/include/mach/sysmap-sdm845.h create mode 100644 arch/arm/mach-snapdragon/init_sdm845.c create mode 100644 arch/arm/mach-snapdragon/pinctrl-sdm845.c create mode 100644 arch/arm/mach-snapdragon/sysmap-sdm845.c create mode 100644 board/samsung/starqltechn/Kconfig create mode 100644 board/samsung/starqltechn/MAINTAINERS create mode 100644 board/samsung/starqltechn/Makefile create mode 100644 board/samsung/starqltechn/starqltechn.c create mode 100644 configs/starqltechn_defconfig create mode 100644 doc/board/qualcomm/sdm845.rst create mode 100644 doc/device-tree-bindings/serial/msm-geni-serial.txt create mode 100644 drivers/serial/serial_msm_geni.c create mode 100644 include/configs/sdm845.h create mode 100644 include/configs/starqltechn.h -- 2.20.1
[PATCH 3/4] SoC: exynos: add support for exynos 78x0
Samsung Exynos 7880 \ 7870 - SoC for mainstream smartphones and tablets
introduced on March 2017.
Features:
- 8 Cortex A53 cores
- ARM Mali-T830 MP3 GPU
- LTE Cat. 7 (7880) or 6 (7870) modem
Signed-off-by: Dzmitry Sankouski
Cc: Minkyu Kang
---
arch/arm/dts/exynos78x0-gpio.dtsi | 204 ++
arch/arm/dts/exynos78x0-pinctrl.dtsi| 280
arch/arm/dts/exynos78x0.dtsi| 98 +++
arch/arm/mach-exynos/mmu-arm64.c| 66 +
drivers/gpio/s5p_gpio.c | 1 +
drivers/pinctrl/exynos/Kconfig | 8 +
drivers/pinctrl/exynos/Makefile | 1 +
drivers/pinctrl/exynos/pinctrl-exynos78x0.c | 119 +
include/configs/exynos78x0-common.h | 112
9 files changed, 889 insertions(+)
create mode 100644 arch/arm/dts/exynos78x0-gpio.dtsi
create mode 100644 arch/arm/dts/exynos78x0-pinctrl.dtsi
create mode 100644 arch/arm/dts/exynos78x0.dtsi
create mode 100644 drivers/pinctrl/exynos/pinctrl-exynos78x0.c
create mode 100644 include/configs/exynos78x0-common.h
diff --git a/arch/arm/dts/exynos78x0-gpio.dtsi
b/arch/arm/dts/exynos78x0-gpio.dtsi
new file mode 100644
index 00..a7f75c5ca9
--- /dev/null
+++ b/arch/arm/dts/exynos78x0-gpio.dtsi
@@ -0,0 +1,204 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Samsung's Exynos7880 SoC pin-mux and pin-config device tree source
+ *
+ * Copyright (c) 2014 Samsung Electronics Co., Ltd.
+ * http://www.samsung.com
+ * Copyright (c) 2020 Dzmitry Sankouski (dsankou...@gmail.com)
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+/ {
+ /* ALIVE */
+ gpio@139F {
+ etc0: etc0 {
+ gpio-controller;
+ #gpio-cells = <2>;
+ };
+
+ etc1: etc1 {
+ gpio-controller;
+ #gpio-cells = <2>;
+ };
+
+ gpa0: gpa0 {
+ gpio-controller;
+ #gpio-cells = <2>;
+ };
+
+ gpa1: gpa1 {
+ gpio-controller;
+ #gpio-cells = <2>;
+ };
+
+ gpa2: gpa2 {
+ gpio-controller;
+ #gpio-cells = <2>;
+ };
+
+ gpa3: gpa3 {
+ gpio-controller;
+ #gpio-cells = <2>;
+ };
+
+ gpq0: gpq0 {
+ gpio-controller;
+ #gpio-cells = <2>;
+ };
+ };
+
+ /* CCORE */
+ gpio@1063 {
+ gpm0: gpm0 {
+ gpio-controller;
+ #gpio-cells = <2>;
+ };
+ };
+
+ /* DISP/AUD */
+ gpio@148C {
+ gpz0: gpz0 {
+ gpio-controller;
+ #gpio-cells = <2>;
+ };
+
+ gpz1: gpz1 {
+ gpio-controller;
+ #gpio-cells = <2>;
+ };
+
+ gpz2: gpz2 {
+ gpio-controller;
+ #gpio-cells = <2>;
+ };
+ };
+
+ /* FSYS0 */
+ gpio@1375 {
+ gpr0: gpr0 {
+ gpio-controller;
+ #gpio-cells = <2>;
+ };
+
+ gpr1: gpr1 {
+ gpio-controller;
+ #gpio-cells = <2>;
+ };
+
+ gpr2: gpr2 {
+ gpio-controller;
+ #gpio-cells = <2>;
+ };
+
+ gpr3: gpr3 {
+ gpio-controller;
+ #gpio-cells = <2>;
+ };
+
+ gpr4: gpr4 {
+ gpio-controller;
+ #gpio-cells = <2>;
+ };
+ };
+
+ /* TOP */
+ gpio@139B {
+ gpb0: gpb0 {
+ gpio-controller;
+ #gpio-cells = <2>;
+ };
+
+ gpc0: gpc0 {
+ gpio-controller;
+ #gpio-cells = <2>;
+ };
+
+ gpc1: gpc1 {
+ gpio-controller;
+ #gpio-cells = <2>;
+ };
+
+ gpc4: gpc4 {
+ gpio-controller;
+ #gpio-cells = <2>;
+ };
+
+ gpc5: gpc5 {
+ gpio-controller;
+ #gpio-cells = <2>;
+ };
+
+ gpc6: gpc6 {
+ gpio-controller;
+ #gpio-cells = <2>;
+ };
+
+
[PATCH 4/4] board: samsung: add support for Galaxy A series of 2017 (a5y17lte)
Samsung Galaxy A3, A5, A7 (2017) - middle class Samsung smartphones.
U-boot can be used as chain-loaded bootloader to gain control
on booting vanilla linux(and possibly others) kernels
Signed-off-by: Dzmitry Sankouski
Cc: Minkyu Kang
---
arch/arm/dts/Makefile| 3 +
arch/arm/dts/exynos78x0-axy17lte.dts | 29 +
arch/arm/mach-exynos/Kconfig | 28 +
board/samsung/axy17lte/Kconfig | 58 ++
board/samsung/axy17lte/MAINTAINERS | 8 +++
board/samsung/axy17lte/Makefile | 3 +
board/samsung/axy17lte/axy17lte.c| 11
configs/a3y17lte_defconfig | 24
configs/a5y17lte_defconfig | 24
configs/a7y17lte_defconfig | 24
doc/board/index.rst | 1 +
doc/board/samsung/axy17lte.rst | 92
doc/board/samsung/index.rst | 9 +++
13 files changed, 314 insertions(+)
create mode 100644 arch/arm/dts/exynos78x0-axy17lte.dts
create mode 100644 board/samsung/axy17lte/Kconfig
create mode 100644 board/samsung/axy17lte/MAINTAINERS
create mode 100644 board/samsung/axy17lte/Makefile
create mode 100644 board/samsung/axy17lte/axy17lte.c
create mode 100644 configs/a3y17lte_defconfig
create mode 100644 configs/a5y17lte_defconfig
create mode 100644 configs/a7y17lte_defconfig
create mode 100644 doc/board/samsung/axy17lte.rst
create mode 100644 doc/board/samsung/index.rst
diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
index b8a382d153..947c15aa50 100644
--- a/arch/arm/dts/Makefile
+++ b/arch/arm/dts/Makefile
@@ -28,6 +28,9 @@ dtb-$(CONFIG_EXYNOS5) += exynos5250-arndale.dtb \
exynos5800-peach-pi.dtb \
exynos5422-odroidxu3.dtb
dtb-$(CONFIG_EXYNOS7420) += exynos7420-espresso7420.dtb
+dtb-$(CONFIG_TARGET_A5Y17LTE) += exynos78x0-axy17lte.dtb
+dtb-$(CONFIG_TARGET_A3Y17LTE) += exynos78x0-axy17lte.dtb
+dtb-$(CONFIG_TARGET_A7Y17LTE) += exynos78x0-axy17lte.dtb
dtb-$(CONFIG_ARCH_DAVINCI) += \
da850-evm.dtb \
diff --git a/arch/arm/dts/exynos78x0-axy17lte.dts
b/arch/arm/dts/exynos78x0-axy17lte.dts
new file mode 100644
index 00..7fae8db874
--- /dev/null
+++ b/arch/arm/dts/exynos78x0-axy17lte.dts
@@ -0,0 +1,29 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Samsung Exynos78x0 SoC device tree source
+ *
+ * Copyright (c) 2020 Dzmitry Sankouski (dsankou...@gmail.com)
+ */
+
+/dts-v1/;
+#include "exynos78x0.dtsi"
+/ {
+ compatible = "samsung,exynos78x0", "samsung,exynos7880",
"samsung,exynos7870";
+
+ aliases {
+ console = &uart2;
+ };
+
+ chosen {
+ stdout-path = &uart2;
+ };
+};
+
+&gpioi2c0 {
+ status = "okay";
+};
+
+&fin_pll {
+ clock-frequency = <2600>;
+};
+
diff --git a/arch/arm/mach-exynos/Kconfig b/arch/arm/mach-exynos/Kconfig
index 7df0e17617..7f3aee5712 100644
--- a/arch/arm/mach-exynos/Kconfig
+++ b/arch/arm/mach-exynos/Kconfig
@@ -151,6 +151,33 @@ config TARGET_ESPRESSO7420
select PINCTRL_EXYNOS7420
select SUPPORT_SPL
+config TARGET_A5Y17LTE
+ bool "Samsung SM-A520F board"
+ select ARM64
+ select CLK_EXYNOS
+ select OF_CONTROL
+ select PINCTRL
+ select PINCTRL_EXYNOS78x0
+ select SUPPORT_SPL
+
+config TARGET_A7Y17LTE
+ bool "Samsung SM-A520F board"
+ select ARM64
+ select CLK_EXYNOS
+ select OF_CONTROL
+ select PINCTRL
+ select PINCTRL_EXYNOS78x0
+ select SUPPORT_SPL
+
+config TARGET_A3Y17LTE
+ bool "Samsung SM-A520F board"
+ select ARM64
+ select CLK_EXYNOS
+ select OF_CONTROL
+ select PINCTRL
+ select PINCTRL_EXYNOS7880
+ select SUPPORT_SPL
+
endchoice
endif
@@ -167,6 +194,7 @@ source "board/samsung/arndale/Kconfig"
source "board/samsung/smdk5250/Kconfig"
source "board/samsung/smdk5420/Kconfig"
source "board/samsung/espresso7420/Kconfig"
+source "board/samsung/axy17lte/Kconfig"
config SPL_LDSCRIPT
default "board/samsung/common/exynos-uboot-spl.lds" if ARCH_EXYNOS5 ||
ARCH_EXYNOS4
diff --git a/board/samsung/axy17lte/Kconfig b/board/samsung/axy17lte/Kconfig
new file mode 100644
index 00..2abf8e7acf
--- /dev/null
+++ b/board/samsung/axy17lte/Kconfig
@@ -0,0 +1,58 @@
+config SYS_CONFIG_NAME
+ string "Board configuration name"
+ default "exynos78x0-common.h"
+ help
+ This option contains information about board configuration name.
+ Based on this option include/configs/.h header
+ will be used for board configuration.
+
+if TARGET_A5Y17LTE
+config SYS_BOARD
+ default "axy17lte"
+ help
+ a5y17lte is a production board for SM-A520F phone on Exynos7880 SoC.
+
+config SYS_VENDOR
+ default "samsung"
+
+config SYS_CONFIG_NAME
+ default "a5y17lte"
+
+config EXYNOS7880
+bool "Exynos 7880 SOC support"
+default y
+endif
+
+if TARGET_A7Y17LTE
+config SYS_BOARD
+ default "axy17lte
[PATCH 1/4] serial: samsung: add support for skip debug init in s5p
Signed-off-by: Dzmitry Sankouski
Cc: Minkyu Kang
---
drivers/serial/serial_s5p.c | 8 +---
1 file changed, 5 insertions(+), 3 deletions(-)
diff --git a/drivers/serial/serial_s5p.c b/drivers/serial/serial_s5p.c
index 6d09952a5d..caa9a4e5c1 100644
--- a/drivers/serial/serial_s5p.c
+++ b/drivers/serial/serial_s5p.c
@@ -221,10 +221,12 @@ U_BOOT_DRIVER(serial_s5p) = {
static inline void _debug_uart_init(void)
{
- struct s5p_uart *uart = (struct s5p_uart *)CONFIG_DEBUG_UART_BASE;
+ if (IS_ENABLED(CONFIG_DEBUG_UART_SKIP_INIT)) {
+ struct s5p_uart *uart = (struct s5p_uart
*)CONFIG_DEBUG_UART_BASE;
- s5p_serial_init(uart);
- s5p_serial_baud(uart, CONFIG_DEBUG_UART_CLOCK, CONFIG_BAUDRATE);
+ s5p_serial_init(uart);
+ s5p_serial_baud(uart, CONFIG_DEBUG_UART_CLOCK, CONFIG_BAUDRATE);
+ }
}
static inline void _debug_uart_putc(int ch)
--
2.20.1
[PATCH 2/4] pinctrl: exynos: add support for multiple pin banks
Iterate all pin banks to find a pin
Signed-off-by: Dzmitry Sankouski
Cc: Minkyu Kang
---
drivers/pinctrl/exynos/pinctrl-exynos.c | 28 +++--
1 file changed, 22 insertions(+), 6 deletions(-)
diff --git a/drivers/pinctrl/exynos/pinctrl-exynos.c
b/drivers/pinctrl/exynos/pinctrl-exynos.c
index 2640c8fcef..898185479b 100644
--- a/drivers/pinctrl/exynos/pinctrl-exynos.c
+++ b/drivers/pinctrl/exynos/pinctrl-exynos.c
@@ -5,6 +5,7 @@
* Thomas Abraham
*/
+#include
#include
#include
#include
@@ -38,9 +39,9 @@ static unsigned long pin_to_bank_base(struct udevice *dev,
const char *pin_name,
u32 *pin)
{
struct exynos_pinctrl_priv *priv = dev_get_priv(dev);
- const struct samsung_pin_ctrl *pin_ctrl = priv->pin_ctrl;
- const struct samsung_pin_bank_data *bank_data = pin_ctrl->pin_banks;
- u32 nr_banks = pin_ctrl->nr_banks, idx = 0;
+ const struct samsung_pin_ctrl *pin_ctrl_array = priv->pin_ctrl;
+ const struct samsung_pin_bank_data *bank_data;
+ u32 nr_banks, pin_ctrl_idx = 0, idx = 0, bank_base;
char bank[10];
/*
@@ -55,11 +56,26 @@ static unsigned long pin_to_bank_base(struct udevice *dev,
const char *pin_name,
*pin = pin_name[++idx] - '0';
/* lookup the pin bank data using the pin bank name */
- for (idx = 0; idx < nr_banks; idx++)
- if (!strcmp(bank, bank_data[idx].name))
+ while (true) {
+ const struct samsung_pin_ctrl *pin_ctrl =
&pin_ctrl_array[pin_ctrl_idx];
+
+ nr_banks = pin_ctrl->nr_banks;
+ if (!nr_banks)
break;
- return priv->base + bank_data[idx].offset;
+ bank_data = pin_ctrl->pin_banks;
+ for (idx = 0; idx < nr_banks; idx++) {
+ debug("pinctrl[%d] bank_data[%d] name is: %s\n",
+ pin_ctrl_idx, idx, bank_data[idx].name);
+ if (!strcmp(bank, bank_data[idx].name)) {
+ bank_base = priv->base + bank_data[idx].offset;
+ break;
+ }
+ }
+ pin_ctrl_idx++;
+ }
+
+ return bank_base;
}
/**
--
2.20.1
[PATCH 0/4] Add support for Samsung 2017 A-series phones
Samsung Galaxy A3, A5, A7 (2017) - middle class Samsung smartphones, powered by Exynos7880 (A5,A7) and Exynos7870 (A3) U-boot can be used as chain-loaded bootloader to gain control on booting vanilla linux(and possibly others) kernels. Samsung Exynos 7880 \ 7870 - SoC for mainstream smartphones and tablets introduced on March 2017. Features: - 8 Cortex A53 cores - ARM Mali-T830 MP3 GPU - LTE Cat. 7 (7880) or 6 (7870) modem Dzmitry Sankouski (4): serial: samsung: add support for skip debug init in s5p pinctrl: exynos: add support for multiple pin banks SoC: exynos: add support for exynos 78x0 board: samsung: add support for Galaxy A series of 2017 (a5y17lte) arch/arm/dts/Makefile | 3 + arch/arm/dts/exynos78x0-axy17lte.dts| 29 ++ arch/arm/dts/exynos78x0-gpio.dtsi | 204 ++ arch/arm/dts/exynos78x0-pinctrl.dtsi| 280 arch/arm/dts/exynos78x0.dtsi| 98 +++ arch/arm/mach-exynos/Kconfig| 28 ++ arch/arm/mach-exynos/mmu-arm64.c| 66 + board/samsung/axy17lte/Kconfig | 58 board/samsung/axy17lte/MAINTAINERS | 8 + board/samsung/axy17lte/Makefile | 3 + board/samsung/axy17lte/axy17lte.c | 11 + configs/a3y17lte_defconfig | 24 ++ configs/a5y17lte_defconfig | 24 ++ configs/a7y17lte_defconfig | 24 ++ doc/board/index.rst | 1 + doc/board/samsung/axy17lte.rst | 92 +++ doc/board/samsung/index.rst | 9 + drivers/gpio/s5p_gpio.c | 1 + drivers/pinctrl/exynos/Kconfig | 8 + drivers/pinctrl/exynos/Makefile | 1 + drivers/pinctrl/exynos/pinctrl-exynos.c | 28 +- drivers/pinctrl/exynos/pinctrl-exynos78x0.c | 119 + drivers/serial/serial_s5p.c | 8 +- include/configs/exynos78x0-common.h | 112 24 files changed, 1230 insertions(+), 9 deletions(-) create mode 100644 arch/arm/dts/exynos78x0-axy17lte.dts create mode 100644 arch/arm/dts/exynos78x0-gpio.dtsi create mode 100644 arch/arm/dts/exynos78x0-pinctrl.dtsi create mode 100644 arch/arm/dts/exynos78x0.dtsi create mode 100644 board/samsung/axy17lte/Kconfig create mode 100644 board/samsung/axy17lte/MAINTAINERS create mode 100644 board/samsung/axy17lte/Makefile create mode 100644 board/samsung/axy17lte/axy17lte.c create mode 100644 configs/a3y17lte_defconfig create mode 100644 configs/a5y17lte_defconfig create mode 100644 configs/a7y17lte_defconfig create mode 100644 doc/board/samsung/axy17lte.rst create mode 100644 doc/board/samsung/index.rst create mode 100644 drivers/pinctrl/exynos/pinctrl-exynos78x0.c create mode 100644 include/configs/exynos78x0-common.h -- 2.20.1
Re: [RFC 07/22] dm: blk: add UCLASS_PARTITION
On Mon, Oct 11, 2021 at 10:14:00AM -0600, Simon Glass wrote:
> Hi Heinrich,
>
> On Mon, 11 Oct 2021 at 09:02, Heinrich Schuchardt wrote:
> >
> >
> >
> > On 10/11/21 16:54, Simon Glass wrote:
> > > Hi Takahiro,
> > >
> > > On Sun, 10 Oct 2021 at 20:29, AKASHI Takahiro
> > > wrote:
> > >>
> > >> Heinrich,
> > >>
> > >> On Fri, Oct 08, 2021 at 10:23:52AM +0200, Heinrich Schuchardt wrote:
> > >>>
> > >>>
> > >>> On 10/8/21 02:51, AKASHI Takahiro wrote:
> > On Mon, Oct 04, 2021 at 12:27:59PM +0900, AKASHI Takahiro wrote:
> > > On Fri, Oct 01, 2021 at 11:30:37AM +0200, Heinrich Schuchardt wrote:
> > >>
> > >>
> > >> On 10/1/21 07:01, AKASHI Takahiro wrote:
> > >>> UCLASS_PARTITION device will be created as a child node of
> > >>> UCLASS_BLK device.
> > >>>
> > >>> Signed-off-by: AKASHI Takahiro
> > >>> ---
> > >>> drivers/block/blk-uclass.c | 111
> > >>> +
> > >>> include/blk.h | 9 +++
> > >>> include/dm/uclass-id.h | 1 +
> > >>> 3 files changed, 121 insertions(+)
> > >>>
> > >>> diff --git a/drivers/block/blk-uclass.c b/drivers/block/blk-uclass.c
> > >>> index 83682dcc181a..dd7f3c0fe31e 100644
> > >>> --- a/drivers/block/blk-uclass.c
> > >>> +++ b/drivers/block/blk-uclass.c
> > >>> @@ -12,6 +12,7 @@
> > >>> #include
> > >>> #include
> > >>> #include
> > >>> +#include
> > >>> #include
> > >>> #include
> > >>> #include
> > >>> @@ -695,6 +696,44 @@ int blk_unbind_all(int if_type)
> > >>>return 0;
> > >>> }
> > >>>
> > >>> +int blk_create_partitions(struct udevice *parent)
> > >>> +{
> > >>> + int part, count;
> > >>> + struct blk_desc *desc = dev_get_uclass_plat(parent);
> > >>> + struct disk_partition info;
> > >>> + struct disk_part *part_data;
> > >>> + char devname[32];
> > >>> + struct udevice *dev;
> > >>> + int ret;
> > >>> +
> > >>> + if (!CONFIG_IS_ENABLED(PARTITIONS) ||
> > >>> + !CONFIG_IS_ENABLED(HAVE_BLOCK_DEVICE))
> > >>> + return 0;
> > >>> +
> > >>> + /* Add devices for each partition */
> > >>> + for (count = 0, part = 1; part <= MAX_SEARCH_PARTITIONS;
> > >>> part++) {
> > >>> + if (part_get_info(desc, part, &info))
> > >>> + continue;
> > >>> + snprintf(devname, sizeof(devname), "%s:%d",
> > >>> parent->name,
> > >>> + part);
> > >>> +
> > >>> + ret = device_bind_driver(parent, "blk_partition",
> > >>> + strdup(devname), &dev);
> > >>> + if (ret)
> > >>> + return ret;
> > >>> +
> > >>> + part_data = dev_get_uclass_plat(dev);
> > >>> + part_data->partnum = part;
> > >>> + part_data->gpt_part_info = info;
> > >>> + count++;
> > >>> +
> > >>> + device_probe(dev);
> > >>> + }
> > >>> + debug("%s: %d partitions found in %s\n", __func__, count,
> > >>> parent->name);
> > >>> +
> > >>> + return 0;
> > >>> +}
> > >>> +
> > >>> static int blk_post_probe(struct udevice *dev)
> > >>> {
> > >>>if (IS_ENABLED(CONFIG_PARTITIONS) &&
> > >>> @@ -713,3 +752,75 @@ UCLASS_DRIVER(blk) = {
> > >>>.post_probe = blk_post_probe,
> > >>>.per_device_plat_auto = sizeof(struct blk_desc),
> > >>> };
> > >>> +
> > >>> +static ulong blk_part_read(struct udevice *dev, lbaint_t start,
> > >>> +lbaint_t blkcnt, void *buffer)
> > >>> +{
> > >>> + struct udevice *parent;
> > >>> + struct disk_part *part;
> > >>> + const struct blk_ops *ops;
> > >>> +
> > >>> + parent = dev_get_parent(dev);
> > >>
> > >> What device type will the parent have if it is a eMMC hardware
> > >> partition?
> > >>
> > >>> + ops = blk_get_ops(parent);
> > >>> + if (!ops->read)
> > >>> + return -ENOSYS;
> > >>> +
> > >>> + part = dev_get_uclass_plat(dev);
> > >>
> > >> You should check that we do not access the block device past the
> > >> partition end:
> > >
> > > Yes, I will fix all of checks.
> > >
> > >> struct blk_desc *desc = dev_get_uclass_plat(parent);
> > >> if ((start + blkcnt) * desc->blksz < part->gpt_part_info.blksz)
> > >> return -EFAULT.
> > >>
> > >>> + start += part->gpt_part_info.start;
> >
> > A better solution is:
> > if (start >= part->gpt_part_info.size)
> > return 0;
> >
> > if ((start + blkcnt) > part->gpt_part_info.size)
> >
Re: [PATCH] stm32mp: add binman support for STM32MP15x
Hi,
On 10/8/21 9:34 AM, Patrick Delaunay wrote:
Use binman to add the stm32image header on SPL binary for basic boot
or on U-Boot binary when it is required, i.e. for TF-A boot without FIP
support, when CONFIG_STM32MP15x_STM32IMAGE is activated.
The "binman" tool is the recommended tool for specific image generation.
This patch allows to suppress the config.mk file and it is a preliminary
step to manage FIT generation with binman.
Signed-off-by: Patrick Delaunay
---
arch/arm/dts/stm32mp15-u-boot.dtsi | 29 +
arch/arm/mach-stm32mp/Kconfig | 1 +
arch/arm/mach-stm32mp/config.mk| 29 -
3 files changed, 30 insertions(+), 29 deletions(-)
delete mode 100644 arch/arm/mach-stm32mp/config.mk
diff --git a/arch/arm/dts/stm32mp15-u-boot.dtsi
b/arch/arm/dts/stm32mp15-u-boot.dtsi
index 43a7909978..db23d80eef 100644
--- a/arch/arm/dts/stm32mp15-u-boot.dtsi
+++ b/arch/arm/dts/stm32mp15-u-boot.dtsi
@@ -21,6 +21,10 @@
pinctrl1 = &pinctrl_z;
};
+ binman: binman {
+ multiple-images;
+ };
+
clocks {
u-boot,dm-pre-reloc;
};
@@ -228,3 +232,28 @@
resets = <&rcc UART8_R>;
};
+#if defined(CONFIG_STM32MP15x_STM32IMAGE)
+&binman {
+ u-boot-stm32 {
+ filename = "u-boot.stm32";
+ mkimage {
+ args = "-T stm32image -a 0xC010 -e 0xC010";
+ u-boot {
+ };
+ };
+ };
+};
+#endif
+
+#if defined(CONFIG_SPL)
+&binman {
+ spl-stm32 {
+ filename = "u-boot-spl.stm32";
+ mkimage {
+ args = "-T stm32image -a 0x2FFC2500 -e 0x2FFC2500";
+ u-boot-spl {
+ };
+ };
+ };
+};
+#endif
diff --git a/arch/arm/mach-stm32mp/Kconfig b/arch/arm/mach-stm32mp/Kconfig
index 69d56c23e1..4acb29333c 100644
--- a/arch/arm/mach-stm32mp/Kconfig
+++ b/arch/arm/mach-stm32mp/Kconfig
@@ -37,6 +37,7 @@ config STM32MP15x
bool "Support STMicroelectronics STM32MP15x Soc"
select ARCH_SUPPORT_PSCI if !TFABOOT
select ARM_SMCCC if TFABOOT
+ select BINMAN
select CPU_V7A
select CPU_V7_HAS_NONSEC if !TFABOOT
select CPU_V7_HAS_VIRT
diff --git a/arch/arm/mach-stm32mp/config.mk b/arch/arm/mach-stm32mp/config.mk
deleted file mode 100644
index f7f5b77c41..00
--- a/arch/arm/mach-stm32mp/config.mk
+++ /dev/null
@@ -1,29 +0,0 @@
-# SPDX-License-Identifier: GPL-2.0+ OR BSD-3-Clause
-#
-# Copyright (C) 2018, STMicroelectronics - All Rights Reserved
-#
-
-ifndef CONFIG_SPL
-INPUTS-$(CONFIG_STM32MP15x_STM32IMAGE) += u-boot.stm32
-else
-ifdef CONFIG_SPL_BUILD
-INPUTS-y += u-boot-spl.stm32
-endif
-endif
-
-MKIMAGEFLAGS_u-boot.stm32 = -T stm32image -a $(CONFIG_SYS_TEXT_BASE) -e
$(CONFIG_SYS_TEXT_BASE)
-
-u-boot.stm32: MKIMAGEOUTPUT = u-boot.stm32.log
-
-u-boot.stm32: u-boot.bin FORCE
- $(call if_changed,mkimage)
-
-MKIMAGEFLAGS_u-boot-spl.stm32 = -T stm32image -a $(CONFIG_SPL_TEXT_BASE) -e
$(CONFIG_SPL_TEXT_BASE)
-
-spl/u-boot-spl.stm32: MKIMAGEOUTPUT = spl/u-boot-spl.stm32.log
-
-spl/u-boot-spl.stm32: spl/u-boot-spl.bin FORCE
- $(call if_changed,mkimage)
-
-u-boot-spl.stm32 : spl/u-boot-spl.stm32
- $(call if_changed,copy)
The binary are correctly managed for basic boot or trusted boot (TFABOOT
with STM32IMAGE support)
but the TF-A boot with FIP failed with the error:
NOTICE: CPU: STM32MP157CAC Rev.B
NOTICE: Model: STMicroelectronics STM32MP157C-DK2 Discovery Board
NOTICE: Board: MB1272 Var2.0 Rev.C-01
NOTICE: BL2: v2.5(release):v2.5-614-g40358fc54
NOTICE: BL2: Built : 14:54:35, Oct 12 2021
NOTICE: BL2: Booting BL32
I/TC: Early console on UART#4
I/TC:
I/TC: Pager is enabled. Hashes: 2176 bytes
I/TC: Pager pool size: 96kB
I/TC: Non-secure external DT found
I/TC: Embedded DTB found
I/TC: OP-TEE version: 3.15.0-rc1-1-g96c7b633b (gcc version 9.3.0 (GCC))
#1 Tue Oct 12 14:56:25 UTC 2021 arm
I/TC: Primary CPU initializing
I/TC: Platform stm32mp1: flavor PLATFORM_FLAVOR - DT stm32mp157c-dk2.dts
I/TC: RCC is non-secure
I/TC: DTB enables console (non-secure)
I/TC: Primary CPU switching to normal world boot
U-Boot 2021.10-00609-gbd6c2d38d1 (Oct 12 2021 - 16:59:42 +0200)
CPU: STM32MP157CAC Rev.B
Model: STMicroelectronics STM32MP157C-DK2 Discovery Board
Board: stm32mp1 in trusted mode (st,stm32mp157c-dk2)
Board: MB1272 Var2.0 Rev.C-01
DRAM: 512 MiB
Clocks:
- MPU : 650 MHz
- MCU : 208.878 MHz
- AXI : 266.500 MHz
- PER : 24 MHz
- DDR : 533 MHz
binman_init failed:-2
initcall sequence ddce91b8 failed at call c011a825 (err=-2)
### ERROR ### Please RESET the board ###
=> after analysis, the CONFIG_BINMAN_FDT should be deactivated
as STM32MP15x U-Boot have no reason to parse the binman node
(no binary to select or to load) = the binman library can be
deactivated
I will add in V2
# CONFI
Re: [PATCH 2/2] dt-bindings: u-boot: Add an initial binding for config
On Tue, Oct 12, 2021 at 8:41 AM Simon Glass wrote: > > Hi Rob, > > On Mon, 4 Oct 2021 at 13:30, Rob Herring wrote: > > > > On Sun, Oct 03, 2021 at 12:51:53PM -0600, Simon Glass wrote: > > > U-Boot makes use of the devicetree for its driver model. Devices are bound > > > based on the hardware description in the devicetree. > > > > > > Since U-Boot is not an operating system, it has no command line or user > > > space to provide configuration and policy information. This must be made > > > available in some other way. > > > > > > Therefore U-Boot uses devicetree for configuration and run-time control > > > and has done for approximately 9 years. This works extremely well in the > > > project and is very flexible. However the bindings have never been > > > incorporated in the devicetree bindings in the Linux tree. This could be > > > a good time to start this work as we try to create standard bindings for > > > communicating between firmware components. > > > > > > Add an initial binding for this node, covering just the config node, which > > > is the main requirement. It is similar in concept to the chosen node, but > > > used for passing information between firmware components, instead of from > > > firmware to operating system. > > > > > > Signed-off-by: Simon Glass > > > --- > > > Please be kind in your review. Some words about why this is needed are > > > included in the description in config.yaml file. > > > > > > The last attempt to add just one property needed by U-Boot went into the > > > weeds 6 years ago, with what I see as confusion about the role of the > > > chosen node in devicetree[1]. > > > > > > I am trying again in the hope of reaching resolution rather than just > > > going around in circles with the 'devicetree is a hardware description' > > > argument :-) > > > > > > Quoting from the introduction to latest devicetree spec[2]: > > > > > > >>> > > > To initialize and boot a computer system, various software components > > > interact. Firmware might perform low-level initialization of the system > > > hardware before passing control to software such as an operating system, > > > bootloader, or hypervisor. Bootloaders and hypervisors can, in turn, > > > load and transfer control to operating systems. Standard, consistent > > > interfaces and conventions facilitate the interactions between these > > > software components. In this document the term boot program is used to > > > generically refer to a software component that initializes the system > > > state and executes another software component referred to as a client > > > program. > > > <<< > > > > > > This clearly envisages multiple software components in the firmware > > > domain and in fact that is the case today. They need some way to > > > communicate configuration data such as memory setup, runtime-feature > > > selection and developer conveniences. Devicetree seems ideal, at least for > > > components where the performance / memory requirements of devicetree are > > > affordable. > > > > > > I hope that the Linux community (which owns the devicetree bindings) finds > > > this initiative valuable and acceptable. > > > > Owns? I'm having a sale and can make you a good offer. Buy 1 binding, > > get 2000 free. :) > > Yes, it's the price of that first binding that surely puts everyone off. > > (sorry for sitting on this for a week, my spam filter doesn't like > some mailing lists and I'm working on it) > > > > > > > > > [1] https://lists.denx.de/pipermail/u-boot/2015-July/218585.html > > > [2] > > > https://github.com/devicetree-org/devicetree-specification/releases/tag/v0.3 > > > > > > .../devicetree/bindings/u-boot/config.yaml| 137 ++ > > > 1 file changed, 137 insertions(+) > > > create mode 100644 Documentation/devicetree/bindings/u-boot/config.yaml > > > > Might as well put this into dt-schema rather than the kernel. But might > > get more review here first. > > OK, so does that mean a PR to https://github.com/robherring/dt-schema Wrong one: https://github.com/devicetree-org/dt-schema I need to update the readme there for the old one. > or is there a mailing list for it? I think I am missing some > understanding here. You can send a PR or to a DT mailing list, but the mail list will get more reviews (hopefully). devicetree-spec is better than devicetree as it is not a firehose. > > > > > diff --git a/Documentation/devicetree/bindings/u-boot/config.yaml > > > b/Documentation/devicetree/bindings/u-boot/config.yaml > > > new file mode 100644 > > > index 00..336577a17fdf5a > > > --- /dev/null > > > +++ b/Documentation/devicetree/bindings/u-boot/config.yaml > > > @@ -0,0 +1,137 @@ > > > +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) > > > +%YAML 1.2 > > > +--- > > > +$id: http://devicetree.org/schemas/u-boot/config.yaml# > > > +$schema: http://devicetree.org/meta-schemas/core.yaml# > > > + > > > +title: U-Boot configuration node > > > + > > > +maintainers: > > > + - Simon Glass > >
Re: [RFC 00/22] efi_loader: more tightly integrate UEFI disks to device model
On Sun, Oct 10, 2021 at 08:14:00AM -0600, Simon Glass wrote: > Hi Takahiro, > > On Thu, 30 Sept 2021 at 23:02, AKASHI Takahiro > wrote: > > > > The purpose of this RPC is to reignite the discussion about how UEFI > > subystem would best be integrated into U-Boot device model. > > In the past, I poposed a couple of patch series, the latest one[1], > > while Heinrich revealed his idea[2], and the approach taken here is > > something between them, with a focus on block device handlings. > > > > # The code is a PoC and not well tested yet. > > > > Disks in UEFI world: > > > > In general in UEFI world, accessing to any device is performed through > > a 'protocol' interface which are installed to (or associated with) the > > device's > > UEFI handle (or an opaque pointer to UEFI object data). Protocols are > > implemented by either the UEFI system itself or UEFI drivers. > > > > For block IO's, it is a device which has EFI_BLOCK_IO_PROTOCOL (efi_disk > > hereafter). Currently, every efi_disk may have one of two origins: > > a.U-Boot's block devices or related partitions > > (lib/efi_loader/efi_disk.c) > > b.UEFI objects which are implemented as a block device by UEFI drivers. > > (lib/efi_driver/efi_block_device.c) > > > > All the efi_diskss as (a) will be enumelated and created only once at UEFI > > subsystem initialization (efi_disk_register()), which is triggered by > > first executing one of UEFI-related U-Boot commands, like "bootefi", > > "setenv -e" or "efidebug". > > EFI_BLOCK_IO_PROTOCOL is implemented by UEFI system using blk_desc(->ops) > > in the corresponding udevice(UCLASS_BLK). > > > > On the other hand, efi_disk as (b) will be created each time UEFI boot > > services' connect_controller() is executed in UEFI app which, as a (device) > > controller, gives the method to access the device's data, > > ie. EFI_BLOCK_IO_PROTOCOL. > > > > >>> more details >>> > > Internally, connect_controller() search for UEFI driver that can support > > this controller/protocol, 'efi_block' driver(UCLASS_EFI) in this case, > > then calls the driver's 'bind' interface, which eventually installs > > the controller's EFI_BLOCK_IO_PROTOCOL to efi_disk object. > > 'efi_block' driver also create a corresponding udevice(UCLASS_BLK) for > > * creating additional partitions efi_disk's, and > > * supporting a file system (EFI_SIMPLE_FILE_SYSTEM_PROTOCOL) on it. > > <<< <<< > > > > Issues: > > === > > 1. While an efi_disk represents a device equally for either a whole disk > >or a partition in UEFI world, the device model treats only a whole > >disk as a real block device or udevice(UCLASS_BLK). > > > > 2. efi_disk holds and makes use of "blk_desc" data even though blk_desc > >in plat_data is supposed to be private and not to be accessed outside > >the device model. > ># This issue, though, exists for all the implmenetation of U-Boot > ># file systems as well. > > Yes, this was a migration convenience and we should be able to unpick it now. > > However we still have SPL_BLK so need to consider whether we can drop that. To be clear here, in that I can hand-wave my way to seeing a use case for lib/efi_loader/ under SPL, it would not be in a world where we also still would be supporting the non-DM infrastructure, and is also not a near-term goal. -- Tom signature.asc Description: PGP signature
[PULL] Pull request for u-boot next / v2022.01 = u-boot-stm32-20211012
Hi Tom Please pull the STM32 related patches for u-boot/next, v2022.01: u-boot-stm32-20211012 CI status: https://source.denx.de/u-boot/custodians/u-boot-stm/-/pipelines/9455 Thanks Patrice The following changes since commit d80bb749fab53da72c4a0e09b8c2d2aaa3103c91: Prepare v2021.10 (2021-10-04 11:09:26 -0400) are available in the Git repository at: https://source.denx.de/u-boot/custodians/u-boot-stm.git tags/u-boot-stm32-20211012 for you to fetch changes up to 39bd2c8e1aa9143c22f1fd20d054fc895a0880d2: test/py: Add usb gadget binding test (2021-10-12 14:20:04 +0200) - Disable ATAGS for STM32 MCU and MPU boards - Disable bi_boot_params for STM32 MCU and MPU boards - Update stm32-usbphyc node management - Convert CONFIG_STM32_FLASH to Kconfig for STM32 MCU boards - Convert some USB config flags to Kconfig for various boards - Convert CONFIG_BOOTCOMMAND flag to Kconfig for STM32 F429 board - Remove specific CONFIG_STV0991 flags - Remove unused CONFIG_USER_LOWLEVEL_INIT flag - Add ofdata_to_platdata() callback for stm32_spi driver - Update for stm32f7_i2c driver - Remove gpio_hog_probe_all() from STM32 MP1 board - Fix bind command Marek Vasut (1): Revert "configs: stm32mp1: only support SD card after NOR in bootcmd_stm32mp" Patrice Chotard (10): spi: stm32: Add ofdata_to_platdata() callback arm: dts: stm32: Add i2c-analog-filter property in I2C nodes for stm32f746 arm: dts: stm32: Add i2c-analog-filter property in I2C nodes for stm32h743 board: stm32mp1: Remove gpio_hog_probe_all() from board board: dh_stm32mp1: Remove gpio_hog_probe_all() from board cmd: bind: Fix driver binding on a device usb: gadget: Add bcdDevice for the DWC2 USB Gadget Controller usb: sandbox: Add gadget callbacks configs: sandbox: add USB_ETHER and GADGET_DOWNLOAD gadget support test/py: Add usb gadget binding test Patrick Delaunay (14): arm: stm32: Disable ATAGs support board: stm32: Remove the bi_boot_params initialization phy: stm32-usbphyc: use connector for vbus-supply with phy-stm32-usbphyc phy: stm32-usbphyc: stm32: usbphyc: add protection on phy sub-node Convert CONFIG_STM32_FLASH to Kconfig configs: Move some usb config in defconfig stm32f429: move CONFIG_BOOTCOMMAND in defconfig stv0991: remove specific CONFIG_STV0991 configs pm9263: Remove unused CONFIG_USER_LOWLEVEL_INIT i2c: stm32f7: move driver data of each instance in a privdata i2c: stm32f7: support DT binding i2c-analog-filter i2c: stm32f7: fix configuration of the digital filter i2c: stm32f7: add support for DNF i2c-digital-filter binding i2c: stm32f7: compute i2cclk only one time arch/arm/cpu/armv7/stv0991/timer.c | 6 +- arch/arm/dts/stm32f746.dtsi| 4 + arch/arm/dts/stm32h743.dtsi| 4 + arch/arm/include/asm/arch-stv0991/stv0991_gpt.h| 4 +- board/congatec/cgtqmx8/spl.c | 2 +- board/dhelectronics/dh_stm32mp1/board.c| 6 - board/engicam/stm32mp1/stm32mp1.c | 3 - board/st/stm32f429-discovery/stm32f429-discovery.c | 2 - .../st/stm32f429-evaluation/stm32f429-evaluation.c | 2 - board/st/stm32f469-discovery/stm32f469-discovery.c | 2 - board/st/stm32f746-disco/stm32f746-disco.c | 2 - board/st/stm32h743-disco/stm32h743-disco.c | 1 - board/st/stm32h743-eval/stm32h743-eval.c | 1 - board/st/stm32h750-art-pi/stm32h750-art-pi.c | 1 - board/st/stm32mp1/stm32mp1.c | 6 - cmd/bind.c | 2 +- configs/dh_imx6_defconfig | 2 + configs/kp_imx6q_tpc_defconfig | 2 + configs/mx53ppd_defconfig | 4 + configs/sandbox_defconfig | 4 + configs/stih410-b2260_defconfig| 4 + configs/stm32f429-discovery_defconfig | 2 + configs/stm32f429-evaluation_defconfig | 1 + configs/stm32f469-discovery_defconfig | 1 + configs/stm32f746-disco_defconfig | 1 + configs/stm32f769-disco_defconfig | 1 + configs/stv0991_defconfig | 1 - drivers/core/device.c | 2 +- drivers/core/lists.c | 4 +- drivers/core/root.c| 2 +- drivers/i2c/stm32f7_i2c.c | 91 + drivers/misc/imx8/scu.c| 2 +- drivers/mtd/Kconfig| 7 + drivers/phy/phy-stm32-usbphyc.c| 34 ++-- drivers/serial/serial-uclass.c | 2 +
Re: [RFC 14/22] efi_loader: disk: a helper function to create efi_disk objects from udevice
Hi Akashi,
On Mon, 11 Oct 2021 at 19:09, AKASHI Takahiro
wrote:
>
> Simon,
>
> On Mon, Oct 11, 2021 at 08:54:06AM -0600, Simon Glass wrote:
> > Hi Takahiro,
> >
> > On Mon, 11 Oct 2021 at 00:52, AKASHI Takahiro
> > wrote:
> > >
> > > On Sun, Oct 10, 2021 at 08:14:21AM -0600, Simon Glass wrote:
> > > > On Thu, 30 Sept 2021 at 23:04, AKASHI Takahiro
> > > > wrote:
> > > > >
> > > > > Add efi_disk_create() function.
> > > > >
> > > > > Any UEFI handle created by efi_disk_create() can be treated as a
> > > > > efi_disk
> > > > > object, the udevice is either a UCLASS_BLK (a whole raw disk) or
> > > > > UCLASS_PARTITION (a disk partition).
> > > > >
> > > > > So this function is expected to be called every time such an udevice
> > > > > is detected and activated through a device model's "probe" interface.
> > > > >
> > > > > Signed-off-by: AKASHI Takahiro
> > > > > ---
> > > > > include/efi_loader.h | 2 +
> > > > > lib/efi_loader/efi_disk.c | 92
> > > > > +++
> > > > > 2 files changed, 94 insertions(+)
> > > > >
> > > >
> > > > Reviewed-by: Simon Glass
> > > >
> > > > But some nits below.
> > > >
> > > > Don't worry about !CONFIG_BLK - that code should be removed.
> > >
> > > Yes. I added a tentative patch to remove !CONFIG_BLK code in efi_disk
> > > in patch#13.
> > >
> > >
> > > > > diff --git a/include/efi_loader.h b/include/efi_loader.h
> > > > > index c440962fe522..751fde7fb153 100644
> > > > > --- a/include/efi_loader.h
> > > > > +++ b/include/efi_loader.h
> > > > > @@ -517,6 +517,8 @@ efi_status_t EFIAPI
> > > > > efi_convert_pointer(efi_uintn_t debug_disposition,
> > > > > void efi_carve_out_dt_rsv(void *fdt);
> > > > > /* Called by bootefi to make console interface available */
> > > > > efi_status_t efi_console_register(void);
> > > > > +/* Called when a block devices has been probed */
> > > > > +int efi_disk_create(struct udevice *dev);
> > > >
> > > > Please buck the trend in this file and add a full function comment. In
> > > > this case it needs to cover @dev and the return value and also explain
> > > > what the function does.
> > >
> > > OK.
> > >
> > > > > /* Called by bootefi to make all disk storage accessible as EFI
> > > > > objects */
> > > > > efi_status_t efi_disk_register(void);
> > > > > /* Called by efi_init_obj_list() to install EFI_RNG_PROTOCOL */
> > > > > diff --git a/lib/efi_loader/efi_disk.c b/lib/efi_loader/efi_disk.c
> > > > > index cd5528046251..3fae40e034fb 100644
> > > > > --- a/lib/efi_loader/efi_disk.c
> > > > > +++ b/lib/efi_loader/efi_disk.c
> > > > > @@ -10,6 +10,7 @@
> > > > > #include
> > > > > #include
> > > > > #include
> > > > > +#include
> > > > > #include
> > > > > #include
> > > > > #include
> > > > > @@ -484,6 +485,7 @@ error:
> > > > > return ret;
> > > > > }
> > > > >
> > > > > +#ifndef CONFIG_BLK
> > > > > /**
> > > > > * efi_disk_create_partitions() - create handles and protocols for
> > > > > partitions
> > > > > *
> > > > > @@ -531,6 +533,96 @@ int efi_disk_create_partitions(efi_handle_t
> > > > > parent, struct blk_desc *desc,
> > > > >
> > > > > return disks;
> > > > > }
> > > > > +#endif /* CONFIG_BLK */
> > > > > +
> > > > > +/*
> > > > > + * Create a handle for a whole raw disk
> > > > > + *
> > > > > + * @devuclass device
> > > >
> > > > ?? what type of device?
> > >
> > > (Will fix: UCLASS_BLK)
> > >
> > >
> > > > > + * @return 0 on success, -1 otherwise
> > > > > + */
> > > > > +static int efi_disk_create_raw(struct udevice *dev)
> > > > > +{
> > > > > + struct efi_disk_obj *disk;
> > > > > + struct blk_desc *desc;
> > > > > + const char *if_typename;
> > > > > + int diskid;
> > > > > + efi_status_t ret;
> > > > > +
> > > > > + desc = dev_get_uclass_plat(dev);
> > > > > + if_typename = blk_get_if_type_name(desc->if_type);
> > > > > + diskid = desc->devnum;
> > > > > +
> > > > > + ret = efi_disk_add_dev(NULL, NULL, if_typename, desc,
> > > > > + diskid, NULL, 0, &disk);
> > > > > + if (ret != EFI_SUCCESS) {
> > > >
> > > > if (ret)
> > > >
> > > > is much shorter and easier to read
> > >
> > > Yeah, but I don't want to assume EFI_SUCCESS is *zero*.
> >
> > It is defined as 0 in 'Appendix D - Status Code' and cannot change, as
> > I understand it. This is one of the things I don't like about the EFI
> > code in U-Boot. Presumably the people who wrote the spec defined it as
> > 0 to make use of C constructs.
>
> Yeah, I confirmed that, but still want to keep the code
> as "ret != EFI_SUCCESS" is used everywhere in UEFI code :)
OK that can be a clean-up for another day, along with the overly long
types and naming in general.
At least we managed to avoid all the capital letters and camel case...
Regards,
Simon
[PATCH v2] dt-bindings: u-boot: Add an initial binding for config
U-Boot makes use of the devicetree for its driver model. Devices are bound based on the hardware description in the devicetree. Since U-Boot is not an operating system, it has no command line or user space to provide configuration and policy information. This must be made available in some other way. Therefore U-Boot uses devicetree for configuration and run-time control and has done for approximately 9 years. This works extremely well in the project and is very flexible. However the bindings have never been incorporated in the devicetree bindings in the Linux tree. This could be a good time to start this work as we try to create standard bindings for communicating between firmware components. Add an initial binding for this node, covering just the config node, which is the main requirement. It is similar in concept to the chosen node, but used for passing information between firmware components, instead of from firmware to operating system. Signed-off-by: Simon Glass --- Please be kind in your review. Some words about why this is needed are included in the description in config.yaml file. The last attempt to add just one property needed by U-Boot went into the weeds 6 years ago, with what I see as confusion about the role of the chosen node in devicetree[1]. I am trying again in the hope of reaching resolution rather than just going around in circles with the 'devicetree is a hardware description' argument :-) Quoting from the introduction to latest devicetree spec[2]: >>> To initialize and boot a computer system, various software components interact. Firmware might perform low-level initialization of the system hardware before passing control to software such as an operating system, bootloader, or hypervisor. Bootloaders and hypervisors can, in turn, load and transfer control to operating systems. Standard, consistent interfaces and conventions facilitate the interactions between these software components. In this document the term boot program is used to generically refer to a software component that initializes the system state and executes another software component referred to as a client program. <<< This clearly envisages multiple software components in the firmware domain and in fact that is the case today. They need some way to communicate configuration data such as memory setup, runtime-feature selection and developer conveniences. Devicetree seems ideal, at least for components where the performance / memory requirements of devicetree are affordable. I hope that the Linux community (which owns the devicetree bindings) finds this initiative valuable and acceptable. [1] https://lists.denx.de/pipermail/u-boot/2015-July/218585.html [2] https://github.com/devicetree-org/devicetree-specification/releases/tag/v0.3 Changes in v2: - Update chosen.txt to chosen.yaml - Drop quotes on u-boot,config - Rename bootdelay to bootdelay-sec and drop type - Add default and maximum to bootsecure, silent-console .../devicetree/bindings/u-boot/config.yaml| 143 ++ 1 file changed, 143 insertions(+) create mode 100644 Documentation/devicetree/bindings/u-boot/config.yaml diff --git a/Documentation/devicetree/bindings/u-boot/config.yaml b/Documentation/devicetree/bindings/u-boot/config.yaml new file mode 100644 index 00..fe8ee6ecaf9cd2 --- /dev/null +++ b/Documentation/devicetree/bindings/u-boot/config.yaml @@ -0,0 +1,143 @@ +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/u-boot/config.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: U-Boot configuration node + +maintainers: + - Simon Glass + +description: | + The config node does not represent a real device, but serves as a place + for passing data between firmware elements, like memory maps. Data in the + config node does not represent the hardware. It is ignored by operating + systems. + + Purpose of config node + -- + + A common problem with firmware is that many builds are needed to deal with the + slight variations between different, related models. For example, one model + may have a TPM and another may not. Devicetree provides an excellent solution + to this problem, in that the devicetree to actually use on a platform can be + injected in the factory based on which model is being manufactured at the time. + + A related problem causing build proliferation is dealing with the differences + between development firmware, developer-friendly firmware (e.g. with all + security features present but with the ability to access the command line), + test firmware (which runs tests used in the factory), final production + firmware (before signing), signed firmware (where the signatures have been + inserted) and the like. Ideally all or most of these should use the same + U-Boot build, with just some options to determine the features available. For + example, being able to control whether the UART consol
Re: [PATCH 2/2] dt-bindings: u-boot: Add an initial binding for config
Hi Rob, On Mon, 4 Oct 2021 at 13:30, Rob Herring wrote: > > On Sun, Oct 03, 2021 at 12:51:53PM -0600, Simon Glass wrote: > > U-Boot makes use of the devicetree for its driver model. Devices are bound > > based on the hardware description in the devicetree. > > > > Since U-Boot is not an operating system, it has no command line or user > > space to provide configuration and policy information. This must be made > > available in some other way. > > > > Therefore U-Boot uses devicetree for configuration and run-time control > > and has done for approximately 9 years. This works extremely well in the > > project and is very flexible. However the bindings have never been > > incorporated in the devicetree bindings in the Linux tree. This could be > > a good time to start this work as we try to create standard bindings for > > communicating between firmware components. > > > > Add an initial binding for this node, covering just the config node, which > > is the main requirement. It is similar in concept to the chosen node, but > > used for passing information between firmware components, instead of from > > firmware to operating system. > > > > Signed-off-by: Simon Glass > > --- > > Please be kind in your review. Some words about why this is needed are > > included in the description in config.yaml file. > > > > The last attempt to add just one property needed by U-Boot went into the > > weeds 6 years ago, with what I see as confusion about the role of the > > chosen node in devicetree[1]. > > > > I am trying again in the hope of reaching resolution rather than just > > going around in circles with the 'devicetree is a hardware description' > > argument :-) > > > > Quoting from the introduction to latest devicetree spec[2]: > > > > >>> > > To initialize and boot a computer system, various software components > > interact. Firmware might perform low-level initialization of the system > > hardware before passing control to software such as an operating system, > > bootloader, or hypervisor. Bootloaders and hypervisors can, in turn, > > load and transfer control to operating systems. Standard, consistent > > interfaces and conventions facilitate the interactions between these > > software components. In this document the term boot program is used to > > generically refer to a software component that initializes the system > > state and executes another software component referred to as a client > > program. > > <<< > > > > This clearly envisages multiple software components in the firmware > > domain and in fact that is the case today. They need some way to > > communicate configuration data such as memory setup, runtime-feature > > selection and developer conveniences. Devicetree seems ideal, at least for > > components where the performance / memory requirements of devicetree are > > affordable. > > > > I hope that the Linux community (which owns the devicetree bindings) finds > > this initiative valuable and acceptable. > > Owns? I'm having a sale and can make you a good offer. Buy 1 binding, > get 2000 free. :) Yes, it's the price of that first binding that surely puts everyone off. (sorry for sitting on this for a week, my spam filter doesn't like some mailing lists and I'm working on it) > > > > > [1] https://lists.denx.de/pipermail/u-boot/2015-July/218585.html > > [2] > > https://github.com/devicetree-org/devicetree-specification/releases/tag/v0.3 > > > > .../devicetree/bindings/u-boot/config.yaml| 137 ++ > > 1 file changed, 137 insertions(+) > > create mode 100644 Documentation/devicetree/bindings/u-boot/config.yaml > > Might as well put this into dt-schema rather than the kernel. But might > get more review here first. OK, so does that mean a PR to https://github.com/robherring/dt-schema or is there a mailing list for it? I think I am missing some understanding here. > > > diff --git a/Documentation/devicetree/bindings/u-boot/config.yaml > > b/Documentation/devicetree/bindings/u-boot/config.yaml > > new file mode 100644 > > index 00..336577a17fdf5a > > --- /dev/null > > +++ b/Documentation/devicetree/bindings/u-boot/config.yaml > > @@ -0,0 +1,137 @@ > > +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) > > +%YAML 1.2 > > +--- > > +$id: http://devicetree.org/schemas/u-boot/config.yaml# > > +$schema: http://devicetree.org/meta-schemas/core.yaml# > > + > > +title: U-Boot configuration node > > + > > +maintainers: > > + - Simon Glass > > + > > +description: | > > + The config node does not represent a real device, but serves as a place > > + for passing data between firmware elements, like memory maps. Data in the > > + config node does not represent the hardware. It is ignored by operating > > + systems. > > + > > + Purpose of config node > > + -- > > + > > + A common problem with firmware is that many builds are needed to deal > > with the > > + slight variations between different, related models. For example, one > > model > >
Re: [RFC 01/22] part: call part_init() in blk_get_device_by_str() only for MMC
On 10/12/21 05:26, AKASHI Takahiro wrote: Simon, Heinrich, On Mon, Oct 11, 2021 at 10:14:02AM -0600, Simon Glass wrote: Hi Heinrich, On Mon, 11 Oct 2021 at 09:09, Heinrich Schuchardt wrote: On 10/11/21 16:32, Simon Glass wrote: Hi Heinrich, On Mon, 11 Oct 2021 at 04:07, Heinrich Schuchardt wrote: On 10/1/21 13:48, Peter Robinson wrote: On Fri, Oct 1, 2021 at 6:03 AM AKASHI Takahiro wrote: In blk_get_device_by_str(), the comment says: "Updates the partition table for the specified hw partition." Since hw partition is supported only on MMC, it makes no sense to do so for other devices. Is it not also supported on UFS, and I believe it may also be an option in the NVME spec too. An NVMe device may expose multiple namespaces. blk_create_devicef() is called for each namespace. A SCSI device may have multiple LUNs. blk_create_devicef() is called for each LUN. This is what the tree shown by 'dm tree' with on NVMe namespace and one LUN. Class Index Driver Name - root 0 root_driverroot_driver simple_bus 0 simple_bus |- soc spi1 sifive_spi | |- spi@1005 mmc0 mmc_spi| | `- mmc@0 blk0 mmc_blk| | `- m...@0.blk pci0 pcie_sifive| |- pcie@e pci1 pci_bridge_drv | | `- pci_0:0.0 pci2 pci_bridge_drv | | `- pci_1:0.0 pci5 pci_bridge_drv | ||- pci_2:3.0 ahci 0 ahci_pci | || `- ahci_pci scsi 0 ahci_scsi | || `- ahci_scsi blk2 scsi_blk | ||`- ahci_scsi.id0lun0 pci6 pci_bridge_drv | ||- pci_2:4.0 nvme 0 nvme | || `- nvme#0 blk1 nvme-blk | || `- nvme#0.blk#1 Namespaces and LUNs are modeled as block devices (class = 'blk'). So multiple block devices per NVMe device? I did not know that was supported. We need a sandbox driver for NVMe as it has no tests at present. Since it has no tests, I don't think we can expect people to know how to maintain whatever functionality is there. NVMe drives with multiple namespaces exist for servers but not for consumer NVMe drives. In QEMU you can define an NVMe device with multiple namespaces. Cf. https://qemu.readthedocs.io/en/latest/system/devices/nvme.html?highlight=namespace#additional-namespaces So for a first glimpse at the handling I suggest to use QEMU. Well that's fine, but every uclass must have a test and a sandbox emulator as well. Wait, it seems that you're discussing a different thing from my patch. While I don't know whether NVMe namespaces are a kind of "HW partitions", we don't care much here as long as any namespace can be handled simply as a normal block device, like scsi LUN's, in terms of U-Boot driver model. # On the other hand, we have to explicitly switch "hw partitions" # with blk_select_hwpart_devnum() on MMC devices even though we use # the *same* udevice(blk_desc). # See do_mmcrpmb() in cmd/mmc.c Each hardware partition should be a block device (class blk) which is mirrored in the UEFI world by a CTRL() device. It is not necessary for parent device to be a block device. Best regards Heinrich So I hope that *your* discussion doesn't make any difference to my patch. Right? -Takahiro Akashi Regards, Simon
Pull request: u-boot-sunxi/master for v2022.01
Hi Tom, please pull the sunxi/master branch, containing the first part of the 2022.01 changes. The bulk of it is Samuel's DM_I2C rework, which removes the nasty I2C deprecation warnings for most 32-bit boards. It also includes some smaller refactorings that pave the way for more changes, mostly driven by needing to support the Allwinner RISC-V SoC later on. Board wise we gain support for the FriendlyARM NanoPi R1S H5 router board and official Pinetab support. Build-tested for all 160 sunxi boards, and boot tested on a A64, A20, H3, H6, and H616 board. USB, SD card, eMMC, and Ethernet all work there (where applicable). Thanks, Andre == The following changes since commit f331497d3ad4166f9826e7674793ae04094b29c1: Merge tag 'video-20211009' of https://source.denx.de/u-boot/custodians/u-boot-video (2021-10-09 17:47:27 -0400) are available in the Git repository at: git://git.denx.de/u-boot-sunxi.git master for you to fetch changes up to f9437b00c06382d3edc623c10c69901786ad6317: sunxi: Enable DM_I2C for all sunxi boards (2021-10-12 11:01:27 +0100) Arnaud Ferraris (3): configs: add PineTab defconfig board: sunxi: enable status LED early pinephone_defconfig: add support for early-boot status LED Chukun Pan (1): sunxi: Add support for FriendlyARM NanoPi R1S H5 Samuel Holland (20): clk: sunxi: Move header out of arch directory sunxi: Simplify MMC pinmux selection gpio: sunxi: Remove the sunxi_name_to_gpio_bank function sunxi: Clean up inclusions of asm/arch/gpio.h sunxi: gpio: Remove name_to_gpio macro sunxi: gpio: Remove bank-specific size macros clk: sunxi: Add support for I2C gates/resets clk: sunxi: Add drivers for A31 and H6 PRCM CCUs power: pmic: Consistently depend on DM_PMIC power: pmic: Consistently depend on SPL_DM_PMIC power: pmic: Add a driver for X-Powers AXP PMICs sunxi: Only initialize legacy I2C when enabled sunxi: Select SUN8I_RSB more carefully sunxi: pmic_bus: Fix Kconfig dependencies i2c: Add a DM_I2C driver for the sun6i P2WI controller i2c: Add a DM_I2C driver for the sun8i RSB controller sunxi: pmic_bus: Clean up preprocessor conditions sunxi: pmic_bus: Use the DM PMIC interface when possible sunxi: video: Convert panel I2C to use DM_I2C sunxi: Enable DM_I2C for all sunxi boards arch/arm/Kconfig | 1 + arch/arm/dts/Makefile | 1 + arch/arm/dts/sun50i-h5-nanopi-r1s-h5.dts | 195 ++ arch/arm/include/asm/arch-sunxi/gpio.h | 20 +- arch/arm/mach-sunxi/Kconfig| 79 ++ arch/arm/mach-sunxi/Makefile | 2 - arch/arm/mach-sunxi/board.c| 3 +- arch/arm/mach-sunxi/clock.c| 1 - arch/arm/mach-sunxi/clock_sun4i.c | 1 - arch/arm/mach-sunxi/p2wi.c | 117 - arch/arm/mach-sunxi/pmic_bus.c | 109 arch/arm/mach-sunxi/rsb.c | 175 - board/sunxi/MAINTAINERS| 10 + board/sunxi/board.c| 152 +++ board/sunxi/gmac.c | 1 - configs/A20-Olimex-SOM-EVB_defconfig | 1 - configs/Colombus_defconfig | 6 - configs/Cubieboard4_defconfig | 1 + configs/Merrii_A80_Optimus_defconfig | 1 + configs/Sinlinx_SinA31s_defconfig | 1 - configs/UTOO_P66_defconfig | 3 - configs/Yones_Toptech_BD1078_defconfig | 2 +- configs/nanopi_r1s_h5_defconfig| 14 + configs/parrot_r16_defconfig | 1 - configs/pinephone_defconfig| 6 + configs/pinetab_defconfig | 10 + drivers/clk/sunxi/Kconfig | 14 + drivers/clk/sunxi/Makefile | 2 + drivers/clk/sunxi/clk_a10.c| 7 +- drivers/clk/sunxi/clk_a10s.c | 5 +- drivers/clk/sunxi/clk_a23.c| 8 +- drivers/clk/sunxi/clk_a31.c| 10 +- drivers/clk/sunxi/clk_a31_r.c | 59 + drivers/clk/sunxi/clk_a64.c| 8 +- drivers/clk/sunxi/clk_a80.c| 12 +- drivers/clk/sunxi/clk_a83t.c | 8 +- drivers/clk/sunxi/clk_h3.c | 8 +- drivers/clk/sunxi/clk_h6.c | 12 +- drivers/clk/sunxi/clk_h616.c | 14 +- drivers/clk/sunxi/clk_h6_r.c | 61 + drivers/clk/sunxi/clk_r40.c
Re: [PATCH 08/10] env: Use strncpy() instead of ad-hoc code to copy variable value
On 12/10/2021 14.00, Marek Behún wrote: > On Tue, 12 Oct 2021 13:41:43 +0200 > Rasmus Villemoes wrote: > >> On 12/10/2021 13.04, Marek Behún wrote: >> I understand why you want to avoid an open-coded copying, but strncpy >> is almost certainly the wrong tool for the job. Apart from not >> revealing anything about the actual length of the source string, it >> also has the well-known defect of zeroing the tail of the buffer in >> the (usual) case where the source is shorter than the buffer. > > U-Boot's strncpy does not do that: > * Note that unlike userspace strncpy, this does not %NUL-pad the > buffer. > * However, the result is not %NUL-terminated if the source exceeds > * @count bytes. Yeah, I just saw that. That's extremely dangerous, and can cause silent wrong code generation. The compiler knows the semantics of various standard functions, including strncpy, and can optimize accordingly. For example, look at https://godbolt.org/z/855s7hsEE In g1, we see that gcc has recognized strncpy() and open-codes it by two immediate stores (6384738 == 0x616c62 == ascii "bla"), including the trailing zero padding. Then in g2, gcc further realizes that the conditional is always false, hence folds the whole thing to "return -1" (though it does not manage to elide the then-dead stores to buf). So, I wouldn't bet that in cases where the compiler _does_ end up emitting a call to strncpy() that it doesn't somehow also rely on the implementation actually honouring the semantics required by the C standard. For another example, see https://godbolt.org/z/W6W3od The only way it is ok for gcc to compile copy_and_do to the exact same machine code as copy_and_do2 is because it knows memcpy returns its dst argument, hence (in the x86-64 case) it can prepare the first argument to do_stuff via a "mov rdi, rax", instead of spilling and reloading p. Well, U-Boot seems to pessimize the build with -fno-builtin making much of the above moot. But: On pa-risc, until very recently, "prctl(PR_SET_NAME, "x"); ; prctl(PR_GET_NAME)" was a simple way to read 14 bytes of kernel stack from userspace because pa-risc's strncpy didn't do that zeroing. Of course U-Boot doesn't really have problems with that kind of info-leak, but given the amount of code U-Boot imports from other projects, not least linux, there's certainly a fair chance that some of that code relies on strncpy's semantics for correctness. Rasmus
[PATCH] arm: total_compute: increase DRAM to 8GB
The extra 6GB start at 0x808000. Signed-off-by: Usama Arif --- board/armltd/total_compute/total_compute.c | 3 +++ include/configs/total_compute.h| 3 +++ 2 files changed, 6 insertions(+) diff --git a/board/armltd/total_compute/total_compute.c b/board/armltd/total_compute/total_compute.c index b7eaab0851..b7772f79a3 100644 --- a/board/armltd/total_compute/total_compute.c +++ b/board/armltd/total_compute/total_compute.c @@ -59,6 +59,9 @@ int dram_init_banksize(void) gd->bd->bi_dram[0].start = PHYS_SDRAM_1; gd->bd->bi_dram[0].size = PHYS_SDRAM_1_SIZE; + gd->bd->bi_dram[1].start = PHYS_SDRAM_2; + gd->bd->bi_dram[1].size = PHYS_SDRAM_2_SIZE; + return 0; } diff --git a/include/configs/total_compute.h b/include/configs/total_compute.h index bbeedaf841..933a145f99 100644 --- a/include/configs/total_compute.h +++ b/include/configs/total_compute.h @@ -30,6 +30,9 @@ #define PHYS_SDRAM_1_SIZE 0x8000 - DRAM_SEC_SIZE #define CONFIG_SYS_SDRAM_BASE PHYS_SDRAM_1 +#define PHYS_SDRAM_2 0x808000 +#define PHYS_SDRAM_2_SIZE 0x18000 + #define CONFIG_SYS_MMC_MAX_BLK_COUNT 127 #define CONFIG_EXTRA_ENV_SETTINGS \ -- 2.17.1
Re: [PATCH 08/10] env: Use strncpy() instead of ad-hoc code to copy variable value
On Tue, 12 Oct 2021 13:41:43 +0200
Rasmus Villemoes wrote:
> On 12/10/2021 13.04, Marek Behún wrote:
> > From: Marek Behún
> >
> > Copy the value of the found variable into given buffer with
> > strncpy().
> >
> > Signed-off-by: Marek Behún
> > ---
> > cmd/nvedit.c | 15 +--
> > 1 file changed, 5 insertions(+), 10 deletions(-)
> >
> > diff --git a/cmd/nvedit.c b/cmd/nvedit.c
> > index 412918a000..51b9e4ffa4 100644
> > --- a/cmd/nvedit.c
> > +++ b/cmd/nvedit.c
> > @@ -746,18 +746,13 @@ int env_get_f(const char *name, char *buf,
> > unsigned len) continue;
> >
> > /* found; copy out */
> > - for (n = 0; n < len; ++n, ++buf) {
> > - *buf = env[val++];
> > - if (*buf == '\0')
> > - return n;
> > + n = strncpy(buf, &env[val], len) - buf;
>
> strncpy by definition returns the dst argument, so this is, apart from
> the side effects done by strncpy, a complicated way of saying "n =
> 0;".
You are right, this is a mistake.
> > + if (len && n == len) {
>
> which then makes this automatically false always.
>
> I understand why you want to avoid an open-coded copying, but strncpy
> is almost certainly the wrong tool for the job. Apart from not
> revealing anything about the actual length of the source string, it
> also has the well-known defect of zeroing the tail of the buffer in
> the (usual) case where the source is shorter than the buffer.
U-Boot's strncpy does not do that:
* Note that unlike userspace strncpy, this does not %NUL-pad the
buffer.
* However, the result is not %NUL-terminated if the source exceeds
* @count bytes.
But you are right that I should use strlcpy here.
Thanks.
> n = strlcpy(buf, &env[val], len);
> if (n >= len) ...
>
> is probably closer to what you want. But only if you can trust
> &env[val] to actually have a nul byte before going into lala land.
>
> Rasmus
Double free vulnerability in sqfs commands ("sqfsls" and "sqfsload")
Hello U-Boot lists! I had been doing a fuzz testing in U-Boot . There is a double free bug in U-Boot, in /fs/squashfs/sqfs.c in the function sqfs_tokenize( ). On the line 307, tokens[i] is being freed and the ret is being set -ENOMEM, it will go to the out: label and free tokens[i] again (just like CVE-2020-8432, double free in do_rename_gpt_parts() ). Here is a sample command cause to crash in sandbox environment: host bind 0 test.sqsh sqfsls host 0 1//3
how to run u-boot on qemu arm64 virt machine?
Hello, u-boot mail list members, I'm trying to run u-boot on qemu arm64 virt machine to analyze how the S/W runs. I followed "doc/board/emulation/qemu-arm.rst", and here is what I did. For qemu build (using qemu-2.9.0), I did under ~/QEMU/qemu directory, mkdir build; cd build; ../configure --target-list=aarch64-softmmu --enable-debug --enable-gtk --disable-werror; make -j24 to build u-boot, I did under ~/U-BOOT/u-boot, make ARCH=arm CROSS_COMPILE=aarch64-none-elf- qemu_arm64_defconfig To run u-boot on qemu, I did under ~/U-BOOT/u-boot ~/QEMU/qemu/build/aarch64-softmmu/qemu-system-aarch64 -M virt -cpu cortex-a57 -bios u-boot.bin But I see only qemu manager window and I don't know how to proceed. Am I not supposed to see u-boot program running? What am I doing wrong? Any help will be really appreciated. Thank you. Chan Kim
Re: [PATCH 08/10] env: Use strncpy() instead of ad-hoc code to copy variable value
On 12/10/2021 13.04, Marek Behún wrote:
> From: Marek Behún
>
> Copy the value of the found variable into given buffer with strncpy().
>
> Signed-off-by: Marek Behún
> ---
> cmd/nvedit.c | 15 +--
> 1 file changed, 5 insertions(+), 10 deletions(-)
>
> diff --git a/cmd/nvedit.c b/cmd/nvedit.c
> index 412918a000..51b9e4ffa4 100644
> --- a/cmd/nvedit.c
> +++ b/cmd/nvedit.c
> @@ -746,18 +746,13 @@ int env_get_f(const char *name, char *buf, unsigned len)
> continue;
>
> /* found; copy out */
> - for (n = 0; n < len; ++n, ++buf) {
> - *buf = env[val++];
> - if (*buf == '\0')
> - return n;
> + n = strncpy(buf, &env[val], len) - buf;
strncpy by definition returns the dst argument, so this is, apart from
the side effects done by strncpy, a complicated way of saying "n = 0;".
> + if (len && n == len) {
which then makes this automatically false always.
I understand why you want to avoid an open-coded copying, but strncpy is
almost certainly the wrong tool for the job. Apart from not revealing
anything about the actual length of the source string, it also has the
well-known defect of zeroing the tail of the buffer in the (usual) case
where the source is shorter than the buffer.
n = strlcpy(buf, &env[val], len);
if (n >= len) ...
is probably closer to what you want. But only if you can trust &env[val]
to actually have a nul byte before going into lala land.
Rasmus
Re: [PATCH v2 00/12] sunxi: Migrate to DM_I2C
On Fri, 8 Oct 2021 00:17:13 -0500
Samuel Holland wrote:
Hi Samuel,
> This series does the initial work to migrate sunxi boards to DM_I2C.
> Version 1 of this series bitrotted quite a bit, so there is some
> reorganization in version 2.
>
> First it takes care of the PMIC:
> - Patches 1-2 clean up the PMIC Kconfig, though they are not strictly
>necessary after 7abf178b, and are independent from the other patches.
> - Patch 3 then adds a DM_PMIC driver.
> - Patches 4-6 prepare to move the P2WI/RSB bus drivers to drivers/i2c.
> - Patches 7-8 move and add DM_I2C versions of those two drivers.
> - Patches 9-10 migrate the "pmic_bus" functions to use the DM_I2C bus
>and DM_PMIC driver when possible.
> Then it takes care of the LCD panels:
> - Patch 11 converts those drivers to use DM_I2C.
> Finally, patch 12 switches all sunxi boards over to DM_I2C.
>
> I have build-tested each commit on all sunxi boards.
I am fine with this, and this removes the deprecation warnings for many
older boards, so I applied it to sunxi/master and will send a PR for this.
This looks like it has the potential to break boards, but I guess we will
never find out without applying it and waiting for bug reports.
Thanks!
Andre
>
> There is some remaining work to clean up uses of pmic_bus in U-Boot
> proper and replace them with DM_PMIC functions:
> - drivers/gpio/axp_gpio.c - I have a series for this.
> - do_poweroff() in drivers/gpio/axp???.c - I have a series for this.
> - axp_get_sid() in drivers/power/axp221.c - Not sure what to do here.
> - axp_set_eldo() in drivers/video/sunxi/sunxi_display.c - This will
>need a DM_REGULATOR driver.
>
> Changes in v2:
> - Rebase to pick up 7abf178b ("power: Tidy up #undef of CONFIG_DM_PMIC")
> - Rebase to pick up 7abf178b ("power: Tidy up #undef of CONFIG_DM_PMIC")
> - Replace axp_pmic_bind() with `.bind = dm_scan_fdt_dev`
> - New patch to account for I2C Kconfig changes
> - Renamed Kconfig symbol to SYS_I2C_SUN6I_P2WI
> - Moved entire P2WI driver source to drivers/i2c
> - Renamed Kconfig symbol to SYS_I2C_SUN8I_RSB
> - Moved entire RSB driver source to drivers/i2c
> - Update IS_ENABLEDs in pmic_bus.c to match chages to previous patches
>
> Samuel Holland (12):
> power: pmic: Consistently depend on DM_PMIC
> power: pmic: Consistently depend on SPL_DM_PMIC
> power: pmic: Add a driver for X-Powers AXP PMICs
> sunxi: Only initialize legacy I2C when enabled
> sunxi: Select SUN8I_RSB more carefully
> sunxi: pmic_bus: Fix Kconfig dependencies
> i2c: Add a DM_I2C driver for the sun6i P2WI controller
> i2c: Add a DM_I2C driver for the sun8i RSB controller
> sunxi: pmic_bus: Clean up preprocessor conditions
> sunxi: pmic_bus: Use the DM PMIC interface when possible
> sunxi: video: Convert panel I2C to use DM_I2C
> sunxi: Enable DM_I2C for all sunxi boards
>
> arch/arm/Kconfig| 1 +
> arch/arm/mach-sunxi/Kconfig | 59 ++
> arch/arm/mach-sunxi/Makefile| 2 -
> arch/arm/mach-sunxi/board.c | 2 +-
> arch/arm/mach-sunxi/p2wi.c | 117
> arch/arm/mach-sunxi/pmic_bus.c | 109 +--
> arch/arm/mach-sunxi/rsb.c | 175 -
> board/sunxi/board.c | 44 +
> configs/Colombus_defconfig | 6 -
> configs/UTOO_P66_defconfig | 3 -
> drivers/i2c/Kconfig | 16 ++
> drivers/i2c/Makefile| 2 +
> drivers/i2c/sun6i_p2wi.c| 220 ++
> drivers/i2c/sun8i_rsb.c | 281
> drivers/power/pmic/Kconfig | 69 ---
> drivers/power/pmic/Makefile | 1 +
> drivers/power/pmic/axp.c| 38
> drivers/video/anx9804.c | 103 +-
> drivers/video/anx9804.h | 5 +-
> drivers/video/sunxi/sunxi_display.c | 55 --
> include/axp_pmic.h | 12 ++
> include/configs/sunxi-common.h | 17 --
> 22 files changed, 773 insertions(+), 564 deletions(-)
> delete mode 100644 arch/arm/mach-sunxi/p2wi.c
> delete mode 100644 arch/arm/mach-sunxi/rsb.c
> create mode 100644 drivers/i2c/sun6i_p2wi.c
> create mode 100644 drivers/i2c/sun8i_rsb.c
> create mode 100644 drivers/power/pmic/axp.c
>
[PATCH] arm: a37xx: pci: Do not allow setting bars on PCI Bridge
PCI Bridge which represents Aardvark PCIe Root Port does not have
configurable bars.
So ensure that write operation to bars registers on PCI Bridge is noop and
bars registers always contain zero address which indicates that bars are
unsupported.
After this change U-Boot 'pci bar 0.0.0' command does not show any
allocated bars for PCI Bridge device.
Signed-off-by: Pali Rohár
Fixes: cb056005dc67 ("arm: a37xx: pci: Add support for accessing PCI Bridge on
root bus")
---
drivers/pci/pci-aardvark.c | 4
1 file changed, 4 insertions(+)
diff --git a/drivers/pci/pci-aardvark.c b/drivers/pci/pci-aardvark.c
index 38eff495ab1c..ade5ab056f84 100644
--- a/drivers/pci/pci-aardvark.c
+++ b/drivers/pci/pci-aardvark.c
@@ -581,6 +581,10 @@ static int pcie_advk_write_config(struct udevice *bus,
pci_dev_t bdf,
if (offset >= 0x10 && offset < 0x34) {
data = pcie->cfgcache[(offset - 0x10) / 4];
data = pci_conv_size_to_32(data, value, offset, size);
+ /* This PCI bridge does not have configurable bars */
+ if ((offset & ~3) == PCI_BASE_ADDRESS_0 ||
+ (offset & ~3) == PCI_BASE_ADDRESS_1)
+ data = 0x0;
pcie->cfgcache[(offset - 0x10) / 4] = data;
} else if ((offset & ~3) == PCI_ROM_ADDRESS1) {
data = advk_readl(pcie, PCIE_CORE_EXP_ROM_BAR_REG);
--
2.20.1
