[PATCH 3/3] sunxi: H616: Add OrangePi Zero 3 board support
Stephen Graf
stephen.graf at gmail.com
Tue Nov 28 07:03:32 CET 2023
I did some digging into the orangepi SDK and it sort of looks like the
zero3 is set up for dram_clk = 792. I use their image as a fallback and
it has been stable (built linux kernel and set up debian rootfs).
from https://github.com/orangepi-xunlong/orangepi-build.git
external/packages/pack-uboot/sun50iw9/bin/dts/orangepizero3-u-boot-legacy.dts:
dram_type = <0x8>;
external/packages/pack-uboot/sun50iw9/bin/sys_config/sys_config_orangepizero3.fex
[dram_para]
dram_clk = 792
dram_type = 8
dram_dx_odt = 0x07070707
dram_dx_dri = 0x0e0e0e0e
dram_ca_dri = 0x0e0e
dram_odt_en = 0xaaaaeeee
dram_para1 = 0x30fa
dram_para2 = 0x0000
dram_mr0 = 0x0
dram_mr1 = 0x34
dram_mr2 = 0x1b
dram_mr3 = 0x33
dram_mr4 = 0x3
dram_mr5 = 0x0
dram_mr6 = 0x0
dram_mr11 = 0x4
dram_mr12 = 0x72
dram_mr13 = 0x0
dram_mr14 = 0x9
dram_mr16 = 0x0
dram_mr17 = 0x0
dram_mr22 = 0x24
dram_tpr0 = 0x0
dram_tpr1 = 0x0
dram_tpr2 = 0x0
dram_tpr3 = 0x0
dram_tpr6 = 0x35808080
dram_tpr10 = 0x402f6663
dram_tpr11 = 0x36363535
dram_tpr12 = 0x10101110
dram_tpr13 = 0x2080C60
[dram_para16]
dram_clk = 792
dram_type = 8
dram_dx_odt = 0x07070707
dram_dx_dri = 0x0e0e0e0e
dram_ca_dri = 0x0e0e
dram_odt_en = 0xaaaaeeee
dram_para1 = 0x30fa
dram_para2 = 0x0000
dram_mr0 = 0x0
dram_mr1 = 0x34
dram_mr2 = 0x1b
dram_mr3 = 0x33
dram_mr4 = 0x3
dram_mr5 = 0x0
dram_mr6 = 0x0
dram_mr11 = 0x4
dram_mr12 = 0x72
dram_mr13 = 0x0
dram_mr14 = 0x9
dram_mr16 = 0x0
dram_mr17 = 0x0
dram_mr22 = 0x24
dram_tpr0 = 0x0
dram_tpr1 = 0x0
dram_tpr2 = 0x0
dram_tpr3 = 0x0
dram_tpr6 = 0x35808080
dram_tpr10 = 0x402f6663
dram_tpr11 = 0x36363535
dram_tpr12 = 0x10101110
dram_tpr13 = 0x2080C60
On 2023-11-27 5:37 p.m., Andre Przywara wrote:
> On Mon, 27 Nov 2023 14:31:19 -0800
> Stephen Graf <stephen.graf at gmail.com> wrote:
>
> Hi,
>
>> Since the last test I rebuilt u-boot without the
>> "CONFIG_DRAM_CLK=792" in the defconfig and got the wrong DRAM size
>> problem (showing 2G instead of 1G). I had to do a power down/up to see this.
>> Are you planning to add this parameter to your patch?
>
> This symptom is pretty surely not directly related to the DRAM
> frequency, it's caused by a missing barrier or delay *somewhere*.
> People report that this is fixed by adding another "dsb();" at the
> beginning of the mctl_mem_matches() function, but I don't have a good
> explanation why exactly there, and would like to avoid submitting
> patches that "just seem to work (TM)".
>
> If I find some time, I will try to setup some automated environment
> where I can run some experiments with different barrier locations.
> I can offer some rationale for putting it at the end of the function(s)
> that call mctl_mem_matches(), so hope that this fixes it.
>
> Cheers,
> Andre
>
>> U-Boot 2024.01-rc3-00012-g1fcf078f54-dirty (Nov 27 2023 - 12:25:33
>> -0800) Allwin ner
>> Technology
>>
>> CPU: Allwinner H616 (SUN50I)
>> Model: OrangePi Zero3
>> DRAM: 2 GiB
>>
>>
>> On 2023-11-27 12:21 p.m., Stephen Graf wrote:
>>> Yes I forgot about the zBIT patch. With this patch also included I built
>>> and retested u-boot loaded from SPI flash. The two warning/error
>>> messages disappeared and the flash worked properly and booted from a USB
>>> device.
>>>
>>> There was one message that I did not understand:
>>> "Loading Environment from SPIFlash... SF: Detected zb25vq128 with page
>>> size 256 Bytes, erase size 4 KiB, total 16 MiB
>>> *** Warning - bad CRC, using default environment"
>>>
>>> I tried to follow the u-boot documentation on writing the SPI flash but
>>> had problems with the write command. When issued it returned
>>> immediately. The erase command took about 5 sec to execute. I researched
>>> use of mtd commands and got a suggestion to use cat instead, which worked.
>>>
>>> "root at orangepizero3:~# mtdinfo
>>> Count of MTD devices: 1
>>> Present MTD devices: mtd0
>>> Sysfs interface supported: yes
>>> root at orangepizero3:~# mtd_debug erase /dev/mtd0 0 0xf0000
>>> Erased 983040 bytes from address 0x00000000 in flash
>>> root at orangepizero3:~# mtd_debug write /dev/mtd0 0 0xf0000
>>> /home/sysadmin/u-boot-sunxi-with-spl.bin
>>> file_to_flash: fread, size 0xf0000, n 0xf0000
>>> fread(): Success
>>> root at orangepizero3:~# cat /home/sysadmin/u-boot-sunxi-with-spl.bin >
>>> /dev/mtd0
>>>
>>>
>>> Console log of boot:
>>>
>>> U-Boot SPL 2024.01-rc3-00012-g1fcf078f54-dirty (Nov 27 2023 - 10:17:46
>>> -0800)
>>> DRAM: 1024 MiB
>>> Trying to boot from sunxi SPI
>>> 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 0x4a0b2798, 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 for EL3 exit to normal world
>>> INFO: Entry point address = 0x4a000000
>>> INFO: SPSR = 0x3c9
>>> INFO: Changed devicetree.
>>>
>>>
>>> U-Boot 2024.01-rc3-00012-g1fcf078f54-dirty (Nov 27 2023 - 10:17:46
>>> -0800) Allwinner Technology
>>>
>>> CPU: Allwinner H616 (SUN50I)
>>> Model: OrangePi Zero3
>>> DRAM: 1 GiB
>>> Core: 57 devices, 25 uclasses, devicetree: separate
>>> WDT: Not starting watchdog at 30090a0
>>> MMC: mmc at 4020000: 0
>>> Loading Environment from SPIFlash... SF: Detected zb25vq128 with page
>>> size 256 Bytes, erase size 4 KiB, total 16 MiB
>>> *** Warning - bad CRC, using default environment
>>>
>>> Loading Environment from FAT... Card did not respond to voltage select!
>>> : -110
>>> ** Bad device specification mmc 0 **
>>> In: serial at 5000000
>>> Out: serial at 5000000
>>> Err: serial at 5000000
>>> Allwinner mUSB OTG (Peripheral)
>>> Net: eth0: ethernet at 5020000using 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 at 5200000: USB EHCI 1.00
>>> Bus usb at 5200400: USB OHCI 1.0
>>> scanning bus usb at 5200000 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 at 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: 3828.0 MB = 3.7 GB (7839744 x 512)
>>> ... is now current device
>>> Scanning usb 0:1...
>>> Found U-Boot script /boot.scr
>>> 1575 bytes read in 1 ms (1.5 MiB/s)
>>> ## Executing script at 4fc00000
>>> Mainline u-boot / new-style environment detected.
>>> This installer medium does not contain a suitable device-tree file for
>>> this system (allwinner/sun50i-h618-orangepi-zero3.dtb). Aborting boot
>>> process.
>>> SCRIPT FAILED: continuing...
>>> Found U-Boot script /boot/boot.scr
>>> 621 bytes read in 2 ms (302.7 KiB/s)
>>> ## Executing script at 4fc00000
>>> 19472 bytes read in 3 ms (6.2 MiB/s)
>>> Working FDT set to 4fa00000
>>> 7088139 bytes read in 326 ms (20.7 MiB/s)
>>> 22491144 bytes read in 1031 ms (20.8 MiB/s)
>>> Moving Image from 0x40080000 to 0x40200000, end=41800000
>>> ## Loading init Ramdisk from Legacy Image at 4ff00000 ...
>>> Image Name: uInitrd
>>> Image Type: AArch64 Linux RAMDisk Image (gzip compressed)
>>> Data Size: 7088075 Bytes = 6.8 MiB
>>> Load Address: 00000000
>>> Entry Point: 00000000
>>> Verifying Checksum ... OK
>>> ## Flattened Device Tree blob at 4fa00000
>>> Booting using the fdt blob at 0x4fa00000
>>> Working FDT set to 4fa00000
>>> Loading Ramdisk to 4993d000, end 49fff7cb ... OK
>>> Loading Device Tree to 00000000498cf000, end 000000004993cfff ... OK
>>> Working FDT set to 498cf000
>>>
>>> Starting kernel ...
>>>
>>> [ 0.000000] Booting Linux on physical CPU 0x0000000000 [0x410fd034]
>>> [ 0.000000] Linux version 6.6.2 (orangepi at orangepizero3) (gcc (Debian
>>> 12.2.0-14) 12.2.0, GNU ld (GNU Binutils for Debian) 2.40) #1 SMP Sat Nov
>>> 25 18:37:47 UTC 2023
>>>
>>>
>>> On 2023-11-26 4:23 a.m., Andre Przywara wrote:
>>>> On Sat, 25 Nov 2023 20:27:05 -0800
>>>> Stephen Graf <stephen.graf at gmail.com> wrote:
>>>>
>>>> Hi Stephen,
>>>>
>>>>> 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".
>>>>
>>>> This is a normal, though admittedly confusing message if no SD card is
>>>> inserted. The code tries to (unconditionally) access the SD card, and
>>>> sees that no card is there, the missing respond to the voltage select
>>>> command is just the first real proof of this.
>>>>
>>>>> 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 at 0:
>>>>> unrecognized JEDEC id bytes: 5e, 40, 18
>>>>> *** Warning - spi_flash_probe_bus_cs() failed, using default
>>>>> environment"
>>>>
>>>> So for a start there is no environment on the SPI flash yet, so it
>>>> wouldn't do anything. But the "unrecognised JEDEC id bytes" message
>>>> doesn't sound right. Can you dig into this? Do you have patch 1/3
>>>> applied, which tells U-Boot about 0x5e meaning zBIT?
>>>>
>>
>
More information about the U-Boot
mailing list