James Hogan <James.Hogan@xxxxxxxxxx> writes: > On 26/02/15 12:37, Daniel Schwierzeck wrote: > > 2015-02-26 11:17 GMT+01:00 Paul Burton <paul.burton@xxxxxxxxxx>: > >> On Thu, Feb 19, 2015 at 01:50:23PM +0000, Matthew Fortune wrote: > >>> Hi Daniel, > >>> > >>> The spec for MIPS Unified Hosting Interface is available here: > >>> > >>> http://prplfoundation.org/wiki/MIPS_documentation > >>> > >>> As we have previously discussed, this is an ideal place to define > >>> the handover of device tree data from bootloader to kernel. Using a0 > >>> == -2 and defining which register(s) you need for the actual data > >>> will fit nicely. I'll happily include whatever is decided into the > >>> next version of the spec. > > > > this originates from an off-list discussion some months ago started by > > John Crispin. > > > > (CC +John, Ralf, Jonas, linux-mips) > > > >> > >> (CC +Andrew, Ezequiel, James, James) > >> > >> On the talk of DT handover, this recent patchset adding support for a > >> system doing so to Linux is relevant: > >> > >> > >> http://www.linux-mips.org/archives/linux-mips/2015-02/msg00312.html > >> > >> I'm also working on a system for which I'll need to implement DT > >> handover very soon. It would be very nice if we could agree on some > >> standard way of doing so (and eventually if the code on the Linux > >> side can be generic enough to allow a multiplatform kernel). > >> > > > > to be conformant with UHI I propose $a0 == -2 and $a1 == address of DT > > blob. It is a simple extension and should not interfere with the > > various legacy boot interfaces. > > I was just looking at Andrew's patch: > http://patchwork.linux-mips.org/patch/9549/ > > How would the other registers (i.e. $a2 and $a3) be defined for this > boot interface? I'm guessing any future extensions are envisioned to use > a different negative value of $a0, in which case treating them as > unused/undefined is fine, but perhaps that should be spelt out in the > UHI spec? Sounds sensible. Making it explicit may help prevent anyone extending this and presuming that they can give meaning to one of the unused registers. Did anyone come to a conclusion on physical vs virtual address for the DTB? I forgot to reply to the thread, I would have thought the KSEG0 address would be the obvious choice so that it is immediately usable from ordinary memory accesses. However, that is only because I don't follow how the kernel would benefit from being given a physical address. It can't be remapped except for the case of segmentation control (I believe) so there seems little risk in using KSEG0. Thanks, Matthew
