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

[Daniel Schwierzeck]

On 22.01.2018 19:01, Paul Burton wrote:
> 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?
> 

I had to remove the patches because there is a failing test case in qemu
pytest [1] which needs to be fixed. The test case fetches the RAM base
address from the "bdinfo" output which is 0x0 due to
CONFIG_SYS_SDRAM_BASE = 0. I'm not sure if we need to add a phys_to_virt
mapping to the "md" command or if "bdinfo" should show the virtual
address. What do you think? Actually other tools like "cp" are also
affected.

Also we now need a new patch for CONFIG_SYS_SDRAM_BASE in various
"include/configs/bmips_*.h" files.

[1] https://travis-ci.org/danielschwierzeck/u-boot/jobs/330776664

-- 
- Daniel

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20180122/c7b14d96/attachment.sig>