jock

The search function? It was two posts above yours: https://forum.armbian.com/topic/24085-csc-armbian-for-rk3318rk3328-tv-box-boards/?do=findComment&comment=153877

@hotnikq Thanks for reporting, that 5.19.15 kernel has LibreELEC patches in. Unfortunately they were not accepted into mainline armbian, the 5.19 train is gone and I won't do all the rebasing work again for 6.0 or future kernels, so I suggest you to stay stick with that and hold the kernel packages if you're happy with them.

Perhaps you did not pay attention to what I already wrote several times, so I highlight a bit it here: the ddrbin is a proprietary code from rockchip with no public source code. I don't see any value in checking the original firmware on a different board, that's your precise board that is having issues, other boards are known to work well even with 4GB of RAM.

Mmmh, I will try to check in the next week if there is something wrong with the driver, please be patient...!

I don't have an nvme ssd around to replicate this problem, but still I don't understand what you mean with "github sources". Also your dump is a broken link.

I don't know if it has already been fixed, but the last time I tried the RC images, the Terminator font was huge again. I tested 32 bit Tinkerboard and 64 bit Orange PI 4 LTS jammy xfce images.

Hello fr3d, I recently tried the Tinkerboard-S (which should be identical to yours, except for the onboard eMMC) for the imminent new armbian issue release and, despite the network was far from being fast, I was able to connect without particular issues to my router which is one floor away with basic WPA2 encryption. My test image was Jammy with linux 5.15 kernel, so it was pretty regular. Which image did you use?

If the armbian boots from sdcard the worst thing that may happen, once installed on eMCP, is the rootfs that does not get recognized. It is not as scary as it may sound, because you will indeed be able to reboot from sdcard into armbian/multitool. I think you're safe enough.

I have a better answer: use the forum search tool, or maybe google. The answer is just around the corner.

Normally all the other board works that way because that behaviour is embedded in the SoC, but I don't know if the manufacturer did some weirdness with your board and that does not apply to you, but if you wipe the emmc the board should boot from sdcard, and then armbian can boot. What is preventing armbian from running from sdcard is the android firmware, if you remove it from the emmc then both armbian and multitool should boot fine from sdcard. edit: ha, I just reread the post and got the thing about the multitool green screen... well that's a very good sign, that means there is something not exactly right for your board in the dtb or the kernel. Do the led is fixed on/off or it is blinking? The serial adapter may tell more about the crash.

Yes, when you push the button you can then use rkdeveloptool to erase flash or upload a new firmware to the board, but you need a male-to-male cable to connect your PC to the OTG port of the board. There is some reference about in the first page of the forum on how to do that. The Armbian image as-is is not supposed to boot from sdcard if there is the android firmware, but the multitool should boot from sdcard no matter what firmware is there. Well you can erase your flash if you don't care about the original android firmware; then the board will boot from sdcard in any case, but still your case is a bit weird because usually the multitool boots fine.

Ah ok, not I got it... you tried to decompressed the backup twice, and the second time came the error. Well that's right, once you decompress the first time, you get a binary image that indeed cannot be decompressed again. You need a specific tool if you want to extract anything from it, but as long as your board boots and works fine there is no need for the dtb to be inspected. The performance is what you get from an old armv7 chip, it has no horsepower to be a complete desktop replacement but works really fine for server/command line tasks.

Normally the base dtb shipped with armbian should work fine with all boards out of the box. Since your board looks very similar to MXQ_V72/V73, you may also try to apply the led-conf for that board via rk322x-config, but actually you can also keep the base dtb if your board is stable. The wifi chip is not supported in mainline kernel, only the ssv6051 works; there is an adapted driver but you have to compile it by yourself. Ethernet will work out of the box. Anyway a dmesg log can already tell if the peripherals of the device are all detected or not, but for your tasks probably it is much more useful to see if the eMCP flash supports DDR or HS200 modes.

Thanks for pointing it out, I'm going to remove that warning! I had the chance to test some boards with eMCP (notable the MXQ_V73) and they now are quite well supported. I don't know which board you have, so apply the general precautions before flashing into the internal emmc.

Ah ok, so your backups are not good. Unfortunately there is a huge bug in multitool due to FAT32 partitions: the files cannot be bigger than 4GB. The multitool will say the backup is ok, but in reality the file is broken because it is truncated to 4GB by FAT limits, despite being compressed. At the moment there is no easy solution for this, both using NTFS partition or split program have some drawbacks and this bug is still not fixed yet 😕 You may altough try to do a backup via network, since you have ssh access. Do this on your PC: nc -l -p 1234 > backup.img.gz Then login in the multitool and run this: pv /dev/mmcblk1 | gzip | nc -N your_PC_ip 1234 The commands will transfer the content of /dev/mmcblk1 (which should be your emmc, double check with lsblk) via network using netcat to your computer (change your_PC_ip with the right IP address) and you will get a full and compressed backup in backup.img.gz file. The pv command is handy because will tell you the progress of the operation. An alternative is to restore Android factory defaults and try to backup again. Maybe without the user content you will be able to shrink the backup size. Yes, that's the correct procedure.

@MattWestB @Aapo Tahkola sorry but I have no real explanation for this, chips are marked as 4 gigabit each, there are 8 of them, so it is 32 gigabit which is 4 gigabyte of RAM. Can't correlate the bus widths with anything, I don't really know to what those buses refer to so I avoid to do any math with them, but my best guess is that they should not change the amount of memory shown by the system. The ddrbin that does the RAM initialization and shows that information is a piece of binary supplied by rockchip itself, so there are two chances: the ddrbin is failing to detect the ram, because it is buggy or does not like your board the chips are somehow fake and they are advertised as 4 gigabit instead they are 2 gigabit Now, for what is worth, you can reinstall an original Android image and see what the original ddrbin tells you about the RAM. If the original Android detects 4 gigabyte of RAM, then the first chance is the true one; if the original Android image detects 2 gigabyte of RAM, the second option is true.

Once you get a valid backup you can extract the dtb from the original image. But anyway I should already have a dtb for the t95n around. In theory you should not even have the black screen if Android is still in the internal flash. Normally Armbian on sdcard boots if it is already installed in the internal flash or the internal flash is just empty. If Android is installed in the internal flash, the only thing that boots from sdcard is the multitool. Then you can verify that the backups are sane (just open the files on a regular PC) and then may proceed to erase the internal flash to try armbian from sdcard. You also have what I think are the serial pads if you have a serial adapter to connect for full boot logging. The HDMI problem may be due to several reasons: incompatibility with your board, bad cable, bad monitor/tv, ... and the previous lockups during backups may be due to a bad power adapter for example (those coming with the tvbox are generally crap)

You have what? That datasheet is describing memory chips that range from 64 megabytes up to 512 megabytes each.

Who knows? Instructions are on first post.

@marras which board (not tv box) do you have? Some photos are very welcome, I see you already disassembled the box since you posted the dram markings. If you have the chance to connect a serial adapter, a detailed dmesg log from multitool or armbian would be useful, especially when the board seems stuck. You could also login to the multitool via ssh and launch the backup from there and login from another session to see if it is still responsive and what the kernel is saying. Also, did you erase the whole flash before trying armbian from sdcard? Does the led blink or it stays on/off?

Tested Orange Pi 4 LTS with both debian bullseye and jammy images, it booted in all attempts except one attempt where apparently the HDMI monitor did not turn on (led was blinking so kernel was alive). Unfortunately I had no serial attached and when I attached the serial, it never occurred anymore.

Checked in the last few days, with both USB2 ports and a PS/2 -> USB adapter. The board did boot fine with the thing attached with kernels 5.15, 5.19 and 6.0

Where you see armbian has been supporting the board? This is the page of the armbian supported boards, there is no trace of respeaker. You may want try to download an image for "generic" rk322x tv boxes (see this thread), it may work, or may not. If you want to build an armbian image by yourself, you're welcome, but you should at least read a bit of documentation to get acquainted with the process.

Well I heard about respeaker, me and @fabiobassa studied their source code and device tree to get clues about rk322x devices. AFAIR is a board with a microphone array much like amazon echo/dot devices. Getting respeaker work with armbian would not be a so incredible task, but judging by the tone and manners the guy is asking, it looks to me that he's not really interested in the matter and didn't spend more than a minute to document himself about.

Which kernel are you using? Currently stable and supported kernel version is 5.15, other versions are experimental and should not be considered stable. If the system didn't boot, there are no messages from the previous boot. However the serial port will provide very helpful information about the failed boot reasons. Personally, i never had any problem with the keyboard plugged in the alone USB 2.0 port, in fact it is common way I use the board. Will check when possible, but indeed the kernel version is essential.