Since Tanix TX6 can boot from the SD card

[xaduha]

Tanix TX6 is H6 based Android TV Box and it can boot from SD cards prepared with PhoenixCard. It should be possible to make it work with Armbian too, right? I tried a recent Lite2 image, it didn't work, but it also didn't boot main Android, which means SD boot takes priority. I don't think it's a normal behavior for other Android TV boxes, but maybe it is for those with H6 boards.

[hexdump]

i just gave it a try to boot the orange-pi-3 and pine h64 armbian images and the orangepi 4.9 kernel image on a q-plus h6 4g/32g tv box and it did not work out well - the serial console output was:

Quote

armbian images:

U-Boot SPL 2019.04-armbian (May 27 2019 - 02:06:56 +0200)
DRAM:This DRAM setup is currently not supported.

resetting ...

 

orangepi 4.9 kernel image:

[240]HELLO! BOOT0 is starting!
[244]boot0 commit : 94a1b3d504ad4cd9bb5d9522947301ac0350ab1b
 
[251]key press : [

and nothing more. looks like one would first need to get some uboot working to the point that it boots well and is able to boot a kernel. the legacy uboot on the box is a 2014 one, so even older than the already historical 2015 ones from amlogic boxes ... the bad thing about it is that you cannot interrupt its boot via keyboard early on, so no way to explore if it can be used to boot a mainline kernel.

 

anyone having any idea how to add the proper dram setup to uboot (i guess its not part of the dtb as for rockchip devices) or how to extract maybe a sdcard uboot from a stock firmware image (like it can be done for amlogic boxes)?

 

best wishes - hexdump

[jernej]

That's expected because Tanix TX6 uses DDR3 memory which is not supported yet by U-Boot. All currently supported boards use LPDDR3. Anyone wants to do some low level hacking? I would, but I don't have such board. Previous unsuccessful attempt can be found here: https://github.com/apritzel/u-boot/commits/eachlink-h6-mini-WIP

It's only a matter of fixing this up.

 

[balbes150]

15 hours ago, jernej said:

That's expected because Tanix TX6 uses DDR3 memory which is not supported yet by U-Boot. All currently supported boards use LPDDR3. Anyone wants to do some low level hacking? I would, but I don't have such board. Previous unsuccessful attempt can be found here: https://github.com/apritzel/u-boot/commits/eachlink-h6-mini-WIP

It's only a matter of fixing this up.

I have a TX6 sample but no UART on it. If you give me the necessary files (images) and steps to perform, I can run the tests.

[jernej]

5 hours ago, balbes150 said:

If you give me the necessary files (images) and steps to perform, I can run the tests.

Thanks, but I haven't any files. Somebody with a board and will to write/debug DRAM driver has to do it.

[hexdump]

what exactly would be required to be done (for someone who never did any dram driver development)? i looked at the commits in the git repo you mentioned and it looks like it contains tries to define the ram timing in the code but at some point it switched to getting the timing info from a binary blob. is that correct and do you know how far he got with either of the two approaches?

 

a lot of thanks in advance and best wishes - hexdump

[jernej]

9 minutes ago, hexdump said:

what exactly would be required to be done (for someone who never did any dram driver development)?

My approach was (not in that order):

- disassemble DRAM blob from Allwinner

- compare disassembled code to existing code and minimize differences

- read documentation of similar controllers (some Zynq variants seems to have similar controller)

- read explanation of how DRAM actually works on the net

- compile SPL and U-Boot as 32-bit binary, which allows loading it through USB quickly (FEL boot)

- prepare SPL/U-Boot binary using libdram for later register comparison

- add a lot of debug prints in driver to see what is actually doing and compare values to those from libdram

 

I didn't wrote it from scratch, so this is similar situation.

 

Since testing and comparing is everything, I can only help with reverse engineering libdram and comparing existing code to that. One person already accepted the challenge on LibreELEC forum for writing this driver (also Tanix TX6 box), but it's always nice to have bigger team working on this.

[hexdump]

oh - that sounds quite complicated

 

would btw. also something like https://github.com/armbian/build/blob/master/config/sources/rockchip.conf#L68-L71 possible where @jock used the existing binary spl for the memory initialization and then combined it with mainline uboot on the xt-q8l-v10 rockchip tv box?

 

a lot of thanks in advance and best wishes - hexdump

 

 

[jernej]

32 minutes ago, hexdump said:

oh - that sounds quite complicated

yeah, DRAM drivers usually nobody wants to write due to that. And that driver is also responsible for stability of whole system.

 

34 minutes ago, hexdump said:

would btw. also something like https://github.com/armbian/build/blob/master/config/sources/rockchip.conf#L68-L71 possible where @jock used the existing binary spl for the memory initialization and then combined it with mainline uboot on the xt-q8l-v10 rockchip tv box?

 

You can achieve something similar with using libdram as it is done in commit you noticed. However, it has at least two downsides. As commit message says, it's legally non-redistributable, because you mixing GPL code (SPL) and closed source code (libdram) in single binary. Second downside is that libdram is 32-bit, which complicates compiling SPL and other parts. You would need two different configuration files and combine everything by hand.

 

I don't think using BSP SPL as a whole is possible with mainline U-Boot.

[hexdump]

ok - i gave it a try and compile the u-boot from the repo and the branch you mentioned - looks like this is how far we get so far:

Quote

U-Boot SPL 2018.11-g458f795e53 (Jun 06 2019 - 17:37:48 +0200)
DRAM:

... so looks like its maybe not happy with the dram config - how to proceed from here?

 

i also gave it a try to boot via the spl from the box, but looks like it cannot properly initialize the sd-card, so no chance to see if it will boot the mainline uboot in the end:

Quote

[308]HELLO! BOOT0 is starting!
[312]boot0 commit : 8
[326]set pll start
[329]set pll end
[331]rtc[0] value = 0x00000000
[334]rtc[1] value = 0x00000000
[337]rtc[2] value = 0x00000000
[340]rtc[3] value = 0x00000000
[343]rtc[4] value = 0x00000000
[346]rtc[5] value = 0x00000000
[349]DRAM VERSION IS V2_761
[352]DRAM CLK =672 MHZ
[354]DRAM Type =3 (3:DDR3,4:DDR4,6:LPDDR2,7:LPDDR3)
[359]DRAM zq value: 003b3bfb
[663]IPRD=00780078--PGCR0=00000f7d--PLL=b0003700
[668]para1 = 0000310b,para2 = 0c000000
[678]DRAM simple test OK.
[682]card no is 0
[683]sdcard 0 line count 4
[686][mmc]: mmc driver ver 2017-10-19 10:34:00
[691][mmc]: sdc0 spd mode error, 2
[694][mmc]: mmc 0 bias 00000004
[702][mmc]: ***Try MMC card 0***
[710][mmc]: mmc 0 cmd 1 timeout, err 00000100
[714][mmc]: mmc 0 cmd 1 err 00000100
[718][mmc]: mmc 0 send op cond failed
[722][mmc]: MMC card 0 Card did not respond to voltage select!
[728][mmc]: ***SD/MMC 0 init error!!!***
[732][mmc]: mmc 0 register failed
[735]Loading boot-pkg fail(error=2)
[739]Ready to disable icache.

any idea what could be done about this? @balbes150 - can you maybe dump the spl of your tanix box (first 40kb = 8k empty plus 32k spl i think ... but maybe the few first mb would be nice too, to see if your u-boot is maybe better than mine, as mine does not allow to interrupt the boot)

 

best wishes - hexdump

[hexdump]

a little update to my last post: i also tried the libdram version to see if i can get a little success story and it looks quite promising (but is ugly of course as its non redistributable, requires compiling on arm32, uses a binary blob):

Quote

U-Boot SPL 2018.11-g458f795e53-dirty (Jun 06 2019 - 18:37:37 +0200)
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=5d005c--PGCR0=f7d--PLL=b0004500
DRAM SIZE =2048 M
DRAM simple test OK.
 2048 MiB
Trying to boot from MMC1

U-Boot 2018.11-g458f795e53-dirty (Jun 06 2019 - 18:37:37 +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...
switch to partitions #0, OK
mmc1(part 0) is current device
** Unrecognized filesystem type **
starting USB...
No controllers found
USB is stopped. Please issue 'usb start' first.
starting USB...
No controllers found
No ethernet found.
missing environment variable: pxeuuid
missing environment variable: bootfile
Retrieving file: pxelinux.cfg/00000000
No ethernet found.

 

in short how to do it:

- get https://github.com/apritzel/u-boot.git

- checkout eachlink-h6-mini-WIP

- apply

Quote

diff --git a/arch/arm/mach-sunxi/spl_switch.c b/arch/arm/mach-sunxi/spl_switch.c
index 9ae3825841..912a523ce6 100644
--- a/arch/arm/mach-sunxi/spl_switch.c
+++ b/arch/arm/mach-sunxi/spl_switch.c
@@ -52,7 +52,8 @@ void __noreturn jump_to_image_no_args(struct spl_image_info *spl_image)
                jump_to_image_native(spl_image);
        } else {
                debug("entering by RMR switch\n");
-               writel(spl_image->entry_point, CONFIG_SUNXI_RVBAR_ADDRESS);
+               writel(spl_image->entry_point, 0x09010040);
+/*             writel(spl_image->entry_point, CONFIG_SUNXI_RVBAR_ADDRESS); */
                DSB;
                ISB;
                reset_rmr_switch();

- get http://files.pine64.org/os/sdk/H64-ver1.0/H6-BSP-1.0.tgz (via: https://wiki.pine64.org/index.php/PINE_H64_Main_Page#Linux_BSP_SDK)

- extract lichee/tools/pack/chips/sun50iw6p1/bin/bl31.bin and lichee/bootloader/uboot_2014_sunxi_spl/sunxi_spl/dram/sun50iw6p1/dram/libdram from it

- put both into the root of the git tree (libdram as libdram-h6)

- make eachlink_h6_mini_libdram_spl_defconfig

- make (important: this needs to run on a 32bit arm system - not 64bit)

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

[hexdump]

update: things are more complex

 

the uboot with libdram did work, but it was running completely in 32bit mode, had just a 32bit uboot and was thus only be able to boot 32bit kernels, which is not what we want to achieve. so i now build uboot with "make eachlink_h6_mini_defconfig" on an arm64 machine and built one with "make eachlink_h6_mini_libdram_spl_defconfig" on a arm32 machine (plus the patch from above). then i copied the resulting file spl/sunxi-spl.bin as sunxi-spl.bin-arm32 from the arm32 to the arm64 machine and created a bootable sd-card with the command (on the arm64 machine):

cat sunxi-spl.bin-arm32 u-boot.img u-boot.dtb | dd of=/dev/sdX bs=1024 seek=8

i actually first wrote a pine-h64 (or orange pi 3) nightly image from https://dl.armbian.com/pineh64/nightly/ before i did the dd command from above - this way i had some test kernel to play around with around on the sd card as well. booting this one now results in:

 

U-Boot SPL 2018.11-g458f795e53-dirty (Jun 06 2019 - 18:37:37 +0200)
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
DRAM SIZE =2048 M
DRAM simple test OK.
 2048 MiB
Trying to boot from MMC1


U-Boot 2018.11-g458f795e53 (Jun 07 2019 - 23:12:25 +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 U-Boot script /boot/boot.scr
831 bytes read in 35 ms (22.5 KiB/s)
## Executing script at 4fc00000
5586861 bytes read in 605 ms (8.8 MiB/s)
27263 bytes read in 70 ms (379.9 KiB/s)
14704648 bytes read in 1526 ms (9.2 MiB/s)
## Loading init Ramdisk from Legacy Image at 43300000 ...
   Image Name:   uInitrd
   Image Type:   AArch64 Linux RAMDisk Image (gzip compressed)
   Data Size:    5586797 Bytes = 5.3 MiB
   Load Address: 00000000
   Entry Point:  00000000
   Verifying Checksum ... OK
## Flattened Device Tree blob at 43000000
   Booting using the fdt blob at 0x43000000
   Loading Ramdisk to 49aac000, end 49ffff6d ... OK
   Loading Device Tree to 0000000049aa2000, end 0000000049aaba7e ... OK

Starting kernel ...

using this /boot/boot.cmd file (converted to its corresponding /boot/boot.scr file as described in the last line):

setenv bootargs "console=ttyS0,115200n8 no_console_suspend consoleblank=0 root=UUID=056b7f6b-ee6f-4089-8dde-fad454515b02 rootwait ro fsck.fix=yes fsck.repair=yes net.ifnames=0 ipv6.disable=1"
ext2load mmc 0 0x43300000 boot/uInitrd-5.1.3-sunxi64
#ext2load mmc 0 0x43000000 boot/dtb-5.1.3-sunxi64/allwinner/sun50i-h6-orangepi-3.dtb
#ext2load mmc 0 0x43000000 boot/dtb-5.1.3-sunxi64/allwinner/sun50i-h6-orangepi-lite2.dtb
#ext2load mmc 0 0x43000000 boot/dtb-5.1.3-sunxi64/allwinner/sun50i-h6-orangepi-one-plus.dtb
ext2load mmc 0 0x43000000 boot/dtb-5.1.3-sunxi64/allwinner/sun50i-h6-pine-h64.dtb
ext2load mmc 0 0x42000000 boot/vmlinuz-5.1.3-sunxi64
booti 0x42000000 0x43300000 0x43000000
# Recompile with:
# mkimage -C none -A arm -T script -d boot.cmd boot.scr

this means that the kernel crashed even before it was able to setup the serial console or that somehow it cannot speak to it i guess. i think at least this should somehow work even with the wrong dtb (looks like i'll have to model some proper dtb for that box based on one of the existing mainline h6 dtbs and the information from the android dtb of the box at some point).

 

@jernej - is there anything like earlyprintk for the allwinner h6?

 

best wishes - hexdump

[chwe]

2 hours ago, hexdump said:

 

@jernej - is there anything like earlyprintk for the allwinner h6?

 

might give the 8250 UART driver a try? At least mt7623 got really talky once it was configured properly.

[jernej]

7 hours ago, hexdump said:

cat sunxi-spl.bin-arm32 u-boot.img u-boot.dtb | dd of=/dev/sdX bs=1024 seek=8

Note that you are missing ATF binary, so Linux won't boot.

 

7 hours ago, hexdump said:

is there anything like earlyprintk for the allwinner h6?

of course, earlyprintk works everywhere if  UART driver driver is available.

[balbes150]

On 6/6/2019 at 6:58 PM, hexdump said:

any idea what could be done about this? @balbes150 - can you maybe dump the spl of your tanix box (first 40kb = 8k empty plus 32k spl i think ... but maybe the few first mb would be nice too, to see if your u-boot is maybe better than mine, as mine does not allow to interrupt the boot)

My device is not running UART, so I can't check the startup log or abort the startup. I can only get into Android. If you write steps in Android, I can try to download the necessary data (to dump the necessary objects).

 

 

 

 

[hexdump]

@chwe @jernej - is the allwinner h6 using a 8250 uart and if yes, how to configure it properly like you mentioned above?

 

@jernej - i think i included the atf binary - i'm using the bl31.bin from the h6 bsp (see above) - is there anything else required? at least the uboot build did not complain about anything else (about bl31.bin it complained before). i btw. added earlyprintk, but this does not really change anything. are there any other simpler boot tests i might try, like trying to chainload u-boot.bin to itself to see if uboot can at least execute any 64bit stuff properly?

 

@balbes150 - in case you want to get the serial console working on your tx6, this (and earler posts there): https://forum.libreelec.tv/thread/17565-nightly-images-for-a64-h3-and-h6-boards/?postID=120706#post120706 might help you - in android you might simply install a terminal app, then su to root (assuming the the box is rooted like most of the tv boxes) and do a "dd if=/dev/mmcblk0 of=mmcblk0-start.dd= bs=1024k count=4" - this should dump the first 4mb of the emmc into a file  and should be enough to catch the spl and uboot i guess - this assumes that mmcblk0 is you emmc.

 

best wishes and a lot of thanks in advance - hexdump

[jernej]

16 minutes ago, hexdump said:

i think i included the atf binary - i'm using the bl31.bin from the h6 bsp (see above) - is there anything else required? at least the uboot build did not complain about anything else (about bl31.bin it complained before).

In case of Allwinner port of U-Boot, ATF (bl31.bin) gets packaged into itb file (u-boot.itb), along with U-Boot proper (u-boot.bin) and dtb file. You should just combine sunxi-spl.bin-arm32 (make sure is padded to 32K or 24K, I'm not sure ATM) and u-boot.itb.

 

BTW, I'm not sure if mainline Linux works with BSP ATF binary. Just compile latest official ATF release (mainline H6 ATF is not board specific, so it should work).

 

25 minutes ago, hexdump said:

btw. added earlyprintk, but this does not really change anything. are there any other simpler boot tests i might try, like trying to chainload u-boot.bin to itself to see if uboot can at least execute any 64bit stuff properly? 

Not sure, I don't use earlyprintk. If it's not CPU mode issue (Linux expects that it's already in 64-bit mode) it may be DT issue.

 

Anyway, I wouldn't bother with Linux at this stage. Fixing mainline DDR3 DRAM driver would help a lot with other issues.

[hexdump]

just a little update: there is now some more useful information regarding uboot for the h6 with ddr3 ram here: https://github.com/apritzel/u-boot/issues/4 (@jernej@balbes150) - a big thanks to andre for his very detailed responses!

 

best wishes - hexdump

[hexdump]

another update: meanwhile i have the box kind of booting using the libdram blob based uboot (so not redistributable), but still there is quite a bit left to be done to get it to some useful level. no progress so far on an open source dram config for ddr3 ram on h6 boxes. for more info see the github issue from the last post and this thread here: https://forum.libreelec.tv/thread/17636-tanix-tx6/?pageNo=1 ...

 

best wishes - hexdump

[jernej]

I'll get box with DDR3 probably early next week, so I'll join the party.

[hexdump]

@jernej - that is good news!

[balbes150]

Can now add an Armbian image Assembly for TX6.

 

https://forum.libreelec.tv/thread/17636-tanix-tx6/?postID=121128#post121128

[hexdump]

i played around a bit more with the h6 qplus box - i used the kernel sources from https://github.com/megous/linux which are supposed to already contain some interesting h6 patches (dvfs, thermal sensor etc.). a defconfig kernel built from those sources runs fine and i could trick it into some dummy frequency scaling (with the default voltage only) with the attached dts and patch - depending on which (i guess virtual) voltage i gave my vcccpu regulator it scaled up to 1.8ghz (1.08hgz in the attached patch) and was running well and snappy as long as i kept the load on it low, but as soon as i put some heavy load on it (i ran glmark2 with mesa software rendering, which keeps the cpu cores at 50-80%) it rebooted after some minutes. looks like there is no way around understanding what the axpdummy device in android is doing to provide some voltage regulation - in android there is frequency scaling across several values with different voltages, so there must be some kind of voltage switching possible. i at some point also added some ethernet settings and got some ethernet interface, but as @jernej already mentioned in the libreelec forum there is most probably some coding for the phy required (got errors regarding the phy as soon as i tried to do anything with the interface). the thermal sensor points in /sys/class/thermal were there, but as soon as i tried to cat their temp values i only got an "invalid argument". i expected at least them to work, as they seem to be part of the soc itself and should not really depend on the device, but maybe my assumption here is wrong. (fyi @balbes150 for all the above).

 

best wishes - hexdump

 

 

qplus-dtb-plus-opp-changes.patch sun50i-h6-qplus.dts

[hexdump]

i think i have to revert my theory from yesterday: the problem with this h6 qplus box (as with most probably many other cheap h6 tv boxes) is not the cpu voltage but pure thermal topics. i removed the board from the box and did the following test: i switched the dtb to scale up to 1.8 ghz again and pushed a cooling pack against the heatsink while running glmark2 as a test and voila: it runs through perfectly fine at 1.8 ghz. also disabling two of the four cpu cores helps - this way it runs through completely stable with 1.8 ghz on the remaining two cores just with the small heatsink of the box (but not in the box, which gives way better heat dissipation). so in the end those h6 boxes are quite promising if they get cooled properly, as you can really run them at 1.8 ghz. thermally the h6 seems to be way better than for instance the rockchip 3328 as the h6 can run at 1.8 ghz with only 1.06 to 1.16 v while the rk3328 is already in the range of 1.2 to 1.5 v to even reach 1.5 ghz - this also explains while the rockchips are running so hot and are so hard to get to even 1.5 ghz compared to for instance amlogic cpus, which seem to run around 1.0 to 1.1 v (s905/s905x) for around 1.4 to 1.5 ghz.

 

@jernej am i right, that this axpdummy regulator might simply be a dummy regulator allowing me to set the full range of voltages i need on the software side while in reality on the box the cpu simply runs with a hard coded voltage of maybe 1.06 v to reach the 1.5 ghz the box runs at maxium on android and in the case of my box even the 1.8 ghz. it still does frequency scaling, but most probably this will not help a lot on the thermal side without any real voltage scaling - i guess on android the constant hot plugging of unused cpu cores helps a bit to keep the temperature of the box acceptable. do i see it right that mainline linux does not support passive cpu cooling by dynamically disabling cpu cores? it does via dvfs, but this does not help us here, as there is most probably no voltage- (and just frequency-) scaling on those cheap h6 boxes.

 

@jernej did you receive your tx-6 meanwhile? if yes any progress or plan regarding getting ethernet working?

 

best wishes - hexdump

[jernej]

@hexdump I think axp_dummy is really just that, dummy driver. However, at some point I saw that it may call to AR100 to do voltage switching instead, but I think that's not the case here. I'm really not specialist in DVFS, so I can't answer your questions regarding that.

 

No, I didn't do much regarding PHY driver. I just researched the topic in kernel. AFAIK we will have big pain to get it mainlined. There is no other PHY in kernel which has similar initialization sequence. We'll see.

 

These days I was focused on implementing "half DQ" support in H6 DRAM driver for Tanix TX6 mini. Why would someone use that in media center oriented box is beyond me. It brings (much?) lower memory bandwitdh. I guess they really wanted to lower the price of the box, because they also used XR819 wifi. But yes, I received my TX6. I'm trying to add support for it to LE, but in the process I broke all other already supported boards. It has something to do with GPU, frequency and voltage regulator. In the process I also found regressions in AXP805 mainline driver (I didn't send patches yet).

 

P.S.: These days it's very hot here, so I'm a bit slow with all this stuff. Fortunately, next days will not be so hot.

[hexdump]

@jernej - thanks a lot for the update

 

a little update from my end: i have meanwhile removed the board from the case and added a larger passive heat sink to avoid overheating problems. with this and a 5.2 kernel built from the orange-pi-5.2 branch of https://github.com/megous/linux the thermal sensor is now working and with it the cpu cooling via d[v]fs. as a result the reboot problems due to overheating are gone: when the cpu gets too hot it will now get throttled down and that works perfectly fine even with a fixed cpu voltage only by just lowering the frequency. i can now run a make -j 4 kernel compile on the board and it is running absolutely stable - just after a while the cpu frequency will throttle down to around 800mhz due to heat - i would most probably need active cooling (fan) to keep the cpu cool enough to run at full speed if all cores are running at full load. for smaller or shorter load it runs fine and absolutely stable at 1.8 ghz.

 

there are three problems hitting me the most right now:

• both usb ports (1x 2.0 & 1x 3.0) are working fine as long as i plugin devices directly to them, but as soon as i plug in a usb-hub none of the devices plugged into the usb hub are seem by the system - anyone any idea what might be the problem here?
• the hdmi monitor currently defaults to 1024x768 - not that critical and i think i had seen it at the 1280x1024 of the monitor already with other kernels - maybe an edid detection problem, will try to set the mode on the kernel cmdline next
• the missing ethernet - as i only have two working usb ports and can't use a usb hub yet the need to use a usb ethernet uses one of the usb ports and i can't use a keyboard and mouse together while connected to the network - it would be really cool if we could get native ethernet working ...

best wishes - hexdump

[jernej]

- HDMI works fine if you use OrangePi 3 patches, which set GPIO PH7 high, to enable DDC bus.

- I'm working on ethernet phy driver, it's close to being ready, I just need to debug it

- not sure about USB hub as I don't use them

[jernej]

@hexdump With latest two patches here: https://github.com/jernejsk/linux-1/commits/ac200 ethernet now works!

 

However, this is very early work, so it contains one ugly hack in PWM driver. In order to use it, you have to enable following drivers:

CONFIG_AC200_PHY=y

CONFIG_MFD_AC200=y

CONFIG_COMMON_CLK_PWM=y

CONFIG_PWM_SUN4I=y

CONFIG_NVMEM_SUNXI_SID=y

 

and some more obvious, like I2C. Note that SID will gain H6 support only in Linux 5.3. You also need two patches from linux-next for H6 ethernet driver.

 

Now I have to clean it up, which will probably take as much time as I needed to write this.

 

P.S. eMMC doesn't work for me for some reason. But that is low on my TODO list. If you manage to fix it, please let me know.

[hexdump]

@jernej - this is an amazing news! i'll try it either tomorrow or on friday - did not have any time today and i'm not sure about tomorrow ... emmc is not working on my qplus box neither, i actually have to disable it in the dtb as otherwise the kernel hangs on boot ... maybe this is worth a try? - https://github.com/apritzel/u-boot/issues/4#issuecomment-502304665

 

best wishes and keep up your cool work! - hexdump

[hexdump]

@jernej - i did give it a try today, but it did not work - most probably there is still some patch missing or some config option. i'm using the above mentioned megous tree as base, as it already contains a lot of orangepi-3 stuff, h6 themal sensors, devfs etc. - i was able to add your patch and adjust my .config accordingly but maybe i'll retry it the next days with a bit more time. or maybe you can push your working kernel tree somewhere on github and i'll build from that. or i'll just wait a few more days until things are cleaned up a bit more.

 

once more a lof of thanks for your efforts and best wishes - hexdump