jock

@mwe Perhaps you're trying to ping the wifi interface from another machine? Because the ssv6051 suffered a problem with the broadcast ARP packets that has been solved in the mainline flavour of the kernel, which does not work with NAND yet. In practice the driver does not respond to ARP packets, so the wifi interface does not "announce" itself to others when asked to. The presence of the ethernet may cause some side effects that let the interface announce deliberately and so it works.

@sum1saw @ais From the back of the board I see a very nice "debug" label with three pins nearby (GND, TX and RX). You should attach the USB to TTL adapter connectors there (TX of the board to RX of the adapter, RX of the board to TX of adapter, GND from board to GND of adapter). Then you should be able to use any terminal emulator (like Putty on windows, minicom, picocom, or whatever on linux). Speed is usually 115000bps for rk3288. If you're lucky you get something on the serial port. About shorting the eMMC clock pins, usually the 7th pin is the clock one, but the orientation of the chip may vary, so you should also try the pins from the other side. The pads nearby the emmc often are connected to the clock pin and they are useful during board development as "test points" for engineering to quickly check if clock is present. In turn, try to short one pad to ground and give power. Is is important that you give power while the pad is still shorted to ground, then release one second after you power the board. Ideally even the eMMC clock pin should be shorted to ground, but it is not as easy to do as it is with the pads. For the pads you press a needle over them connected to a ground point of the board, ie: the ethernet/hdmi chassis, or the mounting holes with the copper around them. Ah, I also see that the board has an act8846 PMIC, so the board may require to be turned on with a power key instead of directly giving power with the power cable. That's because the PMIC is turning on and off the SOC. Also try with the male to male cable to plug it into the USB OTG port without power cable connected. If the board turns on, then you should not need to push the power button but you can plug the USB cable while you short the pin/pad.

Hello @sum1saw if you wrote the wrong firmware on emmc, surely you should be able to enter maskrom mode shorting the clock emmc pin; it is not exactly uneasy to do, especially if you don't have comfy access to the board, but if you can disassemble and clean the device it would be much better to handle. When the emmc pin is shorted, to SOC will look for a loader on the sdcard and, if not found, will put itself in maskrom mode accepting a connection ONLY from the USB OTG port. There is only one singel USB OTG port on rk3288 and hopefully it is exposed on your board, but may be that your board does not expose it at all, or sometimes it is exposed as a mini/micro USB port instead of a regular A-type. Sometimes also there is an "OTG" marking nearby the port on the PCB. I don't know if the multitool is able to boot on your particular board, it has not been tested so broadly on rk3288 devices and the ideal troubleshooting equipment here is a serial adapter to understand the current status: it may be that the firmware you put on boots but then the SOC completely freezes for some reason, or the firmware does not boot at all. In the first case you are forced to short the clock pin of emmc. I can't spot serial pads/pins on your board, but they may be hidden somewhere in those pin arrays I see all around. You should carefully inspect the board for RX/TX markings (or sometimes there is a "DEBUG" label). The maskrom mode usually only requires that you plug a male-to-male USB cable inside the USB OTG port on a side and the other side in your PC. Usually the PC will feed the board without the need to give separate power and in this case you absolutely do not need to feed the board with its power adapter. There are other cases where the power adapter need to be connected, so you should do experiments by yourself. In case the firmware is completely bad so that the SOC does not find a valid loader, it should put itself in maskrom mode even without shorting the pin ;in this case it is a matter of finding which port is the OTG one and you should be immediately find the device on the PC. If the SOC is freeezed due to a bad loader, then you won't get into maskrom mode if you don't short the clock pin of the emmc WHILE you power the board (either with its power adapter or the male-to-male cable). Going with sdcard is a bit more complicated, just because I don't know if the original firmware is able to boot from sdcard. You could try the multitool, but if it does not work you can't know if the problem is the multitool or the clock pin you're shorting is the wrong one and without a USB-to-ttl serial adapter thet tells you the outcome of the experiments you will be totally blind.

@drigohighlander you posted no useful information there: the dmesg link is broken and the dtb file comes from the multitool. I asked for the original device tree. I still see no photos of the board.

Perhaps, and I say perhaps, you're not getting anything on teamviewer without HDMI cable because simply there is no framebuffer, since resolution is not known. You may try to force an EDID to the linux kernel to let it believe there is an HDMI device with some parameters attached, but I won't endorse this solution for any reason: despite the fact that turning on HDMI requires a significant amount of energy just to keep the circuitry on, if you need teamviewer to access the terminal is a bad solution to a common problem; the right solution would be ssh, which is much more handy.

@hartraft Currently, I can assure you that the tinkerboard with armbian edge kernel (6.1) receives MGLRU compiled and enabled by default because I maintain the rk3288 (rockchip 32 bit) family. The other two boards are not under my maintenance so I can't say anything about, but you could check in the config sample file in your /boot directory to see if a kernel is compiled with the options pointed by @hexdump

@hartraft rk322x and rockchip (32 bit) are already shipped with MGLRU active in the kernel config, but I don't know if other families have enabled MGLRU already. What is your board?

@drigohighlander please post your dmesg log, photos of the board, the original dtb or a link to the original firmware. If you don't post informations about your hardware but just say "does not work" we can't help at all.

I wonder what dmesg is saying about. Recently it happened to me that I could not connect to a board that worked as an AP. On the client, network manager was telling me errors about the missing secret, but dmesg was telling that the connection was denied and soon I discovered that the AP was not able to accept more clients.

@Maker39 well, my best guess is that the emmc is faulty 🤷‍♂️

@Maker39 I don't see mmc buffer errors, is the emmc working with pins + ddr-ph45 overlay? If it works you should go with that.

@Maker39 it looks to me that you're running an "old" image: the kernel reports it has been compiled 21th Sep 2022, but the esp8089 driver and wifi fixes have been introduced the 3rd Oct 2022. Use a newer image or do apt update && apt upgrade. The emmc in those logs looks fine to me, it is detected correctly and I don't see any error. Upgrade and send again the URL from armbianmonitor -u

@Maker39 Well maybe the eMMC is really broken if it kernel can't write the sector 0 of the device but doing those tests with rk322x-config may help. About the esp8089, you should post dmesg log (or, even better, the URL given by armbianmonitor -u). The esp8089 driver is there and it is perfectly working. Did you select the right led-conf from rk322x-config? (Yours should be led-conf6) Also the original dtb may come handy

@Maker39 Yes, that piece of dmesg is exactly was I looking for and it explains the reason why the device does not boot from emmc. It could be that the eMMC is broken, but if Android was booting and working fine I guess the part is physically ok and there is some configuration issue. I suggest to you to run armbian on sdcard and do some tests with rk322x-config. You need to try the various combinations from the eMMC section: From there try these combinations: * emmc-pins alone * emmc-pins + emmc-ddr-ph45 * emmc-pins + emmc-ddr-ph180 * emmc-pins + emmc-hs200 * don't set any options and see if any of them provides stable access to eMMC. On every reconfiguration of course you need to reboot the machine. If you get a fairly stable combination, you can install it onto emmc. Another question: was the multitool able to access the eMMC without particular issues?

@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.