According to my calculations, my proposed 768 default - which is just slightly larger than a previous 600 - should also allow having ~20 CPUs, although the systems with 20 CPUs are significantly less popular than i.e. 16. Also, the uneven (unrelated to the power of 2's) values of 600 weren't really justified in the first place: 768 decimal is 0x300, while 600 is a weird 0x258.
On Tue, Mar 9, 2021 at 2:28 AM Kevin O'Connor <ke...@koconnor.net> wrote: > > On Tue, Mar 02, 2021 at 11:21:27PM +0300, Mike Banon wrote: > > There are plenty of coreboot platforms whose MPTABLE size is just > > slightly larger than the current uneven limit of 600 bytes, which > > prevents these important tables from being copied. For example, G505S > > has 628 bytes and A88XM-E has 740 bytes. I propose 768 bytes as a new > > saner default for MPTABLE size, to replace the current uneven limit of > > 600. SMBIOS size should be bumped the similar way as well. > > This doesn't look correct to me. There is only a limited amount of > space in the f-segment, and it shouldn't be necessary to store large > tables there. All recent OSes should support the SMBIOS in > high-memory, and recent OSes don't need the mptable at all. > > The concern with increasing the size is that it could cause allocation > failures for other critical information that does need to be stored in > the f-segment (like drive layout). > > -Kevin -- Best regards, Mike Banon Open Source Community Manager of 3mdeb - https://3mdeb.com/ _______________________________________________ SeaBIOS mailing list -- seabios@seabios.org To unsubscribe send an email to seabios-le...@seabios.org
