MaxT

It would be great, if you could post results of all your findings here, so that someone else could save a few hours on this problem and rather spend them on another one;)

May be worth looking into armbian-install script? Just a thought.

I would open the box make photos of the board with silk prints visible and search similar box in a relevant section of tv boxes on this forum. Name on the plastic box means nothing, silk prints on the board and SoC itself might help.

Probably marking on the board is the only what really matters.

Thanks, very helpful. Maybe someone will be able to bring some light on how second partition could appear (uboot update script transition bug?), while being not a part of Armbian's functionality.

Context of the TV boxes section might be helpful, especially in the sticky thread re their status in Armbian.

If tester is not available, I'd try powering failing ports with their respective cables but feeding them from pins powering other ports (eg with wires from some molex cable, just need to be careful with polarity and shortcuts) and then powering working ports from pins on the board feeding failing ports - to exclude failure of the power rail feeding these ports on the board. If cables are faulty, I'd check them for electrical connections and if they are ok, would replace capacitors.

Disabling automount (drive letter assignment) in windows before flashing might help - probably it is mount time when windows is checking and changing partition table.

I wouldn't be so categorical - I have rock pi 4b, which never saw android or any os other than armbian, which has same thing- two boot devices on emmc. Since it doesn't bother me, I didn't investigate further.

If I remember correctly, recently there was a similar thread on the forum re GPT corruption under windows. Not sure, but there might be some useful info. Alternatively, flashing under Linux might be an option.

WSL might be easier if you're on windows

Either of those, I personally used Ubuntu running in ESXi VM

Are you joking? Open readme.md in GitHub repo, read it and explore links therein

As per documentation, run on a compatible host: git clone https://github.com/armbian/build cd build ./compile.sh Follow screen menus. Build system will download necessary toolchain, sources, patches, etc and build an image. Whether or not it will work depends on whether sources/patches for a particular board deviated from the hardware due to time or bugs. If someone is regularly testing then image likely will be ok, if not then image might work or not. If the board has community maintained status, then it is up to its users to test/develop/send patches in GitHub. If necessary, it is possible to play with sources, configs, develop and place extra patches, etc. At times it looks not that straightforward, so there will be a learning curve.

I guess they are free to spend that time to develop own samba implementation

It would be interesting to compare corrupt and non corrupt cards, including partition tables, etc. Windows might be playing bad with partition tables - if one only inserts ESXi boot disk into windows machine, such disk becomes non bootable. AFAIR this is because ESXi relies on records order in the gpt table of the disk, while windows strips away blank records so that if eg second and third records are blank then windows will move the fourth record to the second place, while ESXi relies on the fourth record in a table. I personally met this issue a few years ago and it took a while to find the solution of reordering gpt table records back to restore ESXi boot.

If I remember correctly, it is possible to mount such partition flashed to usb or sd within WSL (just ensure that proper support is installed into WSL) and make any changes. It is possible even to script changes to be run under windows, though I can't remember how exactly this is done. Probably AI can hint.

yeah, frustration is quite clear, but probably it is manufacturer who should be most/only interested in that. that also cost quite a lot, so it is probably better to demand where money were paid to, i guess.

AFAIR someone on this forum also experienced booting issue with orange pi board though 4 not 5 with quite similar symptoms. May be worth contacting that person for his results so far - might give some hints on what's going on and whether it's a manufacturing fault

google/AI Hint: ext4

@Gwolf2u Hate to disappoint, but if your YP-01 serial converter is based on PL2303 chip, it will not work with Rockchip CPUs based boards as pl2303 doesn't support baud rate of 1 500 000 required for Rockchip CPUs (table 6-2 in the attached datasheet). DOC001036118.pdf

If you have uboot on emmc, to boot purely from SD, you have to either erase emmc or mask it. Try booting with maskrom pressed and having SD cards in the slot, if in the maskrom mode SD slot is not masked, bootrom will pick up uboot of SD since will not find emmc.

I'm not armbian team member, though feel that alike notes might be not welcomed at best. Kind advice- if someone doesn't like smth or believe smth should be improved, someone is advised to send a PR, otherwise keep silent. Re booting from SD - if you have uboot on the emmc it will be picked up by SoC's bootrom even if you manage to put several SD cards into the slot . Boot order starts from bootrom which is hardcoded in the SoC and it has its strict order to search for loader(s) - u-boot in this case (actually comprising of several loaders/firmwares). Uboot in turn has its own, though configurable, order of scanning media for kernel image. So if you have uboot on emmc AND uboot on SD with kernel, uboot on SD is ignored by bootrom.

Seems to be innovative way to get positive attention of the team to issues you face. Good luck with that.

@renard If you have u-boot on emmc, there might be incompatibility between u-boot on emmc and u-boot required to load kernel from SD. IIRC bootrom is looking on fixed storage first (SPI flash, emmc) before going to SD and if uboot is found on a fixed storage, this one is used. Uboot, however, is configured to look for kernel on removable storage first (USB, SD card) and load kernel from one of these if found.