Add support for t520, t530 and w530 #1059
Conversation
re-uploading executable.
|
@eganonoa thanks for your contribution!
|
|
it's actually a good moment to question if we should support hotp-verification and other board configs then maximized and hotp-maximized boards. @eganonoa : thoughts? |
@tlaurion thanks for asking me this. Personally, I do not see the value. Am I right in saying that they are only really necessary if vendors have shipped non-maximized boards to consumers without unlocking ifd first, so an internal flash is not possible at all? If so, that seems appropriate for a fork by those vendors and not ultimately master. The maximized boards have huge long-term advantages and I think continuing with non-maximized boards in master has the risk of encouraging people with non-maximized boards to try to flash the latest and greatest and finding themselves with bricks that need external flashing that they aren't equipped to perform. I can tell you that I have made that mistake myself twice, simply by forgetting, despite running heads-based computers in my small, but global, org for over two years now. It isn't fun having to urgently ship a new computer to a remote worker and have them ship theirs back simply because I've forgotten to run from the command line and not via the GUI (I've always flashed externally all devices and unlocked). It seems to me that, unless there is some genuine benefit of the non-maximized boards, heads master shouldn't be encouraging them. So personally, I'd drop them entirely. At a minimum, while I can see the benefit for legacy boards, for new boards, not yet ported into heads master like the t530, why encourage this? For example, do you really want (can handle) a flood of folks coming over from 1vyrain with issues and bricks caused by the ease of flashing combined with the ease that that flashing leads to a brick? Nonetheless, as I'll note in my reply to your other comment, it is possible for a non-max verification board for the t530, and I can test it. I'll just never have any interest myself in using it. |
Thanks @tlaurion! Happy to help and to have a new set of devices available. The t530 is a great computer and I'm already seeing the big benefit of it in these COVID days: completely silent, staying very cool even with endless videoconferencing and P2P calls, bigger and better screen than t430, better processors than x230. Of course, it travels less. But these days we're finding the real benefit of heads to be related less to travel and more to office and house break-ins (sadly not a non-negligible concern for orgs on the radar of certain state actors, irrespective of location) so travel isn't really the only benefit of heads (sadly!). Anyway, to go through your bullets one-by-one:
This builds fine (using the x230 equivalent as based). I'll give it a test and if it works will add it in, irrespective of my views on the non-max boards (responded separately on that).
I can't seem to get a clean coreboot 4.15 build, including of existing boards on heads:master. I got an x230-hotp-maximized build to work, but it seems to have reverted to 4.14 automatically (not sure at all what happens there). So this seems like something for a separate line of work covering the whole of heads. Happy to work on that.
I'm not sure I really understand this. I've built these boards as if the dGPU doesn't exist at all, and indeed after the fact this is how they act: there is no dGPU. In other words I used boards designed for ordinary, integrated graphics boards -- x220, t420, x230, t430 -- and made no changes relevant to having a dGPU. In my experience with other coreboot systems (vanilla, e.g. t440p, and libreboot, e.g. with a w500) I've been able to use roms built for integrated graphics motherboards interchangeably with motherboards with a dGPU. As long as you don't care about the dGPU, I've always assumed and seen that you can just act as if they don't exist. The challenge only seems to arise when you want to actually initialize the dGPU, and then you've got a whole host of things to deal with. Given that, with these xx20 and xx30 boards you are talking about pretty junky dGPUs then I'm not sure it's worth the headache, except for tinkerers to figure out on their own systems. Long way of saying that I'm not sure we need that config change for integrated graphics-only boards (but, of course, we'd need someone with such a board to confirm that as I only have the dGPU version for the t530). |
@tlaurion: Just to add a little to what I have written above after some additional reflection, servers might be a good reason to have a minimal heads. I'm not sure if Purism see the need for a full-blown maximized heads (inc. with their new extension of pureboot into the root partition) for a server, but they would be the best to ask if there is a value there or whether a maximized board is good there also. But for the desktops/laptops, (a) I really don't think vendors should be shipping solely internally-flashed devices, especially at the price point that these 10-year old computers are being sold at (it kind of goes against the whole ethos and marketing, and besides at new computer prices the least that could be done is to open up a computer and give it a totally new lease of life); and (b) as a niche security/free software product I think the general trend should be towards encouraging folks to take as much ownership of the computer as possible. At a minimum, if these boards are being continued for support in heads:master, I would vote for changing the name from "non-maximized" to "minimal" to highlight better what is being given/used, and the boards themselves and the README should have some very clear language about what they are and their limitations. Ideally a warning about not being able to migrate at all to a maximized board with more functionality should be displayed clearly somewhere in Heads itself, either upfront on boot or in the dialogue around updating the bios. |
|
Too many things in my mind to write on a PR. Looking forward to talk in a more dynamic way first so we can fix this correctly. Otherwise, its a massive maintainership problem, even more if same issues of t430 boards will hit those with dGPU issues. |
|
Also, please look into https://github.com/osresearch/heads/pull/828/files#diff-FF759347F6D9CDB5A35A9933161A9558 |
Tested and working for W530. Built off of heads:master and using Coreboot 4.14. Board contains dGPU but build ignores dGPU's existence and does not initialize. As with T530 (also tested with a dGPU board, not initialized), no problems encountered with display init that apparently affect certain t430's with dGPU.
eganonoa
changed the title
@tlaurion, as discussed, very happy on my end not to have non-maximized boards. Agree this adds additional complexity to maintaining the boards. Noting here though that the dGPU issue impacting the t430 does not appear present in the t530 or w530 as I have tested both with the dGPU. |
@tlaurion There's a lot going on here. Has it been tested on the other boards? |
@eganonoa sorry about that, I was thinking https://github.com/osresearch/heads/blob/05b76ed4cbdf817b0a1bd3c77185e55d33709738/initrd/bin/flash.init because there is not anything, really, changing between the new added flash init scritpts. Additionally, the more I think about it, the less I believe in adding legacy boards. They should be flashed as maximized, and linuxboot/heads-wiki#82 should be commented/modified accordingly. |
In its current form, Heads has so many variables it appears very difficult to determine the cause of issues being raised. There is a risk in development being stalled or taken off track by a rise of very specific bugs reported that are not readily reproducible or only appears in a very specific set of circumstances. In addition, its increasingly difficult to identify separate feature requests from bug reports. These three templates provide templates for: (a) feature requests; (b) bug reports related to build errors for Heads; and (b) bug reports that come from the flashing or operation of Heads. They are designed to better help the identification of the best people to respond to any given issue, as well as to help triage issues.
Use issue templates
|
Closing to clean up. Will reissue. |
Successfully tested using Coreboot 4.13 and Coreboot 4.14 for the following boards:
Boards currently point to Coreboot 4.14. T530 tested on dGPU and non-dGPU boards. W530 tested on dGPU board (I believe w530 only comes with the dGPU). Built as if the dGPU in either model does not exist (i.e. once flashed no dGPU will be detected or initialized, allowing to use smaller charger plug and make full use of the big heat sink for significantly lower temperatures).
Note: it can be tricky to properly read the 8MB chip on the T530 and W530 (see #996). This appears to be because the two chips share a power source on these boards (see generally). This is true for both the Rasbperry Pi and the CH431a. There appears to be two workarounds: (1) the Wake on Lan method (which has the one downside of only working once, because it is not supported by coreboot and is, therefore, not available after flashing); or (2) keeping the CMOS battery plugged in, which works also post-flashing. Both methods provide a little extra power to the board and appear to then be sufficient to get enough power to the 8MB chip to get a proper read of it. The Skulls team generally suggest using an external power source with the CH341a, and it's possible that this might help, but I have not tested (see here)