[U-Boot] [PATCH 3/3] rockchip: fix incorrect detection of ram size

Marty E. Plummer hanetzer at startmail.com
Sat May 19 10:40:40 UTC 2018


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.


More information about the U-Boot mailing list