Re: BCM2836 (Raspberry Pi 2) port

[Stephen Warren <swarren-3lzwWm7+Weoh9ZMKESR00Q@public.gmane.org>]

On 05/13/2015 11:46 AM, Eric Anholt wrote:
> Stephen Warren <swarren-3lzwWm7+Weoh9ZMKESR00Q@public.gmane.org> writes:
>
>> On 05/12/2015 11:32 AM, Eric Anholt wrote:
>>> Stephen Warren <swarren-3lzwWm7+Weoh9ZMKESR00Q@public.gmane.org> writes:
>>>
>>>> On 05/12/2015 09:39 AM, Alexander Stein wrote:
>>>>> On Monday 11 May 2015, 20:36:40 wrote Stephen Warren:
>>>>>> On 05/08/2015 10:14 AM, Alexander Stein wrote:
>>>>>>> On Thursday 23 April 2015, 22:25:08 wrote Stephen Warren:
>>>>>>>>> Hit any key to stop autoboot:  0
>>>>>>>>> U-Boot> setenv fdt_high fffffff
>>>>>>>
>>>>>>> Any specific reason to set fdt_high to fffffff?
>>>>>>
>>>>>> Yes, it prevents U-Boot's annoying habit of moving the DTB from where it
>>>>>> was loaded to some other place. This was especially important in this
>>>>>> case since I was trying to find out exactly which piece of RAM being
>>>>>> over-written caused the issues I was seeing.
>>>>>
>>>>> Shouldn't this then be part of the default raspberry (2 only?) environment?
>>>>
>>>> Eventually yes. So far, nobody seems to know which areas of RAM are
>>>> off-limits (presumably since the RAM is used as a CPU1..3 pen), so I was
>>>> experimenting to try and find that out.
>>>
>>> If I'm reading this right, the CPU1-3 pen is in the bottom 8k of memory
>>> (actually much less than 8k).
>>
>> Hmm. I wondered if that was the case. I don't think anything I was doing
>> in U-Boot /should/ touch those pages, but there have been bugs before
>> where some pointer was left at NULL, and some DM (U-Boot Device Model)
>> code ended up putting structures in page 0 by mistake. Perhaps something
>> like that has resurfaced. I'll try to find time to diff page 0
>> before/after various U-Boot operations, and see if it's getting modified...
>
> How about on the Linux side?  What's reserving that memory for us, if
> anything?

Likely nothing at present. I was starting to see what looked like 
SMP-pen-related issues just in U-Boot, before even attempting to boot a 
kernel at all. So, I didn't put any though into how to communicate this 
to the kernel.

>  Weird things happen if I put "ARM: bcm2836: Add a DT binding
> for the ARM local registers." and "ARM: bcm2835: Use a syscon regmap to
> set up timer frequency." before the SMP support in the bcm2836-smp tree
> (init crashes).

This issue would probably explain that; if the kernel just happens to 
allocate a physical page of RAM that overlaps the SMP pen memory.

A /memreserve/ in the DT would probably solve this. Adjusting the 
content of the /memory/reg property to remove the SMP pen would likely 
work too.

Is there no way to disable CPU1..n other than using an SMP pen in 
memory? If the CPUs simply weren't executing anything at all, but could 
be unblocked/powered-up/... later, that'd simplify life.
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html