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

[Warner Losh]

On Mar 1, 2014, at 8:49 AM, Ian Lepore <ian at FreeBSD.org> wrote:

> On Sat, 2014-03-01 at 07:41 -0800, Tim Kientzle wrote:
>> On Feb 28, 2014, at 5:42 AM, Ian Lepore <ian at freebsd.org> wrote:
>> 
>>> I've added a new imx6 unified kernel config named IMX6.  It has no
>>> compiled-in fdt, and can boot all three flavors of Wandboard when u-boot
>>> and ubldr load a dtb file.  Folks should start using it and eventually
>>> the WANDBOARD* configs will go away when nobody needs them anymore.
>> 
>> Nice!  Another step towards GENERIC ARM.

Yes, many more steps to go, but if we can have a generic kernel per SoC that’s
miles ahead of where we are now.

>>> the .dtb file in your /boot/kernel or /boot/modules directory, and ubldr
>>> will load it from there, using the filename set in the u-boot env var
>>> fdt_file.
>> 
>> Using a U-Boot env var to specify the FDT is a nice idea.

When U-Boot itself doesn’t have the DTB already in the image, yes.

>>> Unfortunately we can't do a single image that boots any wandboard,
>>> because u-boot itself has to be different for each board.  This is what
>>> my u-boot env looks like on each wandboard:
>>> 
>>> => printenv
>>> baudrate=115200
>>> bootcmd=run ubnet
>>> bootdelay=1
>>> console=ttymxc0
>>> fdt_file=wandboard-dual.dtb
>>> loadaddr=11000000
>>> loaderdev=net
>>> ubmmc=fatload mmc 0 ${loadaddr} ubldr; bootelf
>>> ubnet=dhcp ${loadaddr} /wand/boot/ubldr;bootelf
>>> 
>>> Environment size: 265/8188 bytes
>>> 
>>> The only thing that differs per-board is the fdt_file setting, and the
>>> u-boot binary itself.
>> 
>> If you could get to a single U-Boot binary, you might
>> be able to do what BeagleBone does:  The U-boot.env
>> script detects the board variation and conditionally
>> loads the correct DTB blob.
> 
> That's my long-term goal, but it'll take some major u-boot hacking,
> probably won't happen for months.  The imx6 quad chip is different
> enough from the solo and dual-lite that a single u-boot to handle both
> will be kind of tricky the way the u-boot code is structured now.  Doing
> a single u-boot for solo+dual-lite is so trivial I'm not sure why
> wandboard didn't do it that way.

Things get more complicated when more boards are involved…  For all
the Atmel boards, the user or board maker (more typically) will have to
include the DTB so you know which one of the dozens of choices is
present…But then again, from the kernel/ubldr perspective, the right DTB
is present, and you are good to go

Warner