> On 26 Jul 2018, at 22:05, Carlo Caione <ca...@endlessm.com> wrote: > > On Thu, 2018-07-26 at 15:59 +0200, Philipp Tomsich wrote: >> The calculation in `rockchip_sdram_size` would overflow for 4GB on >> 32bit systems (i.e. when PHYS_64BIT is not defined). >> >> This makes the internal variables and the signature prototype use a >> u64 to ensure that we can represent the 33rd bit (as in '4GB'). >> > > Hi Philipp, > just to let you know that this is still not working on the veyron jerry > chromebook with 4GB I have here (RK3288). The boot stops at: > > U-Boot SPL 2018.07-00403-gdbe6ef8276 (Jul 26 2018 - 17:21:11 +0100) > Trying to boot from SPI > > U-Boot 2018.07-00403-gdbe6ef8276 (Jul 26 2018 - 17:21:11 +0100) > > Model: Google Jerry > DRAM: 0 Bytes > > I'm still investigating why but for sure there are several points to > fix to have a proper debug, see [0].
I reread ‘rockchip_sdram_size’ and it looks as if I forgot to mark the value shifted to create chipsize_mb as ULL. When looking at this code I had an uneasy feeling that this might run into the C type rules (i.e. 1 will be a 32bit integer and shifting it by 32 would result in 0), but I didn’t think that this would ever be the case and that any 4GB DRAM setup would be made up of multiple channels or of multiple ranks. > > Also I was wondering if we should also fix get_effective_memsize() and > gd->bd->bi_dram[].size > > [0]https://gist.github.com/carlocaione/b93cfd9ee71e07fcf68d5c02256ff0fa > > Cheers, > > -- > Carlo Caione <ca...@endlessm.com> _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
