Hi All,
Variants can be used for mainboards. The variants are used for boards within the same mainboard manufacturer directory.
Computer-On-Module (COM) can be used on different carriers which do not have same manufacturer.
Proposal is creating a COM directory 'src/com' where the module manufacturer and module name are used. (Similar to mainboard).
In this src/com directory common module support is placed.
mainboard will use this COM module and contains the 'variant' code.
What's the opinion on this suggestion?
Met vriendelijke groet / Best regards,
Frans Hendriks
Eltan B.V.
www.eltan.com
-------- 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 <kinky_nekoboi(a)nekoboi.moe>
An: Felix Held <felix-coreboot(a)felixheld.de>
Kopie (CC): user(a)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
>
Addional info:
linux 4.19 works flawless on corebooted F2A85m, thinkpad x220, w520,
x60, t60, apu2
Am 09.07.19 um 12:04 schrieb Kinky Nekoboi:
> 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
>>
Hi all!
In the commit https://review.coreboot.org/c/coreboot/+/33565, I tried to rewrite
the PCH GPIOs configuration using macros instead of raw values of the DW0 and DW1
registers.
However, macros from src/soc/intel/common/block/include/intelblocks/gpio_defs.h
can't determine the setting for each pads.
1) Why do the standard macros (like PAD_CFG_NF, PAD_CFG_GPO, ...) set RX Level/Edge
Configuration (RXEVCFG bit[26:25] DW0 register) to 0?
From Doc(1) RXEVCFG = 0 -> "determines if the internal RX pad state should be
passed on to the next logic stage as is, as level signal". Is this correct if
the pad is used as a functional output, PAD_CFG_NF()?
At the same time, after resetting, by default, the RXEVCFG field is set to 2h =
Drive '0'. If I understood correctly, this means that the pad state will not be
transmitted to the next logic block and the interrupt controller will not receive
signal from the pad. Maybe this setting will be better for PAD_CFG_NF() or
PAD_CFG_GPO()? See https://review.coreboot.org/c/coreboot/+/34144
[1] p1429, Intel 100/C230 Series Chipset Family PCH Volume 2 (February 2019)
2) The macros PAD_CFG_NF() and PAD_CFG_GPO() are defined correctly.
In this case, I mast to add new macros, how this is done in commit
https://review.coreboot.org/c/coreboot/+/33565.
I think adding new macros with strange names isn't the best way. But only in
this case, I can set the GPIOs configuration, which fully corresponds to the
inteltool log. On the other hand, if I ignore the PAD_CFG0_TRIG_OFF setting (set
RX Level/Edge Configuration (RXEVCFG) to 0 = Level), then I need only 2 macros:
PAD_CFG_NF_TX_DIS and PAD_CFG_NF_RX_DIS.
All Chromebooks install RXEVCFG to 0 and it works.
The motherboard works well in both cases.
I would like to get your opinion on this. So, maybe I should ignore Drive '0' setting
for Level/Edge Configuration (bit[26:25] DW0 register) and use standard macros?
Information about GPIOs was obtained from the inteltool log.
My motherboard is asrock-h110m-dvs with Intel Skylake/Kaby Lake CPU.
Thanks!
--
Regards,
Maxim Polyakov
Software Engineer, YADRO.
If you have the source code to build a binaryPI, I think you can `cd
binarypi/stoney-pi/AmdAgesaPkg && make Agesa_B2_Target`. I've never
tried it though.
On Wed, Jul 3, 2019 at 4:58 AM Jorge Fernandez Monteagudo
<jorgefm(a)cirsa.com> wrote:
>
> Hi again,
>
> A clarification. From the StoneyPI_1_3_0_A.ZIP file I've got under NDA is it possible to compile it and get the AGESA.bin file?
> For instance, for the fam15tn family the coreboot build process generates a libagesa.fam15tn.a file which is integrated in the
> final coreboot.rom file. Could it be possible to do the same from a PI family? The build process in coreboot is only prepared to
> use a wrapper and the AGESA.bin file, but maybe is it possible to generate the AGESA.bin from the zip file...
>
> Thanks!
>
> ________________________________
> De: Jorge Fernandez Monteagudo <jorgefm(a)cirsa.com>
> Enviado: martes, 2 de julio de 2019 14:25
> Para: Kyösti Mälkki
> Cc: coreboot(a)coreboot.org
> Asunto: [coreboot] Re: Question about blobs
>
> Hi Kyösti! Thanks for the info!
>
> >AMD contracted SilverBack for the tasks on StoneyRidge (and
> >MerlinFalcon apparently). The source is a heavily modified StoneyPI
> >package. You may get the unmodified one from AMD reps under NDA. Or
> >pay SilverBack for the development you would be more capable of doing
> >yourself, and you still might not get a license that allows
> >distributing the work. There was a promise of scrubbing and
> >relicensing StoneyPI source but... Let's just say legalities messed it
> >up, I don't have the details.
>
> Yes, the AMD reps we're in touch answer me to get in touch with SilverBack to get support :(
> We've been able to get a more recent StoneyPI_1_3_0_A.ZIP under NDA because I've seen
> this version fixed the issue:
>
> EMBSWDEV-4487: System is not booting when memory is connected only to DIMM 1 slot
>
> maybe related with our problem, but I don't know how to integrate this code into coreboot...
> And if you say that the current work in coreboot is from a heavily modified base from SilverBack
> I don't have any chance to make it work...
>
> >As for the the other blobs (MullinsPI, CarrizoPI, KaveriPI), those
> >were either built at SAGE (R.I.P.) or AMD AES (R.I.P.) and I have been
> >told the repositories and toolchains were never officially transferred
> >to SilverBack's possession. In other words, even if you paid,
> >SilverBack is not likely to work on those.
>
> Then, no more options to get a working BIOS than SilverBack?
>
> >I believe we have talked before. Maybe it was about CarrizoPI? I was
> >asking for commercial adopters around coreboot and binaryPI, in
> >attempts to get to the same negotiation table with AMD management. Did
> >You or Your manager ever respond?
>
> Yes. I began asking in the coreboot mailing list about the Bettong mainboard. I added TPM support
> and tianocore to that demoboard. I remember the email and I answered it giving my support because
> we thought coreboot is the way to go to support our custom board.
>
> Regards,
> Jorge
>
> _______________________________________________
> coreboot mailing list -- coreboot(a)coreboot.org
> To unsubscribe send an email to coreboot-leave(a)coreboot.org
I am using a PCEngines APU2 system and I noticed that its HPET timers do not
advertise FSB (MSI) interrupt delivery capability.
That is despite the fact that BKDG for family 16h models 30h - 3Fh says that
those capability bits are hardwired to 1.
I took a quick look through coreboot sources (APU2 firmware is coreboot) and
noticed something interesting. It seems that the repository includes code for
AGESA (src/vendorcode/amd/agesa) and there I see that the MSI capability can be
turned on / off via a special PM I/O register. It appears that HPET MSI support
is disabled on some platforms by default:
src/vendorcode/amd/agesa/f15tn/Proc/Fch/Interface/Family/Hudson2/EnvDefHudson2.c:
TRUE, // HpetMsiDis
src/vendorcode/amd/agesa/f16kb/Proc/Fch/Interface/Family/Yangtze/EnvDefYangtze.c:
TRUE, // HpetMsiDis
Does anyone know what is a reason for that?
Are there any hardware errata related to that feature?
I think that MSI delivery is more efficient and "sexy" than the traditional
delivery via IO-APIC (although everything is integrated).
Also, is there a way to override that default in a mainboard configuration?
Thank you.
--
Andriy Gapon
That's Denverton? If the selection is not part of fspupd file
https://github.com/IntelFsp/FSP/tree/master/DenvertonNSFspBinPkg/Include,
then probably they only have default setting. We can't enable/disable those
option through FSP didn't mean those feature is not available.
Lance
Ashmita Chakraborty <Ashmita.Chakraborty(a)ltts.com> 于2019年7月3日周三 上午2:10写道：
> Hi Ranga,
>
> Exactly, only Hyperthreading is available. I could not find Intel
> Virtualization Tech , MLC streamer, etc. So here's my question if all these
> options support coreboot for Xeon D-15xx?
>
>
> Thanks&Regards,
>
> Ashmita Chakraborty
> ------------------------------
> *From:* Ranga Rao <rangarao(a)ircona.com>
> *Sent:* Wednesday, July 3, 2019 1:15:07 PM
> *To:* Ashmita Chakraborty; coreboot(a)coreboot.org
> *Subject:* RE: [coreboot] Re: Does Coreboot support the following options
> to enable/disable?
>
>
> Hi Ashmita,
>
>
>
> I could see HyperThreading Enable/Disable in Upd_Data_region
>
> FSP-master\BroadwellDEFspBinPkg\include\fspvpd.h
>
>
>
> Regards
>
> Ranga
>
>
>
> *From:* Ranga Rao <rangarao(a)ircona.com>
> *Sent:* Wednesday 3 July 2019 08:18
> *To:* Ashmita Chakraborty <Ashmita.Chakraborty(a)Ltts.com>;
> coreboot(a)coreboot.org
> *Subject:* [coreboot] Re: Does Coreboot support the following options to
> enable/disable?
>
>
>
> Hi Ashmita,
>
>
>
> Broadwell-DE / Xeon D support still depends Intel's closed-source FSP
> (Firmware Support Package) binary-only blobs.
>
> Broadwell-DE SoC / Xeon D Support Added To Coreboot
>
>
>
> Hope you could configure them through fsp_upd_data?
>
>
>
> Regards
>
> Ranga
>
>
>
>
>
>
>
>
>
> *From:* Ashmita Chakraborty <Ashmita.Chakraborty(a)Ltts.com>
> *Sent:* Wednesday 3 July 2019 08:14
> *To:* Ranga Rao <rangarao(a)ircona.com>; coreboot(a)coreboot.org
> *Subject:* Re: [coreboot] Does Coreboot support the following options to
> enable/disable?
>
>
>
> Dear Ranga,
>
>
>
> These options are meant for Xeon D-15xx series family. So will the
> coreboot support these options? The coreboot will be built for Xeon D-15xx
> processor. Yes, I have access to them in fsp_early_init through
> fsp_upd_data.
>
>
>
> Thanks&Regards,
>
> Ashmita Chakraborty
>
>
> ------------------------------
>
> *From:* Ranga Rao <rangarao(a)ircona.com>
> *Sent:* Tuesday, July 2, 2019 8:41 PM
> *To:* Ashmita Chakraborty; coreboot(a)coreboot.org
> *Subject:* RE: [coreboot] Does Coreboot support the following options to
> enable/disable?
>
>
>
> Hi,
>
>
>
> As these features are processor/SoC specific and they are part of FSPM,
> they should be configurable
>
> during fsp early init in coreboot, though you may not find a KConfig
> option to enable/disable
>
>
>
> Do you have access to them in *fsp_early_init* through *fsp_upd_data?*
>
>
>
> Regards
>
> Ranga
>
>
>
> -----Original Message-----
> From: ashmita.chakraborty(a)ltts.com <ashmita.chakraborty(a)ltts.com>
> Sent: Tuesday 2 July 2019 07:34
> To: coreboot(a)coreboot.org
> Subject: [coreboot] Does Coreboot support the following options to
> enable/disable?
>
>
>
> Does the coreboot support the following options to enable/disable:
>
>
>
> HyperThreading - Disabled
>
> Execute Disable Bit - Enabled
>
> Intel Virtualization Tech- Enabled
>
> Intel (R) TXT- Disabled
>
> Enhanced Error Containment Mode -Disabled
>
> MLC Streamer -Enabled
>
> MLC Spatial Prefetcher -Enabled
>
> DUC Data Prefetcher -Enabled
>
> DUC Instruction Prefetcher -Enabled
>
> LLC Prefetch - Enabled
>
> Intel Configurable TDB -Enabled
>
> TDP Level -level 2
>
>
>
>
>
> Please let me know.
>
>
>
> Thanks in advance.
>
>
>
> Regards,
>
> Ashmita Chakraborty
>
> _______________________________________________
>
> coreboot mailing list -- coreboot(a)coreboot.org To unsubscribe send an
> email to coreboot-leave(a)coreboot.org
>
> *L&T Technology Services Ltd*
>
> www.LTTS.com
>
> This Email may contain confidential or privileged information for the
> intended recipient (s). If you are not the intended recipient, please do
> not use or disseminate the information, notify the sender and delete it
> from your system.
>
> *L&T Technology Services Ltd*
>
> www.LTTS.com
>
> This Email may contain confidential or privileged information for the
> intended recipient (s). If you are not the intended recipient, please do
> not use or disseminate the information, notify the sender and delete it
> from your system.
> _______________________________________________
> coreboot mailing list -- coreboot(a)coreboot.org
> To unsubscribe send an email to coreboot-leave(a)coreboot.org
>
Hi again,
A clarification. From the StoneyPI_1_3_0_A.ZIP file I've got under NDA is it possible to compile it and get the AGESA.bin file?
For instance, for the fam15tn family the coreboot build process generates a libagesa.fam15tn.a file which is integrated in the
final coreboot.rom file. Could it be possible to do the same from a PI family? The build process in coreboot is only prepared to
use a wrapper and the AGESA.bin file, but maybe is it possible to generate the AGESA.bin from the zip file...
Thanks!
________________________________
De: Jorge Fernandez Monteagudo <jorgefm(a)cirsa.com>
Enviado: martes, 2 de julio de 2019 14:25
Para: Kyösti Mälkki
Cc: coreboot(a)coreboot.org
Asunto: [coreboot] Re: Question about blobs
Hi Kyösti! Thanks for the info!
>AMD contracted SilverBack for the tasks on StoneyRidge (and
>MerlinFalcon apparently). The source is a heavily modified StoneyPI
>package. You may get the unmodified one from AMD reps under NDA. Or
>pay SilverBack for the development you would be more capable of doing
>yourself, and you still might not get a license that allows
>distributing the work. There was a promise of scrubbing and
>relicensing StoneyPI source but... Let's just say legalities messed it
>up, I don't have the details.
Yes, the AMD reps we're in touch answer me to get in touch with SilverBack to get support :(
We've been able to get a more recent StoneyPI_1_3_0_A.ZIP under NDA because I've seen
this version fixed the issue:
EMBSWDEV-4487: System is not booting when memory is connected only to DIMM 1 slot
maybe related with our problem, but I don't know how to integrate this code into coreboot...
And if you say that the current work in coreboot is from a heavily modified base from SilverBack
I don't have any chance to make it work...
>As for the the other blobs (MullinsPI, CarrizoPI, KaveriPI), those
>were either built at SAGE (R.I.P.) or AMD AES (R.I.P.) and I have been
>told the repositories and toolchains were never officially transferred
>to SilverBack's possession. In other words, even if you paid,
>SilverBack is not likely to work on those.
Then, no more options to get a working BIOS than SilverBack?
>I believe we have talked before. Maybe it was about CarrizoPI? I was
>asking for commercial adopters around coreboot and binaryPI, in
>attempts to get to the same negotiation table with AMD management. Did
>You or Your manager ever respond?
Yes. I began asking in the coreboot mailing list about the Bettong mainboard. I added TPM support
and tianocore to that demoboard. I remember the email and I answered it giving my support because
we thought coreboot is the way to go to support our custom board.
Regards,
Jorge
