[coreboot] Re: Discussing Controversial Upstreaming

[Patrick Georgi via coreboot]

David Hendricks  schrieb am Mi., 29. Jan. 2020,
00:51:

> we'd first need to invent a way to
> send an electric shock thru the keyboard to users who complain to (or
> about) Intel when something goes wrong with the code.
>
That may have been necessary in the era of the fdiv bug but I'm not sure
this trope is still applicable to today:

The concern is that something outside Intel's control reflected badly onto
Intel, but our industry seems fully exempt of consequences (except for
revenue being in the up and up) even when participants are fully
responsible that I don't know how this can be true:

Take Intel, their chips make news every few weeks because another side
channel attack was discovered and besides some (probably uncomfortable)
news cycle the only results seem to be that they still sell chips faster
than they can produce them and that they provide workarounds that reduce
performance by, I think, 25% (and counting) less than what people paid for?
Meanwhile Intel's quarterly reports look fabulous.

And this issue is by no means Intel specific, the entire industry managed
to somehow replace responsibility with a short uncomfortable news cycle
that is forgotten 24 hours later.
No matter if hardware, software (what other paid product requires monthly
maintenance cycles?) or even users (who opt to not even do that maintenance
and instead pretend that any malware they suffer from is a force of nature
instead of pain old neglect), there just are no consequences.

And now we need to prevent users from whining at the wrong folks with
something as drastic as remote shocks? Something doesn't seem to add up.


Patrick

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

[coreboot] Re: No video output?

[Mogens Jensen via coreboot]

Hello Jose,

Thanks, you must have missed my reply to the thread a few days back.

Everything is working perfectly now, I had to disable VGA_BIOS as you also 
suggests.


Regards,
Mogens Jensen

‐‐‐ Original Message ‐‐‐
On Tuesday, January 28, 2020 5:01 PM, Jose Trujillo  
wrote:

> Hello Mogens,
>
> If you want to use LIBGFXINIT please disable VGA_BIOS and for SeaBIOS choose 
> "Legacy VGA text mode" as framebuffer mode in "Display".
>
> Let us know if the problem remains after this.
>
> Jose Trujillo.
>
> ‐‐‐ Original Message ‐‐‐
> On Thursday, January 23, 2020 12:41 PM, Mogens Jensen via coreboot 
> coreboot@coreboot.org wrote:
>
> > I have compiled coreboot from master branch (63fd650e2e) and flashed it to 
> > a CompuLab Intense PC following this guide:
> > https://watchmysys.com/blog/2017/12/coreboot-compulab-intense-pc-mintbox/
> > My problem is that video ouput is missing during POST, only after Linux 
> > kernel starts booting, video output become available. This problem is 
> > described in the guide and the solution is to include Intel VGA BIOS, which 
> > I have done, but still no video ouput before Linux kernel.
> > The guide is two years old, maybe something has changed in coreboot since 
> > then, so more steps are required to get the video working?
> > This is my defconfig:
> > CONFIG_USE_BLOBS=y
> > CONFIG_VENDOR_COMPULAB=y
> > CONFIG_VGA_BIOS=y
> > CONFIG_VGA_BIOS_FILE="3rdparty/blobs/mainboard/$(MAINBOARDDIR)/ipc_vbios.rom"
> > CONFIG_INTEL_GMA_VBT_FILE="3rdparty/blobs/mainboard/$(MAINBOARDDIR)/ipc_vbt.rom"
> > CONFIG_ENABLE_MSATA=y
> > CONFIG_DRIVERS_INTEL_WIFI is not set
> > =
> > CONFIG_IFD_BIN_PATH="3rdparty/blobs/mainboard/$(MAINBOARDDIR)/flashregion_0_flashdescriptor.bin"
> > CONFIG_ME_BIN_PATH="3rdparty/blobs/mainboard/$(MAINBOARDDIR)/flashregion_2_intel_me.bin"
> > CONFIG_GBE_BIN_PATH="3rdparty/blobs/mainboard/$(MAINBOARDDIR)/flashregion_3_gbe.bin"
> > CONFIG_HAVE_IFD_BIN=y
> > CONFIG_HAVE_ME_BIN=y
> > CONFIG_CHECK_ME=y
> > CONFIG_HAVE_GBE_BIN=y
> > CONFIG_MAINBOARD_USE_LIBGFXINIT=y
> > CONFIG_INTEL_GMA_ADD_VBT=y
> > CONFIG_SEABIOS_BOOTORDER_FILE="bootorder.txt"
> > Any ideas on what I could be doing wrong?
> > Regards,
> > Mogens Jensen
> > 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: Discussing Controversial Upstreaming

[David Hendricks]

> Writing new code could considerably reduce its complexity
> and make things much easier. After a few years with FSP, I'm convinced
> that writing clean code would be cheaper than the FSP integration with
> all its avoidable complexity. Intel might not like it, but you could
> reach proper coreboot support much faster without FSP.

Assuming that's true from an engineering perspective and we're clear
to publish all code/info needed, we'd first need to invent a way to
send an electric shock thru the keyboard to users who complain to (or
about) Intel when something goes wrong with the code.
___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] Re: Discussing Controversial Upstreaming

[Nico Huber]

Hi Marshall,

On 28.01.20 02:12, Marshall Dawson wrote:
>> That's why I always encourage people to ask for documentation instead
>> of code. Opening code that was developed in private is a pain for both
>> sides. However, I guess it could be taken as a good omen; that a silicon
>> vendor won't forbid open implementations.
>>
>
> For our FSP implementation, I intend to rely on the FSP 2.0 EAS published
> by Intel then document the important differences, which I hope is extremely
> minimal.  Then there will also be a Picasso-specific Integration Guide,
> again similar to Intel's docs.  This leaves us subject to many of the
> complaints in CB:36328, however I'm trying to do my best to avoid as much
> of that as possible -- I forwarded your RFC to my team, asked them to read
> it carefully to understand FSP customers' concerns, and told them I fully
> expect us to outshine Intel.

sounds great. But before you can outrun them you have to catch up. And
I fear you might try to take shortcuts. I don't want to tell you how to
do your job, but here is what I'd try to do (I guess an extreme): Do
whatever needs to be done for the priority customers when writing code,
but only start writing code for upstream coreboot when there is also
public documentation about the chips. If you start earlier, you exclude
too many people from collaboration. Just in case you don't know, there
is not even a public datasheet to be found that would acknowledge that
Ryzen, Picasso etc. are SoCs with FCH like components.

> By the way, picasso now faces some of the
> same challenges with AGESA that stoneyridge did.  The traditional AMD
> mindset is/was to keep as much as possible in AGESA and there's inertia to
> keep that in place.  For stoneyridge, we wanted as much as possible in
> coreboot instead, and moving some of it to coreboot was an absolute
> requirement.  Gaining permission to port closed AGESA code to open source
> was not very difficult in those cases.

Thanks. Makes me hope again :)

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

[coreboot] Re: Discussing Controversial Upstreaming

[Nico Huber]

Hi Jonathan,

On 27.01.20 23:01, Jonathan Zhang (Infra) wrote:
> On 1/27/20, 10:56 AM, "Nico Huber"  wrote:
>> We had this before: Something that nobody really cared about was
>> upstreamed. And then later, it was copied for newer platforms and
>> people were confused by the feedback that they didn't get for the
>> original platform's code (they expected that what was acceptable for
>> the platform that nobody cared about would always be accepted). I'm
>> not saying that this is the wrong way. Just that from my point of
>> view, we had bad experience with it.
> Most industry projects fail in the end. I hope this one does not. Let's work
> together to  make it happens.

I think we are caught in a loop. How can we work together if only you
have the blob?

> The difficulty is not just at technology side, it is
> more on the process side and business side. There is a chicken and egg 
> problems
> between coreboot support for Xeon-SP and FSP support for Xeon-SP. I hope the
> community is sensitive to the engineers working in silicon vendor. Let's 
> encourage
> them and support them, it is not easy to turn around a big ship.

So, the first code would just be in the coreboot repository to raise a
flag there? So people (at Intel) can see it, not use it?

>> This seems critical to me. With little documentation (if any at all)
>> about the silicon initialization, no documentation about the blob (I
>> assume?) and no binaries to at least test it, what do you expect from
>> the review?
> Without coreboot able to support Xeon-SP, silicon vendor is rightly hesitate 
> to
> make Xeon-SP FSP as a product. Instead of wishing others to do something, 
> let's
> firm up coreboot support, and we have allies helping us.

Here I see another company that wants Intel to write firmware. I'm not
convinced that is a good idea. Have you evaluated alternatives? If one
looks close at Intel's reference code, it's clear that it's mostly
boilerplate. Writing new code could considerably reduce its complexity
and make things much easier. After a few years with FSP, I'm convinced
that writing clean code would be cheaper than the FSP integration with
all its avoidable complexity. Intel might not like it, but you could
reach proper coreboot support much faster without FSP.

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

[coreboot] Significant slowdown for asus/p2b-* boards after moving to C environment bootblock

[Keith Hui]

Earlier this month Paul reached out to me in private and asked me
about a few of my board status uploads. We collectively noticed the
romstage now takes significantly longer to the tune of 1.5 seconds. We
were not quite sure where the problem was because I also tried
reverting to romcc bootblock and I didn't see much improvement.

Now that I have timestamps in i440bx ram init, I ran the tests again,
and here are the results. (This time my board status is not uploading
correctly...)

With serial console:
   0:1st timestamp 741
  11:start of bootblock4,763 (4,021)
  12:end of bootblock  4,980 (216)
  13:starting to load romstage 6,127 (1,146)
  14:finished loading romstage 6,269 (142)
   1:start of romstage 6,724 (454)
   2:before ram initialization 500,006 (493,282)
   3:after ram initialization  670,733 (170,726)
   4:end of romstage   2,189,924 (1,519,190)
 100:start of postcar  2,311,060 (121,136)
 101:end of postcar2,311,061 (0)
   8:starting to load ramstage 2,318,690 (7,629)
  15:starting LZMA decompress (ignore for x86) 2,322,877 (4,187)
  16:finished LZMA decompress (ignore for x86) 2,361,147 (38,269)
   9:finished loading ramstage 2,369,966 (8,818)
  10:start of ramstage 2,381,486 (11,519)
  30:device enumeration2,381,490 (4)
  40:device configuration  2,447,811 (66,321)
  50:device enable 2,649,524 (201,713)
  60:device initialization 2,672,956 (23,431)
  65:Option ROM initialization 2,819,134 (146,178)
  66:Option ROM copy done  2,895,605 (76,471)
  67:Option ROM run done   3,249,285 (353,679)
  70:device setup done 3,283,763 (34,478)
  75:cbmem post3,287,313 (3,550)
  80:write tables  3,287,315 (1)
  85:finalize chips3,427,717 (140,401)
  90:load payload  3,431,452 (3,735)
  15:starting LZMA decompress (ignore for x86) 3,460,849 (29,396)
  16:finished LZMA decompress (ignore for x86) 3,517,611 (56,762)
  99:selfboot jump 3,528,778 (11,167)

Total Time: 3,528,022

Without serial console:
   0:1st timestamp 742
  11:start of bootblock4,763 (4,021)
  12:end of bootblock  4,980 (216)
  13:starting to load romstage 6,127 (1,146)
  14:finished loading romstage 6,269 (142)
   1:start of romstage 6,742 (472)
   2:before ram initialization 315,196 (308,454)
   3:after ram initialization  486,614 (171,417)
   4:end of romstage   1,650,976 (1,164,362)
 100:start of postcar  1,722,827 (71,851)
 101:end of postcar1,722,828 (0)
   8:starting to load ramstage 1,722,929 (101)
  15:starting LZMA decompress (ignore for x86) 1,722,952 (22)
  16:finished LZMA decompress (ignore for x86) 1,761,057 (38,105)
   9:finished loading ramstage 1,761,177 (119)
  10:start of ramstage 1,762,626 (1,449)
  30:device enumeration1,762,631 (4)
  40:device configuration  1,762,816 (185)
  50:device enable 1,763,445 (628)
  60:device initialization 1,763,542 (97)
  65:Option ROM initialization 1,764,321 (778)
  66:Option ROM copy done  1,826,366 (62,045)
  67:Option ROM run done   2,175,483 (349,116)
  70:device setup done 2,175,535 (52)
  75:cbmem post2,175,537 (1)
  80:write tables  2,175,539 (2)
  85:finalize chips2,179,763 (4,223)
  90:load payload  2,179,768 (5)
  15:starting LZMA decompress (ignore for x86) 2,179,995 (226)
  16:finished LZMA decompress (ignore for x86) 2,236,000 (56,005)
  99:selfboot jump 2,236,034 (33)

Total Time: 

[coreboot] Re: Discussing Controversial Upstreaming

[Patrick Georgi via coreboot]

On Mon, Jan 27, 2020 at 04:24:00PM -0600, Matt DeVillier wrote:
> having a src/mainboard/stub/ for **all** SoC might not be a bad idea,
> especially if it were to select less common/non-default options that other
> in-tree boards don't select by default, to ensure full coverage of all SoC
> options.
I think for non-default options, having more specimen of real world examples
in configs/ is better simply because that means that we're optimizing for
real-world configurations.


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


signature.asc
Description: PGP signature
___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] Workflows and Guidelines

[Patrick Georgi via coreboot]

Hi everybody,

one thing that became clear to me in the recent (and not-so-recent)
discussions broadly related to coding style, code duplication, code
submission strategies, documentation requirements and similar things
is that there have to be many different styles of approaching coreboot
development out there.

As David said:
> Which development model works for a particular project (or sub-project
> within coreboot) depends on a lot of variables and I don't think we
> can expect many people to stick around if we make unfeasible demands
> of their workflow.

We can only avoid making unfeasible demands on other people's workflows
if we know these workflows. Developers might also benefit from guidelines
telling them how to approach certain projects.

On the other end, there's not really a standard on how we review things:
For example some people (I belong to that crowd) tend to accept stuff
that is part of active development (and for example have a long set of
commits on top), even if there are minor issues left (that look like
they create tons of patch handling work if fixed in the base commit of
the patch train), on the understanding that people follow up on comments
with later commits. Others seem, at times, to be rather close to give such
a change a -2 review until it's perfect and all comments are addressed
in that very commit.

Which approach is right? I don't know. (And therein lies the problem)

There are other points of disagreement in review style, and having
unspoken assumptions be in force with some reviewer but not with others is
a doubly confusing experience: we shouldn't expect things without stating
them (but for the reviewer they probably appear to be natural) and the
varying style means that every review can be a whole new experience full
of surprises.

So here's something I'd really love to do, but lack the time for:

 - Interview developers in all kinds of contexts (hobbyists, corporate,
   and so on) about how they work and what their constraints are
 - Interview reviewers on what they consider important, how they work
   and what they look for
 - Document all that, coalescing common pieces
 - Draft guidelines that bring the workflows (or variations thereof
   that the developers agree can be implemented on their part) in line
   with the review requirements and vice-versa.
 - Iterate on the guidelines until there's rough consensus

The idea isn't to create some legal text to wield as a weapon during
review ("§3 says that I can do it this way!" "but §7.a.5 says that you
mustn't in this particular case!"), but to establish a baseline for common
understanding when working on the code we all care for in this project.

Such an effort probably takes half a year or longer (not full time,
but catching up with folks, and rewriting draft after draft accumulates)
and that's sadly nothing I can offer right now or in the near future.

But, if there's somebody in the community wondering how they could
participate, thinking that this is a useful endeavour and that it's just
their cup of tea, that project is for the taking.

(Or maybe this is just a stupid idea of mine)

Beware though: the "Iterate" step looks short and simple in this text
but it won't be since you'll have to reconcile all the forces pulling
at the text.


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


signature.asc
Description: PGP signature
___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] Re: Do we have a rule that code should be build tested?

[Patrick Georgi via coreboot]

Am Di., 28. Jan. 2020 um 08:03 Uhr schrieb David Hendricks <
david.hendri...@gmail.com>:

> Please correct me if I'm way off base with that example. The stubs
> Patrick proposed in the other thread might help address the issue,
> however it can also mean adding code which exists only to satisfy the
> build requirement, churns as the real code changes, and may need to be
> removed later on anyway.
>

Right, but it means that there's less of a risk of API changes across the
tree (that happen all the time) throwing bring-up projects off-track.
I mean, these stubs don't have to _do_ anything useful, they merely have to
present themselves as just good enough to the build system to put all
source code through the grinder^Wcompiler.

I'd expect all developers to have _some_ kind of board set up for their SoC
because otherwise how do they test the SoC code in the first place? (I
assume it is tested, at least to some degree)
Maybe it's good enough to push these early, potentially anonymized plus
some signifier that they're stubs? Not sure if that's practical in all
existing workflows, but I'll leave that to a separate thread.

I suppose we could look into having jenkins throw out a warning if a source
file (*.c or *.h) wasn't touched during the build. That might be a good
exercise in any case to see what the situation looks like right now.


Regards,
Patrick
-- 
Google Germany GmbH, ABC-Str. 19, 20354 Hamburg
Registergericht und -nummer: Hamburg, HRB 86891, Sitz der Gesellschaft:
Hamburg
Geschäftsführer: Paul Manicle, Halimah DeLaine Prado
___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] Re: No video output?

[Jose Trujillo via coreboot]

Hello Mogens,

If you want to use LIBGFXINIT please disable VGA_BIOS and for SeaBIOS choose 
"Legacy VGA text mode" as framebuffer mode in "Display".

Let us know if the problem remains after this.

Jose Trujillo.


‐‐‐ Original Message ‐‐‐
On Thursday, January 23, 2020 12:41 PM, Mogens Jensen via coreboot 
 wrote:

> I have compiled coreboot from master branch (63fd650e2e) and flashed it to a 
> CompuLab Intense PC following this guide:
>
> https://watchmysys.com/blog/2017/12/coreboot-compulab-intense-pc-mintbox/
>
> My problem is that video ouput is missing during POST, only after Linux 
> kernel starts booting, video output become available. This problem is 
> described in the guide and the solution is to include Intel VGA BIOS, which I 
> have done, but still no video ouput before Linux kernel.
>
> The guide is two years old, maybe something has changed in coreboot since 
> then, so more steps are required to get the video working?
>
> This is my defconfig:
>
> CONFIG_USE_BLOBS=y
> CONFIG_VENDOR_COMPULAB=y
> CONFIG_VGA_BIOS=y
> CONFIG_VGA_BIOS_FILE="3rdparty/blobs/mainboard/$(MAINBOARDDIR)/ipc_vbios.rom"
> CONFIG_INTEL_GMA_VBT_FILE="3rdparty/blobs/mainboard/$(MAINBOARDDIR)/ipc_vbt.rom"
> CONFIG_ENABLE_MSATA=y
>
> CONFIG_DRIVERS_INTEL_WIFI is not set
>
> =
>
> CONFIG_IFD_BIN_PATH="3rdparty/blobs/mainboard/$(MAINBOARDDIR)/flashregion_0_flashdescriptor.bin"
> CONFIG_ME_BIN_PATH="3rdparty/blobs/mainboard/$(MAINBOARDDIR)/flashregion_2_intel_me.bin"
> CONFIG_GBE_BIN_PATH="3rdparty/blobs/mainboard/$(MAINBOARDDIR)/flashregion_3_gbe.bin"
> CONFIG_HAVE_IFD_BIN=y
> CONFIG_HAVE_ME_BIN=y
> CONFIG_CHECK_ME=y
> CONFIG_HAVE_GBE_BIN=y
> CONFIG_MAINBOARD_USE_LIBGFXINIT=y
> CONFIG_INTEL_GMA_ADD_VBT=y
> CONFIG_SEABIOS_BOOTORDER_FILE="bootorder.txt"
>
> Any ideas on what I could be doing wrong?
>
> Regards,
> Mogens Jensen
>
> 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: [RFT] Linux fails to detect devices on AGESA board with `nosmp`

[Michal Zygowski]

Hi,

As Kyösti pointed, MP tables and IRQ is broken on AGESA boards. Most of
the mainboards have mindlessly copy-pasted code that generates MP tables
and IRQ tables. Those often contain entries of non-existing devices as a
result. Since the most preferred way of IRQ routing is ACPI and most
systems use it, the "noacpi" path wasn't thoroughly validated.

I will start working on it soon (most likely together with Kyösti), so
the situation should improve a little bit.

Regards,
Michał

On 28.01.2020 11:33, Sergej Ivanov wrote:
> Hello,
>
> adding nosmp pci=noacpi results in same behaviour - linux can't assign
> irq to usb controllers(but I don't see IRQ >15 anymore). Adding
> nosmp pci=biosirq,noacpi allow system to boot.
>
> сб, 25 янв. 2020 г. в 03:14, Kyösti Mälkki  >:
>
> On Thu, Jan 16, 2020 at 5:21 PM awokd via coreboot
> mailto:coreboot@coreboot.org>> 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 mailing list -- coreboot@coreboot.org
> To unsubscribe send an email to coreboot-le...@coreboot.org

-- 
Michał Żygowski
Firmware Engineer
http://3mdeb.com | @3mdeb_com

___
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`

[Sergej Ivanov]

Hello,

adding nosmp pci=noacpi results in same behaviour - linux can't assign irq
to usb controllers(but I don't see IRQ >15 anymore). Adding nosmp
pci=biosirq,noacpi allow system to boot.

сб, 25 янв. 2020 г. в 03:14, 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 mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org