Hi, I need help identifying the Maskrom/eMMC short points for an RK3528 TV box. Device: - TV box sold as H20 Pro - SoC confirmed as Rockchip RK3528 - Board marking: M16-R6B-L3-V1.0-260121 - RAM detected in Linux: 963 MiB - eMMC detected in Linux: 7.83 GB / 7.30 GiB - eMMC name from Linux: P1J95K - eMMC CID: fe014e50314a39354b12739109744200 What happened: - The box originally booted Android from eMMC. - Armbian booted successfully from SD using a customized joilg/x88pro-based image. - Later I wrote U-Boot/idbloader to eMMC: - idbloader.img at sector 64 - u-boot.itb at sector 16384 - After reboot, the board no longer boots from SD or eMMC. - LED stays red. - No HDMI output. - No Ethernet link/activity. - RKDevTool on Windows shows "No Devices Found". Recovery attempts: - Tried the reset/recovery button behind the AV/P2 jack while connecting power and USB. - Tried both USB ports. - Tried RKDevTool v2.86 with Rockchip drivers installed. - No Loader or Maskrom device appears. - Tried UART pads marked GND/TX/RX using ESP32-C3 as bridge, but output is not readable. Question: Can anyone identify the eMMC Maskrom short point for this board? I need to force RK3528 into Maskrom mode so I can restore the first bootloader area of the eMMC. Attached photos: - Front of board - Back of board - Macro photo of the eMMC/storage chip area - Macro photo of test pads near the storage chip

I tried to downgrade to 6.18, unfortunately it froze during the process, which left the kernel and boot loader in an incomplete state. I have decided to re-image the whole thing with 6.18.x and for now it appears to be stable again.

Your previous post reminded me that the board supplier changed the BOM of the ODROID-N2+ by using a different SPI flash vendor. He hacked the support for it into his legacy firmware build without making any further note about it. It took some effort of reverse engineering to figure that out. Mainline hasn't picked up this additional driver activation to this day, but I still keep it in my builds anyway. In my latest build for the ODROID-HC4, I also included this driver to see if they might have gone about it in the same way. But your confirmation shows that this is probably not the case. Since I don't have an ODROId-HC4 with the behavior you described on hand, I can't analyze any further what the cause of it is. These days, I also mostly avoid devices with Amlogic SoCs because of their strict closed-source policy and lack of mainline support. And the board manufacturer isn't much more helpful on this point either. Devices powered by Rockchip are much more appealing objects. So you have to help yourself if you want to find a solution.

These most recent edge updates for K1 based boards are really great! With all this mainline additions of kernel 7.2 it's finally becoming a trustworthy clean alternative to outdated vendor images. At least for headless micro server usage everything is now already provided by mainline code (e.g. temperature and CPU frequency control are indispensable for serious work on this board!) Only WiFi and BT still don't work out of the box. I personally would prefer utilizing mainline brcmfmac drivers instead of fighting with all those unmaintainable bmcdhd patches. That's working for other boards with AP6256 modules as well.

OK I see: # dmesg | grep watchdog [ 0.462093] sunxi-wdt 1c20c90.watchdog: Watchdog enabled (timeout=16 sec, nowayout=0) That would mean study 'bark' or so, forgot most of it. I guess the board should restart if IPv6 LL connection is not there for more than 1 minute or so, but in relation to NAS makes then only sense if I move from NBD to iSCSI or so.