CSC Armbian for RK322x TV box boards

[im_chc]

On 12/1/2022 at 2:03 AM, jock said:

But from the photos I see that your stick has a SPI flash memory.

It has never been tested and I don't think any image could even boot there because both u-boot and kernel must be aware of that hardware, and in current images they aren't.

Hi @jock, it's been a while...I know...😅

Correct me if I'm wrong, if I use an SD card drive for the dongle, does that mean that I can use a uboot and kernel that supports SD cards to boot it up?

I mean, just to install uboot and kernel and the distribution to the SD card, ignoring the SPI storage.

 

But there is one more problem, the dongle has only one usb port, and after I plugged in a card drive, there will be no free usb port left for power.

Do I need some special cables like those that has one single male connector at one end, and one male connector + one female connector on the other?

Edited July 5, 2023 by im_chc
tag recipient's account

[mcs]

hello @fabiobassa I did jump start on NAND burned my jammy_current image with etcher to usb stick and inserted it to otg port it's not booting but multitool still works.

I did dmesg in bash shell in multitool and it detects my usb stick...

[mcs]

@jock I want to run armbian on usb and later on to ssd (usb to sata)

[mcs]

im stuck with this:

[mcs]

I upgraded with rkflashtool and upgrade_tool still can't boot from usb I removed all hdmi usb stick etc. only the usb to usb cord

also I always do rkdeveloptool db rk322x_loader so I can do rkdeveloptool rd 3 idk why coz it will say Reset Device Failed you see in the picture it says Reset Device OK.

[mcs]

see I did rkdeveloptool db rk322x_loader anything that doesn't work works now I was able to rkflashtool e 0 8192 while earlier it was stuck

 

Edited July 4, 2023 by mcs

[mcs]

hello @EmilB can you help me because you were able to boot from usb after following jock's guide on rkflashtool what armbian image did you use mine I burned current_jammy from archive builds to USB stick

edit: I replaced my multitool in SD card with the current_jammy and it worked but I need my armbian in USB stick

Edited July 4, 2023 by mcs

[mcs]

armbian on external SD card

[mcs]

after installing armbian on SD card removed the SD card and inserted USB stick, now I can boot from USB stick  I will now replace my multitool (USB stick) with armbian

[mcs]

here guys armbian working on USB stick thank you @jock & @fabiobassa and the community

can you guys tell how this happened after installing armbian on SD and I can now boot from USB stick

[mcs]

my r329q_v3.1 idle temperature 😥

ched

[feralfeather]

So after the successfull install and being connected via LAN, I can SSH into the device and run

sudo rk322x-config &

sudo armbian-config

but somehow it acts super weird as a entity, it can SHH and send packages out but not retrieve any, regardless what I ping and hence many stuff does not work... "Destination Net Unreachable"

28 packages transmitted, 0 packets received

any ideas?

 

[mcs]

hello @ilmich you said we have same board what is your cpu temp? also your rk322x-config

[jock]

On 7/5/2023 at 12:48 AM, feralfeather said:

any ideas?

Nope, usually the ethernet is working very well by default and does not require any specific configuration: both phy and mac are in the 322x SoC, so once configured properly in the dtb, there are practically no chances of misconfiguration at kernel level. There may be some corner cases, but as long as this thread exists, I never encountered a board which required a specific configuration for ethernet.

[mcs]

hello @jock is my temperature common for r329q boards?

[jock]

18 hours ago, mcs said:

hello @jock is my temperature common for r329q boards?

Yes and no. They are known to report quite high temperatures but the heatsink is just barely warm. Surely a reported temperature of 80°C at idle is a bit too high.

Mines are idling around 65°C

[im_chc]

On 7/3/2023 at 5:51 PM, im_chc said:

Correct me if I'm wrong, if I use an SD card drive for the dongle, does that mean that I can use a uboot and kernel that supports SD cards to boot it up?

I mean, just to install uboot and kernel and the distribution to the SD card, ignoring the SPI storage.

 

But there is one more problem, the dongle has only one usb port, and after I plugged in a card drive, there will be no free usb port left for power.

Do I need some special cables like those that has one single male connector at one end, and one male connector + one female connector on the other?

@jockMind if you take a look?🙏🙇

[jock]

1 hour ago, im_chc said:

@jockMind if you take a look?🙏🙇

Honestly, I don't know. I did not even know that rk322x could boot from a SPI device.

About the USB thing, despite the "adapter" you may need to do what you ask, the boot options depend upon the original firmware you have on the SPI right now and, AFAIK, USB boot is not available in any original firmware.

 

Surely the SOC itself is not capable to boot from USB, there should be a piece of software installed on the SPI (read: uboot) that will do that.

If you put an sdcard in a USB dongle and then the USB dongle in the USB port clearly you're trying to boot from USB, so it won't work

[mcs]

13 hours ago, jock said:

Yes and no. They are known to report quite high temperatures but the heatsink is just barely warm. Surely a reported temperature of 80°C at idle is a bit too high.

Mines are idling around 65°C

thanks for the reply, I removed it from the box/case the idle temp is 65°C now.

[kirill91]

good day, I have 2 tv boxes type H20 with RK 3229 chip.
Problem is that multitool does not start. I have tried several times to use other versions of multitool,
to use other formatting. Without sd card the box starts normally with android once the sd card is inserted,
only the red led is on but it doesn't start. i would love to get them both running. are there other ways to start multitool or flash armbian?

[ojogoperdi]

Hey @jock and @fabiobassa, thanks for all the work you put on this!

 

My team has been messing around with TV boxes (TX9) and the tools you made.

 

I have some questions about the boot process of these TV boxes, and I'm hoping you could share some insights we don't have yet.
 

Sorry in advance for the long post!

 

 

Question 1.

According to the rockchip wiki, the SD card boot process and the eMMC boot process are the same, only the boot device changes.

We understand the first 16 MiB of the boot device should contain multiple stages of bootloaders (the rockchip miniloader, trust.img and U-boot) in specific sectors.

Looking at the multitool image, we find the expected data at the expected offsets (sectors 0x40, 0x4000 and 0x6000).

 

On the armbian image, there's a difference!

We could find idbloader at sector 0x40, but the user partition starts at sector 0x2000, so there isn't any more rockchip-specific "magic" data after that!

 

So my question is: why does the eMMC only need the idbloader, while the other boot stages are required for the SD card to boot?

 

I have a theory that trust.img and u-boot are there in the eMMC, but offset behind what the operating system can access (for example, Linux wants  to read sector 42 of the eMMC, and the controller translates that to a read to sector 42+0x8000).

But that doesn't account for the need for the idbloader to be in the armbian image.

In the end, the idbloader would be located at sector 0x8040, which isn't where it would be expected.

 

 

Question 2.

 

Armbian installed in the eMMC works. We tested kernel versions 4.4, 5.something and 6.1. All work as expected.

 

We were able to extract the "magic" rockchip section from the multitool image and use that to create bootable SD card images from backups of the eMMC (armbian).

We create a FAT partition similar to the multitool partition and put there an extlinux config and the kernel and DTB from multitool.

The extlinux config is modified so it points to the correct rootfs, and the system boots (even the UI works)!

 

However, replacing the multitool (or modified armbian) kernel.img with a more recent kernel doesn't boot.

We expected that just changing the kernel and adding to the command line "console=tty1 verbose=1" should at least show something if the kernel is able to start the HDMI driver. (even if it would eventually panic because it couldn't find the rootfs or a initramfs)

But because nothing shows up, either the kernel isn't being loaded at all or it isn't able to start the HDMI driver or it panicked very early in the boot.

We tried using the DTB that comes with multitool and the DTB in the armbian image, to no avail.

 

Why is it that the same kernel that works on armbian installed in the eMMC doesn't even boot on multitool installed on the SD card?

Have you had luck with newer kernels + multitool?

 

 

Questions 3.1 and 3.2.

 

To work around the problem of only one kernel being sure to boot from the SD card, we tried kexec'ing newer kernels.

We recompiled the kernel to enable the kexec feature and it boots from the SD card.

We kexec the same kernel, to make sure it works, passing the same command line used to boot it.

The HDMI output instantly turns off, but the device starts responding to pings after a while, so it's somewhat working.

CTRL+ALT+DEL resets the device, as expected.

 

Do you know why the HDMI output is instantly disabled and never turns on again?

I don't have access to a dmesg log right now, but I can provide one on monday.

But from what I read, there wasn't any difference in the HDMI related messages.

 

And back to kexec: kexec'ing a newer kernel doesn't work!

We don't have video feedback, the same as after the successful kexec, but it never responds to pings, and CTRL+ALT+DEL doesn't reset the device, so we assume it panicked.

 

Have you had luck kexec'ing newer kernels?

 

We still haven't tried kexec'ing after booting armbian. I will report on how that goes on monday.

[ojogoperdi]

Here are the dmesg logs.

I didn't have time to test kexec from armbian on eMMC. Sorry about that!

dmesg.log dmesg-kexec.log

[fabiobassa]

@ojoperdi

 

what do you mean by this sentence:

Quote

My team has been messing around with TV boxes (TX9) and the tools you made

If you would explain what is the final goal you want achieve by this boxes eventually would be easier find the right approach

[ojogoperdi]

hi @fabiobassa

 

I'm part of a research team / group in my university.

Our overall goal is to install Linux on TV boxes that we receive.

Right now, we are creating, flashing and testing armbian images.

 

Currently, we have a lot (hundreds) of TX9 boxes (based on rk322x chips).

That's why we are using the tools you and jock created.

 

I decided to focus on how the device boots, because some tests broke a lot of assumptions I had about the boot process.

Some devices wouldn't boot after flashing, so there must be some nuance of the boot process that we don't understand.

 

After a lot of rabbit holes trying to understand why some wouldn't boot, I only got more questions.

Why is the eMMC image so barebones compared to the multitool image when it comes to the rockchip boot section?

Why does multitool only work with an old kernel version, but armbian installed in the eMMC work with all kernel versions?

 

The reason I am even trying to answer these questions is because I want to create something that would allow us to test armbian images without having to flash them to the eMMC, as that takes time (and can leave some TV boxes unusable).

I ran into problems trying to run newer kernels from multitool in any way I tried.

 

Because you two built these tools, I thought you also ran into similar problems, or had better insight to understand these problems than I have.

 

But it's alright if you don't! I still plan on messing around with the TX9 TV boxes and figure out answers to these questions eventually.

Edited July 12, 2023 by ojogoperdi
clarification

[fabiobassa]

@ojogoperdi

I am SURE you read the whole 3ad ( did you, isn't it ??? ) and I am SURE you and your team realized that multitool is based upon LEGACY kernel that is the MOST COMPATIBLE ever kernel tha t boots quite every box

This said , I am also sure you and your team realized that saying TX9 box is a little bit as saying "water"..
Sparkling ? Flat ? Cold? Warm ? Salty? With sugar ?
TX9 means NOTHING is just a commercial brand !!!!

 It seems it is emmc from what you wrote and emmc are the easiest to boot since they don't mess with nand and FTL  . To be sure it always boots from external sd is enough to erase the flash and it will boot form the stuff on the sd. I believe you already read this:

https://opensource.rock-chips.com/wiki_Boot_option

DDR2 ? DDR3? the ram is 1T or 2T ??

The only way to anser to a failing boot is attach a UART to the box

I don't personally know this box so I cannot point you where rxd txd are on it, if present or just hiddend pads but I guess in your university you own an oscilloscope to further investigate where serial signals are

About new kernels they should boot quite smoothly even from SD since the early stages of booting (  idbloader and trust or optee in his opensource version should be already in the right places) but missing uart log it is difficult to give you an answer

As last resource we wait for a @jock 's answer regarding this behaviour but without serial log is a bit a nightmare

Regards

Edited July 12, 2023 by fabiobassa

[jock]

On 7/12/2023 at 4:51 AM, ojogoperdi said:

Our overall goal is to install Linux on TV boxes that we receive.

Your goal is achieved already, since armbian already runs on those boxes, or do i miss something?

 

On 7/12/2023 at 4:51 AM, ojogoperdi said:

Some devices wouldn't boot after flashing, so there must be some nuance of the boot process that we don't understand.

Did you inspect the hardware? Did you connect a serial adapter to debug the output from the serial port?

Have you read carefully and throughly the first post of this thread? Perhaps you have different boards or boards with different hardware, despite the commercial name.

 

On 7/12/2023 at 4:51 AM, ojogoperdi said:

Why is the eMMC image so barebones compared to the multitool image when it comes to the rockchip boot section?

Why does multitool only work with an old kernel version, but armbian installed in the eMMC work with all kernel versions?

Multitool does not only work with old kernel version, it is made this way on purpose, to be the most compatible with the plethora of devices around; also NAND boards work only on legacy 4.4 kernel.

I don't understand what you mean with "eMMC image"; there is no limitation about the storage device for armbian images (read the first post)

On 7/12/2023 at 4:51 AM, ojogoperdi said:

The reason I am even trying to answer these questions is because I want to create something that would allow us to test armbian images without having to flash them to the eMMC

Read the first post.

Even better, this thread is filled with useful info you may need.

 

May I ask how your university got all those cheap and trashy devices and what is the final purpose of altering their firmware?

But it's okay if you don't want to share!

 

[ojogoperdi]

I haven't read the whole thread. Sorry for any information you had to repeat! I'll take some due time to read it when I enter school break.

 

6 hours ago, jock said:

Your goal is achieved already, since armbian already runs on those boxes, or do i miss something?

I meant it in a more of a "create custom images for our client" kind of way. (more on the client at the end)

It's not in the scope of this thread, so don't worry about it!

 

6 hours ago, jock said:

Did you inspect the hardware? Did you connect a serial adapter to debug the output from the serial port?

Have you read carefully and throughly the first post of this thread? Perhaps you have different boards or boards with different hardware, despite the commercial name.

For the first question: not all devices. But I am sure they all have one thing in common: they are based on rk322x chips.

I said they don't boot, but I should clarify. I mean they don't boot without further intervention.

After flashing armbian, the board is "soft-bricked". Multitool doesn't boot from SD again.

If I force them into maskrom and upload a bootloader you posted in this thread, they can boot armbian.

For all that I tested, I could recover them.

I don't have access to a serial adapter yet, sadly.

As for why I'm sure they are all rk322x (at least the vast majority): this week we flashed some hundreds of the same model of device, and about 12 didn't boot completely, for reasons we have yet to investigate, and maybe 2 of those gave no video signal again. All other devices reached a desktop session.

 

6 hours ago, jock said:

Multitool does not only work with old kernel version

On these devices, building multitool from your repo (./create_image rk322x) or using a premade image, replacing the kernel with a newer one doesn't work for us. The devices never boot. Kernel seems to panic before starting the HDMI driver, or whatever makes the console output appear on the screen.

I don't yet have access to a serial adapter, but I'll report if I have any output when I try.

 

However, the mysterious part is that armbian images (with any kernel version) boot! (if installed into the eMMC)

 

For some reason, booting from the SD card with a kernel version other than 4.4 doesn't work, but from armbian installed on the eMMC works.

 

6 hours ago, jock said:

I don't understand what you mean with "eMMC image"

just armbian. I said eMMC image because I thought it was only meant to work there.

Is armbian supposed to boot from the SD card? That never worked here.

And I assumed it wouldn't because it doesn't contain the special images at the special offsets described here https://opensource.rock-chips.com/wiki_Boot_option

But I read the first post again and you said it's supposed to work. Now I'm kind of confused as to why it doesn't work here.

 

6 hours ago, jock said:

May I ask how your university got all those cheap and trashy devices and what is the final purpose of altering their firmware?

The Brazilian government confiscated (big) irregular shipments of TV boxes. They plan on repurposing some of them (the ones that are actually usable) as mini PCs for schools and other social causes. So our university got a portion of TX9-brand boxes to explore the feasibility of using these devices as PCs. They are very sluggish, and I don't expect them to be usable for this purpose.

[art3mis_17]

My Device is MXQ-4K with RK3228a chip, Unfortunately I erased my emmc chip clearing out the idbloader, when inspecting using serial I'm getting this output (I Don't have a USB to TTL convertor, so I've repurposed my Arduino to read serial out from MXQ-4K, don't know how reliable the serial output is)

 

�DDR Version V1.10 20190926
In
ID:0xFFF
300MHz
DDR3
Bus Width=16 Col=11 Bank=8 Row=15 CS=1 Die Bus-Width=16 Size=1024MB
mach:2
OUT
Boot1 Release Time: May 13 2019 17:02:59, version: 2.56
ChipType = 0xc, 407
No.1 FLASH ID:2c 64 44 32 a5 0
ECC:60
FTL version: 5.0.56 20190508

Is my box done or is it possible to revive it to earlier state, P.S I installed armbian using rkdeveloptool even though there was a SD card slot, because my micro-sd to SD adapter was faulty. Also I did a backup of LBA using wl command in rkdeveloptool. Post installing armbian there was no display so I tried to restore the dumped LBA as instructed above, now  my device is detected in mask rom mode only when EMMC clock is grounded and I'm unable to download bootloader onto the chip, I'm new to this so any suggestions on reviving the device would be helpful

[fabiobassa]

@art3mis_17 your board is ddr3 and nand storage NOT EMMC

 

Is suggested go find a working sd adapter because you need stePnand method by multitool

 

As alternate method you can try to flash android image on It.

 

You can device device for sure but need some tools as a good sd

 

 

Edited July 16, 2023 by fabiobassa

[jock]

@art3mis_17

@fabiobassa is totally right, you will need a working sd adapter because you have a NAND chip and not an eMMC chip; I just add a quick note: you must use the image with legacy kernel if you want to install to NAND. Refer to the first page for detailed instructions.