sunxi: chip: Enable the DIP auto-detection
Get series with b4
b4 am 20161111163338.GK27304@bill-the-catVersions newest first · linked by author and title
- v1 Latest posting 2/21 of 9 patches 0 repliesNew
- v1 posting 1/20 of 9 patches 0 repliesSuperseded
1 of 9 patches is in this archive. The cover letter announces 9.
Patches in v1 posting 2/2 No applies recorded yet
| # | Subject and files | Size | Replies | Applied |
|---|---|---|---|---|
| 6/9 | eeprom: Add DS2431 support | +0 | 4 replies |
Reviews trailers per patch
No Reviewed-by, Acked-by or Tested-by trailers for v1 yet.
Cover letter [U-Boot] [PATCH RESEND 0/9] sunxi: chip: Enable the DIP auto-detection
Quoted 20 lines · Maxime Ripard
Hi Tom,
Quoted 17 lines · Tom Rini
On Tue, Nov 08, 2016 at 11:19:20AM +0100, Maxime Ripard wrote:
[snip]
Quoted 5 lines
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 aCONFIG_PREBOOTload 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.
Quoted 5 lines
Quoted 1 line
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.
Quoted 8 lines
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 overlayI think
CONFIG_PREBOOTis 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?
Quoted 5 lines
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.
Quoted 10 lines
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.
Signature · 8 lines
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>