[coreboot] Re: KGPE-D16 maintainership
On Wed, 2 Oct 2019 00:58:43 +0200 Kinky Nekoboi wrote: > 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: > > > > 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 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. > >> 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, > > > ___ > coreboot > > > mailing list -- coreboot@coreboot.org > To unsubscribe > > send an email to coreboot-le...@coreboot.org > > > > ___ > > coreboot mailing list -- coreboot@coreboot.org > > To unsubscribe send an email to coreboot-le...@coreboot.org -- Best regards/Mit freundlichen Grüßen/Cordialement/Met vriendelijke groet The Vikings Team Thomas Umbach Web: https://www.vikings.net/ Store: https://store.vikings.net/ Phone: +49 69 247 54 91 0 Fax: +49 69 247 50 339 Follow us on Mastodon: https://social.vikings.net/@vikings Follow us on Twitter: https://twitter.com/vikingslibre Vikings GmbH Sauerackerweg 14, 60529 Frankfurt/Main, Germany Register Court: AG Frankfurt am Main Register No.: HR B 84497, CEO: Thomas Umbach Tax Office: Frankfurt am Main, VATIN: DE254094338 GPG key fingerprint: FD5E 2543 EE62 7395 00A6 9FBB F228 7A48 7CA2 3FA5 pgpOZBF6cQGAr.pgp Description: OpenPGP digital signature ___ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
[coreboot] Re: KGPE-D16 maintainership
Can you start with a memtest run with the hardware configuration that causes the kernel bug to trigger? - Original Message - > From: "Kinky Nekoboi" > To: "Vikings GmbH" > Cc: "Piotr Król" , "coreboot" , > "insurgo" > Sent: Wednesday, October 2, 2019 2:44:22 AM > Subject: [coreboot] Re: KGPE-D16 maintainership > 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: >> On Wed, 2 Oct 2019 00:58:43 +0200 >> Kinky Nekoboi wrote: >>> 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: >>>> 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 >> 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. >> >>>>> 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, >>>>> ___ > coreboot >>>>> mailing list -- coreboot@coreboot.org > To unsubscribe >>>> send an email to coreboot-le...@coreboot.org >>>> >>>> ___ >>>> coreboot mailing list -- coreboot@coreboot.org >>>> To unsubscribe send an email to coreboot-le...@coreboot.org >> >> > > > ___ > coreboot mailing list -- coreboot@coreboot.org > To unsubscribe send an email to coreboot-le...@coreboot.org ___ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
[coreboot] Re: KGPE-D16 maintainership
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: > On Wed, 2 Oct 2019 00:58:43 +0200 > Kinky Nekoboi wrote: >> 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: >>> 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 > 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. > 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, ___ > coreboot mailing list -- coreboot@coreboot.org > To unsubscribe >>> send an email to coreboot-le...@coreboot.org >>> >>> ___ >>> coreboot mailing list -- coreboot@coreboot.org >>> To unsubscribe send an email to coreboot-le...@coreboot.org > > signature.asc Description: OpenPGP digital signature ___ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
[coreboot] Re: KGPE-D16 maintainership
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: > > 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 > > > >> 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, > > ___ > coreboot mailing list -- > > coreboot@coreboot.org > To unsubscribe > send an email to coreboot-le...@coreboot.org > > ___ > coreboot mailing list -- coreboot@coreboot.org > To unsubscribe send an email to coreboot-le...@coreboot.org signature.asc Description: OpenPGP digital signature ___ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
[coreboot] Re: KGPE-D16 maintainership
On 9/23/19 4:42 AM, Arthur Heymans wrote:
> Hi
>
> Thanks for wanting to maintain this platform!
>
> There are a issues with the amdfam10 codebase that could be improved
> upon. I'll try to list a few of them, to give an idea of what
> maintaining this code in 2019 could mean.
>
> So first and foremost:
> 1) The amdfam10 codebase (terminology-wise this always means non-agesa
> in this context) suffers from a romcc romstage past. This code is
> derived from code that used to be compiled with romcc instead of running
> in CAR. The result of that is a big amount of romstage boilerplate code
> and lots of #include *.c in the mainboard code, that is often not
> mainboard specific. To give an example romstage spinlocks and memory
> tests are implemented in the kgpe-d16 romstage.c file while not being
> mainboard specific at all. These practices result in an unusually large
> amount of unmaintained code in mainboard dirs with a fragile inclusion
> order of headers (and *.c files!).
>
> Other issues pertain to coreboot wanting to move forward by mandating a
> few features (relocatable ramstage, postcar
> stage/no_car_global_migration, c environment bootblock):
> 2) relocatable ramstage: This is just a Kconfig switch to build the
> ramstage as a relocatable stage instead of statically linking it to
> execute at CONFIG_RAM_BASE. Typically you want to set up some caching of
> where cbmem is going to be to speed up ramstage, but on amd hardware
> it's bit more complicated. Part of ramstage is to initialize AP's and AP's
> will eventually jump to ramstage code. On AMD hardware however there is
> a TOP_MEM MTRR that creates a boundary between ram and mmio below 4G. If
> this is configured to be below cbmem AP's won't execute code. I see a
> few proper solutions:
> - AP's are also active during the romstage -> try to sync MTRR's at the
> end of romstage.
> - Use the parallel mp init code and modify the relocatable SIPI vector
> stub to have the MTRR's as arguments instead of a pointer to the BSP
> MTRR settings, in order to copy them.
>
> https://review.coreboot.org/c/coreboot/+/30063 is an attempt to make it
> work but by setting TOP_MEM to something sufficiently large...
>
> 3) Postcar-stage: This development goes hand in hand with relocatable
> ramstage, as it easily allows to program MTRR's to set up caching cbmem.
> If you tearing down CAR during romstage you need to take special care
> for where you're globals are (before and after CAR). Tearing down CAR in
> a separate stage, hence having a romstage with a clean program boundary,
> as a solution allows to get rid of a lot of code to deal with globals.
>
> https://review.coreboot.org/c/coreboot/+/30064/ is an attempt to
> implement it on amdfam10
>
> 4) C_ENVIRONMENT_BOOTBLOCK: romcc is an unmaintained 20k+ lines of C
> code in one file program, that imposes some restrictions and workarounds
> in C code. On older platforms it is used to compile a bootblock that
> often does nothing more than loading {normal,fallback}/romstage. The CAR
> setup happens at the start of romstage. The alternative is to move the CAR
> init to the bootblock and compile the bootblock with gcc. One big
> functional advantage is the ability to have a separate verstage running
> in CAR before romstage. This broadens the scope of what can be placed in
> RW_A/B slot in a VBOOT setup.
>
> 5) a few minor things: coreboot often has multiple methods of achieving
> more or less the same things, with newer methods being better in some
> aspects. It would be great if:
> - for saving the raminit timings the drivers/mrc_cache code was used
> instead of the custom implementation in
> northbridge/amd/amdmct/mct_ddr3/s3utils.c
> - for AP init CONFIG_PARALLEL_MP were used instead of the old
> cpu/x86/lapic/lapic_cpu_init.c code.
> - A stage cache were set up in TSEG to ensure the OS can't trash the
> ramstage in cbmem on S3 resume.
>
>
> I hope this list provides some useful pointers to where to code can be
> improved. Feel free to add me on reviews.
Thanks Arthur, awesome inputs.
>
>
> Piotr Król writes:
>
>> 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.
On my side, I'm committing to spin the need of support into Libreboot
communities, open source privacy forums and in the real world in
[coreboot] Re: KGPE-D16 maintainership
On September 23, 2019 8:42:04 AM UTC, Arthur Heymans wrote: >Hi > >Thanks for wanting to maintain this platform! > >There are a issues with the amdfam10 codebase that could be improved >upon. I'll try to list a few of them, to give an idea of what >maintaining this code in 2019 could mean. Awesome points, Arthur. Thanks a bunch! > >So first and foremost: >1) The amdfam10 codebase (terminology-wise this always means non-agesa >in this context) suffers from a romcc romstage past. This code is >derived from code that used to be compiled with romcc instead of >running >in CAR. The result of that is a big amount of romstage boilerplate code >and lots of #include *.c in the mainboard code, that is often not >mainboard specific. To give an example romstage spinlocks and memory >tests are implemented in the kgpe-d16 romstage.c file while not being >mainboard specific at all. These practices result in an unusually large >amount of unmaintained code in mainboard dirs with a fragile inclusion >order of headers (and *.c files!). > >Other issues pertain to coreboot wanting to move forward by mandating a >few features (relocatable ramstage, postcar >stage/no_car_global_migration, c environment bootblock): >2) relocatable ramstage: This is just a Kconfig switch to build the >ramstage as a relocatable stage instead of statically linking it to >execute at CONFIG_RAM_BASE. Typically you want to set up some caching >of >where cbmem is going to be to speed up ramstage, but on amd hardware >it's bit more complicated. Part of ramstage is to initialize AP's and >AP's >will eventually jump to ramstage code. On AMD hardware however there is >a TOP_MEM MTRR that creates a boundary between ram and mmio below 4G. >If >this is configured to be below cbmem AP's won't execute code. I see a >few proper solutions: >- AP's are also active during the romstage -> try to sync MTRR's at the > end of romstage. > - Use the parallel mp init code and modify the relocatable SIPI vector > stub to have the MTRR's as arguments instead of a pointer to the BSP > MTRR settings, in order to copy them. > >https://review.coreboot.org/c/coreboot/+/30063 is an atte On my side, I'm committing to spin the need of support into Libreboot communities and open source forums and security trainings I do for organisation for self hosting needs. I also commit of giving a margin of Insurgo profits following needs to cover part of the maintenance fees. Sorry to not have jumped in preciously, I'm crazy busy with Insurgo tasks and looking myself for collaboration to build a cooperative business platform and modify things so I can be completely replaceable into doing the whole production chain for the PrivacyBeast x230. Both from a Heads perspective and from a QubesOS perspective. Let me know what I can do to help on a community basis and what are the costs to cover. I'll do my best. Thanks a bunch for showing interest into keeping that platform alive. Thierry/Insurgo -- Sent from /e/ Mail ___ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
[coreboot] Re: KGPE-D16 maintainership
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: > 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 wrote: > >> 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 >> >> >> >>> 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, >>> ___ > coreboot mailing list -- >>> coreboot@coreboot.org > To unsubscribe send >> an email to coreboot-le...@coreboot.org > > signature.asc Description: OpenPGP digital signature ___ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
[coreboot] Re: KGPE-D16 maintainership
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 wrote: > 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 > > > > > 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, > > ___ > coreboot mailing list -- > > coreboot@coreboot.org > To unsubscribe send > an email to coreboot-le...@coreboot.org -- Merlin Büge defconfig Description: Binary data cb4.10_linuxkernel_panic_log Description: Binary data cb4.8.1_payload_not_loaded_log Description: Binary data cb4.8_payload_not_loaded_log Description: Binary data ___ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
[coreboot] Re: KGPE-D16 maintainership
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 > 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, > ___ > coreboot mailing list -- > coreboot@coreboot.org > To unsubscribe send an email to coreboot-le...@coreboot.org signature.asc Description: OpenPGP digital signature ___ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
[coreboot] Re: KGPE-D16 maintainership
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 < tpear...@raptorengineering.com> wrote: > 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 - > > From: "Vikings GmbH" > > To: "Piotr Król" , insu...@riseup.net > > Cc: "coreboot" , "Timothy Pearson" < > tpear...@raptorengineering.com>, "Andrew Luke Nesbit" > > > > Sent: Tuesday, September 17, 2019 4:50:35 AM > > Subject: Re: KGPE-D16 maintainership > > > Hello, > > > > On Tue, 17 Sep 2019 11:19:42 +0200 > > Piotr Król wrote: > >> -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. > > > > 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. > > > >> 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 > >> -BEGIN PGP SIGNATURE- > >> > >> iQIzBAEBCgAdFiEE4DCbLYWmfoRjKeNLsu5x6WeqnkwFAl2ApSoACgkQsu5x6Weq > >> nkw0XQ//WeO+U6VFcr6wsfCkv5qXnKVHb6XDXyEknhu7Q82HZ9Hx+0IiZ0+ikzVZ > >> oLU36euPwlHoRFh3HPm34DHeeYAZYzzsdc41+0MZJao152CGZJQwe+pqD/JeymOU > >> Jky+PhULeGKXt22ftbxte1ac82tRDFt//0Yc07qxP9G/CboZ8sjckKjfyfoy5PFm > >> 9jRFwdZUMbU42mU+NYLn/iXGWM/+mxC+ghncQBYwwGX1npr1r5gSiZS9ImoHFpgj > >> DQaaUQq2v8vS1uvYZ84vVEXeOljTkzFg7UyUZq3sSob8bA/a42rsgFMPVI6Bpc5R > >> lAEdhBZgMaD4jjO2GK+3zFSy32pBvK71tzwrdLjhb/bjjN1phHy2zbwTebFWlyiu > >> HQJ/+iu4uoTQj69GT9i7HLyngorh37GWFHKScDDzEASnSO868ELhlrt+yHwyY284 > >> EAe7dTOhOtfdxJOKcfdyUez5nwPZON4AXEVSvLWLUv4r+f82CG89f+LLg7rbZH5n > >> C0HnUOJas89xEvRhXChTBHnM9NBKSWpch5uZ5SbZHb/JCWBb26yT6Ua46H0STFRh > >> y+pWHc8AN76FQnWvpYer5F3hyVEX1+wAsi+RJMROFUejCn3lCl5ogAnT4ZRCqzo3 > >> 61Ao6dYmtYhaQ3JjZ+5bv3926ZwRjvr7i5t9bHf9THXCn1UobjY= > >> =wYUt > >> -END PGP SIGNATURE- > > > > > > > > > > -- > > Best regards/Mit freundlichen Grüßen/Cordialement/Met vriendelijke groet > > Thomas Umbach > > > > Web: https://www.vikings.net/ > > Phone: +49 69 247 54 91 0 > > > > Follow us on GNUsocial: https://quitter.se/vikings > > Follow us on Twitter: https://twitter.com/vikingslibre > > > > Vikings GmbH > > Sauerackerweg 14, 60529 Frankfurt/Main, Germany > > Register Court: AG Frankfurt am Main > > Register No.: HR B 84497, CEO: Thomas Umbach > > Tax Office: Frankfurt am Main, VATIN: DE254094338 > > > > GPG key fingerprint: FD5E 2543 EE62 7395 00A6 9FBB
[coreboot] Re: KGPE-D16 maintainership
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 - > From: "Vikings GmbH" > To: "Piotr Król" , insu...@riseup.net > Cc: "coreboot" , "Timothy Pearson" > , "Andrew Luke Nesbit" > > Sent: Tuesday, September 17, 2019 4:50:35 AM > Subject: Re: KGPE-D16 maintainership > Hello, > > On Tue, 17 Sep 2019 11:19:42 +0200 > Piotr Król wrote: >> -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. > > 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. > >> 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 >> -BEGIN PGP SIGNATURE- >> >> iQIzBAEBCgAdFiEE4DCbLYWmfoRjKeNLsu5x6WeqnkwFAl2ApSoACgkQsu5x6Weq >> nkw0XQ//WeO+U6VFcr6wsfCkv5qXnKVHb6XDXyEknhu7Q82HZ9Hx+0IiZ0+ikzVZ >> oLU36euPwlHoRFh3HPm34DHeeYAZYzzsdc41+0MZJao152CGZJQwe+pqD/JeymOU >> Jky+PhULeGKXt22ftbxte1ac82tRDFt//0Yc07qxP9G/CboZ8sjckKjfyfoy5PFm >> 9jRFwdZUMbU42mU+NYLn/iXGWM/+mxC+ghncQBYwwGX1npr1r5gSiZS9ImoHFpgj >> DQaaUQq2v8vS1uvYZ84vVEXeOljTkzFg7UyUZq3sSob8bA/a42rsgFMPVI6Bpc5R >> lAEdhBZgMaD4jjO2GK+3zFSy32pBvK71tzwrdLjhb/bjjN1phHy2zbwTebFWlyiu >> HQJ/+iu4uoTQj69GT9i7HLyngorh37GWFHKScDDzEASnSO868ELhlrt+yHwyY284 >> EAe7dTOhOtfdxJOKcfdyUez5nwPZON4AXEVSvLWLUv4r+f82CG89f+LLg7rbZH5n >> C0HnUOJas89xEvRhXChTBHnM9NBKSWpch5uZ5SbZHb/JCWBb26yT6Ua46H0STFRh >> y+pWHc8AN76FQnWvpYer5F3hyVEX1+wAsi+RJMROFUejCn3lCl5ogAnT4ZRCqzo3 >> 61Ao6dYmtYhaQ3JjZ+5bv3926ZwRjvr7i5t9bHf9THXCn1UobjY= >> =wYUt >> -END PGP SIGNATURE- > > > > > -- > Best regards/Mit freundlichen Grüßen/Cordialement/Met vriendelijke groet > Thomas Umbach > > Web: https://www.vikings.net/ > Phone: +49 69 247 54 91 0 > > Follow us on GNUsocial: https://quitter.se/vikings > Follow us on Twitter: https://twitter.com/vikingslibre > > Vikings GmbH > Sauerackerweg 14, 60529 Frankfurt/Main, Germany > Register Court: AG Frankfurt am Main > Register No.: HR B 84497, CEO: Thomas Umbach > Tax Office: Frankfurt am Main, VATIN: DE254094338 > > GPG key fingerprint: FD5E 2543 EE62 7395 00A6 9FBB F228 7A48 7CA2 3FA5 ___ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
[coreboot] Re: KGPE-D16 maintainership
On Tue, 17 Sep 2019 11:19:42 +0200 Piotr Król wrote: > 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 > > 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 > -BEGIN PGP SIGNATURE- > > iQIzBAEBCgAdFiEE4DCbLYWmfoRjKeNLsu5x6WeqnkwFAl2ApSoACgkQsu5x6Weq > nkw0XQ//WeO+U6VFcr6wsfCkv5qXnKVHb6XDXyEknhu7Q82HZ9Hx+0IiZ0+ikzVZ > oLU36euPwlHoRFh3HPm34DHeeYAZYzzsdc41+0MZJao152CGZJQwe+pqD/JeymOU > Jky+PhULeGKXt22ftbxte1ac82tRDFt//0Yc07qxP9G/CboZ8sjckKjfyfoy5PFm > 9jRFwdZUMbU42mU+NYLn/iXGWM/+mxC+ghncQBYwwGX1npr1r5gSiZS9ImoHFpgj > DQaaUQq2v8vS1uvYZ84vVEXeOljTkzFg7UyUZq3sSob8bA/a42rsgFMPVI6Bpc5R > lAEdhBZgMaD4jjO2GK+3zFSy32pBvK71tzwrdLjhb/bjjN1phHy2zbwTebFWlyiu > HQJ/+iu4uoTQj69GT9i7HLyngorh37GWFHKScDDzEASnSO868ELhlrt+yHwyY284 > EAe7dTOhOtfdxJOKcfdyUez5nwPZON4AXEVSvLWLUv4r+f82CG89f+LLg7rbZH5n > C0HnUOJas89xEvRhXChTBHnM9NBKSWpch5uZ5SbZHb/JCWBb26yT6Ua46H0STFRh > y+pWHc8AN76FQnWvpYer5F3hyVEX1+wAsi+RJMROFUejCn3lCl5ogAnT4ZRCqzo3 > 61Ao6dYmtYhaQ3JjZ+5bv3926ZwRjvr7i5t9bHf9THXCn1UobjY= > =wYUt > -END PGP SIGNATURE- > ___ > coreboot mailing list -- coreboot@coreboot.org > To unsubscribe send an email to coreboot-le...@coreboot.org -- Merlin Büge ___ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
[coreboot] Re: KGPE-D16 maintainership
On 17/09/2019 10:50, Vikings GmbH via coreboot wrote: On Tue, 17 Sep 2019 11:19:42 +0200 Piotr Król wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 [...] 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. 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. 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 -- OpenPGP key: EB28 0338 28B7 19DA DAB0 B193 D21D 996E 883B E5B9 ___ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
[coreboot] Re: KGPE-D16 maintainership
Hello, On Tue, 17 Sep 2019 11:19:42 +0200 Piotr Król wrote: > -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. 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. > 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 > -BEGIN PGP SIGNATURE- > > iQIzBAEBCgAdFiEE4DCbLYWmfoRjKeNLsu5x6WeqnkwFAl2ApSoACgkQsu5x6Weq > nkw0XQ//WeO+U6VFcr6wsfCkv5qXnKVHb6XDXyEknhu7Q82HZ9Hx+0IiZ0+ikzVZ > oLU36euPwlHoRFh3HPm34DHeeYAZYzzsdc41+0MZJao152CGZJQwe+pqD/JeymOU > Jky+PhULeGKXt22ftbxte1ac82tRDFt//0Yc07qxP9G/CboZ8sjckKjfyfoy5PFm > 9jRFwdZUMbU42mU+NYLn/iXGWM/+mxC+ghncQBYwwGX1npr1r5gSiZS9ImoHFpgj > DQaaUQq2v8vS1uvYZ84vVEXeOljTkzFg7UyUZq3sSob8bA/a42rsgFMPVI6Bpc5R > lAEdhBZgMaD4jjO2GK+3zFSy32pBvK71tzwrdLjhb/bjjN1phHy2zbwTebFWlyiu > HQJ/+iu4uoTQj69GT9i7HLyngorh37GWFHKScDDzEASnSO868ELhlrt+yHwyY284 > EAe7dTOhOtfdxJOKcfdyUez5nwPZON4AXEVSvLWLUv4r+f82CG89f+LLg7rbZH5n > C0HnUOJas89xEvRhXChTBHnM9NBKSWpch5uZ5SbZHb/JCWBb26yT6Ua46H0STFRh > y+pWHc8AN76FQnWvpYer5F3hyVEX1+wAsi+RJMROFUejCn3lCl5ogAnT4ZRCqzo3 > 61Ao6dYmtYhaQ3JjZ+5bv3926ZwRjvr7i5t9bHf9THXCn1UobjY= > =wYUt > -END PGP SIGNATURE- -- Best regards/Mit freundlichen Grüßen/Cordialement/Met vriendelijke groet Thomas Umbach Web: https://www.vikings.net/ Phone: +49 69 247 54 91 0 Follow us on GNUsocial: https://quitter.se/vikings Follow us on Twitter: https://twitter.com/vikingslibre Vikings GmbH Sauerackerweg 14, 60529 Frankfurt/Main, Germany Register Court: AG Frankfurt am Main Register No.: HR B 84497, CEO: Thomas Umbach Tax Office: Frankfurt am Main, VATIN: DE254094338 GPG key fingerprint: FD5E 2543 EE62 7395 00A6 9FBB F228 7A48 7CA2 3FA5 pgpDCvK9K1_Ze.pgp Description: OpenPGP digital signature ___ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
