Adding xx20 boards into CI (x220, T420) #873
Comments
|
There simply isn't enough space to install heads on a XX20 system without
stripping the ME at all, not even the xx30 install-phase inits would be
small enough to fit on an untouched IFD/ME xx20 units.
…On Tue, Oct 27, 2020, 10:08 tlaurion ***@***.***> wrote:
Quick reflexion to launch debate for xx20 boards owners/enthusiasts
<#692>:
@SebastianMcMillan <https://github.com/SebastianMcMillan> @techge
<https://github.com/techge> @eganonoa <https://github.com/eganonoa>
@shamen123 <https://github.com/shamen123> @Thrilleratplay
<https://github.com/Thrilleratplay>
If the instructions of installation were specifying to
flashrom -p ch341_a -c XXXXXXXX --ifd BIOS -w heads.rom
- Wouldn't it be possible to produce valid externally/internally
flashable roms which just doesn't touch ME/GBE and respect origin IFD board?
- Then, without releasing blobs bases repositories, have instructions
showing how to unlock IFD, reduce ME, expend BIOS region on original ROM
and then have another x220 board, which produces ROMs for that larger BIOS
region, permitting other tools to merge in?
Asking the question to xx20 boards testers cause this board is not enough
tested and consequently of the past merged commits that passed to all other
boards, I believe that those boards might become less and less supported if
at least regressions are not at least validated by CIs.
- Flashrom was invalid and blindly corrected without testing:
cd6ba01
<cd6ba01>
https://github.com/osresearch/heads/blob/master/boards/x220/x220.config#L39
- GPG toolstack got upgraded which fitted in other boards but probably
not to xx20 boards:
e3519f2
<e3519f2>
- Flashrom was updated but not tested by any xx20 boards users
3c24460
<3c24460>
Time to change our approaches. Otherwise we will have to fixate boards to
use a specific versions of modules in board configs, since upgrading them
is becoming more and more difficult, each version of a module upgrade
normally increasing in size. (coreboot, kernel, gpg2, etc)
The next approach, if noone joins in, will probably be to fixate modules
version to last known working version prior of pushing changes upstream.
That would mean, for example, that the xx20 would be stuck to old versions
of everything.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#873>, or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AFNTUNCVRYRUZLFB77TVINTSM3O6BANCNFSM4TA6YOQQ>
.
|
Externally, no. There is only one 8mb rom chip and will need to contain the ME/IFD/GBE partitions to flash externally. Internally, perhaps with the With additional scripts/modules, a solution similar to #703 could be implemented. The GBE is the same for both models. While it would be a lot of work and testing to get to this point, the X220,T420,T520, X230, T430, T530 could all generate 8mb externally flashable versions heads. For the models that have 12MB, they can be flashed internally to take advantage of the remaining 4mb with extra features. |
|
@SebastianMcMillan : so only:
This would still require modifications on xx20 instructions so that all users know what they have to do to have a xx20 board, where CI could create flashable ROMS only for that BIOS region, where it would fail if the regions mismatches. |
|
@SebastianMcMillan : I edited OP. |
|
Also, I just noticed #871 being made. I know for a fact those changes were
made a while back and merged in, as my X220 has the flashrom options with
ich hwseq enabled.
Which commit reverted that?
Edit: when flashrom 1.2 support was added, X220 flashrom options got changed and had that reverted. I added that specifically since it prevented the issue with different flash chips needing the -c flag.
…On Tue, Oct 27, 2020, 10:20 tlaurion ***@***.***> wrote:
@SebastianMcMillan <https://github.com/SebastianMcMillan> : I edited OP.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#873 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AFNTUNGWCGORY4TSNAQK4TDSM3QKNANCNFSM4TA6YOQQ>
.
|
|
@SebastianMcMillan this is linked to #870 (comment) |
Yeah. Seems like a regression was added https://github.com/osresearch/heads/blame/e3519f2ecd8e396d92905317ac5151e590388b02/boards/x220/x220.config#L39 thinking it was not required anymore. |
|
First step is #877 |
|
We might have a problem |
|
Won't happen until #877 |
|
@Thrilleratplay Clarified xx30 board config with explanations and proper seperations of modules with explanations under b981004 |
|
fixed under maximized xx20 boards |
Quick reflexion to launch debate for xx20 boards owners/enthusiasts:
@SebastianMcMillan @techge @eganonoa @shamen123 @Thrilleratplay
If the instructions of installation were specifying to
flashrom -p ch341_a -c XXXXXXXX --ifd BIOS -w heads.romWouldn't it be possible to produce valid externally/internally flashable roms which just doesn't touch ME/GBE and respect origin IFD board?
Then, without releasing blobs based repositories (no actual blobs, under blobs dir), have instructions showing how to unlock IFD, reduce ME, expend BIOS region on original ROM and then have another x220 board, which produces ROMs for that larger BIOS region, permitting other tools to merge in? Instructions would need to be updated, of course. But i'm thinking of something like 3 boards per actual platform or something similar to, for example:
x220-neutered (having CBFS for BIOS region maximized, taking into consideration that ME is cleaned and IFD corresponding to CBFS region defined in coreboot-xx20.config)
x220-deactivated (the user having deactivated ME, while not having neutered it, CBFS region of coreboot matching stock IFD, with ME not being neutered)
x220-external-flash (with blobs in, similar to Add xx30-maximized and xx30-hotp-maximized boards (11.5mb flashable BIOS regions, reproducible me.bin and generated gbe.bin and totally externally and internally flashable roms) #703)
Asking the question to xx20 boards testers cause this board is not enough tested and consequently of the past merged commits that passed to all other boards, I believe that those boards might become less and less supported (and not even building per users) if at least regressions are not at least validated by CIs. This is undesired:
cd6ba01
https://github.com/osresearch/heads/blob/master/boards/x220/x220.config#L39
e3519f2
3c24460
Time to change our approaches. Otherwise we will have to fixate boards to use a specific versions of modules in board configs, since upgrading them is becoming more and more difficult, each version of a module upgrade normally increasing in size. (coreboot, kernel, gpg2, etc)
The next approach, if no-one joins in, will probably be to fixate modules version to last known working version prior of pushing changes upstream. That would mean, for example, that the xx20 would be stuck to old versions of everything.
The text was updated successfully, but these errors were encountered: