An opinionated distribution of U-Boot. — https://matrix.to/#/#Tow-Boot:matrix.org?via=matrix.org
As you may have guessed, the same personal circumstances affected this development cycle too. Read more in the previous announcement.
A part of the changes were made to help future proof releases, by reducing the direct involvement required from any particular individual.
See also the milestone and git history:
libreComputer-amlS905xCc (#213)orangePi-pc2 (#229)libreComputer-allH3CcH5 @shvetsnikita (#256)friendlyElec-nanoPiM1 @shvetsnikita (#257)friendlyElec-nanoPiM1Plus @shvetsnikita (#275)Some of the dependencies have been updated:
With initial help from @jirutka, Tow-Boot changes are now built automatically using GitHub Actions.
These builds are the ones being uploaded to the release tag, removing one manual operation from the release workflow.
Tow-Boot changes on top of U-Boot are now tracked as branches in a repository.
This removes all the patches from the main Tow-Boot repository. This also ensures none of the patch conflict in unintended ways, as they are now always applied.
With these changes, it is also now possible to test against a stock U-Boot using the same build tooling. This is mainly useful to verify whether or not our changes to U-Boot are causing observed issues.
uSWID data is now generated and appended to out platform firmware binaries.
At this current point in time, it is not used by Tow-Boot or any of its tooling.
It does, however, hash the full build inputs information through using the $out path of the derivation as part of the tag-id value.
Rockchip devices now support powering off from U-Boot (and thus UEFI) properly.
Sometimes it happens that contributions can't be used, be it because they were superseded by something else, implemented differently, or unneeded past an update.
The linked PRs should include the actual resolution in use in the comments.
Here's those that I think deserve a mention:
Since U-Boot changes are now independently tracked the release notes are too.
I'm probably missing some notable changes here. Though I think mainly they were cleanups to either make them more upstreamable, or work better in a unified tree.
See also the tag commit for a complete overview of the changes compared to U-Boot:
I won't go into the details of what happened, but note that I am looking into future-proofing the project such that a long hiatus like that will not depend on a single individual. Read more in a small announcement I shared previously in the matrix room.
A few months late, this update syncs Tow-Boot with version 2022.07 of U-Boot.
See also the milestone and git history:
Amlogic
Pinephone Pro
Sometimes it happens that contributions can't be used, be it because they were superseded by something else, implemented differently, or unneeded past an update.
The linked PRs should include the actual resolution in use in the comments.
Here's those that I think deserve a mention:
That's pretty much it.
If you're not booting your operating system via UEFI, there is no need to upgrade.
Time was scarce to do what I expected to do for this release, and even then I ended up releasing way late.
This release improves device information made available through SMBIOS tables. This data is available when the Operating System is booted through UEFI, and before would often present the fallback data.
So instead of having the system advertise their identity as Unknown Product made by Unknown, the system will show useful information.
This information will either be the platform-specific information added to the driver, like in #135 by @MartijnBraam. Some systems in upstream U-Boot already provide that information, and it will be preferred.
Since it would be preferable to always have useful information, fallback information is now taken from the Tow-Boot knowledge of the current build #158 when the system does not include data. The upstream data is preferred as it improves compatibility with non Tow-Boot implementations.
In platform-specific changes, The ODROID-N2+ support was improved with support for its XT25Q64D SPI Flash chip #149, by @ulrikstrid.
See also other documentation fixes and minor fixes, listed in the milestone:
Thank you @CRTified, @MartijnBraam, @ulrikstrid, @flokli, and @tpwrules for the contributions.
All of this:
But here's some highlights
With #67, we now build Tow-Boot with a user experience optimized for phones, while supporting the use case of phones without display enablement in U-Boot.
These builds should enable users to live the dream of EBBR but on their phones.
#78 is more for Tow-Boot developers. It changes from an ad-hoc functional build pipeline, which was getting hard to maintain, to a build system building on top of the modules system used also by NixOS.
This provides better semantics for the developers, reducing needless repetitions.
With the -003 release, a form of regression slipped through that changed the boot order of some boards. When fixing the regression, it was observed that there was less consistency than assumed in the boot order.
Boot order has been reviewed with #92, and verified to be consistent across platforms. Internal storage devices are preferred to external devices.
pine64-pinephoneA64
pine64-pinephonePro
radxa-zero2
radxa-RockPi4 (A/B) (Thank you @CRTified)Hello! :wave:
Not a lot of changes. Dependencies updates, and two new boards.
I'm still marking this as a pre-release, under the same caveats as previously described. Mainly that this is probably fine for daily use, but lacking mainly in documentation. After all, the main changes here are version upgrade in dependencies, no behaviour should differ.
(Just in time to be outdated? Yeah, just over a week after the release of U-Boot 2022.01!)
odroid-N2 (Thank you @L-as)radxa-RockPi4C (Tank you @CRTified)This is a simple upgrade, changes have been rebased on top of 2021.10. I don't know if there's anything to be truly excited about.
There are regressions upstream for RK3399 boards and eMMC, but they all have been taken care of using already upstreamed or being-upstreamed changes.
A simple upgrade, yet again.
The suspend patch for the Pinebook Pro has been dropped, as it was mainlined.
Hi!
I was surprised by some uses of Tow-Boot outside of the initial soft launch circle! But it's not like it's a problem or anything, the reception was good :).
I'm making what should have been "soft launch release 2", which is mainly bug fixes, and some improvements. I still haven't taken the time to look into making the life easier for non-Nix users, which was the main goal for the actual next "less soft" launch.
Anyway, here's what's in this release.
With #34, we are now producing distinct builds for SPI installation, and shared storage. These variants have one major distinction: the SPI build saves the environment to the SPI Flash, while the other (noenv) does not allow saving the environment. Note that in a future update, saving the environment will be added as a feature for shared storage installations.
SPI Flashing has been improved in #36. Some hardening steps have been added, mainly to ensure that in the event of a stray reset, the SPI Flash would not be used as a boot option during the boot process. This should reduce most risks in updating the SPI Flash contents. Additionally, the installer now verifies it is installing to the right board.
A website is now produced from the documentation. (#40)
With #22, we are now providing all patches, in addition to the configuration, used to build the released binaries. This means that a user should be able to "rehydrate" a working tree on top of the correct U-Boot version and build the equivalent product. Helps show the recipe to the secret sauce!
Support was added for a new board the Olimex Teres-I in #26, by @Thra11.
In Tow-Boot 001, there was no validation for the board when installing or upgrading the SPI Flash.
With the update to 002, changes in #36, upgrading now checks for $board_identifier, which will be unset on Tow-Boot 001.
On some platforms it is not an issue. E.g. on Allwinner A64, the Boot ROM firmware load order starts with SD, so it should use the firmware from the SD card, which will have the appropriate identifier.
On many other platforms, e.g. amlogic and rockchip, this is not the case.
The workaround is to run env default board_identifier from the firmware console before updating. Another workaround would be to completely erase the SPI Flash, which does not validate the board identifier. Then rebooting and installing should work. Neither option is better than the other, pick the one you prefer.
The file naming scheme has changed. All boards now produce artifacts with approximately the same names. This is not really a breaking change, but really more something to be aware of for external instructions. (#34)
If any builds were using the environment, e.g. from FAT32, EXT4, or SPI, it is almost definitive that with this release it will either not work anymore (for shared storage installations) or the environment will be lost this upgrade for SPI installations. This is by design, first to reduce confusion from stray environments left by other U-Boot installs, and second, to reduce confusion about the provenance of the environment. (#34)
With this release, all boards use the 115200 serial baud rate. Nothing needs to be done on your device. Just be aware when using a serial connection. (#33)
Built using
$ env -i nix-build release.nix
001 may be problematic on platforms that did not have setexpr enabled in 001. (#45)