[U-Boot] [PATCH] boston: Ensure DDR address calcuations don't overflow

[Paul Burton]

Hi Daniel,

On Fri, Jan 19, 2018 at 12:31:25PM +0100, Daniel Schwierzeck wrote:
> On 18.01.2018 22:19, Paul Burton wrote:
> > When constraining the highest DDR address that U-Boot will use for its
> > data & relocated self, we need to handle the common case in which a 32
> > bit system with 2GB DDR will have a zero gd->ram_top, due to the
> > addition of 2GB (0x80000000) to the base address of kseg0 (also
> > 0x80000000) which overflows & wraps to 0.
> > 
> > We originally had a check for this case, but it was lost in commit
> > 78edb25729ce ("boston: Provide physical CONFIG_SYS_SDRAM_BASE") causing
> > problems for the affected 32 bit systems.
> 
> I think I did a wrong conflict resolution because the patch didn't apply
> anymore. I folded this patch into "boston: Provide physical
> CONFIG_SYS_SDRAM_BASE" to fix this. Actually I wanted to resend the
> updated patches. But if you are okay with the current state in
> u-boot-mips/next branch, I'll take them as they are.
> 
> BTW: could you resend your series "boston: Ethernet support for MIPS
> Boston board"? I still have no Acks or Reviews on the generic DM parts.
> Thanks.

When I last fetched from u-boot-mips.git I saw patches up to
564cc3a11c45 ("mips: Remove virt_to_phys call on bi_memstart") in the
next branch, which I have then rebased my ethernet patches atop with the
result working fine on a real Boston board.

I see that next now contains only 2 patches up to d2a4e3664150 ("mips:
bmips: increment SYS_MALLOC_F_LEN") and has dropped the patches
switching to a physical CONFIG_SYS_SDRAM_BASE. Would you like me to
rebase those plus the Boston ethernet support atop the current next
branch?

Thanks,
    Paul