u-boot.lists.denx.de archive mirror
 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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).