4.14 doesn't boot on ifc6601

Products Support DragonBoard 820c
#1

Hi all,

I’m using an IFC6601 board based on snapdragon 820,
we currently use with success the 4.11 branch of linaro with the meta-qcom
layer, and we look to move on a LTS kernel.

So we tried the 4.14 linaro branch (release/qcomlt-4.14) on this sha-1 1df12036cb4a5df7325781ae2667f1fee69f3929

and the kernel is stuck early in the boot.
https://pastebin.com/raw/HaHcdwm2

Maybe we have slight difference between db820c and ifc6601,
and we have to modify the device tree.
If you have any highlight it could be helpful.

Thanks a lot,
Julien

#2

Looking at the pastebin it struck me that setting initcall_debug might left you know which driver is coming up when the kernel stops:
https://elinux.org/Initcall_Debug

#3

Hi,
I enabled initcall_debug in cmdline, but most likely the kernel
is stuck in an earlier process so it didn’t offered much information.

https://pastebin.com/raw/wyyL8BPg

Regards,
Julien

#4

The debug messages are printed at KERN_DEBUG… you need to set the kernel loglevel to be able to see them on the console (debug should do it).

#5

Good catch indeed it’s more verbose
https://pastebin.com/raw/7GB8qCjq

So the kernel is stuck in arm_smmu_driver_init

#6

Good catch indeed it’s more verbose
https://pastebin.com/raw/7GB8qCjq

So the kernel is stuck in arm_smmu_driver_init

Cool. I know we might have guessed that from the original traces but at
least now you know its worth the effort digging deeper in this specific
area.

I’m afraid I don’t have any more sneaky ideas though… just debugging
:frowning: .

#7

Thanks anyway, i know where to look.
It seems that’s there is difference between both branch
regarding arm-smmu I can try to disable some part to see where the problem is.

Thanks,
Julien

#8

Arm SMMU is (mostly) set up during the early bootloader phases. Recently there have been some changes to the bootloaders. Are you mixing old(er) boot loaders with new(er) kernel?

Full Disclosure: I am currently an employee of Qualcomm Canada and any opinions I may have left in this or any other post do not necessarily match the opinions of my employer. As of May 22nd/2018 I will no longer be employed by Qualcomm Canada. Currently looking for new opportunities, you can contact my personal email through the forums at 96Boards.

2 Likes
Random kernel crashes observed on some boards
#9

Thanks a lot ljking,

I could passed a long time before figuring that.

My board was initially made to run a 3.18 kernel, and I’m indeed looking for
upstream kernel.

So What I did is reflashing my board using the instruction for board recovery

Although I’m using a different board than db820c with a different ufs, it succeed, and even boot.

It’s working, now I can boot linaro kernel, and have a perfect and clean Yocto setup,
with a LTS kernel with shiny features as camera support, video encoding, audio, dsp, gpu.

Thanks a lot,
You made my day

#10

And mine :wink:

I always like reading success stories in the morning!

#11

Hi Julien,
I am trying to do the same thing you did. I updated the kernel of my IFC6601 to the version that the dragonboard uses. Then I went to the DragonBoard 820c Board Recovery as you stated. At this point I am not sure what to do. Can you describe to me in detail what steps you took from this page? Did you use fastboot or SD card? If you used fastboot, which commands did you issue specifically?
Thanks,
kimbo

#12

Hi kimbo,
Download the dragonboard-820c-bootloader-ufs-linux-35.zip package from
https://snapshots.linaro.org/96boards/dragonboard820c/linaro/rescue/latest/

put the board in fastboot mode then run flashall script which is found inside the package.

Then flash boot and rootfs images.

This is generic for all db820c based boards.

Thanks

#13

Hi kimbo,
As laxman said you can use fastboot.
You can also only flash the bootloader and not the partition table:
fastboot flash cdt sbc_1.0_8096.bin
fastboot flash xbl xbl.elf
fastboot flash rpm rpm.mbn
fastboot flash tz tz.mbn
fastboot flash hyp hyp.mbn
fastboot flash pmic pmic.elf
fastboot flash aboot emmc_appsboot.mbn
fastboot flash devcfg devcfg.mbn
fastboot flash cmnlib64 cmnlib64.mbn
fastboot flash cmnlib cmnlib.mbn

The reason why I prefer to not flash the partition table is to keep the system and data partition
separated, instead of having only a rootfs partition.
In this case you will ne be able to boot the linaro build since it’s looking for init/rootfs in a different location.

I also flashed the files using qdl as explained in DB820c board recovery documentation,
to be able to put the ifc6601 in EDL mode.

I strongly advise to ask for it from inforce, since you are about to reflash the bootloaders and GPT partition.

Julien

#14

Hi. Thanks for the response. I did what laxman suggested. I ran flashall, then flashed boot image and then tried flashing rootfs, but I get this error:
fastboot flash userdata linaro-buster-alip-dragonboard-820c-212.img
target reported max download size of 536870912 bytes
erasing ‘userdata’…
FAILED (remote: Partition table doesn’t exist
)
finished. total time: 0.012s

Is this because of something in the flashall script?

Thanks,
kimbo

#15

Hi,
Yep your partition table changed and now you no longer have userdata or system partition,
but only a rootfs partition.
so you can do
$ fastboot flash rootfs linaro-buster-alip-dragonboard-820c-212.img

as explained here

Regards,
Julien

#16

Hi Julien,

I see now and it does work. This is per your previous statement of keeping userdata and system separate, by only issuing select flashall commands and not repartitioning things. Sorry I did not get that before. Did you then keep the userdata as it was from Inforce if you don’t run the repartition commands?

Thank you for your help,

kimbo

#17

Hi Kimbo,

This is exactly what I did.
I kept the origin gpt partition and only reflashed the bootloaders.

Julien

#18

Hi Julian,
Thanks for the response. So I tried as you suggested. First I put the inforce board back to original state with qdl recovery and loaded the original aboot, boot, and userdata. Restarted the system and everything seems to be working. Then I went back into fastboot mode and executed these commands:
fastboot flash cdt sbc_1.0_8096.bin
fastboot flash xbl xbl.elf
fastboot flash rpm rpm.mbn
fastboot flash tz tz.mbn
fastboot flash hyp hyp.mbn
fastboot flash pmic pmic.elf
fastboot flash aboot emmc_appsboot.mbn
fastboot flash devcfg devcfg.mbn
fastboot flash cmnlib64 cmnlib64.mbn
fastboot flash cmnlib cmnlib.mbn
fastboot flash keymaster keymaster.mbn

fastboot flash boot boot-linaro-buster-dragonboard-820c-212.img

After that I rebooted. I see this in the serial debug output and I do not get to a command prompt: Begin: Running /scripts/local-block … done.
Begin: Running /scripts/local-block … done.
done.
Gave up waiting for root file system device. Common problems:

  • Boot args (cat /proc/cmdline)
    • Check rootdelay= (did the system wait long enough?)
  • Missing modules (cat /proc/modules; ls /dev)
    ALERT! /dev/disk/by-partlabel/rootfs does not exist. Dropping to a shell!
    (initramfs) [ 54.123248] usb 1-1.1: USB disconnect, device number 3
    [ 55.639060] usb 1-1.1: new low-speed USB device number 6 using xhci-hcd
    [ 55.790744] input: PixArt USB Optical Mouse as /devices/platform/soc/soc:usb@6a00000/6a00000.dwc3/xhci-hcd.0.auto/usb1/1-1/1- :4E70.0004/input/input4

How can I use this system now? Can I do anything to get a command prompt and to use the original filesystem?
Thanks,
kimbo

#19

I think I see what is going on. The kernel is point to rootfs for the filesystem. So I think I’ve got to rebuild the Dragonboard kernel with the bootargs set to use userdata instead of rootfs. Is this correct?
Thanks,
Kim

#20

Hi kim,
instead of rebuilding kernel again, with below command you can change the command line to point to userdata instead of rootfs

abootimg -u boot-linaro-buster-dragonboard-820c-212.img -c “cmdline=root=/dev/disk/by-partlabel/userdata rw rootwait console=tty0 console=ttyMSM0,115200n8”