jock

@Maker39 hello, welcome back Your board should be well supported, esp8089 also is well supported and performs very well. Which image are you running? You should use an up-to-date image running with mainline kernel. Older images and legacy have not been tested or are not supported at all on eMCP boards. Also please post a dmesg log from your armbian sdcard installation.

@speed21 Well I don't have experience with OMV in docker, I run mine on the bare operating system without issues, but actually I don't know if installation scripts have been adapted to OMV6: you could try to install it from armbian-config if you don't worry about having it outside docker, or you can try and run your own container but that may take some time... edit: your MXQPRO_V71 Is very very similar to mine MXQPRO_V73, which is very well supported with the proper led-conf overlay, you should have no particular issues with the hardware.

@MR01 Yes of course you can, you should try to investigate ir-keytable utility that should help you receive the raw scancodes, in particular the -t flag to do testing. Usually one of the common protocol is NEC (practically all tvbox remotes use the NEC protocol), but you may have to guess it in case it does not work with your smartphone, which usually is software programmable to emulate several devices.

Hmmm, I did not understand if the board crashes or OMV becomes unresponsive (and which part, since OMV leverages nginx and php for the web admin and samba/nfs/ftp for the file serving services). You say that you can "ssh the box", but you mean that you can login via ssh and the board still operates normally or the ssh service is apparently responding but you can't login? I have a board with debian buster that is running OMV perfectly fine for several months right now, but also I'm experimenting with an eMCP board that has Home Assistant and running as wireless AP without any issues. Both of the board are running headless with no problems or crashes. The eMCP board is a MXQPRO_V73, should not be far different than your MXQ_V71 (I may guess it is a MXQPRO_V71? You could post some high resolution photos that may be helpful identifying the board and its components)

@MattWestB AFAIK rockchip devices don't look for USB boot as Amlogic instead do. I don't know if newer SOCs like rk356x or rk3588 do that, but for older SOCs USB boot it is not mentioned anywhere. @r00tl3ss you have to select a piece of text and a quote popup will appear. You may indeed try the cp210x USB serial, maybe it can reach the 1.5mbps speed even if it is not officially rated for.

@r00tl3ss Hello, the answer to your question is "yes, but depends". Normally you're in the perfect condition to boot from sdcard: the emmc is not recognized or has and invalid bootloader, so the SOC tries to boot from sdcard. You should be able to boot anything (except Android) from sdcard: armbian, libreelec, multitool or whatever... You're both right either about completely desoldering the emmc and shorting the clock pin: shorting the emmc clock pin should be enough to mask it from the soc and desoldering should not be necessary. Now comes the bad news: unfortunately if you're not able to boot from sdcard in your condition, I'm afraid the sdcard slot is wired to the "alternative" (also called sdmmc_ext) controller and not the usual one. The SOC, as far as we experienced here on the forum, does not look for alternative controller during its very first boot phase. It turns out that, on those boards like yours, it just does not see the sdcard because it is not wired where expected. If you have the serial uart attached, you could post the output you get when you run rkdeveloptool db your_loader.bin from your computer. Maybe it has some hints about the emmc or sdcard controller. Also be sure to get a loader which is recent or up to date; if it is too old it may not detect the emmc correctly.

Nope, I can't. Anyone can here; this is not an android support forum.

@Fathur Radhy that's because that board does not have an rk3229 but a allwinner h3. Another fake spec is 8gb ram and 64gb rom: neither rk3229 nor h3 support more than 2gb of ram. Probably your board has 1gb of ram and 8gb of flash.

Hello @fr3d, last day I checked in with my tinkerboard-s and a fresh Ubuntu Jammy cli image, kernel 5.15, taken from download pages. Everything was working very fine with my router, which is crappy sercomm but does its job. What I noticed is that the power management of the chip, which is on by default, may interfere a bit and caused some up&downs in throughput. You can try to turn it off with: iwconfig wlan0 power off Also the transmitting was kind of low (12db); I don't know where is the programmed default, but you may try to increase to near-maximum and see if you still have problems: iwconfig wlan0 txpower 18 To show the hardware settings (including power management and tx power): iwconfig wlan0 Try and tell me if it gets better

This is exactly the reason why the linux has no bugzilla-like issue tracker, because people would abuse of that since this is not a bug of the kernel. Please, stop posting nonsense.

You can try and follow the "Restore" paragraph on the first page. It shows how to manually upload an image to the internal flash without using the multitool but just the basic maskrom mode. 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.

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.