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

[Hans de Goede]

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.

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

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've been using an a23 dtb + generic multi-platform kernel for my testing
>> (as said before the a33 really is almost the same design), and that boots
>> fine without this alignment hack on an actual A23 device, so this is not
>> a kernel limitation.
>
> Not necessarily. Is RAM at the same location on both SoCs? What about
> other devices and carevouts?

Everything is the same on both SoCs except that one has 2 Cortex A7
cores and the new one with the problem has 4 Cortex A7 cores, and a
new dram controller / mbus subsystem to keep the 4 cores fed.

> It could be htat the stars happen to align and we're finally caught out
> by some dodgy maths.

I don't think that that is the case here.

Regards,

Hans