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.