On Thu, Mar 25, 2010 at 3:04 PM, Russell King - ARM Linux <li...@arm.linux.org.uk> wrote: > On Wed, Mar 24, 2010 at 09:11:56AM -0600, Grant Likely wrote: >> ===Required System State=== >> *Quiesce all DMA >> *CPU register contents >> **r0 = 0 >> **r1 = Linux machine number (as defined in the ARM Linux machine database) >> or 0 > > 0 is a valid machine number. What is your purpose of passing 0?
Heh, I forgot to go back and check if 0 was assigned or not. I just wanted something that wasn't going to conflict. How about 0xffffffff like Jeremy has been using? >> **r2 = physical address of tagged parameter list in system RAM >> *IRQs disabled >> *MMU off >> *Instruction cache either on or off >> *Data cache turned off > > Would recommend saying "Data cache(s) turned off" so that L2 cache is > included. done. >> ===Minimal state for Flattened Device Tree Boot=== >> For FDT booting, the tagged list only needs to contain a single device >> tree tag, and the device tree blob could be appended to the end of the >> tagged list so that everything resides in the same region of memory. > > That's a bad idea. Sometimes the tagged list can be extended by wrappers > around the kernel, and data placed at the end of the list would be > overwritten. Fair enough, I hadn't considered that. Currently I'm handling the tree blob the same way ramdisks are handled and waiting until after bootmem_init() to actually access the tree. That works for the device registration code, but I still rely on the machine id for probing platform code. Jeremy has patches that can do platform probing from device tree data, but last I talked to him it required the blob to be in the same section of memory as the atags. ie. between PHYS_BASE and PHYS_BASE+0x4000 IIRC. > As the tagged list can encode arbitarily sized data chunks, there's no > reason to use a pointer in the tagged list. However, there is a problem: > what do you do with a large chunk of data in the tagged list? You can't > allocate memory to copy it in the kernel because no memory allocators > are up and running... > > That's always been the catch-22 with passing binary data blobs to the > kernel. Indeed. Another option I suppose is to extract the needed data from the tree as part of the wrapper and squirt it into atags. Then there would be no problem in waiting until bootmem_init() to reserve the devicetree memory. Cheers, g. -- Grant Likely, B.Sc., P.Eng. Secret Lab Technologies Ltd. _______________________________________________ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
