On Mon, May 14, 2018 at 05:56:27PM +0200, Dr. Philipp Tomsich wrote: > I had a bit more time to look into this and it looks as if we have two > problem-spots... > > First, there's a type-mismatch between ram_info.size (a size_t) and > gd.ram_size (phys_size_t). > While we can increase the size of a phys_size_t to 64bit (by defining > CONFIG_PHYS_64BIT), > the size_t will always be an unsigned int on a 32bit arm architecture. So > here's one possible > pitfall that should be resolved. > > Once this is adjusted, we might just increase the width of ram_info.size to > 64bit by enabling > CONFIG_PHYS_64BIT ... however, this comes with a caveat: the default cell > sizes for the > FDT (via fdtdec) also increases. I.e. if any come in our arch or the drivers > still goes through > the fdtdec-functions, we'll end up with a problem. > > As my test coverage is limited to 64bit targets, I can't tell whether > defining the PHYS_64BIT > configuration would be possible for the RK3288 -- if it is, we'd have a > rather easy way forward > and could reuse the phys_size_t for ram_info.size. > > I'd appreciate if you could take a look at whether CONFIG_PHYS_64BIT gets us > into a lot > of trouble on the RK3288 or whether this will trigger just a few minor > adjustments... > > Thanks, > Philipp.
So explain to me what you'd like me to do here, if you would. What I gather from this is you want me to flip CONFIG_PHYS_64BIT and see if it works or what? I can flash/reflash u-boot and coreboot pretty easily on the device, so I'm down for any sort of hardware testing needed to get this into a usable state. Regards, Marty. _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
