hexdump
-
Posts
457 -
Joined
-
Last visited
Content Type
Forums
Store
Crowdfunding
Applications
Events
Raffles
Community Map
Posts posted by hexdump
-
-
i tried the 5.2.8 dtb, but this is not the problem - no output on hdmi neither. on my other qplus box hdmi out works fine with 5.3, so the problem seems to be specific to the eachlink box. so looks like there is no real way around some kernel bisecting to find out which commit is causing this ...
-
by just putting the above lines into your s905_autoboot.cmd and creating a fresh s905_autoboot from it. then it will on boot start the mainline u-boot instead of the kernel. and you need a working extlinux/extlinux.conf file then which tells the mainline what to do.
good luck - hexdump
-
you might try to get to the u-boot prompt by pressing a key around when it is as "Hit any key to stop autoboot: " (try it several times, as the timing for it might be very short), but the chance that this will work is very low as on any rockchip box i have seen so far the possible to interrupt had been disabled internally. if should get there, then there might be a chance to boot linux by hand initially.
best wishes - hexdump
-
i can confirm this: just built a megous 5.3.0-rc3 tree and i'm not getting any signal from hdmi on my eachlink anymore - 5.2.8 works fine ... looks like its time for some kernel bisecting ...
-
just in case someone else runs into this problem too: i had the same error - looks like some checksum or magic number is now different than the one used for the .zip file in /boot of the images usually selected in the android update app ... luckily the old toothpick method still works fine: turn off the box, put the sd card with the armbian image into the sd card slot, but a toothpick (nothing metallic) into the audio out and hit the switch inside (be careful, it should be possible to feel when you click it), keep it pressed while you plug in the box power, keep it like this until the initial sceen logo gets black again and then release the toothpick - afterwards it should boot into armbian normally ...
best wishes - hexdump
-
booting with usb and mmc does not make sense, as the boot does not get far enough that this would matter - looking at a normal rk3328 boot log like https://github.com/Kwiboo/linux-rockchip/issues/14#issuecomment-308640444 it looks like the boot is failing even before loding the real u-boot - there is no real chance to get this working until someone adds support for this hardware to atf/u-boot i guess
can you please put up the serial boot log when booting android on this box to pastebin.com and link it here or attach the boot log here?
best wishes - hexdump
-
your are right with your assumption: it does not yet read the dtb or boot the kernel - it hangs in the early stages of uboot already. i'm not sure how well the rk3318 is already supported by the uboot used in the armbian image (or by mainline uboot at all). you might give libreelec a try to see if maybe an image there boots any further. if also that does not help, then you'll most probably have to wait until there is better support for your box in uboot.
best wishes - hexdump
-
i was looking into this a while ago for a s905w tv box and found out, that a lot of memory seems to be blocked already by legacy u-boot etc. (about 120m) and you cannot get it back by changes on linux kernel side. what helps is to chainload mainline u-boot (just build the libretech-cc u-boot from 2019.07 and use the resulting u-boot.bin):
fatload mmc 0 0x01000000 u-boot.bin
go 0x01000000in legacy u-boot and then you can use regular boot.scr or extlinux to boot further from there using the chainloaded u-boot just booted.
good luck and best wishes - hexdump
-
there seems to be a dtb for this box in mainline now ... https://github.com/torvalds/linux/blob/master/arch/arm64/boot/dts/rockchip/rk3399-hugsun-x99.dts
-
@wdtz - there is no driver for ssv6051 as there exists no driver source for it - you'll need usb wifi and/or bluetooth
update: just discovered this: https://github.com/chewitt/ssv6051 - but i guess this will not work in mainline, but it might be worth a try ... @chewitt - any comment if this is useable for malinline as well?
-
@jernej - thanks a lot for all this information, it helped me a lot ... i now have my vcvrack opengl app running in x11 (with the normal modesetting xorg server) with opengl being rendered by the mali fbdev blob via gl4es and LIBGL_FB=3 hack. it is very slow due to the extra memory copying, but very useable in my case: the ui now gets rendered by the gpu and the cpu is free for doing audio stuff. some more details are here: https://github.com/ptitSeb/gl4es/issues/119
i'll write down some more about all this and put up my latest dtb with the gpu stuff here over the weekend.
a lot of thanks and best wishes - hexdump
-
@jernej - which mali gpu driver(s) are you using? i think for panfrost you said that the megous tree maybe already has everything, but i think panfrost is not really useable at all right now on the t720 according to the panfrost irc - so lets look at the mali blobs: which driver are you using for this - i guess this one? - https://github.com/jernejsk/mali-midgard - if yes, which branch of it? and which blobs are you using, i guess this one? - https://github.com/jernejsk/H6-mali-userspace - is this the fbdev driver or the wayland one?
i'm thinking if it is maybe possible to use gl4es with the LIBGL_FB=3 option to run opengl apps even on the h6 in x11 with mali hw rendering this way - a simple proof of concept of the same setup on an amlogic s905w tv box looks very promising (https://github.com/ptitSeb/gl4es/issues/119). it will most probably not be very fast, but at least the opengl ui will be rendered by the gpu and not the cpu, which is a big progress already for my use case (www.vcvrack.com).
a lot of thanks in advance and best wishes - hexdump
-
there is no need to hurry - enjoy your vacation @balbes150
-
just in case someone else would like to play around with mainline on rk3328 tv boxes: i have created dts files for the t9 and the mx10 rk3328 tv boxes, which work with mainline - you can either try the dtb files or drop the dts files into this tree: https://github.com/ayufan-rock64/linux-mainline-kernel.git plus apply the attached patch to build them from source. for me it works quite well, but its not deeply tested yet and not all hardware supported by the 4.4 kernels will be supported by mainline most probably. i think one or the other should work for most rk3328 tv boxes where the corresponding 4.4 dtb's work with the 4.4 kernels. @balbes150 - maybe they are interesting for you to include into future rk3328 images?
best wishes - hexdump
rk3328-t9-mainline.dtb rk3328-mx10-mainline.dts rk3328-mx10-mainline.dtb mx10-t9-mainline.patch rk3328-t9-mainline.dts
-
@PiotrO - i think the original kernel (3.x) is too old for a dtb on allwinner - they had their own thing similar to dtb back then. i think @jernej is more familiar with this and i think he even extracted something like this from the image of the box - maybe he can put it up here too if possible?
best wishes - hexdump
-
-
no - for the rockchip rk3229 there is no real support in the open source world
best wishes - hexdump
-
@PiotrO - for the frequency scaling there two things needed:
- the hardware on tv boxes (or maybe their current support) does not support a changable voltage for the cpu - you only have one fixed voltage and you'll have to change the ranges of all opp speeds you want to support to include this one voltage (opp-table in sun50i-h6.dtsi)
- i think you need to create (vcccpu) and attach a cpu-supply voltage regulator (&cpu0 section) to make it work
have a look at my qplus and eachlink-h6mini dtbs in the patch i attached above. this should get you forward i guess.
on my eachlink h6 mini (board revision v1.2) i have to add video=HDMI-A-1:e to get hdmi output at all. if you have an eachlink too, it might be interesting if you get something on hdmi without it.
what gpu node in the dtb are you using for panfrost?
best wishes and good luck - hexdump
-
@PiotrO - maybe first test if there is any general problem with the tx6 mini by using the linux-megous tree (which has a lot h6 stuff in it already - it is mentioned in my post above) plus the config and the patch i attached above - this has been tested to work well and reliable on 3 different h6 tv boxes here. if this works, then maybe trying to get it working closer to mainline might be worth a try, but mainline is missing for instance frequency scaling so you'll end up at 900mhz and there is no thermal control as the thermal sensor is missing too.
best wishes - hexdump
-
-
is this on wayland or x11? i'm asking as i though panfrost is not running that well with x11 and your screenshot looks a bit like x11 ... would be nice if panfrost made that much progress, that something like this is possible now.
can you maybe summarize you experience with current panfrost - is it mostly working or mostly not working?
a lot of thanks in advance and best wishes - hexdump
-
@jernej - unplugging and replugging the hdmi cable did not help - looks like "video=HDMI-A-1:e" is a must for this box for now. thanks for the info regarding u-boot ethernet - will have a look at this during the next days (setting a fixed mac via setenv ethaddr aa:bb:cc:... in u-boot works fine for now). is there actually an audio driver for the different audio outputs (analog, spdif and hdmi) in the works or existing? i would especially be interested in the analog out. the nice thing is that the h6 boards have a mali chip, which is on the radar of the panfrost team too ...
the system is now running very well, snappy and stable. with the little heat sink and the fan it still throttles a bit when i put all cores to full load, but it still remains at the higher clock speeds then. i changed the thermal tripping points to 85/90/100 for now - btw. at least in the megous code there is a bug in the third thermal trip point - it is set to 1000, which i guess is a bit too high
(i think it is originally coming from a patch from icenowy)
at the end of the day two pictures of my current cooling hack: i used a 5mm thick piece of thermal conducting stuff (the green thing on the left of the first picture) a bit smaller than the cpu to get the heat sink high enough to not touch anything else on the board. then i put the heat sink on top and fixated it a bit with some rubber bands. at the end i put a small fan on top with some tape and connected it to a usb port. not really nice, but works quite well ...
best wishes and once more a lot of thanks to jernej for his support - hexdump
p.s. - attached at the very end is also my current kernel config and my current patch against the orange-pi-5.2 branch of https://github.com/megous/linux
config.ah6-5.2.1-meg-ah6+ h6-tv-box-eth-qplus-eachlink.patch
-
no "video=HDMI-A-1:e" is still required - looks like it is needed for this box to get hdmi working at all ...
regarding u-boot ethernet: so i simply define this alias there (and then the same in the linux kernel)? i'll have to check if there was even ethernet defined in u-boot. i remember u-boot output saying ethernet not found ... and i guess i cannot simply take over the ethernet dtb section from the kernel to u-boot as i guess all the ac200 magic is missing there - right or wrong?
-
:e is "output forced to on" according to https://wiki.archlinux.org/index.php/kernel_mode_setting#Forcing_modes
ok - will try the ddc-en-gpios now ...
update: mission accomplished - with ddc-en-gpios i get the full resolution even without edid forcing as you said - very nice! ... this box is a really nice system now ... next is to get the little fan i have laying around here working and to put it on the heat sink i put onto the cpu, so that i can hopefully run a make -j 4 kernel build with 1.8ghz on all 4 cores without throttling
@jernej - is there any other way to set a fixed eth mac besides setting it in u-boot? right now i'm getting a random new one on each boot ... and besides that: a big thank you for your support in getting this going that far!
@balbes150 - i think the h6 tv boxes now are really getting ready for some first armbian test builds
Since Tanix TX6 can boot from the SD card
in Allwinner CPU Boxes
Posted
@jernej - bisecting in progress - 14 rounds, so it will take a while