8GB eMMC flash?

During production and test, we format only 128MB of eMMC to save time.

You can use Linux fdisk utilities to create a larger partition.

/Matt

Yes, the reason is that during production only 128M of the 8GB device is formatted to save time.  You can format additional partitions (or delete the current one) with

fdisk /dev/mmcblk1

Note: One can create one huge extended partition, but that it will always be 7GB in size and you cannot format that as FAT32.  And the largest primary partition size that you can create is 2048M (2GB).

Important note: After doing the fdisk, you should not do the formatting immediately, because the partition will not be available to format yet.  You have to shut down and power cycle first!  So after running fdisk (look at cat /usr/local/bin/format_emmc.sh to see how to do this in a script) you should shut down (shutdown -h now) and then power cycle by removing the power cable(s).  Hitting the reset button is not enough.  After reset you can run your format and then go through the reset again.  Then you will see your formatted partition with df.

After making a 512MB partition:

root@plnx_arm:~# df

Filesystem                Size      Used Available Use% Mounted on

devtmpfs                 64.0K      4.0K     60.0K   6% /dev

tmpfs                   249.0M     28.0K    248.9M   0% /run

tmpfs                   249.0M     44.0K    248.9M   0% /var/volatile

tmpfs                    64.0K      4.0K     60.0K   6% /dev

/dev/mmcblk1p1          487.3M      4.0K    487.3M   0% /run/media/mmcblk1p1

Can't find /usr/local/bin/format_emmc.sh 

On your MiniZed device, is there no file /usr/local/bin/format_emmc.sh ?  If you are running a device from the factory or if you generated your running image from a published MiniZed BSP, it should be there.  In the 2017.4 and 2018.2 BSP, the user scripts are stored under project-spec/meta-user/recipes-bsp/minized-misc/

Here is the file contentsfor the file (it only formats a 128MB partition):

Stefan

             Just a dumb clarification on the above  procedure for my lack of experience on fdisk etc. You mention that once you delete a partition and add a new one, it has be to power cycled to make the new partition visible.

But in the format_emmc script procedure that you pasted above, you delete the 128MB, added a new one of the same size

and simultaneously did a Fat32 format after a sleep/halt procedure in the same code.

Does the power cycling apply only to extended partitions (and not the primary) so that it is visible in the next boot.

I want to make the primary as 2GB (for FAT-32) to allow sufficient capacity. (like the 512M) that you have shown.

Thanks

Siva R

Siva,

The way I remember this, the very first time you format the flash, a power cycle is not required, so the script above will work.  But subsequent attempts that need a different partition size (not just formatting) will need a power cycle.

Stefan

Stefan

              I will try to modify you script to make it larger (like 512M or 2048M) and see what happens with 1 partition only.

Thanks

Siva R

All,

         I was able to add 2 primary partitions of 2GB each. After fdisk command is executed, you need to power cycle, then do an mkdos format for FAT 32, reboot and in the 3rd cycle, the partitions show up. // This was the BKM I adopted after going through a few iterations and also covered by Stefan earlier.

I was not successful in adding an extended partition. Fdisk is not the problem, but mkdos complains "image is too small" and fails.

Also I read somewhere that it is best to exhaust the 4 primary partitions before going to extended

It also nicely divides the 8GB space into  4 identical partitions that allows F 32 and the useable capacity of 2GB

For now I created 2 primary partitions of 2 GB each in my minized.

The mount command I used for second partition is manual Since it not in the original image.

mount /dev/mmcblk1p2 /p2

Note that initially when you delete the primary (and only partition) (of 128MB from factory) and add the 2048MB partition as primary in my example and commit the partition table, it will not be visible immediately after the fdisk command is executed. Secondly the image.ub stored in the erstwhile partition will be blown away as a side effect.

I used the fdisk /dev/mmcblk1 and then into the prompt window to go through the configuration albeit a script can be used.

On reboot, it will complain that  image.ub is not seen. make sure you have the fallback or smallboot.bin already set up. Run
from the Zynq promt > run boot_qspi   // Follow the restoring guide for factory settings if you need more details

You will get back the 2017.4 peta Linux for example assuming that is your backup image.

% mkdosfs -F 32 -I /dev/mmcblk1p1

% mkdosfs -F 32 -I /dev/mmcblk1p2  // If you have created the 2nd partition)

Either you can add attach USB stick and copy the image.ub, smallboot.bin and the wpa_supplicant files (as discussed in the restoration pdf) to the emmc (p1) mounted as /mnt/emmc

or in my case, I edited the default wpa* file (located in /usr/local/bin) to program my router/WIFI data, ran wifi.sh and used WinSCP to move the above image* files from windows10 to the emmc p1

Plugging the USB stick and adding auxillary power and pulling them out each time is a pain (for me atleast). Connectors and sockets could become loose, touching some pins inadvertently etc can cause ESD and brick the part (theoretically).

Reboot and off you go with the minized from the image.ub file in p1.

Thanks

Siva R