[coreboot] Re: 2023-08-23 - coreboot Leadership meeting minutes

[Peter Stuge]

Hello Hannah,

Williams, Hannah wrote:
> Already there are binaries FSP, AGESA, PSP being used in Coreboot

We consider this historical problems in the coreboot project and it
is absolutely not something we intend to lean into. Since you have
a mandate to work with coreboot I guess you are onboard with this,
after all, our culture is inherent to our project.


> and because of IP and licensing issues everything cannot be open sourced.

I consider this a temporary problem for Intel that it needs to solve
to avoid losing future business to competing, open source solutions.


> This is the fastest method for this specific product

Since coreboot isn't owned by Intel I'm afraid Intel has to accept
that the request gets denied by coreboot.

I guess you can understand that coreboot has no incentive to make
further compromise that would really only benefit Intel and actually
hurt coreboot.


> binary rule (by the way where is this stated in coreboot.org?).

Do you really not understand the spirit of open source and what
coreboot is doing since more than 20 years? I guess you do but that
you need a reference to something written for some silly higher-ups. :\


> We will also work closely with our other open source Linux graphics
> team to see how we can leverage common code for future Silicon. 

This is a good idea. Maybe libgfxinit could even become the primary
codebase at some point. In any case it's just silly to duplicate work
at all, including for i915+GOP.


Kind regards

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

[coreboot] Re: Legacy OS Support

[Peter Stuge]

Mason McAlister wrote:
> any idea when Legacy OS/BIOS support is coming to Coreboot?

To coreboot itself probably never but you can use SeaBIOS as payload
to get a BIOS environment that will boot Windows, if the ACPI tables
created/delivered by coreboot for the mainboard are correct.


> it'd just be cool if i could get windows XP or windows 7 on a chromebook.

Should work as long as ACPI tables are correct, I would expect
Chromebooks to have fairly good ones.


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

[coreboot] Re: How to best handle new Intel Saphire Rapids server boards based on Intel Archer City?

[Peter Stuge]

ron minnich wrote:
> And, yes, no question, this is an activity that likely occurs less than it
> should. Such is our industry.

Such is project policy. Maybe because it's the lowest common
denominator in industry.


> It is not possible to know, a priori, what those common pieces will be.

I think this is where we fundamentally disagree. I think common
pieces and their interfaces can be recognized based on the hard
IP blocks and their interfaces plus some creative thinking based
on development experience.

That working really well requires supportive silicon vendors. AMD is
in a good position to lead by example here. ;)


> There is the further risk (this has happened) that a seemingly harmless
> change is discovered to break some board, 1.5 years later. This has
> happened. To me.

Regression testing and release engineering are for sure important for
anyone delivering firmware updates to customers.


> As has been pointed out, always in motion, the future is.

Interesting times!


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

[coreboot] Re: How to best handle new Intel Saphire Rapids server boards based on Intel Archer City?

[Peter Stuge]

(sorry if you receive this twice)

David Hendricks wrote:
> it will be easier to refactor portions of the code with the large
> patches merged in a buildable and (hopefully) usable/testable state.

That's pretty weak sauce and I think you all know deep down.

Who pays for refactoring? Probably someone else.

That's unsustainable for the project.

It externalizes refactoring cost from those creating the initial
mainboard ports but that's not how any platform code can grow
into something well-engineered and versatile.

One can certainly argue that well-engineered is just too costly for
our community to strive for but while that does seem the prevailing
group think I have to say I would consider it a sad resignation.


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

[coreboot] Re: 440BX meminit changes testing

[Peter Stuge]

Keith Hui wrote:
> I'll keep you guys (including anyone watching on the mailing list) posted.

Thanks a lot. I appreciate reading along!


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

[coreboot] Re: Quick question for Kconfig lint checking

[Peter Stuge]

Prajapati, Pratikkumar V wrote:
> Any recommendation to achieve this in a clean way?

In case you don't find a good way then please at least ensure a build
error with a meaningful error message for invalid configurations.


Thanks

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

[coreboot] Re: Unable to get S3 resume to work on new port

[Peter Stuge]

Kevin Keijzer via coreboot wrote:
> I found the issue. 3VSBSW# had to be enabled for S3 resume to work.
> 
> It ended up being a oneliner fix in devicetree.cb:
> 
> device pnp 2e.a on
> + irq 0xe4 = 0x10 # + enable 3VSBSW#

Good find!

Can you please push a commit with the fix to gerrit?


Thanks

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

[coreboot] Poettering@MSFT on the future of secure booting Linux

[Peter Stuge]

https://0pointer.net/blog/brave-new-trusted-boot-world.html

"Proposed Construction

Central to the proposed design is the concept of a Unified Kernel Image (UKI).
These UKIs are the combination of a Linux kernel image, and initrd, a UEFI
boot stub program (and further resources, see below) into one single UEFI
PE file ... "

Good bye grub, hello UEFI lock-in.


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

[coreboot] Re: Trouble building coreboot early stages

[Peter Stuge]

Hi Gabriel,

Gabriel Malaspina wrote:
> I'm using openSuSE 15.4. I didn't think there'd be a problem with this 
> particular distro, but I installed Ubuntu on a VM nevertheless. 
> Instructions from the tutorial worked *without a single problem*.
> 
> Unless advised otherwise I'll carry on using Ubuntu to compile coreboot, 
> but if anybody here comes up with an attempt to make it work on 
> openSuSE, please fell free to contact me and I'll give it a try.

There is significant value in the knowledge needed to build across
different distributions so hopefully that can be gathered by some
further testing.

The good news is that your build seems to be almost at the end; it
looked like libpayload couldn't be found by the coreboot toolchain
in the (late) linking step. It would be interesting to know how you
installed libpayload on OpenSuSE, especially anything you did
different on Ubuntu.


Thanks

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

[coreboot] Re: Reducing Jenkins workload

[Peter Stuge]

Felix Held wrote:
> The additional workload for Jenkins is my main concern here

I understand that it is helpful to make also quite long patch trains
with multiple "topics" visible in Gerrit early, for context and for
discussion.

I had an idea today:

What if Jenkins does not build until human has given +2 ?


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

[coreboot] Re: ASUS P8ZZ7-V i7-3770 >16GB RAM: SPD CRC failed

[Peter Stuge]

Nico Rikken wrote:
> I tried a a different motherboard with the same RAM DIMMs and that
> worked just fine. So it seems to be related to the motherboard. I still
> have the malfunctioning motherboard, so perhaps I'll do some debugging
> in the future.

Do you have access to an oscilloscope or a (simple) logic analyzer,
something like a Saleae Logic or even a basic Cypress CY3689
discovery kit, that can be used with sigrok?

It would be interesting to know what the SPD signals look like and also
what bytes coreboot reads from the DIMMs on the problem board.


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

[coreboot] Re: search_isolinux usb

[Peter Stuge]

Hey Geert,

Geert Stappers wrote:
> When I active menu entry 'Search ISOLINUX menu (USB)', which has grub
> command 'search_isolinux usb', screen goes shortly black and then
> the main grub menu re-appears. As if the coreboot payload grub wants to
> tell "nothing found".
..
> What to do to make coreboot grub accepting USB image?

There are two ways forward, but neither actually involves coreboot itself:


1. Debug your grub

For this, please get in touch with the grub community, and remember to
make clear that you're using grub on coreboot, not grub with a BIOS.


2. Use a SeaBIOS payload instead of grub

SeaBIOS is an open source BIOS implementation that can be built as
coreboot payload, is known to boot well from USB and can additionally
also boot other coreboot payloads (which you could use to start grub).


Replacing the payload requires changing the contents of the boot flash
on your mainboard, possibly to contain a SeaBIOS payload that you
built yourself. This alternative may or may not be practical for you.


In any case, coreboot is not involved in booting the operating system
and that is on purpose. This task lies with the payload, so once the
payload is running successfully you have to investigate the payload,
not coreboot. I hope that makes sense. :)


Kind regards

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

[coreboot] Re: Reconsidering the Gerrit submission strategy

[Peter Stuge]

Felix Held wrote:
> I can let other developers with submit right try out the new submit
> strategy and not submit anything that's not directly related to
> what I'm working on right now.

I want to apologize if it seemed that I asked you to hold back on any
effort, especially some not directly related to day-to-day tasks, I
did not mean anything like that.

I understood Martin's point to be that you spend a lot of time
working with Gerrit so have great insight, which I agree with.

That said, of course it would be great if more developers try the
new submit strategy and see how they feel about it.


> At least for me getting all patches with just checking out the last 
> commit isn't the reason why I occasionally push rather long patch 
> trains. For me the reason is that for example when adding support for a 
> new SoC there will be mostly short patch trains for different unrelated 
> features, but pushing those different short patch trains isn't a good 
> option, since despite working on different features there will be a lot 
> of merge conflicts between the different short branches, especially in 
> the Kconfig and Makefile.

Nod, that's very understandable. For this, do you think it could work to
not push everything at once, but only one "topic" at a time?

In the local repo it would be still be one long series of commits,
but each "topic" could have its own branch name locally, although
there is no branch in the commit graph. A bit like using tags, but
with branch names so that rebase works well locally.

The workflow would then be to push the first "topic" (short patch train)
to Gerrit, have that enter master, pull and then rebase the following
local branches onto master, push next "topic" and so on.

This has both benefits and drawbacks; a benefit is that there are
more frequent but much smaller patch sets to review, a drawback is
that each patch set requires one "Gerrit turnaround" which for a
large project could take a while.


> The additional workload for Jenkins is my main concern here although 
> it's also a bit annoying to need to do the extra rebases.

This would be mitigated by only pushing smaller patch sets at a time.


> the submit together with previous patches button on the last
> submittable patch in the train should be used to not need to rebase 
> most of the patches after the previous patch got submittet, the rebases 
> might not be as much of a problem than I initially thought.

That's a good point - but that only applies to the "perfect patch set"
case, right? It's cool if we can optimize that but I wouldn't want to
make things a lot worse for patch sets needing some turnarounds.


> I hope that writing about the things I ran into might help others
> to not run into those themselves.

Thanks a lot for that!


Kind regards

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

[coreboot] Re: Reconsidering the Gerrit submission strategy

[Peter Stuge]

Martin Roth via coreboot wrote:
> If we continue with this method (and for the rest of this month), I
> think we want to encourage shorter patch trains, consisting of only
> related patches.

Ouch! Yes please, for sure, regardless of the submit strategy.


> Currently, it seems like projects will occasionally build up
> enormous trains of patches that aren't necessarily related so that
> they can pull all of their patches at once just by grabbing the last one.

I can understand such a desire, it does simplify things for the
pushing developer and their testers, but then that shouldn't be
done in upstream Gerrit.

I guess for contributors who can only commit lots of unrelated
changes to a single internal branch (e.g. because they don't use git
internally) would have an extra TODO in the export to git commits. :\

It's of course unfortunate to require that extra work but I find the
benefit for the community significant!

The different "topics" in that train of commits become directly
visible and can receive individual outside engagement much easier.
I think that's unlikely to happen with commits in the middle of a
long branch.

On a personal note I find unrelated commits in a branch quite
confusing, others can of course be different there! :)


> It also sounds like rebasing all of the patches so that the entire
> train is contiguous is really needed - no more patches based on
> older versions of the previous patch.  I think the same is true for
> abandoned patches - rebase everything so that the patch train isn't
> broken in the middle.

May be - but that shouldn't be too bad?

I agree that it would be great for Jenkins to recognize when new
commits are effectively unchanged since last test so that many
"rebase builds" can be skipped but I don't have a great suggestion
for how to make it happen. Sorry. :\


Kind regards

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

[coreboot] Re: Reconsidering the Gerrit submission strategy

[Peter Stuge]

Felix Held wrote:
> > Maybe the patch train is too long if it becomes hard to keep an overview?
> 
> I'd say that it always better to have to look at all the individual 
> patches instead of just looking at the bigger picture

I agree completely, and don't want to suggest otherwise!

By "keep an overview" I mean to know which commits in a pushed branch
that have been reviewed and which not.


> > If you have pushed a branch with 3 commits, use interactive rebase
> > locally to fix up the middle commit and then push the branch again,
> > doesn't Gerrit always recognize that the first commit remains
> > unchanged, ie. with one generation less than the middle and last commit?
> 
> To reduce unnecessary load on the build servers, it has become common 
> practice to only push up to the changed patch and not the patches after 

I don't understand this at all..?

I'm all for skipping unneeded build load, but pushing only commits 1
and 2 in my case would still create build load (because commit 2 is
new), right?

Later pushing 3 will also always create build load, because that too
is a new commit.

What am I missing here?


> that if the changes if the fixes are unrelated and there's more than 
> maybe one patch after the one being updated.
..
> > If the patches aren't actually linked (ie. can be submitted individually)
> > then I think they shouldn't be pushed as a single branch, right?
> 
> Yes, but that's not the case I tried to outline;

Hm, but "fixes are unrelated" seems to describe exactly this case?



Felix Held wrote:
> I reread the documentation and the thing I missed in there is that 
> Gerrit will only automatically rebase a patch when submitting when none 
> of the files it changed have been changed between the parent commit of 
> the to be submitted patch and the current top of tree.

That seems like an improvement to me. By the way, I don't think Gerrit
has ever actually rebased anything, nor will it with the new setting,
I understand it to always do an equivalent of "git cherry-pick" but
with different requirements with the new strategy.


> This makes both treewide changes and submitting patch trains patch
> by patch more difficult.

Hmm, how so? Submitting one commit at a time should make top of tree
always match the parent commit of the to-be-submitted commit, right?


Kind regards

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

[coreboot] Re: Reconsidering the Gerrit submission strategy

[Peter Stuge]

Felix Held wrote:
> I definitely want to submit a patch train patch by patch and not just
> the last submittable patches including all patches before to make sure
> that I looked at each individual patch when submitting.

Maybe the patch train is too long if it becomes hard to keep an overview?


> When part of a patch train gets re-pushed due to some small fixes that 
> won't affect patches after a certain patch and then all patches from the 
> patch series are reviewed and submittable, how will the case that later 
> patches are on top of outdated patches be handled?

Hmm, I don't understand what you mean here..

If you have pushed a branch with 3 commits, use interactive rebase
locally to fix up the middle commit and then push the branch again,
doesn't Gerrit always recognize that the first commit remains
unchanged, ie. with one generation less than the middle and last commit?


> Previously the latest version of each individual patch was used
> which is the correct behavior,

If the patches aren't actually linked (ie. can be submitted individually)
then I think they shouldn't be pushed as a single branch, right?


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

[coreboot] Re: Custom coreboot installer and license

[Peter Stuge]

Hi Felix,

Felix Freeman via coreboot wrote:
> I'm just a few days ahead of the official opening of an online store
> that will sell corebooted laptops in Chile.

That's cool.


> As far as I understand I'm just using a software in a separate program,
> not linking nor intending to distribute derivatives of coreboot project
> programs under other license.

You can not get qualified legal advice applicable to your particular
jurisdiction from the coreboot mailing list.

That said, I think the key question in your case is whether your
work can be considered a derivative work of coreboot or not.

Personally, I don't think a derivative work is limited to coreboot+patches;
I understand it to be a broader concept that *would* include works like
yours.

GPL allows you to do whatever you want "at home" as long as you don't
distribute to others, so maybe that's a practical solution for you -
but it's not really open, which I guess is a USP for your business.

Please use a known compatible license instead... :)


Kind regards

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

[coreboot] Re: Reconsidering the Gerrit submission strategy

[Peter Stuge]

Felix Held wrote:
> Having a commit queue or even running a build test for every patch 
> before it gets submitted would catch more breakages before the patches 
> land in the tree than switching to the new submit strategy,

Hmm, I'm not sure about that? I understand the effective difference
with the new strategy to merely be that a later commit in a pushed
changeset/branch can't be submitted before an earlier one. I think
each commit is still build tested and verified?

And different pushed changesets continue to be build tested
individually and can be submitted individually - right?

Hmm, what happens when commit 1/2 in changeset 1 is submitted and
someone then wants to submit commit 1/2 in changeset 2 before the
other commit in the first changeset? Let's try in August I guess. :)

I'm sure the change could be rolled back quickly in case there's any
kind of annoying disaster problem in the repo.


Kind regards

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

[coreboot] Re: Intel Quark - a quick update

[Peter Stuge]

ron minnich wrote:
> At some point, you're going to find code changing out from under you;

I find that obnoxious.

I understand that you Ron are *not* saying that *you* will change
code from under Andy but I find the embracing/accepting of non-
compatibility and lack of longevity toxic.

I am not naive; yes it can happen, and I agree that it's okay, even
important to talk about that, but I also think it's important to
consider each time it happens a failure.

For me, longevity is a major reason to invest into free and open source
software. It's quite ironic that Win32 is the best example by far! :)


Kind regards

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

[coreboot] Re: Reconsidering the Gerrit submission strategy

[Peter Stuge]

Patrick Georgi via coreboot wrote:
> I was recently made aware that Gerrit now supports adding metadata to
> commit messages in the "rebase" strategy.

That's cool!


> It's a matter of trade-offs, but given that "rebase always" can now add the
> metadata that was the deal breaker for anything but cherry-pick back in the
> day, I wanted to know how y'all feel about changing or keeping the
> submission strategy.

I find the benefits quite desirable.


> David proposed that we could try out "rebase always" for a while (maybe a
> month) to see how it feels.

Good idea!


Thanks

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

[coreboot] Re: Cisco Meraki use coreboot in some MX products and will not provide the source code

[Peter Stuge]

This is discussion based on experience and reading comprehension, not
legal advice.

Hal Martin wrote:
> As coreboot is GPL licensed software, I wanted to inform the coreboot
> community that I believe Cisco Meraki are not acting in good faith and are,
> in my opinion, violating the GPL by not providing the coreboot source code
> upon request.

Thanks for the heads up, but this is primarily actionable by yourself.

Whether in good faith or not (noone can know and it doesn't really
matter) your supplier should of course comply with the GPL and
provide you with the source code that you have a right to receive.

Remember that you may be the only one who has received a specific binary
(we can't really know) and therefore you may also be the only one who
has the right to receive corresponding source code.

Others - including the coreboot project and/or the Software Conservancy -
don't per se have the particular right to receive source code that you
have, that would only be the case if they've also received the same binary.

The coreboot project uses GPL so that at least someone (you!) has a
right to receive source code.

Once you've received it you can also choose to contribute it into
coreboot, because GPL applies.

(Whoever may own the copyright matters little as long as GPL applies.)


See also gpl-violations.org, an organization that could successfully
achieve GPL compliance (this is the goal, not public shaming) in a
number of high profile cases over the course of several years:

https://www.gpl-violations.org/faq/violation-faq/


Kind regards

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

[coreboot] Re: I may have misconfigured my Coreboot ROM, what did I do wrong?

[Peter Stuge]

Hi Tristan,

Tristan Young wrote:
> fixed it by flashing my previous Coreboot BIOS

Great job - well done!


> Should I send my .config file so that you can tell if any of the config
> settings or combinations of them that I chose wouldn't work on my specific
> model of ThinkPad?

You can send the config but don't expect that someone else will
analyze your problem.

Ideally, please instead investigate this yourself and share your
findings (also along the way if you like) - if you can arrive at a
clear conclusion then there is at least some possibility that someone
else improves the code in case that makes sense.


Kind regards

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

[coreboot] Re: Open letter regarding a more open FSP codebase

[Peter Stuge]

coreboot org wrote:
> Subrata has written a fantastic proposal for a plan to reduce the work
> done by the Intel FSP, and transition that work into open source
> implementations.[1]

While that's worthwhile for legacy platforms, I feel that the vastly
more important objective re. Intel is to not allow UEFI and/or USF to
be forced into RISC-V.

https://www.theregister.com/2022/05/17/intel_riscv_contributions/


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

[coreboot] Re: Will coreboot work on my machine? DELL XPS m1330

[Peter Stuge]

Mateusz Kolbusz wrote:
> c) Processor: Intel(R) Core(TM)2 Duo CPU T5800 @ 2.00GHz

This CPU generation is well-supported.

> d) Bridge: Mobile PM965/GM965/GL960 Memory Controller Hub

AFAIK the 965 chipset is not at all supported.

I'm not sure but I believe the 64-bit 965 to be relatively similar to
the well-supported 32-bit 945 chipset, so pursuing this would perhaps
only require moderate reverse engineering effort. It's not the
absolute worst case but still takes at least some months of effort
with an all-too-rare skillset. It may not be worth that much time out
of your life.


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

[coreboot] Re: Systems that use coreboot

[Peter Stuge]

Valerii Gugnin wrote:
> What are the most popular systems on which coreboot is typically used?

I guess that's the various Chromebooks, all of which ship with coreboot.


> What mainboards, southbridges, SoCs etc do these systems use?

Chromebook (and related) reference mainboards live under mainboard/google/
in the codebase, but note that those are just that, reference designs.

>From these reference designs OEMs that you may already know
(Lenovo, HP, etc.) then create products which may (or may not!) have
a subdirectory of their own under mainboard/lenovo/.

Then please refer to the source code for the components used, since
that's a long list. Look at the Kconfig file (it's just a text file)
in the subdirectory for a mainboard and you'll see which different
components that board uses, in select SOUTHBRIDGE_.. etc. lines.


> What is the most used part of code (for which system) in coreboot?

A core design principle of coreboot is to maximize code reuse across
as many systems as possible. This is in contrast to common practice
among commercial IBVs where a single full codebase per mainboard is
not uncommon.

So I'd like to answer this your question with "almost everything for
all systems" but in reality some code is central and other is not.

Code in {console,device,lib}/ is explicitly generic so that should
have the largest coverage.


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

[coreboot] Re: Document branch boards [was: Quark deprecation]

[Peter Stuge]

Martin Roth via coreboot wrote:
> https://review.coreboot.org/c/coreboot/+/63797

This is great!

Do you think we can generate the table for each branch from Kconfig
select MAINBOARD_SUPPORTED_ON_BRANCH_* automatically on releases?

Initially I also had a concern that maybe column width would need to
increase over time but these branch tables will only ever have lines
removed, never added to, so no problem.


Kind regards

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

[coreboot] Re: Kconfig branch boards [was: 2022-04-20 minutes]

[Peter Stuge]

Hi Martin,

Martin Roth via coreboot wrote:
> https://review.coreboot.org/c/coreboot/+/63754
..
> It's not a complete solution, but hopefully it's seen as a step in
> the right direction.

Thanks a lot for this.

I think that this really helps with visibility while guiding people
at the same time. Great idea!


I have some comments: (apologies for not using gerrit)

* Managing expectations

"Run the command 'git checkout $(CONFIG_MAINBOARD_BRANCH)' to build this board."

The git command doesn't build anything, so maybe ".. to switch branch."
or ".. first and then re-run Kconfig to set up your board." or somesuch?


* Most of src/Kconfig now seems excluded for branch boards, maybe:

if MAINBOARD_SUPPORTED_ON_BRANCH
source "src/mainboard/Kconfig"
source "site-local/Kconfig"
else
# everything
endif

rather than multiple if-endif statements is less confusing? (Yes, the
duplicated source lines aren't great, but maybe okay for two lines?)


* Branch names

Newer git branch names look like "4.11_branch" so src/Kconfig and
Kconfig.branch saying "(supported on 4.11 branch)" could really trap
people, especially with "4.11" being a valid git tag.

But including the branch name also in the bool description is already
redundant and could conflict with select _ON_BRANCH_*.

I really like the comment idea in src/Kconfig to connect _ON_BRANCH_*
configs with the branch name only in a single place!

Do you see any way to avoid all the "(supported on * branch)"
instances, while still making the information available in the vendor
menu? Hmm.


* Having both Kconfig.name + Kconfig.branch

The idea is for SHOW_BRANCH_SUPPORTED_PLATFORMS to gate board
visibility in Kconfig for "forward-movers", right? (Maybe name
it _SUPPORTED_BOARDS btw.?)

IIUC the "if SHOW_BRANCH_SUPPORTED_PLATFORMS" logic would need to
sometimes go into Kconfig.name (all boards on branches) and other
times into Kconfig.branch (only some boards on branches), that seems
a bit fiddly.

Might it be better to only use Kconfig.name and not introduce a new
Kconfig.branch?

And maybe it would even be better to introduce this
SHOW_BRANCH_SUPPORTED_PLATFORMS in a commit of its own?


Thanks again and kind regards

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

[coreboot] Re: Intel Quark - a quick update

[Peter Stuge]

Andy Pont wrote:
> As soon as they get here I will start testing the various configs
> to see what works and what is broken.

Many thanks to you and everyone who helped make this happen!


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

[coreboot] Re: Get Coreboot version and build details in linux.

[Peter Stuge]

Putsala Amar via coreboot wrote:
> We are working on intel c508 intel denverton board.
> We have programmed coreboot image in 16MB NOR flash.
> 
> How can i get the coreboot version and build time stamp details in
> linux user mode? Does it creates any sys/proc entry?

Investigate DMI and cbmem.


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

[coreboot] Re: Can coreboot run on a Dell Wyse 3290 or 3030?

[Peter Stuge]

Martin Butt wrote:
> Do you know if Coreboot would work on either of these systems?
..
> Both the 3290 and the 3030 CPUs are a Intel Celeron N2807 1.58GHz

That's the CPU marketing name which in firmware like coreboot doesn't
mean much. What matters is that this is a Bay Trail platform.


> From a visual inspection, the only difference between the boards of the two
> models is that the BIOS chip is different. The 3029 is a Winbond 25Q64FVSIG
> (or a 25Q64FWSIG, the chip is hard to read). The 3030 is a Macronix
> MX25U6435F.

The 25Q64 chip is unproblematic. flashrom mentiones an OTP region in
the MX chip, I would investigate if and how that is being used, if
the OTP lies within the 8 Mbyte then that could be a problem and
you'd have to replace the chip by soldering.

(If you need to replace a chip: cut its pins flush with the black
package so that you can first remove the package and then use a
soldering iron to remove one pin at a time. Clean the pads with
solder wick and then solder a new chip in.)

> flashrom v1.2 on Linux 5.13.0-30-generic (x86_64)
..
> Found chipset "Intel Bay Trail" with PCI ID 8086:0f1c.

I know that coreboot *has* had *some* support for Bay Trail, IIRC
the minnowmax board, IIRC that was the very first attempt at using
Intel's FSP blob in coreboot and I think it did work but it wasn't
a great success. You'd have to investigate.


Kind regards

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

[coreboot] Re: 2022-03-29 - coreboot UEFI working group meeting minutes

[Peter Stuge]

Rudolf, thanks a lot for challenging me and clarifying the problem!

ron minnich wrote:
> Rudolf's point is crucial: "Challenge accepted. They aren't [self
> defining] because they are defined with ABI/compiler:"
> 
> As Rudolf points out, we are defining a binary layout with a c
> compiler. That's known not to work.

Ron, I now understand what you mean by self-describing.

But I think we should focus only on the lack of explicit serialization.

I don't think self-describing is important; it would in fact be
redundant and thus a source of possibly contradictory information
which I absolutely do not want at boot. And it would make parsing
a lot more complex without real benefit.

I think the key requirement is that we must use a well-defined,
explicit serialization, even if simply "never any padding" aka "packed".

When considering tables in memory not as structs but using Ron's
framing "a packet" transfered to somewhere else then serializing
the fields without padding is not unreasonable at all!


> I'm not saying we can use this, but if you use this string to generate
> an array of uint8_t, then you package the string with the array, you
> now have a self-describing structure, I believe.

The current cbtable tag-and-size system parsing a lot easier and
quicker than a pack pattern would, we should not give that up.

I however agree completely that we should define serialization!

But I see no reason to introduce a pack pattern.

The tag already implies which specific members are contained and we
can add tags when needed.


> Again, what we have today is not self-describing,

Not a problem.

> not portable to non-gcc toolchains or other kernels, and not
> portable even across kernel and compiler versions

This is the problem, and we should fix it for sure!


> Further, because coreboot depends on gcc features,

As an aside, I disagree with Julius on this; even if we do so in some
places we shouldn't do so frivolously. But let's stay on topic.


> Consider the case of a 10y old coreboot, with a modern kernel (Linux)
> booting from it. How does linux parse the structures?

Existing tags will have to always mean "GCC ABI" alignment, but we
can invest some time into explicitly defining those alignments that
have been output by GCC up til now and explicitly serialize to that
in order to ensure forward compatibility with old kernels.

Then there are at least never any further variations, and being
explicit is always better than letting the compiler pick.

More importantly though, once we have defined a "coreboot ABI"
serialization we should add new tags which only ever use that, while
continuing to output also GCC ABI tags, until they demonstrably break
all possible consumers, which I expect will be never.

Modern Linux then learns to prefer coreboot ABI tags with well-defined
serialization and could output warnings about GCC-ABI tags and optionally
try its best to parse them as it always has.

We can't magically fix 10y old coreboot from within Linux, that machine
then deserves a firmware update, but at least we can fix this while
maintaining both backwards and forward compatibility.


I propose that coreboot ABI serializes table members without padding.

What issues do you see there? x86 can access single bytes anywhere
(really only relevant until RAM is available, right?) but would we
have a problem on other architechtures?

(This btw also seems like a good example of a change that could and
should benefit every single board that we've ever had code for but
could require duplicated engineering to apply on diverged branches.)


Kind regards

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

[coreboot] Re: Deprecation of the Intel Quark SoC

[Peter Stuge]

Michael Niewöhner wrote:
> Once again, nobody is talking about deleting the platform or make it unusable.

Moving a board to a branch includes deleting it on master.

Deleting on master harms the board in two ways:

* Board code loses visibility, which also harms the project as a whole.
  (Less discoverable outside of the project => less newcomers.)

* master diverges over time, so future work on master is less likely
  to apply to the board code.

Whether you intend it or not that de-facto deprecates the board code.


Added to that is a less quantifiable organizational/psychological
aspect, where a board existing only on a historical release branch
is likely understood by most to mean that this board code is indeed
historical within coreboot. This is "softer" than the two points
above, but I believe still of consequence.


> Actually, moving it to a branch is the exact opposite to that -
> preserve a *hopefully* working state,

That state is preserved on master too, so that's not a good argument.

If you want to discuss how we can best document the collective
experience and test results for all boards then I think that's great!

Martin mentioned board-status and how there's room for improvement
in this area. But e.g. a branch per board is not an improvement, for
the reasons I give in this thread.

We could consider using git tags, but they're also not a very good fit.

Do you have more ideas? Maybe something concrete for how board-status
could be improved?

Maybe a first improvement is to split it into two; one small repo for
high-level test results with metadata, another for the log files.
Perhaps some compression could improve storage requirements for the latter?


> while still taking maintaince work

My ask is that such benefits in fact exist and are explained when
proposing to delete a board from master, so *those* can be discussed -
as opposed to (like in this case) speculatively proposing to delete a
board on master based merely on lack of recent (define recent?) test
results and development work. (At some point every board code will
become complete, so no more work required.)

When there is a clear benefit, such as reducing workload in other
code then it's possible to have a concrete discussion and it's also
possible for people to offer other ways to create the same benefit.

To me, deleting from master without clear benefit is premature.

I guess one could argue that master should contain as little code as
possible, only whatever someone is actively working on, but that
doesn't seem at all useful for those who like to use our project.


> from ***VOLUNTEERS***.

I wonder what the split is between paid and spare time coreboot folks.


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

[coreboot] Re: Deprecation of the Intel Quark SoC

[Peter Stuge]

Michael Niewöhner wrote:
> > But once code is moved off master reuse of changes on master will
> > eventually become impossible and there's no good path to recover from
> > that situation, so it should be important to avoid such dead ends for
> > any code we want to stay usable - IMO all code.
> 
> How would you "reuse [] changes on master" on a platform, where these
> changes can't be tested? o.O

By reuse I don't mean that code runs, I mean that a commit benefits
also platforms without test coverage.

There are many ways to determine whether a commit benefits a platform
or not, testing is just one way and testing alone is a weak indicator.

That's perhaps foreign to someone with a "test-driven" mindset. I
don't hate on testing at all, I just want to preserve value also
where there's no coverage when that's possible without much detriment
to other parts of the code.

I don't think it's reasonable nor is it current practice to require
every commit to be tested on every affected platform. That would
obviously be nice data points to have but that has not been coreboot
reality in the past 20 years and I predict that it will also not be
so in the next 20 years. I think that's fine.


I hope you can understand that my ask is simply to not erase what
might be working well based only on a lack of information.

I'm obviously grateful that the leadership meeting settled on keeping
quark at least as long as it causes no problems. Thanks for that!


Kind regards

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

[coreboot] Re: Deprecation of the Intel Quark SoC

[Peter Stuge]

Martin Roth via coreboot wrote:
> > On Mon, 2022-04-11 at 22:23 +, Peter Stuge wrote:
> >> Martin Roth via coreboot wrote:
> >> >   1) Please don't use the term deprecate - use "moved to a branch"
> >>
> >> I don't think the wording matters, my points are discoverability and
> >> drive-by maintainance.
> 
> Yes, wording matters.

I disagree, since a new name doesn't affect the points I make.

Trying to reframe even risks detracting from the actual argument.
It has a taste of whataboutism.


> If you really don't think that wording matters check out this article,
> and the book that it's about:
> https://commonslibrary.org/frame-the-debate-insights-from-dont-think-of-an-elephant/

Thanks for the link. A quote: "Framing is the art of communicating such
that one’s language activates particular unspoken ideas and associations."

That could certainly help in political contexts where it may be
undesirable to communicate matter of fact, to not reveal true intentions.

But I don't think that's something to strive for in open source
projects, where my goal is transparency and determinism.


> Every time coreboot says that some platform is being "deprecated",
> it starts an argument.

That's not because of the wording, but because of the foreseeable
consequences of the action known as "deprecate" or "move to branch".


> I'd really like to avoid that argument.

Let's see what we can achieve.


> >> > If a platform is perfect and doesn't need to be updated, it doesn't
> >> > need to be on the master branch, right?
> >>
> >> I think wrong, because being on master is the only chance to receive
> >> tree-wide changes, e.g. through coccinelle spatches or sed:its.
> >>
> >> Missing those rots the code quicker so yes, something getting moved
> >> to a non-master branch is de-facto deprecation by degradation to
> >> second class.
> 
> How can it degrade if it's not being changed?

Code not in master eventually requires duplicated engineering to
reuse desirable bug fixes in master.

That's a degradation, since duplicating effort is less efficient.


> Older platforms that aren't being tested regularly stop working *because*
> they're in the main branch, receiving lots of code changes without being
> tested.

That's an interesting argument. Whether it holds true depends on the
particular changes. I understand now that both you and Michael are
very test-focused, which explains why you feel that untested code is
per definition second class. I view that differently.


> By moving them to a branch, they're less likely to get additional
> breaking fixes. So allowing them to be maintained on a branch is
> much better for stability.

IBVs have tried that model, it eventually results in one branch per
board, essentially a completely silo:ed situation, with reuse across
branches approaching zero over time.

Do we agree that such a situation is undesirable in coreboot and
really any open source project?

In companies that generate revenue each time the same change is
implemented in another branch the silo model is profitable, but
we don't have that driver in coreboot - here I view it as wasteful
duplication of already-scarce labour at best and malicious at worst.


> It's absolutely not second class either.  If people understand that
> the older platforms are maintained on these version branches, they
> can be worked on there without having all of the changes on newer
> platforms to deal with.  It's a matter of getting people used to
> working on those older branches.

I completely disagree with this paragraph.

Branches are second class because as they diverge over time (which is
their purpose) reusability approaches zero, value for consumers follows
that directly and so does the likelihood of future investment into
the branch.

Deprecation of the code in the branch becomes a self-fulfilling prophecy.

Because this is very predictable there's pushback each time something
is being proposed for deprecation AKA move to another branch.

Every time it reduces the value of engineering that has gone into
coreboot in the past.

I think everyone understands that there's a tradeoff where such
reduction in value can be offset by a significant increase in value
which can't happen until the code is moved.

I ask that such increase in value must be demonstrated before code
can be moved off master.

If there's no clear benefit then I disagree with moving something off
master, especially based merely on a lack of test datapoints or
because current project contributors can no longer buy the hardware.

Taking action because there *isn't* any data seems the very opposite
of a scientific approach - not something I think we want to do, right?


> > Maintaining without ability to test will make 

[coreboot] Re: 2022-03-29 - coreboot UEFI working group meeting minutes

[Peter Stuge]

ron minnich wrote:
> My goal was pretty simple: Kill the UEFI HOBs, and the FSP UPD, and
> put something better in their place. coreboot tables could easily
> replace HOBs, save that intel will never accept that;

Thanks, now I understand.


> but I don't see coreboot tables replacing UPD.

Why couldn't they? (Politics aside, for now.)


> I like self describing data as it avoids that mess that we are in with
> UPD today, where you can end up with problems if the compilers you use
> for FSP and (e.g.) coreboot don't agree totally on how to lay out data
> structures.

Understand! Not even having a well-defined serialization is a disaster.
CBOR is a solution to that but I think it has way too many primitives.


> UPD are also a major pain for non-C firmware, such as oreboot.

Again because of undefined alignment, or something else?


> So I'd like a data format that is not defined by a compiler or
> language. But maybe I'm the only person who wants that :-)

I completely agree that well-defined serialization is neccessary for
interoperability, it's pretty amazing that Intel overlooked that.
I wonder what else..


You asked about other serializations, the one I was last pleasantly
surprised by was the Kafka protocol, which isn't as arduous as
one might think based on the name. :) Like coreboot tables it does
not describe structure, only values, so reader and writer must agree
on what they transfer out-of-band based on a shared definition, but
certainly not based on any compiler properties.

It is however a network and disk serialization - far simpler than
CBOR but maybe still unneccessarily complex or at least somewhat
unfitting for firmware. It mostly has signed values and later
versions (there's a version in a header) add varints to save bytes,
because the protocol is made for very high message volume - so not
really applicable to firmware.


How about using cbtable primitives to express UPD and calling it
something new?


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

[coreboot] Re: 2022-03-29 - coreboot UEFI working group meeting minutes

[Peter Stuge]

ron minnich wrote:
> peter, you are right about CBOR, and that says to me it does not
> really meet the original goal of self-describing data.

Hm, whose goal is that?

Anyway, using some data structure serialized in CBOR requires
defining the structure somewhere. Using coreboot tables requires
definitions too, they are currently defined in coreboot,
standardizing coreboot tables would probably see them move to a
repo of their own.


> But coreboot tables, at least in my understanding, is also not
> self-describing.

I don't know? What do you mean by self-describing actually?


> Do you have some thoughts on a good format that is self-describing?

So what's the expectation there; what does a self-describing format
enable or need to enable? And what's the complexity tradeoff involved?

As Arthur pointed out, coreboot tables have the quite significant
advantage of being very very simple to read and write.


I think this is still interesting to pursue:

> > > So if the idea is to create a payload handoff format that can be
> > > shared and used by multiple different firmware packages, do you have
> > > a better option?
> >
> > I'd ask what other boot firmware is missing from coreboot tables for
> > them to be universally acceptable.

Martin wrote that the goal is to create a handoff format that can be
shared and I'm asking what coreboot tables are missing to serve others,
because I think we have a really good (simple) technical solution there.


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

[coreboot] Re: Security notice: SMM can be hijacked by the OS on APs

[Peter Stuge]

Arthur Heymans wrote:
> > Would it make sense to backport your fix to old releases and bump
> > those release numbers to a .1 on the end?
..
> It's a bit weird to have releases that you'd have to advertise as *don't
> use*, but I've seen us do that in the past (because issues are quite often
> just fixed in master).

I don't know about actively advertising "don't use" but most projects
do keep public records of security-related issues including the first
fixed version.

I asked specifically about backporting since non-master branches are
a) supposed to have some longevity and b) maybe used to simplify
people's and companies' own release management.

I too would appreciate hearing from those shipping coreboot.


Thanks

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

[coreboot] Re: Security notice: SMM can be hijacked by the OS on APs

[Peter Stuge]

Arthur Heymans wrote:
> I think this issue might affect a lot more systems than I initially thought.

Would it make sense to backport your fix to old releases and bump
those release numbers to a .1 on the end?


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

[coreboot] Re: Deprecation of the Intel Quark SoC

[Peter Stuge]

Martin Roth via coreboot wrote:
>   1) Please don't use the term deprecate - use "moved to a branch"

I don't think the wording matters, my points are discoverability and
drive-by maintainance.


> If a platform is perfect and doesn't need to be updated, it doesn't
> need to be on the master branch, right?

I think wrong, because being on master is the only chance to receive
tree-wide changes, e.g. through coccinelle spatches or sed:its.

Missing those rots the code quicker so yes, something getting moved
to a non-master branch is de-facto deprecation by degradation to
second class.


> I absolutely agree that if something isn't being used, it doesn't
> need to be maintained on the master branch.

I disagree.


> I just want to make sure that things actually aren't being used
> before moving them to a branch.

I think "no usage" alone should be a very weak motivator to move
something from master, just like "no availability".

(Many SOCs are currently unavailable and will remain so for some time!)

If code is perfect or nearly perfect then why move it?

If there are *concrete* issues with code then I think it would be
reasonable for *that* to count much more than "no/unknown usage",
but the current proposal did not reference any such issues, Paul's
ask didn't yield any and neither did mine.


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

[coreboot] Re: 2022-03-29 - coreboot UEFI working group meeting minutes

[Peter Stuge]

Martin Roth via coreboot wrote:
> > Your concern is valid and I think a key point. CBOR may not be bad
> > over a socket, but such a complex and arbitrarily extensible format
> > is much too error prone to be a good technical choice during boot.
> 
> So if the idea is to create a payload handoff format that can be
> shared and used by multiple different firmware packages, do you have
> a better option?  Yes, coreboot can just continue with just the
> coreboot tables, but that seems a little like sticking our head in
> the sand and refusing to recognize that other boot firmware exists.

I'd ask what other boot firmware is missing from coreboot tables for
them to be universally acceptable.


> > I agree that it could be a step forward, but I think the devil is in
> > the details. CBOR data structures can also be unneccessarily complex
> > and error prone, beyond the parser itself.
> 
> So maybe we try to limit the complexity?  I'm not really familar with
> CBOR, so I don't know the issues with it.

CBOR (RFC 8949) is a binary serialization of JSON with some extensions.

So "CBOR" itself says nothing about the data within.


> Intel did say that they were willing to look at other alternatives if
> we had any.

That's a positive signal!

I propose that coreboot tables are a good alternative - fight me! :)


> I hope nobody takes any of this as criticism - I appreciate the
> open discussion, and am sincerely looking for the best path forward here.

Not at all.

Let's see if coreboot tables can grow to cover all needs?


Kind regards

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

[coreboot] Re: Deprecation of the Intel Quark SoC

[Peter Stuge]

Michael Niewöhner wrote:
> It feels this is the usual "but what if *someone* out there *needs/wants* 
> it?".

Not quite, it's "why delete it if it might work?". This is still
ideological of course, so the question becomes what we find valuable.

I e.g. do not consider it at all valuable to only keep code for the
last n Intel platform generations, in spite of knowing that only
those have any value whatsoever for the vast majority of coreboot users.

But coreboot is not a company and thus not restricted to only value
market demand or otherwise proven utility. We can have other values
and I do.


> Does anyone know if the platform still works, at all?

Does anyone know that the platform *doesn't* work?

Are there any practical concerns whatsoever?


For me, at a very minimum both those questions must have a yes answer
to qualify deletion.

Reducing scope is always satisfying but that's not a good reason to
delete platforms.

It is of course very easy to manufacture practical concerns, but
maybe that's a fair enough hurdle for arbitrary deletion...


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

[coreboot] Re: Deprecation of the Intel Quark SoC

[Peter Stuge]

Felix Singer wrote:
> to me it seems like the Intel Quark SoC has been unmaintained and
> unused for a long time now. So I'm proposing to deprecate the support
> for it with coreboot release 4.17 [1], in order to drop the support
> with release 4.19 so that the community has less maintenance overhead.
> 
> Does anyone use this platform? Any opinions against this?

What Paul wrote; are there some practical concerns beyond the
academic concern seemingly based on perceived utility?

Quark is funny and as I understand also the ME CPU, I find those to
be two more good reasons not to delete it.


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

[coreboot] Re: [GSoC] Console via SMBus

[Peter Stuge]

Ahamed Husni wrote:
> Please add your thoughts and concerns about the project and suggest a
> mainboard for the project :)

You're correct that socketed RAM is important for the project;
mainboards with onboard RAM usually have no SPD memory at all,
so the SMBus may not be at all accessible.

Any particular mainboard might not be so important as long as the
SMBus can be accessed somewhere; possibly a cellphone repair store
can help solder the three SMBus wires to a small connector for the
purpose of the project.

But it would be great to also consider what the user story is for
people who want to use this on other mainboards.

Ideally it shouldn't be neccessary to buy a niche product like a RAM
breakout adapter; it would be great to also explore more ways to
access the SMBus signals, e.g. PCI Express optionally has SMBus,
smart batteries have it, etc.


Kind regards

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

[coreboot] Re: 2022-03-29 - coreboot UEFI working group meeting minutes

[Peter Stuge]

Hi,

Arthur Heymans wrote:
> I would like to add a few notes to the meeting notes to clarify things a
> bit better.

Thank you for that.


> So the only thing not 'practical' here is that UEFI teams don't have
> control over the handoff structure format that is inside coreboot and
> is used by coreboot payloads (coreboot tables).

Right. The spec (overview graphic) makes it clear that USF is an
embrace-and-extend type of effort to supercede existing projects
and de-facto standards in the space.


> > The current payload handoff method has a number of flaws that
> > they’d like to fix, such as the address for stack being hardcoded.
> 
> Normally payloads set up their own stack very early on so this is not a
> problem.

It has always been a primary design goal for coreboot to leave no trace
when the payload takes over. Payloads have total control of the system
and need not look back. Anything that violates this principle goes
against the primary design goal of coreboot to not stay resident.

This primary design goal was very much on purpose.


> The context here, was that I voiced some practical concerns about
> using CBOR as a handoff structure. LinuxBIOS or coreboot tables were
> carefully designed to be very easy to parse.

Your concern is valid and I think a key point. CBOR may not be bad
over a socket, but such a complex and arbitrarily extensible format
is much too error prone to be a good technical choice during boot.

The same properties that make it technically unsuitable can of course
make it a perfect choice politically, for someone.


> My objection to a new format like cbor was that it is likely very hard to
> parse using the same trampoline scheme.
> It is likely possible to write a trampoline using a stack in C, but then
> again that just complicates things a lot needlessly just to adopt a new
> format with probably little to gain.

I see zero gain for coreboot.

The gain is political for someone outside of coreboot; using a free
form and extensible data structure instead of coreboot tables moves
handover standardization out of the coreboot project and enables
arbitrary extension at will by someone not coreboot.

I believe that would be a net loss for the firmware community at large.


> > * The coreboot project can, however, encapsulate a CBOR-based
> > handoff-structure into cbmem, similar to what we currently do
> > with ACPI tables.
> 
> I think this is about supporting both a CBOR-based handoff and coreboot
> tables at the same time.
> My concerns here are that is requires some synchronization between both
> codepaths and just increases maintenance in general.
> Introducing multiple codepaths to do roughly the same is an error we get
> bit by way too often. I think we should be careful about this...

Yes! Double trouble would be silly. If someone wants to use CBOR then
why not just create a payload for that, rather than trying to mess up
coreboot itself?


> > Additionally Intel was willing to look at using CBOR structures as
> > input and output to the FSP, so we could get rid of both the UPDs
> > & HOBs.
> 
> This seems like the real positive upshot of that conversation!

I agree that it could be a step forward, but I think the devil is in
the details. CBOR data structures can also be unneccessarily complex
and error prone, beyond the parser itself.


Kind regards

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

[coreboot] Re: [Building] Latest Coreboot crossgcc x86_64 builds fails under ArchLinux x86_64

[Peter Stuge]

Lahfa Samy wrote:
> Hey so here is what I found out about the error and solved it, it was 
> actually making this error because the folder named 'cp' exists, as soon 
> as I renamed the folder 'cp' to something else, the build got working 
> again.

Good find! Where did that 'cp' folder exist?


> Very weird issue, if anyone has an idea why it happened, my shell being 
> used is ZSH.

It actually makes sense. Most systems don't treat program binaries
specially, they are usually just files, ie. entries in directories.

Commands issued to the system are searched in the PATH directories.

If there's an entry with the sought name in a PATH directory then
it's not so wrong to try to execute it, although obviously directories
can't ever be executed successfully.



Karl Semich wrote:
> I was able to reproduce your error with:

Thanks for the reproducer.


> sudo mkdir /usr/local/bin/asdf
> echo -e 'all:\n\tasdf' > Makefile
> make
> 
> I have gnu make 4.3 .
> 
> This could be considered a bug with gnu make, trying to execute
> directories. Ideally it would be reported to them and a fix
> contributed. It is likely very easy to fix.

make probably isn't actively choosing to do it.

$ sudo mkdir /usr/local/bin/asdf
$ bash -c asdf
bash: asdf: command not found
$ tcsh -c asdf
/usr/local/bin/asdf: Permission denied.
$ busybox sh -c asdf
sh: asdf: Permission denied
$ gcc -o /tmp/a.out -x c - << EOF
#include 
#include 
#include 

int main(int argc, char *argv[]) {
execlp("asdf", "asdf", NULL);
perror("execlp");
exit(EXIT_FAILURE);
}
EOF
$ /tmp/a.out
execlp: Permission denied
$ 

Based on the error messages and as confirmed with strace -f only bash
chooses to reject the subdirectory as a command while the other
programs probably just call execlp() or execvp(), so this is libc
behavior.


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

[coreboot] Re: New array-bounds warnings with GCC 12

[Peter Stuge]

Paul Menzel wrote:
> x86_64-linux-gnu-gcc-12 .. -std=gnu11 ..
..
> In file included from src/include/cpu/x86/lapic.h:4,
>   from src/cpu/x86/lapic/lapic.c:5:
> In function 'read32',
>  inlined from 'xapic_read' at src/include/cpu/x86/lapic.h:13:9,
>  inlined from 'lapic_read' at src/include/cpu/x86/lapic.h:80:10,
>  inlined from 'lapicid' at src/include/cpu/x86/lapic.h:138:21,
>  inlined from 'enable_lapic' at src/cpu/x86/lapic/lapic.c:41:3:
> src/arch/x86/include/arch/mmio.h:20:16: error: array subscript 0 is 
> outside array bounds of 'const volatile void[0]' [-Werror=array-bounds]
> 20 | return *((volatile uint32_t *)(addr));
>|^~
..
> I have no idea, if it’s valid or not

gcc-12 is technically correct that accessing element 0 (the first element)
in an array with 0 elements is out of bounds.

But in practice it's not a problem for our code, because these are all
uint32_t pointers to memory mapped registers (hint: volatile).

So our code is somehow incorrect since these are, in fact, not arrays
with 0 elements. The question is why we use them.

One reason can be that older C standards didn't allow arrays to have an
unknown size and nobody fixed that using coccinelle when bumping -std=.

Another is that an array with an unknown size must always be the last
member in structs, and that there can only ever be one of those and
using a 0-sized array can work around that, but IMHO isn't really
very pretty.

If possible it would be nicer to use (const?) volatile uint32_t *
instead of const volatile void[0], then the casts would also disappear.

Some analysis is required to understand the 0-sized arrays rationale.

Or maybe someone remembers? :)


Kind regards

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

[coreboot] Re: Installing coreboot with SeaBIOS

[Peter Stuge]

bernd...@web.de wrote:
> I suppose your second choice
> ... "2. Reformat the stick partition with a filesystem" ...
> is the most promising.

If you haven't saved anything else on the USB stick then sure, go ahead
and format it.


> What's the default partitioning/file systems for a 64 GiB USB stick
> (how many partitions, what types of partitions, what file system for
> which specific partition)?

This too is a function of the particular software you're using. I don't
know what the file manager or disk manager applications you got with
your Linux installation will suggest.

I'd create a single partition and format it to use ext4.

Note that ext4 being a journaling filesystem makes it critically important
to cleanly unmount the filesystem after you write to it, before unplugging
the USB stick.

ext4 is not optimized to be very robust when misused, so if the USB
stick is unplugged without unmounting first then data loss is highly
likely and the filesystem can even become corrupted beyond repair.

(These things are unrelated to coreboot and quite off-topic for the list,
plus I'd think that the same answers can be found in many other places.)


I hope you've been able to flash already :)

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

[coreboot] Re: Installing coreboot with SeaBIOS

[Peter Stuge]

bernd...@web.de wrote:
> while copying the coreboot/SeaBIOS installation (folder coreboot)
> to a USB stick I got the following error message:
> Error with copying of >>usb_tcpm_v2_rev30_fuzz.c<<.
> With copying of the file to ... /coreboot/3rdparty/-chromeec/fuzz an error 
> occurred.
> The file system doesn't support symbolic links
> Cancel | Skip all | Skip
> What can I do?

Two choices come to my mind:

1. Don't copy the folder to the stick as-is but instead create an archive
(something like .tar, .tar.gz or .zip) of the folder first and then
copy that single file to the stick.

Exactly how to do that depends on the tools you're using. I'd suggest
to right-click on the coreboot folder on the hard drive and see if
there's any promising option in the menu that opens.


2. Reformat the stick partition with a filesystem that supports symbolic
links, e.g. ext4.


Kind regards

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

[coreboot] Re: Installing coreboot with SeaBIOS

[Peter Stuge]

Peter Stuge wrote:
> > How should I continue to get access to the flash chip?
> 
> I didn't know the board so I searched and found someone who has
> documented exactly the process that you are going through with photos:
> 
> https://szclsya.me/posts/coreboot/x220/#headline-4

Turns out www.coreboot.org also has some documentation and photos. :)

https://www.coreboot.org/Board:lenovo/x220
https://www.coreboot.org/File:X220_flash_chip.jpg
https://www.coreboot.org/File:X220_clip.jpg


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

[coreboot] Re: Installing coreboot with SeaBIOS

[Peter Stuge]

Hi Bernd,

bernd...@web.de wrote:
> I performed the steps â1010 Battery packâ, â1040 Keyboardâ,
> â1050 Palm rest or palm rest with a fingerprint readerâ and after
> that "1090 Keyboard bezel".
> I see what's on the attached image. That's the upper side where the
> keyboard was before.

Excellent progress! Well done.


> How should I continue to get access to the flash chip?

I didn't know the board so I searched and found someone who has
documented exactly the process that you are going through with photos:

https://szclsya.me/posts/coreboot/x220/#headline-4

Great news: No need to disassemble the machine any further! The flash
chip is on the top side of the mainboard, under the black plastic
film next to the Expresscard slot.


Kind regards

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

[coreboot] Re: Installing coreboot with SeaBIOS

[Peter Stuge]

bernd...@web.de wrote:
>... "tl;dr Go!" ...

TL;DR is short for "Too Long; Didn't Read", sometimes used to place the
most important message at the very top for limited capacity readers.


>... "AFAICT" ...

"As Far As I Can Tell"


> Should I use this tutorial, that applies to the ThinkPad X200 where I
> got a ThinkPad X220, for opening the housing and figuring out what
> screws to open in order to get access to the chip or is there one for
> the ThinkPad X220, too

The hardware is not identical but will probably be similar-ish. The
official X220 Hardware Maintenance Manual by Lenovo is available here:

https://download.lenovo.com/ibmdl/pub/pc/pccbbs/mobiles_pdf/0a60739_04.pdf

Chapter 8 on Page 67 is where disassembly starts, you eventually want
to complete the first step of 1120 "Removal steps of system board"
but quite possibly you don't actually need to perform every single
step before even though the manual says so, in particular I doubt
that you actually have to remove the LCD assembly.

It's also possible that you don't need to remove the system board
from the case at all, to access the flash chip. It depends on which
side of the system board it is mounted on and I unfortunately don't know.
If you're lucky it's on the top side of the board and you only have to
go through step 1090 to remove the keyboard bezel.

You may have to experiment to get to know your X220. It might take up
to a full day but hang in there, it's a great learning experience.

Keep in mind that the maintenance manual will never mention the BIOS
flash because Lenovo does not intend for anyone to do component level
work on the system. Their technicians must only ever consider the
system board as a whole, quite wasteful btw.

You can of course compare the maintenance manual both to the X200
instructions on the web page and to your actual hardware to figure
out how much overlap there is, either beforehand or as you go.

Take all the blahblah about having to be trained and certified and
whatnot with a grain of salt. It's your hardware, you can do what
you want with it, and taking it apart is highly admirable!

Viel Erfolg and in case you get stuck you can always ask questions.


Kind regards

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

[coreboot] Re: Gerrit shows a Merge Conflict (was: Re: Denverton-NS refactoring)

[Peter Stuge]

Thank you for your updates, Jeff.

Jeff Daly wrote:
> the feedback I got from Intel is that they will be moving away from
> internal support for DNV coreboot.

It's sad and telling to see one of the most ambitious technology
companies in the world, one that routinely pushed technology limits,
choose to not continue to accept responsibility and be active in our
firmware community.

Value is never inherent, it's what we choose to create.


Kind regards

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

[coreboot] Re: My Asus P2B-LS is still having fun with coreboot/SeaBIOS/flashrom. Now I have questions.

[Peter Stuge]

Keith Hui wrote:
> The hard disk booting stalled after SeaBIOS. Took me hours but
> eventually I found a line in my serial log that there has been a
> DMA timeout. Turning UDMA off in devicetree.cb and flash again made
> it boot again. So I would have to revert 576315e1 (aka CB:40961),
> but I'm hesitant because that seemed like the reasonable thing to
> do and it should have worked.

UDMA should only ever be enabled for a channel when an actual drive
that supports UDMA is connected. I don't believe it's a good idea to
enable UDMA on channels without a connected drive. And finally the
UDMA code can of course be buggy.


Regards

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

[coreboot] Re: spkmodem output

[Peter Stuge]

Martin Roth via coreboot wrote:
> I spoke with Phcoder (the original author) about this ages ago, and
> he recommended not actually playing sound with it, but using it
> with an audio cable between the output device and input device.
> I assume you'd be able to use it at a much higher speed that way.

Modulation surely works better in cable but I /have/ successfully
used spkmodem over air, it was just long ago and I guess neither
transmitter nor receiver are tested much so maybe something is
broken now..

Sound output from QEMU would be a great test; try -audiodev wav
to save straight to a file; ie. digital lossless transmission.


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

[coreboot] Re: spkmodem output

[Peter Stuge]

Keith Emery wrote:
> To verify that spkmodem.c is not the source of the issue. I decided I 
> would try to part off the code from the console, and then compile it. 
> Producing a wav file that I could then manually interpret, certify as 
> good, and use to fix or replace spkmodem-recv. My efforts however were 
> once again stumped when I realized the paired off code accessing the low 
> level hardware with the OS still loaded, will just cause a segmentation 
> fault.
> 
> Is there an easy way to run the executable under say QEMU, but emulating 
> just the PC hardware rather than a whole OS?

What if you build coreboot for emulation/qemu with spkmodem console? Does
QEMU produce actual sound? I don't know whether QEMU has a speaker output.

Otherwise, you can take a chance and run your program as root in
userspace after adding a call to iopl(3); before any in/out calls.

If your kernel is using the PIT then the system might lock up, but
I don't expect that modern systems need the PIT so I think it's fine.

Finally, you could try compiling the source code for DOS, that should
work fine on actual hardware.


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

[coreboot] Re: spkmodem output

[Peter Stuge]

Keith Emery wrote:
> When I enable spkmodem in the coreboot config, I get output from the PC 
> speaker. But spkmodem-recv interprets the tones as consistent gibberish. 
> The output is consistent with a mismatch in the baud rates, but there 
> appears no apparent way to select anything different in the 
> spkmodem-recv software.

spkmodem uses a fixed baudrate, IIRC 1200.

Did you look at a recording in a spectrum analyzer software? Maybe
that would help identify modulation timing issues.


> If the CPU is running coreboot as fast as possible while receiving
> those instructions from a relatively slow SPI bus. Is it possible
> that I've somehow overclocked the SPI bus, leading to a mismatch in
> the baud rates?

SPI isn't involved in tone timing, I think only the (emulated) legacy
timer is used for that.


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

[coreboot] Re: Add memory support for mb/apple: MacBook Air 5,2 (A1466)

[Peter Stuge]

Mariusz Grabarczyk wrote:
> I would like to have memory support added for mb/apple:
> MacBook Air 5,2 (A1466)

Just a note that A1466 is not a particularly stable identifier, it
would probably be better to use the actual mainboard part number.


//Peter
___
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

[Peter Stuge]

TL;DR: If someone wants to deprecate older code then *they* have to
first balance any compatibility debt introduced by the newer code.

Anything else incentivises a race to the bottom; to move fast and
break things. coreboot IMO neither wants nor needs that.


Patrick Georgi via coreboot wrote:
> > With all due respect, dropping support for the majority of AMD boards
> 
> Dropping support for hardware has never been the primary purpose of
> deprecation plans,

I think the difference is unimportantly subtle; deprecation is formal
intent to (eventually) drop.

Deprecating code that not only provably works on hardware but is in
fact *our only* code that currently works on the hardware IMO falls
between lazy and malicious, in any case far from good practice when
considering the future.

Our classic tension between private interests and the public good
will not diminish over time unless everyone invests towards that goal.
The Linux kernel is a perfect example of what happens otherwise, it's
certainly nothing to strive for.

I consider Arthur's argument about maintenance burden to be based on the
false premise that newer code is per se more valuable than older code.

If only considering hardware running the newer code with tunnel vision
I do understand such an attitude, but to me a hard requirement for such
a premise is that the newer code is a drop-in replacement - only then
is it prudent to speak of deprecating the older code. If it's not
compatible then the new code obviously solves a different problem.

It's of course too late to enforce drop-in compatibility once new code
has been accepted into the tree, but the desire for deprecation such as
this is a good opportunity to pay back what I consider compatibility debt
in the new code.

Accepting an incompatible new implementation fails to create the incentives
required for medium to long-term codebase stability. It would be wise to
start repairing that culture deficit right now.

I find it completely unacceptable for someone working on something new
to push a workload of forward-porting onto people who have no relation
whatsoever to that new effort, but I'm sure it's a fun power trip. :)
Please be more mindful than that. I've of course also made mistakes,
but I try to always improve.

If companies are unable to invest in creating open source firmware for
the public good then please think about whether you really want to be
known for introducing compatibility debt.

If companies are able but merely unwilling then please be honest about
that and do not bother others with your code, you should maintain it
locally then.


No progress can be infinitely better than "wrong" progress, and
therein lies the challenge for private interests in projects for
the public good. A strange game!


Kind regards

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

[coreboot] Re: Abandoning patches older than 30 Nov, 2019

[Peter Stuge]

coreboot org wrote:
> | https://review.coreboot.org/23376 | Changed 2019-06-29 | Paul Menzel | 
> "mb/lenovo/x60: Use big enough type for left-shift"

Commit 399b6c11efaff64cb86a879dc9047a97538e790f moved the relevant
code to src/southbridge/intel/i82801gx/early_init.c and it looks like
current master may still need the fix.


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

[coreboot] Re: Placing coreboot in system memory

[Peter Stuge]

Julian Stecklina wrote:
> I was asking, because we see coreboot memcpy'ing to ROM. We map it to
> 0xFF00_ and it's copying 0xee8 bytes of memory from 0xff20_0300 to
> 0xff20_0300 (the same memory). So this is basically a NOP, but very weird.

Right after reset it wouldn't be a NOP, but this seems to be a lot later.

(Real mode f000: after reset maps to physical .)


> CBFS: Found 'fallback/romstage' @0x80 size 0x3ba0 in mcache @0x00014e2c
> WARN - MOVS to ROM at RIP dc2f RCX ee8 ff200300->ff200300

I guess this is in 32-bit mode. coreboot leaves real mode quickly.


Anyway, memory mapped sounds correct for QEMU. :)


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

[coreboot] Re: Installing coreboot with SeaBIOS

[Peter Stuge]

bernd...@web.de wrote:
> /bin/sh: 1: python: not found
> make[2]: *** [Makefile:168: out/romlayout16.lds] Error 127

It's unfortunate that SeaBIOS requires python to build, but keep it
up, you're not far away.


Merlin Büge wrote:
> If you want to proceed with doing it yourself, be prepared that it will
> take some time (several weeks+) and that you will have to learn a lot.

I hope Bernd does proceed and the first success shouldn't be too long
now. It's a great feeling to have a machine (virtual or otherwise)
boot self-built firmware! :)


Hang in there

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

[coreboot] Re: 26 October 2021 - coreboot EFI working group meeting minutes

[Peter Stuge]

coreboot org wrote:
> It looks like the push to require linux to use EFI is coming from the
> Universal Scalable Firmware project.
> [https://github.com/UniversalScalableFirmware/linuxpayload]

Thanks for the link! I didn't know about USF and found a good project
overview linked from https://github.com/UniversalScalableFirmware :

https://github.com/UniversalScalableFirmware/Introduction/blob/main/USF_Overview.pdf

The last page has a good diagram of the USF vision showing coreboot
positioned next to tianocore, slimboot and U-Boot while also showing
that these are all rather small pieces and, crucially, that Intel will
of course not accept anything but theirs as the overarching concept -
one where ACPI, binary configuration through YAML (funny oxymoron!)
and FSP are key features, with benefits such as minimized need for
source code manipulation.

To me, this is sadly as unsurprising as it is disgusting.


> It might be good if coreboot contributors helped drive those decisions.

That seems a fool's errand to me, but power to you if you try.


Kind regards

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

[coreboot] Re: spkmodem-recv

[Peter Stuge]

Keith Emery wrote:
> Can somebody please verify that the attached file can be interpreted by 
> spkmodem-recv?

$ sox test.wav -t s16 -L -c 1 -r 48000 - | ./spkmodem-recv | xxd
000: 25   %
$ 

A single '%' is output. Is that what you would expect?


> Or point out where I might be going wrong?

Looking at the .wav file in a wave editor it has little if any noise.

Is this actually a recording?


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

[coreboot] Re: coreboot EFI working group meeting minutes - 12 October 2021

[Peter Stuge]

Patrick Georgi via coreboot wrote:
> > > Linux is expecting more and more to use EFI supplied interfaces (UEFI
> > > Boot Services in particular, even if many are stubbed out)
> >
> > LOL!
> 
> The fun part about this segment was that all we could go by was hear-say
> and unfounded rumors that went around.

Nico Huber wrote:
> It's just not true.

That's good news!


Patrick Georgi via coreboot wrote:
> Remember that LF is a trade organization (501(c)(6)), not a charitable
> organization (501(c)(3)).
> This difference in target audience compared to most open source
> organizations informs their strategic decisions, and keeping that in mind
> minimizes surprises and heartburn.

Yes, exactly right.


> > * The coreboot repo will host an EDK2 fork for use as a coreboot payload.
> > I think the planned tighter integration is a significant first step
> > towards coreboot becoming UEFI.
> 
> This isn't about a "tighter" integration: we already have that payload, and
> we had Tianocore-as-a-payload integration since 2013 (commit
> cc5b3446624cf85e13a8130a524e81360c5f4239)
> 
> It minimizes the time each individual, who for one reason or another works
> on edk2, needs to spend on edk2.

Ah, so, if it's mostly a matter of giving a coreboot.org home to what
Matt has been maintaining outside of coreboot.org then I think it's a
good decision!


> OTOH I haven't found a better way to make developers fervent edk2
> opponents than simply showing them the source, so there's that.

Thanks, that made me smile. :)


> > * Definitely no one-size fits all solution here
> >
> > The challenge is great. The coreboot community must be strong and
> > vigilant to not allow coreboot to get locked into EDK2/UEFI like has
> > already happened with vboot.
> 
> I'm not sure why vboot makes this sudden appearance here.

It's supposed to be optional but actually (I believe still) isn't.

The lock isn't very strong, which is why I argue that the damage is small.


> > I don't expect this to go at all well for coreboot, but fingers crossed!
> 
> Want peanuts?

With cranberries, please. :)



Nico Huber wrote:
> If it were generally true, Chromebooks would have to implement UEFI,
> all the mobile and embedded devices running Linux would have to
> implement UEFI, and it would render LinuxBoot impossible. I don't see
> that happening;

I can imagine that some are pushing for it to happen though.


> rather the opposite: I'm often reminded that server folks run away
> from EFI, for instance.

A good point! But are servers a more important market than mobile?
I honestly don't know what that fight looks like.


> There are a few who might actually need it.

Also a good point. I think it's a good thing if it becomes easier to
create UEFI using coreboot, less so if it becomes the primary use case.


> For instance if one is in the business of general purpose PCs where
> any OS should work.

Exciting times for such business!


> In this area one will always have to support legacy boot in one way
> or the other (BIOS/UEFI). Maybe who wrote that is in this particular
> business and "we" was referring to them and not the whole coreboot
> community.

Nod - I hope that's right.


Thanks and kind regards

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

[coreboot] Re: coreboot EFI working group meeting minutes - 12 October 2021

[Peter Stuge]

Martin Roth via coreboot wrote:
> ## Objective:
> 
> Linux is expecting more and more to use EFI supplied interfaces (UEFI
> Boot Services in particular, even if many are stubbed out) so like it or
> not, we’re going to need to support these interfaces.

LOL!

This is super embarrassing for Linux and Linux Foundation, but of
course also 100% to be expected. Linux plods along towards absolute
uselessness.


> How do we approach this without turning coreboot into UEFI.

I think it's mostly a waste of time to try to avoid that. When
Linux Foundation dictates technical requirements to coreboot instead
of the other way around then the question is not "if" but "when"
coreboot becomes UEFI, given that LF groupthinks "firmware == UEFI".

That was bad already in BIOS times, apparently things haven't gotten better.


> ## Decisions:
> 
> * The coreboot repo will host an EDK2 fork for use as a coreboot payload.

I think the planned tighter integration is a significant first step
towards coreboot becoming UEFI.


> * Definitely no one-size fits all solution here

The challenge is great. The coreboot community must be strong and
vigilant to not allow coreboot to get locked into EDK2/UEFI like has
already happened with vboot. The vboot case arguably hurts coreboot a
lot less, but unfortunately all incentives are wrong for quality!

I don't expect this to go at all well for coreboot, but fingers crossed!


Kind regards

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

[coreboot] Re: Atomic Accesses to Local APIC

[Peter Stuge]

ron minnich wrote:
> same applies to new software applied to antiques.

While you are correct for some software and some antiques I find this
premise completely unacceptable. This attitude may be convenient for
developers but it only further normalizes planned obsolecense. Not OK!

Software can make it a high priority to be compatible. Windows is a
great example of that, and I'm sure that backwards compatibility (has)
contributes significantly to its success.

Hardware is no different and can of course also make it a priority to
be backwards compatible. If we consider the x86 instruction set in
isolation then that's another great example.

I don't see this problem as lack of compatibility but more as lack of
transparency, openness and/or collaboration - those are the
ingredients for a general hardware initialization software without all
the ridiculous fights that coreboot must endure to this day.


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

[coreboot] Re: Atomic Accesses to Local APIC

[Peter Stuge]

ron minnich wrote:
> The problem, at this point, is that a change this broad must also be
> tested across all platforms to make sure it's not breaking.

While true it could be worthwhile to check how often CONFIG_X86_GOOD_APIC
is unset...


> This looks like it was done for a hardware problem. We had a lot of
> x86 implementations in tree at that time, and they had lots of bugs.

Maybe none of them are left.


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

[coreboot] Re: how intel ME is connected to the internet ?

[Peter Stuge]

Hendra wrote:
> I read in Wikipedia that Intel ME has an independent internet connection.
> But what does "independent" mean ?
> 
> Is it an independent internet connection from the OS ?

Yes. The ME is inside the CPU or chipset and can use all hardware
devices in the system. It can use any network connection configured
by the OS without the OS ever noticing.


> or maybe it has its own secret/hidden independent networking device,
> so it can connect to the internet,
> without depending on Laptop's networking device,
> such as: wwan card, wlan card, bluetooth module, wimax card ?

I guess no, but only Intel really knows. Antennas would be tricky though.

I highly recommend reading this book by Intel to learn more about the ME:

http://www.apress.com/9781430265719


My favorite quote is on p.165, first page of the "Trust Computing" chapter:

"The owner of a platform is not always the one to protect."


Kind regards

//Peter
___
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?!?

[Peter Stuge]

Thanks for bringing this to the list, Patrick.

Stefan Reinauer wrote:
> 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.

I strongly agree.

On a more general note I find it super sad that distributions purge
Python 2 only because it is EOL upstream when it still has many use
cases. It's not a problem for me but it does demonstrate how little
critical thinking happens within distributions.

So projects must be extra critical about dependencies.


I prefer changing nothing (change != progress) or banning Python
for the coreboot build. Utilities (and payloads) not needed for the
actual coreboot build can continue to use it.

openssl + dd could probably calculate and inject hashes.


Thanks

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

[coreboot] Re: Coreboot help/teaching

[Peter Stuge]

Brian Milliron wrote:
> > coreboot supports several or even many platforms, but not all, and
> > more than likely the support for each platform covers only what is
> > required for the supported mainboards using that platform.
> 
> I see an option for an Intel Cometlake reference board in the
> menuconfig. Does that mean the platform is supported?

Yes, to some degree. I don't know the Cometlake code so can't comment
on what degree that is. But in general it's a fairly good sign that
the reference board is supported because those are not easy to get
so whoever added that support might be quite motivated to contribute
high quality, complete platform support. But no guarantee.


> It has previously been suggested to me to use the inteltool to get
> information about the GPIOs which I have done. Is this all that is
> needed or is there more?

I don't know the Cometlake platform but in general you'll need more
information, but if the platform is properly supported everything
needed may still be in the realm of what is discoverable with a
running system using factory firmware.


> I ask because I have no access to proprietary board schematics or
> other documentation, just the tools I can find on github or in
> coreboot itself. If that isn't going to give me the info I need,
> I will need to return this laptop and get another.

Nod - I hope others can comment on Cometlake specifically, but the
situation will be similar for most "mainstream" laptops - none of the
traditional mainstream PC companies provide the information needed
for coreboot work, that's always a challenge.

But again, you may be lucky and have a system where you can learn all
required information from a running system. ACPI tables can help,
maybe the tooling in coreboot can also help capture the details you
need.


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

[coreboot] Re: Coreboot help/teaching

[Peter Stuge]

Brian Milliron wrote:
> Can you elaborate on what factors determine whether setting up coreboot
> on a previously unsupported laptop takes days or years?

Mainboards are more or less modified reference designs for a given
platform, where platform means the combination of Intel or AMD chips
intended to be used together.

coreboot supports several or even many platforms, but not all, and
more than likely the support for each platform covers only what is
required for the supported mainboards using that platform.

If your platform is unsupported you have thousands of registers to study,
most of which are either not at all or merely not correctly described in
public documentation.

This case is the "years" end of the spectrum, when no source code and no
usable documentation is publically available. I'd guess that this is
actually still the common case, even though coreboot has good industry
traction. (Many companies do use coreboot but not on all possible platforms.)


If your platform is supported to some degree but your specific mainboard
is not then you have to understand the exact details of all differences
between your mainboard and the general platform support in coreboot.

Maybe there is no code for things you require or maybe it's there but
you must correctly describe how your hardware differs from a reference
design or one particular supported mainboard.

Those differences are usually never well-documented, are never
purposely published and are quite unlikely to ever leak. Leaked
schematics can be helpful, but may not always suffice.

This means another pile of unknowns to first discover and then study
in depth.

Once that's done, turn learned knowledge into working coreboot
support for your mainboard.

There is tooling (in coreboot) to help with parts of the latter.
Tools extract as much information as possible from a running system
and try to automatically turn that into coreboot support.

The "days" end of the spectrum is when you are lucky and such tools
can completely and accurately capture all required information for
your hardware without requiring much learning.


Personal experience and background are further factors, someone with
zero knowledge about hardware and zero interest to learn will likely
fail no matter how much time they invest.

Zero knowledge with significant interest is a completely different
story and can yield a successful world class coreboot developer. :)


There's no x86 firmware development "course", I think you have to
just start doing it and teach yourself as you go.


Kind regards

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

[coreboot] Re: [SPECIFICATION RFC v3] The firmware and bootloader log specification

[Peter Stuge]

Alec Brown wrote:
> Below is how the layout of these logs would store their data.
> 
> bf_log_header:
>+---+
> u32| version   |
> u32| size  |
> u8[64] | producer  |
> u8[64] | log_format|
> u64| flags |
> u64| next_bflh_addr|
> u64| log_addr  |
> u32| log_size  |
>+---+

I suggest to include a .magic at least in bf_log_header and an
.xor_checksum or .crc32 only in bf_log_header.

.magic doubles as endianess indicator when the structures are
stored on movable media. (Pick an asymmetric magic bit pattern!)

I suggest renaming .next_bflh_addr to .next_log_header and .log_addr
to .log_buffer_addr.

I suggest to remove .size and .log_size:

The rationale for .size is "to allow for backward compatibility" but
that seems redundant thanks to .version.

.log_size can be calculated from the subordinate data and is thus
mostly an unneccessary source of potential inconsistency.


> bf_log_buffer:
>+---+
> u32| version   |
> u32| size  |
> u8[64] | producer  |
> u32| next_msg_off  |
> bf_log_msg[l]  | msgs  |
>+---+

I suggest replacing .size and .next_msg_off with .messages containing l:

.size can then be calculated from .messages; again, reliably avoiding
inconsistency between .size and .next_msg_off.

Allocated size doesn't seem useful if writers must anyway maintain state
containing the starting address. If writers must be allowed to be completely
stateless then maybe at least rename .size to .allocated_size and see below
for discovery.

Having .messages also eliminates the need for an end-of-messages marker
when the allocated space is not yet filled.


> bf_log_msg:
>+---+
> u32| size  |
> u64| ts_nsec   |
> u32| level |
> u32| facility  |
> u32| msg_off   |
> u8[n]  | type  |
> u8[m]  | msg   |
>+---+

It seems inconsistent that log_header.size and log_msg.size cover only
the respective struct itself while log_buffer.size also covers all
subordinate messages. Skipping all .size in this version fixes that.

And log_msg.size is not very useful since both .type and .msg have variable
length; it's not possible to access .msg without scanning .type. Please at
a minimum add .type_size but better yet replace .size with .type_size and
.msg_size.


> There is still the outstanding issue of how the logs will be sent to the OS. 
> If
> UEFI is used, we can use config tables. If ACPI or Device Tree is used, we can
> use bf_log_header.next_bflh_addr to present the logs. If none of these 
> platforms
> are used, it becomes a lot trickier to solve this issue.
> 
> Any suggestions are much appreciated and will be taken into consideration.

Having bf_log_header.magic and some bf_log_header.$checksum, a strict rule
for bf_log_header start address granularity and a strict maximum offset
for the first header from top and/or bottom of memory allows to quickly
discover a log in memory without explicit handover.


> LPC System Boot and Security Micro-conference on the 22nd of September
> at 7:50 AM PDT (14:50 UTC).

Have fun! :)


Heinrich Schuchardt wrote:
> We already the EFI_TCG2_PROTOCOL and RFC 5424 (The syslog protocol).
> Why do we need to start from scratch?

That's a good question. I guess noone wants to settle for a standard
from somewhere else. ;)

I wouldn't mind if log_msg was a syslog transport, but I can understand
if that's rejected because syslog messages require a lot of parsing for
presentation while Alec's proposal seems focused on efficiency and simplicity.

It's also nice to be able to strictly mandate UTF-8 for all fields.
(RFC 5424 allows MSG to be anything.)


Kind regards

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

[coreboot] Re: Coreboot help/teaching

[Peter Stuge]

Hi Patrick,

Welcome to coreboot and I hope you have a lot of fun with it!

Patrick Charon wrote:
> But now, I want to go deeper again, and install it on a real machine.
> The computer I selected is an old laptop from 2005

This isn't a great way to start - I'd suggest to select a computer
known to work with coreboot rather than whatever happens to be
available, and especially not to select a laptop.

Making coreboot reliably work correctly on a previously unsupported
laptop requires significant effort and can take between days and
years (no joke) depending on a large number of factors, some of which
are out of (y)our control.

If you do want to go ahead with that hardware then please start by
constructing a workable development environment, because as you
anticipate the first attempt is not likely to be successful.

At a bare minimum you need a way to recover from a non-booting system,
ie. an external flash programmer.


> P.-S.: this address is my "professional" address; my personal address
> p...@galaxyhit.com often goes to spam. But if you answer, please use this
> personal address!

List etiquette differs from list to list, on the coreboot list the rule
is to be subscribed with the address you want to use and to not Cc:
all thread participants in replies, I've done so anyway because of your
request but please arrange for your desired address to be subscribed.
Remember that your outbound messages are resent by the mailing list
which should mitigate any bad reputation your mailhost might have.


Kind regards

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

[coreboot] Re: Supermicro X10SLM-F / Gerrit and how to contribute

[Peter Stuge]

Hi Andreas,

Andreas Bauer wrote:
> and now wonder how I can contribute a patch via Gerrit? I do not have any
> OpenID nor do I wish to use any commercial entity. Note that I am also in
> the process to divest all my data from Google, so I would prefer to not to
> use the parts of my Google account still left.
> 
> Is there a way to contribute to Coreboot Gerrit in a privacy friendly
> manner using just an email address and not having my data shared with
> any commercial entity?

OpenID can be self-hosted, I've used SimpleID in the past.

But your hosting and/or connectivity might still need some commercial entity...


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

[coreboot] Re: Build for F2A85-M Foobared, any ideas?

[Peter Stuge]

Hi Keith,

Paul Menzel wrote:
> https://review.coreboot.org/plugins/gitiles/board-status/+/71278e2819996f2e6b0ac9ff444e5d31b8073677

Keith Emery wrote:
> > It’s in the path name or logs in the directory I referenced: 
> > 4.13-917-g192177d34d refers to commit hash 192177d34d.
> 
> I've tried both hash's refrencing both sucessfull builds for F2A85-M
> board. I just get:
> 
>   error: pathspec '192177d34d' did not match any file(s) known to git
>   error: pathspec 'fdfc473380' did not match any file(s) known to git

192177d34d is the commit locally on idwer's system at the time of
testing - it's possible that he had some minor changes on top of
the upstream code, resulting in a new commit.

Fortunately, this file:

https://review.coreboot.org/plugins/gitiles/board-status/+/71278e2819996f2e6b0ac9ff444e5d31b8073677/asus/f2a85-m/4.13-917-g192177d34d/2021-01-11T01_03_00Z/revision.txt

Shows:

Upstream revision: 9a1b720b1f

And commit 9a1b720b1f is indeed some 950 commits ahead of the 4.13
tag, so I would try that out.


Kind regards

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

[coreboot] Re: Adding support for asynchronous operations

[Peter Stuge]

Raul Rangel wrote:
> I'm currently working on improving the boot time for the AMD Cezanne
> platform.
..
> Another difference between the latest AMD SoCs (Picasso, Cezanne), is
> that RAM is available in bootblock.

As I have understood, the PSP has both trained RAM and copied firmware from
SPI to RAM when x86 comes out of reset.

Is that accurate, false, or only partially accurate?

If not fully accurate then how are you accessing the SPI chip? I guess it
can't be memory mapped?


> One place where we spend a decent amount of time is reading from SPI
> flash. We have the SPI speed/modes set to the optimal settings for
> our platforms, but there is still room for improvement.

Please provide numbers?


> The question is, how do we model these asynchronous operations, how is
> data ownership handled, and how does the BSP know the operation is
> done?

I haven't yet reveiewed your API proposal, but find it an absolutely
horrible idea to create a *general* API for asynchronous operations in
coreboot, because - as you recognize - it can easily be misused to great
detriment of the codebase, which already suffers chronically from such
trivial problems as copy-paste:itis. Don't do it.

There is zero incentive for developers to improve the source beyond
making it work for their deadline; more complexity *will* create more
problems. (I understand that you have good intentions proposing this
change!)


> I'm curious to see what the community thinks, and welcome any feedback.

A special purpose DMA API is another matter to me, because it's very well
defined. It could still be useful beyond x86 and I think a blocking
"wait-for-DMA-to-finish" API is easy to understand, easy to implement and
to use, and sufficient since runtime flow is serial, especially when
measuring.


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

[coreboot] Re: Problem with booting windows 8 on Minnowmax with Coreboot+seabios

[Peter Stuge]

zahra rahimkhani wrote:
> I am trying to install windows 8 on coreboot (4.11 branch) + seabios.
..
> I investigated the error message and found Microsoft's explanation
> 
> of 0x005c error code. But I don't know how to fix it.

--8<-- From that page
Cause

   This issue occurs because the ACPI driver (Acpi.sys) incorrectly
   creates a duplicated physical device object (PDO) when some APIC IDs
   are larger than a value of 255.
-->8--


> I would appreciate it if anyone can help me figure out the solution.

You would have to dive into the ACPI table swamp in the coreboot
source for your mainboard and/or platform.

Given the above cause maybe someone else can provide a hint or even a fix.

The MSFT hotfix for the issue can unfortunately only be used on an
already installed system.


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

[coreboot] Re: link time optimization testing

[Peter Stuge]

Felix Held wrote:
> Not sure if that might be what you're looking for, but I have 
> successfully used a memSIM2 emulator on a similarly old platform.

Nod, that'll work, even though the implementation is truly gruesome...

The price is fair.


> It's basically an SRAM, some level shifters

So actually no opto-isolation as the advertising claims?


> I ended up plugging a socket with those two pins removed between the
> socket on the mainboard and the emulator.

Great idea!


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

[coreboot] Re: link time optimization testing

[Peter Stuge]

Hi Branden,

Branden Waldner wrote:
> To: coreboot 
> Cc: Paul Menzel , Angel Pons ,
>  Peter Stuge 
> Subject: Re: link time optimization testing
> Date: Sun, 6 Jun 2021 23:07:37 -0500
> 
> >> I haven't had much luck in finding options for recovery. Ideally I'd
> >> like something like the dual switched bios in the old wiki but
> >> toggle-able electronically ie. gpio pin from spare router w/ Openwrt.
> >
> >That's the product BIOS Savior RD1 from Taiwanese IOSS, switched by a
> >jumper which could be replaced by e.g. a 2N7000 FET driven by a GPIO.
> >
> >https://www.coreboot.org/Developer_Manual/Tools#BIOS_Savior
> >https://www.overclockers.com/bios-savior/
> >
> >There were a few different versions, IIRC one being for parallel 5V.
> >
> >They seem no longer available, but you could add a watch on ebay or such.
> 
> I was thinking specifically of the "dual flash 'pie'" on that page,

Ah like this:

https://www.coreboot.org/Developer_Manual/Tools/Dual_Flash

Yes, that's a nice solution, if basic.


> though really anything would be nice, even just the dip32 risers would
> probably come in handy.

A couple of "precision" style DIP32-sockets might do that job?

https://www.digikey.ca/en/products/detail/mill-max-manufacturing-corp/110-44-632-41-001000/947066


> >VultureProg was mentioned - even a DIY emulator would be fairly
> >straightforward; that's a nice microcontroller project.
> 
> That seems a bit overkill, but then again flash chips seem to be more
> expensive then microcontrollers these days. I don't think I'm up to
> working on something like that right now though.

What capabilities do you have available? Any soldering equipment at all
or not under current circumstances (hackerspace mention)?


> >Where are you located?
> 
> I'm in southern Manitoba, Canada.

Okay, so not Europe, but maybe I could send you something.


> I had been interested in checking out the hackerspace (skullspace) in
> Winnipeg sometime and seeing if anybody could help me with out with
> anything but never got around to it. It isn't really local to me
> though (~2hr drive), and isn't really an option right now for obvious
> reasons.

It's a great idea, I'm sure they would be able to help, but 2hr is
not so great and yeah not feasible at the moment anyway.


> >>> That's great to hear. I hope you didn't need to build crossgcc-i386 on
> >>> the P2B, though! :P
> >>
> >> Well, it's got a gentoo install that has to build it's own updates,
> >> including the system compiler, as well as crossgcc-i386.
> >..
> >> It would probably be a lot faster if I could get a better cpu
> >
> >You can use Gentoo releng's catalyst tool to build an i686 stage4 on
> >any x86_64 build machine in half an hour or so, you'll just need to use
> >a profile with i686 (17.0 should work) and possibly an older snapshot.
> >
> >If you're interested in trying that I could help with a spec file,
> >catalyst isn't very well documented.
> 
> I'm not sure that catalyst is really what I want, though it did occur
> to me now that you mentioned that I could probably use it for a
> different project.
> 
> It would be nice if you could just have portage/emerge on the client
> system request the build server to just make and send binary packages
> it wants to update - either everything or just whatever has a history
> of taking more then a certain amount of time on the client - even if
> it needed to cross compile and/or use qemu. I've seen at least one
> project that attempted this, but it was abandoned.

There's no way for emerge on the client to trigger catalyst on the
build server, but the second half works out of the box; catalyst
always creates binary packages, which are used by the client emerge
by setting PORTAGE_BINHOST in make.conf.

So you have to trigger the build some other way (manually, or with
other automation) but then have binary packages for easy installation
on the client.


> So far I've gotten by just by leaving it running to finish whatever it
> is working on,.

It works well - but takes a long time. :)


> PS. I hope the quoting turns out alright, I really need to get a
> proper email client setup yet. I had to  do it all manually, since
> it wouldn't pull from the digest properly for some reason.

Ouch - yes the digest is not very easy to use - it also has a
different message ID than the original posts, so not only is quoting
a hassle (yours was fine though!) but the digests break threading too.

I completely understand if you don't want lots of individual mails though.


Kind regards

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

[coreboot] Re: DiskonChip 2000 testing (& old coreboot_v1/linux_bios)

[Peter Stuge]

Branden Waldner wrote:
> I purchased a diskonchip 2000 266mb a while ago just to mess around with.
..
> In the first place, I think my assumption of it exposing a large rom
> was wrong, it looks like they only actually only expose a small amount
> as regular bios boot rom space. While that sounds annoying, it would
> probably still be workable though.

On hardware level the device exposes only a window of its full capacity
at a time. The electrical interface which it plugs into only has a
limited address space. Software must have not only a driver for the
device which knows how to move the window around but also an
abstraction layer for memory access so that the driver can move the
window at the correct time.

This is not in place for current coreboot boards.


> Going by the "HOWTO" documentation in the coreboot_v1 branch I figured
> I could just hotswap it and load the diskonchip kernel module,

Good thinking, I believe this ought to work as long as the driver
supports your device.


> but I can't find any information about whether that actually supports
> the diskonchip 2000 or has been tested recently.

Also good thinking - please be aware that DiskOnChip and DiskOnChip 2000
are different products which are *not* compatible.


> I tried the dos utils on freedos as well and couldn't get them to
> detect it either.

If that doesn't work, nothing else will.


> I'm hoping that somebody still remembers a bit about them and maybe
> knows something about how I can get the chip working, confirm that
> it's not working, or just tell me I'm doing it wrong.

You're not doing it wrong, perhaps you need to look for more/other
drivers and DOS utilities, perhaps the device is broken.

In the end, the experience in the coreboot community with these devices
suggested to me that they are not actually worthwhile.

The requirement for two kinds of explicit software support with one
being a fundamental abstraction of memory access make them difficult
and very annoying to work with. Really only an option for completely
custom systems.


> I'm also hoping that it's not too off topic.

Don't worry, not at all.


In another mail I asked you where you're located but didn't notice a reply.
Are you in the US? I've been thinking about your P2B situation and maybe I
can help you out there.


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

[coreboot] Re: link time optimization testing - Was: Re: asus/p2b - not enough space in cbfs for default build since i440bx bootblock console enable

[Peter Stuge]

Branden Waldner wrote:
> I haven't had much luck in finding options for recovery. Ideally I'd
> like something like the dual switched bios in the old wiki but
> toggle-able electronically ie. gpio pin from spare router w/ Openwrt.

That's the product BIOS Savior RD1 from Taiwanese IOSS, switched by a
jumper which could be replaced by e.g. a 2N7000 FET driven by a GPIO.

https://www.coreboot.org/Developer_Manual/Tools#BIOS_Savior
https://www.overclockers.com/bios-savior/

There were a few different versions, IIRC one being for parallel 5V.

They seem no longer available, but you could add a watch on ebay or such.

VultureProg was mentioned - even a DIY emulator would be fairly
straightforward; that's a nice microcontroller project.

Where are you located?


Branden Waldner wrote:
> > That's great to hear. I hope you didn't need to build crossgcc-i386 on
> > the P2B, though! :P
> 
> Well, it's got a gentoo install that has to build it's own updates,
> including the system compiler, as well as crossgcc-i386.
..
> It would probably be a lot faster if I could get a better cpu

You can use Gentoo releng's catalyst tool to build an i686 stage4 on
any x86_64 build machine in half an hour or so, you'll just need to use
a profile with i686 (17.0 should work) and possibly an older snapshot.

If you're interested in trying that I could help with a spec file,
catalyst isn't very well documented.


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

[coreboot] Re: cgit on review.coreboot.org

[Peter Stuge]

Patrick Georgi via coreboot wrote:
> We could consider setting up a separate domain for that purpose and provide
> raw files there

I think that would be great..


> but as an immediate workaround, all our repos are mirrored
> ~hourly to github.com/coreboot, too (and therefore are available
> through raw.githubusercontent.com)

..since it's not great to depend on github.com.


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

[coreboot] Re: Printing u32 on 32-bit and 64-bit without cast

[Peter Stuge]

Hi Paul,

Paul Menzel wrote:
> printk(BIOS_DEBUG, "%s: stack_end = 0x%lx\n", __func__, 
> stub_params->stack_top - total_stack_size);
> 
> Using `PRIx32` fixes the build with 64-bit but now it fails with 32-bit, 
> as commit 3a323808 (include, lib: Add  printf macros) [2] adds
> 
>  src/include/inttypes.h:#define PRIx32  "x"
> 
> which is dependent on the architecture(?),

Isn't the purpose of those PRI defines that they are always correct?

If they aren't correct in some cases then they should probably just
be fixed? I guess that -m32 with a x86_64 toolchain may need to be
detected differently than a i686 toolchain.


> and is not the right length modifier for u32 on 32-bit.

Huh? What is?

AFAIK %x is fine for a 32-bit value, both with i686 and x86_64.

%lx is always for a (signed or unsigned) long value, which obviously
differs between i686 and x86_64.

%llx is always for a long long value, which AFAIK is 64-bit on all
systems, but sure, not neccessarily guaranteed to be.


> Is there an elegant way around it besides casting the values?

If the PRI-defines are wrong in some cases they should be fixed.

Code explicitly using a l or ll length modifier for fixed-size values
is incorrect and should also be fixed.


> Do we need specific headers for 32-bit or 64-bit?

No, but maybe more cases in the existing header.


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

[coreboot] Re: What should we do about freenode IRC services?

[Peter Stuge]

Patrick Georgi via coreboot wrote:
> So, what should we do?

I don't think it's a horrible idea to just chill and see what happens. I
find it interesting that christel seems invested in the Handshake project.


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

[coreboot] Re: failure cherry-picking patches from https://review.coreboot.org/coreboot

[Peter Stuge]

Hi Selma,

Bensaid, Selma wrote:
> FYI, we are observing the same issue today on chromium coreboot repo 
> https://chromium-review.googlesource.com/admin/repos/chromiumos/third_party/coreboot
> I think we need to figure out a proper solution.

Thanks for providing the debug output!

So since the issue does stem from a large distance between branches
and hitting network communication limits maybe an effective workaround
would be to maintain a local clone of the upstream repo (in a separate repo)
and using a file:// URL pointing to that repo for the origin remote in your
working repo?

The upstream clone must be on the same machine, so it's more overhead,
but file:// should be reliable.

HTTP, regardless of version, is really inappropriate for applications.


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

[coreboot] Re: failure cherry-picking patches from https://review.coreboot.org/coreboot

[Peter Stuge]

Aaron Durbin via coreboot wrote:
> > We are observing since 3 days instabilities while cherry-picking patches
> > from coreboot.org:
> >
> > git fetch https://review.coreboot.org/coreboot refs/changes/40/52140/3 &&
> > git cherry-pick FETCH_HEAD
> >
> > fatal: The remote end hung up unexpectedly
> >
> > fatal: protocol error: bad pack header
> >
> > This is happening on several machines, our automation is also impacted.
> > Any change/issue that could explain such behavior?
> 
> I think it's on your end, Selma. Perhaps the git repo got corrupted?
..
> The root cause is likely the first error: remote end hung up unexpectedly.
> The following might be helpful.
> 
> https://stackoverflow.com/questions/6842687/the-remote-end-hung-up-unexpectedly-while-git-cloning

My guess is either a change in an outgoing proxy at Intel or that all
your repos changed in the same way at the same time to now interact
badly with how outgoing proxying has always worked. (HTTP request larger
than http.postBuffer git config setting leading to HTTP/1.1 chunked transfer.)


> Also if there's a way to get more verbose logging out that might
> help point in the right direction.

Do try (from that stackoverflow):

# Linux 
export GIT_TRACE_PACKET=1   
export GIT_TRACE=1  
export GIT_CURL_VERBOSE=1   

#Windows
set GIT_TRACE_PACKET=1  
set GIT_TRACE=1 
set GIT_CURL_VERBOSE=1  

Before the git command, and see what comes out.


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

[coreboot] Re: [RFC] How should we manage tree-wide changes?

[Peter Stuge]

Piotr Król wrote:
> I don't understand argument about running significant ("enough") of
> the infrastructure. Why maintainers of platforms do not run their
> part of infrastructure which support those platforms?

I think this is a key point. It's a lot easier to develop centralized
solutions, so that's a common mistake. And even if not strictly or
intentionally centralized then there's often at least a knowledge gap,
case in point your request for more integration information.


> > If you want to maintain any particular release as a long term branch,
> > announce your intent and we'll set up a branch!
> 
> I'm not sure what benefit it would give to community or to us, but we
> have to maintain v4.0.x probably until PC Engines hardware EOL.

I think it would be fantastic if that happened on coreboot.org!

Maybe it would not benefit you in any way immediately, but it would
probably not be a disadvantage for you either, and it would for sure
look great for the project as a whole.

And maybe, just maybe, some colleagues will pitch in because they see
value in what is then in practice a stable branch.


> What I really try is to highlight various problems 3mdeb see over 6
> years of coreboot development.

That's super valuable and I'm much appreciate your input!


> Toolchain stability and reproducibility is something I discussed. I even
> started to write something here:
> https://docs.dasharo.com/osf-trolling-list/build_process/

Yes. Docker is a dark pattern, yet like `curl | bash` it prevails.


> Yeah, our coreboot-sdk has problem having only python3, SeaBIOS do not
> understand that:
> https://github.com/coreboot/seabios/blob/master/Makefile#L25
> 
> At least this was problem on 4.13 tag.

I appreciate that SeaBIOS likes to still support python2, but when
all distributions choose to end support for python2 it'll take more
effort in SeaBIOS. It could be simple though, maybe the attached patch
is already enough? It looks like all python scripts are called through
$(PYTHON) rather than executed directly, so the #! command doesn't
actually matter so much.


//Peter
From 6a828363bd7a6fc18d85a7c2e63a2c05438f7b1a Mon Sep 17 00:00:00 2001
From: Peter Stuge 
Date: Fri, 7 May 2021 01:23:00 +0200
Subject: [PATCH] build: set PYTHON to python3 || python2

---
 Makefile | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/Makefile b/Makefile
index 3d8943e..6397b1e 100644
--- a/Makefile
+++ b/Makefile
@@ -22,7 +22,7 @@ LD=$(CROSS_PREFIX)ld
 OBJCOPY=$(CROSS_PREFIX)objcopy
 OBJDUMP=$(CROSS_PREFIX)objdump
 STRIP=$(CROSS_PREFIX)strip
-PYTHON=python
+PYTHON=$(shell which python3 >/dev/null 2>&1 && echo python3 || echo python2)
 CPP=cpp
 IASL:=iasl
 LD32BIT_FLAG:=-melf_i386
-- 

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

[coreboot] Re: [RFC] How should we manage tree-wide changes?

[Peter Stuge]

Nico Huber wrote:
> > Another idea brought up was to require that such changes come with
> > documentation and, ideally, migration support in the form of scripts and
> > the like. We had something like this in the past[2] and I created a
> > proposal[3] to establish it as a rule and build a culture around
> > documenting sweeping changes.
> 
> I think it's nice to use a script and if one does, sharing it is
> obviously a good thing. But demanding that would again burden up-
> stream development.

Do you place spatch in this category?

I mean, do you see it as too burdensome to mandate that changes
affecting the tree more than some TBD threshold are to be generated
by an spatch which must also be contributed?

Clearly it is one step more to create that spatch instead of just
changing all the files, but in my experience it pays off very quickly;
it will never miss any files and it pays forward, helping others in
the community who share the goal but can't yet push/publish.

Not only does coccinelle understand the C language but it's indeed built
for the very purpose of refactoring C code across large codebases.
I admit that I am biased though; I find semantic patching quite fun. :)


Werner mentioned that it might take longer to write an spatch than
change something in two boards. If we do decide to try to reduce efforts
through spatches then we could start out by having a high-ish threshold
for what changes must include an spatch and also set a sensible date
for review of outcomes of the experiment?


> I think we first need a very precise description of the problem.

I think that's fair, although I can imagine upstream changes to cause
problems when working on a board for a platform that's newish with
platform support upstream moving around.


> My guess is that somebody is trying to rebase downstream work rather
> often. Is that the case? If so, I'd ask what the reasons for each rebase
> are.

If so, I guess to not stray too far from master.


Nico Huber wrote:
> I've seen some company size arguments on Gerrit. From my perspective,
> it doesn't get much smaller than the firmware department I work for.

Thanks for sharing your situation!

Are your boards usually on the newest platforms, or more often on more
mature platforms?


> There's a wrinkle: To upstream as much as possible, this often includes
> changes that affect all boards of a new platform. That's why I'm arguing
> against making such changes harder.

So I have to ask again, do you really mean that requiring spatches is
"making such changes harder" ?


> You mentioned 4k LOC of downstream patches on Gerrit. Maybe we should
> try to figure out case-by-case what led to keeping them downstream?
> Maybe we can find upstream solutions for some of them?

Certainly a good idea!


Thanks

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

[coreboot] Re: Default-timings in Designware I2C driver

[Peter Stuge]

Zeh, Werner wrote:
> there are cases where the calculated and reported timing can be
> suitable for a given speed in coreboot and a speed switch to HIGH
> in OS ... will lead to a different timing, worse case not matching
> the hardware circumstances and therefore ending up in violating
> the I2C spec.

I think this is an important point, if the OS driver does not
calculate different parameters, but relies on what coreboot prepares.

In that case, coreboot should make an effort to prepare correctly for
all speeds, possibly by pushing this responsibility onto whoever adds
a new mainboard and/or informing the OS driver about which speeds
have actually been correctly prepared by coreboot.

coreboot should indeed not prepare for only some of the possible cases
at runtime and then stick its head in the sand yolo style.

Does the coreboot code communicate something to the OS driver already?


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

[coreboot] Re: [Events] "vBeer v2" online Party! - 7th May at 3PM UTC

[Peter Stuge]

Mike Banon wrote:
> Dear friends, on behalf of 3mdeb I invite you to a fresh "vBeer v2"!

v1 sounds like fun, I'll try to join v2, but maybe not for 12h! Wow! :)


> * new advances at opensource firmware/hardware world, like this new
> initiative [2] for opensource FPGAs
..
> [2] https://osfpga.org/osfpga-foundation-launched/

It's interesting that DARPA is (becoming?) transparent about the EDA
design crisis and about funding open source (hardware) to spur innovation
in the defense and commercial industries. https://youtu.be/xKxv7Bdm7Do

By doing so they essentially declare commercial, proprietary software a
failed model, at least in the long term.


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

[coreboot] Re: [RFC] How should we manage tree-wide changes?

[Peter Stuge]

Patrick Georgi via coreboot wrote:
> tree-wide changes
..
> there may be other approaches on how to make development easier

I'm a big fan of semantic patching as provided by coccinelle and used
heavily in Linux kernel development.

Perhaps one way to make lives easier is to require tree-wide changes
to be the result of an spatch, which can then be applied downstream too?


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

[coreboot] Re: Status of Tianocore EDK2 on Coreboot

[Peter Stuge]

Julian Stecklina wrote:
> Is there any deeper reason why fixes don't flow back to EDK2?

I'm guessing here - I have no experience with EDK2 development - but
I suspect that it's not actually an open source project, I think it's
just source code by Intel+Microsoft+friends published on GitHub.

The traditional firmware industry isn't so good at community efforts.


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

[coreboot] Re: Building Coreboot with Nix

[Peter Stuge]

Julian Stecklina wrote:
> I'm trying to build Coreboot with Nix [1] and am facing some issues. I'm
> wondering whether someone has already tried this before and can give some
> pointers.

I don't think so.


> My specific problem is how to nicely package the toolchain that
> coreboot requires.
> 
> Any hints are appreciated. :)

How does Nix deal with other cross-toolchains? That's essentially
what the coreboot toolchain is, so maybe you can find inspiration
there.


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

[coreboot] Re: Coreboot on newer hardware after some hardware mods?

[Peter Stuge]

Nico Huber wrote:
> > if the system integrator has enabled BootGuard in the
> > "wrong" way then the signature verification is intended to make it
> > impossible to install coreboot onto the system.
> 
> This seems a bit misleading. BootGuard is independent of the flash
> chip and write access to it.

You're of course correct. I didn't express my point very well.

I wanted to make clear that, as you write, BootGuard is intended to
disallow any firmware other than from the integrator, and bar some bug
in chipset lockdown or SMM it can be expected to indeed be effective.

BootGuard itself doesn't control flash write access, but its idea is
contrary toleaving the flash chip accessible e.g. by flashrom, and by
now I think it's fair to expect that machines using BootGuard will
also lock down flash write access such that only correctly (as decided
by the manufacturer) signed firmware can be flashed in a running system.

Whether BootGuard allows a foreign firmware to boot is the next hurdle,
and if no then no soldering iron helps.

I second Nico: Do everyone a favour and buy hardware actually designed
for coreboot if you want coreboot. :)


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

[coreboot] Re: Coreboot on newer hardware after some hardware mods?

[Peter Stuge]

maxime.corne--- via coreboot wrote:
> I know this question had been asked many times, but is it possible
> to have Coreboot on modern hardware?

The general answer is yes, it is possible under certain conditions.

What those conditions are depends both on the particular hardware platform
(CPU+chipset generation) and on what decisions the system integrator
(ODM and/or OEM) has made before shipping the machine.

Fairly modern consumer products are indeed supported in the coreboot
master tree.


Another set of conditions determines *how* a coreboot image could be
installed onto a machine which was sold without coreboot.

Regardless of those conditions, desoldering the flash chip and either
reprogramming it externally or soldering a new, already programmed
flash chip onto the mainboard will always work, assuming of course
that the flash is a discrete component, which is not always the case.

The boot flash is sometimes part of an embedded controller - I've
only seen this on some Thinkpads so far.


> After some research on the Internet, I found out coreboot couldn’t
> be port to modern hardware because of an Intel technology which
> encrypt the bios (I might be wrong, if so, sorry).

Encryption (signatures actually, not encryption) isn't relevant for
porting, but if the system integrator has enabled BootGuard in the
"wrong" way then the signature verification is intended to make it
impossible to install coreboot onto the system. In that case, and a
few others, the only option is to desolder the flash chip and work
with external programming options.


> On the other end, companies like System76 are able to ship modern
> processor with Coreboot.

Because they are the system integrator they are allowed to make the
neccessary decisions to enable coreboot on their machines, and they
are better positioned to have access to the relevant information for
porting coreboot - but don't be fooled, the platform vendors (Intel,
AMD) do not release the neccessary information for coreboot porting
to anyone at all. Anyone who asks for it is told the same old lie:
"Nobody is asking for that information so we don't make it available."


> I’d be more than happy to tinker with my hardware, so how you would
> you do to put coreboot on a recent thinkpad by replacing the bios chip?

Desolder the flash chip and create a header solution for the 5
relevant pins so that you can move the flash chip between your laptop
and a programmer like a beaglebone or worst case raspberrypi, make a
backup of the original contents outside your laptop, download and build
coreboot, program the flash outside your laptop, connect it to the
laptop, try to boot, and start debugging why the boot fails... ;)


Hope this helps

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

[coreboot] Re: HP compaq 8200 compatability

[Peter Stuge]

ppbruhuwu--- via coreboot wrote:
> Hello so i was talking to my friend about coreboot but i saw that
> only the SFF version of the compaq 8200 was compatible and so i
> wanted to know why that is?

Those adding that code were only interested in supporting that model.

> Also will coreboot be available for the compaq 8200 in the future?

It could, if you or someone else makes it happen. If you're interested
then you should not wait for someone else to do it for you, since
that's unlikely.


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

[coreboot] Re: On handling vendorcode

[Peter Stuge]

Patrick Georgi via coreboot wrote:
> Any objections to moving the code out there that has no other upstream
> (e.g. src/vendorcode/google/chromeos or src/vendorcode/eltan, I think?)
> while moving in code from elsewhere in the tree that fits the "it has a
> foreign upstream" description (e.g. the lzma library)?

I think that can make sense, but where would the chromeos, eltan and
other directories go instead? Someplace existing, or someplace new?


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

[coreboot] Re: Intel ME, once more (Re: Coreboot on new laptops)

[Peter Stuge]

Nico Huber wrote:
> First thing to understand is that the Intel ME is no spyware and nothing
> evil per se.
..
> FWIW, people mostly call it spyware or backdoor because they bought
> a computer, didn't read the manual, and were later taken by surprise
> when they learned what their computer can do. There are scary things,
> that's true, but they are usually advertised (e.g. Remote Management,
> Anti-Theft, these things are sold, not hidden).

I'd like to remind everyone of what I call "the ME book":

Platform Embedded Security Technology Revealed
ISBN: 9781430265719
http://www.apress.com/9781430265719

The book is essentially a collection of ME whitepapers to make Intel's
customers feel good about Intel platforms.

It provides fairly good insight into the ME, functionally and conceptually,
and while it doesn't include a detailed roadmap the book still shows a
general direction for the ME into the future. Perhaps most importantly,
the book makes very clear who Intel's customer is, or isn't, like in my
favorite quote from page 165 at the start of the "Trust Computing" chapter:

"The owner of a platform is not always the one to protect."

I celebrate this honesty. This helps clarify that Intel platforms are
not meant to be controlled by, and to protect, their owners.

Which may also explain why some Intel platforms capabilities have never
been communicated to prospective platform owners in a very clear and
understandable way. I think people quite justifiably feel betrayed by
the many layers of marketing BS about vPro and AMT.

Intel platforms clearly optimize for an interest other than that of
platform owners. Intel may not actively hinder accidental alignment
of those different interests, but it's clear that these are products
not made for you, the owner, you're just the sucker paying for them.

I can completely understand that people disagree.


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

[coreboot] Re: EC config registers?

[Peter Stuge]

crabstorage@getbackinthe.kitchen wrote:
> In devicetree.cb there are changes to the config0-config3 registers.
> Is this notable

Mh, it's all EC stuff like hotkeys, fan control, backlight control, etc.


> and can it cause pcie issues?

In theory not impossible, but I doubt it.


> Also the subsystemid is listed for devices in autoport, is it
> superfluous or should I append it to the current devicetree?

Subsystem IDs are largely cosmetic, but may be needed for some drivers
to load.


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

[coreboot] Re: Coreboot with VIA-Processors available?

[Peter Stuge]

Hallo Sherzod,

Burkhanov, Sherzod wrote:
> I would like to ask is it possible to use coreboot also with VIA-Processors?

In principle yes, and in practice at least there was code for them in
the repo before - but I don't know what the current situation is...

Since VIA stopped their x86 CPU efforts the number of people working
on support for VIA hardware in coreboot shrunk.


> And how is to install coreboot onto motherboard EPIA M920?  Maybe is there
> video tutorials for that?

If the mainboard is actually supported (it might be, I'm not sure)
then the process is the same as for all mainboards:

* set up an environment where you can recover from a non-functional firmware
  (this involves being able to reprogram the boot flash independently of the
  mainboard itself)

* make a backup of the factory bios

* verify that the backup is correct

* build or download a coreboot image you want to test

* keep fingers crossed while rebooting

usually this is followed by:

* debug, rebuild, then test again


> Is it also possible to use coreboot on MacBooks?

It has been done on a few, but nothing recent AFAIK. Also, Apple is
quite determined to lock users out of their hardware, so this is a
really unneccessary uphill endeavor, especially because they're just
another Intel based system.


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