[U-Boot] [PATCH 07/10] sunxi: Fix end of kernel memory alignment for A33

[Hans de Goede]

Hi Mark,

On 17-04-15 12:20, Mark Rutland wrote:
> On Thu, Apr 16, 2015 at 08:12:31PM +0100, Hans de Goede wrote:
>> Hi,
>>
>> On 16-04-15 19:35, Mark Rutland wrote:
>>> On Thu, Apr 16, 2015 at 08:32:03AM +0100, Hans de Goede wrote:
>>>> Hi,
>>>>
>>>> On 15-04-15 21:57, Ian Campbell wrote:
>>>>> On Tue, 2015-04-14 at 18:06 +0200, Hans de Goede wrote:
>>>>>> For unknown reasons the A33 needs the end of the memory we report to the
>>>>>> kernel to be aligned to a multiple of 4 MiB.
>>>>>
>>>>> Do you really mean "the A33 needs" (as in the processor itself) or do
>>>>> you actually mean "the A33 kernel port"?
>>>>>
>>>>> If the latter than can't that be investigated/fixed instead of hacked
>>>>> here? That would be far more preferable.
>>>>
>>>> I mean the former, it seems that the SoC itself cannot handle dram
>>>> ranges with different cache policies which are not aligned to 4 MiB,
>>>> at least that is my WAG what is going on here.
>>>
>>> That sounds incredibly suspicious.
>>>
>>> What do you mean w.r.t. different cache policies -- what does that have
>>> to do with the end of DRAM?
>>
>> We carve out a framebuffer at the end of DRAM, and then report less
>> DRAM then we actually have to the kernel. This framebuffer then gets
>> picked up by the kernel through simplefb, which will map it with a different
>> cache policy then the normal part of the DRAM has.
>
> I see. Thanks for the clarification.
>
>>> What problem do you see?
>>
>> Depending on the framebuffer-size the kernel either boots or does not boot,
>> when it does not boot it does nothing (I've a serial console) earlyprintk
>> does not help, I was looking into setting up an early console (should be
>> a matter of just putting in the right parameters) when I found out that if
>> I modify the framebuffer size that fixes things.
>
> Ok. So we don't know if the kernel is stuck somewhere or everything is
> completely hosed, then?
>
> I take it you can't get JTAG worknig via the SD card slot?
>
>> After experimenting more it seems that keeping the last pixel of the
>> framebuffer at the very end of DRAM is not a problem (so this does not seem
>> to be a display engine problem), things start to work when I make the carve
>> out at the end bigger.
>>
>> On the very similar A23 giving the kernel all of the DRAM except for the
>> framebuffer (aligned to a multiple of 4k) works just fine.
>>
>> Sometimes I can get away with just making the carve-out bigger without
>> aligning it to a multiple of 4 MiB, but an alignment to 4 MiB seems to
>> always work independent of the framebuffer size.
>>
>>> It would be worth reporting this on lakml.
>>
>> If you still think that after the above explanation I'll start a new thread
>> on lakml with contents more targeted at kernel devs.
>
> I think it would be worthwhile. This could be one instance of an issue
> in the memory system that we might hit elsewhere. Even if we don't come
> to another solution, it'll at least make it visible to others.

So it seems that I'm not the only one seeing this, and I've been wrongly
blaming it on the A33, instead it seems to be a kernel bug, triggered
on my A33 due to the display resolution it has.

For details see:

http://www.spinics.net/lists/arm-kernel/msg413811.html

Regards,

Hans