All of lore.kernel.org
 help / color / mirror / Atom feed
From: Heinrich Schuchardt <xypron.glpk@gmx.de>
To: u-boot@lists.denx.de
Subject: [U-Boot] [BUG] U-Boot hangs on fatload, commit ee88eacbdd840199a3dec707234579fb15ddd46a
Date: Sat, 9 Nov 2019 18:08:12 +0100	[thread overview]
Message-ID: <c550e448-36c1-73e9-8748-b972c4a062d5@gmx.de> (raw)
In-Reply-To: <CACwrec+J+mV5RDXczT7mssiRMzm5RWS9Qsu_dr70nhHb1qj_dA@mail.gmail.com>

On 11/9/19 4:11 PM, Gray Remlin wrote:
> On Fri, 8 Nov 2019 at 20:08, Heinrich Schuchardt <xypron.glpk@gmx.de
> <mailto:xypron.glpk@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.
>

  reply	other threads:[~2019-11-09 17:08 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <CACwrecKgrDAoSOrmWmEawFUbj_c1o2j0T=CitkR9+Cn-qAMfTg@mail.gmail.com>
2019-11-08 20:08 ` [U-Boot] [BUG] U-Boot hangs on fatload, commit ee88eacbdd840199a3dec707234579fb15ddd46a Heinrich Schuchardt
2019-11-09 15:11   ` Gray Remlin
2019-11-09 17:08     ` Heinrich Schuchardt [this message]
2019-11-09 17:45       ` Gray Remlin
2019-11-09 18:40       ` Heinrich Schuchardt
2019-11-09 19:42         ` Gray Remlin
2019-11-09 20:50           ` Heinrich Schuchardt
2019-11-09 21:31             ` Gray Remlin
2019-11-10  8:41               ` Heinrich Schuchardt
2019-11-11 17:14                 ` Gray Remlin
2019-11-12 19:50                   ` Heinrich Schuchardt
2019-11-12 22:55                     ` Gray Remlin
2019-11-13  7:07                       ` Heinrich Schuchardt
2019-11-16 10:11                         ` Heinrich Schuchardt
2019-11-17  7:50                           ` Stefan Roese
2019-11-17  9:42                             ` Heinrich Schuchardt
2019-11-18  7:18                             ` Chris Packham

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=c550e448-36c1-73e9-8748-b972c4a062d5@gmx.de \
    --to=xypron.glpk@gmx.de \
    --cc=u-boot@lists.denx.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.