From mboxrd@z Thu Jan 1 00:00:00 1970 From: Timur Tabi Date: Thu, 27 May 2010 15:01:06 -0500 Subject: [U-Boot] [PATCH] [RFC] memsize.c: adapt get_ram_size() for address spaces >32 bit In-Reply-To: <20100527194442.632FEEAC238@gemini.denx.de> References: <1274983869-9173-1-git-send-email-wd@denx.de> <20100527194442.632FEEAC238@gemini.denx.de> Message-ID: <4BFECF82.60901@freescale.com> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de Wolfgang Denk wrote: >> The problem is that on all of our PowerPC boards, the TLBs only map >> the lower 2GB of memory, regardless as to how much is present. So we >> still can't use get_ram_size() to determine how much memory is in the >> system, because any attempt to access memory higher than 2GB will >> fail. > > Now this is your problem, then, and you should kno how to fix it. Scott pointed out that writing/reading memory to determine how much memory actually exists is dangerous. I'm not convinced that I should be using get_ram_size(). I still believe that I shouldn't. >> And even if we did have TLBs for all of memory, an attempt to access >> RAM that doesn't exist will cause a machine check, which will hang >> U-Boot. So we still couldn't use get_ram_size() to determine how much >> RAM actually exists. > > Please see how it's done on all other PowerPC systems, and do similar. I have not been able to find any other PowerPC system in U-boot that supports more memory than is mapped. If you know of one, please tell me. Otherwise, I would say that there are no other comparable PowerPC systems that I can use as an example. >>> -long get_ram_size(volatile long *base, long maxsize) >>> +phys_size_t get_ram_size(volatile phys_addr_t *base, phys_size_t maxsize) >> >> I don't think you want 'base' to be a pointer to phys_addr_t, because >> the pointer type determines how much is read/written in a single >> operation. I don't think you want to be doing 64-bit reads and >> writes. > > I don't know your mnemory bus. This is an RFC patch. My point is that sizeof(phys_addr_t) has got nothing to do with the size of the read/write operation, so I think it's wrong on all platforms. -- Timur Tabi Linux kernel developer at Freescale