hexdump
-
Posts
457 -
Joined
-
Last visited
Content Type
Forums
Store
Crowdfunding
Applications
Events
Raffles
Community Map
Posts posted by hexdump
-
-
its not a trivial problem (i usually get serial consoles working easily) - i tried close to all speeds etc. ... its either that the connectors are not for the serial console (but they really look like: 4 connectors, one is mass, another seems to be vcc and the other two in the middle go directly to the soc chip), there are maybe some electrical components missing to make it work properly or u-boot output is somehow scrambled (never seen something like this so far) ... these are at least my guesses ...
best wishes - 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 ...
-
-
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
-
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
-
-
@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 0xso 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
Since Tanix TX6 can boot from the SD card
in Allwinner CPU Boxes
Posted
hi @balbes150, sure there is still a lot of interest in h6 tv box support - they are easily available, they are usually quite cheap (around 30+ euro for 4/32g), their performance is very good (4x1.8ghz if cooled well) and the h6 mainline support including panfrost is progressing very well ...
as a base i would recommend the megous tree as it already has a lot of h6 patches not yet in mainline in it (it has v5.4 and v5.5 branches) -> https://github.com/megous/linux/tree/orange-pi-5.4
i have some patches on top of it to add tv box ethernet support and to fake the opp tables and gpu power to give access to all cpu frequencies and the gpu as there is no software controllable power in tv boxes (like for instance in the orange pi 3) - i'll recheck them against 5.4 in the next days and upload some updated ones here
other ressources of interest:
best wishes - hexdump