In message: <AANLkTi=UM2p26JJMqv-cNh8xACS_KPf_dCst5cgmh5VR@xxxxxxxxxxxxxx>
Grant Likely <grant.likely@xxxxxxxxxxxx> writes:
: Overall the plan makes sense, however I would suggest the following.
: instead of 'live' modifying the tree, another option is to carry a set
: of 'stock' device trees in the kernel; one per board. Of course this
: assumes that your current ad-hoc code is keying on the specific board.
: If it is interpreting data provided by the firmware, then your
: suggestion of modifying a single stock tree probably makes more sense,
: or possibly a combination of the too. In general you should avoid
: live modification as much as possible.
The one draw back on this is that there's lots of different "stock"
boards that the Cavium Octeon SDK supports. These will be difficult
to drag along for every kernel. And they'd be mostly the same to,
which is why I think that David is suggesting the live modification
thing...
I know that FreeBSD will have exactly the same problem as we move to
using the FDT for FreeBSD/mips' configuration.
Warner
