Bring back Lenovo Thinkpad T530 to supported/tested - images are working fine

[fhvyhjriur]

The Lenovo Thinkpad T530 was disabled because there was no reports for a longer time if the build images for this device are working or broken. To protect regular users who just want known reported and booting images and not having to redo many times the disassemble work, the images get disabled for long time untested devices.
I ordered because of this a T530 and did the time consuming full disassemble work, flashed it in circuit with the known great beaglebone black and external 3.3Volt rail.
I can happily report the images in https://circleci.com/gh/tlaurion/heads/46423 (from #1672 (comment) ) are working fine.
The T530 could be brought back to the supported devices list.

Like @tlaurion wrote, Heads community people willing to help with testing are happily invited to do the same i did for the T530. Look at what is untested, test it and report back if its working.

[fhvyhjriur]

Its nice to see that now the images got build automatically when heads changes and people can install the images.

@tlaurion
Not moving those away from "unmaintained" does not make sense.
You explained what "unmaintained" is about in here:
https://github.com/linuxboot/heads/blob/master/unmaintained_boards/README.md

Quote from there:

To test those boards, move them to boards directory and follow normal build operations, test builds on boards and open an issue stating you are willing to test those when builds are made available from CircleCI in the future.

This is what its done now. The images got tested and worked fine.
But you seem to now have added a new burden to get them back to normal.
In #1673 (comment) you wrote:

Left as unmaintsined board because no board owner being able to test

This is not true. I tested it. I fulfill the point of "board owner".

and improve this board if needed.

This is not part of https://github.com/linuxboot/heads/blob/master/unmaintained_boards/README.md

[3hhh]

and improve this board if needed.

This is not part of https://github.com/linuxboot/heads/blob/master/unmaintained_boards/README.md

Even if that should be a requirement, I can still attempt that, if given some time. Anyway I agree that requiring to be a coreboot developer is a bit too much of a requirement for 99% of board owners.

@fhvyhjriur Regarding your question: I'm located in DE. If you're also somewhere in Europe, I'll send the bricked T530 to you for free, too. You can send me your address to david [at] hobach.de. At best afterwards reply in this thread that you just did it so that I know it's not someone else playing games.

[tlaurion]

and improve this board if needed.

This is not part of https://github.com/linuxboot/heads/blob/master/unmaintained_boards/README.md

Even if that should be a requirement, I can still attempt that, if given some time. Anyway I agree that requiring to be a coreboot developer is a bit too much of a requirement for 99% of board owners.

@fhvyhjriur Regarding your question: I'm located in DE. If you're also somewhere in Europe, I'll send the bricked T530 to you for free, too. You can send me your address to david [at] hobach.de. At best afterwards reply in this thread that you just did it so that I know it's not someone else playing games.

@fhvyhjriur @3hhh
Being a coreboot developer is not needed. I'm. Sorry if that's what you extracted of what I wrote before.

I am not a coreboot developer either.

I'm sorry for those walls of text, my brain works like that, which is why I'm not so good at writing documentation and I prefer doing code and documenting as code.

The complexity of keeping boards flashable by end users (Heads is now used by many not so technical users now, as opposed to before) is that amongst board owners, there are at least one or two that can tip what is going on without requiring of me to do the glue between coreboot developers, Linux developers for boards I do not own. There are a lot of examples under heads issues and PR which required such collaboration in the past, resulting in fixes that were board specific and requiring board owners to engage into fixing things for themselves (fix their own itches) by being that glue for themselves for their board to keep waking up from suspend, have raminit code under coreboot still work (regression fixes) and have their iGPU /dgpu work correctly, which is a really grey area in the coreboot world.

Agreed that the t530 doesn't have much more different then it's cousins already in tree, but yet again, history shows that x220 for example had regression in the past for S3 suspend/resume from sleep path, t430 had vbt inconsistencies, etc etc and maintenance from my side requires at least a desired involvement from older platforms owners to be able to test pronto mainly coreboot version bumps, which the t530 stayed behind two times already.

Now the t530 is tested. I just hope we have a common understanding of what is needed to keep that board as tested so my time is not lost when doing version bump PR.

Tldr: if I have at least one board owner per platform being willing to externally flash prior version in case of a brick, being able to do the glue between issues open g and tracking with coreboot devs for regression fixes, I am more then willing to bring the t530 back as tested. But if not, I am still reluctant simply because of the history of that board being untested in the past, and leaving that board untested alongside others that are promptly tested with many owners is the issue here.

I hope we understand the core issue of this board: not easy to unbrick and not many technical board owners, the official being scared to brick their devices because of flash placement on that platform. I rrpest: this is why this platform is not sold on the internet and why users chose easier to unbrick ones.

It's a human problem, not a maintenance one. I need engagement under #692 from at least one board owner willing to reflash externally when I reach out for testing, and participate with other communities so that a patch to the coreboot version under heads tree (by collaboration with coreboot devs) can be Cherry-picked and added to PR before merge. If that takes too much time, then those boards don't fit well in rolling release which Heads is under.

Feel free to ask for clarifications where needed

• engagement of at least one t530 board owner ready to unbrick a PR build
• engagement from at least one board owner willing to engage with coreboot devels so that a fix for regression is created prior of board version bump

If I have that and someone signs up under #692 to be tagged, I am ready to move the t530 as tested so that other people looking to own the t530 will know that the board won't fall as untested/unmaintained again. I unfortunately do not have the time to deal with platforms having only users as board owners. That is not possible from a maintainer perspective.

The x230t raw keyboard unfixed issue is yet another example of the x230t not being officially supported here since people expect me to fix the issue which makes that board impractical to maintain. How to document that properly? I have no answer to that but to put limits in my own engagement for free as in free beer time I can invest on platforms while others decide it's not their problem either.

[tlaurion]

You explained what "unmaintained" is about in here: https://github.com/linuxboot/heads/blob/master/unmaintained_boards/README.md

Then I should clarify some more what is written there.

@3hhh @fhvyhjriur what should be read there so it's clear for everyone what is needed of at least one board owner?

Suggestions welcome.

[fhvyhjriur]

I understood what you like to achieve and why it was not that clear at the public. I made with the github website a edit here #1696

It fulfills exactly your two points you wrote but in general for all upcoming same situations:

engagement of at least one t530 board owner ready to unbrick a PR build
engagement from at least one board owner willing to engage with coreboot devels so that a fix for regression is created prior of board version bump

It made sense for me. The first point you told is the already existing "UNTESTED". The second point you told is the already existing "UNMAINTAINED".
Fixing UNMAINTAINED file addition in heads does not require you to be a developer. If you fill up a bugreport at coreboot and provide logfiles to the coreboot developers, this is still count as maintaining.
This also helps to clarify that heads is using coreboot as upstream and not developing coreboot.

And at the end: Because there is no known issue at T530, it should get the UNMAINTAINED removed. Because there is no need of it. If there are at some point known issues with the T530 that no one care to fix them, it can get UNMAINTAINED addition again like every other device also can get of same reason the UNMAINTAINED addition.