hexdump

@soljah - you might give this u-boot a try: and in case that works you'll then most probably need this one too: best is to read a bit around those posts in that thread too to get some other good hints best wishes and good luck - hexdump

@balbes150 - with "sound works" you mean sound over hdmi and not sound via the analog 3.5mm jack directly on the box - right? i tried the image on a s905x box and got proper sound over hdmi but nothing out of the boxes jack directly ... best wishes - hexdump

@mar0ni - yes this is normal behaviour i think as there is some inefficient memory copying happening between the gpu and the x server and there is no proper 2d acceleration (used for such window moves) around ... but i guess @JMCC can explain it in more detail ... best wishes - hexdump

if you want the dtb, you can also try the approach from from a terminal app from inside android best wishes - hexdump

@zero - btw. how did you find the emmc clk pin with an earphone? can you describe that a bit more?

@zero - welcome to the wonderful world of fake tv boxes - they are getting more and more common nowadays - you cannot really trust that you'll find in the boxes what is printed on them - the cheaper they are the more likely it is that they are fake with a hacked up android letting it look like having more ram, more emmc and a faster soc than they really have in a way, so that a normal user will not recognize it ... see my other posting about fake tv boxes here

btw. i doubt that the initially mentioned box really has 2g/16g at this price - see my other posting about fake tv boxes here - i guess it will be 1g/8g maybe even nand instead of emmc if you are unlucky - all this with a hacked up android letting it look like 2g/16g so that a normal user will not recognize it ...

just a little update on my tries to get the h96max h2 rk3328 box to boot from external media (natively it does not boot from sd card as rk3328 boxes usually do, as the sd card is connected to another mmc port than usual, which can not be booted - looks like the manufacturer did not want it to be sd card bootable ... there are some other boxes with a similar "design" or even without an sd-card slot at all) ... so far i got it booting from usb and mmc should be possible too after some more adjustments - to get there i had to combine the efforts of some other people from here: i took the u-boot extracted from the armbian image for the a5xmax from @Gergely and replaced the u-boot in the box with it using rkdeveloptool - with this it boots everything which has a proper extlinux on it (usb and in theory sd card, but that is not yet working completely) ... as the box is using a trust image i had to add the memory reservation for it to the linux dtb like for the h96max rk3318 ... the linux dtb for the box needs some more adjustment to make the sd card accessible at the "wrong" port it is connected too - there are patches for this for the a5xmax again, but i need some time to apply them to my mainline dts - so if booted the sd card is not there yet ... i'll try to polish all this a bit more during the next days (or maybe weeks) and then write down some info on how to do all this to get such boxes working with armbian too (might be interesting for @martos maybe) ... so stay tuned best wishes - hexdump

this is just a quick note that in my experience the amount of tv boxes with fake specs has grown quite a bit in the last months and that this is something to always have in mind when getting a box for a surprisingly cheap (i.e. quite a bit cheaper than usual or most of the other offerings) price - you might be lucky and it will be a bargain or you might hit one with fake specs. some examples i saw recently: a qplus 4g ram / 32g emmc ended up to be 2g ram and 16g nand, a h6 box sold as 4g ram / 32g emmc ended up as 2g ram / 16g emmc, a x96mini 2g ram / 16g emmc ended up at only 1g ram / 16g emmc, a r39 2g ram / 16g emmc with rockchip rk3229 ends up as 1g ram / 16g emmc and an allwinner h3 cpu and so on. the fake specs are not that easy to spot: in android they even fake the storage size shown in the storage settings and with a terminal installed even the "free" command tells you most of the time that the memory amount is proper. what usualy works for storage is "cat /proc/partitions" and watching for the device itself (for instance mmcblk0) - this also quickly shows you if its emmc (=mmcblk) or nand (=nand) and for memory "dmesg | grep -i mem" (do this immediately after booting android, otherwise the memory lines from the bootup might run out of the log buffer) - both of course called in a terminal app. booting one of balbes150's armbian images usually quickly shows you the real specs of the box too. good luck at not ending up with fake boxes and best wishes - hexdump p.s.: one thing to keep in mind is that allwinner h6 boxes always only can use 3g ram, even if they have 4g installed - this is a limitataion of the soc ...

@Tarzanus - my dtb is for mainline kernel, i.e. 5.4 or newer - the most rockchip images are based on the rockchip 4.4 kernel - then you most probably just have to add the reserved memory section to the dtb there @caruso - sorry, i did not look at the ir remote yet and its actually very low on my prio list

update: i think i have found another problem - as we are using the trust.img we have to unmap the trust memory area from the kernel, otherwise it will panic whenever it will try to access memory in that region. this can be done with a reserved memory region in the dtb: /* seems to be required to not touch the trust area - see: - https://forum.manjaro.org/t/rockpro64-kernel-panics-caused-by-firmware/117900 - https://lore.kernel.org/linux-arm-kernel/006d3ee0-2711-1b4e-d8cf-6a226fcad0e4@arm.com/ */ reserved-memory { #address-cells = <2>; #size-cells = <2>; ranges; tee@0x8400000 { reg = <0x0 0x8400000 0x0 0x2400000>; no-map; }; }; after this the box finally seems to run completely stable now (this might be of interest for @caruso and @Tarzanus too most probably). attached are updated mainline dts/dtb files with this inside (beware, those files is for mainline and not the 4.4 rockchip kernel). @Amoren - better wait a bit before using all this stuff as it is still quite a bit in the move. best wishes - hexdump rk3318-h96max.dts rk3318-h96max.dtb

my latest u-boot version for my rk3318 box was not completely stable in the end - attached is a new one using the lpddr3-666 ram timing instead of the ddr3-666 timing and it seems to be stable now ... the files are: 5.4.7-stb-rkc.tar.gz - precompiled kernel with an attitional kernel option stmmac.macaddr=aa:bb:cc:11:22:33 to set the ethernet mac (u-boot does not support ethernet as the support for the internal phy seems to be missing for rk3328), uboot-rk3318-h96max.img - u-boot image - see my postings from above for how to write it to the sd card, dtb/dts - mainline dtb/dts for the rk3318 board (cpu clocks up to 1.1 ghz), diff/added - my changes to mainline u-boot for the uboot-rk3318-h96max.img best wishes - hexdump 5.4.7-stb-rkc+.tar.gz uboot-rk3318-h96max.img rk3318-h96max.dtb rk3318-h96max.dts u-boot-rk3318-h96max.diff u-boot-rk3318-h96max-added.tar.gz gen-stmmac-mac-addr-on-kernel-cmdline-v5.3.patch

@jernej - just tested your latest patch: sadly no change - the value at 0x3006100 is 0x7 for both mainline u-boot and also for the libdram version ...

@jernej - would it make sense to play around with lowering this frequency even further? update: but this one was semi working too and seemed to have the higher frequency:

@jernej - interesting - i'm not aware of having changed anything - what would result in such a change, i.e. what kind of change would explain it? can only be that during testing i mixed up some defconfig files (i might have lowered the frequency set in there once for testing to 648mhz, which i think the android or libdram showed as frequency - i think it was something like 660mhz before), but as said i'm not really aware of having done anything like this ...

searching on google for "odroid n2 download" brings it up immediately (same for khadas vim3): https://wiki.odroid.com/odroid-n2/os_images/ubuntu https://docs.khadas.com/vim3/FirmwareUbuntu.html

for testing you might start with the native odroid and khadas images to see if something works at all without having to invest too much effort and if that is the case you might look into building armbian with it ...

@amirul - one thing you might try is to boot an 4.9 bsp kernel based linux image (from the odroid n2 or khadas vim3) with the dtb from the box and see how far you get and if usb is working there ... this would at least be some basic check if usb is working in any setup ...

sorry, that was i typo - i ment the rk3328 u-boot (corrected meanwhile) ... yes i think it is not needed, but my u-boot is just the u-boot part and not the idbloader part, so i suggested to write the rk3328 u-boot before to have that on sd as well although it seems to be ignored as the box seems to boot the first stage from emmc ...

@balbes150 - i think this depends on the actual box

in case anyone wants to give my self built u-boot a try with his rk3318 box, it is attached here. just download it and also get the trust.img from: then image the rk-aml-aw image from here to an sd-card, add the rockchip rk3328 u-boot for it like described at the bottom of the first post there (most probably this step is not really required, as the relevant part will be overwritten soon, but it can't be wrong). then add and reference the attached rk3318-t9-mainline.dtb (because those images are built based on mainline and not the rockchip 4.4 kernel). now run the following commands: dd if=uboot-rk3318.img of=/dev/yoursdcard seek=16384 dd if=trust.img of=/dev/yoursdcard seek=24576 and try to boot that sd card - might be interesting for @Tarzanus, maybe for others too ... good luck and best wishes - hexdump uboot-rk3318.img rk3318-t9-mainline.dtb

in case anyone (maybe @kalikopfnuss maybe others too) wants to give this approach a try on such a box or maybe even on other not yet working allwinner h6 boxes - just get the latest rk aml aw image from @balbes150 from here: und use the attached file as u-boot written via: dd if=u-boot-sunxi-with-spl-h6-noname.bin of=/dev/yoursdcarddevice bs=1024 seek=8 be aware that at least with my box it will reset for a while (even a few minutes) before it actually boots, but so far it always booted at some point in time good luck and best wishes - hexdump u-boot-sunxi-with-spl-h6-noname.bin

@martos - i'll let you know when i have something to test ...

@martos - also a little update regarding those rk3328 boxes, which do not natively boot from sd card: with all i have learned now about the rockchip boot process and u-boot stages while getting my rk3318 box running i might be able to provide you with a u-boot you could flash with the rockchip tools to the emmc and which then would check for an sd-card or maybe even usb device and boot that first if there is any - i think this would be as far as we could get with those boxes ... it will take a few days until i get to this, but stay tuned best wishes - hexdump

who knows if there will be any updates for such cheap boxes at all