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