> -----Original Message----- > From: Milton Miller [mailto:[EMAIL PROTECTED] > Sent: Friday, December 14, 2007 12:06 AM > To: Stephen Neuendorffer > Cc: ppcdev; Grant Likely > Subject: Re: [PATCH 1/7] bootwrapper: Add a > firmware-independent "raw" target. > > On Fri Dec 14 10:43:27 EST 2007, Stephen Neuendorffer wrote: > > > From: Grant Likely <grant.likely at secretlab.ca> > > > > This target produces a flat binary rather than an ELF file, > > fixes the entry point at the beginning of the image, and takes > > a complete device tree with no fixups needed. > > > > The device tree must have labels on /#address-cells, the timebase > > frequency, and the memory size. > > > > Signed-off-by: Grant Likely <grant.likely at secretlab.ca> > > --- > > > You indicated in the intro in 0/ that this was not ready, and you > didn't include your own s-o-b, but you did not put any statements to > that effect in the header. The intro is not copied into patchwork, > which maintainers often use when deciding what to push.
Sorry... Still trying to figure out the process. > Now on to why this should not be merged: > > In addition to the above, it changes the build rules. It tries to > change wrapper to assemble the .dtb into a .o from a .S file, but > doesn't set any flags to force the assembler into the right mode. In > contrast the linker is controlled by the .lds linker script. > > In addition, the requirement for assembly labels can easily be > eliminated. As mentioned above, they are used for 3 > properties. With > the existing library (in 2.6.24 and earlier), call simple_malloc_init > with a small bss array (like BSS_STACK does to allocate stack), and > then read the properties out of the device tree. At that point, call > simple_malloc_init a second time using the found memory size. As I > said the last time this was posted, my patches to boot from kexec > implemented this strategy. > > However, with the new libfdt, which is already in for-2.6.25, > we should > no longer need malloc() to simple read the tree. At least that is > what was advertised. Yes, I agree, I just haven't had a chance to go back and write that code yet... Thanks for the comments, Steve _______________________________________________ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
