[coreboot] Re: linux boot failure on 440bx/i82371eb [asus/p2b & p2-99] after [acpi/acpi.c: Reduce boilerplate] change

[Kyösti Mälkki]

Hi

The mentioned board asus/p2b falls into a rare category of mainboards from
around 1999 (?) when discrete southbridge silicon did not implement an
IOAPIC. There is a hint in sb/intel/i82371eb/isa.c about enabling IOAPIC as
a discrete component for SMP configurations.

One thing I notice is that a failing boot sees ACPI table entry APIC
present, yet it is without any LAPIC entries. At least the following line
seems to disappear, diffing against a log that reaches login prompt:
[0.858042] APIC: Switch to virtual wire mode setup with no configuration

I did not check the details for the kernel message yet, one definition of
the term "virtual wire" is the connection of a legacy PIC 8259 and the
"local interrupt" pin of the LAPIC. Appears as if kernel would skip said
virtual wire configuration now. Not getting interrupts would likely raise
timeouts on IDE DMA.

Kyösti


On Tue, Aug 22, 2023 at 8:07 AM Branden Waldner  wrote:

> Hi Keith Hui & list
>
> I just recently tested the latest coreboot ahead of the upcoming
> release and found that there had been a regression that broke [linux]
> booting with the disk controller timing out on the asus p2b.
>
> It broke with change 76127 [1] and was improved, but not fixed by 76321
> [2].
>
> Initially after the change it would hang at:
> "Write protecting kernel text and read-only data
> Run /init as init process"
>
> With the DSDT fix it would make it past there, but be unable to access
> the ide drive with the root filesystem.
>
> I haven't been able to look in to it much and don't know anything
> about acpi anyways, but I figured I would at least make sure to post
> logs.
>
> I might still be able to get it booted through usb or a pci ide/sata
> controller, but I haven't tried it, though it would probably help to
> get more diagnostic info.
>
>
> Branden Waldner
>
> [1] acpi/acpi.c: Reduce boilerplate
> https://review.coreboot.org/c/coreboot/+/76127
> [2] acpi/acpi.c: Fix regression with DSDT
> https://review.coreboot.org/c/coreboot/+/76321
> ___
> 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: Supermicro X11SSH-LN4F PCI-e bifurcation?

[Kyösti Mälkki]

On Tue, Apr 11, 2023 at 11:10 PM Tomas  wrote:
>
> Hi,
> I installed Coreboot with SeaBIOS on a Supermicro X11SSH-LN4F.
> The stock BIOS can read two NVMe drives in a Dual m.2 splitter card inserted 
> in the middle slot 5 on the motherboard.
> But coreboot can not. In the coreboot nconfig menu there is no setting that 
> will enable bifurcation of the x8 slot to x4x4.
>
> Is this something that is configurable in any way?
>
HI Tomas

The patch below might give you directions or ideas.

I don't have the hardware in question, so mostly guessing based on the
comments in the file. If you have lspci output from OEM boot, it could
help.

Kyösti
commit 12e9004e02a6f7225e5147e2e13483315a2b3b05
Author: Kyösti Mälkki 
Date:   Thu Apr 13 10:09:26 2023 +0300

test-supermicro

diff --git a/src/mainboard/supermicro/x11-lga1151-series/variants/x11ssh-f/overridetree.cb b/src/mainboard/supermicro/x11-lga1151-series/variants/x11ssh-f/overridetree.cb
index 35825f8630..b223e1e794 100644
--- a/src/mainboard/supermicro/x11-lga1151-series/variants/x11ssh-f/overridetree.cb
+++ b/src/mainboard/supermicro/x11-lga1151-series/variants/x11ssh-f/overridetree.cb
@@ -56,7 +56,12 @@ chip soc/intel/skylake
 			smbios_slot_desc "SlotTypePciExpressGen3X16" "SlotLengthShort" "CPU SLOT6 PCI-E 3.0 X8(IN X16)" "SlotDataBusWidth8X"
 		end			# CPU PCIE Slot (JPCIE3)
 		device pci 01.1 on	# CPU PCIE Slot (JPCIE2)
-			smbios_slot_desc "SlotTypePciExpressGen3X8" "SlotLengthShort" "CPU SLOT6 PCI-E 3.0 X8" "SlotDataBusWidth8X"
+			register "Peg1MaxLinkWidth" = "Peg1_x4"
+			smbios_slot_desc "SlotTypePciExpressGen3X4" "SlotLengthShort" "CPU SLOT5-0 PCI-E 3.0 X4" "SlotDataBusWidth4X"
+		end
+		device pci 01.2 on	# CPU PCIE Slot (JPCIE2)
+			register "Peg2MaxLinkWidth" = "Peg2_x4"
+			smbios_slot_desc "SlotTypePciExpressGen3X4" "SlotLengthShort" "CPU SLOT5-1 PCI-E 3.0 X4" "SlotDataBusWidth4X"
 		end
 		device pci 02.0 on end	# Integrated Graphics Device (No Output)
 		device pci 1c.0 on	# PCI Express Port 1
___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] [coreboot - Bug #388] (Resolved) denverton_ns: crash when starting postcar

[Kyösti Mälkki]

Issue #388 has been updated by Kyösti Mälkki.



Status changed from New to Resolved





Bug #388: denverton_ns: crash when starting postcar

https://ticket.coreboot.org/issues/388#change-1041



* Author: King Sumo

* Status: Resolved

* Priority: Normal

* Assignee: Arthur Heymans

* Category: board support

* Target version: master

* Start date: 2022-06-15

* Affected versions: 4.17, master

* Affected hardware: intel harcuvar

* Affected OS: all



Postcar is crashing when using configured to teardown the CAR using FSP.

Therefore the bug may occur in other platforms than denverton as well.

See also the discussion here: 
https://mail.coreboot.org/hyperkitty/list/coreboot@coreboot.org/thread/2JC3GNJSGXUD6DRVUY7O2O3W6OM3E2MY/

The bug was instroduced by the following change:

* 5315e96abf arch/x86/postcar: Use a separate stack for C execution

Attached is a patch with the bug fix.



---Files

fix-postcar-crash.patch (822 Bytes)





-- 

You have received this notification because you have either subscribed to it, 
or are involved in it.

To change your notification preferences, please click here: 
https://ticket.coreboot.org/my/account

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

[coreboot] [coreboot - Bug #386] ASUS P8Z77-V LX2 - Raminit issue at second boot with two 8GiB DIMMs - bootloop

[Kyösti Mälkki]

Issue #386 has been updated by Kyösti Mälkki.





> I build coreboot today for the ASUS P8Z77-V LX2 and used the latest coreboot 
> master code.

> 

> The 2 8GiB DIMMs are working fine at first boot.



I think only 8 GiB of RAM was available at first boot.



One of the DIMMs has SPD CRC error, and while they have matching part number, 
timing parameters are different.



[DEBUG]  SPD probe channel1, slot1

[DEBUG]  ERROR: SPD CRC failed!!!









Bug #386: ASUS P8Z77-V LX2 - Raminit issue at second boot with two 8GiB DIMMs - 
bootloop

https://ticket.coreboot.org/issues/386#change-947



* Author: gzz5f gzz5f

* Status: New

* Priority: High

* Category: board support

* Target version: master

* Start date: 2022-06-05

* Affected versions: master

* Needs backport to: none

* Affected hardware: ASUS P8Z77-V LX2

* Affected OS: all



I build coreboot today for the ASUS P8Z77-V LX2 and used the latest coreboot 
master code.



The 2 8GiB DIMMs are working fine at first boot. You can start computer, 
install from a live media the OS and so on. But at the second boot it failes 
boot forever and its bootooping. It does not make a change if i boot for a 
second until SeaBIOS output and then turn off the computer or use the computer 
for longer time. The second boot is always broken.

Workaround 1: Remove one of the two 8GiB DIMMs. Then the computer also starts 
fine after a reboot.

Workaround 2: Install two 4GiB DIMMs instead of two 8GiB DIMMs. Then the 
computer also starts fine after reboot.

Workaround 3: At every boot boot for a second with one DIMM. Turn off the 
computer, insert the second DIMM and start it again.



kmalkki told me to rebuid the image with DEBUG_RAM_SETUP=y



I then build a second image, with DEBUG_RAM_SETUP=y.

The logfile contains the first successfull boot (created with Workaround 3), 
the poweroff and the poweron with the bootloop. I have let it bootloop few 
times before turned off the PSU.





---Files

coreboot_logfie.txt (197 KB)

coreboot_logfile_cleaned.txt (160 KB)





-- 

You have received this notification because you have either subscribed to it, 
or are involved in it.

To change your notification preferences, please click here: 
https://ticket.coreboot.org/my/account

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

[coreboot] [coreboot - Bug #386] ASUS P8Z77-V LX2 - Raminit issue at second boot with two 8GiB DIMMs - bootloop

[Kyösti Mälkki]

Issue #386 has been updated by Kyösti Mälkki.



File coreboot_logfile_cleaned.txt added





Bug #386: ASUS P8Z77-V LX2 - Raminit issue at second boot with two 8GiB DIMMs - 
bootloop

https://ticket.coreboot.org/issues/386#change-946



* Author: gzz5f gzz5f

* Status: New

* Priority: High

* Category: board support

* Target version: master

* Start date: 2022-06-05

* Affected versions: master

* Needs backport to: none

* Affected hardware: ASUS P8Z77-V LX2

* Affected OS: all



I build coreboot today for the ASUS P8Z77-V LX2 and used the latest coreboot 
master code.



The 2 8GiB DIMMs are working fine at first boot. You can start computer, 
install from a live media the OS and so on. But at the second boot it failes 
boot forever and its bootooping. It does not make a change if i boot for a 
second until SeaBIOS output and then turn off the computer or use the computer 
for longer time. The second boot is always broken.

Workaround 1: Remove one of the two 8GiB DIMMs. Then the computer also starts 
fine after a reboot.

Workaround 2: Install two 4GiB DIMMs instead of two 8GiB DIMMs. Then the 
computer also starts fine after reboot.

Workaround 3: At every boot boot for a second with one DIMM. Turn off the 
computer, insert the second DIMM and start it again.



kmalkki told me to rebuid the image with DEBUG_RAM_SETUP=y



I then build a second image, with DEBUG_RAM_SETUP=y.

The logfile contains the first successfull boot (created with Workaround 3), 
the poweroff and the poweron with the bootloop. I have let it bootloop few 
times before turned off the PSU.





---Files

coreboot_logfie.txt (197 KB)

coreboot_logfile_cleaned.txt (160 KB)





-- 

You have received this notification because you have either subscribed to it, 
or are involved in it.

To change your notification preferences, please click here: 
https://ticket.coreboot.org/my/account

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

[coreboot] Re: asus p2b logs - change: cpu/x86/lapic: Move LAPIC configuration to MP init

[Kyösti Mälkki]

On Wed, Feb 9, 2022 at 8:06 PM Branden Waldner  wrote:
>
> With https://review.coreboot.org/c/coreboot/+/58387 merged, my p2b
> board hangs at seabios.
> I've attached serial logs from a rom of this commit and the previous one.
>

Sorry about that, I posted comments on the commit referenced above.

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

[coreboot] Re: 915G support

[Kyösti Mälkki]

On Mon, Dec 20, 2021 at 9:35 AM Kyösti Mälkki  wrote:
>
> On Fri, Dec 17, 2021 at 9:40 AM Nico Huber  wrote:
> >
> > Hi,
> >
> > On 15.12.21 14:25, Sid_key wrote:
> > > Hello, is 915G supported?
> >
> > alas not, and it never was, AFAICT. i945 is supported and i855 was once.
>
> I think I did a lot of the SerialICE development with 915G back in
> 2013(?).  in serialice tree you can find some support files for
> Commell LV-672 and MSI MS-7133. I believe I had one or both of them
> reach payload with coreboot, but I don't remember ever publishing that
> work. I can check if I have those repositories somewhere in my
> backups.

Hi, sorry for the delays.

The work is on three branches, i915-build, ich6-build and commell-build.
https://github.com/kmalkki/coreboot

From what I recall, booting-last-image branch was able to reach
payload, but no guarantees about that. It was probably only ever
tested with one type of a DIMM.

I did find bunch of serialice logs, but no coreboot console logs.

Regards,
Kyösti
___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] Re: 915G support

[Kyösti Mälkki]

On Fri, Dec 17, 2021 at 9:40 AM Nico Huber  wrote:
>
> Hi,
>
> On 15.12.21 14:25, Sid_key wrote:
> > Hello, is 915G supported?
>
> alas not, and it never was, AFAICT. i945 is supported and i855 was once.

I think I did a lot of the SerialICE development with 915G back in
2013(?).  in serialice tree you can find some support files for
Commell LV-672 and MSI MS-7133. I believe I had one or both of them
reach payload with coreboot, but I don't remember ever publishing that
work. I can check if I have those repositories somewhere in my
backups.

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

[coreboot] Re: Suggestion for deprecation: LEGACY_SMP_INIT & RESOURCE_ALLOCATOR_V3

[Kyösti Mälkki]

On Thu, Nov 25, 2021 at 9:50 PM Angel Pons  wrote:
>
> TL;DR: The deprecation notice is a call for action. Please stop
> complaining about it, let's work on a solution instead. Especially
> when https://review.coreboot.org/q/topic:amd_resource_allocator_v4
> already exists, which implements some of the required changes.
>

Thanks for your thoughts, Angel.

Seems like my first contribution to coreboot just reached the age of 10 years.

commit 521d8c25734dcfd38fa2e17a416e587fccb96080
Author: Kyösti Mälkki 
Date:   Mon Oct 17 17:10:03 2011 +0300

Activate older Xeon P4 microcodes

This was for one of the boards on the deprecation list,
aopen/dxplplusu. No SPI flash, ASEG SMM (TSEG available), no
compulsory SMI_HANDLER, no PCI MMCONFIG (now ECAM). CPU without
x86_64, only 34bit PAE, somewhat complex CAR bringup, 2 power-hungry
socketed P4 Xeon CPUs. No PCIe, some PCI-X slots, DDR1 with ECC,
Parallel ATA no SATA. I think I have touched the chipset support maybe
3 times in the last 5 years --- still boots with iPXE to iSCSI root.
It is likely to survive this deprecation of LEGACY_SMP_INIT too. I
think OEM BIOS had a date like from 2005.


For a contributor I find competent and interested enough, I might
offer some of the following AGESA boards as a donation:
 * lippert/frontrunner-af (fam14 liano?)
 * gizmosphere/gizmo (fam14 liano?)
 * pcengines/apu1 (fam14 liano?)
 * amd/olivehill (fam16 kabini)
 * asrock/imb-a180  (fam16 kabini)
 * lenovo/g505s  (fam15 trinity/richland)
 * ibase/i595f (fam15 trinity/richland, reaches payload with serial
console, not really ported)

Contact me privately to discuss terms and possible shipment. I may not
be able to provide much documentation, many I have are NDA'd.

AFAICS master and release 4.15 are in a booting condition for all the
above with allocator V3. Like with C_ENV_BOOTBLOCK (previous valid and
sensible deprecation reason) I can participate with the review
progress. If I remember correctly, it was you Mike B. and Michal Z.
who did most of the legwork then. I feel I have personally contributed
enough with little returned value to AGESA, but a lot of
soc/amd/common should be reusable for TSEG, PARALLEL_MP and also
cleaner SPI Flash write support and MRC_WR_CACHE (fam16kb). There may
still be a lot of assumptions of HyperTransport and multiple CPU
sockets under nb/ that should be cleaned too.

From experience, I can tell having parallel implementations for a
single task is both a development headache with lots of preprocessor
guards involved, and slows down the review process a lot. From what I
remember allocator V3 does not play well with large graphics
framebuffers or 64bit resources in general and I feel it's time to let
it go. Also, feel free to study the history of deprecations and
imagine what the tree would look like if we still allowed things like
a static allocation for CBMEM done late in ramstage, or optional
choice of CAR_MIGRATION or ROMCC. As I see it, forced deprecation is
the only means to wake up the small group of people who are competent
enough to take on a task like PARALLEL_MP migration, but are mostly
just waiting for someone else to volunteer first. Maybe with some luck
they provide feedback by testing builds when requested, often feedback
arrives 6 months later revealing something broken.

My ballpark estimation is a total of less than 100hours of
contributors' time to migrate AGESA platform codes to avoid
deprecation. Shared between five people who know what they are doing,
it is very much doable within a month.

Kind regards,
Kyösti Mälkki
___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] Re: Atomic Accesses to Local APIC

[Kyösti Mälkki]

On Mon, Oct 4, 2021 at 8:12 PM Julian Stecklina
 wrote:
>
> The X86_GOOD_APIC was set in the past in a few configs. You can find them via:
>
> git log -S GOOD_APIC --source --all
>
> The define itself was finally removed in:
>
> commit fc57d6c4c2848726be1361f6dee3c33e7551b857
> Author: Patrick Rudolph 
> Date:   Tue Nov 12 16:30:14 2019 +0100
>
> cpu/x86/lapic: Support x86_64 and clean up code
>
> From then on all APICs were "bad".
>
> But it looks like the workaround was just carried forward with no discussion 
> of
> whether it's still necessary or what it actually works around.
>

Hi

Removal has been suggested with the X2APIC work:

https://review.coreboot.org/c/coreboot/+/55199

Regards,
Kyösti
___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] Re: Resource allocator v3

[Kyösti Mälkki]

On Wed, Apr 28, 2021 at 3:17 PM Michal Zygowski
 wrote:
>
> Hi Kyösti,
>
> On 28.04.2021 12:33, Kyösti Mälkki wrote:
> > Hi
> >
> > According to Documentation/releases/coreboot-4.14-relnotes.md we are
> > expecting following chipset deprecations due to RESOURCE_ALLOCATOR_V3:
> >
> > * northbridge/amd/pi/00630F01
> > * northbridge/amd/pi/00730F01
> > * northbridge/amd/pi/00660F01 (already removed)
> > * northbridge/amd/agesa/family14
> > * northbridge/amd/agesa/family15tn
> > * northbridge/amd/agesa/family16kb
> >
> > Any progress or any interest to get these fixed?
> Working on northbridge/amd/pi/00630F01 and
> northbridge/amd/agesa/family14 in particular right now. Hope to upload
> the patches soon. Struggling with the SeaBIOS right now which doesn't
> seem to see any content behind BARs of peripheral controllers and PCIe
> devices after switching to allocator v4. Any hints?
>

Not really. The deprecation was announced May 2020 but I have not
witnessed any real progress in form of code merges in upstream at
least. And the conversion was advertised as easier than dropping
ROMCC. So I mostly came to check if someone had earmarked donations on
the topic, and if things were stuck with the bureaucracy.

I still have following to test and develop with:
* lippert/frontrunner-af, gizmosphere/gizmo, pcengines/apu1
* lenovo/g505s, ibase/mi959f (not published)
* amd/olivehill, asrock/imb-a180
* pcengines/apu{2,3}

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

[coreboot] Resource allocator v3

[Kyösti Mälkki]

Hi

According to Documentation/releases/coreboot-4.14-relnotes.md we are
expecting following chipset deprecations due to RESOURCE_ALLOCATOR_V3:

* northbridge/amd/pi/00630F01
* northbridge/amd/pi/00730F01
* northbridge/amd/pi/00660F01 (already removed)
* northbridge/amd/agesa/family14
* northbridge/amd/agesa/family15tn
* northbridge/amd/agesa/family16kb

Any progress or any interest to get these fixed?

Regards,
Kyösti
___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] [RFC] Whether to drop Kconfig option TRACE

[Kyösti Mälkki]

Hi

Looks like option TRACE=y would need either someone to make it usable
again or have it face removal.

I did not really try the feature either, but it appears it would log
function entry point addresses after relocation, which makes them not
helpful at all. Having it enabled also blocks some functions from
being inlined and evaluated to false at build time, this again makes
some configurations fail due to unresolved symbols [1].

Regards,
Kyösti

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

[coreboot] Re: Revoke of Gerrit privileges and asking to fork (was: Gerrit etiquette)

[Kyösti Mälkki]

On Sun, Feb 2, 2020 at 2:40 PM Paul Menzel  wrote:
>
> Thank you for the email, which I am pretty sad about to hear. For such a
> drastic measure, I really want to know about more details, as otherwise
> it’s just accusation.

Paul,

Let's just move on. The outcome is what was expected and my English is
too good for me to try to hide behind a language barrier.

I cannot share the details of the discussions, nor does the leadership
have some of the details from my side.

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

[coreboot] Re: AGESA versions of fam15h/fam16h? Version string is v0.001

[Kyösti Mälkki]

On Wed, Jan 15, 2020 at 10:26 PM awokd via coreboot
 wrote:
>
> Mike Banon:
> > If you know, please tell the AGESA versions of fam15h/fam16h AMD
> > vendorcode. For fam14h it is v1.103 - so no questions - but for fam15h
> > and fam16h it says v0.001: #define AGESA_VERSION_STRING  {'V', '0',
> > '.', '0', '.', '0', '.', '1', ' ', ' ', ' ', ' '}
>
> From hacking on the code itself, it seems f16kb is a newer fork of AGESA
> than f15tn, which is newer than f14. For example, a couple failures to
> initialize a variable in f14 were already addressed in f15 and f16, and
> the MMIO allocation seems a bit more fleshed out in f16 than f15.

This is true. Just assume zero correllation with the version string of
the scrubbed AGESA with anything you may find embedded in proprietary
OEM blobs.

Also, the build of MullinsPI binaryPI, that SAGE or AMD AES pushed to
3rdparty/blobs, (AFAIR tagged 1.0.0.4 or 1.0.0.A) has a change
(relevant ECC fix) that they never upstreamed to whatever AMD
department was responsible of the MullinsPI upstream. Furthermore,
that change was incomplete for configurations without UMA (like the
headless pcengines/apu2 variants) so proper ECC support requires a
binary-patched AGESA blob. Neither of these relevant ECC fixes are in
the official MullinsPI source package (1.0.0.J is last I am aware of),
should an industry partner request the source from AMD under NDA for
product development. Same goes for IOMMU feature, ACPI tables from
AGESA are broken and coreboot has to override IVRS at least.

Regards,
Kyösti Mälkki
___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] Re: [RFT] Linux fails to detect devices on AGESA board with `nosmp`

[Kyösti Mälkki]

On Thu, Jan 16, 2020 at 5:21 PM awokd via coreboot
 wrote:
>
> Sergej Ivanov:
> > I can reproduce this bug on Biostar AM1ML. I think this bug is ACPI
> > related, if i add 'nosmp acpi=off' Ubuntu boots fine.

Hi

Parameter 'nosmp' disables I/O APIC and enforces PIC IRQ routing. How
about 'nosmp pci=noacpi', it's less intrusive than using 'acpi=off'.

It is somewhat well-known that AGESA boards' IRQ routing is a one sick
puppy [1] [2]. Or perhaps the entire litter, pun intended.

[1] https://review.coreboot.org/c/coreboot/+/38262
[2] https://review.coreboot.org/c/coreboot/+/38313

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

[coreboot] Re: Booting Linux kernel with nosmp required on Lenovo T60 (ATI/AMD)

[Kyösti Mälkki]

>
> System *boots* with one of:
>
> 1.  maxcpus=0 (equivalent nosmp)
> 2.  maxcpus=1
> 3.  nolapic (with e1000 warning about missing MSI-X
>
> System does *not* boot with one of:
>
> 1.  maxcpus=2
> 2.  noapic
>

I thought SMP was generally not compatible with PIC IRQ routing (which
noapic enforces?) and this would explain case 2.

As for case 1, maybe I missed some detail with my commit [1] when
switching from LAPIC to TSC timers. Like leaving LAPIC timers running
at different rate or generally having the timer counters too much
out-of-sync across CPU #0 and #1. You coud try if that one is the
commit with regression.

[1] https://review.coreboot.org/c/coreboot/+/34200

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

[coreboot] Re: AMD AGESA and binaryPI board removals, last calls

[Kyösti Mälkki]

On Tue, Dec 17, 2019 at 8:13 AM Jorge Fernandez Monteagudo
 wrote:
>
> Hi Marshall
>
> >* amd/bettong removal, should it happen, triggers CarrizoPI (00660F01) 
> >removal
> >
> >We ought to have all the backward-compatibility for CZ and the Embedded 
> >variants landed in stoneyridge and amd_blobs now.  I think it should be a 
> >fairly easy changeover for amd/bettong from cpu/nb/sb to soc/amd
> >/stoneyridge if someone is able to spend the time on it.  The older 0060F01 
> >AGESA was superseded years ago by StoneyPI, and has practically no chance of 
> >ever being updated again.  Padmelon may be the preferred >board now but I 
> >believe there are likely still Bettongs in the field.
>
> I would like to try to do the modifications to avoid bettong removal. I'll 
> have some time this Xmas holidays to spend on it.
> But I'm still struggling with the minimal changes to be able to generate a 
> board_status report because no commits I've done
> are merged. I don't know exactly how to proceed to avoid deprecation...
>

AMD is not valueing my work or fulfilling their part of the
agreements, so I am leaving these size 13 shoes behind for someone to
fill. From what I know, the only persons I could recommend for further
binaryPI related reviews are not being for these tasks either.

Regards,
Kyösti Mälkki
___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] AMD AGESA and binaryPI board removals, last calls

[Kyösti Mälkki]

Hi

Regarding the deprecation of AGESA and binaryPI platforms.

As of 15th Dec 2019 following boards have been transformed to meet
4.11 release requirements, and most have a fresh board-status uploaded
now too:

* asrock/e350m1
* asrock/imb-a180
* asus/f2a85-m
* gizmosphere/gizmo
* hp/pavilion_m6_1035dx
* lenovo/g505s
* pcengines/apu1
* pcengines/apu2

I have seen some active development for the boards listed below, and I
am postponing the source removals for these until 2nd Feb 2020. As
these boards are no longer build-tested they may degrade fast.

* amd/bettong
* asus/am1i-a
* biostar/am1ml

Developers will help people who have these platforms to bring their
board sources to current standards. The process begins by uploading a
fresh board-status result for the board you volunteer to work on and
announce this by replying to this thread.

Unless followilng boards see activity in form of boot success/failure
reports on the mailing list or in the board-status repository, their
sources will be removed from master 31st Dec 2019.

* amd/db-ft3b-lc
* amd/inagua
* amd/lamar
* amd/olivehill
* amd/olivehillplus
* amd/parmer
* amd/persimmon
* amd/thatcher
* amd/south_station
* amd/union_station
* bap/ode_e20XX
* bap/ode_e21XX
* biostar/a68n_5200
* elmex/pcm205400
* gizmosphere/gizmo2
* hp/abm
* jetway/nf81-t56n-lf
* lippert/frontrunner-af
* lippert/toucan-af
* msi/ms7721

Furthermore:
* amd/bettong removal, should it happen, triggers CarrizoPI (00660F01) removal
* amd/lamar removal, should it happen, triggers KaveriPI (00630F01) removal

Once a board has its source removed, it will face the standard review
process should someone want to bring it back. Reincarnations until
next (4.12) release might not be accepted.

Kind regards,
Kyösti Mälkki
___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] Re: AMD AGESA board removals

[Kyösti Mälkki]

On Fri, Dec 13, 2019 at 10:16 PM Sergej Ivanov  wrote:
>
> Hello,
> I'm back with biostar/am1ml development. I've currently tested it with 
> ROMCC_BOOTBLOCK, all works fine. Current board status has been uploaded. What 
> is the last date to submit version without ROMCC?
>


Any board with ROMCC_BOOTBLOCK will be disabled from automatic
build-testing by 14th December at latest, such that ROMCC_BOOTBLOCK
removal in common code can proceed. Boards that see no activity will
be removed from the tree 31st December 2019.

Once a board has its source removed, it will face the standard review
process should someone want to bring it back. Reincarnations until
next (4.12) release might not be accepted.

Kind regards,
Kyösti Mälkki
___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] Re: Asus F2A85M broken from version 4.10

[Kyösti Mälkki]

On Fri, Dec 13, 2019 at 9:42 PM Balázs Vinarz  wrote:
>
> Hello there!
>
> I just recently started to work again on my port for Asus A88XM-E,
> which is based on the F2A85-M:
> https://review.coreboot.org/c/coreboot/+/30987.
> The master build was broken for the A88XM-E and I though maybe some of
> the differences between the sources have caused this, but it's broken
> for the F2A85-M (LE) as well.
> I built all the 4.9, 4.10 and 4.11 versions and 4.10 and 4.11 is
> definitely broken. Right after the kernel loads it stops with a panic.

There are two board-status reports for 4.10 and 4.10-942 for
asus/f2a85m-pro you can try.
Or different kernel, I am not so sure about IOMMU in fam15tn, the
panic points to that direction.

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

[coreboot] Re: AMD AGESA board removals

[Kyösti Mälkki]

On Fri, Dec 13, 2019 at 1:38 PM Github Hun  wrote:
>
> Hi,
>
> just to give a heads-up status: as of today (13.12.2019) with the current 
> Master revision, I can confirm, that for lenovo/g505s coreboot builds and 
> boots perfectly with ROMCC_BOOTBLOCK already removed.

Upload  the board-status, please !!

> There are two modifications are needed though:
> 1. revise commit: 0178760 on Oct 25: 'Don't use both of _ADR and _HID' patch 
> --> for Fam15h '_CID' is missing from:
>  src/northbridge/amd/agesa/family15tn/acpi/northbridge.asl

Please elaborate, or better yet push a fix.

> therefore, you have to add this (from eg. fam14h asl file). Otherwise Linux 
> will not boot (4.19.x and 5.3.x, 5.4.x...).
> 2. in lenovo/g505s/bootblock.c, you'll need an 'empty' 
> bootblock_mainboard_early_init(void) function.  Of course if you'll ever need 
> PCI debug card support, then the LPC code will need to be still fixed (eg. 
> from Gizmo2?)

Empty bootblock_mainboard_early_init() is in lib/bootblock.c already.
What exactly do you think is broken with LPC?

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

[coreboot] Re: AM1I-A Failing to Boot

[Kyösti Mälkki]

On Thu, Dec 12, 2019 at 11:58 AM Mike Banon  wrote:
>
> It would be nice if this "drop time" could be extended until at least
> mid January (i.e 19th Jan), so that those of us who have New Year
> holidays will be able to spend them working on coreboot. I also want
> to save AM1I-A but don't have much time in December.

Download board-status for 4.11-400 so that I know it boots, solution
for am1i-a may magically appear after that.

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

[coreboot] Re: AMD Agesa Bettong board support

[Kyösti Mälkki]

On Tue, Dec 10, 2019 at 11:19 AM Jorge Fernandez Monteagudo
 wrote:
>
> >> So, before I can send the board status, should I wait for someone to 
> >> upload the changes
> >> to the repository?
> >
> >You can wait. Keep in mind board removals for binaryPI are (currently)
> >scheduled for 14th December.
> >
> >It would be wiser to learn to contribute and upload the required fixes
> >to gerrit yourself. Clearly, you have already managed to bisect a boot
> >regression issue, so your previous statement of "I can only help with
> >uploading board-status at release times" is just ... lame.
>
> Hi Kyösti,
>
> I've been able to push a Bettong board status (commit 
> 31848f291a5f9b8ed0cf5e7c2f6651d1b56a1086)
> yesterday. The patches I've sent to Gerrit still are not merged but I think 
> we are on the right track.
> What's more is needed to avoid Bettong deprecation?
>
> Regards,
> Jorge

Thanks

The board-status you submitted relies on local changes. Can you send
output of 'git log --oneline db945ff860' so we have better record of
what you had done to make it boot again?

You need to replicate [1] for NORTHBRIDGE_AMD_PI_00660F01 and [2] for
mb/amd/bettong. AGESA blobs were sometimes modified in unpredictable
ways, so it probably will not work out-of-the-box.

[1] https://review.coreboot.org/c/coreboot/+/32421
[2] https://review.coreboot.org/c/coreboot/+/32363

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

[coreboot] Re: AMD AGESA board removals

[Kyösti Mälkki]

On Tue, Dec 10, 2019 at 1:07 AM Denis 'GNUtoo' Carikli
 wrote:
>
> On Mon, 9 Dec 2019 02:20:29 +0200
> Kyösti Mälkki  wrote:
>
> [E350M1]
> > You want to rebase your changes on pcengines/apu1 transition [1]
> > which is the first fam14 board to drop ROMCC_BOOTBLOCK.
> >
> > [1] https://review.coreboot.org/c/coreboot/+/37332/11
> I've done that, and after build it, flashing it and powering off and on
> the board, nothing appears on the serial port.
>

You can push your own commits on top of the existing (but not yet
merged) works on gerrit. Run 'git push --dry-run' and if it only shows
your commit as new/updated you would not mess with the already
existing branch we have. You can achieve this by making sure the
parent commit is one that you already find gerrit UI, in other words
do not rebase when you have done a checkout.

We'll do some tests on cimx/sb800, probably some missing LPC route or clock.

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

[coreboot] Re: AMD AGESA board removals

[Kyösti Mälkki]

On Tue, Dec 10, 2019 at 10:22 AM Kyösti Mälkki  wrote:
>
> On Tue, Dec 10, 2019 at 1:10 AM Denis 'GNUtoo' Carikli
>  wrote:
> >
> > On Mon, 9 Dec 2019 18:54:18 +0200
> > Kyösti Mälkki  wrote:
> >
> > [f2a85m-pro broken on master]
> > > Weird. Seems like I let the devicetree in a bit of a bad shape back
> > > in 2015. Try if this makes any difference:
> > > https://review.coreboot.org/c/coreboot/+/37619
> > I tried that through the normal/fallback mechanism on top of master and
> > it didn't boot.
> >
>
> It should be pretty obvious we are building new bootblocks, you can't
> test with the fallback/normal mechanism of romcc bootblock.

Ah.. I just realised this wasn't a bootblock change we are talking
about. Anyways, try fix the f2a85m-pro, send logs here if necessary.

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

[coreboot] Re: AMD AGESA board removals

[Kyösti Mälkki]

On Tue, Dec 10, 2019 at 1:10 AM Denis 'GNUtoo' Carikli
 wrote:
>
> On Mon, 9 Dec 2019 18:54:18 +0200
> Kyösti Mälkki  wrote:
>
> [f2a85m-pro broken on master]
> > Weird. Seems like I let the devicetree in a bit of a bad shape back
> > in 2015. Try if this makes any difference:
> > https://review.coreboot.org/c/coreboot/+/37619
> I tried that through the normal/fallback mechanism on top of master and
> it didn't boot.
>

It should be pretty obvious we are building new bootblocks, you can't
test with the fallback/normal mechanism of romcc bootblock.

Someone should create a mock verstage to support the equivalent of
fallback/normal mechanism, but I don't know anyone working actively on
it.

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

[coreboot] Re: AMD AGESA board removals

[Kyösti Mälkki]

On Mon, Dec 9, 2019 at 5:48 PM Denis 'GNUtoo' Carikli
 wrote:
>
> On Sun, 8 Dec 2019 18:49:26 +0200
> Kyösti Mälkki  wrote:
> > > - What to do if the board doesn't boot anymore with master
> > >   (f2a85m-pro)? Should I bisect the issue first? Or would the
> > >   conversion be able to fix the issue?
> >
> > Bisect first and return master to a working state please. There is a
> > recent fam15tn test so I hope your board did not regress since 4.10
> > tag.
> I found the commit that broke the F2A85M-PRO booting:
> > 51b75ae50aa device: Use scan_static_bus() over scan_lpc_bus()
>

Weird. Seems like I let the devicetree in a bit of a bad shape back in 2015.
Try if this makes any difference: https://review.coreboot.org/c/coreboot/+/37619

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

[coreboot] Re: AMD AGESA board removals

[Kyösti Mälkki]

On Mon, Dec 9, 2019 at 1:53 AM Denis 'GNUtoo' Carikli
 wrote:
>
> On Sun, 8 Dec 2019 18:49:26 +0200
> Kyösti Mälkki  wrote:
> > Here is fam16kb asrock/imb-a180 with super-io init moved to bootblock:
> > https://review.coreboot.org/c/coreboot/+/37453
> Thanks.
>
> I've tried to do the same for the E350M1 and I end up with:
> > [...]/i386-elf-ld.bfd: build/bootblock/arch/x86/bootblock_crt0.o: in
> >  function `enable_sse':
> > [...]/src/arch/x86/bootblock_crt0.S:71: undefined reference to
> >  `bootblock_pre_c_entry'
>

You want to rebase your changes on pcengines/apu1 transition [1]
which is the first fam14 board to drop ROMCC_BOOTBLOCK.

[1] https://review.coreboot.org/c/coreboot/+/37332/11


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

[coreboot] Re: AM1I-A Failing to Boot

[Kyösti Mälkki]

On Mon, Dec 9, 2019 at 12:32 AM Matt B  wrote:
>
> Question specifically for Kyösti Mälkki or those similarly knowledgeable:
>
> My current .config seems to say I'm still using romcc.

Please read the recent thread "AMD AGESA board removals".

> I assume I've pulled the latest ("git clone 
> https://review.coreboot.org/coreboot; as of a couple days ago) so would those 
> changes you mentioned be present?
> If so, is there an option to test the C bootblock in the menu somewhere?

There will be no option as romcc will be gone for good. You should do
a checkout on commit f66da11 [1], make similar changes to asus/am1i-a,
and push your work for review. I have done quick boottest on
asrock/imb-a180 with commit ca150dc [2] and it got past the made
bootblock changes.

[1] https://review.coreboot.org/c/coreboot/+/37453/9
[2] https://review.coreboot.org/c/coreboot/+/37440/10

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

[coreboot] Re: AM1I-A Failing to Boot

[Kyösti Mälkki]

On Sun, Dec 8, 2019 at 8:44 PM Matt B  wrote:
>
> Hi,
>
> In the spirit of board report coverage, I pulled out the (used, but new to 
> me) AM1I-A I have and spent a day or two trying to install the latest 
> coreboot on it.

I hope board-status repository shows its value here for you as the
previous record is from early November. There appears to be download
link for pre-built image as well.

This platform with family16kb "Kabini" was the last scrubbed
vendorcode released so it is not binaryPI. From what I remember
CONSOLE_SPI_FLASH has not been tested with AGESA or binaryPI, the
board seems to have a serial port so maybe put that into good use.

Disclaimer: Due the time constraints to transition away from
ROMCC_BOOTBLOCK we have merged code changes that affect all
fam14-15tn-16kb AGESA, while not being able to test on a wide variety
of boards. By the end of 2019, the boards will either extinct or be
tested to boot, but todays status is somewhat volatile.

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

[coreboot] Re: AMD AGESA board removals

[Kyösti Mälkki]

On Sun, Dec 8, 2019 at 6:20 PM Denis 'GNUtoo' Carikli
 wrote:
>
> On Tue, 3 Dec 2019 19:29:48 +0200
> Kyösti Mälkki  wrote:
>
> > Hi
> Hi,
>
> > Regarding the deprecation of AGESA platforms due to ROMCC_BOOTBLOCK.
> >
> > As of 3rd December there is active development, while not much testing
> > yet, only for the following AGESA platform boards:
> >
> > * asrock/imb-a180
> > * lenovo/g505s
> > * pcengines/apu1
> >
> > Using one of the above boards as a sample, it might not take more than
> > 30 minutes and two boots to make the required transition. But first we
> > need to have the above boards working of course.
> - Do you have some pointers to commits doing that transition?

Here is fam16kb asrock/imb-a180 with super-io init moved to bootblock:
https://review.coreboot.org/c/coreboot/+/37453

And a fam15tn lenovo/g505s without serial port:
https://review.coreboot.org/c/coreboot/+/37499

> - What to do if the board doesn't boot anymore with master
>   (f2a85m-pro)? Should I bisect the issue first? Or would the
>   conversion be able to fix the issue?

Bisect first and return master to a working state please. There is a
recent fam15tn test so I hope your board did not regress since 4.10
tag.

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

[coreboot] Re: AMD Agesa Bettong board support

[Kyösti Mälkki]

On Thu, Dec 5, 2019 at 3:45 PM Jorge Fernandez Monteagudo
 wrote:
>
>
> >Regarding the conflicting commit, it was there to be reviewed from Jan
> >24th and finally approved Sep 11th, having seen testing only on
> >pcengines/apu2 which is a different SoC. The other error is likely a
> >regression after two weeks of not being build-tested. Sounds like two
> >commits you need tol land first.
>
> So, before I can send the board status, should I wait for someone to upload 
> the changes
> to the repository?
>

You can wait. Keep in mind board removals for binaryPI are (currently)
scheduled for 14th December.

It would be wiser to learn to contribute and upload the required fixes
to gerrit yourself. Clearly, you have already managed to bisect a boot
regression issue, so your previous statement of "I can only help with
uploading board-status at release times" is just ... lame.

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

[coreboot] Re: AMD Agesa Bettong board support

[Kyösti Mälkki]

On Thu, Dec 5, 2019 at 11:14 AM Jorge Fernandez Monteagudo
 wrote:
>
> Hi all,
>
> I've been able to make it work the Bettong board again with the commit before 
> a0a50775
> as Kyösti Mälkki pointed. I've had to remove the next commit to make it work 
> again.
>
> bfb5c807e720761f4457d5106bb919f2aacb5535 binaryPI: Drop PSP Secure OS from 
> build
>
> and some minor changes. I really want to upload the board status but I'm 
> still trying to make
> the git push to work, I stil can't login. I've attached the tar.gz related to 
> the path:
>

The commit hash you push to board-status with has to be one from
upstream, local changes are not really useful or acceptable. The
entire purpose is to have a known-good reference where board has
somewhat booted. You can go to parent of the commit above.

Regarding the conflicting commit, it was there to be reviewed from Jan
24th and finally approved Sep 11th, having seen testing only on
pcengines/apu2 which is a different SoC. The other error is likely a
regression after two weeks of not being build-tested. Sounds like two
commits you need tol land first.

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

[coreboot] Re: AMD AGESA board removals

[Kyösti Mälkki]

On Wed, Dec 4, 2019 at 11:44 PM Peter Stuge  wrote:
>
> Kyösti Mälkki wrote:
> > * gizmosphere/gizmo
>
> I have a gizmo and would like to help it stay in tree. If I understand you
> correctly I should start by trying to build and boot current master?
>

Nice, a fresh board-status is most welcome. With no super-io to set up
in the bootblock, gizmo would get a free ride [1].

[1] https://review.coreboot.org/c/coreboot/+/37452

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

[coreboot] Re: AMD AGESA board removals

[Kyösti Mälkki]

On Wed, Dec 4, 2019 at 4:48 PM Michal Zygowski
 wrote:
>
> On 03.12.2019 18:29, Kyösti Mälkki wrote:
> > Hi
> >
> > Regarding the deprecation of AGESA platforms due to ROMCC_BOOTBLOCK.
> >
> > As of 3rd December there is active development, while not much testing
> > yet, only for the following AGESA platform boards:
> >
> > * asrock/imb-a180
> > * lenovo/g505s
> > * pcengines/apu1
> I do not exactly understand "not much testing". While uploading patches
> for family14 or apu1 I always build, flash, boot Linux test whether it
> works...

You can read this no testing at all for fam15tn and fam16kb so far,
and testing fam14 with a single board.

I believe there was a commit for apu1 where newly added bootblock.c
file was not linked in, while the boot sequence to OS worked just
perfect? Some super-io configuration bits are sticky and powered from
Vbat /Vrtc or Vstb rails, these bootblock changes should be verified
with (RTC) battery removed.

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

[coreboot] AMD AGESA board removals

[Kyösti Mälkki]

Hi

Regarding the deprecation of AGESA platforms due to ROMCC_BOOTBLOCK.

As of 3rd December there is active development, while not much testing
yet, only for the following AGESA platform boards:

* asrock/imb-a180
* lenovo/g505s
* pcengines/apu1

Developers will help people who have these platforms to bring their
board sources to current standards. The process begins by uploading a
fresh board-status result for the board you volunteer to work on and
announce this by replying to this thread.

Using one of the above boards as a sample, it might not take more than
30 minutes and two boots to make the required transition. But first we
need to have the above boards working of course.

Our board-status repository has some previous results for the boards
listed below, and we need your assistance to keep these boards in:

* amd/olivehill
* amd/persimmon
* amd/thatcher
* asrock/e350m1
* asus/am1i-a
* asus/f2a85-m
* biostar/am1ml
* gizmosphere/gizmo
* hp/pavilion_m6_1035dx
* jetway/nf81-t56n-lf
* lippert/frontrunner-af
* msi/ms7721

Same offer and request of help as above applies to the following
boards, for which we have no previous board-status records:

* amd/inagua
* amd/parmer
* amd/south_station
* amd/union_station
* bap/ode_e20XX
* biostar/a68n_5200
* elmex/pcm205400
* gizmosphere/gizmo2
* hp/abm
* lippert/toucan-af

Any board with ROMCC_BOOTBLOCK will be disabled from automatic
build-testing by 14th December at latest, such that ROMCC_BOOTBLOCK
removal in common code can proceed. Boards that see no activity will
be removed from the tree 31st December 2019.

Once a board has its source removed, it will face the standard review
process should someone want to bring it back. Reincarnations until
next (4.12) release might not be accepted.

Kind regards,
Kyösti Mälkki
___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] Re: AMD binaryPI board removals

[Kyösti Mälkki]

On Tue, Dec 3, 2019 at 4:35 PM Michal Zygowski
 wrote:
>
> I think Kyösti could share a little bit more details on that (commit
> 55fffa29c23).

Lots of things I could but will not volunteer to. I have every reason
to believe any party requesting amd/bettong to be maintained, and
having access to such board, has designed and potentially manufactured
some custom board based on that particular reference design. Yet I
have not seen this party contributing anything to the maintenance of
the tree in the past 4 or so years. What goes around comes around, I
don't mind amd/bettong disappearing at all.

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

[coreboot] Re: AMD binaryPI board removals

[Kyösti Mälkki]

On Tue, Dec 3, 2019 at 3:58 PM Jorge Fernandez Monteagudo
 wrote:
>
> >Here is a short guide how to upload board status:
> >
> >https://github.com/coreboot/coreboot/blob/master/util/board_status/README
> >
> >The system you are going to boot has to have cbmem installed.
>
> Hi Michal,
>
> Do you have already any patch to test? I've updated to the last git and 
> enabled the AMD Bettong
> board (it's disabled in Kconfig.name!) but it's not compiling. There are 
> several errors:
>

Checkout a commit before a0a50775. We (or at least I) want to have a
reference boot loaded into board-status for amd/bettong first.

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

[coreboot] Re: AMD binaryPI board removals

[Kyösti Mälkki]

On Wed, Nov 27, 2019 at 12:48 PM Jorge Fernandez Monteagudo
 wrote:
>
> >As of 27th November and commit [1]  platforms using AMD binaryPI blobs
> >have been disabled from automatic  build testing. The following are
> >affected:
> >
> >* amd/bettong
>
> Hi all,
>
> I have an AMD Bettong demoboard and I would like to remain supported by 
> coreboot.
> What can I do to help?
>

Nice!

First you need to upload a board-status, preferably built from the
commit tagged 4.11.

Regards,
Kyösti Mälkki
___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] AMD binaryPI board removals

[Kyösti Mälkki]

Hi

As of 27th November and commit [1]  platforms using AMD binaryPI blobs
have been disabled from automatic  build testing. The following are
affected:
* amd/bettong
* amd/db-ft3b-lc
* amd/lamar
* amd/olivehillplus
* bap/ode_e21XX

This is inline with CAR_GLOBAL_MIGRATION deprecation as mandated by
4.11 release requirements. You should expect that the board sources
and platform support will disappear by 14th December, at latest,
unless you show interest *and* are able to provide bootlogs for the
boards above.

PCEngines APU2 and variants are an exception to this, they were
converted to POSTCAR_STAGE and work away from ROMCC_BOOTBLOCK shows
promising results.

[1] https://review.coreboot.org/c/coreboot/+/37170

Regards,
Kyösti Mälkki
___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] Re: Planning coreboot 4.11

[Kyösti Mälkki]

On Tue, Nov 12, 2019 at 12:07 PM Michal Zygowski
 wrote:
>
>
> On 10.11.2019 17:13, Kyösti Mälkki wrote:
> > On Sun, Nov 10, 2019 at 12:35 PM Mike Banon  wrote:
> >> Thank you, I've sent the reports for Lenovo G505S (AMD Fam15h) and
> >> ASUS AM1I-A (AMD Fam16h). Hope this helps, especially AM1I-A since
> >> its' previous report was from early 2018.
> >>
> > I do not plan to volunteer for C_ENVIRONMENT_BOOTBLOCK=y conversion
> > for AGESA/PI platforms, so it is currently uncertain if some or any of
> > them will remain on master branch after 4.11 release.
> I will soon update my patches with C_ENVIRONMENT_BOOTBLOCK for binaryPI
> which will be rebased on top of postcar patches (easier for CAR teardown).
>
> Kyösti I would appreciate if you could look at
> https://review.coreboot.org/c/coreboot/+/32363
> Nobody tells you to volunteer, but review very welcome, since nobody
> seems to be interested
> to even take look at it.
>

At the moment there is too much bad blood for me to touch anything
remotely related to AGESA, you have seen some of the private email
exchange. And most notably, the lack of response.

Looks like when AMD is not stabbing you in the back, they are shooting
themselves in the leg instead.


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

[coreboot] Re: [AMD 16h / ASUS AM1I-A] 1866MHz CL9 RAM runs only as 1333MHz CL9 - how to fix?

[Kyösti Mälkki]

On Sun, Nov 10, 2019 at 3:52 PM Mike Banon  wrote:
>
> Sorry it took me so long: using FT232H and screen Ctrl+A h option,
> finally I got a complete boot log on AM1I-A Fam16h with these IDS
> options enabled. Please could you take a look, to see if it contains
> any hints why this 1866MHz CL9 RAM has been initialized as 1333MHz CL9
> only?

Not really, I expect it to involve several hours of work with little or no gain.

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

[coreboot] Re: Planning coreboot 4.11

[Kyösti Mälkki]

On Sun, Nov 10, 2019 at 12:35 PM Mike Banon  wrote:
>
> Thank you, I've sent the reports for Lenovo G505S (AMD Fam15h) and
> ASUS AM1I-A (AMD Fam16h). Hope this helps, especially AM1I-A since
> its' previous report was from early 2018.
>

I do not plan to volunteer for C_ENVIRONMENT_BOOTBLOCK=y conversion
for AGESA/PI platforms, so it is currently uncertain if some or any of
them will remain on master branch after 4.11 release.

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

[coreboot] Re: [RFC] Logging boot_state times

[Kyösti Mälkki]

On Fri, Nov 1, 2019 at 9:34 AM Kyösti Mälkki  wrote:
>
> Another (but yet unimplemented) change is to accumulate for each
> boot_state the times spent in printk() and udelay(). I think it will
> be more meaningful to report estimated execution time, rather than
> realtime there. I don't plan to remove the latter, though.
>

This change in logging format is read for review:

[1] https://review.coreboot.org/c/coreboot/+/36574

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

[coreboot] Re: G505S : S3 resume freezes without CONFIG_CBMEM_STAGE_CACHE

[Kyösti Mälkki]

On Sun, Nov 3, 2019 at 3:48 PM Mike Banon  wrote:
>
> Good day! Starting with commit
> 0a4457ff44b10f22b711f64e8c757fbedf32 which introduced a
> disabled-by-default CONFIG_CBMEM_STAGE_CACHE option  -
> https://github.com/coreboot/coreboot/commit/0a4457ff44b10f22b711f64e8c757fbedf32
> - S3 resume freezes on G505S if this option isn't enabled.
>
> Commit message tells that "AGESA platforms without TSEG will
> experience slower S3 resume speed unless they explicitly select the
> option.", however I've waited for like an hour but it's still stuck
> and can't be turned on later without a force shutdown and full laptop
> discharge.

Well.. it would not be first or the last time when I write commit
messages anticipating certain things to happen, while not having fully
tested all aspects.

> There's the same behavior for a fresh coreboot as well. Here is my
> coreboot config I've used as a base - https://pastebin.com/6Nj6e6xZ .
> Is this problem expected? If not, I could help by testing your debug
> builds aimed on fixing it.

Just add 'select CBMEM_STAGE_CACHE' for fam14, fam15tn and fam16kb for
now. I kind of came across this problem recently but did not make any
debugging attempts yet.

> In addition, S3 resume is also not working with
> CONFIG_SECURITY_CLEAR_DRAM_ON_REGULAR_BOOT even if
> CONFIG_CBMEM_STAGE_CACHE is enabled.

We did discuss this before in gerrit, I could not find the link
though. AGESA has some valuables at around 128 MiB (or was it 64 MiB)
in ramstage that coreboot proper does not really know about. Clearing
that wipes out cached RAM training data before it is written to SPI
flash.

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

[coreboot] [RFC] Logging boot_state times

[Kyösti Mälkki]

Hi

In case someone is parsing coreboot logs and boot_state times in
particular, I am suggesting a change [1] to that format to report in
milliseconds rather than microseconds.

Another (but yet unimplemented) change is to accumulate for each
boot_state the times spent in printk() and udelay(). I think it will
be more meaningful to report estimated execution time, rather than
realtime there. I don't plan to remove the latter, though.

[1] https://review.coreboot.org/c/coreboot/+/36528

Regards,
Kyösti
___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] Re: How to access the PCIE device registers at an early stage of coreboot booting?

[Kyösti Mälkki]

On Sun, Oct 27, 2019 at 4:29 PM  wrote:
>
> Hello to all!
> Need quick help! I am poorly versed in the question so detailed answers are 
> welcome :) !
>
> As a result of the  motherboard developers laziness the hard straps for 
> ASPEED AST2510 chip were not properly prescribed.
> Now I need to write register 0x1e6e2070 with necessary bits [5][15] to '1' at 
> an early stage of coreboot booting.
> Motherboard based on Intel Atom SOC Processor C3758 (DENVERTON_NS).
> The AST2510 chip is always located on (B3:D0:F0) [0x1a03:0x2000] after aspeed 
> bridge (B2:D0:F0) [1a03/1150]:
>
> PCI: 00:09.0 scanning...
> do_pci_scan_bridge for PCI: 00:09.0
> PCI: pci_scan_bus for bus 02
> PCI: 02:00.0 subordinate PCI
> PCI: 02:00.0 [1a03/1150] enabled
> PCI: 02:00.0 scanning...
> do_pci_scan_bridge for PCI: 02:00.0
> PCI: pci_scan_bus for bus 03
> PCI: 03:00.0 [1a03/2000] ops
> PCI: 03:00.0 [1a03/2000] enabled
>
> The code below located in romstage.c file successfully finds the device:
>
> pci_devfn_t dev;
>
> /* ASPEED AST2510 Graphics (B3:D0:F0). */
> dev = PCI_DEV(3, 0, 0);
> uint32_t id = pci_read_config32(dev, 0); //id = (0x1a03<<16) | 
> 0x2000 => Aspeed graphics!

Generally, accessing PCI devices on bus other than 0 does not work in
romstage. If the above worked, it's probably something the FSP blobs
have done. While you could access PCI configuration register of
AST2510, you still need to open up IO and/or MMIO windows on the
upstream PCI bridge devices as well to achieve the rest.

The way things currently work, you don't use struct device in romstage
for PCI configuration access.

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

[coreboot] Re: Debugging EHCI - but Pre-CBMEM romstage/ramstage console overflowed, log truncated

[Kyösti Mälkki]

On Sun, Oct 27, 2019 at 9:55 AM Mike Banon  wrote:
>
> Thank you very much for your reply. Still curious about this
> "Pre-CBMEM log truncated" issue - how would you have solved it?
>

It is called config PRERAM_CBMEM_CONSOLE_SIZE and I don't have a good
value to give you, specially assuming AGESA with its convoluted CAR
setup. Increase the config too much and it will fail to build, assume
it to fail to boot way sooner. AGESA with SMP romstage is somewhat
memory hungry and there is CAR no-eviction mode either.

As for that EHCI debug output: One  could reduce its verbosity by
removing retry loops and using a predefined fixed USB port
(USBDEBUG_HCD_INDEX != 0). But only USB2 high-speed devices give
interesting output there.

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

[coreboot] Re: Debugging EHCI - but Pre-CBMEM romstage/ramstage console overflowed, log truncated

[Kyösti Mälkki]

On Sun, Oct 27, 2019 at 8:53 AM Mike Banon  wrote:
>
> Good day, I'm researching if it's possible to support a cheaper
> FT232BL-based EHCI usbdebug dongle like the already-supported FT232H
> -- to make EHCI debugging more accessible to the newcoming
> coreboot'ers -- and need the detailed logs (i.e.
> CONFIG_DEBUG_CONSOLE_INIT) to figure this out.

EHCI debug mode requires USB 2.0 High Speed (480 Mbps) device which
FT232BL is not. That hardware can possibly provide console with GRUB
payload but nothing earlier than that.

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

[coreboot] Re: DIY debug Dongle

[Kyösti Mälkki]

On Sun, Oct 13, 2019 at 1:28 AM  wrote:
>
> Hi
> I’ve seen an EHCI debug dongle in the old wiki. I’m trying to build one for 2 
> purposes: debug a homebrew os/Shell and make it a new UEFI bootloader. 
> However I don’t know where to find further documentation or comments about 
> this. I also dont’ know what is the current or most up to date schematic to 
> build the “sandwich” and what tracks cut and what not. I have bought those 
> blue cypress FX2LP boards and I don’t know how to check revisions. Also, 
> I’dont know exactly what software can be used to control it. It would be 
> desirable if one can send stop or install some breakpoints with Visual 
> studio’s debugger or WinDBG or GDB or something like that.
> thanks in advance for your advice.

Hi

I created the original FX2LP dongle sandwich, crafting together pieces
from different fx2lib sources back in 2013. I think my repository
regressed (no longer built) already in 2014-2015 after some sdcc
update and I never had interest to maintain that; coreboot devs had
switched to USB gadgets like BBB screwdriver and  dual-FT232H.

There was further work [1] linked in wiki that claims to work as a
compatible net20dc replacement with windows kernel debugger. I never
built or run that firmware. I may still have the hardware somewhere
but I
don't remember them having any distinct PCB revision silkscreens
printed, you just need to trace the pins. The FX2LP boards I had were
actually relabeled FX2, which might also may break net20dc
compatibility.

I would go with one of the other non-FX2LP approaches instead:

- use pre-built beaglebone black screwdriver image, route USB gadget
(g_dbpg) to TCP  (how to make it appear as virtual COM port for WinDBG
I have no clue of)
- some phone or devboard with USB OTG 2.0 operating in device mode,
otherwise same as above
- in case you develop with some TianoCore / EDK, which claims net20dc
support, make it compatible with FT232H, it should be just a matter of
sending couple different USB packets [2]

[1] https://github.com/night199uk/fx2lib/pull/2
[2] https://review.coreboot.org/c/coreboot/+/10063

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

[coreboot] Re: Postcodes to IO port 80

[Kyösti Mälkki]

On Wed, Oct 16, 2019 at 3:36 PM Jorge Fernandez Monteagudo
 wrote:
>
> Hi all,
>
> Sorry for my noob question but, how can I know where the IO port 80 is 
> physically mapped in my hardware?
>
> I have a custom board with an AMD Prairie Falcon SOC and I'm still trying to 
> get it work. I've read the AGESA
> blob could post error codes to this IO port and I would like to get this 
> info, but I don't complete understand the
> magic behind the postcodes and the IO port. Anybody could bring some light?
>

Do you have working coreboot serial console and postcodes already?
Recent AMD SoCs have LPC clocks disabled and/or LPC pins as
multi-purpose. See hudson_lpc_port80() implementation and try adapt
from that to route IO 0x80 to LPC.

You can contact me privately if you are willing to share more details
from your design.

Regards,
Kyösti Mälkki
___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] Re: Fixing Hidden PCI devices on Intel common SoCs

[Kyösti Mälkki]

On Fri, Sep 27, 2019 at 8:11 PM Nico Huber  wrote:
>
> On 26.09.19 18:45, Aaron Durbin via coreboot wrote:
> > Here's some of the requirements/issues we should resolve that come to mind:
> >
> > 1. Easy way to directly retrieve a device's chip config object w/o
> > traversing the device hierarchy. Which leads to...
> > 2. Symbol alias for accessing struct device directly (no bdf lookup)
>
> What we already have:
>
> Static pointers to `struct device` for devices with a globally valid
> address (PCI devices on bus 0 and PNP devices), e.g.:
>
> DEVTREE_CONST struct device *DEVTREE_CONST __pci_0_02_0 = &_dev6;
> DEVTREE_CONST struct device *DEVTREE_CONST __pnp_002e_00 = &_dev56;
>
> What I suggested somewhere on Gerrit:
>
> At the chip driver level, add a header file that maps these to more
> distinct names, e.g.
>
> #define igd_dev __pci_0_02_0;
>
> But that was last week. Since then I've written yet another override
> tree and realized something. We write a lot lines like
>
> device pci 02.0 on  end # Integrated Graphics Device
>
> What's wrong with that? (if you know me it's obvious) there is a
> comment! IIRC, Kyösti suggested it already, we could let sconfig
> read a chip specific mapping for device names. That would also
> allow us to write the above as

One way or another, I would like most of  gone and
same information derived from devicetree.cb files.

For the record, I am rebasing my local trees, this work removes most
if not all #if __SIMPLE_DEVICE__ under soc/intel. Except for [1] and
[2] I do not have any work pending related to providing usable alias
names, or much interest to work on devicetree.cb parser.

[1] https://review.coreboot.org/c/coreboot/+/31936
[2] https://review.coreboot.org/c/coreboot/+/31934

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

[coreboot] Re: Fixing Hidden PCI devices on Intel common SoCs

[Kyösti Mälkki]

On Fri, Sep 27, 2019 at 7:42 PM Nico Huber  wrote:
>
> IIRC, I asked this elsewhere already. Do we want to keep simple device?
> If we reduce `struct device` to b/d/f and a pointer to the chip info
> in early stages, couldn't we just use `struct device` for PCI config
> access everywhere?

I got side-tracked from the PCI development, also I noticed the one
big [RFC] commit on my local tree I had never pushed.

1. I want to remove all preprocessor #ifdef __SIMPLE_DEVICE__ mess. We
currently have that because of name collisions, some of that looked
prettier prior to removal of device_t but we definitely do not want
that back.

2. I have experimented with romstage, switching from passing immediate
BDF value PCI_DEV(b,d,f) to struct pointer; I have not seen
performance or code size penalty. Having inspected some of the
generated objects, code patterns that transfer multiple register
values from devtree.cb to a single PCI device are actually tighter
assembly code (on x86). My vision here is we need to optimise the
developer's use of time.

3. I want to keep pci_devfn_t available for PCI subsystem primitives,
like  and  . Also I would
like to keep those files simple and see at most an anonymous struct
device. I am not convinced if we are ready to really require
C_ENVIRONMENT_BOOTBLOCK with next release? The forms with pci_devfn_t
do work with romcc and we need that little PCI configuration in
bootblocks.

4. I do not want to make devicetree compulsory for (gcc-built)
bootblocks. But if we can drop the topology links there, the size
impact would not be that bad. If we follow this approach, and get all
romstages converted to use struct device, we could reconsider #3.

5. I don't plan to fix/clean amdfam10 from the preprocessor mess
discussed here (or elsewhere).

Kyösti Mälkki
___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] Re: Fixing Hidden PCI devices on Intel common SoCs

[Kyösti Mälkki]

On Thu, Sep 26, 2019 at 7:45 PM Aaron Durbin  wrote:
>
> On Thu, Sep 26, 2019 at 10:06 AM Kyösti Mälkki  
> wrote:
>> Should be easy enough to implement
>> platform hook telling to not remove PCI device node from topology
>> links (based on BDF), even when it does not respond to ID queries.
>
>
> Yes, we can certainly do that. However, I also think this issue and yours and 
> Nico's devicetree work are somewhat related as well as 
> https://review.coreboot.org/c/coreboot/+/35621.

I'll try to rebase all my work during the weekend.

> Here's some of the requirements/issues we should resolve that come to mind:
>
> 1. Easy way to directly retrieve a device's chip config object w/o traversing 
> the device hierarchy. Which leads to...
> 2. Symbol alias for accessing struct device directly (no bdf lookup)
> 3. Symbol alias for pci b/d/f lookup (equivalent of simple device but 
> cleaner) so we can perform pci operations.
> 4. possibly hidden pci devices
>
> Anything else I'm missing? I think a lot of the issues we're running into 
> could be fixed w/ the above. Let me know what you think.
>

5. PCI coalesce can alter PCI dev.fn assignments?
6. Devicetree in ENV SMM is problematic when chip config is mutable in
ENV_RAMSTAGE.
7. In general, trend seems to be the need to do more and earlier, like
assign some resources of SATA or eMMC in romstage already.

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

[coreboot] Re: Fixing Hidden PCI devices on Intel common SoCs

[Kyösti Mälkki]

In a nutshell:

The implementation of dev_find_slot() traverses the linked list of all
devices in the devicetree, regardless of the topology. Since PCI bus
numbers are only assigned in early ramstage, this function is not a
reliable API. Furthermore, referencing (dynamically) assigned PCI
busses by integers (>1) is also prone to errors as insertion of PCIe
add-on cards will shift these.

Now.. during PCI enumeration, missing static devices are only removed
from the PCI topology links, not the 'linked list of all devices' that
dev_find_slot(). AFAICS, this is the root cause why pcidev_on_root()
caused regressions with 903b40a. Should be easy enough to implement
platform hook telling to not remove PCI device node from topology
links (based on BDF), even when it does not respond to ID queries.

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

[coreboot] Re: Fixing Hidden PCI devices on Intel common SoCs

[Kyösti Mälkki]

Hi Matt,

thanks for bringing the topic up. Please also contact your Intel reps
about this via commercial support channel as well. I believe Patrick
G. once stated that he could act as a relay when it comes to disputes
between commercial and community development 'strategies'.

On Wed, Sep 25, 2019 at 8:48 PM Matt DeVillier  wrote:
>
> Commit 903b40a [soc/intel: Replace uses of dev_find_slot()] replaced calls to 
> dev_find_slot() with calls to pcidev_path_on_root() for all Intel common 
> SoCs, but it seems unclear exactly what problem this was intended to fix, and 
> has created problems with locating hidden PCI devices.

I believe [1] commit explains dev_find_slot() with enough details.

> Commit f2ac0137 [soc/intel: Fix regression with hidden PCI devices] fixed 
> this partially by creating a debug version of pcidev_path_on_root() which 
> falls back on dev_find_slot(), but did not apply it to all devices which need 
> it. On SKL/KBL alone, there are at least 5 different function calls accessing 
> a dozen PCI devices which require falling back on dev_find_slot().
>
> Kyosti has expressed a desire to eliminate the use of dev_find_slot() since 
> it can potentially return false positives prior to device enumeration in 
> ramstage, but as currently implemented the cure seems worse than the disease.
>
> Short term, it seems like having pcidev_path_on_root() fall back on 
> dev_find_slot() with a loud warning (like pcidev_path_on_root_debug() does 
> now) makes the most sense, vs having two nearly identical function calls used 
> inconsistently. Long term, we need a better strategy for dealing with PCI 
> devices which get hidden by FSP / are in violation of PCI spec.
>
> But since discussion on Gerrit seems to have died, reviving it here for a 
> larger audience.

I will quote below what I already wrote in gerrit [2], [3]:

The trouble is the entire PCI subsystem in ramstage is based on
matching the vendor/device ID register with a PCI driver and to the
source we want to control that device with. To allow this hiding of
PCI devices will ultimately force us to write the control somewhere in
the scope of SOC instead. Oh, but wait, perhaps the intention is for
us to __not__ write that control anymore but let the FSP blob do all
that too!

AFAICS, hardware that does not respond to vendor/device ID register
reads does not meet PCI compliance. I am willing to hit +2 on removing
support for platforms that do not meet PCI compliance, specially when
in the cases here, it is a matter of broken FSP blobs and not broken
silicon per-se.

Also, I should not be accepting new callers for dev_find_slot() due
the ill semantics it has. Prior to device enumeration, it can return
false positives because all devices appear on bus 0. So please look
for alternative solution if you want to support Intel's initiative of
more blob less FOSS.

I suggest you post on the mailing list. That active PCI devices no
longer respond to Vendor ID / Device ID queries does not meet PCI
compliance, as I understand the specs. Unfortunately, someone with
enough authority inside the org will likely decide it's just fine that
ramstage will no longer be designed using PCI drivers and allow use of
shim calling massive FSP blob.


As for solutions:

Preferably fix FSP and not allow this PCI hide-and-seek.

or

Rewrite PCI device enumeration such that devices that do not respond
to ID queries are not permanently removed from topology links. You
need platform hooks to decide whether to remove a particular device
(based on B:D.F) or not. This would avoid ill dev_find_slot() then.

or

Revert to __SIMPLE_DEVICE__ for PCI access. But __SIMPLE_DEVICE__ is
also on my kill list due to uglyness and high maintenance whenever we
attempt to move sources to earlier stages. Unfortunately things found
in soc/intel has slowed down the process to standstill and work is not
funded.

[1] https://review.coreboot.org/c/coreboot/+/26447
[2] https://review.coreboot.org/c/coreboot/+/35087
[3] https://review.coreboot.org/c/coreboot/+/35088

Regards,
Kyösti Mälkki
___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] Re: ASUS AM1I-A and AM1M-A, ECC

[Kyösti Mälkki]

On Thu, Sep 26, 2019 at 4:34 AM Matt B  wrote:
>
> Hello,
>
> This might be a dumb question, but not having a manual to go off of, would 
> the ECC ram have to be buffered or unbuffered? (if it can be made to work 
> with the AM1I-A at all) Any other important specifications?
>
> I bought a AM1I-A (I've had my eye on a good deal on ebay) and it should be 
> here in a couple of weeks.

ECC signals between DIMM sockets and AM3 are not routed in AM1I-A
boardview files I found, while they are in AM1M-A boardview.

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

[coreboot] Re: [BUG] nonexisting function current_time_from

[Kyösti Mälkki]

On Sun, Sep 22, 2019 at 7:56 PM Petr Cvek  wrote:
>
> Enabling X86EMU_DEBUG_TIMINGS config option will cause the compilation to 
> fail with:
>

Not a big surprise, see [1].

> In file included from src/device/oprom/yabel/debug.h:48,
>  from src/device/oprom/yabel/biosemu.c:39:
> src/device/oprom/yabel/biosemu.c: In function 'biosemu':
> src/device/oprom/yabel/debug.h:103:66: error: implicit declaration of 
> function 'current_time_from' [-Werror=implicit-function-declaration]
>   103 | #define DEBUG_PRINTF_CS_IP(_x...) DEBUG_PRINTF("[%08lx]%x:%x ", 
> (current_time_from()).microseconds, M.x86.R_CS, M.x86.R_IP); 
> DEBUG_PRINTF(_x);
>
> It seems there isn't current_time_from() defined anywhere.

See [2] that removed it in 2015, might be a quite clean revert to bring it back.

[1] https://review.coreboot.org/c/coreboot/+/34201
[2] https://review.coreboot.org/c/coreboot/+/8896/

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

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

[Kyösti Mälkki]

On Sat, Sep 21, 2019 at 5:18 AM Matt B  wrote:
>>
>> There is essentially no interest for new board ports on AGESA/binaryPI, 
>> these platforms have mostly survived in the tree due to commercial support 
>> to maintain them.
>
> This seems to be untrue when boards like the Asus AM1I-A were ported as 
> recently as last year. [1] It's a AMD family 16h board that looks like it 
> calls into binaryPI based AGESA a number of times, judging by the boot logs 
> on the wiki. [2]

Like Martin noted above, board-status for asus/am1i-a is from
mid-2018. Now it's not uncommon to lose interest after initial port is
merged, aspecially if that board turned into a NAS production system,
but the next big board obsoletion criteria might be the lack of active
testing. Those who actively do testing and development on lenovo/g505s
and asus/f2a85-m, thank you.

I could rephrase what I said before but it will just look worse or
offending to some: Those who have contributed to coreboot in form of
new boards ports, using scrubbed AGESA vendorcode or binaryPI blobs,
have never shown much interest to evolve the platform code (in
coreboot proper). This very much applies to original authors AMD AES
(R.I.P.) and SAGE (R.I.P.), AGESA and binaryPI only survived over
LATE_CBMEM_INIT deprecation thanks to PC Engines support.

Kyösti Mälkki
___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

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

[Kyösti Mälkki]

On Thu, Sep 19, 2019 at 11:12 AM Nico Huber  wrote:
>
> 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

Interesting. In terms of lines of code, probably 75% of AGESA glue
logic in ports has already been removed. But I agree, aside from
release requirements, there is lots left that could be done. There is
essentially no interest for new board ports on AGESA/binaryPI, these
platforms have mostly survived in the tree due to commercial support
to maintain them.

Kyösti Mälkki
___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

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

[Kyösti Mälkki]

On Thu, Sep 19, 2019 at 3:20 AM Matt B  wrote:
>
>
> Kyösti Mälkki said:
>>
>> AFAICS, that platform codebase even suffers from cache coherency issues 
>> while executing from cache-as-ram; there has been indications that increased 
>> spinlock usage in romstage causes boot failures and/or reset loops.
>
>
> Where do you see this? Has it been reported?

It was the plausible reason for the revert:
https://review.coreboot.org/c/coreboot/+/30830 where seemingly legit
code change trigger bugs.

Like with many RAM related problems on same platform(s) running with
upstream coreboot, those with hardware have not bisected or debugged
this further to have definite answers. I can tell AGESA fam14 has
issues with AP's accessing CAR.

>> Implementation of HyperTransport requires maintaining some pretty strange 
>> (or poor-quality) code for both static devicetree and PCI subsystem.
>
>
> Which code? How can it be improved?

Unless platform meets release requirements, there will be a commit to
remove offending/bad code with explanations. As noted earlier, pretty
much none of the promises from last five years to
debug/bisect/improve, by various people on the mailing list, have not
been fulfilled. My goodwill with fam10-15 is long gone.

Regards,
Kyösti Mälkki
___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

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

[Kyösti Mälkki]

On Thu, Sep 19, 2019 at 1:05 AM Martin Roth  wrote:
>
> My proposal is to drop platforms that aren't being tested, aren't
> being maintained, or are causing serious problems with general
> coreboot development.
>
> For example
> - ASUS KGPE-d16 is still being used and tested, so I wouldn't suggest
> dropping that code, even though it apparently doesn't support S3, so
> it was suggested that we drop it.  S3 isn't used heavily on servers,
> so personally I don't think it matters.

Nothing to do with S3 for asus/kgpe-d16 deprecation.

Platform code (non-AGESA) fam10-15 does not meet 3 of the 3 announced
requirements for next release. Should someone want to maintain
kgpe-d16 on master branch, the decisions on those release requirements
will need to be officially withdrawn. AFAICS, that platform codebase
even suffers from cache coherency issues while executing from
cache-as-ram; there has been indications that increased spinlock usage
in romstage causes boot failures and/or reset loops.

Implementation of HyperTransport requires maintaining some pretty
strange (or poor-quality) code for both static devicetree and PCI
subsystem.

Regards,
Kyösti Mälkki
___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

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

[Kyösti Mälkki]

On Thu, Sep 12, 2019 at 5:43 PM Patrick Georgi via coreboot
 wrote:
>
> Hi everybody,
>
> coreboot is shipping AMD's open sourced AGESA for a few generations
> as part of its tree.
>
> Some people advocate dropping the code due to its quality and lack
> of maintenance while others are happy with using the code.

Would "some people" or these "advocates" be willing to elaborate?
Pretty much none of the style guide rules have ever been applied to
vendorcode, if this is about clang-format or source code style in
vendorcode/.

> So: to help keep this code alive, we'd need maintainers - people
> willing to work through issues, improve the code quality and generally
> act as a point of contact if any questions arise.

I would say >50% of our MAINTAINERS file is just bogus when it comes
to working through issues. We can equally make such quality assurance
arguments about FSP2.0, once commercial vendor gets something merged,
they don't really care how much it gets in the way of overall
architecture or subsystems evolution. As an active topic, I don't see
anybody at Intel willing to discuss the topic of how hiding PCI
devices may brake PCI compliance and generally several assumptions in
coreboot PCI subsystem.

Previous decisions by coreboot leadership and/or community meeting
minutes were to let platform obsolition be determined by a) release
requirements, typically announced at least 12 months beforehand and b)
lack of board-status submissions. Do you want to extend this with c)
coverity scan over vendorcode/ ?

> One item to start with could be to work through Coverity
> issues, where the largest proportion is now AGESA based
> after Jacob cleaned up most of the rest of the tree. See
> https://scan.coverity.com/projects/coreboot

Since coreboot seems to accept blobs with ease nowadays, the solution
to keep these platforms can be such that we move AGESA vendorcode to
submodule. We already have infrastructure to embed AGESA as a blob
into CBFS/FMAP. Method has been approved for amd/stoneyridge, so there
should be little to complain about it. Neither coverity or
clang-format rules need to extend to 3rdparty repositories.

> Drivers needs support to not get in the way of later development,
> and AGESA is sorely lacking in that department. If you see value
> in that code, please step up now, not only when we're looking into
> removing that code for good.

Please give detailed sample where AGESA or binaryPI (inside coreboot
proper, not vendorcode) is "sorely lacking or getting in the way" of
current developments. Reference to some already existing gerrit
comments or mailing list posts would be nice. I agree there are things
like SMM_ASEG=y, PARALLEL_MP=n. Do you have something completely
different in mind? I am not surprised if you wanted to deprecate
util/romcc rather sooner than later. If that is the driving force, it
is already covered with requirements for next release.

AGESA may reach C_ENVIRONMENT_BOOTBLOCK by the time of the next
release and is already at CAR_GLOBAL_MIGRATION=n. Situation with
binaryPI is actually worse, selected boards may meet requirements
though. The timeframe for dropping entire platforms has previously
been couple releases or couple years, you are making it sound like you
want to drop AGESA vendorcode like tomorrow.

Regards,
Kyösti Mälkki
___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] Re: Verified boot on AMD Picasso

[Kyösti Mälkki]

On Fri, Aug 23, 2019 at 10:32 PM Patrick Georgi  wrote:
>
> On Fri, Aug 23, 2019 at 10:23:06PM +0300, Kyösti Mälkki wrote:
> > Is everything still under non-disclosure about those made
> > compromises, or is someone willing to reveal in public what we should
> > expect this time?
> I don't know timelines, decisions made or agreements under which these were
> made (e.g. NDAs).
>
> I'll point out the thread to people who may know more, but I can't promise a
> response given that I don't know the constraints.
>

Sometimes it is not that I didn't know who to ask, but that I receive
partial answers in private email exchange. Since they know I am not
under their NDA, any information they give me in private emails should
equally be available to other developers. And yes, it's not really my
problem if they are breaching or bending their NDA, it's theirs. I
read several paragraphs about this vboot/verstage running on PSP and
all that should have just appeared under Documentation/ instead.

Regarding this thread; at least the question about toolchain remains
without an answer. If we go back to early amd/stoneyridge, the first
iteration wanted to call (unverified but possibly read-only) AGESA
blob from within bootblock, before verstage. I believe the approach
was vetoed and rejected by some security advisory team at Chromium,
invalidating perhaps a couple month's worth of development work? We
are dealing with verstage here again, I want confirmations that the
compromises get evaluated before we put more effort on attempts to
merge the work.

Kind Regards,
Kyösti Mälkki
___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] Re: Verified boot on AMD Picasso

[Kyösti Mälkki]

On Fri, Aug 23, 2019 at 9:25 PM Patrick Georgi  wrote:
>
>
> I wish we could reach the global maximum as well, but that's not in
> our hands.
>
> And here we end up with the age old disagreement in whether we should
> be open to compromise and keep the conversation going (hopefully in
> the right direction, although sometimes that's hard) or take our toys
> and leave.
>

Well, not quite the age old disagreement, but close.

In the case of AMD Picasso I  believe those conversations about the
role of PSP have been completed, behind closed doors, sometime last
spring. Is everything still under non-disclosure about those made
compromises, or is someone willing to reveal in public what we should
expect this time?

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

[coreboot] Re: Verified boot on AMD Picasso

[Kyösti Mälkki]

On Fri, Aug 23, 2019 at 3:06 PM Patrick Georgi  wrote:
>
> On Fri, Aug 23, 2019 at 02:38:13PM +0300, Kyösti Mälkki wrote:
> > short; appers it has been decided verstage will run on PSP instead of
> > x86 cores.
> verstage isn't used for all coreboot configuration, and while it
> originated with Chrome OS firmware it has been extended to cover other
> use-cases as well. It might help if you could outline the impact to
> various scenarios.

At the moment I don't know if verstage will be compulsory on
amd/picasso. While the commercial development may target Chromebooks
only, it would be nice to leave the opportunity for community ports
using same SoC. Admittedly, that community interest never surfaced
with amd/stoneyrige or any of the other older binaryPI platforms.

> > So which of the following approaches do You find acceptable:
> Generally speaking, from a license perspective, ...?

Quoting website frontpage; "As an Open Source project it (coreboot)
provides auditability and maximum control over technology. "

FOSS to blob ratio in coreboot images, when only accounting for x86
code, is something like 1:8 with recent Intel hardware and FSP. I am
wondering if trademark holder wishes or dares to draw the line
somewhere.

> Note that vboot_reference is BSD-licensed, so depending on how this
> is implemented specifically, GPL compliance might not matter much.

Right, GPL may not apply. Just that for x86 vboot links with coreboot
console code, that's where the reference for GPL compliance came from.

> That said:
>
> > a) Platform shall use proprietary ARM TrustZone instead of vboot for
> > any cryptographics and measurements of firmware. This may be the AMD
> > endorsed way of doing things.
> Silicon vendors often endorse things that seem nonsensical
> for us. Doesn't mean that they're the only way to approach
> things. (Example: Intel recommending to use FSP-T instead of open
> CAR code).
>
> > b) Platform shall use vboot, built and signed internally at AMD, for
> > the Security Processor (aka PSP), using their choice of proprietary
> > tools.
> Non-opensource toolchains are often much more painful to deal with
> than the opensource ones. If they want to inflict that pain onto
> themselves, there's little we can do about it.
>
> > While GPL compliance may say build scripts are to be published
> > in such case (IANAL!!), that does not mean the used compiler is
> > available for purchase on open market.
> As discussed above: that depends a lot on what the actual
> implementation looks like.
>
> > c) Platform shall use vboot, built using an extended __and published__
> > coreboot toolchain. Built PSP vboot binary shall be reproducible and
> > signed with OEM key. Community developers will not be able to run
> > custom verstage builds, but are able to audit integrity of the source.
> >
> > d) Platform shall use vboot, built using an extended __and published__
> > coreboot toolchain. Built PSP vboot binary should be reproducible.
> > Community developers are able to run custom verstage builds, but state
> > of PSP/TPM/etc may reveal to the OS that sections of the firmware does
> > not originate from the OEM, as detected by the lack of signage or use
> > of insecure key published for experimental use only. User experience
> > or DRM might suffer.
> >
> > e) Platform shall use vboot, built using an extended __and published__
> > coreboot toolchain. Developers can run whatever they want on PSP,
> > without OS ever noticing it.
>
> A generalization of d) would be preferable: Provide a secure channel
> to determine the signer of the firmware, no matter who that is. Some
> optional features (like DRM) could depend on having some form of
> "blessed" signature.
>
> That way every customer and user could implement their desired security
> model without being able to impersonate anybody else.

I agree. I really wish options a) and b) would be ruled out for one
reason or another.

>
> I'm not sure about the thrust of your inquiry: Some of it sounds like
> damage control with regard to licensing (e.g. option b), options
> c to f sound more like collecting requirements for a platform's
> security model.

Major thrust is if verstage becomes yet another blob we cannot audit.
In practice that happens in options a) and b). Having reproducible
binary created with known reference toolchain is in my opinion the
absolute minimal requirement.

Also with c) d) and e), it would be feasible to build rmodule loader
into the PSP firmware and load romstage as an rmodule? (I am probably
late with this idea, I believe tools have already been prepared to
provide a compressed flat romstage binary instead, linked to a fixed
DRAM location).

> For the 

[coreboot] Verified boot on AMD Picasso

[Kyösti Mälkki]

Open letter to coreboot leadership

I have spent some time helping out sort some fundamentals on the tree
to bring up that new amd/picasso platforms. During the reviews I found
some proceedings there somewhat alarming, so I am hoping for coreboot
leadership and trademark holder to make some clear statements on the
topic.

Now, I may know a bit more than I can write here in public, I try
defer from disclosing information received in private emails and stick
with the information that can be found in gerrit review commits. In
short; appers it has been decided verstage will run on PSP instead of
x86 cores.

So which of the following approaches do You find acceptable:

a) Platform shall use proprietary ARM TrustZone instead of vboot for
any cryptographics and measurements of firmware. This may be the AMD
endorsed way of doing things.

b) Platform shall use vboot, built and signed internally at AMD, for
the Security Processor (aka PSP), using their choice of proprietary
tools. While GPL compliance may say build scripts are to be published
in such case (IANAL!!), that does not mean the used compiler is
available for purchase on open market.

c) Platform shall use vboot, built using an extended __and published__
coreboot toolchain. Built PSP vboot binary shall be reproducible and
signed with OEM key. Community developers will not be able to run
custom verstage builds, but are able to audit integrity of the source.

d) Platform shall use vboot, built using an extended __and published__
coreboot toolchain. Built PSP vboot binary should be reproducible.
Community developers are able to run custom verstage builds, but state
of PSP/TPM/etc may reveal to the OS that sections of the firmware does
not originate from the OEM, as detected by the lack of signage or use
of insecure key published for experimental use only. User experience
or DRM might suffer.

e) Platform shall use vboot, built using an extended __and published__
coreboot toolchain. Developers can run whatever they want on PSP,
without OS ever noticing it.

f) Something else in between the presented choices or outside of them?

Regards,
Kyösti Mälkki
___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] Re: Final calls for S3 suspend support on amdfam10-15

[Kyösti Mälkki]

On Thu, Aug 22, 2019 at 4:59 AM Matt B  wrote:
>>
>> I believe S3 resume path is PSP assisted. When x86 core reset is deasserted 
>> some parts of the memory controller PHY have already been programmed by PSP 
>> or SMU firmwares.
>
> (No PSP present on the G505s)

Perhaps my commentary was not so clear, this was meant in the context
of amd/stoneyridged.

>
>>
>> You should consider binaryPI mostly broken for the purpose of S3 
>> suspend/resume.
>>
>> AMD never got S3 right for open-source AGESA and I think they struggled long 
>> to get it right for amd/stoneyridge.
>
> Does this and the above regarding the PSP mean that S3 is impossible on the 
> G505s (open-source AGESA), or would otherwise require changes to the AGESA 
> source? (even if C_ENVIRONMENT_BOOTBLOCK were implemented? If I understand 
> correctly the other two requirements are already fulfilled?)

Absolutely not! G505s does have working S3 support. We (coreboot
community) got it right while AMD did not. ACPI S3 support is not in
the release requirements. For G505s and other open-source AGESA,
C_ENVIRONMENT_BOOTBLOCK is what is currently lacking. For binaryPI,
like mentioned, POSTCAR_STAGE=y support code is mostly there but the
platform code is landing slowly.

>> I have been told that later AGESAv5 firmwares do not have the capability of 
>> "MRC cache" to speed up cold boot as they lack the (x86) code to replay 
>> memory training parameters from non-volatile memory.
>
> Does this apply to the G505s? I presume that it's version of AGESA predates 
> that used to create the PI binaries.

Different reason why it does apply to G505s; our copy of family15tn
AGESA source was so old the feature was not yet implemented, at least
correctly. For family16kb this feature does work [1].

asrock/imb-a180:
   0:1st timestamp 1,923
   1:start of romstage 1,972 (48)
   2:before ram initialization 67,680 (65,707)
   3:after ram initialization  2,572,863 (2,505,183)
   4:end of romstage   2,584,322 (11,458)

versus
   0:1st timestamp 1,924
   1:start of romstage 1,973 (48)
   2:before ram initialization 67,988 (66,014)
   3:after ram initialization  397,508 (329,520)
   4:end of romstage   408,894 (11,386)

[1] https://review.coreboot.org/c/coreboot/+/20597

Regards,
Kyösti Mälkki
___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] Re: Final calls for S3 suspend support on amdfam10-15

[Kyösti Mälkki]

On Wed, Aug 21, 2019 at 7:52 PM Raul Rangel  wrote:
>
> You can grep for commits containing b:65442212 or b:111610455 to see the work 
> required to remove AGESA from bootblock.

Thanks!

Some of that seems very SoC or hardware specific. I think we will go
ahead with a bootblock that does nothing else but sets up CAR and
finds a romstage.elf to jump into. At this time verstage is not a
requirement so we'll just ignore any LPC or SPI PAD configurations TPM
might need.

In general, changes from amd/stoneyridge do not apply to previous
binaryPI builds. A different set of modifications to StoneyPI were
made in comparison to the changes that SAGE had previously made to
MullinsPI, KaveriPI and CarrizoPI. Also AMD rolled out a custom PSP
firmware build for Chromebooks? So it is possible the implementation
of AGESAv5 API we have for amd/stoneyridge is only compatible with the
modified StoneyPI source tree and the modified PSP firmware. And the
PSP mailbox APIs are not exactly the same across different SoCs
either.

Regards,
Kyösti Mälkki
___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] Re: Final calls for S3 suspend support on amdfam10-15

[Kyösti Mälkki]

On Wed, Aug 21, 2019 at 6:53 PM Michal Zygowski
 wrote:
>> I get the overall idea of C bootblock. The most fun is about the
> assembly to setup CAR early. But what about S3 suspend/resume for APU2
> for example? It is not supported by the platform and does not seem to be
> needed at all there (it is just a router which should be always on).
> Maybe the check for RELOCATABLE_RAMSTAGE should be omitted when
> HAVE_ACPI_RESUME is not set for the platform? However the thing is all
> about southbridge/northbridge code still.

You should consider binaryPI mostly broken for the purpose of S3
suspend/resume. I did not understand what you mean about a
RELOCATABLE_RAMSTAGE check.

AMD never got S3 right for open-source AGESA and I think they
struggled long to get it right for amd/stoneyridge. I believe S3
resume path is PSP assisted. When x86 core reset is deasserted some
parts of the memory controller PHY have already been programmed by PSP
or SMU firmwares. I have been told that later AGESAv5 firmwares do not
have the capability of "MRC cache" to speed up cold boot as they lack
the (x86) code to replay memory training parameters from non-volatile
memory.

>> That stoneyridge thing is interesting... Cannot imagine what it could be
> called for such early.

A lot of that review is public in gerrit, maybe January-March 2017.

Regards,
Kyösti Mälkki
___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] Re: Final calls for S3 suspend support on amdfam10-15

[Kyösti Mälkki]

On Wed, Aug 21, 2019 at 9:23 AM Michal Zygowski
 wrote:
>
> Hello Kyösti,
>
> Giving such a "credit" to give a little more time to bring the platform
> to release requirements sounds like a good idea.
>
> 3mdeb will surely approach to implement those changes based on family
> 14h apu1, as well as for binary PI familty 16h based on apu2 (postcar
> support already slowly landing to the binaryPI). Although these are
> AGESA and binaryPI types, will the same approach be applicable here?
>

Nice, let's coordinate the efforts on PC Engines products.

The principles are the same, move CAR init from the start of romstage
to start of bootblock. There are some things to consider about CAR
memory layout and stack, but nothing major there. An aspect for
possible future deployment of verstage is that calling vendorcode or
binaryPI blob from bootblock is discouraged. We should not need the
binaryPI blob to setup LPC routes or any SoC PAD configurations so
enabling console in bootblock should not be an issue for us. I can't
remember why the initial work on amd/stoneyridge called (unverified
but read-only) vendorcode blob already from within the bootblock.
Maybe it was something about GPIOs.

Regards,
Kyösti Mälkki
___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] Re: Final calls for S3 suspend support on amdfam10-15

[Kyösti Mälkki]

On Wed, Aug 21, 2019 at 5:43 AM Matt B  wrote:
>
> Is a lack of C bootblock support common to all family 15h platforms? 
> (Including the G505s and any others?)
> In other words, would it only need to be implemented once for all of these 
> systems?
>

It's not really a CPU family thing at all, but about the
implementation otherwise. It's one fix for all AGESA, one for all
binaryPI, and a third one for native amdfam10-15.

My suggestion on moving forwards with amdfam10-15 is as follows:

The next release is scheduled for Oct 2019 (?). Regardless of when
that happens, I would introduce a flag on the October 1st that
disables all amdfam10-15 boards from the automatic build. Then, if we
have anyone capable and willing to have this amdfam10-15 stay on
master branch, she/he would get to select one mainboard for which the
build would remain enabled. The platform code then needs to go through
the transitions of =>RELOCATABLE_RAMSTAGE, =>POSTCAR_STAGE,
=>C_ENVIRONMENT_BOOTBLOCK. During that process, any remaining #include
<*.c> are to be removed and regressions other amdfam10-15 boards
__are__ allowed and will be ignored as the builds are disabled, Once
the reference platform reaches a state where it fulfills the release
requirements, interested parties can port the necessary changes to
individual motherboards. Providing boot-logs is a necessity. At the
time of next release, boards that don't build will have their source
files removed.

Regards,
Kyösti Mälkki
___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] Re: Final calls for S3 suspend support on amdfam10-15

[Kyösti Mälkki]

On Wed, Aug 21, 2019 at 5:57 AM Thierry Laurion - Insurgo Technologies
Libres / Open Technologies  wrote:
>
> I could provide such resume logs for kgpe-d16.
>
> How do I produce them?
>

Cold boot, enter OS, enter S3 suspsnd. Wake up (probably toggle power
button, moving mouse or anykey might not do it), then run 'sudo cbmem
-1; sudo cbmem -c' after OS resumes and you have commandline. Also
'dmesg' would be nice.

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

[coreboot] Final calls for S3 suspend support on amdfam10-15

[Kyösti Mälkki]

Hi

The decisions are out on 4.11 release requirements. Unless anyone acts
on it, amdfam10-15 boards will hit deprecation due to:
* RELOCATABLE_RAMSTAGE=n
* CAR_GLOBAL_MIGRATION=y
* C_ENVIRONMENT_BOOTBLOCK=n

To smooth down the path, should anyone want to attempt on fixing
these, I have pushed a patchset [1] that removes S3 suspend support
from said platform. Depending of what the response is, I hope to have
that submitted already before 4.11 release.

The latest info [2] I have is asus/kcma-d8 not working and
asus/kgpe-d16 working in 4.6 but very slowly, for S3 resume boot, that
is. No resume logs have been brought to my knowledge for 12 months. I
also had some suspicions that tests results were mistakenly from
suspend-to-disk (S4).

Affected boards are asus/kcma-d8 and asus/kgpe-d16.

[1] https://review.coreboot.org/c/coreboot/+/15474
[2] https://mail.coreboot.org/pipermail/coreboot/2018-June/086906.html

Kind regards,
Kyösti
___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] Re: [AMD 16h / ASUS AM1I-A] 1866MHz CL9 RAM runs only as 1333MHz CL9 - how to fix?

[Kyösti Mälkki]

On Fri, Jul 5, 2019 at 5:36 PM Mike Banon  wrote:
>
> Thank you for advice. I followed the instructions of this change, and
> after fixing a few compilation errors (had to replace a few %x with
> %llu at printf's) - using the same .config - I got a ROM which is
> unbootable! Maybe because I don't have AMD HDT Debugger, and it
> should've been connected to some usually-not-soldered header for this
> ROM to boot?

You don't need HDT debugger. At least I have not experienced IDS
troubles because of not having one connected. But go through the IDS
options...

> Perhaps I can manually redirect these IDS prints to a standard
> coreboot log - if that will give some useful info. Or I could dive
> into AGESA and replace all DDR1333 stuff with a DDR1866 one, to force
> it running as 1866MHz CL9 - since that "#define
> BLDCFG_MEMORY_CLOCK_SELECT" seemingly doesn't work for some reason.

That's what is supposed to happen already, it should dump all IDS
debug on serial console. Or whatever console you have enabled, IDS is
routed to printk(). Boots will be slow due the amount of data, maybe
30 seconds or so to get past ram training. There's lots of filtering
inside AGESA you can adjust.

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

[coreboot] Re: [AMD 16h / ASUS AM1I-A] 1866MHz CL9 RAM runs only as 1333MHz CL9 - how to fix?

[Kyösti Mälkki]

On Wed, Jul 3, 2019 at 8:54 PM Mike Banon  wrote:
>
> A pair of 1866MHz CL9 RAM modules* runs only as 1333MHz CL9 on 16h
> AM1I-A with coreboot is installed, but worked faster when a
> proprietary UEFI was installed. To fix this "turtle RAM" coreboot
> problem I tried to play with buildOpts.c -
> https://review.coreboot.org/c/coreboot/+/33920 , but the things like
> "#define BLDCFG_MEMORY_CLOCK_SELECT DDR1866_FREQUENCY" sadly did not
> help.
>
> Any ideas how to improve the RAM speeds? How I can force this RAM to run 
> faster?
>

Maybe AGESA debugging / IDS tracing is of some assistance? I have not
tried it for a while, though.

https://review.coreboot.org/c/coreboot/+/15320/7

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

[coreboot] Re: Question about blobs

[Kyösti Mälkki]

On Tue, Jul 2, 2019 at 1:01 PM Jorge Fernandez Monteagudo
 wrote:
>
> Hi all,
>
> I would like to know the source of the AGESA.bin blobs I've seen in the 
> 3rdparty directory. For instance, the 
> '3rdparty/blobs/pi/amd/00670F00/FP4/AGESA.bin'. Is it generated by AMD? Is it 
> compiled from a NDA file by a coreboot developer?

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.

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.

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?


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

[coreboot] Re: e820 memory map

[Kyösti Mälkki]

On Mon, Jun 10, 2019 at 11:22 PM Andrew A. I.  wrote:
>
> Hello, Kyösti!
> cbmem log in attachment.
> I am rebooting and/or powering off after upgrading corboot firmware for 
> verify. It doesn't help, as I remember.
>

Logs from both a cold boot and hibernation resume would be needed for
comparison.

But this pretty much sounds like the case of entering ACPI S4 from a
boot that did memory training and wrote MRC CACHE in SPI. This is the
known failing case described earlier.

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

[coreboot] Re: e820 memory map

[Kyösti Mälkki]

On Mon, Jun 10, 2019 at 9:15 PM Andrew A. I.  wrote:
>
> Hello!
> Please, someone tell me, why SeaBIOS changing e820 memory map for 0x10 - 
> 0x7ff2dfff region? For example:
>

Could you collect and share the coreboot logs with 'util/cbmem -1'.
I've seen similar hibernate/resume failure before, it was then related
to the changed memory layout of coreboot tables (which is reflected in
the e820 table SeaBIOS creates). In short, hibernate (ACPI S4) does
not work on the first boot after flashing firmware or change of DIMMs.
It's about MRC CACHE being allocated in CBMEM for the initial boot,
but not the following resume boots.

If this is your case too, there should be an easy fix by adding a
dummy reserve, but sounds like nobody has taken the initiative to
submit such change. As an alternative solution, I would like to see
runtime code to mask of ACPI S4 and S3 features from SSDT/DSDT.

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

[coreboot] Re: How to enable the SMBus0 in coreboot for Intel Atom C2000?

[Kyösti Mälkki]

On Fri, May 31, 2019 at 5:24 PM Дмитрий Понаморев  wrote:
>
> Unfortunately, FITs does not have any settings for SMBus enable/disable and 
> so on. In general, this program for Edisonville_Rangeley is very poor 
> settings.
>
> Thanks for youre advice Kyösti! I add files with logs. I tried to play with 
> the enable_smbus() function but without result. Rather, the result is the 
> same - no devices on i2c-1.
> You can see the comparison of devices on (SMBus0) i2c-1 bus with the OEM Bios 
> and with Coreboot bios in i2cdetect.log.
> Could nuvoton superio somehow affect the SMBus?
>
> I also noticed errors in dmesg output such:
> [   93.737732] i801_smbus :00:1f.3: Timeout waiting for interrupt!
> [   93.744750] i801_smbus :00:1f.3: Transaction timeout
>

That is a fairly strong suggestion that PCI 0:1f.3 does not have
correct interrupt routing, but I did not check the logs yet.

You might be able to use polling instead and add more verbose debug
logging for driver i2c-i801, just to get further now with the SMBus
part.

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

[coreboot] Re: How to enable the SMBus0 in coreboot for Intel Atom C2000?

[Kyösti Mälkki]

On Wed, May 29, 2019 at 5:48 PM  wrote:
>
> There is motherboard based on the Intel Rangeley Atom C2000 (C2758) series 
> processor. How to enable the SMBus0 in coreboot? If I use OEM BIOS or BIOS 
> from Intel (EDVLCRB1.86B.0048.R00.1508181657_MPK) for mohon peak crb, then I 
> see on the SMBus0 (i2c-1 in Fedora 28) memory DIMM spd (0x50 & 0x52), clock 
> generator (0x69) and other devices. If I use a coreboot based bios for the 
> Mohon peak platform - I do not see any devices on i2c-1. I see an data 
> exchange on the SMBus0 with oscilloscope at boot time only. When I send 
> "i2cdetect -y 1" command in Linux no activity on SMBus0 and no device found.

Your chances of getting support are much better when you provide more
context and logfiles. We would probably need relevant lines from
system logs (dmesg) and outputs from 'i2cdetect' and 'lspci -xx' here,
both OEM BIOS and coreboot. For coreboot, also 'cbmem -1'. Would not
hurt if you pushed your mainboard port as a draft to gerrit or make
your work otherwise accesible.

What we have in rangeley_smbus_read_resources() does not look that
good, it may leave SMBUS IO BAR unset in the hardware. Might be simply
case of calling enable_smbus() in romstage for the board to get that
fixed.

Regards,
Kyösti Mälkki
___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] Re: How to add NUVOTON NCT6776F support with serial port logic enabled ???

[Kyösti Mälkki]

On Fri, May 24, 2019 at 5:23 PM Дмитрий Понаморев  wrote:
>
> Thank for help!
>
> The LPC_CLKOUT1 clock signal appeared but there is no nuvoton chip detected 
> in linux.
>

Well couple things you need to check in the hardware then:

Probe the LPC FRAME signal or use a logic analyzer to see if there is
any LPC activity while you run util/superiotool.
Check from Nuvoton datasheet if it requires LPC CLK to be present
before its RESET signal is de-asserted.
Check if Nuvoton has otherwise a sane power-up sequence (Vcc, Vstb
rise-up vs RESET pins).

> I could not turn off the SOC UART yet. With my changes, the system does not 
> start well (stops at post code 0x46, 0x47).

Disable coreboot console output to serial port for now. When neither
UART is present, it might just be hitting transmit timeout for every
single character, making it boot ridiculously slow. If you can boot to
OS, you can still read the logs with util/cbmem.

> And the most important thing is that the Nuvoton System Clock (48 MHz for the 
> baud generator of the UARTs) is missing.

This may be preventing util/superiotool from detecting the chip. I
think I have seen some SIO parts respond to ID queries even without
this clock if LPC CLK is present.

> How can I change the IDT clock synthesizer (9VRS4420DKLFT) settings in 
> coreboot? Rather, where can I make changes in coreboot to properly configure 
> IDT clock synthesizer (9VRS4420DKLFT)?

Grep the source for smbus_block_write. There is drivers/ck505 and
lenovo/x201 that you can use as base for your modifications. Sometimes
these IDT datasheets are hard to get and you may need to capture the
correct commands from SMBus signals or with utilities from i2c-tools
package after booting with OEM firmware.

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

[coreboot] Re: How to add NUVOTON NCT6776F support with serial port logic enabled ???

[Kyösti Mälkki]

On Wed, May 22, 2019 at 6:14 PM Дмитрий Понаморев  wrote:
>
> The controversial decision but the console output is not connected directly 
> to the processor but to the superio Nuvoton.
> I did not find any settings to enable LPC (LPC_EN) for the Atom C2000 to.
> In atom-c2000-microserver-datasheet-334978.pdf I found register LPCC (LPC 
> control register).
> This register includes LPC_CLKOUT1. As far as I understood, the nuvoton uses 
> this signal.
>

Okay then. The paragraphs of datasheet you should be interested are:

24.2.4 about the LPC routing rules. It says anything not positively
decoded by SOC integrated peripherals will be routed to LPC.

20.2 and 20.3 to disable the SoC's integrated UART devices. When
enabled, they would positively decode 0x3f8 and 0x2f8 (bases) and
prevent those from being routed to LPC controller.

If you previously did not have LPC_CLK running for the Nuvoton part in
your coreboot build, it explains why util/superiotool did not detect
Nuvoton. If you did not do so already, run that tool again. Hopefully
you see something on 0x4e  now.

SuperIOs typically have another clock input pin (either 24 MHz or 48
MHz) for the baud generator of the UARTs. If you get that Nuvoton
detected, and disable SoC UARTs, and still have no serial output, I
would trace the source for that clock next.

Regards,
Kyösti
___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] Re: How to add NUVOTON NCT6776F support with serial port logic enabled ???

[Kyösti Mälkki]

On Fri, May 17, 2019 at 6:02 PM  wrote:
>
> There is a Lanner FW-7573 platform based on the Intel Rangeley Atom C2000 
> series processor.
> To work with the Serial port in this platform, the NUVOTON NCT6776F chip is 
> connected via the LPC bus to the processor.
> I just can’t get Serial port working for debuging. I take as a basis intel 
> littleplains board.  I tried to add NCT6776F support following the example of 
> other boards - without success. There is no output to the console, and in 
> Linux, the superiotool program does not see the NCT6776F.

Check the datasheets for PCI 0:1f.0 register LPC_EN (or search for
0x4e). Might be register 0x82 but I don't know for sure for Rangeley.
I did not notice any code that would enable routing 4e/4f to LPC bus
under southbridge/fsp_rangely or mainboard/littleplains.

> On the official version of the BIOS I loaded linux OS and took a dump.  
> (superiotool r => Found Nuvoton NCT6776F/D (C) (id=0xc333) at 0x4e) )

You can also compare the register banks of PCI 0:1f.0.

HTH,
Kyösti
___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] Re: RFC: Replacing IS_ENABLED(CONFIG_XXX) with the shorter CONFIG(XXX)

[Kyösti Mälkki]

On Wed, Mar 6, 2019 at 3:52 AM Julius Werner  wrote:

> Hi folks,
>
> I'm proposing a small policy change for the way we refer to boolean
> Kconfig variables in code. Right now, the directive is to always use the
> IS_ENABLED() macro. I would like to replace this with a shorter macro
> CONFIG() that also removes the need to type the CONFIG_ prefix again. The
> idea is mostly to save some horizontal space and the occasional extra line
> break for this boilerplate and make it a little easier to type.
>

I like it.

It's a very simple change (patch train starts at
> https://review.coreboot.org/c/coreboot/+/31773), but since it affects
> pretty much all code in coreboot and payloads I wanted to send out a quick
> FYI. Please let me know if anyone has any concerns with this.
>

While doing so, I think we should consider if some of these CONFIG_xx
options are ones we should resolve runtime. Taking ACPI S3 feature as
sample, we have acpi_s3_resume_is_allowed() to wrap
IS_ENABLED(CONFIG_HAVE_ACPI_RESUME). So if one wanted to provide eg. CMOS
bit to disable this, there is less source to change.

There is some indirect CONFIG_xxx changes when you switch payload in
config. IMO it should be necessary to simply swap the payload binary in
CBFS without rebuilding coreboot proper, so these should also resolve
runtime, not build-time. (Sure, we would then need to peek early in process
what payload we are going to boot.)

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

[coreboot] Primitive low-level header file changes

[Kyösti Mälkki]

Hi folks!

In order to (better) support other than X86 to have PCI support, headers
with primitive low-level accessors have been re-organised as follows:

For any MMIO access, 
  read8/16/32/64()
  write8/16/32/64()

For any PCI configurations, 
  pci_read_config8/16/32()
  pci_write_config8/16/32()
  pci_or_config8/16/32()
  pci_update_config8/16/32()

For X86 (or other) IO space, 
  inb(),inw(),inl(),insb(),insw(),insl()
  outb(),outw(),outl(),outsb(),outsw(),outsl()

For PNP configuration (pre-ram), 
  pnp_read_config(), pnp_write_config()
  pnp_set_XX(), pnp_read_XX()

My current advice is you don't need to include  or
 explicitly.

Regards,
Kyösti
___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] CBMEM console to be made verbose

[Kyösti Mälkki]

Hi all

A change [1] has been approved that applys a minimum loglevel of BIOS_DEBUG
for CBMEM console. There should be miminal performance impact as it is
nothing but writes to cacheable memory.

For some platform this could cause that pre-ram console buffer runs out of
space. My opinion is that those are too verbose and some logging should be
moved to BIOS_SPEW. If you are debugging raminit you cannot rely on
readable CBMEM console anyways so I suggest against increasing the pre-ram
buffer size.

Regards,
Kyösti

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

[coreboot] Re: AMDFlaws

[Kyösti Mälkki]

On Sun, Feb 17, 2019 at 8:47 AM Mike Banon  wrote:

> Hi,

Almost all the coreboot-supported AMD 16h boards are AMD _early_ 16h
> (so no PSP). Please tell what 16h systems do you have, maybe they
> don't have a PSP at all?
>
>
Well pcengines/apu2 variants are fam16h model30h with PSP.

I have done experiments with it to reduce PSP blob footprint, see the
branch [1] in gerrit. There is some (NDAd) documentation about the firmware
signatures and one can capture PSP firwmare POST codes from LPC. Now since
the build of x86 AGESA blob used never actually sends PSP the message RAM
is ready, I figured that we may never actually load the "PSP Secure OS" but
only the bootloader part.

Also, don't forget pre-PSP silicons still have SMU/PMU.

[1] https://review.coreboot.org/q/topic:"amd-fw-layout;
___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] Re: if your G505S does NOT have a discrete GPU (= LA-A092P board), please test this coreboot build

[Kyösti Mälkki]

On Sat, Feb 16, 2019 at 3:49 PM Mike Banon  wrote:

> I almost completed refining the HJK's dGPU patches and discrete GPU is
> still working at my G505S after these changes, but before submitting
> the patches I would like to make sure that they are not breaking the
> things for G505S without a discrete GPU.


Just go ahead and submit your patches for gerrit review. You can set WIP
flags or I can tag them with -2 until we feel happy about them getting
merged.

I won't be testing any random pre-built binary, need to build one myself.

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

[coreboot] Re: hang in walkcbfs.S on skylake SP

[Kyösti Mälkki]

I am not sure you have access to some kind of XDP or Jtag, but an general
> idea is after romcc complied the code may looks different. You may use
> objdump to double check that, such as compare the disasemble on DUT and
> disasemble from objdump.


Well the first suspect was .S file so it does not go thru C compiler. It
was also skylake platform so it would not be romcc even for bootblock.

Sometimes system watchdogs can fool you to believe a fault between two POST
codes, when it's really hitting some timeout.

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

[coreboot] Re: AMD FHC for G-series SOCs (GX-412TC)

[Kyösti Mälkki]

On Mon, Feb 11, 2019 at 12:34 PM Enrico Weigelt, metux IT consult <
l...@metux.net> wrote:

> Hi folks,
>
>
> I'm currently writing Linux drivers for AMD FCH GPIO. It's currently
> running fine on an APUv2 board (based on some examples I've found in
> the net, including coreboot APUv2 code) but for mainline it should be
> more generic. Yet lacking automatic probing / configuration (don't
> like hardcoding so much)
>
> My problem now is finding out which FCH it is exactly and find the
> corresponding specs. There seem to be two FCH types: Bolton and
> hudson.
>

And Yangtze, Avalon, Kern, ...


> For Bolton, I've found some specs that seem to fit, but other sites
> indicate, the GX-412TC had an Hudson - unfortunately didn't find
> any register specs for this one yet
>

Well coreboot tree has these names somewhat wrong, and mostly just call
them Hudson. In GX-412TC codename was probably Avalon.


> Does anybody here have some more detailed information on that ?
>

Usually, AMD BKDG papers have the info you are after, for pcengines/apu2
variants:
https://www.amd.com/system/files/TechDocs/52740_16h_Models_30h-3Fh_BKDG.pdf


Often it was PCI 0:14.3 (LPC bridge) register 08h (REVISION_ID) you can
identify FCH silicon from.

HTH,
Kyösti
___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] Re: PCI tree topology regression

[Kyösti Mälkki]

On Mon, Jan 21, 2019 at 1:49 PM Michal Zygowski 
wrote:

> Hello coreboot community,
>
> It seems like recent changes to PCI introduced regression. Building
> coreboot for PC Engines apu2 results in unbootable image halting at:
>
> get_pbus: dev is NULL!
>
>
Oh my, sorry about this. I had the incomplete fix in my local tree already,
but have not extended it yet to cover all AGESA/binaryPI. I'll go through
the various places where NULL check is required. The error is harsh, but we
wan't to track down the places where caller is ignoring the cases where PCI
devices are disabled runtime.


> Any ideas what can I do to fix it, or what is the cause? I would
> appreciate Your help.
>

https://review.coreboot.org/c/coreboot/+/31026

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

Re: [coreboot] intel/i82801dx SMM memory size?

[Kyösti Mälkki]

On Wed, Oct 3, 2018 at 7:00 AM ron minnich  wrote:

> I'm wondering ... does anyone know the limits on SMM memory size for this
> part?
>
>
SMM memory size was determined by the MCH part, not ICH.  The boards we had
with i82801dx used ASEG with 128 kiB of SMRAM. The only remaining user of
i82801dx couples with e7505 that could handle 1 MiB of TSEG.


> I'm looking for a mainboard emulation which can support the larger sizes,
> e.g. 8M.
>
>
Out of the box, not supported. But emulation/qemu-q35 can do that if you
add "select SMM_TSEG" and some glue logic to write those TSEG related
registers. You also need a recent QEMU, 2.10 or later.

thanks
>
> ron
> --
> 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] [RFH] Native AMD fam10-15 support

[Kyösti Mälkki]

On Sat, Jul 14, 2018 at 1:46 AM, taii...@gmx.com  wrote:

> Another regression I have noticed is that my 4th SATA hard drive doesn't
> appear in linux for some reason, although it does appear in grub...ideas?
>
> Also kyosti what logs and tests would you like? For now I have
> re-flashed my old 4.6 coreboot but I will flash master again soon for you.
>
>
Output of following after having done S3 resume would be of my interest:
`cbmem -c (or -1)` `cbmem -t` and `dmesg`.

Better have those collected for normal boot path as well.

Also it's worth having low_memory_corruption_check=1 and
low_memory_corruption_check_size=512k as kernel parameters when checking
S3, we have had regressions there for both Intel and AMD, and cases where
initial implementation was just wrong (AGESA).

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

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

[Kyösti Mälkki]

On Fri, Jul 13, 2018 at 6:44 AM, Timothy Pearson <
tpear...@raptorengineering.com> wrote:

> On 07/12/2018 10:41 PM, Kyösti Mälkki wrote:
> > On Fri, Jul 13, 2018 at 5:41 AM, Timothy Pearson
> > mailto:tpear...@raptorengineering.com>>
> > wrote:
> >
> > Good to know, thanks for testing!  I've been looking into
> relocateable
> > ramstage in case suspend was still failing, but if things fell back
> into
> > place, so to speak, in master we should also look at reactivating
> REACTS
> > with the suspend tests enabled.
> >
> >
> > I never suspected RELOCATABLE_RAMSTAGE=n would be a reason for
> > (possible) S3 regressions. The motivation for having
> > RELOCATABLE_RAMSTAGE=y goes beyond the improvement it has on not having
> > to do low-mem backup S3 resume path. I am also wondering how S3 resume
> > path is taking one minute and how that relates to normal boot path time.
> >
> > Kyösti
>
> My understanding is that without relocateable ramstage, there are
> additional bounce buffers involved that not only slow things down, but
> also introduce new code paths that could be responsible for regressions
> in resume.  I think avph on IRC is looking into an initial port of the
> CAR code for relocateable support, and if things are stable enough in
> master to reactivate the REACTS tests on the KGPE-D16 that would help
> him iterate more quickly.
>
>
Right, with RELOCATABLE_RAMSTAGE=n there is a back-and-forth of low-memory
region ramstage occupies on S3 resume path. Also you do not have benefit of
executing a copy of ramstage that was cached in RAM already on normal boot
path, but have to decompress it again from flash.

The low-memory copy is not that big, RAMBASE..RAMTOP is 3 MiB, so this does
not explain one minute.

Indeed RELOCATABLE_RAMSTAGE=n is already in the minority now and
bounce-buffer logic recently had some regressions for loading some payloads.

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

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

[Kyösti Mälkki]

On Fri, Jul 13, 2018 at 5:41 AM, Timothy Pearson <
tpear...@raptorengineering.com> wrote:

> Good to know, thanks for testing!  I've been looking into relocateable
> ramstage in case suspend was still failing, but if things fell back into
> place, so to speak, in master we should also look at reactivating REACTS
> with the suspend tests enabled.
>
>
I never suspected RELOCATABLE_RAMSTAGE=n would be a reason for (possible)
S3 regressions. The motivation for having RELOCATABLE_RAMSTAGE=y goes
beyond the improvement it has on not having to do low-mem backup S3 resume
path. I am also wondering how S3 resume path is taking one minute and how
that relates to normal boot path time.

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

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

[Kyösti Mälkki]

On Fri, Jul 13, 2018 at 5:40 AM, taii...@gmx.com  wrote:

> Hi guys!
>
> I have just tested my KGPE-D16's suspend a few times with the latest
> master and it works fine - takes around a minute to get back to my linux
> terminal.
>

Thanks

And logs please.

My previous mails had some pointers to commits which I believe had
regressions and fixes. I would like to know if those were accurate.

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

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

[Kyösti Mälkki]

On Fri, Jun 15, 2018 at 2:14 PM, qtux  wrote:

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

One of these boards had LPC related lockups. I think the solution was to
disable serial console or to set console to low loglevel.



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

Let's take the parent of that, commit 4a027e6e -- the one you refer to only
appears on gerrit review branch.

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

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

[Kyösti Mälkki]

On Fri, Jun 15, 2018 at 8:58 AM, taii...@gmx.com  wrote:

> On 06/14/2018 08:42 PM, Kyösti Mälkki wrote:
> > On Thu, Jun 14, 2018 at 4:38 AM, qtux  wrote:
> > 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
>
> I just tested S3 again and it worked fine on my v4.6 D16.
>

Please state the commit hash of the source tree you built and booted from,
we don't literally have such tag as "v4.6".

Repeat tests with current master.

Thanks
Kyösti
-- 
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot