CSC Armbian for RK322X TV Boxes


Recommended Posts

@fabiobassa thank you for replying.

I just realized that my box had only NAND but not eMMC. Such an irony!

Can I ask is there any way that I can flash partitions instead of the whole image or can I boot it from usb.

If so, can you please give me an instruction on that?

Thank you!

Link to post
Share on other sites
Donate and support the project!

5 hours ago, dale said:

@fabiobassa thank you for replying.

I just realized that my box had only NAND but not eMMC. Such an irony!

Can I ask is there any way that I can flash partitions instead of the whole image or can I boot it from usb.

If so, can you please give me an instruction on that?

Thank you!

Ah, I suspected that!

 

The big problem with NAND is that you need to keep the idbloader there, because the miniloader (which is a part of the idbloader) contains some specific bits to format the NAND the right way. Using rkdeveloptool makes things harder for NAND users, in fact the Multitool has a special way (SteP-NAND) to install things on the NAND automatically. The multitool crafts a GPT partition table and moves the armbian partition in the right position, plus it installs a rockchip u-boot and trust to make things work.

 

Doing things manually with rkdeveloptool may require some manual adjustment for the armbian image: you have to strip the bootloader from the armbian image to let the rootfs start at 0x0. Stripping away the first 0x2000 sectos (4 megabytes) from the image will do the job.

 

Here starts the code for the stepnand installation procedure: the rootfs has to be installed at sector 0x8000, then legacy u-boot is installed @0x2000 and trustos @0x4000.

 

The Multitool then does not touch the original idbloader (which is installed starting form sector 0x20 up to sector 0x2000), but since you erased it you have to restore it back with:

rkdeveloptool ul theloader.bin

 

Then you have to create a GPT partition table (that installs @0x0) with a single ext4 partition starting at 0x8000 (where you placed the rootfs).

rkdeveloptool allows to create GPT partitions directly on the NAND, but honestly I never succeed with that. Maybe you can create an empty file of 0x20 sectors, mount it as a loop device, create the GPT partition on that and then burn it using rkdeveloptool.

 

If you are not able to recreate a proper GPT partition, armbian probably won't boot; but if you did the other steps (idbloader + u-boot + trustos) properly, you can try then to burn the Multitool image (carried with the armbian image) on a usb stick, plug it into the USB OTG port and reboot the device. Hopefully it will start from USB and you will be able to properly install the image.

 

Very important: everytime you reboot, unplug and replug the power cord! Always do that, otherwise the miniloader will spit out horrible messages about the NAND and system won't boot.

Link to post
Share on other sites

Hey im having some toruble getting this to work. Multitool works fine, boots into it as it should, but when trying to flash the image, it says "No eMMC devices found" and does nothing. So im assuming mine would be a NAND, but i didint really understand what to do for those. Help would be appreciated!

Link to post
Share on other sites
8 hours ago, Dum said:

Hey im having some toruble getting this to work. Multitool works fine, boots into it as it should, but when trying to flash the image, it says "No eMMC devices found" and does nothing. So im assuming mine would be a NAND, but i didint really understand what to do for those. Help would be appreciated!

Multitool detects NAND devices and allows them to be flashed as well.

For some reason the kernel does not detect any flash memory on your board.

Is the original android image working? It may just be a defective eMMC.

 

To debug, you should go in a shell using "Drop to a bash shell" menu option. Then write the following commands to mount the FAT partition and take the dmesg log:

$ mount /dev/mmcblk0p1 /mnt
$ dmesg > /mnt/dmesg.log
$ exit

 

Finally choose "Shutdown" from menu.

Upload the dmesg.log on the forum so we can take a look into if there is something wrong, but I suspect an unusual GPIO pin configuration which can be very hard to debug.

Clear and detailed photos of the board can be helpful, along with the name of the product.

Link to post
Share on other sites

Hi @fabiobassa @jock

Thank you for your help.

Here is what I've tried so far.
1) put back again loader.
2) write legacy uboot and trust images (from bsp folder in multitool) @2000 & 4000 sectors respectively.
3) create gpt partition in rkdeveloptool. --> called rkdeveloptool --> succeeded. (1 partition system)

Quote

FIRMWARE_VER:7.0.0
MACHINE_MODEL: Leelbox
MACHINE_ID:007
MANUFACTURER:RK30SDK
MAGIC: 0x5041524B
ATAG: 0x60000800
MACHINE: 3228
CHECK_MASK: 0x80
KERNEL_IMG: 0x60408000
#RECOVER_KEY: 1,1,0,20,0
CMDLINE:console=earlycon=uart8250,mmio32,0x11030000 console=uart8250,mmio32,0x11030000,1500000n8 rw root=/dev/rknand_system rootwait rootfstype=ext4 init=/sbin/init initrd=0x62000000,0x00800000 mtdparts=rk29xxnand:-@0x00008000(system)


4) write armbian.img @8000 with rkdeveloptool (removed first 4MB in gparted or something, I'm not so sure about this)

5) plug in power cord and the monitor was up!

But I only got this 
qDx8dZW.jpg

I guess I'm so close to success.

 

Could you please guide me how to strip away first 0x2000 sectors of armbian.img? I admit that I'm pretty noob at linux thing.

Or what am I doing wrong?

Edited by dale
Link to post
Share on other sites
32 minutes ago, dale said:

Hi @fabiobassa @jock

Thank you for your help.

Here is what I've tried so far.
1) put back again loader.
2) write legacy uboot and trust images (from bsp folder in multitool) @2000 & 4000 sectors respectively.
3) create gpt partition in rkdeveloptool. --> called rkdeveloptool --> succeeded. (1 partition system)


4) write armbian.img @8000 with rkdeveloptool (removed first 4MB in gparted or something, I'm not so sure about this)

5) plug in power cord and the monitor was up!

But I only got this 
qDx8dZW.jpg

I guess I'm so close to success.

 

Could you please guide me how to strip away first 0x2000 sectors of armbian.img? I admit that I'm pretty noob at linux thing.

Or what am I doing wrong?

You did fine and I also think that you are really close to!

Something is still strange to me because your system is almost there, it gets the initramfs but not the rootfs.

 

To easily remove the first 0x2000 sectors from the image you can run the dd command on the decompressed image:

dd if=the_decompressed_input_image.img of=stripped_output_image.img bs=1M skip=4

of course change the_decompressed_input-image.img with the right input image.

 

Once the command is done, you can invoke the file command to check that the resulting stripped_output_image.img is just the ext4 rootfs partition:

file stripped_output_image.img
stripped_output_image.img: Linux rev 1.0 ext4 filesystem data, UUID=751a6e1b-6c0b-4787-892a-0c3fec92315c (needs journal recovery) (extents) (large files) (huge files)

You should also get the same UUID requested by the kernel in the error you posted above.

 

 

Link to post
Share on other sites

Hi @jock
Thanks for your kind support.
I created stripped image just as you guided but the result was the same.
Kernel kept asking about the UUID not existing.
I tried a lot with other build versions but no luck.
I thought it was about the /etc/fstab or boot/armbianenv.txt but I think I was wrong.
There must be something else that I cannot figure it out.

Link to post
Share on other sites

@dale This commonly happen when, for some reason, the kernel is not able to see the eMMC (or the NAND).

There may be a lot of reasons, the first one that pops in my mind is that you are using the mainline kernel, which has no NAND driver. You said you are using a legacy kernel so that should not be the case, but double check that you downloaded the image with legacy 4.4.194 kernel.

 

I know that it is not easy, but invoking dmesg | more from initramfs and inspecting the kernel messages is the only way to understand what is going wrong.

 

You may try to burn the Multitool on a USB stick and see if it boots from there: if this works, you should be able to flash the NAND using the automatic step-nand procedure which should put the right things in the right places.

 

Otherwise from the initramfs you can mount an USB stick to save dmesg log there and then paste it here. These commands should do the work:

mkdir -p /mnt
mount /dev/sda1 /mnt
dmesg > /mnt/dmesg.log
umount /mnt

 

Link to post
Share on other sites

I ordered another box and i got the exact same board with the exact same hardware marked R28-MXQ. the wifi chip is identified as ap6210. mainline should have a driver available right? i will also attempt to backup firmware later and the first 4MB of the emmc. i'm gonna use rkdumper. i hope it goes without a hitch. :D

 

It seems wifi chip is connected in SDIO mode. will have to do a little digging on the led config and hdmi too. hdmi audio is in i2s mode.

 

@jock @fabiobassa

Do you guys have a guide on extracting those configuration from the original firmware?

Link to post
Share on other sites

@Seth

what do you mean extract config from original firmware?
behaviour of led are defined in the dtb PLUS kernel : example I have my two leds one is just heartbeat and the other is emmc ( or cpu0 ) activity just because it remembers me a spinning hard drive. This is my PERSONAL approach in the dtb just an example
 

gpio-leds {
		compatible = "gpio-leds";
		pinctrl-names = "default";
		pinctrl-0 = <0x75>;

		blue {
			gpios = <0x3f 0x7 0x1>;
			label = "blue";
			linux,default-trigger = "timer";
			default-state = "off";
		};

		red {
			gpios = <0x6e 0x15 0x1>;
			label = "red";
			linux,default-trigger = "cpu0";
			default-state = "off";
		};


Regarding hdmi it should work out of the box

as @hexdump said the original dtb would be great help

Link to post
Share on other sites
5 hours ago, Seth said:

I ordered another box and i got the exact same board with the exact same hardware marked R28-MXQ. the wifi chip is identified as ap6210. mainline should have a driver available right? i will also attempt to backup firmware later and the first 4MB of the emmc. i'm gonna use rkdumper. i hope it goes without a hitch. :D

 

It seems wifi chip is connected in SDIO mode. will have to do a little digging on the led config and hdmi too. hdmi audio is in i2s mode.

 

@jock @fabiobassa

Do you guys have a guide on extracting those configuration from the original firmware?

ap6210 is a package of two broadcom chips, don't know exactly which ones but dmesg will give some hints about the firmware and nvram you need.

The wlan driver is brcmfmac and is both in legacy and mainline kernel and works fine so far.

 

Link to post
Share on other sites

@Seth

no worries, feel free to ask as many info as we are able to explain

Consider that dtb isn't related only to rockchip so studying, understanding them will help ALSO with rockchip but not only with them ( also with allwinner, amlogic )
The kernels @jock compiled ( both legacy and main) are already optimized for having all out of the box in MOST cases but of course new devilish boxes can appear on market :D:rolleyes:
I am sure your box will work

 

Link to post
Share on other sites

@hexdump

thanks. i managed to get device tree from android box. nice guide.

 

@jock

i got the dmesg, will upload tomorrow, i need some sleep. :D

 

@fabiobassa

box is working fine as headless super router at the moment, running soho dhcp, dns server/cache, squid transparent proxy/cache. will slowly try to improve it as i learn more about these little things. i remember, i used to install debian/pfsense on old p3 and p4 boards just to get a reliable mega router/firewall and run squid and squidguard on em. now i can do that at the fraction of the size and power consumption. Just when i thought those boxes couldn't get any wierder. :D

 

I found an s9012.ko in /lib/modules folder btw.

Link to post
Share on other sites

@Seth

 

Quote

I found an s9012.ko in /lib/modules folder btw.


android producer put in modules folder usually 3 or 4 drivers for wifi they mostly use ( s9012, ssv6051 etc etc)
s9012 it seems to me veryyy old wifi sdio

I use my box for voip ( asterisk) , vpn ( tinc ) , domotic, pihole dns catcher and I love it and yes I agree with you, good power less consumtion

Link to post
Share on other sites
14 hours ago, dale said:

@jock hi jock,

Thank you for helping me so far.

I tried to boot multitool from usb drive but no luck. Mount usb device and write log into it --> no luck.

Here is screenshot for what I did.

tekSeT07_o.jpg

uhm... from what I see from the screenshot:

- mount command does not want to work despite the right syntax, that's as stupid as it could be

- more command is not available in initramfs; my fault, I tought it would be there, it makes the dmesg output more manageable

- blkid command output is useful: it does not tell of any partitions on rknand0, maybe the GPT partition table is not the right one because it does not tell any partition UUID

 

In the meantime I tried to replicate some of your setup on a box of mine, and I found a possible bug in the Multitool, preventing it to boot from USB. I was quite sure it was working in the past but maybe something happened. I investigate and I will tell you more soon.

In the meantime, did you try to put an armbian image on a USB stick and try to boot?

 

PS: sorry for all these trials and errors, boxes without sdcard slto are rare and NAND are bad b*****s, so that's a very bad combination. We have none of them to do proper tests and bring up decent support, so please be patient -_-

Link to post
Share on other sites

@dale Definitely the Multitool was not behaving correctly when used from USB - I was pretty sure someone else in the past used it successfully, but probably he/she made some modifications to let it boot and work correctly.

Anyway I have uploaded a new fixed version of the Multitool. Download it again from the first page.

 

Follow the instructions to install into NAND you find in the first page, of course burn the Multitool on the USB stick, then boot with the USB stick in the USB OTG port of the box and let's see if it finally works!

 

PS: if the Multitool still refuses to load, follow the suggestion to burn the Armbian legacy image directly on the USB stick and let's see if it at least works (BTW it should work, it has been tested in the past)

Link to post
Share on other sites

Hi @jock

Thank you for the hints and for your all hard work.

Finally I managed to boot the system from NAND.

After a bit digging up, I tried this gpt partition table config and bingo!

I'm happy now despite the cpu temp is a little weird for me.

 

Quote

uuid:system=330e0ed9-50e9-4158-b032-4840af9685d4
CMDLINE:mtdparts=rk29xxnand:-@0x00008000(system:grow)

 

b8vHRaG.png

 

Secondly, booting Armbian from USB also works like a charm. But unfortunately, Multitiool did not have that luck. I guess Multitool would require more investigate from you. I'd like to know the reason for that, too

 

Once again thank you and @fabiobassa as well.

 

Link to post
Share on other sites

@Seth I will take a look to the dtb, expecially for the led configuration (maybe yours is a special one)

 

@dale Congrats, finally you made it! Need to understand why the multitool is not booting although, on my box it boots fine from USB. May I ask what happens exactly when you power on the box with the USB stick into?

The system hangs and you see a black screen? The led is blinking or is steady on/off? Do armbian boots instead like no USB stick is in the port at all?

edit: about the temps, yes they are a bit weird. Some chips reports rather high temperatures, I have a board with rk3229 that is idling at 82°C and easily reaches 90°C, but never had any lock-up and the heatspreader is just regularly warm.

Link to post
Share on other sites

Hi @jock,

Play around with rockchip tv box is always such an interesting thing.

I tried to boot off usb drive with 3 types of image:

1) same with image flashed into NAND (buster legacy) --> Armbian could boot from usb drive

2) focal legacy image --> could not boot armbian just ignored the usb drive and booted right from NAND

3) Multiboot --> could not boot, armbian just ignored the usb drive and booted right from NAND

 

Link to post
Share on other sites

@dale

 

ty so much for sharing your experiments. This helps  @jock and me to better understand behaviour of some boxes that haven't sd card reader , ddr3 and nand.
The u-boot legacy we realized have some difficult to proper initialize the usb: it's random failure so quite difficult to debug, maybe jock will investigate further or/and rewrite some pieces of code to proper start USB subsystem but this requires it's time. For now we are glad your board is functional

@Seth

ty for sharing the dtb and your experiences, too

Link to post
Share on other sites

Hi,

In the mean time @jock is investigating the problem with legacy uboot, I'm happy with using my box now.

After setting options in rk322x-config with led-conf1, I got the solid blue led on. It's not quite comfortable at night time. I would like to ask if there's a way that I can disable the led? Thank you

Link to post
Share on other sites
On 2/18/2021 at 6:15 PM, dale said:

Hi,

In the mean time @jock is investigating the problem with legacy uboot, I'm happy with using my box now.

After setting options in rk322x-config with led-conf1, I got the solid blue led on. It's not quite comfortable at night time. I would like to ask if there's a way that I can disable the led? Thank you

Hello, I investigated quite a bit the u-boot issue, but it is not an immediately solvable issue, so it has to wait for the time being.

About the leds, they can be controlled using the sysfs interface available in /sys/class/leds.

 

In particular, you can do cat /sys/class/leds/working/trigger that will tell you a list of acceptable options, and use echo value > /sys/class/leds/working/trigger (change value with something you got from the list) to change the led behaviour.

Link to post
Share on other sites
On 2/15/2021 at 4:55 AM, Seth said:

@dale

congrats for successful setup!

 

Anyway, i got a hold of the device tree copy from android as well as dmesg.

I figured, i'm gonna follow @hexdump's instructions. hope it all works out fine.

device-tree-copy.tar.gzUnavailable dmesg_android.txtUnavailable

 

Hello @Seth, I inspected your device tree and it looks like you have a led which is connected to a GPIO pin which is different from the two existing configurations. I can arrange a device tree overlay if you're interested in getting support for the second led too.

Link to post
Share on other sites