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

[Gray Remlin]

On Sat, 9 Nov 2019 at 17:08, Heinrich Schuchardt <xypron.glpk at gmx.de> wrote:

> 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.
>

Wasn't that the reason for the load wrapper ?

'load' for bootefi
and
'fatload' for 'bootz' | 'bootm'


>
> 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)
>
>
efi_dp_split_file_path(/VenHw(e61d73b9-a384-4acc-aeab-82e828f3628b)/UsbClass(0x0,0x0,0x9,0x0,0x1)/UsbClass(0x1a40,0x101,0x9,0x0,0x1)/UsbClass(0x5e3,0x726,0x0,0x0,0x0)/HD(1,MBR,0x000f2899,0x800,0x1f800)/uImage/UNKNOWN(0000,0000)/UNKNOWN(0000,0000)/UNKNOWN(0000,0000)/UNKNOWN(0000,0000)/UNKNOWN(0000,0000)/UNKNOWN(0000,0000)/UNKNOWN(0000,0000)/UNKNOWN(0000,0000)/UNKNOWN(0000,0000)/UNKNOWN(0000,0000)/UNKNOWN(0000,0000)/UNKNOWN(0000,0000)/UNKNOWN(0000,0000)/UNKNOWN(0000,0000)/UNKNOWN(0000,0000)/UNKNOWN(0000,0000)/UNKNOWN(0000,0000)/UNKNOWN(0000,0000))


> 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.
> >
>
>