[coreboot] Re: Starting the coreboot 4.10 release process

[Matt DeVillier]

there is no "stable" branch for upstream edk2 though. Previously, coreboot
used an arbitrary commit as stable, and applied ~7 patches on top if it to
make it functional. Even the UDK201x branches don't boot without patches

On Sun, Jun 2, 2019 at 3:30 PM Lance Zhao  wrote:

> Tianocore master branch build from edk2 will break, but that had been
> quite some time. Stable branch is working fine though.
>
> On Mon, Jun 3, 2019, 3:28 AM Matt DeVillier 
> wrote:
>
>> On Sun, Jun 2, 2019 at 1:27 PM Mike Banon  wrote:
>>
>>>
>>> Also, regarding the significant changes: " ### Tianocore UEFI
>>> integrated as payload " . I hope it doesn't mean that Tianocore will
>>> become the default payload, since there are ideological/technical
>>> reasons against this ( I think there's a significant overlap between
>>> the groups of people who love / interested in coreboot and hate UEFI )
>>>
>>
>> the change could be reworded better I think: instead of the stable tag
>> for Tianocore being pulled from the upstream edk2 github repo and a series
>> of patches applied, it's now pulled directly from my fork/repo, which is
>> actually functional on most (x86_64) devices. A few tweaks (like
>> customizable boot splash) were added as well.
>>
>> there is no change to the default payload, only to the defaults for
>> Tianocore
>> ___
>> 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: Starting the coreboot 4.10 release process

[Lance Zhao]

Tianocore master branch build from edk2 will break, but that had been quite
some time. Stable branch is working fine though.

On Mon, Jun 3, 2019, 3:28 AM Matt DeVillier 
wrote:

> On Sun, Jun 2, 2019 at 1:27 PM Mike Banon  wrote:
>
>>
>> Also, regarding the significant changes: " ### Tianocore UEFI
>> integrated as payload " . I hope it doesn't mean that Tianocore will
>> become the default payload, since there are ideological/technical
>> reasons against this ( I think there's a significant overlap between
>> the groups of people who love / interested in coreboot and hate UEFI )
>>
>
> the change could be reworded better I think: instead of the stable tag for
> Tianocore being pulled from the upstream edk2 github repo and a series of
> patches applied, it's now pulled directly from my fork/repo, which is
> actually functional on most (x86_64) devices. A few tweaks (like
> customizable boot splash) were added as well.
>
> there is no change to the default payload, only to the defaults for
> Tianocore
> ___
> 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: Starting the coreboot 4.10 release process

[Evgeny Zinoviev via coreboot]

Your plan worked, I've just uploaded board status for 4 more boards.

On 6/2/19 9:26 PM, Mike Banon wrote:
> I've just added a "Recently tested mainboards:" section to the end of
> https://piratenpad.de/p/coreboot4.10-release-checklist . I think its'
> existence could encourage the people to submit a board status report
> for their board, to increase its' visibility and attract more
> potential users/developers who'll read these release notes at some
> opensource-dedicated websites and may become interested at coreboot
> project. This section includes 6 laptops and 2 desktops for which the
> board status reports have been submitted during May and the beginning
> of June. Luckily 4.10 release is not there yet, so the people still
> have some time to submit a fresh board status for their board and then
> it could be included to this list.
>
> Also, regarding the significant changes: " ### Tianocore UEFI
> integrated as payload " . I hope it doesn't mean that Tianocore will
> become the default payload, since there are ideological/technical
> reasons against this ( I think there's a significant overlap between
> the groups of people who love / interested in coreboot and hate UEFI )
>
> Recently tested mainboards:
> ---
> * Lenovo Ideapad G505S
> * Lenovo Thinkpad T400
> * Lenovo Thinkpad T430
> * Lenovo Thinkpad T430s baseboard
> * Lenovo Thinkpad X131e Chromebook
> * Lenovo Thinkpad X230
> * Gigabyte GA-B75M-D3H
> * Asrock E350M1
>
> On Fri, May 10, 2019 at 11:17 PM Patrick Georgi via coreboot
>  wrote:
>> Hi everybody,
>>
>> with this mail I'm officially starting the 4.10 release process.
>> As per the first step of our checklist 
>> (Documentation/releases/checklist.md), I hereby announce the intent to 
>> release coreboot 4.10 in about 2 weeks. I'm aiming for May 28th to avoid 
>> releasing into the weekend or on Memorial Day in the US, but I'll likely 
>> lock down the commit we'll designate 4.10 during those days to give some 
>> room for testing.
>>
>> I created a copy of the checklist on 
>> https://piratenpad.de/p/coreboot4.10-release-checklist, also including the 
>> current state of the 4.10 release notes.
>>
>> Please test the boards you have around and provide fixes, please be careful 
>> with intrusive changes (and maybe postpone them until after the release) and 
>> please update the release notes 
>> (Documentation/releases/coreboot-4.10-relnotes.md or near the bottom of the 
>> etherpad doc, I'll carry them over into our git repo then).
>>
>> As promised with the 4.9 release there won't be deprecations after 4.10. 
>> However we need to finalize our set of deprecations we want to announce with 
>> 4.10 that will happen after the 4.11 release (those also belong in the 
>> release notes).
>>
>>
>> Regards,
>> Patrick
>> --
>> 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 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: Starting the coreboot 4.10 release process

[Matt DeVillier]

On Sun, Jun 2, 2019 at 1:27 PM Mike Banon  wrote:

>
> Also, regarding the significant changes: " ### Tianocore UEFI
> integrated as payload " . I hope it doesn't mean that Tianocore will
> become the default payload, since there are ideological/technical
> reasons against this ( I think there's a significant overlap between
> the groups of people who love / interested in coreboot and hate UEFI )
>

the change could be reworded better I think: instead of the stable tag for
Tianocore being pulled from the upstream edk2 github repo and a series of
patches applied, it's now pulled directly from my fork/repo, which is
actually functional on most (x86_64) devices. A few tweaks (like
customizable boot splash) were added as well.

there is no change to the default payload, only to the defaults for
Tianocore
___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] Re: Starting the coreboot 4.10 release process

[Mike Banon]

I've just added a "Recently tested mainboards:" section to the end of
https://piratenpad.de/p/coreboot4.10-release-checklist . I think its'
existence could encourage the people to submit a board status report
for their board, to increase its' visibility and attract more
potential users/developers who'll read these release notes at some
opensource-dedicated websites and may become interested at coreboot
project. This section includes 6 laptops and 2 desktops for which the
board status reports have been submitted during May and the beginning
of June. Luckily 4.10 release is not there yet, so the people still
have some time to submit a fresh board status for their board and then
it could be included to this list.

Also, regarding the significant changes: " ### Tianocore UEFI
integrated as payload " . I hope it doesn't mean that Tianocore will
become the default payload, since there are ideological/technical
reasons against this ( I think there's a significant overlap between
the groups of people who love / interested in coreboot and hate UEFI )

Recently tested mainboards:
---
* Lenovo Ideapad G505S
* Lenovo Thinkpad T400
* Lenovo Thinkpad T430
* Lenovo Thinkpad T430s baseboard
* Lenovo Thinkpad X131e Chromebook
* Lenovo Thinkpad X230
* Gigabyte GA-B75M-D3H
* Asrock E350M1

On Fri, May 10, 2019 at 11:17 PM Patrick Georgi via coreboot
 wrote:
>
> Hi everybody,
>
> with this mail I'm officially starting the 4.10 release process.
> As per the first step of our checklist (Documentation/releases/checklist.md), 
> I hereby announce the intent to release coreboot 4.10 in about 2 weeks. I'm 
> aiming for May 28th to avoid releasing into the weekend or on Memorial Day in 
> the US, but I'll likely lock down the commit we'll designate 4.10 during 
> those days to give some room for testing.
>
> I created a copy of the checklist on 
> https://piratenpad.de/p/coreboot4.10-release-checklist, also including the 
> current state of the 4.10 release notes.
>
> Please test the boards you have around and provide fixes, please be careful 
> with intrusive changes (and maybe postpone them until after the release) and 
> please update the release notes 
> (Documentation/releases/coreboot-4.10-relnotes.md or near the bottom of the 
> etherpad doc, I'll carry them over into our git repo then).
>
> As promised with the 4.9 release there won't be deprecations after 4.10. 
> However we need to finalize our set of deprecations we want to announce with 
> 4.10 that will happen after the 4.11 release (those also belong in the 
> release notes).
>
>
> Regards,
> Patrick
> --
> 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 mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] Re: ASUS KCMA-D8 RAM issues

[up6IfzRzvQCyv9AK4XvYirxDa8 via coreboot]

Hi guys,

thank you for the valuable feedbacks. As I can see from the git commits, it was 
mainly Timothy Pearson from Raptor Engineering Inc who worked on the kcma-d8 
porting. Libreboot is based on some version of coreboot 4.6. But it seems that 
after that a number of RAM related commits has been done,like e.g. this:

commit 99e27ceb6d913a7a882cc6e7277b881df38dc9ad
Author: Timothy Pearson 
Date:   Sun Apr 24 20:33:29 2016 -0500

mainboard/kgpe-d16|kcma-d8: Update memory test to include second PRNG stage

The existing memory test routine was insufficient to detect certain types
of bus instability related to multiple incompatible RDIMMs on one channel.

Add a PRNG second stage test to the memory test routine.  This second stage
test reliably detects faults in memory setup for RDIMM configurations that
also fail under the proprietary BIOS.

Change-Id: I44721447ce4c2b728d4a8f328ad1a3eb8f324d3d
Signed-off-by: Timothy Pearson 
Reviewed-on: https://review.coreboot.org/14502
Tested-by: build bot (Jenkins)
Tested-by: Raptor Engineering Automated Test Stand 

Reviewed-by: Martin Roth 


Can someone confirm that the latest libreboot on the kcma-d8 is stable, so that 
the effort of the commit 'dichotomy' will be worth it. This means basically
to roll back the commits for the kcma-d8 that has been done since the libreboot 
fork.

Another approach would be to figure out why only very few RAM modules are 
supported. I can offer test support, but the analysis exceeds my knowledge and
skills in this area.

Regards



‐‐‐ Original Message ‐‐‐
On Saturday, June 1, 2019 6:29 PM, Mike Banon  wrote:

> > Why libreboot works and coreboot doesn't?
>
> Libreboot is some older version of coreboot where all the blobs have
> been removed. If something works at libreboot but doesn't work at
> coreboot, most likely that means there was a breaking commit at
> coreboot which came later than a libreboot release (and, like the rest
> of new commits, this breaking commit is going to be inherited by
> libreboot in its' next release). When you encounter such a situation,
> you should do a commit dichotomy to find out which commit broke the
> things and report it, so that maybe it would be reverted or improved
> and then the things should become working for you in the latest
> coreboot master. Good luck
>
> On Sat, Jun 1, 2019 at 9:28 AM Sean Lynn Rhone espionage...@posteo.net wrote:
>
> > For non-ECC modules on the KCMA-D8, I found that Samsung M378B5273CH0-
> > CK0, Micron 16JTF25664AZ-1G4F1, and Nanya NT2GC64B88B0NF-CG work with
> > Coreboot.
> > I also had SK Hynix HMT151R7BFR4C-H9 which didn't work with Coreboot,
> > but worked on Libreboot. Samsung M393B5270CH0-CH9 also doesn't work
> > with Coreboot.
> > On Fri, 2019-05-31 at 10:00 +, up6IfzRzvQCyv9AK4XvYirxDa8 via
> > coreboot wrote:
> >
> > > There are also differences between 42xx and 42xx/43xx. Below a
> > > logfile of coreboot 4.9 with 4225 and 4180.
> > > Test with 4365 + coreboot 4.9 and 1x M391B1G73BH0-CK0 in the Slot A2
> > > and 1x CPU. The same configuration but with the HMT325U7BFR8A
> > > (recommended by raptorengineering.com) works. I t
> >
> > 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] linux kernel > 4.9 hang at boot on ASUS KGPE-D16

[Kinky Nekoboi]

After upgrading my Debian Stretch installation to Buster, i experienced
this behaviour.

acpi=off lets the kernel boot, but the system is still unusable as some
controller do not work correctly.

So i guess its something ACPI related.

Also wrote an bugreport to debian.

I can not give any usable debug output as the kernel hangs before giving
any output.


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

[coreboot] Re: Fwd: Re: ASUS KGPE-D16 ECC disabled by default

[Kinky Nekoboi]

Yes exactly.

I still have to give the amd64_edac module an force Option to be enabled.

Am 01.06.19 um 18:17 schrieb Matt B:
>
>
> -- Forwarded message -
> From: *Matt B*  >
> Date: Sat, Jun 1, 2019 at 12:17 PM
> Subject: Re: [coreboot] Re: ASUS KGPE-D16 ECC disabled by default
> To: Kinky Nekoboi 
>
>
> Hi,
>
> So configuring ECC to be on by default in nvram has no effect?
>
> Sincerely,
>     -Matt
>
> On Sat, Jun 1, 2019 at 11:08 AM Kinky Nekoboi
>  wrote:
>
> OK i flashed a recompiled version with nvram options enabled.
>
> ECC is enabled by default:
> boot_option = Fallback
> reboot_counter = 0x0
> interleave_chip_selects = Enable
> interleave_nodes = Disable
> interleave_memory_channels = Enable
> max_mem_clock = DDR3-1600
> multi_core = Enable
> debug_level = Debug
> ecc_scrub_rate = 1.28us
> slow_cpu = off
> nmi = Disable
> gart = Enable
> power_on_after_fail = On
> ECC_memory = Enable
> ECC_redirection = Enable
> hypertransport_speed_limit = Auto
> minimum_memory_voltage = 1.5V
> compute_unit_siblings = Enable
> cpu_c_states = Enable
> cpu_cc6_state = Enable
> sata_ahci_mode = Enable
> sata_alpm = Disable
> dimm_spd_checksum = Enforce
> probe_filter = Auto
> l3_cache_partitioning = Disable
> ieee1394_controller = Enable
> iommu = Enable
> cpu_core_boost = Enable
> ehci_async_data_cache = Enable
> experimental_memory_speed_boost = Disable
> maximum_p_state_limit = 0xf
>
> Still i need to force the kernel to enable ECC.
>
> Am 01.06.19 um 14:10 schrieb Kinky Nekoboi:
>> Hello everybody, i just setup an ASUS KGPE-D16 with coreboot in my
>> fileserver today.
>>
>> CPU: Opteron 6380 with newest microcode loaded in coreboot
>>
>> 1x 8GB Hynix DDR3 ECC
>>
>> 1x 8GB Samsung DDR3 ECC
>>
>> ECC works after you force the linux kernel / the amd_edac module to
>> enable ECC as you can see on this dmesg output :
>>
>> root@lain:~# dmesg | grep -i edac
>> [   44.487132] EDAC MC: Ver: 3.0.0
>> [   44.520632] EDAC amd64: DRAM ECC disabled.
>> [   44.520670] EDAC amd64: ECC disabled in the BIOS or no ECC
>> capability, module will not load.
>> [   44.520670] EDAC amd64: Forcing ECC on!
>> [   44.520747] EDAC amd64: DRAM ECC disabled on this node, enabling...
>> [   44.520749] EDAC amd64: Hardware accepted DRAM ECC Enable
>> [   44.520750] EDAC amd64: F15h detected (node 0).
>> [   44.520802] EDAC MC: DCT0 chip selects:
>> [   44.520804] EDAC amd64: MC: 0: 0MB 1: 0MB
>> [   44.520805] EDAC amd64: MC: 2: 0MB 3: 0MB
>> [   44.520806] EDAC amd64: MC: 4: 0MB 5: 0MB
>> [   44.520807] EDAC amd64: MC: 6: 0MB 7: 0MB
>> [   44.520808] EDAC MC: DCT1 chip selects:
>> [   44.520809] EDAC amd64: MC: 0: 0MB 1: 0MB
>> [   44.520810] EDAC amd64: MC: 2: 0MB 3: 0MB
>> [   44.520811] EDAC amd64: MC: 4: 0MB 5: 0MB
>> [   44.520812] EDAC amd64: MC: 6: 0MB 7: 0MB
>> [   44.520813] EDAC amd64: using x4 syndromes.
>> [   44.520813] EDAC amd64: MCT channel count: 0
>> [   44.520903] EDAC MC0: Giving out device to module amd64_edac
>> controller F15h: DEV :00:18.2 (INTERRUPT)
>> [   44.520904] EDAC amd64: DRAM ECC enabled.
>> [   44.520916] EDAC amd64: F15h detected (node 1).
>> [   44.520958] EDAC MC: DCT0 chip selects:
>> [   44.520959] EDAC amd64: MC: 0: 0MB 1: 0MB
>> [   44.520961] EDAC amd64: MC: 2:  4096MB 3:  4096MB
>> [   44.520962] EDAC amd64: MC: 4: 0MB 5: 0MB
>> [   44.520963] EDAC amd64: MC: 6: 0MB 7: 0MB
>> [   44.520964] EDAC MC: DCT1 chip selects:
>> [   44.520965] EDAC amd64: MC: 0: 0MB 1: 0MB
>> [   44.520966] EDAC amd64: MC: 2:  4096MB 3:  4096MB
>> [   44.520967] EDAC amd64: MC: 4: 0MB 5: 0MB
>> [   44.520968] EDAC amd64: MC: 6: 0MB 7: 0MB
>> [   44.520969] EDAC amd64: using x4 syndromes.
>> [   44.520969] EDAC amd64: MCT channel count: 2
>> [   44.521294] EDAC MC1: Giving out device to module amd64_edac
>> controller F15h: DEV :00:19.2 (INTERRUPT)
>> [   44.521313] EDAC PCI0: Giving out device to module amd64_edac
>> controller EDAC PCI controller: DEV :00:18.2 (POLLED)
>> [   44.521314] AMD64 EDAC driver v3.4.0
>>
>> Is there an NVRAM Option for ECC and should i rebuild coreboot with
>> nvram options enabled ?
>>
>> best regards
>>
>> kinky_nekoboi
>>
>>
>>
>> ___
>> coreboot mailing list -- coreboot@coreboot.org 
>> 
>> To unsubscribe send an email to coreboot-le...@coreboot.org 
>> 
> ___
> coreboot mailing list --