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 _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
