FreeBSD source tree https://cgit-dev.freebsd.org/src/atom?h=releng%2F14.3 2025-04-20T07:01:18Z 2025-04-20T07:01:18Z Ravi Pokala rpokala@FreeBSD.org 2025-04-08T06:04:31Z urn:sha1:b337e9fd11711a7dff6a35f211c2b4f3210b29c4 in the bootloader. Reviewed by: imp MFC after: 1 week Sponsored by: Vdura Differential Revision: https://reviews.freebsd.org/D49708 (cherry picked from commit 3adae4f27d600f0be7904eb1bb30e79d90386793) 2025-04-08T13:38:28Z Olivier Certner olce@FreeBSD.org 2025-03-05T10:34:49Z urn:sha1:f6b90dc8afc0666a6a7e012d38ec02eb1d5b771f When such an address is known, do not search elsewhere, contrary to what we are doing on non-EFI boot (see SMBIOS_START and SMBIOS_LENGTH). Reviewed by: markj MFC after: 2 weeks Sponsored by: The FreeBSD Foundation Differential Revision: https://reviews.freebsd.org/D49291 (cherry picked from commit 1ee8714950b8d07ccd172f2bcbbbaa91f02ef9e7) 2025-04-08T13:38:28Z Olivier Certner olce@FreeBSD.org 2025-03-05T10:27:50Z urn:sha1:d19f1559d008290f87d303b22833f66eaef61e36 In particular, this allows the caller to know whether the detection was successful. Reviewed by: imp, markj MFC after: 2 weeks Sponsored by: The FreeBSD Foundation Differential Revision: https://reviews.freebsd.org/D49290 (cherry picked from commit 9dad0ba286807c4aa2886f13705fca2334bb4759) 2025-04-08T13:38:28Z Olivier Certner olce@FreeBSD.org 2025-03-05T10:24:36Z urn:sha1:9b8e1558c961dd47494519385da4fa96124307e3 This is in preparation for modifying the EFI loader to favor a v3 table if present. As an impact, caller smbios_match() has been changed so that it only calls smbios_probe() with NULL (non-EFI discovery) once. While here, expand the original XXXRP comment in smbios_match(). Reviewed by: imp, markj MFC after: 2 weeks Sponsored by: The FreeBSD Foundation Differential Revision: https://reviews.freebsd.org/D49289 (cherry picked from commit c340797e08d8c20983ea57de88992f988fe7bb9b) 2025-04-08T13:38:28Z Olivier Certner olce@FreeBSD.org 2025-03-03T21:10:25Z urn:sha1:7b0350b376c073c22e6dd2f129313c6f486421a4 On amd64, boot blocks and the non-EFI loader are 32-bit compiled as clients of BTX, so cannot access addresses beyond 4GB. However, the 64-bit entry point may refer to a structure table below 4GB, which we want to use if the BIOS does not provide a 32-bit entry point. The situation is similar for powerpc64. Consequently, always compile-in support for the 64-bit entry point, but ensure that it is not selected on 32-bit-compiled boot loaders if the structure table it points to grows beyond 4GB (as it is then not accessible). PR: 284460 Reviewed by: markj MFC after: 2 weeks Relnotes: yes Sponsored by: The FreeBSD Foundation Differential Revision: https://reviews.freebsd.org/D49288 (cherry picked from commit 7f005c6699f429c2f762b4dd8fb39b3bcf5378e2) 2025-04-08T13:38:27Z Olivier Certner olce@FreeBSD.org 2025-03-03T14:38:10Z urn:sha1:93af0db0d5298bc7d1eb05d57aacfc6495d2c057 When both the 32-bit and 64-bit entry points are present, the SMBIOS specification says that the 64-bit entry point always has at least all the structures the 32-bit entry point refers. In other words, the 32-bit entry point is provided for compatibility, so we assume the 64-bit one has more chances to be filled with adequate values. Doing this also increases consistency with the kernel's smbios(4) driver. Reviewed by: imp, markj MFC after: 2 weeks Relnotes: yes Sponsored by: The FreeBSD Foundation Differential Revision: https://reviews.freebsd.org/D49287 (cherry picked from commit 3f744fb8b2c5528c2170be113e0e4947eee3cffc) 2025-04-08T13:38:27Z Olivier Certner olce@FreeBSD.org 2025-03-07T13:32:24Z urn:sha1:5feb3c8ea6025688944b2c402dee86fbc1878041 According to the specification, such an entry point may have different data in bytes at offsets 0x0c to 0x17 (included). In such a case, interpreting them as the Structure Table Maximum Size and Address fields could have catastrophic consequences. Reviewed by: imp, markj MFC after: 2 weeks Sponsored by: The FreeBSD Foundation Differential Revision: https://reviews.freebsd.org/D49286 (cherry picked from commit 64fc51a9cf71b2308399b7b7dee8a9bc9468877b) 2025-04-08T13:38:27Z Olivier Certner olce@FreeBSD.org 2025-03-04T11:17:45Z urn:sha1:330f1a42813e70186bdbef6ff22f24c61d36a24a This structure exists since SMBIOS v2.2 and indicates that there are no structures to be parsed beyond this point. For backwards compatibility, the standard recommends that system software ensures that this structure covers the rest of the SMBIOS structure table area as reported by the Structure Table Address, and the Structure Table Maximum Size (64-bit entry point) or the Structure Table Length (32-bit entry point), which makes existing parsers continue to work correctly as they usually ignore unknown structure types. However, this is not a requirement, so be bullet proof and immediately stop parsing in this case. Reviewed by: imp, markj MFC after: 2 weeks Sponsored by: The FreeBSD Foundation Differential Revision: https://reviews.freebsd.org/D49285 (cherry picked from commit 7e61fc76400cce08de39adde99b879f0bca21b7d) 2025-04-08T13:38:27Z Olivier Certner olce@FreeBSD.org 2025-03-03T14:30:16Z urn:sha1:19a5b6aaab92e4fe7617c0f7ed21849cdaa9ae67 The code parsing the BCD revision is only meaningful on v2, so move it away into the appropriate 'if' branch to ease reading (and to avoid a useless test). Expand comments. In particular, make it clear that setting 'smbios.count' to '-1' removes the limit of the number of structures to parse. No functional change. Reviewed by: imp, markj MFC after: 2 weeks Sponsored by: The FreeBSD Foundation Differential Revision: https://reviews.freebsd.org/D49284 (cherry picked from commit d1f351fcb22f46805ff0a0cecf6ce787f84d31d5) 2025-04-08T13:38:26Z Olivier Certner olce@FreeBSD.org 2025-03-03T16:44:38Z urn:sha1:2337cd86dc469ee3e263666e94621816141dc15d Via the kenv 'smbios.entry_point_type'. Reviewed by: imp, markj MFC after: 2 weeks Sponsored by: The FreeBSD Foundation Differential Revision: https://reviews.freebsd.org/D49283 (cherry picked from commit 3b2303ba3dba4e33ee0866953b4390c5481cac83)