Custom board - First time flash with QFIL (no SD)



ok , here is another attempt


Uhmm, do you copy-paste this from a terminal? Scroll all the way to the right - the lines are still truncated


hhm… ENEEDCOFFEA… my bad. I have updated the gist now.

just to make it clear, the following attributes for partitions sec, aboot and boot respectively should be

start_byte_hex="0x8280000" start_sector="267264"
start_byte_hex="0x8284000" start_sector="267296"
start_byte_hex="0x8384000" start_sector="269344"

Instead of what is in the bootloader build.


Looks good now, thanks! Will test right away


Works perfectly now, thank you!
For future reference: patched rawprogram.xml, flash + boot log,


I could also boot in fastboot mode, thank you for the help.

However, when flashing rootfs in fastboot mode, I got the following error:

target reported max download size of 268435456 bytes
sending sparse 'rootfs' (261171 KB)...
OKAY [ 53.902s]
writing 'rootfs'...
FAILED (remote: size too large)
finished. total time: 53.912s

I use a 4GB emmc on my custom board with a separate 1Gb RAM. Should I change something on the bootloader to allow me to flash rootfs with fastboot?

Thank you


When you run

simg2img rootfs.img rootfs.raw

how big is the resulting rootfs.raw ?


ok, cool! I am very sorry about the confusing situation. i will make a new bootloader release next week with this fix.

for the rootfs, which image are you trying to flash? for our ALIP image we create a 3GB file system, if i remember correctly. so you need at least this size.

can you try a smaller image to start with (such as the developer image). if that works, then please report the output of gdisk -l /dev/mmcblk0

we can debug that further.


@jakob-tsd the resulting rootfs.raw is 4G. I guess this is too much for my 4GB emmc.

I will try @ndec suggestion to flash the developper image.

I hope the developper image is good enough for my product. I do not need any desktop experience anyway.

Thank you for your help, I keep in touch


I was able to flash the developper image.
Now I am stuck in initramfs:

Begin: Running /scripts/local-block ... 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) cat /proc/cmdline

I think I am getting close to getting it to work but still something must be wrong in my build chain.
I am not sure about the "–pagesize 2048 " option in mkbootimg, as I am using a 4GB emmc.

Any help is welcome, thank you


I would try boot-linaro-buster-dragonboard-410c-359.img from first, and see if this works. Then, I’d follow the build instructions on the bottom of the page, in the section How to get and customize the kernel source code


Hello, thank you for your answer.

I tried flashing original images as you suggested, but the error is still the same, I am stuck in initramfs as it cannot find the rootfs.
ALERT! /dev/disk/by-partlabel/rootfs does not exist. Dropping to a shell!

Any hints? (I can create a new thread maybe?)


Yeah, new thread is better I think



Can you please provide the full boot log when it failed?

Can you please confirm that when using the SD rescue method, and the same rootfs (e.g. developer) , then everything works as expected? If so, please report the output of

gdisk -l /dev/mmcblk0

I am trying to understand if this is a problem when flashing with QDL, or something related to your hardware config.

To debug further, we might need to use the SD card with the developer image, e.g. the full Linux system is on the SD card, and we boot from SD card. From that point, we would be able to inspect the eMMC using gdisk as well.


Hello ndec,

Thank you for your answer;

Please find here the boot logs when it failed (after successfully flashing with fastboot the developper rootfs)

I will give a try with the SD card tomorrow and let you know the results.


hello Vix,

Using --pagesize 2048 is ok for DB410c.

It looks like you are building your own kernel and get a few issues throughout the boot. Can you please provide more details about your kernel:

  • which branch/commit?
  • how do you configure it?
    I suspect you are not using the right defconfig options…

Have you tried with our released kernel ? if not can you please try? If yes , do you have same issues?


Hello ndec,

Indeed in my custom board I use a custom kernel, based on linaro debian 18.01 release.

However, I also tried with the released kernel 18.01 (not custom), as follow:
I successfully flashed with fastboot: bootloader files from dragonboard410c_bootloader_emmc_linux-88, boot-linaro-buster-dragonboard-410c-359.img and the rootfs linaro-buster-developer-dragonboard-410c-developer-359.img.
Then I reboot and it also gets stuck in initramfs. See boot logs here.

Then, I also tried with my custom kernel, but I end up with the same problem at boot.
In my custom kernel, I change a few stuff in config/dts related to OV5640 camera. Also, I remove everything related to hdmi in the dtsi file (I do not use hdmi). But that’s pretty much it. here are the boot logs when booting my custom 18.01 kernel.

The issue seems the same in both cases.
I will try to get a sd boot for further debug but that’s a bit tricky on my hardware (I only have tests points to connect a SD card), as I planned not to use a SD card.

Note: as I am not a linux expert, it could be something really simple that I just don’t get. Thank you for any suggestion !


Hello @ndec

I tried to boot from SD card without success:
I flash “dragonboard-410c-sdcard-developer-buster-359.img” on the SD card; then I have the same issue as previously stated at boot:

B - 646447 - Error code 3038 at boot_elf_loader.c Line 334

I use the patched xml when flashing with qdl , so I did not expect this error to come back.
Any hints on what’s happening here?

Note: when I remove the SD card, the board boots in fastboot mode

Thank you,

Stuck in Initramfs




Please don’t use ALL CAPS to ask questions!

In this case I’m afraid we cannot really offer any guidance. None of the tools discussed above have been tested on production phones.