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

[Tom Rini <trini@konsulko.com>]

On Wed, Nov 09, 2016 at 03:10:18PM +0100, Maxime Ripard wrote:
> 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.

Yeah, I share that concern too.  But it's also the "easy" one in terms
of debug and test too.

> 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.

Something I honestly wonder about at times is, would it not be better to
optimize the default case such that the kernel is up and dealing with
the display ASAP?  If we go from power-on to Kernel is up and has thrown
something on-screen in a few seconds, do we really need a complex
solution so that it's up 1 or 2 seconds sooner?

> 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).

OK.

> 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?

I think that might work.  I think we really want to avoid having modify
U-Boot to add a new DIP, so if we can move things to the point of
"Here's your DIP and here's a link to the file you install $here on your
board and it just works" we'll be in a good spot.

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20161111/066c5a79/attachment.sig>