Re: [coreboot] How does intelmetool's support for Skylake?

[Shawn]

Sunrise Point-H & Sunrise Point-LP can be supported by intelmetool:

https://github.com/zamaudio/intelmetool


Tested it on Alienware 13R2 & P10S-M WS and it's working perfectly.


On Thu, Jan 5, 2017 at 3:20 PM, Zoran Stojsavljevic
 wrote:
> Hello Shawn,
>
> Happy New Year to you too. I wish you and all Coreboot community to be
> blessed by Health. :-)
>
> Needless to say, I found your changes there, but just yesterday evening.
>
> Here they are:
> https://github.com/zamaudio/intelmetool/commit/052350ae131b34b95f55a56c35e3b84e80fa860a
>
> I also fetched the latest coreboot few moments the same time, and checked:
> these changes are not incorporated in the latest Coreboot:
> 4.5-759-gab8f7d315e
>
> So, I'll ask kindly Damien to add these changes into Coreboot (there are a
> bit more lines that you added there).
>
> Damien (Zammit),
>
> could you, please, update Coreboot intelmetool with the latest changes?
>
> I'll look (later) into two latest net links you have provided to me. :-)
>
> Thank you,
> Zoran
>
> On Thu, Jan 5, 2017 at 7:22 AM, Shawn  wrote:
>>
>> Hi Zoran,
>>
>> Happy new year;-)
>>
>> intelmetool merged the patch, plz check:
>>
>> https://github.com/zamaudio/intelmetool
>>
>> If you're going to only neutralize the ME, you can use external
>> programmer && try me_cleaner:
>>
>> https://github.com/corna/me_cleaner/
>>
>> We've only tested a few coreboot supported mainboards on neutralizing
>> ME( I'm afarid your hardware isn't on the list-_-):
>>
>>
>> https://github.com/hardenedlinux/hardenedlinux_profiles/tree/master/coreboot
>>
>> On Wed, Jan 4, 2017 at 8:28 PM, Zoran Stojsavljevic
>>  wrote:
>> > Hello Shawn,
>> >
>> > I am late, I apologize... New Year, everything is slow, me either.
>> >
>> > For me, the link you have provided does not work?! it is HTTP 404 (page
>> > not
>> > found). Could you, please, repost the valid link? Or to attach the given
>> > patch to this email?
>> >
>> > With the normal Coreboot intelmetool (where I added one more printk() to
>> > explore what are the device ids the tool looks into), I have the
>> > following:
>> >
>> > [root@localhost intelmetool]# uname -a
>> > Linux localhost.localdomain 4.8.15-300.fc25.x86_64 #1 SMP Thu Dec 15
>> > 23:10:23 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux
>> > [1]+  Doneemacs intelmetool.h
>> > [root@localhost intelmetool]# ./intelmetool -s
>> > dev->vendor_id = 0x8086, dev->device_id = 0x9c22
>> > dev->vendor_id = 0x8086, dev->device_id = 0x9c03
>> > dev->vendor_id = 0x8086, dev->device_id = 0x9c43
>> > Bad news, you have a `8 Series LPC Controller` so you have ME hardware
>> > on
>> > board and you can't control or disable it, continuing...
>> >
>> > Error mapping physical memory 0x004275159040 [0x4000] ERRNO=1
>> > Segmentation fault (core dumped)
>> >
>> > [root@localhost intelmetool]# lspci -nn | grep 9c22
>> > 00:1f.3 SMBus [0c05]: Intel Corporation 8 Series SMBus Controller
>> > [8086:9c22] (rev 04)
>> > [root@localhost intelmetool]# lspci -nn | grep 9c03
>> > 00:1f.2 SATA controller [0106]: Intel Corporation 8 Series SATA
>> > Controller 1
>> > [AHCI mode] [8086:9c03] (rev 04)
>> > [root@localhost intelmetool]# lspci -nn | grep 9c43
>> > 00:1f.0 ISA bridge [0601]: Intel Corporation 8 Series LPC Controller
>> > [8086:9c43] (rev 04)
>> > [root@localhost intelmetool]#
>> >
>> > Yet, in intelmetool.h it says explicitly:
>> >
>> > // Definitely has ME and is very difficult to remove
>> > [snap]
>> > #define PCI_DEVICE_ID_INTEL_LYNXPOINT_LP_FULL0x9c41
>> > #define PCI_DEVICE_ID_INTEL_LYNXPOINT_LP_PREM  0x9c43
>> > #define PCI_DEVICE_ID_INTEL_LYNXPOINT_LP_BASE   0x9c45
>> >
>> > Coreboot ME pros, any comment on my HW (i5-4300U HSW ULT + PCH
>> > LynxPoint)?
>> > Appreciate any help!
>> >
>> > Thank you,
>> > Zoran
>> >
>> > On Fri, Dec 30, 2016 at 11:25 AM, Shawn  wrote:
>> >>
>> >> This is a work around patch( I think?):
>> >>
>> >>
>> >> https://github.com/hardenedlinux/intelmetool/commit/ad778fc347b2bb0494abe2186632a072b8ad1a11
>> >>
>> >> ./intelmetool -s
>> >> RCBA at 0x
>> >> MEI not hidden on PCI, checking if visible
>> >> MEI found: [8086:9d3a] Sunrise Point-LP CSME HECI
>> >>
>> >> ME Status   : 0xa245
>> >> ME Status 2 : 0x86110306
>> >>
>> >> ME: FW Partition Table  : OK
>> >> ME: Bringup Loader Failure  : NO
>> >> ME: Firmware Init Complete  : YES
>> >> ME: Manufacturing Mode  : NO
>> >> ME: Boot Options Present: NO
>> >> ME: Update In Progress  : NO
>> >> ME: Current Working State   : Normal
>> >> ME: Current Operation State : M0 with UMA
>> >> ME: Current Operation Mode  : Normal
>> >> ME: Error Code  : No Error
>> >> ME: Progress Phase  : Clean Moff->Mx wake
>> >> ME: Power Management Event  : Pseudo-global reset
>> >> ME: Progress Phase State: Unknown 0x11
>> >>
>> >> PCI READ [bc] : 0x00bc
>> >> ME: Extend Register not valid
>> >>
>> 

[coreboot] !IS_TOP_ALIGNED_ADDRESS failure

[giuseppe.ferrigni--- via coreboot]

Hello to all,

I'm getting confidence with coreboot for the first time. I followed instruction 
in the "Lesson1" article for a very basic build and everything gone well. Now 
I'm trying to build coreboot for a real board (amd ipc_fp4_dp not present in 
current release) but setting several mainbord devices results in different 
errors. One of these is the following:

cbfstool: /home/oxboxes/coreboot/util/cbfstool/cbfstool_image.c:666: 
cbfs_add_entry: Assertion '' !IS_TOP_ALIGNED_ADDRESS(content_offset)' failed

Due to lack of tutorial to understand the coreboot structure, can someone help 
me to understand why the building process fail?

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

[coreboot] FILO 0.6.0 payload bootloader - Questions?

[qma ster]

I have successfully built and added FILO bootloader to my Lenovo G505S
coreboot image! First of all, I had to use Xubuntu 16.04.1 *i386* because
FILO fails to compile on x86_64 bit system. Also: from
*./coreboot/payloads/libpayload/drivers/storage/ahci.c * removed two " #if
IS_ENABLED(CONFIG_LP_STORAGE_AHCI_ONLY_TESTED) ... #endif " parts, ---
because there are only three tested controllers in a list and FILO doesnt
even try to initialize the not listed controllers - despite that they could
work! By default, FILO just outputs "ahci: Not using untested SATA
controller" message, without any option for a user to try forcing its usage
to test it and made it a tested controller...

now FILO outputs the following log:

Booting from CBFS...
coreboot: ... version (its from the beginning of December 2016) ...
FILO version 0.6.0 (user@pc) date-of-the-build
ahci: Found SATA controller 00:11.00 (1022:7801) <--- this is AMD SATA AHCI
controller, built-in inside Bolton A76M FCH Southbridge of Lenovo G505S
ahci: ATA drive on port #1.
ata: Identified [my 1TB HDD drive model here]
ahci: ATAPI drive on port #2.
atapi: Identified [my DVD drive model here]
ERROR: No such CMOS option (boot_devices)

Then, it shows me FILO screen with " root_dev = unset " message on top, and
FILO command line

Questions:

could you give some good examples about how to use FILO ? Do I have to set
boot_devices in CMOS through nvramcui payload, or it is possible to choose
that root_dev in FILO - if yes, how?

I tried some random commands like
filo> kernel hda:/vmlinuz
but it tells:
Disk read error dev=1 drive=0 sector=0
Disk read error dev=1 drive=0 sector=2
Disk read error dev=1 drive=0 sector=2
Disk read error dev=1 drive=0 sector=128
Disk read error dev=1 drive=0 sector=16
Disk read error dev=1 drive=0 sector=64
Disk read error dev=1 drive=0 sector=0
Disk read error dev=1 drive=0 sector=64
Disk read error dev=1 drive=0 sector=0
Disk read error dev=1 drive=0 sector=0
Unknown filesystem type.

Error 15: Filo not found.

EDIT: found https://www.coreboot.org/FILO but its too basic - for example,
it does not tell how I could see the list of available devices. When I run
"probe" command it only tells 6 messages "IDE channel X not found"  (with X
changing 0,0,1,1,2,2,3,3) - does not show SATA drive, despite I know that
it successfully initialized, because it output its model and brand

Please give any real world FILO usage examples with a modern Linux, it will
help a lot!

Best regards,
qmastery
-- 
coreboot mailing list: coreboot@coreboot.org
https://www.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] Let’s solve the Asus KCMA-D8 mess

[Pierre P]

Hi,


Thanks Paul for this peaceful and hopeful message. I'll follow you and would 
like to help with another 1000 €.


Thanks Timothy for your work !

Pierre


From: coreboot  on behalf of Timothy Pearson 

Sent: Friday, January 27, 2017 12:21 AM
To: Paul Menzel
Cc: Paul Menzel via coreboot
Subject: Re: [coreboot] Let’s solve the Asus KCMA-D8 mess

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 01/26/2017 05:13 PM, Paul Menzel via coreboot wrote:
> Dear coreboot folks,
>
>
> As many of you know, last week was not pretty [1]. Unfortunately, no
> solution was found.
>
> Chances are slim, that the involved parties will get along in the
> future, but hopefully they will.
>
> I had hoped, that the community would have been asked for help before
> to find a solution, that (all?) the money could not be raised.
>
> Also, the coreboot project has the source code for the Asus KCMA-D8,
> and the REACTS infrastructure is run to build test the board to find
> regressions.
>
> I propose, that the community steps in for Minifree(?) and raises the
> $15,000 instead to settle the debts, forget about it and go on.
>
> I’ll take my 1000 € pledge for the TALOS workstation and put 500 € on
> top, so ten percents are covered.
>
> Is anybody with me? Smaller amounts are as welcome as bigger. If nobody
> else wants to, I would note down the amounts, already transferred.
>
> Having not done that before, I hope tax rules and regulations don’t
> make that difficult. Please advice how to best transfer the money.
>
> I believe in our community, and I am hopeful to settle this.
>
>
> Thanks,
>
> Paul
>
>
> [1] see the thread *ASUS KCMA-D8 workstation board port offer*
>

First, thank you to Paul for making this suggestion; I appreciate the
effort that went into it.

To sweeten the deal a bit, I'd be willing to throw in some overclocking
code for the KCMA-D8 if the community made this happen.  I developed
the overclock on the side for use with my personal gaming rig, and have
been running a single HE Opteron at a 4.2GHz core clock vs. the stock
~2.5GHz(?) base clock.  Until now there really was no way to overclock
the Opterons, but I was able to figure a method out with some fairly
decent results.

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/

iQEcBAEBAgAGBQJYioSFAAoJEK+E3vEXDOFb9egH/0hH3N/y+GqtfyEMNiaNKOER
XR1tPixDFYhbLGhvTSvg2X0xjd6IgRLlbRjMm42dGphyJHXA4g7g8FQhvWVxdTu4
+cWLuTrxyyhdAc1hxCq9UhLA+eoyXYCVDuYABMVq5VqtgKQFc6H4oEkM9YvUtD0y
iUj2tml4znLhSJXwcz+t60I8z4r/+xI5OaZ1jMWliYcHS/j4Syo/MUp0LapYwfE1
APtSe/dpcnh00eBVd3Ar4vSc8mWDvng2lo8bxRGpBJG7qWTGBzg538eVEjsfpAhY
Bd8/HgrFblEbcU+idoN4ELlPFB12BFJb1tBGeyeCnD3yDw37sBrsj4P1jbMs7oI=
=TKy3
-END PGP SIGNATURE-

--
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] Documentation creation for the coreboot wiki - what to do?

[Timothy Pearson]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 01/29/2017 01:28 PM, Marshall Dawson wrote:
> I agree with Martin's assessment.  I'll elaborate that the suppliers are
> simply delivering what their revenue generators ask for.  Those are
> overwhelmingly ODMs and OEMs who demand that solutions be provided to
> them, not Swiss Army knives or DIY kits.  That's why suppliers design
> software that runs on MEs, IMCs, PSPs, sideband controllers, etc. 
> Customers rarely care about what a product could do; they want to know
> what it does.

I'll also add that there is are actually two markets for people that
care about building something to execute a task that the OEM didn't know
about.  The problem is you're really looking at very low end (embedded,
where the processor is not the primary solution, only part of the
overall system) and very high end (where a good chunk of your trade
secrets may revolve around how you're using the machine and what you
quietly stuck onto it without the OEM's knowledge).

There is absolutely no reason for anyone to use mid range computing
systems in these type of roles.  This primarily is a factor of cost; on
the embedded side you can't justify using a more powerful / complex
processor with more to go wrong than what you actually need, and on the
high end the investment in developing the secret IP dwarfs the cost of
the machines themselves.  Therefore, I assert that market forces dictate
libre firmware (and possibly certain classes of libre software) will not
be available for mid range general purpose computing systems barring a
massive shift in semiconductor manufacturing.

The only argument one could theoretically make is security, but again
this applies moreso to large organizations that are going to be using
very specific types of machines and are going to be willing to pay more
for the secure computers.  There is no benefit to an average Joe
(Windows user, uploads all their data to Facebook, likes to torrent
movies and games, etc.) to have their firmware secured.  When something
goes wrong enough that they can't use their PC, they'll just wipe,
reload, and continue on.  Even if an APT embedded itself in their
firmware they won't be aware of it or experience any sensible financial
loss from the situation -- just look at the IoT hack last year for a
good example.  Did any of the "owners" of the hacked IoT devices receive
a fine for their role, or lose access to the device?  No.  So why would
average Joe care one bit about security, and why would the OEMs creating
hardware for average Joe pay more for securable systems?

I hate to say it, but libre software is now the domain of those who just
want to connect to cloud services or retrocompute, and those
organizations with large enough budgets and valuable enough IP to
justify the extra cost.  It's not a matter of the OEMs being evil, it's
a matter of the market adjusting to meet the demands of the 95% at the
expense of the 5%, even if the 5% were heavily contributing to society
as a whole.

- -- 
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/

iQEcBAEBAgAGBQJYjkwjAAoJEK+E3vEXDOFb1fAIAKvCINVZazjphz3ja0oY5YHx
jT+fnTP7cJ5l1g9aqKZH4cl4th8k1+VMn/MqGsNjn2J/+11/MUnY6QpHrU9mqsLq
bxEvrK9ZPX06GdVN2gtf35/Z5p9xL+GwN7yUtQfCGdrjtujert4VtyOYFiR/NWTR
p/9H0kVrZEd32wYLSb2/d3GbA3802gxbJtJx/f4Q4xh1So46RORfNJ3X3XYg7xH8
rkkQs8EXK3mezKSLfajD/8gbNdm2A2oOY6uZiHD0M0Tvc/Fz3er/mVbMNlZ29Z7p
r5w5SyhDPOPP5NzInatDZodeI9x5QHJ6ZVheHfqyISWbmzIRQ9Qc+alD+ukNrt4=
=KMDF
-END PGP SIGNATURE-

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

Re: [coreboot] Documentation creation for the coreboot wiki - what to do?

[Marshall Dawson]

I agree with Martin's assessment.  I'll elaborate that the suppliers are
simply delivering what their revenue generators ask for.  Those are
overwhelmingly ODMs and OEMs who demand that solutions be provided to them,
not Swiss Army knives or DIY kits.  That's why suppliers design software
that runs on MEs, IMCs, PSPs, sideband controllers, etc.  Customers rarely
care about what a product could do; they want to know what it does.

AMD used to be chill, they released the AGESA code - but then they took it
> closed source againI would really like to know why.
>
AMD, in particular, requires any open-sourced closed code to go through an
IP scrub process first.  This is prohibitively expensive compared to their
anticipated return on investment.  Those of us interested in coreboot could
never make a convincing business case for the scrub to happen on time.
Without board and silicon support prior to a product's launch, that
would've made coreboot a non-starter for AMD customers.  Developing the
binaryPI was not intended as a slap on freedom, but it was a "something is
better than nothing" approach.

Thanks,
Marshall


On Sun, Jan 29, 2017 at 9:57 AM, taii...@gmx.com  wrote:

> On 01/28/2017 08:48 PM, Martin Roth wrote:
>
> On Fri, Jan 27, 2017 at 5:16 PM, taii...@gmx.com  wrote:
>>
>>> I would like to know as to how much we are allowed to indicate that x86
>>> OEM's are generally hostile to the FOSFW movement? I don't want to ruffle
>>> any feathers, as these days they are already significantly ruffled.
>>>
>> Hi Talidan,
>>My personal opinion here is that you're incorrect.  I don't think
>> that they're hostile at all.  I think that the corporations don't see
>> the value in catering to the few people who are interested in
>> completely open firmware.  They're trying to solve issues, and the
>> solutions that they've chosen just happen to completely lock out third
>> party firmware.
>>
>> If you want to change that, I'd say that you have to be noticed, and
>> noticed in a POSITIVE light.  If the coreboot community just complains
>> about the current situation, we're not going to get anywhere.  There
>> are plenty of people at these companies who feel the same way that we
>> do about these sorts of issues, and we only make it harder by saying
>> that the OEMs are 'hostile' or 'evil'.  They aren't - they're just
>> looking to create value for their shareholders by leveraging
>> synergistic solutions.  Or something like that.  :)
>>
>> So while this is just my opinion, I'd recommend just keeping to the
>> facts about the issues, and not going beyond that.  Feel free to point
>> out the issues that Intel's bootguard or AMD's PSP present for us, but
>> I'd try to refrain from anything beyond that.  If you do want to go
>> beyond that, please make it plain that it's coming from you as an
>> individual, and may or may not reflect the coreboot community as a
>> whole.
>>
>> If we want to change things, we need an argument that makes sense to
>> the companies we want to change - Something financial.
>>
>> Martin
>>
>> The only issue is that there won't be a free firmware community in a few
> years due to the actions of intel and AMD as there is no way to shut off
> boot guard or ME/PSP.
> I don't consider a system with FSP/MRC/ME to be "free" firmware as
> coreboot does hardly anything in that situation.
>
> AMD used to be chill, they released the AGESA code - but then they took it
> closed source againI would really like to know why.
>
>
> IMO getting intelligence agencies and major corporations involved in the
> free firmware movement is what will save it,  assured computing is all the
> rage these days - china and russia are making their own CPU designs and
> DARPA is interested in hardware verification. What corporation that deals
> with sensitive IP wants a black box supervisor processor (magic backdoor)
> on their every device?
>
> They currently do not know how much they need it, let us hope that will
> change.
>
>
> --
> 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] KGPE-D16 with over 128GB RAM - works reliably yet?

[Timothy Pearson]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 01/29/2017 09:38 AM, Peter Stuge wrote:
> Timothy Pearson wrote:
>> Populating all four slots closest to CPU1 with large ECC registered
>> DIMMs is a surefire way to recreate the instability -- note a
>> training failure is not common, the main issue is that the marginal
>> routing causes severe memory corruption when the BKDG-recommended
>> algorithms are used.
> 
> What does the vendor BIOS do?

Unknown.  I would imagine there is a hack in the vendor BIOS to work
around this board-specific issue, but that doesn't help coreboot very
much.  We had looked into it before, but decided it was not worth the
cost to research and implement a fix.

For what it's worth, there are several threads online about the KGPE-D16
and memory corruption with the vendor BIOS.  It seems to have taken ASUS
some time to iterate and work around 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/

iQEcBAEBAgAGBQJYjj6vAAoJEK+E3vEXDOFbbH8H/RarB/ky7zMKzZrWnYJgsieD
bEA7RXdCQyBU8w44QOswMbdaM61e4V4luwklJlCUSMgsCfuABHNgoR9v1C1u9E1b
Q5AKj0FJzUgET1Eb+dBfN7VAVG1ezhJkPHXqRJI9MPkKsmwlAXrYynaZqS6x8AZE
q4a0VYqWyckDTECti+kjgGwN5EyPEy+Mg+9ic1tSn8ItjIlV8ztpvmTUy2d56B+R
wr4RKDM8WBWOMQm2itPVKAoeM7KA3ewJ2ZkpLG1cGmUMOjIMPyjlEKPKchBbpmvk
zoPBhyJSDbbcMoAWp4h2813pVWWDxCufmcGlINZSwztmKkhXWgRDDnRlH7J6PRs=
=EcKb
-END PGP SIGNATURE-

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

Re: [coreboot] Documentation creation for the coreboot wiki - what to do?

[taii...@gmx.com]

On 01/28/2017 08:48 PM, Martin Roth wrote:


On Fri, Jan 27, 2017 at 5:16 PM, taii...@gmx.com  wrote:

I would like to know as to how much we are allowed to indicate that x86
OEM's are generally hostile to the FOSFW movement? I don't want to ruffle
any feathers, as these days they are already significantly ruffled.

Hi Talidan,
   My personal opinion here is that you're incorrect.  I don't think
that they're hostile at all.  I think that the corporations don't see
the value in catering to the few people who are interested in
completely open firmware.  They're trying to solve issues, and the
solutions that they've chosen just happen to completely lock out third
party firmware.

If you want to change that, I'd say that you have to be noticed, and
noticed in a POSITIVE light.  If the coreboot community just complains
about the current situation, we're not going to get anywhere.  There
are plenty of people at these companies who feel the same way that we
do about these sorts of issues, and we only make it harder by saying
that the OEMs are 'hostile' or 'evil'.  They aren't - they're just
looking to create value for their shareholders by leveraging
synergistic solutions.  Or something like that.  :)

So while this is just my opinion, I'd recommend just keeping to the
facts about the issues, and not going beyond that.  Feel free to point
out the issues that Intel's bootguard or AMD's PSP present for us, but
I'd try to refrain from anything beyond that.  If you do want to go
beyond that, please make it plain that it's coming from you as an
individual, and may or may not reflect the coreboot community as a
whole.

If we want to change things, we need an argument that makes sense to
the companies we want to change - Something financial.

Martin

The only issue is that there won't be a free firmware community in a few 
years due to the actions of intel and AMD as there is no way to shut off 
boot guard or ME/PSP.
I don't consider a system with FSP/MRC/ME to be "free" firmware as 
coreboot does hardly anything in that situation.


AMD used to be chill, they released the AGESA code - but then they took 
it closed source againI would really like to know why.



IMO getting intelligence agencies and major corporations involved in the 
free firmware movement is what will save it,  assured computing is all 
the rage these days - china and russia are making their own CPU designs 
and DARPA is interested in hardware verification. What corporation that 
deals with sensitive IP wants a black box supervisor processor (magic 
backdoor) on their every device?


They currently do not know how much they need it, let us hope that will 
change.


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

Re: [coreboot] 8 GB DIMMs on Nehalem (Arrandale)

[Zoran Stojsavljevic]

> The T410s does have only two slots (NB: T410 is a completely different
> model with a different casing). The 4-slot system is the W510 with the
> clarkdale i7 CPU that does not have coreboot support at all.

Sorry for my ignorance. I know very well (more than) in many aspects INTEL
CPU CORE and ATOM architectures/technologies. I really do not track
platform specifics (too many of them). Especially I do NOT track which
INTEL "Echo System" (as INTEL call 'em) partners (ASUS, LENOVO etc.) use
which INTEL CORE CPUs for which of theirs' platforms, per say. People need
to feed me with these info. If they feed me with detailed journalctl/dmesg
(with various options), I can figure it out from kernel dmesg/journalctl
traces. If I have (any personal) interest to do this. Usually I do not.

There are IOTG INTEL (R as well as Support) employees on this list which
should know (much) better. At least, to help you with these requests. Why
they do NOT do these... Not (really) my problem! Rather theirs/INTEL.

Don't you agree? ;-)

Please, ask INTEL. Tell us, please, what did they answer to you?! :-))

> In the T410s the vendor firmware and coreboot work fine with 2x 4GB
> DIMMs but as soon as there is one 8GB DIMM even if it is the only
> stick and no matter in which slot it is, things go crazy with the vendor
> firmware and the raminit code of coreboot stops in the middle as
> described earlier. So there is nothing obvious left to try regarding
> DIMM combinations in the T410s.

My best guess is... INTEL internally (teamed with AMI) did NOT (even in The
Past) issue internal BIOS (for the given platforms) which does
(particularly) MRC for 2 X 8GB DDR. Just for 2 X 4GB (if they did for 2 X
8GB, please, keep us all in Coreboot list informed)

I have advice to you: either you give up, either you try to rewrite AMI
BIOS/Coreboot MRC algorithm(s) to comply with 2 X 8GB DIMM for Lenovo
T410s/Nehalem DDRAM timings. ;-)

Good Luck!
Zoran

On Sun, Jan 29, 2017 at 11:43 AM, Stefan Tauner <
stefan.tau...@alumni.tuwien.ac.at> wrote:

> On Sun, 29 Jan 2017 07:15:18 +0100
> Zoran Stojsavljevic  wrote:
>
> > > The current raminit for Nehalem in coreboot is not able to train the
> two
> > > 8 GB DIMMs I have tested so far. I have added a debug output to
> > > choose_reg178 in the first loop before the margins are compared to
> > > STANDARD_MIN_MARGIN that shows that all margins are 0.
> >
> > I would suggest to you to do the following: to return to the platform
> true
> > BIOS, and to see if BIOS works with your Arrandale i5-520M (Thinkpad
> 410).
> > Then you can try several different DIMM configurations, and see if BIOS
> > supports up to maximum of 32GB (4 X 8GB DIMM).
> >
> > Then, from these BIOS experiments, you can draw obvious conclusions in
> > relations with Coreboot MRC algorithm. :-)
>
> The T410s does have only two slots (NB: T410 is a completely different
> model with a different casing). The 4-slot system is the W510 with the
> clarkdale i7 CPU that does not have coreboot support at all.
>
> In the T410s the vendor firmware and coreboot work fine with 2x 4GB
> DIMMs but as soon as there is one 8GB DIMM even if it is the only stick
> and no matter in which slot it is, things go crazy with the vendor
> firmware and the raminit code of coreboot stops in the middle as
> described earlier. So there is nothing obvious left to try regarding
> DIMM combinations in the T410s.
>
> --
> Kind regards/Mit freundlichen Grüßen, Stefan Tauner
>
-- 
coreboot mailing list: coreboot@coreboot.org
https://www.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] KGPE-D16 with over 128GB RAM - works reliably yet?

[Peter Stuge]

Timothy Pearson wrote:
> Populating all four slots closest to CPU1 with large ECC registered
> DIMMs is a surefire way to recreate the instability -- note a
> training failure is not common, the main issue is that the marginal
> routing causes severe memory corruption when the BKDG-recommended
> algorithms are used.

What does the vendor BIOS do?


//Peter

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

Re: [coreboot] 8 GB DIMMs on Nehalem (Arrandale)

[Stefan Tauner]

On Sun, 29 Jan 2017 07:15:18 +0100
Zoran Stojsavljevic  wrote:

> > The current raminit for Nehalem in coreboot is not able to train the two
> > 8 GB DIMMs I have tested so far. I have added a debug output to
> > choose_reg178 in the first loop before the margins are compared to
> > STANDARD_MIN_MARGIN that shows that all margins are 0.  
> 
> I would suggest to you to do the following: to return to the platform true
> BIOS, and to see if BIOS works with your Arrandale i5-520M (Thinkpad 410).
> Then you can try several different DIMM configurations, and see if BIOS
> supports up to maximum of 32GB (4 X 8GB DIMM).
> 
> Then, from these BIOS experiments, you can draw obvious conclusions in
> relations with Coreboot MRC algorithm. :-)

The T410s does have only two slots (NB: T410 is a completely different
model with a different casing). The 4-slot system is the W510 with the
clarkdale i7 CPU that does not have coreboot support at all.

In the T410s the vendor firmware and coreboot work fine with 2x 4GB
DIMMs but as soon as there is one 8GB DIMM even if it is the only stick
and no matter in which slot it is, things go crazy with the vendor
firmware and the raminit code of coreboot stops in the middle as
described earlier. So there is nothing obvious left to try regarding
DIMM combinations in the T410s.

-- 
Kind regards/Mit freundlichen Grüßen, Stefan Tauner

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

Re: [coreboot] Documentation creation for the coreboot wiki - what to do?

[Paul Menzel via coreboot]

Dear Taiidan,


Am Freitag, den 27.01.2017, 19:16 -0500 schrieb taii...@gmx.com:

[…]

Thank you on planning to improve the documentation in the Wiki. Please
make sure to contact Zaolin and Martin, to be up-to-date, what the
current plans regarding documentation are.

> I would like to know as to how much we are allowed to indicate that x86 
> OEM's are generally hostile to the FOSFW movement? I don't want to 
> ruffle any feathers, as these days they are already significantly ruffled.
> 
> I was able to figure all this out but for the free firmware movement to 
> survive it needs to be spread to a wider audience thus things need to be 
> made a little bit easier, I have plenty of linux sysadmin acquaintances 
> but none of them use coreboot because they aren't yet fanatical enough 
> about FOSFW to bother with the difficulty level.

Do you have a suggestion on how the indication would look like?


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] Proposal for new "Commenting" wiki text

[Paul Menzel via coreboot]

Dear Nico,


Thank you for taking this up again.


Am Samstag, den 28.01.2017, 15:00 +0100 schrieb Nico Huber:
> 
> sorry to revive this old, stale topic. I got stalled by a request to
> ensure the comment style with a script. Now, that I had a look at
> checkpatch.pl, I don't think this could be done easily without risking
> many false positives.
> 
> So I'm again asking to commit my proposal below. I've incorporated the
> comments from Martin.

Just to be clear, also for the proposal below, the style can’t be
checked, right?

> Even if it's not going to be my preferred style, I would really appre-
> ciate it if we could agree on one style.
> 
> Nico
> 
> > == Commenting ==
> > 
> > Comments are good, but there is also a danger of over-commenting. NEVER
> > try to explain HOW your code works in a comment: it's much better to
> > write the code so that the _working_ is obvious, and it's a waste of
> > time to explain badly written code.
> > 
> > Generally, you want your comments to tell WHAT your code does, not HOW.
> > Also, try to avoid complex comments inside a function body: if the
> > function is so complex that you need to separately comment parts of it,
> > you should probably go back to chapter 6 for a while.  You can make
> > small comments to note or warn about something particularly clever (or
> > ugly), but try to avoid excess.  Instead, put the comments at the head
> > of the function, telling people what it does, and possibly WHY it does
> > it.
> > 
> > coreboot style for comments is the C89 "/* ... */" style. You may also
> > use C99-style "// ..." comments.

Could we change that, C89 style comments are preferred, and add a note about 
consistency?

> … You may also use C99 style "// …" comments, if it’s beneficial.
> Also, the commenting should be consistent in one file.

Or is that wishful thinking, and both style will always be mixed?

> > The preferred style for concise multi-line comments that explain a
> > single piece of code is:

Please, emphasize *concise*, or elaborate right away with *i. e., one
paragraph*

> > 
> > /* This is the preferred style for
> >two or three line comments that
> >avoids excessive blank lines. */
> > 
> > Note that there shouldn't be leading asterisks on new lines in the
> > concise style.
> > 
> > The preferred style for long multi-line comments is:

Please emphasize *long*.

> > /*
> >  * This is the preferred style for multi-line
> >  * comments in the coreboot source code.
> >  *
> >  * Description: A column of asterisks on the left side,
> >  * with beginning and ending almost-blank lines.
> >  */
> > 
> > Some rules of thumb to decide which style to use:
> > * If you are commenting a whole function (indentation level 0) or
> >   something high level (indentation level 1), use the long style.
> > * If you want to explain a single piece of code and your comment
> >   doesn't span multiple paragraphs, use the concise style.
> > * Otherwise you might want to ask yourself why what you're going to
> >   explain doesn't deserve an own function.
> > 
> > It's also important to comment data, whether they are basic types or
> > derived types.  To this end, use just one data declaration per line (no
> > commas for multiple data declarations).  This leaves you room for a
> > small comment on each item, explaining its use.
> > 
> > If the author has reasonable arguments for breaking the recommended
> > style guide to improve readability, others should be respectful of those
> > differences.

Nico, thank you again.


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] Does the 62xx Series Opteron work *securely* without microcode?

[Elena ``of Valhalla'']

On 2017-01-27 at 12:26:56 -0600, Timothy Pearson wrote:
> Something to think about: have you tried developing modern software on
> that Core 2 Duo?  Are you OK with only having hardware that can consume
> software (libre or not) that was created (compiled) on more powerful,
> non-free systems?

Please, define "modern software".

I have a deep (mostly) irrational hostility towards (libre|open)office,
so i have never tried to compile it (and suspect it may be problematic,
but not only because of performance issues).

Other than that, I have an X200 as my main (only, mostly) working
computer, updated to the maximum 8GB or RAM (which btw I'm only able to
fill when running multiple virtual machines).
For my $DAY_JOB I'm mostly working on what I believe is quite a common
type of modern software: web applications written in an interpreted
language, and that works on such a machine with absolutely no issue.

Lately I've compiled a couple of QT programs written by other people,
and I don't remember waiting a significantly longer time than expected;
it compares with the time spent running a full testsuite on some of the
projects I'm working on, so I expect that I could work on developing
such software with no big stumbling block from my computer's
performances.
Out of curiosity I've just compiled one of the heaviest programs I'm
using, darktable, and that took 10 minutes *including downloading all of
the dependencies in a chroot* and compiling from scratch (I used the
package building tools, because I have them installed and configured,
instead of having to install a dev environment).

I haven't (cross-)compiled a full OS for a few years; back when I was
using openembedded and did it I was using an even more limited computer
and yes, it could take hours. Nowadays however I'm mostly using debian
and packages that somebody else have compiled, usually on ARM boards¹
that aren't exactly known for their raw computing power.

¹ Debian doesn't crosscompile their "other" architectures.

One thing that would probably be problematic is compiling something like
the android SDK: that's an issue for freedom, but that's not really
required to work on modern software *for the free-ish computer I'm
using*.  Also, IIRC it is something that already required something like
8-16 GB or RAM a few years ago, when this computer would have been
considered quite new, and would have come with 4GB RAM max.

-- 
Elena ``of Valhalla''

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

Re: [coreboot] C++

[Paul Menzel via coreboot]

Dear Philipp,


Am Samstag, den 28.01.2017, 15:13 +0100 schrieb Philipp Stanner:
> Could coreboot (or parts of it) be written in C++?

Sure, it’s possible and could be done.

> What would be the advantages and disadvantages?

As the others, I don’t see an advantage.

But, did you just mean coreboot, or “coreboot based firmware”, which
includes payloads?

If the later, I believe that you can indeed write payloads with C++, if
you know it well.

I have no idea about the size implications though.


Kind regards,

Paul

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