[U-Boot] U-Boot Sunxi breaks LCD output on Olimex Lime A10

[U-Boot] U-Boot Sunxi breaks LCD output on Olimex Lime A10

[Hendrik]

I have always been using the sunxi u-boot from 
'https://github.com/linux-sunxi/u-boot-sunxi' and that works fine, but 
now I want to boot the kernel from USB. That is not possible in that 
u-boot branch. Therefore I switched to the latest U-Boot 
'git://git.denx.de/u-boot.git' for the Olimex Allwinner A10 Lime as this 
one does have a working USB mass storage implementation.

But when the kernel and root filesystem is booted and my application 
(using DirectFB) starts, the LCD screen is flickering between a correct 
image and an incorrect image as if sometimes random image data is 
displayed to the screen. Although it looks more like a clock or timing 
issue because the colors of the faulty screen resemble the colors of the 
correct screen. Also: when the cpu is inactive the screen is more or 
less ok but when doing a lot of work the screen starts to flicker. Then 
it is stable for a while and after some time it starts flickering again.

I am using the exact same kernel, root filesystem, U-boot environment, 
SD-card and 'script.bin' (which defines the hardware layout, I am not 
using a device tree file). The only difference is the version (and 
origin) of U-boot.

Can anybody shine some light on this? Maybe Hans de Goede? I have seen 
his name pop-up a lot of times with the Sunxi branch.

Regards,
Hendrik

[U-Boot] U-Boot Sunxi breaks LCD output on Olimex Lime A10

[Hans de Goede]

Hi,

On 10/01/2014 07:43 PM, Hendrik wrote:
> I have always been using the sunxi u-boot from 'https://github.com/linux-sunxi/u-boot-sunxi' and that works fine, but now I want to boot the kernel from USB. That is not possible in that u-boot branch. Therefore I switched to the latest U-Boot 'git://git.denx.de/u-boot.git' for the Olimex Allwinner A10 Lime as this one does have a working USB mass storage implementation.
> 
> But when the kernel and root filesystem is booted and my application (using DirectFB) starts, the LCD screen is flickering between a correct image and an incorrect image as if sometimes random image data is displayed to the screen. Although it looks more like a clock or timing issue because the colors of the faulty screen resemble the colors of the correct screen. Also: when the cpu is inactive the screen is more or less ok but when doing a lot of work the screen starts to flicker. Then it is stable for a while and after some time it starts flickering again.
> 
> I am using the exact same kernel, root filesystem, U-boot environment, SD-card and 'script.bin' (which defines the hardware layout, I am not using a device tree file). The only difference is the version (and origin) of U-boot.
> 
> Can anybody shine some light on this? Maybe Hans de Goede? I have seen his name pop-up a lot of times with the Sunxi branch.

Hmm, the only thing I can think of which may have caused this are the
recent DRAM controller code cleanups which are in upstream u-boot and
not in https://github.com/linux-sunxi/u-boot-sunxi

Can you try copying these 2 files:

arch/arm/cpu/armv7/sunxi/dram.c
arch/arm/include/asm/arch-sunxi/dram.h

From https://github.com/linux-sunxi/u-boot-sunxi over into upstream
u-boot, essentially reverting the DRAM cleanup patches, and see if that
fixes things ?

Regards,

Hans

[U-Boot] U-Boot Sunxi breaks LCD output on Olimex Lime A10

[Siarhei Siamashka]

On Fri, 03 Oct 2014 10:04:29 +0200
Hans de Goede <hdegoede@redhat.com> wrote:

> Hi,
> 
> On 10/01/2014 07:43 PM, Hendrik wrote:
> > I have always been using the sunxi u-boot from 'https://github.com/linux-sunxi/u-boot-sunxi' and that works fine, but now I want to boot the kernel from USB. That is not possible in that u-boot branch. Therefore I switched to the latest U-Boot 'git://git.denx.de/u-boot.git' for the Olimex Allwinner A10 Lime as this one does have a working USB mass storage implementation.
> > 
> > But when the kernel and root filesystem is booted and my application (using DirectFB) starts, the LCD screen is flickering between a correct image and an incorrect image as if sometimes random image data is displayed to the screen. Although it looks more like a clock or timing issue because the colors of the faulty screen resemble the colors of the correct screen. Also: when the cpu is inactive the screen is more or less ok but when doing a lot of work the screen starts to flicker. Then it is stable for a while and after some time it starts flickering again.
> > 
> > I am using the exact same kernel, root filesystem, U-boot environment, SD-card and 'script.bin' (which defines the hardware layout, I am not using a device tree file). The only difference is the version (and origin) of U-boot.
> > 
> > Can anybody shine some light on this? Maybe Hans de Goede? I have seen his name pop-up a lot of times with the Sunxi branch.
> 
> Hmm, the only thing I can think of which may have caused this are the
> recent DRAM controller code cleanups which are in upstream u-boot and
> not in https://github.com/linux-sunxi/u-boot-sunxi
> 
> Can you try copying these 2 files:
> 
> arch/arm/cpu/armv7/sunxi/dram.c
> arch/arm/include/asm/arch-sunxi/dram.h
> 
> From https://github.com/linux-sunxi/u-boot-sunxi over into upstream
> u-boot, essentially reverting the DRAM cleanup patches, and see if that
> fixes things ?

It is most definitely the PLL5P clock speed problem and it can be
resolved by either reverting the following patch in u-boot
    http://git.denx.de/?p=u-boot.git;a=commit;h=013f2d746955147439215a4939655c9ed6bdd866
or by fixing a bunch of hardcoded divisors in the sunxi-3.4
kernel (for which I'll send a patch to the linux-sunxi mailing list
later today).

Please note that you can't use the sunxi-3.4 kernel with the unmodified
mainline u-boot anyway because of the missing machine id definitions and
the new PSCI code (but this is a problem only on Allwinner A20
hardware). A few minor patches are needed here and there.

A feature complete u-boot branch with extra patches on top of u-boot
v2014.10 (for example, with HDMI video driver support) and the
sunxi-3.4 kernel compatibility tweaks is going to be available shortly
after the u-boot v2014.10 release.

-- 
Best regards,
Siarhei Siamashka

[U-Boot] U-Boot Sunxi breaks LCD output on Olimex Lime A10

[Hans de Goede]

Hi,

On 10/03/2014 10:49 AM, Siarhei Siamashka wrote:
> On Fri, 03 Oct 2014 10:04:29 +0200
> Hans de Goede <hdegoede@redhat.com> wrote:
> 
>> Hi,
>>
>> On 10/01/2014 07:43 PM, Hendrik wrote:
>>> I have always been using the sunxi u-boot from 'https://github.com/linux-sunxi/u-boot-sunxi' and that works fine, but now I want to boot the kernel from USB. That is not possible in that u-boot branch. Therefore I switched to the latest U-Boot 'git://git.denx.de/u-boot.git' for the Olimex Allwinner A10 Lime as this one does have a working USB mass storage implementation.
>>>
>>> But when the kernel and root filesystem is booted and my application (using DirectFB) starts, the LCD screen is flickering between a correct image and an incorrect image as if sometimes random image data is displayed to the screen. Although it looks more like a clock or timing issue because the colors of the faulty screen resemble the colors of the correct screen. Also: when the cpu is inactive the screen is more or less ok but when doing a lot of work the screen starts to flicker. Then it is stable for a while and after some time it starts flickering again.
>>>
>>> I am using the exact same kernel, root filesystem, U-boot environment, SD-card and 'script.bin' (which defines the hardware layout, I am not using a device tree file). The only difference is the version (and origin) of U-boot.
>>>
>>> Can anybody shine some light on this? Maybe Hans de Goede? I have seen his name pop-up a lot of times with the Sunxi branch.
>>
>> Hmm, the only thing I can think of which may have caused this are the
>> recent DRAM controller code cleanups which are in upstream u-boot and
>> not in https://github.com/linux-sunxi/u-boot-sunxi
>>
>> Can you try copying these 2 files:
>>
>> arch/arm/cpu/armv7/sunxi/dram.c
>> arch/arm/include/asm/arch-sunxi/dram.h
>>
>> From https://github.com/linux-sunxi/u-boot-sunxi over into upstream
>> u-boot, essentially reverting the DRAM cleanup patches, and see if that
>> fixes things ?
> 
> It is most definitely the PLL5P clock speed problem and it can be
> resolved by either reverting the following patch in u-boot
>     http://git.denx.de/?p=u-boot.git;a=commit;h=013f2d746955147439215a4939655c9ed6bdd866
> or by fixing a bunch of hardcoded divisors in the sunxi-3.4
> kernel (for which I'll send a patch to the linux-sunxi mailing list
> later today).

Thanks, that is good to know. I'm tempted to revert that patch then for
now. I say tempted, as I'm not 100% sure on this. I do want mainline
u-boot to work eventually with the sunxi-3.4, so that we can stop
maintaining https://github.com/linux-sunxi/u-boot-sunxi

But this will requires some sunxi-3.4 kernel changes for A20 anyways,
so if you've a sunxi-3.4 patch fixing things, then maybe

> Please note that you can't use the sunxi-3.4 kernel with the unmodified
> mainline u-boot anyway because of the missing machine id definitions and
> the new PSCI code (but this is a problem only on Allwinner A20
> hardware). A few minor patches are needed here and there.

Right, I plan to fix the missing machine ids ASAP, we did not add them
because we thought they were not properly registered, but I've checked
and they actually are properly registered. I welcome a patch adding them,
and unless someone beats me to it I hope to write one myself real soon.

With the machine ids added upstream u-boot will work fine for sun4i and
sun5i with existing sunxi-3.4 kernels, which is why I'm tempted to
revert the commit you mention above if that breaks that (in some scenarios).

> A feature complete u-boot branch with extra patches on top of u-boot
> v2014.10 (for example, with HDMI video driver support) 

Hmm, I assume that you're working on this and are going to maintain this?

So this is going to be some patches on top of v2014.10, or do you plan to
merge v2014.10 and https://github.com/linux-sunxi/u-boot-sunxi ?

If this is going to be some patches on top of v2014.10, please consider
pushing for getting these merged. I'm definitely interested in getting
upstream u-boot to work with the sunxi-3.4 kernels, and I say this with my
sunxi u-boot custodian hat firmly on.

As for the hdmi support, please note that I maintain a branch with that,
(*) which includes several fixes here:

https://github.com/jwrdegoede/u-boot-sunxi/commits/sunxi-wip

And I plan to get this merged into u-boot master post the v2014.10 release,
the big blocker is the simplefb clocks binding thingie, and I hope that
that will be resolved soon.

Regards,

Hans


*) other pending stuff I'm working on

[U-Boot] U-Boot Sunxi breaks LCD output on Olimex Lime A10

[Hendrik]

Hi,

Thanks for letting me know all this. I wasn't aware that there are some 
troubles using the sunxi-linux branch with the mainline u-boot. 
Unfortunately there are many sources of information on the sunxi boards 
and how to get things up and running but there is only limited 
information about running mainline stuff.

I will try to overwrite the dram settings and see if that changes anything.

I did not mention in my first e-mail that I also used the 'machid' 
setting in the new u-boot that points to sun4i (because in the mainline 
version it didn't detect my Olinuxino and told me to specify the correct 
machid), could that also be the cause of troubles because it does not 
really match the exact board (I did use the 'defconfig' for the A10-Lime).

And another thing; I tried a couple of the latest 3.15 mainline kernels 
a couple of weeks ago with sunxi-uboot to create a home-server with the 
Olinuxino Line A10. I combined this with the BTRFS filesystem (2 USB 
sticks in mirror), but that filesystem created corruption out of the 
blue over and over again. I tried multiple USB sticks and SD cards but 
maybe there are some other discrepancies between the mainline and sunxi 
sources that could cause this? That was the opposite of what I am doing 
now (so sunxi-uboot with mainline kernel instead of now mainline sunxi 
with sunxi-kernel)

Regards,
Hendrik

On 03-10-14 11:19, Hans de Goede wrote:
> Hi,
>
> On 10/03/2014 10:49 AM, Siarhei Siamashka wrote:
>> On Fri, 03 Oct 2014 10:04:29 +0200
>> Hans de Goede <hdegoede@redhat.com> wrote:
>>
>>> Hi,
>>>
>>> On 10/01/2014 07:43 PM, Hendrik wrote:
>>>> I have always been using the sunxi u-boot from 'https://github.com/linux-sunxi/u-boot-sunxi' and that works fine, but now I want to boot the kernel from USB. That is not possible in that u-boot branch. Therefore I switched to the latest U-Boot 'git://git.denx.de/u-boot.git' for the Olimex Allwinner A10 Lime as this one does have a working USB mass storage implementation.
>>>>
>>>> But when the kernel and root filesystem is booted and my application (using DirectFB) starts, the LCD screen is flickering between a correct image and an incorrect image as if sometimes random image data is displayed to the screen. Although it looks more like a clock or timing issue because the colors of the faulty screen resemble the colors of the correct screen. Also: when the cpu is inactive the screen is more or less ok but when doing a lot of work the screen starts to flicker. Then it is stable for a while and after some time it starts flickering again.
>>>>
>>>> I am using the exact same kernel, root filesystem, U-boot environment, SD-card and 'script.bin' (which defines the hardware layout, I am not using a device tree file). The only difference is the version (and origin) of U-boot.
>>>>
>>>> Can anybody shine some light on this? Maybe Hans de Goede? I have seen his name pop-up a lot of times with the Sunxi branch.
>>> Hmm, the only thing I can think of which may have caused this are the
>>> recent DRAM controller code cleanups which are in upstream u-boot and
>>> not in https://github.com/linux-sunxi/u-boot-sunxi
>>>
>>> Can you try copying these 2 files:
>>>
>>> arch/arm/cpu/armv7/sunxi/dram.c
>>> arch/arm/include/asm/arch-sunxi/dram.h
>>>
>>>  From https://github.com/linux-sunxi/u-boot-sunxi over into upstream
>>> u-boot, essentially reverting the DRAM cleanup patches, and see if that
>>> fixes things ?
>> It is most definitely the PLL5P clock speed problem and it can be
>> resolved by either reverting the following patch in u-boot
>>      http://git.denx.de/?p=u-boot.git;a=commit;h=013f2d746955147439215a4939655c9ed6bdd866
>> or by fixing a bunch of hardcoded divisors in the sunxi-3.4
>> kernel (for which I'll send a patch to the linux-sunxi mailing list
>> later today).
> Thanks, that is good to know. I'm tempted to revert that patch then for
> now. I say tempted, as I'm not 100% sure on this. I do want mainline
> u-boot to work eventually with the sunxi-3.4, so that we can stop
> maintaining https://github.com/linux-sunxi/u-boot-sunxi
>
> But this will requires some sunxi-3.4 kernel changes for A20 anyways,
> so if you've a sunxi-3.4 patch fixing things, then maybe
>
>> Please note that you can't use the sunxi-3.4 kernel with the unmodified
>> mainline u-boot anyway because of the missing machine id definitions and
>> the new PSCI code (but this is a problem only on Allwinner A20
>> hardware). A few minor patches are needed here and there.
> Right, I plan to fix the missing machine ids ASAP, we did not add them
> because we thought they were not properly registered, but I've checked
> and they actually are properly registered. I welcome a patch adding them,
> and unless someone beats me to it I hope to write one myself real soon.
>
> With the machine ids added upstream u-boot will work fine for sun4i and
> sun5i with existing sunxi-3.4 kernels, which is why I'm tempted to
> revert the commit you mention above if that breaks that (in some scenarios).
>
>> A feature complete u-boot branch with extra patches on top of u-boot
>> v2014.10 (for example, with HDMI video driver support)
> Hmm, I assume that you're working on this and are going to maintain this?
>
> So this is going to be some patches on top of v2014.10, or do you plan to
> merge v2014.10 and https://github.com/linux-sunxi/u-boot-sunxi ?
>
> If this is going to be some patches on top of v2014.10, please consider
> pushing for getting these merged. I'm definitely interested in getting
> upstream u-boot to work with the sunxi-3.4 kernels, and I say this with my
> sunxi u-boot custodian hat firmly on.
>
> As for the hdmi support, please note that I maintain a branch with that,
> (*) which includes several fixes here:
>
> https://github.com/jwrdegoede/u-boot-sunxi/commits/sunxi-wip
>
> And I plan to get this merged into u-boot master post the v2014.10 release,
> the big blocker is the simplefb clocks binding thingie, and I hope that
> that will be resolved soon.
>
> Regards,
>
> Hans
>
>
> *) other pending stuff I'm working on

[U-Boot] U-Boot Sunxi breaks LCD output on Olimex Lime A10

[Hendrik]

Hi,

I now tried to get the latest version from 
git://git.denx.de/u-boot-sunxi.git and then replaced the dram.c/h files 
with the ones from https://github.com/linux-sunxi/u-boot-sunxi.

That seems to work. The LCD screen no longer flickers!

Regards,
Hendrik

[U-Boot] U-Boot Sunxi breaks LCD output on Olimex Lime A10

[Siarhei Siamashka]

On Fri, 03 Oct 2014 11:19:47 +0200
Hans de Goede <hdegoede@redhat.com> wrote:

> Hi,
> 
> On 10/03/2014 10:49 AM, Siarhei Siamashka wrote:
> > On Fri, 03 Oct 2014 10:04:29 +0200
> > Hans de Goede <hdegoede@redhat.com> wrote:
> > 
> >> Hi,
> >>
> >> On 10/01/2014 07:43 PM, Hendrik wrote:
> >>> I have always been using the sunxi u-boot from 'https://github.com/linux-sunxi/u-boot-sunxi' and that works fine, but now I want to boot the kernel from USB. That is not possible in that u-boot branch. Therefore I switched to the latest U-Boot 'git://git.denx.de/u-boot.git' for the Olimex Allwinner A10 Lime as this one does have a working USB mass storage implementation.
> >>>
> >>> But when the kernel and root filesystem is booted and my application (using DirectFB) starts, the LCD screen is flickering between a correct image and an incorrect image as if sometimes random image data is displayed to the screen. Although it looks more like a clock or timing issue because the colors of the faulty screen resemble the colors of the correct screen. Also: when the cpu is inactive the screen is more or less ok but when doing a lot of work the screen starts to flicker. Then it is stable for a while and after some time it starts flickering again.
> >>>
> >>> I am using the exact same kernel, root filesystem, U-boot environment, SD-card and 'script.bin' (which defines the hardware layout, I am not using a device tree file). The only difference is the version (and origin) of U-boot.
> >>>
> >>> Can anybody shine some light on this? Maybe Hans de Goede? I have seen his name pop-up a lot of times with the Sunxi branch.
> >>
> >> Hmm, the only thing I can think of which may have caused this are the
> >> recent DRAM controller code cleanups which are in upstream u-boot and
> >> not in https://github.com/linux-sunxi/u-boot-sunxi
> >>
> >> Can you try copying these 2 files:
> >>
> >> arch/arm/cpu/armv7/sunxi/dram.c
> >> arch/arm/include/asm/arch-sunxi/dram.h
> >>
> >> From https://github.com/linux-sunxi/u-boot-sunxi over into upstream
> >> u-boot, essentially reverting the DRAM cleanup patches, and see if that
> >> fixes things ?
> > 
> > It is most definitely the PLL5P clock speed problem and it can be
> > resolved by either reverting the following patch in u-boot
> >     http://git.denx.de/?p=u-boot.git;a=commit;h=013f2d746955147439215a4939655c9ed6bdd866
> > or by fixing a bunch of hardcoded divisors in the sunxi-3.4
> > kernel (for which I'll send a patch to the linux-sunxi mailing list
> > later today).
> 
> Thanks, that is good to know. I'm tempted to revert that patch then for
> now. I say tempted, as I'm not 100% sure on this. I do want mainline
> u-boot to work eventually with the sunxi-3.4, so that we can stop
> maintaining https://github.com/linux-sunxi/u-boot-sunxi

There is no real need to maintain u-boot in this repository since a
long time ago.

Just please don't fix something that is not broken. And also don't
break it unnecessarily by pushing there some unreviewed submarine
patches and doing reckless merges.

> But this will requires some sunxi-3.4 kernel changes for A20 anyways,
> so if you've a sunxi-3.4 patch fixing things, then maybe
> 
> > Please note that you can't use the sunxi-3.4 kernel with the unmodified
> > mainline u-boot anyway because of the missing machine id definitions and
> > the new PSCI code (but this is a problem only on Allwinner A20
> > hardware). A few minor patches are needed here and there.
> 
> Right, I plan to fix the missing machine ids ASAP, we did not add them
> because we thought they were not properly registered, but I've checked
> and they actually are properly registered. I welcome a patch adding them,
> and unless someone beats me to it I hope to write one myself real soon.
> 
> With the machine ids added upstream u-boot will work fine for sun4i and
> sun5i with existing sunxi-3.4 kernels, which is why I'm tempted to
> revert the commit you mention above if that breaks that (in some scenarios).

The (missing) machine id acts as a safety guard and prevents loading
incompatible kernel. But as soon as you add the machine id, the
users will assume that any old kernel is supposed to be supported the
u-boot will effectively have to be compatible with old bugs.

This is not a very nice situation, but there are a few possible
scenarios:

1) A bureaucratic way. Try to register a new set of machine identifiers,
something like "sun4i_v2", "sun5i_v2", "sun7i_v2". Then patch the
sunxi-3.4 kernel to support both old and new machine identifiers, so
that both old u-boot-sunxi and the mainline u-boot can be used with the
updated kernels. But the old kernels will refuse to load from the
mainline u-boot. There is already a garbage (?) entry in the machine id
database, a few more would not hurt too much:
    3931 AllWinner A1x Developer Board lichee_sun4i_devbd

2) A hackish way. Similar to 1), but don't register anything. Just treat
a few high bits of the machine id as some kind of a version number. So
the current machine ids have version "0", the next set can have version
"1" and so on. The sunxi-3.4 kernel can be patched to fix bugs and the
supported "version" can be increased. Because real machine id numbers
are assigned sequentially, no clash is likely.

3) Just do the revert of the PLL5P patch, add the legacy machine id and
hope that the old kernels will die off eventually. The problem here is
that we don't know how long to wait. We are taking the burden of
promise to be be compatible with the legacy kernel and respect all of
its restrictions. And it's not just a single patch. Trying to increase
the DRAM clock speed is potentially dangerous. For example, ACE is
documented to have a 200MHz clock speed limit, but it is using /2
divisor. Which means that with the 480MHz DRAM clock speed, we are
clocking ACE beyond normal operational limit. There are also voltage
regulators, controlled from FEX. We can't safely increase the VDD-DLL
voltage in u-boot, because the sunxi-3.4 kernel will change it to the
lower value.

> > A feature complete u-boot branch with extra patches on top of u-boot
> > v2014.10 (for example, with HDMI video driver support) 
> 
> Hmm, I assume that you're working on this and are going to maintain this?
> 
> So this is going to be some patches on top of v2014.10, or do you plan to
> merge v2014.10 and https://github.com/linux-sunxi/u-boot-sunxi ?

Just a minimal set of important patches on to of v2014.10, so that the
delta is clearly visible and kept minimal. There is no point doing
anything with https://github.com/linux-sunxi/u-boot-sunxi

> If this is going to be some patches on top of v2014.10, please consider
> pushing for getting these merged. I'm definitely interested in getting
> upstream u-boot to work with the sunxi-3.4 kernels, and I say this with my
> sunxi u-boot custodian hat firmly on.
> 
> As for the hdmi support, please note that I maintain a branch with that,
> (*) which includes several fixes here:
> 
> https://github.com/jwrdegoede/u-boot-sunxi/commits/sunxi-wip
> 
> And I plan to get this merged into u-boot master post the v2014.10 release,
> the big blocker is the simplefb clocks binding thingie, and I hope that
> that will be resolved soon.
> 
> Regards,
> 
> Hans
> 
> 
> *) other pending stuff I'm working on



-- 
Best regards,
Siarhei Siamashka