All of lore.kernel.org
 help / color / mirror / Atom feed
From: Alexander Graf <agraf@suse.de>
To: u-boot@lists.denx.de
Subject: [U-Boot] [PATCH 4/9] efi_loader: Add boot time services
Date: Fri, 15 Jan 2016 15:14:54 +0100	[thread overview]
Message-ID: <5698FEDE.30508@suse.de> (raw)
In-Reply-To: <20160115130201.GU25034@bivouac.eciton.net>



On 15.01.16 14:02, Leif Lindholm wrote:
> On Fri, Jan 15, 2016 at 01:13:15AM +0100, Alexander Graf wrote:
>> On 26.12.15 19:09, Leif Lindholm wrote:
>>>> diff --git a/lib/efi_loader/efi_boottime.c b/lib/efi_loader/efi_boottime.c
>>>> new file mode 100644
>>>> index 0000000..ed95962
>>>> --- /dev/null
>>>> +++ b/lib/efi_loader/efi_boottime.c
>>>> @@ -0,0 +1,838 @@
>>>> +/*
>>>> + *  EFI application boot time services
>>>> + *
> ...
>>>> +
>>>> +static unsigned long efi_raise_tpl(unsigned long new_tpl)
>>>> +{
>>>> +	EFI_ENTRY("0x%lx", new_tpl);
>>>> +	return EFI_EXIT(efi_unsupported(__func__));
>>>
>>> "Unlike other UEFI interface functions, EFI_BOOT_SERVICES.RaiseTPL()
>>> does not return a status code. Instead, it returns the previous task
>>> priority level, which is to be restored later with a matching call to
>>> RestoreTPL()."
>>
>> Since we don't do TPLs (or IRQs for that matter), I'll just return 0 here.
> 
> Sure.
> 
>>>> +}
>>>> +
>>>> +static void efi_restore_tpl(unsigned long old_tpl)
>>>> +{
>>>> +	EFI_ENTRY("0x%lx", old_tpl);
>>>> +	EFI_EXIT(efi_unsupported(__func__));
>>>
>>> (void function, nothing to return)
>>
>> Yes, hence no return. EFI_EXIT deals with the gd swapping and
>> efi_unsupported() gives me a nice debug message :).
> 
> Ah, ok.
> 
>>>> +static efi_status_t efi_allocate_pages(int type, int memory_type,
>>>> +				       unsigned long pages, uint64_t *memory)
>>>> +{
>>>> +	u64 len = pages << 12;
>>>> +	efi_status_t r = EFI_SUCCESS;
>>>> +
>>>> +	EFI_ENTRY("%d, %d, 0x%lx, %p", type, memory_type, pages, memory);
>>>> +
>>>> +	switch (type) {
>>>> +	case 0:
>>>> +		/* Any page means we can go to efi_alloc */
>>>> +		*memory = (unsigned long)efi_alloc(len, memory_type);
>>>> +		break;
>>>> +	case 1:
>>>> +		/* Max address */
>>>> +		if (gd->relocaddr < *memory) {
>>>> +			*memory = (unsigned long)efi_alloc(len, memory_type);
>>>> +			break;
>>>> +		}
>>>> +		r = EFI_UNSUPPORTED;
>>>
>>> EFI_OUT_OF_RESOURCES/EFI_NOT_FOUND?
>>>
>>>> +		break;
>>>> +	case 2:
>>>> +		/* Exact address, grant it. The addr is already in *memory. */
>>>
>>> As far as I can tell, this is why GRUB works. Because it filters
>>> through the memory map manually, requesting to allocate its heap at an
>>> exact address in a region of free memory in the UEFI memory map.
>>
>> Yes.
>>
>>> The key is that EFI_LOADER_MEMORY will be used by applications loaded
>>> as well as by U-Boot to load applications into. A simple example where
>>> this could be problematic would be a large(ish) initrd loaded via initrd=
>>> on kernel (stub loader) command line rather than via GRUB.
>>
>> Ah, so here the 128MB limit on the LOADER_DATA section might bite us?
> 
> Yeah, I think so.
> 
>>>> +	runtime_start = (ulong)&__efi_runtime_start & ~0xfffULL;
>>>> +	runtime_end = ((ulong)&__efi_runtime_stop + 0xfff) & ~0xfffULL;
>>>> +	runtime_len_pages = (runtime_end - runtime_start) >> 12;
>>>> +	runtime_len = runtime_len_pages << 12;
>>>> +
>>>> +	/* Fill in where normal RAM is (up to U-Boot) */
>>>> +	efi_memory_map[0].num_pages = gd->relocaddr >> 12;
>>>
>>> U-Boot question: is gd->relocaddr always the offset from start of RAM?
>>> How does this work with gaps in memory map?
>>
>> U-Boot always relocates itself at TOM (or at least what we consider TOM
>> here). gd->relocaddr is the physical address of the start of U-Boot
>> which is right below TOM.
> 
> Still ... would need additional handling if memory has holes (like,
> fitted with multiple DIMMs smaller than the individual memory window
> reserved for them). Or even on something like Juno, which has 2GB of
> RAM at 0x00_8000_0000, and a further 6GB at 0x08_8000_0000 (I think).

Yes. I think we'll have to just implement that when we hit the first
board that does this (and has awareness in U-Boot for it).

With the UEFI entry path, Linux will ignore memory nodes in dt, right?

> 
>>>> +#ifdef CONFIG_SYS_SDRAM_BASE
>>>> +	efi_memory_map[0].physical_start = CONFIG_SYS_SDRAM_BASE;
>>>> +	efi_memory_map[0].virtual_start = CONFIG_SYS_SDRAM_BASE;
>>>> +	efi_memory_map[0].num_pages -= CONFIG_SYS_SDRAM_BASE >> 12;
>>> #else
>>> #error "..."
>>> ?
>>
>> If it's not defined, it's 0 :).
> 
> Make it
> #if CONFIG_SYS_SDRAM_BASE != 0
> for clarity?

I really don't think we'll make it more readable with more #iffery here :).


Alex

  reply	other threads:[~2016-01-15 14:14 UTC|newest]

Thread overview: 70+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-12-22 13:57 [U-Boot] [PATCH 0/9] EFI payload / application support Alexander Graf
2015-12-22 13:57 ` [U-Boot] [PATCH 1/9] disk/part.c: Expose a list of available block drivers Alexander Graf
2016-01-14 19:18   ` Tom Rini
2016-01-14 23:11   ` Simon Glass
2016-01-14 23:33     ` Alexander Graf
2016-01-15  0:46       ` Simon Glass
2016-01-15  1:04         ` Alexander Graf
2015-12-22 13:57 ` [U-Boot] [PATCH 2/9] include/efi_api.h: Add more detailed API definitions Alexander Graf
2015-12-22 13:57 ` [U-Boot] [PATCH 3/9] efi_loader: Add PE image loader Alexander Graf
2015-12-26 16:26   ` Leif Lindholm
2016-01-14 23:45     ` Alexander Graf
2016-01-15 12:29       ` Leif Lindholm
2015-12-22 13:57 ` [U-Boot] [PATCH 4/9] efi_loader: Add boot time services Alexander Graf
2015-12-22 14:15   ` Andreas Färber
2015-12-22 14:31     ` Alexander Graf
2015-12-26 18:09   ` Leif Lindholm
2016-01-15  0:13     ` Alexander Graf
2016-01-15 13:02       ` Leif Lindholm
2016-01-15 14:14         ` Alexander Graf [this message]
2016-01-15 14:21           ` Leif Lindholm
2016-01-15 17:04             ` Alexander Graf
2016-01-15  3:40     ` Alexander Graf
2015-12-22 13:57 ` [U-Boot] [PATCH 5/9] efi_loader: Add console interface Alexander Graf
2015-12-22 13:57 ` [U-Boot] [PATCH 6/9] efi_loader: Add runtime services Alexander Graf
2015-12-26 18:33   ` Leif Lindholm
2016-01-15  0:26     ` Alexander Graf
2016-01-15 13:52       ` Leif Lindholm
2016-01-15 14:15         ` Alexander Graf
2016-01-15 14:22           ` Leif Lindholm
2015-12-22 13:57 ` [U-Boot] [PATCH 7/9] efi_loader: Add disk interfaces Alexander Graf
2016-01-15  1:37   ` Simon Glass
2016-01-15  2:40     ` Alexander Graf
2015-12-22 13:57 ` [U-Boot] [PATCH 8/9] efi_loader: Add "bootefi" command Alexander Graf
2015-12-24 11:15   ` Matwey V. Kornilov
2015-12-25  9:02     ` Alexander Graf
2015-12-25  9:25       ` Andreas Färber
2015-12-25  9:40         ` Matwey V. Kornilov
2015-12-25 17:04           ` Tom Rini
2015-12-26 18:55         ` Leif Lindholm
2015-12-27 15:33           ` Alexander Graf
2015-12-26 18:45       ` Leif Lindholm
2015-12-25 16:58     ` Tom Rini
2015-12-22 13:57 ` [U-Boot] [PATCH 9/9] efi_loader: hook up in build environment Alexander Graf
2015-12-22 18:28 ` [U-Boot] [PATCH 0/9] EFI payload / application support Matwey V. Kornilov
2015-12-22 20:32   ` Alexander Graf
2015-12-25  3:29 ` Tom Rini
2015-12-25  8:53   ` Alexander Graf
2015-12-25 16:50     ` Tom Rini
2015-12-25 16:53       ` Matwey V. Kornilov
2015-12-25 17:00         ` Tom Rini
2016-01-15  3:00       ` Alexander Graf
2016-01-15  3:06         ` Tom Rini
2015-12-25 19:34 ` Blibbet
2015-12-26 15:31 ` Leif Lindholm
2015-12-26 16:27   ` Alexander Graf
2015-12-26 19:34     ` Leif Lindholm
2016-01-04 16:25       ` Alexander Graf
2016-01-04 16:56         ` Tom Rini
2016-01-04 18:03           ` Andreas Färber
2016-01-04 18:41             ` Andreas Färber
2016-01-04 19:54               ` Tom Rini
2016-01-04 22:37                 ` Dennis Gilmore
2016-01-04 22:48                   ` Alexander Graf
2016-01-15  3:40             ` Peter Robinson
2016-01-04 20:11           ` Matwey V. Kornilov
2016-01-15  3:32           ` Peter Robinson
2015-12-27 18:10   ` Tom Rini
2015-12-27 18:39     ` Leif Lindholm
2015-12-27 19:48       ` Tom Rini
2016-01-05 20:18       ` Tom Rini

Reply instructions:

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

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

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

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

  git send-email \
    --in-reply-to=5698FEDE.30508@suse.de \
    --to=agraf@suse.de \
    --cc=u-boot@lists.denx.de \
    /path/to/YOUR_REPLY

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

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