From mboxrd@z Thu Jan 1 00:00:00 1970 From: Alexander Graf Date: Fri, 15 Jan 2016 18:04:33 +0100 Subject: [U-Boot] [PATCH 4/9] efi_loader: Add boot time services In-Reply-To: <20160115142141.GX25034@bivouac.eciton.net> References: <1450792676-109541-1-git-send-email-agraf@suse.de> <1450792676-109541-5-git-send-email-agraf@suse.de> <20151226180901.GY25034@bivouac.eciton.net> <5698399B.3000409@suse.de> <20160115130201.GU25034@bivouac.eciton.net> <5698FEDE.30508@suse.de> <20160115142141.GX25034@bivouac.eciton.net> Message-ID: <569926A1.2040304@suse.de> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.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