Re: Cubox-i 4x4 RAM [was Re: Performance of armhf boards]
On Oct 5, 2016, at 1:54 PM, Vagrant Cascadian wrote: > On 2016-10-01, Rick Thomas wrote: >> On Jun 5, 2016, at 1:35 PM, Vagrant Cascadian wrote: >>> On 2016-06-05, Gaudenz Steinlin wrote: I have the same problem with my Cubox-i 4x4. Is there any progress on this? > ... Are the patches incorporated into the latest version in experimental? >>> >>> No, it requires a patch that does run-time detection. At least the >>> versions of u-boot in debian currently boot on both cubox-i4x4 and >>> cubox-i4pro, even if it limits ram to 2gb on the i4x4. >>> >>> Is there anything I could test to get this into Debian? >>> >>> Someone could write a patch acceptible for u-boot upstream that does >>> run-time detection... there may be folks on #u-boot on irc.freenode.net >>> willing to help a bit. >>> >>> It also might be good to file a bug report against the u-boot-imx >>> package in Debian at this point, so that the issue can at least be >>> tracked appropriately. > ... >> Sorry to bring this back up after such a long time, but I had a couple >> of thoughts that I’d like to bounce off those more knowledgable than >> I. >> >> Would it be possible to do one or the other of these two: >> >> 1) Put the 2GB vs 4GB setting in the .dtb file. >> >> 2) Put setting in a kernel command line argument. > > I believe it actually requires u-boot to initialize ram timings and > various other parameters. You can trick the kernel into using more > memory, but in my experience that just caused crashes when trying to use > more ram than u-boot initilized. > > It would of course be useful to experiment with alternative methods, but > my guess is getting proper patches into u-boot may likely be the > simplest approach. It just takes some work. scanning the subject lines in the u-boot list, it looks like somebody has made this work for a different (from the Cubox) architecture. > Subject: Re: [U-Boot] [PATCH v2 2/3] rk3288: sdram: auto-detect the > capacity Would you be interested in getting it to work on the Cubox i-4x4? It looks like the next couple of weeks for me will be free enough to do some testing, if you’re willing. Rick
Re: Cubox-i 4x4 RAM [was Re: Performance of armhf boards]
> On Oct 5, 2016, at 11:57 PM, Uwe Kleine-König wrote: > > Hello, > > On 10/05/2016 10:54 PM, Vagrant Cascadian wrote: >> I believe it actually requires u-boot to initialize ram timings and >> various other parameters. You can trick the kernel into using more > > Right, the kernel expects the boot loader to initialize RAM. I don't > know about u-boot, but barebox edits the dtb that is passed to the > kernel on the fly to contain the right description for all RAM it > initialized. > >> It would of course be useful to experiment with alternative methods, but >> my guess is getting proper patches into u-boot may likely be the >> simplest approach. It just takes some work. > > So another not too hard possibility is to port barebox to your board :-) > (This should really be easy, the i.MX6 is well supported in barebox, and > because barebox probes itself from a device tree that already exists it > should be really easy.) I don’t have the skills to participate in the porting, but I’ve got two Cubox-I4 devices, one with 2GB, one with 4GB RAM that I can use for testing, if somebody else wants to try. Enjoy! Rick
Re: Cubox-i 4x4 RAM [was Re: Performance of armhf boards]
Hello, On 10/05/2016 10:54 PM, Vagrant Cascadian wrote: > I believe it actually requires u-boot to initialize ram timings and > various other parameters. You can trick the kernel into using more Right, the kernel expects the boot loader to initialize RAM. I don't know about u-boot, but barebox edits the dtb that is passed to the kernel on the fly to contain the right description for all RAM it initialized. > It would of course be useful to experiment with alternative methods, but > my guess is getting proper patches into u-boot may likely be the > simplest approach. It just takes some work. So another not too hard possibility is to port barebox to your board :-) (This should really be easy, the i.MX6 is well supported in barebox, and because barebox probes itself from a device tree that already exists it should be really easy.) Best regards Uwe signature.asc Description: OpenPGP digital signature
Re: Cubox-i 4x4 RAM [was Re: Performance of armhf boards]
> On Oct 5, 2016, at 1:54 PM, Vagrant Cascadian wrote: > > It would of course be useful to experiment with alternative methods, but > my guess is getting proper patches into u-boot may likely be the > simplest approach. It just takes some work. Anything I can do as a tester to help with that process? How does one file a wishlist bug report to u-boot upstream? Would that help any? Rick
Re: Cubox-i 4x4 RAM [was Re: Performance of armhf boards]
On 2016-10-01, Rick Thomas wrote: > On Jun 5, 2016, at 1:35 PM, Vagrant Cascadian wrote: >> On 2016-06-05, Gaudenz Steinlin wrote: >>> I have the same problem with my Cubox-i 4x4. Is there any progress on >>> this? ... >>> Are the patches incorporated into the latest version in experimental? >> >> No, it requires a patch that does run-time detection. At least the >> versions of u-boot in debian currently boot on both cubox-i4x4 and >> cubox-i4pro, even if it limits ram to 2gb on the i4x4. >> >> >>> Is there anything I could test to get this into Debian? >> >> Someone could write a patch acceptible for u-boot upstream that does >> run-time detection... there may be folks on #u-boot on irc.freenode.net >> willing to help a bit. >> >> It also might be good to file a bug report against the u-boot-imx >> package in Debian at this point, so that the issue can at least be >> tracked appropriately. ... > Sorry to bring this back up after such a long time, but I had a couple > of thoughts that I’d like to bounce off those more knowledgable than > I. > > Would it be possible to do one or the other of these two: > > 1) Put the 2GB vs 4GB setting in the .dtb file. > > 2) Put setting in a kernel command line argument. I believe it actually requires u-boot to initialize ram timings and various other parameters. You can trick the kernel into using more memory, but in my experience that just caused crashes when trying to use more ram than u-boot initilized. It would of course be useful to experiment with alternative methods, but my guess is getting proper patches into u-boot may likely be the simplest approach. It just takes some work. live well, vagrant signature.asc Description: PGP signature
Re: Cubox-i 4x4 RAM [was Re: Performance of armhf boards]
On Jun 5, 2016, at 1:35 PM, Vagrant Cascadian wrote: > On 2016-06-05, Gaudenz Steinlin wrote: >> I have the same problem with my Cubox-i 4x4. Is there any progress on >> this? > > Not the I'm aware of. > > Currently, the one-liner I patch just hard-codes a different ram > configuration. In my experience it breaks booting on the cubox-i4pro. > > >> The version of u-boot mentioned above is no longer available. > > Must have removed it in order to test other features; sorry. > > >> Are the patches incorporated into the latest version in experimental? > > No, it requires a patch that does run-time detection. At least the > versions of u-boot in debian currently boot on both cubox-i4x4 and > cubox-i4pro, even if it limits ram to 2gb on the i4x4. > > >> Is there anything I could test to get this into Debian? > > Someone could write a patch acceptible for u-boot upstream that does > run-time detection... there may be folks on #u-boot on irc.freenode.net > willing to help a bit. > > It also might be good to file a bug report against the u-boot-imx > package in Debian at this point, so that the issue can at least be > tracked appropriately. > > > live well, > vagrant Sorry to bring this back up after such a long time, but I had a couple of thoughts that I’d like to bounce off those more knowledgable than I. Would it be possible to do one or the other of these two: 1) Put the 2GB vs 4GB setting in the .dtb file. 2) Put setting in a kernel command line argument. Wondering… Rick
Re: Cubox-i 4x4 RAM [was Re: Performance of armhf boards]
On 2016-06-05, Gaudenz Steinlin wrote: > I have the same problem with my Cubox-i 4x4. Is there any progress on > this? Not the I'm aware of. Currently, the one-liner I patch just hard-codes a different ram configuration. In my experience it breaks booting on the cubox-i4pro. > The version of u-boot mentioned above is no longer available. Must have removed it in order to test other features; sorry. > Are the patches incorporated into the latest version in experimental? No, it requires a patch that does run-time detection. At least the versions of u-boot in debian currently boot on both cubox-i4x4 and cubox-i4pro, even if it limits ram to 2gb on the i4x4. > Is there anything I could test to get this into Debian? Someone could write a patch acceptible for u-boot upstream that does run-time detection... there may be folks on #u-boot on irc.freenode.net willing to help a bit. It also might be good to file a bug report against the u-boot-imx package in Debian at this point, so that the issue can at least be tracked appropriately. live well, vagrant signature.asc Description: PGP signature
Re: Cubox-i 4x4 RAM [was Re: Performance of armhf boards]
Vagrant Cascadian writes: > [ Unknown signature status ] > On 2016-04-24, Rick Thomas wrote: >> Any chance I could download a pre-built binary? > > Just uploaded u-boot 2016.05-rc2 packages to: > > deb http://cascadia.debian.net/~vagrant/debian UNRELEASED main > > The u-boot-imx package there worked on my cubox-i4x4, but will almost > certainly hang on a cubox-i4pro. It also doesn't seem to boot with > firefly-4gb variant. Too experimental for Debian experimental... > > I have the same problem with my Cubox-i 4x4. Is there any progress on this? The version of u-boot mentioned above is no longer available. Are the patches incorporated into the latest version in experimental? Is there anything I could test to get this into Debian? Gaudenz
Re: Cubox-i 4x4 RAM [was Re: Performance of armhf boards]
On 04/26/16 00:51, Rick Thomas wrote: On Apr 21, 2016, at 11:54 PM, Rick Thomas wrote: I seem to remember that I got roughly the same number (lightly less than 2.0 GiB) when I booted the manufacturer supplied u-boot and Ubuntu kernel from the uSD-card that came with it. Maybe it came with a u-boot that didn't support the cubox-i4x4, as it wasn't added until relatively recently: https://github.com/SolidRun/u-boot-imx6 Or, maybe you really did get a cubox-i4pro. Possible… I’ll have to boot it from the original µSD-card and see what version of u-boot it has. I may have time to do that this weekend. Here’s the info on the u-boot from the original µSDcard that came with the device. U-Boot 2013.10-rc4-ga06fada (Jul 16 2014 - 10:20:49) I’ve attached an edited transcript of the console output, if that’s interesting. I’m pretty sure that u-boot from almost 2 years ago won’t have support for the “4x4”. Next is to try your updated u-boot and see what it says about available RAM. I finally got some time to test the experimental u-boot: u-boot-imx_2016.05~rc2+dfsg0~20160423~1-1_armhf.deb It installs and boots and recognizes 3.8GB RAM on the 4x4. So I guess I got a real 4x4 after all! I also have a cubox-i4pro (the 2GB variety). You suggested that this would probably not work there. Would you like me to test it for you? If that would speed up getting this patch into production, I'm willing to give it a try! Enjoy! Rick
Re: Cubox-i 4x4 RAM [was Re: Performance of armhf boards]
On Apr 21, 2016, at 11:54 PM, Rick Thomas wrote: >>> >>> I seem to remember that I got roughly the same number (lightly less >>> than 2.0 GiB) when I booted the manufacturer supplied u-boot and >>> Ubuntu kernel from the uSD-card that came with it. >> >> Maybe it came with a u-boot that didn't support the cubox-i4x4, as it >> wasn't added until relatively recently: >> >> https://github.com/SolidRun/u-boot-imx6 >> >> Or, maybe you really did get a cubox-i4pro. > > Possible… I’ll have to boot it from the original µSD-card and see what > version of u-boot it has. I may have time to do that this weekend. Here’s the info on the u-boot from the original µSDcard that came with the device. > U-Boot 2013.10-rc4-ga06fada (Jul 16 2014 - 10:20:49) I’ve attached an edited transcript of the console output, if that’s interesting. I’m pretty sure that u-boot from almost 2 years ago won’t have support for the “4x4”. Next is to try your updated u-boot and see what it says about available RAM. Enjoy! Rick uboot.log Description: Binary data
Re: Cubox-i 4x4 RAM [was Re: Performance of armhf boards]
On 2016-04-24, Rick Thomas wrote: > Any chance I could download a pre-built binary? Just uploaded u-boot 2016.05-rc2 packages to: deb http://cascadia.debian.net/~vagrant/debian UNRELEASED main The u-boot-imx package there worked on my cubox-i4x4, but will almost certainly hang on a cubox-i4pro. It also doesn't seem to boot with firefly-4gb variant. Too experimental for Debian experimental... > 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? The extent of my understanding is that u-boot configures the ram available that the kernel has access to. At least, that's what I've observed by experimentation on both the cubox-i and firefly boards. > 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? Run-time detection would be a lot better, yes. The vendor u-boot does this, but it's non-trivial to forward-port those patches to mainline u-boot, as they have diverged significantly. live well, vagrant > On Apr 22, 2016, at 2:02 PM, Vagrant Cascadian wrote: > >> On 2016-04-21, Rick Thomas wrote: >>> On Apr 21, 2016, at 9:04 AM, Vagrant Cascadian 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. signature.asc Description: PGP signature
Re: Cubox-i 4x4 RAM [was Re: Performance of armhf boards]
Hello, On 04/22/2016 08:54 AM, Rick Thomas wrote: > > On Apr 21, 2016, at 9:04 AM, Vagrant Cascadian wrote: > >> On 2016-04-21, Rick Thomas wrote: >>> Are you saying that the amount of RAM seen by Debian Linux is >>> determined by something in u-boot? >> >> Yes. > > How is this information communicated from u-boot to the Linux kernel? I > thought I understood (at least in principle) how the hand-off between then > worked, but clearly I’m missing something. RAM setup is done by the boot loader and Linux only gets told the offset and amount of RAM. If your machine uses dt that info is communicated in the /memory node, with ATAGs there is an ATAG_MEM tag for each bank. >> https://github.com/SolidRun/u-boot-imx6 >> >> Or, maybe you really did get a cubox-i4pro. > > Possible… I’ll have to boot it from the original µSD-card and see what > version of u-boot it has. I may have time to do that this weekend. You can also check which and how many memory chips are assembled on your machine. Best regards Uwe
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 wrote: > On 2016-04-21, Rick Thomas wrote: >> On Apr 21, 2016, at 9:04 AM, Vagrant Cascadian 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
Re: Cubox-i 4x4 RAM [was Re: Performance of armhf boards]
On Apr 21, 2016, at 9:04 AM, Vagrant Cascadian wrote: > On 2016-04-21, Rick Thomas wrote: >> Are you saying that the amount of RAM seen by Debian Linux is >> determined by something in u-boot? > > Yes. How is this information communicated from u-boot to the Linux kernel? I thought I understood (at least in principle) how the hand-off between then worked, but clearly I’m missing something. > >> 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. > > There's something about the imx6 that limits it to 3.8GB. > > >> I seem to remember that I got roughly the same number (lightly less >> than 2.0 GiB) when I booted the manufacturer supplied u-boot and >> Ubuntu kernel from the uSD-card that came with it. > > Maybe it came with a u-boot that didn't support the cubox-i4x4, as it > wasn't added until relatively recently: > > https://github.com/SolidRun/u-boot-imx6 > > Or, maybe you really did get a cubox-i4pro. Possible… I’ll have to boot it from the original µSD-card and see what version of u-boot it has. I may have time to do that this weekend. > live well, > vagrant
Re: Cubox-i 4x4 RAM [was Re: Performance of armhf boards]
On Thu, Apr 21, 2016 at 09:04:38AM -0700, Vagrant Cascadian wrote: > That's how it's worked for me, yes. > > There's something about the imx6 that limits it to 3.8GB. It is Cortex-A9 which is 32bit, and hence it needs a bit of memory range set aside for I/O, like networking and disk and PCIe and such (whatever it actually supports). You would need a Cortex A15+ (or A7) with LPAE enabled to actually support 4GB or more of ram on a system. -- Len Sorensen
Re: Cubox-i 4x4 RAM [was Re: Performance of armhf boards]
On 2016-04-21, Rick Thomas wrote: > Are you saying that the amount of RAM seen by Debian Linux is > determined by something in u-boot? Yes. > 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. There's something about the imx6 that limits it to 3.8GB. > I seem to remember that I got roughly the same number (lightly less > than 2.0 GiB) when I booted the manufacturer supplied u-boot and > Ubuntu kernel from the uSD-card that came with it. Maybe it came with a u-boot that didn't support the cubox-i4x4, as it wasn't added until relatively recently: https://github.com/SolidRun/u-boot-imx6 Or, maybe you really did get a cubox-i4pro. live well, vagrant signature.asc Description: PGP signature
Cubox-i 4x4 RAM [was Re: Performance of armhf boards]
[Ooops, the last one got away from me before it was finished!] On Apr 20, 2016, at 10:26 PM, Vagrant Cascadian wrote: > This appears to be a thread forked from a reproducible-builds > discussion. :) Yeah… sorry for hijacking the thread… Please forgive my curiosity (: > > On 2016-04-20, Rick Thomas wrote: >> On Sun, Apr 17, 2016, at 06:36 PM, Steven Chamberlain wrote: >>> I was wondering what is the performance of various armhf boards, for >>> package building. >> ... >>> cbxi4a-armhf-rb.debian.net19962365# 4x,4G; >>> Cubox-i4x4 >>> cbxi4pro0-armhf-rb.debian.net 19732743# 4x,2G; >>> CuBox-i4Pro >> ... >>> I don't know whether to believe these figures yet! >>> >>> * cbxi4a/b seem no faster than cbxi4pro0 despite twice the RAM? > >> One personal experience that may be relevant: >> >> I ordered a Cubox-i4x4 from NewEgg a few months ago. When it arrived it >> was clearly marked as a 4x4, and in the original shrink-wrap, But it >> only had 2GB of RAM. I notified NewEgg and they tested one of the other >> one's of that batch they had in stock. Surprise! It also had only 2GB >> RAM... They gave me a rebate of the difference in price between the >> i4-Pro and the 4x4 and we considered the matter closed. > > Well, you need to either use the vendor u-boot with support for more > ram, or patch mainline u-boot to use more. Haven't taken the time to > write a patch that works with all the various ram configurations, so > haven't pushed anything mainline. > > The cubox-i4x4 I am running with a one or two line patched mainline > u-boot but effectively are limited to 3.8GB, but that's still > significantly more than 2GB. > > > live well, > vagrant Let me see if I’ve got this right… Are you saying that the amount of RAM seen by Debian Linux is determined by something in u-boot? Here’s what I see on the machine in question running Debian: > rbthomas@half:~$ uname -a > Linux half 3.16.0-4-armmp #1 SMP Debian 3.16.7-ckt25-2 (2016-04-08) armv7l > GNU/Linux and > U-Boot 2014.10+dfsg1-5 (Apr 07 2015 - 22:16:43) I get > rbthomas@half:~$ cat /proc/meminfo > MemTotal:2069780 kB 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)? Very interesting! I seem to remember that I got roughly the same number (lightly less than 2.0 GiB) when I booted the manufacturer supplied u-boot and Ubuntu kernel from the uSD-card that came with it. Enjoy! Rick
