Size of my DragonBoard 410c' eMMC is very small



Size of my DragonBoard 410c’ eMMC is very small

I want to boot AGLv3.0.4(agl-image-minimal) on DragonBoard 410c, and my try is successful.
But, size of my DragonBoard 410c’s eMMC is vary small.

Filesystem       1K-blocks     Used  Available Use% Mounted on
/dev/root          590260     555916               0 100% /

I think correct value of 1K-blocks is nearly 8000000.
What is the cause of this problem?

P.S poor English. Sorry.


This command shows the size of your root filesystem, not the size of your eMMC!

Try using fstab to show the partition table.

fstab /dev/mmcblk0


Using fdisk (p command), I saw the partition table /dev/mmcblk0.
This result is following…

Devices Boot        Start     End  Blocks     Id  System
/dev/mmcblk0p1         1  22103 265231+ ee EFI GPT

and Using v command

14739416 unallocated sectors

cat /etc/fstab

# stock fstab - you probably want to override this with a machine specific one

/dev/root            /                    auto       defaults              1  1
proc                 /proc                proc       defaults              0  0
devpts               /dev/pts             devpts     mode=0620,gid=5       0  0
tmpfs                /run                 tmpfs      mode=0755,nodev,nosuid,strictatime 0  0
tmpfs                /var/volatile        tmpfs      defaults              0  0

# uncomment this if your device has a SD/MMC/Transflash slot
#/dev/mmcblk0p1       /media/card          auto       defaults,sync,noauto  0  0

I used following command when I made a bootable SD card.

$ sudo fastboot flash boot boot-dragonboard-410c.img
$ sudo fastboot flash rootfs agl-demo-platform-dragonboard-410c.ext4

Should I use fdisk to extend the partion of /dev/mmcblk0?


I retried to make a bootable SD Card.

$ wget
$ unzip
$ sudo ./flashall
$ sudo fastboot flash boot boot-dragonboard-410c.img
$ sudo fastboot flash rootfs agl-demo-platform-dragonboard-410c.ext4
target reported max download size of 268435456 bytes
Invalid sparse file format at header magi

I guess that this message Invalid sparse file format at header magi tell me how to solve this problem.
But, I can’t understand the message and how to solve.

Could you tell me a meaning of Invalid sparse file format at header magi and how to solve this problem?


Could you tell me a meaning of Invalid sparse file format at header magi and how to solve this problem?

It means you tried to write a raw image rather than an Android sparse
image. Android sparse format is slightly closer to the fastboot
wire format making it easier (and sometimes more effiecient) to

Normally this doesn’t matter much and the message is just a warning
since fastboot can still process raw images.

Look at tools like ext2simg (for extX filesystems) and img2simg (for
everything else) if you want to get rid of this problem.


BTW the partition table you saw in /dev/mmcblk0 looks pretty wrong although the size looks about right (just to be sure you didn’t have an 8G SD card connected to the DB410C did you?). Happily the commands you ran to reinstall the bootloaders should have restored a sensible partition table to the eMMC.


The problem is remained.

/dev/mmcblk0 has one partition and, this partition size is as large as rootfs image.

When I use sudo fastboot flash rootfs burabura -S 7G, error happend.

How can I make rootfs’s partition size expanded in making a bootable SD Card?
I want to use full of eMMC.


Bluntly I don’t understand how such a system could possibly be bootable. Are you currently booting from microSD card?

I would recommend you install the latest Debian release using the SD card method (i.e. boot installer from SD card and use that to populate eMMC).

Once you have done that you should be able to remove the uSD card, boot from eMMC and observe the following partition table:

root@linaro-alip:~# fdisk /dev/mmcblk0

Welcome to fdisk (util-linux 2.29.2).
Changes will remain in memory only, until you decide to write them.
Be careful before using the write command.

Command (m for help): p
Disk /dev/mmcblk0: 7.3 GiB, 7818182656 bytes, 15269888 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: gpt
Disk identifier: F1101A36-3F95-429B-8D3D-0F39DE40B316

Device           Start      End  Sectors  Size Type
/dev/mmcblk0p1  131072   131075        4    2K unknown
/dev/mmcblk0p2  131076   132099     1024  512K unknown
/dev/mmcblk0p3  132100   133123     1024  512K unknown
/dev/mmcblk0p4  133124   135171     2048    1M unknown
/dev/mmcblk0p5  135172   136195     1024  512K unknown
/dev/mmcblk0p6  262144   262175       32   16K unknown
/dev/mmcblk0p7  262176   264223     2048    1M unknown
/dev/mmcblk0p8  264224   395295   131072   64M unknown
/dev/mmcblk0p9  395296   397343     2048    1M unknown
/dev/mmcblk0p10 397344 15269854 14872511  7.1G Linux filesystem

That is the right starting point to start using fastboot to install AGL…


Actually things might be a bit clearer if we swapped and started using gdisk instead of fdisk (I’m starting to wonder if the version of fdisk you are running might have been built without GPT support meaning it is only showing us a, slightly broken, protective partition rather than the actual partition table):

root@linaro-alip:~# gdisk /dev/mmcblk0
GPT fdisk (gdisk) version 1.0.1

Partition table scan:
  MBR: protective
  BSD: not present
  APM: not present
  GPT: present

Found valid GPT with protective MBR; using GPT.

Command (? for help): p
Disk /dev/mmcblk0: 15269888 sectors, 7.3 GiB
Logical sector size: 512 bytes
Disk identifier (GUID): F1101A36-3F95-429B-8D3D-0F39DE40B316
Partition table holds up to 128 entries
First usable sector is 34, last usable sector is 15269854
Partitions will be aligned on 4-sector boundaries
Total free space is 256986 sectors (125.5 MiB)

Number  Start (sector)    End (sector)  Size       Code  Name
   1          131072          131075   2.0 KiB     FFFF  cdt
   2          131076          132099   512.0 KiB   FFFF  sbl1
   3          132100          133123   512.0 KiB   FFFF  rpm
   4          133124          135171   1024.0 KiB  FFFF  tz
   5          135172          136195   512.0 KiB   FFFF  hyp
   6          262144          262175   16.0 KiB    FFFF  sec
   7          262176          264223   1024.0 KiB  FFFF  aboot
   8          264224          395295   64.0 MiB    FFFF  boot
   9          395296          397343   1024.0 KiB  FFFF  devinfo
  10          397344        15269854   7.1 GiB     8300  rootfs

Command (? for help):


Assuming the problems so far really are down to having a feature reduced version of fdisk then an interesting experiment might be something like: resize2fs /dev/root or resize2fs /dev/mmcblk0p10. Whether this works or not depends on a lot factors about your system that you haven’t shared… but it might work.


Thank you for everything.
But, I can’t solve this problem. I will give up.

I used AGL 3.0.4 because I can’t build some package I want to add in rootfs(e.g. python-smbus, python-pip…etc) in AGL4.0.2.

I succeeded to boot correctly AGL 4.0.2, but I can boot only bad AGL3.0.4, that has too small rootfs and wrong partition.