hexdump

this box i would not recommend: one i got was in the end 2+16g instead of the promised 4+32g - furthermore the allwinner h6 u-boot is not booting it (maybe some new memory timing issues - the cpu is a h6 for sure, i checked) and i was not able to get a serial console working on it - there are connection points, which look very much like serial, but i was only able to get garbage from it ... @jernej - there was someone on the libreelec forum, who had problems too with another box not booting well due to probably memory timing issues - do you have any idea of how to potentially solve this? do you maybe have an idea what might be wrong with the serial console? i tried all possible combinations of serial settings, but only get garbage on boot and without working serial output it is hard to debug the boot problems ... best wishes - hexdump

@fabiobassa - thanks a lot for taking the time to write all this down in such a detailed way! best wishes - hexdump

for the eachlink it works, but of course i can't say for your device - if i remember correctly the gbit ethernet should in theory even be simpler (as not needing extra ac200 handling), but i might be wrong ... a very well maintained allwinner h6 kernel can also be found at https://github.com/megous/linux/tree/orange-pi-4.14 best wishes and good luck - hexdump

as @fabiobassa seems to have never created its own rk3229 thread, i'll just add some information sources regarding this topic here in case others want to continue working on it (i myself do not have any rk3229 device anymore): https://github.com/jhswartz/rk3229.git https://forum.freaktab.com/forum/tv-player-support/rockchip-based-tv-players/rk3229-devices/firmware-roms-tools-bg/672259-debian-on-rk3229-is-it-possible/page4 https://mxqproject.com/rockchip-rk3229-linux-debian-distro-now-running/ best wishes - hexdump

see here: best wishes - hexdump

ok - so, maybe a flaw in the hardware design of this specific box then ...

@PiotrO - btw. has the hdmi problem been fixed meanwhile or is there still the video=HDMI-A-1:e kernel cmdline option required on the eachlink h6 mini? if it is fixed, which patch or commit fixed it in case you know it? a lot of thanks in advance and best wishes - hexdump

cool - happy to hear that ...

hi @PiotrO attached is my eachlink dtb, from which you can see how the gpu is powered in my case - i think the trick was to make the regulator powering the gpu a fixed one (its a while ago meanwhile since i did this) ... good luck - hexdump sun50i-h6-eachlink-h6mini.dts

i doubt that there is really a power problem with the t720 gpu, as i am able to use it with the mali fbdev blob successfully on an eachlink h6 - using gl4es and LIBGL_FB=3 mode as described here: https://github.com/ptitSeb/gl4es/issues/119 best wishes - hexdump

@MarekBelisko: can you please be a bit more specific what kind of resistor you had to solder where? a lot of thanks in advance - hexdump

@IvMa - rk3318 is not really supprted - see

@fabiobassa - i agree with @jock - it would be best to create a new thread, this way all rk3229 related info is at one place and easy to find ...

hi @fabiobassa - it might be good to write down your information how to get it working on rk3229 either here or maybe make a new thread for the rk3229. this way the information would be publicly available and others might join your effort or try it out. best wishes - hexdump

i'll have a look, but it might take a while ... i'm actually a bit surprised, that it does not work anymore as i do not really expect a lot of changes in this rockchip linux 4.4 tree affecting the dtbs ... maybe double check, that the new kernel has all the required kernel modules the old working one had

i guess that the drivers for the cam are maybe not part of the default armbian kernel - so you might have to compile your own kernel with them included. good luck and best wishes - hexdump

wasn't the a5x max+ the box, which cannot boot from sd, as the sd-card is connected to the wrong emmc port for that? - you may search the rk3328 tv box thread for how to flash it via usb connection best wishes - hexdump

a short update on my rk3318 tv box (h96 max rk3318 2/16G) excursion in short: simply avoid those boxes in detail: i tried to boot armbian rk3288 tv box & rock64 images, the original rock64 image and the libre ROC-RK3328-CC image - none of them worked ... then i tried to get into maskrom mode of the box, tried all the test points on the board but none worked, the heavy way of zeroing the emmc worked of course and i'm in mask rom mode now and can boot from sd card without any interference from the installed loader on emmc - i tried to boot the above mentioned images again: no way (with different error scenarios, but non of them really looking promising), i built atf and u-boot from sources too, but this failed as well - some other experiments failed too - all in all i do not see any way right now to get linux booted in an easy way on it ... besides that the rk3318 hardware seems to be way lower speced than rk3328: on android the cpu frequency scaling only went up to 1.1ghz and there seemed to be only two mali pp cores enabled (just like on the rk3328) - so no gain at all of the rk3318 over the rk3328 - in the end better stick to rk3328 boxes instead trying your luck with rk3318 ones ... best wishes - hexdump

does anyone have armbian successfully running on a tv box with a rk3318 cpu? in theory one might guess, that it is very close to a rk3328 cpu (maybe like s905w to s905x for amlogic) - looking back in this thread i found the postings from @serat with a rk3318 box h96 max 4/64G which hangs in u-boot/atf. i now also got my hands on a 2/16G version of that box and it hangs too in u-boot/atf - it gets one line further than serat's at least my serial output looks like: ... Load uboot, ReadLba = 2000 Load OK, addr=0x200000, size=0xa3cb8 RunBL31 0x10000 NOTICE: BL31: v1.3(debug):f947c7e NOTICE: BL31: Built : 12:09:31, Aug 30 2018 NOTICE: BL31:Rockchip release version: v1.3 INFO: ARM GICv2 driver initialized INFO: Using rkfiq sec cpu_context! INFO: boot cpu mask: 1 INFO: plat_rockchip_pmu_init: pd status 0x so looks like some debugging in atf and/or u-boot might be required ... does anyone already have an idea before i start experimenting? update: i just discovered (again within this thread) that @sekarpdkt does successfully run armbian on the 4/32G version of this box ... i'm confused - @sekarpdkt - can you maybe post your u-boot output somewhere on a pastebin or similar and link it here in case you have a serial console connected to your box? best wishes - hexdump

i am getting the same error on the megous 5.2 tree, but i must admin that i never used this scaling_setspeed functionality yet ... frequency scaling as such is working well though: root@eachlink:~# cat /sys/devices/system/cpu/cpufreq/policy0/stats/time_in_state 480000 14726 720000 231 816000 96 888000 120 1080000 458 1320000 136 1488000 149 1800000 3333

@PiotrO - with megous 5.2 tree i have a normal /sys/devices/cpu/cpu0/cpufreq and i can see all the frequencies (up to 1.8ghz is possible) i have hacked the voltage for into the h6 dtsi and thermal throttling is working perfectly well too as long as there is enough airflow so that just reducing the frequency can cool the cpu enough down (as there is no voltage scaling, which usually reduces heat the most)

@PiotrO - did you add a supply to your cpu too? - like https://github.com/megous/linux/blob/orange-pi-5.1/arch/arm64/boot/dts/allwinner/sun50i-h6-orangepi-3.dts#L122 on the h6 tv boxes this is getting a bit tricky as they do not have a real regulator for the cpu voltage - you might have a look at my hack in the patch in the link below: see vcccpu (as some kind of dummy regulator) in the dts and the hacked opp tables in the h6 dtsi to allow this single voltage for all frequencies - but this is just a hack for now ... on the megous 5.2 kernel both the temp sensor and cpufreq are working well this way. best wishes - hexdump

i just posted the libretech u-boot which works well for me in the thread linked in the post above this one - maybe just give that one a try best wishes - hexdump

@utgf - maybe try the attached u-boot.bin (after gunzipping it) - if that does not work, then maybe do a printenv on the legacy u-boot prompt - maybe it uses another address (your should find some start address in there) best wishes - hexdump u-boot.bin-libretech-cc.gz

yes 5.x works as well with other dtbs (i posted some for t9 and mx10 a bit up), but to be on the safe side better stay with 4.4 for now - if you are familiar with linux and arm etc. you may try 5.x - for me on the t9 it runs a bit less stable (have to clock it up to 1.2ghz only) - might be related to memory timing, will have to look closer at it at some point in time ...