Drop forest of patches, and use the new unified tree#238
Drop forest of patches, and use the new unified tree#238samueldr merged 35 commits intoTow-Boot:developmentfrom
Conversation
| TOW_BOOT_PREDICTABLE_BOOT_PREFER_EXTERNAL = yes; | ||
| TOW_BOOT_PREDICTABLE_BOOT_PREFER_INTERNAL = no; |
There was a problem hiding this comment.
Since this is a choice, just the PREFER_EXTERNAL = yes; should be enough, but having a no for the other ensures there's nothing wrong going on with the implementation. It's redundant, but gives assurance both won't be true at once.
| CMD_CLS = yes; | ||
| CMD_SETEXPR = yes; | ||
| CMD_PAUSE = yes; | ||
| CMD_PAUSE = lib.mkIf (!config.Tow-Boot.buildUBoot) yes; |
There was a problem hiding this comment.
CMD_PAUSE has been mainlined, so it will be possible to enable this outright when upgrading U-Boot.
67a9019 to
668ee76
Compare
|
For anyone playing at home:
This shows a correctness issue when syncing DTs with linux and that workaround. From a quick grep, no other The solution is to change the workaround implementation. This turns a regulator off and on again. This is not elegant. This also shows garbage in the display for a short while. What we can do, instead, is force the regulator off during SPL. Since it's A better(?) solution might be to have a "for U-Boot" tag on the regulator telling it that actually while it is always-on, SPL should turn it off, as a warm reset keeps the thing in a bad state. Or maybe it shouldn't be With the upcoming change, there is no garbage on display, but the framebuffer
|
668ee76 to
dabb614
Compare
|
Latest push updates the source ref; which in turn has the RK3399 history revisions, Pinebook Pro revisions, and framebuffer clearing. |
dabb614 to
5cb63ca
Compare
|
(Force-push synced with current |
5cb63ca to
f5c9c27
Compare
|
CI is already paying dividends |
f5c9c27 to
30231db
Compare
- remove unused args for fetchpatch - dropped newline
We'll better support that use-case, since we're moving away from large set of patches to using a single unified tree.
Capitalize the name, and make make it obvious it's about the docs
Those will now live in a unified git tree.
Will now live in the unified source tree.
They will now live in the unified source tree.
This is required anyway with stock U-Boot or else our tooling will build it at the wrong location.
This was previously applied to any board. Let's opt-in.
This is when we use the *configuration* from Tow-Boot, e.g. environment position. This is useful to find out whether Tow-Boot is broken, or stock U-Boot is broken under specific configuration options.
30231db to
f28f24d
Compare
By using the Modules system, we can introspect on the attrsets (or even add new values), and in turn this means we can use the attrsets for automatically building all the known versions! (upcoming!)
f28f24d to
4904f24
Compare
|
It wasn't entirely "tested" in full, like I wanted initially, but the reasoning to merge is two-fold:
Nothing here will require "fixing" other than the revision and hash once that is done. Which leads to one question: how should that be managed for updates? I guess we'll add a pin in only when ready to publish a new version? |
This change set aims to make it easier to work and collaborate on the patches.
This makes use of the (Tow-Boot/U-Boot)[https://github.com/Tow-Boot/U-Boot] repo, where topic branches are created for releases.
A final strategy hasn't been decided for dealing with the actual branches, but the gist of it is once "ready", a "final" unified branch is pushed, which is an octopus merge of the whole set of changes. This merge is made using a tool, and should also be used when validating work before publishing things for U-Boot changes. Note that this is still a WIP and likely will change, TBD with other collaborators.
Though what is final is that we will be using a single source to represent the whole change set*.
One benefit that has already been shown, where some way too hacky changes were in use, and it instead was preferable to work things out in a better manner with discrete U-Boot config options. In other words, it keeps us more honest and in better working order, without giving us as much opportunities to lapse into bad hacks.
The code, short of some minor cleanups, mainly centered around surrounding hacks with
CONFIG_TOW_BOOT*options, the code is basically identical. I have verified that by taking a snapshot (new git repo) of the source tarball produced by the currentdevelopmenttip, then this PR, for the same board (pine64-pinebookA64), and looking at the diff. This is "hard" to judge properly because now all the patches are included all the time, but the changes, other than new boards and new features (unused) are minor and trivial.What was done
Ithat brokeexcept panel on reboot)What needs to be done
Out of scope of this PR
fetchFromGitHubto a repo, shared between all boards.