Armbian for TV box rk3328

martos · January 7, 2020

For information , with the device H96MAX H2 (not +), it don't want to start from SDcard (or usb) i flash an another android image with an another boot release (2.44 -> 2.49 )

its the same ... ( i put the serial boot log )

rk3328_4.txt

martos · January 7, 2020

with my H96MAX H2 (not +)

with the serial console (of course i try to hit "ENTER" at the begininng of the boot without succes ) , i have a login when Android is started :

rk3328_box:/

and i can go in root mode :

rk3328_box:/ $ su

rk3328_box:/ #

i have a look on the /mnt/ directory and i see the sdcar or the USB key

Can i change something to boot after in the sdcard ?

Other way is to write armbian in the eMMC in loader mode or in MaskRom mode

But i dont understand the solution to make it, if someone can help ...

hexdump · January 7, 2020

@martos - some things which come to my mind:

did you try my t9 dtb? - see: most probably it will not work as your box does not seem to boot off sd card at all
another thing worth trying is combined sd/usb booting - see this thread:
if all that does not work then you might have to flash it via usb (i think i have read that some tv boxes have the sd card connected to the wrong mmc port and are thus not sd card bootable at all) - see here and above and below it:

good luck and best wishes - hexdump

Amoren · January 8, 2020

I extracted the armbian img file(Armbian_19.11.3_Rk3328-tv_eoan_legacy_4.4.154_desktop_20191126) with the win 32 extrctor. I inserted to my h96max tvbox(rk3318) but it wont boot. any help please?

n.b if i try to updtade from the android o.s (update from locale) it says that there is no zip file on the sd card.

Thanx in advance.

hexdump · January 8, 2020

a little update regarding my rk3318 box - at my last try it was hanging at u-boot -> see:

i finally got it booting by dd'ing the u-boot from this image: xenial-minimal-rock64-0.5.15-136-arm64.img.xz from https://github.com/ayufan-rock64/linux-build/releases/tag/0.5.15 to my sd-card and afterwards dd'ing the trust.img from:

on top of it ... not really straight forward, but works at least

best wishes - hexdump

martos · January 9, 2020

Hello,

Some news of my device : i think it's hardware trouble , i compare 2 device and the sdard reader is not the same ID , i think the boot can't work so i try a physical change ...

hexdump · January 9, 2020

another little rk3318 update (see two posts up): it looks like the memory timing of that old pine64 u-boot which allowed my box to at least boot well is not really stable - from time to time it crashes even if i lower the cpu clocks to 600mhz - i tried both the 4.4 rockchip and main kernel - both are the same ... looks like i need to find some proper memory initialization for it ... does anyone know if it is possible to extract only the memory initialization part of the boot in emmc via dd and combine it with parts of a self compile u-boot - @jock - i think you did something similar for the rk3288, but you used the rockchip provided ram timing files, do you know if it would be possible to extract this part from an existing system or maybe from an android firmware image?

best wishes - hexdump

update: this is what would be available in the android firmware image:

update: i think i found out: the ddr and miniloader part is from block 64 to 16384 - i dumped those from emmc and wrote them to the sd card and the boot output is exactly the same, so looks like those files are already used - so maybe the instability is not due to the memory timing?

i might have a look at the 4.4 kernel android dtb of the box, which i think contains some memory timing settings too - lets see if this is different to the one in the t9 dtb i used ... i think for mainline we would be lost in that case as i think the memory timing part in the kernel via dtb is not implemented there yet ...

hexdump · January 10, 2020

i think i got it stable finally - i built u-boot for it myself (v2020.01) and did the following:

loaderimage --pack --uboot ./u-boot-dtb.bin uboot.img 0x200000 # loaderimage on x86
dd if=uboot.img of=/dev/sdx seek=16384

the dd of trust.img as described above is required still. booted this way the box seems to run quite stable. i guess the u-boot i used before was setting a too advanced memory timing and my self build evb-rk3328 u-boot seems to have a more conservative memory timing which is ok for the box. i'll tomorrow upload a readymade dd'able u-boot here in case someone else wants to give it a try.

i also tried to dd the spl/tpl idbloader.img and u-boot.itb too following https://github.com/u-boot/u-boot/blob/master/doc/README.rockchip but it looks the box initally boots off the emmc and only uses the u-boot on the sd-card, so the spl/tpl on the sd card were ignored.

best wishes - hexdump

hexdump · January 10, 2020

@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

martos · January 10, 2020

@hexdump

Thank's a lot , if you need help ...

hexdump · January 10, 2020

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

hexdump · January 10, 2020

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

balbes150 · January 11, 2020

11 hours ago, hexdump said:

add the allwinner h6 u-boot

You don't need to write a u-boot from H6 to RK. It is enough to write your u-boot for rk3318

hexdump · January 11, 2020

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 · January 11, 2020

If there is a u-boot in eMMC, the idbloader from eMMC is used to start from the SD card, then the u-boot control is transferred to the SD card.

Amoren · January 12, 2020

Hello, I have the h96max rk3318 box. I extracted the Armbian_19.11.3_Rk3328-tv_eoan_legacy_4.4.154_desktop_20191126 onto sd card (i rememeberd to make changes to the conf and env files) then I inserted to my box but it wont boot at all. only when i remove the sd card it reboots again to android.

Any help to boot from sd card? Thanx...

caruso · January 12, 2020

13 hours ago, Amoren said:

Hello, I have the h96max rk3318 box. I extracted the Armbian_19.11.3_Rk3328-tv_eoan_legacy_4.4.154_desktop_20191126 onto sd card (i rememeberd to make changes to the conf and env files) then I inserted to my box but it wont boot at all. only when i remove the sd card it reboots again to android.

Any help to boot from sd card? Thanx...

dding of trust.img and copy of 3318.dtb is needed also, check my description. You can execute dd command from virtual machine (i.e virtual box), linux machine, or even in terminal on the same box when it's booted to android, you must check only name of target sdcard device.

You can extract trust.img or use attached one in this thread.

Edited January 12, 2020 by caruso
dtb also needed

hexdump · January 12, 2020

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

Amoren · January 13, 2020

Hi hexdump, can you please pack all the partitions for the rk3318hmax onto one xz image?

It will help linux beginners like me... ;-)

hexdump · January 13, 2020

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

Tarzanus · January 13, 2020

That dtb does not boot on A95X Z2 device. Rk3318-t9.dtb from caruso works.

I'll try latest ubuntu image now and try to make it work as well.

I checked armbian distro before and the only real issue was that wifi and BT don't seem to work. Sound works but you have to manually select output each after each restart.

Edited January 13, 2020 by Tarzanus
PS

caruso · January 13, 2020

2 hours ago, hexdump said:
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 11.67 kB · 1 download rk3318-h96max.dtb 33.34 kB · 1 download

@hexdump Thanks for sharing, I was playing with different dtbs and sometimes I had kernel panic.

Did you managed to have working ir remote?

I was also playing with LibreElec with manual:

https://forum.libreelec.tv/thread/20813-step-by-step-tutorial-libreelec-on-h96-max-also-ir-remote-support/

and I successfully run with rk3318, by analogy (dding trust.img, removing >1.1 GHz frequencies from cpu section of dts and recompile dtb)

hexdump · January 13, 2020

@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

zero · January 14, 2020

All the hard part are done by everyone's here,,, since the last u-boot and the dtb files from hexdump are telling almost everything to the board...

I had the kernel run great on Armbian 19.11.7 image with Debian Buster 4.4.208 on its rootfs,,,

So many thanks to hexdump and everyone...

and i did some patch also on the cpu part on the dtb, for the scaling capabilities

Quote

   cpu0-opp-table {
       nvmem-cell-names = "cpu_leakage";
       opp-shared;
       compatible = "operating-points-v2";
       nvmem-cells = <0x05>;
       phandle = <0x03>;
       rockchip,leakage-voltage-sel = <0x01 0x0a 0x00 0x0b 0xfe 0x01>;
       rockchip,video-4k-freq = <0xf6180>;

       opp-408000000 {
           opp-suspend;
           opp-hz = <0x00 0x18519600>;
           opp-microvolt = <0xe7ef0 0xe7ef0 0x149970>;
           opp-microvolt-L0 = <0xe7ef0 0xe7ef0 0x149970>;
           opp-microvolt-L1 = <0xe7ef0 0xe7ef0 0x149970>;
           clock-latency-ns = <0x9c40>;
       };

       opp-600000000 {
           opp-hz = <0x00 0x23c34600>;
           opp-microvolt = <0xe7ef0 0xe7ef0 0x149970>;
           opp-microvolt-L0 = <0xe7ef0 0xe7ef0 0x149970>;
           opp-microvolt-L1 = <0xe7ef0 0xe7ef0 0x149970>;
           clock-latency-ns = <0x9c40>;
       };

       opp-816000000 {
           opp-hz = <0x00 0x30a32c00>;
           opp-microvolt = <0x100590 0x100590 0x149970>;
           opp-microvolt-L0 = <0x100590 0x100590 0x149970>;
           opp-microvolt-L1 = <0xf4240 0xf4240 0x149970>;
           clock-latency-ns = <0x9c40>;
       };

       opp-1008000000 {
           opp-hz = <0x00 0x3c14dc00>;
           opp-microvolt = <0x118c30 0x118c30 0x149970>;
           opp-microvolt-L0 = <0x118c30 0x118c30 0x149970>;
           opp-microvolt-L1 = <0x10c8e0 0x10c8e0 0x149970>;
           clock-latency-ns = <0x9c40>;
       };

       opp-1104000000 {
           opp-hz = <0x00 0x41cdb400>;
           opp-microvolt = <0x137478 0x137478 0x149970>;
           opp-microvolt-L0 = <0x137478 0x137478 0x149970>;
           opp-microvolt-L1 = <0x12b128 0x12b128 0x149970>;
           clock-latency-ns = <0x9c40>;
       };
   };

patch that i got by dumping the dtb on the original Android firmware running on my tvb...

so far so good, at least for last 3 hours, since i apply the last patch from hexdump...

Anyway my tvb is x88-pro, no much different from the h96...

and.... waiting for any newer pacth...

Tarzanus · January 14, 2020

@hexdump I only found 5.3 for RK3328.

Tarzanus · January 14, 2020

@hexdump Well, I used unified version 5.5 rc-2 now, which works. I'll see how it performs. I've noticed legacy 5.3 version had issues with graphics. Video playback was next to useless. First impression is better with this image, but I'll see later when I check it a bit more.

zero · January 15, 2020

have not try yet to run the 5.x kernel on my tvb... may will be do it soon...

and about reserved tee memory, does that really needed? since it cost about 32M of memory...?

last time i was still be able to run the system before i apply the patch from @caruso

one more question about the armbian-firmware (usualy on "/lib/firmware")

i didn't install any of it on the rootfs, does that have some further effect?

for now cpu, ethernet, usb, ir, etc (except wifi-bt) are able to works without it's installed...

alex161rus · January 20, 2020

Hey. On the Russian forum h96max 3318, people suffer. Flash memory falls off. There is still hope for LibreElec. How to start, please write a manual

hexdump · January 20, 2020

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

alex161rus · January 21, 2020

12 hours ago, hexdump said:

12 hours ago, hexdump said:

Я постараюсь отшлифовать все это немного больше в течение следующих дней

I realized. thanks.

Sign In

Armbian for TV box rk3328

Recommended Posts

martos

martos

hexdump

Amoren

hexdump

martos

hexdump

hexdump

hexdump

martos

hexdump

hexdump

balbes150

hexdump

balbes150

Amoren

caruso

hexdump

Amoren

hexdump

Tarzanus

caruso

hexdump

zero

Tarzanus

Tarzanus

zero

alex161rus

hexdump

alex161rus

Forums

My Activity Streams

Download

Store

Important Information