[U-Boot] [PATCH 4/9] efi_loader: Add boot time services

[Alexander Graf <agraf@suse.de>]

On 15.01.16 15:21, Leif Lindholm wrote:
> On Fri, Jan 15, 2016 at 03:14:54PM +0100, Alexander Graf wrote:
>> On 15.01.16 14:02, Leif Lindholm wrote:
>>>>> 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).
> 
> Yeah, sure.
> 
>> With the UEFI entry path, Linux will ignore memory nodes in dt, right?
> 
> Yep.
> 
>>>>>> +#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 :).
> 
> It isn't really the kind of thing I'm here to review, but ...
> Current version requires knowledge of state of certain macros, the
> alternative is explicit without familiarity with the codebase.

Hrm. So how about a comment like this:

 /* RAM starts at an offset above 0 */

right before the #ifdef?


Alex