PROCESSOR-SDK-AM335X: Dosfs/Fatboot partition

Hi Marc,

Which version of the Processor SDK Linux release do you use? What OS is on your host PC?

Can you please explain the procedure of creating your SD card?

Sorry, I forgot to disclose that I'm using openSUSE 15.3

I did do a bug report on openSUSE: https://bugzilla.opensuse.org/show_bug.cgi?id=1188401

 I use:

to create the sdcard (it  a part of a bash script)

Hi Marc,

The Processor SDK for AM335x is only validated on Ubuntu 18.04. After you have installed the SDK to the host PC, the bin/ folder has a script called create-sdcard.sh, which can be used to create the bootable SD card with the prebuilt images in the SDK. The script does SD card partitioning and copying files to the corresponding place in the SD card. Please try to use the create-sdcard.sh to create your SDcard.

This is not the answer I asked for (I build my images using an Ubuntu 18.04 docker container.)

I asked if the difference in fat partition(the attached working and not working fat partition in first post) will cause the am335x not to boot(U-BOOT is not loading, I'm not sure of the MLO)

You can recreate the issue by creating a sd-card using your tools/ scripts.

• Check if it boots. 
• Copy the content of the fat partition to a local drive
• use sudo dd of=/dev/sd*1 if=/home/hmw/tmp/fatNotWorking.img  (change the * to propped device name and note that the 1 points to the fat partition)
• copy back the original fat32 content to the sd-card
• check if it boots (this fails if I try)
• use sudo dd of=/dev/sd*1 if=/home/hmw/tmp/fatWorking.img   (change the * to propped device name and note that the 1 points to the fat partition)
• copy back the original fat32 content to the sd-card
• check if it boots (this works if I try)

So I investigated the problem and think that the bytes that changed in the fat32 partition(see first post) are causing the am335x not to boot. I like to know if what I think is true. Or that there is some other issue I am unaware of

The fat32 partition is made using the same commands. What points the tool that creates the fat partition that got updated (see bug report to openSUSE).

It probably is also true that if I change the host OS to Ubuntu 18.04 that the sd-card creation Wil "fix" this issue. But that is not what I asked.
 I only want to know if the differences in partition causes the am335x not to boot.

I also know that if I run "sd-card create(not listed in my sdk)" script on openSUSE 15.2,15.3 or tumbleweed the sd-card won't boot. Probably to fat partition differences. So I like to know if the differences in fat partition causes the am335x not to boot (the sd-card create script that I use is a derivate of something that was supplied with arago 2.X something)

I also know that if I alter my sdcard create script so that is using the image of a working fat partition, it also works. But again not the question I asked

I also can search what version of dosfstools that Ubuntu 18.04 uses and install that on my systems. But again not the question I asked (not sure if this works)

I also can roll back the installation version of dosfstools to 4.1-lp152.3.6 (see bug report openSUSE)that works. But again not the question i asked

Changing host OS to Ubuntu 18.04 is not a decision I can just make.

Yes, I know how to "Fix" it, but I like to know if the differences in the fat partition are causing the processor not to boot

Hi Marc,

I am afraid we won't be able to tell if the partition data difference in your two images is the cause of the not booting issue. It would involve in ROM code debugging along with the FAT partition specs. This is out of our support scope.

Ubuntu 18.04 is the only host Linux we support, it has dosfstools v4.1.

mkfs.fat 4.1 (2017-01-24)

Hi Bin Liu,

I like to suggest going this route, sins linked in the openSUSE bug report:

So there is a major difference in both images: "1 reserved".

And there is only a single change between these versions:
* St kvě 26 2021 Matej Cepl <mcepl@suse.com>
- Add fix-calculation.patch (gh#dosfstools/dosfstools#153, bsc#1172863)
  to work with different size of clusters.

(as far I know, this links to 404ead8adb76fcb3a3521c0c3f13ef39898c0818 commit in dosfstools)
That suggest that all future distros won't work. And will impact more than only my working environment ( ubuntu 20.04 and onwards includes a newer dosfstools version with this issue)

Hi Marc,

My personal computer uses Debian 11 which has mkfs.vfat version 4.2. I confirmed the SD card created with Debian 11 / mkfs.vfat 4.2 doesn't boot my AM335x GPEVM either. So as you observed, likely the new dosfstools breaks on AM335x.

Hi Marc,

The instructions in the link below solve the non-bootable issue for me.

https://github.com/dosfstools/dosfstools/issues/165#issuecomment-860912482