Re: [PATCH v1 2/2] configs: starfive_visionfive2_defconfig: Update CONFIG_SPL_STACK
On 5/17/23 11:41 PM, Yanhong Wang wrote: SPL runs on the L2 LIM, which is 2M in size mapped at 0x800.This region consists of 16 0x2 sized regions, each one can be used as either L2 cache way or SRAM (not both).From top to bottom, you have way 0-15.The way 0 is always enabled, so SPL can only use at most 0x1e bytes of memory.So, update the value of the CONFIG_SPL_STACK to 0x81C. Signed-off-by: Yanhong Wang --- configs/starfive_visionfive2_defconfig | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/configs/starfive_visionfive2_defconfig b/configs/starfive_visionfive2_defconfig index ffbc4b9476..fc3d27bbec 100644 --- a/configs/starfive_visionfive2_defconfig +++ b/configs/starfive_visionfive2_defconfig @@ -13,7 +13,7 @@ CONFIG_SYS_PROMPT="StarFive #" CONFIG_OF_LIBFDT_OVERLAY=y CONFIG_DM_RESET=y CONFIG_SPL_MMC=y -CONFIG_SPL_STACK=0x818 +CONFIG_SPL_STACK=0x81C CONFIG_SPL=y CONFIG_SPL_SPI_FLASH_SUPPORT=y CONFIG_SPL_SPI=y Hi Yanhong, Thanks for taking care of this. Would you mind refer my name if you want to directly copy-paste my previous response? (https://lists.denx.de/pipermail/u-boot/2023-May/518359.html) Regarding the patch itself, I don't quite understand it. If you want to fully utilize the L2 LIM, then we should have CONFIG_SPL_STACK=0x81e. Let me know if I missed anything. Thanks.
Re: [PATCH v1 1/2] arch: riscv: jh7110: Split the zeroing of L2 LIM on JH7110
On 5/17/23 11:41 PM, Yanhong Wang wrote:
The per-hart stack,malloc space and global variable 'gd' sits between
__bss_end and L2_LIM_MEM_END.Zeroing this region could overwrite the
hart's stack, and other harts' stacks.If it were to save and restore
`ra` register, then we would crash in function epilogue. Also, we are
having data-races here, because harts are writing over each other's
stack.
So we should split the zeroing of L2 LIM into different places just
before the region is to be used. For stacks,let each hart clearing its
own stack, and for the malloc space, we can do so during malloc
initialization. The global variable 'gd' is initialized in the
board_init_f_init_reserve function.
Signed-off-by: Yanhong Wang
---
Hi Yanhong, Thanks for taking care of this. Would you mind refer my
name if you want to directly copy-paste my previous response?
arch/riscv/cpu/jh7110/spl.c | 6 +++---
arch/riscv/cpu/start.S | 14 ++
common/init/board_init.c| 1 +
3 files changed, 18 insertions(+), 3 deletions(-)
diff --git a/arch/riscv/cpu/jh7110/spl.c b/arch/riscv/cpu/jh7110/spl.c
index 104f0fe949..6a48fba63d 100644
--- a/arch/riscv/cpu/jh7110/spl.c
+++ b/arch/riscv/cpu/jh7110/spl.c
@@ -10,7 +10,6 @@
#include
#define CSR_U74_FEATURE_DISABLE 0x7c1
-#define L2_LIM_MEM_END 0x81FUL
int spl_soc_init(void)
{
@@ -42,13 +41,14 @@ void harts_early_init(void)
csr_write(CSR_U74_FEATURE_DISABLE, 0);
/* clear L2 LIM memory
-* set __bss_end to 0x81F region to zero
+* set __bss_end to stack end region to zero
* The L2 Cache Controller supports ECC. ECC is applied to SRAM.
* If it is not cleared, the ECC part is invalid, and an ECC error
* will be reported when reading data.
*/
ptr = (ulong *)&__bss_end;
- len = L2_LIM_MEM_END - (ulong)&__bss_end;
+ len = CONFIG_SPL_STACK - CONFIG_VAL(SYS_MALLOC_F_LEN) - sizeof(*gd) -
+ CONFIG_NR_CPUS * BIT(CONFIG_STACK_SIZE_SHIFT) -
(ulong)&__bss_end;
I don't understand what we are zeroing here. It seems that we are zeroing
the hole between __bss_end and gd? Any reason in doing so?
remain = len % sizeof(ulong);
len /= sizeof(ulong);
diff --git a/arch/riscv/cpu/start.S b/arch/riscv/cpu/start.S
index dad22bfea8..46da9ec503 100644
--- a/arch/riscv/cpu/start.S
+++ b/arch/riscv/cpu/start.S
@@ -118,6 +118,20 @@ call_board_init_f_0:
mv sp, a0
#endif
+#if defined(CONFIG_SPL_BUILD) && defined(CONFIG_SPL_STACK) && \
+ defined(CONFIG_STARFIVE_JH7110)
+
+ /* Set the stack region to zero */
+ li t0, 1
+ slli t1, t0, CONFIG_STACK_SIZE_SHIFT
+ mv t0, sp
+ sub t1, t0, t1
+clear_stack:
+ SREGzero, 0(t1)
+ addit1, t1, REGBYTES
+ blt t1, t0, clear_stack
+#endif
+
I think we should introduce another Kconfig option to indicate that stack should
be zeroed before use, so we don't need board specific check, such as
defined(CONFIG_STARFIVE_JH7110)
/* Configure proprietary settings and customized CSRs of harts */
call_harts_early_init:
jal harts_early_init
diff --git a/common/init/board_init.c b/common/init/board_init.c
index 96ffb79a98..46e4e4abc7 100644
--- a/common/init/board_init.c
+++ b/common/init/board_init.c
@@ -162,6 +162,7 @@ void board_init_f_init_reserve(ulong base)
#if CONFIG_VAL(SYS_MALLOC_F_LEN)
/* go down one 'early malloc arena' */
gd->malloc_base = base;
+ memset((void *)base, 0, CONFIG_VAL(SYS_MALLOC_F_LEN));
#endif
if (CONFIG_IS_ENABLED(SYS_REPORT_STACK_F_USAGE))
Same as above.
Re: [PATCH] riscv: setup per-hart stack earlier
On 5/14/23 10:08 PM, Rick Chen wrote: Hi Bo Gan, It builds fail as below: arch/riscv/cpu/start.S:97: Error: illegal operands `li t0,CONFIG_SYS_INIT_SP_ADDR' Thanks, Rick Hi Rick & Leo, Please help take a look at v2 of the patch: https://patchwork.ozlabs.org/project/uboot/patch/1684650044-313122-1-git-send-email-ganbo...@gmail.com/ I've fixed the macro and also did some testing on my vf2 board. Thanks!
[PATCH v2] riscv: setup per-hart stack earlier
Harts need to use per-hart stack before any function call, even if that function is a simple one. When the callee uses stack for register save/ restore, especially RA, if nested call, concurrent access by multiple harts on the same stack will cause data-race. This patch sets up SP before `board_init_f_alloc_reserve`. A side effect of this is that the memory layout has changed as the following: ++++ <- SPL_STACK/ | ..|| hart 0 stack |SYS_INIT_SP_ADDR | malloc_base |++ ++| hart 1 stack | | GD|++ If not SMP, N=1 ++| ..| | hart 0 stack |++ ++ ==> | hart N-1 stack| | hart 1 stack |++ ++| ..| | ..|| malloc_base | ++++ | hart N-1 stack|| GD| ++++ |||| Signed-off-by: Bo Gan Cc: Rick Chen Cc: Leo Cc: Sean Anderson Cc: Bin Meng Cc: Lukas Auer --- v2: - Fixed macro CONFIG_SYS_INIT_SP_ADDR -> SYS_INIT_SP_ADDR - Tested SPL with VisionFive 2 board --- arch/riscv/cpu/start.S | 37 - 1 file changed, 24 insertions(+), 13 deletions(-) diff --git a/arch/riscv/cpu/start.S b/arch/riscv/cpu/start.S index dad22bf..59d58a5 100644 --- a/arch/riscv/cpu/start.S +++ b/arch/riscv/cpu/start.S @@ -91,16 +91,35 @@ _start: * Set stackpointer in internal/ex RAM to call board_init_f */ call_board_init_f: - li t0, -16 #if defined(CONFIG_SPL_BUILD) && defined(CONFIG_SPL_STACK) - li t1, CONFIG_SPL_STACK + li t0, CONFIG_SPL_STACK #else - li t1, SYS_INIT_SP_ADDR + li t0, SYS_INIT_SP_ADDR #endif - and sp, t1, t0 /* force 16 byte alignment */ + and t0, t0, -16 /* force 16 byte alignment */ + + /* setup stack */ +#if CONFIG_IS_ENABLED(SMP) + /* tp: hart id */ + sllit1, tp, CONFIG_STACK_SIZE_SHIFT + sub sp, t0, t1 +#else + mv sp, t0 +#endif +/* + * Now sp points to the right stack belonging to current CPU. + * It's essential before any function call, otherwise, we get data-race. + */ call_board_init_f_0: - mv a0, sp + /* find top of reserve space */ +#if CONFIG_IS_ENABLED(SMP) + li t1, CONFIG_NR_CPUS +#else + li t1, 1 +#endif + sllit1, t1, CONFIG_STACK_SIZE_SHIFT + sub a0, t0, t1 /* t1 -> size of all CPU stacks */ jal board_init_f_alloc_reserve /* @@ -109,14 +128,6 @@ call_board_init_f_0: */ mv s0, a0 - /* setup stack */ -#if CONFIG_IS_ENABLED(SMP) - /* tp: hart id */ - sllit0, tp, CONFIG_STACK_SIZE_SHIFT - sub sp, a0, t0 -#else - mv sp, a0 -#endif /* Configure proprietary settings and customized CSRs of harts */ call_harts_early_init: -- 2.7.4
Re: [RFC PATCH 00/10] Improve ARM target's support for LLVM toolchain
Am 20. Mai 2023 22:55:37 MESZ schrieb Sam Edwards : > >Here is a series of patches aimed at improving support for the LLVM >toolchain (clang, lld, and to a lesser extent, llvm-objcopy) when >targeting ARM. This toolchain is a cross-compiler "by default" -- a user >generally should not need to install anything more to target their board >of choice if they already have Clang installed. Additionally, Clang has >a few nice diagnostics that should help appreciably with code quality, >if Clang starts to be used regularly by a few more U-Boot developers. ;) > >Most of these patches are trivial and as such they should be pretty easy >to review, but the later patches in the patchset start making some >pretty big changes to the linker scripts. There are no behavioral >changes with those (U-Boot should still function the same) but there is >always the risk of compatibility with some third-party tool or loader >being broken. Fortunately, I foresee any problems making themselves >immediately apparent upon testing. > >I have tested booting on sunxi/T113, and building for Raspberry Pi >(32-bit and 64-bit). The remaining testing efforts should be focused on: >- Exynos >- EFI loader (esp. on Lenovo X13s, which Heinrich Schuchardt had >mentioned in a previous commit as being fickle) >- Zynq >- Rockchip TPL >- AArch64 SPL > >I'm submitting this as an RFC since this doesn't completely guarantee >LLVM toolchain compatibility yet; my focus here is mostly on ensuring >that I haven't caused any regressions in GNU-land. Also, I haven't >discussed most of these changes before doing them. Perhaps alternate >approaches to some of these things can be proposed - I'm all ears. > >Outstanding problems are: >- LLD sometimes puts .hash outside of the image binary area, though this > is flagged by binary_size_check >- The main makefile uses --gap-fill=0xff, which is not supported in > llvm-objcopy >- llvm-objcopy also doesn't appear to speak S-Record; the u-boot.srec > target has to be deleted manually >- llvm-objcopy gets upset at some of the EFI code, since the EFI linker > scripts preserve dynamic sections that llvm-objcopy doesn't want to > strip off > >Cheers, >Sam Hello Sam, thanks for looking into llvm compatibility. I guess the documentation and the CI testing would also have to be adjusted. What about non-ARM architectures? Could you, please, describe how built with lld so that reviewers can test it. I find reviewing hard when receiving only 3 out of 10 patches. Best regards Heinrich > > >Sam Edwards (10): > makefile: Fix symbol typo in binary_size_check > arm: set alignment properly for asm funcs > arm: exclude eabi_compat from LTO > arm: add __aeabi_memclr in eabi_compat > arm: add aligned-memory aliases to eabi_compat > arm: discard .gnu.version* sections > arm: efi_loader: discard hash, unwind information > arm: efi_loader: move .dynamic out of .text in EFI > arm: discard all .dyn* sections > arm: migrate away from sections.c > > Makefile | 2 +- > arch/arm/cpu/armv8/spl_data.c| 4 +- > arch/arm/cpu/armv8/u-boot-spl.lds| 26 ++ > arch/arm/cpu/armv8/u-boot.lds| 48 +++ > arch/arm/cpu/u-boot.lds | 103 +++ > arch/arm/include/asm/linkage.h | 4 +- > arch/arm/lib/Makefile| 3 +- > arch/arm/lib/eabi_compat.c | 17 > arch/arm/lib/elf_aarch64_efi.lds | 3 +- > arch/arm/lib/elf_arm_efi.lds | 3 + > arch/arm/lib/sections.c | 36 > arch/arm/mach-rockchip/u-boot-tpl-v8.lds | 26 ++ > arch/arm/mach-zynq/u-boot.lds| 73 +++- > 13 files changed, 96 insertions(+), 252 deletions(-) > delete mode 100644 arch/arm/lib/sections.c >
Re: U-Boot OMAP GPMC ECC change
On Fri, May 19, 2023 at 03:41:34PM +0300, Roger Quadros wrote: > Hi Colin, > > On 19/05/2023 02:19, Colin Foster wrote: > > Hi Roger, > > > >> Can you please share your spl/u-boot.cfg? > > > > Attached > > Couple of questions there > > 1) CONFIG_MTDPARTS_DEFAULT > "mtdparts=nandflash:0x2(xload_raw),0x18(u-boot),0x18(u-boot-2),0x1fce(main)" > Is this correct and matches with what kernel sees? > I couldn't see the NAND partition table in the Kernel Device tree patch. Yes, this is correct. I intentionally left my MTD Partitions out of the kernel patch, since I don't want any changes I might make to the flash partitions to require further patches. I'm currently at this structure (SPL, 2x U-Boot, and main UBI with A/B partitions and 2x U-Boot Envs) The SD Boot version of U-Boot doesn't use NAND, so it might have a stale partition layout that I'll need to remove / modify. > > 2) > #define CONFIG_SYS_NAND_U_BOOT_OFFS 0x2 > #define CONFIG_SYS_NAND_U_BOOT_OFFS_REDUND 0x1a > > These don't seem to match what you have defined in MTDPARTS_DEFAULT. > Which one is correct? This matches the above partition layout. 0x18 + 0x2 = 0x1a. It wasn't until recently I realized I needed to remove CONFIG_SPL_RAW_IMAGE_SUPPORT in order for this fallback to succeed. > > How do you flash the MLO and u-boot image to NAND? I boot to from SD card, then run a commissioning script that contains: ``` echo "Erasing MLO partition $MLO_PART" flash_erase $MLO_PART 0 0 echo "Programming MLO partition" nandwrite -a -p $MLO_PART $MLO_FILE echo "Erasing U-Boot partition $U_BOOT_PART" flash_erase $U_BOOT_PART 0 0 echo "Programming U-Boot partition" nandwrite -a -p $U_BOOT_PART $U_BOOT_FILE echo "Erasing U-Boot redundant partition $U_BOOT_PART_REDUND" flash_erase $U_BOOT_PART_REDUND 0 0 echo "Programming U-Boot redund partition" nandwrite -a -p $U_BOOT_PART_REDUND $U_BOOT_FILE echo "Clearing UBI partition" flash_erase $UBI_PART 0 0 echo "Formatting UBI partition" ubiformat $UBI_PART -y ubiattach -p $UBI_PART echo "Making UBI volumes" ubimkvol /dev/ubi0 -N env1 -s 0x4 ubimkvol /dev/ubi0 -N env2 -s 0x4 ubimkvol /dev/ubi0 -N rootfs-a -s 0xc00 ubimkvol /dev/ubi0 -N rootfs-b -s 0xc00 echo "Writing rootfs partitions" ubiupdatevol /dev/ubi0_2 $ROOTFS_FILE ubiupdatevol /dev/ubi0_3 $ROOTFS_FILE ``` For all these tests I've been manually running the flash_erase / nandwrite process for the SPL / U-Boot partitions. > > I tried on AM335x-EVM and it works fine both before and after commit > 04fcd25873. > > Once change I had to do was to increase the u-boot partition size > as u-boot image does not fit in original partition size. > > -boot log follows- > > U-Boot SPL 2023.01-rc4-00381-g04fcd25873-dirty (May 19 2023 - 15:10:15 +0300) > Trying to boot from NAND > > > U-Boot 2023.01-rc4-00381-g04fcd25873-dirty (May 19 2023 - 15:10:15 +0300) > > CPU : AM335X-GP rev 1.0 > Model: TI AM335x EVM > DRAM: 512 MiB > Core: 156 devices, 17 uclasses, devicetree: separate > WDT: Started wdt@44e35000 with servicing every 1000ms (60s timeout) > NAND: 256 MiB > MMC: OMAP SD/MMC: 0 > Loading Environment from FAT... Unable to read "uboot.env" from mmc0:1... > not set. Validating first E-fuse MAC > Net: eth2: ethernet@4a10, eth3: usb_ether > Hit any key to stop autoboot: 0 > => > > => mtd > > device nand0 , # parts = 10 > #: namesizeoffset mask_flags > 0: NAND.SPL0x0002 0x 0 > 1: NAND.SPL.backup10x0002 0x0002 0 > 2: NAND.SPL.backup20x0002 0x0004 0 > 3: NAND.SPL.backup30x0002 0x0006 0 I need to go back to the 4460 datasheet. I looked and don't remember seeing anything about an SPL search. I'd sleep better at night knowing that when the day comes I need to update the SPL, I can do so with some redundancy. Sorry - I'm getting off topic. I'll be back with hardware on Monday to keep looking at this. > 4: NAND.u-boot-spl-os 0x0004 0x0008 0 > 5: NAND.u-boot 0x0020 0x000c 0 > 6: NAND.u-boot-env 0x0002 0x002c 0 > 7: NAND.u-boot-env.backup10x0002 0x002e 0 > 8: NAND.kernel 0x0070 0x0030 0 > 9: NAND.file-system0x0f60 0x00a0 0 > > > -- > cheers, > -roger
USB mass storage gadget on SAMA5D2
Hi,
I'm trying to use ums to access EMMC on our SAMA5D2 board without success.
My board_init(), without adding usba_udc_probe() ums will cause data abort
error:
int board_init(void)
{
/* address of boot parameters */
gd->bd->bi_boot_params = CONFIG_SYS_SDRAM_BASE + 0x100;
#ifdef CONFIG_USB_GADGET_ATMEL_USBA
at91_udp_hw_init();
usba_udc_probe(&pdata);
#endif
return 0;
}
USB related config:
CONFIG_USB=y
CONFIG_USB_EHCI_HCD=y
CONFIG_USB_STORAGE=y
CONFIG_USB_GADGET=y
CONFIG_USB_GADGET_VENDOR_NUM=0xdead
CONFIG_USB_GADGET_PRODUCT_NUM=0xbeef
CONFIG_USB_GADGET_ATMEL_USBA=y
CONFIG_USB_GADGET_VBUS_DRAW=500
CONFIG_USB_GADGET_DOWNLOAD=y
CONFIG_USB_ETHER=y
EMMC can be successfully accessed, Linux boot is ok:
=> mmc list
sdio-host@a000: 0 (eMMC)
=> mmc info
Device: sdio-host@a000
Manufacturer ID: 70
OEM: 100
Name: M6270
Bus Speed: 5200
Mode: MMC High Speed (52MHz)
Rd Block Len: 512
MMC version 5.1
High Capacity: Yes
Capacity: 3.6 GiB
Bus Width: 4-bit
Erase Group Size: 512 KiB
HC WP Group Size: 4 MiB
User Capacity: 3.6 GiB
Boot Capacity: 2 MiB ENH
RPMB Capacity: 512 KiB ENH
Boot area 0 is not write protected
Boot area 1 is not write protected
=> mmc part
Partition Map for MMC device 0 -- Partition Type: DOS
PartStart SectorNum Sectors UUIDType
1 20481044480 0508e2bf-01 83
However, when I use "ums 0 mmc 0", the USB device is partially enumerated
without a block device available, in the console the rotation cursor spins
about 20s then USB is disconnected.
On u-boot:
=> ums 0 mmc 0
UMS: LUN 0, dev mmc 0, hwpart 0, sector 0x0, count 0x72
-=> (self-exit after 20s)
On Linux:
[ 699.920316] usb 3-5: new high-speed USB device number 5 using xhci_hcd
[ 700.060766] usb 3-5: New USB device found, idVendor=dead,
idProduct=beef, bcdDevice= 2.17
[ 700.060772] usb 3-5: New USB device strings: Mfr=1, Product=2,
SerialNumber=0
[ 700.060774] usb 3-5: Product: USB download gadget
[ 700.060776] usb 3-5: Manufacturer: U-Boot
[ 700.081573] usb-storage 3-5:1.0: USB Mass Storage device detected
[ 700.081780] scsi host0: usb-storage 3-5:1.0
[ 700.081874] usbcore: registered new interface driver usb-storage
[ 700.088339] usbcore: registered new interface driver uas
[ 722.407008] usb 3-5: USB disconnect, device number 5
Thanks,
[PATCH v2 2/2] rockchip: rk3328: Add support for Orange Pi R1 Plus LTS
The OrangePi R1 Plus LTS is a minor variant of OrangePi R1 Plus with
the on-board NIC chip changed from rtl8211e to yt8531c, and RAM type
changed from DDR4 to LPDDR3.
The device tree is taken from kernel v6.4-rc1.
Signed-off-by: Tianling Shen
---
Changes in v2:
* Rebased upon the latest git HEAD
* Fixed memory profile (rk3328-sdram-lpddr3-1600.dtsi ->
rk3328-sdram-lpddr3-666.dtsi)
* Removed kernel link from commit message
---
arch/arm/dts/Makefile | 1 +
.../rk3328-orangepi-r1-plus-lts-u-boot.dtsi | 46 +++
arch/arm/dts/rk3328-orangepi-r1-plus-lts.dts | 40 ++
board/rockchip/evb_rk3328/MAINTAINERS | 6 +
configs/orangepi-r1-plus-lts-rk3328_defconfig | 114 ++
5 files changed, 207 insertions(+)
create mode 100644 arch/arm/dts/rk3328-orangepi-r1-plus-lts-u-boot.dtsi
create mode 100644 arch/arm/dts/rk3328-orangepi-r1-plus-lts.dts
create mode 100644 configs/orangepi-r1-plus-lts-rk3328_defconfig
diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
index 9d189788aa..425bf4e7a9 100644
--- a/arch/arm/dts/Makefile
+++ b/arch/arm/dts/Makefile
@@ -126,6 +126,7 @@ dtb-$(CONFIG_ROCKCHIP_RK3328) += \
rk3328-nanopi-r2c.dtb \
rk3328-nanopi-r2s.dtb \
rk3328-orangepi-r1-plus.dtb \
+ rk3328-orangepi-r1-plus-lts.dtb \
rk3328-roc-cc.dtb \
rk3328-rock64.dtb \
rk3328-rock-pi-e.dtb
diff --git a/arch/arm/dts/rk3328-orangepi-r1-plus-lts-u-boot.dtsi
b/arch/arm/dts/rk3328-orangepi-r1-plus-lts-u-boot.dtsi
new file mode 100644
index 00..ebe33e48cb
--- /dev/null
+++ b/arch/arm/dts/rk3328-orangepi-r1-plus-lts-u-boot.dtsi
@@ -0,0 +1,46 @@
+// SPDX-License-Identifier: GPL-2.0-or-later
+/*
+ * (C) Copyright 2018-2019 Rockchip Electronics Co., Ltd
+ * (C) Copyright 2020 David Bauer
+ */
+
+#include "rk3328-u-boot.dtsi"
+#include "rk3328-sdram-lpddr3-666.dtsi"
+/ {
+ chosen {
+ u-boot,spl-boot-order = "same-as-spl", &sdmmc, &emmc;
+ };
+};
+
+&gpio0 {
+ bootph-pre-ram;
+};
+
+&pinctrl {
+ bootph-pre-ram;
+};
+
+&sdmmc0m1_pin {
+ bootph-pre-ram;
+};
+
+&pcfg_pull_up_4ma {
+ bootph-pre-ram;
+};
+
+/* Need this and all the pinctrl/gpio stuff above to set pinmux */
+&vcc_sd {
+ bootph-pre-ram;
+};
+
+&gmac2io {
+ snps,reset-gpio = <&gpio1 RK_PC2 GPIO_ACTIVE_LOW>;
+ snps,reset-active-low;
+ snps,reset-delays-us = <0 1 5>;
+};
+
+&spi0 {
+ spi_flash: spiflash@0 {
+ bootph-all;
+ };
+};
diff --git a/arch/arm/dts/rk3328-orangepi-r1-plus-lts.dts
b/arch/arm/dts/rk3328-orangepi-r1-plus-lts.dts
new file mode 100644
index 00..5d7d567283
--- /dev/null
+++ b/arch/arm/dts/rk3328-orangepi-r1-plus-lts.dts
@@ -0,0 +1,40 @@
+// SPDX-License-Identifier: GPL-2.0-or-later OR MIT
+/*
+ * Copyright (c) 2016 Xunlong Software. Co., Ltd.
+ * (http://www.orangepi.org)
+ *
+ * Copyright (c) 2021-2023 Tianling Shen
+ */
+
+/dts-v1/;
+#include "rk3328-orangepi-r1-plus.dts"
+
+/ {
+ model = "Xunlong Orange Pi R1 Plus LTS";
+ compatible = "xunlong,orangepi-r1-plus-lts", "rockchip,rk3328";
+};
+
+&gmac2io {
+ phy-handle = <&yt8531c>;
+ tx_delay = <0x19>;
+ rx_delay = <0x05>;
+
+ mdio {
+ /delete-node/ ethernet-phy@1;
+
+ yt8531c: ethernet-phy@0 {
+ compatible = "ethernet-phy-ieee802.3-c22";
+ reg = <0>;
+
+ motorcomm,clk-out-frequency-hz = <12500>;
+ motorcomm,keep-pll-enabled;
+ motorcomm,auto-sleep-disabled;
+
+ pinctrl-0 = <ð_phy_reset_pin>;
+ pinctrl-names = "default";
+ reset-assert-us = <15000>;
+ reset-deassert-us = <5>;
+ reset-gpios = <&gpio1 RK_PC2 GPIO_ACTIVE_LOW>;
+ };
+ };
+};
diff --git a/board/rockchip/evb_rk3328/MAINTAINERS
b/board/rockchip/evb_rk3328/MAINTAINERS
index 91dc6b58cf..8a19eb373d 100644
--- a/board/rockchip/evb_rk3328/MAINTAINERS
+++ b/board/rockchip/evb_rk3328/MAINTAINERS
@@ -24,6 +24,12 @@ S: Maintained
F: configs/orangepi-r1-plus-rk3328_defconfig
F: arch/arm/dts/rk3328-orangepi-r1-plus-u-boot.dtsi
+ORANGEPI-R1-PLUS-LTS-RK3328
+M: Tianling Shen
+S: Maintained
+F: configs/orangepi-r1-plus-lts-rk3328_defconfig
+F: arch/arm/dts/rk3328-orangepi-r1-plus-lts-u-boot.dtsi
+
ROC-RK3328-CC
M: Loic Devulder
M: Chen-Yu Tsai
diff --git a/configs/orangepi-r1-plus-lts-rk3328_defconfig
b/configs/orangepi-r1-plus-lts-rk3328_defconfig
new file mode 100644
index 00..59a28e5209
--- /dev/null
+++ b/configs/orangepi-r1-plus-lts-rk3328_defconfig
@@ -0,0 +1,114 @@
+CONFIG_ARM=y
+CONFIG_SKIP_LOWLEVEL_INIT=y
+CONFIG_COUNTER_FREQUENCY=2400
+CONFIG_ARCH_ROCKCHIP=y
+CONFIG_TEXT_BASE=0x0020
+CONFIG_SPL_GPIO=y
+CONFIG_NR_DRAM_BANKS=1
+CONFIG_
[PATCH v2 1/2] rockchip: rk3328: Add support for Orange Pi R1 Plus
Orange Pi R1 Plus is a Rockchip RK3328 based SBC by Xunlong.
This device is similar to the NanoPi R2S, and has a 16MB
SPI NOR (mx25l12805d). The reset button is changed to
directly reset the power supply, another detail is that
both network ports have independent MAC addresses.
The device tree and description are taken from kernel v6.3-rc1.
Reviewed-by: Kever Yang
Signed-off-by: Tianling Shen
---
Changes in v2:
* Rebased upon the latest git HEAD
* Collected R-b tag.
* Removed kernel link from commit message.
---
arch/arm/dts/Makefile | 1 +
.../dts/rk3328-orangepi-r1-plus-u-boot.dtsi | 46 +++
arch/arm/dts/rk3328-orangepi-r1-plus.dts | 373 ++
board/rockchip/evb_rk3328/MAINTAINERS | 6 +
configs/orangepi-r1-plus-rk3328_defconfig | 114 ++
5 files changed, 540 insertions(+)
create mode 100644 arch/arm/dts/rk3328-orangepi-r1-plus-u-boot.dtsi
create mode 100644 arch/arm/dts/rk3328-orangepi-r1-plus.dts
create mode 100644 configs/orangepi-r1-plus-rk3328_defconfig
diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
index 480269fa60..9d189788aa 100644
--- a/arch/arm/dts/Makefile
+++ b/arch/arm/dts/Makefile
@@ -125,6 +125,7 @@ dtb-$(CONFIG_ROCKCHIP_RK3328) += \
rk3328-evb.dtb \
rk3328-nanopi-r2c.dtb \
rk3328-nanopi-r2s.dtb \
+ rk3328-orangepi-r1-plus.dtb \
rk3328-roc-cc.dtb \
rk3328-rock64.dtb \
rk3328-rock-pi-e.dtb
diff --git a/arch/arm/dts/rk3328-orangepi-r1-plus-u-boot.dtsi
b/arch/arm/dts/rk3328-orangepi-r1-plus-u-boot.dtsi
new file mode 100644
index 00..637c70adf1
--- /dev/null
+++ b/arch/arm/dts/rk3328-orangepi-r1-plus-u-boot.dtsi
@@ -0,0 +1,46 @@
+// SPDX-License-Identifier: GPL-2.0-or-later
+/*
+ * (C) Copyright 2018-2019 Rockchip Electronics Co., Ltd
+ * (C) Copyright 2020 David Bauer
+ */
+
+#include "rk3328-u-boot.dtsi"
+#include "rk3328-sdram-ddr4-666.dtsi"
+/ {
+ chosen {
+ u-boot,spl-boot-order = "same-as-spl", &sdmmc, &emmc;
+ };
+};
+
+&gpio0 {
+ bootph-pre-ram;
+};
+
+&pinctrl {
+ bootph-pre-ram;
+};
+
+&sdmmc0m1_pin {
+ bootph-pre-ram;
+};
+
+&pcfg_pull_up_4ma {
+ bootph-pre-ram;
+};
+
+/* Need this and all the pinctrl/gpio stuff above to set pinmux */
+&vcc_sd {
+ bootph-pre-ram;
+};
+
+&gmac2io {
+ snps,reset-gpio = <&gpio1 RK_PC2 GPIO_ACTIVE_LOW>;
+ snps,reset-active-low;
+ snps,reset-delays-us = <0 1 5>;
+};
+
+&spi0 {
+ spi_flash: spiflash@0 {
+ bootph-all;
+ };
+};
diff --git a/arch/arm/dts/rk3328-orangepi-r1-plus.dts
b/arch/arm/dts/rk3328-orangepi-r1-plus.dts
new file mode 100644
index 00..dc83d74045
--- /dev/null
+++ b/arch/arm/dts/rk3328-orangepi-r1-plus.dts
@@ -0,0 +1,373 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+/*
+ * Based on rk3328-nanopi-r2s.dts, which is:
+ * Copyright (c) 2020 David Bauer
+ */
+
+/dts-v1/;
+
+#include
+#include
+#include "rk3328.dtsi"
+
+/ {
+ model = "Xunlong Orange Pi R1 Plus";
+ compatible = "xunlong,orangepi-r1-plus", "rockchip,rk3328";
+
+ aliases {
+ ethernet1 = &rtl8153;
+ mmc0 = &sdmmc;
+ };
+
+ chosen {
+ stdout-path = "serial2:150n8";
+ };
+
+ gmac_clk: gmac-clock {
+ compatible = "fixed-clock";
+ clock-frequency = <12500>;
+ clock-output-names = "gmac_clkin";
+ #clock-cells = <0>;
+ };
+
+ leds {
+ compatible = "gpio-leds";
+ pinctrl-0 = <&lan_led_pin>, <&sys_led_pin>, <&wan_led_pin>;
+ pinctrl-names = "default";
+
+ led-0 {
+ function = LED_FUNCTION_LAN;
+ color = ;
+ gpios = <&gpio2 RK_PB7 GPIO_ACTIVE_HIGH>;
+ };
+
+ led-1 {
+ function = LED_FUNCTION_STATUS;
+ color = ;
+ gpios = <&gpio3 RK_PC5 GPIO_ACTIVE_HIGH>;
+ linux,default-trigger = "heartbeat";
+ };
+
+ led-2 {
+ function = LED_FUNCTION_WAN;
+ color = ;
+ gpios = <&gpio2 RK_PC2 GPIO_ACTIVE_HIGH>;
+ };
+ };
+
+ vcc_sd: sdmmc-regulator {
+ compatible = "regulator-fixed";
+ gpio = <&gpio0 RK_PD6 GPIO_ACTIVE_LOW>;
+ pinctrl-0 = <&sdmmc0m1_pin>;
+ pinctrl-names = "default";
+ regulator-name = "vcc_sd";
+ regulator-boot-on;
+ vin-supply = <&vcc_io>;
+ };
+
+ vcc_sys: vcc-sys-regulator {
+ compatible = "regulator-fixed";
+ regulator-name = "vcc_sys";
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-min-microvolt = <500>;
+
