Dear coreboot folks,
Two days ago, on November 7th, the change-sets of the topic *drop_LEGACY_SMP_INIT* [1] were submitted after being created on November 2nd [2].
The removal was announced on the list some time ago and was documented in the release notes.
1. RESOURCE_ALLOCATOR_V3 in the 4.16 release notes [3] 2. LEGACY_SMP_INIT in the 4.16, 4.17, and 4.18 release notes [4]
(I think that planned deprecations should to be listed in each release note.)
Despite the missing RESOURCE_ALLOCATOR_V3 deprecation announcement in 4.17 and 4.18, everything was done formally correct, nevertheless I would have wished, more time would have been given and the actions would have been announced once more on the mailing list.
My understanding was always, that code removal will be handled more leniently, if the required changes are being worked on. This was the case here for parallel SMP init [5] and resource allocator v4 [6]. Some change-sets even had a +1 or +2. The request for testing was also fulfilled by the users. Some of the change-sets were even authored by “non-AGESA“ folks, which was awesome to see.
Letting this effort go to waste without documenting somewhere, what needed to be done to finish these change-sets makes me sad. 3mdeb also invested resources into implementing some of the features.
The last thing I noticed, that at least for the PC Engines board removal, the approval of the maintainers listed in `MAINTAINERS` was not given, and should have been waited for. The +2 itself were also by developers normally not (very) active with AMD AGESA Open Source boards.
The points above are just my observations, and, hopefully, things can improve in the future to avoid bad feelings. I am thankful to everyone working on coreboot, and I also understand the frustration of having to maintain several code paths.
Although I own and run two of the removed boards, I am fine to move to the branch *4.18_branch* although I am not happy about it, as branches also increase maintenance burden.
The main reason for writing this message is to ask, if entities (read 3mdeb) have big interest in getting part of the boards back into the master branch, so that the already made investments are not in vain, and nobody is alienated from working upstream. If that is a goal, this effort should be coordinated as reverting commits is going to become harder and harder. mb/aopen/dxplplusu (Intel) is already worked on to be put back into the master branch [7].
Kind regards,
Paul
[1]: https://review.coreboot.org/q/topic:drop_LEGACY_SMP_INIT [2]: https://review.coreboot.org/c/coreboot/+/69111/2 [3]: https://review.coreboot.org/plugins/gitiles/coreboot/+/refs/tags/4.18/Docume... [4]: https://review.coreboot.org/plugins/gitiles/coreboot/+/refs/tags/4.18/Docume... [5]: https://review.coreboot.org/c/coreboot/+/64892 "cpu/amd/family15: Use parallel_mp init" [6]: https://review.coreboot.org/c/coreboot/+/53990 "nb/amd/agesa/family15tn: Enable RESOURCE_ALLOCATOR_V4" [7]: https://review.coreboot.org/c/coreboot/+/69339 "Revert "mb/aopen/dxplplusu: Remove board""
Hello All,
We regret to announce that PC Engines, a provider of small and low-power servers for network security, wireless networking, and embedded applications, has discontinued its sponsorship for open-source firmware. Although this is a significant change for the open-source firmware community, our commitment to supporting the hardware remains strong. At Dasharo, we aim to continue the legacy of PC Engines by distributing open-source firmware and putting the community's needs first. Our focus will be on releases and feature sets driven by community support. We are considering a subscription model to ensure stable and reliable firmware updates. Your input is important to us, and we would appreciate your feedback through our survey at https://forms.gle/MHrT2f1du1Afvwvj9. Please help us understand how we can better serve the open-source firmware community and ensure its success in the future.
Full details: https://docs.dasharo.com/variants/pc_engines/post-eol-fw-announcement
Best regards, Norbert Kamiński Junior Marketing Specialist at 3mdeb
On 9.11.2022 13:36, Paul Menzel wrote:
Dear coreboot folks,
Two days ago, on November 7th, the change-sets of the topic *drop_LEGACY_SMP_INIT* [1] were submitted after being created on November 2nd [2].
The removal was announced on the list some time ago and was documented in the release notes.
- RESOURCE_ALLOCATOR_V3 in the 4.16 release notes [3]
- LEGACY_SMP_INIT in the 4.16, 4.17, and 4.18 release notes [4]
(I think that planned deprecations should to be listed in each release note.)
Despite the missing RESOURCE_ALLOCATOR_V3 deprecation announcement in 4.17 and 4.18, everything was done formally correct, nevertheless I would have wished, more time would have been given and the actions would have been announced once more on the mailing list.
My understanding was always, that code removal will be handled more leniently, if the required changes are being worked on. This was the case here for parallel SMP init [5] and resource allocator v4 [6]. Some change-sets even had a +1 or +2. The request for testing was also fulfilled by the users. Some of the change-sets were even authored by “non-AGESA“ folks, which was awesome to see.
Letting this effort go to waste without documenting somewhere, what needed to be done to finish these change-sets makes me sad. 3mdeb also invested resources into implementing some of the features.
The last thing I noticed, that at least for the PC Engines board removal, the approval of the maintainers listed in `MAINTAINERS` was not given, and should have been waited for. The +2 itself were also by developers normally not (very) active with AMD AGESA Open Source boards.
The points above are just my observations, and, hopefully, things can improve in the future to avoid bad feelings. I am thankful to everyone working on coreboot, and I also understand the frustration of having to maintain several code paths.
Although I own and run two of the removed boards, I am fine to move to the branch *4.18_branch* although I am not happy about it, as branches also increase maintenance burden.
The main reason for writing this message is to ask, if entities (read 3mdeb) have big interest in getting part of the boards back into the master branch, so that the already made investments are not in vain, and nobody is alienated from working upstream. If that is a goal, this effort should be coordinated as reverting commits is going to become harder and harder. mb/aopen/dxplplusu (Intel) is already worked on to be put back into the master branch [7].
Kind regards,
Paul
Hi Norbert
Please check the attached.
Norbert Kamiński norbert.kaminski@3mdeb.com 於 2023年2月3日 週五 下午4:30寫道：
Hello All,
We regret to announce that PC Engines, a provider of small and low-power servers for network security, wireless networking, and embedded applications, has discontinued its sponsorship for open-source firmware. Although this is a significant change for the open-source firmware community, our commitment to supporting the hardware remains strong. At Dasharo, we aim to continue the legacy of PC Engines by distributing open-source firmware and putting the community's needs first. Our focus will be on releases and feature sets driven by community support. We are considering a subscription model to ensure stable and reliable firmware updates. Your input is important to us, and we would appreciate your feedback through our survey at https://forms.gle/MHrT2f1du1Afvwvj9. Please help us understand how we can better serve the open-source firmware community and ensure its success in the future.
Full details: https://docs.dasharo.com/variants/pc_engines/post-eol-fw-announcement
Best regards, Norbert Kamiński Junior Marketing Specialist at 3mdeb
On 9.11.2022 13:36, Paul Menzel wrote:
Dear coreboot folks,
Two days ago, on November 7th, the change-sets of the topic *drop_LEGACY_SMP_INIT* [1] were submitted after being created on November 2nd [2].
The removal was announced on the list some time ago and was documented in the release notes.
- RESOURCE_ALLOCATOR_V3 in the 4.16 release notes [3]
- LEGACY_SMP_INIT in the 4.16, 4.17, and 4.18 release notes [4]
(I think that planned deprecations should to be listed in each release note.)
Despite the missing RESOURCE_ALLOCATOR_V3 deprecation announcement in 4.17 and 4.18, everything was done formally correct, nevertheless I would have wished, more time would have been given and the actions would have been announced once more on the mailing list.
My understanding was always, that code removal will be handled more leniently, if the required changes are being worked on. This was the case here for parallel SMP init [5] and resource allocator v4 [6]. Some change-sets even had a +1 or +2. The request for testing was also fulfilled by the users. Some of the change-sets were even authored by “non-AGESA“ folks, which was awesome to see.
Letting this effort go to waste without documenting somewhere, what needed to be done to finish these change-sets makes me sad. 3mdeb also invested resources into implementing some of the features.
The last thing I noticed, that at least for the PC Engines board removal, the approval of the maintainers listed in `MAINTAINERS` was not given, and should have been waited for. The +2 itself were also by developers normally not (very) active with AMD AGESA Open Source boards.
The points above are just my observations, and, hopefully, things can improve in the future to avoid bad feelings. I am thankful to everyone working on coreboot, and I also understand the frustration of having to maintain several code paths.
Although I own and run two of the removed boards, I am fine to move to the branch *4.18_branch* although I am not happy about it, as branches also increase maintenance burden.
The main reason for writing this message is to ask, if entities (read 3mdeb) have big interest in getting part of the boards back into the master branch, so that the already made investments are not in vain, and nobody is alienated from working upstream. If that is a goal, this effort should be coordinated as reverting commits is going to become harder and harder. mb/aopen/dxplplusu (Intel) is already worked on to be put back into the master branch [7].
Kind regards,
Paul
[3]:
https://review.coreboot.org/plugins/gitiles/coreboot/+/refs/tags/4.18/Docume...
[4]:
https://review.coreboot.org/plugins/gitiles/coreboot/+/refs/tags/4.18/Docume...
coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-leave@coreboot.org
-
Lee.Chain-Wu 李謙吾 TAO -
Norbert Kamiński -
Paul Menzel