Re: [PATCH 3/3] sunxi: H616: Add OrangePi Zero 3 board support
I built u-boot with the additional parameter for usb and it works, I think. There was one message that might be of concern " Card did not respond to voltage select! : -110". I am not sure of the details of the boot.cmd. The output below came from the supplier image on an SD plugged into a USB card reader. The SD slot of the board was empty. I was able to install u-boot to the SPI flash memory and there is a warning message from that also: " Loading Environment from SPIFlash... jedec_spi_nor flash@0: unrecognized JEDEC id bytes: 5e, 40, 18 *** Warning - spi_flash_probe_bus_cs() failed, using default environment" Thank you for your advice on getting something to boot. None of the Debian installer images were suitable. Even SID was at 6.1. I built the latest Linux 6.6.2 and wrestled with the rootfs before I got it running. I built the tested u-boot with this system, as a test of system stability. defconfig used + emac patches CONFIG_ARM=y CONFIG_ARCH_SUNXI=y CONFIG_DEFAULT_DEVICE_TREE="sun50i-h618-orangepi-zero3" CONFIG_SPL=y CONFIG_DRAM_SUN50I_H616_DX_ODT=0x07070707 CONFIG_DRAM_SUN50I_H616_DX_DRI=0x0e0e0e0e CONFIG_DRAM_SUN50I_H616_CA_DRI=0x0e0e CONFIG_DRAM_SUN50I_H616_ODT_EN=0x CONFIG_DRAM_SUN50I_H616_TPR6=0x4400 CONFIG_DRAM_SUN50I_H616_TPR10=0x402f6663 CONFIG_DRAM_SUN50I_H616_TPR11=0x24242624 CONFIG_DRAM_SUN50I_H616_TPR12=0x0f0f100f CONFIG_MACH_SUN50I_H616=y CONFIG_SUNXI_DRAM_H616_LPDDR4=y # CONFIG_DRAM_CLK=792 CONFIG_USB1_VBUS_PIN="PC16" # CONFIG_R_I2C_ENABLE=y CONFIG_SPL_SPI_SUNXI=y # CONFIG_SYS_MALLOC_CLEAR_ON_INIT is not set CONFIG_SPL_I2C=y CONFIG_SPL_SYS_I2C_LEGACY=y CONFIG_SYS_I2C_MVTWSI=y CONFIG_SYS_I2C_SLAVE=0x7f CONFIG_SYS_I2C_SPEED=40 CONFIG_SPI_FLASH_ZBIT=y CONFIG_PHY_MOTORCOMM=y CONFIG_SUN8I_EMAC=y CONFIG_AXP313_POWER=y CONFIG_SPI=y CONFIG_USB_EHCI_HCD=y CONFIG_USB_OHCI_HCD=y CONFIG_USB_MUSB_GADGET=y Console Output: U-Boot 2024.01-rc3-9-g9e53e45292-dirty (Nov 25 2023 - 18:32:16 -0800) Allwinner Technology CPU: Allwinner H616 (SUN50I) Model: OrangePi Zero3 DRAM: 1 GiB Core: 57 devices, 25 uclasses, devicetree: separate WDT: Not starting watchdog@30090a0 MMC: mmc@402: 0 Loading Environment from SPIFlash... jedec_spi_nor flash@0: unrecognized JEDEC id bytes: 5e, 40, 18 *** Warning - spi_flash_probe_bus_cs() failed, using default environment Loading Environment from FAT... Card did not respond to voltage select! : -110 ** Bad device specification mmc 0 ** In:serial@500 Out: serial@500 Err: serial@500 Allwinner mUSB OTG (Peripheral) Net: eth0: ethernet@502using musb-hdrc, OUT ep1out IN ep1in STATUS ep2in MAC de:ad:be:ef:00:01 HOST MAC de:ad:be:ef:00:00 RNDIS ready , eth1: usb_ether starting USB... Bus usb@520: USB EHCI 1.00 Bus usb@5200400: USB OHCI 1.0 scanning bus usb@520 for devices... Device NOT ready Request Sense returned 02 3A 00 Device NOT ready Request Sense returned 02 3A 00 Device NOT ready Request Sense returned 02 3A 00 2 USB Device(s) found scanning bus usb@5200400 for devices... 1 USB Device(s) found scanning usb for storage devices... 1 Storage Device(s) found Hit any key to stop autoboot: 0 Card did not respond to voltage select! : -110 Device 0: Vendor: Generic- Rev: 1.00 Prod: SD/MMC Type: Removable Hard Disk Capacity: 15193.5 MB = 14.8 GB (31116288 x 512) ... is now current device Scanning usb 0:1... Found U-Boot script /boot/boot.scr 3636 bytes read in 1 ms (3.5 MiB/s) ## Executing script at 4fc0 U-boot loaded from SD Boot script loaded from usb 205 bytes read in 1 ms (200.2 KiB/s) Failed to load '/boot/dtb/allwinner/sun50i-h618-orangepi-zero3.dtb' libfdt fdt_check_header(): FDT_ERR_BADMAGIC No FDT memory address configured. Please configure the FDT address via "fdt addr " command. Aborting! 4203 bytes read in 4 ms (1 MiB/s) Applying kernel provided DT fixup script (sun50i-h616-fixup.scr) ## Executing script at 4500 7088139 bytes read in 325 ms (20.8 MiB/s) 9419107 bytes read in 430 ms (20.9 MiB/s) Uncompressing Kernel Image Moving Image from 0x4008 to 0x4020, end=4180 ## Loading init Ramdisk from Legacy Image at 4ff0 ... Image Name: uInitrd Image Type: AArch64 Linux RAMDisk Image (gzip compressed) Data Size:7088075 Bytes = 6.8 MiB Load Address: Entry Point: Verifying Checksum ... OK ERROR: Did not find a cmdline Flattened Device Tree On 2023-11-25 4:23 p.m., Andre Przywara wrote: On Sat, 25 Nov 2023 20:43:12 +0300 Mikhail Kalashnikov wrote: Hi Mikhail, Hi Andre! Thanks for your patches. I started checking and noticed that USB storage was not working: => usb reset resetting USB... Bus usb@520: USB EHCI 1.00 Bus usb@5200400: USB OHCI 1.0 scanning bus usb@520 for devices... 1 USB Device(s) found scanning bus usb@5200400 for devices... 1 USB Device(s) found scanning usb for storage devices... 0 Storage Device(s) found => usb storage No storage devices, perhaps
Re: [GIT PULL] Please pull u-boot-dfu-20231124
On Fri, Nov 24, 2023 at 11:39:39AM +0100, Mattijs Korpershoek wrote: > Hi Tom, > > Here are some fixes for master including: > > - Fix reinit for ChipIdea controller > - Add missing newline in fastboot error handling > > This CI job is at > https://source.denx.de/u-boot/custodians/u-boot-dfu/-/pipelines/18703 > > Thanks, > Mattijs > > The following changes since commit 24ca49b33af98d54d6cd2e845f071f6565345ffd: > > Prepare v2024.01-rc3 (2023-11-20 08:43:46 -0500) > > are available in the Git repository at: > > https://source.denx.de/u-boot/custodians/u-boot-dfu.git > tags/u-boot-dfu-20231124 > > for you to fetch changes up to 6f68dcd0259f9f1c03f097669e9490b13b5325c7: > > usb: fastboot: Add missing newline in pr_err (2023-11-21 09:19:48 +0100) > Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH 3/3] sunxi: H616: Add OrangePi Zero 3 board support
On Sat, 25 Nov 2023 20:43:12 +0300 Mikhail Kalashnikov wrote: Hi Mikhail, > Hi Andre! > Thanks for your patches. I started checking and noticed that USB storage > was not working: > > => usb reset > resetting USB... > Bus usb@520: USB EHCI 1.00 > Bus usb@5200400: USB OHCI 1.0 > scanning bus usb@520 for devices... 1 USB Device(s) found > scanning bus usb@5200400 for devices... 1 USB Device(s) found > scanning usb for storage devices... 0 Storage Device(s) found > => usb storage > No storage devices, perhaps not 'usb start'ed..? Ah, thanks for the report, seems I didn't even test this! So digging around I figured it's working in Linux, and it's the right USB port, but we are missing the VBUS power switch, which is a GPIO controlled regulator. There are pending patches to pick this from the devicetree[1], but we are not there yet, so we need: CONFIG_USB1_VBUS_PIN="PC16" in the defconfig, for now. I will update the file. The same is actually missing from the OrangePi Zero2 defconfig, I will send a patch ASAP. > Otherwise my OpiZero3 (4GB) board looks working. > Ethernet works with my 10 Mbps usb-dongle. > > sf probe detect spi nor flash: > => sf probe > SF: Detected zb25vq128 with page size 256 Bytes, erase size 4 KiB, total > 16 MiB > > Loading the kernel and running the operating system (from microsd) also > without problems. > > Tested-by: Mikhail Kalashnikov Great, thanks for the tag! Cheers, Andre > On 14.11.2023 04:31, Andre Przywara wrote: > > The OrangePi Zero 3 is a small development board featuring the Allwinner > > H618 SoC, shipping with up to 4GB of DRAM, Gigabit Ethernet, a micro-HDMI > > connector and two USB sockets. > > The board uses LPDDR4 DRAM and an X-Powers AXP313a PMIC, support for > > which was recently added to U-Boot. > > > > Add a defconfig file selecting the right drivers and DRAM options. > > Since the .dts file was synced from the Linux kernel repo already, we > > just need to add one line to the Makefile to actually build the .dtb. > > > > The DRAM parameters were derived from the values found in the BSP DRAM > > drivers on the SPI NOR flash. > > > > Signed-off-by: Andre Przywara > > --- > > arch/arm/dts/Makefile| 1 + > > board/sunxi/MAINTAINERS | 5 + > > configs/orangepi_zero3_defconfig | 30 ++ > > 3 files changed, 36 insertions(+) > > create mode 100644 configs/orangepi_zero3_defconfig > > > > diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile > > index 1be08c5fdc2..5fc888680b3 100644 > > --- a/arch/arm/dts/Makefile > > +++ b/arch/arm/dts/Makefile > > @@ -835,6 +835,7 @@ dtb-$(CONFIG_MACH_SUN50I_H6) += \ > > sun50i-h6-tanix-tx6-mini.dtb > > dtb-$(CONFIG_MACH_SUN50I_H616) += \ > > sun50i-h616-orangepi-zero2.dtb \ > > + sun50i-h618-orangepi-zero3.dtb \ > > sun50i-h616-x96-mate.dtb > > dtb-$(CONFIG_MACH_SUN50I) += \ > > sun50i-a64-amarula-relic.dtb \ > > diff --git a/board/sunxi/MAINTAINERS b/board/sunxi/MAINTAINERS > > index 00614372119..f556857a391 100644 > > --- a/board/sunxi/MAINTAINERS > > +++ b/board/sunxi/MAINTAINERS > > @@ -455,6 +455,11 @@ M: Jernej Skrabec > > S:Maintained > > F:configs/orangepi_zero2_defconfig > > > > +ORANGEPI ZERO 3 BOARD > > +M: Andre Przywara > > +S: Maintained > > +F: configs/orangepi_zero3_defconfig > > + > > ORANGEPI PC 2 BOARD > > M:Andre Przywara > > S:Maintained > > diff --git a/configs/orangepi_zero3_defconfig > > b/configs/orangepi_zero3_defconfig > > new file mode 100644 > > index 000..e59044f6639 > > --- /dev/null > > +++ b/configs/orangepi_zero3_defconfig > > @@ -0,0 +1,30 @@ > > +CONFIG_ARM=y > > +CONFIG_ARCH_SUNXI=y > > +CONFIG_DEFAULT_DEVICE_TREE="sun50i-h618-orangepi-zero3" > > +CONFIG_SPL=y > > +CONFIG_DRAM_SUN50I_H616_DX_ODT=0x07070707 > > +CONFIG_DRAM_SUN50I_H616_DX_DRI=0x0e0e0e0e > > +CONFIG_DRAM_SUN50I_H616_CA_DRI=0x0e0e > > +CONFIG_DRAM_SUN50I_H616_ODT_EN=0x > > +CONFIG_DRAM_SUN50I_H616_TPR6=0x4400 > > +CONFIG_DRAM_SUN50I_H616_TPR10=0x402f6663 > > +CONFIG_DRAM_SUN50I_H616_TPR11=0x24242624 > > +CONFIG_DRAM_SUN50I_H616_TPR12=0x0f0f100f > > +CONFIG_MACH_SUN50I_H616=y > > +CONFIG_SUNXI_DRAM_H616_LPDDR4=y > > +CONFIG_R_I2C_ENABLE=y > > +CONFIG_SPL_SPI_SUNXI=y > > +# CONFIG_SYS_MALLOC_CLEAR_ON_INIT is not set > > +CONFIG_SPL_I2C=y > > +CONFIG_SPL_SYS_I2C_LEGACY=y > > +CONFIG_SYS_I2C_MVTWSI=y > > +CONFIG_SYS_I2C_SLAVE=0x7f > > +CONFIG_SYS_I2C_SPEED=40 > > +CONFIG_SPI_FLASH_ZBIT=y > > +CONFIG_PHY_MOTORCOMM=y > > +CONFIG_SUN8I_EMAC=y > > +CONFIG_AXP313_POWER=y > > +CONFIG_SPI=y > > +CONFIG_USB_EHCI_HCD=y > > +CONFIG_USB_OHCI_HCD=y > > +CONFIG_USB_MUSB_GADGET=y >
Re: Licensing discrepancies or ambiguities
On 2023-11-21, Tom Rini wrote: > On Tue, Nov 21, 2023 at 11:10:57AM -0800, Vagrant Cascadian wrote: > >> I've been reviewing the copyright and license information for Das U-Boot >> in preparation for uploading to Debian, and found a few surprises. >> >> tools/libfdt/fdt_rw.c: /* SPDX-License-Identifier: GPL-2.0+ BSD-2-Clause */ > > This comes from the kernel and has been clarified there: > // SPDX-License-Identifier: (GPL-2.0-or-later OR BSD-2-Clause) That's much better! Thanks for looking into it! I suspect there are quite a few that get pulled in from linux or elsewhere that might have similar issues. >> I *think* according to the SPDX spec this needs an OR or an AND. I also >> see no copyright declaration, although maybe there is a standard >> interpretation for this. >> >> Similar issue with (though thankfully they include copyright >> declarations): >> >> include/bloblist.h:/* SPDX-License-Identifier: GPL-2.0+ BSD-3-Clause */ >> common/bloblist.c:// SPDX-License-Identifier: GPL-2.0+ BSD-3-Clause > > Simon? > >> doc/README.ubispl:# SPDX-License-Identifier: GPL 2.0+ BSD-3-Clause > > Should be an OR as well, yes, but it's also out of date and we could > just delete if a problem. Ok. >> This one has a non-existent license: >> >> test/lib/strlcat.c: // SPDX-License-Identifier: GPL-2.1+ >> >> No such license exists, though thankfully it references the exact file >> in the original glibc sources it came from, which is listed as >> LGPL-2.1+. > > Since you did the research would you mind sending the patch? Thanks. Will do eventually! Also found some more ambiguous ones where the license text is in conflict with the SPDX identifiers: arch/sandbox/cpu/u-boot-spl.lds-/* SPDX-License-Identifier: GPL-2.0+ */ arch/sandbox/cpu/u-boot-spl.lds-/* arch/sandbox/cpu/u-boot-spl.lds- * Copyright (c) 2011-2012 The Chromium OS Authors. arch/sandbox/cpu/u-boot-spl.lds: * Use of this source code is governed by a BSD-style license that can be arch/sandbox/cpu/u-boot-spl.lds- * found in the LICENSE file. arch/sandbox/cpu/u-boot-spl.lds- */ The referred to LICENSE file does not appear to exist in u-boot, and exactly what the text of this BSD-style license is ... a mystery. And lib/zstd includes many entries in a similar situation: lib/zstd/Makefile-# Copyright (c) Facebook, Inc. lib/zstd/Makefile-# All rights reserved. lib/zstd/Makefile-# lib/zstd/Makefile:# This source code is licensed under both the BSD-style license (found in the lib/zstd/Makefile-# LICENSE file in the root directory of this source tree) and the GPLv2 (found lib/zstd/Makefile-# in the COPYING file in the root directory of this source tree). lib/zstd/Makefile-# You may select, at your option, one of the above-listed licenses. This seems like it would be "GPL-2.0 OR BSD-*something*", but it is unclear what BSD-style maps to, as the LICENSE file is not present where it claims. Many similar discrepancies can be found with: git grep -B4 -A3 'BSD-style' I probably have mroe to dig up, but these are the ones that leapt out at me for now! live well, vagrant signature.asc Description: PGP signature
Re: [GIT PULL] Please pull u-boot-dfu-next-20231124
On Fri, Nov 24, 2023 at 11:44:14AM +0100, Mattijs Korpershoek wrote: > Hi Tom, > > Here are some developments for next including: > > - Make dfu entity name size configurable in KConfig > - Implement start-stop for UMS (graceful shutdown via eject) > - Improve help messages for cmd/bind > - Improve help message for udc bind failures > > The CI job is at > https://source.denx.de/u-boot/custodians/u-boot-dfu/-/pipelines/18704 > > Thanks, > Mattijs > > The following changes since commit dca7a8958f8d0dbd53072caa4353353e062d80ca: > > Merge tag 'v2024.01-rc3' into next (2023-11-20 09:19:50 -0500) > > are available in the Git repository at: > > https://source.denx.de/u-boot/custodians/u-boot-dfu.git > tags/u-boot-dfu-next-20231124 > > for you to fetch changes up to 8a0d07807abb5370fe879321c7f1d22fdda3255f: > > usb: udc: Try to clarify an error message (2023-11-21 15:48:38 +0100) > Applied to u-boot/next, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH v2 1/4] arm: dts: npcm845-evb: fix/add node and aliases
On Tue, Nov 14, 2023 at 04:51:56PM +0800, Jim Liu wrote: > Modify spi and usb aliases name. > Add dt-binding for usb phy define and fix usb phy reset error. > Add tpm/otpee and host_intf node. > > Signed-off-by: Jim Liu For the series, applied to u-boot/next, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH] boards: Disable NET on platforms without NETDEVICES
On Fri, Nov 17, 2023 at 10:47:57AM -0500, Tom Rini wrote: > None of these platforms enabled a networking devices, and disabled > CMD_NET. Given that we used to gate network support on CMD_NET rather > than NET, we disable CONFIG_NET on these platforms now. > > Signed-off-by: Tom Rini > Reviewed-by: Simon Glass Applied to u-boot/next, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH] net: Make NET imply NETDEVICES
On Wed, Nov 08, 2023 at 07:12:25PM -0500, Tom Rini wrote: > Normally, when NET is enabled, CMD_NET will then be enabled and in turn > NETDEVICES will (likely) be enabled via imply. However, if we disable > CMDLINE in a defconfig we now no longer get CMD_NET enabling NETDEVICES > for us. This suggestion (as an imply is) really isn't about the network > commands but network itself and is a legacy of how intertwined > NET/CMD_NET were historically. Move this over to the NET entry instead > where it is a more logical fit. > > Reported-by: Simon Glass > Signed-off-by: Tom Rini > Reviewed-by: Simon Glass > Tested-by: Simon Glass Applied to u-boot/next, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH 1/6] siemens,am335x: clean-up draco targets
On Wed, Nov 08, 2023 at 03:53:17PM +0100, Enrico Leto wrote: > Draco is a family of 3 boards: thuban, rastaban & etamin. Rename all > targets of the family adding the draco- prefix to increase readibility > and simplify future commits about concerning all boards of the family. > > The name draco was initially used for the first target. It's deprecated > since a 2nd target was introduced. Unfortunately the draco target was > copied to the thuban target instead to be renamed. Remove it to save > unnecessary maintenance effort. > > Signed-off-by: Enrico Leto For the series, applied to u-boot/next, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH 3/3] sunxi: H616: Add OrangePi Zero 3 board support
Hi Andre! Thanks for your patches. I started checking and noticed that USB storage was not working: => usb reset resetting USB... Bus usb@520: USB EHCI 1.00 Bus usb@5200400: USB OHCI 1.0 scanning bus usb@520 for devices... 1 USB Device(s) found scanning bus usb@5200400 for devices... 1 USB Device(s) found scanning usb for storage devices... 0 Storage Device(s) found => usb storage No storage devices, perhaps not 'usb start'ed..? Otherwise my OpiZero3 (4GB) board looks working. Ethernet works with my 10 Mbps usb-dongle. sf probe detect spi nor flash: => sf probe SF: Detected zb25vq128 with page size 256 Bytes, erase size 4 KiB, total 16 MiB Loading the kernel and running the operating system (from microsd) also without problems. Tested-by: Mikhail Kalashnikov On 14.11.2023 04:31, Andre Przywara wrote: The OrangePi Zero 3 is a small development board featuring the Allwinner H618 SoC, shipping with up to 4GB of DRAM, Gigabit Ethernet, a micro-HDMI connector and two USB sockets. The board uses LPDDR4 DRAM and an X-Powers AXP313a PMIC, support for which was recently added to U-Boot. Add a defconfig file selecting the right drivers and DRAM options. Since the .dts file was synced from the Linux kernel repo already, we just need to add one line to the Makefile to actually build the .dtb. The DRAM parameters were derived from the values found in the BSP DRAM drivers on the SPI NOR flash. Signed-off-by: Andre Przywara --- arch/arm/dts/Makefile| 1 + board/sunxi/MAINTAINERS | 5 + configs/orangepi_zero3_defconfig | 30 ++ 3 files changed, 36 insertions(+) create mode 100644 configs/orangepi_zero3_defconfig diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile index 1be08c5fdc2..5fc888680b3 100644 --- a/arch/arm/dts/Makefile +++ b/arch/arm/dts/Makefile @@ -835,6 +835,7 @@ dtb-$(CONFIG_MACH_SUN50I_H6) += \ sun50i-h6-tanix-tx6-mini.dtb dtb-$(CONFIG_MACH_SUN50I_H616) += \ sun50i-h616-orangepi-zero2.dtb \ + sun50i-h618-orangepi-zero3.dtb \ sun50i-h616-x96-mate.dtb dtb-$(CONFIG_MACH_SUN50I) += \ sun50i-a64-amarula-relic.dtb \ diff --git a/board/sunxi/MAINTAINERS b/board/sunxi/MAINTAINERS index 00614372119..f556857a391 100644 --- a/board/sunxi/MAINTAINERS +++ b/board/sunxi/MAINTAINERS @@ -455,6 +455,11 @@ M: Jernej Skrabec S:Maintained F:configs/orangepi_zero2_defconfig +ORANGEPI ZERO 3 BOARD +M: Andre Przywara +S: Maintained +F: configs/orangepi_zero3_defconfig + ORANGEPI PC 2 BOARD M:Andre Przywara S:Maintained diff --git a/configs/orangepi_zero3_defconfig b/configs/orangepi_zero3_defconfig new file mode 100644 index 000..e59044f6639 --- /dev/null +++ b/configs/orangepi_zero3_defconfig @@ -0,0 +1,30 @@ +CONFIG_ARM=y +CONFIG_ARCH_SUNXI=y +CONFIG_DEFAULT_DEVICE_TREE="sun50i-h618-orangepi-zero3" +CONFIG_SPL=y +CONFIG_DRAM_SUN50I_H616_DX_ODT=0x07070707 +CONFIG_DRAM_SUN50I_H616_DX_DRI=0x0e0e0e0e +CONFIG_DRAM_SUN50I_H616_CA_DRI=0x0e0e +CONFIG_DRAM_SUN50I_H616_ODT_EN=0x +CONFIG_DRAM_SUN50I_H616_TPR6=0x4400 +CONFIG_DRAM_SUN50I_H616_TPR10=0x402f6663 +CONFIG_DRAM_SUN50I_H616_TPR11=0x24242624 +CONFIG_DRAM_SUN50I_H616_TPR12=0x0f0f100f +CONFIG_MACH_SUN50I_H616=y +CONFIG_SUNXI_DRAM_H616_LPDDR4=y +CONFIG_R_I2C_ENABLE=y +CONFIG_SPL_SPI_SUNXI=y +# CONFIG_SYS_MALLOC_CLEAR_ON_INIT is not set +CONFIG_SPL_I2C=y +CONFIG_SPL_SYS_I2C_LEGACY=y +CONFIG_SYS_I2C_MVTWSI=y +CONFIG_SYS_I2C_SLAVE=0x7f +CONFIG_SYS_I2C_SPEED=40 +CONFIG_SPI_FLASH_ZBIT=y +CONFIG_PHY_MOTORCOMM=y +CONFIG_SUN8I_EMAC=y +CONFIG_AXP313_POWER=y +CONFIG_SPI=y +CONFIG_USB_EHCI_HCD=y +CONFIG_USB_OHCI_HCD=y +CONFIG_USB_MUSB_GADGET=y
[PATCH v2] remoteproc: k3-dsp: Avoid reloading of firmware
DSP core is going into abnormal state when load callback is called
after starting of DSP core.
Reload of firmware needs core to be stopped first, followed by
load.
So avoid loading of firmware, when core is started.
Signed-off-by: Udit Kumar
---
Change log:
Changes in v2:
- Added details for in_use variable in comment
- Link to v1
https://lore.kernel.org/all/20231124063111.1744600-1-u-kum...@ti.com/
drivers/remoteproc/ti_k3_dsp_rproc.c | 11 +++
1 file changed, 11 insertions(+)
diff --git a/drivers/remoteproc/ti_k3_dsp_rproc.c
b/drivers/remoteproc/ti_k3_dsp_rproc.c
index 576de4bb26..1c6515f9ab 100644
--- a/drivers/remoteproc/ti_k3_dsp_rproc.c
+++ b/drivers/remoteproc/ti_k3_dsp_rproc.c
@@ -56,6 +56,7 @@ struct k3_dsp_boot_data {
* @data: Pointer to DSP specific boot data structure
* @mem: Array of available memories
* @num_mem: Number of available memories
+ * @in_use: flag to tell if the core is already in use.
*/
struct k3_dsp_privdata {
struct reset_ctl dsp_rst;
@@ -63,6 +64,7 @@ struct k3_dsp_privdata {
struct k3_dsp_boot_data *data;
struct k3_dsp_mem *mem;
int num_mems;
+ bool in_use;
};
/*
@@ -128,6 +130,13 @@ static int k3_dsp_load(struct udevice *dev, ulong addr,
ulong size)
u32 boot_vector;
int ret;
+ if (dsp->in_use) {
+ dev_err(dev,
+ "Invalid op: Trying to load/start on already running
core %d\n",
+ dsp->tsp.proc_id);
+ return -EINVAL;
+ }
+
dev_dbg(dev, "%s addr = 0x%lx, size = 0x%lx\n", __func__, addr, size);
ret = ti_sci_proc_request(>tsp);
if (ret)
@@ -195,6 +204,7 @@ static int k3_dsp_start(struct udevice *dev)
ti_sci_proc_power_domain_off(>tsp);
}
+ dsp->in_use = true;
proc_release:
ti_sci_proc_release(>tsp);
@@ -207,6 +217,7 @@ static int k3_dsp_stop(struct udevice *dev)
dev_dbg(dev, "%s\n", __func__);
+ dsp->in_use = false;
ti_sci_proc_request(>tsp);
reset_assert(>dsp_rst);
ti_sci_proc_power_domain_off(>tsp);
--
2.34.1
[PATCH v4 8/8] doc: spl: Add info regarding memory reservation
Add details regarding scheme which need to be followed in SPL and further stages for those regions which need to be preserved across bootstages. Signed-off-by: Devarsh Thakkar --- V1->V3: No change. V4: Split this to separate patch and add more details regarding memory reservation scheme that needs to be followed at SPL. --- doc/develop/spl.rst | 28 1 file changed, 28 insertions(+) diff --git a/doc/develop/spl.rst b/doc/develop/spl.rst index 814530d348..0a3e572310 100644 --- a/doc/develop/spl.rst +++ b/doc/develop/spl.rst @@ -173,3 +173,31 @@ cflow will spit out a number of warnings as it does not parse the config files and picks functions based on #ifdef. Parsing the '.i' files instead introduces another set of headaches. These warnings are not usually important to understanding the flow, however. + + +Reserving memory in SPL +--- + +If memory needs to be reserved in RAM during SPL stage with the requirement that +the SPL reserved memory remains preserved across further boot stages too +then it needs to be reserved mandatorily starting from end of RAM. This is to +ensure that further stages can simply skip this region before carrying out +further reservations or updating the relocation address. + +Also out of these regions which are to be preserved across further stages of +boot, video framebuffer memory region must be reserved first starting from +end of RAM for which helper function spl_reserve_video_from_ram_top is provided +which makes sure that video memory is placed at top of reservation area with +further reservations below it. + +The corresponding information of reservation for those regions can be passed to +further boot stages using a bloblist. For e.g. the information for +framebuffer area reserved by SPL can be passed onto U-boot using +BLOBLISTT_U_BOOT_VIDEO. + +The further boot stages need to parse each of the bloblist passed from SPL stage +starting from video bloblist and skip this whole SPL reserved memory area from +end of RAM as per the bloblists received, before carrying out further +reservations or updating the relocation address. For e.g, U-boot proper uses +function "setup_relocaddr_from_bloblist" to parse the bloblists passed from +previous stage and skip the memory reserved from previous stage accordingly. -- 2.34.1
[PATCH v4 7/8] doc: spl: Add info for missing Kconfigs
Add info regarding splash screen, video, bloblist and GPIO related Kconfigs which were missing in the documentation. Signed-off-by: Devarsh Thakkar --- V2: No change V3: No change V4: Patch split from parent --- doc/develop/spl.rst | 9 + 1 file changed, 9 insertions(+) diff --git a/doc/develop/spl.rst b/doc/develop/spl.rst index 76e87f07c7..814530d348 100644 --- a/doc/develop/spl.rst +++ b/doc/develop/spl.rst @@ -65,6 +65,15 @@ CONFIG_SPL_NAND_LOAD (drivers/mtd/nand/raw/nand_spl_load.o) CONFIG_SPL_SPI_LOAD (drivers/mtd/spi/spi_spl_load.o) CONFIG_SPL_RAM_DEVICE (common/spl/spl.c) CONFIG_SPL_WATCHDOG (drivers/watchdog/libwatchdog.o) +CONFIG_SPL_SYSCON (drivers/core/syscon-uclass.o) +CONFIG_SPL_GZIP (lib/gzip.o) +CONFIG_SPL_VIDEO (drivers/video/video-uclass.o drivers/video/vidconsole-uclass.o) +CONFIG_SPL_SPLASH_SCREEN (common/splash.o) +CONFIG_SPL_SPLASH_SOURCE (common/splash_source.o) +CONFIG_SPL_GPIO (drivers/gpio) +CONFIG_SPL_DM_GPIO (drivers/gpio/gpio-uclass.o) +CONFIG_SPL_BMP (drivers/video/bmp.o) +CONFIG_SPL_BLOBLIST (common/bloblist.o) Adding SPL-specific code -- 2.34.1
[PATCH v4 6/8] video: Fill video handoff in video post probe
Fill video handoff fields in video_post_probe as at this point we have
full framebuffer-related information.
Also fill all the fields available in video hand-off struct as those
were missing earlier and U-boot framework expects them to be filled for
some of the functionalities.
Reported-by: Simon Glass
Signed-off-by: Devarsh Thakkar
---
V2:
- No change
V3:
- Fix commit message per review comment
- Add a note explaining assumption of single framebuffer
V4:
- Wrap message to 72 chars
---
drivers/video/video-uclass.c | 29 +++--
1 file changed, 19 insertions(+), 10 deletions(-)
diff --git a/drivers/video/video-uclass.c b/drivers/video/video-uclass.c
index 378f01f3d7..f4cebf3087 100644
--- a/drivers/video/video-uclass.c
+++ b/drivers/video/video-uclass.c
@@ -144,16 +144,6 @@ int video_reserve(ulong *addrp)
debug("Video frame buffers from %lx to %lx\n", gd->video_bottom,
gd->video_top);
- if (spl_phase() == PHASE_SPL && CONFIG_IS_ENABLED(VIDEO_HANDOFF)) {
- struct video_handoff *ho;
-
- ho = bloblist_add(BLOBLISTT_U_BOOT_VIDEO, sizeof(*ho), 0);
- if (!ho)
- return log_msg_ret("blf", -ENOENT);
- ho->fb = *addrp;
- ho->size = size;
- }
-
return 0;
}
@@ -552,6 +542,25 @@ static int video_post_probe(struct udevice *dev)
priv->fb_size = priv->line_length * priv->ysize;
+ /*
+* Set up video handoff fields for passing video blob to next stage
+* NOTE:
+* This assumes that reserved video memory only uses a single
framebuffer
+*/
+ if (spl_phase() == PHASE_SPL && CONFIG_IS_ENABLED(BLOBLIST)) {
+ struct video_handoff *ho;
+
+ ho = bloblist_add(BLOBLISTT_U_BOOT_VIDEO, sizeof(*ho), 0);
+ if (!ho)
+ return log_msg_ret("blf", -ENOENT);
+ ho->fb = gd->video_bottom;
+ ho->size = gd->video_top - gd->video_bottom;
+ ho->xsize = priv->xsize;
+ ho->ysize = priv->ysize;
+ ho->line_length = priv->line_length;
+ ho->bpix = priv->bpix;
+ }
+
if (IS_ENABLED(CONFIG_VIDEO_COPY) && plat->copy_base)
priv->copy_fb = map_sysmem(plat->copy_base, plat->size);
--
2.34.1
[PATCH v4 5/8] video: Skip framebuffer reservation if already reserved
Skip framebufer reservation if it was already reserved from previous
stage and whose information was passed using a bloblist.
Return error in case framebuffer information received from bloblist is
invalid i.e NULL or empty.
While at it, improve the debug message to make it more clear that
address in discussion is of framebuffer and not bloblist and also match
it with printing scheme followed in video_reserve function.
Signed-off-by: Devarsh Thakkar
---
V2:
- Add debug prints
- Fix commenting style
V3:
- Fix commenting style
V4:
- Remove extra checks on gd for video data in video_reserve
- Add check and return error if video handoff provided info is invalid
- Improve debug message
- Remove Reviewed-by due to additional changes per review comments
---
common/board_f.c | 8 ++--
drivers/video/video-uclass.c | 10 --
2 files changed, 14 insertions(+), 4 deletions(-)
diff --git a/common/board_f.c b/common/board_f.c
index acf802c9cb..442b8349d0 100644
--- a/common/board_f.c
+++ b/common/board_f.c
@@ -407,11 +407,15 @@ static int reserve_video_from_videoblob(void)
{
if (IS_ENABLED(CONFIG_SPL_VIDEO_HANDOFF) && spl_phase() > PHASE_SPL) {
struct video_handoff *ho;
+ int ret = 0;
ho = bloblist_find(BLOBLISTT_U_BOOT_VIDEO, sizeof(*ho));
if (!ho)
- return log_msg_ret("blf", -ENOENT);
- video_reserve_from_bloblist(ho);
+ return log_msg_ret("Missing video bloblist", -ENOENT);
+
+ ret = video_reserve_from_bloblist(ho);
+ if (ret)
+ return log_msg_ret("Invalid Video handoff info", ret);
/* Sanity check fb from blob is before current relocaddr */
if (likely(gd->relocaddr > (unsigned long)ho->fb))
diff --git a/drivers/video/video-uclass.c b/drivers/video/video-uclass.c
index f743ed74c8..378f01f3d7 100644
--- a/drivers/video/video-uclass.c
+++ b/drivers/video/video-uclass.c
@@ -123,6 +123,9 @@ int video_reserve(ulong *addrp)
struct udevice *dev;
ulong size;
+ if (IS_ENABLED(CONFIG_SPL_VIDEO_HANDOFF) && spl_phase() > PHASE_SPL)
+ return 0;
+
gd->video_top = *addrp;
for (uclass_find_first_device(UCLASS_VIDEO, );
dev;
@@ -208,11 +211,14 @@ int video_fill_part(struct udevice *dev, int xstart, int
ystart, int xend,
int video_reserve_from_bloblist(struct video_handoff *ho)
{
+ if (!ho->fb || ho->size == 0)
+ return -ENOENT;
+
gd->video_bottom = ho->fb;
gd->fb_base = ho->fb;
gd->video_top = ho->fb + ho->size;
- debug("Reserving %luk for video using blob at: %08x\n",
- ((unsigned long)ho->size) >> 10, (u32)ho->fb);
+ debug("%s: Reserving %lx bytes at %08x as per bloblist received\n",
+ __func__, (unsigned long)ho->size, (u32)ho->fb);
return 0;
}
--
2.34.1
[PATCH v4 4/8] common/board_f: Catch bloblist before starting resevations
Start reservations needed for init sequence only after catching
bloblists from previous stage.
This is to avoid catching bloblists in the middle causing gaps while
u-boot is reserving.
Adjust the relocaddr as per video hand-off information received from
previous stage so that further reservations start only after regions
reserved for previous stages
Skip reservation for video memory if it was already filled by a
bloblist.
Signed-off-by: Devarsh Thakkar
Reviewed-by: Simon Glass
---
V2: Fix typo in commit title and checkpatch warnings/checks
V3: No change
V4: Add Reviewed-by
---
common/board_f.c | 33 ++---
1 file changed, 30 insertions(+), 3 deletions(-)
diff --git a/common/board_f.c b/common/board_f.c
index d4d7d01f8f..acf802c9cb 100644
--- a/common/board_f.c
+++ b/common/board_f.c
@@ -403,7 +403,7 @@ __weak int arch_reserve_mmu(void)
return 0;
}
-static int reserve_video(void)
+static int reserve_video_from_videoblob(void)
{
if (IS_ENABLED(CONFIG_SPL_VIDEO_HANDOFF) && spl_phase() > PHASE_SPL) {
struct video_handoff *ho;
@@ -412,8 +412,34 @@ static int reserve_video(void)
if (!ho)
return log_msg_ret("blf", -ENOENT);
video_reserve_from_bloblist(ho);
- gd->relocaddr = ho->fb;
- } else if (CONFIG_IS_ENABLED(VIDEO)) {
+
+ /* Sanity check fb from blob is before current relocaddr */
+ if (likely(gd->relocaddr > (unsigned long)ho->fb))
+ gd->relocaddr = ho->fb;
+ }
+
+ return 0;
+}
+
+/*
+ * Check if any bloblist received specifying reserved areas from previous
stage and adjust
+ * gd->relocaddr accordingly, so that we start reserving after pre-reserved
areas
+ * from previous stage.
+ *
+ * NOTE:
+ * IT is recommended that all bloblists from previous stage are reserved from
ram_top
+ * as next stage will simply start reserving further regions after them.
+ */
+static int setup_relocaddr_from_bloblist(void)
+{
+ reserve_video_from_videoblob();
+
+ return 0;
+}
+
+static int reserve_video(void)
+{
+ if (CONFIG_IS_ENABLED(VIDEO)) {
ulong addr;
int ret;
@@ -923,6 +949,7 @@ static const init_fnc_t init_sequence_f[] = {
reserve_pram,
#endif
reserve_round_4k,
+ setup_relocaddr_from_bloblist,
arch_reserve_mmu,
reserve_video,
reserve_trace,
--
2.34.1
[PATCH v4 3/8] board: ti: am62x: evm: Remove video_setup from spl_board_init
Remove video_setup from evm_init sequence since video memory is getting
called at an earlier place to make sure video memory is reserved at
the end of RAM.
Suggested-by: Simon Glass
Signed-off-by: Devarsh Thakkar
Reviewed-by: Simon Glass
---
V2: No change
V3: No change
V4: Add Reviewed-by
---
board/ti/am62x/evm.c | 18 --
1 file changed, 18 deletions(-)
diff --git a/board/ti/am62x/evm.c b/board/ti/am62x/evm.c
index ad93908840..88e02155ee 100644
--- a/board/ti/am62x/evm.c
+++ b/board/ti/am62x/evm.c
@@ -60,27 +60,9 @@ int dram_init_banksize(void)
}
#if defined(CONFIG_SPL_BUILD)
-static int video_setup(void)
-{
- if (CONFIG_IS_ENABLED(VIDEO)) {
- ulong addr;
- int ret;
-
- addr = gd->relocaddr;
- ret = video_reserve();
- if (ret)
- return ret;
- debug("Reserving %luk for video at: %08lx\n",
- ((unsigned long)gd->relocaddr - addr) >> 10, addr);
- gd->relocaddr = addr;
- }
-
- return 0;
-}
void spl_board_init(void)
{
- video_setup();
enable_caches();
if (IS_ENABLED(CONFIG_SPL_SPLASH_SCREEN) && IS_ENABLED(CONFIG_SPL_BMP))
splash_display();
--
2.34.1
[PATCH v4 1/8] spl: Enforce framebuffer reservation from end of RAM
Add an API which enforces framebuffer reservation from end of RAM.
This is done so that next stage can directly skip this region before
carrying out further reservations.
Signed-off-by: Devarsh Thakkar
---
V2:
No change.
V3:
Change spl_reserve_video to spl_reserve_video_from_ram_top
which enforce framebuffer reservation from end of RAM.
V4:
Split this to an independent patch with more details added
in comments for API in header file.
---
common/spl/spl.c | 19 +++
include/spl.h| 10 ++
2 files changed, 29 insertions(+)
diff --git a/common/spl/spl.c b/common/spl/spl.c
index 3ce5bfeec8..b65c439e7a 100644
--- a/common/spl/spl.c
+++ b/common/spl/spl.c
@@ -42,6 +42,7 @@
#include
#include
#include
+#include
DECLARE_GLOBAL_DATA_PTR;
DECLARE_BINMAN_MAGIC_SYM;
@@ -152,6 +153,24 @@ void spl_fixup_fdt(void *fdt_blob)
#endif
}
+int spl_reserve_video_from_ram_top(void)
+{
+ if (CONFIG_IS_ENABLED(VIDEO)) {
+ ulong addr;
+ int ret;
+
+ addr = gd->ram_top;
+ ret = video_reserve();
+ if (ret)
+ return ret;
+ debug("Reserving %luk for video at: %08lx\n",
+ ((unsigned long)gd->relocaddr - addr) >> 10, addr);
+ gd->relocaddr = addr;
+ }
+
+ return 0;
+}
+
ulong spl_get_image_pos(void)
{
if (!CONFIG_IS_ENABLED(BINMAN_UBOOT_SYMBOLS))
diff --git a/include/spl.h b/include/spl.h
index 0952188901..043875f10f 100644
--- a/include/spl.h
+++ b/include/spl.h
@@ -889,6 +889,16 @@ int spl_usb_load(struct spl_image_info *spl_image,
int spl_ymodem_load_image(struct spl_image_info *spl_image,
struct spl_boot_device *bootdev);
+/**
+ * spl_reserve_video_from_ram_top() - Reserve framebuffer memory from end of
RAM
+ *
+ * This enforces framebuffer reservation at SPL stage from end of RAM so that
+ * next stage can directly skip this pre-reserved area before carrying out
+ * further reservations. The allocation address is stored in struct
video_uc_plat.
+ *
+ * Return: 0 on success, otherwise error code
+ */
+int spl_reserve_video_from_ram_top(void);
/**
* spl_invoke_atf - boot using an ARM trusted firmware image
--
2.34.1
[PATCH v4 0/8] Move framebuffer reservation for SPL to RAM end
Move video memory reservation for SPL at end of RAM so that it does not interefere with reservations for next stage so that the next stage need not have holes in between for passed regions and instead it can maintain continuity in reservations. Also catch the bloblist before starting reservations to avoid the same problem. While at it, also fill missing fields in video handoff struct before passing it to next stage. This is as per discussions at : For moving SPL framebuffer reservation at end of RAM: https://lore.kernel.org/all/capnjgz3xsoe_g3yrqwuavoivjufz+yqgkor0ztvxgt9vk8t...@mail.gmail.com/ For filling missing video handoff fields : https://lore.kernel.org/all/CAPnjgZ1Hs0rNf0JDirp6YPsOQ5=qqqsp9g9qrwlooasuv8a...@mail.gmail.com/ Changelog: V2: - Make a generic function to reserve video memory at SPL stage. - Add debug prints while skipping framebuffer allocation at uboot. - Correct commenting style as suggested. V3: - Change spl_reserve_video to spl_reserve_video_from_ram_top which enforce framebuffer reservation from end of RAM. - Use gd->ram_top instead of local ram_top and update gd->reloc_addr after each reservation. - Print error message on framebuffer reservation. - Update SPL doc with spl splash screen specific info. V4: - Split patches into atomic commits. - Remove duplicate check for video blob passed addresses and error out if invalid address/size received from blob. - Improve SPL documentation memory reservation scheme and print message for video memory reservation from bloblist. - Add Reviewed-By. Test logs: https://gist.github.com/devarsht/6a748b1d69bd2a4b60695a5e7776db73 Devarsh Thakkar (8): spl: Enforce framebuffer reservation from end of RAM arm: mach-k3: common: Reserve video memory from end of the RAM board: ti: am62x: evm: Remove video_setup from spl_board_init common/board_f: Catch bloblist before starting resevations video: Skip framebuffer reservation if already reserved video: Fill video handoff in video post probe doc: spl: Add info for missing Kconfigs doc: spl: Add info regarding memory reservation arch/arm/mach-k3/common.c| 17 ++- board/ti/am62x/evm.c | 18 common/board_f.c | 41 +++- common/spl/spl.c | 19 + doc/develop/spl.rst | 37 drivers/video/video-uclass.c | 39 +++--- include/spl.h| 10 + 7 files changed, 141 insertions(+), 40 deletions(-) -- 2.34.1
[PATCH v4 2/8] arm: mach-k3: common: Reserve video memory from end of the RAM
Setup video memory before page table reservation using
"spl_reserve_video_from_ram_top" which ensures framebuffer memory gets
reserved from the end of RAM.
This is done to enable the next stage to directly skip the
pre-reserved area from previous stage right from the end of RAM without
having to make any gaps/holes to accommodate those regions which was the
case before as previous stage reserved region not from the end of RAM.
Use gd->ram_top instead of local ram_top and update gd->reloc_addr after
each reservation to ensure further regions are reserved properly.
Signed-off-by: Devarsh Thakkar
---
V2:
- Make a generic function "spl_reserve_video" under
common/spl which can be re-used by other platforms too
for reserving video memory from spl.
V3:
- Change spl_reserve_video to spl_reserve_video_from_ram_top
which enforce framebuffer reservation from end of RAM
- Use gd->ram_top instead of local ram_top and update
gd->reloc_addr after each reservation
- Print error message on framebuffer reservation
V4:
- Split this into a separate patch
---
arch/arm/mach-k3/common.c | 17 -
1 file changed, 12 insertions(+), 5 deletions(-)
diff --git a/arch/arm/mach-k3/common.c b/arch/arm/mach-k3/common.c
index fd400e7e3d..42ceeb5296 100644
--- a/arch/arm/mach-k3/common.c
+++ b/arch/arm/mach-k3/common.c
@@ -524,19 +524,26 @@ void remove_fwl_configs(struct fwl_data *fwl_data, size_t
fwl_data_size)
void spl_enable_cache(void)
{
#if !(defined(CONFIG_SYS_ICACHE_OFF) && defined(CONFIG_SYS_DCACHE_OFF))
- phys_addr_t ram_top = CFG_SYS_SDRAM_BASE;
+ gd->ram_top = CFG_SYS_SDRAM_BASE;
+ int ret = 0;
dram_init();
/* reserve TLB table */
gd->arch.tlb_size = PGTABLE_SIZE;
- ram_top += get_effective_memsize();
+ gd->ram_top += get_effective_memsize();
/* keep ram_top in the 32-bit address space */
- if (ram_top >= 0x1)
- ram_top = (phys_addr_t) 0x1;
+ if (gd->ram_top >= 0x1)
+ gd->ram_top = (phys_addr_t)0x1;
- gd->arch.tlb_addr = ram_top - gd->arch.tlb_size;
+ gd->relocaddr = gd->ram_top;
+
+ ret = spl_reserve_video_from_ram_top();
+ if (ret)
+ panic("Failed to reserve framebuffer memory (%d)\n", ret);
+
+ gd->arch.tlb_addr = gd->relocaddr - gd->arch.tlb_size;
gd->arch.tlb_addr &= ~(0x1 - 1);
debug("TLB table from %08lx to %08lx\n", gd->arch.tlb_addr,
gd->arch.tlb_addr + gd->arch.tlb_size);
--
2.34.1
Re: orangepi zero3
On 24.11.2023 03:11, Andre Przywara wrote:
On Thu, 23 Nov 2023 11:12:25 -0800
Stephen Graf wrote:
Hi Stephen,
Thank you for your reply.
Thanks for coming back. Please keep the list(s) on CC:, as this is also
interesting for others, and more eyes help to find issues faster.
CC:ing Piotr and Mikhail, who were debugging the LPDDR4 DRAM setup
before.
I built u-boot with the proposed changes and it seems to work. It does
however report "DRAM: 2048 MiB" although I have a board with only 1G.
Ah, that's a good report! I actually saw the same issue (reporting 8GB
instead of 4GB), and my hunch is that it's related to some missing
barriers or delays, as seen on other boards.
Can you try to add a "dsb();" to the beginning of
arch/arm/mach-sunxi/dram_helpers.c:mctl_mem_matches(), before the first
writel()?
I am still not convinced this is the right place to put the barrier,
but it would confirm that this is the issue.
Also I didn't see this effect consistently, so did this happen for you
every time?
I tried using an additional barrier as you described:
diff --git a/arch/arm/mach-sunxi/dram_helpers.c
b/arch/arm/mach-sunxi/dram_helpers.c
index cdf2750..16938fa 100644
--- a/arch/arm/mach-sunxi/dram_helpers.c
+++ b/arch/arm/mach-sunxi/dram_helpers.c
@@ -34,6 +34,7 @@ bool mctl_mem_matches(u32 offset)
{
/* Try to write different values to RAM at two addresses */
writel(0, CFG_SYS_SDRAM_BASE);
+ dsb();
writel(0xaa55aa55, (ulong)CFG_SYS_SDRAM_BASE + offset);
dsb();
/* Check if the same value is actually observed when reading back */
After this I did not notice any problems with incorrect configuration.
As I understand it, the problem occurs most often during a hot plug.
Another thing you could try is to increase the voltage to 1150mV, this
is what Piotr needed for reliable operation.
When I built u-boot with the config that I used it reported 1G
correctly. The Zunlong distros do have different images for various RAM
configurations.
Yeah, I saw this, and I hope we can avoid this. I am not sure if you
are the first one with a 1GB board, so your testing is definitely
helpful.
I do not know enough about the details to determine which differences in
the two configs result in the change.
I am more than willing to test and report if someone can direct me a bit.
sysadmin@ubuntu:~/defconfgs$ diff sg.txt andre.txt
(please use "diff -u", that's easier to read and people are more used
to its output style)
9d8
< CONFIG_DRAM_SUN50I_H616_TPR0=0x0
11,13c10,12
< CONFIG_DRAM_SUN50I_H616_TPR10=0x402f0663
< CONFIG_DRAM_SUN50I_H616_TPR11=0x24242323
< CONFIG_DRAM_SUN50I_H616_TPR12=0x0e0e0e0e
---
> CONFIG_DRAM_SUN50I_H616_TPR10=0x402f6663
> CONFIG_DRAM_SUN50I_H616_TPR11=0x24242624
> CONFIG_DRAM_SUN50I_H616_TPR12=0x0f0f100f
I don't think those minor timing differences matter much, but you can
try to experiment with both set of values.
16d14
< CONFIG_DRAM_CLK=792
Not specifying DRAM_CLK means it uses the default 720 MHz. In the past
lowering the DRAM frequency was an easy way to stabilise the DRAM
setup, even though this might somewhat paper over other issues.
25c23
< CONFIG_SPI_FLASH_MACRONIX=y
---
> CONFIG_SPI_FLASH_ZBIT=y
Please double check, but I think all new OrangePi boards now use a zBIT
flash chip? Should have a small "Z" like logo on that 8 pin chip with
the large pins on top.
27a26
> CONFIG_AXP313_POWER=y
32,34c31
< CONFIG_AXP313_POWER=y
< CONFIG_AXP_DCDC3_VOLT=1100
1100mV is the default, so putting exactly this value in doesn't change
anything.
< CONFIG_CMD_BOOTZ=y
Why do you need bootz? I don't think this doing anything useful in
mainline U-Boot. Don't know if OrangePi was just confused and had an
actual use case for this.
---
>
A second issue that I discovered with both builds is that the Ethernet
does not come up on a 1Gb switch, but works on a 100Mb switch.
There is a pending patch for mainline Linux, can you try to apply those
DT changes to U-Boot's DT copy and see if that helps?
https://lore.kernel.org/linux-sunxi/2303336.ElGaqSPkdT@jernej-laptop/T/#m77ee30923cb0351f2d701a463a940dc7c00fa8b7
Cheers,
Andre
Output from the patch defconfig (1Gb LAN):
U-Boot SPL 2024.01-rc3-9-g9e53e45292-dirty (Nov 23 2023 - 18:08:24
+)
DRAM: 2048 MiB
Trying to boot from MMC1
NOTICE: BL31: v2.10.0 (debug):v2.10.0
NOTICE: BL31: Built : 18:07:18, Nov 23 2023
NOTICE: BL31: Detected Allwinner H616 SoC (1823)
NOTICE: BL31: Found U-Boot DTB at 0x4a0b2750, model: OrangePi Zero3
INFO: ARM GICv2 driver initialized
INFO: Configuring SPC Controller
INFO: PMIC: Probing AXP305 on RSB
ERROR: RSB: set run-time address: 0x10003
INFO: Could not init RSB: -65539
INFO: BL31: Platform setup done
INFO: BL31: Initializing runtime services
INFO: BL31: cortex_a53: CPU workaround for erratum 855873 was applied
INFO: BL31: cortex_a53: CPU workaround for erratum 1530924 was applied
INFO: PSCI: Suspend is unavailable
INFO: BL31: Preparing
Re: [PATCH v2 5/6] video: Fill video handoff in video post probe
Hi Simon,
Thanks for the review.
On 13/11/23 01:31, Simon Glass wrote:
> Hi Devarsh,
>
> On Fri, 10 Nov 2023 at 08:29, Devarsh Thakkar wrote:
>>
>> Fill video handoff fields in video_post_probe
>> as at this point we have full framebuffer-related
>> information.
>>
>> Also fill all the fields available in video hand-off
>> struct as those were missing earlier and U-boot
>
> U-Boot
>
>> framework expects them to be filled for some of the
>> functionalities.
>
> Can you wrap your commit messages to closer to 72 chars?
>
>>
>> Reported-by: Simon Glass
>> Signed-off-by: Devarsh Thakkar
>> ---
>> V2:
>> - No change
>>
>> V3:
>> - Fix commit message per review comment
>> - Add a note explaining assumption of single framebuffer
>> ---
>> drivers/video/video-uclass.c | 29 +++--
>> 1 file changed, 19 insertions(+), 10 deletions(-)
>>
>> diff --git a/drivers/video/video-uclass.c b/drivers/video/video-uclass.c
>> index f619b5ae56..edc3376b46 100644
>> --- a/drivers/video/video-uclass.c
>> +++ b/drivers/video/video-uclass.c
>> @@ -154,16 +154,6 @@ int video_reserve(ulong *addrp)
>> debug("Video frame buffers from %lx to %lx\n", gd->video_bottom,
>> gd->video_top);
>>
>> - if (spl_phase() == PHASE_SPL && CONFIG_IS_ENABLED(VIDEO_HANDOFF)) {
>> - struct video_handoff *ho;
>> -
>> - ho = bloblist_add(BLOBLISTT_U_BOOT_VIDEO, sizeof(*ho), 0);
>> - if (!ho)
>> - return log_msg_ret("blf", -ENOENT);
>> - ho->fb = *addrp;
>> - ho->size = size;
>> - }
>> -
>> return 0;
>> }
>>
>> @@ -559,6 +549,25 @@ static int video_post_probe(struct udevice *dev)
>>
>> priv->fb_size = priv->line_length * priv->ysize;
>>
>> + /*
>> +* Set up video handoff fields for passing video blob to next stage
>> +* NOTE:
>> +* This assumes that reserved video memory only uses a single
>> framebuffer
>> +*/
>> + if (spl_phase() == PHASE_SPL && CONFIG_IS_ENABLED(BLOBLIST)) {
>> + struct video_handoff *ho;
>> +
>> + ho = bloblist_add(BLOBLISTT_U_BOOT_VIDEO, sizeof(*ho), 0);
>> + if (!ho)
>> + return log_msg_ret("blf", -ENOENT);
>> + ho->fb = gd->video_bottom;
>> + ho->size = gd->video_top - gd->video_bottom;
>
> should be plat->base and plat->size
>
plat->size contains the unaligned size actually. While reserving video memory,
the size of allocation is updated [0] as per default alignment (1 MiB) or
alignment requested by driver. So I thought it is better to pass actual
allocated size calculated using gd as the next stage receiving hand-off can
directly skip the region as per passed size. And since I used gd for
calculating size, I thought to stick to using gd for ho->fb too for consistency.
Kindly let me know if any queries.
[0]:
https://source.denx.de/u-boot/u-boot/-/blob/u-boot-2023.07.y/drivers/video/video-uclass.c?ref_type=heads#L88
Regards
Devarsh
>> + ho->xsize = priv->xsize;
>> + ho->ysize = priv->ysize;
>> + ho->line_length = priv->line_length;
>> + ho->bpix = priv->bpix;
>> + }
>> +
>> if (IS_ENABLED(CONFIG_VIDEO_COPY) && plat->copy_base)
>> priv->copy_fb = map_sysmem(plat->copy_base, plat->size);
>>
>> --
>> 2.34.1
>>
>
> Regards,
> Simon
Re: [PATCH] mtd: nand: omap_gpmc: Fix NAND in SPL for AM335x
Hi Roger
On Sat, Nov 25, 2023 at 12:16 PM Roger Quadros wrote:
>
> AM335x uses a special driver "am335x_spl_bch.c" as SPL
> NAND loader. This driver expects 1 sector at a time ECC
> and doesn't work well with multi-sector ECC that was implemented in
> commit 04fcd2587321 ("mtd: rawnand: omap_gpmc: Fix BCH6/16 HW based
> correction")
>
> Switch back to 1 sector at a time read/ECC.
>
> Fixes: 04fcd2587321 ("mtd: rawnand: omap_gpmc: Fix BCH6/16 HW based
> correction")
> Signed-off-by: Roger Quadros
> ---
> drivers/mtd/nand/raw/omap_gpmc.c | 95 ++--
> 1 file changed, 29 insertions(+), 66 deletions(-)
>
> diff --git a/drivers/mtd/nand/raw/omap_gpmc.c
> b/drivers/mtd/nand/raw/omap_gpmc.c
> index 1a5ed0de31..2d2d2c2b6d 100644
> --- a/drivers/mtd/nand/raw/omap_gpmc.c
> +++ b/drivers/mtd/nand/raw/omap_gpmc.c
> @@ -293,7 +293,7 @@ static void __maybe_unused omap_enable_hwecc_bch(struct
> mtd_info *mtd,
> break;
> case OMAP_ECC_BCH8_CODE_HW:
> bch_type = 1;
> - nsectors = chip->ecc.steps;
> + nsectors = 1;
> if (mode == NAND_ECC_READ) {
> wr_mode = BCH_WRAPMODE_1;
> ecc_size0 = BCH8R_ECC_SIZE0;
> @@ -306,7 +306,7 @@ static void __maybe_unused omap_enable_hwecc_bch(struct
> mtd_info *mtd,
> break;
> case OMAP_ECC_BCH16_CODE_HW:
> bch_type = 0x2;
> - nsectors = chip->ecc.steps;
> + nsectors = 1;
> if (mode == NAND_ECC_READ) {
> wr_mode = 0x01;
> ecc_size0 = 52; /* ECC bits in nibbles per sector */
> @@ -345,17 +345,16 @@ static void __maybe_unused omap_enable_hwecc_bch(struct
> mtd_info *mtd,
> }
>
> /**
> - * _omap_calculate_ecc_bch - Generate BCH ECC bytes for one sector
> + * omap_calculate_ecc_bch - Generate BCH ECC bytes for one sector
> * @mtd:MTD device structure
> * @dat:The pointer to data on which ecc is computed
> * @ecc_code: The ecc_code buffer
> - * @sector: The sector number (for a multi sector page)
> *
> * Support calculating of BCH4/8/16 ECC vectors for one sector
> * within a page. Sector number is in @sector.
> */
> -static int _omap_calculate_ecc_bch(struct mtd_info *mtd, const u8 *dat,
> - u8 *ecc_code, int sector)
> +static int omap_calculate_ecc_bch(struct mtd_info *mtd, const u8 *dat,
> + u8 *ecc_code)
> {
> struct nand_chip *chip = mtd_to_nand(mtd);
> struct omap_nand_info *info = nand_get_controller_data(chip);
> @@ -368,7 +367,7 @@ static int _omap_calculate_ecc_bch(struct mtd_info *mtd,
> const u8 *dat,
> case OMAP_ECC_BCH8_CODE_HW_DETECTION_SW:
> #endif
> case OMAP_ECC_BCH8_CODE_HW:
> - ptr = _cfg->bch_result_0_3[sector].bch_result_x[3];
> + ptr = _cfg->bch_result_0_3[0].bch_result_x[3];
> val = readl(ptr);
> ecc_code[i++] = (val >> 0) & 0xFF;
> ptr--;
> @@ -383,21 +382,21 @@ static int _omap_calculate_ecc_bch(struct mtd_info
> *mtd, const u8 *dat,
>
> break;
> case OMAP_ECC_BCH16_CODE_HW:
> - val =
> readl(_cfg->bch_result_4_6[sector].bch_result_x[2]);
> + val = readl(_cfg->bch_result_4_6[0].bch_result_x[2]);
> ecc_code[i++] = (val >> 8) & 0xFF;
> ecc_code[i++] = (val >> 0) & 0xFF;
> - val =
> readl(_cfg->bch_result_4_6[sector].bch_result_x[1]);
> + val = readl(_cfg->bch_result_4_6[0].bch_result_x[1]);
> ecc_code[i++] = (val >> 24) & 0xFF;
> ecc_code[i++] = (val >> 16) & 0xFF;
> ecc_code[i++] = (val >> 8) & 0xFF;
> ecc_code[i++] = (val >> 0) & 0xFF;
> - val =
> readl(_cfg->bch_result_4_6[sector].bch_result_x[0]);
> + val = readl(_cfg->bch_result_4_6[0].bch_result_x[0]);
> ecc_code[i++] = (val >> 24) & 0xFF;
> ecc_code[i++] = (val >> 16) & 0xFF;
> ecc_code[i++] = (val >> 8) & 0xFF;
> ecc_code[i++] = (val >> 0) & 0xFF;
> for (j = 3; j >= 0; j--) {
> - val =
> readl(_cfg->bch_result_0_3[sector].bch_result_x[j]
> + val =
> readl(_cfg->bch_result_0_3[0].bch_result_x[j]
> );
> ecc_code[i++] = (val >> 24) & 0xFF;
> ecc_code[i++] = (val >> 16) & 0xFF;
> @@ -431,22 +430,6 @@ static int _omap_calculate_ecc_bch(struct mtd_info *mtd,
> const u8 *dat,
> return 0;
> }
>
> -/**
> - * omap_calculate_ecc_bch - ECC generator for 1 sector
> - * @mtd:MTD device structure
> - * @dat: The pointer to data on which ecc is
[PATCH] mtd: nand: omap_gpmc: Fix NAND in SPL for AM335x
AM335x uses a special driver "am335x_spl_bch.c" as SPL
NAND loader. This driver expects 1 sector at a time ECC
and doesn't work well with multi-sector ECC that was implemented in
commit 04fcd2587321 ("mtd: rawnand: omap_gpmc: Fix BCH6/16 HW based correction")
Switch back to 1 sector at a time read/ECC.
Fixes: 04fcd2587321 ("mtd: rawnand: omap_gpmc: Fix BCH6/16 HW based correction")
Signed-off-by: Roger Quadros
---
drivers/mtd/nand/raw/omap_gpmc.c | 95 ++--
1 file changed, 29 insertions(+), 66 deletions(-)
diff --git a/drivers/mtd/nand/raw/omap_gpmc.c b/drivers/mtd/nand/raw/omap_gpmc.c
index 1a5ed0de31..2d2d2c2b6d 100644
--- a/drivers/mtd/nand/raw/omap_gpmc.c
+++ b/drivers/mtd/nand/raw/omap_gpmc.c
@@ -293,7 +293,7 @@ static void __maybe_unused omap_enable_hwecc_bch(struct
mtd_info *mtd,
break;
case OMAP_ECC_BCH8_CODE_HW:
bch_type = 1;
- nsectors = chip->ecc.steps;
+ nsectors = 1;
if (mode == NAND_ECC_READ) {
wr_mode = BCH_WRAPMODE_1;
ecc_size0 = BCH8R_ECC_SIZE0;
@@ -306,7 +306,7 @@ static void __maybe_unused omap_enable_hwecc_bch(struct
mtd_info *mtd,
break;
case OMAP_ECC_BCH16_CODE_HW:
bch_type = 0x2;
- nsectors = chip->ecc.steps;
+ nsectors = 1;
if (mode == NAND_ECC_READ) {
wr_mode = 0x01;
ecc_size0 = 52; /* ECC bits in nibbles per sector */
@@ -345,17 +345,16 @@ static void __maybe_unused omap_enable_hwecc_bch(struct
mtd_info *mtd,
}
/**
- * _omap_calculate_ecc_bch - Generate BCH ECC bytes for one sector
+ * omap_calculate_ecc_bch - Generate BCH ECC bytes for one sector
* @mtd:MTD device structure
* @dat:The pointer to data on which ecc is computed
* @ecc_code: The ecc_code buffer
- * @sector: The sector number (for a multi sector page)
*
* Support calculating of BCH4/8/16 ECC vectors for one sector
* within a page. Sector number is in @sector.
*/
-static int _omap_calculate_ecc_bch(struct mtd_info *mtd, const u8 *dat,
- u8 *ecc_code, int sector)
+static int omap_calculate_ecc_bch(struct mtd_info *mtd, const u8 *dat,
+ u8 *ecc_code)
{
struct nand_chip *chip = mtd_to_nand(mtd);
struct omap_nand_info *info = nand_get_controller_data(chip);
@@ -368,7 +367,7 @@ static int _omap_calculate_ecc_bch(struct mtd_info *mtd,
const u8 *dat,
case OMAP_ECC_BCH8_CODE_HW_DETECTION_SW:
#endif
case OMAP_ECC_BCH8_CODE_HW:
- ptr = _cfg->bch_result_0_3[sector].bch_result_x[3];
+ ptr = _cfg->bch_result_0_3[0].bch_result_x[3];
val = readl(ptr);
ecc_code[i++] = (val >> 0) & 0xFF;
ptr--;
@@ -383,21 +382,21 @@ static int _omap_calculate_ecc_bch(struct mtd_info *mtd,
const u8 *dat,
break;
case OMAP_ECC_BCH16_CODE_HW:
- val = readl(_cfg->bch_result_4_6[sector].bch_result_x[2]);
+ val = readl(_cfg->bch_result_4_6[0].bch_result_x[2]);
ecc_code[i++] = (val >> 8) & 0xFF;
ecc_code[i++] = (val >> 0) & 0xFF;
- val = readl(_cfg->bch_result_4_6[sector].bch_result_x[1]);
+ val = readl(_cfg->bch_result_4_6[0].bch_result_x[1]);
ecc_code[i++] = (val >> 24) & 0xFF;
ecc_code[i++] = (val >> 16) & 0xFF;
ecc_code[i++] = (val >> 8) & 0xFF;
ecc_code[i++] = (val >> 0) & 0xFF;
- val = readl(_cfg->bch_result_4_6[sector].bch_result_x[0]);
+ val = readl(_cfg->bch_result_4_6[0].bch_result_x[0]);
ecc_code[i++] = (val >> 24) & 0xFF;
ecc_code[i++] = (val >> 16) & 0xFF;
ecc_code[i++] = (val >> 8) & 0xFF;
ecc_code[i++] = (val >> 0) & 0xFF;
for (j = 3; j >= 0; j--) {
- val =
readl(_cfg->bch_result_0_3[sector].bch_result_x[j]
+ val = readl(_cfg->bch_result_0_3[0].bch_result_x[j]
);
ecc_code[i++] = (val >> 24) & 0xFF;
ecc_code[i++] = (val >> 16) & 0xFF;
@@ -431,22 +430,6 @@ static int _omap_calculate_ecc_bch(struct mtd_info *mtd,
const u8 *dat,
return 0;
}
-/**
- * omap_calculate_ecc_bch - ECC generator for 1 sector
- * @mtd:MTD device structure
- * @dat: The pointer to data on which ecc is computed
- * @ecc_code: The ecc_code buffer
- *
- * Support calculating of BCH4/8/16 ECC vectors for one sector. This is used
- * when SW based correction is required as ECC is required for one sector
- * at a time.
- */
-static int __maybe_unused omap_calculate_ecc_bch(struct mtd_info *mtd,
