Jump to content

Recommended Posts

Posted

@jernej - interesting - this time i got the same error and after the first reset it went further ... sadly retrying it resulted in it resetting over and over again ...

 

U-Boot SPL 2020.01-rc3-00007-g8d8ee47e03-dirty (Jan 08 2020 - 00:05:04 +0100)
DRAM:PLL = b0003600
DRAM PHY PGSR0 = 20003d
DRAM PHY DX0RSR0 = 0
DRAM PHY DX1RSR0 = 0
DRAM PHY DX2RSR0 = 0
DRAM PHY DX3RSR0 = 0
Error while initializing DRAM PHY!

resetting ...

U-Boot SPL 2020.01-rc3-00007-g8d8ee47e03-dirty (Jan 08 2020 - 00:05:04 +0100)
DRAM:MBUS port 0 cfg0 0100000d cfg1 00640080
MBUS port 1 cfg0 06000009 cfg1 01000578
MBUS port 2 cfg0 0200000d cfg1 00600100
MBUS port 3 cfg0 01000009 cfg1 00500064
MBUS port 4 cfg0 20000209 cfg1 1388157c
MBUS port 5 cfg0 00640209 cfg1 00200040
MBUS port 6 cfg0 00640209 cfg1 00200040
MBUS port 8 cfg0 01000009 cfg1 00400080
MBUS port 11 cfg0 01000009 cfg1 00640080
MBUS port 14 cfg0 04000009 cfg1 00400100
MBUS port 16 cfg0 2000060d cfg1 09600af0
MBUS port 25 cfg0 0064000d cfg1 00200040
MBUS port 26 cfg0 20000209 cfg1 1388157c
MBUS port 37 cfg0 01000009 cfg1 00400080
MBUS port 38 cfg0 00640209 cfg1 00200040
MBUS port 39 cfg0 20000209 cfg1 1388157c
MBUS port 40 cfg0 00640209 cfg1 00200040
 2048 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 0xc07ad38, model: Eachlink H6 Mini
INFO:    ARM GICv2 driver initialized
NOTICE:  PMIC: Probing AXP805
IN

 

afterwards it hangs at the same place as if booted with the 32/64bit libdram u-boot - is that in the bl31.bin atf or is that afterwards already?

 

update: i now tried to let it reset for a while and it looks like after dozens of resets it always ends up like above ...

 

best wishes - hexdump

Posted

@hexdump Interesting, so mainline U-Boot fails in ATF, no matter which DRAM init method is used (libdram vs open source)? I think it can be related to the fact that we have old libdram ("V2_2"), while Android you have uses newer version ("V2_78"). Let's try to find newer blob... In worst case we could also analyze dumped U-Boot from your box, but a lot of information would be omitted.

 

Can you try http://ix.io/26Ln ? I changed two fields according to Zynq documentation with similar DRAM controller. This may be fixed in newer libdram versions...

 

edit: this one is V2_5: https://github.com/orangepi-xunlong/OrangePiH6_uboot/blob/master/sunxi_spl/dram/sun50iw6p1/dram/libdram

edit2: and this V2_7: https://github.com/Allwinner-Homlet/H6-BSP4.9-bootloader/blob/master/uboot_2014_sunxi_spl/sunxi_spl/dram/sun50iw6p1/dram/libdram

but now I don't know where to look for newer ones...

Posted

@jernej - sadly no change with the new patch ... will try the newer libdram tomorrow - time for sleep now :) ... please let me know in case you find some newer one ...

Posted

@jernej - libdram v2_5 makes things rather worse than better:

 

U-Boot SPL 2018.11-g458f795e53-dirty (Jan 08 2020 - 09:32:34 +0100)
DRAM:DRAM VERSION IS V2_5
DRAM CLK =840 MHZ
DRAM Type =3 (3:DDR3,4:DDR4,6:LPDDR2,7:LPDDR3)
DRAM zq value: 3b3bfb

 

and then it hangs ... it is also important to note, that with the old v2_2 libdram it boots completely fine to u-boot if i use the bsp bl31.bin atf blob (so the memory timing seems to be ok somehow) - only disadvantage is that i'm then ending up with a 32bit u-boot, which is think is not able to boot a 64bit kernel ... is there maybe a way to extract the 64bit bl31.bin atf from the boxes emmc somehow?

 

can it be that the problem is the atf itself maybe? it fails shortly after "NOTICE:  PMIC: Probing AXP805" and the box does not have a AXP805 - can the AXP805 probing somehow be disabled?

 

best wishes - hexdump

 

update: i think the full 32bit u-boot gets to u-boot, as it seems to miss the atf somehow - will have to check its build in more detail once more ...

Posted

@hexdump it really seems to be ATF issue. Try to comment out AXP805 initialization and make sure DT you are using doesn't have nodes for it. If still doesn't work, I suggest you contact apritzel.

Posted

@jernej - i found a newer atf build (v2.2 vs. v2.0 for the apritzel build) here: https://github.com/orangepi-xunlong/external/blob/master/chips/sun50iw6p1/mainline/bl31.bin and it hangs at the same place ... my u-boot dtb does not include an axp805 node and i checked the atf sources and looks like there is also no real option to disable the axp805 code in an easy way ... but in the end it might still be a memory timing issue so that the atf code starts making use of the memory and crashes then ...

Posted

@jernej - success! finally :) ... it was the atf - i now built the atf myself (v2.2) and just emptied the axp probing function (so that it does nothing anymore and just returns an error back, i.e. no axp) and voila: it boots ... with the mainline u-boot it still resets dozens of times until it finally continues to boot, but it always does at some point in time after a few seconds or minutes (with the libdram version it boots absolutely reliable) ... so we are back to trying to improve the dram setup and timing to maybe get rid of the resets - please let me know in case you have any idea what else to maybe test ...

 

a lot of thanks for all you help and support and best wishes - hexdump

 

...
resetting ...

U-Boot SPL 2020.01-rc3-00007-g8d8ee47e03-dirty (Jan 10 2020 - 16:34:14 +0100)
DRAM:PLL = b0003500
DRAM PHY PGSR0 = 20003d
DRAM PHY DX0RSR0 = 0
DRAM PHY DX1RSR0 = 0
DRAM PHY DX2RSR0 = 0
DRAM PHY DX3RSR0 = 0
Error while initializing DRAM PHY!

resetting ...

U-Boot SPL 2020.01-rc3-00007-g8d8ee47e03-dirty (Jan 10 2020 - 16:34:14 +0100)
DRAM:MBUS port 0 cfg0 0100000d cfg1 00640080
MBUS port 1 cfg0 06000009 cfg1 01000578
MBUS port 2 cfg0 0200000d cfg1 00600100
MBUS port 3 cfg0 01000009 cfg1 00500064
MBUS port 4 cfg0 20000209 cfg1 1388157c
MBUS port 5 cfg0 00640209 cfg1 00200040
MBUS port 6 cfg0 00640209 cfg1 00200040
MBUS port 8 cfg0 01000009 cfg1 00400080
MBUS port 11 cfg0 01000009 cfg1 00640080
MBUS port 14 cfg0 04000009 cfg1 00400100
MBUS port 16 cfg0 2000060d cfg1 09600af0
MBUS port 25 cfg0 0064000d cfg1 00200040
MBUS port 26 cfg0 20000209 cfg1 1388157c
MBUS port 37 cfg0 01000009 cfg1 00400080
MBUS port 38 cfg0 00640209 cfg1 00200040
MBUS port 39 cfg0 20000209 cfg1 1388157c
MBUS port 40 cfg0 00640209 cfg1 00200040
 2048 MiB
Trying to boot from MMC1
NOTICE:  BL31: v2.2(debug):v2.2-dirty
NOTICE:  BL31: Built : 16:17:47, Jan 10 2020
NOTICE:  BL31: Detected Allwinner H6 SoC (1728)
NOTICE:  BL31: Found U-Boot DTB at 0xc07ad38, model: Eachlink H6 Mini
INFO:    ARM GICv2 driver initialized
NOTICE:  PMIC: Probing AXP805   <=== this is actually not doing anything in this version
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 2020.01-rc3-00007-g8d8ee47e03-dirty (Jan 10 2020 - 16:34:14 +0100) Allwinner Technology

CPU:   Allwinner H6 (SUN50I)
Model: Eachlink H6 Mini
DRAM:  2 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.
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
1103 bytes read in 5 ms (214.8 KiB/s)
1:      Armbian
Retrieving file: /initrd.img-5.4.7-stb-ah6+
11947280 bytes read in 1201 ms (9.5 MiB/s)
Retrieving file: /Image-5.4.7-stb-ah6+
21233672 bytes read in 2131 ms (9.5 MiB/s)
append: root=LABEL=ROOTFS rootflags=data=writeback rw console=ttyS0,115200 console=tty0 no_console_suspend cons0
Retrieving file: /dtb-5.4.7-stb-ah6+/sun50i-h6-eachlink-h6mini.dtb
21044 bytes read in 7 ms (2.9 MiB/s)
## Flattened Device Tree blob at 4fa00000
   Booting using the fdt blob at 0x4fa00000
   Loading Ramdisk to 4949b000, end 49fffd10 ... OK
   Loading Device Tree to 0000000049492000, end 000000004949a233 ... OK

Starting kernel ...

Booting Linux on physical CPU 0x0000000000 [0x410fd034]
Linux version 5.4.7-stb-ah6+ (root@eachlink) (gcc version 7.4.0 (Ubuntu/Linaro 7.4.0-1ubuntu1~18.04.1)) #1 SMP 0
Machine model: Eachlink H6 Mini
...

 

Posted

in case anyone (maybe @kalikopfnuss maybe others too) wants to give this approach a try on such a box or maybe even on other not yet working allwinner h6 boxes - just get the latest rk aml aw image from @balbes150 from here:

und use the attached file as u-boot written via:

dd if=u-boot-sunxi-with-spl-h6-noname.bin of=/dev/yoursdcarddevice bs=1024 seek=8

be aware that at least with my box it will reset for a while (even a few minutes) before it actually boots, but so far it always booted at some point in time :)

 

good luck and best wishes - hexdump

 

 

u-boot-sunxi-with-spl-h6-noname.bin

Posted

@hexdump Out of curiosity, why do you have different DRAM PLL settings in different reports? In this one frequency is 576 MHz (DRAM:PLL = b0003500) but for example in this one is 672 MHz (DRAM:PLL = b0003600). Did you change that in config file?

 

Edit: According to Android boot log, it should be set to 576 MHz. Can you try if lowering frequency helps?

Posted

@jernej - interesting - i'm not aware of having changed anything - what would result in such a change, i.e. what kind of change would explain it? can only be that during testing i mixed up some defconfig files (i might have lowered the frequency set in there once for testing to 648mhz, which i think the android or libdram showed as frequency - i think it was something like 660mhz before), but as said i'm not really aware of having done anything like this ...

Posted

@jernej - would it make sense to play around with lowering this frequency even further?

 

update: but this one was semi working too and seemed to have the higher frequency:

 

Posted

@hexdump can you please read out location 0x3006100 with either devmem from Linux or md.b from U-Boot? I suspect it will be 7, but it might be 3.

Posted
On 1/10/2020 at 11:46 PM, hexdump said:

in case anyone (maybe @kalikopfnuss maybe others too) wants to give this approach a try on such a box or maybe even on other not yet working allwinner h6 boxes - just get the latest rk aml aw image from @balbes150 from here:

und use the attached file as u-boot written via:


dd if=u-boot-sunxi-with-spl-h6-noname.bin of=/dev/yoursdcarddevice bs=1024 seek=8

be aware that at least with my box it will reset for a while (even a few minutes) before it actually boots, but so far it always booted at some point in time :)

 

good luck and best wishes - hexdump

 

 

u-boot-sunxi-with-spl-h6-noname.bin 577.54 kB · 11 downloads

Hi Hexdump. I have an Allwinner H616 (pretty new box with android 10). Could it work with the u-boot-sunxi-spl-h6-noname.bin and a generic Armbian? Should I try or may be wait for newer development?

Posted
15 hours ago, zanfi said:

I try or may be wait for newer development?

I think there will be nothing critical, if you check all the available options for u-boot for H6, suddenly a miracle happens and some of the options will be able to start or at least show some activity in the UART console .

Posted
On 3/4/2020 at 7:32 AM, balbes150 said:

I think there will be nothing critical, if you check all the available options for u-boot for H6, suddenly a miracle happens and some of the options will be able to start or at least show some activity in the UART console .

Hi, found some more info about Allwinner H616 on https://www.cnx-software.com/2020/02/27/allwinner-h616-tv-box-processor-comes-with-mali-g31-gpu-supports-android-10/

See attached dts file too

 

image.png.da9e0cd4dd659f62aacfc8675c5e949e.png

sun50iw9p1-dts.txt

  • Werner locked this topic
Guest
This topic is now closed to further replies.
×
×
  • Create New...

Important Information

Terms of Use - Privacy Policy - Guidelines