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

[Aaron Durbin via coreboot]

On Thu, May 20, 2021 at 11:05 PM Bensaid, Selma 
wrote:

> Thanks Peter and Aaaron!
> For more context we observe this failure on our local coreboot hosted in
> GitHub (Intel Org). Cherry-picking from coreboot.org worked well until
> few days ago, where the failure showed up.
> Looking into the logs (that I cannot attach) and if I understand well
> while fetching from a remote git looks for a common ancestor between the
> local repo and the remote. In our case this common ancestor is quite old (
> https://review.coreboot.org/c/coreboot/+/34368). It seems that the remote
> (coreboot.org) has a timeout mechanism that triggers before we find the
> common ancestor.
> I think I figured out a dirty WA ☹, any idea will be more than welcome!
>

This is not original thought, but since the ancestor is so old maybe it is
the solution in the article: raise limits to get all the SHAs of the trees
and objects. If it's too big then that might cause the hangup. I think it'd
be good for someone on your end to do a proper rebase. Once that's complete
I expect the fetchting to start working again.

> Thanks,
> Selma.
>
>
> -Original Message-
> From: Peter Stuge 
> Sent: Thursday, May 20, 2021 10:57 AM
> To: coreboot@coreboot.org
> Subject: [coreboot] Re: failure cherry-picking patches from
> https://review.coreboot.org/coreboot
>
> 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-une
> > xpectedly-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 mailing list -- coreboot@coreboot.org
> To unsubscribe send an email to coreboot-le...@coreboot.org
>
___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

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

[Aaron Durbin via coreboot]

On Wed, May 19, 2021 at 6:25 PM Bensaid, Selma 
wrote:

> Hi,
>
> 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? I just
tried your instructions and the fetch was successful.

The root cause is likely the first error: remote end hung up unexpectedly.
The following might be helpful. Also if there's a way to get more verbose
logging out that might help point in the right direction.

https://stackoverflow.com/questions/6842687/the-remote-end-hung-up-unexpectedly-while-git-cloning

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

[coreboot] Re: [RFC] Replace strapping entries in coreboot table

[Aaron Durbin via coreboot]

On Thu, Oct 22, 2020 at 4:01 PM Tim Wawrzynczak via coreboot <
coreboot@coreboot.org> wrote:

>
>
> On Thu, Oct 22, 2020 at 2:01 PM Nico Huber  wrote:
>
>> On 22.10.20 02:25, Tim Wawrzynczak wrote:
>> > On Wed, Oct 21, 2020 at 4:54 PM Nico Huber  wrote:
>> >
>> >> On 22.10.20 00:29, Tim Wawrzynczak wrote:
>> >>> On Wed, Oct 21, 2020 at 4:00 PM Nico Huber  wrote:
>> >>>
>>  On 21.10.20 21:19, Tim Wawrzynczak via coreboot wrote:
>> > Currently there are 3 different "strapping" entries in the coreboot
>>  tables,
>> > and with the recent addition of fw_config (
>> > https://review.coreboot.org/c/coreboot/+/41209), we would also
>> like to
>>  add
>> > the 64-bit fw_config field (updated here
>> > https://review.coreboot.org/c/coreboot/+/45939) to the coreboot
>> table
>> >> as
>> > well.
>> >
>> > In this patch (https://review.coreboot.org/c/coreboot/+/46605), I
>> am
>> > proposing to deprecate the 3 current "strapping" entries (board ID,
>> ram
>> > code and SKU ID), and add them all to 1 entry, containing board ID,
>> ram
>> > code, SKU ID as well as fw_config. This saves the overhead of
>> parsing 4
>> > different entries to obtain board configuration information.
>> >
>> > Would like to hear any thoughts on this,
>> 
>>  I'm actually very confused about these things and how they are
>> supposed
>>  to be used. Is it correct to say that there are / would be coreboot
>>  table entries with board-specific encodings?
>> >>>
>> >>>
>> >>> There already are :) Board ID, SKU ID, and RAM Code are inherently
>> >>> mainboard (family) or vendor specific
>> >>> conventions. I see FW_CONFIG as yet another one of these strapping
>> >> fields.
>> >>>
>> >>>
>>  Wouldn't it be better to
>>  decode the infos first and put that into tables so generic drivers
>> can
>>  consume them?
>> >>>
>> >>>
>> >>> That's an interesting thought, Nico. Can I assume you're talking about
>> >> the
>> >>> coreboot table here?
>> >>
>> >> Yes? Are you? ;)
>> >>
>> >
>> > I wasn't sure if you were implying I decode the ACPI tables :P (which I
>> > obviously
>> > can't do on ARM, although I guess they have a DT).
>>
>> Not my intention. But actually: if the information you need in
>> Depthcharge is available in these other tables, you should use
>> them by definition. The comment in `coreboot_tables.h` suggests
>> that it's only for information that isn't available otherwise.
>> I don't fully agree with it, but whoever wrote it had a point.
>>
>
> Adding an ACPI parser to depthcharge is way overkill, IMHO.
> git blame shows that comment was from Aaron, maybe he
> could chime in here.
>

I moved the file. Those comments were sitting in there already as far as I
remember: https://review.coreboot.org/c/coreboot/+/11592/

The specific things Tim was referring to are not in other tables, but they
can be obtained from other sources. Real question is if we want to
duplicate the act of requerying all the information and duplicating the
code to do that. I would say that's not really great. The whole
coreboot/libpayload split rears its head again in forcing duplicative work
and code. That's a broader topic in general.


>
>> >
>> >
>> >>>
>> >>> What I'm trying to accomplish here is to be able to pass the FW_CONFIG
>> >>> value from coreboot
>> >>> to the payload, in my case, obviously depthcharge. You can see some of
>> >> our
>> >>> uses for fw_config
>> >>> in coreboot already, in mb/google/volteer for example. Some of the
>> fields
>> >>> are distinguishing which
>> >>> daughterboard or audio device is on a given mainboard, which in these
>> >> cases
>> >>> is not enumerable
>> >>> information, hence my thought to pass the fw_config value to the
>> payload.
>> >>> This alleviates needing
>> >>> the payload to know where this information came from, as coreboot has
>> >>> already done the work
>> >>> to figure that out.
>> >>
>> >> The question is, does depthcharge need to know the daughterboard id? or
>> >> does it actually need to know something that is implied by that id and
>> >> could be written into the table explicitly?
>> >>
>> >
>> > Sure, the ID contains implicit information. It would be possible to add
>> a
>> > whole bunch of
>> > new entry types into the coreboot table, but which way to take that?
>> > Let's look at volteer as a strawman; I want to to able to tell
>> depthcharge
>> > which audio chip & interface (I2S vs. SNDW) it has. I could go two
>> > different ways with that:
>> > 1) Create an audio device table, which just contains board- or vendor-
>> > specific IDs in it, and doesn't really shift the issue away from
>> > board-specific encodings
>>
>> I don't see why such a table would have to be board specific. Even if
>> these chip models don't have a unique id, couldn't we enumerate them
>> globally in coreboot?
>>
>> > 2) reinvent ACPI / DT and encode the device structure & properties in a
>> > binary structure
>> > or even add 

[coreboot] Re: [RFC] Replace strapping entries in coreboot table

[Aaron Durbin via coreboot]

On Wed, Oct 21, 2020 at 2:37 PM Tim Wawrzynczak 
wrote:

> On Wed, Oct 21, 2020 at 1:50 PM Aaron Durbin  wrote:
>
>>
>>
>> On Wed, Oct 21, 2020 at 1:20 PM Tim Wawrzynczak via coreboot <
>> coreboot@coreboot.org> wrote:
>>
>>> Hi coreboot community,
>>>
>>> Currently there are 3 different "strapping" entries in the coreboot
>>> tables, and with the recent addition of fw_config (
>>> https://review.coreboot.org/c/coreboot/+/41209), we would also like to
>>> add the 64-bit fw_config field (updated here
>>> https://review.coreboot.org/c/coreboot/+/45939) to the coreboot table
>>> as well.
>>>
>>> In this patch (https://review.coreboot.org/c/coreboot/+/46605), I am
>>> proposing to deprecate the 3 current "strapping" entries (board ID, ram
>>> code and SKU ID), and add them all to 1 entry, containing board ID, ram
>>> code, SKU ID as well as fw_config. This saves the overhead of parsing 4
>>> different entries to obtain board configuration information.
>>>
>>
>> Not all of these entities are sourced through the same mechanism (gpios
>> vs cbi).  As such any time you want to read one of those fields you'll be
>> unconditionally needing to obtain all of those while at the time the user
>> may only want one field. And then this can happen from multiple stages.
>>
>
> The patch I'm proposing doesn't change whether or not the functions
> `board_id()`, `ram_code()`, `sku_id()` are called or not, or their
> definition. It will, however, currently waste 12 bytes of space if none of
> the weak functions are overridden.
> However, if a board uses all 4 IDs, then this patch saves 20 bytes of
> space in the table on redundant tags/sizes in the records. I guess this is
> the tradeoff here.
>
>
>> I would say that since these things aren't all related to answering the
>> question someone may want to answer that we shouldn't go down this path.
>> Width of fields, e.g., could be different across platforms since not
>> everything is consistent.
>>
>
> I'm not sure I follow; board_id, ram_code and sku_id are all currently
> defined as 32 bits in coreboot/libpayload.
>

Sorry. I missed that this topic was pertaining to coreboot tables -- not
runtime in coreboot. And I didn't read the patch. :)

I think it doesn't matter how the tables are encoded.


>
>> Would like to hear any thoughts on this,
>>>  - Tim
>>> ___
>>> coreboot mailing list -- coreboot@coreboot.org
>>> To unsubscribe send an email to coreboot-le...@coreboot.org
>>>
>>
___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] Re: [RFC] Replace strapping entries in coreboot table

[Aaron Durbin via coreboot]

On Wed, Oct 21, 2020 at 1:20 PM Tim Wawrzynczak via coreboot <
coreboot@coreboot.org> wrote:

> Hi coreboot community,
>
> Currently there are 3 different "strapping" entries in the coreboot
> tables, and with the recent addition of fw_config (
> https://review.coreboot.org/c/coreboot/+/41209), we would also like to
> add the 64-bit fw_config field (updated here
> https://review.coreboot.org/c/coreboot/+/45939) to the coreboot table as
> well.
>
> In this patch (https://review.coreboot.org/c/coreboot/+/46605), I am
> proposing to deprecate the 3 current "strapping" entries (board ID, ram
> code and SKU ID), and add them all to 1 entry, containing board ID, ram
> code, SKU ID as well as fw_config. This saves the overhead of parsing 4
> different entries to obtain board configuration information.
>

Not all of these entities are sourced through the same mechanism (gpios vs
cbi).  As such any time you want to read one of those fields you'll be
unconditionally needing to obtain all of those while at the time the user
may only want one field. And then this can happen from multiple stages.

I would say that since these things aren't all related to answering the
question someone may want to answer that we shouldn't go down this path.
Width of fields, e.g., could be different across platforms since not
everything is consistent.

>
> Would like to hear any thoughts on this,
>  - Tim
> ___
> coreboot mailing list -- coreboot@coreboot.org
> To unsubscribe send an email to coreboot-le...@coreboot.org
>
___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] Re: Resource allocator: Getting v4 back in

[Aaron Durbin via coreboot]

On Fri, May 22, 2020 at 10:01 AM Nico Huber  wrote:

> On 19.05.20 02:07, Furquan Shaikh wrote:
> > On Sun, May 17, 2020 at 2:01 PM Nico Huber  wrote:
> >> I told people that I had something similar in mind. But actually, I
> >> don't like it very much. I fear, if we move things aside, they can be
> >> left behind and we might soon have to discuss platform deprecation
> >> again.
> >
> > Having both old and new allocators gives us the option to move the
> > chipsets/boards to the older one in case issues are identified even
> > later on and not in the first pass of testing. So, I like the idea of
> > having both allocators in the tree at least for a while.
>
> ok, let's do this.
>
> > As mentioned
> > above, the old allocator is currently limited to only the AMD chipsets
> > that are known to have breakages and require more than a quick fix:
> > https://review.coreboot.org/c/coreboot/+/41444. The other chipsets
> > that were identified as problematic last week have all been fixed
> > since: https://review.coreboot.org/c/coreboot/+/41374.
> >
> > Another reason why I like having both in the tree is it serves as a
> > quick A/B test without anyone having to revert series of patches just
> > to test the old allocator.
>
> That's a great idea. I will likely pick up the opportunity to add more,
> optional things to test.
>
> >> It would also be harder to make changes in generic code like
> >> device/pci_device when one has to be sure that both allocators work
> >> fine.
> >
> > For the most part, the rest of the code should not really be aware of
> > the internals of any of the allocators. (In practice it is not always
> > true). I understand that we had some assumptions in find_pci_tolm()
> > and how invalid resources are handled. With the following changes:
> > https://review.coreboot.org/c/coreboot/+/41524, those assumptions
> > should no longer be required. We just need a set of rules saying what
> > goes into the allocator and what is the state coming out.
>
> Let's try it. We can put this in Documentation/ once we agree on the
> rules.
>
> INPUT
> -
>
> The allocator processes, per domain sub-tree, all resources with
> IORESOURCE_IO or IORESOURCE_MEM set. From here on, these are
> simply referred to as *resources*.
>
> Resources with the IORESOURCE_FIXED bit set are referred to as
> *fixed resources*, resources with the IORESOURCE_BRIDGE bit set
> as *bridge resources*, and resources with the IORESOURCE_ASSIGNED
> bit set as *assigned resources*.
>

We should elaborate on the semantics of 'assigned' and its meaning.

>
> Resources with IORESOURCE_IO set must not have IORESOURCE_MEM set.
>
> Resources that should not be changed by the allocator must be
> fixed resources.
>
> Fixed resources must be assigned resources and have a valid `base`
> address pre-assigned.
>
> A fixed resource must not overlap with any other fixed resource
> within the same address space (IO / MEM), unless either of them
> is a bridge resource.
>
> A fixed bridge resource must not overlap with any other fixed
> resource within the same address space and on the same bus (i.e.
> the same device or its siblings), unless exactly one of them has
> IORESOURCE_SUBTRACTIVE set.
>

What are you assuming w.r.t. decode priority with SUBTRACTIVE being set?

>
> OUTPUT
> --
>
> All device attributes beside non-fixed resources are left unaltered.
>

What did you mean by device attributes?

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

[coreboot] Re: Resource allocator: multiple boards regression

[Aaron Durbin via coreboot]

On Thu, May 14, 2020 at 3:46 PM Aaron Durbin  wrote:

>
>
> On Thu, May 14, 2020 at 2:46 PM Mike Banon  wrote:
>
>> Unfortunately it seems a lot of boards are affected by this. A88XM-E
>> and Lenovo G505S (AMD fam15h) also got broken: they rarely succeed at
>> booting - and, when they do, no boot devices are available (virtual
>> floppies too, for some reason) - except coreinfo/tint secondary
>> payloads which became prone to freezing. I attach the A88XM-E logs
>> I've been able to obtain with USB FT232H:
>>
>> 1) ok_e6fb1344ed9188e19be4b54bdf1a76680b8c4523.txt - last coreboot
>> repo's revision where all the stuff works
>> 2) fail_1_3b02006afe8a85477dafa1bd149f1f0dba02afc7.txt - this commit
>> got the boards broken for the first time
>> 3) fail_2_6b95507ec5b087658178a325bdc68570bc48bb20.txt - this is a log
>> for coreboot's master top
>>
>> For some reason logs for 2) and 3) always stop after "PCI: 00:12.2
>> EHCI Debug Port hook triggered".
>>
>> I hope these commits could be reverted before we figure out what's
>> going on with them. Good thing we've noticed it fast enough.
>>
>>
> Thanks, Mike. The amd chipset code (all of it from what I can tell) is
> fundamentally broken and at odds with all of the resource allocation flow.
> They worked previously because dynamic resources were being assigned using
> an algorithm that just assumed there weren't collisions, and that was done
> w/o all the necessary info required for making the proper decisions
> regarding dynamic resource allocation.
>
> I landed the other chipsets' fixes, but the amd chipset code is going to
> take a lot more to fix. Would you be willing to test patches as they are
> crafted? Given the largeness of the problem as well as the gnarly code that
> is the amd chipset code it's going to take some time so I think we do need
> to revert the allocator changes until we can do some house keeping.
>
>
I just was brainstorming with Furquan. He did push the revert changes, but
we were scheming on a patch that I was hoping affected parties could try in
conjunction with https://review.coreboot.org/c/coreboot/+/41363. Basically
we'll allocate top down like the previous allocator did hoping for no
collisions. Let's try that, and see where we land. Regardless we need to
fix this amd chipset code as it's a major liability.

> -Aaron
>
>> Best regards,
>> Mike Banon
>>
>> On Thu, May 14, 2020 at 8:47 PM Keith Hui  wrote:
>> >
>> > Hi guys,
>> >
>> > 31ab7de51a is CB:41368, cherry picked into my local repo.
>> >
>> > Turns out I have to back out all four of Furquan's patches
>> > (CB:39486~39489) for my board to boot normally again.
>> >
>> > Thoughts?
>> >
>> > I'll now get a log with everything in at SPEW.
>> >
>> >
>> > On Thu, May 14, 2020 at 1:05 PM Aaron Durbin 
>> wrote:
>> > >
>> > > Keith, is it possible to have the console log level set to SPEW? I'm
>> not seeing the full logs to piece it all together.
>> > >
>> > > Allocating resources...
>> > > Reading resources...
>> > > Setting RAM size to 768 MB
>> > > PNP: 03f0.8 missing read_resources
>> > > Done reading resources.
>> > > Resource allocator: DOMAIN:  - Pass 1 (gathering requirements)
>> > > Resource allocator: DOMAIN:  - Pass 2 (allocating resources)
>> > > Resource ranges:
>> > > Base: 1000, Size: d000, Tag: 100
>> > > Base: f000, Size: 1000, Tag: 100
>> > > Resource ranges:
>> > > Base: 0, Size: ff80, Tag: 200
>> > > Base: 1, Size: f, Tag: 100200
>> > > Resource ranges:
>> > > Base: 1000, Size: 800, Tag: 1200
>> > > Resource ranges:
>> > > Base: 1800, Size: 110, Tag: 200
>> > >
>> > > This is the memory address space:
>> > > Base: 0, Size: ff80, Tag: 200
>> > > Base: 1, Size: f, Tag: 100200
>> > >
>> > > Those are valid ranges to choose dynamic resources from.
>> > >
>> > > PCI: 00:00.0 10 <- [0x00 - 0x000fff] size 0x1000 gran
>> 0x1c prefmem
>> > >
>> > > I see 'Setting RAM size to 768 MB' which means I would expect to see
>> a hole in the ranges representing 768MiB.
>> > >
>> > > that would be bad. I don't know what commit '31ab7de51a' is, but it
>> might not contain the CB:41368. Having SPEW logs would be helpful.
>> > >
>> > > Also, what mainboard Kconfig are you selecting for p3bf?
>> src/mainboard/asus/p2b ?
>> > >
>> > >
>> > >
>> > > On Thu, May 14, 2020 at 10:42 AM Keith Hui  wrote:
>> > >>
>> > >> (Temporarily leaving the list out)
>> > >>
>> > >> Hi Aaron,
>> > >>
>> > >> Here is a log with everything including CB:41368 included. I'll get
>> > >> this log out to you first, while I try a build with all problem
>> > >> commits left out.
>> > >>
>> > >> Thanks
>> > >> Keith
>> > >>
>> > >> On Thu, May 14, 2020 at 12:53 AM Aaron Durbin 
>> wrote:
>> > >> >
>> > >> >
>> > >> >
>> > >> > On Wed, May 13, 2020 at 10:51 PM Keith Hui 
>> wrote:
>> > >> >>
>> > >> >> Hi guys,
>> > >> >>
>> > >> >> I tested these fixes on my board, and I have to say there's still
>> > >> >> something wrong. They did address 

[coreboot] Re: Resource allocator: multiple boards regression

[Aaron Durbin via coreboot]

On Thu, May 14, 2020 at 4:44 PM Keith Hui  wrote:

> Hi Aaron,
>
> You may want to check the QEMU-q35 target as well:
>
> Automatic boot test returned (PASS/FAIL/TOTAL): 2/2/4
> Emulation targets:
> "QEMU x86 q35/ich9" using payload TianoCore : FAIL :
> https://lava.9esec.io/r/3427
> "QEMU x86 q35/ich9" using payload SeaBIOS : FAIL :
> https://lava.9esec.io/r/3426
> "QEMU x86 i440fx/piix4" using payload SeaBIOS : SUCCESS :
> https://lava.9esec.io/r/3425
> "QEMU AArch64" using payload LinuxBoot_u-root_kexec : SUCCESS :
> https://lava.9esec.io/r/3424


Ya. Those are fixed from the patches that fixed your device, Keith.

>
>
> Thanks
> Keith
>
> On Thu, May 14, 2020 at 5:47 PM Aaron Durbin  wrote:
> >
> >
> >
> > On Thu, May 14, 2020 at 2:46 PM Mike Banon  wrote:
> >>
> >> Unfortunately it seems a lot of boards are affected by this. A88XM-E
> >> and Lenovo G505S (AMD fam15h) also got broken: they rarely succeed at
> >> booting - and, when they do, no boot devices are available (virtual
> >> floppies too, for some reason) - except coreinfo/tint secondary
> >> payloads which became prone to freezing. I attach the A88XM-E logs
> >> I've been able to obtain with USB FT232H:
> >>
> >> 1) ok_e6fb1344ed9188e19be4b54bdf1a76680b8c4523.txt - last coreboot
> >> repo's revision where all the stuff works
> >> 2) fail_1_3b02006afe8a85477dafa1bd149f1f0dba02afc7.txt - this commit
> >> got the boards broken for the first time
> >> 3) fail_2_6b95507ec5b087658178a325bdc68570bc48bb20.txt - this is a log
> >> for coreboot's master top
> >>
> >> For some reason logs for 2) and 3) always stop after "PCI: 00:12.2
> >> EHCI Debug Port hook triggered".
> >>
> >> I hope these commits could be reverted before we figure out what's
> >> going on with them. Good thing we've noticed it fast enough.
> >>
> >
> > Thanks, Mike. The amd chipset code (all of it from what I can tell) is
> fundamentally broken and at odds with all of the resource allocation flow.
> They worked previously because dynamic resources were being assigned using
> an algorithm that just assumed there weren't collisions, and that was done
> w/o all the necessary info required for making the proper decisions
> regarding dynamic resource allocation.
> >
> > I landed the other chipsets' fixes, but the amd chipset code is going to
> take a lot more to fix. Would you be willing to test patches as they are
> crafted? Given the largeness of the problem as well as the gnarly code that
> is the amd chipset code it's going to take some time so I think we do need
> to revert the allocator changes until we can do some house keeping.
> >
> > -Aaron
> >>
> >> Best regards,
> >> Mike Banon
> >>
> >> On Thu, May 14, 2020 at 8:47 PM Keith Hui  wrote:
> >> >
> >> > Hi guys,
> >> >
> >> > 31ab7de51a is CB:41368, cherry picked into my local repo.
> >> >
> >> > Turns out I have to back out all four of Furquan's patches
> >> > (CB:39486~39489) for my board to boot normally again.
> >> >
> >> > Thoughts?
> >> >
> >> > I'll now get a log with everything in at SPEW.
> >> >
> >> >
> >> > On Thu, May 14, 2020 at 1:05 PM Aaron Durbin 
> wrote:
> >> > >
> >> > > Keith, is it possible to have the console log level set to SPEW?
> I'm not seeing the full logs to piece it all together.
> >> > >
> >> > > Allocating resources...
> >> > > Reading resources...
> >> > > Setting RAM size to 768 MB
> >> > > PNP: 03f0.8 missing read_resources
> >> > > Done reading resources.
> >> > > Resource allocator: DOMAIN:  - Pass 1 (gathering requirements)
> >> > > Resource allocator: DOMAIN:  - Pass 2 (allocating resources)
> >> > > Resource ranges:
> >> > > Base: 1000, Size: d000, Tag: 100
> >> > > Base: f000, Size: 1000, Tag: 100
> >> > > Resource ranges:
> >> > > Base: 0, Size: ff80, Tag: 200
> >> > > Base: 1, Size: f, Tag: 100200
> >> > > Resource ranges:
> >> > > Base: 1000, Size: 800, Tag: 1200
> >> > > Resource ranges:
> >> > > Base: 1800, Size: 110, Tag: 200
> >> > >
> >> > > This is the memory address space:
> >> > > Base: 0, Size: ff80, Tag: 200
> >> > > Base: 1, Size: f, Tag: 100200
> >> > >
> >> > > Those are valid ranges to choose dynamic resources from.
> >> > >
> >> > > PCI: 00:00.0 10 <- [0x00 - 0x000fff] size 0x1000
> gran 0x1c prefmem
> >> > >
> >> > > I see 'Setting RAM size to 768 MB' which means I would expect to
> see a hole in the ranges representing 768MiB.
> >> > >
> >> > > that would be bad. I don't know what commit '31ab7de51a' is, but it
> might not contain the CB:41368. Having SPEW logs would be helpful.
> >> > >
> >> > > Also, what mainboard Kconfig are you selecting for p3bf?
> src/mainboard/asus/p2b ?
> >> > >
> >> > >
> >> > >
> >> > > On Thu, May 14, 2020 at 10:42 AM Keith Hui 
> wrote:
> >> > >>
> >> > >> (Temporarily leaving the list out)
> >> > >>
> >> > >> Hi Aaron,
> >> > >>
> >> > >> Here is a log with everything including CB:41368 included. I'll get
> >> > >> this log out to you first, while I try a 

[coreboot] Re: Resource allocator: multiple boards regression

[Aaron Durbin via coreboot]

On Thu, May 14, 2020 at 2:46 PM Mike Banon  wrote:

> Unfortunately it seems a lot of boards are affected by this. A88XM-E
> and Lenovo G505S (AMD fam15h) also got broken: they rarely succeed at
> booting - and, when they do, no boot devices are available (virtual
> floppies too, for some reason) - except coreinfo/tint secondary
> payloads which became prone to freezing. I attach the A88XM-E logs
> I've been able to obtain with USB FT232H:
>
> 1) ok_e6fb1344ed9188e19be4b54bdf1a76680b8c4523.txt - last coreboot
> repo's revision where all the stuff works
> 2) fail_1_3b02006afe8a85477dafa1bd149f1f0dba02afc7.txt - this commit
> got the boards broken for the first time
> 3) fail_2_6b95507ec5b087658178a325bdc68570bc48bb20.txt - this is a log
> for coreboot's master top
>
> For some reason logs for 2) and 3) always stop after "PCI: 00:12.2
> EHCI Debug Port hook triggered".
>
> I hope these commits could be reverted before we figure out what's
> going on with them. Good thing we've noticed it fast enough.
>
>
Thanks, Mike. The amd chipset code (all of it from what I can tell) is
fundamentally broken and at odds with all of the resource allocation flow.
They worked previously because dynamic resources were being assigned using
an algorithm that just assumed there weren't collisions, and that was done
w/o all the necessary info required for making the proper decisions
regarding dynamic resource allocation.

I landed the other chipsets' fixes, but the amd chipset code is going to
take a lot more to fix. Would you be willing to test patches as they are
crafted? Given the largeness of the problem as well as the gnarly code that
is the amd chipset code it's going to take some time so I think we do need
to revert the allocator changes until we can do some house keeping.

-Aaron

> Best regards,
> Mike Banon
>
> On Thu, May 14, 2020 at 8:47 PM Keith Hui  wrote:
> >
> > Hi guys,
> >
> > 31ab7de51a is CB:41368, cherry picked into my local repo.
> >
> > Turns out I have to back out all four of Furquan's patches
> > (CB:39486~39489) for my board to boot normally again.
> >
> > Thoughts?
> >
> > I'll now get a log with everything in at SPEW.
> >
> >
> > On Thu, May 14, 2020 at 1:05 PM Aaron Durbin  wrote:
> > >
> > > Keith, is it possible to have the console log level set to SPEW? I'm
> not seeing the full logs to piece it all together.
> > >
> > > Allocating resources...
> > > Reading resources...
> > > Setting RAM size to 768 MB
> > > PNP: 03f0.8 missing read_resources
> > > Done reading resources.
> > > Resource allocator: DOMAIN:  - Pass 1 (gathering requirements)
> > > Resource allocator: DOMAIN:  - Pass 2 (allocating resources)
> > > Resource ranges:
> > > Base: 1000, Size: d000, Tag: 100
> > > Base: f000, Size: 1000, Tag: 100
> > > Resource ranges:
> > > Base: 0, Size: ff80, Tag: 200
> > > Base: 1, Size: f, Tag: 100200
> > > Resource ranges:
> > > Base: 1000, Size: 800, Tag: 1200
> > > Resource ranges:
> > > Base: 1800, Size: 110, Tag: 200
> > >
> > > This is the memory address space:
> > > Base: 0, Size: ff80, Tag: 200
> > > Base: 1, Size: f, Tag: 100200
> > >
> > > Those are valid ranges to choose dynamic resources from.
> > >
> > > PCI: 00:00.0 10 <- [0x00 - 0x000fff] size 0x1000 gran
> 0x1c prefmem
> > >
> > > I see 'Setting RAM size to 768 MB' which means I would expect to see a
> hole in the ranges representing 768MiB.
> > >
> > > that would be bad. I don't know what commit '31ab7de51a' is, but it
> might not contain the CB:41368. Having SPEW logs would be helpful.
> > >
> > > Also, what mainboard Kconfig are you selecting for p3bf?
> src/mainboard/asus/p2b ?
> > >
> > >
> > >
> > > On Thu, May 14, 2020 at 10:42 AM Keith Hui  wrote:
> > >>
> > >> (Temporarily leaving the list out)
> > >>
> > >> Hi Aaron,
> > >>
> > >> Here is a log with everything including CB:41368 included. I'll get
> > >> this log out to you first, while I try a build with all problem
> > >> commits left out.
> > >>
> > >> Thanks
> > >> Keith
> > >>
> > >> On Thu, May 14, 2020 at 12:53 AM Aaron Durbin 
> wrote:
> > >> >
> > >> >
> > >> >
> > >> > On Wed, May 13, 2020 at 10:51 PM Keith Hui 
> wrote:
> > >> >>
> > >> >> Hi guys,
> > >> >>
> > >> >> I tested these fixes on my board, and I have to say there's still
> > >> >> something wrong. They did address the hang or reset in SeaBIOS I
> first
> > >> >> described, but now either my ATA hard drive failed to boot (it
> tried
> > >> >> to hand off to GRUB on my drive, but didn't get there), or it can't
> > >> >> find the option ROM of my video card, meaning no display.
> > >> >>
> > >> >> Now I want to try the other way, testing a build with all changes
> > >> >> related to the problem backed out instead. So besides the one I
> first
> > >> >> identified, what other related patches should I try backing out?
> > >> >
> > >> >
> > >> > Just go to the parent of the identified patch.  As for the other
> symptoms you are 

[coreboot] Re: Change in coreboot[master]: nb/intel/i440bx: add resources during read_resources()

[Aaron Durbin via coreboot]

On Thu, May 14, 2020 at 2:25 PM Keith Hui  wrote:

> Hi Aaron,
>
> I think I have success after applying 41363 as well. Please see
> attached and tell us if this is what you set out to do.
>

That looks correct, and what I was expecting. Thanks for the help gathering
logs.


> Thanks
> Keith
>
> On Thu, May 14, 2020 at 4:01 PM Aaron Durbin  wrote:
> >
> > Hi Keith,
> >
> > Did the newresalloc.log file contain this patch?
> https://review.coreboot.org/c/coreboot/+/41363
> >
> > I ask because I see the fixed resources on the domain that are dram:
> >   DOMAIN:  resource base 0 size a align 0 gran 0 limit 0 flags
> e0004200 index a
> >   DOMAIN:  resource base c size 2ff4 align 0 gran 0 limit 0
> flags e0004200 index b
> >
> > However, I don't see them being removed the address space selection:
> > DOMAIN:  mem: base: 0 size: 0 align: 0 gran: 0 limit: f
> > update_constraints: PCI: 00:04.0 02 base ff80 limit  mem
> (fixed)
> > Resource ranges:
> > Base: 0, Size: ff80, Tag: 200
> > Base: 1, Size: f, Tag: 100200
> >
> > update_constraints isn't called for the resources above.
> >
> > On Thu, May 14, 2020 at 1:32 PM Keith Hui  wrote:
> >>
> >> Hi Aaron,
> >>
> >> Here are two more logs at SPEW. Old log is a separate branch where I
> >> reverted all the problem commits; new log has everything.
> >>
> >> Thanks
> >> Keith
>
___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] Re: Change in coreboot[master]: nb/intel/i440bx: add resources during read_resources()

[Aaron Durbin via coreboot]

Hi Keith,

Did the newresalloc.log file contain this patch?
https://review.coreboot.org/c/coreboot/+/41363

I ask because I see the fixed resources on the domain that are dram:
  DOMAIN:  resource base 0 size a align 0 gran 0 limit 0 flags
e0004200 index a
  DOMAIN:  resource base c size 2ff4 align 0 gran 0 limit 0
flags e0004200 index b

However, I don't see them being removed the address space selection:
DOMAIN:  mem: base: 0 size: 0 align: 0 gran: 0 limit: f
update_constraints: PCI: 00:04.0 02 base ff80 limit  mem (fixed)
Resource ranges:
Base: 0, Size: ff80, Tag: 200
Base: 1, Size: f, Tag: 100200

update_constraints isn't called for the resources above.

On Thu, May 14, 2020 at 1:32 PM Keith Hui  wrote:

> Hi Aaron,
>
> Here are two more logs at SPEW. Old log is a separate branch where I
> reverted all the problem commits; new log has everything.
>
> Thanks
> Keith
>
___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] Re: i440BX regression; P3B-F flashrom board enable is finally happening

[Aaron Durbin via coreboot]

On Wed, May 13, 2020 at 10:51 PM Keith Hui  wrote:

> Hi guys,
>
> I tested these fixes on my board, and I have to say there's still
> something wrong. They did address the hang or reset in SeaBIOS I first
> described, but now either my ATA hard drive failed to boot (it tried
> to hand off to GRUB on my drive, but didn't get there), or it can't
> find the option ROM of my video card, meaning no display.
>
> Now I want to try the other way, testing a build with all changes
> related to the problem backed out instead. So besides the one I first
> identified, what other related patches should I try backing out?
>

Just go to the parent of the identified patch.  As for the other symptoms
you are seeing, I'd love to see logs with the patches we identified so we
can root cause.

Thanks.

-Aaron


> On Wed, May 13, 2020 at 11:54 PM Furquan Shaikh
>  wrote:
> >
> > Similar fix for i440x: https://review.coreboot.org/c/coreboot/+/41368
> >
> > On Wed, May 13, 2020 at 11:29 AM Aaron Durbin 
> wrote:
> > >
> > > i440x chipset is doing things in the wrong way like sandybridge. I
> uploaded this fix for sandy:
> https://review.coreboot.org/c/coreboot/+/41364 We'll need to do the
> equivalent for i440x.
> > >
> > > On Wed, May 13, 2020 at 11:13 AM Aaron Durbin 
> wrote:
> > >>
> > >> OK. I'll take a look at your logs and see what's going on. The patch
> link I sent was based off of someone else's mainboard logs.
> > >>
> > >> On Wed, May 13, 2020 at 10:59 AM Keith Hui  wrote:
> > >>>
> > >>> Hi Aaron,
> > >>>
> > >>> It didn't help. There still a way out of whack entry in the coreboot
> > >>> table and e820 entry ending at 03ff, which I think have
> > >>> more to do than the 41363's scope.
> > >>>
> > >>> Keith
> > >>>
> > >>> On Wed, May 13, 2020 at 12:24 PM Aaron Durbin 
> wrote:
> > >>> >
> > >>> > I think the following patch will fix things up:
> https://review.coreboot.org/c/coreboot/+/41363 Please let me know.
> > >>> >
> > >>> > On Wed, May 13, 2020 at 8:43 AM Keith Hui 
> wrote:
> > >>> >>
> > >>> >> Thanks Furquan.
> > >>> >>
> > >>> >> Here are 3 logs. Log 1 is at the commit just before the problem.
> Log 2
> > >>> >> is at the problem commit. Log 3 is at the current master, if
> that's
> > >>> >> what you meant by ToT.
> > >>> >>
> > >>> >> I'm using SeaBIOS 1.13.0, compiled once using the attached .config
> > >>> >> before taking these logs. All 3 runs are taken using the same
> SeaBIOS
> > >>> >> binary.
> > >>> >>
> > >>> >> Then I recompiled SeaBIOS with CONFIG_RELOCATE_INIT off, replaced
> the
> > >>> >> payload used in run 3, and took an extra run. In this case the
> board
> > >>> >> reset on its own at "Scanning option roms", looping infinitely.
> > >>> >>
> > >>> >> Hope this helps
> > >>> >> Keith
> > >>> >>
> > >>> >> On Wed, May 13, 2020 at 7:38 AM Furquan Shaikh
> > >>> >>  wrote:
> > >>> >> >
> > >>> >> > Thanks for the report Keith!
> > >>> >> >
> > >>> >> > On Wed, May 13, 2020 at 3:42 AM Paul Menzel <
> pmen...@molgen.mpg.de> wrote:
> > >>> >> > >
> > >>> >> > > Dear Keith,
> > >>> >> > >
> > >>> >> > >
> > >>> >> > > Am 13.05.20 um 05:21 schrieb Keith Hui:
> > >>> >> > >
> > >>> >> > > > I am still refining the P2B family of boards, now including
> the
> > >>> >> > > > infamous P3B-F with an unusual appetite for hacks to make
> work.
> > >>> >> > > >
> > >>> >> > > > That said, I'm now finding that, on P3B-F, SeaBIOS hangs
> when it tries
> > >>> >> > > > to relocate itself as part of its usual chores. Having just
> learned
> > >>> >> > > > git bisect, I decided to try it out.
> > >>> >> > > >
> > >>> >> > > > It was commit 3b02006afe8a85477dafa1bd149f1f0dba02afc7 [1]
> that broke
> > >>> >> > > > my SeaBIOS. It doesn't affect my newer toy the P8Z77-M as
> much as
> > >>> >> > > > P3B-F, but I still want to blame that, and probably the
> very next
> > >>> >> > > > commit as well, as they both deal with some very modern
> aspects of PCI
> > >>> >> > > > that well predates the 440BX.
> > >>> >> > > >
> > >>> >> > > > Is there anything we can do to fix 3b02006afe?
> > >>> >> > >
> > >>> >> > > I commented in the change-set [1] to make the author and
> reviewers aware
> > >>> >> > > of this issue and referenced your list message, and ask to
> comment here.
> > >>> >> > >
> > >>> >> > > Could you please provide the debug log of coreboot and
> SeaBIOS?
> > >>> >> >
> > >>> >> > As Paul mentioned, can you please provide the debug logs for
> coreboot
> > >>> >> > and SeaBIOS both with ToT coreboot and with HEAD set before the
> change
> > >>> >> > 3b02006afe where it does not hang? Thanks!
> > >>> >> >
> > >>> >> > >
> > >>> >> > >
> > >>> >> > > > Meanwhile I ported the P3B-F board enable to flashrom [2],
> which got a
> > >>> >> > > > heavy workout during this bisect, through vendor firmware
> and both
> > >>> >> > > > good and bad builds of coreboot. In all cases I can flash
> internal, no
> > >>> >> > > > longer having to haul out my P2B-LS just to use it as a
> flasher.
> > >>> >> > 

[coreboot] Re: i440BX regression; P3B-F flashrom board enable is finally happening

[Aaron Durbin via coreboot]

i440x chipset is doing things in the wrong way like sandybridge. I uploaded
this fix for sandy: https://review.coreboot.org/c/coreboot/+/41364 We'll
need to do the equivalent for i440x.

On Wed, May 13, 2020 at 11:13 AM Aaron Durbin  wrote:

> OK. I'll take a look at your logs and see what's going on. The patch link
> I sent was based off of someone else's mainboard logs.
>
> On Wed, May 13, 2020 at 10:59 AM Keith Hui  wrote:
>
>> Hi Aaron,
>>
>> It didn't help. There still a way out of whack entry in the coreboot
>> table and e820 entry ending at 03ff, which I think have
>> more to do than the 41363's scope.
>>
>> Keith
>>
>> On Wed, May 13, 2020 at 12:24 PM Aaron Durbin  wrote:
>> >
>> > I think the following patch will fix things up:
>> https://review.coreboot.org/c/coreboot/+/41363 Please let me know.
>> >
>> > On Wed, May 13, 2020 at 8:43 AM Keith Hui  wrote:
>> >>
>> >> Thanks Furquan.
>> >>
>> >> Here are 3 logs. Log 1 is at the commit just before the problem. Log 2
>> >> is at the problem commit. Log 3 is at the current master, if that's
>> >> what you meant by ToT.
>> >>
>> >> I'm using SeaBIOS 1.13.0, compiled once using the attached .config
>> >> before taking these logs. All 3 runs are taken using the same SeaBIOS
>> >> binary.
>> >>
>> >> Then I recompiled SeaBIOS with CONFIG_RELOCATE_INIT off, replaced the
>> >> payload used in run 3, and took an extra run. In this case the board
>> >> reset on its own at "Scanning option roms", looping infinitely.
>> >>
>> >> Hope this helps
>> >> Keith
>> >>
>> >> On Wed, May 13, 2020 at 7:38 AM Furquan Shaikh
>> >>  wrote:
>> >> >
>> >> > Thanks for the report Keith!
>> >> >
>> >> > On Wed, May 13, 2020 at 3:42 AM Paul Menzel 
>> wrote:
>> >> > >
>> >> > > Dear Keith,
>> >> > >
>> >> > >
>> >> > > Am 13.05.20 um 05:21 schrieb Keith Hui:
>> >> > >
>> >> > > > I am still refining the P2B family of boards, now including the
>> >> > > > infamous P3B-F with an unusual appetite for hacks to make work.
>> >> > > >
>> >> > > > That said, I'm now finding that, on P3B-F, SeaBIOS hangs when it
>> tries
>> >> > > > to relocate itself as part of its usual chores. Having just
>> learned
>> >> > > > git bisect, I decided to try it out.
>> >> > > >
>> >> > > > It was commit 3b02006afe8a85477dafa1bd149f1f0dba02afc7 [1] that
>> broke
>> >> > > > my SeaBIOS. It doesn't affect my newer toy the P8Z77-M as much as
>> >> > > > P3B-F, but I still want to blame that, and probably the very next
>> >> > > > commit as well, as they both deal with some very modern aspects
>> of PCI
>> >> > > > that well predates the 440BX.
>> >> > > >
>> >> > > > Is there anything we can do to fix 3b02006afe?
>> >> > >
>> >> > > I commented in the change-set [1] to make the author and reviewers
>> aware
>> >> > > of this issue and referenced your list message, and ask to comment
>> here.
>> >> > >
>> >> > > Could you please provide the debug log of coreboot and SeaBIOS?
>> >> >
>> >> > As Paul mentioned, can you please provide the debug logs for coreboot
>> >> > and SeaBIOS both with ToT coreboot and with HEAD set before the
>> change
>> >> > 3b02006afe where it does not hang? Thanks!
>> >> >
>> >> > >
>> >> > >
>> >> > > > Meanwhile I ported the P3B-F board enable to flashrom [2], which
>> got a
>> >> > > > heavy workout during this bisect, through vendor firmware and
>> both
>> >> > > > good and bad builds of coreboot. In all cases I can flash
>> internal, no
>> >> > > > longer having to haul out my P2B-LS just to use it as a flasher.
>> >> > > >
>> >> > > > Enjoy this long overdue board enable. If it gets submitted, I'll
>> >> > > > retract the ramstage hack[3] doing the same as redundant.
>> >> > >
>> >> > > Very nice! It’s always amazing, how after so many years, when the
>> vendor
>> >> > > already stopped supporting the device, the community still
>> supports the
>> >> > > device and improves the firmware showing that Free Software is the
>> more
>> >> > > sustainable way.
>> >> > >
>> >> > >
>> >> > > Kind regards,
>> >> > >
>> >> > > Paul
>> >> > >
>> >> > >
>> >> > > > [1] https://review.coreboot.org/c/coreboot/+/39486
>> >> > > > [2] https://review.coreboot.org/c/flashrom/+/41354
>> >> > > > [3] https://review.coreboot.org/c/coreboot/+/41224
>> >> > > ___
>> >> > > coreboot mailing list -- coreboot@coreboot.org
>> >> > > To unsubscribe send an email to coreboot-le...@coreboot.org
>> >> ___
>> >> coreboot mailing list -- coreboot@coreboot.org
>> >> To unsubscribe send an email to coreboot-le...@coreboot.org
>>
>
___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] Re: i440BX regression; P3B-F flashrom board enable is finally happening

[Aaron Durbin via coreboot]

OK. I'll take a look at your logs and see what's going on. The patch link I
sent was based off of someone else's mainboard logs.

On Wed, May 13, 2020 at 10:59 AM Keith Hui  wrote:

> Hi Aaron,
>
> It didn't help. There still a way out of whack entry in the coreboot
> table and e820 entry ending at 03ff, which I think have
> more to do than the 41363's scope.
>
> Keith
>
> On Wed, May 13, 2020 at 12:24 PM Aaron Durbin  wrote:
> >
> > I think the following patch will fix things up:
> https://review.coreboot.org/c/coreboot/+/41363 Please let me know.
> >
> > On Wed, May 13, 2020 at 8:43 AM Keith Hui  wrote:
> >>
> >> Thanks Furquan.
> >>
> >> Here are 3 logs. Log 1 is at the commit just before the problem. Log 2
> >> is at the problem commit. Log 3 is at the current master, if that's
> >> what you meant by ToT.
> >>
> >> I'm using SeaBIOS 1.13.0, compiled once using the attached .config
> >> before taking these logs. All 3 runs are taken using the same SeaBIOS
> >> binary.
> >>
> >> Then I recompiled SeaBIOS with CONFIG_RELOCATE_INIT off, replaced the
> >> payload used in run 3, and took an extra run. In this case the board
> >> reset on its own at "Scanning option roms", looping infinitely.
> >>
> >> Hope this helps
> >> Keith
> >>
> >> On Wed, May 13, 2020 at 7:38 AM Furquan Shaikh
> >>  wrote:
> >> >
> >> > Thanks for the report Keith!
> >> >
> >> > On Wed, May 13, 2020 at 3:42 AM Paul Menzel 
> wrote:
> >> > >
> >> > > Dear Keith,
> >> > >
> >> > >
> >> > > Am 13.05.20 um 05:21 schrieb Keith Hui:
> >> > >
> >> > > > I am still refining the P2B family of boards, now including the
> >> > > > infamous P3B-F with an unusual appetite for hacks to make work.
> >> > > >
> >> > > > That said, I'm now finding that, on P3B-F, SeaBIOS hangs when it
> tries
> >> > > > to relocate itself as part of its usual chores. Having just
> learned
> >> > > > git bisect, I decided to try it out.
> >> > > >
> >> > > > It was commit 3b02006afe8a85477dafa1bd149f1f0dba02afc7 [1] that
> broke
> >> > > > my SeaBIOS. It doesn't affect my newer toy the P8Z77-M as much as
> >> > > > P3B-F, but I still want to blame that, and probably the very next
> >> > > > commit as well, as they both deal with some very modern aspects
> of PCI
> >> > > > that well predates the 440BX.
> >> > > >
> >> > > > Is there anything we can do to fix 3b02006afe?
> >> > >
> >> > > I commented in the change-set [1] to make the author and reviewers
> aware
> >> > > of this issue and referenced your list message, and ask to comment
> here.
> >> > >
> >> > > Could you please provide the debug log of coreboot and SeaBIOS?
> >> >
> >> > As Paul mentioned, can you please provide the debug logs for coreboot
> >> > and SeaBIOS both with ToT coreboot and with HEAD set before the change
> >> > 3b02006afe where it does not hang? Thanks!
> >> >
> >> > >
> >> > >
> >> > > > Meanwhile I ported the P3B-F board enable to flashrom [2], which
> got a
> >> > > > heavy workout during this bisect, through vendor firmware and both
> >> > > > good and bad builds of coreboot. In all cases I can flash
> internal, no
> >> > > > longer having to haul out my P2B-LS just to use it as a flasher.
> >> > > >
> >> > > > Enjoy this long overdue board enable. If it gets submitted, I'll
> >> > > > retract the ramstage hack[3] doing the same as redundant.
> >> > >
> >> > > Very nice! It’s always amazing, how after so many years, when the
> vendor
> >> > > already stopped supporting the device, the community still supports
> the
> >> > > device and improves the firmware showing that Free Software is the
> more
> >> > > sustainable way.
> >> > >
> >> > >
> >> > > Kind regards,
> >> > >
> >> > > Paul
> >> > >
> >> > >
> >> > > > [1] https://review.coreboot.org/c/coreboot/+/39486
> >> > > > [2] https://review.coreboot.org/c/flashrom/+/41354
> >> > > > [3] https://review.coreboot.org/c/coreboot/+/41224
> >> > > ___
> >> > > coreboot mailing list -- coreboot@coreboot.org
> >> > > To unsubscribe send an email to coreboot-le...@coreboot.org
> >> ___
> >> coreboot mailing list -- coreboot@coreboot.org
> >> To unsubscribe send an email to coreboot-le...@coreboot.org
>
___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] Re: i440BX regression; P3B-F flashrom board enable is finally happening

[Aaron Durbin via coreboot]

I think the following patch will fix things up:
https://review.coreboot.org/c/coreboot/+/41363 Please let me know.

On Wed, May 13, 2020 at 8:43 AM Keith Hui  wrote:

> Thanks Furquan.
>
> Here are 3 logs. Log 1 is at the commit just before the problem. Log 2
> is at the problem commit. Log 3 is at the current master, if that's
> what you meant by ToT.
>
> I'm using SeaBIOS 1.13.0, compiled once using the attached .config
> before taking these logs. All 3 runs are taken using the same SeaBIOS
> binary.
>
> Then I recompiled SeaBIOS with CONFIG_RELOCATE_INIT off, replaced the
> payload used in run 3, and took an extra run. In this case the board
> reset on its own at "Scanning option roms", looping infinitely.
>
> Hope this helps
> Keith
>
> On Wed, May 13, 2020 at 7:38 AM Furquan Shaikh
>  wrote:
> >
> > Thanks for the report Keith!
> >
> > On Wed, May 13, 2020 at 3:42 AM Paul Menzel 
> wrote:
> > >
> > > Dear Keith,
> > >
> > >
> > > Am 13.05.20 um 05:21 schrieb Keith Hui:
> > >
> > > > I am still refining the P2B family of boards, now including the
> > > > infamous P3B-F with an unusual appetite for hacks to make work.
> > > >
> > > > That said, I'm now finding that, on P3B-F, SeaBIOS hangs when it
> tries
> > > > to relocate itself as part of its usual chores. Having just learned
> > > > git bisect, I decided to try it out.
> > > >
> > > > It was commit 3b02006afe8a85477dafa1bd149f1f0dba02afc7 [1] that broke
> > > > my SeaBIOS. It doesn't affect my newer toy the P8Z77-M as much as
> > > > P3B-F, but I still want to blame that, and probably the very next
> > > > commit as well, as they both deal with some very modern aspects of
> PCI
> > > > that well predates the 440BX.
> > > >
> > > > Is there anything we can do to fix 3b02006afe?
> > >
> > > I commented in the change-set [1] to make the author and reviewers
> aware
> > > of this issue and referenced your list message, and ask to comment
> here.
> > >
> > > Could you please provide the debug log of coreboot and SeaBIOS?
> >
> > As Paul mentioned, can you please provide the debug logs for coreboot
> > and SeaBIOS both with ToT coreboot and with HEAD set before the change
> > 3b02006afe where it does not hang? Thanks!
> >
> > >
> > >
> > > > Meanwhile I ported the P3B-F board enable to flashrom [2], which got
> a
> > > > heavy workout during this bisect, through vendor firmware and both
> > > > good and bad builds of coreboot. In all cases I can flash internal,
> no
> > > > longer having to haul out my P2B-LS just to use it as a flasher.
> > > >
> > > > Enjoy this long overdue board enable. If it gets submitted, I'll
> > > > retract the ramstage hack[3] doing the same as redundant.
> > >
> > > Very nice! It’s always amazing, how after so many years, when the
> vendor
> > > already stopped supporting the device, the community still supports the
> > > device and improves the firmware showing that Free Software is the more
> > > sustainable way.
> > >
> > >
> > > Kind regards,
> > >
> > > Paul
> > >
> > >
> > > > [1] https://review.coreboot.org/c/coreboot/+/39486
> > > > [2] https://review.coreboot.org/c/flashrom/+/41354
> > > > [3] https://review.coreboot.org/c/coreboot/+/41224
> > > ___
> > > coreboot mailing list -- coreboot@coreboot.org
> > > To unsubscribe send an email to coreboot-le...@coreboot.org
> ___
> coreboot mailing list -- coreboot@coreboot.org
> To unsubscribe send an email to coreboot-le...@coreboot.org
>
___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] Re: What does mirror_payload() do and do we still need it?

[Aaron Durbin via coreboot]

On Fri, Mar 6, 2020 at 6:52 PM Julius Werner  wrote:

> [resend with right account]
>
> On Fri, Mar 6, 2020 at 5:50 PM Julius Werner  wrote:
> >
> > Hi,
> >
> > I'm trying to refactor some CBFS code (which necessarily leaks into
> > the prog_loaders) and
> > mirror_payload()/CONFIG_MIRROR_PAYLOAD_TO_RAM_BEFORE_LOADING is a bit
> > of a complication. I'm trying to understand if this option is actually
> > used by anyone. It seems to be "default n" in Kconfig and I don't see
> > any mainboard/SoC select it specifically. It is not user-visible in
> > menuconfig and the Chrome OS specific defconfig files don't select it
> > either. In the original patch
> > (https://review.coreboot.org/c/coreboot/+/5305) there seems to have
> > been some discussion about which boards can even benefit from this,
> > and I don't see any indication that it was ever really enabled
> > anywhere.
> >
> > So is this actually used anywhere, by anyone? Can I just rip it out?
>

We can likely rip it out if it's not being used. In the past it was done to
load everything into memory prior to performing decompression. We used to
have the equivalent enabled everywhere. Subsequent churn in various places
has led to the current situation. We have definitely seen speedups by using
it, but if no one is actively taking advantage of it then I don't see why
we should keep it. This was a related patch: http://review.coreboot.org/5144
___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] Re: [RFC] Using relocatable module program parameters to pass cbmem_top() on X86

[Aaron Durbin via coreboot]

On Sat, Oct 19, 2019 at 9:42 AM Arthur Heymans  wrote:

> Hi
>
> Currently all stages that need cbmem need an implementation of a
> cbmem_top function. On platforms with fully open source coreboot code it
> is generally not a problem to link in all stages the code reading the
> hardware registers to figur out where the top of lower memory is. On FSP
> platforms this proves to be painful and using the value provided by the
> FSP-M HOB is to be preferred. Next stages don't have access to this
> variable since CAR is gone. EBDA is used to pass it on to next stages.
>
> The problem with this is that EBDA also need to be written on S3 as one
> cannot assume it to be still there. Writing things on S3 is always
> fragile as it could overwrite other things set up by something else.
>
> One possible solution is to back up the area it's going to write to in
> romstage in cbmem and restoring it on the ramstage, but writing to cbmem
> on S3 resume is just moving the problem to a different place and likely
> makes things even worse...
>
> One other idea I could come up with is to make the cbmem_top pointer an
> argument to the relocatable stages needing it (postcar and ramstage).
> This would unify all cbmem_top implementation in those stages and should
> be more robust on S3 resume as on S3 resume the ramstage is typically
> fetched from RAM (cbmem or tseg stage cache).
>

That's the same thing as effectively providing a register ABI between the
stages passing information to it. I'm not sure EBDA is necessarily bad in
practice. It's typically reserved. What specific issues are you concerned
with EBDA?


> Any thoughts?
>
> Arthur Heymans
> ___
> coreboot mailing list -- coreboot@coreboot.org
> To unsubscribe send an email to coreboot-le...@coreboot.org
>
___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] Re: Adding System76 to End Users webpage

[Aaron Durbin via coreboot]

On Thu, Oct 10, 2019 at 11:13 AM Matt DeVillier 
wrote:

> just checkout and push changes to the 'homepage' project
>

FWIW: https://review.coreboot.org/admin/repos/homepage

>
> On Thu, Oct 10, 2019 at 12:05 PM Jeremy Soller 
> wrote:
>
>> Hello,
>>
>> Now that System76 is providing products with Coreboot pre-installed, is
>> it possible to add us  to Consumer platforms on
>> https://www.coreboot.org/users.html ?
>>
>> Also, we have a distribution of firmware utilizing Coreboot, EDK2, and
>> open-source System76 firmware applications called System76 Open Firmware.
>> Could this be added to Community/Custom coreboot images on that same page?
>> Here is the link:
>>
>> https://github.com/system76/firmware-open
>>
>> Thanks!
>>
>> --
>>   Jeremy Soller
>>   System76
>>   Principal Engineer
>>   jer...@system76.com
>> ___
>> coreboot mailing list -- coreboot@coreboot.org
>> To unsubscribe send an email to coreboot-le...@coreboot.org
>>
> ___
> coreboot mailing list -- coreboot@coreboot.org
> To unsubscribe send an email to coreboot-le...@coreboot.org
>
___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] Re: PCIe Hotplug for Thunderbolt and U.2

[Aaron Durbin via coreboot]

On Wed, Oct 9, 2019 at 3:07 PM Jeremy Soller  wrote:

> Will do. Any relevant emails I should CC when I have something?
>

I'm not sure about Intel, but you can include mine, Duncan's, and
Furquan's. Should be autocomplete in gerrit.

>
> --
>   Jeremy Soller
>   System76
>   Engineering Manager
>   jer...@system76.com
>
>
>
> On Wed, Oct 9, 2019, at 1:29 PM, Aaron Durbin wrote:
>
> Please include intel and google on your patches because we'll be needing
> this support in the near future as well. The allocator limitations are
> known, and Kyosti and I have talked about improving things here. As for the
> children comment you need to reserve a sufficiently large mmio space and in
> the hotplug path one can allocate subdevices. Since it's inherently a
> hotplug there's no way to know what the topology will be when a device is
> plugged in.
>
> On Wed, Oct 9, 2019 at 12:32 PM Jeremy Soller  wrote:
>
> This is to continue the discussion from the coreboot leadership meeting.
> Thunderbolt devices are not correctly initialized by Coreboot such that the
> OS can boot without kernel parameters and allow for Thunderbolt
> hotplugging. Additional bus numbers and memory must be allocated.
>
> I will be working on support for this for our System76 mainboards.
>
> Here were the notes taken about it during the meeting, see 9 October 2019,
> PCIe Hotplug on newer Intel socs:
>
>
> https://docs.google.com/document/d/1NRXqXcLBp5pFkHiJbrLdv3Spqh1Hu086HYkKrgKjeDQ/edit#heading=h.pcmhez7yc2on
>
> --
>   Jeremy Soller
>   System76
>   Engineering Manager
>   jer...@system76.com
> ___
> coreboot mailing list -- coreboot@coreboot.org
> To unsubscribe send an email to coreboot-le...@coreboot.org
>
>
>
___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] Re: PCIe Hotplug for Thunderbolt and U.2

[Aaron Durbin via coreboot]

Please include intel and google on your patches because we'll be needing
this support in the near future as well. The allocator limitations are
known, and Kyosti and I have talked about improving things here. As for the
children comment you need to reserve a sufficiently large mmio space and in
the hotplug path one can allocate subdevices. Since it's inherently a
hotplug there's no way to know what the topology will be when a device is
plugged in.

On Wed, Oct 9, 2019 at 12:32 PM Jeremy Soller  wrote:

> This is to continue the discussion from the coreboot leadership meeting.
> Thunderbolt devices are not correctly initialized by Coreboot such that the
> OS can boot without kernel parameters and allow for Thunderbolt
> hotplugging. Additional bus numbers and memory must be allocated.
>
> I will be working on support for this for our System76 mainboards.
>
> Here were the notes taken about it during the meeting, see 9 October 2019,
> PCIe Hotplug on newer Intel socs:
>
>
> https://docs.google.com/document/d/1NRXqXcLBp5pFkHiJbrLdv3Spqh1Hu086HYkKrgKjeDQ/edit#heading=h.pcmhez7yc2on
>
> --
>   Jeremy Soller
>   System76
>   Engineering Manager
>   jer...@system76.com
> ___
> coreboot mailing list -- coreboot@coreboot.org
> To unsubscribe send an email to coreboot-le...@coreboot.org
>
___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] Re: [PATCH] x86_64 support needs testing

[Aaron Durbin via coreboot]

On Tue, Oct 1, 2019 at 10:29 AM Raul Rangel  wrote:

> Yeah, we can place the stack at the bottom of a page so if it overflows we
> get a page fault. I'm assuming that will work in SMM?
>

Paging works in SMM, yes. However, paging works on 32-bit as well where one
could achieve the same thing. Minimum 4KiB stack granularity is necessary
as well as ensuring physical and virtual address spaces are split up to
allow guard pages. Currently everything is assumed 1:1.

>
> On Tue, Oct 1, 2019 at 10:27 AM Aaron Durbin  wrote:
>
>>
>>
>> On Tue, Oct 1, 2019 at 9:42 AM Raul Rangel  wrote:
>>
>>> That's exciting. That means we can finally catch stack overflows in SMM.
>>>
>>
>> Because of paging?
>>
>>>
>>> On Sun, Sep 29, 2019 at 5:42 AM Patrick Rudolph 
>>> wrote:
>>>
 Dear coreboot community,
 Please test and review the patch series [1].

 It adds support for x86 long mode on qemu and allows to build test
 most of coreboot's common code using the x86_64 toolchain.
 It serves as reference implementation to migrate real hardware to long
 mode.

 Here some technical details, that can also be found in the
 Documentation/ folder:

 A new tool called pgtblgen create static page tables for a known
 physical
 memory address. The page tables are placed in CBFS at the given address.
 Due to the fixed and known address, they can easily be loaded in
 assembly code.
 It only works on platforms that memory map the SPI flash, which are
 almost all
 modern x86 platforms.

 The advantage of page tables in ROM are:
 * No runtime (assembly) code to generate page tables
 * No need to find a (4K aligned) place in heap to store them
 * Improved security for SMM, as page tables are always immutable

 The page tables are loaded in bootblock and SMM and persist until
 control is handed
 over to the payload.

 For the Proof-of-Concept only 4GiB are identity mapped, thus no stage
 can't access
 memory over 4GiB. That's not a problem for now as no coreboot code make
 use of memory
 above 4GiB yet.

 I haven't done further tests on long mode.
 It will be interesting to see if there are improvements on boot speed,
 code size or
 faster firmware decompression speeds.

 Regards,
 Patrick

 1:

 https://review.coreboot.org/q/topic:%22x86_64_support2%22+(status:open%20OR%20status:merged)
 ___
 coreboot mailing list -- coreboot@coreboot.org
 To unsubscribe send an email to coreboot-le...@coreboot.org

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

[coreboot] Re: [PATCH] x86_64 support needs testing

[Aaron Durbin via coreboot]

On Tue, Oct 1, 2019 at 9:42 AM Raul Rangel  wrote:

> That's exciting. That means we can finally catch stack overflows in SMM.
>

Because of paging?

>
> On Sun, Sep 29, 2019 at 5:42 AM Patrick Rudolph 
> wrote:
>
>> Dear coreboot community,
>> Please test and review the patch series [1].
>>
>> It adds support for x86 long mode on qemu and allows to build test
>> most of coreboot's common code using the x86_64 toolchain.
>> It serves as reference implementation to migrate real hardware to long
>> mode.
>>
>> Here some technical details, that can also be found in the
>> Documentation/ folder:
>>
>> A new tool called pgtblgen create static page tables for a known
>> physical
>> memory address. The page tables are placed in CBFS at the given address.
>> Due to the fixed and known address, they can easily be loaded in
>> assembly code.
>> It only works on platforms that memory map the SPI flash, which are
>> almost all
>> modern x86 platforms.
>>
>> The advantage of page tables in ROM are:
>> * No runtime (assembly) code to generate page tables
>> * No need to find a (4K aligned) place in heap to store them
>> * Improved security for SMM, as page tables are always immutable
>>
>> The page tables are loaded in bootblock and SMM and persist until
>> control is handed
>> over to the payload.
>>
>> For the Proof-of-Concept only 4GiB are identity mapped, thus no stage
>> can't access
>> memory over 4GiB. That's not a problem for now as no coreboot code make
>> use of memory
>> above 4GiB yet.
>>
>> I haven't done further tests on long mode.
>> It will be interesting to see if there are improvements on boot speed,
>> code size or
>> faster firmware decompression speeds.
>>
>> Regards,
>> Patrick
>>
>> 1:
>>
>> https://review.coreboot.org/q/topic:%22x86_64_support2%22+(status:open%20OR%20status:merged)
>> ___
>> coreboot mailing list -- coreboot@coreboot.org
>> To unsubscribe send an email to coreboot-le...@coreboot.org
>>
> ___
> coreboot mailing list -- coreboot@coreboot.org
> To unsubscribe send an email to coreboot-le...@coreboot.org
>
___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

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

[Aaron Durbin via coreboot]

On Fri, Sep 27, 2019 at 10:42 AM Nico Huber  wrote:

> On 27.09.19 15:42, Kyösti Mälkki wrote:
> > On Thu, Sep 26, 2019 at 7:45 PM Aaron Durbin  wrote:
> >>
> >> On Thu, Sep 26, 2019 at 10:06 AM Kyösti Mälkki 
> wrote:
> >>> Should be easy enough to implement
> >>> platform hook telling to not remove PCI device node from topology
> >>> links (based on BDF), even when it does not respond to ID queries.
>
> For those who missed it: we already have a `hidden` keyword in sconfig
> which complements `on`/`off`. Currently it's only used to write static
> ACPI _STA methods. Maybe we could just use that? If a device is known
> to be hidden on purpose, don't detach it from the topology but report
> attempts to access PCI config?
>
> >>
> >>
> >> Yes, we can certainly do that. However, I also think this issue and
> yours and Nico's devicetree work are somewhat related as well as
> https://review.coreboot.org/c/coreboot/+/35621.
> >
> > I'll try to rebase all my work during the weekend>
> >> Here's some of the requirements/issues we should resolve that come to
> mind:
> >>
> >> 1. Easy way to directly retrieve a device's chip config object w/o
> traversing the device hierarchy. Which leads to...
> >> 2. Symbol alias for accessing struct device directly (no bdf lookup)
>
> More on this in a separate email.
>
> >> 3. Symbol alias for pci b/d/f lookup (equivalent of simple device but
> cleaner) so we can perform pci operations.
>
> IIRC, I asked this elsewhere already. Do we want to keep simple device?
> If we reduce `struct device` to b/d/f and a pointer to the chip info
> in early stages, couldn't we just use `struct device` for PCI config
> access everywhere?
>

We could give it a go. One issue we have is the use of dev->bus->dev in
encoding buses.

static __always_inline pci_devfn_t pcidev_bdf(const struct device *dev)
{
>---return (dev->path.pci.devfn << 12) | (dev->bus->secondary << 20);
}

If we wanted to get to more code consistency we need a better way to track
bus number (even though we don't use it in practice currently). It could be
as simple as us just conditionally supporting buses >  0 or not depending
on the environment. I don't think this is a huge blocker, but I wanted to
bring it up.

To be explicit you are thinking the following?

struct device {
  struct device_path path;
  void *config;
};


> >> 4. possibly hidden pci devices
> >>
> >> Anything else I'm missing? I think a lot of the issues we're running
> into could be fixed w/ the above. Let me know what you think.
> >>
> >
> > 5. PCI coalesce can alter PCI dev.fn assignments?
>
> That's a serious problem. I noticed that CFL FSP can reassign them
> without being asked to, unpredictably (e.g. if a device fails to show
> up in whatever timeframe FSP assumes). Solution might be simple? A
> chip->enable_dev() that updates b/d/f based on DID?
>

Ya. I think that's likely what is required.

>
> > 6. Devicetree in ENV SMM is problematic when chip config is mutable in
> > ENV_RAMSTAGE.
>
> Do we need chip config in SMM?
>

I'm not sure. I don't recall us needing it at the moment.

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

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

[Aaron Durbin via coreboot]

On Fri, Sep 27, 2019 at 11:11 AM Nico Huber  wrote:

> On 26.09.19 18:45, Aaron Durbin via coreboot wrote:
> > Here's some of the requirements/issues we should resolve that come to
> mind:
> >
> > 1. Easy way to directly retrieve a device's chip config object w/o
> > traversing the device hierarchy. Which leads to...
> > 2. Symbol alias for accessing struct device directly (no bdf lookup)
>
> What we already have:
>
> Static pointers to `struct device` for devices with a globally valid
> address (PCI devices on bus 0 and PNP devices), e.g.:
>
> DEVTREE_CONST struct device *DEVTREE_CONST __pci_0_02_0 = &_dev6;
> DEVTREE_CONST struct device *DEVTREE_CONST __pnp_002e_00 = &_dev56;
>
> What I suggested somewhere on Gerrit:
>
> At the chip driver level, add a header file that maps these to more
> distinct names, e.g.
>
> #define igd_dev __pci_0_02_0;
>
> But that was last week. Since then I've written yet another override
> tree and realized something. We write a lot lines like
>

Have you pushed this patch?

>
> device pci 02.0 on  end # Integrated Graphics Device
>
> What's wrong with that? (if you know me it's obvious) there is a
> comment! IIRC, Kyösti suggested it already, we could let sconfig
> read a chip specific mapping for device names. That would also
> allow us to write the above as
>
> device igd on end
>
> Mapping could look like this:
>
> device pci 00.0 alias mch
> device pci 02.0 alias igd
>

We can do this in 2 stages, I think, right? Or were you wanting to push a
mapping along with the alias wording? I could run with what you had prior
in patch from the get go and follow up with further clean up.

>
> and we could directly generate pointers with these names:
>
> DEVTREE_CONST struct device *DEVTREE_CONST igd_dev = &_dev6;
>
> Limitations: Actually, chip drivers can't provide global names. What
> should sconfig generate if a second instance of a chip pops up? So
> the generated pointers must somehow be limited to chips that can only
> occur once, e.g. PCH, single socket CPU.
>
> What do you think?
>
> Nico
>
___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

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

[Aaron Durbin via coreboot]

On Thu, Sep 26, 2019 at 10:06 AM Kyösti Mälkki 
wrote:

> In a nutshell:
>
> The implementation of dev_find_slot() traverses the linked list of all
> devices in the devicetree, regardless of the topology. Since PCI bus
> numbers are only assigned in early ramstage, this function is not a
> reliable API. Furthermore, referencing (dynamically) assigned PCI
> busses by integers (>1) is also prone to errors as insertion of PCIe
> add-on cards will shift these.
>
> Now.. during PCI enumeration, missing static devices are only removed
> from the PCI topology links, not the 'linked list of all devices' that
> dev_find_slot(). AFAICS, this is the root cause why pcidev_on_root()
> caused regressions with 903b40a. Should be easy enough to implement
> platform hook telling to not remove PCI device node from topology
> links (based on BDF), even when it does not respond to ID queries.
>

Yes, we can certainly do that. However, I also think this issue and yours
and Nico's devicetree work are somewhat related as well as
https://review.coreboot.org/c/coreboot/+/35621.

Here's some of the requirements/issues we should resolve that come to mind:

1. Easy way to directly retrieve a device's chip config object w/o
traversing the device hierarchy. Which leads to...
2. Symbol alias for accessing struct device directly (no bdf lookup)
3. Symbol alias for pci b/d/f lookup (equivalent of simple device but
cleaner) so we can perform pci operations.
4. possibly hidden pci devices

Anything else I'm missing? I think a lot of the issues we're running into
could be fixed w/ the above. Let me know what you think.


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

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

[Aaron Durbin via coreboot]

On Thu, Sep 26, 2019 at 8:51 AM Kyösti Mälkki 
wrote:

> Hi Matt,
>
> thanks for bringing the topic up. Please also contact your Intel reps
> about this via commercial support channel as well. I believe Patrick
> G. once stated that he could act as a relay when it comes to disputes
> between commercial and community development 'strategies'.
>
> On Wed, Sep 25, 2019 at 8:48 PM Matt DeVillier 
> wrote:
> >
> > Commit 903b40a [soc/intel: Replace uses of dev_find_slot()] replaced
> calls to dev_find_slot() with calls to pcidev_path_on_root() for all Intel
> common SoCs, but it seems unclear exactly what problem this was intended to
> fix, and has created problems with locating hidden PCI devices.
>
> I believe [1] commit explains dev_find_slot() with enough details.
>
> > Commit f2ac0137 [soc/intel: Fix regression with hidden PCI devices]
> fixed this partially by creating a debug version of pcidev_path_on_root()
> which falls back on dev_find_slot(), but did not apply it to all devices
> which need it. On SKL/KBL alone, there are at least 5 different function
> calls accessing a dozen PCI devices which require falling back on
> dev_find_slot().
> >
> > Kyosti has expressed a desire to eliminate the use of dev_find_slot()
> since it can potentially return false positives prior to device enumeration
> in ramstage, but as currently implemented the cure seems worse than the
> disease.
> >
> > Short term, it seems like having pcidev_path_on_root() fall back on
> dev_find_slot() with a loud warning (like pcidev_path_on_root_debug() does
> now) makes the most sense, vs having two nearly identical function calls
> used inconsistently. Long term, we need a better strategy for dealing with
> PCI devices which get hidden by FSP / are in violation of PCI spec.
> >
> > But since discussion on Gerrit seems to have died, reviving it here for
> a larger audience.
>

I just noticed these commits and have commented there. :)

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

I think we can provide a semantic of "possibly hidden" devices and provide
operations which do the correct thing provided the platform constraints. I
do want to understand the complete problem, though.

My current understanding is that we're forcing a device to be unhidden
after a sequence we know that hides a particular device. And we're
attempting to put it back to hidden permanently because of policy enforced
by a silicon vendor. However, if an access comes after the hide sequence we
trip over the NULL check if the device was removed from the topology. What
I couldn't figure out was what caused the need for f2ac0137? p2sb was
working still? The commits don't have more information as to the
circumstances of the failure.

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

I'm not in agreement on the policies/thinking from all the hardware
vendors. Many issues have arisen in not thinking through pci dev/fun
allocation. e.g. function 0 can be hidden but functions >1 should be
around. Definitely a violation of PCI spec and many things have been worked
around that.

That said, computer architecture/design is messy, and I think it's naive to
think everything is spec compliant. There are complex fabrics and fabric
policies in all these devices that are utilized to provide a "pci". And as
firmware people we need to deal with the realities of the hardware. That's
pretty much the point of firmware: prepare the abstractions for the OS to
make those assumptions of aligning with specs. Even then, some things just
can't be fixed (check out all the quirks and layering violations in the
drivers).



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

dev_find_slot() failures have nothing to do with blobs or not. Certainly,
some of the circumstances have tripped up some of the assumptions made in
that code. And I agree we should move away from using that API and/or
removing it.

>
> I suggest you post on the mailing list. That active PCI devices no
> longer respond to Vendor ID / Device ID queries does not meet PCI
> 

[coreboot] Re: [coreboot-gerrit] Change in ...coreboot[master]: usbdebug: Fix reserve in CAR

[Aaron Durbin via coreboot]

On Thu, Jan 31, 2019 at 11:13 AM Kyösti Mälkki (Code Review) <
ger...@coreboot.org> wrote:

> Aaron, Julius; there is a bit of dilemma with car.ld.
>
> 1) We need consistent layout across PRE_RAM stages
> 2) We want RO bootblock, unaware of (future) RW romstage requirements
> 3) I don't like the semi-random size reserve, like done here for usbdebug
>
> Any ideas how to from improve this? Looking at CONFIG_COMMONLIB_STORAGE
> and CONFIG_PAGING_IN_CACHE_AS_RAM, I am not sure if the fixed locations are
> always maintained properly. There is some strong assumption at least, that
> bootblock and romstage are built with same set of Kconfig options set.
>

That definitely is the assumption. Kconfigs are global and there shouldn't
be guarding of entries in the car.ld linker script based on stage w.r.t. to
order and size of the allocated space.

> View Change 
>
> 1 comment:
>
>-
>
>File src/arch/x86/car.ld:
>
>-
>
>   Patch Set #1, Line 70:
>    .
>   += 0x60;
>
>   yes
>
>   Done
>
> To view, visit change 31174
> . To unsubscribe, or for
> help writing mail filters, visit settings
> .
> Gerrit-Project: coreboot
> Gerrit-Branch: master
> Gerrit-Change-Id: Ib49fca781e55619179aae2d859560e050876
> Gerrit-Change-Number: 31174
> Gerrit-PatchSet: 2
> Gerrit-Owner: Kyösti Mälkki 
> Gerrit-Reviewer: Arthur Heymans 
> Gerrit-Reviewer: Julius Werner 
> Gerrit-Reviewer: Kyösti Mälkki 
> Gerrit-Reviewer: Nico Huber 
> Gerrit-Reviewer: Patrick Rudolph 
> Gerrit-Reviewer: build bot (Jenkins) 
> Gerrit-CC: Paul Menzel 
> Gerrit-Comment-Date: Thu, 31 Jan 2019 18:13:01 +
> Gerrit-HasComments: Yes
> Gerrit-Has-Labels: No
> Comment-In-Reply-To: Patrick Rudolph 
> Comment-In-Reply-To: Arthur Heymans 
> Gerrit-MessageType: comment
> ___
> coreboot-gerrit mailing list -- coreboot-ger...@coreboot.org
> To unsubscribe send an email to coreboot-gerrit-le...@coreboot.org
>
___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] Re: Fallback mechanisms on x86 with C_ENVIRONMENT_BOOTBLOCK

[Aaron Durbin via coreboot]

On Thu, Jan 24, 2019 at 6:24 PM Julius Werner  wrote:

> > What does that practically look like? Every time we have to re-walk we
> have to reverify the integrity of the metadata.
>
> I mean, that is exactly what we're doing right now anyway (unless
> something significantly changed in CBFS code since the last time I
> checked). For every single CBFS file access we start at the root and
> we walk the chain until we find the file we're trying to load (and all
> of this are real SPI transfers, it's not cached anywhere). Hashing
> times are generally insignificant compared to SPI access times IIRC
> (especially since this should be a raw hash, not an RSA signature like
> we use in current vboot). Validating the hash means we have to walk
> the whole CBFS directory rather than stopping at the file when we find
> it, but since we generally don't really pay attention for CBFS file
> placement for performance right now that's presumably not a big deal
> (would only double cost on average).
>
> And there are certainly still ways to improve this with the right
> caching, and ways to do that in a safe way even if verification is
> involved, which we could explore if we wanted to. I'm just saying as a
> baseline that the cost of CBFS walks seems to have never bothered us
> in the past, so the comparable cost of reverifying metadata probably
> shouldn't be a major criterion to reject the per-file approach.
>

I wasn't considering just the perf costs. I was including the notion of
re-checking and re-visiting the boot media repeatedly wit TOCTOU in mind. I
think we're on the same page, though, with the two approaches on what both
would entail. We collectively need to align on pros/cons of both and
ultimately decide on an approach.
___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] Re: Fallback mechanisms on x86 with C_ENVIRONMENT_BOOTBLOCK

[Aaron Durbin via coreboot]

On Wed, Jan 23, 2019 at 11:17 PM Zeh, Werner  wrote:

> Currently with the one CBFS containing all files it is easy and simple to
> access every file in every stage.
> Wouldn't this be harder if we chose to split the CBFS into several,
> stand-alone CBFSes?
> Or, on the other hand, wouldn't we end up in duplicating CBFS files just
> to have them around handy?
>
> I have the case in mind where we need access to data other than
> stage-code  like Siemens' HWInfo.
> We need to access this configuration data from different stages.
>

Such a thing would need to be loaded once and maintained in-core. But that
would be true regardless of cbfs layout. However, if one doesn't care about
protecting against physical attacks on boot media it's not really
relevant. There's also more than one way to do things. For example, if we
implemented namespacing that mapped to cbfs region then the call site would
also just work as-is with a name change. e.g. 'file1' -> 'ns/file1' where
'ns' would map to a specific region. However that's more like a vfs
implementation, but it's not too complicated to implement if we wanted to
do such a thing.


> Werner
>
> > -Ursprüngliche Nachricht-
> > Von: Julius Werner [mailto:jwer...@chromium.org]
> > Gesendet: Donnerstag, 24. Januar 2019 00:01
> > An: Aaron Durbin
> > Cc: Julius Werner; Arthur Heymans; Coreboot
> > Betreff: [coreboot] Re: Fallback mechanisms on x86 with
> C_ENVIRONMENT_BOOTBLOCK
> >
> > > For 1, this is attempting to protect physical attack. Obviously this
> particular problem can't be solved in isolation, but it's something to think
> > about.
> >
> > But isn't this something that per-file hashing would probably make
> easier to protect against, not harder? I mean, right now we just hash the
> > whole region once and then assume it stays good -- there is no
> protection. I doubt this would really become easier to solve if you split
> the
> > CBFS up into chunks... you'd have to somehow built a system where a
> whole chunk is loaded into memory at once, verified there, and then
> > every file we may want to access from it is accessed in that same stage
> from that cached version in memory.
> >
> > The file is the natural unit which is loaded at a time, so I'd think
> scoping the verification to that would make it easiest to verify on load. I
> > mean, on Arm we already always load whole files at a time anyway, so
> it's really just a matter of inserting the verification step between load
> > and decompression on the buffer we already have. (On
> > x86 it may be a bit different, but it should still be easier to find
> space to load a file at a time than to load a larger CBFS chunk at a
> > time.)
> >
> > > When discussing 2 from a practical matter, we need to pass on the
> metadata information across stages to help mitigate 1 and ensure
> > integrity of the hashes are correct.
> >
> > This is true -- but isn't this the same for all solutions? No matter how
> you scope verification, if you want to verify things at load time then
> > every stage needs to be able to run verification, and it needs some kind
> of trust anchor passed in from a previous stage for that. I also don't
> > think this should be a huge hurdle... we're already passing vboot
> workbuffer metadata, this just means passing something more in there.
> > (For per-file hashing, I'd assume you'd just pass the single hash
> covering all the metadata, and then all the metadata is verified again on
> > every CBFS walk.)
> >
> > > Similarly, limiting complexity is also important. If we can group the
> assets together that are tied to the boot flow then it's conceptually
> > easier to limit access to regions that haven't been checked yet or
> shouldn't be accessed. I do think per-file metadata hashing brings a lot of
> > complications in implementation. When in limited resource environments
> chunking cbfs into multiple regions lends itself well to
> > accomplishing that while also restricting access to data/regions that
> aren't needed yet when thinking about limiting #1.
> >
> > Fair enough. I agree limiting complexity is always important, I'm just
> not ad-hoc convinced that a solution like you describe would really be
> > less complex than per-file hashing. I think that while it makes the CBFS
> access code itself a bit more complex, it would save complexity in
> > other areas (e.g. if you have arbitrary chunks then something must
> decide which chunk to use at what time and which file to pack into
> > which chunk, all of which is extra code). Assuming we can "get it right
> once", I think per-file hashing should be a solution that will "just work"
> > for whatever future platform ports and general features want to put in
> CBFS (whereas a solution where everyone who wants to put another
> > file into CBFS must understand the verification solution well enough to
> make an informed decision on which chunk to place something into
> > may end up pushing more complexity onto more people).
> >
> > Anyway, I 

[coreboot] Re: Fallback mechanisms on x86 with C_ENVIRONMENT_BOOTBLOCK

[Aaron Durbin via coreboot]

On Wed, Jan 23, 2019 at 4:00 PM Julius Werner  wrote:

> > For 1, this is attempting to protect physical attack. Obviously this
> particular problem can't be solved in isolation, but it's something to
> think about.
>
> But isn't this something that per-file hashing would probably make
> easier to protect against, not harder? I mean, right now we just hash
> the whole region once and then assume it stays good -- there is no
> protection. I doubt this would really become easier to solve if you
> split the CBFS up into chunks... you'd have to somehow built a system
> where a whole chunk is loaded into memory at once, verified there, and
> then every file we may want to access from it is accessed in that same
> stage from that cached version in memory.
>
> The file is the natural unit which is loaded at a time, so I'd think
> scoping the verification to that would make it easiest to verify on
> load. I mean, on Arm we already always load whole files at a time
> anyway, so it's really just a matter of inserting the verification
> step between load and decompression on the buffer we already have. (On
> x86 it may be a bit different, but it should still be easier to find
> space to load a file at a time than to load a larger CBFS chunk at a
> time.)
>

I don't believe the per-file approach necessarily makes things easier to
protect. In fact the re-walk with validation might make it easier to
exploit (depending on complexity of implementation). For
time-of-check-time-of-use scenarios the easier thing is to load data that
will be used in-core. i.e. not going back to boot media. Platform specifics
with resource constraints would inherently leave these attacks open. Your
suggestion on loading file, verifying, then using is valid, but my concern
is all the rewalking of cbfs (comment below).


> > When discussing 2 from a practical matter, we need to pass on the
> metadata information across stages to help mitigate 1 and ensure integrity
> of the hashes are correct.
>
> This is true -- but isn't this the same for all solutions? No matter
> how you scope verification, if you want to verify things at load time
> then every stage needs to be able to run verification, and it needs
> some kind of trust anchor passed in from a previous stage for that. I
> also don't think this should be a huge hurdle... we're already passing
> vboot workbuffer metadata, this just means passing something more in
> there. (For per-file hashing, I'd assume you'd just pass the single
> hash covering all the metadata, and then all the metadata is verified
> again on every CBFS walk.)
>

What does that practically look like? Every time we have to re-walk we have
to reverify the integrity of the metadata. Designing on the fly, to me that
suggests we need to carry a copy of the metadata including offset & size
after verifying it and not using it again on the boot media. That way it
stays in-core. Otherwise, one has to walk all of the cbfs to only rewind
and find the file again. There's variants of how big a span is covered by
the metadata hash (i.e. how many entries), but one shouldn't rely upon
existing entries every time we walk. It should be reliant upon the previous
verified and cached metadata. Assets and access patterns very much are a
part of the puzzle. Some platforms have very little assets while others
have a quite a bit.

>
> > Similarly, limiting complexity is also important. If we can group the
> assets together that are tied to the boot flow then it's conceptually
> easier to limit access to regions that haven't been checked yet or
> shouldn't be accessed. I do think per-file metadata hashing brings a lot of
> complications in implementation. When in limited resource environments
> chunking cbfs into multiple regions lends itself well to accomplishing that
> while also restricting access to data/regions that aren't needed yet when
> thinking about limiting #1.
>
> Fair enough. I agree limiting complexity is always important, I'm just
> not ad-hoc convinced that a solution like you describe would really be
> less complex than per-file hashing. I think that while it makes the
> CBFS access code itself a bit more complex, it would save complexity
> in other areas (e.g. if you have arbitrary chunks then something must
> decide which chunk to use at what time and which file to pack into
> which chunk, all of which is extra code). Assuming we can "get it
> right once", I think per-file hashing should be a solution that will
> "just work" for whatever future platform ports and general features
> want to put in CBFS (whereas a solution where everyone who wants to
> put another file into CBFS must understand the verification solution
> well enough to make an informed decision on which chunk to place
> something into may end up pushing more complexity onto more people).
>

The decision on where files go is a static one at build time. When the cbfs
chunks follow boot flow then the decision to switch to a new one follows
those same boundaries. I 

[coreboot] Re: Fallback mechanisms on x86 with C_ENVIRONMENT_BOOTBLOCK

[Aaron Durbin via coreboot]

On Tue, Jan 22, 2019 at 6:21 PM Julius Werner  wrote:

> > FWIW, it's my opinion I think we'll need to start splitting cbfs into
> smaller ones. This isn't specific to this situation, but splitting slots
> into multiple cbfses  (rw-a-1, rw-a-2, etc) allows one to chain/group
> resources as they are used along with more flexibility for
> signing/verification methods. What you wrote above seems sane, but I think
> you'll run into build limitations that don't allow one to target fmap
> regions for different assets. It's a lot of Make w/ some special casing
> currently which is because people didn't want another tool at the time --
> however, once you need more cbfs regions of different granularity I think
> having better tooling around targeting final destination for assets is
> required.
>
> Are we abandoning the idea to verify individual files instead (once
> someone has time to implement it) then? I'd still think that would be
> a nicer solution to get more flexible verification.
>

I'm just expressing my opinion on how I think we should move forward. I'm a
little concerned about multiple things when it comes to doing per-file
signature/hashing:

1. Time of Check and Time of Use issues.
2. Passing metadata forward for validation.
3. Complexity

For 1, this is attempting to protect physical attack. Obviously this
particular problem can't be solved in isolation, but it's something to
think about. When discussing 2 from a practical matter, we need to pass on
the metadata information across stages to help mitigate 1 and ensure
integrity of the hashes are correct. Similarly, limiting complexity is also
important. If we can group the assets together that are tied to the boot
flow then it's conceptually easier to limit access to regions that haven't
been checked yet or shouldn't be accessed. I do think per-file metadata
hashing brings a lot of complications in implementation. When in limited
resource environments chunking cbfs into multiple regions lends itself well
to accomplishing that while also restricting access to data/regions that
aren't needed yet when thinking about limiting #1.

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

[coreboot] Re: Fallback mechanisms on x86 with C_ENVIRONMENT_BOOTBLOCK

[Aaron Durbin via coreboot]

On Tue, Jan 22, 2019 at 6:45 AM Arthur Heymans  wrote:

> Hi
>
> As more and more x86 platforms are moving to C_ENVIRONMENT_BOOTBLOCK
> and therefore don't use a romcc compiled bootblock anymore a certain
> question arises. With the romcc bootblock there was a normal/fallback
> mechanism.
>
> It works the following way:
> It uses RTC cmos to select between the normal and the fallback
> bootpaths. So depending on that bit the bootblock selected either
> normal/romstage or fallback/romstage which also load postcar stage,
> ramstage and payloads with the same prefix from there. There is also a
> reboot counter which makes sure that it actually gets to the point it
> can load the payload and depending on CONFIG_SKIP_MAX_REBOOT_CNT_CLEAR
> it resets that the counter.
>
> This mechanism is not very robust and is more intended to be used to be
> able to test things without needing a hardware programmer to flash
> images in the case something goes wrong. I use it for instance to test
> changes on laptops which take a long time to disassemble.
>
> Currently C_ENVIRONMENT_BOOTBLOCK lacks such generic mechanism on x86
> platforms. On the first sight it looks like VBOOT with verstage running
> after the bootblock, might be able to achieve a similar boot
> scheme. VBOOT seems to lack documentation and while not that hard to get
> working, it looks like it is not falling back when there is problem on a
> RW_A/B boot path (I called die die(); somewhere in the ramstage to
> test). Also the tools around vboot (crossystem) are quite chromeos
> specific, requiring Chromeos specific ACPI code exposing the VBNV
> variables and also a Linux kernel exposing those ACPI methods via
> sysfs.
>
> My understanding of VBOOT might be incorrect or incomplete, so it would
> be great if someone more knowledgeable could fill in here.
>

There's a trycount that I think defaults to 10. After 10 failing tries it
should switch slots. There's also a 'set good firmware' notion which
signals to the firmware one was able to boot. This is picked up on the next
reboot and the information is passed through  vboot non volatile storage. I
can dig up specific pointers in the code, but you may not have tried enough
times to see things switch.

That said, if you want to implement fallback stuff, it should be fairly
straight forward to do -- and not rely on vboot.


> So at the moment it looks like VBOOT does not fit the bill to be able to
> quickly test things while having a fallback mechanism.
>
> Now being able to run GCC compiled code in the bootblock does have the
> advantage of allowing much more flexibility over romcc compiled code.
> So it is possible to simply reimplement the same behavior with different
> prefixes for bootpaths but it would also be possible to do something
> similar to what vboot does, namely using separate FMAP regions for boot
> paths. This would require a simple cbfs_locator. Upstream flashrom
> master now supports using FMAP as a layout so it would be rather easy to
> use.
>
> Using FMAP requires a little bit more work (generating a proper default
> FMAP, populate the CBFS FMAP regions, implementing a cbfs_locator) but
> does allow for nice features like locking the fallback CBFS region to
> make sure the fallback can't be erased by accident.
>
> Any thought or suggestions?
>

FWIW, it's my opinion I think we'll need to start splitting cbfs into
smaller ones. This isn't specific to this situation, but splitting slots
into multiple cbfses  (rw-a-1, rw-a-2, etc) allows one to chain/group
resources as they are used along with more flexibility for
signing/verification methods. What you wrote above seems sane, but I think
you'll run into build limitations that don't allow one to target fmap
regions for different assets. It's a lot of Make w/ some special casing
currently which is because people didn't want another tool at the time --
however, once you need more cbfs regions of different granularity I think
having better tooling around targeting final destination for assets is
required.



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

Re: [coreboot] Coreboot hangs during SYS_RESET

[Aaron Durbin via coreboot]

On Wed, Nov 7, 2018 at 6:47 AM Antony AbeePrakash X V
 wrote:
>
> Hi,
>
>
>
> We are developing coreboot (with Intel FSP) for apollo lake platform custom 
> board. We are facing a hang issue during the SYS_RESET button press.
>
>
>
> Observations:
>
> With soft reset the board gets hang(occurs within 2 or 3 reboot) with POST 
> code 0x38 and the coreboot log stops during the romstage relocation. (Logs 
> attached for Ref.)
> When the SYS_RESET is pressed again the board boots and hangs at same POST 
> code 0x38.
>
>
>
> Please provide feedback and help us to resolve this issue.
>

I'm confused by the following logs in romstage:

CBFS @ 0 size 7
CBFS: Locating 'romstage.rel'
CBFS: Found @ offset 64c0 size 480
romstage is relocated from fef40054 to 0x7abf1000

I'm not familiar where this code is coming from.  Are you carrying
external patches or have I forgotten what is going on here?

>
>
> Currently our coreboot build does not include any microcode 
> (CPU_MICROCODE_CBFS_NONE). We tried to change it as “Generate from tree” in 
> memuconfig.
>
> But the build fails with fatal error saying no microcode/microcode.h file.
>
>
>
> Whether the CPU by default have microcode ? or we need to build the microcode 
> in coreboot ?
>
> Please advise on this.
>
>
>
> Thanks & Regards,
>
> Antony
>
>
>
> L Technology Services Ltd
>
> www.LntTechservices.com
>
> This Email may contain confidential or privileged information for the 
> intended recipient (s). If you are not the intended recipient, please do not 
> use or disseminate the information, notify the sender and delete it from your 
> system.

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

Re: [coreboot] MRC in coreboot

[Aaron Durbin via coreboot]

On Mon, Oct 15, 2018 at 6:42 AM Antony AbeePrakash X V
 wrote:
>
> Hi Aron,
>
>
>
> I have tried giving iomem=relaxed to the kernel command line. But still I am 
> getting the same error.
>
>
>
> This time I tried with verbose option and the output is below
>
> $ ./cbmem -V -t
>
>
>
> Looking for coreboot table at 0 1048576 bytes.
>
> Mapping 1MB of physical memory at 0x0 (requested 0x0).
>
> Unmapping 1MB of virtual memory at 0x7fd372347000.
>
> Looking for coreboot table at f 1048576 bytes.
>
> Mapping 1MB of physical memory at 0xf (requested 0xf).
>
>   ... failed.  Mapping 1052671B of physical memory at 0xef000.
>
> Failed to mmap /dev/mem: Operation not permitted
>
>
>
> Also could you please tell any method to measure the boot time ? Currently we 
> are measuring with the help of stop watch which may not accurate.

cbmem -t will provide it. What do you see in 'dmesg' ? Also, what do
the e820 entries show? They should match below.

 0. -0fff: CONFIGURATION TABLES
 1. 1000-0009: RAM
 2. 000a-000f: RESERVED
 3. 0010-0fff: RAM
 4. 1000-12150fff: RESERVED
 5. 12151000-7a92cfff: RAM
 6. 7a92d000-7aff: CONFIGURATION TABLES
 7. 7b00-7fff: RESERVED
 8. d000-: RESERVED

How old of a cbmem utility are you using? don't understand where the
1MiB mappings are coming from.

>
>
>
> Thanks,
>
> Antony
>
>
>
> From: Aaron Durbin [mailto:adur...@google.com]
> Sent: Friday, October 12, 2018 7:12 PM
> To: Antony AbeePrakash X V 
> Cc: Coreboot ; Dinesh Kumar 
> 
> Subject: Re: [coreboot] MRC in coreboot
>
>
>
>
>
>
>
> On Fri, Oct 12, 2018 at 4:38 AM Antony AbeePrakash X V 
>  wrote:
>
> Hi Aron,
>
>
>
> I am not able to get the cbmem timestamps. I am using cbmem utility to find 
> the timestamps.
>
>
>
> $ . /cbmem -t
>
>
>
> The above command gives the following error.
>
>
>
> Failed to mmap /dev/mem : Operation not permitted
>
>
>
> Could you please help on this?
>
>
>
> https://01.org/linuxgraphics/gfx-docs/drm/admin-guide/kernel-parameters.html
>
>
>
> Adding 'iomem=relaxed' to the kernel cmdline would fix that particular 
> problem.
>
>
>
> Note, with that current error, that you should see a PAT error in dmesg.
>
>
>
>
>
> Thanks & Regards,
>
> Antony
>
> From: Aaron Durbin [mailto:adur...@google.com]
> Sent: Thursday, October 11, 2018 9:44 PM
> To: Antony AbeePrakash X V 
> Cc: Coreboot ; Dinesh Kumar 
> 
> Subject: Re: [coreboot] MRC in coreboot
>
>
>
> cbmem timstamps will be needed.
>
>
>
> Looks like FSP is manipulating the tsc:
>
> BS: BS_DEV_INIT_CHIPS times (us): entry 0 run 4291539104 exit 0
>
>
>
> I have a hard time believing that took 4291 seconds.
>
>
>
> On Thu, Oct 11, 2018 at 10:11 AM Antony AbeePrakash X V 
>  wrote:
>
> Hi Aaron,
>
> PFA the console log for your reference.
>
> Please look into this and provide feedback.
>
> Thanks,
> Antony
>
> -Original Message-
> From: Aaron Durbin [mailto:adur...@google.com]
> Sent: Thursday, October 11, 2018 7:27 PM
> To: Antony AbeePrakash X V 
> Cc: Coreboot ; Dinesh Kumar 
> 
> Subject: Re: [coreboot] MRC in coreboot
>
> On Thu, Oct 11, 2018 at 3:24 AM Antony AbeePrakash X V 
>  wrote:
> >
> > Hi All,
> >
> > We are able to achieve the memory initialization time reduction. Now we 
> > have achieved the boot time as 5sec until the Postcode 0xf8 (entry into Elf 
> > boot).
> >
> > We have reduced the unwanted codes. We would like to reduce the boot time 
> > to less than 2sec.
> >
> > Could anyone please tell what can be done further ?
>
> You're going to need to post more information (cbmem timings and console 
> logs).
>
> >
> > Thanks,
> > Antony
> >
> > -Original Message-
> > From: Aaron Durbin [mailto:adur...@google.com]
> > Sent: Wednesday, September 05, 2018 7:39 PM
> > To: Antony AbeePrakash X V 
> > Cc: Coreboot 
> > Subject: Re: [coreboot] MRC in coreboot
> >
> > On Wed, Sep 5, 2018 at 8:06 AM Antony AbeePrakash X V 
> >  wrote:
> > >
> > > Hi,
> > >
> > >
> > >
> > > We are developing coreboot for Apollo lake custom board.  MRC training 
> > > data save is enabled in FSP using Binary configuration tool.
> > >
> > >
> > >
> > > But we are getting logs like,
> > >
> > >
> > >
> > > No MRC cache found.
> > >
> > > MRC SeCUmaSize memory size from SeC ... 0
> > >
> > > MRC Parameters not valid. Status is Success
> > >
> > > MRC:CpuMemoryTest Successful!
> > >
> > > Saving MRC data using CSE through HECI interface
> >
> > I have never seen this path used in coreboot. This line above is saying CSE 
> > is responsible for saving and retrieving training data. In coreboot we use 
> > the main processor to save and restore. I suggest reading over the UPD 
> > parameters and ensure they match with our typical use cases. BCT tool 
> > enabling 'training data save' sounds like it's enabling CSE path.
> >
> > >
> > > Try to find 

Re: [coreboot] MRC in coreboot

[Aaron Durbin via coreboot]

On Fri, Oct 12, 2018 at 4:38 AM Antony AbeePrakash X V <
antonyabee.prakas...@lnttechservices.com> wrote:

> Hi Aron,
>
>
>
> I am not able to get the cbmem timestamps. I am using cbmem utility to
> find the timestamps.
>
>
>
> *$ . /cbmem -t*
>
>
>
> The above command gives the following error.
>
>
>
> *Failed to mmap /dev/mem : Operation not permitted*
>
>
>
> Could you please help on this?
>

https://01.org/linuxgraphics/gfx-docs/drm/admin-guide/kernel-parameters.html

Adding 'iomem=relaxed' to the kernel cmdline would fix that particular
problem.

Note, with that current error, that you should see a PAT error in dmesg.


>
> Thanks & Regards,
>
> Antony
>
> *From:* Aaron Durbin [mailto:adur...@google.com]
> *Sent:* Thursday, October 11, 2018 9:44 PM
> *To:* Antony AbeePrakash X V 
> *Cc:* Coreboot ; Dinesh Kumar <
> dineshkumar.varadara...@lnttechservices.com>
> *Subject:* Re: [coreboot] MRC in coreboot
>
>
>
> cbmem timstamps will be needed.
>
>
>
> Looks like FSP is manipulating the tsc:
>
> BS: BS_DEV_INIT_CHIPS times (us): entry 0 run 4291539104 exit 0
>
>
>
> I have a hard time believing that took 4291 seconds.
>
>
>
> On Thu, Oct 11, 2018 at 10:11 AM Antony AbeePrakash X V <
> antonyabee.prakas...@lnttechservices.com> wrote:
>
> Hi Aaron,
>
> PFA the console log for your reference.
>
> Please look into this and provide feedback.
>
> Thanks,
> Antony
>
> -Original Message-
> From: Aaron Durbin [mailto:adur...@google.com]
> Sent: Thursday, October 11, 2018 7:27 PM
> To: Antony AbeePrakash X V 
> Cc: Coreboot ; Dinesh Kumar <
> dineshkumar.varadara...@lnttechservices.com>
> Subject: Re: [coreboot] MRC in coreboot
>
> On Thu, Oct 11, 2018 at 3:24 AM Antony AbeePrakash X V <
> antonyabee.prakas...@lnttechservices.com> wrote:
> >
> > Hi All,
> >
> > We are able to achieve the memory initialization time reduction. Now we
> have achieved the boot time as 5sec until the Postcode 0xf8 (entry into Elf
> boot).
> >
> > We have reduced the unwanted codes. We would like to reduce the boot
> time to less than 2sec.
> >
> > Could anyone please tell what can be done further ?
>
> You're going to need to post more information (cbmem timings and console
> logs).
>
> >
> > Thanks,
> > Antony
> >
> > -Original Message-
> > From: Aaron Durbin [mailto:adur...@google.com]
> > Sent: Wednesday, September 05, 2018 7:39 PM
> > To: Antony AbeePrakash X V 
> > Cc: Coreboot 
> > Subject: Re: [coreboot] MRC in coreboot
> >
> > On Wed, Sep 5, 2018 at 8:06 AM Antony AbeePrakash X V <
> antonyabee.prakas...@lnttechservices.com> wrote:
> > >
> > > Hi,
> > >
> > >
> > >
> > > We are developing coreboot for Apollo lake custom board.  MRC training
> data save is enabled in FSP using Binary configuration tool.
> > >
> > >
> > >
> > > But we are getting logs like,
> > >
> > >
> > >
> > > No MRC cache found.
> > >
> > > MRC SeCUmaSize memory size from SeC ... 0
> > >
> > > MRC Parameters not valid. Status is Success
> > >
> > > MRC:CpuMemoryTest Successful!
> > >
> > > Saving MRC data using CSE through HECI interface
> >
> > I have never seen this path used in coreboot. This line above is saying
> CSE is responsible for saving and retrieving training data. In coreboot we
> use the main processor to save and restore. I suggest reading over the UPD
> parameters and ensure they match with our typical use cases. BCT tool
> enabling 'training data save' sounds like it's enabling CSE path.
> >
> > >
> > > Try to find MRC training data HOB.
> > >
> > > No MRC training data found, perform data save via HECI.
> > >
> > > Saved MRC training data with status (0x8003)
> > >
> > >
> > >
> > > It seems that MRC data is not found and saved. Also I found that there
> are options to add MRC file path and mrc.bin in menuconfig. The only option
> I have is save cached MRC settings.
> > >
> > >
> > >
> > > What this mrc.bin will do?
> > >
> > > How to add the mrc.bin in coreboot?
> > >
> > >
> > >
> > > Please explain on this.
> > >
> > >
> > >
> > > Thanks & Regards,
> > >
> > > Antony
> > >
> > >
> > >
> > > L Technology Services Ltd
> > >
> > > www.LntTechservices.com
> > >
> > > This Email may contain confidential or privileged information for the
> intended recipient (s). If you are not the intended recipient, please do
> not use or disseminate the information, notify the sender and delete it
> from your system.
> > >
> > > --
> > > coreboot mailing list: coreboot@coreboot.org
> > > https://mail.coreboot.org/mailman/listinfo/coreboot
> > L Technology Services Ltd
> >
> > www.LntTechservices.com
> >
> > This Email may contain confidential or privileged information for the
> intended recipient (s). If you are not the intended recipient, please do
> not use or disseminate the information, notify the sender and delete it
> from your system.
> L Technology Services Ltd
>
> www.LntTechservices.com
>
> This Email may contain confidential or privileged information for the
> 

Re: [coreboot] MRC in coreboot

[Aaron Durbin via coreboot]

cbmem timstamps will be needed.

Looks like FSP is manipulating the tsc:

BS: BS_DEV_INIT_CHIPS times (us): entry 0 run 4291539104 exit 0


I have a hard time believing that took 4291 seconds.


On Thu, Oct 11, 2018 at 10:11 AM Antony AbeePrakash X V <
antonyabee.prakas...@lnttechservices.com> wrote:

> Hi Aaron,
>
> PFA the console log for your reference.
>
> Please look into this and provide feedback.
>
> Thanks,
> Antony
>
> -Original Message-
> From: Aaron Durbin [mailto:adur...@google.com]
> Sent: Thursday, October 11, 2018 7:27 PM
> To: Antony AbeePrakash X V 
> Cc: Coreboot ; Dinesh Kumar <
> dineshkumar.varadara...@lnttechservices.com>
> Subject: Re: [coreboot] MRC in coreboot
>
> On Thu, Oct 11, 2018 at 3:24 AM Antony AbeePrakash X V <
> antonyabee.prakas...@lnttechservices.com> wrote:
> >
> > Hi All,
> >
> > We are able to achieve the memory initialization time reduction. Now we
> have achieved the boot time as 5sec until the Postcode 0xf8 (entry into Elf
> boot).
> >
> > We have reduced the unwanted codes. We would like to reduce the boot
> time to less than 2sec.
> >
> > Could anyone please tell what can be done further ?
>
> You're going to need to post more information (cbmem timings and console
> logs).
>
> >
> > Thanks,
> > Antony
> >
> > -Original Message-
> > From: Aaron Durbin [mailto:adur...@google.com]
> > Sent: Wednesday, September 05, 2018 7:39 PM
> > To: Antony AbeePrakash X V 
> > Cc: Coreboot 
> > Subject: Re: [coreboot] MRC in coreboot
> >
> > On Wed, Sep 5, 2018 at 8:06 AM Antony AbeePrakash X V <
> antonyabee.prakas...@lnttechservices.com> wrote:
> > >
> > > Hi,
> > >
> > >
> > >
> > > We are developing coreboot for Apollo lake custom board.  MRC training
> data save is enabled in FSP using Binary configuration tool.
> > >
> > >
> > >
> > > But we are getting logs like,
> > >
> > >
> > >
> > > No MRC cache found.
> > >
> > > MRC SeCUmaSize memory size from SeC ... 0
> > >
> > > MRC Parameters not valid. Status is Success
> > >
> > > MRC:CpuMemoryTest Successful!
> > >
> > > Saving MRC data using CSE through HECI interface
> >
> > I have never seen this path used in coreboot. This line above is saying
> CSE is responsible for saving and retrieving training data. In coreboot we
> use the main processor to save and restore. I suggest reading over the UPD
> parameters and ensure they match with our typical use cases. BCT tool
> enabling 'training data save' sounds like it's enabling CSE path.
> >
> > >
> > > Try to find MRC training data HOB.
> > >
> > > No MRC training data found, perform data save via HECI.
> > >
> > > Saved MRC training data with status (0x8003)
> > >
> > >
> > >
> > > It seems that MRC data is not found and saved. Also I found that there
> are options to add MRC file path and mrc.bin in menuconfig. The only option
> I have is save cached MRC settings.
> > >
> > >
> > >
> > > What this mrc.bin will do?
> > >
> > > How to add the mrc.bin in coreboot?
> > >
> > >
> > >
> > > Please explain on this.
> > >
> > >
> > >
> > > Thanks & Regards,
> > >
> > > Antony
> > >
> > >
> > >
> > > L Technology Services Ltd
> > >
> > > www.LntTechservices.com
> > >
> > > This Email may contain confidential or privileged information for the
> intended recipient (s). If you are not the intended recipient, please do
> not use or disseminate the information, notify the sender and delete it
> from your system.
> > >
> > > --
> > > coreboot mailing list: coreboot@coreboot.org
> > > https://mail.coreboot.org/mailman/listinfo/coreboot
> > L Technology Services Ltd
> >
> > www.LntTechservices.com
> >
> > This Email may contain confidential or privileged information for the
> intended recipient (s). If you are not the intended recipient, please do
> not use or disseminate the information, notify the sender and delete it
> from your system.
> L Technology Services Ltd
>
> www.LntTechservices.com
>
> This Email may contain confidential or privileged information for the
> intended recipient (s). If you are not the intended recipient, please do
> not use or disseminate the information, notify the sender and delete it
> from your system.
>
-- 
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] MRC in coreboot

[Aaron Durbin via coreboot]

On Thu, Oct 11, 2018 at 3:24 AM Antony AbeePrakash X V
 wrote:
>
> Hi All,
>
> We are able to achieve the memory initialization time reduction. Now we have 
> achieved the boot time as 5sec until the Postcode 0xf8 (entry into Elf boot).
>
> We have reduced the unwanted codes. We would like to reduce the boot time to 
> less than 2sec.
>
> Could anyone please tell what can be done further ?

You're going to need to post more information (cbmem timings and console logs).

>
> Thanks,
> Antony
>
> -Original Message-
> From: Aaron Durbin [mailto:adur...@google.com]
> Sent: Wednesday, September 05, 2018 7:39 PM
> To: Antony AbeePrakash X V 
> Cc: Coreboot 
> Subject: Re: [coreboot] MRC in coreboot
>
> On Wed, Sep 5, 2018 at 8:06 AM Antony AbeePrakash X V 
>  wrote:
> >
> > Hi,
> >
> >
> >
> > We are developing coreboot for Apollo lake custom board.  MRC training data 
> > save is enabled in FSP using Binary configuration tool.
> >
> >
> >
> > But we are getting logs like,
> >
> >
> >
> > No MRC cache found.
> >
> > MRC SeCUmaSize memory size from SeC ... 0
> >
> > MRC Parameters not valid. Status is Success
> >
> > MRC:CpuMemoryTest Successful!
> >
> > Saving MRC data using CSE through HECI interface
>
> I have never seen this path used in coreboot. This line above is saying CSE 
> is responsible for saving and retrieving training data. In coreboot we use 
> the main processor to save and restore. I suggest reading over the UPD 
> parameters and ensure they match with our typical use cases. BCT tool 
> enabling 'training data save' sounds like it's enabling CSE path.
>
> >
> > Try to find MRC training data HOB.
> >
> > No MRC training data found, perform data save via HECI.
> >
> > Saved MRC training data with status (0x8003)
> >
> >
> >
> > It seems that MRC data is not found and saved. Also I found that there are 
> > options to add MRC file path and mrc.bin in menuconfig. The only option I 
> > have is save cached MRC settings.
> >
> >
> >
> > What this mrc.bin will do?
> >
> > How to add the mrc.bin in coreboot?
> >
> >
> >
> > Please explain on this.
> >
> >
> >
> > Thanks & Regards,
> >
> > Antony
> >
> >
> >
> > L Technology Services Ltd
> >
> > www.LntTechservices.com
> >
> > This Email may contain confidential or privileged information for the 
> > intended recipient (s). If you are not the intended recipient, please do 
> > not use or disseminate the information, notify the sender and delete it 
> > from your system.
> >
> > --
> > coreboot mailing list: coreboot@coreboot.org
> > https://mail.coreboot.org/mailman/listinfo/coreboot
> L Technology Services Ltd
>
> www.LntTechservices.com
>
> This Email may contain confidential or privileged information for the 
> intended recipient (s). If you are not the intended recipient, please do not 
> use or disseminate the information, notify the sender and delete it from your 
> system.

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

Re: [coreboot] Loading Linux payloads on RISC-V

[Aaron Durbin via coreboot]

On Sun, Sep 23, 2018 at 9:00 AM ron minnich  wrote:
>
> ah sorry I forgot.
>
> I think selfboot could be reworked (and should be) to interpret "0" as 
> "somewhere useful"?

Why is the kernel being loaded at 0?

>
> On Sat, Sep 22, 2018 at 10:47 PM ron minnich  wrote:
>>
>> shouldn't we fix the riscv kernel build process? it's producing bad elf 
>> files?
>>
>> On Sat, Sep 22, 2018 at 4:40 PM Jonathan Neuschäfer  
>> wrote:
>>>
>>> Hi,
>>>
>>> we've discussed this briefly at OSFC: Linux's ELF file (vmlinux)
>>> currently has segments starting at 0x0 (if you look at the physical
>>> address field) and an entry point at 0xffe0:
>>>
>>> > $ readelf -l vmlinux
>>> >
>>> > Elf file type is EXEC (Executable file)
>>> > Entry point 0xffe0
>>> > There are 3 program headers, starting at offset 64
>>> >
>>> > Program Headers:
>>> >   Type   Offset VirtAddr   PhysAddr
>>> >  FileSizMemSiz  Flags  Align
>>> >   LOAD   0x1000 0xffe0 0x
>>> >  0xffce 0xffce  R E0x1000
>>> >   LOAD   0x00011000 0xffe1 0x0001
>>> >  0x002cda3c 0x002cda3c  RWE0x1000
>>> >   NOTE   0x002dea00 0xffe0002dda00 0x002dda00
>>> >  0x003c 0x003c  R  0x4
>>> >
>>> >  Section to Segment mapping:
>>> >   Segment Sections...
>>> >00 .init.text
>>> >01 .init.data .exit.text .data..percpu .text .softirqentry.text 
>>> > .rodata __param __modver .srodata .data __bug_table .sdata .bss 
>>> > __ex_table .notes
>>> >02 .notes
>>>
>>>
>>> coreboot's SELF loader rightly points out that 0x0 is not in RAM:
>>>
>>> > Loading segment from ROM address 0x200287b8
>>> >   code (compression=0)
>>> >   New segment dstaddr 0x0 memsize 0xffce srcaddr 0x2002880c filesize 
>>> > 0xffce
>>> > Loading segment from ROM address 0x200287d4
>>> >   code (compression=0)
>>> >   New segment dstaddr 0x1 memsize 0x2cda3c srcaddr 0x200387da 
>>> > filesize 0x2cda3c
>>> > Loading segment from ROM address 0x200287f0
>>> >   Entry Point 0xffe0
>>> > SELF Payload doesn't target RAM:
>>> > Failed Segment: 0x0, 65486 bytes
>>> >  0. 8000-80011fff: RAMSTAGE
>>> >  1. 80012000-8003: RAM
>>> >  2. 8004-80044fff: RAMSTAGE
>>> >  3. 80045000-fffdbfff: RAM
>>> >  4. fffdc000-: CONFIGURATION TABLES
>>> >  5. 0001-00027fff: RAM
>>> > Payload not loaded.
>>>
>>>
>>> How should we solve this?
>>>
>>> One option I see is to keep CONFIG_PAYLOAD_ELF as is, and add quirks to
>>> CONFIG_PAYLOAD_LINUX.
>>>
>>>
>>> Jonathan
>
> --
> coreboot mailing list: coreboot@coreboot.org
> https://mail.coreboot.org/mailman/listinfo/coreboot

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

Re: [coreboot] MRC in coreboot

[Aaron Durbin via coreboot]

On Wed, Sep 5, 2018 at 8:06 AM Antony AbeePrakash X V
 wrote:
>
> Hi,
>
>
>
> We are developing coreboot for Apollo lake custom board.  MRC training data 
> save is enabled in FSP using Binary configuration tool.
>
>
>
> But we are getting logs like,
>
>
>
> No MRC cache found.
>
> MRC SeCUmaSize memory size from SeC ... 0
>
> MRC Parameters not valid. Status is Success
>
> MRC:CpuMemoryTest Successful!
>
> Saving MRC data using CSE through HECI interface

I have never seen this path used in coreboot. This line above is
saying CSE is responsible for saving and retrieving training data. In
coreboot we use the main processor to save and restore. I suggest
reading over the UPD parameters and ensure they match with our typical
use cases. BCT tool enabling 'training data save' sounds like it's
enabling CSE path.

>
> Try to find MRC training data HOB.
>
> No MRC training data found, perform data save via HECI.
>
> Saved MRC training data with status (0x8003)
>
>
>
> It seems that MRC data is not found and saved. Also I found that there are 
> options to add MRC file path and mrc.bin in menuconfig. The only option I 
> have is save cached MRC settings.
>
>
>
> What this mrc.bin will do?
>
> How to add the mrc.bin in coreboot?
>
>
>
> Please explain on this.
>
>
>
> Thanks & Regards,
>
> Antony
>
>
>
> L Technology Services Ltd
>
> www.LntTechservices.com
>
> This Email may contain confidential or privileged information for the 
> intended recipient (s). If you are not the intended recipient, please do not 
> use or disseminate the information, notify the sender and delete it from your 
> system.
>
> --
> coreboot mailing list: coreboot@coreboot.org
> https://mail.coreboot.org/mailman/listinfo/coreboot

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

Re: [coreboot] Whether coreboot has restrictions on the bootblock program, cannot use static variables with initial values.

[Aaron Durbin via coreboot]

On Wed, Jul 11, 2018 at 1:16 AM 王翔  wrote:

> I am try to read the code that cache-as-ram of bootblock stage. And found
> that just cleared the memory and did not initialize the data segment code.
>
> So, I want to ask : "Whether coreboot has restrictions on the bootblock
> program, cannot use static variables with initial values."
>
> Looking forward to your reply！Thank you!
>

​coreboot does not currently support static objects that would reside in a
data segment.​ That would require runtime support for loading them into the
proper area. It's doable, but it hasn't been a feature with a very high
priority.


>
> XiangWang
>
> --
> coreboot mailing list: coreboot@coreboot.org
> https://mail.coreboot.org/mailman/listinfo/coreboot
-- 
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] FSP 2.0 headers in coreboot

[Aaron Durbin via coreboot]

On Tue, May 22, 2018 at 2:25 PM, Youness Alaoui
 wrote:
> On Fri, May 18, 2018 at 2:59 PM, Nico Huber  wrote:
>>
>> I have to admit, I don't like your patch. While it gets the job done,
>> it brings `MemInfoHob.h` and `FspsUpd.h` out of sync, so the state in
>> coreboot as a whole would match neither version.
>>
> Good point. It is a Frankenstein, but it was either that or have
> #ifdefs in the fsp vendorcode itself to determine if attribute X is
> available or not, etc..
>
>>> - or abandon my patch (which means I can never send a working
>>> board-status for the librems without having a dirty tree or a version
>>> commit hash that doesn't match upstream)
>>> - or have the possibility to choose between the two (either via
>>> #ifdefs or via a variants method).
>>
>> If we can't get a new, fitting binary out of Intel, I would prefer this,
>> or, more bluntly, just copy the GitHub version and revert the changes
>> that need the additional UPD.
>>
>> In other words, whatever happens, I think we should have the headers
>> of the latest public release in the tree.
>>
>
> I agree, that's probably the cleanest solution, but I didn't suggest
> it because I figured people would be yelling about removing
> functionality that might need to be re-added eventually if Intel end
> up doing an updated release.
>
>>> - or, if Intel people are reading this right now (or someone here can
>>> poke them directly), have the public release updated so this matter
>>> can be dropped entirely (the public update would need to be released
>>> *very* soon though).
>>
>> Even if you (Purism) poke them about it, that might help. But I would
>> like to see that Google does that too (IMHO, they profit most from the
>> mess). Any of you should have more leverage than the customer of a
>> customer of a customer of a potential customer of Intel has, that I
>> work for ;)
> I know no-one at Intel to poke them about. I'll ask if Todd has
> contacts that might be able to help. I'm hoping that some of the
> people that are working for Intel are following this email thread but
> if they are, they haven't raised their hands. Anyone knows or can
> suggest the name of someone that we might poke ? I'm guessing those
> working for Google who actually received the newer FSP from Intel
> might know who to ask, and since they are the ones that would be
> affected by their code/features being removed if we revert to github
> version of header, it might help put some pressure on this issue (so
> far, I haven't seen any incentive to make them do that).


I thought I said something somewhere -- maybe on a code review?
Anyway, I've been pushing on this from my end. I don't have an answer
yet, though.

>
>>
>>> Should we put this to a vote now, or should we discuss the
>>> possibilities/alternatives some more, if anyone has ideas on how to
>>> tackle this specific issue ?
>>
>> Well, my vote, in order of preference:
>>
>>  1. Poke Intel.
>>  2. Get a verbatim copy of the GitHub headers in (in a way of [least] effort 
>> for
>> the community). Maybe in a month from now? no matter the outcome
>> from 1.
>>
>> Nico
>
> I agree, and I give my 100% vote for that as well. It will be much
> better than an #ifdef mess and would be a good incentive for the
> people from Intel not saying "no, too much hassle to update the file,
> we got nothing to lose anyway if we just ignore this".
> So let's see who can poke who from Intel, let's give a deadline (1 or
> 2 months? if bureaucracy means it will take longer, we might revisit
> if we at least got a confirmation that the issue is being looked at on
> Intel's side), then once deadline is reached, we revert to public
> headers and remove functionality that prevents building (access to
> nonexistent fields in UPD) and in the future, reject patches on gerrit
> for non public blobs.
>
> Thanks!

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

Re: [coreboot] FSP 2.0 headers in coreboot

[Aaron Durbin via coreboot]

On Thu, May 10, 2018 at 5:10 PM, Nico Huber  wrote:
> Ok, I'll try to break this loop here. You are repeating the great bene-
> fits for a user (that I agree to) even if a blob is involved. And I keep
> asking why it should happen on our master branch (I don't see how we
> would take something away by not maintaining everything. Also, I never
> tried to exclude all blobs). It seems somehow we talk past each other.

I've been meaning to respond to your original response, but I haven't
had a lot of time to articulate things. You've brought this up
numerous times; it sounds like you care what is in the master branch.
But maybe not any other branches? And what is the threshold for being
in master branch? And what audience is the master branch for? I'm
trying to envision what the development and eventual result will be.

You have been focusing on FSP talking about maintaining it, etc, but I
don't think that maintainership is falling on people
disproportionately any more than other parts of the tree. I do find it
a bit ironic that you were te one using FSP for some of your work.

As for the github fsp proper, the license in the headers is weird, as
Youness pointed out. But in addition to that, it says IOTG Kabylake H
as a release. It doesn't say anything beyond that from a support
standpoint. Empirically it may work, but so does the FSP generated by
Chrome OS. As I'm sure you know assets can be extracted from recovery
images for those FSPs. What's the bar for picking one over the other?
I don't believe either can be submitted into coreboot.org blobs repo?
Or did I miss where that was concluded?

Anyway, just lots of questions -- not many statements. I'm trying to
understand the distinction when I don't see many differences of a
situation I think most people would agree is unfortunate.

> On 10.05.2018 23:26, Julius Werner wrote:
>>> You really seem to miss the point of free software.
>>
>> Okay, now this is starting to get personal again, let's please not go
>> there. You too have been among those who spoke out against that in that
>> derailment thread recently. It's insulting to insinuate that some of us
>> don't understand or don't care about free software just because we're
>> working for a big company. You also don't need to educate me about the
>> spirit of the GPL or the fundamental travesty of jumping back and forth
>> between blobs and GPL code a dozen times during a single boot and calling
>> it okay because it's "technically not linking". I am aware of these things
>> and I'm not happy about them either. But there have been blobs in most
>> boards that were added to this project since before I started working on it
>> and there will keep being blobs for the foreseeable future. You are not
>> going to convince Intel to open-source their FSP by yelling at fellow
>> coreboot developers about it. It's the reality we live in. This discussion
>> started (as I understood it) about how we can make the blob situation we
>> *are* living with a little better, so let's keep it focused on that.
>>
>>> As long as everybody
>>> adheres to the copyleft, you can do things on your own. If a blob ends
>>> up being only useful for a single board, ok. Should somebody be able to
>>> sell his product with it, sure. But why should the community maintain
>>> that shit (partially on the shoulders of volunteers) if it doesn't pro-
>>> vide what free software provides?
>>
>> "That shit" allows people to build custom firmware for the hardware that
>> they bought, which I think is a very important and worthwhile benefit on
>> its own. For Chromebooks, a whole little ecosystem of custom ROMs and build
>> instructions has developed around this. Do you want to take that away from
>> everyone just because some of the blobs may be mainboard specific? (And
>> again, as far as I am aware most blobs aren't really tied to a specific
>> mainboard, they're just SoC support which may or may not have been written
>> to include whatever peripheral support a particular mainboard needs. You
>> are really just complaining that peripheral support which the existing
>> mainboards didn't need is not implemented yet, which is a situation that
>> can happen just as well on a fully blob-free board.)
>>
>> It's not just free software when you can port it to a completely new
>> mainboard, in the same way that the coreboot core code is still free
>> software even though you can't automatically port it to any new chipset.
>> You can still add features or make changes to customize behavior for an
>> existing board. You can make it boot your own operating system with custom
>> calling convention, add some code signing or measuring framework, or make
>> it play the Jeopardy melody on the speaker while it's booting. That, too,
>> is a benefit of free software.
>>

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

Re: [coreboot] PC Engines apu2 boot regression

[Aaron Durbin via coreboot]

On Sat, May 5, 2018 at 4:26 PM, Kyösti Mälkki  wrote:
> On Sun, May 6, 2018 at 12:17 AM, Aaron Durbin  wrote:
>>> I find it particularly hard to be civil on your first question, so
>>> trying with sarcasm instead. After 5000 or so development hours and
>>> direct support from AMD, is the boot sequence for soc/stoneyridge
>>> prototypes equally bad, that is, AP CPUs execute through bootblock and
>>> verstage?
>>
>> They currently jump to where they are told at the moment. See
>> bootblock_c_entry() in src/soc/amd/stoneyridge/bootblock/bootblock.c.
>> There is no running through multiple stages within coreboot.
>
> I think CAR_GLOBAL equally fails with soc/amd/stoneyridge if you had
> SoC with multiple compute units where MTRRs are not shared, thus setup
> becomes asymmetric between some cores. Marshall's experiments support
> this happens.

Agreed. That's a concern w/ running APs through all the stages and not
having a symmetric view of the address space.

>
>> I think you are right that guarding things w/ boot_cpu() would work.
>> Is CONFIG_SQUELCH_EARLY_SMP set for all those types of boards? Or do
>> we have a weird mix? Or should we have a Kconfig that says 'CAR' is
>> not symmetric across cpus thus can't be used?
>
> I would rather grant AP CPUs access to CAR_GLOBALs by manipulating the
> MTRR setup.
>
> Kyösti

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

Re: [coreboot] FSP 2.0 headers in coreboot

[Aaron Durbin via coreboot]

On Sat, May 5, 2018 at 5:36 AM, Nico Huber <nic...@gmx.de> wrote:
> On 04.05.2018 23:41, Aaron Durbin via coreboot wrote:
>> On Fri, May 4, 2018 at 3:20 PM, Youness Alaoui
>> <kakar...@kakaroto.homelinux.net> wrote:
>>> Hi,
>>>
>>> I've just pushed a commit for review on gerrit
>>> (https://review.coreboot.org/#/c/coreboot/+/26108/) and I'm hoping to
>>> open the discussion here on whether the public coreboot code should
>>> have the FSP headers that match the public FSP headers or if they
>>> should match the 'google fsp' headers.
>
> I tried myself before [1] and ran against a wall of lies and broken
> promises.
>
> Roughly:
>
>   - July to September/October: I warned Intel about the situation
> over all available channels (Gerrit, different corporate support
> channels, wrote to Vincent who uploaded the first Kabylake FSP
> to GitHub, several laments about the situation on this mailing
> list I guess).
>   - After the first Kaby Lake FSP drop on GitHub, Intel commented
> on Gerrit that the headers there are outdated and internal ones
> have to be used.
>   - December 11th, Intel commented on Gerrit that everything is sorted
> out.
>   - December 13th, Intel painted Kabylake FSP "Gold" with 6 months
> outdated UPDs.
>
>>>
>>> My understanding of the situation is that chromebooks ship with a
>>> google-modified FSP image and the fsp headers in coreboot have been
>>> added by google employees even before the FSP was officially made
>>> public by Intel. I also somewhat understood that the fsp headers in
>>> coreboot would not be updated to match the public release because it
>>> would break everyone building coreboot for their chromebooks or
>>> something like that.
>>
>> They aren't modified necessarily. It's more of different views on the
>> same timeline of a development. Granted, the releases are definitely
>> not coordinated. I'm not even sure how/who releases the github
>> blobs/headers on Intel's side.
>
> I have more a feeling that different branches exist.
>
>>
>>>
>>> I'm a bit tired of always having that commit that fixes the header
>>> applied locally in all my branches, and I think that it makes much
>>> more sense for coreboot to have the fsp headers that match the public
>>> release and for the google/chromebook coreboot repository to have the
>>> "non-standard header" committed to it instead.
>>> Worst case scenario, we could add #ifdefs to determine what the
>>> structure contents should be depending on the target platform.
>>>
>>> Maybe everyone will say "of course, that makes sense" or maybe
>>> everyone will say "nope, I disagree", but hopefully we can have the
>>> discussion here (or on gerrit) and decide how to handle this use case.
>>> Note: I only pushed for skylake/kabylake, but apollolake/canonlake are
>>> probably also affected by this mismatch of headers.
>>
>> I think we should have both that can be selected through a Kconfig
>> such that we can bind to the headers correctly. We already had to do
>> that for edk2 issues as well. I can't think of better alternative at
>> the moment that supports both.
>
> You can not just switch headers. As Youness pointed out in his commit,
> UPDs used by coreboot are missing in the public release. We'd clutter
> up the tree with #ifdefs. And once that started, I'm sure, somebody
> will use that as excuse to practice it further. OTOH, we could just
> revert the past 10 months of soc/intel/. The major stakeholders had been
> warned early enough. If somebody gets that through Jenkins, I'll +2.

The technical challenges of managing different sets of headers doesn't
seem too hard. Things can be isolated fairly easily w.r.t. to the
field mismatches. Code can be co-located to handle such scenarios and
keep it isolated.

>
> Um, a little more serious: I believe the only solution is to enforce
> some sane rules about code changes that depend on blob headers and
> blobbed platforms in general, e.g. (just a draft; but I wouldn't mind
> if we take it verbatim):
>
> (meaning of *shall*, *should* and *recommended* as specified in [2],
> "changes" refer to new commits for the coreboot master branch)
>
>0. Generally:
>  All platforms should be blob-free.
>
>  All blobs should be redistributable.
>
>  Providers of blobs should sign them and take responsibility
>  that the signed blobs were unaltered after compilation (e.g.
>  do not contain malware). It is *recommended

Re: [coreboot] PC Engines apu2 boot regression

[Aaron Durbin via coreboot]

On Fri, May 4, 2018 at 8:49 PM, Kyösti Mälkki  wrote:
> On Fri, May 4, 2018 at 8:22 PM, Aaron Durbin  wrote:
>> On Fri, May 4, 2018 at 11:16 AM, Kyösti Mälkki  
>> wrote:
>>> On Fri, May 4, 2018 at 7:19 PM, Kyösti Mälkki  
>>> wrote:
 On Fri, May 4, 2018 at 6:37 PM, Aaron Durbin  wrote:
>>
>> Any idea what can be result of such weird behavior?
>
>>>
>>> My current guess is AP CPUs do not see initialised memory for
>>> _car_region_start .. _end. That region is set up using fixed MTRRs in
>>> low memory and probably not synced between cores so early in romstage.
>>>
>>
>> Ugh.  Why do we allow the APs to run through all these stages? Is this
>> for parallel node memory training? Can we ring fence where the APs
>> actually run better?
>>
>
> I have to check closer, but for apu2 this would be in AMD_INIT_EARLY
> already, so AP CPUs run way before (the only) memory controller is
> configured. I believe there is microcode updates and some CPU
> registers that are also synced during AMD_INIT_EARLY. So it is doing
> more than just bringing an idle AP task engine.
>
> I find it particularly hard to be civil on your first question, so
> trying with sarcasm instead. After 5000 or so development hours and
> direct support from AMD, is the boot sequence for soc/stoneyridge
> prototypes equally bad, that is, AP CPUs execute through bootblock and
> verstage?

They currently jump to where they are told at the moment. See
bootblock_c_entry() in src/soc/amd/stoneyridge/bootblock/bootblock.c.
There is no running through multiple stages within coreboot.

I think you are right that guarding things w/ boot_cpu() would work.
Is CONFIG_SQUELCH_EARLY_SMP set for all those types of boards? Or do
we have a weird mix? Or should we have a Kconfig that says 'CAR' is
not symmetric across cpus thus can't be used?

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

Re: [coreboot] FSP 2.0 headers in coreboot

[Aaron Durbin via coreboot]

On Fri, May 4, 2018 at 3:20 PM, Youness Alaoui
 wrote:
> Hi,
>
> I've just pushed a commit for review on gerrit
> (https://review.coreboot.org/#/c/coreboot/+/26108/) and I'm hoping to
> open the discussion here on whether the public coreboot code should
> have the FSP headers that match the public FSP headers or if they
> should match the 'google fsp' headers.
>
> My understanding of the situation is that chromebooks ship with a
> google-modified FSP image and the fsp headers in coreboot have been
> added by google employees even before the FSP was officially made
> public by Intel. I also somewhat understood that the fsp headers in
> coreboot would not be updated to match the public release because it
> would break everyone building coreboot for their chromebooks or
> something like that.

They aren't modified necessarily. It's more of different views on the
same timeline of a development. Granted, the releases are definitely
not coordinated. I'm not even sure how/who releases the github
blobs/headers on Intel's side.

>
> I'm a bit tired of always having that commit that fixes the header
> applied locally in all my branches, and I think that it makes much
> more sense for coreboot to have the fsp headers that match the public
> release and for the google/chromebook coreboot repository to have the
> "non-standard header" committed to it instead.
> Worst case scenario, we could add #ifdefs to determine what the
> structure contents should be depending on the target platform.
>
> Maybe everyone will say "of course, that makes sense" or maybe
> everyone will say "nope, I disagree", but hopefully we can have the
> discussion here (or on gerrit) and decide how to handle this use case.
> Note: I only pushed for skylake/kabylake, but apollolake/canonlake are
> probably also affected by this mismatch of headers.

I think we should have both that can be selected through a Kconfig
such that we can bind to the headers correctly. We already had to do
that for edk2 issues as well. I can't think of better alternative at
the moment that supports both.

>
> Thanks,
> Youness.
>
> --
> coreboot mailing list: coreboot@coreboot.org
> https://mail.coreboot.org/mailman/listinfo/coreboot

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

Re: [coreboot] PC Engines apu2 boot regression

[Aaron Durbin via coreboot]

On Fri, May 4, 2018 at 11:16 AM, Kyösti Mälkki  wrote:
> On Fri, May 4, 2018 at 7:19 PM, Kyösti Mälkki  wrote:
>> On Fri, May 4, 2018 at 6:37 PM, Aaron Durbin  wrote:

 Any idea what can be result of such weird behavior?
>>>
>
> My current guess is AP CPUs do not see initialised memory for
> _car_region_start .. _end. That region is set up using fixed MTRRs in
> low memory and probably not synced between cores so early in romstage.
>

Ugh.  Why do we allow the APs to run through all these stages? Is this
for parallel node memory training? Can we ring fence where the APs
actually run better?

>
> diff --git a/src/console/init.c b/src/console/init.c
> index 8f71b09..4731e7e 100644
> --- a/src/console/init.c
> +++ b/src/console/init.c
> @@ -35,7 +35,7 @@ static int console_loglevel = 
> CONFIG_DEFAULT_CONSOLE_LOGLEVEL;
>
>  static inline int get_log_level(void)
>  {
> -   if (car_get_var(console_inited) == 0)
> +   if (boot_cpu() && car_get_var(console_inited) == 0)
> return -1;
> if (CONSOLE_LEVEL_CONST)
> return get_console_loglevel();
>
> Kyösti

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

Re: [coreboot] DDR1 K8 boot broken too (was: Re: PC Engines apu2 boot regression)

[Aaron Durbin via coreboot]

On Fri, May 4, 2018 at 10:01 AM, Jonathan A. Kollasch
 wrote:
> On Fri, May 04, 2018 at 05:23:40PM +0200, Piotr Król wrote:
>> Hi Aaron,
>> I tried to boot PC Engines apu2 on recent master branch and discovered
>> that it not boot. Bisection points to:
>>
>> 60320182d011 console: only allow console messages after initialization
>>
>> It is hard to believe that this change cause AGESA reset loop, but I
>> checked 3 times. After applying above commit I end up with loop:
>
> I see a similar romstage boot loop starting with this commit on
> msi/ms7135 (K8N Neo3), a DDR1 K8 board.

I think it's the AMD boards and their weird config. CAR_GLOBAL is
used, but apparently these boards fail if accessing CAR_GLOBAL at the
wrong time? If you have log diffs w/ and w/o the patch it'd help with
root cause.

>
> Jonathan Kollasch
>
> --
> coreboot mailing list: coreboot@coreboot.org
> https://mail.coreboot.org/mailman/listinfo/coreboot

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

Re: [coreboot] PC Engines apu2 boot regression

[Aaron Durbin via coreboot]

On Fri, May 4, 2018 at 9:23 AM, Piotr Król  wrote:
> Hi Aaron,
> I tried to boot PC Engines apu2 on recent master branch and discovered
> that it not boot. Bisection points to:
>
> 60320182d011 console: only allow console messages after initialization
>
> It is hard to believe that this change cause AGESA reset loop, but I
> checked 3 times. After applying above commit I end up with loop:
>
> coreboot-4.7-441-g60320182d0 Fri Mar  2 15:22:24 UTC 2018 romstage
> starting...
> BSP Family_Model: 00730f01
> cpu_init_detectedx = 
> agesawrapper_amdinitreset() entry
> CBFS: 'Master Header Locator' located CBFS at [200:7fffc0)
> CBFS: Locating 'AGESA'
> CBFS: Found @ offset 5ffdc0 size 7b0e0
> CBFS: 'Master Header Locator' located CBFS at [200:7fffc0)
> CBFS: Locating 'AGESA'
> CBFS: Found @ offset 5ffdc0 size 7b0e0
> Fch OEM config in INIT RESET Done
>
> Any idea what can be result of such weird behavior?

I think it's because we still have boards that utilize CAR_GLOBAL, but
don't handle migration of CAR globals. Those two things combined
really makes for situations that just don't work and ramstage loading
is just lucky to work on those platforms. I was originally thinking
this patch would work, but I don't think that's the case because when
I build apu2 CONFIG_EARLY_CBMEM_INIT is already set. If you revert
that patch what does your log look like? We could be recursively
entering into car_get_var_ptr() through the printk() path, but that
would require things not marked as CAR_GLOBAL being passed to that
function. There is one way to fix all of these scenarios: remove CAR
migration by transitioning everyone to postcar stub between romstage
and ramstage. That's a lot of work, though. We can try and debug
further because I'm not clear why things aren't working.

diff --git a/src/console/init.c b/src/console/init.c
index 8f71b09881..b5c2f792fa 100644
--- a/src/console/init.c
+++ b/src/console/init.c
@@ -35,7 +35,7 @@ static int console_loglevel = CONFIG_DEFAULT_CONSOLE_LOGLEVEL;

 static inline int get_log_level(void)
 {
-   if (car_get_var(console_inited) == 0)
+   if (IS_ENABLED(CONFIG_EARLY_CBMEM_INIT) && !car_get_var(console_inited))
return -1;
if (CONSOLE_LEVEL_CONST)
return get_console_loglevel();
@@ -78,7 +78,8 @@ asmlinkage void console_init(void)

console_hw_init();

-   car_set_var(console_inited, 1);
+   if (IS_ENABLED(CONFIG_EARLY_CBMEM_INIT))
+   car_set_var(console_inited, 1);

printk(BIOS_NOTICE, "\n\ncoreboot-%s%s %s " ENV_STRING " starting...\n",
   coreboot_version, coreboot_extra_version, coreboot_build);



>
> Best Regards,
> --
> Piotr Król
> Embedded Systems Consultant
> https://3mdeb.com | @3mdeb_com
>

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

Re: [coreboot] Why do we have FSP-S

[Aaron Durbin via coreboot]

On Mon, Apr 30, 2018 at 9:46 PM, taii...@gmx.com  wrote:
> Like I have said I believe the gradual encroachment of blobs and corporate
> control will end up leaving coreboot dead in the water and eventually even

Can you articulate what 'corporate control' is impacting coreboot? I'm
curious as to what particular things have transpired that impacted the
platforms you care about.

As for Google, we obviously heavily rely on coreboot for shipping
products. coreboot is very much an enormous piece of the foundation we
use for shipping millions of products. Some of those products are blob
free while others aren't because of the vendors' decisions. That said,
the investment put into coreboot is not insignificant, and I don't
envision Google abandoning coreboot any time soon.

That said, what are your thoughts for rectifying the problems you
perceive? Is it to have all corporate contributors leave the project?
Fork the project? Only support very old systems or the TALOS 2? How
does that jive with companies that want to use coreboot in shipping
modern platforms?

> code not related to platform initiation will be blobbed, coreboot will be an
> open source project only in theory not in reality - the only boards that
> work with coreboot v8 or w/e will be unobtainable development boards
> requiring not just blobs but an NDA and special connections to obtain.
>
> Lets say 10 years from now, will there be a coreboot? I doubt it - you can't
> sustain a project like this without passion and people who believe in
> freedom not fake "freedom" (ie: a certain company who entertains the idea
> that x86 can still be free with some kind of magic)
>
> Then again in a decade you probably won't even be able to run the programs
> you want on a computer without approval and submission of a scanned passport
> and CS masters degree let alone firmware - look on the list today and you
> will see people who entertain the concept that computing freedom is simply
> not "safe" for those not blessed and tell me that isn't the future?
>
> On 04/30/2018 11:11 PM, Zoran Stojsavljevic wrote:> >> OpenPOWER's actually
> shipping open POWER9 systems right now >> with source code. Why not go down
> that route?
> Here here! - freedom today not tomorrow!
>
>> > The only obstacle to this one is the price. If the price goes 2x down, >
>> > it would be the perfect technical solution. :-) >If you assemble your own
>> > TALOS 2 it costs less than a proprietary intel/AMD platform with equivilant
>> > performance and features, and I consider this a miracle - it isn't meant to
>> > compete price wise with a bargain basement x86 dell "server" or what not.
>
> The idea too is that you will have it for quite longer than a normal PC, as
> it is very fast, high quality (assembled in usa!), and you will continue
> receiving security updates for much longer than with most boards.
> If someone is very broke they can always get one of the cheaper
> coreboot-libre boards which still function and are easily available.
>
> --
> coreboot mailing list: coreboot@coreboot.org
> https://mail.coreboot.org/mailman/listinfo/coreboot

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

Re: [coreboot] Why do we have FSP-S

[Aaron Durbin via coreboot]

On Sat, Apr 28, 2018 at 7:16 AM, Nico Huber  wrote:
> Hello coreboot folks, hello Intel and Google coreboot developers,
>
> back on Tuesday, some of us discovered a commit on gerrit [1] that
> implements (another) foreign interface inside coreboot. Discussing

It's more of a bridge into coreboot's infrastructure, imo.

> it didn't go well and I kind of bursted. I feel sorry about that now
> (especially because I got too personal).
>
> One of the causes for this clash definitely was that things apparently
> were discussed before but not with coreboot (i.e. this coreboot mailing
> list). So I'll try to take the general discussion here, but I've to
> start some years back, where you lost me.
>
> Some questions (that I believe have to be answered) right away. I'll
> argue about why later, so these won't get lost (in an already too long
> email):
>
>
> TLDR;
> For Google:
> You kind of introduced blobs in coreboot (with Sandy Bridge) which was
> a simple jump-in-jump-out thing and kind of accepted. The argument was
> that the things it does aren't documented by Intel anymore, AFAIR. But
> with Broadwell suddenly another blob emerged (in ramstage) some
> `refcode.elf` AIUI. It turned out, later, that this blob (also) does
> things that were open source for Haswell (and would work verbatim on
> Broadwell). It seems to play a role comparable to FSP-S.
>   o What's the story behind this blob?
>   o Why was it introduced?
>   o Was there more than IP concerns? Time to market pressure maybe?

Saying it's comparable to FSP-S is apt. The story is, like most
things, that it has specific things that are not architectural that
Intel thinks they need to be secret. Typical settings are related to
power management. When needing to be competitive in the laptop space
power is a big concern. Time to market may have been a thing too, but
I don't recall all the specifics. I'll get to it later in the
response, but there are temporal components to decisions and/or how
things change over time that are not within Google's control when
working on a particular platform.

>
> For Intel:
> It's hard for me to understand what parts of your silicon init you can
> open-source and what parts you can't. I know your BIOS Writer's Guides
> (BWG) / BIOS Spec, and many things therein are often published by you
> or Google. Please tell us.
>   o Are the things that you can *not* open-source documented at all?
>   o if so, in these BWG documents?
>   o Or is everything in these documents generally publishable (with
> some NDA clearance, ofc)?
>   o For a configuration of FSP-S that just runs the bare minimum to
> boot (e.g. skips questionable add-ons like TXT, SGX), is there
> anything not publishable?
>   o Can anything be done to get more documentation published? e.g.
> for things that are done in open source (or were done in the past)
> but are not publicly documented.

Based on my working history a lot of BWGs and/or specs are usually
wrong. They don't always contain the right information, but generally
contain quite a few things that are wrong where you second guess
everything in the docs. This should sound familiar: the 'reference
code' is the documentation. Most docs are not in sync with reality or
necessarily with how the silicon was actually designed. It's my belief
when there wasn't as much change from version to version, the
copy-pasting in docs just kinda worked. But as things have been
getting more complicated and incorporating more 'features' the
documentation has not been keeping up.

>
>
> So why ask? The original introduction of blobs in coreboot in general
> happened with the argument that the things it does (e.g. memory init)
> are not documented anymore by Intel. This is a valid argument because
> the lack of documentation makes it harder to write clean code. I also
> believe it's true (that no documentation exists) because I've seen a
> previous BWG that already referred a lot to the reference code.
>
> But, AFAIR, the introduction of blobs in coreboot's *ramstage* was never
> discussed. The blobs I've seen so far all did things that were already
> open source for earlier platforms. Plus they are twisting coreboot into
> something that isn't coreboot anymore. Architectural changes happen in
> chipset specific code instead of moving coreboot as a whole (after an
> open discussion). Also, most of the positive aspects about coreboot are
> lost.

Purely business commentary: In order to develop a competitive laptop
on recent hardware one needs to include the features that consumers
expect. Intel also ties those features inside of FSP, but FSP has a
responsibility problem. It has traditionally attempted to do things it
should not. FSP should be a library of sorts, but it has things in
there it shouldn't. I mentioned some of this on the CL itself about
our usage of SkipMpInit. It trying to take over resources that it
shouldn't (among other things).

What architectural changes are you referring to? 

Re: [coreboot] How is our SPI API supposed to work?

[Aaron Durbin via coreboot]

On Thu, Apr 19, 2018 at 4:51 PM, Julius Werner  wrote:
>> How does it mean two different things? The pairing of a controller and
>> device where a full duplex operation is needed but the controller
>> doesn't support things should indeed fail. I do not undertand how
>> xfer() means two different things. Whenever pairing hardware together
>> one needs to validate that things work when married.
>
> spi_xfer_two_vectors() takes a call like this:
>
>struct spi_op vectors[2] = { {.dout = out, .din = NULL, ...}, {.dout =
> NULL, .din = in, ...};
>spi_xfer_vector(..., vectors, 2);
>
> and turns it into
>
>spi_xfer(..., dout, ..., din, ...);
>
> Those are two different things. The former means "first transfer dout on
> MOSI and ignore MISO, then read in din on MISO and send zeroes or whatever
> out on MOSI". The latter means "do a full-duplex transaction where you read
> from MISO into din and write dout out on MOSI at the same time". If you did
> the latter call on a controller supporting full-duplex it wouldn't actually
> be a correct SPI flash transaction. But all the controllers that use
> spi_xfer_two_vectors() have implemetations of xfer() that don't actually do
> the thing I just described... instead they do the "first out, then in"
> behavior even though that's normally not what spi_xfer(..., dout, ..., din,
> ...) means. I think those implementations of xfer() are wrong and violating
> the API. If they were corrected, spi_xfer_two_vectors() wouldn't make sense
> the way it works right now.

I said it was helper to fuse the ops. Sure we can invert the code paths.

>
>> OK. It's just moving code around.
>
> Yeah, I just want to shuffle code around. Nothing is broken right now, it's
> just working in a confusing and inconsistent way. We should have an API
> where the callbacks share the same semantics across all implementations
> (and also document those semantics more clearly).

I can send some CLs out.

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

Re: [coreboot] How is our SPI API supposed to work?

[Aaron Durbin via coreboot]

On Thu, Apr 19, 2018 at 4:06 PM, Julius Werner  wrote:
>> > My question is basically what happens when bytesout and bytesin are both
>> > non-zero. My previous understanding was always that the SPI controller
>
>> It's up to the spi controller itself. They should support full duplex,
>> if possible.
>
> And if not? The problem is that right now xfer() means two different things
> depending on which controller implementation you talk to. Isn't that a
> pretty bad situation? The point of having an API is that you can program
> something without having to care (too much) what implements it on the other
> side. The behavior of the same call shouldn't change based on the
> implementation, other than aborting for requests that the implementation
> cannot support.

How does it mean two different things? The pairing of a controller and
device where a full duplex operation is needed but the controller
doesn't support things should indeed fail. I do not undertand how
xfer() means two different things. Whenever pairing hardware together
one needs to validate that things work when married.

>
> I think if we want to allow full-duplex, then any controllers that don't
> support full-duplex should error out if their xfer() is called with two
> buffers. They shouldn't just do something different than what the
> controllers which support full-duplex would do if they were called the same
> way. If the caller wants to transfer things one after the other, it needs
> to use xfer_vector() with two vectors or do two separate xfer() calls.

Sure.

>
>> cmd *then* response behavior. As you noted you'd have to eat the cmd
>> bytes in the receive buffer. The issue is that we are dealing with 2
>> different types of spi *flash* controllers:
>> 1. generic spi controller that can do any normal spi thing
>> 2. spi flash controllers on x86 systems. The ones on x86 systems are
>> not a normal spi controller, and they can't really be treated like
>> one.
>
>> The spi flash drivers previously made assumptions around #2 in that
>> they would/could send din/dout in a full duplex manner assuming #2
>> semantics -- basically very not normal spi.
>
> Right. So I think the way spi_flash.c is written right now looks good, if
> we want to consider transfers full-duplex. do_spi_flash_cmd() correctly
> builds a vector with two separate transactions, one out and one in. My
> problem is just that the Intel controllers then implement xfer_vector()
> with spi_xfer_two_vectors() which just merges it back together into a
> single xfer() call, with different semantics than what the other
> (full-duplex-supporting) controllers use for xfer(). That just seems
> wrong... xfer() is an external part of the SPI controller API so it should
> have the same semantics for all controllers. If the Intel flash controllers
> want to do something special with what do_spi_flash_cmd() gives them, they
> should have their own custom implementation of xfer_vector() that doesn't
> call xfer() and instead calls something internal to them which implements
> this behavior, while xfer() should conform to the standard API (as best as
> it can).
>
>> mediatek does that for reasons I'm not aware of.
>
> I think they just copied off the wrong implementation when writing that
> driver and I didn't notice during review. Like I'm saying, I think the
> current situation is very confusing, especially to those vendors who see it
> for the first time. The MediaTek controller is definitely capable of
> full-duplex AFAIK, the driver is written in a way that explicitly avoids
> being full-duplex right now.
>
>> That's just to combine the two ops spi flash cmds follow. Those
>> helpers are there only for that purpose. If you look at the spi flash
>> API buffers are passed in for getting data back, etc. There's no where
>> to eat the setup cmd pieces w/o sending two ops down to the controller
>> aside from realloc'ing a buffer with the larger size then memcpy()'ing
>> back into the original buffer. Otherwise you are putting the burden on
>> the higher layer callers to somehow know they need to pad their
>> buffers. Also, the x86 spi flash controllers need all the info at once
>> as a fused op.
>
> Right, I get that those x86 flash controllers need to treat this specially.
> I just think their xfer_vector() implementation shouldn't go back and call
> xfer() like that (in a way that xfer() is normally not meant to work).
> Their xfer_vector() should do the operation directly, and their xfer()
> should be a different implementation that follows the normal API for xfer()
> as best as it can (or if they can't do that at all they just shouldn't
> provide an xfer() callback).

OK. It's just moving code around.

>
>> One could never connect a generic spi device to an x86 spi *flash*
>> controller.  That's similarly why is the special function
>> flash_probe() in spi_ctrlr. It's to bypass the spi driver probing
>> because it's not possible to probe the way the drivers are written.
>

Re: [coreboot] How is our SPI API supposed to work?

[Aaron Durbin via coreboot]

On Wed, Apr 18, 2018 at 8:46 PM, Julius Werner  wrote:
> I was trying to understand how to best implement the coreboot SPI API for a
> new SoC, and as I was reading into it I got increasingly confused. This has
> changed a bit last year (with the addition of struct spi_ctrlr), and I
> don't think it was fully consistent before that across all implementations
> either. Basically, we've always had the following base transfer prototype
> (used to be spi_xfer(), now a callback in struct spi_ctrlr):
>
>  int (*xfer)(const struct spi_slave *slave, const void *dout, size_t
> bytesout, void *din, size_t bytesin);
>
> There's also a more recent addition that can handle multiple transfer
> "vectors" at once, and the code will fall back to the basic xfer() callback
> if a controller doesn't implement this:
>
>  struct spi_op {
>  const void *dout;
>  size_t bytesout;
>  void *din;
>  size_t bytesin;
>  enum spi_op_status status;
>  };
>  int (*xfer_vector)(const struct spi_slave *slave, struct spi_op
> vectors[], size_t count);
>
> My question is basically what happens when bytesout and bytesin are both
> non-zero. My previous understanding was always that the SPI controller

It's up to the spi controller itself. They should support full duplex,
if possible.

> should then operate in full-duplex mode, clocking out bytes from the dout
> array while reading bytes into the din array in the same cycle. AFAIK no
> driver in coreboot actually wants to use the controller this way, but it is
> a legitimate way to operate a SPI bus and it's not impossible that we may
> one day have a need for it. The Rockchip, Samsung and (I believe, those are
> a little harder to read) Nvidia SoC drivers are implemented this way. There
> is also the following comment (and associated implemented code) in
> spi_flash.c:do_spi_flash_cmd() which makes me think that this understanding
> was at least at some point the intended one:
>
>  /*
>   * SPI flash requires command-response kind of behavior. Thus, two
>   * separate SPI vectors are required -- first to transmit dout and
> other
>   * to receive in din. If some specialized SPI flash controllers
>   * (e.g. x86) can perform both command and response together, it
> should
>   * be handled at SPI flash controller driver level.
>   */
>   <...array with two spi_op structs, one having only din and one
> only dout...>

cmd *then* response behavior. As you noted you'd have to eat the cmd
bytes in the receive buffer. The issue is that we are dealing with 2
different types of spi *flash* controllers:
1. generic spi controller that can do any normal spi thing
2. spi flash controllers on x86 systems. The ones on x86 systems are
not a normal spi controller, and they can't really be treated like
one.

The spi flash drivers previously made assumptions around #2 in that
they would/could send din/dout in a full duplex manner assuming #2
semantics -- basically very not normal spi.

>
> However, most/all(?) Intel drivers and the Mediatek one seem to instead
> implement a "one after the other" behavior: the controller first clocks out

x86 spi *flash* controllers do that for sure, but that's to handle
true spi flash operations that are essentially two transactions.
mediatek does that for reasons I'm not aware of.

> the dout array (discarding any bits received on MISO during this time), and
> only once that is done and bytesout clock cycles have passed does it start
> reading bytes into the din array for another bytesin cycles (clocking out
> zeroes or some arbitrary value on MOSI during that time). There's also the
> global spi_xfer_two_vectors() helper used by most of the above-mentioned
> controllers (as their xfer_vector() callback) which combines two struct
> spi_op vectors into a single xfer() call iff the first one only has a dout
> and the second one only a din.

That's just to combine the two ops spi flash cmds follow. Those
helpers are there only for that purpose. If you look at the spi flash
API buffers are passed in for getting data back, etc. There's no where
to eat the setup cmd pieces w/o sending two ops down to the controller
aside from realloc'ing a buffer with the larger size then memcpy()'ing
back into the original buffer. Otherwise you are putting the burden on
the higher layer callers to somehow know they need to pad their
buffers. Also, the x86 spi flash controllers need all the info at once
as a fused op.

>
> Clearly, we shouldn't just let every controller decide on its own how to
> interpret a transfer command, because they mean two very different things.

One could never connect a generic spi device to an x86 spi *flash*
controller.  That's similarly why is the special function
flash_probe() in spi_ctrlr. It's to bypass the spi driver probing
because it's not possible to probe the way the drivers are written.

> An SPI ROM 

Re: [coreboot] Problem with tianocore compilation in coreboot-sdk:1.50

[Aaron Durbin via coreboot]

On Wed, Apr 4, 2018 at 8:40 AM, Piotr Król  wrote:
>
>
> On 04/04/2018 05:31 PM, Aaron Durbin wrote:
>> On Wed, Apr 4, 2018 at 4:55 AM, Piotr Król  wrote:
>>> Hi all,
>>> I can't compile tianocore payload using coreboot-sdk:1.50 and coreboot 4.7.
>>>
>>> VfrUtilityLib.cpp: In member function 'CHAR8*
>>> CVfrStringDB::GetVarStoreNameFormStringId(EFI_STRING_ID)':
>>>
>>> VfrUtilityLib.cpp:3375:26: error: ISO C++ forbids comparison between
>>> pointer and integer [-fpermissive]
>>>if (mStringFileName == '\0' ) {
>>
>> That's just an incorrect check. i.e. bad code. Current master seems to
>> not have that error.
>>
>> https://github.com/tianocore/edk2/blob/master/BaseTools/Source/C/VfrCompile/VfrUtilityLib.cpp
>>
>> FWIW, comparing a char (integer) to a pointer is indeed incorrect.
>
> Agree, but coreboot use old commit from edk2. Is it fine to push vUDK2018?

I guess? I'm not really sure who uses edk2. I guess tianocore payload?
Patrick is on holiday right now, but he would probably the best person
to answer that.

>
> I believe coreboot should stick to edk2 releases not to random commits
> in the tree.
>
> Can anyone tell what tests were made against tianocore payload? There
> are patches in payload/external/tianocore/patches and I'm not sure
> against what hardware those should be validated.
>
> Best Regards,
> --
> Piotr Król
> Embedded Systems Consultant
> http://3mdeb.com | @3mdeb_com

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

Re: [coreboot] Problem with tianocore compilation in coreboot-sdk:1.50

[Aaron Durbin via coreboot]

On Wed, Apr 4, 2018 at 4:55 AM, Piotr Król  wrote:
> Hi all,
> I can't compile tianocore payload using coreboot-sdk:1.50 and coreboot 4.7.
>
> VfrUtilityLib.cpp: In member function 'CHAR8*
> CVfrStringDB::GetVarStoreNameFormStringId(EFI_STRING_ID)':
>
> VfrUtilityLib.cpp:3375:26: error: ISO C++ forbids comparison between
> pointer and integer [-fpermissive]
>if (mStringFileName == '\0' ) {

That's just an incorrect check. i.e. bad code. Current master seems to
not have that error.

https://github.com/tianocore/edk2/blob/master/BaseTools/Source/C/VfrCompile/VfrUtilityLib.cpp

FWIW, comparing a char (integer) to a pointer is indeed incorrect.

>
> I think this is not a single issue. Key problem is that tianocore do not
> support modern toolchains - it requires GCC5. I have no problem when
> compiling with 3mdeb/edk2-docker container which use GCC5.
>
> I can workaround that problem by including payload as elf file, but if
> we have integration we should make sure it works.
>
> I'm not sure how coexistence of 3 toolchain should be solved to serve
> stable build environment. In coreboot-sdk we have 2 toolchains native
> Debian GCC7.2 and coreboot toolchain GCC6.3.
>
> If we want stable build environment for tianocore payload we should have
> 3rd - GCC5.
>
> Options to solve that problem:
> 1. Add another toolchain, which would be selected somehow through
> Makefile logic when tianocore payload selected
> 2. Add patches in coreboot to support GCC7 or GCC6 - this may cause
> unexpected behavior and maintaining this support out of edk2 can be
> problematic
> 3. Add patches in edk2 to support GCC7 or GCC6 - I think this is long
> and hard road
> 4. Any other that I'm missing ?
>
> In light of coreboot-sdk I have one question that bugs me for long time.
> Why we use Debian sid? Each build using moving target can be different
> what means it is hard to build 2 the same coreboot-sdk containers.
>
> Best Regards,
> --
> Piotr Król
> Embedded Systems Consultant
> http://3mdeb.com | @3mdeb_com
>
> --
> coreboot mailing list: coreboot@coreboot.org
> https://mail.coreboot.org/mailman/listinfo/coreboot

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

Re: [coreboot] VbTryLoadKernel restriction on 512 byte sector size

[Aaron Durbin via coreboot]

On Tue, Apr 3, 2018 at 10:26 AM,   wrote:
> Folks,
> Can anyone on this list expound on why VbTryLoadKernel() performs a
> sanity-check on bytes_per_lba != 512?

>--->---/*
>--->--- * Sanity-check what we can. FWIW, VbTryLoadKernel() is always
>--->--- * called with only a single bit set in get_info_flags.
>--->--- *
>--->--- * Ensure 512-byte sectors and non-trivially sized disk (for
>--->--- * cgptlib) and that we got a partition with only the flags we
>--->--- * asked for.
>--->--- */

Seems to do with cgptlib having a 512 byte assumption. I'm not sure
what would break if that check was removed. We'd have to look at
cgptlib and other uses. Please file a Google issue tracker bug so we
can properly drive this.

>
> We are working on supporting a board that will require bytes_per_lba == 4K.
> Cheers,
> T.mike
>
> --
> coreboot mailing list: coreboot@coreboot.org
> https://mail.coreboot.org/mailman/listinfo/coreboot

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

Re: [coreboot] Out of MTRRs

[Aaron Durbin via coreboot]

On Sat, Mar 31, 2018 at 10:21 AM, Nico Huber  wrote:
> On 31.03.2018 17:31, Nico Huber wrote:
>>
>> On 23.03.2018 16:29, Jay Talbott wrote:
>>>
>>> Do you think they will resolve the issue that I am seeing?
>>
>>
>> I don't know. As you top posted, I haven't looked at it yet. I'll have a
>> look. But it seems very likely that you'll have to fix something about
>> your memory map.
>
>
> Yes, it should help. Can you please send a log of the same configuration
> as used for the last log but with (at least) the first two of my patches
> applied?
>
> I would expect the UC-default case to succeed, then, because we can
> squash the MTRRs above 4GiB together.
>
> Another thought that came about the temporary ROM caching: In your case
> 2MiB ROM are set up (is that correct? [1]). I think this is why nobody
> else run into this issue, most have a big (e.g. 16MiB) SPI flash that is
> easier to handle in the WB-default case. But the code that adds the tem-
> porary caching confuses me anyway:
>
> (from src/soc/intel/skylake/romstage/romstage_fsp20.c)
>>
>> /* Cache the ROM as WP just below 4GiB. */
>> postcar_frame_add_mtrr(, 0x - CONFIG_ROM_SIZE + 1,
>> CONFIG_ROM_SIZE, MTRR_TYPE_WRPROT);
>
>
> Here (and for many other platforms in coreboot), CONFIG_ROM_SIZE is
> used. Beside your problem of the hard to cache smaller ROM sizes, it
> could also be too big. e.g. with a 32MiB ROM, we would mark MMIO space
> as cacheable. Aaron, what do you think? would it hurt to always mark
> 16MiB on Intel? IIRC, 16MiB is the maximum that is memory mapped of
> the boot ROM, and I don't think it would hurt if the ROM is actually
> smaller.

I think that's definitely viable. That'd fix some of these messages.
To be fair, the MTRR calculation does end up working. It's just trying
really hard temporarily add things in.

>
> Nico
>
> [1] This line of your log seems to suggest that you actually have 16MiB:
>>
>> SF: Detected FAST_SPI Hardware Sequencer with sector size 0x1000, total
>> 0x100
>
> So I suspect your CONFIG_ROM_SIZE is off.

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

Re: [coreboot] Assigning PCI resources clobbers console with io-mapped / memory-mapped UART

[Aaron Durbin via coreboot]

On Thu, Mar 29, 2018 at 3:36 PM, Jay Talbott
 wrote:
> We ran into an issue where we were not getting a full coreboot log on
> Denverton with the Harcuvar CRB, where it just abruptly stops the serial
> console output during the assignment of the PCI resources.
>
>
>
> Root Device assign_resources, bus 0 link: 0
>
> DOMAIN:  assign_resources, bus 0 link: 0
>
> PCI: 00:09.0 1c <- [0x00 - 0x00fffe] size 0x gran 0x0c
> bus 01 io
>
> PCI: 00:09.0 24 <- [0x00dfff - 0x00dffe] size 0x gran 0x14
> bus 01 prefmem
>
> PCI: 00:09.0 20 <- [0x00dfff - 0x00dffe] size 0x gran 0x14
> bus 01 mem
>
> PCI: 00:09.0 10 <- [0x00df70 - 0x00df71] size 0x0002 gran 0x11
> mem64
>
> PCI: 00:0e.0 1c <- [0x00 - 0x00fffe] size 0x gran 0x0c
> bus 02 io
>
> PCI: 00:0e.0 24 <- [0x00dfff - 0x00dffe] size 0x gran 0x14
> bus 02 prefmem
>
> PCI: 00:0e.0 20 <- [0x00dfff - 0x00dffe] size 0x gran 0x14
> bus 02 mem
>
> PCI: 00:0e.0 10 <- [0x00df72 - 0x00df73] size 0x0002 gran 0x11
> mem64
>
> PCI: 00:10.0 1c <- [0x00 - 0x00fffe] size 0x gran 0x0c
> bus 03 io
>
> PCI: 00:10.0 24 <- [0x00dc00 - 0x00ddff] size 0x0200 gran 0x14
> bus 03 prefmem
>
> PCI: 00:10.0 20 <- [0x00de00 - 0x00de8f] size 0x0090 gran 0x14
> bus 03 mem
>
> PCI: 00:10.0 10 <- [0x00df74 - 0x00df75] size 0x0002 gran 0x11
> mem64
>
> PCI: 00:10.0 assign_resources, bus 3 link: 0
>
> PCI: 03:00.0 1c <- [0x00 - 0x00fffe] size 0x gran 0x0c
> bus 04 io
>
> PCI: 03:00.0 24 <- [0x00dc00 - 0x00ddff] size 0x0200 gran 0x14
> bus 04 prefmem
>
> PCI: 03:00.0 20 <- [0x00de00 - 0x00de8f] size 0x0090 gran 0x14
> bus 04 mem
>
> PCI: 03:00.0 assign_resources, bus 4 link: 0
>
> PCI: 04:00.0 10 <- [0x00dc00 - 0x00ddff] size 0x0200 gran 0x19
> prefmem
>
> PCI: 04:00.0 14 <- [0x00de82 - 0x00de823fff] size 0x4000 gran 0x0e
> mem
>
> PCI: 04:00.0 18 <- [0x00de00 - 0x00de7f] size 0x0080 gran 0x17
> mem
>
> PCI: 04:00.0 30 <- [0x00de80 - 0x00de81] size 0x0002 gran 0x11
> romem
>
> PCI: 03:00.0 assign_resources, bus 4 link: 0
>
> PCI: 00:10.0 assign_resources, bus 3 link: 0
>
> PCI: 00:12.0 10 <- [0x00df77b000 - 0x00df77b3ff] size 0x0400 gran 0x0a
> mem64
>
> PCI: 00:14.0 10 <- [0x00df774000 - 0x00df775fff] size 0x2000 gran 0x0d
> mem
>
> PCI: 00:14.0 14 <- [0x00df77c000 - 0x00df77c0ff] size 0x0100 gran 0x08
> mem
>
> PCI: 00:14.0 18 <- [0x001c40 - 0x001c47] size 0x0008 gran 0x03
> io
>
> PCI: 00:14.0 1c <- [0x001c60 - 0x001c63] size 0x0004 gran 0x02
> io
>
> PCI: 00:14.0 20 <- [0x001c00 - 0x001c1f] size 0x0020 gran 0x05
> io
>
> PCI: 00:14.0 24 <- [0x00df77a000 - 0x00df77a7ff] size 0x0800 gran 0x0b
> mem
>
> PCI: 00:15.0 10 <- [0x00df76 - 0x00df76] size 0x0001 gran 0x10
> mem64
>
> PCI: 00:16.0 1c <- [0x00 - 0x00fffe] size 0x gran 0x0c
> bus 05 io
>
> PCI: 00:16.0 24 <- [0x00dea0 - 0x00deef] size 0x0050 gran 0x14
> bus 05 prefmem
>
> PCI: 00:16.0 20 <- [0x00df50 - 0x00df5f] size 0x0010 gran 0x14
> bus 05 mem
>
> PCI: 00:16.0 assign_resources, bus 5 link: 0
>
> PCI: 05:00.0 10 <- [0x00dea0 - 0x00debf] size 0x0020 gran 0x15
> prefmem64
>
> PCI: 05:00.0 20 <- [0x00dee0 - 0x00dee03fff] size 0x4000 gran 0x0e
> prefmem64
>
> PCI: 05:00.0 30 <- [0x00df50 - 0x00df57] size 0x0008 gran 0x13
> romem
>
> PCI: 05:00.1 10 <- [0x00dec0 - 0x00dedf] size 0x0020 gran 0x15
> prefmem64
>
> PCI: 05:00.1 20 <- [0x00dee04000 - 0x00dee07fff] size 0x4000 gran 0x0e
> prefmem64
>
> PCI: 05:00.1 30 <- [0x00df58 - 0x00df5f] size 0x0008 gran 0x13
> romem
>
> PCI: 00:16.0 assign_resources, bus 5 link: 0
>
> PCI: 00:17.0 1c <- [0x00 - 0x00fffe] size 0x gran 0x0c
> bus 06 io
>
> PCI: 00:17.0 24 <- [0x00df00 - 0x00df4f] size 0x0050 gran 0x14
> bus 06 prefmem
>
> PCI: 00:17.0 20 <- [0x00df60 - 0x00df6f] size 0x0010 gran 0x14
> bus 06 mem
>
> PCI: 00:17.0 assign_resources, bus 6 link: 0
>
> PCI: 06:00.0 10 <- [0x00df00 - 0x00df1f] size 0x0020 gran 0x15
> prefmem64
>
> PCI: 06:00.0 20 <- [0x00df40 - 0x00df403fff] size 0x4000 gran 0x0e
> prefmem64
>
> PCI: 06:00.0 30 <- [0x00df60 - 0x00df67] size 0x0008 gran 0x13
> romem
>
> PCI: 06:00.1 10 <- [0x00df20 - 0x00df3f] size 0x0020 gran 0x15
> prefmem64
>
> PCI: 06:00.1 20 <- [0x00df404000 - 0x00df407fff] size 0x4000 gran 0x0e
> prefmem64
>
> PCI: 06:00.1 30 <- [0x00df68 - 0x00df6f] size 0x0008 gran 0x13
> romem
>
> PCI: 00:17.0 assign_resources, bus 6 link: 0
>
> PCI: 00:18.0 10 <- [0x00df776000 - 0x00df776fff] size 0x1000 gran 0x0c
> mem64
>
>
>
> The boot continues, there’s just no more console output from coreboot past
> 

Re: [coreboot] Out of MTRRs

[Aaron Durbin via coreboot]

On Mon, Mar 19, 2018 at 10:55 AM, Jay Talbott
 wrote:
> See below…
> - Jay
>

[Mon Mar 19 09:41:59.840 2018] MTRR Range: Start=79fff000 End=7a00
(Size 1000)
[Mon Mar 19 09:41:59.840 2018] MTRR Range: Start=7a00 End=7a80
(Size 80)
[Mon Mar 19 09:41:59.840 2018] MTRR Range: Start=7a80 End=7ac0
(Size 40)
[Mon Mar 19 09:41:59.840 2018] MTRR Range: Start=7ac0 End=7ae0
(Size 20)
[Mon Mar 19 09:41:59.840 2018] MTRR Range: Start=7ae0 End=7af0
(Size 10)
[Mon Mar 19 09:41:59.840 2018] MTRR Range: Start=7af0 End=7af8
(Size 8)
[Mon Mar 19 09:41:59.840 2018] MTRR Range: Start=7af8 End=7afc
(Size 4)
[Mon Mar 19 09:41:59.840 2018] MTRR Range: Start=7afc End=7afe
(Size 2)
[Mon Mar 19 09:41:59.840 2018] MTRR Range: Start=7afe End=7aff
(Size 1)
[Mon Mar 19 09:41:59.840 2018] MTRR Range: Start=7aff End=7aff8000
(Size 8000)
[Mon Mar 19 09:41:59.840 2018] No more variable MTRRs: 10
[Mon Mar 19 09:41:59.840 2018] No more variable MTRRs: 10
[Mon Mar 19 09:41:59.840 2018] No more variable MTRRs: 10

This is from postcar loading. I don't understand why the code is is
adding that many MTRR entries during postcar loading. The only that
should be added is the ranges needed to load and run ramstage.  The
postcar MTRR code *does not* combine entries. It just determines the
number of MTRRs to meet what is sent in. It seems 0x79fff000--7aff8000
is being requested. That's a pretty bad request given the current
constraints. Do you know why that was requested? And why it can't be
more naturally aligned?

Below is the final MTRR calculation in ramstage:

[Mon Mar 19 09:42:04.473 2018] MTRR: Physical address space:
[Mon Mar 19 09:42:04.473 2018] 0x - 0x000a
size 0x000a type 6
[Mon Mar 19 09:42:04.473 2018] 0x000a - 0x000c
size 0x0002 type 0
[Mon Mar 19 09:42:04.473 2018] 0x000c - 0x7b80
size 0x7b74 type 6
[Mon Mar 19 09:42:04.473 2018] 0x7b80 - 0xc000
size 0x4480 type 0
[Mon Mar 19 09:42:04.473 2018] 0xc000 - 0xd000
size 0x1000 type 1
[Mon Mar 19 09:42:04.473 2018] 0xd000 - 0x0001
size 0x3000 type 0
[Mon Mar 19 09:42:04.473 2018] 0x0001 - 0x00047f00
size 0x37f00 type 6
[Mon Mar 19 09:42:04.473 2018] MTRR: Fixed MSR 0x250 0x0606060606060606
[Mon Mar 19 09:42:04.473 2018] MTRR: Fixed MSR 0x258 0x0606060606060606
[Mon Mar 19 09:42:04.473 2018] MTRR: Fixed MSR 0x259 0x
[Mon Mar 19 09:42:04.473 2018] MTRR: Fixed MSR 0x268 0x0606060606060606
[Mon Mar 19 09:42:04.473 2018] MTRR: Fixed MSR 0x269 0x0606060606060606
[Mon Mar 19 09:42:04.473 2018] MTRR: Fixed MSR 0x26a 0x0606060606060606
[Mon Mar 19 09:42:04.473 2018] MTRR: Fixed MSR 0x26b 0x0606060606060606
[Mon Mar 19 09:42:04.480 2018] MTRR: Fixed MSR 0x26c 0x0606060606060606
[Mon Mar 19 09:42:04.480 2018] MTRR: Fixed MSR 0x26d 0x0606060606060606
[Mon Mar 19 09:42:04.480 2018] MTRR: Fixed MSR 0x26e 0x0606060606060606
[Mon Mar 19 09:42:04.480 2018] MTRR: Fixed MSR 0x26f 0x0606060606060606
[Mon Mar 19 09:42:04.480 2018] call enable_fixed_mtrr()
[Mon Mar 19 09:42:04.480 2018] CPU physical address size: 39 bits
[Mon Mar 19 09:42:04.480 2018] MTRR: default type WB/UC MTRR counts: 6/11.
[Mon Mar 19 09:42:04.480 2018] MTRR: WB selected as default type.
[Mon Mar 19 09:42:04.480 2018] MTRR: 0 base 0x7b80 mask
0x007fff80 type 0
[Mon Mar 19 09:42:04.480 2018] MTRR: 1 base 0x7c00 mask
0x007ffc00 type 0
[Mon Mar 19 09:42:04.480 2018] MTRR: 2 base 0x8000 mask
0x007fc000 type 0
[Mon Mar 19 09:42:04.480 2018] MTRR: 3 base 0xc000 mask
0x007ff000 type 1
[Mon Mar 19 09:42:04.480 2018] MTRR: 4 base 0xd000 mask
0x007ff000 type 0
[Mon Mar 19 09:42:04.480 2018] MTRR: 5 base 0xe000 mask
0x007fe000 type 0
[Mon Mar 19 09:42:04.480 2018] MTRR: Fixed MSR 0x250 0x0606060606060606
[Mon Mar 19 09:42:04.480 2018] MTRR: Fixed MSR 0x258 0x0606060606060606
[Mon Mar 19 09:42:04.480 2018] MTRR: Fixed MSR 0x259 0x
[Mon Mar 19 09:42:04.480 2018] MTRR: Fixed MSR 0x268 0x0606060606060606
[Mon Mar 19 09:42:04.480 2018] MTRR: Fixed MSR 0x269 0x0606060606060606
[Mon Mar 19 09:42:04.480 2018] MTRR: Fixed MSR 0x26a 0x0606060606060606
[Mon Mar 19 09:42:04.480 2018] MTRR: Fixed MSR 0x26b 0x0606060606060606
[Mon Mar 19 09:42:04.486 2018] MTRR: Fixed MSR 0x26c 0x0606060606060606
[Mon Mar 19 09:42:04.486 2018] MTRR: Fixed MSR 0x26d 0x0606060606060606
[Mon Mar 19 09:42:04.486 2018] MTRR: Fixed MSR 0x26e 0x0606060606060606
[Mon Mar 19 09:42:04.486 2018] MTRR: Fixed MSR 0x26f 0x0606060606060606
[Mon Mar 19 09:42:04.486 2018] MTRR: TEMPORARY Physical address space:
[Mon Mar 19 09:42:04.486 2018] call enable_fixed_mtrr()
[Mon Mar 19 09:42:04.486 2018] 0x - 

Re: [coreboot] only 8GB RAM on ThinkPad X230 after commit 7539b8c3

[Aaron Durbin via coreboot]

Could you please post the logs?

On Sun, Mar 18, 2018 at 4:42 PM, Marek Behun  wrote:
> Hello,
>
> with the commit 7539b8c3 "nb/intel/sandybridge: Use common mrc cache
> functions" I only have accessible 8 GB of ram on ThinkPad X230,
> although I have two 8 GB modules. On the previous commit whole 16 GB is
> visible.
>
> Marek

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

Re: [coreboot] Out of MTRRs

[Aaron Durbin via coreboot]

Please post the full logs so we can see the address space. The 'Unable
to insert temporary MTRR range' log message is only for tempoarility
mapping the SPI flash. However, it's impossible to debug w/o the full
logs to see what your address space looks like.

On Sat, Mar 17, 2018 at 12:28 PM, Jay Talbott
 wrote:
> I’m working on a coreboot solution for a SkyLake based board that uses
> SO-DIMMs.
>
>
>
> The plan is for two 8GB DIMMs, for a total of 16GB of RAM.
>
>
>
> But with two 8GB DIMMs installed, I get the following during the boot:
>
>
>
> Taking a reserved OS MTRR.
>
> Taking a reserved OS MTRR.
>
> Taking a reserved OS MTRR.
>
> ERROR: Not enough MTRRs available! MTRR indexis 10 with 10 MTTRs in total.
>
> Not enough MTRRs: 11 vs 10
>
> Unable to insert temporary MTRR range: 0xff80 -
> 0x0001 size 0x0080 type 5
>
>
>
> This is obviously a problem…
>
>
>
> If I remove one DIMM, then I just get:
>
>
>
> Taking a reserved OS MTRR.
>
> Taking a reserved OS MTRR.
>
>
>
> Still an issue, although at least we don’t run out of MTRRs.
>
>
>
> If I use a single 4GB DIMM instead of an 8GB DIMM, there’s no issue with the
> MTRR config at all.
>
>
>
> I’m assuming that I’m not the first person to run into this when using
> coreboot on systems with larger amounts of RAM, so I figured I’d ask the
> community what’s the fix to getting this to work correctly with 16GB of RAM
> before trying to figure it out myself.
>
>
>
> Any help would be most appreciated.
>
>
>
> Thanks,
>
>
>
> - Jay
>
>
>
> Jay Talbott
> Principal Consulting Engineer
> SysPro Consulting, LLC
> 3057 E. Muirfield St.
> Gilbert, AZ 85298
> (480) 704-8045
> (480) 445-9895 (FAX)
> jaytalb...@sysproconsulting.com
>
> http://www.sysproconsulting.com
>
>
>
>
> --
> coreboot mailing list: coreboot@coreboot.org
> https://mail.coreboot.org/mailman/listinfo/coreboot

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

Re: [coreboot] Intel soc ACPI generation using soc/intel/common/block/acpi

[Aaron Durbin via coreboot]

On Thu, Feb 8, 2018 at 8:54 AM, Julien Viard de Galbert
 wrote:
>
>
> Le 8 févr. 2018 à 17:24, Aaron Durbin  a écrit :
>
> On Thu, Feb 8, 2018 at 7:20 AM, Julien Viard de Galbert
>  wrote:
>
> Hello all,
>
> First sorry for mailing direclty those of you who are on the coreboot
> mailing list.
>
> I’m currently in the process of upstreaming the changes we have on
> denverton.
> On the ACPI I see a lot in common with the code available in
> soc/intel/common/block/acpi.
> However this depends on PMC which depends on GPIO. And the GPIO code
> conflicts with the code already in denverton so I can’t enable it. (I’ve not
> checked
> In details about the PMC code yet).
>
> What would be the best way to port it ?
>
> 1. Stick with what is working, duplicate some code but don’t break other
> platforms.
> 2. Try to refactor the GPIO code and denverton code so they are compatible.
>
> For point 2 the thing is that I can test for other platforms and it will
> really add more
> work now. But if the longterm goal is to refactor all intel soc to mostly
> use common/block
> then this might be worth it.
>
> What are your recommendations?
>
>
> What are the actual changes in the gpio blocks compared to what's there?
>
>
> I’ve not looked into the datasheet of other chips to see the difference.
> But the code is really different.
> The GPIO code in denverton looks like it’s been imported from the EFI code.
>
> After looking again, it seams that the underlying hardware is similar (I
> checked
> a few bits and they are at the same place).
> However the ‘user' interface is really different: The denverton uses a
> configuration
> structure based on enums and bitfields that is not present in common code.

That's what happens w/ out of tree patches and people take short cuts.

>
>
> Best Regards
>
>
> --
> Julien Viard de Galbert - jviarddegalb...@online.net
> Online / Scaleway
> Looking for an amazing job? Join us NOW ! https://careers.scaleway.com/
>
>
>
>
>
> --
> coreboot mailing list: coreboot@coreboot.org
> https://mail.coreboot.org/mailman/listinfo/coreboot
>
>
> --
> Julien Viard de Galbert - jviarddegalb...@online.net
> Online / Scaleway
> Looking for an amazing job? Join us NOW ! https://careers.scaleway.com/
>
>
>
>

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

Re: [coreboot] Intel soc ACPI generation using soc/intel/common/block/acpi

[Aaron Durbin via coreboot]

On Thu, Feb 8, 2018 at 7:20 AM, Julien Viard de Galbert
 wrote:
> Hello all,
>
> First sorry for mailing direclty those of you who are on the coreboot
> mailing list.
>
> I’m currently in the process of upstreaming the changes we have on
> denverton.
> On the ACPI I see a lot in common with the code available in
> soc/intel/common/block/acpi.
> However this depends on PMC which depends on GPIO. And the GPIO code
> conflicts with the code already in denverton so I can’t enable it. (I’ve not
> checked
> In details about the PMC code yet).
>
> What would be the best way to port it ?
>
> 1. Stick with what is working, duplicate some code but don’t break other
> platforms.
> 2. Try to refactor the GPIO code and denverton code so they are compatible.
>
> For point 2 the thing is that I can test for other platforms and it will
> really add more
> work now. But if the longterm goal is to refactor all intel soc to mostly
> use common/block
> then this might be worth it.
>
> What are your recommendations?
>

What are the actual changes in the gpio blocks compared to what's there?

> Best Regards
>
>
> --
> Julien Viard de Galbert - jviarddegalb...@online.net
> Online / Scaleway
> Looking for an amazing job? Join us NOW ! https://careers.scaleway.com/
>
>
>
>
>
> --
> coreboot mailing list: coreboot@coreboot.org
> https://mail.coreboot.org/mailman/listinfo/coreboot

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

Re: [coreboot] 16 GPUs on one board

[Aaron Durbin via coreboot]

On Sun, Jan 7, 2018 at 2:05 PM, Adam Talbot  wrote:

> Lets take a slight differently tactic. What would happen if we removed the
> ROM from a GPU/NIC? Would the GPU's still require 256MB~304MB of PCI_MMIO?
>

Yes, I would expect it to. Those cards have on-board memory that would need
to be addressed.


>
>
>
> On Sat, Jan 6, 2018 at 3:00 PM, taii...@gmx.com  wrote:
>
>> I have had this issue in regards to SR-IOV, - at the moment coreboot only
>> supports 32Bit MMIO unfortunately one can't have too many graphics devices
>> or network interfaces apparently.
>>
>> Considering the success of the OpenBMC port fund it would be nice if we
>> could get a fund going to fix this if it wouldn't cost too much as I would
>> really like to be able to use SR-IOV and many more PCI-e devices on my
>> board via a cyclone PCI-e expansion system eventually.
>>
>> I am not sure if there is a work-around in linux but post back if you
>> find one.
>>
>
>
> --
> coreboot mailing list: coreboot@coreboot.org
> https://mail.coreboot.org/mailman/listinfo/coreboot
>
-- 
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] 16 GPUs on one board

[Aaron Durbin via coreboot]

On Thu, Jan 4, 2018 at 1:33 PM, Arthur Heymans  wrote:

> Hi
>
> What target are you on?
>
> Coreboot tries to locate all PCI BAR's below 4G in the PCI_MMIO region and
> above the lower DRAM
> limit (the rest of the DRAM is mapped above 4G). Typically a GPU takes
> around 256M but I guess that could be more nowadays. If that doesn't fit
> in the PCI MMIO region, it will have troubles and probably not boot.
>
> The real fix would be to have coreboot locate BAR's above 4G too.
>
> At least that is what I think is going on here...
>

That is most likely the case.


>
> (sry for top posting it felt like the answer was better in one block)
>
> Adam Talbot  writes:
>
> > -Coreboot
> > I am totally off the deep end and don't know where else to turn for
> help/advice. I am trying to get 16 GPU's on one motherboard. Whenever I
> attach more then 3~5 GPU's to a single motherboard, it fails to post. To
> make matters worse, my post
> > code reader(s) don't seem to give me any good error codes. Or at least
> nothing I can go on.
> >
> > I am using PLX PEX8614 chips (PCIe 12X switch) to take 4 lanes and pass
> them to 8 GPU's, 1 lane per GPU. Bandwidth is not an issues as all my code
> runs native on the GPUs. Depending on the motherboard, I can get up to 5
> GPU's to post. After
> > many hours of debugging, googling, and trouble shooting, I am out of
> ideas.
> >
> > At this point I have no clue. I think there is a hardware, and a BIOS
> component? Can you help me understand the post process and where the hang
> up is occurring? Do you think Coreboot will get around this hangup and, if
> so, can you advise a
> > motherboard for me to test with?
> >
> > Its been a long time sense I last compiled linuxbios. ;-)
> >
> > Thanks
> > -Adam
>
> Kind regards
>
> --
> Arthur Heymans
>
> --
> coreboot mailing list: coreboot@coreboot.org
> https://mail.coreboot.org/mailman/listinfo/coreboot
>
-- 
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] Depthcharge License

[Aaron Durbin via coreboot]

https://chromium-review.googlesource.com/c/chromiumos/platform/depthcharge/+/837589

On Thu, Dec 21, 2017 at 11:14 AM, <ttu...@codeaurora.org> wrote:

> On 2017-12-19 09:53, David Hendricks wrote:
>
>> To be fair, it appears that many source files refer to a non-existent
>> LICENSE file. Someone on the CrOS team should probably just add the
>> LICENSE file for depthcharge and/or contact mal@ to see how the
>> license info is being collected these days (e.g. for
>> chrome://os-credits [3]).
>>
>>
> Thanks for the input on the DC licensing, and because lawyers are involved
> I need to ask a direct question.
> Can a Depthcharge maintainer (anybody who has +2 gerrit authority would
> suffice) state on this thread
> that the Depthcharge project license is GPLv2 (or later)?
>
> I know this feels redundant and that the question has been asked and
> answered, I'm just trying
> to satisfy our internal legal group.
>
> Per David's point above, this direct question would not be required to
> satisfy the lawyers
> if a top-level COPYING or LICENSE file is added to Depthcharge.  Which I
> will be happy to
> add once I'm able to start contributing to the project.
> Cheers,
> T.mike
>
> On Tue, Dec 19, 2017 at 9:19 AM, ron minnich <rminn...@gmail.com>
>> wrote:
>>
>> Is there even a question? Looks like aaron just answered the
>>> original question, which boils down to Read The Source?
>>>
>>> On Tue, Dec 19, 2017 at 7:58 AM Aaron Durbin via coreboot
>>> <coreboot@coreboot.org> wrote:
>>>
>>> On Tue, Dec 19, 2017 at 8:03 AM, <ttu...@codeaurora.org> wrote:
>>> On 2017-12-15 13:39, ttu...@codeaurora.org wrote:
>>> Preparing to mirror the coreboot.org [1] requires us to vet the
>>> various
>>> licenses, etc.
>>>
>>> There doesn't appear to be a LICENSE or COPYING file in the
>>> Depthcharge tree.
>>>
>>> My understanding is that Depthcharge is licensed GPLv2 (or later).
>>>
>>> How would I confirm this with an online source?
>>>
>>> Cheers,
>>> T.mike
>>>
>>> Should this query be posted on Chromium list rather than Coreboot
>>> list?
>>>
>>
>> Probably. The files in the depthcharge repository  have licenses at
>> the top of each file. They are GPLv2.
>>
>> Cheers,
>>> T.mike
>>>
>>> --
>>> coreboot mailing list: coreboot@coreboot.org
>>> https://mail.coreboot.org/mailman/listinfo/coreboot [2]
>>>
>>  --
>> coreboot mailing list: coreboot@coreboot.org
>> https://mail.coreboot.org/mailman/listinfo/coreboot [2]
>> --
>> coreboot mailing list: coreboot@coreboot.org
>> https://mail.coreboot.org/mailman/listinfo/coreboot [2]
>>
>>
>>
>> Links:
>> --
>> [1] http://coreboot.org
>> [2] https://mail.coreboot.org/mailman/listinfo/coreboot
>> [3] https://www.chromium.org/chromium-os/licenses
>>
>
-- 
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] Depthcharge License

[Aaron Durbin via coreboot]

On Tue, Dec 19, 2017 at 8:03 AM,  wrote:

> On 2017-12-15 13:39, ttu...@codeaurora.org wrote:
>
>> Preparing to mirror the coreboot.org requires us to vet the various
>> licenses, etc.
>>
>> There doesn't appear to be a LICENSE or COPYING file in the Depthcharge
>> tree.
>>
>> My understanding is that Depthcharge is licensed GPLv2 (or later).
>>
>> How would I confirm this with an online source?
>>
>> Cheers,
>> T.mike
>>
>
> Should this query be posted on Chromium list rather than Coreboot list?
>
>
Probably. The files in the depthcharge repository  have licenses at the top
of each file. They are GPLv2.

Cheers,
> T.mike
>
> --
> coreboot mailing list: coreboot@coreboot.org
> https://mail.coreboot.org/mailman/listinfo/coreboot
>
-- 
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] SMM save area in MSRs on newer intel CPUs

[Aaron Durbin via coreboot]

haswell and on has this. You can see it in the haswell code. We
actually opted not to use it but for relocation so we could look at
each cpu's save state from a single cpu to see who caused the smi,
etc.

On Sat, Oct 7, 2017 at 8:38 AM, ron minnich  wrote:
> can someone point me at the documents that describe how this works?
>
> thanks
>
> ron
>
> --
> coreboot mailing list: coreboot@coreboot.org
> https://mail.coreboot.org/mailman/listinfo/coreboot

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

Re: [coreboot] How is depreciating 95% of coreboot boards worth it for such minor improvements?

[Aaron Durbin via coreboot]

On Wed, Aug 23, 2017 at 8:31 PM, Kyösti Mälkki  wrote:
> On Thu, Aug 24, 2017 at 12:29 AM, taii...@gmx.com  wrote:
>> Ah I see thanks for explaining.
>>
>> I had read all the AGESA boards were going to be removed, besides the asus
>> D8/D16 those are the last and best owner controlled x86 boards.
>> Is there a current list of boards to be removed?
>>
>
> Hi
>
> The work for LATE -> EARLY CBMEM transition for AGESA has been
> available for review since February 2017. It's probably announced or
> mentioned only briefly on the mailing list, but certainly very visible
> on gerrit.
>
> Unfortunately people currently working on AMD platforms did not show
> much interest to review that work. Luckily, devs from chromeos team
> (who had no commercial interest, but maybe strings attached) stepped
> in the reviews so that the groundwork of AGESA interface changes got
> done and reviewed. What's left is merging the individual board
> changes, which I am about to do very soon now. Some regressions
> expected, most of the old defects remain unfixed.
>
> I should thank the couple individuals and companies that contributed
> by covering some costs of this development. Still, that does not
> magically turn all these boards into status of "maintained".
>
> Now, this applies to everyone: please push status updates for the
> boards you have access to, otherwise majority of AGESA boards just hit
> that deprecation in the next cycle of board removals. Also, when you
> create a board port and you go through all the trouble of getting it
> past (my strict or someone else's less strict) review policy, is it
> REALLY that hard to run board_status script? You know who you are. Is
> there something we need to do better here? Provide OS boot images just
> for this purpose?
>
> As for binaryPI boards, those are at EARLY_CBMEM_INIT starting from August 2.
>
> As for K8/K10, your help is needed in testing. This is particularly
> for boards with multiple CPU packages (nodes).

I do want to thank Kyösti for putting in the development effort in
this area for these platforms. He's been actively maintaining and
developing for a lot of platforms that have lost some love over the
years. I know there are others who contribute as well, but I did want
to call attention Kyösti's contribution as I've been following it
fairly closely. It's very much appreciated.

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

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

Re: [coreboot] How is depreciating 95% of coreboot boards worth it for such minor improvements?

[Aaron Durbin via coreboot]

On Wed, Aug 23, 2017 at 2:06 PM, Felipe Sanches  wrote:
> Is there an index of which was the latest git commit for each removed board
> ?
> That would help anyone interested in working on them in the future. It is
> not strictly necessary, but would certainly make life easier. And it can't
> be that hard to update a wiki page (or something equivalent) any time
> there's a new board deprecation.

Keep in mind that branches exist for each release which inherently has
the full history at time of release:

$ git ls-remote upstream refs/heads/*
6cb3a59fd5e754c3627b79db21c5bcc284bfd721refs/heads/4.1
ad342a4589df6c51c96c1e9110979964b244fec3refs/heads/4.2
1bf5e6409678d04fd15f9625460078853118521crefs/heads/4.3
588ccaa9a7d94da4f5a5b3579eb9e3d06c9f4a51refs/heads/4.4
c21e07385f9b4048d6ddb67989b23999f566951drefs/heads/classic-2014.10
e9418b454f6d2734360ca4e3c017f59904490d9frefs/heads/coreboot-v1
25d77ad675f8bac8fd7e038801c72797ea8dc7d6refs/heads/coreboot-v3
4fcce9da0a1b62b46ed78c522f6fcbf51ff5974erefs/heads/foo2
f5fe3590af9a67f9fd3adaee85168d3cac0d84d0refs/heads/master


>
> 2017-08-23 16:53 GMT-03:00 Nico Huber :
>>
>> Hi,
>>
>> On 23.08.2017 06:00, taii...@gmx.com wrote:
>> > Just because a board lacks active developers doesn't mean that no one is
>> > using it.
>>
>> right, and we won't stop anybody from using them in the future. Please
>> keep in mind, when a board is removed from the tree that only means that
>> the people working on newer boards don't maintain the old ones any more.
>> You can still check out the parent of the removal commit and build these
>> boards. I don't know which boards exactly are in question, but older
>> board ports are often broken anyway. So you can't argue that keeping
>> them in the tree would magically make them work.
>>
>> > As a layman I simply can't understand as to how all these seemingly
>> > insignificant improvements such as CBMEM in ramstage make it worth
>> > removing almost every compatible board from the source,
>>
>> I agree that these improvements would be insignificant to the boards in
>> question. Though, making improvements at all for newer platforms is much
>> harder if you have to take care of the old platforms (with incompatible
>> code) too.
>>
>> > including nearly
>> > all the models that still have an open source init.
>>
>> Can I see numbers please? I count about 50 Intel based boards (not
>> counting variants) with free init code which is actively developed.
>> There are more on the ARM front and probably some AMD based too. They'll
>> all stay. How many are we going to remove?
>>
>> > To me it seems at the rate this is going soon all that will be left is a
>> > few blobbed and NDA'ed development boards unavailable to the general
>> > public.
>>
>> What rate? how many have we removed already? 2? If you estimate from
>> that and the prospect that we'll remove 50+ one year later, well, then
>> we'd remove 1,000+ boards next year. That would indeed be a problem...
>>
>> >
>> > Am I mistaken?
>>
>> Yes, I guess.
>>
>> Nico
>>
>> --
>> coreboot mailing list: coreboot@coreboot.org
>> https://mail.coreboot.org/mailman/listinfo/coreboot
>
>
>
> --
> coreboot mailing list: coreboot@coreboot.org
> https://mail.coreboot.org/mailman/listinfo/coreboot

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

Re: [coreboot] About Paging, Realmode and what is going on

[Aaron Durbin via coreboot]

On Wed, Aug 2, 2017 at 1:36 PM, ron minnich  wrote:
>
>
> On Wed, Aug 2, 2017 at 12:08 PM Zoran Stojsavljevic
>  wrote:
>>
>>
>>
>> So, turning on the Virtual Mode (paging ON), you'll also imply that
>> Coreboot will initialize and use MMU, don't you?
>
>
> sure.
>
>>
>>
>> Am I correct, or you can use paging without MMU?!
>
>
> MMU must be on.
>
>>
>> I doubt that, perhaps. So, then, I would like to see this code in Coreboot
>> where MMU is initialized. And how it is initialized (maybe there is a some
>> over-simplified mode of operation using 2MB pages).
>
>
> yep.
>
>>
>>
>> And my question is: what for? Or I did not get the idea... Who really
>> needs to use paging in boot-loaders? Even INTEL, which (on purpose) makes
>> things way over-dimensioned and over-complicated, does NOT use paging in
>> UEFI BIOSes, so far???
>>
>
> it's trivial to turn on paging. In harvey I've got it down to 160 lines,
> including comments and white space. I made it much more compact in my CL
> from 1/2014.
>
> If you turn on paging you can capture null pointer derefs, and all other out
> of range address references. And relocatable modules are much easier..
>
> My question is, why not do it? I don't see any harm. All the other platforms
> in coreboot use paging. What's so special about x86 that it should not use
> paging?

You can't use it for CAR so that sorta throws out romstage and before.
It's up to the implementation of how CAR works within the hierarchy,
but with hardware page walkers that pull things through the cache
things can go badly. So then you could enable paging for ramstage.
Need to locate storage for the page tables, but that's not an
impossible thing either.

>
> ron
>
> --
> coreboot mailing list: coreboot@coreboot.org
> https://mail.coreboot.org/mailman/listinfo/coreboot

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

Re: [coreboot] What does *intelblocks* mean?

[Aaron Durbin via coreboot]

On Mon, Jun 5, 2017 at 2:48 AM, Paul Menzel
 wrote:
> Dear coreboot folks,
>
>
> In commit a554b0c5b7 (soc/intel/common/block: Add Intel XHCI driver
> support) [1] the directory
> `src/soc/intel/common/block/include/intelblocks` is created.
>
> Could somebody please help me, what *intelblocks* means here, and why
> *intel* is twice in the path?

It's common code to be used for intel SoCs. 'ipblock' would be more
appropriate, but I think people didn't want to freak anyone out with
the name 'ip'. The reason 'intelblocks' is in the include path is
because the include headers are namespaced. e.g. #include
.


>
>
> Thanks,
>
> Paul
>
>
> [1] https://review.coreboot.org/18221/
>
> --
> coreboot mailing list: coreboot@coreboot.org
> https://mail.coreboot.org/mailman/listinfo/coreboot

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

Re: [coreboot] Will we maintain Skylake/FSP1.1?

[Aaron Durbin via coreboot]

On Tue, May 9, 2017 at 10:14 AM, Nico Huber  wrote:
> Hi,
>
> I was walking through the Skylake FSP1.1 support in coreboot and asked
> myself if it is worth to clean it up and maintain the code? given that
> the upcoming release of Kabylake FSP should be able to supersede it (I
> presume it is?). Are there any plans yet to drop it once the next FSP
> is released? (when will that be anyway?)

I wanted to get rid of it, but Intel claimed they had customers using it still.

>
> Btw. does anybody feel like a maintainer for soc/intel/skylake/?

Personally feel? Or want?

>
> In it's current state it's very hard to use from a mainboard porter's
> point of view. Many of the selectable Kconfig settings are useless
> (either don't compile or don't run) for FSP1.1, and there's a `struct
> pei_data` [1] that seems to be a remnant of compatibility for a dif-
> ferent blob ;)

That's just an old remnant of passing data around. It could be removed
as you annotated isolating those pieces to different structs and/or
variables for passing data around. The name is obviously not
applicable w.r.t. its current use.

>
> Best regards,
> Nico
>
> PS. Microcode updates are also missing in the upstream blobs repo. Is
> that a licensing problem? If I try to download them from Intel, it
> asks me to click to accept that I'll prevent further distribution.
> I could prepare a patch to add them but somebody else would have
> to sign it off.
>
> [1] https://review.coreboot.org/#/c/19638/
>

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

Re: [coreboot] Intel PCH: When is the code for SPI flash reading used?

[Aaron Durbin via coreboot]

On Thu, May 4, 2017 at 4:16 PM, Marek Behun  wrote:
> Hello,
>
> is the code for SPI flash reading (from src/drivers/spi/spi_flash.c)
> used at all? From what I understood when reading Intel PCH datasheets,
> the SPI controller alone reads the whole BIOS. Is this wrong? Does the
> SPI controller read only the bootblock (on ThinkPad X230, for example),
> and the bootblock then reads the rest?
>

It is for certain platforms. But for the boot spi on Intel machine's
that's all abstracted away. If you look at spi_flash_probe() there's a
call to spi_flash_programmer_probe() which does a magic binding of a
spi flash that allows these specialized spi flash controllers on
chipsets like Intel's to provide the spi flash implementation. More
generic spi controllers with a spi flash hanging off of them would use
the code you are likely referring to. If you were talking about the
memory mapped reading of spi flash in the CPU's address space that's
all done within the hardware proper responding to the CPU's memory
read transaction.

> Thank you.
>
> Marek
>
> --
> coreboot mailing list: coreboot@coreboot.org
> https://mail.coreboot.org/mailman/listinfo/coreboot

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

Re: [coreboot] Why does src/soc/intel/ exist?

[Aaron Durbin via coreboot]

On Tue, May 2, 2017 at 5:24 AM, Arthur Heymans  wrote:
> Hi
>
> I am wondering why newer intel code is being pushed to src/soc/intel/*/
> instead of the traditional src/{cpu,southbridge,northbridge}/intel ?

The era of mix and match ICs is pretty much gone. Even when there are
separate chips on a board there's only a single variant which actually
works in conjunction with the parts. Similarly to the socket
abstraction that closely coupled features to physical sockets it's not
really applicable any longer. It'd be forcing one to separate out
support where things are actually closely related.

>
> I know that physically things are now on one chip hence the soc but the
> code itself is often very similar to older cpu/southbridge/northbridge
> code. A good example is for instance smbus:
> https://review.coreboot.org/#/c/19372/ (unify src/soc/intel smbus code)
> https://review.coreboot.org/#/c/19258/ (unify src/southbridge/intel
> smbus code)
> with code that is almost identical so it would be beneficial to have
> this code in common for all intel targets, which is somewhat hindered or
> unpractical due to this dir separation.

How is that unpractical? I think you are assuming a specific directory
layout? Regardless of where code resides it's certainly possible to
share code. I think what you've pointed out is the timeline when new
development cutover to use src/soc for all the parts as the parts
really are SoC with a close coupling of implementations. The logic
blocks inside the parts are definitely forks of one another just like
software so there is re-use at play. With your change and the other
one we'd have 2 parallel implementations that could be tested for
parity and combined. That said, one needs to be careful in the details
for determining where something can be truly common. In the smbus
stuff specifically I'm sure there has be no real modification in a
very long time, but that isn't true for all blocks.

>
> The same could be said about a lot of LPC code, which has parts that are
> very similar across multiple generations, like pirq routing.
>
> Another thing to note is that dir names are often poorly named like amd
> where in src/northbridge/amd memory controller code resides, while in
> src/southbridge the code for both the northbridge and the southbridge
> resides.

I think you are seeing a reflection of how closely coupled certain
support and features are. There isn't always a hard split/separation
into those directory names because one needs to deal with configuring
multiple ip blocks for a feature.

>
> So my question is why does the newer codebase need to be separated like
> this and what is the benefit of doing so?

The newer code is not separated. It's actually combined? Benefit is
one stop shopping for a given platform for code to reside instead of
laying down multiple directories in various places that doesn't
reflect the construction of the systems. That said, with the
introduction of the common modules the soc/intel directories will
become thinner with selecting the common modules. That reflects more
closely how hardware development is being done.

Though the soc/ directory layout isn't the only way of making the
following work, it certainly helps. For the purposes of porting a
board based off of another board of a different platform it makes the
code maintenance easier solely based on #include files. There's really
not reason to have to #include a/specific/directory/header to make
something work. If the abstractions are done correctly one can
#include genericpath/header with a conforming API. That allows code
reuse and porting to go more smoothly. If you are having to #ifdef
CONFIG to figure out the include path in the c files that makes the
source ugly and a maintenance burden. This isn't the only the example,
but a good one where there's a ton of #ifdef for include paths:
src/cpu/x86/smm/smmrelocate.S. That's also ignoring the "common"
headers which do or don't expose certain functions that are found in
specific places as well. In short, I think the
southbridge/cpu/northbridge split in how it's been done in the past
actually creates more of a burden. Again, that doesn't mean things
can't be fixed by using consistent and namespaced include paths.

>
> Kind regards
> 
>
> Arthur Heymans
>
>
> --
> coreboot mailing list: coreboot@coreboot.org
> https://mail.coreboot.org/mailman/listinfo/coreboot

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

Re: [coreboot] SPI Flash does not work on Intel LeafHill CRB

[Aaron Durbin via coreboot]

On Thu, Mar 30, 2017 at 4:53 AM, Goetz Salzmann  wrote:
> Dear Toan,
>
>> I tried as your suggestion: flashed an 8 MB Intel-provided image, read
>> back from SPI chip right after flashing, got a 16 MB file (since SPI
>> chip is 16 MB size).
>> The first 8 MB of 2 files are exactly the same. So, flashing should
>> work fine.
>
> that's your problem right there.  The last 128kB of the SPI flash will be
> mapped to the End ot 1MB, there the CPU will start executing.  In your
> case, that's not the IBB / coreboot, but zeros (ok, maybe 0xFFs).

That's not exactly true. What is mapped below 4GiB in CPU address
space is the BIOS region described in the firmware descriptor. That
can float within the SPI address space. i.e. it doesn't have to be at
the end. To complicate matters further the IBBL on apollolake is found
in the IFWI -- completely separate from the CBFS and coreboot side of
things. The ifiwitool jams the bootblock into the right place. Lastly,
if there's not a correct setting applied in the descriptor the CSE
validates and checks that there are 2 IFWIs -- one is primary and one
is secondary. The secondary has to live directly at halfway point of
BIOS region (not half of SPI itself) with a 4KiB alignment, iirc.

>
> You have to rebuild your image for the correct flash size.
>
> Have fun,
> Goetz.
>
>
> --
> coreboot mailing list: coreboot@coreboot.org
> https://www.coreboot.org/mailman/listinfo/coreboot

-- 
coreboot mailing list: coreboot@coreboot.org
https://www.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] Group demographics

[Aaron Durbin via coreboot]

On Tue, Mar 28, 2017 at 3:20 PM,   wrote:
> On 2017-03-24 17:42, Julius Werner wrote:
>>>
>>> * Google's recovery manifest (from linux_recovery.sh) can pull a
>>> recovery image for a specific product, I have yet to find
>>> depthcharge as a payload
>>> * Obviously I haven't pulled all of the recovery images, but have
>>> looked at ~10
>>> * those interested in recovery image,
>>> /usr/sbin/chromeos_firmwareupdate --sb_extract yields a bios.bin
>>> file that cbfstool can parse (i.e. is a coreboot.rom file)
>>
>>
>> All non-x86 Chromebooks that use coreboot also use depthcharge. What
>> exactly do you mean when you say you can't find it? If you parse
>> bios.bin with cbfstool print, you should see a "fallback/payload"
>> file... that is depthcharge. (coreboot always requires the payload to
>> just be called "payload" in CBFS, regardless of what it actually is.)
>> You can extract it and run 'strings' on it to confirm.
>
>
> This was my understanding (Depthcharge being used as payload for all recent
> Chromebooks).
> What led me to question this understanding was:
>  * limited number of libpayload config files in coreboot source tree
>  * chromiumos build tree explicitly setting CONFIG_PAYLOAD="n" for all
> coreboot boards
>  * u-boot.dtb file being present in all bios.bin files I looked at from
> linux_recovery.sh manifest (including Kevin)
>
> As fallback/payload is compressed in bios.bin, I'm not sure what strings
> will provide.
> I did run strings on bios.bin (as well as looking at it in hex editor) and
> found nothing
> explicitly suggesting depthcharge (or u-boot for that matter) was the
> payload.  I made
> assumption u-boot was payload based on presence of u-boot.dtb file in
> bios.bin.

FWIW, you can 'cbfstool extract' the fallback/payload file from an
existing image. It'll write an ELF file that you should be familiar
with for inspection purposes (strings, readelf, objdump, etc).

>
> As has already been explained in this thread the coreboot build within
> chromiumos tree does not include
> building payload, this is a later step.  My work to date has been solely
> within confines of coreboot
> build tree and directly generating depthcharge, etc. so this deferred
> building of the payload came as a surprise.
>
> I welcome pointers to online documentation (either coreboot or chromiumos)
> that more clearly discuss coreboot inclusion within chromiumos build and
> development cycle.
>
> Thanks to all who have contributed to my current level of knowledge and I
> know I am just scratching the surface.
> Cheers,
> T.mike

-- 
coreboot mailing list: coreboot@coreboot.org
https://www.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] [coreboot-gerrit] Change in coreboot[master]: KBL: Update FSP headers - upgrade to FSP.2.0.0

[Aaron Durbin via coreboot]

Why can't I access this CL on gerrit, but I'm getting emails for it?

On Tue, Mar 28, 2017 at 10:10 AM, Subrata Banik (Code Review)
 wrote:
> Subrata Banik has posted comments on this change. ( 
> https://review.coreboot.org/19023 )
>
> Change subject: KBL: Update FSP headers - upgrade to FSP.2.0.0
> ..
>
>
> Patch Set 3:
>
> (2 comments)
>
> https://review.coreboot.org/#/c/19023/3/src/vendorcode/intel/fsp/fsp2_0/skykabylake/ConfigBlock/CpuConfigFspData.h
> File 
> src/vendorcode/intel/fsp/fsp2_0/skykabylake/ConfigBlock/CpuConfigFspData.h:
>
> PS3, Line 66:} Bits;
> : UINT32 Uint32[2];
> :   } CPU_CONFIG_FSP_DATA;
> why added space? don't we run clean up script?
>
>
> https://review.coreboot.org/#/c/19023/3/src/vendorcode/intel/fsp/fsp2_0/skykabylake/FspmUpd.h
> File src/vendorcode/intel/fsp/fsp2_0/skykabylake/FspmUpd.h:
>
> PS3, Line 41: #include 
> directory structure change
> ??
>
>
> --
> To view, visit https://review.coreboot.org/19023
> To unsubscribe, visit https://review.coreboot.org/settings
>
> Gerrit-MessageType: comment
> Gerrit-Change-Id: Id8ecea6fa5f4e7a72410f8da535ab9c4808b3482
> Gerrit-PatchSet: 3
> Gerrit-Project: coreboot
> Gerrit-Branch: master
> Gerrit-Owner: Balaji Manigandan 
> Gerrit-Reviewer: Barnali Sarkar 
> Gerrit-Reviewer: Naresh Solanki 
> Gerrit-Reviewer: Rizwan Qureshi 
> Gerrit-Reviewer: Subrata Banik 
> Gerrit-HasComments: Yes
>
> --
> coreboot-gerrit mailing list: coreboot-ger...@coreboot.org
> https://www.coreboot.org/mailman/listinfo/coreboot-gerrit

-- 
coreboot mailing list: coreboot@coreboot.org
https://www.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] Group demographics

[Aaron Durbin via coreboot]

On Fri, Mar 24, 2017 at 10:39 AM,   wrote:
> On 2017-03-24 08:23, ron minnich wrote:
>>
>> On Fri, Mar 24, 2017 at 8:14 AM  wrote:
>>
>>> Q.1) Are questions related to Coreboot + Payload that boots a
>>> Chromebook
>>> appropriate for this list or a ChromiumOS list?
>>
>>
>> of course!
>
>
> First the question and then the background.
>
> Q) Are there any shipping commercial chromebooks that use depthcharge as a
> payload?

All x86 system since 2013? All non-x86 systems a little after that
once the switch to coreboot.

>
> Background...
>  * coreboot tree only list 4 payload config files:  nyan, oak, purin, veyron
>  * chromium tree
> .../src/third_party/chromiumos-overlay/sys-boot/coreboot/files/configs/ all
> have CONFIG_PAYLOAD_NONE=y

We add payloads ourselves using cbfstool in the chromeos-bootimage ebuild.

>  * Google's recovery manifest (from linux_recovery.sh) can pull a recovery
> image for a specific product, I have yet to find depthcharge as a payload
>  * Obviously I haven't pulled all of the recovery images, but have looked at
> ~10
>  * those interested in recovery image, /usr/sbin/chromeos_firmwareupdate
> --sb_extract yields a bios.bin file that cbfstool can parse (i.e. is a
> coreboot.rom file)
>
> At this point I would be interested in any chromebook (even x86) that ships
> with depthcharge as a payload.
>
> Cheers,
> T.mike
>
> --
> coreboot mailing list: coreboot@coreboot.org
> https://www.coreboot.org/mailman/listinfo/coreboot

-- 
coreboot mailing list: coreboot@coreboot.org
https://www.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] Intel Leafhill/Apollolake wrong CBFS header address in coreboot.rom

[Aaron Durbin via coreboot]

On Sun, Mar 19, 2017 at 1:20 AM, Gailu Singh  wrote:
> Failing grub code
> --
> static void
> init_cbfsdisk (void)
> {
>   grub_uint32_t ptr;
>   struct cbfs_header *head;
>
>   ptr = *(grub_uint32_t *) 0xfffc;
>   head = (struct cbfs_header *) (grub_addr_t) ptr;
>   grub_dprintf ("cbfs", "head=%p\n", head);
>
>   /* coreboot current supports only ROMs <= 16 MiB. Bigger ROMs will
>  have problems as RCBA is 18 MiB below end of 32-bit typically,
>  so either memory map would have to be rearranged or we'd need to
> support
>  reading ROMs through controller directly.
>*/
>   if (ptr < 0xff00
>   || 0x - ptr < (grub_uint32_t) sizeof (*head) + 0xf
>   || !validate_head (head))
> return;
> --
>
> On Sun, Mar 19, 2017 at 11:47 AM, Gailu Singh  wrote:
>>
>> Hi Experts,
>>
>> On Intel Leafhill board grub fails to find cbfsdisk. We tried to debug and
>> found that cbfs header address validation fails.
>>
>> According to
>> https://github.com/mrnuke/coreboot/blob/master/documentation/cbfs.txt,
>> "A pointer to the location of the header will be located at offset -4 from
>> the end of the ROM. This translates to address 0xFFFC on a normal x86
>> system. The pointer will be to physical memory somewhere between -
>> 0xB000 and 0xFFF0".
>>
>>
>> We checked the coreboot.rom in hex editor and address in last 4 bytes is
>> all ones () as a result grub is not able to find cbfs header.
>>
>>
>> We have earlier used coreboot on baytrail and in the coreboot.rom cbfs
>> header address in last 4 byte was a valid pointer.
>>

This isn't going to fix your real problem but the value at 4 bytes
below 4GiB is actually an offset from that location:

https://review.coreboot.org:4430/cgit/coreboot.git/tree/src/lib/cbfs.c?id=refs/heads/master#n268

>>
>> What is the location grub can find cbfs header on this board?

The following 2 files detail the mapping of the spi part. The
'COREBOOT' region is where cbfs resides and where you'd find that
relative offset. However, you'd have to know where the FMAP is in
order to parse things.

src/mainboard/intel/leafhill/leafhill.16384.fmd
src/mainboard/intel/leafhill/leafhill.8192.fmd

The 'BIOS' region listed in the spi descriptor is what is memory
mapped into the cpu address space under 4GiB. That does not mean when
reading a SPI image like a file that the region has to be at the end
of the file.  There are linear translations you can do to go back and
forth between CPU mmio addresses and SPI addresses. Again, this
doesn't fix the current assumption in the code where it think it can
just dereference an int32_t pointer with a value of 0xfffc.

I don't know what the leaf hill descriptor indicates for the various
regions, but if you moved COREBOOT to the very top of the fmd file
(sans DEVICE_EXTENSION and UNUSED_HOLE) then you would be closer to
the current assumptions.

>>
>>
>
>
> --
> coreboot mailing list: coreboot@coreboot.org
> https://www.coreboot.org/mailman/listinfo/coreboot

-- 
coreboot mailing list: coreboot@coreboot.org
https://www.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] Some errors by compiling romstage (I am a newbie)

[Aaron Durbin via coreboot]

On Fri, Mar 3, 2017 at 11:23 AM, Maxim Gusev  wrote:
> Yes, Aaron. I tried to figure it all out.
> Some option doesn't works correctly. But the compiler and the linker are
> supporting these options.
> There is a log of "readelf -e imd_cbmem.o": http://pastebin.com/G5y36uU4

The above is indicating that -ffunction-sections and -fdata-sections
is not working. All your symbols are in .text and .data so when you
attempt to link it'll try to pull in everything which is why you are a
getting the link error.

> I also have a warning: cannot find entry symbol start; defaulting to
> 000100187000 before undefined refference errors (but I think it doesn't
> affect).
>
> I have also tried to compile the simple code by gcc:
> http://pastebin.com/AYnxTjZx (the compilation string, code and the readelf
> log).
> I'm not doing something wrong, because I don't see sections with the name of
> the function. There is the same with my compiler.
> Maybe these options work only in conjunction with others?

No. They work on all of our supported architectures as standalone options.

>
> If I will compile some sources of supported mainboard by coreboot, the
> readelf log and sections will be good with appropriate title
> (.text.function).
>
> Thanks a lot!
> Regards, Maxim
>
>
>
>  Original Message 
> Subject: Re: [coreboot] Some errors by compiling romstage (I am a newbie)
> Local Time: 3 Марта 2017 г. 5:54 вечера
> UTC Time: 3 Марта 2017 г. 14:54
> From: adur...@google.com
> To: Maxim Gusev , Coreboot 
>
> On Fri, Mar 3, 2017 at 8:37 AM, Maxim Gusev  wrote:
>> It doesn't work any case.
>> As I understood these options remove the unreferenced symbols, but I have
>> referenced symbols (the error is undefined reference).
>> The definition of the used functions is in the file that is missing at
>> this
>> stage but all works on other archs.
>>
>
> The symbol might be referenced in one function in that compilation
> unit, but if the symbol of the function using the undefined symbols is
> not referenced from any of the root symbols then it should be removed.
> The fact that it isn't suggests -gc-sections isn't working *or*
> -f(data|function)-sections isn't working. As I requested previously,
> readelf -e from one of the romstage .o files would confirm the latter.
> As it stands now I can't speculate as to what is happening because the
> code you are working on isn't published so I can't do anything beyond
> request the information I've already requested.
>
>>
>>
>>  Original Message 
>> Subject: Re: [coreboot] Some errors by compiling romstage (I am a newbie)
>> Local Time: 3 Марта 2017 г. 4:54 дня
>> UTC Time: 3 Марта 2017 г. 13:54
>> From: adur...@google.com
>> To: Maxim Gusev , Coreboot 
>>
>> On Fri, Mar 3, 2017 at 6:41 AM, Maxim Gusev  wrote:
>>> These options are supported.
>>> But the option -fno-pie is not supported (Don’t produce a position
>>> independent executable).
>>> Is it the reason of the fault?
>>
>>
>> I wouldn't think so. If you remove that option does it magically work?
>> From the errors you showed -gc-sections along with -fdata-sections and
>> -ffunction-sections would have removed the unreferenced symbols and
>> not cause a link error. To prove that -f(data|function)-sections are
>> working can you provide the readelf -e output from an intermediate .o
>> file you compiled for romstage?
>>
>>>
>>>
>>>
>>>  Original Message 
>>> Subject: Re: [coreboot] Some errors by compiling romstage (I am a newbie)
>>> Local Time: 2 Марта 2017 г. 6:01 вечера
>>> UTC Time: 2 Марта 2017 г. 15:01
>>> From: adur...@google.com
>>> To: Maxim Gusev 
>>> coreboot@coreboot.org 
>>>
>>> On Thu, Mar 2, 2017 at 8:33 AM, Maxim Gusev  wrote:
 Hello, Aaron!

 I am compiling sourses of my arch e2k.
 I have compiled bootblock with my sources. There aren't my sources in
 other
 stages. I have create arch directory and mainboard directory where the
 sources are located.



 Log:

 /home/maxim/coreboot/util/crossgcc/xgcc/bin/linux-ld: warning: cannot
 find
 entry symbol start; defaulting to 000100187000
 build/romstage/lib/imd_cbmem.o: In function `cbmem_add_bootmem':
 /home/maxim/coreboot/src/lib/imd_cbmem.c:287: undefined reference to
 `bootmem_add_range'
 build/romstage/lib/imd_cbmem.o: In function
 `cbmem_add_records_to_cbtable':
 /home/maxim/coreboot/src/lib/imd_cbmem.c:314: undefined reference to
 `lb_new_record'
 make: *** [build/cbfs/fallback/romstage.debug] Error 1

>>>
>>> Does your arch's compiler support -ffuncation-sections and
>>> -fdata-sections? As well as your linker supporting --gc-sections ? All
>>> the architectures we support have those flags. See Makefile.inc 

Re: [coreboot] Some errors by compiling romstage (I am a newbie)

[Aaron Durbin via coreboot]

On Fri, Mar 3, 2017 at 8:37 AM, Maxim Gusev  wrote:
> It doesn't work any case.
> As I understood these options remove the unreferenced symbols, but I have
> referenced symbols (the error is undefined reference).
> The definition of the used functions is in the file that is missing at this
> stage but all works on other archs.
>

The symbol might be referenced in one function in that compilation
unit, but if the symbol of the function using the undefined symbols is
not referenced from any of the root symbols then it should be removed.
The fact that it isn't suggests -gc-sections isn't working *or*
-f(data|function)-sections isn't working. As I requested previously,
readelf -e from one of the romstage .o files would confirm the latter.
As it stands now I can't speculate as to what is happening because the
code you are working on isn't published so I can't do anything beyond
request the information I've already requested.

>
>
>  Original Message 
> Subject: Re: [coreboot] Some errors by compiling romstage (I am a newbie)
> Local Time: 3 Марта 2017 г. 4:54 дня
> UTC Time: 3 Марта 2017 г. 13:54
> From: adur...@google.com
> To: Maxim Gusev , Coreboot 
>
> On Fri, Mar 3, 2017 at 6:41 AM, Maxim Gusev  wrote:
>> These options are supported.
>> But the option -fno-pie is not supported (Don’t produce a position
>> independent executable).
>> Is it the reason of the fault?
>
>
> I wouldn't think so. If you remove that option does it magically work?
> From the errors you showed -gc-sections along with -fdata-sections and
> -ffunction-sections would have removed the unreferenced symbols and
> not cause a link error. To prove that -f(data|function)-sections are
> working can you provide the readelf -e output from an intermediate .o
> file you compiled for romstage?
>
>>
>>
>>
>>  Original Message 
>> Subject: Re: [coreboot] Some errors by compiling romstage (I am a newbie)
>> Local Time: 2 Марта 2017 г. 6:01 вечера
>> UTC Time: 2 Марта 2017 г. 15:01
>> From: adur...@google.com
>> To: Maxim Gusev 
>> coreboot@coreboot.org 
>>
>> On Thu, Mar 2, 2017 at 8:33 AM, Maxim Gusev  wrote:
>>> Hello, Aaron!
>>>
>>> I am compiling sourses of my arch e2k.
>>> I have compiled bootblock with my sources. There aren't my sources in
>>> other
>>> stages. I have create arch directory and mainboard directory where the
>>> sources are located.
>>>
>>>
>>>
>>> Log:
>>>
>>> /home/maxim/coreboot/util/crossgcc/xgcc/bin/linux-ld: warning: cannot
>>> find
>>> entry symbol start; defaulting to 000100187000
>>> build/romstage/lib/imd_cbmem.o: In function `cbmem_add_bootmem':
>>> /home/maxim/coreboot/src/lib/imd_cbmem.c:287: undefined reference to
>>> `bootmem_add_range'
>>> build/romstage/lib/imd_cbmem.o: In function
>>> `cbmem_add_records_to_cbtable':
>>> /home/maxim/coreboot/src/lib/imd_cbmem.c:314: undefined reference to
>>> `lb_new_record'
>>> make: *** [build/cbfs/fallback/romstage.debug] Error 1
>>>
>>
>> Does your arch's compiler support -ffuncation-sections and
>> -fdata-sections? As well as your linker supporting --gc-sections ? All
>> the architectures we support have those flags. See Makefile.inc which
>> provides those in CFLAGS_common and LDFLAGS_common. That support
>> allows us to not sprinkle #ifdef's all around in the code when the
>> same source file is compiled for different stages.
>>
>>>
>>>
>>>  Original Message 
>>> Subject: Re: [coreboot] Some errors by compiling romstage (I am a newbie)
>>> Local Time: 2 Марта 2017 г. 5:22 вечера
>>> UTC Time: 2 Марта 2017 г. 14:22
>>> From: adur...@google.com
>>> To: Maxim Gusev 
>>> coreboot@coreboot.org 
>>>
>>> On Thu, Mar 2, 2017 at 7:24 AM, Maxim Gusev via coreboot
>>>  wrote:
 Hi everbody!

 I have a question. Very hope for your help.

 When I am compiling the romstage there are 2 errors by the linker:
 Undefined refference to 'bootmem_add_range'
 Undefined refference to 'lb_new_record' in the imd_cbmem.c file (it is
 included in src/lib/Makefile.inc romstage).

 The definitions of these functions are in lib/bootmem.c and
 lib/coreboot_table.c accordingly.
 But I can't see the inclusion of these files in romstage in
 src/Makefile.inc
 (only in ramstage):
 ramstage-y += bootmem.c
 ramstage-y += coreboot_table.c

 How to solve this problem?
 The inclusion of these files produces a number of other errors, but
 nowhere
 in the code no one does it? Why only I am having this error.
>>>
>>>
>>> What board are you building? Are you working on local patches to your
>>> setup only? What does the build log indicate?
>>>

 In General, I don't even need these stages (romstage and ramstage) - I
 want
 to check the performance on 

Re: [coreboot] Some errors by compiling romstage (I am a newbie)

[Aaron Durbin via coreboot]

On Fri, Mar 3, 2017 at 6:41 AM, Maxim Gusev  wrote:
> These options are supported.
> But the option -fno-pie is not supported (Don’t produce a position
> independent executable).
> Is it the reason of the fault?


I wouldn't think so. If you remove that option does it magically work?
From the errors you showed -gc-sections along with -fdata-sections and
-ffunction-sections would have removed the unreferenced symbols and
not cause a link error. To prove that -f(data|function)-sections are
working can you provide the readelf -e output from an intermediate .o
file you compiled for romstage?

>
>
>
>  Original Message 
> Subject: Re: [coreboot] Some errors by compiling romstage (I am a newbie)
> Local Time: 2 Марта 2017 г. 6:01 вечера
> UTC Time: 2 Марта 2017 г. 15:01
> From: adur...@google.com
> To: Maxim Gusev 
> coreboot@coreboot.org 
>
> On Thu, Mar 2, 2017 at 8:33 AM, Maxim Gusev  wrote:
>> Hello, Aaron!
>>
>> I am compiling sourses of my arch e2k.
>> I have compiled bootblock with my sources. There aren't my sources in
>> other
>> stages. I have create arch directory and mainboard directory where the
>> sources are located.
>>
>>
>>
>> Log:
>>
>> /home/maxim/coreboot/util/crossgcc/xgcc/bin/linux-ld: warning: cannot find
>> entry symbol start; defaulting to 000100187000
>> build/romstage/lib/imd_cbmem.o: In function `cbmem_add_bootmem':
>> /home/maxim/coreboot/src/lib/imd_cbmem.c:287: undefined reference to
>> `bootmem_add_range'
>> build/romstage/lib/imd_cbmem.o: In function
>> `cbmem_add_records_to_cbtable':
>> /home/maxim/coreboot/src/lib/imd_cbmem.c:314: undefined reference to
>> `lb_new_record'
>> make: *** [build/cbfs/fallback/romstage.debug] Error 1
>>
>
> Does your arch's compiler support -ffuncation-sections and
> -fdata-sections? As well as your linker supporting --gc-sections ? All
> the architectures we support have those flags. See Makefile.inc which
> provides those in CFLAGS_common and LDFLAGS_common. That support
> allows us to not sprinkle #ifdef's all around in the code when the
> same source file is compiled for different stages.
>
>>
>>
>>  Original Message 
>> Subject: Re: [coreboot] Some errors by compiling romstage (I am a newbie)
>> Local Time: 2 Марта 2017 г. 5:22 вечера
>> UTC Time: 2 Марта 2017 г. 14:22
>> From: adur...@google.com
>> To: Maxim Gusev 
>> coreboot@coreboot.org 
>>
>> On Thu, Mar 2, 2017 at 7:24 AM, Maxim Gusev via coreboot
>>  wrote:
>>> Hi everbody!
>>>
>>> I have a question. Very hope for your help.
>>>
>>> When I am compiling the romstage there are 2 errors by the linker:
>>> Undefined refference to 'bootmem_add_range'
>>> Undefined refference to 'lb_new_record' in the imd_cbmem.c file (it is
>>> included in src/lib/Makefile.inc romstage).
>>>
>>> The definitions of these functions are in lib/bootmem.c and
>>> lib/coreboot_table.c accordingly.
>>> But I can't see the inclusion of these files in romstage in
>>> src/Makefile.inc
>>> (only in ramstage):
>>> ramstage-y += bootmem.c
>>> ramstage-y += coreboot_table.c
>>>
>>> How to solve this problem?
>>> The inclusion of these files produces a number of other errors, but
>>> nowhere
>>> in the code no one does it? Why only I am having this error.
>>
>>
>> What board are you building? Are you working on local patches to your
>> setup only? What does the build log indicate?
>>
>>>
>>> In General, I don't even need these stages (romstage and ramstage) - I
>>> want
>>> to check the performance on real hardware the work of the bootblock, but
>>> the
>>> toolchain requires me to compile other stages. And the error occurs even
>>> not
>>> in my code, but my ignorance.
>>>
>>> Thanks a lot!
>>> Regards, Maxim
>>>
>>>
>>>
>>>
>>> --
>>> coreboot mailing list: coreboot@coreboot.org
>>> https://www.coreboot.org/mailman/listinfo/coreboot
>>
>>
>
>

-- 
coreboot mailing list: coreboot@coreboot.org
https://www.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] Some errors by compiling romstage (I am a newbie)

[Aaron Durbin via coreboot]

On Thu, Mar 2, 2017 at 8:33 AM, Maxim Gusev  wrote:
> Hello, Aaron!
>
> I am compiling sourses of my arch e2k.
> I have compiled bootblock with my sources. There aren't my sources in other
> stages. I have create arch directory and mainboard directory where the
> sources are located.
>
>
>
> Log:
>
> /home/maxim/coreboot/util/crossgcc/xgcc/bin/linux-ld: warning: cannot find
> entry symbol start; defaulting to 000100187000
> build/romstage/lib/imd_cbmem.o: In function `cbmem_add_bootmem':
> /home/maxim/coreboot/src/lib/imd_cbmem.c:287: undefined reference to
> `bootmem_add_range'
> build/romstage/lib/imd_cbmem.o: In function `cbmem_add_records_to_cbtable':
> /home/maxim/coreboot/src/lib/imd_cbmem.c:314: undefined reference to
> `lb_new_record'
> make: *** [build/cbfs/fallback/romstage.debug] Error 1
>

Does your arch's compiler support -ffuncation-sections and
-fdata-sections? As well as your linker supporting --gc-sections ? All
the architectures we support have those flags. See Makefile.inc which
provides those in CFLAGS_common and LDFLAGS_common. That support
allows us to not sprinkle #ifdef's all around in the code when the
same source file is compiled for different stages.

>
>
>  Original Message 
> Subject: Re: [coreboot] Some errors by compiling romstage (I am a newbie)
> Local Time: 2 Марта 2017 г. 5:22 вечера
> UTC Time: 2 Марта 2017 г. 14:22
> From: adur...@google.com
> To: Maxim Gusev 
> coreboot@coreboot.org 
>
> On Thu, Mar 2, 2017 at 7:24 AM, Maxim Gusev via coreboot
>  wrote:
>> Hi everbody!
>>
>> I have a question. Very hope for your help.
>>
>> When I am compiling the romstage there are 2 errors by the linker:
>> Undefined refference to 'bootmem_add_range'
>> Undefined refference to 'lb_new_record' in the imd_cbmem.c file (it is
>> included in src/lib/Makefile.inc romstage).
>>
>> The definitions of these functions are in lib/bootmem.c and
>> lib/coreboot_table.c accordingly.
>> But I can't see the inclusion of these files in romstage in
>> src/Makefile.inc
>> (only in ramstage):
>> ramstage-y += bootmem.c
>> ramstage-y += coreboot_table.c
>>
>> How to solve this problem?
>> The inclusion of these files produces a number of other errors, but
>> nowhere
>> in the code no one does it? Why only I am having this error.
>
>
> What board are you building? Are you working on local patches to your
> setup only? What does the build log indicate?
>
>>
>> In General, I don't even need these stages (romstage and ramstage) - I
>> want
>> to check the performance on real hardware the work of the bootblock, but
>> the
>> toolchain requires me to compile other stages. And the error occurs even
>> not
>> in my code, but my ignorance.
>>
>> Thanks a lot!
>> Regards, Maxim
>>
>>
>>
>>
>> --
>> coreboot mailing list: coreboot@coreboot.org
>> https://www.coreboot.org/mailman/listinfo/coreboot
>
>

-- 
coreboot mailing list: coreboot@coreboot.org
https://www.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] Some errors by compiling romstage (I am a newbie)

[Aaron Durbin via coreboot]

On Thu, Mar 2, 2017 at 7:24 AM, Maxim Gusev via coreboot
 wrote:
> Hi everbody!
>
> I have a question. Very hope for your help.
>
> When I am compiling the romstage there are 2 errors by the linker:
> Undefined refference to 'bootmem_add_range'
> Undefined refference to 'lb_new_record' in the imd_cbmem.c file (it is
> included in src/lib/Makefile.inc romstage).
>
> The definitions of these functions are in lib/bootmem.c and
> lib/coreboot_table.c accordingly.
> But I can't see the inclusion of these files in romstage in src/Makefile.inc
> (only in ramstage):
> ramstage-y += bootmem.c
> ramstage-y += coreboot_table.c
>
> How to solve this problem?
> The inclusion of these files produces a number of other errors, but nowhere
> in the code no one does it? Why only I am having this error.


What board are you building? Are you working on local patches to your
setup only? What does the build log indicate?

>
> In General, I don't even need these stages (romstage and ramstage) - I want
> to check the performance on real hardware the work of the bootblock, but the
> toolchain requires me to compile other stages. And the error occurs even not
> in my code, but my ignorance.
>
> Thanks a lot!
> Regards, Maxim
>
>
>
>
> --
> coreboot mailing list: coreboot@coreboot.org
> https://www.coreboot.org/mailman/listinfo/coreboot

-- 
coreboot mailing list: coreboot@coreboot.org
https://www.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] Dont filter supported CPUs on a mainboard by the CPUID

[Aaron Durbin via coreboot]

On Fri, Feb 24, 2017 at 5:04 AM,   wrote:
> Yes, this die() is what i mean. Try to get maybe some functionality is i
> think better then just stopping there and providing zero functionality.
>
> I also know, that there is a message when the CPUID is not known. Its about
> the die() afterwards.

Patches always welcome. Did you try removing the die() and seeing if
things actually booted?

>
>
> 23. Feb 2017 14:31 by coreboot@coreboot.org:
>
> On Thu, Feb 23, 2017 at 2:39 AM, Nico Huber  wrote:
>
> On 23.02.2017 00:07, i1w5d7gf38...@tutanota.com wrote:
>
> There is a Filter to stop booting when the CPUID is not in a list of
> supported CPUs. This filter does not make sense in the real world usage.
>
>
> It's not a filter. It's a measure to know which code to run for which
> CPU. Please dig a little deeper before making such useless complaints.
>
>
> To add to Nico's point: the cpuid list is a way to bind code code to
> run for certain devices -- including CPUs. If the cpuid is not listed
> then the match on device->code to run is not met. Therefore, the code
> necessary to make that CPU work won't ever be ran. src/arch/x86/cpu.c
> has the cpu driver binding. And there already is message printed. See
> the callers of set_cpu_ops() in that file. The issue is that we die()
> when no match is found. We could attempt to boot further, but there's
> no guarantee it'd actually succeed.
>
>
> Nico
>
> --
> coreboot mailing list: coreboot@coreboot.org
> https://www.coreboot.org/mailman/listinfo/coreboot
>
>
> --
> coreboot mailing list: coreboot@coreboot.org
> https://www.coreboot.org/mailman/listinfo/coreboot

-- 
coreboot mailing list: coreboot@coreboot.org
https://www.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] Dont filter supported CPUs on a mainboard by the CPUID

[Aaron Durbin via coreboot]

On Thu, Feb 23, 2017 at 2:39 AM, Nico Huber  wrote:
> On 23.02.2017 00:07, i1w5d7gf38...@tutanota.com wrote:
>
>> There is a Filter to stop booting when the CPUID is not in a list of
>> supported CPUs. This filter does not make sense in the real world usage.
>
> It's not a filter. It's a measure to know which code to run for which
> CPU. Please dig a little deeper before making such useless complaints.

To add to Nico's point: the cpuid list is a way to bind code code to
run for certain devices -- including CPUs. If the cpuid is not listed
then the match on device->code to run is not met. Therefore, the code
necessary to make that CPU work won't ever be ran. src/arch/x86/cpu.c
has the cpu driver binding. And there already is message printed. See
the callers of set_cpu_ops() in that file. The issue is that we die()
when no match is found. We could attempt to boot further, but there's
no guarantee it'd actually succeed.

>
> Nico
>
> --
> coreboot mailing list: coreboot@coreboot.org
> https://www.coreboot.org/mailman/listinfo/coreboot

-- 
coreboot mailing list: coreboot@coreboot.org
https://www.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] [VERY IMPORTANT] Announcement regarding Apollo Lake Coreboot building

[Aaron Durbin via coreboot]

On Wed, Feb 22, 2017 at 10:18 AM, Zoran Stojsavljevic
 wrote:
> Aaron,
>
> Not that I am trying to be pest/bad guy. Please, believe me on this. Just
> about the simple logic, which SHOULD NOT be deniable!
>
> I did what I know about Coreboot, hands on, from 3.3 years ago. Then, I
> built the VERY first Emerald Lake 2 (CCG CRB) -> Cougar Canyon 2 CRB as
> payload SeaBIOS, and WIN 8.0 32bit. I was really amazed. Then.
>
> And I read much more these days, and a bit emailed with Martin (forth/back),
> so Martin can give me a jump start. And then I read more. And more. And for
> 5 full days I was doing this exercise (with lot of pain).
>
> So, I'll quote you:
>
>> That file is the FSP blob. Nothing more. As Nico pointed out that is
>> something completely different from the flash descriptor. The flash
>> descriptor can be obtained from the original released BIOS or you have
>> to generate it using Intel's FIT tool.
>
> Please, guide me through this process. Or point to some documents about this
> process I can read about?

IIRC, FIT is provided by Intel to its customers under NDA. You'll have
to contact your Intel rep for that. It's quite the barrier to entry
for using these devices, but that's a policy decision from Intel.

Or you can take a previously released bios for this board and do
similar as the instructions on the Minnow Max page:
http://elinux.org/Minnowboard:MinnowMaxCoreboot#TXE_and_SPI_descriptor

Note, TXE/CSE on apollolake does not have its own region in the flash.
It's in something intel calls IFWI and has its own new format that
lives in the "BIOS" region. There's a tool (util/cbfstool/ifwitool.c)
which takes an existing image with the IFWI and makes it work with
coreboot's implementation/support for apollolake.

>
> Thank you,
> Zoran
>
> On Wed, Feb 22, 2017 at 5:05 PM, Aaron Durbin  wrote:
>>
>> On Wed, Feb 22, 2017 at 10:01 AM, Zoran Stojsavljevic
>>  wrote:
>> > I can admit my errors:
>> >
>> > This is what I have:
>> >
>> > user@localhost FspBin]$ pwd
>> >
>> > /home/user/projects/coreboot/coreboot/APL-I_FSP/ApolloLakeFspBinPkg/FspBin
>> > [user@localhost FspBin]$ ls -al
>> > total 672
>> > drwxr-xr-x. 2 user user   4096 Feb 11 12:19 .
>> > drwxr-xr-x. 6 user user   4096 Feb 11 12:19 ..
>> > -rw-r--r--. 1 user user 136832 Feb 11 12:19 ApolloLakeFsp.bsf
>> > -rw-r--r--. 1 user user 540672 Feb 11 12:19 ApolloLakeFsp.fd
>> > [user@localhost FspBin]$
>> >
>> > I use one in RED.
>> >
>> > Need the clarification. Please, do it for me.
>>
>> That file is the FSP blob. Nothing more. As Nico pointed out that is
>> something completely different from the flash descriptor. The flash
>> descriptor can be obtained from the original released BIOS or you have
>> to generate it using Intel's FIT tool.
>>
>> >
>> > Zoran
>> >
>> > On Wed, Feb 22, 2017 at 4:56 PM, Nico Huber 
>> > wrote:
>> >>
>> >> On 22.02.2017 08:12, Zoran Stojsavljevic wrote:
>> >> > Hello to community,
>> >> >
>> >> > I finally, after 3 days of additional very hard struggle, found out
>> >> > why
>> >> > I
>> >> > have (while I am in the last stage of building CBFS) nonsense while
>> >> > building APL-I Coreboot coreboot.rom?!
>> >> >
>> >> > Please, read carefully this announcement.
>> >> >
>> >> > For last three days I came to hard stop because of this failure:
>> >> >
>> >> > Just quick look into the final failure (all passed, but last stage -
>> >> > IFD
>> >> > failed):
>> >> >
>> >> > Compile IFDTOOL
>> >> > HOSTCC util/ifdfake/ifdfake
>> >> > DD Adding Intel Firmware Descriptor
>> >> > IFDTOOLUnlocking Management Engine
>> >> > File build/coreboot.pre is 8388608 bytes
>> >> > No Flash Descriptor found in this image
>> >> > *src/southbridge/intel/common/firmware/Makefile.inc:50: recipe for
>> >> > target
>> >> > 'add_intel_firmware' failed*
>> >> > *make: *** [add_intel_firmware] Error 1*
>> >> > [user@localhost coreboot]$
>> >> >
>> >> > At first, I suspect that culprit my .config file, but I have checked
>> >> > it
>> >> > several times (maybe > dozen), and I could NOT find any problem with
>> >> > it
>> >> > (except minor doubts).
>> >> >
>> >> > Then I switched to inspect -southbridge- setup, but these is none,
>> >> > since
>> >> > (simplified explanation/view) APL-I is SoC.
>> >> >
>> >> > The next phase was to inspect
>> >> > *src/southbridge/intel/common/firmware/Makefile.inc* , but there
>> >> > (although
>> >> > my make scripting is rusty) I could NOT find any problem...
>> >> >
>> >> > Finally, somewhere around 2:00 AM I noticed/determined the root cause
>> >> > of
>> >> > the problem: the util/ifdtool/ifdtool.c, line:
>> >> >   if (*(uint32_t *) (image + i) == *0x0FF0A55A*) {
>> >> >
>> >> > YET another INTEL IOTG PED hidden road bomb: the latest APL-I FSP:
>> >> > APL-I_
>> >> > FSP/ApolloLakeFspBinPkg/FspBin/ApolloLakeFsp.fd does NOT have pattern
>> >> > *0x0FF0A55A* 

Re: [coreboot] [VERY IMPORTANT] Announcement regarding Apollo Lake Coreboot building

[Aaron Durbin via coreboot]

On Wed, Feb 22, 2017 at 10:01 AM, Zoran Stojsavljevic
 wrote:
> I can admit my errors:
>
> This is what I have:
>
> user@localhost FspBin]$ pwd
> /home/user/projects/coreboot/coreboot/APL-I_FSP/ApolloLakeFspBinPkg/FspBin
> [user@localhost FspBin]$ ls -al
> total 672
> drwxr-xr-x. 2 user user   4096 Feb 11 12:19 .
> drwxr-xr-x. 6 user user   4096 Feb 11 12:19 ..
> -rw-r--r--. 1 user user 136832 Feb 11 12:19 ApolloLakeFsp.bsf
> -rw-r--r--. 1 user user 540672 Feb 11 12:19 ApolloLakeFsp.fd
> [user@localhost FspBin]$
>
> I use one in RED.
>
> Need the clarification. Please, do it for me.

That file is the FSP blob. Nothing more. As Nico pointed out that is
something completely different from the flash descriptor. The flash
descriptor can be obtained from the original released BIOS or you have
to generate it using Intel's FIT tool.

>
> Zoran
>
> On Wed, Feb 22, 2017 at 4:56 PM, Nico Huber  wrote:
>>
>> On 22.02.2017 08:12, Zoran Stojsavljevic wrote:
>> > Hello to community,
>> >
>> > I finally, after 3 days of additional very hard struggle, found out why
>> > I
>> > have (while I am in the last stage of building CBFS) nonsense while
>> > building APL-I Coreboot coreboot.rom?!
>> >
>> > Please, read carefully this announcement.
>> >
>> > For last three days I came to hard stop because of this failure:
>> >
>> > Just quick look into the final failure (all passed, but last stage - IFD
>> > failed):
>> >
>> > Compile IFDTOOL
>> > HOSTCC util/ifdfake/ifdfake
>> > DD Adding Intel Firmware Descriptor
>> > IFDTOOLUnlocking Management Engine
>> > File build/coreboot.pre is 8388608 bytes
>> > No Flash Descriptor found in this image
>> > *src/southbridge/intel/common/firmware/Makefile.inc:50: recipe for
>> > target
>> > 'add_intel_firmware' failed*
>> > *make: *** [add_intel_firmware] Error 1*
>> > [user@localhost coreboot]$
>> >
>> > At first, I suspect that culprit my .config file, but I have checked it
>> > several times (maybe > dozen), and I could NOT find any problem with it
>> > (except minor doubts).
>> >
>> > Then I switched to inspect -southbridge- setup, but these is none, since
>> > (simplified explanation/view) APL-I is SoC.
>> >
>> > The next phase was to inspect
>> > *src/southbridge/intel/common/firmware/Makefile.inc* , but there
>> > (although
>> > my make scripting is rusty) I could NOT find any problem...
>> >
>> > Finally, somewhere around 2:00 AM I noticed/determined the root cause of
>> > the problem: the util/ifdtool/ifdtool.c, line:
>> >   if (*(uint32_t *) (image + i) == *0x0FF0A55A*) {
>> >
>> > YET another INTEL IOTG PED hidden road bomb: the latest APL-I FSP:
>> > APL-I_
>> > FSP/ApolloLakeFspBinPkg/FspBin/ApolloLakeFsp.fd does NOT have pattern
>> > *0x0FF0A55A* embedded in it (I have checked with HxD WIN tool).
>>
>> Looks like this [VERY IMPORTANT] Announcement is about you, confusing
>> two very different concepts. FSP is a binary program run by coreboot
>> and has nothing in common with the Intel Firmware Descriptor. It's
>> called *.fd for some reason I don't know, but I'm pretty sure it's
>> another binary. The Firmware Descriptor describes some flash parameters
>> and soft straps. It's just data, no program. You only need it as an OEM
>> to build a full ROM image for a new system. If you have a system that
>> already runs another firmware, you can just keep the existing descriptor
>> in place.
>>
>> Nico
>
>
>
> --
> coreboot mailing list: coreboot@coreboot.org
> https://www.coreboot.org/mailman/listinfo/coreboot

-- 
coreboot mailing list: coreboot@coreboot.org
https://www.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] [VERY IMPORTANT] Announcement regarding Apollo Lake Coreboot building

[Aaron Durbin via coreboot]

On Wed, Feb 22, 2017 at 9:56 AM, Nico Huber  wrote:
> On 22.02.2017 08:12, Zoran Stojsavljevic wrote:
>> Hello to community,
>>
>> I finally, after 3 days of additional very hard struggle, found out why I
>> have (while I am in the last stage of building CBFS) nonsense while
>> building APL-I Coreboot coreboot.rom?!
>>
>> Please, read carefully this announcement.
>>
>> For last three days I came to hard stop because of this failure:
>>
>> Just quick look into the final failure (all passed, but last stage - IFD
>> failed):
>>
>> Compile IFDTOOL
>> HOSTCC util/ifdfake/ifdfake
>> DD Adding Intel Firmware Descriptor
>> IFDTOOLUnlocking Management Engine
>> File build/coreboot.pre is 8388608 bytes
>> No Flash Descriptor found in this image
>> *src/southbridge/intel/common/firmware/Makefile.inc:50: recipe for target
>> 'add_intel_firmware' failed*
>> *make: *** [add_intel_firmware] Error 1*
>> [user@localhost coreboot]$
>>
>> At first, I suspect that culprit my .config file, but I have checked it
>> several times (maybe > dozen), and I could NOT find any problem with it
>> (except minor doubts).
>>
>> Then I switched to inspect -southbridge- setup, but these is none, since
>> (simplified explanation/view) APL-I is SoC.
>>
>> The next phase was to inspect
>> *src/southbridge/intel/common/firmware/Makefile.inc* , but there (although
>> my make scripting is rusty) I could NOT find any problem...
>>
>> Finally, somewhere around 2:00 AM I noticed/determined the root cause of
>> the problem: the util/ifdtool/ifdtool.c, line:
>>   if (*(uint32_t *) (image + i) == *0x0FF0A55A*) {
>>
>> YET another INTEL IOTG PED hidden road bomb: the latest APL-I FSP: APL-I_
>> FSP/ApolloLakeFspBinPkg/FspBin/ApolloLakeFsp.fd does NOT have pattern
>> *0x0FF0A55A* embedded in it (I have checked with HxD WIN tool).
>
> Looks like this [VERY IMPORTANT] Announcement is about you, confusing
> two very different concepts. FSP is a binary program run by coreboot
> and has nothing in common with the Intel Firmware Descriptor. It's
> called *.fd for some reason I don't know, but I'm pretty sure it's
> another binary. The Firmware Descriptor describes some flash parameters
> and soft straps. It's just data, no program. You only need it as an OEM
> to build a full ROM image for a new system. If you have a system that
> already runs another firmware, you can just keep the existing descriptor
> in place.

I missed that bit. Yes, the .fd is just the extension FSP decided to
use for their blob.

>
> Nico
>
> --
> coreboot mailing list: coreboot@coreboot.org
> https://www.coreboot.org/mailman/listinfo/coreboot

-- 
coreboot mailing list: coreboot@coreboot.org
https://www.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] [VERY IMPORTANT] Announcement regarding Apollo Lake Coreboot building

[Aaron Durbin via coreboot]

On Wed, Feb 22, 2017 at 9:36 AM, Zoran Stojsavljevic <
zoran.stojsavlje...@gmail.com> wrote:

> > Still not enough information.  Good luck with your problem.
>
> I have no problem that you believe to INTEL IOTG 100x more than me. ;-)
>

That has nothing to do with it. You have not presented enough information
for me to actually help. That's the crux of the current situation.


>
> Good luck to you, Google, with INTEL IOTG PED dept. problem (please, do
> not input to me other people problems, could I ask?).
>
> And, you need to work, and try to reproduce this problem, because I DO
> (certainly) know that another people trying to build APL-I Coreboot have
> this problem?! ;-)
>

I don't know what PED dept. is at Intel. I also haven't been working with
IOTG so it's not clear to me what APL-I device you are trying to use or its
characteristics. I was attempting to help with the situation, but as you
are purposefully being opaque about settings it's impossible for me to
help.



>
> Thank you,
> Zoran
>
> On Wed, Feb 22, 2017 at 4:29 PM, Aaron Durbin  wrote:
>
>>
>>
>> On Wed, Feb 22, 2017 at 9:25 AM, Zoran Stojsavljevic <
>> zoran.stojsavlje...@gmail.com> wrote:
>>
>>> Not possible to share with you the details of my .config, until you
>>> understand that you need to investigate this problem as well. :-)
>>>
>>
>> I'm not sure I understand what you are saying. You are asking for help
>> but won't share more details? If that's the case, then good luck as I can't
>> be much help. You telling me to investigate something doesn't make me want
>> to continue helping in the slightest.
>>
>>
>>>
>>> CLI transcript follows:
>>>
>>> [user@localhost coreboot]$ pwd
>>> /home/user/projects/coreboot/coreboot
>>> [user@localhost coreboot]$ cat .config | grep FIRMWARE
>>> CONFIG_CPU_INTEL_FIRMWARE_INTERFACE_TABLE=y
>>> CONFIG_HAVE_INTEL_FIRMWARE=y
>>>
>>
>> Still not enough information.  Good luck with your problem.
>>
>>
>>> [user@localhost coreboot]$
>>> ___
>>>
>>> [user@localhost firmware]$ pwd
>>> /home/user/projects/coreboot/coreboot/src/southbridge/intel/
>>> common/firmware
>>> [user@localhost firmware]$ emacs Kconfig &
>>>
>>> Beginning of the file: Kconfig?
>>>
>>> *config HAVE_INTEL_FIRMWARE*
>>> * bool*
>>> * help*
>>> *  Chipset uses the Intel Firmware Descriptor to describe the*
>>> *  layout of the SPI ROM chip.*
>>>
>>> *if HAVE_INTEL_FIRMWARE*
>>>
>>> *comment "Intel Firmware"*
>>>
>>> *config HAVE_IFD_BIN*
>>>
>>> Zoran
>>>
>>> On Wed, Feb 22, 2017 at 4:13 PM, Aaron Durbin 
>>> wrote:
>>>


 On Wed, Feb 22, 2017 at 9:08 AM, Zoran Stojsavljevic <
 zoran.stojsavlje...@gmail.com> wrote:

> You mean, this one (in *RED*)?
>
> [user@localhost coreboot]$ cat .config | grep SPI
> CONFIG_BOOT_DEVICE_SPI_FLASH_BUS=0
> # CONFIG_TPM_ON_FAST_SPI is not set
> # CONFIG_SPI_FLASH_INCLUDE_ALL_DRIVERS is not set
> CONFIG_SOC_INTEL_COMMON_SPI_FLASH_PROTECT=y
> # CONFIG_BOOTBLOCK_DEBUG_SPINLOOP is not set
> # CONFIG_VERSTAGE_DEBUG_SPINLOOP is not set
> # CONFIG_ROMSTAGE_DEBUG_SPINLOOP is not set
> *CONFIG_SPI_FLASH=y*
> CONFIG_BOOT_DEVICE_SPI_FLASH_RW_NOMMAP=y
> CONFIG_BOOT_DEVICE_SPI_FLASH_RW_NOMMAP_EARLY=y
> # CONFIG_SPI_FLASH_SMM is not set
> # CONFIG_SPI_FLASH_NO_FAST_READ is not set
> # CONFIG_SPI_FLASH_FAST_READ_DUAL_OUTPUT_3B is not set
> # CONFIG_SPI_FLASH_HAS_VOLATILE_GROUP is not set
> # CONFIG_HAVE_SPI_CONSOLE_SUPPORT is not set
> # CONFIG_BOOT_DEVICE_NOT_SPI_FLASH is not set
> *CONFIG_BOOT_DEVICE_SPI_FLASH=y*
> # CONFIG_HAVE_ROMSTAGE_CONSOLE_SPINLOCK is not set
> # CONFIG_HAVE_ROMSTAGE_NVRAM_CBFS_SPINLOCK is not set
> # CONFIG_HAVE_ROMSTAGE_MICROCODE_CBFS_SPINLOCK is not set
> # CONFIG_DEBUG_SPI_FLASH is not set
> [user@localhost coreboot]$
> Which one (but, anyway, I think you are on the wrong mental tread,
> unless *you explicitly prove to me that I am wrong*)? [image: Inline
> image 1]
>
>
 Where are you setting the descriptor to use during the build? Those
 settings highlighted in red have nothing to do with the flash descriptor
 settings. Please look in src/southbridge/intel/common/firmware/Kconfig
 for that list. Also, without the full details of your config it's
 impossible to know what you are or aren't doing.



> Zoran
>
> On Wed, Feb 22, 2017 at 3:39 PM, Aaron Durbin 
> wrote:
>
>> On Wed, Feb 22, 2017 at 1:12 AM, Zoran Stojsavljevic
>>  wrote:
>> > Hello to community,
>> >
>> > I finally, after 3 days of additional very hard struggle, found out
>> why I
>> > have (while I am in the last stage of building CBFS) nonsense while
>> building
>> > APL-I Coreboot coreboot.rom?!
>> >
>> > Please, read carefully this announcement.
>> >
>> > For last three days I came to hard stop 

Re: [coreboot] [VERY IMPORTANT] Announcement regarding Apollo Lake Coreboot building

[Aaron Durbin via coreboot]

On Wed, Feb 22, 2017 at 9:25 AM, Zoran Stojsavljevic <
zoran.stojsavlje...@gmail.com> wrote:

> Not possible to share with you the details of my .config, until you
> understand that you need to investigate this problem as well. :-)
>

I'm not sure I understand what you are saying. You are asking for help but
won't share more details? If that's the case, then good luck as I can't be
much help. You telling me to investigate something doesn't make me want to
continue helping in the slightest.


>
> CLI transcript follows:
>
> [user@localhost coreboot]$ pwd
> /home/user/projects/coreboot/coreboot
> [user@localhost coreboot]$ cat .config | grep FIRMWARE
> CONFIG_CPU_INTEL_FIRMWARE_INTERFACE_TABLE=y
> CONFIG_HAVE_INTEL_FIRMWARE=y
>

Still not enough information.  Good luck with your problem.


> [user@localhost coreboot]$
> ___
>
> [user@localhost firmware]$ pwd
> /home/user/projects/coreboot/coreboot/src/southbridge/
> intel/common/firmware
> [user@localhost firmware]$ emacs Kconfig &
>
> Beginning of the file: Kconfig?
>
> *config HAVE_INTEL_FIRMWARE*
> * bool*
> * help*
> *  Chipset uses the Intel Firmware Descriptor to describe the*
> *  layout of the SPI ROM chip.*
>
> *if HAVE_INTEL_FIRMWARE*
>
> *comment "Intel Firmware"*
>
> *config HAVE_IFD_BIN*
>
> Zoran
>
> On Wed, Feb 22, 2017 at 4:13 PM, Aaron Durbin  wrote:
>
>>
>>
>> On Wed, Feb 22, 2017 at 9:08 AM, Zoran Stojsavljevic <
>> zoran.stojsavlje...@gmail.com> wrote:
>>
>>> You mean, this one (in *RED*)?
>>>
>>> [user@localhost coreboot]$ cat .config | grep SPI
>>> CONFIG_BOOT_DEVICE_SPI_FLASH_BUS=0
>>> # CONFIG_TPM_ON_FAST_SPI is not set
>>> # CONFIG_SPI_FLASH_INCLUDE_ALL_DRIVERS is not set
>>> CONFIG_SOC_INTEL_COMMON_SPI_FLASH_PROTECT=y
>>> # CONFIG_BOOTBLOCK_DEBUG_SPINLOOP is not set
>>> # CONFIG_VERSTAGE_DEBUG_SPINLOOP is not set
>>> # CONFIG_ROMSTAGE_DEBUG_SPINLOOP is not set
>>> *CONFIG_SPI_FLASH=y*
>>> CONFIG_BOOT_DEVICE_SPI_FLASH_RW_NOMMAP=y
>>> CONFIG_BOOT_DEVICE_SPI_FLASH_RW_NOMMAP_EARLY=y
>>> # CONFIG_SPI_FLASH_SMM is not set
>>> # CONFIG_SPI_FLASH_NO_FAST_READ is not set
>>> # CONFIG_SPI_FLASH_FAST_READ_DUAL_OUTPUT_3B is not set
>>> # CONFIG_SPI_FLASH_HAS_VOLATILE_GROUP is not set
>>> # CONFIG_HAVE_SPI_CONSOLE_SUPPORT is not set
>>> # CONFIG_BOOT_DEVICE_NOT_SPI_FLASH is not set
>>> *CONFIG_BOOT_DEVICE_SPI_FLASH=y*
>>> # CONFIG_HAVE_ROMSTAGE_CONSOLE_SPINLOCK is not set
>>> # CONFIG_HAVE_ROMSTAGE_NVRAM_CBFS_SPINLOCK is not set
>>> # CONFIG_HAVE_ROMSTAGE_MICROCODE_CBFS_SPINLOCK is not set
>>> # CONFIG_DEBUG_SPI_FLASH is not set
>>> [user@localhost coreboot]$
>>> Which one (but, anyway, I think you are on the wrong mental tread,
>>> unless *you explicitly prove to me that I am wrong*)? [image: Inline
>>> image 1]
>>>
>>>
>> Where are you setting the descriptor to use during the build? Those
>> settings highlighted in red have nothing to do with the flash descriptor
>> settings. Please look in src/southbridge/intel/common/firmware/Kconfig
>> for that list. Also, without the full details of your config it's
>> impossible to know what you are or aren't doing.
>>
>>
>>
>>> Zoran
>>>
>>> On Wed, Feb 22, 2017 at 3:39 PM, Aaron Durbin 
>>> wrote:
>>>
 On Wed, Feb 22, 2017 at 1:12 AM, Zoran Stojsavljevic
  wrote:
 > Hello to community,
 >
 > I finally, after 3 days of additional very hard struggle, found out
 why I
 > have (while I am in the last stage of building CBFS) nonsense while
 building
 > APL-I Coreboot coreboot.rom?!
 >
 > Please, read carefully this announcement.
 >
 > For last three days I came to hard stop because of this failure:
 >
 > Just quick look into the final failure (all passed, but last stage -
 IFD
 > failed):
 >
 > Compile IFDTOOL
 > HOSTCC util/ifdfake/ifdfake
 > DD Adding Intel Firmware Descriptor
 > IFDTOOLUnlocking Management Engine
 > File build/coreboot.pre is 8388608 bytes
 > No Flash Descriptor found in this image
 > src/southbridge/intel/common/firmware/Makefile.inc:50: recipe for
 target
 > 'add_intel_firmware' failed
 > make: *** [add_intel_firmware] Error 1
 > [user@localhost coreboot]$
 >
 > At first, I suspect that culprit my .config file, but I have checked
 it
 > several times (maybe > dozen), and I could NOT find any problem with
 it
 > (except minor doubts).
 >
 > Then I switched to inspect -southbridge- setup, but these is none,
 since
 > (simplified explanation/view) APL-I is SoC.
 >
 > The next phase was to inspect
 > src/southbridge/intel/common/firmware/Makefile.inc , but there
 (although my
 > make scripting is rusty) I could NOT find any problem...
 >
 > Finally, somewhere around 2:00 AM I noticed/determined the root cause
 of the
 > problem: the util/ifdtool/ifdtool.c, line:
 >   if (*(uint32_t *) 

Re: [coreboot] [VERY IMPORTANT] Announcement regarding Apollo Lake Coreboot building

[Aaron Durbin via coreboot]

On Wed, Feb 22, 2017 at 9:08 AM, Zoran Stojsavljevic <
zoran.stojsavlje...@gmail.com> wrote:

> You mean, this one (in *RED*)?
>
> [user@localhost coreboot]$ cat .config | grep SPI
> CONFIG_BOOT_DEVICE_SPI_FLASH_BUS=0
> # CONFIG_TPM_ON_FAST_SPI is not set
> # CONFIG_SPI_FLASH_INCLUDE_ALL_DRIVERS is not set
> CONFIG_SOC_INTEL_COMMON_SPI_FLASH_PROTECT=y
> # CONFIG_BOOTBLOCK_DEBUG_SPINLOOP is not set
> # CONFIG_VERSTAGE_DEBUG_SPINLOOP is not set
> # CONFIG_ROMSTAGE_DEBUG_SPINLOOP is not set
> *CONFIG_SPI_FLASH=y*
> CONFIG_BOOT_DEVICE_SPI_FLASH_RW_NOMMAP=y
> CONFIG_BOOT_DEVICE_SPI_FLASH_RW_NOMMAP_EARLY=y
> # CONFIG_SPI_FLASH_SMM is not set
> # CONFIG_SPI_FLASH_NO_FAST_READ is not set
> # CONFIG_SPI_FLASH_FAST_READ_DUAL_OUTPUT_3B is not set
> # CONFIG_SPI_FLASH_HAS_VOLATILE_GROUP is not set
> # CONFIG_HAVE_SPI_CONSOLE_SUPPORT is not set
> # CONFIG_BOOT_DEVICE_NOT_SPI_FLASH is not set
> *CONFIG_BOOT_DEVICE_SPI_FLASH=y*
> # CONFIG_HAVE_ROMSTAGE_CONSOLE_SPINLOCK is not set
> # CONFIG_HAVE_ROMSTAGE_NVRAM_CBFS_SPINLOCK is not set
> # CONFIG_HAVE_ROMSTAGE_MICROCODE_CBFS_SPINLOCK is not set
> # CONFIG_DEBUG_SPI_FLASH is not set
> [user@localhost coreboot]$
> Which one (but, anyway, I think you are on the wrong mental tread, unless *you
> explicitly prove to me that I am wrong*)? [image: Inline image 1]
>
>
Where are you setting the descriptor to use during the build? Those
settings highlighted in red have nothing to do with the flash descriptor
settings. Please look in src/southbridge/intel/common/firmware/Kconfig for
that list. Also, without the full details of your config it's impossible to
know what you are or aren't doing.



> Zoran
>
> On Wed, Feb 22, 2017 at 3:39 PM, Aaron Durbin  wrote:
>
>> On Wed, Feb 22, 2017 at 1:12 AM, Zoran Stojsavljevic
>>  wrote:
>> > Hello to community,
>> >
>> > I finally, after 3 days of additional very hard struggle, found out why
>> I
>> > have (while I am in the last stage of building CBFS) nonsense while
>> building
>> > APL-I Coreboot coreboot.rom?!
>> >
>> > Please, read carefully this announcement.
>> >
>> > For last three days I came to hard stop because of this failure:
>> >
>> > Just quick look into the final failure (all passed, but last stage - IFD
>> > failed):
>> >
>> > Compile IFDTOOL
>> > HOSTCC util/ifdfake/ifdfake
>> > DD Adding Intel Firmware Descriptor
>> > IFDTOOLUnlocking Management Engine
>> > File build/coreboot.pre is 8388608 bytes
>> > No Flash Descriptor found in this image
>> > src/southbridge/intel/common/firmware/Makefile.inc:50: recipe for
>> target
>> > 'add_intel_firmware' failed
>> > make: *** [add_intel_firmware] Error 1
>> > [user@localhost coreboot]$
>> >
>> > At first, I suspect that culprit my .config file, but I have checked it
>> > several times (maybe > dozen), and I could NOT find any problem with it
>> > (except minor doubts).
>> >
>> > Then I switched to inspect -southbridge- setup, but these is none, since
>> > (simplified explanation/view) APL-I is SoC.
>> >
>> > The next phase was to inspect
>> > src/southbridge/intel/common/firmware/Makefile.inc , but there
>> (although my
>> > make scripting is rusty) I could NOT find any problem...
>> >
>> > Finally, somewhere around 2:00 AM I noticed/determined the root cause
>> of the
>> > problem: the util/ifdtool/ifdtool.c, line:
>> >   if (*(uint32_t *) (image + i) == 0x0FF0A55A) {
>> >
>> > YET another INTEL IOTG PED hidden road bomb: the latest APL-I FSP:
>> > APL-I_FSP/ApolloLakeFspBinPkg/FspBin/ApolloLakeFsp.fd does NOT have
>> pattern
>> > 0x0FF0A55A embedded in it (I have checked with HxD WIN tool).
>>
>> So this device isn't supporting SPI boot? If so, then it's not
>> surprise that there's no SPI descriptor. And you didn't add one it
>> seems.
>> >
>> > Then, modifying the C f-n static fdbar_t *find_fd(char *image, int
>> size),
>> > finally I've got success! :-(
>> >
>> > Hello Martin,
>> >
>> > Thank you for unselfish help.
>> >
>> > Best Regards,
>> > Zoran Stojsavljevic
>> >
>> >
>> > --
>> > coreboot mailing list: coreboot@coreboot.org
>> > https://www.coreboot.org/mailman/listinfo/coreboot
>>
>
>
-- 
coreboot mailing list: coreboot@coreboot.org
https://www.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] [VERY IMPORTANT] Announcement regarding Apollo Lake Coreboot building

[Aaron Durbin via coreboot]

On Wed, Feb 22, 2017 at 1:12 AM, Zoran Stojsavljevic
 wrote:
> Hello to community,
>
> I finally, after 3 days of additional very hard struggle, found out why I
> have (while I am in the last stage of building CBFS) nonsense while building
> APL-I Coreboot coreboot.rom?!
>
> Please, read carefully this announcement.
>
> For last three days I came to hard stop because of this failure:
>
> Just quick look into the final failure (all passed, but last stage - IFD
> failed):
>
> Compile IFDTOOL
> HOSTCC util/ifdfake/ifdfake
> DD Adding Intel Firmware Descriptor
> IFDTOOLUnlocking Management Engine
> File build/coreboot.pre is 8388608 bytes
> No Flash Descriptor found in this image
> src/southbridge/intel/common/firmware/Makefile.inc:50: recipe for target
> 'add_intel_firmware' failed
> make: *** [add_intel_firmware] Error 1
> [user@localhost coreboot]$
>
> At first, I suspect that culprit my .config file, but I have checked it
> several times (maybe > dozen), and I could NOT find any problem with it
> (except minor doubts).
>
> Then I switched to inspect -southbridge- setup, but these is none, since
> (simplified explanation/view) APL-I is SoC.
>
> The next phase was to inspect
> src/southbridge/intel/common/firmware/Makefile.inc , but there (although my
> make scripting is rusty) I could NOT find any problem...
>
> Finally, somewhere around 2:00 AM I noticed/determined the root cause of the
> problem: the util/ifdtool/ifdtool.c, line:
>   if (*(uint32_t *) (image + i) == 0x0FF0A55A) {
>
> YET another INTEL IOTG PED hidden road bomb: the latest APL-I FSP:
> APL-I_FSP/ApolloLakeFspBinPkg/FspBin/ApolloLakeFsp.fd does NOT have pattern
> 0x0FF0A55A embedded in it (I have checked with HxD WIN tool).

So this device isn't supporting SPI boot? If so, then it's not
surprise that there's no SPI descriptor. And you didn't add one it
seems.
>
> Then, modifying the C f-n static fdbar_t *find_fd(char *image, int size),
> finally I've got success! :-(
>
> Hello Martin,
>
> Thank you for unselfish help.
>
> Best Regards,
> Zoran Stojsavljevic
>
>
> --
> coreboot mailing list: coreboot@coreboot.org
> https://www.coreboot.org/mailman/listinfo/coreboot

-- 
coreboot mailing list: coreboot@coreboot.org
https://www.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] Understand vboot logic to select FW_B

[Aaron Durbin via coreboot]

On Wed, Feb 15, 2017 at 3:20 PM,  <ttu...@codeaurora.org> wrote:
> On 2017-02-15 09:45, Aaron Durbin via coreboot wrote:
>>
>> On Wed, Feb 15, 2017 at 11:38 AM,  <ttu...@codeaurora.org> wrote:
>>>
>>> On 2017-02-15 07:46, Aaron Durbin via coreboot wrote:
>>>>
>>>>
>>>> On Tue, Feb 14, 2017 at 8:26 PM,  <ttu...@codeaurora.org> wrote:
>>>>>
>>>>>
>>>>>
>>>>> Folks,
>>>>> I'm working on coreboot on ARMv8 architecture and recently attempted to
>>>>> verify FW_B can be selected if FW_A is corrupted.
>>>>>
>>>>> In reviewing the code-path through coreboot vboot wrapper and
>>>>> vboot_reference library I'm not understanding the logic.
>>>>>
>>>>> The logic appears to be that vboot_reference library determines FW_A is
>>>>> corrupt and forces a reboot.
>>>>>
>>>>> After reboot, early in verstage_main(), both the NVRAM (flash) and
>>>>> vb2_context structures are initialized, wiping out any history of
>>>>> failure
>>>>> condition.
>>>>>
>>>>> I know I must be missing something in my analysis but don't see it.
>>>>>
>>>>> Can anybody on this list share their experiences in confirming the FW_B
>>>>> boot
>>>>> path if FW_A is corrupt?
>>>>
>>>>
>>>>
>>>>
>>>> ctx->flags & VB2_CONTEXT_FW_SLOT_B determines which slot to use. The
>>>> vbnv (vboot non-volatile) storage keeps counts for slots to try.
>>>> vb2_select_fw_slot() will do that work for you. It's located in
>>>> firmware/2lib/2misc.c. That function is called from vb2api_fw_phase2()
>>>> in firmware/2lib/2api.c.  All this logic lives in vboot_reference code
>>>> repository.
>>>>
>>>
>>> Thanks for this recap, I had identified most of this path previously.
>>>
>>> I can clearly see the corrupted A slot being detected and the status
>>> updated
>>> and vboot requesting a reboot.
>>> The reboot causes verstage to go through its initialization sequence,
>>> which
>>> in my case blows away the history of the reboot, so the cycle repeats
>>> endlessly.
>>> FW_A slot detected as corrupt reboot requested to boot from FW_B, reboot
>>> blows away this data and FW_A is detected to be corrupt and reboot
>>> requested, etc.
>>>
>>> I have verstage configured to run from bootblock, no DRAM/CBMEM
>>> available,
>>> just the RW_NVRAM fmap partition on the flash.
>>> I haven't made any change in vboot_reference or the coreboot vboot
>>> wrapper
>>> layer so for me, out of the box, something is amiss.
>>
>>
>>
>> The try count should drop on each reset. And then it should swap to
>> slot B. All of our ARMv8 and x86 boards utilize the same path. Have
>> you ensured your vbnv bindings are working? And dumping the vbnv
>> contents to the terminal each time might be helpful. I'm not sure what
>> platform you are running so it's hard to know what configuration and
>> support files you are including. Do you have serial console logging
>> enabled? What's it say?
>>
>> If you don't have one of these set then you wouldn't be reading any
>> vbnv -- or saving:
>>
>> CONFIG_VBOOT_VBNV_CMOS
>> CONFIG_VBOOT_VBNV_EC
>> CONFIG_VBOOT_VBNV_FLASH
>>
>> Check out read_vbnv() and save_vbnv() in src/vboot/vbnv.c.
>
>
> CONFIG_VBOOT_VBNV_FLASH is set in our system.
> I think the key point I was missing before is the vboot reset has to retain
> vboot bss data.
> The vbnv_flash variable (static struct vbnv_flash_ctx) has to remain
> initialized across the reboot.

No. We aren't reliant on that. It would get wiped on program load. If
it doesn't that's a bug. The vbnv is supposed to maintain the state
and the flow will reload the necessary state.

>
>
>>
>>>
>>> I would be interested in hearing from anybody on the list on an ARMv8
>>> target
>>> who has run the same test I'm trying to reproduce here.
>>> Specifically, I'm not running the test code in vboot_reference, I am
>>> manually corrupting partition A before flashing it.
>>> Cheers,
>>> T.mike
>>>
>>>
>>>>
>>>>> Cheers,
>>>>> T.mike
>>>>>
>>>>> --
>>>>> coreboot mailing list: coreboot@coreboot.org
>>>>> https://www.coreboot.org/mailman/listinfo/coreboot

-- 
coreboot mailing list: coreboot@coreboot.org
https://www.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] Understand vboot logic to select FW_B

[Aaron Durbin via coreboot]

On Wed, Feb 15, 2017 at 11:38 AM,  <ttu...@codeaurora.org> wrote:
> On 2017-02-15 07:46, Aaron Durbin via coreboot wrote:
>>
>> On Tue, Feb 14, 2017 at 8:26 PM,  <ttu...@codeaurora.org> wrote:
>>>
>>>
>>> Folks,
>>> I'm working on coreboot on ARMv8 architecture and recently attempted to
>>> verify FW_B can be selected if FW_A is corrupted.
>>>
>>> In reviewing the code-path through coreboot vboot wrapper and
>>> vboot_reference library I'm not understanding the logic.
>>>
>>> The logic appears to be that vboot_reference library determines FW_A is
>>> corrupt and forces a reboot.
>>>
>>> After reboot, early in verstage_main(), both the NVRAM (flash) and
>>> vb2_context structures are initialized, wiping out any history of failure
>>> condition.
>>>
>>> I know I must be missing something in my analysis but don't see it.
>>>
>>> Can anybody on this list share their experiences in confirming the FW_B
>>> boot
>>> path if FW_A is corrupt?
>>
>>
>>
>> ctx->flags & VB2_CONTEXT_FW_SLOT_B determines which slot to use. The
>> vbnv (vboot non-volatile) storage keeps counts for slots to try.
>> vb2_select_fw_slot() will do that work for you. It's located in
>> firmware/2lib/2misc.c. That function is called from vb2api_fw_phase2()
>> in firmware/2lib/2api.c.  All this logic lives in vboot_reference code
>> repository.
>>
>
> Thanks for this recap, I had identified most of this path previously.
>
> I can clearly see the corrupted A slot being detected and the status updated
> and vboot requesting a reboot.
> The reboot causes verstage to go through its initialization sequence, which
> in my case blows away the history of the reboot, so the cycle repeats
> endlessly.
> FW_A slot detected as corrupt reboot requested to boot from FW_B, reboot
> blows away this data and FW_A is detected to be corrupt and reboot
> requested, etc.
>
> I have verstage configured to run from bootblock, no DRAM/CBMEM available,
> just the RW_NVRAM fmap partition on the flash.
> I haven't made any change in vboot_reference or the coreboot vboot wrapper
> layer so for me, out of the box, something is amiss.


The try count should drop on each reset. And then it should swap to
slot B. All of our ARMv8 and x86 boards utilize the same path. Have
you ensured your vbnv bindings are working? And dumping the vbnv
contents to the terminal each time might be helpful. I'm not sure what
platform you are running so it's hard to know what configuration and
support files you are including. Do you have serial console logging
enabled? What's it say?

If you don't have one of these set then you wouldn't be reading any
vbnv -- or saving:

CONFIG_VBOOT_VBNV_CMOS
CONFIG_VBOOT_VBNV_EC
CONFIG_VBOOT_VBNV_FLASH

Check out read_vbnv() and save_vbnv() in src/vboot/vbnv.c.

>
> I would be interested in hearing from anybody on the list on an ARMv8 target
> who has run the same test I'm trying to reproduce here.
> Specifically, I'm not running the test code in vboot_reference, I am
> manually corrupting partition A before flashing it.
> Cheers,
> T.mike
>
>
>>
>>> Cheers,
>>> T.mike
>>>
>>> --
>>> coreboot mailing list: coreboot@coreboot.org
>>> https://www.coreboot.org/mailman/listinfo/coreboot

-- 
coreboot mailing list: coreboot@coreboot.org
https://www.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] Understand vboot logic to select FW_B

[Aaron Durbin via coreboot]

On Tue, Feb 14, 2017 at 8:26 PM,   wrote:
>
> Folks,
> I'm working on coreboot on ARMv8 architecture and recently attempted to
> verify FW_B can be selected if FW_A is corrupted.
>
> In reviewing the code-path through coreboot vboot wrapper and
> vboot_reference library I'm not understanding the logic.
>
> The logic appears to be that vboot_reference library determines FW_A is
> corrupt and forces a reboot.
>
> After reboot, early in verstage_main(), both the NVRAM (flash) and
> vb2_context structures are initialized, wiping out any history of failure
> condition.
>
> I know I must be missing something in my analysis but don't see it.
>
> Can anybody on this list share their experiences in confirming the FW_B boot
> path if FW_A is corrupt?


ctx->flags & VB2_CONTEXT_FW_SLOT_B determines which slot to use. The
vbnv (vboot non-volatile) storage keeps counts for slots to try.
vb2_select_fw_slot() will do that work for you. It's located in
firmware/2lib/2misc.c. That function is called from vb2api_fw_phase2()
in firmware/2lib/2api.c.  All this logic lives in vboot_reference code
repository.


> Cheers,
> T.mike
>
> --
> coreboot mailing list: coreboot@coreboot.org
> https://www.coreboot.org/mailman/listinfo/coreboot

-- 
coreboot mailing list: coreboot@coreboot.org
https://www.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] Add coreboot storage driver

[Aaron Durbin via coreboot]

On Tue, Feb 14, 2017 at 1:07 PM, Patrick Georgi <pgeo...@google.com> wrote:
> 2017-02-14 17:12 GMT+01:00 Aaron Durbin via coreboot <coreboot@coreboot.org>:
>> For an optimized bootflow
>> all pieces of work that need to be done pretty much need to be closely
>> coupled. One needs to globally optimize the full sequence.
> Like initializing slow hardware even before RAM init (as long as it's
> just an initial command)?
> How about using PIT/IRQ0 plus some tiny register-only interrupt
> routine to do trivial register wrangling (we do have register
> scripts)?

I don't think I properly understand your suggestion. For this
particular eMMC case are you suggesting taking the PIT interrupt and
doing the next piece of work in it?

>
>> that we seem to be absolutely needing to
>> maintain boot speeds. Is Chrome OS going against tide of coreboot
>> wanting to solve those sorts of issues?
> The problem is that two basic qualities collide here: speed and
> simplicity. The effect is that people ask to stop a second to
> reconsider the options.
> MPinit and parallelism are the "go to" solution for all performance
> related issues of the last 10 years, but they're not without cost.
> Questioning this approach doesn't mean that that we shouldn't go there
> at all, just that the obvious answers might not lead to simple
> solutions.
>
> As Andrey stated elsewhere, we're far from CPU bound.

Agreed. But our chunking of work is very coarsely sectioned up. I
think the other CPU path is an attempt to work around the coarseness
of the work steps in the dependency chain.

>
> For his concrete example: does eMMC init fail if you ping it more
> often than every 10ms? It better not, you already stated that it's
> hard to guarantee those 10ms, so there needs to be some spare room. We
> could look at the largest chunk of init process that could be
> restructured to implement cooperative multithreading on a single core
> for as many tasks as possible, to cut down on all those udelays (or
> even mdelays). Maybe we could even build a compiler plugin to ensure
> at compile time that the resulting code is proper (loops either have
> low bounds or are yielding, yield()/sched()/... aren't called within
> critical sections)...

That's a possibility, but you have to solve the case for each
combination of hardware present and/or per platform. Building up the
dependency chain is the most important piece. And from there to ensure
execution context is not lost for longer than a set amount of time.
We're miles away from that since we're run to completion serially
right now.

>
> Once we leave that scheduling to physics (ie enabling multicore
> operation), all bets are off (or we have to synchronize the execution
> to a degree that we could just as well do it manually). A lot of
> complexity just to have 8 times the CPU power for the same amount of
> IO bound tasks.
>
>
> Patrick

-- 
coreboot mailing list: coreboot@coreboot.org
https://www.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] Add coreboot storage driver

[Aaron Durbin via coreboot]

On Tue, Feb 14, 2017 at 1:06 PM, Nico Huber  wrote:
> On 14.02.2017 18:56, ron minnich wrote:
>> At what point is ramstage a kernel? I think at the point we add file
>> systems or preemptive scheduling. We're getting dangerously close. If we
>> really start to cross that boundary, it's time to rethink the ramstage in
>> my view. It's not a good foundation for a kernel.
>
> Agreed. I wouldn't call it a kernel, but it really seems to grow very
> ugly. Every time I think about this, I scarcely find anything that needs
> to be done in ramstage. I believe even most payloads could live without
> it with some more initialization done in romstage.
>
> Some things that I recall, what ramstage does:
>
>   o MP init => maybe can be done earlier, does it need RAM generally???

You need a stack and vector for the SIPI to be somewhere.

>
>   o PCI resource allocation => can be done offline
> Just add the resources to the devicetree. If you want to boot
> from a plugged card, that isn't in the devicetree, the payload
> would have to handle it though.

This largely works with static allocation, but the question is if you
want to handle different SKUs of devices that have different hardware
behind root bridges. You need to recalculate the IO windows. You could
produce a signature of devices and leverage that for picking the right
static allocation. Doable, but gets kinda funky needing to run the
allocation pass for each configuration and ensuring its updated
properly.
>
>   o Those small PCI device "drivers" => I doubt they need RAM

That's how their initialization code is currently scheduled. May not
need RAM, but I'm not sure that's what makes them distinctive nor why
you bring this up? Just a regular pci device doesn't need anything in
practice. It's the workarounds and things that need to be done for
power optimization, etc is where the complexity arises. Using pci
device "drivers" as a proxy for all pci devices isn't representative.

>
>   o Table generation => Not that dynamic after all
> I suppose much is done with static (compile time) information.

Sure, if you go and analyze devicetree.cb to know all the options.
Tables have quite a few things that change based on runtime attributes
aside from that. For example, a single firmware build can support a
different number SoC models that have largely different numbers of
CPUs, etc or support different feature sets that require different
table generation.

>
>   o Sometimes gfx modesetting => do it in the payload
>
> Nico

-- 
coreboot mailing list: coreboot@coreboot.org
https://www.coreboot.org/mailman/listinfo/coreboot