cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
danwaqar
Visitor
Visitor
1,384 Views
Registered: ‎01-07-2020

Boot time difference

I am using ultrascale + and running bare metal, booting from emmc

i have seen two scenario's

1. booting time (15 secs) is shorter when the emmc has only 1 partition

2. booting takes longer (30 secs) if there are multiple partitions on the emmc, however the three boot files are still present only in 1 i.e. first partition

 

Can you shed some light on why this happens

0 Kudos
10 Replies
denist
Xilinx Employee
Xilinx Employee
1,313 Views
Registered: ‎10-11-2011

We know formatting of the eMMC can impact the FSBL performance during read.

How are you formatting the eMMC?

Please provide flow and command lines.

-------------------------------------------------------------------------
Don’t forget to reply, kudo, and accept as solution.
-------------------------------------------------------------------------
0 Kudos
danwaqar
Visitor
Visitor
1,301 Views
Registered: ‎01-07-2020

While trying to create multiple partitions I am encountering a problem.

I am able to use f_fdisk and f_mkfs to make multiple partitions.

But when I try to create files in the any partition other than the first partition I ran in to trouble. Error stating no work area present.

I have enabled the multiple partition flag in the BSP.

 

 Code below

PARTITION VolToPart[FF_VOLUMES] = {
    {0, 1},     /* "0:" ==> 1st partition on physical drive 0 */
    {0, 2},     /* "1:" ==> 2nd partition on physical drive 0 */
    {0, 3},     /* "2:" ==> 3rd partition on physical drive 0 */
    {0, 4}      /* "3:" ==> 4th partition on physical drive 0  */
};

 

FATFS fs;

FRESULT 

BYTE work[512];
DWORD plist[] = {50, 50,0};
f_fdisk(0, plist, work);
res = f_mkfs("0:", FM_EXFAT,0, work, sizeof work);
res = f_mkfs("1:", FM_EXFAT,0, work, sizeof work);

 

 

 

 

 

 

0 Kudos
abhinayp
Xilinx Employee
Xilinx Employee
1,018 Views
Registered: ‎07-12-2018

There was an issue in the partitioning tool at the @danwaqar 's end and he managed to fix the issue.

@danwaqar , could you please add your steps how you fixed it, which would help others?

Best Regards
Abhinay PS
------------------------------------------------------------------------------------------------------------------------------
Kindly note- Please mark the Answer as "Accept as solution" if information provided is helpful.
Give kudos to a post which you think is helpful and reply oriented.
-------------------------------------------------------------------------------------------------------------------------------

0 Kudos
989 Views
Registered: ‎08-29-2019

The details of the partitioning tool problem :

"

The difference is that, there is defined low level partitioning / formatting in the BSP which puts the MBR at the 64 sector of the eMMC. Whereas these tools put the MBR information at a much later sector (Number most probably in 1000s). This results in bootloader taking more time to read from the starting sectors to reach the MBR sector in case of OS (Windows) formatted eMMC and then reading the FAT and ultimately accessing the boot file.

"

Hopefully this assists anyone else that encounters a similar problem in the future with longer than expected boot times and I expect the fix is to ensure the MBR is located at the correct location in memory.

studded_seance
Visitor
Visitor
528 Views
Registered: ‎05-21-2021

Hi, I am experiencing a similar problem. I am booting from eMMC. Although I have managed to get short boot times in the past, currently it takes over 30 seconds (!) to reach the FSBL banner. I am confused about your explanation of the partitioning problem.

> The difference is that, there is defined low level partitioning / formatting in the BSP which puts the MBR at the 64 sector of the eMMC.

As I understand it, the MBR can only be placed at sector 0. There is no way for the MBR to be located at sector 64. I assume you are referring to the first sector of the first partition, which is a FAT filesystem.

However, I have noticed no difference in boot time when moving the offset of the first partition. I have tried sectors 1, 2, 16, 32, 64, and 2048.

> the fix is to ensure the MBR is located at the correct location in memory.

So this is a ram problem, and not a storage problem?

0 Kudos
danwaqar
Visitor
Visitor
524 Views
Registered: ‎01-07-2020

You problem looks different becaus there is a defined boardinit project that is used to do BSP allowed formatting and partitioning that does put mbr at 0. But the fatfile info was put at 64

but when i used windows based formatting tools that took the fatfile starting sectors to a high number sector value such as 1.5MB size sectors later causing delay in boot time as it searches for boot code and finds it very a sector very later in the memory

0 Kudos
studded_seance
Visitor
Visitor
444 Views
Registered: ‎05-21-2021

Ok, I am still not sure what you think the problem is. I believe this is because we are not specific enough with our terminology. I will try and document my current setup, pointing out the particular terms for different offsets.

Below is the (abbreviated) output of fdisk. This reflects the content of the MBR which resides at physical sector 0.

Device     Boot  Start       End   Sectors  Size Id Type
/dev/sdi1           64    131071    131008   64M  c W95 FAT32 (LBA)
/dev/sdi2       131072 124190719 124059648 59.2G 83 Linux

The first partition holds the FAT32 filesystem. It begins at sector 64.

Next, here is the (abbreviated) output of fatcat for the first partition. This reflects the contents of the reserved sectors, particularly the boot sector, which is the first sector of the partition (physical sector 64).

Filesystem type: FAT32   
OEM name: mkfs.fat
Total sectors: 131008
Total data clusters: 129024
Data size: 66060288 (63M)
Disk size: 67076096 (63.9688M)
Bytes per sector: 512
Sectors per cluster: 1
Bytes per cluster: 512
Reserved sectors: 32
Sectors per FAT: 1008
Fat size: 516096 (504K)
FAT1 start address: 0000000000004000
FAT2 start address: 0000000000082000
Data start address: 0000000000100000
Root directory cluster: 2
Disk label: boot       

From here, we can see that there are 32 reserved sectors before the first FAT (FAT1 at 0x4000, or 512*32). Therefore the first FAT begins at sector 32, or physical sector 96. Because of the FAT size, the data does not start until address 0x100000, or sector 2048 (physical sector 2112).

Let's examine the physical location of BOOT.BIN. Below is the output of fatcat for the directory entry for BOOT.BIN

Searching entry for /BOOT.BIN
Entry address 0000000000100020
Attributes 20
Found entry, cluster=3, file with size=9074160 (8.65379M) 

This shows that the directory entry is stored in the root directory which always occupies the first data sector. The information for cluster 3 (which stores the actual data for BOOT.BIN) is

Cluster 3 address:
1049088 (0000000000100200)
Next cluster:
FAT1: 4 (00000004)
FAT2: 4 (00000004)
Chain size: 17723 (9074176 / 8.65381M)
Chain is contiguous

Here, we can see that cluster 3 begins at address 0x100200, which is sector 2049 (physical sector 2113).

 

So there are several different structures which the boot rom must read in order to load the FSBL. They are

  • The MBR at sector 0
  • The boot sector at sector 64
  • The FAT at sector 96
  • The root directory at sector 2112
  • The BOOT.BIN file itself at sector 2113

What, then, should I try moving around?

0 Kudos
studded_seance
Visitor
Visitor
405 Views
Registered: ‎05-21-2021

Ok, I tried reformatting using FAT16, with the following offsets:

  • The MBR at sector 0
  • The boot sector at sector 64
  • The FAT at sector 68
  • The root directory at sector 348
  • The BOOT.BIN file itself at sector 360

Unfortunately, this has had no affect on boot times.

0 Kudos
danwaqar
Visitor
Visitor
391 Views
Registered: ‎01-07-2020

I just gave another look into my image files that were loaded last year into the eMMC.

The Root Directory was at sector 26642 and BOOT.bin at sector 26688

Then i modified their locations to 

The Root Directory at sector 3840 and BOOT.bin at sector 3904

 

This solved the problem for me and the boot times were greatly improved. Apart from that i didn't do anything specific causing this to improve. I can see you already did that somehow but this didn't improve it for you.

Did you tried switching hardware?

0 Kudos
studded_seance
Visitor
Visitor
340 Views
Registered: ‎05-21-2021

> Did you tried switching hardware?

Yes. The problem seems tied to the image in some way.

I also noticed that times improved for warm boots. That is, after a cold reboot, it took around 35s to see the FSBL banner. However, after booting into Linux, subsequent reboots took only 20s to print the banner.

0 Kudos