Bringing Up 820c

Products Support DragonBoard 820c
#1

I have decided to bring up my 820c board. Before doing anything I plugged it in and checked that it was working, check. Holding the volume key and applying power takes me to Fastboot, so I should just need to load a new boot and rootfs and away I go…

So, I loaded the boot and roofs from the latest snapshot #297 Linaro Snapshots and sure enough the board sort of comes up, but it doesn’t get to the debian screen. Hmmm, maybe I need a new aboot and boot loaders, so using the flashall script I installed #43-linux from https://snapshots.linaro.org/96boards/dragonboard820c/linaro/rescue/latest/. This didn’t help.

Next I loaded snapshot #220 (with aboot from #43) and it comes up with no problem, so somewhere between #220 and #297 something changes. after many reflashes of boot and rootfs I have determined that the issue comes in between snapshot #222 (works great) and snapshot #223 (bad).

The console output for #222 is here: Format: Log Type - Time(microsec) - Message - Optional InfoLog Type: B - Since - Pastebin.com

On first boot after loading #223 it eventually comes up (takes over 600 seconds). See Format: Log Type - Time(microsec) - Message - Optional InfoLog Type: B - Since - Pastebin.com but if I reboot it doesn’t come up (or at least not in the 1300+ seconds I was willing to wait), see boot log here: Format: Log Type - Time(microsec) - Message - Optional InfoLog Type: B - Since - Pastebin.com

I looked at the build changes for #223 and a lot of packages have changed, as well as the kernel, from #222. Linaro Snapshots

What infrastructure in the UFS have I missed changing to get the later snapshots to work?

Thanks in advance for your help.

#2

I am pleased to see I am not the only one having problems. :slight_smile:

When I first tried debian snapshot 297, it got into a loop of connecting and disconnecting my usb mouse.
If I unplugged the mouse, the boot seemed to time out while ‘Creating SSH2 RSA key’ and stopped at:

[ TIME ] Timed out waiting for device /dev/ttyMSM0.
[DEPEND] Dependency failed for Serial Getty on ttyMSM0.

A little research prompted me to check that CONFIG_FHANDLE, CONFIG_VT and CONFIG_IKCONFIG are set; they are.
At this point, ctrl+c, entered in the serial console, allowed the boot to continue to the heartbeat but no prompt was available in the serial console, hdmi was still not working for me and I could not login by ssh.

I would appear that it is aquisition of some entropy for the initial generation of the SSH key that is causing the problem.

On the fifth boot, with the mouse disconnected, the SSH keys were created and boot continued to a prompt. If the mouse was plugged in at this point, it did not disconnect and I could also log in by ssh.

On the sixth boot, with the mouse connected, everything seems to work correctly, after the mouse reconnects a few times.

If you are interested, I could pastebin the logs, as I recorded them.

BTW, for some time, the only change in the firmware has been in LK. So that is all you need to update.
For example:
$ diff -r dragonboard-820c-bootloader-ufs-linux-43 dragonboard-820c-bootloader-ufs-linux-34
Binary files dragonboard-820c-bootloader-ufs-linux-43/emmc_appsboot.mbn and dragonboard-820c-bootloader-ufs-linux-34/emmc_appsboot.mbn differ
diff -r dragonboard-820c-bootloader-ufs-linux-43/MD5SUMS.txt dragonboard-820c-bootloader-ufs-linux-34/MD5SUMS.txt
4c4
< 2493946e0fa75ff8372c41737d3a9afb emmc_appsboot.mbn
—
> 3df3d6e307cbe2fcf2420fee5da0a6dd emmc_appsboot.mbn

#3

Thanks @kldixon

It hadn’t occurred to me to try rebooting over and over, after all the definition of insanity is trying the same thing over and over and expecting a different result :wink: But you are correct, after the 6th boo is works pretty normally, with the exception of needing to hit -C on the connected keyboard to get the UI to come up.

I am using aboot #43. I think we are seeing the same issue. I suspect that the kernel developers that use the system every day are using the “developer” version, and not the “alip” version, hence they haven’t observed this issue.

-Lawrence-

#4

Interesting. I don’t have an specific insight onto the DB820C but I did notice that the current DB410C snapshots (and 19.01 release candidate) have an annoying bug w.r.t. SSH key generation. Specifically the images to not include rngd so the h/ware RNG is not feeding entropy into the kernel properly meaning it takes ages to generate SSH keys.

It is possible the same problems are apparent in DB820C images…

#5

I have tried recent snapshots on both platforms (820c and 410c). 820 is worse but both show the same thing.

#6

I was trying to reproduce my OpenCV issues, but now when I do apt-get upgrade it loads hundreds of packages and then the board no longer boots. This happens with older snapshots that were working acceptably.

So I tried a newer snapshot (#325 today) and a new issue has crept in. The ath10k_pci driver is crashing and causing the board to shutdown. Here is the last message sent to the console:

[ 431.841396] ath10k_pci 0000:01:00.0: Unknown eventid: 3

This is consistent for the last few builds. Is nobody actually using the db820c daily build?

#7

Your problem after apt-get is probably caused by the kernel modules being updated and so no longer corresponding to the running kernel.
I am not a debian user, except for these builds, but you need to exclude the kernel module package from being updated by whatever mechanism apt-get provides.

#8

I can understand that the kernel and modules can get out of sync when upgrading. However this happens when I take a build from the daily builds and load both a new kernel and a new rootfs (which should contain the correct modules).

#9

I’m afraid I can only really offer sympathy and a bug report on this one.

I’m surprised by the breakage during an apt upgrade though. I thought kernel pinning was enabled in the snapshots but maybe that only impacts the DB410C snapshots. What snapshot should I start from if I wanted to try and reproduce?

#10

I haven’t tried every daily build, but certainly 308, 324 and 325 exhibit the ath10k_pci problem. I will try again in a few days. I am downloading the boot-linaro-buster-dragonboard-820c-324.img and linaro-buster-alip-dragonboard-820c-324.img files, using fastboot to install them into the board, then restarting. It often takes 400 or 500 seconds to get past the creating RSA key issue (see above discussion) before enough of the system starts enough to hit the ath10k_pci error. I am using the latest linux boot loaders from https://snapshots.linaro.org/96boards/dragonboard820c/linaro/rescue/43/

#11

Anybody had any luck with this? I am seeing both the

[ TIME ] Timed out waiting for device /dev/ttyMSM0.
[DEPEND] Dependency failed for Serial Getty on ttyMSM0.

Bug on bootup, and the ath10k_pci serial crashes with the latest linaro builds for the 820.

#12

In reference to the ath10k crash, I just looked at kernel source, and there are no changes to ath10k between 296 and 329 (v4.14.90 - v4.14.96) and then lo and behold yesterday it looks like a fix may have been merged to thud branch of meta-qcom:

I can’t test this till monday but looks promising.