On Mon, Oct 22, 2018 at 07:58:29AM +0100, Alexander Graf wrote:
On 22.10.18 06:37, AKASHI Takahiro wrote:
On Thu, Oct 18, 2018 at 10:46:36AM +0200, Alexander Graf wrote:
On 18.10.18 07:48, AKASHI Takahiro wrote:
On Wed, Oct 17, 2018 at 10:43:22AM +0200, Alexander Graf wrote:
On 17.10.18 09:32, AKASHI Takahiro wrote:
With this patch applied, we will be able to selectively execute an EFI application by specifying a load option, say "-1" for Boot0001, "-2" for Boot0002 and so on.
=> bootefi bootmgr -1 <fdt addr>
I don't think -1 is very good user experience :). How about => bootefi bootmgr Boot0001 <fdt addr>
It looks like u-boot's run command with six more characters! How about this:
=> bootefi bootmgr #1 <fdt addr>
So what is the problem with making it Boot0001? That way at least the variable name is consistent across the board ;).
More typing!
or allowing "-" as empty fdt,
=> bootefi bootmgr - 1
(Please notice that this is NOT "-1.") I also like this one as it maintains upward-compatibility: bootefi bootmgr [<fdt addr> [<boot id>]]
Otherwise, a new sub command?
=> bootefi run 1, or => efi(shell) run 1
Well, if you stick to "setenv -e"-like syntax, how about => run -e Boot0001
Given that "run" takes an environment variable, this syntax is perfectly fit to U-boot, isn't it?
Ooooh, that is an amazing suggestion! And "run -e" without an explicit target could just invoke efibootmgr directly, looping through the BootOrder.
We agree here :)
# Discussing UI is a fun or mess.
# I hope that this is not fruitless discussion.
Yeah :(. What we really need would be that "bootefi bootmgr" becomes "efiboot". But that would be even more confusing ;).
So I think that we should not add anything more to "bootefi bootmgr" to extend functionality.
So the whole rationale of why "bootefi" is the way it is today is that it's trying to lean on the existing "bootm", "booti", "bootz" etc syntax as much as it can. In other words, it's trying to fit into the U-Boot ecosystem much rather than the existing edk2 one.
IMO, "boot*" variants are already a mess.
I would like to keep following that path going forward. Whenever there is an option between "U-Boot like" and "edk2 like" I would always opt for the "U-Boot like" user experience, because if they want edk2 they may as well use edk2 ;).
Well, BootXXXX is quite UEFI-specific and people who are not familiar with UEFI need to consult UEFI specification anyway and this means, to me, that UEFI shell's similarity would be favorable. (See "setvar" syntax, not mine but UEFI shell's, which can be quite different and complicated.)
Well my thinking there is that if someone likes the UEFI Shell, they may as well just run it :).
My aim here is to provide poor man's uefi shell! For example, I think there are a few useful commands to be supported: * devices * devtree * dh * (dis)connect * drivers * memmap * unload They must be useful even now for debugging and understanding internal status of UEFI environment. # Please note that some of those commands in edk2's shell will still cause a panic.
That's is why I want to have efi(shell) command.
Thanks, -Takahiro Akashi
Alex
Does anybody else have any opinions?
Thanks, -Takahiro Akashi
Alex