-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512
Hi all, we see a lot of attention around KGPE-D16 maintainership problems. After discussion with Thierry Laurion (Insurgo) at OSFC2019 3mdeb decided to help in maintaining that platform by organizing crowd founding campaign or getting founds in other ways (direct sponsors).
Since we are based in Poland there is chance that even with small contribution from community we would be able to cover the costs.
Ideal plan would be to have structure similar to what we maintain for PC Engines: https://pcengines.github.io/ Where we providing signed and reproducible binaries every month and keep as close to mainline as possible. Of course if development will be active, then there always would be delta of patches held in review.
Unfortunately we don't have hardware. During OSFC 2019 Stefan left one board, but it was too late (and probably too expensive) for us to organize any shipment to Poland. We looking to have 2 mainboards one for development and one in our automated regression testing environment. Of course we will start even with just one.
If anyone is willing to help in founding, sponsoring hardware or by code development and testing we would be very grateful.
Please copy other people and share this post wherever is necessary to keep this platform alive. Positive feedback will help things rolling.
Best Regards, - -- Piotr Król Embedded Systems Consultant GPG: B2EE71E967AA9E4C https://3mdeb.com | @3mdeb_com
Hello,
On Tue, 17 Sep 2019 11:19:42 +0200 Piotr Król piotr.krol@3mdeb.com wrote:
I would be pleased if Vikings could help out by sending two KGPE-D16 systems for this purpose. You can contact me at this address for details.
Perhaps someone in CC will also be able to help out one way or the other.
On 17/09/2019 10:50, Vikings GmbH via coreboot wrote:
[...]
Thank you for your contribution to the community, Thomas.
Perhaps someone in CC will also be able to help out one way or the other.
Of course there are many things aside that are needed besides the boards. I would be happy to contribute hardware in addition to Thomas's contributions (and any other people's contributions too).
If anyone is willing to help in founding, sponsoring hardware
I would very much like to help (no, I would actually _love_ to help) in founding this project. I am very excited about any possibility of taking on maintainership or foundership duties.
or by code development and testing we would be very grateful.
Among the coreboot community I am relatively inexperienced but I have a good working knowledge of Libreboot. If experienced D16 coreboot developers who are involved in this could help me occasionally, I would be immensely grateful.
I am good at research at self-directed learning. In _most_ projects that I start to work on, after I have the information I need to start I can carry on without too much extra hand-holding.
Please copy other people and share this post wherever is necessary to keep this platform alive. Positive feedback will help things rolling.
I agree that this is a particularly important thing to keep well supported and well maintained. (I feel the same way about several other, specific, computing platforms too. I will express this in detail later.)
Aside from positive feedback, /using/ the platform is important. Education, the coreboot/D16 development toolchain, writing and sharing documentation, helping newcomers, plus /many other things/, are just as important as having a functional D16.
Kind regards,
Andrew
I'd be happy to assist as well with hardware. I have a spare fully functional KGPE-D16 with dual CPUs that can be donated to a US-side developer interested in keeping the native init alive, working, and in-tree. If enough functionality can be restored in coreboot master I can also reactivate the REACTS autotest for it -- it was shut off a long time ago due to coreboot master no longer reliably booting on the hardware, but remains mothballed for potential reactivation.
The hardware is definitely showing its age, it's slow, power hungry, uses an ancient and very limited BMC (if you can get the module for it), and still requires AMD microcode binaries, but it's still the fastest open (sans microcode) x86 platform available anywhere.
I've also got a stack of KFSN4-DRE boards (K8 era), but the K8 support was ripped out a while back IIRC. I can send these to good homes as well if there's interest. :)
Thanks!
----- Original Message -----
Hello,
I'd be happy to kick more than a few bucks towards hardware or other costs. Just need to know where to send it.
I'll also drop a post over on r/Libreboot.
Sincerely, -Matt
On Tue, Sep 17, 2019 at 1:33 PM Timothy Pearson < tpearson@raptorengineering.com> wrote:
On Tue, 17 Sep 2019 11:19:42 +0200 Piotr Król piotr.krol@3mdeb.com wrote: <snip>
If anyone is willing to help in founding, sponsoring hardware or by code development and testing we would be very grateful.
Cool! Thank you for your effort.
I don't have much funds available, but I could contribute a few spare 16 MiB flash chips I don't need anymore. Just write me an email if there's interest.
Cheers,
Merlin
Highly appreciating that afford.
Would like to mention Problems with Current Linux kernel with this Board.
( The SLUB Allocator is causing panics at boot for my builds)
Pls see:
https://www.mail-archive.com/coreboot@coreboot.org/msg53915.html
an email to coreboot-leave@coreboot.org
Hi,
maybe related:
With coreboot master (as of 20190916), 4.10 and 4.9 (compiled on Debian 10) I get kernel panics, too. Log and config attached. There is one Opteron 6328 installed in the KGPE-D16. I'm using the GRUB2 payload (which runs fine). I don't know what's causing this, I just want to provide another data point.
coreboot 4.8 and 4.8.1 were not able to load my payload (same config). For reference, I also attached the logs of that.
Finally, coreboot commit b1d26f0e92 from mid 2018 worked for me.
Cheers,
Merlin
On Wed, 18 Sep 2019 14:22:23 +0200 Kinky Nekoboi kinky_nekoboi@nekoboi.moe wrote:
This Panic i got in the past two.
Try building coreboot without Microcode included and load microcode via kernel (you need non-free repo for that)
Would be interessting if you than also my Error.
If so i can send you a deb-package with a working kernel with SLAB allocator.
Am 18.09.19 um 15:53 schrieb Merlin Büge:
I finally have found the problem:
This BUG appears when you only have memory in the Orange Slots
yikes this boathert me for such a long time
any idea how i could debug this further ?
Am 18.09.19 um 14:22 schrieb Kinky Nekoboi:
On Wed, 2 Oct 2019 00:58:43 +0200 Kinky Nekoboi kinky_nekoboi@nekoboi.moe wrote:
Not sure if that helps at all, but I'm getting reports that
CONFIG_SLAB=y CONFIG_SLAB_MERGE_DEFAULT=y CONFIG_SLAB_FREELIST_RANDOM=y
instead of
CONFIG_SLUB=y CONFIG_SLUB_CPU_PARTIAL=y
"fixes" the issues.
let me correct, you have to have modules installed on both NUMA nodes. (For example when you have an 16 core opteron, i guess the 8 core version have only one numa node inside ?
Am 02.10.19 um 09:00 schrieb Vikings GmbH: