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