# No more powering up

**URL:** <https://community.solid-run.com/t/no-more-powering-up/512>\
**Category:** NXP i.MX8M Plus\
**Created:** [October 31, 2022, 4:22pm UTC](https://community.solid-run.com/t/no-more-powering-up/512 "2022-10-31T16:22:38Z")\
**Posts on this page:** 13\
**Page:** 1

<div class="post-metadata">

**Author:** ![Tom](https://avatars.discourse-cdn.com/v4/letter/t/3d9bf3/32.png) [@Tom](https://community.solid-run.com/u/Tom)\
**Post date:** [October 31, 2022, 4:22pm UTC](https://community.solid-run.com/t/no-more-powering-up/512/1 "2022-10-31T16:22:38Z")

</div>

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

---

<div class="post-metadata">

**Author:** ![jnettlet](https://dub1.discourse-cdn.com/flex005/user_avatar/community.solid-run.com/jnettlet/32/62_2.png) [@jnettlet](https://community.solid-run.com/u/jnettlet)\
**Post date:** [November 1, 2022, 5:09am UTC](https://community.solid-run.com/t/no-more-powering-up/512/2 "2022-11-01T05:09:12Z")

</div>

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.

---

<div class="post-metadata">

**Author:** ![Tom](https://avatars.discourse-cdn.com/v4/letter/t/3d9bf3/32.png) [@Tom](https://community.solid-run.com/u/Tom)\
**Post date:** [November 2, 2022, 8:06am UTC](https://community.solid-run.com/t/no-more-powering-up/512/3 "2022-11-02T08:06:31Z")

</div>

Thank you for your great answer!

---

<div class="post-metadata">

**Author:** ![Tom](https://avatars.discourse-cdn.com/v4/letter/t/3d9bf3/32.png) [@Tom](https://community.solid-run.com/u/Tom)\
**Post date:** [November 2, 2022, 8:50am UTC](https://community.solid-run.com/t/no-more-powering-up/512/4 "2022-11-02T08:50:37Z")

</div>

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:

 ![image](https://europe1.discourse-cdn.com/flex005/uploads/solid_run/original/1X/94b156e168da360c5d21398db1d953c3f4c31d2f.png)

```auto
$ 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

```

---

<div class="post-metadata">

**Author:** ![jnettlet](https://dub1.discourse-cdn.com/flex005/user_avatar/community.solid-run.com/jnettlet/32/62_2.png) [@jnettlet](https://community.solid-run.com/u/jnettlet)\
**Post date:** [November 2, 2022, 9:37am UTC](https://community.solid-run.com/t/no-more-powering-up/512/5 "2022-11-02T09:37:53Z")

</div>

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?

---

<div class="post-metadata">

**Author:** ![Tom](https://avatars.discourse-cdn.com/v4/letter/t/3d9bf3/32.png) [@Tom](https://community.solid-run.com/u/Tom)\
**Post date:** [November 2, 2022, 9:58am UTC](https://community.solid-run.com/t/no-more-powering-up/512/6 "2022-11-02T09:58:37Z")

</div>

Sadly it does not change anything.

I used this script:

```auto
#!/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:

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

```

because previously it was at:

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

```

and it was still booting

---

<div class="post-metadata">

**Author:** ![jnettlet](https://dub1.discourse-cdn.com/flex005/user_avatar/community.solid-run.com/jnettlet/32/62_2.png) [@jnettlet](https://community.solid-run.com/u/jnettlet)\
**Post date:** [November 2, 2022, 10:36am UTC](https://community.solid-run.com/t/no-more-powering-up/512/7 "2022-11-02T10:36:28Z")

</div>

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.

---

<div class="post-metadata">

**Author:** ![Tom](https://avatars.discourse-cdn.com/v4/letter/t/3d9bf3/32.png) [@Tom](https://community.solid-run.com/u/Tom)\
**Post date:** [November 2, 2022, 10:54am UTC](https://community.solid-run.com/t/no-more-powering-up/512/8 "2022-11-02T10:54:20Z")

</div>

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

---

<div class="post-metadata">

**Author:** ![jnettlet](https://dub1.discourse-cdn.com/flex005/user_avatar/community.solid-run.com/jnettlet/32/62_2.png) [@jnettlet](https://community.solid-run.com/u/jnettlet)\
**Post date:** [November 2, 2022, 11:21am UTC](https://community.solid-run.com/t/no-more-powering-up/512/9 "2022-11-02T11:21:36Z")

</div>

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.

---

<div class="post-metadata">

**Author:** ![Tom](https://avatars.discourse-cdn.com/v4/letter/t/3d9bf3/32.png) [@Tom](https://community.solid-run.com/u/Tom)\
**Post date:** [November 2, 2022, 12:26pm UTC](https://community.solid-run.com/t/no-more-powering-up/512/10 "2022-11-02T12:26:26Z")

</div>

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

Thank you very much!

---

<div class="post-metadata">

**Author:** ![jnettlet](https://dub1.discourse-cdn.com/flex005/user_avatar/community.solid-run.com/jnettlet/32/62_2.png) [@jnettlet](https://community.solid-run.com/u/jnettlet)\
**Post date:** [November 2, 2022, 1:35pm UTC](https://community.solid-run.com/t/no-more-powering-up/512/11 "2022-11-02T13:35:03Z")

</div>

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](https://europe1.discourse-cdn.com/flex005/uploads/solid_run/original/1X/69f95da8b4990632e9018ec1677cb40bce2d86a1.png) 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.

 ![image](https://europe1.discourse-cdn.com/flex005/uploads/solid_run/original/1X/e2cd516445e06ffba935ae57801fb71e32abb2e9.jpeg)

The boot modes can be referenced here,

 ![image](https://europe1.discourse-cdn.com/flex005/uploads/solid_run/original/1X/8b4ecb1d33d0a6087ca8e37e7409155da1a31f44.png)

Follow up here if you have any more questions.

---

<div class="post-metadata">

**Author:** ![Tom](https://avatars.discourse-cdn.com/v4/letter/t/3d9bf3/32.png) [@Tom](https://community.solid-run.com/u/Tom)\
**Post date:** [November 7, 2022, 8:16am UTC](https://community.solid-run.com/t/no-more-powering-up/512/12 "2022-11-07T08:16:44Z")

</div>

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

---

<div class="post-metadata">

**Author:** ![jnettlet](https://dub1.discourse-cdn.com/flex005/user_avatar/community.solid-run.com/jnettlet/32/62_2.png) [@jnettlet](https://community.solid-run.com/u/jnettlet)\
**Post date:** [November 7, 2022, 8:22am UTC](https://community.solid-run.com/t/no-more-powering-up/512/13 "2022-11-07T08:22:55Z")

</div>

Glad you were able to get your hardware working again!