Jump to content
  • 0

Cubox-i does not boot anymore after power shutdown


Aoz

Question

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.

Link to comment
Share on other sites

Recommended Posts

  • 0
7 hours ago, usual user said:

What I have done with my exercise is to approve that the 5.3.1 kernel is really broken and missing some proper build config.


Check images from download section. They are working fine for me, for example: https://dl.armbian.com/cubox-i/archive/Armbian_5.98_Cubox-i_Ubuntu_bionic_next_5.3.1_desktop.7z

Relevant commit:
https://github.com/armbian/build/commit/70e1e5882d7ea8ad7a61543070e6e00169401028

 

Edit: armbianmonitor logs http://ix.io/1XA7

Edited by Igor
Add boot logs
Link to comment
Share on other sites

  • 0

OK, figured what was going on.
First step was to reinstall the armbian uboot from /usr/lib/linux-u-boot-next-cubox-i_5.98_armhf again. It has full distro boot feature available. I was mislead by a comment (# next kernels have different u-boot without autodetection) in /boot/boot.cmd.
In the end uboot is setting up the boot parameters in a not suitable manner for my environment. And "Starting kernel ..." as the only feedback is not of much help to analyse the problem. I came up with the append line setup of the first boot stanza in /boot/extlinux/extlinux.conf to boot successful in my environment.
In serial.log you see an automatic recover from a failing boot.
Initially the fourth boot stanza is selected with boot parameters derived from /boot/boot.cmd. This is failing with "Starting kernel ...". After a while the watchdog kicks in and triggers a reset. Uboot restarts and autoboots the first boot stanza.
The attached extlinux.conf can be used for the Armbian_5.98_Cubox-i_Debian_buster_next_5.3.1_minimal.7z as is. For other images the PARTUUID has to be adopted. "blkid" will tell you the proper value of your rootfs partition.

serial.log extlinux.conf

Link to comment
Share on other sites

  • 0
On 10/4/2019 at 8:16 AM, Igor said:

Check images from download section. They are working fine for me, for example: https://dl.armbian.com/cubox-i/archive/Armbian_5.98_Cubox-i_Ubuntu_bionic_next_5.3.1_desktop.7z

Dropping the bare image on the micro SD starts with working HDMI support. Maybe it is the different content of the initrd as that is the only difference to the previous used image kernel wise. But it is loading the wrong DTB (for cubox-i, not for hummingboard) and there is no visible cursor in the VT. Dropping in the attached /boot/extlinux/extlinux.conf fixes this. The first boot stanza doesn't even matter as uboot recognizes the missing files and gracefully skips to the second stanza. This gives a nice snappy desktop.

extlinux.conf

Link to comment
Share on other sites

  • 0

I was able to get uboot updated. I copied the files from here https://apt.armbian.com/pool/main/l/linux-5.3.1-cubox/  to my SD card.

I am getting closer. Oh, this is a buster server deployment if that matters.

This is what I get now...

I have armbianEnv.txt with

```

verbosity=1

rootdev=/dev/mmcblk0p1

rootfstype=ext4

```

 

 

```

U-Boot SPL 2018.01-armbian (Sep 27 2019 - 23:10:03)
Trying to boot from MMC1


U-Boot 2018.01-armbian (Sep 27 2019 - 23:10:03 +0200)

CPU:   Freescale i.MX6Q rev1.5 996 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
MMC:   FSL_SDHC: 0, FSL_SDHC: 1
auto-detected panel HDMI
Display: HDMI (1024x768)
In:    serial
Out:   serial
Err:   serial
Net:   FEC
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
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
1845 bytes read in 132 ms (12.7 KiB/s)
## Executing script at 12000000
0 bytes read in 101 ms (0 Bytes/s)
51 bytes read in 120 ms (0 Bytes/s)
37518 bytes read in 5767 ms (5.9 KiB/s)
** File not found /boot/uInitrd **
** Unrecognized filesystem type **
** File not found uInitrd **
5263872 bytes read in 408 ms (12.3 MiB/s)
Wrong Ramdisk Image Format
Ramdisk image is corrupt or invalid
SCRIPT FAILED: continuing...
MMC: no card present
mmc_init: -123, time 48

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 **
FEC Waiting for PHY auto negotiation to complete........

```

Link to comment
Share on other sites

  • 0
On 10/2/2019 at 4:28 PM, dudepron said:

I tired to copy the files from a new SD install of 5.3.1

If you have copied in /boot/vmlinuz-5.3.1-cubox, /boot/initrd.img-5.3.1-cubox, /boot/dtb-5.3.1-cubox/ and /lib/modules/5.3.1-cubox/ from your new SD install of 5.3.1 your only missing part should be to copy in the attached /boot/extlinux/extlinux.conf.

extlinux.conf

Link to comment
Share on other sites

  • 0
On 10/1/2019 at 7:21 AM, Igor said:

As the error tells. You need to recreate it. Boot without is possible if you set root device to /dev/mmcblk01 and not UUID

Boot without initrd with the current config-5.3.1-cubox is not possible. In fedora config I need at least to flip CONFIG_MMC_BLOCK, CONFIG_MMC_SDHCI, CONFIG_MMC_SDHCI_PLTFM and CONFIG_MMC_SDHCI_ESDHC_IMX from module to buildin to be able to boot without initramfs from mmc.

Link to comment
Share on other sites

  • 0
23 minutes ago, usual user said:

Boot without initrd with the current config-5.3.1-cubox is not possible. In fedora config


Oh, yes, few things has to be build into the kernel to be able to boot that way. But I didn't pay attention to that since Armbian always boots with initrd. If you care, send a PR with changes to our config.

Link to comment
Share on other sites

  • 0

In fedora these changes can`t land since the kernel is universal and device specific buildins are not allowed to prevent vmlinuz bloat. An initramfs is only required if you have an encrypted rootfs or want to use UUID or LABEL for rootfs identification. For this to work you need user space tools. The initramfs is highly rootfs dependent hence it is almost ever created on the fly while kernel package installation in the running system. Doing it in an offline manner is quite difficult if not impossible. For a not encrypted rootfs with PARTUUID the kernel can always find the rootfs as long as it has buildin support to access the rootfs. No matter at what block device the rootfs resides the kernel will find it. IMHO a distribution building device dedicated kernels should try to avoid using an initramfs. Without an initramfs installing a kernel boils down to copy preassembled files in place and point the boot loader at them. It can be done easily in an offline manner to recover a system and is rootfs independent as long as the files are copied in the correct location. I have done it with the fedora kernel to bootstrap the minimal armbian image.

On 9/13/2019 at 9:50 PM, Igor said:

... and we are very limited with testings changes on hardware. I am the only one dealing with this. 

As a fly by, I thought I should report some observations. I don't care enough for armbian to get this included.
An armbian supporter has to take over here.

Link to comment
Share on other sites

  • 0

Does the image provided ---there---, put on a separate microSD with "xz -dcv Fedora-Minimal-armhfp-31-1.9-trial.raw.xz > /dev/sdX", boot for you properly?
"/dev/sdX" has to be replaced by the device where the separate microSD resides while the transfer.

Edited by usual user
Image no longer provided
Link to comment
Share on other sites

Guest
This topic is now closed to further replies.
×
×
  • Create New...

Important Information

Terms of Use - Privacy Policy - Guidelines