Set default U-Boot revision to v2023.01 and rebase patches on top of that. Upstream kconfig status is a bit unstable, so updating configs with `make oldconfig` would miss important upstream changes. For each board, run `make savedefconfig` and `diffconfig -m` at the old version to get a diff from upstream defconfigs. Fix those affected by upstream changes, like SYS_TEXT_BASE being renamed to TEXT_BASE. Then append those to the new version's defconfigs and run `make olddefconfig` to get updated configs. Signed-off-by: Alper Nebi Yasak <alpernebiyasak@gmail.com>
Add a series posted to upstream mailing lists that makes the GRUB text-mode console faster by implementing video damage tracking [1]. Refresh the config files to include its new VIDEO_DAMAGE Kconfig. Patch 7/7 upstream has a tiny conflict with "Improve UEFI experience" series we already have, but it's only in the diff context. No changes other than fixing that. [1] https://lore.kernel.org/u-boot/20220609225921.62462-1-agraf@csgraf.de/ Signed-off-by: Alper Nebi Yasak <alpernebiyasak@gmail.com>
Set revision to the commit hash of the v2022.10 release, and run "make olddefconfig" for all boards to refresh the configs. Signed-off-by: Alper Nebi Yasak <alpernebiyasak@gmail.com>
Merge all boards into a common "default" tree, currently for v2022.07. This ends up applying the "Improve UEFI experience on DM_VIDEO" series to everything, so refresh the configs for the new options. Signed-off-by: Alper Nebi Yasak <alpernebiyasak@gmail.com>
osboot is now part of libreboot, and will soon shut down. libreboot now conforms to osboot policy.
Boards may want to specify a board-specific U-Boot revision. At the very least, pseudo-boards for u-boot-libre releases will need to specify their U-Boot versions somehow. Copy the existing mechanism from download/coreboot for specifying build info with board.cfg files. Specify the commit hash for the 'v2021.07' pseudo-board, and 'master' as the default. Signed-off-by: Alper Nebi Yasak <alpernebiyasak@gmail.com>
This firmware lack corresponding source code. Signed-off-by: Denis 'GNUtoo' Carikli <GNUtoo@cyberdimension.org>
Once the tarball are released, it will enable distributions to use these tarballs to produce deblobbed u-boot packages. Note that the produced tarball is not reproducible yet. Because of that it has to be trusted. During a release, it's a good idea to sign the uncompressed tarball as the various compression formats and associated tools make different tradeoffs. For instance with xz, xz -9e tends to compress really well with the the most used xz[1] implementation, and most GNU/Linux users probably already have it installed, but and the drawbacks is that the format is very fragile[2]. The lzip format is more suited for long term archiving but its most packaged implementation[3] is less likely to be already installed by users than more well known formats like xz, bzip2 or gzip. Being able to add more compression formats after the release is also useful, for instance to accommodate different build systems or use cases (like being able to build u-boot with less dependencies in distributions like Guix, or building u-boot directly on devices which don't have enough RAM for xz for instance). [1]https://tukaani.org/xz/ [2]https://www.nongnu.org/lzip/xz_inadequate.html [3]https://www.nongnu.org/lzip/ Signed-off-by: Denis 'GNUtoo' Carikli <GNUtoo@cyberdimension.org>