[U-Boot] L2 cache and LCD on sunxi

[U-Boot] L2 cache and LCD on sunxi

[Simon Glass]

Hi,

I ran up a banana PI and noticed that HDMI works in U-Boot. Great!

Scrolling seems very slow though - is the L2 cache disabled perhaps?

Also are there instructions for getting an LCD running in U-Boot? I
have an Olimex A20-OLinuxion-MICRO (what a mouthful!) with a 7 inch
display if that matters. I can't find any useful information so far.

Regards,
Simon

[U-Boot] L2 cache and LCD on sunxi

[Hans de Goede]

Hi,

On 21-12-14 19:52, Simon Glass wrote:
> Hi,
>
> I ran up a banana PI and noticed that HDMI works in U-Boot. Great!
>
> Scrolling seems very slow though - is the L2 cache disabled perhaps?

I don't think so, but it could be, I think the scrolling code is just
very inefficient. Feel free to poke things a bit around this, ARM
cache management is not my forte.

> Also are there instructions for getting an LCD running in U-Boot? I
> have an Olimex A20-OLinuxion-MICRO (what a mouthful!) with a 7 inch
> display if that matters. I can't find any useful information so far.

He he, your in luck I've been working on LCD support the last few days,
and I just got the olimex 7" lcd running on olimex boards :)

If you use my current wip tree:

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

And build for the A20-OLinuXino_MICRO-lcd7_defconfig things should
just work, assuming you are using the standard olimex 7" lcd with
a standard 40 pins pata cable.

Note in order for the kernel to take over the fb you need a small
kernel patch on top of 3.19, I've attached the patch.

Regards,

Hans



-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-ARM-dts-sunxi-Add-simplefb-nodes-for-de_be0-lcd0-dis.patch
Type: text/x-patch
Size: 1127 bytes
Desc: not available
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20141222/05d7c825/attachment.bin>

[U-Boot] L2 cache and LCD on sunxi

[Simon Glass]

Hi Hans,

On 22 December 2014 at 09:45, Hans de Goede <hdegoede@redhat.com> wrote:
> Hi,
>
> On 21-12-14 19:52, Simon Glass wrote:
>>
>> Hi,
>>
>> I ran up a banana PI and noticed that HDMI works in U-Boot. Great!
>>
>> Scrolling seems very slow though - is the L2 cache disabled perhaps?
>
>
> I don't think so, but it could be, I think the scrolling code is just
> very inefficient. Feel free to poke things a bit around this, ARM
> cache management is not my forte.

I think it need ssomething like the code in exynos/soc.c - see
v7_outer_cache_enable().

Even with the 7 inch it's very slow.

>
>> Also are there instructions for getting an LCD running in U-Boot? I
>> have an Olimex A20-OLinuxion-MICRO (what a mouthful!) with a 7 inch
>> display if that matters. I can't find any useful information so far.
>
>
> He he, your in luck I've been working on LCD support the last few days,
> and I just got the olimex 7" lcd running on olimex boards :)
>
> If you use my current wip tree:
>
> https://github.com/jwrdegoede/u-boot-sunxi/tree/sunxi-wip
>
> And build for the A20-OLinuXino_MICRO-lcd7_defconfig things should
> just work, assuming you are using the standard olimex 7" lcd with
> a standard 40 pins pata cable.
>
> Note in order for the kernel to take over the fb you need a small
> kernel patch on top of 3.19, I've attached the patch.

That's great, yes it works!

Looking at the patches, rather than adding new board configs and
CONFIGs I think it should be device-tree-controlled. Maybe an
environment variable could hold the display type?

Regards,
Simon

[U-Boot] L2 cache and LCD on sunxi

[Hans de Goede]

Hi,

On 23-12-14 05:36, Simon Glass wrote:
> Hi Hans,
>
> On 22 December 2014 at 09:45, Hans de Goede <hdegoede@redhat.com> wrote:
>> Hi,
>>
>> On 21-12-14 19:52, Simon Glass wrote:
>>>
>>> Hi,
>>>
>>> I ran up a banana PI and noticed that HDMI works in U-Boot. Great!
>>>
>>> Scrolling seems very slow though - is the L2 cache disabled perhaps?
>>
>>
>> I don't think so, but it could be, I think the scrolling code is just
>> very inefficient. Feel free to poke things a bit around this, ARM
>> cache management is not my forte.
>
> I think it need ssomething like the code in exynos/soc.c - see
> v7_outer_cache_enable().
>
> Even with the 7 inch it's very slow.

Ok, I'll put looking into this on my TODO list, if someone who is more
knowledge beats me to it I won't complain :)

>>> Also are there instructions for getting an LCD running in U-Boot? I
>>> have an Olimex A20-OLinuxion-MICRO (what a mouthful!) with a 7 inch
>>> display if that matters. I can't find any useful information so far.
>>
>>
>> He he, your in luck I've been working on LCD support the last few days,
>> and I just got the olimex 7" lcd running on olimex boards :)
>>
>> If you use my current wip tree:
>>
>> https://github.com/jwrdegoede/u-boot-sunxi/tree/sunxi-wip
>>
>> And build for the A20-OLinuXino_MICRO-lcd7_defconfig things should
>> just work, assuming you are using the standard olimex 7" lcd with
>> a standard 40 pins pata cable.
>>
>> Note in order for the kernel to take over the fb you need a small
>> kernel patch on top of 3.19, I've attached the patch.
>
> That's great, yes it works!
>
> Looking at the patches, rather than adding new board configs and
> CONFIGs I think it should be device-tree-controlled. Maybe an
> environment variable could hold the display type?

I agree that ultimately this should all move to devicetree as mentioned
in this commit message:

https://github.com/jwrdegoede/u-boot-sunxi/commit/4182ed0c8d037a357161dda63e179340e08adb7e

:)

As for using an environment variable, there is already video-mode env. var support, see
doc/README.video in my tree. I've considered also adding things like the LCD timings to
the environment but they really belong in a devicetree overlay, and if I add support for
them to the environment now I need to keep supporting that in the future. So the plan is
to use Kconfig for now, and move over to dt in the future.

Regards,

Hans

[U-Boot] L2 cache and LCD on sunxi

[Hans de Goede]

Hi,

On 23-12-14 05:36, Simon Glass wrote:
> Hi Hans,
>
> On 22 December 2014 at 09:45, Hans de Goede <hdegoede@redhat.com> wrote:
>> Hi,
>>
>> On 21-12-14 19:52, Simon Glass wrote:
>>>
>>> Hi,
>>>
>>> I ran up a banana PI and noticed that HDMI works in U-Boot. Great!
>>>
>>> Scrolling seems very slow though - is the L2 cache disabled perhaps?
>>
>>
>> I don't think so, but it could be, I think the scrolling code is just
>> very inefficient. Feel free to poke things a bit around this, ARM
>> cache management is not my forte.
>
> I think it need ssomething like the code in exynos/soc.c - see
> v7_outer_cache_enable().
>
> Even with the 7 inch it's very slow.

I've run some tests, and it is not slower then on say the A10 (cortex A8),
also I've been unable to find any docs or allwinner code pointing to
allwinner specific l2 cache init. As such ATM I do not believe that we've
the l2 cache disabled.

Regards,

Hans

[U-Boot] L2 cache and LCD on sunxi

[Simon Glass]

Hi Hans,

On 24 December 2014 at 09:47, Hans de Goede <hdegoede@redhat.com> wrote:
> Hi,
>
> On 23-12-14 05:36, Simon Glass wrote:
>>
>> Hi Hans,
>>
>> On 22 December 2014 at 09:45, Hans de Goede <hdegoede@redhat.com> wrote:
>>>
>>> Hi,
>>>
>>> On 21-12-14 19:52, Simon Glass wrote:
>>>>
>>>>
>>>> Hi,
>>>>
>>>> I ran up a banana PI and noticed that HDMI works in U-Boot. Great!
>>>>
>>>> Scrolling seems very slow though - is the L2 cache disabled perhaps?
>>>
>>>
>>>
>>> I don't think so, but it could be, I think the scrolling code is just
>>> very inefficient. Feel free to poke things a bit around this, ARM
>>> cache management is not my forte.
>>
>>
>> I think it need ssomething like the code in exynos/soc.c - see
>> v7_outer_cache_enable().
>>
>> Even with the 7 inch it's very slow.
>
>
> I've run some tests, and it is not slower then on say the A10 (cortex A8),
> also I've been unable to find any docs or allwinner code pointing to
> allwinner specific l2 cache init. As such ATM I do not believe that we've
> the l2 cache disabled.

Yes the code is not super-efficient (and could use the arch-specific
memcpy()) but I'm mostly interested in whether the platform is running
at full speed.

I'm comparing it to say an Exynos 5250 which is 1.7GHz Cortex-A15.
Without the L2 cache it scrolls quite slowly but with it it is fast.

There is probably some cache setup required.

Regards,
Simon

[U-Boot] L2 cache and LCD on sunxi

[Hans de Goede]

Hi,

On 29-12-14 17:23, Simon Glass wrote:
> Hi Hans,
>
> On 24 December 2014 at 09:47, Hans de Goede <hdegoede@redhat.com> wrote:
>> Hi,
>>
>> On 23-12-14 05:36, Simon Glass wrote:
>>>
>>> Hi Hans,
>>>
>>> On 22 December 2014 at 09:45, Hans de Goede <hdegoede@redhat.com> wrote:
>>>>
>>>> Hi,
>>>>
>>>> On 21-12-14 19:52, Simon Glass wrote:
>>>>>
>>>>>
>>>>> Hi,
>>>>>
>>>>> I ran up a banana PI and noticed that HDMI works in U-Boot. Great!
>>>>>
>>>>> Scrolling seems very slow though - is the L2 cache disabled perhaps?
>>>>
>>>>
>>>>
>>>> I don't think so, but it could be, I think the scrolling code is just
>>>> very inefficient. Feel free to poke things a bit around this, ARM
>>>> cache management is not my forte.
>>>
>>>
>>> I think it need ssomething like the code in exynos/soc.c - see
>>> v7_outer_cache_enable().
>>>
>>> Even with the 7 inch it's very slow.
>>
>>
>> I've run some tests, and it is not slower then on say the A10 (cortex A8),
>> also I've been unable to find any docs or allwinner code pointing to
>> allwinner specific l2 cache init. As such ATM I do not believe that we've
>> the l2 cache disabled.
>
> Yes the code is not super-efficient (and could use the arch-specific
> memcpy()) but I'm mostly interested in whether the platform is running
> at full speed.
>
> I'm comparing it to say an Exynos 5250 which is 1.7GHz Cortex-A15.
> Without the L2 cache it scrolls quite slowly but with it it is fast.

Well this is a 1 GHz Cortex A7, and one with likely a much less
efficient DRAM controller / less DRAM bandwidth.

> There is probably some cache setup required.

That could be, but if that is the case then I don't know where to start
looking for it. I certainly cannot find any such thing in allwinner;s
boot0 / boot1 bootloader.

Regards,

Hans

[U-Boot] L2 cache and LCD on sunxi

[Simon Glass]

Hi Hans,

On 29 December 2014 at 12:17, Hans de Goede <hdegoede@redhat.com> wrote:
> Hi,
>
>
> On 29-12-14 17:23, Simon Glass wrote:
>>
>> Hi Hans,
>>
>> On 24 December 2014 at 09:47, Hans de Goede <hdegoede@redhat.com> wrote:
>>>
>>> Hi,
>>>
>>> On 23-12-14 05:36, Simon Glass wrote:
>>>>
>>>>
>>>> Hi Hans,
>>>>
>>>> On 22 December 2014 at 09:45, Hans de Goede <hdegoede@redhat.com> wrote:
>>>>>
>>>>>
>>>>> Hi,
>>>>>
>>>>> On 21-12-14 19:52, Simon Glass wrote:
>>>>>>
>>>>>>
>>>>>>
>>>>>> Hi,
>>>>>>
>>>>>> I ran up a banana PI and noticed that HDMI works in U-Boot. Great!
>>>>>>
>>>>>> Scrolling seems very slow though - is the L2 cache disabled perhaps?
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> I don't think so, but it could be, I think the scrolling code is just
>>>>> very inefficient. Feel free to poke things a bit around this, ARM
>>>>> cache management is not my forte.
>>>>
>>>>
>>>>
>>>> I think it need ssomething like the code in exynos/soc.c - see
>>>> v7_outer_cache_enable().
>>>>
>>>> Even with the 7 inch it's very slow.
>>>
>>>
>>>
>>> I've run some tests, and it is not slower then on say the A10 (cortex
>>> A8),
>>> also I've been unable to find any docs or allwinner code pointing to
>>> allwinner specific l2 cache init. As such ATM I do not believe that we've
>>> the l2 cache disabled.
>>
>>
>> Yes the code is not super-efficient (and could use the arch-specific
>> memcpy()) but I'm mostly interested in whether the platform is running
>> at full speed.
>>
>> I'm comparing it to say an Exynos 5250 which is 1.7GHz Cortex-A15.
>> Without the L2 cache it scrolls quite slowly but with it it is fast.
>
>
> Well this is a 1 GHz Cortex A7, and one with likely a much less
> efficient DRAM controller / less DRAM bandwidth.
>
>> There is probably some cache setup required.
>
>
> That could be, but if that is the case then I don't know where to start
> looking for it. I certainly cannot find any such thing in allwinner;s
> boot0 / boot1 bootloader.

Me neither, although I suppose the kernel sets it up. It should only
be a few instructions to enable.

It would be nice to have some memory bandwidth testing code in U-Boot perhaps...

Regards,
Simon