Skip site navigation (1)Skip section navigation (2)
Date:      Sun, 3 Apr 2011 19:45:29 -0600
From:      Warner Losh <imp@bsdimp.com>
To:        Juli Mallett <jmallett@FreeBSD.org>
Cc:        "mips@freebsd.org" <mips@FreeBSD.org>
Subject:   Re: Toiling away on booting the new blades
Message-ID:  <F63B0665-6215-4190-B9E3-DE6A34F5AA40@bsdimp.com>
In-Reply-To: <BANLkTi=%2B0W8%2BCgpfXVtSwA7wzqcQu4T1vw@mail.gmail.com>
References:  <AC6674AB7BC78549BB231821ABF7A9AEB52F1950D0@EMBX01-WF.jnpr.net> <153BB57A-6F99-4E5C-9F39-55D6C3B210FC@bsdimp.com> <BANLkTi=%2B0W8%2BCgpfXVtSwA7wzqcQu4T1vw@mail.gmail.com>

next in thread | previous in thread | raw e-mail | index | archive | help

On Apr 3, 2011, at 5:19 PM, Juli Mallett wrote:

> On Sun, Apr 3, 2011 at 15:07, Warner Losh <imp@bsdimp.com> wrote:
>> On Apr 3, 2011, at 3:29 PM, Andrew Duane wrote:
>>> Since the MIPS bootinfo structure is already part of FreeBSD, is =
this code in the startup path something you'd be interested in taking =
in?
>>=20
>> I think I'd be interested.  I think this is a decent path to explore, =
but would need to see code before committing :)
>=20
> Indeed, I think it's worth committing probably, or perhaps committing
> a modified version that does the same thing.  It's easy to imagine
> that some people will eventually want to just use loader with U-Boot
> on Octeon so that they can have hints, good UFS support, module
> loading, etc.
>=20
> Also, Warner, if you touch octeon_machdep.c, could you please move the
> app boot descriptor thing to a separate header file with the Cavium
> license?  I believe I've touched all of the actual *source code*
> there, but right now we're possibly violating the license (depending
> on how big you believe a page is) which requires the license to be at
> the top of the file.  So I think moving the license and struct to a
> separate header would be sufficient (using the structure from the
> current SDK would probably be even better?)

I'll look into it.  I inherited the code from the Cavium folks, so if =
there's a license violation, they did it to themselves :)

Structurally, I think it would be better.  I've wanted to have more =
modularity in how we hook up the bootloader-> kernel handoff for =
embedded systems for a while, and this will help that goal.

Warner




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?F63B0665-6215-4190-B9E3-DE6A34F5AA40>