status of the eachlink-h6-mini-WIP branch?

[hexdump0815]

hi @apritzel - what is the latest state of the eachlink-h6-mini-WIP branch of this tree - how far did you get with the libdram case and with your own timinigs taken from the eachlink box? i'm asking, because i'm currently trying to get this working too on a qplus h6 tv box and got to the point that i have uboot running properly with libdram, but looks like booting a linux kernel hangs and without libdram it hangs early on with "DRAM:". the details of my tries can be found here: https://forum.armbian.com/topic/10174-since-tanix-tx6-can-boot-from-the-sd-card/# - any advice, hint or latest status from you would be very helpful.

a lot of thanks in advance and best wishes - hexdump

[apritzel]

Hi @hexdump0815, I didn't find time to come back to the SPL DRAM code yet. Back then I started to disassemble libdram, but it's quite tedious and time consuming. I have the hope that the code isn't far off, probably just a few bits here and there. Problem is finding them :-( The libdram part worked for me up till the Linux prompt, IIRC. Which libdram version did you try? Also did you try to match parameters with what came with your box? Some settings might be different compared to the Eachlink.

[hexdump0815]

hi @apritzel, thanks for the quick response. i used the h6 libdram from the pine64 h64 h6 bsp tarball 1.0 as you mentioned in your commits. i have it working so far that uboot is starting fine and is useable well, but when i try to boot a linux kernel i'm getting to "Starting kernel ..." and thats it. all this is with your eachlink code, so maybe its time to adjust the uboot to my box, write an own dtb for it etc. - how can i match the parameters for my box - is there any documentation about the process around? btw. i used the bl31.bin from the h6 bsp 1.0 tarball - could this be a problem when trying to boot a mainline kernel (i.e. do i have to compile it from the atf sources as well)?

update: is using bootinfo or meminfo from here http://linux-sunxi.org/Sunxi-tools the right way to obtain the memory timing for my box? and one last question: does the fact, that i'm having a stable working uboot already now mean, that the triming as such should be fine (i guess otherwise uboot would crash too)?

a lot of thanks in advance and best wishes - hexdump

[Andre-ARM]

Hi @hexdump0815! I guess the libdram version is probably fine if it brings you into U-Boot. IIRC the other versions I tried failed to do that. You cannot use bl31.bin from the BSP, that is not really compatible. The generic H6 version from mainline is the one to use. Either compile this according to the sunxi64 instructions in U-Boot (easier than compiling U-Boot), or pick a precompiled binary from my pine64 repo. In general you cannot mix and match firmware components between BSP and mainline, it's SPL/libdram + mainline ATF + mainline U-Boot + mainline kernel with a mainline DTB or everything from the BSP side (not sure that was evident).

"Starting kernel ..." is the last message from U-Boot, it typically means the DTB is missing or corrupt. How did you start the kernel? Try booti $kernel_addr_r - $fdtcontroladdr, also make sure to set the kernel command line (setenv bootargs ...). You should add "earlycon" to get some early output, that should work with a stdout-path in DT. Alternatively try earlycon=uart,mmio32,0x50000000 for the explicit version. Also worth a shot is trying to load a more up-to-date .dtb from the kernel version you are using. I guess the Pine H64 one should bring you somewhat into the kernel, at least (just serial, maybe MMC and USB). And btw: the BSP .dtb is of no use whatsoever, it's just for gathering information. For creating a .dts there is no real shortcut, you should try to learn as much as you can about the box. Good sources are the BSP boot log (U-Boot, ATF, kernel) and the BSP sources. The latter might not really match your box, though, or are more confusing. If you can post the BSP boot log (to some gist, for instance), I might be able to give you some hints. Re: bootinfo/meminfo: the versions in sunxi-tools are for much older BSPs, AFAIK they don't even fit the A64 BSPs, not to speak of H6 ones. I have some info somewhere about the parameters, I think the structure is in the last patch about hooking in libdram. One of the first members is the frequency. Timing-wise I have seen U-Boot working fine before, but then the kernel crashing with weird errors, for instance related to page tables. This is when the timing parameters are not quite right. Doesn't match your description though, but something to keep in mind. Don't waste your time with trying to tune the parameters then, just lowering the frequency is a much easier and more promising approach (but also kind of a hack). We can sort out the fine tuning later.

Cheers, Andre.

[hexdump0815]

hi andre, thanks a lot for the long explaination - this is very helpful! i'll give a bl31.bin from your repo then a next try - that sounds promising. good info, that match and mix is not a good idea in this area.

i'm currently using armbian h6 kernels (pine h64 and some orangepi ones) as test kernels for now and my next goal is to get the kernel at least booting - if that should happen, next would be to build a proper dtb for it. at least i have the dtb from my box extracted already and i plan to use this information together with the existing h6 dtbs as a startingpoint.

the uboot commands for booting i used were those ones here: https://forum.armbian.com/topic/10174-since-tanix-tx6-can-boot-from-the-sd-card/?do=findComment&comment=80354 - i later added earlyprintk, but it did not help - so looks like its earlycon here - will try that too.

one thing i noticed is that the legacy boot output of the box has this dram output:

[127]DRAM VERSION IS V2_761
[130]DRAM CLK =672 MHZ
[132]DRAM Type =3 (3:DDR3,4:DDR4,6:LPDDR2,7:LPDDR3)
[137]DRAM zq value: 003b3bfb
[441]IPRD=00790079--PGCR0=00000f7d--PLL=b0003700

and my selfbuilt uboot+spl based on your sources and libdram gives:

DRAM:DRAM VERSION IS V2_2
DRAM CLK =840 MHZ
DRAM Type =3 (3:DDR3,4:DDR4,6:LPDDR2,7:LPDDR3)
DRAM zq value: 3b3bfb
IPRD=5c005b--PGCR0=f7d--PLL=b0004500

can this higher DRAM CLK already be a potential problem? would it easily be possible to lower it to the legacy speed like you suggested (if i understood you right) - maybe in https://github.com/apritzel/u-boot/blob/eachlink-h6-mini-WIP/arch/arm/mach-sunxi/dram_timings/h6_ddr3_1600.c? (i'm not that familiar with dram timings yet)

once more a log of thanks for your help and best wishes - hexdump

p.s.: in case you are interested - there are currently two threads (i'm aware of) ongoing about trying to get ddr3 ram working on the h6: https://forum.armbian.com/topic/10174-since-tanix-tx6-can-boot-from-the-sd-card/# https://forum.libreelec.tv/thread/17636-tanix-tx6/

[Andre-ARM]

Those timing parameters are in "BSP lingo", coded here: https://github.com/apritzel/u-boot/blob/eachlink-h6-mini-WIP/arch/arm/mach-sunxi/dram_libdram.c#L68 You should definitely match as much as you can here. Check the beginning of the BSP boot0 binary, for instance by dumping it from 8KB of eMMC (mmc dev 1; mmc read 0x50000000 0x10; md.l 0x50000000 100). That should have more parameters, this is the same layout as this struct.

[jernejsk]

I dumped Eachlink and Tanix TX6 DT from update image and DRAM parameters slightly differ to those you use. Since currently used parameters work for you, I guess this is not very important.

@Andre-ARM Do you have any idea which part of the code might not match completely? If not, I'll compare timings code to libdram disassembly next. I assume common code should work, otherwise LPDDR3 wouldn't work.

[Andre-ARM]

@jernejsk I don't think it's the timings, as it doesn't detect it at all. In one of the commits I actually made the register dumps match as much as possible, to no avail. My guess is that it's some (extra) register that needs special setup for DDR3 (but not for LPDDR3) and we miss that. I tried to compare LPDD3 vs. DDR3 on the A64, but the DRAM controller is different, so that didn't help. I mostly looked at the Xilink online documentation, but that didn't always make sense, so it's not a 100% clone of that.

[jernejsk]

can someone please read value at address 0x3006100? I don't have any DDR3 box, but I would still like to solve issue with DDR3 driver.

[hexdump0815]

hi @jernejsk - do you mean: => md.l 0x3006100 1 03006100: 00000007 ? this is after booting with a blob libdram mainline u-boot. please keep in mind, that i'm having a qplus 4/32g h6 tv-box, so not tx6 ... i'll have a look at you second patch later tonight

best wishes - hexdump

[jernejsk]

@hexdump0815 yes, that's it, thanks. It seems most boards have this value 7. I'm not sure I've seen any board with any other value.

[hexdump0815]

@Andre-ARM - i have successfully dumped the boot0 dram timing of my box as you described and the result is this:

        .dram_clk = 672,
        .dram_type = 3,
        .dram_zq = 0x3b3bfb,
        .dram_odt_en = 1,
        .dram_para1 = 0x310b,
        .dram_para2 = 0x0c000000,
        .dram_mr0 = 0x1c70,
        .dram_mr1 = 0x40,
        .dram_mr2 = 0x18,
        .dram_mr3 = 0x0,
        .dram_mr4 = 0x0,
        .dram_mr5 = 0x400,
        .dram_mr6 = 0x848,
        .dram_tpr0 = 0x1248a192,
        .dram_tpr1 = 0x11b1b18d,
        .dram_tpr2 = 0x00676051,
        .dram_tpr3 = 0x78787896,
        .dram_tpr4 = 0x0,
        .dram_tpr5 = 0x0,
        .dram_tpr6 = 0x09090900,
        .dram_tpr7 = 0x1e08a1e0,
        .dram_tpr8 = 0x0,
        .dram_tpr9 = 0x0,
        .dram_tpr10 = 0x80000000,
        .dram_tpr11 = 0x0,
        .dram_tpr12 = 0x1212,
        .dram_tpr13 = 0x6003,

using this and your atf bl31.bin from https://github.com/apritzel/pine64/blob/master/binaries/bl31-h6.bin nothing really changed, but when i did just used a simple earlycon on the kernel cmdline i got:

U-Boot SPL 2018.11-g458f795e53-dirty (Jun 11 2019 - 19:06:10 +0200)
DRAM:DRAM VERSION IS V2_2
DRAM CLK =672 MHZ
DRAM Type =3 (3:DDR3,4:DDR4,6:LPDDR2,7:LPDDR3)
DRAM zq value: 3b3bfb
IPRD=730072--PGCR0=f7d--PLL=b0003700
DRAM SIZE =4096 M
DRAM simple test OK.
 2048 MiB
Trying to boot from MMC1

U-Boot 2018.11-g458f795e53-dirty (Jun 11 2019 - 19:06:42 +0200) Allwinner Technology

CPU:   Allwinner H6 (SUN50I)
Model: Eachlink H6 Mini
DRAM:  2 GiB
MMC:   SUNXI SD/MMC: 0, SUNXI SD/MMC: 1
Loading Environment from FAT... Unable to use mmc 1:1... In:    serial@5000000
Out:   serial@5000000
Err:   serial@5000000
Net:   No ethernet found.
starting USB...
No controllers found
Hit any key to stop autoboot:  0 
switch to partitions #0, OK
mmc0 is current device
Scanning mmc 0:1...
Found /boot/extlinux/extlinux.conf
Retrieving file: /boot/extlinux/extlinux.conf
1494 bytes read in 43 ms (33.2 KiB/s)
h6 boot options
1:      test
2:      test
3:      test
4:      test
Enter choice: 2
2:      test
Retrieving file: /boot/extlinux/../initrd.img-5.1.5-sunxi64
8796321 bytes read in 962 ms (8.7 MiB/s)
Retrieving file: /boot/extlinux/../vmlinuz-5.1.5-sunxi64
14563336 bytes read in 1547 ms (9 MiB/s)
append: console=ttyS0,115200 earlycon root=UUID=dd30c6eb-e016-4a9f-abf3-fae5e0cff27c rootwait ro fsck.fix=yes f1
Retrieving file: /boot/extlinux/../dtb-5.1.5-sunxi64/allwinner/sun50i-h6-orangepi-one-plus.dtb
26322 bytes read in 105 ms (244.1 KiB/s)
## Flattened Device Tree blob at 4fa00000
   Booting using the fdt blob at 0x4fa00000
   Loading Ramdisk to 4979c000, end 49fff8a1 ... OK
   Loading Device Tree to 0000000049792000, end 000000004979b6d1 ... OK

Starting kernel ...

[    0.000000] Internal error: Oops - BUG: 0 [#1] SMP
[    0.000000] Modules linked in:
[    0.000000] Process swapper (pid: 0, stack limit = 0x(____ptrval____))
[    0.000000] CPU: 0 PID: 0 Comm: swapper Not tainted 5.1.5-sunxi64 #5.88.190529
[    0.000000] Hardware name: OrangePi One Plus (DT)
[    0.000000] pstate: 00000085 (nzcv daIf -PAN -UAO)
[    0.000000] pc : do_undefinstr+0x2a4/0x2c0                                             
[    0.000000] lr : do_undefinstr+0x138/0x2c0                                             
[    0.000000] sp : ffff000010db3c90                                                      
[    0.000000] x29: ffff000010db3c90 x28: ffff000010dc4bc0                                
[    0.000000] x27: 0000000000000040 x26: ffff000010c0d0e8                                
[    0.000000] x25: ffff000010c29cb8 x24: 0000000000000000                                
[    0.000000] x23: 0000000080000085 x22: ffff000010093900                                
[    0.000000] x21: ffff000010db3e30 x20: ffff000010db3cf0                                
[    0.000000] x19: ffff000010dbc000 x18: 0000000000004000                                
[    0.000000] x17: 0000000000000000 x16: 0000000000001400                                
[    0.000000] x15: 00000000fffffff0 x14: ffffffffffffffff                                
[    0.000000] x13: 0000000000000038 x12: 0101010101010101                                
[    0.000000] x11: 0000000000000004 x10: 0101010101010101                                
[    0.000000] x9 : 0000000000000004 x8 : 0000000000000004                                
[    0.000000] x7 : 0000000000000000 x6 : ffff000010db3ce8                                
[    0.000000] x5 : ffff000010e68148 x4 : 0000000000000000                                
[    0.000000] x3 : 0000000000000001 x2 : ffff000010dc66c8                                
[    0.000000] x1 : ffff000010e68148 x0 : 0000000080000085                                
[    0.000000] Call trace:                                                                
[    0.000000]  do_undefinstr+0x2a4/0x2c0
[    0.000000]  el1_undef+0x10/0x84
[    0.000000]  __arm_smccc_smc+0x0/0x2c
[    0.000000]  psci_0_2_init+0x40/0x2c0
[    0.000000]  psci_dt_init+0x64/0x88
[    0.000000]  setup_arch+0x360/0x4f0
[    0.000000]  start_kernel+0x7c/0x448
[    0.000000] Code: 2a154035 17ffffac a9025bb5 f9001bb7 (d4210000) 
[    0.000000] random: get_random_bytes called from print_oops_end_marker+0x48/0x68 with crng_init=0
[    0.000000] ---[ end trace 0000000000000000 ]---
[    0.000000] Kernel panic - not syncing: Attempted to kill the idle task!
[    0.000000] ---[ end Kernel panic - not syncing: Attempted to kill the idle task! ]---

at least we can watch it crashing now :) ... any idea what might be the problem? just for completeness, the below is the extlinux entry i'm using for booting:

LABEL test1
      MENU LABEL test
      LINUX ../vmlinuz-5.1.5-sunxi64
      INITRD ../initrd.img-5.1.5-sunxi64
      FDT ../dtb-5.1.5-sunxi64/allwinner/sun50i-h6-orangepi-one-plus.dtb
      APPEND console=ttyS0,115200 earlycon root=UUID=dd30c6eb-e016-4a9f-abf3-fae5e0cff27c rootwait ro fsck.fix=yes fsck.repair=yes net.ifnames=0 ipv6.disable=1

@jernejsk - testing your patch from http://sprunge.us/f0y8YF now - can't be wrong to test it a second time on another box ...

update: i can confirm what ukmark62 found out in the other thread: it simply hangs

U-Boot SPL 2018.11-g7702a7c2b1-dirty (Jun 11 2019 - 19:25:22 +0200)
DRAM:

and i think its a good idea of you thinking about getting a h6 ddr3 box yourself :) ... the qplus (Q+) 4/32 ones are quite cheap (i got mine here in germany and shipped from germany for around 34 euro including shipping) and the serial port is easy to find and solder.

update2: i just tried the libdram case with the bsp h6 bl31.bin instead of the bl31.bin mentioned above and i'm getting the same kernel crash in this case ...

best wishes - hexdump

[Andre-ARM]

@hexdump0815: That smells like ATF not being installed, which is also supported by no output from ATF (between SPL and U-Boot proper). What image do you write to the SD card? Can you check whether the FIT image is created correctly, with bl31.bin being included? You could use dtc u-boot.itb to list what's included. Is your BL31 env variable or bl31.bin file/link correct? Viele Grüße, Andre

[hexdump0815]

ok - looks i did something wrong then: i used cat sunxi-spl.bin-arm32 u-boot.img u-boot.dtb > myuboot.dd which i grabbed from the Makefile. here sunxi-spl.bin-arm32 is from a compilation with eachlink_h6_mini_libdram_spl_defconfig on an arm32 system and u-boot.img + u-boot.dtb are from a compilation with eachlink_h6_mini_defconfig on an arm64 system. libdram and your bl31.bin are both in the root dir of the uboot sources and used in the build (otherwise the build will complain that the bl31.bin is not there). after reading your last comment and the README.sunxi64 i now tried cat sunxi-spl.bin-arm32 u-boot.itb > myuboot.dd with u-boot.itb compiled with eachlink_h6_mini_defconfig on an arm64 system. this results in:

U-Boot SPL 2018.11-g458f795e53-dirty (Jun 11 2019 - 19:06:10 +0200)
DRAM:DRAM VERSION IS V2_2
DRAM CLK =672 MHZ
DRAM Type =3 (3:DDR3,4:DDR4,6:LPDDR2,7:LPDDR3)
DRAM zq value: 3b3bfb
IPRD=740073--PGCR0=f7d--PLL=b0003700
DRAM SIZE =4096 M
DRAM simple test OK.
 2048 MiB
Trying to boot from MMC1
INFO:    Configuring SPC Controller

and there it hangs. the INFO: Configuring SPC Controller seems to come from the bl31.bin now at least :) ... is my assumption to compile the spl part on arm32 and the rest on arm64 correct? i must admit i do not yet fully understand the 32/64bit boot switches in the libdram case. if not: on which system (arm32/64) to build which part and how to put them together in the end?

a lot of thanks once more for your support und viele grüsse zurück :) - hexdump

update: wait - looks like this boot.itb was from my last bsp bl31.bin try as only this contains the string "SPC Controller" - will have to rebuild the boot.itb with your atf bl31.bin again ... update will follow :)

[Andre-ARM]

Ah yes, the blessings of combining 32 and 64-bit parts ;-) Indeed you need to combine a 32-bit SPL (using libdram) with the 64-bit .itb file. Normally we switch to 64-bit first part in the SPL, but we can't here because of libdram being 32-bit only. So we keep running in AArch32, then doing the switch at the end of SPL, when handing over to ATF. ATF runs in AArch64 EL3, and drops back to AArch64 EL2 when jumping to U-Boot proper. Easy, eh?

[hexdump0815]

success :)

with the proper bl31.bin it now boots - the bl31 output:

NOTICE:  BL31: Built : 00:08:51, Dec  6 2018
NOTICE:  BL31: Detected Allwinner H6 SoC (1728)
NOTICE:  BL31: Found U-Boot DTB at 0xc06dc20, model: Eachlink H6 Mini
INFO:    ARM GICv2 driver initialized
NOTICE:  PMIC: Probing AXP805
ERROR:   Start clear bit timeout
ERROR:   PMIC: Cannot put AXP805 to master mode.
INFO:    BL31: Platform setup done
INFO:    BL31: Initializing runtime services
INFO:    BL31: cortex_a53: CPU workaround for 855873 was applied
INFO:    BL31: Preparing for EL3 exit to normal world
INFO:    Entry point address = 0x4a000000
INFO:    SPSR = 0x3c9

and dmesg (using a pine h64 dtb):

[    0.000000] Booting Linux on physical CPU 0x0000000000 [0x410fd034]
[    0.000000] Linux version 5.1.5-sunxi64 (root@nightly) (gcc version 7.4.1 20181213 [linaro-7.4-2019.02 revis9
[    0.000000] Machine model: Pine H64
[    0.000000] cma: Reserved 128 MiB at 0x00000000b8000000
[    0.000000] NUMA: No NUMA configuration found
[    0.000000] NUMA: Faking a node at [mem 0x0000000040000000-0x00000000bfffffff]
[    0.000000] NUMA: NODE_DATA [mem 0xb7bd9840-0xb7bdafff]
[    0.000000] Zone ranges:
[    0.000000]   DMA32    [mem 0x0000000040000000-0x00000000bfffffff]
[    0.000000]   Normal   empty
[    0.000000] Movable zone start for each node
[    0.000000] Early memory node ranges
[    0.000000]   node   0: [mem 0x0000000040000000-0x00000000bfffffff]
[    0.000000] Initmem setup node 0 [mem 0x0000000040000000-0x00000000bfffffff]
[    0.000000] On node 0 totalpages: 524288
[    0.000000]   DMA32 zone: 8192 pages used for memmap
[    0.000000]   DMA32 zone: 0 pages reserved
[    0.000000]   DMA32 zone: 524288 pages, LIFO batch:63
[    0.000000] psci: probing for conduit method from DT.
[    0.000000] psci: PSCIv1.1 detected in firmware.
[    0.000000] psci: Using standard PSCI v0.2 function IDs
[    0.000000] psci: MIGRATE_INFO_TYPE not supported.
[    0.000000] psci: SMC Calling Convention v1.1
[    0.000000] random: get_random_bytes called from start_kernel+0xa4/0x448 with crng_init=0
[    0.000000] percpu: Embedded 22 pages/cpu s52952 r8192 d28968 u90112
[    0.000000] pcpu-alloc: s52952 r8192 d28968 u90112 alloc=22*4096
[    0.000000] pcpu-alloc: [0] 0 [0] 1 [0] 2 [0] 3 
[    0.000000] Detected VIPT I-cache on CPU0
[    0.000000] CPU features: detected: ARM erratum 845719
[    0.000000] Speculative Store Bypass Disable mitigation not required
[    0.000000] Built 1 zonelists, mobility grouping on.  Total pages: 516096
[    0.000000] Policy zone: DMA32
[    0.000000] Kernel command line: console=ttyS0,115200 root=UUID=dd30c6eb-e016-4a9f-abf3-fae5e0cff27c rootwai1
[    0.000000] printk: log_buf_len individual max cpu contribution: 4096 bytes
[    0.000000] printk: log_buf_len total cpu_extra contributions: 12288 bytes
[    0.000000] printk: log_buf_len min size: 16384 bytes
[    0.000000] printk: log_buf_len: 32768 bytes
[    0.000000] printk: early log buf free: 13944(85%)
[    0.000000] Memory: 1905352K/2097152K available (10238K kernel code, 718K rwdata, 2508K rodata, 704K init, 2)
[    0.000000] SLUB: HWalign=64, Order=0-3, MinObjects=0, CPUs=4, Nodes=1
[    0.000000] rcu: Hierarchical RCU implementation.
[    0.000000] rcu:     RCU restricting CPUs from NR_CPUS=8 to nr_cpu_ids=4.
[    0.000000] rcu: RCU calculated value of scheduler-enlistment delay is 25 jiffies.
[    0.000000] rcu: Adjusting geometry for rcu_fanout_leaf=16, nr_cpu_ids=4
[    0.000000] NR_IRQS: 64, nr_irqs: 64, preallocated irqs: 0
[    0.000000] GIC: Using split EOI/Deactivate mode
[    0.000000] arch_timer: cp15 timer(s) running at 24.00MHz (phys).
[    0.000000] clocksource: arch_sys_counter: mask: 0xffffffffffffff max_cycles: 0x588fe9dc0, max_idle_ns: 4407s
[    0.000004] sched_clock: 56 bits at 24MHz, resolution 41ns, wraps every 4398046511097ns
[    0.000219] Console: colour dummy device 80x25
[    0.000283] Calibrating delay loop (skipped), value calculated using timer frequency.. 48.00 BogoMIPS (lpj=9)
[    0.000291] pid_max: default: 32768 minimum: 301
[    0.000371] LSM: Security Framework initializing
[    0.001190] Dentry cache hash table entries: 262144 (order: 9, 2097152 bytes)
[    0.001600] Inode-cache hash table entries: 131072 (order: 8, 1048576 bytes)
[    0.001637] Mount-cache hash table entries: 4096 (order: 3, 32768 bytes)
[    0.001654] Mountpoint-cache hash table entries: 4096 (order: 3, 32768 bytes)
[    0.002068] *** VALIDATE proc ***
[    0.002278] *** VALIDATE cgroup1 ***
[    0.002284] *** VALIDATE cgroup2 ***
[    0.002900] ASID allocator initialised with 32768 entries
[    0.002967] rcu: Hierarchical SRCU implementation.
[    0.003460] smp: Bringing up secondary CPUs ...
[    0.004140] Detected VIPT I-cache on CPU1
[    0.004189] CPU1: Booted secondary processor 0x0000000001 [0x410fd034]
[    0.004810] Detected VIPT I-cache on CPU2
[    0.004837] CPU2: Booted secondary processor 0x0000000002 [0x410fd034]
[    0.005409] Detected VIPT I-cache on CPU3
[    0.005436] CPU3: Booted secondary processor 0x0000000003 [0x410fd034]
[    0.005501] smp: Brought up 1 node, 4 CPUs
[    0.005505] SMP: Total of 4 processors activated.
[    0.005509] CPU features: detected: 32-bit EL0 Support
[    0.005514] CPU features: detected: CRC32 instructions
[    0.005757] CPU: All CPU(s) started at EL2
[    0.005772] alternatives: patching kernel code
[    0.007207] devtmpfs: initialized
[    0.011756] clocksource: jiffies: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 7645041785100000 ns
[    0.011786] futex hash table entries: 1024 (order: 4, 65536 bytes)
[    0.015918] xor: measuring software checksum speed
[    0.052078]    8regs     :  1750.000 MB/sec
[    0.092114]    32regs    :  2151.000 MB/sec
[    0.132164]    arm64_neon:  1904.000 MB/sec
[    0.132167] xor: using function: 32regs (2151.000 MB/sec)
[    0.132214] pinctrl core: initialized pinctrl subsystem
[    0.132967] NET: Registered protocol family 16
[    0.133377] audit: initializing netlink subsys (disabled)
[    0.133521] audit: type=2000 audit(0.132:1): state=initialized audit_enabled=0 res=1
[    0.133977] cpuidle: using governor menu
[    0.134159] vdso: 2 pages (1 code @ (____ptrval____), 1 data @ (____ptrval____))
[    0.134166] hw-breakpoint: found 6 breakpoint and 4 watchpoint registers.
[    0.135260] DMA: preallocated 256 KiB pool for atomic allocations
[    0.135383] Serial: AMBA PL011 UART driver
[    0.145326] HugeTLB registered 1.00 GiB page size, pre-allocated 0 pages
[    0.145334] HugeTLB registered 32.0 MiB page size, pre-allocated 0 pages
[    0.145339] HugeTLB registered 2.00 MiB page size, pre-allocated 0 pages
[    0.145343] HugeTLB registered 64.0 KiB page size, pre-allocated 0 pages
[    0.145787] cryptd: max_cpu_qlen set to 1000
[    0.212344] raid6: neonx8   gen()  1257 MB/s
[    0.280397] raid6: neonx8   xor()  1170 MB/s
[    0.348483] raid6: neonx4   gen()  1155 MB/s
[    0.416577] raid6: neonx4   xor()  1104 MB/s
[    0.484709] raid6: neonx2   gen()   887 MB/s
[    0.552775] raid6: neonx2   xor()   925 MB/s
[    0.620855] raid6: neonx1   gen()   554 MB/s
[    0.688950] raid6: neonx1   xor()   654 MB/s
[    0.757053] raid6: int64x8  gen()   748 MB/s
[    0.825145] raid6: int64x8  xor()   572 MB/s
[    0.893223] raid6: int64x4  gen()   792 MB/s
[    0.961320] raid6: int64x4  xor()   584 MB/s
[    1.029488] raid6: int64x2  gen()   517 MB/s
[    1.097496] raid6: int64x2  xor()   460 MB/s
[    1.165586] raid6: int64x1  gen()   337 MB/s
[    1.233721] raid6: int64x1  xor()   338 MB/s
[    1.233724] raid6: using algorithm neonx8 gen() 1257 MB/s
[    1.233726] raid6: .... xor() 1170 MB/s, rmw enabled
[    1.233730] raid6: using neon recovery algorithm
[    1.234694] SCSI subsystem initialized
[    1.234850] usbcore: registered new interface driver usbfs
[    1.234881] usbcore: registered new interface driver hub
[    1.234931] usbcore: registered new device driver usb
[    1.235162] pps_core: LinuxPPS API ver. 1 registered
[    1.235165] pps_core: Software ver. 5.3.6 - Copyright 2005-2007 Rodolfo Giometti <giometti@linux.it>
[    1.235176] PTP clock support registered
[    1.236102] clocksource: Switched to clocksource arch_sys_counter
[    1.236240] VFS: Disk quotas dquot_6.6.0
[    1.236295] VFS: Dquot-cache hash table entries: 512 (order 0, 4096 bytes)
[    1.236354] *** VALIDATE hugetlbfs ***
[    1.241884] NET: Registered protocol family 2
[    1.242381] tcp_listen_portaddr_hash hash table entries: 1024 (order: 2, 16384 bytes)
[    1.242440] TCP established hash table entries: 16384 (order: 5, 131072 bytes)
[    1.242620] TCP bind hash table entries: 16384 (order: 6, 262144 bytes)
[    1.242874] TCP: Hash tables configured (established 16384 bind 16384)
[    1.242980] UDP hash table entries: 1024 (order: 3, 32768 bytes)
[    1.243036] UDP-Lite hash table entries: 1024 (order: 3, 32768 bytes)
[    1.243210] NET: Registered protocol family 1
[    1.243584] RPC: Registered named UNIX socket transport module.
[    1.243587] RPC: Registered udp transport module.
[    1.243589] RPC: Registered tcp transport module.
[    1.243591] RPC: Registered tcp NFSv4.1 backchannel transport module.
[    1.243795] Unpacking initramfs...
[    1.687104] Freeing initrd memory: 8588K
[    1.841480] Initialise system trusted keyrings
[    1.841628] workingset: timestamp_bits=44 max_order=19 bucket_order=0
[    1.846549] zbud: loaded
[    1.847918] squashfs: version 4.0 (2009/01/31) Phillip Lougher
[    1.848575] NFS: Registering the id_resolver key type
[    1.848595] Key type id_resolver registered
[    1.848597] Key type id_legacy registered
[    1.848607] nfs4filelayout_init: NFSv4 File Layout Driver Registering...
[    1.848610] Installing knfsd (copyright (C) 1996 okir@monad.swb.de).
[    1.849406] 9p: Installing v9fs 9p2000 file system support
[    1.998776] Key type asymmetric registered
[    1.998784] Asymmetric key parser 'x509' registered
[    1.998849] Block layer SCSI generic (bsg) driver version 0.4 loaded (major 248)
[    1.999001] io scheduler mq-deadline registered
[    1.999006] io scheduler kyber registered
[    1.999156] io scheduler bfq registered
[    1.999423] sun50i-de2-bus 1000000.display-engine: Error couldn't map SRAM to device
[    1.999995] sun4i-usb-phy 5100400.phy: Couldn't get regulator usb0_vbus... Deferring probe
[    2.000333] sun50i-usb3-phy 5210000.phy: failed to get phy clock
[    2.003823] sun50i-h6-r-pinctrl 7022000.pinctrl: initialized sunXi PIO driver
[    2.010887] Serial: 8250/16550 driver, 4 ports, IRQ sharing disabled
[    2.013876] cacheinfo: Unable to detect cache hierarchy for CPU 0
[    2.017743] loop: module loaded
[    2.018598] libphy: Fixed MDIO Bus: probed
[    2.020152] ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver
[    2.020157] ehci-platform: EHCI generic platform driver
[    2.020313] ehci-platform 5101000.usb: EHCI Host Controller
[    2.020332] ehci-platform 5101000.usb: new USB bus registered, assigned bus number 1
[    2.020652] ehci-platform 5101000.usb: irq 18, io mem 0x05101000
[    2.036112] ehci-platform 5101000.usb: USB 2.0 started, EHCI 1.00
[    2.036305] usb usb1: New USB device found, idVendor=1d6b, idProduct=0002, bcdDevice= 5.01
[    2.036312] usb usb1: New USB device strings: Mfr=3, Product=2, SerialNumber=1
[    2.036317] usb usb1: Product: EHCI Host Controller
[    2.036322] usb usb1: Manufacturer: Linux 5.1.5-sunxi64 ehci_hcd
[    2.036327] usb usb1: SerialNumber: 5101000.usb
[    2.036768] hub 1-0:1.0: USB hub found
[    2.036804] hub 1-0:1.0: 1 port detected
[    2.037300] ohci_hcd: USB 1.1 'Open' Host Controller (OHCI) Driver
[    2.037318] ohci-platform: OHCI generic platform driver
[    2.037448] ohci-platform 5101400.usb: Generic Platform OHCI controller
[    2.037465] ohci-platform 5101400.usb: new USB bus registered, assigned bus number 2
[    2.037709] ohci-platform 5101400.usb: irq 19, io mem 0x05101400
[    2.100370] usb usb2: New USB device found, idVendor=1d6b, idProduct=0001, bcdDevice= 5.01
[    2.100377] usb usb2: New USB device strings: Mfr=3, Product=2, SerialNumber=1
[    2.100382] usb usb2: Product: Generic Platform OHCI controller
[    2.100387] usb usb2: Manufacturer: Linux 5.1.5-sunxi64 ohci_hcd
[    2.100392] usb usb2: SerialNumber: 5101400.usb
[    2.100784] hub 2-0:1.0: USB hub found
[    2.100818] hub 2-0:1.0: 1 port detected
[    2.101552] usbcore: registered new interface driver usb-storage
[    2.101989] mousedev: PS/2 mouse device common for all mice
[    2.102423] sun6i-rtc 7000000.rtc: registered as rtc0
[    2.102428] sun6i-rtc 7000000.rtc: RTC enabled
[    2.102494] i2c /dev entries driver
[    2.102656] sun50i-h6-r-pinctrl 7022000.pinctrl: 7022000.pinctrl supply vcc-pl not found, using dummy regular
[    2.103173] axp20x-i2c 0-0036: AXP20x variant AXP806 found
[    4.128110] i2c i2c-0: mv64xxx: I2C bus locked, block: 1, time_left: 0
[    6.176109] i2c i2c-0: mv64xxx: I2C bus locked, block: 1, time_left: 0
[    6.176118] axp20x-i2c 0-0036: Failed to set masks in 0x40: -110
[    6.176124] axp20x-i2c 0-0036: failed to add irq chip: -110
[    6.176195] axp20x-i2c: probe of 0-0036 failed with error -110
[    6.176844] sun50i-h6-r-pinctrl 7022000.pinctrl: 7022000.pinctrl supply vcc-pm not found, using dummy regular
[    6.177063] sdhci: Secure Digital Host Controller Interface driver
[    6.177066] sdhci: Copyright(c) Pierre Ossman
[    6.177085] Synopsys Designware Multimedia Card Interface Driver
[    6.177586] sdhci-pltfm: SDHCI platform and OF driver helper
[    6.178152] ledtrig-cpu: registered to indicate activity on CPUs
[    6.178410] hidraw: raw HID events driver (C) Jiri Kosina
[    6.178488] usbcore: registered new interface driver usbhid
[    6.178490] usbhid: USB HID core driver
[    6.179163] IPv6: Loaded, but administratively disabled, reboot required to enable
[    6.179170] NET: Registered protocol family 17
[    6.179379] 8021q: 802.1Q VLAN Support v1.8
[    6.179506] 9pnet: Installing 9P2000 support
[    6.179553] Key type dns_resolver registered
[    6.180144] registered taskstats version 1
[    6.180147] Loading compiled-in X.509 certificates
[    6.180240] zswap: loaded using pool lzo/zbud
[    6.181165] Btrfs loaded, crc32c=crc32c-generic
[    6.189692] Key type encrypted registered
[    6.202645] sun50i-h6-pinctrl 300b000.pinctrl: initialized sunXi PIO driver
[    6.202872] sun50i-h6-pinctrl 300b000.pinctrl: 300b000.pinctrl supply vcc-ph not found, using dummy regulator
[    6.203277] printk: console [ttyS0] disabled
[    6.224118] 5000000.serial: ttyS0 at MMIO 0x5000000 (irq = 15, base_baud = 1500000) is a 16550A
[    6.224165] printk: console [ttyS0] enabled
[    6.243182] sun4i-drm display-engine: bound 1100000.mixer (ops 0xffff000010b23d90)
[    6.243311] sun4i-drm display-engine: bound 6510000.tcon-top (ops 0xffff000010b27f78)
[    6.243522] sun4i-drm display-engine: bound 6515000.lcd-controller (ops 0xffff000010b202d0)
[    6.243574] sun8i-dw-hdmi 6000000.hdmi: 6000000.hdmi supply hvcc not found, using dummy regulator
[    6.243665] platform connector: connector supply ddc not found, using dummy regulator
[    6.243878] sun8i-dw-hdmi 6000000.hdmi: Detected HDMI TX controller v2.12a with HDCP (DWC HDMI 2.0 TX PHY)
[    6.244307] sun8i-dw-hdmi 6000000.hdmi: registered DesignWare HDMI I2C bus driver
[    6.244545] sun4i-drm display-engine: bound 6000000.hdmi (ops 0xffff000010b23148)
[    6.244551] [drm] Supports vblank timestamp caching Rev 2 (21.10.2013).
[    6.244553] [drm] No driver support for vblank timestamp query.
[    6.244824] [drm] Initialized sun4i-drm 1.0.0 20150629 for display-engine on minor 0
[    6.244861] [drm] Cannot find any crtc or sizes
[    6.245314] [drm] Cannot find any crtc or sizes
[    6.352348] xhci-hcd xhci-hcd.2.auto: xHCI Host Controller
[    6.352366] xhci-hcd xhci-hcd.2.auto: new USB bus registered, assigned bus number 3
[    6.352832] xhci-hcd xhci-hcd.2.auto: hcc params 0x0220f064 hci version 0x100 quirks 0x0000000002010010
[    6.352875] xhci-hcd xhci-hcd.2.auto: irq 20, io mem 0x05200000
[    6.353148] usb usb3: New USB device found, idVendor=1d6b, idProduct=0002, bcdDevice= 5.01
[    6.353154] usb usb3: New USB device strings: Mfr=3, Product=2, SerialNumber=1
[    6.353160] usb usb3: Product: xHCI Host Controller
[    6.353165] usb usb3: Manufacturer: Linux 5.1.5-sunxi64 xhci-hcd
[    6.353170] usb usb3: SerialNumber: xhci-hcd.2.auto
[    6.353572] hub 3-0:1.0: USB hub found
[    6.353600] hub 3-0:1.0: 1 port detected
[    6.353840] xhci-hcd xhci-hcd.2.auto: xHCI Host Controller
[    6.353853] xhci-hcd xhci-hcd.2.auto: new USB bus registered, assigned bus number 4
[    6.353866] xhci-hcd xhci-hcd.2.auto: Host supports USB 3.0  SuperSpeed
[    6.353932] usb usb4: We don't know the algorithms for LPM for this host, disabling LPM.
[    6.354046] usb usb4: New USB device found, idVendor=1d6b, idProduct=0003, bcdDevice= 5.01
[    6.354052] usb usb4: New USB device strings: Mfr=3, Product=2, SerialNumber=1
[    6.354057] usb usb4: Product: xHCI Host Controller
[    6.354062] usb usb4: Manufacturer: Linux 5.1.5-sunxi64 xhci-hcd
[    6.354067] usb usb4: SerialNumber: xhci-hcd.2.auto
[    6.354386] hub 4-0:1.0: USB hub found
[    6.354412] hub 4-0:1.0: 1 port detected
[    6.355090] ehci-platform 5311000.usb: EHCI Host Controller
[    6.355106] ehci-platform 5311000.usb: new USB bus registered, assigned bus number 5
[    6.355429] ehci-platform 5311000.usb: irq 21, io mem 0x05311000
[    6.368117] ehci-platform 5311000.usb: USB 2.0 started, EHCI 1.00
[    6.368250] usb usb5: New USB device found, idVendor=1d6b, idProduct=0002, bcdDevice= 5.01
[    6.368257] usb usb5: New USB device strings: Mfr=3, Product=2, SerialNumber=1
[    6.368262] usb usb5: Product: EHCI Host Controller
[    6.368268] usb usb5: Manufacturer: Linux 5.1.5-sunxi64 ehci_hcd
[    6.368272] usb usb5: SerialNumber: 5311000.usb
[    6.368625] hub 5-0:1.0: USB hub found
[    6.368655] hub 5-0:1.0: 1 port detected
[    6.369229] ohci-platform 5311400.usb: Generic Platform OHCI controller
[    6.369245] ohci-platform 5311400.usb: new USB bus registered, assigned bus number 6
[    6.369465] ohci-platform 5311400.usb: irq 22, io mem 0x05311400
[    6.432377] usb usb6: New USB device found, idVendor=1d6b, idProduct=0001, bcdDevice= 5.01
[    6.432384] usb usb6: New USB device strings: Mfr=3, Product=2, SerialNumber=1
[    6.432389] usb usb6: Product: Generic Platform OHCI controller
[    6.432395] usb usb6: Manufacturer: Linux 5.1.5-sunxi64 ohci_hcd
[    6.432399] usb usb6: SerialNumber: 5311400.usb
[    6.432735] hub 6-0:1.0: USB hub found
[    6.432762] hub 6-0:1.0: 1 port detected
[    6.433413] usb_phy_generic usb_phy_generic.3.auto: usb_phy_generic.3.auto supply vcc not found, using dummyr
[    6.433682] musb-hdrc musb-hdrc.4.auto: MUSB HDRC host driver
[    6.433690] musb-hdrc musb-hdrc.4.auto: new USB bus registered, assigned bus number 7
[    6.433852] usb usb7: New USB device found, idVendor=1d6b, idProduct=0002, bcdDevice= 5.01
[    6.433859] usb usb7: New USB device strings: Mfr=3, Product=2, SerialNumber=1
[    6.433865] usb usb7: Product: MUSB HDRC host driver
[    6.433870] usb usb7: Manufacturer: Linux 5.1.5-sunxi64 musb-hcd
[    6.433875] usb usb7: SerialNumber: musb-hdrc.4.auto
[    6.434212] hub 7-0:1.0: USB hub found
[    6.434237] hub 7-0:1.0: 1 port detected
[    6.435001] sun50i-h6-pinctrl 300b000.pinctrl: 300b000.pinctrl supply vcc-pf not found, using dummy regulator
[    6.435596] sun50i-h6-pinctrl 300b000.pinctrl: 300b000.pinctrl supply vcc-pg not found, using dummy regulator
[    6.436148] sun50i-h6-pinctrl 300b000.pinctrl: 300b000.pinctrl supply vcc-pc not found, using dummy regulator
[    6.436726] sun50i-h6-pinctrl 300b000.pinctrl: 300b000.pinctrl supply vcc-pf not found, using dummy regulator
[    6.437243] sun50i-h6-pinctrl 300b000.pinctrl: 300b000.pinctrl supply vcc-pg not found, using dummy regulator
[    6.437749] sun50i-h6-pinctrl 300b000.pinctrl: 300b000.pinctrl supply vcc-pc not found, using dummy regulator
[    6.438120] sun6i-rtc 7000000.rtc: setting system clock to 1970-01-01T00:00:16 UTC (16)
[    6.438229] of_cfs_init
[    6.438318] of_cfs_init: OK
[    6.438493] vcc3v3: disabling
[    6.438497] vcc1v8: disabling
[    6.439009] Freeing unused kernel memory: 704K
[    6.456162] Run /init as init process
[    6.727894] sun50i-h6-pinctrl 300b000.pinctrl: 300b000.pinctrl supply vcc-pd not found, using dummy regulator
[    6.728242] dwmac-sun8i 5020000.ethernet: PTP uses main clock
[    8.800115] i2c i2c-0: mv64xxx: I2C bus locked, block: 1, time_left: 0
[    8.800132] rtc-pcf8563 0-0051: pcf8563_write_block_data: err=-110 addr=0e, data=03
[    8.800138] rtc-pcf8563 0-0051: pcf8563_probe: write error
[    8.800183] rtc-pcf8563: probe of 0-0051 failed with error -5

looks like its time to look closer at the dtbs for the uboot and the kernel for this box now - it does not seem to find the sd card (i end up in the initramfs) and also the console setup is strange: the kernel boot messages are not printed anywhere on the serial console or hdmi (but i can get them via dmesg) despite using earlycon or not and while specifiying the serail console. but this remains for tomorrow and later days - time to go to bed now :)

once more a lot of thanks - hexdump

p.s.: btw. if the above bl31 output or dmesg rings any bell for you regarding hints for the dtb (like the axp805 lines etc), i'm of course open to hear what you would have to say :)

[Andre-ARM]

Congrats! As you might have figured already, your box probably does not have an AXP chip, same as the Eachlink. So you need to remove that and replace all references with fixed regulators - look at the Eachlink .dts. Just updated my branch here locally, and my box boots to the Ubuntu prompt, so MMC works, USB as well. Does your box have Gigabit Ethernet? In that case chances are that would work as well, for Fast Ethernet we need to enable the AC200, but I failed to talk to it via I2C so far ...

[Andre-ARM]

Oh, and one thing: You don't need two DTs (for U-Boot and the kernel). Just use one DT in U-Boot, then use $fdtcontroladdr instead of loading some .dtb to $fdt_addr_r. Actually you might already get to the prompt using the Eachlink .dtb you already seem to use for U-Boot.

[hexdump0815]

thanks a lot - i tried this and this way the kernel sees the mmc properly as well, but somehow the boot hangs at some point - i'm preparing to switch from the armbian image to my own ubuntu rootfs - lets see if this changes anything. the serial console logging got better after adding loglevel=8 to the kernel cmdline - maybe the armbian kernels i used for testing has turned down the logging by default? ethernet is not detected by uboot or the kernel. android detects it as gmac - will check the android dtb later for this.

does your uboot and kernel detect the full 4gb (or 3gb useable)? mine only detects 2gb - can this be due to the 32bit libdram booting? can you maybe upload your kernel and modules somewhere, so that i can test with it and we would have the same test base. which kernel source tree and kernel-config would you recommend for building an own kernel for such an h6 tv box?

a lot of thanks - hexdump

update: this is the gmac probe on android:

[   21.461742] libphy: gmac0: probed
[   21.537116] sunxi-gmac gmac0 eth0: eth0: Type(6) PHY ID 00441400 at 0 IRQ poll (gmac0-0:00)

and this the android dtb entry for it:

                eth@05020000 {
                        pinctrl-0 = <0xe7>;
                        compatible = "allwinner,sunxi-gmac";
                        interrupts = <0x0 0xc 0x4>;
                        gmac-power2;
                        clocks = <0xd2>;
                        phy-mode = "rmii";
                        clock-names = "gmac";
                        device_type = "gmac0";
                        reg = <0x0 0x5020000 0x0 0x10000 0x0 0x3000030 0x0 0x4>;
                        phy-rst;
                        interrupt-names = "gmacirq";
                        pinctrl-1 = <0xd4>;
                        gmac-power1;
                        phandle = <0x18e>;
                        status = "okay";
                        rx-delay = <0x0>;
                        gmac-power0 = "vcc-ephy";
                        tx-delay = <0x0>;
                        pinctrl-names = "default", "sleep";
                };

[hexdump0815]

just discovered this one here - http://linux-sunxi.org/Eachlink_H6_Mini - i guess this is from you? looks like you had quite a bit of a fight with the serial console :)

also with my ubuntu rootfs and my defconfig 5.1.5 kernel and your dtb the boot hangs here:

[    2.469220] sun50i-h6-pinctrl 300b000.pinctrl: 300b000.pinctrl supply vcc-pf not found, using dummy regulator
[    2.479878] sunxi-mmc 4020000.mmc: Got CD GPIO
[    2.509742] sunxi-mmc 4020000.mmc: initialized, max. request size: 16384 KB, uses new timings mode
[    2.520234] sun50i-h6-pinctrl 300b000.pinctrl: 300b000.pinctrl supply vcc-pc not found, using dummy regulator
[    2.554421] sunxi-mmc 4022000.mmc: initialized, max. request size: 2048 KB, uses new timings mode
[    2.563666] hctosys: unable to open rtc device (rtc0)
[    2.569047] ALSA device list:
[    2.572027]   No soundcards found.
[    2.576458] Freeing unused kernel memory: 1408K
[    2.585465] mmc0: host does not support reading read-only switch, assuming write-enable
[    2.588130] Run /init as init process
[    2.597268] mmc0: new high speed SDHC card at address 0007
[    2.604181] mmcblk0: mmc0:0007 SL16G 14.5 GiB 
Loading, please wait...
[    2.614555]  mmcblk0: p1 p2 p3
starting version[    2.653013] mmc1: new DDR MMC card at address 0001
 237
[    2.659437] mmcblk1: mmc1:0001 BD11A0 28.8 GiB 
[    2.664851] mmcblk1boot0: mmc1:0001 BD11A0 partition 1 4.00 MiB
[    2.671592] mmcblk1boot1: mmc1:0001 BD11A0 partition 2 4.00 MiB
[    2.691575] Alternate GPT is invalid, using primary GPT.
[    2.696989]  mmcblk1: p1 p2 p3 p4 p5 p6 p7 p8 p9 p10 p11 p12 p13 p14 p15 p16 p17 p18
[    2.720703] sunxi-mmc 4022000.mmc: data error, sending stop command
[    3.724088] sunxi-mmc 4022000.mmc: send stop command failed

maybe some mmc parameters are not right or missing?

once more best wishes - hexdump

[Andre-ARM]

Hi, kernel: You shouldn't really go with a tailored config in 2019 anymore. Distro configs should cover everything needed, but for the H6 you might need a recent kernel (at least 5.0). For basic booting into MMC/SD you don't need anything special, I just compiled a 5.2-rc4 kernel with defconfig and that worked (MMC and USB 2.0, at least). Do you use an initrd? This might spoil the whole thing, it works for me without one. You should add rootwait to the kernel command line, though. Ethernet: AFAIK there is only one Ethernet controller in the SoC, the GMAC, which is almost the same as in the A64. This needs to be combined with a PHY, either an external one, usually for GBit Ethernet, or using the integrated 100MBit PHY, which seems to be AC200 compatible. So far there is no official support for the latter in the kernel, though I am hopeful that just flipping a few bits in some registers (via I2C) should do the trick. Didn't manage to talk to the I2C device yet. RAM: The SPL DRAM driver supports odd sizes (works with LPDDR3), not sure about libdram. One could hack the reported size in the SPL to hard code it to 3GB: check U-Boot commit 5776610e9ef0 and its parents. But to be honest so far I would be happy with 2GB, at least until the SPL driver works. And yes, serial needed some tinkering on the Eachlink, though I was more lucky than Sven.

[hexdump0815]

i tried to boot wirhout initrd - that went a bit further but hung again later with: "data error, sending stop command" and "send stop command failed" from the emmc device. as a result i set the emmc device to disabled for now in the dtb and now it boots fine with and without initrd :) ... i guess that maybe i'll have to limit the timing for the emmc a bit - will have to google a bit for options. running 5.1.5 mainline kernel now. 2gb should be fine so far, but i'll have a look at the commit you mentioned and the ones around it. usb works as well and this way i can get some ethernet until the built-in will work one day. one thing i noticed is that there is no frequency scaling yet (nothing below /sys/devices/system/cpu/cpufreq/) - is it just because there are no opp tables etc. in the dtb or other things missing or are maybe still patches needed for this on the h6?

a lot of thanks and best wishes - hexdump

[Andre-ARM]

Haven't heard about timing tuning for MMC yet, or any issues related to that. You could try to increase the drive strength of the eMMC pins to 40mA, see sun9i-a80-cubieboard4.dts in the kernel. Didn't try too much with the eMMC on my box, but I haven't seen those messages: seems to work for me. Frequency scaling is WIP, see http://linux-sunxi.org/Linux_mainlining_effort. Problem is that we don't know about voltage regulators on those boxes without the AXP, so we are stuck with one setting, I guess. This makes DVFS much less fun. Also we might want to have thermal feedback, which is also WIP.

[hexdump0815]

i'll give your drive strength suggestion a try - thanks a lot. for frequency scaling i gues that would be https://lore.kernel.org/patchwork/cover/1069625/ for the thermal support and https://lore.kernel.org/patchwork/cover/1042857/ for the scaling - right? i just reopened my box once more again and it seems to have the same a8038 pmic as the eachlink h6 mini. is there anything we can learn from the android dtb about it? for instance in mine there is something about axpdummy (can this be helpful maybe: https://github.com/orangepi-xunlong/OrangePiH5_kernel/tree/9705533570c5d1741a84cc00a482631d5a24019a/drivers/power/axp_power/axpdummy?) and i can see that it uses 4 different voltages in the opp-tables and the box does seem to make frequency scaling up to 1.4+ ghz - with mainline it seems to run at around 900mhz right now according to http://git.1wt.eu/web?p=mhz.git;a=summary ... but i guess, if we do not have a proper driver the pmic we are lost maybe?

[jernejsk]

It seems we have a fix: Apply http://sprunge.us/C37uzY over 7702a7c2b1ef4c56fc6fd6b7605f81ede82a07db. It should work according to https://forum.libreelec.tv/thread/17636-tanix-tx6/?postID=121062#post121062

Latest change, which seems to make the difference, was updating h6_ddr3_1600.c to behave same as libdram. Of course, I blindly copied values, so this is probably suboptimal. But it's at least a start.

@Andre-ARM do you mind taking it over from here? You are still original author.

[hexdump0815]

hey that sounds really good! i can confirm that this patch works on my qplus box too - same uboot output here :)

just some more point regarding the pmic: it looks like there is an axp8036 for the h3 (http://linux-sunxi.org/Table_of_Allwinner_based_boards) - can it be, that that strange a8038 is some kind of a folowup version for the h6? but anyway, there is not much info to be found anywhere about both ...

update: i tried again with the new spl uboot without libdram blob and used an armbian 5.1.5 kernel and got this during boot (using the orangepi-3 and pine-h64 dtb):

[    2.980428] axp20x-i2c 0-0036: AXP20x variant AXP806 found
[    5.011889] i2c i2c-0: mv64xxx: I2C bus locked, block: 1, time_left: 0
[    7.059887] i2c i2c-0: mv64xxx: I2C bus locked, block: 1, time_left: 0
[    7.067059] axp20x-i2c 0-0036: Failed to set masks in 0x40: -110
[    7.073655] axp20x-i2c 0-0036: failed to add irq chip: -110
[    7.079840] axp20x-i2c: probe of 0-0036 failed with error -110

does that mean it detects some axp or is this simply a wrong detection?

[Andre-ARM]

@jernejsk: Awesome! Many thanks. Yes, I will sort that out, and prepare proper patches for U-Boot. Haven't tried it yet, though. I took the delay values from back-calculations of a register dump, also the timings, IIRC. Will try to bisect what the actual fix is.

@hexdump0815: I am afraid the first line just means that the driver found this compatible string in the DT. As the following messages suggest, there is no I2C slave, might even be the controller is not fully happy (haven't found the real reason for this "bus locked" message yet, saw this on other occasions before).

[jernejsk]

@Andre-ARM I noticed that some MR register values depends on DRAM frequency, so that part needs a bit of work.

[Andre-ARM]

@jernejsk: did some experimentation: the only actual change needed (and required!) for me was lowering the clock frequency. The delay values are board specific anyway, and some parts of the mode registers depend indirectly on the frequency, because the latency values are given in unit of clock cycles (CAS latency, CAS write latency, Write recovery). So the changes to the timings file are actually to make it match DDR3-1333 values, I guess. I will put your changes in a separate file, named accordingly. Maybe I will go with the 1333 timing for all boards first, similar to what we do with most of the other Allwinner boards anyway.

[jernejsk]

I will be able to experiment next week, when I receive the box. IIRC, just lower frequency was not enough for one person who tested my changes. The box, his and mine, uses k4b4g0446q chips, which should be DDR3-1600 compatible.

[Andre-ARM]

@jernejsk, @hexdump0815: I cleaned up and rebased the patches and included Jernej's fixes. I went with the DDR3-1333 timing for now, this works on my box as well. I pushed this to https://github.com/apritzel/u-boot/commits/sunxi-h6-ddr3. Can you please check whether this works for you? Just using eachlink_h6_mini_defconfig should work for the other boxes, at least for now and for testing purposes. If you can confirm that this works, I will post it to the ML.

[Andre-ARM]

@hexdump0815: Regarding the PMIC: According to the Libretech schematics the 8036 looks like a "dumb" regulator, only allowing to turn on and off certain rails using GPIOs. So there is no I2C interface. Some H3/H5 boards feature some simple extra regulator with a choice of two voltages for the CPU, switchable by a GPIO. I doubt this is implemented on those boxes, though. For DVFS this means we have to go with one voltage, which reduces the potential power savings with lower frequencies, and also limits the maximum frequency. It would require some experiments to see how high we can clock with this fixed voltage, also to stay within the thermal envelope. Not my highest priority, to be honest, but feel free to jump into this ;-)

[Andre-ARM]

@jernejsk: Sorry, just realised I posted the patches without addressing your Github comments. They make sense, thanks for having a look! Feel free to repeat them on the list, otherwise I will incorporate them in the next revision. Cheers, Andre

[hexdump0815]

@Andre-ARM - sorry i was a few days offline - will test your branch tomorrow and let you know ...

[Andre-ARM]

@hexdump0815: no worries, glad to see that people still have real lives ;-) I posted it to the U-Boot ML yesterday, it would be great if you could comment there: https://lists.denx.de/pipermail/u-boot/2019-June/373265.html

[hexdump0815]

@Andre-ARM - i can confirm, that your branch sunxi-h6-ddr3 with the eachlink_h6_mini_defconfig combined with your atf bl31.bin boots and runs fine on my qplus h6 tv box - as good as before the patched version from @jernejsk ... is there an easy way to respond to your u-boot mailinglist message without being subscribed to it?

[Andre-ARM]

@hexdump0815: if you send me your email (use my email address from the post), I can bounce the cover letter to you, so that you can reply on that.

[apritzel]

@hexdump0815: Thanks for the reply on the ML, also for staying on it for the whole time. I consider this done now, at least here. @jernejsk: many thanks for all your help!

[jernejsk]

@apritzel you're welcome!

[jernejsk]

@apritzel I just got info from AW that value at location 0x3006100 is bonding id and quote:

on H6 SBC, there is no need to check on this value. If you want to be safe, then just use value 7.

Not sure if we should just hard code it or at least make a macro for this location.

[hexdump0815]

funny anecdote: i think i know now why there are some parts missing for accessing the serial console on the v1.2 version (see http://linux-sunxi.org/Eachlink_H6_Mini) of the eachlink h6 mini :) ... i got my hands on a used one of those and got linux booting on it, but after a while strange things started to happen: kernel crashes, core dumps in linux - besides that the ethernet driver from @jernejsk for the h6 tv boxes did not work ... i first assumed that something is wrong with the memory timing, but after looking at the android u-boot output and dmesg i found out the reason: the box has 3gb of ram installed (2g + 1g - all 8 chips on the board are populated) but the upper 1g seems to be ram chips from the trash bin: it seems to be there, gets detected by u-boot but is unusable resulting in the above mentioned crashes. when i boot the box with mem=2048M it runs absolutely stable. the included android only uses 2gb in u-boot and in the kernel and the kernel dmesg has those funny lines in it ...

...
[    0.000000] Memory: 2048MB = 3072MB total
[    0.000000] Memory: 1964408k/1964408k available, 132744k reserved
...

i especially like the first line :) ... those tv boxes are always good for a surprise

@apritzel - it would be interesting to see if it is similar for your v1.1 version too - i was able to trigger a kernel panic very fast by simply running "memorytester 2500M" if booted without mem=2048M

p.s. - in case anyone else is using one of those boxes: i did not have the mentioned 10k resistor at hand as described in the above sunxi wiki page to get the serial console working and simply bridged those contacts as well - maybe not perfect but works ...

[jernejsk]

@hexdump0815 I think all chips are active at the same time, because H6 data memory bus width is 32-bit and those chips are 4-bit. If you put 8 chips in parallel, you get 4-bit x 8 = 32-bit, which match H6 data width.

Currently what I can't understand is how much memory should be detected, 2 GiB or 4 GiB. You have 8x 2Gb chips which would suggest 2 GiB, but I'm unsure. How much memory is detected by Android?

There is also another bug in H6 DRAM code, which sometimes causes wrong amount of RAM to be detected. Can you try this patch just to see if it fixes anything? https://megous.com/git/u-boot/commit/?h=opi-v2019.04&id=c2675f18c0dc3f1892d96a0d7d608ed74d3fc636

[jernejsk]

@hexdump0815 you can also test this patch: https://patchwork.ozlabs.org/patch/1133463/ I'm not sure how rank is determined, but if those chips use half DQ configuration (16-bit memory bus width) and dual rank, it should solve your issue.

[Andre-ARM]

Hi @hexdump0815: Interesting info. Can you double check what chips you actually have? Sven reported 8 K4B2G0446 chips, which means 8 2GBit = 16 Gbit = 2GByte. So there is no third 3GB at all. Which just brings up the question of why the code detects it wrongly. My version of the box has 4 4GBit + 4 * 2GBit, so it's really 3GByte, just the detection code checks the first byte lane only, I believe, and assumes homogeneous chips, so 4GByte. This then gets cut down by U-Boot due to address space limitations (the H6 can only address up to 3GB of DRAM). But in the case of eight 2GBit chips it should really detect 2GB.

[Andre-ARM]

Oh, and in case this turns out to be a real bug, can we have this discussion on the U-Boot mailing list, please? The H6 DDR3 DRAM code has been merged recently, so it would need to be fixed there.

[hexdump0815]

i hope its ok to continue here, as i'm not on the u-boot mailinglist. this is what u-boot says:

U-Boot SPL 2019.07-rc4-g29c10c7113 (Jul 21 2019 - 09:07:45 +0200)
DRAM: 4096 MiB
Trying to boot from MMC1
NOTICE:  BL31: v2.0(debug):v2.0-337-g19b56cf4
NOTICE:  BL31: Built : 00:08:51, Dec  6 2018
NOTICE:  BL31: Detected Allwinner H6 SoC (1728)
NOTICE:  BL31: Found U-Boot DTB at 0xc079398, model: Eachlink H6 Mini
INFO:    ARM GICv2 driver initialized
NOTICE:  PMIC: Probing AXP805
ERROR:   Start clear bit timeout
ERROR:   PMIC: Cannot put AXP805 to master mode.
INFO:    BL31: Platform setup done
INFO:    BL31: Initializing runtime services
INFO:    BL31: cortex_a53: CPU workaround for 855873 was applied
INFO:    BL31: Preparing for EL3 exit to normal world
INFO:    Entry point address = 0x4a000000
INFO:    SPSR = 0x3c9

U-Boot 2019.07-rc4-g29c10c7113 (Jul 21 2019 - 09:07:45 +0200) Allwinner Technology

CPU:   Allwinner H6 (SUN50I)
Model: Eachlink H6 Mini
DRAM:  3 GiB
MMC:   mmc@4020000: 0, mmc@4022000: 1
Loading Environment from FAT... Unable to use mmc 1:1... In:    serial@5000000
Out:   serial@5000000
Err:   serial@5000000
Net:   No ethernet found.
starting USB...
No working controllers found
Hit any key to stop autoboot:  0 
switch to partitions #0, OK
mmc0 is current device
Scanning mmc 0:1...
Found /extlinux/extlinux.conf
Retrieving file: /extlinux/extlinux.conf
6343 bytes read in 8 ms (773.4 KiB/s)

so the spl finds 4gb and u-boot 3gb. the box is closed right now, but i think i remember that it had 4x2g chips and 4x4g chips - this would make no real sense if the 8x4bit layout assumption of @jernejsk is correct. but it might explain the numbers maybe (just a wild guess): the spl sees the first chip (4g) or maybe only some of the chips and assumes all of them the same resulting in 4gb, u-boot maybe really checks all the chips and comes to the correct size of 3gb (or it simply shows what the h6 can address). the problem is that everything is fine until 2gb, but from there only half of the bits are really being delivered from the 4g chips while there is nothing anymore on the 2g chips. while trying out different u-boots yesterday i also tried by accident my old libdram uboot where i had forgotten the atf and that somehow detected 4gb and then did the "DRAM simple test" (looks like this is only in libdram?) which gave an error at some address and the error pattern looked like half of the bits of the test pattern were correct and the other half looked like random. as a result the test resulted in 2gb only. however it is in the end, i think the hardware of this box is weird and i do not think that this is really a bug in u-boot.

@jernejsk i tried your half dq ram patch already as part of my testing yesterday and did not make any difference - it gave 3gb and crashed with memtester 2500M.

[jernejsk]

@hexdump0815 what about second patch from megous?

[hexdump0815]

sorry - i overlooked that one somehow - just rebuilt u-boot with it and looks like it does not make any real difference:

U-Boot SPL 2019.07-rc4-g29c10c7113-dirty (Jul 22 2019 - 19:12:52 +0200)
DRAM: 4096 MiB
Trying to boot from MMC1
NOTICE:  BL31: v2.0(debug):v2.0-337-g19b56cf4
NOTICE:  BL31: Built : 00:08:51, Dec  6 2018
NOTICE:  BL31: Detected Allwinner H6 SoC (1728)
NOTICE:  BL31: Found U-Boot DTB at 0xc0793a8, model: Eachlink H6 Mini
INFO:    ARM GICv2 driver initialized
NOTICE:  PMIC: Probing AXP805
ERROR:   Start clear bit timeout
ERROR:   PMIC: Cannot put AXP805 to master mode.
INFO:    BL31: Platform setup done
INFO:    BL31: Initializing runtime services
INFO:    BL31: cortex_a53: CPU workaround for 855873 was applied
INFO:    BL31: Preparing for EL3 exit to normal world
INFO:    Entry point address = 0x4a000000
INFO:    SPSR = 0x3c9

U-Boot 2019.07-rc4-g29c10c7113-dirty (Jul 22 2019 - 19:12:52 +0200) Allwinner Technology

CPU:   Allwinner H6 (SUN50I)
Model: Eachlink H6 Mini
DRAM:  3 GiB
MMC:   mmc@4020000: 0, mmc@4022000: 1
Loading Environment from FAT... Unable to use mmc 1:1... In:    serial@5000000
Out:   serial@5000000
Err:   serial@5000000
Net:   No ethernet found.
starting USB...
No working controllers found
Hit any key to stop autoboot:  0 
switch to partitions #0, OK
mmc0 is current device
Scanning mmc 0:1...
Found /extlinux/extlinux.conf
Retrieving file: /extlinux/extlinux.conf
6343 bytes read in 8 ms (773.4 KiB/s)

[Andre-ARM]

@hexdump0815: thanks for the data. So here are my findings, not fully conclusive yet, but getting closer:

• For clarification: The SPL is the only one to detect DRAM, by probing the memory controller and its chips. U-Boot proper just takes the amount found by the SPL, and applies the address limit. The whole address bus is only 32-bits wide, and DRAM starts at 1GB, so 3GB is the limit.
• For the topology: My box has 4 Micron D9PQL=MT41K1G4 and 4 Samsung K4B2G0446Q chips. They all share a 1K page size, 4 bits of data per chip, 8 banks and 11 column bits. The difference is the number of row bits: 16 on the Micron, 15 on the Samsung. If you do the math: 3(bank bits) + 11 + 16 = 30bits * 4 (bits per chip) = 2^32 bits = 2^29 Byte = 512MByte for each Micron chip, and 256 MByte for the Samsung ones. It is my understanding that the four bits of data provided by each chip are connected next to each other to form the 32 bit data bus.
• We detect the number of rows by trying to configure the controller for this number of row bits, then checking if two memory locations exactly a certain number of bytes apart share a set of DRAM cells. This is accomplished by writing 0 to DRAM address 0, and some other number to address "offset". Compare arch/arm/mach-sunxi/dram_helpers.c:mctl_mem_matches() and its callers in mctl_auto_detect_dram_size().

At this point it get fuzzy for me (it's also late here and my brain stops working):

• By using address 0 and 0 + offset we probe the number of rows in the lower part(?) of the DRAM space. So we detect the number of rows for the first four chips? Or maybe the special symmetrical pattern used ( 0xaa55aa55) covers up for this and lets the code believe in a certain number of rows? Need to check the exact meaning the the addrmap registers to understand this.
• Should checking for the validity of a certain number of rows configuration occur repeatedly over the whole DRAM size (not only from 0)? Or with some byte lanes masked to detect different number of rows in each chip?
• If each chip provides one nibble of each 32-bit word, then we would see half of the nibbles missing for each word accessed with an address above 2GB, if every chip is configured identically? Does this match your description? So the DRAM controller would need to be programmed differently for the upper and the lower two byte lanes, to use 16 and 15 row bits correctly?

Grateful for any ideas, corrections or insights.

[jernejsk]

@Andre-ARM My understanding also match with your last point. @hexdump0815 also said on Armbian forum that Android detects only 2 GiB of RAM. I don't see a way to configure half DQ for upper GiB only.

[hexdump0815]

@Andre-ARM - yes what you write explains quite well what i mean. i think we should not see such a case that often - all the newer h6 tv boxes seem to have 8x4g chips, so real 4gb to be able to provide proper 3gb in the end. i guess a simple test in the spl might be to detect the memory like right now and then write a pattern at an address beyond half of that (so 2gb+ in our case) and read it back. if all 32bit of it match, we really have the full amount of memory (4gb in our case), in case we only get 16 of the 32bit properly back then we have the eachlink case and have to half the detected memory amount.

could you maybe do a simple test on your eachlink: boot linux on it which should show 3gb of memory, then install the "memtester" package and run "memtester 2500M" - my guess is that it will crash the kernel quickly as in my case as i have a very similar memory config resulting in every access above 2gb only returning half of the proper bits back (the ones from the 4g chips) - then restart linux with the kernel cmdline option "mem=2048M" and run "memtester 1800M" and i guess it will run absolutely stable.

@jernejsk - now i finally understood what "half dq memory" is, so memory which is only using half of the 32bit memory bus - right? :) ... if yes, then what you wrote is what would be required to make the eachlink working with 3gb. i guess someone wanted to save some money by only adding 3gb in total if the cpu can only handle 3gb, but they did not really think that far and later fixed it in software by limiting memory to 2gb and faking the 3gb in android (if at all).

best wishes - hexdump