Re: [U-Boot] [PATCH] efi_loader: initialise partition_signature memory
On Tue, Nov 21, 2017 at 7:24 AM, Jonathan Gray wrote: > Zero partition_signature in the efi_device_path_hard_drive_path > structure when signature_type is zero. > > This is required so that efi_dp_match() will work as expected > when doing memcmp() comparisons. > > Corrects a problem where the loaded image protocol would not return a > device path with MEDIA_DEVICE causing the OpenBSD bootloader to fail > on rpi_3 and other targets. > > Signed-off-by: Jonathan Gray Reviewed-by: Rob Clark > --- > lib/efi_loader/efi_device_path.c | 3 +++ > 1 file changed, 3 insertions(+) > > diff --git a/lib/efi_loader/efi_device_path.c > b/lib/efi_loader/efi_device_path.c > index f6e368e029..8045532a29 100644 > --- a/lib/efi_loader/efi_device_path.c > +++ b/lib/efi_loader/efi_device_path.c > @@ -431,6 +431,9 @@ static void *dp_part_fill(void *buf, struct blk_desc > *desc, int part) > if (hddp->signature_type != 0) > memcpy(hddp->partition_signature, &desc->guid_sig, >sizeof(hddp->partition_signature)); > + else > + memset(hddp->partition_signature, 0, > + sizeof(hddp->partition_signature)); > > buf = &hddp[1]; > } > -- > 2.15.0 > ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH] efi_loader: add missing breaks
Otherwise with GUID partition types you would end up with things like: .../HD(Part0,Sig6252c819-4624-4995-8d16-abc9cd5d4130)/HD(Part0,MBRType=02,SigType=02) Signed-off-by: Rob Clark --- Reported by 'ykaukab' on IRC. Not sure if someone already sent a similar patch. lib/efi_loader/efi_device_path_to_text.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/lib/efi_loader/efi_device_path_to_text.c b/lib/efi_loader/efi_device_path_to_text.c index 62771338f0..3b703301ff 100644 --- a/lib/efi_loader/efi_device_path_to_text.c +++ b/lib/efi_loader/efi_device_path_to_text.c @@ -135,10 +135,12 @@ static char *dp_media(char *s, struct efi_device_path *dp) case SIG_TYPE_GUID: s += sprintf(s, "/HD(Part%d,Sig%pUl)", hddp->partition_number, sig); + break; default: s += sprintf(s, "/HD(Part%d,MBRType=%02x,SigType=%02x)", hddp->partition_number, hddp->partmap_type, hddp->signature_type); + break; } break; -- 2.13.6 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2 01/18] efi_loader: efi_bootmgr: do not make hidden assignments
On Fri, Nov 17, 2017 at 12:46 PM, Heinrich Schuchardt
wrote:
> On 11/17/2017 03:04 PM, Rob Clark wrote:
>>
>> On Sun, Nov 12, 2017 at 9:02 AM, Heinrich Schuchardt
>> wrote:
>>>
>>> Assignments should not be made in the middle of nowhere.
>>>
>>> Signed-off-by: Heinrich Schuchardt
>>> ---
>>> v2
>>> Call efi_dp_str in debug mode only.
>>> ---
>>> lib/efi_loader/efi_bootmgr.c | 6 --
>>> 1 file changed, 4 insertions(+), 2 deletions(-)
>>>
>>> diff --git a/lib/efi_loader/efi_bootmgr.c b/lib/efi_loader/efi_bootmgr.c
>>> index 857d88a879..a55f210f0b 100644
>>> --- a/lib/efi_loader/efi_bootmgr.c
>>> +++ b/lib/efi_loader/efi_bootmgr.c
>>> @@ -120,11 +120,13 @@ static void *try_load_entry(uint16_t n, struct
>>> efi_device_path **device_path,
>>>
>>> if (lo.attributes & LOAD_OPTION_ACTIVE) {
>>> efi_status_t ret;
>>> - u16 *str = NULL;
>>> +#ifdef _DEBUG
>>> + u16 *str = efi_dp_str(lo.file_path);
>>>
>>> debug("%s: trying to load \"%ls\" from: %ls\n",
>>> __func__,
>>> - lo.label, (str = efi_dp_str(lo.file_path)));
>>> + lo.label, str);
>>> efi_free_pool(str);
>>> +#endif /* _DEBUG */
>>
>>
>> I was trying to avoid the #ifdef DEBUG in the first place.. ;-)
>>
>> btw, don't have the code in front of me atm, but I thought _DEBUG was
>> unconditionally defined to either 0 or 1.. so maybe you mean '#if
>> _DEBUG' or '#ifdef DEBUG' (no underscore)?
>
>
> Thanks for catching this
>
> I will change this to
> #if _DEBUG
>
> I often found the necessity to change the value of _DEBUG multiple times
> within a single C file to get only the relevant debug messages. This is why
> I prefer checking _DEBUG.
>
>>
>> btw2, possibly a better/cleaner option is add printf support for
>> format modifier to print device-paths?
>
>
> This is the only place where efi_dp_str is called.
>
I have had locally other callers while debugging things.. maybe I
should have left some of those in the code (and maybe I would have if
printf() supported it :-P)
Device-paths are fairly heavily used in UEFI.. so it tends to be
something you end up wanting to print in various places when
debugging.
BR,
-R
> Regards
>
> Heinrich
>
>
>>
>> BR,
>> -R
>>
>>>
>>> ret = efi_load_image_from_path(lo.file_path, &image);
>>>
>>> --
>>> 2.15.0
>>>
>>
>
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2 01/18] efi_loader: efi_bootmgr: do not make hidden assignments
On Sun, Nov 12, 2017 at 9:02 AM, Heinrich Schuchardt wrote:
> Assignments should not be made in the middle of nowhere.
>
> Signed-off-by: Heinrich Schuchardt
> ---
> v2
> Call efi_dp_str in debug mode only.
> ---
> lib/efi_loader/efi_bootmgr.c | 6 --
> 1 file changed, 4 insertions(+), 2 deletions(-)
>
> diff --git a/lib/efi_loader/efi_bootmgr.c b/lib/efi_loader/efi_bootmgr.c
> index 857d88a879..a55f210f0b 100644
> --- a/lib/efi_loader/efi_bootmgr.c
> +++ b/lib/efi_loader/efi_bootmgr.c
> @@ -120,11 +120,13 @@ static void *try_load_entry(uint16_t n, struct
> efi_device_path **device_path,
>
> if (lo.attributes & LOAD_OPTION_ACTIVE) {
> efi_status_t ret;
> - u16 *str = NULL;
> +#ifdef _DEBUG
> + u16 *str = efi_dp_str(lo.file_path);
>
> debug("%s: trying to load \"%ls\" from: %ls\n", __func__,
> - lo.label, (str = efi_dp_str(lo.file_path)));
> + lo.label, str);
> efi_free_pool(str);
> +#endif /* _DEBUG */
I was trying to avoid the #ifdef DEBUG in the first place.. ;-)
btw, don't have the code in front of me atm, but I thought _DEBUG was
unconditionally defined to either 0 or 1.. so maybe you mean '#if
_DEBUG' or '#ifdef DEBUG' (no underscore)?
btw2, possibly a better/cleaner option is add printf support for
format modifier to print device-paths?
BR,
-R
>
> ret = efi_load_image_from_path(lo.file_path, &image);
>
> --
> 2.15.0
>
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [RFC] efi_loader: frame buffers in EFI GOP and DM_VIDEO
On Wed, Oct 25, 2017 at 3:45 PM, Heinrich Schuchardt wrote: > Hello Alex, hello Simon, > > I have just been reading through efi_gop and video_uclass.c and there seems > to be something missing in the support of video modes. > > U-Boot configuration knows the following color models: > > 16-color > 256-color > 32k (1:5:5:5) > 64k (5:6:5) > 16.8M (8:8:8) > > In lib/efi_loader/efi_gop.c I only found > > VIDEO_BPP32 > VIDEO_BPP16 > Patch a812241091ce efi_loader: Add DM_VIDEO support (Alexander Graf) > > Shouldn't gop_blt differentiate between 32k and 64k color mode? > Unfortunately video_uclass.c cannot tell the difference! > What about 4 and 8 bit modes? > > When I look at the coding in video_uclass.c, function video_clear it seems > that this only correctly supports 32bit and 8bit mode. > Patch 1acafc73bfc7 dm: video: Add a video uclass (Simon Glass) > > Shouldn't 4, 15 and 16 bit modes be added here? > (apologies for being a bit behind on u-boot mails but been busy on other upstreams) iirc UEFI only supports a subset of what u-boot supports (and I think it is worse because u-boot doesn't do a good job of differentiating between different component orders of a given bpp).. but we could support more hw by not with the path that doesn't expose the scanout buffer address and only supports blitting to scanout buffer (and doing conversion as part of the blit). I think it is mostly a matter of someone who has this hw writing and testing the appropriate blit paths.. BR, -R ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] efi_loader: Disable env_save() call on boot
On Thu, Oct 19, 2017 at 5:23 PM, Alexander Graf wrote:
> With the introduction of EFI variable support, we also wanted to persist
> these EFI variables. However, the way it was implemented we ended up
> persisting all U-Boot environment variables on every EFI boot.
>
> That could potentially lead to unexpected side effects because variables
> that were not supposed to be written to persisted env get written. It also
> means we may end up writing the environment more often than we should.
>
> For this release, let's just disable EFI variable persistence and instead
> implement it properly for the next one.
>
Acked-by: Rob Clark
> Reported-by: Heinrich Schuchardt
> Fixes: ad644e7c182 ("efi_loader: efi variable support")
> Signed-off-by: Alexander Graf
> ---
> lib/efi_loader/efi_boottime.c | 5 +
> 1 file changed, 1 insertion(+), 4 deletions(-)
>
> diff --git a/lib/efi_loader/efi_boottime.c b/lib/efi_loader/efi_boottime.c
> index f627340de4..743b84864f 100644
> --- a/lib/efi_loader/efi_boottime.c
> +++ b/lib/efi_loader/efi_boottime.c
> @@ -1439,10 +1439,7 @@ static efi_status_t EFIAPI efi_exit_boot_services(void
> *image_handle,
> /* Make sure that notification functions are not called anymore */
> efi_tpl = TPL_HIGH_LEVEL;
>
> -#if defined(CONFIG_CMD_SAVEENV) && !defined(CONFIG_ENV_IS_NOWHERE)
> - /* save any EFI variables that have been written: */
> - env_save();
> -#endif
> + /* XXX Should persist EFI variables here */
>
> board_quiesce_devices();
>
> --
> 2.12.3
>
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 3/3] efi_loader: Do not enable it by default for sunxi
On Thu, Oct 19, 2017 at 7:43 AM, Maxime Ripard wrote: > On Thu, Oct 19, 2017 at 10:12:36AM +0100, Peter Robinson wrote: >> On Thu, Oct 19, 2017 at 10:06 AM, Peter Robinson >> wrote: >> > On Thu, Oct 19, 2017 at 10:01 AM, Maxime Ripard >> > wrote: >> >> On Thu, Oct 19, 2017 at 09:43:20AM +0100, Peter Robinson wrote: >> >>> On Thu, Oct 19, 2017 at 9:26 AM, Maxime Ripard >> >>> wrote: >> >>> > The EFI loader support takes around 31kB on an ARMv7 board, which >> >>> > makes us >> >>> > trip across the size limit we've had on the U-Boot binary. >> >>> > >> >>> > Since it's not an essential feature, disable it by default for >> >>> > ARCH_SUNXI >> >>> > so that we get back some extra room for user customisations. >> >>> >> >>> Does this disable it on aarch64 boards by default such as the Pine64? >> >>> If so NAK as Fedora, SUSE and I'm pretty sure Debian all use EFI to >> >>> boot aarch64 devices and this would regress this for all those >> >>> distros. >> >> >> >> This is something that Fedora, Suse and I'm pretty sure Debian can add >> >> to their defconfig. These are just default configuration, not >> >> one-size-fits-all configuration. >> > >> > So you're making at least three groups of users do more work? It could >> > also be argued that those that need the smaller space could disable it >> > if they don't need it in their configuration. >> >> Ultimately the problem with the argument about disabling it by default >> and distros can enable it if they want to is a false one. > > If it's a false one, then I guess Red Hat doesn't have any kind of > custom defconfigs for Fedora or RHEL for the kernel? kernel is part of the distro, "firmware" (ie. u-boot or whatever implements UEFI) should not be.. so this argument is a bit of a red herring. Maybe the solution is a "distro.config" option to separate options that make sense for distro/EBBR from what people who are doing more non-standard boot-chains are wanting. For example, for UEFI boot, we can disable all the filesystems other than FAT if you need to trim some space. And maybe doing a more simplified (ie. add it to efi_bootmgr.c) alternative to distro bootcmd could save a bunch of .text space. In fact we don't really need the scripting env at all. Probably there are other options for things to disable that I haven't thought of if you *really* needed to trim down. BR, -R >> By enabling it by default we have devices that ship with SPI or NAND >> flash, like a bunch of the OrangePis do now, be able to work with >> all distributions out of the box without any requirements of distros >> to produce a firmware (something I'd really prefer to leave to the >> device makers) to boot a number of Linux OSes OOTB. > > That one is the false argument in the discussion. No vendor is > providing such a U-Boot, all of them provide a vendor one that will > not even be able to boot a mainline kernel, let alone supporting > EFI. So having something that works out of the box is just a pipe > dream. > >> I think this is a good thing for the entire ecosystem. I don't want >> to regress that, I'd sooner get the size checks in place and then >> review rather than what seems like a "quick win" > > I've added a size check. 3 boards are broken: > - A20-OLinuXino-Lime2-eMMC > - A20-OLinuXino-Lime2 > - Cubietruck > > What now? > Maxime > > -- > Maxime Ripard, Free Electrons > Embedded Linux and Kernel engineering > http://free-electrons.com > > ___ > U-Boot mailing list > U-Boot@lists.denx.de > https://lists.denx.de/listinfo/u-boot > ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] Unexpected saving of all environment variables during EFI boot
On Thu, Oct 19, 2017 at 5:05 PM, Alexander Graf wrote:
>
>
> On 19.10.17 22:40, Heinrich Schuchardt wrote:
>> This was merged as
>> ad644e7c18238026fecc647f62584d87d2c5b0a3
>> efi_loader: efi variable support
>>
>>> diff --git a/lib/efi_loader/efi_boottime.c b/lib/efi_loader/efi_boottime.c
>>> index ec40f41bcb..c406ff82ff 100644
>>> --- a/lib/efi_loader/efi_boottime.c
>>> +++ b/lib/efi_loader/efi_boottime.c
>>> @@ -8,6 +8,7 @@
>>>
>>> #include
>>> #include
>>> +#include
>>> #include
>>> #include
>>> #include
>>> @@ -942,6 +943,11 @@ static efi_status_t EFIAPI efi_exit_boot_services(void
>>> *image_handle,
>>> {
>>> EFI_ENTRY("%p, %ld", image_handle, map_key);
>>>
>>> +#if defined(CONFIG_CMD_SAVEENV) && !defined(CONFIG_ENV_IS_NOWHERE)
>>> +/* save any EFI variables that have been written: */
>>> +env_save();
>>
>> You save all changed variables and not specifically those bound to EFI.
>> This is completely unexpected behavior for the user and not covered by
>> the commit message.
>>
>> Furthermore you call env_save even if no EFI variable has been touched
>> at all.
>>
>> This leads to writing to flash on every boot via EFI. Depending on
>> technology this might ruin the flash after a few hundred reboots.
>
> I agree that overwriting flash on every boot isn't a terribly smart idea.
>
> Also saving random environment variables that are set while we are in a
> distro loop to persistent storage isn't great either.
>
> I agree that we should probably improve this code to only save efi
> variables.
>
> Rob, how bad would it be for Fedora if we remove the persistent variable
> store call (just the env_save() line) for 2017.11 to not kill people's
> storage devices? Then for the next version tackle it for real and only
> save efi variable changes here and only if anything really did change.
>
As I mentioned on #u-boot, I think we can just comment the
env_save().. or perhaps make it a config option. It will be mildly
annoying, since it means every boot is "first boot", ie. falling back
to fallback.efi to populate BootOrder/Boot variables, and never
using bootmgr. But since we can't set EFI variables from userspace
yet, it isn't really a regression (yet).
Longer term, maybe we need to split out EFI variables from u-boot env
vars.. I thought it would be nice to store them together, since it
gives a convenient way to set EFI variables from script or cmdline.
But at least a subset of the EFI vars should be persisted to reach
EBBR, and if that breaks expectations about u-boot env vars, then I
guess we need to split them.
Side note, devices that can't repeatedly save env (even if we split
out the EFI variables to be stored separately) might be problematic
with EFI_LOADER. Maybe we need a build option they can set to have a
more crippled version of EFI_LOADER, so as to not penalize more
capable devices.
BR,
-R
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 1/1] efi_loader: use named constant for memory type
On Tue, Oct 17, 2017 at 12:53 PM, Heinrich Schuchardt
wrote:
> When we call an EFI image from memory a memory device path
> is created. The memory type should use a named constant.
>
> Fixes: bf19273e81e efi_loader: Add mem-mapped for fallback
> Signed-off-by: Heinrich Schuchardt
> ---
> cmd/bootefi.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/cmd/bootefi.c b/cmd/bootefi.c
> index b2f6fd486a..140072f044 100644
> --- a/cmd/bootefi.c
> +++ b/cmd/bootefi.c
> @@ -173,7 +173,7 @@ static unsigned long do_bootefi_exec(void *efi, void *fdt,
> if (!device_path && !image_path) {
> printf("WARNING: using memory device/image path, this may
> confuse some payloads!\n");
> /* actual addresses filled in after efi_load_pe() */
> - memdp = efi_dp_from_mem(0, 0, 0);
> + memdp = efi_dp_from_mem(EFI_RESERVED_MEMORY_TYPE, 0, 0);
Note that I actually used '0' because this is a special case where the
real memtype is filled in later. And the real mem_type is going to be
one of EFI_LOADER_CODE / EFI_BOOT_SERVICES_CODE /
EFI_RUNTIME_SERVICES_CODE depending on type of .efi that is loaded.
So using EFI_RESERVED_MEMORY_TYPE makes things more confusing.
So I think it should stay '0'.. (or maybe '-1' would be more clear,
except that it is an unsigned arg)
BR,
-R
> device_path = image_path = memdp;
> } else {
> assert(device_path && image_path);
> --
> 2.14.2
>
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 07/11] efi_loader: fix events
On Fri, Oct 13, 2017 at 1:24 AM, Heinrich Schuchardt wrote:
>
>
> On 10/10/2017 02:23 PM, Rob Clark wrote:
>>
>> An event can be created with type==0, Shell.efi does this for an event
>> that is set when Ctrl-C is typed. So our current approach of having a
>> fixed set of timer slots, and determining which slots are unused by
>> type==0 doesn't work so well. But we don't have any particularly good
>> reason to have a fixed table of events, so just dynamically allocate
>> them and keep a list.
>>
>> Also fixes an incorrect implementation of CheckEvent() which was (a)
>> incorrectly returning an error if type==0, and (b) didn't handle the
>> case of an unsignaled event with a notify callback.
>>
>> With these fixes (plus implementation of SIMPLE_TEXT_INPUT_EX protocol),
>> Ctrl-C works in Shell.efi.
>>
>> Signed-off-by: Rob Clark
>> ---
>> include/efi_loader.h | 1 +
>> lib/efi_loader/efi_boottime.c | 217
>> +-
>> 2 files changed, 111 insertions(+), 107 deletions(-)
>>
>> diff --git a/include/efi_loader.h b/include/efi_loader.h
>> index e6e55d2cb4..2232caca44 100644
>> --- a/include/efi_loader.h
>> +++ b/include/efi_loader.h
>> @@ -154,6 +154,7 @@ struct efi_event {
>> enum efi_timer_delay trigger_type;
>> bool is_queued;
>> bool is_signaled;
>> + struct list_head link;
>> };
>> diff --git a/lib/efi_loader/efi_boottime.c
>> b/lib/efi_loader/efi_boottime.c
>> index 39dcc72648..19fafe546c 100644
>> --- a/lib/efi_loader/efi_boottime.c
>> +++ b/lib/efi_loader/efi_boottime.c
>> @@ -350,11 +350,26 @@ static efi_status_t efi_create_handle(void **handle)
>> return r;
>> }
>> +static LIST_HEAD(efi_events);
>> +
>> /*
>> - * Our event capabilities are very limited. Only a small limited
>> - * number of events is allowed to coexist.
>> + * Check if a pointer is a valid event.
>> + *
>> + * It might be nice at some point to extend this to a more general
>> + * mechanism to check if pointers passed from the EFI world are
>> + * valid objects of a particular type.
>>*/
>> -static struct efi_event efi_events[16];
>> +static bool efi_is_event(const void *obj)
>> +{
>> + struct efi_event *evt;
>> +
>> + list_for_each_entry(evt, &efi_events, link) {
>> + if (evt == obj)
>> + return true;
>> + }
>> +
>> + return false;
>> +}
>> /*
>>* Create an event.
>> @@ -377,7 +392,7 @@ efi_status_t efi_create_event(uint32_t type, UINTN
>> notify_tpl,
>> void *context),
>> void *notify_context, struct efi_event
>> **event)
>> {
>> - int i;
>> + struct efi_event *evt;
>> if (event == NULL)
>> return EFI_INVALID_PARAMETER;
>> @@ -389,21 +404,24 @@ efi_status_t efi_create_event(uint32_t type, UINTN
>> notify_tpl,
>> notify_function == NULL)
>> return EFI_INVALID_PARAMETER;
>> - for (i = 0; i < ARRAY_SIZE(efi_events); ++i) {
>> - if (efi_events[i].type)
>> - continue;
>> - efi_events[i].type = type;
>> - efi_events[i].notify_tpl = notify_tpl;
>> - efi_events[i].notify_function = notify_function;
>> - efi_events[i].notify_context = notify_context;
>> - /* Disable timers on bootup */
>> - efi_events[i].trigger_next = -1ULL;
>> - efi_events[i].is_queued = false;
>> - efi_events[i].is_signaled = false;
>> - *event = &efi_events[i];
>> - return EFI_SUCCESS;
>> - }
>> - return EFI_OUT_OF_RESOURCES;
>> + evt = calloc(1, sizeof(*evt));
>> + if (!evt)
>> + return EFI_OUT_OF_RESOURCES;
>> +
>> + evt->type = type;
>> + evt->notify_tpl = notify_tpl;
>> + evt->notify_function = notify_function;
>> + evt->notify_context = notify_context;
>> + /* Disable timers on bootup */
>> + evt->trigger_next = -1ULL;
>> + evt->is_queued = false;
>> + evt->is_signaled = false;
>> +
>> + list_add_tail(&evt->link, &efi_events);
>> +
>> + *event = evt;
>> +
>
Re: [U-Boot] [PATCH 06/11] efi_loader: Decouple EFI input/output from stdin/stdout
On Thu, Oct 12, 2017 at 7:48 PM, Heinrich Schuchardt wrote: > On 10/12/2017 11:26 PM, Rob Clark wrote: >> On Thu, Oct 12, 2017 at 6:38 PM, Heinrich Schuchardt >> wrote: >>> On 10/12/2017 04:28 PM, Rob Clark wrote: >>>> On Thu, Oct 12, 2017 at 9:50 AM, Alexander Graf wrote: >>>>> On 10/12/2017 03:40 PM, Rob Clark wrote: >>>>>> >>>>>> On Thu, Oct 12, 2017 at 9:05 AM, Heinrich Schuchardt >>>>>> wrote: >>>>>>> >>>>>>> >>>>>>> On 10/12/2017 02:48 PM, Rob Clark wrote: >>>>>>>> >>>>>>>> On Thu, Oct 12, 2017 at 3:15 AM, Alexander Graf wrote: >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> On 12.10.17 00:07, Rob Clark wrote: >>>>>>>>>> >>>>>>>>>> On Wed, Oct 11, 2017 at 10:45 AM, Alexander Graf >>>>>>>>>> wrote: >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> On 10.10.17 14:23, Rob Clark wrote: >>>>>>>>>>>> >>>>>>>>>>>> In some cases, it is quite useful to have (for example) EFI on >>>>>>>>>>>> screen >>>>>>>>>>>> but u-boot on serial port. >>>>>>>>>>>> >>>>>>>>>>>> This adds two new optional environment variables, "efiin" and >>>>>>>>>>>> "efiout", >>>>>>>>>>>> which can be used to set EFI console input/output independently of >>>>>>>>>>>> u-boot's input/output. If unset, EFI console will default to >>>>>>>>>>>> stdin/ >>>>>>>>>>>> stdout as before. >>>>>>>>>>>> >>>>>>>>>>>> Signed-off-by: Rob Clark >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> With this patch, we lose the ability to have the efi in/out go to >>>>>>>>>>> both >>>>>>>>>>> graphical and serial console, right? This is critical functionality >>>>>>>>>>> to >>>>>>>>>>> have, since we don't necessarily know which output/input a user ends >>>>>>>>>>> up >>>>>>>>>>> using. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> I'll think about how to support iomux.. but some things like console >>>>>>>>>> size are just not going to work properly there. And as long as we >>>>>>>>>> fix >>>>>>>>> >>>>>>>>> >>>>>>>>> Yeah, those probably would need to get special cased. >>>>>>>>> >>>>>>>>>> the stdout shenanigans (ie. what I was seeing w/ qemu-x86) you can >>>>>>>>>> simply not set efiout var and have things working as before, so you >>>>>>>>>> don't loose any existing functionality (although, like I said, if the >>>>>>>>>> two different consoles have different sizes things aren't going to >>>>>>>>>> work properly for anything other than simple cases). >>>>>>>>>> >>>>>>>>>> In most cases, the display driver should be able to detect whether a >>>>>>>>>> display is connected.. this is what I've done on dragonboard410c, so >>>>>>>>>> if no display plugged in, 'efiout=vidconsole' fails and you fall back >>>>>>>>>> to serial, else you get efi on screen like you would on a "real" >>>>>>>>>> computer. For boards that have a display driver that isn't able to >>>>>>>>>> do >>>>>>>>>> the basic check of whether a cable is plugged in, just don't set >>>>>>>>>> "efiout" (or fix the display driver) ;-) >>>>>>>>> >>>>&
Re: [U-Boot] [PATCH 06/11] efi_loader: Decouple EFI input/output from stdin/stdout
On Thu, Oct 12, 2017 at 6:38 PM, Heinrich Schuchardt wrote: > On 10/12/2017 04:28 PM, Rob Clark wrote: >> On Thu, Oct 12, 2017 at 9:50 AM, Alexander Graf wrote: >>> On 10/12/2017 03:40 PM, Rob Clark wrote: >>>> >>>> On Thu, Oct 12, 2017 at 9:05 AM, Heinrich Schuchardt >>>> wrote: >>>>> >>>>> >>>>> On 10/12/2017 02:48 PM, Rob Clark wrote: >>>>>> >>>>>> On Thu, Oct 12, 2017 at 3:15 AM, Alexander Graf wrote: >>>>>>> >>>>>>> >>>>>>> >>>>>>> On 12.10.17 00:07, Rob Clark wrote: >>>>>>>> >>>>>>>> On Wed, Oct 11, 2017 at 10:45 AM, Alexander Graf >>>>>>>> wrote: >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> On 10.10.17 14:23, Rob Clark wrote: >>>>>>>>>> >>>>>>>>>> In some cases, it is quite useful to have (for example) EFI on >>>>>>>>>> screen >>>>>>>>>> but u-boot on serial port. >>>>>>>>>> >>>>>>>>>> This adds two new optional environment variables, "efiin" and >>>>>>>>>> "efiout", >>>>>>>>>> which can be used to set EFI console input/output independently of >>>>>>>>>> u-boot's input/output. If unset, EFI console will default to stdin/ >>>>>>>>>> stdout as before. >>>>>>>>>> >>>>>>>>>> Signed-off-by: Rob Clark >>>>>>>>> >>>>>>>>> >>>>>>>>> With this patch, we lose the ability to have the efi in/out go to >>>>>>>>> both >>>>>>>>> graphical and serial console, right? This is critical functionality >>>>>>>>> to >>>>>>>>> have, since we don't necessarily know which output/input a user ends >>>>>>>>> up >>>>>>>>> using. >>>>>>>> >>>>>>>> >>>>>>>> I'll think about how to support iomux.. but some things like console >>>>>>>> size are just not going to work properly there. And as long as we fix >>>>>>> >>>>>>> >>>>>>> Yeah, those probably would need to get special cased. >>>>>>> >>>>>>>> the stdout shenanigans (ie. what I was seeing w/ qemu-x86) you can >>>>>>>> simply not set efiout var and have things working as before, so you >>>>>>>> don't loose any existing functionality (although, like I said, if the >>>>>>>> two different consoles have different sizes things aren't going to >>>>>>>> work properly for anything other than simple cases). >>>>>>>> >>>>>>>> In most cases, the display driver should be able to detect whether a >>>>>>>> display is connected.. this is what I've done on dragonboard410c, so >>>>>>>> if no display plugged in, 'efiout=vidconsole' fails and you fall back >>>>>>>> to serial, else you get efi on screen like you would on a "real" >>>>>>>> computer. For boards that have a display driver that isn't able to do >>>>>>>> the basic check of whether a cable is plugged in, just don't set >>>>>>>> "efiout" (or fix the display driver) ;-) >>>>>>> >>>>>>> >>>>>>> Are you sure that's what happens on a "real" computer? As far as I >>>>>>> remember from all ARM servers running edk2 based firmware that I've >>>>>>> touched so far, the default is always to display on serial *and* >>>>>>> graphical output at the same time. >>>>>> >>>>>> >>>>>> Well, I suppose some of the arm64 server vendors have done a better >>>>>> job than others on firmware.. you'd hope they would probe EDID, and >>>>>> report correct console dimensions based on display resolution, etc. >>>>>> >>>>>> Doing bot
Re: [U-Boot] [PATCH 06/11] efi_loader: Decouple EFI input/output from stdin/stdout
On Thu, Oct 12, 2017 at 9:50 AM, Alexander Graf wrote: > On 10/12/2017 03:40 PM, Rob Clark wrote: >> >> On Thu, Oct 12, 2017 at 9:05 AM, Heinrich Schuchardt >> wrote: >>> >>> >>> On 10/12/2017 02:48 PM, Rob Clark wrote: >>>> >>>> On Thu, Oct 12, 2017 at 3:15 AM, Alexander Graf wrote: >>>>> >>>>> >>>>> >>>>> On 12.10.17 00:07, Rob Clark wrote: >>>>>> >>>>>> On Wed, Oct 11, 2017 at 10:45 AM, Alexander Graf >>>>>> wrote: >>>>>>> >>>>>>> >>>>>>> >>>>>>> On 10.10.17 14:23, Rob Clark wrote: >>>>>>>> >>>>>>>> In some cases, it is quite useful to have (for example) EFI on >>>>>>>> screen >>>>>>>> but u-boot on serial port. >>>>>>>> >>>>>>>> This adds two new optional environment variables, "efiin" and >>>>>>>> "efiout", >>>>>>>> which can be used to set EFI console input/output independently of >>>>>>>> u-boot's input/output. If unset, EFI console will default to stdin/ >>>>>>>> stdout as before. >>>>>>>> >>>>>>>> Signed-off-by: Rob Clark >>>>>>> >>>>>>> >>>>>>> With this patch, we lose the ability to have the efi in/out go to >>>>>>> both >>>>>>> graphical and serial console, right? This is critical functionality >>>>>>> to >>>>>>> have, since we don't necessarily know which output/input a user ends >>>>>>> up >>>>>>> using. >>>>>> >>>>>> >>>>>> I'll think about how to support iomux.. but some things like console >>>>>> size are just not going to work properly there. And as long as we fix >>>>> >>>>> >>>>> Yeah, those probably would need to get special cased. >>>>> >>>>>> the stdout shenanigans (ie. what I was seeing w/ qemu-x86) you can >>>>>> simply not set efiout var and have things working as before, so you >>>>>> don't loose any existing functionality (although, like I said, if the >>>>>> two different consoles have different sizes things aren't going to >>>>>> work properly for anything other than simple cases). >>>>>> >>>>>> In most cases, the display driver should be able to detect whether a >>>>>> display is connected.. this is what I've done on dragonboard410c, so >>>>>> if no display plugged in, 'efiout=vidconsole' fails and you fall back >>>>>> to serial, else you get efi on screen like you would on a "real" >>>>>> computer. For boards that have a display driver that isn't able to do >>>>>> the basic check of whether a cable is plugged in, just don't set >>>>>> "efiout" (or fix the display driver) ;-) >>>>> >>>>> >>>>> Are you sure that's what happens on a "real" computer? As far as I >>>>> remember from all ARM servers running edk2 based firmware that I've >>>>> touched so far, the default is always to display on serial *and* >>>>> graphical output at the same time. >>>> >>>> >>>> Well, I suppose some of the arm64 server vendors have done a better >>>> job than others on firmware.. you'd hope they would probe EDID, and >>>> report correct console dimensions based on display resolution, etc. >>>> >>>> Doing both serial and display works for simple stuff, but it goes >>>> badly once the efi payload starts trying to change the cursor position >>>> and write to specific parts of the screen (which both Shell.efi and >>>> grub try to do). >>>> >>>> BR, >>>> -R >>>> >>> Hello Rob, >>> >>> I do not know which program you use for connecting to your serial >>> console. I >>> use minicom which is a Debian/Ubuntu package. I had no problem using >>> grub, >>> vim, nano or any other console program. >>> >>> Minicom just provides a VT100 emulation and that is clos
Re: [U-Boot] [PATCH 06/11] efi_loader: Decouple EFI input/output from stdin/stdout
On Thu, Oct 12, 2017 at 9:44 AM, Mark Kettenis wrote: >> From: Rob Clark >> Date: Thu, 12 Oct 2017 08:48:39 -0400 >> >> On Thu, Oct 12, 2017 at 3:15 AM, Alexander Graf wrote: >> > >> > >> > On 12.10.17 00:07, Rob Clark wrote: >> >> On Wed, Oct 11, 2017 at 10:45 AM, Alexander Graf wrote: >> >>> >> >>> >> >>> On 10.10.17 14:23, Rob Clark wrote: >> >>>> In some cases, it is quite useful to have (for example) EFI on screen >> >>>> but u-boot on serial port. >> >>>> >> >>>> This adds two new optional environment variables, "efiin" and "efiout", >> >>>> which can be used to set EFI console input/output independently of >> >>>> u-boot's input/output. If unset, EFI console will default to stdin/ >> >>>> stdout as before. >> >>>> >> >>>> Signed-off-by: Rob Clark >> >>> >> >>> With this patch, we lose the ability to have the efi in/out go to both >> >>> graphical and serial console, right? This is critical functionality to >> >>> have, since we don't necessarily know which output/input a user ends up >> >>> using. > > Seconded. In many cases I'd want to continue using serial as the > console even if a display is connected. Sure, and this patch isn't preventing that. >> >> I'll think about how to support iomux.. but some things like console >> >> size are just not going to work properly there. And as long as we fix >> > >> > Yeah, those probably would need to get special cased. >> > >> >> the stdout shenanigans (ie. what I was seeing w/ qemu-x86) you can >> >> simply not set efiout var and have things working as before, so you >> >> don't loose any existing functionality (although, like I said, if the >> >> two different consoles have different sizes things aren't going to >> >> work properly for anything other than simple cases). >> >> >> >> In most cases, the display driver should be able to detect whether a >> >> display is connected.. this is what I've done on dragonboard410c, so >> >> if no display plugged in, 'efiout=vidconsole' fails and you fall back >> >> to serial, else you get efi on screen like you would on a "real" >> >> computer. For boards that have a display driver that isn't able to do >> >> the basic check of whether a cable is plugged in, just don't set >> >> "efiout" (or fix the display driver) ;-) > > Display detection will always be somewhat fragile. The old Sun > workstations used to base the decision on whether a keyboard was > connected. With no keyboard detected the output would always go to > serial. s/always/sometimes/ For analog outputs it can be more tricky. For any display technology from this century, it isn't really that hard. Boards that cannot reliably detect whether a display is connected probably don't want to set efiout. >> > Are you sure that's what happens on a "real" computer? As far as I >> > remember from all ARM servers running edk2 based firmware that I've >> > touched so far, the default is always to display on serial *and* >> > graphical output at the same time. >> >> Well, I suppose some of the arm64 server vendors have done a better >> job than others on firmware.. you'd hope they would probe EDID, and >> report correct console dimensions based on display resolution, etc. >> >> Doing both serial and display works for simple stuff, but it goes >> badly once the efi payload starts trying to change the cursor position >> and write to specific parts of the screen (which both Shell.efi and >> grub try to do). > > From my point of view a bootloader should only do "simple stuff". All > this fancy display stuff makes a serial console much harder to use. Sure, but people who tinker with u-boot and low level stuff aren't the only target audience here. This patch provides a (completely optional) way to provide a sane default that doesn't require a serial cable, yet still works with one if you don't have a display connected.. some people expect to be able to just plug in display + keyboard + power and get to a grub boot menu, just like you would on an x86/uefi system. BR, -R ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 06/11] efi_loader: Decouple EFI input/output from stdin/stdout
On Thu, Oct 12, 2017 at 9:11 AM, Alexander Graf wrote: > On 10/12/2017 02:48 PM, Rob Clark wrote: >> >> On Thu, Oct 12, 2017 at 3:15 AM, Alexander Graf wrote: >>> >>> >>> On 12.10.17 00:07, Rob Clark wrote: >>>> >>>> On Wed, Oct 11, 2017 at 10:45 AM, Alexander Graf wrote: >>>>> >>>>> >>>>> On 10.10.17 14:23, Rob Clark wrote: >>>>>> >>>>>> In some cases, it is quite useful to have (for example) EFI on screen >>>>>> but u-boot on serial port. >>>>>> >>>>>> This adds two new optional environment variables, "efiin" and >>>>>> "efiout", >>>>>> which can be used to set EFI console input/output independently of >>>>>> u-boot's input/output. If unset, EFI console will default to stdin/ >>>>>> stdout as before. >>>>>> >>>>>> Signed-off-by: Rob Clark >>>>> >>>>> With this patch, we lose the ability to have the efi in/out go to both >>>>> graphical and serial console, right? This is critical functionality to >>>>> have, since we don't necessarily know which output/input a user ends up >>>>> using. >>>> >>>> I'll think about how to support iomux.. but some things like console >>>> size are just not going to work properly there. And as long as we fix >>> >>> Yeah, those probably would need to get special cased. >>> >>>> the stdout shenanigans (ie. what I was seeing w/ qemu-x86) you can >>>> simply not set efiout var and have things working as before, so you >>>> don't loose any existing functionality (although, like I said, if the >>>> two different consoles have different sizes things aren't going to >>>> work properly for anything other than simple cases). >>>> >>>> In most cases, the display driver should be able to detect whether a >>>> display is connected.. this is what I've done on dragonboard410c, so >>>> if no display plugged in, 'efiout=vidconsole' fails and you fall back >>>> to serial, else you get efi on screen like you would on a "real" >>>> computer. For boards that have a display driver that isn't able to do >>>> the basic check of whether a cable is plugged in, just don't set >>>> "efiout" (or fix the display driver) ;-) >>> >>> Are you sure that's what happens on a "real" computer? As far as I >>> remember from all ARM servers running edk2 based firmware that I've >>> touched so far, the default is always to display on serial *and* >>> graphical output at the same time. >> >> Well, I suppose some of the arm64 server vendors have done a better >> job than others on firmware.. you'd hope they would probe EDID, and >> report correct console dimensions based on display resolution, etc. > > > Not sure that's terribly helpful. Most of these servers have built-in BMC > chips that just go to a fake video console, so they always get EDID > information, but that doesn't mean that it's sensible for what the user ends > up seeing. > > I think what happens is that in most cases they just assume you have a 80x25 > console :). oh, right.. BMC's.. well, let's not strive to be as horrible as enterprise hardware ;-) BR, -R ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 06/11] efi_loader: Decouple EFI input/output from stdin/stdout
On Thu, Oct 12, 2017 at 9:05 AM, Heinrich Schuchardt wrote: > > > On 10/12/2017 02:48 PM, Rob Clark wrote: >> >> On Thu, Oct 12, 2017 at 3:15 AM, Alexander Graf wrote: >>> >>> >>> >>> On 12.10.17 00:07, Rob Clark wrote: >>>> >>>> On Wed, Oct 11, 2017 at 10:45 AM, Alexander Graf wrote: >>>>> >>>>> >>>>> >>>>> On 10.10.17 14:23, Rob Clark wrote: >>>>>> >>>>>> In some cases, it is quite useful to have (for example) EFI on screen >>>>>> but u-boot on serial port. >>>>>> >>>>>> This adds two new optional environment variables, "efiin" and >>>>>> "efiout", >>>>>> which can be used to set EFI console input/output independently of >>>>>> u-boot's input/output. If unset, EFI console will default to stdin/ >>>>>> stdout as before. >>>>>> >>>>>> Signed-off-by: Rob Clark >>>>> >>>>> >>>>> With this patch, we lose the ability to have the efi in/out go to both >>>>> graphical and serial console, right? This is critical functionality to >>>>> have, since we don't necessarily know which output/input a user ends up >>>>> using. >>>> >>>> >>>> I'll think about how to support iomux.. but some things like console >>>> size are just not going to work properly there. And as long as we fix >>> >>> >>> Yeah, those probably would need to get special cased. >>> >>>> the stdout shenanigans (ie. what I was seeing w/ qemu-x86) you can >>>> simply not set efiout var and have things working as before, so you >>>> don't loose any existing functionality (although, like I said, if the >>>> two different consoles have different sizes things aren't going to >>>> work properly for anything other than simple cases). >>>> >>>> In most cases, the display driver should be able to detect whether a >>>> display is connected.. this is what I've done on dragonboard410c, so >>>> if no display plugged in, 'efiout=vidconsole' fails and you fall back >>>> to serial, else you get efi on screen like you would on a "real" >>>> computer. For boards that have a display driver that isn't able to do >>>> the basic check of whether a cable is plugged in, just don't set >>>> "efiout" (or fix the display driver) ;-) >>> >>> >>> Are you sure that's what happens on a "real" computer? As far as I >>> remember from all ARM servers running edk2 based firmware that I've >>> touched so far, the default is always to display on serial *and* >>> graphical output at the same time. >> >> >> Well, I suppose some of the arm64 server vendors have done a better >> job than others on firmware.. you'd hope they would probe EDID, and >> report correct console dimensions based on display resolution, etc. >> >> Doing both serial and display works for simple stuff, but it goes >> badly once the efi payload starts trying to change the cursor position >> and write to specific parts of the screen (which both Shell.efi and >> grub try to do). >> >> BR, >> -R >> > Hello Rob, > > I do not know which program you use for connecting to your serial console. I > use minicom which is a Debian/Ubuntu package. I had no problem using grub, > vim, nano or any other console program. > > Minicom just provides a VT100 emulation and that is close enough to what > Linux expects. fwiw, I generally use kermit so my terminal emulator is whatever "xterm" type app I'm using. (Currently a big fan of Tilix).. but that isn't so much the issue.. > So I would not see what should be so special about Shell.efi. I'm not explaining the problem well, but you can see basically the same issue if you resize your terminal emulator to something smaller than what grub/shell/etc think you are using. I guess if they just fall back to assuming 80x25 like agraf mentioned, that would kind of work. It just means shell or grub will only use the tiny upper-left corner of your monitor. > My U-Boot system all have video but I never have a monitor connected. > > So being able to use serial even if video is available is a necessity. If the video driver doesn't detect that it is unconnected, someone should really fix that, otherwise you'll have problems booting an image where grub tries to use gfxterm if GOP is present (but we are really getting off topic here) Either way, you still have the option of not setting efiout (or setting it to serial) But for end users (at least of boards that I care about), if they plug in a monitor they should get grub on screen. Not everyone has a serial cable attached. BR, -R ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 06/11] efi_loader: Decouple EFI input/output from stdin/stdout
On Thu, Oct 12, 2017 at 3:15 AM, Alexander Graf wrote: > > > On 12.10.17 00:07, Rob Clark wrote: >> On Wed, Oct 11, 2017 at 10:45 AM, Alexander Graf wrote: >>> >>> >>> On 10.10.17 14:23, Rob Clark wrote: >>>> In some cases, it is quite useful to have (for example) EFI on screen >>>> but u-boot on serial port. >>>> >>>> This adds two new optional environment variables, "efiin" and "efiout", >>>> which can be used to set EFI console input/output independently of >>>> u-boot's input/output. If unset, EFI console will default to stdin/ >>>> stdout as before. >>>> >>>> Signed-off-by: Rob Clark >>> >>> With this patch, we lose the ability to have the efi in/out go to both >>> graphical and serial console, right? This is critical functionality to >>> have, since we don't necessarily know which output/input a user ends up >>> using. >> >> I'll think about how to support iomux.. but some things like console >> size are just not going to work properly there. And as long as we fix > > Yeah, those probably would need to get special cased. > >> the stdout shenanigans (ie. what I was seeing w/ qemu-x86) you can >> simply not set efiout var and have things working as before, so you >> don't loose any existing functionality (although, like I said, if the >> two different consoles have different sizes things aren't going to >> work properly for anything other than simple cases). >> >> In most cases, the display driver should be able to detect whether a >> display is connected.. this is what I've done on dragonboard410c, so >> if no display plugged in, 'efiout=vidconsole' fails and you fall back >> to serial, else you get efi on screen like you would on a "real" >> computer. For boards that have a display driver that isn't able to do >> the basic check of whether a cable is plugged in, just don't set >> "efiout" (or fix the display driver) ;-) > > Are you sure that's what happens on a "real" computer? As far as I > remember from all ARM servers running edk2 based firmware that I've > touched so far, the default is always to display on serial *and* > graphical output at the same time. Well, I suppose some of the arm64 server vendors have done a better job than others on firmware.. you'd hope they would probe EDID, and report correct console dimensions based on display resolution, etc. Doing both serial and display works for simple stuff, but it goes badly once the efi payload starts trying to change the cursor position and write to specific parts of the screen (which both Shell.efi and grub try to do). BR, -R ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 02/11] efi_loader: Initial HII protocols
On Thu, Oct 12, 2017 at 3:13 AM, Alexander Graf wrote:
>
>
> On 12.10.17 00:02, Rob Clark wrote:
>> On Wed, Oct 11, 2017 at 10:30 AM, Alexander Graf wrote:
>>>
>>>
>>> On 10.10.17 14:22, Rob Clark wrote:
>>>> From: Leif Lindholm
>>>>
>>>> Enough implementation of the following protocols to run Shell.efi and
>>>> SCT.efi:
>>>>
>>>> EfiHiiConfigRoutingProtocolGuid
>>>> EfiHiiDatabaseProtocol
>>>> EfiHiiStringProtocol
>>>>
>>>> We'll fill in the rest once SCT is running properly so we can validate
>>>> the implementation against the conformance test suite.
>>>>
>>>> Initial skeleton written by Leif, and then implementation by myself.
>>>>
>>>> Cc: Leif Lindholm
>>>> Signed-off-by: Rob Clark
>>>> ---
>>>> include/efi_api.h | 261 ++
>>>> include/efi_loader.h | 6 +
>>>> lib/efi_loader/Makefile | 2 +-
>>>> lib/efi_loader/efi_boottime.c | 9 +
>>>> lib/efi_loader/efi_hii.c | 507
>>>> ++
>>>> 5 files changed, 784 insertions(+), 1 deletion(-)
>>>> create mode 100644 lib/efi_loader/efi_hii.c
>>>>
>>>> diff --git a/include/efi_api.h b/include/efi_api.h
>>>> index ffdba7fe1a..164147dc87 100644
>>>> --- a/include/efi_api.h
>>>> +++ b/include/efi_api.h
>>>> @@ -16,6 +16,7 @@
>>>> #define _EFI_API_H
>>>>
>>>> #include
>>>> +#include
>>>>
>>>> #ifdef CONFIG_EFI_LOADER
>>>> #include
>>>> @@ -536,6 +537,266 @@ struct efi_device_path_utilities_protocol {
>>>> uint16_t node_length);
>>>> };
>>>>
>>>> +#define EFI_HII_CONFIG_ROUTING_PROTOCOL_GUID \
>>>> + EFI_GUID(0x587e72d7, 0xcc50, 0x4f79, \
>>>> + 0x82, 0x09, 0xca, 0x29, 0x1f, 0xc1, 0xa1, 0x0f)
>>>> +
>>>> +typedef uint16_t efi_string_id_t;
>>>> +
>>>> +struct efi_hii_config_routing_protocol {
>>>> + efi_status_t(EFIAPI *extract_config)(
>>>> + const struct efi_hii_config_routing_protocol *this,
>>>> + const efi_string_t request,
>>>> + efi_string_t *progress,
>>>> + efi_string_t *results);
>>>> + efi_status_t(EFIAPI *export_config)(
>>>> + const struct efi_hii_config_routing_protocol *this,
>>>> + efi_string_t *results);
>>>> + efi_status_t(EFIAPI *route_config)(
>>>> + const struct efi_hii_config_routing_protocol *this,
>>>> + const efi_string_t configuration,
>>>> + efi_string_t *progress);
>>>> + efi_status_t(EFIAPI *block_to_config)(
>>>> + const struct efi_hii_config_routing_protocol *this,
>>>> + const efi_string_t config_request,
>>>> + const uint8_t *block,
>>>> + const efi_uintn_t block_size,
>>>> + efi_string_t *config,
>>>> + efi_string_t *progress);
>>>> + efi_status_t(EFIAPI *config_to_block)(
>>>> + const struct efi_hii_config_routing_protocol *this,
>>>> + const efi_string_t config_resp,
>>>> + const uint8_t *block,
>>>> + const efi_uintn_t *block_size,
>>>> + efi_string_t *progress);
>>>> + efi_status_t(EFIAPI *get_alt_config)(
>>>> + const struct efi_hii_config_routing_protocol *this,
>>>> + const efi_string_t config_resp,
>>>> + const efi_guid_t *guid,
>>>> + const efi_string_t name,
>>>> + const struct efi_device_path *device_path,
>>>> + const efi_string_t alt_cfg_id,
>>>> + efi_string_t *alt_cfg_resp);
>>>> +};
>>>> +
>>>> +#define EFI_HII_DATABASE_PROTOCOL_GUID\
>>>> + EFI_GUID(0xef9fc172, 0xa1b2, 0x4693, \
>>>> + 0xb3, 0x27, 0x6d, 0x32, 0xfc, 0x41, 0x60, 0x42)
>>>> +
>>>> +typedef enum {
>>>> + EFI_KEY_LCTRL, EFI_KEY_A0, EFI_KEY_LALT, EFI_KEY_SPACE_BAR,
>>>> + EFI_KEY_A2, EFI_KEY_A3,
Re: [U-Boot] efi_loader query
On Wed, Oct 11, 2017 at 12:13 PM, Suneel Garapati wrote: > Hi Rob, > > I am enlisted on u-boot mailing list and currently trying to use efi > loader to launch ubuntu distro. > > Appreciate your great efforts on this, would definitely help a lot. > > I tried to boot grub from u-boot using efi_loader using, > bootefi note that the distro-bootcmd stuff should "just work" to avoid needing to do this step manually > however I see one error "Error to install/update FDT" while launch > ubuntu from grub menu. So, without editing grub.cfg to add 'devicetree' commands, it is expecting u-boot to load the correct fdt before 'bootefi'.. I have a patch[1] to do this as part of distro-bootcmd which we are using in fedora. [1] https://patchwork.ozlabs.org/patch/821470/ > I could also see > "Loading Linux.." > "Loading ramdisk..." > But jumps back to grub menu instead of booting into linux. > > I would like to know if CONFIG_EFI_LOADER will suffice or anything > else needs to be defined for distro support. I think also CONFIG_DISTRO_DEFAULTS.. assuming there are no special hacks in ubuntu's grub build for arm/arm64, at least. For fedora we are not using any special arm specific patches for grub (or shim/fallback) and (at least with the addition of the patch mentioned above to handled fdt loading in u-boot) it all just works automatically the same way it does on x86_64 (with all the other patches that landed for 2017.11 so far). BR, -R > Any suggestions/inputs would be of great help. > > Regards, > Suneel ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 10/11] efi_loader: Add mem-mapped for fallback
On Wed, Oct 11, 2017 at 10:59 AM, Alexander Graf wrote:
>
>
> On 10.10.17 14:23, Rob Clark wrote:
>> When we don't have a real device/image path, such as 'bootefi hello',
>> construct a mem-mapped device-path.
>>
>> This fixes 'bootefi hello' after devicepath refactoring.
>>
>> Fixes: 95c5553ea2 ("efi_loader: refactor boot device and loaded_image
>> handling")
>> Signed-off-by: Rob Clark
>> ---
>> cmd/bootefi.c| 23 +++
>> include/efi_api.h| 8
>> include/efi_loader.h | 3 +++
>> lib/efi_loader/efi_device_path.c | 24
>> lib/efi_loader/efi_device_path_to_text.c | 9 +
>> 5 files changed, 67 insertions(+)
>>
>> diff --git a/cmd/bootefi.c b/cmd/bootefi.c
>> index 24958ada46..18176a1266 100644
>> --- a/cmd/bootefi.c
>> +++ b/cmd/bootefi.c
>> @@ -128,6 +128,7 @@ static unsigned long do_bootefi_exec(void *efi, void
>> *fdt,
>> {
>> struct efi_loaded_image loaded_image_info = {};
>> struct efi_object loaded_image_info_obj = {};
>> + struct efi_device_path *memdp = NULL;
>> ulong ret;
>>
>> ulong (*entry)(void *image_handle, struct efi_system_table *st)
>> @@ -136,6 +137,20 @@ static unsigned long do_bootefi_exec(void *efi, void
>> *fdt,
>> const efi_guid_t fdt_guid = EFI_FDT_GUID;
>> bootm_headers_t img = { 0 };
>>
>> + /*
>> + * Special case for efi payload not loaded from disk, such as
>> + * 'bootefi hello' or for example payload loaded directly into
>> + * memory via jtag/etc:
>> + */
>> + if (!device_path && !image_path) {
>> + printf("WARNING: using memory device/image path, this may
>> confuse some payloads!\n");
>> + /* actual addresses filled in after efi_load_pe() */
>> + memdp = efi_dp_from_mem(0, 0, 0);
>> + device_path = image_path = memdp;
>> + } else {
>> + assert(device_path && image_path);
>> + }
>> +
>> /* Initialize and populate EFI object list */
>> if (!efi_obj_list_initalized)
>> efi_init_obj_list();
>> @@ -182,6 +197,14 @@ static unsigned long do_bootefi_exec(void *efi, void
>> *fdt,
>> goto exit;
>> }
>>
>> + if (memdp) {
>> + struct efi_device_path_memory *mdp = (void *)memdp;
>> + mdp->memory_type = loaded_image_info.image_code_type;
>> + mdp->start_address = (uintptr_t)loaded_image_info.image_base;
>> + mdp->end_address = mdp->start_address +
>> + loaded_image_info.image_size;
>> + }
>> +
>
> memdp gets leaked after bootefi is done. Putting it on the stack would
> at least remove that problem ;). We currently expect to only return from
> bootefi when a payload was successfully quit.
>
dp's that aren't allocated from pool are a bad idea, in some cases
they get free'd by the payload. (Well not really in this particular
case but it feels like a bad idea to mix/match how we allocate dp's..
also, it needs an /End node.) I guess it isn't such a critical leak,
but the right solution would be to efi_free_pool() it..
BR,
-R
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 07/11] efi_loader: fix events
On Wed, Oct 11, 2017 at 10:49 AM, Alexander Graf wrote:
>
>
> On 10.10.17 14:23, Rob Clark wrote:
>> An event can be created with type==0, Shell.efi does this for an event
>> that is set when Ctrl-C is typed. So our current approach of having a
>> fixed set of timer slots, and determining which slots are unused by
>> type==0 doesn't work so well. But we don't have any particularly good
>> reason to have a fixed table of events, so just dynamically allocate
>> them and keep a list.
>>
>> Also fixes an incorrect implementation of CheckEvent() which was (a)
>> incorrectly returning an error if type==0, and (b) didn't handle the
>> case of an unsignaled event with a notify callback.
>>
>> With these fixes (plus implementation of SIMPLE_TEXT_INPUT_EX protocol),
>> Ctrl-C works in Shell.efi.
>>
>> Signed-off-by: Rob Clark
>> ---
>> include/efi_loader.h | 1 +
>> lib/efi_loader/efi_boottime.c | 217
>> +-
>> 2 files changed, 111 insertions(+), 107 deletions(-)
>>
>> diff --git a/include/efi_loader.h b/include/efi_loader.h
>> index e6e55d2cb4..2232caca44 100644
>> --- a/include/efi_loader.h
>> +++ b/include/efi_loader.h
>> @@ -154,6 +154,7 @@ struct efi_event {
>> enum efi_timer_delay trigger_type;
>> bool is_queued;
>> bool is_signaled;
>> + struct list_head link;
>> };
>>
>>
>> diff --git a/lib/efi_loader/efi_boottime.c b/lib/efi_loader/efi_boottime.c
>> index 39dcc72648..19fafe546c 100644
>> --- a/lib/efi_loader/efi_boottime.c
>> +++ b/lib/efi_loader/efi_boottime.c
>> @@ -350,11 +350,26 @@ static efi_status_t efi_create_handle(void **handle)
>> return r;
>> }
>>
>> +static LIST_HEAD(efi_events);
>> +
>> /*
>> - * Our event capabilities are very limited. Only a small limited
>> - * number of events is allowed to coexist.
>> + * Check if a pointer is a valid event.
>> + *
>> + * It might be nice at some point to extend this to a more general
>> + * mechanism to check if pointers passed from the EFI world are
>> + * valid objects of a particular type.
>> */
>> -static struct efi_event efi_events[16];
>> +static bool efi_is_event(const void *obj)
>> +{
>> + struct efi_event *evt;
>> +
>> + list_for_each_entry(evt, &efi_events, link) {
>> + if (evt == obj)
>> + return true;
>> + }
>> +
>> + return false;
>> +}
>>
>> /*
>> * Create an event.
>> @@ -377,7 +392,7 @@ efi_status_t efi_create_event(uint32_t type, UINTN
>> notify_tpl,
>> void *context),
>> void *notify_context, struct efi_event **event)
>> {
>> - int i;
>> + struct efi_event *evt;
>>
>> if (event == NULL)
>> return EFI_INVALID_PARAMETER;
>> @@ -389,21 +404,24 @@ efi_status_t efi_create_event(uint32_t type, UINTN
>> notify_tpl,
>> notify_function == NULL)
>> return EFI_INVALID_PARAMETER;
>>
>> - for (i = 0; i < ARRAY_SIZE(efi_events); ++i) {
>> - if (efi_events[i].type)
>> - continue;
>> - efi_events[i].type = type;
>> - efi_events[i].notify_tpl = notify_tpl;
>> - efi_events[i].notify_function = notify_function;
>> - efi_events[i].notify_context = notify_context;
>> - /* Disable timers on bootup */
>> - efi_events[i].trigger_next = -1ULL;
>> - efi_events[i].is_queued = false;
>> - efi_events[i].is_signaled = false;
>> - *event = &efi_events[i];
>> - return EFI_SUCCESS;
>> - }
>> - return EFI_OUT_OF_RESOURCES;
>> + evt = calloc(1, sizeof(*evt));
>> + if (!evt)
>> + return EFI_OUT_OF_RESOURCES;
>> +
>> + evt->type = type;
>> + evt->notify_tpl = notify_tpl;
>> + evt->notify_function = notify_function;
>> + evt->notify_context = notify_context;
>> + /* Disable timers on bootup */
>> + evt->trigger_next = -1ULL;
>> + evt->is_queued = false;
>> + evt->is_signaled = false;
>> +
>> + list_add_tail(&evt->link, &efi_events);
>> +
>> + *event = evt;
>> +
>> + return EFI_SUCCESS;
>> }
>>
>&
Re: [U-Boot] [PATCH 06/11] efi_loader: Decouple EFI input/output from stdin/stdout
On Wed, Oct 11, 2017 at 10:45 AM, Alexander Graf wrote: > > > On 10.10.17 14:23, Rob Clark wrote: >> In some cases, it is quite useful to have (for example) EFI on screen >> but u-boot on serial port. >> >> This adds two new optional environment variables, "efiin" and "efiout", >> which can be used to set EFI console input/output independently of >> u-boot's input/output. If unset, EFI console will default to stdin/ >> stdout as before. >> >> Signed-off-by: Rob Clark > > With this patch, we lose the ability to have the efi in/out go to both > graphical and serial console, right? This is critical functionality to > have, since we don't necessarily know which output/input a user ends up > using. I'll think about how to support iomux.. but some things like console size are just not going to work properly there. And as long as we fix the stdout shenanigans (ie. what I was seeing w/ qemu-x86) you can simply not set efiout var and have things working as before, so you don't loose any existing functionality (although, like I said, if the two different consoles have different sizes things aren't going to work properly for anything other than simple cases). In most cases, the display driver should be able to detect whether a display is connected.. this is what I've done on dragonboard410c, so if no display plugged in, 'efiout=vidconsole' fails and you fall back to serial, else you get efi on screen like you would on a "real" computer. For boards that have a display driver that isn't able to do the basic check of whether a cable is plugged in, just don't set "efiout" (or fix the display driver) ;-) BR, -R > > Alex ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 02/11] efi_loader: Initial HII protocols
On Wed, Oct 11, 2017 at 10:30 AM, Alexander Graf wrote:
>
>
> On 10.10.17 14:22, Rob Clark wrote:
>> From: Leif Lindholm
>>
>> Enough implementation of the following protocols to run Shell.efi and
>> SCT.efi:
>>
>> EfiHiiConfigRoutingProtocolGuid
>> EfiHiiDatabaseProtocol
>> EfiHiiStringProtocol
>>
>> We'll fill in the rest once SCT is running properly so we can validate
>> the implementation against the conformance test suite.
>>
>> Initial skeleton written by Leif, and then implementation by myself.
>>
>> Cc: Leif Lindholm
>> Signed-off-by: Rob Clark
>> ---
>> include/efi_api.h | 261 ++
>> include/efi_loader.h | 6 +
>> lib/efi_loader/Makefile | 2 +-
>> lib/efi_loader/efi_boottime.c | 9 +
>> lib/efi_loader/efi_hii.c | 507
>> ++
>> 5 files changed, 784 insertions(+), 1 deletion(-)
>> create mode 100644 lib/efi_loader/efi_hii.c
>>
>> diff --git a/include/efi_api.h b/include/efi_api.h
>> index ffdba7fe1a..164147dc87 100644
>> --- a/include/efi_api.h
>> +++ b/include/efi_api.h
>> @@ -16,6 +16,7 @@
>> #define _EFI_API_H
>>
>> #include
>> +#include
>>
>> #ifdef CONFIG_EFI_LOADER
>> #include
>> @@ -536,6 +537,266 @@ struct efi_device_path_utilities_protocol {
>> uint16_t node_length);
>> };
>>
>> +#define EFI_HII_CONFIG_ROUTING_PROTOCOL_GUID \
>> + EFI_GUID(0x587e72d7, 0xcc50, 0x4f79, \
>> + 0x82, 0x09, 0xca, 0x29, 0x1f, 0xc1, 0xa1, 0x0f)
>> +
>> +typedef uint16_t efi_string_id_t;
>> +
>> +struct efi_hii_config_routing_protocol {
>> + efi_status_t(EFIAPI *extract_config)(
>> + const struct efi_hii_config_routing_protocol *this,
>> + const efi_string_t request,
>> + efi_string_t *progress,
>> + efi_string_t *results);
>> + efi_status_t(EFIAPI *export_config)(
>> + const struct efi_hii_config_routing_protocol *this,
>> + efi_string_t *results);
>> + efi_status_t(EFIAPI *route_config)(
>> + const struct efi_hii_config_routing_protocol *this,
>> + const efi_string_t configuration,
>> + efi_string_t *progress);
>> + efi_status_t(EFIAPI *block_to_config)(
>> + const struct efi_hii_config_routing_protocol *this,
>> + const efi_string_t config_request,
>> + const uint8_t *block,
>> + const efi_uintn_t block_size,
>> + efi_string_t *config,
>> + efi_string_t *progress);
>> + efi_status_t(EFIAPI *config_to_block)(
>> + const struct efi_hii_config_routing_protocol *this,
>> + const efi_string_t config_resp,
>> + const uint8_t *block,
>> + const efi_uintn_t *block_size,
>> + efi_string_t *progress);
>> + efi_status_t(EFIAPI *get_alt_config)(
>> + const struct efi_hii_config_routing_protocol *this,
>> + const efi_string_t config_resp,
>> + const efi_guid_t *guid,
>> + const efi_string_t name,
>> + const struct efi_device_path *device_path,
>> + const efi_string_t alt_cfg_id,
>> + efi_string_t *alt_cfg_resp);
>> +};
>> +
>> +#define EFI_HII_DATABASE_PROTOCOL_GUID\
>> + EFI_GUID(0xef9fc172, 0xa1b2, 0x4693, \
>> + 0xb3, 0x27, 0x6d, 0x32, 0xfc, 0x41, 0x60, 0x42)
>> +
>> +typedef enum {
>> + EFI_KEY_LCTRL, EFI_KEY_A0, EFI_KEY_LALT, EFI_KEY_SPACE_BAR,
>> + EFI_KEY_A2, EFI_KEY_A3, EFI_KEY_A4, EFI_KEY_RCTRL, EFI_KEY_LEFT_ARROW,
>> + EFI_KEY_DOWN_ARROW, EFI_KEY_RIGHT_ARROW, EFI_KEY_ZERO,
>> + EFI_KEY_PERIOD, EFI_KEY_ENTER, EFI_KEY_LSHIFT, EFI_KEY_B0,
>> + EFI_KEY_B1, EFI_KEY_B2, EFI_KEY_B3, EFI_KEY_B4, EFI_KEY_B5, EFI_KEY_B6,
>> + EFI_KEY_B7, EFI_KEY_B8, EFI_KEY_B9, EFI_KEY_B10, EFI_KEY_RSHIFT,
>> + EFI_KEY_UP_ARROW, EFI_KEY_ONE, EFI_KEY_TWO, EFI_KEY_THREE,
>> + EFI_KEY_CAPS_LOCK, EFI_KEY_C1, EFI_KEY_C2, EFI_KEY_C3, EFI_KEY_C4,
>> + EFI_KEY_C5, EFI_KEY_C6, EFI_KEY_C7, EFI_KEY_C8, EFI_KEY_C9,
>> + EFI_KEY_C10, EFI_KEY_C11, EFI_KEY_C12, EFI_KEY_FOUR, EFI_KEY_FIVE,
>> + EFI_KEY_SIX, EFI_KEY_PLUS, EFI_KEY_TAB, EFI_KEY_D1, EFI_KEY_D2,
>> + EFI_KEY_D3, EFI_KEY_D4, EFI_KEY_D5, EFI_KEY_D6, EFI_KEY_D7, EFI_KEY_D8,
>> + EFI_KEY_D9, EFI_KEY_D10, EFI_KEY_D11
Re: [U-Boot] [PATCH 01/11] efi_loader: Initial EFI_DEVICE_PATH_UTILITIES_PROTOCOL
On Wed, Oct 11, 2017 at 10:07 AM, Alexander Graf wrote:
>
>
> On 10.10.17 14:22, Rob Clark wrote:
>> From: Leif Lindholm
>>
>> Not complete, but enough for Shell.efi and SCT.efi. We'll implement the
>> rest as needed or once we have SCT running properly so there is a way to
>> validate the interface against the conformance test suite.
>>
>> Initial skeleton written by Leif, and then implementation by myself.
>>
>> Cc: Leif Lindholm
>> Signed-off-by: Rob Clark
>> ---
>> include/efi_api.h | 34 +++-
>> include/efi_loader.h | 2 +
>> lib/efi_loader/Makefile| 1 +
>> lib/efi_loader/efi_boottime.c | 4 ++
>> lib/efi_loader/efi_device_path_utilities.c | 88
>> ++
>> 5 files changed, 127 insertions(+), 2 deletions(-)
>> create mode 100644 lib/efi_loader/efi_device_path_utilities.c
>>
>> diff --git a/include/efi_api.h b/include/efi_api.h
>> index a9a6494afe..ffdba7fe1a 100644
>> --- a/include/efi_api.h
>> +++ b/include/efi_api.h
>> @@ -28,8 +28,9 @@ enum efi_timer_delay {
>> EFI_TIMER_RELATIVE = 2
>> };
>>
>> -#define UINTN size_t
>> -typedef long INTN;
>> +#define UINTN size_t /* TODO this should be removed in a future patch */
>
> $ git grep UINTN | wc -l
> 13
>
> Just send a preceding patch that introduces efi_uintn_t and replaces all
> occurences of UINTN with it.
>
> The uintn bits shouldn't be part of the
> EFI_DEVICE_PATH_UTILITIES_PROTOCOL patch anyways :).
>
Heinrich mentioned he was doing that, so I didn't want to step on
feet. I figured this was the easiest approach regardless of the order
of merging patches (should be simple enough to drop the duplicate
efi_uintn_t)
BR,
-R
>> +typedef size_t efi_uintn_t;
>> +typedef ssize_t efi_intn_t;
>> typedef uint16_t *efi_string_t;
>
>
> Alex
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 03/11] efi_loader: Initial EFI_UNICODE_COLLATION_PROTOCOL
On Wed, Oct 11, 2017 at 10:36 AM, Alexander Graf wrote:
>
>
> On 10.10.17 14:22, Rob Clark wrote:
>> From: Leif Lindholm
>>
>> Not complete, but enough for Shell.efi and SCT.efi.
>>
>> Initial skeleton written by Leif, and then implementation by myself.
>>
>> Cc: Leif Lindholm
>> Signed-off-by: Rob Clark
>> ---
>> include/efi_api.h | 41 ++
>> include/efi_loader.h | 3 +
>> lib/efi_loader/Makefile | 2 +-
>> lib/efi_loader/efi_boottime.c | 6 ++
>> lib/efi_loader/efi_unicode.c | 170
>> ++
>> 5 files changed, 221 insertions(+), 1 deletion(-)
>> create mode 100644 lib/efi_loader/efi_unicode.c
>>
>> diff --git a/include/efi_api.h b/include/efi_api.h
>> index 164147dc87..38dd1240c1 100644
>> --- a/include/efi_api.h
>> +++ b/include/efi_api.h
>> @@ -797,6 +797,47 @@ struct efi_hii_string_protocol {
>> efi_uintn_t *secondary_languages_size);
>> };
>>
>> +/*
>> + * Both UNICODE_COLLATION protocols seem to be the same thing, but
>> + * advertised with two different GUID's because, why not?
>> + */
>> +
>> +#define EFI_UNICODE_COLLATION_PROTOCOL_GUID \
>> + EFI_GUID(0x1d85cd7f, 0xf43d, 0x11d2, \
>> + 0x9a, 0x0c, 0x00, 0x90, 0x27, 0x3f, 0xc1, 0x4d)
>> +
>> +#define EFI_UNICODE_COLLATION_PROTOCOL2_GUID \
>> + EFI_GUID(0xa4c751fc, 0x23ae, 0x4c3e, \
>> + 0x92, 0xe9, 0x49, 0x64, 0xcf, 0x63, 0xf3, 0x49)
>> +
>> +struct efi_unicode_collation_protocol {
>> + efi_intn_t (EFIAPI *stri_coll)(
>> + struct efi_unicode_collation_protocol *this,
>> + efi_string_t s1,
>> + efi_string_t s2);
>> + bool (EFIAPI *metai_match)(
>> + struct efi_unicode_collation_protocol *this,
>> + efi_string_t string,
>> + efi_string_t pattern);
>> + void (EFIAPI *str_lwr)(
>> + struct efi_unicode_collation_protocol *this,
>> + efi_string_t string);
>> + void (EFIAPI *str_upr)(
>> + struct efi_unicode_collation_protocol *this,
>> + efi_string_t string);
>> + void (EFIAPI *fat_to_str)(
>> + struct efi_unicode_collation_protocol *this,
>> + efi_uintn_t fat_size,
>> + uint8_t *fat,
>> + efi_string_t string);
>> + bool (EFIAPI *str_to_fat)(
>> + struct efi_unicode_collation_protocol *this,
>> + efi_string_t string,
>> + efi_uintn_t fat_size,
>> + uint8_t *fat);
>> + uint8_t *supported_languages;
>> +};
>> +
>> #define EFI_GOP_GUID \
>> EFI_GUID(0x9042a9de, 0x23dc, 0x4a38, \
>>0x96, 0xfb, 0x7a, 0xde, 0xd0, 0x80, 0x51, 0x6a)
>> diff --git a/include/efi_loader.h b/include/efi_loader.h
>> index 591bf07e7a..af6812b2b4 100644
>> --- a/include/efi_loader.h
>> +++ b/include/efi_loader.h
>> @@ -83,6 +83,7 @@ extern const struct efi_device_path_utilities_protocol
>> efi_device_path_utilities
>> extern const struct efi_hii_config_routing_protocol efi_hii_config_routing;
>> extern const struct efi_hii_database_protocol efi_hii_database;
>> extern const struct efi_hii_string_protocol efi_hii_string;
>> +extern const struct efi_unicode_collation_protocol efi_unicode_collation;
>>
>> uint16_t *efi_dp_str(struct efi_device_path *dp);
>>
>> @@ -97,6 +98,8 @@ extern const efi_guid_t
>> efi_guid_device_path_utilities_protocol;
>> extern const efi_guid_t efi_guid_hii_config_routing_protocol;
>> extern const efi_guid_t efi_guid_hii_database_protocol;
>> extern const efi_guid_t efi_guid_hii_string_protocol;
>> +extern const efi_guid_t efi_guid_unicode_collation_protocol;
>> +extern const efi_guid_t efi_guid_unicode_collation_protocol2;
>>
>> extern unsigned int __efi_runtime_start, __efi_runtime_stop;
>> extern unsigned int __efi_runtime_rel_start, __efi_runtime_rel_stop;
>> diff --git a/lib/efi_loader/Makefile b/lib/efi_loader/Makefile
>> index 725e0cba85..7ea96a4f1c 100644
>> --- a/lib/efi_loader/Makefile
>> +++ b/lib/efi_loader/Makefile
>> @@ -17,7 +17,7 @@ endif
>> obj-$(CONFIG_CMD_BOOTEFI_HELLO) += helloworld_efi.o
>> obj-y += efi_image_loader.o efi_boottime.o efi_runtime.o efi_console.o
>> obj-y += efi_memory.o efi_device_path_to_text.o efi_device_path.o
>> -obj-y += efi_device_path_utilities.o efi_hii.o
>> +obj-y += efi_de
Re: [U-Boot] [PATCH 11/11] efi_loader: exclude openrd devices
On Tue, Oct 10, 2017 at 6:28 PM, Heinrich Schuchardt wrote: > On 10/10/2017 02:23 PM, Rob Clark wrote: >> >> These devices have small image size limits, so exclude EFI_LOADER to >> help avoid exceeding limits. >> >> Signed-off-by: Rob Clark >> --- >> lib/efi_loader/Kconfig | 2 +- >> 1 file changed, 1 insertion(+), 1 deletion(-) >> >> diff --git a/lib/efi_loader/Kconfig b/lib/efi_loader/Kconfig >> index d2b6327119..6e22940da5 100644 >> --- a/lib/efi_loader/Kconfig >> +++ b/lib/efi_loader/Kconfig >> @@ -1,6 +1,6 @@ >> config EFI_LOADER >> bool "Support running EFI Applications in U-Boot" >> - depends on (ARM || X86) && OF_LIBFDT >> + depends on (ARM || X86) && OF_LIBFDT && !TARGET_OPENRD >> default y >> help >> Select this option if you want to run EFI applications (like >> grub2) >> > > I understand that with the progress we make on EFI implementation and other > parts of U-Boot the U-Boot image size is growing too big for direct loading > by the primary boot loader. > > The OPENRD boards have abundant memory, e.g. openrd_ultimate_defconfig > refers to a board with 512 MB RAM. > > So I think completely disabling EFI is not the solution. > Instead building an SPL should be enabled for this architecture when the > image is becoming too big for direct load. > > I am copying in the KIRKWOOD maintainers go get their view. > I'm defn open to alternatives.. I don't know too much about what the limit was on these boards, other than we were close to it before, and the additional uefi proto's add <4k to the image size, which was enough to push it over the limit. Since this was effecting only a few boards, I went with this.. if it is only a temporary fix that can be removed soon, or if someone can do something better with a separate SPL build in the near term, that would be great. BR, -R ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 09/11] efi_loader: Fix disk dp's for pre-DM/legacy devices
This fixes an issue with OpenBSD's bootloader, and I think should also
fix a similar issue with grub2 on legacy devices. In the legacy case
we were creating disk objects for the partitions, but not also the
parent device.
Reported-by: Jonathan Gray
Signed-off-by: Rob Clark
---
lib/efi_loader/efi_disk.c | 11 +++
1 file changed, 11 insertions(+)
diff --git a/lib/efi_loader/efi_disk.c b/lib/efi_loader/efi_disk.c
index eb9ce772d1..47b487aa30 100644
--- a/lib/efi_loader/efi_disk.c
+++ b/lib/efi_loader/efi_disk.c
@@ -340,6 +340,8 @@ int efi_disk_register(void)
for (i = 0; i < 4; i++) {
struct blk_desc *desc;
char devname[32] = { 0 }; /* dp->str is u16[32] long */
+ disk_partition_t info;
+ int part = 1;
desc = blk_get_devnum_by_type(if_type, i);
if (!desc)
@@ -349,6 +351,15 @@ int efi_disk_register(void)
snprintf(devname, sizeof(devname), "%s%d",
if_typename, i);
+
+ /* add devices for each partition: */
+ while (!part_get_info(desc, part, &info)) {
+ efi_disk_add_dev(devname, if_typename, desc,
+i, 0, part);
+ part++;
+ }
+
+ /* ... and add block device: */
efi_disk_add_dev(devname, if_typename, desc, i, 0, 0);
disks++;
--
2.13.6
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 05/11] efi_loader: console support for color attributes
Shell.efi uses this, and supporting color attributes makes things look
nicer. Map the EFI fg/bg color attributes to ANSI escape sequences.
Not all colors have a perfect match, but spec just says "Devices
supporting a different number of text colors are required to emulate the
above colors to the best of the device’s capabilities".
Signed-off-by: Rob Clark
---
include/efi_api.h| 33 +
lib/efi_loader/efi_console.c | 27 +--
2 files changed, 58 insertions(+), 2 deletions(-)
diff --git a/include/efi_api.h b/include/efi_api.h
index 58bf15b8e6..9610d03d47 100644
--- a/include/efi_api.h
+++ b/include/efi_api.h
@@ -427,6 +427,39 @@ struct simple_text_output_mode {
EFI_GUID(0x387477c2, 0x69c7, 0x11d2, \
0x8e, 0x39, 0x0, 0xa0, 0xc9, 0x69, 0x72, 0x3b)
+#define EFI_BLACK0x00
+#define EFI_BLUE 0x01
+#define EFI_GREEN0x02
+#define EFI_CYAN 0x03
+#define EFI_RED 0x04
+#define EFI_MAGENTA 0x05
+#define EFI_BROWN0x06
+#define EFI_LIGHTGRAY0x07
+#define EFI_BRIGHT 0x08
+#define EFI_DARKGRAY 0x08
+#define EFI_LIGHTBLUE0x09
+#define EFI_LIGHTGREEN 0x0a
+#define EFI_LIGHTCYAN0x0b
+#define EFI_LIGHTRED 0x0c
+#define EFI_LIGHTMAGENTA 0x0d
+#define EFI_YELLOW 0x0e
+#define EFI_WHITE0x0f
+#define EFI_BACKGROUND_BLACK 0x00
+#define EFI_BACKGROUND_BLUE 0x10
+#define EFI_BACKGROUND_GREEN 0x20
+#define EFI_BACKGROUND_CYAN 0x30
+#define EFI_BACKGROUND_RED 0x40
+#define EFI_BACKGROUND_MAGENTA 0x50
+#define EFI_BACKGROUND_BROWN 0x60
+#define EFI_BACKGROUND_LIGHTGRAY 0x70
+
+/* extract foreground color from EFI attribute */
+#define EFI_ATTR_FG(attr)((attr) & 0x07)
+/* treat high bit of FG as bright/bold (similar to edk2) */
+#define EFI_ATTR_BOLD(attr) (((attr) >> 3) & 0x01)
+/* extract background color from EFI attribute */
+#define EFI_ATTR_BG(attr)(((attr) >> 4) & 0x7)
+
struct efi_simple_text_output_protocol {
void *reset;
efi_status_t (EFIAPI *output_string)(
diff --git a/lib/efi_loader/efi_console.c b/lib/efi_loader/efi_console.c
index f508b79ab8..c25d6b16f2 100644
--- a/lib/efi_loader/efi_console.c
+++ b/lib/efi_loader/efi_console.c
@@ -316,14 +316,37 @@ static efi_status_t EFIAPI efi_cout_set_mode(
return EFI_EXIT(EFI_SUCCESS);
}
+static const struct {
+ unsigned fg;
+ unsigned bg;
+} color[] = {
+ { 30, 40 }, /* 0: black */
+ { 34, 44 }, /* 1: blue */
+ { 32, 42 }, /* 2: green */
+ { 36, 46 }, /* 3: cyan */
+ { 31, 41 }, /* 4: red */
+ { 35, 45 }, /* 5: magenta */
+ { 33, 43 }, /* 6: brown, map to yellow as edk2 does*/
+ { 37, 47 }, /* 7: light grey, map to white */
+};
+
+/* See EFI_SIMPLE_TEXT_OUTPUT_PROTOCOL.SetAttribute(). */
static efi_status_t EFIAPI efi_cout_set_attribute(
struct efi_simple_text_output_protocol *this,
unsigned long attribute)
{
+ unsigned int bold = EFI_ATTR_BOLD(attribute);
+ unsigned int fg = EFI_ATTR_FG(attribute);
+ unsigned int bg = EFI_ATTR_BG(attribute);
+
EFI_ENTRY("%p, %lx", this, attribute);
- /* Just ignore attributes (colors) for now */
- return EFI_EXIT(EFI_UNSUPPORTED);
+ if (attribute)
+ printf(ESC"[%u;%u;%um", bold, color[fg].fg, color[bg].bg);
+ else
+ printf(ESC"[0;37;40m");
+
+ return EFI_EXIT(EFI_SUCCESS);
}
static efi_status_t EFIAPI efi_cout_clear_screen(
--
2.13.6
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 04/11] efi_loader: SIMPLE_TEXT_INPUT_EX plus wire up objects properly
We need the _EX version for SCT.. and we need to wire up the
corresponding objects in the systab properly, as well as dealing
with the console_in object advertising multiple protocols.
Signed-off-by: Rob Clark
---
include/efi_api.h | 61 +-
include/efi_loader.h | 10 +-
lib/efi_loader/efi_boottime.c | 3 +
lib/efi_loader/efi_console.c | 264 +++---
4 files changed, 308 insertions(+), 30 deletions(-)
diff --git a/include/efi_api.h b/include/efi_api.h
index 38dd1240c1..58bf15b8e6 100644
--- a/include/efi_api.h
+++ b/include/efi_api.h
@@ -243,11 +243,11 @@ struct efi_system_table {
struct efi_table_hdr hdr;
unsigned long fw_vendor; /* physical addr of wchar_t vendor string */
u32 fw_revision;
- unsigned long con_in_handle;
+ efi_handle_t con_in_handle;
struct efi_simple_input_interface *con_in;
- unsigned long con_out_handle;
+ efi_handle_t con_out_handle;
struct efi_simple_text_output_protocol *con_out;
- unsigned long stderr_handle;
+ efi_handle_t stderr_handle;
struct efi_simple_text_output_protocol *std_err;
struct efi_runtime_services *runtime;
struct efi_boot_services *boottime;
@@ -474,6 +474,61 @@ struct efi_simple_input_interface {
struct efi_event *wait_for_key;
};
+
+#define EFI_SIMPLE_TEXT_INPUT_EX_PROTOCOL_GUID \
+ EFI_GUID(0xdd9e7534, 0x7762, 0x4698, \
+0x8c, 0x14, 0xf5, 0x85, 0x17, 0xa6, 0x25, 0xaa)
+
+/* key-shift state: */
+#define EFI_SHIFT_STATE_VALID 0x8000
+#define EFI_RIGHT_SHIFT_PRESSED 0x0001
+#define EFI_LEFT_SHIFT_PRESSED0x0002
+#define EFI_RIGHT_CONTROL_PRESSED 0x0004
+#define EFI_LEFT_CONTROL_PRESSED 0x0008
+#define EFI_RIGHT_ALT_PRESSED 0x0010
+#define EFI_EFI_LEFT_ALT_PRESSED 0x0020
+#define EFI_RIGHT_LOGO_PRESSED0x0040
+#define EFI_LEFT_LOGO_PRESSED 0x0080
+#define EFI_MENU_KEY_PRESSED 0x0100
+#define EFI_SYS_REQ_PRESSED 0x0200
+
+/* key-toggle state: */
+#define EFI_TOGGLE_STATE_VALID 0x80
+#define EFI_SCROLL_LOCK_ACTIVE 0x01
+#define EFI_NUM_LOCK_ACTIVE0x02
+#define EFI_CAPS_LOCK_ACTIVE 0x04
+
+struct efi_key_state {
+ uint32_t key_shift_state;
+ uint8_t key_toggle_state;
+};
+
+struct efi_key_data {
+ struct efi_input_key key;
+ struct efi_key_state key_state;
+};
+
+struct efi_simple_text_input_ex_interface {
+ efi_status_t (EFIAPI *reset)(
+ struct efi_simple_text_input_ex_interface *this,
+ bool ExtendedVerification);
+ efi_status_t (EFIAPI *read_key_stroke)(
+ struct efi_simple_text_input_ex_interface *this,
+ struct efi_key_data *key_data);
+ struct efi_event *wait_for_key;
+ efi_status_t (EFIAPI *set_state)(
+ struct efi_simple_text_input_ex_interface *this,
+ uint8_t key_toggle_state);
+ efi_status_t (EFIAPI *register_key_notify)(
+ struct efi_simple_text_input_ex_interface *this,
+ struct efi_key_data *key_data,
+ efi_status_t (EFIAPI *notify_fn)(struct efi_key_data
*key_data),
+ efi_handle_t *notify_handle);
+ efi_status_t (EFIAPI *unregister_key_notify)(
+ struct efi_simple_text_input_ex_interface *this,
+ efi_handle_t notify_handle);
+};
+
#define CONSOLE_CONTROL_GUID \
EFI_GUID(0xf42f7782, 0x12e, 0x4c12, \
0x99, 0x56, 0x49, 0xf9, 0x43, 0x4, 0xf7, 0x21)
diff --git a/include/efi_loader.h b/include/efi_loader.h
index af6812b2b4..e6e55d2cb4 100644
--- a/include/efi_loader.h
+++ b/include/efi_loader.h
@@ -75,7 +75,9 @@ const char *__efi_nesting_dec(void);
extern struct efi_runtime_services efi_runtime_services;
extern struct efi_system_table systab;
+extern struct efi_object efi_console_output_obj;
extern const struct efi_simple_text_output_protocol efi_con_out;
+extern struct efi_object efi_console_input_obj;
extern struct efi_simple_input_interface efi_con_in;
extern const struct efi_console_control_protocol efi_console_control;
extern const struct efi_device_path_to_text_protocol efi_device_path_to_text;
@@ -129,14 +131,6 @@ struct efi_object {
void *handle;
};
-#define EFI_PROTOCOL_OBJECT(_guid, _protocol) (struct efi_object){ \
- .protocols = {{ \
- .guid = &(_guid), \
- .protocol_interface = (void *)(_protocol), \
- }}, \
- .handle = (void *)(_protocol), \
-}
-
/**
* struct efi_event
*
diff --git a/lib/efi_loader/efi_boottime.c b/lib/efi_loader/efi_boottime.c
i
[U-Boot] [PATCH 07/11] efi_loader: fix events
An event can be created with type==0, Shell.efi does this for an event
that is set when Ctrl-C is typed. So our current approach of having a
fixed set of timer slots, and determining which slots are unused by
type==0 doesn't work so well. But we don't have any particularly good
reason to have a fixed table of events, so just dynamically allocate
them and keep a list.
Also fixes an incorrect implementation of CheckEvent() which was (a)
incorrectly returning an error if type==0, and (b) didn't handle the
case of an unsignaled event with a notify callback.
With these fixes (plus implementation of SIMPLE_TEXT_INPUT_EX protocol),
Ctrl-C works in Shell.efi.
Signed-off-by: Rob Clark
---
include/efi_loader.h | 1 +
lib/efi_loader/efi_boottime.c | 217 +-
2 files changed, 111 insertions(+), 107 deletions(-)
diff --git a/include/efi_loader.h b/include/efi_loader.h
index e6e55d2cb4..2232caca44 100644
--- a/include/efi_loader.h
+++ b/include/efi_loader.h
@@ -154,6 +154,7 @@ struct efi_event {
enum efi_timer_delay trigger_type;
bool is_queued;
bool is_signaled;
+ struct list_head link;
};
diff --git a/lib/efi_loader/efi_boottime.c b/lib/efi_loader/efi_boottime.c
index 39dcc72648..19fafe546c 100644
--- a/lib/efi_loader/efi_boottime.c
+++ b/lib/efi_loader/efi_boottime.c
@@ -350,11 +350,26 @@ static efi_status_t efi_create_handle(void **handle)
return r;
}
+static LIST_HEAD(efi_events);
+
/*
- * Our event capabilities are very limited. Only a small limited
- * number of events is allowed to coexist.
+ * Check if a pointer is a valid event.
+ *
+ * It might be nice at some point to extend this to a more general
+ * mechanism to check if pointers passed from the EFI world are
+ * valid objects of a particular type.
*/
-static struct efi_event efi_events[16];
+static bool efi_is_event(const void *obj)
+{
+ struct efi_event *evt;
+
+ list_for_each_entry(evt, &efi_events, link) {
+ if (evt == obj)
+ return true;
+ }
+
+ return false;
+}
/*
* Create an event.
@@ -377,7 +392,7 @@ efi_status_t efi_create_event(uint32_t type, UINTN
notify_tpl,
void *context),
void *notify_context, struct efi_event **event)
{
- int i;
+ struct efi_event *evt;
if (event == NULL)
return EFI_INVALID_PARAMETER;
@@ -389,21 +404,24 @@ efi_status_t efi_create_event(uint32_t type, UINTN
notify_tpl,
notify_function == NULL)
return EFI_INVALID_PARAMETER;
- for (i = 0; i < ARRAY_SIZE(efi_events); ++i) {
- if (efi_events[i].type)
- continue;
- efi_events[i].type = type;
- efi_events[i].notify_tpl = notify_tpl;
- efi_events[i].notify_function = notify_function;
- efi_events[i].notify_context = notify_context;
- /* Disable timers on bootup */
- efi_events[i].trigger_next = -1ULL;
- efi_events[i].is_queued = false;
- efi_events[i].is_signaled = false;
- *event = &efi_events[i];
- return EFI_SUCCESS;
- }
- return EFI_OUT_OF_RESOURCES;
+ evt = calloc(1, sizeof(*evt));
+ if (!evt)
+ return EFI_OUT_OF_RESOURCES;
+
+ evt->type = type;
+ evt->notify_tpl = notify_tpl;
+ evt->notify_function = notify_function;
+ evt->notify_context = notify_context;
+ /* Disable timers on bootup */
+ evt->trigger_next = -1ULL;
+ evt->is_queued = false;
+ evt->is_signaled = false;
+
+ list_add_tail(&evt->link, &efi_events);
+
+ *event = evt;
+
+ return EFI_SUCCESS;
}
/*
@@ -443,30 +461,31 @@ static efi_status_t EFIAPI efi_create_event_ext(
*/
void efi_timer_check(void)
{
- int i;
+ struct efi_event *evt;
u64 now = timer_get_us();
- for (i = 0; i < ARRAY_SIZE(efi_events); ++i) {
- if (!efi_events[i].type)
- continue;
- if (efi_events[i].is_queued)
- efi_signal_event(&efi_events[i]);
- if (!(efi_events[i].type & EVT_TIMER) ||
- now < efi_events[i].trigger_next)
+ /*
+* TODO perhaps optimize a bit and track the time of next
+* timer to expire?
+*/
+ list_for_each_entry(evt, &efi_events, link) {
+ if (evt->is_queued)
+ efi_signal_event(evt);
+ if (!(evt->type & EVT_TIMER) ||
+ now < evt->trigger_next)
continue;
- switch (efi_events[i].trigger_type) {
+ switch (evt->trigger_type) {
[U-Boot] [PATCH 11/11] efi_loader: exclude openrd devices
These devices have small image size limits, so exclude EFI_LOADER to help avoid exceeding limits. Signed-off-by: Rob Clark --- lib/efi_loader/Kconfig | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/lib/efi_loader/Kconfig b/lib/efi_loader/Kconfig index d2b6327119..6e22940da5 100644 --- a/lib/efi_loader/Kconfig +++ b/lib/efi_loader/Kconfig @@ -1,6 +1,6 @@ config EFI_LOADER bool "Support running EFI Applications in U-Boot" - depends on (ARM || X86) && OF_LIBFDT + depends on (ARM || X86) && OF_LIBFDT && !TARGET_OPENRD default y help Select this option if you want to run EFI applications (like grub2) -- 2.13.6 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 08/11] efi_loader: implement SetWatchdogTimer
From: Heinrich Schuchardt
The watchdog is initialized with a 5 minute timeout period.
It can be reset by SetWatchdogTimer.
It is stopped by ExitBoottimeServices.
Signed-off-by: Heinrich Schuchardt
---
cmd/bootefi.c | 1 +
include/efi_loader.h | 4 ++
lib/efi_loader/Makefile | 2 +-
lib/efi_loader/efi_boottime.c | 17 ++---
lib/efi_loader/efi_watchdog.c | 86 +++
5 files changed, 95 insertions(+), 15 deletions(-)
create mode 100644 lib/efi_loader/efi_watchdog.c
diff --git a/cmd/bootefi.c b/cmd/bootefi.c
index b7087e3da8..24958ada46 100644
--- a/cmd/bootefi.c
+++ b/cmd/bootefi.c
@@ -43,6 +43,7 @@ static void efi_init_obj_list(void)
#ifdef CONFIG_GENERATE_SMBIOS_TABLE
efi_smbios_register();
#endif
+ efi_watchdog_register();
/* Initialize EFI runtime services */
efi_reset_system_init();
diff --git a/include/efi_loader.h b/include/efi_loader.h
index 2232caca44..fa4e1cdb1c 100644
--- a/include/efi_loader.h
+++ b/include/efi_loader.h
@@ -169,6 +169,8 @@ int efi_disk_register(void);
int efi_gop_register(void);
/* Called by bootefi to make the network interface available */
int efi_net_register(void);
+/* Called by bootefi to make the watchdog available */
+int efi_watchdog_register(void);
/* Called by bootefi to make SMBIOS tables available */
void efi_smbios_register(void);
@@ -177,6 +179,8 @@ efi_fs_from_path(struct efi_device_path *fp);
/* Called by networking code to memorize the dhcp ack package */
void efi_net_set_dhcp_ack(void *pkt, int len);
+/* Called by efi_set_watchdog_timer to reset the timer */
+efi_status_t efi_set_watchdog(unsigned long timeout);
/* Called from places to check whether a timer expired */
void efi_timer_check(void);
diff --git a/lib/efi_loader/Makefile b/lib/efi_loader/Makefile
index 7ea96a4f1c..4238cf9f9b 100644
--- a/lib/efi_loader/Makefile
+++ b/lib/efi_loader/Makefile
@@ -18,7 +18,7 @@ obj-$(CONFIG_CMD_BOOTEFI_HELLO) += helloworld_efi.o
obj-y += efi_image_loader.o efi_boottime.o efi_runtime.o efi_console.o
obj-y += efi_memory.o efi_device_path_to_text.o efi_device_path.o
obj-y += efi_device_path_utilities.o efi_hii.o efi_unicode.o
-obj-y += efi_file.o efi_variable.o efi_bootmgr.o
+obj-y += efi_file.o efi_variable.o efi_bootmgr.o efi_watchdog.o
obj-$(CONFIG_LCD) += efi_gop.o
obj-$(CONFIG_DM_VIDEO) += efi_gop.o
obj-$(CONFIG_PARTITIONS) += efi_disk.o
diff --git a/lib/efi_loader/efi_boottime.c b/lib/efi_loader/efi_boottime.c
index 19fafe546c..310f0a3b62 100644
--- a/lib/efi_loader/efi_boottime.c
+++ b/lib/efi_loader/efi_boottime.c
@@ -156,18 +156,6 @@ void efi_signal_event(struct efi_event *event)
}
/*
- * Write a debug message for an EPI API service that is not implemented yet.
- *
- * @funcname function that is not yet implemented
- * @return EFI_UNSUPPORTED
- */
-static efi_status_t efi_unsupported(const char *funcname)
-{
- debug("EFI: App called into unimplemented function %s\n", funcname);
- return EFI_EXIT(EFI_UNSUPPORTED);
-}
-
-/*
* Raise the task priority level.
*
* This function implements the RaiseTpl service.
@@ -1470,6 +1458,7 @@ static efi_status_t EFIAPI efi_exit_boot_services(void
*image_handle,
bootm_disable_interrupts();
/* Give the payload some time to boot */
+ efi_set_watchdog(0);
WATCHDOG_RESET();
return EFI_EXIT(EFI_SUCCESS);
@@ -1513,7 +1502,7 @@ static efi_status_t EFIAPI efi_stall(unsigned long
microseconds)
/*
* Reset the watchdog timer.
*
- * This function implements the WatchdogTimer service.
+ * This function implements the SetWatchdogTimer service.
* See the Unified Extensible Firmware Interface (UEFI) specification
* for details.
*
@@ -1529,7 +1518,7 @@ static efi_status_t EFIAPI
efi_set_watchdog_timer(unsigned long timeout,
{
EFI_ENTRY("%ld, 0x%"PRIx64", %ld, %p", timeout, watchdog_code,
data_size, watchdog_data);
- return efi_unsupported(__func__);
+ return EFI_EXIT(efi_set_watchdog(timeout));
}
/*
diff --git a/lib/efi_loader/efi_watchdog.c b/lib/efi_loader/efi_watchdog.c
new file mode 100644
index 00..eb437faf4b
--- /dev/null
+++ b/lib/efi_loader/efi_watchdog.c
@@ -0,0 +1,86 @@
+/*
+ * EFI watchdog
+ *
+ * Copyright (c) 2017 Heinrich Schuchardt
+ *
+ * SPDX-License-Identifier: GPL-2.0+
+ */
+
+#include
+#include
+
+static struct efi_event *watchdog_timer_event;
+
+/*
+ * Reset the system when the watchdog event is notified.
+ *
+ * @event: the watchdog event
+ * @context: not used
+ */
+static void EFIAPI efi_watchdog_timer_notify(struct efi_event *event,
+void *context)
+{
+ EFI_ENTRY("%p, %p", event, context);
+
+ printf("\nEFI: Watchdog timeout\n");
+ EFI_CALL_VOID(efi_runtime_services.reset_system(EFI_RESET_COLD,
+ EFI_SUCCESS, 0, NULL));
+
+
[U-Boot] [PATCH 06/11] efi_loader: Decouple EFI input/output from stdin/stdout
In some cases, it is quite useful to have (for example) EFI on screen
but u-boot on serial port.
This adds two new optional environment variables, "efiin" and "efiout",
which can be used to set EFI console input/output independently of
u-boot's input/output. If unset, EFI console will default to stdin/
stdout as before.
Signed-off-by: Rob Clark
---
As mentioned yesterday, this triggers some problems w/ qemu + 'bootefi
hello' since puts() != fputs(stdout). So you can hold off applying
this one for now if you want until we figure out a solution. It is
not strictly required, only nice-to-have (and nice for enabling debug
traces on serial without interfering with Shell.efi output on screen)
lib/efi_loader/efi_console.c | 111 ---
1 file changed, 82 insertions(+), 29 deletions(-)
diff --git a/lib/efi_loader/efi_console.c b/lib/efi_loader/efi_console.c
index c25d6b16f2..1333f9cb71 100644
--- a/lib/efi_loader/efi_console.c
+++ b/lib/efi_loader/efi_console.c
@@ -47,6 +47,38 @@ static struct cout_mode efi_cout_modes[] = {
const efi_guid_t efi_guid_console_control = CONSOLE_CONTROL_GUID;
+static struct stdio_dev *efiin, *efiout;
+
+static int efi_tstc(void)
+{
+ return efiin->tstc(efiin);
+}
+
+static int efi_getc(void)
+{
+ return efiin->getc(efiin);
+}
+
+static int efi_printf(const char *fmt, ...)
+{
+ va_list args;
+ uint i;
+ char printbuffer[CONFIG_SYS_PBSIZE];
+
+ va_start(args, fmt);
+
+ /*
+* For this to work, printbuffer must be larger than
+* anything we ever want to print.
+*/
+ i = vsnprintf(printbuffer, sizeof(printbuffer), fmt, args);
+ va_end(args);
+
+ /* Print the string */
+ efiout->puts(efiout, printbuffer);
+ return i;
+}
+
#define cESC '\x1b'
#define ESC "\x1b"
@@ -111,16 +143,16 @@ static int term_read_reply(int *n, int maxnum, char
end_char)
char c;
int i = 0;
- c = getc();
+ c = efi_getc();
if (c != cESC)
return -1;
- c = getc();
+ c = efi_getc();
if (c != '[')
return -1;
n[0] = 0;
while (1) {
- c = getc();
+ c = efi_getc();
if (c == ';') {
i++;
if (i >= maxnum)
@@ -164,7 +196,7 @@ static efi_status_t EFIAPI efi_cout_output_string(
*utf16_to_utf8((u8 *)buf, string, n16) = '\0';
- fputs(stdout, buf);
+ efiout->puts(efiout, buf);
for (p = buf; *p; p++) {
switch (*p) {
@@ -217,14 +249,14 @@ static int query_console_serial(int *rows, int *cols)
u64 timeout;
/* Empty input buffer */
- while (tstc())
- getc();
+ while (efi_tstc())
+ efi_getc();
- printf(ESC"[18t");
+ efi_printf(ESC"[18t");
/* Check if we have a terminal that understands */
timeout = timer_get_us() + 100;
- while (!tstc())
+ while (!efi_tstc())
if (timer_get_us() > timeout)
return -1;
@@ -246,16 +278,13 @@ static efi_status_t EFIAPI efi_cout_query_mode(
EFI_ENTRY("%p, %ld, %p, %p", this, mode_number, columns, rows);
if (!console_size_queried) {
- const char *stdout_name = env_get("stdout");
int rows, cols;
console_size_queried = true;
- if (stdout_name && !strcmp(stdout_name, "vidconsole") &&
+ if (!strcmp(efiout->name, "vidconsole") &&
IS_ENABLED(CONFIG_DM_VIDEO)) {
- struct stdio_dev *stdout_dev =
- stdio_get_by_name("vidconsole");
- struct udevice *dev = stdout_dev->priv;
+ struct udevice *dev = efiout->priv;
struct vidconsole_priv *priv =
dev_get_uclass_priv(dev);
rows = priv->rows;
@@ -342,9 +371,9 @@ static efi_status_t EFIAPI efi_cout_set_attribute(
EFI_ENTRY("%p, %lx", this, attribute);
if (attribute)
- printf(ESC"[%u;%u;%um", bold, color[fg].fg, color[bg].bg);
+ efi_printf(ESC"[%u;%u;%um", bold, color[fg].fg, color[bg].bg);
else
- printf(ESC"[0;37;40m");
+ efi_printf(ESC"[0;37;40m");
return EFI_EXIT(EFI_SUCCESS);
}
@@ -354,7 +383,7 @@ static efi_status_t EFIAPI efi_cout_clear_screen(
{
EFI_ENTRY("%p", this);
- printf(ESC"[2J");
+ efi_printf(ESC"[2J");
return EFI_EXIT(EFI_SUCCESS);
}
[U-Boot] [PATCH 10/11] efi_loader: Add mem-mapped for fallback
When we don't have a real device/image path, such as 'bootefi hello',
construct a mem-mapped device-path.
This fixes 'bootefi hello' after devicepath refactoring.
Fixes: 95c5553ea2 ("efi_loader: refactor boot device and loaded_image handling")
Signed-off-by: Rob Clark
---
cmd/bootefi.c| 23 +++
include/efi_api.h| 8
include/efi_loader.h | 3 +++
lib/efi_loader/efi_device_path.c | 24
lib/efi_loader/efi_device_path_to_text.c | 9 +
5 files changed, 67 insertions(+)
diff --git a/cmd/bootefi.c b/cmd/bootefi.c
index 24958ada46..18176a1266 100644
--- a/cmd/bootefi.c
+++ b/cmd/bootefi.c
@@ -128,6 +128,7 @@ static unsigned long do_bootefi_exec(void *efi, void *fdt,
{
struct efi_loaded_image loaded_image_info = {};
struct efi_object loaded_image_info_obj = {};
+ struct efi_device_path *memdp = NULL;
ulong ret;
ulong (*entry)(void *image_handle, struct efi_system_table *st)
@@ -136,6 +137,20 @@ static unsigned long do_bootefi_exec(void *efi, void *fdt,
const efi_guid_t fdt_guid = EFI_FDT_GUID;
bootm_headers_t img = { 0 };
+ /*
+* Special case for efi payload not loaded from disk, such as
+* 'bootefi hello' or for example payload loaded directly into
+* memory via jtag/etc:
+*/
+ if (!device_path && !image_path) {
+ printf("WARNING: using memory device/image path, this may
confuse some payloads!\n");
+ /* actual addresses filled in after efi_load_pe() */
+ memdp = efi_dp_from_mem(0, 0, 0);
+ device_path = image_path = memdp;
+ } else {
+ assert(device_path && image_path);
+ }
+
/* Initialize and populate EFI object list */
if (!efi_obj_list_initalized)
efi_init_obj_list();
@@ -182,6 +197,14 @@ static unsigned long do_bootefi_exec(void *efi, void *fdt,
goto exit;
}
+ if (memdp) {
+ struct efi_device_path_memory *mdp = (void *)memdp;
+ mdp->memory_type = loaded_image_info.image_code_type;
+ mdp->start_address = (uintptr_t)loaded_image_info.image_base;
+ mdp->end_address = mdp->start_address +
+ loaded_image_info.image_size;
+ }
+
/* we don't support much: */
env_set("efi_8be4df61-93ca-11d2-aa0d-00e098032b8c_OsIndicationsSupported",
"{ro,boot}(blob)");
diff --git a/include/efi_api.h b/include/efi_api.h
index 9610d03d47..07b2af7020 100644
--- a/include/efi_api.h
+++ b/include/efi_api.h
@@ -299,8 +299,16 @@ struct efi_mac_addr {
} __packed;
#define DEVICE_PATH_TYPE_HARDWARE_DEVICE 0x01
+# define DEVICE_PATH_SUB_TYPE_MEMORY 0x03
# define DEVICE_PATH_SUB_TYPE_VENDOR 0x04
+struct efi_device_path_memory {
+ struct efi_device_path dp;
+ u32 memory_type;
+ u64 start_address;
+ u64 end_address;
+} __packed;
+
struct efi_device_path_vendor {
struct efi_device_path dp;
efi_guid_t guid;
diff --git a/include/efi_loader.h b/include/efi_loader.h
index fa4e1cdb1c..db805e898f 100644
--- a/include/efi_loader.h
+++ b/include/efi_loader.h
@@ -269,6 +269,9 @@ struct efi_device_path *efi_dp_from_part(struct blk_desc
*desc, int part);
struct efi_device_path *efi_dp_from_file(struct blk_desc *desc, int part,
const char *path);
struct efi_device_path *efi_dp_from_eth(void);
+struct efi_device_path *efi_dp_from_mem(uint32_t mem_type,
+ uint64_t start_address,
+ uint64_t end_address);
void efi_dp_split_file_path(struct efi_device_path *full_path,
struct efi_device_path **device_path,
struct efi_device_path **file_path);
diff --git a/lib/efi_loader/efi_device_path.c b/lib/efi_loader/efi_device_path.c
index 5d5c3b3464..f6e368e029 100644
--- a/lib/efi_loader/efi_device_path.c
+++ b/lib/efi_loader/efi_device_path.c
@@ -538,6 +538,30 @@ struct efi_device_path *efi_dp_from_eth(void)
}
#endif
+/* Construct a device-path for memory-mapped image */
+struct efi_device_path *efi_dp_from_mem(uint32_t memory_type,
+ uint64_t start_address,
+ uint64_t end_address)
+{
+ struct efi_device_path_memory *mdp;
+ void *buf, *start;
+
+ start = buf = dp_alloc(sizeof(*mdp) + sizeof(END));
+
+ mdp = buf;
+ mdp->dp.type = DEVICE_PATH_TYPE_HARDWARE_DEVICE;
+ mdp->dp.sub_type = DEVICE_PATH_SUB_TYPE_MEMORY;
+ mdp->dp.length = sizeof(*mdp);
+ mdp->me
[U-Boot] [PATCH 02/11] efi_loader: Initial HII protocols
From: Leif Lindholm
Enough implementation of the following protocols to run Shell.efi and
SCT.efi:
EfiHiiConfigRoutingProtocolGuid
EfiHiiDatabaseProtocol
EfiHiiStringProtocol
We'll fill in the rest once SCT is running properly so we can validate
the implementation against the conformance test suite.
Initial skeleton written by Leif, and then implementation by myself.
Cc: Leif Lindholm
Signed-off-by: Rob Clark
---
include/efi_api.h | 261 ++
include/efi_loader.h | 6 +
lib/efi_loader/Makefile | 2 +-
lib/efi_loader/efi_boottime.c | 9 +
lib/efi_loader/efi_hii.c | 507 ++
5 files changed, 784 insertions(+), 1 deletion(-)
create mode 100644 lib/efi_loader/efi_hii.c
diff --git a/include/efi_api.h b/include/efi_api.h
index ffdba7fe1a..164147dc87 100644
--- a/include/efi_api.h
+++ b/include/efi_api.h
@@ -16,6 +16,7 @@
#define _EFI_API_H
#include
+#include
#ifdef CONFIG_EFI_LOADER
#include
@@ -536,6 +537,266 @@ struct efi_device_path_utilities_protocol {
uint16_t node_length);
};
+#define EFI_HII_CONFIG_ROUTING_PROTOCOL_GUID \
+ EFI_GUID(0x587e72d7, 0xcc50, 0x4f79, \
+0x82, 0x09, 0xca, 0x29, 0x1f, 0xc1, 0xa1, 0x0f)
+
+typedef uint16_t efi_string_id_t;
+
+struct efi_hii_config_routing_protocol {
+ efi_status_t(EFIAPI *extract_config)(
+ const struct efi_hii_config_routing_protocol *this,
+ const efi_string_t request,
+ efi_string_t *progress,
+ efi_string_t *results);
+ efi_status_t(EFIAPI *export_config)(
+ const struct efi_hii_config_routing_protocol *this,
+ efi_string_t *results);
+ efi_status_t(EFIAPI *route_config)(
+ const struct efi_hii_config_routing_protocol *this,
+ const efi_string_t configuration,
+ efi_string_t *progress);
+ efi_status_t(EFIAPI *block_to_config)(
+ const struct efi_hii_config_routing_protocol *this,
+ const efi_string_t config_request,
+ const uint8_t *block,
+ const efi_uintn_t block_size,
+ efi_string_t *config,
+ efi_string_t *progress);
+ efi_status_t(EFIAPI *config_to_block)(
+ const struct efi_hii_config_routing_protocol *this,
+ const efi_string_t config_resp,
+ const uint8_t *block,
+ const efi_uintn_t *block_size,
+ efi_string_t *progress);
+ efi_status_t(EFIAPI *get_alt_config)(
+ const struct efi_hii_config_routing_protocol *this,
+ const efi_string_t config_resp,
+ const efi_guid_t *guid,
+ const efi_string_t name,
+ const struct efi_device_path *device_path,
+ const efi_string_t alt_cfg_id,
+ efi_string_t *alt_cfg_resp);
+};
+
+#define EFI_HII_DATABASE_PROTOCOL_GUID \
+ EFI_GUID(0xef9fc172, 0xa1b2, 0x4693, \
+0xb3, 0x27, 0x6d, 0x32, 0xfc, 0x41, 0x60, 0x42)
+
+typedef enum {
+ EFI_KEY_LCTRL, EFI_KEY_A0, EFI_KEY_LALT, EFI_KEY_SPACE_BAR,
+ EFI_KEY_A2, EFI_KEY_A3, EFI_KEY_A4, EFI_KEY_RCTRL, EFI_KEY_LEFT_ARROW,
+ EFI_KEY_DOWN_ARROW, EFI_KEY_RIGHT_ARROW, EFI_KEY_ZERO,
+ EFI_KEY_PERIOD, EFI_KEY_ENTER, EFI_KEY_LSHIFT, EFI_KEY_B0,
+ EFI_KEY_B1, EFI_KEY_B2, EFI_KEY_B3, EFI_KEY_B4, EFI_KEY_B5, EFI_KEY_B6,
+ EFI_KEY_B7, EFI_KEY_B8, EFI_KEY_B9, EFI_KEY_B10, EFI_KEY_RSHIFT,
+ EFI_KEY_UP_ARROW, EFI_KEY_ONE, EFI_KEY_TWO, EFI_KEY_THREE,
+ EFI_KEY_CAPS_LOCK, EFI_KEY_C1, EFI_KEY_C2, EFI_KEY_C3, EFI_KEY_C4,
+ EFI_KEY_C5, EFI_KEY_C6, EFI_KEY_C7, EFI_KEY_C8, EFI_KEY_C9,
+ EFI_KEY_C10, EFI_KEY_C11, EFI_KEY_C12, EFI_KEY_FOUR, EFI_KEY_FIVE,
+ EFI_KEY_SIX, EFI_KEY_PLUS, EFI_KEY_TAB, EFI_KEY_D1, EFI_KEY_D2,
+ EFI_KEY_D3, EFI_KEY_D4, EFI_KEY_D5, EFI_KEY_D6, EFI_KEY_D7, EFI_KEY_D8,
+ EFI_KEY_D9, EFI_KEY_D10, EFI_KEY_D11, EFI_KEY_D12, EFI_KEY_D13,
+ EFI_KEY_DEL, EFI_KEY_END, EFI_KEY_PG_DN, EFI_KEY_SEVEN, EFI_KEY_EIGHT,
+ EFI_KEY_NINE, EFI_KEY_E0, EFI_KEY_E1, EFI_KEY_E2, EFI_KEY_E3,
+ EFI_KEY_E4, EFI_KEY_E5, EFI_KEY_E6, EFI_KEY_E7, EFI_KEY_E8, EFI_KEY_E9,
+ EFI_KEY_E10, EFI_KEY_E11, EFI_KEY_E12, EFI_KEY_BACK_SPACE,
+ EFI_KEY_INS, EFI_KEY_HOME, EFI_KEY_PG_UP, EFI_KEY_NLCK, EFI_KEY_SLASH,
+ EFI_KEY_ASTERISK, EFI_KEY_MINUS, EFI_KEY_ESC, EFI_KEY_F1, EFI_KEY_F2,
+ EFI_KEY_F3, EFI_KEY_F4, EFI_KEY_F5, EFI_KEY_F6, EFI_KEY_F7, EFI_KEY_F8,
+ EFI_KEY_F9, EFI_KEY_F10, EFI_KEY_F11, EFI_KEY_F12, EFI_KEY_PRINT,
+ EFI_KEY_SLCK, EFI_KEY_PAUSE,
+} efi_key;
+
+struct efi_key_descriptor {
+ efi_key key;
+ uint16_t unicode;
+ uint16_t shifted_unicode;
+ uint16_t alt_gr_unicode;
+ uint16_t shifted_alt_gr_unicode;
+ uint16_t modifier;
+ uin
[U-Boot] [PATCH 03/11] efi_loader: Initial EFI_UNICODE_COLLATION_PROTOCOL
From: Leif Lindholm
Not complete, but enough for Shell.efi and SCT.efi.
Initial skeleton written by Leif, and then implementation by myself.
Cc: Leif Lindholm
Signed-off-by: Rob Clark
---
include/efi_api.h | 41 ++
include/efi_loader.h | 3 +
lib/efi_loader/Makefile | 2 +-
lib/efi_loader/efi_boottime.c | 6 ++
lib/efi_loader/efi_unicode.c | 170 ++
5 files changed, 221 insertions(+), 1 deletion(-)
create mode 100644 lib/efi_loader/efi_unicode.c
diff --git a/include/efi_api.h b/include/efi_api.h
index 164147dc87..38dd1240c1 100644
--- a/include/efi_api.h
+++ b/include/efi_api.h
@@ -797,6 +797,47 @@ struct efi_hii_string_protocol {
efi_uintn_t *secondary_languages_size);
};
+/*
+ * Both UNICODE_COLLATION protocols seem to be the same thing, but
+ * advertised with two different GUID's because, why not?
+ */
+
+#define EFI_UNICODE_COLLATION_PROTOCOL_GUID \
+ EFI_GUID(0x1d85cd7f, 0xf43d, 0x11d2, \
+0x9a, 0x0c, 0x00, 0x90, 0x27, 0x3f, 0xc1, 0x4d)
+
+#define EFI_UNICODE_COLLATION_PROTOCOL2_GUID \
+ EFI_GUID(0xa4c751fc, 0x23ae, 0x4c3e, \
+0x92, 0xe9, 0x49, 0x64, 0xcf, 0x63, 0xf3, 0x49)
+
+struct efi_unicode_collation_protocol {
+ efi_intn_t (EFIAPI *stri_coll)(
+ struct efi_unicode_collation_protocol *this,
+ efi_string_t s1,
+ efi_string_t s2);
+ bool (EFIAPI *metai_match)(
+ struct efi_unicode_collation_protocol *this,
+ efi_string_t string,
+ efi_string_t pattern);
+ void (EFIAPI *str_lwr)(
+ struct efi_unicode_collation_protocol *this,
+ efi_string_t string);
+ void (EFIAPI *str_upr)(
+ struct efi_unicode_collation_protocol *this,
+ efi_string_t string);
+ void (EFIAPI *fat_to_str)(
+ struct efi_unicode_collation_protocol *this,
+ efi_uintn_t fat_size,
+ uint8_t *fat,
+ efi_string_t string);
+ bool (EFIAPI *str_to_fat)(
+ struct efi_unicode_collation_protocol *this,
+ efi_string_t string,
+ efi_uintn_t fat_size,
+ uint8_t *fat);
+ uint8_t *supported_languages;
+};
+
#define EFI_GOP_GUID \
EFI_GUID(0x9042a9de, 0x23dc, 0x4a38, \
0x96, 0xfb, 0x7a, 0xde, 0xd0, 0x80, 0x51, 0x6a)
diff --git a/include/efi_loader.h b/include/efi_loader.h
index 591bf07e7a..af6812b2b4 100644
--- a/include/efi_loader.h
+++ b/include/efi_loader.h
@@ -83,6 +83,7 @@ extern const struct efi_device_path_utilities_protocol
efi_device_path_utilities
extern const struct efi_hii_config_routing_protocol efi_hii_config_routing;
extern const struct efi_hii_database_protocol efi_hii_database;
extern const struct efi_hii_string_protocol efi_hii_string;
+extern const struct efi_unicode_collation_protocol efi_unicode_collation;
uint16_t *efi_dp_str(struct efi_device_path *dp);
@@ -97,6 +98,8 @@ extern const efi_guid_t
efi_guid_device_path_utilities_protocol;
extern const efi_guid_t efi_guid_hii_config_routing_protocol;
extern const efi_guid_t efi_guid_hii_database_protocol;
extern const efi_guid_t efi_guid_hii_string_protocol;
+extern const efi_guid_t efi_guid_unicode_collation_protocol;
+extern const efi_guid_t efi_guid_unicode_collation_protocol2;
extern unsigned int __efi_runtime_start, __efi_runtime_stop;
extern unsigned int __efi_runtime_rel_start, __efi_runtime_rel_stop;
diff --git a/lib/efi_loader/Makefile b/lib/efi_loader/Makefile
index 725e0cba85..7ea96a4f1c 100644
--- a/lib/efi_loader/Makefile
+++ b/lib/efi_loader/Makefile
@@ -17,7 +17,7 @@ endif
obj-$(CONFIG_CMD_BOOTEFI_HELLO) += helloworld_efi.o
obj-y += efi_image_loader.o efi_boottime.o efi_runtime.o efi_console.o
obj-y += efi_memory.o efi_device_path_to_text.o efi_device_path.o
-obj-y += efi_device_path_utilities.o efi_hii.o
+obj-y += efi_device_path_utilities.o efi_hii.o efi_unicode.o
obj-y += efi_file.o efi_variable.o efi_bootmgr.o
obj-$(CONFIG_LCD) += efi_gop.o
obj-$(CONFIG_DM_VIDEO) += efi_gop.o
diff --git a/lib/efi_loader/efi_boottime.c b/lib/efi_loader/efi_boottime.c
index c179afc25a..b568f3f162 100644
--- a/lib/efi_loader/efi_boottime.c
+++ b/lib/efi_loader/efi_boottime.c
@@ -1166,6 +1166,12 @@ void efi_setup_loaded_image(struct efi_loaded_image
*info, struct efi_object *ob
obj->protocols[7].guid = &efi_guid_hii_config_routing_protocol;
obj->protocols[7].protocol_interface = (void *)&efi_hii_config_routing;
+ obj->protocols[8].guid = &efi_guid_unicode_collation_protocol;
+ obj->protocols[8].protocol_interface = (void *)&efi_unicode_collation;
+
+ obj->protocols[9].guid = &efi_guid_unicode_collation_protocol2;
+ obj->protocols[9].protocol_interface = (void *)&efi_unicode_collation;
+
info->
[U-Boot] [PATCH 01/11] efi_loader: Initial EFI_DEVICE_PATH_UTILITIES_PROTOCOL
From: Leif Lindholm
Not complete, but enough for Shell.efi and SCT.efi. We'll implement the
rest as needed or once we have SCT running properly so there is a way to
validate the interface against the conformance test suite.
Initial skeleton written by Leif, and then implementation by myself.
Cc: Leif Lindholm
Signed-off-by: Rob Clark
---
include/efi_api.h | 34 +++-
include/efi_loader.h | 2 +
lib/efi_loader/Makefile| 1 +
lib/efi_loader/efi_boottime.c | 4 ++
lib/efi_loader/efi_device_path_utilities.c | 88 ++
5 files changed, 127 insertions(+), 2 deletions(-)
create mode 100644 lib/efi_loader/efi_device_path_utilities.c
diff --git a/include/efi_api.h b/include/efi_api.h
index a9a6494afe..ffdba7fe1a 100644
--- a/include/efi_api.h
+++ b/include/efi_api.h
@@ -28,8 +28,9 @@ enum efi_timer_delay {
EFI_TIMER_RELATIVE = 2
};
-#define UINTN size_t
-typedef long INTN;
+#define UINTN size_t /* TODO this should be removed in a future patch */
+typedef size_t efi_uintn_t;
+typedef ssize_t efi_intn_t;
typedef uint16_t *efi_string_t;
#define EVT_TIMER 0x8000
@@ -506,6 +507,35 @@ struct efi_device_path_to_text_protocol
bool allow_shortcuts);
};
+#define EFI_DEVICE_PATH_UTILITIES_PROTOCOL_GUID \
+ EFI_GUID(0x0379be4e, 0xd706, 0x437d, \
+0xb0, 0x37, 0xed, 0xb8, 0x2f, 0xb7, 0x72, 0xa4)
+
+struct efi_device_path_utilities_protocol {
+ efi_uintn_t (EFIAPI *get_device_path_size)(
+ const struct efi_device_path *device_path);
+ struct efi_device_path *(EFIAPI *duplicate_device_path)(
+ const struct efi_device_path *device_path);
+ struct efi_device_path *(EFIAPI *append_device_path)(
+ const struct efi_device_path *src1,
+ const struct efi_device_path *src2);
+ struct efi_device_path *(EFIAPI *append_device_node)(
+ const struct efi_device_path *device_path,
+ const struct efi_device_path *device_node);
+ struct efi_device_path *(EFIAPI *append_device_path_instance)(
+ const struct efi_device_path *device_path,
+ const struct efi_device_path *device_path_instance);
+ struct efi_device_path *(EFIAPI *get_next_device_path_instance)(
+ struct efi_device_path **device_path_instance,
+ efi_uintn_t *device_path_instance_size);
+ bool (EFIAPI *is_device_path_multi_instance)(
+ const struct efi_device_path *device_path);
+ struct efi_device_path *(EFIAPI *create_device_node)(
+ uint8_t node_type,
+ uint8_t node_sub_type,
+ uint16_t node_length);
+};
+
#define EFI_GOP_GUID \
EFI_GUID(0x9042a9de, 0x23dc, 0x4a38, \
0x96, 0xfb, 0x7a, 0xde, 0xd0, 0x80, 0x51, 0x6a)
diff --git a/include/efi_loader.h b/include/efi_loader.h
index e1179b7dcd..5d37c1d75f 100644
--- a/include/efi_loader.h
+++ b/include/efi_loader.h
@@ -79,6 +79,7 @@ extern const struct efi_simple_text_output_protocol
efi_con_out;
extern struct efi_simple_input_interface efi_con_in;
extern const struct efi_console_control_protocol efi_console_control;
extern const struct efi_device_path_to_text_protocol efi_device_path_to_text;
+extern const struct efi_device_path_utilities_protocol
efi_device_path_utilities;
uint16_t *efi_dp_str(struct efi_device_path *dp);
@@ -89,6 +90,7 @@ extern const efi_guid_t efi_guid_loaded_image;
extern const efi_guid_t efi_guid_device_path_to_text_protocol;
extern const efi_guid_t efi_simple_file_system_protocol_guid;
extern const efi_guid_t efi_file_info_guid;
+extern const efi_guid_t efi_guid_device_path_utilities_protocol;
extern unsigned int __efi_runtime_start, __efi_runtime_stop;
extern unsigned int __efi_runtime_rel_start, __efi_runtime_rel_stop;
diff --git a/lib/efi_loader/Makefile b/lib/efi_loader/Makefile
index ddb978f650..b6927b3b84 100644
--- a/lib/efi_loader/Makefile
+++ b/lib/efi_loader/Makefile
@@ -17,6 +17,7 @@ endif
obj-$(CONFIG_CMD_BOOTEFI_HELLO) += helloworld_efi.o
obj-y += efi_image_loader.o efi_boottime.o efi_runtime.o efi_console.o
obj-y += efi_memory.o efi_device_path_to_text.o efi_device_path.o
+obj-y += efi_device_path_utilities.o
obj-y += efi_file.o efi_variable.o efi_bootmgr.o
obj-$(CONFIG_LCD) += efi_gop.o
obj-$(CONFIG_DM_VIDEO) += efi_gop.o
diff --git a/lib/efi_loader/efi_boottime.c b/lib/efi_loader/efi_boottime.c
index 976d5822f7..92c778fcca 100644
--- a/lib/efi_loader/efi_boottime.c
+++ b/lib/efi_loader/efi_boottime.c
@@ -1153,6 +1153,10 @@ void efi_setup_loaded_image(struct efi_loaded_image
*info, struct efi_object *ob
obj->protocols[3].protocol_interface =
(void *)&efi_device_path_to_text;
+ obj->protocols[4].guid = &efi_guid_device_path_utilities_pr
[U-Boot] [PATCH 00/11] efi_loader: patches for Shell.efi
Re-send of the patch series to get Shell.efi working, and almost get SCT.efi (the UEFI test suite) working. Since last time, I've updated to Heinrich's latest SetWatchdogTimer patch (as of yesterday evening), and adressed review comments on the three new sets of protocols added. Part of that, to avoid moving changes from my later patch that added implementation on top of Leif's initial stubs was done by simply squashing the patches together. Heinrich Schuchardt (1): efi_loader: implement SetWatchdogTimer Leif Lindholm (3): efi_loader: Initial EFI_DEVICE_PATH_UTILITIES_PROTOCOL efi_loader: Initial HII protocols efi_loader: Initial EFI_UNICODE_COLLATION_PROTOCOL Rob Clark (7): efi_loader: SIMPLE_TEXT_INPUT_EX plus wire up objects properly efi_loader: console support for color attributes efi_loader: Decouple EFI input/output from stdin/stdout efi_loader: fix events efi_loader: Fix disk dp's for pre-DM/legacy devices efi_loader: Add mem-mapped for fallback efi_loader: exclude openrd devices cmd/bootefi.c | 24 ++ include/efi_api.h | 438 - include/efi_loader.h | 29 +- lib/efi_loader/Kconfig | 2 +- lib/efi_loader/Makefile| 3 +- lib/efi_loader/efi_boottime.c | 256 --- lib/efi_loader/efi_console.c | 398 +++--- lib/efi_loader/efi_device_path.c | 24 ++ lib/efi_loader/efi_device_path_to_text.c | 9 + lib/efi_loader/efi_device_path_utilities.c | 88 + lib/efi_loader/efi_disk.c | 11 + lib/efi_loader/efi_hii.c | 507 + lib/efi_loader/efi_unicode.c | 170 ++ lib/efi_loader/efi_watchdog.c | 86 + 14 files changed, 1861 insertions(+), 184 deletions(-) create mode 100644 lib/efi_loader/efi_device_path_utilities.c create mode 100644 lib/efi_loader/efi_hii.c create mode 100644 lib/efi_loader/efi_unicode.c create mode 100644 lib/efi_loader/efi_watchdog.c -- 2.13.6 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] efi_loader: Decouple EFI input/output from stdin/stdout
On Mon, Sep 11, 2017 at 10:04 AM, Rob Clark wrote:
> In some cases, it is quite useful to have (for example) EFI on screen
> but u-boot on serial port.
>
> Signed-off-by: Rob Clark
> ---
> Applies on top of my previous efi_loader patchset.
>
> lib/efi_loader/efi_console.c | 104
> +--
> 1 file changed, 80 insertions(+), 24 deletions(-)
>
> diff --git a/lib/efi_loader/efi_console.c b/lib/efi_loader/efi_console.c
> index 139f7ea55b..e2b1b88ecf 100644
> --- a/lib/efi_loader/efi_console.c
> +++ b/lib/efi_loader/efi_console.c
> @@ -47,6 +47,38 @@ static struct cout_mode efi_cout_modes[] = {
>
> const efi_guid_t efi_guid_console_control = CONSOLE_CONTROL_GUID;
>
> +static struct stdio_dev *efiin, *efiout;
> +
> +static int efi_tstc(void)
> +{
> + return efiin->tstc(efiin);
> +}
> +
> +static int efi_getc(void)
> +{
> + return efiin->getc(efiin);
> +}
> +
> +static int efi_printf(const char *fmt, ...)
> +{
> + va_list args;
> + uint i;
> + char printbuffer[CONFIG_SYS_PBSIZE];
> +
> + va_start(args, fmt);
> +
> + /*
> +* For this to work, printbuffer must be larger than
> +* anything we ever want to print.
> +*/
> + i = vsnprintf(printbuffer, sizeof(printbuffer), fmt, args);
> + va_end(args);
> +
> + /* Print the string */
> + efiout->puts(efiout, printbuffer);
> + return i;
> +}
> +
> #define cESC '\x1b'
> #define ESC "\x1b"
>
> @@ -111,16 +143,16 @@ static int term_read_reply(int *n, int maxnum, char
> end_char)
> char c;
> int i = 0;
>
> - c = getc();
> + c = efi_getc();
> if (c != cESC)
> return -1;
> - c = getc();
> + c = efi_getc();
> if (c != '[')
> return -1;
>
> n[0] = 0;
> while (1) {
> - c = getc();
> + c = efi_getc();
> if (c == ';') {
> i++;
> if (i >= maxnum)
> @@ -164,7 +196,7 @@ static efi_status_t EFIAPI efi_cout_output_string(
>
> *utf16_to_utf8((u8 *)buf, string, n16) = '\0';
>
> - fputs(stdout, buf);
> + efiout->puts(efiout, buf);
>
> for (p = buf; *p; p++) {
> switch (*p) {
> @@ -217,14 +249,14 @@ static int query_console_serial(int *rows, int *cols)
> u64 timeout;
>
> /* Empty input buffer */
> - while (tstc())
> - getc();
> + while (efi_tstc())
> + efi_getc();
>
> - printf(ESC"[18t");
> + efi_printf(ESC"[18t");
>
> /* Check if we have a terminal that understands */
> timeout = timer_get_us() + 100;
> - while (!tstc())
> + while (!efi_tstc())
> if (timer_get_us() > timeout)
> return -1;
>
> @@ -348,9 +380,9 @@ static efi_status_t EFIAPI efi_cout_set_attribute(
> EFI_ENTRY("%p, %lx", this, attribute);
>
> if (attribute)
> - printf(ESC"[%u;%um", color[fg].fg, color[bg].bg);
> + efi_printf(ESC"[%u;%um", color[fg].fg, color[bg].bg);
> else
> - printf(ESC"[37;40m");
> + efi_printf(ESC"[37;40m");
>
> /* Just ignore attributes (colors) for now */
> return EFI_EXIT(EFI_UNSUPPORTED);
> @@ -361,7 +393,7 @@ static efi_status_t EFIAPI efi_cout_clear_screen(
> {
> EFI_ENTRY("%p", this);
>
> - printf(ESC"[2J");
> + efi_printf(ESC"[2J");
>
> return EFI_EXIT(EFI_SUCCESS);
> }
> @@ -372,7 +404,7 @@ static efi_status_t EFIAPI efi_cout_set_cursor_position(
> {
> EFI_ENTRY("%p, %ld, %ld", this, column, row);
>
> - printf(ESC"[%d;%df", (int)row, (int)column);
> + efi_printf(ESC"[%d;%df", (int)row, (int)column);
> efi_con_mode.cursor_column = column;
> efi_con_mode.cursor_row = row;
>
> @@ -385,7 +417,7 @@ static efi_status_t EFIAPI efi_cout_enable_cursor(
> {
> EFI_ENTRY("%p, %d", this, enable);
>
> - printf(ESC"[?25%c", enable ? 'h' : 'l');
> + efi_printf(ESC"[?25%c", enable ? 'h' : 'l');
>
> return EFI_EXIT(EFI_SUCCESS);
> }
> @@ -427,27 +459,27 @@ static efi_status_t read_key_stroke(struct efi_key_data
> *key_data)
>
Re: [U-Boot] [PATCH] efi_loader: Fix disk dp's for pre-DM/legacy devices
On Mon, Oct 9, 2017 at 1:48 PM, Jonathan Gray wrote: > On Mon, Oct 09, 2017 at 01:06:26PM -0400, Rob Clark wrote: >> On Mon, Oct 9, 2017 at 12:41 PM, Jonathan Gray wrote: >> > On Mon, Oct 09, 2017 at 12:06:24PM -0400, Rob Clark wrote: >> >> On Mon, Oct 9, 2017 at 11:35 AM, Jonathan Gray wrote: >> >> > On Mon, Oct 09, 2017 at 10:17:18AM -0400, Rob Clark wrote: >> >> >> On Mon, Oct 9, 2017 at 8:25 AM, Jonathan Gray wrote: >> >> >> > On Mon, Oct 09, 2017 at 06:52:18AM -0400, Rob Clark wrote: >> >> >> >> On Sun, Oct 8, 2017 at 11:33 PM, Jonathan Gray >> >> >> >> wrote: >> >> >> >> > On Sun, Oct 08, 2017 at 11:33:08AM -0400, Rob Clark wrote: >> >> >> >> >> This fixes an issue with OpenBSD's bootloader, and I think >> >> >> >> >> should also >> >> >> >> >> fix a similar issue with grub2 on legacy devices. In the legacy >> >> >> >> >> case >> >> >> >> >> we were creating disk objects for the partitions, but not also >> >> >> >> >> the >> >> >> >> >> parent device. >> >> >> >> >> >> >> >> >> >> Reported-by: Jonathan Gray >> >> >> >> >> Signed-off-by: Rob Clark >> >> >> >> > >> >> >> >> > Thanks for looking into this. While this lets armv7/bootarm.efi >> >> >> >> > boot again on cubox-i and bbb it doesn't help rpi3. >> >> >> >> > >> >> >> >> > What is the easiest way to get U-Boot to display these paths >> >> >> >> > to be able to compare the current behaviour to 2017.09? >> >> >> >> > >> >> >> >> >> >> >> >> in grub, there is the lsefi command, not sure if the OpenBSD >> >> >> >> bootloader has something similar? >> >> >> >> >> >> >> >> u-boot implements that device-path to text protocol, so it should be >> >> >> >> pretty easy to implement something like this if not. >> >> >> >> >> >> >> >> BR, >> >> >> >> -R >> >> >> > >> >> >> > With git + your patch a node with type 4 >> >> >> > (DEVICE_PATH_TYPE_MEDIA_DEVICE) >> >> >> > is no longer seen. Is it possible having U-Boot on mmc but directing >> >> >> > it to load off usb is somehow involved here? >> >> >> >> >> >> There is no requirement that efi payload and u-boot are on the same >> >> >> device. The distro bootcmd stuff will just look for >> >> >> /efi/boot/bootxyz.efi on all the devices/partitions until it finds >> >> >> one. >> >> >> >> >> >> The dp for the partition device should end in MEDIA_DEVICE:HARD_DRIVE >> >> >> or MEDIA_DEVICE:CDROM. What comes before that differs depending on DM >> >> >> or legacy boards, in the former case we can construct something more >> >> >> realistic. Although the bootloader shouldn't really care. >> >> > >> >> > I only see MEDIA_DEVICE with U-Boot 2017.09. The latest code >> >> > in master only gives types of 1 (Hardware Device Path) and >> >> > 3 (Messaging Device Path). >> >> > >> >> > It is DM in this case: >> >> >> >> Possibly something weird with your partition table? In >> >> efi_disk_register() it should create objects for the disk itself >> >> (part==0, no MEDIA_DEVICE nodes in the dp), as well as for each >> >> partition (part>=1, which would have same dp as the disk but >> >> additional MEDIA_DEVICE:HARD_DRIVE or MEDIA_DEVICE:CDROM node). >> >> >> >> If part_get_info() fails for part==1 then you won't get any of the >> >> partition devices. I suppose this could happen if you an unknown >> >> partition table type, or u-boot is not built w/ the correct partition >> >> driver. >> >> >> >> BR, >> >> -R >> > >> > It is partitioned mbr style. >> > >> > U-Boot> part list mmc 0 >> > >> > Partition Map for MMC device 0 -- Partition Typ
Re: [U-Boot] [PATCH] efi_loader: Fix disk dp's for pre-DM/legacy devices
On Mon, Oct 9, 2017 at 12:41 PM, Jonathan Gray wrote: > On Mon, Oct 09, 2017 at 12:06:24PM -0400, Rob Clark wrote: >> On Mon, Oct 9, 2017 at 11:35 AM, Jonathan Gray wrote: >> > On Mon, Oct 09, 2017 at 10:17:18AM -0400, Rob Clark wrote: >> >> On Mon, Oct 9, 2017 at 8:25 AM, Jonathan Gray wrote: >> >> > On Mon, Oct 09, 2017 at 06:52:18AM -0400, Rob Clark wrote: >> >> >> On Sun, Oct 8, 2017 at 11:33 PM, Jonathan Gray wrote: >> >> >> > On Sun, Oct 08, 2017 at 11:33:08AM -0400, Rob Clark wrote: >> >> >> >> This fixes an issue with OpenBSD's bootloader, and I think should >> >> >> >> also >> >> >> >> fix a similar issue with grub2 on legacy devices. In the legacy >> >> >> >> case >> >> >> >> we were creating disk objects for the partitions, but not also the >> >> >> >> parent device. >> >> >> >> >> >> >> >> Reported-by: Jonathan Gray >> >> >> >> Signed-off-by: Rob Clark >> >> >> > >> >> >> > Thanks for looking into this. While this lets armv7/bootarm.efi >> >> >> > boot again on cubox-i and bbb it doesn't help rpi3. >> >> >> > >> >> >> > What is the easiest way to get U-Boot to display these paths >> >> >> > to be able to compare the current behaviour to 2017.09? >> >> >> > >> >> >> >> >> >> in grub, there is the lsefi command, not sure if the OpenBSD >> >> >> bootloader has something similar? >> >> >> >> >> >> u-boot implements that device-path to text protocol, so it should be >> >> >> pretty easy to implement something like this if not. >> >> >> >> >> >> BR, >> >> >> -R >> >> > >> >> > With git + your patch a node with type 4 (DEVICE_PATH_TYPE_MEDIA_DEVICE) >> >> > is no longer seen. Is it possible having U-Boot on mmc but directing >> >> > it to load off usb is somehow involved here? >> >> >> >> There is no requirement that efi payload and u-boot are on the same >> >> device. The distro bootcmd stuff will just look for >> >> /efi/boot/bootxyz.efi on all the devices/partitions until it finds >> >> one. >> >> >> >> The dp for the partition device should end in MEDIA_DEVICE:HARD_DRIVE >> >> or MEDIA_DEVICE:CDROM. What comes before that differs depending on DM >> >> or legacy boards, in the former case we can construct something more >> >> realistic. Although the bootloader shouldn't really care. >> > >> > I only see MEDIA_DEVICE with U-Boot 2017.09. The latest code >> > in master only gives types of 1 (Hardware Device Path) and >> > 3 (Messaging Device Path). >> > >> > It is DM in this case: >> >> Possibly something weird with your partition table? In >> efi_disk_register() it should create objects for the disk itself >> (part==0, no MEDIA_DEVICE nodes in the dp), as well as for each >> partition (part>=1, which would have same dp as the disk but >> additional MEDIA_DEVICE:HARD_DRIVE or MEDIA_DEVICE:CDROM node). >> >> If part_get_info() fails for part==1 then you won't get any of the >> partition devices. I suppose this could happen if you an unknown >> partition table type, or u-boot is not built w/ the correct partition >> driver. >> >> BR, >> -R > > It is partitioned mbr style. > > U-Boot> part list mmc 0 > > Partition Map for MMC device 0 -- Partition Type: DOS > > PartStart SectorNum Sectors UUIDType > 1 81928192-01 0c Boot > 4 16384 26624 -04 a6 > U-Boot> part list usb 0 perhaps jumping from partition #1 to #4 is what is confusing things here? It's possible you end up with a partition "diskobj" for partition #1 but not #4? Try adding a print in efi_disk_register() and see how many times we go thru the while(!part_get_info()) loop. BR, -R > Partition Map for USB device 0 -- Partition Type: DOS > > PartStart SectorNum Sectors UUIDType > 1 819232768 -01 0c Boot > 4 40960 60021540-04 a6 > > I changed the part_get_info() debug messages to normal printfs and no > error path
Re: [U-Boot] [PATCH] efi_loader: Fix disk dp's for pre-DM/legacy devices
On Mon, Oct 9, 2017 at 12:22 PM, Heinrich Schuchardt wrote: > On 10/09/2017 06:06 PM, Rob Clark wrote: >> On Mon, Oct 9, 2017 at 11:35 AM, Jonathan Gray wrote: >>> On Mon, Oct 09, 2017 at 10:17:18AM -0400, Rob Clark wrote: >>>> On Mon, Oct 9, 2017 at 8:25 AM, Jonathan Gray wrote: >>>>> On Mon, Oct 09, 2017 at 06:52:18AM -0400, Rob Clark wrote: >>>>>> On Sun, Oct 8, 2017 at 11:33 PM, Jonathan Gray wrote: >>>>>>> On Sun, Oct 08, 2017 at 11:33:08AM -0400, Rob Clark wrote: >>>>>>>> This fixes an issue with OpenBSD's bootloader, and I think should also >>>>>>>> fix a similar issue with grub2 on legacy devices. In the legacy case >>>>>>>> we were creating disk objects for the partitions, but not also the >>>>>>>> parent device. >>>>>>>> >>>>>>>> Reported-by: Jonathan Gray >>>>>>>> Signed-off-by: Rob Clark >>>>>>> >>>>>>> Thanks for looking into this. While this lets armv7/bootarm.efi >>>>>>> boot again on cubox-i and bbb it doesn't help rpi3. >>>>>>> >>>>>>> What is the easiest way to get U-Boot to display these paths >>>>>>> to be able to compare the current behaviour to 2017.09? >>>>>>> >>>>>> >>>>>> in grub, there is the lsefi command, not sure if the OpenBSD >>>>>> bootloader has something similar? >>>>>> >>>>>> u-boot implements that device-path to text protocol, so it should be >>>>>> pretty easy to implement something like this if not. >>>>>> >>>>>> BR, >>>>>> -R >>>>> >>>>> With git + your patch a node with type 4 (DEVICE_PATH_TYPE_MEDIA_DEVICE) >>>>> is no longer seen. Is it possible having U-Boot on mmc but directing >>>>> it to load off usb is somehow involved here? >>>> >>>> There is no requirement that efi payload and u-boot are on the same >>>> device. The distro bootcmd stuff will just look for >>>> /efi/boot/bootxyz.efi on all the devices/partitions until it finds >>>> one. >>>> >>>> The dp for the partition device should end in MEDIA_DEVICE:HARD_DRIVE >>>> or MEDIA_DEVICE:CDROM. What comes before that differs depending on DM >>>> or legacy boards, in the former case we can construct something more >>>> realistic. Although the bootloader shouldn't really care. >>> >>> I only see MEDIA_DEVICE with U-Boot 2017.09. The latest code >>> in master only gives types of 1 (Hardware Device Path) and >>> 3 (Messaging Device Path). >>> >>> It is DM in this case: >> >> Possibly something weird with your partition table? In >> efi_disk_register() it should create objects for the disk itself >> (part==0, no MEDIA_DEVICE nodes in the dp), as well as for each >> partition (part>=1, which would have same dp as the disk but >> additional MEDIA_DEVICE:HARD_DRIVE or MEDIA_DEVICE:CDROM node). >> >> If part_get_info() fails for part==1 then you won't get any of the >> partition devices. I suppose this could happen if you an unknown >> partition table type, or u-boot is not built w/ the correct partition >> driver. >> >> BR, >> -R >> >> >>> U-Boot> dm tree >>> Class Probed Driver Name >>> >>> root [ + ] root_drive root_driver >>> simple_bus [ + ] generic_si |-- soc >>> gpio [ + ] gpio_bcm28 | |-- gpio@7e20 >>> serial [ + ] serial_bcm | |-- serial@7e215040 >>> mmc[ + ] sdhci-bcm2 | |-- sdhci@7e30 >>> blk[ + ] mmc_blk | | `-- sd...@7e30.blk >>> video [ + ] bcm2835_vi | |-- hdmi@7e902000 >>> vidconsole [ + ] vidconsole | | `-- hdmi@7e902000.vidconsole0 >>> usb[ + ] dwc2_usb| `-- usb@7e98 >>> usb_hub[ + ] usb_hub | `-- usb_hub >>> usb_hub[ + ] usb_hub | `-- usb_hub >>> eth[ + ] smsc95xx_e | |-- smsc95xx_eth >>> usb_mass_s [ + ] usb_mass_s | `-- usb_mass_storage >>> blk[ ] usb_storag | `-- >>> usb_mass_storage.lun0 >>> simple_bus [ ] generic_si `-- cloc
Re: [U-Boot] [PATCH] efi_loader: Fix disk dp's for pre-DM/legacy devices
On Mon, Oct 9, 2017 at 11:35 AM, Jonathan Gray wrote: > On Mon, Oct 09, 2017 at 10:17:18AM -0400, Rob Clark wrote: >> On Mon, Oct 9, 2017 at 8:25 AM, Jonathan Gray wrote: >> > On Mon, Oct 09, 2017 at 06:52:18AM -0400, Rob Clark wrote: >> >> On Sun, Oct 8, 2017 at 11:33 PM, Jonathan Gray wrote: >> >> > On Sun, Oct 08, 2017 at 11:33:08AM -0400, Rob Clark wrote: >> >> >> This fixes an issue with OpenBSD's bootloader, and I think should also >> >> >> fix a similar issue with grub2 on legacy devices. In the legacy case >> >> >> we were creating disk objects for the partitions, but not also the >> >> >> parent device. >> >> >> >> >> >> Reported-by: Jonathan Gray >> >> >> Signed-off-by: Rob Clark >> >> > >> >> > Thanks for looking into this. While this lets armv7/bootarm.efi >> >> > boot again on cubox-i and bbb it doesn't help rpi3. >> >> > >> >> > What is the easiest way to get U-Boot to display these paths >> >> > to be able to compare the current behaviour to 2017.09? >> >> > >> >> >> >> in grub, there is the lsefi command, not sure if the OpenBSD >> >> bootloader has something similar? >> >> >> >> u-boot implements that device-path to text protocol, so it should be >> >> pretty easy to implement something like this if not. >> >> >> >> BR, >> >> -R >> > >> > With git + your patch a node with type 4 (DEVICE_PATH_TYPE_MEDIA_DEVICE) >> > is no longer seen. Is it possible having U-Boot on mmc but directing >> > it to load off usb is somehow involved here? >> >> There is no requirement that efi payload and u-boot are on the same >> device. The distro bootcmd stuff will just look for >> /efi/boot/bootxyz.efi on all the devices/partitions until it finds >> one. >> >> The dp for the partition device should end in MEDIA_DEVICE:HARD_DRIVE >> or MEDIA_DEVICE:CDROM. What comes before that differs depending on DM >> or legacy boards, in the former case we can construct something more >> realistic. Although the bootloader shouldn't really care. > > I only see MEDIA_DEVICE with U-Boot 2017.09. The latest code > in master only gives types of 1 (Hardware Device Path) and > 3 (Messaging Device Path). > > It is DM in this case: Possibly something weird with your partition table? In efi_disk_register() it should create objects for the disk itself (part==0, no MEDIA_DEVICE nodes in the dp), as well as for each partition (part>=1, which would have same dp as the disk but additional MEDIA_DEVICE:HARD_DRIVE or MEDIA_DEVICE:CDROM node). If part_get_info() fails for part==1 then you won't get any of the partition devices. I suppose this could happen if you an unknown partition table type, or u-boot is not built w/ the correct partition driver. BR, -R > U-Boot> dm tree > Class Probed Driver Name > > root [ + ] root_drive root_driver > simple_bus [ + ] generic_si |-- soc > gpio [ + ] gpio_bcm28 | |-- gpio@7e20 > serial [ + ] serial_bcm | |-- serial@7e215040 > mmc[ + ] sdhci-bcm2 | |-- sdhci@7e30 > blk[ + ] mmc_blk | | `-- sd...@7e30.blk > video [ + ] bcm2835_vi | |-- hdmi@7e902000 > vidconsole [ + ] vidconsole | | `-- hdmi@7e902000.vidconsole0 > usb[ + ] dwc2_usb| `-- usb@7e98 > usb_hub[ + ] usb_hub | `-- usb_hub > usb_hub[ + ] usb_hub | `-- usb_hub > eth[ + ] smsc95xx_e | |-- smsc95xx_eth > usb_mass_s [ + ] usb_mass_s | `-- usb_mass_storage > blk[ ] usb_storag | `-- usb_mass_storage.lun0 > simple_bus [ ] generic_si `-- clocks > >> >> > efi_bootdp obtained from the loaded image protocol >> > >> > 2017.09 >> > >> > Scanning usb 0:1... >> > Found EFI removable media binary efi/boot/bootaa64.efi >> > reading efi/boot/bootaa64.efi >> > 78959 bytes read in 76 ms (1013.7 KiB/s) >> > ## Starting EFI application at 0100 ... >> > Scanning disk sd...@7e30.blk... >> > Scanning disk usb_mass_storage.lun0... >> > Found 2 disks >> > efi_diskprobe >> > efi_device_path_depth looking for type 4 i=0 type 4 >> > depth=0 >> > i=0 >> > efi_bootdp=Dusbmassstoragelun dp=Dsdhcieblk >> > i=1 >> > efi
Re: [U-Boot] [PATCH] efi_loader: Fix disk dp's for pre-DM/legacy devices
On Mon, Oct 9, 2017 at 8:25 AM, Jonathan Gray wrote: > On Mon, Oct 09, 2017 at 06:52:18AM -0400, Rob Clark wrote: >> On Sun, Oct 8, 2017 at 11:33 PM, Jonathan Gray wrote: >> > On Sun, Oct 08, 2017 at 11:33:08AM -0400, Rob Clark wrote: >> >> This fixes an issue with OpenBSD's bootloader, and I think should also >> >> fix a similar issue with grub2 on legacy devices. In the legacy case >> >> we were creating disk objects for the partitions, but not also the >> >> parent device. >> >> >> >> Reported-by: Jonathan Gray >> >> Signed-off-by: Rob Clark >> > >> > Thanks for looking into this. While this lets armv7/bootarm.efi >> > boot again on cubox-i and bbb it doesn't help rpi3. >> > >> > What is the easiest way to get U-Boot to display these paths >> > to be able to compare the current behaviour to 2017.09? >> > >> >> in grub, there is the lsefi command, not sure if the OpenBSD >> bootloader has something similar? >> >> u-boot implements that device-path to text protocol, so it should be >> pretty easy to implement something like this if not. >> >> BR, >> -R > > With git + your patch a node with type 4 (DEVICE_PATH_TYPE_MEDIA_DEVICE) > is no longer seen. Is it possible having U-Boot on mmc but directing > it to load off usb is somehow involved here? There is no requirement that efi payload and u-boot are on the same device. The distro bootcmd stuff will just look for /efi/boot/bootxyz.efi on all the devices/partitions until it finds one. The dp for the partition device should end in MEDIA_DEVICE:HARD_DRIVE or MEDIA_DEVICE:CDROM. What comes before that differs depending on DM or legacy boards, in the former case we can construct something more realistic. Although the bootloader shouldn't really care. > efi_bootdp obtained from the loaded image protocol > > 2017.09 > > Scanning usb 0:1... > Found EFI removable media binary efi/boot/bootaa64.efi > reading efi/boot/bootaa64.efi > 78959 bytes read in 76 ms (1013.7 KiB/s) > ## Starting EFI application at 0100 ... > Scanning disk sd...@7e30.blk... > Scanning disk usb_mass_storage.lun0... > Found 2 disks > efi_diskprobe > efi_device_path_depth looking for type 4 i=0 type 4 > depth=0 > i=0 > efi_bootdp=Dusbmassstoragelun dp=Dsdhcieblk > i=1 > efi_bootdp=Dusbmassstoragelun dp=Dusbmassstoragelun >>> OpenBSD/arm64 BOOTAA64 0.8 > boot> > booting sd0a:/bsd: 3871708+578596+509352+803952 > [283845+96+451968+239920]=0x82f330 > > git + patch I assume you are referring to this patch? It should only add additional per-partion "disk" objects. (In UEFI terminology each partition is a "disk" object.) BR, -R > Scanning usb 0:1... > Found EFI removable media binary efi/boot/bootaa64.efi > reading efi/boot/bootaa64.efi > 78959 bytes read in 86 ms (896.5 KiB/s) > ## Starting EFI application at 0100 ... > Scanning disk sd...@7e30.blk... > Scanning disk usb_mass_storage.lun0... > Found 2 disks > efi_diskprobe > efi_device_path_depth looking for type 4 i=0 type 1 > efi_device_path_depth looking for type 4 i=1 type 3 > efi_device_path_depth looking for type 4 i=2 type 3 > efi_device_path_depth looking for type 4 i=3 type 3 > efi_device_path_depth no match for type 4 > depth=-1 > i=0 > i=1 > i=2 > i=3 >>> OpenBSD/arm64 BOOTAA64 0.8 > boot> > cannot open sd0a:/etc/random.seed: Device not configured > booting sd0a:/bsd: open sd0a:/bsd: Device not configured ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] efi_loader: enough-uefi-for-shell: [PATCH 06/11] efi_loader: implement SetWatchdogTimer
On Sun, Oct 8, 2017 at 6:14 PM, Heinrich Schuchardt wrote:
> On 10/08/2017 06:57 AM, Heinrich Schuchardt wrote:
>> The watchdog is initialized with a 5 minute timeout period.
>> It can be reset by SetWatchdogTimer.
>> It is stopped by ExitBoottimeServices.
>>
>> Signed-off-by: Heinrich Schuchardt
>> ---
>> cmd/bootefi.c | 1 +
>> include/efi_loader.h | 4 +++
>> lib/efi_loader/Makefile | 2 +-
>> lib/efi_loader/efi_boottime.c | 15 ++-
>> lib/efi_loader/efi_watchdog.c | 59
>> +++
>> 5 files changed, 67 insertions(+), 14 deletions(-)
>> create mode 100644 lib/efi_loader/efi_watchdog.c
>>
>> diff --git a/cmd/bootefi.c b/cmd/bootefi.c
>> index b7087e3da8..24958ada46 100644
>> --- a/cmd/bootefi.c
>> +++ b/cmd/bootefi.c
>> @@ -43,6 +43,7 @@ static void efi_init_obj_list(void)
>> #ifdef CONFIG_GENERATE_SMBIOS_TABLE
>> efi_smbios_register();
>> #endif
>> + efi_watchdog_register();
>>
>> /* Initialize EFI runtime services */
>> efi_reset_system_init();
>> diff --git a/include/efi_loader.h b/include/efi_loader.h
>> index e1179b7dcd..223d8d8222 100644
>> --- a/include/efi_loader.h
>> +++ b/include/efi_loader.h
>> @@ -163,6 +163,8 @@ int efi_disk_register(void);
>> int efi_gop_register(void);
>> /* Called by bootefi to make the network interface available */
>> int efi_net_register(void);
>> +/* Called by bootefi to make the watchdog available */
>> +int efi_watchdog_register(void);
>> /* Called by bootefi to make SMBIOS tables available */
>> void efi_smbios_register(void);
>>
>> @@ -171,6 +173,8 @@ efi_fs_from_path(struct efi_device_path *fp);
>>
>> /* Called by networking code to memorize the dhcp ack package */
>> void efi_net_set_dhcp_ack(void *pkt, int len);
>> +/* Called by efi_set_watchdog_timer to reset the timer */
>> +efi_status_t efi_set_watchdog(unsigned long timeout);
>>
>> /* Called from places to check whether a timer expired */
>> void efi_timer_check(void);
>> diff --git a/lib/efi_loader/Makefile b/lib/efi_loader/Makefile
>> index ddb978f650..83d879b686 100644
>> --- a/lib/efi_loader/Makefile
>> +++ b/lib/efi_loader/Makefile
>> @@ -17,7 +17,7 @@ endif
>> obj-$(CONFIG_CMD_BOOTEFI_HELLO) += helloworld_efi.o
>> obj-y += efi_image_loader.o efi_boottime.o efi_runtime.o efi_console.o
>> obj-y += efi_memory.o efi_device_path_to_text.o efi_device_path.o
>> -obj-y += efi_file.o efi_variable.o efi_bootmgr.o
>> +obj-y += efi_file.o efi_variable.o efi_bootmgr.o efi_watchdog.o
>> obj-$(CONFIG_LCD) += efi_gop.o
>> obj-$(CONFIG_DM_VIDEO) += efi_gop.o
>> obj-$(CONFIG_PARTITIONS) += efi_disk.o
>> diff --git a/lib/efi_loader/efi_boottime.c b/lib/efi_loader/efi_boottime.c
>> index 30577f717e..81e7d818fc 100644
>> --- a/lib/efi_loader/efi_boottime.c
>> +++ b/lib/efi_loader/efi_boottime.c
>> @@ -155,18 +155,6 @@ void efi_signal_event(struct efi_event *event)
>> event->is_queued = false;
>> }
>>
>> -/*
>> - * Write a debug message for an EPI API service that is not implemented yet.
>> - *
>> - * @funcname function that is not yet implemented
>> - * @return EFI_UNSUPPORTED
>> - */
>> -static efi_status_t efi_unsupported(const char *funcname)
>> -{
>> - debug("EFI: App called into unimplemented function %s\n", funcname);
>> - return EFI_EXIT(EFI_UNSUPPORTED);
>> -}
>> -
>> /*
>> * Raise the task priority level.
>> *
>> @@ -1454,6 +1442,7 @@ static efi_status_t EFIAPI efi_exit_boot_services(void
>> *image_handle,
>> bootm_disable_interrupts();
>>
>> /* Give the payload some time to boot */
>> + efi_set_watchdog(0);
>> WATCHDOG_RESET();
>>
>> return EFI_EXIT(EFI_SUCCESS);
>> @@ -1514,7 +1503,7 @@ static efi_status_t EFIAPI
>> efi_set_watchdog_timer(unsigned long timeout,
>> {
>> EFI_ENTRY("%ld, 0x%"PRIx64", %ld, %p", timeout, watchdog_code,
>> data_size, watchdog_data);
>> - return efi_unsupported(__func__);
>> + return EFI_EXIT(efi_set_watchdog(timeout));
>> }
>>
>> /*
>> diff --git a/lib/efi_loader/efi_watchdog.c b/lib/efi_loader/efi_watchdog.c
>> new file mode 100644
>> index 00..50e95290ea
>> --- /dev/null
>> +++ b/lib/efi_loader/efi_watchdog.c
>> @@ -0,0 +1,59 @@
>> +/*
>> + * EFI device path interface
>> + *
>> + * Copyright (c) 2017 Heinrich Schuchardt
>> + *
>> + * SPDX-License-Identifier: GPL-2.0+
>> + */
>> +
>> +#include
>> +#include
>> +
>> +static struct efi_event *watchdog_timer_event;
>> +
>> +static void EFIAPI efi_watchdog_timer_notify(struct efi_event *event,
>> + void *context)
>> +{
>> + EFI_ENTRY("%p, %p", event, context);
>> +
>> + printf("\nEFI: Watchdog timeout\n");
>> + EFI_CALL_VOID(efi_runtime_services.reset_system(EFI_RESET_COLD,
>> + EFI_SUCCESS, 0, NULL));
>
> Hello Rob,
>
> referring to:
> https://github.com/robclark/u-boot/commits/enough-uefi-for-shell
>
> The patch
Re: [U-Boot] [PATCH] efi_loader: Fix disk dp's for pre-DM/legacy devices
On Sun, Oct 8, 2017 at 11:33 PM, Jonathan Gray wrote: > On Sun, Oct 08, 2017 at 11:33:08AM -0400, Rob Clark wrote: >> This fixes an issue with OpenBSD's bootloader, and I think should also >> fix a similar issue with grub2 on legacy devices. In the legacy case >> we were creating disk objects for the partitions, but not also the >> parent device. >> >> Reported-by: Jonathan Gray >> Signed-off-by: Rob Clark > > Thanks for looking into this. While this lets armv7/bootarm.efi > boot again on cubox-i and bbb it doesn't help rpi3. > > What is the easiest way to get U-Boot to display these paths > to be able to compare the current behaviour to 2017.09? > in grub, there is the lsefi command, not sure if the OpenBSD bootloader has something similar? u-boot implements that device-path to text protocol, so it should be pretty easy to implement something like this if not. BR, -R ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 1/1] efi_loader: use type bool for event states
On Sun, Oct 8, 2017 at 12:41 PM, Alexander Graf wrote: > > >> Am 08.10.2017 um 17:54 schrieb Rob Clark : >> >>> On Wed, Oct 4, 2017 at 12:02 PM, Heinrich Schuchardt >>> wrote: >>> Patch efi_loader: add stub HII protocols uses UINTN heavily. In a recent >>> comment Simon remarked that types should not be uppercase. So I was >>> planning to replace all occurences of UINTN by size_t in an upcoming patch. >> >> btw, how would you feed about: >> >> typedef size_t efi_uintn_t; >> >> instead of using size_t directly? UINTN is used in a bunch of places >> where size_t, although it might be the right size, does not feel >> appropriate.. > > I like the idea :) > btw, 2nd benefit that I didn't immediately think of.. but if I'm comparing UEFI spec and edk2 headers, if I see size_t in u-boot's headers but UINTN in UEFI spec / edk2, then I have to stop and think and remember how UINTN is defined in the spec. If I see efi_uintn_t, I don't ;-) I'll convert the efi_loader patches for Shell.efi to efi_uintn_t/efi_intn_t.. we can handle the rest of conversion and removal of UINTN as a follow-on patch, imho. BR, -R ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 1/1] efi_loader: use type bool for event states
On Wed, Oct 4, 2017 at 12:02 PM, Heinrich Schuchardt wrote: > Patch efi_loader: add stub HII protocols uses UINTN heavily. In a recent > comment Simon remarked that types should not be uppercase. So I was > planning to replace all occurences of UINTN by size_t in an upcoming patch. btw, how would you feed about: typedef size_t efi_uintn_t; instead of using size_t directly? UINTN is used in a bunch of places where size_t, although it might be the right size, does not feel appropriate.. BR, -R ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH] efi_loader: Fix disk dp's for pre-DM/legacy devices
This fixes an issue with OpenBSD's bootloader, and I think should also
fix a similar issue with grub2 on legacy devices. In the legacy case
we were creating disk objects for the partitions, but not also the
parent device.
Reported-by: Jonathan Gray
Signed-off-by: Rob Clark
---
lib/efi_loader/efi_disk.c | 11 +++
1 file changed, 11 insertions(+)
diff --git a/lib/efi_loader/efi_disk.c b/lib/efi_loader/efi_disk.c
index eb9ce772d1..47b487aa30 100644
--- a/lib/efi_loader/efi_disk.c
+++ b/lib/efi_loader/efi_disk.c
@@ -340,6 +340,8 @@ int efi_disk_register(void)
for (i = 0; i < 4; i++) {
struct blk_desc *desc;
char devname[32] = { 0 }; /* dp->str is u16[32] long */
+ disk_partition_t info;
+ int part = 1;
desc = blk_get_devnum_by_type(if_type, i);
if (!desc)
@@ -349,6 +351,15 @@ int efi_disk_register(void)
snprintf(devname, sizeof(devname), "%s%d",
if_typename, i);
+
+ /* add devices for each partition: */
+ while (!part_get_info(desc, part, &info)) {
+ efi_disk_add_dev(devname, if_typename, desc,
+i, 0, part);
+ part++;
+ }
+
+ /* ... and add block device: */
efi_disk_add_dev(devname, if_typename, desc, i, 0, 0);
disks++;
--
2.13.6
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] disk: part_dos: Use the original allocation scheme for the SPL case
On Fri, Oct 6, 2017 at 10:08 PM, Jonathan Gray wrote:
> On Fri, Oct 06, 2017 at 08:21:26AM -0400, Rob Clark wrote:
>> On Fri, Oct 6, 2017 at 12:35 AM, Jonathan Gray wrote:
>> > On Thu, Oct 05, 2017 at 05:05:49AM -0400, Rob Clark wrote:
>> >> On Thu, Oct 5, 2017 at 12:36 AM, Jonathan Gray wrote:
>> >> > On Wed, Oct 04, 2017 at 01:12:48PM -0400, Rob Clark wrote:
>> >> >> On Wed, Oct 4, 2017 at 12:29 PM, Fabio Estevam
>> >> >> wrote:
>> >> >> > Since commit ff98cb90514d ("part: extract MBR signature from
>> >> >> > partitions")
>> >> >> > SPL boot on i.MX6 starts to fail:
>> >> >> >
>> >> >> > U-Boot SPL 2017.09-00221-g0d6ab32 (Oct 02 2017 - 15:13:19)
>> >> >> > Trying to boot from MMC1
>> >> >> > (keep in loop)
>> >> >> >
>> >> >> > Use the original allocation scheme for the SPL case, so that MX6
>> >> >> > boards
>> >> >> > can boot again.
>> >> >> >
>> >> >> > This is a temporary solution to avoid the boot regression.
>> >> >> >
>> >> >> > Signed-off-by: Fabio Estevam
>> >> >> > ---
>> >> >> > Hi Tom,
>> >> >> >
>> >> >> > I do not have time this week to further investigate and narrow down
>> >> >> > this problem.
>> >> >> >
>> >> >> > Using the old allocation scheme fixes the mx6 SPL boot problem.
>> >> >> >
>> >> >>
>> >> >> Hi Tom, if you are ok with this as a temporary fix, then this is:
>> >> >>
>> >> >> Acked-by: Rob Clark
>> >> >>
>> >> >> I'm getting some help from some of the fedora-arm folks so hopefully I
>> >> >> can get some idea what is going wrong, but I'd like to unblock folks
>> >> >> w/ mx6 boards..
>> >> >>
>> >> >> BR,
>> >> >> -R
>> >> >
>> >> > This does not seem to be a complete fix, cubox is still broken when
>> >> > U-Boot proper loads, unless the efi loader commits are to blame
>> >> > for introducing unaligned accesses.
>> >> >
>> >> > Works with 2017.09.
>> >> >
>> >> > U-Boot SPL 2017.11-rc1-00026-g14b55fc833 (Oct 05 2017 - 15:17:47)
>> >> > Trying to boot from MMC1
>> >> >
>> >> >
>> >> > U-Boot 2017.11-rc1-00026-g14b55fc833 (Oct 05 2017 - 15:17:47 +1100)
>> >> >
>> >> > CPU: Freescale i.MX6Q rev1.5 996 MHz (running at 792 MHz)
>> >> > CPU: Extended Commercial temperature grade (-20C to 105C) at 34C
>> >> > Reset cause: WDOG
>> >> > Board: MX6 Cubox-i
>> >> > DRAM: 2 GiB
>> >> > MMC: FSL_SDHC: 0
>> >> > *** Warning - bad CRC, using default environment
>> >> >
>> >> > No panel detected: default to HDMI
>> >> > Display: HDMI (1024x768)
>> >> > In:serial
>> >> > Out: serial
>> >> > Err: serial
>> >> > Net: FEC
>> >> > Hit any key to stop autoboot: 0
>> >> > switch to partitions #0, OK
>> >> > mmc0 is current device
>> >> > Scanning mmc 0:1...
>> >>
>> >> I don't think any efi_loader code is running here, you would see a
>> >> message like:
>> >>
>> >> ## Starting EFI application at XYZ
>> >>
>> >> But to be sure you can disable CONFIG_EFI_LOADER in menuconfig to confirm.
>> >>
>> >> I guess this is some unrelated change. I suspect Tom's change to
>> >> malloc the fat_itr's which would make the buffers used for
>> >> fs_exists()/etc not cache aligned. I thought there was a patch
>> >> floating around to change that to memalign().
>> >
>> > The imx6 problems still occur with CONFIG_EFI_LOADER disabled indeed.
>> >
>> > I can no longer load a kernel via efi on bbb though:
>> >
>> > U-Boot SPL 2017.11-rc1-00066-g4ac7de9239 (Oct 06 2017 - 14:21:51)
>> > Trying to boot from MMC1
>> > reading u-boot.img
>> > reading u-boot.img
>> >
>> >
>> > U-Boot 2017.11-rc1-00066-g4a
Re: [U-Boot] [PATCH] dm: video: make ANSI escape sequence support optional
On Fri, Oct 6, 2017 at 12:15 PM, Anatolij Gustschin wrote: > On Sat, 30 Sep 2017 10:19:17 +0200 > Anatolij Gustschin ag...@denx.de wrote: > >> As mentioned in review comments for ANSI escape sequence >> support patches, this should be optional to reduce code >> size. Disable escape sequence support when CONFIG_VIDEO_ANSI >> is not enabled. >> >> Signed-off-by: Anatolij Gustschin >> --- >> This patch is based on basic ANSI escape seq. support series: >> https://www.mail-archive.com/u-boot@lists.denx.de/msg263777.html >> >> drivers/video/vidconsole-uclass.c | 6 ++ >> include/video_console.h | 4 >> 2 files changed, 10 insertions(+) > > Applied to u-boot-video/master. > Like I mentioned before, we shouldn't really need this patch.. It only makes a trivial difference in size (which you could probably get back by just adding #ifdef VIDEO_ANSI / #endif around the single case statement in vidconsole_put_char()) text data bss dec hex 1937 2240 2161 871 VIDEO_ANSI disabled with this patch 2002 2240 2226 8b2 VIDEO_ANSI disabled without this patch 2698 2240 2922 b6a VIDEO_ANSI enabled And it makes the code a lot uglier and removes at least compile-time testing when VIDEO_ANSI is disabled. So I think you should drop/revert this patch BR, -R ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] disk: part_dos: Use the original allocation scheme for the SPL case
On Fri, Oct 6, 2017 at 8:21 AM, Rob Clark wrote:
> On Fri, Oct 6, 2017 at 12:35 AM, Jonathan Gray wrote:
>> On Thu, Oct 05, 2017 at 05:05:49AM -0400, Rob Clark wrote:
>>> On Thu, Oct 5, 2017 at 12:36 AM, Jonathan Gray wrote:
>>> > On Wed, Oct 04, 2017 at 01:12:48PM -0400, Rob Clark wrote:
>>> >> On Wed, Oct 4, 2017 at 12:29 PM, Fabio Estevam
>>> >> wrote:
>>> >> > Since commit ff98cb90514d ("part: extract MBR signature from
>>> >> > partitions")
>>> >> > SPL boot on i.MX6 starts to fail:
>>> >> >
>>> >> > U-Boot SPL 2017.09-00221-g0d6ab32 (Oct 02 2017 - 15:13:19)
>>> >> > Trying to boot from MMC1
>>> >> > (keep in loop)
>>> >> >
>>> >> > Use the original allocation scheme for the SPL case, so that MX6 boards
>>> >> > can boot again.
>>> >> >
>>> >> > This is a temporary solution to avoid the boot regression.
>>> >> >
>>> >> > Signed-off-by: Fabio Estevam
>>> >> > ---
>>> >> > Hi Tom,
>>> >> >
>>> >> > I do not have time this week to further investigate and narrow down
>>> >> > this problem.
>>> >> >
>>> >> > Using the old allocation scheme fixes the mx6 SPL boot problem.
>>> >> >
>>> >>
>>> >> Hi Tom, if you are ok with this as a temporary fix, then this is:
>>> >>
>>> >> Acked-by: Rob Clark
>>> >>
>>> >> I'm getting some help from some of the fedora-arm folks so hopefully I
>>> >> can get some idea what is going wrong, but I'd like to unblock folks
>>> >> w/ mx6 boards..
>>> >>
>>> >> BR,
>>> >> -R
>>> >
>>> > This does not seem to be a complete fix, cubox is still broken when
>>> > U-Boot proper loads, unless the efi loader commits are to blame
>>> > for introducing unaligned accesses.
>>> >
>>> > Works with 2017.09.
>>> >
>>> > U-Boot SPL 2017.11-rc1-00026-g14b55fc833 (Oct 05 2017 - 15:17:47)
>>> > Trying to boot from MMC1
>>> >
>>> >
>>> > U-Boot 2017.11-rc1-00026-g14b55fc833 (Oct 05 2017 - 15:17:47 +1100)
>>> >
>>> > CPU: Freescale i.MX6Q rev1.5 996 MHz (running at 792 MHz)
>>> > CPU: Extended Commercial temperature grade (-20C to 105C) at 34C
>>> > Reset cause: WDOG
>>> > Board: MX6 Cubox-i
>>> > DRAM: 2 GiB
>>> > MMC: FSL_SDHC: 0
>>> > *** Warning - bad CRC, using default environment
>>> >
>>> > No panel detected: default to HDMI
>>> > Display: HDMI (1024x768)
>>> > In:serial
>>> > Out: serial
>>> > Err: serial
>>> > Net: FEC
>>> > Hit any key to stop autoboot: 0
>>> > switch to partitions #0, OK
>>> > mmc0 is current device
>>> > Scanning mmc 0:1...
>>>
>>> I don't think any efi_loader code is running here, you would see a message
>>> like:
>>>
>>> ## Starting EFI application at XYZ
>>>
>>> But to be sure you can disable CONFIG_EFI_LOADER in menuconfig to confirm.
>>>
>>> I guess this is some unrelated change. I suspect Tom's change to
>>> malloc the fat_itr's which would make the buffers used for
>>> fs_exists()/etc not cache aligned. I thought there was a patch
>>> floating around to change that to memalign().
>>
>> The imx6 problems still occur with CONFIG_EFI_LOADER disabled indeed.
>>
>> I can no longer load a kernel via efi on bbb though:
>>
>> U-Boot SPL 2017.11-rc1-00066-g4ac7de9239 (Oct 06 2017 - 14:21:51)
>> Trying to boot from MMC1
>> reading u-boot.img
>> reading u-boot.img
>>
>>
>> U-Boot 2017.11-rc1-00066-g4ac7de9239 (Oct 06 2017 - 14:21:51 +1100)
>>
>> CPU : AM335X-GP rev 2.1
>> I2C: ready
>> DRAM: 512 MiB
>> No match for driver 'omap_hsmmc'
>> No match for driver 'omap_hsmmc'
>> Some drivers were not found
>> MMC: OMAP SD/MMC: 0, OMAP SD/MMC: 1
>> not set. Validating first E-fuse MAC
>> Net: cpsw, usb_ether
>> Press SPACE to abort autoboot in 2 seconds
>> switch to partitions #0, OK
>> mmc0 is current device
>> SD/MMC found on device 0
>> ** Unabl
Re: [U-Boot] [PATCH] disk: part_dos: Use the original allocation scheme for the SPL case
On Fri, Oct 6, 2017 at 12:35 AM, Jonathan Gray wrote:
> On Thu, Oct 05, 2017 at 05:05:49AM -0400, Rob Clark wrote:
>> On Thu, Oct 5, 2017 at 12:36 AM, Jonathan Gray wrote:
>> > On Wed, Oct 04, 2017 at 01:12:48PM -0400, Rob Clark wrote:
>> >> On Wed, Oct 4, 2017 at 12:29 PM, Fabio Estevam
>> >> wrote:
>> >> > Since commit ff98cb90514d ("part: extract MBR signature from
>> >> > partitions")
>> >> > SPL boot on i.MX6 starts to fail:
>> >> >
>> >> > U-Boot SPL 2017.09-00221-g0d6ab32 (Oct 02 2017 - 15:13:19)
>> >> > Trying to boot from MMC1
>> >> > (keep in loop)
>> >> >
>> >> > Use the original allocation scheme for the SPL case, so that MX6 boards
>> >> > can boot again.
>> >> >
>> >> > This is a temporary solution to avoid the boot regression.
>> >> >
>> >> > Signed-off-by: Fabio Estevam
>> >> > ---
>> >> > Hi Tom,
>> >> >
>> >> > I do not have time this week to further investigate and narrow down
>> >> > this problem.
>> >> >
>> >> > Using the old allocation scheme fixes the mx6 SPL boot problem.
>> >> >
>> >>
>> >> Hi Tom, if you are ok with this as a temporary fix, then this is:
>> >>
>> >> Acked-by: Rob Clark
>> >>
>> >> I'm getting some help from some of the fedora-arm folks so hopefully I
>> >> can get some idea what is going wrong, but I'd like to unblock folks
>> >> w/ mx6 boards..
>> >>
>> >> BR,
>> >> -R
>> >
>> > This does not seem to be a complete fix, cubox is still broken when
>> > U-Boot proper loads, unless the efi loader commits are to blame
>> > for introducing unaligned accesses.
>> >
>> > Works with 2017.09.
>> >
>> > U-Boot SPL 2017.11-rc1-00026-g14b55fc833 (Oct 05 2017 - 15:17:47)
>> > Trying to boot from MMC1
>> >
>> >
>> > U-Boot 2017.11-rc1-00026-g14b55fc833 (Oct 05 2017 - 15:17:47 +1100)
>> >
>> > CPU: Freescale i.MX6Q rev1.5 996 MHz (running at 792 MHz)
>> > CPU: Extended Commercial temperature grade (-20C to 105C) at 34C
>> > Reset cause: WDOG
>> > Board: MX6 Cubox-i
>> > DRAM: 2 GiB
>> > MMC: FSL_SDHC: 0
>> > *** Warning - bad CRC, using default environment
>> >
>> > No panel detected: default to HDMI
>> > Display: HDMI (1024x768)
>> > In:serial
>> > Out: serial
>> > Err: serial
>> > Net: FEC
>> > Hit any key to stop autoboot: 0
>> > switch to partitions #0, OK
>> > mmc0 is current device
>> > Scanning mmc 0:1...
>>
>> I don't think any efi_loader code is running here, you would see a message
>> like:
>>
>> ## Starting EFI application at XYZ
>>
>> But to be sure you can disable CONFIG_EFI_LOADER in menuconfig to confirm.
>>
>> I guess this is some unrelated change. I suspect Tom's change to
>> malloc the fat_itr's which would make the buffers used for
>> fs_exists()/etc not cache aligned. I thought there was a patch
>> floating around to change that to memalign().
>
> The imx6 problems still occur with CONFIG_EFI_LOADER disabled indeed.
>
> I can no longer load a kernel via efi on bbb though:
>
> U-Boot SPL 2017.11-rc1-00066-g4ac7de9239 (Oct 06 2017 - 14:21:51)
> Trying to boot from MMC1
> reading u-boot.img
> reading u-boot.img
>
>
> U-Boot 2017.11-rc1-00066-g4ac7de9239 (Oct 06 2017 - 14:21:51 +1100)
>
> CPU : AM335X-GP rev 2.1
> I2C: ready
> DRAM: 512 MiB
> No match for driver 'omap_hsmmc'
> No match for driver 'omap_hsmmc'
> Some drivers were not found
> MMC: OMAP SD/MMC: 0, OMAP SD/MMC: 1
> not set. Validating first E-fuse MAC
> Net: cpsw, usb_ether
> Press SPACE to abort autoboot in 2 seconds
> switch to partitions #0, OK
> mmc0 is current device
> SD/MMC found on device 0
> ** Unable to read file boot.scr **
> ** Unable to read file uEnv.txt **
> switch to partitions #0, OK
> mmc0 is current device
> Scanning mmc 0:1...
> reading /am335x-boneblack.dtb
> 35712 bytes read in 10 ms (3.4 MiB/s)
> Found EFI removable media binary efi/boot/bootarm.efi
> reading efi/boot/bootarm.efi
> 65448 bytes read in 16 ms (3.9 MiB/s)
> ## Starting EFI application at 8200 ...
> Scanning disks on usb...
> Scanning disks on mmc...
> MMC De
Re: [U-Boot] [PATCH] usb: kbd: Fix dangling pointers on probe fail
On Thu, Oct 5, 2017 at 7:48 PM, Bin Meng wrote:
> Hi Rob,
>
> On Wed, Oct 4, 2017 at 1:31 AM, Rob Clark wrote:
>> If probe fails, we should unregister the stdio device, else we leave
>> dangling pointers to the parent 'struct usb_device'.
>>
>> Signed-off-by: Rob Clark
>> ---
>> I finally got around to debugging why things explode so badly without
>> fixing usb_kbd vs. iomux[1] (which this patch applies on top of).
>>
>> [1] https://patchwork.ozlabs.org/patch/818881/
>>
>> common/usb_kbd.c | 30 --
>> 1 file changed, 24 insertions(+), 6 deletions(-)
>>
>> diff --git a/common/usb_kbd.c b/common/usb_kbd.c
>> index 4c3ad95fca..82ad93f6ca 100644
>> --- a/common/usb_kbd.c
>> +++ b/common/usb_kbd.c
>> @@ -535,22 +535,40 @@ static int probe_usb_keyboard(struct usb_device *dev)
>> error = iomux_doenv(stdin, stdinname);
>> free(newstdin);
>> if (error)
>> - return error;
>> + goto unregister_stdio;
>> } else {
>> /* Check if this is the standard input device. */
>> - if (strcmp(stdinname, DEVNAME))
>> - return 1;
>> + if (strcmp(stdinname, DEVNAME)) {
>> + error = -1;
>
> Could we use some meaningful errno?
suggestions welcome.. I wasn't sure what to pick so I just went with <0
>> + goto unregister_stdio;
>> + }
>>
>> /* Reassign the console */
>> - if (overwrite_console())
>> - return 1;
>> + if (overwrite_console()) {
>> + error = -1;
>> + goto unregister_stdio;
>> + }
>>
>> error = console_assign(stdin, DEVNAME);
>> if (error)
>> - return error;
>> + goto unregister_stdio;
>> }
>>
>> return 0;
>> +
>> +unregister_stdio:
>> + /*
>> +* If probe fails, the device will be removed.. leaving dangling
>> +* pointers if the stdio device is not unregistered. If u-boot
>
> nits: U-Boot
>
>> +* is built without stdio_deregister(), just pretend to succeed
>> +* in order to avoid dangling pointers.
>> +*/
>> +#if CONFIG_IS_ENABLED(SYS_STDIO_DEREGISTER)
>> + stdio_deregister(DEVNAME, 1);
>> + return error;
>> +#else
>> + return 0;
>
> Don't understand why 'return 0' here if probe fails...
see above comment, basically we can't fail after we've registered the
stdio device unless we can remove it. Suggestions welcome on better
wording for the comment if it wasn't clear
BR,
-R
>> +#endif
>> }
>>
>> #ifndef CONFIG_DM_USB
>> --
>
> Regards,
> Bin
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] distro: load FDT from any partition on boot device
On Thu, Oct 5, 2017 at 8:39 AM, Alexander Graf wrote:
>
>
> On 04.10.17 22:16, Rob Clark wrote:
>>
>> In the EFI_LOADER boot path, we were only checking the FAT partition
>> containing the EFI payload for dtb files. But this is somewhat of a
>> fiction. In reality there will be one small (V)FAT partition containing
>> grub (or whatever the payload may be), and a second boot partition
>> containing kernel/initrd/fdt (typically ext4). It is this second
>> partition where we should be looking for a FDT to load.
>>
>> So instead scan all the partitions of the disk containing the EFI
>> payload. This matches where grub looks for kernel/initrd (barring
>> custom grub.cfg, in which case the user can use grub's 'devicetree'
>> command to load the correct FDT).
>>
>> The other option is somehow passing the ${fdtfile} to grub so that it
>> can load the FDT based on selected kernel version location (which grub
>> knows) and SoC/board specific ${fdtfile} (which grub does not know).
>>
>> Signed-off-by: Rob Clark
>> ---
>> include/config_distro_bootcmd.h | 34 +++---
>> 1 file changed, 23 insertions(+), 11 deletions(-)
>>
>> diff --git a/include/config_distro_bootcmd.h
>> b/include/config_distro_bootcmd.h
>> index e232a62996..58b2fe3371 100644
>> --- a/include/config_distro_bootcmd.h
>> +++ b/include/config_distro_bootcmd.h
>> @@ -126,25 +126,37 @@
>> "fi\0"
>> \
>> \
>> "load_efi_dtb="
>> \
>> - "load ${devtype} ${devnum}:${distro_bootpart} "
>> \
>> - "${fdt_addr_r} ${prefix}${efi_fdtfile}\0"
>> \
>> + "load ${devtype} ${devnum}:${dtb_devp} "
>> \
>> + "${fdt_addr_r} ${prefix}${efi_fdtfile} && "
>> \
>> + "run boot_efi_binary\0"
>> \
>> \
>> "efi_dtb_prefixes=/ /dtb/ /dtb/current/\0"
>> \
>> - "scan_dev_for_efi="
>> \
>> + "scan_dev_for_dtb="
>> \
>> "setenv efi_fdtfile ${fdtfile}; "
>> \
>> BOOTENV_EFI_SET_FDTFILE_FALLBACK
>> \
>> - "for prefix in ${efi_dtb_prefixes}; do "
>> \
>> - "if test -e ${devtype} "
>> \
>> - "${devnum}:${distro_bootpart} "
>> \
>> - "${prefix}${efi_fdtfile}; then "
>> \
>> - "run load_efi_dtb; "
>> \
>> - "fi;"
>> \
>> - "done;"
>> \
>> + "part list ${devtype} ${devnum} dtb_devplist; "
>> \
>
>
> part list spawns 128 error messages for me on a USB stick with an iso dd'ed
> onto it. I'm not sure we want to do that twice during boot.
I'm not sure how to avoid doing two 'part list's since one we want to
find *all* the partitions, not just the -bootable ones..
I'd suggest you might be better off fixing the root problem here ;-)
>> + "env exists dtb_devplist || setenv dtb_devplist "
>> \
>> + "${distro_bootpart}; "
>> \
>> + "for dtb_devp in ${dtb_devplist}; do "
>> \
>> + "for prefix in ${efi_dtb_prefixes}; do "
>> \
>> + "if test -e ${devtype} "
>> \
>> + "${devnum}:${dtb_devp} "
>> \
>> +
>> "${prefix}${efi_fdtfile};"\
>> + " then "
>> \
>> + "echo Found DTB ${devtype} "
>> \
>> + "${devnum}:${dtb_devp} "
>> \
>> +
>> "${prefix}${efi_fdtfile};"\
>> + "run load_efi_dtb; "
>> \
>> + "fi;"
>> \
>> + "done; "
>> \
>> + "done; "
>> \
>> + "run boot_efi_binary\0"
>> \
>
>
> This will run the EFI binary twice if we find a DT on disk. Or really
> nr_dtb_parts_found + 1 times :).
only if the EFI binary returns, which isn't usually going to be the
case for distro boot
That said, if grub scripting supported "break", this would make this much easier
> We also don't want to loop through 50 other partitions if the 1st one
> already contained a dtb. Instead the loop really should end after the first
> successful boot attempt on that device.
>
> (other distro targets should still get boot attempts, you may want to exit
> grub from dhcp to enter grub on scsi).
>
> Furthermore I remember that Andreas worked in that area too before, let's
> make sure to CC him.
If someone has a better patch, then I'm fine to go with that. I just
needed something to get fedora booting
BR,
-R
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] disk: part_dos: Use the original allocation scheme for the SPL case
On Thu, Oct 5, 2017 at 12:36 AM, Jonathan Gray wrote:
> On Wed, Oct 04, 2017 at 01:12:48PM -0400, Rob Clark wrote:
>> On Wed, Oct 4, 2017 at 12:29 PM, Fabio Estevam wrote:
>> > Since commit ff98cb90514d ("part: extract MBR signature from partitions")
>> > SPL boot on i.MX6 starts to fail:
>> >
>> > U-Boot SPL 2017.09-00221-g0d6ab32 (Oct 02 2017 - 15:13:19)
>> > Trying to boot from MMC1
>> > (keep in loop)
>> >
>> > Use the original allocation scheme for the SPL case, so that MX6 boards
>> > can boot again.
>> >
>> > This is a temporary solution to avoid the boot regression.
>> >
>> > Signed-off-by: Fabio Estevam
>> > ---
>> > Hi Tom,
>> >
>> > I do not have time this week to further investigate and narrow down
>> > this problem.
>> >
>> > Using the old allocation scheme fixes the mx6 SPL boot problem.
>> >
>>
>> Hi Tom, if you are ok with this as a temporary fix, then this is:
>>
>> Acked-by: Rob Clark
>>
>> I'm getting some help from some of the fedora-arm folks so hopefully I
>> can get some idea what is going wrong, but I'd like to unblock folks
>> w/ mx6 boards..
>>
>> BR,
>> -R
>
> This does not seem to be a complete fix, cubox is still broken when
> U-Boot proper loads, unless the efi loader commits are to blame
> for introducing unaligned accesses.
>
> Works with 2017.09.
>
> U-Boot SPL 2017.11-rc1-00026-g14b55fc833 (Oct 05 2017 - 15:17:47)
> Trying to boot from MMC1
>
>
> U-Boot 2017.11-rc1-00026-g14b55fc833 (Oct 05 2017 - 15:17:47 +1100)
>
> CPU: Freescale i.MX6Q rev1.5 996 MHz (running at 792 MHz)
> CPU: Extended Commercial temperature grade (-20C to 105C) at 34C
> Reset cause: WDOG
> Board: MX6 Cubox-i
> DRAM: 2 GiB
> MMC: FSL_SDHC: 0
> *** Warning - bad CRC, using default environment
>
> No panel detected: default to HDMI
> Display: HDMI (1024x768)
> In:serial
> Out: serial
> Err: serial
> Net: FEC
> Hit any key to stop autoboot: 0
> switch to partitions #0, OK
> mmc0 is current device
> Scanning mmc 0:1...
I don't think any efi_loader code is running here, you would see a message like:
## Starting EFI application at XYZ
But to be sure you can disable CONFIG_EFI_LOADER in menuconfig to confirm.
I guess this is some unrelated change. I suspect Tom's change to
malloc the fat_itr's which would make the buffers used for
fs_exists()/etc not cache aligned. I thought there was a patch
floating around to change that to memalign().
BR,
-R
> CACHE: Misaligned operation at range [8f89da30, 8f89e230]
> CACHE: Misaligned operation at range [8f89da30, 8f89e230]
> ERROR: v7_outer_cache_inval_range - start address is not aligned - 0x8f89da30
> ERROR: v7_outer_cache_inval_range - stop address is not aligned - 0x8f89e230
> CACHE: Misaligned operation at range [8f89da30, 8f89e230]
> CACHE: Misaligned operation at range [8f89da30, 8f89e230]
> ERROR: v7_outer_cache_inval_range - start address is not aligned - 0x8f89da30
> ERROR: v7_outer_cache_inval_range - stop address is not aligned - 0x8f89e230
> CACHE: Misaligned operation at range [8f89dca0, 8f89e4a0]
> CACHE: Misaligned operation at range [8f89dca0, 8f89e4a0]
> CACHE: Misaligned operation at range [8f89dca0, 8f89e4a0]
> CACHE: Misaligned operation at range [8f89dca0, 8f89e4a0]
> CACHE: Misaligned operation at range [8f89dc68, 8f89e468]
> CACHE: Misaligned operation at range [8f89dc68, 8f89e468]
> ERROR: v7_outer_cache_inval_range - start address is not aligned - 0x8f89dc68
> ERROR: v7_outer_cache_inval_range - stop address is not aligned - 0x8f89e468
> CACHE: Misaligned operation at range [8f89dc68, 8f89e468]
> CACHE: Misaligned operation at range [8f89dc68, 8f89e468]
> ERROR: v7_outer_cache_inval_range - start address is not aligned - 0x8f89dc68
> ERROR: v7_outer_cache_inval_range - stop address is not aligned - 0x8f89e468
> CACHE: Misaligned operation at range [8f89dab0, 8f89e2b0]
> CACHE: Misaligned operation at range [8f89dab0, 8f89e2b0]
> ERROR: v7_outer_cache_inval_range - start address is not aligned - 0x8f89dab0
> ERROR: v7_outer_cache_inval_range - stop address is not aligned - 0x8f89e2b0
> CACHE: Misaligned operation at range [8f89dab0, 8f89e2b0]
> CACHE: Misaligned operation at range [8f89dab0, 8f89e2b0]
> ERROR: v7_outer_cache_inval_range - start address is not aligned - 0x8f89dab0
> ERROR: v7_outer_cache_inval_range - stop address is not aligned - 0x8f89e2b0
> CACHE: Misaligned operation at range [8f89dca8, 8f89e4a8]
> CACHE: Misaligned operation at range [8f89dca8, 8f89e4a8]
> ERROR: v7_outer_cache_inval_range - start address is not al
Re: [U-Boot] [PATCH v1 08/12] efi_loader: console support for color attributes
On Wed, Oct 4, 2017 at 8:00 PM, Rob Clark wrote:
> On Wed, Oct 4, 2017 at 7:53 PM, Heinrich Schuchardt
> wrote:
>> On 10/05/2017 01:19 AM, Rob Clark wrote:
>>> On Wed, Oct 4, 2017 at 6:01 PM, Heinrich Schuchardt
>>> wrote:
>>>> On 10/04/2017 10:54 PM, Rob Clark wrote:
>>>>> On Wed, Oct 4, 2017 at 2:53 PM, Heinrich Schuchardt
>>>>> wrote:
>>>>>> On 09/10/2017 03:22 PM, Rob Clark wrote:
>>>>>>> Shell.efi uses this, and supporting color attributes makes things look
>>>>>>> nicer. Map the EFI fg/bg color attributes to ANSI escape sequences.
>>>>>>> Not all colors have a perfect match, but spec just says "Devices
>>>>>>> supporting a different number of text colors are required to emulate the
>>>>>>> above colors to the best of the device’s capabilities".
>>>>>>>
>>>>>>> Signed-off-by: Rob Clark
>>>>>>> ---
>>>>>>> include/efi_api.h| 29 +
>>>>>>> lib/efi_loader/efi_console.c | 30 ++
>>>>>>> 2 files changed, 59 insertions(+)
>>>>>>>
>>>>>>> diff --git a/include/efi_api.h b/include/efi_api.h
>>>>>>> index 87c8ffe68e..3cc1dbac2e 100644
>>>>>>> --- a/include/efi_api.h
>>>>>>> +++ b/include/efi_api.h
>>>>>>> @@ -426,6 +426,35 @@ struct simple_text_output_mode {
>>>>>>> EFI_GUID(0x387477c2, 0x69c7, 0x11d2, \
>>>>>>>0x8e, 0x39, 0x0, 0xa0, 0xc9, 0x69, 0x72, 0x3b)
>>>>>>>
>>>>>>> +#define EFI_BLACK0x00
>>>>>>> +#define EFI_BLUE 0x01
>>>>>>> +#define EFI_GREEN0x02
>>>>>>> +#define EFI_CYAN 0x03
>>>>>>> +#define EFI_RED 0x04
>>>>>>> +#define EFI_MAGENTA 0x05
>>>>>>> +#define EFI_BROWN0x06
>>>>>>> +#define EFI_LIGHTGRAY0x07
>>>>>>> +#define EFI_BRIGHT 0x08
>>>>>>> +#define EFI_DARKGRAY 0x08
>>>>>>> +#define EFI_LIGHTBLUE0x09
>>>>>>> +#define EFI_LIGHTGREEN 0x0a
>>>>>>> +#define EFI_LIGHTCYAN0x0b
>>>>>>> +#define EFI_LIGHTRED 0x0c
>>>>>>> +#define EFI_LIGHTMAGENTA 0x0d
>>>>>>> +#define EFI_YELLOW 0x0e
>>>>>>> +#define EFI_WHITE0x0f
>>>>>>> +#define EFI_BACKGROUND_BLACK 0x00
>>>>>>> +#define EFI_BACKGROUND_BLUE 0x10
>>>>>>> +#define EFI_BACKGROUND_GREEN 0x20
>>>>>>> +#define EFI_BACKGROUND_CYAN 0x30
>>>>>>> +#define EFI_BACKGROUND_RED 0x40
>>>>>>> +#define EFI_BACKGROUND_MAGENTA 0x50
>>>>>>> +#define EFI_BACKGROUND_BROWN 0x60
>>>>>>> +#define EFI_BACKGROUND_LIGHTGRAY 0x70
>>>>>>
>>>>>> Will we ever use these constants?
>>>>>>
>>>>>
>>>>> possibly not, but it is useful to understand what is going on with
>>>>> efi->ansi mapping, so I would prefer to keep them.
>>>>>
>>>>>>
>>>>>> Where are the comments explaining the defines below?
>>>>>>
>>>>>>> +
>>>>>>> +#define EFI_ATTR_FG(attr)((attr) & 0x0f)
>>>>>>
>>>>>> This saves 8 entries in the table below.
>>>>>> +#define EFI_ATTR_FG(attr)((attr) & 0x07)
>>>>>>
>>>>>>> +#define EFI_ATTR_BG(attr)(((attr) >> 4) & 0x7)
>>>>>>
>>>>>> Add
>>>>>> #define EFI_ATTR_BOLD(attr) (((attr) >> 3) & 0x01)
>>>>>>
>>>>>>> +
>>>>>>> struct efi_simple_text_output_protocol {
>>>>>>> void *reset;
>>>>>>> efi_status_t (EFIAPI *output_string)(
>>>>>>> diff --git a/lib/efi_loader/efi_console.c b/lib/efi_loader/efi_console.c
>>>>>>> index 2e13fdc096..fcd65ca488
Re: [U-Boot] [PATCH v1 08/12] efi_loader: console support for color attributes
On Wed, Oct 4, 2017 at 7:53 PM, Heinrich Schuchardt wrote:
> On 10/05/2017 01:19 AM, Rob Clark wrote:
>> On Wed, Oct 4, 2017 at 6:01 PM, Heinrich Schuchardt
>> wrote:
>>> On 10/04/2017 10:54 PM, Rob Clark wrote:
>>>> On Wed, Oct 4, 2017 at 2:53 PM, Heinrich Schuchardt
>>>> wrote:
>>>>> On 09/10/2017 03:22 PM, Rob Clark wrote:
>>>>>> Shell.efi uses this, and supporting color attributes makes things look
>>>>>> nicer. Map the EFI fg/bg color attributes to ANSI escape sequences.
>>>>>> Not all colors have a perfect match, but spec just says "Devices
>>>>>> supporting a different number of text colors are required to emulate the
>>>>>> above colors to the best of the device’s capabilities".
>>>>>>
>>>>>> Signed-off-by: Rob Clark
>>>>>> ---
>>>>>> include/efi_api.h| 29 +
>>>>>> lib/efi_loader/efi_console.c | 30 ++
>>>>>> 2 files changed, 59 insertions(+)
>>>>>>
>>>>>> diff --git a/include/efi_api.h b/include/efi_api.h
>>>>>> index 87c8ffe68e..3cc1dbac2e 100644
>>>>>> --- a/include/efi_api.h
>>>>>> +++ b/include/efi_api.h
>>>>>> @@ -426,6 +426,35 @@ struct simple_text_output_mode {
>>>>>> EFI_GUID(0x387477c2, 0x69c7, 0x11d2, \
>>>>>>0x8e, 0x39, 0x0, 0xa0, 0xc9, 0x69, 0x72, 0x3b)
>>>>>>
>>>>>> +#define EFI_BLACK0x00
>>>>>> +#define EFI_BLUE 0x01
>>>>>> +#define EFI_GREEN0x02
>>>>>> +#define EFI_CYAN 0x03
>>>>>> +#define EFI_RED 0x04
>>>>>> +#define EFI_MAGENTA 0x05
>>>>>> +#define EFI_BROWN0x06
>>>>>> +#define EFI_LIGHTGRAY0x07
>>>>>> +#define EFI_BRIGHT 0x08
>>>>>> +#define EFI_DARKGRAY 0x08
>>>>>> +#define EFI_LIGHTBLUE0x09
>>>>>> +#define EFI_LIGHTGREEN 0x0a
>>>>>> +#define EFI_LIGHTCYAN0x0b
>>>>>> +#define EFI_LIGHTRED 0x0c
>>>>>> +#define EFI_LIGHTMAGENTA 0x0d
>>>>>> +#define EFI_YELLOW 0x0e
>>>>>> +#define EFI_WHITE0x0f
>>>>>> +#define EFI_BACKGROUND_BLACK 0x00
>>>>>> +#define EFI_BACKGROUND_BLUE 0x10
>>>>>> +#define EFI_BACKGROUND_GREEN 0x20
>>>>>> +#define EFI_BACKGROUND_CYAN 0x30
>>>>>> +#define EFI_BACKGROUND_RED 0x40
>>>>>> +#define EFI_BACKGROUND_MAGENTA 0x50
>>>>>> +#define EFI_BACKGROUND_BROWN 0x60
>>>>>> +#define EFI_BACKGROUND_LIGHTGRAY 0x70
>>>>>
>>>>> Will we ever use these constants?
>>>>>
>>>>
>>>> possibly not, but it is useful to understand what is going on with
>>>> efi->ansi mapping, so I would prefer to keep them.
>>>>
>>>>>
>>>>> Where are the comments explaining the defines below?
>>>>>
>>>>>> +
>>>>>> +#define EFI_ATTR_FG(attr)((attr) & 0x0f)
>>>>>
>>>>> This saves 8 entries in the table below.
>>>>> +#define EFI_ATTR_FG(attr)((attr) & 0x07)
>>>>>
>>>>>> +#define EFI_ATTR_BG(attr)(((attr) >> 4) & 0x7)
>>>>>
>>>>> Add
>>>>> #define EFI_ATTR_BOLD(attr) (((attr) >> 3) & 0x01)
>>>>>
>>>>>> +
>>>>>> struct efi_simple_text_output_protocol {
>>>>>> void *reset;
>>>>>> efi_status_t (EFIAPI *output_string)(
>>>>>> diff --git a/lib/efi_loader/efi_console.c b/lib/efi_loader/efi_console.c
>>>>>> index 2e13fdc096..fcd65ca488 100644
>>>>>> --- a/lib/efi_loader/efi_console.c
>>>>>> +++ b/lib/efi_loader/efi_console.c
>>>>>> @@ -316,12 +316,42 @@ static efi_status_t EFIAPI efi_cout_set_mode(
>>>>>> return EFI_EXIT(EFI_SUCCESS);
>>>>>> }
>>>>>>
>>>>>> +static const struc
Re: [U-Boot] [PATCH v1 08/12] efi_loader: console support for color attributes
On Wed, Oct 4, 2017 at 6:01 PM, Heinrich Schuchardt wrote:
> On 10/04/2017 10:54 PM, Rob Clark wrote:
>> On Wed, Oct 4, 2017 at 2:53 PM, Heinrich Schuchardt
>> wrote:
>>> On 09/10/2017 03:22 PM, Rob Clark wrote:
>>>> Shell.efi uses this, and supporting color attributes makes things look
>>>> nicer. Map the EFI fg/bg color attributes to ANSI escape sequences.
>>>> Not all colors have a perfect match, but spec just says "Devices
>>>> supporting a different number of text colors are required to emulate the
>>>> above colors to the best of the device’s capabilities".
>>>>
>>>> Signed-off-by: Rob Clark
>>>> ---
>>>> include/efi_api.h| 29 +
>>>> lib/efi_loader/efi_console.c | 30 ++
>>>> 2 files changed, 59 insertions(+)
>>>>
>>>> diff --git a/include/efi_api.h b/include/efi_api.h
>>>> index 87c8ffe68e..3cc1dbac2e 100644
>>>> --- a/include/efi_api.h
>>>> +++ b/include/efi_api.h
>>>> @@ -426,6 +426,35 @@ struct simple_text_output_mode {
>>>> EFI_GUID(0x387477c2, 0x69c7, 0x11d2, \
>>>>0x8e, 0x39, 0x0, 0xa0, 0xc9, 0x69, 0x72, 0x3b)
>>>>
>>>> +#define EFI_BLACK0x00
>>>> +#define EFI_BLUE 0x01
>>>> +#define EFI_GREEN0x02
>>>> +#define EFI_CYAN 0x03
>>>> +#define EFI_RED 0x04
>>>> +#define EFI_MAGENTA 0x05
>>>> +#define EFI_BROWN0x06
>>>> +#define EFI_LIGHTGRAY0x07
>>>> +#define EFI_BRIGHT 0x08
>>>> +#define EFI_DARKGRAY 0x08
>>>> +#define EFI_LIGHTBLUE0x09
>>>> +#define EFI_LIGHTGREEN 0x0a
>>>> +#define EFI_LIGHTCYAN0x0b
>>>> +#define EFI_LIGHTRED 0x0c
>>>> +#define EFI_LIGHTMAGENTA 0x0d
>>>> +#define EFI_YELLOW 0x0e
>>>> +#define EFI_WHITE0x0f
>>>> +#define EFI_BACKGROUND_BLACK 0x00
>>>> +#define EFI_BACKGROUND_BLUE 0x10
>>>> +#define EFI_BACKGROUND_GREEN 0x20
>>>> +#define EFI_BACKGROUND_CYAN 0x30
>>>> +#define EFI_BACKGROUND_RED 0x40
>>>> +#define EFI_BACKGROUND_MAGENTA 0x50
>>>> +#define EFI_BACKGROUND_BROWN 0x60
>>>> +#define EFI_BACKGROUND_LIGHTGRAY 0x70
>>>
>>> Will we ever use these constants?
>>>
>>
>> possibly not, but it is useful to understand what is going on with
>> efi->ansi mapping, so I would prefer to keep them.
>>
>>>
>>> Where are the comments explaining the defines below?
>>>
>>>> +
>>>> +#define EFI_ATTR_FG(attr)((attr) & 0x0f)
>>>
>>> This saves 8 entries in the table below.
>>> +#define EFI_ATTR_FG(attr)((attr) & 0x07)
>>>
>>>> +#define EFI_ATTR_BG(attr)(((attr) >> 4) & 0x7)
>>>
>>> Add
>>> #define EFI_ATTR_BOLD(attr) (((attr) >> 3) & 0x01)
>>>
>>>> +
>>>> struct efi_simple_text_output_protocol {
>>>> void *reset;
>>>> efi_status_t (EFIAPI *output_string)(
>>>> diff --git a/lib/efi_loader/efi_console.c b/lib/efi_loader/efi_console.c
>>>> index 2e13fdc096..fcd65ca488 100644
>>>> --- a/lib/efi_loader/efi_console.c
>>>> +++ b/lib/efi_loader/efi_console.c
>>>> @@ -316,12 +316,42 @@ static efi_status_t EFIAPI efi_cout_set_mode(
>>>> return EFI_EXIT(EFI_SUCCESS);
>>>> }
>>>>
>>>> +static const struct {
>>>> + unsigned fg;
>>>> + unsigned bg;
>>>> +} color[] = {
>>>> + { 30, 40 }, /* 0: black */
>>>> + { 34, 44 }, /* 1: blue */
>>>> + { 32, 42 }, /* 2: green */
>>>> + { 36, 46 }, /* 3: cyan */
>>>> + { 31, 41 }, /* 4: red */
>>>> + { 35, 45 }, /* 5: magenta */
>>>> + { 30, 40 }, /* 6: brown, map to black */
>>>
>>> This should be { 33, 43 }
>>>
>>>> + { 37, 47 }, /* 7: light grey, map to white */
>>>
>>> The entries below are redundant.
>>>
>>>> + { 37, 47 }, /* 8: bright, map to white */
>>&g
Re: [U-Boot] [PATCH v1 08/12] efi_loader: console support for color attributes
On Wed, Oct 4, 2017 at 2:53 PM, Heinrich Schuchardt wrote:
> On 09/10/2017 03:22 PM, Rob Clark wrote:
>> Shell.efi uses this, and supporting color attributes makes things look
>> nicer. Map the EFI fg/bg color attributes to ANSI escape sequences.
>> Not all colors have a perfect match, but spec just says "Devices
>> supporting a different number of text colors are required to emulate the
>> above colors to the best of the device’s capabilities".
>>
>> Signed-off-by: Rob Clark
>> ---
>> include/efi_api.h| 29 +
>> lib/efi_loader/efi_console.c | 30 ++
>> 2 files changed, 59 insertions(+)
>>
>> diff --git a/include/efi_api.h b/include/efi_api.h
>> index 87c8ffe68e..3cc1dbac2e 100644
>> --- a/include/efi_api.h
>> +++ b/include/efi_api.h
>> @@ -426,6 +426,35 @@ struct simple_text_output_mode {
>> EFI_GUID(0x387477c2, 0x69c7, 0x11d2, \
>>0x8e, 0x39, 0x0, 0xa0, 0xc9, 0x69, 0x72, 0x3b)
>>
>> +#define EFI_BLACK0x00
>> +#define EFI_BLUE 0x01
>> +#define EFI_GREEN0x02
>> +#define EFI_CYAN 0x03
>> +#define EFI_RED 0x04
>> +#define EFI_MAGENTA 0x05
>> +#define EFI_BROWN0x06
>> +#define EFI_LIGHTGRAY0x07
>> +#define EFI_BRIGHT 0x08
>> +#define EFI_DARKGRAY 0x08
>> +#define EFI_LIGHTBLUE0x09
>> +#define EFI_LIGHTGREEN 0x0a
>> +#define EFI_LIGHTCYAN0x0b
>> +#define EFI_LIGHTRED 0x0c
>> +#define EFI_LIGHTMAGENTA 0x0d
>> +#define EFI_YELLOW 0x0e
>> +#define EFI_WHITE0x0f
>> +#define EFI_BACKGROUND_BLACK 0x00
>> +#define EFI_BACKGROUND_BLUE 0x10
>> +#define EFI_BACKGROUND_GREEN 0x20
>> +#define EFI_BACKGROUND_CYAN 0x30
>> +#define EFI_BACKGROUND_RED 0x40
>> +#define EFI_BACKGROUND_MAGENTA 0x50
>> +#define EFI_BACKGROUND_BROWN 0x60
>> +#define EFI_BACKGROUND_LIGHTGRAY 0x70
>
> Will we ever use these constants?
>
possibly not, but it is useful to understand what is going on with
efi->ansi mapping, so I would prefer to keep them.
>
> Where are the comments explaining the defines below?
>
>> +
>> +#define EFI_ATTR_FG(attr)((attr) & 0x0f)
>
> This saves 8 entries in the table below.
> +#define EFI_ATTR_FG(attr)((attr) & 0x07)
>
>> +#define EFI_ATTR_BG(attr)(((attr) >> 4) & 0x7)
>
> Add
> #define EFI_ATTR_BOLD(attr) (((attr) >> 3) & 0x01)
>
>> +
>> struct efi_simple_text_output_protocol {
>> void *reset;
>> efi_status_t (EFIAPI *output_string)(
>> diff --git a/lib/efi_loader/efi_console.c b/lib/efi_loader/efi_console.c
>> index 2e13fdc096..fcd65ca488 100644
>> --- a/lib/efi_loader/efi_console.c
>> +++ b/lib/efi_loader/efi_console.c
>> @@ -316,12 +316,42 @@ static efi_status_t EFIAPI efi_cout_set_mode(
>> return EFI_EXIT(EFI_SUCCESS);
>> }
>>
>> +static const struct {
>> + unsigned fg;
>> + unsigned bg;
>> +} color[] = {
>> + { 30, 40 }, /* 0: black */
>> + { 34, 44 }, /* 1: blue */
>> + { 32, 42 }, /* 2: green */
>> + { 36, 46 }, /* 3: cyan */
>> + { 31, 41 }, /* 4: red */
>> + { 35, 45 }, /* 5: magenta */
>> + { 30, 40 }, /* 6: brown, map to black */
>
> This should be { 33, 43 }
>
>> + { 37, 47 }, /* 7: light grey, map to white */
>
> The entries below are redundant.
>
>> + { 37, 47 }, /* 8: bright, map to white */
>> + { 34, 44 }, /* 9: light blue, map to blue */
>> + { 32, 42 }, /* A: light green, map to green */
>> + { 36, 46 }, /* B: light cyan, map to cyan */
>> + { 31, 41 }, /* C: light red, map to red */
>> + { 35, 45 }, /* D: light magenta, map to magenta */
>> + { 33, 43 }, /* E: yellow */
>> + { 37, 47 }, /* F: white */
>> +};
>> +
I'm not totally convinced about mapping extra colors that UEFI defines
to bold.. unless you have some example of prior-art for this on other
platforms.
There are ansi extensions that allow for more colors, we could perhaps
map the extra EFI colors to the base sequence (presumably more widely
supported) followed by the extended sequence (which presumably not all
terminal emulators support).. I'm not sure if it is worth the effort.
The current patch implem
[U-Boot] [PATCH] distro: load FDT from any partition on boot device
In the EFI_LOADER boot path, we were only checking the FAT partition
containing the EFI payload for dtb files. But this is somewhat of a
fiction. In reality there will be one small (V)FAT partition containing
grub (or whatever the payload may be), and a second boot partition
containing kernel/initrd/fdt (typically ext4). It is this second
partition where we should be looking for a FDT to load.
So instead scan all the partitions of the disk containing the EFI
payload. This matches where grub looks for kernel/initrd (barring
custom grub.cfg, in which case the user can use grub's 'devicetree'
command to load the correct FDT).
The other option is somehow passing the ${fdtfile} to grub so that it
can load the FDT based on selected kernel version location (which grub
knows) and SoC/board specific ${fdtfile} (which grub does not know).
Signed-off-by: Rob Clark
---
include/config_distro_bootcmd.h | 34 +++---
1 file changed, 23 insertions(+), 11 deletions(-)
diff --git a/include/config_distro_bootcmd.h b/include/config_distro_bootcmd.h
index e232a62996..58b2fe3371 100644
--- a/include/config_distro_bootcmd.h
+++ b/include/config_distro_bootcmd.h
@@ -126,25 +126,37 @@
"fi\0"\
\
"load_efi_dtb=" \
- "load ${devtype} ${devnum}:${distro_bootpart} " \
- "${fdt_addr_r} ${prefix}${efi_fdtfile}\0" \
+ "load ${devtype} ${devnum}:${dtb_devp} " \
+ "${fdt_addr_r} ${prefix}${efi_fdtfile} && " \
+ "run boot_efi_binary\0" \
\
"efi_dtb_prefixes=/ /dtb/ /dtb/current/\0"\
- "scan_dev_for_efi=" \
+ "scan_dev_for_dtb=" \
"setenv efi_fdtfile ${fdtfile}; " \
BOOTENV_EFI_SET_FDTFILE_FALLBACK \
- "for prefix in ${efi_dtb_prefixes}; do " \
- "if test -e ${devtype} " \
- "${devnum}:${distro_bootpart} " \
- "${prefix}${efi_fdtfile}; then " \
- "run load_efi_dtb; " \
- "fi;" \
- "done;" \
+ "part list ${devtype} ${devnum} dtb_devplist; " \
+ "env exists dtb_devplist || setenv dtb_devplist " \
+ "${distro_bootpart}; "\
+ "for dtb_devp in ${dtb_devplist}; do "\
+ "for prefix in ${efi_dtb_prefixes}; do " \
+ "if test -e ${devtype} " \
+ "${devnum}:${dtb_devp} " \
+ "${prefix}${efi_fdtfile};"\
+ " then " \
+ "echo Found DTB ${devtype} " \
+ "${devnum}:${dtb_devp} " \
+ "${prefix}${efi_fdtfile};"\
+ "run load_efi_dtb; " \
+ "fi;" \
+ "done; " \
+ "done; " \
+ "run boot_efi_binary\0" \
+ "scan_dev_for_efi=" \
"if test -e ${devtype} ${devnum}:${distro_bootpart} " \
"efi/boot/"BOOTEFI_NAME"; then " \
"echo Found EFI removable media binary " \
"efi/boot/"BOOTEFI_NAME"; " \
- "run boot_efi_binary; " \
+ "run scan_dev_for_dtb; " \
"echo EFI LOAD FAILED: continuing...; " \
"fi; "\
"setenv efi_fdtfile\0"
--
2.13.5
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v1 03/12] efi_loader: add EFI_UNICODE_COLLATION_PROTOCOL stub
On Wed, Oct 4, 2017 at 1:57 PM, Heinrich Schuchardt wrote:
> On 09/10/2017 03:22 PM, Rob Clark wrote:
>> From: Leif Lindholm
>
> The commit message is missing.
>
> Fix all issues reported by checkpatch.
>
>>
>> Signed-off-by: Leif Lindholm
>> ---
>> include/efi_api.h | 33 +++
>> include/efi_loader.h | 2 ++
>> lib/efi_loader/Makefile | 2 +-
>> lib/efi_loader/efi_boottime.c | 3 ++
>> lib/efi_loader/efi_unicode.c | 73
>> +++
>> 5 files changed, 112 insertions(+), 1 deletion(-)
>> create mode 100644 lib/efi_loader/efi_unicode.c
>>
>> diff --git a/include/efi_api.h b/include/efi_api.h
>> index 932a3429a8..25f774f253 100644
>> --- a/include/efi_api.h
>> +++ b/include/efi_api.h
>> @@ -740,6 +740,39 @@ struct efi_hii_string_protocol
>> UINTN *secondary_languages_size);
>> };
>>
>> +#define EFI_UNICODE_COLLATION_PROTOCOL2_GUID \
>> + EFI_GUID(0xa4c751fc, 0x23ae, 0x4c3e, \
>> + 0x92, 0xe9, 0x49, 0x64, 0xcf, 0x63, 0xf3, 0x49)
>> +
>> +struct efi_unicode_collation_protocol
>> +{
>
> ERROR: open brace '{' following struct go on the same line
> #30: FILE: include/efi_api.h:748:
> +struct efi_unicode_collation_protocol
> +{
>
>> + INTN(EFIAPI *stri_coll)(
>> + struct efi_unicode_collation_protocol *this,
>> + efi_string_t s1,
>> + efi_string_t s2);
>> + bool(EFIAPI *metai_match)(
>> + struct efi_unicode_collation_protocol *this,
>> + efi_string_t string,
>> + efi_string_t pattern);
>> + void(EFIAPI *str_lwr)(
>> + struct efi_unicode_collation_protocol *this,
>> + efi_string_t string);
>> + void(EFIAPI *str_upr)(
>> + struct efi_unicode_collation_protocol *this,
>> + efi_string_t string);
>> + void(EFIAPI *fat_to_str)(
>> + struct efi_unicode_collation_protocol *this,
>> + UINTN fat_size,
>> + uint8_t *fat,
>> + efi_string_t string);
>> + bool(EFIAPI *str_to_fat)(
>> + struct efi_unicode_collation_protocol *this,
>> + efi_string_t string,
>> + UINTN fat_size,
>> + uint8_t *fat);
>> + uint8_t *supported_languages;
>> +};
>> +
>> #define EFI_GOP_GUID \
>> EFI_GUID(0x9042a9de, 0x23dc, 0x4a38, \
>>0x96, 0xfb, 0x7a, 0xde, 0xd0, 0x80, 0x51, 0x6a)
>> diff --git a/include/efi_loader.h b/include/efi_loader.h
>> index a89bb2fcd9..6668338d0b 100644
>> --- a/include/efi_loader.h
>> +++ b/include/efi_loader.h
>> @@ -62,6 +62,7 @@ extern const struct efi_device_path_utilities_protocol
>> efi_device_path_utilities
>> extern const struct efi_hii_config_routing_protocol efi_hii_config_routing;
>> extern const struct efi_hii_database_protocol efi_hii_database;
>> extern const struct efi_hii_string_protocol efi_hii_string;
>> +extern const struct efi_unicode_collation_protocol efi_unicode_collation;
>>
>> uint16_t *efi_dp_str(struct efi_device_path *dp);
>>
>> @@ -76,6 +77,7 @@ extern const efi_guid_t
>> efi_guid_device_path_utilities_protocol;
>> extern const efi_guid_t efi_guid_hii_config_routing_protocol;
>> extern const efi_guid_t efi_guid_hii_database_protocol;
>> extern const efi_guid_t efi_guid_hii_string_protocol;
>> +extern const efi_guid_t efi_guid_unicode_collation_protocol2;
>>
>> extern unsigned int __efi_runtime_start, __efi_runtime_stop;
>> extern unsigned int __efi_runtime_rel_start, __efi_runtime_rel_stop;
>> diff --git a/lib/efi_loader/Makefile b/lib/efi_loader/Makefile
>> index e8fd6823a3..82b703bb39 100644
>> --- a/lib/efi_loader/Makefile
>> +++ b/lib/efi_loader/Makefile
>> @@ -16,7 +16,7 @@ always := $(efiprogs-y)
>> obj-$(CONFIG_CMD_BOOTEFI_HELLO) += helloworld_efi.o
>> obj-y += efi_image_loader.o efi_boottime.o efi_runtime.o efi_console.o
>> obj-y += efi_memory.o efi_device_path_to_text.o efi_device_path.o
>> -obj-y += efi_device_path_utilities.o efi_hii.o
>> +obj-y += efi_device_path_utilities.o efi_hii.o efi_unicode.o
>> obj-y += efi_file.o efi_variable.o efi_bootmgr.o
>> obj-$(CONFIG_LCD) += efi_gop.o
>> obj-$(CONFIG_DM_VIDEO) += efi_gop.o
>> diff --git a/lib/efi_loader/efi_boottime.c b/lib/efi_loader/efi_boottime.c
>> index 4d1a16051b..04358e8aca 100644
>> --- a/lib/efi_loader/efi_boottime.c
>>
Re: [U-Boot] [PATCH] disk: part_dos: Use the original allocation scheme for the SPL case
On Wed, Oct 4, 2017 at 12:29 PM, Fabio Estevam wrote:
> Since commit ff98cb90514d ("part: extract MBR signature from partitions")
> SPL boot on i.MX6 starts to fail:
>
> U-Boot SPL 2017.09-00221-g0d6ab32 (Oct 02 2017 - 15:13:19)
> Trying to boot from MMC1
> (keep in loop)
>
> Use the original allocation scheme for the SPL case, so that MX6 boards
> can boot again.
>
> This is a temporary solution to avoid the boot regression.
>
> Signed-off-by: Fabio Estevam
> ---
> Hi Tom,
>
> I do not have time this week to further investigate and narrow down
> this problem.
>
> Using the old allocation scheme fixes the mx6 SPL boot problem.
>
Hi Tom, if you are ok with this as a temporary fix, then this is:
Acked-by: Rob Clark
I'm getting some help from some of the fedora-arm folks so hopefully I
can get some idea what is going wrong, but I'd like to unblock folks
w/ mx6 boards..
BR,
-R
>
> disk/part_dos.c | 10 ++
> 1 file changed, 10 insertions(+)
>
> diff --git a/disk/part_dos.c b/disk/part_dos.c
> index 1a36be0..6dd2c2d 100644
> --- a/disk/part_dos.c
> +++ b/disk/part_dos.c
> @@ -89,6 +89,7 @@ static int test_block_type(unsigned char *buffer)
>
> static int part_test_dos(struct blk_desc *dev_desc)
> {
> +#ifndef CONFIG_SPL_BUILD
> ALLOC_CACHE_ALIGN_BUFFER(legacy_mbr, mbr, dev_desc->blksz);
>
> if (blk_dread(dev_desc, 0, 1, (ulong *)mbr) != 1)
> @@ -102,6 +103,15 @@ static int part_test_dos(struct blk_desc *dev_desc)
> dev_desc->sig_type = SIG_TYPE_MBR;
> dev_desc->mbr_sig = mbr->unique_mbr_signature;
> }
> +#else
> + ALLOC_CACHE_ALIGN_BUFFER(unsigned char, buffer, dev_desc->blksz);
> +
> + if (blk_dread(dev_desc, 0, 1, (ulong *)buffer) != 1)
> + return -1;
> +
> + if (test_block_type(buffer) != DOS_MBR)
> + return -1;
> +#endif
>
> return 0;
> }
> --
> 2.7.4
>
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 1/1] efi_loader: use type bool for event states
On Wed, Oct 4, 2017 at 12:29 PM, Heinrich Schuchardt wrote:
> On 10/04/2017 05:25 PM, Alexander Graf wrote:
>>
>>
>> On 04.10.17 16:57, Rob Clark wrote:
>>> On Wed, Oct 4, 2017 at 10:46 AM, Heinrich Schuchardt
>>> wrote:
>>>> On 10/04/2017 04:14 PM, Rob Clark wrote:
>>>>> On Wed, Oct 4, 2017 at 9:03 AM, Heinrich Schuchardt
>>>>> wrote:
>>>>>> Queued and signaled describe boolean states of events.
>>>>>> So let's use type bool and rename the structure members to is_queued
>>>>>> and is_signaled.
>>>>>>
>>>>>> Update the comments for is_queued and is_signaled.
>>>>>
>>>>> Reviewed-by: Rob Clark
>>>>>
>>>>> It would be kinda nice to merge my efi_event fixes and rework to use
>>>>> an arbitrary sized list of events before making too many more
>>>>> efi_event changes, since that is kind of annoying to keep rebasing ;-)
>>>>>
>>>>> BR,
>>>>> -R
>>>>
>>>> I would not mind if you patch went first.
>>>>
>>>> But your patch
>>>> https://patchwork.ozlabs.org/patch/812967/
>>>> is not applicable to U-Boot master and needs rebasing anyway.
>>>
>>> jfyi, I have it (and other pending patches) rebased on latest master
>>> (as of ~yesterday) here:
>>>
>>>https://github.com/robclark/u-boot/commits/wip-enough-uefi-for-shell
>>>
>>> I wasn't planning on resending until I get further with FAT write
>>> stuff (currently on a local branch, although I might not get much time
>>> to work on in the next week or two).. although I can re-send it or any
>>> of the other patches to get Shell.efi working if wanted. (Note that
>>> I'm also using your patch for efi watchdog support, that was one of
>>> the other required bits.)
>>>
>>> Not sure what agraf's plan is but I think the needed bits for
>>> Shell.efi are mergable already.
>>
>> I don't have a concrete plan - in general I consider patches that have
>> unaddressed review comments as "not to be applied atm" though and I'm
>> not sure I have anything pending from you that would not fall into that
>> category :).
>>
>> Can you split off a series that has Heinrich's blessing to get us as far
>> as we can, so we can keep your queue short?
>>
>
> These are the two first patches in Rob's queue:
>
> efi_loader: support 16 protocols per efi_object
> https://patchwork.ozlabs.org/patch/806167/
>
> efi_loader: allow creating new handles
> https://patchwork.ozlabs.org/patch/806173/
btw, you can add for these two:
Reviewed-by: Rob Clark
> Please, merge these.
>
> I am aware that we need to convert the protocols list to a linked list
> and will do so in a later patch.
>
> Please, also merge this patch that definitively does not interfere with
> Rob's work:
>
> efi_selftest: enable CONFIG_CMD_BOOTEFI_SELFTEST
> https://patchwork.ozlabs.org/patch/816412/
>
> Best regards
>
> Heinrich
>
>>>
>>>> Please, add the missing check that the event pointer is valid.
>>>> The EFI code checks other arguments rigorously so we should do the same
>>>> for pointers. It would be very hard to debug a problem in an EFI
>>>> application otherwise.
>>>
>>> I'm a bit undecided on this, since we have other places where there is
>>> no good way to check the validity of a pointer. (For example file or
>>> disk objects.) I was thinking about perhaps implementing a
>>> compile-time optional feature using a hashtable to map objects to type
>>> so we can add in some type checking, at the expense of extra runtime
>>> overhead. Probably not something you'd want to ship enabled, but it
>>> would be useful for debugging.
>>
>> Feel free to implement just the boilerplate for it with a function that
>> always returns true:
>>
>> static int efi_ptr_valid(void *foo)
>> {
>> return 1;
>> }
>>
>> which we can then later on improve to do actual checking if we care. The
>> least we can do is probably to check for alignment problems.
>>
>>
>> Alex
>>
>
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 1/1] efi_loader: use type bool for event states
On Wed, Oct 4, 2017 at 12:02 PM, Heinrich Schuchardt wrote: > On 10/04/2017 04:57 PM, Rob Clark wrote: >> On Wed, Oct 4, 2017 at 10:46 AM, Heinrich Schuchardt >> wrote: >>> On 10/04/2017 04:14 PM, Rob Clark wrote: >>>> On Wed, Oct 4, 2017 at 9:03 AM, Heinrich Schuchardt >>>> wrote: >>>>> Queued and signaled describe boolean states of events. >>>>> So let's use type bool and rename the structure members to is_queued >>>>> and is_signaled. >>>>> >>>>> Update the comments for is_queued and is_signaled. >>>> >>>> Reviewed-by: Rob Clark >>>> >>>> It would be kinda nice to merge my efi_event fixes and rework to use >>>> an arbitrary sized list of events before making too many more >>>> efi_event changes, since that is kind of annoying to keep rebasing ;-) >>>> >>>> BR, >>>> -R >>> >>> I would not mind if you patch went first. >>> >>> But your patch >>> https://patchwork.ozlabs.org/patch/812967/ >>> is not applicable to U-Boot master and needs rebasing anyway. >> >> jfyi, I have it (and other pending patches) rebased on latest master >> (as of ~yesterday) here: >> >> https://github.com/robclark/u-boot/commits/wip-enough-uefi-for-shell > > You have a Travis CI build error. Could you, please, fix that. > > efi_loader: implement SetWatchdogTimer > is the last patch in your branch that is not called "HACK ...". > > So could you, please, prepare a branch that ends here and let Travis > test it. > >> >> I wasn't planning on resending until I get further with FAT write >> stuff (currently on a local branch, although I might not get much time >> to work on in the next week or two).. although I can re-send it or any >> of the other patches to get Shell.efi working if wanted. (Note that >> I'm also using your patch for efi watchdog support, that was one of >> the other required bits.) > > I have also a lot of patches in the pipeline. We should not block each > other. So, please, either resend the patch series (but please nothing > called HACK) for review now or let my patches below enter efi-next. sorry, I didn't have time to push the non "wip-" version of the branch (which does not have other patches+hacks to make things work on db410c), but ofc I wouldn't send those as part of a patchset btw, did you plan any further changes for your watchdog patch? I've rebased it already, but let me know if I should pull in something newer. > Some review comments for your branch: > > Patch efi_loader: add stub HII protocols uses UINTN heavily. In a recent > comment Simon remarked that types should not be uppercase. So I was > planning to replace all occurences of UINTN by size_t in an upcoming patch. ok, I also wanted to clean up efi strings and introduce a typedef for efi 16b chars too.. and this might be easier just to do on top of the other patches. If you were planning on doing this before the weekend, I'll rebase on top.. if you weren't going to have time for it in the next week or so I can take a stab at it. I guess both the cleanups are just a big chunk of mechanical churn, but otherwise not so difficult. > Patch efi_loader: add EFI_UNICODE_COLLATION_PROTOCOL stub > has EFI_EXIT(0). We should yuse a constant like EFI_SUCCESS here. > > In patch efi_loader: Decouple EFI input/output from stdin/stdout > the commit message is insufficient. Please, explain how the output > device will be controlled. I am managing my machines remotely via > serial. Some of my machines have video but not monitor attached. I would > not be able to accept no longer seeing EFI output on my serial. ok.. fwiw, this introduces two new env vars, efiin and efiout, so you can still configure output/input as you prefer. I was planning to add efiout=vidconsole\0efiin=usbkbd to include/configs/dragonboard410c (although maybe there is a better place.. either way setting the vars isn't part of this patch) > Patch efi_loader: fix events > still has the TODO text that you wanted to remove. And of cause the > missing pointer validity check. I did update the TODO text to clarify better, but I could remove it. It was mostly an idea for a future optimization which might (or might not) be useful, not something I was planning to add as part of this patch. BR, -R > Best regards > > Heinrich > >> >> Not sure what agraf's plan is but I think the needed bits for >> Shell.efi are mergable already. >> >>> Please, add the missing check that the event pointer is valid. >>> The EFI code checks other a
Re: [U-Boot] [PATCH 1/1] efi_loader: use type bool for event states
On Wed, Oct 4, 2017 at 11:25 AM, Alexander Graf wrote:
>
>
> On 04.10.17 16:57, Rob Clark wrote:
>>
>> On Wed, Oct 4, 2017 at 10:46 AM, Heinrich Schuchardt
>> wrote:
>>>
>>> On 10/04/2017 04:14 PM, Rob Clark wrote:
>>>>
>>>> On Wed, Oct 4, 2017 at 9:03 AM, Heinrich Schuchardt
>>>> wrote:
>>>>>
>>>>> Queued and signaled describe boolean states of events.
>>>>> So let's use type bool and rename the structure members to is_queued
>>>>> and is_signaled.
>>>>>
>>>>> Update the comments for is_queued and is_signaled.
>>>>
>>>>
>>>> Reviewed-by: Rob Clark
>>>>
>>>> It would be kinda nice to merge my efi_event fixes and rework to use
>>>> an arbitrary sized list of events before making too many more
>>>> efi_event changes, since that is kind of annoying to keep rebasing ;-)
>>>>
>>>> BR,
>>>> -R
>>>
>>>
>>> I would not mind if you patch went first.
>>>
>>> But your patch
>>> https://patchwork.ozlabs.org/patch/812967/
>>> is not applicable to U-Boot master and needs rebasing anyway.
>>
>>
>> jfyi, I have it (and other pending patches) rebased on latest master
>> (as of ~yesterday) here:
>>
>>https://github.com/robclark/u-boot/commits/wip-enough-uefi-for-shell
>>
>> I wasn't planning on resending until I get further with FAT write
>> stuff (currently on a local branch, although I might not get much time
>> to work on in the next week or two).. although I can re-send it or any
>> of the other patches to get Shell.efi working if wanted. (Note that
>> I'm also using your patch for efi watchdog support, that was one of
>> the other required bits.)
>>
>> Not sure what agraf's plan is but I think the needed bits for
>> Shell.efi are mergable already.
>
>
> I don't have a concrete plan - in general I consider patches that have
> unaddressed review comments as "not to be applied atm" though and I'm not
> sure I have anything pending from you that would not fall into that category
> :).
>
> Can you split off a series that has Heinrich's blessing to get us as far as
> we can, so we can keep your queue short?
>
>>
>>> Please, add the missing check that the event pointer is valid.
>>> The EFI code checks other arguments rigorously so we should do the same
>>> for pointers. It would be very hard to debug a problem in an EFI
>>> application otherwise.
>>
>>
>> I'm a bit undecided on this, since we have other places where there is
>> no good way to check the validity of a pointer. (For example file or
>> disk objects.) I was thinking about perhaps implementing a
>> compile-time optional feature using a hashtable to map objects to type
>> so we can add in some type checking, at the expense of extra runtime
>> overhead. Probably not something you'd want to ship enabled, but it
>> would be useful for debugging.
>
>
> Feel free to implement just the boilerplate for it with a function that
> always returns true:
>
> static int efi_ptr_valid(void *foo)
> {
> return 1;
> }
that is reasonable.. I do think we want something to identify types
(which could just be a unique global/const ptr for now), so like:
static inline bool efi_ptr_valid(void *ptr, efi_type_t *type)
(which would let us change what a type is later if we needed)
I'll try to cook something up (which might not be until the weekend..
still getting caught up after two weeks of conferences)
BR,
-R
> which we can then later on improve to do actual checking if we care. The
> least we can do is probably to check for alignment problems.
>
>
> Alex
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 1/1] efi_loader: use type bool for event states
On Wed, Oct 4, 2017 at 10:46 AM, Heinrich Schuchardt wrote: > On 10/04/2017 04:14 PM, Rob Clark wrote: >> On Wed, Oct 4, 2017 at 9:03 AM, Heinrich Schuchardt >> wrote: >>> Queued and signaled describe boolean states of events. >>> So let's use type bool and rename the structure members to is_queued >>> and is_signaled. >>> >>> Update the comments for is_queued and is_signaled. >> >> Reviewed-by: Rob Clark >> >> It would be kinda nice to merge my efi_event fixes and rework to use >> an arbitrary sized list of events before making too many more >> efi_event changes, since that is kind of annoying to keep rebasing ;-) >> >> BR, >> -R > > I would not mind if you patch went first. > > But your patch > https://patchwork.ozlabs.org/patch/812967/ > is not applicable to U-Boot master and needs rebasing anyway. jfyi, I have it (and other pending patches) rebased on latest master (as of ~yesterday) here: https://github.com/robclark/u-boot/commits/wip-enough-uefi-for-shell I wasn't planning on resending until I get further with FAT write stuff (currently on a local branch, although I might not get much time to work on in the next week or two).. although I can re-send it or any of the other patches to get Shell.efi working if wanted. (Note that I'm also using your patch for efi watchdog support, that was one of the other required bits.) Not sure what agraf's plan is but I think the needed bits for Shell.efi are mergable already. > Please, add the missing check that the event pointer is valid. > The EFI code checks other arguments rigorously so we should do the same > for pointers. It would be very hard to debug a problem in an EFI > application otherwise. I'm a bit undecided on this, since we have other places where there is no good way to check the validity of a pointer. (For example file or disk objects.) I was thinking about perhaps implementing a compile-time optional feature using a hashtable to map objects to type so we can add in some type checking, at the expense of extra runtime overhead. Probably not something you'd want to ship enabled, but it would be useful for debugging. BR, -R > @Alexander > I guess with Suseconf you were quite busy in the last weeks. Did you > already make up your mind in which sequence we should prepare the EFI > patches? > > The following of my patches could be directly applied to efi-next: > > [U-Boot,1/1] efi_selftest: enable CONFIG_CMD_BOOTEFI_SELFTEST > https://patchwork.ozlabs.org/patch/816412/ > [U-Boot,1/1] efi_loader: replace efi_div10 by div64_u64 > https://patchwork.ozlabs.org/patch/820731/ > [U-Boot,1/1] efi_selftest: use efi_st_error for all error messages > https://patchwork.ozlabs.org/patch/821237/ > [U-Boot,1/1] efi_loader: use type bool for event states > https://patchwork.ozlabs.org/patch/821302/ > [U-Boot,v2,1/1] efi_selftest: make tests easier to read > https://patchwork.ozlabs.org/patch/821306/ > > I guess Rob was refering to > [U-Boot,1/1] efi_loader: use type bool for event states > > Best regards > > Heinrich ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] disk: Don't assume blksz > legacy_mbr
On Wed, Oct 4, 2017 at 10:27 AM, Fabio Estevam wrote: > Hi Rob, > > On Wed, Oct 4, 2017 at 11:11 AM, Rob Clark wrote: > >> btw, I'm still hoping someone can get me some logs so I can see what >> blksz is, etc, on these boards.. > > Sorry, I haven't been able to get you the logs yet. > > I will probably be able to work on this next week only, unfortunately. > > I am adding some mx6 folks in case they could help collecting such > logs in the meantime. > > Just to provide them some context: we are investigating the mx6 SPL > regression in mainline. > >> in the worst case I guess we can change part_test_dos() to: >> >> #ifdef SPL >> .. old code .. >> #else >> .. new code .. >> #endif >> a bit ugly, but at least that wouldn't break efi_bootmgr plus boards >> with multiple "disks".. having the proper partition signatures I guess >> doesn't matter in the SPL stage.. > > Yes, this is what I have locally to workaround the issue: > https://pastebin.com/XxBfpwh7 > Not sure Tom's opinion, but I'd be ok with applying this patch, even if just a temporary fix, to unblock folks trying to test latest u-boot on these devices BR, -R ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 1/1] efi_loader: use type bool for event states
On Wed, Oct 4, 2017 at 9:03 AM, Heinrich Schuchardt wrote:
> Queued and signaled describe boolean states of events.
> So let's use type bool and rename the structure members to is_queued
> and is_signaled.
>
> Update the comments for is_queued and is_signaled.
Reviewed-by: Rob Clark
It would be kinda nice to merge my efi_event fixes and rework to use
an arbitrary sized list of events before making too many more
efi_event changes, since that is kind of annoying to keep rebasing ;-)
BR,
-R
> Reported-by: Simon Glass
> Signed-off-by: Heinrich Schuchardt
> ---
> include/efi_loader.h | 8
> lib/efi_loader/efi_boottime.c | 32
> lib/efi_loader/efi_console.c | 2 +-
> 3 files changed, 21 insertions(+), 21 deletions(-)
>
> diff --git a/include/efi_loader.h b/include/efi_loader.h
> index 2f081f8996..1148db2b00 100644
> --- a/include/efi_loader.h
> +++ b/include/efi_loader.h
> @@ -136,8 +136,8 @@ struct efi_object {
> * @nofify_function: Function to call when the event is triggered
> * @notify_context:Data to be passed to the notify function
> * @trigger_type: Type of timer, see efi_set_timer
> - * @queued:The notification functionis queued
> - * @signaled: The event occured
> + * @queued:The notification function is queued
> + * @signaled: The event occurred. The event is in the signaled
> state.
> */
> struct efi_event {
> uint32_t type;
> @@ -147,8 +147,8 @@ struct efi_event {
> u64 trigger_next;
> u64 trigger_time;
> enum efi_timer_delay trigger_type;
> - int queued;
> - int signaled;
> + bool is_queued;
> + bool is_signaled;
> };
>
>
> diff --git a/lib/efi_loader/efi_boottime.c b/lib/efi_loader/efi_boottime.c
> index d63c66dd45..8975fc4ec1 100644
> --- a/lib/efi_loader/efi_boottime.c
> +++ b/lib/efi_loader/efi_boottime.c
> @@ -132,14 +132,14 @@ const char *__efi_nesting_dec(void)
> void efi_signal_event(struct efi_event *event)
> {
> if (event->notify_function) {
> - event->queued = 1;
> + event->is_queued = true;
> /* Check TPL */
> if (efi_tpl >= event->notify_tpl)
> return;
> EFI_CALL_VOID(event->notify_function(event,
> event->notify_context));
> }
> - event->queued = 0;
> + event->is_queued = false;
> }
>
> static efi_status_t efi_unsupported(const char *funcname)
> @@ -267,8 +267,8 @@ efi_status_t efi_create_event(uint32_t type, UINTN
> notify_tpl,
> efi_events[i].notify_context = notify_context;
> /* Disable timers on bootup */
> efi_events[i].trigger_next = -1ULL;
> - efi_events[i].queued = 0;
> - efi_events[i].signaled = 0;
> + efi_events[i].is_queued = false;
> + efi_events[i].is_signaled = false;
> *event = &efi_events[i];
> return EFI_SUCCESS;
> }
> @@ -301,7 +301,7 @@ void efi_timer_check(void)
> for (i = 0; i < ARRAY_SIZE(efi_events); ++i) {
> if (!efi_events[i].type)
> continue;
> - if (efi_events[i].queued)
> + if (efi_events[i].is_queued)
> efi_signal_event(&efi_events[i]);
> if (!(efi_events[i].type & EVT_TIMER) ||
> now < efi_events[i].trigger_next)
> @@ -317,7 +317,7 @@ void efi_timer_check(void)
> default:
> continue;
> }
> - efi_events[i].signaled = 1;
> + efi_events[i].is_signaled = true;
> efi_signal_event(&efi_events[i]);
> }
> WATCHDOG_RESET();
> @@ -354,7 +354,7 @@ efi_status_t efi_set_timer(struct efi_event *event, enum
> efi_timer_delay type,
> }
> event->trigger_type = type;
> event->trigger_time = trigger_time;
> - event->signaled = 0;
> + event->is_signaled = false;
> return EFI_SUCCESS;
> }
> return EFI_INVALID_PARAMETER;
> @@ -391,14 +391,14 @@ static efi_status_t EFIAPI efi_wait_for_event(unsigned
> long num_events,
> known_event:
> if (!event[i]->type || event[i]->type & EVT_NOTIFY_SIGNAL)
> return EFI_EXIT(EFI_INVALID_PARAMETER);
> -
Re: [U-Boot] [PATCH] disk: Don't assume blksz > legacy_mbr
On Tue, Oct 3, 2017 at 12:32 PM, Rob Clark wrote: > On Tue, Oct 3, 2017 at 12:04 PM, Fabio Estevam wrote: >> On Tue, Oct 3, 2017 at 12:30 PM, Rob Clark wrote: >>> On some devices, this does not appear to be a valid assumption. So >>> figure out the number of blocks we actually need to read. >>> >>> Signed-off-by: Rob Clark >> >> This version does not solve the mx6 spl boot issue. > > Hmm, the change you had tested earlier is not correct, since it would > allocate potentially less than blksz (and then read blksz bytes into > it).. > > *maybe* the memory allocation is failing? I'm not sure, I'm kind of > just guessing here. It would be nice to know what blksz is on your > device. (That said, before the original patch, the allocation was for > blksz bytes too, so if this were the issue I think it would have been > failing before.) > btw, I'm still hoping someone can get me some logs so I can see what blksz is, etc, on these boards.. in the worst case I guess we can change part_test_dos() to: #ifdef SPL .. old code .. #else .. new code .. #endif a bit ugly, but at least that wouldn't break efi_bootmgr plus boards with multiple "disks".. having the proper partition signatures I guess doesn't matter in the SPL stage.. BR, -R ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH] usb: kbd: Fix dangling pointers on probe fail
If probe fails, we should unregister the stdio device, else we leave
dangling pointers to the parent 'struct usb_device'.
Signed-off-by: Rob Clark
---
I finally got around to debugging why things explode so badly without
fixing usb_kbd vs. iomux[1] (which this patch applies on top of).
[1] https://patchwork.ozlabs.org/patch/818881/
common/usb_kbd.c | 30 --
1 file changed, 24 insertions(+), 6 deletions(-)
diff --git a/common/usb_kbd.c b/common/usb_kbd.c
index 4c3ad95fca..82ad93f6ca 100644
--- a/common/usb_kbd.c
+++ b/common/usb_kbd.c
@@ -535,22 +535,40 @@ static int probe_usb_keyboard(struct usb_device *dev)
error = iomux_doenv(stdin, stdinname);
free(newstdin);
if (error)
- return error;
+ goto unregister_stdio;
} else {
/* Check if this is the standard input device. */
- if (strcmp(stdinname, DEVNAME))
- return 1;
+ if (strcmp(stdinname, DEVNAME)) {
+ error = -1;
+ goto unregister_stdio;
+ }
/* Reassign the console */
- if (overwrite_console())
- return 1;
+ if (overwrite_console()) {
+ error = -1;
+ goto unregister_stdio;
+ }
error = console_assign(stdin, DEVNAME);
if (error)
- return error;
+ goto unregister_stdio;
}
return 0;
+
+unregister_stdio:
+ /*
+* If probe fails, the device will be removed.. leaving dangling
+* pointers if the stdio device is not unregistered. If u-boot
+* is built without stdio_deregister(), just pretend to succeed
+* in order to avoid dangling pointers.
+*/
+#if CONFIG_IS_ENABLED(SYS_STDIO_DEREGISTER)
+ stdio_deregister(DEVNAME, 1);
+ return error;
+#else
+ return 0;
+#endif
}
#ifndef CONFIG_DM_USB
--
2.13.5
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] disk: Don't assume blksz > legacy_mbr
On Tue, Oct 3, 2017 at 12:04 PM, Fabio Estevam wrote: > On Tue, Oct 3, 2017 at 12:30 PM, Rob Clark wrote: >> On some devices, this does not appear to be a valid assumption. So >> figure out the number of blocks we actually need to read. >> >> Signed-off-by: Rob Clark > > This version does not solve the mx6 spl boot issue. Hmm, the change you had tested earlier is not correct, since it would allocate potentially less than blksz (and then read blksz bytes into it).. *maybe* the memory allocation is failing? I'm not sure, I'm kind of just guessing here. It would be nice to know what blksz is on your device. (That said, before the original patch, the allocation was for blksz bytes too, so if this were the issue I think it would have been failing before.) BR, -R ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH] disk: Don't assume blksz > legacy_mbr
On some devices, this does not appear to be a valid assumption. So
figure out the number of blocks we actually need to read.
Signed-off-by: Rob Clark
---
Sorry, took a bit longer to get to a point of testing this.. somehow
himport_r() of the default_environment is clobbering my usb keyboard's
usb_device, which I'm still tracking down. Good thing that pointers
overwritten with ascii are fairly obvious.
disk/part_dos.c | 6 --
disk/part_efi.c | 6 --
2 files changed, 8 insertions(+), 4 deletions(-)
diff --git a/disk/part_dos.c b/disk/part_dos.c
index 1a36be0446..a9d23e121c 100644
--- a/disk/part_dos.c
+++ b/disk/part_dos.c
@@ -89,9 +89,11 @@ static int test_block_type(unsigned char *buffer)
static int part_test_dos(struct blk_desc *dev_desc)
{
- ALLOC_CACHE_ALIGN_BUFFER(legacy_mbr, mbr, dev_desc->blksz);
+ /* blksz *should* be a PoT, but to be safe use DIV_ROUND_UP: */
+ lbaint_t blkcnt = DIV_ROUND_UP(sizeof(legacy_mbr), dev_desc->blksz);
+ ALLOC_CACHE_ALIGN_BUFFER(legacy_mbr, mbr, blkcnt * dev_desc->blksz);
- if (blk_dread(dev_desc, 0, 1, (ulong *)mbr) != 1)
+ if (blk_dread(dev_desc, 0, blkcnt, (ulong *)mbr) != 1)
return -1;
if (test_block_type((unsigned char *)mbr) != DOS_MBR)
diff --git a/disk/part_efi.c b/disk/part_efi.c
index 208bb14ee8..e00f6c9d24 100644
--- a/disk/part_efi.c
+++ b/disk/part_efi.c
@@ -923,7 +923,9 @@ static int is_pmbr_valid(legacy_mbr * mbr)
static int is_gpt_valid(struct blk_desc *dev_desc, u64 lba,
gpt_header *pgpt_head, gpt_entry **pgpt_pte)
{
- ALLOC_CACHE_ALIGN_BUFFER(legacy_mbr, mbr, dev_desc->blksz);
+ /* blksz *should* be a PoT, but to be safe use DIV_ROUND_UP: */
+ lbaint_t blkcnt = DIV_ROUND_UP(sizeof(legacy_mbr), dev_desc->blksz);
+ ALLOC_CACHE_ALIGN_BUFFER(legacy_mbr, mbr, blkcnt * dev_desc->blksz);
if (!dev_desc || !pgpt_head) {
printf("%s: Invalid Argument(s)\n", __func__);
@@ -931,7 +933,7 @@ static int is_gpt_valid(struct blk_desc *dev_desc, u64 lba,
}
/* Read MBR Header from device */
- if (blk_dread(dev_desc, 0, 1, (ulong *)mbr) != 1) {
+ if (blk_dread(dev_desc, 0, blkcnt, (ulong *)mbr) != 1) {
printf("*** ERROR: Can't read MBR header ***\n");
return 0;
}
--
2.13.5
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [RFC] disk: part_dos: Fix part_test_dos() regression
On Tue, Oct 3, 2017 at 7:04 AM, Fabio Estevam wrote:
> On Tue, Oct 3, 2017 at 7:57 AM, Rob Clark wrote:
>
>> btw, if I had to take a guess, I'd say that perhaps blksz is smaller
>> than 'legacy_mbr', so maybe rather than allocating blksize, it should
>> be DIV_ROUND_UP(sizeof(legacy_mbr), dev_desc->blksz).. or I guess that
>> could be simplified to not use division if blksz is a power of two
>
> Yes, it does seem to be size related as we are size constraint in SPL.
>
> Just tried your suggestion:
>
> --- a/disk/part_dos.c
> +++ b/disk/part_dos.c
> @@ -89,7 +89,9 @@ static int test_block_type(unsigned char *buffer)
>
> static int part_test_dos(struct blk_desc *dev_desc)
> {
> - ALLOC_CACHE_ALIGN_BUFFER(legacy_mbr, mbr, dev_desc->blksz);
> + ALLOC_CACHE_ALIGN_BUFFER(legacy_mbr, mbr,
> +DIV_ROUND_UP(sizeof(legacy_mbr),
> +dev_desc->blksz));
>
> if (blk_dread(dev_desc, 0, 1, (ulong *)mbr) != 1)
> return -1;
>
> and it does work for me :-)
Ok, I guess if blksz can actually be less than the mbr, we probably
also need a similar fix in is_gpt_valid() (and also to pass the
correct # of blks to blk_dread()).. I'll make a patch in a few..
BR,
-R
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [RFC] disk: part_dos: Fix part_test_dos() regression
On Tue, Oct 3, 2017 at 6:47 AM, Rob Clark wrote:
> personally I think we should try to figure out what is wrong on imx6
> rather than blindly reverting.. without this change MBR partitioned
> disks might not generate unique device-paths for EFI boot.
>
> If you can't get any debug logs from SPL build, perhaps you can try an
> old SPL image but main u-boot image with the logs I suggested? I
> guess the same issue should happen with the main u-boot image.
>
> BR,
> -R
>
> On Mon, Oct 2, 2017 at 9:50 PM, Fabio Estevam wrote:
>> From: Fabio Estevam
>>
>> Since commit ff98cb90514d ("part: extract MBR signature from partitions")
>> SPL boot on i.MX6 starts to fail:
>>
>> U-Boot SPL 2017.09-00221-g0d6ab32 (Oct 02 2017 - 15:13:19)
>> Trying to boot from MMC1
>> (hangs here)
>>
>> Revert the part_test_dos() changes from this commit, so that
>> SPL boot can be functional again.
>>
>> Tested on a imx6q-cuboxi board.
>>
>> Signed-off-by: Fabio Estevam
>> ---
>> disk/part_dos.c | 10 ++
>> 1 file changed, 2 insertions(+), 8 deletions(-)
>>
>> diff --git a/disk/part_dos.c b/disk/part_dos.c
>> index 1a36be0..213a8d8 100644
>> --- a/disk/part_dos.c
>> +++ b/disk/part_dos.c
>> @@ -89,20 +89,14 @@ static int test_block_type(unsigned char *buffer)
>>
>> static int part_test_dos(struct blk_desc *dev_desc)
>> {
>> - ALLOC_CACHE_ALIGN_BUFFER(legacy_mbr, mbr, dev_desc->blksz);
>> + ALLOC_CACHE_ALIGN_BUFFER(unsigned char, mbr, dev_desc->blksz);
btw, if I had to take a guess, I'd say that perhaps blksz is smaller
than 'legacy_mbr', so maybe rather than allocating blksize, it should
be DIV_ROUND_UP(sizeof(legacy_mbr), dev_desc->blksz).. or I guess that
could be simplified to not use division if blksz is a power of two
BR,
-R
>>
>> if (blk_dread(dev_desc, 0, 1, (ulong *)mbr) != 1)
>> return -1;
>>
>> - if (test_block_type((unsigned char *)mbr) != DOS_MBR)
>> + if (test_block_type(mbr) != DOS_MBR)
>> return -1;
>>
>> - if (dev_desc->sig_type == SIG_TYPE_NONE &&
>> - mbr->unique_mbr_signature != 0) {
>> - dev_desc->sig_type = SIG_TYPE_MBR;
>> - dev_desc->mbr_sig = mbr->unique_mbr_signature;
>> - }
>> -
>> return 0;
>> }
>>
>> --
>> 2.7.4
>>
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [RFC] disk: part_dos: Fix part_test_dos() regression
personally I think we should try to figure out what is wrong on imx6
rather than blindly reverting.. without this change MBR partitioned
disks might not generate unique device-paths for EFI boot.
If you can't get any debug logs from SPL build, perhaps you can try an
old SPL image but main u-boot image with the logs I suggested? I
guess the same issue should happen with the main u-boot image.
BR,
-R
On Mon, Oct 2, 2017 at 9:50 PM, Fabio Estevam wrote:
> From: Fabio Estevam
>
> Since commit ff98cb90514d ("part: extract MBR signature from partitions")
> SPL boot on i.MX6 starts to fail:
>
> U-Boot SPL 2017.09-00221-g0d6ab32 (Oct 02 2017 - 15:13:19)
> Trying to boot from MMC1
> (hangs here)
>
> Revert the part_test_dos() changes from this commit, so that
> SPL boot can be functional again.
>
> Tested on a imx6q-cuboxi board.
>
> Signed-off-by: Fabio Estevam
> ---
> disk/part_dos.c | 10 ++
> 1 file changed, 2 insertions(+), 8 deletions(-)
>
> diff --git a/disk/part_dos.c b/disk/part_dos.c
> index 1a36be0..213a8d8 100644
> --- a/disk/part_dos.c
> +++ b/disk/part_dos.c
> @@ -89,20 +89,14 @@ static int test_block_type(unsigned char *buffer)
>
> static int part_test_dos(struct blk_desc *dev_desc)
> {
> - ALLOC_CACHE_ALIGN_BUFFER(legacy_mbr, mbr, dev_desc->blksz);
> + ALLOC_CACHE_ALIGN_BUFFER(unsigned char, mbr, dev_desc->blksz);
>
> if (blk_dread(dev_desc, 0, 1, (ulong *)mbr) != 1)
> return -1;
>
> - if (test_block_type((unsigned char *)mbr) != DOS_MBR)
> + if (test_block_type(mbr) != DOS_MBR)
> return -1;
>
> - if (dev_desc->sig_type == SIG_TYPE_NONE &&
> - mbr->unique_mbr_signature != 0) {
> - dev_desc->sig_type = SIG_TYPE_MBR;
> - dev_desc->mbr_sig = mbr->unique_mbr_signature;
> - }
> -
> return 0;
> }
>
> --
> 2.7.4
>
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v3 02/21] part: extract MBR signature from partitions
On Mon, Oct 2, 2017 at 2:17 PM, Fabio Estevam wrote: > On Wed, Sep 13, 2017 at 7:05 PM, Rob Clark wrote: >> From: Peter Jones >> >> EFI client programs need the signature information from the partition >> table to determine the disk a partition is on, so we need to fill that >> in here. >> >> Signed-off-by: Peter Jones >> [separated from efi_loader part, and fixed build-errors for non- >> CONFIG_EFI_PARTITION case] >> Signed-off-by: Rob Clark > > This is commit ff98cb90514d9b78 in mainline now and breaks all mx6 SPL boots: > > U-Boot SPL 2017.09-00221-g0d6ab32 (Oct 02 2017 - 15:13:19) > Trying to boot from MMC1 > (hangs here) > > Does anyone know how to fix this problem? not sure to what extent debug()/printf() works from SPL, but if it does maybe adding this patch with and without that commit and comparing logs would give some hint: -- diff --git a/disk/part.c b/disk/part.c index aa9183d696..8e0bf54b3e 100644 --- a/disk/part.c +++ b/disk/part.c @@ -5,6 +5,8 @@ * SPDX-License-Identifier:GPL-2.0+ */ +#define DEBUG + #include #include #include @@ -13,7 +15,7 @@ #include #include -#undefPART_DEBUG +#definePART_DEBUG #ifdefPART_DEBUG #definePRINTF(fmt,args...)printf (fmt ,##args) -- I don't really see why this commit would cause problems, but I guess either something unexpected going on w/ partitions or block device driver on this platform.. BR, -R ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] dm: video: make ANSI escape sequence support optional
On Sat, Sep 30, 2017 at 4:19 AM, Anatolij Gustschin wrote:
> As mentioned in review comments for ANSI escape sequence
> support patches, this should be optional to reduce code
> size. Disable escape sequence support when CONFIG_VIDEO_ANSI
> is not enabled.
Assuming the later version of the patch was applied there should be,
at the top of vidconsole_escape_char:
if (!IS_ENABLED(CONFIG_VIDEO_ANSI))
goto error;
which (at least if not building with -O0) should be enough to strip
the rest out, with somewhat less ifdef than this approach..
BR,
-R
> Signed-off-by: Anatolij Gustschin
> ---
> This patch is based on basic ANSI escape seq. support series:
> https://www.mail-archive.com/u-boot@lists.denx.de/msg263777.html
>
> drivers/video/vidconsole-uclass.c | 6 ++
> include/video_console.h | 4
> 2 files changed, 10 insertions(+)
>
> diff --git a/drivers/video/vidconsole-uclass.c
> b/drivers/video/vidconsole-uclass.c
> index 5f63c12d6c..f62e9f9308 100644
> --- a/drivers/video/vidconsole-uclass.c
> +++ b/drivers/video/vidconsole-uclass.c
> @@ -108,6 +108,7 @@ static void vidconsole_newline(struct udevice *dev)
> video_sync(dev->parent);
> }
>
> +#if CONFIG_IS_ENABLED(VIDEO_ANSI)
> static const struct {
> unsigned r;
> unsigned g;
> @@ -299,22 +300,27 @@ error:
> /* something went wrong, just revert to normal mode: */
> priv->escape = 0;
> }
> +#endif
>
> int vidconsole_put_char(struct udevice *dev, char ch)
> {
> struct vidconsole_priv *priv = dev_get_uclass_priv(dev);
> int ret;
>
> +#if CONFIG_IS_ENABLED(VIDEO_ANSI)
> if (priv->escape) {
> vidconsole_escape_char(dev, ch);
> return 0;
> }
> +#endif
>
> switch (ch) {
> +#if CONFIG_IS_ENABLED(VIDEO_ANSI)
> case '\x1b':
> priv->escape_len = 0;
> priv->escape = 1;
> break;
> +#endif
> case '\a':
> /* beep */
> break;
> diff --git a/include/video_console.h b/include/video_console.h
> index 9dce234bd9..f07f43c1e2 100644
> --- a/include/video_console.h
> +++ b/include/video_console.h
> @@ -7,6 +7,8 @@
> #ifndef __video_console_h
> #define __video_console_h
>
> +#include
> +
> #define VID_FRAC_DIV 256
>
> #define VID_TO_PIXEL(x)((x) / VID_FRAC_DIV)
> @@ -45,6 +47,7 @@ struct vidconsole_priv {
> int xsize_frac;
> int xstart_frac;
> int last_ch;
> +#if CONFIG_IS_ENABLED(VIDEO_ANSI)
> /*
> * ANSI escape sequences are accumulated character by character,
> * starting after the ESC char (0x1b) until the entire sequence
> @@ -53,6 +56,7 @@ struct vidconsole_priv {
> int escape;
> int escape_len;
> char escape_buf[32];
> +#endif
> };
>
> /**
> --
> 2.11.0
>
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 0/3] dm: video: enhancements for Shell.efi
On Thu, Sep 28, 2017 at 8:17 AM, Simon Glass wrote: > Hi Rob, > > On 13 September 2017 at 16:12, Rob Clark wrote: >> >> Split out of earlier efi_loader patchset, and updated with some >> comments, use of simple_strtol[1], and added kconfig option to >> enable ANSI escape sequence support. >> >> [1] not a hard dependency, but to ensure correct behavior in all cases, >> depends on "lib: strto: fix incorrect handling of specified base" >> >> Rob Clark (3): >> dm: video: Fix cache flushes >> dm: video: Add basic ANSI escape sequence support >> dm: video: Add color ANSI escape sequence support >> >> drivers/video/Kconfig | 8 ++ >> drivers/video/vidconsole-uclass.c | 206 >> ++ >> drivers/video/video-uclass.c | 4 +- >> include/video.h | 7 ++ >> include/video_console.h | 11 ++ >> 5 files changed, 233 insertions(+), 3 deletions(-) > > I'd like to apply this series but am waiting for the test update. Did > you get my email about this? > yes, I guess you missed: https://patchwork.ozlabs.org/project/uboot/list/?series=5009 BR, -R ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH] usb: kbd: Don't fail with iomux
stdin might not be set, which would cause iomux_doenv() to fail
therefore causing probe_usb_keyboard() to fail. Furthermore if we do
have iomux enabled, the sensible thing (in terms of user experience)
would be to simply add ourselves to the list of stdin devices.
This fixes an issue with usbkbd on dragonboard410c with distro-
bootcmd, where stdin is not set (so stdinname is null).
Signed-off-by: Rob Clark
---
Somehow this patch was dropped on the floor. I don't remember
which version # this is up to, search the list if you care. But
this is the latest. I only noticed it was missing because u-boot
crashes when you boot with usb-keyboard plugged in (at least on
db410c) without it. So someone please apply this patch before it
gets lost again.
common/usb_kbd.c | 46 +++---
include/console.h | 2 --
2 files changed, 31 insertions(+), 17 deletions(-)
diff --git a/common/usb_kbd.c b/common/usb_kbd.c
index a323d72a36..4c3ad95fca 100644
--- a/common/usb_kbd.c
+++ b/common/usb_kbd.c
@@ -516,23 +516,39 @@ static int probe_usb_keyboard(struct usb_device *dev)
return error;
stdinname = env_get("stdin");
-#if CONFIG_IS_ENABLED(CONSOLE_MUX)
- error = iomux_doenv(stdin, stdinname);
- if (error)
- return error;
-#else
- /* Check if this is the standard input device. */
- if (strcmp(stdinname, DEVNAME))
- return 1;
+ if (CONFIG_IS_ENABLED(CONSOLE_MUX)) {
+ char *devname = DEVNAME;
+ char *newstdin = NULL;
+ /*
+* stdin might not be set yet.. either way, with console-
+* mux the sensible thing to do is add ourselves to the
+* list of stdio devices:
+*/
+ if (stdinname && !strstr(stdinname, DEVNAME)) {
+ newstdin = malloc(strlen(stdinname) +
+ strlen(","DEVNAME) + 1);
+ sprintf(newstdin, "%s,"DEVNAME, stdinname);
+ stdinname = newstdin;
+ } else if (!stdinname) {
+ stdinname = devname;
+ }
+ error = iomux_doenv(stdin, stdinname);
+ free(newstdin);
+ if (error)
+ return error;
+ } else {
+ /* Check if this is the standard input device. */
+ if (strcmp(stdinname, DEVNAME))
+ return 1;
- /* Reassign the console */
- if (overwrite_console())
- return 1;
+ /* Reassign the console */
+ if (overwrite_console())
+ return 1;
- error = console_assign(stdin, DEVNAME);
- if (error)
- return error;
-#endif
+ error = console_assign(stdin, DEVNAME);
+ if (error)
+ return error;
+ }
return 0;
}
diff --git a/include/console.h b/include/console.h
index cea29ed6dc..7dfd36d7d1 100644
--- a/include/console.h
+++ b/include/console.h
@@ -57,8 +57,6 @@ int console_announce_r(void);
/*
* CONSOLE multiplexing.
*/
-#ifdef CONFIG_CONSOLE_MUX
#include
-#endif
#endif
--
2.13.5
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 2/2] video: test: Add ANSI escape sequence tests
Signed-off-by: Rob Clark
---
Not sure if there is a way to inject a -l arg when test.py runs
sanbox somehow, to visually confirm the results? It is not really
possible to do manually since 'echo' command doesn't handle escape
sequences properly. At any rate, efi_console uses all the same
escape sequences, and at least with a 32bpp display they look
correct.
test/dm/video.c | 34 ++
1 file changed, 34 insertions(+)
diff --git a/test/dm/video.c b/test/dm/video.c
index 6a5626c5e3..29917d0c2d 100644
--- a/test/dm/video.c
+++ b/test/dm/video.c
@@ -159,6 +159,40 @@ static int dm_test_video_chars(struct unit_test_state *uts)
}
DM_TEST(dm_test_video_chars, DM_TESTF_SCAN_PDATA | DM_TESTF_SCAN_FDT);
+#ifdef CONFIG_VIDEO_ANSI
+#define ANSI_ESC "\x1b"
+/* Test handling of ANSI escape sequences */
+static int dm_test_video_ansi(struct unit_test_state *uts)
+{
+ struct udevice *dev, *con;
+
+ ut_assertok(select_vidconsole(uts, "vidconsole0"));
+ ut_assertok(uclass_get_device(UCLASS_VIDEO, 0, &dev));
+ ut_assertok(uclass_get_device(UCLASS_VIDEO_CONSOLE, 0, &con));
+
+ /* reference clear: */
+ video_clear(con->parent);
+ video_sync(con->parent);
+ ut_asserteq(46, compress_frame_buffer(dev));
+
+ /* test clear escape sequence: [2J */
+ vidconsole_put_string(con, "A\tB\tC"ANSI_ESC"[2J");
+ ut_asserteq(46, compress_frame_buffer(dev));
+
+ /* test set-cursor: [%d;%df */
+ vidconsole_put_string(con, "abc"ANSI_ESC"[2;2fab"ANSI_ESC"[4;4fcd");
+ ut_asserteq(142, compress_frame_buffer(dev));
+
+ /* test colors (30-37 fg color, 40-47 bg color) */
+ vidconsole_put_string(con, ANSI_ESC"[30;41mfoo"); /* black on red */
+ vidconsole_put_string(con, ANSI_ESC"[33;44mbar"); /* yellow on blue */
+ ut_asserteq(268, compress_frame_buffer(dev));
+
+ return 0;
+}
+DM_TEST(dm_test_video_ansi, DM_TESTF_SCAN_PDATA | DM_TESTF_SCAN_FDT);
+#endif
+
/**
* check_vidconsole_output() - Run a text console test
*
--
2.13.5
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 1/2] video: test: Helper for writing strings
I'll need some more of this, let's not just copy-pasta the
vidconsole_put_char() loop.
Named to match vidconsole_put_char() in case that is ever useful
outside of the tests.
Signed-off-by: Rob Clark
---
test/dm/video.c | 24
1 file changed, 12 insertions(+), 12 deletions(-)
diff --git a/test/dm/video.c b/test/dm/video.c
index 4d000fa1be..6a5626c5e3 100644
--- a/test/dm/video.c
+++ b/test/dm/video.c
@@ -100,6 +100,14 @@ static int select_vidconsole(struct unit_test_state *uts,
const char *drv_name)
return 0;
}
+static void vidconsole_put_string(struct udevice *dev, const char *str)
+{
+ const char *s;
+
+ for (s = str; *s; s++)
+ vidconsole_put_char(dev, *s);
+}
+
/* Test text output works on the video console */
static int dm_test_video_text(struct unit_test_state *uts)
{
@@ -140,13 +148,11 @@ static int dm_test_video_chars(struct unit_test_state
*uts)
{
struct udevice *dev, *con;
const char *test_string = "Well\b\b\b\bxhe is\r \n\ta very \amodest
\bman\n\t\tand Has much to\b\bto be modest about.";
- const char *s;
ut_assertok(select_vidconsole(uts, "vidconsole0"));
ut_assertok(uclass_get_device(UCLASS_VIDEO, 0, &dev));
ut_assertok(uclass_get_device(UCLASS_VIDEO_CONSOLE, 0, &con));
- for (s = test_string; *s; s++)
- vidconsole_put_char(con, *s);
+ vidconsole_put_string(con, test_string);
ut_asserteq(466, compress_frame_buffer(dev));
return 0;
@@ -294,12 +300,10 @@ static int dm_test_video_truetype(struct unit_test_state
*uts)
{
struct udevice *dev, *con;
const char *test_string = "Criticism may not be agreeable, but it is
necessary. It fulfils the same function as pain in the human body. It calls
attention to an unhealthy state of things. Some see private enterprise as a
predatory target to be shot, others as a cow to be milked, but few are those
who see it as a sturdy horse pulling the wagon. The \aprice OF\b\bof
greatness\n\tis responsibility.\n\nBye";
- const char *s;
ut_assertok(uclass_get_device(UCLASS_VIDEO, 0, &dev));
ut_assertok(uclass_get_device(UCLASS_VIDEO_CONSOLE, 0, &con));
- for (s = test_string; *s; s++)
- vidconsole_put_char(con, *s);
+ vidconsole_put_string(con, test_string);
ut_asserteq(12619, compress_frame_buffer(dev));
return 0;
@@ -312,7 +316,6 @@ static int dm_test_video_truetype_scroll(struct
unit_test_state *uts)
struct sandbox_sdl_plat *plat;
struct udevice *dev, *con;
const char *test_string = "Criticism may not be agreeable, but it is
necessary. It fulfils the same function as pain in the human body. It calls
attention to an unhealthy state of things. Some see private enterprise as a
predatory target to be shot, others as a cow to be milked, but few are those
who see it as a sturdy horse pulling the wagon. The \aprice OF\b\bof
greatness\n\tis responsibility.\n\nBye";
- const char *s;
ut_assertok(uclass_find_device(UCLASS_VIDEO, 0, &dev));
ut_assert(!device_active(dev));
@@ -321,8 +324,7 @@ static int dm_test_video_truetype_scroll(struct
unit_test_state *uts)
ut_assertok(uclass_get_device(UCLASS_VIDEO, 0, &dev));
ut_assertok(uclass_get_device(UCLASS_VIDEO_CONSOLE, 0, &con));
- for (s = test_string; *s; s++)
- vidconsole_put_char(con, *s);
+ vidconsole_put_string(con, test_string);
ut_asserteq(33849, compress_frame_buffer(dev));
return 0;
@@ -335,7 +337,6 @@ static int dm_test_video_truetype_bs(struct unit_test_state
*uts)
struct sandbox_sdl_plat *plat;
struct udevice *dev, *con;
const char *test_string = "...Criticism may or may\b\b\b\b\b\bnot be
agreeable, but seldom it is
necessary\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\bit is necessary. It
fulfils the same function as pain in the human body. It calls attention to an
unhealthy state of things.";
- const char *s;
ut_assertok(uclass_find_device(UCLASS_VIDEO, 0, &dev));
ut_assert(!device_active(dev));
@@ -344,8 +345,7 @@ static int dm_test_video_truetype_bs(struct unit_test_state
*uts)
ut_assertok(uclass_get_device(UCLASS_VIDEO, 0, &dev));
ut_assertok(uclass_get_device(UCLASS_VIDEO_CONSOLE, 0, &con));
- for (s = test_string; *s; s++)
- vidconsole_put_char(con, *s);
+ vidconsole_put_string(con, test_string);
ut_asserteq(34871, compress_frame_buffer(dev));
return 0;
--
2.13.5
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 3/3] fs-test: Add test for a filename using '..' to go back to the root
On Sun, Sep 24, 2017 at 5:38 PM, Tom Rini wrote: > On Mon, Sep 25, 2017 at 12:07:36AM +0300, Tuomas Tynkkynen wrote: > >> The previous commit fixed a problem in FAT code where going back to the >> root directory using '..' wouldn't work correctly on FAT12 or FAT16. >> Add a test to exercise this case (which was once fixed in commit >> 18a10d46f26 "fat: handle paths that include ../" but reintroduced due to >> the directory iterator refactoring). >> >> This test only very barely catches the problem - without the fix the >> size command still gives valid output but the additional spurious >> "Invalid FAT entry" error message makes it not get caught in the >> 'egrep -A3 ' output. I tried to make a proper test that grows the root >> directory to two clusters lots of with dummy files but that causes the >> write tests to crash the sandbox totally... > > Can you post, unrelated, the code that totally crashed sandbox? Maybe > that's a problem we need to fix too :) jfwiw, I've started looking at the fat_write code, so even a failing/crashing test is useful. BR, -R > Otherwise fine, but we need to update the expected results. > > -- > Tom > > ___ > U-Boot mailing list > U-Boot@lists.denx.de > https://lists.denx.de/listinfo/u-boot > ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 1/3] fs-test: Add FAT16 support
On Sun, Sep 24, 2017 at 5:07 PM, Tuomas Tynkkynen
wrote:
> Currently we can only test FAT32 which is the default FAT version that
> mkfs.vfat creates by default. Instead make it explicitly create either a
> FAT16 or a FAT32 volume. This allows us to exercise more code, for
> instance the root directory handling is done differently in FAT32 than
> the older FATs.
>
> Adding FAT12 support is a much bigger job since the test creates a 2.5GB
> file and the FAT12 maximum partition size is way smaller than that.
Thanks
Note that fat12 and fat16 work more similar to each other (other than
file allocation table size) compared to fat32. (fat12 and fat16 have
a single contiguous root directory, whereas fat32 has a root directory
constructed from a chain of clusters, more like how subdirectories
work on earlier fat versions).
That said, I think we could probably increase test coverage w/ much
smaller filesys image sizes.. my current wishlist:
+ bunch of small files w/ long vfat names, enough that the directory
spans multiple clusters.. depends a bit on sector/cluster size but
>128 should do the trick.. there might end up being a lower limit on
root directory in fat12/fat16 so this could be a subdir
+ we don't need huge files, but something bigger than cluster size..
1MB should be sufficient
BR,
-R
> Signed-off-by: Tuomas Tynkkynen
> ---
> test/fs/fs-test.sh | 41 +++--
> 1 file changed, 27 insertions(+), 14 deletions(-)
>
> diff --git a/test/fs/fs-test.sh b/test/fs/fs-test.sh
> index b19486419e..2ddac50f90 100755
> --- a/test/fs/fs-test.sh
> +++ b/test/fs/fs-test.sh
> @@ -41,7 +41,7 @@ SMALL_FILE="1MB.file"
> BIG_FILE="2.5GB.file"
>
> # $MD5_FILE will have the expected md5s when we do the test
> -# They shall have a suffix which represents their file system (ext4/fat)
> +# They shall have a suffix which represents their file system
> (ext4/fat16/...)
> MD5_FILE="${OUT_DIR}/md5s.list"
>
> # $OUT shall be the prefix of the test output. Their suffix will be .out
> @@ -104,15 +104,25 @@ function prepare_env() {
> }
>
> # 1st parameter is the name of the image file to be created
> -# 2nd parameter is the filesystem - fat ext4 etc
> +# 2nd parameter is the filesystem - fat16 ext4 etc
> # -F cant be used with fat as it means something else.
> function create_image() {
> # Create image if not already present - saves time, while debugging
> - if [ "$2" = "ext4" ]; then
> + case "$2" in
> + fat16)
> + MKFS_OPTION="-F 16"
> + FS_TYPE="fat"
> + ;;
> + fat32)
> + MKFS_OPTION="-F 32"
> + FS_TYPE="fat"
> + ;;
> + ext4)
> MKFS_OPTION="-F"
> - else
> - MKFS_OPTION=""
> - fi
> + FS_TYPE="ext4"
> + ;;
> + esac
> +
> if [ ! -f "$1" ]; then
> fallocate -l 3G "$1" &> /dev/null
> if [ $? -ne 0 ]; then
> @@ -123,8 +133,8 @@ function create_image() {
> exit $?
> fi
> fi
> - mkfs -t "$2" $MKFS_OPTION "$1" &> /dev/null
> - if [ $? -ne 0 -a "$2" = "fat" ]; then
> + mkfs -t "$FS_TYPE" $MKFS_OPTION "$1" &> /dev/null
> + if [ $? -ne 0 -a "$FS_TYPE" = "fat" ]; then
> # If we fail and we did fat, try vfat.
> mkfs -t vfat $MKFS_OPTION "$1" &> /dev/null
> fi
> @@ -136,7 +146,7 @@ function create_image() {
> }
>
> # 1st parameter is image file
> -# 2nd parameter is file system type - fat/ext4
> +# 2nd parameter is file system type - fat16/ext4/...
> # 3rd parameter is name of small file
> # 4th parameter is name of big file
> # 5th parameter is fs/nonfs/sb - to dictate generic fs commands or
> @@ -149,7 +159,7 @@ function test_image() {
> length="0x0010"
>
> case "$2" in
> - fat)
> + fat*)
> FPATH=""
> PREFIX="fat"
> WRITE="write"
> @@ -550,7 +560,7 @@ TOTAL_PASS=0
> # In each loop, for a given file system image, we test both the
> # fs command, like load/size/write, the file system specific command
> # like: ext4load/ext4size/ext4write and the sb load/ls/save commands.
> -for fs in ext4 fat; do
> +for fs in ext4 fat16 fat32; do
>
> echo "Creating $fs image if not already present."
> IMAGE=${IMG}.${fs}.img
> @@ -563,11 +573,14 @@ for fs in ext4 fat; do
>
> # Lets mount the image and test sb hostfs commands
> mkdir -p "$MOUNT_DIR"
> - if [ "$fs" = "fat" ]; then
> + case "$fs" in
> + fat*)
> uid="uid=`id -u`"
> - else
> + ;;
> + *)
> uid=""
> - fi
> + ;;
> + esac
> sudo mount -o loop,rw,$uid
Re: [U-Boot] FAT filesystems and mtools-created filesystems
On Sat, Sep 23, 2017 at 6:51 AM, Tuomas Tynkkynen wrote: > On 09/23/2017 01:26 PM, Tuomas Tynkkynen wrote: >> >> Hi, >> >> FAT file systems created by GNU mtools have a problem that mtools doesn't >> initialize the first cluster field of the '.' and '..' directory entries. >> That is, with the following script: Sorry for the delay, I've been travelling. I'll have a look at this.. leaning towards moving sanitize_path() from efi_file.c into fs/fat, since we don't have an infinite stack to store parent ".." entries. Definitely would be good if you could send a patch to add this to test/fs/fs-test.sh >> > > Oh, and unrelated to the mtools problem, '..' entries leading to the root > directory need fixing in the current code, as itr->is_root needs to be set. Hmm, I thought I fixed this once, but I guess only for fat32.. BR, -R ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v3 15/21] efi_loader: add bootmgr
On Thu, Sep 21, 2017 at 12:58 AM, Simon Glass wrote: > Hi, > > On 20 September 2017 at 08:09, Rob Clark wrote: >> On Wed, Sep 20, 2017 at 5:08 AM, Alexander Graf wrote: >>> >>> >>> On 14.09.17 00:05, Rob Clark wrote: >>>> >>>> Similar to a "real" UEFI implementation, the bootmgr looks at the >>>> BootOrder and Boot variables to try to find an EFI payload to load >>>> and boot. This is added as a sub-command of bootefi. >>>> >>>> The idea is that the distro bootcmd would first try loading a payload >>>> via the bootmgr, and then if that fails (ie. first boot or corrupted >>>> EFI variables) it would fallback to loading bootaa64.efi. (Which >>>> would then load fallback.efi which would look for \EFI\*\boot.csv and >>>> populate BootOrder and Boot based on what it found.) >>>> >>>> Signed-off-by: Rob Clark >>> >>> >>> Would it make sense to convert the bootmgr into a genuine EFI application >>> now that we have Heinrich's test framework available? >>> >> >> I had considered that, but then decided it was nice to be able to use >> printf()/malloc()/etc.. plus easier to gdb/debug.. >> >> Maybe at some point it would be worth trying to fixup edk2 build so >> some things like this and HII/unicode protocols and maybe a few other >> things could be built as standalone .efi drivers and loaded by u-boot. >> (Might make sense by the time someone wants a full blown HII "bios >> setup menu" ;-)) > > Another advantage of the current approach used by this series is that > we can test it with sandbox. With a separate EFI application we would > lose that ability. > jfwiw, I do actually have Shell.efi very nearly loading in sandbox.. it crashes part-way through startup (shortly after reading "ShellOpt" variable) and I haven't had a chance to debug further.. but I suspect in some form or another having VA != "PA" in sandbox is biting us. Anyways, getting a bit off topic, but separate .efi in sandbox doesn't seem like it should be completely out of the question for sandbox.. and it would make sandbox *way* more useful for EFI testing, since this is really half of the point of efi.. BR, -R ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH] efi_loader: fix efi_exit
efi_exit() already restores gd, so we shouldn't EFI_EXIT() on the
otherside of the longjmp().
Signed-off-by: Rob Clark
---
cmd/bootefi.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/cmd/bootefi.c b/cmd/bootefi.c
index fdfed1be05..a049e5f64d 100644
--- a/cmd/bootefi.c
+++ b/cmd/bootefi.c
@@ -191,7 +191,6 @@ static unsigned long do_bootefi_exec(void *efi, void *fdt,
if (setjmp(&loaded_image_info.exit_jmp)) {
ret = loaded_image_info.exit_status;
- EFI_EXIT(ret);
goto exit;
}
--
2.13.5
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2 1/1] efi_loader: reenable selftest
On Wed, Sep 20, 2017 at 4:54 PM, Heinrich Schuchardt wrote:
> ad503ffe9c6 efi_loader: refactor boot device and loaded_image handling
> leads to an error when building with CONFIG_CMD_BOOTEFI_SELFTEST=y
> This patch fixes the problem.
>
> Fixes: ad503ffe9c6 efi_loader: refactor boot device and loaded_image handling
> Signed-off-by: Heinrich Schuchardt
> ---
> v2
> completely initialize loaded_image_info
lgtm, thanks
Reviewed-by: Rob Clark
> ---
> cmd/bootefi.c | 8 ++--
> 1 file changed, 6 insertions(+), 2 deletions(-)
>
> diff --git a/cmd/bootefi.c b/cmd/bootefi.c
> index 1e2dbcc4a4..e0a657323f 100644
> --- a/cmd/bootefi.c
> +++ b/cmd/bootefi.c
> @@ -273,6 +273,12 @@ static int do_bootefi(cmd_tbl_t *cmdtp, int flag, int
> argc, char * const argv[])
> #endif
> #ifdef CONFIG_CMD_BOOTEFI_SELFTEST
> if (!strcmp(argv[1], "selftest")) {
> + struct efi_loaded_image loaded_image_info = {};
> + struct efi_object loaded_image_info_obj = {};
> +
> + efi_setup_loaded_image(&loaded_image_info,
> + &loaded_image_info_obj,
> + bootefi_device_path,
> bootefi_image_path);
> /*
> * gd lives in a fixed register which may get clobbered while
> we
> * execute the payload. So save it here and restore it on
> every
> @@ -282,8 +288,6 @@ static int do_bootefi(cmd_tbl_t *cmdtp, int flag, int
> argc, char * const argv[])
> /* Initialize and populate EFI object list */
> if (!efi_obj_list_initalized)
> efi_init_obj_list();
> - loaded_image_info.device_handle = bootefi_device_path;
> - loaded_image_info.file_path = bootefi_image_path;
> return efi_selftest(&loaded_image_info, &systab);
> } else
> #endif
> --
> 2.14.1
>
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 1/1] efi_loader: reenable selftest
On Wed, Sep 20, 2017 at 3:46 PM, Heinrich Schuchardt wrote:
> ad503ffe9c6 efi_loader: refactor boot device and loaded_image handling
> leads to an error when building with CONFIG_CMD_BOOTEFI_SELFTEST=y
> This patch fixes the problem.
>
> Fixes: ad503ffe9c6 efi_loader: refactor boot device and loaded_image handling
> Signed-off-by: Heinrich Schuchardt
> ---
> cmd/bootefi.c | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/cmd/bootefi.c b/cmd/bootefi.c
> index 1e2dbcc4a4..9460747f96 100644
> --- a/cmd/bootefi.c
> +++ b/cmd/bootefi.c
> @@ -273,6 +273,8 @@ static int do_bootefi(cmd_tbl_t *cmdtp, int flag, int
> argc, char * const argv[])
> #endif
> #ifdef CONFIG_CMD_BOOTEFI_SELFTEST
> if (!strcmp(argv[1], "selftest")) {
> + struct efi_loaded_image loaded_image_info = {};
> +
> /*
> * gd lives in a fixed register which may get clobbered while
> we
> * execute the payload. So save it here and restore it on
> every
> --
> 2.14.1
>
I'm not sure this is complete enough (or at least will run into
problems if you add more tests) since loaded_image_info won't be
populated completely. You want a efi_setup_loaded_image() call:
efi_setup_loaded_image(&loaded_image_info, &loaded_image_info_obj,
bootefi_device_path, bootefi_image_path);
BR,
-R
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] cmd/bootefi.c:285:3: error: ‘loaded_image_info’ undeclared
On Wed, Sep 20, 2017 at 2:42 PM, Heinrich Schuchardt wrote:
> Hello Rob, hello Alex,
>
> when I try to compile efi-next I get
>
> CC cmd/bootefi.o
> cmd/bootefi.c: In function ‘do_bootefi’:
> cmd/bootefi.c:285:3: error: ‘loaded_image_info’ undeclared (first use in
> this function)
>loaded_image_info.device_handle = bootefi_device_path;
>^
> cmd/bootefi.c:285:3: note: each undeclared identifier is reported only
> once for each function it appears in
> scripts/Makefile.build:280: recipe for target 'cmd/bootefi.o' failed
> make[3]: *** [cmd/bootefi.o] Error 1
> Makefile:1279: recipe for target 'cmd' failed
>
> when compiling with CONFIG_CMD_BOOTEFI_SELFTEST=y.
>
> I guess we should enable this option in qemu-x86_defconfig to make such
> errors visible in Travis CI.
>
> This seems to be the problematic patch:
> ad503ffe9c6: efi_loader: refactor boot device and loaded_image handling
>
The rebased version of this patch fixed this. It looks like the
original patch was applied. What you want is approximately:
#ifdef CONFIG_CMD_BOOTEFI_SELFTEST
if (!strcmp(argv[1], "selftest")) {
+ struct efi_loaded_image loaded_image_info = {};
+ struct efi_object loaded_image_info_obj = {};
+
+ efi_setup_loaded_image(&loaded_image_info, &loaded_image_info_obj,
+ bootefi_device_path, bootefi_image_path);
+
/*
* gd lives in a fixed register which may get clobbered while we
* execute the payload. So save it here and restore it on every
See:
https://github.com/robclark/u-boot/commit/c17f3a0fbcedf1b5e38e671c277dbd2187d30c19
BR,
-R
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 16/23] efi_loader: implement DisconnectController
On Wed, Sep 20, 2017 at 9:49 AM, Simon Glass wrote:
> Hi Heinrich,
>
> On 15 September 2017 at 00:35, Heinrich Schuchardt wrote:
>> On 08/31/2017 02:52 PM, Simon Glass wrote:
>>> On 27 August 2017 at 06:53, Heinrich Schuchardt wrote:
Signed-off-by: Heinrich Schuchardt
---
lib/efi_loader/efi_boottime.c | 77
++-
1 file changed, 76 insertions(+), 1 deletion(-)
diff --git a/lib/efi_loader/efi_boottime.c b/lib/efi_loader/efi_boottime.c
index 1069da7d79..c5a17b6252 100644
--- a/lib/efi_loader/efi_boottime.c
+++ b/lib/efi_loader/efi_boottime.c
@@ -1052,9 +1052,84 @@ static efi_status_t EFIAPI
efi_disconnect_controller(void *controller_handle,
void
*driver_image_handle,
void *child_handle)
>>>
>>> Can you add a function comment?
>>
>> Hello Simon,
>>
>> the API functions (here DisconnectController) are documented in the UEFI
>> spec. Is your idea that we should duplicate part of this information for
>> all API functions? Or do you miss a comment on implementation details?
>
> I think the code in U-Boot should stand alone, so arguments should be
> described here along with a one-line function description. The args
> are all void which is not good, but makes it even more important to
> document.
couple notes, fwiw..
1) As someone else implementing parts of UEFI interface, I'd find link
to section in spec (or perhaps to http://wiki.phoenix.com/) to be more
useful than re-writing the spec in our own words (and possibly getting
it wrong)
2) Leif introduced (iirc, in the stub HII or unicode patch)
efi_handle_t, and efi_string_t (and maybe we should add efi_char_t)..
which we should probably use more extensively. Although I haven't
wanted to go on a major housecleaning while we still have so many
patches pending on list.. but would be a nice cleanup to make at some
point.
BR,
-R
>>
>>>
{
+ struct efi_driver_binding_protocol *binding_protocol;
+ efi_handle_t child_handle_buffer;
+ unsigned long driver_count;
+ efi_handle_t *driver_handle_buffer;
+ size_t i;
+ UINTN number_of_children;
>>>
>>> Can we somehow use a lower-case type for this? Otherwise U-Boot will
>>> start to look like EFI and I will have to start taking
>>> antidepressants.
>>>
>>
>> In different places the EFI API requires a bitness dependent unsigned
>> integer.
>>
>> Shall we globally rename UINTN to uintn?
>> This is my patch to blame:
>> 503f2695548 (efi_loader: correct size for tpl level)
>
> What does bitness-dependent mean? Do you mean 32-bit? It looks like
> this is just passed to a function, so could be uint or instead?
>
> If it is 32-bit then uint32_t should do.
>
> Regards,
> Simon
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v3 05/21] efi_loader: add device-path utils
On Wed, Sep 20, 2017 at 4:31 AM, Alexander Graf wrote: > > > On 14.09.17 00:05, Rob Clark wrote: >> >> Helpers to construct device-paths from devices, partitions, files, and >> for parsing and manipulating device-paths. >> >> For non-legacy devices, this will use u-boot's device-model to construct >> device-paths which include bus hierarchy to construct device-paths. For >> legacy devices we still fake it, but slightly more convincingly. >> >> Signed-off-by: Rob Clark > > > This patch gives me checkpatch warnings left and right (unsigned vs unsigned > int, double blank lines, double assignments, unsafe define, ...). I'll pull > it in for now since it seems to be functionally correct, but please fix up > the warnings in a follow-up patch. > > > Alex > > WARNING: Adding new packed members is to be done with care > #56: FILE: include/efi_api.h:340: > +} __packed; fwiw, the __packed warnings are bogus and should be ignored. Maybe someone can fix checkpatch to whitelist efi_api.h (or just drop that warning again). BR, -R > > CHECK: Please don't use multiple blank lines > #69: FILE: include/efi_loader.h:200: > > + > > WARNING: Prefer 'unsigned int' to bare use of 'unsigned' > #74: FILE: include/efi_loader.h:205: > +unsigned efi_dp_size(const struct efi_device_path *dp); > > CHECK: Please don't use multiple blank lines > #81: FILE: include/efi_loader.h:212: > + > + > > CHECK: Macro argument reuse '_dp' - possible side-effects? > #91: FILE: include/efi_loader.h:222: > +#define EFI_DP_TYPE(_dp, _type, _subtype) \ > + (((_dp)->type == DEVICE_PATH_TYPE_##_type) && \ > +((_dp)->sub_type == DEVICE_PATH_SUB_TYPE_##_subtype)) > > WARNING: added, moved or deleted file(s), does MAINTAINERS need updating? > #136: > new file mode 100644 > > CHECK: Comparison to NULL could be written "!dp" > #195: FILE: lib/efi_loader/efi_device_path.c:55: > + if (dp == NULL) > > CHECK: Please don't use multiple blank lines > #232: FILE: lib/efi_loader/efi_device_path.c:92: > + > + > > CHECK: Please don't use multiple blank lines > #301: FILE: lib/efi_loader/efi_device_path.c:161: > + > + > > WARNING: Prefer 'unsigned int' to bare use of 'unsigned' > #320: FILE: lib/efi_loader/efi_device_path.c:180: > +unsigned efi_dp_size(const struct efi_device_path *dp) > > WARNING: Prefer 'unsigned int' to bare use of 'unsigned' > #322: FILE: lib/efi_loader/efi_device_path.c:182: > + unsigned sz = 0; > > WARNING: Prefer 'unsigned int' to bare use of 'unsigned' > #335: FILE: lib/efi_loader/efi_device_path.c:195: > + unsigned sz = efi_dp_size(dp) + sizeof(END); > > WARNING: Prefer 'unsigned int' to bare use of 'unsigned' > #357: FILE: lib/efi_loader/efi_device_path.c:217: > + unsigned sz1 = efi_dp_size(dp1); > > WARNING: Prefer 'unsigned int' to bare use of 'unsigned' > #358: FILE: lib/efi_loader/efi_device_path.c:218: > + unsigned sz2 = efi_dp_size(dp2); > > WARNING: Missing a blank line after declarations > #360: FILE: lib/efi_loader/efi_device_path.c:220: > + void *p = dp_alloc(sz1 + sz2 + sizeof(END)); > + memcpy(p, dp1, sz1); > > WARNING: Prefer 'unsigned int' to bare use of 'unsigned' > #379: FILE: lib/efi_loader/efi_device_path.c:239: > + unsigned sz = node->length; > > WARNING: Missing a blank line after declarations > #381: FILE: lib/efi_loader/efi_device_path.c:241: > + void *p = dp_alloc(sz + sizeof(END)); > + memcpy(p, node, sz); > > WARNING: Prefer 'unsigned int' to bare use of 'unsigned' > #386: FILE: lib/efi_loader/efi_device_path.c:246: > + unsigned sz = efi_dp_size(dp); > > WARNING: Missing a blank line after declarations > #388: FILE: lib/efi_loader/efi_device_path.c:248: > + void *p = dp_alloc(sz + node->length + sizeof(END)); > + memcpy(p, dp, sz); > > WARNING: Prefer 'unsigned int' to bare use of 'unsigned' > #401: FILE: lib/efi_loader/efi_device_path.c:261: > +static unsigned dp_size(struct udevice *dev) > > CHECK: multiple assignments should be avoided > #484: FILE: lib/efi_loader/efi_device_path.c:344: > + start = buf = dp_alloc(dp_size(dev) + sizeof(END)); > > WARNING: Prefer 'unsigned int' to bare use of 'unsigned' > #492: FILE: lib/efi_loader/efi_device_path.c:352: > +static unsigned dp_part_size(struct bl
Re: [U-Boot] [PATCH v3 15/21] efi_loader: add bootmgr
On Wed, Sep 20, 2017 at 5:08 AM, Alexander Graf wrote: > > > On 14.09.17 00:05, Rob Clark wrote: >> >> Similar to a "real" UEFI implementation, the bootmgr looks at the >> BootOrder and Boot variables to try to find an EFI payload to load >> and boot. This is added as a sub-command of bootefi. >> >> The idea is that the distro bootcmd would first try loading a payload >> via the bootmgr, and then if that fails (ie. first boot or corrupted >> EFI variables) it would fallback to loading bootaa64.efi. (Which >> would then load fallback.efi which would look for \EFI\*\boot.csv and >> populate BootOrder and Boot based on what it found.) >> >> Signed-off-by: Rob Clark > > > Would it make sense to convert the bootmgr into a genuine EFI application > now that we have Heinrich's test framework available? > I had considered that, but then decided it was nice to be able to use printf()/malloc()/etc.. plus easier to gdb/debug.. Maybe at some point it would be worth trying to fixup edk2 build so some things like this and HII/unicode protocols and maybe a few other things could be built as standalone .efi drivers and loaded by u-boot. (Might make sense by the time someone wants a full blown HII "bios setup menu" ;-)) BR, -R ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 08/16] sandbox: Add a setjmp() implementation
On Mon, Sep 18, 2017 at 2:01 AM, Heinrich Schuchardt wrote:
> On 09/18/2017 12:59 AM, Simon Glass wrote:
>> Add an implementation of setjmp() and longjmp() which rely on the
>> underlying host C library. Since we cannot know how large the jump buffer
>> needs to be, pick something that should be suitable and check it at
>> runtime. At present we need access to the underlying struct as well.
>>
>> Signed-off-by: Simon Glass
>> ---
>>
>> arch/sandbox/cpu/cpu.c| 13 +
>> arch/sandbox/cpu/os.c | 17 +
>> arch/sandbox/include/asm/setjmp.h | 21 +
>> include/os.h | 21 +
>> 4 files changed, 72 insertions(+)
>> create mode 100644 arch/sandbox/include/asm/setjmp.h
>>
>> diff --git a/arch/sandbox/cpu/cpu.c b/arch/sandbox/cpu/cpu.c
>> index 01991049cc..de5862a53b 100644
>> --- a/arch/sandbox/cpu/cpu.c
>> +++ b/arch/sandbox/cpu/cpu.c
>> @@ -9,6 +9,7 @@
>> #include
>> #include
>> #include
>> +#include
>> #include
>> #include
>>
>> @@ -154,3 +155,15 @@ ulong timer_get_boot_us(void)
>>
>> return (count - base_count) / 1000;
>> }
>> +
>> +int setjmp(jmp_buf jmp)
>> +{
>> + return os_setjmp((ulong *)jmp, sizeof(jmp));
>> +}
>> +
>> +void longjmp(jmp_buf jmp, int ret)
>> +{
>> + os_longjmp((ulong *)jmp, ret);
>> + while (1)
>> + ;
>> +}
>> diff --git a/arch/sandbox/cpu/os.c b/arch/sandbox/cpu/os.c
>> index 22d6aab534..909034fa4b 100644
>> --- a/arch/sandbox/cpu/os.c
>> +++ b/arch/sandbox/cpu/os.c
>> @@ -7,6 +7,7 @@
>> #include
>> #include
>> #include
>> +#include
>> #include
>> #include
>> #include
>> @@ -609,3 +610,19 @@ void os_localtime(struct rtc_time *rt)
>> rt->tm_yday = tm->tm_yday;
>> rt->tm_isdst = tm->tm_isdst;
>> }
>> +
>> +int os_setjmp(ulong *jmp, int size)
>> +{
>> + if (size < sizeof(jmp_buf)) {
>> + printf("setjmp: jmpbuf is too small (%d bytes, need %d)\n",
>> +size, sizeof(jmp_buf));
>> + return -ENOSPC;
>> + }
>> +
>> + return setjmp((struct __jmp_buf_tag *)jmp);
>> +}
>> +
>> +void os_longjmp(ulong *jmp, int ret)
>> +{
>> + longjmp((struct __jmp_buf_tag *)jmp, ret);
>> +}
>> diff --git a/arch/sandbox/include/asm/setjmp.h
>> b/arch/sandbox/include/asm/setjmp.h
>> new file mode 100644
>> index 00..e25f50107c
>> --- /dev/null
>> +++ b/arch/sandbox/include/asm/setjmp.h
>> @@ -0,0 +1,21 @@
>> +/*
>> + * (C) Copyright 2016
>> + * Alexander Graf
>> + *
>> + * SPDX-License-Identifier: GPL-2.0+
>> + */
>> +
>> +#ifndef _SETJMP_H_
>> +#define _SETJMP_H_ 1
>> +
>> +struct jmp_buf_data {
>> + /* We're not sure how long this should be */
>> + ulong data[32];
>> +};
>> +
>> +typedef struct jmp_buf_data jmp_buf[1];
>> +
>> +int setjmp(jmp_buf jmp);
>> +__noreturn void longjmp(jmp_buf jmp, int ret);
>> +
>> +#endif /* _SETJMP_H_ */
>> diff --git a/include/os.h b/include/os.h
>> index 2bf4bdb1b8..ad1836ac9f 100644
>> --- a/include/os.h
>> +++ b/include/os.h
>> @@ -310,4 +310,25 @@ int os_spl_to_uboot(const char *fname);
>> */
>> void os_localtime(struct rtc_time *rt);
>>
>> +/**
>> + * os_setjmp() - Call setjmp()
>> + *
>> + * Call the host system's setjmp() function.
>> + *
>> + * @jmp: Buffer to store current execution state
>> + * @size: Size of buffer
>> + * @return normal setjmp() value if OK, -ENOSPC if @size is too small
>> + */
>> +int os_setjmp(ulong *jmp, int size);
>> +
>> +/**
>> + * os_longjmp() - Call longjmp()
>> + *
>> + * Call the host system's longjmp() function.
>> + *
>> + * @jmp: Buffer where previous execution state was stored
>> + * @ret: Value to pass to longjmp()
>> + */
>> +void os_longjmp(ulong *jmp, int ret);
>> +
>> #endif
>>
>
> Please, fix this warning:
>
> arch/sandbox/cpu/cpu.c: In function ‘setjmp’:
> arch/sandbox/cpu/cpu.c:161:39: warning: ‘sizeof’ on array function
> parameter ‘jmp’ will return size of ‘struct jmp_buf_data *’
> [-Wsizeof-array-argument]
> return os_setjmp((ulong *)jmp, sizeof(jmp));
>^
> arch/sandbox/cpu/cpu.c:159:20: note: declared here
> int setjmp(jmp_buf jmp)
>
with the sizeof changed to sizeof(jmp_buf), I'm getting:
...
EFI: Entry efi_exit(7fffc198, 2147483662, 0, )
Program received signal SIGSEGV, Segmentation fault.
os_longjmp (jmp=0x7fffc200,
jmp@entry=, ret=1,
ret@entry=)
at ../arch/sandbox/cpu/os.c:627
627longjmp((struct __jmp_buf_tag *)jmp, ret);
So it seems like something not quite right still..
BR,
-R
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] efi_loader: EFI entry point should be EFIAPI
On Mon, Sep 18, 2017 at 1:47 PM, Rob Clark wrote:
> This is needed to run 'bootefi' from sandbox. I suspect StartImage()
> must have been broken too on x86.
>
> Signed-off-by: Rob Clark
> ---
> cmd/bootefi.c | 2 +-
> include/efi.h | 2 +-
> lib/efi_loader/efi_boottime.c | 2 +-
> 3 files changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/cmd/bootefi.c b/cmd/bootefi.c
> index fb8ba9be6a..3c9a466e20 100644
> --- a/cmd/bootefi.c
> +++ b/cmd/bootefi.c
> @@ -96,7 +96,7 @@ static void *copy_fdt(void *fdt)
>
> static ulong efi_do_enter(void *image_handle,
> struct efi_system_table *st,
> - asmlinkage ulong (*entry)(void *image_handle,
> + EFIAPI ulong (*entry)(void *image_handle,
> struct efi_system_table *st))
> {
> efi_status_t ret = EFI_LOAD_ERROR;
> diff --git a/include/efi.h b/include/efi.h
> index 04e83220b4..47c2c8f398 100644
> --- a/include/efi.h
> +++ b/include/efi.h
> @@ -19,7 +19,7 @@
> #include
> #include
>
> -#ifdef CONFIG_EFI_STUB_64BIT
> +#if defined(CONFIG_EFI_STUB_64BIT) || defined(CONFIG_SANDBOX)
btw, maybe we should have CONFIG_SANDBOX_$arch somehow so we don't
have to assume SANDBOX==X86 (but I guess at least just having
efi_loader work in sandbox on x86 is a nice first step)
BR,
-R
> /* EFI uses the Microsoft ABI which is not the default for GCC */
> #define EFIAPI __attribute__((ms_abi))
> #else
> diff --git a/lib/efi_loader/efi_boottime.c b/lib/efi_loader/efi_boottime.c
> index 22bb95d738..3e10e6f6b5 100644
> --- a/lib/efi_loader/efi_boottime.c
> +++ b/lib/efi_loader/efi_boottime.c
> @@ -950,7 +950,7 @@ static efi_status_t EFIAPI efi_start_image(efi_handle_t
> image_handle,
>unsigned long *exit_data_size,
>s16 **exit_data)
> {
> - ulong (*entry)(void *image_handle, struct efi_system_table *st);
> + EFIAPI ulong (*entry)(void *image_handle, struct efi_system_table
> *st);
> struct efi_loaded_image *info = image_handle;
>
> EFI_ENTRY("%p, %p, %p", image_handle, exit_data_size, exit_data);
> --
> 2.13.5
>
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH] efi_loader: EFI entry point should be EFIAPI
This is needed to run 'bootefi' from sandbox. I suspect StartImage()
must have been broken too on x86.
Signed-off-by: Rob Clark
---
cmd/bootefi.c | 2 +-
include/efi.h | 2 +-
lib/efi_loader/efi_boottime.c | 2 +-
3 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/cmd/bootefi.c b/cmd/bootefi.c
index fb8ba9be6a..3c9a466e20 100644
--- a/cmd/bootefi.c
+++ b/cmd/bootefi.c
@@ -96,7 +96,7 @@ static void *copy_fdt(void *fdt)
static ulong efi_do_enter(void *image_handle,
struct efi_system_table *st,
- asmlinkage ulong (*entry)(void *image_handle,
+ EFIAPI ulong (*entry)(void *image_handle,
struct efi_system_table *st))
{
efi_status_t ret = EFI_LOAD_ERROR;
diff --git a/include/efi.h b/include/efi.h
index 04e83220b4..47c2c8f398 100644
--- a/include/efi.h
+++ b/include/efi.h
@@ -19,7 +19,7 @@
#include
#include
-#ifdef CONFIG_EFI_STUB_64BIT
+#if defined(CONFIG_EFI_STUB_64BIT) || defined(CONFIG_SANDBOX)
/* EFI uses the Microsoft ABI which is not the default for GCC */
#define EFIAPI __attribute__((ms_abi))
#else
diff --git a/lib/efi_loader/efi_boottime.c b/lib/efi_loader/efi_boottime.c
index 22bb95d738..3e10e6f6b5 100644
--- a/lib/efi_loader/efi_boottime.c
+++ b/lib/efi_loader/efi_boottime.c
@@ -950,7 +950,7 @@ static efi_status_t EFIAPI efi_start_image(efi_handle_t
image_handle,
unsigned long *exit_data_size,
s16 **exit_data)
{
- ulong (*entry)(void *image_handle, struct efi_system_table *st);
+ EFIAPI ulong (*entry)(void *image_handle, struct efi_system_table *st);
struct efi_loaded_image *info = image_handle;
EFI_ENTRY("%p, %p, %p", image_handle, exit_data_size, exit_data);
--
2.13.5
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 00/16] efi: Enable basic sandbox support for EFI loader
On Mon, Sep 18, 2017 at 11:07 AM, Rob Clark wrote: > On Mon, Sep 18, 2017 at 10:30 AM, Rob Clark wrote: >> On Mon, Sep 18, 2017 at 9:31 AM, Rob Clark wrote: >>> On Mon, Sep 18, 2017 at 9:18 AM, Rob Clark wrote: >>>> On Sun, Sep 17, 2017 at 11:48 PM, Heinrich Schuchardt >>>> wrote: >>>>> On 09/18/2017 12:59 AM, Simon Glass wrote: >>>>>> A limitation of the EFI loader at present is that it does not build with >>>>>> sandbox. This makes it hard to write tests, since sandbox is used for >>>>>> most >>>>>> testing in U-Boot. >>>>>> >>>>>> This series enables the EFI loader feature. It allows sandbox to build >>>>>> and >>>>>> run a trivial function which calls the EFI API to output a message. >>>>>> >>>>>> Much work remains but this should serve as a basis for adding tests more >>>>>> easily for EFI loader. >>>>>> >>>>>> This series sits on top of Heinrich's recent EFI test series. It is >>>>>> available at u-boot-dm/efi-working >>>>>> >>>>>> >>>>>> Simon Glass (16): >>>>>> efi: Update efi_smbios_register() to return error code >>>>>> efi: Move the init check inside efi_init_obj_list() >>>>>> efi: Add error checking for efi_init_obj_list() >>>>>> efi: Add a TODO to efi_init_obj_list() >>>>>> efi: Correct header order in efi_memory >>>>>> efi: sandbox: Adjust memory setup for sandbox >>>>>> sandbox: smbios: Update to support sandbox >>>>>> sandbox: Add a setjmp() implementation >>>>>> efi: sandbox: Add required linker sections >>>>>> efi: sandbox: Add distroboot support >>>>>> Define board_quiesce_devices() in a shared location >>>>>> Add a comment for board_quiesce_devices() >>>>>> efi: sandbox: Add relocation constants >>>>>> efi: Add a comment about duplicated ELF constants >>>>>> efi: sandbox: Enable EFI loader builder for sandbox >>>>>> efi: sandbox: Add a simple 'bootefi test' command >>>>>> >>>>>> arch/arm/include/asm/u-boot-arm.h | 1 - >>>>>> arch/sandbox/cpu/cpu.c| 13 ++ >>>>>> arch/sandbox/cpu/os.c | 17 >>>>>> arch/sandbox/cpu/u-boot.lds | 29 + >>>>>> arch/sandbox/include/asm/setjmp.h | 21 +++ >>>>>> arch/sandbox/lib/Makefile | 2 +- >>>>>> arch/sandbox/lib/sections.c | 12 + >>>>>> arch/x86/include/asm/u-boot-x86.h | 1 - >>>>>> arch/x86/lib/bootm.c | 4 --- >>>>>> cmd/bootefi.c | 54 >>>>>> ++- >>>>>> common/bootm.c| 4 +++ >>>>>> configs/sandbox_defconfig | 1 + >>>>>> include/bootm.h | 8 ++ >>>>>> include/config_distro_bootcmd.h | 2 +- >>>>>> include/efi_loader.h | 13 -- >>>>>> include/os.h | 21 +++ >>>>>> lib/efi_loader/Kconfig| 12 - >>>>>> lib/efi_loader/Makefile | 1 + >>>>>> lib/efi_loader/efi_boottime.c | 4 +++ >>>>>> lib/efi_loader/efi_memory.c | 33 +--- >>>>>> lib/efi_loader/efi_runtime.c | 7 + >>>>>> lib/efi_loader/efi_smbios.c | 6 +++-- >>>>>> lib/efi_loader/efi_test.c | 17 >>>>>> lib/smbios.c | 38 --- >>>>>> 24 files changed, 277 insertions(+), 44 deletions(-) >>>>>> create mode 100644 arch/sandbox/include/asm/setjmp.h >>>>>> create mode 100644 arch/sandbox/lib/sections.c >>>>>> create mode 100644 lib/efi_loader/efi_test.c >>>>>> >>>>> Thanks for enabling efi_loader on sandbox. That will make many things >>>>> easier. >>>>> >>>>> Unfortunately >>>>> efi_status_t EFIAPI efi_selftest(efi_handle_t image_handle, >>>&
Re: [U-Boot] [PATCH 00/16] efi: Enable basic sandbox support for EFI loader
On Mon, Sep 18, 2017 at 10:30 AM, Rob Clark wrote:
> On Mon, Sep 18, 2017 at 9:31 AM, Rob Clark wrote:
>> On Mon, Sep 18, 2017 at 9:18 AM, Rob Clark wrote:
>>> On Sun, Sep 17, 2017 at 11:48 PM, Heinrich Schuchardt
>>> wrote:
>>>> On 09/18/2017 12:59 AM, Simon Glass wrote:
>>>>> A limitation of the EFI loader at present is that it does not build with
>>>>> sandbox. This makes it hard to write tests, since sandbox is used for most
>>>>> testing in U-Boot.
>>>>>
>>>>> This series enables the EFI loader feature. It allows sandbox to build and
>>>>> run a trivial function which calls the EFI API to output a message.
>>>>>
>>>>> Much work remains but this should serve as a basis for adding tests more
>>>>> easily for EFI loader.
>>>>>
>>>>> This series sits on top of Heinrich's recent EFI test series. It is
>>>>> available at u-boot-dm/efi-working
>>>>>
>>>>>
>>>>> Simon Glass (16):
>>>>> efi: Update efi_smbios_register() to return error code
>>>>> efi: Move the init check inside efi_init_obj_list()
>>>>> efi: Add error checking for efi_init_obj_list()
>>>>> efi: Add a TODO to efi_init_obj_list()
>>>>> efi: Correct header order in efi_memory
>>>>> efi: sandbox: Adjust memory setup for sandbox
>>>>> sandbox: smbios: Update to support sandbox
>>>>> sandbox: Add a setjmp() implementation
>>>>> efi: sandbox: Add required linker sections
>>>>> efi: sandbox: Add distroboot support
>>>>> Define board_quiesce_devices() in a shared location
>>>>> Add a comment for board_quiesce_devices()
>>>>> efi: sandbox: Add relocation constants
>>>>> efi: Add a comment about duplicated ELF constants
>>>>> efi: sandbox: Enable EFI loader builder for sandbox
>>>>> efi: sandbox: Add a simple 'bootefi test' command
>>>>>
>>>>> arch/arm/include/asm/u-boot-arm.h | 1 -
>>>>> arch/sandbox/cpu/cpu.c| 13 ++
>>>>> arch/sandbox/cpu/os.c | 17
>>>>> arch/sandbox/cpu/u-boot.lds | 29 +
>>>>> arch/sandbox/include/asm/setjmp.h | 21 +++
>>>>> arch/sandbox/lib/Makefile | 2 +-
>>>>> arch/sandbox/lib/sections.c | 12 +
>>>>> arch/x86/include/asm/u-boot-x86.h | 1 -
>>>>> arch/x86/lib/bootm.c | 4 ---
>>>>> cmd/bootefi.c | 54
>>>>> ++-
>>>>> common/bootm.c| 4 +++
>>>>> configs/sandbox_defconfig | 1 +
>>>>> include/bootm.h | 8 ++
>>>>> include/config_distro_bootcmd.h | 2 +-
>>>>> include/efi_loader.h | 13 --
>>>>> include/os.h | 21 +++
>>>>> lib/efi_loader/Kconfig| 12 -
>>>>> lib/efi_loader/Makefile | 1 +
>>>>> lib/efi_loader/efi_boottime.c | 4 +++
>>>>> lib/efi_loader/efi_memory.c | 33 +---
>>>>> lib/efi_loader/efi_runtime.c | 7 +
>>>>> lib/efi_loader/efi_smbios.c | 6 +++--
>>>>> lib/efi_loader/efi_test.c | 17
>>>>> lib/smbios.c | 38 ---
>>>>> 24 files changed, 277 insertions(+), 44 deletions(-)
>>>>> create mode 100644 arch/sandbox/include/asm/setjmp.h
>>>>> create mode 100644 arch/sandbox/lib/sections.c
>>>>> create mode 100644 lib/efi_loader/efi_test.c
>>>>>
>>>> Thanks for enabling efi_loader on sandbox. That will make many things
>>>> easier.
>>>>
>>>> Unfortunately
>>>> efi_status_t EFIAPI efi_selftest(efi_handle_t image_handle,
>>>> struct efi_system_table *systab)
>>>> {
>>>> ...
>>>> boottime = systable->boottime;
>>>> ...
>>>> ret = boottime->allocate_pool(EFI_BOOT_SERVICES_DATA, map_size,
>>>> (void **)&memory_map);
>>>> leads to a segmentation f
Re: [U-Boot] [PATCH 00/16] efi: Enable basic sandbox support for EFI loader
On Mon, Sep 18, 2017 at 9:31 AM, Rob Clark wrote:
> On Mon, Sep 18, 2017 at 9:18 AM, Rob Clark wrote:
>> On Sun, Sep 17, 2017 at 11:48 PM, Heinrich Schuchardt
>> wrote:
>>> On 09/18/2017 12:59 AM, Simon Glass wrote:
>>>> A limitation of the EFI loader at present is that it does not build with
>>>> sandbox. This makes it hard to write tests, since sandbox is used for most
>>>> testing in U-Boot.
>>>>
>>>> This series enables the EFI loader feature. It allows sandbox to build and
>>>> run a trivial function which calls the EFI API to output a message.
>>>>
>>>> Much work remains but this should serve as a basis for adding tests more
>>>> easily for EFI loader.
>>>>
>>>> This series sits on top of Heinrich's recent EFI test series. It is
>>>> available at u-boot-dm/efi-working
>>>>
>>>>
>>>> Simon Glass (16):
>>>> efi: Update efi_smbios_register() to return error code
>>>> efi: Move the init check inside efi_init_obj_list()
>>>> efi: Add error checking for efi_init_obj_list()
>>>> efi: Add a TODO to efi_init_obj_list()
>>>> efi: Correct header order in efi_memory
>>>> efi: sandbox: Adjust memory setup for sandbox
>>>> sandbox: smbios: Update to support sandbox
>>>> sandbox: Add a setjmp() implementation
>>>> efi: sandbox: Add required linker sections
>>>> efi: sandbox: Add distroboot support
>>>> Define board_quiesce_devices() in a shared location
>>>> Add a comment for board_quiesce_devices()
>>>> efi: sandbox: Add relocation constants
>>>> efi: Add a comment about duplicated ELF constants
>>>> efi: sandbox: Enable EFI loader builder for sandbox
>>>> efi: sandbox: Add a simple 'bootefi test' command
>>>>
>>>> arch/arm/include/asm/u-boot-arm.h | 1 -
>>>> arch/sandbox/cpu/cpu.c| 13 ++
>>>> arch/sandbox/cpu/os.c | 17
>>>> arch/sandbox/cpu/u-boot.lds | 29 +
>>>> arch/sandbox/include/asm/setjmp.h | 21 +++
>>>> arch/sandbox/lib/Makefile | 2 +-
>>>> arch/sandbox/lib/sections.c | 12 +
>>>> arch/x86/include/asm/u-boot-x86.h | 1 -
>>>> arch/x86/lib/bootm.c | 4 ---
>>>> cmd/bootefi.c | 54
>>>> ++-
>>>> common/bootm.c| 4 +++
>>>> configs/sandbox_defconfig | 1 +
>>>> include/bootm.h | 8 ++
>>>> include/config_distro_bootcmd.h | 2 +-
>>>> include/efi_loader.h | 13 --
>>>> include/os.h | 21 +++
>>>> lib/efi_loader/Kconfig| 12 -
>>>> lib/efi_loader/Makefile | 1 +
>>>> lib/efi_loader/efi_boottime.c | 4 +++
>>>> lib/efi_loader/efi_memory.c | 33 +---
>>>> lib/efi_loader/efi_runtime.c | 7 +
>>>> lib/efi_loader/efi_smbios.c | 6 +++--
>>>> lib/efi_loader/efi_test.c | 17
>>>> lib/smbios.c | 38 ---
>>>> 24 files changed, 277 insertions(+), 44 deletions(-)
>>>> create mode 100644 arch/sandbox/include/asm/setjmp.h
>>>> create mode 100644 arch/sandbox/lib/sections.c
>>>> create mode 100644 lib/efi_loader/efi_test.c
>>>>
>>> Thanks for enabling efi_loader on sandbox. That will make many things
>>> easier.
>>>
>>> Unfortunately
>>> efi_status_t EFIAPI efi_selftest(efi_handle_t image_handle,
>>> struct efi_system_table *systab)
>>> {
>>> ...
>>> boottime = systable->boottime;
>>> ...
>>> ret = boottime->allocate_pool(EFI_BOOT_SERVICES_DATA, map_size,
>>> (void **)&memory_map);
>>> leads to a segmentation fault:
>>
>> I'm seeing something similar, because:
>>
>> (gdb) print gd->bd->bi_dram[0]
>> $2 = {start = 0, size = 134217728}
>>
>> u-boot expects 1:1 phys:virt mapping, so that probably won't work.
>
> The following quick hack works.. something similar could probably be
> smashed in to ""
Re: [U-Boot] [PATCH 00/16] efi: Enable basic sandbox support for EFI loader
On Mon, Sep 18, 2017 at 9:18 AM, Rob Clark wrote:
> On Sun, Sep 17, 2017 at 11:48 PM, Heinrich Schuchardt
> wrote:
>> On 09/18/2017 12:59 AM, Simon Glass wrote:
>>> A limitation of the EFI loader at present is that it does not build with
>>> sandbox. This makes it hard to write tests, since sandbox is used for most
>>> testing in U-Boot.
>>>
>>> This series enables the EFI loader feature. It allows sandbox to build and
>>> run a trivial function which calls the EFI API to output a message.
>>>
>>> Much work remains but this should serve as a basis for adding tests more
>>> easily for EFI loader.
>>>
>>> This series sits on top of Heinrich's recent EFI test series. It is
>>> available at u-boot-dm/efi-working
>>>
>>>
>>> Simon Glass (16):
>>> efi: Update efi_smbios_register() to return error code
>>> efi: Move the init check inside efi_init_obj_list()
>>> efi: Add error checking for efi_init_obj_list()
>>> efi: Add a TODO to efi_init_obj_list()
>>> efi: Correct header order in efi_memory
>>> efi: sandbox: Adjust memory setup for sandbox
>>> sandbox: smbios: Update to support sandbox
>>> sandbox: Add a setjmp() implementation
>>> efi: sandbox: Add required linker sections
>>> efi: sandbox: Add distroboot support
>>> Define board_quiesce_devices() in a shared location
>>> Add a comment for board_quiesce_devices()
>>> efi: sandbox: Add relocation constants
>>> efi: Add a comment about duplicated ELF constants
>>> efi: sandbox: Enable EFI loader builder for sandbox
>>> efi: sandbox: Add a simple 'bootefi test' command
>>>
>>> arch/arm/include/asm/u-boot-arm.h | 1 -
>>> arch/sandbox/cpu/cpu.c| 13 ++
>>> arch/sandbox/cpu/os.c | 17
>>> arch/sandbox/cpu/u-boot.lds | 29 +
>>> arch/sandbox/include/asm/setjmp.h | 21 +++
>>> arch/sandbox/lib/Makefile | 2 +-
>>> arch/sandbox/lib/sections.c | 12 +
>>> arch/x86/include/asm/u-boot-x86.h | 1 -
>>> arch/x86/lib/bootm.c | 4 ---
>>> cmd/bootefi.c | 54
>>> ++-
>>> common/bootm.c| 4 +++
>>> configs/sandbox_defconfig | 1 +
>>> include/bootm.h | 8 ++
>>> include/config_distro_bootcmd.h | 2 +-
>>> include/efi_loader.h | 13 --
>>> include/os.h | 21 +++
>>> lib/efi_loader/Kconfig| 12 -
>>> lib/efi_loader/Makefile | 1 +
>>> lib/efi_loader/efi_boottime.c | 4 +++
>>> lib/efi_loader/efi_memory.c | 33 +---
>>> lib/efi_loader/efi_runtime.c | 7 +
>>> lib/efi_loader/efi_smbios.c | 6 +++--
>>> lib/efi_loader/efi_test.c | 17
>>> lib/smbios.c | 38 ---
>>> 24 files changed, 277 insertions(+), 44 deletions(-)
>>> create mode 100644 arch/sandbox/include/asm/setjmp.h
>>> create mode 100644 arch/sandbox/lib/sections.c
>>> create mode 100644 lib/efi_loader/efi_test.c
>>>
>> Thanks for enabling efi_loader on sandbox. That will make many things
>> easier.
>>
>> Unfortunately
>> efi_status_t EFIAPI efi_selftest(efi_handle_t image_handle,
>> struct efi_system_table *systab)
>> {
>> ...
>> boottime = systable->boottime;
>> ...
>> ret = boottime->allocate_pool(EFI_BOOT_SERVICES_DATA, map_size,
>> (void **)&memory_map);
>> leads to a segmentation fault:
>
> I'm seeing something similar, because:
>
> (gdb) print gd->bd->bi_dram[0]
> $2 = {start = 0, size = 134217728}
>
> u-boot expects 1:1 phys:virt mapping, so that probably won't work.
The following quick hack works.. something similar could probably be
smashed in to ""
diff --git a/lib/efi_loader/efi_memory.c b/lib/efi_loader/efi_memory.c
index cddafe2d43..da2079a4b1 100644
--- a/lib/efi_loader/efi_memory.c
+++ b/lib/efi_loader/efi_memory.c
@@ -459,9 +459,10 @@ int efi_memory_init(void)
unsigned long uboot_start, uboot_pages;
unsigned long uboot_stack_size = 16 * 1024 * 1024;
-efi_add_known_memory();
if (!IS_ENABLED(CONFIG_SANDBOX))
