On Sat, 9 Nov 2019 at 17:08, Heinrich Schuchardt <xypron.g...@gmx.de> wrote:
> On 11/9/19 4:11 PM, Gray Remlin wrote: > > On Fri, 8 Nov 2019 at 20:08, Heinrich Schuchardt <xypron.g...@gmx.de > > <mailto:xypron.g...@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. > > > > _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot