Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Update Prerequisites.md #85

Open
wants to merge 3 commits into
base: master
Choose a base branch
from
Open

Update Prerequisites.md #85

wants to merge 3 commits into from

Conversation

copyvar
Copy link

@copyvar copyvar commented Dec 28, 2021

Updated / simplified text for newcomers. I hardly understood part "Current Legacy boards" and following, but I think the first part helps newcomers to get an idea. Please see my two comments in BOLD in the text section before applying. (This is my first fork, hopefully I am doing everything correctly.)

Updated / simplified text for newcomers. I hardly understood part "Current Legacy boards" and following, but I think the first part helps newcomers to get an idea. Please see my two comments in BOLD in the text section before applying. (This is my first fork, hopefully I am doing everything correctly.)
@tlaurion
Copy link
Collaborator

tlaurion commented Dec 28, 2021

@copyvar

Flashrom and linux kernel fit into the 4MB SPI flash from the x230-flash ROM. Booting into via external programmer flashed x230-flash ROM launches a recovery shell, which made possible to flash only the BIOS region from the x230 created ROM (PLEASE EXPLAIN, WHAT DO YOU MEAN BY "x230 created ROM"?). This ROM image is incomplete and flashing the whole 12MB image would create a brick.

Well. This means things are still not clear enough. Let's try to explain differently so newcomers are understanding better. :)
Let me know if you have more questions and adapt your PR accordingly.

When you do make BOARD=x230, you are creating a x230 board, legacy, rom.

That rom is invalid as a whole (it doesn't contain neither a valid Intel Firmware Descriptor (IFD), GBE nor ME and if it was flashed externally, by seperating the 12mb image into 4mb and 8mb image, would consequently brick the board, since the IFD descriptor is used to locate ME which initializes the main CPU, there would be no Ethernet controller functioning; the board would simply not boot). It cannot be flashed externally.

Legacy xx30 boards depend on their xx30-flash board produced rom counterpart to be flashed externally first on top SPI chip, to then be able to flash the xx30 produced rom internally wich will only flash BIOS region of IFD. This is the goal of xx30-flash legacy boards roms (as opposed to maximized roms): to be able to flash only one chip externally, with or without cleaning ME, and reusing the IFD, GBE and ME already defined and existing IFD regions, without requiring IFD to be unlocked and reflashed nor ME to be neutered and reflashed on 8mb bottom chip per cleaning instructions; basically permitting to come from 1vyrain (whoich cannot modify neither ME nor unlock IFD) or Skulls (which permitted unlocking IFD per an additional and optional step in the past and now unlocks it by default: so we do not know if locked/unlocked).

It was the first boards (x230-flash, x230) added into Heads, without having to clean ME to gain additional space and get rid of the blobs and take advantage of freed space. And consequently, they are called legacy boards because available SPI space is limited to unoccupied ME SPI space and won't interfere with ME region defined in stock IFD. So you get 7mb of available and flashable BIOS region space. Diagram below on coreboot documentation website.

After flashing x230-flash externally to the 4mb top SPI flash, with or without cleaning ME per separate instructions on the 8mb flash chip, you can then flash a x230 produced rom internally.

That is possible because the x230-flash board flashrom statement instructs flashrom to flash only the BIOS region of the combined 8mb+4mb SPI flash, which will overwrite only thr 7mb IFD defined BIOS region and nothing else.

The same applies for each legacy boards (eg: x230)

Here the flash layout of a xx30, spanning on 8mb+4mb SPIs to create a 12mb combined flash
There:

  • The xx30-flash produced 4mb rom is flashed externally to only overwrite Flash #1 top spi
  • The xx30 produced 8mb rom is flashed internally and is made to fit the untouched Flash #2 IFD region defined BIOS region (defined in bottom SPI flash chip first partition), which you see spans over the 4mb Flash #1 bottom SPI chip space and overlaps to the Flash #2 bottom SPI chip region (doing flashrom --force --noverify-all -p internal --ifd --image bios -w legacy.rom)

Consequently, if externally flashing legacy xx30-flash, the end user intended (and protected?) experience is to be able to flash only xx30 roms internally, which are invalid (no IFD, no GBE, no ME) to fit inside that small defined BIOS region overlapping on Flash #1 and Flash #2, keeping stock, locked regions (IFD, ME and GBE untouched AND reused).

The Maximized boards are different.
They are valid in themselves, contain neutered and unlocked ME region, an IFD which redistributes that neutered space from IFD ME region and gives it to the IFD BIOS region (the 7mb BIOS region is extended to be 11.5mb).

A maximized board produces 3 roms:

  • a bottom(8mb) rom to be flashed externally
  • top (4mb) rom to be flashed externally
  • And a full 12mb rom to be internally UPGRADED if already on board that was initially externally flashed, of where the IFD and ME regions were previously unlocked per cleaning instructions, or from Skulls if the optional IFD unlock step was followed, and by flashing explicitly from the command line to flash the whole 12mb with flashrom --force --noverify-all -p internal -w maximized.rom.

Then, subsequent internal flash will flash the whole combined 12mb SPI space, as per FLASHROM board statement that is used for all subequent flashrom calls on maximized boards.

Thanks for this peer review and first PR! If you understand, this means others will. This is needed and really appreciated.
Let me know if anything else is unclear.

@tlaurion
Copy link
Collaborator

@merge tagging you for validation on Skulls part.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants