[U-Boot] [BUG] U-Boot hangs on fatload, commit ee88eacbdd840199a3dec707234579fb15ddd46a

[Heinrich Schuchardt]

On 11/9/19 4:11 PM, Gray Remlin wrote:
> On Fri, 8 Nov 2019 at 20:08, Heinrich Schuchardt <xypron.glpk at gmx.de
> <mailto:xypron.glpk at gmx.de>> wrote:
>
>     On 11/8/19 7:32 PM, Gray Remlin wrote:
>      > Please excuse the noise. I would like to file a bug report
>     against the
>      > above commit, a quick search of www.denx.de <http://www.denx.de>
>     <http://www.denx.de> did not
>      > reveal how I should proceed. Please point me in the right direction.
>      >
>      >
>      > Issue:
>      > U-Boot hangs (i.e. during boot) whenever the command 'fatload' is
>     used.
>      >
>      > Details:
>      > U-Boot 2019.10 compiled with either dreamplug_defconfig or
>      > guruplug_defconfig.
>      >
>      > After the commit do_load() now additionally calls efi_set_bootdev()
>      > which was moved out of do_load_wrapper() which is only called by the
>      > 'load' command.
>      >
>      > Reverting the commit fixes this issue for me.
>      >
>
>     Dear Gray,
>
>     thanks for reporting the issue with commit
>     fs: do_load: pass device path for efi payload
>     ee88eacbdd840199a3dec707234579fb15ddd46a
>
>     Is it only the fatload command that fails on your device or also the
>     load command?
>
>     There is no bug tracker for U-Boot. So sending a mail to the U-Boot
>     mailing list, the patch author, and the maintainer is the best way to
>     inform the developers about bugs.
>
>     Best regards
>
>     Heinrich
>
>
> Additional information:
> cross-compiler gcc-linaro-7.4.1-2019.02-x86_64_arm-linux-gnueabi
>
> The U-Boot environment being used is the default obtained by
> compiling U-Boot 2020.01-rc1-00100-gee93ef0c4b as dreamplug_defconfig
>
> => printenv
> baudrate=115200
> bootcmd=setenv ethact egiga0; ${x_bootcmd_ethernet}; setenv ethact
> egiga1; ${x_bootcmd_ethernet}; ${x_bootcmd_usb}; ${x_bootcmd_kernel};
> setenv bootargs ${x_bootargs} ${x_bootargs_root}; bootm 0x6400000;
> bootdelay=3
> ethact=egiga0
> fdtcontroladdr=1fb8e7c8
> stderr=serial
> stdin=serial
> stdout=serial
> x_bootargs=console=ttyS0,115200
> x_bootargs_root=root=/dev/sda2 rootdelay=10
> x_bootcmd_ethernet=ping 192.168.2.1
> x_bootcmd_kernel=fatload usb 0 0x6400000 uImage
> x_bootcmd_usb=usb start
>
> U-Boot hangs for other syntactically correct invocations of either
> 'fatload' or 'load'
> Other commands such as 'fatls' function as expected.
>
> Program flow is as follows:
>
> command 'fatload' (or 'load')
>          efi_set_bootdev()
>                  ...
>                  efi_dp_split_file_path()
>                          ...
>                          efi_dp_dup()
>                                  ....
>                                  efi_dp_size()
>                                  *while exit condition never met*
>                                          *infinite loop*
>
>
> This is not an attempted EFI boot, why is EFI code being invoked ?

Thanks for debugging.

When booting from EFI we need to know from which device the EFI binary
was loaded. We use this information to install the loaded image
protocol. At the time of the load command we do no know if you will
invoke bootz or bootefi.

It might be that we have a problem with creating device paths for USB. I
will try to reproduce this.

You could add

printf("efi_dp_split_file_path(%pD)\n", full_path);

at the beginning of efi_dp_split_file_path() to identify what device
path is passed to the function. This should produce an output like

=> load scsi 0:2 $kernel_addr_r description.txt
efi_dp_split_file_path(/VenHw(e61d73b9-a384-4acc-aeab-82e828f3628b)/Scsi(0,0)/HD(2,MBR,0x6fe3a999,0x400,0x400)/description.txt)

Best regards

Heinrich

> Whilst the proposition 'EFI boot = FAT filesystem' is True
> the converse 'FAT filesystem = EFI boot' is Not True
>
> I am willing to help, but that may require some EFI hand-holding.
> Gray
>
> PS. If anyone knows how to set '>' on reply content in GMail, please
> email me off list.
>