The intel cache_as_ram postcodes actually wouldn't go into the bootblock area. The coreboot areas are meant to be common to all platforms. The CAR codes would mostly go into the "SoC specific area", which I've doubled from 16 to 32 codes based on your comment here.
``` * 0x00 : unregulated - 0x00 is not a good postcode. * * 0x01 - 0x07 : general coreboot startup code & common * 0x08 - 0x0b : general coreboot console * 0x0c - 0x0f : <RESERVED> * * 0x10 - 0x1f : general coreboot bootblock * 0x20 - 0x2f : general coreboot romstage * 0x30 - 0x33 : general coreboot postcar * 0x34 - 0x3f : general coreboot ramstage * 0x40 - 0x4f : coreboot ramstage hardwaremain boot stages * * 0x50 - 0x6f : SOC specific - Each SoC/CPU/Chipset can use as it chooses * * 0x70 - 0x7f : <Reserved for expansion> * * 0x80 - 0x87 : ACPI postcodes * 0x88 - 0x8f : Unregulated - may be used anywhere for any purpose. * 0x90 - 0x9f : Vendorcode calls: FSP, AGESA, etc. entry & exit. * * 0xa0 - 0xaf : Mainboard specific - Each mainboard can use as it chooses * * 0xb0 : Driver/SuperIO ID, followed by ID byte (serves as driver entry) * 0xb1 - 0xbf : Driver/SuperIO specific - Can use as the device chooses * * 0xc0 - 0xca : <Reserved for expansion> * * 0xcb : coreboot identifier - used when returning from FSP, AGESA, etc * * 0xcc - 0xcf : <Reserved for expansion> * * 0xd0 : Debug ID, followed by ID byte * 0xd1 - 0xdf : Debug postcodes - never enabled by default. * * 0xe0 - 0xef : Errors * 0xf0 - 0xf7 : general coreboot SMM * 0xf8 - 0xfe : end of coreboot code - resume and the like. * 0xff : coreboot finished - jump to payload ```
I've also moved some reserved area to just after the SoC postcode area in case we find we still need more than 32, we can easily expand it up to 48 postcodes for the SoC or CPU/NB/SB areas.
If we find we need to reorganize more in the future, we should be able to do that without too much difficulty in the future. It was suggested in the leadership meeting last week that we could version the postcodes based on releases, but hopefully it'll settle down very shortly, and we won't need to do that.
Martin
Nov 16, 2022, 15:20 by maximilian.brune@9elements.com:
src/soc/intel/common/block/cpu/car/cache_as_ram.S is a candidate which hard codes all post codes (instead of using post_codes.h) and that file alone already uses more than your 16 propsed postcodes for bootblock (I think). Since bootblock is kind of relying on post codes for proper debug (since serial output may not be available at that time), it would make sense to use more post codes for bootblock I guess.
On Wed, Nov 16, 2022, 17:23 Martin Roth via coreboot <> coreboot@coreboot.org> > wrote:
The current state of the coreboot postcodes is a mess. There’s no good way to give anyone a postcode table. The post_code() function is called with direct hardcoded values all over the codebase. The post_codes.h file is disorganized with values being added without regard for being contiguous or ordered. As an example, despite using hexadecimal values, console post codes go from 0x39 to 0x40.
We can do better than this.
Proposal
The postcodes should be better organized and standardized. Each stage should have its own block of postcodes, and they should be easily recognizable as a flow from early coreboot to late coreboot. common between blocks:
- bootblock
- verstage
- romstage
- postcar
- ramstage
- smm
We should have blocks of postcodes for different sections as well.
SoC/CPU/Chipset
Mainboard
Drivers
A set of debug-specific postcodes that may be used in any area, but may not be enabled by default, but only by user request.
The debug and driver post codes should have identifiers to show what section of the codebase they're coming from.
Finally, there should be small section of uncontrolled values that can be used anywhere that doesn’t have an already allocated specific value.
Additional Improvements
- Postcodes should be able to be included in the timestamp table so we can grab timestamps for individual postcodes.
- Specific Postcodes should have associated text names, similar to the timestamps, and should have a decode tool.
- Multi-byte postcodes should be implemented for platforms that support them.
Proposed postcode ranges
* 0x00 : unregulated - 0x00 is not a good postcode. * * 0x01 - 0x07 : coreboot startup code & common * 0x08 - 0x0b : coreboot console * 0x0c - 0x0f : <RESERVED> * * 0x10 - 0x1f : coreboot bootblock * 0x20 - 0x2f : coreboot romstage * 0x30 - 0x33 : postcar * 0x34 - 0x3f : coreboot ramstage * 0x40 - 0x4f : coreboot ramstage hardwaremain boot stages * * 0x50 - 0x5f : Mainboard specific - Each mainboard can use as it chooses * 0x60 - 0x6f : SOC specific - Each SoC/CPU/Chipset can use as it chooses * * 0x70 : Driver/SuperIO ID, followed by ID byte * 0x71 - 0x7f : Driver/SuperIO specific - Can use as the device chooses * * 0x80 - 0x87 : ACPI postcodes * 0x88 - 0x8f : Unregulated - may be used anywhere for any purpose. * 0x90 - 0x9f : Vendorcode calls: FSP, AGESA, etc. * * 0xa0 - 0xaf : <RESERVED> * 0xb0 - 0xbf : <RESERVED> * * 0xc0 - 0xca : <RESERVED> * * 0xcb : coreboot identifier - used when returning from FSP, AGESA, etc * * 0xcc - 0xcf : <RESERVED> * * 0xd0 - 0xdf : Debug postcodes - never enabled by default. * * 0xe0 - 0xef : Errors * 0xf0 - 0xf7 : SMM * 0xf8 - 0xfe : end of coreboot code - resume and the like. * 0xff : coreboot finished - jump to payloadDriver/SuperIO/Debug IDs
Because there are many drivers, and a single board can use multiple of the drivers, we want a way to know which device is putting out postcodes. To handle this, the driver, superIO, or debug section should emit a DRIVER_ID_FOLLOWS or DEBUG_ID_FOLLOWS postcode, followed by the actual ID code.
The ID code would currently be a single byte, with the bytes 0xf0 - 0xff being reserved as page and continue bytes. The continue bytes would tell the code that the ID is on a secondary or later page - See the method used by the SPD to identify Manufacturers as a similar concept. 0xF0 - 0xFE would each point to a page of 240 possible drivers, and 0xff would tell the code to look for the next level of pages, which would follow the same pattern.
The driver IDs and debug IDs would all be contained in separate header files.
This would allow for the area to be uniquely identified by a tool.
Postcode rules
- Don’t use postcodes other than the debug postcodes in loops. Spewing out postcodes isn’t helpful.
- Don’t output bare numbers, a macro in post_codes.h must be used. A linter will be set up to look the macros and will give an error if it’s not one of the postcode files.
- All postcode output should be able to be identified by an automatic parser tool (with the exception of unregulated codes)
coreboot mailing list -- >> coreboot@coreboot.org To unsubscribe send an email to >> coreboot-leave@coreboot.org
I think it would be good to replace Documents/POSTCODES with this content, and move it into an actual markdown file at the same time.
It would probably be easier to comment on specific blocks/ranges in gerrit also.
On Sun, Nov 20, 2022 at 5:23 PM Martin Roth via coreboot < coreboot@coreboot.org> wrote:
The intel cache_as_ram postcodes actually wouldn't go into the bootblock area. The coreboot areas are meant to be common to all platforms. The CAR codes would mostly go into the "SoC specific area", which I've doubled from 16 to 32 codes based on your comment here.
* 0x00 : unregulated - 0x00 is not a good postcode. * * 0x01 - 0x07 : general coreboot startup code & common * 0x08 - 0x0b : general coreboot console * 0x0c - 0x0f : <RESERVED> * * 0x10 - 0x1f : general coreboot bootblock * 0x20 - 0x2f : general coreboot romstage * 0x30 - 0x33 : general coreboot postcar * 0x34 - 0x3f : general coreboot ramstage * 0x40 - 0x4f : coreboot ramstage hardwaremain boot stages * * 0x50 - 0x6f : SOC specific - Each SoC/CPU/Chipset can use as it chooses * * 0x70 - 0x7f : <Reserved for expansion> * * 0x80 - 0x87 : ACPI postcodes * 0x88 - 0x8f : Unregulated - may be used anywhere for any purpose. * 0x90 - 0x9f : Vendorcode calls: FSP, AGESA, etc. entry & exit. * * 0xa0 - 0xaf : Mainboard specific - Each mainboard can use as it chooses * * 0xb0 : Driver/SuperIO ID, followed by ID byte (serves as driver entry) * 0xb1 - 0xbf : Driver/SuperIO specific - Can use as the device chooses * * 0xc0 - 0xca : <Reserved for expansion> * * 0xcb : coreboot identifier - used when returning from FSP, AGESA, etc * * 0xcc - 0xcf : <Reserved for expansion> * * 0xd0 : Debug ID, followed by ID byte * 0xd1 - 0xdf : Debug postcodes - never enabled by default. * * 0xe0 - 0xef : Errors * 0xf0 - 0xf7 : general coreboot SMM * 0xf8 - 0xfe : end of coreboot code - resume and the like. * 0xff : coreboot finished - jump to payloadI've also moved some reserved area to just after the SoC postcode area in case we find we still need more than 32, we can easily expand it up to 48 postcodes for the SoC or CPU/NB/SB areas.
If we find we need to reorganize more in the future, we should be able to do that without too much difficulty in the future. It was suggested in the leadership meeting last week that we could version the postcodes based on releases, but hopefully it'll settle down very shortly, and we won't need to do that.
Martin
Nov 16, 2022, 15:20 by maximilian.brune@9elements.com:
src/soc/intel/common/block/cpu/car/cache_as_ram.S is a candidate which
hard codes all post codes (instead of using post_codes.h) and that file alone already uses more than your 16 propsed postcodes for bootblock (I think). Since bootblock is kind of relying on post codes for proper debug (since serial output may not be available at that time), it would make sense to use more post codes for bootblock I guess.
On Wed, Nov 16, 2022, 17:23 Martin Roth via coreboot <>
coreboot@coreboot.org> > wrote:
The current state of the coreboot postcodes is a mess. There’s no good
way to give anyone a postcode table. The post_code() function is called with direct hardcoded values all over the codebase. The post_codes.h file is disorganized with values being added without regard for being contiguous or ordered. As an example, despite using hexadecimal values, console post codes go from 0x39 to 0x40.
We can do better than this.
Proposal
The postcodes should be better organized and standardized. Each stage
should have its own block of postcodes, and they should be easily recognizable as a flow from early coreboot to late coreboot.
common between blocks:
- bootblock
- verstage
- romstage
- postcar
- ramstage
- smm
We should have blocks of postcodes for different sections as well.
SoC/CPU/Chipset
Mainboard
Drivers
A set of debug-specific postcodes that may be used in any area, but
may not be enabled by default, but only by user request.
- The debug and driver post codes should have identifiers to show what
section of the codebase they're coming from.
- Finally, there should be small section of uncontrolled values that
can be used anywhere that doesn’t have an already allocated specific value.
Additional Improvements
- Postcodes should be able to be included in the timestamp table so we
can grab timestamps for individual postcodes.
- Specific Postcodes should have associated text names, similar to the
timestamps, and should have a decode tool.
- Multi-byte postcodes should be implemented for platforms that
support them.
Proposed postcode ranges
* 0x00 : unregulated - 0x00 is not a good postcode. * * 0x01 - 0x07 : coreboot startup code & common * 0x08 - 0x0b : coreboot console * 0x0c - 0x0f : <RESERVED> * * 0x10 - 0x1f : coreboot bootblock * 0x20 - 0x2f : coreboot romstage * 0x30 - 0x33 : postcar * 0x34 - 0x3f : coreboot ramstage * 0x40 - 0x4f : coreboot ramstage hardwaremain boot stages * * 0x50 - 0x5f : Mainboard specific - Each mainboard can use as itchooses
- 0x60 - 0x6f : SOC specific - Each SoC/CPU/Chipset can use as it
chooses
- 0x70 : Driver/SuperIO ID, followed by ID byte
- 0x71 - 0x7f : Driver/SuperIO specific - Can use as the device chooses
- 0x80 - 0x87 : ACPI postcodes
- 0x88 - 0x8f : Unregulated - may be used anywhere for any purpose.
- 0x90 - 0x9f : Vendorcode calls: FSP, AGESA, etc.
- 0xa0 - 0xaf : <RESERVED>
- 0xb0 - 0xbf : <RESERVED>
- 0xc0 - 0xca : <RESERVED>
- 0xcb : coreboot identifier - used when returning from FSP,
AGESA, etc
- 0xcc - 0xcf : <RESERVED>
- 0xd0 - 0xdf : Debug postcodes - never enabled by default.
- 0xe0 - 0xef : Errors
- 0xf0 - 0xf7 : SMM
- 0xf8 - 0xfe : end of coreboot code - resume and the like.
- 0xff : coreboot finished - jump to payload
Driver/SuperIO/Debug IDs ------------------------ Because there are many drivers, and a single board can use multiple ofthe drivers, we want a way to know which device is putting out postcodes. To handle this, the driver, superIO, or debug section should emit a DRIVER_ID_FOLLOWS or DEBUG_ID_FOLLOWS postcode, followed by the actual ID code.
The ID code would currently be a single byte, with the bytes 0xf0 -
0xff being reserved as page and continue bytes. The continue bytes would tell the code that the ID is on a secondary or later page - See the method used by the SPD to identify Manufacturers as a similar concept. 0xF0 - 0xFE would each point to a page of 240 possible drivers, and 0xff would tell the code to look for the next level of pages, which would follow the same pattern.
The driver IDs and debug IDs would all be contained in separate header
files.
This would allow for the area to be uniquely identified by a tool.
Postcode rules
- Don’t use postcodes other than the debug postcodes in loops.
Spewing out postcodes isn’t helpful.
- Don’t output bare numbers, a macro in post_codes.h must be used. A
linter will be set up to look the macros and will give an error if it’s not one of the postcode files.
- All postcode output should be able to be identified by an automatic
parser tool (with the exception of unregulated codes)
coreboot mailing list -- >> coreboot@coreboot.org To unsubscribe send an email to >> coreboot-leave@coreboot.org
coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-leave@coreboot.org
-
Martin Roth -
Tim Van Patten