[SOLVED] Failed to handle fs_proto (file address in cmdline)

[jrobin28260]

Hi everybody,

The question seems to be simple but I have a problem : I have a DTB file that is mandatory to boot my ARM64 computer. And I fail at trying to tell him to use it !
On the ISO at side of the "vmLinuz" and "initrd.gz" file, i've placed the "msm8998-mtp.dtb" file.

grub.cfg interesting part :

Code: Select all

menuentry 'Linux 4.20 No ACPI build MSM8998 DTB' {
    set background_color=black
    linux    /install.a64/vmLinuz --- dtb=/install.a64/msm8998-mtp.dtb
    initrd   /install.a64/initrd.gz
}

When trying this, kernel tells me "Failed to handle fs_proto". I guess /install.a64/ is only visible from GRUB, but not from the Kernel.
Also, I think it's a CDROM Filesystem, because it's an ISO file I'm placing on the USB Key with dd. But I guess Linux know what a CD-ROM filesystem is !

I have to give this DTB file to the Kernel, if not it has no chance to boot. When it's saying "using DTB from configuration table" it's not going to work (somebody told me that the DTB inside the UEFI Configuration Tables is not complete enough on this device), I have to read "using DTB from command line" into the feedback.

I'm failing at that which is pretty sad and frustrating.
I get an error message saying "Failed to handle fs_proto" when I try to give the address of the file. It makes no differences if the adress is valid or invalid, which probably means I have to use a precise syntax in order to have Linux looking into the good device>file system, at the correct folder... But I don't know which syntax and searching on the Internet gives anything but that...

Thank you in advance !


EDIT : after a lot of frustrating searches telling me uninteresting things over hundreds of pages, I'm back to this page talking about "dtb=" command. https://www.kernel.org/doc/Documentation/efi-stub.txt but giving some clues some lines upper, into initrd explanations.
It seems that the syntax (at least for initrd) should be with backslashes and can only be relative to ESP root... However my DTB file is not into ESP root so I'll try to find a way to add it by moving / resizing partitions of the ISO (hoping that GRUB will still be able to find its files) in order to add my file on it. If not I will try to add fs0, fs1, fs2, or fs0:\, fs1:\, fs2:\... and hope that Linux would be able to understand what I'm talking about !

I'll keep you informed

[Head_on_a_Stick]

EFI_STUB booting requires that the kernel image & intramfs also be on the ESP.

I'm not familiar with arm64 but does this help:

https://superuser.com/questions/736500/ ... leboard-xm

[jrobin28260]

Thank you for this link, and tip about putting everything into the ESP

I'm completely stuck

Absolutely no dtc='xxxx' is able to successfully give a working DTB file address to the Kernel, I spent the entire afternoon on it

Putting the DTB at the end of the Image does nothings, since the Kernel, seeing that there is no "dtb=" command, load the DTB from Configuration Table.
The only way that seems to exist to tell the Kernel "do not use DTB from configuration table" is to give him a DTB file trough command line.

The created ISO has a very little ESP in FAT12 and putting the DTB file in it has no effect : Linux gives the same error, which is so fast that you have to record it with a camera in order to see it


dtb=\msm8998-mtp.dtb gives the error

dtb=fs0:\msm8998-mtp.dtb has no effect (same error)
dtb=fs1:\msm8998-mtp.dtb has no effect (same error)
dtb=fs2:\msm8998-mtp.dtb has no effect (same error)
dtb=fs3:\msm8998-mtp.dtb has no effect (same error)
dtb=fs4:\msm8998-mtp.dtb has no effect (same error)
dtb=fs5:\msm8998-mtp.dtb has no effect (same error)
dtb=fs6:\msm8998-mtp.dtb has no effect (same error)
dtb=fs7:\msm8998-mtp.dtb has no effect (same error)
dtb=fs8:\msm8998-mtp.dtb has no effect (same error)
dtb=fs9:\msm8998-mtp.dtb has no effect (same error)

dtb=fs0\msm8998-mtp.dtb has no effect (same error)
dtb=fs1\msm8998-mtp.dtb has no effect (same error)
dtb=fs2\msm8998-mtp.dtb has no effect (same error)
dtb=fs3\msm8998-mtp.dtb has no effect (same error)
dtb=fs4\msm8998-mtp.dtb has no effect (same error)
dtb=fs5\msm8998-mtp.dtb has no effect (same error)
dtb=fs6\msm8998-mtp.dtb has no effect (same error)
dtb=fs7\msm8998-mtp.dtb has no effect (same error)
dtb=fs8\msm8998-mtp.dtb has no effect (same error)
dtb=fs9\msm8998-mtp.dtb has no effect (same error)

and so on... I've tried to put the DTB file everywhere, even on others partitions, others devices with fat32 partitioning... the error message is always the same


Any modification to the installation disk partitions (in order to put more things into the ESP partition) will make the grub file into the ESP (bootaa64.efi) unable to find the second partition, falling into a rescue mode where "linux" and "initrd" commands doesn't even exist anymore.
grub-mkstandalone is giving a big bootaa64.efi file with every command available, that is unable to see any file around him.

I spent the entire afternoon trying to mark the address of a file... I feel very bad, this is one of the most frustrating day of my entire life !
And I'm not able to resize the ESP (in order to add big files in it) without having a GRUB that is unable to see my files.

[jrobin28260]

I'm reading the source code of the Linux kernel part that is giving those messages

This is where the error comes from

Code: Select all

static efi_status_t efi_open_volume(efi_system_table_t *sys_table_arg,
				    efi_loaded_image_t *image,
				    efi_file_handle_t **__fh)
{
	efi_file_io_interface_t *io;
	efi_file_handle_t *fh;
	efi_guid_t fs_proto = EFI_FILE_SYSTEM_GUID;
	efi_status_t status;
	void *handle = (void *)(unsigned long)efi_table_attr(efi_loaded_image,
							     device_handle,
							     image);

	status = efi_call_early(handle_protocol, handle,
				&fs_proto, (void **)&io);
	if (status != EFI_SUCCESS) {
		efi_printk(sys_table_arg, "Failed to handle fs_proto\n");
		return status;
	}

	status = efi_call_proto(efi_file_io_interface, open_volume, io, &fh);
	if (status != EFI_SUCCESS)
		efi_printk(sys_table_arg, "Failed to open volume\n");
	else
		*__fh = fh;

	return status;
}

If is called by handle_cmdline_files() if there is "initrd=" or "dtb=" into the command line.
It's failing at opening what is supposed to be "the" EFI Files System.
Is it the ESP ?
Or the entire ability to see the different files and partitions ?

-----------------------------------------------------------------------------
EDIT :
I think I can confirm that "964e5b22-6459-11d2-8e39-00a0c969723b" is simply the File System Protocol, inside UEFI.
Even if something is wrong with this computer, it is impossible that the UEFI firmware doesn't give the access to the files, so I guess there is something blocking it ?

May be the presence of Windows inside of it ? Or something wrong with the ISO (which is CDROM format) ?

I'm unable to put all the Debian installer's files into a standard GPT disk with a FAT32 formatted partition that grub would agree to work with, since the grub files I'm able to generate, are only focusing on finding a CDROM file system in a partition that shouldn't be touched... and I don't know how to do differently.

The function that fails is in arm64/include/asm/efi.h
#define efi_call_early(f, ...) sys_table_arg->boottime->f(__VA_ARGS__)

[jrobin28260]

Unfortunately, apart from embedding the blob inside the Kernel image (and making EFI-STUB using it instead of loading another one) the Kernel will have to read the filesystem to load this DTB file

I learned how to make a simple and clever bootaa64.efi grub file which would be able to see files around him, on his partition, before saying "blah blah error cannot found /boot/grub files..." even as the files he's looking for are just around him

./grub-mkimage -p /boot/grub -o bootaa64.efi -O arm64-efi part_gpt fat

It was unable to see anything before to add "part_gpt" then "fat" options in order to tell him to add those modules. If the partitioning is different (msdos, is9660) then those options should be added to the grub-mkimage command line.

Now I have 1 normal partition, into a GPT partitioned disk, with the partition formatted as FAT32, set as "EFI System Partition" type.

Also, I've completely erased the internal storage containing Windows 10 ! So everything that could have been conflicting is now out of there.

And the problem persists.

Does a "insmod something" or I don't know what mandatory in order to have the Kernel able to play with the filesystem ? That would explain the problem I'm encountering !
Edit : after adding
insmod gzio
insmod disk
insmod file
insmod fshelp
insmod iorw
insmod ehci
insmod usb

And having no changes, I guess there is a problem with the Kernel : it is unable to access the files. Grub is succeeding is reading those files so this is very unlikely to be an UEFI problem.
So my guess is that there is some Kernel build option somewhere that should be enabled or changed in order to change something !

[Head_on_a_Stick]

GRUB is not an EFI_STUB loader and does not require that all the files be on the ESP.

[jrobin28260]

Yes of course, GRUB is even able to work on a CD-ROM Filesystem
This was just to drive a test and try to discover how can Linux's EFI-STUB fail on storage access ability, because EFI-STUB has to read the DTB file (if not, it's loading a not working one).

I also copied (dd) the USB stick content to a SD card in order to have it inserted into then memory card port (no more USB stick, unless it's behind an USB controller ?), same problem.

In summary, I'm stuck : for passing a DTB file to the Kernel, because of EFI-STUB, the only single way that could be considered, is giving the address of the file DTB file with the "dtb=" parameter into Kernel command line.
And because of something (I don't know what exactly), Kernel EFI-STUB is not able to access the UEFI "fs_proto".

Giving the DTB with "devicetree" grub command does nothing : as soon as the Kernel is loaded, EFI-STUB replaces the device tree by "Using DTB from configuration table".
Appending the DTB at the end of the Kernel Image does nothing for the same reason.

I've tried to build the kernel by disabling EFI ability to load DTB :
Firmware Driver -> EFI (Extensible Firmware Interface) Support ---> [ ] Enable the DTB loader

I also tried to give the DTB file to grub with -D, --dtb=FILE embed FILE as a device tree (DTB) but again, EFI-STUB says "Using DTB from configuration table" and stops doing anything.

But it does nothing, it still says "Using DTB from configuration table". I don't know what I can do.

[jrobin28260]

Hi everybody,

Some news :
-> Using EFI Stub is easy : your Linux image file just has to be renamed "bootaa64.efi", placed into the ESP at /efi/boot/bootaa64.efi, and it will be loaded by the UEFI firmware of the computer. So I tried without GRUB !
-> Without GRUB, with an empty command line, "Generating empty DTB" appears. It means that finally, "Using DTB from configuration table" can be translated "GRUB provided the DTB".
-> As my computer just loads "bootaa64.efi" without parameters, it is possible to put a default command line before to build the kernel (CONFIG_CMDLINE), and it's usage can be forced by CONFIG_CMDLINE_FORCE=y
However, it has no chance to work ! there is a big mistake into the Linux source code, at arm-stub.c if enabled, CONFIG_CMDLINE will be used for calling "efi_parse_options" but the real (and possibly empty) line passed by the UEFI firmware will always be used in the following functions calls, so everything that you put inside CONFIG_CMDLINE will be ignored.

For having my workaround, I locally modified my copy of Linux source code before to build, by forcing the usage of "CONFIG_CMDLINE" where "cmdline_ptr" was used : handle_cmdline_files() for dtb=, handle_cmdline_files() for initrd=, and at allocate_new_fdt_and_exit_boot()

Then, I successfully had "Using DTB from command line" displayed on the screen. It confirms that MY (and only my) DTB file was found and used. If the file is missing and the address incorrect, it tells about the error.
By the way, It freezes the same way. I think my DTB is finally wrong !

By driving all those test and having others people point of view on it, I guess that finally, "Using DTB from configuration table" is indicating that GRUB correctly handle DTB, and is passing it to the Kernel. If not, the Kernel says "Generating empty DTB".

The error I had (Failed to handle fs_proto) is probably caused by the fact that GRUB is taking the filesystem and by doing so, it avoid linux EFI stub to take the filesystem too. It looks that "dtb=" and "initrd=" kernel options are designed to be used when you can't carry on GRUB, and those options aren't working if you're using GRUB.

The end !