Hi. Is there some other way to get a rootfs image onto the dragonboard filesystem partition without using fastboot?
Thanks,
Kim
I don’t think there are any alternatives out-of-the-box but you should be able to use fastboot boot aboot.img to boot a kernel with a custom ramdisk and then get use the kernel drivers to copy the rootfs from the network. Mostly I use this technique in reverse (to backup an unfamiliar device before hacking on it) but there is no reason it cannot be used to write out the rootfs.
I generally use buildroot to generate the initramfs. If you want known working config files for buildroot take a look at the ones I use to test kgdb:
PS To inject kernel modules into the cpio file try something like the following:
rm -rf mod-rootfs
make -j `nproc` modules modules_install INSTALL_MOD_PATH=$PWD/mod-rootfs INSTALL_MOD_STRIP=1
gunzip /path/to/rootfs.cpio.gz > rootfs+modules.cpio
(cd mod-rootfs; find . | cpio -H newc -AoF ../rootfs+modules.cpio)
pigz -9 rootfs+modules.cpio
the process of flashing requires 2 main steps:
a. copy from the host to the target memory
b. write from target memory to eMMC
The most important things to do to reduce the overal flashing time are:
- create the smaller possible file system image (you don’t need a 6GB image if your actual content is <1GB). It’s easy to resize the file system image on first boot so that it matches the partition size.
- sparse the image. it can optimize both #a and #b above. sparsing can remove from the file blocks/sector of unused data (if you have ‘holes’ with nodata, then the content is not transfered over USB, and not written into eMMC). Also if your image contains repeated bytes, then the sparse image will encode that and you can save time with #a so that you don’t transfer the repeated bytes.
You can flash using QDL tool as well instead of fastboot (USB bootloader flashing tool). we haven’t done benchmarks so i don’t know if this would be faster than fastboot. But depending on how important it is for you to flash “faster” that might be an interesting experimentation.
Hi danielt and ndec,
Thank you for the good suggestions. I will take a look,
Kim
Hi ndec,
I was going to try using the QDL tool to flash the filesystem image, but I’m not sure of the parameters to the tool. The help gives: qdl [–debug] [–finalize-provisioning] [–include ] <prog.mbn> [ …]
What would be a command line example for using QDL to flash the filesystem image? Do I need special xml files?
Thanks,
Kim
yes, you need a new XML file, e.g. different set of ‘program’ commands. the QDL flashing tool operates at the ‘sector level’, and it’s agnostic from the file system and GPT… so it’s not straight forward to write the XML commands… if it’s just 1 partition it can be done ‘manually’, by determining the start sector and size… ideally a tool would be useful for that… but we don’t have it…
i don’t want to discourage you though, and I would be happy to see some progress on that (including adding support for sparsing the files to avoid flashing unneeded data)…
Hi ndec,
I will keep you posted. Another option we are investigating would be to boot from an sd card and then overlay the rootfs partition from there.
Thanks,
Kim
Hi ndec,
The original .img was 6G and took ~8minutes to flash. I created a sparse version with the fallocate utility and it’s size is 5.8G and takes ~6minutes. This is more reasonable. 8 minutes isn’t bad either, but before this week when I flashed the image to the board, it took closer to 20 minutes. Maybe a Windows update? I do not know. But anyway, it is more in the range we were looking for 
If I get around to trying QDL, I’ll let you know.
Thanks,
Kim
