[coreboot] Re: How to maintain AGESA-based ports long-term?
>
> From my point of view, I'd be very grateful if we could get this
> community strongly engaged in getting upstream coreboot builds working
> on, e.g., chromebooks.
>
I fully understand that companies like Google which rely on shipping
coreboot would like it to be as easy as possible to port new platforms. At
the same time, this is a large number of AGESA platforms which have active
and vocal users. They no doubt would like to stay with the mainline to
continue to see fixes and enhancements like
https://github.com/osresearch/heads/issues/453.
I'm interested in what would get everyone to a better state where things go
more smoothly. There is work underway to overcome the requirements this
time. Now is the best time to think about what can be done to ease the
maintenance burden before the next requirement creates another crisis.
For example, untangling the AGESA code from the mainboard code to make it
more FSP-like. Examining the stages of what it does and better documenting
it so that e.g. the unknown resources that have been holding up the
allocator switchover are easier to find. Isolating the AGESA code into
stages to make it more modular and improve the most troublesome parts. To
work towards a more "native" port, what makes the most sense to tackle
first? I'm no expert in either AGEA or the minute of coreboot's structure
but those are some things that come to mind.
As an interested user I'm fully willing and committed to contribute funding
towards such work. Everyone involved in the project has the same goal in
the end.
-Matt
On Sat, Dec 4, 2021 at 11:58 PM ron minnich wrote:
> based on what I'm seeing so far, 100 hours just means "compiles",
> which is only a fraction of the possible effort to get it to "works".
> You then have 50 boards to get working.
>
> and even then, at real world rates, 100 hours -> 25,000.
>
> There's only so much we can do. I at least would be way happier to see
> effort going into new boards.
>
> On Sat, Dec 4, 2021 at 8:48 PM Keith Emery
> wrote:
> >
> >
> > I only said 100 hours because that was the figure that somebody stated
> > to shift all the listed boards onto the new Resource Allocator. We need
> > that to happen if these boards are to see maintenance in the future, so
> > I figured it made sense to just start with that.
> >
> >
> > On 5/12/21 5:53 am, ron minnich wrote:
> > > 100 hours of work for 50 boards? 2 hours per board? Each one fully
> > > tested and working as before? 'm pretty surprised.
> > >
> > > On Sat, Dec 4, 2021 at 4:38 AM Keith Emery <
> k.emery@internode.on.net> wrote:
> > >> Getting the listed AGESA boards operating on the new scheduler is
> > >> estimated to take around 100 hours of work. So do we have some idea of
> > >> what might be considered an acceptable hourly rate? Also do we have a
> > >> clear estimate of how many people have one of the effected boards?
> That
> > >> at least gives us a funding goal to work with.
> > >>
> > >> Alternatively is there some other way to determine a price to at least
> > >> get my specific board working with the new infrastructure?
> > >>
> > >>
> > >> On 4/12/21 12:37 pm, ron minnich wrote:
> > >>> I think the reason the question comes up time and time again is
> > >>> because the effort is non trivial. Were it reasonably easy, it would
> > >>> have been done by now. It's easy to get it to compile, but getting it
> > >>> to work solidly is not at all easy.
> > >>>
> > >>> It's very hard to let old systems go. But there's always a tradeoff.
> > >>>
> > >>> From my point of view, I'd be very grateful if we could get this
> > >>> community strongly engaged in getting upstream coreboot builds
> working
> > >>> on, e.g., chromebooks.
> > >>>
> > >>> I.e., upstream coreboot working on systems that are designed for, and
> > >>> ship with, coreboot. Even things that look easy are not always easy.
> > >>>
> > >>> ron
> > >>>
> > >>> On Fri, Dec 3, 2021 at 1:07 PM Matt B
> wrote:
> > > It's just software, so it could certainly be done. How much work
> would
> > > be involved is the right question. Alas, I have no idea. One needs
> to
> > > study the AGESA sources to tell, I guess.
> > This question has come up time and time again:
> > What would actually be involved in {"cleaning up","doing a 'real'
> port","whatever else makes sense'} to make these platforms based on AGESA
> as maintainable as corresponding intel platforms?
> >
> > I'll happily buy a round of beer (or equivalent) for anyone who can
> provide a clear picture of what the road forward looks like. Then we can at
> least talk in grounded terms.
> >
> > -Matt
> >
> > On Wed, Dec 1, 2021 at 12:51 PM ron minnich
> wrote:
> > > We've always deprecated platforms. And they're still in tree --
> you
> > > can build for DEC Alpha if you want. There's no shame in not being
> in
> > > the latest release.
> > >
> > > Given unlimited time and money and people, we could fix al
[coreboot] spkmodem output
I had a bit of a brainwave regarding what might be happening with this spkmodem output. I was hoping to collect peoples thoughts in regards to weather I might be at least possibly on the right track. When I enable spkmodem in the coreboot config, I get output from the PC speaker. But spkmodem-recv interprets the tones as consistent gibberish. The output is consistent with a mismatch in the baud rates, but there appears no apparent way to select anything different in the spkmodem-recv software. If the CPU is running coreboot as fast as possible while receiving those instructions from a relatively slow SPI bus. Is it possible that I've somehow overclocked the SPI bus, leading to a mismatch in the baud rates? ___ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
[coreboot] Re: How to maintain AGESA-based ports long-term?
based on what I'm seeing so far, 100 hours just means "compiles",
which is only a fraction of the possible effort to get it to "works".
You then have 50 boards to get working.
and even then, at real world rates, 100 hours -> 25,000.
There's only so much we can do. I at least would be way happier to see
effort going into new boards.
On Sat, Dec 4, 2021 at 8:48 PM Keith Emery wrote:
>
>
> I only said 100 hours because that was the figure that somebody stated
> to shift all the listed boards onto the new Resource Allocator. We need
> that to happen if these boards are to see maintenance in the future, so
> I figured it made sense to just start with that.
>
>
> On 5/12/21 5:53 am, ron minnich wrote:
> > 100 hours of work for 50 boards? 2 hours per board? Each one fully
> > tested and working as before? 'm pretty surprised.
> >
> > On Sat, Dec 4, 2021 at 4:38 AM Keith Emery
> > wrote:
> >> Getting the listed AGESA boards operating on the new scheduler is
> >> estimated to take around 100 hours of work. So do we have some idea of
> >> what might be considered an acceptable hourly rate? Also do we have a
> >> clear estimate of how many people have one of the effected boards? That
> >> at least gives us a funding goal to work with.
> >>
> >> Alternatively is there some other way to determine a price to at least
> >> get my specific board working with the new infrastructure?
> >>
> >>
> >> On 4/12/21 12:37 pm, ron minnich wrote:
> >>> I think the reason the question comes up time and time again is
> >>> because the effort is non trivial. Were it reasonably easy, it would
> >>> have been done by now. It's easy to get it to compile, but getting it
> >>> to work solidly is not at all easy.
> >>>
> >>> It's very hard to let old systems go. But there's always a tradeoff.
> >>>
> >>> From my point of view, I'd be very grateful if we could get this
> >>> community strongly engaged in getting upstream coreboot builds working
> >>> on, e.g., chromebooks.
> >>>
> >>> I.e., upstream coreboot working on systems that are designed for, and
> >>> ship with, coreboot. Even things that look easy are not always easy.
> >>>
> >>> ron
> >>>
> >>> On Fri, Dec 3, 2021 at 1:07 PM Matt B wrote:
> > It's just software, so it could certainly be done. How much work would
> > be involved is the right question. Alas, I have no idea. One needs to
> > study the AGESA sources to tell, I guess.
> This question has come up time and time again:
> What would actually be involved in {"cleaning up","doing a 'real'
> port","whatever else makes sense'} to make these platforms based on
> AGESA as maintainable as corresponding intel platforms?
>
> I'll happily buy a round of beer (or equivalent) for anyone who can
> provide a clear picture of what the road forward looks like. Then we can
> at least talk in grounded terms.
>
> -Matt
>
> On Wed, Dec 1, 2021 at 12:51 PM ron minnich wrote:
> > We've always deprecated platforms. And they're still in tree -- you
> > can build for DEC Alpha if you want. There's no shame in not being in
> > the latest release.
> >
> > Given unlimited time and money and people, we could fix all the
> > problems. We live in a world of limits, and must do what we can with
> > the resources we have.
> >
> > Nobody is stopping anyone from cleaning up the AGESA code. But it's
> > been about 10 years since it came in, and such cleanup has yet to
> > happen.
> >
> > We should move forward with the resource allocator, and if a board
> > can't work with v4, and nobody is willing to do the work, that board
> > should be left out of new releases. Having v3 and v4 both in-tree is
> > not a viable long term strategy.
> >
> > On Wed, Dec 1, 2021 at 8:43 AM Nico Huber wrote:
> >> On 01.12.21 15:57, Ivan Ivanov wrote:
> >>> Thank you, these seem to be good points. However, in regards to:
> >>>
> If you have any hope of open-source coreboot for newer platforms,
> you shouldn't make it harder for coreboot to advance.
> >>> Where to advance? Are there any "newer platforms" that are as worthy
> >>> as the "older platforms":
> >> Not sure how to compare that, nobody has written native coreboot code
> >> for the platforms that you deem worthy either. Also, ...
> >>
> >>> 1) as secure: no Intel ME / AMD PSP "security" co-processors, which
> >>> are seen as harmful to real security by many ;
> >> ...open-source AGESA seems worse to me. In theory one could review it,
> >> but did anyone? AIUI, it even provides runtime code for the OS (ACPI
> >> DSDT), i.e. tells the OS what to do.
> >>
> >> So what you call "real security" seems more like wishful security to
> >> me. Presence of ME or PSP does not provide a security issue per se. It
> >> depends on your threat model and if they are your weakest spot. There
> >
[coreboot] Re: How to maintain AGESA-based ports long-term?
I only said 100 hours because that was the figure that somebody stated
to shift all the listed boards onto the new Resource Allocator. We need
that to happen if these boards are to see maintenance in the future, so
I figured it made sense to just start with that.
On 5/12/21 5:53 am, ron minnich wrote:
100 hours of work for 50 boards? 2 hours per board? Each one fully
tested and working as before? 'm pretty surprised.
On Sat, Dec 4, 2021 at 4:38 AM Keith Emery wrote:
Getting the listed AGESA boards operating on the new scheduler is
estimated to take around 100 hours of work. So do we have some idea of
what might be considered an acceptable hourly rate? Also do we have a
clear estimate of how many people have one of the effected boards? That
at least gives us a funding goal to work with.
Alternatively is there some other way to determine a price to at least
get my specific board working with the new infrastructure?
On 4/12/21 12:37 pm, ron minnich wrote:
I think the reason the question comes up time and time again is
because the effort is non trivial. Were it reasonably easy, it would
have been done by now. It's easy to get it to compile, but getting it
to work solidly is not at all easy.
It's very hard to let old systems go. But there's always a tradeoff.
From my point of view, I'd be very grateful if we could get this
community strongly engaged in getting upstream coreboot builds working
on, e.g., chromebooks.
I.e., upstream coreboot working on systems that are designed for, and
ship with, coreboot. Even things that look easy are not always easy.
ron
On Fri, Dec 3, 2021 at 1:07 PM Matt B wrote:
It's just software, so it could certainly be done. How much work would
be involved is the right question. Alas, I have no idea. One needs to
study the AGESA sources to tell, I guess.
This question has come up time and time again:
What would actually be involved in {"cleaning up","doing a 'real'
port","whatever else makes sense'} to make these platforms based on AGESA as maintainable as
corresponding intel platforms?
I'll happily buy a round of beer (or equivalent) for anyone who can provide a
clear picture of what the road forward looks like. Then we can at least talk in
grounded terms.
-Matt
On Wed, Dec 1, 2021 at 12:51 PM ron minnich wrote:
We've always deprecated platforms. And they're still in tree -- you
can build for DEC Alpha if you want. There's no shame in not being in
the latest release.
Given unlimited time and money and people, we could fix all the
problems. We live in a world of limits, and must do what we can with
the resources we have.
Nobody is stopping anyone from cleaning up the AGESA code. But it's
been about 10 years since it came in, and such cleanup has yet to
happen.
We should move forward with the resource allocator, and if a board
can't work with v4, and nobody is willing to do the work, that board
should be left out of new releases. Having v3 and v4 both in-tree is
not a viable long term strategy.
On Wed, Dec 1, 2021 at 8:43 AM Nico Huber wrote:
On 01.12.21 15:57, Ivan Ivanov wrote:
Thank you, these seem to be good points. However, in regards to:
If you have any hope of open-source coreboot for newer platforms, you shouldn't
make it harder for coreboot to advance.
Where to advance? Are there any "newer platforms" that are as worthy
as the "older platforms":
Not sure how to compare that, nobody has written native coreboot code
for the platforms that you deem worthy either. Also, ...
1) as secure: no Intel ME / AMD PSP "security" co-processors, which
are seen as harmful to real security by many ;
...open-source AGESA seems worse to me. In theory one could review it,
but did anyone? AIUI, it even provides runtime code for the OS (ACPI
DSDT), i.e. tells the OS what to do.
So what you call "real security" seems more like wishful security to
me. Presence of ME or PSP does not provide a security issue per se. It
depends on your threat model and if they are your weakest spot. There
are plenty of controllers even in older machines that run code from ROM
masks. What's the difference? Can we trust vendors with code in ROM
masks but not with code in flash? These are subtle considerations. So
far, it doesn't make older hardware more attractive to me.
Did I mention that at least one of the pre-PSP platforms already has
a PSP, just hidden? Ok, I admit I didn't look at the silicon to check,
but it's common that a silicon vendor puts new stuff early into chips
to test it. So it seems very likely to be true. We generally don't
know what exactly lives in these chips. I rather trust what I can see.
2) as affordable: the older devices are possible to get used for like
$100-$200. Meanwhile - because of Boot Guard etc. - the "newer
platforms" are unlikely to have coreboot without vendor's involvement,
who will gladly charge a big extra for "coreboot support".
Last time I checked BootGuard wasn't a big issue, i.e. not so many
devices ship with it. Did that c
[coreboot] Add memory support for mb/apple: MacBook Air 5,2 (A1466)
‐‐‐ Original Message ‐‐‐ On Saturday, December 4th, 2021 at 10:30 AM, Mariusz Grabarczyk wrote: > Hi > > I would like to have memory support added for mb/apple: MacBook Air 5,2 > (A1466) > Per > https://review.coreboot.org/c/coreboot/+/32604/36/Documentation/mainboard/apple/macbookair5_2.md#51 > > Originally > https://review.coreboot.org/c/coreboot/+/32604 > > If your RAM configuration is not supported, you can help supporting it. Run > `sudo inteltool -m`, save output to a text file and send a message to coreboot > > inteltool -g | get_macbook_ramcfg -m mba52 > unsupported memory configuration 1 > > inteltool -m >> macbook52_memory > > Attached is dump fileCPU: ID 0x306a9, Processor Type 0x0, Family 0x6, Model 0x3a, Stepping 0x9 Northbridge: 8086:0154 (3rd generation (Ivy Bridge family) Core Processor (Mobile)) Southbridge: 8086:1e56 (QS77) IGD: 8086:0166 (Intel(R) HD 4000 Graphics) = GPIOS = GPIOBASE = 0x0500 (IO) gpiobase+0x: 0xbdebfdff (GPIO_USE_SEL) gpiobase+0x0004: 0xae166eff (GP_IO_SEL) gpiobase+0x0008: 0x (RESERVED) gpiobase+0x000c: 0xde8e8fa6 (GP_LVL) gpiobase+0x0010: 0x (RESERVED) gpiobase+0x0014: 0x (RESERVED) gpiobase+0x0018: 0x (GPO_BLINK) gpiobase+0x001c: 0x (GP_SER_BLINK) gpiobase+0x0020: 0x0008 (GP_SB_CMDSTS) gpiobase+0x0024: 0x (GP_SB_DATA) gpiobase+0x0028: 0x (GPI_NMI_EN) gpiobase+0x002a: 0x (GPI_NMI_STS) gpiobase+0x002c: 0x00b6 (GPI_INV) gpiobase+0x0030: 0x13ff80fe (GPIO_USE_SEL2) gpiobase+0x0034: 0x1f04ffe2 (GP_IO_SEL2) gpiobase+0x0038: 0xffadbfc6 (GP_LVL2) gpiobase+0x003c: 0x (RESERVED) gpiobase+0x0040: 0x04ff (GPIO_USE_SEL3) gpiobase+0x0044: 0x0bf0 (GP_IO_SEL3) gpiobase+0x0048: 0x0f80 (GPIO_LVL3) gpiobase+0x004c: 0x (RESERVED) gpiobase+0x0050: 0x (RESERVED) gpiobase+0x0054: 0x (RESERVED) gpiobase+0x0058: 0x (RESERVED) gpiobase+0x005c: 0x (RESERVED) gpiobase+0x0060: 0x8800 (GP_RST_SEL1) gpiobase+0x0064: 0x (GP_RST_SEL2) gpiobase+0x0068: 0x (GP_RST_SEL3) gpiobase+0x006c: 0x (RESERVED) gpiobase+0x0070: 0x (RESERVED) gpiobase+0x0074: 0x (RESERVED) gpiobase+0x0078: 0x (RESERVED) gpiobase+0x007c: 0x (RESERVED) CPU: ID 0x306a9, Processor Type 0x0, Family 0x6, Model 0x3a, Stepping 0x9 Northbridge: 8086:0154 (3rd generation (Ivy Bridge family) Core Processor (Mobile)) Southbridge: 8086:1e56 (QS77) IGD: 8086:0166 (Intel(R) HD 4000 Graphics) = GPIOS = GPIOBASE = 0x0500 (IO) gpiobase+0x: 0xbdebfdff (GPIO_USE_SEL) gpiobase+0x: 0xb96ba1ff (GPIO_USE_SEL) DEFAULT gpiobase+0x: 0x04805c00 (GPIO_USE_SEL) DIFF gpiobase+0x0004: 0xae166eff (GP_IO_SEL) gpiobase+0x0004: 0xeeff6eff (GP_IO_SEL) DEFAULT gpiobase+0x0004: 0x40e9 (GP_IO_SEL) DIFF gpiobase+0x0008: 0x (RESERVED) gpiobase+0x000c: 0xde8e8fa6 (GP_LVL) gpiobase+0x000c: 0x02fe0100 (GP_LVL) DEFAULT gpiobase+0x000c: 0xdc708ea6 (GP_LVL) DIFF gpiobase+0x0010: 0x (RESERVED) gpiobase+0x0014: 0x (RESERVED) gpiobase+0x0018: 0x (GPO_BLINK) gpiobase+0x0018: 0x0004 (GPO_BLINK) DEFAULT gpiobase+0x0018: 0x0004 (GPO_BLINK) DIFF gpiobase+0x001c: 0x (GP_SER_BLINK) gpiobase+0x0020: 0x0008 (GP_SB_CMDSTS) gpiobase+0x0024: 0x (GP_SB_DATA) gpiobase+0x0028: 0x (GPI_NMI_EN) gpiobase+0x002a: 0x (GPI_NMI_STS) gpiobase+0x002c: 0x00b6 (GPI_INV) gpiobase+0x002c: 0x (GPI_INV) DEFAULT gpiobase+0x002c: 0x00b6 (GPI_INV) DIFF gpiobase+0x0030: 0x13ff80fe (GPIO_USE_SEL2) gpiobase+0x0030: 0x020300fe (GPIO_USE_SEL2) DEFAULT gpiobase+0x0030: 0x11fc8000 (GPIO_USE_SEL2) DIFF gpiobase+0x0034: 0x1f04ffe2 (GP_IO_SEL2) gpiobase+0x0034: 0x1f57fff4 (GP_IO_SEL2) DEFAULT gpiobase+0x0034: 0x00530016 (GP_IO_SEL2) DIFF gpiobase+0x0038: 0xffadbfc6 (GP_LVL2) gpiobase+0x0038: 0xa4aa0007 (GP_LVL2) DEFAULT gpiobase+0x0038: 0x1b07bfc1 (GP_LVL2) DIFF gpiobase+0x003c: 0x (RESERVED) gpiobase+0x0040: 0x04ff (GPIO_USE_SEL3) gpiobase+0x0040: 0x0030 (GPIO_USE_SEL3) DEFAULT gpiobase+0x0040: 0x04cf (GPIO_USE_SEL3) DIFF gpiobase+0x0044: 0x0bf0 (GP_IO_SEL3) gpiobase+0x0044: 0x0ff0 (GP_IO_SEL3) DEFAULT gpiobase+0x0044: 0x0400 (GP_IO_SEL3) DIFF gpiobase+0x0048: 0x0f80 (GPIO_LVL3) gpiobase+0x0048: 0x00c0 (GPIO_LVL3) DEFAULT gpiobase+0x0048: 0x0f40 (GPIO_LVL3) DIFF gpiobase+0x004c: 0x (RESERVED) gpiobase+0x0050: 0x (RESERVED) gpiobase+0x0054: 0x (RESERVED) gpiobase+0x0058: 0x (RESERVED) gpiobase+0x005c: 0x (RESERVED) gpiobase+0x0060: 0x8800 (GP_RST_SEL1) gpiobase+0x0060: 0x0100 (GP_RST_SEL1) DEFAULT gpiobase+0x0060: 0x01008800 (GP_RST_SEL1) DIFF gpiobase+0x0064: 0x (GP_RST_SEL2) gpiobase+0x0068: 0x (GP_RST_SEL3) gpiobase+0x006c: 0x (RESERVED) gpiobase+0x0070: 0x (RESERVED) gpiobase+0x0074: 0x (RESERVED) gpiobase+0x0078: 0x
[coreboot] Re: Add memory support for mb/apple: MacBook Air 5,2 (A1466)
Hi! Thank you. Just in case, can you please also attach the full output of inteltool -g. On 04.12.2021 13:30, Mariusz Grabarczyk wrote: Hi I would like to have memory support added for mb/apple: MacBook Air 5,2 (A1466) Per https://review.coreboot.org/c/coreboot/+/32604/36/Documentation/mainboard/apple/macbookair5_2.md#51 Originally https://review.coreboot.org/c/coreboot/+/32604 If your RAM configuration is not supported, you can help supporting it. Run `sudo inteltool -m`, save output to a text file and send a message to coreboot inteltool -g | get_macbook_ramcfg -m mba52 unsupported memory configuration 1 inteltool -m >> macbook52_memory Attached is dump file ___ coreboot mailing list --coreboot@coreboot.org To unsubscribe send an email tocoreboot-le...@coreboot.org___ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
[coreboot] Re: Does PCI driver code belong in coreboot (ARM)?
On Wed, Dec 1, 2021 at 10:08 PM Patrick Georgi wrote: > 1. Dezember 2021 12:06, "Paul Menzel" schrieb: > > If I remember correctly, coreboot’s goal to only do minimal hardware > > initialization originally meant, that the payload/OS does PCI > > initialization. > The original idea was to boot into Linux (hence LinuxBIOS, back in the day). > coreboot is very different from this scheme, see the presence of payloads > that aren't Linux. > > > Should PCI support be added to coreboot for ARM, so it’s aligned with > > x86? > > Should coreboot stay minimal on ARM, for example PCI code adds 100 ms delay > > [4]? Need to check with MTK folks, but I'd assume the 100ms will be eliminated in the end, or re-implemented as early-init (and do the rest in depthcharge). > > PCI drivers then have to be added to the payloads, which > > could be a minimal Linux kernel, so that booting from drives connected > > over PCI is possible? > The only option I see for getting rid of PCI support on ARM is to remodel the > relationships between coreboot, the payload and the OS. Reminds me that I > wanted to build a proof-of-concept for chainloaded payloads, a concept that > might help with such a redesign because we could move things out of coreboot > to "elsewhere" (wherever that might be) piece by piece. > > But as is, if there are PCI(e) devices that need early init, coreboot is the > place to put these drivers. Agree with Patrick - many eMMC devices do need early init, so in the end we still have to put some eMMC code in Coreboot, and I'd assume that will be the same situation for PCI-e (NVMe) and UFS. ___ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
[coreboot] Add memory support for mb/apple: MacBook Air 5,2 (A1466)
Hi I would like to have memory support added for mb/apple: MacBook Air 5,2 (A1466) Per https://review.coreboot.org/c/coreboot/+/32604/36/Documentation/mainboard/apple/macbookair5_2.md#51 Originally https://review.coreboot.org/c/coreboot/+/32604 If your RAM configuration is not supported, you can help supporting it. Run `sudo inteltool -m`, save output to a text file and send a message to coreboot inteltool -g | get_macbook_ramcfg -m mba52 unsupported memory configuration 1 inteltool -m >> macbook52_memory Attached is dump file macbook52_memory Description: Binary data ___ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
