x230 x220 t430 t420 base boards: remove networking?

[merge]

here's a question: do we really need networking right now? My impression is that we don't deal with booting over a network at all. "x230-flash.init" loads the ethernet module but 1. the "x230-flash" "board" is questionable at best anyways (and largely unused). and 2. it's not documented, not tested and probably not used by anybody. "x230" doesn't do networking at all right?

also: what is the seemingly unused "keylime" thing?

my suggestion would be to remove all networking "usage" in x230 (and x230-flash in case that still sticks around) and remove networking from our linux config.

any objecitons? thanks.

[tlaurion]

No objection at all in removing networking support.

Sent from my Galaxy S3 using FastHub-Libre

[tlaurion]

No clue about keylime need either.

[tlaurion]

But the main consumer of space is Cairo dependencies I wasn't able to reduce.

After which GPG2 and dependencies

Sent from my Galaxy S3 using FastHub-Libre

[merge]

Let's first get #565 in and move on on top of that, ok?

[ThePlexus]

I cant see a huge use case at all for networking init in x230 or x230-flash. I mean, who really is going to netboot a x230? corner case, if it exists at all.

1. the "x230-flash" "board" is questionable at best anyways (and largely unused). and 2. it's not documented, not tested and probably not used by anybody.

@merge - not sure what you mean here. x230-flash is needed to flash the 4mb chip to then use the internal programmer to flash the full x230 board build? Or have I mis understood and you just meant it was networking on the x230-flash board that was not used and untested?

[merge]

@shamen123 nah you got that right, but I was just nagging because IMO we haven't solved the "first-time flashing" situation in Heads. Having a 4M image is important and it's good that we have one, but it isn't enough. If you don't disable IFD-write-protection on the 8M chip (by flashing externally too), you won't be able to use the x230-flash image to actually flash... but I shouldn't be nagging if I don't do anything about it :) We've solved it in Skulls, but not yet in Heads.

[ThePlexus]

@merge its an interesting problem. I see what you mean, I remember flashing both chips as part of my install cycle from stock, which given my experience, i automatically ran ME cleaner and ifd unlocked the 8Mb chip. i did make write up notes at the time and they are lurking around on one of my machines somewhere, which may be of use to others. but that was based on 0.2.1 generic init, so its likely already out of date.

I guess x230-flash could be done away with in the event the user is already flashing with a different system. They just need to ifd unlock the 8mb and ME neuter, then flash heads to the 4mb chip. In this case, im assuming that BOARD=x230 has its entire CBFS in 0x00800000 - 0x00bfffff in the 12mb version layout. User would then boot into heads and use the running env to sign (though will GPG fit into the 4mb along side the other utils? I vaguely remember having to comment out GPG in the x230-flash build due to size constraints #508

i still have to stock firmware, i could flash back to stock, implement & validate various build permutations and see what works, though likely I cant start this till next week.

[merge]

@shamen123 I haven't really looked into the current state of the x230-flash "board". IMO it shouldn't need gpg at all. It's for bootstrapping only, right?

Once the 4M "board" itself is in a nice shape (flash-gui, ... can be tested independently of the bootstrapping problem), we can think about how to help users with IFD unlocking. I can imagine a similar solution to https://github.com/merge/skulls/blob/master/x230/external_install_bottom.sh and good documentation. That script can directly be used actually... If it wasn't for "x230-flash" (a flash-only solution independent of the hard disk), we could even say "install Skulls first, and then come back here and flash Heads for your running Linux distro", but it's of course nicer to have a flash-only solution.

[merge]

If you want to work on x230-flash, please open a new issue or use #234 or #307 both of them should actually get closed by fixing this.

[ThePlexus]

@merge

IMO it shouldn't need gpg at all. It's for bootstrapping only, right

correct. not needed in x230-flash (and it wouldnt build since after 0.2.1, due to the size issues outlines in #517 - so I just commented GPG out to fix, and issued a pull to get it working again)

Once the 4M "board" itself is in a nice shape

to be fair, I recently rebuilt the x230 and it works pretty well. I did not need to use x230-flash as x230 was already in firmware, so i just put the new build on a usb stick, dropped to recovery and flashed the ful 12Mb coreboot.com. The only real annoying thing about moving from generic to gui was the TOTP code does not auto refresh. I think BOARD=x230 itself (at least as of a few weeks ago when I last built it) is pretty solid.

The problem we face is a bit chicken and egg. To flash the x230 12Mb heads coreboot.rom, the user must have an environment running on the machine in order to run flashrom, where the 8Mb chip must be unlocked and allow flashing of all regions and also with access to a filesystem where the 12Mb head coreboot.com is available. So we cant simply build BOARD=x230 and have some hypothetical system flash it.

Here is a bit of a long shot, and shoot me down if im barking up the wrong tree.

If memory serves me, when I first built BOARD=x230 it used to build three files. coreboot.rom (12), 8mb.rom and 4mb.com. You couldnt not really use the two smaller files as the IFD and ME was not built in. (Note: As of the last time I built, BOARD=x230 only produced one file, coreboot.rom 12mb)

Could we use (and adapt) the skulls script to pull the 8mb rom, ME neuter/unlock, and then use ifdtool to extract the IFD and ME region. Then tell heads/coreboot to build BOARD=x230 using those extracted files (IFD_BIN_PATH and ME_BIN_PATH) and - reverting back to the three file output - produce 12Mb coreboot.rom, 8Mb.rom and 4Mb.rom.

If that is possible, the user would then be able to flash the 8Mb.rom and 4Mb.rom using a SOIC clip, and the necessity for x230-flash would be gone.

Or maybe ive missed something. The x230 process is a bit of a doozy to get head around sometimes.

[merge]

1. please open an issue about TOTP auto-refreshing!

2. please move the bootstrapping discussion to a different issue too :)

yes, your scenario would technically work. It has been discussed and dismissed in favour of removing the 4M/8M split, which is an equally correct solution.

Creating a fully flashable 12M image would add quite some complexity and we already have enough work to do in Heads :) I think it's way easier to add support/docs for one-time IFD-unlocking. Benefits:

• The beauty of being device-independent (can ME/IFD/GBE blobs be shared? we'll never know)
• Users don't need to exctract or save anything
• No vector for errors added that we hardly can debug
• I guess documentation for your scenario would even be more complicated than documenting our current situation.

Let's not increase the scope of the project. Keep generating the BIOS region only. We are fine right now. We only lack some boostrapping support for users.

That said, I don't want to discourage you. Nothing is set in stone. If you want to do it all and come up with a complete, elegant solution that doesn't make building Heads harder, you may be able to convince people...

[testbird]

use case at all for networking init in x230 or x230-flash. I mean, who really is going to netboot a x230? corner case, if it exists at all.

Well, of course it's not for the daily booting "on the road", but it is very useful for "partition image" managing of the operating systems whenever there are more than just one or two devices, i.e. see the linbo tool from Knopper or clonezilla.

http://docs.linuxmuster.net/en/latest/clients/linbo/
http://www.knopper.net/linbo/index-en.html

[BlackMaria]

From what I can tell, the code would need to be customized to work anyway. It would be best saved as an example doc pointing to the commit before it was removed to show its implementation.

So I agree with the proposal to remove it.