On Mon, Mar 16, 2015 at 4:53 AM, Matthew Fortune <Matthew.Fortune@xxxxxxxxxx> wrote: > 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. We've changed our bootloader to pass the DTB via KSEG0. V2 of the Pistachio platform patches I posted last week used this protocol. Thanks, Andrew
