Jump to content

hexdump

Members
  • Posts

    457
  • Joined

  • Last visited

Posts posted by hexdump

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

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

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

  4. 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):

    best wishes - hexdump

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

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

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

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

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

     

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

     

     

×
×
  • Create New...

Important Information

Terms of Use - Privacy Policy - Guidelines