Marty, > On 6 Jul 2018, at 05:11, Marty E. Plummer <hanet...@startmail.com> wrote: > > On Sat, May 19, 2018 at 02:08:53PM +0200, Dr. Philipp Tomsich wrote: >> Marty, >> >>> On 19 May 2018, at 12:40, Marty E. Plummer <hanet...@startmail.com> wrote: >>> >>> 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. >> >> Yes, just enable PHYS_64BIT and report on how far it goes (activating some >> debug may be helpful to understand what goes wrong, if it fails). >> >> My gut feeling is that it could work, but there’s a number of pitfalls and >> we may >> not be lucky. >> > Testing flipping CONFIG_PHYS_64BIT, both with and without my 'clamping' > patch to sdram_common.c, has the same results, in that all that is > output on the servo console is that wierd <?> output. Where to from > here, then?
I have a patchset for changing the relevant fields in U-Boot to allow for 33bits (i.e. using u64) for the RAM size and it finally passes Travis cleanly. It will be another round or two of cleanup before I can submit the series — once this happens, I’ll copy you so you can give your Tested-by if it works… Thanks, Phil. _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot