[PATCH] maintainership update for the Marvell Orion family of SOCs
arnd at arndb.de
Wed May 2 09:05:17 EDT 2012
On Tuesday 01 May 2012, Andrew Lunn wrote:
> > Well, there is no reason to rush this at all, it could live in parallel
> > for a couple of years. But at one point we can decide that if nobody has
> > bothered to write the .dts file for one board and tested it that nobody
> > cares about that board any more and it can just get removed and possibly
> > added back in dts form when someone does complain.
> Probably a FAQ, but maybe somebody can point me in the right
> direction. How will Debian, Ubuntu, etc, deal with old machines who's
> u-boot does not support DT, yet the kernel has moved on and only has
> DT support for a board? Will the kernel install process need to
> determine what board the machine is and append the DT to the end of
> the kernel?
I think that is the most likely scenario. Another option would be
to provide a replacement or second-stage boot loader that actually
understands DT and that gets loaded instead of the kernel by the
first-stage boot loader.
> Or do we envisage a process where all DT are appended to
> the kernel, and the machine ID, as passed by the old uboot, is used to
> pick the correct DT?
This has been discussed in the past, but IIRC we decided against putting
that logic into the kernel. Folks on devicetree-discuss at l.o.o might remember
the details better than me.
More information about the linux-arm-kernel