Why is EFI directory in caps?

Just my wild guess.

Maybe just for 100% sure to be safe.

As you already mentioned, msdosfs (aka FAT, especially for old FAT12 and FAT16) doesn't differentiate between upper and lower cases, and DOS basically (unless forcibly done by filers like fd and Norton commander) forcibly converts lower cases to upper cases for 8.3 finenames.

With this in mind, it is not assured that all (exactly all) implementation of FAT in the wild can sanely access to lower case directory names.
So making the common EFI directory on top of filesystem root directory in upper case is the safest.

In contrast with it, all directories under it is vendor/OS specific. So it is purely on the OS vendors/firmware vendors using lower cases or not.
Just avoiding same names when converted into upper cases only is mandatory.

Of course, as all combinations of EFI (such as EFi, Efi, efi, eFI,...) shoule be considered as exactly same file/directory names at least on root directory entries and should sanely boot whichever is used. (Crazy firmware vendors can implement their firmware to accept eFi only, though. But would be none.)
 
>>> ChatGPT o1 answers:


The reason the /EFI/ directory on the EFI System Partition (ESP) is in all capital letters is rooted in the UEFI (Unified Extensible Firmware Interface) specification and historical conventions of the FAT filesystem used on the ESP.

1. UEFI Specification Compliance:
  • UEFI Standard Requirements: The UEFI specification mandates that the ESP must contain an EFI directory (in uppercase) at the root level. This directory is where bootloaders and related applications are stored. Firmware implementations look for this directory during the boot process.
    Reference: UEFI Specification (Version 2.9, March 2021), Section 13.3.1 "EFI System Partition":
    "An ESP must contain an EFI directory at the root of the partition. The path to the boot file is \EFI\BOOT\BOOTX64.EFI for 64-bit x86 systems."
2. Filesystem Case Sensitivity and Conventions:
  • FAT Filesystem Characteristics: The ESP is typically formatted with a FAT variant (usually FAT32 for partitions larger than 512 MB). FAT filesystems are case-insensitive but case-preserving. This means while they do not differentiate between uppercase and lowercase for file operations, they preserve the case of filenames as they were originally created.
  • Historical Conventions: Historically, the FAT filesystem (used in DOS and early Windows systems) displayed filenames in uppercase. This convention has been carried forward in many systems and tools that interact with FAT filesystems, especially in contexts where firmware or low-level utilities are involved.
3. Compatibility Considerations:
  • Firmware Expectations: Some firmware implementations might strictly adhere to the UEFI specification and expect the EFI directory to be in uppercase. Using lowercase or mixed-case could potentially lead to boot failures on systems with such firmware.
  • Cross-Platform Consistency: Ensuring that the EFI directory is in uppercase improves compatibility across different operating systems and firmware implementations. It avoids issues when the ESP is accessed or modified by tools that might not handle case variations consistently.
4. msdosfs Behavior in FreeBSD:
  • Case Insensitivity: While msdosfs in FreeBSD is case-insensitive (you can access files regardless of their case), it preserves the case of filenames when creating or listing them. Therefore, directories and files created with uppercase letters will display as such.
  • Best Practices: Adhering to the expected case (uppercase EFI) aligns with best practices and avoids potential issues with tools or firmware that might not handle lowercase names appropriately.
In Summary:
  • The /EFI/ directory is in all caps to comply with the UEFI specification and to ensure maximum compatibility with firmware and tools that interact with the ESP.
  • While msdosfs doesn't differentiate between cases in terms of accessing files, preserving the uppercase naming convention is important for consistency and to prevent potential boot issues.
Recommendation:
  • Maintain Uppercase Naming: When working with the ESP, especially when creating or modifying the EFI directory or its contents, use uppercase letters to align with the UEFI specification and avoid compatibility issues.
Additional Resources:
  • UEFI Specification: For detailed information, you can refer to the official UEFI specification document available from the UEFI Forum.
  • FreeBSD Handbook: The FreeBSD Handbook provides information on filesystem support and best practices for managing filesystems in FreeBSD.


Is it a good answer? Is it even true or just a hallucination of the thing? I have no idea.
 
I wonder if a Windows dev involved with the first UEFI implementation (around XP) may know? They had to get the idea from somewhere or chose it for a reason, unless they copied from something else, which would have more digging :p
 
Short DOS/FAT file names are 8.3. Lowercase FAT file names use records for long names.
If I understand/recall correctly, IBM and Microsoft supported long file names differently.
IBM used "longname" extended attribute, which were stored in hidden special file on the root directory of FAT disks/partitions named EA_DATA.SF for all files in the FAT disk/partition on OS/2. (HPFS had EAs in mature.)
Microsoft used special directory entry just for long file name just before (after) the actual entry of the file on VFAT implementation.
Both generated 8.3 upper case filename automatically for the actual file.
 
On the ESP partition the /EFI/ directory is in all CAPS? WHY? msdosfs doesn't differentiate between them on file names and directories.

Inquiring minds want to know.
UEFI is a standard, FreeBSD intends/tries to adhere to it; firmware is rather fundamental. The standard (as referenced by VladiBG), mandates it says so,
(my emphasis):
An EFI system partition that is present on a hard disk must contain an EFI defined directory in the root directory. This directory is named EFI. All OS loaders and applications will be stored in subdirectories below EFI. Applications that are loaded by other applications or drivers are not required to be stored in any specific location in the EFI system partition. The choice of the subdirectory name is up to the vendor, but [...]

However, UEFI Specification Version 2.10 Errata A (August 2024) - 13.3 File System Format (my emphasis):
The file system supported by the Extensible Firmware Interface is based on the FAT file system. EFI defines a specific
version of FAT that is explicitly documented and testable. Conformance to the EFI specification and its associate
reference documents is the only definition of FAT that needs to be implemented to support EFI. To differentiate the
EFI file system from pure FAT, a new partition file system type has been defined.
EFI encompasses the use of FAT32 for a system partition, and FAT12 or FAT16 for removable media. The FAT32
system partition is identified by an OSType value other than that used to identify previous versions of FAT. This unique
partition type distinguishes an EFI defined file system from a normal FAT file system.
The file system supported by
EFI includes support for long file names.
The definition of the EFI file system will be maintained by specification and will not evolve over time to deal with
errata or variant interpretations in OS file system drivers or file system utilities. Future enhancements and compatibility
enhancements to FAT will not be automatically included in EFI file systems. The EFI file system is a target that is
fixed by the EFI specification, and other specifications explicitly referenced by the EFI specification.
For more information about the EFI file system and file image format, visit the web site from which this document
was obtained.

Reference: Unified Extensible Firmware Interface Forum - Specifications
 
Fat's long file names are summarised on wikipedia.
The Human68k does not generate uppercase filename, so if you gave a lowercase filename, the file could not be accessed from MS-DOS.
It would be accessible, unless Human68k allowed coexisting files such as A.txt and a.TxT in the same directory at the same time like in UFS and so on.
If I recall correctly, DOS simply masked bit 7as 0 (for "A" [0x41], is 0100001 in binary, while "a" [0x61] being 1100001 in binary) on comparing filenames.

At least some filers (at least FD, the original of shells/fd) allow renaming files into which includes lower cases. But if I recall correctly, it had fool-proof for rejecting renames like ABC.TXT into Abd.txt when ABD.TXT already existing in the same directory.
 
In DOS/Microsoft world, filenames are case insensitive. For that reason ABC.txt and Abc.TXT is the same file.
 
On the ESP partition the /EFI/ directory is in all CAPS
Is it ? Not on my systems. My EFI loader is located under the funny hierarchy /boot/efi/efi/boot/bootx64.efi. I didn't create that myself, so this is what the FreeBSD installer does by default.
 
In DOS/Microsoft world, filenames are case insensitive. For that reason ABC.txt and Abc.TXT is the same file.
Exactly. But it's because of the filesystem "driver" implementation.
Filesystem "data structure" does not matter.

Phishfry, the background is so complexed as such.
But would be chosen the safest one.
 
Is it ? Not on my systems. My EFI loader is located under the funny hierarchy /boot/efi/efi/boot/bootx64.efi. I didn't create that myself, so this is what the FreeBSD installer does by default.
It usually works, because directory names EFI and efi are not distinguished as different on FAT, as discussed above. And /boot/efi are mountpoint to mount ESP, on (usually) UFS or ZFS for FreeBSD.
 
Is it ? Not on my systems. My EFI loader is located under the funny hierarchy /boot/efi/efi/boot/bootx64.efi. I didn't create that myself, so this is what the FreeBSD installer does by default.
I have seen that directory structure before. I only occurs when there is an existing ESP.
It confuses the installer which searches for an ESP to add its entry to efivars. 0000,0007 or whatever disk shows as.

I am working with ARM64 alot so I find it odd that the directory is in all caps, /EFI/BOOT/bootaa64.efi, but the loader is not.....

Thanks for everyones answer. The answer does lay in the UEFI Specs. But with loader filename not in CAPs I had to ask.

Deep dive on efivars
 
But with loader filename not in CAPs I had to ask.
Would be just because:
  • The source file (/boot/loader.efi by default for EFI/freebsd/ in ESP) has its filename with lower case.
  • msdosfs on FreeBSD does not automatically convert filenames into upper case (CAPS).
  • FAT "data structure" itself can retain upper and lower case.
 
Is it ? Not on my systems. My EFI loader is located under the funny hierarchy /boot/efi/efi/boot/bootx64.efi. I didn't create that myself, so this is what the FreeBSD installer does by default.
Focussing on the capitalization and not on the curious dir structure quoted, then, by the looks of it, it seems that Phishfry has their dir structure installed according pre-2021-01-15 and bsduck post date this commit bootconfig - bsdinstall: create /efi/boot directory in ESP

Besides the UEFI spec, "all caps" is in line with:
  • uefi(8):
    Rich (BB code):
    DESCRIPTION
       [...]
           The UEFI	boot process proceeds as follows:
    	     1.	  UEFI firmware	runs at	power up and searches for an OS	loader
    		  in the EFI system partition.	The path to the	loader may  be
    		  set by an EFI	environment variable managed by	efibootmgr(8).
    		  If not set, an architecture-specific default is used.
    
    			Architecture	Default	Path
    			amd64		/EFI/BOOT/BOOTX64.EFI
    			arm			/EFI/BOOT/BOOTARM.EFI
    			arm64		/EFI/BOOT/BOOTAA64.EFI
    			i386		/EFI/BOOT/BOOTIA32.EFI
    			riscv		/EFI/BOOT/BOOTRISCV64.EFI
  • Bootable UEFI memory stick or Hard Disk - FreeBSD Wiki Unified Extensible Firmware Interface (UEFI):
    Rich (BB code):
    To test UEFI booting on a memory stick or a hard disk, create a GPT partition table 
    with a small EFI partition and the rest of the space dedicated to a FreeBSD UFS partition:
    
    gpart create -s gpt da0
    gpart add -t efi -s 40M da0
    gpart add -t freebsd-ufs da0
    newfs_msdos -F 32 -c 1 /dev/da0p1
    mount -t msdosfs /dev/da0p1 /mnt
    mkdir -p /mnt/EFI/BOOT
Without knowing all the intricate details, I'd be in favor of adhering to the UEFI spec. I'd like to hear what more knowledgable persons than me (like for example bsdimp) have to say about this though.
 
by the looks of it, it seems that Phishfry has their dir structure installed according pre-2021-01-15
It was directy taken from RockPro64 -CURRENT image. I am using that as my jumping off point.
14.1-RELEASE for ROCKPRO64 is the same.

Code:
~/Downloads # mdconfig FreeBSD-14.1-RELEASE-arm64-aarch64-ROCKPRO64.img
md0

~/Downloads # gpart show -p md0
=>      40  10485680    md0  GPT  (5.0G)
        40     32728         - free -  (16M)
     32768    102400  md0p1  efi  (50M)
    135168  10350464  md0p2  freebsd-ufs  (4.9G)
  10485632        88         - free -  (44K)

~/Downloads # mount -t msdosfs /dev/md0p1 /mnt

~/Downloads # ls /mnt
EFI    dtb

~/Downloads # ls /mnt/EFI/BOOT
bootaa64.efi
 
Even on Memstick installer which uses MBR.
Code:
~/Downloads # umount /mnt

~/Downloads # mdconfig FreeBSD-14.1-RELEASE-amd64-memstick.img
md0

~/Downloads # gpart show -p md0
=>      1  2734760    md0  MBR  (1.3G)
        1    66584  md0s1  efi  (33M)
    66585  2668176  md0s2  freebsd  [active]  (1.3G)

~/Downloads # mount -t msdosfs /dev/md0s1 /mnt

~/Downloads # ls /mnt
EFI

~/Downloads # ls /mnt/EFI
BOOT

~/Downloads # ls /mnt/EFI/BOOT
bootx64.efi

This is nothing I would want to bother a developer with. They have more important work.
It was just one of those things.
I have been messing with mounting Linux Arm64 ESP partition and rooting around there and noticed loader file in CAPS.
 
Also:

 
Back
Top