Don't get my Turris Omnia to boot from mSATA SSD

Software SW help
1

Hi,
I open a new topic even though there are a lot of topics which are already dealing with booting from mSATA in different ways. In my case it seems like just the very last step that will not work.

My initial reason to switch from eMMC to mSATA was this topic:

I done so and bought a serial cable and KINGSTON SKC600M (256GB) mSATA SSD.
I installed the SSD and followed the guide:

  1. uBoot update from U-Boot SPL 2015.10-rc2 (Aug 18 2016 - 20:43:35) to U-Boot SPL 2022.10-rc4-OpenWrt-r16653+119-44ce70f0e2 (Sep 15 2022 - 18:21:35 +0000) via turris-nor-update worked without problem.
  2. Next steps at “Preparation of SSD” went also good. I decided to use my last schnapps snapshot instead of the latest medkit.
  3. Next steps at “Updating U-Boot to boot from SSD” resulted after reboot always in booting from eMMC.

That’s what the console logging say’s:

Console Log 
U-Boot SPL 2022.10-rc4-OpenWrt-r16653+119-44ce70f0e2 (Sep 15 2022 - 18:21:35 +0000)
High speed PHY - Version: 2.0
MiniPCIe/mSATA card detection... mSATA
WWAN slot configuration... PCIe+USB2.0
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	|
 --------------------------------
High speed PHY - Ended Successfully
mv_ddr: 14.0.0 
DDR3 Training Sequence - Switching XBAR Window to FastPath Window
mv_ddr: completed successfully
Trying to boot from SPI

U-Boot 2022.10-rc4-OpenWrt-r16653+119-44ce70f0e2 (Sep 15 2022 - 18:21:35 +0000)

SoC:   MV88F6820-A0 at 1600 MHz
DRAM:  2 GiB (800 MHz, 32-bit, 2T, ECC not enabled)
Core:  72 devices, 26 uclasses, devicetree: separate
WDT:   Started watchdog@20300 with servicing (60s timeout)
MMC:   mv_sdh: 0
Loading Environment from SPIFlash... SF: Detected s25fl164k with page size 256 Bytes, erase size 4 KiB, total 8 MiB
OK
Model: Turris Omnia
  MCU type: STM32
  MCU version: b5a8a24e007eb72be16aeb3fff6f03ec647023e4
  RAM size: 2048 MiB
  Serial Number: 0000000B00002116
Disabling MCU watchdog... disabled
Regdomain set to **
pcie1.0: Link up
pcie2.0: Link up
Net:   eth0: ethernet@70000, eth1: ethernet@30000, eth2: ethernet@34000 [PRIME]
Hit any key to stop autoboot:  3  0 
=> setenv boot_prefixes / /boot/ /@/boot/
=> setenv boot_targets scsi0 mmc0 nvme0 usb0 pxe dhcp
=> printenv boot_prefixes
boot_prefixes=/ /boot/ /@/boot/
=> printenv boot_targets
boot_targets=scsi0 mmc0 nvme0 usb0 pxe dhcp
=> run distro_bootcmd
scanning bus for devices...
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 
BTRFS: superblock end 69632 is larger than device size 0
  Device 0: (0:0) Vendor: ATA Prod.: KINGSTON SKC600M Rev: S480
            Type: Hard Disk
            Capacity: 244198.3 MB = 238.4 GB (500118192 x 512)

Device 0: (0:0) Vendor: ATA Prod.: KINGSTON SKC600M Rev: S480
            Type: Hard Disk
            Capacity: 244198.3 MB = 238.4 GB (500118192 x 512)
... is now current device
BTRFS: superblock end 69632 is larger than device size 0
switch to partitions #0, OK
mmc0(part 0) is current device
Scanning mmc 0:1...
Found U-Boot script /boot.scr
1199 bytes read in 32 ms (36.1 KiB/s)
## Executing script at 01800000
gpio: pin gpio@71_4 (gpio 20) value is 1
20883 bytes read in 36 ms (566.4 KiB/s)
4325992 bytes read in 285 ms (14.5 MiB/s)
Kernel image @ 0x1000000 [ 0x000000 - 0x420268 ]
## Flattened Device Tree blob at 02000000
   Booting using the fdt blob at 0x2000000
   Loading Device Tree to 0fff7000, end 0ffff192 ... OK

Starting kernel ...
Mount 
BusyBox v1.33.2 (2022-10-20 23:59:29 UTC) built-in shell (ash)
 -----------------------------------------------------
 TurrisOS 6.4.4, Turris Omnia
 -----------------------------------------------------
root@FW:/# mount
/dev/mmcblk0p1 on / type btrfs (rw,noatime,ssd,space_cache,commit=5,subvolid=281,subvol=/@)
devtmpfs on /dev type devtmpfs (rw,relatime,size=1031744k,nr_inodes=188192,mode=755)
proc on /proc type proc (rw,nosuid,nodev,noexec,noatime)
sysfs on /sys type sysfs (rw,nosuid,nodev,noexec,noatime)
cgroup2 on /sys/fs/cgroup type cgroup2 (rw,nosuid,nodev,noexec,relatime,nsdelegate)
tmpfs on /tmp type tmpfs (rw,nosuid,nodev,noatime)
tmpfs on /dev type tmpfs (rw,nosuid,relatime,size=512k,mode=755)
devpts on /dev/pts type devpts (rw,nosuid,noexec,relatime,mode=600,ptmxmode=000)
debugfs on /sys/kernel/debug type debugfs (rw,noatime)
bpffs on /sys/fs/bpf type bpf (rw,nosuid,nodev,noexec,noatime,mode=700)

I don’t have any idea what to do now or how I can fix this. There is one thing I see at the log that is this BTRFS: superblock end 69632 is larger than device size 0, but I can’t get rid of this.

Even this information don’t get me anywhere:

Just to add, I tried many things like adding setenv boot_prefixes / /boot/ /@/boot/, although you no longer have to do that.

  1. Create a symlink to the boot.scr file
    This will eliminate need to alter `boot_prefixes

What do I miss?

1 Like
2

I done some more testing - more likely try and error - and finally I got my Turris Omnia booting from /dev/sda1.

At the end I had to size the /dev/sda1 partition to the full disk size of 238.5G. Different sizes like 20G or 100G ended always with BTRFS: superblock end 69632 is larger than device size 0 error and booting from eMMC.

That’s the logging when I was able to boot into the SSD disk. No BTRFS superblock error any more.

Console Log 
root@FW:/# lsblk
NAME         MAJ:MIN RM   SIZE RO TYPE MOUNTPOINT
sda            8:0    1 238.5G  0 disk 
└─sda1         8:1    1 238.5G  0 part 
mtdblock0     31:0    0   960K  0 disk 
mtdblock1     31:1    0     7M  0 disk 
mtdblock2     31:2    0    64K  0 disk 
mmcblk0      179:0    0   7.3G  0 disk 
└─mmcblk0p1  179:1    0   7.3G  0 part /
mmcblk0boot0 179:8    0     4M  1 disk 
mmcblk0boot1 179:16   0     4M  1 disk 
root@FW:/# df
Filesystem           1K-blocks      Used Available Use% Mounted on
/dev/mmcblk0p1         7633920   1085260   6554836  14% /
devtmpfs                   512         0       512   0% /dev
tmpfs                  1032256    102668    929588  10% /tmp
tmpfs                      512         0       512   0% /dev
root@FW:/# mount
/dev/mmcblk0p1 on / type btrfs (rw,noatime,ssd,space_cache,commit=5,subvolid=281,subvol=/@)
devtmpfs on /dev type devtmpfs (rw,relatime,size=1031744k,nr_inodes=188192,mode=755)
proc on /proc type proc (rw,nosuid,nodev,noexec,noatime)
sysfs on /sys type sysfs (rw,nosuid,nodev,noexec,noatime)
cgroup2 on /sys/fs/cgroup type cgroup2 (rw,nosuid,nodev,noexec,relatime,nsdelegate)
tmpfs on /tmp type tmpfs (rw,nosuid,nodev,noatime)
tmpfs on /dev type tmpfs (rw,nosuid,relatime,size=512k,mode=755)
devpts on /dev/pts type devpts (rw,nosuid,noexec,relatime,mode=600,ptmxmode=000)
debugfs on /sys/kernel/debug type debugfs (rw,noatime)
bpffs on /sys/fs/bpf type bpf (rw,nosuid,nodev,noexec,noatime,mode=700)
root@FW:/# reboot
root@FW:/# Stopping router Turris.

U-Boot SPL 2022.10-rc4-OpenWrt-r16653+119-44ce70f0e2 (Sep 15 2022 - 18:21:35 +0000)
High speed PHY - Version: 2.0
MiniPCIe/mSATA card detection... mSATA
WWAN slot configuration... PCIe+USB2.0
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	|
 --------------------------------
High speed PHY - Ended Successfully
mv_ddr: 14.0.0 
DDR3 Training Sequence - Switching XBAR Window to FastPath Window
mv_ddr: completed successfully
Trying to boot from SPI

U-Boot 2022.10-rc4-OpenWrt-r16653+119-44ce70f0e2 (Sep 15 2022 - 18:21:35 +0000)

SoC:   MV88F6820-A0 at 1600 MHz
DRAM:  2 GiB (800 MHz, 32-bit, 2T, ECC not enabled)
Core:  72 devices, 26 uclasses, devicetree: separate
WDT:   Started watchdog@20300 with servicing (60s timeout)
MMC:   mv_sdh: 0
Loading Environment from SPIFlash... SF: Detected s25fl164k with page size 256 Bytes, erase size 4 KiB, total 8 MiB
OK
Model: Turris Omnia
  MCU type: STM32
  MCU version: b5a8a24e007eb72be16aeb3fff6f03ec647023e4
  RAM size: 2048 MiB
  Serial Number: 0000000B00002116
Disabling MCU watchdog... disabled
Regdomain set to **
pcie1.0: Link up
pcie2.0: Link up
Net:   eth0: ethernet@70000, eth1: ethernet@30000, eth2: ethernet@34000 [PRIME]
Hit any key to stop autoboot:  3  0 
=> setenv boot_prefixes / /boot/ /@/boot/
=> setenv boot_targets scsi0 mmc0 nvme0 usb0 pxe dhcp
=> printenv boot_prefixes
boot_prefixes=/ /boot/ /@/boot/
=> printenv boot_targets
boot_targets=scsi0 mmc0 nvme0 usb0 pxe dhcp
=> run distro_bootcmd
scanning bus for devices...
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 
  Device 0: (0:0) Vendor: ATA Prod.: KINGSTON SKC600M Rev: S480
            Type: Hard Disk
            Capacity: 244198.3 MB = 238.4 GB (500118192 x 512)

Device 0: (0:0) Vendor: ATA Prod.: KINGSTON SKC600M Rev: S480
            Type: Hard Disk
            Capacity: 244198.3 MB = 238.4 GB (500118192 x 512)
... is now current device
Scanning scsi 0:1...
Found U-Boot script /boot.scr
1199 bytes read in 23 ms (50.8 KiB/s)
## Executing script at 01800000
gpio: pin gpio@71_4 (gpio 20) value is 1
20883 bytes read in 29 ms (703.1 KiB/s)
4325992 bytes read in 105 ms (39.3 MiB/s)
Kernel image @ 0x1000000 [ 0x000000 - 0x420268 ]
## Flattened Device Tree blob at 02000000
   Booting using the fdt blob at 0x2000000
   Loading Device Tree to 0fff7000, end 0ffff192 ... OK

Starting kernel ...
Mount 
Router Turris successfully started.

BusyBox v1.33.2 (2022-10-20 23:59:29 UTC) built-in shell (ash)
 -----------------------------------------------------
 TurrisOS 6.4.4, Turris Omnia
 -----------------------------------------------------
root@FW:/# mount
/dev/sda1 on / type btrfs (rw,noatime,ssd,space_cache=v2,commit=5,subvolid=256,subvol=/@)
devtmpfs on /dev type devtmpfs (rw,relatime,size=1031744k,nr_inodes=188192,mode=755)
proc on /proc type proc (rw,nosuid,nodev,noexec,noatime)
sysfs on /sys type sysfs (rw,nosuid,nodev,noexec,noatime)
cgroup2 on /sys/fs/cgroup type cgroup2 (rw,nosuid,nodev,noexec,relatime,nsdelegate)
tmpfs on /tmp type tmpfs (rw,nosuid,nodev,noatime)
tmpfs on /dev type tmpfs (rw,nosuid,relatime,size=512k,mode=755)
devpts on /dev/pts type devpts (rw,nosuid,noexec,relatime,mode=600,ptmxmode=000)
debugfs on /sys/kernel/debug type debugfs (rw,noatime)
bpffs on /sys/fs/bpf type bpf (rw,nosuid,nodev,noexec,noatime,mode=700)
root@FW:/# df
Filesystem           1K-blocks      Used Available Use% Mounted on
/dev/sda1            250058052    190260 247775660   0% /
devtmpfs                   512         0       512   0% /dev
tmpfs                  1032256     20716   1011540   2% /tmp
tmpfs                      512         0       512   0% /dev
root@FW:/# lsblk
NAME         MAJ:MIN RM   SIZE RO TYPE MOUNTPOINT
sda            8:0    1 238.5G  0 disk 
└─sda1         8:1    1 238.5G  0 part /
mtdblock0     31:0    0   960K  0 disk 
mtdblock1     31:1    0     7M  0 disk 
mtdblock2     31:2    0    64K  0 disk 
mmcblk0      179:0    0   7.3G  0 disk 
└─mmcblk0p1  179:1    0   7.3G  0 part 
mmcblk0boot0 179:8    0     4M  1 disk 
mmcblk0boot1 179:16   0     4M  1 disk

My question is now. Why I can’t use the SSD with a partition /dev/sda1 that is not the full size of the disk?

The documentation says something different:

  1. Create a new primary partition. Its size must be at least the same as the original
    (eMMC) partition has (see above). Mark this partition as bootable.

Any ideas?

Thanks
Daniel

Update:
No other ideas came up. So I will stay with my workaround marked bold.

3 Likes
3

This topic was automatically closed 3 days after the last reply. New replies are no longer allowed.

5

It seems the newer U-Boot has a somewhat different implementation of BTRFS than the older one. In my case, the fix for this error was not necessarily deleting all but the first partition and extending the first one to the end of the disk. It showed sufficient to slightly enlarge the partition (without touching the filesystem residing on it).

My previous partitioning was:

/dev/sda1 : start=        2048, size=    33554432, type=83
/dev/sda2 : start=    33556480, size=   188743680, type=83
/dev/sda3 : start=   222300160, size=    12141488, type=83

With this partitioning, Omnia could not boot from the mSATA SSD.

I’ve enlarged the boot partition by 4096 sectors and recreated/moved the other partitions to fit and now I can boot flawlessly:

/dev/sda1 : start=        2048, size=    33558529, type=83
/dev/sda2 : start=    33562624, size=   188743681, type=83
/dev/sda3 : start=   222308352, size=    12133296, type=83

Of course, if you have some important data on the other partitions, you need to move them instead of just deleting and recreating slightly shifted. But that was not my case, I only had backups on sda2 and swap on sda3, so I ditched them.

Be aware that the UUIDs of the partitions will change after this operation, so update /etc/config/fstab accordingly. Storage plugin would also be affected if you have it on the mSATA SSD.

1 Like
6

Hi,
boot partiton means /dev/sda1 right?

If so, it didn’t work in my case. Size of original eMMC was 8GB.

Do I unterstand something wrong, within enlarging this partition?
Or should this partition to be enlarged by exactly 4096 sectors more to the originial eMMC?

7

I have a suspicion but I did not have time to prove it.

My suspicion is that if you just create a partition and mkfs.btrfs on it, it won’t work with the new u-boot. You need to create the partition, then mkfs.btrfs, and then extend the partition by a few sectors. I chose 4096 sectors in hope for good alignment of the next partition, but I didn’t do the math properly to know if it’s actually aligned. I think in one of my experiments i enlarged the partition by a single sector and it helped.

Maybe if you stretch the partition to the whole drive, then mkfs.btrfs makes the filesystem a bit smaller at the end, which is what the new u-boot needs.

8

If so, then the documentation should be adjusted.

  1. Create a filesystem on the new partition: mkfs.btrfs /dev/sda1
    9.1. Run cfdisk /dev/sda again and now enlarge partition /dev/sda1 by size x.

I havn’t tested this because of

My production Omnia is running now and I dont want to destroy it again.

and I don’t have a spare Omnia and need not more then one partition so far.

Maybe Turris team can check this.

Update:
Just a side note. I never created a second or third partition to my SSD. When I partly sized the boot partition, the rest of the disk was just empty space.

9

That’s right. But as I don’t have a proof, I also didn’t want to push it. I might get to testing it next week, but don’t rely on it.

1 Like
10

This topic was automatically closed 3 days after the last reply. New replies are no longer allowed.