Re: Cubox-i 4x4 RAM [was Re: Performance of armhf boards]
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 <vagrant@debian.org> wrote:
> On 2016-04-21, Rick Thomas wrote:
>> On Apr 21, 2016, at 9:04 AM, Vagrant Cascadian <vagrant@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
Reply to: