Willy Moto

I think I have to disappoint you, see here.

@DmitryS There is no opensource OpenCL driver in mesa, what you want to use is the closed source binary.
The closed source binary requires the closed source drivers; it can be installed and probably brought into working state, but it is a real PITA  since it requires the proprietary mali kernel driver first, then the closed source blobs and finally the closed source OpenCL driver. I hope I scared you enough, because that way is very scary by itself.
 
Just a side consideration: people, in general, should be very thankful for opensource drivers that make things work out of the box  and should heavily blame companies that put obstacles - like ARM does.

Thanks for the explanation. I finally unbricked it. What I figured out is that I should put a sd-card. I put it into the board, shortened contacts which MattWestB helped me to find and it booted into multitool where I choose to burn another image and now it boots into it from emmc! Thank you guys!

@Seth the HDMI disappearing is quite disappointing, since I did not tweak that part in 5.18.
 
Anyway this looks very suspicious to me:
[ 2.099836] rockchip-drm display-subsystem: [drm] Cannot find any crtc or sizes [ 2.100004] rockchip-drm display-subsystem: [drm] Cannot find any crtc or sizes  and maybe is somehow related to EDID or alike

@callegar@Willy Moto@MX10.AC2N
Ok, I double checked the cpu voltage supply and effectively it seems that in the latest device tree I pushed it way too low... The original device tree of my box said 1.375v@1.3Ghz, the voltage in mainline kernel says 1.300v@1.3Ghz and I set 1.200v@1.3Ghz. That is very good for temperatures and power consumption, but maybe it is a bit too low for stable operations.
 
I will rebuild the whole set of images, but in the meantime I updated the dtb deb package you can install that should fix issues: https://users.armbian.com/jock/rk3318/upgrade/linux-dtb-edge-rockchip64_22.08.0-trunk_arm64.deb
 

After more tests, what makes the difference is probably not the kernel (5.15 vs 5.18) but the dtb: with linux-dtb-current-rockchip64_22.08.0-trunk_arm64.deb and kernel linux-image-current-rockchip64_22.08.0-trunk_arm64.deb (5.15) the system does not boot, but with the same kernel and the former linux-dtb-current-rockchip64_22.05.0-trunk_arm64.deb the system works fine.

This looks like as ready to put it here https://github.com/armbian/build/pulls 

After some experimenting I found a way to flush the journal and maintain logs in tmpfs using /run/log/journal, and only have a softlink from /var/log/journal to /var/log.hdd/journal. Additionally the cached journals are to be cleaned up when /var/log becomes too full.
 
 I created the attached patches for armbian-truncate-logs and armbian-ramlog: armbian-truncate-logs.patcharmbian-ramlog.patch 
 
Some logic was needed in cases where the user decides to do Storage=volatile journal logging in /etc/systemd/journald.conf, or when the user or journald with Storage=persistent creates a /var/log/journal folder which will be moved to /var/log.hdd/journal and replaced by the softlink.
 
I tested stop, start, write for armbian-ramlog, and truncate-logs. They seem to work fine.

There is such 2734C chip, a google search would have confirmed that to you easily.
The chipset under the hood is an ampak AP6334 which is in turn made of a couple of broadcom chips. The wireless part is a bcm4334.
 
Probably your issue is not the dtb but the wifi chip firmware or, more in particular, the nvram /lib/firmware/brcm/brcmfmac4334-sdio.rockchip,rk3318-box.txt which is not suitable for your board setup. The wifi depends on how the board is build for important things like reference frequency, antenna setup, sideband gpio, etc... If the nvram does not specify these params correctly, it will not perform well or will not work at all.
 
The best thing you could do is mount the vendor partition of your Android firmware and search for a suitable firmware for your board or extract from the live Android system.
Tthat could be easy but could also require various steps  to get access to the partition, it depends and how the firmware is built.
 
Otherwise you could look around in google, download new nvrams for bcm4334/ap6334 and try and see if they work for you.
 
edit: BTW the wifi chip is fully supported by linux kernel and works wonderfully well on my board; when I say don't buy tv boxes if you want supported hardware I mean exactly this.
 

@Excel I've an image. Unofficial. Unsupported. unzstd it, burn it to SD, put jumper J3 in Maskrom mode, UART at 1500000.
 https://github.com/rpardini/armbian-release/releases/download/20220522c/Armbian_20220522c-rpardini_Tinkerboard_jammy_edge_5.17.9.img.zst (WRONG! That is for the TB1!)
 
UPDATE: https://github.com/rpardini/armbian-release/releases/download/20220522c/Armbian_20220522c-rpardini_Tinkerboard-2_jammy_edge_5.17.9.img.zst (correct for the TB2)
 
Good luck!
 
 
 
Sorry boss, I've all these images laying around and can't help myself. 😉
 
 
 

@jock
I have just tried to erase the eMMC, and then re-installed the latest Armbian 22.08 trunk build from scratch.
 
1) Unfortunately, it appears the latest edge Kernel 5.18.6 is unstable, at least for my TV box -- which is a H96 Max+ 4GB RAM/32GB EMMC model.
Running rk3318-config and after reboot, the system produced some sort of error similar to previous screen, as in attached (I chose unlisted for led option).
 
2) By comparison, I fell back to previous Armbian  22.05 trunk build ( 5.15.35 current kernel ), on the same TV box.
Running rk3318-config and after reboot, the system did not produce any error and running fine (I chose unlisted for led option).
 
 
I guess it's either my H96 Max+ TV box sucks, or the 5.18.6 edge Kernel is pushing too far for my hardware configuration (ie. my TV box still sucks 🤣 ).
Anyway, I fallback to the previous CSC Armbian version for now.    Thanks.
 
 

@yuzhaogoogle thanks a lot for the answer; I finally I managed to recompile the kernel v5.18 with v11 patch as-is (without the additional fix mentioned by @hexdump).
 
I removed an offending patch that was in the armbian patch set and the system is now just stable as I expected it to be; just doing the usual desktop business for a while (browsing on half dozen firefox tabs, streaming music via bluetooth, moving files via samba, a couple of terminals, ...) and keeping the device busy for a whole night resulted into perfect stability so far, clean dmesg and 662 megabytes of swap file usage (zram) out of 1gb of swap available.
 
I will look forward to contact you for a the new patchset backported to v5.18 with latest fixes, I think the forum community will be happy to test and give feedback 😉

@jock - little update: v12 of the patches is out - it is essentially v11 pus the above mentioned fixes and rebased for v5.19:
https://lore.kernel.org/lkml/20220614071650.206064-1-yuzhao@google.com/
https://patchwork.kernel.org/project/linux-mm/list/?series=650073
https://www.phoronix.com/scan.php?page=news_item&px=MGLRU-v12-For-Linux-5.19-rc
https://github.com/hexdump0815/kernel-extra-patches/tree/main/multi-gen-lru/v12
best wishes - hexdump

UPDATE!!
 
Hello, I'm pleased to announce that rk3318 CSC configuration has been accepted into mainline kernel!.
This means that next Armbian release (probably August) will provide regular kernel upgrades offered by Armbian ecosystem via normal apt upgrade command.
Until then, please stay stick to the usual manual upgrade!
 
But there is something more: new update for the rk3318/rk3328 images!
Most important changes:
Kernel upgraded to version v5.18.6 Memory clock set to 667 MHz (was 333 MHz), providing a nice boost in general, desktop and GPU performance; despite this works fine on my board I always warn you to test images first via sdcard Introduces MGLRU patches from @yuzhaogoogle (you can read about here and search google for more details), which should provide much snappier experience especially on low-memory devices You can find the images and deb packages for upgrades browsing the directory pointed on first page as usual.
 
You can visit the Armbian MGLRU topic, if you have questions about the features or kernel issues (like crash dumps which involve kswapd, for example)
 
 

Hi all.
I made a new video where I explain all the basics of working with Armbian xfce4.
This for the absolute beginners that come from Windows. But a more advanced user can maybe also learn a few things from it.
Here is the video.
Greetings,
NicoD

Well I think that a large portion of credits goes to official armbian developers too; that's a combined effort of everyone that provides good hardware and good software support of both "grateful" and "ungrateful" devices

Armbian by default boots up with user auto login. However, after sudo apt upgrade, I lost the auto login and have to enter password at every boot up.
( Armbian_21.08.0-trunk_Aw-h6-tv_focal_current_5.10.53_xfce_desktop.img)
 
For those who are interested, this is the solution I made to make it auto login again.
    edit /etc/lightdm/lightdm.conf.d/10-slick-greeter.conf, and add these two commands below
            autologin-user=yourloginusername
            autologin-user-timeout=0
    save and reboot

@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

@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!
 

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".

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.

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.

@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.

In case anyone is interested in building from mainline Armbian, here is a doc describing the steps I used.  The goal with this was to change as little as possible and document all changes so they could be reproduced.  Hopefully nothing missing/wrong, but I'll recheck everything tomorrow.  
 
 
 
Tanix TX6 with Armbian.odt
 

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