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? 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).
Attachment:
signature.asc
Description: PGP signature
