[coreboot] Re: KGPE-D16 maintainership

[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


signature.asc
Description: OpenPGP digital signature
___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] Re: OpenBMC on KGPE-D16, somebody has it working?

[ron minnich]

If you like running systemd on your bmc, the minimum 60 seconds
openbmc takes to boot, the complex, fragile, and long time it takes to
build from source, and the openbmc stack's need for giant memory
footprint and lots of nvme, stop reading.

IF, OTOH, you like the idea of a very lightweight stack, which builds
in minutes not hours, and needs maybe 32M of memory to run, and boots
much faster, well, you might want to checkout u-bmc.

https://github.com/u-root/u-bmc

On Sat, Oct 12, 2019 at 2:00 PM Kinky Nekoboi  wrote:
>
> Debian 10.
>
> Thats perfect i  have the nessary flashing tools.
>
>
> Am 12.10.19 um 22:57 schrieb Merlin Büge:
> > Hi,
> >
> >> Due to lib depenency hell i am not able to build openbmc myself atm.
> >>
> > Are you building on Debian (9 or 10)?
> >
> >> Does somebody has openbmc working for there kgpe-d16 system and can
> >> maybe send me a rom ?
> > I'll send you a separate email.
> >
> >> Can i flash the module with a Programmer and testclip or only internally?
> > Yes, a SOIC16 testclip and an SPI programmer like the CH341a will work.
> >
> >
> > Merlin
> >
> >
>
> ___
> 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: OpenBMC on KGPE-D16, somebody has it working?

[Kinky Nekoboi]

This sounds promissing, and Out-ofband-managetment should be small and kiss.

Will take a look later but my first goal is to get the AST2500 to work
with any rom.

Hoping chinaman ships fast.

Am 13.10.19 um 07:11 schrieb ron minnich:
> If you like running systemd on your bmc, the minimum 60 seconds
> openbmc takes to boot, the complex, fragile, and long time it takes to
> build from source, and the openbmc stack's need for giant memory
> footprint and lots of nvme, stop reading.
>
> IF, OTOH, you like the idea of a very lightweight stack, which builds
> in minutes not hours, and needs maybe 32M of memory to run, and boots
> much faster, well, you might want to checkout u-bmc.
>
> https://github.com/u-root/u-bmc
>
> On Sat, Oct 12, 2019 at 2:00 PM Kinky Nekoboi  
> wrote:
>> Debian 10.
>>
>> Thats perfect i  have the nessary flashing tools.
>>
>>
>> Am 12.10.19 um 22:57 schrieb Merlin Büge:
>>> Hi,
>>>
>>>> Due to lib depenency hell i am not able to build openbmc myself atm.
>>>>
>>> Are you building on Debian (9 or 10)?
>>>
>>>> Does somebody has openbmc working for there kgpe-d16 system and can
>>>> maybe send me a rom ?
>>> I'll send you a separate email.
>>>
>>>> Can i flash the module with a Programmer and testclip or only internally?
>>> Yes, a SOIC16 testclip and an SPI programmer like the CH341a will work.
>>>
>>>
>>> Merlin
>>>
>>>
>> ___
>> 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: Coreboot on asus KGPE-D16 - Black screen

[Elisenda Cuadros]

Hi Ale,

It could be due to RAM. As far as I know not all modules are compatible 
with this board. Also memory must be installed in pairs.


Please, check page 2-17 of the manual.

I would tell you to try to make it work first with stock BIOS.

Regards,

Eli

On 14/09/2020 22:55, Ale via coreboot wrote:

Hello,
I have an Asus kgpe-d16 with 2 AMD opteron 6282 SE installed; 
obviously, since I had the first stock bios version the screen was 
black and no boot occurs because CPUs are not supported. So I have 
ordered a coreboot bios DIP and I have installed it but nothing has 
changed, same behaviour (only black screen and no sound, only fans 
starts). Can someone have some idea? I even try to log with the serial 
port but no log is shown at all...


P.S. Could it be that one of the CPUs is broken? Or that something 
went wrong during the flashing procedure over the DIP? Is there a way 
to check that the DIP is ok and with coreboot?

Thank you very much!


___
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: Max RAM problem

[Mike Banon]

Hi there Ale, two suggestions: 1) check this thread -
https://www.reddit.com/r/coreboot/comments/jdcn5y/latest_coreboot_for_the_asus_kcmad8/
, you may have to revert a specific commit for a fresher coreboot
build 2) try to backport my XMP / custom RAM timings patch to KGPE-D16
related sources and then artificially raise the custom timings, hoping
that would make your PC more bootable
https://review.coreboot.org/q/topic:%22AMD_XMP%22+(status:open%20OR%20status:merged)

On Tue, Dec 22, 2020 at 4:48 PM Ale via coreboot  wrote:
>
> Hello everyone,
> I have a kgpe d16 motherboard with coreboot and seabios, and 2 opteron 6282 
> SE processor with 64 gb of RAM: all the modules are 16 Gb hynix HMT42GR7AFR4C 
> - RD and all are inserted into the orange slots. The problem is, if I add 2 
> additional modules, inside the last 2 orange slots, the machine doesn't 
> starts and only black screen is shown, no log is detected over COM port. Any 
> suggestion? Maybe another RAM module configuration is needed, because I read 
> that 192 Gb of RAM is possible to obtain (I have followed the official Asus 
> manual for the RAM-Slots configuration)
>
> Thank you very much
> Best regards
> Ale
> ___
> 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

Re: [coreboot] Sun Ultra 40 M2 Board - Obscured coreboot status

[taii...@gmx.com]

Not to rain on your parade but currently I see this system going for
$400 on ebay or $130 for the board and am curious...what is compelling
for you and this? I did not know when I first started coreboot but you
can buy faster and newer open source firmware boards for less money -
stuff that you can do real work on.


I would definitely get a KCMA-D8 or KGPE-D16[1] if you want something
newer with open source firmware that works straight away but that's me.
If you are a programmer and want to tinker/port coreboot there are other
similar boards of the same class and era that would be a better fit too
such as the TYAN systems.

[1]The D8/D16 are fast enough to compile modern software and can play
modern games in a VM (via IOMMU-GFX) so you can use it for more than
just tinkering - they also support the facebook version of OpenBMC
(AFAIK there are two OpenBMC's versions the facebook and the IBM the
second has more features and comes on the TALOS system but both are
secure owner controlled remote access) via replacing the crappy vendor
firmware on the ASMB4/5 module (D16 comes with module D8 doesn't)
Both have working coreboot with no fiddling just compile and go same
features as the factory BIOS...and the D8 can be had used for less than
your U40.

I would also check out the TALOS 2; POWER is the future of high
performance freedom computing as there will probably never be another
owner controlled x86 system due to ME/PSP etc. It has open source
firmware out of the box (not coreboot) but again you should start with a
D8 or D16 and a decent compatible CPU.

-- 
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] KCMA-D8 /D16 and xen+bsd

[taii...@gmx.com]

I have a coreboot-libre D16 and it works fine with xen - no errors and I
haven't even embedded microcode in coreboot (req for my 43xx/63xx) I
instead do an early update from initramfs.

I suggest obtaining a null modem serial cable and a real serial pci-e
card or expresscard device (nothing involving usb) asap and set both
coreboot and linux to output their logs then you can post them here or
send them to me.

Of course since you have more than one d8/d16 I guess you just need the
cable? and can view the output of one on the other yes?

On 09/18/2018 12:24 PM, Jo wrote:
> 
> Cheers Guys,
> 
> im currently trying to migrate kmca-d8 servers from libreboot+ debian to
> coreboot+xen (ideally arch/centos/alpine as host, with openbsd /windows
> vms).
> 
> however, i do have a weird bug, resulting in an immediate shutdown /
> reboot into the payload after decrypting the main partition.
> 
> There are no error-outputs whatsoever, and i dont have a serial-to usb
> cable (yet), so i cant get any output from serial console.
> 
> Has anyone ever tried this setup/ get it to work?
> 
> Hardware:
> 
> Mobo: kcma-D8 , CPU: dual Opteron 4284, Ram: 16 or 32 gb KVR16E11/8 .
> 
> The problem is persistent/reproducible with different kcma-d8 and
> kgpe-d16, with any os+xen setup we tried so far, also with qubes os.
> 
> Since im using Qubes on various coreboot devices, it has to be something
> specific with those 2 boards.
> 
> Any hints would be greatly appreciated.
> 
> 
> Jo
> 
> 
> 
> 
> 


-- 
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot

[coreboot] Re: KGPE-D16 maintainership

[Timothy Pearson]

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

[Matt B]

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
>

Re: [coreboot] KGPE-D16 PCI passthrough

[Iru Cai]

I seem to know what happened to me. Now I pass throught 00.12.{0,1,2} and
there's no problem now. But if I plug in my keyboard and mouse, then
because of the USB controller is passed to the VM, then I have no keyboard
or mouse to use, so the system seems to hang.

However, I still don't know why there exists some kernel oops in previous
tests.

On Fri, Sep 8, 2017 at 2:33 PM, taii...@gmx.com <taii...@gmx.com> wrote:

> On 09/08/2017 02:12 AM, Iru Cai wrote:
>
> On Fri, Sep 8, 2017 at 2:02 PM, taii...@gmx.com <taii...@gmx.com> wrote:
>>
>> On 09/08/2017 12:44 AM, Iru Cai wrote:
>>>
>>> On Fri, Sep 8, 2017 at 11:42 AM, taii...@gmx.com <taii...@gmx.com>
>>> wrote:
>>>
>>>> On 09/07/2017 11:21 PM, Iru Cai wrote:
>>>>
>>>>> Hi,
>>>>>
>>>>> I have a problem about PCI passthrough on KGPE-D16. I plugged in a PCI
>>>>>> to
>>>>>> USB adapter to the PCI slot, and it's in IOMMU group 7 with the ASpeed
>>>>>> video card and the LSI 1394a controller. I try to pass them all to a
>>>>>> VM,
>>>>>> but then kernel crashes. I tried in Linux 4.9.47 and Linux 4.12.10.
>>>>>>
>>>>>> Does anyone with KGPE-D16 have this problem?
>>>>>>
>>>>>> Iru
>>>>>>
>>>>>> You are attempting to pass the primary video device to a VM which
>>>>>> hardly
>>>>>>
>>>>> ever works, I tried the same thing and it didn't work (I wanted my PCI
>>>>> sound card in the VM, and as PCI doesn't support ACS and all the PCI
>>>>> devices on the D16 are behind the same bridge they are in the same
>>>>> IOMMU
>>>>> group so I had to do that - I ended up buying a USB sound adapter)
>>>>>
>>>>> Now I'm using GTX 650 as my primary video device and not using the on
>>>>>
>>>> board
>>>> ASpeed  video card.
>>>>
>>>> Also I tried to pass the onboard USB controller to the VM, and also
>>>> crashed
>>>> the kernel.
>>>>
>>>> Damn :[
>>> FYI you forgot to reply all - please re post this to the list :]
>>>
>>> Hmm can I have dmesg logs and your libvirt or w/e VM config files? for
>>> the
>>> new config you are trying.
>>> I am playing games right now with my pass thru usb ports.
>>>
>>> So are you using vfio-pci or pci-stub? I don't know if I can use pci-stub
>> in libvirt, but vfio-pci will require all devices
>> in an IOMMU group passed to a VM, and I don't use a modded kernel.
>>
> VFIO-PCI
> I pass thru my video card, an onboard nic and an onboard usb controller
> (all three usb subdevices) - works great and they're all in their own iommu
> group.
>



-- 
Please do not send me Microsoft Office/Apple iWork documents. Send
OpenDocument instead! http://fsf.org/campaigns/opendocument/
-- 
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot

[coreboot] Testing modernizing patches on ASUS KGPE-D16. (was Re: Asus KGPE-D16 with latest coreboot errors with Unsupported Hardware on Qubes 4 install missing IOMMU?)

[Arthur Heymans]

Felix Held  writes:

> Hi!
>
>
>> Things should settle down some after Christmas, so I'll see what I can
>> do to pull the old D16 dev platform back out at that time and start
>> testing / merging patches.  Are there any others that I should also help
>> take a look at?
>
> Arthur pushed a new version of your patch #19820 and since it does what your
> original patch does, I'd say that it should be safe for merging to have that
> problem fixed in the upcoming release. Of course unless someone else tests the
> patch and finds a (very unlikely) regression before tomorrow. There are two 
> more
> patches from that series, but I haven't reviewed them, since they add features
> and don't just fix problems.
>
> I'm not sure if Arthur has some other patches that are relevant to the 
> KGPE-D16;
> IIRC he also looked into some improvements on the AMD side.
>

https://review.coreboot.org/c/coreboot/+/30063 implement relocatable
ramstage on AMDFAM10. Would be interesting to see whether it works on
amdfam15 hardware and if S3 resume still works fine.

https://review.coreboot.org/c/coreboot/+/30064/4 Implements postcar
stage on amdfam10 and drops the backup of RAMBASE..RAMTOP region.
It would allow to drop a whole lot of legacy code used for S3 resume, so
also definitely worth testing.

Both patches worked on a gigabyte m57-sli4 board with a amdfam10 CPU, so
I expect that booting till the OS still works fine. S3 resume might be a
little different. (review for board port is:
https://review.coreboot.org/c/coreboot/+/27618)

Something thing that would seem nice and would make CAR setup more
unified with how we do things on Intel hardware is to use variable
MTRR's for CAR instead of the fixed ones. A difficulty is that the
location needs to be carefully chosen as it needs to be below the
TOP_MEM MTRR, while also not hindering the raminit (I suppose)...

Another thing I'm working on, is to use C_ENVIRONMENT_BOOTBLOCK on all
x86 platforms (dropping use of romcc). Bringing that feature to amdfam10
won't be practical on my gigabyte m57sli board due to it using LPC flash
(I expect tons of reflashes/testing cycles ;). If someone is willing to
donate a supported board (not really interested in doing a board port
due to the deplorable state of AMD code in general) featuring amdfam10
hardware, preferably with DDR3 (implements S3 resume) and a SPI boot
medium, that would be fun.

It does not look this has anything to do with the original thread title
so sorry for hijacking it a little...

> Regards
>
> Felix

Kind regards

-- 
==
Arthur Heymans

-- 
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot

[coreboot] Re: Need help with getting KGPE-D16 working.

[Michal Zygowski]

Hi,

3mdeb office has two of these KGPE-D16 boards. We also experience some
issues with booting. Built an image from 4.11 branch using stable
SeaBIOS and enabled console over serial port. Using 1x Kingston
KVR16R11D4/16 16GB ECC RAM and booting without issues.

2. Secondary payloads may require some tuning of libpayload config, for
example to increase stack size and heap size (noticed issues with USB
when the stack or heap was too small).

3. The graphics is exposed by BMC ASPEED AST2050, it should allow to use
display. The problems may occur when GRUb is switching display mode or
something. The kernel booting problems may be related to memory training
problem.

4. If you have a discrete GPU, you may include its VGA option ROM into
CBFS using correct naming, SeaBIOS should execute it and provide
graphics output. There is also an option in Kconfig "Onboard VGA is
prmiary", try to deselect it when using discrete GPU.

5. If you do not have BMC running, the fans will keep running at full
speed IIRC. BMC was responsible for fan control. In order to utilize BMC
one needs the BMC flash chip module. The fans are spinning up to max
speed during hardware enumeration in ramstage, probably during Super IO
intialization and BMC initialization. I am not yet familiar with this
board. However maybe if you look into Winbond chip drivers used on KGPE
you may find some settings to tweak the speed, I am not sure.

The only RAM HCL I found are:

https://www.coreboot.org/Board:asus/kgpe-d16#RAM_HCL

https://libreboot.org/docs/hardware/kgpe-d16.html#memory-compatibility-with-libreboot

https://www.raptorengineering.com/coreboot/kgpe-d16-status.php

I would gladly help to resolve those issues, but we lack resources to do
it "pro publico bono". 3mdeb is trying to change it together with
Insurgo Technologies Libres, we are gathering funds for the development
and revivial of this platform:
https://github.com/osresearch/heads/issues/719

Regards,

-- 
Michał Żygowski
Firmware Engineer
https://3mdeb.com | @3mdeb_com

On 5/9/20 5:33 AM, ragna...@tenebr.is wrote:
> Recently I'm finally able to get a KGPE-D16 coreboot environment that could 
> always boot, although there are a lot of issues and questions. I'm currently 
> using the 4.11 branch as this board has been dropped in the master branch.
>
> The main issue is memory. It seems there are still issues with memory 
> initialization. The Samsung 16GB sticks I currently have (normal or VLP) do 
> not work when using all orange slots, ending in a bootloop due to DIMM 
> training failure (which is the same error I had when I was trying coreboot on 
> KCMA-D8). However, on KGPE-D16, by installing the 8 sticks to the following 
> slots: D1/D2, B1/B2, E1/E2 and G1/G2, I could always get it past the memory 
> initialization, albeit with this error:
>
> "TrainDQSRdWrPos: negative DQS recovery delay detected! Attempting to 
> continue but your system may be unstable..."
>
> This is currently the only combination that could always boot (and with all 
> 128GB recognized). Other combinations I tested either resulted in some 
> "HARDWARE FAULT: HT_EVENT_HW_SYNCHFLOOD" errors which would soft reset before 
> even reaching the DIMM training part, or it entered the DIMM training part 
> but would never complete.
>
> However, the system is currently not at a point that could properly boot to a 
> system (or even a payload) yet. As of yesterday, the only thing I could boot 
> and steadily function is a Menuet64 floppy image.
>
> 1. I'm using SeaBIOS master, and have put several floppy images into the 
> CBFS, but it seems to only list the last floppy image I added as a boot 
> option (Ramdisk). It appears multiple floppy images is not officially 
> supported in master yet and I've just located the patch regarding this. I'm 
> still new to SeaBIOS so I'm not sure how to modify configuration/bootorder 
> later on, as I currently don't have a configuration/bootorder file supplied 
> and let it use default values.
>
> 2. None of the secondary payloads work. nvramcui hangs with something like 
> "unable to init curs" (I only tried it once and couldn't remember what 
> exactly it is). coreinfo and tint hangs with this "Not enough memory creating 
> EHCI periodic frame list." error. memtest could load, but when it starts 
> testing, it hangs with a glitched screen of blinking characters, among which 
> something like "d h l p t x" could be seen. This also happened when using 
> memtest that comes with the Manjaro Linux boot USB.
>
> 3. Initially I had issues with graphical bootloaders like grub, but after 
> disabling bootsplash image as well as not building the seavgabios.bin (by 
> unchecking the "Include generated option rom that implements legacy VGA BIOS 
> compatibility"), I could get Manja

Re: [coreboot] ASUS KGPE-D16 Automated Test Failure [master]

[Aaron Durbin via coreboot]

Kyosti, this looks in the area of your recent patches.


amdmct_cbmem_store_info: Storing AMDMCT configuration in CBMEM
CBFS: 'Master Header Locator' located CBFS at [100100:1fffc0)
CBFS: Locating 'cmos_layout.bin'
CBFS: Checking offset 0
CBFS: File @ offset 0 size 20
CBFS:  Unmatched 'cbfs master header' at 0
CBFS: Checking offset 80
CBFS: File @ offset 80 size 297fc
CBFS:  Unmatched 'normal/romstage' at 80
CBFS: Checking offset 29900
CBFS: File @ offset 29900 size 280
CBFS:  Unmatched 'config' at 29900
CBFS: Checking offset 29bc0
CBFS: File @ offset 29bc0 size 24e
CBFS:  Unmatched 'revision' at 29bc0
CBFS: Checking offset 29e80
CBFS: File @ offset 29e80 size 100
CBFS:  Unmatched 'cmos.default' at 29e80
CBFS: Checking offset 29fc0
CBFS: File @ offset 29fc0 size e84
CBFS: Found @ offset 29fc0 size e84
disable_spd()
prepare_romstage_ramstack: Prepare CAR migration and stack
regions...memset_:  Fill [003f5400-003f]
...prepare_romstage_ramstack:  Done
post_cache_as_ram: Copying data from cache to RAM...memcpy_:  Copy
[000c2c00-000cd2bf] to [003f5940 - 003f] ...post_cache_as_ram:
Done
post_cache_as_ram: Verifying data integrity in RAM...memcmp_:  Compare
[000c2c00-000cd2bf] with [003f5940 - 003f] ...post_cache_as_ram:
Done
post_cache_as_ram: Switching to use RAM as
stack...cache_as_ram_new_stack: Disabling cache as ram now
prepare_ramstage_region: Prepare ramstage memory region...memset_:
Fill [-003f53ff] ...

On Tue, Jul 19, 2016 at 12:48 PM, Raptor Engineering Automated
Coreboot Test Stand <no-re...@raptorengineering.com> wrote:
> The ASUS KGPE-D16 fails verification for branch master as of commit 
> dc97b1ce2f4e671e73e2a3fb65e49a881a694590
>
> The following tests failed:
> BOOT_FAILURE
>
> Commits since last successful test:
> dc97b1c soc/intel/apollolake: Fix bitshift issue in bootblock
> b921725 nb/intel/x4x: Fix CAS latency detection
> 47995fb arch/riscv: Remove enter_supervisor
> b8e67ac arch/riscv: Change all eret instructions to .word 0x30200073 (mret)
> 5d687ad google/oak & elm: initialize touchscreen reset gpio
>
> <124 commits skipped>
>
> 70cd543 AMD k8 fam10: Drop excessive spinlock initialization
> b5664de Romstage spinlocks require EARLY_CBMEM_INIT
> d113190 AMD k8 fam10: Fix romstage handoff
> 880b458 google/chromeec: Update EC command header
> 1f83ffa gru: include ram_code in coreboot table
>
> See attached log for details
>
> This message was automatically generated from Raptor Engineering's ASUS 
> KGPE-D16 test stand
> Want to test on your own equipment?  Check out 
> https://www.raptorengineeringinc.com/content/REACTS/intro.html
>
> Raptor Engineering also offers coreboot consulting services!  Please visit 
> https://www.raptorengineeringinc.com for more information
>
> Please contact Timothy Pearson at Raptor Engineering 
> <tpear...@raptorengineeringinc.com> regarding any issues stemming from this 
> notification
>
> --
> coreboot mailing list: coreboot@coreboot.org
> https://www.coreboot.org/mailman/listinfo/coreboot

-- 
coreboot mailing list: coreboot@coreboot.org
https://www.coreboot.org/mailman/listinfo/coreboot

[coreboot] How to improve the boot time of the Asus KGPE-D16?

[Paul Menzel via coreboot]

Dear coreboot folks,


With 128 GB of RAM consisting of eight 16 GB modules, coreboot takes
over a minute to get to the payload on the Asus KGPE-D16 even without
serial console enabled [1]. This is not much faster than the vendor
firmware.

Please note that the timings below are incorrect. Comparing it with the
timings from SeaBIOS’ `script/read_serial.py`, I’d say the time values
need to be multiplied by two. (Somebody mentioned, that the reason
might be `cbmem -t` using some scaling factor to convert the time
stamps to seconds, and that might be wrong on the board.)

```
$ more 
asus/kgpe-d16/4.5-1093-g308aeff/2017-03-01T16_03_07Z/coreboot_timestamps.txt
21 entries total:

   0:1st timestamp 24,384
   1:start of rom stage25,061 (676)
   2:before ram initialization 913,502 (888,441)
   3:after ram initialization  35,548,889 (34,635,386)
   4:end of romstage   35,642,960 (94,070)
   8:starting to load ramstage 35,647,351 (4,391)
  15:starting LZMA decompress (ignore for x86) 35,647,872 (520)
  16:finished LZMA decompress (ignore for x86) 35,695,864 (47,991)
   9:finished loading ramstage 35,696,312 (447)
  10:start of ramstage 35,696,893 (581)
  30:device enumeration35,696,897 (3)
  40:device configuration  36,639,627 (942,730)
  50:device enable 36,644,848 (5,221)
  60:device initialization 36,646,012 (1,163)
  70:device setup done 37,044,848 (398,836)
  75:cbmem post37,044,850 (1)
  80:write tables  37,044,851 (1)
  85:finalize chips37,053,950 (9,099)
  90:load payload  37,324,647 (270,697)
  15:starting LZMA decompress (ignore for x86) 37,325,042 (395)
  16:finished LZMA decompress (ignore for x86) 37,349,321 (24,278)
  99:selfboot jump 37,349,328 (7)
```

I think most of the time is spent in RAM initialization.

   1. Do board owners with similar amount of memory (independent of the
  board) have similar numbers?
   2. What are the ways to improve that? Is it possible? For example, can
  the modules be probed in parallel (if that isn’t done already)?


Thanks,

Paul


[1] 
https://review.coreboot.org/cgit/board-status.git/commit/?id=4b4b7ab5865b15ae7caa43f0a99a80772818090f21 entries total:

   0:1st timestamp 24,384
   1:start of rom stage25,061 (676)
   2:before ram initialization 913,502 (888,441)
   3:after ram initialization  35,548,889 (34,635,386)
   4:end of romstage   35,642,960 (94,070)
   8:starting to load ramstage 35,647,351 (4,391)
  15:starting LZMA decompress (ignore for x86) 35,647,872 (520)
  16:finished LZMA decompress (ignore for x86) 35,695,864 (47,991)
   9:finished loading ramstage 35,696,312 (447)
  10:start of ramstage 35,696,893 (581)
  30:device enumeration35,696,897 (3)
  40:device configuration  36,639,627 (942,730)
  50:device enable 36,644,848 (5,221)
  60:device initialization 36,646,012 (1,163)
  70:device setup done 37,044,848 (398,836)
  75:cbmem post37,044,850 (1)
  80:write tables  37,044,851 (1)
  85: 37,053,950 (9,099)
  90:load payload  37,324,647 (270,697)
  15:starting LZMA decompress (ignore for x86) 37,325,042 (395)
  16:finished LZMA decompress (ignore for x86) 37,349,321 (24,278)
  99:selfboot jump 37,349,328 (7)

Total Time: 37,324,934


signature.asc
Description: This is a digitally signed message part
-- 
coreboot mailing list: coreboot@coreboot.org
https://www.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] How to improve the boot time of the Asus KGPE-D16?

[Timothy Pearson]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 03/02/2017 01:18 PM, Paul Menzel via coreboot wrote:
> Dear coreboot folks,
> 
> 
> With 128 GB of RAM consisting of eight 16 GB modules, coreboot takes
> over a minute to get to the payload on the Asus KGPE-D16 even without
> serial console enabled [1]. This is not much faster than the vendor
> firmware.
> 
> Please note that the timings below are incorrect. Comparing it with the
> timings from SeaBIOS’ `script/read_serial.py`, I’d say the time values
> need to be multiplied by two. (Somebody mentioned, that the reason
> might be `cbmem -t` using some scaling factor to convert the time
> stamps to seconds, and that might be wrong on the board.)
> 
> ```
> $ more 
> asus/kgpe-d16/4.5-1093-g308aeff/2017-03-01T16_03_07Z/coreboot_timestamps.txt
> 21 entries total:
> 
>0:1st timestamp 24,384
>1:start of rom stage25,061 (676)
>2:before ram initialization 913,502 (888,441)
>3:after ram initialization  35,548,889 (34,635,386)
>4:end of romstage   35,642,960 (94,070)
>8:starting to load ramstage 35,647,351 (4,391)
>   15:starting LZMA decompress (ignore for x86) 35,647,872 (520)
>   16:finished LZMA decompress (ignore for x86) 35,695,864 (47,991)
>9:finished loading ramstage 35,696,312 (447)
>   10:start of ramstage 35,696,893 (581)
>   30:device enumeration35,696,897 (3)
>   40:device configuration  36,639,627 (942,730)
>   50:device enable 36,644,848 (5,221)
>   60:device initialization 36,646,012 (1,163)
>   70:device setup done 37,044,848 (398,836)
>   75:cbmem post37,044,850 (1)
>   80:write tables  37,044,851 (1)
>   85:finalize chips37,053,950 (9,099)
>   90:load payload  37,324,647 (270,697)
>   15:starting LZMA decompress (ignore for x86) 37,325,042 (395)
>   16:finished LZMA decompress (ignore for x86) 37,349,321 (24,278)
>   99:selfboot jump 37,349,328 (7)
> ```
> 
> I think most of the time is spent in RAM initialization.
> 
>1. Do board owners with similar amount of memory (independent of the
>   board) have similar numbers?
>2. What are the ways to improve that? Is it possible? For example, can
>   the modules be probed in parallel (if that isn’t done already)?
> 
> 
> Thanks,
> 
> Paul
> 
> 
> [1] 
> https://review.coreboot.org/cgit/board-status.git/commit/?id=4b4b7ab5865b15ae7caa43f0a99a80772818090f
> 

The issue isn't probing; the delays are introduced in both DRAM training
(DDR3 training is quite complex and involves repeatedly streaming
pseudorandom data to/from the modules at full speed) and in the
mandatory clearing of the ECC check bits.

The only way to feasibly decrease boot time would be to run the DRAM
training on each CPU package (and possibly memory controller, though I
don't think that's a good idea) in parallel.  This, in turn, couples
with previous discussions on whether coreboot, and in particular
coreboot's romstage, should even be attempting to provide a
multi-tasking environment; i.e. does the added complexity provide a
significant enough benefit to justify the maintenance overhead?

- -- 
Timothy Pearson
Raptor Engineering
+1 (415) 727-8645 (direct line)
+1 (512) 690-0200 (switchboard)
https://www.raptorengineering.com
-BEGIN PGP SIGNATURE-
Version: GnuPG v1
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQEcBAEBAgAGBQJYuHIzAAoJEK+E3vEXDOFbr4YH/2c74mr+eTlSM63yfBF9DbSX
aTy795FQ+aKeJdAe+UUlIM25L+HxNbbsctH3fRNA1OgmFrrXtIenpQZlVItBE09l
YZUp/+WDgDOkuIxJ8+2NKnU8i3cOHN2uIFKs1fyEenrTMXZBvOcXbV+tnJ54VJJ5
ISCKAlJcvZGs4HGdVhkx1RoN3S77kTrLkRhi6+2Zj1HN8KcawGfl99qOfXQ3TY1A
9+n3K8PjtRcQXN23OI2DdO+Vc9JFuVA7uyIXJdmWDV35dcc1p9wK1QZRyn5vMU9p
l9fvpNxn1Emf7p30L01Anx0m/ihlP0Qfx8QC11L4YpQMaDloAjOy3IAdt3v87LU=
=Dzfn
-END PGP SIGNATURE-

-- 
coreboot mailing list: coreboot@coreboot.org
https://www.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] [RFH] Native AMD fam10-15 support

[qtux]

On 15/06/18 02:42, Kyösti Mälkki wrote:
> On Thu, Jun 14, 2018 at 4:38 AM, qtux  wrote:
>> On 13/06/18 22:12, Kyösti Mälkki wrote:
>> Hi,
>>
>> S3 is __not__ working on my KCMA-D8. The last time I tried, I had to
>> remove the power cord for a couple of seconds to be able to boot again.
>>
>> Interestingly, this issue looks similar to another one I had with a
>> flash chip which seems not to be supported by coreboot. Here the
>> relevant part of the logs regarding the bad chip:
>> Manufacturer: ef
>> SF: Unsupported Winbond ID 4014
>> SF: Unsupported manufacturer!
>>
> 
> Thanks, [1] should take care of this.
> 

Thank you! I will test the Winbond chip when I find some time to do so.

>> Coreboot did work well, but froze sometimes when booting during the
>> assigning resources step (more or less exactly after assigning the PCI
>> 14.3 or PNP 002e.2 device, which happen to be close to each other inside
>> the devicetree). I had to remove the power cord in order to be able to
>> boot again (or to get the next random freeze...). Rarely, after such an
>> recovery, I have got flooded by IOMMU warnings in Linux which would only
>> disappear after another reboot.
> 
> Ah, that resume reboot-loop issue. The bit that tells to do S3 resume
> is a sticky register backed up by Vstb rail. With [2] you should not
> need to do full power-cycling at least. We should extend this work to
> other platforms.
> 

I am not sure whether the term resume reboot-loop applies for my issue
(side note: I used a serial connection to monitor the boot process):

Rebooting (via holding the power button for some seconds) after
encountering a freeze (aka stopping at the assign resource step)
resulted into having no output from serial at all. I could repeat this
with no effect at all, the computer seemed to be dead. Only removing the
power cord could solve the issue.

This issue could occur when rebooting but even when cold booting.

>> Replacing the chip seems to have solved this random boot freeze problem.
>> But maybe the S3 issue and the issue I had with the wrong chip are
>> related as they both lock down the machine until I remove the power cord.
> 
> Yes, it's connected. Having a non-supported SPI part ID there would
> prevent ACPI S3 resume, and likely enter the loop.>

Just to be sure: The S3 resume does not work with the __supported__ SPI
chip. I did not test S3 with the unsupported one.

> If someone takes the task of testing and/or bisecting please note:
> 
> Regression present between: 714709f .. a26377b
> 
> Regression present between: 9e94dbf .. c2a921b (for kcma-d8) 8a8386e
> (for kgpe-d16)
> 
> Now, since commit babb2e6 that claims to add S3 support on kgpe-d16 is
> within the latter period, I do not quite see how S3 support could have
> worked with that commit on kgpe-d16.  Or maybe this feature was never
> retested once it was rebased and upstreamed. Nor can I see how it
> could have worked for any commit in 4.6, so I must be missing
> something here. So I will need some logs.
> 
> 
> [1] https://review.coreboot.org/#/c/coreboot/+/27107
> [2] https://review.coreboot.org/#/c/coreboot/+/27108
> 
> Kyösti
> 

Answers are inside the text.
I forgot to mention that I am currently on commit 793ae846e8.

Cheers,
Matthias

-- 
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] New user of KGPE-D16

[Timothy Pearson]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

To try the OpenBMC port you don't need to solder anything; you just need
to find an ASMB4-iKVM module and program it.  Soldering is for if you
want access to the JTAG connector for low-level development (U-Boot
development, mostly).

https://www.asus.com/Commercial-Servers-Workstations/ASMB4iKVM/

The ASMB5-iKVM also works from a hardware perspective, but both may be
hard to find as the KGPE-D16 and the Opterons it uses are now out of
production.

On 02/14/2018 04:50 PM, Elisenda Cuadros wrote:
> Yes, I cleaned the CPU before but it's obvious it wasn't shiny :-) .
> 
> I want to try your OpenBMC port. I readed I have to solder the 20 pin
> connector.
> 
> Pin 1 is the squared shape, isn't it? But which is Pin 1 in the female
> connector?
> 
> Best regards,
> 
> - Eli
> 
> 
> On 14/02/18 23:42, Timothy Pearson wrote:
> Good to hear.  I was going to mention bad CPU but that seemed unlikely;
> on this end we always make sure the CPU contacts are shiny before
> attempting boot so that could explain the discrepancy.
> 
> On 02/14/2018 04:38 PM, Elisenda Cuadros wrote:
>>>> Thank you for your reply Timothy.
>>>>
>>>> I removed the heatsink and cleaned the cpu contacts.
>>>>
>>>> Now it boots.
>>>>
>>>> Thank you for your support.
>>>>
>>>> Best regards,
>>>>
>>>> - Eli
>>>>
>>>>
>>>> On 14/02/18 22:46, Timothy Pearson wrote:
>>>> Dead / incompatible DIMM, DIMM(s) in wrong slots, or damaged mainboard.
>>>>The fact that the vendor BIOS won't post is a very bad sign, since in
>>>> our experience the vendor BIOS is far more forgiving of faulty DIMMs
>>>> than coreboot (basically, the vendor BIOS will show something on the VGA
>>>> port even if the DIMMs are completely damaged and unable to properly
>>>> store data).
>>>>
>>>> On 02/14/2018 03:28 PM, Elisenda Cuadros wrote:
>>>>>>> Hello,
>>>>>>>
>>>>>>> I recently bought an Asus KGPE-D16 board, with an Opteron 6238 and 4
>>>>>>> Micron MT18JSF25672PDZ-1G4F1DD modules.
>>>>>>>
>>>>>>> Firstly I tried to boot with vendor BIOS but I don't get any output
>>>>>>> on VGA.
>>>>>>>
>>>>>>> I have a PCI Post Card and it seems it arrives to 3E and then I
>>>>>>> think it
>>>>>>> enters in a loop.
>>>>>>>
>>>>>>> I flashed Coreboot with default settings just to try to get some more
>>>>>>> useful logs. The result I think is more or less the same, it doesn't
>>>>>>> arrive to payload.
>>>>>>>
>>>>>>> Memory is installed in A2,B2,C2 and D2 slots.
>>>>>>>
>>>>>>> I spent multiple hours trying to figure where is the problem.
>>>>>>>
>>>>>>> Do you have any ideas?
>>>>>>>
>>>>>>> I attach the console log.
>>>>>>>
>>>>>>> Thanks in advance.
>>>>>>>
>>>>>>> Best Regards,
>>>>>>>
>>>>>>> - Eli
>>>>>>>
>>>> -- Timothy Pearson
>>>> Raptor Engineering
>>>> +1 (415) 727-8645 (direct line)
>>>> +1 (512) 690-0200 (switchboard)
>>>> https://www.raptorengineering.com
> -- Timothy Pearson
> Raptor Engineering
> +1 (415) 727-8645 (direct line)
> +1 (512) 690-0200 (switchboard)
> https://www.raptorengineering.com

- -- 
Timothy Pearson
Raptor Engineering
+1 (415) 727-8645 (direct line)
+1 (512) 690-0200 (switchboard)
https://www.raptorengineering.com
-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQEcBAEBAgAGBQJahL47AAoJEK+E3vEXDOFbtcoIAJkkd0yqvExnFwqrx2j91sUF
jPkMCTd1lKPMPOYp8lFfDeG9hcBP8RBpuf/G32bhGvjArVEwIgqPWghiygLK6W6M
yn+I+utV6N2XxAzO/y0lnJYtswOF7Ppq9TutBENGdfwh5vlm5sCpLbcp30Fvbd9L
vdUkBhhzfb3BBN/87RvqGzxWiqgYkoOYtfXy7ZndpIFNzeSqsY0+z79uQhrW9EEf
d44OIR/dxJ3nC5pQAlZtbC6jxI1TsP79cUP5d6BZgJfaMCVliNtc/Tat/gTM4kyH
SniuCwEVoPOCxGCUufw6UOZtElm8BlCCE07XclzkkmH9Rk8WugXhhwrnR3yNU+k=
=LqqY
-END PGP SIGNATURE-

-- 
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] OpenBMC & KGPE-D16

[Mike Banon]

> Any particular reason those patches were not upstreamed?

Because a person who submitted these patches did not fix some problems,
if you scroll down to comments at
https://review.coreboot.org/#/c/coreboot/+/19820/

Paul Menzel
May 23, 2017

Patch Set 1:

(2 comments)

src/mainboard/asus/kgpe-d16/romstage.c
Line 96:

Add macro or set `dev = PCI_DEV(0, 0x14, 4)`?

Line 118:

Line length?

Arthur Heymans
May 23, 2017

Patch Set 1:

(5 comments)

Change looks good, just pci_def.h macros that could be used a bit more.

src/mainboard/asus/kgpe-d16/romstage.c
Line 93:

Use macros?

Line 101:

#define TEMP_PCI_BUS 0x1

Line 101:

PCI_SECUNDARY_BUS

Line 102:

PCI_SUBORDINATE_BUS

Line 103:

PCI_BASE_ADDRESS_4


On Sun, Feb 25, 2018 at 6:01 AM, Thierry Laurion
<thierry.laur...@gmail.com> wrote:
> Any particular reason those patches were not upstreamed?
>
>
> Le ven. 23 févr. 2018 21:40, Thierry Laurion <thierry.laur...@gmail.com> a
> écrit :
>>
>> Timothys patches were mot included un coreboot
>> https://review.coreboot.org/#/c/coreboot/+/19822/
>>
>> Le ven. 23 févr. 2018 17:40, Elisenda Cuadros <li...@e4l.es> a écrit :
>>>
>>> Hello,
>>>
>>> Thank you for your reply.
>>>
>>> I reflashed (same build) the BMC module with a hotplug. Now it works
>>> like a charm, it got an ip, I can log through ssh, reboot, etc..
>>>
>>> But now I have a new problem. If I try to boot from a halted system,
>>> with BMC module attached, the system fires up but Coreboot hangs:
>>>
>>> Unable to detect valid memory on any nodes.  Halting!
>>> mct_d: fatalexit
>>>
>>> If I remove the BMC module the system boots fine.
>>>
>>> I have 4 Micron MT18JSF25672PDZ-1G4F1DD modules, located in CPU1 orange
>>> slots.
>>>
>>> I attach both console logs.
>>>
>>> Regards,
>>>
>>> - Eli
>>>
>>>
>>>
>>> On 22/02/18 22:36, Timothy Pearson wrote:
>>> > Actually, for OpenBMC work, hotplugging is often the only way to go.
>>> > Just be very careful to align the pins correctly the first time; you
>>> > don't have a second chance if you misalign the pins and fry the
>>> > module...
>>> >
>>> > On 02/22/2018 03:22 PM, taii...@gmx.com wrote:
>>> >> On 02/17/2018 09:46 AM, Elisenda Cuadros wrote:
>>> >>
>>> >>> Hi,
>>> >>>
>>> >>> Now I trying to use your OpenBMC port.
>>> >>>
>>> >>> I followed the instructions and everything was fine (compiling,
>>> >>> reading and flashing). I waited several minutes after flashing, but
>>> >>> the module didn 't blinked like in the vendor rom, nor did it receive
>>> >>> an ip.
>>> >>>
>>> >>> I halted the system because I thought maybe it needs a cold start.
>>> >>>
>>> >>> After this, the system doesn't boot with the module plugged in. The
>>> >>> fans begin to spin for approximately 1/4 second, but nothing else.
>>> >>>
>>> >>> My two fans (1 cpu & 1 chassis) have 3 pins and are low speed
>>> >>> (~1000rpm)
>>> >>>
>>> >>> In the case I have to reflash the module, is it possible to hotplug
>>> >>> it?
>>> >> Hotplugging is dangerous and not supported, don't do it.
>>> >>> Thank you very much for your support.
>>> >> You can use a test clip to externally flash it via a flashing device
>>> >> (not sure which can do 16 pins though, I would inquire on the flashrom
>>> >> mailinglist)
>>> >>
>>> >> Are you using the latest coreboot? AFAIK coreboot was patched to
>>> >> support
>>> >> OpenBMC, so you need a new version with the patches.
>>> --
>>> coreboot mailing list: coreboot@coreboot.org
>>> https://mail.coreboot.org/mailman/listinfo/coreboot
>
>
> --
> coreboot mailing list: coreboot@coreboot.org
> https://mail.coreboot.org/mailman/listinfo/coreboot

-- 
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] (libre) Add-on cards for getting higher SSD throughput on the KGPE-D16?

[Timothy Pearson]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 03/01/2018 01:36 PM, Daniel Kulesz via coreboot wrote:
> Hi,
> 
> after plugging a rather newish 2,5 SATA SSD to my KGPE-D16, I realized that 
> the regular SATA ports connected to the SP5100 on this board can only handle 
> SATA2, limiting transfer speeds to max. 300 MB/s. I thought about various 
> options what I could do now:
> 
> (1) try to get the PIKE 9230 card => but does come with a co-processor and 
> non-free firmware like the SAS Pike cards? Seems almost impossible to get one 
> though

Non free firmware is basically standard on SAS.  I am not aware of any
SAS controller that can work without firmware; the SAS protocol is
complex and there has been no effort toward writing replacement firmware
within the open source community.

A typical SAS controller provides an entire operating system on the card
itself, with LSI devices using an ARM processor as the host and
Microsemi devices apparently using a MIPS processor.  You can even find
the UART out pins on some cards if curious; I haven't actually hooked
anything up to see what is running on the card.

> (2) get the PIKE 2008 card => will SATA3 work without non-free firmware?

No.

> (3) put in some PCIe SATA3 card => any recommended chips that respect freedom?

There are very few.  You can try some of the Marvell devices but you
will still be limited by the host side bus as these old Opterons only
support PCIe v2.

> (4) get a m.2 SSD instead together with some PCIe adapter => the cards don't 
> have a co-processor, right?

Yes, they do.  NVMe devices have an integrated proprietary controller to
manage data storage / wear levelling.

> (5) stay with SATA2 and live with the limited speed
>
> Any recommendations for a freedom-respecting choice?

To be blunt, even your hard disks have an integrated (and hackable!)
proprietary controller.  I'd suggest going with m.2 and:

1.) Making sure your IOMMU is running
2.) Using full disk encryption
3.) Run a checksumming filesystem on top of the encryption, such as BTRFS

If all of those criteria are met, it's going to be next to impossible
for malicious controller firmware to do any silent damage to the system;
about the worst a malicious controller blob could do is corrupt data in
a way that would show up on the next scrub (DoS attack).

Also, mandatory plug for Talos II here: these bottlenecks disappear on
newer hardware and you don't have to accept the ME/PSP to get access to
modern speeds.  The KGPE-D16 is the last and most powerful
owner-controllable x86 machine, but it is definitely showing its age in
some areas.

> Cheers, Daniel
> 


- -- 
Timothy Pearson
Raptor Engineering
+1 (415) 727-8645 (direct line)
+1 (512) 690-0200 (switchboard)
https://www.raptorengineering.com
-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQEcBAEBAgAGBQJamGCKAAoJEK+E3vEXDOFbRUkIAJ1R7aabF8QwwWL7e12RZsPq
lhInBSbLgi7xRJglAFytR0K0nXjpfqE6kvsJoUCJl4gfc/gldJAk2V5O3hGJ8rBX
82yJjqcCN6dShT95DNbSe90Eq7sn3iinc487s9kDP3utYABNtEZVzEtAOrpNWjFy
EHQ4qOX7W7Te+Uo9Nckni693YH6xkotigAbahp2kef9KwS7O9m+HZcg6Rem5FI+L
aIxvRtiWfBNW7lKDNq6tm+E3oeWER1/2Xxjkgld9A4aDjSUYNTnDDUcphuYo158N
piEFtQ1868/LXOGrlnATpeH9hu0f2xtACVZGMbVoWY8eqRC6ylw2ybZ/J4iuSx0=
=nHiE
-END PGP SIGNATURE-

-- 
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] 8GB graphics cards work on coreboot - in case anyone is wondering

[Matt B]

Hi,

One thing I just noticed about the page:
https://www.coreboot.org/Board:asus/kgpe-d16

Here "Crossfire XDMA" is listed as needing testing. If nobody has been able
to test this, and you (or someone else) has the opportunity this might be
an interesting thing to test.

After learning that this board can take a more modern CPU (family 15h) I'm
now considering it more strongly for a future computer. My K10 box is
*currently* mitigated against Spectre V2 (IBP disabled under CentOS via a
chicken bit) but I don't think it's wise to expect further mitigations to
be forthcoming from AMD should more bugs rear their ugly head. Moving up to
a family 15h CPU means getting updated Spectre V2-mitigating microcode and
a much more realistic expectation of support in the immediate future. I'll
probably even move up to piledriver (like the G505s I'm currently working
on), since a microcode patch will also fix the NMI issue (and I'll be
applying one to the stock microcode anyway).

I'd be really interested to learn if Crossfire and other features of modern
cards work on these older boards under coreboot, since they may come in
REALLY handy when running any machine learning loads on these boards.

On another note, does anyone have a favorite PSU for these boards?
Preferably something that will last a bit longer than crappy consumer gear?
This thing already requires two 8-pin connectors for a dual CPU setup, and
graphics cards demand them now too.

Sincerely,
-Matt



On Sat, Sep 1, 2018 at 4:15 PM Mike Banon  wrote:

> Taiidan, thank you very much for your valuable feedback! When I've
> been thinking of getting KGPE-D16 my main concern was that some high
> end GPUs wouldn't work for some reason and it was difficult to find
> any info... Luckily your RX580 doesn't have a Security Processor
> inside it ! Did you know AMD started putting this "security processor"
> crap into their GPUs also, starting with Vega? Hopefully RX line would
> be safe for a while, maybe I'd get RX680 when it comes out if it will
> not be tainted by this "security" :P Wish you to get a second nice
> Opteron one day
> On Sat, Sep 1, 2018 at 10:41 PM taii...@gmx.com  wrote:
> >
> > I was worried that it wouldn't work for some reason like due to lack of
> > 64bit MMIO in coreboot but I just installed an AMD Raden RX580 8GB on my
> > KGPE-D16 and it works great.
> >
> > I am playing the latest games on max settings in a VM with a GPU
> > bottleneck at 1080p with my single 6328 CPU...it is nice to finally have
> > good smooth gameplay with high fps.
> >
> > --
> > coreboot mailing list: coreboot@coreboot.org
> > https://mail.coreboot.org/mailman/listinfo/coreboot
>
> --
> coreboot mailing list: coreboot@coreboot.org
> https://mail.coreboot.org/mailman/listinfo/coreboot
>
-- 
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot

[coreboot] Re: Status of Board Asus KGPE-d16

[Mike Banon]

> Has [2] updated the default microcode for the G505s to the latest available 
> version? (no longer requiring patches with a separate script?)

Yes, this microcode question is solved for G505S now. But I have some
other not-merged patches which are also useful (e.g. dGPU patch), so
still need to run some scripts before building a coreboot.

Here is the first public version of a ./csb_patcher.sh script I am
working on currently - https://pastebin.com/HbTvZUiv . It helps to
patch your coreboot more conveniently (with SHA256 verifications as
always) and could even download the floppies collection! There are
almost 600 lines of code and some parts of it aren't optimized, but it
already works great - so, despite there's a long TODO list, I'm not
ashamed to release it. And I set the expiration time for this paste
because there should be a better version eventually...

Hopefully you could test it or take a look on its' code and share some
feedback, e.g. regarding its' POSIX compatibility (I'm trying to make
this script as portable as possible)

Best regards,
Mike Banon



On Sun, May 26, 2019 at 12:00 PM Kinky Nekoboi
 wrote:
>
> Hello Mike,
>
> thank you for the verbose anwser, as always.
>
> The board is not in my possession yet.
>
> I ordered it as upgrade for my Fileserver.
>
> I will investigate it, after i have it up running.
>
> Kinky greetings.
>
>
> Am 25.05.19 um 10:15 schrieb Mike Banon:
> > ASUS KGPE-D16 is using a "microcode update infrastructure" ( which
> > IMHO has some shortcomings, hopefully this will be discussed here -
> > [1] ) which extracts a microcode from a container - and I haven't
> > checked yet if my recently merged "15h microcodes" patch 28273 ([2])
> > brings any benefit for your board , since this "microcode update
> > infrastructure" might replace this new microcode hardcoded into C file
> > by an older version extracted later from a binary container. If this
> > really happens, we could either wait for a new container released by
> > AMD at linux-firmware.git , or if it takes too long - I could try to
> > make such a container by myself, looking at how a current container is
> > done, and submit for a review.
> >
> > Please, could you run " cat /proc/cpuinfo | grep microcode " command
> > and tell its' output? Hope it gives "microcode: 0x600111f".
> >
> > [1] - 
> > https://review.coreboot.org/c/coreboot/+/29272/2#message-771016d7aa4633189e22b3354dbba0494d8c8d0e
> >
> > [2] - 
> > https://review.coreboot.org/c/coreboot/+/28273/6#message-cbbdcce72362a39ad3edb056f25cd54037dce59a
> >
> > Best regards,
> > Mike Banon
> >
> >
> > On Fri, May 24, 2019 at 11:04 PM Kinky Nekoboi
> >  wrote:
> >> Hello fellow corebooters,
> >>
> >> i have succesfully build an rom for the asus kgpe-d16, with microcode
> >> (FAM15h) enabled.
> >>
> >> Does anybody has experience with this systemboard.
> >>
> >> Is the current included ucode working with Opteron 63XX processors?
> >>
> >> 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] KGPE-D16: coreboot-4.5 stuck in boot loop. Help on getting the system to boot or flash newer version

[Pablo Correa Gómez]

Hello and thank you in advance for your time.

 I recently bought a KGPE-D16 motherboard with a single AMD Opeteron
8262SE and coreboot installed. I bought from another supplier 4 memory
sticks Samsung 8GB (M393B1K70DH0-YK0) that per this thread[1] should
work with coreboot. I am able to start the assembled system and to get
serial output. According to the logs, coreboot first does the
initialisation and training of the memory and then start working on the
PCIs. At one point in the boot sequence, I get the following message:

Loaded segments
BS: BS_PAYLOAD_LOAD times (us): entry 0 run 80561 exit 0
POST: 0x7b
Jumping to boot code at 000ff06e(b7cc1000)
POST: 0xf8
CPU0: stack: 0015 - 00151000, lowest used address 001509e0, stack
used: 1568 bytes
entry= 0x000ff06e
lb_start = 0x0010
lb_size  = 0x00116270
buffer   = 0xbfdd3000

Then it stalls for like 20-30 seconds and the booting process restarts
from the beginning. I had considered different options in order to boot
and I would like to know if someone would have any recommendations.
Right now my priority is to get the system up and working. I can worry
about installing coreboot later, but having it now is for sure a plus:
  1) Buy a new chip with the original ASUS BIOS in order to boot the
system.
  2) Externally flash the chip I have right now with a newer version of
coreboot. I probably have enough things at home to flash it, but I have
not found information from ASUS. In coreboot there is some information
but very general and not enough for my knowledge. As far as I have read
from flashrom, I should be able to flash it using a Raspberry Pi or a
BeagleBone Black, but KGPE-D16 is not marked as supported and I don't
know which model is the BIOS chip to check if it is supported.
  3) The moderboard datasheet has a section called: "Force BIOS
recovery setting", which says that in order to flash the proprietary
BIOS, it is as simple as changing a jumper an inserting an USB stick. I
would have already done it if I would not be reluctant to believe that
it is that simple.

Which are your thoughts about this ideas? Any other one that would be
simpler and would let me boot the full system?

Thank you very much,
Pablo.


NOTE: I have tried with the 4 sticks in the orange slots, the 4 sticks
in the 4 further DIMMs from the CPU (2 orange, 2 black) and those
configurations both 1.35 and 1.5V. Logs are slightly different, in the
training section, but the problem while booting remains. A USB stick
with Debian Installer has been plugged-in during since boot process
begins.

[1] https://mail.coreboot.org/pipermail/coreboot/2017-February/083151.h
tml
___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] Re: KGPE-D16: coreboot-4.5 stuck in boot loop. Help on getting the system to boot or flash newer version

[Matt B]

That method of emergency recovery with a USB stick has already been wiped
out by installing coreboot.

-Matt

On Mon, Apr 29, 2019 at 4:09 PM Pablo Correa Gómez 
wrote:

> Hello and thank you in advance for your time.
>
>  I recently bought a KGPE-D16 motherboard with a single AMD Opeteron
> 8262SE and coreboot installed. I bought from another supplier 4 memory
> sticks Samsung 8GB (M393B1K70DH0-YK0) that per this thread[1] should
> work with coreboot. I am able to start the assembled system and to get
> serial output. According to the logs, coreboot first does the
> initialisation and training of the memory and then start working on the
> PCIs. At one point in the boot sequence, I get the following message:
>
> Loaded segments
> BS: BS_PAYLOAD_LOAD times (us): entry 0 run 80561 exit 0
> POST: 0x7b
> Jumping to boot code at 000ff06e(b7cc1000)
> POST: 0xf8
> CPU0: stack: 0015 - 00151000, lowest used address 001509e0, stack
> used: 1568 bytes
> entry= 0x000ff06e
> lb_start = 0x0010
> lb_size  = 0x00116270
> buffer   = 0xbfdd3000
>
> Then it stalls for like 20-30 seconds and the booting process restarts
> from the beginning. I had considered different options in order to boot
> and I would like to know if someone would have any recommendations.
> Right now my priority is to get the system up and working. I can worry
> about installing coreboot later, but having it now is for sure a plus:
>   1) Buy a new chip with the original ASUS BIOS in order to boot the
> system.
>   2) Externally flash the chip I have right now with a newer version of
> coreboot. I probably have enough things at home to flash it, but I have
> not found information from ASUS. In coreboot there is some information
> but very general and not enough for my knowledge. As far as I have read
> from flashrom, I should be able to flash it using a Raspberry Pi or a
> BeagleBone Black, but KGPE-D16 is not marked as supported and I don't
> know which model is the BIOS chip to check if it is supported.
>   3) The moderboard datasheet has a section called: "Force BIOS
> recovery setting", which says that in order to flash the proprietary
> BIOS, it is as simple as changing a jumper an inserting an USB stick. I
> would have already done it if I would not be reluctant to believe that
> it is that simple.
>
> Which are your thoughts about this ideas? Any other one that would be
> simpler and would let me boot the full system?
>
> Thank you very much,
> Pablo.
>
>
> NOTE: I have tried with the 4 sticks in the orange slots, the 4 sticks
> in the 4 further DIMMs from the CPU (2 orange, 2 black) and those
> configurations both 1.35 and 1.5V. Logs are slightly different, in the
> training section, but the problem while booting remains. A USB stick
> with Debian Installer has been plugged-in during since boot process
> begins.
>
> [1] https://mail.coreboot.org/pipermail/coreboot/2017-February/083151.h
> tml
> <https://mail.coreboot.org/pipermail/coreboot/2017-February/083151.html>
> ___
> 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

[Vikings GmbH via coreboot]

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

[coreboot] Re: KGPE-D16 maintainership

[Kinky Nekoboi]

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

[Timothy Pearson]

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: Need help with getting KGPE-D16 working.

[Mike Banon]

Hi there, KGPE-D16 friends.

1) Please look at my not-merged-yet "AMD_XMP" changes on
review.coreboot.org: they could help you to either use a XMP 1 or XMP
2 memory profile (should exist on ALL your sticks), or - preferably -
to set up your custom memory profile that will override the SPD
values. This way, maybe you could figure out the values to make your
RAM sticks run stable. You'll need to port this code to AMD fam10h
architecture to which KGPE-D16 belongs (if I'm not mistaken),
hopefully that wouldn't be hard.

2) USB is broken at floppy-based OS - maybe fam10h could have the same
"IRQ routing" issue as fam15h has. Sophisticated OS like Linux somehow
get around this issue, while the more simple OS couldn't.

3) Glad you liked my floppy patches and collection: there are
certainly a lot of goodies that are fun and useful. Usually the latest
revisions of these, and other, unofficial patches could be
automatically obtained with a csb_patcher.sh script from 33509 change
to save your time - I'm trying my best to keep up this stuff with a
coreboot master, as well as to get merged at least some of these
changes to reduce this maintenance.

Best regards,
Mike Banon

On Thu, May 14, 2020 at 9:28 PM Peter Stuge  wrote:
>
> ragna...@tenebr.is wrote:
> > 4.  For 32GB configuration (2 x 16GB sticks), installing to the
> > closest orange slot of each CPU would not boot, it booted when I
> > installed the sticks to the second closest orange slot of each CPU.
>
> If you install memory modules as far *away* from CPU/chipset as possible then
> you create more margin in DRAM signal integrity, which can make the system
> work more reliably even if memory initialization is not perfect.
>
> The reason is that signals reflect everywhere on the memory bus.
> When the chipset drives signals and modules are installed nearby, the
> signal will reflect back at the last slot and possibly interfere with
> either the controller's request or the DRAM's response.
>
> The same happens when the DRAM drives signals, in response to requests.
> They go out from the DRAM and both left to the chipset and right towards
> those unpopulated memory slots, and then reflects there, possibly
> interfering with what the DRAM sent or with the next request from the
> controller.
>
> Mainboard memory busses, especially with many slots, go right up to the
> limit of physics, and yes there is supposed to be a little bit of margin
> and there are some workarounds available, but all of that is the
> responsibility of the memory initialization, and it's very easy to
> not get everything 100% right. Then stuff doesn't always work.
>
> With this in mind, the safest bet should be, to populate a single DRAM
> module per channel, as far away from the chipset as possible.
>
>
> //Peter
> ___
> 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

Re: [coreboot] New user of KGPE-D16

[Elisenda Cuadros]

Hello Taiidan,

I bought it used, but the seller was so kind to send me the module. It 
was a nice surprise.


If you need high quality photos of this module or anything else, please 
don´t hesitate to contact me. I will be happy to help.


My cpu is 6238 not 6328, but thank you for your advise :-) .

Regards,

- Eli



On 15/02/2018 2:46, taii...@gmx.com wrote:

On 02/14/2018 06:08 PM, Elisenda Cuadros wrote:

I have an ASMB4-iKVM. I think it's this, although it has two stickers 
and I can not see the concrete model
If you got your D16 new it comes with one (so that is probably what 
you have) - its a tiny little module that attaches next to the PCI-e 
slots - see the manual for a photo.
This is one of the reasons I always advise people to buy a new D16 as 
that module is very hard to find despite being so simple.


I imagine it could be easily reverse engineered and copied for those 
who don't have one, although I lack the time and have never done that 
sort of thing before.


re: 6328 - please be aware that this has two NUMA nodes (it is two 4 
core CPU's in a single package) and that games won't work well if you 
don't properly align the memory to have the games memory present on 
only one node (this appears to be the best arrangement)
For gaming I imagine that a C32 board like the KCMA-D8 and one or two 
of the single node/MCM opteron 4386 would be better but I run games on 
a dual numa setup in a VM without much issues - I am able to max out 
newish video games with a decent graphics card (the board also 
supports crossfire if you have mad money to burn on GPU's)



--
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] New user of KGPE-D16

[taii...@gmx.com]

On 02/14/2018 06:08 PM, Elisenda Cuadros wrote:

I have an ASMB4-iKVM. I think it's this, although it has two stickers 
and I can not see the concrete model
If you got your D16 new it comes with one (so that is probably what you 
have) - its a tiny little module that attaches next to the PCI-e slots - 
see the manual for a photo.
This is one of the reasons I always advise people to buy a new D16 as 
that module is very hard to find despite being so simple.


I imagine it could be easily reverse engineered and copied for those who 
don't have one, although I lack the time and have never done that sort 
of thing before.


re: 6328 - please be aware that this has two NUMA nodes (it is two 4 
core CPU's in a single package) and that games won't work well if you 
don't properly align the memory to have the games memory present on only 
one node (this appears to be the best arrangement)
For gaming I imagine that a C32 board like the KCMA-D8 and one or two of 
the single node/MCM opteron 4386 would be better but I run games on a 
dual numa setup in a VM without much issues - I am able to max out 
newish video games with a decent graphics card (the board also supports 
crossfire if you have mad money to burn on GPU's)


--
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] Supported Motherboards

[taii...@gmx.com]

If you want an owner controlled coreboot-libre firmware (coreboot isn't
always foss) available board get a kcma-d8, kgpe-d16, etc. or one of the
raptor computing systems OpenPOWER boards which have foss firmware (not
coreboot) from the factory, documentation and are owner controlled.

You can score a D16 new on fleabay for $150 ATM plus a 6328 cpu for $30
resulting in (with ram and a good amd gfx card) being able to play games
in a vm at max settings - there are a lot of good native linux and or
drm free games right now. It seems those new D16's sold there also have
the ASMB4 chip you need for OpenBMC.

the G34/C32 opterons are much faster than the G41's C2Q's and the
OpenPOWER9 stuff is much faster than intel/amd's proprietary blobbed x86
offerings of comparable price

I have wrote longer posts about that in the past so look 'em up :D and
welcome to the community.

I concur the g505s is a superior choice to a me'ed device as me can't be
disabled...unlike with workstations you can't have perfect with a laptop
right now here's hoping for a openpower laptop.

-- 
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] Schematics and PCB design for ASMB4 (Was: There are ASMB5's on fleabay right now for $30/ea (firmware storage module required for OpenBMC on the KGPE-D16/KCMA-D8))

[taii...@gmx.com]

On 11/03/2018 12:32 AM, Daniel Gröber wrote:
> Hi,
> 
> On Sat, Nov 03, 2018 at 12:10:25AM +0100, Angel Pons wrote:
>> Is it me, or is that thing a SPI flash chip on a PCB plus a few
>> transistors? It seems like copying the PCB design is rather doable, or am I
>> missing something?
> 
> Indeed, very doable, but tedious work ;)
> 
> Here you go:
> 
> https://github.com/DanielG/asmb4
> https://oshpark.com/shared_projects/jZLoDQ3Y
> 
> I had the schematics lying around on paper for a while now but I was
> too lazy to digitize them until now. The design is completely
> untested, I just ordered some boards though so we'll see.
> 
> FWIW if anyone is interrested in getting some assembled boards I might
> do a small production run.
> 

Holy crap awesome you are the best dude!

I asked about this awhile ago and I wish you had replied :D

I have boards without it so I would love to buy some if they are priced
lower than the official one - Do you have an estimate?

Might be a way for you to make a bit of extra cash as you could peddle
them to the various core/libreboot D8/D16 sellers plus leah/minifree,
the fsf, raptor (for integricloud x86) etc.

It is still quite important to have these boards as
propriatary-equivilant-functional for applications that don't yet run on
POWER (talos 2/blackbird) and this is a great step considering the D8
and many D16's even new don't come with that chip and they sell for IMO
too much on ebay. (my linky is $30 plus a silly $30 shipping for tiny
chip - so $60)

-- 
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] Asus KGPE-D16 non-working S3 suspend with Qubes 4

[Merlin Büge]

Hi,

as I currently have a D16 right next to me, I thought I'd just test it,
too. This is with coreboot-4.8-660-gb1d26f0e92. S3 seems to be working
somehow, but I have to press the power button to make it resume - it
doesn't react on (USB keyboard) key presses. Also it takes about one
minute to resume, with 8x 8GB RAM, single CPU.

Just in case it helps somehow...

See the attached coreboot log.

And BTW, yes, the D16 has a serial port exposed at the rear panel.

Kind Regards,

Merlin


defconfig:

CONFIG_USE_OPTION_TABLE=y
CONFIG_VENDOR_ASUS=y
CONFIG_BOARD_ASUS_KGPE_D16=y
CONFIG_COREBOOT_ROMSIZE_KB_16384=y
CONFIG_PAYLOAD_GRUB2=y
CONFIG_GRUB2_EXTRA_MODULES="cat"
CONFIG_GRUB2_INCLUDE_RUNTIME_CONFIG_FILE=y
CONFIG_COREINFO_SECONDARY_PAYLOAD=y
CONFIG_MEMTEST_SECONDARY_PAYLOAD=y
CONFIG_NVRAMCUI_SECONDARY_PAYLOAD=y





On Mon, 10 Dec 2018 13:32:04 +
petecb via coreboot  wrote:

> Hi,
> 
> I have not been able to get S3 suspend to work with this board when
> using Qubes 4. It's running coreboot v4.6 with the default CMOS
> options. It appears to go into suspend ok but when I try to resume
> the system does not respond to keyboard or mouse input and pressing
> the powerbutton results in what appears to be a fresh cold-boot.
> 
> Does anyone know whether there is a specific coreboot/cmos option I
> could be missing or if it is a Qubes configuration issue?
> 
> Kind regards,
> 
> Pete


-- 
Merlin Büge


coreboot_d16_s3_debug_01.log.gz
Description: application/gzip
-- 
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] ASUS KCMA-D8 workstation board port offer

[Leah Rowe]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

I would also like to point out that Timothy is a psychopath. The
reason I told him I couldn't pay the final 15k on the KCMA-D8 is
because I would have ended up *homeless* if I did. He told me he
didn't care, and that I didn't deserve a home or to eat properly. He
only cared about that 15k, despite the fact that I already paid the
full 75 for the D16 contract, and despite all the positive endorsement
and support that I gave TALOS on libreboot.org when that campaign was
still running.

I had every intention of paying Timothy that 15k, if I became able to.
But now that will not happen, as a result of what he has done and said
in the last 24 hours.

On 20/01/17 13:15, Leah Rowe wrote:
> I'm just going to paste what I wrote on phoronix's comments
> section.
> 
> On 19/01/17 17:58, Timothy Pearson wrote:
>> Sorry to revive an old thread, but as many of you are aware 
>> Minifree (Leah Rowe) contracted with us to port the KCMA-D8 and 
>> release it.  We performed this work and the KCMA-D8 continues to 
>> operate, however Minifree has decided not to pay their contract
>> on this work.  We strongly recommend that no person do any
>> business with Minifree or its founder Leah Rowe, as they do not
>> honor their legally binding contracts.
> 
> 
> 
> I'm perfectly happy for Raptor to publicly complain. This is only 
> fair, and they have the right. However, there are certain facts
> that I would like to point out clearly for the community.
> 
> Fact 1: I paid 100% of the KGPE-D16 contract with was 75k USD I
> did not pay the KCMA-D8 contract which was 15k. Timothy's email
> implies that I barely paid any of it. The D8 was a mere extension
> on top of the D16 and was a few weeks work for Timothy. The article
> also implies that I was unwilling to pay the remaining 15k. I was
> actually *unable* to pay. Big difference. I fully paid for the
> KGPE-D16 contract, and D16 is all that Minifree sells. Most people
> don't use D8 and it wasn't viable to sell. I would also like to
> point out that several organisations now use the KGPE-D16 with
> libreboot. This includes the Free Software Foundation, to host
> their websites. I personally sacrificed a lot to pull that off. I
> find it deeply insulting that Timothy causes all this fuss about
> the D8. The D8 port was also missold to me. I was lead to believe
> that the hardware was readily available when it wasn't (unlike D16
> hardware), so the work for the D8 was more or less a waste of
> resources.
> 
> Fact 2: Libreboot is not a dead project. We are currently working
> on a new release behind the scenes. We've merged an entirely new
> build system that was written from scratch, to replace the old one
> (the one that is "stagnant and hard to use" according to the
> article). It's in the libreboot git repository as I speak, it was
> merged a few days ago. Please mention this. The new build system is
> extremely modern, flexible and easy to use. It adds many features
> which the old build system lacked, such as (but certainly not
> limited to): * easy ability to build and integrate linux kernel
> payloads (*hint* petitboot *hint*) * integrates all
> chromebook-related utils, for rockchip ARM chromebooks * integrates
> chromeos flashrom, in addition to upstream flashrom * generally
> better design, more modular, easier to maintain, easier to build *
> plus a whole host of other advantages * about 10 new chromebooks
> have been added to libreboot. So much for libreboot being dead,
> eh?
> 
> Please also mention that Libreboot is actually abandoning coreboot
> and will be using Librecore as upstream. This will be covered in
> my upcoming FOSDEM talk too. We have been quite public about this 
> already, on the Libreboot bug tracker.
> 
> I would also like to point out, that so far Raptor Engineering has
> not fixed the bug on KGPE-D16 where above 128GiB RAM becomes
> unstable to the point of being unusable. Only up to 128GiB works.
> This is less than what the contract suggests. They also released
> source code that was broken; memory initialization was broken on
> most memory modules. It took 6 months after the initial release of
> the KGPE-D16 source code for them to make memory initialization
> work, and even now raminit only works with a few modules.
> 
> This is in addition to other bugs which they haven't fixed. I also 
> have IRC logs of private conversations between me and Timothy,
> where he states that he's willing to let the free/libre hardware
> movement crash and burn. This was before the dispute that happened
> yesterday regarding payment.
> 
> 
> 
> 

- -- 
Leah Rowe

Libreboot developer

Use free software. Free as in freedom.
https://en.wikipedia.org/wiki/Free_so

Re: [coreboot] coreboot ported to the ASUS KGPE-D16 (Libreboot: blobless, fully functional!)

[Emilian Bold]

I'm curious, is there some Coreboot Foundation that would gather this money
and purchase the copyright or would Raptor just somehow crowd-fund this
money to license their work as GPLv2 while keeping the copyright?

--emi


On Thu, Apr 30, 2015 at 4:54 AM, Ward Vandewege w...@gnu.org wrote:

 On Wed, Apr 29, 2015 at 10:46:29PM +0100, The Gluglug wrote:
  You should crowd-fund the $35,000 figure, there are lots of people who
  will be interested in this. I personally will chip in, and I'd ask
  others to as well.

 I would chip in too.

 Thanks,
 Ward.

 --
 Ward Vandewege
 GPG Key: 25F774AB

 Do you use free software? Donate to join the FSF and support freedom at
  http://www.fsf.org/register_form?referrer=859

 --
 coreboot mailing list: coreboot@coreboot.org
 http://www.coreboot.org/mailman/listinfo/coreboot

-- 
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] coreboot ported to the ASUS KGPE-D16 (Libreboot: blobless, fully functional!)

[Timothy Pearson]

On 04/29/2015 04:56 PM, The Gluglug wrote:


What about simply pushing the code as-is (make your non-upstream tree
publicly available for people to git-clone), and let the community
upstream it in their own time?


There is no real incentive for Raptor to do this.  There is no guarantee 
of code actually being up-streamed and maintained by the community, but 
after this release our competitors may use the code at will.


To be clear, we use coreboot internally on a large server cluster.  This 
port is the result of an internal effort to upgrade said cluster, and 
while it is in our financial interest to upstream ports of older boards 
(e.g. the ASUS KFSN4-DRE) that did not require changes to the underlying 
support code, it is _not_ in our financial interest to simply release 
the code to modern boards that required major changes to underlying 
support code.


--
Timothy Pearson
Raptor Engineering
+1 (415) 727-8645
http://www.raptorengineeringinc.com

--
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot

[coreboot] x86 smm: memory sinkhole attack

[Francis Rowe]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hi,

I've been reading lately about this attack:
https://github.com/xoreaxeaxeax/sinkhole

Some summary articles:
*
http://www.theregister.co.uk/2015/08/11/memory_hole_roots_intel_processors
* http://www.bit-tech.net/news/hardware/2015/08/07/x86-security-flaw/1

My basic question is: are coreboot systems affected by this
vulnerability, and if so, what work is being done to patch it?

Specifically, in my case, I am interested in the following coreboot
systems:
* i945 platforms (Lenovo X60/T60, Macbook2,1)
* GM45 platforms (Lenovo X200/T400/T500/R400/R500)
* fam10h AMD platforms (ASUS KFSN4-DRE, ASUS KGPE-D16)

Could someone shed a light on this?

Regards,
Francis Rowe.

-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQEcBAEBAgAGBQJVy1gdAAoJEP9Ft0z50c+UYm0H/RutL81jWDKpYx9AGaSnIt5Y
kwhyRj5MByd4pB6TUF/nVEwvxtpef/rhLvE611Gv3s85+7oCRoqdg6kcgMuOvtW/
/8xN3XnzmbJlQgCvc99rN1Tm/GJ1oqHcVUZx8Rj3ljG2l9qGtdGIaKiZmhwW82pD
TeV9IUEKb7KTLaX/asSCZoJexRMd4zmfFb36wHpbHih9XDSUxdf1QKXRRBr1PhLf
IxXLhS/0+YXmfUHksvOco5z5pB96ApMfzU409ewbJb3kDK7Dfp2C37QRqjP+S2wO
kqPQBgGrQc74vzbgdQjxg3f9XqNzhUlZH56Tw2sUPNlUJxRCvKJLIcpjxvtSLEE=
=z7lk
-END PGP SIGNATURE-

-- 
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] x86 smm: memory sinkhole attack

[Patrick Georgi]

2015-08-12 16:28 GMT+02:00 Francis Rowe i...@gluglug.org.uk:

 My basic question is: are coreboot systems affected by this
 vulnerability, and if so, what work is being done to patch it?

I reviewed our SMM handler, drafted out how to mitigate any potential issue
and started work on a PoC. Then got distracted by something else.

My test system is the getac/p470 (i945, core2duo CPU)

Specifically, in my case, I am interested in the following coreboot
 systems:
 * i945 platforms (Lenovo X60/T60, Macbook2,1)
 * GM45 platforms (Lenovo X200/T400/T500/R400/R500)



 * fam10h AMD platforms (ASUS KFSN4-DRE, ASUS KGPE-D16)

Totally different architecture, I'm not sure if the APIC decoding behavior
even translates to that.


Patrick
-- 
Google Germany GmbH, ABC-Str. 19, 20354 Hamburg
Registergericht und -nummer: Hamburg, HRB 86891, Sitz der Gesellschaft:
Hamburg
Geschäftsführer: Graham Law, Christine Elizabeth Flores
-- 
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] Dead links - missing information?

[Patrick Georgi]

2015-07-27 19:19 GMT+02:00 Karl Schmidt k...@xtronics.com:

 This page has several dead links and I was unable to find a single
 coreboot server motherboard for sale after following the links.

 http://www.coreboot.org/Products

Thanks, I cleaned up at least the dead links on that page.
We'll need to decide what it is supposed to cover before that page becomes
really useful again. For example, Chromebooks are pretty much not covered,
despite being the most easily available device on the market that runs
coreboot.

One server board that is for sale and can be equipped with coreboot would
be the ASUS KGPE-D16.


Patrick
-- 
Google Germany GmbH, ABC-Str. 19, 20354 Hamburg
Registergericht und -nummer: Hamburg, HRB 86891, Sitz der Gesellschaft:
Hamburg
Geschäftsführer: Graham Law, Christine Elizabeth Flores
-- 
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] Dead links - missing information?

[Karl Schmidt]

On 07/29/2015 01:54 PM, Patrick Georgi wrote:


One server board that is for sale and can be equipped with coreboot would be 
the ASUS KGPE-D16.

I looked at that - those are 5 years old now.. I would worry about the age of 
the capacitors.

I'm no longer seeing any MB - desktop or server that are from the last 2 years? And no one selling 
such systems?


Also - I did some work with some UEFI BIOSs - I think there is an small OS running on top of 
everything?  (not something the lends itself to creating secure systems... ). Thus my quest for a 
coreboot system.


I had looked a few years ago and had the sense that there were rather current options - it appears 
that the climate has changed?  Or am I missing part of the bigger picture?


--

Link to our website and get free US-48 shipping on your next order.

Karl Schmidt  EMail k...@xtronics.com
Transtronics, Inc.  WEB 
https://secure.transtronics.com
3209 West 9th Street Ph (785) 841-3089
Lawrence, KS 66049  FAX (785) 841-3089

The lack of a middle class is a good indicator of how corrupt a government is.
kps


--
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] Thinkpad x230 video glitches during boot

[ron minnich]

On Sun, Jul 24, 2016 at 11:32 AM Trammell Hudson <hud...@trmm.net> wrote:

>
> The Qubes kernel is the Xen hypervisor and is only about 800 KB.
> I'm attempting to add it as the payload, although I think that a minimal
> Linux in ROM that kexec's Xen from an encrypted and measured disk image
> will be better suited to my goals.
>
>
>

well, that suits my goals as well, and I'm working on the same thing :-)

I have linux and root file system in flash on a KGPE-d16. All my tools in
root file system are written in Go, i.e. not busybox.  I'm currently trying
to get kexec in Go done. It's a pain but evidently in 4.x kexec got far
easier to work with.

I'm hitting one problem: I need to get a working 4.7.0 kernel as a payload.
I have a 3.18 working fine, as payload, but the 4.7.0 never puts out any
serial output. If you have a 4.x.+ kernel config that works as a payload,
let me know.

I'm happy to see you blazing the trail :-)

ron
-- 
coreboot mailing list: coreboot@coreboot.org
https://www.coreboot.org/mailman/listinfo/coreboot

[coreboot] Supermicro H8QGI-F (Quad G34) - blob status?

[taii...@gmx.com]

https://www.coreboot.org/Board:supermicro/h8qgi

A quad g34 with 1TB RAM would be nice to have...

I am creating a beginners guide with all the new enough to be useful and 
easily available brand new in box boards, I am curious if anyone uses 
this as I have the following questions:


- Does it work without blobs? (what happens if you don't include the 
video bios blob? can you still get video via seabios or linux?)
- Can you de-activate the on-board iKVM? (sketchy, it seems to have an 
interface to one of the regular nics too)
- Are there any problems with reaching the full OEM 1TB spec RAM (like 
where the kgpe-d16 can only go to 192gb instead of the spec'ed 256



--
coreboot mailing list: coreboot@coreboot.org
https://www.coreboot.org/mailman/listinfo/coreboot

[coreboot] KGPE-D16 SR-IOV problems (iommu groups) - Anyone else tried this?

[taii...@gmx.com]

Assigning regular devices such as a graphics card to a VM works just 
fine, but when I try to assign an intel i350 virtual function I receive 
the error


"error: internal error: Invalid device :07:10.0 iommu_group file 
/sys/bus/pci/devices/:07:10.0/iommu_group is not a symlink"


The PF's are split in to seperate IOMMU groups like every other pci-e 
device but for some while the VF's appear in lspci they aren't placed in 
IOMMU groups at all not even in the ones that the PF's are in.


Weird.

Note: PCI-e root ports all report ACS support and so does the NIC and I 
am using the /etc/modprobe.d/blahblah.conf max_vfs option to enable SR-IOV.



Help from intel is blood from a stone, so I am wondering if anyone else 
has this successfully working?
(I just bought a null modem cable and I now have free time to supply 
whichever logs are needed)



--
coreboot mailing list: coreboot@coreboot.org
https://www.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] Does the 62xx Series Opteron work *securely* without microcode?

[taii...@gmx.com]

On 01/26/2017 10:12 AM, ron minnich wrote:

On Thu, Jan 26, 2017 at 3:41 AM Sam Kuper <sam.ku...@uclmail.net> wrote:



Hypothetical example: I buy a machine with built-in microcode from the
young Anakin Skywalker. A decade later, Darth Vader releases a
microcode update. Should I apply it?



A decade later? You should buy a new computer.

ron

Very excellent example Sam, couldn't have said it better myself.

For us who desire libre computing that simply won't be an option, 4 
years from now when the KGPE-D16 is a 10 year old motherboard you will 
only be able to buy ME/PSP junk or expensive POWER servers which while 
lacking a supervisor processor certainly aren't libre...yet (as no-one 
who is able to is willing to fund development)


I have an 8 year old server myself, there isn't any reason to buy a new 
one as it isn't being used for anything that needs super juice.


--
coreboot mailing list: coreboot@coreboot.org
https://www.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] KGPE-D16 BMC Port Offer (was: Fund a TALOS Secure Workstation as coreboot build system)

[Timothy Pearson]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 01/19/2017 11:36 AM, Martin Roth wrote:
> Hey Merlin,
>   I was taking and keeping track of the pledges for Talos, so I'd be
> happy to continue.
> 
> Martin

I just wanted to bring this back up for discussion.  Raptor is chipping
in funding for over half of the development work, and Martin is matching
pledges, so if there's interest in this port your contributions will go
a long way, but it still depends on community interest.  Are you willing
to contribute to this development project?  It is a limited time offer,
so the quicker we can reach the relatively low goal to get this work
underway the better. :-)

Thanks!

- -- 
Timothy Pearson
Raptor Engineering
+1 (415) 727-8645 (direct line)
+1 (512) 690-0200 (switchboard)
https://www.raptorengineering.com
-BEGIN PGP SIGNATURE-
Version: GnuPG v1
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQEcBAEBAgAGBQJYijUnAAoJEK+E3vEXDOFbQKAIAKPqeHZylATs3aZXC2QeTmUG
p0bnwfU4G+0qkXEwApoYk+y8WRKEkhBsug5EvzEXw65fAAmwi4COVjUBvm2l9kUI
m3/51sfrZRpo+H8c1lXld0WiwomTGapm9FX3rqAjLZn354TOqnrfoGYoJQC+ovKm
0AYXCGN8fmWkr6nTj9Q1tWwxEXrRv48YudF8bDFZhbMjOswnagNzImQNTC6wLgnY
+7UyqBgpihc8vh3GoGuPQT1mNpAtUwv1PS8HFGnDO86zW9gWB7+xHEGBhMyy+Rys
CTNWkI15X4dy8pz6XIsqjuBNSUcgTnVVAelecdm1BfykpgSyPyOf/39JQc/O41M=
=HzeR
-END PGP SIGNATURE-

-- 
coreboot mailing list: coreboot@coreboot.org
https://www.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] Fund a TALOS Secure Workstation as coreboot build system

[taii...@gmx.com]

Tim, how come you guys didn't go after government and corporate sources 
of funding? I read DARPA is really interested in assured computing these 
days.


Maybe there should be a fund for a IBM/TYAN POWER system for the 
coreboot project?, maybe better than being stuck doing development on an 
older platform?


Does anyone know how long ASUS will keep making new ones?

Something for people to think about - In 2012 a brand new KGPE-D16 
spec'ed out with cpus and memory would have been just as much as a 
POWER8 system is now (I read on a forum that someone got a S822LC for 5K 
through an IBM corporate rep)


(I would just buy you guys one but I am unemployed despite the bogus "it 
worker shortage")


--
coreboot mailing list: coreboot@coreboot.org
https://www.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] [Resend] Tapping into the core (33C3)

[taii...@gmx.com]

Bootguard can be bypassed by simply swapping compatible CPU's from two 
computers/laptops, correct?


The bigger issue is, do we really want to support a company that will 
one day succeed in shutting us down? while x86 is the only real option 
for a mobile workstation I feel as though all desktop/server development 
should be focused on POWER as IBM isn't yet entirely hostile to the idea 
of free firmware (in 2012 a new kgpe-d16, compatible RAM, cpu's etc 
would be as much as a power habanero is now, it isn't really that 
expensive the only issue is that they don't depreciate in value as much 
as an x86 device so it isn't as easy to pick up older models for cheap)


What do you guys think?

--
coreboot mailing list: coreboot@coreboot.org
https://www.coreboot.org/mailman/listinfo/coreboot

[coreboot] Neither seaBIOS or GRUB payloads are able to boot gentoo [amd_pmu_init performance counters freeze] [KGPE-D16]

[taii...@gmx.com]

I have tried booting with multiple gentoo kernels but every time it 
either hangs on amd_pmu_init ("amd performance counters") with a stack 
trace or simply black screens and reboots quickly.


Other distros (fedora, opensuse) work fine.

I have tried coreboot 4.5 and the git version but neither work.

I would post this on the gentoo forum but it seems like a coreboot 
problem instead as the same kernels work fine on other machines.


Any ideas? This happens with both the LiveCD/USB kernel (-nofb doesn't 
change anything either) and the deblobbed hardened kernel.



+ (if anyone knows) How come I have to run fancontrol/pwmconfig to get 
the fans to slow down? The proprietary bios had the same issue until I 
found an option for "whisper" fan control mode.


--
coreboot mailing list: coreboot@coreboot.org
https://www.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] new problem with KGPE-d16

[Timothy Pearson]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 01/09/2017 04:55 PM, ron minnich wrote:
> yes I do. I'm working from ToT. Bisecting now

This brings up an interesting question.  How should we be testing for
payload-dependent failures on systems like the REACTS?  The possibility
of the payload causing breakage within coreboot itself was not even
considered before now.

- -- 
Timothy Pearson
Raptor Engineering
+1 (415) 727-8645 (direct line)
+1 (512) 690-0200 (switchboard)
https://www.raptorengineering.com
-BEGIN PGP SIGNATURE-
Version: GnuPG v1
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQEcBAEBAgAGBQJYdBYAAAoJEK+E3vEXDOFbt6EIAJZ5Dfg5WvkeA4OKWlOqX9R/
ZSmqOyaJFmf4PQEsYlhnJqH6NkvSnYJIekwKG8oEC7zOVyJe439BQe/9t42kMZkL
PB9EX9NedeMO9jLsSMz5C6sSxn4UIJrqHJ//w2uowVmjvNb/kOkq2Yd8Elx2tS//
bQk5At+zL/HE/86ZVmgfHxyelAkyjYAEf4c2IrmZT72uyoH3NX4aIdvnTftoNhsV
7pTpRqTtlcAg2fp7JX2v6vfiee6SculQDq+xVCDtXTYACZVsUYZnbS5c/158KKAv
Rndq+mYZwSoJGQFcRQm6hkAMfRPzvQWoYhVAW5LrQaiQu1HbyHgyRGPS4Jx4ULc=
=P5u1
-END PGP SIGNATURE-

-- 
coreboot mailing list: coreboot@coreboot.org
https://www.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] new problem with KGPE-d16

[ron minnich]

On Mon, Jan 9, 2017 at 3:00 PM Timothy Pearson <
tpear...@raptorengineering.com> wrote:

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> On 01/09/2017 04:55 PM, ron minnich wrote:
> > yes I do. I'm working from ToT. Bisecting now
>
> This brings up an interesting question.  How should we be testing for
> payload-dependent failures on systems like the REACTS?  The possibility
> of the payload causing breakage within coreboot itself was not even
> considered before now.
>
>
I think what we need is a good regression test payload kernel. This is what
I"ve done on ports to powerpc and riscv. You have a simple priveleged mode
bundle of code that exercises known failure cases.

I've found plan 9  (now harvey) to be an easy code base for this, but a
smaller, lighter kernel would probably be even better.
-- 
coreboot mailing list: coreboot@coreboot.org
https://www.coreboot.org/mailman/listinfo/coreboot

[coreboot] new problem with KGPE-d16

[ron minnich]

what's weird is coreboot is unchanged, just the payload.

I am wondering if anyone recognizes this

IMD small region:
  IMD ROOT0. bfffec00 0400
  ROMSTAGE1. bfffebe0 0004
  GDT 2. bfffe9e0 0200
Writing AMD DCT configuration to Flash
CBFS: 'Master Header Locator' located CBFS at [100:c0)
CBFS: Locating 's3nv'
CBFS: Found @ offset 2fec0 size 1
Manufacturer: ef
SF: Detected W25Q128 with sector size 0x1000, total 0x100
FCH SPI: Too much to write. Does your SPI chip driver use spi_crop_chunk()?
SF: Failed to send command 06: 1
FCH SPI: Too much to write. Does your SPI chip driver use spi_crop_chunk()?
SF: Failed to send command 06: 1

Also ... "Too much to write" ... I'll submit a CL but, folks, "Too much to
write"? How about some numbers on this kind of message :-)
-- 
coreboot mailing list: coreboot@coreboot.org
https://www.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] How to improve the boot time of the Asus KGPE-D16?

[Timothy Pearson]

On 03/15/2017 04:09 PM, Daniel Kulesz via coreboot wrote:
> Hi,
> 
> I wanted to try caching of the MRC training data. As described in Timothy's 
> post, I commented the following line:
> 
>> allow_config_restore = 0;
> 
> However, I was not able to measure any effects regarding boot time. Does this 
> setting only work with cbfs enabled? And if so, is it necessary to set 
> additionally any cbfs variables?
> 
> Cheers, Daniel

You will need NVRAM enabled for this setting to work.  Additionally,
there is some instability when this line is uncommented; when I have
some free time available I'll take another look at why.

Thanks!

-- 
Timothy Pearson
Raptor Engineering
+1 (415) 727-8645 (direct line)
+1 (512) 690-0200 (switchboard)
https://www.raptorengineering.com

-- 
coreboot mailing list: coreboot@coreboot.org
https://www.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] Crowdfunding Status for KGPE-D16 BMC Port Offer

[Timothy Pearson]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

> Are there any status updates on this?
> 
> I noticed that some people still haven't paid up and we're a couple
> grand short.

That is correct; unfortunately we're still waiting for the remaining
payments.  I'm checking with Martin to see if we've had any success with
collecting the last payments, but if we haven't been able to collect by
the end of the month the most likely action will be to drop one of the
stretch goals and move forward without it.

- -- 
Timothy Pearson
Raptor Engineering
+1 (415) 727-8645 (direct line)
+1 (512) 690-0200 (switchboard)
https://www.raptorengineering.com
-BEGIN PGP SIGNATURE-
Version: GnuPG v1
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQEcBAEBAgAGBQJY9PLoAAoJEK+E3vEXDOFb4GoH/Rq4sTkdQ1lychaxXfElpA2s
BP7UoVeUDQHMott8Hyf0f3XZeTZkO5hhaq4gD30pQBwyWdbr2ncHb8C8TuCamGy+
2Tz8VZCG9IIK5dmsuJU/cKseJd7ICjCb5nkp7BTNlhw6BY/XMMjWwjwPUtzoSAch
P9CEcbpPmkuhanNorKTi0vlES3iuDfg7S3k8JVr7jm8ujYZxHk2c5Z07ieu77MJ0
eflv2thQ2t1aolqmRBjiq9ZtCdSb2hQfxhWj5ohc4gVA41Q127Tx66T5rrHrOfKh
+86+gtymZ4GTL4ohLTB6tfaWxpvblDNJVVnY5Hm1rtzLXQqwvIVUzMf70pgS6BY=
=GZSw
-END PGP SIGNATURE-

-- 
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] Crowdfunding Status for KGPE-D16 BMC Port Offer

[taii...@gmx.com]

Today I noticed a new stretch goal about flashrom support (kinda late in 
the game), it seems pretty important to have this so I think that the 
stretch goal funding should be extended.


I had assumed that the BMC firmware would be stored in and loaded from 
the main coreboot flash image, or that there would be a shim loader 
installable on the bmc firmware module that would (as the BMC has DMA) 
load the firmware from memory for easy updating.


The requiring of the firmware module may be a problem for some people 
because apparently there are two different SKU's from asus one of which 
didn't ship with it and no retailers sell it separately.


Also, If the stretch goal doesn't get funded is it possible to perform a 
"clean" flash with a test clip?


--
coreboot mailing list: coreboot@coreboot.org
https://www.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] How to improve the boot time of the Asus KGPE-D16?

[Arthur Heymans]

Paul Menzel via coreboot  writes:


> I think most of the time is spent in RAM initialization.
>
>1. Do board owners with similar amount of memory (independent of the
>   board) have similar numbers?
>2. What are the ways to improve that? Is it possible? For example, can
>   the modules be probed in parallel (if that isn’t done already)?
>
I'm not the right person to answer this since I don't know this
code/hardware that well, but on modern Intel hardware native code uses
the MRC cache to store dram training results and restore those on
next boots (and resume from suspend) if no change in dimm configuration
was detected.

Maybe something like this could also be applied here (or maybe it's already
the case since it includes code to access spi flash)?

>
> Thanks,
>
> Paul

Kind regards
-- 
Arthur Heymans

-- 
coreboot mailing list: coreboot@coreboot.org
https://www.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] ASUS KGPE-D16 PIKE slot usable as a PCI-e x4 slot

[Christian E . Jørgensen]

On 2017-07-21 20:40, Timothy Pearson wrote:

It works, yes.  ASUS just flipped the slot around for the PIKE slot as 
a
crude form of lock-in to the PIKE cards.  Electrically and 
firmware-wise

it's just a standard 4x slot.


A crude form of lock-in indeed. I'm glad that it's only a minor 
annoyance to someone who just wants to use the slot as a standard PCI-e 
x4 slot.


Anyway, I've just ordered the riser and this low profile M.2 to PCI-e 
adapter:


http://www.ebay.com/itm/Desktop-Dual-Port-NGFF-M-2-B-M-Key-SSD-to-PCI-Express-4X-PCI-E-Adapter-Card/112479629708

Now I'm hoping that Petitboot will let me boot from it. :-)


Christian

--
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] ASUS KGPE-D16 Automated Test Failure [master]

[Timothy Pearson]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 05/25/2017 12:35 PM, BogDan Vatra wrote:
> Hi,
> 
> It's this a false positive? i.e. it's a problem with the test or
> actually coreboot doesn't boot?
> 
> BogDan.

There remains an undiagnosed race condition in coreboot's Opteron
startup code that leads to an occasional (empirically this seems to be a
1 in 3 chance) hang in ramstage when the debug level is cranked up and
the AP console output is enabled.

I've been wondering if I should lower the debug level on the test stand
for this particular board to mask the problem, or if these occasional
reminders might prod someone to take a look at the problem?

- -- 
Timothy Pearson
Raptor Engineering
+1 (415) 727-8645 (direct line)
+1 (512) 690-0200 (switchboard)
https://www.raptorengineering.com
-BEGIN PGP SIGNATURE-
Version: GnuPG v1
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQEcBAEBAgAGBQJZJxs6AAoJEK+E3vEXDOFbKIsH/iS3yOPdg27VSd1qrcF+ArWf
DvqbyRw6/n0uVH74GL+H2hzZljCg8zhgzpBCcF66EqNMdmLri1VSQo3BI6fe7j7K
0ozJ9BbK1UU4yuY40BFOF7zVRE0aPE8HdNoY7tUzFBAA5tslSgfuk158FeejEmXB
/qdhBiIjaGoIF8bbOMgg8lI9XUwHxpi2Dvqo7pOH58/bYmavGaKQEgai8ntDtwR7
xFt+kFNqhXvX21990sxOvK44Z0h+P7rPDMjNqniyCQbxR8hGpkflyHjNCBAQ8+i9
7QuMvnPmcaLIjW4FqEmXOFGfI0GAdqzXYARz9/ptmQoOys5u6JAJfz+oDv/4uJw=
=00Vf
-END PGP SIGNATURE-

-- 
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot

[coreboot] ASUS KGPE-D16 IOMMU issue

[lowsec]

Hi,

when starting a video I'm getting the following error with activated 
IOMMU under Coreboot:


[  230.800362] AMD-Vi: Event logged [
[  230.800368] IO_PAGE_FAULT device=08:00.0 domain=0x 
address=0x7370 flags=0x0050]

[  230.800371] AMD-Vi: Event logged [
[  230.800373] IO_PAGE_FAULT device=08:00.0 domain=0x 
address=0x73700040 flags=0x0050]

[  230.800375] AMD-Vi: Event logged [
[  230.800376] IO_PAGE_FAULT device=08:00.0 domain=0x 
address=0x7370 flags=0x0050]

[  230.800377] AMD-Vi: Event logged [
[  230.800378] IO_PAGE_FAULT device=08:00.0 domain=0x 
address=0x73700040 flags=0x0050]


There are over 100 lines in dmesg and it's caused by my Xonar DX sound 
card. With the proprietary BIOS everthing works fine.
I'm using the latest Linux-kernel and the Raptor build config for 
Coreboot.


This is basically the same bug: 
https://bugzilla.kernel.org/show_bug.cgi?id=111711


--
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] [KGPE-D16] No video output with Ati x600se GPU

[aether]

Hello,

> No, afaik the VGA rom is only needed for native gfx init on (some) devices 
> with embedded graphics but not for add-on pci(e) cards.

Ok.

> It seems like you are not using SeaBIOS. Normally, Seabios initializes PCI 
> devices. 
> Are you sure you are using the same coreboot configuration that worked fine 
> for your GTX660 
> with this ATI card or did you rebuild/reflash coreboot inbetween?

It is the same rom I was using with the GTX660. No changes.
Seabios was starting fine, menu quickly appeared after coreboot init was done.

I don't have enough knowledge to interpret cbmem output but I was wondering 
if something was wrong before Seabios payload execution ? Is the Ati card 
detected ?
Only Aspeed VGA controller seems to be recognized.

Also, what is meaning of this :

"link_width=2, lane_mask=ffPcieLinkTraining port=c:lc current state=2030506" ?



Thank you,

aether





-- 
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] KGPE-D16 BMC port

[taii...@gmx.com]

On 08/29/2017 02:24 PM, Timothy Pearson wrote:

Let me know what you think of the OpenBMC system.  We're considering
allowing bugs to be tracked on GitHub; is this something the community
wants to see or would a separate Bugzilla type install be preferred?  We
want to provide the infrastructure needed for the community to start
working with and enhancing this port, so suggestions and comments are
welcome!

I don't like that nearly everything these days is on too-big-to-fail 
github so I always prefer a self hosted option.
"Don't put all your eggs in one basket" was forgotten by the massive 
amounts of projects who think that git should = github - at least 
coreboot developers don't think that :D


It is truly excellent to see the rare successful crowdfunding project 
bearing fruit, raptor is making history!


--
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] Coreboot support on H8SGL-F

[taii...@gmx.com]

On 11/01/2017 08:06 AM, Lucian Cojocar wrote:


Hi,

Is coreboot working on the H8SGL-F motherboard[1] with AMD Opteron 6168
(10h Family)?

Probably not, the code hasn't been modified since 2011.

I would just get a KGPE-D16, then you can use OpenBMC (it is very nice 
to have) and benefit from the coreboot fam15h native init code that has 
IOMMU for 62xx and 63xx CPU's.

I know there is support for the H8SCM-F[2] board, which is very similar.
The only difference between the two boards seems to be the socket. It
seems there was some interest in this direction a while back ago[3].

G34 vs C32 is potato potatoe (same thing)
If you want quad socket you could probably port either board to the 
native init code without much effort if you know what you are doing then 
gain IOMMU support (that AGESA has no IOMMU support, it will also be 
removed from coreboot soon due to some silly choices by the leadership 
meaning you wouldn't be able to use these boards on the future released 
versions even if they did work)


--
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] KGPE-D16 AMD-vi fails because combined sata is enabled

[Peter Stuge]

Thierry Laurion wrote:
> ENABLE_IDE_COMBINED_MODE available for sp800 but not for sp700, for ewhich
> sp5100 is derived from:
..
> Suggested Workaround
> Disable combined mode by setting a platform BIOS callback option to CIMx
> called "SataIdeCombinedMode" to 0.
..
> Is there something i'm missing? Is it possible to disable combined
> sata mode for sb700 from coreboot?

SB700 mainboard support seems copypasted rather than engineered. The
sustainable solution is to move sb700_cfg.c from src/mainboard/*/
to src/southbridge/amd/cimx/sb700/ and hook the configuration in that
file into Kconfig.

Until someone does that, you could indeed change the assignment of
that option by looking for

SataIdeCombinedMode

in the source code, if a sb700_cimx_config() function is called for
this board - but that might not be the case if the board port chose
not to use that part of AGESA.


//Peter

-- 
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] ast2400 / ast2500

[taii...@gmx.com]

On 10/20/2017 03:04 PM, Tirumalesh wrote:


Thanks for the reply, it is somewhat strange though.

It means no server board runs fully with coreboot as firmware for both c86 and 
BMC.

If this is not the case, what kind of bmc is used by all the supported boards, 
all of them are using different firmware for bmc and x86?
As tim said the KGPE-D16 and KCMA-D8 have a fully open source libre init 
process on coreboot and support the libre OpenBMC for the AST BMC chip


There aren't any other coreboot boards that support a BMC, and the only 
other device that has both fully open source firmware/init and an open 
source BMC off the shelf is the TALOS 2.


Coreboot itself couldn't be ran on a BMC chip, well I suppose one could 
port it but there really wouldn't be a point to that as that isn't what 
it was designed for.



PS welcome to the list :D

--
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] ast2400 / ast2500

[Tirumalesh]

Thanks for the information.

As I understand correctly, the main support is for x86 only. So if we want to 
run coreboot as the only firmware, we have to do it our self.

Thanks,
Tirumalesh

On Fri, Oct 20, 2017 at 6:42 PM, taii...@gmx.com <taii...@gmx.com> wrote:

> On 10/20/2017 03:04 PM, Tirumalesh wrote: > Thanks for the reply, it is 
> somewhat strange though. > > It means no server board runs fully with 
> coreboot as firmware for both c86 and BMC. > > If this is not the case, what 
> kind of bmc is used by all the supported boards, all of them are using 
> different firmware for bmc and x86? As tim said the KGPE-D16 and KCMA-D8 have 
> a fully open source libre init process on coreboot and support the libre 
> OpenBMC for the AST BMC chip There aren't any other coreboot boards that 
> support a BMC, and the only other device that has both fully open source 
> firmware/init and an open source BMC off the shelf is the TALOS 2. Coreboot 
> itself couldn't be ran on a BMC chip, well I suppose one could port it but 
> there really wouldn't be a point to that as that isn't what it was designed 
> for. PS welcome to the list :D-- 
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] KGPE-D16: Trouble using three PCIe cards simultaneously

[taii...@gmx.com]

Did you get my email? can you provide a:
dmesg
# lspci -t -v
# lspci -vv

Thanks

Most quad adapters use PCI-e bifurcation not a PCI-e switch and AFAIK
not many boards support bifurcation so you would need a switched model
which you might have (I am not sure) if you do have a switched card I
would also contact the OEM as there shouldn't be any reason as to why it
doesn't work.

Not having PCI-e 3.0 wouldn't make a difference at all in terms of the
card working with all 4 cards and if the cards uplink is PCI-e 2.0 x8 or
x16 you won't notice a difference in speed.

VROC is an optional wintel gimmick addon that shouldn't be required for
it to work - if you could link a .pdf manual I will find out if it is
switched or bifurcated.

-- 
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot

[coreboot] [RFH] Native AMD fam10-15 support

[Kyösti Mälkki]

Hi

Now that we wiped out K8, I'd like to put my eyes on fam10-15 boards.

Couple questions for board owners:

First, about asus/kcma-d8 and asus/kgpe-d16: Do these have working S3
support? I remember rumours they originally worked at some point, but
regressed during the rebase / upstream process. Anyone willing to
bisect/fix it if necessary?

I am asking, because these are the last two remaining boards with
combination of HAVE_ACPI_RESUME=y and RELOCATABLE_RAMSTAGE=n, and we
have to drag along some back-and-forth memory copy code to keep OS
memory intact for these two.

Second, I would like to move forwards with AMD fam10 to have
RELOCATABE_RAMSTAGE=y, that would also solve above-mentioned issue and
open up doors for some new features.

If it was my decision, RELOCATABLE_RAMSTAGE for x86 would be one
criteria to survive the next (October 2018?) release. POSTCAR_STAGE
for May 2019. I am probably too late to make such wishes, but I hope
these will happen in the next two years nevertheless.

Kyösti

-- 
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] RV: Error booting with TPM enabled.

[taii...@gmx.com]

On 06/23/2018 01:58 AM, Jorge Fernandez Monteagudo wrote:
> Hi Nico, thanks for the feedback!
> 
> 
>> I guess it's used, but you need an acpi name for all devices along the
>> path. "LIBR" is the name for the LPC device, there should also be one
>> for the PCI bus/domain. I would try `src/northbridge/amd/pi/00660F01/
>> northbridge.c`.
> 
> 
> Could you point me to an example to know what I have to look for, p.e, to a 
> good supported board or something related. I'm still introducing me in the 
> coreboot world :)

The KGPE-D16 and KCMA-D8 are I would say the best examples of coreboot
boards, they have the most features such as IOMMU-GFX and OpenBMC and
their code base is 100% open source/libre. They also of course support
TPM via a removable TPM header module.

The various sandybridge and ivybridge thinkpad T/X/W series laptops are
the most widely used coreboot devices that support TPM and can be
obtained for not much money if you want to have a working example.

-- 
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot

[coreboot] [off topic] Opteron CPU missing chips on the bottom

[taii...@gmx.com]

I purchased a used g34 opteron off of fleabay (sold as working with no 
mention of this) and I noticed that it is missing some of the bits on 
the bottom and that most of them are crooked, I haven't tried it in my 
system yet and I am wondering should return it? or if there isn't any 
much risk of it damaging my (expensive kgpe-d16) motherboard and I 
should see if it works?

I got it for half the usual priceguess I should have asked for photos.

I noticed many CPU's sold on ebay have this issue (in those cases they 
mentioned it) but I can't understand how it happens, for instance I 
noticed a 6386 for sale where they mentioned that it was missing a few 
and because of that it doesn't work in a dual socket configuration.



--
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] External flashing PCI-e RAID card firmware

[Alberto Bursi]

On 15/02/2018 02:56, taii...@gmx.com wrote:
> I am contemplating the purchase of an ASUS PIKE for my KGPE-D16 and I 
> was wondering if anyone here knows if it is possible to externally 
> re-flash them.
>
> I notice a SOIC-8 chip on the front of the card and I imagine the 
> firmware is there, does it entail simply hooking up a test clip and 
> using flashrom as one would with a motherboard?
>
> 20% chance the manufacturers utility performs some type of secret 
> sauce that is required for it to function.
>

the sas controllers require multiple flashes at different positions,  
and afaik only the manufacturer's utility knows where.

I don't think it is doing anything particularly exotic, and it works 
from FreeDOS, so you can just follow the tutorials and then use the 
external flasher to see what is being done to the flash chip so you know 
where it writes stuff, and maybe write down some info about this in a 
wiki for future readers.

But then again what's the point, you're (cross)flashing a proprietary 
firmware anyway, just use the tools provided by manufacturer.
-- 
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] OpenBMC & KGPE-D16

[taii...@gmx.com]

On 02/17/2018 09:46 AM, Elisenda Cuadros wrote:


Hi,

Now I trying to use your OpenBMC port.

I followed the instructions and everything was fine (compiling, 
reading and flashing). I waited several minutes after flashing, but 
the module didn 't blinked like in the vendor rom, nor did it receive 
an ip.


I halted the system because I thought maybe it needs a cold start.

After this, the system doesn't boot with the module plugged in. The 
fans begin to spin for approximately 1/4 second, but nothing else.


My two fans (1 cpu & 1 chassis) have 3 pins and are low speed (~1000rpm)

In the case I have to reflash the module, is it possible to hotplug it?

Hotplugging is dangerous and not supported, don't do it.

Thank you very much for your support.
You can use a test clip to externally flash it via a flashing device 
(not sure which can do 16 pins though, I would inquire on the flashrom 
mailinglist)


Are you using the latest coreboot? AFAIK coreboot was patched to support 
OpenBMC, so you need a new version with the patches.


--
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] New user of KGPE-D16

[taii...@gmx.com]

On 02/15/2018 01:22 AM, Elisenda Cuadros wrote:


Hello Taiidan,

I bought it used, but the seller was so kind to send me the module. It 
was a nice surprise.

The rare moral fleabay seller haha.
If you need high quality photos of this module or anything else, 
please don´t hesitate to contact me. I will be happy to help.
Ah thanks, if you can I would love some to upload to the wiki for future 
reference as I don't have a good camera (remember to remove EXIF etc)

My cpu is 6238 not 6328, but thank you for your advise :-) .
I suggest obtaining the faster 6386SE ASAP before they become harder to 
come by (as AMD/ASUS has stopped making all G34/C32 stuff, so stock up 
while you can)


--
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] OpenBMC & KGPE-D16

[Timothy Pearson]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 02/25/2018 02:18 AM, Mike Banon wrote:
>> Any particular reason those patches were not upstreamed?
> 
> Because a person who submitted these patches did not fix some problems,

I'm aware of this.  Upstreaming was never part of the original funding
effort and I haven't had any spare time to try to work on it; been
working on several other projects in what little spare time I have had
over the past year.  If anyone else would like to apply the recommended
cleanups and resubmit I'm fine with that.

- -- 
Timothy Pearson
Raptor Engineering
+1 (415) 727-8645 (direct line)
+1 (512) 690-0200 (switchboard)
https://www.raptorengineering.com
-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQEcBAEBAgAGBQJako8TAAoJEK+E3vEXDOFbtikIALooPL3+eUeog+JWDYy6WmiR
UpzHFR8masKd33ae8+6Sfz3Xh3P0jXvMhVnXPT5QxT1OAMuiOsqRTlp2Tt0ErmJ1
y8FNYVEjBWzWAg8FIJD9IRUlumcVqXRCI2DTDNQJt9ckCtm7mFqaN5oB49TlL0D0
o30+5Gm0kSzXEgC5G9NgiQk/sD06R+l9UDlwJa51ysvl5b5tPMh9eT2jj5kn6uAE
h5BDhruEODJb6E7077wuzKREhZR/gEmUvBmdgUCuPWs2EHZyC6vkAYqIWhjBODtv
dBL5fyPsMnQRua+A+O7suKxt5ieNxx59BOsGwh5XWvubg/Gr7TIDVYDD5lK6Bms=
=tApG
-END PGP SIGNATURE-

-- 
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] OpenBMC & KGPE-D16

[Timothy Pearson]

On 02/27/2018 11:15 PM, taii...@gmx.com wrote:
> On 02/22/2018 04:36 PM, Timothy Pearson wrote:
> 
>> Actually, for OpenBMC work, hotplugging is often the only way to go.
>> Just be very careful to align the pins correctly the first time; you
>> don't have a second chance if you misalign the pins and fry the module...
> I stand corrected, but I am nervous about doing this myself - is it
> possible to use a tester clip?

We have not been able to do so.  There are logic circuits onboard the
firmware module that interfere with direct flashing methods.

> Have you found a source for ASMB4 or ASMB5 modules? Many people I know
> who bought their boards on ebay didn't get one and the D8 unfortunately
> doesn't come with them either. I am going to contact ASUS and see if
> they have a stash.

As with most of the obsolete Opteron hardware, our sources are rapidly
drying up.  We have no source for these modules at this time.

-- 
Timothy Pearson
Raptor Engineering
+1 (415) 727-8645 (direct line)
+1 (512) 690-0200 (switchboard)
https://www.raptorengineering.com

-- 
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] coreboot is going to make kcma-d8 obsolete

[ron minnich]

On Fri, Apr 6, 2018 at 5:45 PM Thierry Laurion <thierry.laur...@gmail.com>
wrote:

> I agree. This is wrong.
> Kgpe-d16 and alike are the last resorts for x86 blob free hardware.
>
> This NEEDS to be kept maintained and upstreamed.
>
>
>
I like the board too. I have one. I have no time to keep it going. I have
not even turned it on in months.

Now that I think about it, my board has an EM100. I can try to automate the
mess if I can remember where the directions are. I also need to work out
remote reset :-) -- any hints on what to buy to make that go?

Realistically, though, if you want blob free, I think you need power9 or
riscv. I've written x86 off for blob free. I'm sad about that, given where
we were in 2000 and where we are today, but there's not much to be done for
it. AMD and Intel just don't see this as a priority :-(

ron
-- 
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] KGPE-D16 / Problem booting with two CPUs

[Timothy Pearson]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

That should work, yes.  It's the very early init code that is getting
confused with the differing core counts, likely related to APIC setup or
similar.

On 04/11/2018 03:26 PM, taii...@gmx.com wrote:
> But it would be possible to have two CPU's with the same core count but
> differing frequencies?
> 
> Thanks
> 


- -- 
Timothy Pearson
Raptor Engineering
+1 (415) 727-8645 (direct line)
+1 (512) 690-0200 (switchboard)
https://www.raptorengineering.com
-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQEcBAEBAgAGBQJaznCJAAoJEK+E3vEXDOFbfqsH+wegvs3Zu2ZNrM+W54LFXB7U
qVv4eAomKhPsf2UY5XzwhxVqzDn81PFI3HbMolfOwhNu/MfYeJIX7uxSdbMFReSH
3DF2808zOVaPQ5GdK3+dtNz7csM9pSTJUAIXPuDmRRYczrbDGEGYIP2OhMku+12x
b8X2iUVRDk0C9s/Rou+p9dEgJiH/xAf47X8L4BHzf8jna2IrY6WJgJiUvK2wxVx+
fahO6au24/yRsNfsdaG7Ax+1GXQF7imlcL7z1zM0JxQjt1OHExjClW/klaNEshjc
Wn+ebc77Blw6+klh7PdSkzs5nIQ3kCIoQuP9KvR0zbiWdmYKzj5NPk2awKAUTbg=
=P/vl
-END PGP SIGNATURE-

-- 
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] Looking for a volunteer to add Fam15h spectre MSR to coreboot

[Arthur Heymans]

Hi

Linux already does that for you: (v4.16) arch/x86/kernel/cpu/amd.c line 869.


Kind regards

On 5 April 2018 00:51:30 GMT+02:00, "taii...@gmx.com" <taii...@gmx.com> wrote:
>As I am not a programmer I do not know how to do this (thanks for the
>heads-up rmarek) nor am I permitted to add to the repos.
>
>MITIGATION G-2                                       
>Description: Set an MSR in the processor so that LFENCE is a dispatch
>serializing instruction and then
>use LFENCE in code streams to serialize dispatch (LFENCE is faster than
>RDTSCP which is also dispatch
>serializing).
>
>This mode of LFENCE may be enabled by setting MSR C001_1029[1]=1.
>
>This is important and covers a variety of boards such as the KGPE-D16,
>KCMA-D8 and G505s (all the last and best owner controlled x86_64
>systems)

-- 
Arthur Heymans-- 
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] OpenBMC & KGPE-D16

[James Hebden]

On Sun, Feb 25, 2018 at 04:25:23AM -0600, Timothy Pearson wrote:
> On 02/25/2018 02:18 AM, Mike Banon wrote:
> >> Any particular reason those patches were not upstreamed?
> > 
> > Because a person who submitted these patches did not fix some problems,
> 
> I'm aware of this.  Upstreaming was never part of the original funding
> effort and I haven't had any spare time to try to work on it; been
> working on several other projects in what little spare time I have had
> over the past year.  If anyone else would like to apply the recommended
> cleanups and resubmit I'm fine with that.

I've taken a swing at pushing a patch to address reviewer comments.
First time submitting to CoreBoot, fingers crossed :)

https://review.coreboot.org/#/c/coreboot/+/19820/

Best,
James


signature.asc
Description: PGP signature
-- 
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot

[coreboot] What happened to the Option ROM options?

[taii...@gmx.com]

Using KGPE-D16 with master.

The choices for them have been messed around with in kconfig sometime ago:

In /src/device/kconfig
ON_DEVICE_ROM_LOAD has for some reason been changed to require VGA_ROM_RUN
which makes no sense to me (maybe someone could need option ROM's
without VGA option ROM's?)
and VGA_ROM_RUN is not available on boards with native (coreboot) init
irregardless so people don't see it even if they require Option ROM's
for whatever reason without SeaBIOS.

Does anyone know where the changelog for this is? and maybe can explain
what the reasoning is behind it? (if it is not a mistake)

Before...I believe last in v4.5 they were shown all the time.

I attempted to find the change in gerrit etc but I was unable to locate it.

Thanks!

-- 
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot

[coreboot] Schematics and PCB design for ASMB4 (Was: There are ASMB5's on fleabay right now for $30/ea (firmware storage module required for OpenBMC on the KGPE-D16/KCMA-D8))

[Daniel Gröber]

Hi,

On Sat, Nov 03, 2018 at 12:10:25AM +0100, Angel Pons wrote:
> Is it me, or is that thing a SPI flash chip on a PCB plus a few
> transistors? It seems like copying the PCB design is rather doable, or am I
> missing something?

Indeed, very doable, but tedious work ;)

Here you go:

https://github.com/DanielG/asmb4
https://oshpark.com/shared_projects/jZLoDQ3Y

I had the schematics lying around on paper for a while now but I was
too lazy to digitize them until now. The design is completely
untested, I just ordered some boards though so we'll see.

FWIW if anyone is interrested in getting some assembled boards I might
do a small production run.

--Daniel


signature.asc
Description: PGP signature
-- 
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] Schematics and PCB design for ASMB4 (Was: There are ASMB5's on fleabay right now for $30/ea (firmware storage module required for OpenBMC on the KGPE-D16/KCMA-D8))

[Timothy Pearson]

On 11/05/2018 03:44 PM, Daniel Gröber wrote:
> On Sun, Nov 04, 2018 at 02:21:10PM -0600, Timothy Pearson wrote:
>> Since Raptor has the ability to allocate official MACs (non-local),
>> which can be useful at the enterprise level via DHCP pinning, I might
>> see if we can reactivate our existing BMC flash offering, but based on
>> your hardware if that's OK with you.  
> 
> Yeah, sure. I'm just making these to scratch my own itch. Didn't think
> there'd be enough demand for you guys to bother producing them though?
> 
> --Daniel

We have some internal demand still; not looking high volume at all but
maybe whip up a few spares while we're at it? :-)

-- 
Timothy Pearson
Raptor Engineering
+1 (415) 727-8645 (direct line)
+1 (512) 690-0200 (switchboard)
https://www.raptorengineering.com

-- 
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] Asus KGPE-D16 with latest coreboot errors with Unsupported Hardware on Qubes 4 install missing IOMMU?

[petecb via coreboot]

Hi Taiidan,

Thanks for your message.


> I am using v4.6 on my system FYI (no reason for me to update) and the
> only options I have changed are the ones I told you about before...all I
> can figure is perhaps I have a different version of the SP5100 that
> doesn't have the erratum or something to that effect.

Is it possible for me to build v4.6 in case something has changed since then 
that causes my issues? When I look at the branches available on git there is no 
4.6 available.

>
> FYI I saw you select build nvramcui as a secondary payload so you can
> mess with cmos options without recompiling as long as next time you shut
> off "Load default configuration values into CMOS on each boot"
>
> Since your menuconfig options look fine...shot in the dark but try using
> grub instead of SeaBIOS as I use grub.
>

I will try building it with Grub. There is an option to include a GRUB2 runtime 
config file into ROM image. Should I select this? If so, what options should be 
in this file?

Kind regards,

Pete


-- 
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] Asus KGPE-D16 with latest coreboot errors with Unsupported Hardware on Qubes 4 install missing IOMMU?

[Angel Pons]

Hello,

On Sun, Dec 2, 2018 at 4:07 PM petecb via coreboot
 wrote:
> Thank you for all those details. I've now compiled a version with the default 
> CMOS settings apart from the following changes
>
> Minimum memory voltage = 1.35v
> experimental_memory_speed_boost enabled
> 1394 controller disabled
> SATA ALPM enabled.

Okay.

> Unfortunately, this results in the Qubes installation on the SSD crashing 
> before it gets to the password prompt and the Qubes installer crashing 
> shortly after booting. They both produce a similar error message that has 
> been too quick to catch so far but mentions "PCI" and "IRQ".

One of the options you selected has the word "experimental" on its
name. I would suspect it may cause issues.

Regards,

Angel Pons

-- 
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] Asus KGPE-D16 with latest coreboot errors with Unsupported Hardware on Qubes 4 install missing IOMMU?

[Nico Huber]

Hi Pete,

On 01.12.18 17:21, petecb via coreboot wrote:
> I'm wondering if my problem is related to not having any SATA drives
> installed? (I just have a PCI-E SSD). It may be the case that the logic
> to disable combined mode is not getting triggered in my scenario, yet it
> would do if there was a SATA drive present.

it's a configuration issue. If you have nvram settings enabled (CONFIG_
USE_OPTION_TABLE), you can enable `sata_ahci_mode` with nvramtool.

No idea why combined mode is the default, it's only useful for OSes from
the '90s. It's not about the type of drives (SATA vs PATA) connected but
how the SATA controller identifies itself to the OS.

Hope that helps,
Nico

-- 
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] Asus KGPE-D16 with latest coreboot errors with Unsupported Hardware on Qubes 4 install missing IOMMU?

[taii...@gmx.com]

On 12/02/2018 05:30 PM, Nico Huber wrote:
> Hi Pete,
> 
> On 02.12.18 23:13, petecb via coreboot wrote:
>> As the default SATA setting already appeared correct, I modified the 3
>> additional settings that Taiidan had already indicated worked
>> (memory_speed_boost, 1394 controller and SATA ALPM) so in my mind I was
>> only adjusting one additional setting, the memory voltage. I thought
>> this was fairly sensible as my RAM is definitely 1.35V.
> 
> did you have CONFIG_USE_OPTION_TABLE before? If not you potentially have
> changed all settings. The defaults in the cmos.default file don't have
> to be the same defaults that are hardcoded in the code and the file only
> takes effect if CONFIG_USE_OPTION_TABLE is set. As I looked at the SATA
> code, I know the AHCI setting is one that definitely differs.

I would also use nvramcui to verify that settings have actually been
changed anyways.

-- 
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot

[coreboot] Re: Does NSA contribute to Coreboot?

[ron minnich]

Thanks for clearing that up 

On Mon, Jun 24, 2019, 11:16 AM Hubert Ruch  wrote:

>
>
> On 6/24/19 10:17 PM, ron minnich wrote:
> > On Mon, Jun 24, 2019 at 7:20 AM Hubert Ruch  wrote:
> >> Thanks for the info. Didn't know that. Now, one has to wonder how many
> skilled developers actually do read and understand their code. IIRC Leah
> Rowe paid someone $90.000 for adding some code to LibreBoot. I'm mentioning
> this because it leads to the assumption that boot coding must be a pretty
> difficult task.
> > Speculation preceded by IIRC is not helpful. Lots of people read this
> > list and you can now expect to see your IIRC bounce around the world
> > as fact, and we have no idea if it's true or not.
> Here's the source. Leah Rove writes that she "paid 90,000 USD to Raptor
> Engineering to port the ASUS KGPE-D16 and KCMA-D8 to Libreboot".
> https://libreboot.org/news/leah-fundraiser.html
> ___
> 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: Does NSA contribute to Coreboot?

[Hubert Ruch]

On 6/24/19 10:17 PM, ron minnich wrote:

On Mon, Jun 24, 2019 at 7:20 AM Hubert Ruch  wrote:

Thanks for the info. Didn't know that. Now, one has to wonder how many skilled 
developers actually do read and understand their code. IIRC Leah Rowe paid 
someone $90.000 for adding some code to LibreBoot. I'm mentioning this because 
it leads to the assumption that boot coding must be a pretty difficult task.

Speculation preceded by IIRC is not helpful. Lots of people read this
list and you can now expect to see your IIRC bounce around the world
as fact, and we have no idea if it's true or not.
Here's the source. Leah Rove writes that she "paid 90,000 USD to Raptor 
Engineering to port the ASUS KGPE-D16 and KCMA-D8 to Libreboot".

https://libreboot.org/news/leah-fundraiser.html
___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] Fwd: Re: Kernel Panics on corebooted systems with linux 4.19 ( >4.9)

[Kinky Nekoboi]

 Weitergeleitete Nachricht 
Betreff:Re: [coreboot] Re: Kernel Panics on corebooted systems with
linux 4.19 ( >4.9)
Datum:  Tue, 9 Jul 2019 12:04:33 +0200
Von:Kinky Nekoboi 
An: Felix Held 
Kopie (CC): u...@localhost.com



Vendor firmware i did not, and i guess cannot anymore test.

Tested in my case (KGPE-D16) with libreboot (coreboot 4.6) with and
without microcode.Same behaviour.

kernel 4.9 works flawless btw

Am 09.07.19 um 12:02 schrieb Felix Held:
> Hi!
>
>> Tested it both with microcode and without microcode. It doesent changes
>> the behaviour.
>
> Uh, that's indeed not good then. Have you tried if this also happens
> with older coreboot versions or when running under the vendor firmware?
>
> Regards
> Felix
>


___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] Re: AMD AGESA maintenance and/or deprecation

[Nico Huber]

On 12.09.19 18:42, Patrick Georgi wrote:
> On Thu, Sep 12, 2019 at 07:20:49PM +0300, Kyösti Mälkki wrote:
>> Would "some people" or these "advocates" be willing to elaborate?
> I CC'd Nico and Martin because I seem to remember that we talked
> about AGESA (and its quality and/or life cycle). Nico, for example,
> seems to advocate scrapping AGESA to replace it with a rewrite ;-)

Ah, yes. I might have said something. When talking about AGESA ports,
I most probably meant the hook-up in coreboot, not the vendorcode/.
I usually don't look at the latter.

I would love to see a clean rewrite and assume that I proposed this
when somebody asked what could/should be done. However, I don't see
it as a requirement. Also, we have much more worrisome code in the
tree (e.g. KGPE-D16 and surrounding code, suffering from undefined
behavior, #including of .c files etc.).

Nico
___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] Re: Intel Atom C2000 SOC - Do they lack Intel ME?

[Goetz Salzmann]

Hi Kinky,

> i sadly had to replace KGPE-d16 board for my fileserver to a Supermicro  
> A1SRi-C2558 because of electric pill 
>
> investigating a bit with intelmetool and mecleaner non of them could  
> found any sign for an ME-region in this board.. so i asking myself if  
> there is no ME/SPS on the intel C2000 socs, what would make them a DAMN  
> SEXY platform to port coreboot too.

to answer your other question: yes the Intel Rangeley (C2000) is the
last/newest SoC what does not include a ME(like) subsystem.

Unfortunately the SoC has a fatal hardware bug: 

https://www.extremetech.com/computing/244074-intel-atom-c2000-bug-killing-products-multiple-manufacturers

But this hardware bug has resurfaced on some of the later ATOMs aswell.

There is a Golden Master Image for coreboot from intel, but it's
probably not publicaly available, OTOH if you want to work on Rangely,
there should be someone on this list, that can arange for you to get
this "drop".

Another pointer:
https://mail.coreboot.org/pipermail/coreboot/2017-March/083712.html

Cu,
Goetz.


___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] Re: Coreboot computer doesn't boot with 2 CPU

[Lance Zhao]

What's the does not boot point to? Stuck in POST with some serial log, or
not even CPU is running.

d.verdi via coreboot  于2020年11月24日周二 上午6:49写道：

> Hi to all,
> I had this problem: when I start the computer with 1 cpu (opteron 6282se)
> everything is fine, if I add the second CPU, the computer doesn't boot, did
> you have any suggestions? I put only 2 rams module, following the Asus kgpe
> d16 manual, is that the correct order (one in the first and one in the last
> orange socket)?
>
> Thank you very much
> Dave
> ___
> 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] Debian doesn't boot after firewire card insertion

[d.verdi via coreboot]

Hello,
recently I add to my asus kgpe d16 a pci-e to firewire card adapter, a sunix 
FWB3400T; after that, my Debian distro previously installed doesn't boot 
anymore, it boot partially but at one point it show "hdaudio no AFG or MFG node 
found" and then the PC restart itself.
I have also installed a Fedora 33, which starts without problem, so does anyone 
have some suggestion to make Debian boot again?

The configuration is this sunix adapter, another sunix to parallel adapter 
(PAR6408A) and an nvidia quadro P2000 as graphic card; 2 opteron 6282SE and 96 
Gb ram of hynix ECC registered memory ( btw, I tried with 128 gb but machine 
doesn't starts).

Thanks a lot
Dav

Sent with [ProtonMail](https://protonmail.com) Secure Email.___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

Re: [coreboot] Install Coreboot into KGPE-D16 (Cloud Dai)

[taii...@gmx.com]

On 03/11/2018 08:06 AM, Jason Lenz wrote:


I viewed your blog post and it sounds like you are using the stock bios to 
confirm the board works properly before flashing coreboot.  I believe the 
problem is that your power supply itself does not have enough capacity.  I have 
experienced the problem myself when I first tested my KGPE board.  The 
motherboard draws a lot of current initially at start up and my first power 
supply had an internal protection circuit that would activate and stop it due 
to overload drawing too much current.  Once I upgraded to a higher capacity 
power supply everything worked fine.  I bought a 1000w power supply which was 
probably more than needed, but with this power supply the motherboard started 
up fine.  Can you borrow a larger capacity power supply from a friend to test 
it?  Best of luck to you.  I also had no problem understanding your English.

Ah thank you I did not read the blog post myself.

Yeah you need a quality PSU with one EPS12V connection per CPU, I am 
able to run my single CPU system with a 550W PSU but it is very high 
quality - cheap PSU's are usually over-rated.


--
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] Install Coreboot into KGPE-D16 (Cloud Dai)

[Elisenda Cuadros]

Hello,

I'm using and old Thermaltake 430W PSU, single CPU + dedicated graphics 
card.


No problems at the moment.

Regards,

- Eli


On 11/03/18 20:25, taii...@gmx.com wrote:

On 03/11/2018 08:06 AM, Jason Lenz wrote:

I viewed your blog post and it sounds like you are using the stock 
bios to confirm the board works properly before flashing coreboot.  I 
believe the problem is that your power supply itself does not have 
enough capacity.  I have experienced the problem myself when I first 
tested my KGPE board.  The motherboard draws a lot of current 
initially at start up and my first power supply had an internal 
protection circuit that would activate and stop it due to overload 
drawing too much current.  Once I upgraded to a higher capacity power 
supply everything worked fine.  I bought a 1000w power supply which 
was probably more than needed, but with this power supply the 
motherboard started up fine.  Can you borrow a larger capacity power 
supply from a friend to test it?  Best of luck to you.  I also had no 
problem understanding your English.

Ah thank you I did not read the blog post myself.

Yeah you need a quality PSU with one EPS12V connection per CPU, I am 
able to run my single CPU system with a 550W PSU but it is very high 
quality - cheap PSU's are usually over-rated.





--
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] KGPE-D16 SR-IOV problems (iommu groups) - Anyone else tried this?

[taii...@gmx.com]

On 01/23/2017 09:23 AM, Timothy Pearson wrote:


-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 01/21/2017 02:57 AM, taii...@gmx.com wrote:

It seems the PCI-e root ports on the KGPE-D16 have ARI which is needed
for SR-IOV, however it is not reported via # lspci -vv
I assume that is why the VF's are not assigned to IOMMU groups and thus
can't be assigned.

I am running coreboot v4.5 (I forgot to note this as it is another late
night)

Tim was the ARI feature implemented when you guys did the programming?
https://support.amd.com/TechDocs/44549.pdf

We did not explicitly enable nor verify the ARI feature as we did not
need it for our internal machines.  As always, this is something that we
could definitely work on under contract, and I am always happy to review
patches on Gerrit if you choose to tackle this on your own!

- -- 
Timothy Pearson

Raptor Engineering
+1 (415) 727-8645 (direct line)
+1 (512) 690-0200 (switchboard)
https://www.raptorengineering.com
-BEGIN PGP SIGNATURE-
Version: GnuPG v1
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQEcBAEBAgAGBQJYhhHzAAoJEK+E3vEXDOFbwP0IAIbCI5HLMEYNmDOeYyO/IYQT
eVFMs+Bd2Q9bJA+x6e0D8MXL6LQzCOjxcg8qbeS4UuI6Kq6HszHqmKKH6rusmPqD
Ew2DCffmoQnvsshmL/YvqPSL1SZhYWjjNCdUrBNCAvJAZLEh9Tef4eKpVp9aHjt4
WBvrttU7uFyTf5zbWAPsOFfe2aQ0TNGlCgl+EOqJQWeIaHw+8gu6MPDOIc7aorJ/
2wC6ReI9iybAAlI0ZfYvsYFtuypqmJEOYmC/9uaU8xYtKOvrNumRPeJw1gB/m1yD
Z1joJMC9WQ/1b9+L9D9wRnhFrYp00e5GVZYXWbSM31v81zjg+GKThsAZYwpTnO4=
=haoQ
-END PGP SIGNATURE-

TY for info.

I finally found some real info on ARI.
https://us-east.manta.joyent.com/jmc/public/opensolaris/ARChive/FWARC/2010/063/Materials/ari-support.txt
Apparently SR-IOV doesn't actually require it, it is only needed for 
more than 8 total functions per device.
I will continue troubleshooting and get back to you, SR-IOV is an 
important feature for today's modern servers so I will try to figure it out.


I would DIY but hardware engineering is currently above my paygrade, but 
when I get a job I am definitely going to do some bankrollin'


--
coreboot mailing list: coreboot@coreboot.org
https://www.coreboot.org/mailman/listinfo/coreboot

[coreboot] KGPE-D16: More insights on the PCI hang failure

[Daniel Kulesz via coreboot]

Hi folks,

as we know, the KGPE-D16 is likely to hang during PCI init, especially if the 
serial console is enabled (Timothy mentioned that he did not observe failures 
with the debug level of the console lowered - however, for me this did not 
work). Typical symptoms look like the following:

ERROR: PNP: 002e.b 70 irq size: 0x01 not assigned

After discussing the issue with Timothy and doing a (huge) number of 
experiments in different settings I am of the opinion that the issue *does* 
seem to be memory/clock related. I tried various memory configurations and 
found some interesting correlations between memory configuration and the rate 
of failures. Also, I found another trigger which makes the hang *much* more 
likely.

For testing, I used the current coreboot master with the proposed revert which 
made the MC4 errors go away. After some experimenting, I found two settings 
which made the PCI-hangs go away:

1. Setting minimum memory voltage to 1.5V (probably unrelated)
2. Setting maximum memory clock down to 400 MHz (DDR3-800 instead of DDR3-1600)

With this setting, the number of PCI hangs went considerably down on a number 
of different configurations (all using two Opteron 6276 CPUs). The numbers are 
(#hangs / #boot attempts):

1xCK0 (in slot A2): warm (0/8), cold (0/3) => no failures!
1xYK0 (in slot A2): warm (0/6), cold (0/3) => no failures!
8xYK0 (in all orange slots): warm (1/8), cold (1/5) => rare
16xYK0 (in all slots): warm (3/8), cold (1/5) => more likely

Specs of the memory modules (all from Samsung):

CK0: 8GB DDR3-1600, 1.5V
YK0: 8GB DDR3L-1600, 1.35V

However, there is one more and quite severe issue: If I set the following 
option, I am get a hang in like 70% of the boot attempts:

Chipset => Enable PCI-E MMCONFIG Support

I wouldn't care too much about leaving this disabled. Unfortunately, I am 
getting a "force reboot" of the Kernel each time it tries to initialize the 
nouveau driver. Not sure if this is really related to this option or the fact 
that I'm running the RDIMMs at such low settings, but we'll have to find out.

Cheers, Daniel

-- 
coreboot mailing list: coreboot@coreboot.org
https://www.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] KGPE-D16 and Samsung DDR3L memory sticks

[Paul Menzel via coreboot]

Dear Daniel,


Thank you for keeping us in the loop.


Am Samstag, den 11.02.2017, 16:14 +0100 schrieb Daniel Kulesz:
> To answer my question myself: It works partially.
> 
> > 1.) Samsung M393B1K70DH0-YK0
> > 
> > Type: DDR3 DIMM 240-Pin, reg ECC • Ranks/Banks: dual rank, x4 • Modules: 1x 
> > 8GB • JEDEC: PC3L-12800R • Voltage: 1.35V
> 
> I got 8 of these working with one CPU package on the KGPE-D16 with
> one of the latest Coreboot master versions:

(Please note, that coreboot is officially spelled all lowercase.)

How much did you pay for these modules?

Just to be sure. You got 64 GB of RAM working. If you plug in more
modules, it fails, right?

> Version: 4.5-963-gf57a768

Please upload your logs to the board status repository. (This commit
has not been uploaded by REACTS, so it wouldn’t overwrite anything.)

> However, the experience was not very good because I did not fit all
> of them at once and started with testing "partical" configurations
> with just two or four modules inserted. In these cases, raminit
> succeeded but when detecting the PCI devices the system hang up -
> especially when placing 4 modules in the orange slots. Also, with
> coreboot-4.5, I only managed to get four modules working when placing
> them in the slots most far away from CPU0 (two orange, two black).
> 
> Apart from that, the configured clock speed seems too low to me (the
> vendor bios runs the modules at 800 MHz instead of 667 MHz):
> 
> Handle 0x0007, DMI type 17, 40 bytes
> Memory Device
> Array Handle: 0x0006
> Error Information Handle: Not Provided
> Total Width: 72 bits
> Data Width: 64 bits
> Size: 8192 MB
> Form Factor: DIMM
> Set: None
> Locator: NODE 0 DIMM_A1
> Bank Locator: Not Specified
> Type: DDR3
> Type Detail: Synchronous Registered (Buffered)
> Speed: 667 MHz
> Manufacturer: Samsung
> Serial Number: xxx
> Asset Tag: Not Specified
> Part Number: M393B1K70DH0-YK0  
> Rank: 2
> Configured Clock Speed: 667 MHz
> Minimum Voltage: 1.35 V
> Maximum Voltage: 1.5 V
> Configured Voltage: 1.35 V

Without the logs, it’s hard to debug anything. Verbose logs are one of
the biggest advantages of coreboot. So please upload them, or attach
them.


Thanks,

Paul

signature.asc
Description: This is a digitally signed message part
-- 
coreboot mailing list: coreboot@coreboot.org
https://www.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] Fund a TALOS Secure Workstation as coreboot build system

[Merlin Büge]

On Tue, 17 Jan 2017 14:24:16 -0600
Timothy Pearson <tpear...@raptorengineering.com> wrote:



> Regarding the BMC work, we're looking to enable a fully libre BMC on
> the KGPE-D16.  This is a complex process involving significant reverse
> engineering efforts, writing new kernel drivers for the BMC, etc.
> With the BMC enabled, proper fan control can be established on the
> KGPE-D16, in addition to remote console access and of course remote
> power on / power off / reset functionality.
> 
> If this work can be funded, Raptor would chip in a matching amount to
> lower the costs to the community; essentially we're looking to fund
> half of the work internally but cannot justify the full cost of the
> work as the sole sponsor.  Every little bit helps, so even if you can
> only chip in $100 please consider doing so.

Do you think running a crowdfunding campaign again would help getting
this funded / collecting donations? I don't know if you have to pay any
fees for the various platforms out there, but I bet there are some for
which you don't have to pay much.

I'm not thinking of a campaign like the Talos one, I just think it
would be useful to keep track on how many people already donated, and
how much is still missing to meet the goal. With 'useful' I
mean it'd probably boost donations, in contrast to accepting donations
quietly. So no big updates etc., just using their infrastructure for
collecting donations. But after all, I've no idea about R etc. :P

If this is not too straight forward, may I ask of how much of
community support you are thinking?


Thank you,

Merlin


> 
> Thanks!
> 
> - -- 
> Timothy Pearson
> Raptor Engineering
> +1 (415) 727-8645 (direct line)
> +1 (512) 690-0200 (switchboard)
> https://www.raptorengineering.com
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v1
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
> 
> iQEcBAEBAgAGBQJYfn1uAAoJEK+E3vEXDOFbTV4H+QHqUiszRRI7kp5Qd0p/uI7G
> tOyL32CzMrUqekDj+A/V1gC5lYtQbjN6WzcMrBFQ9lvJrQy/GxFoRn0cHaZtteya
> MmqugPSGotjARM2quWCkbIdhNGgyzKWr+BHwpImH9SyiJ0nozl4RDGDfqhqdPI3+
> 7nt4TAc54Kq9yhUlP9XLpYq6Gi67sYt0qgVXyNhekiT4a7HrG+0aLtu8mzOVMktc
> /oIqnhHlZQnX6LDvNkKJkifanrjL5NXigEEB/iwaFW56Pm9avs07pQeU0wnJjL4G
> pcNKQ7/4j2opEn//bBqofU3u60thdbxb16O3aBcAJTkUDFtNjeX0VNPNb56/5HQ=
> =uc5x
> -END PGP SIGNATURE-
> 
> -- 
> coreboot mailing list: coreboot@coreboot.org
> https://www.coreboot.org/mailman/listinfo/coreboot


-- 
Merlin Büge <t...@bluenox07.de>

-- 
coreboot mailing list: coreboot@coreboot.org
https://www.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] Proposal: "Freedom level" field for boards supported by coreboot

[taii...@gmx.com]

On 01/19/2017 06:16 PM, Andrés Domínguez wrote:


2017-01-18 23:39 GMT+01:00 Timothy Pearson <tpear...@raptorengineering.com>:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

All,

I've been working on a new way to classify boards supported by coreboot
based on their freedom level.

Very good idea.


I uploaded the classification criteria to
the Wiki here

https://www.coreboot.org/Board_freedom_levels

There are a few things that I don't like about your categories,
specially the "scary red Pwned": Don't you think that people reading
the coreboot web page, will think that the "Pwned" are worse than
buying any random board not supported by coreboot, with the same
freedom issues? I would use not colored not named for the last
category. Gold, Silver and Bronze sound good to me, you could always
add Platinum and Iridium if more free boards appear and + or - for
every category that needs subcategories.

I also agree with Julius about the ARM platforms that have not
supported GPU or WIFI. For many use cases GPU is not needed, and WIFI
can be replaced by PCIe or USB one.

Andrés
FSP coreboot isn't the real thing, it is almost absolutely pointless as 
it doesn't really do anything at all - we shouldn't entertain the purism 
idiots who support that.



x86 is dead, in a year or so you won't be able to find any new non 
FSP/ME/PSP type motherboards so we will be reduced to buying overpriced 
used boards from ebay (kgpe-d16 - get em new while you can boys)


At this point the only realistic option is a campaign to make libre one 
of the more affordable POWER8 systems, eventually they will come down in 
price and it'll be affordable (in 2012 a brand new kgpe d16 plus new cpu 
ram etc would be just as much as a lower end POWER8 is now)


Unfortunate despite all the linux sysadmin's who are making 100K+ per 
year the authentic "hacker" culture[1] is nearly dead so nobody really 
cares about free firmware enough to cough up real money for to make it a 
reality, which is why TALOS failed.


[1] people who work for facebook, google or another web 2.0 trendster 
company and who call themselves a "hacker" don't fall in to this category.


--
coreboot mailing list: coreboot@coreboot.org
https://www.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] weird problem with KGPE-D16

[ron minnich]

I did a bit more digging. With this change, the trampoline code changed
too.

I have no idea why linux payloads work for anyone past this ref. It may
just be you get the right config options and get lucky.

The bigger problem is lots of us took the bzimage format as constant, in
some sense, and it's clearly possible for it to change in ways that break
coreboot (and u-boot, in this case, and an arm chromebook as you can see
from the discussion).

good times.

tpearson and Tram, are you running with CONFIG_RELOCATABLE? I expect Tram
has to be, since he uses kexec. tpearson? Because the coreboot trampoline
makes assumptions that don't work with CONFIG_RELOCATABLE AFAICT.

Overall, a problem I see is that the coreboot trampoline code is built with
the assumption that a trampoline can function apart from the kernel, i.e.
that there is indepedence. I don't believe that is true any more.

See this in newer 4.x linuxes:
#ifdef CONFIG_RELOCATABLE

i.e. the trampoline code is now parameterized by the configuration. Our
trampoline assumes the kernel starts at 0x10.

I think the fix will be to remove the coreboot trampolilne code for bzimage
and extract the needed trampoline code from the bzimage. I'll try that.


ron

On Tue, Sep 13, 2016 at 4:43 PM ron minnich <rminn...@gmail.com> wrote:

> I've been trying to find a problem in linux that makes it not boot when
> used as the payload in the KGPE-D16. The symptom is that I get no output at
> all on serial when linux starts.
>
> I finally got it down to 1 commit today in linux.
>
> commit 974f221c84b05b1dc2f5ea50dc16d2a9d1e95eda
> Author: Yinghai Lu <ying...@kernel.org>
> Date:   Thu Apr 28 17:09:04 2016 -0700
>
> x86/boot: Move compressed kernel to the end of the decompression buffer
>
> If I build a linux kernel up to but not including this commit, all is
> well. If I build with this commit, Linux is silent -- no serial output.
>
> Anyway, I will be looking at this, but if you have solved it let me know.
>
> thanks
>
> ron
>
-- 
coreboot mailing list: coreboot@coreboot.org
https://www.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] PCI passthrough on ASUS KGPE-D16

[taii...@gmx.com]

I would really love to find a legit answer Re: what chipsets/mobos 
support gfx i/o fwd before I splash out hundreds of dollars.



AFIAK forwarding graphics devices requires a lot more special sauce than 
regular pci devices (like network interfaces)


On my propitiatory-firmware intel laptop dmesg says
"DMAR: BIOS has allocated no shadow GTT; disabling IOMMU for graphics"
So apparently you need a shadow gart for it to work, something that is 
above my paygrade.


It would be really great if there was an IOMMU/GFX bit on the coreboot 
supported motherboards page as this is a common question that never 
finds anything more than anecdotal evidence. I am grateful for your help 
mike but running grep commands on the source files provides nothing more 
than just that.


On 10/03/2016 07:09 PM, Mike Banon wrote:

Correct me if I am wrong, but I think: IOMMU support means that a
graphics card passthrough is possible (this is binary: IOMMU yes ==>
possible / no ==> not possible). If IOMMU support is buggy (which
seems to be commonly found with proprietary BIOS) maybe your system
could experience some bugs while you are using this feature. Of course
the most reliable way to find out is to try it, but I am pretty sure
that coreboot's IOMMU support is good

On Sun, Oct 2, 2016 at 9:04 PM, Zoran Stojsavljevic
<zoran.stojsavlje...@gmail.com> wrote:

Would it be possible to passthrough a graphics card to a virtual machine
while using Coreboot/Libreboot?

Hello opteron/AMD supporter,

You did ask very (very, should say extremely) tricky question, you do know
this (I betcha you do, don't you)??? ;-)

Zoran
___

On Sun, Oct 2, 2016 at 6:22 PM, <opte...@keemail.me> wrote:

Hi,

would it be possible to passthrough a graphics card to a virtual machine
while using Coreboot/Libreboot? The libreboot website says that the
motherboard offers full IOMMU-support when using a CPU from the Opteron
6200/6300 series.

https://wiki.archlinux.org/index.php/PCI_passthrough_via_OVMF
https://libreboot.org/docs/hcl/kgpe-d16.html

--
coreboot mailing list: coreboot@coreboot.org
https://www.coreboot.org/mailman/listinfo/coreboot



--
coreboot mailing list: coreboot@coreboot.org
https://www.coreboot.org/mailman/listinfo/coreboot



--
coreboot mailing list: coreboot@coreboot.org
https://www.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] DMA protection? [AMD-Vi]

[Timothy Pearson]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 11/15/2016 03:35 PM, taii...@gmx.com wrote:
> I have KGPE-d16 with IOMMU/AMD-VI and I was wondering if it would be
> possible to designate in coreboot certain devices pass-through only to
> stop them from communicating with the host? If I have to launch a rescue
> CD or what not then a rogue infected device could do a DMA attack correct?
>
> On linux does iommu only isolate from the host devices assigned to a
> guest? assigned to pcistub? or is there always some level of mediation?
> My system says "dom0 mode - relaxed" right below the AMDVI messages,
> what does it mean?
>
> Thanks for any replies!
>
>

Coreboot does not currently configure the IOMMU to reject unauthorized
access; it waits for Linux to start and configure the IOMMU.  By
default, Linux configures the IOMMU (if present) to only accept access
to authorised areas of memory*, therefore once Linux starts exploiting
the system via PCI becomes very difficult.  If you have passed any
options to Linux regarding the IOMMU (e.g. iommu=soft or iommu=pt), the
system may have lost this protection, so be careful!

It might be an interesting experiment to configure the IOMMU from within
coreboot in order to close the small window where a malicious PCI device
could attack the host.  This is something we'd be willing to consider
under contract if there's interest.

I hope this helps!

* Both Raptor and other KGPE-D16 users have seen this in action with
rogue cards -- in particular, one USB 3 card with firmware blobs
attempted to scan host memory.  When a peripheral misbehaves in this
manner, you will see messages similar to:

"AMD-Vi: Event logged [IO_PAGE_FAULT device=00.00.0 domain=0x
address=0x flags=0x]"

Each one of those is a peripheral access to main memory that has been
blocked by the IOMMU.  If you see a lot of these, especially if they
continue to be generated after bootup, you probably have a buggy or
malicious PCI device installed.

- -- 
Timothy Pearson
Raptor Engineering
+1 (415) 727-8645 (direct line)
+1 (512) 690-0200 (switchboard)
https://www.raptorengineering.com
-BEGIN PGP SIGNATURE-
Version: GnuPG v1
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQEcBAEBAgAGBQJYLLE/AAoJEK+E3vEXDOFbYV4H/RPmG3dXHQMWGVevchuSjP9r
3Xsvr+KTvIzypR0rxtj8WM9qvoHARBgCmIaNgIdvVqdtxPK5YELU8tFZw1KiUotg
sJ5WXNgBHCygR8O3L5i3BhnqztLYlK50Oq2+uj2jG0VoIZeXUALZS1YNno2h4RrW
ot9WRaQR9XWKOf87CpDWyqu+qty/qjsL3Rnx9XaBNzsgcJsP/JPcXLk3jbOgFRVZ
WS3K2/PQrT/B34aicBDXI9QwCpPdwi/RWUToQGBAIqG4Y/ZTfcpFtQrmrMOl6bG0
KAn9SIugIkHKbX394d+uYKJUJQIuSljP8NiyalHfT3gTG6psdiZnC2EeZfj/Ypw=
=aHep
-END PGP SIGNATURE-

-- 
coreboot mailing list: coreboot@coreboot.org
https://www.coreboot.org/mailman/listinfo/coreboot