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
next prev parent 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).