Date: Wed, 7 Sep 2011 13:16:01 -0700 From: Juli Mallett <jmallett@FreeBSD.org> To: Andrew Duane <aduane@juniper.net> Cc: "mips@freebsd.org" <mips@freebsd.org> Subject: Re: Adding board IDs to sys/contrib/octeon-sdk/cvmx-app-init.h Message-ID: <CACVs6=-8h4DVD7F2Ahh9RiEv=OR00iE4tSNwJdvzp2yPAP1X0g@mail.gmail.com> In-Reply-To: <AC6674AB7BC78549BB231821ABF7A9AEB7452DBBF1@EMBX01-WF.jnpr.net> References: <AC6674AB7BC78549BB231821ABF7A9AEB7452DBBF1@EMBX01-WF.jnpr.net>
index | next in thread | previous in thread | raw e-mail
On Wed, Sep 7, 2011 at 12:37, Andrew Duane <aduane@juniper.net> wrote: > I know this is a Cavium maintained file, there's even a comment inside that says: > > /* Set aside a range for customer boards. These numbers are managed > ** by Cavium. > */ > > Is there a protocol for adding new board IDs? And, would it be a real problem if the board IDs were not between CVMX_BOARD_TYPE_CUST_PRIVATE_MIN and CVMX_BOARD_TYPE_CUST_PRIVATE_MAX? I'm trying to sort out some code additions to define our private boards, and they already have hardware IDs assigned and burned into them that are in the range of 1300 to 1600 or so. Look at the ifdefs I added to that file to handle a couple of vendors who went outside of those ranges or overlapped with other boards. Just add an OCTEON_VENDOR_JUNIPER option and put your board-related stuff behind an ifdef in the SDK and outside of it. > I guess I could read the hardware IDs and add CVMX_BOARD_TYPE_CUST_PRIVATE_MIN as an offset, is that a reasonable approach? > > As a related question, is there a protocol for managing kernel configuration files that belong to a private platform? I think probably not managing them in a FreeBSD.org tree makes the most sense :)help
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CACVs6=-8h4DVD7F2Ahh9RiEv=OR00iE4tSNwJdvzp2yPAP1X0g>