Script based .img preparation for BBB - console outputs CCCCCC....

I made a script that creates image .img with two partitions (1 GB FAT16 with bootable flag where I store MLO, u-boot.img, uImage, am335x-boneblack.dtb, and boot.scr and 3GB EXT3 for ROOTFS). I call the script with ./script “imagename” and as an output I get imagename.img.
Then I flash it to the SD card with balena or using dd comand, mount it on my host PC and I see that all files are present, partitions checked with gparted and everything seems correct.
Apart from that I use separate SD card where I create two partitions manually with gparted, and copy all files manually.
When comparing two cards with different set of commands, content looks exactly the same.
The difference is that in the first case, when I try to boot BeagleBone Black I always see just CCCCCC in the console. In the case with manually partitioned card, everything is ok, board is booting normally.
This is my script:


# Check for the image name parameter
if [ "$#" -ne 1 ]; then
    echo "Usage: $0 <image-name>"
    exit 1

# Set the name of the output image file from the first script argument

# Define the paths

# Create an image of the desired size (4GB here)
echo "Creating a $IMG_SIZE image named $IMG_FILE..."
#fallocate -l 4G $IMG_FILE || exit 1
dd if=/dev/zero of=$IMG_FILE bs=1M count=$((4*1024)) # 4GB image

# Setup loop device
echo "Creating loop device..."
LOOP_DEVICE=$(sudo losetup --show -fP $IMG_FILE)
if [ -z "$LOOP_DEVICE" ]; then
    echo "Failed to create loop device"
    exit 1

# Calculate the end sector for the second partition
END_SECTOR=$((1024 * 1024 * 4 / 512))  # 4GB image size in 512-byte sectors

# Create partitions using sfdisk
echo "Creating partitions..."
    echo label: dos
    echo start=2048, size=2097152, type=6, bootable
    echo start=2099200, type=83
} | sfdisk $LOOP_DEVICE

# Wait for the kernel to recognize new partitions
sleep 10

# Format partitions
echo "Formatting FAT16 boot partition..."
sudo mkfs.vfat -F 16 ${LOOP_DEVICE}p1 -n BOOT
echo "Checking and repairing FAT16 filesystem..."
sudo fsck.vfat -a -v ${LOOP_DEVICE}p1 || exit 1

echo "Formatting ext3 root filesystem..."
sudo mkfs.ext3 ${LOOP_DEVICE}p2 -L ROOTFS
echo "Checking and repairing ext3 filesystem..."
sudo e2fsck -p -f ${LOOP_DEVICE}p2 || exit 1

# Wait for the system to settle
sleep 5

# Mount the FAT16 partition and copy files
echo "Mounting boot partition..."
mkdir -p ${MOUNT_DIR}/boot
sudo mount ${LOOP_DEVICE}p1 ${MOUNT_DIR}/boot
echo "Copying bootloader files..."
sudo cp ${MLO_PATH} ${MOUNT_DIR}/boot # MLO should be copied first
sleep 1
echo "Unmounting boot partition..."
sudo umount ${MOUNT_DIR}/boot || exit 1
sleep 5

# Mount the ext3 partition and extract root filesystem
echo "Mounting root filesystem..."
mkdir -p ${MOUNT_DIR}/rootfs
sudo mount ${LOOP_DEVICE}p2 ${MOUNT_DIR}/rootfs
echo "Extracting root filesystem..."
sudo tar -xpf ${RFS_TAR_PATH} -C ${MOUNT_DIR}/rootfs
echo "Unmounting root filesystem..."
sudo umount ${MOUNT_DIR}/rootfs || exit 1
sleep 5
# Clean up
echo "Cleaning up..."
sudo losetup -d ${LOOP_DEVICE}
rm -rf ${MOUNT_DIR}/boot ${MOUNT_DIR}/rootfs
sleep 10
# Compress the image
#echo "Compressing the image..."
#xz -z ${IMG_FILE}

echo "Image ${IMG_NAME}.img.xz created successfully"

Can someone point out where the issue can be? I have exactly same SD cards, and one is working and another is not.
Did I miss something, and can someone suggest another approach?
Thanks a lot.

while this is correct according to the docs, dd’ing MLO, u-boot*.img to the start of the drive tends to be more reliable…


1 Like

Hi Robert,
Thank you for your prompt response! What would be modification to my script?
I am suspicious if that would solve my issue, especially because it works with the manual partitioned SD card with gparted and manual placing files to partitions.
When I flash script cretaed image it can not even load MLO, but SD card are exactly same.

Hi Robert,

In addition ti my previous answer I tried writing this on my SD card to check if it will boot from raw sectors.

sudo dd if=./MLO of=/dev/sda count=1 seek=1 bs=128k
sudo dd if=./u-boot.img of=/dev/sda count=2 seek=1 bs=384k

MLO can be found but not u-boot.img. Do you maybe know why u-boot.img is not loading?

Btw. still need to integrate this in my script to automate the process of simple imafe creation.


It’s changed over time… newer u-boot builds, build u-boot-dtb.img much older verions was simple u-boot.img use… u-boot-dtb.img today…

also bump your count: repos/bb-u-boot-am335x-evm-debian-11-ubuntu-2004-2204/suite/bookworm/debian/ at master · rcn-ee/repos · GitHub

dd if=${wdir}/MLO of=/dev/mmcblk0 count=2 seek=1 bs=128k
dd if=${wdir}/u-boot-dtb.img of=/dev/mmcblk0 count=4 seek=1 bs=384k


Hi Robert,
Since I use u-boot version 2022.04 it still builds u-boot.img.
If I bump count to 4 like you suggested, that means that partition can not start from default sector 2048 (1MB offset) becaus u-boot.img will overwrite it and I need to bump it as well, correct?

According to .config of my u-boot it builds a SPL/MLO that expects the u-boot.img to be stored at raw sector 0x300 (384k).


Seems that the ROM code is capable of reading the MLO from the SD card in either raw sector more or in FAT file mode. Can you perhaps point me where in .config file I can remove second option?

i default to a 4MB hole…

sudo sfdisk ${DISK} <<-__EOF__

I don’t bother with that, it’s a ‘bootrom’ feature, here is our config: configs/am335x_evm_defconfig · · / u-boot · GitLab


Hi Robert,

Leaving 4MB hole and putting MLO and u-boot in raw sectors with count increased solved my issue.