[U-Boot] [PATCH RESEND 0/9] sunxi: chip: Enable the DIP auto-detection

[Maxime Ripard <maxime.ripard@free-electrons.com>]

Hi Tom,

On Tue, Nov 08, 2016 at 10:44:18PM -0500, Tom Rini wrote:
> On Tue, Nov 08, 2016 at 11:19:20AM +0100, Maxime Ripard wrote:
> 
> [snip]
> > I think the biggest drawback at the moment is that we maintain a list of
> > DIPs and the actions needed directly into the C code, which will make it
> > quite hard to customise for end users and tedious to maintain in the long
> > term. I couldn't really get my head around a better solution, so feel free
> > to suggest alternative approaches.
> 
> A thought I had after reading over 8/9 in the series was, could we try
> something like:
> - In C, loop over everything in w1 and set environment variables based
>   on each thing we find.
> - In a CONFIG_PREBOOT load a U-Boot shell script in that will look for
>   the right env variables to be set for a given DIP and then do whatever
>   is needed to load in the overlay.
> 
> Does that make sense?

I thought about an environment-based solution too, but I was pretty
worried about its scalability. But I guesse that's also the easiest
thing to modify by end-users.

However, we have basically, three things to do (so far)
  1) Modify the U-Boot environment before the display is initialized
  2) Modify the kernel command line
  3) Apply an overlay

I think CONFIG_PREBOOT is too late for 1, because the display is
already initialized, and too early for 2 and 3, because the command
line and DT will probably be set / loaded at bootcmd time.

I think we can decouple 1 and 2 from 3, since doing 2 too early is not
an issue, because we might have boards that require to load some
overlay but wouldn't need to make environment modifications (like an
MMC DIP), or the other way around (even though I fail to see a use
case for that at the moment).

So we're left with basically two things:
  - Do a bunch of modifications in the environment early
  - And apply the overlay very late (basically right before booting
    the kernel)

So we could do something like having an environment script called
dip-<vid>-<pid>-setup called when a DIP is detected (if it exists),
and keep the DT overlay logic in its current form.

What do you think?
Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: not available
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20161109/11bba8a8/attachment.sig>