[ Solved] Turris Omnia bricked

Hi,
I spent a lot of time searching on this forum and I did not manage to resolve my problem.
I have an old Turris Omnia, from the first model I think which does not boot.
I tried flashing uboot, a new medkit, etc. Nothing worked.
The serial console output is:

U-Boot SPL 2015.10-rc2 (Aug 18 2016 - 20:43:35)
High speed PHY - Version: 2.0
SERDES0 card detect: SATA

Initialize Turris board topology
Detected Device ID 6820
board SerDes lanes topology details:
 | Lane #  | Speed |  Type       |
 --------------------------------
 |   0    |  6   |  SATA0       |
 |   1    |  5   |  USB3 HOST0  |
 |   2    |  5   |  PCIe1       |
 |   3    |  5   |  USB3 HOST1  |
 |   4    |  5   |  PCIe2       |
 |   5    |  0   |  SGMII2      |
 --------------------------------
:** Link is Gen1, check the EP capability
PCIe, Idx 1: remains Gen1
:** Link is Gen1, check the EP capability
PCIe, Idx 2: remains Gen1
High speed PHY - Ended Successfully
DDR3 Training Sequence - Ver TIP-1.29.0
Memory config in EEPROM: 0x02
DDR3 Training Sequence - Switching XBAR Window to FastPath Window
DDR3 Training Sequence - Ended Successfully


U-Boot 2015.10-rc2 (Aug 18 2016 - 20:43:35 +0200), Build: jenkins-omnia-master-23

SoC:   MV88F6820-A0
       Watchdog enabled
I2C:   ready
SPI:   ready
DRAM:  2 GiB (ECC not enabled)
Enabling Armada 385 watchdog.
Disabling MCU startup watchdog.
Regdomain set to **
MMC:   mv_sdh: 0
SF: Detected S25FL164K with page size 256 Bytes, erase size 64 KiB, total 8 MiB
PCI:
  00:01.0     - 168c:003c - Network controller
PCI:
  01:00.0     - 11ab:6820 - Memory controller
  01:01.0     - 168c:002e - Network controller
Model: Marvell Armada 385 GP
Board: Turris Omnia SN: 0000000B000154F5
Regdomain set to **
SCSI:  MVEBU SATA INIT
Target spinup took 0 ms.
SATA link 1 timeout.
AHCI 0001.0000 32 slots 2 ports 6 Gbps 0x3 impl SATA mode
flags: 64bit ncq led only pmp fbss pio slum part sxs 
Net:   neta2
Hit any key to stop autoboot:  0 
Setting bus to 1
BOOT eMMC FS
btrfs probe failed
** Unrecognized filesystem type **
btrfs probe failed
** Unrecognized filesystem type **
Bad Linux ARM zImage magic!
=>

Looks like the eMMC storage is dead. You can try to set boot from the USB drive.

Booting from USB with the U-Boot SPL 2015.10-rc2?

Thanks @hagrid, at some point I figured this may be that as nothing else worked.
Is it straightforward to replace the eMMC storage and flash it?

What I would You can get some info is to flash the newest U-boot. You can get some info reading How to flash a new u-boot on Turris Omnia - #39 by hagrid or follow the official documentation on Omnia - Turris Documentation and omitting the serial boot process as your current bootloader is not corrupted.

Replacement of the eMMC is not rentable as it is soldered on the PCB and you need to have access to really expensive tools.
As an alternative you can install the mSATA SSD and load the system onto it. Details are in the documentation.

Thanks, I already tried updating u-boot without success.
I tried with serial console and it failed, with USB I get this error:

=> usb start
starting USB...
USB0:   USB EHCI 1.00
scanning bus 0 for devices... 1 USB Device(s) found
=> load usb 0 ${kernel_addr_r} uboot
** Bad device usb 0 **

As I was not seeing the eMMC, I checked the board schema and figured out that I have an SSD installed on the SATA port (under which is the eMMC) which must have been added by the past owner of the router.
And also, when trying to solve my problem, some answers seemed related to LXC, and from what I found on the SSD, LXC containers may have been used as well.

I figured this could be an interesting input to help me fix this router.

What went wrong with the serial transfer?

I retried, and the problem was not in the copy but when writing the image to nor.
Here is what I get in the serial console:

=> loadx
## Ready for binary (xmodem) download to 0x00800000 at 115200 bps...
C## Total Size      = 0x000bfa4c = 784972 Bytes
=> sf probe
SF: Detected S25FL164K with page size 256 Bytes, erase size 64 KiB, total 8 MiB
=> sf update ${kernel_addr_r} 0 ${filesize}
device 0 offset 0xbfa4c, size 0x7405b4
Failed to map physical memory

Hm, can you type echo ${kernel_addr_r}? I guess this variable is not defined.
Can you try to use sf update 0x00800000 0 ${filesize}?

Once I experienced something similar when I broke Omnia boot from mSATA SSD (it was caused by some error in reforris when I plugged in USB Flashdisk and formated it in reforris which somehow corrupted MBR on SSD) what helped was to take SSD out and boot from internal flash and then reformat SSD, put it back and do fresh migration to SSD which is rather easy as all you need is to create first btrfs partition on SSD in BTRFS and unpack actual omnia medkit from https://repo.turris.cz

What if you go other way around and try install mSATA SSD and boot from mSATA, you will need the TTL-USB cable for it as I already mentioned somewhere here but was deleted by Pepe upon someone’s GDPR request.

Thanks @hagrid and @Twinkie.

${kernel_addr_r} is not defined indeed.
sf update 0x00800000 0 ${filesize} worked as expected, after reset I have the new U-Boot 2019.07 and now over serial I see BOOTP broadcast loop.

Can I securely restart and try removing the SSD as suggested by @Twinkie? When the SSD is removed, do you sugggest to re-flash with the latest medkit?

Well, no. I will tell you how I proceed with this situation.

I’m a lazy person :slightly_smiling_face: and I do not like to always remove the SSD (I don’t even have a device where I can put it to format it and prepare the partition) so I have the USB stick with the TurrisOS system. I boot the Omnia from the USB stick, then from the running system prepare the SSD with the TurrisOS and then I just change the bootloader to let the Omnia boot from the SSD drive.

Your internal eMMC drive is dead, there is no way to flash it with the medkit.

Ok, so I imagine I would need to follow the instructions from here?

Ok, I thought that maybe the problem was caused by the fact I have a corrupted SSD and the eMMC may be just fine.

I would suggest to follow Boot from SSD - Turris Documentation

This describes the process how to prepare the SSD drive from the running TOS, but you can use it as an inspiration how to prepare the USB stick by using your personal computer.
The only change is, to boot it from the USB stick, you need to set the bootloader with
setenv boot_targets usb0 without saving the environment. This will make the Omnia to one time boot from the USB. Then you can follow the documentation again, now with all the steps.

You putted there an extra space between usb and 0! Maybe thats why it doesnt want to boot from usb.

No, that is a correct syntax. The very old U-boot had problems with the USB subsystem.

That worked. Thanks @hagrid and all for your quick help!