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
_______________________________________________
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
