• Content Count

  • Joined

  • Last visited

1 Follower

About hexdump

  • Rank
    Elite member

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. 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
  2. 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
  3. 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
  4. 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
  5. 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
  6. 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
  7. @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)
  8. @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
  9. 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
  10. @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
  11. 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 ...
  12. it is 3gb except for the eachlink h6 mini with its strange memory setup - this 4gb advertising thing is simply marketing i guess: most of those boxes really have 4gb, just that it is not useable it would be interesting if those 3gb are a hard limit of the hardware or if there are any ways to maybe move it to 3.5gb ... i know the h6 has 32bit memory addressing, but i think on other even full 32bit systems one can address close to 4gb ...
  13. there is no working ssv6051 driver for mainline and most probably there will never be one ...
  14. @jernej - already tested and responded - it fixes the problem i'm too tired tonight and too slow to review them as well - maybe you can have a look?
  15. @jernej - sure will do - thanks for the hint - did not check my email yet ... not sure if i'll get to it today, but during the next days for sure ... in case the tests would be ok, shall i then respond with tested-by to all four of them?