libreboot / lbwww (public) (License: Unspecified) (since 2023-04-11) (hash sha1)
libreboot website (markdown files). https://libreboot.org/
Clone URLs: https://rocketgit.com/user/libreboot/lbwww ssh://rocketgit@ssh.rocketgit.com/user/libreboot/lbwww git://git.rocketgit.com/user/libreboot/lbwww
25.04 master
List of commits:
Subject Hash Author Date (UTC)
update docs/maintain/ b2b2b7a95698b1591b3fa945a27aefdca60f82eb Leah Rowe 2024-05-26 14:39:50
add missing parenthese 91e4e3974aece4a24d142c1300b3d43cceacb60e sertonix 2024-05-23 18:30:45
docs/install/e6400.md: Make note of 1440x900 panel errata 222db52b57487cf1ae0503c814132c9314f091d3 Nicholas Chin 2024-05-20 17:13:07
follow-up c1c9a60e67c73d56986c40c9e0af3ce0769d3b11 Leah Rowe 2024-05-13 17:04:02
docs/hardware/dell9029: Internal Flashing is possible with original BIOS 10b6ca1f638f1d131a8c286a64fe5850b2a34a74 Ben Westover 2024-05-13 03:55:53
reddit 0a66ed0e2222040985ef0e842b6caf0c46435631 Leah Rowe 2024-05-12 19:27:23
further context 6520f681fa9e0c3db689dd53f992fbad2b275a42 Leah Rowe 2024-05-12 18:54:14
sex it up a bit 8c407d05c99a28dc3de78e4cb579fba76cf6f0fd Leah Rowe 2024-05-12 18:23:50
purists 0fb8d5d75719d4197368370942b2bac7693e6b7f Leah Rowe 2024-05-12 18:14:49
intent 061f47fd3a22b290b6f34c049938669b1bcd357f Leah Rowe 2024-05-12 18:08:52
context 8451f94036815c7ac023e5aa04a3c27b5c429b06 Leah Rowe 2024-05-12 18:07:36
actually add the canoegnu page a02fe843e6197324a316fde694a7792f65e50edc Leah Rowe 2024-05-12 18:04:40
canoegnu f671d8929475c0cce6a869e4cdff578d7b5f1a66 Leah Rowe 2024-05-12 18:02:58
updates 5d5ed3b930ef76310683b95ec7f26f9a5d48bc13 Leah Rowe 2024-05-10 04:04:10
purge remaining stragglers cb8dbd0f386b5b0a892ff05fdc03481708160e3c Leah Rowe 2024-05-07 18:44:53
extreme ditto 96e51ca06ed3cca057cc2d9aaa0c3f9de1cf9fc8 Leah Rowe 2024-05-07 16:38:45
extremely ditto 83de07b6033250c5c113fd172badb0216e88ded1 Leah Rowe 2024-05-07 16:25:34
don't promote canoeboot in release 4f992eedaa5fedb8caa3429e003e3b6da6471e5a Leah Rowe 2024-05-07 16:19:49
shorter intro ef774e2587d38f6b5e95f47d85e32bec4690126e Leah Rowe 2024-05-06 23:24:10
fix directory name 32b14145b30836c7138c90bb026b58ab3fc583a0 Leah Rowe 2024-05-04 20:13:15
Commit b2b2b7a95698b1591b3fa945a27aefdca60f82eb - update docs/maintain/
Signed-off-by: Leah Rowe <info@minifree.org>
Author: Leah Rowe
Author date (UTC): 2024-05-26 14:39
Committer name: Leah Rowe
Committer date (UTC): 2024-05-26 14:39
Parent(s): 15f0b41108069ffd71df0cb24ca9db9eba27155e
Signer:
Signing key:
Signing status: N
Tree: b2b60708a15ac39ee74f1f1db8b37afbe1a636b7
File Lines added Lines deleted
site/docs/maintain/index.md 83 208
site/tasks/index.md 15 0
File site/docs/maintain/index.md changed (mode: 100644) (index 69a1aba..34d5825)
... ... project that Libreboot imports, such as coreboot.
88 88 Environmental variables Environmental variables
89 89 ======================= =======================
90 90
91 LBMK\_THREADS
91 XBMK\_THREADS
92 92 ------------- -------------
93 93
94 94 For example: For example:
95 95
96 export LBMK_THREADS=2
96 export XBMK_THREADS=2
97 97
98 98 This would build on two threads, when running lbmk. It defaults to 1. This would build on two threads, when running lbmk. It defaults to 1.
99 99
100 100 Previous revisions of lbmk used `nproc` by default, but this was set to 1 Previous revisions of lbmk used `nproc` by default, but this was set to 1
101 101 instead, because nproc is not available on every operating system. instead, because nproc is not available on every operating system.
102 102
103 LBMK\_STATUS
104 ------------
105
106 By default, the user is asked to confirm when building for a given mainboard,
107 if that mainboard is not marked *stable* in `target.cfg`. To disable such
108 dialogs, do this:
109
110 export LBMK_STATUS=n
111
112 LBMK\_RELEASE
103 XBMK\_RELEASE
113 104 ------------- -------------
114 105
115 If set to `y`, it signals to `script/build/roms` that a release is being built,
106 If set to `y`, it signals to `script/roms` that a release is being built,
116 107 and it will honour `release="n"` in target.cfg files. You could also set this and it will honour `release="n"` in target.cfg files. You could also set this
117 108 yourself, when doing regular builds, if you wanted to test how `./build roms` yourself, when doing regular builds, if you wanted to test how `./build roms`
118 109 behaves running it in release mode. Do this if you want to: behaves running it in release mode. Do this if you want to:
119 110
120 export LBMK_RELEASE=y
121
122 This has a similar effect compared to `LBMK_STATUS="y"` but you probably don't
123 need to use this option yourself.
111 export XBMK_RELEASE=y
124 112
125 113 Projects/files downloaded/generated by lbmk Projects/files downloaded/generated by lbmk
126 114 =========================================== ===========================================
 
... ... visit: <https://doc.coreboot.org/northbridge/intel/haswell/mrc.bin.html> - the
193 181 handling of this, in Libreboot, is based largely on the information there. handling of this, in Libreboot, is based largely on the information there.
194 182
195 183 This contains the Intel MRC firmware, auto-downloaded during build This contains the Intel MRC firmware, auto-downloaded during build
196 by `script/vendor/download`.
184 by logic contained under `include/vendor.sh`.
197 185
198 186 In some cases, libre MRC firmware is also available, and provided In some cases, libre MRC firmware is also available, and provided
199 187 by Libreboot as an alternative choice. by Libreboot as an alternative choice.
 
... ... currently only initialises Intel GPUs natively, on Libreboot systems.
208 196 release/ release/
209 197 --------------- ---------------
210 198
211 The script at `script/update/release` create tarballs in here, which
199 The script at `build` create tarballs in here, which
212 200 constitute regular Libreboot releases. It is meticulously maintained, as per constitute regular Libreboot releases. It is meticulously maintained, as per
213 201 current lbmk behaviour, and executed so as to provide Libreboot release current lbmk behaviour, and executed so as to provide Libreboot release
214 202 archives. archives.
 
... ... containing non-redistributable vendor code are *scrubbed* such that these files
218 206 in regular releases, be [re-added manually](../install/ivy_has_common.md) by in regular releases, be [re-added manually](../install/ivy_has_common.md) by
219 207 the user. the user.
220 208
209 You can create release archives by doing:
210
211 ./update release
212
213 By default, this creates a release under `release/`, but you can change the
214 directory, for example:
215
216 ./update release -d path
217
218 You can also specify that only a *source archive* be created, like so:
219
220 ./update release -m src
221
222 Or with a custom directory:
223
224 ./update release -d path -m src
225
226 The build system expects there to be a *git tag*, so make sure there is one.
227 This is used to create the version number for a given release.
228
221 229 src/ src/
222 230 ---- ----
223 231
 
... ... GRUB image under `elf/grub/`.
290 298 NOTE: This is *only* provided for x86 machines, in Libreboot. For ARM, we ship NOTE: This is *only* provided for x86 machines, in Libreboot. For ARM, we ship
291 299 U-Boot instead. U-Boot instead.
292 300
293 src/me\_cleaner/
294 ---------------
295
296 Please also visit: <https://github.com/corna/me_cleaner/>
297
298 This is used by Libreboot, to *neuter* Intel ME images. The intel ME images
299 are auto-downloaded from the vendor during each build process, cached on
300 disk and processed by `me_cleaner`. It removes almost all code from Intel ME,
301 leaving only the basic bringup code (analogous to running coreboot without a
302 payload). More information available at these pages:
303
304 * <https://github.com/corna/me_cleaner/>
305 * Libreboot [freedom status page](../../freedom-status.md)
306
307 The *vendor file* scripts are what handle this, specifically the download script
308 located at `script/vendor/download`.
309
310 301 src/memtest86plus/ src/memtest86plus/
311 302 --------------- ---------------
312 303
 
... ... src/uefitool/
347 338 Please also visit: <https://github.com/LongSoft/UEFITool> Please also visit: <https://github.com/LongSoft/UEFITool>
348 339
349 340 This is compiled, so as to provide `UEFIExtract`. Currently used by the This is compiled, so as to provide `UEFIExtract`. Currently used by the
350 vendor download script at `script/vendor/download`, to download SCH5545 EC
341 vendor download logic within `include/vendor.sh`, to download SCH5545 EC
351 342 firmware (used for fan control on Dell Precision T1650). firmware (used for fan control on Dell Precision T1650).
352 343
353 344 src/pico-serprog src/pico-serprog
 
... ... desirable, `lbmk.git` provides a few utilities as part of itself, namely:
411 402 util/dell-flash-unlock/ util/dell-flash-unlock/
412 403 --------------- ---------------
413 404
414 **NOTE (15 October 2023): The util is now called `dell-flash-unlock`, but it
415 was previously called `e6400-flash-unlock`. Links have been updated.**
416
417 405 This program, written by Nicholas Chin, unlocks the boot flash on Dell Latitude This program, written by Nicholas Chin, unlocks the boot flash on Dell Latitude
418 406 E6400; it permits internal flashing, from factory firmware to Libreboot, so that E6400; it permits internal flashing, from factory firmware to Libreboot, so that
419 407 the user need not disassemble and flash externally. the user need not disassemble and flash externally.
 
... ... config/
498 486 This directory contains configuration files, used by the Libreboot build This directory contains configuration files, used by the Libreboot build
499 487 system. These next sections will cover specific configuration files. system. These next sections will cover specific configuration files.
500 488
489 config/PROJECT\*/nuke.list
490 --------------------------
491
492 The script `include/git.sh` handles deletion of certain files, for downloaded
493 projects, based on a `nuke.list` file that can (for single-tree projects) be
494 included at `config/PROJECT/nuke.list` or (multi-tree project)
495 at `config/PROJECT/TREE/nuke.list` (entries are relative links from the root
496 directory of the given source tree e.g. `src/coreboot/default/`).
497
498 So, if `src/coreboot/default/` contained foo/bar.txt, you could add to
499 the `nuke.list` file as follows:
500
501 ```
502 foo/bar.txt
503 ```
504
505 Ditto `src/flashprog/`, if you wanted to delete a file from in there, as one
506 other example. Deletions occur when the source tree is created.
507
501 508 config/vendor/ config/vendor/
502 509 --------------- ---------------
503 510
 
... ... When a given coreboot tree is compiled, for a given target, this file defines
526 533 which files to copy from the coreboot directory, which are then copied to which files to copy from the coreboot directory, which are then copied to
527 534 a location under `elf/coreboot`. a location under `elf/coreboot`.
528 535
529 The presence of this file affects behaviour in `script/update/release`;
536 The presence of this file affects behaviour in `./update release` commands;
530 537 specifically, PROJECT is then downloaded to `src/PROJECT/PROJECT`, and files specifically, PROJECT is then downloaded to `src/PROJECT/PROJECT`, and files
531 538 under `config/PROJECT/TARGET/target.cfg` define which tree to use, which then under `config/PROJECT/TARGET/target.cfg` define which tree to use, which then
532 539 looks under `config/PROJECT/TREE/target.cfg` to get the git revision; then looks under `config/PROJECT/TREE/target.cfg` to get the git revision; then
 
... ... as:
579 586 * `grub_scan_disk="ata"` * `grub_scan_disk="ata"`
580 587 * `uboot_config=default` (specify which U-Boot tree to use) * `uboot_config=default` (specify which U-Boot tree to use)
581 588 * `release="n"` (example entry) * `release="n"` (example entry)
582 * `status=stable` (example entry)
583 589 * `xtree="default"` (example entry) * `xtree="default"` (example entry)
584 590 * `tree_depend="default"` (example entry) * `tree_depend="default"` (example entry)
585 591
 
... ... on a ThinkPad X60 with the optical drive may cause GRUB to hang, so on that
633 639 machine it is advisable to set this option to `ahci` (becuse the default HDD machine it is advisable to set this option to `ahci` (becuse the default HDD
634 640 slot is AHCI). slot is AHCI).
635 641
636 The `release` variable can be set to n, which makes the `script/update/release`
637 script skip that target, when creating release images. For example, a given
642 The `release` variable can be set to n, which makes the `./update release`
643 call skip that target, when creating release images. For example, a given
638 644 board may not be stable and you don't want images for it to be included in the board may not be stable and you don't want images for it to be included in the
639 645 release. release.
640 646
641 The `status` variable can be set to whatever you want, but anything other
642 than `stable` will make `script/build/roms` ask for y/n confirmation if
643 not building images using `script/update/release`.
644
645 Recommended strings for `status` could be: `stable`, `unstable`, `broken`
646 or `untested`. Alternatively, you might state `wip`. You can set whatever
647 string you want here.
648
649 647 The `xtree` option specifies that a given tree with use a specific coreboot The `xtree` option specifies that a given tree with use a specific coreboot
650 648 tree for compiling crossgcc. This can be used to skip building gcc if OK on tree for compiling crossgcc. This can be used to skip building gcc if OK on
651 649 a given board; two trees may use the same crossgcc as each other. a given board; two trees may use the same crossgcc as each other.
 
... ... a given board; two trees may use the same crossgcc as each other.
653 651 The `tree_depend` option means that a given tree needs another tree, defined The `tree_depend` option means that a given tree needs another tree, defined
654 652 by this variable, to also be present. by this variable, to also be present.
655 653
656 ### config/coreboot/BOARDNAME/warn.txt
657
658 Additionally: the `warn.txt` file can be included alongside target.cfg, to
659 provide warning of any potential issues or quirks. For example, raminit may
660 only be reliable with certain modules. This is printed on the user's terminal
661 when building that target.
662
663 654 ### config/coreboot/BOARDNAME/config/ ### config/coreboot/BOARDNAME/config/
664 655
665 656 Files in this directory are *coreboot* configuration files. Files in this directory are *coreboot* configuration files.
 
... ... Scripts in root directory of lbmk
1071 1062 build build
1072 1063 --------------- ---------------
1073 1064
1074 This is the main script in lbmk, Libreboot's build system. It is what executes
1075 all other parts of the Libreboot build system. The rules are as follows:
1076
1077 * Argument zero, representing the name of the symlink, will be used to
1078 execute `script/LINKNAME/COMMAND` - for example: `./build roms all`
1079 would execute `script/build/roms all` in `sh`.
1080 * In the above example, `LINKNAME` could also be `vendor`. In examples below,
1081 symlinks are described pointing to `build` (the actual script). The script
1082 works by checking argument zero, so it would look in a different directory
1083 under `script/` matching `LINKNAME` - in this case, `script/vendor/`
1084 * `TMPDIR` is exclicitly set, providing a constant location where temporary
1085 files and directories can be made. `TMPDIR` is exported by the parent to
1086 all children; for example, `./build roms all` would export it
1087 to `script/build/roms`, and then anything called by *that* will also
1088 inherit it - the main parent process running `lbmk` will then clean up this
1089 `TMPDIR` directory upon any exit.
1090 * All exits from lbmk are handled by this script. *All* exits, zero or non-zero,
1091 are engineered such that *this* script, in the parent process (the very first
1092 instance) is what ultimately exits back to the user's shell prompt.
1093 * This script is programmed to *exit* with non-zero status, when run as root,
1094 unless the `./build dependencies *` commands are used,
1095 referencing files under `config/dependencies/`
1096 * Under fault conditions, each child process shall output to stderr, and the
1097 main parent process running `lbmk` will output the final error message.
1098
1099 tl;dr break this script and you *break Libreboot*.
1100
1101 update
1102 ---------------
1065 This is the main script. Symlinks `vendor` and `update` also point to it.
1103 1066
1104 Symbolic link, pointing to the `build` script. This is executed by the user, or
1105 by lbmk, referencing scripts under `script/update/`.
1067 Take any given file under `script/` and you can do:
1106 1068
1107 vendor
1108 ---------------
1069 ./build file # (THIS IS NOT A VALID COMMAND)
1070
1071 For example:
1072
1073 ./build roms
1074 ./update trees
1075
1076 Special commands available (not provided by files under `script/`):
1077
1078 ./update release
1079 ./vendor download
1080 ./vendor inject
1109 1081
1110 Symbolic link, pointing to the `build` script. This is executed by the user, or
1111 by lbmk, referincing scripts under `script/vendor/`
1082 The `vendor` commands are handled by the `build` script, calling functions
1083 inside `include/vendor.sh`, and the `./update release` logic is handled
1084 directly by the `build` script.
1085
1086 More information about `./vendor` commands can be found
1087 here: [inserting vendor files](../install/ivy_has_internal.md)
1088
1089 Information about `./update release` is written elsewhere on this page.
1090
1091 You can also know what build system revision you have by running:
1092
1093 ./build version
1094
1095 This script is the beating heart of Libreboot. Break it and you break Libreboot.
1112 1096
1113 1097 include/ include/
1114 1098 =============== ===============
 
... ... it is provided as an include to bypass license incompatibility. It has been
1143 1127 heavily modified to use the same style of logic and general control flow used heavily modified to use the same style of logic and general control flow used
1144 1128 in the script at `script/vendor/download`, and it is used from there. in the script at `script/vendor/download`, and it is used from there.
1145 1129
1146 include/option.sh
1130 include/lib.sh
1147 1131 --------------- ---------------
1148 1132
1149 Functions used by scripts under `script/vendor/`, for checking defconfig
1150 files. These files are checked because the scripts need to know whether a given
1151 file is used; if it is, a path is then specified in defconfig, telling the vendor
1152 script either where it is, or where it should be downloaded to.
1153
1154 1133 Several other parts of lbmk also use this file. It is added to as little as Several other parts of lbmk also use this file. It is added to as little as
1155 1134 possible, and contains miscallaneous functions that don't belong anywhere else. possible, and contains miscallaneous functions that don't belong anywhere else.
1156 1135
 
... ... return an error state.
1171 1150 script/ script/
1172 1151 ======= =======
1173 1152
1174 *All* scripts under `script/` are executed only by the main `lbmk` script,
1175 conforming to the standard `buildpath/option` e.g. `build/roms` - so,
1176 running `./build roms` would run `script/build/roms`.
1177
1178 script/build/
1179 ---------------
1180
1181 These are highly specialised build scripts, written for specific tasks, almost
1182 entirely in the context of building firmware images themselves, but some utils
1183 are also handled.
1184
1185 The scripts that create release archives are also located under this directory.
1186
1187 ### script/build/roms
1153 script/roms
1154 -----------
1188 1155
1189 1156 This builds coreboot ROM images. This builds coreboot ROM images.
1190 1157
 
... ... It creates ROM images with GRUB, SeaBIOS, U-Boot, optionally with Memtest86+
1226 1193 also included, in various separate configurations in many different ROM images also included, in various separate configurations in many different ROM images
1227 1194 for user installation. for user installation.
1228 1195
1229 The `romtype` entry in `target.cfg` tells this script what to do with the ROM,
1230 after it has been built. Currently, it operates based on these possible values
1231 for `romtype`:
1232
1233 * `d8d16sas` will cause *fake* (empty) files named `pci1000,0072.rom`
1234 and `pci1000,3050.rom` to be inserted in CBFS. This prevents SeaBIOS from
1235 loading or executing the option ROM stored on PIKE2008 modules, present on
1236 certain configurations with the ASUS KCMA-D8 or KGPE-D16 mainboards. Those
1237 option ROMs cause the system to hang, so they should never be executed (this
1238 means however that booting Linux kernels from SAS devices is impossible on
1239 those boards, unless a Linux payload is used; Linux can use those SAS drives,
1240 without relying on the PIKE2008 option ROMs). When SeaBIOS runs, it will
1241 default to loading the corresponding option ROM from CBFS, if it exists, for
1242 a given PCI device, overriding whatever option ROM is present on the device
1243 itself, but if the option ROM is invalid/empty, SeaBIOS will not attempt to
1244 load another one, until the empty/invalid one (in CBFS) is deleted.
1245 * `i945 laptop`: in this configuration, the upper 64KB section of the ROM is
1246 copied into the 64KB section below that. This results in there being two
1247 bootblocks in the ROM, and you can decide which one is used by setting `bucts`
1248 * If no declaration is made, or a declaration is made contrary to the above,
1249 no special modifications will be made.
1250
1251 1196 If no payload is defined in `target.cfg`, the `build/roms` script will exit If no payload is defined in `target.cfg`, the `build/roms` script will exit
1252 1197 with error status. with error status.
1253 1198
 
... ... The `list` argument is available:
1293 1238 Without arguments, all targets would be compiled, but you can specify a short Without arguments, all targets would be compiled, but you can specify a short
1294 1239 list of targets instead, based on the output of `list`. list of targets instead, based on the output of `list`.
1295 1240
1296 script/update/
1297 --------------
1298
1299 This handles most actual building of source trees, called into by scripts
1300 under `script/build/fw` - it also contains logic for downloading source trees
1301 or vendor files.
1302
1303 ### script/update/release
1304
1305 This script builds the release archives, which are then provided in a new
1306 Libreboot release. Most users do not need to look at this file at all, but it
1307 is provided under free license for curious souls.
1308
1309 Command: `./update release`
1310
1311 NOTE: if the `-d` option is used, you can specify a directory other
1312 than `release`. For example:
1313
1314 ./update release -d /media/stuff/libreboot_release_test
1315
1316 If `-d` is not passed, they will go under `release/` in your lbmk repository.
1317 The script is engineered to re-initialise git if ran from a release archive.
1318 Libreboot releases after 20230625 include `.gitignore` in the src archive.
1319
1320 This builds release archives, containing ROM images for coreboot and/or serprog
1321 programmers. It works simply: lbmk clones *itself*, and builds itself in its
1322 clone, then cleans itself up and creates tarballs. If you run this script, you
1323 should expect it to take at least 4 hours; slower on really old systems. On
1324 really fast systems, it might take 2-3 hours.
1325
1326 NOTE: This script *scrubs* certain vendor firmware from release ROMs, such as
1327 Intel ME or MRC firmware. The release ROMs shall then exclude these files
1328 within them, requiring manual insertion by the user post-release. See:
1329
1330 [Insert vendor files
1331 on Sandybridge/Ivybridge/Haswell](../install/ivy_has_common.md)
1332
1333 ### script/update/trees
1241 script/trees
1242 ------------
1334 1243
1335 1244 *This* is the other beating heart of Libreboot. Used heavily by Libreboot, this *This* is the other beating heart of Libreboot. Used heavily by Libreboot, this
1336 1245 script is what handles defconfig files for SeaBIOS, U-Boot *and* coreboot; it script is what handles defconfig files for SeaBIOS, U-Boot *and* coreboot; it
 
... ... All of this used to about 20 different scripts, all with much-duplicated logic.
1450 1359 Now it is unified, efficiently, under a single script. Now it is unified, efficiently, under a single script.
1451 1360
1452 1361 Remember: code equals bugs, so less code equals fewer bugs. Remember: code equals bugs, so less code equals fewer bugs.
1453
1454 script/vendor/
1455 --------------
1456
1457 ### script/vendor/download
1458
1459 This downloads vendor code when needed, on a given coreboot target. It does
1460 this by scanning the defconfig files of that board, to know where the files
1461 are (or where they should be) within lbmk. Based on this, it then knows which
1462 files to download.
1463
1464 These files are then inserted at build time by the coreboot build system (as
1465 defined by defconfigs), or post-release by running the `inject` script.
1466
1467 It looks inside `config/vendor/` at the files in there, concatenating them and
1468 then scanning that to find info about the given board; for example, info like
1469 where to download a Lenovo BIOS updater to extract `me.bin` from, to run through
1470 the `me_cleaner` program.
1471
1472 More information is available [here](../install/ivy_has_common.md).
1473
1474 This script is executed automatically, when you compile ROM images, if the given
1475 mainboard requires vendor code to be inserted. In this way, you do not need to
1476 manually extract such files from your original vendor image.
1477
1478 ### script/vendor/inject
1479
1480 This is not used during the build process, but it can be run by the user on
1481 release ROMs (which do not contain non-redistributable code handled by these
1482 vendor scripts, even if they are required). This script inserts those files
1483 into the coreboot ROM image; if you're building from source, using lbmk, you
1484 do not need to run the inject script at all.
1485
1486 More information is available [here](../install/ivy_has_common.md).
File site/tasks/index.md changed (mode: 100644) (index 8c31704..891bd8c)
... ... ec hacking on lenovo x230
2214 2214 ========================= =========================
2215 2215
2216 2216 <https://zmatt.net/unlocking-my-lenovo-laptop-part-2/> <https://zmatt.net/unlocking-my-lenovo-laptop-part-2/>
2217
2218 DELL 7th gen
2219 ============
2220
2221
2222 3050 micro is being worked on.
2223
2224 3050 sff and mt are TODO
2225
2226 5050 models also.
2227
2228 Dell 3020
2229 =========
2230
2231 another haswell. different to 9020, but could be added.
Hints:
Before first commit, do not forget to setup your git environment:
git config --global user.name "your_name_here"
git config --global user.email "your@email_here"

Clone this repository using HTTP(S):
git clone https://rocketgit.com/user/libreboot/lbwww

Clone this repository using ssh (do not forget to upload a key first):
git clone ssh://rocketgit@ssh.rocketgit.com/user/libreboot/lbwww

Clone this repository using git:
git clone git://git.rocketgit.com/user/libreboot/lbwww

You are allowed to anonymously push to this repository.
This means that your pushed commits will automatically be transformed into a merge request:
... clone the repository ...
... make some changes and some commits ...
git push origin main