Allwinner H6

[danboid]

1 hour ago, jernej said:

SPDIF is already included in base H6 DTSI file (any board can easily enable it, if present) and it will be enabled for Tanix TX6 by default in 5.17

 

Thats good news! I've got an amp with SPDIF inputs so I will have to give that a go when 5.17 arrives.

 

I ordered a 32 GB Zedo TX6 off Amazon UK but it is also using the rtl88x2bs hence no wifi (or BT) under awawas fork.

I've been very busy the last couple of days. I managed to have a quick go at getting the rtl88x2bs driver to build last night but didn't get very far and it was already too late to be messing with that. I'm going to have another go tonight.

[jernej]

1 hour ago, awawa said:

Is it active already or sound-spdif /spdif_out need to be "okey"?

If there is no status line, it's considered active. You have to set status to "okey" only when parent node sets it to "disabled". For example, sun50i-h6.dtsi has spdif node set to disabled. In sun50i-h6-tanix-tx6.dts we override status to "okay".

[jernej]

32 minutes ago, danboid said:

I ordered a 32 GB Zedo TX6 off Amazon UK but it is also using the rtl88x2bs hence no wifi (or BT) under awawas fork.

I have TX6 box with 8822BS wifi+bt too. I have patches for this wifi, meant to be upstreamed. Speed is probably not on par with out of tree driver and has locking issue (I never experienced it, but it was discovered during testing it on another wifi), but it generally works ok. Take a look here: https://github.com/jernejsk/linux-1/commits/rtw88-test2 (ignore first two patches). BT needs some more patches and FW extracted from Android image (I asked Realtek, but they are not interested in officially supporting BT on 8822BS version). I don't have those patches available anywhere currently.

[danboid]

5 hours ago, jernej said:

I have TX6 box with 8822BS wifi+bt too. I have patches for this wifi, meant to be upstreamed. Speed is probably not on par with out of tree driver and has locking issue (I never experienced it, but it was discovered during testing it on another wifi), but it generally works ok. Take a look here: https://github.com/jernejsk/linux-1/commits/rtw88-test2 (ignore first two patches). BT needs some more patches and FW extracted from Android image (I asked Realtek, but they are not interested in officially supporting BT on 8822BS version). I don't have those patches available anywhere currently.

 

 I had just returned to say that I had quick look at that otherdriver and gave up on it because it looks super ruff and targeted at Android and I noticed that the sunxi wiki links to Jernej's rtw88. Should rtw88 work with 5.15, 5.16 or 5.10? Have you tested it with any of these kernel versions Jernej?

Do you plan to release your BT patches?

[jernej]

5 hours ago, danboid said:

Should rtw88 work with 5.15, 5.16 or 5.10?

I don't remember which version was first. I guess 5.15? There is also one patch, which was merged already, so you need to dig it up from rtw88 history.

5 hours ago, danboid said:

Do you plan to release your BT patches?

As I said, I don't have them. I deleted them at one point. Anyway, it's simple, adding new variant to BT RTL driver and making sure module is reset before use (patch for this is on BT mailing list).

[PiotrO]

On 2/16/2022 at 11:29 PM, awawa said:

Had better luck using OpenVfd. The watch is working. But currently really have no idea how to include it in the build scripts.

@awawa

Since few days i'm trying to get openvfd working on tanix-tx6 in my project.

i'm on 5.17 kernel and dmesg's openvfd entires are looking like expected - but display is black.

Hw is ok as under factory android led disp. works ok.

I installed latest armbian from your git, kick systemctl start openvfd and...display is also black.

I verified LED IC on my tanix-tx6: it is fd650.

 

As you have it working + my box failing on sources build 5.17+openvfd1.4.1 nor on your armbian not with jernej's i2c with py code - i see 2 possible reasons:

-my box is using different gpio's

-my box has missing pull-ups on SDA/SCL (so wire OR not works)

 

What board version you have in your box?   

 

[awawa]

What's in the dmesg when you activate openvfd in my fork? The dmesg output is different than on 5.17? Just to be sure: did you enabled that service before running it? 5.17 introduces some breaking changes in DT for our board and as jernej noted still could have some bugs.

Settings for Tanix TX6 are generic and taken from vfd homepage https://github.com/arthur-liberman/vfd-configurations/blob/master/tanix-tx6-allwinner-h6-vfd.conf

I didn't open my box so don't know its board revision.

[PiotrO]

1 hour ago, awawa said:

What's in the dmesg when you activate openvfd in my fork? The dmesg output is different than on 5.17? Just to be sure: did you enabled that service before running it? 5.17 introduces some breaking changes in DT for our board and as jernej noted still could have some bugs.

Settings for Tanix TX6 are generic and taken from vfd homepage https://github.com/arthur-liberman/vfd-configurations/blob/master/tanix-tx6-allwinner-h6-vfd.conf

I didn't open my box so don't know its board revision.

Pls find dmesg from armbian running on my tanix-tx6:

[ 3723.481800] OpenVFD: Version: V1.4.1
[ 3723.481839] OpenVFD: vfd_gpio_clk:        #0 = 0x01; #1 = 0xE5; #2 = 0x00;
[ 3723.481857] OpenVFD: vfd_gpio_dat:        #0 = 0x01; #1 = 0xE6; #2 = 0x00;
[ 3723.481873] OpenVFD: vfd_gpio_stb:        #0 = 0x00; #1 = 0x00; #2 = 0xFF;
[ 3723.481889] OpenVFD: vfd_gpio0:        #0 = 0x00; #1 = 0x00; #2 = 0xFF;
[ 3723.481905] OpenVFD: vfd_gpio1:        #0 = 0x00; #1 = 0x00; #2 = 0xFF;
[ 3723.481921] OpenVFD: vfd_gpio2:        #0 = 0x00; #1 = 0x00; #2 = 0xFF;
[ 3723.481936] OpenVFD: vfd_gpio3:        #0 = 0x00; #1 = 0x00; #2 = 0xFF;
[ 3723.481950] OpenVFD: vfd_gpio_protocol:    #0 = 0x00; #1 = 0x00;
[ 3723.481969] OpenVFD: vfd_chars:        #0 = 0x02; #1 = 0x04; #2 = 0x03; #3 = 0x02; #4 = 0x01;
[ 3723.481992] OpenVFD: vfd_dot_bits:        #0 = 0x00; #1 = 0x01; #2 = 0x02; #3 = 0x03; #4 = 0x04; #5 = 0x05; #6 = 0x06;
[ 3723.482011] OpenVFD: vfd_display_type:    #0 = 0x01; #1 = 0x00; #2 = 0x00; #3 = 0x03;
[ 3723.482026] OpenVFD: Detected gpio chips:    300b000.pinctrl, 7022000.pinctrl.
[ 3723.482037] OpenVFD: "300b000.pinctrl" chip found.    base = 0, pin count = 256, pin = 229, offset = 229
[ 3723.482055] OpenVFD: "300b000.pinctrl" chip found.    base = 0, pin count = 256, pin = 230, offset = 230
[ 3723.482071] OpenVFD: Skipping vfd_gpio_stb evaluation (0xFF)
[ 3723.482080] OpenVFD: Skipping vfd_gpio0 evaluation (0xFF)
[ 3723.482088] OpenVFD: Skipping vfd_gpio1 evaluation (0xFF)
[ 3723.482096] OpenVFD: Skipping vfd_gpio2 evaluation (0xFF)
[ 3723.482104] OpenVFD: Skipping vfd_gpio3 evaluation (0xFF)
[ 3723.482662] OpenVFD: Select FD650 controller
[ 3723.482777] OpenVFD: SW I2C interface intialized (address = 0x0000 (N/A), MSB mode, pull-ups off)

On my box with my distro i tried multiple ways:

1. by providing all data in DT

2. by inserting openvfd.ko with params taken from https://github.com/arthur-liberman/vfd-configurations/blob/master/tanix-tx6-allwinner-h6-vfd.conf

3. by adding in /etc/modprobe.d file openvfd.conf with content like this:

# This file must be renamed to vfd.conf and placed in the /storage/.config/ folder.
#
# Tanix TX6 - Allwinner H6 configuration
#--------------------
#gpio_xxx:
# [0] 0 = &gpiochip0, 1 = &gpiochip1.
# [1] pin number
# [0] Reserved - must be 0.
options openvfd vfd_gpio_clk=1,229,0
options openvfd vfd_gpio_dat=1,230,0
options openvfd vfd_gpio_stb=0,0,0xFF
options openvfd vfd_gpio_chip_name="300b000.pinctrl"
#chars:
# < DHHMM > Order of display chars (D=dots, represented by a single char)
options openvfd vfd_chars=2,4,3,2,1
#dot_bits:
# Order of dot bits. Typical configurations:
# Display Type 0, 1 usually has Alarm, USB, Play, Pause, Col, Ethernet, Wifi dots
# Alarm = 0, USB = 1, Play = 2, Pause = 3, Col = 4, Eth = 5, Wifi = 6
# Display Type 2 usually has APPS, USB, SETUP, CARD, Col, HDMI, CVBS dots
# APPS = 0, USB = 1, SETUP = 2, CARD = 3, Col = 4, HDMI = 5, CVBS = 6
# Display Type 3 Power, LAN, Col, Low Wifi, High Wifi
# N/A = 0, N/A = 1, Power = 2, LAN = 3, Col = 4, Low Wifi = 5, High Wifi = 6
options openvfd vfd_dot_bits=0,1,2,3,4,5,6
#display_type:
# [0] - Display type.
# [1] - Reserved - must be 0..
# [2] - Flags. (bit 0 = '1' - Common Anode display)
# [3] - Controller.
options openvfd vfd_display_type=0x01,0x00,0x00,0x03

on every case i examined dmesg to make sure module loads ok.  

no matter what - display is black

 

for me most probable issue is in bus from SOC to fd650: gpio wrong lines or logic state voltages are out of working levels.

i don't believe tanix changed gpio between board versions....

but it is highly probable i.e. some Chinese manager decided to save 0.01$ by not soldering 2 pull-up resistors. or soldered resistors with way too high resistance...

thats why i'm curious what board you have?

(mine is H6-06_V1.0 2019-07-10)

 

   

[Pic55]

I just installed the latest release provied by @awawa (v2022.02.24) on my TX6-A (32G with the  XR819 wifi chipset) and it works great ! Thanks so much Awawa for your work and the sharing. However on my side chromium is not working. Did anyone tested chromium with this release ?

 

PS) Actually after posting this question I manged to install an older version of chromium that works. It's for sure not the best solution (for security reasons) but at least I'have a running chromium. For anyone having the same issue, I installed the old stable version 90.0.4430.212-1 version with the two entries:

 

apt-get install chromium-common=90.0.4430.212-1 -V

apt-get install chromium=90.0.4430.212-1 -V

[awawa]

@PiotrO Your output is identical to mine, so you are probably right about pull-up resistors. On the case I have only: Model TX6-P

@Pic55 Yes, with current chromium version there is an issue with a GPU:

[PiotrO]

12 hours ago, awawa said:

@PiotrO Your output is identical to mine, so you are probably right about pull-up resistors. On the case I have only: Model TX6-P

@Pic55 Yes, with current chromium version there is an issue with a GPU:

@awawa

thx for keeping eye on this!

i opened my box and look with oscilloscope on sda/scl pins on fd650.

-with factory android: led display works; 3.3v + every 0.5sec series of to low polarity pulses

-with yours armbian: led display black; constant 3.3v without any pulses

-with mine distro: led display black; constant 3.3v without any pulses

 

So for me it looks like:

-issue is not due missed pull-ups

-issue is because my board uses different gpio

i don't believe issue is i.e.due miss-working gpio controller as i have working i.e. wifi which uses near gpio pin228.

 

Now i see: you have tanix-tx6-p while i have tanix-tx6. This may explain: in fact we have different devices.

 

I dumped boot/system/vendor/dtbo partitions from factory Android - and i want to extract android dtb to see what gpio are used to drive fd650 on my box.

Has anybody any hint what is easiest way to do this? (playing mkdtboimg.py or...?)

  

In the meantime i want to see how population of various tanix-tx6 variants looks like.

 

Are users of tanix-tx6 may give me favour please and:

-download my distro (https://github.com/warpme/minimyth2/releases/download/v11.28.3-master-Pre-122-g6a79086179/MiniMyth2-armv8-master-11.28.3.r122-board-h6.tanix_tx6-board-s912-SD-Image.img.xz)

-burn to SD card

-if lcd display not works: telnet to box (user is root; no password) and provide me pls dmesg + possible box details  

 

thx in advance!

 

[Pic55]

@PiotrOI tried on my TX6-A (4G / 32G). The lcd doesn't work. Attanched the output of dmesg. I also tried on a TX6-P but the booting process not even finish (so I can not connect with Telnet).

DMSG_TX6-A-4G32G

[PiotrO]

1 hour ago, Pic55 said:

@PiotrOI tried on my TX6-A (4G / 32G). The lcd doesn't work. Attanched the output of dmesg. I also tried on a TX6-P but the booting process not even finish (so I can not connect with Telnet).

DMSG_TX6-A-4G32G 27.07 kB · 0 downloads

 

Pic55: many many thx!

 

May you spent more 2..3 minutes on this?

If yes - pls make sure that file minimyth.conf on partition BOOT has uncommented entry MM_LCDPROC_ENABLED='openvfd'

(probably you download SD card image variant in which this var is not set by default. i corrected this approx 12:45 CET) 

 

Re: TX6-P: did box get IP addr at all or rather i.e. hang on DHCP stage?

If it is failing on Eth - you can try with WiFi.

1. leave Eth unconnected

2. set in minimyth.conf MM_WLAN_SSID='your net' and MM_WLAN_PASS='your pass'

 

sorry dragging you with all this!  

[Pic55]

@PiotrOI did the two changes and with exactly the same SD, it boots fine on the model A and the LCD works (and finish stuck on a DB problem - see picture), with model P it gets stuck on "Loading kernel modules" with Wifi or Eth (see picture). Good luck ;-)

[Pic55]

A quick question for the gurus in the forum ;-) The Tanix TX6 H6 processor is supposed to be able to run up to 1.8 Ghz. However in Armbian the limit is 1.7Ghz.

Do you know why ? Did anyone managed to use it at 1.8 Ghz ?

[hexdump]

@Pic55 - i even have h6 boxes running at ~2 ghz (with a fan) successfully and stable - in the end it really depends on the actual box ... i think the cpu voltage on most h6 tv boxes is fixed and depends maybe a bit on the box (i think the cpu voltage is not regulated as for most other boxes and sbc's) and i think that this maybe is also the cause of the temperature differences: the higher the fixed voltage, the higher the soc can be clocked in a somewhat stable way and the hotter it runs (... and the earlier it will break most probably too)

 

best wishes - hexdump

[Pic55]

15 hours ago, hexdump said:

@Pic55 - i even have h6 boxes running at ~2 ghz (with a fan) successfully and stable - in the end it really depends on the actual box ... i think the cpu voltage on most h6 tv boxes is fixed and depends maybe a bit on the box (i think the cpu voltage is not regulated as for most other boxes and sbc's) and i think that this maybe is also the cause of the temperature differences: the higher the fixed voltage, the higher the soc can be clocked in a somewhat stable way and the hotter it runs (... and the earlier it will break most probably too)

 

best wishes - hexdump

Thanks a lot for the information @hexdump. And if I can abuse a bit more of your experience ;-) do you think the limitation I see on Armbian on the TX6 is rather due to an hardware limitation, a limit in the kernel or it's due to the dtb I use ? Just to know if it worth spending time investigating how to change the limit. Thanks

[PiotrO]

16 hours ago, Pic55 said:

@PiotrOI did the two changes and with exactly the same SD, it boots fine on the model A and the LCD works (and finish stuck on a DB problem - see picture), with model P it gets stuck on "Loading kernel modules" with Wifi or Eth (see picture). Good luck ;-)

@Pic55

great you find time to play with this.

many thx!

 

i'm really surprised about hang of tx6-p model.

ideally will be to see what logging on UART says.

Is armbian working ok on this box?

 

btw: I suspect hang is at wifi driver.

Interesting will be to

-mount sd card ROOTFS partition under Linux

-delete /rootfs-ro/lib/modules/5.17.0-rc6/kernel/drivers/net/wireless/*

-see is it booting

 

[Pic55]

4 hours ago, PiotrO said:

@Pic55

great you find time to play with this.

many thx!

 

i'm really surprised about hang of tx6-p model.

ideally will be to see what logging on UART says.

Is armbian working ok on this box?

 

btw: I suspect hang is at wifi driver.

Interesting will be to

-mount sd card ROOTFS partition under Linux

-delete /rootfs-ro/lib/modules/5.17.0-rc6/kernel/drivers/net/wireless/*

-see is it booting

 

@PiotrOI deleted the modules and that didn't change the issues on the 2 boxes. Unfortunatly connecting to the UART is a bit too complex for me ;-) But for your information the model P works great with @awawa release including the Wifi (both boxes use the same wifi chipset / XRadio XR819. I'm surprised the behaviour is different between the two, with Armbian they behave the same (and the hardware is more or less the same with the exception of the RAM size and eMMC size)

[hexdump]

@Pic55 - the possible cpu clocks are usually specified in the opp tables in the dtb, so either they only contain entries up to 1.7ghz in your dtb or the higher entries are disabled (status="disabled") or the supply voltage regulator (defined in the cpu node i think) does not go high enough for the highest opp entries in your case

[Pic55]

48 minutes ago, hexdump said:

@Pic55 - the possible cpu clocks are usually specified in the opp tables in the dtb, so either they only contain entries up to 1.7ghz in your dtb or the higher entries are disabled (status="disabled") or the supply voltage regulator (defined in the cpu node i think) does not go high enough for the highest opp entries in your case

Thanks a lot for the clarifications @hexdump, I'll try to investigate from there.

[danboid]

Awawa's build is running nicely on the H10 Play - wifi and ethernet work fine as do all 4 USB ports! Under its stock Android, only 2 of the USB ports work but all 4 work under Armbian.

 

Another nice thing about this box is the ethernet port has link and activity LEDs which is rare on these TV boxes. It is still only 100 Mb tho. It looks like it has a clock display in pictures when its turned off but its just a transparent plastic window to allow you to see its power led.

[Pic55]

@hexdumpyou were right, the problem was in the dbt and was due to a mistake in the power supply block: The regulator-vdd-cpu-gpu is set to 1.135V and the 1.8Ghz block (opp-1800000000) was requiring 1.16V. By changing that limit to 1.135V (opp-microvolt-speed0 = <0x115198 0x115198 0x124f80>;) the 1.8Ghz is now available (and seems to run well). @awawaas your build is the new reference for the TX6 maybe you can add the fix in the dtb ? It's not a major frequency improve but at least all the frequencies listed in the provided dtb are available.

[awawa]

According to linux-sunxi.org TX6 was designed for 1.5ghz. I think 1.7ghz is already too much due to very poor ventilation and I was rather considering downclocking Maybe some alternative solution could be possible like script to modifying DTB after the installation (decompiling DTB, changing voltage/max speed, compile it again).

[Pic55]

43 minutes ago, awawa said:

According to linux-sunxi.org TX6 was designed for 1.5ghz. I think 1.7ghz is already too much due to very poor ventilation and I was rather considering downclocking Maybe some alternative solution could be possible like script to modifying DTB after the installation (decompiling DTB, changing voltage/max speed, compile it again).

Actually being able to temporarely run at 1.8ghz (with the on-demand governor) enable some use cases (eg in my case web navigation, for which the system goes 1.8ghz only for short period of time). And through armbian-config you can alway define the limits between which you wish the CPU to run (if you want to keep it below the 1.8 to stay safe). However, today the dbt is buggy : the frequency is there but due to the wrong voltage it's not available) And if you remove the 1.8Ghz (or even the 1.7) it's a bit a pity for the ones requiring it (knowing that it's possible ;-) On top some users could add a better coling system. But up to you, it was just to share (as I fixed my problem ;-)

[Pic55]

It's likely a newbie question but I coudn't find the answer in the forum. @awawadid you manage to install your build on the internal eMMC ? If yes could you please share how ?

[awawa]

No, I didn't install system on eMMC. I've got some other TV boxes that are tested for my HyperHDR project as Rpi 4 replacement. Rpi doesn't have eMMC and I want to provide them equal chances (and I don't want to break them if something with eMMC goes wrong , maybe later). BTW so far Rpi4 USB3.0 handling/bandwidth is no match for them...probably tvboxes' USB3.0 drivers are inferior. CPU/Thermal handling is very tricky on H6. For example: one of Armbian patches that should improve CPU's temps is introducing massive instability in fact (it can be observed in dmesg after some time). Despite CPU temps in valid range. So now I'm very cautious when it comes to modify related things.

[MBB]

The doc I posted a few days ago in this thread on building from mainline includes a patch to fix eMMC and everything is fully documented there.  I use it and it works well.  I find these boxes are far more responsive when running from eMMC vs SD. Plus, it frees up the SD slot for use as a removable storage device.  Or, if you install something like Balana Etcher, it can even flash it's own images from a URL.  We provide our products pre-flashed to eMMC so they are ready to plug in and use.  

 

With the patch, you can boot from SD and flash eMMC using armbian-config in the usual way (basically, take the first option all the way through the menus and it will start).

[Pic55]

Thanks a lot  @awawaand @MBB for the clarifications.

[danboid]

I'm going to have to try installing to the eMMC. I have noticed it offers about twice the read speed of using the SD card slot according to hdparm. I have got this working with Manjaro on my X96 Air amlogic TV box, eMMC boot. Good to hear it works and thats cool that you can even do it over the web in you're brave enough!

 

Back to my H10-play. I tried Android again and all 4 USB ports do work. Not sure what happened last time. The build quality of the H10-play is not up to the standard of the T95 MAX, as evidenced by the constant and very audible noise and distortion on the onboard audio jack when using the default Android rom. My T95 MAX runs at just under 50 degrees whilst I've not seen the H10 run any cooler than 62 degrees. Also, on the T95 MAX I am able to power a mechanical 2.5" USB 3 disk via its onboard USB 3 port but you cannot do that on the H10-play so I'd recommend people buy the T95 boxes in most cases unless you really want the ethernet blinkenlichts or the extra 2 USB 2 ports.

 

I recently bought a rockpi4c and its great now that I have 4K output working and it booting directly off nvme. Wifi and bluetooth work too under Manjaro, I just need to rebuild the kernel with the pcie-gen2 patch now to get full disk speed. I've also got the rpi4 and the jetson nano and I've not done any proper benchmarks yet but I'm confident it will beat both notably and it has MUCH better mainline kernel support than the nano.

 

I would buy the rockpi4b instead of the 4c if I was buying another. The 4c has an extra mini displayport but it uses mini HDMI whereas the 4b just has one normal HDMI output. Beware if buying a second hand 4b that it has the SPI chip because you need that to install u-boot to so you ca boot directly off nvme.