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
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).
Good catch indeed it’s more verbose
https://pastebin.com/raw/7GB8qCjq
So the kernel is stuck in arm_smmu_driver_init
Good catch indeed it’s more verbose
https://pastebin.com/raw/7GB8qCjqSo 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
.
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
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
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
And mine 
I always like reading success stories in the morning!
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
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
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
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
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
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
Hi Kimbo,
This is exactly what I did.
I kept the origin gpt partition and only reflashed the bootloaders.
Julien
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
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
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”
Hi kimbo, laxman,
If that line root=/dev/disk/by-partlabel/userdata doesn’t works try sda9 (if it’s the same layout than my ifc6601).
AFAIK /dev/disk/by-partlabel/* is populated by udev which will not be ready yet
when mounting the rootfs.
Julien
Hi laxman and Julien,
I tried both /dev/disk/by-partlabel/userdata and /dev/sda9 for cmdline and both have the same results. I can get to a command prompt but I do not get as far as the display working. I did notice that there is an error that says:
[FAILED] Failed to start Load Kernel Modules.
See ‘systemctl status systemd-modules-load.service’ for details.
systemd-modules-load.service: Failed with result ‘exit-code’.
It’s not a big deal for me to get this working, I just thought it would be nice if it did because I’m not sure how the dragonboard filesystem differences affect how ifc6601 does things.
Thanks for the help!
Kim
