Dear coreboot community,
as a part of coreboot port for Talos II POWER9 architecture, we are porting the cbmem tool. [1] This platform can switch between the big-endian and the little-endian. coreboot operates in big-endian but in theory it could also operate in little-endian, and the OS can also operate in both - little-endian and big-endian. This creates a situation where cbmem tries to read cbtable in different endianness than the cbtable was created. Therefore, cbmem needs to convert the endianness, and it needs to differentiate if the conversion is required or not.
There are several ways we could differentiate if it is required to convert endianness or not. What would be the best approach to this problem?
1. Save endianness information in the cbtable header. For example, the signature on the big-endian coreboot could be “OIBL” instead “LBIO”. This solution would be very portable as the other tools looking for the cbtable but not expecting the big-endian format would simply not find the table instead of trying to read it and crashing. However, this change would need to be introduced in multiple places in coreboot as the signature is hardcoded in multiple where it was needed.
2. Add preprocessor checks to enable endianness conversion only on defined platforms. It would be easy to implement, but if the BIOS and the OS can have different endianness, then it could break for cbtable written in little-endian mode.
3. Recognize the correct endianness by checking some property of cbtable header. For example, header size property value could be checked if it reads as 0x18 or 0x18000000, but this solution requires very little changes but feels hacky and susceptible to changes in cbtable header format.
4. Add command-line option to cbmem so the user can choose what endianness should be used. I’m not sure about this solution, because it pushes the responsibility to recognize endianness to the user.
[1] https://github.com/Dasharo/coreboot/pull/62
Hi Igor,
On 23.12.21 15:49, Igor Bagnucki wrote:
Dear coreboot community,
as a part of coreboot port for Talos II POWER9 architecture, we are porting the cbmem tool. [1] This platform can switch between the big-endian and the little-endian. coreboot operates in big-endian but in theory it could also operate in little-endian, and the OS can also operate in both - little-endian and big-endian.
how likely is it that an OS runs in big-endian? IIRC from past discussions it was usually expected that the OS runs in little- endian. If there is such a preference, I'd simply specify the cbtable endianness to be little-endian. After all, the cbtable is an interface for the OS so we should make things easy on that end, IMHO.
Also, if we could assume little-endian OS's, we could also switch early (e.g. bootblock) to that. Or is there any other technical difficulty why we don't do that already?
This creates a situation where cbmem tries to read cbtable in different endianness than the cbtable was created. Therefore, cbmem needs to convert the endianness, and it needs to differentiate if the conversion is required or not.
There are several ways we could differentiate if it is required to convert endianness or not. What would be the best approach to this problem?
- Save endianness information in the cbtable header.
For example, the signature on the big-endian coreboot could be “OIBL” instead “LBIO”. This solution would be very portable as the other tools looking for the cbtable but not expecting the big-endian format would simply not find the table instead of trying to read it and crashing. However, this change would need to be introduced in multiple places in coreboot as the signature is hardcoded in multiple where it was needed.
- Add preprocessor checks to enable endianness conversion only on
defined platforms. It would be easy to implement, but if the BIOS and the OS can have different endianness, then it could break for cbtable written in little-endian mode.
- Recognize the correct endianness by checking some property of cbtable
header. For example, header size property value could be checked if it reads as 0x18 or 0x18000000, but this solution requires very little changes but feels hacky and susceptible to changes in cbtable header format.
- Add command-line option to cbmem so the user can choose what
endianness should be used. I’m not sure about this solution, because it pushes the responsibility to recognize endianness to the user.
5. Specify a single endianness for cbtable. I would prefer little-endian as that would keep compatibility to older (maybe not too old) user-space binaries. Even if we have code that runs in big-endian, that would still keep the conversion simple. We could just always convert host-to-LE and vice versa, no need for any `if`.
Nico
-
Igor Bagnucki -
Nico Huber