[U-Boot] MIPS UHI spec

[Andrew Bresticker]

On Mon, Mar 16, 2015 at 4:53 AM, Matthew Fortune
<Matthew.Fortune at imgtec.com> wrote:
> 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.

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