lbmk.git/config/ifd/xx30, branch 25.04_branch libreboot build system (LibreBoot MaKe) restore old x230 gbe file 2025-01-29T04:17:07+00:00 Leah Rowe leah@libreboot.org 2025-01-29T04:17:07+00:00 6b9cf09ca21987363ad11b8396aa4a9ba19a6ee3 i accidentally committed one where i'd changed the mac address, on a previous revision to nvmutil Signed-off-by: Leah Rowe <leah@libreboot.org> 
i accidentally committed one where i'd changed
the mac address, on a previous revision to nvmutil

Signed-off-by: Leah Rowe <leah@libreboot.org>
util/nvmutil: Only read up to 4KB on larger gbe 2025-01-29T03:41:55+00:00 Leah Rowe leah@libreboot.org 2025-01-29T03:41:55+00:00 b1d8975959dc942bb8691253f3599e4ac99932eb On the 16KB and 128KB files, we still only need to operate on 4KB at the start of each block, where the block size is larger than 4KB. The reason we deal with the entire 4KB block is because the nvm words (in the 128 byte section) can define an extended nvm area anywhere after 128 bytes, within the 128 byte block. We could systematically read where that is being handled, and handle it; we could then allocate less memory, and read/write fewer bytes, but many block devices like SSDs and flash drives have at least a 4KB erase block anyway, so it's kinda pointless. saving memory would be nice, but I don't really want to bloat the code. This is a nice easy optimisation, to avoid wasting an additional 8KB of memory when handling 16KB files, and additional 120KB if handling 128KB files, since nf is what determines how much memory will be allocated. the alternative would be to use an mmap, and then we could reasonably handle the idea above for only writing, surgically, what we need: nvm words and extended nvm words. Signed-off-by: Leah Rowe <leah@libreboot.org> 
On the 16KB and 128KB files, we still only need to
operate on 4KB at the start of each block, where the
block size is larger than 4KB.

The reason we deal with the entire 4KB block is because
the nvm words (in the 128 byte section) can define an
extended nvm area anywhere after 128 bytes, within the
128 byte block.

We could systematically read where that is being handled,
and handle it; we could then allocate less memory, and
read/write fewer bytes, but many block devices like SSDs
and flash drives have at least a 4KB erase block anyway,
so it's kinda pointless. saving memory would be nice, but
I don't really want to bloat the code.

This is a nice easy optimisation, to avoid wasting an
additional 8KB of memory when handling 16KB files, and
additional 120KB if handling 128KB files, since nf is
what determines how much memory will be allocated.

the alternative would be to use an mmap, and then we
could reasonably handle the idea above for only writing,
surgically, what we need: nvm words and extended nvm
words.

Signed-off-by: Leah Rowe <leah@libreboot.org>
config/ifd/xx30: Fix 16_ifd component density and count 2023-12-21T04:27:44+00:00 Nicholas Chin nic.c3.14@gmail.com 2023-12-21T01:13:54+00:00 dbec5bf3f8d0c7ad96c782001ebfa352285300b1 The component 1 and 2 densities were still set to 8 MiB and 4 MiB respectively, which is incorrect for 16 MiB only configurations. Change the component 1 density to 16 MiB so that the address space gets properly mapped to SPI 1. In addition, change the number of components field (byte 0x15) to 0x00 to indicate 1 flash chip. Signed-off-by: Nicholas Chin <nic.c3.14@gmail.com> 
The component 1 and 2 densities were still set to 8 MiB and 4 MiB
respectively, which is incorrect for 16 MiB only configurations.
Change the component 1 density to 16 MiB so that the address space
gets properly mapped to SPI 1. In addition, change the number of
components field (byte 0x15) to 0x00 to indicate 1 flash chip.

Signed-off-by: Nicholas Chin <nic.c3.14@gmail.com>
move ifd/gbe configs into config/ifd/ 2023-09-04T00:38:08+00:00 Leah Rowe leah@libreboot.org 2023-09-04T00:17:23+00:00 03788d14fb0dd79b38817d5a40f1c5c2017f4551 it doesn't really make sense for them to be under blobs/ - nominally, they are blobs, but they are well-understood data files containing config data, that is easily parsed by tools like ich9show or ifdtool (and tools like bincfg or nvmutil) blobs/ has been re-purposed: this directory no longer exists in lbmk, but it is created (and on .gitignore) when needed, by blobutil thus, the blobs/ directory shall only contain vendor files, and only those files that libreboot scrubs from releases. therefore, build/release/src can (and has been) simplified; it currently copies just the ifd and gbe files from blobs/, selectively, and this logic is quite error prone, requiring maintenance. now, the build/release/src script simply copies config/ (which only ever contains distributable files) and entirely ignores the blobs/ directory the blob download script already creates the required directory, except for the sch5545 download; this is now fixed lbmk code size is slightly smaller, due to this patch Signed-off-by: Leah Rowe <leah@libreboot.org> 
it doesn't really make sense for them to be under
blobs/ - nominally, they are blobs, but they are
well-understood data files containing config data,
that is easily parsed by tools like ich9show or
ifdtool (and tools like bincfg or nvmutil)

blobs/ has been re-purposed: this directory no longer
exists in lbmk, but it is created (and on .gitignore)
when needed, by blobutil

thus, the blobs/ directory shall only contain vendor
files, and only those files that libreboot scrubs from
releases. therefore, build/release/src can (and has
been) simplified; it currently copies just the ifd and
gbe files from blobs/, selectively, and this logic is
quite error prone, requiring maintenance. now, the
build/release/src script simply copies config/ (which
only ever contains distributable files) and entirely
ignores the blobs/ directory

the blob download script already creates the required
directory, except for the sch5545 download; this is
now fixed

lbmk code size is slightly smaller, due to this patch

Signed-off-by: Leah Rowe <leah@libreboot.org>