[U-Boot] [linux-sunxi] [UBOOT] Both Linux-Sunxi and Mainline Uboot have issues

[U-Boot] [linux-sunxi] [UBOOT] Both Linux-Sunxi and Mainline Uboot have issues

[Hans de Goede]

Hi,

On 19-02-15 07:29, TsvetanUsunov wrote:
> Hi
>
> For A13-OLinuxino till now we conservatively used the Linux-Sunxi uboot,
> but we recently got new lot of Samsung memories and we decided to tweak
> some parameters for this DDR in Linux-Sunxi uboot and found problems.
> As this uboot is with status not maintained anymore I will not discuss the
> problems, as probably no one will spend time on it, so we wisely decided to
> move to mainline uboot :) but it seems there are other issues to address.

First of all let me say that it is a good decision to move to upstream u-boot,
as one of the upstream u-boot Allwinner support maintainers I believe that
that is a very good decision.

In case you've not noticed yet upstream u-boot will give you a console on
hdmi (or lcd if configured in the configs/A*-OLinuxIno*_defconfig file)
and supports usb keyboards, so you can interact with u-boot without needing
to hook up a serial console, and it supports booting from sata disks, and ...
lets just say it is much better :)

> The PLL5 and PLL6 values are changed and this cause problems, this is what
> we found so far:
>
>
> 1. mainline u-boot
> =================
> 1.1 pll5
> address 0x01c20020, value 0xb1049091 - P=1, N=16, K=2, M=2.
>   The PLL5 output for DDR = (24MHz*N*K)/M. DDR=24*16*2/2 = 384MHz
> The PLL5 output for other module = (24MHz*N*K)/P. DDR=24*16*2/1 = 768MHz  -
> This high frequency cause LCDs connected to the board to flicker

pll5's clock was doubled in upstream u-boot to give downstream users
more flexibility in which clocks they can get by dividing it.

Unfortunately the allwinner derived linux-sunxi kernels have some hardcoded
assumptions about pll5 speed left and right, so you must make sure that
your kernel has these 2 commits:

https://github.com/linux-sunxi/linux-sunxi/commit/9a1cd034181af628d4145202289e1993c1687db6
https://github.com/linux-sunxi/linux-sunxi/commit/ade08aa6e5249a9e75a97393e86c250b2bcb3ec8

Alternatively you can enable the old kernel compat option in u-boot's config, so
you would do the following:

make -j4 CROSS_COMPILE=arm-linux-gnu- A13-OLinuXino_defconfig
make -j4 CROSS_COMPILE=arm-linux-gnu- menuconfig
  -> goto "ARM architecture" -> select "Enable workarounds for booting old kernels"
  -> exit -> exit -> save
make -j4 CROSS_COMPILE=arm-linux-gnu- spl/menuconfig
  Do the same as for the normal menuconfig

This will remove the doubling of the PLL5 speed.

Note assuming you're using linux-sunxi kernels and not upstream kernels you also
need "Enable workarounds for booting old kernels" for things to boot at all
on A20 based devices, because the new u-boot by default boots the kernel in
non secure mode (so that it can be a hypervisor and hw accelerated qemu-kvm works
on the A20), but the old kernels do not work when booted in non secure mode
(another bug in the old kernels, for which no fix is available).

> 1.2 pll6
> address 0x01c20028, value 0xA1009900 - N=25, K=1, M=1
>   The PLL6 output is (24MHz*N*K)/M/2 = 24*25*1/1/2 = 300MHz

Actually with upstream u-boot the value is 0xA1009911, but the end
result is the same: 24*25*2/2/2 = 300MHz

> 1.3 MBUS clock
> address 0x01c2015c, value 0x81000001  - MBUS clock source is PLL6/2 = 300/2
> = 150MHz - This is connected to PLL6 setup, at this 150 Mhz the board cant
> play video smoothly and sometimes drop video packets when the video is
> playing

Hmm, interesting so it seems that PLL6 is different on the A13 compared to
the A10/A20 and both upstream u-boot and the kernel get this wrong, and
miss the extra /2 which is being done on the A13 only, causing this.

I'll work on a fix for this and get back to you.

Regards,

Hans



>   2. sunxi u-boot
> =================
> 1.1 pll5
> address 0x01c20020, value 0xb1049091 - P=2, N=17, K=2, M=2.
>   The PLL5 output for DDR = (24MHz*N*K)/M. DDR=24*17*2/2 = 408MHz
> The PLL5 output for other module = (24MHz*N*K)/P. DDR=24*16*2/2 = 408MHz  -
> this frequency was OK, There is no problem with LCD flickering, why the
> frequency increase was necessary?
> 1.2 pll6
> address 0x01c20028, value 0xA1009900 - N=25, K=1, M=1
>   The PLL6 output is (24MHz*N*K)/M/2 = 24*25*1/1/2 = 300MHz
> 1.3 about MBUS clock
> address 0x01c2015c, value 0x82000001  - MBUS clock source is PLL5/2 = 408/2
> = 204MHz - at this frequency No packet drop when the video is playing
>
>
> Can you tell me the reasons for the PLL5 and PLL6 frequency changes to
> mainline uboot?
>
> Best regards
> Tsvetan
>

[U-Boot] [linux-sunxi] [UBOOT] Both Linux-Sunxi and Mainline Uboot have issues

[Ian Campbell]

On Thu, 2015-02-19 at 09:11 +0100, Hans de Goede wrote:
> Note assuming you're using linux-sunxi kernels and not upstream kernels you also
> need "Enable workarounds for booting old kernels" for things to boot at all
> on A20 based devices,

IIRC there is also an env var which can be set to force booting in
secure mode?

>  because the new u-boot by default boots the kernel in
> non secure mode (so that it can be a hypervisor and hw accelerated qemu-kvm works
> on the A20), but the old kernels do not work when booted in non secure mode
> (another bug in the old kernels, for which no fix is available).

(probably some mainline commits to head.S to handle boot in hyp mode
could be backported, ignoring the actual KVM stuff)

Ian.

[U-Boot] [linux-sunxi] [UBOOT] Both Linux-Sunxi and Mainline Uboot have issues

[Hans de Goede]

Hi,

On 19-02-15 10:22, Ian Campbell wrote:
> On Thu, 2015-02-19 at 09:11 +0100, Hans de Goede wrote:
>> Note assuming you're using linux-sunxi kernels and not upstream kernels you also
>> need "Enable workarounds for booting old kernels" for things to boot at all
>> on A20 based devices,
>
> IIRC there is also an env var which can be set to force booting in
> secure mode?

Correct, doing:

setenv bootm_boot_mode sec

Before calling "bootm" also is a way to boot old kernels on A20 devices.

>>   because the new u-boot by default boots the kernel in
>> non secure mode (so that it can be a hypervisor and hw accelerated qemu-kvm works
>> on the A20), but the old kernels do not work when booted in non secure mode
>> (another bug in the old kernels, for which no fix is available).
>
> (probably some mainline commits to head.S to handle boot in hyp mode
> could be backported, ignoring the actual KVM stuff)

IIRC someone took a quick look and this was non trivial, but yeah this would
really be the best thing to do, so that we can drop the old kernel compat
u-boot config at one point.

Regards,

Hans

[U-Boot] [linux-sunxi] [UBOOT] Both Linux-Sunxi and Mainline Uboot have issues

[Hans de Goede]

Hi,

On 19-02-15 13:38, Siarhei Siamashka wrote:
> On Wed, 18 Feb 2015 22:29:07 -0800 (PST)
> TsvetanUsunov <tsvetanusunov@gmail.com> wrote:
>
>> Hi
>>
>> For A13-OLinuxino till now we conservatively used the Linux-Sunxi uboot,
>> but we recently got new lot of Samsung memories and we decided to tweak
>> some parameters for this DDR in Linux-Sunxi uboot and found problems.
>> As this uboot is with status not maintained anymore I will not discuss the
>> problems, as probably no one will spend time on it,

<snip>

>> The PLL5 and PLL6 values are changed and this cause problems, this is what
>> we found so far:

<snip>

>> 1. mainline u-boot
>> =================
>> 1.1 pll5
>> address 0x01c20020, value 0xb1049091 - P=1, N=16, K=2, M=2.
>>   The PLL5 output for DDR = (24MHz*N*K)/M. DDR=24*16*2/2 = 384MHz
>> The PLL5 output for other module = (24MHz*N*K)/P. DDR=24*16*2/1 = 768MHz  -
>> This high frequency cause LCDs connected to the board to flicker
>
> Yes, this was already known. And had been addressed a long time ago.
> Hans has a more detailed reply, so I'm not going to duplicate it.
>
>> 1.2 pll6
>> address 0x01c20028, value 0xA1009900 - N=25, K=1, M=1

This is not the value set by u-boot, u-boot sets this to
0xA1009911

>>   The PLL6 output is (24MHz*N*K)/M/2 = 24*25*1/1/2 = 300MHz

And this formula from the A13 user manual is wrong I've run several
tests and the formula from the A10/A20 user manual, as used by the
allwinner kernel sources, upstream u-boot and upstream kernel:

PLL6 = (24MHz*N*K)/2

Is the correct one. This means that what u-boot is doing:

PLL6 = 0xA1009911, MBUS = 0x81000001

Results in PLL6 = 600 MHz , MBUS = 600 / 2 = 300 MHz so upstream
u-boot actually gives you more MBUS bandwidth to work with, as
intended.

But then the linux-sunxi-3.4 kernel comes along and sets PLL6 to:
0xA1009900 which translates to 300 MHz (in both the wrong and
correct formula) and you end up with an MBUS of only 150 MHz.



>> 1.3 MBUS clock
>> address 0x01c2015c, value 0x81000001  - MBUS clock source is PLL6/2 = 300/2
>> = 150MHz - This is connected to PLL6 setup, at this 150 Mhz the board cant
>> play video smoothly and sometimes drop video packets when the video is
>> playing
>
> Right. Having a reasonably fast MBUS clock speed is very important for
> performance.
>
>>   2. sunxi u-boot
>> =================
>> 1.1 pll5
>> address 0x01c20020, value 0xb1049091 - P=2, N=17, K=2, M=2.
>>   The PLL5 output for DDR = (24MHz*N*K)/M. DDR=24*17*2/2 = 408MHz
>> The PLL5 output for other module = (24MHz*N*K)/P. DDR=24*16*2/2 = 408MHz  -
>> this frequency was OK, There is no problem with LCD flickering, why the
>> frequency increase was necessary?
>> 1.2 pll6
>> address 0x01c20028, value 0xA1009900 - N=25, K=1, M=1
>>   The PLL6 output is (24MHz*N*K)/M/2 = 24*25*1/1/2 = 300MHz
>
> Thanks a lot for finding and reporting this particular problem.
>
> Based on a quick look, the most likely culprit seems to be the
> 'c' function in u-boot, which is providing wrong
> information to the DRAM code. But Hans is already working on a
> fix, so I'm not going to get involved yet.

Nope, the user manual for A13 is wrong (see above).

> Additionally, the sunxi-3.4 kernel is trying to re-configure PLL6 in
> 'arch/arm/mach-sun5i/clock/clock.c', which is a bit of a mess. As you
> have the problem, most likely it also ends up being 300MHz there.
> Probably the sunxi-3.4 kernel should not touch PLL6 at all and keep
> the settings from u-boot.

Oh, thanks for pointing that out, that explains why Tsvetan is seeing
0xA1009900 for the PLL6 setting, and explains his problem (see analysis
above).

I've attached a patch which should fix this, Tsvetan note that you
need to build with old kernel compatibility enabled for this fix to
work, as explained in my previous mail. Please let me know if this
fixes things then I'll push it upstream ASAP.

And someone should also write a kernel patch for the linux-sunxi kernel
to not touch pll6 on sun5i.

Regards,

Hans
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-sunxi-Fix-sun5i-mbus-speed-when-booting-old-kernels.patch
Type: text/x-patch
Size: 1273 bytes
Desc: not available
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20150219/42408bf6/attachment.bin>

[U-Boot] [linux-sunxi] [UBOOT] Both Linux-Sunxi and Mainline Uboot have issues

[Siarhei Siamashka]

On Thu, 19 Feb 2015 14:57:14 +0100
Hans de Goede <hdegoede@redhat.com> wrote:

> Hi,
> 
> On 19-02-15 13:38, Siarhei Siamashka wrote:
> > On Wed, 18 Feb 2015 22:29:07 -0800 (PST)
> > TsvetanUsunov <tsvetanusunov@gmail.com> wrote:
> >
> >> Hi
> >>
> >> For A13-OLinuxino till now we conservatively used the Linux-Sunxi uboot,
> >> but we recently got new lot of Samsung memories and we decided to tweak
> >> some parameters for this DDR in Linux-Sunxi uboot and found problems.
> >> As this uboot is with status not maintained anymore I will not discuss the
> >> problems, as probably no one will spend time on it,
> 
> <snip>
> 
> >> The PLL5 and PLL6 values are changed and this cause problems, this is what
> >> we found so far:
> 
> <snip>
> 
> >> 1. mainline u-boot
> >> =================
> >> 1.1 pll5
> >> address 0x01c20020, value 0xb1049091 - P=1, N=16, K=2, M=2.
> >>   The PLL5 output for DDR = (24MHz*N*K)/M. DDR=24*16*2/2 = 384MHz
> >> The PLL5 output for other module = (24MHz*N*K)/P. DDR=24*16*2/1 = 768MHz  -
> >> This high frequency cause LCDs connected to the board to flicker
> >
> > Yes, this was already known. And had been addressed a long time ago.
> > Hans has a more detailed reply, so I'm not going to duplicate it.
> >
> >> 1.2 pll6
> >> address 0x01c20028, value 0xA1009900 - N=25, K=1, M=1
> 
> This is not the value set by u-boot, u-boot sets this to
> 0xA1009911
> 
> >>   The PLL6 output is (24MHz*N*K)/M/2 = 24*25*1/1/2 = 300MHz
> 
> And this formula from the A13 user manual is wrong I've run several
> tests and the formula from the A10/A20 user manual, as used by the
> allwinner kernel sources, upstream u-boot and upstream kernel:
> 
> PLL6 = (24MHz*N*K)/2
> 
> Is the correct one. This means that what u-boot is doing:
> 
> PLL6 = 0xA1009911, MBUS = 0x81000001
> 
> Results in PLL6 = 600 MHz , MBUS = 600 / 2 = 300 MHz so upstream
> u-boot actually gives you more MBUS bandwidth to work with, as
> intended.
> 
> But then the linux-sunxi-3.4 kernel comes along and sets PLL6 to:
> 0xA1009900 which translates to 300 MHz (in both the wrong and
> correct formula) and you end up with an MBUS of only 150 MHz.
> 
> 
> 
> >> 1.3 MBUS clock
> >> address 0x01c2015c, value 0x81000001  - MBUS clock source is PLL6/2 = 300/2
> >> = 150MHz - This is connected to PLL6 setup, at this 150 Mhz the board cant
> >> play video smoothly and sometimes drop video packets when the video is
> >> playing
> >
> > Right. Having a reasonably fast MBUS clock speed is very important for
> > performance.
> >
> >>   2. sunxi u-boot
> >> =================
> >> 1.1 pll5
> >> address 0x01c20020, value 0xb1049091 - P=2, N=17, K=2, M=2.
> >>   The PLL5 output for DDR = (24MHz*N*K)/M. DDR=24*17*2/2 = 408MHz
> >> The PLL5 output for other module = (24MHz*N*K)/P. DDR=24*16*2/2 = 408MHz  -
> >> this frequency was OK, There is no problem with LCD flickering, why the
> >> frequency increase was necessary?
> >> 1.2 pll6
> >> address 0x01c20028, value 0xA1009900 - N=25, K=1, M=1
> >>   The PLL6 output is (24MHz*N*K)/M/2 = 24*25*1/1/2 = 300MHz
> >
> > Thanks a lot for finding and reporting this particular problem.
> >
> > Based on a quick look, the most likely culprit seems to be the
> > 'c' function in u-boot, which is providing wrong
> > information to the DRAM code. But Hans is already working on a
> > fix, so I'm not going to get involved yet.
> 
> Nope, the user manual for A13 is wrong (see above).

You are right, thanks.

I felt that something was odd, because I did run some memory benchmarks
on an A13-OLinuXino-Micro board earlier (with the mainline kernel) an
did not notice any PLL6 related anomalies at that time:

    http://linux-sunxi.org/A10_DRAM_Controller_Performance

The "300 MHz MBUS" results (MBUS is clocked from PLL6) are more or less
consistent with the others (when MBUS is clocked from PLL5P).

> > Additionally, the sunxi-3.4 kernel is trying to re-configure PLL6 in
> > 'arch/arm/mach-sun5i/clock/clock.c', which is a bit of a mess. As you
> > have the problem, most likely it also ends up being 300MHz there.
> > Probably the sunxi-3.4 kernel should not touch PLL6 at all and keep
> > the settings from u-boot.
> 
> Oh, thanks for pointing that out, that explains why Tsvetan is seeing
> 0xA1009900 for the PLL6 setting, and explains his problem (see analysis
> above).
> 
> I've attached a patch which should fix this, Tsvetan note that you
> need to build with old kernel compatibility enabled for this fix to
> work, as explained in my previous mail. Please let me know if this
> fixes things then I'll push it upstream ASAP.
> 
> And someone should also write a kernel patch for the linux-sunxi kernel
> to not touch pll6 on sun5i.

I have looked at it a bit. And now I don't feel like touching anything
PLL6 related in the sunxi-3.4 kernel. The A20 and A13 manuals contain
some rather confusing information about PLL6 (all these PLL6, PLL6*2,
PLL6/2, the M divisor, etc.). The sunxi-3.4 kernel sources are rather
convoluted too.

So I'm not quite sure whether changing PLL6 from 300MHz to 600MHz (by
keeping the default PLL6 settings from u-boot) in the sun5i build of the
sunxi-3.4 kernel is really free from any regressions. We might upset
Tsvetan again :)

-- 
Best regards,
Siarhei Siamashka

[U-Boot] [linux-sunxi] [UBOOT] Both Linux-Sunxi and Mainline Uboot have issues

[Siarhei Siamashka]

Hi Tsvetan,

On Thu, 19 Feb 2015 14:38:58 +0200
Siarhei Siamashka <siarhei.siamashka@gmail.com> wrote:

> On Wed, 18 Feb 2015 22:29:07 -0800 (PST)
> TsvetanUsunov <tsvetanusunov@gmail.com> wrote:
> 
> > Hi
> > 
> > For A13-OLinuxino till now we conservatively used the Linux-Sunxi uboot, 
> > but we recently got new lot of Samsung memories and we decided to tweak 
> > some parameters for this DDR in Linux-Sunxi uboot and found problems. 
> > As this uboot is with status not maintained anymore I will not discuss the 
> > problems, as probably no one will spend time on it,
> 
> This is actually very much interesting. What kind of problems you
> got after the change of DDR3 chips? My (probably somewhat limited)
> understanding is that all DDR3 chips have to support standard timings
> according to the JEDEC specs. There are several standard speed bins,
> so the faster chips just are tested for compatibility with a faster
> speed bin and labelled as such.
> 
> BUT
> 
> The "magic" Allwinner settings in u-boot make the DDR3 chips
> configuration violate the spec:
> 
>     http://lists.denx.de/pipermail/u-boot/2015-January/201787.html
> 
> So I would not be very surprised if some of the chips can tolerate
> these settings and the others can't.
> 
> If you can confirm that this is indeed the problem, then we might try
> to drop the problematic magic settings sooner. You can find a
> collection of DDR3 timing parameters for different clock speeds
> and JEDEC speed bins at:
> 
>    http://git.denx.de/?p=u-boot.git;a=blob;f=board/sunxi/dram_timings_sun4i.h;h=29b934da639c86b1830d1e26b7a751b6b227a21a;hb=HEAD
> 
> The hardware documentation about the timing parameters is in the
> linux-sunxi wiki (no official documentation exists, but we took some
> efforts to collect the information about similar DRAM controllers
> used in Rockchip/TI SoCs from the Internet and verify that they
> actually apply to our hardware, mostly using the "trial and error"
> method of black box testing):
> 
>    http://linux-sunxi.org/A10_DRAM_Controller_Register_Guide#SDR_TPR0
>    http://linux-sunxi.org/A10_DRAM_Controller_Register_Guide#SDR_TPR1
>    http://linux-sunxi.org/A10_DRAM_Controller_Register_Guide#SDR_TPR2
> 
> Additionally, by tweaking the impedance matching configuration (using a
> brute force search and some heuristics), we can reach much higher DRAM
> clock speeds on various hardware. Some information about this is here:
> 
>    http://linux-sunxi.org/A10_DRAM_Controller_Calibration
> 
> I know that Olimex has opted to just change the RZQ resistors nominal
> away from the standard 240 Ohm in different board revisions instead of
> tweaking the impedance via software. This introduces a practical problem
> for us on Olimex boards, which employ these tricks.
> 
> It would be great if we could have a better cooperation with Olimex
> and maybe improve the DRAM configuration on Olimex boards to get
> better reliability and performance. Basically, we need to run certain
> tests on a statistically significant number of boards, preferably from
> different batches. I can help and answer questions. But most of the
> information is already available in the linux-sunxi wiki.
> 
> > so we wisely decided to 
> > move to mainline uboot :) but it seems there are other issues to address.
> 
> That's a good choice :)
> 
> BTW, the blog post
> 
>     https://olimex.wordpress.com/2014/10/27/a20-olinuxino-lime2-review-and-updates/
> 
> says that "Much better routing of DDR3 memory. We increased the number
> of layers to 8 vs the 6 layers in LIME, we put the DDR3 memory closer
> to the A20, we layout the tracks shorter, as result now LIME2 runs with
> DDR3 on 532Mhz on LIME there were problems to run DDR3 at more than
> 400Mhz"
> 
> I'm very happy about the improved DRAM clock speed in LIME2. But if I
> understand this correctly, the old LIME is not expected to be reliable
> with the DRAM clocked higher than 400MHz? Are you now going to
> contribute updates for
> 
>     http://git.denx.de/?p=u-boot.git;a=blob;f=configs/A10-OLinuXino-Lime_defconfig;h=8fa1a330cd34e1a8202892595c549971b3275169;hb=HEAD
>     http://git.denx.de/?p=u-boot.git;a=blob;f=configs/A20-OLinuXino-Lime_defconfig;h=5442f645f87165c34bbed8ba3e6cde3d8a8b87e8;hb=HEAD
> 
> to pick a more reasonable DRAM clock speed? Or do you see no
> problems having it configured as 480MHz in the mainline u-boot
> for A10-OLinuXino-Lime and A20-OLinuXino-Lime?

This is just a reminder to say that I'm still very much interested to
get a reply. You seem to be assuming that nobody here (and in the
upstream U-Boot) is interested in the DRAM settings used on Olimex
boards, but this is not quite true.

The wiki page at https://www.olimex.com/wiki/A13-OLinuXino now says:

    "Please note that you might need different Debian Linux images for
     different boards with different hardware - you would need to
     inspect the DDR3 RAM memory and use the image suitable for your
     board. Previously we used HYNIX H5TQ2G83CFR, now we use SAMSUNG
     K4B2G0846Q.

     Newest official Debian release (recommended):

     Torrent of Debian release 11.2 suitable for boards with SAMSUNG
     K4B2G0846Q DDR3 RAM memory: A13 Debian Linux with kernel 3.4.90+,
     suitable for boards with SAMSUNG DDR3 RAM

     Torrent of Debian release 10 suitable for boards with HYNIX
     H5TQ2G83CFR DDR3 RAM memory: A13 Debian Linux with kernel 3.4.90+,
     suitable for HYNIX DDR3 RAM".

So Olimex is using different DRAM settings for the A13-OLinuXino board,
depending on the DRAM chip type. And providing binary images to the end
users.

SAMSUNG K4B2G0846Q is quite interesting, because it is a family of DDR3
chips supporting speeds ranging from DDR3-1600 to DDR3-2133. And they
are only officially backwards compatible with DDR3-1600, but not with
anything lower. And we are mostly interested in DDR3-1066 timings.
DDR3-1600 specifies 13.75 ns timings for tRCD/tRP, while DDR3-1066F
speed bin specifies 13.125 ns. These newer SAMSUNG chips support higher
clock frequencies, but have *worse* access latency. I would not be
very surprised if this is exactly the source of the reliability
problems. So it probably makes sense to use the DDR3-1066G speed bin
timings (15 ns) for these chips. This can be done by adding the
following line to the A13-OLinuXino defconfig file in U-Boot:

    +S:CONFIG_DRAM_TIMINGS_DDR3_800E_1066G_1333J=y

Additionally, I did a bit of detective work earlier and "interrogated"
a user named <TJvV> in the #olimex irc channel:

    https://www.olimex.com/irc?date=2015-02-24

Appears that these binary images, supplied by Olimex, are indeed using
non-default DRAM settings. And an additional observation is that the
DCDC3 voltage is set to only 1.2V on this board (down from the default
1.25V configured by U-Boot). The reduced DCDC3 voltage may be
responsible for poor reliability at high MBUS and DRAM clock speeds
too.

To sum it up. It would be great if Olimex better cooperated with the
upstream U-Boot and provided the DRAM settings for Olimex boards
instead of diverging from the defaults in the custom binary images.
IANAL, but some people may even treat the custom DRAM settings tweaks
as a sort of GPL violation, unless Olimex provides U-Boot sources
somewhere nearby.

-- 
Best regards,
Siarhei Siamashka