Directly copy linux kernel and .dtb file to SD card's partition/directory?

Products Support DragonBoard410c
#1

Hi!
I’m trying to find a way to update the linux kernel and .dtb file of the Debian on my SD card, which boots directly on Dragonboard 410c and doesn’t use DB410c’s eMMC. (That SD card was originally programmed with dragonboard-410c-sdcard-developer-buster-528.img)

By following the instructions (" How to get and customize the kernel source code") in this webpage: https://releases.linaro.org/96boards/dragonboard410c/linaro/debian/latest/, I’ve successfully created: the linux kernel (Image.gz), the .dtb (apq8016-sbc.dtb) and a boot image boot-db410c.img.

Now I want to update the linux kernel and .dtb file on SD card. I’m wondering, in addition to using the utility fastboot, can I simply copy the linux kernel (Image.gz) and .dtb (apq8016-sbc.dtb) files to some partition/directly of the SD card? If this is possible, that it will be very very convenient.
Or, should I use fastboot anyway??

#2

hi,

it is unfortunately still not very straight forward to do that… but it’s possible :wink:

The kernel has artifacts in a several places and they all need to be updated at once.

  1. the boot image has the DTB and the kernel Image file
  2. the rootfs has the kernel modules (in /lib/modules/xxx)

Updating #1 without #2 will mostly likely break your boot.

You can’t use fastboot , since fastboot is mostly meant to write to eMMC. When booting from SD card, fastboot “might” actually try to write into SD card, but I don’t recommend doing so because I don’t think we’ve tested that. So for now, let’s assume that we don’t know the outcome…

Once you have built your kernel and boot image on your PC/host, just put your SDcard on the host, and you can use ‘dd’ to copy the boot image into the ‘boot’ partition, e.g.

dd if= of=/dev/mmcblk0pX

where mmcblk0pX is the ‘boot’ partition on the SD card (it can be /dev/sdbXX depending on your PC and SD card controller).

In fact what fastboot really does is to provide a custom protocol to do a ‘byte copy’ over the USB cable, so doing ‘dd’ on the card itself is equivalent.

Then you need to mount your rootfs from the SD card on the host, and copy the kernel modules you deployed with “make modules_install” onto the target rootfs.

in theory it should then “just work”.

If you do that, that also means you are overwriting the debian file system without using debian packages, so the kernel modules will be ‘orphan’ files as far as debian packaging system is concerned. which is fine for local testing. Instead you could build a debian kernel package out of your kernel tree (using deb-pkg makefile target from Linux) , and instead of manually copying the modules you could:

  1. build boot image
  2. build .deb file and copy on the target (before updating the kernel)
  3. use dpkg -i to install your custom .deb file
  4. reboot and use ‘dd’ to copy the new boot image on the SD card
  5. reboot
#3

Hi @anon91830841,
Thank you for providing such a clear description!
Let me try your way and feedback later.

#4

Hi @anon91830841,
Unfortunately, after dd boot-db410c.img to the boot partition (/dev/sdb7 on the host) and copy /lib/modules to rootfs on SD card, it seems to fail to boot because it doesn’t respond the ping command from host any more. Well, the heartbeat LED still blinks after power-on, anyway.
Any comment? If not, then I may need to get a UART to USB cable to check the console message.

#5

It looks like module issue since your board seems able to boot (heartbeat), but does network drivers (e.g. usb, wifi)… What your /lib/module directory looks like, is the version aligned with kernel?

Yes it is a must for debugging.

#6

Hi @Logic,
Thanks for your comment.
It’s great to know some part of it boots at least. :slight_smile:

What your /lib/module directory looks like, is the version aligned with kernel
Well, it looks like fine. I generated it according to the instructions (" How to get and customize the kernel source code") in this webpage: https://releases.linaro.org/96boards/dragonboard410c/linaro/debian/latest/. And the img file dragonboard-410c-sdcard-developer-buster-528.img originally programmed to that SD card was downloaded from the webpage, too. So I assume they are aligned.

#7

You should be able to reflash the original boot image (that worked). At least you should boot again and inspect the module folder.

I don’t remember if we release the sd boot image file but you can extract it from the full sd image if needed.

Le jeu. 4 juil. 2019 à 15:32, oliverchen via 96Boards Forum noreply@discuss.96boards.org a écrit :

#8

Hi @anon91830841,

I don’t remember if we release the sd boot image file

Well, I think Linaro has released it as boot-sdcard-linaro-buster-dragonboard-410c-528.img. After dd this img file to the boot partition of SD card just programmed with dragonboard-410c-sdcard-developer-buster-528.img, the SD card still boots successfully.

And, I think the lib/modules I created is OK, because after I use it to replace the /lib/modules in SD card just programmed with dragonboard-410c-sdcard-developer-buster-528.img, the SD card still boots successfully and I can ssh to DB410c.

Maybe I’ve found the root cause of this symptom: The boot image boot-db410c.img I created IS for eMMC, NOT for SD card.

By compare the “boot” partitions of SD card, eMMC and img files from Linaro, I found there are two types of bootargs: one for eMMC and one for SD card. I’ve summarized the bootargs and where they are found respectively in the following list:

  1. boot-db410c.img: The boot img I created

root=/dev/disk/by-partlabel/rootfs rw rootwait console=ttyMSM0,115200n8

  1. mmcblk0p8.bin: eMMC’s partition 8

root=/dev/disk/by-partlabel/rootfs rw rootwait console=tty0 console=ttyMSM0,115200n8

  1. boot-sdcard-linaro-buster-dragonboard-410c-528.img: SD card boot img from Linaro

root=/dev/mmcblk1p9 rw rootwait console=ttyMSM0,115200n8

  1. loop0p7.img: Partion 7 of dragonboard-410c-sdcard-developer-buster-528.img

root=/dev/mmcblk1p9 rw rootwait console=ttyMSM0,115200n8

As you can see, 1 & 2 are similar, 3 & 4 are identical. So I guess the boot image boot-db410c.img I created is for eMMC, not for SD card.

If my guess were true, then I’m wondering how I should create the boot image like boot-sdcard-linaro-buster-dragonboard-410c-528.img?

#9

hi,

I am not sure I understand your last question. Not sure why you are asking “how”. For SD boot, we are using a different bootloader ‘package’, the one call “bootloader-sd-linux”, e.g. http://releases.linaro.org/96boards/dragonboard410c/linaro/rescue/19.01/dragonboard-410c-bootloader-sd-linux-110.zip

The difference between the ‘eMMC’ and the ‘SD’ bootloader packages are:

  1. different bootloader (it needs to read from SD , not from eMMC)
  2. different ptable, you can find the ptable we use for eMMC and SD here:
    partitions.txt « linux « dragonboard410c - working/qualcomm/db-boot-tools.git - [no description]
    sdcard.txt « linux « dragonboard410c - working/qualcomm/db-boot-tools.git - [no description]

For the reference, the scripts that generates the SD image that we release is here:
https://git.linaro.org/ci/job/configs.git/tree/lt-qcom-debian-images/sdcard-dragonboard-410c.sh

There, you can see that we use /dev/mmcblk1p9 for root partition, instead of using the ‘rootfs’ label. To be honest , i am not sure I remember exactly why we are doing that… The only reason I can think of is to make sure that we mount ‘rootfs’ on the SD card, in case the eMMC bootloader package was flashed into eMMC, in which case there would be 2 partitions with the label rootfs, so using root=/dev/disk/by-partlabel/rootfs would be problematic.

#10

Hi @anon91830841,
Sorry, I didn’t make myself clear.
Thanks to your replies, I’ve found how boot-sdcard-linaro-buster-dragonboard-410c-528.img was created in line 17~23 of https://git.linaro.org/ci/job/configs.git/tree/lt-qcom-debian-images/sdcard-dragonboard-410c.sh :

I experimented to create a boot image for SD boot in the following way:

  1. Create Image.gz+dtb and /lib/modules
    According to the instruction in https://releases.linaro.org/96boards/dragonboard410c/linaro/debian/latest/, I used the following lines to create the file Image.gz+dtb:

    git clone -n working/qualcomm/kernel.git - Qualcomm Landing Team kernel
    cd kernel
    git checkout -b kernel-19.01 debian-qcom-dragonboard410c-19.01
    export ARCH=arm64
    export CROSS_COMPILE=aarch64-linux-gnu-
    make defconfig distro.config
    make -j4 Image.gz dtbs KERNELRELEASE=4.14.0-qcomlt-arm64
    cat arch/arm64/boot/Image.gz arch/arm64/boot/dts/qcom/apq8016-sbc.dtb > Image.gz+dtb
    make -j4 modules KERNELRELEASE=4.14.0-qcomlt-arm64
    make modules_install KERNELRELEASE=4.14.0-qcomlt-arm64 INSTALL_MOD_STRIP=1 INSTALL_MOD_PATH=…/

  2. Make the boot image for SD boot boot-db410c.img:
    mkbootimg
    –kernel Image.gz+dtb
    –ramdisk initrd.img
    –output boot-db410c.img
    –pagesize 2048
    –base “0x80000000”
    –cmdline “root=/dev/mmcblk1p9 rw rootwait console=ttyMSM0,115200n8”

Finally:

  1. Program boot-db410c.img to ‘boot’ partion of the sd card :
    sudo dd if=./boot-db410c.img of=/dev/sdb7
  2. Copy the newly created /lib/modules to rootfs in sd card

Unfortunately, this sd card doesn’t boot anymore. Only the hearbeat LED blinks.

I’m wondering whether there is some wrong with the file Image.gz+dtb?
If the instruction in https://releases.linaro.org/96boards/dragonboard410c/linaro/debian/latest/ is primary for eMMC boot image, then maybe the Image.gz+dtb created using its way is also for eMMC boot, not for SD boot??

1 Like
#11

no, the same kernel an DTB should work regardless of the boot method. as Loic suggested it could be a mismatch with the modules. It will be hard to make progress without UART console access, at this point.

#12

Hi @anon91830841,
OK, I understand. Thanks for your comment.
My UART to USB cable should arrive in few days. I’ll check the console message then.

#13

Hi @anon91830841,
In https://gist.github.com/oliverjungen/9fe5c2b6197a3f604c2943a6ea3663ae you can find the log from DB410c’s UART console.
Any comment will be welcome.

#14

Move the contents to https://gist.github.com/oliverjungen/9fe5c2b6197a3f604c2943a6ea3663ae

#15

Using a pastebin or gist.github.com is good for sharing log files.

#16

All the image creation steps were performed in a host computer ?
Regarding:

export CROSS_COMPILE=aarch64-linux-gnu-

How did you prepared your gcc cross compiler ?

#17

Hi @danielt,
I’ve moved the log to gist.github.com. Thanks for your suggestion!

#18

Hi @gubertoli,

All the image creation steps were performed in a host computer ?

Yes, all performed on a Ubuntu 16.04 x86_64 host.

How did you prepared your gcc cross compiler?

Well, I simply extracted the gcc-linaro-7.4.1-2019.02-x86_64_aarch64-linux-gnu.tar.xz downloaded from Linaro to /opt/gcc-linaro-7.4.1-2019.02-x86_64_aarch64-linux-gnu. Finally added the following line to my .bashrc:

export PATH="/opt/gcc-linaro-7.4.1-2019.02-x86_64_aarch64-linux-gnu/bin:$PATH"

Any comment?

#19

Three things.

  1. I’m a bit confused with the comments about the ethernet RJ-45. A DB410C does not have an RJ-45. I take it you are relying on an additional peripheral?
  2. I didn’t see anything in the update procedures you have mentioned where you updated the kernel modules in the rootfs. Can you confirm what you are doing here?
  3. You should be able to login via the serial port to kick the tyres further. For example you can do things like cat /proc/modules and compare the results to thje regular build.
#20

Hi @danielt,

  1. I’m a bit confused with the comments about the ethernet RJ-45. A DB410C does not have an RJ-45. I take it you are relying on an additional peripheral?

Yes, you are right. It’s a USB to Ethernet adapter. I’m sorry that I should have stated this clearly. This adapter woks fine if I didn’t program the file “boot-db410c.img” to ‘boot’ partition of the sd card.

  1. I didn’t see anything in the update procedures you have mentioned where you updated the kernel modules in the rootfs. Can you confirm what you are doing here?

“updated the kernel modules in the rootfs”: No, I didn’t update the /lib/modules files. Well, I’ll try to update them later and see if it makes any difference.

  1. You should be able to login via the serial port to kick the tyres further. For example you can do things like cat /proc/modules and compare the results to thje regular build.

OK, I’ll try this later.