i accidentally picked an older version from Dell update A16. this update uses A29. Signed-off-by: Leah Rowe <leah@libreboot.org>
Thank you Iru Cai for this coreboot port. Signed-off-by: Leah Rowe <leah@libreboot.org>
Yes. Thank you Johann C. Rode for this excellent coreboot port. You're a star. Signed-off-by: Leah Rowe <leah@libreboot.org>
theu current comment is for an old version of the n150 patch, before it was actually merged. the comment has been adjusted, to match the actual implementation that was merged. Signed-off-by: Leah Rowe <leah@libreboot.org>
Patch in Gerrit: https://review.coreboot.org/c/coreboot/+/89281 Not working: USB3 ports only work at USB2 speeds. IFD: Modified the original by: - Removing Device Exp2 region (empty anyway) - Enlarging the BIOS region to use this freed space - Setting the HAP bit in PCHSTRP55 using a fork of me_cleaner: https://github.com/XutaxKamay/me_cleaner Signed-off-by: Riku Viitanen <riku.viitanen@protonmail.com> Signed-off-by: Leah Rowe <leah@libreboot.org>
Everything should work except cpu fan control because ME cleaning breaks PECI.
I currently check the downloaded files e.g. .exe file, but then I don't check - or even define - sha512sums for the files extracted from them e.g. me.bin This patch fixes that. It also caches the hashed files, so that extraction is faster on a re-run - this makes release builds go faster, when running ./mk release If a checksum is not defined, i.e. blank, then a warning is given, telling you to check a specific directory. This way, when adding new vendor files, you can add it first without specifying the checksum, e.g. me.bin checksum. Then you can manually inspect the files that were extracted, and define it, then test again. In a given pkg.cfg for config/vendor, the following variables are now available for use: FSPM_bin_hash for fsp m module FSPS_bin_hash for fsp s module EC_FW1_hash for KBC1126 EC firmware (1st file) EC_FW2_hash for KBC1126 EC firmware (2nd file) ME_bin_hash for me.bin MRC_bin_hash for mrc.bin (broadwell boards) REF_bin_hash for refcode (broadwell boards) SCH5545EC_bin_hash for sch5545 firmware (Dell Precision T1650) TBFW_bin_hash for Lenovo ThunderBolt firmware (e.g. T480/T480s) E6400_VGA_bin_hash for Dell E6400 Nvidia VGA ROM In practise, most people use release archives, and the inject script, so I knew those were reliable, because the ROM images were hashed prior to removing files. This patch benefits people using lbmk.git directly, without using release files, because now they know they have a valid file e.g. me.bin Previously, only the download was checked, not the extracted files, which meant that the only thing preventing a brick was the code not being buggy. Any number of bugs could pop up in the future, so this new level of integrity will protect against such a scenario, and provide early warning prompting bug fixes. Signed-off-by: Leah Rowe <leah@libreboot.org>
We used cbfstool from coreboot 4.13, because it was the last version to work with the particular format used for stage files, before the CBFS standard changed in newer releases of cbfstool. When I added this board to Libreboot, it was source-only at first so it didn't matter. I didn't want to do a standalone cbfstool binary, in case some people decided to use that one on newer boards, which would cause all sorts of issues. So I bodged it and just included an import of coreboot 4.13. Well, the cbfstool from coreboot 4.11, as used for FAM15H AMD boards, is compatible. I checked the code diff between the two, and there is no meaningful difference. I've tested this, and it works, since the last release or two now includes 820 G2 images, so I was able to use those with ./mk inject, to verify whether the refcode file is still grabbed properly. We need the refcode to handle MRC on Broadwell platform, but we extract it from an old Google Chromebook image, that uses the old CBFS stage file layout. This change solves my problem: the problem was that releases are bloated further, due to including this extra coreboot version. This should reduce the size of the next release considerably, especially after decompressing the tarball. Signed-off-by: Leah Rowe <leah@libreboot.org>
This is similar to the 9020SFF, but this board has ECC support. However, the native raminit isn't used here, even though it is otherwise compatible, because the native init doesn't do ECC yet. The broadwell mrc.bin has ECC support, which is also used on the HP EliteBook 820 G2. The MRC for broadwell can be used on haswell boards such as the T1700. Add both the SFF and MT variants. Since these are identical to the 9020 variants, except for slightly different PCH enabling ECC, we can just re-use the 9020 port without issue. We *could* add a variant to coreboot, for T1700, but there is not really any pressing need. It is simply the 9020sff/mt with mrc.bin Signed-off-by: Leah Rowe <leah@libreboot.org>
Signed-off-by: Leah Rowe <leah@libreboot.org>