summaryrefslogtreecommitdiff
path: root/config/submodule
AgeCommit message (Collapse)Author
2024-06-12coreboot nasm: use coreboot mirror as backupLeah Rowe
don't use the macports mirror, because it's not certain whether those tarballs will always be there. use the coreboot one as a backup instead, and nasm.us as main Signed-off-by: Leah Rowe <leah@libreboot.org>
2024-06-12grub: only enable nvme if needed on a boardLeah Rowe
remove nvme support from the "default" grub tree now there are three trees: * default: no xhci or nvme patches * nvme: contains nvme support * xhci: contains xhci and nvme support this is in case a bug like lbmk issue #216 ever occurs again, as referenced before during lbmk audit 5 there is no indication that the nvme patch causes any issues, but after previous experience i want to be sure Signed-off-by: Leah Rowe <leah@libreboot.org>
2024-06-11fix nasm download path for coreboot/fam15hLeah Rowe
Signed-off-by: Leah Rowe <leah@libreboot.org>
2024-06-09add crossgcc tarballs to config/submodules/Leah Rowe
support redundant downloads, and enable inclusion of these tarballs inside release archives, for offline builds. Signed-off-by: Leah Rowe <leah@libreboot.org>
2024-06-08git.sh: support downloading *files* as submodulesLeah Rowe
when we download coreboot, we currently don't have a way to download crossgcc tarballs, so we rely on coreboot to do it, which means running the coreboot build system to do it; which means we don't get them in release archives, unless we add very hacky logic (which did exist and was removed). the problem with coreboot's build system is that it does not define backup links for each given tarball, instead relying on gnu.org exclusively, which seems OK at first because the gnu.org links actually return an HTTP 302 response leading to a random mirror, HOWEVER: the gnu.org 302 redirect often fails, and the download fails, causing an error. a mitigation for this has been to patch the coreboot build system to download directly from a single mirror that is reliable (in our case mirrorservice.org). while this mitigation mostly works, it's not redundant; the kent mirror is occasionally down too, and again we still have the problem of not being able to cleanly provide crossgcc tarballs inside release archives. do it in config/submodules, like so: module.list shall say the relative path of a given file, once downloaded, relative to the given source tree. module.cfg shall be re-used, in the same way as for git submodules, but: subfile="url" subfile_bkup="backup url" do this, instead of: subrepo="url" subrepo_bkup="backup url" example entries in module.list: util/crossgcc/tarballs/binutils-2.41.tar.xz util/crossgcc/tarballs/gcc-13.2.0.tar.xz util/crossgcc/tarballs/gmp-6.3.0.tar.xz util/crossgcc/tarballs/mpc-1.3.1.tar.gz util/crossgcc/tarballs/mpfr-4.2.1.tar.xz util/crossgcc/tarballs/nasm-2.16.01.tar.bz2 util/crossgcc/tarballs/R06_28_23.tar.gz the "subrev" variable (in module.cfg) has been renamed to "subhash", so that this makes sense, and that name is common to both subfile/subrepo. the download logic from the vendor scripts has been re-used for this purpose, and it verifies files using sha512sum. therefore: when specifying subrepo(git submodule), subhash will still be a sha1 checksum, but: when specifying subfile(file, e.g. tarball), subhash will be a sha512 checksum the logic for both (subrepo and subfile) is unified, and has this rule: subrepo* and subfile* must never *both* be declared. the actual configuration of coreboot crossgcc tarballs will be done in a follow-up commit. this commit simply modifies the code to accomodate this. over time, this feature could be used for many other files within source trees, and could perhaps be expanded to allow extracting source tarballs in leiu of git repositories, but the latter is not yet required and thus not implemented. Signed-off-by: Leah Rowe <leah@libreboot.org>
2024-06-07define mdfiles/images in config/submodules/docs/Leah Rowe
again: the "depend" variable must never be used for subprojects that point to a subdirectory of the main project, because there's no clean way of handling this in case of error conditions. make it a submodule under config/submodules/. this is for the documentation, including static site generator documentation, and image files (photos). as of this revision, there are now only those "depend" projects defined in config/git/, where the destination directory of the subject is not a subdirectory of the main project, so: in a subsequest revision, i will mitigate an existing bug whereby failure of the dependency project leaves the main one still intact, breaking builds; this revision enables that to be done. from now on, subproject-to-subdirectory-of-main-project will be avoided in config/git/; config/submodules/ will be used. Signed-off-by: Leah Rowe <leah@libreboot.org>
2024-06-07libopencm3 to config/submodules/ on stm32-vserprogLeah Rowe
same as the previous patch, we must no longer use "define" variables in config/git/ when the path is a subdirectory of a given project, because it means that the download can only happen after the main one, and currently if that fails, the download of the main repo would remain intact, breaking future builds in ways that we can't control - to be clear, it could be controlled, but with added code complexity in the build system, so: put it in config/submodules/ Signed-off-by: Leah Rowe <leah@libreboot.org>
2024-06-07add tinyusb to config/submodule/ for pico-sdkLeah Rowe
don't define it as a "depend" variable in config/git/, because it means putting the files in a subdirectory of an existing project was was already then downloaded, and that means it can't be downloaded first; if the download of it fails, the old download is left intact. this bug isn't currently fixed in the build system, at all, so this and other patches are being made to mitigate it. Signed-off-by: Leah Rowe <leah@libreboot.org>
2024-06-02make GRUB multi-tree and re-add xhci patchesLeah Rowe
Re-add xHCI only on haswell and broadwell machines, where they are needed. Otherwise, keep the same GRUB code. The xHCI patches were removed because they caused issues on Sandybridge-based Dell Latitude laptops. See: https://codeberg.org/libreboot/lbmk/issues/216 The issue was not reported elsewhere, including on the Haswell/Broadwell hardware where they are needed, but the build system could only build one version of GRUB. The older machines do not need xHCI patches, because they either do not have xHCI patches, or work (in GRUB) because they're in EHCI mode when running the payload. So, the problem is that we need the xHCI patches for GRUB on Haswell/Broadwell hardware, but the patches break Sandybridge hardware, and we only had the one build of GRUB. To mitigate this problem, the build system now supports building multiple revisions of GRUB, with different patches, and each given coreboot target can say which GRUB tree to use by setting this in target.cfg: grubtree="xhci" In the above example, the "xhci" tree would be used. Some generic GRUB config has been moved to config/data/grub/ and config/grub/ now looks like config/coreboot/ - also, the grub.cfg file (named "payload" in each tree) is copied to the GRUB source tree as ".config", then added to GRUB's memdisk in the same way, as grub.cfg. Several other design changes had to be made because of this: * grub.cfg in memdisk no longer automatically jumps to one in CBFS, but now shows a menuentry for it if available * Certain commands in script/trees are disabled for GRUB, such as *config make commands. * gnulib is now defined in config/submodule/grub/, instead of config/git/grub - and this mitigates an existing bug where downloading gnulib first would make grub no longer possible to download in lbmk. The coreboot option CONFIG_FINALIZE_USB_ROUTE_XHCI has been re-enabled on: Dell OptiPlex 9020 MT, Dell OptiPlex 9020 SFF, Lenovo ThinkPad T440p and Lenovo ThinkPad W541 - now USB should work again in GRUB. The GRUB payload has been re-enabled on HP EliteBook 820 G2. This change will enable per-board GRUB optimisation in the future. For example, we hardcode what partitions and LVMs GRUB scans because * is slow on ICH7-based machines, due to GRUB's design. On other machines, * is reasonably fast, for automatically enumerating the list of devices for boot. Use of * (and other wildcards) could enable our GRUB payload to automatically boot more distros, with minimal fuss. This can be done at a later date, in subsequent revisions. Signed-off-by: Leah Rowe <leah@libreboot.org>
2024-05-30Fix building vboot on i686Luke T. Shumaker
2024-05-24config: add backup coreboot submodule repositoriesLeah Rowe
this is using the same functionality that was added a few commits ago, to override the use of "git submodule update" each coreboot submodule has two repositories defined, with the second one kicking in if the mail one fails upon cloning. Signed-off-by: Leah Rowe <leah@libreboot.org>
2024-05-24coreboot/default: remove chromeec from module.listLeah Rowe
Signed-off-by: Leah Rowe <leah@libreboot.org>
2024-05-24coreboot: only download the necessary submodulesLeah Rowe
whitelist what modules are downloaded, by adding module.list files in the corresponding directories under config/submodule/, per each coreboot tree. this is making use of functionality added in the previous commit. Signed-off-by: Leah Rowe <leah@libreboot.org>
2024-05-21Fix E6400 display reference clock patchesNicholas Chin
The ones I submitted before seem to have been outdated ones that don't actually build properly. Signed-off-by: Nicholas Chin <nic.c3.14@gmail.com>
2024-05-21fix building coreboot images on i686 hostsLeah Rowe
firstly, memtest86+ is currently not cross compiled and relies on 64-bit headers (x86_64 only). a 32-bit distro is unlikely to be able to build 64-bit binaries. secondly: vboot throws a build error due to -Werror when building on 32-bit hosts. we rely on vboot code to build cbfstool, so turn off -Werror on vboot that's all. 32-bit hosts are not recommended; it is assumed that you are building on an x86_64 host. work will go into the build system at a later date to make it more portable, by cross compiling everything, but this should fix 32-bit for now. there are some x60/t60 users who still want to build roms, so let's allow them that possibility. Signed-off-by: Leah Rowe <leah@libreboot.org>
2024-05-20Fix E6400 display issue with 1440 x 900 panelNicholas Chin
The E6400 uses a 100 MHz reference clock on DPLL_REF_SSCLK, whereas libgfxinit assumed that the reference was always 96 MHz. The frequency difference caused by a 100 MHz reference with PLL config values calculated assuming a 96 MHz reference were not significant enough to cause noticable issues with the more common 1280 x 800 panels, but are enough to matter for the 1440 x 900 panels which use a higher pixel clock. This only affected the pre-OS graphics environment provided by libgfxinit, as Linux drivers would determine the reference clock frequency based on data in the VBT. Fix this by making the reference clock frequency in libgfxinit configurable for GM45 based on a new coreboot Kconfig, which is set to 100 MHz for the E6400. Signed-off-by: Nicholas Chin <nic.c3.14@gmail.com>
2024-05-20git.sh: allow patching submodulesLeah Rowe
for single-tree project (e.g. flashprog): config/submodule/PROJECT/MODNAME/patches for multi-tree project (e.g. coreboot): config/submodule/PROJECT/TREE/MODNAME/patches MODNAME is e.g.: 3rdparty/vboot directory in coreboot: would become vboot (the submodule codepath is filtered to up to the final slash) another example: submodire src dir 3rdparty/foo/bar MODNAME would be "bar" Add whatever patches you like to a given submodule. An example patch is included in this commit. Signed-off-by: Leah Rowe <leah@libreboot.org>