Controller never released inhibit bit(s)

[anon50890781]

@Shulyaka

What does partition table on a normal device look like?

Partition Map for MMC device 0  --   Partition Type: DOS

Part    Start Sector    Num Sectors     UUID            Type
  1     2048            15267840        799aaebd-01     83

The various I/O errors would seem to indicate the eMMC being gone. The various mmc commands unfortunately do not provide suitable tools to check the health of the eMMC…

As a last resort perhaps mmc hwpartition but likely that any attempt of data recovery afterwards will be futile. If that command however also fails with I/O then I reckon it would be clear that the eMMC is definitely gone.

[Shulyaka]

It feels like some of the blocks are still readable with dd, just not the first ones that define a partition table.
My plan is to get the system running with mSATA SSD, then create a dump of /dev/mmcblk0 (of what’s readable) and attempt to recover data from it. I will also try to use UART1 for my zigbee modem (will need to get an xbee module for that).
Is mmc hwpartition essentially the same as fdisk? I mean, I know on some ARM boards the partitions are somewhat more complicated than gust a block device with a DOS partition table on it, don’t remember the details though.

[anon50890781]

@Shulyaka

Is mmc hwpartition essentially the same as fdisk?

Both would appear userland. Not sure whether mmc hwpartition is just a wrapper for fdisk or different code entirely.

Once you got the dump perhaps also worth looking into

mmc read addr blk# cnt
mmc write addr blk# cnt
mmc erase blk# cnt

[cynerd]

@anon50890781

Do you know whether the USB device port designation will be static or random, e.g. currently with the interior port only the env variable is set to usb 0:2 (0=device port and 2=partition on that device).

What I am trying to ask is whether the ports are static designated in a way like:

interior = port 0 (or 1 or 2)
exterior front = port 1 (or 0 or 2)
exterior back = port 2 (or 0 or 1)

This should be stable up to my knowledge but can probably change if device tree or drivers change so stable-ish.

@anon50890781

On a 5x TO installation with u-boot-omnia 2019-07-4.0 the UART output however reads

Updates do not update firmware, only software on mmc. Firmware is stored on nor memory on board and can be updated voluntarily with nor-update but even that only updates it to version we consider stable. It can also update it to development version (latest build shipped with system) but that version is not tested and advice is to not use it.

[anon50890781]

@cynerd

Firmware is stored on nor memory on board and can be updated voluntarily with nor-update

that produces`from a fully booted node

-ash: nor-update: Permission denied

Is that supposed to work from the rescue shell?

`

[cynerd]

It should not work. Rescue shell is old version of Turris OS in core and this script is probably missing some files and most probably shouldn’t be there. You have to run it from standard system.

[anon50890781]

@cynerd

You have to run it from standard system.

Did that and it produces aforementioned

-ash: nor-update: Permission denied

[cynerd]

I see. I can reproduce it. It is not marked as executable for some reason.