jock

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.

Looking at the log all those sdiohal messages does not seems right at all, you should understand why you get all those messages. The bus seems to have been probed correctly, although the frequency of 200MHz looks a bit too high to me. I would reduce it to 100MHz to exclude possible data integrity issues at first. Anyway I'm no expert with the rockchip_wlan framework, but it really looks to me there is something wrong with the communication with the chip. Maybe some wrongly configured gpio pins (check the pullup/pulldown configurations), maybe the frequency is too high, or the chip is somehow in reset state - if you use the rockchip framework don't use the sdio-pwrseq; surely the chipid should be rightly detected, otherwise the driver won't go anywhere.

Could you be so magnanimous to share how did you solve the issue?

Please read the first post It may be related to some clocks, but until you provide the working dtb I can't say more and surely can't fix anything.

So you did something noone told you to do and now are lamenting the multitool does not work? 🙄 I understand the monitor blinks, but you can access even via network; also if that dtb provides a stable signal maybe you could post it for analysis and comparison? Did you try another HDMI cable or another monitor?

@Orcus did you change the dtb of the multitool with something else?

Photos of the board would be very useful too

Hello, obviously we don't know what you're doing wrong, because if you don't post some logs or other details there is no chance to help with anything. Maybe your emmc is faulty and it will just never work... Once run, multitool will drop a file on the FAT partition called dmesg.multitool.log with the kernel dmesg log you can post here for inspection. However I would rather erase the internal emmc and try armbian from sdcard instead of burning on emmc.

Yes, I mean the armbian patched one This is one of the reasons to stay away, whenever possible, from the "proprietary" kernels: they use customizations in place of standard kernel sunsystems. Sometimes there is no other way, but that rockchip_wlan is a duplicate framework that has been superseded by kernel "power sequence" (pwrseq) framework. Anyway the two frameworks can coexist. The driver in the armbian trunk works fine without the rockchip_wlan framework and you should not try to integrate it into. No idea 🤷‍♂️

That phandle is absolutely spurious and not needed, it is possible that it has been left there. Well, you can use either wl-reg-on or sdio-pwrseq, but sdio-pwrseq is better to do because it is non-proprietary and kernel is informed about the on/off switch and can control it via rfkill. wl-reg-on is "simpler" though, because does not involve another node and subsystem and you may start with this to avoid an unnecessary bring-up complication IMHO. There is no "kernel paradigm" though: the device tree properties are actually interpreted by the driver and not by the kernel itself. The kernel will read some "common" properties like compatible, pinctrl-names, and some others. You have to use the nodes and properties you found in the 5.10 device tree because you took the driver from there and ported in your 4.19 kernel. Actually I don't remember exactly, I should check back the discussion with Igor and which one was hinted by Orange Pi people themselves. I had several headaches with 5.10 driver because there were issues with either newer kernels and firmware. I remember also that the 5.10 driver was having issues with recent wpa_supplicant revisions (ubuntu jammy was able to connect to wifi, for example). At last, the driver which is in the 5.15 rockchip64 kernel flavor is the best choice, is working quite well and I would suggest to go with that.

@NicoD Hello, no bothering at all, I'm happy to help! That pull request adds the libreelec patches to rockchip64 branch that provide several fixes and multimedia enhancements to mainline kernel so it is possible to use an "almost" mainline ffmpeg/gstreamer for h.264/hevc/vp8/vp9 hardware decoding, DRM fixes, support for 10-bit HDR videos, more DRM planes, etc... etc... There was an old thread where I provided a ready-to-go mpv executable with hardware acceleration on mainline kernel, but should be rebuilt for recent distros since it is quite old now. It could be a nice idea to try mainline kernel with wayland based desktop environment. I may build an Opi800 image with kernel 5.19 from that branch, maybe with a fully-fledged KDE, rebuild ffmpeg/mpv and give instructions for a cutting edge test if you think it is reasonable

@handymenny Cool, thanks! Maybe the broadcast decrypt can be fixed adding a proper -DUSE_MAC80211_DECRYPT_BROADCAST directive in the kernel module makefile nearby the other conditionals that relate to hardware/software encryption and decryption, without hardcoding the conditional. Anyway thanks, do what you prefer and if you open a pull request I will accept and rebuild the armbian patches to fix the problem

@handymenny hmmm, that line is very interesting! To let things work on mainline kernel, hw encryption and decryption have been disabled and everything is handled by the mac80211 layer in the kernel, which has fast enough algorithms to provided enough throughput without taxing the system too much. Maybe that block inside the ifdef is not compiled because the macro is not defined. Unfortunately the driver is filled with such ifdef conditionals which are very hard to track.

@handymenny Maybe it is a makefile configuration option. Double check the kernel running on your android installation, because the driver in the rockchip 4.4 repository looks like an adaptation from something from kernel 3.x ported to 4.4 and then later ported by us to 5.x, so it could have happened something in the process has been lost.

About the android roms, I have no direct experiences but I may guess the same issue applies because the "original" driver in the legacy 4.4 rockchip kernel also behaves the same. The driver working on mainline kernel is nothing more than an adaptation from the legacy one. The other driver ssv6x5x, despite the name matching, does not work with ssv6051p. Me and @ilmich inspected both of them. We found that some parts are significantly different, and the result is ssv6x5x driver works only with ssv6256p chip (common on some "5G" boards) and ssv6051 driver works only with ssv6051p chip. Adapting ssv6x5x to work on ssv6051p apparently is not a trivial task, and is complicated by the lack of internal documentation.