Cubox-i does not boot anymore after power shutdown

[Aoz]

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.

[Igor]

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

[Aoz]

I am able to boot on the following kernels: 4.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

[Aoz]

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...

 

[Aoz]

If I want to update the u-boot manually (as described in https://docs.armbian.com/User-Guide_Advanced-Features/#how-to-unbrick-the-system) , from where should I download the "boot.cmd" dedicated to cubox-i?

[Igor]

boot binary are packed into deb files - extract them and DD to sdcard as noted previously.
https://apt.armbian.com/pool/main/l/linux-u-boot-cubox-i-default/

 

boot.cmd and boot.scr (compiled version - how to is written in the end of the boot.cmd file). You need both. 
https://github.com/armbian/build/blob/master/config/bootscripts/boot-cubox.cmd

[Aoz]

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?

 

 

 

[Igor]

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)

[Aoz]

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? 

[Igor]

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.

[Aoz]

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

 

[Igor]

4 hours ago, Aoz said:

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

 

That's all. You need a superuser rights ofc.

[Aoz]

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...

 

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

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

 

[Igor]

2 hours ago, Aoz said:

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

Yes of course. I completely forgot about  

Here is the recipe:
https://github.com/armbian/build/blob/master/config/sources/cubox.conf#L48-L52

Sometimes order is also important ...

[Aoz]

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?? 

 

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...
 

[Igor]

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?

[Aoz]

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?

[Igor]

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

[Aoz]

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)

[Igor]

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.

[Aoz]

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!??!

[Igor]

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.

 

[WDaveO]

I also have a cubox-i and haven't been able to get the newest .next kernel to run. I actually have an ancient version of u-boot and a uEnv.txt file no armbianEnv.txt or boot.txt and no boot.cmd or boot.scr. I went through the steps outlined here and was able to install an updated version of u-boot and the various config files (I duplicated the examples given by Aoz but altered them as I boot from sdhc. I ran through a lot of permutations I'll try to come back sometime soon with more specific details but a few things I noticed: 

 

I didn't have a .next file so for the longest time things were failing because the appropriate dtb couldn't be found. I changed boot.cmd and eventually put an empty .next file in my boot folder and the dtb file would be found. 

 

I would always get mmc no card found but files were being read off of the sdhc's ext4 partition.

 

I would get to the part in boot.scr where the kernel should be loaded and end up with

 

5263872 bytes read in 376 ms (13.4 MiB/s)
Wrong Ramdisk Image Format
Ramdisk image is corrupt or invalid
SCRIPT FAILED: continuing...

I downloaded linux-image-next-cubox_5.98_armhf.deb and verified that vmlinuz-5.3.1-cubox from the deb matches what I have in /boot on the sdhc card I try to boot from.

 

I tried both the default and .next u-boot versions as well as my ancient one and none worked. Out of curiosity is there any difference between the .next and default ones?

 

Any ideas what's going on? 

 

More details from the boot attempt:

 

U-Boot SPL 2018.01-armbian (Sep 27 2019 - 22:43:42)
Trying to boot from MMC1
   
   
U-Boot 2018.01-armbian (Sep 27 2019 - 22:43:42 +0200)
   
CPU:   Freescale i.MX6Q rev1.5 996 MHz (running at 792 MHz)
CPU:   Extended Commercial temperature grade (-20C to 105C) at 30C
Reset cause: POR
Board: MX6 Cubox-i
       Watchdog enabled
DRAM:  2 GiB
MMC:   FSL_SDHC: 0, FSL_SDHC: 1
No panel detected: default to HDMI
Display: HDMI (1024x768)
In:    serial
Out:   serial
Err:   serial
Net:   FEC
Hit any key to stop autoboot:  0
switch to partitions #0, OK
mmc0 is current device
Scanning mmc 0:1...
Found U-Boot script /boot/boot.scr
1865 bytes read in 54 ms (33.2 KiB/s)
## Executing script at 12000000
0 bytes read in 105 ms (0 Bytes/s)
257 bytes read in 55 ms (3.9 KiB/s)
37518 bytes read in 3040 ms (11.7 KiB/s)
** File not found /boot/uInitrd **
** Unrecognized filesystem type **
** File not found uInitrd **
5263872 bytes read in 376 ms (13.4 MiB/s)
Wrong Ramdisk Image Format
Ramdisk image is corrupt or invalid
SCRIPT FAILED: continuing...
MMC: no card present
mmc_init: -123, time 44
starting USB...
USB0:   Port not available.
USB1:   USB EHCI 1.00
scanning bus 1 for devices... 1 USB Device(s) found
       scanning usb for storage devices... 0 Storage Device(s) found
   
Device 0: device type unknown
... is now current device
** Bad device usb 0 **
** Bad device usb 0 **
AHCI 0001.0300 32 slots 1 ports 3 Gbps 0x1 impl SATA mode
flags: ncq stag pm led clo only pmp pio slum part
No port device detected!
   
Device 0: Model:  Firm:  Ser#:
            Type: Hard Disk
            Capacity: not available
... is now current device
** Bad device size - sata 0 **
BOOTP broadcast 1
 

Edited October 1, 2019 by WDaveO
noticed I had some output from a recent failed attempt.

[Igor]

1 hour ago, WDaveO said:

Ramdisk image is corrupt or invalid

As the error tells. You need to recreate it. Boot without is possible if you set root device to /dev/mmcblk01 and not UUID in /boot/armbianEnv.txt and with changed https://github.com/armbian/build/blob/master/config/bootscripts/boot-cubox.cmd#L36 to 

bootz ${loadaddr} - ${fdt_addr}

Recompile boot.cmd - boot.scr, boot, then install kernel deb file again and it will recreate ramdisk .... reverse changes and it should boot normally with ramdisk.

[WDaveO]

Thanks so much Igor,

 

I was assuming it was an issue with u-boot as the ramdisk had come from the .deb (later I realized that the ramdisk form the .deb is fine it's just not in uInitrd format...)

 

I made the changes you suggested and I can get the kernel to try to boot but now it hangs on "waiting for root device /dev/mmcblk0p1" . If I change rootwait to rootdelay I get:

 

[    4.363678] VFS: Cannot open root device "mmcblk0p1" or unknown-block(0,0): error -6
[    4.371461] Please append a correct "root=" boot option; here are the available partitions:
[    4.379847] Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(0,0)

I tried adding break=mount to the bootargs but I wasn't able to get the kernel to drop to a shell to look at what devices exist. I've tried mmcblk0p1 ..1p1.. 0p2.. 1p2 and mmcblk01 none seem to work. The microsd card has one ext4 partition and used to mount as /dev/mmcblk0p1 

 

I then decided rather than to roll back completely I'd just move back to the 5.90 kernel and see if the current u-boot setup works for it. I was able to boot the older kernel with no issues using my armbianEnv.txt boot.txt and boot.cmd (compiled into a boot.scr). I also noticed that when I turned the ramdisk on the 5.90 kernel stopped working. I reinstalled the 5.90 kernel using apt (I'd previously just copied a known working boot folder into place and the boot.scr was replaced with one that used a ramdisk and the system wouldn't boot. I eventually realised that I had no uInitrd at all and used `mkimage -A arm -T ramdisk -C none -n uInitrd -d /path/to/initrd.img /path/to/uInitrd` to make one. I was then able to boot into 5.90. 

 

I still couldn't boot into 5.98 but decided to try again and make sure I controlled all the variables. When I made the uInitrd I was able to boot into the kernel but it still wasn't finding the root file system. With the ramdisk in place however I was able to get to a shell and note that the naming had changed and the device was now mmcblk1p1. With that setting in armbianEnv.txt and the correctly created ramdisk I was able to fully boot into the updated kernel and actually use the system. When I was logged in however my openvpn connection didn't work for some reason and every few minutes the system would suddenly reboot... The red light under the optical audio port also never went off even when I was in a working shell. I didn't dare trying to reinstall using apt while booted into 5.98 because the reboots were too frequent to not interrupt apt and they weren't linux reboots the terminal would just jump to the boot loader suddenly. 

 

So long story short I wonder if I'm missing packages that are needed to automatically update the system and generate the uInitrd file when a kernel is updated or if this just isn't automated? additionally it seems to me that there are bugs in the 5.98 kernel for the cubox-i though I'm not really comfortable enough with u-boot to say if some or all of these issues are my fault. For my purposes my plan is to hold the kernel packages at 5.90 and try the next kernel release. If you (or anyone else,) has any ideas to try in order to better understand if there is an issue with 5.98 kernel please let me know and I'll do some more experimenting. though I'm heading out of town soon so I likely won't be able to get to it for a few weeks unless it's something I can try really quick. 

 

[dudepron]

Recent upgrade to armbian (5.3.1) on my Cubox has left it unbootable. It appears that it is looking for the older version of the boot image (5.1.6 IIRC) and says that is unable to find a flattened device tree. I tired to copy the files from a new SD install of 5.3.1 to the /boot and that didn't seem to work either. I am not sure if this is an old Uboot (2013?) and a new image or what.  What is the best way to recover without losing my data on the SD?

[dudepron]

I can access the device via Uboot, but just cannot get the image to load.

[dudepron]

 I will try these steps.

[usual user]

Wondering what this is all about. Out of curiosity I downloaded Armbian_5.98_Cubox-i_Debian_buster_next_5.3.1_minimal.7z and took a look. The bare image does indeed not boot on my Hummingboard. Ok, lets copy over the fedora /usr/lib/modules/5.3.0-0.rc1.git0.1.fc30.armv7hl directory. As I have long time not tinkered with boot.cmd, boot.scr lets switch over to distro boot and drop in an /boot/extlinux/extlinux.conf.
Wow, the armbian uboot recognized it, but with missing DTB autoselect this is not of much use. Replace the uboot with a mainline one like used by fedora.
Now the image is properly starting up with HDMI support working. Dropping in a stanza for the image provided kernel confirms the 5.3.1 kernel gets stuck early while booting. A kernel from the Armbian_5.94_Cubox-i_Debian_buster_next_5.2.10_minimal.7z is properly booting, but only usable via serial console. The HDMI support seems to be missing. I ended up with the attached extlinux.conf. As I had to collect the armbian kernel command line parameters manually, there is a possibility I messed something up. But none of them should prevent booting up the kernel.

extlinux.conf

[WDaveO]

It's hard to say but I'm not coming from a new image, rather I have a cubox-i that I've been using as a headless server for years and I've been able to upgrade kernels until 5.98 came out which bricked my box. It used to brick a lot before I switched to armbian actually but this was my first armbian bricking. I had no idea that there were updates to u-boot before I found this thread and I'm really not sure what else might make my install different from a fresh image. I've done a lot of configuration on top of the OS so I'm going to hold off on the update and see if a future version repairs things, maybe just never upgrade my kernel again or possibly eventually break down and start with a fresh image.