No more powering up

Hi,

I am using the cubox-M since one month.
Today I tried to flash the emmc and when I powered on again, it was no more working.
I have nothing on the terminal when I power on my Cubox-M although I correctly have the red light on the front.
I tried to boot again with an image on an sd card with the same result.
I tried on another Cubox-M.

It was working perfectly until I flashed the emmc, since that moment, nothing is showing on the terminal nor the screen.

Is there a way to unlock this situation?

Thank you in advance

Tom

The CuBox-M by default is booting from the sd-card as the “fallback” mmc boot with NXP’s unfused default configuration. The moment that it finds a bootloader on the internal MMC it will attempt to use that instead, and only that. If that is not booting then it is possible it is falling back to SDP recovery mode on the USB port. In order to see if this is the case you need a USB-A to USB-A cable with a protective resistor on the VCC line. You can see our developer docs on how to make this. The alternative is to use a USB-A to USB-C cable and then a USB-C female to USB-A Male adapter with a VCC protective resistor. The VCC protective resistor is part of the spec for USB-C since it can handle power delivery, so any good quality adapter should have this built in. I use Syntech branded adapters.

If you then plug this into a computer you should see the NXP recovery usb device present, and you can use NXP’s uuu utility to load a recovery boot-loader and recovery your device.

Thank you for your great answer!

The only problem:
When I connect my USB cable to the upper USB-A port, I do not have the usb nxp detect as I should:

$ lsusb 
Bus 006 Device 002: ID 05e3:0620 Genesys Logic, Inc. USB3.0 Hub
Bus 001 Device 048: ID 0403:6015 Future Technology Devices International, Ltd Bridge(I2C/SPI/UART/FIFO)
Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 001 Device 002: ID 04f2:b67c Chicony Electronics Co., Ltd Integrated Camera
Bus 006 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 001 Device 050: ID 05e3:0610 Genesys Logic, Inc. 4-port hub
Bus 001 Device 003: ID 06cb:00bd Synaptics, Inc. 
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 005 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub

Can you try flipping the USB-C port in the adapter? I have found that sometimes this makes a difference. Otherwise something is crashing early in SPL and not falling back to recovery mode.

If this doesn’t work can you provide the method you used for flashing u-boot to the eMMC?

Sadly it does not change anything.

I used this script:

#!/bin/sh

SD_DEV=/dev/mmcblk1
EMMC_DEV=/dev/mmcblk2

# ${EMMC_DEV}p4 might be mounted on /data
mountpoint /data
RETVAL=$?
if [ $RETVAL -eq 0 ]
then
    echo "/data is mounted, meaning that you are probably trying to flash an already programmed system."
    while true; do
        read -p "Are you sure you want to continue [y/n]? " yn
        case $yn in
            [Yy]* ) break;;
            [Nn]* ) exit;;
            * ) echo "Please answer yes or no.";;
        esac
    done

    echo "Erasing ${EMMC_DEV}'s partition table..."
    dd if=/dev/zero of=${EMMC_DEV} bs=512 count=1 conv=notrunc
    sync
    echo "Done !"
    echo "Please retry after reboot"
    sleep 5
    reboot
fi

# clean EMMC_DEV until first partition; the rest will be overwritten by the next commands
dd if=/dev/zero of=${EMMC_DEV} bs=1M count=4 conv=fsync

# create the following partition table:
#  /boot: 50MB, from offset 32K, FAT
#  /rootfs1: 1GB, from end of /boot, Linux
#  /rootfs2: 1GB, from end of /rootfs1, Linux
#  /data: from end of /rootfs2, Linux

echo "label: dos
label-id: 0x00000000
device: ${EMMC_DEV}
unit: sectors

${EMMC_DEV}p1 : start=        2515, size=      102400, type=c, bootable
${EMMC_DEV}p2 : start=      104915, size=     2202066, type=83
${EMMC_DEV}p3 : start=     2306981, size=     2202066, type=83
${EMMC_DEV}p4 : start=     4509047, type=83" | sfdisk --force ${EMMC_DEV}

# ${EMMC_DEV}p4 might be automatically re-mounted
umount -f /data

# refresh the partition table; this ensure the kernel considers the new partition table
partprobe ${EMMC_DEV}

while ! [ -e /dev/mmcblk2p1 ] || ! [ -e /dev/mmcblk2p2 ] || ! [ -e /dev/mmcblk2p3 ] || ! [ -e /dev/mmcblk2p4  ]
do
  echo "waiting for /dev/mmcblk2 partition to refresh"
  sleep 2
  partprobe ${EMMC_DEV}
done


# copy U-Boot
dd if=${SD_DEV} of=${EMMC_DEV} bs=1k skip=32 seek=32 count=64 conv=fsync

# copy the boot and rootfs partitions
dd if=${SD_DEV}p1 of=${EMMC_DEV}p1 bs=1M conv=fsync
dd if=${SD_DEV}p2 of=${EMMC_DEV}p2 bs=1M conv=fsync

# ${EMMC_DEV}p4 might be automatically re-mounted
umount -f /data

# format data partition
mkfs.ext4 -F -L data ${EMMC_DEV}p4

# ${EMMC_DEV}p4 might be automatically re-mounted
umount -f /data

# set randomly generated systemd.machine_id as permanent via kernel bootarg in uboot's uEnv.txt
mount ${EMMC_DEV}p1 /mnt
sed -i -r "/extraargs=.*/s/$/ systemd.machine_id=$(cat /etc/machine-id)/" /mnt/uEnv.txt
# change the rootfs partition to boot
sed -i "s/mmcblk1p2/mmcblk2p2/g" /mnt/extlinux/extlinux.conf
umount /mnt

# create rw-overlay structure in data partition
mount ${EMMC_DEV}p4 /mnt

for entry in 'etc' 'opt' 'usr'; do
    mkdir -p /mnt/rw-overlay/"$entry"
    mkdir -p /mnt/rw-overlay/work/"$entry"
done

# create persistent structure in data partition
mkdir -p /mnt/var
mkdir -p /mnt/config
mkdir -p /mnt/root
mkdir -p /mnt/home

umount /mnt

exit 0

I have the feeling that it failed due to this specific line:

dd if=${SD_DEV} of=${EMMC_DEV} bs=1k skip=32 seek=32 count=64 conv=fsync

because previously it was at:

dd if=${SD_DEV} of=${EMMC_DEV} bs=1k skip=32 seek=32 count=10k conv=fsync

and it was still booting

yep, that would do it. You have flashed just enough SPL for it to boot, but not enough for it to get into recovery mode.

Ok it was indeed a bad move…
Is there so any way to recover it?

With only a CuBox-M the only way to recover is by opening it up and soldering to the board to change the boot mode to force sdhc rather than eMMC. With our development board the HummingBoard Pulse we have dip-switches on board that would allow manually switching the boot method.

Ok fine, could you advice what I have to sold to be able to boot on the sd?

Thank you very much!

You will need to full disassemble your CuBox-M and remove the top board from the bottom. As per the schematic you need to connect Boot_Mode0 and Boot_Mode1 to V_3V3 with 10k resistors.
image This will set BOOT_MODE from internal fuses to SDCARD. Hopefully your SOM is not fused to eMMC with SDCARD fall back. The 2 connections to 3.3V are marked in red and the BOOT_MODE1 is highlighted green.

The boot modes can be referenced here,

Follow up here if you have any more questions.

1 Like

I solved it thanks to you!
Thank you very much!

Glad you were able to get your hardware working again!