Stephen Warren <swarren@xxxxxxxxxxxxx> writes: > On 05/13/2015 11:46 AM, Eric Anholt wrote: >> Stephen Warren <swarren@xxxxxxxxxxxxx> writes: >> >>> On 05/12/2015 11:32 AM, Eric Anholt wrote: >>>> Stephen Warren <swarren@xxxxxxxxxxxxx> 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.
Attachment:
signature.asc
Description: PGP signature
