Re: Cubox-i 4x4 RAM [was Re: Performance of armhf boards]

[Rick Thomas]

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]

[Rick Thomas]

> 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]

[Uwe Kleine-König]

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]

[Rick Thomas]

> 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]

[Vagrant Cascadian]

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]

[Gaudenz Steinlin]

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]

[Rick Thomas]

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]

[Rick Thomas]

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]

[Vagrant Cascadian]

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]

[Uwe Kleine-König]

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]

[Rick Thomas]

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]

[Rick Thomas]

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]

[Lennart Sorensen]

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]

[Vagrant Cascadian]

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]

[Rick Thomas]

[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

Cubox-i4x4 - [was Re: Performance of armhf boards]

[Rick Thomas]

On Apr 20, 2016, at 10:26 PM, Vagrant Cascadian  wrote:

> This appears to be a thread forked from a reproducible-builds
> discussion. :)
> 
> 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

Re: Performance of armhf boards

[Lennart Sorensen]

On Wed, Apr 20, 2016 at 05:17:02PM -0700, Rick Thomas wrote:
> 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.
> 
> But it might be worth checking, anyway.
> 
> Also, as for the (lack of) difference between USB2 and USB3 disks, the
> Cubox boards all have Gbit Ethernet ports, but they are limited to
> 480Mbit actual throughput rate.  I assume this is because the SoC
> handles everything thru a USB2 driver circuit, though I'm not privy to
> any actual design information.  You may be seeing a similar thing here.

Well errata entry ERR004512 of
http://cache.freescale.com/files/32bit/doc/errata/IMX6DQCE.pdf?fpsp=1_TYPE=Errata_VENDOR=FREESCALE_FILE_FORMAT=pdf_ASSET=Documentation
seems to say that's the limit for ethernet throughput on the imx6 and
it isn't going to change.  Doesn't say why that is the limit.

-- 
Len Sorensen

Re: Performance of armhf boards

[Rick Thomas]

On Sun, Apr 17, 2016, at 06:36 PM, Steven Chamberlain wrote:
> Hi!
> 
> 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?
>   * ff2a/b show USB3 SSD to be no faster than USB2?
... 
> Corrections/suggestions are welcome.

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.

But it might be worth checking, anyway.

Also, as for the (lack of) difference between USB2 and USB3 disks, the
Cubox boards all have Gbit Ethernet ports, but they are limited to
480Mbit actual throughput rate.  I assume this is because the SoC
handles everything thru a USB2 driver circuit, though I'm not privy to
any actual design information.  You may be seeing a similar thing here.

Just my two cents.
Rick