jock

@MattWestB @SteeMan I've been thinking about that too and I would have liked to ask @Igor in the last release meeting but I did not want to be off-topic. Perhaps the community images are "too edgy", and perhaps it is more savvy to produce images with current kernel, then upgrade to edge via apt install, than starting with edge kernel, that is not guaranteed to work correctly, and then downgrade to current. I just had a very brief test after burning an image with kernel 6.1 and, against all my thoughts because I was sure I already checked kernel 6.1, it does not boot on my rk3318 box, while kernel 6.0 had no troubles in booting (broadcom bluetooth was broken although). Did not have the time and tools at hand to dig into the issue (moving into a new house...), but I hope to check better very soon, perhaps during the weekend. About moving rockchip64 to 6.1 for the next release, I'm a bit reluctant and maybe a bit more testing is required. 32 bit rockchips although seems rather acquainted with 6.1, no issue and no troubles so far (my HA testing rig on rk322x has an uptime of 10 days and doing a variety of jobs that is pretty amazing for the piece of junk it was )

@Serkan Polat no static public address, hundreds of device behind NAT, ... sounds like you should work on network level rather than trying to get access to the devices using some trick that firewalls may intercept. For example, I would consider to let your devices establish a VPN targeting an external public server that acts as a gateway. If your firewall allows free outbound traffic you should have no issues with wireguard/openvpn solution.

Hello, good you finally had the board running happily armbian. It would be nice if you could detail a bit over the non-working images: kernel version, where you did pick them, do you get something on the serial port if you have any, do the led is blinking while you try to boot or it is steady... You should be able to burn a testing image and a sdcard, plug it in and the system should boot from sdcard instead of internal eMMC.

You can read exactly two posts above yours.

@kfj Hello, I imagine you are powering off and on the board when you experience such issue, aren't you? The brand name of the tvbox says nothing about the board itself, so it is not helpful for other digging. Although sometimes it happens on a board of mine that on reboot the board does not boot from sdcard and then requires another power cycle to boot again. Anyway you may want to install armbian on internal eMMC, since it looks it works ok on your board.

@Elbie Kittens Thanks a lot! I'm sorry I told you that you already should have been in maskrom mode, but it really had to work that way if you erased the eMMC. I really don't what was wrong in first instance. Surely the serial log would have been helpful. About the tools, I don't know what tools are you using, but the armbian images are provided as xzipped raw images, not the proprietary format expected by AndroidTool for Windows, for example. Multitool is capable of burning them decompressing them on the fly, otherwise rkdeveloptool is able too but you have to decompress them first. Anyway yes, it is very odd what you describe. X88 Pro has been tested in the past and should work without issues with armbian.

@Elbie KittensAFAIR I don't remember a rockchip device that was unable to be restored using the maskrom mode + male-to-male cable. You can go with emmc clock pin shorting, probably one of the pads behind the eMMC is the right one, nonetheless in you erased the eMMC it should already go in maskrom mode.

@sum1saw you're welcome, at least you have been able to restore the original firmware and the device is not bricked anymore

@sum1saw Very well, the fact that you found the emmc clock pin is a great advancement! There is no issue with power with your board. The problem you are facing is one of the first great headaches I had when I was first dealing with these boards. In practice when you give the signal to power on the board through the button, the ACT8846 PMIC receives a signal to turn on the board. The ACT8846 then starts powering the SOC and the firmware boots. The firmware then must raise a GPIO to tell the ACT8846 that the board has been really powered on and it has to hold the power on. If the ACT8846 does not receive this feedback signal, it cuts the power. If you keep the power button pressed, you can let the ACT8846 hold the power on for up to 10 seconds. Another way hold the power on should be the presence of the OTG cable connected to PC and the board, or at least this happens on my board. This message: Unknow param: PWR_HLD: 0,0,A,0,1! tells that the firmware wants the GPIO (bank 0x0, GPIO pin 0xA) that needs to be turned on (1) to keep the power on, but somehow u-boot does not understand that parameter, does not raise the GPIO and then the ACT8846 shuts the whole thing down. Now the problem you have with AndroidTool makes me think if you have the right firmware for your device and the right AndroidTool for your device... maybe you need an older version since the rk3288 is a bit old device? Also try and see if you are able to Erase the flash from Android Tool while you're in maskrom mode: that won't brick your device, but will force the device to boot from sdcard or, if no sdcard is found, go in maskrom mode without having to short the emmc clock pin anymore. (some reference here) I don't know if you also have a raw image of the good firmware, in such case you may also try to boot with the multitool sdcard inside the slot and try to burn the raw image directly from there.

@fr3d are you sure the wlan0 device isn't changing the MAC address on each reboot? I read from the @atone's link the same error can happen when there is a MAC address blacklist.

No, the pads on the back of the board must not be shorted together! They must be shorted, in turn, to a ground point of the board, like the HDMI or ethernet metallic chassis. The other part should be exactly like you describe: if there is no sdcard, the device goes in maskrom mode and it should appear automatically in Android Tool; instead if the sdcard is inserted, the soc will try to boot from there and, if a suitable image is found, the serial will tell you that the boot is happening.

@sum1saw Well that's definitely NOT in maskrom mode. The device is booting, but then it gets stuck in u-boot for some reason. Also it looks like it is lacking the "miniloader" part, hence does not boot from sdcard, but it could easily be that u-boot gets stuck and does not go further. IMHO you definitely need to short the emmc clock pin, either to get into maskrom mode or force the device to boot from sdcard. The procedure: 1) remove power plug 2) insert power plug 3) put the screwdriver on the emmc contacts to short emmc pins or short the pad on the backside to GND 4) turn on the board (via power button) 5) unshort the emmc clock pin 6) you should not see anything on the serial; if you get any message from ddrbin/u-boot, then the board booted from eMMC, so start again from 1) and try another pair of contacts or the other pad on the backside 7) if you have the sdcard inserted, the board will probably boot from there, otherwise plug the USB male to male cable in the OTG port and into PC 😎 you should see the device in maskrom mode with lsusb tool within linux 9) use rkdeveloptool to restore the original firmware

@Elbie Kittens If you erased the emmc, it must be in maskrom mode, there is no further need to short the eMMC clock pins. f it is in maskrom mode, the serial will be totally silent. Beware that there are other possible serial pins on the front side of the board, nearby the IR receiver. I don't remember which ones where in use for debug. Beware that you MUST connect the USB cable in the OTG port only, other ports won't work at all. Your board should have one USB2 and one USB3 port, the OTG should be the USB2 port. Also you should also try with and without the power plug connected, but try to power the box only via USB cable: when the USB cable is inserted in the USB OTG port, the box should be automatically powered on. Last but not least: when you plug the cable, you should use lsusb tool to see if there is a rockchip device in maskrom mode, and not wait for something to automatically show up like a storage device.

@atone uhm, very interesting finding link, thanks. I hope it helps @fr3d

@fr3d Thanks, happy new year to you too! The OF dtb is shared among regular tinkerboard and tinkerboard S, the latter should just have a soldered eMMC. About the still missing secret, well, I really don't know what's wrong. Looks like a software issue rather than hardware/dtb related. If you could try a different router or a different distribution (maybe a debian one) could give some more hints... Also are you using WPA3?

@MR01 Well I don't know if there will be newer kernels with libreelec patches imported like the special 5.19 one I did; it took me quite an amount of time to refactor the existing armbian patches and at last they went to waste despite they seem to provide compatibility and performance benefits.

@MR01 that 5.19.15 version was an experimental version; I compiled it without the extra wifi drivers because they were causing compilation issues. If you need something "stable" you should stay stick with the community version available on github which is updated regularly and prefer the "current" kernel flavour in place of edge.

@sum1saw The chances that the pointed CLK pin is the right one are near to zero, I can exclude that one is the clock pin you're looking for. I was referring to the pads I circled in green in the attached image, and only to those ones! Don't go blind shorting pins randomly, or you will surely damage something. Feeding a bad voltage to the wrong device can easily damage it. Also I see another "PWRON" label which is probably the power on button. Probably you need to briefly short that pin to 3.3V or 5V depending on which one is available during the board "stand by" to give power to the system. I don't think "volume up" is of any use in this case.

@MR01 It should work as usual, that part never changed and the boot priority is always sdcard -> USB -> eMMC. I don't remember if there were minor or major bugs in that part in the past. Perhaps you can try to upgrade the bootloader with apt update && apt install linux-u-boot-rk322x-box-current, but usually it is best to upgrade bootloader and kernel together, so I don't suggest to do that. You can also try to boot multitool from USB stick, but the best way to do experiments is to burn an armbian image onto sdcard or USB stick so you don't touch the installed system. Of course remember to decompress the image first, if your image writer does not so automatically.

@Elbie Kittens AFAIR the X88 has the sdcard connected to sdmmc_ext bus, that's the reason why it won't boot from sdcard when firmware is erased. You should have install the armbian image right after erasing the emmc. Now you are probably in maskrom mode, the board should show when connected to PC via USB male-to-male cable, but you have to use the board USB OTG port. Then you can use rkdeveloptool to upload an armbian image. Read the paragraph The Multitool does not boot / How to burn image directly on eMMC on the support page

@umiddelb true, the serial speed is configurable but newer SOCs than rk3288 have their default set to 1.5mbps, rk3288 and older socs have their default set to 115kbps. At last, it totally depends upon the ddrbin/loader software because the SOC does not talk on the serial by itself.

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