SOC.sh issue - problems creating SD card from eMMC

Embedded Linux Discussions
1

I followed the instructions here:
https://www.digikey.com/eewiki/display/linuxonarm/BeagleBone+Black
to create a new file system/kernel for BeagleBoneBlack on an SD card.

I then used /opt/scripts/tools/eMMC/bbb-eMMC-flasher-eewidi-ext4.sh
to copy SD card to onboard flash. Made some additional changes to the file system and tried to create an SD card from eMMC flash using:
/opt/scripts/tools/eMMC/beaglebone-black-make-microSD-flasher-from-eMMC.sh

The command failed and I tracked it down to a problem with /boot/SOC.sh
Here is what mine looks like:
root@beaglebone:/opt/scripts/tools/eMMC# cat /boot/SOC.sh

spl_uboot_name=MLO
dd_spl_uboot_count=1
dd_spl_uboot_seek=1
dd_spl_uboot_conf=
dd_spl_uboot_bs=128k
dd_spl_uboot_name=
uboot_name=u-boot.img
dd_uboot_count=2
dd_uboot_seek=1
dd_uboot_conf=
dd_uboot_bs=384k
boot_name=u-boot.img
dd_uboot_name=

If I replace this file with a copy from a previous image, the command succeeds. What is the correct way of generating this file?

2

@AnneBruner, /boot/SOC.sh is generated via the “setup_sdcard.sh” script that is used to convert a generic image into a device specific image.

It was designed to share the bootloader type, it’s location, and where to find the files, along with partition information.

However as you built your rootfs manually, none of this information was stored on the file system. The script bbb-eMMC-flasher-eewidi-ext4.sh knows what to do in that situation as it’s default is to build an ext4 based partition on the eMMC. In that process it creates a base /boot/SOC.sh, which it forgets to write the other important details to /boot/SOC.sh

Use this version of /boot/SOC.sh, which was taken from current production images.

#!/bin/sh
format=1.0

board=am335x_evm

bootloader_location=dd_spl_uboot_boot
bootrom_gpt=

dd_spl_uboot_count=2
dd_spl_uboot_seek=1
dd_spl_uboot_conf=notrunc
dd_spl_uboot_bs=128k
dd_spl_uboot_backup=/opt/backup/uboot/MLO

dd_uboot_count=4
dd_uboot_seek=1
dd_uboot_conf=notrunc
dd_uboot_bs=384k
dd_uboot_backup=/opt/backup/uboot/u-boot.img

boot_fstype=ext4
conf_boot_startmb=4
conf_boot_endmb=
sfdisk_fstype=L

boot_label=BOOT
rootfs_label=rootfs

#Kernel
dtb=
serial_tty=ttyO0
usbnet_mem=

#Advanced options
#disable_ssh_regeneration=true

Regards,

3

Thanks for the info regarding SOC.sh. I was able to create an SD card using the suggested SOC.sh and it appears to have created a valid SD card.
However, I think something is not quite right with the filesystem/partitions.

fdisk -l shows for the SD card:

Disk /dev/mmcblk0: 14.9 GiB, 15931539456 bytes, 31116288 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0x4add9aa9
Device Boot Start End Sectors Size Id Type
/dev/mmcblk0p1 8192 31116287 31108096 14.9G 83 Linux

I am trying to reduce the size of the image and running into difficulties. I first tried using Win32 Disk Imager to create an img file from the SD Card (which seemed to work) and then use gparted to reduce the size of the partition. This resulted in an error as soon as I click on Apply.

Next I tried reducing the file size directly on the SD card:

root@beaglebone:~# **resize2fs /dev/mmcblk0 4G**
resize2fs 1.44.5 (15-Dec-2018)
resize2fs: **Bad magic number in super-block while trying to open /dev/mmcblk0**
Couldn't find valid filesystem superblock.

Running e2fsck results in:

root@beaglebone:~# **sudo e2fsck /dev/mmcblk0**
e2fsck 1.44.5 (15-Dec-2018)
ext2fs_open2: **Bad magic number in super-block**
e2fsck: Superblock invalid, trying backup blocks...
e2fsck: Bad magic number in super-block while trying to open /dev/mmcblk0

The superblock could not be read or does not describe a valid ext2/ext3/ext4
filesystem. If the device is valid and it really contains an ext2/ext3/ext4
filesystem (and not swap or ufs or something else), then the superblock
is corrupt, and you might try running e2fsck with an alternate superblock:

e2fsck -b 8193
or
e2fsck -b 32768

Found a dos partition table in /dev/mmcblk0

Noticed that the instructions I followed for copying the u-boot files were:

sudo dd if=./u-boot/MLO of=${DISK} count=1 seek=1 bs=128k
sudo dd if=./u-boot/u-boot.img of=${DISK} count=2 seek=1 bs=384k

and the SOC.sh has
dd_spl_uboot_count= 2
dd_uboot_count= 4

Would that make any difference?
Or maybe I am missing something else since I manually created the filesystem?

4

@AnneBruner, I wouldn’t trust Win32 Disk Imager. Just use gparted on another Linux System to resize the microSD.

Why do you need to make the partition smaller? There is a better way if your interested, using an Image file, rsync and few more tools…

The count values don’t matter too much, it will stop at the end of the file size, i should probally update the wiki with the current directions.

Regards,

5

I am trying to share the new BB image with co-workers in Europe. Previously I had created an .img file using Win32 Disk Imager and then used gparted to shrink - but as I mentioned, gparted fails for some reason. I have also tried creating an img file from the SD card using dd, but it did not complete. Got about 2/3 the way done and I got an error. Thought if I could shrink the size on the SD card, maybe dd would complete ok. Ultimately I would just like to reduce the size of the file they will need to copy across the pond and also get it to fit on an 8GB card. But also wanted to make sure there wasn’t something wrong with my image. What do you recommend?

6

I have made progress. I was able to create an SD card from my onboard flash, use an Ubuntu machine to shrink the partition (using gparted) and dd to resize the filesystem on the card, then use dd to import the SD card as an .img file. I think my problems might have had to do with using Ubuntu 16.04 and the version of mkfs.ext4?? I ended up creating a Ubuntu 18.04 VM which worked. Just a few more questions…

Is there a way to call beaglebone-black-make-microSD-flasher-from-eMMC that won’t automatically shutdown the system? We are calling this script from another script and would like to finish executing our script after the SD card is created.

When creating a filesystem manually, do I need to add the UUID to the uEnv.txt at some point?