[U-Boot] MIPS UHI spec

[Matthew Fortune]

James Hogan <James.Hogan at imgtec.com> writes:
> On 26/02/15 12:37, Daniel Schwierzeck wrote:
> > 2015-02-26 11:17 GMT+01:00 Paul Burton <paul.burton at imgtec.com>:
> >> 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