On Thu, Jul 15, 2010 at 10:39 AM, Matthew McClintock <m...@freescale.com> wrote: > 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? Where does the device tree (and >> memreserve list) come from >> that you're passing to kexec? My 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 > > > -- Grant Likely, B.Sc., P.Eng. Secret Lab Technologies Ltd. _______________________________________________ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
