On 11/9/19 6:08 PM, Heinrich Schuchardt 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.

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

I just tested on an OrangePi PC with v2019.10 and got this:

=> fatload usb 0:1 $kernel_addr_r test.txt
efi_dp_split_file_path(/VenHw(e61d73b9-a384-4acc-aeab-82e828f3628b)/UsbClass(0x0,0x0,0x9,0x0,0x1)/UsbClass(0x781,0x5571,0x0,0x0,0x0)/HD(1,MBR,0xfae8c6af,0x800,0x3b9f800)/test.txt)
device path =
/VenHw(e61d73b9-a384-4acc-aeab-82e828f3628b)/UsbClass(0x0,0x0,0x9,0x0,0x1)/UsbClass(0x781,0x5571,0x0,0x0,0x0)/HD(1,MBR,0xfae8c6af,0x800,0x3b9f800)
file path = /test.txt
12 bytes read in 26 ms (0 Bytes/s)
=> md.b $kernel_addr_r 0c
42000000: 4a 75 73 74 20 61 20 74 65 73 74 0a  Just a test.

So debugging on your specific device is needed.

> x_bootcmd_kernel=fatload usb 0 0x6400000 uImage
You do not specify a partition number. Do you have a partition table?
Than the partition defaults to 1. Or does the file system sit directly
on the device?

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

Reply via email to