Any chance I could download a pre-built binary? (It’s been a couple of decades since I actually built any binaries… |-: )
Please forgive my curiosity. I’m trying to understand how this process works… Do I understand correctly that this is part of the definition of a structure that contains memory config parameters and gets passed from u-boot to the kernel when it gets control? And why is this determined by a compile-time value? Wouldn’t it be more flexible if the kernel (or u-boot) discovered it at run-time? For example, by probing successively higher memory locations until it got a men-fault? Fascinating… What other things, besides memory config, get passed this way? Thanks! Rick On Apr 22, 2016, at 2:02 PM, Vagrant Cascadian <vagr...@debian.org> wrote: > On 2016-04-21, Rick Thomas wrote: >> On Apr 21, 2016, at 9:04 AM, Vagrant Cascadian <vagr...@debian.org> wrote: >>> On 2016-04-21, Rick Thomas wrote: >>>> But if I were using your patched mainline u-boot, I would get a >>>> different (larger) number (almost, but not quite, the full 4.0GiB)? >>> >>> That’s how it's worked for me, yes. >> >> Would you be willing to share this modified u-boot with me? I’d like >> to try it out on my device to see if it’s really an i4pro or a 4x4. > > It's a one-line patch against u-boot 2016.03~rc1: > > Index: u-boot/board/solidrun/mx6cuboxi/mx6cuboxi.c > =================================================================== > --- u-boot.orig/board/solidrun/mx6cuboxi/mx6cuboxi.c > +++ u-boot/board/solidrun/mx6cuboxi/mx6cuboxi.c > @@ -563,7 +563,7 @@ static struct mx6_ddr3_cfg mem_ddr_4g = > .density = 4, > .width = 16, > .banks = 8, > - .rowaddr = 15, > + .rowaddr = 16, > .coladdr = 10, > .pagesz = 2, > .trcd = 1375, > > I haven't tested on a more recent version, but it would probably work as > well. > > > live well, > vagrant
