i.MX ProcessorsのトピックRe: wrong boot device at kernel/ramdisk boot stage... where should I look in to solve this?

wrong boot device at kernel/ramdisk boot stage... where should I look in to solve this?

chadrickkwag — Fri, 01 Apr 2016 03:09:37 GMT

after uboot, I am having trouble booting kernel. comparing the logs with a properly booting sd card, I believe the problem is due to the fact that the kernel(or ramdisk) is configured to boot from the wrong device.

here is the problematic snippet of the log:

====

UTC (2)

ALSA device list:

#0: wm8962-audio

#1: imx-hdmi-soc

Freeing unused kernel memory: 432K (c0be3000 - c0c4f000)

audit: type=1403 audit(2.640:2): policy loaded auid=4294967295 ses=4294967295

audit: type=1404 audit(2.650:3): enforcing=1 old_enforcing=0 auid=4294967295 ses=4294967295

Console: switching to colour dummy device 80x30

fs_mgr: __mount(source=/dev/block/mmcblk3p5,target=/system,type=ext4)=-1

fs_mgr: Failed to mount an un-encryptable or wiped partition on/dev/block/mmcblk3p5 at /system options: barrier=1 error: No such file or directory

random: nonblocking pool is initialized

fs_mgr: __mount(source=/dev/block/mmcblk3p4,target=/data,type=ext4)=-1

fs_mgr: fs_mgr_mount_all(): possibly an encryptable blkdev /dev/block/mmcblk3p4 for mount /data type ext4 )

fs_mgr: __mount(source=/dev/block/mmcblk3p6,target=/cache,type=ext4)=-1

fs_mgr: Failed to mount an un-encryptable or wiped partition on/dev/block/mmcblk3p6 at /cache options: nomblk_io_submit error: No such file or directory

fs_mgr: __mount(source=/dev/block/mmcblk3p7,target=/device,type=ext4)=-1

fs_mgr: Failed to mount an un-encryptable or wiped partition on/dev/block/mmcblk3p7 at /device options: (null) error: No such file or directory

init: fs_mgr_mount_all returned an error

init: fs_mgr_mount_all returned unexpected error 255

======

meanwhile this is the same part of the properly booting log

======

ALSA device list:

#0: wm8962-audio

#1: imx-hdmi-soc

Freeing unused kernel memory: 432K (c0be3000 - c0c4f000)

audit: type=1403 audit(2.670:2): policy loaded auid=4294967295 ses=4294967295

audit: type=1404 audit(2.680:3): enforcing=1 old_enforcing=0 auid=4294967295 ses=4294967295

Console: switching to colour dummy device 80x30

bio: create slab <bio-1> at 1

EXT4-fs (dm-0): mounted filesystem with ordered data mode. Opts: barrier=1

fs_mgr: __mount(source=/dev/block/dm-0,target=/system,type=ext4)=0

EXT4-fs (mmcblk2p4): Ignoring removed nomblk_io_submit option

EXT4-fs (mmcblk2p4): mounted filesystem with ordered data mode. Opts: nomblk_io_submit,noauto_da_alloc,errors=panic

fs_mgr: __mount(source=/dev/block/mmcblk2p4,target=/data,type=ext4)=0

EXT4-fs (mmcblk2p6): Ignoring removed nomblk_io_submit option

EXT4-fs (mmcblk2p6): mounted filesystem with ordered data mode. Opts: nomblk_io_submit

fs_mgr: __mount(source=/dev/block/mmcblk2p6,target=/cache,type=ext4)=0

EXT4-fs (mmcblk2p7): mounted filesystem with ordered data mode. Opts: (null)

fs_mgr: __mount(source=/dev/block/mmcblk2p7,target=/device,type=ext4)=0

Adding 307196k swap on /dev/block/zram0. Priority:-1 extents:1 across:307196k SS

======

as you can see, the proper configuration should be to boot from 'mmcblk2' while the the problematic sd card image boot from 'mmcblk3'.

Which part should I look into to fix this issue?

Am I right to think that the problem is in the ramdisk image since all this 'mounting' is a procedure due to executing '/init' which is located in the ramdisk?

Re: wrong boot device at kernel/ramdisk boot stage... where should I look in to solve this?

igorpadykov — Fri, 01 Apr 2016 04:23:41 GMT

Hi chadric

this may depend on boot device, please check Android Guide sect.6.1.1 Booting

from MMC/SD on the i.MX 6DualQuad/6DualLite SABRE-SD board

Best regards

igor

-----------------------------------------------------------------------------------------------------------------------

Note: If this post answers your question, please click the Correct Answer button. Thank you!

-----------------------------------------------------------------------------------------------------------------------

Re: wrong boot device at kernel/ramdisk boot stage... where should I look in to solve this?

chadrickkwag — Fri, 01 Apr 2016 05:03:52 GMT

I've checked it and do not think this is the problem.

My uboot envs are already set accordingly with the pdf file. It is configured to boot from sd card.

Again, I believe the real reason behind my problem lies withint the /init file which as far as I know, is the script that is executed once the kernel is booted.

The log error messages indicate failure at mounting partitions. Wouldn't some part in '/init' script be responsible for this?

If you can shed any light on my hunch, I would be grateful. Thanks

Re: wrong boot device at kernel/ramdisk boot stage... where should I look in to solve this?

chadrickkwag — Tue, 05 Apr 2016 12:02:33 GMT

i have solved this problem.

My hunch that the problem is due to the ramdisk init file was partially right.

The solution indeed required modifying the ramdisk but it wasn't the init file to be exact. It was the fstab configuration file. In my case, where I am developing on sabre-sdb(imx6quad) Lollipop 5.1 BSP, the ramdisk has a file named 'fstab.freescale'. Opening the fstab file for the problematic image ramdisk, the contents were as below:

=======================================

# Android fstab file.

#<src> <mnt_point> <type> <mnt_flags and options> <fs_mgr_flags>

# The filesystem that contains the filesystem checker binary (typically /system) cannot

# specify MF_CHECK, and must come before any filesystems that do specify MF_CHECK

/devices/soc0/soc.0/2100000.aips-bus/2198000.usdhc/mmc_host /mnt/media_rw/extsd vfat defaults voldmanaged=extsd:auto

/devices/soc0/soc.0/2100000.aips-bus/2184000.usb/ci_hdrc.0 /mnt/media_rw/udisk vfat defaults voldmanaged=udisk:auto

/dev/block/mmcblk3p5 /system ext4 ro,barrier=1 wait,verify

/dev/block/mmcblk3p4 /data ext4 nosuid,nodev,nodiratime,noatime,nomblk_io_submit,noauto_da_alloc,errors=panic wait,encryptable=/dev/block/mmcblk3p9

/dev/block/mmcblk3p6 /cache ext4 nosuid,nodev,nomblk_io_submit wait

/dev/block/mmcblk3p7 /device ext4 ro,nosuid,nodev wait

/dev/block/mmcblk3p1 /boot emmc defaults defaults

/dev/block/mmcblk3p2 /recovery emmc defaults defaults

/dev/block/mmcblk3p8 /misc emmc defaults defaults

/dev/block/mmcblk3boot0 /bootloader emmc defaults defaults

/dev/block/zram0 none swap defaults zramsize=314572800

========================================

In comparision, opening the same fstab.freescale file in the functional ramdisk, the contents were as below:

====================================

# Android fstab file.

#<src> <mnt_point> <type> <mnt_flags and options> <fs_mgr_flags>

# The filesystem that contains the filesystem checker binary (typically /system) cannot

# specify MF_CHECK, and must come before any filesystems that do specify MF_CHECK

/devices/soc0/soc.0/2100000.aips-bus/2194000.usdhc/mmc_host /mnt/media_rw/extsd vfat defaults voldmanaged=extsd:auto

/devices/soc0/soc.0/2100000.aips-bus/2184000.usb/ci_hdrc.0 /mnt/media_rw/udisk vfat defaults voldmanaged=udisk:auto

/dev/block/mmcblk2p5 /system ext4 ro,barrier=1 wait,verify

/dev/block/mmcblk2p4 /data ext4 nosuid,nodev,nodiratime,noatime,nomblk_io_submit,noauto_da_alloc,errors=panic wait,encryptable=/dev/block/mmcblk2p9

/dev/block/mmcblk2p6 /cache ext4 nosuid,nodev,nomblk_io_submit wait

/dev/block/mmcblk2p7 /device ext4 ro,nosuid,nodev wait

/dev/block/mmcblk2p1 /boot emmc defaults defaults

/dev/block/mmcblk2p2 /recovery emmc defaults defaults

/dev/block/mmcblk2p8 /misc emmc defaults defaults

/dev/block/mmcblk2 /bootloader emmc defaults defaults

/dev/block/zram0 none swap defaults zramsize=314572800

=====================================

As you can see the problematic version has been all set to 'mmcblk3' which is identical to the log retrieved from the log, which is shown in the main post.

Thus what I had to do was switch the problematic fstab.freescale file with the functional version.

I repacked the image(kernel+ramdisk+dtb) with mkbootimage (be sure to properly set the boot addresses for each), and checked that it works!