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

[Leif Lindholm]

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.

/
    Leif