BCM2836 (Raspberry Pi 2) port

[Eric Anholt]

Stephen Warren <swarren at wwwdotorg.org> writes:

> On 05/13/2015 11:46 AM, Eric Anholt wrote:
>> Stephen Warren <swarren at wwwdotorg.org> writes:
>>
>>> On 05/12/2015 11:32 AM, Eric Anholt wrote:
>>>> Stephen Warren <swarren at wwwdotorg.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.

Not that I can see -- looks like they all come up the same way, then 1-3
fall into the pen and 0 continues on to do interesting things.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 818 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20150513/0840e7d8/attachment.sig>