hi,
it is a bug in LK/fastboot (on the target side). It was found (and fixed) after the initial launch release. If you see this issue, it probably means that you haven’t flashed the most recent bootloaders on the board. e.g. http://builds.96boards.org/releases/dragonboard410c/linaro/rescue/latest/
The bug fix in LK is:
So alternatively, you can recompile LK yourself and reflash it, there are instructions in the release notes for that.
I also ran into this problem on my board that had a bad 5V regulator:
https://www.96boards.org/forums/topic/voltage-problems/
Turning down the input voltage until the 5V rail was actually at 5V (which required ~5.8V input) allowed fastboot to run to completion and everything else to work correctly, but I ended up having to RMA the board to fix the voltage problem in the end anyway.
Thanks ndec! Worked perfectly.
ndec,
What else could the issue be if using a later bootloader and the problem is still present?
Dragonboard came with Android installed. Installed linux bootloader dragonboard410c_bootloader_emmc_linux-50 and installed our kernel and rootfs. Tested various Debian builds over the course of a week.
To test scripts to convert brand new, out of the box Dragons from Android to Debian, I reverted back to latest Android (bootloader dragonboard410c_bootloader_emmc_android-72). I booted into fastboot, installed the linux bootloader, installed Debian kernel, but then ran into rootfs failing.
With dragonboard410c_bootloader_emmc_linux-50:
target reported max download size of 268435456 bytes
sending sparse ‘rootfs’ (260340 KB)…
OKAY [ 12.155s]
writing ‘rootfs’…
FAILED (remote: Bogus size sparse and chunk header)
finished. total time: 31.152s
With dragonboard410c_bootloader_emmc_linux-72:
target reported max download size of 268435456 bytes
sending sparse ‘rootfs’ (260340 KB)…
OKAY [ 12.280s]
writing ‘rootfs’…
FAILED (remote: size too large)
finished. total time: 12.284s
I didn’t have a problem loading this or previous rootfs files prior to flashing back to Android. MD5 checksums match, so I don’t think its a corrupt file.
Given that the two bootloaders I’ve tried were made in Aug and Oct 2016, and this bug was supposedly fixed over a year ago, I have a similar but different problem than the OP did.
Any ideas?
Thanks in advance.
Edit: 5V measured at L14 is 5.06V. So I don’t appear to have faulty board like others that had similar issue.
I can successfully load the latest Linaro debian files:
dragonboard410c_bootloader_emmc_linux-72
fastboot flash boot boot-linaro-jessie-qcom-snapdragon-arm64-20161006-144.img
fastboot flash rootfs linaro-jessie-developer-qcom-snapdragon-arm64-20161006-144.img
I can also successfully write rootfs to my other testing dragonboard that I didn’t just revert back to Android.
So in summary, I have two dragonboards, one that loads rootfs and one that errors. Both went through same process to go from Android to Debian a couple of weeks ago when first received. Both were loaded with same Debian builds provided by my colleague that I’ve been testing with over the last week. The only difference, is that the dragonboard that is no longer accepting my rootfs, was changed back to Android prior to loading this last round of Debian. So it’s like something in that process has dirtied my flash or something.
I’d like to report to my colleague that the rootfs is created wrong, but since it loads successfully ontop of the existing rootfs/Debian, I don’t know if I’m wasting his time or not.
I’m leery to load Android back on my working Dragon in fear I’ll have two Dragon’s stuck unable to load our Debian.
Any suggestions or advice is welcome. Thanks
rootfs from 10/28 that loads without error: 2,768,092,360 bytes
rootfs from 11/17 that fails for “Bogus size sparse and chunk header”: 2,652,007,036 bytes
After rebooting and tripping fastboot again, I can load the 11/17 rootfs that was failing.
Sorry for all the posts, just under a time crunch and this new issue was unexpected.
hi,
sorry, i am confused after the last post 
does that mean that you no longer have any issue?
one thing I wanted to highlight is that you need to power cycle the board after flashing a new set of bootloaders, otherwise the previous bootloaders are still ‘in effect’. that might explain what you were seeing, maybe?
and for the record the Android LK has a bug which is only triggered with large file systems (such as the debian rootfs). It seems that we never trigger the bug with Android rootfs, and QCOM has not merged this bug in their code base… so we have to patch LK for our linux releases, here is a link to the patch
ndec,
Yes, I still had the problem at the end of my post. I’m a terrible ranter.
The solution was to reboot after updating to the linux bootloader before loading boot and rootfs. I had incorrectly noted that fastboot reboot-bootloader didn’t work in that scenario, but it was adb reboot-bootloader that I was thinking of when ran when in Debian.
I would suggest making two changes in your documentation:
Specifically instruct the user to reboot after changing bootloaders and remove the sentence “This section assumes the DB410c is still in fastboot mode from the previous section.”
Add “chmod +x ./flashall” step. I had to every time. I’m not aware of where it wouldn’t be required.
Regards
Hi,
I am having the same issue with regards to Fastboot flashing, i was trying to restore my back-up rootfs_ext4.img to DB410c, the size is about 7.5GB. The following are the steps i did
$ mount -o loop -t ext4 rootfs_ext4.img ./mnt
$ make_ext4fs -s -l 7198M …/rootfs.img ./mnt
this created a rootfs.img file with 122.4MB of size, and after i flash the rootfs it writes a few lines and succeded. However when i tried to boot my DB410c it is stuck on line ‘32 nonblocking pool is initialized’
I’m not sure if the whole image was written in emmc or not… please help
To be honest I’m somewhat skeptical that a 122.4MB rootfs.img is correct… given the data is uncompressed it seems way too small to me. What is on it?
Hi, Daniel.
Thanks for your quick response 
… when i tried to unsparse the image it makes the same file size as my raw rootfs_ext4.img
$ sudo simg2img rootfs.img newrootfs.img
is there any other way i can restore my backup (rootfs_ext4.img) to my DB410c?
Sorry if my previous post confuse you, i’m not sure how exactly i can see what’s inside sparsed (rootfs.img) file (btw i’m still newbie with this ) But when i tried to mount rootfs_ext4.img the figure below is the content
Again… these sizes don’t feel right to me. So far I’m assuming you can’t make it boot because your rootfs is somehow damaged (incompletely backed up?).
To explain the smallest Debian image we offer is 400MB compressed so your rootfs still seems a lot smaller than expected. What was OS was running in the rootfs?
Hi, Daniel.
The OS is debian jessie-linaro-alip, the backup method I used were as follows:
Boot to DB using a bootable SD card (jessie-alip)
Connected to DB a 32GB USB (NTFS format)
Unmounted rootfs partition on eMMC
linaro@linaro-alip:~ sudo umount /dev/mmcblk0p10
linaro@linaro-alip:~
Save rootfs partition on eMMC to USB memory
linaro@linaro-alip:~ sudo dd if=/dev/mmcblk0p10 of=/media/linaro/EC-PHU3/rootfs_ext4.img conv=sync bs=4096
linaro@linaro-alip:~
Unmount the USB memory
linaro@linaro-alip:~ sudo umount /dev/sda1
Removed USB from DB port
Turn off DB.
The tools i used to perform fastboot: android-tools-fsutils, android-tools-fastboot
The bootloader I used was dragonboard410c_bootloader_emmc_linux-72.zip
The bootimage I used was boot-linaro-jessie-qcom-snapdragon-arm64-20161006-144.img.gz
I tried to use different backup (rootfs) image with about same size of 7.5G and use the same command
~/work$ mkdir ./mnt
~/work$ sudo mount -o loop -t ext4 rootfs_ext4.img ./mnt
~/work$
…Still this method creates about the same compressed size, perhaps i’m missing something out? or did a wrong step?
Your answers are greatly appreciated
Hi, Daniel.
I found a solution provided thru this link:
Problem:
It turns out that aside from having issues with fastboot commands, my vm is having a hard time writing to DBoard due to USB set-up as shown below
it should have been set to USB 2.0… that fixed the writing time-outs
I followed the steps provided from link above (thanks to Nicolas )
I changed a few lines as highlighted below
// loop mount the raw img
mkdir mnt
mount -o loop -t ext4 rootfs_ext4.img ./mnt
// create a new rootfs image with the linux mkfs tools and with the content of the original image:
// the size can be small here, we will resize automatically on the first boot.
sudo mkfs.ext4 -L rootfs rootfs_ext4-new.img.raw 7G (here i used 7G as full size of my rootfs_ext4 based on df -Th)
mkdir rootfs2
sudo mount -o loop rootfs_ext4-new.img.raw rootfs2
cp -a mnt/* rootfs2
//create the fastboot sparse image
ext2simg -v rootfs_ext4-new.img.raw newrootfs.img
the newrootfs.img size is about 1.8G and i could write then boot to DBoard successfully.
… Also I tried to directly convert my rootfs_ext4.img (7GB) to sparse image using ext2simg and it also works.
I’m still trying to figure-out what exactly happen to steps provided by Nicolas, but if anyone could enlighten me that would also be very nice … as far as i understand, they tried to shrink the original image into its actual usage size then sparsed it.
I am not sure I understand what you mean or expect here. can you please clarify?
About the rest of your message, yes, you’re right… i didn’t notice that you were using the android make_ext4fs utility, which we stopped using some time ago.
Hi, Nicolas.
Regarding my statement you mentioned, to clarify I am still new to working with Dragonboard410c and Linux environment so i’m still trying to grasp the purpose of each command.
The goal of the steps you provided is quite different than what I try to achieve (since i got the link from a different topic-[eMMC] Partition not getting increased beyond 3.1GB)
My goal is just to restore a backup image to DB using fastboot, but since the steps you provided were somewhat related to the steps i had… i applied it.
and it works like a charm
And with that said, It’s still not quite clear to me i.e. below I used the entire 7G size for my rootfs_ext4-new.img.raw
on the other hand from the sample you provided, you used 2G
… sorry my post got cut, clicked wrong button 
…continue
sudo mkfs.ext4 -L rootfs rootfs_ext4-new.img.raw 7G
(from your sample)…
// the size can be small here, we will resize automatically on the first boot.
mkfs.ext4 -L rootfs linaro-vivid-new.img.raw 2G
Then i also tried to use 2G as my new.img.raw size and still works fine …
Lastly, i tried to experiment a bit more so i tried to just directly convert my backup image to sparsed image and that still works
Does that make any difference?
ok, i see.
mkfs.ext4 will create an image with an ext4 file system on it. The size of the image needs to be more than the actual amount of data. So if your disk has 1.5GB of data, you can create a 2GB image and it will hold everything.
The output is a raw image that can be loop mounted.
The command about ‘the size can be small’ relates to the eMMC partition. On the eMMC we have (by default) a ~7GB partition called ‘rootfs’. When you flash a 2GB image into the 7GB partition , it will work, but when you boot you will notice that the file system size is effectively 2GB, not 7GB.
We have a script in the 96boards-tools package in our images that would run resize2fs command on the first boot , to ensure that the file system size in the rootfs partition is extended to match the size of the partition. Effectively making your 2G filesystem into a 7GB filesystem.
So you could have created a 7GB image / filesystem with mkfs.ext4 in the first place, and it would have worked. But it’s not needed. you just need to create the ‘smallest’ image possible, and then everything is automatically resized on first boot.
Fastboot can flash raw images , in which case it basically just does a ‘dd over USB’, it’s a bit-to-bit copy of the image that gets flashed into eMMC. But it also supports sparse images, where un-needed content is trimmed from the image , and you reduce the size of the image to the bare minimal. When fastboot flashes a sparse image it only sends chunk of valid data in eMMC, and ‘empty’ pages are not copied/initialized.
AWESOME 
you’ve shed light in my dark days this past week, Thanks a lot. 
