Re: [PATCH V4] powerpc/prom: Export device tree physical address via proc

[Grant Likely <grant.likely@secretlab.ca>]

On Thu, Jul 15, 2010 at 10:39 AM, Matthew McClintock <msm@freescale.com> wr=
ote:
> On Thu, 2010-07-15 at 10:22 -0600, Grant Likely wrote:
>> > Thanks for taking a look. My first thought was to just blow away all
>> the
>> > memreserve regions and start over. But, there are reserve regions
>> for
>> > other things that I might not want to blow away. For example, on
>> mpc85xx
>> > SMP systems we have an additional reserve region for our boot page.
>>
>> What is your starting point? =A0Where does the device tree (and
>> memreserve list) come from
>> that you're passing to kexec? =A0My first impression is that if you have
>> to scrub the memreserve list, then the source being used to
>> obtain the memreserves is either faulty or unsuitable to the task.
>
> I'm pulling the device tree passed in via u-boot and passing it to
> kexec.

How?  (what mechanism?)  I hope you're not using the debugfs
flat-device-tree file.

> It is the most complete device tree and requires the least amount
> of fixup.
>
> I have to scrub two items, the ramdisk/initrd and the device tree
> because upon kexec'ing the kernel we have the ability to pass in new
> ramdisk/initrd and device tree. They can also live at different physical
> addresses for the second reboot.

This sounds like the model is backwards.  Rather than scrubbing items,
the memreserve list should be built up from a known good source.

> The initrd addresses are already exposed, so we can update/remove/reuse
> that entry, we just need a way for kexec to determine the current device
> tree address so it can replace the correct memreserve region for the
> kexec'ing kernels' device tree.
>
> The whole problem comes from repeatedly kexec'ing, we need to make sure
> we don't keep losing blobs of memory to reserve regions (so we can't
> just blindly add). We also need to make sure we don't lose other
> memreserve regions that might be important for other things (so we can't
> just blow them all away).

Right, so you need to have a known-good list of reserve sections.
Trying to go the other way sounds very fragile.

g.


>
> -M
>
>
>



--=20
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.