CSC Armbian for RK322x TV box boards

jock · October 17, 2022

@remlei As expected, I download the latest 5.15.74 community image and there are no problems with ethernet at all 😑

fabiobassa · October 17, 2022

@Max Sterg

You have a 64 giga sd... You burn an image of around what dimensioni ???

5 giga ? 4 giga ???

How big Is the image you are burning with balena ?

jock · October 17, 2022

@Max Sterg It's happening that the partition will be enlarged the first time you run the system.

You should read a bit of the armbian documentation to grasp the basics, it has been written for a purpose: https://docs.armbian.com/

RaptorSDS · October 17, 2022

@jock @Max Sterg thats correct the first time the image only occupied some GigaByte , after first run is enlarge .

But you you can also put , after burn the sd card , the images as a compressed file on it (tar.zx or something like that) the multitool can decompress this file on the fly ( at the moment this tool burn the image to the box)

the one gig is enough for that desktop image

fukowaka · October 19, 2022

Hello there, here i am with updates. im with legacy armbian on rk3229. Octoprint works like a charm with a creality ender 3.
Also webcams with fswebcam to take pictures.

Wifi antenna is weak but works. Ethernet works fine.
I tried to compile retroarch but i have no hardware acceleration on legacy version so im looking another way.

I have a working lakka image booting from the sd card. Works really great. i burn to emmc with u-tool but no success booting...
Sorry for the offtopic but is there any way to make it work?

BTW i tried to debug mainline boot following yt tutorials but there is no text on the board with rx, tx or ground... i found 4 suspicious copper points, im risking to brick the device

if i try?

Seth · October 20, 2022

4 hours ago, fukowaka said:

BTW i tried to debug mainline boot following yt tutorials but there is no text on the board with rx, tx or ground... i found 4 suspicious copper points, im risking to brick the device

if i try?

board version? sometimes those 4 pads do not work for me, what i sometimes do when i'm feeling lazy is i try connecting the ground on the board first then i try connecting the rx pin of usb serial to different pads of the board while booting to find its tx pin. you only need two pins to capture serial debug logs. i found mine at the back of the board. i think i posted the pics in this post at page 26. you get very low chances of bricking your board if you do it this way. other method i use is a low cost stm32 o-scope and a multitester which a is way safer method in my opinion.

Edited October 20, 2022 by Seth

MattWestB · October 20, 2022

The right and left is VCC and GND but i dont know witch is witch.

The 2 middle is RX and TX als not know the order of them.

Start using one known GND form some shield or the power plug - to the USB-TTL GND.

Then testing the RX from your USB-TTL cable and testing connecting is to one of the middle pins and rebooting the board. If getting some charters in the terminal (speed is 150000 baud for boot loader) its the right pin and if not testing the other middle pin.

If getting the board TX -> USB-TTL RX working is the other middle the board RX <- USB-TTL TX.

Then testing is the right or the left is GND (if both VCC and GND is on the pins you can using one multi meter for getting 3.3 Volt plus is the black GND).

Then having GND, RX and TX all is connected OK and you can using it as one local terminal but need changing the comport speed for Linux kernel (see first post / unbricking) and you can see and changing all in normal Linux way..

fukowaka · October 20, 2022

thank you very much both @Seth @MattWestB

remlei · October 21, 2022

On 10/17/2022 at 12:07 AM, jock said:

You should at least describe the issue before alarming people this way, and moreover you should post logs to let people understand if there is an issue with the image.

I don't see logs and I don't see the filename of the image object of the problem, just a dubious procedure based upon a dubious hypothesis.

And I say it is a dubious hypothesis because what you are stating can be only an issue related to the kernel (or possibly device trees), just because u-boot and related code has been frozen months ago.

Everything is possible, and I will check soon, to me it looks very difficult that a newer minor release of the kernel could corrupt some ROM data about the ethernet that, even after reverting to a previous working image, you don't solve the problem.

Maybe you have a broken cable or a broken router?

sorry about that.

I used the image Armbian_22.11.0-trunk_Rk322x-box_jammy_current_5.15.72.img

once the image flash, it works fine until you perform a apt upgrade.

procedure to reproduce it is to perform apt upgrade and reboot. it doesnt really matter what dtb file I use but my board is based of V72 (MXQPRO_V72 2021-01-29) so even if I picked the V72 on rk322x-config the issue persist. funny thing about this is that the issue persist even after reflashing everything. I even go as far as reflashing Armbian_22.05.0-trunk_Rk322x-box_bullseye_current_5.15.25_minimal.img the issue still persist. Not until I reflash the tvbox-backup.gz I have before and suddenly after android booted up, that ethernet port suddenly works.

this is no fluke, I didnt even touch the LAN cable nor replugging it, I just left it plug in all the time.

I wish I had some meaningful dmesg output I can share other than having