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
signature.asc
Description: OpenPGP digital signature
_______________________________________________ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot