[coreboot] Re: How to maintain AGESA-based ports long-term?

[Matt B]

I think you meant to reply-all on this Keith, not just to me?

On Sun, Dec 5, 2021 at 3:28 AM Keith Emery 
wrote:

> Bounty source still needs an issue / feature request URL to be able to
> determine if the funding goals have been met. Would it be possible to add
> this to the coreboot documentation directory and have known bugs and or
> feature requests render in an equivelent manner?
>
>
> On 5/12/21 6:48 pm, Matt B wrote:
>
> 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 build

[coreboot] Re: How to maintain AGESA-based ports long-term?

[Matt B]

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

[coreboot] Re: How to maintain AGESA-based ports long-term?

[Matt B]

>
> 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 change?
> >
> > Devices sold today will be as affordable tomorrow (well, on a slightly
> > larger timescale). What's your point?
> >
> > > 3) as available: these generic consumer electronics, which have been
> > > shipped with a proprietary UEFI but got coreboot support later, have a
> > > huge numbers all over the world - compared to the quite limited
> > > availability of newer coreboot platforms.
> >
> > I don't understand this point either. This will change, earth keeps
> > turning, right? Also, I'm quite sure that your numbers are wrong
> > anyway. Please check how many Chromebooks are sold, for instance.
> > These, are sold by people who actually support the project btw.
> >
> > >
> > > Sorry, I don't see any "newer platforms" which would match the "older
> > > platforms" on these critically-important points.
> >
> > You seem to be too much used to look behind. Please look ahead from
> > time to time. And regarding security, don't trust what you read on
> > the internet. It's far more subtle than non-PSP is secure, PSP is
> > insecure.
> >
> > Also, it's not about old vs. new hardware anyway. There's much older
> > hardware than the AGESA ports that will stay maintained. It's about
> > hardware that nobody took the time to write a proper, long-term main-
> > tainable coreboot for. And I can't blame anyone for it. Everything
> > AMD Bulldozer based always seemed like the most unattractive hard-
> > ware to me.

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

[Matt B]

>
> On a side note is there any kind of crowd sourcing platform / escrow
> service for GPL projects? I know it's been talked about, and there have
> been attempts made. But as far as I can tell, nothing has ever prospered.


 If  someone wanted to work with one of the approved coreboot contractors
> or individual contributor to set up a fundraiser of some sort to raise
> money to do things like this, that'd be great. We've had a requests for
> things like this in the past, but it's not something that the coreboot
> project itself can really do.  We don't want to pit one group of coreboot
> developers against another, and the coreboot project also doesn't deliver
> binaries or sign contracts for work, so coreboot can't make guarantees
> about deliverables.I'd be happy to help get a fundraiser set up if anyone
> is interested in doing the work, but it's going to have to go through an
> actual fundraising site, and of course we'd want to have a full written
> plan before starting anything.


I've seen bountysource employed for various things in the past, from
compatibility enhancements for POWER9 to GCC backend implementations for
AVR. I think it's reasonably fair, with the bounty available to whoever is
willing to put in the work to close the issue. The only thing missing that
I can see is the need for an "issue" (a la github issues) that can be
"closed" to trigger the end of the bounty. I don't know if gerrit supports
such a functionality.

On Sun, Nov 28, 2021 at 9:46 PM ron minnich  wrote:

> having read this discussion, and with all respect for all the opinions
> so clearly expressed, I still support Arthur's original proposal.
>
>
> On Sun, Nov 28, 2021 at 2:20 PM David Hendricks
>  wrote:
> >
> >
> >
> >> 1. These boards will be gone for the people who check the "mainboards
> >> supported by coreboot" and see only the "new Intel stuff". This
> >> hinders the coreboot community growth around the "gone boards", and
> >> also of the coreboot community in general: the fewer boards are
> >> supported by coreboot, the more difficult it is for a potential
> >> user/contributor to find the supported board and join us.
> >
> >
> > For the record, we have removed Intel boards from the master branch in
> the past - See 4.11_branch. This was for boards that used FSP 1.0,
> including popular Baytrail Atom and Broadwell-DE platforms which are still
> widely used today. This ensures that those platforms continue existence on
> an easy-to-find stable branch where one can reasonably expect to check out
> the code and have it work. Checking out the master branch only to find out
> that it doesn't work and then bisecting years worth of commits is a poor
> user experience.
> >
> > Perhaps we should follow the 4.11_branch example and do something
> similar with old AGESA boards? Boards which are forward-ported and tested
> can stay (or be re-introduced) in the master branch, of course.
> >
> > Many of the AGESA platforms in the list Arthur provided are ~10 years
> old. Some are clearly obsolete, like the Gizmosphere boards that have not
> been in production for years and whose manufacturer is defunct. Others like
> the PCEngines APUs should be more readily available to test and have
> developers able to spend some time forward-porting the necessary bits.
> >
> > Lastly, I'll mention that there is an active crowdfunding effort to
> re-upstream KGPE-D16 support:
> https://github.com/osresearch/heads/issues/719. There's clearly a lot of
> enthusiasm with that board, and 3mdeb is already porting allocate v4 to it.
> Perhaps enthusiasts for other boards can piggyback on this effort and
> leverage some of their work to bring other boards up to date.
> ___
> 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: How to maintain AGESA-based ports long-term?

[Matt B]

My two cents regarding funding:

There are quite a lot of concerned users who use AGESA platforms, but
aren't able to directly contribute to development (documentation and guides
are indeed thin). Funding through the usual channels for the overall
coreboot project seems to be impractical for bureaucratic reasons, but
perhaps an effort chosen here could be more readily funded through
something like https://www.bountysource.com/ ?

Even if the full total can't be covered, it may make it more worth
developer(s) time to undertake.

There's also potential tie-in with
https://github.com/osresearch/heads/issues/719 as the goal, cleaned up
AGESA code fit for mainline, is very much the same. If they clean up the
fam15h code that may provide a good base to undertake other cleanup work
for 16h and 14h.

On Sun, Nov 28, 2021 at 5:24 PM Nico Huber  wrote:

> On 28.11.21 19:54, Nico Huber wrote:
> > Oh, and I almost forgot, the board ports don't look like coreboot code.
> > There's CamelCase, odd tables in C code (as if there was no devicetree),
> > AGESA configuration done in the code of each and every mainboard that
> > should be done only once in the chipset code... IMHO it looks like a
> > mess. When one is used to coreboot and then sees this, there should
> > be no doubt why we have deprecation squabbles ;) This [1] might be
> > related. Board ports of other platforms have seen a lot of updates
> > over the last ten years, that's not easy for ports where one doesn't
> > know what to begin with.
>
> Looks like I forgot the ref here.
>
> [1] https://en.wikipedia.org/wiki/Broken_windows_theory
>
___
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

[Matt B]

It's definitely preferable to have platforms working in-tree rather than
out of tree. This is a *significant* portion of coreboot's supported
platforms and sends a strong signal to anyone using or considering them
that they can just forget about the coreboot project because the rug may be
pulled out from under them at any time.

These users didn't contribute fixes to their boards (or even just feedback
> that things needs to be done and testing when others provide patches) - are
> they even contributors?
> It's easy to argue in favor of "lots of users" (or contributors if you
> want), but if they're all but invisible, do they even exist?
>

 People constantly complain about a lack of developer manpower, yet also
don't care about how many users coreboot has. Do you not see that the only
source of the former is from the latter?

Loco is right about coreboot being more developer focused than user
focused. While there is now (finally!) some sane documentation for simple
things like creating a patch on gerrit, these few guides are very hard to
find especially from the coreboot.org frontpage. I'm still not aware of
anything even approaching a comprehensive porting guide. There is
effectively no path for users to follow to fix even the simplest bug. (eg.
I'd love to port from the AM1I-A to the AM1M-A, owning spares of both, but
the lack of guidance makes the process a black hole of inestimable time)

This is in STARK contrast to a project like PostmarketOS which puts a lot
of thought into bringing users into development work. They have font-page
guides that go into great detail on creating a new port. They even have
detailed guides on how to port a phone to the mainline kernel, for absolute
beginners. They have a simple all-in-one script that build the environment,
can create the files for a new port, and can automatically package these
changes for review. There are a lot of lessons to be learned from pmOS who
ran into exactly this problem and fixed it.

On Thu, Nov 25, 2021 at 12:17 PM Arthur Heymans  wrote:

> > 1. These boards will be gone for the people who check the "mainboards
> > supported by coreboot" and see only the "new Intel stuff". This
> > hinders the coreboot community growth around the "gone boards", and
> > also of the coreboot community in general: the fewer boards are
> > supported by coreboot, the more difficult it is for a potential
> > user/contributor to find the supported board and join us.
>
> Coreboot supports a lot more platforms than "new Intel stuff", which is
> quite an achievement.
> To make it possible for very different hardware in one branch, thoughtful
> design is needed.
> Supporting different codepaths to do the same thing blows up the
> complexity of maintenance and makes it harder to
> support both old and new boards as you lose track of how code changes can
> affect other systems.
> Keeping things simple is not optional in a project like coreboot. So it's
> not about adding
> a minor feature like you said in your previous email. It's really about
> keeping
> things manageable long term for everyone. That however requires some work
> from time to time on some platforms and sometimes dropping boards if no
> one steps up to do that work.
>
> > 2. It's not just the loss of boards - it's also the loss of coreboot
> > users/contributors who only have these boards and don't want to switch
> > to anything else: i.e. because the newer coreboot-supported boards
> > have Intel ME / AMD PSP that are viewed negatively by many people out
> > of security considerations, - and security is one of the top reasons
> > why the people switch to coreboot in the first place.
>
> Sorry, not buying that argument at all for AMD AGESA supported platforms.
> I don't see a lot of development on gerrit for these platforms especially
> in comparison with Intel ones of similar age.
>
> Regards
> Arthur
>
> On Thu, Nov 25, 2021 at 5:04 PM Mike Banon  wrote:
>
>> > The word 'drop' has ominous connotations, but it's not a deletion. A
>> board is never really gone.
>>
>> "Dropping" 50 boards may be ominous in relation to the future of the
>> coreboot project:
>>
>> 1. These boards will be gone for the people who check the "mainboards
>> supported by coreboot" and see only the "new Intel stuff". This
>> hinders the coreboot community growth around the "gone boards", and
>> also of the coreboot community in general: the fewer boards are
>> supported by coreboot, the more difficult it is for a potential
>> user/contributor to find the supported board and join us.
>>
>> 2. It's not just the loss of boards - it's also the loss of coreboot
>> users/contributors who only have these boards and don't want to switch
>> to anything else: i.e. because the newer coreboot-supported boards
>> have Intel ME / AMD PSP that are viewed negatively by many people out
>> of security considerations, - and security is one of the top reasons
>> why the people switch to coreboot in the first place.
>>
>> 3. Unless someone will be manu

[coreboot] Status of native Haswell raminit

[Matt B]

Greetings,

What is the status of native raminit on haswell? It's the first generation
that doesn't have a native implementation.

I did find some seemingly successful past work [1] but what happened to it?
Did it run into a blocker issue or was it just abandoned in favor of other
priorities?

[1]
https://code.georgi.software/coreboot/coreboot/commit/bc0066825877ea4f6e03cf5d4ab9c431615e2039

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

[coreboot] Re: 7010 Motherboard Variants

[Matt B]

Would the DT/MT board be expected to work?

On Sat, Oct 16, 2021 at 4:04 PM Matt B  wrote:

> A question about Optiplex 7010 motherboards:
>
> It appears (at least to me) that the DT and MT variants of the 7010 use
> the same motherboard, different from the SFF.
> The docs specify the SFF version. Has any testing been done on the DT/MT
> motherboard?
>
> The only mention in the documentation:
>
>> There are no schematics for SFF, but if one looks for MT/DT schematics,
>> they can be found publicly.
>
> Most of the schematics should match the SFF (although MT/DT has additional
>> PCIe and PCI slot).
>
>
> -M
>
___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] 7010 Motherboard Variants

[Matt B]

A question about Optiplex 7010 motherboards:

It appears (at least to me) that the DT and MT variants of the 7010 use the
same motherboard, different from the SFF.
The docs specify the SFF version. Has any testing been done on the DT/MT
motherboard?

The only mention in the documentation:

> There are no schematics for SFF, but if one looks for MT/DT schematics,
> they can be found publicly.

Most of the schematics should match the SFF (although MT/DT has additional
> PCIe and PCI slot).


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

[coreboot] Re: Atomic Accesses to Local APIC

[Matt B]

My concern is more about surprise brokenness when trying to use the newest
version, if any of those pentiums remain.

On Tue, Oct 5, 2021 at 4:06 PM ron minnich  wrote:

> That's what versions are all about. It seems sensible to me to leave
> the old bad stuff behind; if people need it, it's all still there if
> they know the tag.
>
> On Tue, Oct 5, 2021 at 1:02 PM Matt B  wrote:
> >
> > I should note I'm not 100% sure what they're doing there.
> >
> > Are there any more of these buggy pentiums left in the coreboot tree?
> (If he chooses to update) I can imagine RMS getting real snippy if we break
> his thinkpad. :P
> >
> > On Tue, Oct 5, 2021 at 3:53 PM ron minnich  wrote:
> >>
> >> nice fine. Might be worth adding the text of this comment (modified as
> >> needed) to the CL so that in years to come people understand the
> >> reasons.
> >>
> >> On Tue, Oct 5, 2021 at 12:51 PM Matt B 
> wrote:
> >> >
> >> > A quick google turned this up:
> >> >
> https://chromium.googlesource.com/chromiumos/third_party/kernel/+/chromeos-3.0/arch/x86/kernel/cpu/intel.c#253
> >> >
> >> > On Tue, Oct 5, 2021 at 4:06 AM Julian Stecklina <
> julian.steckl...@cyberus-technology.de> wrote:
> >> >>
> >> >> On Tue, 2021-10-05 at 09:29 +0300, Kyösti Mälkki wrote:
> >> >> > On Mon, Oct 4, 2021 at 8:12 PM Julian Stecklina
> >> >> >  wrote:
> >> >> > >
> >> >> > > 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
> >> >> >
> >> >>
> >> >> I've been looking at 4.13 instead of master. My bad. In master,
> indeed most
> >> >> atomic accesses are gone and the ones writing to ICR are left. This
> mostly makes
> >> >> sense and is much clearer now. :)
> >> >>
> >> >> Thanks,
> >> >> Julian
> >> >>
> >> >> ___
> >> >> coreboot mailing list -- coreboot@coreboot.org
> >> >> To unsubscribe send an email to coreboot-le...@coreboot.org
> >> >
> >> > ___
> >> > coreboot mailing list -- coreboot@coreboot.org
> >> > To unsubscribe send an email to coreboot-le...@coreboot.org
> >
> > ___
> > coreboot mailing list -- coreboot@coreboot.org
> > To unsubscribe send an email to coreboot-le...@coreboot.org
>
___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] Re: Atomic Accesses to Local APIC

[Matt B]

I should note I'm not 100% sure what they're doing there.

Are there any more of these buggy pentiums left in the coreboot tree? (If
he chooses to update) I can imagine RMS getting real snippy if we break his
thinkpad. :P

On Tue, Oct 5, 2021 at 3:53 PM ron minnich  wrote:

> nice fine. Might be worth adding the text of this comment (modified as
> needed) to the CL so that in years to come people understand the
> reasons.
>
> On Tue, Oct 5, 2021 at 12:51 PM Matt B  wrote:
> >
> > A quick google turned this up:
> >
> https://chromium.googlesource.com/chromiumos/third_party/kernel/+/chromeos-3.0/arch/x86/kernel/cpu/intel.c#253
> >
> > On Tue, Oct 5, 2021 at 4:06 AM Julian Stecklina <
> julian.steckl...@cyberus-technology.de> wrote:
> >>
> >> On Tue, 2021-10-05 at 09:29 +0300, Kyösti Mälkki wrote:
> >> > On Mon, Oct 4, 2021 at 8:12 PM Julian Stecklina
> >> >  wrote:
> >> > >
> >> > > 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
> >> >
> >>
> >> I've been looking at 4.13 instead of master. My bad. In master, indeed
> most
> >> atomic accesses are gone and the ones writing to ICR are left. This
> mostly makes
> >> sense and is much clearer now. :)
> >>
> >> Thanks,
> >> Julian
> >>
> >> ___
> >> coreboot mailing list -- coreboot@coreboot.org
> >> To unsubscribe send an email to coreboot-le...@coreboot.org
> >
> > ___
> > coreboot mailing list -- coreboot@coreboot.org
> > To unsubscribe send an email to coreboot-le...@coreboot.org
>
___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] Re: Atomic Accesses to Local APIC

[Matt B]

A quick google turned this up:
https://chromium.googlesource.com/chromiumos/third_party/kernel/+/chromeos-3.0/arch/x86/kernel/cpu/intel.c#253

On Tue, Oct 5, 2021 at 4:06 AM Julian Stecklina <
julian.steckl...@cyberus-technology.de> wrote:

> On Tue, 2021-10-05 at 09:29 +0300, Kyösti Mälkki wrote:
> > On Mon, Oct 4, 2021 at 8:12 PM Julian Stecklina
> >  wrote:
> > >
> > > 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
> >
>
> I've been looking at 4.13 instead of master. My bad. In master, indeed most
> atomic accesses are gone and the ones writing to ICR are left. This mostly
> makes
> sense and is much clearer now. :)
>
> Thanks,
> Julian
>
> ___
> 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: There is a python in our toolchain?!?

[Matt B]

> What coreboot problems that we have seen in the past are we actually
solving with these rewrites?
To be a bit more blunt, what is expected to be improved by writing it in
python?
Utilities, eg. to analyse blobs?
Menu and configuration of builds?
Packing blobs for flashing?

I could see some things being harmless, like using python to drive menus
and check dependencies. I could potentially see a case that it's preferable
to complicated #ifdef logic and for handling of board variants.

On the other hand, I could definitely see python adding new ways that
reproducible builds fail, unless you compile a specific python interpreter
on the spot. Who knows what subtle differences there might be in python's
handling of binary data, especially on different arches and systems with
different endianness? Maybe I'm paranoid, or maybe this stuff could be
caught well enough in automated testing (and $someone could fix it).

Perhaps user-driven utils like those that extract blobs or examine MSRs to
discover interrupt routing on proprietary firmware are a safer middle
ground between the two extremes, but those are already written in C aren't
they?

>Python is already being used, in the "util" directory. util/qualcomm has
~3500 LoC in Python [1] (this is not just a "small snippet" of code).
How was it introduced? Was this from a vendor dump? Those seem to
occasionally bend the rules of what would be "ideal."

-Matt


On Wed, Sep 29, 2021 at 5:15 PM Ricardo Quesada via coreboot <
coreboot@coreboot.org> wrote:

> Thanks Patrick for bringing this in.
>
> Regarding Pytest for utils (https://review.coreboot.org/c/coreboot/+/57869
> ), what's the recommended way to test the tools that are placed in "util/*"
> ?
> I noticed that most of them don't have any kind of end-to-end test (I
> couldn't find a single one, but perhaps I missed them).
>
> Using PyTest (or any other easy to install / easy to use framework) to
> create tests for util/* seems natural to me.
> Although any other test framework can be used. Suggestions?
>
> Besides all the things that have been said in favor or against Python, I'd
> like to add that:
>Python is already being used, in the "util" directory. util/qualcomm
> has ~3500 LoC in Python [1] (this is not just a "small snippet" of code).
>(compare it with PyTests for elogutil[2]: It has ~160 LoC ).
>
> [1]: https://github.com/coreboot/coreboot/tree/master/util/qualcomm
> [2]: https://review.coreboot.org/c/coreboot/+/57869
>
>
> Thanks.
>
>
> On Wed, Sep 29, 2021 at 12:09 PM Stefan Reinauer <
> stefan.k.reina...@gmail.com> wrote:
>
>> On Wed, Sep 29, 2021 at 7:44 AM Jack Rosenthal 
>> wrote:
>>
>>> Overall I think introducing Python to the build would provide net
>>> benefit, mainly from Kconfiglib, but could also find other good uses in e2e
>>> tests like Ricardo was working on. Most people's Linux distros ship with a
>>> Python interpreter too, so most developers would be unlikely to notice the
>>> extra dependency introduction.
>>>
>>> In terms of Kconfiglib, we have a lot to gain by switching away from the
>>> Linux C implementation of Kconfig, mainly the ~30kloc of C code that we've
>>> forked from the Linux tree and hacked in our own customizations
>>> (KCONFIG_NEGATIVES). With Kconfiglib, these customizations get turned into
>>> a miniature Python script
>>> 
>>> that we use to handle our custom header format, and a stable API to work
>>> off of so that we can uprev Kconfiglib without needing to change our
>>> scripts.
>>>
>>
>> Looking at the current Kconfiglib implementation we would be replacing
>> the C code with 21873 lines of Python code that is now taking the code to
>> deviate from what the Linux kernel is doing. I am having a hard time seeing
>> a "net benefit" in this scenario. Given the mess that Python 2 to Python 3
>> conversion has been (and still is), this is just inviting a lot of trouble
>> into what has been a fairly stable part of coreboot for the last decade.
>>
>> In terms of Kconfiglib's stability and track record: I think it has it
>>> covered. We adopted Kconfiglib in both Zephyr OS and in Depthcharge already
>>> without any issues at all.
>>>
>>
>> I am failing to see how anybody involved in coreboot would sign up for
>> and commit to porting 20k lines of Python code to the next version, when it
>> arrives. My indication is that not even the python code that is currently
>> in the tree has been ported to python3 yet.
>>
>>
>>> At a minimum, I think we should consider introducing Python on an
>>> optional basis (i.e., the C Kconfig implementation only gets used if a
>>> Python interpreter is unavailable), but making it required would be even
>>> better.
>>>
>>
>> Come on, we do not need two types of Kconfig parsers in the tree. Let's
>> focus coreboot on actually booting cores, not collections of
>> implementations in different programming languages. There are better

[coreboot] Re: ECC in native ram init? (sandy/ivy)

[Matt B]

Hello,

Thanks Angel. To clarify, the part of the chipset you're referring to would
be the memory controller on the CPU, yes? Not somewhere on the southbridge?

Thanks,
-Matt

On Wed, Sep 8, 2021 at 11:33 AM Angel Pons  wrote:

> Hi Matt, list,
>
> On Wed, Sep 8, 2021 at 3:29 PM Matt B  wrote:
> >
> > Would an Ivybridge CPU even be expected to work with RDIMMs? Was this
> something anticipated when native raminit was written?
>
> I don't think so. RDIMMs have higher latencies and very likely exceed
> the maximum value that can be programmed into the chipset's timing
> registers. Native raminit doesn't account for RDIMMs at all.
>
> > -Matt
>
> Best regards,
> Angel
>
___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] Re: ECC in native ram init? (sandy/ivy)

[Matt B]

Would an Ivybridge CPU even be expected to work with RDIMMs? Was this
something anticipated when native raminit was written?

-Matt

On Mon, Sep 6, 2021 at 6:00 PM Michał Żygowski 
wrote:

> Hi Matthew,
>
> On 8/31/21 11:46 PM, Matt B wrote:
> > Hello Patrick,
> >
> > Thank you very much for your reply!
> >
> > From subsequent investigation it appears that the ECC lines of the 7010
> > SFF are indeed connected and Xeon CPUs can be made to work under the
> > stock BIOS (and presumably under coreboot).
> >
> > A minor side question I have: does the chipset on intel ivybridge
> > platforms play a role in ECC support? It appears to me that the only
> > components involved are the CPU, RAM DIMMs, and BIOS.
> >
>
> I have some good news for you.
> 1) I can assure that ECC lines are connected between CPU and DIMMs on
> 7010/9010 DT schematics
> 2) I have successfully launched my OptiPlex 9010 SFF with a Xeon E3-1275
> v2 and 4x 4GB UDIMMs non-ECC.
>
> Unfortunately I haven't been able to launch the machine with ECC RDIMMs
> due to I/O latency overflow in the native raminit. Probably it will only
> work  with unregistered DIMMs (which I will probably try soon) because
> registers on the DIMMs introduce higher latency. Maybe Patrick can shed
> some light on this raminit matter?
>
> Best regards,
> --
> Michał Żygowski
> Firmware Engineer
> GPG: 6B5BA214D21FCEB2
> https://3mdeb.com | @3mdeb_com
> ___
> 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: ECC in native ram init? (sandy/ivy)

[Matt B]

Hello Patrick,

Thank you very much for your reply!

>From subsequent investigation it appears that the ECC lines of the 7010
SFF are indeed connected and Xeon CPUs can be made to work under the stock
BIOS (and presumably under coreboot).

A minor side question I have: does the chipset on intel ivybridge platforms
play a role in ECC support? It appears to me that the only components
involved are the CPU, RAM DIMMs, and BIOS.

Sincerely,
-Matthew Bradley

On Sat, Aug 14, 2021 at 12:24 PM Patrick Rudolph <
patrick.rudo...@9elements.com> wrote:

> Hi Matt,
> the ECC support on Sandy/Ivy Bridge should be fully working since Aug
> 2020, to be exact, commit b5fa9c8200423beb660403b6656fa8fd5d7edc31 .
> By default it is automatically enabled if the hostbridge and all DIMMs
> are ECC capable. It was tested on HP Z220 workstation PC.
>
> Regards,
> Patrick Rudolph
> B.Sc. Electrical Engineering
> System Firmware Developer
>
> 9elements GmbH, Kortumstraße 19-21, 44787 Bochum, Germany
> Email: patrick.rudo...@9elements.com
> Phone:  +49 234 68 94 188
>
> Sitz der Gesellschaft: Bochum
> Handelsregister: Amtsgericht Bochum, HRB 17519
> Geschäftsführung: Sebastian Deutsch, Eray Basar
>
> Datenschutzhinweise nach Art. 13 DSGVO
>
> On Fri, Aug 13, 2021 at 9:46 PM Matt B  wrote:
> >
> > Greetings,
> >
> > I gather that while native ram init is very far along and quite
> featureful, it doesn't support ECC. I'm interested to know if there have
> been past attempts at it, and what might be required for it to work.
> >
> > In the unofficial mapping [1] it looks like there's just one register to
> turn it on, plus some registers to inject faults for testing. (I imagine
> you would also need to clear the memory to avoid lots of errors from random
> initial contents, and make sure all the DIMMS are the same type first)
> >
> > It certainly "looks" simple (famous last words) so I'm wondering in part
> if the unofficial register documentation is just very incomplete? Is there
> any intel guidance on ECC out there?
> >
> > I suppose having ECC is attractive for servers, though I don't think
> people would still run ivybridge/sandybridge in production. I'm more
> interested in it for the Optiplex 9010 which appears to support ECC on the
> factory BIOS. [2] Would make a really nice NAS (external SAS disk shelf) if
> ECC worked under coreboot. Would also get bonus points as a
> daily-driver/home server from me.
> >
> > [1]
> https://doc.coreboot.org/northbridge/intel/sandybridge/nri_registers.html
> >
> > Sincerely,
> > -Matthew Bradley
> >
> > ___
> > 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] ECC in native ram init? (sandy/ivy)

[Matt B]

Greetings,

I gather that while native ram init is very far along and quite featureful,
it doesn't support ECC. I'm interested to know if there have been past
attempts at it, and what might be required for it to work.

In the unofficial mapping [1] it looks like there's just one register to
turn it on, plus some registers to inject faults for testing. (I
imagine you would also need to clear the memory to avoid lots of errors
from random initial contents, and make sure all the DIMMS are the same type
first)

It certainly "looks" simple (famous last words) so I'm wondering in part if
the unofficial register documentation is just very incomplete? Is there any
intel guidance on ECC out there?

I suppose having ECC is attractive for servers, though I don't think people
would still run ivybridge/sandybridge in production. I'm more interested in
it for the Optiplex 9010 which appears to support ECC on the factory BIOS.
[2] Would make a really nice NAS (external SAS disk shelf) if ECC worked
under coreboot. Would also get bonus points as a daily-driver/home server
from me.

[1]
https://doc.coreboot.org/northbridge/intel/sandybridge/nri_registers.html

Sincerely,
-Matthew Bradley
___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] Re: intel leak hits torrents

[Matt B]

I'm not touchin' any of this.

Reminds me an awful lot of the story of the PowerVR leak's cautionary tale:
https://libv.livejournal.com/26972.html

-Matt

On Thu, Aug 6, 2020 at 3:40 PM Simon Newton  wrote:

>
> https://www.tomshardware.com/news/massive-20gb-intel-data-breach-floods-the-internet-mentions-backdoors
>
>
> n fact, the title of many of the documents do correlate to the list of
> purported information posted by the leaker:
>
>- Intel ME Bringup guides + (flash) tooling + samples for various
>platforms
>- Kabylake (Purley Platform) BIOS Reference Code and Sample Code +
>Initialization code (some of it as exported git repos with full history)
>- Intel CEFDK (Consumer Electronics Firmware Development Kit
>(Bootloader stuff)) SOURCES
>- Silicon / FSP source code packages for various platforms
>- Various Intel Development and Debugging Tools
>- Simics Simulation for Rocket Lake S and potentially other platforms
>- Various roadmaps and other documents
>- Binaries for Camera drivers Intel made for SpaceX
>- Schematics, Docs, Tools + Firmware for the unreleased Tiger Lake
>platform
>- (very horrible) Kabylake FDK training videos
>- Intel Trace Hub + decoder files for various Intel ME versions
>- Elkhart Lake Silicon Reference and Platform Sample Code
>- Some Verilog stuff for various Xeon Platforms, unsure what it is
>exactly.
>- Debug BIOS/TXE builds for various Platforms
>- Bootguard SDK (encrypted zip)
>- Intel Snowridge / Snowfish Process Simulator ADK
>- Various schematics
>- Intel Marketing Material Templates (InDesign)
>- Lots of other things
>
>
> --
> Kind Regards,
>
> Simon Newton
>
> E: simon.new...@gmail.com
> ___
> 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: Porting Coreboot without Intel FSP

[Matt B]

Hi,

Doing a quick google this comes up, where it seems someone else looked at
this CPU before:
https://www.mail-archive.com/search?l=coreboot@coreboot.org&q=subject
:"\[coreboot\]+Re\%3A+About+support+for+my+netbook"&o=newest&f=1

It seems there's no support for this CPU/chipset in coreboot, ao at the
very least you'd have to update and adapt some very old pineview code to
support cedarview, assuming it's possible. No idea whether an FSP would be
required, but I'd guess not considering the age of the chipset? (not to
mention, if no FSP is available then you can't use it whether any other
method is possible or not)

Even assuming you could somehow scrape together CPU and chipset support,
you'd then need to go through the arduous process of porting to the
motherboard itself, adapting coreboot to match it's wiring.

As for U-Boot vs Coreboot, Coreboot+payload is primarily targeted at x86 at
the moment (sorry Ron!) whereas I've seen U-Boot more commonly on
ARM/MIPS/PowerPC embedded systems. My understanding is that both do much
the same job however, though in different ways with different features.

Sincerely,
-Matthew Bradley

On Wed, Jul 15, 2020 at 8:43 AM Alif Ilhan  wrote:

> Pardon me for absurd questions, I am a noob. Is there any way to port
> coreboot to my netbook without Intel FSP. Or is there any way I could
> generate Intel FSP for my netbook? My netbook has Intel Atom N2600 CPU
> which doesn't seem to have any Intel FSP available. Please, if there is any
> guide to port coreboot to a new device WITHOUT Intel FSP, tell me about it.
> And can you tell me the difference between Coreboot and U-Boot and how each
> one is different from the other?
>
> Thanks
> Alif
> ___
> 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] Difference between GA-B75M-D3V and GA-B75M-D3H?

[Matt B]

Hi,

Noticed someone running a GA-B75M-D3V with coreboot but that it hadn't had
a status report since 2017. I did notice that GA-B75M-D3H is still around
though with a status from may of 2019.

Is the GA-B75M-D3H supported in the latest master? What's the difference
between these two?

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

[coreboot] DRI_PRIME on G505s with enabled dGPU?

[Matt B]

Hi,

Quick question before I go out and buy a different motherboard for my G505s:

To those who have a dual-GPU G505s and have enabled the recent support for
the dGPU, does DRI_PRIME GPU offloading work?

Thanks,
-Matt

PS. Could here be an option created to enable/disable the dGPU at boot time
without recompiling?
___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] Re: Status of Optimus work? Target laptops?

[Matt B]

>
> Further work is required to make it stable and cross-platform.
>
What is it that triggers the instability (freezing?)? Does it have to do
with the the nvidia drivers?
What do you mean by cross-platform? are there other laptops which might
benefit from it?

Sincerely,
-Matt

On Fri, Feb 28, 2020 at 3:35 PM Evgeny Zinoviev via coreboot <
coreboot@coreboot.org> wrote:

> > Is [1] the current, most recent work on supporting nvidia Optimus?
> Yes! Needs rebasing, though.
> ___
> 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: Status of Optimus work? Target laptops?

[Matt B]

Is [1] the current, most recent work on supporting nvidia Optimus?
It seems to be fairly complete (aside from some stability issues) and
frequently worked on.

-Matt

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

On Thu, Feb 20, 2020 at 2:28 PM Matt B  wrote:

> Hi,
>
> As I understand it, the only thing missing with regard to nvidia dGPUs on
> Coreboot are the ACPI calls to turn them on and off at run-time, which is
> what Optimus is. Things like DRI_PRIME and similar work just fine as long
> as the dGPU is running, even under nouveau.
>
> What is the current status of the work to get nvidia Optimus working? From
> what I gather there have been a couple of attempts and a recent restart,
> but I don't know what the current status of this work is.
>
> I have heard that some laptops currently have the option to switch the
> dGPU on or off at boot-time. For which ones does this work?
>
> If the work on Optimus is completed, what laptops are most likely to
> support it? My expectation is that turning the GPU on or off may be
> different for different laptops, even though the ACPI calls are the same,
> and so may not work everywhere.
>
> Thanks,
> -Matt
>
>
>
___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] Status of Optimus work? Target laptops?

[Matt B]

Hi,

As I understand it, the only thing missing with regard to nvidia dGPUs on
Coreboot are the ACPI calls to turn them on and off at run-time, which is
what Optimus is. Things like DRI_PRIME and similar work just fine as long
as the dGPU is running, even under nouveau.

What is the current status of the work to get nvidia Optimus working? From
what I gather there have been a couple of attempts and a recent restart,
but I don't know what the current status of this work is.

I have heard that some laptops currently have the option to switch the dGPU
on or off at boot-time. For which ones does this work?

If the work on Optimus is completed, what laptops are most likely to
support it? My expectation is that turning the GPU on or off may be
different for different laptops, even though the ACPI calls are the same,
and so may not work everywhere.

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

[coreboot] Re: AM1I-A Failing to Boot

[Matt B]

Hello,

4.11-400

What is the extra -400? It doesn't seem like a commit hash.

Sincerely,
-Matt

On Thu, Dec 12, 2019 at 5:23 PM Kyösti Mälkki 
wrote:

> 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: AM1I-A Failing to Boot

[Matt B]

Hi,

I am likely unable to work on this until after the 14th. (with final exams
finishing this week)
As I understand it, unfixed boards will be disabled from automatic
building after the 14th, but will not be dropped until the 31st?

-Matt

On Mon, Dec 9, 2019 at 10:55 AM Michal Zygowski 
wrote:

> On 09.12.2019 05:36, Matt B wrote:
>
> Hi,
>
> Hi Matt,
>
>
> Thanks for the pointer.
>
> I need a bit more context here, being completely unfamiliar with how
> coreboot works.
> I've never done any non-userspace programming, and this is the first time
> I've gotten a freshly-compiled coreboot to actually boot.
> I do have most of a degree in computer engineering, but that's
> unfortunately 99% theory with little-to-no hands-on experience.
>
> A) If I understand correctly, [1] is the complete change (not the last
> commit in a series for this board) to remove romcc usage from
> asrock/imb-a180.
> The same changes need to be applied to asus/am1i-a.
>
> B) If I understand correctly, the necessary family16h changes have been
> made elsewhere, so only changes to the mainboard-specific code need to be
> made.
> This would explain why there is a net removal of code, not addition.
>
> C) I can't say that I really understand the contents of this file. Can
> someone explain how
>
>> /* Set LPC decode enables. */
>> pci_devfn_t dev = PCI_DEV(0, 0x14, 3);
>> pci_write_config32(dev, 0x44, 0xff03ffd5);
>>
> and
>
>> /* Enable the AcpiMmio space */
>> outb(0x24, 0xcd6);
>> outb(0x1, 0xcd7);
>>
> and
>
>> /* Disable PCI-PCI bridge and release GPIO32/33 for other uses. */
>> outb(0xea, 0xcd6);
>> outb(0x1, 0xcd7);
>
> becomes
>
>> /* Disable PCI-PCI bridge and release GPIO32/33 for other uses. */
>> pm_write8(0xea, 0x1);
>
> ?
>
> We did a lot of cleanup with Kyösti and unified implementations of LPC
> decode enables and ACPIMMIO. Those instructions you point to were moved to
> southbridge bootblock initialization, because it is not mainboard specific.
> Also pm_write8(0xea, 0x1); does the same thing as outb(0xea, 0xcd6); and
> outb(0x1, 0xcd7); but in more readable form. See:
> https://review.coreboot.org/c/coreboot/+/37177
> https://review.coreboot.org/c/coreboot/+/37329/
> https://review.coreboot.org/c/coreboot/+/37168/
>
>
> D) I'm a bit confused about what [2] is. Is this an earlier, unrefined
> version of the changes?
>
> I don't think that a naive transform would be wise, as there is a lot more
> stuff going on in [3] :P
> For instance:
> 1) would
>
>> /* In Hudson RRG, PMIOxD2[5:4] is "Drive strength control for
>> * LpcClk[1:0]".  To be consistent with Parmer, setting to 4mA
>> * even though the register is not documented in the Kabini BKDG.
>> * Otherwise the serial output is bad code.
>> */
>> outb(0xD2, 0xcd6);
>> outb(0x00, 0xcd7);
>>
> and
>
> This was also moved to southbridge bootblock initialization - not
> mainboard specific.
>
> /* Disable PCI-PCI bridge and release GPIO32/33 for other uses. */
>> outb(0xEA, 0xcd6);
>> outb(0x1, 0xcd7);
>
> be transformed similarly to how
>
>>  /* Disable PCI-PCI bridge and release GPIO32/33 for other uses. */
>> outb(0xea, 0xcd6);
>> outb(0x1, 0xcd7);
>
> coreboot uses lowercase for hex values. This should be transformed to
> pm_write8(0xea, 1).
>
> was?
> 2) would
>
>> /* Set LPC decode enables. */
>> pci_devfn_t dev2 = PCI_DEV(0, 0x14, 3);
>> pci_write_config32(dev2, 0x44, 0xff03ffd5);
>
> and
>
>> /* Enable the AcpiMmio space */
>> outb(0x24, 0xcd6);
>> outb(0x1, 0xcd7);
>
> completely disappear?
> what about
>
>> hudson_lpc_port80();
>
> in the middle?
> 4) Would
>
>> /* Configure ClkDrvStr1 settings */
>> addr32 = (u32 *)0xfed80e24;
>> *addr32 = 0x030800aa;
>
> /* Configure MiscClkCntl1 settings */
>> addr32 = (u32 *)0xfed80e40;
>> *addr32 = 0x000c4050;
>> /* enable SIO LPC decode */
>> dev = PCI_DEV(0, 0x14, 3);
>> byte = pci_read_config8(dev, 0x48);
>> byte |= 3; /* 2e, 2f & 4e, 4f */
>> pci_write_config8(dev, 0x48, byte);
>> ite_gpio_conf(GPIO_DEV);
>> ite_evc_conf(ENVC_DEV);
>> ite_conf_clkin(CLKIN_DEV, ITE_UART_CLK_PREDIVIDE_48);
>> ite_enable_serial(SERIAL_DEV, CONFIG_TTYS0_BASE);
>> ite_kill_watchdog(GPIO_DEV);
>> /*
>> * On Larne, after LpcClkDrvSth is set, it needs some time to be stable,
>> * because of the buffer ICS551M
>> */
>> for (i = 0; i < 20; i++)
>> val = inb(0xcd6);
>
> remain unchanged?
>
> It should be something li

[coreboot] Re: AM1I-A Failing to Boot

[Matt B]

Hi,

Thanks for the pointer.

I need a bit more context here, being completely unfamiliar with how
coreboot works.
I've never done any non-userspace programming, and this is the first time
I've gotten a freshly-compiled coreboot to actually boot.
I do have most of a degree in computer engineering, but that's
unfortunately 99% theory with little-to-no hands-on experience.

A) If I understand correctly, [1] is the complete change (not the last
commit in a series for this board) to remove romcc usage from
asrock/imb-a180.
The same changes need to be applied to asus/am1i-a.

B) If I understand correctly, the necessary family16h changes have been
made elsewhere, so only changes to the mainboard-specific code need to be
made.
This would explain why there is a net removal of code, not addition.

C) I can't say that I really understand the contents of this file. Can
someone explain how

> /* Set LPC decode enables. */
> pci_devfn_t dev = PCI_DEV(0, 0x14, 3);
> pci_write_config32(dev, 0x44, 0xff03ffd5);
>
and

> /* Enable the AcpiMmio space */
> outb(0x24, 0xcd6);
> outb(0x1, 0xcd7);
>
and

> /* Disable PCI-PCI bridge and release GPIO32/33 for other uses. */
> outb(0xea, 0xcd6);
> outb(0x1, 0xcd7);

becomes

> /* Disable PCI-PCI bridge and release GPIO32/33 for other uses. */
> pm_write8(0xea, 0x1);

?

D) I'm a bit confused about what [2] is. Is this an earlier, unrefined
version of the changes?

I don't think that a naive transform would be wise, as there is a lot more
stuff going on in [3] :P
For instance:
1) would

> /* In Hudson RRG, PMIOxD2[5:4] is "Drive strength control for
> * LpcClk[1:0]".  To be consistent with Parmer, setting to 4mA
> * even though the register is not documented in the Kabini BKDG.
> * Otherwise the serial output is bad code.
> */
> outb(0xD2, 0xcd6);
> outb(0x00, 0xcd7);
>
and

> /* Disable PCI-PCI bridge and release GPIO32/33 for other uses. */
> outb(0xEA, 0xcd6);
> outb(0x1, 0xcd7);

be transformed similarly to how

>  /* Disable PCI-PCI bridge and release GPIO32/33 for other uses. */
> outb(0xea, 0xcd6);
> outb(0x1, 0xcd7);

was?
2) would

> /* Set LPC decode enables. */
> pci_devfn_t dev2 = PCI_DEV(0, 0x14, 3);
> pci_write_config32(dev2, 0x44, 0xff03ffd5);

and

> /* Enable the AcpiMmio space */
> outb(0x24, 0xcd6);
> outb(0x1, 0xcd7);

completely disappear?
what about

> hudson_lpc_port80();

in the middle?
4) Would

> /* Configure ClkDrvStr1 settings */
> addr32 = (u32 *)0xfed80e24;
> *addr32 = 0x030800aa;

/* Configure MiscClkCntl1 settings */
> addr32 = (u32 *)0xfed80e40;
> *addr32 = 0x000c4050;
> /* enable SIO LPC decode */
> dev = PCI_DEV(0, 0x14, 3);
> byte = pci_read_config8(dev, 0x48);
> byte |= 3; /* 2e, 2f & 4e, 4f */
> pci_write_config8(dev, 0x48, byte);
> ite_gpio_conf(GPIO_DEV);
> ite_evc_conf(ENVC_DEV);
> ite_conf_clkin(CLKIN_DEV, ITE_UART_CLK_PREDIVIDE_48);
> ite_enable_serial(SERIAL_DEV, CONFIG_TTYS0_BASE);
> ite_kill_watchdog(GPIO_DEV);
> /*
> * On Larne, after LpcClkDrvSth is set, it needs some time to be stable,
> * because of the buffer ICS551M
> */
> for (i = 0; i < 20; i++)
> val = inb(0xcd6);

remain unchanged?

Sincerely,
-Matt

[1] https://review.coreboot.org/c/coreboot/+/37453/9
[2] https://review.coreboot.org/c/coreboot/+/37440/10
[3] src/mainboard/asus/am1i-a/romstage.c (for reference:
https://pastebin.com/kSka2YL7)


On Sun, Dec 8, 2019 at 6:57 PM Kyösti Mälkki 
wrote:

> 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: Intel Atom C2000 SOC - Do they lack Intel ME?

[Matt B]

Hi,

I have heard an unverified rumour that Atom substitutes the ME for an ARM
microcontroller running Trustzone.
If this is the case however, it's possible it's only for bringup, in which
case it's not too much different from the inaccessible micrcontrollers
already present in most x86 silicon.
(eg superio chips with their own baked-in firmware)

It's something worth looking into, but probably not even on the same scale
as the ME.

At the same time, a micro-itx board like this one would be FANTASTIC for a
NAS device, as many NAS-oriented cases with built-in bays are
micro-itx-only.
If such a board existed in coreboot with ECC support (not available in my
AM1I-A) a year ago, my own NAS build would have been quite a bit different.

Sincerely,
-Matt

On Tue, Dec 3, 2019 at 10:32 AM Kinky Nekoboi 
wrote:

> Hallo Goetz,
>
> thanks for that information.
>
> I am aware of this bug, but i read that Intel released an PCB level
> workaround what hopefully supermicro has applied on my new bought board.
>
> As i have only one board atm what is now in a "Production System" i am
> not able to activly test it but for interesst i would like to take a
> look on this image..
>
> But that pure fact that eart of my storage server has still no ME inside
> makes me happy already.
>
> Am 03.12.19 um 13:25 schrieb Goetz Salzmann:
> > Hi Kinky,
> >
> >> i sadly had to replace KGPE-d16 board for my fileserver to a Supermicro
> >> A1SRi-C2558 because of electric pill 
> >>
> >> investigating a bit with intelmetool and mecleaner non of them could
> >> found any sign for an ME-region in this board.. so i asking myself if
> >> there is no ME/SPS on the intel C2000 socs, what would make them a DAMN
> >> SEXY platform to port coreboot too.
> > to answer your other question: yes the Intel Rangeley (C2000) is the
> > last/newest SoC what does not include a ME(like) subsystem.
> >
> > Unfortunately the SoC has a fatal hardware bug:
> >
> https://www.extremetech.com/computing/244074-intel-atom-c2000-bug-killing-products-multiple-manufacturers
> >
> > But this hardware bug has resurfaced on some of the later ATOMs aswell.
> >
> > There is a Golden Master Image for coreboot from intel, but it's
> > probably not publicaly available, OTOH if you want to work on Rangely,
> > there should be someone on this list, that can arange for you to get
> > this "drop".
> >
> > Another pointer:
> >  https://mail.coreboot.org/pipermail/coreboot/2017-March/083712.html
> >
> > Cu,
> >  Goetz.
> >
> >
> > ___
> > coreboot mailing list -- coreboot@coreboot.org
> > To unsubscribe send an email to coreboot-le...@coreboot.org
> ___
> coreboot mailing list -- coreboot@coreboot.org
> To unsubscribe send an email to coreboot-le...@coreboot.org
>
___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] Re: Enable non-NVME devices in M.2 slot?

[Matt B]

As somebody who's abused the hell out of pcie extenders (I have over three
meters of pcie-over-cheap-usb3.0-cable in one box) I've never had an
obvious issue so it seems pretty tolerant. You probably just won't get the
same transfer speed.

I would check if any drives you have show up as being attached to pcie
instead of sata when in that slot.
Also double check it's keying. If the keying of the slot is such that it
can't even accept an nvme drive, then there's your answer right there.

Sincerely,
-Matt

On Sun, Dec 8, 2019 at 6:12 PM Rafael Send 
wrote:

> Hey,
> I used the mini PCIe -> x1PCIe version with the same cable length from the
> same people to test the card in the WiFi slot successfully, so I doubt that
> it is a signal integrity problem.
>
> I'll try to build against coreboot master on Monday and see what happens.
>
> How can I get the sort of logs that would help here out of coreboot?
> I'll be building with Tianocore.
>
> Cheers,
> Rafael
>
> On Sat, Dec 7, 2019, 04:58 Nico Huber  wrote:
>
>> Hi Rafael,
>>
>> On 07.12.19 07:40, Rafael Send wrote:
>> > However, so far nothing I've done lets me detect the Sunix card if I
>> try to
>> > put it in the NVME slot using this adapter
>> > . I would think it should just
>> show
>> > up under "lspci" like it does in the WiFi slot, but it does not.
>>
>> have you tried the adapter with another device yet? Though, even if it
>> did work, from above link:
>>
>>"1. All kinds of Motherboard and equipment condition such as signal
>> driving ability is different, the results of our test does not
>> guarantee that it is the same as your test results. You need to
>> know, as long as using a extension cable, the signal will have a
>> loss. The buyer who requires perfectly, please don't buy."
>>
>> So they know, that board design matters for the compatibility of their
>> adapter. I'm a mere software developer, so could be totally wrong about
>> this: PCIe rates are now that high that the trace length between chips
>> can get longer than a wavelength. Doesn't mean it can't work, but there
>> may be things to take special care of and I don't know if regular PCIe
>> ports are prepared for it. In other words, lightspeed might be too slow
>> to make things like this plug'n'play :D
>>
>> > I have not tried the latest Coreboot / port yet, but I figured I might
>> as
>> > well get some opinions on the subject.
>>
>> Still worth a shot, imho. You never know what a proprietary BIOS does.
>> And even if it doesn't work, coreboot logs can give some insight.
>>
>> Nico
>>
> ___
> 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: AM1I-A Failing to Boot

[Matt B]

Question specifically for Kyösti Mälkki or those similarly knowledgeable:

My current .config seems to say I'm still using romcc.
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?

Thanks,
-Matt

On Sun, Dec 8, 2019 at 5:19 PM Matt B  wrote:

> Ok. I'm kind of annoyed at myself now.
>
> Your thread revealed the answer. The stock bios will boot if the dimm is
> in either slot. Coreboot will only boot if it is in the outermost one.
> It never occurred to me to try this.
>
> The board now boots to the OS. More details to follow later this evening
> or tomorrow morning.
>
> Thanks,
> -Matt
>
> On Sun, Dec 8, 2019 at 3:45 PM Elisenda Cuadros  wrote:
>
>> Hi Matt,
>>
>> Did you see this old thread?
>>
>> https://www.mail-archive.com/coreboot@coreboot.org/msg51097.html
>>
>> I have and AM1I-A too and I had some problems at the beginning..
>>
>> Regards,
>>
>> Eli
>> On 08/12/2019 19:43, 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.
>>
>> The board boots fine under the stock bios, and returns to working order
>> if flashed with my backup, but shows little signs of life with coreboot.
>>
>> Along the way I extracted and included the vgabios rom, as well as tried
>> with a nivida card, so I'm pretty sure that's not it.
>>
>> I tried having it save the console output to flash, but that made the
>> build fail. [1]
>>
>> Yesterday evening I noticed it was configured by default to use
>> open-source init (and for some reason the build finishes without error),
>> but as far as I know that doesn't exist for family 16h. Switching to
>> BinaryPI causes the build to fail. [2] 3rd party blobs are cloned and
>> enabled.
>>
>> I'm running an Athlon 5250, or something of that nature, with a couple of
>> gigs of ram on one dimm. My current .config is [3].
>>
>> Sincerely,
>> -Matt
>>
>> [1] https://pastebin.com/FZEiCq8P
>> [2] https://pastebin.com/Q30u7Lgs
>> [3] https://pastebin.com/ufuq22i8
>>
>> ___
>> coreboot mailing list -- coreboot@coreboot.org
>> To unsubscribe send an email to coreboot-le...@coreboot.org
>>
>> ___
>> coreboot mailing list -- coreboot@coreboot.org
>> To unsubscribe send an email to coreboot-le...@coreboot.org
>>
>
___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] Re: AM1I-A Failing to Boot

[Matt B]

Ok. I'm kind of annoyed at myself now.

Your thread revealed the answer. The stock bios will boot if the dimm is in
either slot. Coreboot will only boot if it is in the outermost one.
It never occurred to me to try this.

The board now boots to the OS. More details to follow later this evening
or tomorrow morning.

Thanks,
-Matt

On Sun, Dec 8, 2019 at 3:45 PM Elisenda Cuadros  wrote:

> Hi Matt,
>
> Did you see this old thread?
>
> https://www.mail-archive.com/coreboot@coreboot.org/msg51097.html
>
> I have and AM1I-A too and I had some problems at the beginning..
>
> Regards,
>
> Eli
> On 08/12/2019 19:43, 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.
>
> The board boots fine under the stock bios, and returns to working order if
> flashed with my backup, but shows little signs of life with coreboot.
>
> Along the way I extracted and included the vgabios rom, as well as tried
> with a nivida card, so I'm pretty sure that's not it.
>
> I tried having it save the console output to flash, but that made the
> build fail. [1]
>
> Yesterday evening I noticed it was configured by default to use
> open-source init (and for some reason the build finishes without error),
> but as far as I know that doesn't exist for family 16h. Switching to
> BinaryPI causes the build to fail. [2] 3rd party blobs are cloned and
> enabled.
>
> I'm running an Athlon 5250, or something of that nature, with a couple of
> gigs of ram on one dimm. My current .config is [3].
>
> Sincerely,
> -Matt
>
> [1] https://pastebin.com/FZEiCq8P
> [2] https://pastebin.com/Q30u7Lgs
> [3] https://pastebin.com/ufuq22i8
>
> ___
> coreboot mailing list -- coreboot@coreboot.org
> To unsubscribe send an email to coreboot-le...@coreboot.org
>
> ___
> coreboot mailing list -- coreboot@coreboot.org
> To unsubscribe send an email to coreboot-le...@coreboot.org
>
___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] Re: AM1I-A Failing to Boot

[Matt B]

I've also left the board for an hour or two, just in case this was slow ram
training or something

-Matt

On Sun, Dec 8, 2019 at 1:43 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.
>
> The board boots fine under the stock bios, and returns to working order if
> flashed with my backup, but shows little signs of life with coreboot.
>
> Along the way I extracted and included the vgabios rom, as well as tried
> with a nivida card, so I'm pretty sure that's not it.
>
> I tried having it save the console output to flash, but that made the
> build fail. [1]
>
> Yesterday evening I noticed it was configured by default to use
> open-source init (and for some reason the build finishes without error),
> but as far as I know that doesn't exist for family 16h. Switching to
> BinaryPI causes the build to fail. [2] 3rd party blobs are cloned and
> enabled.
>
> I'm running an Athlon 5250, or something of that nature, with a couple of
> gigs of ram on one dimm. My current .config is [3].
>
> Sincerely,
> -Matt
>
> [1] https://pastebin.com/FZEiCq8P
> [2] https://pastebin.com/Q30u7Lgs
> [3] https://pastebin.com/ufuq22i8
>
___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] AM1I-A Failing to Boot

[Matt B]

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.

The board boots fine under the stock bios, and returns to working order if
flashed with my backup, but shows little signs of life with coreboot.

Along the way I extracted and included the vgabios rom, as well as tried
with a nivida card, so I'm pretty sure that's not it.

I tried having it save the console output to flash, but that made the build
fail. [1]

Yesterday evening I noticed it was configured by default to use open-source
init (and for some reason the build finishes without error), but as far as
I know that doesn't exist for family 16h. Switching to BinaryPI causes the
build to fail. [2] 3rd party blobs are cloned and enabled.

I'm running an Athlon 5250, or something of that nature, with a couple of
gigs of ram on one dimm. My current .config is [3].

Sincerely,
-Matt

[1] https://pastebin.com/FZEiCq8P
[2] https://pastebin.com/Q30u7Lgs
[3] https://pastebin.com/ufuq22i8
___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] Re: AMD binaryPI board removals

[Matt B]

Hi,

I noted this on this thread's companion regarding AGESA, but I'd be willing
to put up some money on https://www.bountysource.com/ for migration away
from ROMCC_BOOTBLOCK.
I could have sworn asus/am1i-a mentioned over there was a BinaryPI board.

Thoughts?

Sincerely,
-Matt

On Wed, Dec 4, 2019 at 2:10 AM Jorge Fernandez Monteagudo 
wrote:

> >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.
>
> In my case I have a bettong and pademelon demoboards and i would like
> to get them supported by coreboot. We don't manufacture any product with
> these processors but maybe they are viable options in a near future.
>
> I've been able to make it work the vboot, a TPM/TPM2 through LPC and the
> SATA
> but there are minor changes that I don't mind to contribute. I think that
> I only can
> be useful to report the board status with every release but I think I'm
> not able to
> develop any feature on them.
>
> Regards
> Jorge
> ___
> 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: AMD AGESA board removals

[Matt B]

Hi,

Regarding lenovo/g505s, asus/am1i-a, and maybe some others (suggestions
welcome!) I'd be willing to put up some money on
https://www.bountysource.com/ for their migration away from ROMCC_BOOTBLOCK.

Thoughts?

Sincerely,
-Matt

On Wed, Dec 4, 2019 at 10:26 AM Michal Zygowski 
wrote:

>
> On 04.12.2019 16:15, Kyösti Mälkki wrote:
> > 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.
> True. The NCT5104D has UARTA LDN enabled by default with
> IO base 0x3f8. So Vbat wouldn't affect it at all.
> >
> > Kyösti
> > ___
> > 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 mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] Re: Basic hardware documentation

[Matt B]

Hello,

Adding to this, it would also be good to have what
CPUs/chipsets/superIOs/etc coreboot supports. As I mentioned in another
thread, this information is currently very disparate and out of date and
can only really discovered by asking on this mailing list.

Sincerely,
-Matt

On Mon, Oct 7, 2019 at 10:27 AM Rafael Machado <
rafaelrodrigues.mach...@gmail.com> wrote:

> Hi Christoph
>
> I consider this a really good idea. It would help the beginners to
> understanding a lot of things.
>
> Rafael
>
> Em seg, 7 de out de 2019 às 06:53, Christoph Pomaska via coreboot <
> coreboot@coreboot.org> escreveu:
>
>> Hi,
>>
>> I had the idea of contributing basic information about hardware
>> components to the coreboot documentation
>> in the style of "What is Super I/O?" and similar.
>>
>> What do other people think of that?
>>
>>
>> Best regards
>>
>> Christoph Pomaska
>>
>> hosting.de GmbH
>> Franzstr. 51
>> 52064 Aachen
>>
>> Telefon: 0241 46314 480
>> Telefax: 0241 46314 489
>>
>> http://www.hosting.de
>>
>> Registergericht: Amtsgericht Aachen
>> Registernummer: HRB 13988
>> Geschäftsführer: Oliver Dick, Oguzhan Gökal
>>
>> ___
>> coreboot mailing list -- coreboot@coreboot.org
>> To unsubscribe send an email to coreboot-le...@coreboot.org
>>
> ___
> coreboot mailing list -- coreboot@coreboot.org
> To unsubscribe send an email to coreboot-le...@coreboot.org
>
___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] Re: G505S (coreboot AMD no-PSP laptop) being sold for a good price, 40 mins left

[Matt B]

Neat. I've seen a few of these pop up every couple of months.
A lot of them seems to be sold from the UK, dunno why.

-Matt

On Fri, Oct 4, 2019 at 12:18 PM Ivan Ivanov  wrote:

> Mike found a good condition G505S with top A10-5750M CPU preinstalled,
> being sold for a good price:
>
>
> https://www.ebay.com/itm/LENOVO-G505S-LAPTOP-WINDOWS-10-AMD-A10-WEBCAM-4GB-500GB-15-6-HDMI-GRADE-C-14414/264479816991
>
> Initially we wanted to share this link with our friend, but sadly he
> is not online in the moment and unlikely to come in time, so now
> sharing with everyone! Hopefully it could end up in the hands of a
> fellow coreboot'er. Please tell others if you'd like to bid, to avoid
> a bidding war between each other ;-)
> ___
> 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] (no subject)

[Matt B]

Hello,

Shifting away from the focus of [1] I'm interested in how hard it would be
to port coreboot to the AM1M-A. This board seems to be a larger version of
the supported AM1I-A and is known to officially support ECC. (the manuals
for the AM1I-A [2] and AM1M-A [3])

The porting guide at [4] is very detailed on information gathering but is
scant on details when it comes to making changes. (see "Adjusting the
contents of the new board directory")

I have the opportunity to obtain this board relatively inexpensively. What
would be the steps (after gathering information from the stock bios) for
porting coreboot to this board? What are the potential pitfalls?

Sincerely,
-Matthew Bradley

[1]
https://mail.coreboot.org/hyperkitty/list/coreboot@coreboot.org/thread/ST5QMZ6N57E4FOKHFLMGWZCDRRW6O6D4/
[2] https://dlcdnets.asus.com/pub/ASUS/mb/SocketAM1/AM1I-A/E8963_AM1I-A.pdf
[3]
https://dlcdnets.asus.com/pub/ASUS/mb/SocketAM1/AMD_SoC_APU/AM1M-A/E9004_AM1M-A.pdf
[4]
https://www.coreboot.org/Motherboard_Porting_Guide#Adjusting_the_contents_of_the_new_board_directory
___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] Re: Trying to check potential compatibility of intel server board

[Matt B]

Thanks,

Looking at the releases,
"3rd Generation Intel® Core™ processors with mobile Intel® HM76 and QM77
chipsets (formerly Chief River Platform: Ivy Bridge and Panther Point)"
seems the most probable, but I'm skeptical that the C206 is equivalent to a
HM76 or QM77.

Can anyone familiar with the FSPs speak to how likely it is that the same
FSP would support a chipset in the same family which isn't specifically
named?
Or would intel only release an FSP targeting those two chipsets likely to
be used by OEMs in the wild?

Sincerely,
-Matthew Bradley

PS. the manual for this motherboard can be found at:
https://www.intel.com/content/dam/support/us/en/documents/motherboards/server/s1200kp/sb/g38894002_s1200kp_tps_r1_1.pdf


On Sun, Sep 29, 2019 at 1:58 PM Lance Zhao  wrote:

> https://github.com/IntelFsp/FSP  that shall have all the current platform
> that FSP can supported,
>
> Matt B  于2019年9月29日周日 上午10:52写道：
>
>> Hello,
>>
>> I'm trying to check the potential compatibility of the s1200kp intel
>> server board. [1] It's mini-itx and supports ECC ram, making it attractive
>> for use in a NAS device. (cases with multiple hotswap bays and room for an
>> itx board abound, but few itx boards have ECC capability)
>>
>> The chipset is listed as the C206, which is part of cougar point. The
>> socket is FCLGA1155 and I've seen the board with an i3-3220 (3rd gen ivy
>> bridge).
>>
>> However, I'm having a really hard time finding information on whether
>> coreboot supports the chipset. (never mind the superio etc)
>>
>> It seems the compatibility list [2] on the wiki is out of date (and
>> slated for retirement) and the docs at [3] are still mostly incomplete.
>> From grepping through the source and the coreboot blog [4] there's been a
>> port (in coreboot 4.2) to at least one other cougar point platform.
>> (apple/macbookair4_2) The blog post also mentions that support for ivy
>> bridge and cougar point come from an FSP binary. There is also a coreboot
>> blog entry linking to the following article [5] discussing support for
>> these chips being merged.
>>
>> This lack of accessible documentation makes it difficult to find good
>> porting candidates for hardware of *any* generation. Are all ivy bridge
>> CPUs supported? Does the FSP binary support all cougar point chipsets?
>>
>> Sincerely,
>> -Matt
>>
>> [1]
>> https://ark.intel.com/content/www/us/en/ark/products/60637/intel-server-board-s1200kp.html
>> [2] https://www.coreboot.org/Supported_Chipsets_and_Devices
>> [3] https://doc.coreboot.org/northbridge/intel/index.html
>> [4] https://blogs.coreboot.org/blog/2015/10/30/announcing-coreboot-4-2/
>> [5] https://www.phoronix.com/scan.php?page=news_item&px=MTA4Mjg
>> ___
>> 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] Trying to check potential compatibility of intel server board

[Matt B]

Hello,

I'm trying to check the potential compatibility of the s1200kp intel server
board. [1] It's mini-itx and supports ECC ram, making it attractive for use
in a NAS device. (cases with multiple hotswap bays and room for an itx
board abound, but few itx boards have ECC capability)

The chipset is listed as the C206, which is part of cougar point. The
socket is FCLGA1155 and I've seen the board with an i3-3220 (3rd gen ivy
bridge).

However, I'm having a really hard time finding information on whether
coreboot supports the chipset. (never mind the superio etc)

It seems the compatibility list [2] on the wiki is out of date (and slated
for retirement) and the docs at [3] are still mostly incomplete. From
grepping through the source and the coreboot blog [4] there's been a port
(in coreboot 4.2) to at least one other cougar point platform.
(apple/macbookair4_2) The blog post also mentions that support for ivy
bridge and cougar point come from an FSP binary. There is also a coreboot
blog entry linking to the following article [5] discussing support for
these chips being merged.

This lack of accessible documentation makes it difficult to find good
porting candidates for hardware of *any* generation. Are all ivy bridge
CPUs supported? Does the FSP binary support all cougar point chipsets?

Sincerely,
-Matt

[1]
https://ark.intel.com/content/www/us/en/ark/products/60637/intel-server-board-s1200kp.html
[2] https://www.coreboot.org/Supported_Chipsets_and_Devices
[3] https://doc.coreboot.org/northbridge/intel/index.html
[4] https://blogs.coreboot.org/blog/2015/10/30/announcing-coreboot-4-2/
[5] https://www.phoronix.com/scan.php?page=news_item&px=MTA4Mjg
___
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

[Matt B]

Hello,

Kyösti Mälkki said,

> ECC signals between DIMM sockets and AM3 are not routed in AM1I-A
> boardview files I found, while they are in AM1M-A boardview.
>
Are you able to link to these boardviews?

If ECC will not work on the AM1I-A but is known to work on the AM1M-A, and
the boards are very similar, what would the steps look like for porting
from one to another? The guide at [1] is very detailed about information
gathering, but is scant on details about virtually everything else. (not to
mention, does inteltool etc. even work on AMD boards?)

Thanks,
-Matt

[1] https://www.coreboot.org/Motherboard_Porting_Guide

On Thu, Sep 26, 2019 at 6:29 AM Alberto Bursi 
wrote:

> Unbuffered and/or NOT registered.
>
> The buffered/registered is cheaper on ebay, and also higher density (up to
> 32GB or 64GB per DDR3 DIMM) so it could look like a bargain but it isn't.
>
> It's cheaper because you can't use it on most consumer hardware.
>
> AMD hardware that supports buffered and/or Registered ECC is Threadripper
> or server processors (Opteron, Epyc).
>
> Similar for Intel, only server-grade Xeons and Enthusiast i7 processors
> (Socket 2xxx or something) support that.
>
> Buffered/Registered RAM exists for servers that need to use large amounts
> of RAM, hundreds of GB or even a TB or more (for multi-CPU systems).
>
> -Alberto
> On 26/09/19 03:34, 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.
>
> Sincerely,
> -Matt
>
>
> On Mon, Sep 23, 2019 at 8:06 PM Matt B  wrote:
>
>> Hello,
>>
>> That has short but very informative indeed. Thank you. :)
>>
>> Even if the pinout is the same, is it possible that some connections have
>> been left disconnected or components unpopulated on the board, which would
>> prevent ECC from working?
>>
>> As a more general porting question, what steps should be taken in porting
>> coreboot to the larger board (the 'M' variant) to avoid unpleasant
>> consequences?
>>
>> I would think the PCI layout would be different (obvious, since one board
>> has more slots then the other) but what should not be assumed to be the
>> same?
>>
>> Thanks,
>> -Matt
>>
>
> ___
> coreboot mailing list -- coreboot@coreboot.org
> To unsubscribe send an email to coreboot-le...@coreboot.org
>
> ___
> coreboot mailing list -- coreboot@coreboot.org
> To unsubscribe send an email to coreboot-le...@coreboot.org
>
___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

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

[Matt B]

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.

Sincerely,
-Matt


On Mon, Sep 23, 2019 at 8:06 PM Matt B  wrote:

> Hello,
>
> That has short but very informative indeed. Thank you. :)
>
> Even if the pinout is the same, is it possible that some connections have
> been left disconnected or components unpopulated on the board, which would
> prevent ECC from working?
>
> As a more general porting question, what steps should be taken in porting
> coreboot to the larger board (the 'M' variant) to avoid unpleasant
> consequences?
>
> I would think the PCI layout would be different (obvious, since one board
> has more slots then the other) but what should not be assumed to be the
> same?
>
> Thanks,
> -Matt
>
___
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

[Matt B]

Hello,

That has short but very informative indeed. Thank you. :)

Even if the pinout is the same, is it possible that some connections have
been left disconnected or components unpopulated on the board, which would
prevent ECC from working?

As a more general porting question, what steps should be taken in porting
coreboot to the larger board (the 'M' variant) to avoid unpleasant
consequences?

I would think the PCI layout would be different (obvious, since one board
has more slots then the other) but what should not be assumed to be the
same?

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

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

[Matt B]

Greetings,

The AM1I-A [1] is supported by Coreboot, while the AM1M-A [2] is not. The
latter seems to be a larger version of the first, with more
expansion options.

For the smaller 'I' not much is stated in the manual [3] except to check
the "qualified vendor list" on ASUS' site. It does list sizes for
unbuffered, non-ecc memory though. I've also read from people testing it
that the board doesn't post with ECC installed under the proprietary bios.

According to the manual [4], the larger board ('M') supports unbuffered ECC
(and only ECC?) and from what I've read ECC error injection works as
expected in memtest86.

What is the probability that ECC will work with the 'I' under Coreboot? (I
would expect not much if it's not wired for it, but I don't know how
similar these boards are)

How hard would it be to port Coreboot from the 'I' to the larger 'M"? What
steps would be required? (was previously mentioned breifly in [5])

Sincerely,
-Matt

[1] https://www.asus.com/us/Motherboards/AM1IA/
[2] https://www.asus.com/us/Motherboards/AM1MA/
[3] https://dlcdnets.asus.com/pub/ASUS/mb/SocketAM1/AM1I-A/E8963_AM1I-A.pdf
[4]
https://dlcdnets.asus.com/pub/ASUS/mb/SocketAM1/AMD_SoC_APU/AM1M-A/E9004_AM1M-A.pdf
[5] https://mail.coreboot.org/pipermail/coreboot/2018-February/086145.html
___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

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

[Matt B]

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

I plan on using this board myself for a small NAS system.

-Matt

[1] https://www.phoronix.com/scan.php?page=news_item&px=ASUS-AM1I-A-Coreboot
https://source.puri.sm/coreboot/coreboot/commit/3dce9f09d9e26b147153ad0cda493ecb4b6d15d8
https://github.com/coreboot/coreboot/commits/master/src/mainboard/asus/am1i-a
[2] https://www.coreboot.org/Board:asus/am1i-a

On Fri, Sep 20, 2019 at 4:00 AM Kyösti Mälkki 
wrote:

> 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 mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

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

[Matt B]

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?

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?

Sincerely,
-Matthew Bradley

On Wed, Sep 18, 2019 at 6:25 PM Kyösti Mälkki 
wrote:

> 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 mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] Re: KGPE-D16 maintainership

[Matt B]

Hello,

I'd be happy to kick more than a few bucks towards hardware or other costs.
Just need to know where to send it.

I'll also drop a post over on r/Libreboot.

Sincerely,
-Matt

On Tue, Sep 17, 2019 at 1:33 PM Timothy Pearson <
tpear...@raptorengineering.com> wrote:

> I'd be happy to assist as well with hardware.  I have a spare fully
> functional KGPE-D16 with dual CPUs that can be donated to a US-side
> developer interested in keeping the native init alive, working, and
> in-tree.  If enough functionality can be restored in coreboot master I can
> also reactivate the REACTS autotest for it -- it was shut off a long time
> ago due to coreboot master no longer reliably booting on the hardware, but
> remains mothballed for potential reactivation.
>
> The hardware is definitely showing its age, it's slow, power hungry, uses
> an ancient and very limited BMC (if you can get the module for it), and
> still requires AMD microcode binaries, but it's still the fastest open
> (sans microcode) x86 platform available anywhere.
>
> I've also got a stack of KFSN4-DRE boards (K8 era), but the K8 support was
> ripped out a while back IIRC.  I can send these to good homes as well if
> there's interest. :)
>
> Thanks!
>
> - Original Message -
> > From: "Vikings GmbH" 
> > To: "Piotr Król" , insu...@riseup.net
> > Cc: "coreboot" , "Timothy Pearson" <
> tpear...@raptorengineering.com>, "Andrew Luke Nesbit"
> > 
> > Sent: Tuesday, September 17, 2019 4:50:35 AM
> > Subject: Re: KGPE-D16 maintainership
>
> > Hello,
> >
> > On Tue, 17 Sep 2019 11:19:42 +0200
> > Piotr Król  wrote:
> >> -BEGIN PGP SIGNED MESSAGE-
> >> Hash: SHA512
> >>
> >> Hi all,
> >> we see a lot of attention around KGPE-D16 maintainership problems.
> >> After discussion with Thierry Laurion (Insurgo) at OSFC2019 3mdeb
> >> decided to help in maintaining that platform by organizing crowd
> >> founding campaign or getting founds in other ways (direct sponsors).
> >>
> >> Since we are based in Poland there is chance that even with small
> >> contribution from community we would be able to cover the costs.
> >>
> >> Ideal plan would be to have structure similar to what we maintain for
> >> PC Engines:
> >> https://pcengines.github.io/
> >> Where we providing signed and reproducible binaries every month and
> >> keep as close to mainline as possible. Of course if development will
> >> be active, then there always would be delta of patches held in review.
> >>
> >> Unfortunately we don't have hardware. During OSFC 2019 Stefan left one
> >> board, but it was too late (and probably too expensive) for us to
> >> organize any shipment to Poland. We looking to have 2 mainboards one
> >> for development and one in our automated regression testing
> >> environment. Of course we will start even with just one.
> >
> > I would be pleased if Vikings could help out by sending two KGPE-D16
> > systems for this purpose. You can contact me at this address for
> > details.
> >
> > Perhaps someone in CC will also be able to help out one way or the
> > other.
> >
> >> If anyone is willing to help in founding, sponsoring hardware or by
> >> code development and testing we would be very grateful.
> >>
> >> Please copy other people and share this post wherever is necessary to
> >> keep this platform alive. Positive feedback will help things rolling.
> >>
> >> Best Regards,
> >> - --
> >> Piotr Król
> >> Embedded Systems Consultant
> >> GPG: B2EE71E967AA9E4C
> >> https://3mdeb.com | @3mdeb_com
> >> -BEGIN PGP SIGNATURE-
> >>
> >> iQIzBAEBCgAdFiEE4DCbLYWmfoRjKeNLsu5x6WeqnkwFAl2ApSoACgkQsu5x6Weq
> >> nkw0XQ//WeO+U6VFcr6wsfCkv5qXnKVHb6XDXyEknhu7Q82HZ9Hx+0IiZ0+ikzVZ
> >> oLU36euPwlHoRFh3HPm34DHeeYAZYzzsdc41+0MZJao152CGZJQwe+pqD/JeymOU
> >> Jky+PhULeGKXt22ftbxte1ac82tRDFt//0Yc07qxP9G/CboZ8sjckKjfyfoy5PFm
> >> 9jRFwdZUMbU42mU+NYLn/iXGWM/+mxC+ghncQBYwwGX1npr1r5gSiZS9ImoHFpgj
> >> DQaaUQq2v8vS1uvYZ84vVEXeOljTkzFg7UyUZq3sSob8bA/a42rsgFMPVI6Bpc5R
> >> lAEdhBZgMaD4jjO2GK+3zFSy32pBvK71tzwrdLjhb/bjjN1phHy2zbwTebFWlyiu
> >> HQJ/+iu4uoTQj69GT9i7HLyngorh37GWFHKScDDzEASnSO868ELhlrt+yHwyY284
> >> EAe7dTOhOtfdxJOKcfdyUez5nwPZON4AXEVSvLWLUv4r+f82CG89f+LLg7rbZH5n
> >> C0HnUOJas89xEvRhXChTBHnM9NBKSWpch5uZ5SbZHb/JCWBb26yT6Ua46H0STFRh
> >> y+pWHc8AN76FQnWvpYer5F3hyVEX1+wAsi+RJMROFUejCn3lCl5ogAnT4ZRCqzo3
> >> 61Ao6dYmtYhaQ3JjZ+5bv3926ZwRjvr7i5t9bHf9THXCn1UobjY=
> >> =wYUt
> >> -END PGP SIGNATURE-
> >
> >
> >
> >
> > --
> > Best regards/Mit freundlichen Grüßen/Cordialement/Met vriendelijke groet
> > Thomas Umbach
> >
> > Web: https://www.vikings.net/
> > Phone: +49 69 247 54 91 0
> >
> > Follow us on GNUsocial: https://quitter.se/vikings
> > Follow us on Twitter: https://twitter.com/vikingslibre
> >
> > Vikings GmbH
> > Sauerackerweg 14, 60529 Frankfurt/Main, Germany
> > Register Court: AG Frankfurt am Main
> > Register No.: HR B 84497, CEO: Thomas Umbach
> > Tax Office: Frankfurt am Main, VATIN: DE254094338
> >
> > GPG key fingerprint: FD5E 2543 EE62 7395 00A6 9FBB F22

[coreboot] Re: TPM measurements with UefiPayloadPkg EDK2

[Matt B]

Hello,

Are there any up-to-date references you're aware of, for those interested?

-Matt

On Fri, Sep 13, 2019 at 8:44 AM Michal Zygowski 
wrote:

> Thank you for response. I already got that working actually yesterdays
> evening :)
>
> If you mean the white paper A Tour Beyond BIOS with the UEFI TPM2
> Support in EDKII and the wiki on GitHub, I have also encountered these
> guides. They have removed TrEE protocol and rewritten whole TCG2 stack.
> So most of the guidelines in this white paper are useless unfortunately.
>
> Some modifications to included libraries and components in DSC and few
> INFs in FDF. At last few PCD fixes and done.
>
> Regards,
>
> On 13.09.2019 02:33, benjamin.doro...@gmail.com wrote:
> > I remember seeing a guide on Tianocore's wiki on GitHub that I was
> meaning to follow after porting coreboot to my laptop. From memory, it's a
> matter of adding some "includes" to the package you plan to build.
> Hopefully isn't much more than that.
> > ___
> > 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 mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

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

[Matt B]

Greetings all,

Patrick gregori said:

> Mostly chatter on IRC, to be honest. Part of the intent of this mail was
> to surface this more officially.
>
It would be helpful to carry over more details when porting discussions
from IRC. It is always good to be specific how something is broken, not
just that the garbage collector is coming.

Kyösti said:

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

This is one way of handling it, but I don't think it does anything to
address the quality of the code. Out of sight and out of mind, so to speak.

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 Ron noted:

> We kept it relatively the same when AMD was a player in coreboot, but
> they're long gone; time for major surgery?

I assume that AMD probably doesn't have any plans to revisit 15h if/when
they follow through on porting 17h? :-)

Patrik said:

> This was about surfacing issues like these earlier, to reduce the amount
> of surprise. Having your status update on the C bootblock and CAR migration
> implementation is useful for that, too!
>
Is there a single point of reference for this kind of information, to avoid
surprises?

Ron said:

> Is this statement true?
> "There is no source so bad that a binary blob is better"
>
Unless this is the trivial case where the blob boots and the code doesn't
(or is otherwise functionally inferior), I would argue that any code can be
compiled into a blob.
Thus, the code is automatically as-good-or-better. :-)

If we take that to be true, then what about this:
> "bad source should never be replaced by a blob, but only by better source"

This is where things begin to come apart. The first part is true based on
(1) but unless someone writes better source, eventually the code breaks and
you enter the trivial case above.

"we must never remove source that is in use if the only replacement is a
> blob"
>
If the code works (it is in use after all), then refer to (1). Otherwise,
this is the trivial case.

Once you find yourself in the trivial case, you need to make the decision
to either fix the broken code, or embrace the blob.

Sincerely,
-Matt

On Thu, Sep 12, 2019 at 1:36 PM ron minnich  wrote:

> Interesting discussion! It got me to wondering, having spent a lot of
> time in the V1, V2, and V3 trees the last few months.
>
> Is this statement true?
> "There is no source so bad that a binary blob is better"
>
> If we take that to be true, then what about this:
> "bad source should never be replaced by a blob, but only by better source"
>
> From there:
> "we must never remove source that is in use if the only replacement is a
> blob"
>
> Would that help guide the decision on AGESA? Or is it just more
> bikeshedding :-)
>
> I personally find the AgEsA cOdE quite UgLy, but ... it's code. I
> wonder if it can't be fixed with a few
> initial spatch passes. We kept it relatively the same when AMD was a
> player in coreboot, but they're long
> gone; time for major surgery?
>
> I don't think we want to say "ugly code, nuke it" unless there is
> replacement that is code.
>
> ron
>
>
>
> On Thu, Sep 12, 2019 at 9:46 AM awokd via coreboot
>  wrote:
> >
> > Patrick Georgi via coreboot:
> > > 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.
> > >
> > > 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.
> > >
> > > 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
> >
> > I would like to help out. Is there someone experienced who can mentor me
> > on setting up a streamlined, open-source development environment for
> > Coreboot? I've been using grep and gedit for my hacking needs, but
> > trying to maintain a 5 level deep state table of AGESA code dependencies
> > in my head was a problem. How did Jacob get started and what IDE did he
> > use, for example?
> >
> > > 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.
> >
> > Which drivers and what support? I see Kyösti Mälkki replied with better
> > questions. Where is the biggest pain point today, i.e. not already being
> > worked on and 

[coreboot] Fwd: Re: Web site revamp

[Matt B]

-- Forwarded message -
From: Matt B 
Date: Tue, Sep 3, 2019 at 1:05 AM
Subject: Re: [coreboot] Re: Web site revamp
To: David Hendricks 


Building on that, postmarketOS (which in some ways feels like a weird
sister project to coreboot?) does this thing where they display 3 random
supported phones on the homepage every time it loads. Doing that with
supported boards, with some feature bullet-points underneath might look
real spiffy.

-Matt

On Mon, Sep 2, 2019 at 9:13 PM David Hendricks 
wrote:

> It would be nice if we can more prominently show libre-friendly systems
> with coreboot. There have been some ideas proposed about how to do this,
> for example this one by Carl-Daniel:
> https://mail.coreboot.org/pipermail/coreboot/2010-October/060894.html
>
> Now that our infrastructure is much better than it was nearly a decade
> ago, maybe we can reconsider some ideas that would have previously involved
> a lot of tedious manual labor. For example, perhaps a matrix of boards and
> blob dependencies can be auto-generated using `make what-jenkins-does` (or
> something similar) and looking at the resulting .config file for each
> board. From there, boards with no blob dependencies (at least no
> 3rdparty/{blobs,fsp} dependencies) can be put on a list of "libre
> platforms" linked from the homepage.
>
> Just thinking out loud...
> ___
> 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: Web site revamp

[Matt B]

>
> Where I take issue still is that we're nowhere near 100%.  On modern
> platforms we're somewhere below 50% and oftentimes well below that.  The
> wording is confusing and misleading as-is. ... What is to be gained by
> hiding the reality of the situation from non-technical users visiting the
> website?
>
While I think this is true, it raises another question:

Users can expect a linux live CD to work, but flashing coreboot carries
risk of creating a brick. It's a process which for beginners isn't
inaccessible but does require a lot of research. What are the anticipated
characteristics of the various audiences who visit the site?

To take an extreme stance, could non-technical users one day be directed to
coreboot distributions like Librecore or vendors like Purism/System76?

-Matt

On Sat, Aug 31, 2019 at 8:23 PM Timothy Pearson <
tpear...@raptorengineering.com> wrote:

>
>
> - Original Message -
> > From: "David Hendricks" 
> > To: "Timothy Pearson" 
> > Cc: "coreboot" 
> > Sent: Saturday, August 31, 2019 7:08:55 PM
> > Subject: Re: [coreboot] Web site revamp
>
> >> If people are not aware of the ME, PSP, AGESA, FSP, BinaryPI, and a host
> >> of other proprietary components, they naturally take the statements
> above
> >> at face value and assume that installing coreboot on their machine (or
> >> paying for coreboot support for their system) allows them to replace the
> >> entire proprietary firmware with an auditable, fast, secure OpenSource
> >> firmware.
> >>
> >
> > If people are confusing coreboot with ME, PSP, AGESA, FSP, BinaryPI, etc.
> > then that is indeed a problem.
> >
> >
> >> One of the problems as I see it is that coreboot is really two different
> >> projects with two different goals right now, under the same label.  One
> is
> >> the native init project, which at the moment is only viable for RISC-V,
> >> POWER, and certain ARM SoCs.  The other is the open glue project for
> vendor
> >> binaries, which is not well understood at this time among much of the
> open
> >> source community, but seems to have significant support from vendors
> like
> >> Google, Intel, and AMD.
> >>
> >
> > I don't see the latter as a project goal, it's just something that
> enables
> > coreboot to be used in non-libre platforms.
>
> I think you've touched on the heart of the problem here.  What exactly
> does "using coreboot" mean?  As an analogy, if I use WSL (which exposes
> Linux-like interfaces but is actually a proprietary NT kernel under the
> hood) am I really "using Linux"?  To purposefully go to an extreme, if a
> vendor comes up with 128MB of proprietary firmware that calls ~10 lines of
> coreboot code in the end to handoff to an OS, is that "using coreboot"?
>
> From a business perspective I see severe trademark dilution in an attempt
> to cater to non-libre platforms.  Is this the direction we want to go?
> From our side at Raptor, if coreboot becomes synonymous with proprietary
> firmware / glue, we'd need to seriously reconsider our promotion /
> association given our focus on fully open / owner controlled computing
> (note this is not intended as a threat in any way, I'm simply trying to
> highlight that going to one extreme to capture x86 platforms as "coreboot"
> may make coreboot itself unattractive for open platform vendors).
>
> >
> >> Complicating matters, the trademark "coreboot" is currently known to
> some
> >> members of the public as a trusted (albeit limited in compatibility)
> fully
> >> open source replacement for their exiting board level firmware.  When
> the
> >> word "coreboot" is used, very few people think of the glue project.  Do
> we
> >> want to dilute / shift the coreboot trademark / branding to the glue
> part
> >> of the project, or do we want to somehow reserve "coreboot" for the
> native
> >> init part of the project?
> >>
> >
> > Similar points have been made about Linux supporting binary modules. I'm
> > not convinced that conflating the project's openness with that of
> > third-party modules is helpful.
>
> From where I sit, Linux can get away with it because the ratio of open
> code to binary modules is so high, and has remained extremely high with no
> indication of significant change.  I'd argue that this hard-to-reach goal
> being attained for so long is reflective of excellent leadership from Linus
> and the other folks in charge of Linux.
>
> > The heading could read something like "Flexible, open source frameworks
> for
> >> system firmware"
> >>
> >> and the detailed description could read "coreboot is an extensible
> >> firmware platform that aims to provide a minimal boot environment for
> >> modern computers and embedded systems.  As an Open Source project it
> >> provides a flexible framework for insertion of vendor specific firmware
> >> modules, and on open ISA platforms aims to provide a fully open,
> auditable
> >> boot process with maximum control over the technology."
> >>
> >
> > Adding the word "framework" somewhere in there could be u

[coreboot] Re: Web site revamp

[Matt B]

Hello,

This seems to be a fairly accurate assessment of the situation, imo.

It's disappointing to see people shocked by inclusion of binary components
and left with a very negative impression. I've seen coreboot particularly
derided by people who first learn about libreboot from the FSF and arrive
with high expectations. Perhaps acknowledging the split and that right now
x86 is a best effort in bad situation can help with this.

This both points out the platforms which are "fully free" and manages
expectations upfront with other architectures. POWER systems that exist
like the Talos II and any future openPOWER implementations are arguably far
more "free" than anything on the RYF list (every thinkpad runs proprietary
EC firmware, including the X220), and may be very appealing to those
looking for a "maximum freedom" solution. The only other thing to do is be
specific about what firmware modules are included in various other
platforms and provide information needed to make an informed decision for a
given threat model.

As Patrick Georgi noted:

> FSP is a mixed bag in that it enabled going on with contemporary hardware
> but also seemed to have killed all motivation to reverse engineer chipset
> bringup - or maybe that's due to the omnipresent ME...

I think acknowledging the split may also generate interest in improving
this situation. It's great if it prompts people to investigate proprietary
components or pressure their vendors for better documentation.

A nitpick: Perhaps

> As an Open Source project it provides a flexible framework for integration
> of necessary vendor-specific firmware modules, and...
>
instead of

> As an Open Source project it provides a flexible framework for insertion
> of vendor specific firmware modules, and...

is more specific?

I not sure about naming. There was mention a while back of Oreboot, but not
everything fully open source is also C-free.
Which one of the two would be coreboot-lite? :P

Sincerely,
-Matt


On Sat, Aug 31, 2019 at 5:54 PM Timothy Pearson <
tpear...@raptorengineering.com> wrote:

> I'd like to open discussion on a revamp of the text on the main
> coreboot.org Web site.  I had a brief discussion on IRC recently with
> some basic agreement from a couple of people that the text on that page has
> likely bitrotted enough compared to the current status and goals of
> coreboot to no longer be useful.
>
> I bring this up due to confusion in less technical circles that I've been
> having to correct over the past week or so.  Specifically, these statements
> taken in isolation:
>
> "Fast, secure and flexible OpenSource firmware"
>
> "coreboot is an extended firmware platform that delivers a lightning fast
> and secure boot experience on modern computers and embedded systems. As an
> Open Source project it provides auditability and maximum control over
> technology."
>
> present a very different picture than the reality of the project at the
> moment for modern platforms.  If people are not aware of the ME, PSP,
> AGESA, FSP, BinaryPI, and a host of other proprietary components, they
> naturally take the statements above at face value and assume that
> installing coreboot on their machine (or paying for coreboot support for
> their system) allows them to replace the entire proprietary firmware with
> an auditable, fast, secure OpenSource firmware.  As those of us dealing
> with the reality of modern x86 and ARM platforms understand more fully,
> this could not be farther from the truth.
>
> One of the problems as I see it is that coreboot is really two different
> projects with two different goals right now, under the same label.  One is
> the native init project, which at the moment is only viable for RISC-V,
> POWER, and certain ARM SoCs.  The other is the open glue project for vendor
> binaries, which is not well understood at this time among much of the open
> source community, but seems to have significant support from vendors like
> Google, Intel, and AMD.
>
> Complicating matters, the trademark "coreboot" is currently known to some
> members of the public as a trusted (albeit limited in compatibility) fully
> open source replacement for their exiting board level firmware.  When the
> word "coreboot" is used, very few people think of the glue project.  Do we
> want to dilute / shift the coreboot trademark / branding to the glue part
> of the project, or do we want to somehow reserve "coreboot" for the native
> init part of the project?  I don't have an answer here, I'm just trying to
> state the facts as I currently see them for further discussion.
>
> I would propose the following changes, and welcome discussion on these
> topics:
>
> The heading could read something like "Flexible, open source frameworks
> for system firmware"
>
> and the detailed description could read "coreboot is an extensible
> firmware platform that aims to provide a minimal boot environment for
> modern computers and embedded systems.  As an Open Source project it
> provides a 

[coreboot] Re: Chainloading Windows from a Linux Payload

[Matt B]

Hello,

Just adding some information that might be useful to others who find
themselves in a similar position:

ReactOS (open source widows re-implementation) has a bootloader called
freeloader which is capable of loading all sorts of windows and
windows-like operating systems. It can even do funny things like boot
windows server 2003 from a btrfs or ext2/3 partition.

Freeloader can be loaded by grub as a multiboot-compatible kernel, with
instructions here:
https://reactos.org/wiki/Boot_FreeLoader_from_GRUB

I would expect it to also be possible to chainload it from linux using
kexec, making it possible to boot windows from within linuxboot-based
payloads.

Sincerely,
-Matthew Bradley

On Wed, Jun 12, 2019 at 11:55 PM Matt B  wrote:

> Hi,
>
>
>> I think SeaBIOS already has an option to build a multiboot image. In
>> either case you could also (in theory) pack either into a bzImage and
>> feed that to kexec.
>>
>
> Clearly this is one place I should look next. I was mainly looking at grub
> as I understood it to be the most capable among payloads, though not
> necessarily the most streamlined.
>
> Just for the sake of completeness, can grub be packed into a compatible
> multiboot image? I can only find information on grub loading them.
>
> I wonder why you would want to chainload grub, however, instead of
>> using u-root programs that read grub config files and do the boot
>> directly?
>>
>
> My impression is things that try to parse grub config files (or similar)
> tend to implement only partial compatibility and be a bit buggy. I also
> couldn't find any clear documentation on this.
>
> There are reasons to use grub, of course, but I was curious
>> about your specific reason.
>>
>
> From what I've read grub has the best support among payloads for things
> like loading or verifying encrypted partitions, while also being able to
> load a wide variety of media (from live CDs to windows loaders). The
> general outline was to have linuxboot come up first and do all of the boot
> logic and other tasks in a nice linux environment, then invoke grub to take
> the appropriate final action. I still don't know if seabios can boot
> something on an encrypted partition, even if the linux runtime that's
> loading seabios is capable of mounting it.
>
> One of many ideas I'm fiddling with is to implement functionality that
> coreboot lacks compared to most proprietary BIOSs (self flashing,
> configuration, and other goodies) using fairly normal scripts under linux.
> If linuxboot can provide a great deal of flexibility, this is one way I can
> imagine using it.
>
> windows 12
>
>
> What?
>
> Sincerely,
> -Matt
>
> On Wed, Jun 12, 2019 at 4:26 AM Mike Banon  wrote:
>
>> At least Windows 10 supports the Legacy BIOS, and most likely 12 will
>> too. As long as they are making a 32-bit version of Windows they're
>> still caring about the "legacy" PCs and we shouldn't be worried. Also,
>> it's hard to imagine a coreboot'er who would be running 12 natively -
>> not inside some virtual machine.
>>
>> On Wed, Jun 12, 2019 at 2:38 AM Gregg Levine 
>> wrote:
>> >
>> > Hello!
>> > (Incidentally all of you are getting this because Google Mail delights
>> > in sending things out as reply-all.)
>> > I'm currently an observer in this set of circumstances but as it
>> > happens Stefan you are very right. My older laptop used a BIOS that
>> > was more suited to an earlier and even uglier release of Windows(!)
>> > and this one is using EFI and behaves strangely  sometimes.
>> >
>> > Oh and I was able to run Windows 8 and Windows 8.1 for a while on the
>> > older one. Slowly of course but those versions ran.
>> >
>> > Let's see what does work..
>> > -
>> > Gregg C Levine gregg.drw...@gmail.com
>> > "This signature fought the Time Wars, time and again."
>> >
>> > On Tue, Jun 11, 2019 at 6:53 PM Stefan Reinauer
>> >  wrote:
>> > >
>> > > * ron minnich  [190611 07:13]:
>> > > > if you boot windows 12 would you need tianocore?
>> > >
>> > > Need is a harsh word, but the simple answer to a simple question is
>> yes,
>> > > you do.
>> > >
>> > > You can use SeaBIOS, but Windows does not officially support legacy
>> BIOS
>> > > since at least Windows 7, so whatever works today might stop working
>> > > tomorrow.
>> > >
>> > > >
>> > > > On Mon, Jun 10, 2019 at 1:44 PM Nico Hube

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

[Matt B]

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


> 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?)

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.

Sincerely,
-Matthew Bradley

On Wed, Aug 21, 2019 at 1:28 PM Kyösti Mälkki 
wrote:

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

[Matt B]

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?

Sincerely,
-Matthew Bradley

On Thu, Aug 15, 2019 at 11:50 AM Kyösti Mälkki 
wrote:

> 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 mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] Related: General NERF Install Procedure?

[Matt B]

Hello,

A couple of years ago I saw Ron's talk on NERF. An acquaintance who
maintains a fleet of machines expressed some interest in NERF. He wants to
boot linux instead of windows, which isn't supported by his (extremely
recent) build of UEFI. (no legacy support whatsoever)

The closest thing I could find to instructions for using it or otherwise
replicating what's been done is the explanation for the Dell R630 here: [1]
Many sections are still TODO and it overall seems fairly half-baked (with
things like USB and networking not working).

I surmise the basic steps are:
-Dump the BIOS flash
-Extract key boot blobs from flash
-Configure and build NERF
-Flash resulting image

Has any progress been made (public) since 2017? Does a generalized install
process exist (like that provided by me_cleaner, for example) or is this
something that requires a large amount of rework for each platform?

I imagine it is totally impossible to produce anything that would be
accepted by stock UEFI as an update for internal flashing.

Sincerely,
-Matthew Bradley

[1] https://trmm.net/NERF
___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] Re: Chainloading Windows from a Linux Payload

[Matt B]

Hi,


> I think SeaBIOS already has an option to build a multiboot image. In
> either case you could also (in theory) pack either into a bzImage and
> feed that to kexec.
>

Clearly this is one place I should look next. I was mainly looking at grub
as I understood it to be the most capable among payloads, though not
necessarily the most streamlined.

Just for the sake of completeness, can grub be packed into a compatible
multiboot image? I can only find information on grub loading them.

I wonder why you would want to chainload grub, however, instead of
> using u-root programs that read grub config files and do the boot
> directly?
>

My impression is things that try to parse grub config files (or similar)
tend to implement only partial compatibility and be a bit buggy. I also
couldn't find any clear documentation on this.

There are reasons to use grub, of course, but I was curious
> about your specific reason.
>

>From what I've read grub has the best support among payloads for things
like loading or verifying encrypted partitions, while also being able to
load a wide variety of media (from live CDs to windows loaders). The
general outline was to have linuxboot come up first and do all of the boot
logic and other tasks in a nice linux environment, then invoke grub to take
the appropriate final action. I still don't know if seabios can boot
something on an encrypted partition, even if the linux runtime that's
loading seabios is capable of mounting it.

One of many ideas I'm fiddling with is to implement functionality that
coreboot lacks compared to most proprietary BIOSs (self flashing,
configuration, and other goodies) using fairly normal scripts under linux.
If linuxboot can provide a great deal of flexibility, this is one way I can
imagine using it.

windows 12


What?

Sincerely,
-Matt

On Wed, Jun 12, 2019 at 4:26 AM Mike Banon  wrote:

> At least Windows 10 supports the Legacy BIOS, and most likely 12 will
> too. As long as they are making a 32-bit version of Windows they're
> still caring about the "legacy" PCs and we shouldn't be worried. Also,
> it's hard to imagine a coreboot'er who would be running 12 natively -
> not inside some virtual machine.
>
> On Wed, Jun 12, 2019 at 2:38 AM Gregg Levine 
> wrote:
> >
> > Hello!
> > (Incidentally all of you are getting this because Google Mail delights
> > in sending things out as reply-all.)
> > I'm currently an observer in this set of circumstances but as it
> > happens Stefan you are very right. My older laptop used a BIOS that
> > was more suited to an earlier and even uglier release of Windows(!)
> > and this one is using EFI and behaves strangely  sometimes.
> >
> > Oh and I was able to run Windows 8 and Windows 8.1 for a while on the
> > older one. Slowly of course but those versions ran.
> >
> > Let's see what does work..
> > -
> > Gregg C Levine gregg.drw...@gmail.com
> > "This signature fought the Time Wars, time and again."
> >
> > On Tue, Jun 11, 2019 at 6:53 PM Stefan Reinauer
> >  wrote:
> > >
> > > * ron minnich  [190611 07:13]:
> > > > if you boot windows 12 would you need tianocore?
> > >
> > > Need is a harsh word, but the simple answer to a simple question is
> yes,
> > > you do.
> > >
> > > You can use SeaBIOS, but Windows does not officially support legacy
> BIOS
> > > since at least Windows 7, so whatever works today might stop working
> > > tomorrow.
> > >
> > > >
> > > > On Mon, Jun 10, 2019 at 1:44 PM Nico Huber  wrote:
> > > > >
> > > > > On 09.06.19 20:53, Matt B wrote:
> > > > > > It is possible through u-root support for multiboot images [1]
> to chainload
> > > > > > grub?
> > > > >
> > > > > Yes, I would think so. But in case we are still on topic: It won't
> > > > > help you to boot Windows (unless you also implement UEFI services
> > > > > in your LinuxBoot and use a UEFI GRUB).
> > > > >
> > > > > To chainload something for Windows I would currently go either one
> of
> > > > > these ways:
> > > > >
> > > > > coreboot -> LinuxBoot -> SeaBIOS   -> Windows loader
> > > > > coreboot -> LinuxBoot -> tianocore -> Windows loader
> > > > >
> > > > > I think SeaBIOS already has an option to build a multiboot image.
> In
> > > > > either case you could also (in theory) pack either into a bzImage
> and
> > > > > feed that to kexec.
> > > > >
> > > > > Nico
> > ___
> > 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: Chainloading Windows from a Linux Payload

[Matt B]

Hi,

It is possible through u-root support for multiboot images [1] to chainload
grub?

-Matt

[1] https://godoc.org/github.com/u-root/u-root/pkg/boot#MultibootImage

On Sat, Apr 13, 2019 at 2:48 PM ron minnich  wrote:

> Esxi works today freebsd is coming and windows is in Long term thinking
>
> On Fri, Apr 12, 2019, 11:46 AM Rafael Send 
> wrote:
>
>> Good question, I'd be interested in the answer to this as well if anyone
>> has some insight.
>>
>> Cheers,
>> R
>>
>> On Fri, Apr 12, 2019 at 7:45 AM Matt B 
>> wrote:
>>
>>> Greetings,
>>>
>>> From what I can find, Linux can only chainload another linux kernel.
>>> (via kexec) Does this mean that a Linux payload like LinuxBoot cannot be
>>> used to boot Windows or another OS, either directly or by chainloading
>>> another payload from CBFS?
>>>
>>> It's nice that a Linux payload can provide superior flexibility and
>>> configurability than UEFI with the added benefit of a battle-hardened
>>> environment, but the ability to only boot a Linux OS seems like a pretty
>>> significant limitation (if this is indeed the case).
>>>
>>> Sincerely,
>>> -Matt
>>> ___
>>> coreboot mailing list -- coreboot@coreboot.org
>>> To unsubscribe send an email to coreboot-le...@coreboot.org
>>>
>> ___
>> coreboot mailing list -- coreboot@coreboot.org
>> To unsubscribe send an email to coreboot-le...@coreboot.org
>>
>
___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] How would an open source vgabios work?

[Matt B]

Hello,

This is perhaps naive, but it's a question that I've been thinking about
for a while.

Pretty much all AMD GPUs (both integrated and otherwise, including PCIe
cards) rely on vgabios blobs for init and to support the driver(s).

>From what I've heard, the people writing open source drivers for these GPUs
really don't want to deal with the init and modesetting, ect. Does this
mean it's more practical to try to make open source versions than to try to
eliminate their use outright?

If that's the case, it seems like there's insufficient tooling?

There's been some stuff about reading and writing of vgabios blobs with
flashrom [1] but I haven't heard anything about a compiler or toolchain
that can produce them. The closest is the available disassembler [2], which
can provide some insight but probably wouldn't be useful for building
vgabios blobs from source as part of a coreboot build. (I think there were
also some modified radeon drivers for tracing vgabios calls, but I can't
find them now)

Besides a compiler, what other infrastructure would be needed? Maybe tools
for testing and debugging?

--
A side tangent:

One thing realized recently is some versions of the G505s contain slightly
different versions of the same rom. It seems my G505s' for example has
different LVDS timings that perfectly match the slightly different panel
that mine shipped with. [4]

I haven't been able to try a "normal" rom with the panel yet, but one
theory to be tested is that the proprietary bios is patching the rom with
the values from the panel's EDID information. (I tried installing a
different panel, but was only met with a temporarily nonfunctional laptop)

Assuming it's not the rom modifying itself (do vgabios' have access to EDID
information?), would it be correct to supply values from the EDID
information to the vgabios build? Or would it be better to have the
coreboot's loader patch the tables by parsing the current panel's EDID
info? (I've seen comments that coreboot's lack of EDID parsing support also
makes native graphics init harder [5])

Does anyone else know of other tooling that's out there?

Sincerely,
-Matt

--
[1]
https://www.phoronix.com/scan.php?page=news_item&px=Flashrom-AMD-SPI-Patches
[2]
https://www.phoronix.com/scan.php?page=article&item=amd_atombios_dumper&num=1
[3]
[4]
https://mail.coreboot.org/hyperkitty/list/coreboot@coreboot.org/thread/LKB4VKBFQ26ACC6D2D5I6FAKJY3WNAJB/
[5] https://www.raptorengineering.com/coreboot/kcma-d8-status.php
I also came across some other misc stuff:
https://www.phoronix.com/scan.php?page=news_item&px=MTQyMTg
https://www.nongnu.org/vgabios/
--
___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] Fwd: Re: Starting the coreboot 4.10 release process

[Matt B]

-- Forwarded message -
From: Matt B 
Date: Mon, Jun 3, 2019 at 7:19 PM
Subject: Re: [coreboot] Re: Starting the coreboot 4.10 release process
To: Mike Banon 


On a side note, when more than one option is possible, it's good to know
which the tester used.

Hypothetical example: did someone test the X230 with a vgabios blob or with
libgfxinit?
If unspecified, or if the default is the vgabiosblob (or nothing at all, as
above) then who knows if libgfxinit works?

-Matt

On Mon, Jun 3, 2019 at 4:21 PM Mike Banon  wrote:

> Okay, I returned your boards but added a note that "no board_status
> report yet". Hopefully you could submit them in the near future, at
> least for the archival purposes. And there's a similar question to
> someone else who added "Asus P8H61-M Pro" despite that the latest
> report for it is one year ago.
> > The default config should always be a known good config, unless the
> > board isn't well maintained. Needing a specific "good config" is a
> > sign of unattended bugs.
> Not necessarily: it could be that a default config is bootable for
> some board but still somehow inferior. For example, it may boot but
> without showing anything on a display, because no VGABIOS specified or
> provided. Or i.e. it may be hard to convince the people to enable some
> config by default despite it being useful, e.g. a coreinfo secondary
> payload. So board_status report is a great way to promote your nice
> config, and hopefully the people would share them more
>
> On Mon, Jun 3, 2019 at 5:28 PM Matt DeVillier 
> wrote:
> >
> > I added those devices, all of which I have in my possession and were
> tested over the weekend with TOT. I'd not yet had a chance to upload board
> status for them, but figured knowing a good range of platforms/boards were
> known working just prior to release was useful (and the purpose of the list)
> >
> > On Mon, Jun 3, 2019 at 9:14 AM Mike Banon  wrote:
> >>
> >> Just noticed that someone included i.e. some Purism Librem devices to
> >> a " Recently tested mainboards: " section - but, when I check
> >> https://review.coreboot.org/cgit/board-status.git/log/purism , the
> >> latest board status for Purism happened even before 4.9 ! And without
> >> a recent enough _public_ "board status" report - containing the
> >> important info about your build and its' complete configuration - I
> >> don't think we could include them to a "recently tested" list, since
> >> the other users won't have a chance to reproduce your build by using
> >> your configuration. Same question regarding some other of these
> >> additions, so removing them from a " Recently tested mainboards: "
> >> list, but of course they could be re-added if someone will submit a
> >> board_status reports from them.
> >>
> >> We would like to encourage the board status reporting, and relying on
> >> the word of users ( "I tested X board and it worked" ) would not help
> >> us to collect the known good configs at our coreboot/board_status
> >> repository.
> >>
> >> To submit a board status report for your board, please run a
> >> ./coreboot/util/board_status/board_status.sh script on it.
> >>
> >> Removed:
> >> * Purism Librem 13 v1
> >> * Purism Librem 15 v2
> >> * Purism Librem 13 v2/v3
> >> * Purism Librem 15 v3
> >> * Purism Librem 13 v4
> >> * Purism Librem 15 v4
> >> * Samsung Chromebook 3 (google/celes)
> >> * Acer Chromebook R11 (google/cyan)
> >> * Google Chromebook Pixel 2013 (google/link)
> >> * Toshiba Chromebook 2 (2014) (google/swanky)
> >> * Dell Chromebook 13 7310 (google/lulu)
> >> * Dell Inspiron Chromebook 14 (google/nami)
> >> * Acer Chromebook 14 (google/edgar)
> >> * HP Chromebook 13 G1 (google/chell)
> >> * Asus Chromebox CN60 (google/panther)
> >> * Asus Chromebox CN62 (google/guado)
> >> * Asus Chromebox CN65 (google/fizz)
> ___
> 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] Fwd: Re: ASUS KGPE-D16 ECC disabled by default

[Matt B]

-- Forwarded message -
From: Matt B 
Date: Sat, Jun 1, 2019 at 12:17 PM
Subject: Re: [coreboot] Re: ASUS KGPE-D16 ECC disabled by default
To: Kinky Nekoboi 


Hi,

So configuring ECC to be on by default in nvram has no effect?

Sincerely,
-Matt

On Sat, Jun 1, 2019 at 11:08 AM Kinky Nekoboi 
wrote:

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

[Matt B]

That's pretty impressive, imho. Especially the ability to figure out some
of the steps it goes through during boot.
With AMD suddenly putting out more capable chips, they and the PSP might
become more relevant.

Sincerely,
-Matt

On Fri, May 31, 2019 at 6:05 AM Kinky Nekoboi 
wrote:

> Nice work,
>
>  first step to an PSPCleaner!
>
>
> Am 31.05.19 um 11:27 schrieb Christian Werling:
>
> Hi everyone,
>
> over the past year I did some research on AMD’s controversial Secure
> Processor (formerly known as Platform Security Processor or PSP). Its
> firmware is stored in an undocumented area of UEFI images and so I wrote a
> tool that can parse it. I thought some of you might be interested in that:
> https://github.com/cwerling/psptool
>
> It is accompanied by PSPTrace, which can correlate an SPI capture of a
> boot procedure to the AMD firmware entries so you can deduct some boot
> logic from it.
>
> Cheers,
> Christian
>
> ___
> coreboot mailing list -- coreboot@coreboot.org
> To unsubscribe send an email to coreboot-le...@coreboot.org
>
> ___
> coreboot mailing list -- coreboot@coreboot.org
> To unsubscribe send an email to coreboot-le...@coreboot.org
>
___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] Re: Asus M5A88-V (EVO?) Status

[Matt B]

Hi,

Just a quick question: did the ASUS KFSN4-DRE ever receive family 15h
support, in addition to 10h? or was that only the KGPE boards?

Thanks,
-Matt

On Tue, May 21, 2019 at 12:16 PM Kinky Nekoboi 
wrote:

> Also Asus F2A85-M works now really good,
>
> An Zen2 coreboot board with PSP Cleaner and working ECC would be a dream.
>
> Am 21.05.19 um 15:23 schrieb Mike Banon:
> > Robin, if you already have this M5A88-V board, why not to try? ;-)
> > AM3+ : if you'd go to a coreboot board status page [1] and search for
> > AM3, there are 8 matches - some have a fresh board status and some of
> > these AM3 may be AM3+, haven't checked yet. AM4 : no such boards, but
> > maybe would appear in the future - see [2] - but we don't know if
> > there would be a PSP inside these Chinese Zens.
> >
> > If you are simply looking for a high performance AMD desktop
> > motherboard, maybe you could consider looking at some of the other
> > sockets? For example, A88XM-E FM2+ boards - which you could find used
> > for 58 usd with free ship (e.g. AliExpress) and where you could
> > install a powerful A10-6700 or A10-6800 APU (newer -7*** models may be
> > not supported). Although A88XM-E boards are not officially supported
> > by a coreboot yet, if you would look under a [2] patch review, aside
> > from a few problems this board has a pretty good working status. There
> > are also more powerful AMD boards like the (also libreboot-supported)
> > ASUS KCMA-D8 / ASUS KFSN4-DRE and especially a prominent ASUS KGPE-D16
> > with two AMD Opterons . And there are less powerful ASUS AM1I-A and a
> > few of other AM1 boards ( Athlon 5370 is the most powerful for this
> > socket, but it's rare; more frequent is 5350 )
> >
> > [1] https://coreboot.org/status/board-status.html
> > [2]
> https://www.phoronix.com/scan.php?page=news_item&px=Hygon-Dhyana-Coreboot-First
> > [3] https://review.coreboot.org/c/coreboot/+/30987
> >
> > On Tue, May 21, 2019 at 12:45 PM Robin C  wrote:
> >> Hi,
> >>
> >> Thanks for all info. I wont try coreboot with this board... I hope that
> one day AMD mainboards will be much supported.
> >>
> >> Recetly many security breaches had been descovered in Intel cpus. And I
> would like to fine an am3+ or even am4 Mobo compatible with coreboot.
> >>
> >> Did you know if there is any?
> >>
> >> R
> >>
> >> Le sam. 18 mai 2019 22:56, Matt B  a écrit
> :
> >>> Hi,
> >>>
> >>> Looks like as of this thread there were issues detecting any CPU newer
> than a K10:
> >>> https://mail.coreboot.org/pipermail/coreboot/2012-April/069394.html
> >>>
> >>> At some point someone tried to get family 15h to work as well, but ran
> into issues bringing up sata:
> >>> https://review.coreboot.org/c/coreboot/+/3611
> >>> There are also issues there with usb and the GPU. Issues with the sata
> controller were mentioned previously here:
> >>> https://review.coreboot.org/c/coreboot/+/2610
> >>>
> >>> There is also an abandoned port that was based on this board:
> >>> https://review.coreboot.org/c/coreboot/+/5551
> >>>
> >>> And it was mentioned here:
> >>> https://review.coreboot.org/c/coreboot/+/28225
> >>>
> >>> Sincerely,
> >>> -Matt
> >>>
> >>> On Sat, May 18, 2019 at 3:17 PM Mike Banon  wrote:
> >>>> Hi Robin, M5A88-V board is supported by coreboot, but nobody sent a
> >>>> board_status report for it - that's why its' status at this page is
> >>>> "unknown". So, to learn what is working and what isn't, you have to
> >>>> search through the coreboot mailing list archives and read the
> >>>> discussions under M5A88-V patches at review.coreboot.org . Hope you
> >>>> could share your findings here then, to save the time for others.
> >>>>
> >>>> Best regards,
> >>>> Mike Banon
> >>>>
> >>>> On Sat, May 18, 2019 at 4:59 PM Robin C  wrote:
> >>>>> Hi all,
> >>>>>
> >>>>> On coreboot status page, I can see that M5A88-V status is unknown
> (EVO? M5A88-V seems not referenced in asus support page)
> >>>>>
> >>>>> But when I search infos about it :
> https://github.com/DarkDefender/coreboot
> >>>>> In coreboot official repo somes changes have been down recently.
&

[coreboot] Re: Asus M5A88-V (EVO?) Status

[Matt B]

Hi,

Looks like as of this thread there were issues detecting any CPU newer than
a K10:
https://mail.coreboot.org/pipermail/coreboot/2012-April/069394.html

At some point someone tried to get family 15h to work as well, but ran into
issues bringing up sata:
https://review.coreboot.org/c/coreboot/+/3611
There are also issues there with usb and the GPU. Issues with the sata
controller were mentioned previously here:
https://review.coreboot.org/c/coreboot/+/2610

There is also an abandoned port that was based on this board:
https://review.coreboot.org/c/coreboot/+/5551

And it was mentioned here:
https://review.coreboot.org/c/coreboot/+/28225

Sincerely,
-Matt

On Sat, May 18, 2019 at 3:17 PM Mike Banon  wrote:

> Hi Robin, M5A88-V board is supported by coreboot, but nobody sent a
> board_status report for it - that's why its' status at this page is
> "unknown". So, to learn what is working and what isn't, you have to
> search through the coreboot mailing list archives and read the
> discussions under M5A88-V patches at review.coreboot.org . Hope you
> could share your findings here then, to save the time for others.
>
> Best regards,
> Mike Banon
>
> On Sat, May 18, 2019 at 4:59 PM Robin C  wrote:
> >
> > Hi all,
> >
> > On coreboot status page, I can see that M5A88-V status is unknown (EVO?
> M5A88-V seems not referenced in asus support page)
> >
> > But when I search infos about it :
> https://github.com/DarkDefender/coreboot
> > In coreboot official repo somes changes have been down recently.
> >
> > So is this mainboard officialy supported with the lastest coreboot
> version and what does or does not work?
> >
> > Best regards
> >
> > SkollRC
> > ___
> > coreboot mailing list -- coreboot@coreboot.org
> > To unsubscribe send an email to coreboot-le...@coreboot.org
> ___
> coreboot mailing list -- coreboot@coreboot.org
> To unsubscribe send an email to coreboot-le...@coreboot.org
>
___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] Re: G505s: Discrepancies b/w harvested vgabios VS patches

[Matt B]

Hi,

Real progress this time, on understanding the differences in the LVDS info.

I should note (btw) that I'm currently testing with the most up-to-date
version of the proprietary G505s bios.

I dumped the EDID information for my display panel from the following files:
/sys/devices/pci:00/:00:01.0/drm/card0/card0-HDMI-A-1/edid
/sys/devices/pci:00/:00:01.0/drm/card0/card0-VGA-1/edid
/sys/devices/pci:00/:00:01.0/drm/card0/card0-eDP-1/edid
The first two were blank (which seems to be normal for Lenovo) and the
third contained an EDID blob, see the end of the email for the raw bytes,
attachments for the file itself.

I pasted this into the online tool www.edidreader.com and made some
interesting findings, like that my panel's serial number is zero or that
the manufacturing date seems to be incomplete. (some time in 2012?)
However, most notably the detailed timing characteristics are:
Pixel Clock: 69.3MHz
Horizontal Active: 1366
Horizontal Blanking: 112
Vertical Active: 768
Vertical Blanking: 14
Horizontal Sync Offset: 32
Horizontal Sync Pulse: 32
Vertical Sync Offset: 2
Vertical Sync Pulse: 4
Horizontal Display Size: 345
Vertical Display Size: 194
Horizontal Border: 0
Vertical Border: 0
Interlaced: false
Stereo Mode: 0
Sync Type: 3
2-Way Line-Interleaved Stereo: true

The weird thing is that it was the *eDP* EDID file which was non-empty,
when I could have sworn that the G505s uses a 40 pin LVDS cable.

When these values are compared with the LVDS values you flagged, every
single one of them is a match when your values are converted to decimal. It
might be worthwhile to compare the two sets in their entirety to see if
there's anything that doesn't match up.

This is *pure* speculation on my part, but I'm suspecting that the
proprietary bios patches the vgabios rom with the timing information it
extracts from the panel's EDID information. For the sake of argument, I
suppose that the EDID information presented could be derived from the blob,
but this seems unlikely.

As luck would have it, I have another laptop with a display panel that (I
suspect) is a compatible replacement for the one in the G505s, and which I
am *very* experienced at replacing. :) It will have to wait, but it's
theoretically possible I could frankenstein this panel into the G505s and
check to see if the above theory is correct. The blob as it exists in the
spi flash could also be examined.

This raises an interesting question: Does coreboot have machinery to patch
vgabios blobs based on EDID codes? I have to imagine it might improve
compatibility, and parts of it might even be helpful to libgfxinit.

Sincerely,
-Matt

EDID bytes:
0x00 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0x00 0x30 0xE4 0x9F 0x03 0x00 0x00 0x00
0x00 0x00 0x16 0x01 0x03 0x80 0x23 0x13 0x78 0x0A 0x05 0xF5 0x94 0x58 0x56
0x92 0x28 0x1E 0x50 0x54 0x00 0x00 0x00 0x01 0x01 0x01 0x01 0x01 0x01 0x01
0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x12 0x1B 0x56 0x70 0x50 0x00
0x0E 0x30 0x20 0x20 0x24 0x00 0x59 0xC2 0x10 0x00 0x00 0x19 0x00 0x00 0x00
0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00
0x00 0x00 0x00 0xFE 0x00 0x4C 0x47 0x20 0x44 0x69 0x73 0x70 0x6C 0x61 0x79
0x0A 0x20 0x20 0x00 0x00 0x00 0xFE 0x00 0x4C 0x50 0x31 0x35 0x36 0x57 0x48
0x33 0x2D 0x54 0x4C 0x53 0x31 0x00 0xE3




On Thu, May 9, 2019 at 7:03 PM Matt B  wrote:

> Hi,
>
> I didn't get a different binary (at least, using this method) when
> charging the battery, nor did I get different results when doing so under
> full CPU load under linux.
>
> Getting frustrated with the livecd I took a break and tried Hardware
> Monitor under windows. The "GPU voltage" was static at 1.062 V while
> charging the battery and under none-to-light load. (graphics and memory
> clocks at 351 and 800 MHz respectively) The CPU voltages started to swing
> noticeably when the CPU was stressed, but the GPU voltages remained
> constant. This was confirmed by AMD OverDrive. (version 4.2.6.0659)
>
> However, when stressing the GPU using a browser-based benchmark (
> web.basemark.com), the GPU voltage spiked to as high as 1.137 Volts as
> reported by the windows software. I switched back to void linux and ran the
> same benchmark, but unfortunately the collected vgabios rom is still the
> same. (even while under such heavy load that the computer became difficult
> to use)
>
> Sincerely,
> -Matt
>


eDP_EDID.bin
Description: Binary data
___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] Re: G505s: Discrepancies b/w harvested vgabios VS patches

[Matt B]

Hi,

I didn't get a different binary (at least, using this method) when charging
the battery, nor did I get different results when doing so under full CPU
load under linux.

Getting frustrated with the livecd I took a break and tried Hardware
Monitor under windows. The "GPU voltage" was static at 1.062 V while
charging the battery and under none-to-light load. (graphics and memory
clocks at 351 and 800 MHz respectively) The CPU voltages started to swing
noticeably when the CPU was stressed, but the GPU voltages remained
constant. This was confirmed by AMD OverDrive. (version 4.2.6.0659)

However, when stressing the GPU using a browser-based benchmark (
web.basemark.com), the GPU voltage spiked to as high as 1.137 Volts as
reported by the windows software. I switched back to void linux and ran the
same benchmark, but unfortunately the collected vgabios rom is still the
same. (even while under such heavy load that the computer became difficult
to use)

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

[coreboot] Re: G505s: Discrepancies b/w harvested vgabios VS patches

[Matt B]

Hi,

Interesting results for sure.

It's probably important to note that I actually performed the dump while
the laptop was running on a half-charged battery or somewhere in that
ballpark. (and a really rather annoying Void Linux live-cd) It seems
counter-intuitive that the system would raise voltages under this scenario.

I'll try dumping the rom again multiple times under various load/power
conditions. I can probably accomplish this by the end of the day.

I'll look into seeing if I can get the model number of my panel too. At the
same time, it would be good if there were a way to ask it about itself.

Sincerely,
-Matt

On Wed, May 8, 2019 at 1:10 PM Mike Banon  wrote:

> Hi Matt, so I compared the AtomDis dumps for iGPU ROMs ( yours vs mine
> ). There are some differences at " data_table  aae6  #06
> (LVDS_Info): ", sLCDTiming structure:  usPixClk ( 0x1b12 vs 0x1c41 ),
> usHBlanking_Time ( 0x0070 vs 0x00a0 ), usVBlanking_Time ( 0x000e vs
> 0x0016 ), usHSyncOffset ( 0x0020 vs 0x0030 ), usVSyncWidth ( 0x0004 vs
> 0x0005 ), usImageHSize ( 0x0159 vs 0x0158 ). Also, some differences at
> " data_table  b1b8  #1e  (IntegratedSystemInfo): " : usNBP0Voltage
> ( 0x4c vs 0x4a ) and usNBP1Voltage ( 0x4e vs 0x4c ) - your values are
> slightly higher, and some of your usVoltageID values are also slightly
> higher (0x72 vs 0x70, 0x4e vs 0x4c, 0x48 vs 0x46, 0x42 vs 0x40, 0x42
> vs 0x40). Finally, nearby there is also one different ulReserved3 (
> 0x00760050 vs 0x0074004e ) - I don't know what this reserved value
> means, but perhaps it's also related to the voltages or power control.
>
> What is interesting, at our messages [*] there also was a difference
> at usNBP0Voltage and usNBP1Voltage values: 0x4a vs 0x48 and 0x4c vs
> 0x4a , but these and your other voltage values are even slightly more
> higher than this, 2 points higher. Now I think that maybe these values
> are changing in runtime: while there is a higher CPU load (e.g. while
> I was reading a lot of RAM with Belkasoft RAM capturer to later
> extract the AtomBIOS ROMs from it), the performance of GPU could
> automatically decrease by slightly lowering the voltage, in order to
> fit the whole APU into 35 Watts TDP.
>
> 1) It will be great if you could test this theory by running some
> CPU-intensive program and dumping the AtomBIOS ROM while it's running.
>
> I still don't know why your sLCDTiming structure is different. Is it
> also a variable value not tied to the specific hardware, or maybe you
> have a slightly different LCD panel - which I have never encountered
> before - and it has a slightly different settings?
>
> 2) It will be interesting if you could build a coreboot with my
> version of iGPU ROM, to see if there are any problems with your screen
> image.
>
> Hope you could complete "1)" and "2)" quests when you have some free time
> ;-)
>
> Best regards,
> Mike Banon
>
> P.S. It could be that a few diffs, e.g. a couple of tiny diffs at the
> beginning, may have gone unnoticed while using AtomDis :P
>
> [*]
> https://mail.coreboot.org/hyperkitty/list/coreboot@coreboot.org/thread/GZNWISLFHUTYN6C7RTWSQUMJIFOUHMED/
>
> On Mon, May 6, 2019 at 8:49 PM Mike Banon  wrote:
> >
> > Hi, Matt! Thank you very much for your research. Yes, I confirm that
> > the ROMs provided my patch [1] ( installed by ./atombios.sh from this
> > wiki [3] ) have been obtained from two G505S: one with HD 8570M dGPU
> > and another with R5 M230 dGPU ; and the iGPU ROM of this patch is
> > "from G505S with R5 M230", with the differences outlined in our
> > messages [4] . I don't have a G505S without a discrete GPU - so
> > couldn't get its' iGPU ROM version from it by myself. However: the
> > build with my ("from G505S with R5 M230") integrated GPU ROM version,
> > discrete GPU ROMs and also the dGPU patches - has been tested by
> > /u/QubesN00b at [2] thread - and no problems observed.
> >
> > Maybe these differences at iGPU are related to dGPU, since these GPUs
> > were meant to be working together in a Crossfire? Thank you for
> > submitting your ROM, a bit later I'm going to use AtomDis to try to
> > figure out what are these differences and report back. Hopefully these
> > differences aren't significant and this iGPU ROM "from G505S with R5
> > M230" really could be used by everyone without any downsides (also
> > because I don't want to overcomplicate my patches with multiple ROM
> > versions for the same iGPU)
> >
> > Best regards,
> > Mike Banon
> >
> > [1] https://review.coreboot.org/c/coreboot/+/31944
> > [2]
> https://www.

[coreboot] Re: KGPE-D16: coreboot-4.5 stuck in boot loop. Help on getting the system to boot or flash newer version

[Matt B]

While I think it's great that it worked, I'd recommend flashing with a
programmer before hotswapping the bios chip.

You could work through compiling a fresh copy of coreboot on another
computer, or if someone knows how to extract the bios image from an asus
download you could try restoring that.

-Matt

On Tue, Apr 30, 2019 at 11:50 AM Sean Lynn Rhone 
wrote:

> I had to do something similar with a KCMA-D8 motherboard, but I had an
> old motherboard around that let me hotswap the BIOS chip, and I was
> able to use flashrom from a Linux LiveUSB to flash the ASUS vendor BIOS
> to the chip, while socketed in another motherboard.
>
> After the flash, I powered off the computer, took the BIOS chip out,
> tossed it into the KCMA-D8 motherboard, and was good to go.
>
> For specific beginner-friendly steps:
>
> 1. Boot an old motherboard (something without Intel ME is more likely
> to succeed; I have an AMD 700/800 Phenom II motherboard for this) with
> it's BIOS chip into a Linux LiveUSB (like Lubuntu)
> 2. Install flashrom (apt/zypper/dnf/package manager should be fine, but
> worst-case if the chip isn't recognized, you'll need to compile
> flashrom from source which has additional dependencies and steps)
> 3. Download/copy the vendor BIOS ROM file somewhere
> 4. Test if flashrom can read/write to the original BIOS chip without
> problem (dump the chip contents and attempt to re-write it back)
> 5. With the computer/motherboard still powered, remove its BIOS chip
> (with usual anti-ESD measures; use a chip puller preferably but you can
> also "gently" wiggle it out with your fingers)
> 6. Insert a different BIOS chip that you want flashed into the socket
> 7. Use flashrom to write to that BIOS chip (internal flash)
> 8. If flashrom succeeds, power off the computer/motherboard
> 9. Remove the flashed BIOS chip from that computer/motherboard, and
> insert it into whatever other motherboard you were trying to fix
> 10. Re-insert the original BIOS chip into the flasher motherboard
>
> On Tue, 2019-04-30 at 18:02 +0300, Mike Banon wrote:
> > These pre-flashed BIOS chips are overpriced. You could download the
> > latest BIOS from ASUS website and flash it directly to your existing
> > BIOS chip using another computer and flashrom-supported hardware
> > flasher.
> > ___
> > coreboot mailing list -- coreboot@coreboot.org
> > To unsubscribe send an email to coreboot-le...@coreboot.org
> ___
> coreboot mailing list -- coreboot@coreboot.org
> To unsubscribe send an email to coreboot-le...@coreboot.org
>
___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] Re: KGPE-D16: coreboot-4.5 stuck in boot loop. Help on getting the system to boot or flash newer version

[Matt B]

That method of emergency recovery with a USB stick has already been wiped
out by installing coreboot.

-Matt

On Mon, Apr 29, 2019 at 4:09 PM Pablo Correa Gómez 
wrote:

> Hello and thank you in advance for your time.
>
>  I recently bought a KGPE-D16 motherboard with a single AMD Opeteron
> 8262SE and coreboot installed. I bought from another supplier 4 memory
> sticks Samsung 8GB (M393B1K70DH0-YK0) that per this thread[1] should
> work with coreboot. I am able to start the assembled system and to get
> serial output. According to the logs, coreboot first does the
> initialisation and training of the memory and then start working on the
> PCIs. At one point in the boot sequence, I get the following message:
>
> Loaded segments
> BS: BS_PAYLOAD_LOAD times (us): entry 0 run 80561 exit 0
> POST: 0x7b
> Jumping to boot code at 000ff06e(b7cc1000)
> POST: 0xf8
> CPU0: stack: 0015 - 00151000, lowest used address 001509e0, stack
> used: 1568 bytes
> entry= 0x000ff06e
> lb_start = 0x0010
> lb_size  = 0x00116270
> buffer   = 0xbfdd3000
>
> Then it stalls for like 20-30 seconds and the booting process restarts
> from the beginning. I had considered different options in order to boot
> and I would like to know if someone would have any recommendations.
> Right now my priority is to get the system up and working. I can worry
> about installing coreboot later, but having it now is for sure a plus:
>   1) Buy a new chip with the original ASUS BIOS in order to boot the
> system.
>   2) Externally flash the chip I have right now with a newer version of
> coreboot. I probably have enough things at home to flash it, but I have
> not found information from ASUS. In coreboot there is some information
> but very general and not enough for my knowledge. As far as I have read
> from flashrom, I should be able to flash it using a Raspberry Pi or a
> BeagleBone Black, but KGPE-D16 is not marked as supported and I don't
> know which model is the BIOS chip to check if it is supported.
>   3) The moderboard datasheet has a section called: "Force BIOS
> recovery setting", which says that in order to flash the proprietary
> BIOS, it is as simple as changing a jumper an inserting an USB stick. I
> would have already done it if I would not be reluctant to believe that
> it is that simple.
>
> Which are your thoughts about this ideas? Any other one that would be
> simpler and would let me boot the full system?
>
> Thank you very much,
> Pablo.
>
>
> NOTE: I have tried with the 4 sticks in the orange slots, the 4 sticks
> in the 4 further DIMMs from the CPU (2 orange, 2 black) and those
> configurations both 1.35 and 1.5V. Logs are slightly different, in the
> training section, but the problem while booting remains. A USB stick
> with Debian Installer has been plugged-in during since boot process
> begins.
>
> [1] https://mail.coreboot.org/pipermail/coreboot/2017-February/083151.h
> tml
> 
> ___
> 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: Chainloading Windows from a Linux Payload

[Matt B]

Thanks for the info. Does anyone know of a workaround in the meantime?

I've found some information on chainloading grub4dos and from there loading
windows (or whatever else), but all of it dates back to around 2014.

Around the same time there's stuff on passing elf files to kexec, but that
looks like it never got merged or isn't used. (appears to be from the time
when kexec itself was implemented) No idea whether that would work with a
payload, even if the mechanism exists.

Thanks,
-Matt

On Sat, Apr 13, 2019 at 2:48 PM ron minnich  wrote:

> Esxi works today freebsd is coming and windows is in Long term thinking
>
> On Fri, Apr 12, 2019, 11:46 AM Rafael Send 
> wrote:
>
>> Good question, I'd be interested in the answer to this as well if anyone
>> has some insight.
>>
>> Cheers,
>> R
>>
>> On Fri, Apr 12, 2019 at 7:45 AM Matt B 
>> wrote:
>>
>>> Greetings,
>>>
>>> From what I can find, Linux can only chainload another linux kernel.
>>> (via kexec) Does this mean that a Linux payload like LinuxBoot cannot be
>>> used to boot Windows or another OS, either directly or by chainloading
>>> another payload from CBFS?
>>>
>>> It's nice that a Linux payload can provide superior flexibility and
>>> configurability than UEFI with the added benefit of a battle-hardened
>>> environment, but the ability to only boot a Linux OS seems like a pretty
>>> significant limitation (if this is indeed the case).
>>>
>>> Sincerely,
>>> -Matt
>>> ___
>>> coreboot mailing list -- coreboot@coreboot.org
>>> To unsubscribe send an email to coreboot-le...@coreboot.org
>>>
>> ___
>> coreboot mailing list -- coreboot@coreboot.org
>> To unsubscribe send an email to coreboot-le...@coreboot.org
>>
>
___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] Re: Bios problem. Will not boot

[Matt B]

Out of curiosity, what payload are you using?

-Matthew

On Sun, Apr 14, 2019 at 8:22 AM Enkelena Haxhiu 
wrote:

> I am using lenovo thinkpad x230. It has Linux on its ssd, Debian to be
> precise.
>
> You are saying that just because the new hdd has windows, its not booting
> on it?
>
> Regards,
> Enkelena
>
> On Sun, Apr 14, 2019, 2:02 PM Ivan Ivanov  wrote:
>
>> I think you'll need to reinstall your Windows in any case, especially
>> if you've installed it using another PC. This is not a coreboot
>> problem, more like a Windows problem, and going back from glorious
>> opensource coreboot to heretical proprietary UEFI won't fix the things
>> ;-) Also, you haven't even told us what coreboot-supported computer
>> you are using...
>>
>> вс, 14 апр. 2019 г. в 14:50, Enkelena Haxhiu :
>> >
>> > Hi everyone,
>> >
>> > I have a problem.
>> >
>> > I had flashed my bios last year into coreboot by a raspberry pi.
>> > Now, I changed the hard disk of that laptop, and put another one with
>> windows on it, but it does not boot there.
>> > Every key that I press it gets me to booting from hard disk, and again
>> the process repeats.
>> >
>> > Is there any way I can fix it?
>> >
>> > What do you think if I put again the last disk and boot into that to
>> make it start
>> > normally and then download files to flash the bios into lenovo's
>> default bios?
>> > Will this work?
>> >
>> > Regards,
>> > Enkelena
>> >
>> > ___
>> > coreboot mailing list -- coreboot@coreboot.org
>> > To unsubscribe send an email to coreboot-le...@coreboot.org
>>
> ___
> coreboot mailing list -- coreboot@coreboot.org
> To unsubscribe send an email to coreboot-le...@coreboot.org
>
___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] Chainloading Windows from a Linux Payload

[Matt B]

Greetings,

>From what I can find, Linux can only chainload another linux kernel. (via
kexec) Does this mean that a Linux payload like LinuxBoot cannot be used to
boot Windows or another OS, either directly or by chainloading another
payload from CBFS?

It's nice that a Linux payload can provide superior flexibility and
configurability than UEFI with the added benefit of a battle-hardened
environment, but the ability to only boot a Linux OS seems like a pretty
significant limitation (if this is indeed the case).

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

[coreboot] Re: Booting from MiniPCI on X230

[Matt B]

On Tue, Mar 26, 2019 at 2:44 PM Matt B  wrote:

> Hi,
>
> Good to hear. Does having a regular 2.5 inch drive present affect your
> ability to do this?
>
> The above wiki notes that an msata drive is used as cache whenever such a
> drive is present under the stock BIOS on the X230. While your laptop is not
> the same model I'm wondering if this behavior is a product of the chipset
> or the BIOS itself (in which case, it may not be an issue under coreboot).
>
> Thanks,
> -Matt
>
> On Tue, Mar 26, 2019 at 9:06 AM Evgeny Zinoviev  wrote:
>
>> Hi. I boot my W530 from mSATA SSD using only GRUB payload. SeaBIOS also
>> works.
>> On 26/03/2019 01:57, Matt B wrote:
>>
>> Hi,
>>
>> Does anyone know of a payload (or payloads) that would allow booting from
>> an mSATA SSD within the second MiniPCI Express slot in an X230 thinkpad?
>>
>> http://www.thinkwiki.org/wiki/Category:X230 notes that it's possible
>> under the stock BIOS when a HDD is not present, but is it possible under
>> Coreboot? Has anyone tried?
>>
>> Thanks,
>> -Matt
>>
>> ___
>> coreboot mailing list -- coreboot@coreboot.org
>> To unsubscribe send an email to coreboot-le...@coreboot.org
>>
>> ___
>> coreboot mailing list -- coreboot@coreboot.org
>> To unsubscribe send an email to coreboot-le...@coreboot.org
>>
>
___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] Booting from MiniPCI on X230

[Matt B]

Hi,

Does anyone know of a payload (or payloads) that would allow booting from
an mSATA SSD within the second MiniPCI Express slot in an X230 thinkpad?

http://www.thinkwiki.org/wiki/Category:X230 notes that it's possible under
the stock BIOS when a HDD is not present, but is it possible under
Coreboot? Has anyone tried?

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

[coreboot] Re: Locking coreboot against internal flashing

[Matt B]

Would it make the most sense to put locking option in coreboot's
board-specific code, since the method varies between boards? Could a common
ACPI call for it be provided that could be called by a payload or OS later
if it's present?

-Matt


On Sun, Feb 17, 2019 at 8:48 PM Frank Beuth  wrote:

> On Sun, Feb 17, 2019 at 12:24:38PM +0100, Nico Huber wrote:
> >I'm not sure if I quite follow. You mean the locking that prevents you
> >from installing a retrofitted coreboot? That's not a lock that prevents
> >malware from anything (because of existing exploits). There are ways to
> >install coreboot on such systems without external programmer. It's just
> >sometimes a very uncomfortable, hacky way and if it fails you'll need an
> >external programmer anyway. But nothing is too uncomfortable for crimi-
> >nals. They just have to figure it out once and then profit per every-
> >body's unit (not just there own unit).
>
> I see, this explains a lot and goes a long way to resolving the original
> issue
> ("installing Coreboot makes me less secure because it enables software
> reflashing").
>
> > [Coreboot] offers only
> >locking options that make sense in certain use cases.
>
> Most of the locking options that have been discussed in this thread so far
> are
> rather hacky (often requiring writing new code) and not part of any
> Coreboot or related (e.g SeaBIOS) software package.
>
> For Coreboot and related packages, you previously mentioned
> LOCK_SPI_FLASH_RO
> and some unspecified locking options in the FILO payload. Are there any
> others?
> ___
> 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: if your G505S does NOT have a discrete GPU (= LA-A092P board), please test this coreboot build

[Matt B]

So, if one does not have a dGPU, one should not set
CONFIG_MULTIPLE_VGA_ADAPTERS and the appropriate tables will be filled in
with the vbios for the iGPU. And the dGPU will not be initialized. (or
attempted, since it doesn't exist)

If one does have a dGPU, then only information for the dGPU will be
included (no vbios for iGPU) and the iGPU will not be initialized.

Is this correct?

-Matt

On Mon, Feb 18, 2019 at 10:02 AM Mike Banon  wrote:

> Great news! /u/QubesN00b flashed this dGPU build to his "no-dGPU"
> G505S and everything seems to be working fine for him :D (
>
> https://www.reddit.com/r/coreboot/comments/ar8v7d/if_your_g505s_does_not_have_a_discrete_gpu/
> ) . Now I could e.g. remove "if
> (IS_ENABLED(CONFIG_MULTIPLE_VGA_ADAPTERS))" condition from
>
> https://review.coreboot.org/c/coreboot/+/31450/3/src/mainboard/lenovo/g505s/OemCustomize.c
> - and set BottomIo to 0xD0 for all G505S.
>
___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] Re: AMDFlaws

[Matt B]

>
> Early 16h systems (Jaguar) are safe because they don't have a
> PSP


Safe yes, but not helpful in coming to grips with the PSP.


> > On Sun, Feb 17, 2019 at 12:18 AM Matt B 
> wrote:
> >
> > As for the patching, afaik AMD has released patches for all of these,
> but I haven't seen any patches for my 16h systems.
> >
> 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?


I was specifically referring to the non-coreboot-supported 16h systems with
PSP that I have.

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.


This sounds very promising and should be well worth pursuing.

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


One step at a time I guess. We'd get nowhere if we weren't willing to
tolerate some imperfections, especially while working on others.

-Matt

On Sun, Feb 17, 2019 at 7:20 AM Kyösti Mälkki 
wrote:

>
> 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: AMDFlaws

[Matt B]

This fairly interesting stuff. With the fairly wide range of attacks
(arbitrary code execution and faking signatures for modules) maybe some
sort of runtime "psp-cleaner" might be possible, but it would probably be a
crushingly difficult undertaking.

It's somewhat unclear form the slides, but it looks like these target the
17h (ryzen) psp. Do the same exploits also affect earlier versions?

As for the patching, afaik AMD has released patches for all of these, but I
haven't seen any patches for my 16h systems. Maybe if it's ryzen there has
been more enthusiasm to provide patches?

-Matt

On Sat, Feb 9, 2019 at 4:53 PM Ivan Ivanov  wrote:

> Hi Shawn, thank you for the message! Luckily almost all the
> coreboot-supported AMD boards don't contain the PSP inside their CPUs
> - maybe because PSP got added to AMD much later than ME got added to
> Intel. Only a few AMD boards, starting with "late 16h" architecture
> (early 16h is fine) have the PSP inside. "With PSP +
> coreboot-supported" : could remember only some of newer PC Engines
> boards. Some examples: I have Lenovo G505S laptop - it has powerful
> quadcore CPU and supports 16GB RAM, but it is AMD 15h architecture, so
> no PSP there. ASUS KGPE-D16 powerful server with two AMD opterons (up
> to 16 cores each) - also no PSP. So, as you see, this "PSP problem" is
> not critical yet for AMD coreboot users. But of course it is important
> and thank you for raising the awareness and sharing this interesting
> presentation. Although maybe it'd have been better if such
> presentations were released later by their authors, because now AMD
> could patch these PSP flaws to make it stronger and harder to
> jailbreak :P
>
> чт, 7 февр. 2019 г. в 09:13, Shawn :
> >
> >
> https://storage.googleapis.com/wzukusers/user-28822230/documents/5c5b3fd28b669cTWPzwo/AMDFlaws%20Lecture%20Slides.pdf
> >
> > PSP is so powerful just like ME/SPS on Intel chipset. AMD user might
> > need a similar tool like me_cleaner? psp_cleaner?
> >
> > --
> > GNU powered it...
> > GPL protect it...
> > God blessing it...
> >
> > regards
> > Shawn
> > ___
> > coreboot mailing list -- coreboot@coreboot.org
> > To unsubscribe send an email to coreboot-le...@coreboot.org
> ___
> coreboot mailing list -- coreboot@coreboot.org
> To unsubscribe send an email to coreboot-le...@coreboot.org
>
___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

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

[Matt B]

Out of curiosity, is there a config to disable the dGPU to save power if
one is present?

Thanks,
-Matt

On Sat, Feb 16, 2019 at 9:12 AM Kyösti Mälkki 
wrote:

>
>
> 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 mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] Re: Coreboot Self-Flashing Through Payload?

[Matt B]

Makes sense. That was one thing that gave me a bit of a gut feeling to do
it in a small linux install than to try to integrate more tightly with the
firmware. The linux utility is what everyone uses and should be more
reliable.

I've been recently burned by that issue too, on proprietary firmware from
around 2008.

-Matt

On Thu, Feb 14, 2019 at 7:56 PM ron minnich  wrote:

> On Thu, Feb 14, 2019 at 9:29 AM Matt B  wrote:
> >
> > Hi,
> >
> > I was helping a friend with a bios issue (we may have an involuntary
> coreboot convert on our hands ;) ) and realized that a lot of BIOSs provide
> a way for the BIOS to flash itself but Coreboot doesn't.
>
> And, for the record, this was intentional, a decision I made in 1999
> when I started the project. I had been burned big time by firmware
> systems that claimed to be able to reliably reflash themselves, and
> the history of UEFI self-reflash, at least in my view, confirms that
> this was the right call.
>
> I just wanted to make clear that this was not an oversight, it was a
> decision we made from the start. We always felt more willing to trust
> a user mode program running under Linux to get it right, as opposed to
> some magic thing in the firmware ... :-)
>
> thanks
>
> ron
>
___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] Re: Coreboot Self-Flashing Through Payload?

[Matt B]

>
> Actually that's what we do in the FILO payload.


What is libflashrom used for in FILO? Was it intended at some point that
FILO be able to reflash the BIOS, or is it being used for something like
reading the flash chip in order to load other things?

-Matt

On Thu, Feb 14, 2019 at 3:45 PM Nico Huber  wrote:

> Hi Matt,
>
> On 14.02.19 18:56, Patrick Georgi via coreboot wrote:
> > Am Do., 14. Feb. 2019 um 18:47 Uhr schrieb Vadim Bendebury
> > :
> >> Why does it have to be done by Seabios as opposed to Linux? It is easy
> >> to create a USB stick which would boot Linux compiled with permissions
> >> needed and with startup files which will program the new firmware image.
> >> This would be much easier to debug and modify when needed, right?
> > I think the idea is to provide flashing from within the boot flow. But
> > even then I wouldn't rely on SeaBIOS for that, but use libflashrom to
> > build a payload: SeaBIOS can load other payloads, as can GRUB2, so
> > that increases the potential user base of the flashing feature, and it
> > would be smaller than a disk image of a Linux that's put into flash
> > (which sounds rather convoluted to me).
>
> libflashrom and libpayload integrate very well. Actually that's what we
> do in the FILO payload. The upstream code is stale, though, and won't
> compile with current libflashrom. Let me know if you want to try that
> path (FILO is a pain to compile atm).
>
> Nico
>
___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] Coreboot Self-Flashing Through Payload?

[Matt B]

Hi,

I was helping a friend with a bios issue (we may have an involuntary
coreboot convert on our hands ;) ) and realized that a lot of BIOSs provide
a way for the BIOS to flash itself but Coreboot doesn't.

For Coreboot afaik the only two methods available are to flash with a
programmer or to flash internally from linux with iomem=relaxed. For most
proprietary BIOSs, you can boot a utility that knows what USB drives are
and flash from there.

What I'm thinking of trying, and would appreciate feedback on, is the idea
of making a Seabios floppy image specifically intended for flashing
Coreboot.

I figure this has a few advantages:
-It's OS-agnostic, meaning you can reflash the BIOS regardless of what you
boot into, or even if there's nothing to boot at all (without running to
grab some jumper cables)
-It means you don't have to fiddle with setting iomem=relaxed on your main
install and un-setting it when you're done (I don't fancy leaving it on all
the time)
-Some level of confidence that you can trust the flashing environment,
being as it's stripped down and purpose built, while also residing on the
flash itself

Might be a security advantage if flashing could be restricted to only this
pathway (and not say, through the main OS), but let's not get ahead of
ourselves.

I figure the easiest way would be to build a floppy image for seabios with
a kernel and a copy of busybox, with the bare essentials to find an image
on a usb drive and run flashrom. (maybe even a convenient shell script :P)
What I'm not sure on (not having built an install completely from scratch)
is what else those bare essentials might include.

Eventually something akin to (or included in?) LinuxBoot might be better,
integrating everything into a single payload and cutting out the dependency
on seabios.

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

[coreboot] Fwd: Supported Motherboards

[Matt B]

I need to pick a better email client, or remember to say "reply all"

-- Forwarded message -----
From: Matt B 
Date: Sun, Nov 25, 2018 at 2:59 PM
Subject: Re: [coreboot] Supported Motherboards
To: 


I also don't see "drop it and if someone likes it they'll work to get it
back to master" as being more than a band-aid solution. It doesn't do
anything to raise the probability of bad code getting dealt with, but it
does put the problem out of sight and out of mind.

The reason people who use this laptop are so resistant is that they see it
as a statement that the speaker doesn't care about fixing what's broken and
would much rather it just disappear. (regardless of who happens to be using
it) It's saying you want the other side just be quiet and go away, which
isn't constructive.

-Matt

On Sun, Nov 25, 2018 at 2:43 PM Matt B  wrote:

> Hi,
>
> It seems that whenever someone mentions the ME (or one of a number of
> other topics) the G505s is inevitably recommended, and people subsequently
> get into a debate over the relative badness of the ME vs atomBIOS/microcode
> ect. [1] This also leads to people lamenting the G505s for it's shitty
> AGESA codebase [2], and arguments over dropping boards like the G505s from
> master. If the thread gets really nasty, it gets into arguments over
> corporate influence of coreboot.
>
> But this cycle of arguments doesn't get us anywhere and the G505s code
> continues to languish. It hasn't been abandoned *yet* but it doesn't become
> any less likely that some new feature will lead to it getting dropped [3].
>
> I think this is tragic, since it's a still reasonably powerful laptop,
> probably took a lot of porting work, and has advantages over a lot of
> alternatives. [4] The fundamental problem seems to me to be that there are
> a hell of a lot of people who use G505s (seems very popular with people who
> run qubes), there haven't been a lot of people with the skill or
> inclination [5] to do the work required to put it on par with [insert
> favorite thinkpad]. The task of doing the cleanup or rewrite (whatever is
> required) may not be the most immediately attractive or productive task,
> but it seems like something that would make everybody a lot happier and
> eliminate a lot of arguing in the long run.
>
> Now, I may be a G505s owner, but I'm certainly not qualified to work on
> it's code. Rather than argue that "some developer"
> should, I'd like to propose something different. I think we should have a
> proper, technical discussion of what we want the G505s port to look like,
> what the best means to get there is (cleanup or rewrite, for example), and
> based on who wants to volunteer and who would be willing to do it under
> contract, figure out how much it would cost. Then we ask the people who own
> G505s or who want to see it improved to pony up the money to make that
> happen in a crowd-funding campaign, like any other open source software
> project would. [6]
>
> Then maybe we can firmly put this laptop on the list of  "great to use
> with coreboot" without this massive asterisk beside it.
>
> Sincerely,
> -Matt
>
> [1] It's interesting to note that there has been some recent movement on
> improving the atomBIOS situation a little bit. While I have a hard time
> imagining a future where all the drivers are patched to not need atomBIOSs,
> I can imagine a future where we compile and use open source
> re-implementations of existing atomBIOSs.
> https://www.phoronix.com/scan.php?page=news_item&px=Flashrom-AMD-SPI-Patches
> [2] For an example, look no further that is the current workaround for
> getting up-to-date microcode into these things, which I understand is borne
> in part from buggyness in AGESA microcode loading code
> [3] These rules are probably very reasonable, but I don't think there's
> any way that people won't read them as malicious in contexts like these.
> [4] To name a recent example, there are threads from this month that look
> like discrete GPU support will come in the immediate future, along with
> better support for variants with the A8 APU.
> [5] Empirically, since this still hasn't been done. No offense to anyone
> who's tried.
> [6] Inspired by the recent talk about offering funding to paulk to work on
> his open source EC firmware for the G505s.
>
>
-- 
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] 8GB graphics cards work on coreboot - in case anyone is wondering

[Matt B]

Hi,

One thing I just noticed about the page:
https://www.coreboot.org/Board:asus/kgpe-d16

Here "Crossfire XDMA" is listed as needing testing. If nobody has been able
to test this, and you (or someone else) has the opportunity this might be
an interesting thing to test.

After learning that this board can take a more modern CPU (family 15h) I'm
now considering it more strongly for a future computer. My K10 box is
*currently* mitigated against Spectre V2 (IBP disabled under CentOS via a
chicken bit) but I don't think it's wise to expect further mitigations to
be forthcoming from AMD should more bugs rear their ugly head. Moving up to
a family 15h CPU means getting updated Spectre V2-mitigating microcode and
a much more realistic expectation of support in the immediate future. I'll
probably even move up to piledriver (like the G505s I'm currently working
on), since a microcode patch will also fix the NMI issue (and I'll be
applying one to the stock microcode anyway).

I'd be really interested to learn if Crossfire and other features of modern
cards work on these older boards under coreboot, since they may come in
REALLY handy when running any machine learning loads on these boards.

On another note, does anyone have a favorite PSU for these boards?
Preferably something that will last a bit longer than crappy consumer gear?
This thing already requires two 8-pin connectors for a dual CPU setup, and
graphics cards demand them now too.

Sincerely,
-Matt



On Sat, Sep 1, 2018 at 4:15 PM Mike Banon  wrote:

> Taiidan, thank you very much for your valuable feedback! When I've
> been thinking of getting KGPE-D16 my main concern was that some high
> end GPUs wouldn't work for some reason and it was difficult to find
> any info... Luckily your RX580 doesn't have a Security Processor
> inside it ! Did you know AMD started putting this "security processor"
> crap into their GPUs also, starting with Vega? Hopefully RX line would
> be safe for a while, maybe I'd get RX680 when it comes out if it will
> not be tainted by this "security" :P Wish you to get a second nice
> Opteron one day
> On Sat, Sep 1, 2018 at 10:41 PM taii...@gmx.com  wrote:
> >
> > I was worried that it wouldn't work for some reason like due to lack of
> > 64bit MMIO in coreboot but I just installed an AMD Raden RX580 8GB on my
> > KGPE-D16 and it works great.
> >
> > I am playing the latest games on max settings in a VM with a GPU
> > bottleneck at 1080p with my single 6328 CPU...it is nice to finally have
> > good smooth gameplay with high fps.
> >
> > --
> > 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
>
-- 
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] Flashing Coreboot on Lenovo G505s

[Matt B]

I'm definitely interested in helping fund the Origami-EC's development.
I've been kicking around the idea of sending him an email on the subject
for about a month or two.

(not to mention, working open-source EC firmware could potentially benefit
a LOT of other x86 boards)

-Matt

On Sun, Sep 23, 2018 at 2:56 PM Mike Banon  wrote:

> Is it possible to crowdfund Paul's KB9012 Origami EC development?
> Judging by git code website he's busy working on Paper (if I
> understood correctly, a libreboot fork) and some side-projects, but
> hopefully he still has some interest in Origami. From paulk fr page at
> personal donations: accepting "bitcoin, bank transfer or credit card
> payment". Although maybe a 4th way of payments is possible:
> sending/ordering some hardware to Paul's address. Would be nice to get
> some comments from Paul regarding the cost estimates of completing the
> Origami, then we could think about splitting the development costs
> between us the G505S owners...
>
> Best regards,
> Mike Banon
>
-- 
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] Flashing Coreboot on Lenovo G505s

[Matt B]

Some additional origami info.

A talk from last year:
https://ecc2017.coreboot.org/uploads/talk/presentation/51/origami-ec-status-update-g505s.pdf
Some info in a thread from earlier this year:
https://mail.coreboot.org/pipermail/coreboot/2018-February/086107.html
The git repo: https://git.code.paulk.fr/gitweb/?p=origami-ec.git;a=summary

I haven't heard anything more up to date. It appears the author also has
his hands full with some (pretty cool) replicant work.

-Matt

On Sun, Sep 23, 2018 at 1:26 PM Matt B  wrote:

> Hi,
> I'm in basically the same situation, having just got a g505s. I'm looking
> at chronicling my experience on an ifixit article as I go, though I don't
> really have any time right now while in class. Right now the winter break
> looks most likely for some serious coreboot fun.
>
> Sadly, the ebay seller sent me a G505s without discrete graphics chip when
> one with a chip was advertised. All things considered though, the machine
> is in really good condition and the discrete graphics chip afaik doesn't
> work in coreboot (yet) and has to be disabled to boot successfully (that
> and crossfire never caught on) so I'm not too broken up about it. Still if
> it ever is supported properly, it might make a nice machine learning
> accelerator even if crossfire graphics never gets good support. (and there
> are tempting replacement boards for 60 bucks available should I get
> adventurous.)
>
> As for your questions:
> A) I would have thought pi would work, though I haven't looked at all into
> the flashing procedure yet
> B) I would back up the factory image SEVERAL times and compare them to
> make sure they're the same before doing anything
> C) See above answers. idk on this, haven't got there yet
> D) Flash with factory EC firmware. Origami is an *amazing* project, but
> it's still going to be a bit before even "just boots the board" is possible
> E) There was something a long time ago about using HVM (hardware
> virtualization) causing Qubes to freeze on the G505s under coreboot. I
> don't know if it was ever resolved or could even be reproduced. I think at
> the very least you want to have the most up-to-date microcode patch to fix
> a RANGE of issues (irq privilege escalation, IOMMU bugs, proper spectre V2
> mitigation, ect.) with the stock microcode that's burned into the CPU.
>
> Speaking of microcode, I've seen on other threads that the microcode has
> to be manually updated for some boards, and for the g505s this is
> especially complicate with many manual steps. Can anyone provide a more
> explicit series of steps than the below? Is this something being worked on?
>
> Regarding a NOTE from your last message:
>> > For microcode embedding in coreboot to work you must check
>> > both the "generate microcode update from tree" option and the
>> > "use non-free blob repo" option -
>> > doing the first but not the second will result in a silent fail.
>> It works for KGPE-D16 but doesn't work for G505S and maybe some other
>> AMD boards. Currently the only working way for those "other boards" to
>> get the latest microcodes is to " xxd -i -c 8 " a microcode binary and
>> then put this array of hex values into their .c file containing a
>> microcode ( path like [1] ) . Tired of doing this manually, yesterday
>> I wrote these microcode updating scripts :
>> https://review.coreboot.org/c/coreboot/+/28425
>> AMD microcodes: scripts for applying the unofficial (not-merged-yet)
>> updates
>> Put those 4 files to your freshly cloned coreboot directory,
>> run ./get_ucode_patches.sh , ./check... and ./apply... ,
>> and your fresh coreboot now has the latest microcodes ;-)
>> But thats only for those "other boards" like G505S. To get the latest
>> microcode for your KGPE-D16, you may also need to patch its'
>> microcode_amd_fam15h.bin with a new 2018 microcode which sadly is not
>> merged yet neither to linux-firmware nor to coreboot
>> [1] example of a path to .c file with microcode -
>>
>> ./coreboot/src/vendorcode/amd/agesa/f16kb/Proc/CPU/Family/0x16/KB/F16KbId7001MicrocodePatch.c
>
>
> That's from this thread here:
> https://mail.coreboot.org/pipermail/coreboot/2018-August/087279.html
> There are also instructions in this thread, that I can't make sense of:
> https://mail.coreboot.org/pipermail/coreboot/2018-August/087150.html
>
> Sincerely,
> -Matt
>
> On Sun, Sep 23, 2018 at 10:09 AM awokd via coreboot 
> wrote:
>
>> Anac:
>> > Greetings
>> >
>> > Following various recommendations on Lenovo G505s, I finally got myse

Re: [coreboot] Flashing Coreboot on Lenovo G505s

[Matt B]

Hi,
I'm in basically the same situation, having just got a g505s. I'm looking
at chronicling my experience on an ifixit article as I go, though I don't
really have any time right now while in class. Right now the winter break
looks most likely for some serious coreboot fun.

Sadly, the ebay seller sent me a G505s without discrete graphics chip when
one with a chip was advertised. All things considered though, the machine
is in really good condition and the discrete graphics chip afaik doesn't
work in coreboot (yet) and has to be disabled to boot successfully (that
and crossfire never caught on) so I'm not too broken up about it. Still if
it ever is supported properly, it might make a nice machine learning
accelerator even if crossfire graphics never gets good support. (and there
are tempting replacement boards for 60 bucks available should I get
adventurous.)

As for your questions:
A) I would have thought pi would work, though I haven't looked at all into
the flashing procedure yet
B) I would back up the factory image SEVERAL times and compare them to make
sure they're the same before doing anything
C) See above answers. idk on this, haven't got there yet
D) Flash with factory EC firmware. Origami is an *amazing* project, but
it's still going to be a bit before even "just boots the board" is possible
E) There was something a long time ago about using HVM (hardware
virtualization) causing Qubes to freeze on the G505s under coreboot. I
don't know if it was ever resolved or could even be reproduced. I think at
the very least you want to have the most up-to-date microcode patch to fix
a RANGE of issues (irq privilege escalation, IOMMU bugs, proper spectre V2
mitigation, ect.) with the stock microcode that's burned into the CPU.

Speaking of microcode, I've seen on other threads that the microcode has to
be manually updated for some boards, and for the g505s this is especially
complicate with many manual steps. Can anyone provide a more explicit
series of steps than the below? Is this something being worked on?

Regarding a NOTE from your last message:
> > For microcode embedding in coreboot to work you must check
> > both the "generate microcode update from tree" option and the
> > "use non-free blob repo" option -
> > doing the first but not the second will result in a silent fail.
> It works for KGPE-D16 but doesn't work for G505S and maybe some other
> AMD boards. Currently the only working way for those "other boards" to
> get the latest microcodes is to " xxd -i -c 8 " a microcode binary and
> then put this array of hex values into their .c file containing a
> microcode ( path like [1] ) . Tired of doing this manually, yesterday
> I wrote these microcode updating scripts :
> https://review.coreboot.org/c/coreboot/+/28425
> AMD microcodes: scripts for applying the unofficial (not-merged-yet)
> updates
> Put those 4 files to your freshly cloned coreboot directory,
> run ./get_ucode_patches.sh , ./check... and ./apply... ,
> and your fresh coreboot now has the latest microcodes ;-)
> But thats only for those "other boards" like G505S. To get the latest
> microcode for your KGPE-D16, you may also need to patch its'
> microcode_amd_fam15h.bin with a new 2018 microcode which sadly is not
> merged yet neither to linux-firmware nor to coreboot
> [1] example of a path to .c file with microcode -
>
> ./coreboot/src/vendorcode/amd/agesa/f16kb/Proc/CPU/Family/0x16/KB/F16KbId7001MicrocodePatch.c


That's from this thread here:
https://mail.coreboot.org/pipermail/coreboot/2018-August/087279.html
There are also instructions in this thread, that I can't make sense of:
https://mail.coreboot.org/pipermail/coreboot/2018-August/087150.html

Sincerely,
-Matt

On Sun, Sep 23, 2018 at 10:09 AM awokd via coreboot 
wrote:

> Anac:
> > Greetings
> >
> > Following various recommendations on Lenovo G505s, I finally got myself
> > a A10-5750M with dedicated GPU. At least I think it has dedicated
> > graphics, due to the following output:
> >
> > # inxi -G
> >
> > Card-1: AMD Richland [Radeon HD 8650G]
> > Card-2: AMD Sun Pro [Radeon HD 8570A/8570M]
> >
> > While waiting for some AliExpress deliveries, I'd like to ask a few
> > questions that worry me. I have never flashed anything, but I'm used to
> > Linux, the command line and soldering.
> >
> > A)
> > According to
> > http://dangerousprototypes.com/docs/Flashing_a_BIOS_chip_with_Bus_Pirate
> > either a Bus Pirate or a CH341A programmer is needed for flashing
> > CoreBoot. LibreBoot folks can just take a Raspberry Pi (or better a
> > Beagle Bone Black) and a SOIC clip, while CoreBoot needs more equipment.
> > Why is that?
> > Somewhere it reads that the CH341A was faster than BusPirate. But is it
> > faster than a Raspi or BeagleBone?
> > Btw. Flashrom does in fact support RaspberryPi:
> > https://www.flashrom.org/RaspberryPi
> >
> > The reason for asking is because I really don't want to brick anything
> > and/or destroy the G505s. And I don't know how to operate a CH341A and

Re: [coreboot] When does AMD release the fam15 spectre microcode updates?

[Matt B]

Hi,

My deepest apologies if this doesn't show up in the right spot, despite
editing the subject. I'm a dummy and I'm switching off digest mode right
now.

I'm no expert on microcode but I'll share my personal stance which I think
is pretty reasonable and practical. As the saying goes, the best way to ask
a question on the Internet is to give the wrong answer. :)

For some context, see:
https://lwn.net/Articles/744818/

My understanding of microcode, both from what I've read and what I've
studied is that it is or is more analogous to the contents of one or more
state tables, for state machinery in the CPU, and most useful for handling
complicated functionality (like a multi-word copy). (the actual details are
probably a hugely proprietary secret)

I seems to me that most people hear the 'code' part of 'microcode' and
assume it's a huge compiled binary blob running on a general-purpose
processor, and can do just about anything and attacker could possibly want.
I wrote this sentence, then then realized that everyone knows that's what
the IME is for. ;D

Do I expect you could introduce a very subtle security vulnerability with
it? Absolutely. The spectre microcode patches effectively do the reverse of
that.

Do I worry about that too much? Not really. My reasoning is that it would
be equivalent to introducing it in the in-silicon architecture of the CPU,
and that's already something we *assume* Intel/AMD/ect don't (or shouldn't,
for practical/legal/moral reasons) do. We can talk about silicon poisoning
later over (preferably alcoholic) beverages.

Do I think that this has any bearing on whether you should install
microcode patches? Not really, no. Microcode patches are (typically)
created to fix some specific errata. You could make some argument that they
also provide the opportunity introduce/remove some vulnerability, since
they can't really be inspected that well (or at all), but I refer you to #2.

Since they typically exist to fix some (sometimes serious) errata I install
them as a matter of "best security practice" like I do for innumerable
software updates.

Note that all of the above is purely from a practical stability/security
perspective. Proprietary IP (code and otherwise) permeating everything we
use at a deep level is also a huge moral issue (or so I am repeatedly told
:D), it's just that I tend to focus on the practical aspects/implications.

That said, even if you have stronger free-software moral fortitude than me
[1], I can't fathom why you wouldn't install a microcode patch. You're free
to abstain, but I would *mostly* equate running a CPU with unpatched
microcode with running one that's patched. I say mostly, because I consider
the patching to be small potatoes, especially compared with, say, not
infecting your friends with a virus that exploits a significant errata. (I
won't say more on this though, since I've probably already just ensured a
"lively" ethics debate. I just want the option to load the damn things.)

Don't get me wrong, for both moral and practical reasons I would love more
than anything to be using a 100% open computer. But I would have to not
ignore hardware in that, especially if we count microcode. I don't think we
can expect Intel/AMD/ect to release the complete design of *any* CPU since
at least the Z80, and that still may not do anyone any good if they're the
only ones making them. I think the best we can look forward to on that
front right now right now is RISC-V hitting silicon from a variety of
manufacturers. I recently saw their dev board running youtube videos, so
that looks promising.

[1] I will, on occasion, use N-F software *Gasp!* that's convenient *Gasp!*
and from sources I sufficiently trust in contexts where that trust is
sufficient.

Sincerely,
-Matt

On Thu, May 24, 2018 at 6:00 AM,  wrote:

> Message: 8
> Date: Wed, 23 May 2018 22:37:47 +0100
> From: Andrew Luke Nesbit 
> To: coreboot@coreboot.org
> Subject: Re: [coreboot] When does AMD release the fam15 spectre
> microcode updates?
> Message-ID: 
> Content-Type: text/plain; charset=utf-8
>
> On 23/05/2018 20:55, ron minnich wrote:
> >
> >
> > On Wed, May 23, 2018 at 12:54 PM Rudolf Marek  > > wrote:
> >
> > Hi all,
> >
> > Dne 22.5.2018 v 07:03 taii...@gmx.com 
> > napsal(a):
> >
> >
> > > don't they have those in this update? Would it be possible to
> > easily add
> > > the support flags without microcode for those who use libreboot?
> >
> > So libreboot guys don't want any fixes for a CPU?
> >
> >
> > I've been wondering about this. IIRC the original motivation for the
> > libreboot fork was microcode.?
> > Is microcode still out of bounds for libreboot?
>
> I don't know if the original motivation still applies.  This is an
> important discussion to have.
>
> I've pinged the folks in #libreboot and #vikings on Freenode to alert
> them to this discussion.  There are probably other relevant channels
> I've mis