[coreboot] Re: Planning the next coreboot release

2020-04-23 Thread Jonathan Zhang (Infra) via coreboot
Hi Patrick,

Your help and dedication is much appreciated!

As we (FB and its partners) successfully finished bring-up of coreboot on 
CooperLake-SP based
1 socket platform, we are shifting our focus to exclusively on Cooperlake-SP 
based platfroms, away 
from using Skylake-SP based TiogaPass as the feature development vehicle.

This timing works well with the planned coreboot release.  We have a number of 
SKX-SP 
platform related changes in the pipeline, we will try our best to work with the 
community to get them
merged, then we will run a test pass, and we could report the status to the 
community (such as 
document what works and what further works are needed in 
Documentation/mainboard).

Many features (in particular smbios and BMC interaction) have been added to 
TiogaPass OCP
platform, also TiogaPass can be bought off-the-shelf from Wiwynn. If we are 
lucky enough to have
an IBV taking care of SKX-SP FSP maintenance, the industry at large will have 
an end to end open source
firmware solution for SKX-SP based platform. Such solution is not 100% open 
source due to FSP, ME, etc,
but it is a huge step forward.

The patch sets we would like to merge in for the planned releases are:
a. https://review.coreboot.org/c/coreboot/+/40500 . 
b. https://review.coreboot.org/q/author:wiwynn.com+status:open
c. https://review.coreboot.org/c/coreboot/+/40481 

Thank you,
Jonathan

On 4/22/20, 11:09 AM, "Patrick Georgi via coreboot"  
wrote:

Hi everybody,

it's that time of year again: we should look into cutting a
release. Not because there's anything noteworthy that we should bring
out (although there certainly is), but because we have a 6-monthly
cadence of giving our tree a new number and pushing out tarballs and
press releases.

I plan to do the release on or shortly after May 11, and
this announcement is in accordance to the process detailed on
https://doc.coreboot.org/releases/checklist.html, so we're at the
"~2 weeks prior to release" point right now.

As such, there are a number of things I ask of you (all of you
subscribed to the list, but since you're reading this mail, yes,
I mean you, personally!):

1. If you have anything big that you want to get in before the release,
it's on you to maintain the changes responsibly and responsively so
that it all works out in time. I'll gladly help coordinate things
but I'm not interested in last-minute heroics, so get in touch with
me ASAP.

2. Please try to postpone riskier refactorings and the like until after
the release (unless they're ready to land in the next few days), so
that people have a solid foundation to test their hardware on. Which
gets us to the next point:

3. Please test your coreboot-supported gear if you can, report and/or
fix issues, and upload fresh reports to the board-status repo. While
we have no quality requirement for releases - they're _really_ only
about giving the tree a new number, a release is a good opportunity
to verify that what we have in the tree is still functional, with
only limited work required to pin-point new issues (bisections since
4.11 should take 12 steps or less at this time).

4. Please check the preliminary release notes in
Documentation/releases/coreboot-4.12-relnotes.md and add whatever
happened since 4.11 that you think is noteworthy. If in doubt, push
a change to gerrit and see what your fellow developers think about it.


Thanks,
Patrick Georgi
-- 
Google Germany GmbH, ABC-Str. 19, 20354 Hamburg
Registergericht und -nummer: Hamburg, HRB 86891, Sitz der Gesellschaft: 
Hamburg
Geschäftsführer: Paul Manicle, Halimah DeLaine Prado


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


[coreboot] Re: Planning the next coreboot release

2020-04-23 Thread Keith Hui
Hi Patrick,

> 1. If you have anything big that you want to get in before the release,

Can we get [38354] merged before 4.12 is cut? This is the last patch
needed to get onboard SCSI on Asus P2B-LS working - all its
prerequisites have been merged.

I have a new board and more 440BX platform stuff in the pipeline and I
understand they will have to wait.

Thanks
Keith

[38354] https://review.coreboot.org/c/coreboot/+/38354
___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org


[coreboot] Re: Memtest86+ stuck

2020-04-23 Thread Mike Banon
On Thu, Apr 23, 2020 at 5:42 PM R S  wrote:
>
> On Thu, Apr 23, 2020 at 6:46 AM Paul Menzel  wrote:
>>
>> PS: By the way, Memtest86+ 5.31b was released [2].
>>
>> [1]: https://review.coreboot.org/c/coreboot/+/32613
>> [2]: https://www.memtest.org/
>
>
> That's huge! Thanks for picking up development.
>
> --
> LAN Engineer * NOC and IT Infrastructure Maintenance
> BCS Technology Department * Network Group
> ComicSans Awareness Campaign
> ___
> coreboot mailing list -- coreboot@coreboot.org
> To unsubscribe send an email to coreboot-le...@coreboot.org

Would like to add 2 notes:
1) Recently I've discovered that you could build a coreboot's "5.01
002" memtest86+ fork as a floppy instead of payload (and then manually
add a floppy to a coreboot BIOS build)
2) A good way to double check is to also use a Passmark's memtest86
4.37 floppy. If you're getting the same results, means that maybe a
RAM is faulty; if the different results - maybea false positive.

Thank you for telling about a new memtest86+, nice to see it active
again. I'd inform the developer about coreboot's fork and some other
forks, so that he could merge them into a one great memtest.
___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org


[coreboot] Re: Regarding Intel CPU frequency.

2020-04-23 Thread nitin . ramesh . singh
Hi Mariusz,

I tried running the stress test to increase the load average, but still the 
frequency stays at 800Mhz.

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


[coreboot] Re: CBFS pointer problem with SeaBios and Apollo Lake platform

2020-04-23 Thread Matt DeVillier
Apollolake should work with:

CONFIG_CBFS_LOCATION=0xfffb1000
# CONFIG_HARDWARE_IRQ is not set

That's what I use for SeaBIOS as a legacy boot payload on ChromeOS devices,
but the CBFS address will be the same if using upstream coreboot

regards,
Matt

On Thu, Apr 23, 2020 at 3:24 AM Wolfgang Kamp - datakamp 
wrote:

> Hello,
>
>
>
> Am I correct that the problem still exists that SeaBios can’t find the
> CBFS in apl platform?
>
>
>
> Kind regards,
>
> Wolfgang Kamp
> ___
> 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: Memtest86+ stuck

2020-04-23 Thread R S
On Thu, Apr 23, 2020 at 6:46 AM Paul Menzel  wrote:

> PS: By the way, Memtest86+ 5.31b was released [2].
>
> [1]: https://review.coreboot.org/c/coreboot/+/32613
> [2]: https://www.memtest.org/


That's huge! Thanks for picking up development.

-- 
LAN Engineer * NOC and IT Infrastructure Maintenance
BCS Technology Department * Network Group
ComicSans Awareness Campaign 
___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org


[coreboot] Re: Memtest86+ stuck

2020-04-23 Thread Max Zim

On 23/04/2020 12:45, Paul Menzel wrote:

It’d be great, if you could bisect the commit


2182c5b is the first "good" commit.
___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org


[coreboot] Re: Regarding Intel CPU frequency.

2020-04-23 Thread Szafranski, MariuszX
Hi Nitin,

Look`s like SpeedStepping in action - correct behavior while on idle.
Please put more stress on CPU and recheck - It should jump back to 2200

BR,
Mariusz

-Original Message-
From: nitin.ramesh.si...@gmail.com  
Sent: czwartek, 23 kwietnia 2020 14:36
To: coreboot@coreboot.org
Subject: [coreboot] Regarding Intel CPU frequency.

Hi,

I am using coreboot to boot Denverton cpu (CPU C3558) based board.

I can see that the cpu frequency is set to the correct value i.e. "2200 Mhz" 
under the coreboot logs.
.
"
CPU #3 initialized
bsp_do_flight_plan done after 146 msecs.
cpu: frequency set to 2200
"

Later when I check the frequency reading under linux (kernel version 4.19) , It 
comes out as 800 Mz:

model name  : Intel(R) Atom(TM) CPU C3558 @ 2.20GHz
stepping: 1
microcode   : 0x24
cpu MHz : 800.000


When I reprogram the board with BIOS, the cpu frequency gets reflected 
correctly (i.e. 2200 MHz) with the same kernel image.

I have also tried out the different Grub command line options like disabling 
the pstate, and idle state e.t.c, but the end result remains same. 

Can anyone please provide me some suggestions. Is there is any cpu specific 
settings which needs to enabled under coreboot or with Intel-FSP ? 

Thanks,
Nitin.
___
coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to 
coreboot-le...@coreboot.org
--
Intel Research and Development Ireland Limited
Registered in Ireland
Registered Office: Collinstown Industrial Park, Leixlip, County Kildare
Registered Number: 308263


This e-mail and any attachments may contain confidential material for the sole
use of the intended recipient(s). Any review or distribution by others is
strictly prohibited. If you are not the intended recipient, please contact the
sender and delete all copies.
___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org


[coreboot] Regarding Intel CPU frequency.

2020-04-23 Thread nitin . ramesh . singh
Hi,

I am using coreboot to boot Denverton cpu (CPU C3558) based board.

I can see that the cpu frequency is set to the correct value i.e. "2200 Mhz" 
under the coreboot logs.
.
"
CPU #3 initialized
bsp_do_flight_plan done after 146 msecs.
cpu: frequency set to 2200
"

Later when I check the frequency reading under linux (kernel version 4.19) , It 
comes out as 800 Mz:

model name  : Intel(R) Atom(TM) CPU C3558 @ 2.20GHz
stepping: 1
microcode   : 0x24
cpu MHz : 800.000


When I reprogram the board with BIOS, the cpu frequency gets reflected 
correctly (i.e. 2200 MHz) with the same kernel image.

I have also tried out the different Grub command line options like disabling 
the pstate, and idle state e.t.c, but the end result remains same. 

Can anyone please provide me some suggestions. Is there is any cpu specific 
settings which needs to enabled under coreboot or with Intel-FSP ? 

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


[coreboot] Re: Memtest86+ stuck

2020-04-23 Thread Max Zim

On 23/04/2020 13:06, Krystian Hebel wrote:

Please try to apply the patch I did some time ago [1].
Unfortunately it does not work for me. I applied patch manually, 
switched back to the Stable Memtest86+ and ran `make clean && make`; 
memory test hanged at the same point. Checked twice.

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


[coreboot] Re: Memtest86+ stuck

2020-04-23 Thread Krystian Hebel

Hello,


Hello Max,

I discovered the issue with Memtest86+ stuck on my Thinkpad x230 on 
the very first tests. Always on the same point, 52%. Every release 
since 4.8 works this way, coreboot 4.7 works fine. Is this a known bug? 


Please try to apply the patch I did some time ago [1]. It is exactly the 
same issue I was having, except it hang at a different point IIRC.


The cause of this is that when Memtest86+ is run as a payload, it 
expects that the memory map provided in coreboot tables is correct. It 
isn't, as SeaBIOS modified it and didn't update the coreboot tables. 
However, it keeps track of used memory in E820 properly, so other 
Memtest86+ binaries (e.g. emulated floppy or file on a disk) work.


[1] 
https://mail.coreboot.org/hyperkitty/list/seab...@seabios.org/thread/Y4BLTEDDMKIF33H55O2GL73A7GLIEBVE/


Krystian Hebel
Firmware Engineer
https://3mdeb.com | @3mdeb_com

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


[coreboot] Re: Memtest86+ stuck

2020-04-23 Thread Paul Menzel

Dear Max,


Am 23.04.20 um 12:34 schrieb Max Zim:

On 23/04/2020 12:07, Paul Menzel wrote:


So, coreboot master with Memtest86+ Stable does *not* work. coreboot 
master with Memtest86+ Master *does* work?


Correct.


The Memtest86+ stable tag was changed to v002 in coreboot 4.10 in commit 
af15d040 (payloads/external/Memtest86Plus: update to version 002 stable) 
[1].


It’d be great, if you could bisect the commit, fixing this in 
Memtest86+’ master branch. There are less than 20 commits, so it should 
be really fast.


$ git log --oneline --reverse v002..origin/master
746c840 spd: refactor code for AMD SBx00 and FCH
aeb2c32 pci.c: Remove unneeded 'else'
a5c8cea dmi.c: Fix whitespace for conditional statements
80c4e48 controller: Remove dead assignment
e3cfbc0 spd.c: Remove dead assignment
d2519c0 Revert "spd.c: Remove dead assignment"
2182c5b Work around freeze if built with GCC8+ due to pointer overflow 
optimizations in test.c

09c630f Update Standard manufacturer’s ID code
07c9685 controller.c: Fix logical ‘or’ of equal expressions
a78401b spd.c: Remove dead assignment
fb07598 Memtest86+: Support for configuring console from LB_SERIAL entry
1e49025 Memtest86+: Replace serial accessor macros with inline functions
73ad6b3 Memtest86+: Refactor serial port code to reduce global variables
c6f27cc Memtest86+: Support MMIO serial ports
0b75625 (origin/master, origin/HEAD) Memtest86+: Fix typos

Afterward, we tag Memtest86+ v003, and use that as the new stable release.


Kind regards,

Paul


PS: By the way, Memtest86+ 5.31b was released [2].


[1]: https://review.coreboot.org/c/coreboot/+/32613
[2]: https://www.memtest.org/
___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org


[coreboot] Re: Memtest86+ stuck

2020-04-23 Thread Max Zim

On 23/04/2020 12:07, Paul Menzel wrote:

Ok, so you are using SeaBIOS as primary payload.


Correct.

So, coreboot master with Memtest86+ Stable does *not* work. coreboot 
master with Memtest86+ Master *does* work?


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


[coreboot] Re: Memtest86+ stuck

2020-04-23 Thread Paul Menzel

Dear Max,


Am 23.04.20 um 11:28 schrieb Max Zim:

On 23/04/2020 09:24, Paul Menzel wrote:

1.  How do you build the Memtest86+ payload?
2.  What version do you choose? I believe there is *Stable* and *Master*?


I just checked the box in the nconfig menu, so it should be Stable as 
defined in the coreboot's automated build flow.


Understood. No idea, if the stable tag changed between 4.7 and today.


3.  How do you start the Memtest86+ payload?


I'm pressing ESC and choose Memtest86+ from the payloads menu. I also 
checked the Debian's Memtest86+. It stuck on both "good" and "bad" 
coreboot.


Ok, so you are using SeaBIOS as primary payload.

If you add the Memtest86+ payload, which works with coreboot 4.7 to 
coreboot master, does it still work?


Yes. Workaround previously suggested by Lars Hochstetter also works. I 
also rebuilt coreboot with Memtest86+ from master, it also works fine 
while Debian's Memtest86+ still stuck.


Sorry, you lost me. Please give more details, so there is no room for 
ambiguity – especially when two programs and different versions are 
involved.


So, coreboot master with Memtest86+ Stable does *not* work. coreboot 
master with Memtest86+ Master *does* work?



Kind regards,

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


[coreboot] Re: Memtest86+ stuck

2020-04-23 Thread Max Zim

On 23/04/2020 09:24, Paul Menzel wrote:

1.  How do you build the Memtest86+ payload?
2.  What version do you choose? I believe there is *Stable* and *Master*?


I just checked the box in the nconfig menu, so it should be Stable as 
defined in the coreboot's automated build flow.



3.  How do you start the Memtest86+ payload?


I'm pressing ESC and choose Memtest86+ from the payloads menu. I also 
checked the Debian's Memtest86+. It stuck on both "good" and "bad" coreboot.


If you add the Memtest86+ payload, which works with coreboot 4.7 to 
coreboot master, does it still work?


Yes. Workaround previously suggested by Lars Hochstetter also works. I 
also rebuilt coreboot with Memtest86+ from master, it also works fine 
while Debian's Memtest86+ still stuck.

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


[coreboot] CBFS pointer problem with SeaBios and Apollo Lake platform

2020-04-23 Thread Wolfgang Kamp - datakamp
Hello,

Am I correct that the problem still exists that SeaBios can't find the CBFS in 
apl platform?

Kind regards,
Wolfgang Kamp
___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org


[coreboot] Re: Memtest86+ stuck

2020-04-23 Thread Paul Menzel

Dear Max,


Am 22.04.20 um 23:11 schrieb Max Zim:

I discovered the issue with Memtest86+ stuck on my Thinkpad x230 on the 
very first tests. Always on the same point, 52%. Every release since 4.8 
works this way, coreboot 4.7 works fine. Is this a known bug?


Thank you for your report. I cannot remember hearing/reading about that. 
Your report is lacking some details, so it’s unclear if it’s a 
regression in Memtest86+ or coreboot. It’d be great if you could answer 
the questions below.


1.  How do you build the Memtest86+ payload?
2.  What version do you choose? I believe there is *Stable* and *Master*?
3.  How do you start the Memtest86+ payload? I assume you have it as 
secondary payload, and select it from some primary payload 
(`fallback/payload` in CBFS)? Which one do you use?
4.  Payloads are actually interchangeable between coreboot versions. If 
you add the Memtest86+ payload, which works with coreboot 4.7 to 
coreboot master, does it still work?


Something like:

$ build/cbfstool path/to/coreboot-v4.7.rom extract -n 
img/memtest -f memtest-v4.7


And then for the master:

$ build/cbfstool path/to/coreboot-master.rom add-payload -n 
img/mtest-v4.7 -f memtest-v4.7 -c lzma


That way, we can figure out if it’s a regression in coreboot or 
Memtest86+.



Kind regards,

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