A unified imx6 kernel config, old WANDBOARD-* configs going away

[Warner Losh]

On Mar 2, 2014, at 9:41 AM, Ian Lepore <ian at FreeBSD.org> wrote:

> On Sun, 2014-03-02 at 09:30 -0700, Warner Losh wrote:
>> On Mar 1, 2014, at 8:42 PM, Ian Lepore <ian at FreeBSD.org> wrote:
>> 
>>> On Sat, 2014-03-01 at 18:01 -0700, Tom Everett wrote:
>>>> I'm looking at the crochet code, and I see in freebsd_install_fdt that both
>>>> *.dtb and *.dts are supported. However on the source tree it's imx6.dtsi.
>>>> What's the difference b/t a dts file and a dtsi file?
>>> 
>>> A .dtsi file is an include file used by .dts files.  A .dtb is the
>>> binary (compiled) form used by the kernel.
>>> 
>>> So there are several wandboard-something.dts files, each of which
>>> includes imx6.dtsi where all the common parts live.  For a new imx6
>>> device, a new board-named file similar to one of the wandboard files is
>>> necessary, and it would also include imx6.dtsi.
>> 
>> As would other boards that use the imx6 SoC. They’d have their own .dts
>> file that included the imx6.dsti and customized it for how they are wired
>> together.
>> 
>>> We're pushing hard towards just using the standard dtb files from
>>> vendors, but we've got a bit of work to do before we're there.
>> 
>> I have some rough changes that allow us to build N different DTBs as part
>> of the kernel build, but not glom them into the kernel. Not strictly required
>> for this, but helpful.
>> 
>> I’m planning on having Atmel use 100% vendor supplied files as well.
>> It is a very good goal. There’s also efforts on the linux side to separate out
>> the device-trees from the linux kernel, which is where I grabbed the recent
>> /vendor/device-tree stuff from.
>> 
>> Warner
> 
> For imx6, the big obstacle to using vendor dtb files is now just the
> device instantiation order.  The stock dts files list devices basically
> in order of their memory-mapped register addresses, but we need the
> interrupt controller to be available first regardless of where it's
> mapped, and likewise for a few other critical devices.
> 
> I need to do another round of experimentation with the
> EARLY_DRIVER_MODULE() stuff and multipass device instantiation.  We may
> not be all that far from success.

Taking your patches, I expanded them so that I could list the interrupt controller
and such last on my Atmel boards, but still have it attach first… I want to make
sure that I can get the NAND working just from the FDT file and then I’d feel
comfortable committing. Interested in peeking at the diffs before I do?

Warner