0
Aoz

Cubox-i does not boot anymore after power shutdown

Recommended Posts

Hi,

 

After a power shutdown, my Cubox-i 4 Pro does not boot anymore.

I am running on it Debian Stretch since years. My system is on a hard drive (/dev/sda1).

 

It seems that the boot process is blocked in a loop, as each time, just after:

Starting kernel ...
 Uncompressing Linux... done, booting the kernel.

...U-boot is restarting as after a fresh reboot.

 

 

My boot.txt:

$ more armbianEnv.txt
verbosity=7
rootdev=/dev/sda1
console=serial
usbstoragequirks=0x2537:0x1066:u,0x2537:0x1068:u

 

Here is the bootlog:

U-Boot SPL 2013.10-rc4-ge4bc4c3 (Dec 18 2014 - 14:55:42)
Boot Device: SD1
spl: error reading image u-boot.img, err - -1
Load image from RAW...
 
 
U-Boot 2013.10-rc4-ge4bc4c3 (Dec 18 2014 - 14:55:42)
 
CPU:   Freescale i.MX6Q rev1.2 at 792 MHz
Reset cause: POR
Board: MX6-CuBox-i
DRAM:  2 GiB
MMC:   FSL_SDHC: 0
*** Warning - bad CRC, using default environment
 
In:    serial
Out:   vga
Err:   vga
Net:   FEC [PRIME]
(Re)start USB...
USB0:   USB EHCI 1.00
scanning bus 0 for devices... 2 USB Device(s) found
       scanning usb for storage devices... 1 Storage Device(s) found
       scanning usb for ethernet devices... 0 Ethernet Device(s) found
Hit any key to stop autoboot:  0
mmc0 is current device
** File not found /boot.scr **
** File not found /uEnv.txt **
** File not found /zImage **
** File not found /uImage **
1816 bytes read in 122 ms (13.7 KiB/s)
Running bootscript from mmc ...
## Executing script at 10800000
** File not found .next **
94 bytes read in 113 ms (0 Bytes/s)
37237 bytes read in 855 ms (42 KiB/s)
4820085 bytes read in 378 ms (12.2 MiB/s)
5961616 bytes read in 568 ms (10 MiB/s)
Kernel image @ 0x10800000 [ 0x000000 - 0x5af790 ]
## Loading init Ramdisk from Legacy Image at 14800000 ...
   Image Name:   uInitrd
   Image Type:   ARM Linux RAMDisk Image (gzip compressed)
   Data Size:    4820021 Bytes = 4.6 MiB
   Load Address: 00000000
   Entry Point:  00000000
   Verifying Checksum ... OK
## Flattened Device Tree blob at 18000000
   Booting using the fdt blob at 0x18000000
   Using Device Tree in place at 18000000, end 1800c174
 
Starting kernel ...
 
Uncompressing Linux... done, booting the kernel.
 
U-Boot SPL 2013.10-rc4-ge4bc4c3 (Dec 18 2014 - 14:55:42)
Boot Device: SD1
spl: error reading image u-boot.img, err - -1
Load image from RAW...
 
 
U-Boot 2013.10-rc4-ge4bc4c3 (Dec 18 2014 - 14:55:42)
 
CPU:   Freescale i.MX6Q rev1.2 at 792 MHz
Reset cause: POR
Board: MX6-CuBox-i
DRAM:  2 GiB
MMC:   FSL_SDHC: 0
*** Warning - bad CRC, using default environment
 
In:    serial
Out:   vga
Err:   vga
Net:   FEC [PRIME]
(Re)start USB...
USB0:   USB EHCI 1.00
scanning bus 0 for devices... 2 USB Device(s) found
       scanning usb for storage devices... 1 Storage Device(s) found
       scanning usb for ethernet devices... 0 Ethernet Device(s) found
Hit any key to stop autoboot:  0
mmc0 is current device
** File not found /boot.scr **
** File not found /uEnv.txt **
** File not found /zImage **
** File not found /uImage **
1816 bytes read in 122 ms (13.7 KiB/s)
Running bootscript from mmc ...
## Executing script at 10800000
** File not found .next **
94 bytes read in 113 ms (0 Bytes/s)
37237 bytes read in 855 ms (42 KiB/s)
4820085 bytes read in 378 ms (12.2 MiB/s)
5961616 bytes read in 568 ms (10 MiB/s)
Kernel image @ 0x10800000 [ 0x000000 - 0x5af790 ]
## Loading init Ramdisk from Legacy Image at 14800000 ...
   Image Name:   uInitrd
   Image Type:   ARM Linux RAMDisk Image (gzip compressed)
   Data Size:    4820021 Bytes = 4.6 MiB
   Load Address: 00000000
   Entry Point:  00000000
   Verifying Checksum ... OK
## Flattened Device Tree blob at 18000000
   Booting using the fdt blob at 0x18000000
   Using Device Tree in place at 18000000, end 1800c174
 
Starting kernel ...
 
Uncompressing Linux... done, booting the kernel.
 
U-Boot SPL 2013.10-rc4-ge4bc4c3 (Dec 18 2014 - 14:55:42)
Boot Device: SD1
spl: error reading image u-boot.img, err - -1
Load image from RAW...
 
 
U-Boot 2013.10-rc4-ge4bc4c3 (Dec 18 2014 - 14:55:42)
 
CPU:   Freescale i.MX6Q rev1.2 at 792 MHz
Reset cause: POR
Board: MX6-CuBox-i
DRAM:  2 GiB
MMC:   FSL_SDHC: 0
*** Warning - bad CRC, using default environment
 
In:    serial
Out:   vga
Err:   vga
Net:   FEC [PRIME]
(Re)start USB...
USB0:   USB EHCI 1.00
scanning bus 0 for devices... 2 USB Device(s) found
       scanning usb for storage devices... 1 Storage Device(s) found
       scanning usb for ethernet devices... 0 Ethernet Device(s) found
Hit any key to stop autoboot:  0
mmc0 is current device
** File not found /boot.scr **
** File not found /uEnv.txt **
** File not found /zImage **
** File not found /uImage **
1816 bytes read in 122 ms (13.7 KiB/s)
Running bootscript from mmc ...
## Executing script at 10800000
** File not found .next **
94 bytes read in 113 ms (0 Bytes/s)
37237 bytes read in 855 ms (42 KiB/s)
4820085 bytes read in 378 ms (12.2 MiB/s)
5961616 bytes read in 568 ms (10 MiB/s)
Kernel image @ 0x10800000 [ 0x000000 - 0x5af790 ]
## Loading init Ramdisk from Legacy Image at 14800000 ...
   Image Name:   uInitrd
   Image Type:   ARM Linux RAMDisk Image (gzip compressed)
   Data Size:    4820021 Bytes = 4.6 MiB
   Load Address: 00000000
   Entry Point:  00000000
   Verifying Checksum ... OK
## Flattened Device Tree blob at 18000000
   Booting using the fdt blob at 0x18000000
   Using Device Tree in place at 18000000, end 1800c174
 
Starting kernel ...
 
Uncompressing Linux... done, booting the kernel.
 
U-Boot SPL 2013.10-rc4-ge4bc4c3 (Dec 18 2014 - 14:55:42)
Boot Device: SD1
spl: error reading image u-boot.img, err - -1
Load image from RAW...
 
 
U-Boot 2013.10-rc4-ge4bc4c3 (Dec 18 2014 - 14:55:42)
 
CPU:   Freescale i.MX6Q rev1.2 at 792 MHz
Reset cause: POR
Board: MX6-CuBox-i
DRAM:  2 GiB
MMC:   FSL_SDHC: 0
*** Warning - bad CRC, using default environment

etc, etc...

 

I suspect a hard drive power issue, as I already had few weeks ago (see the thread below). On the current setup, the hard drive is powered directly thanks to a usb hub, not from the cubox.

 

Please note that the hard drive, plugged on my desktop, is running fine.

 

What could I investigate?

Thank you a lot for any support.

Share this post


Link to post
Share on other sites

https://github.com/armbian/build/commits/master/config/sources/cubox.conf

There were some major changes during this summer ... and we are very limited with testings changes on hardware. I am the only one dealing with this. 
Boot loader and kernel was updated which both represent major change. If your kernel was upgreaded and your u-boot not, this could explain the problem you are facing. Possible solutions:
- updating u-boot manually https://github.com/armbian/build/blob/master/config/sources/cubox.conf#L51

- change kernel from next to default or vice versa

 

This could be helpful:
https://docs.armbian.com/User-Guide_Advanced-Features/#how-to-unbrick-the-system

 

55 minutes ago, Aoz said:

My boot.txt:

 

It could only be the problem of changing rootdev=UUID=xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx

Share this post


Link to post
Share on other sites

I am able to boot on the following kernels4.14.132 or 5.1.16 (both on the /boot of the SDCard)
Currently, the system is set up to boot on 5.1.16.

Should I try to switch to 4.14?

 

I can also read the hard drive UUID on my desktop and edit the boot.txt to replace /dev/sda1 with UUID

 

I will also give a look to https://docs.armbian.com/User-Guide_Advanced-Features/#how-to-unbrick-the-system

Share this post


Link to post
Share on other sites

I switched from kernel 5.1.16 to kernel 4.14.132: it does not fix the issue

 

 

I replaced /dev/sda1 by UUID=XXXXXXXXXXXXX in /boot/armbianEnv.txt  and in /boot/boot.txt

 

armbianEnv.txt:

verbosity=7
rootdev=UUID=4a9f4e28-6a2f-4a58-b21a-8b0582b90cd5
console=serial
usbstoragequirks=

boot.txt:

setenv bootargs root=UUID=4a9f4e28-6a2f-4a58-b21a-8b0582b90cd5 rootfstype=ext4 rootwait console=tty1 video=mxcfb0:dev=hdmi,1920x1080M@60,if=RGB24,bpp=32 rd.dm=0 rd.luks=0 rd.lvm=0 raid=noautodetect pci=nomsi ahci_imx.hotplug=1 consolebl
ank=0 vt.global_cursor_default=0 quiet
ext2load mmc 0 0x18000000 /boot/dtb/${fdt_file}
ext2load mmc 0 0x12000000 /boot/zImage
bootz 0x12000000 - 0x18000000

 

All this does not fix the issue: it is still looping and rebooting each time just after "Starting the kernel".

 

Starting kernel ...
 
Uncompressing Linux... done, booting the kernel.
 
U-Boot SPL 2013.10-rc4-ge4bc4c3 (Dec 18 2014 - 14:55:42)
Boot Device: SD1

 

The strange thing is that even if I set up "verbosity" to 7, no kernel message is displayed...

 

Share this post


Link to post
Share on other sites

Thank you!

 

I compiled the boot.src from the boot.cmd

 

I took the v5.90 deb file, extracted it and got three files: control.tar.xz  data.tar.xz  debian-binary

 

I am sorry but I do not understand how to dd to the SDcard as described:

dd if=$1/u-boot.img.sdhc of=$2 bs=1K seek=69 status=noxfer > /dev/null 2>&1

What are $1 and $2?

 

Couldn't I just copy the content of data.tar.xz to the "/usr/lib/" folder of my SDCard?

 

 

 

Share this post


Link to post
Share on other sites
50 minutes ago, Aoz said:

extracted it

 

Type "how to extract a deb file" into the google then look for u-boot.img.sdhc

 

$1/ = path of u-boot.img.sdhc file

$2 = /dev/yourSDcard device ... usually /dev/sda (be sure that this is not your Linux system drive)

Share this post


Link to post
Share on other sites

You mean I need to replace the content of the SDCard by the content of u-boot.img.sdhc?

 

Doing so, the boot.src I have just compiled in the SDCard/boot/ folder and the kernels will be overwritten, no? 

Share this post


Link to post
Share on other sites
9 hours ago, Aoz said:

You mean I need to replace the content of the SDCard by the content of u-boot.img.sdhc

 

No. This is the way you flash boot loader to the SD card. For doing this you need some Linux computer where you will be attaching SD card for repair/boot loader flash.
 

9 hours ago, Aoz said:

Doing so, the boot.src I have just compiled in the SDCard/boot/ folder and the kernels will be overwritten, no? 


No. Especially if your boot script is identical to the one from Github.

You probably don't need to touch boot scripts. You need to alter /boot/armbianEnv.txt and change /dev/sda1 for its UUID version.

Share this post


Link to post
Share on other sites

Thank you a lot for the explanations.

 

I have got a linux computer with a card reader. When inserted, the SDCard is at  /dev/sde

 

I have got a final question about the command line: what about its end: "2>&1"?

Should I also replace here "&1" by "u-boot.img.sdhc"?

What about the "2", should I replace it by "/dev/sde"?

 

That is to say, should I run:

dd if=u-boot.img.sdhc of=/dev/sde bs=1K seek=69 status=noxfer > /dev/null 2>u-boot.img.sdhc

Or:

dd if=u-boot.img.sdhc of=/dev/sde bs=1K seek=69 status=noxfer > /dev/null /dev/sde>boot.img.sdhc

 

Share this post


Link to post
Share on other sites

Ok, did it.

 

Now, on the console (via USB-TTL serial console) I have only:

U-Boot SPL 2013.10-rc4-ge4bc4c3 (Dec 18 2014 - 14:55:42)
Boot Device: SD1
spl: error reading image u-boot.img, err - -1
Load image from RAW...

U-Boot SPL 2013.10-rc4-ge4bc4c3 (Dec 18 2014 - 14:55:42)
Boot Device: SD1
spl: error reading image u-boot.img, err - -1
Load image from RAW...

U-Boot SPL 2013.10-rc4-ge4bc4c3 (Dec 18 2014 - 14:55:42)
Boot Device: SD1
spl: error reading image u-boot.img, err - -1
Load image from RAW...

:unsure:

 

Should I try updating also the "SPL.sdhc" using:

sudo dd if=SPL.sdhc of=/dev/sde bs=1K seek=1 status=noxfer

 

Share this post


Link to post
Share on other sites

After running:

$ sudo dd if=SPL.sdhc of=/dev/sde bs=1K seek=1 status=noxfer
$ sudo dd if=u-boot.img.sdhc of=/dev/sde bs=1K seek=69 status=noxfer

 

U-boot seems having well been updated!

 

But it does not boot, it is looping like this:

U-Boot 2018.01-armbian (Jul 07 2019 - 11:26:59 +0200)

CPU:   Freescale i.MX6Q rev1.2 1200 MHz (running at 792 MHz)
CPU:   Extended Commercial temperature grade (-20C to 105C) at 33C
Reset cause: POR
Board: MX6 Cubox-i
       Watchdog enabled
DRAM:  2 GiB

U-Boot SPL 2018.01-armbian (Jul 07 2019 - 11:26:59)
Trying to boot from MMC1

 

Why MMC1?? :huh:

 

armbianEnv.txt:

verbosity=7
rootdev=UUID=4a9f4e28-6a2f-4a58-b21a-8b0582b90cd5
console=serial
usbstoragequirks=

boot.txt:

setenv bootargs root=UUID=4a9f4e28-6a2f-4a58-b21a-8b0582b90cd5 rootfstype=ext4 rootwait console=tty1 video=mxcfb0:dev=hdmi,1920x1080M@60,if=RGB24,bpp=32 rd.dm=0 rd.luks=0 rd.lvm=0 raid=noautodetect pci=nomsi ahci_imx.hotplug=1 consoleblank=0 vt.global_cursor_default=0 quiet
ext2load mmc 0 0x18000000 /boot/dtb/${fdt_file}
ext2load mmc 0 0x12000000 /boot/zImage
bootz 0x12000000 - 0x18000000

boot.cmd is the default one.

 

Shouldn't I do something with the other files which are in the deb? SPL.emmc  SPL.sata  SPL.spi-flash  u-boot.img.emmc  u-boot.img.sata  u-boot.img.spi-flash

I wanna boot on /dev/sda...
 

Share this post


Link to post
Share on other sites
1 hour ago, Aoz said:

Shouldn't I do something with the other files which are in the deb? SPL.emmc  SPL.sata  SPL.spi-flash  u-boot.img.emmc  u-boot.img.sata  u-boot.img.spi-flash


Each of those SPL's is prepared for different targets. I didn't experiment much with those. Apparently its possible to boot directly from SATA drive, but I never tried and I am not sure if boot scripts are capable to handle this without adjustements.

 

BTW. Can you boot fresh image from the download section?

Share this post


Link to post
Share on other sites

Actually, there are several kernels on my SDCard, in the /boot folder. But none is booting. Juste after "Trying to boot from MMC1", it loops back to "U-Boot 2018.01-armbian (Jul 07 2019 - 11:26:59 +0200)"  etc....

 

I don't even understand why it is trying to boot from MMC1, given my armbianEnv.txt & boot.txt

 

What else could I test?

Share this post


Link to post
Share on other sites
8 hours ago, Aoz said:

I don't even understand why it is trying to boot from MMC1, given my armbianEnv.txt & boot.txt


This looks like you have boot loader compiled for eMMC ... or your hardware has eMMC and SD card wired the other way around (have seen that before). Try booting this image on a clean SD card:
https://dl.armbian.com/cubox-i/archive/Armbian_5.94_Cubox-i_Ubuntu_bionic_default_4.9.179.7z

Share this post


Link to post
Share on other sites

I will try those images on a clean SD.

But, previously, I will try to boot on sata thanks to u-boot.img.sata + SPL.sata...

 

Anyhow, don't you have old images with Debian Stretch instead of Buster? (as I am running Yunohost.org which is not yet compatible with Buster)

Share this post


Link to post
Share on other sites
3 hours ago, Aoz said:

Anyhow, don't you have old images with Debian Stretch instead of Buster? (as I am running Yunohost.org which is not yet compatible with Buster)


If they are not in archive, you have to build them.

Share this post


Link to post
Share on other sites

I made several tests:

1. burn all the possible pairs of SPL / u-boot.img on the existing SDCard --> each time the same story:

U-Boot 2018.01-armbian (Jul 07 2019 - 11:26:59 +0200)

CPU:   Freescale i.MX6Q rev1.2 1200 MHz (running at 792 MHz)
CPU:   Extended Commercial temperature grade (-20C to 105C) at 33C
Reset cause: POR
Board: MX6 Cubox-i
       Watchdog enabled
DRAM:  2 GiB

U-Boot SPL 2018.01-armbian (Jul 07 2019 - 11:26:59)
Trying to boot from MMC1

2. take a new SDCard, dd the SPL.sdhc and u-boot.img.sdhc then use Etcher to burn "Armbian_5.91_Cubox-i_Debian_buster_default_4.14.133" on it, boot with no hard drive connected to the cubox-i:

U-Boot 2018.01-armbian (Jul 15 2019 - 21:19:21 +0200)

CPU:   Freescale i.MX6Q rev1.2 1200 MHz (running at 792 MHz)
CPU:   Extended Commercial temperature grade (-20C to 105C) at 35C
Reset cause: POR
Board: MX6 Cubox-i
       Watchdog enabled
DRAM:  2 GiB

U-Boot SPL 2018.01-armbian (Jul 15 2019 - 21:19:21)

U-Boot SPL 2018.01-armbian (Jul 15 2019 - 21:19:21)

U-Boot SPL 2018.01-armbian (Jul 15 2019 - 21:19:21)

U-Boot SPL 2018.01-armbian (Jul 15 2019 - 21:19:21)

U-Boot SPL 2018.01-armbian (Jul 15 2019 - 21:19:21)

U-Boot SPL 2018.01-armbian (Jul 15 2019 - 21:19:21)

 

 

That is crazy! It seems no more possible to boot that cubox!??!

Share this post


Link to post
Share on other sites
2 hours ago, Aoz said:

That is crazy! It seems no more possible to boot that cubox!??!


Indeed :(


Try stock Solidrun builds?

While Armbian_5.91_Cubox-i_Debian_buster_default_4.14.133 is more or less stock u-boot, stock kernel + few improvements.

 

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
0